Re: CI status

On Wed, Dec 15, 2021 at 08:38:56PM +0100, Mathieu Othacehe wrote: > > > * The cuirass-remote-server Avahi service is no longer visible when > > running "avahi-browse -a". I strongly suspect that this is related to > > the static-networking update, even if I don't have a proof for > > now.

Re: CI status

On Wed, Dec 15, 2021 at 05:15:08PM +0100, Mathieu Othacehe wrote: > * The IO operations on Berlin are mysteriously slow. Removing files from > /gnu/store/trash is taking ages. This is reported here: > https://issues.guix.gnu.org/51787. I believe this is because we are running `guix gc

Re: Any go expert willing to help with updating IPFS?

It's likely that you need to use a newer version of Go. On Mon, Dec 13, 2021, at 02:51, Konrad Hinsen wrote: > Hi Guix, > > the version of IPFS in Guix is 0.8, and in view of the important changes > introduced in 0.10, that's obsolete by now. Which is why I am trying to > update to 0.11. > > My

Re: Derivations differ between computers?

On Wed, Nov 24, 2021 at 08:55:31PM -0500, Leo Famulari wrote: > Computer A: > -- > $ guix time-machine --commit=c70eadeaed9367e45be3797a17d3a34e5f8f67cd -- > build --no-grafts hello -d > /gnu/store/260bk0ch4np4h2yz5yqhf8hjbsyhwpmr-hello-2.10.drv > -- > > Compu

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

On Mon, Nov 22, 2021 at 07:10:48PM +0100, pelzflorian (Florian Pelz) wrote: > Maybe there is consensus that adding ZFS is a legal risk. I assume we are talking about the risk of litigation from Oracle (ZFS owner), right? Canonical decided in 2016 that the risk was low enough to take a chance and

Re: Making `python-next` the next `python`

On Mon, Nov 08, 2021 at 10:58:40AM +0100, Tanguy LE CARROUR wrote: > Just to make sure I don't ask any other stupid questions in the future, > where am I supposed to get this information from? I mean, I checked > `guix-devel` before posting, but could not find any mention to this topic. You have

Re: "Trojan Source" (CVE-2021-42574 and CVE-2021-42694): can 'guix lint' help someway?

On Mon, Nov 01, 2021 at 12:30:38PM +0100, Giovanni Biscuolo wrote: > as probably many of you have discovered, today was announced two new > vulnerabilities that exploits the "bidirectional override" Unicode > codepoints feature, making it possible to hide malicious source code in > comments and

Re: Split (gnu packages suckless) module

On Fri, Oct 29, 2021 at 06:22:28AM +0200, Liliana Marie Prikler wrote: > Am Donnerstag, den 28.10.2021, 15:55 + schrieb Mekeor Melire: > > 1. We generally do not create modules according to the groups of > > developers, but rather package declarations are grouped into > > modules

Re: Split (gnu packages suckless) module

On Thu, Oct 28, 2021 at 03:55:26PM +, Mekeor Melire wrote: > I would like to propose to split the (gnu packages suckless) module, > located in the /gnu/packages/suckless.scm source file. I agree. There are already a handful of "suckless" packages scattered in other modules. > The reasons for

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

On Fri, Oct 22, 2021 at 02:17:33PM -0700, Vagrant Cascadian wrote: > * Disable substitutes for relevent packages. Technically correct as > license incompatibility is only triggered on transmission of binary, > though maybe missing something about the spirit of the GPL. Maybe, but did anyone

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

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 for... What are other distros doing? Surely we can't be the only

Re: Tricking peer review

On Fri, Oct 15, 2021 at 08:54:09PM +0200, Ludovic Courtès wrote: > The trick is easy: we give a URL that’s actually 404, with the hash of a > file that can be found on Software Heritage (in this case, that of > ‘grep-3.4.tar.xz’). When downloading the source, the automatic > content-addressed

Re: Tricking peer review

On Tue, Oct 19, 2021 at 10:39:12AM +0200, zimoun wrote: > Drifting from the initial comment. One could name “tragic” commits are > commits which break “guix pull”. It is rare these days but there are > some reachable ones via “guix time-machine”. That's a good point. Is it a good idea to teach

