Re: [CORE-UPDATES] librsvg and rust

[Kaelyn]

On Wednesday, December 8th, 2021 at 6:36 AM, Ricardo Wurmus 
 wrote:

> Ludovic Courtès l...@gnu.org writes:
>
> > Hello!
> >
> > For the record, this is a followup to Efraim’s proposal in
> >
> > https://issues.guix.gnu.org/51845.
> >
> > Efraim Flashner efr...@flashner.co.il skribis:
> >
> > > Option 1:
> > >
> > > Track down the ~220 crates which form the dependency graph (of crates)
> > >
> > > for librsvg and pin them until the next core-updates cycle. Continue
> > >
> > > like with other packages and add newer versions (like cmake or meson) as
> > >
> > > packages need them.¹
> >
> > The advantage of this approach is that we could do it incrementally: we
> >
> > could merge ‘core-updates-frozen’ today and just add pinned variants of
> >
> > these 200+ crates as needed as time passes. The downside is that it’s a
> >
> > lot of crates to take care of, and we might still accidentally overlook
> >
> > seemingly innocuous crate upgrades that end up causing major rebuilds.
> >
> > > Option 2:
> > >
> > > Use the bundled crates and treat it as just part of the librsvg source
> > >
> > > code.²
> > >
> > > Option 2b:
> > >
> > > Use the bundled crates for now to finish with core-updates-frozen and
> > >
> > > revisit this immediately on core-updates (not frozen).
> >
> > This option will involved a rebuild on x86_64, but the advantage is that
> >
> > we’ll be safe going forward: we won’t accidentally cause world rebuilds
> >
> > just because an obscure crate somewhere has been upgraded.
> >
> > [...]
> >
> > > I'm currently leaning option 2b, it'll get us past this hurdle for
> > >
> > > core-updates-frozen and let us make changes to the crates as we work to
> > >
> > > integrate them more fully into Guix.
> >
> > Same here; it’s not ideal, but it seems like the most reasonable
> >
> > short-term option.
> >
> > If there are no objections, I’d suggest that you go ahead with this
> >
> > plan.
>
> I agree that 2b is the most sensible option in our current situation.

As a developer and new-ish Guix user (and not someone familiar with rust), I am 
also in favor of 2b. Dealing with 200+ dependencies takes time, and 
core-updates-frozen has been on the cusp of merging for some time now.

I'd like to see c-u-f merged back into master sooner, as master lacks support 
for newer hardware while also getting regular package updates that are only 
periodically merged to core-updates-frozen. Even before the c-u-f sprint last 
month where I switched all of my systems to c-u-f, I had one system that was 
first a frankensteined master before finally managing to switch it to c-u-f, to 
pick up a newer mesa that wasn't unusably buggy on a Radeon RX 6700 XT.

Cheers,
Kaelyn

P.S. Regarding switching my systems, the only issue I've run into that hasn't 
been fixed is that tigervnc only recently added support for building against 
xorg-server 21.1.1, and the current tigervnc release (1.12.0) was released 
before that support landed. (I have a standalone package definition for 
building a recent git commit.)
>
> 
>
> Ricardo

help with my opensmtpd-records.scm file

[jbranso]

Hey guix!

I am still working on extending guix's current opensmtpd-service with (guix 
records). 

I am getting fairly close to realizing that goal. For example this works:

(display (opensmtpd-configuration->mixed-text-file
 (let ([interface "wlp2s0"]
 [creds (opensmtpd-table
 (name "creds")
 (values
 (list
 (cons "joshua"
 
"$6$Ec4m8FgKjT2F/03Y$k66ABdse9TzCX6qaALB3WBL9GC1rmAWJmaoSjFMpbhzat7DOpFqpnOwpbZ34wwsQYIK8RQlqwM1I/v6vsRq86."]
 [receive-action (opensmtpd-action-local-delivery-configuration
 (name "receive")
 (method (opensmtpd-maildir-configuration
 (pathname "/home/%{rcpt.user}/Maildir")
 (junk #t)))
 (virtual "vusers"))]
 [smtp.gnucode.me (opensmtpd-pki
 (domain "smtp.gnucode.me")
 (cert "opensmtpd.scm")
 (key "opensmtpd.scm"))])
 (opensmtpd-configuration
 (mta-max-deferred 50)
 (queue
 (opensmtpd-queue-configuration
 (compression #t)))
 (smtp
 (opensmtpd-smtp-configuration
 (max-message-size "10M")))
 (srs
 (opensmtpd-srs-configuration
 (ttl-delay "5d")))
 (listen-ons
 (list
 ;; this forum help suggests that I listen on 0.0.0.0 and NOT eth0
 ;; https://serverfault.com/questions/726795/opensmtpd-wont-work-at-reboot
 ;; this listens for email from the outside world
 (opensmtpd-listen-on
 (interface interface)
 (port 25)
 (secure-connection "tls")
 (pki smtp.gnucode.me)
 )
 ;; this lets local users logged into the system via ssh send email
 (opensmtpd-listen-on
 (interface "lo")
 (port 25)
 (secure-connection "tls")
 (pki smtp.gnucode.me))
 (opensmtpd-listen-on
 (interface interface)
 (port 465)
 (secure-connection "smtps")
 (pki smtp.gnucode.me)
 (auth creds)
 ;;(filter )
 )
 (opensmtpd-listen-on
 (interface interface)
 (port 587)
 (secure-connection "tls-require")
 (pki smtp.gnucode.me)
 (auth creds)
 )))
 (matches (list
 (opensmtpd-match
 (action (opensmtpd-action-relay-configuration
 (name "send")))
 (for (opensmtpd-match-option-configuration
 (option "for any")))
 (from (opensmtpd-match-option-configuration
 (option "from any")))
 (auth (opensmtpd-match-option-configuration
 (option "auth"
 (opensmtpd-match
 (action receive-action)
 (from (opensmtpd-match-option-configuration
 (option "from any")))
 (for (opensmtpd-match-option-configuration
 (option "for domain")
 (value "gnucode.me"))
 ;;FIXME/TODO put in a table  here
 ;;"for domain "
 ))
 (opensmtpd-match
 (action receive-action)
 (for (opensmtpd-match-option-configuration
 (option "for local"))

;; and it outputs:
smtp max-message-size 10M
srs ttl 5d
queue compression

mta max-deferred 50

pki smtp.gnucode.me cert "opensmtpd.scm"
pki smtp.gnucode.me key "opensmtpd.scm"

listen on wlp2s0 tls port 25 pki smtp.gnucode.me
listen on lo tls port 25 pki smtp.gnucode.me
listen on wlp2s0 smtps port 465 pki smtp.gnucode.me auth 
listen on wlp2s0 tls-require port 587 pki smtp.gnucode.me auth 

action "send" relay
action "receive" maildir "/home/%{rcpt.user}/Maildir" junk virtual  

match from any for any auth action "send"
match from any for domain gnucode.me action "receive"
match for local action "receive"
My question has to do with how I am handling the opensmtpd filters...Some of 
the opensmtpd filter
commands execute programs. I would like to get some advice about how to let 
some of the
's fieldnames be gexps. My current opensmtpd.scm file 
does so:

https://notabug.org/jbranso/linode-guix-system-configuration/src/master/opensmtpd.scm
 
(https://notabug.org/jbranso/linode-guix-system-configuration/src/master/opensmtpd.scm)

(though I am getting some errors with the procedure

create-etc-dkimsign-key-file. I should probable use the guix's 
etc-service instead). Anyway, Right now I am using a LOT of code like  
(mixed-text-file (string-append variable (string-append (function 
(string-append (another-function ...

I suppose I should instead change this to

(define my-list (list (function ...) (function ...) (list (function (list 
(function ...) (function ...

(mixed-text-file (apply string-append (flatten my-list))) 
BUT that doesn't quite answer my issue. It would be helpful to allow some 
's
fieldnames accept gexps. How would I allow go about doing that?

I think that the answer would be to use guix's mixed-text-file*, but I am not 
sure how to do that elegantly...

My current code is here:

https://notabug.org/jbranso/linode-guix-system-configuration/src/master/opensmtpd-records.scm
 
(https://notabug.org/jbranso/linode-guix-system-configuration/src/master/opensmtpd-records.scm)

Perhaps a more targeted question would be how do I modify the current procedure

opensmtpd-filter-proc-exec->string record to accept gexps?  

Suggestions are most welcome.

My thoughts about the service are here: 

https://notabug.org/jbranso/linode-guix-system-configuration/src/master/opensmtpd.org
 
(https://notabug.org/jbranso/linode-guix-system-configuration/src/master/opensmtpd.org)
Thanks,

Joshua

Re: [CORE-UPDATES] librsvg and rust

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello!
>
> For the record, this is a followup to Efraim’s proposal in
> .
>
> Efraim Flashner  skribis:
>
>> Option 1:
>> Track down the ~220 crates which form the dependency graph (of crates)
>> for librsvg and pin them until the next core-updates cycle. Continue
>> like with other packages and add newer versions (like cmake or meson) as
>> packages need them.¹
>
> The advantage of this approach is that we could do it incrementally: we
> could merge ‘core-updates-frozen’ today and just add pinned variants of
> these 200+ crates as needed as time passes.  The downside is that it’s a
> lot of crates to take care of, and we might still accidentally overlook
> seemingly innocuous crate upgrades that end up causing major rebuilds.
>
>> Option 2:
>> Use the bundled crates and treat it as just part of the librsvg source
>> code.²
>>
>> Option 2b:
>> Use the bundled crates for now to finish with core-updates-frozen and
>> revisit this immediately on core-updates (not frozen).
>
> This option will involved a rebuild on x86_64, but the advantage is that
> we’ll be safe going forward: we won’t accidentally cause world rebuilds
> just because an obscure crate somewhere has been upgraded.
>
> [...]
>
>> I'm currently leaning option 2b, it'll get us past this hurdle for
>> core-updates-frozen and let us make changes to the crates as we work to
>> integrate them more fully into Guix.
>
> Same here; it’s not ideal, but it seems like the most reasonable
> short-term option.
>
> If there are no objections, I’d suggest that you go ahead with this
> plan.

I agree that 2b is the most sensible option in our current situation.

-- 
Ricardo

Re: [CORE-UPDATES] librsvg and rust

[Ludovic Courtès]

Hello!

For the record, this is a followup to Efraim’s proposal in
.

Efraim Flashner  skribis:

> Option 1:
> Track down the ~220 crates which form the dependency graph (of crates)
> for librsvg and pin them until the next core-updates cycle. Continue
> like with other packages and add newer versions (like cmake or meson) as
> packages need them.¹

The advantage of this approach is that we could do it incrementally: we
could merge ‘core-updates-frozen’ today and just add pinned variants of
these 200+ crates as needed as time passes.  The downside is that it’s a
lot of crates to take care of, and we might still accidentally overlook
seemingly innocuous crate upgrades that end up causing major rebuilds.

> Option 2:
> Use the bundled crates and treat it as just part of the librsvg source
> code.²
>
> Option 2b:
> Use the bundled crates for now to finish with core-updates-frozen and
> revisit this immediately on core-updates (not frozen).

This option will involved a rebuild on x86_64, but the advantage is that
we’ll be safe going forward: we won’t accidentally cause world rebuilds
just because an obscure crate somewhere has been upgraded.

[...]

> I'm currently leaning option 2b, it'll get us past this hurdle for
> core-updates-frozen and let us make changes to the crates as we work to
> integrate them more fully into Guix.

Same here; it’s not ideal, but it seems like the most reasonable
short-term option.

If there are no objections, I’d suggest that you go ahead with this
plan.

Thanks for keeping the ball rolling!

Ludo’.

[CORE-UPDATES] librsvg and rust

[Efraim Flashner]

Core-updates is almost done which means we need to come to a decision
about librsvg and the rust crates.

The problem:
The librsvg tarball includes bundled rust crates. We normally unbundle
bundled sources, and we just so happen to have a) replacement crates for
the bundled ones, b) a method to replace them, and c) a method to build
the package with our packaged crates.
There are multiple cycles between the crates themselves, and between
"traditional" packages (like gtk) and librsvg, traversing the crates.
We (currently) cannot track the dependency cycles between the crates, so
we need to Do Something™.

Option 1:
Track down the ~220 crates which form the dependency graph (of crates)
for librsvg and pin them until the next core-updates cycle. Continue
like with other packages and add newer versions (like cmake or meson) as
packages need them.¹

Option 2:
Use the bundled crates and treat it as just part of the librsvg source
code.²

Option 2b:
Use the bundled crates for now to finish with core-updates-frozen and
revisit this immediately on core-updates (not frozen).

Notes:
Bug 51845 is so far where it's been discussed a bit, but it seems more
relevant for guix-devel.

Ludo has made a nice first patch at treating rust packages in inputs as
cargo-inputs (and native-inputs as cargo-development-inputs), allowing
us to piecemeal change the rust crates. This doesn't directly help with
our librsvg problem, but will help us track dependencies across rust
packages.

Thoughts?

I'm currently leaning option 2b, it'll get us past this hurdle for
core-updates-frozen and let us make changes to the crates as we work to
integrate them more fully into Guix.


¹ If there are any security problems in any of the crates we'd be
grafting librsvg itself, not the individual crates (this is due to how
crates are used).

² (We are not Debian) This is what Debian does.

-- 
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