Re: FOSDEM: Meeting on Wednesday evening?

[Janneke Nieuwenhuizen]

Ludovic Courtès writes:

Hello!

> I’ll be in Brussels on Wednesday afternoon, Feb. 1st.  As was tradition
> in the good’ol times, I propose that interested parties meet in the bar
> called “Au Bon Vieux Temps”, downtown, let’s say around 6:30PM:
>
>   
> https://www.openstreetmap.org/?mlat=50.84830=4.35238#map=19/50.84830/4.35238

Lovely, see you there!
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: UTF-8 progress bar

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

Hi,

On Mon, Jan 30, 2023 at 3:35 PM  wrote:
>
> I suspect those characters could be made to work in Akib's console
> if his kernel supports KMS and setfont etc ..

The characters displayed correctly in my Linux virtual console VT2
after I ran this command in Bash:

setfont 
/gnu/store/iga6jf0krlh135zca7y6f1f7c4ar32z2-font-gnu-unifont-15.0.01-psf/share/consolefonts/Unifont-APL8x16.psf.gz

I was logged in as root. The variable $LC_ALL appeared to be empty. My
VT2 is managed by Greetd.

Hope that helps!

Kind regards,
Felix Lechner

Re: UTF-8 progress bar

[bokr]

Hi Ludo, Akib, et al,

On +2023-01-30 23:02:43 +0100, Ludovic Courtès wrote:
> 
  ^^--- interesting: I see that thumb up emoji in mutt's display,
  but not in emacs, which I have configured mutt to use as my editor.

