Re: FSDG issues of SCUMMVM-based games

On 2022-08-24, Liliana Marie Prikler wrote: > Am Mittwoch, dem 24.08.2022 um 14:53 +0200 schrieb Nicolas Goaziou: >> Liliana Marie Prikler writes: >> >> > The packages >> > - drascula, >> > - lure, >> > - queen, and >> > - sky >> > all share issues that make me question whether they should be in

guix lint should support overrides

I love guix lint! The vast majority of the time I even use it! But... sometimes a guix lint suggestion isn't appropriate, at which point it becomes noise for future contributors of that package. tt might not be possible, or at least not worth the effort, to improve guix lint to catch that particu

Re: Reproducible Builds Status Summary for Guix

On 2022-06-12, Vagrant Cascadian wrote: > I've been working on Reproducible Builds in guix a fair amount this > month. I did another round of this... I fixed a few packages recently, and noticed some other people fixing packages too, yay! As of this moment for x86_64, it looks l

Re: Guix on my ROCKPro64 and on an old Android Tablet

On 2022-08-13, Tobias Platen wrote: > Today I began building the Guix System for my ROCKPro64. > I installed Guix on top of Debian and tried to build uboot, it works: > > guix build u-boot-rockpro64-rk3399 > successfully built /gnu/store/g1d4kjgn9b46vqk9mwhd0kc2r6sfi7cz-u-boot- > rockpro64-rk3399-2

Re: Set FORCE_SOURCE_DATE=1 by default

