Re: Jam: which licence is this?

On 2021-04-25, Jack Hill wrote: > On Sun, 25 Apr 2021, Vagrant Cascadian wrote: >> On 2021-04-25, Jack Hill wrote: >>> I'm working on packaging the Argyll Color Management System for Guix. To >>> build, it uses the Jam tool, which has the following license: >>

Re: Jam: which licence is this?

On 2021-04-25, Jack Hill wrote: > I'm working on packaging the Argyll Color Management System for Guix. To > build, it uses the Jam tool, which has the following license: > > ``` > This is Release 2.5 of Jam, a make-like program. > > License is hereby granted to use this software and distribute

Re: Pinebook pro TODO

On 2021-04-24, Vincent Legoll wrote: > now that I've got my pbp running guix, I have > more questions. > > The kernel is still "manjaro kernel", should > this be changed to reflect some changes > we have made ? That's probably just tweaking the kernel defconfig a bit more. > What about the

Re: Application for aarch64 computing resources

On 2021-04-02, Leo Famulari wrote: > Those of us who watch the Guix build farm [0] closely have identified > the lack of capacity for building ARM binaries as a serious limitation. > > As part of our efforts to improve the situation, I've applied for > donation of aarch64 (64-bit ARM) computing

Re: Are gzip-compressed substitutes still used?

On 2021-03-18, zimoun wrote: > On Wed, 17 Mar 2021 at 11:08, Vagrant Cascadian wrote: > >> ... and I would expect this version to ship in Debian for another ~3-5 >> years, unless it gets removed from Debian bullseye before the upcoming >> (real soon now) release! > >

Re: Are gzip-compressed substitutes still used?

On 2021-03-17, Léo Le Bouter wrote: > Just as a reminder siding with vagrantc here: > > We must ensure the Debian 'guix' package can still work and upgrade > from it's installed version, so ensure that removing gzip doesnt break > initial 'guix pull' with it. ... and I would expect this version

Re: Update on wip-arm-bootstrap

On 2021-02-13, Jan Nieuwenhuizen wrote: > Let's try to bisect where the problem is; we now have tree first > candidates: gcc-core-mesboot0, glibc-mesboot0 and binutils-mesboot0. > Luckily, Debian "woody" carries an almost compatible set. Doing > someting like > > --8<---cut

Guix in Debian!

So, a while back I mentioned that Guix was present in Debian "experimental": https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00254.html And it was useable for a brief window of time, but was broken due to some issues with guile-gnutls and guile-3.0: https://bugs.debian.org/964284

Re: bug#45069: Guix System: unprivileged user cannot create user namespaces?

On 2020-12-07, zimoun wrote: > On Mon, 07 Dec 2020 at 18:13, Pierre Neidhardt wrote: > >>> Can you try, as root on Guix System: >>> >>> $ echo 1 > /proc/sys/kernel/unprivileged_userns_clone >> >> # echo 1 > /proc/sys/kernel/unprivileged_userns_clone >> -bash:

Guix now in Debian experimental!

It's been a long haul getting all the build dependencies of guix into Debian, but it has finally paid off: https://tracker.debian.org/pkg/guix So now you can install guix from Debian's experimental distribution! It is not well tested, in fact, I had to disable many tests, because in Debian

Re: Etymology of derivation

On 2020-11-02, Arun Isaac wrote: > I am translating Guix to the Tamil language. Tamil doesn't yet have a > very standardized technical vocabulary, and I mostly coin terms on my > own. Most often, I construct calques of existing English words, and it > sounds alright. But, I'm having trouble with

Re: Porting Guix to RISCV

On 2020-10-31, Pjotr Prins wrote: > Anyone interested in porting GNU Mes and GNU Guix to RISCV? We can try > and purchase the hardware. We have a Polarfire running > > https://www.crowdsupply.com/microchip/polarfire-soc-icicle-kit > > and there are more options coming. I am happy to support such

Re: [PATCH 1/2] services: guix: Make /etc/guix/acl really declarative by default.

On 2020-10-21, Ludovic Courtès wrote: > diff --git a/doc/guix.texi b/doc/guix.texi > index c161012da5..50d2d9a730 100644 > --- a/doc/guix.texi > +++ b/doc/guix.texi ... > @@ -14583,6 +14598,27 @@ Whether to use substitutes. > @item @code{substitute-urls} (default: @code{%default-substitute-urls})

