Re: xwayland security updates, to mesa- or core-updates or ?

[Efraim Flashner]

On Thu, Dec 21, 2023 at 09:18:50PM +, John Kehayias wrote:
> Hi all,
> 
> On Mon, Dec 18, 2023 at 12:57 AM, John Kehayias wrote:
> 
> > Hi Kaelyn and everyone,
> >
> > On Fri, Dec 15, 2023 at 05:25 PM, Kaelyn wrote:
> >
> >> On Thursday, December 14th, 2023 at 10:21 PM, John Kehayias
> >>  wrote:
> >>
> >>>
> >>> Hi Guix,
> >>>
> >>> In light of (more) CVEs in xwayland, see
> >>> ,
> >>>
> >>> with already pending security updates, see
> >>> , I would like to prioritize
> >>>
> >>> getting that fixed in master. The tricky thing is that, according to
> >>> 67136, the xwayland update needs newer xorgproto, which corresponds to
> >>> many rebuilds. (The related CVEs in xorg-server have been pushed
> >>> already as effectively minor version bumps.)
> >>>
> 
> I also updated curl as it was going to be rebuilt and had a new
> version out (with some security fixes). I hadn't grafted it on master
> but we could do that if the mesa-updates branch isn't merged to master
> first.
> 
> [snip]
> 
> >
> > I've pushed 3 patches (mesa, xorgproto, xorg-server-xwayland) to
> > mesa-updates after merging in master. The farm is building away.
> >
> 
> I also had to skip a failing test (unknown reasons) of gtk with these
> updates.
> 
> Finally, I also enabled the zink driver in Mesa (zink is for OpenGL on
> Vulkan). I remember someone asking about it on #guix recently as well,
> and we should have it enabled in general, to support devices which may
> not be able to use OpenGL without it.
> 
> > The request for merging is at  with
> > some details. In short, running into some issues with builds "failing"
> > because they just die or "missing derivation" errors. I'm restarting
> > what I see that seems higher impact, but is there anyway to restart
> > all the failed builds or ones with missing dependencies?
> >
> 
> This is still true though I've tried to manually restart lots of
> builds on x86_64 and i686, which has removed many of the failures. Any
> idea what is happening to cause this more recently?
> 
> [snip]
> 
> > Thanks! I saw you had posted the latest version and that's what I
> > included. On x86_64-linux at least everything has built fine for
> > those, but the larger world remains to be seen.
> >
> > Would still like confirmation from other branches about what they want
> > to do, but we have some time while things build. And builds get
> > restarted.
> >
> 
> I haven't seen QA process this branch, so I'm just going with what I
> see on Berlin. From the branches overview it shows about 61% last I
> saw, compared to 72% for master. Unfortunately, non x86 architectures
> are usually better covered by Bordeaux, but I don't know where to get
> a sense of that coverage. For what it is worth, Efraim has manually
> built xorgproto and mesa at least on powerpc64le, riscv64, without
> issues.

I had berlin build for powerpc64le and that went without any problems.
Locally I built for riscv64 and powerpc and those both built fine.  I
ran into an issue locally with curl on aarch64 and test 1477(?) which is
weird since it's supposed to be skipped but I'm sending it through
again.  Haven't started armhf yet.

> Coverage on x86_64 and i686 seems good from what I can tell. I also
> don't think there are any other branches ready to merge, and would
> like to give them time to rebuild once these changes hit.
> 
> Any thoughts on when to merge?
> 
> Thanks everyone!
> John
> 

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: xwayland security updates, to mesa- or core-updates or ?

[John Kehayias]

Hi all,

On Mon, Dec 18, 2023 at 12:57 AM, John Kehayias wrote:

