bug#58374: GVFS depends on WebKitGTK via gnome-online-accounts

[kiasoc5--- via Bug reports for GNU Guix]

For inspiration, here is Arch Linux's pkgbuild for libgoa, which is 
split from gnome-online-accounts:


https://gitlab.archlinux.org/archlinux/packaging/packages/gnome-online-accounts/-/blob/main/PKGBUILD

bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor

[Ludovic Courtès]

Hi,

(Cc: guix-sysadmin.)

Tobias Geerinckx-Rice  skribis:

> On 2023-08-04 18:57, Altadil via Bug reports for GNU Guix wrote:

[...]

>> The result is an error message saying: "The connection has timed out".
>> It looks like a general block of Tor rather than a block of specific
>> IPs, since attempting with different Tor circuits does not change the
>
> The Guix project does not block Tor.  If the datacentre has decided to
> block Tor like it blocked most of Russia, there is little we can do
> but ask them to reconsider.

I think it’s worse than this.  I noticed that ci.guix.gnu.org (same
machine) would occasionally time out on my side, without Tor, starting
from this week (I was on vacation before, so I don’t know exactly when
it started).  From a browser, I get this “DoS attack” HTML page:


The HTML doesn’t contain clues as to where it originates from.

--8<---cut here---start->8---
$ wget -qO- http://ci.guix.gnu.org | tail

Attack Detected



Blocked because of DoS Attack
Your computer has been blocked because a DoS attack originating from 
your system was detected. For more information, contact the system 
administrator.


--8<---cut here---end--->8---

Some firewall-ish network equipment must be sitting right before our
machine.  It’s a problem because fetching narinfos and nars is likely to
count as a “DoS attack”.

Could it be some change at the MDC?

Thanks,
Ludo’.

bug#65225: [PATCH] environment: Build the profile for the requested system.

[Ludovic Courtès]

Hi,

Josselin Poiret  skribis:

> IMO, this is way too complicated to keep in mind at all times, and there
> are bugs lurking under the surface absolutely everywhere, waiting for a
> corner case to be uncovered.

Great writeup!  Yeah, that’s the sad situation of mixing parameters and
monads; it’s a longstanding issue and as you write, there have been
bugs.  The solution to these has been primarily to avoid relying on
default values and pass explicit values.  The other trick is what
‘lower-gexp’ does, with the comment you quoted, or what
‘gexp->derivation’ does.

The good news is that the monadic interface is kept internal
and not really exposed to users, who should stick to file-like objects
as much as possible.

Back to profile hooks: it seems that passing #:system #f to
‘gexp->derivation’ in each of these hooks would solve the problem, no?

Alternatively, each hook could take ‘system’ as a second argument.

Willing to give it a shot?

Thanks,
Ludo’.

bug#65253: Renpy-launcher raises exception when opening editor.

[Jesse Gibbons]

Here's a problem I diagnosed in the version of renpy installed by guix 
(hash 19a7a824c35eae56ce56e2a460042fb7e2129234):

Problem: Editor won't open, raises exception.
How to replicate:
1. Run renpy-launcher
2. Click any of the files under Edit File.
An exception is raised and the stack trace is dumped.
Cause: Editor files (*.edit.py) are not copied at install.
Proposed Solution: Copy editor files at install. I frankly don't care 
about Visual Studio Code or Atom, but at minimum "launcher/None.edit.py" 
and "launcher/System Editor.edit.py" must be included or the editor 
function won't work.


--
-Jesse Gibbons

bug#65252: Renpy raises exception when opening save screen.

[Jesse Gibbons]

Here's a problem I diagnosed in the version of renpy installed by guix 
(19a7a824c35eae56ce56e2a460042fb7e2129234):

Problem: Save screen raises an exception
How to replicate:
1. launch a renpy project
2. Navigate to the save screen.
An exception is raised and the stack trace is dumped.
Cause: config.has_sync not set outside renpy/common/00sync.rpy which is 
deleted by guix (presumably for security reasons)
Proposed Solution: Set config.has_sync = None in a different file at a 
point while config.locked=False. If no suitable file can be found, 
perhaps create renpy/common/00guix.rpy using a patch?


--
-Jesse Gibbons

bug#65218: emacs-orderless 1.0 shows as 0.8 due to incorrect value in package file

[Hilton Chain via Bug reports for GNU Guix]

Hi Piotr,

