Packaging for guix

[John Soo]

Hello pyside maintainers,

Hope you are all well.  I am looking to package freecad for the guix package 
manager for which pyside is a dependency. I’m having some trouble packaging 
pyside as the build and environment for guix (like nix) are quite different 
from a Debian style system. There a quite a few differences:

 -  the prefix for installation directories is in a unique directory specific 
to the package
 - cmake and python require many particular environment variables and flags
- library and linking paths are very different and often source shebangs and 
linking paths need to be patched to point to the correct paths
 - the build process happens in an isolated build environment apart from any 
system directories
 - probably more that I haven’t come across yet

I’ve tried using the provided python build process but I get several build 
errors, let alone runtime issues. Would anyone be able to point me in a 
direction to patch pyside for such a packaging system? Currently I’m stuck 
building Shiboken. I’d particularly like guidance on how to setup cmake to 
build it correctly (mostly the ability to provide our particular flags and 
variables). Any help would be greatly appreciated.

Thank you,

John

Re: 02/05: gnu: tdb: Update to 1.4.0.

[Mark H Weaver]

Hi Marius,

guix-comm...@gnu.org writes:

> mbakke pushed a commit to branch master
> in repository guix.
>
> commit 5e7e193b71a39c7b31d7036aaef25644a4bc7206
> Author: Marius Bakke 
> Date:   Sat Mar 23 22:13:01 2019 +0100
>
> gnu: tdb: Update to 1.4.0.
> 
> * gnu/packages/databases.scm (tdb): Update to 1.4.0.

Although I've never had trouble building earlier versions of tdb, this
new version consistently fails its test suite on my Thinkpad X200
running GuixSD, or at least it has failed in four consecutive attempts.

On the other hand, I see that hydra.gnunet.org built tdb-1.4.0 on its
first attempt.  Bah.  I guess I'll just revert this update on my private
machine for now.

See below for the log of one of the failed build attempts.

   Mark


starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to 
`/gnu/store/b7fqhszxl02g6pfm3vw6b3cjz472qrly-python-3.7.0/bin:/gnu/store/29dazsnk3rr5j5kv9wi0p2974an9z9sk-which-2.21/bin:/gnu/store/bl3pxxj6frg0dww8pj5dvh2d1akwvj47-tar-1.30/bin:/gnu/store/h0c398zan9ibhk4w0c944vp5pwgzkfpd-gzip-1.9/bin:/gnu/store/j74aabxwayjl9yfyrm6ni482gykxq48b-bzip2-1.0.6/bin:/gnu/store/9425b5dwpfc04bb4p58hsjypxghliyr3-xz-5.2.4/bin:/gnu/store/ypiyk8ngn79cz655jrl0hng37xv54yjr-file-5.33/bin:/gnu/store/4bzzz0lzjc9b7bfsnqbq2j22d4fvf433-diffutils-3.6/bin:/gnu/store/a4rxl40jr7gmq8bp3dryq4yq67cwkwiw-patch-2.7.6/bin:/gnu/store/fd621k6fmdnr1yiw0lbvw5spqaa169j3-findutils-4.6.0/bin:/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk-4.2.1/bin:/gnu/store/lmfddplnplxd03bcqv3w9pynbnr1fp8k-sed-4.5/bin:/gnu/store/02k245xy33cvcnr8vm3lagm9zmb1s2wa-grep-3.1/bin:/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin:/gnu/store/7j3941iannrngdvgbclyxid12vds5w9i-make-4.2.1/bin:/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin:/gnu/store/9ysmg2739n1ms84lx6hifncgc5l2hiy9-ld-wrapper-0/bin:/gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/bin:/gnu/store/n2p1zs14y89lwkg9da68y12pc10c6sw9-gcc-5.5.0/bin:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/bin:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/sbin'
environment variable `PYTHONPATH' set to 
`/gnu/store/b7fqhszxl02g6pfm3vw6b3cjz472qrly-python-3.7.0/lib/python3.7/site-packages'
environment variable `BASH_LOADABLES_PATH' unset
environment variable `C_INCLUDE_PATH' set to 
`/gnu/store/b7fqhszxl02g6pfm3vw6b3cjz472qrly-python-3.7.0/include:/gnu/store/j74aabxwayjl9yfyrm6ni482gykxq48b-bzip2-1.0.6/include:/gnu/store/9425b5dwpfc04bb4p58hsjypxghliyr3-xz-5.2.4/include:/gnu/store/ypiyk8ngn79cz655jrl0hng37xv54yjr-file-5.33/include:/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk-4.2.1/include:/gnu/store/7j3941iannrngdvgbclyxid12vds5w9i-make-4.2.1/include:/gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/include:/gnu/store/n2p1zs14y89lwkg9da68y12pc10c6sw9-gcc-5.5.0/include:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include:/gnu/store/xha1mk4qji8fmg62nygfzdx0l94ikdhm-linux-libre-headers-4.14.67/include'
environment variable `CPLUS_INCLUDE_PATH' set to 
`/gnu/store/b7fqhszxl02g6pfm3vw6b3cjz472qrly-python-3.7.0/include:/gnu/store/j74aabxwayjl9yfyrm6ni482gykxq48b-bzip2-1.0.6/include:/gnu/store/9425b5dwpfc04bb4p58hsjypxghliyr3-xz-5.2.4/include:/gnu/store/ypiyk8ngn79cz655jrl0hng37xv54yjr-file-5.33/include:/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk-4.2.1/include:/gnu/store/7j3941iannrngdvgbclyxid12vds5w9i-make-4.2.1/include:/gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/include:/gnu/store/n2p1zs14y89lwkg9da68y12pc10c6sw9-gcc-5.5.0/include:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include:/gnu/store/xha1mk4qji8fmg62nygfzdx0l94ikdhm-linux-libre-headers-4.14.67/include'
environment variable `LIBRARY_PATH' set to 
`/gnu/store/b7fqhszxl02g6pfm3vw6b3cjz472qrly-python-3.7.0/lib:/gnu/store/j74aabxwayjl9yfyrm6ni482gykxq48b-bzip2-1.0.6/lib:/gnu/store/9425b5dwpfc04bb4p58hsjypxghliyr3-xz-5.2.4/lib:/gnu/store/ypiyk8ngn79cz655jrl0hng37xv54yjr-file-5.33/lib:/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk-4.2.1/lib:/gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/lib:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib:/gnu/store/a3p8zc23w5asxck5h4mswz4s8yl9s6pa-glibc-2.28-static/lib:/gnu/store/mn3ymm3f2r4xjqf8m9fgmadh6b8p6fvr-glibc-utf8-locales-2.28/lib'
environment variable `GUIX_LOCPATH' set to 
`/gnu/store/mn3ymm3f2r4xjqf8m9fgmadh6b8p6fvr-glibc-utf8-locales-2.28/lib/locale'
phase `set-paths' succeeded after 0.0 seconds
starting phase `install-locale'
using 'en_US.utf8' locale for category "LC_ALL"
phase `install-locale' succeeded after 0.0 seconds
starting phase `unpack'
tdb-1.4.0/ABI/tdb-1.2.1.sigs
tdb-1.4.0/ABI/tdb-1.2.10.sigs
tdb-1.4.0/ABI/tdb-1.2.11.sigs
tdb-1.4.0/ABI/tdb-1.2.12.sigs
tdb-1.4.0/ABI/tdb-1.2.13.sigs
tdb-1.4.0/ABI/tdb-1.2.2.sigs
tdb-1.4.0/ABI/tdb-1.2.3.sigs
tdb-1.4.0/ABI/tdb-1.2.4.sigs
tdb-1.4.0/ABI/tdb-1.2.5.sigs
tdb-1.4.0/ABI/tdb-1.2.6.sigs

