Re: Fwd: [core-updates] libaio test fails on powerpc64le-linux due to kernel bug

[Thiago Jung Bauermann]

Hello Tobias,

Tobias Geerinckx-Rice  writes:

> [[PGP Signed Part:Undecided]]
> Thiago,
>
> Done:
> - Ran ‘apt update && apt full-upgrade’
> - rebooted

Thank you!

> - read [0] to figure out what Debian's weirdo unames mean.
>
> [0]: 
> https://unix.stackexchange.com/questions/509247/debian-linux-kernel-versioning

Yes, it's weird. I always resort to reading the kernel package
changelog.

-- 
Thanks
Thiago

okay to merge rekados-rust-queue branch?

[Ricardo Wurmus]

Hi Guix,

I have a small branch with minor Rust package upgrades.  I successfully
built icecat on that branch and the failing rust-* packages seen in the
latest builds at https://ci.guix.gnu.org/jobset/rekados-rust-queue seem
to be broken on the master branch as well.

Would it be okay to merge this branch?

I’m asking because the cargo-build-system makes it difficult to see how
upgrades affect other packages, so building things on ci.guix.gnu.org
and locally is the only way I can verify that the changes aren’t
catastrophic.

I’d like to merge this soon while the successful builds are fresh.

-- 
Ricardo

Re: 'staging' freeze

[Efraim Flashner]

On Sun, Aug 28, 2022 at 05:56:08PM +0200, Mathieu Othacehe wrote:
> 
> Hey Marius,
> 
> > The 'staging' branch is in a pretty good shape, let's get it merged!
> 
> Nice work!
> 
> > I'm fairly rusty when it comes to Cuirass, and don't see a button to
> > start the jobset here even when authenticated:
> >
> >   https://ci.guix.gnu.org/jobset/staging
> >
> > Can someone remind me how to enable a disable jobset?  :-)
> 
> No easy way for now:
> 
> --8<---cut here---start->8---
> psql -d cuirass -c "update specifications set is_active = 1 where name = 
> 'staging';"
> --8<---cut here---end--->8---
> 
> does the trick.
> 
> Thanks,
> 
> Mathieu

