Re: Public guix offload server

[Arun Isaac]

Hi zimoun,

> Imagine another Cuirass instance where any committer could add [1] their
> own branch.  It would act as this minimal job submission API.
>
> 1: 
>
> The questions are the authentication to this Cuirass instance and how
> Cuirass deals with rebased branch (which would happen).

I don't think we need Cuirass. We could just use the remote guix-daemon
features that are already in Guix.

$ export GUIX_DAEMON_SOCKET=ssh://char...@sandbox.guix.gnu.org:22
$ guix build foo

Then we just need to copy over the build outputs from the remote
host. Maybe, `guix copy' could be used.

With this method, we already have all the software that we
need. Authentication is handled via ssh. And, there is no need for trust
between users of the build server. Now, somebody just needs to set up
the hardware! :-)

Regards,
Arun


signature.asc
Description: PGP signature

Re: Incentives for review

[Thiago Jung Bauermann]

Hello Kyle,

Em sexta-feira, 22 de outubro de 2021, às 22:43:05 -03, Kyle Meyer 
escreveu:
> Thiago Jung Bauermann writes:
> > Em quinta-feira, 21 de outubro de 2021, às 10:38:44 -03, Artem Chernyak
> > escreveu:
> [...]
> 
> >> One thing that could help this, is to include a little more info in
> >> the subject line for patches. Right now we include the broad area
> >> (e.g. "gnu: ..."). But we could go on level deeper and include the
> >> specific file (e.g. "gnu: docker: ..."). This becomes important
> >> because gnu as an area of guix spans a lot of different packages and
> >> languages. With the extra file level information, we can easily filter
> >> it down to only the areas we know about.
> > 
> > That is a good idea. I agree that it would be helpful.
> 
> Fwiw public-inbox () indexes the file name
> from diffs.  Searching with the "dfn:" prefix against
> , you can get a feed of changes
> touching particular paths by using the "dfn:" prefix .  For example:
> 
>   https://yhetil.org/guix-patches/?q=dfn:docker=A

That is very good! I didn’t know that public-inbox did that. Thank you for 
the tip!

-- 
Thanks,
Thiago

License issue with SRFI 5

[Philip McGrath]

Hi Guix,

I was recently reminded of a thorny license issue with the SRFI 5 
standard document, which is part of the main Racket distribution. People 
from Racket, the SRFI community, Debian, and Fedora have taken steps to 
help mitigate the problem: I want to make some further improvements, but 
I first need clarity on what Guix's policy requires and permits.


Since 2005, SRFIs have used the MIT/Expat license, and all but two older 
SRFIs were relicensed: however, the SRFI editors were not able to 
contact the author of SRFI 5, Andy Gaynor, so it remains under the 
original SRFI license.[1] That license, modeled on that of IETF RFCs, 
was intended to be quite permissive while also trying to ensure 
derivative works would not be confused with the final, official SRFI 
itself. (The many versions of some SRFIs that nonetheless have come up 
while hunting down related issues has given me some sympathy for that 
goal.) Unfortunately, the restrictions on modifications went to far, at 
least in the judgement of Debian and Fedora.


Here is the license text, as it appears at 
 and 
:



Copyright (C) Andy Gaynor (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and 
derivative works that comment on or otherwise explain it or assist in its 
implementation may be prepared, copied, published and distributed, in whole or 
in part, without restriction of any kind, provided that the above copyright 
notice and this paragraph are included on all such copies and derivative works. 
However, this document itself may not be modified in any way, such as by 
removing the copyright notice or references to the Scheme Request For 
Implementation process or editors, except as needed for the purpose of 
developing SRFIs in which case the procedures for copyrights defined in the 
SRFI process must be followed, or as required to translate it into languages 
other than English.

The limited permissions granted above are perpetual and will not be revoked by 
the authors or their successors or assigns.

This document and the information contained herein is provided on an "AS IS" 
basis and THE AUTHOR AND THE SRFI EDITORS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 
PARTICULAR PURPOSE.
Before going any further, let me emphasize that a great deal of progress 
has been made since distro packagers first pointed out the problem.[2] 
First, there was work to separate the problematic SRFIs (plural, at the 
time) into "srfi-lib-nonfree" and "srfi-doc-nonfree" Racket packages.[3] 
Distro packagers could cleanly remove these from their Racket 
distributions, and they also work properly if a user of the 
distro-packaged Racket explicitly decides to install them. Later, I 
wrote a free implementation of SRFI 5, so "srfi-lib-nonfree" is now 
(confusingly) free software, an empty package definition for backwards 
compatibility.[4] SRFI 29 was supposed to have been converted to the 
MIT/Expat license in 2005, but somehow was missed: just today, the 
current SRFI editor, Arthur Gleckler, confirmed the permission of the 
author, Scott Miller, and updated the official document.[5][6][7] So the 
only problem remaining is the SRFI 5 standard document.


Racketeers have high expectations of their documentation, like being 
able to right-click on an identifier in DrRacket (or the equivalent in 
Emacs with racket-mode) and jump to the locally-installed documentation 
for the relevant binding according to lexical scope and the module 
system---even for a binding like `let`, which is defined by 27 different 
Racket modules, including `srfi/5`. My tentative plan is to write free 
replacement documentation for SRFI 5, eliminate everything from 
"srfi-doc-nonfree" but the official SRFI 5 document itself, and program 
the free SRFI 5 documentation (in Racket's Scribble language) to link to 
the SRFI 5 document at racket-lang.org if there isn't a local copy 
installed.


This all raises a few questions about Guix policy:

 1. Can Guix distribute the official SRFI 5 standard document under
the license listed above?

 2. If not, can Guix distribute free documentation that links
to an online copy of the official SRFI 5 standard document?

 3. Would it be permissible for the free documentation to
include instructions for installing the official SRFI 5 standard
document locally, e.g. `raco pkg install srfi-doc-nonfree`?
(Or perhaps `raco pkg install srfi-5-std-doc`, to avoid the
implication of arbitrary non-free materials?)

(Of course, if someone can manage to contact Andy Gaynor, that would be 
even better!)


The first question is fundamental but less immediately important to me: 
since Debian and Fedora, at 

Re: Incentives for review

[Kyle Meyer]

Thiago Jung Bauermann writes:

> Em quinta-feira, 21 de outubro de 2021, às 10:38:44 -03, Artem Chernyak 
> escreveu:
[...]
>> One thing that could help this, is to include a little more info in
>> the subject line for patches. Right now we include the broad area
>> (e.g. "gnu: ..."). But we could go on level deeper and include the
>> specific file (e.g. "gnu: docker: ..."). This becomes important
>> because gnu as an area of guix spans a lot of different packages and
>> languages. With the extra file level information, we can easily filter
>> it down to only the areas we know about.
>
> That is a good idea. I agree that it would be helpful.

Fwiw public-inbox () indexes the file name
from diffs.  Searching with the "dfn:" prefix against
, you can get a feed of changes
touching particular paths by using the "dfn:" prefix .  For example:

  https://yhetil.org/guix-patches/?q=dfn:docker=A

Preservation of Guix 2021-10-22

[Timothy Sample]

Hey all,

As promised, here is the updated Preservation of Guix Report:

https://ngyro.com/pog-reports/2021-10-22/

It takes into account the as yet unreleased Disarchive fix.  The results
are quite a bit better!  Note especially that for the most recent
commit, of the 72.8% that I could check, 97.8% are in the SWH archive.

I didn’t add the breakdowns that zimoun suggested (yet), but here is a
bit of extra information.  Of the missing fixed-output derivations, we
have:

git  376
tar+gz  3092
total   3468

If we limit ourselves to the most recent commit (258a27e):

git  217
tar+gz78
total295

My guess (and that’s all it is!) is that before “sources.json”, a lot of
tarballs slipped through the cracks.  Now, most of the tarballs are
getting archived via “sources.json”, but since the Git references are
not, there are several that are being missed.

I was curious about the tarballs in the most recent commit, so I took a
look.  There’s no clear pattern.  There were three old GNU packages
(from “commencement.scm”), which I thought was strange, because SWH has
a special GNU loader.  OK, let’s look at Gawk 3.0.0.  It’s there, but
the ID is different.  It turns out the SWH version is missing the
executable bit on all the scripts.  I wonder if they somehow made a
mistake when they first ingested it  (At least it’s not *another*
Disarchive bug!)


-- Tim

Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

[Vagrant Cascadian]

On 2021-10-21, Vagrant Cascadian wrote:
> For the last couple years guix has been applying simple workarounds in
> u-boot packages to disable the features that required openssl due to
> GPL/openssl license incompatibilities.
>
> I made an attempt at updating guix to u-boot 2021.10, which seems to
> have made openssl harder to workaround... many of the u-boot-BOARD
> packages now require it, and the previous workarounds to disable openssl
> in u-boot-tools seem ineffective.
>
> I see a few ways forward:
>
> * Dig deeper into figuring out how to disable the workarounds...
>
> * Refactor the code that uses openssl to use an alternate
>   implementation. Upstream would welcome the fixes, at least in
>   theory. Most promising candidate might be wolfssl, last I looked, but
>   it may miss some features.
>
> * Convince upstream u-boot to relicense relevent GPLed portions of code
>   with an openssl exception. Upstream is dubious about this being
>   practical, largely due to the sheer number of potential contributors
>   who would have to agree to it.

* Disable substitutes for relevent packages. Technically correct as
  license incompatibility is only triggered on transmission of binary,
  though maybe missing something about the spirit of the GPL.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

[Vagrant Cascadian]

On 2021-10-22, Leo Famulari wrote:
> On Thu, Oct 21, 2021 at 11:17:03PM -0700, Vagrant Cascadian wrote:
>> While openssl 3.0 is licensed compatibly with GPLv3, u-boot has portions
>> which are GPLv2-only, so that's not as attractive of a way forward as
>> one might hope for...
>
> What are other distros doing? Surely we can't be the only group
> distributing u-boot?

Both fedora and (recently) debian have openssl declared as a system
library, invoking the GPL's system library exception... which I
personally find at best to be a grey area workaround.

I wouldn't be surprised if most distros simply ignore the issue
entirely.

Interestingly, today I was called in on a relevent discussion on the
u-boot mailing list:

  https://lists.denx.de/pipermail/u-boot/2021-October/464529.html

Though, it is *possible* that various u-boot-BOARD in some cases doesn't
include any openssl code at all in the resulting binaries, but builds
some tools used during the build process, that are then used to produce
various cryptographic signatures in the build:

  https://lists.denx.de/pipermail/u-boot/2021-October/464533.html

If that's true, it should be ok for various boards (though the
possibility of openssl code getting linked in would be hard to
catch).

u-boot-tools would still need a viable workaround, though.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

[Leo Famulari]

On Thu, Oct 21, 2021 at 11:17:03PM -0700, Vagrant Cascadian wrote:
> While openssl 3.0 is licensed compatibly with GPLv3, u-boot has portions
> which are GPLv2-only, so that's not as attractive of a way forward as
> one might hope for...

What are other distros doing? Surely we can't be the only group
distributing u-boot?

Re: EXWM

[André A . Gomes]

André A. Gomes  writes:

> Guix forces the execution of (exwm-config-default), unless the user has
> a .exwm file.  That forces a default config on EXWM users, which is
> unpleasant for those (like me) that have been using it for a long time.
> Notice that those users have their EXWM configuration where it belongs,
> i.e. in their Emacs' init file.

There's a subtle and important detail I missed, and I've only noticed it
now.

This returns

--8<---cut here---start->8---
emacs -q --batch --eval '(progn (require (quote exwm)) (print (featurep (quote 
exwm'
--8<---cut here---end--->8---

true, whereas

--8<---cut here---start->8---
emacs -q --batch --eval '(print (featurep (quote exwm)))'
--8<---cut here---end--->8---

returns nil.  But

--8<---cut here---start->8---
emacs -q --batch --eval '(print (fboundp (quote exwm-enable)))'
--8<---cut here---end--->8---

returns t (as long as emacs-exwm is installed)!

Therefore the claim that Guix forces a default EXWM config on the users
isn't entirely true.

I was led to think that way since, most likely, I didn't add (require
'exwm) in my Emacs init file.  In result, EXWM's symbols were actually
bound, but, due to the lack of the require statement, it was running
with the non-desired default config.

I apologise for my lack of attention.

I'd say that this also qualifies as evidence that the present "magic" is
a double-edge sword.


--
André A. Gomes
"Free Thought, Free World"

Re: Incentives for review

[Thiago Jung Bauermann]

Hello,

Em quinta-feira, 21 de outubro de 2021, às 13:06:35 -03, Ricardo Wurmus 
escreveu:
> Thiago Jung Bauermann  writes:
> > 2. Going through the guix-patches mailing list looking for
> > submissions that
> > touch the few areas of Guix where I have at least some
> > experience. I don’t
> > think I found an effective method yet (in part the problem is on
> > my side
> > because the search function of the email client I use isn’t very
> > reliable).
> 
> If a browser fits into your workflow you may want to search for
> submissions on https://issues.guix.gnu.org.  It also shows
> “forgotten” issues that would likely benefit from some poking.

I don’t have a browser currently in my workflow, but I don’t mind using it. 
Thank you for the tip, I’ll try it out. Also thanks for reminding about the 
“forgotten” issues. I’ll look into them.

> > One thing that would help me would be some way to “subscribe” to
> > changes in
> > certain areas of Guix. That way, when a patch is submitted which
> > touches
> > those areas I would be automatically copied on the emails that
> > go to the
> > guix-patches mailing list. “areas of Guix” could be defined by
> > paths in the
> > repo, guile modules or regexps matching package names, for
> > example.
> 
> Perhaps issues.guix.gnu.org could offer atom feeds for certain
> keywords (e.g. the name of the module touched by the commits?).

That is a great idea.

-- 
Thanks,
Thiago

Re: Incentives for review

[Thiago Jung Bauermann]

Hello Artem,

Em quinta-feira, 21 de outubro de 2021, às 10:38:44 -03, Artem Chernyak 
escreveu:
> > On Wed, Oct 20, 2021 at 4:37 PM Thiago Jung Bauermann 
 wrote:
> [...]
> 
> > One thing that would help me would be some way to “subscribe” to
> > changes in certain areas of Guix. That way, when a patch is submitted
> > which touches those areas I would be automatically copied on the
> > emails that go to the guix-patches mailing list. “areas of Guix” could
> > be defined by paths in the repo, guile modules or regexps matching
> > package names, for example.
> You could handle it by filtering the email in your email client.

Yes, that is true. Thank you for the tip. I’ll set up some message filters 
for guix-patches.

And also use a separate mail client just to read the mailing list folders 
which is more suited for that use case (I like my current mail client for 
handling personal email and low volume stuff).

> One thing that could help this, is to include a little more info in
> the subject line for patches. Right now we include the broad area
> (e.g. "gnu: ..."). But we could go on level deeper and include the
> specific file (e.g. "gnu: docker: ..."). This becomes important
> because gnu as an area of guix spans a lot of different packages and
> languages. With the extra file level information, we can easily filter
> it down to only the areas we know about.

That is a good idea. I agree that it would be helpful.

-- 
Thanks,
Thiago

Re: EXWM

[André A . Gomes]

Ricardo Wurmus  writes:

> Hi André,
>
>> I packaged EXWM (the right way) for myself a long time ago.  If I'm
>> putting effort into this, it's because I think the community is
>> missing
>> an opportunity to improve.  I won't get anything from any of this.
>> You,
>> on the other hand, seem to be interested in your selfish agenda.
>
> it’s frustrating to get the feeling to be misunderstood.  But please
> take a step back before judging others.  “selfish agenda” sounds a lot
> harsher than is warranted in this context.

I apologise for the choice of words.

> Some background: Guix implements a philosophy that could be described
> as “magic with escape hatches”.  We usually offer neat features and
> automation by *default*, but we also provide escape hatches for those
> who don’t want the magic or have different requirements.

I do understand that, and that's why I like Guix.

I started a thread before sending a patch, since I antecipated that it
would be a sensitive topic.  On top of that, I was concerned about
backwards compatibility since, at this point, lots of users are perhaps
used to the .exwm file.

> The expectation to have EXWM start right up after selecting it as a
>window manager is justified, in my opinion.  Do we offer a sufficient
>escape hatch here?

No.  My point is that the "magic" that Guix provides in this case is a
double-edged sword.

Guix forces the execution of (exwm-config-default), unless the user has
a .exwm file.  That forces a default config on EXWM users, which is
unpleasant for those (like me) that have been using it for a long time.
Notice that those users have their EXWM configuration where it belongs,
i.e. in their Emacs' init file.

The .exwm file is non-standard, and it's not documented in any EXWM
project resource.  This would be somehow alleviated if (exwm-enable)
would run, instead of (exwm-config-default).

But we can do better.

I've advocated to the fact that "choosing EXWM as a window manager" is a
meaningless statement.  The meaningful statement is "choosing Emacs as
the window manager".  The user's Emacs init file dictates how EXWM is to
be initiated and operated.  In short, the EXWM bin wrapper should simply
start Emacs.

The approach I describe is the "standard" and documented way of using
and "starting EXWM".  See C-h P exwm RET for more info.

Thank you.


--
André A. Gomes
"Free Thought, Free World"

Re: EXWM

[Ricardo Wurmus]

Hi André,

I packaged EXWM (the right way) for myself a long time ago.  If 
I'm
putting effort into this, it's because I think the community is 
missing
an opportunity to improve.  I won't get anything from any of 
this.  You,

on the other hand, seem to be interested in your selfish agenda.


it’s frustrating to get the feeling to be misunderstood.  But 
please take a step back before judging others.  “selfish agenda” 
sounds a lot harsher than is warranted in this context.


Some background: Guix implements a philosophy that could be 
described as “magic with escape hatches”.  We usually offer neat 
features and automation by *default*, but we also provide escape 
hatches for those who don’t want the magic or have different 
requirements.  The expectation to have EXWM start right up after 
selecting it as a window manager is justified, in my opinion.  Do 
we offer a sufficient escape hatch here?


--
Ricardo

Re: Test parallelism with CMake

[Liliana Marie Prikler]

Hi,

Am Freitag, den 22.10.2021, 09:10 -0400 schrieb Greg Hogan:
> The cmake-build-system does defer to gnu-build-system, which calls
> `make test -jN`; however, CMake generated Makefile specifies 'test'
> as a single target (the Ninja generator suffers from the same issue)
> so `ctest` is run without parallelism.
That does sound like a CMake bug.  Has no one on their end addressed
that like since the inception of CMake?

> To run CMake tests with parallelism the cmake-build-system should
> directly call `ctest` with the configured parallelism (same '-jN'
> argument). The cmake-build-system's check method is essentially
> untouched from March, 2013 (commit c6bded8a) so this issue has
> existed from the beginning.
> 
> I made an inelegant patch to my local guix repo, essentially
> replacing cmake-build-system:check with a copy of gnu-build-
> system:check and changing 'apply invoke "make" test-target' to 'apply
> invoke "ctest"'. This works, although the package I was working on
> requires parallel tests to be disabled. Once the expectation is set
> that code will be run serially it is difficult to change the default
> to parallel execution.
> 
> It seems that we should at a minimum document the issue in cmake-
> build-system:check. We could patch cmake-build-system to enable test
> parallelism and explicitly disable that setting for packages which
> succeed before but fail after making the change. What do you think?
I'm not too sure on any of this.  For one, we'd have to survey whether
really all CMake-based packages use ctest to build and not any other
tool of their choosing.  Next, we'd have to adjust the calling
conventions to add support for ctest command syntax, given that it is
indeed another tool with probably conventions from make itself. 
Finally, messing with cmake-build-system would most likely result in a
world rebuild, so we can realistically do this on core-updates.

Regards,
Liliana

Re: Preservation of Guix Report

[Timothy Sample]

Hi again,

Timothy Sample  writes:

> Yes, but I have another trick.  The “known” endpoint [1].  If you
> already know the SWHIDs you want to check, you can check 1,000 per call.
> With the anonymous rate limit, I can check 120,000 every hour, which is
> plenty.
>
> [1]
> https://docs.softwareheritage.org/devel/swh-web/uri-scheme-api.html#get--api-1-content-known-(sha1)[,(sha1),%20...,(sha1)]-

That’s the wrong “known” endpoint.  I meant to link to this one:

https://docs.softwareheritage.org/devel/swh-web/uri-scheme-api.html#post--api-1-known-

Re: Preservation of Guix Report

[Timothy Sample]

Hey,

Ludovic Courtès  writes:

> Timothy Sample  skribis:
>
>> Early this summer I did a bunch of work trying to figure out which Guix
>> sources are preserved by the SWH archive.  I’m finally ready to share
>> some preliminary results!
>>
>> https://ngyro.com/pog-reports/2021-10-20/
>>
>> This report is already quite outdated, though.  It only covers commits
>> up to the end of May, and sometime in June is when the sources were
>> checked against the SWH archive.  I’m sharing it now to avoid any
>> further delays.
>
> This is truly awesome!  (Did you manage to grab all that info with the
> default rate limit?!)

Yes, but I have another trick.  The “known” endpoint [1].  If you
already know the SWHIDs you want to check, you can check 1,000 per call.
With the anonymous rate limit, I can check 120,000 every hour, which is
plenty.

[1] 
https://docs.softwareheritage.org/devel/swh-web/uri-scheme-api.html#get--api-1-content-known-(sha1)[,(sha1),%20...,(sha1)]-

> I can’t wait for the updated report now that Simon and yourself have
> identified that SWHID computation bug!

I’m computing SWHIDs while writing this.  Not long now!

> Some of our  refer to tags, not commits.  How do you
> determine whether they’re saved?

The short answer is “elbow grease”.  Basically, I’m taking a “work
harder, not smarter” approach.  :p  I go out and obtain the source,
verify it with Guix’s hash, and then compute the SWHID.  This is another
thing we could move to the CI infrastructure, but I think there might be
some hiccoughs.  For git-references, I believe we can’t just compute the
ID after the download derivation – we would have to change the download
derivation itself.  Maybe add an ‘swhid’ output?  It’s a little more
complicated than just throwing up some scripts, anyway.

> ‘guix lint -c archival’ uses ‘lookup-origin-revision’, which is a good
> approximation, but it’s not 100% reliable because tags can be modified
> and that procedure only tells you that a same-named tag was found, not
> that it’s the commit you were expecting.  (And really, we should stop
> referring to tags.)

Like zimoun said elsewhere in this thread, having an explicit mapping
from Guix hash to SHWID will improve reliability quite a bit.  It’s hard
to get to 100%, though!  With the reports, we will eventually be able to
check everything.  However, there’s still a small possibility of bugs
and false positives.  Ultimately, I’m hoping the reports will help
detect small problems (some specific source is missing) and guide our
efforts on big problems (xz support in Disarchive or support for more
version control systems, etc.).


-- Tim

Re: Test parallelism with CMake

[Greg Hogan]

On Sat, Oct 9, 2021 at 3:56 AM Liliana Marie Prikler <
liliana.prik...@gmail.com> wrote:

> for the purposes of GNU Guix, #:parallel-build? and #:parallel-tests?
> are distinct flags and the latter (if implemented) would apply to the
> check phase.  Our cmake-build-system in this case defers to gnu-build-
> system, which ought to insert -jN as you described.
>

On Thu, Oct 21, 2021 at 3:30 PM Ludovic Courtès  wrote:

> Does CMake generate makefiles targets that would allow tests to run in
> parallel?  How does that even work in CMake?
>

Hi Liliana and Ludo’,

The cmake-build-system does defer to gnu-build-system, which calls `make
test -jN`; however, CMake generated Makefile specifies 'test' as a single
target (the Ninja generator suffers from the same issue) so `ctest` is run
without parallelism.

To run CMake tests with parallelism the cmake-build-system should directly
call `ctest` with the configured parallelism (same '-jN' argument). The
cmake-build-system's check method is essentially untouched from March, 2013
(commit c6bded8a) so this issue has existed from the beginning.

I made an inelegant patch to my local guix repo, essentially replacing
cmake-build-system:check with a copy of gnu-build-system:check and changing
'apply invoke "make" test-target' to 'apply invoke "ctest"'. This works,
although the package I was working on requires parallel tests to be
disabled. Once the expectation is set that code will be run serially it is
difficult to change the default to parallel execution.

It seems that we should at a minimum document the issue in
cmake-build-system:check. We could patch cmake-build-system to enable test
parallelism and explicitly disable that setting for packages which succeed
before but fail after making the change. What do you think?

Greg

Re: Incentives for review

[zimoun]

Hi Jonathan,

On Fri, 22 Oct 2021 at 12:40, Jonathan McHugh
 wrote:

> > 
>
> Yes, Arun has recommended public-inbox before, Im enthused by anything he 
> uses or packages.

For the Emacs-Notmuch user, give a look at:



And for the interested reader about how to use public-inbox, give a
look at the thread:



It had been discussed several times to have an official public-inbox
instance.  One could imagine: .  Well,
Org-mode did it [1].  Time is flying and it is hard to burn the candle
at both ends. :-)

1: 


> TBH, having mastered lua/jit I would feel a bit dirty packaging NPN to 
> satisfy something that Lua would be better suited for. What are the 
> (technical/usability) advantages of choosing LibreAdventure?

I do not play to game based on computers so I lack imagination on this
area. :-)
That's just because FSF used it for their LibrePlanet event.

Cheers,
simon

Re: Incentives for review

[zimoun]

Hi,

On Fri, 22 Oct 2021 at 12:49, Arun Isaac  wrote:

> > These are all excellent ideas, and seeing you articulate them
> > makes me happy, because in my experience there’s always good code
> > around the corner whenever you have good ideas :)

It remember me this wishlist: Use Message-ID for indexing instead numbering.




Let take an example.  This is indexing #2,



is fine when using a browser but it is pain from Emacs-Notmuch (or any
descent email client) where is it really easy to get the Message-ID.
For instance, I have to open my browser, scroll to find the relevant
message, copy the URL, go back to my email, paste the link for
publicly sharing it.  Message-ID is the natural email-indexing, thus
it appears to me natural to use when the workflow is email-based. :-)


The wishlist is to also allow this:



as it is done with public-inbox, see
.

Using a bit of Emacs Lisp glue (or submit it to debbugs.el or Gnus),
it becomes easier for both world.


Cheers,
simon

Re: Incentives for review

[Arun Isaac]

Hi zimoun,

> The code running it is Woof (lisp based):
>
>

Ah, woof looks good! :-) It feels a lot like patchwork, but better
integrated into email. I'm tempted to say it's better than our debbugs
bug tracker! :-P But, it may be hard to move out of debbugs now that we
are in it.

Regards,
Arun


signature.asc
Description: PGP signature

Re: Incentives for review

[Jonathan McHugh]

Hi Arun,

I wasnt thinking of that. Ill update you if I find a reference among my notes.


Jonathan

October 22, 2021 12:44 PM, "Arun Isaac"  wrote:

> Hi Jonathan,
> 
>> If I recall, you can request Debbugs content if you email them.
> 
> I think you are referring to https://debbugs.gnu.org/server-request.html
> I haven't tried it myself, and I'm not sure, but it probably doesn't
> give you access to the raw emails. I'm guessing it's just an email
> interface to the usual SOAP API.
> 
> Regards,
> Arun

Re: Incentives for review

[Jonathan McHugh]

October 22, 2021 12:48 PM, "Arun Isaac"  wrote:

> Hi Ricardo,
> 
>> These are all excellent ideas, and seeing you articulate them
>> makes me happy, because in my experience there’s always good code
>> around the corner whenever you have good ideas :)
> 
> He he, thanks! :-)
> 
>> So to hack on mumi I’d suggest downloading a copy of the raw debbugs
>> data from issues.guix.gnu.org. I could put an archive somewhere where
>> you can fetch it.
> 
> Yes, please! Some minimal archive along with a few lines of instructions
> on how to import it into mumi would be great. It might also be more
> generally useful to people who want to hack on mumi.
> 
> Thanks,
> Arun

Seconded

Re: EXWM

[André A . Gomes]

Arun Isaac  writes:

> Hi André,
>
>> Your reply indicates that little or no effort was put into understanding
>> my points.  And no effort was put to indicate where did my reasoning go
>> wrong.
>
> I, for one, did not understand how your workflow is affected by the way
> EXWM is currently packaged in Guix. As far as I understand, Guix's
> ~/.exwm separation is optional and you are not forced to create it. I
> don't have an ~/.exwm, for example.

It's frustrating to keep repeating myself at this point, but let's do
it.

It is optional, indeed.  Now assume that you don't have a .exwm file.
Then (exwm-config-default) runs.  But that's backwards, since the user
might not want that piece of code to run.  

I have explained this from several points of view, several times.  For
instance, in one of the replies to Ludovic.

> But, it is possible that I may have misunderstood something you
> said. Perhaps, making your point more precise by providing a patch or
> just a code snippet showing your modified exwm package would help.

I did all of that.  I sent a link with my own EXWM package definition.
And I've illustrated my points with code snippets.

https://git.sr.ht/~aadcg/aadcg-guix-channel/tree/master/item/packages/aadcg-emacs-xyz.scm#L150


--
André A. Gomes
"Free Thought, Free World"

Re: Incentives for review

[Arun Isaac]

Hi Ricardo,

> These are all excellent ideas, and seeing you articulate them 
> makes me happy, because in my experience there’s always good code 
> around the corner whenever you have good ideas :)

He he, thanks! :-)

> So to hack on mumi I’d suggest downloading a copy of the raw debbugs
> data from issues.guix.gnu.org.  I could put an archive somewhere where
> you can fetch it.

Yes, please! Some minimal archive along with a few lines of instructions
on how to import it into mumi would be great. It might also be more
generally useful to people who want to hack on mumi.

Thanks,
Arun


signature.asc
Description: PGP signature

Re: Incentives for review

[Arun Isaac]

Hi Jonathan,

> If I recall, you can request Debbugs content if you email them.

I think you are referring to https://debbugs.gnu.org/server-request.html
I haven't tried it myself, and I'm not sure, but it probably doesn't
give you access to the raw emails. I'm guessing it's just an email
interface to the usual SOAP API.

Regards,
Arun


signature.asc
Description: PGP signature

Re: Incentives for review

[Jonathan McHugh]

Hi Simon,

October 22, 2021 11:22 AM, "zimoun"  wrote:

> Hi Jonathan,
> 
> On Fri, 22 Oct 2021 at 08:37, "Jonathan McHugh" 
>  wrote:
> 
>> Its also worth citing some of the suggestions in this devel-guix thread 
>> concerning tooling or
>> options:
>> https://lists.nongnu.org/archive/html/guix-devel/2021-08/msg00042.html
> 
> Thanks.
> 
>> Suggestions included:
>> Bugs Everywhere https://bugs-everywhere.readthedocs.io/en/latest
>> Git-Issue https://github.com/dspinellis/git-issue
>> Fossil https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki
>> 
>> IMHO, I though Bugs Everywhere was the most interesting, though it may have 
>> experienced some
>> bitrot.
> 
> Git based, it is possible to use public-inbox with:
> 
> 
> 

Yes, Arun has recommended public-inbox before, Im enthused by anything he uses 
or packages.

>> More recently I have been deliberating on the idea of using a MUD type
>> tool as an interface for issue and bugtracking.
> 
> Yeah, maybe gamify the review could help. Maybe Libreadventure could
> help.
> 
> 1: 
> 2: 
> 
Thanks for the catch, I had forgotten that one (and your appeal for someebody 
to package it!).

The fact its been trialed with FSF and could be Guix Days compatible is a big 
plus.

TBH, having mastered lua/jit I would feel a bit dirty packaging NPN to satisfy 
something that Lua would be better suited for. What are the 
(technical/usability) advantages of choosing LibreAdventure?

I will reflect on this, though Im (personally) more interested in building 
worlds from GemText than JSON.

# One more suggestion
Has anybody ever considered or used psyc - Protocol for Synchronous 
Conferencing?

(its how I discovered Powwow)

https://psyc.eu/
``` description
Imagine smartly multicasted chat and conferencing, non-proprietary instant 
messaging, distributed social networking and data sharing. And now imagine all 
of this rolled into one. PSYC is an open source protocol and technology, 
bringing the useful and amazing aspects of several technologies, some of which 
have been proprietary too long, together. 