Re: Status update on 1.0

[pelzflorian (Florian Pelz)]

On Wed, Mar 27, 2019 at 04:26:55PM +0100, Ludovic Courtès wrote:
> Anyway, you’re still very much welcome to test the installer!  See the
> manual on how to build the installation image:
> 

I tested an old install image a few weeks old and the
locales/languages in the language selection at the beginning were
apparently not sorted by their English name, but the English name was
displayed, so the sorted order was wrong.  Also, will the locale
chosen at the beginning affect the installer’s locale and use
translations?  (I know there are no translated po files yet for the
installer, but would they get used?)  Would it be possible to first
select the locale in the installer and then select a manual
non-installer setup and be shown the info manual for the chosen locale
instead of the English info manual?

Also in my old install image the image cannot boot on my AMD Radeon
because it gets stuck at

[9.334790] fb0: switching to radeondrmfb from EFI VGA

but I believe this issue is known and it was said to be due to KMScon
and maybe it is fixed in a current image.

Re: Status update on 1.0

[Danny Milosavljevic]

Hi Ludo,

On Wed, 27 Mar 2019 16:26:55 +0100
Ludovic Courtès  wrote:

> Anyway, you’re still very much welcome to test the installer!  See the
> manual on how to build the installation image:
> 
>   
> https://gnu.org/software/guix/manual/en/html_node/Building-the-Installation-Image.html

I've tried this on qemu and had the infamous "waiting for udev" problem Mark
also saw on Hydra before.

After rebooting, the same image worked fine.
The installer also works fine and looks great!

Also, I used the non-iso9660 disk image because the iso9660 disk image (not 
documented
on the page above either) has 1.5 MB (not a typo).

$ file /gnu/store/lcx2w0y6pi6av4qhipmwc9xjzy4p7gbd-image.iso
/gnu/store/lcx2w0y6pi6av4qhipmwc9xjzy4p7gbd-image.iso: DOS/MBR boot sector; 
GRand Unified Bootloader, stage1 version 0x79, boot drive 0xbb, stage2 address 
0x8e70, 1st sector stage2 0xb8db31c3, stage2 segment 0x201; partition 1 : 
ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3f8,9,12), startsector 1, 3121451 
sectors, extended partition table (last)

$ stat /gnu/store/lcx2w0y6pi6av4qhipmwc9xjzy4p7gbd-image.iso
  File: /gnu/store/lcx2w0y6pi6av4qhipmwc9xjzy4p7gbd-image.iso
  Size: 1495040 Blocks: 2920   IO Block: 4096   regular file
Device: 801h/2049d  Inode: 34661153Links: 2
Access: (0444/-r--r--r--)  Uid: (0/root)   Gid: (0/root)
Access: 2019-03-27 23:25:26.240200749 +0100
Modify: 1970-01-01 01:00:01.0 +0100
Change: 2019-03-27 23:25:26.248200669 +0100
 Birth: -


pgpeN8r7uzP_P.pgp
Description: OpenPGP digital signature

Re: Video narration

[Laura Lazzati]

Hi Paul!


> I am 4/7ths of the way through the transcripts :)
Great! I am recording the audios in the late evening to have the less
environmental noise as possible.
>
> On the latest one , 02-daily-use2, line 9, there is the URL:
>
> https://audio.video.gnu.org/guix/everyday-use-part1.webm
>
> Is this correct?  The output in the videos subdirectory is '02-daily-
> use1.webm'
Yes, maybe we should change the subdirectory name (and final video),
but it would be just renaming them.

Regards :)
Laura

Re: Video narration

[Paul Garlick]

Hi Laura,

I am 4/7ths of the way through the transcripts :)

On the latest one , 02-daily-use2, line 9, there is the URL:

https://audio.video.gnu.org/guix/everyday-use-part1.webm

Is this correct?  The output in the videos subdirectory is '02-daily-
use1.webm'

Best regards,

Paul.

Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.

[Tobias Geerinckx-Rice]

Pierre, hell, all,

Pierre Neidhardt wrote:

(Using Emacs-Guix.el, Helm, or the next GTK interface.)


Emacs?  Helm?  This ‘average user’ thing is a red herring.

I visited my mother today and she asked why my screen is always 
black and white.


I admit to being irritated by this speculation in my previous 
reply, yet happily joined in, and I shouldn't have.  Since…


Why bother?  We don't have to choose between POLA from other 
command-line package managers and providing pretty metadata for 
higher-level UIs.

We can do both.


Absolutely.


…this is all that matters.

(No, not people agreeing with me.)

Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.

[Daniel Jiang]

Hello,

Might be related to the subject (?) but would adding something like
keywords/tags to package definitions help? On Emacs, a package definition
like this can pop up:

ack is an available package.
>
>  Status: Available from gnu -- Install
> Archive: gnu
> Version: 1.8
> Summary: interface to ack-like tools
>Homepage: https://github.com/leoliu/ack-el
>Keywords: tools processes convenience
>

Then searching packages via keywords can be done:
https://www.gnu.org/software/emacs/manual/html_node/emacs/Package-Keywords.html

On Slackbuilds likewise (keywords somewhere below):
https://slackbuilds.org/repository/14.2/system/guix/

This could be metadata to help find related stuff so there can be a games
tag for the wesnoth package. Also dunno how related, but in Common Lisp
nicknames can be defined for packages. I wrote some game programming
libraries bindings before that uses a longer name for the definition but a
two letter nickname to make it easier to use in practice.

Sincerely,
Daniel Jiang

On Wed, Mar 27, 2019 at 1:26 PM Pierre Neidhardt  wrote:

