bug#32995: Executing pre-compiled binaries

[Brett Gilio]

Hi all, I am having an issue with trying to execute literally any
pre-compiled binary files. One example is Telegram. Here is what 
is

happening.

brettg@oryxpro ~$ cd Downloads/tsetup.1.4.0/Telegram/
brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ls
Telegram  Updater
brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ./Telegram 
bash: ./Telegram: No such file or directory

brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$

Any ideas?


--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/ | https://emacs.org

bug#32995: Executing pre-compiled binaries

[Brett Gilio]

Brett Gilio writes:

Hi all, I am having an issue with trying to execute literally 
any
pre-compiled binary files. One example is Telegram. Here is what 
is

happening.

brettg@oryxpro ~$ cd Downloads/tsetup.1.4.0/Telegram/
brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ls
Telegram  Updater
brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ./Telegram 
bash: ./Telegram:

No such file or directory
brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$

Any ideas?


Also, in the strings evaluation of the binary I am getting 
/lib64/ld-linux-x86-64.so.2

bug#33192: IcedTea & GH-Checkout DRV

[Brett Gilio]

Hi all, I think there might be a bug during the bootstrapping process of
IcedTea. Here is what the builder is throwing.

~ $ guix build icedtea
building /gnu/store/3niclf6ncz56718jaskhc01gbwga7w54-hg-checkout.drv...
abort: HTTP Error 500: Internal Server Error
Backtrace:
   3 (primitive-load "/gnu/store/fvax9w48rk3jbyjqzb86nwg1wxw?")
