How to run mumi locally?

[宋文武]

Hello, I try to run mumi locally on guix system with:
--8<---cut here---start->8---
(service mumi-service-type
 (mumi-configuration
   (mailer? #f)))
--8<---cut here---end--->8---

But then curl localhost:1234 return a empty reply.


In /var/log/mumi.worker.log there are errors:
--8<---cut here---start->8---
2023-02-01 13:10:26 Starting full indexing.
2023-02-01 13:10:26 worker error: (system-error open-file ~A: ~S (No such file 
or directory /var/mumi/data/spool/index.db.realtime) (2))
2023-02-01 13:10:26 worker error: (system-error open-file ~A: ~S (No such file 
or directory /var/mumi/data/spool/index.db.realtime) (2))
--8<---cut here---end--->8---

I think this means I have to get debbugs data (index, log, or maildir?)
files somehow.  How to do it?  Thank you!

Re: Mumi Feature Request: Easier way to apply patches from web interface

[宋文武]

Arun Isaac  writes:

>> Maybe add a guix command for issues/patches?
>>
>> guix issues new
>> guix issues open nnn
>> guix issues reply nnn 
>> guix issues apply nnn
>> guix issues close nnn
>
> Indeed, we should have something like this. But, probably better to put
> it in mumi so that other projects that use debbugs (I have skribilo in
> mind) can also benefit.

Yes, put it in mumi make senses, find a previous thread:

Re: branch master updated: gnu: w3m: Update to 0.5.3+git20230121.

[宋文武]

Christopher Baines  writes:

> guix-comm...@gnu.org writes:
>
>> This is an automated email from the git hooks/post-receive script.
>>
>> iyzsong pushed a commit to branch master
>> in repository guix.
>>
>> The following commit(s) were added to refs/heads/master by this push:
>>  new a3b57e57e6 gnu: w3m: Update to 0.5.3+git20230121.
>> a3b57e57e6 is described below
>>
>> commit a3b57e57e68a1f4848bf8bacd797c5d989f56de2
>> Author: André Batista 
>> AuthorDate: Fri Jan 27 09:37:02 2023 -0300
>>
>> gnu: w3m: Update to 0.5.3+git20230121.
>> 
>> * gnu/packages/w3m.scm (w3m): Update to 0.5.3+git20230121.
>> 
>> Signed-off-by: 宋文武 
>> ---
>>  gnu/packages/w3m.scm | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Given the +1800 dependent packages, the contributing guidance suggests
> this change should go to the core-updates branch.
>
> → guix refresh -l w3m
> Building the following 984 packages would ensure 1859 dependent packages
> are rebuilt: ranger@1.9.3 ...

oops, I forget to check its dependent, think the only one is
emacs-w3m...  Sorry for the troubles!

Re: Mumi Feature Request: Easier way to apply patches from web interface

[Arun Isaac]

> Maybe add a guix command for issues/patches?
>
> guix issues new
> guix issues open nnn
> guix issues reply nnn 
> guix issues apply nnn
> guix issues close nnn

Indeed, we should have something like this. But, probably better to put
it in mumi so that other projects that use debbugs (I have skribilo in
mind) can also benefit.

Re: branch master updated: gnu: w3m: Update to 0.5.3+git20230121.

[kiasoc5]

On 1/31/23 11:35, Leo Famulari wrote:

On Tue, Jan 31, 2023 at 09:20:37AM +, Christopher Baines wrote:

Given the +1800 dependent packages, the contributing guidance suggests
this change should go to the core-updates branch.

→ guix refresh -l w3m
Building the following 984 packages would ensure 1859 dependent packages
are rebuilt: ranger@1.9.3 ...


Wow! It's not great that this package has so many dependents. It's
basically abandonware, dangerous to use on the web, and not exactly a
popular way to browse the web anyways.


Is it abandonware if the project is still under active development?

https://salsa.debian.org/debian/w3m/-/blob/master/ChangeLog

Re: purpose of GnuTLS versions

[Jack Hill]

On Tue, 31 Jan 2023, Ludovic Courtès wrote:


Jack Hill  skribis:


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?


Graft, after making sure both versions are ABI-compatible (it should be
the case).


Unfortunately, we may not be so lucky. ABI Laboratory* reports that were 
some changes in 3.7.3 [0]. Does that look like it would be problem? For 
reference, the fixes for the announced security advisories looks small 
enough that a backport is feasible (although I haven't tried yet) [1][2].


* I don't know if we have ABI checking tools in Guix. The ones that power 
ABI Laboratory look like candidates for packaging though.


[0] 
https://abi-laboratory.pro/index.php?view=compat_report&l=gnutls&v1=3.7.2&v2=3.7.3&obj=0a750&kind=abi#Symbol_Problems_High
[1] 
https://gitlab.com/dueno/gnutls/-/commit/22f837ba0bc7d13c3d738a8583566368fc12aee1
[2] https://gitlab.com/gnutls/gnutls/-/merge_requests/1615/diffs

Anyways, I'm of course happy to propose some patches (keeping in mind the 
usual competition for my time, so it might be a couple days).


Best,
Jack

Re: purpose of GnuTLS versions

[Ludovic Courtès]

Jack Hill  skribis:

> 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?

Agreed!  Make sure Guile is removed from its inputs.

> 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?

Graft, after making sure both versions are ABI-compatible (it should be
the case).

Thanks!

Ludo’.

Re: branch master updated: gnu: w3m: Update to 0.5.3+git20230121.

[Leo Famulari]

On Tue, Jan 31, 2023 at 09:20:37AM +, Christopher Baines wrote:
> Given the +1800 dependent packages, the contributing guidance suggests
> this change should go to the core-updates branch.
> 
> → guix refresh -l w3m
> Building the following 984 packages would ensure 1859 dependent packages
> are rebuilt: ranger@1.9.3 ...

Wow! It's not great that this package has so many dependents. It's
basically abandonware, dangerous to use on the web, and not exactly a
popular way to browse the web anyways.

Re: FOSDEM: Meeting on Wednesday evening?

[Andreas Enge]

Am Mon, Jan 30, 2023 at 11:31:55PM +0100 schrieb Ludovic Courtès:
> 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:

I will arrive too late, but should be able to join for dinner. Please post
the meeting point somewhere ;-)

Andreas

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:
>
> 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?

Should we use the GNU Unifont [1][2] for virtual terminals by default?

With support for the languages below, it may be superior to whatever
we are using currently.

Kind regards
Felix Lechner

[1] https://en.wikipedia.org/wiki/GNU_Unifont
[2] https://unifoundry.com/unifont/

* * *

Full Language Support [https://fontlibrary.org/en/font/gnu-unifont]:
Afrikaans, Arabic, Archaic Greek Letters, Armenian, Baltic, Basic
Cyrillic, Basic Greek, Basic Latin, Bengali, Catalan, Central
European, Cherokee, Chess Symbols, Chinese Zhuyin Fuhao, Claudian
Letters, Coptic, Devanagari, Dutch, Esperanto, Ethiopic, Euro, Farsi,
Georgian, Gujarati, Gurmukhi, Hanunó'o, Hebrew, Igbo Onwu, IPA,
Japanese Jinmeiyo, Japanese Kokuji, Kannada, Kazakh, Khmer, Korean
Hangul, Lao, Latin Ligatures, Malayalam, Mongolian, Myanmar, New Tai
Lue, N’Ko, Ogham, Oriya, Osmanya, Pan African Latin, Pashto, Pinyin,
Polytonic Greek, Romanian, Runic, Simplified Chinese, Sindhi, Sinhala,
Syriac, Tai Le, Tai Tham (Lanna), Tamil, Telugu, Thaana, Thai,
Tibetan, Tifinagh, Traditional Chinese, Turkish, Uighur, Unified
Canadian Aboriginal Syllabics, Urdu, Vai, Vietnamese, Western
European, Yi

Re: FOSDEM: Meeting on Wednesday evening?

[Christopher Baines]

Ludovic Courtès  writes:

> 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:

...

> Who’s in?

I'll be there :D Very excited for FOSDEM to be back on this year and to
be back meeting up with people in Brussels!

Chris


signature.asc
Description: PGP signature

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

[Simon Tournier]

Hi Ludo,

On Mon, 30 Jan 2023 at 22:52, Ludovic Courtès  wrote:

>> 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

Thanks for the pointer.  Cool!

Cheers,
simon

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

[Simon Tournier]

Hi,

On Mon, 30 Jan 2023 at 22:03, Christopher Baines  wrote:

> 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 agree.

For what it is worth, this kind of slow transition seems common to many
projects. :-) For example, a recent story about Yocto [1].  Teaser:

Our scale also means patch requirements are more demanding
now. Once, when the number of people using the project was
small, the impact of breaking things was also more limited,
allowing a little more freedom in development. Now, if we accept
a change commit and something breaks, it becomes an instant
emergency, […]

Well, happy to discuss in Brussels or elsewhere such topic: being more
reliable with fun. :-)

Cheers,
simon


(From LWN [2] ;-))