> Tobias Geerinckx-Rice  writes:
>
> > TL;DR: we're missing a field like ‘DISPLAY-NAME’, and all this is
> > just hacking around the bush.
>
> This could be a very nice idea!
>
> > Using this logic, I counter that these very long names unfairly
> > privilege 1337 hackers who can touch-type, and hurt the average
> > Jo' poking at their chiclet keyboard with a chopstick ;-)
> >
> > Both arguments make about as much sense IMO (and caricature
> > users).  I think a name like ‘the-battle-for-wesnoth’ helps
> > *neither* user.
>
> Users who cannot touch-type will typically perform simple queries, such as:
>
> - battle wesnoth
> - wesnoth battle
> - battle
> - wesnoth
>
> (Using Emacs-Guix.el, Helm, or the next GTK interface.)
>
> With "wesnoth" as a name, 3 out 4 queries won't hit a result.
>
> I don't think that "typing" is the issue here.  At least, I wouldn't
> sacrifice the _ability to search_ just to type short names.
>
> Also an option is to alias package names.
>
>
> > XLong names take longer to type on the command line, and noisy to
> > read in code.
>
> Noisy?  Why?  Short code filled with acronyms tends to be harder to read
> then long explicit names.
>
> Package names are mostly used as inputs.  In those longs package lists,
> it's really nice to have explicit names and leave little room for
> ambiguity.
>
> > Some hinder tab-completion.
>
> Why?
>
> > In a GUI, they still look ugly: why no spaces?  Why lowercase?
> > Why bother?  We don't have to choose between POLA from other
> > command-line package managers and providing pretty metadata for
> > higher-level UIs.
> > We can do both.
>
> Absolutely.
>
> --
> Pierre Neidhardt
> https://ambrevar.xyz/
>

Re: gold linker and collect2: fatal error: cannot find 'ld'

[Ludovic Courtès]

Hi Pjotr,

Pjotr Prins  skribis:

> On Sun, Mar 17, 2019 at 05:06:16PM +0100, Pjotr Prins wrote:
>> Unfortunately the runtime of compiled software fails because the rpath is
>> not updated either. So that requires adding in the RPATH explicitly on
>> the ldc command line. When I set the RPATH the runtime is fine. 
>
> Reading up on the ld-wrapper code - that is exactly what happens. A
> gold-wrapper can do same.
>
> I think, like with rustc, I need to wrap the ldc compiler build with
> ld-wrapper and the ldc tests with gold-wrapper (yet to be written).

Indeed.  We’d just need to add a parameter to ‘make-ld-wrapper’ so we
can specify the executable name, which would be “gold” instead of “ld”
in this case.

Would you like to give it a try?

> gold does not honour LIBRARY_PATH so that means we'll have to use
> LD_LIBRARY_PATH or pass the lib path(s) on the command line. 

LIBRARY_PATH is honored by gcc, which “converts” it into a list of -L
flags for the linker, so no worries here.

HTH, and sorry for the delay!

Ludo’.

Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.

[Pierre Neidhardt]

Ricardo Wurmus  writes:

> Completion should not be used as an excuse to use long package names.
> For one, not everyone is using Bash, so not everyone benefits from our
> Bash completions.  (Some shells can reuse Bash completions but this does
> not invalidate the point.)

We could argue the other way around: limited interfaces should not be an
excuse for amputated names.

The Unix naming scheme ("ls" for "list", etc.) made more sense in a time
where computer users had much more limited input (no completion, etc.)
and output (small screens).

> The package name is just an identifier for command line interaction
> purposes.

I don't see it this way.  The package name is a global variable in the
Guix project, and it bears a global semantic value.  It's used as a
public identifier that has to meaningfully convey the content of the package
to the developers but also to the users.

> There is no reason why it should be descriptive – after all,
> that’s what the package description is used for.  Users can easily find
> the package they are interested in by using the search feature.

Sadly the search feature is even less accessible than bash completion.
It's slower and more demanding to use.

Since this discussion got started, this hints that there might be
a "user experience" issue with our search system.

> That will give them the short name by which they can refer to the
> package.

I don't think this makes for a good user experience in my opinion.
This means that we expect everyone to be using the rather slow and
verbose "guix package --search" and not expect "the principle of least
surprise" to be working.

> Having that short name be long serves little purpose.

I can think of a some long, explicit names instead of
short, cryptic names:

- Improve search experience, completion, live-search.
- Avoid users believe existing packages are missing.
- Avoid packages re-packaging existing package because they failed to
  find them.
- Improve consistency.
- Improve code readability

> In the past we agreed to certain naming rules and we put them into the
> contributors’ guide.  If we want to change or relax those rules we need
> to reach consensus, collectively.  This cannot be a unilateral decision.

I never claimed this ;)

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


signature.asc
Description: PGP signature

Re: Status update on 1.0

[znavko]

Thank you! Nice work! 
Guile handbook wanted!


Mar 27, 2019, 3:26 PM by l...@gnu.org:

> Hello!
>
> Ludovic Courtès <> l...@gnu.org > > skribis:
>
>> • The installer should be changed to produce the right
>>  ‘initrd-modules’ field, using the same mechanism used by
>>  ‘check-device-initrd-modules’.
>>
>
> I’ve done this in commit 50247be5f4633a4c3446cddbd3515d027853ec0d, and
> also added a confirmation dialog before formatting disks in commit
> c73e554c3fe609ee2d66628f7f09cf7fa6c8d4a6 (I think it was Pierre who
> suggested it at the Guix Days.)
>
> I’ve added keyboard layout configuration, except for Xorg, in commit
> 3191b5f6ba5ebbb59a7448facd999ad7f7aeae79.
>
> Xorg keyboard layout configuration remains a bit too complicated so I
> think we’d first need to simplify it, though I’m not sure how (introduce
> an intermediate service?).
>
> Anyway, you’re still very much welcome to test the installer!  See the
> manual on how to build the installation image:
>
>  > 
> https://gnu.org/software/guix/manual/en/html_node/Building-the-Installation-Image.html
>  
> 
>
> Ludo’.
>

Re: Status update on 1.0

[Ludovic Courtès]

Hello!

Ludovic Courtès  skribis:

>   • The installer should be changed to produce the right
> ‘initrd-modules’ field, using the same mechanism used by
> ‘check-device-initrd-modules’.

I’ve done this in commit 50247be5f4633a4c3446cddbd3515d027853ec0d, and
also added a confirmation dialog before formatting disks in commit
c73e554c3fe609ee2d66628f7f09cf7fa6c8d4a6 (I think it was Pierre who
suggested it at the Guix Days.)

I’ve added keyboard layout configuration, except for Xorg, in commit
3191b5f6ba5ebbb59a7448facd999ad7f7aeae79.

Xorg keyboard layout configuration remains a bit too complicated so I
think we’d first need to simplify it, though I’m not sure how (introduce
an intermediate service?).

Anyway, you’re still very much welcome to test the installer!  See the
manual on how to build the installation image:

  
https://gnu.org/software/guix/manual/en/html_node/Building-the-Installation-Image.html

Ludo’.

Re: Interested in working on Guix for Google Summer of Code

[Ludovic Courtès]

Hello Daniel!

Daniel Jiang  skribis:

> I'm a student at the University of Illinois at Urbana-Champaign, a huge
> emacs user, and have been curious about Guix/GuixSD for a while now. I
> found it as a possible project on GSoC and thought it'd be interesting to
> help work on if possible. The organization page on GSoC said to contact the
> mentors and was directed to the mailing list from #guix@freenode. I also
> recognize one of the mentors who wrote bindings to a game programming
> library for Guile because I was writing some for Common Lisp at the time,
> so small world lol. (I dunno if you're reading this or know I exist but
> hello davexunit?)

