bug#64653: works now

[Matt Wette]

This bug no longer occurs on my system.   That change occurred over the 
last week.

bug#64653: stopping ntp and dnsmasq

[Matt Wette]

On 9/17/23 9:42 AM, Matt Wette wrote:
Are there any workarounds for this.   I've been digging into anything 
to help.
I'm dead in the water trying to get ntpd and tftpd (dnsmasq) working.  
They require this.

Or, is there a way to get dnsmasq working itself?


I see there is atftp, so I'll try that.   Still no working ntpd.

bug#64653: stopping ntp and dnsmasq

[Matt Wette]

Are there any workarounds for this.   I've been digging into anything to 
help.
I'm dead in the water trying to get ntpd and tftpd (dnsmasq) working.  
They require this.

Or, is there a way to get dnsmasq working itself?

Matt

bug#49230: please update description for package nyacc

[Matt Wette]

On 6/26/21 6:13 AM, Tobias Geerinckx-Rice wrote:

Matt Wette 写道：

Could you please remove the "should be considered not stable" language
from the description of the nyacc package?


Thanks for reporting this, and thanks for nyacc!

Guix ships four distinct versions of nyacc:

 nyacc 0.86
 nyacc 0.99
 nyacc 1.00.2, and
 nyacc 1.04.0 (the default).

This still holds true on the current core-updates branch.

I'd expect the warning to be accurate for the 0.x series, but maybe 
they turned out to be more stable than expected :-)


Which version(s) of nyacc have ‘stable syntax and nomenclature’, and 
which (if any) did not?

Kind regards,

T G-R


>= 1.00 is a good breaking point.   Thanks for doing this. -- Matt

bug#49230: please update description for package nyacc

[Matt Wette]

Hi All,