1: 

2: 

Re: Translation files .gmo and packaging

[zimoun]

Hi Ludo,

On Mon, 30 Jan 2023 at 22:59, Ludovic Courtès  wrote:

> 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.

Well, v3 [1] is an attempt.

1: 


Cheers,
simon

Re: valgrind

[Simon Tournier]

Hi Andreas,

On Wed, 25 Jan 2023 at 14:16, Andreas Enge  wrote:
> Am Wed, Jan 25, 2023 at 01:39:29PM +0100 schrieb zimoun:

>> Is the package ’valgrind/interactive’ accessible with valgrind@3.17
>> needed?  Indeed, maybe it could be dropped, especially if it is broken
>> for some use-case.
>
> I do not know whether it is broken;

Sorry if I have misunderstood your initial message, quoting: « I have
the impression that my past problems with using valgrind have been
solved since the upgrade to 3.20.0 ».

> the question is rather whether it is
> needed: We do not normally keep several versions of packages around unless
> there is a good reason, and if there is one, it does not seem to be
> documented here.

Yes, I agree with your question.

>From my point of view, the package referred by the symbol
’valgrind/interactive’ accessible by the user with “valgrind@3.17” and
providing an expected Valgrind at version 3.17 is not needed and it
could be dropped.


> Similarly for valgrind-noninteractive 3.17; maybe if it is to be removed
> and replaced by valgrind-noninteractive 3.20, this will have to be done
> on a particular branch, or maybe it is indeed needed.

