Re: gcc-toolchain is missing libstdc++.so

[Kaelyn]

--- Original Message ---
On Thursday, May 4th, 2023 at 9:50 PM, John Kehayias 
 wrote:

> > I have similar use cases of FHS containers to run binaries (primarily
> > games). I recently ran into the issue of gcc:lib going away and no
> > output from a visible package providing libstdc++. My current
> > workaround was to implement a replacement for specifications->manifest
> > that could handle packages and '(package "output") pairs in addition
> > to strings, so that I could include `(,(@@ (gnu packages gcc) gcc)
> > "lib") in place of "gcc:lib". Internally it resolves package strings
> > to packages with specification->package, then passes the package and
> > optional output specifier to package->manifest-entry. But I digress a
> > little...
> 
> 
> Nice little hack Kaelyn, would you mind sharing somewhere? I wonder if
> this should be something we should have more easily anyway.

I wasn't sure the best place to share it, so I've attached my "run" script for 
running the binary download of PolyMC in a container. It is both a shell script 
and a guix package manifest, and is the one place so far I've worked around the 
removal of gcc:lib. The main program-specific bits are what CMD defaults to and 
which packages need to be included (most of the various shares are to get 
things like hardware 3D, pulseaudio, and dbus working and aren't all always 
needed). It also contains the original manifest commented-out for comparison. 
Hope it can be of help to folks!

Cheers,
Kaelyn

run
Description: Binary data

Re: GSoC news

[Sarthak Shah]

Hello Guix,

Thanks for having me onboard!
I hope that my project will prove useful to Guix.

My project is about implementing Parameterized Packages, which will add
optional Gentoo USE flag-like functionality to Guix packages. This will not
only help reduce package size but also provide users with greater choice
with how they'd like to use their packages. I believe that this should also
help somewhat relieve the issue of the denseness of guix's dependency
graphs, which was recently being discussed here on the mailing list.

Due to the nature of this project, it will involve taking a lot of inputs
from the Guix community, and thus you can expect a regular thread or two
with updates/feature discussions on this topic in the mailing list.

Once again, thank you for this wonderful opportunity!

Sincerely,
Sarthak (cel7t)

On Fri, 5 May, 2023, 01:29 Pjotr Prins,  wrote:

> Welcome Sarthak!
>
> On Thu, May 04, 2023 at 09:22:47PM +0200, Gábor Boskovits wrote:
> >Hello guix,
> >We have some news about GSoC, the community is accepting a new intern,
> >Sarthak. The agreed on internship project title is Parameterized
> >Packages for GNU Guix. Welcome on board, and we are looking forward to
> >working together.
> >As there was quite a lot of competition for places this year we only
> >got one internship slot assigned, but we are encouraging all
> >prospective interns to stay around, and try again in the next round.
> >The distributed substitutes proposals are still on the radar, and  it
> >would be nice to keep interested people around.
> >Regards,
> >g_bor
>
>

Re: gcc-toolchain is missing libstdc++.so

[John Kehayias]

Hi all,

> I have similar use cases of FHS containers to run binaries (primarily
> games). I recently ran into the issue of gcc:lib going away and no
> output from a visible package providing libstdc++. My current
> workaround was to implement a replacement for specifications->manifest
> that could handle packages and '(package "output") pairs in addition
> to strings, so that I could include `(,(@@ (gnu packages gcc) gcc)
> "lib") in place of "gcc:lib". Internally it resolves package strings
> to packages with specification->package, then passes the package and
> optional output specifier to package->manifest-entry. But I digress a
> little...

Nice little hack Kaelyn, would you mind sharing somewhere? I wonder if
this should be something we should have more easily anyway.

On Thu, May 04, 2023 at 12:14 PM, Katherine Cox-Buday wrote:

> On 5/4/23 11:33 AM, Kaelyn wrote:
>
>> Regarding solutions, I would prefer to have libstdc++ in it's own
>> package or output rather than bundled into gcc-toolchain:out; it
>> feels messy and against the grain of isolating programs in
>> containers if I have to make the gcc and g++ compilers available in
>> the container in order to run a program that needs libstdc++.
>
> +1. I recently ran into this as well and went looking for it.
>
> I think a good reason to give libstdc++ its own output is that this
> question continually gets asked.

That sounds reasonable to me as well. I would think the make-libstdc++
procedure would work for this, but as I detailed in my other message,
I'm not sure why it seems to be missing symbols. We would have just
what we need there and could just expose some public package versions
through that or leave it similar to how it is and document (so it is
more of an advanced or edge case scenario and not have more people
going that way when what they really want is the actual gcc-toolchain
package).

John

Re: GSoC news

[Pjotr Prins]

Welcome Sarthak!

On Thu, May 04, 2023 at 09:22:47PM +0200, Gábor Boskovits wrote:
>Hello guix,
>We have some news about GSoC, the community is accepting a new intern,
>Sarthak. The agreed on internship project title is Parameterized
>Packages for GNU Guix. Welcome on board, and we are looking forward to
>working together.
>As there was quite a lot of competition for places this year we only
>got one internship slot assigned, but we are encouraging all
>prospective interns to stay around, and try again in the next round.
>The distributed substitutes proposals are still on the radar, and  it
>would be nice to keep interested people around.
>Regards,
>g_bor

GSoC news

[Gábor Boskovits]

Hello guix,

We have some news about GSoC, the community is accepting a new intern,
Sarthak. The agreed on internship project title is Parameterized Packages
for GNU Guix. Welcome on board, and we are looking forward to working
together.

As there was quite a lot of competition for places this year we only got
one internship slot assigned, but we are encouraging all prospective
interns to stay around, and try again in the next round. The distributed
substitutes proposals are still on the radar, and  it would be nice to keep
interested people around.

Regards,
g_bor

Re: OCaml bootstrap

[Simon Tournier]

Hi Julien,

On jeu., 04 mai 2023 at 12:01, Julien Lepiller  wrote:

> Have a grep-for-build that is never updated? Build camlboot once and
> repackage the binary (making it a bootstrap seed)? 

Yes, something like that.

Well, the packages that camlboot depends on barely change because most
of them are “core-updates” packages.  However, still.

Some packages (autotools) use guile-3.0/pinned instead of guile-3.0.
Other gdb/pinned (rust).  Etc.

Therefore we could use something like /pinned (or -boot or else) for
building camlboot once.  This allows transparency and being able to
rebuild if the worst is necessary.

But then, we consider the binary as the bootstrap seed of OCaml world.

Maybe, it could be discussed with the OCaml community.

Well, I do not know if it is worth but somehow I think that a similar
strategy as MES and bootstrapping C could be applied for camlboot and
bootstrapping OCaml.  Something like gnu/packages/ocaml-commencement.scm
that bootstraps the OCaml world and this would depend on packages that
are tweaked with a lot of care.  Similarly as the MES bootstrap chain.


Cheers,
simon

Re: gcc-toolchain is missing libstdc++.so

[Katherine Cox-Buday]

On 5/4/23 11:33 AM, Kaelyn wrote:


Regarding solutions, I would prefer to have libstdc++ in it's own package or 
output rather than bundled into gcc-toolchain:out; it feels messy and against 
the grain of isolating programs in containers if I have to make the gcc and g++ 
compilers available in the container in order to run a program that needs 
libstdc++.


+1. I recently ran into this as well and went looking for it.

I think a good reason to give libstdc++ its own output is that this 
question continually gets asked.


--
Katherine

Re: gcc-toolchain is missing libstdc++.so

[John Kehayias]

Hi again,

On Thu, May 04, 2023 at 11:19 AM, John Kehayias wrote:

> Thanks for opening this and cc'ing; this has come up with some
> frequency on IRC, especially recently. In discussing there today, the
> current reasoning is that usually one will just call g++ which knows
> how to find libstdc++. So, gcc-toolchain does not include gcc:lib as
> part of what it makes available.
>

I tried locally just adding gcc:lib as an input for gcc-toolchain and
that does the trick. And since it is just a union-build, very quick to
try out :)

guix size reports an increase in gcc-toolchain as 0.1 MiB with gcc:lib
included.

> I think what we (and when this comes up, others) are getting at are
> some edge cases or different use cases where one wants to directly get
> at libstdc++. Previously it was more direct to use gcc:lib; of course
> one still can in code and/or cli with the proper call. For example,
> guix build -e "(@@ (gnu packages gcc) gcc)" will download/build/show
> the lib output of the (hidden) gcc package. Though I'm not sure how to
> select just the lib output here.
>
> My use case currently is in the FHS container where a binary wants to
> find some libraries directly. Previously one would include the gcc:lib
> package output in the guix shell call. Now some of those libraries can
> be found elsewhere, like libgccjit, but libstdc++ seems to be the
> trickier one. Open to other suggestions/workarounds, or thoughts on if
> it is worthwhile to include gcc:lib in the gcc-toolchain package (or
> make a gcc-toolchain:lib output?).
>

I tried with my local gcc-toolchain modification and this gets me what
I wanted.

On that note, I forgot to bring up the problem I had with using
make-libstdc++: it does not seem to build the same libstdc++ as
included in the gcc package. The doc string for that procedure notes
that this is meant to be used when using non-gcc toolchains, but we
also have the libstdc++ variable which seems to suggest that
(make-libstdc++ gcc) should be the same library as in gcc.

I'm not sure the difference in looking at the package definitions, but
I don't really know this stuff. Here's an example of the difference I
was finding:

I was running something and it complained that

--8<---cut here---start->8---
 symbol lookup error: : undefined symbol: 
_ZNSt18condition_variableD1Ev, version GLIBCXX_3.4.11
--8<---cut here---end--->8---

Indeed, looking at the libstdc++ I used via (or could have used
libstdc++ here directly since I used the default gcc):

--8<---cut here---start->8---
guix shell -e "(begin (use-modules (gnu packages gcc)) (make-libstdc++ gcc))"
--8<---cut here---end--->8---

I see

--8<---cut here---start->8---
$strings 
/gnu/store/6897bpw5858bdng744ddqw8rrqjb4frr-libstdc++-11.3.0/lib/libstdc++.so | 
grep "_ZNSt18condition_variableD1Ev"
--8<---cut here---end--->8---

while for gcc:lib it is defined

--8<---cut here---start->8---
$ strings 
/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/libstdc++.so | 
grep "_ZNSt18condition_variableD1Ev"
_ZNSt18condition_variableD1Ev
--8<---cut here---end--->8---

and using that libstdc++ does not result in that error.

Is make-libstdc++ not meant to be used/mixed with e.g. gcc-toolchain?
Is this expected that it is a different library produced or is this a
bug?

Thanks!
John

Re: gcc-toolchain is missing libstdc++.so

[Kaelyn]

Hi,

--- Original Message ---
On Thursday, May 4th, 2023 at 3:26 PM, John Kehayias 
 wrote:

> 
> Hi Christopher,
> 
> On Thu, May 04, 2023 at 11:05 AM, Christopher Rodriguez wrote:
> 
> > Sorry for the spam; Resending this without the bugs address, but with
> > the issue's address.
> > 
> > Christopher Rodriguez yewsc...@gmail.com writes:
> > 
> > > Hello All,
> > > 
> > > I noticed today that libstdc++.so.1 (and some others), which used to be
> > > part of gcc:lib, are not included in any of the outputs of the
> > > superceding `gcc-toolchain` package.
> > > 
> > > Is there another method for getting these needed shared libraries in a
> > > guix system at this point? It's entirely possible I'm missing something.
> > > 
> > > I am CCing guix-devel@gnu.org per podiki[m]'s request.
> > > 
> > > Thanks!
> 
> 
> Thanks for opening this and cc'ing; this has come up with some
> frequency on IRC, especially recently. In discussing there today, the
> current reasoning is that usually one will just call g++ which knows
> how to find libstdc++. So, gcc-toolchain does not include gcc:lib as
> part of what it makes available.
> 
> I think what we (and when this comes up, others) are getting at are
> some edge cases or different use cases where one wants to directly get
> at libstdc++. Previously it was more direct to use gcc:lib; of course
> one still can in code and/or cli with the proper call. For example,
> guix build -e "(@@ (gnu packages gcc) gcc)" will download/build/show
> the lib output of the (hidden) gcc package. Though I'm not sure how to
> select just the lib output here.
> 
> My use case currently is in the FHS container where a binary wants to
> find some libraries directly. Previously one would include the gcc:lib
> package output in the guix shell call. Now some of those libraries can
> be found elsewhere, like libgccjit, but libstdc++ seems to be the
> trickier one. Open to other suggestions/workarounds, or thoughts on if
> it is worthwhile to include gcc:lib in the gcc-toolchain package (or
> make a gcc-toolchain:lib output?).