Nice!

> Anyways, are there additional steps to take or things to know other than
> submitting a GSoC proposal based on this?
> https://www.gnu.org/software/soc-projects/guidelines.html

To get a feel of the project, I’d suggest installing it and giving it a
try for yourself.  You can install the “binary tarball” on top of your
distro if you don’t feel like jumping into the standalone Guix system:

  https://gnu.org/s/guix/manual/en/html_node/Binary-Installation.html

Then we usually recommend that newcomers try adding a package definition
for their favorite piece of software.  It’s a good way to get started
with the code base:

  https://gnu.org/software/guix/blog/2018/a-packaging-tutorial-for-guix/
  https://gnu.org/software/guix/manual/en/html_node/Defining-Packages.html

> And what might be some ideas on the level for a undergrad with a bit of
> experience?
> https://libreplanet.org/wiki/Group:Guix/GSoC-2019#Guix_Deploy

I’m Cc’ing Dave Thompson (aka. davexunit) and Chris Webber
(aka. dustyweb) who would be your mentors, and I’ll let them answer.
:-)

Thank you for getting in touch with us!

Ludo’.

Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.

[Ricardo Wurmus]

Pierre wrote:
>Finally, as I mentioned above with the completion systems that we have,
>we've got nothing to lose in having long names.

swedebugia wrote:
> Good useability is important and cryptic acronyms are not something to
> expose to the user if possible to avoid IMO.

> Maybe this is where we need to discuss what our target audience is?
> Nerds only? […]

This is a false dichotomy, in my opinion.  Good usability is not at odds
with using short package names.  I also think that the length of package
names is not going to be a deciding factor for somebody who is not a
“nerd”, so let’s not go down this tangent please.  There are different
interfaces to package managers, and we’re currently not offering fully
functional interfaces that would be more suitable for people without a
“techie” background.  If you want to make Guix more accessible *that’s*
a screw to turn, not the length of package names.

Completion should not be used as an excuse to use long package names.
For one, not everyone is using Bash, so not everyone benefits from our
Bash completions.  (Some shells can reuse Bash completions but this does
not invalidate the point.)

The package name is just an identifier for command line interaction
purposes.  There is no reason why it should be descriptive – after all,
that’s what the package description is used for.  Users can easily find
the package they are interested in by using the search feature.  That
will give them the short name by which they can refer to the package.
Having that short name be long serves little purpose.

In the past we agreed to certain naming rules and we put them into the
contributors’ guide.  If we want to change or relax those rules we need
to reach consensus, collectively.  This cannot be a unilateral decision.

--
Ricardo

Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.

[Ludovic Courtès]

Hello swedebugia,

swedebugia  skribis:

> Good useability is important and cryptic acronyms are not something to expose 
> to the user if possible to avoid IMO. 
>
> Maybe this is where we need to discuss what our target audience is? Nerds 
> only?

I think you’re jumping to the conclusions here.  :-)

We didn’t discuss any acronyms, and we all agree that good usability is
important.

Ludo’.

Re: Audio/sound (ALSA) in guix environment --container

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> Pierre Neidhardt  writes:
>>
>>> Ricardo Wurmus  writes:
>>>
 I suppose /etc/pam.d/ also needs to be in the container.
>>>
>>> Tried it, same error.
>>>
> What about defaulting to 1000?  It's rather common, so I guess that
> would be anonymous enough and "just work".

 Would it make sense to map the current user’s UID into the container
 instead of using a fixed UID?
>>>
>>> We have a "--user" option, so we could use the current user's UID when
>>> --user is not specified, 1000 otherwise.
>>> Or better: add a --uid CLI option.
>>
>> I can see confusion coming from the existence of both “--user” and
>> “--uid”.  Maybe “--user” could take an optional argument, with the
>> default being the current user.  Without “--user” we’d use UID 1000.
>
> Currently, without --user, we keep the current user’s name.  So it would
> actually be consistent to inherit its UID as well.  And with ‘--user’,
> we’d use the given user name and UID 1000.  (Essentially what Pierre
> proposed above.)

Excellent, this sounds good.

-- 
Ricardo

Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.

[Ludovic Courtès]

Hi!

Pierre Neidhardt  skribis:

> Ludovic Courtès  writes:
>
>> Apologies if I missed a previous discussion on this topic, but… I’m
>> skeptical about the renames.  I assume that the original names were
>> those commonly used in distributions, which in itself may be a good
>> reason to keep them.
>
> Names may vary a lot across distributions.  Especially when it comes to
> games, since they tend to have more exotic titles.
>
> If the majority of distributions decides on a poor name, we don't have
> to repeat the same mistake ;)

I agree, but there’s also a tension between that and not violating the
“principle of least surprise”.  Sometimes the latter outweighs the
former.

>> Those names are also used upstream in some cases: the tarball for
>> wesnoth is called “westnoth*.tar.gz”, for example, and the GitHub
>> project of L’Abbaye des morts is “abbayedesmorts” (no ‘l’).  Like our
>> naming guidelines say (info "(guix) Package Naming"), we should try to
>> stick to the upstream name.
>>
>> Thoughts?
>
> I think it's important to ask "why should we name a package this way."
> What's the rationale behind a package name?

I agree with what you’re saying but (1) we’re talking about package
name, which are different from fully spelled out “fancy names” (like
“L’Abbaye des morts”).

For package names, our policy is to follow upstream’s own package name.
For The Battle of Westnoth, it’s “westnoth”.

By doing that, we make the user’s lives easier in that they may already
be familiar with this short name.  If, instead, we try to roll our own
that neither distros nor upstream uses, then we’re not helping people.

Completion helps, I agree, but not everyone uses Helm either.  If you’re
in Bash and type “guix package -i w” and don’t see “westnoth”,
you’re unhappy, and user unhappiness is bad.  :-)

In a GUI things may be different because the package name doesn’t matter
that much.

Thanks,
Ludo’.

Re: Audio/sound (ALSA) in guix environment --container

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Pierre Neidhardt  writes:
>
>> Ricardo Wurmus  writes:
>>
>>> I suppose /etc/pam.d/ also needs to be in the container.
>>
>> Tried it, same error.
>>
 What about defaulting to 1000?  It's rather common, so I guess that
 would be anonymous enough and "just work".
>>>
>>> Would it make sense to map the current user’s UID into the container
>>> instead of using a fixed UID?
>>
>> We have a "--user" option, so we could use the current user's UID when
>> --user is not specified, 1000 otherwise.
>> Or better: add a --uid CLI option.
>
> I can see confusion coming from the existence of both “--user” and
> “--uid”.  Maybe “--user” could take an optional argument, with the
> default being the current user.  Without “--user” we’d use UID 1000.