It has a curious mixture of bit ambition and long history but I cant (yet) tell 
how modern and functional it is.
Pscyc utilities seem interesting
https://perl.psyc.eu/
```
git2psyc- report changes to a git repository into a developer chatroom
psycauth- authenticate something with your PSYC identity
psyccat - dump a file to a PSYC recipient
psyccmd - remote control psycamp and whatever wants to be controlled
psycfilemonitor*- notify changes to the file system in realtime
psycion - amazing console psyc client!
psyclisten  - receive messages and notify the user about them
psycmail- report incoming emails to the recipient
psycamp*- media player with PSYC notification and remote control
psycmsg - send a message to a PSYC recipient
psycnotify  - send presence notification from the command line
psycsyncd   - interfaces PSYC SYNC protocol to DBI (SQL databases etc)
syslog2psyc - daemon that receives events from syslog and forwards to PSYC
remotor - control console for Tor routers that can notify into PSYC
```

For my purposes, the PSYC Syntax Specification could potentially serve 
orthogonal aspects for complementing the design principles of the Gemini 
protocol
https://about.psyc.eu/Spec:Syntax
https://gemini.circumlunar.space/docs/specification.html



Jonathan

Re: EXWM

[Arun Isaac]

Hi André,

> Your reply indicates that little or no effort was put into understanding
> my points.  And no effort was put to indicate where did my reasoning go
> wrong.