Re: Public guix offload server

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? For my first several years with Guix... I handled big builds patience and care. I could have spent a small amount of money on powerful yet

Re: Public guix offload server

On Wed, Oct 20, 2021 at 11:06:05PM +0200, Tobias Geerinckx-Rice wrote: > Guix is not content-addressed. Any [compromised] user can upload arbitrary > malicious binaries with store hashes identical to the legitimate build. > These malicious binaries can then be downloaded by other clients, which >

Re: Linux-libre source code will be taken offline

On Mon, Sep 27, 2021 at 06:30:21PM -0400, Mark H Weaver wrote: > If we wish to preserve Guix users' ability to reproduce older systems, > we will need an 'origin' to fetch the Linux-libre deblob scripts from > that has a policy of retaining older releases, unchanged and at a fixed > location.

Re: branch master updated (a737f2f -> 0454910)

On Wed, Sep 22, 2021 at 02:48:30PM -0400, guix-comm...@gnu.org wrote: > lfam pushed a change to branch master > in repository guix. > > new 443740b gnu: linux-libre 5.14: Update to 5.14.7. > new ce45cd6 gnu: linux-libre 5.10: Update to 5.10.68. > new ce690cb gnu: linux-libre

Re: delete-generations or --delete-generations?

On Thu, Sep 09, 2021 at 05:14:53PM +0300, André A. Gomes wrote: > Let me share the position of a layperson. I noticed the lack of > symmetry between `guix system list-generations` and `guix package > --list-generations` and it felt like an inconsistency to me. And sometimes it confuses me too,

Re: delete-generations or --delete-generations?

On Wed, Sep 08, 2021 at 10:59:33PM +0200, Ludovic Courtès wrote: > zimoun skribis: > > I speculate too. :-) I guess because the idea behind “guix system” is > > one action at a time however “guix package” can compose actions in one > > transaction (guix package --install=foo --remove=bar). Using

Re: Can we find a better idiom for unversioned packages?

I think Ludo meant difftastic: https://github.com/Wilfred/difftastic On Wed, Sep 8, 2021, at 18:21, Jonathan McHugh wrote: > Hi Ludo, > > Just checking: > > Is Diffstatic a real tool? It wasnt quite clear to me (and I fancy > finding a new diff tool). > > > Jonathan

Re: [core-updates-frozen] Bug in binutils 1.37

On Mon, Sep 06, 2021 at 03:39:52PM +, Guillaume Le Vaillant wrote: > There's a bug in binutils 1.37, which we are using on the > core-updates-frozen branch. 2.37, right? :) > It's a file descriptor leak that can lead to 'malformed archive' errors > when linking libraries. We get this problem

Re: PEP 668 -- Graceful cooperation between external and Python package managers

On Tue, Sep 07, 2021 at 04:39:28PM +0200, Maxime Devos wrote: > See . > I haven't looked closely into this myself. > It might be relevant to Guix. > > For LWN subscribers, there is an article about the PEP: > . Here is

Re: Linux-libre source code will be taken offline

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.

Re: Can we find a better idiom for unversioned packages?

On Fri, Sep 03, 2021 at 10:03:47PM +0200, Xinglu Chen wrote: > ‘guix describe’ would show the commit of the guix.git repo used, > wouldn’t it? It shows the commit of currently effective revision of Guix, but it can't tell you what revision of Guix a built package came from. > If the date is not

Linux-libre source code will be taken offline

According to the linux-libre team in the #gnu-linux-libre IRC channel on Libera.chat, all releases of linux-libre before 4.4.282, 4.9.281, 4.14.245, 4.19.205, 5.4.143, 5.10.61, and 5.13.13 will be deleted from their servers, and their Git repo is also going to be rewritten to remove them. So, if

Re: Can we find a better idiom for unversioned packages?

