bug#70302: Tor daemon is unable to use obfuscation
Hello Guix! I am trying to configure tor daemon to use traffic obfuscation by the following lines in my system configuration (service tor-service-type (tor-configuration (plain-file "torrc" " UseBridges 1 ClientTransportPlugin obfs4 exec /path/to/obfuscator/binary Bridge obfs4 .. Bridge obfs4 .. "))) where /path/to/obfuscator/binary corresponds to an obfs4 obfuscator. There are a few of them in the guix repo, see e.g. go-gitlab-torproject-org-tpo-anti-censorship-pluggable-transports-lyrebird or go-github-com-operatorfoundation-obfs4 packages. The obfuscator is also installed in the system profile. Bridges are gotten from the official site https://bridges.torproject.org/. This torrc configuration works perfectly on guix when tor run at user level by command '$ tor -f path/to/torrc' and '# netstat -tupan' shows obfuscator process is listening on 127.0.0.1:[some random port]. However, when tor run as system daemon, there are no obfuscator process listening and tor is unusable. Perhaps this issue is related to https://issues.guix.gnu.org/57222. I have tried to revert commit fb868cd7794f15e21298e5bdea996fbf0dad17ca on recent guix checkout and then to perform 'guix pull --url=/path/to/my/local/guix/repo --disable-authentication'. It worked fined. But when performing 'sudo guix system reconfigure /path/to/system/configuration' I got an error 'make-forkexec-constructor/container: unbound variable' Regards, Nigko Yerden
bug#70254: withershins - failed to build
Closing, because withershins is no more. -- Ricardo
bug#66510: Unexpected `this-package(-native)-input`
Hi Ulf Has any progress been made on this? I ran into the same thing, except with native-inputs instead of inputs. I spent a fair amount of time trying to pin it down, since I don't know much guile and it requires a combination of conditions to manifest. Is it worth documenting this behaviour? Or do we expect a solution will be implemented soon enough? For now, is the following guideline accurate enough to avoid these surprises? If we inherit a package that uses (either directly or through inheritance) this-package-native-input (or this-package-input), we should not modify the native inputs (or inputs) via replace if substitute-keyword-arguments is used anywhere in the inheritance chain. Thanks Jake
bug#70239: (operating-system) structure requires a kernel
Hi, On 2024-04-08 14:28:58 +0200, Ludovic Courtès wrote: > [..] > > Could you confirm? Yes, the attached patch fixed the issue for me. :) > > > I think it would be best to just support (kernel #f) for container > > deployments, > > since that would simplify it and keep it manageable. > > Yes, let’s do that too. > > Thanks, > Ludo’. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
bug#70315: libvirtd daemon scans /gnu/store for unknown reasons, uses 600 MiB of RSS memory
Hi,
I've discovered that libvirtd on my Guix System consumes an excessive
amount of resident memory, about 600 MiB. Other GNU/Linux users report
their daemon uses about 20 MiB. This is when no virtual machine is in
use.
Attaching strace to a freshly started libvirtd process, we can observe
the following strace output:
--8<---cut here---start->8---
$ sudo strace -vf -s600 -p$(pgrep libvirtd)
[pid 4355] read(23, "", 7292) = 0
[pid 4355] close(23) = 0
[pid 4355] newfstatat(AT_FDCWD,
"/gnu/store/pyw31df87mwlxjgi8q9bsbj9725cd2vz-rustc-1.69.0-src.tar.xz-builder",
{st_dev=makedev(0, 0x18), st_ino=341758129, st_mode=S_IFREG|0444, st_nlink=1,
st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=3880,
st_atime=1698766945 /* 2023-10-31T11:42:25-0400 */, st_atime_nsec=0, st_mtime=1
/* 1969-12-31T19:00:01-0500 */, st_mtime_nsec=0, st_ctime=1698766945 /*
2023-10-31T11:42:25.196626584-0400 */, st_ctime_nsec=196626584},
AT_SYMLINK_NOFOLLOW) = 0
[pid 4355] openat(AT_FDCWD,
"/gnu/store/pyw31df87mwlxjgi8q9bsbj9725cd2vz-rustc-1.69.0-src.tar.xz-builder",
O_RDONLY|O_NOCTTY|O_NONBLOCK) = 23
[pid 4355] newfstatat(23, "", {st_dev=makedev(0, 0x18), st_ino=341758129,
st_mode=S_IFREG|0444, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096,
st_blocks=8, st_size=3880, st_atime=1698766945 /* 2023-10-31T11:42:25-0400 */,
st_atime_nsec=0, st_mtime=1 /* 1969-12-31T19:00:01-0500 */, st_mtime_nsec=0,
st_ctime=1698766945 /* 2023-10-31T11:42:25.196626584-0400 */,
st_ctime_nsec=196626584}, AT_EMPTY_PATH) = 0
[pid 4355] fcntl(23, F_GETFL) = 0x8800 (flags
O_RDONLY|O_NONBLOCK|O_LARGEFILE)
[pid 4355] fcntl(23, F_SETFL, O_RDONLY|O_LARGEFILE) = 0
[pid 4355] newfstatat(23, "", {st_dev=makedev(0, 0x18), st_ino=341758129,
st_mode=S_IFREG|0444, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096,
st_blocks=8, st_size=3880, st_atime=1698766945 /* 2023-10-31T11:42:25-0400 */,
st_atime_nsec=0, st_mtime=1 /* 1969-12-31T19:00:01-0500 */, st_mtime_nsec=0,
st_ctime=1698766945 /* 2023-10-31T11:42:25.196626584-0400 */,
st_ctime_nsec=196626584}, AT_EMPTY_PATH) = 0
[pid 4355] lseek(23, 0, SEEK_SET) = 0
[pid 4355] read(23, "(begin (use-modules (ice-9 ftw) (ice-9 match) (ice-9
regex) (srfi srfi-1) (srfi srfi-26) (guix build utils)) (define
tar-supports-sort? (zero? (system* (string-append
\"/gnu/store/8n53xwg5yzm5wzv9c9gcn6rjmq975k06-tar-1.34\" \"/bin/tar\") \"cf\"
\"/dev/null\" \"--files-from=/dev/null\" \"--sort=name\"))) (define
(apply-patch patch) (format (current-error-port) \"applying '~a'...~%\" patch)
(invoke (string-append
\"/gnu/store/d9838iax3lgm57glvv43a1pwpnaipljw-patch-2.7.6\" \"/bin/patch\")
\"--force\" \"--no-backup-if-mismatch\" \"-p1\" \"--input\" patch)) (define
(first-file directory) (car (scandir directory (lambda (nam"..., 8192) = 3880
[pid 4355] read(23, "", 4312) = 0
[pid 4355] close(23) = 0
[pid 4355] newfstatat(AT_FDCWD,
"/gnu/store/fdk9wcp5idm4vgcz0ysps3qvrf7545a3-rustc-1.69.0-src.tar.xz.drv",
{st_dev=makedev(0, 0x18), st_ino=341758131, st_mode=S_IFREG|0444, st_nlink=1,
st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=1290,
st_atime=1698766945 /* 2023-10-31T11:42:25-0400 */, st_atime_nsec=0, st_mtime=1
/* 1969-12-31T19:00:01-0500 */, st_mtime_nsec=0, st_ctime=1698766945 /*
2023-10-31T11:42:25.196626584-0400 */, st_ctime_nsec=196626584},
AT_SYMLINK_NOFOLLOW) = 0
[pid 4355] openat(AT_FDCWD,
"/gnu/store/fdk9wcp5idm4vgcz0ysps3qvrf7545a3-rustc-1.69.0-src.tar.xz.drv",
O_RDONLY|O_NOCTTY|O_NONBLOCK) = 23
[pid 4355] newfstatat(23, "", {st_dev=makedev(0, 0x18), st_ino=341758131,
st_mode=S_IFREG|0444, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096,
st_blocks=8, st_size=1290, st_atime=1698766945 /* 2023-10-31T11:42:25-0400 */,
st_atime_nsec=0, st_mtime=1 /* 1969-12-31T19:00:01-0500 */, st_mtime_nsec=0,
st_ctime=1698766945 /* 2023-10-31T11:42:25.196626584-0400 */,
st_ctime_nsec=196626584}, AT_EMPTY_PATH) = 0
[pid 4355] fcntl(23, F_GETFL) = 0x8800 (flags
O_RDONLY|O_NONBLOCK|O_LARGEFILE)
[pid 4355] fcntl(23, F_SETFL, O_RDONLY|O_LARGEFILE) = 0
[pid 4355] newfstatat(23, "", {st_dev=makedev(0, 0x18), st_ino=341758131,
st_mode=S_IFREG|0444, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096,
st_blocks=8, st_size=1290, st_atime=1698766945 /* 2023-10-31T11:42:25-0400 */,
st_atime_nsec=0, st_mtime=1 /* 1969-12-31T19:00:01-0500 */, st_mtime_nsec=0,
st_ctime=1698766945 /* 2023-10-31T11:42:25.196626584-0400 */,
st_ctime_nsec=196626584}, AT_EMPTY_PATH) = 0
[pid 4355] lseek(23, 0, SEEK_SET) = 0
[pid 4355] read(23,
"Derive([(\"out\",\"/gnu/store/9y2dsnwcdm2a3chmasqkg0wha057cg8g-rustc-1.69.0-src.tar.xz\",\"\",\"\")],[(\"/gnu/store/5kxy5mynf2msxwg3diggsgfi9089cl81-rustc-1.69.0-src.tar.gz.drv\",[\"out\"]),(\"/gnu/store/6i2qvlvfmhmw2vsf8x5jqxsgbpd9kx9p-glibc-utf8-locales-2.35.drv\",[\"out\"]),(\"/gnu/store/782cqklvsgj1fqx27z8mwlyfzcsp8zf6-tar-1.34.drv\",[\"out\"]),(\"/gnu/sto
bug#70316: `guix pack -f squashfs` does not create /tmp and /var/tmp
Similarly to a previous patch for Docker [1], Singularity complains when using a squashfs image as the /tmp and /var/tmp folders do not exist. It would be great if they were, I had programs failing quietly because there was no /tmp folder and tracked down the issue to this. As a more general option, it could be interesting to have an option in guix pack to create any folder in the pack. Thanks, Alexis [1] https://issues.guix.gnu.org/issue/37161
bug#70244: Bug in Guix? ... guix-command substitute' died unexpectedly
April 8, 2024 at 6:34 AM, "Zelphir Kaltstahl" wrote: > > On 4/7/24 21:19, jbra...@dismail.de wrote: > > > > > April 7, 2024 at 9:46 AM, "Zelphir Kaltstahl" > > wrote: > > > > > > > > > > On 4/7/24 03:17, jbra...@dismail.de wrote: > > > > > > > > > > > > > > > > > > > > I was able to update, yes, but I don't know, if the problem is > > > > > solved. I got some error (not necessarily the same, I don't remember) > > > > > on multiple occasions, when trying to update. I have no idea, whether > > > > > it is something other people experience or just my installation. > > > > > Now that you have updated. > > > > > Does the below work without issue? > > > > > > > > $ guix pull && guix package -u > > > > # guix system reconfigure config.scm > > > > > > > > If you still experience issues with the above commands, please let me > > > > know! > > > > > > > > Thanks, > > > > > > > > Joshua > > > > Hi Joshua! > > > > > > I just tried: > > > > > > START > > > guix pull && guix package -u > > > > > > ... > > > (lots of output) > > > ... > > > > > > building /gnu/store/3g7459g63by7wgnjksz3843apq7n7k6m-racket-8.11.1.drv... > > > substitute: updating substitutes from 'https://ci.guix.gnu.org > > > https://ci.guix.gnu.org/ https://ci.guix.gnu.org/ '... 0.0%guix > > > substitute: error: TLS error in procedure 'write_to_session_record_port': > > > Error in the push function. > > > guix package: error: > > > `/gnu/store/l4vir00gbprk85qzmm2v8l38z8jrfly0-guix-command substitute' > > > died unexpectedly > > > ~END~ > > > That sounds like a bug. > > > > What does > > > > $ guix describe > > $ guix system describe > > > > output? > > > > What kind of computer do you have? > > > > Hi again, > > > $ guix describe > Generation 49 Apr 07 2024 14:46:14 (current) > guix 0fa6ba8 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: 0fa6ba879af5625a3220f94fd699d5fae9e999d4 > > > > > That should be the version I pulled with `--no-substitutes`. > > > $ guix system describe > guix system: error: no system generation, nothing to describe > > > > > I guess this is, because I am running Guix on foreign distro? I should have > mentioned that way earlier. Sorry. -.- Didn't make the jump to run Guix > distro yet. Want to try that in a VM at some point. > > > > This machine is a Lenovo T470s. > > > > Installed is Xubuntu or Ubuntu with later installed XFCE: > > > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 22.04.4 LTS > Release: 22.04 > Codename: jammy > > > > > Best regards, > > Zelphir well grr. That's kind of the extent of my guix knowledge. How did you install guix on this foreign distro? Did you use the installer script? That should work. > > -- > repositories: https://notabug.org/ZelphirKaltstahl >
bug#70284: @ancronym not recognized as valid Texinfo in description
Hi, Le 8 avril 2024 13:21:34 GMT-04:00, Christopher Baines a écrit : >Maxim Cournoyer writes: > >> Hi, >> >> Using an acrynym such as @acronym(SNES, Super Nintendo Entertainment >> System) currently throws an "invalid Texinfo markup" error at build >> time. > >I think I've used acronyms in descriptions, seems like diffr in >rust-apps uses one for example. > >The brackets are different though. Haha! Good eye! Texinfo syntax uses curly braces, not brackets! There is no issue after changing these. Closing! Thanks, Maxim
bug#66866: aarch64 system cross compilation + pinebook pro image broken?
Hi all, I would really appreciate if anyone could give some feedback on my previous patch to the copy build system. -- dan