Re: Using #true and #false everywhere?

On 2020-10-16, Ludovic Courtès wrote: > As discussed on IRC recently, several of us think that using “#true” and > “#false” instead of “#t” and “#f” throughout or documentation and code > would probably make it easier for newcomers to decipher that. > > WDYT? I would very much welcome this as

u-boot for beagleboard

On 2020-10-01, Denis Carikli wrote: > I'd like to send a patch to add a bootloader (u-boot) package for a > single board computer. The patch is trivial and it's already > ready. Great! > However before sending the patch, I'm supposed to build it within Guix > source code and to test it. Can't

More checks for Makefile.am:assert-no-store-file-names ?

When running "make dist" there are some checks run, such as checking for hard-coded store paths. Would it be a good idea to add this or a similar check to etc/git/pre-push and/or guix lint? Would it make sense to set up a job to run "make dist" on the build farm to catch these problems? # Make

Re: Linux-libre git repository

On 2020-08-12, Mark H Weaver wrote: > Mark H Weaver wrote: >>> the linux-libre project periodically deletes most of its older >>> tarballs, even if there are no accidents. > > Jason Self responded: >> Just FYI that git://linux-libre.fsfla.org/releases.git was created >> mainly to solve that

Linux-libre 5.8 and beyond

Thanks for updating linux-libre to 5.7! I saw the 5.8 was out, and gave a quick shot at updating it, but it hung python indefinitely during the deblobbing process. I also tried switching to python 3 instead of python 2, but it had the same issue. Apparently this is a known issue:

Re: [GSOC 2020] network-boot-service

On 2020-07-02, Brice Waegeneire wrote: > To support the widest hardware and boot options possible I went with > iPXE > as a chainloader. Meaning that any machine doing a PXE boot (or with > builtin iPXE with restricted feature set) will load the iPXE bootloader > first, which will then properly

Re: Frequent locales problems for new users

On 2020-03-17, Leo Famulari wrote: > Warning! Locales! New users seem to have trouble with Guix locales every > day. > > I think we can improve the situation. > > First, we can deprecate the glibc-utf8-locales package and not mention > it in the manual section Application Setup. I've seen users

