Hi Ludovic,
Ludovic Courtès writes:
> Following discussions on IRC, I’ve created a new ‘ungrafting’ branch
> that does nothing but ungraft things.
>
> The rationale is that grafts incur additional overhead when installing
> things (the time to create those grafts), so it’s good to clean them up
Yes, translations should now go through weblate, at
https://translate.fedoraproject.org/projects/guix/website/
We also manage the cookbook, manual, guix and packages there, though I still
need to announce it :)
Le 14 janvier 2021 16:14:35 GMT-05:00, "Ludovic Courtès" a écrit
:
>Hi,
>
>Peng Me
>> I think that's what mes-m2 rewrite [1] (not to be confused with mes wip-m2
>> branch)
>> is trying to achieve.
> Oh I see. It’s still kinda confusing to have two Mes. Wouldn’t it be
> nice to have just one?
yes it would.
Which is why a third scheme is being written in the Haskell subset we
On Thu, Jan 14, 2021 at 11:37:39PM +0100, Ricardo Wurmus wrote:
>
> Leo Famulari writes:
>
> > For i686-linux:
> >
> > Should we even be attempting to build Rust on this platform? Has it ever
> > worked? What about the ant-bootstrap?
> […]
> >580 ant-bootstrap@1.8.4
> > /gnu/store/rb0r
On Thu, Jan 14, 2021 at 09:44:17AM +0100, Mathieu Othacehe wrote:
> Your weather summary is a great idea, thanks! As I said in my previous
> email, the armhf substitutes are not built right now on the CI. It's
> really sad but we have to make an impossible choice between:
Specifically about armhf,
Leo Famulari writes:
> For i686-linux:
>
> Should we even be attempting to build Rust on this platform? Has it ever
> worked? What about the ant-bootstrap?
[…]
>580 ant-bootstrap@1.8.4
> /gnu/store/rb0r3r4vf3gd63bqinpkha9450yzvjm6-ant-bootstrap-1.8.4
This should work on i686 IIRC.
-
Hi,
zimoun skribis:
> Using Guix 957f0c4 or 0d3f271, I get:
>
> $ guix build --help-transform | grep test
> build PACKAGE from the latest commit of BRANCH
> --without-tests=PACKAGE
[...]
> $ guix build --without-test=foo foo
> guix build: error: without-test=foo:
Mathieu Othacehe skribis:
> Since the introduction of the "wip-offload" branch on Cuirass, the
> situation has much improved. The workers are constantly building. For
> now we are building three specifications:
>
> * guix-modular-master
> * guix-master
> * staging
Yay!
> for x86_64, i686 and aa
Hi,
Mathieu Othacehe skribis:
> Your weather summary is a great idea, thanks! As I said in my previous
> email, the armhf substitutes are not built right now on the CI. It's
> really sad but we have to make an impossible choice between:
>
> * Trying to build everything on all architecture and ha
zimoun writes:
> Hi,
>
> Using Guix 957f0c4 or 0d3f271, I get:
>
> --8<---cut here---start->8---
> $ guix build --help-transform | grep test
> build PACKAGE from the latest commit of BRANCH
> --without-tests=PACKAGE
>
Hi,
Jan Nieuwenhuizen skribis:
> On current master, the disk-size setting on a childhurd has no effect,
> leaving very little disk space to do development.
>
> I am suspecting this commit
>
>> commit 859b362f81598830d7ff276b96a8724aee3c4db7
>> Author: Ludovic Courtès
>> AuthorDate: Mon Dec 7 12
Hi Ludo,
Ludovic Courtès writes:
> We could also drop gzip, but there are probably pre-1.1 daemons out
> there that understand nothing but gzip¹, so perhaps that’ll have to
> wait. Now, compressing substitutes three times may be somewhat
> unreasonable.
>
> Thoughts?
>
Is there a request log wh
Hi Guillaume,
Guillaume Le Vaillant skribis:
> I compared gzip, lzip and zstd when compressing a 580 MB pack (therefore
> containing "subsitutes" for several packages) with different compression
> levels. Maybe the results can be of some use to someone.
It’s insightful, thanks a lot!
One takea
Hi!
Andrius Štikonas skribis:
> I think that's what mes-m2 rewrite [1] (not to be confused with mes wip-m2
> branch)
> is trying to achieve.
Oh I see. It’s still kinda confusing to have two Mes. Wouldn’t it be
nice to have just one? I understand the goals are not exactly the same,
but is th
Hi,
Kei Kebreau skribis:
> Ludovic Courtès writes:
>
>> Hi Kei,
>>
>> Perhaps we can keep the .pc file for libmad, adding a comment mentioning
>> what you wrote above, but remove it in those cases where it’s not needed
>> (as in: not required by Audacity & co., and not done in other distros)?
>
Hi Magali,
Magali skribis:
> As you might know, as part of my Outreachy internship I'm currently
> working on implementing the subcommand 'guix git log', for browsing the
> history of all packages. So far, it works with '--oneline' and
> '--format=', and FORMAT can be 'oneline', 'medium' or 'ful
Hi,
Christopher Baines skribis:
> Something I noticed when looking at things guix.cbaines.net failed to
> build, is that some failures were because a fixed output derivation had
> failed (because of a 404 or hash mismatch for example).
>
> I've got around to adding a page to the Guix Data Servic
Hi,
Peng Mei Yu skribis:
> Can I apply for commit access to guix-artwork.git? I may make changes
> to the Chinese translation and fix small bugs like this one:
> https://issues.guix.gnu.org/45416.
My understanding is that translations will now be hosted elsewhere, with
the on-going migration t
Mathieu,
Mathieu Othacehe 写道：
As I said, the new remote building Cuirass mechanism is not yet
deployed
on those machines and I would need someone with login access to
reconfigure those machines for me.
I reconfigured dmitri and have now also restarted guix-daemon.
Is there anything more I ne
Very important reply:
Tobias Geerinckx-Rice 写道：
Drawing a coloured \ behind the uncoloured / of the S
Of course I meant this the other way 'round.
Of course,
T G-R
signature.asc
Description: PGP signature
Luis, Mathieu,
Luis Felipe 写道：
Like the others I prefer the orange/black colour scheme. It
integrates better with other Guix sites & the other one has
less positive connotiations.
Oh, really?! I know people associate these colors to political
parties and sports teams depending on the region
‐‐‐ Original Message ‐‐‐
On Tuesday, January 12, 2021 10:58 AM, Mathieu Othacehe
wrote:
> If there are no more voters, it looks like the 2B logo with the orange
> logo is the winner!
I just sent a patch with the source files (https://issues.guix.gnu.org/45863).
Let me know if you need
Hello Jonathan,
> I can not speak for Nix, but openSUSE has around 10 more or less powerful ARM
> servers for native building. See https://build.opensuse.org/monitor
Thanks for sharing, I like very much the design of this page, I might
take some ideas from it to improve https://ci.guix.gnu.org
Hi,
Using Guix 957f0c4 or 0d3f271, I get:
--8<---cut here---start->8---
$ guix build --help-transform | grep test
build PACKAGE from the latest commit of BRANCH
--without-tests=PACKAGE
build PACKAGE withou
Hi Mathieu,
I have not read carefully all the emails on the topic, so I am
probably out-of-scope.
On Thu, 14 Jan 2021 at 09:44, Mathieu Othacehe wrote:
> * Trying to build everything on all architecture and have the CI that is
> awfully lagging behind.
>
> * Restrict the number of architectur
Hello Guix!
I was able to successfully package and build the telegram-desktop
(tdesktop). The patch-set can be found at
https://issues.guix.gnu.org/issue/45721 (v8 is the latest).
But I am unable to successfully launch the application. Could anyone of
you, if available, please try the packag
Hello Tobias,
> I don't think it's obvious and I don't think it's true.
Well obvious was a poor choice of word. But I've been spending several
weeks/months monitoring Berlin and I think I'm starting to have a good
overview of the situation.
This new page[1] shows what the build machines are do
Mathieu!
Mathieu Othacehe 写道：
Longer term, we need to figure out a better solution. It's now
obvious that we do not have the computation power to build all
our
branches for 5 different architectures
I don't think it's obvious and I don't think it's true.
relying heavily on emulation for ar
Am Thu, 14 Jan 2021 09:39:41 +0100, Mathieu Othacehe schrieb:
> First, I still need to connect the four overdrives machine to the new
> Cuirass remote building mechanism, and I would need some help for that
> (asked on guix-sysadmins). But, I'm not sure it will much improve the
> situation.
>
> Lon
> The armhf-linux platform is in the worst shape, both on the master and
> staging branches. It's a shame because it's also the least powerful,
> with almost no hardware thermally capable of sustained CPU usage, so
> users will have the worst experience building packages for it.
>
> Does anyone w
Hello Leo,
> --
> master branch
> aarch64: 66%
> x86_64: 93%
> i686: 85%
> armhf: 51%
>
> staging branch
> aarch64: 44%
> x86_64: 80%
> i686: 60%
> armhf: 30%
> --
Thanks for the figures. I can comment on some stuff. Until recently it
was hard to monitor the build farm status becaus
31 matches
Mail list logo
