Current state of cargo-build-system

[Ivan Petkov]

Hello Guix!

I'm new to both Guix and Guile/Scheme and decided to get my feet wet by
attempting to package a non-trivial Rust crate into Guix.

This seems like something others have tried before me with varying degrees of
success (I found this thread from a few years ago which doesn't seem to have
resolved in any way 
https://lists.gnu.org/archive/html/guix-devel/2017-01/msg00306.html 
).
I ran into a host of issues myself, but I was able to prototype some changes
which allowed me to make some progress. Happy to keep hacking on this, but
ultimately I need some insight/guidance on the proper ways to build this out in
Guix :)

But before I propose any new changes, I wanted to check, what is the current
state cargo/crates in Guix from a community perspective?

Are there any philosophical or technical blockers that preclude pulling in
packages from crates.io, or is it just a matter of chipping away at the problem?

--Ivan

Re: perl for arm-linux-gnueabihf

[Ludovic Courtès]

Hello,

Ricardo Wurmus  skribis:

>> *guix build --target=arm-linux-gnueabihf* *perl* fails with the following
>> output: https://pastebin.com/QF0xKAmR
>
> Here’s the output copied from pastebin:
>
> starting phase `remove-extra-references'

[...]

>1 (string-append "incpth='" #f "/include'\n")
> In ice-9/boot-9.scm:
>752:25  0 (dispatch-exception _ _ _)
>
> ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
> In procedure string-append: Wrong type (expecting string): #f
> builder for `/gnu/store/zj5xld149ibdyc4nlm2dj41jnjm9bqyn-perl-5.28.0.drv' 
> failed with exit code 1
> build of /gnu/store/zj5xld149ibdyc4nlm2dj41jnjm9bqyn-perl-5.28.0.drv failed
>
> I have never tried to cross-compiled packages for “arm-linux-gnueabihf”.
> I don’t know if this is expected to work.

The “arm-linux-gnueabihf” is a cross-compilation triplet that we
generally support.  However, note, Gérard, that not all packages in Guix
can be successfully cross-compiled, and Perl is one that fails to cross
build.  We are not committed to supporting cross-compilation of every
package, but we’re of course happy to make the feature more useful.

The patch below is the beginning of a fix, but as it is, it builds a
native Perl.  To address that, we need to fiddle with Perl’s peculiar
build system.  If you know how to instruct it to cross-build, let’s
address this!  :-)

Thanks,
Ludo’.

PS: This issue was previously reported at
 so I suggest we keep
discussing it there.

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index c4d9d64de3..109a4c1154 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017 Ludovic Courtès 
+;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2019 Ludovic Courtès 
 ;;; Copyright © 2013 Andreas Enge 
 ;;; Copyright © 2015, 2016, 2017, 2019 Ricardo Wurmus 
 ;;; Copyright © 2015, 2016, 2017 Eric Bavier 
