[GSoC 2020] [Proposal draft #1] Clojars importer for Guix

[Leandro Doctors]

Dear all,

Below, I share my second draft.

1. Overview: still needs to be completed with material from the
unfinished sections.

2. Problem Statement: fully developed, only need to add some data (you
will note [the placeholders])

3. Solution Overview: this is definitely the less developed section. I
still need to add much more details (which options I see, which one I
will implement, why...)

Even though I have a stub for the remaining sections (mainly, the
implementation stages and planning), their content will be defined
once I have stabilized the content for these sections.
Again, you will notice a few placeholders for data [note: marked with
notes like this one :-)].

Looking forward for your feedback!

Best,
Leandro


***


Clojars importer for Guix

Leandro Doctors


1 Overview

Guix supports importing packages from multiple, diverse sources.
All this offering of software platforms enables Guix as a
competitive option to a wide variety of users.

Whereas the array of supported Guix sources is indeed vast and
diverse, there is a major source yet to be supported: JVM
packages. JVM comprise a major source of software: as of March
2020, there are more than LLL[note:
TODO: add number (with source).
] languages that run on the JVM, with more than PPP[note:
TODO: add number (with source).
] packages.

The main de facto repository for JVM packages is “The Central
Repository” (formerly known as “Maven Central”). However, as TCR
does not support license metadata and explicit repository
linking, supporting it does not seem to be an ethical choice for
Guix.

Fortunately, Clojars, the de facto repository for Clojure
packages, supports the features Guix requires. Considering that
Clojure (a libre, modern LISP dialect) is among the most popular
JVM languages, Clojars would be a very valuable addition to the
list of Guix importers. Finally, as Guix is also written in a
LISP dialect, this would have the additional benefit of bringing
together a kindred functional programming community.

[note: TODO: add list of deliverables]


2 Problem Statement

Guix supports importing packages from multiple, diverse sources.
They range from metadata from the GNU System, repositories such
as the Python Package Index and the Comprehensive R Archive
Network, down to plain JSON metadata files. Supporting a broad
offering of package sources does not only provide Guix with a
broad catalog of packages, it also enriches it with a plethora of
languages to choose from. All this offering of software platforms
enables Guix as a competitive option to a wide variety of users.

Whereas the array of supported Guix sources is indeed vast and
diverse, there is a major source yet to be supported: JVM
packages[footnote: Guix does include many Java packages, but none of
them support
their dependencies]. The Java Virtual Machine is one of the most
popular platforms
for software development, comprising around DDD[note:
TODO: add number (with source).] of estimated developers worldwide.
Whereas initially intended
for a single language (Java), the JVM has been used as a platform
to develop new languages. The only requirement that any language
hosted on the JVM platform has to comply with is to generating
bytecode artifacts compliant with the JVM specifications. In this
way, as of March 2020, there are more than LLL[note:
TODO: add number (with source).] languages that run on the JVM.

JVM packages are distributed via .jar files -compressed files
containing bytecode files. The main de facto repository for JVM
packages is “The Central Repository” (formerly known as “Maven
Central”)[footnote: The Central Repository Search Engine:
https://search.maven.org/]. TCR mainains a network of over PPP[note:
TODO: add number (with source).]
JVM packages, mainly written in Java. Every package from TCR
also specifies on which other packages it depends on. As with any
client-server architecture, TCR takes care of maintaining the
dependency graph and any tool that wants to fetch packages from
TCR takes care of defining the best way of traversing it,
according to its user's commands. There are many tools used to
access TCR and manage package dependencies according to different
heuristics. Depending on the programming language used, the most
popular include Ant, Maven, Gradle, Ivy...

However, supporting TCR does not seem to be an ethical choice for
Guix. To begin with, TCR does not encourage package maintainers
to publish their packages under a free software license (nor to
even publish their sources). Moreover, even though a considerable
number of TCR-hosted packages do use a free software license, TCR
fails to provide any explicit licensing metadata, nor an explicit
link to their repository. These two points force the user to use
a third-party search engine with respect to both license
compliance and package auditing. Therefore, whereas it is
definitely possible reconciling Guix freedom-respecting values
with using TCR-hosted packages, 

Re: Brainstorming features for issues.guix.gnu.org

[John Soo]

Hi Ricardo!

I love the idea of a smoother download/review process. I think I would
be happier with a curl-able endpoint to download patches from. I think
it might compose with other tools a little more smoothly. Other than
that, nothing really comes to my mind.

I only just started using it more frequently since it stopped timing out
so frequently.

Kindly,

John

Re: Use genimage for disk-image creation.

[Danny Milosavljevic]

Hi Mathieu,

from the standpoint of ARM it would be really good to be able to reuse
genimage config files from buildroot.

In fact, partition layout is a major pain in the ass to get right on ARM.
If we want to support a large number of ARM platforms, that would
mean the partitioning would be fixed and not user-modifyable anyway.

> Danny, Ludo, WDYT? Could we modify "system-disk-image" to use genimage
> as a backend instead of spawning a VM?

It depends on whether genimage supports all filesystems we care about.
I suspect that it does, though.

Genimage images tend to be reproducible btw, so it's kinda nice.


pgpDsfBtMiJGj.pgp
Description: OpenPGP digital signature

Re: Linphone

[Raghav Gururajan]

So I was able to fix all the "Qt[...].cmake not found error by adding required 
inputs. But during build I get lot of errors related to Qt. I am not able to 
understand what those are.

BUILD LOG: 
https://bin.disroot.org/?79c1cc2131f7235f#HHS3xWeLCKd98L1fqZB6xEwnkPQWqyJXpoemhwppzRNV

NEW DIFF: 
https://bin.disroot.org/?5c92968202a11fe5#5TrosGgDg5i5ZPve4VXr452wTrNHXaiHo146uc7gzZXP

Re: Brainstorming features for issues.guix.gnu.org

[Christopher Baines]

Ricardo Wurmus  writes:

> I want issues.guix.gnu.org to become more useful for all of us.  It’s
> easy to get lost in a deluge of bug reports and patch submissions, so
> our tools should allow us to stay afloat.
>
> Do you use issues.guix.gnu.org?  If you aren’t: what workflow do you
> have to review patch submissions?

Normally when I look at reviewing patches, I end up finding something
else to try and automate or make easier.

My current workflow is, look for patches to review through email, or
Patchwork [1], look the patches over, follow the link to the Guix Data
Service instance, and maybe try building some of the derivations [2]. If
I want to manipulate the patches locally, I checkout the branch or
cherry-pick the relevant commits [3].

1: https://patchwork.cbaines.net/project/guix-patches/list/
2: I use the substitutes from the Guix Data Service instance for the
derivation, so I can build it locally without having to apply the
patches.
3: https://git.cbaines.net/guix/patches