I, for one, did not understand how your workflow is affected by the way
EXWM is currently packaged in Guix. As far as I understand, Guix's
~/.exwm separation is optional and you are not forced to create it. I
don't have an ~/.exwm, for example.

But, it is possible that I may have misunderstood something you
said. Perhaps, making your point more precise by providing a patch or
just a code snippet showing your modified exwm package would help.

Thanks,
Arun


signature.asc
Description: PGP signature

Re: EXWM

[André A . Gomes]

Jan Nieuwenhuizen  writes:

> André A. Gomes writes:
>
>> Jan Nieuwenhuizen  writes:
>>
>>> I just tried adding my ~/.exwm into my init.el and running a nested
>>> emacs and now I get a GUI dialog:
>>>
>>> Replace existing window manager? Y/N
>>>
>>> Not great!  Not very suprisingly, the extra unnecessary initialization
>>> /does/ hurt here.
>>
>> Isn't exwm doing precisely what it's supposed to do?  Isn't it fair that
>> the newly spawned (nested) Emacs has the right to take control over the
>> "older" Emacs?
>
> Of course; that's my point exactly!  Emacs cannot know, and thus cannot
> help but doing the annoying thing: throwing a dialogue.  That is what
> this code
>
> (cond ((file-exists-p "~/.exwm") (load-file "~/.exwm"))
>   ((not (featurep (quote exwm)))
>(require (quote exwm))
>(require (quote exwm-config))
>(exwm-config-default)
>(message (concat "exwm configuration not found. "
> "Falling back to default configuration..."
>
> helps to prevent in a very nice way.  Let's please keep it!

After all the effort I put into all of my previous messages, it's
unfortunate to receive such a reply.

I packaged EXWM (the right way) for myself a long time ago.  If I'm
putting effort into this, it's because I think the community is missing
an opportunity to improve.  I won't get anything from any of this.  You,
on the other hand, seem to be interested in your selfish agenda.

Your reply indicates that little or no effort was put into understanding
my points.  And no effort was put to indicate where did my reasoning go
wrong.

I give up.  Let "worse is better" reign.


--
André A. Gomes
"Free Thought, Free World"

Re: Incentives for review

[zimoun]

Hi Jonathan,

On Fri, 22 Oct 2021 at 08:37, "Jonathan McHugh"  
wrote:

> Its also worth citing some of the suggestions in this devel-guix thread 
> concerning tooling or options:
> https://lists.nongnu.org/archive/html/guix-devel/2021-08/msg00042.html

Thanks.

> Suggestions included:
> Bugs Everywhere https://bugs-everywhere.readthedocs.io/en/latest/
> Git-Issue https://github.com/dspinellis/git-issue
> Fossil https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki
>
> IMHO, I though Bugs Everywhere was the most interesting, though it may have 
> experienced some bitrot.

Git based, it is possible to use public-inbox with:




> More recently I have been deliberating on the idea of using a MUD type
> tool as an interface for issue and bugtracking.

Yeah, maybe gamify the review could help.  Maybe Libreadventure could
help.

1: 
2: 


Cheers,
simon

Re: Incentives for review

[Jonathan McHugh]

Hi Simon,

I had noticed Woof and it does seem interesting and worthy of analysis.

I should point out that the Ogmode community have the same problems and 
complaints regarding the governance and efficacy of issue/bug tracking. This is 
a socio-technological problem, which hopefully has solutions which can cut 
across communities.

Its also worth citing some of the suggestions in this devel-guix thread 
concerning tooling or options:
https://lists.nongnu.org/archive/html/guix-devel/2021-08/msg00042.html

Suggestions included:
Bugs Everywhere https://bugs-everywhere.readthedocs.io/en/latest/
Git-Issue https://github.com/dspinellis/git-issue
Fossil https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki

IMHO, I though Bugs Everywhere was the most interesting, though it may have 
experienced some bitrot.


More recently I have been deliberating on the idea of using a MUD type tool as 
an interface for issue and bugtracking.

It seems that Powwow would be capable of using scripts in an interesting way.
https://www.hoopajoo.net/static/powwow-mirror/powwow/index.html
This interests me:
```
Powwow also implements the MUME remote editing protocol, which enables you to 
edit texts on the MUD using your own favourite editor, several texts at once if 
you have a windowing terminal. 
```
Im also investigating Tintin++
https://tintin.mudhalla.net/

I personally would find it interesting to create 'conversational models' for 
issue/bug tracking in such an environment, backed by:
* interoperability with computing environments
* interpreting infrastructure
* projectile style configurations
* supplementary protocols
* light writing formats
* configs and bindings to provide workflow

A MUD type inferface is perhaps only a speculative concern but Id be interested 
in hearing -/+ opinions and interest levels, if not practical suggestions.


As some may be aware, I have been considering the issue/bug tracking topic from 
the perspective of the Gemini protocol (though now with a wider scale than just 
comsidering Debbugs). 

That is proceeding, though I was impeeded by some physical setbacks 
(status:resolved) and completing wider responsibilities. Now back in the flow, 
I will provide updates once my projects start perculating.

@Arun please mail me privately regarding your plans, Id like to hear about 
where they may be intersections.

@Christine I look forward to replying to your (private) mail in due course - 
apoligies for radio silence. If you have suggestions regarding how Guix can go 
MUD Im sure we'd all be interested!

Kind regards,



Jonathan McHugh
indieterminacy@libre.brussels

October 22, 2021 9:44 AM, "zimoun"  wrote:

> Hi Arun,
> 
> On Thu, 21 Oct 2021 at 23:51, Arun Isaac  wrote:
> 
>> The way I see it, we are outgrowing general purpose bug trackers like
>> debbugs. We need a special purpose bug tracker specifically for Guix
>> with its special requirements. We are a big enough community for this to
>> be important.
> 
> For an example of such «special purpose bug tracker», give a look at
> what Org-mode people do:
> 
> 
> 
> Well, it is currently down. It looks like that:
> 
> 
> 
> The code running it is Woof (lisp based):
> 
> 
> 
> Maybe there are some ideas to borrow. :-)
> 
> Cheers,
> simon

Re: Preservation of Guix Report

[zimoun]

Hi Timothy,

On Thu, 21 Oct 2021 at 12:26, Timothy Sample  wrote:

> Fixing this in Disarchive is going to make a *huge* difference, so that
> is now high priority for me (it’s a one line change, but I want to fix
> it, release it, update Guix, and recompute the report).

Cool!  Excited to get the new report.


> Thanks!  While investigating the above problem, I found a page that
> lists what SWH is getting from us [1] and another showing when they are
> scanning “sources.json” [2].  I don’t know if you’ve seen them before,
> but they will be invaluable for figuring this stuff out.
>
> [1] 
> https://archive.softwareheritage.org/browse/origin/branches/?origin_url=https://guix.gnu.org/sources.json
> [2] 
> https://archive.softwareheritage.org/browse/origin/visits/?origin_url=https://guix.gnu.org/sources.json

I do not know these.  However, I am confused how to use them.  For
instance, clicking to a random orange link:



which points to a snapshot of the Git repo of Guix.  I would be
interesting to know what does it mean “partial”.  And read the log.
Well, let roam on #swh-devel. ;-)


Cheers,
simon

Re: Preservation of Guix Report

[zimoun]

Hi Ludo,

On Thu, 21 Oct 2021 at 22:47, Ludovic Courtès  wrote:

> ‘guix lint -c archival’ uses ‘lookup-origin-revision’, which is a good
> approximation, but it’s not 100% reliable because tags can be modified
> and that procedure only tells you that a same-named tag was found, not
> that it’s the commit you were expecting.  (And really, we should stop
> referring to tags.)

At package time, Guix uses tag.  Then “guix lint” saves the upstream
repo; containing the correct tag.  Now, upstream replaces in-place the
tag and saves to SWH by their own.  How does SWH deal with this case?


Well, because it is not affordable to switch from the current
tag-address to immutable commit-address for defining packages, in order
to be 100% reliable, any fallback should use Disarchive-DB which stores
the mapping from checksum to swhid; for all kind origins.

Is it what you have in mind?

Cheers,
simon

Re: Incentives for review

[zimoun]

Hi Arun,

On Thu, 21 Oct 2021 at 23:51, Arun Isaac  wrote:

> The way I see it, we are outgrowing general purpose bug trackers like
> debbugs. We need a special purpose bug tracker specifically for Guix
> with its special requirements. We are a big enough community for this to
> be important.

For an example of such «special purpose bug tracker», give a look at
what Org-mode people do:

   

Well, it is currently down.  It looks like that:

   

The code running it is Woof (lisp based):

   

Maybe there are some ideas to borrow. :-)


Cheers,
simon

Re: Public guix offload server

[zimoun]

Hi Tobias,

I understand your point of view.

On Fri, 22 Oct 2021 at 00:16, Tobias Geerinckx-Rice  wrote:

> Trusting people not to be evil is not the same as having to trust 
> the opsec habits of every single one of them.  Trust isn't 
> transitive.  Personally, I don't think a rogue zimoun will 
> suddenly decide to abuse us.  I think rogues will abuse zimoun the 
> very first chance they get.

>From my understanding, here is the net of our “disagreement”.

> That's not a matter of degree: it's a whole different threat 
> model, as is injecting arbitrary binaries vs. pushing malicious 
> code commits.  Both are bad news, but there's an order of 
> magnitude difference between the two.

And I miss the threat model about “injecting binaries” in the case of
shared offload.  Anyway. :-)

Let move forward and discuss another solution than the usual offload.

You pointed the idea «one might consider dropping SSH account-based
access in favour of a minimal job submission API, and just return the
results through guix publish or so…?  OTOH, that's yet another code
path.»

Imagine another Cuirass instance where any committer could add [1] their
own branch.  It would act as this minimal job submission API.

1: 

The questions are the authentication to this Cuirass instance and how
Cuirass deals with rebased branch (which would happen).

WDYT?


Cheers,
simon

Re: Public guix offload server

[Jonathan McHugh]

I have utmost confidence in the Guix project, it has lots of smart and 
inquisitive people to suppliment its accountable structures - a very useful 
bulwark against exploitative behaviour!


Jonathan McHugh
indieterminacy@libre.brussels

October 22, 2021 12:59 AM, "Tobias Geerinckx-Rice"  wrote:

> All,
> 
> zimoun 写道：
> 
>> Do you mean that trusted users would try WM-escape exploits?
>>> The world has been formed by warewolves inside communities
>>> purposely
>>> causing harm. Looking further back, Oliver the Spy is a classic
>>> examplar of trust networks being hollowed out.
> 
> So…
> 
>> I cannot assume that on one hand one trusted person pushes to
>> the main
>> Git repo in good faith and on other hand this very same trusted
>> person
>> behaves as a warewolves using a shared resource.
> 
> …li'l' sleepy here, bewarned, but before this gets out of hand: I
> never implied direct abuse of trust by committers. I don't
> consider it the main threat[0].
> 
> There are the people you meet at FOSDEM and the users who log into
> machines. Both can be compromised, but the latter are much easier
> and more likely to be.
> 
> Such compromise is not laughable or hypothetical: it happens
> *constantly*. It's how kernel.org was utterly owned[1].
> 
> Trusting people not to be evil is not the same as having to trust
> the opsec habits of every single one of them. Trust isn't
> transitive. Personally, I don't think a rogue zimoun will
> suddenly decide to abuse us. I think rogues will abuse zimoun the
> very first chance they get.
> 
> That's not a matter of degree: it's a whole different threat
> model, as is injecting arbitrary binaries vs. pushing malicious
> code commits. Both are bad news, but there's an order of
> magnitude difference between the two.
> 
>> For sure, one can always abuse the trust. Based on this
>> principle, we
>> could stop any collaborative work right now. The real question
>> is the
>> evaluation of the risk of such abuse by trusted people after
>> long period
>> of collaboration (that’s what committer usually means).
> 
> Isn't that the kind of hands-up-in-the-air why-bother
> nothing's-perfect fatalism I thought your Python quote (thanks!)
> was trying to warn me about? ;-)
> 
> Zzz,
> 
> T G-R
> 
> [0]: That's probably no more than an optimistic human flaw on my
> part and ‘disgruntled ex-whatevers’ are probably more of a threat
> that most orgs dare to admit.
> 
> [1]: I know, ancient history, but I'm working from memory here.
> I'm sure it would be trivial to find a more topical example.

Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

