Re: FOSDEM 2019 - stand
Björn Höfling ezt írta (időpont: 2018. szept. 9., V 1:13): > Hi Guix, > > FOSDEM also offers stands where you can present your project and get > directly in contact with interested people. What do you think? Should > we get one? > > Details can be found here: > > https://fosdem.org/2019/news/2018-08-10-call-for-participation/ > > * Application deadline: 2018-11-02, so there is a bit more time left. > * There are no costs. > * We get a 180x80cm table, two chairs. > * Power socket available. > * WiFi as usual available. > * We commit us to have at least 2 people at the stand during whole > FOSDEM. > > I personally like to walk to the stands and get directly in touch with > the people you heard in a talk (or you missed). Do we want this? Do we > find enough people-power to do it? > > I would suggest at least three timeslots for each day, so we would have > 12 slots in total. Who will spend his time at the stand? Of cause, I'm > volunteering for a slot or two and can organize things. > I'm volunteering for a slot, if we do this. > > Ideas to present: > > * A poster of a easy and a complex dependency graph. > * A poster of a nice system declaration. > * Notebook with GuixSD installed, many generations. Show how you can > install/remove packages, switch generations, etc. People can try out > things on their own. > * Can we show some ARM hardware or fancy boards with Guix running on > them? > * Replicant phone with Guix running? > * Stickers > * We should have T-Shirts for us. > > > The stands are usually very demanded. We have better chances if we > share the table with some other project. Should we do that? And if, > with which project? > > * Can we get some reproducible-builds/bootstrappable corporation? > Debian? > * Nix? > * Guile? > > Here is the list from the last two years: > > https://archive.fosdem.org/2018/stands/ > https://archive.fosdem.org/2017/stands/ > > Björn > >
Re: OpenBLAS and INTERFACE64=1
On Sun, Sep 09, 2018 at 05:25:13PM -0500, Eric Brown wrote: > I then set about to ensure that dependents also compiled without issue, > and in fact all do (at least, no *new* failures) except for python-numpy > and python-scipy, which Segmentation Fault on at least one test when > linked with an OpenBLAS defined with 64-bit integers. The problem is that applications have to allow for the 64-bit interface and many have not been designed for that. I still want to convert GEMMA and it is a pain. Trust C/C++ and the mess around short, ints and implicit casting. > Of course, it would be nice if each package can build, and also be > possible for Fortran routines to handle large arrays. > > A few thoughts come to mind, perhaps in combination: > > * add a variant to the current openblas package > * add compiler flags such as -fdefault-integer-8 to gfortran > > * create a new package, e.g. openblas64, perhaps with a suffix to the > library name which distinguishes a 64-bit version from a 32-bit > version Yup. That is the way forward. Convert packages one by one and see if things break. I would not trust numpy/scipy at this point to handle 64-bit correctly unless they explicitly converted. Pj.
Re: Outreachy December round
Ricardo Wurmus ezt írta (időpont: 2018. szept. 8., Szo 9:58): > > Ludovic Courtès writes: > > > Ricardo Wurmus skribis: > > > >> The Outreachy organizers have approved GNU Guix to participate in the > >> current round of Outreachy! > > > > Excellent! > > > > Now to think about project proposals… > > The application opening day has been shifted from Monday to Wednesday, > September 12. That’s in four days. > > If you would like to be a co-mentor or you have a good idea for an > internship project, please let us know as soon as you can, so that we > can prepare a proper proposal and submit it in time. > It seem right now that I will have enough time to be a mentor in this round. What about the project we tried last round? Is it valid to resubmit that? (I am not aware of the rules, but I still think that it is relevant). > > So far no project ideas have been submitted nor has anyone come forward > to volunteer as a mentor. > > -- > Ricardo > > >
Removing configure flags?
Hello everyone, There is this shell scripting test framework called Roundup which I would like to package for Guix: https://github.com/bmizerany/roundup http://bmizerany.github.io/roundup/ It looks like the author has written his own configure script rather than using autotools to generate it, and it chokes on the default configure flags provided by Guix: https://github.com/bmizerany/roundup/blob/master/configure The culprits are the `--enable-fast-install` flag and the `--build` option. There is no need for either of those since it's all just shell scripts anyway, so is there a way to remove them? I know I can add flags, but I haven't found anything in the manual about removing some of the default flags.
Re: Heads-up: New dependency on Guile-Gcrypt
Guix does not expose Guile load paths in etc/profile nor --search-paths. This makes it a bit trickier to solve ** ERROR: In procedure scm-error: no code for module (gcrypt hash) Guix is built with Guile and Guile has trouble finding the gcrypt package. One fix is to install guix in a profile and setting the LOAD PATHS, e.g.: : guix package -i guix -p ~/opt/guix : GUILE_LOAD_PATH=~/opt/guix/share/guile/site/2.2/ : GUILE_LOAD_COMPILED_PATH=~/opt/guix/share/guile/site/2.2/ On Thu, Sep 06, 2018 at 11:08:24PM +0200, Ludovic Courtès wrote: > Hi Paul, > > Paul Garlick skribis: > > > I tried a 'guix pull' as root and this time it completes. However, > > there were warnings generated: > > Could you paste complete commands and outputs? That would help > determine the context of the warning/error messages you mention. > > > Now all the guix commands I have tried generate: > > > > ERROR: In procedure scm-error: > > no code for module (gcrypt hash) > > Since you’re upgrading from a very old checkout, note that you’re also > switching to the new “guix pull”, which populates > ~/.config/guix/current. > > To be sure you’re using the just-pulled ‘guix’ command, could you run: > > export PATH="$HOME/.config/guix/current/bin:$PATH" > hash guix > guix --version > > ? What’s the output of this? > > Thanks in advance, > Ludo’. >
Re: Removing configure flags?
Hi,
you can replace the entire "configure" phase.
Search for "replace 'configure" in gnu/packages/*.scm .
You can find the entire block when you search for "--enable-fast-install"
comments in gnu/packages/*.scm .
It is:
(arguments
`(#:phases
(modify-phases %standard-phases
(replace 'configure
(lambda* (#:key inputs outputs (configure-flags '())
#:allow-other-keys)
(apply invoke
`("./configure"
,(string-append "--prefix=" out)
,(string-append "--sysconfdir=/etc")
,@configure-flags))
pgpxqjrfNwNLN.pgp
Description: OpenPGP digital signature
Re: Heads-up: New dependency on Guile-Gcrypt
Hi Pjotr, Thank you. > Guix is built with Guile and Guile has trouble finding the gcrypt > package. Having successfully upgraded my root and user Guix installations I now find that my development installation is unable to locate guile-gcrypt: $ ./pre-inst-env guix --version ERROR: In procedure scm-error: no code for module (gcrypt hash) If I use my root guix profile, in a simlar way to your suggestion, it works: $ sudo GUILE_LOAD_PATH=/root/.guix-profile/share/guile/site/2.2 ./pre- inst-env guix --version guix (GNU Guix) 0.15.0.1558-b0632 Is there a best way to notify the ./pre-inst-env commands about guile- gcrypt? Using sudo seems like the wrong approach. Would installing guile-gcrypt as the development user suffice? Best regards, Paul.
Re: Outreachy December round
Hello Gábor, Gábor Boskovits skribis: > Ricardo Wurmus ezt írta (időpont: 2018. szept. 8., Szo [...] >> The application opening day has been shifted from Monday to Wednesday, >> September 12. That’s in four days. >> >> If you would like to be a co-mentor or you have a good idea for an >> internship project, please let us know as soon as you can, so that we >> can prepare a proper proposal and submit it in time. >> > It seem right now that I will have enough time to be a mentor in this > round. Great! > What about the project we tried last round? Is it valid to resubmit > that? (I am not aware of the rules, but I still think that it is > relevant). I would say no, mostly because I’m hoping we can get it done before the internship starts (for 1.0). Yesterday on IRC we discussed other possible projects: a PackageKit backend (but PackageKit is biased towards “traditional” package managers), a GNOME Software backend, and probably others I forgot. We ruled out the Cuirass web UI on the grounds that we need progress on that front before the internship. Thanks, Ludo’.
Re: Bringing the Neovim package up to date
Hello! HiPhish skribis: > Currently Neovim on Guix is at version 0.2.0, but the most recent release is > 0.3.1; I want to update the package. I would be grateful is someone could > assist me with guidance on this endeavour. Sure! While you’re trying things out, you may find that IRC will be better suited to get guidance and information on how to debug issues. > The first thing I noticed is that the dependencies are wrong. It specifies > Lua > 5.2 as an input, and the corresponding Lua 5.2 libraries like lpeg. However, > Neovim requires Lua 5.1, and Lua minor releases are not backwards-compatible. > So this needs to be fixed, which also means that we need to define new > packages. > > For lua5.1-lpeg and lua5.1-bitop this should be simple enough, just call the > function that generates the package with lua-5.1 as the Lua version. The > definition of lua5.1-libmpack would be a bit more involved, but still > straight-forward. > > Another thing is that Neovim can be built both with Lua 5.1, or LuaJIT. Using > LuaJIT would be preferable, is there a way to define the above libraries with > lua-5.1 as input, but then swap it out for luajit in the definition of Neovim? Yes. In short you would define the new package to “inherit” from ‘lua-5.1’, and you would change its ‘inputs’ field. There are examples of that in the code. Let us know if anything’s unclear! > On an unrelated note, the coding style always imports everything from a > module. This makes it really hard for someone unfamiliar with Guix to know > where the various procedures, variables and macros come from. Is there a > reason you don't explicitly import identifiers with `#:select`? In my own > code > I always prefer that style because in a month I will have no idea where any > of > that stuff comes from. We cannot #:select from (gnu packages …) modules due to the way Guile handles circular dependencies among modules. However we could use select more frequently for other modules. I don’t know if there’s anything similar for (Neo)Vim, but those of us who use Emacs also use Geiser, which displays in the “mode line” at the bottom the module that provides a given variable. Thanks, Ludo’.
Re: ARMHF flash image - Put on website under GuixSD
Hi Danny, Danny Milosavljevic skribis: > finally, https://hydra.gnu.org/build/3044681 (flash-image armhf) built. > > Can we put it on the website at https://www.gnu.org/software/guix/download/ > inside the GuixSD part? > > I think it would be nice to have something ready-to-go for ARM systems as > well, > and this would be a good start. Apart from the bootloader, everything should > work as-is in there. And the user can either keep the original bootloader > on the board or flash a new one after booting GuixSD - either in qemu or > on a real machine. I agree that it would be nice, but to what extent is this image generic to all ARM boards? My understanding is that images are necessarily bound to a specific board. Other considerations include the fact that it’s yet another image to build when we make a release, but perhaps the solution is simply to improve our automation and build farm availability. Thanks, Ludo’.
Re: ARMHF flash image - Put on website under GuixSD
On Mon, Sep 10, 2018 at 02:28:52PM +0200, Ludovic Courtès wrote: > I agree that it would be nice, but to what extent is this image generic > to all ARM boards? My understanding is that images are necessarily > bound to a specific board. > Many images, one for each board, is what people are accustomed to for other distros. Alternatively reconfiguring an existing system to GuixSD could be simplified. Regards, Florian
Re: ARMHF flash image - Put on website under GuixSD
Hi Ludo, On Mon, 10 Sep 2018 14:28:52 +0200 l...@gnu.org (Ludovic Courtès) wrote: > > Can we put it on the website at https://www.gnu.org/software/guix/download/ > > inside the GuixSD part? > > > > I think it would be nice to have something ready-to-go for ARM systems as > > well, > > and this would be a good start. Apart from the bootloader, everything > > should > > work as-is in there. And the user can either keep the original bootloader > > on the board or flash a new one after booting GuixSD - either in qemu or > > on a real machine. > > I agree that it would be nice, but to what extent is this image generic > to all ARM boards? My understanding is that images are necessarily > bound to a specific board. Yes, but only because of the bootloader (that's a pretty big "but"). It's possible to change it inside qemu, and in the end there has to be *some* way for a user to bootstrap the things (usually using the vendor image). ARM boards are very diverse - some load the bootloader and the root fs from SD card, some load the bootloader from flash and the root fs from SD card, some load everything from flash, some load the bootloader from flash and the root fs from NFS etc. In the end we can also provide one image per board, but we should use a block-deduplicating filesystem then - because everything but ~30 kB of each image will be the same! >Other considerations include the fact that it’s yet another image to >build when we make a release, but perhaps the solution is simply to >improve our automation and build farm availability. I think if we want to support it it has to be built at least once. Otherwise we don't know whether it has a chance to work, no? Having the flash-image isn't really much more work on top of that. pgpB4Z9eJvnBH.pgp Description: OpenPGP digital signature
Re: ARMHF flash image - Put on website under GuixSD
On 2018-09-10, Ludovic Courtès wrote: > Danny Milosavljevic skribis: > >> finally, https://hydra.gnu.org/build/3044681 (flash-image armhf) built. >> >> Can we put it on the website at https://www.gnu.org/software/guix/download/ >> inside the GuixSD part? >> >> I think it would be nice to have something ready-to-go for ARM systems as >> well, >> and this would be a good start. Apart from the bootloader, everything should >> work as-is in there. And the user can either keep the original bootloader >> on the board or flash a new one after booting GuixSD - either in qemu or >> on a real machine. > > I agree that it would be nice, but to what extent is this image generic > to all ARM boards? My understanding is that images are necessarily > bound to a specific board. An armhf image should generally be able to support most modern 32-bit arm boards, and an aarch64 image should be able to support most 64-bit boards. At least to the extent that they are supported in linux-libre. As Danny said, the bootloader is board-specific. This would either be present in firmware on the board itself, or need to be added to the image itself or other boot media manually. For systems that use a modern u-boot, this should work if the image includes the generated /boot/extlinux/extlinux.conf, and the initrd doesn't require any tweaks to the included modules. For EFI systems, it would probably require installing the appropriate grub-efi bits. For maximal compatibility, it would be best if both the relevent u-boot and EFI bits were installed; they don't necessarily conflict, and modern u-boot even has an EFI implementation (though may not work on many armhf systems). For comparison, the supported debian-installer images have a two-part image: https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/README.concatenateable_images Which contains the board-specific bootloader firmware and the common parts as two separate images. This has the obvious downside of requiring more work from the end-user to assemble the correct image with the advantage being that the common parts (which is the vast majority of the image) are shipped only once. I could see it making sense for guix to generate a common image, and then using that common image as an input to generate an image with the bootloader installed, but maybe the substitute servers wouldn't build the generated images by default? live well, vagrant signature.asc Description: PGP signature
Re: Outreachy December round
Ludovic Courtès ezt írta (időpont: 2018. szept. 10., H 14:22): > Hello Gábor, > > Gábor Boskovits skribis: > > > Ricardo Wurmus ezt írta (időpont: 2018. szept. 8., > Szo > > [...] > > >> The application opening day has been shifted from Monday to Wednesday, > >> September 12. That’s in four days. > >> > >> If you would like to be a co-mentor or you have a good idea for an > >> internship project, please let us know as soon as you can, so that we > >> can prepare a proper proposal and submit it in time. > >> > > It seem right now that I will have enough time to be a mentor in this > > round. > > Great! > > > What about the project we tried last round? Is it valid to resubmit > > that? (I am not aware of the rules, but I still think that it is > > relevant). > > I would say no, mostly because I’m hoping we can get it done before the > internship starts (for 1.0). > > Yesterday on IRC we discussed other possible projects: a PackageKit > backend (but PackageKit is biased towards “traditional” package > managers), a GNOME Software backend, and probably others I forgot. We > ruled out the Cuirass web UI on the grounds that we need progress on > that front before the internship. > > Thanks, > Ludo’ > Sorry for the confusion, I meant our last outreachy project aiming better output for guix package. I have also seen an iteresting proposal from Danny on network booting for the last GSoC round. I don't think I could mentor that one, but I would like to comentor if that proposal is still live. >
Re: FOSDEM 2019 - stand
On Mon, Sep 10, 2018 at 09:08:02AM +0200, Gábor Boskovits wrote: > Björn Höfling ezt írta (időpont: 2018. > szept. 9., V 1:13): > > I would suggest at least three timeslots for each day, so we would have > > 12 slots in total. Who will spend his time at the stand? Of cause, I'm > > volunteering for a slot or two and can organize things. > > > I'm volunteering for a slot, if we do this. Me too :) signature.asc Description: PGP signature
Re: FOSDEM 2019 - stand
Gábor Boskovits wrote: I'm volunteering for a slot, if we do this. Me too. Kind regards, T G-R
Re: FOSDEM 2019 - stand
I will probably attend FOSDEM again, and if I do, then I would like to spend a slot at the stall. On Sun, Sep 09, 2018 at 03:13:57PM +0200, Tonton wrote: > I have some stickers [1]; I might > get more of the same, but slightly bigger. I'll bring what I have - if I can. We should be able to sponsor stickers through Guix Europe. Andreas
Re: FOSDEM 2019 - stand
Andreas Enge skribis: > I will probably attend FOSDEM again, and if I do, then I would > like to spend a slot at the stall. +1! > On Sun, Sep 09, 2018 at 03:13:57PM +0200, Tonton wrote: >> I have some stickers [1]; I might >> get more of the same, but slightly bigger. I'll bring what I have - if I can. > > We should be able to sponsor stickers through Guix Europe. Yay! Chris Baines brought those really nice stickers at last year’s GHM, but those that Tonton posted look nice too. :-) Ludo’.
Re: Heads-up: New dependency on Guile-Gcrypt
Hello, Paul Garlick skribis: > Is there a best way to notify the ./pre-inst-env commands about guile- > gcrypt? Using sudo seems like the wrong approach. Would installing > guile-gcrypt as the development user suffice? ‘guix pull’ and ‘make as-derivation’ (which is really like ‘guix pull --url=$PWD’) take care of bootstrapping (modulo the bug that you reported, Paul, and that was fixed in 3ffcad7df3ab8947010814f61b32ce14ea80e780), so normally the tricks I posted should work: https://lists.gnu.org/archive/html/guix-devel/2018-09/msg00031.html Or am I missing something? Thanks, Ludo’.
Re: https://issues.guix.info
Ricardo Wurmus ezt írta (időpont: 2018. szept. 5., Sze, 10:56): > > Arun Isaac writes: > > >> I haven’t yet added a way to download attached patches (they are only > >> displayed inline). At the moment you can only download attachments that > >> cannot be displayed. I’ll try to find time to change this today. > > > > Sure, thanks! > > > >> I think that only GNU packages may use debbugs.gnu.org. Mumi is not a > >> GNU package (yet?). > > > > According to https://debbugs.gnu.org/Using.html , even "Savannah hosted > > non-GNU free software" can use debbugs. > > Oh, I suppose I should apply for having Mumi hosted on Savannah then. > Thanks for checking! > > -- > Ricardo > > Hello Ricardo, I'm now playing with this. It's really nice.
Re: ARMHF flash image - Put on website under GuixSD
Hello Vagrant, Vagrant Cascadian skribis: > An armhf image should generally be able to support most modern 32-bit > arm boards, and an aarch64 image should be able to support most 64-bit > boards. At least to the extent that they are supported in linux-libre. > > As Danny said, the bootloader is board-specific. This would either be > present in firmware on the board itself, or need to be added to the > image itself or other boot media manually. > > For systems that use a modern u-boot, this should work if the image > includes the generated /boot/extlinux/extlinux.conf, and the initrd > doesn't require any tweaks to the included modules. > > For EFI systems, it would probably require installing the appropriate > grub-efi bits. > > For maximal compatibility, it would be best if both the relevent u-boot > and EFI bits were installed; they don't necessarily conflict, and modern > u-boot even has an EFI implementation (though may not work on many armhf > systems). OK. > For comparison, the supported debian-installer images have a two-part > image: > > > https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/README.concatenateable_images > > Which contains the board-specific bootloader firmware and the common > parts as two separate images. Interesting. > This has the obvious downside of requiring more work from the end-user > to assemble the correct image with the advantage being that the common > parts (which is the vast majority of the image) are shipped only once. > > > I could see it making sense for guix to generate a common image, and > then using that common image as an input to generate an image with the > bootloader installed, but maybe the substitute servers wouldn't build > the generated images by default? We’d need to find how to generate these two parts of the image (maybe that’d require changes to ‘guix system’ & co.?). Then we can have continuous integration jobs for all the various parts, especially if the board-specific part is small. At any rate, this approach sounds more viable than uploading a dozen of nearly-identical 1GB images to ftp.gnu.org. :-) The way forward would be to find out what needs to be done in ‘guix system’ to generate these image parts, adjust the “release” target in Makefile.am, add some documentation under “System Installation” in the manual, and possibly adjust the download page of the web site. It’s not a trivial change because of all these bits that need to be adjusted, but it’s doable. Who’d like to give it a go? Thanks for explaining! Ludo’.
Re: Outreachy December round
Hi Guix, I wrote earlier: > The Outreachy organizers have approved GNU Guix to participate in the > current round of Outreachy! […] > The application opening day has been shifted from Monday to Wednesday, > September 12. That’s in four days. The application round opening has again been delayed. Applications will open on September 19. The Outreachy organizers strongly recommend having projects ready be then, so that early applicants can see them. October 9 is the last day to submit a new project, and October 30 is the dealine for intern applications. To maximize our chances we should submit project proposals as soon as possible. -- Ricardo
Re: Removing configure flags?
Danny Milosavljevic writes:
> Hi,
>
> you can replace the entire "configure" phase.
>
> Search for "replace 'configure" in gnu/packages/*.scm .
>
> You can find the entire block when you search for "--enable-fast-install"
> comments in gnu/packages/*.scm .
>
You can look at 'zlib' in 'compression.scm' for example.
> It is:
>
> (arguments
>`(#:phases
>(modify-phases %standard-phases
> (replace 'configure
>(lambda* (#:key inputs outputs (configure-flags '())
> #:allow-other-keys)
> (apply invoke
> `("./configure"
> ,(string-append "--prefix=" out)
> ,(string-append "--sysconfdir=/etc")
> ,@configure-flags))
signature.asc
Description: PGP signature