> Hi Kaelyn and everyone,
>
> On Fri, Dec 15, 2023 at 05:25 PM, Kaelyn wrote:
>
>> On Thursday, December 14th, 2023 at 10:21 PM, John Kehayias
>>  wrote:
>>
>>>
>>> Hi Guix,
>>>
>>> In light of (more) CVEs in xwayland, see
>>> ,
>>>
>>> with already pending security updates, see
>>> , I would like to prioritize
>>>
>>> getting that fixed in master. The tricky thing is that, according to
>>> 67136, the xwayland update needs newer xorgproto, which corresponds to
>>> many rebuilds. (The related CVEs in xorg-server have been pushed
>>> already as effectively minor version bumps.)
>>>

I also updated curl as it was going to be rebuilt and had a new
version out (with some security fixes). I hadn't grafted it on master
but we could do that if the mesa-updates branch isn't merged to master
first.

[snip]

>
> I've pushed 3 patches (mesa, xorgproto, xorg-server-xwayland) to
> mesa-updates after merging in master. The farm is building away.
>

I also had to skip a failing test (unknown reasons) of gtk with these
updates.

Finally, I also enabled the zink driver in Mesa (zink is for OpenGL on
Vulkan). I remember someone asking about it on #guix recently as well,
and we should have it enabled in general, to support devices which may
not be able to use OpenGL without it.

> The request for merging is at  with
> some details. In short, running into some issues with builds "failing"
> because they just die or "missing derivation" errors. I'm restarting
> what I see that seems higher impact, but is there anyway to restart
> all the failed builds or ones with missing dependencies?
>

This is still true though I've tried to manually restart lots of
builds on x86_64 and i686, which has removed many of the failures. Any
idea what is happening to cause this more recently?

[snip]

> Thanks! I saw you had posted the latest version and that's what I
> included. On x86_64-linux at least everything has built fine for
> those, but the larger world remains to be seen.
>
> Would still like confirmation from other branches about what they want
> to do, but we have some time while things build. And builds get
> restarted.
>

I haven't seen QA process this branch, so I'm just going with what I
see on Berlin. From the branches overview it shows about 61% last I
saw, compared to 72% for master. Unfortunately, non x86 architectures
are usually better covered by Bordeaux, but I don't know where to get
a sense of that coverage. For what it is worth, Efraim has manually
built xorgproto and mesa at least on powerpc64le, riscv64, without
issues.

Coverage on x86_64 and i686 seems good from what I can tell. I also
don't think there are any other branches ready to merge, and would
like to give them time to rebuild once these changes hit.

Any thoughts on when to merge?

Thanks everyone!
John

using shepherd's (shepherd service repl) in guix system

[Justin Veilleux]

Hi. I thought it would be interesting to have a shepherd service run a
repl like in
https://www.gnu.org/software/shepherd/manual/html_node/REPL-Service.html.
Since there is no shepherd repl service in a (gnu services *) module, I
created a shepherd-service-type and shepherd-service (I copied the code
from `(shepherd service repl)`)

The `reconfigure` runs and after fiddling with permission bits and
connecting to the socket through emacs and geiser (like in the manual),
I am able to execute expressions such as `(+ 2 2)` and `(display
"test\n")` and everything works as expected.

However, when I try to evaluate `lookup-service` (without calling it),
the repl gets stuck in an infinite loop of

> scheme@(shepherd-user) [1]> While reading expression:
> Attempt to suspend fiber within continuation barrier

This is annoying, since inspecting the state of shepherd is my main use
case for the REPL service. Has anyone encountered this problem?

The `shepherd-repl-service-type`:

