bug#30756: GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking
Hello, Ludovic Courtès writes: > Hi, > > Reza Housseini skribis: > >> So what is the workaround for this bug when one wants to use gcc >= 6.0.0 >> with a cmake build system? > > Guix has been using GCC 7.x as its default compiler for some time, and > everything works well, CMake or not. However, we also switched to using > ‘CPATH’ instead of ‘C_INCLUDE_PATH’ to work around this bug. > > HTH! > > Ludo’. As has been mentioned by Giel van Schijndel earlier in this bug report, using CPATH causes warnings to be emitted for core libraries such as glibc since the headers found in CPATH are not (rightfully) treated as system headers (and thus not muted by GCC). That has bitten me here, where I was mislead to think there was a build issue with the latest Inkscape: https://gitlab.com/inkscape/inkscape/issues/807. Many packages will end up having to disable warnings to cope with this behavior. It'd be nice to find a correct solution, but it seems I can't even make the build system of Inkscape work after switching from CPATH to CPLUS_INCLUDE_PATH and stripping it from any glibc/gcc include directories (I don't get the "stdlib.h: No such file or directory." error anymore, but I now get: "/gnu/store/zw5f5g5aqlxam3imaylfla0i98nkridf-glibc-2.30/include/bits/errno.h:26:11: fatal error: linux/errno.h: No such file or directory" instead, which I don't understand). I also tried moving the glibc include directory to the end of CPLUS_INCLUDE_PATH and it would still wouldn't be happy. Hmmph! Maxim
bug#38086: RAID installation script with ‘mdadm’ no longer works
Ludo', Ludovic Courtès 写道： Continue creating array? D’oh, I hadn’t seen that message. I doubt it was there for you to see in Guix's output. Things not ending with a newline tend to get lost easily due to line-buffering. Probably not worth worrying about. “yes|” works like a charm, I went this that. ‘Beautiful’, T G-R signature.asc Description: PGP signature
bug#39177: The installer encountered unexpected problem. Please report to
Hi Sherab Just like an experience in a dream Everything I now enjoy Will become a mere recollection For what has past will not be seen again Sent from ProtonMail, encrypted email based in Switzerland. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, 19 January 2020 21:33, Ludovic Courtès wrote: > Hello, > > wisdomlight--- via help-g...@gnu.org skribis: > > > Attached is a photo of my screen. > > I am installing on MacBook Air 13” > > I had guix already installed but wanted a fresh install. > > I used exactly the same usb-image I used before. > > So it’s strange that this is happening. > > What file system type did you select for your partitions? I don't remember but I always choose ext4 for linux install. so i presume it was ext4 Also, what > kind of partitioning did you choose (guided, etc.)? guided whole disk without seprate home folder gpt It asked me to have at least one partition with the / mount and when I put it it just did not recognize the / I had problem afterwards when needed to recover the MacosX - the recovery did not recognize the disk. MacOS offers a Disk Utility so i fiddled around with somethings there and finally managed to make the disk seen and re installed MacOSX > > BTW, note that, for Guix System, doing a “fresh install” doesn’t buy you > much in the sense that ‘guix system reconfigure’ amounts to doing a > “fresh install”: the result is the same. Yeah - I got impatient!!! > > Thanks for your report! Pleasure > > Ludo’. Sherab
bug#39177: The installer encountered unexpected problem. Please report to
OK Folk here's another one for you[this is not complaining this is for you to see if there is a problem somewhere??]: I wanted to try Guix again. This time I wanted it on a Librem 13" [instead of Macbook Air][so i can enjoy the libre wifi] I wanted to have Guix installed next to my already installed Linux Mint. So I created usb live Guix os I booted into the usb Got to the bit when it asks about Partitioning method choose the Manual, created two partitions 1 50.00GB ext4/ 70.00GB Free space When i was about to continue Format disk? it said we are about to format your hard disk. All its data will be lost Do you wish to continue? I promptly clicked exit then the installation menu window appeared and i clicked Abort it took me to local language window where again i clicked exit so this cycle of going form one menu to another Locale language window -> click exit -> installation menu window -> click Abort -> Local language -> click exit -> locale language menu window->click exit -> abort ad infinitum so I did the only thing I could and that was switching the machine of form the power button. Now I want to boot back to my Linux Mint and the system is stuck it says Booting from Hard Disk... And nothing happens When I then boot again to the live usb stick with Guix on it - the previous partitioning is till there available as if nothing has happened. This sounds strange to me. And of course now I cannot boot to my machine. Not good. [not the end of the world as well because i have a back up and another live usb with linux mint on it and it boots fine] Sherab Just like an experience in a dream Everything I now enjoy Will become a mere recollection For what has past will not be seen again Sent from ProtonMail, encrypted email based in Switzerland. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, 19 January 2020 21:49, wrote: > Hi > > Sherab > > Just like an experience in a dream > Everything I now enjoy > Will become a mere recollection > For what has past will not be seen again > > Sent from ProtonMail, encrypted email based in Switzerland. > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Sunday, 19 January 2020 21:33, Ludovic Courtès l...@gnu.org wrote: > > > Hello, > > wisdomlight--- via help-g...@gnu.org skribis: > > > > > Attached is a photo of my screen. > > > I am installing on MacBook Air 13” > > > I had guix already installed but wanted a fresh install. > > > I used exactly the same usb-image I used before. > > > So it’s strange that this is happening. > > > > What file system type did you select for your partitions? > > I don't remember but I always choose ext4 for linux install. so i presume it > was ext4 > > Also, what > > > kind of partitioning did you choose (guided, etc.)? > > guided whole disk without seprate home folder > gpt > > It asked me to have at least one partition with the / mount and when I put it > it just did not recognize the / > > I had problem afterwards when needed to recover the MacosX - the recovery did > not recognize the disk. > MacOS offers a Disk Utility so i fiddled around with somethings there and > finally managed to make the disk seen and re installed MacOSX > > > BTW, note that, for Guix System, doing a “fresh install” doesn’t buy you > > much in the sense that ‘guix system reconfigure’ amounts to doing a > > “fresh install”: the result is the same. > > Yeah - I got impatient!!! > > > Thanks for your report! > > Pleasure > > > Ludo’. > > Sherab
bug#38086: RAID installation script with ‘mdadm’ no longer works
Hi Tobias!
Tobias Geerinckx-Rice skribis:
> It's just waiting for input:
>
> $ # dd & losetup magic, where loop0 is 20% larger than loop1
> $ sudo mdadm --create /dev/md0 --verbose --level=mirror
> --raid-devices=2 /dev/loop{0,1}
> mdadm: Note: this array has metadata at the start and
>may not be suitable as a boot device. If you plan to
>store '/boot' on this device please ensure that
>your boot-loader understands md/v1.x metadata, or use
>--metadata=0.90
> mdadm: size set to 101376K
> mdadm: largest drive (/dev/loop1) exceeds size (101376K) by more than
> 1%
> Continue creating array?
D’oh, I hadn’t seen that message.
> Adding --force does not avoid this.
>
> I recommend tweaking the partition table to make both members equal,
> but a ‘yes|’ also works if you're in a hurry ;-)
“yes|” works like a charm, I went this that.
Pushed in commit 3adf320e44e54017a67f219ce9667a379c393dad, thank you!
Ludo’.
bug#39194: help for non-root users to start using
Hi Matt,
Matt Wette skribis:
> This guix-1.0.1 on x86_64 Fedora 30.
>
> After installing as root, it's not clear from the manual how users
> should start.
> I found out "guix pull" is the right thing.
> Maybe add that to the manual? (Or add a "guix init" command.)
“guix pull” brings you an up-to-date Guix, which is a good thing, but
you don’t _have_ to run it to get started.
> Here is the error that I get w/o "guix pull":
>
> [mwette@localhost ~]$ guix install hello
> Backtrace:
> 8 (primitive-load "/usr/local/bin/guix")
> In guix/ui.scm:
> 1813:12 7 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
> 829:9 6 (catch _ _ # ?)
> 829:9 5 (catch _ _ # ?)
> In guix/scripts/package.scm:
> 948:10 4 (_)
> In guix/status.scm:
> 768:4 3 (call-with-status-report _ _)
> In guix/scripts/package.scm:
> 956:14 2 (_)
> In guix/build/syscalls.scm:
> 1127:14 1 (call-with-file-lock/no-wait _ # ?)
> In ice-9/boot-9.scm:
> 777:6 0 (throw "open-file" "~A: ~S" ("No such file or direc?" ?) ?)
>
> ice-9/boot-9.scm:777:6: In procedure throw:
> In procedure throw: Wrong type argument in position 1: open-file
I believe this is fixed by commit 7842ddcbc118cbc2799e22651732b7cdc06b93ee.
Here’s my understanding of what happened:
1. You’re running guix-daemon 1.0.1, which lacks the fix for
(aka. CVE-2019-18192).
2. As “mwette”, you ran ‘guix pull’ and obtained a new ‘guix’, which
you then used in ‘guix install hello’ above.
3. That new Guix contains the new profile locking mechanism that threw
the exception we see above. That exception is because it failed to
create the lock file (“No such file or directory”), and that in
turn is because /var/guix/profiles/per-user/mwette didn’t exist
yet.
/…/per-user/mwette didn’t exist because it was the first time you
ran ‘guix install’ as “mwette”, and because guix-daemon lacks the
fix mentioned above that would create upon first connection.
QED ■ :-)
Thanks for your report!
Ludo’.
bug#39195: guix pull switching between profiles/per-user and profiles/default
Hi, Jimmy Thrasibule skribis: > For example after unpacking the store, the first ``guix pull`` will migrate > the profile to ``profiles/default``: What do you mean by “unpacking the store”? > The workaround is to link back the profile to ``per-user/root`` and delete > ``/var/guix/profiles/default/current-guix*``. After this action, any other > ``guix pull`` will run as expected. I believe /var/guix/profiles/default is used because neither $USER nor $LOGNAME were defined, right? This was fixed here: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c20ba18304ee63f01895f092bb51bc2a9ce3303b but it’s possible that you were running a version that lacks this fix. Also, there was a bug on Ubuntu where “sudo guix pull” would misbehave: https://issues.guix.gnu.org/issue/36785 Perhaps that’s also what happened here? Thanks, Ludo’.
bug#39177: The installer encountered unexpected problem. Please report to
Hello, wisdomlight--- via skribis: > Attached is a photo of my screen. > I am installing on MacBook Air 13” > I had guix already installed but wanted a fresh install. > I used exactly the same usb-image I used before. > > So it’s strange that this is happening. What file system type did you select for your partitions? Also, what kind of partitioning did you choose (guided, etc.)? BTW, note that, for Guix System, doing a “fresh install” doesn’t buy you much in the sense that ‘guix system reconfigure’ amounts to doing a “fresh install”: the result is the same. Thanks for your report! Ludo’.
bug#30756: GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking
Hi, Reza Housseini skribis: > So what is the workaround for this bug when one wants to use gcc >= 6.0.0 > with a cmake build system? Guix has been using GCC 7.x as its default compiler for some time, and everything works well, CMake or not. However, we also switched to using ‘CPATH’ instead of ‘C_INCLUDE_PATH’ to work around this bug. HTH! Ludo’.
bug#39151: Dry-run doesn't say everything
Hi, Julien Lepiller skribis: > On a recently installed system, I ran guix install coq -n. Guix told me it > would download 270 MB and do 4 hooks. Guix install coq however told me it > will 521 MB (which it did) including a lot more packages (including > coq:ide),the same 4 hooks with different store hashes and additional grafts. > This was quite unexpected :) > > Once coq is in the repo though, guix gc will remove coq:ide and dependencies, > and re-installing coq in a new profile will not pull coq:ide in anymore. Note > that coq was grafted. Yes, the difference is due to the current implementation of grafts (‘--dry-run’ implies ‘--no-grafts’). It’s unfortunate, but there’s no easy workaround, I think. Ludo’.
bug#39195: guix pull switching between profiles/per-user and profiles/default
After a fresh Guix install, when calling subsequent ``guix pull`` it will always try to migrate the profile at ``/root/.cong/guix/current`` between ``/var/guix/profiles/default`` and ``/var/guix/profiles/per-user/root``. The issue is that if there are any existing links in the target folder, ``guix pull`` will fail: guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/root/current-guix For example after unpacking the store, the first ``guix pull`` will migrate the profile to ``profiles/default``: # ls -l .config/guix/ total 0 lrwxrwxrwx1 root root45 Jan 19 18:33 current -> /var/guix/profiles/per-user/root/current-guix # guix pull Migrating profile generations to '/var/guix/profiles/default'... Updating channel 'guix' from Git repository at ' https://git.savannah.gnu.org/git/guix.git'... [...] Then calling ``guix pull`` again will fail: # ls -l .config/guix/ total 0 lrwxrwxrwx1 root root39 Jan 19 18:37 current -> /var/guix/profiles/default/current-guix # guix pull Migrating profile generations to '/var/guix/profiles/per-user/root'... guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/root/current-guix" The workaround is to link back the profile to ``per-user/root`` and delete ``/var/guix/profiles/default/current-guix*``. After this action, any other ``guix pull`` will run as expected.
bug#39194: help for non-root users to start using
This guix-1.0.1 on x86_64 Fedora 30.
After installing as root, it's not clear from the manual how users
should start.
I found out "guix pull" is the right thing.
Maybe add that to the manual? (Or add a "guix init" command.)
Here is the error that I get w/o "guix pull":
[mwette@localhost ~]$ guix install hello
Backtrace:
8 (primitive-load "/usr/local/bin/guix")
In guix/ui.scm:
1813:12 7 (run-guix-command _ . _)
In ice-9/boot-9.scm:
829:9 6 (catch _ _ # ?)
829:9 5 (catch _ _ # ?)
In guix/scripts/package.scm:
948:10 4 (_)
In guix/status.scm:
768:4 3 (call-with-status-report _ _)
In guix/scripts/package.scm:
956:14 2 (_)
In guix/build/syscalls.scm:
1127:14 1 (call-with-file-lock/no-wait _ # ?)
In ice-9/boot-9.scm:
777:6 0 (throw "open-file" "~A: ~S" ("No such file or direc?" ?) ?)
ice-9/boot-9.scm:777:6: In procedure throw:
In procedure throw: Wrong type argument in position 1: open-file
bug#38887: sassc has a memory leak
Jesse, Thanks for the report! Jesse Gibbons 写道： When I try to build arc-theme and leave it to run, the entire system eventually freezes. When I monitor how much memory it takes, I see that it spawns a sassc process that eventually takes all 30 GB of the RAM not taken by GNOME and the other services. When I sent the initial bug report, I found an upstream github issue that this could be related to, but I lost it. Probably this[0]. There's no fix yet. I've pushed bed24ecfcd68ca6fbc21f02b477c3b4c0450 which reverts back to libsass@3.5 for arc-theme, and am closing this bug. Please let me know if you still have trouble building it. Kind regards, T G-R [0]: https://github.com/sass/libsass/issues/3033 signature.asc Description: PGP signature
bug#39177: The installer encountered unexpected problem. Please report to
On 18.01.20 16:19, wisdomlight--- via Bug reports for GNU Guix wrote: > Attached is a photo of my screen. Hi! your backtrace is missing the last part. Can you scroll down and post the remaining part? Cheers, Moritz