On Fri, 11 Aug 2023 04:18:57 +0800,
Piotr Kwieciński wrote:
>
> [1  ]
> [2  ]
> I have the latest version of emacs-orderless installed on using guix and it 
> shows:
>
>  Status: External in 
> ‘/gnu/store/mp2ckcr7psy9myby262zqii36cd49yja-emacs-orderless-1.0/share/emacs/site-lisp/orderless-1.0/’
>  (unsigned).
> Version: 0.8
> Summary: Completion style for matching regexps in any order
>
> This is caused by an incorrect version of a package declared in orderless.el.


It seems that emacs-orderless in Guix wasn't really updated to 1.0,
only the version field was changed.


> I'm new to the ecosystem and I'm not familiar with the process of fixing this.
> The issue was fixed by the package maintainer in commit
> https://github.com/oantolin/orderless/commit/847694e78c12d903d5e3f6cb365a5d3b984db537
>
> Would replacing commit in the package definition be enough ? Swapping 
> 004cee6b8e01f8eb0cb1c683d0a637b14890600f with
> 847694e78c12d903d5e3f6cb365a5d3b984db537


That's not enough, the hash in (sha256 (base32 [...])) needs changing
as well.

And when updating an untagged revision to a tagged release, we usually
drop the outer let form, and use the value from version field for
commit.

For example, the original definition:
--8<---cut here---start->8---
(define-public emacs-orderless
  (let ((commit [...]))
(package
  (name "emacs-orderless")
  (version [...])
  (source
   (origin
 (method git-fetch)
 (uri (git-reference
   (url "https://github.com/oantolin/orderless;)
   (commit commit)))
 (file-name (git-file-name name version))
 (sha256
  (base32 [...]
  [...])))
--8<---cut here---end--->8---

would be changed to:
--8<---cut here---start->8---
(define-public emacs-orderless
  (package
(name "emacs-orderless")
(version "1.0")
(source
 (origin
   (method git-fetch)
   (uri (git-reference
 (url "https://github.com/oantolin/orderless;)
 (commit version)))   ; <- see here
   (file-name (git-file-name name version))
   (sha256
(base32 [...] ; <- hash is changed as well
[...]))
--8<---cut here---end--->8---

BTW the hash can be obtained with `guix hash' [1]:
--8<---cut here---start->8---
git clone https://[...] emacs-orderless

cd emacs-orderless
git checkout 1.0

guix hash -rx .
--8<---cut here---end--->8---

Would you like to get familiar with the process by going through the
way [2] to make your first contribution? ;)

I can send a patch if you prefer, and it may take a few days to get
the change into Guix.

Thanks


[1]: 
[2]: 

(Not sure why this issue isn't on the mailing list, but is available
in Debbugs.  Still under moderation?)

bug#65225: [PATCH] environment: Build the profile for the requested system.

[Josselin Poiret via Bug reports for GNU Guix]

Hi everyone,

Actually, let me add a big erratum, since it appears I misread the
intention of gexp->derivation (and realized 2 minutes after writing the
previous email).

Josselin Poiret  writes:
> --8<---cut here---start->8---
> (mlet* %store-monad ( ;; The following binding forces '%current-system' and
>  ;; '%current-target-system' to be looked up at >>=
>  ;; time.
>  (graft?(set-grafting graft?))
>
>  (system -> (or system (%current-system)))
>  (target -> (if (eq? target 'current)
> (%current-target-system)
> target))
>  ...)
>   ...)
> --8<---cut here---end--->8---
>
> Well, the issue here is that such an mlet starts by translating the
> graft? binding into a >>= call, which ends up putting the rest of the
> translation into a function call that will *not* be called until the
> monadic value is run.  That means that the system and target bindings
> afterwards are *not* looked up at call time but at monadic run time!

This is actually what the comment above hints at, I misunderstood its
meaning.  It seems that this piece of code used to be (before 2015)

--8<---cut here---start->8---
(mlet* %store-monad ( ;; The following binding forces '%current-system' and
 ;; '%current-target-system' to be looked up at >>=
 ;; time.
 (unused(return #f)

 (system -> (or system (%current-system)))
 (target -> (if (eq? target 'current)
(%current-target-system)
target))
 ...)
  ...)
--8<---cut here---end--->8---

probably at a time when (current-system) didn't exist.  In turn, this
means that gexp->derivation intentionally delays getting the current
system to monadic run time.  Thus, we probably need to pass an optional
#:system argument to the hooks that they can forward to
gexp->derivation to fix this “properly”

> IMO, this is way too complicated to keep in mind at all times, and there
> are bugs lurking under the surface absolutely everywhere, waiting for a
> corner case to be uncovered.

My comment still stands.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65225: [PATCH] environment: Build the profile for the requested system.

[Josselin Poiret via Bug reports for GNU Guix]

Hi Tobias,

Tobias Geerinckx-Rice  writes:

> Previously, ‘--system=’ did not affect profile hooks, meaning that all
> packages would be built for both the host and requested systems.
>
> * guix/scripts/environment.scm (guix-environment*): Parameterize
> %current-system to match the requested ‘--system=’.
>
> Reported by ekaitz in #guix.
> ---
>  guix/scripts/environment.scm | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
> index 9712389842..27f7e53549 100644
> --- a/guix/scripts/environment.scm
> +++ b/guix/scripts/environment.scm
> @@ -1146,7 +1146,8 @@ (define (guix-environment* opts)
>(warning (G_ "no packages specified; creating an empty 
> environment~%")))
>  
>  ;; Use the bootstrap Guile when requested.
> -(parameterize ((%graft? (assoc-ref opts 'graft?))
> +(parameterize ((%current-system system)
> +   (%graft? (assoc-ref opts 'graft?))
> (%guile-for-build
>  (and store-needed?
>   (package-derivation
>
> base-commit: 9e71d4fd6b3893ae87cb079b57d7a8fe6e9e7914
> -- 
> 2.41.0

So, I've looked into this deeper because this fix didn't seem satisfying
to me: it suggests that the implementation of profile-derivation itself
is wrong, and I wanted to fix it instead.  Here's what I uncovered:

%current-system (applies mutatis mutandis to %current-target-system)
is a Guile parameter.  That means that it is accessed through a function
call, and its values really depends on where that function call occurs.
Now, this interacts with the store monad in a cumbersome way: monadic
values in this case are functions (lambda (store) ...) returning two
values, the actual output and the store.  These functions are run only
at the run-with-store call.

Now, there are two non-equivalent ways of getting the current system in
a monadic context.  You can either do

(mlet ((system -> (%current-system))
  ...)

or

(mlet ((system (current-system))
  ...)

The former directly evaluates (%current-system), while the latter only
evaluates (%current-system) when the monadic value is run!

What does this mean for our case here?  Well, the problem lies with how
the hooks are lowered: they use (gexp->derivation ...) without the
optional #:system keyword.  This looks up the current system at call
time with the mlet -> construct, so everything should be okay, right?
Well, the hooks are run through a mapm/accumulate-builds call, which
puts everything in a monadic value, effectively delaying the look-up
until monadic run time.

--8<---cut here---start->8---
(mlet* %store-monad (...
 (extras (if (null? (manifest-entries manifest))
 (return '())
 (mapm/accumulate-builds (lambda (hook)
   (hook manifest))
 hooks
 ...)
--8<---cut here---end--->8---

At this point, I thought: “Well, I could just parameterize
%current-system inside the (lambda (hook) ...), and all would be well,
right?  Well, it didn't seem to work and I was pretty confused by it.  I
tested a bit and noticed that actually, contrary to what was intended
(there even is a comment in gexp-derivation about it), gexp-derivation
looks up the system at monadic run time!  It looks like this:

--8<---cut here---start->8---
(mlet* %store-monad ( ;; The following binding forces '%current-system' and
 ;; '%current-target-system' to be looked up at >>=
 ;; time.
 (graft?(set-grafting graft?))

 (system -> (or system (%current-system)))
 (target -> (if (eq? target 'current)
(%current-target-system)
target))
 ...)
  ...)
--8<---cut here---end--->8---

Well, the issue here is that such an mlet starts by translating the
graft? binding into a >>= call, which ends up putting the rest of the
translation into a function call that will *not* be called until the
monadic value is run.  That means that the system and target bindings
afterwards are *not* looked up at call time but at monadic run time!
And sure enough, moving the (graft? ...) binding after the (target ->
...) one does solve this!

IMO, this is way too complicated to keep in mind at all times, and there
are bugs lurking under the surface absolutely everywhere, waiting for a
corner case to be uncovered.

I'll send a new patch once I've fixed and tested this further.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature