Rename GNU Jami Package in Guix?

Hello Guix! As per jami.net, it appears GNU Jami is cross-platform and desktop- environment independent. The Jami package in Guix is named as "jami- client-gnome", which is misleading that it can only be used with GNOME. So shouldn't the package be renamed to just "jami"? Thank you! Regards,

Re: [core-updates] Due to flawed bootstrap tarball, full rebuild needed

Marius Bakke writes: > Chris Marusich writes: > >> Mark H Weaver writes: >> >>> It turns out that the MesCC bootstrap tarball includes store references, >>> and moreover it references a different store item than the MesCC >>> bootstrap tarball that I built locally on my own machine. See >>>

Re: Mumi now uses raw emails and Mu

Ricardo, On Sun, 21 Jul 2019, Ricardo Wurmus wrote: Hey there, I just wanted to let y’all know that Mumi at issues.guix.gnu.org now stores raw emails from Debbugs instead of fetching them through the Debbugs SOAP service. This means that messages are no longer truncated, which is what

Re: [core-updates] Due to flawed bootstrap tarball, full rebuild needed

Chris Marusich writes: > Mark H Weaver writes: > >> It turns out that the MesCC bootstrap tarball includes store references, >> and moreover it references a different store item than the MesCC >> bootstrap tarball that I built locally on my own machine. See >>

Re: [core-updates] Due to flawed bootstrap tarball, full rebuild needed

Mark H Weaver writes: > It turns out that the MesCC bootstrap tarball includes store references, > and moreover it references a different store item than the MesCC > bootstrap tarball that I built locally on my own machine. See > for details and a

Mumi now uses raw emails and Mu

Hey there, I just wanted to let y’all know that Mumi at issues.guix.gnu.org now stores raw emails from Debbugs instead of fetching them through the Debbugs SOAP service. This means that messages are no longer truncated, which is what happened to some multipart messages in the past. While I

Re: Rust 1.19 fails to build on i686 on ‘staging’

Chris Marusich writes: > Danny Milosavljevic writes: > >> can we give thepowersgang (author of mrustc) an ssh account on a guix machine >> reachable from the internet, for debugging this problem? >> >> It would be good if "guix build -K" kept the sources on that machine. > > Is/are the

Re: bug#36685: ant-bootstrap fails on core-updates (409 dependents)

Efraim Flashner writes: > currently on bayfront on core-updates ant-bootstrap builds just fine on > i686-linux, where it fails on master. Another option could be to > bootstrap 32 bit -> 64 bit This would be possible, but I consider it a last resort and would very much like to avoid having to

Re: [core-updates] Due to flawed bootstrap tarball, full rebuild needed

Mark H Weaver writes: > It turns out that the MesCC bootstrap tarball includes store references, > and moreover it references a different store item than the MesCC > bootstrap tarball that I built locally on my own machine. See > for details and a

Re: bug#36685: ant-bootstrap fails on core-updates (409 dependents)

Hello, Ricardo Wurmus ezt írta (időpont: 2019. júl. 21., Vas 13:29): > So, with the following change I was able to build all the way up to the > latest openjdk. Should we use it despite the introduction of a memory > leak in a bootstrap JVM? Can we make the patch smaller (fewer uses of >

[core-updates] Due to flawed bootstrap tarball, full rebuild needed

Hello Guix, It turns out that the MesCC bootstrap tarball includes store references, and moreover it references a different store item than the MesCC bootstrap tarball that I built locally on my own machine. See for details and a proposed patch from

[core-updates] Should we patch icu4c?

Node's "parallel/test-intl" fails on the 'core-updates' branch when built for i686-linux: --8<---cut here---start->8--- not ok 1254 parallel/test-intl --- duration_ms: 1.308 severity: fail exitcode: 1 stack: |- assert.js:738 throw newErr;

Re: bug#36685: ant-bootstrap fails on core-updates (409 dependents)

So, with the following change I was able to build all the way up to the latest openjdk. Should we use it despite the introduction of a memory leak in a bootstrap JVM? Can we make the patch smaller (fewer uses of glibc 2.28 or gcc-5)? What do you think? diff --git a/gnu/packages/java.scm

Re: IceWeasel-UXP and IceDove-UXP

guixuser transcribed 680 bytes: > > > To be fair, > > > > - iceweasel-uxp has a different engine than icecat. > > - There is no good email client like thunderbird. I'm stuck with > > claws-mail, and I reallly don't like it. icedove-uxp would be a good > > addition. > > Exactly. > >