On 2022-07-04, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> --- a/gnu/packages/tex.scm >> +++ b/gnu/packages/tex.scm >> @@ -395,6 +395,12 @@ (define-public texlive-bin >> (("srcdir/tests/pprecA-0.ind

Re: Repology and outdated packages

On 2022-06-07, Nicolas Goaziou wrote: > kias...@disroot.org writes: > >> I've been watching the Repology page for Guix and I've noticed that >> we've dropped to 51% outdated packages >> [https://repology.org/repository/gnuguix]. We used to be at 40% >> outdated packages a few months ago. > > Repolo

Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic

On 2022-07-14, zimoun wrote: > Well, dreaming about science fiction, it appears me more approachable to > have Guix running on something as Debian/kfreeBSD – it could be an > interesting project with the help of Debian folks. Other said, “just” > replace the Linux kernel by a variant of the FreeBS

Re: [WIP Patch] Adding an FHS container to guix shell

On 2022-07-12, John Kehayias wrote: > Apologies for the long email, so let me start with the punchline: > attached is a diff which adds an '--fhs-container' (or -F) option to > guix shell/environment to set up an FHS-like container. This includes > the usual /lib directory and a glibc which loads (

Re: maradns reproducibility fixes and the merits of picking a random number

On 2022-07-11, Vagrant Cascadian wrote: > I hear Efraim say better to have unique randomness and no substitutes, > and I hear Tobias say more or less it's ok as long as upstream is right > about it being ok to embed a specific prime as other random numbers get > mixed in at runt

Re: maradns reproducibility fixes and the merits of picking a random number

On 2022-06-28, Tobias Geerinckx-Rice wrote: >>I am at a loss as to what to do then ... nothing and just have it be >>unreproducible? embed a specific random number? come up with better >>upstreamable patches? > > From upstream's response and my own biases and my reading of the room here, > I'd say

Re: glibc-locales

On 2022-07-03, Andreas Enge wrote: > Am Sun, Jul 03, 2022 at 12:53:09PM +0300 schrieb Efraim Flashner: >> I misread the source. I'd like glibc-utf8-locales built with glibc-final. > > Has glibc-utf8-locales not been removed some time ago? I always had it in > my profile, then saw a message during u

Re: Set FORCE_SOURCE_DATE=1 by default

On 2022-06-23, Maxim Cournoyer wrote: >>> Perhaps to show our stand here we could patch our copy of pdftex with >>> 's/FORCE_SOURCE_DATE/SOURCE_DATE_EPOCH/', lest we end up with a grocery >>> list of *SOURCE_DATE* variable variants. >> >> Sure, with some technical details fixed up, as I think they

Re: maradns reproducibility fixes and the merits of picking a random number

On 2022-06-28, Gábor Boskovits wrote: > Tobias Geerinckx-Rice ezt írta (időpont: 2022. jún. 28., K > 18:07): >> Vagrant said: >> > It is expensive to generate the random prime on some hardware, so doing >> > so at runtime might not be feasible in some cases... >> >> But in the same reply you're pa

Re: maradns reproducibility fixes and the merits of picking a random number

On 2022-06-22, Vagrant Cascadian wrote: > On 2022-06-08, Vagrant Cascadian wrote: >> On 2022-06-08, Efraim Flashner wrote: >>> On Tue, Jun 07, 2022 at 07:20:25AM +0200, Julien Lepiller wrote: >>>> On June 7, 2022 5:24:22 AM GMT+02:00, Felix Lechner >>>>

Re: maradns reproducibility fixes and the merits of picking a random number

On 2022-06-08, Vagrant Cascadian wrote: > On 2022-06-08, Efraim Flashner wrote: >> On Tue, Jun 07, 2022 at 07:20:25AM +0200, Julien Lepiller wrote: >>> On June 7, 2022 5:24:22 AM GMT+02:00, Felix Lechner >>> wrote: >>> >On Mon, Jun 6, 2022 at 6:50 PM Va

Re: Set FORCE_SOURCE_DATE=1 by default

On 2022-06-22, Maxim Cournoyer wrote: > Vagrant Cascadian writes: >> On 2022-06-21, Maxim Cournoyer wrote: >>> Vagrant Cascadian writes: >>>> That said, some projects (such as texlive) might be worried about >>>> messing with time too much (I get it, lot

Re: Time namespace for build sandbox (was Re: Set FORCE_SOURCE_DATE=1 by default)

On 2022-06-22, Zhu Zihao wrote: > Can we make some experiments on the Linux time namespace for build > sandbox? > > This can mock the real system with our desired value, maybe a good > solution for the reproduciblity on Linux machine. > > Ref: https://man7.org/linux/man-pages/man7/time_namespaces.7

Re: Set FORCE_SOURCE_DATE=1 by default

On 2022-06-22, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> On 2022-06-21, Maxim Cournoyer wrote: > > [...] > >>> I'd much prefer challenging that stance than "endorsing" it in Guix :-). >>> I think it'd be OK to reluctantl

Re: Set FORCE_SOURCE_DATE=1 by default

On 2022-06-21, Maxim Cournoyer wrote: > Vagrant Cascadian writes: >> So, guix sets SOURCE_DATE_EPOCH=1 by default in >> guix/build/gnu-build-system.scm, which is great! >> >> This allows guix packages in many cases to build packages reproducibly, >> with a curi

Re: Set FORCE_SOURCE_DATE=1 by default

On 2022-06-21, Vagrant Cascadian wrote: > On 2022-06-15, Ludovic Courtès wrote: >> Vagrant Cascadian skribis: >>> From 7a39330b56934accef14b5e2ac003e211c7c6c5b Mon Sep 17 00:00:00 2001 >>> From: Vagrant Cascadian >>> Date: Fri, 10 Jun 2022 16:12:59 -0700

Re: Set FORCE_SOURCE_DATE=1 by default

On 2022-06-15, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> From 7a39330b56934accef14b5e2ac003e211c7c6c5b Mon Sep 17 00:00:00 2001 >> From: Vagrant Cascadian >> Date: Fri, 10 Jun 2022 16:12:59 -0700 >> Subject: [PATCH] guix: gnu-build-system: Set FORCE_SO

Re: Set FORCE_SOURCE_DATE=1 by default

On 2022-06-15, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> From 7a39330b56934accef14b5e2ac003e211c7c6c5b Mon Sep 17 00:00:00 2001 >> From: Vagrant Cascadian >> Date: Fri, 10 Jun 2022 16:12:59 -0700 >> Subject: [PATCH] guix: gnu-build-system: Set FORCE

Reproducible Builds Status Summary for Guix

I've been working on Reproducible Builds in guix a fair amount this month. data.guix.gnu.org has proven invaluable for this work, big thanks for that! https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/package-reproducibility I have cataloged many of the packages

Re: U.S. Midwest based build farm

On 2022-06-11, Maxime Devos wrote: > jbra...@dismail.de schreef op za 11-06-2022 om 16:06 [+]: >> What's good and/or bad about this idea? > > A positive point: extra resources, could be useful for reproducibility > testing, ...? > > A negative point: extra points through with malware can be int

Set FORCE_SOURCE_DATE=1 by default

r your perusal. I'm guessing this would be world-rebuild endeavor, hello core-updates! Thoughts? live well, vagrant From 7a39330b56934accef14b5e2ac003e211c7c6c5b Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Fri, 10 Jun 2022 16:12:59 -0700 Subject: [PATCH] guix: gnu-build-system:

Re: maradns reproducibility fixes and the merits of picking a random number

On 2022-06-08, Efraim Flashner wrote: > On Tue, Jun 07, 2022 at 07:20:25AM +0200, Julien Lepiller wrote: >> On June 7, 2022 5:24:22 AM GMT+02:00, Felix Lechner >> wrote: >> >On Mon, Jun 6, 2022 at 6:50 PM Vagrant Cascadian >> > wrote: >> >> >>

Re: maradns reproducibility fixes and the merits of picking a random number

On 2022-06-09, Arun Isaac wrote: > Hi Vagrant, > >> But there's one nervous-making issue this revealed; maradns embeds a >> random number at build time ... allegedly for systems that don't have >> /dev/urandom... see >> maradns-3.5.0020/deadwood-3.5.0020/src/Makefile.ubuntu2004: >> >> # Since som

Re: maradns reproducibility fixes and the merits of picking a random number

On 2022-06-08, Liliana Marie Prikler wrote: > Am Montag, dem 06.06.2022 um 18:49 -0700 schrieb Vagrant Cascadian: >> p.s. Obviously, I picked the best random number. > I beg to differ. >> +-RandomPrime:  RandomPrime.c >> +-  $(CC) -O3 -o RandomPrime RandomPrime.c

Re: Teams

On 2022-06-04, Ricardo Wurmus wrote: > As a first step I’d suggest collecting teams, setting up the email > aliases, and updating the website to show the existing teams. Here’s > a draft of three teams: I'm almost afraid to volunteer... but maybe architecture specific teams? If I were to put my

maradns reproducibility fixes and the merits of picking a random number

a2e10d39de37c363b25f06dbb275e2bf6d614b7c Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Sun, 5 Jun 2022 13:57:27 -0700 Subject: [PATCH 3/3] gnu: maradns: Build reproducibly. * gnu/packages/patches/maradns-deadwood-do-not-embed-random-number.patch: New file. * gnu/local.mk (dist_patch_DA

Re: Reproducibility of "core" packages in GNU Guix

On 2022-05-02, Vagrant Cascadian wrote: > $ guix challenge --diff=none $(cat guix-base-set) > > /gnu/store/8gmqvwf0ccqfyimficcnhxvrykwx6y8g-linux-libre-5.17.5 contents > differ: Proving more difficult than I'd hoped for, smallish diffs in the .ko files and in the bzImage an

Re: Finding a “good” OpenPGP key server

On 2022-05-30, Ludovic Courtès wrote: > Maxime Devos skribis: > >> Ludovic Courtès schreef op ma 18-04-2022 om 22:24 [+0200]: >>> [... guix refresh -u stuff failing due to not finding the key ...] >>> I’m not sure what a good solution is (other than looking for the key >>> manually on Savannah or

Re: Guix System on RockPro64

On 2022-05-04, Tom Fitzhenry wrote: > On 4/5/22 04:53, Tobias Platen wrote: >> I had a look at the guix page, there is a latest version image for the >> PineBook Pro, which uses the same SoC. > The SoC is the same, but the PineBook Pro and RockPro64 have different > u-boot bootloaders: u-boot-rock

Re: Reproducibility of "core" packages in GNU Guix

On 2022-05-02, zimoun wrote: > On Mon, 02 May 2022 at 06:11, Vagrant Cascadian > wrote: >> $ guix challenge --diff=none $(cat guix-base-set) ... >> The fact that the guix and guile packages do not build reproducibly is a >> little disappointing as they're both

Reproducibility of "core" packages in GNU Guix

On 2022-04-27, Vagrant Cascadian wrote: > Lately, I've been trying to get a handle on the status of the really > core packages in Debian ... > I'd also be really curious to hear about the status of similar package > sets in other distros! With my metaphorical guix hoodie[1]

Re: Hardened toolchain

On 2022-04-28, Aurora wrote: > Katherine Cox-Buday writes: > >> Everyone has different threat models and needs. A lot of computers have CPU >> speculative execution attack mitigation disabled because those types of >> attacks will never affect those computers, and it reduces the performance of

Re: WhereIsEveryone, Guix Packaging Meetup Tomorrow, April 24th

On 2022-04-23, jgart wrote: > Hi Guixers, we'll have a packaging meetup tomorrow, Sunday at 22:30 ET. Is that ... $ date --utc -R -d '2022-04-24 22:30 EDT' Mon, 25 Apr 2022 02:30:00 + e.g. in about an hour and change from now? It is much easier to convert from UTC to other timezones tha

Re: How to find binaries in libexec dir?

On 2022-04-17, Liliana Marie Prikler wrote: > Am Sonntag, dem 17.04.2022 um 12:27 -0700 schrieb Vagrant Cascadian: >> On 2022-04-17, Danny Milosavljevic wrote: >> > On Sat, 16 Apr 2022 16:21:50 -0700 >> > Vagrant Cascadian wrote: >> > >> > > But li

Re: How to find binaries in libexec dir?

On 2022-04-17, Danny Milosavljevic wrote: > On Sat, 16 Apr 2022 16:21:50 -0700 > Vagrant Cascadian wrote: > >> But libxmlb ships the xb-tool binary in libexec, which diffoscope cannot >> find on guix. ... > I've looked upstream https://github.com/hughsie/libxmlb an

How to find binaries in libexec dir?

Diffoscope uses *lots* of optional tools for which it would be impractical to embed all the tool references in the guix packaging... instead, for the most part, diffoscope relies on PATH to find helper utilities to decode various file formats into something more human readable... But libxmlb ships

Re: Interest in "guix lint" Meetup?

On 2022-03-17, Matt wrote: > On Thu, 17 Mar 2022 21:04:13 -0400 Vagrant Cascadian > wrote > > The description and synopsis fixes are generally pretty easy, so might > > make for good first steps for someone wanting to get familiar with the > > process of con

Interest in "guix lint" Meetup?

Hey folks, was wondering if there would be interest in doing a virtual meetup where we try and fix issues revealed by "guix lint". On a fairly recently pulled guix: $ guix lint --checkers=description > guix-lint-description $ guix lint --checkers=synopsis > guix-lint-description $ wc -l gui

Re: Documentation of what is appropriate for #guix?

On 2022-02-19, m...@excalamus.com wrote: > On Sat, 19 Feb 2022 21:33:47 -0500 Vagrant Cascadian > wrote > > Every now and then someone stumbles into #guix and ask questions that > > I've gleaned over time are off-topic (e.g. non-free software). While I >

Documentation of what is appropriate for #guix?

Every now and then someone stumbles into #guix and ask questions that I've gleaned over time are off-topic (e.g. non-free software). While I have a pretty good idea what is appropriate for the channel, it is not clear to me where that is documentated. I figured maybe it is referenced in the code o

Re: The way to promote GUIX package manager

On 2022-02-05, Ricardo Wurmus wrote: > Ludovic Courtès writes: >> Vagrant Cascadian skribis: >> >>> The main two issues I'm aware of are... >>> >>> Issue with "guix pull" from the guix 1.2 version: >>> >>> ht

Re: disable suspend without user login

On 2022-01-28, Attila Lendvai wrote: >> The first reply already says what you have to do, i.e. set those two > > my problem was that i didn't know how to run dbus-launch on Guix. > > the proper incantation on Guix is: > > $ guix install glib:bin xhost > $ xhost + > $ ll `which gsettings` > $ su - >

Re: The way to promote GUIX package manager

On 2022-01-27, Yasuaki Kudo wrote: > Does Guix really run out of the box in Debian? > > I have never tried it but my friend Debian expert friend keeps telling me > that: > > * Just apt-get installing Guix doesn't work What doesn't work? The main two issues I'm aware of are... Issue with "guix p

Re: Clarifying blog post licensing

On 2022-01-26, Ludovic Courtès wrote: > 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 around to fixing > it). > > I’d like us to clarify that, wi

Re: File search

On 2022-01-21, Ludovic Courtès wrote: > Lately I found myself going several times to > to look for packages providing a given > file and I thought it’s time to do something about it. Hah! > The script below creates an SQLite database for the current set of > packages

Re: Preservation of Guix report 2022-01-16

On 2022-01-18, Ludovic Courtès wrote: > Timothy Sample skribis: >> A really important thing to do at this point is to verify that some >> reasonable looking computation is covered by what we are doing already. >> For instance, is every source used to build Guile (or Python or R) >> preserved? Thi

Re: Release v1.4 (or 2.0): process and schedule ?

On 2021-12-26, Maxim Cournoyer wrote: > Vagrant Cascadian writes: >> On 2021-12-19, Maxim Cournoyer wrote: >>> zimoun writes: >>>> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do >>>> we go for v1.4 or v2.0? ... >> Woul

Re: Guix wiki

On 2022-01-09, Matt wrote: > Concern 7: the manual can easily be read and modified while offline > > This is another good point. Things shouldn't be tied to the > internet. > > Fortunately, most wikis allow users to download the wiki (apart from > tools like wget). > > Unfortunately, the

Re: "make dist" fails ...

On 2022-01-07, Vagrant Cascadian wrote: > On 2022-01-07, Vagrant Cascadian wrote: >> Trying to run "make dist" from Debian running guix... but it fails. >> nckx confirmed to have similar issues. >> >> $ guix shell --container --pure --development guix guix git

Re: "make dist" fails ... en@boldquote: warning: PO file headder missing or invalid

On 2022-01-07, Vagrant Cascadian wrote: > Trying to run "make dist" from Debian running guix... but it fails. > nckx confirmed to have similar issues. > > $ guix shell --container --pure --development guix guix git imagemagick perl > less glibc glibc-locales > ... &

"make dist" fails ... en@boldquote: warning: PO file headder missing or invalid

Trying to run "make dist" from Debian running guix... but it fails. nckx confirmed to have similar issues. $ guix shell --container --pure --development guix guix git imagemagick perl less glibc glibc-locales ... $ export LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 # ensure UTF-8 locale available in gui

Re: Release v1.4 (or 2.0): process and schedule ?

On 2022-01-03, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> On 2021-12-21, Vagrant Cascadian wrote: > > [...] > >>> Would it be appropriate to fix the ~700 low-hanbging fruit issues that >>> are identified by: >>> >>> guix lint --c

Re: On raw strings in commit field

On 2022-01-03, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> How about using the output of git describe, which can unambigously >> include the most relevent tag, the number of commits since that tag, and >> the commit hash: >> >> $ git describe

Re: On raw strings in commit field

On 2021-12-28, Liliana Marie Prikler wrote: > Consider a package being added or updated in Guix. At the time of > commit, we have the tag v1.2.3 pointing towards commit deadbeef. We > therefore create a guix package with version "1.2.3" pointing to said > commit (either directly or indirectly).

Re: Convention for new “guix style“?

On 2021-12-22, zimoun wrote: > We had a discussion on IRC starting here [2]. This proposal is to > document in the manual and adapt ‘guix style’ to have one input per line > – as it was the case with the old style. Yes, please! One input per line is simpler to understand, simpler to implement, an

Re: Release v1.4 (or 2.0): process and schedule ?

On 2021-12-21, Vagrant Cascadian wrote: > On 2021-12-19, Maxim Cournoyer wrote: >> zimoun writes: >>> In both case, what is the target for a release date? I propose January >>> 31rst. WDYT? >> >> I'd like to fix #52051 before issuing the first rel

Re: Release v1.4 (or 2.0): process and schedule ?

On 2021-12-19, Maxim Cournoyer wrote: > zimoun writes: >> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do >> we go for v1.4 or v2.0? > > As I've mentioned previously, I'd go for a 1.4.0 release, since overall > we've refined and improved (greatly!) what we already had rathe

Re: guix fails to build on aarch64

On 2021-12-16, Vagrant Cascadian wrote: > Ever since commit: > > 224d437fb4147fe9eae277cbc8d39e1ef54bf5c9 gnu: guix: Update to 2a621f1. > > I've been unable to build "guix" on aarch64, several test suites > failed... I'll try to dig up the failures Here are

guix fails to build on aarch64

Ever since commit: 224d437fb4147fe9eae277cbc8d39e1ef54bf5c9 gnu: guix: Update to 2a621f1. I've been unable to build "guix" on aarch64, several test suites failed... I'll try to dig up the failures, but figured it was worth mentioning in case anyone else saw it too and had the failures more hand

Re: Reverse the naming of store items?

On 2021-12-04, Jacob Hrbek wrote: > Currently we use > /gnu/store/zzz16sfz4jxsdvf8j29rkd46psrc6dpj-emacs-ert-runner-0.8.0.drv > for store items which are painful to navigate from CLI using bash's > auto-completion as the first letter doesn't correspond to the package > name which usually requires d

Re: ZFS part of Guix? RFC?

On 2021-11-26, Denis Carikli wrote: > Or disable zfs as a dependency of Gnome? This specific point is a bit dated; the issue was both introduced and shortly after reverted in early July: 61ccd756e5ff73b2f8dc3449df537f1c5adb5872 gnu: libvirt: Support ZFS. 3fb6c96106df85ba47f8fea34b224071bd75a1

Re: default tar format for "make dist" and patch file length

On 2021-11-19, Vagrant Cascadian wrote: > On 2021-11-19, Philip McGrath wrote: >> On 11/19/21 09:54, Ludovic Courtès wrote: >>> Vagrant Cascadian skribis: >>>> So, I guess I'm leaning towards making the guix lint check a little more >>>> lenient

Re: Proposal: Build timers

On 2021-11-24, zimoun wrote: > On Tue, 23 Nov 2021 at 18:50, Julien Lepiller wrote: >> Do we even care that much about accuracy? I don't really care that the >> build takes 30 or 31 seconds, or even 1 minute, but I certainly care >> whether it takes 30s or 3h. I think this is also what SBUs give y

Re: ZFS part of Guix? RFC?

On 2021-11-24, Denis 'GNUtoo' Carikli wrote: > On Wed, 24 Nov 2021 13:03:18 +0100 > "pelzflorian (Florian Pelz)" wrote: > >> On Wed, Nov 24, 2021 at 01:45:19AM +0100, Denis 'GNUtoo' Carikli >> wrote: https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ > That article states that: >> Pure di

Re: default tar format for "make dist" and patch file length

On 2021-11-19, Philip McGrath wrote: > On 11/19/21 09:54, Ludovic Courtès wrote: >> Vagrant Cascadian skribis: >>> So, I guess I'm leaning towards making the guix lint check a little more >>> lenient. >>> >>> Thoughts? >> >> That sou

Re: default tar format for "make dist" and patch file length

On 2021-11-17, Vagrant Cascadian wrote: > On 2021-11-17, Ludovic Courtès wrote: >> Vagrant Cascadian skribis: >> >>> Ideally, "guix lint" would be run and issues fixed before applying >>> patches ... ! ... >>> Is it worth adding an inexpensiv

Re: default tar format for "make dist" and patch file length

On 2021-11-17, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> Ideally, "guix lint" would be run and issues fixed before applying >> patches ... ! > > On the bright side, that there’s just a dozen of issues on 20K packages > suggests it’s usuall

default tar format for "make dist" and patch file length

When running "make dist", guix apparently uses a very old tar format (presumably for maximal compatibility with tar implementations), which has a hard limit of 99 characters. For this reason, there is a guix lint check for filename lengths, but there are quite a few lint warnings in guix master an

Re: broken "make dist" on core-updates-frozen

On 2021-11-14, Vagrant Cascadian wrote: > There is a very long patch in core-updates-frozen for the gd package > which breaks "make dist" ... and about 10k packages are transitively > dependent on gd... so this seems (at least to me) really important to > fix before merging i

broken "make dist" on core-updates-frozen

Heads up for anyone working on merging core-updates-frozen into master! There is a very long patch in core-updates-frozen for the gd package which breaks "make dist" ... and about 10k packages are transitively dependent on gd... so this seems (at least to me) really important to fix before merging

Re: build issues with "make dist" generated tarball

On 2021-11-13, Vagrant Cascadian wrote: > Which generates an upstream tarball, in my case, > guix-1.3.0.8337-2bb0d.tar.gz, nice ... > > Then I try to build the .deb package for Debian using the tarball, but > various guix.*.info pages fail to build following some odd warnings: >

build issues with "make dist" generated tarball

There appear to be some errors in the translations or something on guix master... Take a recent guix master commit, such as: 2bb0d8bf0c51de73b7573982003ca8441e02af6d $ guix shell --container --pure --development guix guix git imagemagick perl less glibc glibc-locales $ export LC_ALL=en_US

Re: Request to use GNU guix reproducibility bugs data for research project | University of Waterloo

On 2021-11-02, Julien Lepiller wrote: > The guix data service also has some info on reproducibility. See > data.guix.gnu.org (Select master, the latest processed revision, and > add /package-reproducibility to the URL). This page compares between > berlin and bordeaux. Thanks, just added a link at

Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

On 2021-10-21, Vagrant Cascadian wrote: > For the last couple years guix has been applying simple workarounds in > u-boot packages to disable the features that required openssl due to > GPL/openssl license incompatibilities. > > I made an attempt at updating guix to u-boot 2021.10,

Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

On 2021-10-22, Leo Famulari wrote: > On Thu, Oct 21, 2021 at 11:17:03PM -0700, Vagrant Cascadian wrote: >> While openssl 3.0 is licensed compatibly with GPLv3, u-boot has portions >> which are GPLv2-only, so that's not as attractive of a way forward as >> one might hope

Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

On 2019-03-08, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> I'm not sure where it would be appropriate to add more comments >> regarding the GPL/Openssl incompatibilities; e.g. if someone were to >> propose adding one of the u-boot targets that requires it, t

Re: Incentives for review

On 2021-10-19, Ludovic Courtès wrote: > zimoun skribis: > >> On Tue, 19 Oct 2021 at 14:56, Ludovic Courtès >> wrote: >> One question is “encouragement” for reviewing, somehow. Asking for new >> package additions to go via guix-patches is a call making kind of >> equality between contributors.

Re: Public guix offload server

On 2021-10-21, Joshua Branson wrote: > Leo Famulari writes: > >> On Thu, Oct 21, 2021 at 02:23:49AM +0530, Arun Isaac wrote: >>> WDYT? How does everyone else handle big builds? Do you have access to >>> powerful workstations? >> >> Now I have access to a very powerful system on which I can test bu

Re: Code sharing between system and home services

On 2021-10-02, Ludovic Courtès wrote: > Maxime Devos skribis: >> Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]: >>> Joshua Branson skribis: >>> >>> > Apologies if I'm speaking for something I know very little >>> > about...Wouldn't it be nice if guix home services would accept a user

Re: Linux-libre source code will be taken offline

On 2021-09-27, Mark H Weaver wrote: > Leo Famulari writes: > >> On Sat, Sep 04, 2021 at 01:32:16PM -0700, Jason Self wrote: >>> The scripts are not being removed and my understanding is that Guix >>> only uses the scripts anyway. >> >> Okay, that's great. We do use the scripts. > > Unfortunately,

Re: Distributing Guix System Pinebook Pro images

On 2021-08-30, Mathieu Othacehe wrote: > I managed to build a Guix System image with the Sway WM for the Pinebook > Pro. The image is quite large (~6GiB) but it is bootable and works fine. I wonder how much diskspace savings you might get by leaving out the display manager... I typically just logi

Re: Distributing Guix System Pinebook Pro images

On 2021-08-29, Vagrant Cascadian wrote: > On 2021-08-29, Mathieu Othacehe wrote: >> The Guix website now offers Pinebook Pro Guix System images[1]. Those >> images can be directly copied on a micro-SD card and booted from. More >> details here[2]. > > It seems like

Re: Distributing Guix System Pinebook Pro images

On 2021-08-29, Mathieu Othacehe wrote: > The Guix website now offers Pinebook Pro Guix System images[1]. Those > images can be directly copied on a micro-SD card and booted from. More > details here[2]. It seems like I need to write up a hybrid pinebook/pinebook-pro bootloader definition, then tha

Re: Update on bordeaux.guix.gnu.org

On 2021-08-18, Christopher Baines wrote: > Around 2 months ago, bordeaux.guix.gnu.org came in to existence [1][2]. > > 1: > https://guix.gnu.org/en/blog/2021/substitutes-now-also-available-from-bordeauxguixgnuorg/ > 2: https://lists.gnu.org/archive/html/guix-devel/2021-06/msg00044.html > > This to

Re: source tarballs potentially built for each derivation

On 2021-08-01, Vagrant Cascadian wrote: > Turning this conversation into a bug, original thread around here: > > https://lists.gnu.org/archive/html/guix-devel/2021-05/threads.html#00427 For reference: bug#49810: source tarballs potentially built for each derivation live well,

source tarballs potentially built for each derivation

Turning this conversation into a bug, original thread around here: https://lists.gnu.org/archive/html/guix-devel/2021-05/threads.html#00427 On 2021-05-29, Vagrant Cascadian wrote: > On 2021-05-01, Leo Famulari wrote: >> On Sat, May 01, 2021 at 06:45:32PM -0700, Vagrant Cascad

Re: Honeycomb LX2 ARM board, problems booting Guix

On 2021-06-29, Christopher Baines wrote: > I've had a Honeycomb LX2 board for a few weeks now, but I've been > struggling to get Guix installed on it. > > The most success I've had is with an installer image written to either a > USB drive or nVME drive. I changed the bootloader to the > grub-efi-b

Re: Supporting *multiple* bootloaders for arm64 on a single install?

On 2021-06-19, Stefan wrote: >>> To support all of the above, I would need three separate bootloader >>> instances... one for Pinebook, one for Pinebook Pro, and lastly a >>> grub-efi bootloader. ... >> The chain bootloader itself is one Guix bootloader. >> >> I advise you to search for mails by S

Re: Supporting *multiple* bootloaders for arm64 on a single install?

On 2021-06-19, Danny Milosavljevic wrote: > On Sun, 06 Jun 2021 14:38:27 -0700 > Vagrant Cascadian wrote: > >> So, I've managed to get a single image that supports booting both the >> Pinebook and Pinebook Pro reasonably well! I can pop the microSD card >> out

Re: RISCV porting effort

On 2021-06-14, Efraim Flashner wrote: > On Sun, Jun 13, 2021 at 10:24:13AM -0700, Vagrant Cascadian wrote: >> On 2021-06-07, Efraim Flashner wrote: >> > Last week my HiFive Umatched¹ board came >> ... >> > Ubuntu has an image for the board² which booted up just

Re: RISCV porting effort

On 2021-06-07, Efraim Flashner wrote: > Last week my HiFive Umatched¹ board came ... > Ubuntu has an image for the board² which booted up just fine and I'm > using, since I didn't want to spend too long getting Debian to run on > the board. I, on the other hand, went straight for Debian, of course

Re: Rust freedom issue claim

On 2021-06-12, Bone Baboon wrote: > Ludovic Courtès writes: >> Bone Baboon skribis: ... > There are several options for how to move forward with the issue of the > Rust Foundation trademark policy. > > # Passive Approaches ... > * Do nothing > ** Advantages > *** No action needed by Guix. > **

Supporting *multiple* bootloaders for arm64 on a single install?

So, I've managed to get a single image that supports booting both the Pinebook and Pinebook Pro reasonably well! I can pop the microSD card out of one and put it into the other, and it boots! Maybe this is not a big deal to those used to x86, but in the ARM world, it is unfortunately more complica

Re: Applying patches to linux-libre-X.Y-source conditionally by architecture

On 2021-05-12, Vagrant Cascadian wrote: > When patching linux-libre-X.Y-source, is it possible to apply patches > per-architecture? I ask, because I'd like to apply an aarch64/arm64 > patch, but would hate to trigger linux-libre rebuilds for all > architectures just to add tri

Re: linux-libre source tarballs

On 2021-05-01, Leo Famulari wrote: > On Sat, May 01, 2021 at 06:45:32PM -0700, Vagrant Cascadian wrote: >> Pragmatically speaking, on slower platforms this is a huge resource >> overhead. So much so that ci.guix.gnu.org *usually* times out when >> generating the linux-l

Re: Which kernel series to use in the installer and for installed systems?

On 2021-05-27, Leo Famulari wrote: > On Thu, May 27, 2021 at 11:10:21AM -0700, Vagrant Cascadian wrote: >> Would it be too complicated to include both the latest LTS kernel and >> the most recently packaged kernel in the installer, and default to using >> the same kernel

<    1   2   3   >