Re: Rust-team branch status?

[Efraim Flashner]

On Tue, Jun 25, 2024 at 08:48:12AM -0700, Ian Eure wrote:
> Hi Efraim,
> 
> Efraim Flashner  writes:
> 
> > [[PGP Signed Part:Undecided]]
> > On Thu, Jun 20, 2024 at 05:10:11PM -0700, Ian Eure wrote:
> > > Hi Guixers,
> > > 
> > > I want to update the Librewolf package, but it now depends on Rust
> > > >= 1.76, which is newer than what's in master.  I see the >rust-team
> > > branch has versions up to 1.77 — is there a timeline for merging
> > > that, or a TODO list of things that need to be done to merge it?
> > > I'm not sure if I can help there, but would rather direct efforts
> > > towards getting rust updated than patching Librewolf to build with
> > > older versions.
> > 
> > I managed to burn myself out on rust stuff a few months ago and I'm
> > finally coming back to the rust-team branch.  There are still hundreds
> > of patches sent for the branch which I had hoped to catch-up on, but I'm
> > fairly certain that the branch is in a good state for merging even now.
> > 
> > Currently it has rust-1.77.1.  There is a newer 1.77.2 available, and
> > the newest version is 1.79.  After merging the current branch I hope to
> > be able to move the version of rust on the rust-team branch to whatever
> > the latest version is.
> > 
> I’m very sorry to hear that you’re feeling burnt out.
> 
> Would it be reasonable to merge the newer Rust versions, without changing
> the default from 1.75?  That would unblock things needing them, without the
> risk of breaking packages which haven’t been updated.
> 
> This might not work for other packages, but Guix seems to keep nearly every
> version of Rust around for bootstrapping the new ones, so I think this would
> work.

I'll see about backporting(?) the newer rust versions from the rust-team
branch to the master branch. That way they are available for things like
librewolf even if they aren't used for the actual rust packages yet. It
shouldn't be too hard and I can make sure it doesn't cause problems on
the rust-team branch, even thought it has to wait a bit until its turn
to merge.

-- 
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: Rust-team branch status?

[Efraim Flashner]

On Wed, Jun 26, 2024 at 10:46:56AM +0300, Efraim Flashner wrote:
> On Tue, Jun 25, 2024 at 08:48:12AM -0700, Ian Eure wrote:
> > Hi Efraim,
> > 
> > Efraim Flashner  writes:
> > 
> > > [[PGP Signed Part:Undecided]]
> > > On Thu, Jun 20, 2024 at 05:10:11PM -0700, Ian Eure wrote:
> > > > Hi Guixers,
> > > > 
> > > > I want to update the Librewolf package, but it now depends on Rust
> > > > >= 1.76, which is newer than what's in master.  I see the >rust-team
> > > > branch has versions up to 1.77 — is there a timeline for merging
> > > > that, or a TODO list of things that need to be done to merge it?
> > > > I'm not sure if I can help there, but would rather direct efforts
> > > > towards getting rust updated than patching Librewolf to build with
> > > > older versions.
> > > 
> > > I managed to burn myself out on rust stuff a few months ago and I'm
> > > finally coming back to the rust-team branch.  There are still hundreds
> > > of patches sent for the branch which I had hoped to catch-up on, but I'm
> > > fairly certain that the branch is in a good state for merging even now.
> > > 
> > > Currently it has rust-1.77.1.  There is a newer 1.77.2 available, and
> > > the newest version is 1.79.  After merging the current branch I hope to
> > > be able to move the version of rust on the rust-team branch to whatever
> > > the latest version is.
> > > 
> > I’m very sorry to hear that you’re feeling burnt out.
> > 
> > Would it be reasonable to merge the newer Rust versions, without changing
> > the default from 1.75?  That would unblock things needing them, without the
> > risk of breaking packages which haven’t been updated.
> > 
> > This might not work for other packages, but Guix seems to keep nearly every
> > version of Rust around for bootstrapping the new ones, so I think this would
> > work.
> 
> I'll see about backporting(?) the newer rust versions from the rust-team
> branch to the master branch. That way they are available for things like
> librewolf even if they aren't used for the actual rust packages yet. It
> shouldn't be too hard and I can make sure it doesn't cause problems on
> the rust-team branch, even thought it has to wait a bit until its turn
> to merge.

I've pushed through rust-1.79 to master and I've built them on x86_64.
My fast aarch64 build machine is currently offline so I can't test there
and builds are ongoing on riscv64. The packages are public but hidden,
so they can be pulled into a package definition if required (as
rust-1.79) but can't be installed with a simple 'guix package -i rust'.


-- 
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: An IRC bot called Peanuts

[Leo Famulari]

On Tue, Jun 25, 2024 at 01:56:44PM -0700, Felix Lechner via Development of GNU 
Guix and the GNU System distribution. wrote:
> Today I received this private message:
> 
> "hey, as i said before, your bot "peanuts" is fucking
> annoying. it floods the channel too much. the only feature i find
> useful is "bug !12345" but other than that it's just stupid and
> annoying. please fix asap."

It's an opinion. I wish that whoever said that would have said it in a
more friendly way. We try to avoid communicating so harshly within Guix
and I hope they learn to do that.

> Unless anyone expresses appreciation, I plan to turn the bot off in the
> near future.

I like when it shares links to bug tickets and commits. But sometimes,
it echoes links that have already been sent, even in direct response to
the links. For some of us, it's obvious where to find that info, but
others may have no idea. I wonder if it could learn a more sophisticated
way to decide when to share the links or not, and maybe to condense the
information a bit.

GNU Shepherd 0.10.5 released

[Ludovic Courtès]

We are pleased to announce the GNU Shepherd version 0.10.5, a bug-fix
release of the 0.10.x series, representing 5 commits over 3 months.

The 0.10.x series is a major overhaul towards 1.0.  The current ‘devel’
branch provides new features and significant user interface
improvements; it will become 1.0 in the coming weeks or months.


• About

  The GNU Shepherd is a service manager written in Guile that looks
  after the herd of daemons running on the system.  It can be used as an
  “init” system (PID 1) and also by unprivileged users to manage
  per-user daemons—e.g., tor, privoxy, mcron.  It supports several
  daemon startup mechanisms, including inetd and systemd-style socket
  activation.  The GNU Shepherd is configured in Guile Scheme and can be
  extended in the same language.  It builds on a simple memory-safe and
  callback-free programming model.

  The GNU Shepherd is developed jointly with the GNU Guix project; it is
  used as the init system of Guix, GNU’s advanced GNU/Linux distribution.

  https://www.gnu.org/software/shepherd/


• Download

  For a summary of changes and contributors, see:
https://git.sv.gnu.org/gitweb/?p=shepherd.git;a=shortlog;h=v0.10.5
  or run this command from a git-cloned shepherd directory:
git shortlog v0.10.4..v0.10.5

  Here are the compressed sources and a GPG detached signature:
https://ftp.gnu.org/gnu/shepherd/shepherd-0.10.5.tar.gz
https://ftp.gnu.org/gnu/shepherd/shepherd-0.10.5.tar.gz.sig

  Use a mirror for higher download bandwidth:
https://ftpmirror.gnu.org/shepherd/shepherd-0.10.5.tar.gz
https://ftpmirror.gnu.org/shepherd/shepherd-0.10.5.tar.gz.sig

  Here are the SHA1 and SHA256 checksums:

5a00d408660ba02098f6db75f6192c1ee8d1d5c3  shepherd-0.10.5.tar.gz
ncg4eLxPnCIoHU7mwn4SgzT4TkFB6UiSw7nkUnGygEw=  shepherd-0.10.5.tar.gz

  Verify the base64 SHA256 checksum with cksum -a sha256 --check
  from coreutils-9.2 or OpenBSD's cksum since 2007.

  Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:

gpg --verify shepherd-0.10.5.tar.gz.sig

  The signature should match the fingerprint of the following key:

pub   rsa4096 2014-08-11 [SC]
  3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
uid   [  undef ] Ludovic Courtès 
uid   [  undef ] Ludovic Courtès 
uid   [  undef ] Ludovic Courtès (Inria) 

  If that command fails because you don't have the required public key,
  or that public key has expired, try the following commands to retrieve
  or refresh it, and then rerun the 'gpg --verify' command.

gpg --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5

  As a last resort to find the key, you can try the official GNU
  keyring:

wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify shepherd-0.10.5.tar.gz.sig

  This release was bootstrapped with the following tools:
Autoconf 2.71
Automake 1.16.5
Gettext 0.21
Makeinfo 7.1

• Changes since version 0.10.4 (excerpt from the NEWS file)

  ** ‘herd unload root SERVICE’ no longer hangs when there’s a replacement
 ()

  It used to be that, for a running service S that has a replacement registered,
  ‘herd unload root S’ would hang shepherd, making it totally unresponsive—‘herd
  status’, ‘halt’, etc. would hang forever, and inetd-style services would no
  longer start, etc.  This is now fixed.


Please report bugs to bug-g...@gnu.org.
Join guix-devel@gnu.org for discussions.

Ludovic, on behalf of the Shepherd herd.


signature.asc
Description: PGP signature

Re: An IRC bot called Peanuts

[Juliana Sims]

Hi Felix,

Firstly, I feel this person could and should have expressed their 
frustration in a more polite way. I'm sorry someone has taken to using 
such fierce and critical language for something you've worked on. I 
hope that you're not too hurt by their rudeness.


Secondly, I quite like peanuts. It's handy to get an idea of where a 
link will take me before being taken there (and potentially 
misunderstanding a link or wasting my time waiting on a page to load 
just to find out what an uninformative URL points to), and it's handy 
to have references to Guix issue and patch numbers automatically turned 
into links to those issues and patches.


As a final note, for the rest of the folks reading guix-devel: please 
don't cuss at people about their work, nor use ableist insults to 
describe it, please (nor do those things *at people themselves*, though 
I trust y'all to know better than that already). Criticism is good and 
should be couched in polite, ideally positive terms (eg "I find peanuts 
annoying; could you reduce or eliminate its output?" would have been a 
better approach).


All the best,
Juli

Re: Rust-team branch status?

[Ian Eure]

Efraim Flashner  writes:


[[PGP Signed Part:Undecided]]
On Wed, Jun 26, 2024 at 10:46:56AM +0300, Efraim Flashner wrote:

On Tue, Jun 25, 2024 at 08:48:12AM -0700, Ian Eure wrote:
> Hi Efraim,
> 
> Efraim Flashner  writes:
> 
> > [[PGP Signed Part:Undecided]]

> > On Thu, Jun 20, 2024 at 05:10:11PM -0700, Ian Eure wrote:
> > > Hi Guixers,
> > > 
> > > I want to update the Librewolf package, but it now 
> > > depends on Rust
> > > >= 1.76, which is newer than what's in master.  I see the 
> > > >>rust-team
> > > branch has versions up to 1.77 — is there a timeline for 
> > > merging
> > > that, or a TODO list of things that need to be done to 
> > > merge it?
> > > I'm not sure if I can help there, but would rather direct 
> > > efforts
> > > towards getting rust updated than patching Librewolf to 
> > > build with

> > > older versions.
> > 
> > I managed to burn myself out on rust stuff a few months ago 
> > and I'm
> > finally coming back to the rust-team branch.  There are 
> > still hundreds
> > of patches sent for the branch which I had hoped to 
> > catch-up on, but I'm
> > fairly certain that the branch is in a good state for 
> > merging even now.
> > 
> > Currently it has rust-1.77.1.  There is a newer 1.77.2 
> > available, and
> > the newest version is 1.79.  After merging the current 
> > branch I hope to
> > be able to move the version of rust on the rust-team branch 
> > to whatever

> > the latest version is.
> > 
> I’m very sorry to hear that you’re feeling burnt out.
> 
> Would it be reasonable to merge the newer Rust versions, 
> without changing
> the default from 1.75?  That would unblock things needing 
> them, without the

> risk of breaking packages which haven’t been updated.
> 
> This might not work for other packages, but Guix seems to 
> keep nearly every
> version of Rust around for bootstrapping the new ones, so I 
> think this would

> work.

I'll see about backporting(?) the newer rust versions from the 
rust-team
branch to the master branch. That way they are available for 
things like
librewolf even if they aren't used for the actual rust packages 
yet. It
shouldn't be too hard and I can make sure it doesn't cause 
problems on
the rust-team branch, even thought it has to wait a bit until 
its turn

to merge.


I've pushed through rust-1.79 to master and I've built them on 
x86_64.
My fast aarch64 build machine is currently offline so I can't 
test there
and builds are ongoing on riscv64. The packages are public but 
hidden,

so they can be pulled into a package definition if required (as
rust-1.79) but can't be installed with a simple 'guix package -i 
rust'.



Wonderful, thank you very much for the quick turnaround!

I know next to nothing about Rust, but if there’s something that 
would help the rust-team branch, please let met know.


Thanks,

 — Ian

ci.guix.gnu.org homepage is down

[Ada Stevenson]

Hi Guix,

I just wanted to send an email out to let people know that the homepage 
of CI, ci.guix.gnu.org, is down. It returns a 504 Gateway Timeout error.


I was looking to see what was causing the build failure of 
linux-libre@6.9.6, which is when I found I couldn't access it still. I 
had tried two days ago to access it too, and it had the same error then.


Hopefully the sysadmins can look into this! Thank you for all the work 
you put into making sure things work behind the scenes :-)


Warmly,
Ada