Re: Subdirectories in GUIX_PACKAGE_PATH

[Alex Kost]

Ludovic Courtès (2017-07-03 23:53 +0200) wrote:

> Hi Alex,
>
> Alex Kost  skribis:
>
>> Ludovic Courtès (2017-06-30 11:35 +0200) wrote:
>
> [...]

>> I have a (probably not related) question though: in the past, package
>> 'location' contained an *absolute* file name for the packages from
>> GUIX_PACKAGE_PATH.  Now these locations are *relative* file names.  Is
>> this intended?
>>
>> If so, this is a problem for Emacs-Guix: you see, when you try to open a
>> package location (for example, by pressing an according button in *Guix
>> Package Info* buffer), it is expanded against 'guix-directory' variable.
>> So if you open "gnu/packages/guile.scm" location, it works, but now if
>> it is your location like "my-guix-packages/foo.scm", the wrong
>> (non-existent) file will be opened.  Previously it worked, because that
>> location was absolute, like "/home/me/my-guix-packages/foo.scm".
>
> I’ve noticed this but I didn’t think it was a regression.
>
> Basically Guile supports two “file name canonicalization” modes: one
> that returns a file name relative to %load-path, and one that returns an
> absolute file name.  By default, when loading modules, we’re in
> ‘relative’ mode; this is so that modules can be moved on disk and don’t
> record their initial location.

Thanks for the explanation!

> I think the last time this was changed was a year ago in
> 14d5ca2e2e57643b6b4acfb980b18b7474c27e7b.

-- 
Alex

Re: compiling guix is too slow?

[Alex Kost]

Alex Vong (2017-07-04 16:16 +0800) wrote:

[...]
> Is there an intermediate approch? Is is possible for Emacs to signal a
> warning when the required features are not found, but still continue
> loading the rest of the config?

If you wish to have a message in *Messages* buffer, you can do it like
this:

(unless (require 'foo nil t)
  (message "Error during loading 'foo'!!!"))

or like this:

(with-demoted-errors "%S" (require 'foo))

If you want to have a warning in a pop-up buffer, then:

(unless (require 'foo nil t)
  (display-warning 'oops "Error during loading 'foo'!!!"))

[...]
> Thanks for the suggestion! It turns out setting NIX_STATE_DIR to
> "/usr/local/var/guix/" and making "~/.config/guix/latest" pointing to
> "~/scm/guix/" completely resolves the problem. So now only a oneliner is
> required:
>
>   (require 'guix-autoloads '() t)

Actually, why do you need this line at all?  Such autoloads should be
loaded automatically.  Do you also require autoloads of other emacs
packages?  Do you use Emacs from Guix or from your operating system (not
GuixSD)?

> Do you think it is a bug that Emacs-Guix does not set
> `guix-state-directory' correctly?

I'm not sure what you mean.  It sets this variable to "/var/guix" by
default (or to NIX_STATE_DIR if you use it).  If you use Guix with a
non-standard state directory, how can Emacs-Guix define it?

BTW, don't you have problems using "/usr/local/var" as the state
directory?

If you use guix from a git checkout, I think it is a standard practice
to configure it with "--localstatedir=/var".  It is even mentioned in
the manual a couple of times:

  (info "(guix) Building from Git")
  (info "(guix) Requirements")

-- 
Alex

Re: Looking to contribute

[Danny Milosavljevic]

Here's an update :)

>> Installer:
>> - Currently, the installer invokes the parted executable for partitioning 
>> which is quite jarring (it looks very different).  It would be nice if it 
>> just used the parted library.

>>But there's no good guile-parted yet.  I've started hacking on one and it's 
>>starting to look OK but it's not done.  If you are interested in that I can 
>>upload it somewhere (github, gitlab etc).

>I would be happy to work on this.

guile-gcc-unit is 80% done now (it also works on the real parted headers by 
now).  See .  (I think I'll not use 
records after all and just keep the result as huge trees that you can (ice-9 
match) on).

What it allows you is to:
- invoke gcc (with a special option) on a tiny source file which only 
"#include"s stuff and then
- feed the output to guile-gcc-unit and then
- get out a Scheme list of all the C prototypes, records, enums etc that are 
available.

The next step would be to map the generated declaration tree (output of 
main.scm) to the wrapper forms I posted - to have actual callable parted 
procedures.

> - No mouse support yet.

Now the installer does have mouse support :)

Updated installer dev usage (branch "wip-installer-2" on 
):

$ ./pre-inst-env guix environment guix --fallback --pure --ad-hoc guile-ncurses 
kbd pciutils util-linux wireless-tools
[env]$ ./pre-inst-env guix system installer
... press Ctrl-z when you are fed up with it :)

Be careful that it doesn't nuke your system (it does ask before formatting or 
installing anything - so it's not that bad).

Also, don't run it as root...

> - We have ISO9660 CD support code so it would be quite easy to make it so 
> that the image file for the graphical installer (see link above) also worked 
> if you burned it to a CD.  See threads mentioning "grub-mkrescue" on the 
> mainling list.

95% done.  If would actually work if we came to a consensus about the volume 
label (it must be uppercase; see bug# 27520 in guix-patches).  Also, UUID boot 
support is still mostly missing - same as in the non-iso9660 case.

> Bootloader:
> - The bootloader support code doesn't support booting Windows systems etcetc.

Started to provide scaffolding on this - let's see what we decide about using 
 (see bug# 27529 in guix-patches).  I don't really have a use for 
it so I won't go much further than providing the scaffolding.

> - There's no u-boot installer yet.  (There's support for using existing 
> u-boot but it doesn't install the u-boot bootloader itself yet.  That's 
> because doing that safely is very difficult)

Depends on the parted bindings.

> Packages:
> - The GUI hooks for desktop files and mime types suck.  Usually, the desktop 
> file database is updated much too late (mostly by accident).  I've looked 
> into fixing it but it would entail rebuilding almost all the graphical 
> packages we have - and I think KDE would still not do it correctly.

宋文武 fixed it :)

Re: compiling guix is too slow?

[Alex Vong]

Alex Kost  writes:

> Alex Vong (2017-07-04 16:16 +0800) wrote:
>
> [...]
>> Is there an intermediate approch? Is is possible for Emacs to signal a
>> warning when the required features are not found, but still continue
>> loading the rest of the config?
>
> If you wish to have a message in *Messages* buffer, you can do it like
> this:
>
> (unless (require 'foo nil t)
>   (message "Error during loading 'foo'!!!"))
>
> or like this:
>
> (with-demoted-errors "%S" (require 'foo))
>
> If you want to have a warning in a pop-up buffer, then:
>
> (unless (require 'foo nil t)
>   (display-warning 'oops "Error during loading 'foo'!!!"))
>
OK.

> [...]
>> Thanks for the suggestion! It turns out setting NIX_STATE_DIR to
>> "/usr/local/var/guix/" and making "~/.config/guix/latest" pointing to
>> "~/scm/guix/" completely resolves the problem. So now only a oneliner is
>> required:
F>>
>>   (require 'guix-autoloads '() t)
>
> Actually, why do you need this line at all?  Such autoloads should be
> loaded automatically.  Do you also require autoloads of other emacs
> packages?  Do you use Emacs from Guix or from your operating system (not
> GuixSD)?
>
Indeed, even that line is not needed. I think that was needed when
Emacs-Guix was still part of Guix.

>> Do you think it is a bug that Emacs-Guix does not set
>> `guix-state-directory' correctly?
>
> I'm not sure what you mean.  It sets this variable to "/var/guix" by
> default (or to NIX_STATE_DIR if you use it).  If you use Guix with a
> non-standard state directory, how can Emacs-Guix define it?
>
> BTW, don't you have problems using "/usr/local/var" as the state
> directory?
>
It works on my laptop so far...

> If you use guix from a git checkout, I think it is a standard practice
> to configure it with "--localstatedir=/var".  It is even mentioned in
> the manual a couple of times:
>
>   (info "(guix) Building from Git")
>   (info "(guix) Requirements")

Hmm, I am unaware of this practice. I'll re-install Guix with
"--localstatedir=/var".

Indeed, the manual mentions that, "LOCALSTATEDIR is the state directory
specified via ‘--localstatedir’ at configure time, usually ‘/var’"
in:

  (info "(guix) The Store")


signature.asc
Description: PGP signature

Re: Graphical Installer - Call for Testing.

[Danny Milosavljevic]

Hi,

> * Left-clicking on buttons, entries, etc. had no effect.  I expected it
>   to be equivalent to pressing enter or space.

I've implemented this for most things now (except for the status bar at the 
bottom).

> * Left-clicking leaves the clicked square (i.e., row+column
>   intersection) highlighted, which is visually distracting.

Not sure what can be done about this.

> * The installer should either guide the user through a linear series of
>   steps, or explain at the beginning what the user should do.  I wasn't
>   sure what to do at first when I was dropped into the installer.  This
>   doesn't preclude a non-linear path through the installation phases,
>   but I do think a more guided path would be less confusing.

I agree - it was jarring for me as well.

> * The installer begins with nothing selected.  This contributed to my
>   initial confusion: what am I supposed to do?

I agree - providing reasonable defaults would be very good.  The "Install the 
system" page then should show a summary of it all before doing anything.
 
> * The installer should display a keymap, or a hotkey which displays help
>   info (like the help page in cfdisk, or top).

John added this now.

> * I think you made the first letter of some commands bold (like the "C"
>   in "Continue"), but I didn't notice it until I tried the installation
>   on a machine with a different monitor.  More contrast, or an
>   underlined character, might help call that out more.

Yeah, the HIG standard is underline.  Does underline work in curses on the 
Linux console?  Apparently it's always auto-mapped to color.

> * I'm not sure how, but I got stuck in a menu loop between "Partition
>   the disks" and "Choose mount point".  Hitting "Continue" and "Go Back"
>   in any order never took me to any other step, or back to the main
>   menu.  I worked around the issue by getting a shell and rebooting.

Yeah, I don't get the nonlinear structure either.

> * Partition the disks: when launching cfdisk, consider explaining that
>   we're going to launch cfdisk to do the actual partitioning, and the
>   user needs to quit cfdisk to come back and continue the installation.

I'm writing guile-parted bindings now :)

> * The interface was at times sluggish - there was a noticeable delay
>   (hundreds of milliseconds) between pressing e.g. the left-arrow key
>   and the next bottom-menu item being selected.

I don't see this when moving around on the page - but I do see it when 
activating items.  It would be better if the screen was cleared or a progress 
bar shown or something.

> * By default, this installer provides a lot of manual control over how
>   the disks are partitioned, what file systems will be installed, and
>   what their mount points will be.  Perhaps by default we should offer
>   one or more common configurations - e.g., one partition, containing an
>   ext4 file system, mounted at / - and move the finer-grained manual
>   controls into a sub-menu of some kind.  For comparison, I've just
>   installed Ubuntu and Debian today, and both of their installers offer
>   such simplified paths for installation. - useful if someone does not
>   know much about that stuff yet or they just want an easy default.

There should be defaults - especially when the selected disk is empty, it 
should just default to a reasonable setup.

> * Following that note, if we presented pre-set combinations of
>   partitions/file systems/mount points, I can imagine adding another
>   "simple configuration" to that list, 

>for encrypted home partition, or

Yes please.

>   an entire encrypted disk.  

Yes please.  I do consulting in strange environments often - so basically if 
the system can't encrypt, I can't use it.

> * The installer contains various input text boxes (e.g., for file system
>   label).  These boxes are invisible; a border would help call them out
>   (I almost didn't realize they existed).  

John fixed that (they have an opaque background now).

>Also, left/right arrow keys
>   did not scroll left/right, which surprised me, but backspace and
>   delete worked well enough.

Yeah.  There's (ncurses form) which should automatically support all that stuff 
- but the installer doesn't use it.  Why?  Is (gurses form) more flexible?

> * The generated operating system configuration should use file system
>   UUID or label, if possible, rather than device path.

I didn't get that far yet.  Is that still the case?

> * Choose mount point: since you can also set the label here, maybe
>   change the title of the section to "Choose file system and mount
>   point" or something?

In the long run, I think this all should be "disk setup" and encompass 
partitioning, lvm, encryption, file system creation and mount point setup.

> * The installer takes a "window within a window" approach for
>   installation phases.  This conflicts with the "replace the whole
>   window" behavior that occurs when running cfdisk.  

Writing the parted bindings... :)

>I th

Re: FW: [oss-security] accepting new members to (linux-)distros lists

[Mark H Weaver]

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

> Leo Famulari  skribis:
>
>> I've seen some members of Guix express doubts about the utility of
>> private discussion forums like linux-distros, and I'm sympathetic.
>>
>> In fact, even without early notification, we are usually shipping
>> security updates for embargoed issues within 24 hours of public
>> disclosure, and usually within a few hours. And for non-embargoed
>> issues, we are shipping fixes earlier than the major distros very often.
>> I read the "security update round-ups" on LWN, and typically they are
>> full of bugs we already fixed. So, perhaps it wouldn't make a big
>> difference in most cases.
>>
>> But, the "Stack Clash" issues took us by surprise and we spent a few
>> days writing and testing our fixes. We are committed to supporting
>> 32-bit platforms where these bugs are apparently easy to exploit.
>> Without access to the exploits or detailed discussion, it was very
>> difficult to know if our fixes actually worked. So, we could have
>> responded more quickly and effectively with early notice.
>>
>> What do people think? Is anyone else interested in applying to join this
>> mailing list? Is anyone else willing to stick to the rules and to
>> participate?
>
> Like you say, you (and Mark and others) have been doing excellent work
> already without being on that list, but I agree that the early notice
> could help in some cases.  So overall I think being on linux-distros is
> a good idea, and it seems like we meet the criteria.
>
> The real question is about our commitment to contribute back.
> Presumably only one or two of us would be on that list, so they would
> largely have that responsibility individually, even if the rest of us
> could of course help out as far as the embargo etc. permits.
>
> Long story short, I would be super happy if you or Mark were on that
> list.
>
> How do you feel about it?

It might be that joining linux-distros is the right thing to do, but I
don't have the spare capacity to contribute back at this time.  Also, I
have mixed feelings about promising to keep security flaws a secret for
however long I'm asked to do so (which apparently exceeded the time
specified in the mailing list rules for Stack Clash).  I'm not yet
prepared to make such a promise.

   Mark

Re: Binding generator, for Guile, to C libraries

[Ludovic Courtès]

Hello,

Danny Milosavljevic  skribis:

> Okay, I've cleaned up what I have and put it on github, under:
>
> https://github.com/daym/guile-gcc-unit
>
> What this does is it allows you to read gcc output files which specify all 
> the prototypes - in our case in order to extract the prototypes and generate 
> Guile bindings (of parted, or whatever).
>
> The next steps:
> - Provide the actual binding generator (I started a version of it - I'll 
> commit a cleaned-up version in a few days I guess).
> - Get it to work with non-toy examples (see file "tests/huge/input" for the 
> parted non-toy example - the goal is to read this file, find all the record 
> decls and all the function decls in it and generate the Guile pendants of 
> them).  If you happen to know LALR parsing theory, I have a question :)
> - Find out whether that can be integrated as a Guile "language".  Just being 
> able to do something like ',load "foo.h"' and have it register all the 
> functions from it would be way cool.  On the other hand, on non-Guix systems 
> the header files aren't usually installed when the library is installed.  So 
> maybe an offline version would be good as well.

Matt Wette, the author of nyacc, was apparently in the process of
writing a similar tool using nyacc’s C99 parser.  Might be worth looking
at.

Besides and FWIW, I’m skeptical of binding generators.  Things like
SWIG, for instance, generate interfaces that are often not quite what
you’d like, so you end up writing a layer on top of the generated glue
anyway, not to mention annotation in headers.  (Bindings generated from
high-level descriptions like GIR and XCB are a different story; those
seem to work quite well.)

That said, you might want to share on guile-u...@gnu.org to get feedback!

Ludo’.

A question about 'guix build -f'

[Feng Shu]

I want to build emacs-exwm-x in my guix-git repo with the following command:

   guix build emacs-exwm-x -f /home/feng/project/guix/gnu/packages/emacs.scm

But it seem to do nothing, any suggestion?


by the way, pre-inst-env is not suit my need, I just want to hack a
small package -> rebase it to latest git commit -> test build and install -> 
format patch

The problem is that, when I git pull to get latest git commit, test
build and install need download and build many many package, this is
veeery sloow. so I need a way I can code in guix git repo
and use system guix to test build and install.
-- 

Re: 06/08: gnu: python-pyopenssl: Update to 17.1.0.

[Mark H Weaver]

Hi Marius,

mba...@fastmail.com (Marius Bakke) writes:
> mbakke pushed a commit to branch master
> in repository guix.
>
> commit 96bbc41f8be5e6bb8483f5ce596db47be271e9e8
> Author: Marius Bakke 
> Date:   Sat Jul 1 21:14:30 2017 +0200
>
> gnu: python-pyopenssl: Update to 17.1.0.

This new version fails to build on i686 and armhf:

  https://hydra.gnu.org/build/2166654 (i686)
  https://hydra.gnu.org/build/2166355 (armhf)

This causes quite a few dependency failures:

  https://hydra.gnu.org/eval/109708#tabs-now-fail

Would you be willing to investigate?

 Mark

Re: compiling guix is too slow?

[Chris Marusich]

"Feng Shu"  writes:

> Now I have found that 'guix pull' is too slow,
> I need 3 hours to compile guix, is it possible to speed it ?

3 hours is longer than it usually takes on my Lenovo X200 laptop with 2
cores, an SSD, and 8 GB of RAM.  Usually, for me, it seems to take about
15 minutes.

I once tried to speed up 'guix pull' by offloading to another machine
with comparable specs.  Although I did manage to set up offloading
successfully, the result was that 'guix pull' with offloading was many
times slower than 'guix pull' without offloading.  In fact, it was so
slow, I gave up before it completed.  Instead, I just ran 'guix pull'
without offloading.

-- 
Chris


signature.asc
Description: PGP signature