[Vagrant Cascadian]

On 2019-03-08, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>> I'm not sure where it would be appropriate to add more comments
>> regarding the GPL/Openssl incompatibilities; e.g. if someone were to
>> propose adding one of the u-boot targets that requires it, they might
>> just go ahead and re-add the openssl input...
>
> There’s always a risk.  I guess we’ll have to be careful when doing
> reviews.
>
> In addition, we can add a ‘lint’ checker for this case, WDYT?
>
>> From ee613387c49ca60905e0a40af8af017828c8aec8 Mon Sep 17 00:00:00 2001
>> From: Vagrant Cascadian 
>> Date: Thu, 7 Mar 2019 21:50:58 +
>> Subject: [PATCH] gnu: u-boot: Remove openssl input.
>>
>> Fixes: https://bugs.gnu.org/34717
>>
>> * gnu/packages/bootloaders (u-boot): Remove openssl from native-inputs.
>>   (u-boot-tools): Disable FIT_SIGNATURES in tests.
>
> Applied, thanks!

For the last couple years guix has been applying simple workarounds in
u-boot packages to disable the features that required openssl due to
GPL/openssl license incompatibilities.

I made an attempt at updating guix to u-boot 2021.10, which seems to
have made openssl harder to workaround... many of the u-boot-BOARD
packages now require it, and the previous workarounds to disable openssl
in u-boot-tools seem ineffective.

I see a few ways forward:

* Dig deeper into figuring out how to disable the workarounds...

* Refactor the code that uses openssl to use an alternate
  implementation. Upstream would welcome the fixes, at least in
  theory. Most promising candidate might be wolfssl, last I looked, but
  it may miss some features.

* Convince upstream u-boot to relicense relevent GPLed portions of code
  with an openssl exception. Upstream is dubious about this being
  practical, largely due to the sheer number of potential contributors
  who would have to agree to it.

* ???


While openssl 3.0 is licensed compatibly with GPLv3, u-boot has portions
which are GPLv2-only, so that's not as attractive of a way forward as
one might hope for...


live well,
  vagrant


signature.asc
Description: PGP signature