> (define shepherd-repl-service-type
>   (service-type
>(name 'shepherd-repl)
>(description "Run a shepherd repl")
>(default-value "/var/run/shepherd/repl")
>(extensions
> (list
>  (service-extension
>   shepherd-root-service-type
>   (lambda (socket-file)
> (list
>  (shepherd-service
>   (documentation "Run the shepherd repl")
>   (provision '(repl))
>   (requirement '())
>   (start #~(lambda args
>  (format #t "socket file: ~s\n" #$socket-file)
>  (with-exception-handler
>  (lambda (exn)
>#f)
>(lambda ()
>  (delete-file #$socket-file))
>#:unwind? #t)
>  (let ((socket (open-server-socket #$socket-file)))
>((@@ (shepherd service repl) spawn-repl-service) 
> socket)
>socket)))
>   (stop #~(lambda (socket)
> (close-port socket)
> #f))
>   (modules (cons*
> '(shepherd service repl)
> '(shepherd comm)
> %default-modules))

Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems

[Jean-Pierre De Jesus Diaz]

Hello everyone,

I was working before on embedded toolchains with Guix and added AVR
platform as a result. [1]

Just FYI, I have a WIP patch series to add support for arm-none-eabi using the
Guix cross compilation methods, e.g.: using #:target and so on and
also to add an user installable toolchain as done with AVR on [1].

The arm-none-eabi target is not finished yet since I'm running into some
issues when building Axoloti which depends on the (gnu packages embedded)
toolchains and I'm trying to migrate it to use `cross-gcc-toolchain` but it is
proving a bit difficult due to search paths but I'm trying to solve it anyway.

>$ make
>[  1%] Linking ASM executable bs2_default.elf
>arm-none-eabi-gcc: error: nosys.specs: No such file or directory
>
>IIRC, this happens with the vanilla guix packages when i try to use a gcc 
>package instead of a gcc-toolchain package.

This happens when the toolchain doesn't have the Newlib C library which
includes the nosys.specs file so probably if Newlib is present it's then that
GCC can't find the specs file.

[1]: https://issues.guix.gnu.org/66263

-- 
Jean-Pierre De Jesus DIAZ
Foundation Devices, Inc.

Suggestion for a guix shell feature.

[Development of GNU Guix and the GNU System distribution.]

I want to make a suggestion for a feature for guix shell.

I was recently writing guix.scm files for my projects and was having problem 
with the libraries I added, not being found inside the shell. After struggling 
for hours I finally learned that that the LD_LIBRARY_PATH  is not being updated 
automatically inside the  guix shell environment so the libraries can be found 
easily.

So my feature suggestion is that maybe we can have a flag or a option for guix 
shell, something like --add-ld-path or --update-ld-path for example, to add all 
libraries specified in the guix.scm or even as sub-command guix shell 
--add-ld-path mesa as an example, to automatically update the LD_LIBRARY_PATH 
environment variable to contain the correct paths to these libraries so they 
can be found easily inside the shell.

--
Sent with Tuta; enjoy secure & ad-free emails:
https://tuta.com

Re: arm-none-eabi toolchain and compiling C++ stuff

[Ricardo Wurmus]

Attila Lendvai  writes:

> is that a bug in (gnu packages embedded)? shall i look into fixing it?
>
> or am i the one who has invalid expectations?

FWIW I have successfully been using
make-arm-none-eabi-nano-toolchain-4.9 with the Axoloti DSP board (via
the axoloti-patcher package).  The 2018 toolchain you are using should
also just work (perhaps after setting *_CROSS_* variables).  So this
could very well be a bug in the package.

-- 
Ricardo

Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems

[Attila Lendvai]

hi Stefan,


> In the end it worked nicely for my embedded C++ stuff and I also managed
> to compile a custom keyboard firmware based on ZMK using Zephyr,
> although that is just C code.


i've also encountered a problem with the guix cross compiling tools as i have 
described here:

https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00179.html

i tried with your gcc (copied into guix as (gnu packages embedded2)):

~/workspace/guix/guix/pre-inst-env guix shell gcc-toolchain cmake make 
pkg-config -e '(@ (gnu packages embedded2) 
gcc12-cross-newlib-arm-none-eabi-toolchain)'
cd ~/workspace/bios/pico-serprog
cmake .
make

but it errors out with:

$ make
[  1%] Linking ASM executable bs2_default.elf
arm-none-eabi-gcc: error: nosys.specs: No such file or directory

IIRC, this happens with the vanilla guix packages when i try to use a gcc 
package instead of a gcc-toolchain package.

any thoughts on this?

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“There can be no causeless love or any sort of causeless emotion. An emotion is 
a response to a fact of reality, an estimate dictated by your standards.”
— Ayn Rand (1905–1982)