Re: gnus debbugs searches?

[Maxim Cournoyer]

Hi Michael,

Michael Albinus  writes:

[...]

> The recent version in GNU ELPA is debbugs 0.42.

I've now updated it in Guix, thanks (commit 2e8a8b3ddb).

>> It seems to work for me.  M-x debbugs-gnu-guix-search RET python-team,
>> then M-x debbugs-gnu-show-last-result (that seems to be a new thing -- I
>> guess I'll check the customizations to revert to show directly the
>> results):
>
> Since debbugs 0.41, bug reports are retrieved asynchronously.
> debbugs-gnu-show-last-result switches to the result buffer (you get a
> meesage, when bug retrieval has finished).
>
> If you don't like it, set debbugs-gnu-use-threads to nil.

I see!  Thanks for the heads-up.  I'll try it for a bit more time to see
if I get used to it, otherwise it's good to know there's a means to get
the old behavior back!

-- 
Thanks,
Maxim

Re: On the quest for a new release model

[Efraim Flashner]

On Sun, Dec 15, 2024 at 03:21:44PM -0500, Suhail Singh wrote:
> Ricardo Wurmus  writes:
> 
> > Efraim Flashner  writes:
> >
> >> Since, IMO, the major uses of the actual guix package is for the daemon
> >> and the installer, I think we could tag a minor release just about every
> >> time we bump the guix package.
> 
> That's a sensible approach.  How should the discussion proceed further?
> Do we have a proxy to determine whether everyone who needs to be
> involved for consensus-based decision-making has weighed in?

I'd argue that cutting releases is one of those specifically maintainer
duties but I'd love to hear from other people who disagree.

If we do consider the daemon and installer the main reason to actually
cut a release, then I'd argue the daemon always works (we'd know
otherwise), I think we have an installer team, and we should probably
get some feedback from the desktop teams to make sure everything seems
to be working well enough.

I have some opinions about our aarch64 based images, but that should be
a separate email.

> > I've only ever signed off on one release (0.13.0?) and I'd be happy to
> > help get another one out of the door.
> 
> What does making a release entail?  Is this documented somewhere?
> 
> -- 
> Suhail

-- 
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: Make a riscv iso for Guix

[pelzflorian (Florian Pelz)]

Efraim Flashner  writes:

> On Sat, Dec 14, 2024 at 05:39:00PM -0800, R wrote:
>> It would be nice to have a fully libre distro for riscv cpus.
>
> I agree!
>
> My initial look into it suggested that, like armhf and aarch64, we'd
> need a separate image for each riscv64 board.  I eventually found this¹
> page for installing Debian on the StarFive VisionFive1 board (limited
> run, poorly supported upstream), which suggested that the vendor u-boot
> image should be able to load an EFI image and boot that way.
>
> Playing with this is high on my todo list.
>
> ¹ https://wiki.debian.org/InstallingDebianOn/StarFive/VisionFiveV1

Guix too has such a Visionfive image but for V2.  It works, although
last time `guix pull` failed for me, but I believe pull randomly
succeeds on some days.

https://guix.gnu.org/download/latest/

Regards,
Florian

GNU Manuals in Info/HTML format via Guix?

[Jeremy Bryant]

Hi Guix developers,

The GNU Project's documentation format is Texinfo.
How about distributing some or many Texinfo manuals through Guix, is
this something that is consistent with previous norms in Guix?

Following a discussion on emacs-devel, several people suggested that
GNU Guix may be a a good way to contemplate this distribution mechanism,
for obvious GNU-related reasons.

We discussed both a comprehensive solution for Info manuals, as well as
specific cases such as RMS's C manual (c.info) which is not part of a
software project.

WDYT?

Re: GNU Manuals in Info/HTML format via Guix?

[Cayetano Santos]

>dim. 15 déc. 2024 at 22:34, Jeremy Bryant  wrote:

> Following a discussion on emacs-devel, several people suggested that
> GNU Guix may be a a good way to contemplate this distribution mechanism,
> for obvious GNU-related reasons.

Remember you always have the possibility to create a dedicated guix
channel, external but complementary to guix upstream itself, to
distribute manuals. This would about any additional overload on guix
maintenance tasks.

--
Cayetano Santos
GnuPG Key:   https://meta.sr.ht/~csantosb.pgp
FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682


signature.asc
Description: PGP signature