Currently, without --user, we keep the current user’s name.  So it would
actually be consistent to inherit its UID as well.  And with ‘--user’,
we’d use the given user name and UID 1000.  (Essentially what Pierre
proposed above.)

Thoughts?  :-)

Ludo’.

XDG_DATA_DIRS issue in execution environment on LTSP

[Giovanni Biscuolo]

Hello,

I want to share this issue and show my "workaround" to fix it, please
send your comments on alternative ways or other caveats you may find in
my reasoning

I'm running Guix on top of Debian/stretch, recently I made Guix
environment the default execution one for my console and graphical
applications (bad idea?) and now I have to fix env every time I want to
run a Debian installed application

Since I'm connecting to my machine via an LTSP terminal, I followed this
guide https://wiki.debian.org/EnvironmentVariables#Quick_guide to have
the Guix profile automatically set up when I login via LDM; so now I
have this in my .profile:

--8<---cut here---start->8---
### Guix settings
#
# add Guix current path
export PATH="$HOME/.config/guix/current/bin${PATH:+:}$PATH"
# add Guix infopath
export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"
# set default Guix profile
export GUIX_PROFILE="$HOME/.guix-profile"
# source default Guix profile
. $GUIX_PROFILE/etc/profile
# set Guix locale path
export GUIX_LOCPATH="$GUIX_PROFILE/lib/locale"
### end Guix
--8<---cut here---end--->8---

and this in my .bash_profile *and* .xsessionrc:

--8<---cut here---start->8---
if [ -f ~/.profile ]; then
. ~/.profile
fi
--8<---cut here---end--->8---

and lastly this in $GUIX_PROFILE/etc/profile:

--8<---cut here---start->8---
# Source this file to define all the relevant environment variables in Bash
# for this profile.  You may want to define the 'GUIX_PROFILE' environment
# variable to point to the "visible" name of the profile, like this:
#
#  GUIX_PROFILE=/path/to/profile ; \
#  source /path/to/profile/etc/profile
#
# When GUIX_PROFILE is undefined, the various environment variables refer
# to this specific profile generation.

export 
PATH="${GUIX_PROFILE:-/gnu/store/gvfl5wxrgalxjjmyp7cwgfj48bdd34n4-profile}/bin:${GUIX_PROFILE:-/gnu/store/gvfl5wxrgalxjjmyp7cwgfj48bdd34n4-profile}/sbin${PATH:+:}$PATH"
export 
GST_PLUGIN_SYSTEM_PATH="${GUIX_PROFILE:-/gnu/store/gvfl5wxrgalxjjmyp7cwgfj48bdd34n4-profile}/lib/gstreamer-1.0${GST_PLUGIN_SYSTEM_PATH:+:}$GST_PLUGIN_SYSTEM_PATH"
export 
XDG_DATA_DIRS="${GUIX_PROFILE:-/gnu/store/gvfl5wxrgalxjjmyp7cwgfj48bdd34n4-profile}/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"
export 
GIO_EXTRA_MODULES="${GUIX_PROFILE:-/gnu/store/gvfl5wxrgalxjjmyp7cwgfj48bdd34n4-profile}/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES"
--8<---cut here---end--->8---

AFAIU it conforms to the suggested way to setup a working user profile:
right?

The problem here is I'm getting this env when I login and open a
terminal emulator:

--8<---cut here---start->8---
~ $ env | grep -i guix
GIO_EXTRA_MODULES=/home/giovanni/.guix-profile/lib/gio/modules
GST_PLUGIN_SYSTEM_PATH=/home/giovanni/.guix-profile/lib/gstreamer-1.0
GUIX_LOCPATH=/home/giovanni/.guix-profile/lib/locale
GUIX_PROFILE=/home/giovanni/.guix-profile
INFOPATH=/home/giovanni/.config/guix/current/share/info:
PATH=/home/giovanni/.guix-profile/bin:/home/giovanni/.guix-profile/sbin:/home/giovanni/.config/guix/current/bin:/usr/local/bin/Zotero_linux-x86_64:/home/giovanni/.local/bin:/home/giovanni/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/giovanni/bin:/home/giovanni/.local/bin:/home/giovanni/go/bin:/home/giovanni/bin:/home/giovanni/.local/bin
XDG_DATA_DIRS=/home/giovanni/.guix-profile/share
--8<---cut here---end--->8---

This causes some Debian installed GUI applications to chrash with a
GLib-GIO-ERROR like this (evince in this case, I also tried eom from
Mate and gnome-character-map):

--8<---cut here---start->8---
~ $ evince

(evince:26326): GLib-GIO-ERROR **: Settings schema 'org.gnome.Evince' is not 
installed

rilevato trace/breakpoint
--8<---cut here---end--->8---

At first I did not ralized it was an env problem, then looking at an
strace log it tunrs out that it reads gschema.compiled from my user Guix
profile and not from Debian standard folder [2]:

--8<---cut here---start->8---
openat(AT_FDCWD, 
"/home/giovanni/.guix-profile/share/glib-2.0/schemas/gschemas.compiled", 
O_RDONLY) = 12
--8<---cut here---end--->8---

[1] /usr/share/gnome:/usr/local/share/:/usr/share/ as documented here
https://www.debian.org/doc/manuals/debian-reference/ch09.en.html#_starting_a_program_from_gui

To fix this issue now I do (in a terminal emulator):

--8<---cut here---start->8---
unset XDG_DATA_DIRS
export 
XDG_DATA_DIRS="${GUIX_PROFILE:-/gnu/store/gvfl5wxrgalxjjmyp7cwgfj48bdd34n4-profile}/share:/usr/share/gnome:/usr/local/share/:/usr/share/"
--8<---cut 

Re: Zotero Packaging Request

[Ludovic Courtès]

Hello Raghav,

"Raghav Gururajan"  skribis:

> Can anyone package Zotero (https://www.zotero.org/) into Guix? It is a
> powerful reference management software that is being used in academia,
> literature and journalism. This packaging will be useful for many
> users. Kindly consider.

As you know Guix is driven by volunteers who choose to donate their time
to this collaborative effort and to work with one another.  I would
kindly invite you to join us, this is a great opportunity!

If you’re already using Guix, getting into the position of a packager
should not be too difficult.  Pierre wrote a tutorial that should help
you get started:

  https://gnu.org/s/guix/blog/2018/a-packaging-tutorial-for-guix/

along with the reference manual:

  https://gnu.org/s/guix/manual/en/html_node/Defining-Packages.html

People on IRC and on the help-guix mailing list will happily provide
guidance.

Ludo’.

Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.

[swedebugia]

Pierre Neidhardt  skrev: (27 mars 2019 12:46:26 CET)
>Ludovic Courtès  writes:
>
>> Apologies if I missed a previous discussion on this topic, but… I’m
>> skeptical about the renames.  I assume that the original names were
>> those commonly used in distributions, which in itself may be a good
>> reason to keep them.
>
>Names may vary a lot across distributions.  Especially when it comes to
>games, since they tend to have more exotic titles.
>
>If the majority of distributions decides on a poor name, we don't have
>to repeat the same mistake ;)
>
>> Those names are also used upstream in some cases: the tarball for
>> wesnoth is called “westnoth*.tar.gz”, for example, and the GitHub
>> project of L’Abbaye des morts is “abbayedesmorts” (no ‘l’).  Like our
>> naming guidelines say (info "(guix) Package Naming"), we should try
>to
>> stick to the upstream name.
>>
>> Thoughts?
>
>I think it's important to ask "why should we name a package this way."
>What's the rationale behind a package name?
>
>We are facing the users, not package maintainers.  Users are not
>supposed to know about:
>
>- domain names
>- tarball names
>- github names
>
>Those are details, in my understanding, reserved to developers and
>packagers.
>More often than not, those shortened names are used because of
>technical
>limitations (e.g. character length).  We don't have to forward those
>limitations on ourselves.
>
>I think it makes sense that we expose to the users names that speaks to
>them, i.e. the "official project full name".
>
>Finally, as I mentioned above with the completion systems that we have,
>we've got nothing to lose in having long names.
>
>My two cents :)
>
>-- 
>Pierre Neidhardt
>https://ambrevar.xyz/

I agree with Pierre. 

Good useability is important and cryptic acronyms are not something to expose 
to the user if possible to avoid IMO. 

Maybe this is where we need to discuss what our target audience is? Nerds only?
Random Joe who is new to GNU systems but dead tired of the proprietary systems 
he was taught in school who heard og Guix through a good friend who helps him 
getting started? 

Tangent to this is the focus on an  installer. Why bother with an installer if 
we only target nerds and educated computer professionals?

Anyone else who have opinions on the matter of acronyms in names where they can 
be avoided?

-- 
Sent from my k-9 mail for Android.

Re: Automated linting before master branch commit

[mikadoZero]

Danny Milosavljevic writes:

> Hi,
>
>> What do people think about automating package linting?  This would be to
>> make sure a package is linted before it is committed to the Guix
>> repository master branch?
>
> A linter by its nature will in some cases flag things which are not wrong,
> otherwise one could just check the stuff while compiling in the first place.
>
>> I am not familiar with what Guix uses for continuous integration /
>> deployment.
>
> We can manually make cuirass and/or Hydra evaluate custom branches--but it's
> not automated.
>
> Christopher Baines is working on making patch review better--see thread
> "Patchwork + automated checking and testing of patches".

Thanks for sharing that thread.

>> Estimated number of packages with autogenerated tarball:
>> 
>> 389
>
> Yeah, those should be updated.  With that many packages, writing a script
> to do it would be less annoying.

Interested in working on Guix for Google Summer of Code

[Daniel Jiang]

Hi,

I'm a student at the University of Illinois at Urbana-Champaign, a huge
emacs user, and have been curious about Guix/GuixSD for a while now. I
found it as a possible project on GSoC and thought it'd be interesting to
help work on if possible. The organization page on GSoC said to contact the
mentors and was directed to the mailing list from #guix@freenode. I also
recognize one of the mentors who wrote bindings to a game programming
library for Guile because I was writing some for Common Lisp at the time,
so small world lol. (I dunno if you're reading this or know I exist but
hello davexunit?)

Anyways, are there additional steps to take or things to know other than
submitting a GSoC proposal based on this?
https://www.gnu.org/software/soc-projects/guidelines.html

And what might be some ideas on the level for a undergrad with a bit of
experience?
https://libreplanet.org/wiki/Group:Guix/GSoC-2019#Guix_Deploy

Sincerely,
Daniel Jiang

Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.

[Pierre Neidhardt]

Ludovic Courtès  writes:

> Apologies if I missed a previous discussion on this topic, but… I’m
> skeptical about the renames.  I assume that the original names were
> those commonly used in distributions, which in itself may be a good
> reason to keep them.

Names may vary a lot across distributions.  Especially when it comes to
games, since they tend to have more exotic titles.

If the majority of distributions decides on a poor name, we don't have
to repeat the same mistake ;)

> Those names are also used upstream in some cases: the tarball for
> wesnoth is called “westnoth*.tar.gz”, for example, and the GitHub
> project of L’Abbaye des morts is “abbayedesmorts” (no ‘l’).  Like our
> naming guidelines say (info "(guix) Package Naming"), we should try to
> stick to the upstream name.
>
> Thoughts?

I think it's important to ask "why should we name a package this way."
What's the rationale behind a package name?

We are facing the users, not package maintainers.  Users are not
supposed to know about:

- domain names
- tarball names
- github names

Those are details, in my understanding, reserved to developers and
packagers.
More often than not, those shortened names are used because of technical
limitations (e.g. character length).  We don't have to forward those
limitations on ourselves.

I think it makes sense that we expose to the users names that speaks to
them, i.e. the "official project full name".

Finally, as I mentioned above with the completion systems that we have,
we've got nothing to lose in having long names.

My two cents :)

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


signature.asc
Description: PGP signature

Re: Updating mono. Adding MSBuild.

[Danny Milosavljevic]

Also, Microsoft released .net Core as Free Software (on github).
It might make sense to package that (either in addition or only).

(There's also DotGNU which could maybe be used to bootstrap either)


pgp9bSxJhren4.pgp
Description: OpenPGP digital signature

Re: Updating mono. Adding MSBuild.

[Danny Milosavljevic]

Hi,

> > Mono, for most distributions, seems to be bootstrapped with a prebuilt
> > binary mono-lite. Due to this, I am unsure of how to make the first step
> > in correctly repackaging Mono.  
> 
> Instead of adding a new binary mono-lite, can we reuse the existing
> “mono” package to build the new Mono?

+1

> (I don’t know what MSBuild is and how it would help here.)

MSBuild is something like Ant for .NET.  (or "make", but with more XML :) )

I think Brett means that MSBuild is bundled with mono.

I failed to unbundle some things just to have a CVE in one of the bundled
dependencies DAYS later.  I think it's not a good idea in general to bundle
things.  (But if it's from the same vendor and team anyway they'll probably
update their bundled copy after fixing CVEs, too)


pgpSXfnyKA0gJ.pgp
Description: OpenPGP digital signature

Re: Declarative containers

[Ludovic Courtès]

Hi,

Giovanni Biscuolo  skribis:

> Ludovic Courtès  writes:

[...]

>> We could have a ‘container’ (or ‘sub-system’?) service;
>
> mumble: `container` is so abused that it's starting to become a buzzword
> to my ears, `sub-system` is probably more semantic

The Hurd has had this thing called “sub-Hurd”, which is similar to what
we’re talking about.

>> you’d pass it an  and it’d create a Shepherd service
>> that runs that OS in a container.
>
> what is the method used to instantiate containers with Guix?

‘guix system container’ creates an executable that starts the container.
That executable is a Guile program that uses (gnu build
linux-container), a module that provides facilities to create processes
under separate name spaces, etc.

IOW all the functionality is provided by Guix; no systemd-nspawn,
bubblewrap, lxc, etc.

Ludo’.

Re: Audio/sound (ALSA) in guix environment --container

[Ludovic Courtès]

Hello,

Ricardo Wurmus  skribis:

> Would it make sense to map the current user’s UID into the container
> instead of using a fixed UID?

>From a reproducibility viewpoint, I’d find it nicer to use a fixed UID
(it can still be mapped to the user’s name anyway.)

We could make it configurable if necessary.  WDYT?

Ludo’.

Re: 06/15: gnu: wesnoth-server: Rename package to the-battle-for-wesnoth-server.

[Ludovic Courtès]

Hello,

Andreas Enge  skribis:

> On Tue, Mar 26, 2019 at 04:32:46PM +0100, Pierre Neidhardt wrote:
>> Sorry, I misunderstood the conclusion of the discussion: I thought that
>> we would simply follow the package naming convention as per the manual.
>
> I am confused about this statement. The naming convention speaks a bit
> vaguely of "project name chosen upstream"; very often, this means the
> tarball name. Now there is www.wesnoth.org, which distributes tarballs and
> executable files called wesnoth.*. So I would argue that the upstream
> name is "wesnoth" and would suggest to revert this change.

+1

I agree with Ricardo that prior discussion would have been necessary.  I
think it’s now clear that this case does not fall under the
“non-controversial” category that ‘HACKING’ mentions.

Thanks,
Ludo’.

Re: Audio/sound (ALSA) in guix environment --container

[Ricardo Wurmus]

Pierre Neidhardt  writes:

> Ricardo Wurmus  writes:
>
>> I suppose /etc/pam.d/ also needs to be in the container.
>
> Tried it, same error.
>
>>> What about defaulting to 1000?  It's rather common, so I guess that
>>> would be anonymous enough and "just work".
>>
>> Would it make sense to map the current user’s UID into the container
>> instead of using a fixed UID?
>
> We have a "--user" option, so we could use the current user's UID when
> --user is not specified, 1000 otherwise.
> Or better: add a --uid CLI option.

I can see confusion coming from the existence of both “--user” and
“--uid”.  Maybe “--user” could take an optional argument, with the
default being the current user.  Without “--user” we’d use UID 1000.

What do you think?

--
Ricardo

Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.

[Ludovic Courtès]

Hello,

guix-comm...@gnu.org skribis:

> commit 375cb94130b222535ad7c7e0fa0d212483407351
> Author: Pierre Neidhardt 
> Date:   Tue Mar 26 13:37:07 2019 +0100
>
> gnu: wesnoth: Rename package to the-battle-for-wesnoth.

> commit c91ed484d0b66d5639ba01f9ba301ff762d9170d
> Author: Pierre Neidhardt 
> Date:   Tue Mar 26 13:35:16 2019 +0100
>
> gnu: abbaye: Rename package to l-abbaye-des-morts.


Apologies if I missed a previous discussion on this topic, but… I’m
skeptical about the renames.  I assume that the original names were
those commonly used in distributions, which in itself may be a good
reason to keep them.

Those names are also used upstream in some cases: the tarball for
wesnoth is called “westnoth*.tar.gz”, for example, and the GitHub
project of L’Abbaye des morts is “abbayedesmorts” (no ‘l’).  Like our
naming guidelines say (info "(guix) Package Naming"), we should try to
stick to the upstream name.

Thoughts?

Ludo’.

Re: Audio/sound (ALSA) in guix environment --container

[Ricardo Wurmus]

Pierre Neidhardt  writes:

> I've just "guix pull"ed and I get the following:
>
> --8<---cut here---start->8---
>> guix environment --container --ad-hoc coreutils shadow 
> # id
> uid=0(ambrevar) gid=0(users) groups=0(users),65534(overflow)
> # groupadd audio
> groupadd: PAM: Critical error - immediate abort
> # useradd foo
> useradd: PAM: Critical error - immediate abort
> --8<---cut here---end--->8---
>
> Any idea where to go from here?

I suppose /etc/pam.d/ also needs to be in the container.

> Ricardo Wurmus  writes:
>
>> I agree.  Defaulting to UID 0 is not good.  (“conda” is an example of
>> one application that has very different behaviour when it thinks it is
>> running as root.)
>
> What about defaulting to 1000?  It's rather common, so I guess that
> would be anonymous enough and "just work".

Would it make sense to map the current user’s UID into the container
instead of using a fixed UID?

-- 
Ricardo

Re: Failure to build powerpc64le-linux glibc

[Efraim Flashner]

On Wed, Mar 27, 2019 at 07:01:22AM +0100, Tobias Platen wrote:
> Hello,
> 
> I have tried to cross compile the bootstrap binaries for ppc64le using
> 
> ./pre-inst-env guix build --target=powerpc64le-linux bootstrap-tarballs
> 
> but the build failed again, it seems that this is a known bug that
> affects other architectures.
> 
> https://lists.gnu.org/archive/html/bug-guix/2015-01/msg00014.html
> 
> Tobias

I feel like the linked bug report is inconclusive, since it was an
attempt to build from 32-bit -> 64-bit.

Also, I want to make sure you're trying on core-updates, and you should
use '--target=powerpc64le-linux-gnu' IIRC.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Updating mono. Adding MSBuild.

[Ricardo Wurmus]

Hi Brett,

thank you for looking into this.

> Our mono package is pretty severely out of date. I want to take care of
> updating it to a version consistent with this century. However, there
> seems to be an issue perhaps along the lines similar to bootstrapping
> Rust and JDK.
>
> Mono, for most distributions, seems to be bootstrapped with a prebuilt
> binary mono-lite. Due to this, I am unsure of how to make the first step
> in correctly repackaging Mono.

Instead of adding a new binary mono-lite, can we reuse the existing
“mono” package to build the new Mono?

(I don’t know what MSBuild is and how it would help here.)

-- 
Ricardo

Failure to build powerpc64le-linux glibc

[Tobias Platen]

Hello,

I have tried to cross compile the bootstrap binaries for ppc64le using

./pre-inst-env guix build --target=powerpc64le-linux bootstrap-tarballs

but the build failed again, it seems that this is a known bug that
affects other architectures.

https://lists.gnu.org/archive/html/bug-guix/2015-01/msg00014.html



Tobias

