bug#68988: All arm64/aarch64 platforms disabled in linux-libre 6.7.x!
On Thu, Feb 08, 2024 at 07:57:38AM +0100, Wilko Meyer wrote: > Vagrant Cascadian writes: > > > [[PGP Signed Part:Undecided]] > > The linux-libre 6.7.x package contains ... as far as I can tell, no > > supported arm64/aarch64 platforms! This is a pretty significant > > regression from the linux-libre 6.6.x packaging! Huh! When I was generating configs, I never did anything very special to ensure continued aarch64 support in new kernel series except for `make ARCH=arm64 oldconfig`. It would be useful if others would help by testing the patches adding new kernel series on aarch64 or other non-x86_64 platforms. In my observation that rarely happens. And then bugs like this can slip in. > I'll generate a new arm/arm64 config for the 6.7.x series that doesn't > fall behind the 6.6.x series config; and will test it on my pinebook pro > at least before sending in a patch. Thanks Wilko! Let us know if we can help.
bug#53533: [DISCUSSION] Quality of services in reproducible build environment Guix
Hi, I think I can close this now as all questions were covered. Thanks, Oleg signature.asc Description: PGP signature
bug#68961: ASLR seems to be partially broken
Am Dienstag, dem 06.02.2024 um 23:57 +0100 schrieb Jonathan Brielmaier:
> Hi,
>
> I found today an interesting blog post about broken ASLR (Address
> Space
> Layout Randomization) on Linux:
> https://zolutal.github.io/aslrnt/
>
> Curious if this is also a problem on Guix System I did a quick test.
>
> ```
> $ cat aslr.py
> from subprocess import check_output
> result = 0x0
> for _ in range(0,1000):
> out = check_output("cat /proc/self/maps | grep libc | head -n1",
> shell=True).decode()
> base_address = int(out.split('-')[0], 16)
> result |= base_address
> print('libc: ' + hex(result))
>
> resultld = 0x0
> for _ in range(0,1000):
> out = check_output("cat /proc/self/maps | grep ld-linux | head
> -n1", shell=True).decode()
> base_address = int(out.split('-')[0], 16)
> resultld |= base_address
> print('ld-linux: ' + hex(resultld))
> ```
>
> Running this on x86_64 system of mine results on two systems in:
> libc: 0x7ffa9000
> ld-linux: 0x7000
>
> On the third system it prints:
> libc: 0x7000
> ld-linux: 0x7000
On my machine, this also prints 0x7000. Perhaps 1000 runs are
not good enough to get truly random results with some RNGs. Note that
we do have 51 bits of randomness here – perhaps not ideal, but afaik
the best we can do without breaking alignment.
> For 32bit it looks even worse (not sure if it's correct to test it
> like
> this):
> $ guix shell --system=i686-linux coreutils python -- python3 aslr.py
> libc: 0xf780
> ld-linux: 0xf7fff000
>
> Not sure what we should do here. There seem to be some a kernel patch
> for Ubuntu available:
For 32 bit, try
```
from subprocess import check_output
result = 0x
for _ in range(0,1000):
out = check_output("cat /proc/self/maps | grep libc | head -n1",
shell=True).decode()
base_address = int(out.split('-')[0], 16)
result &= base_address
print('libc: ' + hex(result))
resultld = 0x
for _ in range(0,1000):
out = check_output("cat /proc/self/maps | grep ld-linux | head -
n1", shell=True).decode()
base_address = int(out.split('-')[0], 16)
resultld &= base_address
print('ld-linux: ' + hex(resultld))
from subprocess import check_output
result = 0x
for _ in range(0,1000):
out = check_output("cat /proc/self/maps | grep libc | head -n1",
shell=True).decode()
base_address = int(out.split('-')[0], 16)
result &= base_address
print('libc: ' + hex(result))
resultld = 0x
for _ in range(0,1000):
out = check_output("cat /proc/self/maps | grep ld-linux | head -
n1", shell=True).decode()
base_address = int(out.split('-')[0], 16)
resultld &= base_address
print('ld-linux: ' + hex(resultld))
```
instead. I get 0xf7c0 for libc and 0xf7e0 – meaning that the
first nibble is always the same, but more importantly, these are also
the addresses you'd get on each run. So I'm pretty sure that ASLR'nt
applies to our 32 bit builds.
Since this is a known bug in the Linux kernel, I'd like to check
whether there's a fix we can backport. We could of course also patch
our config aux-files like Ubuntu does in the meantime.
Cheers
bug#68912: Guix-home search paths shadow .config/guix/current
Am Samstag, dem 03.02.2024 um 13:12 + schrieb Christina O'Donnell: > This leads to unexpected results if you have Guix inside your home > package list. (Which you might desire if you wanted to use Guix in a > home container.) The wisdom "One does not simply 'guix install guix'" has been passed around for ages. Same applies to home configurations, which merely mimic that aspect. There are valid reasons for using Guix in temporary shells (or home containers), but also many pathological uses. > [T]he situation is preventable and undesirable and there's several > possible solutions: > > 1. Reorder the paths by default, keeping ~/.config/guix in front of > ~/.guix-home As far as I know, this requires changing the order in which files are sourced, and it's not clearly desirable that ~/.config/guix ought to shadow ~/.guix-home or ~/.guix-profile. In particular, whenever you use `guix shell` or similar, you will shadow that anyway. > 2. Have `guix home` warn when 'guix' is included as a package This might be fine, but what about the home container use-case then? I'm not sure whether having no guix in containers is preferable over having a slightly outdated one – at the very least, my personal usage of GWL through `guix shell' is enough reason to keep guix visible as a package. > 3. Have `guix pull` warn when Guix is shadowed and unable to be > updated This would (at least in a naive version) print a weird warning on fresh setups, where the not yet created local ~/.config/guix is not yet on PATH. As far as I know, this would be doable, though, if you're smart enough about it. > (Incidentally, how did gzip and coreutils get in there? I didn't put > it there.) These might have been added by the home container for reason unbeknownst to me. > hint: After setting `PATH', run `hash guix' to make sure your shell > refers to `/home/cdo/.config/guix/current/bin/guix'. Hint: this is the warning you're looking for. It's phrased as a hint, because people typically only encounter it once during setup. Cheers
bug#53423: nncp: Fails to build (renamed file not found)
Hi Vagrant, Thank you for the ping on this issue. It was on my radar to update nncp as the package was failed to build for a long time and quite dated. It looks like the current version is not compatible with versions of golang packages available in Guix anymore. I have a chance to bump it to the 8.0.0 to check if it may fix the build but it did not work any more and the whole package need proper refactoring. I'll place upgrading it to my TODO list. Thanks, Oleg signature.asc Description: PGP signature
bug#68982: Ren'py 8.2.0 Crash on startup
Am Mittwoch, dem 07.02.2024 um 14:38 -0600 schrieb msglm: > When starting the ren'py launcher on version Ren'Py 8.2.0.24012702, > currently my guix channel is on commit > 5d2302a1959d09e6d5a5f02ac199458095847a82, the program crashes with > the following error: > > Full traceback: > File "/gnu/store/2m851i42kc8i929rfhrn6w545w6a94lz-python-renpy- > 8.2.0/lib/python3.10/site-packages/renpy/bootstrap.py", line 354, in > bootstrap > renpy.config.logdir = renpy.__main__.path_to_logdir(basedir) > AttributeError: module '__main__' has no attribute 'path_to_logdir' If you have a local guix checkout, try adding the following lines to gnu/packages/aux-file/renpy.in: def path_to_logdir(basedir): return basedir However, it seems upstream also has a predefined_searchpath added in 8.2, and changed the semantics of path_to_saves. I think we might want to revert to 8.1 to deal with all those changes properly. Cheers