Could you please remove the "should be considered not stable" language from the 
description of the nyacc package?
The current text on the website (https://www.nongnu.org/nyacc) is the following 
gist:


NYACC, for Not Yet Another Compiler Compiler, is set of guile modules for
generating parsers and lexical analyzers.  It also provides sample parsers,
pretty-printers using SXML trees as an intermediate representation, a decent
C parser and a `FFI Helper' tool to help create Guile Scheme bindings for
C-based libraries.

Thanks,
Matt

bug#39511: github auth

[Matt Wette]

On 2/22/20 2:52 AM, Ludovic Courtès wrote:

Hi Matt,

Matt Wette  skribis:


I have not gotten into testing, but according to email and references
provided previously the patch below might work.

I’ve applied the patch on your behalf, thank you!

Ludo’.



much appreciated

Matt

bug#39511: udpate

[Matt Wette]

oops:  `(Auth ...) => (list `(Auth...))

bug#39511: github auth

[Matt Wette]

I have not gotten into testing, but according to email and references
provided previously the patch below might work.


--- github.scm-orig    2020-02-15 10:32:52.209481329 -0800
+++ github.scm    2020-02-15 10:40:36.958144491 -0800
@@ -154,14 +154,12 @@
 ;; Ask for version 3 of the API as suggested at
 ;; .
 `((Accept . "application/vnd.github.v3+json")
+  ,@(if (%github-token)
+    `(Authorization . ,(string-append "token " (%github-token)))
+    '())
   (user-agent . "GNU Guile")))

-  (define (decorate url)
-    (if (%github-token)
-    (string-append url "?access_token=" (%github-token))
-    url))
-
-  (match (json-fetch (decorate release-url) #:headers headers)
+  (match (json-fetch release-url #:headers headers)
 (#()
  ;; We got the empty list, presumably because the user didn't use 
GitHub's

  ;; "release" mechanism, but hopefully they did use Git tags.

bug#39511: github tokens being deprecated

[Matt Wette]

$ guix refresh
...
Backtrace:
  12 (apply-smob/1 #)
In ice-9/boot-9.scm:
    705:2 11 (call-with-prompt _ _ #)
In ice-9/eval.scm:
    619:8 10 (_ #(#(#)))
In guix/ui.scm:
  1808:12  9 (run-guix-command _ . _)
In ice-9/boot-9.scm:
    829:9  8 (catch _ _ # ?)
    829:9  7 (catch _ _ # ?)
In guix/store.scm:
   625:10  6 (call-with-store _)
  1848:24  5 (run-with-store # ?)
In guix/scripts/refresh.scm:
   541:14  4 (_ _)
In srfi/srfi-1.scm:
    640:9  3 (for-each # ?)
In guix/scripts/refresh.scm:
    344:2  2 (check-for-package-update # ?)
In guix/import/github.scm:
   237:25  1 (latest-release #)
In unknown file:
   0 (scm-error misc-error #f "~A" ("Error downloading rel?") ?)

ERROR: In procedure scm-error:
Error downloading release information through the GitHub
API. This may be fixed by using an access token and setting the environment
variable GUIX_GITHUB_TOKEN, for instance one procured from
https://github.com/settings/tokens


after github token acquired:

$ guix refresh
...
guix refresh: warning: input 'Carp' of perl-xml-compile is in Perl core
gnu/packages/xml.scm:1113:13: tinyxml2 would be upgraded from 7.0.1 to 7.1.0
following redirection to 
`https://api.github.com/repositories/7715820/releases?access_token=728ec76dc9ea4344b57ba6be86674ed9e0135090'...
gnu/packages/xdisorg.scm:1731:13: python-pyperclip would be upgraded 
from 1.6.4 to 1.7.0



and then an email from github.com:

Hi @mwette,

On February 8th, 2020 at 14:37 (UTC) your personal access token (guix/bluefin) 
using GNU Guile was used as part of a query parameter to access an endpoint 
through the GitHub API:

https://api.github.com/repositories/32202720/releases

Please use the Authorization HTTP header instead, as using the `access_token` 
query parameter is deprecated and will be removed July 1st, 2020.

Depending on your API usage, we'll be sending you this email reminder once 
every 3 days for each token and User-Agent used in API calls made on your 
behalf.
Just one URL that was accessed with a token and User-Agent combination will be 
listed in the email reminder, not all.

Visithttps://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/#authenticating-using-query-parameters
  for more information.

Thanks,
The GitHub Team

bug#39377: guix search reports bad location for bytestructures

[Matt Wette]

I'm using guix-1.0.1 on Fedora 30, x86_64.

I wanted to get module spec for bytestructures, but failed:
location points to (guix packages), but it's actually in (gnu packages 
guile).


$ guix search bytestructures
name: guile3.0-bytestructures
version: 1.0.7
outputs: out
systems: x86_64-linux i686-linux
dependencies: autoconf@2.69 automake@1.16.1 guile-next@3.0.0 
pkg-config@0.29.2

location: guix/packages.scm:880:11
homepage: https://github.com/TaylanUB/scheme-bytestructures
license: GPL 3+
synopsis: Structured access to bytevector contents for Guile
description: Guile bytestructures offers a system imitating the type 
system of
+ the C programming language, to be used on bytevectors.  C's type 
system works
+ on raw memory, and Guile works on bytevectors which are an abstraction 
over
+ raw memory.  It's also more powerful than the C type system, elevating 
types

+ to first-class status.
relevance: 6

$ guix repl
scheme@(guix-user)> guile3.0-bytestructures
;;; : warning: possibly unbound variable 
`guile3.0-bytestructures'

ERROR: error: guile3.0-bytestructures: unbound variable

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guix-user) [1]> ,use (gnu packages guile)
scheme@(guix-user) [1]> guile3.0-bytestructures
$1 = #7f639f9532c0>

bug#39172: SElinux guix-daemon.cil file

[Matt Wette]

On 1/27/20 1:50 PM, Ludovic Courtès wrote:

Hello,

Ricardo Wurmus  skribis:


Could we also do this in one expression?

 (typeattributeset file_type (or guix_profiles_t
 guix_daemon_conf_t
 guix_daemon_exec_t
 guix_daemon_socket_t
 guix_store_content_t))

I also think we need to declare our use of “file_type” first:

 (typeattribute file_type)

What do you think?

Matt, does what Ricardo proposes work for you?



I can add that and see if it helps.  I am just coming up to speed on this.

There are other changes I may be proposing.
Note that use of

    (block guix_daemon
        ... guix_daemon_conf_t
    )

results in the type guix_daemon.guix_daemon_conf_t.   According to

    https://github.com/SELinuxProject/cil/wiki

the convention is something like the following, with added typealias

 (block guix
   ... daemon_conf
     )

    (typealias guix.daemon_conf guix_daemon_conf_t)

bug#39194: help for non-root users to start using

[Matt Wette]

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#39172: SElinux guix-daemon.cil file

[Matt Wette]

Hi All,

I appologize for the formatting.  I use tbird and I can't find a way to 
do plain-text mode.


I'm trying to get guix-1.0.1 running on Fedora-30 with its default 
SElinux set up.
I found (hint from 
https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00109.html)
that the guix-daemon.cil file seems to be missing a few items. Without 
this patch

    # restorecon -R /gnu/store
fails.

--- guix-daemon.cil.orig    2020-01-18 07:08:12.905986299 -0800
+++ guix-daemon.cil    2020-01-18 07:09:49.765737261 -0800
@@ -34,14 +34,19 @@
   (roletype object_r guix_daemon_t)
   (type guix_daemon_conf_t)
   (roletype object_r guix_daemon_conf_t)
+  (typeattributeset file_type guix_daemon_conf_t)
   (type guix_daemon_exec_t)
   (roletype object_r guix_daemon_exec_t)
+  (typeattributeset file_type guix_daemon_exec_t)
   (type guix_daemon_socket_t)
   (roletype object_r guix_daemon_socket_t)
+  (typeattributeset file_type guix_daemon_socket_t)
   (type guix_store_content_t)
   (roletype object_r guix_store_content_t)
+  (typeattributeset file_type guix_store_content_t)
   (type guix_profiles_t)
   (roletype object_r guix_profiles_t)
+  (typeattributeset file_type guix_profiles_t)

   ;; These types are domains, thereby allowing process rules
   (typeattributeset domain (guix_daemon_t guix_daemon_exec_t))

bug#36330: guix-build-branch.sh failed on Fedora 29

[Matt Wette]

On 7/4/19 2:29 AM, Ludovic Courtès wrote:

Hi Matt,

Matt Wette  skribis:


write(2, "updating checkout of 
'https://notabug.org/cwebber/guile-gcrypt.git'...\n", 71) = 71
openat(AT_FDCWD, "/usr/lib64/libgit2.la", O_RDONLY) = -1 ENOENT (No such file 
or directory)

It seems that your installation of Guile-Git fails to load libgit2, and
thus doesn’t work at all.  Could you check if that is the case?

(Besides, unless you want to build from source, I’d recommend using the
binary tarball to get Guix set up quickly:
<https://gnu.org/software/guix/manual/en/html_node/Binary-Installation.html>.)



I will look into the binary.  Thanks for taking the time on this.

Matt

bug#36330: guix-build-branch.sh failed on Fedora 29

[Matt Wette]

On 6/24/19 11:54 AM, Ludovic Courtès wrote:


readlink -f /home/mwette/proj/guix/guix-1.0.1/test-tmp/var


[mwette@localhost ~]$ readlink -f /home/mwette/proj/guix/guix-1.0.1/test-tmp/var

/home/mwette/proj/guix/guix-1.0.1/test-tmp/var

bug#36330: guix-build-branch.sh failed on Fedora 29

[Matt Wette]

On 6/24/19 1:26 AM, Ludovic Courtès wrote:


make check TESTS=tests/guix-build-branch.sh


I did not use "-j" and the above fails also.

In addition,

$ guix install glibc-locales

failed as well.  I don't remember the error message.
I will see if I can find a log.

Thanks for responding,
Matt

bug#32096: [wishlist] on-line documentation

[Matt Wette]

On 07/08/2018 11:40 AM, Alex Kost wrote:

Matt Wette (2018-07-08 09:53 -0700) wrote:


It would be nice if the guix documentation was directly readable
in HTML at https://www.gnu.org/software/guix

Perhaps I miss-understood what you mean, but it is available:

   https://www.gnu.org/software/guix/manual/en/html_node/index.html

(there is a link to the manual from the Guix site)



There no link from http://www.gnu.org/software/guix that I could find.
It would be nice if the heading, now reading

    [Overview] [Download] [Packages] ... [About]

had a [Documentation] (or [Manual]) link.

bug#32096: [wishlist] on-line documentation

[Matt Wette]

It would be nice if the guix documentation was directly readable
in HTML at https://www.gnu.org/software/guix

bug#29448: Acknowledgement ([wishlist] nice option for guix)

[Matt Wette]

scratch that.
When I executed `guix pull' the processes were not niced, but once the builds 
started, the nice did seem to be there.

bug#29448: [wishlist] nice option for guix

[Matt Wette]

I have `niced' the daemon and --cores=1 but the niceness does not get 
translated to builds. 
I gutless desktop is unusable during the long builds. Please, please make it be 
nice.

bug#27217: break up TeXlive for guix

[Matt Wette]

Here is a link from macports.  It may be of use.  They have broken down to 
50ish packages.  (I didn't count.)   

https://trac.macports.org/wiki/TeXLivePackages