I have similar use cases of FHS containers to run binaries (primarily games). I 
recently ran into the issue of gcc:lib going away and no output from a visible 
package providing libstdc++. My current workaround was to implement a 
replacement for specifications->manifest that could handle packages and 
'(package "output") pairs in addition to strings, so that I could include 
`(,(@@ (gnu packages gcc) gcc) "lib") in place of "gcc:lib". Internally it 
resolves package strings to packages with specification->package, then passes 
the package and optional output specifier to package->manifest-entry. But I 
digress a little...

Regarding solutions, I would prefer to have libstdc++ in it's own package or 
output rather than bundled into gcc-toolchain:out; it feels messy and against 
the grain of isolating programs in containers if I have to make the gcc and g++ 
compilers available in the container in order to run a program that needs 
libstdc++.

Cheers,
Kaelyn

Re: gcc-toolchain is missing libstdc++.so

[John Kehayias]

Hi Christopher,

On Thu, May 04, 2023 at 11:05 AM, Christopher Rodriguez wrote:
>
> Sorry for the spam; Resending this without the bugs address, but with
> the issue's address.
>
> Christopher Rodriguez  writes:
>
>>
>> Hello All,
>>
>> I noticed today that libstdc++.so.1 (and some others), which used to be
>> part of gcc:lib, are not included in any of the outputs of the
>> superceding `gcc-toolchain` package.
>>
>> Is there another method for getting these needed shared libraries in a
>> guix system at this point? It's entirely possible I'm missing something.
>>
>> I am CCing guix-devel@gnu.org per podiki[m]'s request.
>>
>> Thanks!

Thanks for opening this and cc'ing; this has come up with some
frequency on IRC, especially recently. In discussing there today, the
current reasoning is that usually one will just call g++ which knows
how to find libstdc++. So, gcc-toolchain does not include gcc:lib as
part of what it makes available.

I think what we (and when this comes up, others) are getting at are
some edge cases or different use cases where one wants to directly get
at libstdc++. Previously it was more direct to use gcc:lib; of course
one still can in code and/or cli with the proper call. For example,
guix build -e "(@@ (gnu packages gcc) gcc)" will download/build/show
the lib output of the (hidden) gcc package. Though I'm not sure how to
select just the lib output here.

My use case currently is in the FHS container where a binary wants to
find some libraries directly. Previously one would include the gcc:lib
package output in the guix shell call. Now some of those libraries can
be found elsewhere, like libgccjit, but libstdc++ seems to be the
trickier one. Open to other suggestions/workarounds, or thoughts on if
it is worthwhile to include gcc:lib in the gcc-toolchain package (or
make a gcc-toolchain:lib output?).

Thanks all!
John

Re: Reverting d477018b57 "gnu: poetry: Update to 1.1.12."

[Tanguy LE CARROUR]

Hi John,


Quoting John Kehayias (2023-05-04 17:09:14)
> On Wed, May 03, 2023 at 09:49 AM, Tanguy LE CARROUR wrote:
> > I noticed yesterday that Poetry was broken:
> > .
> >
> > I might have spotted it earlier if I had spend time testing `core-update`.
> > My bad!
> >
> 
> Yes, I noticed that too but fixing the current version of Poetry sent
> me down quite a rabbit hole of dependencies and updates.

Oh my G…uix! O_o'

I started working on it yesterday, but stop after:

  gnu: Add python-pyproject-hooks.
  gnu: python-virtualenv: Update to 20.22.0.
  gnu: Add python-poetry-plugin-export.

*ERF*! Not even close! :-(


> I didn't emerge in time for the core-updates merge. There might be a better 
> way
> than causing a python world rebuild, but this is my current series
> which does have Poetry building (might as well do the updates I
> figure): 
> 
> The proper polishing and bootstrapping updates is WIP, but that series
> will get you Poetry building, after lots of other rebuilding :)

Or, I could write a Poetry v1.1.12 package definition in my channel.
Selfish, but efficient. Selfishient?!


> Right, probably a typo in the commit message.
> 
> > Unfortunately, I have no time to work on this right now. Would it be
> > possible to revert the change? Or should I submit a patch to downgrade it?
> 
> I haven't tried if a simple revert will build given all the other
> changes from core-updates. If that works that would be a good stopgap.
> Do you know if that works and is simple enough? Or can you test?

No, I haven't tried! I don't even know if many packages actually depend
on `poetry`. I'm expecting dependencies on `python-poetry-core`.

I'll give it a try at the week end!

Cheers,

-- 
Tanguy

Re: Reverting d477018b57 "gnu: poetry: Update to 1.1.12."

[John Kehayias]

Hi Tanguy,

On Wed, May 03, 2023 at 09:49 AM, Tanguy LE CARROUR wrote:

> Hi Guix,
>
> I noticed yesterday that Poetry was broken:
> .
>
> I might have spotted it earlier if I had spend time testing `core-update`.
> My bad!
>

Yes, I noticed that too but fixing the current version of Poetry sent
me down quite a rabbit hole of dependencies and updates. I didn't
emerge in time for the core-updates merge. There might be a better way
than causing a python world rebuild, but this is my current series
which does have Poetry building (might as well do the updates I
figure): 

The proper polishing and bootstrapping updates is WIP, but that series
will get you Poetry building, after lots of other rebuilding :)

> The problematic commit seems to be d477018b57 "gnu: poetry: Update to 
> 1.1.12.".
>
> What also questions me is the fact that the commit message states that
> it's an upgrade to `1.1.12` when it's the current version and it's
> actually an upgrade to `1.4.2`.
>

Right, probably a typo in the commit message.

> Unfortunately, I have no time to work on this right now. Would it be
> possible to revert the change? Or should I submit a patch to downgrade it?
>
> Cheers,

I haven't tried if a simple revert will build given all the other
changes from core-updates. If that works that would be a good stopgap.
Do you know if that works and is simple enough? Or can you test?

Thanks,
John

Re: gcc-toolchain is missing libstdc++.so

[Christopher Rodriguez]

Sorry for the spam; Resending this without the bugs address, but with
the issue's address.

Christopher Rodriguez  writes:

> [[PGP Signed Part:Undecided]]
>
> Hello All,
>
> I noticed today that libstdc++.so.1 (and some others), which used to be
> part of gcc:lib, are not included in any of the outputs of the
> superceding `gcc-toolchain` package.
>
> Is there another method for getting these needed shared libraries in a
> guix system at this point? It's entirely possible I'm missing something.
>
> I am CCing guix-devel@gnu.org per podiki[m]'s request.
>
> Thanks!

-- 

Christopher Rodriguez
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


signature.asc
Description: PGP signature

gcc-toolchain is missing libstdc++.so

[Christopher Rodriguez]

Hello All,

I noticed today that libstdc++.so.1 (and some others), which used to be
part of gcc:lib, are not included in any of the outputs of the
superceding `gcc-toolchain` package.

Is there another method for getting these needed shared libraries in a
guix system at this point? It's entirely possible I'm missing something.

I am CCing guix-devel@gnu.org per podiki[m]'s request.

Thanks!

-- 
Christopher Rodriguez
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


signature.asc
Description: PGP signature

Re: Outdated dicod-service example in manual

[Nathaniel Nicandro]

Ludovic Courtès  writes:

> Hi Nathaniel,
>
> Apologies for the delay!
>
> Nathaniel Nicandro  skribis:
>
>> First off, I want to say thanks to all the Guix contributors.  I've
>> really enjoyed my time tinkering with my system!  This is my first
>> post
>> to the mailing list after using Guix as my main operating system for
>> the
>> past few years.
>
> Nice, welcome!  :-)
>
>> I've found that when I tried to use the example configuration for
>> the
>> dicod-service in the manual
>> (https://guix.gnu.org/manual/en/html_node/Miscellaneous-Services.html#Dictionary-Service)
>> I wasn't able to get the wordnet dictionary working at all.
>
> Oh.  (BTW, note that this is the manual for the latest release; when
> in
> doubt you can also add “/devel” to the URL to see the manual of the
> current development head:
> .)
>

Thanks for the tip.

>> I was able to get it working for my use case with the following 
>> configuration:
>>
>> (dicod-configuration
>>(handlers
>> (list (dicod-handler
>>(name "wordnet")
>>(module "wordnet")
>>(options (list #~(string-append "wnhome=" #$wordnet))
>>(databases
>> (list (dicod-database
>>(name "wordnet")
>>(handler "wordnet")
>>(complex? #t)
>>(options (list "merge-defs")))
>>   %dicod-database:gcide)))
>>
>> Should I go ahead and make a documentation change patch or would there
>> be another example that would be preferred?
>
> Fixing the current documentation would be most welcome!  And if you
> have
> other examples in mind, we can add them too.

I'll sumbit a patch to fix the example.  I'll look out for other
examples while I browse the documentation and update my system.  All
that I've looked at so far has worked out for me, except for this.

>
> We could also add the ‘dicod-database’ definition for WordNet right
> into
> (gnu services dict), so it’s readily usable, like that of GCIDE.

Doing this would mean that we also have to do something about the
`dicod-handler` definition since the database definition depends on it.
Maybe allow a `dicod-handler` in the `handler` field of a `dicod-database` so 
that the WordNet database definition can be self-contained without having to 
provide a handler definition in the `handlers` field of a 
`dicod-configuration`?  This way we can do as you say.

>
> Thanks!
>
> Ludo’.


-- 
Nathaniel

Re: Deploying experimental versions of Guix

[Csepp]

david larsson  writes:

> On 2023-05-02 15:44, Felix Lechner via "Development of GNU Guix and the 
> GNU System distribution." wrote:
>> Hi,
>> 
>> I'd like to test changes to (gnu system pam). How may I configure my
>> system, preferably using "deploy," please, while also pulling from my
>> custom channels?
>
> Hi Felix,
>
> I think creating a custom profile with a channels file containing a 
> 'guix channel pointing to your modified guix version, and more custom 
> channels as you wish (add to the same list), should solve it:
>
> #+begin_src bash
> guix pull -C custom-channels.scm --profile=/tmp/myguix-and-channels 
> --disable-authentication
> #+end_src

You could also use that file with guix time-machine for one off tests.

Free Style Nginx Service Type

[Andrew Tropin]

There was a few flaws in the current implementation of nginx guix
service type, for example the one described here:
https://issues.guix.gnu.org/37388

There are other things, for example it's really hard or even impossible
to implement some cases in a sane way: adding rtmp context and later
extending it from other guix services and probably much more.

In the report above created by Ludo, he mentioned an idea of using
s-expressions for representing nginx configuration, like sxml for xml.

I prototyped such implementation and even migrated my personal nginx
instance to it.  It works quite well and implementation of service type
became really simple:
https://git.sr.ht/~abcdw/rde/tree/e5bcfc0654/src/rde/system/services/web.scm#L43

It allows to generate configuration in much more programmatic way and
have much less boilerplate.  My real-world nginx configuration itself:
https://git.sr.ht/~abcdw/trop.in/tree/4eb2e07d38/src/tropin/machines.scm#L24

which expands to:
--8<---cut here---start->8---
user nginx nginx;
pid /var/run/nginx/pid;

load_module 
/gnu/store/19apmplkgpmnvn963cfydgjhhnvpf9fs-nginx-rtmp-module-1.2.2/etc/nginx/modules/ngx_rtmp_module.so;

events {
}

http {
  server_tokens off;
  proxy_temp_path /var/run/nginx/proxy_temp;
  include 
/gnu/store/lavf43rgvvmi9a6hqi8f2lmmavipq0vd-nginx-1.23.3/share/nginx/conf/mime.types;
  server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

ssl_certificate /srv/nginx/ssl/hundredrps.pem;
ssl_certificate_key /srv/nginx/ssl/hundredrps.key;
ssl_protocols TLSv1.2;

server_name guix.trop.in guix.ygg.trop.in;

location / {
  proxy_pass https://guix.gnu.org;
  proxy_set_header HOST guix.gnu.org;
}
  }

  server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

ssl_certificate /srv/nginx/ssl/hundredrps.pem;
ssl_certificate_key /srv/nginx/ssl/hundredrps.key;
ssl_protocols TLSv1.2;

server_name ci.guix.trop.in ci.guix.ygg.trop.in;

location / {
  proxy_pass https://ci.guix.gnu.org;
  proxy_set_header HOST ci.guix.gnu.org;
}
  }

  server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

ssl_certificate /srv/nginx/ssl/hundredrps.pem;
ssl_certificate_key /srv/nginx/ssl/hundredrps.key;
ssl_protocols TLSv1.2;

server_name issues.guix.trop.in issues.guix.ygg.trop.in;

location / {
  proxy_pass https://issues.guix.gnu.org;
  proxy_set_header HOST issues.guix.gnu.org;
}
  }

  server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

ssl_certificate /etc/letsencrypt/live/trop.in/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/trop.in/privkey.pem;
ssl_protocols TLSv1.2;

server_name trop.in *.trop.in;

location /rde/meetups {
  return 302 https://meet.jit.si/rde-meetup;
}
location / {
  root /srv/nginx/trop.in;
  if ($request_uri ~ ^/(.*)\.html(\?|$)) {
return 302 /$1;
  }
  try_files $uri $uri.html $uri/ =404;
}
  }

  server {
listen 80;
listen [::]:80;

server_name files.trop.in files.ygg.trop.in;
root /srv/nginx/public;
autoindex on;
  }
}

rtmp {
  server {
listen 1935;
chunk_size 4096;
application live {
  live on;
  push rtmp://a.rtmp.youtube.com/live2/key1;
  push rtmp://diode.zone:1935/live/key2;
  record off;
}
  }
}
--8<---cut here---end--->8---



The configuration structure and merge logic is visible in tests:
https://git.sr.ht/~abcdw/rde/tree/e5bcfc0654/tests/rde/serializers/nginx-test.scm#L159
https://git.sr.ht/~abcdw/rde/tree/e5bcfc0654/src/rde/serializers/nginx.scm#L20

The merge logic have a few problems rn, which I highlighted in those
xtests: https://git.sr.ht/~abcdw/rde/commit/e5bcfc0654


LMKWYT!

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: OCaml bootstrap

[Julien Lepiller]

Le 4 mai 2023 10:41:18 GMT+02:00, Simon Tournier  a 
écrit :
>Hi,
>
>On Wed, 03 May 2023 at 23:25, Julien Lepiller  wrote:
>
>>>Julien, do you happen to know if there are plans to make camlboot more
>>>capable so it can be used to build newer versions of OCaml?  Maybe
>>>something to discuss with Nathanaëlle Courant and Gabriel Scherer?
>
>> We had some discussion here, but there's still some work to do:
>> https://github.com/Ekdohibs/camlboot/issues/59
>
>Cool!
>
>Just to be sure, the discussion is from one year ago, right?  Any
>update?

No updates. I don't think any of us worked more on that than you can read.

>
>Well, rehashing, I think we could consider a full-bootstrap from source
>for OCaml.  Whatever the seed (4.07 or 4.09), we could consider it as
>done and fixed.  Here all the “inputs”:
>
>--8<---cut here---start->8---
> "bash-minimal@5.1.16" 
> "bash-minimal@5.1.16" 
> "binutils@2.38" 
> "bzip2@1.0.8" 
> "coreutils@9.1" 
> "diffutils@3.8" 
> "file@5.44" 
> "findutils@4.9.0" 
> "gawk@5.2.1" 
> "gcc@11.3.0" 
> "glibc-utf8-locales@2.35" 
> "glibc@2.35" 
> "grep@3.8" 
> "guile@3.0.9" 
> "gzip@1.12" 
> "ld-wrapper@0" 
> "libffi@3.4.4" 
> "libgc@8.2.2"
> "libunistring@1.0" 
> "make@4.3" 
> "patch@2.7.6" 
> "pkg-config@0.29.2" 
> "sed@4.8" 
> "tar@1.34" 
> "xz@5.2.8" 
>--8<---cut here---end--->8---
>
>Only guile-3.0 is not a package deep in the graph.  All the others are.
>My question is: do we want to rebuild camlboot and then all the OCaml
>world each time we update one of these “inputs“?
>
>For example, what does it bring on the table to rebuild camlboot because
>grep had been updated?

I don't understand what you suggest here. I think grep is used in the Makefile, 
so we can't just remove it from the inputs. What would not building camlboot 
when grep is updated look like?

Have a grep-for-build that is never updated? Build camlboot once and repackage 
the binary (making it a bootstrap seed)?

>
>
>Cheers,
>simon

Re: package transformation and “guix graph”?

[Simon Tournier]

Hi,

(Well, something appears to me weird: rebuild Gnash which is a C++
software using another toolchain implies a Rust-world rebuild.)


On Wed, 03 May 2023 at 23:36, Ludovic Courtès  wrote:

> Note that it’s not the same version (0.12.0 vs. 0.8.1), but the result
> is the same with 0.8.  The reason is that Rust packages aren’t like
> “real” packages; the sources are eventually aggregated in whatever
> package needs them.

Hum, ok.



>> $ guix graph --path gnash -e '(@@ (gnu packages gcc) gcc-11)' -t bag 
>> guix graph: error: no path from 'gnash@0.8.11-0.583ccbc' to 'gcc@11.3.0'
>
> That’s because you’re not looking at the “right” GCC 11 package object:

Hum, this “right” looks weird to me.  I read from (gnu packages gcc):

--8<---cut here---start->8---
;; Note: When changing the default gcc version, update
;;   the gcc-toolchain-* definitions.
(define-public gcc gcc-11)
--8<---cut here---end--->8---

Then from (gnu packages commencent):

--8<---cut here---start->8---
(define gcc-boot0
  (package
(inherit gcc)
--8<---cut here---end--->8---

Then,

--8<---cut here---start->8---
(define gcc-final
  ;; The final GCC.
  (package (inherit gcc-boot0)
--8<---cut here---end--->8---

And,

--8<---cut here---start->8---
(define-public gcc-toolchain
  (make-gcc-toolchain gcc-final))
--8<---cut here---end--->8---

Well, I am lost with the difference between gcc-final and gcc-11.

Last, what lost me is this:

--8<---cut here---start->8---
(define-public gcc-toolchain-4.8
  (make-gcc-toolchain gcc-4.8))

(define-public gcc-toolchain-4.9
  (make-gcc-toolchain gcc-4.9))

(define-public gcc-toolchain-5
  (make-gcc-toolchain gcc-5))

(define-public gcc-toolchain-6
  (make-gcc-toolchain gcc-6))

(define-public gcc-toolchain-7
  (make-gcc-toolchain gcc-7))

(define-public gcc-toolchain-8
  (make-gcc-toolchain gcc-8))

(define-public gcc-toolchain-9
  (make-gcc-toolchain gcc-9))

(define-public gcc-toolchain-10
  (make-gcc-toolchain gcc-10))

(define-public gcc-toolchain-11
  gcc-toolchain)

(define-public gcc-toolchain-12
  (make-gcc-toolchain gcc-12))
--8<---cut here---end--->8---

compared to ’gcc-toolchain’ which uses gcc-final.  Why not gcc-11 as all
the others?  It would make it consistent with the rest, no?


Cheers,
simon

Re: OCaml bootstrap

[Simon Tournier]

Hi,

On Wed, 03 May 2023 at 23:25, Julien Lepiller  wrote:

>>Julien, do you happen to know if there are plans to make camlboot more
>>capable so it can be used to build newer versions of OCaml?  Maybe
>>something to discuss with Nathanaëlle Courant and Gabriel Scherer?

> We had some discussion here, but there's still some work to do:
> https://github.com/Ekdohibs/camlboot/issues/59

Cool!

Just to be sure, the discussion is from one year ago, right?  Any
update?


Well, rehashing, I think we could consider a full-bootstrap from source
for OCaml.  Whatever the seed (4.07 or 4.09), we could consider it as
done and fixed.  Here all the “inputs”:

--8<---cut here---start->8---
 "bash-minimal@5.1.16" 
 "bash-minimal@5.1.16" 
 "binutils@2.38" 
 "bzip2@1.0.8" 
 "coreutils@9.1" 
 "diffutils@3.8" 
 "file@5.44" 
 "findutils@4.9.0" 
 "gawk@5.2.1" 
 "gcc@11.3.0" 
 "glibc-utf8-locales@2.35" 
 "glibc@2.35" 
 "grep@3.8" 
 "guile@3.0.9" 
 "gzip@1.12" 
 "ld-wrapper@0" 
 "libffi@3.4.4" 
 "libgc@8.2.2"
 "libunistring@1.0" 
 "make@4.3" 
 "patch@2.7.6" 
 "pkg-config@0.29.2" 
 "sed@4.8" 
 "tar@1.34" 
 "xz@5.2.8" 
--8<---cut here---end--->8---

Only guile-3.0 is not a package deep in the graph.  All the others are.
My question is: do we want to rebuild camlboot and then all the OCaml
world each time we update one of these “inputs“?

For example, what does it bring on the table to rebuild camlboot because
grep had been updated?


Cheers,
simon

Re: Build dependency inflation

[Simon Tournier]

Hi,

On Wed, 03 May 2023 at 23:10, Ludovic Courtès  wrote:

> We could also couple the actual graph with data such as individual
> output size.

Oh, that’s a cool idea: apply network algorithms to a weighted graph.

It looks like a nice student project. :-)

Cheers,
simon

Re: Help! Having troubles testing my generalization of home-redshift-service

[Josselin Poiret]

Hi Gabriel,

Gabriel Wicki  writes:

> Hi y'all!
>
> I've been working on a patch on generalizing the
> home-redshift-service-type to also work under wayland.  I've created the
> following patch but am now running into difficulties testing it.
>
> I've created two minimalist system configurations (one for i3 and one
> for sway) and run them like so:
> $ $(./pre-inst-env guix system vm sys-i3-minimal.scm)
>
> In that VM i am unable to
> $  guix home reconfigure my-config.scm
> due to `home-night-time-service-type` allegedly being an "unbound
> variable".  Investigating with `guix repl` and just importing the
> patched module I find a home-redshift-service-type but not my
> home-night-time-service-type.
>
> Having never really hacked home services I am somewhat puzzled.  It
> certainly feels like I'm missing something essential here.
>
> Any ideas?

The Guix that is included inside the `guix vm` corresponds to the guix
package definition in guix, not the current guix checkout you're using!
You could try to modify the guix-service-type's configuration to use
(current-guix) instead, as done in gnu/system/install.scm.

HTH,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: proot-static build failures (master and core-updates)

[Josselin Poiret]

Hi Ludo,

Ludovic Courtès  writes:

> Josselin mentioned on IRC that they’d reported it upstream:
>
>   https://github.com/proot-me/proot/issues/352
>
> Do these tests reveal a real issue, or should we just skip them until a
> fix lands upstream?

From what I understand of the failing test it looks like an actual
regression.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: 07/19: services: postgresql: Add default package.

[Christopher Baines]

Ludovic Courtès  writes:

> Christopher Baines  skribis:
>
>> guix-comm...@gnu.org writes:
>>
>>> civodul pushed a commit to branch master
>>> in repository guix.
>>>
>>> commit e45306c1982aee194243cf661295c7ca776d879f
>>> Author: Ludovic Courtès 
>>> AuthorDate: Thu Apr 20 10:38:37 2023 +0200
>>>
>>> services: postgresql: Add default package.
>>> 
>>> * gnu/services/databases.scm ()[postgresql]:
>>> Add default value, moved from...
>>> (postgresql-service-type)[default-value]: ... here.
>>> ---
>>>  gnu/services/databases.scm | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> The default was removed a few years ago [1] and I don't think there's
>> been a significant change (like supporting automatic upgrading existing
>> databases between versions) in the service since then.
>>
>> 1: 
>> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=bdcf4d88d58798eca7811c8b1fbd4638168d05c3
>
> Oh, my bad.  I found it weird that the default value would be found in
> the service and not in the configuration object.  The result is that
> there is a default value, just not where you’d expect it.
>
> But yeah, I understand the rationale of the commit above, so we should
> probably revert to that and add a comment explaining why there’s no
> default.
>
> I wonder how we can make sure that users can still write (say):
>
>   (service cuirass-service-type)
>
> without having to explicitly specify which postgresql version they want
> to use.
>
> WDYT?

Yeah, we're just moving the problem of matching up the PostgreSQL
software and data at the moment, but I think it's still preferable to
make the problem clear in the configuration and when reconfiguring
rather than delaying things to when the service doesn't start.

It would be good to at least have some Guix specific documentation on
how to migrate from one PostgreSQL version to another, and ideally this
could be integrated in to the service somehow. That's the blocking issue
to providing defaults here, we're just setting the user up for the
service not starting at some point in the future when we change the
default version of PostgreSQL.


signature.asc
Description: PGP signature

Re: Adding content-addressed URLs to https://guix.gnu.org/sources.json

[Ludovic Courtès]

Hello!

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:

[...]

>> So I guess as a matter of policy, we should try and find other ways to
>> express this so we don’t lose track of origins.
>
> Thanks for explaining, it makes sense.  One way to tip package writers
> in the right direction would be to add a warning when such a situation
> occurs upon running 'guix lint'.

How about the attached patch?

--8<---cut here---start->8---
$ ./pre-inst-env guix lint -c archival ruby-sorbet-runtime racket
gnu/packages/ruby.scm:14081:12: 
ruby-sorbet-runtime@0.5.10610.20230106174520-1fa668010: source is not an 
origin, it cannot be archived
--8<---cut here---end--->8---

(The version string of this package looks way too long.)

Thanks,
Ludo’.

>From 153cb8e5782946bd0c9de22022a475ae9fef70ea Mon Sep 17 00:00:00 2001
Message-Id: <153cb8e5782946bd0c9de22022a475ae9fef70ea.1683184269.git.l...@gnu.org>
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Thu, 4 May 2023 09:09:03 +0200
Subject: [PATCH] lint: archival: Warn against non-origin package sources.

Suggested by Maxim Cournoyer 
and Simon Tournier .

* guix/lint.scm (check-archival): Add 'local-file?' clause.  Clarify
message in case (package-source package) is not an origin.
* tests/lint.scm ("archival: not an origin"): New test.
---
 guix/lint.scm  | 11 +++
 tests/lint.scm | 11 +--
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/guix/lint.scm b/guix/lint.scm
index 0ed5b8dc98..72b3f4e7b1 100644
--- a/guix/lint.scm
+++ b/guix/lint.scm
@@ -1610,11 +1610,11 @@ (define (check-archival package)
   (parameterize ((%allow-request? skip-when-limit-reached))
 (catch #t
   (lambda ()
-(match (and (origin? (package-source package))
-(package-source package))
+(match (package-source package)
   (#f ;no source
'())
-  ((= origin-uri (? git-reference? reference))
+  ((and (? origin?)
+(= origin-uri (? git-reference? reference)))
(define url
  (git-reference-url reference))
(define commit
@@ -1680,9 +1680,12 @@ (define (check-archival package)
((? content?)
 '(
'()))
+  ((? local-file?)
+   '())
   (_
(list (make-warning package
-   (G_ "unsupported source type")
+   (G_ "\
+source is not an origin, it cannot be archived")
#:field 'source)
   (match-lambda*
 (('swh-error url method response)
diff --git a/tests/lint.scm b/tests/lint.scm
index ce22e2355a..b91bd053c5 100644
--- a/tests/lint.scm
+++ b/tests/lint.scm
@@ -1,7 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013 Cyril Roelandt 
 ;;; Copyright © 2014, 2015, 2016 Eric Bavier 
-;;; Copyright © 2014-2022 Ludovic Courtès 
+;;; Copyright © 2014-2023 Ludovic Courtès 
 ;;; Copyright © 2015, 2016 Mathieu Lirzin 
 ;;; Copyright © 2016 Hartmut Goebel 
 ;;; Copyright © 2017 Alex Kost 
@@ -43,7 +43,8 @@ (define-module (test-lint)
   #:use-module (guix lint)
   #:use-module (guix ui)
   #:use-module (guix swh)
-  #:use-module ((guix gexp) #:select (gexp local-file gexp?))
+  #:use-module ((guix gexp)
+#:select (gexp local-file computed-file gexp?))
   #:use-module ((guix utils) #:select (call-with-temporary-directory))
   #:use-module ((guix import hackage) #:select (%hackage-url))
   #:use-module ((guix import stackage) #:select (%stackage-url))
@@ -1298,6 +1299,12 @@ (define (package-with-phase-changes changes)
   '()
   (check-formatting (dummy-package "x")))
 
+(test-assert "archival: not an origin"
+  (warning-contains? "not an origin"
+ (check-archival
+  (dummy-package
+   "x" (source (computed-file "x-src" #t))
+
 (test-assert "archival: missing content"
   (let* ((origin   (origin
  (method url-fetch)

base-commit: 44d70440944aa47e5f37493346e560f38907d777
-- 
2.39.2