The removal of the hidden package referred by the symbol ’valgrind’ (I
guess what you are naming valgrind-noninteractive 3.17) is a
core-updates change.  It is difficult to say if the update from 3.17 to
3.20 will be smooth or not; ~1000+ packages at least are impacted by
such update.

Therefore, yes this package is needed for master. :-)


> The need for valgrind-noninteractive is also unclear.

Since it is an hidden package, it is not straightforward to evaluate the
closure.  I guess, this difference between valgrind and
valgrind/interactive (whatever the version) is about the closure.


Well, the package referred by the symbol ’valgrind/interactive’ should
be replaced by what ’valgrind-3.20’ provides.  Done with patch#61199 [1].

1: http://issues.guix.gnu.org/issue/61199

Cheers,
simon

Re: UTF-8 progress bar

[Akib Azmain Turja]

Felix Lechner via "Development of GNU Guix and the GNU System
distribution."  writes:

> 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

Thanks, it worked!

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."


signature.asc
Description: PGP signature

Re: branch master updated: gnu: w3m: Update to 0.5.3+git20230121.

[Christopher Baines]

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

> This is an automated email from the git hooks/post-receive script.
>
> iyzsong pushed a commit to branch master
> in repository guix.
>
> The following commit(s) were added to refs/heads/master by this push:
>  new a3b57e57e6 gnu: w3m: Update to 0.5.3+git20230121.
> a3b57e57e6 is described below
>
> commit a3b57e57e68a1f4848bf8bacd797c5d989f56de2
> Author: André Batista 
> AuthorDate: Fri Jan 27 09:37:02 2023 -0300
>
> gnu: w3m: Update to 0.5.3+git20230121.
> 
> * gnu/packages/w3m.scm (w3m): Update to 0.5.3+git20230121.
> 
> Signed-off-by: 宋文武 
> ---
>  gnu/packages/w3m.scm | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Given the +1800 dependent packages, the contributing guidance suggests
this change should go to the core-updates branch.

→ guix refresh -l w3m
Building the following 984 packages would ensure 1859 dependent packages
are rebuilt: ranger@1.9.3 ...


signature.asc
Description: PGP signature