> 
> Julien Lepiller  skribis:
> 
> > I have a patch waiting (https://issues.guix.gnu.org/59975) that will
> > change progress bars to use some unicode characters. I think they look
> > better, but I'm a bit afraid they might not look right on some config,
> > so I'd like to know if your terminal is able to show these characters:
> >
> > "▏▎▍▌▋▊▉█▏▕"
>
 ---seems fine in tilix and Emacs PureOS/Wayland/Gnom
 e
> Confirmed to work for me in xterm and Emacs on X11 (Guix System).
> 
  ^^---as above
> 
> Ludo’.
> 

I suspect those characters could be made to work in Akib's console
if his kernel supports KMS and setfont etc ..

So I guess you, Akib, mean $LANG="en_US.utf8" in your execution
context is insufficient to make your system show the utf8 charaters
in question, not that there's no fix possible? ;)

IDK, but perhaps your app could use a wrapper that sets up a font,
along with a utf8 map that will show the necessay characters?

See:
info setfont
and
info showconsolefont

HTH
--
Regards,
Bengt Richter

Re: Proposed changes to the commit policy (#59513)

[Christopher Baines]

Andreas Enge  writes:

> Am Wed, Jan 18, 2023 at 11:45:20AM + schrieb Christopher Baines:
>> > as a quick concrete question: Do simple package updates still count as
>> > trivial, or do they need to go through the patches mailing list?
>> My feeling on this is that "simple" package updates are often not
>> trivial, or at least doing rigorous testing for these updates isn't
>> trivial. A definition of trivial might be "having little value or
>> importance", and I don't think that's generally the case for version
>> updates, they're often a valuable and important change.
>
> So I tried it once, and find the hassle offputting. It feels like doubling
> the effort - after doing the real work, I need to get back to it a week
> later and more or less go through the motions again (rebase the commit
> and resign it, recompile Guix, build the package again just in case),
> plus the debbugs effort.
>
> So expect even less package updates from my part in the future... These
> were the kind of instant gratification actions one could do more or less
> in the background, and they have become more complex administrative
> endeavours with delayed gratification. (I also do not know how to set up
> git-sendmail with my remote SMTP server login and password, but this is
> a one-time cost of learning which does not matter that much.)

I appreciate feeling put off by this, although I'd maybe reframe it as
balancing quality with other factors, and how that's going to change for
Guix as a project over time.

In the past and currently to some extent, it's been possible to move
very quickly without comprimising on quality. However, my feeling on
this is that if we want to have quality support for non x86_64-linux
architectures, reproducible builds, packages that build reliably,
... then that's going to require more effort. That might mean some
changes happen more slowly, but this is why I'm working on the tools and
processes, as I think that's a path to trying to maintain and improve
the quality while reducing the impact to pace and enjoyment.

I'm sure there are ways of addressing at least some of the problems you
mention above, so it's really valuable to mention them so that we can
work towards solutions.

Thanks,

Chris


signature.asc
Description: PGP signature

Re: UTF-8 progress bar

[Ludovic Courtès]



Julien Lepiller  skribis:

> I have a patch waiting (https://issues.guix.gnu.org/59975) that will
> change progress bars to use some unicode characters. I think they look
> better, but I'm a bit afraid they might not look right on some config,
> so I'd like to know if your terminal is able to show these characters:
>
> "▏▎▍▌▋▊▉█▏▕"

Confirmed to work for me in xterm and Emacs on X11 (Guix System).


Ludo’.

Re: Translation files .gmo and packaging

[Ludovic Courtès]

Hello!

Simon Tournier  skribis:

> What is the usual way to deal with these generated files?  Can we
> distribute them although it is not the Guix project that generates them
> from source?

In pure bootstrappable spirit, we should view tarballs as byproducts,
not source, and thus depend only on the actual source (VCS repo).

This has been discussed a few times here and there’s consensus I think
that this is The Way to Go (I remember a thread started by Maxime Devos
on this topic months ago).

However, a practical detail: most GNU packages ship generated build
machinery; building those packages from source means adding dependencies
on Autoconf & co., which may prove to be tedious deep in the dependency
graph.

So for now, I think we should avoid tarballs produced by autotools &
co. whenever doing so is simple, while postponing that for more crucial
packages.

In the case of ice-wm, it would seem that there’s the extra difficulty
that source is scattered in different places (where are the .po files?),
so perhaps that’s a case where you may want to use the tarball, possibly
discussing with upstream to see if we can do better.

HTH,
Ludo’.

Re: 01/02: packages: Adjust 'generate-package-cache' for Guile 3.0.9.

[Ludovic Courtès]

Hi!

Simon Tournier  skribis:

> Commit ba1b61a72d56600e7c6f9c490129e95ab9ba0c9e reads:
>
> packages: Adjust 'generate-package-cache' for Guile 3.0.9.
>
> * gnu/packages.scm (generate-package-cache): Adjust for Guile 3.0.9.

[...]

> What are the performances about this change?  Does it improve the
> generation of the cache?  Faster or slower?
>
> Or the resulting cache, is it larger or smaller?

The resulting cache is unchanged and build time should be similar, but
memory usage is slightly reduced:

  https://lists.gnu.org/archive/html/guile-devel/2023-01/msg00013.html

Ludo’.

Re: purpose of GnuTLS versions

[Ludovic Courtès]

Hi Jack,

Jack Hill  skribis:

> We currently have two versions of GnuTLS packaged: 3.7.2 represented
> by the `gnutls` variable and 3.7.7 represented by the `gnutls-latest`
> variable. `guix refresh -l` reports that changes to the 3.7.2 version
> would cause 14770 rebuilds, but only 30 rebuilds for the 3.7.7
> version. As far as I can tell, neither version currently has a
> replacement (graft).

‘gnutls-latest’ was initially added to provide up-to-date Guile
bindings, since Guile bindings were part of GnuTLS.

Since a couple of months ago, Guile bindings live in a separate repo,
but the new ‘guile-gnutls’ package depends on ‘gnutls-latest’, which no
longer depends on Guile (whereas ‘gnutls’ still depends on Guile).

> It seems to me that the `gnutls` variable should refer to the latest
> "stable" release, and the `gnutls-latest` variable to latest "next"
> release. Does that make sense? What am I missing?

As Simon pointed out, that’s for ‘core-updates’.

> It appears that 3.7.2 has some unpatched advisories [2].

Ouch, then we probably need a ‘replacement’.  Would you like to give it
a try?

Thanks for the heads-up!

Ludo’.

Re: valgrind

[Ludovic Courtès]

Hi!

The two ‘/interactive’ versions can probably be merged; I don’t think
there was a good reason to keep 3.17.

Thanks,
Ludo’.

Re: Proposed changes to the commit policy

[Ludovic Courtès]

Hi!

My 2¢ on this…  As a committer & reviewer, I love that I can just go to
, pick one of the patch series with a
green tick, and have the assurance that the resource-intensive work is
already done.  That makes a big difference!

As someone who submits patches, I realize the delay can be off-putting.
For the hwloc upgrade I recently submitted, I got valuable feedback
pointing at actual issues, but that was about a week later.  Then I had
to switch contexts again to adjust the patch accordingly.

I guess that, to a large extent, that’s scheduling and resource issue.

Happy to discuss that in the coming days in Brussels!

Ludo’.

Re: purpose of GnuTLS versions

[Jack Hill]

On Mon, 30 Jan 2023, Jack Hill wrote:


To help us decide, I've asked [0] the GnuTLS developers for their thoughts.


I was directed to an older thread [0] which provides some more insight. 
Having read that, I propose to moving to just one gnutls version in 
core-updates. Thoughts?


Then there's the question of what to do in the meantime for master. Grafts 
for 3.7.2? Move packages to 3.7.7?


[0] https://lists.gnutls.org/pipermail/gnutls-help/2022-September/004748.html

Best,
Jack

Re: purpose of GnuTLS versions

[Jack Hill]

On Thu, 26 Jan 2023, Simon Tournier wrote:


Hi,

On Thu, 26 Jan 2023 at 00:12, Jack Hill  wrote:


It seems to me that the `gnutls` variable should refer to the latest
"stable" release, and the `gnutls-latest` variable to latest "next"
release. Does that make sense? What am I missing?


This means a core-updates change – so next core-updates merge cycle? :-)


Agreed, a change to the gnutls variable will need to go through 
core-updates. However, while the current situation does seem odd to me, 
I'm still not sure what the best resolution will be. "Downgrading" gnutls 
was only one option. Another option that I can think of is moving to only 
having one GnuTLS version, probably 3.7.x, and fixing problems via grafts 
in the master branch. In the meantime, we may want to move individual 
packages from gnutls to gnutls-latest or patch the known bugs in gnutls 
with grafts.


To help us decide, I've asked [0] the GnuTLS developers for their 
thoughts.



If I read correctly, core-updates already uses 3.7.7 for the variable
’gnutls’ and note that the variable ’gnutls-latest’ also uses 3.7.7. :-)


:)