On Fri, Sep 03, 2021 at 12:35:21PM -0400, Leo Famulari wrote: > 1) To know how old the package's source code is Oh, some more thoughts: What about extending `guix refresh` to help with your use case, assuming that it doesn't already? And what about packages that aren't based on

Re: Can we find a better idiom for unversioned packages?

On Fri, Sep 03, 2021 at 06:11:46PM +0200, Xinglu Chen wrote: > The date does give an idea of how old the version is, compare that to a > random string of 7 characters. If a user wants to know the exact > commit, they can always just run ‘guix edit PACKAGE’ and check the > ‘commit’ field in the

Re: Can we find a better idiom for unversioned packages?

On Thu, Sep 02, 2021 at 12:51:58PM -0400, Leo Famulari wrote: > On Wed, Sep 01, 2021 at 06:50:36PM +0200, Xinglu Chen wrote: > > > Commit dates don't have a consistent meaning: are they the time of > > > first revision of a commit? Final revision of a commit? Time of &

Re: Can we find a better idiom for unversioned packages?

On Tue, Aug 31, 2021 at 12:57:23PM -0700, Sarah Morgensen wrote: > I do not have a specific solution in mind, but I think there must be > one. I do have a few half-baked ideas, but I'm curious what we can all > come up with together. Or maybe you'll just tell me I'm just being > awfully picky :)

Re: Can we find a better idiom for unversioned packages?

On Wed, Sep 01, 2021 at 06:50:36PM +0200, Xinglu Chen wrote: > With the former, I can quickly see that the version is from 2021-01-31, > whereas with the latter, I would have to either find the VCS repo online > or go to my local checkout of it and browse the logs. > > > Commit dates don't have a

Re: Can we find a better idiom for unversioned packages?

On Wed, Sep 1, 2021, at 06:55, Xinglu Chen wrote: > I never felt like including the commit id in the version of a package > was useful; e.g., just seeing the first seven characters of the commit > id doesn’t really tell me anything about the version. I think it is > more useful to put the date of

Re: core-updates weather reports!

On Sat, Aug 21, 2021 at 02:57:51AM +0200, zimoun wrote: > The command you posted works if you previously did: > > guix pull --branch=core-updates-frozen Right! This is what I did in the last round (staging?), but this time I am not ready to pull. > instead, I am using: > > guix

Re: core-updates weather reports!

On Sat, Aug 21, 2021 at 08:53:08AM +0200, Mathieu Othacehe wrote: > Thanks for the reports! Cuirass is actually trying to build all packages > on top of the core-updates-frozen branch. Oh, good to know! And are the results gcroots? > A few weeks ago, I tried to work around the substitute timeout

Re: How did you handle making a GNU/Linux distribution?

On Sat, Aug 21, 2021 at 04:43:34PM +, Sage Gerard wrote: > My name is Sage. I wrote a cross-platform Guix-like package manager > called Xiden. It applies functional package management to the Racket > ecosystem. It is also free software under the GPLv3. The source is > available at

Re: core-updates weather reports!

On Fri, Aug 20, 2021 at 08:23:03PM -0400, Leo Famulari wrote: > As far as I can tell, the build farms are not actually trying to build > for core-updates-frozen, at least not in a systematic way. Am I > mistaken? Or are we only building the core subset of packages for this > bran

Re: core-updates weather reports!

On Fri, Aug 20, 2021 at 07:33:04PM -0400, Leo Famulari wrote: > I messed up the weather reports. I think they are based on the master > branch, not core-updates-frozen. I'll try again now. Alright, this time I actually used the correct branch. As far as I can tell, the build

Re: core-updates weather reports!

On Fri, Aug 20, 2021 at 07:25:21PM -0400, Julien Lepiller wrote: > Ant-bootstrap is correctly reported, with around 600 dependents. With 18000 > packages (on master), that's already 3% of packages. Maybe guix weather > doesn't report numbers properly, or is it 3% of packages with at least 10 >

Re: core-updates weather reports!

On Fri, Aug 20, 2021 at 05:40:18PM -0400, Julien Lepiller wrote: > We are still missing all of java, see http://issues.guix.gnu.org/49990 Thanks for the note. Is java contained within the missing 3% of packages? Or is `guix weather` broken?

core-updates weather reports!

On Fri, Aug 20, 2021 at 03:10:00PM -0400, Leo Famulari wrote: > I'm preparing some weather reports now. Basically, I use this command: Here they are! Things to note: These reports list missing packages with 10 or more dependents. So, important leaf packages may be missing... please try upgrad

Re: Core updates frozen.

On Fri, Aug 20, 2021 at 11:49:01AM +0200, zimoun wrote: > Is it possible to “guix weather” a specific branch? If it makes > sense. :-) I'm preparing some weather reports now. Basically, I use this command: $ while read branch; do while read system; do guix weather

Re: 02/02: gnu: syncthing: Prepare for cross-compiling.

On Sun, Aug 15, 2021 at 04:42:19PM -0400, Leo Famulari wrote: > On Mon, Apr 26, 2021 at 02:33:56PM -0400, guix-comm...@gnu.org wrote: > > efraim pushed a commit to branch master > > in repository guix. > > > > commit b33f5d7ff0627424a06fd0416761cd81c350e20a

Re: 02/02: gnu: syncthing: Prepare for cross-compiling.

On Mon, Apr 26, 2021 at 02:33:56PM -0400, guix-comm...@gnu.org wrote: > efraim pushed a commit to branch master > in repository guix. > > commit b33f5d7ff0627424a06fd0416761cd81c350e20a > Author: Efraim Flashner > AuthorDate: Mon Apr 26 21:30:15 2021 +0300 > > gnu: syncthing: Prepare for

Re: cowsay could attract copyright and trademark enforcement action

On Sun, Jul 11, 2021 at 10:56:33PM -0400, Bone Baboon wrote: > cowsay has many questionable files that could attract copyright and > trademark enforcement action. I doubt it. Many of these files have been in the cowsay source code since 1999 (apparently), and at least since 2004, according to

Re: guix weather exit status?

On Sat, Jul 10, 2021 at 04:41:44PM +0200, Ludovic Courtès wrote: > I agree we could change (or rather refine) semantics to exit with > non-zero when overall coverage is below 100%. In the example above, it > should return 0. Maybe we could distinguish between various cases like this: 0 means

guix weather exit status?

When a substitute is not available for all specified substitute servers, `guix weather` exits with a return code of '1', signaling failure. For example: -- $ ./pre-inst-env guix weather linux-libre; echo $? computing 1 package derivations for x86_64-linux... looking for 1 store items on

Re: my apoligies (was Re: Telemetry on by default kitty)

On Wed, Jun 16, 2021 at 07:32:34PM +0200, Giovanni Biscuolo wrote: > Please can you (both) explain me what's aggressive in my above phrasing? > > I'm not a native speaker and I'm pretty sure my english needs much > improvement, so I'll appreciate I you explain me what I did wrong and > why you

Re: Telemetry on by default kitty

On Tue, Jun 15, 2021 at 11:39:59PM +0200, Leo Prikler wrote: > Am Dienstag, den 15.06.2021, 19:24 +0200 schrieb Giovanni Biscuolo: > > I'm sorry you don't see the point, but Good grief... > Might be just me, but this phrasing appears a little aggressive given > the overall tone of the message

Re: Telemetry on by default kitty

On Sun, Jun 13, 2021 at 08:35:18PM +0200, Leo Prikler wrote: > Perhaps it's valuable for developers, but as a user I often have next > to no information about what data gets collected and for which purpose, > both of which are important for *informed consent*. If "the masses" > don't really care

Re: Rust freedom issue claim

On Sat, Jun 12, 2021 at 02:49:21PM -0400, Bone Baboon wrote: > Contents: > * Passive Approaches I definitely think a passive approach is best, unless the owners of the Rust trademark are taking actions that preclude it. Have they given us any reason to think that we need to do something about

Re: Cuirass 1.1 released

On Sun, Jun 13, 2021 at 12:59:55PM +0200, Mathieu Othacehe wrote: > We are pleased to announce the release of Cuirass 1.1. > > This is the second official release of Cuirass, the GNU Guix continuous > integration software. For the last six months, this project has been > funded through the NGI0

Re: Telemetry on by default kitty

On Sun, Jun 13, 2021 at 11:32:01AM +0200, Leo Prikler wrote: > Of course, there's the added bonus of the lead developer > expressing their views in a… rather aggressive tone to put it mildly, > but that's a social problem. To be fair to the author, the bug report described a simple update

Re: Some more rust/cargo insights

On Mon, Jun 07, 2021 at 08:48:11PM +0200, Leo Prikler wrote: > (Note, though, that a Go update would need to go through staging – not > an ideal situation either.) I have "cheated" regarding this in the past. Although changing the Go package should qualify for staging, it's so cheap to build Go

Re: Questions reqarding packaging and conventions

On Wed, Jun 02, 2021 at 07:55:31AM +0200, Ignacio Coterillo wrote: > I'm trying to debug and fix issues with Kerberos based authentication on both > Icecat and > qutebrowser and got a few questions: > > Via strace I found that icecat tries load `libgssapi.so` which doesn't exist. > > Trivially

Re: Ungrafting CI jobs

On Wed, Jun 02, 2021 at 07:53:35PM +0200, Mathieu Othacehe wrote: > I monitored a previous evaluation of the ungrafting Cuirass > specification that was more successful, with more than 17000 builds > performed in less than 24 hours, a new record! The recent evaluation is > sadly less victorious.

Re: Ungrafting CI jobs

On Tue, May 25, 2021 at 04:04:22PM -0400, Leo Famulari wrote: > I just rebased the branch and pushed again. The latest iteration failed en masse due to network timeouts between build farm nodes. Now that Cuirass is aware of dependencies, we have useful info as shown here: ht

Re: linux-libre source tarballs

On Sat, May 29, 2021 at 09:50:36PM -0700, Vagrant Cascadian wrote: > When it generates a tarball, all the various packages independently try > to recreate the source tarball; so you have at least fours jobs > ("linux-libre", "linux-libre-arm64-generic", "linux-libre-headers", > "linux-libre-bpf")

Re: Cuirass badges

On Fri, May 28, 2021 at 07:24:50PM +, Luis Felipe wrote: > Here's my initial proposal: > > https://luis-felipe.gitlab.io/media/2021/05/cuirass-badges-proposal-2021-05-28.png Wow! > And the source file: > > https://luis-felipe.gitlab.io/media/2021/05/cuirass-badges-proposal-2021-05-28.svg >

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

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 for the installation? I'm a bit confused about what you are

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

At the time of the recent 1.3.0 Guix release, the "default" linux-libre kernel series was the 5.11 series [0]: -- (define-public linux-libre-version linux-libre-5.11-version) (define-public linux-libre-pristine-source linux-libre-5.11-pristine-source) (define-public linux-libre-source

Ungrafting CI jobs

We started building the wip-ungrafting branch a week ago: https://ci.guix.gnu.org/jobset/ungrafting Some progress has been made, but not enough. This is partially due to , and also due to inefficient building of expensive bootstrap paths (namely, every Rust package

Re: Adding Trilinos to dealii package

On Sun, May 23, 2021 at 02:40:04PM +0200, zimoun wrote: > Hi, > > > PETSc and Trilinos (and many other libraries available in Guix) can be > > compiled with several different options. > > What is the standard way to deal with this in Guix? > > AFAIK, there is no concrete standard way. Only what

Re: What’s next?

On Sat, May 15, 2021 at 02:08:50PM -0400, Julien Lepiller wrote: > In the short term I'd like to merge the python optimisations. We discussed it > before release and thought it might be nice to merge them before c-u, from a > separate branch. +1 Have you tested them at all yet? If so, and they

Re: What’s next?

On Mon, May 17, 2021 at 10:35:22PM -0400, Joshua Branson wrote: > I suppose someone should fix the Hurd vulnerabilities as reported here: > > https://lists.gnu.org/archive/html/bug-hurd/2021-05/msg00079.html > > I don't think the vulnerabilities have been disclosed yet nor has there > been a fix

Re: Exim CVEs (21Nails)

On Mon, May 17, 2021 at 05:26:36PM +0200, Taylan Kammer wrote: > On the same day that article was published, neat! :-) There was advance warning, so we were ready :)

