It looks like I was wrong on the ls example,
more importantly, it seems we all agree that short options with optional
arguments are messy, at best.
I think the best course of action is to take a look at the guix command line
design and find a way to move away from depending on them. Maybe some
Dear,
Digging in the bug tracker, I found this bug [1] about ESS saying that
it does not behave like all other Emacs packages; installing in
'$out/share/emacs/site-lisp/ess' instead of "guix.d".
Well, all other packages do install in '$out/share/emacs/site-lisp/'
as the manual says [2]. Because
Hi Ricardo,
This bug [1] is fixed by commit 5a14e81e413.
If it really is, feel free to close.
Cheers,
simon
[1] http://issues.guix.gnu.org/issue/25632
Dear,
Because this bug is more than 3 years old, tagged moreinfo and without
any answer by the submitter since 12 weeks, I am closing.
Best regards,
simon
Summary:
The instructions to build a virtual machine uses /dev/sda* devices for
harddrive which are then referenced in /etc/config.scm.
The instructions to run the vm uses /dev/vda* devices for harddrive
This causes "sudo guix system reconfigure /etc/config.scm" to fail with...
guix system: e
Dear David,
The bug report [1] opened more than 4 years ago about the Chicken
bootstrapping is still pending.
I am not sure to understand these lines; quoting you [1]:
<<
Generated from optimizer.scm by the CHICKEN compiler
This is *not* source code, it's a binary disguised as C source code
Dear,
This bug [1] is more than 4 years old. Does this bug report still make sense?
If yes, could you provide more information? (Guix commit)
If no, could we close it?
Best regards,
simon
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22158
After troubleshooting with lfam, rekado, cbaines in #guix the problem was found
to be caused by lack of ram during "guix pull".
With 1GB of ram for VM "guix pull" fails at different locations.
With 2GB of ram "guix pull" finishes. Low point of available system memory (per
'free -s') during pu
After troubleshooting with lfam, rekado, cbaines in #guix the problem was found
to be caused by lack of ram during "guix pull".
With 1GB of ram for VM "guix pull" fails at different locations.
With 2GB of ram "guix pull" finishes. Low point of available system memory (per
'free -s') during pul
Dear Josh,
On Tue, 5 May 2020 at 16:20, Josh Holland wrote:
> Ah, that's good. I'll just wait for the (hopefully soon) core-updates
> merge since this isn't essential to me. If it is fixed, then presumably
> this bug can be closed?
Could you confirm that the bug is now fixed for you?
If yes,
On Tue, 12 May 2020 at 22:19, Tom Zander wrote:
> They are expected to always be equivalent. It would not be logical to have the
> short one as an alias if they are not equivalent.
I agree.
Note that you cannot have short-name with optional argument or you
have to break a rule; see below.
> >
merge 39755 41211
thanks
Thanks for the report. I tried updating texlive-lualatex-otfload a
while back, but gave up because the new versions needs "l3build" which I
have zero experience with. Any pointers for packaging and using l3build
appreciated.
For reference, as the original home page has
On dinsdag 12 mei 2020 20:08:32 CEST zimoun wrote:
> > The design of the short options is that it is an alias. Identical to the
> > software regardless of what the user typed.
>
> Yes. But AFAIU, it is hard -- not impossible -- to detect what is an
> argument or what is another option in the case
(bootloader grub-bootloader)
(target "/dev/sda")
(keyboard-layout keyboard-layout)))
(swap-devices (list "/dev/sda2"))
(file-systems
(cons* (file-system
(mount-point "/")
(device
(uuid "dcb203af-8c28-473b-b101-8553950c56fe"
'ext4))
(type &
I see a memory leak in Gnome Shell 3.32.2
The following is top output after several days of uptime:
PID USER PR NIVIRTRES %CPU %MEM ZEIT+ S BEFEHL
864 gdm 20 0 39,6g 1,1g
>From today’s Guix, where (default-guile) is 3.0, I can’t build 1.0.0:
--8<---cut here---start->8---
$ guix describe
Generacio 142 May 11 2020 00:51:39(nuna)
guix b76b1d3
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
429c8284d232c3f9fbe3dc87a3da323f3a864c03 did preliminary work for ffmpeg
white listing. So we need to add the WebGL required stuff as well to
that whitelist. I'll see what I can do.
Dear,
I am not able to reproduce.
--8<---cut here---start->8---
# first to populate the store
guix time-machine --commit=91be384 \
-- build python-parso
# second to really build it
guix time-machine --commit=91be384 \
-- build python-parso --no-graft
Dear Tom,
On Tue, 12 May 2020 at 18:23, Tom Zander wrote:
> The other is the ordering of arguments being parsed unpredictable.
> The usecase given was the `-d 1 -S 2` arguments (see earlier emails for
> details).
Fix for that coming soon. :-)
Thank you for the report.
> > Please could you i
On dinsdag 12 mei 2020 15:03:14 CEST zimoun wrote:
> If yes, I can come up with a patch.
I think that would be much improved, yes.
--
Tom Zander
On dinsdag 12 mei 2020 13:35:04 CEST zimoun wrote:
> On Tue, 12 May 2020 at 11:55, Tom Zander via Bug reports for GNU Guix
>
> wrote:
> > the bugreport is a usability bug which stems from the fact that the
> > command
> > line parser behaves differently from every single other commandline parser
boost-for-mysql fails to build on current master with following error.
```
starting phase `configure'
Backtrace:
10 (primitive-load "/gnu/store/bsfksp6c63zj3ynx46ck87sip7a…")
In ice-9/eval.scm:
191:35 9 (_ _)
In guix/build/gnu-build-system.scm:
838:2 8 (gnu-build #:source _ #:ou
Hi, after a few months, I still have this problem, though the symptoms
changed somewhat. Now, if I click on either the Help >> wxMaxima help
menu, or the Help >> Maxima help menu, wxMaxima simply terminates, and
the word "Aborted" is dumped to stderr.
--
Christopher Howard
Enterprise Solutions Ma
my guix describe:
Generation 3May 12 2020 09:03:13(current)
guix 91be384
repository URL: /opt/guix
branch: master
commit: 91be384d2ef87af58f814e10a4ce0d8717bea647
(I store the git repository in /opt/guix and pull the source code of upstream
https://github.com/guix-mirror/
--8<---cut here---start->8---
starting phase `configure'
Backtrace:
19 (primitive-load "/gnu/store/4f9lljysahpgjjlzw02dvnhajnk…")
In ice-9/eval.scm:
191:35 18 (_ _)
In guix/build/gnu-build-system.scm:
838:2 17 (gnu-build #:source _ #:outputs _ #:
gcc-cross-sans-libc-arm-none-eabi-4.9.4-1.227977 (an input to
axoloti-patcher) fails to build.
Just like with issue #41209 the headers for both GCC 5 and 7 are
included.
--8<---cut here---start->8---
…
make[2]: Leaving directory
'/tmp/guix-build-avr-gcc-5.5.0.
Dear Tom,
On Tue, 12 May 2020 at 11:55, Tom Zander via Bug reports for GNU Guix
wrote:
[...]
> C apps using libc, python apps using their parser, even C++ apps using the Qt
> commandline classes, all are generally compatible with regards to behavior.
>
> Only Guix is different.
Please could yo
avr-toolchain-5.5.0 fails to build. It seems to be mixing headers from
GCC 5 and GCC 7:
--8<---cut here---start->8---
In file included from
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:36:0,
from ../../gcc-5.5.0/l
On Tue, 12 May 2020 at 10:51, Ludovic Courtès wrote:
> Nothing new here, and everything is properly documented.
Using optional argument with short-option names is unusual, AFAIK.
And for sure, there is an ambiguity; as we are seeing here. :-)
However, the only mention of that is in the commentar
Hi again, :-)
On Tue, 12 May 2020 at 12:38, zimoun wrote:
> > We’ll need to check exactly what will behave differently. If the tests
> > don’t catch anything, I think we’re fine. Most likely, we’re talking
> > about corner cases like ‘-S x -d y’, which probably very few people
> > tried.
>
> O
elaexuo...@wilsonb.com writes:
> With the patch to texlive-amsfonts the above typesets just fine; however,
> metafont ends up generating cmmi10.657pk and cmr10.657pk font files. Is this
> expected? Typsetting it from the texlive installation of my foreign distro
> doesn't call out to metafont a
Hello,
The accountsservice service hasn't access to dbus' interfaces throwing
an error when they're needed.The problem, at least, appears with LightDM.
The error looks like:
WARNING: Error updating user /org/freedesktop/Accounts/User1000:
GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: No suc
On Tue, 12 May 2020 at 11:55, Tom Zander via Bug reports for GNU Guix
wrote:
> the bugreport is a usability bug which stems from the fact that the command
> line parser behaves differently from every single other commandline parser
> average people like me have ever used.
>
> A near 100% of the c
commands run
0.
pwd = ~/work/guix
1.
guix environment guix --pure --ad-hoc git emacs strace gnupg
2.
./bootstrap
3.
./configure
4.
make check
output:
wxie@guix ~/work/guix$ guix environment guix --pure --ad-hoc git emacs strace
gnupg
Folgende Ableitung wird erstellt:
/gnu/store/96sb2i83hqwnxam
Hi Ludo,
Sorry, I am not compliant and reorder your quotes to ease the
discussion -- from my point of view. :-)
On Tue, 12 May 2020 at 10:51, Ludovic Courtès wrote:
> However (srfi srfi-37) does it as we see it now. Fixing it would mean
> implementing a different option parser.
Yes or add a
On dinsdag 12 mei 2020 10:51:28 CEST Ludovic Courtès wrote:
> Nothing new here, and everything is properly documented.
The bugreport was not about a disconnect between documentation and the tool,
the bugreport is a usability bug which stems from the fact that the command
line parser behaves diff
Alternative URL: https://issues.guix.gnu.org/40993
Hey Leo,
> If we have a fix, can we make a new installer image? There are people on
> #guix having trouble getting online in the installer, and I think they
> are hitting this issue.
This bug has been fixed with ea6594e0. However, I left the ticket open
because I'm supposed to add some testing
Hi,
zimoun skribis:
>> --8<---cut here---start->8---> # OK
>> guix package --list-generations -p /path/to/profile
>> guix package --list-installed -p /path/to/profile
>>
>> # KO
>> guix package -l -p /path/to/profile
>> guix package -I -p /path/to/profile
Hey Ludo,
> So I’m very much tempted to instead require each hook to take ‘system’
> and ‘#:target’ arguments and pass them to ‘gexp->derivation’. It’ll
> break the API, in case someone out there has custom profile hooks
> (unlikely given that it’s not really documented), but I’d say that’s OK.
40 matches
Mail list logo