In ice-9/eval.scm:
   293:34  2 (_ #)
In guix/build/hg.scm:
 37:2  1 (hg-fetch _ _ "/gnu/store/dg0pj2dpi8a8r39nzffjxgrrjy1h?" ?)
In guix/build/utils.scm:
616:6  0 (invoke _ . _)

guix/build/utils.scm:616:6: In procedure invoke:
Throw to key `srfi-34' with args `(#http://hg.openjdk.java.net/jdk6/jdk6/langtools/"; "--rev" "jdk6-b41" 
"--insecure" "/gnu/store/dg0pj2dpi8a8r39nzffjxgrrjy1hvc60-hg-checkout") 
exit-status: 255 term-signal: #f stop-signal: #f] 935980>)'.
builder for `/gnu/store/3niclf6ncz56718jaskhc01gbwga7w54-hg-checkout.drv' 
failed with exit code 1
build of /gnu/store/3niclf6ncz56718jaskhc01gbwga7w54-hg-checkout.drv failed
View build log at 
'/var/log/guix/drvs/3n/iclf6ncz56718jaskhc01gbwga7w54-hg-checkout.drv.bz2'.
cannot build derivation 
`/gnu/store/ai303ijm8h8dmh3iqrcgig444v7ja8f0-icedtea-1.13.13.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/4ifz2i0vn1di38qfy7mnqz3z316qrkpw-icedtea-2.6.13.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/v6isyghbfzzq3py5n36bslw5v48j4jcm-icedtea-3.7.0.drv': 1 dependencies 
couldn't be built
guix build: error: build failed: build of
`/gnu/store/v6isyghbfzzq3py5n36bslw5v48j4jcm-icedtea-3.7.0.drv' failed


-- 
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix | https://emacs.org

bug#33192: IcedTea & GH-Checkout DRV

[Brett Gilio]

Gábor Boskovits writes:

> Hello Brett,
>
> Brett Gilio  ezt írta (időpont: 2018. okt. 29., H, 1:06):
>>
>> Hi all, I think there might be a bug during the bootstrapping process of
>> IcedTea. Here is what the builder is throwing.
>>
>> ~ $ guix build icedtea
>> building /gnu/store/3niclf6ncz56718jaskhc01gbwga7w54-hg-checkout.drv...
>> abort: HTTP Error 500: Internal Server Error
>> Backtrace:
>>3 (primitive-load "/gnu/store/fvax9w48rk3jbyjqzb86nwg1wxw?")
>> In ice-9/eval.scm:
>>293:34  2 (_ #)
>> In guix/build/hg.scm:
>>  37:2  1 (hg-fetch _ _ "/gnu/store/dg0pj2dpi8a8r39nzffjxgrrjy1h?" ?)
>> In guix/build/utils.scm:
>> 616:6  0 (invoke _ . _)
>>
>> guix/build/utils.scm:616:6: In procedure invoke:
>> Throw to key `srfi-34' with args `(#> "/gnu/store/2f7zx9xy3yrfcgsai4ld3amj1asw4gbf-mercurial-4.7.2/bin/hg" 
>> arguments: ("clone" "http://hg.openjdk.java.net/jdk6/jdk6/langtools/"; 
>> "--rev" "jdk6-b41" "--insecure" 
>> "/gnu/store/dg0pj2dpi8a8r39nzffjxgrrjy1hvc60-hg-checkout") exit-status: 255 
>> term-signal: #f stop-signal: #f] 935980>)'.
>> builder for `/gnu/store/3niclf6ncz56718jaskhc01gbwga7w54-hg-checkout.drv' 
>> failed with exit code 1
>> build of /gnu/store/3niclf6ncz56718jaskhc01gbwga7w54-hg-checkout.drv failed
>> View build log at 
>> '/var/log/guix/drvs/3n/iclf6ncz56718jaskhc01gbwga7w54-hg-checkout.drv.bz2'.
>> cannot build derivation 
>> `/gnu/store/ai303ijm8h8dmh3iqrcgig444v7ja8f0-icedtea-1.13.13.drv': 1 
>> dependencies couldn't be built
>> cannot build derivation 
>> `/gnu/store/4ifz2i0vn1di38qfy7mnqz3z316qrkpw-icedtea-2.6.13.drv': 1 
>> dependencies couldn't be built
>> cannot build derivation 
>> `/gnu/store/v6isyghbfzzq3py5n36bslw5v48j4jcm-icedtea-3.7.0.drv': 1 
>> dependencies couldn't be built
>> guix build: error: build failed: build of
>> `/gnu/store/v6isyghbfzzq3py5n36bslw5v48j4jcm-icedtea-3.7.0.drv' failed
>>
>>
>> --
>> Brett M. Gilio
>> Free Software Foundation, Member
>> https://gnu.org/s/guix | https://emacs.org
>>
>>
>>
>
> I've just had a look at that, the server does not return the internal
> server error any more, I guess it
> was a transient error on their side. Could you try this again, and report 
> back?
>
> Best regards,
> g_bor

Gabor,

I appreciate you taking time to look into this for me. You appear to be
correct, it likely resolved over night. I appreciate it.


-- 
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix | https://emacs.org

bug#33196: emacs-realgud build failure

[Brett Gilio]

Hi all, I am experiencing the following error when building
emacs-realgud. Any thoughts?

~ $ guix build emacs-realgud
building /gnu/store/3cvp3fdk724wllbf14qcrsskkskcpdrs-emacs-realgud-1.4.5.drv...
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to 
`/gnu/store/jm060w7ms13y17gn51lfx75rwp6gan3r-emacs-minimal-26.1/bin:/gnu/store/g8vdvakifg2gkhd72956x3pgqy8dfq66-autoconf-2.69/bin:/gnu/store/39kbdwp16zi4czqfariw1bdspxw802da-automake-1.16.1/bin:/gnu/store/hxj9mdzhbjxmfj536crfscc0fhwwz4vy-tar-1.30/bin:/gnu/store/kc3xgspiq86ry6spyw874qk6pbxfpjx2-gzip-1.9/bin:/gnu/store/qvwvwbfz2hmjm0spz92sn1w3r5r8l2f8-bzip2-1.0.6/bin:/gnu/store/dk23rrx1nycghfqr32qpcn261pl0gyp4-xz-5.2.3/bin:/gnu/store/qhxgdgyiyq2ilvh17fqfw0njpqlg4gsc-file-5.32/bin:/gnu/store/iwfrjby868bx7fcc6mfl2z098j21ky5k-diffutils-3.6/bin:/gnu/store/q98l02i6wjw3v0x8vbp42ng8wwwxrb4g-patch-2.7.6/bin:/gnu/store/cyw1s5q7s7ql0vwkf34rzjb0cr6w1qnp-findutils-4.6.0/bin:/gnu/store/fbalwbm4yqldbfvcpaa2plhk4z7vszlz-gawk-4.2.1/bin:/gnu/store/2vggh6ka830b73vaw6mc8krqwk59fw9m-sed-4.5/bin:/gnu/store/i69323v107s0jj1l2vflwji1md537agi-grep-3.1/bin:/gnu/store/63gkgnixg6xj3m9cgl25ib2zxl51ngw0-coreutils-8.29/bin:/gnu/store/nx21fqlb8jixwhbs83xlfp9a3h5p3g9a-make-4.2.1/bin:/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin:/gnu/store/b5x786d3h552j2zp4ppvlz9dkbiqy2ng-ld-wrapper-0/bin:/gnu/store/srmqh29dpm50j8kj1pbqg2rgh053wgyp-binutils-2.30/bin:/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin:/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/bin:/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/sbin'
environment variable `INFOPATH' set to 
`/gnu/store/jm060w7ms13y17gn51lfx75rwp6gan3r-emacs-minimal-26.1/share/info:/gnu/store/g8vdvakifg2gkhd72956x3pgqy8dfq66-autoconf-2.69/share/info:/gnu/store/39kbdwp16zi4czqfariw1bdspxw802da-automake-1.16.1/share/info:/gnu/store/hxj9mdzhbjxmfj536crfscc0fhwwz4vy-tar-1.30/share/info:/gnu/store/kc3xgspiq86ry6spyw874qk6pbxfpjx2-gzip-1.9/share/info:/gnu/store/iwfrjby868bx7fcc6mfl2z098j21ky5k-diffutils-3.6/share/info:/gnu/store/cyw1s5q7s7ql0vwkf34rzjb0cr6w1qnp-findutils-4.6.0/share/info:/gnu/store/fbalwbm4yqldbfvcpaa2plhk4z7vszlz-gawk-4.2.1/share/info:/gnu/store/2vggh6ka830b73vaw6mc8krqwk59fw9m-sed-4.5/share/info:/gnu/store/i69323v107s0jj1l2vflwji1md537agi-grep-3.1/share/info:/gnu/store/63gkgnixg6xj3m9cgl25ib2zxl51ngw0-coreutils-8.29/share/info:/gnu/store/nx21fqlb8jixwhbs83xlfp9a3h5p3g9a-make-4.2.1/share/info:/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/share/info:/gnu/store/srmqh29dpm50j8kj1pbqg2rgh053wgyp-binutils-2.30/share/info:/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/share/info:/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/share/info'
environment variable `ACLOCAL_PATH' set to 
`/gnu/store/39kbdwp16zi4czqfariw1bdspxw802da-automake-1.16.1/share/aclocal'
environment variable `BASH_LOADABLES_PATH' unset
environment variable `C_INCLUDE_PATH' set to 
`/gnu/store/qvwvwbfz2hmjm0spz92sn1w3r5r8l2f8-bzip2-1.0.6/include:/gnu/store/dk23rrx1nycghfqr32qpcn261pl0gyp4-xz-5.2.3/include:/gnu/store/qhxgdgyiyq2ilvh17fqfw0njpqlg4gsc-file-5.32/include:/gnu/store/fbalwbm4yqldbfvcpaa2plhk4z7vszlz-gawk-4.2.1/include:/gnu/store/nx21fqlb8jixwhbs83xlfp9a3h5p3g9a-make-4.2.1/include:/gnu/store/srmqh29dpm50j8kj1pbqg2rgh053wgyp-binutils-2.30/include:/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/include:/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/include:/gnu/store/6w4x24a4i8ssgf147a7yhp6ppickr2nr-linux-libre-headers-4.14.26/include'
environment variable `CPLUS_INCLUDE_PATH' set to 
`/gnu/store/qvwvwbfz2hmjm0spz92sn1w3r5r8l2f8-bzip2-1.0.6/include:/gnu/store/dk23rrx1nycghfqr32qpcn261pl0gyp4-xz-5.2.3/include:/gnu/store/qhxgdgyiyq2ilvh17fqfw0njpqlg4gsc-file-5.32/include:/gnu/store/fbalwbm4yqldbfvcpaa2plhk4z7vszlz-gawk-4.2.1/include:/gnu/store/nx21fqlb8jixwhbs83xlfp9a3h5p3g9a-make-4.2.1/include:/gnu/store/srmqh29dpm50j8kj1pbqg2rgh053wgyp-binutils-2.30/include:/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/include:/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/include:/gnu/store/6w4x24a4i8ssgf147a7yhp6ppickr2nr-linux-libre-headers-4.14.26/include'
environment variable `LIBRARY_PATH' set to 
`/gnu/store/jm060w7ms13y17gn51lfx75rwp6gan3r-emacs-minimal-26.1/lib:/gnu/store/qvwvwbfz2hmjm0spz92sn1w3r5r8l2f8-bzip2-1.0.6/lib:/gnu/store/dk23rrx1nycghfqr32qpcn261pl0gyp4-xz-5.2.3/lib:/gnu/store/qhxgdgyiyq2ilvh17fqfw0njpqlg4gsc-file-5.32/lib:/gnu/store/fbalwbm4yqldbfvcpaa2plhk4z7vszlz-gawk-4.2.1/lib:/gnu/store/srmqh29dpm50j8kj1pbqg2rgh053wgyp-binutils-2.30/lib:/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib:/gnu/store/166hj8p5vnlqs4ghh4y6g745i6qx9dyr-glibc-2.27-static/lib:/gnu/store/ki1m42g3s2lav4mr3xjscg1bbdrqd5yz-glibc-utf8-locales-2.27/lib'
environment variable `GUIX_LOCPATH' set to 
`/gnu/store/ki1m42g3s2lav4mr3xjscg1bbdrqd5yz-glibc-utf8-locales-2.27/lib/locale'
phase `set-p

bug#33330: Hurd failing to build

[Brett Gilio]

Hi all,

I know that the hurd is not supported on Guix at the moment. I was
trying to give it a try in spite of that, and it is failing to build.

I am sure that this is a known issue, but I could not find any
referencing issues of recent on debbugs.

building /gnu/store/83vrxqm3xcwj9sn0kkbgaar4g7ac21ck-hurd-0.9.drv...
builder for `/gnu/store/83vrxqm3xcwj9sn0kkbgaar4g7ac21ck-hurd-0.9.drv' failed 
with exit code 1
build of /gnu/store/83vrxqm3xcwj9sn0kkbgaar4g7ac21ck-hurd-0.9.drv failed
View build log at 
'/var/log/guix/drvs/83/vrxqm3xcwj9sn0kkbgaar4g7ac21ck-hurd-0.9.drv.bz2'.
guix system: error: build failed: build of 
`/gnu/store/83vrxqm3xcwj9sn0kkbgaar4g7ac21ck-hurd-0.9.drv' failed


  guix 03a4153
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 03a415365a1cfcc263f56d309f33a1a581790ca7

Best,
Brett Gilio

bug#33330: Hurd failing to build

[Brett Gilio]

Manolis Ragkousis writes:

> Hello Brett,
>
> I imagine you run `guix build hurd`?
>
> Can you share the build log?


phase `unpack' succeeded after 0.2 seconds
starting phase `bootstrap'
GNU build system bootstrapping not needed
phase `bootstrap' succeeded after 0.0 seconds
starting phase `patch-usr-bin-file'
phase `patch-usr-bin-file' succeeded after 0.0 seconds
starting phase `patch-source-shebangs'
patch-shebang: ./config.guess: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./config.sub: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./configure: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./console-client/xkb/kstoucs_map.sh: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./daemons/rc.sh: changing `/bin/bash' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/bash'
patch-shebang: ./daemons/runsystem.hurd.sh: changing `/bin/bash' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/bash'
patch-shebang: ./daemons/runsystem.sh: changing `/bin/bash' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/bash'
patch-shebang: ./install-sh: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./mkinstalldirs: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./move-if-change: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./release/SETUP: changing `/bin/bash' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/bash'
patch-shebang: ./release/install-stripped: changing `/usr/local/bin/bash' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/bash'
patch-shebang: ./release/mkemptyso.sh: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./release/mkfsimage.sh: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./sutils/MAKEDEV.sh: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./sutils/e2os.sh: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./sutils/losetup.sh: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./utils/fakeroot.sh: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./utils/loginpr.sh: changing `/bin/bash' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/bash'
patch-shebang: ./utils/remap.sh: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./utils/sush.sh: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
patch-shebang: ./utils/uptime.sh: changing `/bin/sh' to 
`/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'
phase `patch-source-shebangs' succeeded after 0.1 seconds
starting phase `configure'
source directory: "/tmp/guix-build-hurd-0.9.drv-0/hurd-0.9" (relative from 
build: ".")
build directory: "/tmp/guix-build-hurd-0.9.drv-0/hurd-0.9"
configure flags: 
("CONFIG_SHELL=/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/bash"
 
"SHELL=/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/bash"
 "--prefix=/gnu/store/pcxx20nilxazhhfcjdc1wiydjg6hjsxi-hurd-0.9" 
"--enable-fast-install" "--build=x86_64-unknown-linux-gnu" 
"LDFLAGS=-Wl,-rpath=/gnu/store/pcxx20nilxazhhfcjdc1wiydjg6hjsxi-hurd-0.9/lib" 
"--disable-ncursesw" "--without-libbz2" "--without-libz" "--without-parted")
configure: WARNING: unrecognized options: --enable-fast-install
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
configure: error: this is the gnu os, host cannot be linux-gnu
*** Host configuration must be `MACHINE-gnu' or `MACHINE-VENDOR-gnu'.
*** To cross-compile, you must specify both --host and --build;
*** for example `--build=x86_64-unknown-linux-gnu --host=x86_64-gnu'.
*** Run ./configure --help for more information.
Backtrace:
   4 (primitive-load "/gnu/store/zz96nsjpr1x5dycqdb86qfzrbsg…")
In ice-9/eval.scm:
   191:35  3 (_ _)
In srfi/srfi-1.scm:
640:9  2 (for-each # …)
In 
/gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/gnu-build-system.scm:
   799:31  1 (_ _)
In 
/gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/utils.scm:
616:6  0 (invoke _ . _)

/gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/utils.scm:

bug#33330: Hurd failing to build

[Brett Gilio]

Manolis Ragkousis writes:

> Hello Ludo,
>
> On 11/11/18 6:44 PM, Ludovic Courtès wrote:
>> Hello Brett,
>> 
>> Brett Gilio  skribis:
>> 
>>> checking host system type... x86_64-unknown-linux-gnu
>>> configure: error: this is the gnu os, host cannot be linux-gnu
>>> *** Host configuration must be `MACHINE-gnu' or `MACHINE-VENDOR-gnu'.
>>> *** To cross-compile, you must specify both --host and --build;
>>> *** for example `--build=x86_64-unknown-linux-gnu --host=x86_64-gnu'.
>>> *** Run ./configure --help for more information.
>> 
>> To put it differently, the Hurd cannot be built natively on GNU/Linux.
>> You can cross-build the Hurd from GNU/Linux with something like:
>> 
>>   guix build hurd --target=i586-pc-gnu
>> 
>> … though I seem to remember even that is broken in current master.
>
>
> Yes, I am currently trying to fix this.
>
> Manolis

Thank you Ludo and Manolis for the input, here. If you need help with
anything here, please let me know.

Brett

bug#33496: Guix pull failing to compute derivation

[Brett Gilio]

Hi all, the latest guix pull is throwing a failure for computing the
next derivation.


Describe is:
Generation 16   Nov 24 2018 16:40:56(current)
  guix 71a78ba
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 71a78ba65b00ad1f27086a3dcdded7dc4326ade1

GUIX_PACKAGE_PATH="/home/brettg/GUIXEXT/"


Error is:
@ build-log 21446 107
/gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/utils.scm:616:6:
 In procedure invoke:
@ build-log 21446 239
Throw to key `srfi-34' with args `(#)'.
builder for 
`/gnu/store/qjd2z2zw0fzn6lh3ca9bs9x5kx7dkmag-guix-daemon-0.15.0-8.71a78ba.drv' 
failed with exit code 1
@ build-failed 
/gnu/store/qjd2z2zw0fzn6lh3ca9bs9x5kx7dkmag-guix-daemon-0.15.0-8.71a78ba.drv - 
1 builder for 
`/gnu/store/qjd2z2zw0fzn6lh3ca9bs9x5kx7dkmag-guix-daemon-0.15.0-8.71a78ba.drv' 
failed with exit code 1
Backtrace:
  15 (primitive-load "/gnu/store/br2zgg2j4wvpj44x48132r37d6c…")
In ice-9/eval.scm:
155:9 14 (_ _)
159:9 13 (_ #(#(#(#(#(#(#(#(#(#(#(…) …) …) …) …) …) …) …) …) …) …))
In guix/store.scm:
  1659:24 12 (run-with-store _ _ #:guile-for-build _ #:system _ # _)
   1532:8 11 (_ _)
In guix/gexp.scm:
706:2 10 (_ _)
In guix/monads.scm:
485:9  9 (_ _)
In guix/gexp.scm:
   572:22  8 (_ _)
In guix/store.scm:
   1532:8  7 (_ _)
  1555:38  6 (_ #)
In guix/packages.scm:
   881:14  5 (cache! # # …)
In unknown file:
   4 (_ # # #)
In guix/grafts.scm:
304:4  3 (graft-derivation # # …)
182:4  2 (references-oracle # #)
   191:20  1 (_ _ _)
In guix/store.scm:
  1104:15  0 (_ # _ _)

guix/store.scm:1104:15: Throw to key `srfi-34' with args `(#)'.
guix pull: error: You found a bug: the program 
'/gnu/store/br2zgg2j4wvpj44x48132r37d6cam479-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"254602cdf884379231793c4d793b25c9ebd6c806"; system: "x86_64-linux";
host version: "71a78ba65b00ad1f27086a3dcdded7dc4326ade1"; pull-version: 1).
Please report it by email to .


Thanks,
Brett Gilio

bug#33500: guix pull error. '34843fe'. guix-daemon-0.15.0-8.71a78ba.drv' failed with exit code 1

[Brett Gilio]

zna...@tutanota.com writes:

> Hi! Please, correct this.
>
> #guix pull
> ...
> @ build-log 4927 107
> /gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/utils.scm:616:6:
>  In procedure invoke:
> @ build-log 4927 239
> Throw to key `srfi-34' with args `(# arguments: ("install-binPROGRAMS" "install-nodist_pkglibexecSCRIPTS" 
> "install-nodist_libexecSCRIPTS") exit-status: 2 term-signal: #f stop-signal: 
> #f] a14b00>)'.
> /builder for 
> `/gnu/store/1p3hzkimqdim9cpf6igscvnk6jfz2h66-guix-daemon-0.15.0-8.71a78ba.drv'
>  failed with exit code 1
> @ build-failed 
> /gnu/store/1p3hzkimqdim9cpf6igscvnk6jfz2h66-guix-daemon-0.15.0-8.71a78ba.drv 
> - 1 builder for 
> `/gnu/store/1p3hzkimqdim9cpf6igscvnk6jfz2h66-guix-daemon-0.15.0-8.71a78ba.drv'
>  failed with exit code 1
> Backtrace:
>  15 (primitive-load "/gnu/store/br2zgg2j4wvpj44x48132r37d6c…")
> In ice-9/eval.scm:
>  155:9 14 (_ _)
>  159:9 13 (_ #(#(#(#(#(#(#(#(#(#(#(…) …) …) …) …) …) …) …) …) …) …))
> In guix/store.scm:
>  1659:24 12 (run-with-store _ _ #:guile-for-build _ #:system _ # _)
>  1532:8 11 (_ _)
> In guix/gexp.scm:
>  706:2 10 (_ _)
> In guix/monads.scm:
>  485:9 9 (_ _)
> In guix/gexp.scm:
>  572:22 8 (_ _)
> In guix/store.scm:
>  1532:8 7 (_ _)
>  1555:38 6 (_ #)
> In guix/packages.scm:
>  881:14 5 (cache! # # …)
> In unknown file:
>  4 (_ # # #)
> In guix/grafts.scm:
>  304:4 3 (graft-derivation # # …)
>  182:4 2 (references-oracle # #)
>  191:20 1 (_ _ _)
> In guix/store.scm:
>  1104:15 0 (_ # _ _)
>
> guix/store.scm:1104:15: Throw to key `srfi-34' with args `(# &nix-protocol-error [message: "build of 
> `/gnu/store/1p3hzkimqdim9cpf6igscvnk6jfz2h66-guix-daemon-0.15.0-8.71a78ba.drv'
>  failed" status: 100] 57373c0>)'.
> guix pull: error: You found a bug: the program 
> '/gnu/store/br2zgg2j4wvpj44x48132r37d6cam479-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "34843fe9238a041616f063038557d85cd8a30165"; system: "x86_64-linux";
> host version: "083ce0ad5ecd10c6033bbdef5ddfcc2f58a7b800"; pull-version: 1).
> Please report it by email to mailto:bug-guix@gnu.org>>.
>
> # guix describe
> Generation 39 Nov 24 2018 10:49:56 (current)
>  guix 083ce0a
>  repository URL: https://git.savannah.gnu.org/git/guix.git 
> 
>  branch: master
>  commit: 083ce0ad5ecd10c6033bbdef5ddfcc2f58a7b800
>
> # guix pull
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git 
> '...
> Building from this channel:
>  guix https://git.savannah.gnu.org/git/guix.git 
>  34843fe
> ^Z
> [1]+ Stopped guix pull
> # ^C

I think this is a duplicate of my reported #33496.

bug#33603: Invalid hash for NSS-Certs

[Brett Gilio]

Generation 10   Dec 03 2018 11:42:41(current)
  guix 4f03aa2
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 4f03aa23e805bd653de774e1d74ed2f50826899b

downloading from 
https://mirror.hydra.gnu.org/guix/nar/gzip/xbj4fhad0lnz0ziflwi90gyqbls8ains-nss-certs-3.39...
 nss-certs-3.39  145KiB   417KiB/s 00:00 [##] 100.0%

sha256 hash mismatch for 
/gnu/store/xbj4fhad0lnz0ziflwi90gyqbls8ains-nss-certs-3.39:
  expected hash: 101v69xp1qzw9v6pgmbhw7gfdaic8vvs4v5l567lx7f2mjp25rla
  actual hash:   08ziz714diyfq2klxy1nc0nhr5wa2vd356n9vizlq913a7an9a9s
substitution of /gnu/store/xbj4fhad0lnz0ziflwi90gyqbls8ains-nss-certs-3.39 
failed

bug#33604: Backtrace in guix package -s

[Brett Gilio]

Hi all, When I run ex: `guix package -s emacs` it is presenting this
backtrace. It has been there for a few commits now. Does anybody have
thoughts on it?

Backtrace:
In ice-9/boot-9.scm:
829:9 19 (catch _ _ # …)
829:9 18 (catch _ _ # …)
In guix/scripts/package.scm:
914:8 17 (_)
760:9 16 (process-query _)
In ice-9/boot-9.scm:
829:9 15 (catch _ _ # …)
In guix/scripts/package.scm:
   762:24 14 (_)
   180:17 13 (find-packages-by-description _)
In guix/discovery.scm:
155:3 12 (fold-module-public-variables _ _ _)
In guix/combinators.scm:
45:26 11 (fold2 # …)
45:26 10 (fold2 # …)
In guix/discovery.scm:
   158:33  9 (_ # …)
In guix/scripts/package.scm:
   183:38  8 (_ # …)
In srfi/srfi-1.scm:
   466:18  7 (fold # …)
In guix/ui.scm:
  1270:13  6 (_ _ 4)
  1146:23  5 (texi->plain-text _)
In texinfo.scm:
  1131:22  4 (parse _)
   910:31  3 (loop # (*fragment*) # …)
   753:31  2 (_ # _ #f # …)
   492:18  1 (read-command-token #)
446:8  0 (read-command #)

texinfo.scm:446:8: In procedure read-command:
Throw to key `parser-error' with args `(# "Nonalphabetic 
@-command char: '" #\) "'")'.






brettg@guixsd ~$ guix describe
Generation 12   Dec 03 2018 15:17:28(current)
  guix 91a4863
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 91a4863d9d727754d1743f4c0591c63b950494cf

bug#33604: Backtrace in guix package -s

[Brett Gilio]

Mark H Weaver writes:

> Hi Brett,
>
> Brett Gilio  writes:
>
>> Hi all, When I run ex: `guix package -s emacs` it is presenting this
>> backtrace. It has been there for a few commits now. Does anybody have
>> thoughts on it?
>>
>> Backtrace:
>> In ice-9/boot-9.scm:
>> 829:9 19 (catch _ _ # …)
>> 829:9 18 (catch _ _ # …)
>> In guix/scripts/package.scm:
>> 914:8 17 (_)
>> 760:9 16 (process-query _)
>> In ice-9/boot-9.scm:
>> 829:9 15 (catch _ _ # …)
>> In guix/scripts/package.scm:
>>762:24 14 (_)
>>180:17 13 (find-packages-by-description _)
>> In guix/discovery.scm:
>> 155:3 12 (fold-module-public-variables _ _ _)
>> In guix/combinators.scm:
>> 45:26 11 (fold2 # …)
>> 45:26 10 (fold2 # …)
>> In guix/discovery.scm:
>>158:33  9 (_ # …)
>> In guix/scripts/package.scm:
>>183:38  8 (_ # …)
>> In srfi/srfi-1.scm:
>>466:18  7 (fold # …)
>> In guix/ui.scm:
>>   1270:13  6 (_ _ 4)
>>   1146:23  5 (texi->plain-text _)
>> In texinfo.scm:
>>   1131:22  4 (parse _)
>>910:31  3 (loop # (*fragment*) # …)
>>753:31  2 (_ # _ #f # …)
>>492:18  1 (read-command-token #)
>> 446:8  0 (read-command #)
>>
>> texinfo.scm:446:8: In procedure read-command:
>> Throw to key `parser-error' with args `(# 
>> "Nonalphabetic @-command char: '" #\) "'")'.
>
> This appears to be due to an error in the texinfo markup within one of
> the fields of the 'emacs-csharp-mode' package.
>
> I can't find an 'emacs-csharp-mode' package in the Guix source tree, so
> I guess it lives in one of your private package directories.
>
>Mark

You're right! My mistake! Thank you!

bug#43738: Patch file names too long

[Brett Gilio]

Ludovic Courtès  writes:

> There are several patch file names that are too long for ‘tar’, as
> reported during ‘make dist’:
>
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/ocaml-bisect-fix-camlp4-in-another-directory.patch
>  dosiernomo tro longas (maks 99); ne ŝutita
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/audiofile-signature-of-multiplyCheckOverflow.patch
>  dosiernomo tro longas (maks 99); ne ŝutita
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/python2-pygobject-2-gi-info-type-error-domain.patch
>  dosiernomo tro longas (maks 99); ne ŝutita
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/audiofile-division-by-zero-BlockCodec-runPull.patch
>  dosiernomo tro longas (maks 99); ne ŝutita
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/python-robotframework-honor-source-date-epoch.patch
>  dosiernomo tro longas (maks 99); ne ŝutita
>
> ‘guix lint’ reports it as well, but apparently this is easily
> overlooked.
>
> Ludo’.

Does it matter that this is coming from a dirty working tree? Maybe not.

Brett Gilio

bug#43579: g++ does not provide std::fegetround

[Brett Gilio]

Ludovic Courtès  writes:

> Hallo!
>
> Andreas Enge  skribis:
>
>> The following test file round.cpp does not compile with our g++-10.2.0:
>> #include 
>> int main () {
>>return std::fegetround ();
>> }
>
> Could you provide detailed steps to reproduce it?
>
> Thanks,
> Ludo’.

I believe `std::fegetround` was introduced in C++11, are you using the
appropriate flag?

Brett Gilio

bug#44027: 1.2-29a2eb3 Installer fails at final stage installing GRUB.

[Brett Gilio]

Ludovic Courtès  writes:
>
> Shouldn’t it create a “legacy” partition table rather than GPT since
> we’re on an old, non-UEFI platform?
>
> Ludo’.
>

That is my thinking as well, it should create a legacy MBR table.

-- 
Brett M. Gilio
bre...@gnu.org
https://brettgilio.com/
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

bug#44725: ocaml-cairo2 package fails to build

[Brett Gilio]

Evan Straw  writes:

> Hello Guix maintainers,
>
> While updating Coq recently I found that the ocaml-cairo2 package it
> depends on does not build. It seems to be failing with an error during
> the check phase while calling `dune runtest tests`. The build log is
> very long so I've attached it as a file.
>
> I am using Guix on a foreign distro, Ubuntu 20.04 LTS, and my CPU
> architecture is x86_64.
>

This is a test-phase issue. It looks like it might be a segmentation
fault from a C dependency (maybe Cairo itself)? I or somebody will look
a little deeper. In the meantime I am going to disable the test-phase
and mark this issue as open.

-- 
Brett M. Gilio
bre...@gnu.org
https://brettgilio.com/
GNU Project webmaster [https://gnu.org/help/]
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

bug#44725: ocaml-cairo2 package fails to build

[Brett Gilio]

zimoun  writes:

> Hi,
>
> On Wed, 18 Nov 2020 at 15:53, Brett Gilio  wrote:
>
>> This is a test-phase issue. It looks like it might be a segmentation
>> fault from a C dependency (maybe Cairo itself)? I or somebody will look
>> a little deeper. In the meantime I am going to disable the test-phase
>> and mark this issue as open.


I did some investigating, and it seems disabling the tests is the
correct action to take.

See:

[0]
https://github.com/kit-ty-kate/opam-repository/commit/4db9f97d242fbfd3b3100128797a4f941f66a32d

[1] https://github.com/ocaml/ocaml/issues/9360

-- 
Brett M. Gilio
bre...@gnu.org
https://brettgilio.com/
GNU Project webmaster [https://gnu.org/help/]
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

bug#44725: ocaml-cairo2 package fails to build

[Brett Gilio]

Brett Gilio  writes:

> zimoun  writes:
>
>> Hi,
>>
>> On Wed, 18 Nov 2020 at 15:53, Brett Gilio  wrote:
>>
>>> This is a test-phase issue. It looks like it might be a segmentation
>>> fault from a C dependency (maybe Cairo itself)? I or somebody will look
>>> a little deeper. In the meantime I am going to disable the test-phase
>>> and mark this issue as open.
>
>
> I did some investigating, and it seems disabling the tests is the
> correct action to take.
>
> See:
>
> [0]
> https://github.com/kit-ty-kate/opam-repository/commit/4db9f97d242fbfd3b3100128797a4f941f66a32d
>
> [1] https://github.com/ocaml/ocaml/issues/9360

-- 
Brett M. Gilio
bre...@gnu.org
https://brettgilio.com/
GNU Project webmaster [https://gnu.org/help/]
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

bug#34423: gnome-shell-extensions and glib

[Brett Gilio]

Hi all, when I try to install gnome-shell-extensions it is throwing this
issue

brettg@guixsd ~$ guix package -i gnome-shell-extensions
The following package will be installed:
   gnome-shell-extensions   3.24.3  
/gnu/store/bfw4wp2lm68s3gdhhbic0kr2rfzcab07-gnome-shell-extensions-3.24.3

guix package: error: profile contains conflicting entries for glib
guix package: error:   first entry: glib@2.56.3 
/gnu/store/lly2sqknlw8h59bfffpgh836r38ffsdc-glib-2.56.3
guix package: error:... propagated from gnome-shell-extensions@3.24.3
guix package: error:   second entry: glib@2.56.2 
/gnu/store/qc5b998gnhb5p8lc9mf0knr1nyc648k9-glib-2.56.2
guix package: error:... propagated from cairo@1.14.12
guix package: error:... propagated from guile-cairo@1.10.0
guix package: error:... propagated from guile-gnome@2.16.5
hint: Try upgrading both `gnome-shell-extensions' and `guile-gnome', or remove
one of them from the profile.





The strangeness of the issue is not only that glib seems to be
referencing two different versions, but I don't even have guile-gnome
installed for there to be a "conflict".

Thoughts?

bug#34597: `guix challenge` - 41 packages differ

[Brett Gilio]

mikadoZero writes:

> After running `guix challenge` there are some packages which differ from ones 
> I have built locally.

Hi Mikado,

Unless I am mistaken this isn't truly a reportable bug. As you can see
in the guix challenge documentation
https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-challenge.html
the purpose of challenge is to check for deterministic qualities in
reproducible packages. Right now, not all packages are reproducible as
the guix team is hard at work trying to find the best solution for
replacing binary seeds with something fully bootstrappable (see:
https://bootstrappable.org)

If you look, all of the packages you showed are related to the guix core
system, which means that you are not getting any non-deterministic
packages from the relevant /gnu package repositories, which is good.

I think this bug can probably be closed.

All the best,
Brett Gilio

bug#34611: virt-manager is not recognizing libvirtd service

[Brett Gilio]

Hi all,

I am having an issue using virt-manager on GuixSD. I have libvirt and
virt-manager installed, and am starting the libvirtd service using my
configuration file. However, regardless of whether or not I start
virt-manager as root or normal privileges, I am getting a "checking for
virtualization packages..." note with an error of "No active connection
to install on." libvirtd and virtlogd are properly started as far as I
can tell by queurying the herd. Here is my relevant configuration.

(users (cons (user-account
(name "brettg")
    (comment "Brett Gilio")
(group "users")
(supplementary-groups '("wheel" "netdev"
"audio" "video"
"libvirt"))
(home-directory "/home/brettg"))
   %base-user-accounts))


  (packages (cons* nss-certs ;for HTTPS access
   gvfs  ;for user mounts
   libvirt
   %base-packages))

  (services (cons* (service gnome-desktop-service-type
(gnome-desktop-configuration
 (inherit config)
 (gnome-package gnome-custom)))
   (service libvirt-service-type)
   (service virtlog-service-type)
   (service gdm-service-type)
   (filter (lambda (x)
 (not (eq? (service-kind x) slim-service-type)))
   %desktop-services)))

bug#34890: guix system: error: failed to install bootloader

[Brett Gilio]

Jack Hill writes:

> Hi Guix,
>
> Today after a guix pull to commit
> e3545ffcf95bffbbd967efd852715f4f0a9be290, guix system reconfigure
> fails to install grub (bios grub on x86_64) with
>
> guix system: error: failed to install bootloader 
> /gnu/store/45myfaqas69fnp3mfbqlsf9lafm30cl0-bootloader-installer
>
> /gnu/store/45myfaqas69fnp3mfbqlsf9lafm30cl0-bootloader-installer is
>
> (eval-when (expand load eval) (set! %load-path (cons
> "/gnu/store/wa7bn283y9pg2h5g75j1fmqbp1m5js7w-module-import" (append
> (map (lambda (extension) (string-append extension "/share/guile/site/"
> (effective-version))) (quote ())) %load-path))) (set!
> %load-compiled-path (cons
> "/gnu/store/w5a1xk656i0sw15mqj7bz8zp130c8m27-module-import-compiled"
> (append (map (lambda (extension) (string-append extension
> "/lib/guile/" (effective-version) "/site-ccache")) (quote ()))
> %load-compiled-path(begin (use-modules (gnu build bootloader)
> (guix build utils) (ice-9 binary-ports) (srfi srfi-34) (srfi srfi-35))
> (guard (c ((message-condition? c) (format (current-error-port) "error:
> ~a~%" (condition-message c)) (exit 1))) ((lambda (bootloader device
> mount-point) (let ((grub (string-append bootloader
> "/sbin/grub-install")) (install-dir (string-append mount-point
> "/boot"))) (setenv "GRUB_ENABLE_CRYPTODISK" "y") (invoke/quiet grub
> "--no-floppy" "--target=i386-pc" "--boot-directory" install-dir
> device))) "/gnu/store/shbswxl2g7n6fvi6gq45bvan4saygkv2-grub-2.02"
> "/dev/sda" "/") (format #t "bootloader successfully installed on
> '~a'~%" device)))
>

I can replicate this bug, however it is still successfully installing a
new system configuration. The error printout seems erroneous (pun
intended).

I am sure there is a regression somewhere, but it does not seem to
adversely effect the method in question.

bug#35465: Ocaml-yojson build failing

[Brett Gilio]

Hi all,

the ocaml-yojson build is failing. The output is short enough I just
included it all here.

brettg@guixsd ~ [env]$ guix build ocaml-yojson
building /gnu/store/kif8labifv0ydvfvfxlqc3qkzqqhd5ax-ocaml-yojson-1.4.1.drv...
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to 
`/gnu/store/g0805hbhcml2dhh8pbmc996ml4gzsf03-dune-1.9.1/bin:/gnu/store/yqi231fddnwhdf1jm2lgsiqahcagcbq4-ocaml-4.07.1/bin:/gnu/store/2d80m75lyraby536f68ga2zlkk2iawbl-ocaml-findlib-1.8.0/bin:/gnu/store/h365bb1sj060cgm0vir15vaw86snz1ra-ocaml-cppo-1.6.5/bin:/gnu/store/zrvpggpxf5ggb7mdv2817fn68d17vnyn-ocaml-yojson-1.4.1-checkout/bin:/gnu/store/95m945kvmvfibq8ljb6dbb8m0wf9zibc-ocaml-biniou-1.2.0/bin:/gnu/store/fqwyydd3vjzdh4dbs8xz6y462bjc49k3-ocaml-easy-format-1.3.1/bin:/gnu/store/bl3pxxj6frg0dww8pj5dvh2d1akwvj47-tar-1.30/bin:/gnu/store/h0c398zan9ibhk4w0c944vp5pwgzkfpd-gzip-1.9/bin:/gnu/store/j74aabxwayjl9yfyrm6ni482gykxq48b-bzip2-1.0.6/bin:/gnu/store/9425b5dwpfc04bb4p58hsjypxghliyr3-xz-5.2.4/bin:/gnu/store/ypiyk8ngn79cz655jrl0hng37xv54yjr-file-5.33/bin:/gnu/store/4bzzz0lzjc9b7bfsnqbq2j22d4fvf433-diffutils-3.6/bin:/gnu/store/a4rxl40jr7gmq8bp3dryq4yq67cwkwiw-patch-2.7.6/bin:/gnu/store/fd621k6fmdnr1yiw0lbvw5spqaa169j3-findutils-4.6.0/bin:/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk-4.2.1/bin:/gnu/store/lmfddplnplxd03bcqv3w9pynbnr1fp8k-sed-4.5/bin:/gnu/store/02k245xy33cvcnr8vm3lagm9zmb1s2wa-grep-3.1/bin:/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin:/gnu/store/7j3941iannrngdvgbclyxid12vds5w9i-make-4.2.1/bin:/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin:/gnu/store/9ysmg2739n1ms84lx6hifncgc5l2hiy9-ld-wrapper-0/bin:/gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/bin:/gnu/store/n2p1zs14y89lwkg9da68y12pc10c6sw9-gcc-5.5.0/bin:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/bin:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/sbin'
environment variable `OCAMLPATH' set to 
`/gnu/store/g0805hbhcml2dhh8pbmc996ml4gzsf03-dune-1.9.1/lib/ocaml:/gnu/store/g0805hbhcml2dhh8pbmc996ml4gzsf03-dune-1.9.1/lib/ocaml/site-lib:/gnu/store/yqi231fddnwhdf1jm2lgsiqahcagcbq4-ocaml-4.07.1/lib/ocaml:/gnu/store/2d80m75lyraby536f68ga2zlkk2iawbl-ocaml-findlib-1.8.0/lib/ocaml:/gnu/store/2d80m75lyraby536f68ga2zlkk2iawbl-ocaml-findlib-1.8.0/lib/ocaml/site-lib:/gnu/store/h365bb1sj060cgm0vir15vaw86snz1ra-ocaml-cppo-1.6.5/lib/ocaml:/gnu/store/h365bb1sj060cgm0vir15vaw86snz1ra-ocaml-cppo-1.6.5/lib/ocaml/site-lib:/gnu/store/95m945kvmvfibq8ljb6dbb8m0wf9zibc-ocaml-biniou-1.2.0/lib/ocaml:/gnu/store/95m945kvmvfibq8ljb6dbb8m0wf9zibc-ocaml-biniou-1.2.0/lib/ocaml/site-lib:/gnu/store/fqwyydd3vjzdh4dbs8xz6y462bjc49k3-ocaml-easy-format-1.3.1/lib/ocaml:/gnu/store/fqwyydd3vjzdh4dbs8xz6y462bjc49k3-ocaml-easy-format-1.3.1/lib/ocaml/site-lib'
environment variable `CAML_LD_LIBRARY_PATH' unset
environment variable `BASH_LOADABLES_PATH' unset
environment variable `C_INCLUDE_PATH' set to 
`/gnu/store/j74aabxwayjl9yfyrm6ni482gykxq48b-bzip2-1.0.6/include:/gnu/store/9425b5dwpfc04bb4p58hsjypxghliyr3-xz-5.2.4/include:/gnu/store/ypiyk8ngn79cz655jrl0hng37xv54yjr-file-5.33/include:/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk-4.2.1/include:/gnu/store/7j3941iannrngdvgbclyxid12vds5w9i-make-4.2.1/include:/gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/include:/gnu/store/n2p1zs14y89lwkg9da68y12pc10c6sw9-gcc-5.5.0/include:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include:/gnu/store/xha1mk4qji8fmg62nygfzdx0l94ikdhm-linux-libre-headers-4.14.67/include'
environment variable `CPLUS_INCLUDE_PATH' set to 
`/gnu/store/j74aabxwayjl9yfyrm6ni482gykxq48b-bzip2-1.0.6/include:/gnu/store/9425b5dwpfc04bb4p58hsjypxghliyr3-xz-5.2.4/include:/gnu/store/ypiyk8ngn79cz655jrl0hng37xv54yjr-file-5.33/include:/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk-4.2.1/include:/gnu/store/7j3941iannrngdvgbclyxid12vds5w9i-make-4.2.1/include:/gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/include:/gnu/store/n2p1zs14y89lwkg9da68y12pc10c6sw9-gcc-5.5.0/include:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include:/gnu/store/xha1mk4qji8fmg62nygfzdx0l94ikdhm-linux-libre-headers-4.14.67/include'
environment variable `LIBRARY_PATH' set to 
`/gnu/store/g0805hbhcml2dhh8pbmc996ml4gzsf03-dune-1.9.1/lib:/gnu/store/yqi231fddnwhdf1jm2lgsiqahcagcbq4-ocaml-4.07.1/lib:/gnu/store/2d80m75lyraby536f68ga2zlkk2iawbl-ocaml-findlib-1.8.0/lib:/gnu/store/h365bb1sj060cgm0vir15vaw86snz1ra-ocaml-cppo-1.6.5/lib:/gnu/store/zrvpggpxf5ggb7mdv2817fn68d17vnyn-ocaml-yojson-1.4.1-checkout/lib:/gnu/store/95m945kvmvfibq8ljb6dbb8m0wf9zibc-ocaml-biniou-1.2.0/lib:/gnu/store/fqwyydd3vjzdh4dbs8xz6y462bjc49k3-ocaml-easy-format-1.3.1/lib:/gnu/store/j74aabxwayjl9yfyrm6ni482gykxq48b-bzip2-1.0.6/lib:/gnu/store/9425b5dwpfc04bb4p58hsjypxghliyr3-xz-5.2.4/lib:/gnu/store/ypiyk8ngn79cz655jrl0hng37xv54yjr-file-5.33/lib:/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk-4.2.1/lib:/gnu/sto

bug#35465: Ocaml-yojson build failing

[Brett Gilio]

Julien Lepiller writes:
>
> Most likely this is my fault... I thought I rebuilt everything locally 
> though. Yojson can be upgraded to 1.7.0, but I think it caused a build 
> failure in merlin. Can you try?

I actually did give this a try in my channel before sending the
email. You are right, something with Merlin breaks because of Menhir.

I can get menhir to build just fine, but adding it as an input to Merlin
doesnt change the behavior of the compile-time stuff.

So it is a rabbit hole.

If Ricardo is reading this, would you mind taking a look at this issue?

Brett

bug#35484: GDM failing to start stumpwm after merge

[Brett Gilio]

Hey all

I just reconfigured my system configuration after the big staging merge
to master. I use StumpWM.

GDM seems to be starting just fine, but after this reconfiguration
stumpwm or X or something is crashing for me and looping me back to GDM.

Where are the logs I can view for this? I see some message appear but
quickly disappear before looping back into GDM.

If I can get the logs I can share them or try and figure it out myself.

Best,
Brett Gilio

bug#35484: GDM failing to start stumpwm after merge

[Brett Gilio]

Timothy Sample writes:

> Hi Brett,
>
> bre...@posteo.net writes:
>
>> On 29.04.2019 18:05, Timothy Sample wrote:
>>>
>>> After doing some testing in a VM, it looks like this is an issue
>>> with my
>>> recent commit: 8caa458953eeac783c73a0e5aaa72842fe3914c9.
>>>
>>> I added a placeholder desktop entry file, and even though I did my best
>>> to make it invisible, GDM is still selecting it.  (I tested GNOME and
>>> XFCE, but I guess they were preferred by GDM over the placeholder,
>>> whereas StumpWM is not.  Maybe the has to do with how the names are
>>> sorted.)
>
> This is exactly the problem.  To find a default session, it sorts the
> names of all the “.desktop” files it can find (using “g_strcmp0”), and
> picks the first.  Since we have “GNOME” < “XFCE” < “Fail” < “stumpwm”,
> my tests did not catch this error.
>
> I can think of two options for a fix before 1.0 (which is supposed to be
> tomorrow!).  The cute one is to just rename “Fail” to “~Fail”, on the
> expectation that this will come after most other names when sorted.  The
> ugly one is to patch GDM to exclude the placeholder file when looking
> for “.desktop” files, and then to select it instead of raising an error
> when it can’t find anything.
>
> My preference is for the ugly one, because the cute one feels like
> putting a silly hack on top of silly hack – it’s just a bit too much.
> I’ve attached a patch.  Thoughts?  (If I don’t hear anything, I will
> push it – it’s important that this works for 1.0).
>
>
> In the future, we should find a way to make GDM errors less
> catastrophic, but I doubt we could do that in a day (I certainly
> couldn’t)!
>
>> Thank you for looking into this Tim! I have gone back to SLiM for the
>> time being until it is fixed :).
>>
>> If anybody else is having this issue, going back to SLiM is really
>> easy, check out my commit for reference.
>>
>> https://github.com/brettgilio/guix-system/commit/64d389db13c2f78ee5c58af28c1639b098113c93
>
> Thanks for providing this.  Hopefully it helps anybody else having
> problems.
>
>
> -- Tim

I think the uglier version is more generic and less likely to cause
future errors. But, it is a matter of time. The uglier one is likely
going to be more terse.

Do you need any help on my end?

Brett Gilio

bug#35500: ocaml-utop fatal error

[Brett Gilio]

I have ocaml-utop installed in an environment. When I run utop from the
shell it returns this rather unamusing error message.

brettg@guixsd ~ [env]$ utop
Fatal error: exception Not_found

There is a reference to this error on github, here
https://github.com/ocaml-community/utop/issues/224

I tried patching this myself but I did not get far.

Brett Gilio

bug#38433: ProofGeneral and Emacs sharing a profile

[Brett Gilio]

There is an issue after the EMACSLOADPATH change that creates a problem
when `proof-general` and `emacs` share a profile. This issue can be
replicated as follows:

--8<---cut here---start->8---
$ guix environment --ad-hoc proof-general emacs
--8<---cut here---end--->8---

When you launch the client of either of these after spinning up the
environment, you are prompted with this from the *Messages* buffer.

--8<---cut here---start->8---
Loading 
/gnu/store/bi3yv2q84fpyq1ym9z8rpa8hv2xhz1bf-profile/share/emacs/site-lisp/ProofGeneral/generic/proof-autoloads...done
Loading 
/gnu/store/bi3yv2q84fpyq1ym9z8rpa8hv2xhz1bf-profile/share/emacs/site-lisp/ProofGeneral/generic/proof-autoloads...
byte-code: Already loaded
--8<---cut here---end--->8---

Loading stops without an error message at this point, failing to
complete the initialization process.

I can probably figure out this issue, but I am currently drained for
time, so I am reporting it here. If nobody else gets to it before I do,
I will come back to it.

Thanks!

-- 
Brett M. Gilio
https://git.sr.ht/~brettgilio/

bug#38422: .png files in /gnu/store with executable permissions (555)

[Brett Gilio]

Mark H Weaver  writes:

> [...] In cases where it
> _is_ difficult to find out how to report bugs, that's arguably a problem
> that should be fixed upstream.
>
> What do you think?
>
>   Regards,
> Mark
>
>
>

Agreed 100% with Mark.

-- 
Brett M. Gilio
https://git.sr.ht/~brettgilio/

bug#38433: ProofGeneral and Emacs sharing a profile

[Brett Gilio]

Julien Lepiller  writes:

> It could pg's fault. We have a vcry old vcrsion that is probably
> completely broken. I tried to package a newer version, but being not
> an emacs user it was too hard for me. Maybe someone can give it a try
> (you? :p)

I have began working updating the package. :)

A lot of things have changed between the current version in Guix, and
the latest upstream. So I want to be thorough. Will update on the status
and send a patch soon.

-- 
Brett M. Gilio
https://git.sr.ht/~brettgilio/

bug#38500: Ruby is built against libruby-static.a

[Brett Gilio]

Vicente Eduardo  writes:

> I would like to have two versions, or at least the dynamic one, that's the 
> common way
> Ruby should be built, and also the Guixy style.

This actually brings up a rather interesting point. What is the Guix
protocol on compilation for dynamic vs statically linked interpreters?
This is a prevalent issue not just for Ruby, but for also how we handle
GHC, Rust, JDK, and so on.

Generally, I think we dynamically link most objects. _BUT_, I could be
missing part of the story here. So I am going to wait for the higher
powers that be to respond.

In the mean time, when I get a moment, I will do some auditing on this
package to see if the issue is just that we are missing some compilation
procedure. Hopefully it is just as simple as that, but I still think the
issue of linkage style (dynamic vs static linkage) remains prevalent.

Hopefully we hear some noise on this soon.

-- 
Brett M. Gilio
https://git.sr.ht/~brettgilio/

bug#38500: Ruby is built against libruby-static.a

[Brett Gilio]

Tobias Geerinckx-Rice  writes:

> You could ask Pjotr Prins and David Thompson but I suspect that it was
> simply an oversight: most packages link dynamically by default because
> it's the sane thing to do, and it would have been reasonable to assume
> Ruby did too.

Tobias,
I did some investigating about enabling the --enable-shared flag for
dynamic linkage of the Ruby package. Superficially it seems that simply

--8<---cut here---start->8---
#:configure-flags (list "--enable-shared")
--8<---cut here---end--->8---

takes care of the issue. However, this will trigger a rebuild more along
the lines of core-updates.

--8<---cut here---start->8---
Building the following 1261 packages would ensure 3512 dependent
packages are rebuilt:
--8<---cut here---end--->8---

It is basically everything from SBCL, R, GNOME, XFCE, several Python
packages, and more which is expected.

So I guess the question is where does this patch go given that it isn't
an update but would still spark a massive rebuild?

&&&

Vicente,
I have a suspicion that this patch will need to rest on core-updates (or
staging) for a number of weeks before it reaches master. In the
meantime, I suggest you just inherit the ruby package in your own
channel with the package arguments modified to reflect the
`#:configure-flags` snippet I have listed above.

Okay. Carry on.

-- 
Brett M. Gilio
https://git.sr.ht/~brettgilio/

bug#38529: Make --pure the default for `guix environment'?

[Brett Gilio]

"Thompson, David"  writes:

> Hi,
>
> I have long thought that --ad-hoc should be implied, as that is the
> mode I use 99% of the time, but I disagree that --pure should be the
> default. Most of the time I (and I suspect most other users) just want
> to temporarily augment the current environment with a package or two
> and I think that shouldn't require any special flags (neither --ad-hoc
> nor --pure).  The current default behavior of making an environment
> from package dependencies is because that's how nix-shell worked (or
> at least how I thought it worked) and 'guix environment' was created
> as a clone of that tool.
>
> - Dave

I was waiting for somebody to say this. But, I am 100% in agreement with
Dave as far as the behavior of --pure. I really would like to see either
nothing change, or we make --ad-hoc the implied default.

My reasoning confers with Dave's logic.

-- 
Brett M. Gilio
https://git.sr.ht/~brettgilio/

bug#38500: Ruby is built against libruby-static.a

[Brett Gilio]

I have submitted a patch that will go into core-updates, with bug report
#38552. That patch will close both of these bug reports.

Thanks.
-- 
Brett M. Gilio
https://git.sr.ht/~brettgilio/

bug#38568: Org Mode (as a dependency) is borked

[Brett Gilio]

Cc'ing Maxim since he is tasking the emacs-build-system changes. Sorry for 
duplicate I accidentally replied off list.

Brett Gilio

Dec 12, 2019 3:30:16 AM Konrad Hinsen :

> Hi Jelle,
> 
> 
> > Byte-compiling the org-jira.el file manually gives an .elc file without
> > a reference to `org-outline-overlay-data'. This leads me to believe that
> > the previously posted fix for #38479 could be extended to make sure
> > Emacs' built-in packages are at the trailing end of EMACSLOADPATH, so
> > after any other packages.
> > 
> 
> This looks indeed like a similar problem, but at the level of
> emacs-build-system rather than profile construction.
> 
> Cheers,
> Konrad.
> 

bug#38500: Ruby is built against libruby-static.a

[Brett Gilio]

Pushed to core-updates with fd248cb815d571043c3a0c52a01c9b3e368a069e.

Closing

-- 
Brett M. Gilio
Homepage -- https://scm.pw/
GNU Guix -- https://guix.gnu.org/

bug#38524: [PATCH] services: dhcp-client: Ignore interfaces that need non-free firmware.

[Brett Gilio]

This LGTM, though I'd add a comment noting this bug report or something so it 
is known why this behavior was adjusted.

Dec 13, 2019 3:57:14 PM Brice Waegeneire :

> * gnu/services/networking.scm (dhcp-client-service-type): Filter interfaces
> that need non-free firmware.
> ---
> gnu/services/networking.scm | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/gnu/services/networking.scm b/gnu/services/networking.scm
> index 93d9b6a15e..7a57e33974 100644
> --- a/gnu/services/networking.scm
> +++ b/gnu/services/networking.scm
> @@ -223,14 +223,14 @@ fe80::1%lo0 apps.facebook.com\n")
> (define valid?
> (lambda (interface)
> (and (arp-network-interface? interface)
> - (not (loopback-network-interface? interface)
> + (not (loopback-network-interface? interface))
> + ;; XXX: Make sure the interfaces are up so that
> + ;; 'dhclient' can actually send/receive over them.
> + (false-if-exception
> + (set-network-interface-up interface)
> (define ifaces
> (filter valid? (all-network-interface-names)))
> 
> - ;; XXX: Make sure the interfaces are up so that 'dhclient' can
> - ;; actually send/receive over them.
> - (for-each set-network-interface-up ifaces)
> -
> (false-if-exception (delete-file #$pid-file))
> (let ((pid (fork+exec-command
> (cons* #$dhclient "-nw"
> -- 
> 2.19.2
> 

bug#38613: Disabling bytecompilation on a list of files.

[Brett Gilio]

Hey all.

Just forwarding along an idea discussed between Leo Prikler, Tobias, and
I on IRC.

Recently I was trying to update our emacs-doom-themes package to a
fresher commit since it offers numerous new functionalities but there is
not a marked stable release of the package. In the process I found an
issue where some files have a bytecode compilation overflow issue during
the build phase. My sloppy work around as shown in
e9d8dee6c3d6e2ddff74841a3ab3a2ba2816bf27 was as such:

--8<---cut here---start->8---
;; XXX: There is a byte-code overflow issue in the latest
;; checkout which affects byte-compilation for several theme
;; files. The easiest way to work around this is to disable
;; byte-compilation until the issue is resolved.
;; 
(delete 'build)
--8<---cut here---end--->8---

Obviously just outright deleting the phase responsible for
bytecompilation is not the _best_ solution. So what Leo and I proposed
was adding a #:no-bytecomp which takes a list of REGEXP or files that
will be excluded from the in-place byte-compilation.

I wanted to float this idea by those of us who use the
emacs-build-system regularly.

Thanks!

-- 
Brett M. Gilio
Homepage -- https://scm.pw/
GNU Guix -- https://guix.gnu.org/

bug#38613: Disabling bytecompilation on a list of files.

[Brett Gilio]

Leo Prikler  writes:

> Hey Brett.
>
> Am Dienstag, den 14.12.2019, 13:45 -0600 schrieb Brett Gilio:
>> Just forwarding along an idea discussed between Leo Prikler, Tobias,
>> and I on IRC.
> Thanks for the mention ;)

Any time! :)

>
>> Obviously just outright deleting the phase responsible for
>> bytecompilation is not the _best_ solution. So what Leo and I
>> proposed
>> was adding a #:no-bytecomp which takes a list of REGEXP or files that
>> will be excluded from the in-place byte-compilation.
>> 
>> I wanted to float this idea by those of us who use the
>> emacs-build-system regularly.
> I actually came up with an alternative solution, that I already hinted
> at in IRC.  0001 implements a function to disable byte compilation for
> a single file, 0002 applies this to the package in question.  I'm not
> quite sure why the files are not writable and wonder, whether the chmod
> should be added into 0001, but keeping it out of it should hopefully
> prevent abuse.

I am not sure why the file permissions are needing to be set either. On
a git checkout it looks to me like they are the same as the others. I
wonder if it might have something to do with the rename-file method
moving the themes? Idk.

>
> It's rather late and this is just a proof of concept.  I haven't fully
> evaluated the impact this will have on Guix (specifically in the amount
> of rebuilds it will cause).  Also beware of my somewhat ill-formed
> commit messages.  After painfully checking each of the themes for this
> bug however (on my machine, YMMV), I did update the comment for what
> it's worth.

>
> Regards,
> Leo
>
> From 365f5c02876b51cf566224f60cd6d4c6b7023d66 Mon Sep 17 00:00:00 2001
> From: Leo Prikler 
> Date: Sun, 15 Dec 2019 00:45:08 +0100
> Subject: [PATCH 1/3] guix: emacs-utils: Add emacs-batch-disable-compilation.
>
> * guix/build/emacs-utils.scm (emacs-batch-disable-compilation):
> New procedure.
> ---
>  guix/build/emacs-utils.scm | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/guix/build/emacs-utils.scm b/guix/build/emacs-utils.scm
> index fdacd30dd6..2aa63c3363 100644
> --- a/guix/build/emacs-utils.scm
> +++ b/guix/build/emacs-utils.scm
> @@ -23,6 +23,7 @@
>#:export (%emacs
>  emacs-batch-eval
>  emacs-batch-edit-file
> +emacs-batch-disable-compilation
>  emacs-generate-autoloads
>  emacs-byte-compile-directory
>  emacs-substitute-sexps
> @@ -50,6 +51,12 @@
>(string-append "--visit=" file)
>(format #f "--eval=~S" expr)))
>  
> +(define (emacs-batch-disable-compilation file)
> +  (emacs-batch-edit-file file
> +'(progn
> +  (add-file-local-variable 'no-byte-compile t)
> +  (basic-save-buffer
> +
>  (define (emacs-generate-autoloads name directory)
>"Generate autoloads for Emacs package NAME placed in DIRECTORY."
>(let* ((file (string-append directory "/" name "-autoloads.el"))
> -- 
> 2.24.0
>
>
> From 3f376828d8970c0751b86aef0b49e256ee09287e Mon Sep 17 00:00:00 2001
> From: Leo Prikler 
> Date: Sun, 15 Dec 2019 00:49:26 +0100
> Subject: [PATCH 2/3] gnu: emacs-doom-themes: Only disable breaking
>  compilations.
>
> * gnu/packages/emacs-xyz.scm (emacs-doom-themes) [phases]:
> : Undelete it.
> : New phase.
> ---
>  gnu/packages/emacs-xyz.scm | 23 ++-
>  1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
> index 505594aa0d..1c06a9122d 100644
> --- a/gnu/packages/emacs-xyz.scm
> +++ b/gnu/packages/emacs-xyz.scm
> @@ -19803,6 +19803,10 @@ contrast and few colors.")
>(arguments
> `(#:tests? #t
>   #:test-command '("ert-runner")
> + #:modules ((guix build emacs-build-system)
> +(guix build utils)
> +(guix build emacs-utils)
> +(srfi srfi-1))
>   #:phases
>   (modify-phases %standard-phases
> (add-after 'unpack 'move-themes
> @@ -19813,12 +19817,21 @@ contrast and few colors.")
> (rename-file f (basename f)))
>   (find-files "./themes" ".*\\.el$"))
> #t))
> -   ;; XXX: There is a byte-code overflow issue in the latest
> -   ;; checkout which affects byte-compilation for several theme
> -   ;; files. The easiest way to work around this is to disable
> -   ;; byte-compilation until the issue is res

bug#38613: Disabling bytecompilation on a list of files.

[Brett Gilio]

Leo Prikler  writes:

> Regarding the impact, I think it should be fine if we commit this
> closely before or after #38619, since that probably forces all Elisp
> libraries to be rebuilt anyways (also CC'd Maxim to have a look at
> this).  Hopefully at least the doom-theme autoloads compile correctly. 
> WDYT?
>
> Leo
>

I am in agreement. Maxim, the ball is in your court. :)

-- 
Brett M. Gilio
Homepage -- https://scm.pw/
GNU Guix -- https://guix.gnu.org/

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Brett Gilio]

Dec 17, 2019 7:34:17 AM Kyle Meyer :

> G�bor Boskovits writes:
>
>
> > Konrad Hinsen ezt �rta (id?pont: 2019. dec.
> > 17., Ke 7:52):
> >
> [...]
>
> >
> > > How about a more drastic measure: deprecate "guix environment" and
> > > introduce a new subcommand with the desired new behaviour?
> > >
> > >
> > That is also the other option I was thinking about. Do you have any good
> > idea in mind as how to call it? Of course the classic guix environment2
> > comes to my mind, but it does not look very appealing to me.
> >
>
> Perhaps "guix env"?
>

+1 for guix env

bug#38685: emacs-calfw: Fails to build

[Brett Gilio]

Hi Ivan,

This should be fixed with c01483115951adcc4017682058dd170a983af610.

Thanks :).

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#38712: gnunet: wrong license

[Brett Gilio]

Dima  writes:

> The license is Affero GPL3+, not just GPL3+.
> https://git.gnunet.org/gnunet.git/tree/README

Hi Dima,

You are absolutely right. I did a check myself against the source tree
and confirmed this to be consistent.

This was fixed with 94cc994ee08f99b3aa7bf8da6b8dfd363539d6c4.

Thanks!

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#38613: Disabling bytecompilation on a list of files.

[Brett Gilio]

Maxim Cournoyer  writes:

> Hello,
>
> Leo Prikler 
>
> [...]
>
>> Regarding the impact, I think it should be fine if we commit this
>> closely before or after #38619, since that probably forces all Elisp
>> libraries to be rebuilt anyways (also CC'd Maxim to have a look at
>> this).  Hopefully at least the doom-theme autoloads compile correctly.
>> WDYT?
>>
>> Leo
>
> IIRC, emacs{-minimal} have about ~300 non-Elisp dependents, which IMO is
> OK for master (Elisp packages are very cheap to build, so I don't count
> them).
>
> I've just verified this with the following script:
>
> (use-modules (gnu packages)
>(guix graph)
>(guix monads)
>(guix packages)
>(guix store)
>(guix scripts graph)
>(guix scripts refresh)
>(gnu packages emacs)
>(srfi srfi-1)
>(srfi srfi-26))
>
> (define (all-packages)
>   "Return the list of all the distro's packages."
>   (fold-packages (lambda (package result)
>;; Ignore deprecated packages.
>(if (package-superseded package)
>result
>(cons package result)))
>  '()
>  #:select? (const #t)))
>
> (define (packages->dependents packages)
>
>   (define (full-name package)
> (string-append (package-name package) "@"
>  (package-version package)))
>
>   (with-store store
> (run-with-store store
>   (mlet %store-monad ((edges (node-back-edges
>   %bag-node-type
>   (package-closure (all-packages)
> (let ((dependents (node-transitive-edges packages edges)))
>   (return (map full-name dependents)))
>
> (define (compute-results)
>   (let* ((dependents (packages->dependents (list emacs emacs-minimal)))
>(non-emacs (remove (cut string-prefix? "emacs-" <>) dependents)))
> (format #t "Emacs{-minimal} have ~d dependents, ~d of which are not pure \
> Emacs libraries: ~a~%" (length dependents) (length non-emacs) non-emacs)))
>
> (compute-results)
>
> Which outputs:
>
> Emacs{-minimal} have 973 dependents, 274 of which are not pure Emacs
> libraries: (faust@2.5.23 cedille@1.1.1 cflow@1.6
> translate-shell@0.9.6.11 kicad@5.1.4 lepton-eda@1.9.5-20180820
> quadrapassel@3.31.3 eog-plugins@3.26.4 workrave@1.10.34 emacsy@0.4.1
> guile-gi@0.2.0 nomad@0.1.1-alpha emacsy-minimal@v0.4.1-19.f3bf0db
> evisum@0.2.6 enlightenment-wayland@0.23.1 terminology@1.5.0 ephoto@1.5
> enlightenment@0.23.1 econnman@1.1 python-efl@1.23.0 lekha@0.2.1
> python2-efl@1.23.0 edi@0.6.0 rage@0.3.1 dbus-c++@0.9.0
> [...]
>
> HTH,
>
> Maxim
>
>
>
>

Leo and Maxim,

Do you think this feature addition to the emacs-build-system is good to
be pushed, then? I think it looks quite fine but I want to double check
before potentially doing something dumb.

That said, we should probably also document this.

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#38357: babl-0.1.72 build failure (test failure) - dependency for gimp

[Brett Gilio]

Ludovic Courtès  writes:

> Hi,
>
> Tobias Geerinckx-Rice via Bug reports for GNU Guix 
> skribis:
>
>> Christopher Howard 写道：
>>> 22/25 alpha_symmetric_transform   FAIL 0.12 s (exit
>>
>> I've built master's babl a few times now, the damned thing keeps
>> succeeding:
>
> It failed on berlin:
>
>   https://ci.guix.gnu.org/log/qzz0qv5llrfb6ls8018yjkwg55lk26yk-babl-0.1.72
>
> So the test must be numerically unstable or something.
>
> Does upstream have patches or bug reports?
>
> Thanks,
> Ludo’.
>
>
>
>

This still looks like an on-going issue. I am where Tobias is at, I
can't reproduce this on my machine which lends me to believe you are
right, Ludo'.

Interestingly, the store object hashes are matching.

http://berlin.guixsd.org/log/qzz0qv5llrfb6ls8018yjkwg55lk26yk-babl-0.1.72

--8<---cut here---start->8---
22/25 alpha_symmetric_transform   FAIL 0.17 s (exit status 255 
or signal 127 SIGinvalid)
23/25 types   OK   0.12 s 
24/25 concurrency-stress-test OK   0.37 s 
25/25 palette-concurrency-stress-test OK   0.62 s 

Ok:   24
Expected Fail: 0
Fail:  1
Unexpected Pass:   0
Skipped:   0
Timeout:   0


The output from the failed tests:

22/25 alpha_symmetric_transform   FAIL 0.17 s (exit status 255 
or signal 127 SIGinvalid)

--- command ---
LD_LIBRARY_PATH='/tmp/guix-build-babl-0.1.72.drv-0/build/babl' 
GI_TYPELIB_PATH='/tmp/guix-build-babl-0.1.72.drv-0/build/babl' 
BABL_PATH='/tmp/guix-build-babl-0.1.72.drv-0/build/extensions' 
/tmp/guix-build-babl-0.1.72.drv-0/build/tests/alpha_symmetric_transform
--- stdout ---

--- stderr ---
../babl-0.1.72/babl/babl-internal.h:214 babl_log()
separate alpha 10.2: 10.007812500!=10.0(ref)  
../babl-0.1.72/babl/babl-internal.h:214 babl_log()
separate alpha 11.1: 4.996093750!=5.0(ref)  
../babl-0.1.72/babl/babl-internal.h:214 babl_log()
separate alpha 11.2: 49.96875!=50.0(ref)  
../babl-0.1.72/babl/babl-internal.h:214 babl_log()
associatd-alpha 10.2: 10.007812500!=10.0(ref)  
../babl-0.1.72/babl/babl-internal.h:214 babl_log()
associatd-alpha 11.1: 4.992187500!=5.0(ref)  
../babl-0.1.72/babl/babl-internal.h:214 babl_log()
associatd-alpha 11.2: 49.93750!=50.0(ref)  
---

Full log written to 
/tmp/guix-build-babl-0.1.72.drv-0/build/meson-logs/testlog.txt
FAILED: meson-test 
--8<---cut here---end--->8---

Perhaps we should work around the singular failing test-case and open a
report upstream to include in a comment?

Wdyt?

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#35552: Dead Link

[Brett Gilio]

David Kleuker  writes:

> Hello, 
>
> the link "as its name suggests" on 
> https://www.gnu.org/software/guix/blog/2018/tarballs-the-ultimate-container-image-format/
>
>
> points to  
> https://www.gnu.org/software/tar/manual/en/html_node/Introduction.html 
>
> which shows 404 
>
> congratulations for guix 1.0 btw! 
>
> kind regards 
> davidak 
> (a NixOS user) 
>

Amin,

This sounds like something we should be able to take care of with the
Webmastering team. Perhaps we should open an RT ticket?

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#33278: failed build of webkit

[Brett Gilio]

David Larsson  writes:

> On Mon, 5 Nov 2018, Leo Famulari wrote:
>
>> On Mon, Nov 05, 2018 at 09:13:31PM +0100, david.lars...@selfhosted.xyz wrote:
>>> I ran:
>>> sudo -E guix system reconfigure "$cfg" --no-grub
>>> --substitute-urls="https://mirror.guixsd.org
>>> https://mirror.hydra.gnu.org https://berlin.guixsd.org"; --cores=1
>>> 2>&1 | sudo tee -a "$log"
>>>
>>> It built lots of packages successfully but failed on webkit.
>>
>> Okay, can you send the entire log (xz compressed, please)? I can't tell
>> what package is failing to build.
>>
> Not sure where to find the xz-compressed file but I found the bz2 one.
> --
> Vänliga hälsningar / Best Regards
>
>

As best as I can tell, this bug report is no longer relevant. Please
feel free to re-open if I am mistaken.

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#33397: "guix environment" does not warn about stopped jobs

[Brett Gilio]

swedebugia  writes:

> Hi
>
> I use emacs in a terminal to hack on packages.
> I start an emacs, press C-z to pause it after trying something
> in bash I then build the package from the source tree
> press fg to return to emacs
> and so forth.
>
> Typing guix environment will enter a new environment where apparently
> my paused emacs is not available.
>
> Is this a bug?
> Probably not.
>
> Should we make guix environment warn/refuse to create the env. if
> stopped jobs exist?
>
> Yes, I think so.
>
> What do you think?

This is not a bug, as far as I can tell. Especially with the recent
proposed and adopted changes to how jobs function in `guix environment`
you might have better luck with this issue now.

I am closing this in the mean time, but feel free to open a /new/ bug
report documenting the expected and true behaviors if you wish.

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#33772: StumpWM broken commands?

[Brett Gilio]

Pierre Langlois  writes:

> Christopher Lemmer Webber writes:
>
>> Christopher Lemmer Webber writes:
>>
>>> Pierre Langlois writes:
>>>
 Alex Kost writes:

> I have built stumpwm from the latest commit (which is one commit after
> 18.11 release) and tried it on GuixSD and on ArchLinux.  Works for me
> on both systems, so it's probably not an upstream bug.

 Hi Alex,

 I was investigating just now and thought I'd try that one commit that
 was pushed after the release. The description doesn't sound like it
 would fix the problem but it was easy to try that.  But it looks like it
 does fix the problem!

 Can you confirm the attached patch works for you?

>>> I haven't tried it yet but it makes a lot of sense that this would fix
>>> it.  Both gnew and eval interactively pull up a request for a line of
>>> input.
>>
>> I applied your patch to my machine and it fixed it... thank you!  I
>> pushed the patch upstream to guix master.
>
> Awesome, thanks!
> Pierre
>
>
>
>
>

Hey everybody,

Evan Straw and I removed this patch in
9beec2173f9243456b6aca470acd926d0dcf9b45 with an upgrade to StumpWM
19.11 which fixes this issue.
As such I am closing this bug.

Let me know if 19.11 is working for you all, though!

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#38608: enable --fallback for the guix graphical installer

[Brett Gilio]

Nathan Dehnel  writes:

> I can't install guix because I keep getting substitute download errors.
>
> It's really punishing having to restart the install process after a
> download error.
>

I actually don't know how our installer works that well, so I am going
to leave the issue of whether to default to `--fallback` is the right
decision to somebody else.

However, for anybody reading this: does our installer dump logs
anywhere? That seems like a more useful bit of information so we can
triage and possibily fix why you are not receiving substitutes.

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#38739: i3-gaps package is misbehaving

[Brett Gilio]

Dec 25, 2019 2:30:12 AM Sergiu Marton :

> I submitted a patch to add i3-gaps a couple days ago:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38721
>
> After it got merged into master with the inheritance modification (see
> patch), I installed it over the one I had installed from my original
> script and it seemed to work fine. But I think that's just because I
> didn't reboot to restart the i3 executable.
>
> Now that I shutdown and opened my machine again, i3-gaps specific
> commands don't work... To test this, write `i3-msg gaps` in a shell.
> If it does NOT work, it will output something like:
>
> brown@121407 ~$ i3-msg gaps
> ERROR: Your command: gaps
> ERROR: 
> ERROR: Expected one of these tokens: > represent valid commands>
>
> However, it seems that gaps work if I remove the package, install it
> from the original package definition (without Brett's (inherit i3-wm))
> and reboot. The following output means that i3-gaps has been correctly
> installed:
>
> brown@121407 ~$ i3-msg gaps
> ERROR: Your command: gaps
> ERROR:
> ERROR: Expected one of these tokens: 'inner', 'outer', 'horizontal',
> 'vertical', 'top', 'right', 'bottom', 'left'
>
> This is strange. I still don't know enough about the packaging API to
> troubleshoot this all just by having a quick look at i3-gaps'
> definition. I'll try to investigate this issue but I encourage someone
> more knowledgeable than me too look into this too.
>

Hi Sergiu,

Thank you for opening a new bug report at my request. As best as I can tell, 
the inherited arguments and your proposed package arguments without inheritance 
match 1:1. Tomorrow when I am at my computer I will introspect this further 
using the REPL.

If somebody else beats me to this, great! Hopefully we can get this figured 
out, it is probably some silly issue I just overlooked.

Thanks!

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
< bre...@gnu.org [mailto:bre...@gnu.org] > < bre...@posteo.net 
[mailto:bre...@posteo.net] >

bug#38613: Disabling bytecompilation on a list of files.

[Brett Gilio]

Maxim Cournoyer  writes:

> Brett Gilio  writes:
>
>
> [...]
>
>> Leo and Maxim,
>>
>> Do you think this feature addition to the emacs-build-system is good to
>> be pushed, then? I think it looks quite fine but I want to double check
>> before potentially doing something dumb.
>
> LGTM!
>
> Thank you!
>
> Maxim
>

Done! Thank you Leo and Maxim.

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#38804: Samsung Chromebook 3

[Brett Gilio]

Dec 29, 2019 8:03:39 PM Caleb Herbert :

> I tried running the Guix System installer on my Chromebook. I wanted to
> try replacing GalliumOS.
>
> Unsurprisingly, I get many errors do to proprietary firmware. My
> keyboard doesn't work, so I can't check what all the messages said, and
> I can go no further with the installation.
>
> Model
> Samsung Chromebook 3
>
> Hardware ID
> CELES
>
> Year
> 2016
>
> Processor
> Intel Braswell
>
> It's supported by GalliumOS, but there are multiple issues:
>
> CELES (Samsung Chromebook 3) This model has been problematic for many
> users, but it has also been perfectly successful for others, We haven't
> been able to find the differences that separate these two groups, so we
> do not recommend CELES. If you already own a CELES, and would like to
> try GalliumOS, give it a shot! You might be one of the lucky ones.
> However, if you are looking to purchase a Chromebook with the intention
> of running GalliumOS, we strongly suggest choosing a different model.
>
> https://wiki.galliumos.org/Hardware_Compatibility#cite_note-CELES-22
>


Hey Caleb,

Thanks for the report! I don't have much to say other than I suspect that this 
is going to have to be resolved by somebody reverse-engineering the proprietary 
components and releasing them as free software.

Maybe I am wrong though, so I will let somebody else take over from here. :)

Best!

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
< bre...@gnu.org [mailto:bre...@gnu.org] > < bre...@posteo.net 
[mailto:bre...@posteo.net] >

bug#38959: Adding Coq 8.10.1 for Int63.Ring63 and Coq-Bignums

[Brett Gilio]

Hey all, and particularly the FM-Guix working group. I'd like to get Coq
8.10.1 into Guix as it provides support for the new Int63.Ring63 theory
number library. This would be immensely helpful in getting the
coq-bignums package up-to-date with some neat new tactics. I know that
the CoqIDE package now has an explicit dependency on lablgtk3 from
OCaml. Both Coq 8.10.1 and lablgtk3 exist on Julien's (cc) channel, but
I want to run the idea by Julien and others before possibly integrating
a new Coq into our repository.

We should be extra cautious when doing
this, as there is quite possibly some Coq packages that /do not/ run
against coqtop from a newer Coq version. So we very well may have to
make the newer Coq along side an existing version.

That's all, let me know what you think.

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#38943: libtgvoip fails to build on armhf-linux

[Brett Gilio]

Diego Nicola Barbato  writes:

> Hi Guix,
>
> The package libtgvoip (introduced with commit 494135d) fails to build on
> armhf-linux [0].  This bug appears to have been fixed upstream [1].
>
> Regards,
>
> Diego
>
> [0]: 
> https://ci.guix.gnu.org/log/q4j5kzz25j2knf0vhm8i0bd3g14anv8m-libtgvoip-2.4.2
> [1]: 
> https://github.com/zevlg/libtgvoip/commit/5efda7ac165ece0aee894ed8dd88f12a7ca0582d
>


Hi Diego,

Thank you for reporting this. I think I have fixed it, but it will take
some time to cross-compile on my machine to confirm this. I basically
changed upstream source from the fork to the original, and took the
newer release. I will report back with my findings, or a push to master
once I confirm.

Thanks!

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#38943: libtgvoip fails to build on armhf-linux

[Brett Gilio]

Brett Gilio  writes:

> Diego Nicola Barbato  writes:
>
>> Hi Guix,
>>
>> The package libtgvoip (introduced with commit 494135d) fails to build on
>> armhf-linux [0].  This bug appears to have been fixed upstream [1].
>>
>> Regards,
>>
>> Diego
>>
>> [0]: 
>> https://ci.guix.gnu.org/log/q4j5kzz25j2knf0vhm8i0bd3g14anv8m-libtgvoip-2.4.2
>> [1]: 
>> https://github.com/zevlg/libtgvoip/commit/5efda7ac165ece0aee894ed8dd88f12a7ca0582d
>>
>
>
> Hi Diego,
>
> Thank you for reporting this. I think I have fixed it, but it will take
> some time to cross-compile on my machine to confirm this. I basically
> changed upstream source from the fork to the original, and took the
> newer release. I will report back with my findings, or a push to master
> once I confirm.
>
> Thanks!

Hi Diego, I confirmed that cross-compilation with commit
5a0d73911c93745391a687def9ba8c7d0d41be23 succeeds. Closing! Thanks!


-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#38944: libtgvoip fails to build on i686-linux

[Brett Gilio]

Diego Nicola Barbato  writes:

> Hi Guix,
>
> The package libtgvoip (introduced with commit 494135d) fails to build on
> i686-linux [0].  Since this appears to be related to SSE2 these two
> Debian patches [1] [2], which disable SSE2 on i386 (the first patch does
> something unrelated, but it's required for the second one to apply),
> should fix it.
>
> Regards,
>
> Diego
>
> [0]: 
> https://ci.guix.gnu.org/log/drp47myv1fv6a3scd2rz177yp5b89dp0-libtgvoip-2.4.2
> [1]:
> https://sources.debian.org/patches/libtgvoip/2.4.4-2/Fix-WebRTC-for-non-Linux.patch/
> [2]: https://sources.debian.org/patches/libtgvoip/2.4.4-2/Disable-SSE2.patch/
>
>
>
>

Hi Diego! Thanks again for reporting this issue! I have pushed a
revision upstream with 1792a70655507625cbe654a0eec1428f210d2fd3 that
should fix this issue!

Closing.

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#38959: Adding Coq 8.10.1 for Int63.Ring63 and Coq-Bignums

[Brett Gilio]

Julien Lepiller  writes:

> Le 5 janvier 2020 18:04:16 GMT-05:00, Brett Gilio  a écrit :
>>Hey all, and particularly the FM-Guix working group. I'd like to get
>>Coq
>>8.10.1 into Guix as it provides support for the new Int63.Ring63 theory
>>number library. This would be immensely helpful in getting the
>>coq-bignums package up-to-date with some neat new tactics. I know that
>>the CoqIDE package now has an explicit dependency on lablgtk3 from
>>OCaml. Both Coq 8.10.1 and lablgtk3 exist on Julien's (cc) channel, but
>>I want to run the idea by Julien and others before possibly integrating
>>a new Coq into our repository.
>>
>>We should be extra cautious when doing
>>this, as there is quite possibly some Coq packages that /do not/ run
>>against coqtop from a newer Coq version. So we very well may have to
>>make the newer Coq along side an existing version.
>>
>>That's all, let me know what you think.
>
> We don't have too many coq packages, so when updating coq I've always
> built them all and checked they were ok. I think coq 8.10 was released
> for enough time for upstream to update their code base. We should give
> it a try. I can work on this tomorrow and report my findings if you
> like. Or you could take care of it if you prefer :)
>
> I'd prefer to have only one version of coq in guix, but if we need two of 
> them, so be it. Let's make sure we duplicate other coq packages in that case.
>

I should have some time tonight. I will give it a shot and open a patch
series, and report back the bug number here. :)

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#38959: Adding Coq 8.10.1 for Int63.Ring63 and Coq-Bignums

[Brett Gilio]

Brett Gilio  writes:

> Julien Lepiller  writes:
>
>> Le 5 janvier 2020 18:04:16 GMT-05:00, Brett Gilio  a écrit :
>>>Hey all, and particularly the FM-Guix working group. I'd like to get
>>>Coq
>>>8.10.1 into Guix as it provides support for the new Int63.Ring63 theory
>>>number library. This would be immensely helpful in getting the
>>>coq-bignums package up-to-date with some neat new tactics. I know that
>>>the CoqIDE package now has an explicit dependency on lablgtk3 from
>>>OCaml. Both Coq 8.10.1 and lablgtk3 exist on Julien's (cc) channel, but
>>>I want to run the idea by Julien and others before possibly integrating
>>>a new Coq into our repository.
>>>
>>>We should be extra cautious when doing
>>>this, as there is quite possibly some Coq packages that /do not/ run
>>>against coqtop from a newer Coq version. So we very well may have to
>>>make the newer Coq along side an existing version.
>>>
>>>That's all, let me know what you think.
>>
>> We don't have too many coq packages, so when updating coq I've always
>> built them all and checked they were ok. I think coq 8.10 was released
>> for enough time for upstream to update their code base. We should give
>> it a try. I can work on this tomorrow and report my findings if you
>> like. Or you could take care of it if you prefer :)
>>
>> I'd prefer to have only one version of coq in guix, but if we need two of 
>> them, so be it. Let's make sure we duplicate other coq packages in that case.
>>
>
> I should have some time tonight. I will give it a shot and open a patch
> series, and report back the bug number here. :)

Moving conversation to bugs.gnu.org/38965. Closing.

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

bug#42447: Issue with CGIT service

[Brett Gilio]

Hi all,

I am having an issue with the CGIT service. There is a record field for
setting the directory it should watch, defaulting to /srv/cgit or
something similar. Currently when doing this it just returns an empty
cgit web interface.

--8<---cut here---start->8---
(service cgit-service-type
  (cgit-configuration
   (enable-commit-graph? #t)
   (enable-html-serving? #t)
   (repository-directory
(string-append home-directory "/Repos/"))
   (nocache? #t)
   (readme "CGIT README")))
--8<---cut here---end--->8---

Also, I would also be willing to collaborate with
somebody on getting cgit and nginx to work together to set a port other
than 80.

Thoughts?

Brett Gilio

bug#42448: Issue with Qemu Binfmt and CMake not detecting compiler.

[Brett Gilio]

Hey all,

Opening a bug report as per a request following this issue identified
at: https://lists.gnu.org/archive/html/guix-devel/2020-07/msg00124.html.

To recap, when running

--8<---cut here---start->8---
./pre-inst-env guix build --system=armhf-linux swi-prolog
--8<---cut here---end--->8---

the configure phase is failing to identify the C/CXX compiler
toolchains to compile a test CMake file. There is a variety of
CMakeError.log and other object outputs that populate the build
directory when ran with --keep-failed.

This seems to be reported before, but subsequently patched at
https://issues.guix.gnu.org/38454#3. This only occurs when using the
Qemu method of compiling on a foreign architecture, and is not present
when natively compiling on true hardware.

Thanks,
Brett Gilio

bug#42448: A possible solution

[Brett Gilio]

As Marius Bakke pointed out on IRC, this issue is related to a change in
CMake where after 3.15 they removed the explicit `#define
_FILE_OFFSET_BITS 64`. The solution solution to this is to add

--8<---cut here---start->8---
CFLAGS="-D_FILE_OFFSET_BITS=64"
CXXFLAGS="-D_FILE_OFFSET_BITS=64"
--8<---cut here---end--->8---

to CMakes compilation procedure. This is a core-updates change. I will
leave this issue open for now in case this needs more
investigation. Since I am just coming off of a haitus I think there are
changes to the core-updates and staging procedures so I dont think I am
comfortable making this change myself.

Brett Gilio

bug#42434: Shell can't find basic system tools after massive garbage collection

[Brett Gilio]

Alexandru-Sergiu Marton  writes:

> Hi,
>
> I run Guix System on my laptop and I wanted to free some space so I ran
> all the cleaning stuff I could think of:
>
> guix package --delete-generations
> guix gc --delete-generations
> sudo guix system delete-generations
>
> After running them all, I had troubles using some of the most basic
> tools, like ls or rm. Other programs seemed fine (make, gcc, guix) as I
> could compile my builds of dwm and st.
>
> After I ran `guix system reconfigure` and I made sure my profile
> contains all the software I need at the latest version by running `guix
> package -m` on my manifest, everything went back to normal -- I could
> use ls and rm again.
>
> Sadly, I didn't gather more information as I didn't experiment much with
> the broken system because I freaked out and tried to fix it as fast as
> possible.
>
> I don't know what to make of this. Brett Gilio suggested it may have
> been a bad symlink job.
>
> Cheers,
> Sergiu

I haven't investigated this myself, but on more thought it may also have
to do with some outdated environment variables. Did you happen to reboot
your computer or restart your X/Wayland session anytime after deleting
the old generations and running the garbage collector?

Brett Gilio

bug#42333: Emacs: error on guix-emacs-autoload-packages

[Brett Gilio]

Alexandru-Sergiu Marton  writes:
>
> (mapc (lambda (p) (add-load-path! p)) (split-string (getenv "EMACSLOADPATH") 
> ":"))
>

Are you still needing to use this snippet to get your configuration to work?

bug#42523: ‘Latest’ ISO download link broken

[Brett Gilio]

Tobias Geerinckx-Rice via Bug reports for GNU Guix 
writes:

> Guix,
>
> ‘Download latest images’[0] points to [1], which returns a JSON:
>
>> {"error":"Could not find the request build product."}
>
> There are plenty[2] to choose from.
>
> Kind regards,
>
> T G-R
>
> [0]: http://guix.gnu.org/download/latest/
> [1]:
> https://ci.guix.gnu.org/search/latest/ISO-9660?query=spec:guix-master+status:success+system:x86_64-linux+iso9660-image
> [2]: https://ci.guix.gnu.org/search?query=iso9660

The latest run of the CI for some reason didn't produce an ISO build
output. Strange. Who is in charge of our CI?

bug#40408: emacs-telega: VoIP doesn't work

[Brett Gilio]

Diego Nicola Barbato  writes:

> Hi,
>
> Leo Famulari  writes:
>
>> On Fri, Apr 03, 2020 at 06:12:16PM +0200, Diego Nicola Barbato wrote:
>>> The following error messages in .telega/telega-voip.log seem relevant:
>>> 
>>> --8<---cut here---start->8---
>>> 04-01 20:04:04 E: Error loading libpulse: (null)
>>> 04-01 20:04:04 E: Error loading libasound: (null)
>>> 04-01 20:04:04 E: Error loading libasound: (null)
>>> 04-01 20:04:04 E: Error initializing audio playback
>>> --8<---cut here---end--->8---
>>
>> I'd guess those libraries should be dependencies of this package. I
>> would move it to the telephony module as well.
>
> Turns out the libraries are dependencies of libtgvoip.  It tries to
> dlopen them, but doesn't find them.  I've attached a patch to fix that.
> Unfortunately VoIP still doesn't work in Telega (it still fails in the
> same way as before, except that there are no more error messages in
> .telega/telega-voip.log).  It looks like that's a separate, unrelated
> issue.
>
> Regards,
>
> Diego
>
>>From f63cf832869bee91f3f6e87c076bd1e39d32c285 Mon Sep 17 00:00:00 2001
> From: Diego Nicola Barbato 
> Date: Sat, 4 Apr 2020 19:36:31 +0200
> Subject: [PATCH] gnu: libtgvoip: Fix loading of shared libraries.
>
> Fixes <https://debbugs.gnu.org/40408>.
>
> * gnu/packages/telephony.scm (libtgvoip)[arguments]<#:phases>[patch-dlopen]:
>   New phase.
> ---
>  gnu/packages/telephony.scm | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/gnu/packages/telephony.scm b/gnu/packages/telephony.scm
> index f64cdd3fb2..f73efb0deb 100644
> --- a/gnu/packages/telephony.scm
> +++ b/gnu/packages/telephony.scm
> @@ -1046,6 +1046,23 @@ This package provides the Jami client for the GNOME 
> desktop.")
> ("libopusenc" ,libopusenc)
> ("openssl" ,openssl)
> ("pulseaudio" ,pulseaudio)))
> +(arguments
> + `(#:phases
> +   (modify-phases %standard-phases
> + ;; libtgvoip wants to dlopen libpulse and libasound, so tell it 
> where
> + ;; they are.
> + (add-after 'unpack 'patch-dlopen
> +   (lambda* (#:key inputs #:allow-other-keys)
> + (substitute* "os/linux/AudioPulse.cpp"
> +   (("libpulse\\.so")
> +(string-append (assoc-ref inputs "pulseaudio")
> +  "/lib/libpulse.so")))
> + (substitute* '("os/linux/AudioInputALSA.cpp"
> +"os/linux/AudioOutputALSA.cpp")
> +   (("libasound\\.so")
> +(string-append (assoc-ref inputs "alsa-lib")
> +   "/lib/libasound.so")))
> + #t)
>  (synopsis "VoIP library for Telegram clients")
>  (description "A collection of libraries and header files for implementing
>  telephony functionality into custom Telegram clients.")


Hi all,

I apologize for the late response to this message. When it was sent I
was on haitus.

I am a co-maintainer for emacs-telega upstream along with Evgeny
Zajcev. Currently the functionality for VoIP is broken, and has been
disabled in the emacs-telega package for the time being. However, I
believe you have patched a bug with the libtgvoip package that caused
erroneous linkage to the system libraries on foreign distributions
causing a runtime issue with the telega server. So, I will investigate
your patch, and apply it so that when the time comes and VoIP
functionality is re-enabled we can prevent this issue!

Thank you,

I will forward this along to Evgeny as well.

Brett Gilio

bug#40408: emacs-telega: VoIP doesn't work

[Brett Gilio]

Diego Nicola Barbato  writes:

>
>>From f63cf832869bee91f3f6e87c076bd1e39d32c285 Mon Sep 17 00:00:00 2001
> From: Diego Nicola Barbato 
> Date: Sat, 4 Apr 2020 19:36:31 +0200
> Subject: [PATCH] gnu: libtgvoip: Fix loading of shared libraries.
>
> Fixes .
>
> * gnu/packages/telephony.scm (libtgvoip)[arguments]<#:phases>[patch-dlopen]:
>   New phase.
> ---
>  gnu/packages/telephony.scm | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/gnu/packages/telephony.scm b/gnu/packages/telephony.scm
> index f64cdd3fb2..f73efb0deb 100644
> --- a/gnu/packages/telephony.scm
> +++ b/gnu/packages/telephony.scm
> @@ -1046,6 +1046,23 @@ This package provides the Jami client for the GNOME 
> desktop.")
> ("libopusenc" ,libopusenc)
> ("openssl" ,openssl)
> ("pulseaudio" ,pulseaudio)))
> +(arguments
> + `(#:phases
> +   (modify-phases %standard-phases
> + ;; libtgvoip wants to dlopen libpulse and libasound, so tell it 
> where
> + ;; they are.
> + (add-after 'unpack 'patch-dlopen
> +   (lambda* (#:key inputs #:allow-other-keys)
> + (substitute* "os/linux/AudioPulse.cpp"
> +   (("libpulse\\.so")
> +(string-append (assoc-ref inputs "pulseaudio")
> +  "/lib/libpulse.so")))
> + (substitute* '("os/linux/AudioInputALSA.cpp"
> +"os/linux/AudioOutputALSA.cpp")
> +   (("libasound\\.so")
> +(string-append (assoc-ref inputs "alsa-lib")
> +   "/lib/libasound.so")))
> + #t)
>  (synopsis "VoIP library for Telegram clients")
>  (description "A collection of libraries and header files for implementing
>  telephony functionality into custom Telegram clients.")

This patch was applied in 580414376b03f2430050f8b5405631f4d7e7e8e3. Closing.