[0] https://lists.gnutls.org/pipermail/gnutls-help/2023-January/004813.html

Best,
Jack

Request for review of: [bug#60899] [PATCH 00/25] gnu: golang: Add gopls

[Katherine Cox-Buday]

Katherine Cox-Buday  writes:

> This is a patch series to add the gopls package.
>
> I haven't contributed to many projects which use the e-mail flow, so
> hopefully I'm doing this correctly. Please feel free to make
> suggestions if not!
>
> Some of the diffs are a little busier than I'd like for version bumps.
> This is due to running `guix style` over everything.
>
> For all of the packages I have:
>
> . Run guix style
> . Run guix lint
> . Built 2x
> . Checked that the change is in the correct branch
> . Built all dependencies
> . Built the repository
>
> Katherine Cox-Buday (25):
>   gnu: go-golang-org-x-sync: Update to 0.1.0-1.8fcdb60.
>   gnu: go-golang-org-x-mod: Update to 0.7.0.
>   gnu: Add go-golang-org-x-exp.
>   gnu: Add go-github-com-jba-printsrc.
>   gnu: Add go-github-com-google-safehtml.
>   gnu: Add go-github-com-jba-templatecheck.
>   gnu: go-github-com-google-go-cmp-cmp: Update to 0.5.9.
>   gnu: go-github-com-pkg-diff: Update to
> 0.0.0-20210226163009-20ebb0f2a09e.
>   gnu: go-github-com-rogpeppe-go-internal: Update to 1.9.0.
>   gnu: gopkg-in-errgo-fmt-errors: Rename package to
> go-gopkg-in-errgo-fmt-errors.
>   gnu: go-golang-org-x-tools: Update to 0.5.0.
>   gnu: Add xurls.
>   gnu: Add go-mvdan-cc-xurls.
>   gnu: Add misspell.
>   gnu: Add go-github-com-client9-misspell.
>   gnu: Add go-github-com-google-go-cmdtest.
>   gnu: Add unparam.
>   gnu: Add go-mvdan-cc-unparam.
>   gnu: Add govulncheck.
>   gnu: Add go-golang-org-x-vuln.
>   gnu: go-github-com-burntsushi-toml: Update to 1.2.1.
>   gnu: go-honnef-co-go-tools: Update to 0.3.3.
>   gnu: Add gofumpt.
>   gnu: Add go-mvdan-cc-gofumpt.
>   gnu: Add gopls.
>
>  gnu/packages/configuration-management.scm |   2 +-
>  gnu/packages/golang.scm   | 695 ++
>  2 files changed, 578 insertions(+), 119 deletions(-)
>
>
> base-commit: 5c921977179489caef4a9e54ada6696fc86d2f0b

Hello Guix! Acknowledging that everyone are volunteers, and busy (guilty
myself), this is a humble request for a review of this patch-series I
made two weeks ago so that it doesn't bit-rot.

I have a `gopls` home service[1] waiting to be proposed after this
patch-series is merged.

Thank you very much!

[1] 
https://github.com/kat-co/guix-channels/blob/upstream-staging/upstream/home/services/gopls.scm

P.S. I think I am following etiquette for review reminders (i.e. waiting
long enough, bringing this over to guix-devel), but I was having trouble
finding examples. If I haven't waited long enough, or have reminded in
the wrong way, please give me feedback.

-- 
Katherine

Re: guix package updates review: app team?

[Simon Tournier]

Hi,

On ven., 27 janv. 2023 at 14:19, Andy Tai  wrote:

> Hi, currently Guix has teams of reviewers for different types of
> packages.   For example, changes to R packages and emacs seem to be
> reviewed quickly.  However, recently, patches for updating more
> general application packages (octave, for example) seem to be reviewed
> and processed very slowly.
>
> As a GNU/Linux distribution the update speed of applications impact
> the perception of the community on a distribution, and thus it is
> beneficial if packages update can be processed quickly to keep Guix
> "up to date" so to speak.  Hope Guix maintainers can give some thought
> to this and let more volunteers participate in package review process
> to allow package updates more quickly.   As packages are usually at
> the end of the dependency chain (they depend on other libraries or
> components more than the other way around) updating packages shall
> take less review effort.

First of all, people are volunteers. :-)

