Re: Fallout from recent nss-certs changes

Ian Eure writes: > The change is mentioned in the channel news, but it says nothing about > needing to remove that part of the config. You are right; I have added more explicit instructions as commit e5c0ea22e68cc8d6f99957295bc9198afb8455df. Users should see it when they guix pull again.

Re: Should we include nss-certs out of the box?

Fabio Natali writes: > For what it's worth, I put together a micro-patch and sent it over as a > follow-up to #70451. Pushed as 67a3a83170c038d2eb084d3f53a7ea7b033aea74. Thank you! Regards, Florian

Re: [PATCH] Fix typo (Re: Feedback of the GNU Guix manual)

Pushed as b8ccbc942e0ec7baf695d383e575991289c6e033. Thank you for trudging on through the list. Regards, Florian

Re: Fallout from recent nss-certs changes

Hello Ian. My understanding of the nss-certs etc/news.scm item had been that we should remove (specification->package "nss-certs"), which became unnecessary and clutters config.scm. From what you write, this was actually not intended, but it is still not a bug IMHO. (I’m not involved with the

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

Hello Matt, pushed as 86fb0e039bf30cf85e2066401f9a384427c47ea8. I was bold enough to retain the xref change in (Setting Up the Daemon) prompted by Ludo, because starting a sentence with @xref is recommended in the Texinfo manual and its examples, while @pxref at the start of a phrase is not

Re: Creating a documentation team?

Ludovic Courtès writes: > Hi Florian and all, > > I figure you’ve been doing a lot of review and writing of the manual. > Should we create a documentation team, of which you could be a honorary > member? :-) Yes, please add this team for documentation. I agree and would like to be in that

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

onfusing.) Should I just cut these changes: (Linux Services): Use @pxref to start phrase. (Configuring the Shell): Use @pxref to start phrase. or is there more that should go in this patch? Matt writes: > On Mon, 15 Apr 2024 14:58:50 +0200 pelzflorian (Florian Pelz) wrote > ---

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

Matt writes: > The problem is that the Emacs Info reader incorrectly renders > cross-references by default. I was reading the Texinfo documentation > in Emacs. I believe the Emacs errors are historical; looking at Emacs 29.3 as packaged in Guix, Emacs-Info displays xref properly as See.

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

Matt writes: > The attached change updates "Libera Chat" to the "Libera.Chat" stylization. Pushed as df7b569b464c05036871f23d37ba319be78e5f64. Thanks! Regards, Florian

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

Matt writes: > #+begin_quote > 3.7 After System Installation > L27 Libera_Chat, why the underscore. It is colored as well for me so > I guess this is a special char. Should be anways just Libera Chat > #+end_quote > > "Libera_Chat" is not, or no longer, in the docs (d3fe763fe3). > However, there

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

Hello Matt. Thank you for fixing the oversight. However: Matt writes: > From: Matthew Trzcinski > Date: Sat, 13 Apr 2024 10:12:05 +0200 > Subject: [PATCH] doc: Fix cross-references > > * doc/guix.texi (Setting Up the Daemon): use @xref to start sentence. > (Build Systems): capitalize "python"

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

Pushed as cd557e2d1c83839dd587016279900d31f053efc8. Matt writes: > The next item reported is: > > #+begin_quote > 2.4 Setting up the deamon > > Seems like an issue with info. Have seen this in the Emacs manual as well. > There is also sometimes see see (doc) > > L15 See also see Substitutes.

Re: Security-Enhancement: Fine Control for guix pull --allow-downgrades

"pelzflorian (Florian Pelz)" writes: > And use ‘guix style --whole-file’ for formatting code, This was bad advice in this case, sorry. Regards, Florian

Re: Security-Enhancement: Fine Control for guix pull --allow-downgrades

Hello Rostislav. This is a good idea in my opinion, but please send the patch as a mail to guix-patc...@gnu.org. Also do not use [] for parentheses; always use (), which is Guix policy. And use ‘guix style --whole-file’ for formatting code, see the manual by running the command “info

Re: Bug#1066113: guix: CVE-2024-27297

On 2024-03-16, Vagrant Cascadian wrote: > For anyone with Guix or Nix installed, if I understand correctly, it > basically allows arbitrarily replacing the source code for anything that > you might build using Guix or Nix. Yes, for multi-user systems and people running untrusted code in “guix

Re: the right to rewrite history to rectify the past (was Re: Concerns/questions around Software Heritage Archive)

Hello all. I object to this argument: MSavoritias writes: > We are talking about social rules that we have here in the Guix > community not legal/state rules. No, legal rules come from deliberation of social arguments. CoC-wise, it seems to me that SWH was unfriendly and this is important to

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

The guix-daemon does the hashing, so guix-daemon would have to be fixed to override integrity checks (and it would have to be patched retroactively in every time-travel). Noone likes touching guix-daemon (until it is rewritten in Guile), so I can imagine it would be frustrating. Now ftfy is not

Re: doc: installation: fix ~root confusion (was Re: doc: Removing much of Binary Installation)

ints 3 > and 4 according to 2. > > On Mon, 11 Mar 2024 16:54:01 +0100 pelzflorian (Florian Pelz) wrote --- >> Yes, however the removal means that we should move the sections >> >> * 2.2 Requirements >> * 2.3 Running the Test Suite >> >>

Re: doc: installation: fix ~root confusion (was Re: doc: Removing much of Binary Installation)

Hi Matt. I would almost want to push your changes, but we still disagree on some wordings. Also, Matt writes: > I realigned the subject. It was previously changed to "doc: Removing > much of Binary Installation" which is misleading. The topic is how to > clarify installation based on

Re: doc: Removing much of Binary Installation

Hello Matt and all. As a more proper review, I first tried guix-install.sh on a Debian GNU/Hurd VM. It fails, telling me: [1709825168.049]: [ INFO ] init system is: sysv-init [1709825168.059]: [ FAIL ] Unsupported CPU type: i686-AT386 The script guix-install.sh cannot be used on any GNU/Hurd

doc: Removing much of Binary Installation (was: Feedback of the GNU Guix manual)

Thank you Matt for the suggested diff. Yes, I agree some simplification as you suggested would be beneficial, so that the description of Binary Installation looks as simple as it really is. (In particular, I have witnessed people, to whom I had suggested Guix, fail at trying Guix because they

Re: service 'term-tty2' provided more than once

Hello Felix Lechner. A workaround is in namely multiple (delete mingetty-service-type) as in (modify-services %base-services (delete login-service-type) (delete mingetty-service-type) (delete mingetty-service-type) (delete mingetty-service-type) (delete

[shepherd bug] Re: Format specification issue in the translations...

Sebastian Rasmussen writes: > I will contribute a similar translation in Swedish, but I also > want the bug in the original code fixed. > > I have attached my attempt at a patch to this mail. > Maybe someone can review it and help push it to git HEAD? Cc to Ludo with changed subject. Regards,

Re: Format specification issue in the translations...

Hi Sebastian, in German I have translated in this way and it got accepted. Although, I have not actually tested if it displays correctly. I assume Guile formatting is tolerant. #: modules/shepherd/service.scm:1087 #, scheme-format msgid "Cannot unregister service ~a, which is still running"

Re: GNU Shepherd 0.10.0rc1 available for testing!

Hi Tanguy, Tanguy LE CARROUR writes: > I did that and… I ended up with the following build error: > […] > checking if (fibers) is available... no > configure: error: Fibers is missing; please install it. Could it be that you have not run “guix pull” recently or that a wrong Guix program gets

Re: GNU Shepherd 0.10.0rc1 available for testing!

Wow, shepherd 0.10.0rc1 put an end to occasional hangups when rebooting my slow Beebox server! Thanks once more. Regards, Florian

Re: GNU Shepherd 0.10.0rc1 available for testing!

Thank you shepherds! Also the explanations in the news are great. Finally I understand why GOOPS is not desirable in shepherd. For Guix Home: Ludovic Courtès writes: > In your operating system configuration (and similarly for your > ‘home-environment’), make the following changes: For Guix

Re: Packages grow, no longer fit on a 

Hello all. Ludovic Courtès writes: > Over the course of a few years, the size of our packages has apparently > kept growing. Disregarding dependencies, most store items got slightly bigger. This is what I wrote at bug#58760 “Guix System iso too big for cdrom again”

Re: u-boot-am335x-boneblack -> u-boot-am335x-evm-boneblack

Vagrant Cascadian writes: > With all that said... having 512MB of ram, I wonder how well a > beaglebone black would do running guix at all... I used to use Guix on Debian (not Guix System) on my BeagleboneBlack. With swap space, it worked well, even though `guix pull` took multiple days to

Re: cirrus (was Re: Release progress, week 10)

Ludovic Courtès writes: > "pelzflorian (Florian Pelz)" skribis: >> That hold-up aside, maybe could you also tentatively add the cirrus >> initrd module to the 1.4.0 installation image? I suppose it won’t break >> anything, but it might help with bugs like >&g

Re: cirrus (was Re: Release progress, week 10)

"pelzflorian (Florian Pelz)" writes: > That hold-up aside, maybe could you also tentatively add the cirrus > initrd module to the 1.4.0 installation image? I suppose it won’t break > anything, but it might help with bugs like > <https://issues.guix.gnu.org/60002>. I

cirrus (was Re: Release progress, week 10)

Ludovic Courtès writes: > There are currently two installer bugs that I think now have a valid fix: > > https://issues.guix.gnu.org/60010 > https://issues.guix.gnu.org/59784 Sadly those are still not completely fixed… That hold-up aside, maybe could you also tentatively add the cirrus

Re: Packaging big generated data files?

Denis 'GNUtoo' Carikli writes: > Is there any policies or past decisions of the Guix project on > packaging big generated data files? commit 183db725a4e7ef6a0ae5170bfa0967bb2eafded7 Author: Ricardo Wurmus Date: Tue May 15 12:55:27 2018 +0200 gnu: Add r-bsgenome-dmelanogaster-ucsc-dm6.

Re: GNU Guix 1.4.0rc1 available for testing!

There are some release blockers. To summarize, IMHO it would be regrettable if these bugs were not fixed before release: * [PATCH v2 2/3] install: Add missing e2fsprogs utility. Otherwise manual installation does not work as advertised. * [version

Re: GNU Guix 1.4.0rc1 available for testing!

Hello Svante, Svante Signell writes: > What about hurd? Hurd can be used with QEMU on Linux-based Guix System; see the childhurd section in the manual. However, I tried and somewhat failed to run on my real hardware (a Beebox mini PC): When booting, the Hurd runs an rc script which freezes. I

Re: Licence of the Guix blog posts

Ludovic Courtès writes: > Therefore, I propose to apply the following patch, which leaves out a Yes! The patch looks good. I‘m fine with that license. Regards, Florian

Re: Permanent URL for GUIX packages

Hello Sunshine, Sunshine via "Development of GNU Guix and the GNU System distribution." writes: > I'd like to link guix.gnu.org/packages/monolith-2.6.1/ […] Something similar is possible, see . Regards, Florian

Re: Translation: Would regional translation fall back to primary language?

Hello Luis. Luis Felipe writes: > I think I'll go with that option, thanks. :) > I don't know if I understand correctly the organizational problem > related to leaving the es-CO catalog partially translated, > intentionally. Is it that Weblate would display the es-CO translation > as

Re: Translation: Would regional translation fall back to primary language?

Hello Luis/sirgazil. Translation help sounds great. That said, I believe that, because others will add to the translation, that it would be best if you Downloaded the Spain Spanish file from Weblate and then uploaded that PO file as the first translation in Colombian Spanish. Then change it

Re: Translating news on weblate?

Hi Julien; sorry for the late answer. Julien Lepiller writes: > I was thinking we could have our news file translated at weblate, which > would help having more people translate it. Attached is a script that[…] Translating etc/news.scm via Weblate adds delay but reaches more translators. Now

Re: Merging ‘staging’?

On Thu, Jun 09, 2022 at 09:02:14PM +0200, pelzflorian (Florian Pelz) wrote: > I will try again with staging at 091eb323ba27. But it will take a > long time; feel free to proceed regardless. All my manifest built and runs on rock64 aarch64. Thank you all! Regards, Florian

Re: Merging ‘staging’?

On Thu, Jun 09, 2022 at 09:02:14PM +0200, pelzflorian (Florian Pelz) wrote: > I will try again with staging at 091eb323ba27. llvm@11 was built successfully. Sorry for the noise. Regards, Florian

Re: Merging ‘staging’?

On Thu, Jun 09, 2022 at 08:41:21PM +0300, Efraim Flashner wrote: > I know I've built llvm@11 and mesa on aarch64 hardware for staging. Oh I see I'm missing the last merge; I'm still at commit b422687cbd. I will try again with staging at 091eb323ba27. But it will take a long time; feel free to

Re: Merging ‘staging’?

On Mon, Jun 06, 2022 at 11:17:47PM +0200, Ludovic Courtès wrote: > We have to check for AArch64 & co. Any takers? > > Overall it seems to me we should be able to merge ‘staging’ within a > couple of days. Thoughts? > > Ludo’. > I mostly succeeded in updating my rock64 aarch64 machine guix

Re: Teams

On Sat, Jun 04, 2022 at 02:50:49PM +, Tobias Geerinckx-Rice wrote: > I think we should also have (natural) language 'teams' who can be > pinged when, e.g., a news item lands, through a single > guix-translators@ meta-alias, and who can co-ordinate before > releases. If we do so, please add me

Re: 10 years of stories behind Guix

On Mon, Apr 18, 2022 at 10:37:40PM +0200, Ludovic Courtès wrote: > To celebrate > it, zimoun has collected stories from a sample of the 600+ people who’ve > contributed to Guix over the years, which you can read here: > > https://guix.gnu.org/en/blog/2022/10-years-of-stories-behind-guix/ Thank

Re: The GNU Shepherd 0.9.0rc1 available for testing!

On Wed, Mar 30, 2022 at 06:59:33PM +0200, Ludovic Courtès wrote: > You can test it on Guix System with: > > guix time-machine --branch=wip-shepherd-upgrade -- \ > system reconfigure … On my 2010 Macbook Pro (with hard disk, not using SSD), boot time to GDM got a few seconds slower/faster

Re: The Shepherd on Fibers

On Sat, Mar 26, 2022 at 07:27:00PM +0800, Zhu Zihao wrote: > > IIUC, After fork and execute the program, shepherd will wait for the pid > file to appear. This is a block operation. > > Shepherd on Fiber make this operation non-blocking (because the pid file > is created by Linux kernel, Shepherd

Re: The Shepherd on Fibers

On Sat, Mar 26, 2022 at 12:59:20PM +0100, Maxime Devos wrote: > Grafting is not necessary. See (guix)Shepherd Services: > > >;; Use own Shepherd package. >(essential-services > (modify-services (operating-system-default-essential-services >

Re: The Shepherd on Fibers

On Sat, Mar 26, 2022 at 07:09:12PM +0800, Zhu Zihao wrote: > > So shepherd service authors still cannot write blocking code but need > > to yield? > > IMO, service should not block service, if they have something important > to do before running a program, why not fork first and do it in the >

Re: The Shepherd on Fibers

Hi Ludo! That you add fibers to Shepherd is great news. On Wed, Mar 23, 2022 at 11:36:30PM +0100, Ludovic Courtès wrote: > Fibers is used in a single-threaded fashion, which is the main > constraint for shepherd since it forks. That also means that fibers > cannot be preempted, so it’s fully

Re: Clarifying blog post licensing

I agree. On Wed, Jan 26, 2022 at 10:24:11AM +0100, Ludovic Courtès wrote: > Hello Guix! > > With a few exceptions, our blog posts do not have a license, which is > not great as it prevents sharing and reuse, at least by those outside > Guix circles (we discussed it in the past but never got

Re: Language menu in the HTML manual

On Wed, Jan 19, 2022 at 03:48:07PM +0100, Ludovic Courtès wrote: > Commit fa580bf3b456273ea20b3f4de1afdac3d031 should fix that. It > also introduces the navigation bar as found on the Guix web site; I > didn’t plan to do that, but that sorta came with the rest, so… You accomplished quite a

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Wed, Nov 24, 2021 at 01:32:56PM +0100, pelzflorian (Florian Pelz) wrote: > Sorry I misunderstood. I think your claim is that the ZFS decisions > listed by Ludo i.e. to disallow binary substitutes but to allow > patches for a ZFS file-system object (once reviewed) are inconsistent

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Wed, Nov 24, 2021 at 01:03:29PM +0100, pelzflorian (Florian Pelz) wrote: > On Wed, Nov 24, 2021 at 01:45:19AM +0100, Denis 'GNUtoo' Carikli wrote: > > If that's the case then it would also be legal to redistribute binaries > > too as long as they are dynamically linked as the

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Wed, Nov 24, 2021 at 01:45:19AM +0100, Denis 'GNUtoo' Carikli wrote: > If that's the case then it would also be legal to redistribute binaries > too as long as they are dynamically linked as the linking happens at > runtime. The FSF is unable to have such a position. It seems unrelated to the

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Sun, Nov 21, 2021 at 11:54:15AM +0100, pelzflorian (Florian Pelz) wrote: > raid5atemyhomework wrote patches to add ZFS to Guix > <https://issues.guix.gnu.org/45692>. I put them in CC. That there is > no decision on ZFS and their patches is bad. Maybe their patches > wo

ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

Hello Denis. Thank you for your write-up. raid5atemyhomework wrote patches to add ZFS to Guix . I put them in CC. That there is no decision on ZFS and their patches is bad. Maybe their patches would be for the RFC model to decide? As for Denis’ arguments

Re: Mailman packaging (was: Re: Python package naming: Dots vs hyphens)

Hello Christine, On Wed, Sep 29, 2021 at 12:34:06PM -0400, Christine Lemmer-Webber wrote: > Has anyone worked on this or used it in recent times? Sorry no, it was too much for me. > The above link no > longer works. However I see: > >

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

On Sat, Apr 24, 2021 at 07:13:01PM +0200, Ludovic Courtès wrote: > I’ve pushed these as two separate patches: > > c50db7156d http-client: Remove exception mishandling in 'http-multiple-get'. > 02d62978f4 http-client, substitute: Gracefully handle GnuTLS EAGAIN/EINTR. I assume they will be

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

Success! Thank you. 65;6003;1c On Fri, Apr 23, 2021 at 11:19:28AM +0200, Ludovic Courtès wrote: > Florian, could you try again with the attached patch? It succeeds on two full installs of Enlightenment, no errors, no prolonged getting stuck. > If you have the courage, it would be awesome if

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

Sorry for the slow response. On Wed, Apr 21, 2021 at 12:38:58AM +0200, Ludovic Courtès wrote: > Hi Florian, > > "pelzflorian (Florian Pelz)" skribis: > > On Tue, Apr 20, 2021 at 03:21:13AM +0200, pelzflorian (Florian Pelz) wrote: > >> > git revert be5

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

On Tue, Apr 20, 2021 at 02:00:54PM -0400, Leo Famulari wrote: > On Tue, Apr 20, 2021 at 07:03:26PM +0200, pelzflorian (Florian Pelz) wrote: > > On Tue, Apr 20, 2021 at 05:27:54PM +0200, pelzflorian (Florian Pelz) wrote: > > > It seems this is the bad commit. Downloading

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

On Tue, Apr 20, 2021 at 05:27:54PM +0200, pelzflorian (Florian Pelz) wrote: > On Tue, Apr 20, 2021 at 03:21:13AM +0200, pelzflorian (Florian Pelz) wrote: > > > git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd > > It seems this is the bad commit. Downloading the enlightenmen

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

On Tue, Apr 20, 2021 at 03:21:13AM +0200, pelzflorian (Florian Pelz) wrote: > > git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd It seems this is the bad commit. Downloading the enlightenment substitute got stuck and after a few minutes displayed the usual TLS error. Regards, Florian

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

After flashing the CMOS I can test again. Without reverts TLS errors happen while or after downloading the enlightenment substitute from the installer. With all of those reverts *no* TLS errors happen: On Mon, Apr 19, 2021 at 10:05:25AM +0200, pelzflorian (Florian Pelz) wrote: > git rev

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

On Mon, Apr 19, 2021 at 10:05:25AM +0200, pelzflorian (Florian Pelz) wrote: > I will bisect which reverts are needed, but it takes time … My UEFI broke; the PC cannot display anything anymore. Don’t wait for my debugging.

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

On Mon, Apr 19, 2021 at 10:05:25AM +0200, pelzflorian (Florian Pelz) wrote: > I dd’d the resulting image to a USB drive and the TLS errors no longer > appear (tried installing everything two times now; without reverts > downloading enlightenment needed retrys everytime). > […] I suspec

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

On Sun, Apr 18, 2021 at 02:10:06PM +0200, pelzflorian (Florian Pelz) wrote: > On IRC Ricardo/rekado suspected > c7c7f068c15e419aaf5ef616516aa5ad4e55c2fa, I will try reverting it. It was necessary to revert follow-up commits before reverting c7c7f068c15e419aaf5ef616516aa5ad4e55c2fa. I

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

On Sun, Apr 18, 2021 at 01:33:37PM +0200, pelzflorian (Florian Pelz) wrote: > (well with an unrelated error by > grub-install that it could not determine the canonical path of > /boot/efi). Probably > I will try reproducing, but Jin and me both had this > error. I got

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

On Sun, Apr 18, 2021 at 12:15:47PM +0200, Ludovic Courtès wrote: > Was this in a VM? No, an Asrock Beebox (real x86_64 hardware). > Could it be that networking was unstable (e.g., you > were running this over a flaky WiFi connection)? It is a stable Ethernet connection. > How reproducible is

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

On Sun, Apr 18, 2021 at 11:48:47AM +0200, pelzflorian (Florian Pelz) wrote: > On Sun, Apr 18, 2021 at 11:44:25AM +0200, pelzflorian (Florian Pelz) wrote: > > But now after maybe 10 minutes it finally continued and died with the > > same TLS error about write_to_session_record_po

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

On Sun, Apr 18, 2021 at 11:44:25AM +0200, pelzflorian (Florian Pelz) wrote: > But now after maybe 10 minutes it finally continued and died with the > same TLS error about write_to_session_record_port and Resource not > available. The error happened while substitute: updating substitutes from […]

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

On Sun, Apr 18, 2021 at 11:38:56AM +0200, pelzflorian (Florian Pelz) wrote: > I needed to restart the installer at the last step, this stopped while > downloading enlightenment with no error but it does not continue. Note: The last message was enlightenment-0.24.2 2

[1.2.1 pre-release testing] substitute downloading and TLS errors

On Fri, Apr 16, 2021 at 10:40:55PM -0500, jcguu95 wrote: >2.2. Unexpected failure > >After running `guix system init /mnt/etc/config.scm /mnt' for 5 to 10 >minutes, I got the error > >, >|substitute: updating substitutes from 'https://ci.guix.gnu.org'... > 0.0%guix

Re: 1.2.1 pre-release testing

On Sat, Apr 17, 2021 at 07:09:59PM -0500, Guu, Jin-Cheng wrote: > Not sure if it's appropriate to say here.. but when I was installing, > there was non-free kernel in my machine. And that's why my wifi was > working. If I remember correctly, on some machines the wifi only works after a reboot

Re: 1.2.1 pre-release testing

Hello Jin, On Sat, Apr 17, 2021 at 01:27:09PM -0400, Leo Famulari wrote: > I re-installed my Guix System based on the ISO found here: > > https://ci.guix.gnu.org/build/175632/details > > That's '/gnu/store/lw1j4gn8h51cbfp9dg0g025ngkg83sw1-image.iso.drv'. Ethernet works on the four machines I

Re: 1.2.1 pre-release testing

Hello Jin, On Sat, Apr 17, 2021 at 07:58:30AM -0500, Guu, Jin-Cheng wrote: > > Does the ethernet cable work on the installed system? Or on other > > free distros? > > It has never failed on me before, even when I was installing arch > linux. So I was a bit surprise yesterday. Arch ships with

Re: 1.2.1 pre-release testing

Hello Jin. Thank you for testing! On Fri, Apr 16, 2021 at 10:40:55PM -0500, jcguu95 wrote: > 1. Graphical Installation > >I chose the graphical method for the first installation. Everything >went well, except my wired internet connection failed as it >indicated. Weirdly enough, my

Re: Building the web site is slow

On Mon, Nov 23, 2020 at 11:46:08PM +0100, pelzflorian (Florian Pelz) wrote: > It is funny, when I try to profile via > > cd ~/src/guix-artwork/website > guix install -p haunt-profile guile-syntax-highlight guile-commonmark haunt > LC_ALL=en_US.utf8 \ > GUILE_LOAD_PATH=haunt-p

Re: Building the web site is slow

OK, I now believe `haunt build` is what costs the time. On Mon, Nov 23, 2020 at 11:46:08PM +0100, pelzflorian (Florian Pelz) wrote: > Anyway, I am not sure the `haunt build` runs are the culprit. If it > is a problem with spinning disks only, maybe .guix.scm can be made to > copy

Re: Building the web site is slow

On Mon, Nov 23, 2020 at 11:46:17PM +0100, pelzflorian (Florian Pelz) wrote: > it crashes, but only when using ,profile. I will investigate > tomorrow. No sorry the crash is not due to ,profile. It is when invoking Haunt from Guile instead of haunt build. haunt build must be doing som

Re: Building the web site is slow

On Mon, Nov 23, 2020 at 04:03:26PM +0100, Ludovic Courtès wrote: > Do you think we could arrange > to build all the languages in a single ‘haunt build’ run, would that > help? What kept me from doing a single `haunt build` run are two things. The lesser is that, when not using .guix.scm, running

Re: GNU Guix 1.2.0rc1 available for testing!

On Tue, Nov 17, 2020 at 03:41:34PM +0100, Ludovic Courtès wrote: > One this patch is in, I think we’re ready for either an RC2 or the real > thing. > > WDYT? > > Ludo’. With the patch I see no problems on x86_64 Guix system, install script or VM, but I have no idea of current Guix bugs.

Re: GNU Guix 1.2.0rc1 available for testing!

On Tue, Nov 17, 2020 at 10:02:33AM +0100, Mathieu Othacehe wrote: > That's good news! Here's a more complete patch that I intend to push on > the 1.2.0 branch. It logs the time spent waiting for disk > synchronization. > > It would be great if you could test it one more time, so that we know if >

Re: GNU Guix 1.2.0rc1 available for testing!

On Mon, Nov 16, 2020 at 10:12:09AM +0100, Mathieu Othacehe wrote: > Many thanks (again) for your help here! According to the backtrace you > sent earlier in this thread, it looks like the crash occurs in the > "free-parted" procedure. > > This procedure tries to unallocate Parted resources and

Re: GNU Guix 1.2.0rc1 available for testing!

On Sun, Nov 15, 2020 at 10:53:29PM +0100, Marius Bakke wrote: > I have just installed a system using manual partitioning through the > installer, with encryption. Everything worked like a charm. > > Can you provide more details about the steps you did to arrive at the > error? And information

Re: GNU Guix 1.2.0rc1 available for testing!

On Fri, Nov 13, 2020 at 06:07:32PM +0100, Ludovic Courtès wrote: > system installation: > […] > > https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.x86_64-linux.iso.xz Sorry for testing so late. For me the graphical installer crashes when doing a Manual Partitioning with an

Re: Branching for v1.2?

On Tue, Nov 03, 2020 at 01:51:18PM +0100, Tobias Geerinckx-Rice wrote: > Thanks for your work on the German translation! Could you incorporate this > fix[0] back into the TP version? […] > [0]: > http://git.savannah.gnu.org/cgit/guix.git/commit/?id=1aced9aa0c32849939d1facfaa0f3e5f1a6c11e0 >

Re: Branching for v1.2?

On Mon, Nov 02, 2020 at 10:00:38AM -0500, Julien Lepiller wrote: > Le 2 novembre 2020 08:20:34 GMT-05:00, "Miguel Ángel Arruga Vivas" > a écrit : > >With my translator hat on: a new tarball for TP has to be generated > >before or after creating the branch (1.2.0-pre3). If done tomorrow, I >

Re: Update on the timeline for the release v1.2.

Thank you zimoun for managing all this! About the string freeze: On Mon, Oct 19, 2020 at 08:26:31PM +0200, Miguel Ángel Arruga Vivas wrote: > zimoun writes: > > The proposed coming timeline is: > > > > - freeze starting the Oct. 26th > > - last round for testing all over the week > > -

Re: Commit access

On Sat, Oct 17, 2020 at 03:57:19PM +0200, Miguel Ángel Arruga Vivas wrote: > Hello, everybody! > > I'm happy to announce with this message my access to the repository and > the key I'll use to sign the commits. This text has been signed with > it, which has the following information and

Re: Call for 1.2 installer testing.

On Sun, Oct 11, 2020 at 05:23:30PM +1100, Brendan Tildesley wrote: > Hi, I went through the installer looking for anything negative I could say > about it :) hope there is something helpful here: Thank you for testing! > Unrelated driver bug: installer was just a black screen until I rebooted >

Re: Release v1.2 timetable

On Tue, Sep 29, 2020 at 02:16:30PM +0200, zimoun wrote: > To help the release process, please: > […] > d. translate Julien, shall I just push my translation without going through the TP? Regards, Florian

Re: Translating the web site

On Thu, Sep 24, 2020 at 09:31:19AM -0400, Julien Lepiller wrote: > I'll try to contact everyone today, but some of these emails might > end up in a spam folder, because my server is so small. Can you also > send something to the translators alias? So aside from Julien and me that’s, (from the

etc/news copyright (was Re: Translating the web site)

On Thu, Sep 24, 2020 at 09:25:56AM +0200, Ludovic Courtès wrote: > Julien Lepiller skribis: > > To get the project, we need to clarify the license on the translation > > files, as we discussed before. How should we proceed on that? > > There was a question about copyright holders for

Re: Translating the web site

Thank you for the heads-up. On Wed, Sep 23, 2020 at 08:50:46AM -0400, Julien Lepiller wrote: > Eventually it could be nice to have our own instance, but dividing > the translator community even further might not be a very good idea. Hmm it would seem nice if the Translation Project website would

Re: [website]: Fix rendering of entities.

On Wed, Sep 09, 2020 at 11:35:06PM +0200, Ricardo Wurmus wrote: > Hi Guix, > > this page looks wrong: https://guix.gnu.org/packages/mpc-1.1.0/ > > The non-breaking space is rendered as “GNU<*ENTITY*>nbspMPC”. The > attached patch processes the SHTML to remove *ENTITY* nodes, replacing > the

Re: Translation copyright

On Mon, Aug 31, 2020 at 02:20:37PM +0200, Julien Lepiller wrote: > I'd like to change all of these headers to something like this: > > Copyright (C) 2018-2020 the authors of Guix (msgids) Yes, I think you are right with this change, but where to make it? It seems this “authors of Guix” line in

Re: Persian translation

On Tue, Aug 04, 2020 at 12:57:37PM -0400, Amin Bandali wrote: > Hi Ali Reza, > > Ali Reza Hayati writes: > > > Hey guys. > > I hope you all are well. > > > > I wanted to contribute to GNU and Guix but I'm not a programmer so I > > thought maybe I can translate Guix to Persian if it's needed. Can

  1   2   3   >