> If you do use it: what features do you think are missing?

Being able to go to domain/patch-number would be useful ([4] for
example). Debbugs does a redirect, so I usually end up typing that out
instead.

4: http://issues.guix.info/39258

> Personally, I’d wish for a more streamlined workflow to download and
> apply patch sets.  I don’t want to click on each “download” link in the
> web interface.  Instead I would like to run something like
>
> ./etc/review 12345
>
> which would fetch the patches in issue 12345 and apply them to my
> git worktree.

I use the combination of Patchwork plus some scripts run through Laminar
to populate a Git repository with commits for the patches for this. I've
got the git repository as a remote, which makes applying the patches
reasonably easy.

> I would also like to see neglected issues in the web interface, i.e. a
> list of open issues that haven’t seen any response in a while and that
> haven’t been tagged as awaiting more information from the submitter.
> This should make it easier for us to prevent patches from slipping into
> obscurity, which is a terrible thing to happen especially for new
> contributors.

Those are definitely features I'd like to see. They would be very useful
to help people prioritise.

While most of the discussion here has been about patches, I can think of
a few useful things in terms of issues that don't directly relate to
patches (or at least not yet).

For bug reports, it could be useful to be able to associate them with
packages that the bug is for. This could allow you to filter for bugs
related to a package. It could also be useful to be able to mark which
commit introduced an issue, and when it was resolved.

Thanks for your work on issues.guix.info!

Chris


signature.asc
Description: PGP signature

Re: Experiment in generating multi-layer Docker images with guix pack

[Christopher Baines]

Ludovic Courtès  writes:

> Christopher Baines  skribis:
>
>> I think it could be useful to support multiple different strategies for
>> generating layers for Docker images, with different trade-offs. This approach
>> using two layers should make the resulting images more efficient to use in 
>> the
>> case where like the guile example above, where the packages you run guix pack
>> with have exactly matching inputs.
>
> Did you read ?
> They came up with a pretty smart algorithm that would be worth copying.

I'm aware of it, but I haven't read it in detail yet.

>> As well as these behaviour changes, these patches also modify the
>> implementation. Rather than having some build side code that's used in the
>> pack and vm module gexpressions, these patches introduce two new record 
>> types:
>>  and . This at least structures the
>> derivations so that each layer is represented by a derivation, and then
>> there's a derivation for the image itself, which is a little more efficient 
>> in
>> terms of computation.
>
> Nice.
>
> I think a layering algorithm like Graham Christensen’s above requires
> knowledge of the reference graph, meaning that layering can only be
> computed on the build side, using #:references-graphs.  In that case, it
> could be that you can’t have a host-side  record.

As I understand it, you only have to do the computation on the build
side if you're restricted to doing a single set of builds. If you first
build the store items you want to put in the image, then look at there
references and compute the derivation for building the image, then you
could do this kind of computation on the client side.

But yeah, this is important to work out, as how image generation should
work, and what behaviours we want should define the structure of the
code.

I went with records to represent layers partially because I'm familiar
with it, but also because it allows for easier manipulation of layers on
the client side. Representing different layers as different derivations
also allows them to potentially be built in parallel, although I'm not
sure how beneficial this might be.