Re: What’s next?

On Sun, May 16, 2021 at 06:26:57PM +0200, Svante Signell wrote: > What about Hurd? I think the answer will be: what about it? :) We always welcome Hurd-related work here in Guix.

Re: Exim CVEs (21Nails)

On Mon, May 17, 2021 at 12:10:26PM +0200, Taylan Kammer wrote: > Hi Guix people, > > Just wanted to make sure everyone's aware, since we package Exim: > > https://blog.qualys.com/vulnerabilities-research/2021/05/04/21nails-multiple-vulnerabilities-in-exim-mail-server > > "Last fall, the Qualys

Re: GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)

On Mon, May 17, 2021 at 02:55:39PM +0200, zimoun wrote: > I remember a plot sent to guix-maintaainers about the number of grafts, > the core-updates merges and the release dates. I am not sure it is > really interesting and it is worth to resend it, or maybe dumping the > Cuirass database to

Re: Free software telemetry and the Guix System

On Fri, May 14, 2021 at 06:55:34PM +, Cook, Malcolm wrote: > > If these claims are true, then I think this is quite satisfactory for > > our purposes. I wouldn't even object to enabling the telemetry code via > > the CMake build-time option, as long as it's "opt-in", i.e. that each > > user

Re: GNU Guix 1.3.0rc2 available for testing!

On Sun, May 09, 2021 at 12:25:06PM -0400, Leo Famulari wrote: > I tested this on Debian x86_64, and it worked well. It's nice that it > offers to fetch the signing keys for the user. I also had a successful test on aarch64.

Re: GNU Guix 1.3.0rc2 available for testing!

On Sat, May 08, 2021 at 04:22:33PM -0400, Maxim Cournoyer wrote: > 1. Testing the binary tarball on the distro of your choice. You can > download > . >

Re: Expat 2.3.0 has been released

On Sun, May 09, 2021 at 04:23:16PM +0200, Sebastian Pipping wrote: > On 09.05.21 16:07, Leo Famulari wrote: > > On Sun, May 09, 2021 at 02:53:09PM +0200, Sebastian Pipping wrote: > >> The related soversions are: > >> > >> 2.2. 9 = 7:11:6 -> libexpatso.1.6

Re: Expat 2.3.0 has been released

On Sun, May 09, 2021 at 02:53:09PM +0200, Sebastian Pipping wrote: > The related soversions are: > > 2.2. 9 = 7:11:6 -> libexpatso.1.6.11 (GUIX today) > 2.2.10 = 7:12:6 -> libexpatso.1.6.12 > 2.3. 0 = 8: 0:7 -> libexpatso.1.7.0 (GUIX W.I.P.) > 2.4. 0 = 9: 0:8 -> libexpatso.1.8.0

Re: Authenticating maintenance.git

On Thu, May 06, 2021 at 01:03:21PM +0200, Ludovic Courtès wrote: > Hello Guix! > > I’ve added a ‘.guix-authorizations’ file in maintenance.git, at last! Thanks for taking care of this!

Re: linux-libre source tarballs

On Thu, May 06, 2021 at 01:10:45AM -0300, Alexandre Oliva wrote: > I have heard about early format changes, but since Linux itself has used > git archive to generate tarballs on the fly, and published digital > signatures based on archives generated this way, I presume an > expectation that

Re: GNU Guix 1.3.0rc1 available for testing!

On Wed, May 05, 2021 at 10:01:39AM -0700, Vagrant Cascadian wrote: > Yeah, not sure what best practices are for SysV init scripts these > days. For Debian I just documented that users of SysV in debian should > install daemonize; in future versions I may make it a soft alternate > dependency to

Re: Application for aarch64 computing resources

On Fri, Apr 02, 2021 at 02:43:20PM -0400, Leo Famulari wrote: > As part of our efforts to improve the situation, I've applied for > donation of aarch64 (64-bit ARM) computing resources for the Guix build > farm: > > https://github.com/WorksOnArm/cluster/issues/254 Unfortunat

Re: GNU Guix 1.3.0rc1 available for testing!

On Mon, May 03, 2021 at 09:38:56PM +0200, Tissevert wrote: > I've just given the binary tarball a spin on Devuan. Worked almost flawlessly > (daemonize wasn't installed and I missed the part when it was mentioned > because > I was a bit in a hurry but apart from that the overall experience was

Re: linux-libre source tarballs

On Mon, May 03, 2021 at 01:39:54PM -0300, Alexandre Oliva wrote: > You don't have to clone anything. If all you want is a tarball, use > 'git archive --remote'. Thanks, I didn't know about this feature. Is the tarball generation "stable" across Git releases? Or is it subject to change? We had

Re: ISO image: to xz or not to xz?

On Mon, May 03, 2021 at 01:47:02PM -0300, Alexandre Oliva wrote: > Indeed, install ISOs normally hold already-compressed filesystems or > files, so recompressing the .iso doesn't gain much if at all. To quote the introductory message of this thread: "The xz-compressed image is 23% smaller, which

Re: linux-libre source tarballs (disable "deblob-check"?)

On Sat, May 01, 2021 at 10:45:22PM -0400, Leo Famulari wrote: > The immediate solution is for me to make sure the tarballs have built > before committing the updates. I already do this for x86_64 and I can > start doing it for aarch64 too. Well, this is easier said than done, curr

Re: linux-libre source tarballs

On Sun, May 02, 2021 at 06:26:15PM -0400, Leo Famulari wrote: > In the meantime, can we make a 'kernel-updates' Cuirass job again, that > would build a kernel-updates branch on Savannah? Mistake: I'd want to call the branch wip-kernel-updates, so that it's rebaseable. > We had one

Re: linux-libre source tarballs

On Sun, May 02, 2021 at 11:08:49PM +0200, Ludovic Courtès wrote: > For packages we can add a ‘max-silent-time’ property, but there’s > nothing like this for origins. Oh, right. > I wonder if there’s a way we could address it in (gnu ci). > > Thoughts? In the meantime, can we make a

Re: GNU Guix 1.3.0rc1 available for testing!

On Sun, May 02, 2021 at 02:45:18PM -0400, Maxim Cournoyer wrote: > It should fail only once (as it currently would if Ludo's key was > missing), and display two messages/two commands instead of one to get > the missing keys. This is because we exit after the loop, based on the > exit_flag

Re: Jam: which licence is this?

On Sun, May 02, 2021 at 12:53:07AM -0400, Mark H Weaver wrote: > My understanding is that the 'license' field of a package in Guix has > _always_ been meant to summarize the license restrictions associated > with the package source (the output of "guix build --source"), and > *not* merely the

Re: branch master updated: gnu: sbcl: Update to 2.1.4.

On Sun, May 02, 2021 at 11:57:10AM +0200, Pierre Neidhardt wrote: > Indeed, as far as I can remember we've always updated SBCL directly on > master, because it's one of those exceptions. Alright, I didn't know that. Let's keep the status quo in that case. Maybe we should mention this kind of

What processor features does Guix support on i686?

I noticed that Linux 5.12 has a new config option regarding "Processor family". The default choice, Pentium-Pro (M686), is highlighted in this quote: -- Processor family 1. 486SX (M486SX) (NEW) 2. 486DX (M486) (NEW) 3. 586/K5/5x86/6x86/6x86MX (M586) (NEW) 4. Pentium-Classic (M586TSC)

Re: linux-libre source tarballs

On Sat, May 01, 2021 at 10:45:22PM -0400, Leo Famulari wrote: > The immediate solution is for me to make sure the tarballs have built > before committing the updates. I already do this for x86_64 and I can > start doing it for aarch64 too. I started building the current derivations

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

On Sun, May 02, 2021 at 12:17:59PM +0800, 宋文武 wrote: > Hello Leo, I see nothing wrong for assuming bad faith when security > fixes of packages are removed, in the end the truth matter, which I > believe is: You thought the patches for cario is not needed now on > core-updates, so you remove them.

Re: GNU Guix 1.3.0rc1 available for testing!

On Sun, May 02, 2021 at 12:05:42AM -0400, Leo Famulari wrote: > I've attached a patch. I sent this before seeing your patch. Feel free to disregard it.

Re: GNU Guix 1.3.0rc1 available for testing!

On Sat, May 01, 2021 at 10:52:18PM -0400, Maxim Cournoyer wrote: > > https://guix.gnu.org/manual/en/ > > https://guix.gnu.org/manual/devel/en/ > > Thank you for pointing that issue; I caught the problem with > guix-install.sh before posting, but overlooked that one. As you > pointed, that won't

Re: GNU Guix 1.3.0rc1 available for testing!

On Sat, May 01, 2021 at 05:25:45PM -0400, Leo Famulari wrote: > Maybe we should update the manual to mention "1.3.0rc1" and the correct > key. I've attached a patch. > > 1. Testing the binary tarball on the distro of your choice. You can > > download <

Re: branch master updated: gnu: sbcl: Update to 2.1.4.

On Sat, May 01, 2021 at 07:53:26AM -0400, guix-comm...@gnu.org wrote: > commit c04dfb39f62f764b1c3988d9b0fcedc8221afa67 > Author: Pierre Neidhardt > AuthorDate: Sat May 1 13:53:09 2021 +0200 > > gnu: sbcl: Update to 2.1.4. > > * gnu/packages/lisp.scm (sbcl): Update to 2.1.4. Hi

Re: linux-libre source tarballs

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-libre aarch64 tarballs: > > >

Re: GNU Guix 1.3.0rc1 available for testing!

On Sat, May 01, 2021 at 01:45:57AM -0400, Maxim Cournoyer wrote: > https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.x86_64-linux.tar.xz I tested the binary tarball on x86_64. I used `guix package --export-manifest > manifest` before beginning the test, so that I could easily recreate my

Re: wip-ungrafting builds stuck

On Fri, Apr 30, 2021 at 06:32:54PM +0200, Ludovic Courtès wrote: > I’ve just merged ‘wip-ungrafting’ in master! It was at 76% according to > , with mostly ARM builds missing compared to > ‘master’. Now we have fresh binaries to download (or build)! Hooray! > Thanks Leo

Re: RISC-V is giving away developer boards

On Fri, Apr 30, 2021 at 06:36:29PM +0200, Ludovic Courtès wrote: > Could interested developers raise their hands? :-) I previously applied for early access to the BeagleV: https://beagleboard.org/beaglev I wasn't selected and I decided to focus on aarch64 for now. Hopefully some other people

Re: ISO image: to xz or not to xz?

On Wed, Apr 28, 2021 at 10:18:01PM +0200, Ludovic Courtès wrote: > What do people think? We've received several complaints about the images being compressed. I guess we might as well offer it uncompressed, and maybe offer both ways.

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

On Wed, Apr 28, 2021 at 12:43:53PM -0400, Mark H Weaver wrote: > I'm sorry if this comes off as obtuse, but having now re-read all of my > messages in this thread, I honestly do not see what I did wrong here. > I will need some help to understand. It's common advice that managers and leaders

Re: A "cosmetic changes" commit that removes security fixes

On Mon, Apr 26, 2021 at 11:56:22PM +0200, Giovanni Biscuolo wrote: > No, I simply misunderstood, sorry for the noise! Okay, and thanks for asking! It's important to clarify these things; it's not just noise :) This kind of knowledge is something I picked up over time, but I'm not sure it's

Re: A "cosmetic changes" commit that removes security fixes

update, done in a single atomic commit. That's not how we work. If there is some documentation or messaging that suggests that anyone should ever use the core-updates branch, please let us know and we will fix that. The only branch you should use is the master branch, unless you are testing s

<    1   2   3   4   5   6   7   8   9   10   >