Re: Video Conference

[Yasuaki Kudo]

Hi,

2 years ago, I joined meet.coop , a video conference service cooperative and 
explored the business potential in Japan.

The coop hosted BBB but the gap I discovered was that the potential customers 
in Japan would not be interested unless the service is customized to their 
exact needs - otherwise they preferred Zoom and Google meet.

So ability to to take the video conference service into minimalist components 
and then reassembling  is very important 

-Yasu

 

> On Apr 2, 2022, at 03:59, jbra...@dismail.de wrote:
> 
> March 31, 2022 7:53 PM, "Yasuaki Kudo"  wrote:
> 
>> Hello,
>> 
>> From time to time, I think about audio/video mixer (.i.e. video conference 
>> software like BBB or
>> Jitsi) , with the intension of making it highly modular that it can be 
>> freely remixed and
>> reinvented by volunteer participants.
>> 
>> Is anyone interested? Or is can you think about something that already 
>> exists?
> 
> Your proposal sounds a little vague.  What are you hoping to accomplish that 
> BBB or Jitsi 
> does not already do?
> 
>> 
>> Cheers,
>> Yasu

Reviewing the diff when updating a package?

[Thiago Jung Bauermann]

Hello Maxime,

Maxime Devos  writes:

> Patch is not yet ready (I'm looking at the source code diff for
> anything ‘suspicious’), just reserving a bug number and avoiding double
> work.  Will send an actual patch later.

I hope you don't mind me asking what do you mean by ‘suspicious’?

Is it reviewing the code for security concerns?

I ask because I've wondered sometimes whether contributors updating a
package to a new version should review the new source code.

-- 
Thanks
Thiago

Getting the name of file-like objects

[Justin Veilleux]

Hi everyone. I'm currently writing a set of helper functions (usually 
written using `computed-file`  which act on file like objects to 
transform them in some way.
For instance, I have a `decompress` function which, given a file-like 
object pointing to an archive, will return a computed file object which 
it will decompress to it's output.
Everything works very well, but I would like to be able to name the 
`computed-file` objects something meaningfull.


```
(define (unzip f)
  (computed-file (string-append (name f) "-unzipped")
#~(begin
(system* (string-append #$unzip "/bin/unzip")
 "-d" #$output
 #$file))
 #$out))
```

Is there someting which ressembles the imaginary `name` function I used 
above?


Cheers.

Re: better error messages through assertions

[Philip McGrath]

Hi,

On 3/30/22 05:37, Ludovic Courtès wrote:



What is the preferred mechanism for exceptions?


For Guix code, SRFI-34/35.


Likewise, what record system should I use?


SRFI-9.

(Perhaps we should put answers to these questions in the “Coding Style”
section of the manual.)



As I've looked more closely, I think I'd be porting a fair amount of 
code that looks like this:


```
(define-struct (blame-no-swap blame) ()
  #:property prop:equal+hash
  (list blame=? blame-hash blame-secondary-hash))
```

That code creates a new opaque struct type `blame-no-swap` with parent 
type `blame` and customizes the behavior of `equal?` and `equal?`-based 
hashing (but the customization only applies when the two 
potentially-equal values are both immediate instances of 
`blame-no-swap`, not a supertype or subtype).


It looks like SRFI 9 doesn't have a notion of opaque or parent types, so 
it seems like it would be easier to use R6RS records as the basis for 
porting.


(I think it should still work to use SRFI 9 records for the interface. 
But I know the representation of blame, among other details, has gotten 
a lot of attention over the years, so it seems like it would be good to 
keep the port as close as reasonably possible to the Racket implementation.)


I'm less sure about `equal?` and hashing. I see in [1] that `equal?` can 
be controlled via GOOPS, and I have the impression that there's some 
kind of bridging between basic types and GOOPS, but I'm not clear on the 
details. I don't see anything explicitly about customizing `hash`[2], 
but maybe that would work the same way?


-Philip

[1]: 
https://www.gnu.org/software/guile/manual/html_node/GOOPS-Object-Miscellany.html
[2]: 
https://www.gnu.org/software/guile/manual/html_node/Hash-Table-Reference.html#index-hash

Re: better error messages through assertions

[Philip McGrath]

Hi,

On 3/30/22 09:28, Andy Wingo wrote:


Too bad about all that other crap about checking whether the index is in
range and the field is boxed or not, though :-/  Probably there is a
better design...

Andy


For the index-out-of-range part, when I saw `record-accessor`, I thought 
of it as similar to Racket's `make-struct-field-accessor`[1], which can 
check the index just once, when the accessor is created, rather than 
each time the accessor is used. That's (part of) what Racket's `struct` 
form expands to.


Would it be reasonable to use `record-accessor` in the implementation of 
SRFI 9?


-Philip

[1]: 
https://docs.racket-lang.org/reference/creatingmorestructs.html#%28def._%28%28quote._~23~25kernel%29._make-struct-field-accessor%29%29

Re: Video Conference

[jbranso]

March 31, 2022 7:53 PM, "Yasuaki Kudo"  wrote:

> Hello,
> 
> From time to time, I think about audio/video mixer (.i.e. video conference 
> software like BBB or
> Jitsi) , with the intension of making it highly modular that it can be freely 
> remixed and
> reinvented by volunteer participants.
> 
> Is anyone interested? Or is can you think about something that already exists?

Your proposal sounds a little vague.  What are you hoping to accomplish that 
BBB or Jitsi 
does not already do?

> 
> Cheers,
> Yasu

Re: New review checklist

[Liliana Marie Prikler]

Hi Maxime,

Am Freitag, dem 01.04.2022 um 19:46 +0200 schrieb Maxime Devos:
> [...]
> I know there have been some discussions in the past about whether
> git-version should be used when a commit is explicitly chosen,
> whether
> tags should be used instead of commits, how high a risk there is that
> version->commit can become multi-valued, ‘tricking peer review’ ...
> 
> However, my question isn't about any of that.  It is only about the
> let-binding itself, in situations where the bound variable is only
> used in a single place.  What is the reason for doing
> 
> (let ((commit "cabba9e..."))
>   (package
>     (name "foobar")
>     (version "0.1.2")
>     (source (origin ...
>   ;; this is the only use of the 'commit' variable bound
> in
>   ;; the above 'commit'
>   (commit commit)))
>     ...))
> 
> when it can be simplified to
> 
> (package
>   (name "foobar")
>   (version "0.1.2")
>   (source (origin ... (commit "cabba9e..."?
> 
> I mean, we don't do this for, say, 'name', 'version' and 'uri':
> 
> ;; these three variables are only used in a single location
> (let ((name "foobar")
>   (version "0.1.2")
>   (uri "https://foo.bar;))
>   (package
>     (name name)
>     (version version)
>     (source (origin (uri uri) (commit ) [...]))
>     ...))
> 
> Why would things be different for 'commit' here?  How does putting
> the value of 'commit' in a let-form reduce surprises?
The main goal of let-binding commit and revision is to allow for easier
change.  Suppose you need to reference some half-release for some
obscure reason, then this style makes it easier to switch to what is
already established praxis.

In general, consider the poor soul who may have to read and maintain
your code after you get hit by a car because neither busses nor trams
run in your region.

Re: New review checklist

[Tobias Geerinckx-Rice]

>-- would the commit need to be let-bound here?

You seem to already know the answer, which is 'no'.

Aside, 'let-binding' is not the opposite of 'hard-coding'.


Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Re: New review checklist

[Maxime Devos]

Liliana Marie Prikler schreef op vr 01-04-2022 om 19:03 [+0200]:
> Hi Maxime,
> 
> [...]
> > 
> > -- would the commit need to be let-bound here?
> This discussion has already been had elsewhere, but to reiterate, my
> reasoning is that if you can't trust upstream tags to remain valid, you
> need another proof that the VERSION <-> COMMIT equivalence holds. 
> Referring to another authority (as can be done in the case of Minetest
> packages) is fine for me personally, but in the general case (e.g. your
> #2 without further context) I'd say that let-binding the commit leads
> to the least amount of surprises for everyone.

I know there have been some discussions in the past about whether
git-version should be used when a commit is explicitly chosen, whether
tags should be used instead of commits, how high a risk there is that
version->commit can become multi-valued, ‘tricking peer review’ ...

However, my question isn't about any of that.  It is only about the
let-binding itself, in situations where the bound variable is only used
in a single place.  What is the reason for doing

(let ((commit "cabba9e..."))
  (package
(name "foobar")
(version "0.1.2")
(source (origin ...
  ;; this is the only use of the 'commit' variable bound in
  ;; the above 'commit'
  (commit commit)))
...))

when it can be simplified to

(package
  (name "foobar")
  (version "0.1.2")
  (source (origin ... (commit "cabba9e..."?

I mean, we don't do this for, say, 'name', 'version' and 'uri':

;; these three variables are only used in a single location
(let ((name "foobar")
  (version "0.1.2")
  (uri "https://foo.bar;))
  (package
(name name)
(version version)
(source (origin (uri uri) (commit ) [...]))
...))

Why would things be different for 'commit' here?  How does putting the
value of 'commit' in a let-form reduce surprises?

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: New review checklist

[Liliana Marie Prikler]

Hi Maxime,

Am Freitag, dem 01.04.2022 um 08:30 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op vr 01-04-2022 om 06:14 [+0200]:
> > It won't be added to Guix.  Here's why it won't.
> > You appear to believe that
> > [...]
> > [ ] hard-coding the commit field is a good idea
> 
> Does the following count:
> 
> (define-public foo
>   (package
>     (name "foo")
>     (version "1.0.0")
>     (source
>   (origin
>     [...]
>     (file-name (git-file-name name version))
>     ;; Upstream does not tag versions, see
>     ;;  for which commit
>     ;; corresponds to which version.
>     ;;
>     ;; (alternatively)
>     ;;
>     ;; Upstream deletes old tags every N months,
>     ;; so explicitly write the commit here.;
>     ;;
>     ;; (alternatively)
>     ;;
>     ;; There is consensus that the benefits of explicit commits
>     ;; outweigh the downsides, see
>     ;; 
>     (commit "cabba9e..."))
>    [...]))
> 
> -- would the commit need to be let-bound here?
This discussion has already been had elsewhere, but to reiterate, my
reasoning is that if you can't trust upstream tags to remain valid, you
need another proof that the VERSION <-> COMMIT equivalence holds. 
Referring to another authority (as can be done in the case of Minetest
packages) is fine for me personally, but in the general case (e.g. your
#2 without further context) I'd say that let-binding the commit leads
to the least amount of surprises for everyone.

In the particular case of Minetest, another plausible style would be
(let ((commit ...)
  (revision ACTUAL-REVISION-OR-#f))
  (package 
...
;; tagged TAG as of DATE
;; For a complete list of versions, see 
(version "just the version") 
(source (origin ...
  ;; Upstream is known to yank tags, so always use commits.
  (commit commit)

Cheers

Re: Deprecating legacy build phase style when cross-compiling vs. native

[Maxime Devos]

Daniel Meißner schreef op vr 01-04-2022 om 12:26 [+0200]:
> I am also wondering: How are multiple outputs handled with gexps and
> #$output?

#~(do-stuff #$output:lib #$output:static #$output:bin #$output:doc ...)

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

New Swedish PO file for 'shepherd' (version 0.9.0rc1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'shepherd' has been submitted
by the Swedish team of translators.  The file is available at:

https://translationproject.org/latest/shepherd/sv.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/shepherd/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/shepherd.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Deprecating legacy build phase style when cross-compiling vs. native

[Daniel Meißner]

Hi,

Ludovic Courtès  writes:

> The easiest change is to replace:
>
>   %output
>
> with:
>
>   (assoc-ref %outputs "out")
>
> It’s a simple search-and-replace.
>
> The next step would be to use gexps and #$output, but that can be done
> incrementally over time IMO.

I have a patch in that direction sitting on
https://issues.guix.gnu.org/54641 and I am wondering if this is the
style that you’re proposing as the next step.  If so, I could provide
some more patches for other packages as well.

I am also wondering: How are multiple outputs handled with gexps and
#$output?

Best

--
Daniel

Possible missed translatability of plural string in shepherd

[Anders Jonsson]

Hi,
when translating shepherd to Swedish, I saw that the plural string on
https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n1362
("~a connections still in use after ~a termination.") doesn't seem to be 
translatable.


Only the singular case of the string is present in the po file at 
Translation Project.



Regards,
Anders Jonsson

Re: Compiling rust things without cargo (super WIP POC)

[Maxime Devos]

Ludovic Courtès schreef op vr 01-04-2022 om 11:10 [+0200]:
> I guess the whole question is whether that technique can be made to work
> for the vast majority of Rust packages.  I’d suggest working in that
> direction: writing a build system as a first step, using it in all the
> Rust packages, and analyzing the kinds of problems encountered, with the
> goal of estimating the effort it would take to make it work for every
> single package.  Easier said than done, I guess.

Do you know a ‘real’ Rust applications with few transitive dependencies
(say, 3 or so) with preferably few rust source files?  That would be a
practical target for the ad-hoc Makefile and eventually, the new
antioxidant-build-system.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Compiling rust things without cargo (super WIP POC)

[Maxime Devos]

Ludovic Courtès schreef op vr 01-04-2022 om 11:10 [+0200]:
> Overall, I’m afraid Rust packaging is getting out of hands and we’re all
> looking elsewhere.  For example, that Rust packages live in their own
> separate world means there’s no tooling available, leading to poor QA, a
> proliferation of versions of the same packages that never get removed,
> and so on.  I think addressing that, for instance with something as I
> proposed in , should be high
> priority.

I think I'll look into the cycle issue, maybe cargo.toml can be
modified to not use rust-cfg-il and maybe the solution, if any, could
be used for other cycles.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

[Maxime Devos]

Ludovic Courtès schreef op vr 01-04-2022 om 10:58 [+0200]:
> As a first milestone, maybe we could start running ‘autoreconf’ more
> often, for packages higher in the graph.  We could change the
> ‘bootstrap’ build phase to do that unless it’s explicitly turned off.
> It may turn out to be a Sisyphean task though…
>
> Thoughts?

Changing all pre-existing packages, maybe.  But doing this for new
packages (reducing review effort) and perhaps when a package is updated
(for purity) should be feasible I think?  Then gradually things would
improve and eventually(TM) doing the switch in the bootstrap phase may
become feasible ...

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Deprecating legacy build phase style when cross-compiling vs. native

[Ludovic Courtès]

Hi Josselin,

Josselin Poiret  skribis:

> Looking at guix/build-system/gnu.scm [2], we have gnu-build
> vs. gnu-cross-build, which are responsible for native vs. cross-builds.
> The former uses with-build-variables to set the legacy build variables
> such as %output and %outputs (see the def in guix/gexp.scm), whereas the
> latter does not, only doing so manually and so omitting %output.

‘%output’ (singular) had long been informally deprecated in favor of
‘%outputs’ (plural).

> This means that packages that were not updated to fit the new style
> should all fail to cross-compile.  This simple bug could be resolved by
> adding %output to gnu-cross-build, however as was argued on IRC this is
> now undocumented behaviour and we'd rather switch all packages to the
> new style instead.  While I 100% agree with this, I think we should have
> a uniform deprecation policy for this matter, and that there shouldn't
> be such a disparity between cross and native builds.

The easiest change is to replace:

  %output

with:

  (assoc-ref %outputs "out")

It’s a simple search-and-replace.

The next step would be to use gexps and #$output, but that can be done
incrementally over time IMO.

WDYT?

Thanks,
Ludo’.

Re: Formalizing teams

[Ludovic Courtès]

Hi David,

david larsson  skribis:

> On 2022-01-03 16:22, Ludovic Courtès wrote:

[...]

>> This brings a related but slightly different topic: how to let
>> people
>> filter incoming patches and bug reports in general.
>> How does it even work on git*.com?  Do they let you subscribe to
>> issues/merge requests that match certain patterns or touch certain
>> files?
>
> github.com uses CODEOWNERS file which is well described here:
> https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#about-code-owners

Yes, I like that approach; I suppose mumi could parse and honor such a
file with relatively little effort.  (I’d suggest “CODEFELLOWS” or a
similar name, but that’s another story. :-))

Ludo’.

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

[Jonathan McHugh]

Hi Ludo,

April 1, 2022 11:01 AM, "Ludovic Courtès"  wrote:

> 
> This is conceptually the “right thing”, but it raises a significant
> bootstrapping problem. Our bootstrap path currently focuses on being
> able to run shell scripts, in particular ‘configure’ scripts, before we
> can even build Bash, thanks to Gash and Gash-Utils. If we were to build
> the autotools machinery systematically, we’d need Gash-Utils to provide
> a Perl and an M4 implementation. (Now, Timothy has written an Awk
> interpreter, so a Perl interpreter can’t be so hard, right? :-))
> The other option is to write an Autoconf and Automake implementation…
> 

A huge Awk fan, have you got a reference for Timothy's interpreter?

> As a first milestone, maybe we could start running ‘autoreconf’ more
> often, for packages higher in the graph. We could change the
> ‘bootstrap’ build phase to do that unless it’s explicitly turned off.
> It may turn out to be a Sisyphean task though…
> 
> Thoughts?
> 
> Ludo’.




Jonathan McHugh
indieterminacy@libre.brussels

Re: Compiling rust things without cargo (super WIP POC)

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> I invite you to take a look at 
> .
> It contains a minimal rust library (libhello) and a minimal 'hello
> world'-style application that uses 'libhello'.
>
> To simulate how Guix compiles C software (but here applied to Rust), 
> the Makefile does the following:
>
>   * Run 'rustc --crate-type=lib libhello/hello.rs -o 
> out/libhello/lib/libhello.rlib',
> to compile the library and install it in 'out/libhello/lib/libhello.rlib'
> (cf. /gnu/store/...-libhello.../lib/hello.so).
>
>   * Run 'rustc -Lout/libhello/lib hello-app/main.rs -o 
> out/hello-oxygen/bin/hello'
> to compile the application.  By default, rustc will fail because it 
> cannot find
> the library.  However, if -Lout/libhello/lib is passed, then it does find 
> it!
>
> (cf. LIBRARY_PATH=/gnu/store/.../lib & gcc -L/gnu/store/.../lib)
>
> This is a rather basic example (no transitive dependencies, no test 
> dependencies,
> no macros ...), but it seems like there are some possibilities here ...

Interesting.

> As a next step, maybe I could try writing a Guix package definition for 
> libhello
> and hello-oxygen, gradually making things more complicated (macros, transitive
> dependencies, some non-toy Rust dependencies, a Guix build system ...)?

I guess the whole question is whether that technique can be made to work
for the vast majority of Rust packages.  I’d suggest working in that
direction: writing a build system as a first step, using it in all the
Rust packages, and analyzing the kinds of problems encountered, with the
goal of estimating the effort it would take to make it work for every
single package.  Easier said than done, I guess.

Overall, I’m afraid Rust packaging is getting out of hands and we’re all
looking elsewhere.  For example, that Rust packages live in their own
separate world means there’s no tooling available, leading to poor QA, a
proliferation of versions of the same packages that never get removed,
and so on.  I think addressing that, for instance with something as I
proposed in , should be high
priority.

Thoughts?

Ludo’.

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

[Ludovic Courtès]

Hi!

Maxime Devos  skribis:

> Quite some packages in Guix use the Autotools system.  In this system,
> a 'configure.ac' and 'Makefile.am' script / makefile is written, from
> which 'autoconf' & 'automake' generate a very long bash script and a
> Makefile.in.  Depending on the maintainer of the upstream package, this
> 'configure' and 'Makefile.in' are sometimes included in release
> tarballs.

Clearly, this is an exception to the rule in Guix, some might say it’s
the elephant in the room.

Debian has long considered that these are not source and so it
regenerates all these files as a first step (IIRC).

This is conceptually the “right thing”, but it raises a significant
bootstrapping problem.  Our bootstrap path currently focuses on being
able to run shell scripts, in particular ‘configure’ scripts, before we
can even build Bash, thanks to Gash and Gash-Utils.  If we were to build
the autotools machinery systematically, we’d need Gash-Utils to provide
a Perl and an M4 implementation.  (Now, Timothy has written an Awk
interpreter, so a Perl interpreter can’t be so hard, right?  :-))
The other option is to write an Autoconf and Automake implementation…

As a first milestone, maybe we could start running ‘autoreconf’ more
often, for packages higher in the graph.  We could change the
‘bootstrap’ build phase to do that unless it’s explicitly turned off.
It may turn out to be a Sisyphean task though…

Thoughts?

Ludo’.

Re: better error messages through assertions

[Ludovic Courtès]

Hi,

Andy Wingo  skribis:

> Here we see the first procedure which is the thunk that wraps the
> expression.  Then in the beginning of the procedure at L7 you can see
> there is a check for struct?, which has to be dominated by a true
> heap-object? check.  Duplicate checks are elided.  So if SRFI-9 added a
> `struct?` check it wouldn't be more code; rather it would be less,
> actually, because instead of branching to L38, you'd branch to L37.

Oh very nice, thanks for the explanation!  That ‘,optimize-cps’ command
proves useful.

So we can have better error reports with no performance penalty,
Philip.  Way to go!

Ludo’.

Re: LibreSSL?

[Ludovic Courtès]

Hi,

Leo Famulari  skribis:

> I noticed that some Guix packages depend on LibreSSL, but it seems that
> we are not successfully keeping this package up to date with upstream
> security releases:
>
> https://www.libressl.org/releases.html
>
> Will anyone step up to maintain this package? Or should we remove it
> from Guix?

At first sight, it looks like an easy-to-maintain package: no
dependencies, few users, stable API.

I tried to update it to 3.5.1 and was proved wrong though: there’s one
test failure in ‘tests/asn1object’ and the Internet doesn’t seem to know
how to address the problem.  So it would need a bit more work.

I’d lean towards keeping it and doing that extra work, collectively, but
I understand this very discussion shows that it’s debatable.

Ludo’.

Re: gcc-4.7 and gcc-4.8 compilation failure in x64

[Ludovic Courtès]

Hi!

Ekaitz Zarraga  skribis:

> More specifically I mean the output of that command is:
>
> ./md-unwind-support.h:60:47: error: dereferencing pointer to incomplete type

[...]

> build of /gnu/store/bx2zldsx3by529hri5pfx15k12f67gzb-gcc-4.7.4.drv failed

Could you try building it with an older GCC?  For example, you could add
say ‘gcc-7’ to ‘native-inputs’ (make sure it doesn’t propagate to the
other GCC variants that inherit from it, though).

HTH,
Ludo’.

Re: New review checklist

[Jonathan McHugh]

There is no reference to XML. Nor does it provide any interopabilietie with 
SOAP.
Please stop wasting the mailinglists time with this non XML based hokum, this 
is Guxi.FFSaek.

:)


Jonathan McHugh
indieterminacy@libre.brussels

April 1, 2022 6:15 AM, "Liliana Marie Prikler"  
wrote:

> Dear reviewer,
> 
> in the sequel find the new review checklist, effective immediately. 
> Failure to apply it will result in the confiscation of your machine for
> the purpose of making it usable for continuous integration.
> 
> Happy April Fools
> 
> -
> 
> So you want to package a
> [ ] C [ ] C++ [ ] C# [ ] Common Lisp [ ] Emacs Lisp [ ] Fortran
> [ ] Guile [ ] Haskell [ ] Java [ ] Javascript [ ] Julia [ ] Nim
> [ ] OCaml [ ] Python [ ] R [ ] Rust [ ] V [ ] Zig [ ] 
> application/library/.
> It won't be added to Guix. Here's why it won't.
> 
> You appear to believe that
> [ ] linter warnings can easily be ignored
> [ ] `make check' does not need to succeed
> [ ] nobody will ever want to build your package on
> [ ] x86_64 [ ] i686 [ ] aarch64 [ ] armhf [ ] mips
> [ ] powerpc [ ] riscv__ [ ] __-mingw32 [ ] the Hurd
> [ ] commit hashes make for good version numbers
> [ ] hard-coding the commit field is a good idea
> [ ] using trivial-build system is a good idea
> [ ] we hard-code
> [ ] invocations of command line tools
> [ ] shared libraries
> [ ] _
> for fun
> [ ] updating __ to add your package does not cause a world rebuild
> [ ] committers have nothing better to do than trailing a branch that
> receives _ commits per day.
> 
> Sadly your patch has/lacks
> [ ] copyright headers
> [ ] changes in other parts of the file
> [ ] indentation
> [ ] speling misstakes
> [ ] new-style inputs
> [ ] propagated inputs
> [ ] a useful synopsis
> [ ] a meaningful description
> [ ] a valid home-page
> [ ] correct licensing information
> [ ] significant improvements over the three other patches adding this  
> package, which themselves are stuck in review hell
> 
> The following technophilosophical objections also apply:
> [ ] the GNU FSDG prohibit _
> [ ] your package bundles a meaningless copy of
> [ ] ffmpeg
> [ ] v8
> [ ] font-awesome
> [ ] bundler
> [ ] rustc
> [ ] 
> [ ] your package bootstraps itself using a sparse autoencoder trained
> on /dev/urandom
> [ ] your package is not reproducible thanks to
> [ ] embedded timestamps
> [ ] CPU feature detection during configure/compile time
> [ ] a flaky test suite
> [ ] an evil hack to call rand() inside a constexpr context
> [ ] Guix should not have to carry every fork of suckmore tools
> 
> In conclusion, this is what I think of you:
> [ ] Your patch looks good, but I'm not going to push it.
> [ ] Your patch would need some work, and I'm not going to invest that
> time on your behalf.
> [ ] Your patch is bad and you should feel bad for submitting it.
> [ ] Maintaining this package in your own channel is an adequate
> punishment for writing it.

Re: lxc and subuid

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> Antonio Carlos Padoan Junior schreef op wo 30-03-2022 om 08:51 [+0200]:
>> Hello,
>> 
>> I'm trying to figure out how to set a unprivileged container using lxc
>> in guix. I do not know either how to allocate subuid/gid space in guix,
>
> subuid/gid are _not_ unprivileged.  They are an userspace feature by
> the (privileged) setuid binary 'newuidmap', see
> .
>
> I don't think there's currently a mechanism for that in Guix System,
> except manually creating and modifying /etc/subuid appropriately and
> installing the setuid binaries.  However, I suppose that the 'user-
> account' record could be extended to support subuid/subgid and
> automatically create /etc/subuid.

Or we could unconditionally add 65536 subuids for each non-system user
account; that’s what other distros seem to be doing.

I think we could take advantage of it for ‘guix system container’: it
could run in an unprivileged user namespace and map several UIDs in that
namespace, such that it doesn’t need to run as root anymore.

Thoughts?

Ludo’.

Re: Compiling rust things without cargo (super WIP POC)

[Brendan Tildesley]

Recently I did the bevy (game engine) hello world tutorial[1].
To facilitate less slow iteration time when developing, it supports 
dynamic linking,
disabling some optimizations, and using the lld linker for fast linking, 
although using lld failed for me.


When running cargo build, only your project is recompiled quickly and 
linked.


I was wondering how this dynamic linking might be facilitated in Guix?


Note: I had to update cargo to 0.60 to compile bevy with edition2021

[1] https://bevyengine.org/learn/book/getting-started/

Re: New review checklist

[tanguy]

Dear Liliana,


On 2022-04-01 04:14, Liliana Marie Prikler wrote:

in the sequel find the new review checklist, effective immediately.
Failure to apply it will result in the confiscation of your machine for
the purpose of making it usable for continuous integration.


The last patch I submitted seems to tick 90% of the boxes! ^_^'
So… 1) I'm still a WIP and 2) thanks again for taking the time to review 
it anyway! ;-)


Best regards,

--
Tanguy

Re: New review checklist

[Maxime Devos]

Liliana Marie Prikler schreef op vr 01-04-2022 om 06:14 [+0200]:
> It won't be added to Guix.  Here's why it won't.
> You appear to believe that
> [...]
> [ ] hard-coding the commit field is a good idea

Does the following count:

(define-public foo
  (package
(name "foo")
(version "1.0.0")
(source
  (origin
[...]
(file-name (git-file-name name version))
;; Upstream does not tag versions, see
;;  for which commit
;; corresponds to which version.
;;
;; (alternatively)
;;
;; Upstream deletes old tags every N months,
;; so explicitly write the commit here.;
;;
;; (alternatively)
;;
;; There is consensus that the benefits of explicit commits
;; outweigh the downsides, see
;; 
(commit "cabba9e..."))
   [...]))

-- would the commit need to be let-bound here?

Greetings,
Maxime


signature.asc
Description: This is a digitally signed message part