Related to this, at the moment Docker V1 images can be generated, it
would be good in the future to also support Docker V2 images and OCI
images. All three container formats use a layered approach to managing
the files, but they are all different (as far as I'm aware).

In my mind there are three architectural approaches:

 - Image generation entirely on the build side

   - The layers and the image are constructed through one derivation
   - The code for building images is in a module available at build time
   - Different approaches for layering are implemented in the module
 available at build time, and parameters are passed in as
 data/gexpressions

 - Image generation entirely on the client side

   - Each layer is a derivation, and the image is an additional
 derivation that takes the layers as an input
   - The code for building images is inside gexp compilers for the
 record types representing the images and layers
   - Different approaches for layering manipulate the layer records on
 the client side

 - Image generation can be done both build and client side

   - Depending on the parameters, the layers and image can be a single
 derivation, or one for each layer, and another for the image
   - The code for building images is in a module available at build
 time, and this is also used by gexp compilers
   - Different approaches for layering have the option of either being
 on the build side, or the client side

What are peoples thoughts?

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Linphone

[Raghav Gururajan]

Hi Danny!

> I don't know. It sounds like the versions of the linphone modules are not 
> compatible.
> Please ask upstream about it (for example file a bug report with them).

It appears half of the errors were related to C++ standard. When I used ("gcc" 
,gcc-5) as native-inputs, the number of errors, reduced to half.

Re: Linphone

[Danny Milosavljevic]

Hi Raghav,

> So I was able to fix all the "Qt[...].cmake not found error by adding 
> required inputs. But during build I get lot of errors related to Qt. I am not 
> able to understand what those are. They all contain some king of flags.

I don't know.  It sounds like the versions of the linphone modules are not 
compatible. 
Please ask upstream about it (for example file a bug report with them).


pgpVGWfBYDWUl.pgp
Description: OpenPGP digital signature

Re: automake-1.16.2

[Leo Famulari]

On Thu, Mar 26, 2020 at 08:06:44PM +0100, Marius Bakke wrote:
> Vincent Legoll  writes:
> > For the tests they will be native-inputs, so only increase dependencies
> > for building, is that a problem ? I would have thought that test coverage
> > is more important (especially on such important packages), I'm probably
> > missing something...
> 
> For such heavy-impact packages, an important consideration is that any
> dependency we add gets the same impact.

Additionally, test suites can be less important for core packages like
automake, because the real test is building the distro.

Re: automake-1.16.2

[Marius Bakke]

Vincent Legoll  writes:

>> We’d probably have to decide on a case by case basis which additional
>> dependencies we’d like to add, given that Automake has a lot of
>> dependents.
>
> For the tests they will be native-inputs, so only increase dependencies
> for building, is that a problem ? I would have thought that test coverage
> is more important (especially on such important packages), I'm probably
> missing something...

For such heavy-impact packages, an important consideration is that any
dependency we add gets the same impact.

Hypothetically, let's say Automake has an optional dependency on
'git' for some tests.  Providing git as a native-input means that we can
no longer update git outside of the "core-updates" cycle, because that
would cause too many rebuilds.

Of course there are ways to work around such cycles, but it complicates
the dependency graphs.


signature.asc
Description: PGP signature

Re: Linphone

[Raghav Gururajan]

So I was able to fix all the "Qt[...].cmake not found error by adding required 
inputs. But during build I get lot of errors related to Qt. I am not able to 
understand what those are. They all contain some king of flags.

Here is a new of my project. 
https://bin.disroot.org/?5c92968202a11fe5#5TrosGgDg5i5ZPve4VXr452wTrNHXaiHo146uc7gzZXP

Regards,
RG.

Re: kmscon not working on MacBook

[pelzflorian (Florian Pelz)]

On Thu, Mar 26, 2020 at 03:26:05AM +0100, Bengt Richter wrote:
> On +2020-03-26 00:00:18 +0100, pelzflorian (Florian Pelz) wrote:
> > on one of my computers uvesafb can only be used after „chmmod o+rw
> > /dev/fb0“ which is a security issue, I suppose.
> >
> 
> Are you a member of the video group?

Indeed the issue was that the gdm user was not a member of the video
group.  Thank you!

I have verified the attached patch makes it sufficient to run
`modprobe uvesafb v86d=$(guix build v86d | head -n1)/sbin/v86d
mode_option=1280x800-32` before `herd restart xorg-server` without any
additional chmod.  I will push if nobody objects.

I do however need to remove xf86-video-vesa via
set-xorg-configuration.  Perhaps xf86-video-vesa should not be among
the defaults if uvesafb is to be made a default.  Note that when not
running X as root, xf86-video-vesa does not work anyway.  That’s what
uvesafb is for.

If uvesafb should be made a default, v86d:testvbe could be used to
find a suitable resolution as a mode_option parameter.

However I still do not know how best to modprobe uvesafb
automatically.

Regards,
Florian
>From 419ec6f3866d223b88f195466d3e731090240a2a Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Thu, 26 Mar 2020 15:19:21 +0100
Subject: [PATCH] services: gdm: Add gdm user to 'video' supplementary group.

See .

* gnu/services/xorg.scm (%gdm-accounts): Set supplementary groups.
---
 gnu/services/xorg.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 09379d40c3..d0196a299e 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -798,6 +798,7 @@ the GNOME desktop environment.")
 (user-account
  (name "gdm")
  (group "gdm")
+ (supplementary-groups '("video"))
  (system? #t)
  (comment "GNOME Display Manager user")
  (home-directory "/var/lib/gdm")
-- 
2.25.1

Re: automake-1.16.2

[Vincent Legoll]

On Thu, Mar 26, 2020 at 3:07 PM Ludovic Courtès  wrote:
> > Trying to update automake to the latest, I'm seeing lots
> > of skipped tests because of missing native-inputs, would
> > it be OK toadd those to enable more tests to be run ?
>
> I hadn’t seen your message and added Automake 1.16.2 in commit
> 72a5cc53586080e75ae4ee80f3a2467ff30c4f5e.

No problem, I've seen you added that.

> We’d probably have to decide on a case by case basis which additional
> dependencies we’d like to add, given that Automake has a lot of
> dependents.

For the tests they will be native-inputs, so only increase dependencies
for building, is that a problem ? I would have thought that test coverage
is more important (especially on such important packages), I'm probably
missing something...

--
Vincent Legoll

Re: Issues and improvement for `kernel-loadable-modules'

[Brice Waegeneire]

Hello Danny,

Sorry for the empty email; cancel and send buttons were too close for
me...

On 2020-03-26 15:13, Danny Milosavljevic wrote:

Hi Brice,

On Thu, 26 Mar 2020 14:34:03 +
Brice Waegeneire  wrote:


First I was expecting the packages in `kernel-loadable-modules' to use
the
`kernel' field as their kernel input or to have a simple procedure to 
do
so. Otherwise you get a “Specified Linux kernel and Linux kernel 
modules

are not all of the same version”. It makes it more difficult that it
needs
to be to write composable configurations; IOW why would I want to use 
a

module built with a different kernel that the one I'm specifying in my
`operating-system'.


Because packages are modular, changing the build system can only be 
done
retroactively by a procedure.  We could totally do that but it would 
make
the kernel-loadable-modules field more magical and more difficult to 
debug.

Also, I guess it would hard-code linux-module-build-system for those
(right now you can use whatever build system you want).  Do we want it 
anyway?


Magic isn't the way to go, for sure. I tried writting a procedure to 
abstract
it, but I wasn't successful: see my second issue with inferiors, the 
fact that
it only handle `linux-build-system' and that I need to use a direct 
reference to

a package. On that last point I would like to use something like
“(operating-system-kernel this-operating-system)” to reference the 
kernel
but my guile foo isn't good enough: “this-operating-system” has to be in 
scope

 of “operating-system”. Following is the procedure I'm talking about:

--8<---cut here---start->8---
  (kernel-loadable-modules
   (map (lambda (module)
  (package/inherit module
   (arguments
(ensure-keyword-arguments
 (package-arguments module)
 `(#:linux ,my-linux)
 
--8<---cut here---end--->8---



And last issue, we are missing a service to load module manually when
they
can't be auto-loaded as it's the case with `ddcci`[1]. I have managed 
to

solve this one by writing my first service
`load-kernel-modules-service'.
What can I improve before submitting it as a patch -- except the 
missing

documentation?


I think that things should be described by nouns and actions should be
described by verbs.

So "load-kernel-modules-service" sounds really wrong to me.
Maybe "kernel-module-loader-service"?

Others don't care so much because Scheme kinda erodes the boundary 
anyway.


That's definitely a better name.


Otherwise looks good to me.

I guess it could be nice to be able to extend this service from other 
services

using (service-extension load-kernel-modules-service-type '("module1"
"module2")) or something.


I think it's already the case, there are `compose' and `extend' fields 
in the

`service-type' and I tried it with
“(simple-service 'ddcci-module kernel-module-loader-service-type 
'("ddcci"))”.


Brice.

Re: Issues and improvement for `kernel-loadable-modules'

[Brice Waegeneire]

On 2020-03-26 15:13, Danny Milosavljevic wrote:

Hi Brice,

On Thu, 26 Mar 2020 14:34:03 +
Brice Waegeneire  wrote:


First I was expecting the packages in `kernel-loadable-modules' to use
the
`kernel' field as their kernel input or to have a simple procedure to 
do
so. Otherwise you get a “Specified Linux kernel and Linux kernel 
modules

are not all of the same version”. It makes it more difficult that it
needs
to be to write composable configurations; IOW why would I want to use 
a

module built with a different kernel that the one I'm specifying in my
`operating-system'.


Because packages are modular, changing the build system can only be 
done
retroactively by a procedure.  We could totally do that but it would 
make
the kernel-loadable-modules field more magical and more difficult to 
debug.

Also, I guess it would hard-code linux-module-build-system for those
(right now you can use whatever build system you want).  Do we want it 
anyway?



And last issue, we are missing a service to load module manually when
they
can't be auto-loaded as it's the case with `ddcci`[1]. I have managed 
to

solve this one by writing my first service
`load-kernel-modules-service'.
What can I improve before submitting it as a patch -- except the 
missing

documentation?


I think that things should be described by nouns and actions should be
described by verbs.

So "load-kernel-modules-service" sounds really wrong to me.
Maybe "kernel-module-loader-service"?

Others don't care so much because Scheme kinda erodes the boundary 
anyway.


Otherwise looks good to me.

I guess it could be nice to be able to extend this service from other 
services

using (service-extension load-kernel-modules-service-type '("module1"
"module2")) or something.

Re: Issues and improvement for `kernel-loadable-modules'

[Danny Milosavljevic]

Hi Brice,

On Thu, 26 Mar 2020 14:34:03 +
Brice Waegeneire  wrote:

> First I was expecting the packages in `kernel-loadable-modules' to use 
> the
> `kernel' field as their kernel input or to have a simple procedure to do
> so. Otherwise you get a “Specified Linux kernel and Linux kernel modules
> are not all of the same version”. It makes it more difficult that it 
> needs
> to be to write composable configurations; IOW why would I want to use a
> module built with a different kernel that the one I'm specifying in my
> `operating-system'.

Because packages are modular, changing the build system can only be done
retroactively by a procedure.  We could totally do that but it would make
the kernel-loadable-modules field more magical and more difficult to debug.
Also, I guess it would hard-code linux-module-build-system for those
(right now you can use whatever build system you want).  Do we want it anyway?

> And last issue, we are missing a service to load module manually when 
> they
> can't be auto-loaded as it's the case with `ddcci`[1]. I have managed to
> solve this one by writing my first service 
> `load-kernel-modules-service'.
> What can I improve before submitting it as a patch -- except the missing
> documentation?

I think that things should be described by nouns and actions should be
described by verbs.

So "load-kernel-modules-service" sounds really wrong to me.
Maybe "kernel-module-loader-service"?

Others don't care so much because Scheme kinda erodes the boundary anyway.

Otherwise looks good to me.

I guess it could be nice to be able to extend this service from other services
using (service-extension load-kernel-modules-service-type '("module1"
"module2")) or something.


pgpxtqBcV3Mun.pgp
Description: OpenPGP digital signature

Enhancing `modify-services' to support name in addition to type

[Brice Waegeneire]

Hello,

I was thinking of improving `modify-services' by adding the ability to
specify a service to modify based on it's name and not just it's type. 
This

would allow us to modify singleton services like the ones returned by
`simple-service'. I'm not sure if that's a good idea, that's why I 
prefer
to ask before starting to write a patch. Following is an example of how 
it

would like when modifying `set-xorg-configuration':

--8<---cut here---start->8---
(define t430-xorg-extra-config "
Section \"InputClass\"
  Identifier \"touchpad\"
  Driver \"synaptics\"
  Option \"HorizTwoFingerScroll\" \"on\"
EndSection")

(define t430-services
  (modify-services workstation-services
('set-xorg-configuration
 config => (xorg-configuration
(inherit config)
(extra-config (list t430-xorg-extra-config))
--8<---cut here---end--->8---

Brice.

Re: Use genimage for disk-image creation.

[Vincent Legoll]

> I’m completely sold to the idea.  :-)

Yep, LGTM too

> Apparently ‘genimage’ supports many file systems, including ext[234] and
> ISO9660, which are the two formats we support via ‘--file-system-type’.
> It does not support Btrfs, but ‘guix system disk-image’ doesn’t support
> it either so far.
>
> Likewise, for ISO, it just shells out to ‘genisoimage’.

You probably meant "mkisoimage" ?

> So I think that we could avoid ‘genimage’ altogether and implement
> similar functionality for ext4/ISO in (gnu build disk-image).

Do you anticipate less or similar work in reimplementing rather than
reusing ? Genuinely asking, because we may want to support other
image formats in the future, so reusing may have its interest too...

Or is there another reason that I'm not seing, like maybe avoiding some
overhead (probably not the fork/execs going through genisoimage though)...

-- 
Vincent Legoll

Re: Hi, I was able to do basic build and install of XChat IRC Client

[R Veera Kumar]

On Wed, Mar 25, 2020 at 10:09:27PM -0500, LaFreniere, Joseph wrote:
> 
> Veera  writes:
> 
> > I have successfully done a basic build and install of XChat IRC Client.
> 
> From what I can tell [0], the latest commit to XChat was in 2011. Is this
> the software you packaged, or did you perhaps intend to refer to HexChat
> [1], a maintained fork?
> 
> > I had chat about this in #Guix IRC. brendyyn, drakonis, lfam.
> > 
> > They objected with XChat inclusion in Guix.
> > …
> > Please can you tell me what to do?
> 
> Did the participants in #Guix who objected to including XChat in Guix
> provide any reasons for their objections?  Understanding what specifically
> they disliked about your recipe or the upstream software might provide some
> guidance for next steps.
> 

Please see the patch I posted to guix-patc...@gnu.org for
XChat bug no: 40208 which Gabor Boskovits told me to do.
So that it gets WONTFIX status.

They objected for it being old and unmaintained and has bugs in them.
The hexchat developer objected for it's inclusion in Debian and wanted
it to be removed. He said found new bugs in hexchat or irc in general
which were probably not fixed in this unmaintained software. Though he
did not listed them in xchat. While the current Debian maintainer is
affirmative of still including it saying the bugs which gets found are
fixed and no need to remove it from Debian. Sorry I do not have the
links for those pages as I was using built xchat and it's log got lost.
drakonis gave the links. Hexchat developer in reddit post. Perhaps
XChat and HexChat: When distributions get it wrong.
Debian Bug Reports: 891982 and 892085

R Veera Kumar
[Outreachy Contrib]

> [0] http://xchat.org/files/?C=M;O=D
> [1] https://hexchat.github.io/
> 
> --
> Joseph LaFreniere
> 

Issues and improvement for `kernel-loadable-modules'

[Brice Waegeneire]

Hello Guix,

Thanks to Danny's work in[0] we have, since a few days, a way for 
packages

to provide Linux modules in the system profile. I have been waiting for
such a feature since I packaged `ddcci-driver-linux', which was kind of
useless without it. Using the new field `kernel-loadable-modules' I
stumbled upon three issues.

First I was expecting the packages in `kernel-loadable-modules' to use 
the

`kernel' field as their kernel input or to have a simple procedure to do
so. Otherwise you get a “Specified Linux kernel and Linux kernel modules
are not all of the same version”. It makes it more difficult that it 
needs

to be to write composable configurations; IOW why would I want to use a
module built with a different kernel that the one I'm specifying in my
`operating-system'.

Second issue, I can't manage to use an inferior as the kernel input for 
the

packages in `kernel-loadable-modules'. See the two following
snippets:

--8<---cut here---start->8---
LANGUAGE=C guix system vm kernel-loadable-modules-barbones.scm
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...

Backtrace:
   1 (primitive-load "/home/bricewge/.config/guix/current/bi…")
In guix/ui.scm:
  1894:12  0 (run-guix-command _ . _)

guix/ui.scm:1894:12: In procedure run-guix-command:
In procedure %package-native-inputs-real: Wrong type argument: 
#

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

Following is `kernel-loadable-modules-barbones.scm':

--8<---cut here---start->8---
(use-modules (gnu)
 (gnu system)
 (srfi srfi-1)
 (guix inferior)
 (guix utils)
 (guix packages)
 (guix channels))
(use-package-modules linux)

(define channels
  (list (channel
 (name 'guix)
 (url "https://git.savannah.gnu.org/git/guix.git;)
 (commit
  "591faabd8c93bfb6879910d8a424f0db835066c2"

(define my-linux
  (let ((inferior (inferior-for-channels channels)))
(first (lookup-inferior-packages inferior "linux-libre" 
"4.4.217"


;; ;; NOTE It is already in master
;; (define operating-system-kernel-loadable-modules
;; (@@ (gnu system) operating-system-kernel-loadable-modules))

(define os
  (operating-system
(host-name "komputilo")
(timezone "Europe/Berlin")
(locale "en_US.utf8")
(bootloader (bootloader-configuration
 (bootloader grub-bootloader)
 (target "/dev/sdX")))
(file-systems (cons (file-system
  (device (file-system-label "my-root"))
  (mount-point "/")
  (type "ext4"))
%base-file-systems))

(kernel-loadable-modules (list ddcci-driver-linux

(operating-system
  (inherit os)

  (kernel my-linux)
  (kernel-loadable-modules
   (map (lambda (module)
  (package/inherit module
   (arguments
(ensure-keyword-arguments
 (package-arguments module)
 ;; `(#:linux ,(specification->package 
"linux@4.4.217")) ; NOTE It should works

 `(#:linux ,my-linux) ; NOTE That's issue #2
 
(operating-system-kernel-loadable-modules os
--8<---cut here---end--->8---

And last issue, we are missing a service to load module manually when 
they

can't be auto-loaded as it's the case with `ddcci`[1]. I have managed to
solve this one by writing my first service 
`load-kernel-modules-service'.

What can I improve before submitting it as a patch -- except the missing
documentation?

--8<---cut here---start->8---
(define-record-type* 
load-kernel-modules-configuration make-load-kernel-modules-configuration
load-kernel-modules-configuration? (modules
load-kernel-modules-configuration-modules ; list of strings (default 
'(


(define load-kernel-modules-shepherd-service
  (match-lambda
(($  modules)
 (list
  (shepherd-service
   (documentation "Load kernel modules.")
   (provision '(load-kernel-modules))
   (respawn? #f)
   (one-shot? #t)
   (start
#~(lambda _
(zero? (system* #$(file-append kmod "/bin/modprobe")
#$@modules)

(define load-kernel-modules-service-type
  (service-type
   (name 'load-kernel-modules)
   (description "Load kernel modules.")
   (extensions
(list
 (service-extension shepherd-root-service-type
load-kernel-modules-shepherd-service)))
   (compose concatenate)
   (extend (lambda (config modules)
 (load-kernel-modules-configuration
  (inherit config)
  (modules (append
(load-kernel-modules-configuration-modules 
config)

 

Re: Plan for a release!

[Ludovic Courtès]

Vincent Legoll  skribis:

> On Thu, Mar 26, 2020 at 12:55 PM Ludovic Courtès  wrote:
>> Another approach would be to do like ‘guix system vm’, which is to share
>> the store with the host.  But then we would need a way to be able to run
>> a daemon in the guest and have its build results overlaid on top of the
>> host-provided store.
>
> Couldn't `guix copy` be used here to get built items back onto the host
> easily ?

No, ‘guix copy’ is only for copies over SSH between full-features stores
(each one running a daemon).

Ludo’.

Re: Linphone

[Raghav Gururajan]

Hi Danny!

> I tried
> 
> (arguments
> `(#:configure-flags
> (list "-DENABLE_DBUS=YES"
> "-DENABLE_UPDATE_CHECK=YES")
> #:phases
> (modify-phases %standard-phases
> (add-after 'unpack 'patch
> (lambda _
> (substitute* "CMakeLists.txt"
> (("find_package[(]BcToolbox REQUIRED[)]")
> "find_package(bctoolbox REQUIRED)")
> (("find_package[(]Belcard REQUIRED[)]")
> "find_package(belcard REQUIRED)"))
> #t)
> 
> in linphone-desktop's package description and the error message changed.

Thanks so much. It did change the error :-).

Btw, when I was researching code base, I came across this technique. Will it be 
relevant?

  ("BCTOOLBOX_INCLUDE_DIRS=-lbctoolbox"
  ,(string-append "BCTOOLBOX_CFLAGS=-I"
  (assoc-ref %build-inputs "bctoolbox")
  "/include"))

Re: Cannot build guix from git due to .po file errors

[Ludovic Courtès]

Hi Vagrant,

Vagrant Cascadian  skribis:

> e...@boldquot.po:4591: format specifications in 'msgstr[0]' are not a
> subset of those in 'msgid_plural'
> /gnu/store/p50cw1g05g566bkbr6ylcibqffhha8w4-profile/bin/msgfmt: found 1
> fatal error

What’s the message on that line?

I haven’t hit the problem yet, probably simply because I haven’t tried
rebuilding the PO files.

Thanks,
Ludo’.

Re: Use genimage for disk-image creation.

[Ludovic Courtès]

Hi Mathieu!

Mathieu Othacehe  skribis:

> Let say I want to create a disk-image with one ext4 partition starting
> at offset 10M. I can write the following genimage config file:
>
> image system {
>   hdimage {}
>
>   partition rootfs {
>   partition-type = 0x83
>   image = "rootfs.ext4"
>   size = 8G
>   offset = 10M
>   }
> }
>
> image rootfs.ext4 {
> name = "rootfs"
> ext4 {
> label = "rootfs"
>   use-mke2fs = true
> }
> size = 8G
> mountpoint = "/"
> }
>
>
> and run the command:
>
> fakeroot genimage --config ~/tmp/genimage.cfg 
> --rootpath=/home/mathieu/image-root/
>
> where image-root is a directory containing the result of a `guix system
> init`. The directory size is about 6GiB.
>
> It takes 8 minutes to generate this disk-image, versus 2h30 using `guix
> system disk-image`.
>
> I'm aware that this might not be a fair comparison but, I think its
> already significant.
>
> Danny, Ludo, WDYT? Could we modify "system-disk-image" to use genimage
> as a backend instead of spawning a VM?

I’m completely sold to the idea.  :-)

Apparently ‘genimage’ supports many file systems, including ext[234] and
ISO9660, which are the two formats we support via ‘--file-system-type’.
It does not support Btrfs, but ‘guix system disk-image’ doesn’t support
it either so far.

Looking at ‘image-ext2.c’ reveals that genimage actually just shells out
to mke2fs.  Indeed, I discovered that ‘mke2fs -d /my/root’ copies
/my/root as the image’s root directory.  Likewise, for ISO, it just
shells out to ‘genisoimage’.

So I think that we could avoid ‘genimage’ altogether and implement
similar functionality for ext4/ISO in (gnu build disk-image).

WDYT?

Thanks,
Ludo’.

Re: Linphone

[Danny Milosavljevic]

Hi Raghav,

I tried

(arguments
 `(#:configure-flags
   (list "-DENABLE_DBUS=YES"
 "-DENABLE_UPDATE_CHECK=YES")
   #:phases
   (modify-phases %standard-phases
 (add-after 'unpack 'patch
   (lambda _
 (substitute* "CMakeLists.txt"
  (("find_package[(]BcToolbox REQUIRED[)]")
   "find_package(bctoolbox REQUIRED)")
  (("find_package[(]Belcard REQUIRED[)]")
   "find_package(belcard REQUIRED)"))
 #t)

in linphone-desktop's package description and the error message changed.


pgpiCJYa8MhrE.pgp
Description: OpenPGP digital signature

Re: automake-1.16.2

[Ludovic Courtès]

Hi!

Vincent Legoll  skribis:

> Trying to update automake to the latest, I'm seeing lots
> of skipped tests because of missing native-inputs, would
> it be OK toadd those to enable more tests to be run ?

I hadn’t seen your message and added Automake 1.16.2 in commit
72a5cc53586080e75ae4ee80f3a2467ff30c4f5e.

Most tests are automatically skipped when the tool they need is missing,
except for the one mentioned in the commit.

We’d probably have to decide on a case by case basis which additional
dependencies we’d like to add, given that Automake has a lot of
dependents.

Thanks,
Ludo’.

Re: Linphone

[Raghav Gururajan]

Hi Ricardo!

> Does bctoolbox install a pc file?

bctoolbox source tarball does have bctoolbox.pc.in file. But adding pkg-config 
as native-inputs for linphone-desktop did not work. Should I be doing adding 
something else?

Re: Linphone

[Ricardo Wurmus]

Raghav Gururajan  writes:

> Hi Ricardo!
>  
>> Please try adding pkg-config to the native-inputs.
>
> I tried it, but didn't work.
>
>> If this still doesn’t work check the output of bctoolbox: does it
>> install a pkg-config file? If it does: does the file mention any
>> libraries that must be propagated?
>
> I believe the build script doesn't use pkg-config. :/

Does bctoolbox install a pc file?
Cmake often uses pkg-config for finding packages.

-- 
Ricardo

Re: Hi, I was able to do basic build and install of XChat IRC Client

[LaFreniere, Joseph]

Veera  writes:

I have successfully done a basic build and install of XChat IRC 
Client.


From what I can tell [0], the latest commit to XChat was in 2011. 
Is this the software you packaged, or did you perhaps intend to 
refer to HexChat [1], a maintained fork?



I had chat about this in #Guix IRC. brendyyn, drakonis, lfam.

They objected with XChat inclusion in Guix.
…
Please can you tell me what to do?


Did the participants in #Guix who objected to including XChat in 
Guix provide any reasons for their objections?  Understanding what 
specifically they disliked about your recipe or the upstream 
software might provide some guidance for next steps.


[0] http://xchat.org/files/?C=M;O=D
[1] https://hexchat.github.io/

--
Joseph LaFreniere

Re: Linphone

[Raghav Gururajan]

Hi Danny!

> ... and I checked ./cmake/BcToolboxConfig.cmake.in in bctoolbox and that does 
> look okay.
> 
> But they have a renamer in CMakeLists.txt and that checks
> 
> set(EXPORT_TARGETS_NAME "bctoolbox")
> 
> So probably you could specify that one. No idea why it exists and is different
> from the original name.

I see. How do I specify that in the package-definition of linnphone-desktop? I 
tried "-DEXPORT_TARGETS_NAME=bctoolbox" as configure-flag, but did not work.

Regards,
RG.

Re: Linphone

[Raghav Gururajan]

Hi Danny!

> So I checked that directory and it indeed does not have that file.
> 
> But it does have
> /gnu/store/m92m6bg0xcl28djxg8h97sszf3gdl42r-bctoolbox-4.3.1/share/bctoolbox/cmake/bctoolboxConfig.cm
> ke
> -- note the different case of the name.

Thanks so much for spotting this.

> So I'd say either linphone-desktop or bctoolbox has the case wrong in some 
> cmake file.

I believe it is linphone-desktop and not bctoolbox. Because other 
Belledone-Communications packages has bctoolboox as required dependency and 
they all work fine. So I think the issue is with linphone-desktop.

> linphone-desktop has the following line:
> 
> ./CMakeLists.txt: include("${EP_bctoolbox_CONFIG_DIR}/BcToolboxConfig.cmake")
> 
> ... and that line is not going to work as-is.

Yeah, that's true. Is there a way to patch this, with-in package definition? 
Could you help me with the syntax?

Thank you!

Regards,
RG.

Re: Plan for a release!

[Vincent Legoll]

On Thu, Mar 26, 2020 at 12:55 PM Ludovic Courtès  wrote:
> Another approach would be to do like ‘guix system vm’, which is to share
> the store with the host.  But then we would need a way to be able to run
> a daemon in the guest and have its build results overlaid on top of the
> host-provided store.

Couldn't `guix copy` be used here to get built items back onto the host
easily ?

-- 
Vincent Legoll

Re: Linphone

[Raghav Gururajan]

Hi Ricardo!
 
> Please try adding pkg-config to the native-inputs.

I tried it, but didn't work.

> If this still doesn’t work check the output of bctoolbox: does it
> install a pkg-config file? If it does: does the file mention any
> libraries that must be propagated?

I believe the build script doesn't use pkg-config. :/

Regards,
RG.

Re: Frequent locales problems for new users

[Ludovic Courtès]

Hi,

Leo Famulari  skribis:

> On Sat, Mar 21, 2020 at 04:37:05PM +0100, Ludovic Courtès wrote:
>> Thoughts?  How do other distros deal with this?  Are we missing some
>> trick to compress locale data?
>
> I noticed that downloading glibc-locales, it's 10.8 MiB. On disk, the
> store item is ~220 MiB. I'm not sure how guix size calculates 917 MiB.

Oh, this is due to hard links: nars don’t support hard links, so the
same thing is repeated several times.

--8<---cut here---start->8---
$ guix archive --export glibc-locales |wc -c
961328272
$ du -hsl $(guix build glibc-locales)
939M/gnu/store/03nvilh2x4z07dxv7h13gh986vvgpnsf-glibc-locales-2.29
$ du -hs $(guix build glibc-locales)
220M/gnu/store/03nvilh2x4z07dxv7h13gh986vvgpnsf-glibc-locales-2.29
--8<---cut here---end--->8---

(It does mean that we should replace hard links with symlinks, like we
do for ‘git’.)

Doing that with the full set of UTF-8 locales I mentioned in my previous
message, I see:

--8<---cut here---start->8---
$ du -hsl /gnu/store/p0knl9ggxk91x87ww702g2x78jxy1vgf-glibc-utf8-locales-2.29
870M/gnu/store/p0knl9ggxk91x87ww702g2x78jxy1vgf-glibc-utf8-locales-2.29
$ du -hs /gnu/store/p0knl9ggxk91x87ww702g2x78jxy1vgf-glibc-utf8-locales-2.29
193M/gnu/store/p0knl9ggxk91x87ww702g2x78jxy1vgf-glibc-utf8-locales-2.29
--8<---cut here---end--->8---

To compare to:

--8<---cut here---start->8---
$ du -hs $(guix build glibc-utf8-locales)
6.1M/gnu/store/n79cf8bvy3k96gjk1rf18d36w40lkwlr-glibc-utf8-locales-2.29
$ du -hsl $(guix build glibc-utf8-locales)
15M /gnu/store/n79cf8bvy3k96gjk1rf18d36w40lkwlr-glibc-utf8-locales-2.29
--8<---cut here---end--->8---

Thanks,
Ludo’.

Re: Experiment in generating multi-layer Docker images with guix pack

[Ludovic Courtès]

Hello Chris,

Christopher Baines  skribis:

> These patches are very rough, and not ready, but do at least work in some
> limited capacity. I've been testing with the following commands:
>
>   guix pack --format=docker guile@2.2.6
>   guix pack --format=docker guile@2.2.7
>
> With the previous Docker image generation implementation, two different ~130MB
> images would be generated. These patches mean that each .tar.gz file generated
> by guix pack contains a ~53MB layer which contains the profile and directly
> referenced store items, and then a ~77MB layer with all the other store items
> which is identical for both the 2.2.6 and 2.2.7 pack file.

Nice!

> I think it could be useful to support multiple different strategies for
> generating layers for Docker images, with different trade-offs. This approach
> using two layers should make the resulting images more efficient to use in the
> case where like the guile example above, where the packages you run guix pack
> with have exactly matching inputs.

Did you read ?
They came up with a pretty smart algorithm that would be worth copying.

> This could often be the case if you're developing an application, packaging it
> with Guix, then using guix pack to generate a Docker image which you
> deploy. With the single layer approach, if you change the application code,
> you'll get an entirely different image. I haven't tried this out, but my hope
> is that by generating a common base layer, if you change the application code
> only the top layer of the Docker image will change, meaning you'll only have
> to deploy that, rather than having to deploy the entire image. If you're
> deploying the images across a network, having less data to send around can
> save time, and reduce the amount of space required to store the images.

Definitely.

> As well as these behaviour changes, these patches also modify the
> implementation. Rather than having some build side code that's used in the
> pack and vm module gexpressions, these patches introduce two new record types:
>  and . This at least structures the
> derivations so that each layer is represented by a derivation, and then
> there's a derivation for the image itself, which is a little more efficient in
> terms of computation.

Nice.

I think a layering algorithm like Graham Christensen’s above requires
knowledge of the reference graph, meaning that layering can only be
computed on the build side, using #:references-graphs.  In that case, it
could be that you can’t have a host-side  record.

> What do people think about generating multi-layer images, and using record
> types to represent the layers and image?

I think multi-layering is something we should definitely have, and
record for at least the image are a good idea.  :-)

Thanks for looking into this!

Ludo’.

Re: Plan for a release!

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

>> Yes: you need to have ‘installation-os-for-gui-tests’ (or preferably a
>> variant thereof) include all the services/packages needed for the target
>> config.
>>
>> In the manual installation tests we use ‘define-os-with-source’ to both
>> embed the target OS and its references in the installation image *and*
>> have the source of the target OS available in /etc/target-config.scm in
>> the installation image.
>
> Ok! I'm testing with an installation image containing all desktop
> environments. This represents 1200 store items (image around 6GiB).
>
> The disk-image creation takes 2h45 on a powerful machine (with
> KVM). I've seen your insights on this topic here:
>
>>   I'd like to propose an alternative mechanism which would be faster and
>>   not involving virtual machines. Maybe producing the disk-image in a
>>   container?
>
> Unfortunately, I don’t think that’s possible.  The reason we resort to
> VMs is that the Linux kernel doesn’t allow you, for instance, to mount a
> file system without being root.  So doing things like running Parted,
> mounting a file system, and populating it typically requires root
> privileges.  (In some cases, there are tools like mksquashfs that can do
> that from user-space, but it’s very ad-hoc.)
>
> It makes sense and after some digging, I cannot propose something
> better (nix is using the same mechanism). However, I feel very
> frustrated by this disk-image thing, loosing a lot of time and
> computation time for some copies.

Understood.  :-/

Another approach would be to do like ‘guix system vm’, which is to share
the store with the host.  But then we would need a way to be able to run
a daemon in the guest and have its build results overlaid on top of the
host-provided store.

Note that system tests other than the installation tests actually use
the equivalent of ‘guix system vm’ already, so they copy much less stuff
around.

Thanks,
Ludo’.

Re: Brainstorming features for issues.guix.gnu.org

[Ricardo Wurmus]

Vincent Legoll  writes:

> filtering by severity maybe be of use (low, easy for newcomers, etc.)

This already works for all severities that Debbugs supports.  For
example:

https://issues.guix.gnu.org/search?query=severity%3Aserious+is%3Aopen

(28211 is included because of a bug: the issue has been moved to a
different package, so it is not included in the regular automated
updates of our database.)

We also have a dedicated page for easy issues:

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

The “severity” query filter should be documented, and we should probably
link to the “/easy” page somewhere.

--
Ricardo

Re: Brainstorming features for issues.guix.gnu.org

[Vincent Legoll]

filtering by severity maybe be of use (low, easy for newcomers, etc.)

-- 
Vincent Legoll

Re: Use genimage for disk-image creation.

[Efraim Flashner]

On Thu, Mar 26, 2020 at 10:55:04AM +0100, Vincent Legoll wrote:
> FYI, I'm investigating the test suite failures for the newer
> releases of genimage (v11 (+1 FAIL) & v12 (+2 FAIL))...
> 
> I think I'll report / PR them upstream before updating
> guix's version, to avoid unnecessary churn.
> 

I found that updating Guix's version of mtools also spawned errors on
genimage on aarch64/armhf (IIRC), so that might also be something worth
looking into.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Use genimage for disk-image creation.

[Vincent Legoll]

FYI, I'm investigating the test suite failures for the newer
releases of genimage (v11 (+1 FAIL) & v12 (+2 FAIL))...

I think I'll report / PR them upstream before updating
guix's version, to avoid unnecessary churn.

-- 
Vincent Legoll

Re: Brainstorming features for issues.guix.gnu.org

[Vincent Legoll]

Looks like the "is:Done" bug is not a bug, but a case-sensitivity
issue on my side...

-- 
Vincent Legoll

Re: Brainstorming features for issues.guix.gnu.org

[Vincent Legoll]

Another idea:

Detect applied patches (idependently of the Done issue status)
because an issue may have more than one patch, or patch
revisions, and all may not be applicable / applied, etc.

-- 
Vincent Legoll

Re: Brainstorming features for issues.guix.gnu.org

[Vincent Legoll]

Hello,

On Thu, Mar 26, 2020 at 9:49 AM Ricardo Wurmus  wrote:
>
> Hello Guix!
>
> I want issues.guix.gnu.org to become more useful for all of us.

Yes, that is a nice goal, I have a few ideas.

> If you do use it: what features do you think are missing?

* I'd like to have a way to reverse the ordering of the results, especially
to get newer issues at the top (I think this should even be the default).

But as you say later, the "oldest first" view is also of interest, so
a classical
ordering combobox could be added

order-by:
- oldest to newest
- newest to oldest
- etc.

* The filtering hints are great (are they an exhaustive list, is there a full
list somewhere). But to ease their use, maybe they could be made
clickable, and a click on one could append it to the search entry, making
their usage from a "select, copy, change focus, paste, click search" into
"click item(s) from the hint list, click search"... This is not high
priority, but
maybe nice to have UI enhancement.

* the "is:Done" filtering shows some Open issues, is that a bug, or a
misunderstanding on my part about what is "Done"

> Personally, I’d wish for a more streamlined workflow to download and
> apply patch sets.  I don’t want to click on each “download” link in the
> web interface.  Instead I would like to run something like
>
> ./etc/review 12345
>
> which would fetch the patches in issue 12345 and apply them to my
> git worktree.

or to a new branch (maybe you can take ideas from gerrit, not all of
it hopefully ;-))

> I would also like to see neglected issues in the web interface, i.e. a
> list of open issues that haven’t seen any response in a while and that
> haven’t been tagged as awaiting more information from the submitter.
> This should make it easier for us to prevent patches from slipping into
> obscurity, which is a terrible thing to happen especially for new
> contributors.

An indicator (à la Done, Open) could be added to make issues with
patches stand out.

Thanks for the great work BTW
Tchuss

-- 
Vincent Legoll

Re: Brainstorming features for issues.guix.gnu.org

[Arun Isaac]

> Personally, I’d wish for a more streamlined workflow to download and
> apply patch sets.  I don’t want to click on each “download” link in the
> web interface.  Instead I would like to run something like
>
> ./etc/review 12345
>
> which would fetch the patches in issue 12345 and apply them to my
> git worktree.

This feature would be very welcome. Perhaps we need an emacs interface
to mumi just as debbugs has an emacs interface. We could implement this
emacs interface by first implementing a HTTP API for mumi and then
making emacs interact with that HTTP API. But, I think it would be
better to simply run mumi locally. That is, we first pull all the latest
bug reports using something like `mumi pull` and then operate on the
local copy of bug reports. WDYT?

Also, the "download" link in mumi doesn't correctly download the patch
when the patch is sent using `git send-email`. This is because it
truncates the headers of the email that is required by `git am` to
correctly apply the patch. For example, see the second email in
https://issues.guix.info/issue/34948 Due to this bug, I often find
myself having to fall back to the debbugs web interface.

> I would also like to see neglected issues in the web interface

It would be nice to have the "Recent activity" and "Priority bugs" lists
on the home page load without javascript.

> list of open issues that haven’t seen any response in a while and that
> haven’t been tagged as awaiting more information from the submitter.
> This should make it easier for us to prevent patches from slipping into
> obscurity, which is a terrible thing to happen especially for new
> contributors.

I agree completely.


signature.asc
Description: PGP signature

Re: Outreachy Applicant - Guix Data Service

[Christopher Baines]

Christopher Baines  writes:

> Daniela Lura  writes:

>> In addition to that, I noticed that when I go to
>> http://localhost:/revision/554f5b62805b900a9e4e320c800c13557b7e/system-tests
>> I
>> don't get any data in the name,  description, location, derivation and
>> build status fields even though I have loaded the small dump. Is this
>> normal?
>
> Ah, sorry about that. The system test data seems to be entirely removed
> from the small dump. I'll look at fixing this and hopefully have a new
> small dump with that data available in the next day or two.

Small update on this. I have managed to improve the small dump code, but
not enough for the system tests and channel instance pages to work yet.

Instead of that, perhaps look at the page for a branch. I've just pushed
a change [1] to the Git repository to put in a not very useful
response. The work now is to actually have the response return relevant
data.

1: 
http://git.savannah.gnu.org/cgit/guix/data-service.git/commit/?id=00bc6535f97cac86a91339f492256888d1fff512

Chris


signature.asc
Description: PGP signature

Brainstorming features for issues.guix.gnu.org

[Ricardo Wurmus]

Hello Guix!

I want issues.guix.gnu.org to become more useful for all of us.  It’s
easy to get lost in a deluge of bug reports and patch submissions, so
our tools should allow us to stay afloat.

Do you use issues.guix.gnu.org?  If you aren’t: what workflow do you
have to review patch submissions?

If you do use it: what features do you think are missing?

Personally, I’d wish for a more streamlined workflow to download and
apply patch sets.  I don’t want to click on each “download” link in the
web interface.  Instead I would like to run something like

./etc/review 12345

which would fetch the patches in issue 12345 and apply them to my
git worktree.

I would also like to see neglected issues in the web interface, i.e. a
list of open issues that haven’t seen any response in a while and that
haven’t been tagged as awaiting more information from the submitter.
This should make it easier for us to prevent patches from slipping into
obscurity, which is a terrible thing to happen especially for new
contributors.

What do you think?

--
Ricardo