Re: Guix (and Guile's) promise, and how to (hopefully) get there

[Maxim Cournoyer]

Hi Ricardo

Ricardo Wurmus  writes:

> Divya Ranjan  writes:
>
>> Similarly, I would suggest the thoughts on improving Guix/Guile to
>> look at aspects of the project where we might not be doing the best
>> job, or if we can take different steps in terms of reachout. But as an
>> user and contributor, please don’t take steps to separate Guix from
>> GNU. It’ll be a considerable loss too both the projects.
>
> Some of the parts of GNU that really matter to us as Guix are presented
> at .  The philosophy that was thought up and
> manifested in the early GNU project is what continues to inform our
> technical decisions today: e.g. no distinction between admins and users,
> making software freedom a practical rather than hypothetical freedom,
> giving people [not just developers] the tools to take charge of their
> software needs, etc.
>
> Those of us who have had the displeasure of dealing with the
> *organization* that is called GNU (for example in their role as
> maintainers), however, find it hamstrung by authoritarian governance,
> dominated by a few loud cranks who are given limitless influence in all
> internal discussions, and see their work devalued by tonedeaf statements
> and actions.

> I'm someone who came to Guix because of Scheme and GNU, but as the years
> went on I stayed in *spite* of the association with the entity that GNU
> is now -- luckily, Guix (and with the select links to hackers in other
> GNU-affiliated projects) is a much better embodiment of the early GNU
> philosophy than GNU itself.  That the GNU-internal mailing list that
> contributed significantly to this shift has no public archives is both
> an immeasurable blessing and a curse.

While I guess this list may feel a bit like the Far West at times (I
seldomly participate in it), in that there's little moderation and a few
individuals have loud opinions, I don't think it's fair to label the GNU
people/organization as a whole according to the impression/experience
you've had in this private list.  Most if not all of the interactions
I've had with GNU/FSF people in the last few years have been cordial and
constructive (I'm thinking of the people maintaining the infrastructure,
e.g. on the #savannah channel on IRC or the GNU Debbugs folks, of the
FSF staff sometimes communicating with us co-maintainers, of the Emacs
and other GNU packages people I've dealt with when
reporting/investigating bugs with them, the Linux-libre people, etc.).

I haven't tried convincing the GNU people to review/change their
governance structure, though, which I'm sure would need to be made with
a lot of tact and humility to avoid the issue becoming a "us vs them"
situation.

-- 
Thanks,
Maxim

Re: 01/04: gnu: libtorrent-rasterbar: Update to 2.0.10.

[Maxim Cournoyer]

Hi,

Attila Lendvai  writes:

>> PAGER= git log --author=felix.lechner | wc -l
>> 823
>
> $ PAGER= git log --oneline --author=felix.lechner | wc -l
> 62

Thank you, the --oneline is indeed mandatory to have a proper line count
here :-).  62 is still a lot!

I do believe that committers willing to review and merge others' work is
probably the most impactful way to help Guix grow and maintain pace, so
if someone is frustrated by untimely review/merge of contributions, the
I'd suggest to them to try and become a committer (finding the support
of 3 vouchers) so they can help in reviewing/mergig the work of others
and keep the stack of contributed patches under control.

-- 
Thanks,
Maxim

Re: On the quest for a new release model

[Maxim Cournoyer]

Hi,

Efraim Flashner  writes:

> On Sun, Dec 15, 2024 at 03:21:44PM -0500, Suhail Singh wrote:
>> Ricardo Wurmus  writes:
>>
>> > Efraim Flashner  writes:
>> >
>> >> Since, IMO, the major uses of the actual guix package is for the daemon
>> >> and the installer, I think we could tag a minor release just about every
>> >> time we bump the guix package.
>>
>> That's a sensible approach.  How should the discussion proceed further?
>> Do we have a proxy to determine whether everyone who needs to be
>> involved for consensus-based decision-making has weighed in?
>
> I'd argue that cutting releases is one of those specifically maintainer
> duties but I'd love to hear from other people who disagree.

I'd tend to agree.  A maintainer who doesn't cut releases or organize to
make them happen is a poor maintainer (hello!).

> If we do consider the daemon and installer the main reason to actually
> cut a release, then I'd argue the daemon always works (we'd know
> otherwise), I think we have an installer team, and we should probably
> get some feedback from the desktop teams to make sure everything seems
> to be working well enough.
>
> I have some opinions about our aarch64 based images, but that should be
> a separate email.

I think one reason I'm so turned off from attempting to produce a
release is mainly the very high standard that Ludovic has set for
releases (hats off!), which is quite a lot of tedious work:

1. Comb thousands of commits (and since it'd been 2 years, more like
tens of thousands of them) to find news worthy items to put in the
NEWS.org file (which goes in the eventual announcement email)

2. Write a new blog post for the release, with the above information,
and often more detailed explanation on new features.

3. The challenging/labor intensive integration work such of attempting
to fix all system tests which often bitrot due to not so many people
(myself included) routinely running them and noticing (it's so costly to
do so, I can't really fault them), though I/we should register to the CI
notifications for the 'tests' job, that'd help keeping track of new
failures.

4. Some arcane Perl tool that needs to patch is used to produce the
final release email/upload artifacts, IIRC.  We should have better tools
than that.

5. I remember it to be very time consuming to try to just produce the
release artifacts for all platforms, building the current Guix then the
nested Guix for all targeted architectures.  If it fails, you're in for
a new lengthy round as the process must be started over ('make
release').

6. And of course, since a Guix release is mostly useful for people
installing it on foreign distributions or as fresh Guix System
installations, testing this is important, but also labor intensive
manual work.

If we can agree that producing a release with lowered expectations is
better than producing none, I don't mind to get the ball going.  I'd
drop the combing of thousands of commits for one thing, focusing just on
what's in our etc/news.scm file, or what is on the top of my head.  The
blog post may be spartan, with little backstory or examples.  The email
announcement email may not match the GNU release format, until we get to
rewrite the tool to match our multi-artifacts requirements (in Scheme,
of course).  Testing may have been mostly left to testers out there that
have foreign systems or VMs to experiment with, or the time to install
Guix from scratch using the installer.  A best effort would be done to
fix as many tests before releasing, without the promise of fixing them
all.

Parties interested in refining the release process can have a look at
the 'release' target of our Makefile.am file at the root of the Guix
repo, or at the doc/release.org file in the guix-maintenance repo.

Long term I think I'd like to see for releases:

1. Simplicity - just a tag, release email, artififact uploads may be
good enough, if we release often.

2. Automation - We already have many things automated, but it could be
polished a bit more (such as a better tool to produce the announcement
email), and perhaps some way to automatically test that a Guix istalled
via guix-install.sh' in various environments work (perhaps Docker could
help with that, having readily minimal images of Debian, Ubuntu, Fedora,
etc. to run our script on).

3. Frequency - we want to release often

-- 
Thanks,
Maxim

Re: work-in-progress team branches

[Maxim Cournoyer]

Hello,

Christopher Baines  writes:

[...]

>> Does the following doc addition makes sense?  I've placed it at the end
>> of the 'Managing Patches and Branches' section:
>>
>> --8<---cut here---start->8---
>> 1 file changed, 11 insertions(+)
>> doc/contributing.texi | 11 +++
>>
>> modified   doc/contributing.texi
>> @@ -2362,6 +2362,17 @@ Managing Patches and Branches
>>  Once the branch has been merged, the issue should be closed and the
>>  branch deleted.
>>  
>> +@cindex work-in-progress branches, wip
>> +@cindex wip branches
>> +Sometimes, branches may be a work in progress, for example, for larger
>> +efforts such as updating the GNOME desktop.  For such cases, the branch
>> +name should reflect this by having the ``wip-'' prefix.  The QA
>> +infrastructure will avoid building work-in-progress branches, so that
>> +the available resources can be better focused on building the branches
>> +that are ready to me merged.  When the branch is not longer a work in
>> +progress, it should be renamed, with the ``wip-`` prefix removed, and
>> +only then should the merge requests be created, as documented earlier.
>> +
>>  @node Debbugs User Interfaces
>>  @subsection Debbugs User Interfaces
>> --8<---cut here---end--->8---
>
> Yep, sounds reasonable.

Great, I've fixed a few typos and pushed as
097de97982f328a79394b197d3836842bcfbac44.

-- 
Thanks,
Maxim

Re: On the quest for a new release model

[pelzflorian (Florian Pelz)]

Ricardo Wurmus  writes:
> Efraim Flashner  writes:
>> Lets make releases boring :)
>
> I'm a very boring person, so this deeply resonates with me.
>
> No matter if people agree with this or not, I think we should get a new
> release out very soon.  Do you know of anyone who volunteered to
> shepherd the upcoming release?  I've only ever signed off on one release
> (0.13.0?) and I'd be happy to help get another one out of the door.

Ludo asked at


and even though there were responses, there was no drive.

I will *not* be working on it, but one perhaps blocking issue might be
failing tests on Debian:

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

Regards,
Florian

Re: Make a riscv iso for Guix

[Efraim Flashner]

On Sat, Dec 14, 2024 at 05:39:00PM -0800, R wrote:
> It would be nice to have a fully libre distro for riscv cpus.

I agree!

My initial look into it suggested that, like armhf and aarch64, we'd
need a separate image for each riscv64 board.  I eventually found this¹
page for installing Debian on the StarFive VisionFive1 board (limited
run, poorly supported upstream), which suggested that the vendor u-boot
image should be able to load an EFI image and boot that way.

Playing with this is high on my todo list.

¹ https://wiki.debian.org/InstallingDebianOn/StarFive/VisionFiveV1

-- 
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: On the quest for a new release model

[Ricardo Wurmus]

"pelzflorian (Florian Pelz)"  writes:

> Ricardo Wurmus  writes:
>> Efraim Flashner  writes:
>>> Lets make releases boring :)
>>
>> I'm a very boring person, so this deeply resonates with me.
>>
>> No matter if people agree with this or not, I think we should get a new
>> release out very soon.  Do you know of anyone who volunteered to
>> shepherd the upcoming release?  I've only ever signed off on one release
>> (0.13.0?) and I'd be happy to help get another one out of the door.
>
> Ludo asked at
> 
> 
> and even though there were responses, there was no drive.
>
> I will *not* be working on it, but one perhaps blocking issue might be
> failing tests on Debian:
>
> https://issues.guix.gnu.org/69518

With the recent merge of the python-team branch a lot of packages are
now broken, so I suggest scheduling another python-team branch merge
before a release can possibly be made.

I'll be pushing to the python-team branch with some fixes (and likely
some new breakage) soon.  We're at a point with Python packages that we
cannot delay upgrades anymore, so whenever a fix requires an upgrade and
that creates ripples that necessitate more upgrades we should keep
applying them.

-- 
Ricardo

Re: On the quest for a new release model

[Suhail Singh]

Maxim Cournoyer  writes:

> If we can agree that producing a release with lowered expectations is
> better than producing none, I don't mind to get the ball going.

I think it would be helpful to consider our approach for the upcoming
release distinctly from what we choose to do for subsequent releases.
It would help to hear Ludo's thoughts regarding the upcoming release.

> Long term I think I'd like to see for releases:
>
> 1. Simplicity - just a tag, release email, artififact uploads may be
> good enough, if we release often.
>
> 2. Automation - We already have many things automated, but it could be
> polished a bit more (such as a better tool to produce the announcement
> email), and perhaps some way to automatically test that a Guix istalled
> via guix-install.sh' in various environments work (perhaps Docker could
> help with that, having readily minimal images of Debian, Ubuntu, Fedora,
> etc. to run our script on).
>
> 3. Frequency - we want to release often

Agreed on all points, but especially frequency (3).  If we aim for that,
feasibility and practicality will encourage 1 and 2.

-- 
Suhail

Re: Make a riscv iso for Guix

[Efraim Flashner]

On Mon, Dec 16, 2024 at 05:05:09PM +0100, pelzflorian (Florian Pelz) wrote:
> Efraim Flashner  writes:
> 
> > On Sat, Dec 14, 2024 at 05:39:00PM -0800, R wrote:
> >> It would be nice to have a fully libre distro for riscv cpus.
> >
> > I agree!
> >
> > My initial look into it suggested that, like armhf and aarch64, we'd
> > need a separate image for each riscv64 board.  I eventually found this¹
> > page for installing Debian on the StarFive VisionFive1 board (limited
> > run, poorly supported upstream), which suggested that the vendor u-boot
> > image should be able to load an EFI image and boot that way.
> >
> > Playing with this is high on my todo list.
> >
> > ¹ https://wiki.debian.org/InstallingDebianOn/StarFive/VisionFiveV1
> 
> Guix too has such a Visionfive image but for V2.  It works, although
> last time `guix pull` failed for me, but I believe pull randomly
> succeeds on some days.
> 
> https://guix.gnu.org/download/latest/

I should try that image again on my visionfive2.  The last time I tried
it the board wasn't stable, but it might've been the SDcard I was using.
The last round of power blips we had I corrupted the SDcard in my
unmatched board so I had to rebuild it, but now I can actually run guix
deploy to update it.

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