Well, if it appears slow, then it probably mean people are busy
elsewhere.  The only thing is to help and reduce the workload.

What *you* (reader) could do is:

 1. Review.  It is not restricted only to people with commit access.

 2. Bug triage.  The tracker has many old bugs still open.  It would
help to:

a) confirm or not if the bug is still there;
b) propose a fix if it is still there.


About #1, if applying the patch is straightforward, if the patch is
already compliant with the standard, etc. then it is easier for
merging because it makes the task less boring for people with commit
access.

Please note that some packages and/or patches are harder than other.

Last, here the current state [1] of Guix.  Each red circle means that
one package is not available (probably broken and/or fails to build).
Since the manpower is limited, personally I would prefer to be less “up
to date” and all green, rather than packages merged more quickly and
probably a global state less stable.

Well, the balance is not easy to find and I understand the frustration.

1: 

Moreover, I agree that some part of the process could be revisited.
Please note this past thread « Incentives for review» with my own
ramblings on the topic. :-)

Re: Tricking peer review
Tue, 19 Oct 2021 16:22:30 +0200
id:86k0i9drh5@gmail.com
https://yhetil.org/guix/86k0i9drh5@gmail.com

More than one year later, my words are still describing my own point of
view on this topic about reviewing and merging.  However, the solutions
are not so easy to implement… otherwise it would already be done. ;-)
Thus, the question is: what could it be done for helping?

Cheers,
simon

Re: CLI flag to ignore guix channel

[Simon Tournier]

Hi,

On sam., 28 janv. 2023 at 20:55, Csepp  wrote:

>>> guix import crate behemoth-rust-package-foo -r --ignore-channel=guixrus

[...]

>> guix time-machine -C path/to/channels-wo-guixrus.scm \
>>  -- import crate behemoth-rust-package-foo -r

> How fast is that?  If new commits come in during time-machine
> invocations, won't it keep doing new builds of guix?

It depends what the file ’path/to/channels-wo-guixrus.scm’ would contain. :-)

My point was just to say that this speculative “ignore-channels” could
already be emulated using “guix time-machine”.  From my understanding of
what this speculative “ignore-channels” would do.

BTW, please note that this operation “ignore-channel” would be costly
because at least one “Computing Guix derivation” is required.

Cheers,
simon