Re: [bug#40190] Linux-Libre 5.7

Resending to correct list... On 2020-06-08, Vagrant Cascadian wrote: > On 2020-04-17, Mark H Weaver wrote: >> Vagrant Cascadian wrote: >>> I think the patcset now needs some minor updates to apply to master, but >>> just wondering when we could consider switching to 5

Re: Heads-up: “pre-push” Git hook updated

On 2020-05-29, Ludovic Courtès wrote: > Ludovic Courtès skribis: > >> I think we should change our pre-push hook as shown below. > > I’ve pushed it in e65a44649e8d7698c4a888f1de625a67052520e9. > To all committers: please do use it from now on: > > cp etc/guix/pre-push .git/hooks/ > > If you

Re: Build reproducibility metrics

On 2020-06-03, Christopher Baines wrote: > Combining that with the substitute server operated by Tobias, which has > a pretty awesome substitute availability of over 90% for recent > revisions, not only is there data from 4 different substitute servers to > use in the comparison, but the

Re: Updating the “pre-push” Git hook

On 2020-05-24, Ludovic Courtès wrote: > Efraim Flashner skribis: >> On Fri, May 22, 2020 at 10:44:48PM +0200, Ludovic Courtès wrote: >>> Hello Guix! >>> >>> I think we should change our pre-push hook as shown below. >>> >>> Thoughts? ... >> (ins)efraim@E5400 ~$ type -P make >> (ins)efraim@E5400

Re: Some packages failing to build

On 2020-05-10, Marius Bakke wrote: > Guillaume Le Vaillant writes: > >> Guillaume Le Vaillant skribis: >> >>> Hi, >>> >>> After pulling guix with the merged core updates (guix at commit >>> 95ffdfe86cb1b8a8e4fff1386a147718400b76e0), I found a few packages >>> failing to build: >>> >>> -

Re: core-updates call for testing

On 2020-05-04, Vagrant Cascadian wrote: > On 2020-05-04, Marius Bakke wrote: >> @everyone, please speak up if you find any of your packages failing on >> the core-updates branch! The substitute coverage is currently ~90%, >> which is better than on 'master'. > &g

Re: core-updates call for testing

On 2020-05-04, Marius Bakke wrote: > @everyone, please speak up if you find any of your packages failing on > the core-updates branch! The substitute coverage is currently ~90%, > which is better than on 'master'. I'm noticing libdbusmenu is failing on aarch64 (which is a dependency of waybar):

Re: Adding a subcommand "load-profile"

On 2020-05-03, Ludovic Courtès wrote: > sirgazil skribis: >> On Tue, 28 Apr 2020 22:42:53 + Roel Janssen wrote >> >> > We added a subcommand in the "guixr" script called "load-profile". It >> allows a >> > user to do the following: >> > >>

Re: hint: Run `guix search ... | less' to view all the results

On 2020-04-27, Jan Synacek wrote: > While we're at it, let me also give my opinion about supporting PAGER. If > it means that if PAGER is set, use it, otherwise don't page, then that's > perfectly valid and, in my opinion, how PAGER support is supposed to > work. I don't think PAGER is an

Re: U-boot update revert.

On 2020-04-23, Vagrant Cascadian wrote: > On 2020-04-23, Mathieu Othacehe wrote: >> I reverted the U-Boot update to 2020.04 because it breaks the build of >> u-boot-tools package. Could you please have a look? > > Hrm. Pretty sure it worked locally when I committed it... >

Re: U-boot update revert.

On 2020-04-23, Mathieu Othacehe wrote: > I reverted the U-Boot update to 2020.04 because it breaks the build of > u-boot-tools package. Could you please have a look? Hrm. Pretty sure it worked locally when I committed it... Unfortunately, won't have a chance to debug till next week; if anyone

Re: 1.1.0rc1 available for test!

On 2020-04-09, Ludovic Courtès wrote: > Hello Guix! > > I’ve run “make release” from the new ‘version-1.1.0’ branch and uploaded > the result: > > https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc1 The only tarball I see there is:

Re: Unencrypted boot with encrypted root

On 2020-04-08, Ellen Papsch wrote: > Am Dienstag, den 07.04.2020, 09:47 -0700 schrieb Vagrant Cascadian: >> On 2020-04-07, Alex Griffin wrote: >> > So we can put the key in its own initrd (outside of the store) >> > >> >> I believe it's also possible

Re: Unencrypted boot with encrypted root

On 2020-04-07, Alex Griffin wrote: > On Tue, Apr 7, 2020, at 9:46 AM, Ludovic Courtès wrote: >> The difficulty is that any file traveling through the store is >> world-readable. It’s hard to avoid. > > If we can create the key file outside of the store, then GRUB is capable of > being passed

Re: [GSOC 2020] Booting via network

On 2020-03-30, Brice Waegeneire wrote: > I know it's quite late to submit a GSOC proposal but here it's. > I would like to work on the project suggested by Danny to > add PXE support to Guix. Which has been requested several > times on IRC and in the ML. This would get us a step closer > to

Re: non-deterministic test suite failure for diffoscope

On 2020-03-05, Vagrant Cascadian wrote: > I've occasionally seen non-deterministic failures in diffoscope's test > suite only on GNU Guix, and wondering if someone more familiar with how > guix's python-build-system calls pytest could look into it. The bug is > reported upstream here:

Re: Use genimage for disk-image creation.

On 2020-03-29, Danny Milosavljevic wrote: > Hi Ludo, > > On Sun, 29 Mar 2020 16:44:39 +0200 > Ludovic Courtès wrote: > >> Oh, really? I’m surprised partitioning causes problems (though I’m >> not familiar with embedded dev!). > > Well, maybe not that bad, but it's pretty bad. > > It's because

Cannot build guix from git due to .po file errors

I haven't been able to build guix from a local checkout lately: $ git describe --match=v'*' v1.0.1-13415-g0557618dbe $ git clean -dfx $ guix environment --pure guix [env]$ ./bootstrap && ./configure --localstatedir=/var && make -j4 check ++ find po/doc -type f -name 'guix-manual*.po' ... make[4]:

Re: RFC: Linux-Libre 5.5.x

On 2020-03-19, Vagrant Cascadian wrote: > I've been working on trying to get a mainline or nearly mainline kernel > working for pinebook pro, and there's a little better support in > linux-libre 5.5. > > According to: > > https://linux-libre.fsfla.org/pub/linux-libre/

Re: RFC: Linux-Libre 5.5.x on pinebook pro

On 2020-03-19, Vincent Legoll wrote: > I'm currently trying to get guix on my pinebook pro, so I will try your > patches, > I'm trying with Janneke's recipe now. Thanks! I should also mention that you'll need a serial console, as I haven't gotten video working with a mainline kernel yet. Other

RFC: Linux-Libre 5.5.x on pinebook pro

the default at 5.4), linux-libre-arm64-generic, and adds a patch from linux-next to enable limited support for pinebook-pro. Once I've tested 5.5.10, i'd probably end up pushing that. live well, vagrant From ffef750306d4f2ee3a228938620647270fabc85a Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian

Re: "make dist" broken by German cookbook translation

On 2020-03-06, pelzflorian (Florian Pelz) wrote: > On Fri, Mar 06, 2020 at 11:19:27AM -0800, Vagrant Cascadian wrote: >> It looks like the commit adding the German translation for the cookbook >> f98e83a17fa30587520e858231ec9c61f3624ecd broke "make dist". > > So

"make dist" broken by German cookbook translation

It looks like the commit adding the German translation for the cookbook f98e83a17fa30587520e858231ec9c61f3624ecd broke "make dist". in an environment built using: guix environment --pure guix --ad-hoc git imagemagick running: ./bootstrap && ./configure --localstatedir=/var && make -j4 &&

non-deterministic test suite failure for diffoscope

I've occasionally seen non-deterministic failures in diffoscope's test suite only on GNU Guix, and wondering if someone more familiar with how guix's python-build-system calls pytest could look into it. The bug is reported upstream here:

Quick reproducible test for GNU Guix

I did some quick reproducibility testing running GNU Guix, and so far got pretty good results: Using guix (and packages) built from commit: f83d07f7778b699d46741a5667113342f5f0a737 $ guix challenge --verbose --diff=diffoscope ... 2,463 store items were analyzed: - 2,016 (81.9%) were

Re: Guile 3 migration plan

On 2020-01-16, Ludovic Courtès wrote: > Today is Guile 3 day, a day to celebrate, woohoo! \o/ Yay! > How will Guix migrate to Guile 3? That’s a threefold process: ... > 2. We must be able to run Guix itself on Guile 3. This is already > possible if you add “3.0” to the ‘GUILE_PKG’

Re: bug#22883: Authenticating Git checkouts: step #1

On 2019-12-27, Ricardo Wurmus wrote: >> b3011dbbd2 doc: Mention "make authenticate". >> 787766ed1e git-authenticate: Keep a local cache of >> previously-authenticated commits. >> 785af04a75 git: 'commit-difference' takes a list of excluded commits. >> 1e43ab2c03 Add

Re: #850644: RFP: Guix in Debian

On 2019-05-28, Vagrant Cascadian wrote: > On 2019-05-16, Vagrant Cascadian wrote: >> So in a bit of a focused run of packaging, I've been chasing the >> dependency chain necessary to get guix building on Debian: Summary: all the dependencies are in Debian! >> * guile-g

Re: State of ungoogled-chromium in Guix

On 2019-10-23, Marius Bakke wrote: > Version 78 of the upstream Chromium project was released yesterday, with > the usual amount of security fixes: > > https://chromereleases.googleblog.com/2019/10/stable-channel-update-for-desktop_22.html > > Unfortunately the 'ungoogled-chromium' variant in Guix

Linux-libre 5.3 not quite updated?

< vagrantc> nckx: did you intentionally not update all the linux-libre variables so that linux-libre-arm* still use 5.2 ? < sneek> vagrantc, nckx says: Yes. Not just for ARM. 5.3 is untested on bare metal. < vagrantc> nckx: not untested anymore ... i've tested it on both x86_64

core-updates fails to "make dist" missing guix-manual.pot

I'm trying to generate a tarball from core-updates using "make dist". With the following commit it always ends in a failure due to missing guix-manual.pot: 893c2df00daa4e6dd6a7ff3813d7df5329877f9e Merge branch 'master' into core-updates $ ./bootstrap && ./configure --localstatedir=/var &&

Re: Guix beyond 1.0: let’s have a roadmap!

On 2019-06-27, Ludovic Courtès wrote: > People rightfully suggested having some sort of a roadmap for what’s > next. ... > What do *you* want Guix to address in the future? A few architecture support issues come to mind: * Architectures ** TODO system/installer images for armhf ** TODO

Re: hydra.gnu.org and mirror.hydra.gnu.org service discontinued

On 2019-06-18, Ludovic Courtès wrote: > After seven years of service, the continuous integration service and > ‘guix publish’ service running at hydra.gnu.org, as well as its mirror > at mirror.hydra.gnu.org, are now discontinued. Curious how this will affect armhf systems, as berlin didn't tend

Re: 01/01: gnu: diffoscope: Update to version 115-1.7f3416f.

a comment explaining why that commit was used right after I pushed... > Commit 7f3416ff > Committed by Vagrant Cascadian 6 days ago > > Add support for known external tools on GNU Guix.[1] > > Nice. Thank you! Especially since guix's diffoscope doesn't install *

Re: #850644: RFP: Guix in Debian

Control: block 850644 by 902174 Status update: technically working package! Needs more work within Debian to actually include it... On 2019-05-16, Vagrant Cascadian wrote: > On 2018-05-16, Vagrant Cascadian wrote: >> The main build/runtime dependencies missing from Debian appear to be

Re: savannah access (was Re: [bug#35478] [PATCH] gnu: diffoscope: Update to 114.)

On 2019-04-30, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> On 2019-04-29, Ludovic Courtès wrote: >>> Vagrant Cascadian skribis: >>>> * gnu/packages/package-management (diffoscope): Update to 114. >>> >>> Applied, thanks! >>> &

Re: Guix on the ASUS C201PA

> I have a few more changes to the veyron-specific config that were needed > for desktop use I've submitted the kernel, bootloader and example configuration patches as: https://issues.guix.info/issue/34978 live well, vagrant signature.asc Description: PGP signature

Re: Guix on the ASUS C201PA

On 2019-03-23, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> There's a FIXME for properly fetching the veyron kernel configuration, >> but otherwise it's looking almost like something worth formally >> submitting... ? > > It looks like it! Mark, coul

Re: Guix on the ASUS C201PA

On 2019-03-17, Timothy Sample wrote: > Vagrant Cascadian writes: >> With libreboot re-installed, it's working for me as well! > > Hooray! > >> I haven't tried just applying the minimal patches and/or configuration >> on top of Guix's linux-libre, but that seems like

Re: Guix on the ASUS C201PA

On 2019-03-09, Vagrant Cascadian wrote: > On 2019-03-06, Timothy Sample wrote: >> Vagrant Cascadian writes: >>> On 2019-03-06, Timothy Sample wrote: >>>> I was able to get Guix to boot on an ASUS Chromebook C201PA. > > So, I've gotten the kernel

Re: boot multiple Gnu/Linux Distributions from one USB key

On 2019-03-12, Ricardo Wurmus wrote: > gnuforever writes: >> For GuixSD, I came up with this configuration: >> I used label instead of uuid. >> >> ## GUIXSD >> menuentry "GUIXSD - Gnu/Linux" { >> set isofile="/boot-isos/guixsd-install-0.16.0.x86_64-linux.iso" >> loopback

Re: Guix on the ASUS C201PA

On 2019-03-06, Timothy Sample wrote: > Vagrant Cascadian writes: >> On 2019-03-06, Timothy Sample wrote: >>> I was able to get Guix to boot on an ASUS Chromebook C201PA. So, I've gotten the kernel to load, but the version of coreboot and/or depthcharge I have install

Re: Guix on the ASUS C201PA

On 2019-03-06, Timothy Sample wrote: > I was able to get Guix to boot on an ASUS Chromebook C201PA. This model > of computer is pretty neat. It’s an ARMv7 (32-bit) machine that can be > run with entirely free software. There is even a free graphics driver > in the works [1]. Very excited to

Re: Better names for Guix versions from git?

On 2018-12-26, Gábor Boskovits wrote: > swedebugia ezt írta (időpont: 2018. dec. 25., K, > 22:39): >> On 2018-12-25 20:49, Taylan Kammer wrote: >> > Currently, after running 'guix pull', the Guix version will be reported >> > by 'guix --version' as something like: >> > >> >

Re: keep spinning even without new line

On 2018-12-29, Ricardo Wurmus wrote: > when using “guix package -i” the build log lines are replaced with a > spinner character. In some cases, the build log does not produce new > lines for a long time, so that the spinner appears to be stuck. > What do you think of advancing the spinner even

Re: GuixSD on AArch64

On 2018-12-12, Andreas Enge wrote: > On Mon, Oct 22, 2018 at 12:17:58PM -0700, Vagrant Cascadian wrote: >> Looking like u-boot 2019.01 might be more likely, but modest patches >> work with 2018.11-rc2. I'll probably bring the pinebook with me to the >> Paris meetup in Decembe

Re: GuixSD on librem phone?

On 2018-12-06, Vagrant Cascadian wrote: > On 2018-12-06, swedebu...@riseup.net wrote: >> What about blobs? Any news? (see below) > > Not sure. For their laptops, they use blob-free wireless, at least. > > The chipset proposed for the librem-5 (imx8*) has a GPU that works wi

Re: GuixSD on librem phone?

On 2018-12-06, swedebu...@riseup.net wrote: > I would like to know if there is any interest in this? I've got my eyes on the librem-5 too... > What processor architecture is it using? aarch64 > What about blobs? Any news? (see below) Not sure. For their laptops, they use blob-free wireless,

GuixSD on AArch64

On 2018-10-22, Ludovic Courtès wrote: > On IRC earlier today Vagrant mentioned that the Pinebook AArch64 laptop > (see ) should be able to run > GuixSD when Linux-libre 4.19 and U-Boot 2018.11 are out, with 100% free > software. That may give another

Re: Making javadoc reproducible

On 2018-10-12, Björn Höfling wrote: > On Fri, 12 Oct 2018 19:35:51 +0200 > Gábor Boskovits wrote: >> Gábor Boskovits ezt írta (időpont: 2018. okt. >> 12., P, 19:00): >> > I've tracked down the javadoc timestamp problem. >> > There is a command line flag for javadoc (notimestamp), that >> >

Re: Outreachy internship with Guix

On 2018-10-05, Björn Höfling wrote: > On Fri, 5 Oct 2018 16:28:08 +0200 > Gábor Boskovits wrote: >> namrata malkani ezt írta (időpont: 2018. okt. >> 5., P 16:23): ... >> > But when I tried to download the .sig file, using the command >> > >> > wget >> >

Re: Meetup in Paris, Dec. 10th?

On 2018-09-27, Ludovic Courtès wrote: > I was wondering if people would be willing to gather, say, the day > before the summit (December 10) to discuss Guix things and/or have hack > sessions. Who’s in? :-) Hoping to make it, and would be good to meet more guix folks! live well, vagrant

Re: What ARM hardware should we buy and where should we host it?

On 2018-09-03, Ricardo Wurmus wrote: > - We need to be able to restart the machine remotely. If members of the > Guix project have no physical access to the hosting site, this can be > done via remote-controlled power supply or similar. > > We are looking for volunteers who could either host

Re: ARMHF flash image - Put on website under GuixSD

On 2018-09-10, Ludovic Courtès wrote: > Danny Milosavljevic skribis: > >> finally, https://hydra.gnu.org/build/3044681 (flash-image armhf) built. >> >> Can we put it on the website at https://www.gnu.org/software/guix/download/ >> inside the GuixSD part? >> >> I think it would be nice to have

Re: What ARM hardware should we buy and where should we host it?

On 2018-09-03, Ricardo Wurmus wrote: > The first question is what ARM hardware to buy; the second is where to > host that hardware. Here are some considerations: > > - The new systems should be easy to host in a data centre; this might > mean that we need rack-mounted servers, or that we need a

<    1   2   3