a - string/strcspn-power8.os
a - string/strcspn-ppc64.os
a - string/strlen-power8.os
a - string/strcasestr-power8.os
a - string/strcasestr-ppc64.os
a - string/strcasecmp-ppc64.os
a - string/strcasecmp-power8.os
a - string/strncase-ppc64.os
a - string/strncase-power8.os
a - wcsmbs/wcscat.os
a - wcsmbs/wcschr.os
a - wcsmbs/wcscmp.os
a - wcsmbs/wcscpy.os
a - wcsmbs/wcscspn.os
a - wcsmbs/wcsdup.os
a - wcsmbs/wcslen.os
a - wcsmbs/wcsncat.os
a - wcsmbs/wcsncmp.os
a - wcsmbs/wcsncpy.os
a - wcsmbs/wcspbrk.os
a - wcsmbs/wcsrchr.os
a - wcsmbs/wcsspn.os
a - wcsmbs/wcstok.os
a - wcsmbs/wcsstr.os
a - wcsmbs/wmemchr.os
a - wcsmbs/wmemcmp.os
a - wcsmbs/wmemcpy.os
a - wcsmbs/wmemmove.os
a - wcsmbs/wmemset.os
a - wcsmbs/wcpcpy.os
a - wcsmbs/wcpncpy.os
a - wcsmbs/wmempcpy.os
a - wcsmbs/btowc.os
a - wcsmbs/wctob.os
a - wcsmbs/mbsinit.os
a - wcsmbs/mbrlen.os
a - wcsmbs/mbrtowc.os
a - wcsmbs/wcrtomb.os
a - wcsmbs/mbsrtowcs.os
a - wcsmbs/wcsrtombs.os
a - wcsmbs/mbsnrtowcs.os
a - wcsmbs/wcsnrtombs.os
a - wcsmbs/wcsnlen.os
a - wcsmbs/wcschrnul.os
a - wcsmbs/wcstol.os
a - wcsmbs/wcstoul.os
a - wcsmbs/wcstoll.os
a - wcsmbs/wcstoull.os
a - wcsmbs/wcstod.os
a - wcsmbs/wcstold.os
a - wcsmbs/wcstof.os
a - wcsmbs/wcstol_l.os
a - wcsmbs/wcstoul_l.os
a - wcsmbs/wcstoll_l.os
a - wcsmbs/wcstoull_l.os
a - wcsmbs/wcstod_l.os
a - wcsmbs/wcstold_l.os
a - wcsmbs/wcstof_l.os
a - wcsmbs/wcstod_nan.os
a - wcsmbs/wcstold_nan.os
a - wcsmbs/wcstof_nan.os
a - wcsmbs/wcscoll.os
a - wcsmbs/wcsxfrm.os
a - wcsmbs/wcwidth.os
a - wcsmbs/wcswidth.os
a - wcsmbs/wcscoll_l.os
a - wcsmbs/wcsxfrm_l.os
a - wcsmbs/wcscasecmp.os
a - wcsmbs/wcsncase.os
a - wcsmbs/wcscasecmp_l.os
a - wcsmbs/wcsncase_l.os
a - wcsmbs/wcsmbsload.os
a - wcsmbs/mbsrtowcs_l.os
a - wcsmbs/isoc99_wscanf.os
a - wcsmbs/isoc99_vwscanf.os
a - wcsmbs/isoc99_fwscanf.os
a - wcsmbs/isoc99_vfwscanf.os
a - wcsmbs/isoc99_swscanf.os
a - wcsmbs/isoc99_vswscanf.os
a - wcsmbs/mbrtoc16.os
a - wcsmbs/c16rtomb.os
a - wcsmbs/wcstof128_l.os
a - wcsmbs/wcstof128.os
a - wcsmbs/wcstof128_nan.os
a - wcsmbs/wcschr-power7.os
a - wcsmbs/wcschr-power6.os
a - wcsmbs/wcschr-ppc64.os
a - wcsmbs/wcsrchr-power7.os
a - wcsmbs/wcsrchr-power6.os
a - wcsmbs/wcsrchr-ppc64.os
a - wcsmbs/wcscpy-power7.os
a - wcsmbs/wcscpy-power6.os
a - wcsmbs/wcscpy-ppc64.os
a - time/offtime.os
a - time/asctime.os
a - time/clock.os
a - time/ctime.os
a - time/ctime_r.os
a - time/difftime.os
a - time/gmtime.os
a - time/localtime.os
a - time/mktime.os
a - time/time.os
a - time/gettimeofday.os
a - time/settimeofday.os
a - time/adjtime.os
a - time/tzset.os
a - time/tzfile.os
a - time/getitimer.os
a - time/setitimer.os
a - time/stime.os
a - time/dysize.os
a - time/timegm.os
a - time/ftime.os
a - time/getdate.os
a - time/strptime.os
a - time/strptime_l.os
a - time/strftime.os
a - time/wcsftime.os
a - time/strftime_l.os
a - time/wcsftime_l.os
a - time/timespec_get.os
a - time/era.os
a - time/alt_digit.os
a - time/lc-time-cleanup.os
a - time/ntp_gettime.os
a - time/ntp_gettimex.os
a - dirent/opendir.os
a - dirent/closedir.os
a - dirent/readdir.os
a - dirent/readdir_r.os
a - dirent/rewinddir.os
a - dirent/seekdir.os
a - dirent/telldir.os
a - dirent/scandir.os
a - dirent/alphasort.os
a - dirent/versionsort.os
a - dirent/getdents.os
a - dirent/getdents64.os
a - dirent/dirfd.os
a - dirent/readdir64.os
a - dirent/readdir64_r.os
a - dirent/scandir64.os
a - dirent/alphasort64.os
a - dirent/versionsort64.os
a - dirent/fdopendir.os
a - dirent/scandirat.os
a - dirent/scandirat64.os
a - dirent/scandir-cancel.os
a - dirent/scandir-tail.os
a - dirent/scandir64-tail.os
a - dirent/getdirentries.os
a - dirent/getdirentries64.os
a - grp/fgetgrent.os
a - grp/initgroups.os
a - grp/setgroups.os
a - grp/getgrent.os
a - grp/getgrgid.os
a - grp/getgrnam.os
a - grp/putgrent.os
a - grp/getgrent_r.os
a - grp/getgrgid_r.os
a - grp/getgrnam_r.os
a - grp/fgetgrent_r.os
a - grp/grp-merge.os
a - pwd/fgetpwent.os
a - pwd/getpw.os
a - pwd/putpwent.os
a - pwd/getpwent.os
a - pwd/getpwnam.os
a - pwd/getpwuid.os
a - pwd/getpwent_r.os
a - pwd/getpwnam_r.os
a - pwd/getpwuid_r.os
a - pwd/fgetpwent_r.os
a - posix/uname.os
a - posix/times.os
a - posix/wait.os
a - posix/waitpid.os
a - posix/wait3.os
a - posix/wait4.os
a - posix/waitid.os
a - posix/alarm.os
a - posix/sleep.os
a - posix/pause.os
a - posix/nanosleep.os
a - posix/fork.os
a - posix/vfork.os
a - posix/_exit.os
a - posix/execve.os
a - posix/fexecve.os
a - posix/execv.os
a - posix/execle.os
a - posix/execl.os
a - posix/execvp.os
a - posix/execlp.os
a - posix/execvpe.os
a - posix/getpid.os
a - posix/getppid.os
a - posix/getuid.os
a - posix/geteuid.os
a - posix/getgid.os
a - posix/getegid.os
a - posix/getgroups.os
a -