I manually restarted some of the failed builds and they then built
without any problems (I'm looking at you ghc@8.10). Currently I believe
we could use a retry on aarch64 for staging as a whole; there was a
while where we had key issues and many packages failed to build so they
should be sent back for another try.

Currently the big series of packages I see left are the KDE packages, it
seems that 5.70 from ~2 years ago is too old for our version of Qt and
should really be updated.

I haven't yet tried reconfiguring my desktop with staging, it seemed a
bit early for that.


-- 
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: [swh-devel] Disarchive database includes tar.xz archives

[Ludovic Courtès]

Hi,

Valentin Lorentz  skribis:

> ADDITIONAL_ARCHIVE_FORMATS complements formats already supported
> natively by Python's shutil module (listed here:
> https://docs.python.org/3/library/shutil.html#shutil.unpack_archive )
> which includes tar.bz2

Perfect.  Thanks for explaining!

Ludo’.

Re: [swh-devel] Disarchive database includes tar.xz archives

[Franck Bret]

Hi,

For what I can say tar.xz support is not explicit in tarball.py but I've 
managed tar.xz archive for Arch Linux loader and it worked.


See loader/package/arch/tests/test_arch.py

Le 8/29/22 à 11:43, Ludovic Courtès a écrit :

Hello!

(+Cc: swh-devel)

zimoun  skribis:


I do not the remember the status of tar.xz in nixguix SWH loader.

Looking at
,
it would seem that tar.xz is not supported (but tar.bz2 and tar.zst
are).

Am I right?

That said, I ran ‘guix lint -c archival’ on several tar.xz packages and
couldn’t find any whose source is missing from SWH.

Thanks,
Ludo’.

Re: [swh-devel] Disarchive database includes tar.xz archives

[Valentin Lorentz]

Hi,

ADDITIONAL_ARCHIVE_FORMATS complements formats already supported 
natively by Python's shutil module (listed here: 
https://docs.python.org/3/library/shutil.html#shutil.unpack_archive ) 
which includes tar.bz2


On 29/08/2022 11:43, Ludovic Courtès wrote:

Hello!

(+Cc: swh-devel)

zimoun  skribis:


I do not the remember the status of tar.xz in nixguix SWH loader.


Looking at
,
it would seem that tar.xz is not supported (but tar.bz2 and tar.zst
are).

Am I right?

That said, I ran ‘guix lint -c archival’ on several tar.xz packages and
couldn’t find any whose source is missing from SWH.

Thanks,
Ludo’.

Re: Idea: Function composition to declare operating-system

[Théo Maxime Tyburn]

Hi muradm!

muradm  writes:

[...]

>> --BEGIN USE_CASE
>> For example to add jackd to my system I need to add the "realtime"
>> group, add some users to this group and add a pam-limits-service. If
>> I
>> want to remove this functionality from my system using the
>> declarative
>> approach I have to look down my config file for places where I added
>> these things. Usually I partially solve this problem by putting
>> comments
>> to signal the purpose of each code block in the system declaration.
>>
>> But wouldn’t it be better if I just had a function `add-jackd` that
>> takes an
>> operating-system instance and returns the os with the extra
>> functionalities ?
>> --END USE_CASE
>
> To clarify, do you ask that in the end of the day, some where
> in (gnu services ...) there should be exported `add-jackd`
> function? If so, I beleive that this will increase cross
> dependency between things, thus decreasing flexibility.
>
> Imagine `add-jackd` maintainer should always keep track on
> what is being added into guix, that potentially may cause
> conflict with jackd and/or require adjustments in `add-jackd`
> function implementation.
>
> Also, IMHO, implementation of `add-jackd` would be very
> much opinionated.

Actually I was thinking that the functions that build up the system like
`add-jackd` would be written by users. It is still user
configuration, just packaged in a function. So no one would "have to"
maintain it. But this could still provide an easy way to share
independent parts of a system configs. Especially for features requiring a
complex setup, a canonical configuration could be something you would want to 
maintain. But
it would be up to the maintainer.

Assuming tough, someone wants to maintain `add-jackd` under (gnu
services ...), it should not be more maintenance effort than the effort
each and every user of jackd has to put so that it’s system
configuration doesn’t break. So I don’t see anything against it. But I
might be wrong.

>>
>> So that was the purpose of the experimentation. It didn’t turn out
>> to be
>> too complicated to implement. At least for my use case, I just
>> needed to add two helper
>> functions to extend users and services fields. The rest is handled
>> directly by
>> record inheritance and by accessing the fields of the input
>> operating-system.
>>
>> The final declaration looks like this:
>>
>> ((apply compose (reverse os-functions)) minimal-os)
>>
>
> [...]
>
>>
>> (define* (extend-operating-system-services os services #:key (drop
>> '()) (keep '()))
>>   (append (filter (lambda (service)
>>  (not (member (service-type-name 
>> (service-kind
>> service))
>>   (filter 
>> (lambda (s) (not (member s
>> keep)))
>>  
>>  (append drop
>> %fixed-system-service-types)
>>(operating-system-services os))
>>services))
>>
>
> I suppose this could be useful to have it in guix toolbox,
> although I would prefer to have (required '(account activate ...))
> or (required %fixed-system-service-types) optional argument,
> instead of refering to global constant %fixed-system-service-types,
> which might not satisfy everyone requirements.

I agree, better make this optional. If anything, only this this kind of
helper function would be added to guix so that users can define their
system conveniently using this function composition approach. 

>> and also force keeping or dropping of some services if needed. The
>> list
>> of services that gets duplicated seems to be this one:
>>
>> (define %fixed-system-service-types
>>   '(account activate boot cleanup etc file-systems firmware   fstab
>> guix host-name linux-bare-metal linux-builder pam   profile
>> root-file-system session-environment setuid-program   shepherd-root
>> system user-processes))
>>
>> I generated the list by just checking which services get duplicated,
>> so I am not
>> very sure about it. There surely is a better way to get it.
>>
>> Anyway I can now define a function adding desktop functionalities:
>>
>> (define (x-os os)
>>   (operating-system
>>(inherit os)
>>(services
>>  (extend-operating-system-services
>>   os
>>   (list
>>;; slim display manager
>>(service slim-service-type
>> (slim-configuration
>>  (display ":0")
>>  (vt "vt7")
>>  (theme %default-slim-theme)
>>  (theme-name %default-slim-theme-name)
>>  (xorg-configuration
>>   (xorg-configuration
>>(keyboard-layout 
>> (operating-system-keyboard-layout
>> os)))
>>   #:drop '(gdm)))
>>(packages (cons*
>>;; window managers
>>

Re: Fwd: [core-updates] libaio test fails on powerpc64le-linux due to kernel bug

[Tobias Geerinckx-Rice]

Thiago,

Done:
- Ran ‘apt update && apt full-upgrade’
- rebooted
- read [0] to figure out what Debian's weirdo unames mean.

Thanks!

T G-R

[0]: 
https://unix.stackexchange.com/questions/509247/debian-linux-kernel-versioning


signature.asc
Description: PGP signature

Re: usage of basu as requirement for sd-bus

[Maxime Devos]

On 30-08-2022 11:27, muradm wrote:


IIUC, everything using basu also works fine with elogind (*), so the
'status quo' of still using elogind (for old and new) seems harmless
to me (except for size -- basu is smaller).


I don't find the "everything using basu also works fine with elogind"
statement/assumption/guess correct, as per contents of elogind and
basu. See above comment for ifdef thingy. 


From the README.md of basu:


The sd-bus library, extracted from systemd. Agreed on th

Some projects rely on the sd-bus library for DBus support. However not all
systems have systemd or elogind installed. This library provides just 
sd-bus

(and the `busctl` utility).

This does not look like basu adds additional functionality.


My intention is not to have something that is not used. Roughly, if
elogind is not used, why should I have it on my system.
You should have it because the alternative (i.e., sometimes using basu 
and sometimes using elogind) increases disk space usage -- it's all 
internal, unless there's a bug you shouldn't notice it's using elogind 
instead of basu unless you're doing "guix edit" or such.

Basically,

elogind provides: elogind, loginctl, busctl, libelogind (sd-bus, 
sd-login ...) ...

basu provides: busctl, libbasu

If basu is enought for package it should dependen on basu IMHO.

So my reason is not directly-storage-only, but dependency which
impacts storage in some or another way.
We have package outputs, we can separate the libelogind and busctl from 
the rest. elogind is used, just not in its entirety.

Btw, how much storage are we talking about when having some
packages depend on elogind and some on basu? Is it user
storage or build server/substitute storage concern? 

For basu and elogind itself: 0.9 MiB and 4.2 MiB

For basu and elogind in total: 72.9 MiB and 172.8 MiB.

(See: "guix size").

The latter numbers are a bit misleading, as one of the dependencies is 
'shepherd' and 'libgc', which would be installed anyway by other 
software, and because elogind refers to pkg-config while it probably 
shouldn't.


On "Is it user storage or build serve/substitute storage concern": yes. 
There isn't really a "user / substitute storage" distinction, unless you 
count baked nars. But that's just multiplying the storage by approx. 2 
(ignoring deduplication).


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: usage of basu as requirement for sd-bus

[muradm]

Maxime Devos  writes:


[[PGP Signed Part:Undecided]]

On 30-08-2022 09:59, muradm wrote:


Hello,

basu is sd-bus library extracted from systemd.

Currently, there are two packages depending on it,
which are mako and grimshot.

In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56859,
I suggest switching xdg-desktop-portal-wlr to basu.

In very same issue, Maxime asks to discuss switching
_all_ dependents of elogind to basu.

[1] Some elogind dependents, like wireplumber, as per
code depends on sd-login.h also in module-logind.c.
While I have wireplumber-without-elogind locally,
I don't propose switching it basu, because someone
may want module-logind.c to work.

[2] Currently there are 1461 packages depend on elogind.
First, all of them should be analyzed if they do use
sd-bus only, those can be switched to basu. Then
those using more than sd-bus should be analyzed if
elogind is missing would their functionality be hurt.

If these problems are like [1], then IIUC these problems would
manifest as build errors. Checking for build errors is 
relatively

simple by pushing to a separate branch first, evaluating it on
ci.guix.gnu.org and checking for new build failures.


Not necessarily, simple ifdef or alike will silently drop
anticipiated functionality. Software will build without
errors but functionality expected by users might be
missing.


Because of [1] and [2], I find it not feasible/not
possible to blindly switch _all_ dependents from
elogind to basu.

Do I miss anything else here?


IIUC, everything using basu also works fine with elogind (*), so 
the
'status quo' of still using elogind (for old and new) seems 
harmless

to me (except for size -- basu is smaller).


I don't find the "everything using basu also works fine with 
elogind"

statement/assumption/guess correct, as per contents of elogind and
basu. See above comment for ifdef thingy.



As far as I know, the benefit of 'basu' is using less storage 
(**). 

If most dependents are switched from elogind to basu, then this
benefit can be fulfilled. But if we just do a mix of elogind and 
basu,
then we have both elogind and basu in the store, _increasing_ 
the
storage footprint instead of lowering, which is the opposite of 
the

goal of lowering storage usage.

As such, assuming that lowering the storage footprint was your 
reason
for switching to basu, I think we should either try switching 
_all_
packages to basu or keep using elogind and add elogind instead 
of basu

to new dependents.



My intention is not to have something that is not used. Roughly, 
if

elogind is not used, why should I have it on my system. Basically,

elogind provides: elogind, loginctl, busctl, libelogind (sd-bus, 
sd-login ...) ...

basu provides: busctl, libbasu

If basu is enought for package it should dependen on basu IMHO.

So my reason is not directly-storage-only, but dependency which
impacts storage in some or another way.

Btw, how much storage are we talking about when having some
packages depend on elogind and some on basu? Is it user
storage or build server/substitute storage concern?


Greetings,
Maxime

(*) This is an unverified guess. If disproved, my reasoning 
becomes a

lot weaker.
(**) This is just a guess about what your goal was, maybe you 
had a
different reason in mind. E.g., basu seems to be more active 
than

elogind.

[2. OpenPGP public key --- application/pgp-keys; 
OpenPGP_0x49E3EE22191725EE.asc]...


[[End of PGP Signed Part]]


Thanks in advance,
muradm


signature.asc
Description: PGP signature

Re: usage of basu as requirement for sd-bus

[Maxime Devos]

(**) This is just a guess about what your goal was, maybe you had a 
different reason in mind. E.g., basu seems to be more active than 
elogind.


Oops I misread the dates -- the latest commit in basu was before the 
latest commit in elogind.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: usage of basu as requirement for sd-bus

[Maxime Devos]

On 30-08-2022 09:59, muradm wrote:


Hello,

basu is sd-bus library extracted from systemd.

Currently, there are two packages depending on it,
which are mako and grimshot.

In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56859,
I suggest switching xdg-desktop-portal-wlr to basu.

In very same issue, Maxime asks to discuss switching
_all_ dependents of elogind to basu.

[1] Some elogind dependents, like wireplumber, as per
code depends on sd-login.h also in module-logind.c.
While I have wireplumber-without-elogind locally,
I don't propose switching it basu, because someone
may want module-logind.c to work.

[2] Currently there are 1461 packages depend on elogind.
First, all of them should be analyzed if they do use
sd-bus only, those can be switched to basu. Then
those using more than sd-bus should be analyzed if
elogind is missing would their functionality be hurt.
If these problems are like [1], then IIUC these problems would manifest 
as build errors. Checking for build errors is relatively simple by 
pushing to a separate branch first, evaluating it on ci.guix.gnu.org and 
checking for new build failures.

Because of [1] and [2], I find it not feasible/not
possible to blindly switch _all_ dependents from
elogind to basu.

Do I miss anything else here? 


IIUC, everything using basu also works fine with elogind (*), so the 
'status quo' of still using elogind (for old and new) seems harmless to 
me (except for size -- basu is smaller).


As far as I know, the benefit of 'basu' is using less storage (**).  If 
most dependents are switched from elogind to basu, then this benefit can 
be fulfilled. But if we just do a mix of elogind and basu, then we have 
both elogind and basu in the store, _increasing_ the storage footprint 
instead of lowering, which is the opposite of the goal of lowering 
storage usage.


As such, assuming that lowering the storage footprint was your reason 
for switching to basu, I think we should either try switching _all_ 
packages to basu or keep using elogind and add elogind instead of basu 
to new dependents.


Greetings,
Maxime

(*) This is an unverified guess. If disproved, my reasoning becomes a 
lot weaker.
(**) This is just a guess about what your goal was, maybe you had a 
different reason in mind. E.g., basu seems to be more active than elogind.




OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Idea: Function composition to declare operating-system

[muradm]

Hi,

I had similar problem popping up periodically.
So here are my 10 cents..

Théo Maxime Tyburn  writes:


Hi guix!



[...]



--BEGIN USE_CASE
For example to add jackd to my system I need to add the 
"realtime"
group, add some users to this group and add a 
pam-limits-service. If I
want to remove this functionality from my system using the 
declarative
approach I have to look down my config file for places where I 
added
these things. Usually I partially solve this problem by putting 
comments
to signal the purpose of each code block in the system 
declaration.


But wouldn’t it be better if I just had a function `add-jackd` 
that takes an
operating-system instance and returns the os with the extra 
functionalities ?

--END USE_CASE


To clarify, do you ask that in the end of the day, some where
in (gnu services ...) there should be exported `add-jackd`
function? If so, I beleive that this will increase cross
dependency between things, thus decreasing flexibility.

Imagine `add-jackd` maintainer should always keep track on
what is being added into guix, that potentially may cause
conflict with jackd and/or require adjustments in `add-jackd`
function implementation.

Also, IMHO, implementation of `add-jackd` would be very
much opinionated.



So that was the purpose of the experimentation. It didn’t turn 
out to be
too complicated to implement. At least for my use case, I just 
needed to add two helper
functions to extend users and services fields. The rest is 
handled directly by
record inheritance and by accessing the fields of the input 
operating-system.


The final declaration looks like this:

((apply compose (reverse os-functions)) minimal-os)



[...]



(define* (extend-operating-system-services os services #:key 
(drop '()) (keep '()))

  (append (filter (lambda (service)
	(not (member (service-type-name (service-kind 
service))
 (filter (lambda (s) (not (member 
s keep)))
		 (append drop 
%fixed-system-service-types)

  (operating-system-services os))
  services))



I suppose this could be useful to have it in guix toolbox,
although I would prefer to have (required '(account activate ...))
or (required %fixed-system-service-types) optional argument,
instead of refering to global constant 
%fixed-system-service-types,

which might not satisfy everyone requirements.

and also force keeping or dropping of some services if needed. 
The list

of services that gets duplicated seems to be this one:

(define %fixed-system-service-types
  '(account activate boot cleanup etc file-systems firmware 
  fstab guix host-name linux-bare-metal linux-builder pam 
  profile root-file-system session-environment setuid-program 
  shepherd-root system user-processes))


I generated the list by just checking which services get 
duplicated, so I am not

very sure about it. There surely is a better way to get it.

Anyway I can now define a function adding desktop 
functionalities:


(define (x-os os)
  (operating-system
   (inherit os)
   (services
(extend-operating-system-services
 os
 (list
  ;; slim display manager
  (service slim-service-type
   (slim-configuration
(display ":0")
(vt "vt7")
(theme %default-slim-theme)
(theme-name %default-slim-theme-name)
(xorg-configuration
 (xorg-configuration
  (keyboard-layout 
(operating-system-keyboard-layout os)))

 #:drop '(gdm)))
   (packages (cons*
  ;; window managers
  i3-wm python-py3status
  emacs-nc-exwm-xdg
  (operating-system-packages os)
  

Of course there is room for some macros to make this more 
elegant, but

this is the rough idea.

In a way it feels like treating the operating-system like a 
service
you can extend. Maybe it would even make sense to implement this 
as a

service ? Not sure about that.

It seems it would also be reasonable to have something like an
operating-system-configuration record and a way to compose some 
before

putting them into an operating-system record (it seems to be the
approach rde `features` are based on). But I felt too lazy to 
copy all the
fields from the operating-system record definition. There might 
be a

way to get all the fields programatically and define a
record/configuration though.

Anyway, what do you think about this functionality? Have you 
already experimented with similar things?

Did I reinvent the wheel? Is there a better approach?


Did you try using (modify-services ...)? Basically, you can
achieve similar goal within services list only with it.


Anyway that was a very fun hacking session :)

Happy Hacking!

Théo


Thanks in advance,
muradm

usage of basu as requirement for sd-bus

[muradm]

Hello,

basu is sd-bus library extracted from systemd.

Currently, there are two packages depending on it,
which are mako and grimshot.

In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56859,
I suggest switching xdg-desktop-portal-wlr to basu.

In very same issue, Maxime asks to discuss switching
_all_ dependents of elogind to basu.

[1] Some elogind dependents, like wireplumber, as per
code depends on sd-login.h also in module-logind.c.
While I have wireplumber-without-elogind locally,
I don't propose switching it basu, because someone
may want module-logind.c to work.

[2] Currently there are 1461 packages depend on elogind.
First, all of them should be analyzed if they do use
sd-bus only, those can be switched to basu. Then
those using more than sd-bus should be analyzed if
elogind is missing would their functionality be hurt.

Because of [1] and [2], I find it not feasible/not
possible to blindly switch _all_ dependents from
elogind to basu.

Do I miss anything else here?

Thanks in advance,
muradm


signature.asc
Description: PGP signature