@@ -78,7 +78,7 @@
"perl-reproducible-build-date.patch"
 (build-system gnu-build-system)
 (arguments
- '(#:tests? #f
+ `(#:tests? #f
#:configure-flags
(let ((out  (assoc-ref %outputs "out"))
  (libc (assoc-ref %build-inputs "libc")))
@@ -127,7 +127,10 @@
  (add-after 'install 'remove-extra-references
(lambda* (#:key inputs outputs #:allow-other-keys)
  (let* ((out (assoc-ref outputs "out"))
-(libc(assoc-ref inputs "libc"))
+(libc(assoc-ref inputs
+,(if (%current-target-system)
+ "cross-libc"
+ "libc")))
 (config1 (car (find-files (string-append out "/lib/perl5")
   "^Config_heavy\\.pl$")))
 (config2 (find-files (string-append out "/lib/perl5")

Re: [PATCH] gnu: Add glibc-locales variants for older versions of glibc.

[Ricardo Wurmus]

Hi Ludo,

>> * gnu/packages/base.scm (make-glibc-locales, make-glibc-utf8-locales): New
>> procedures.
>> (glibc-locales): Express in terms of make-glibc-locales.
>> (glibc-utf8-locales): Express in terms of make-glibc-utf8-locales.
>> (glibc-locales-2.27, glibc-utf8-locales-2.27): New variables.

[…]

> I don’t like the package name trick, but I don’t have a better solution.
> Perhaps we could have a special property to explicitly allow for several
> versions of this package in the same profile (say
> ‘allow-multiple-versions?’), but that’s a bit more work.

I also don’t like to work around this by changing the package names.  I
thought of allowing multiple versions via property, but it’s not clear
how it should behave.  I’d want to have only major versions appear as
non-conflicting and still prevent the installation of variants of the
same version.

The next question then is if the property should be a procedure that
takes the current and the potentially conflicting package as arguments
and decides whether they are conflicting, or if this should be handled
centrally when the property is present.

--
Ricardo

Re: FOSDEM 2019 - we need a VGA to HDMI converter! And live streaming

[Pjotr Prins]

FOSDEM from this year only supports HDMI.

For those of us on older laptops, can anyone bring a VGA -> HDMI
converter?  That would be very helpful.

Also it may be an idea to stream some of the GNU Guix days. These days
that can be done with phones. Anyone interested in helping out?

Pj.

Re: Trustworthiness of build farms (was Re: CDN performance)

[Jeremiah]

> > Do you know where one can obtain a copy of this report?  I did an
> > Internet search but couldn't find anything.

> me too

> Jeremiah: sorry if I insist (last time, promised!) but could you give us
> some more info about that report?

I am sorry for the delay, the Government shutdown really disabled access
for me in regards to the archives in which it was found.

As I am currently unable to link that resource, I'll do my best to
provide the key points:

It was a top secret report for the Department of Defense written in 1958
and declassified by the Clinton Administration.

1) Computers are being used to replace human thinking and as computers
are growing faster and faster in complexity; there is going to be a
point in the future where computers will be required to design
computers. References back to a 1952 paper about lithography (that I
couldn't find) and that it is likely that chips will replace single
piece logic and thus provide the ultimate place for hiding of malicous
functionality. 
2) It is possible to infect the software used in the designing of
Computers on elements common to all computers, which will alter the
circuits to provide weaknesses we can exploit and/or functionality to
leverage that the computer designer, builder and owner do not know
about.
3) If done on a large enough machine, there is room to include infectors
for tools such as assmblers, linkers, loaders and compilers on
functionality that can not be removed.
4) It then details how they could backdoor the Strela computer and how
it could be leveraged to compromise future Soviet computers to ensure a
permanent weapon against the Soviet Union.
5) Then it has a huge section of blacked out text
6) Then a section of possible future hooks depending on how software
evolves in the Soviet Union, thus allowing more pervasive hardware
compromises and eliminating the possibility of trustworthy computing
ever becoming possible on Soviet Computers.
7) Another big blacked out section.
8) Then the final section detailed a list of steps required for a
lithography plant to be assembled by an Intelligence Agency to prevent
their own infrastructure from being compromised by a similiar Soviet
attack; with an estimated spinup time of almost a Decade.

Examples included running traces close to the transistors to create a
radio induced functionality such as The intensional leaking of crypto
secrets upon recieving a very specific frequency.

Allowing magic numbers in a set of memory addresses or registers to
cause functionality to be engaged; such as disabling protections or
giving a process priviledges that would normally be restricted for
security reasons.

I'm sorry as I am likely missing alot of the details and attacks.
Once the Shutdown is done, I'll try again to find that paper for you.

-Jeremiah

Re: KVM kernel module permission denied on foreign distro

[Giovanni Biscuolo]

Hi Pierre,

Pierre Neidhardt  writes:

> If I'm not mistaken, this is because you need to add the builders to the 'kvm'
> group.

yes! this solved the "Could not access KVM kernel module: Permission
denied" I had with "guix system vm" (both as user and root):

  $ for i in `seq -w 1 10`; do sudo usermod -G guixbuild,kvm guixbuilder$i; done
  $ sudo systemctl restart guix-daemon.service # since my init system is systemd

the fact that builds are made by a dedicated daemon using dedicated
unprivileged users (guixbuilder${i}) in an isolated environment is
pretty new to me and sometimes I forget it :-S

> From the manual ((guix) 2.4.1 Build Environment Setup):
>
> --8<---cut here---start->8---
> To use ‘guix system vm’ and related commands,
> you may need to add the build users to the ‘kvm’ group so they can
> access ‘/dev/kvm’, using ‘-G guixbuild,kvm’ instead of ‘-G guixbuild’
> (*note Invoking guix system::).
> --8<---cut here---end--->8---

I read that but skipped that because lazy people like me use installers
:-), so I used the shell installer script mentioned in "(guix)Binary
Installation" and that does not add guixbuilder${i} users to the kvm
group in "sys_create_build_user()" shell function

moreover, "(guix)Invoking guix system" should mention this in the "`vm`"
section, in case users (like me) skipped or misunderstood that part of
"(guix)Build Environment Setup" for any reason

tomorrow I'm going to propose a couple of patches to address both of the
above mentioned issues

Thanks!
Giovanni

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature