Re: A certain new commiter

[Katherine Cox-Buday]

On 8/19/23 11:40 AM, Hilton Chain wrote:

Hello Guix,

With the commit [1] made hours ago, I have been granted commit access
to Guix repository.


Congratulations and welcome!

Re: Updates for Go

[Katherine Cox-Buday]

On 8/21/23 11:53 AM, Felix Lechner wrote:

Hi,

On Mon, Aug 21, 2023 at 9:11 AM Katherine Cox-Buday
 wrote:

the immediate emphasis should be on making bringing
our Go ecosystem onto a supported version of Go

 From my experience of packaging Gocryptfs in Debian and here, perhaps
some reconsideration should be given to the widely unpopular idea of
using more package functions in Guix. Ending in asterisks, they would
allow packagers, and perhaps even automated tools, to select exactly
the particular versions or commits specified for each prerequisite in
go.mod.
I have questions about this, but for now, I'm going to try and keep 
bringing the conversation back to just getting our ecosystem compiling 
on a supported version of Go.

Re: Updates for Go

[Katherine Cox-Buday]

Summary: these are good things to talk about. I think we should focus on 
using the current approach to get our Go ecosystem into a supported 
state before we talk about these things.


On 8/19/23 5:31 AM, Attila Lendvai wrote:

at one point i tried to compile some large projects written in golang in a 
reproducible way, and making sure that they use the exact same versions of all 
their dependencies.

in short: there's a philosophical mismatch between how guix and the golang crowd looks at 
building go apps. guix likes to explicitly represent every dependency in the guix 
namespace. golang has its own way of gathering the dependencies (and the nixos crowd 
don't mind "vendoring" the dependencies).


Yeah, there's a lot of unpack in this space for sure. To repeat what I 
think you're saying to ensure I understand it, the way I would 
characterize it is that there are two concerns:


1. The version of module dependencies a module is built with

2. How the toolchain resolves dependencies


(1) is not a new or unique problem to Go. Distros and software have 
always had mis-aligned views on what specific versions a package should 
use. Distros want to maintain fewer packages, and developers want to 
reference specific versions of dependencies. Guix is in a a better 
position in that it's theoretically possible to carry many different 
versions of the same package without conflicts. My understanding is that 
the limiting factor now are the resources that go into doing that (e.g. 
build-farms, cognitive overhead, etc.).


I don't think (2) is actually a problem. A lot of projects like to 
"vendor" their dependencies (i.e. check in the version of their 
dependency in the same repository as the host module), and there's valid 
reasons to do that. Fortunately, Go's vendoring is strongly tied to 
specific versions and the code is checksummed to ensure the vendored 
copy isn't modified. So it follows that all Guix has to do is ignore 
vendored dependencies and refer to the exact same version of the Guix 
package.


That is to say, at least the way I've framed it, I think (1) is the root 
of any issue that exists.



i've also worked on the golang importer (https://issues.guix.gnu.org/55242 
which needs a bit more care). once it works reliably enough, then it'd be 
possible to import the entire transitive closure of the dependencies into an 
isolated namespace in guix, which would be a halfway solution between the two 
conflicting philosophies.
Very nice! Our Go importer has improved so much, and further 
improvements such as these will make managing the Go ecosystem even easier.

for now i've abandoned that endeavour in favor of adding binary packages to my 
channel, but i made some notes on the way:

https://issues.guix.gnu.org/43872

a go-build-system patch
http://issues.guix.gnu.org/50227
discussion with iskarian
https://logs.guix.gnu.org/guix/2021-08-31.log#024401


I don't think this is an issue specifically with Go. As long as I've 
been involved in software, there has been an issue with N software 
depending on M versions of the same thing.



https://logs.guix.gnu.org/guix/2021-08-31.log#180940
iskarian: If you search for my name and "go" or "golang" in the 
mailing list archives, you should find a lot of discussion
https://savannah.gnu.org/users/lfam
Here's a more recent message from me: 
https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00227.html
Ah, I see I've unknowingly repeated you! 
https://lists.gnu.org/archive/html/guix-patches/2021-08/msg01222.html
Heh, it's gratifying that someone else came to the same conclusion. 
It means I wasn't totally in the weeds


The smallest divisible unit of a Go repository that is independently 
distributable is now a Go module. Modules are what are resolvable, 
versioned, and check-summed. As a rule that may have exceptions: Guix 
packages should neither encapsulate anything larger nor smaller than 
that. Some of the messages you're referencing are right around the time 
modules were being reified into the Go ecosystem.


I think there is an opportunity and need for Guix to try and reach a 
consensus on what our primitives and approaches are for the Go ecosystem 
and write them down in the manual. I think our current approach is 
workable, but there's obviously still some confusion and maybe debate to 
be had.


Having said all of that, I think we should focus on using our current 
approach to get everything compiling on a supported version of Go. I 
think our packages and substitutes are probably carrying CVEs that have 
been fixed upstream, and, in my opinion, we need to resolve that ASAP.


WDYT?

Re: Updates for Go

[Development of GNU Guix and the GNU System distribution.]

Hi,

On Mon, Aug 21, 2023 at 9:11 AM Katherine Cox-Buday
 wrote:
>
> the immediate emphasis should be on making bringing
> our Go ecosystem onto a supported version of Go

>From my experience of packaging Gocryptfs in Debian and here, perhaps
some reconsideration should be given to the widely unpopular idea of
using more package functions in Guix. Ending in asterisks, they would
allow packagers, and perhaps even automated tools, to select exactly
the particular versions or commits specified for each prerequisite in
go.mod.

Thank you for all your efforts in making Guix better for everyone!

Kind regards
Felix

Re: A certain new commiter

[John Kehayias]

On Sun, Aug 20, 2023 at 01:40 AM, Hilton Chain wrote:

> Hello Guix,
>
> With the commit [1] made hours ago, I have been granted commit access
> to Guix repository.
>
> Currently, I'm maintaining packages I may use and those I've touched,
> and for now I have no specific plan to move on.  This means I can have
> more time to go through the review process, and I'm glad to do so.
>
> I'm also hako on libera.chat, please contact me if there's anything I
> can help with.
>
> Thanks,
> Hilton Chain
>

Congratulations and welcome!

> ---
> This mail is signed by the key with the following fingerprint, I'll
> use it for commit signing:
> F4C2 D1DF 3FDE EA63 D1D3  0776 ACC6 6D09 CA52 8292
>
> The signing key is a subkey of
> 220F 98D9 5E86 204C 0036  DA7B 6DEC 4360 408B 4185
>
> , which is attached.  And it can be found in [2] as well.
>
> [1]:
> 
>
> [2]:
> 
> 
>

Re: 177/332: gnu: Add qtvirtualkeyboard-5.

[Maxim Cournoyer]

Hi,

guix-comm...@gnu.org writes:

> iyzsong pushed a commit to branch kde-updates
> in repository guix.
>
> commit f370b61078dd0863631433f43d229196d5dc86a7
> Author: Zheng Junjie <873216...@qq.com>
> AuthorDate: Fri Jul 21 19:54:46 2023 +0800
>
> gnu: Add qtvirtualkeyboard-5.
> 
> * gnu/packages/qt.scm (qtvirtualkeyboard-5): New variable.

[...]

> +(define-public qtvirtualkeyboard-5
> +  (package
> +(inherit qtsvg-5)
> +(name "qtvirtualkeyboard")
> +(version %qt-version)
> +(source (origin
> +  (method url-fetch)
> +  (uri (qt-urls name version))
> +  (sha256
> +   (base32
> +"1skdjh9q4m438wwl8hwx3jc5hg22dmi5pwm3vd2yksxw6ny67rd7"
> +(arguments
> + (substitute-keyword-arguments (package-arguments qtsvg-5)
> +   ((#:tests? _ #f) #f) ; TODO: pass 2 fail test
> +   ((#:phases phases)
> +`(modify-phases ,phases
> +   (add-before 'check 'set-display
> + (lambda _
> +   ;; Make Qt render "offscreen", required for tests.
> +   (setenv "QT_QPA_PLATFORM" "offscreen")
> +   (setenv "DISPLAY" ":1")
> +   (system "Xvfb +extension GLX :1 &")))
> +   (delete 'check)   ;move after the install phase
> +   (add-after 'install 'check
> + (assoc-ref %standard-phases 'check))
> +   (add-before 'check 'prepare-for-tests
> + (lambda* (#:key outputs #:allow-other-keys)
> +   (setenv "QML2_IMPORT_PATH"
> +   (string-append (assoc-ref outputs "out")
> +  "/lib/qt5/qml:"
> +  (getenv "QML2_IMPORT_PATH")))
> +   (setenv "QT_PLUGIN_PATH"
> +   (string-append (assoc-ref outputs "out")
> +  "/lib/qt6/plugins:"
> +  (getenv "QT_PLUGIN_PATH")

The above caught my eye; is the 'qt6' here a typo?  I presume so, since
the package is a Qt 5 one.  Probably the second setenv can be dropped
without any effect.

-- 
Thanks,
Maxim

Re: Updates for Go

[Katherine Cox-Buday]

On 8/17/23 3:54 PM, Wilko Meyer wrote:

That being said, I'd actually be willing to put some time and effort
into Guixes Go ecosystem; even though I haven't been on Guix for that
long and would probably have to read through prior contributions to
golang.scm to get the gist on how the go-build-system and packaging all
things go work and to contribute something useful.

Is there a list of current TODOs somewhere? Or would one start by
bumping packages to build with a more recent/non-EoL go version and see
if that works out?


Thank you for volunteering!

I'm not aware of a TODO list anywhere other than the issue tracker 
(https://issues.guix.gnu.org/search?query=golang+is%3Aopen).


Personally, I think the immediate emphasis should be on making bringing 
our Go ecosystem onto a supported version of Go (ideally 1.21.0). If 
there is consensus on that, then ensuring that some of our packages with 
larger dependency graphs compile would be a good place to start.


We also really need a Go branch to host a lot of this work. I can start 
looking at what's needed for that.


It would also be useful to get https://issues.guix.gnu.org/65317 (add 
go-1.21) reviewed, even if you don't have commit access. I've been 
exercising the package since I sent the patch, and I think v3 is correct 
(at least functionally), but it could use more exercising and a review 
of the scheme code.


--

Katherine