Re: Using G-Expressions for public keys (substitutes and possibly more)

Hi Ludo, Am Donnerstag, den 21.10.2021, 22:13 +0200 schrieb Ludovic Courtès: > Hi! > > Liliana Marie Prikler skribis: > > > let's say I wanted to add my own substitute server to my > > config.scm. > > At the time of writing, I would have to add said server's public > > key to > > the

Re: Incentives for review

> On Wed, Oct 20, 2021 at 4:37 PM Thiago Jung Bauermann > wrote: [...] > One thing that would help me would be some way to “subscribe” to changes in > certain areas of Guix. That way, when a patch is submitted which touches > those areas I would be automatically copied on the emails that go to

Re: Public guix offload server

October 21, 2021 12:44 PM, "Tobias Geerinckx-Rice" wrote: > Joshua Branson 写道： > >> I've got an old Dell Optiplex 7020 with 30 gigs of RAM with a >> 3TB >> hard-drive just sitting around. My landlord and ISP is ok with >> me >> running a server. I just set everything up. Would this be >>

Re: Public guix offload server

All, zimoun 写道： Do you mean that trusted users would try WM-escape exploits? The world has been formed by warewolves inside communities purposely causing harm. Looking further back, Oliver the Spy is a classic examplar of trust networks being hollowed out. So… I cannot assume that on one

Re: Public guix offload server

Hi, On Thu, 21 Oct 2021 at 21:15, "Jonathan McHugh" wrote: > October 21, 2021 8:10 PM, "zimoun" wrote: >>> Now, we could spin up a separate VM for each user, and just take >>> the efficiency hit… Users would be safe from anything but >>> VM-escape exploits (which exist but are rare). >> >>

Re: Incentives for review

Hi, I mainly agree with the words of the message I am replying and my intent is to provide numbers about what we are speaking. >> It’s not about urgency but rather about not contributing to the growth >> of our patch backlog, which is a real problem. While I disagree for submitting new package

Re: Incentives for review

Hi Arun, Thiago’s idea to allow people to subscribe to certain *kinds* of issues when they are reported is also good. I agree this is a great idea. Recently, I unsubscribed from guix-patches. It's just too high volume. These days, I prefer to just search for issues using emacs-debbugs

Re: --with-source version not honored?

Hi, On Thu, 21 Oct 2021 at 22:22, Ludovic Courtès wrote: > For historical reasons, ‘--with-source’ only applies to leaf packages, > unlike most (all?) other transformation inputs. Oh, good to know! :-) Therefore, what I wrote before is partially wrong. Cheers, simon

Re: Disarchive and SHA

Hi, On Thu, 21 Oct 2021 at 22:28, Ludovic Courtès wrote: >> That’s why «Disarchive entry refers to non-existent SWH directory». > > However, some time ago, the zabbix.com URL was 200-OK, and at that point > SWH would have ingested it, no? Timothy pointed [1] then click to «Show all visits».

Re: Public guix offload server

October 21, 2021 8:10 PM, "zimoun" wrote: > >> Now, we could spin up a separate VM for each user, and just take >> the efficiency hit… Users would be safe from anything but >> VM-escape exploits (which exist but are rare). > > Do you mean that trusted users would try WM-escape exploits? >

Re: Incentives for review

If I recall, you can request Debbugs content if you email them. Jonathan McHugh indieterminacy@libre.brussels October 21, 2021 8:22 PM, "Arun Isaac" wrote: > Hi, > >> Thiago’s idea to allow people to subscribe to certain *kinds* of >> issues when they are reported is also

Re: Preservation of Guix Report

Hi Timothy! Timothy Sample skribis: > Early this summer I did a bunch of work trying to figure out which Guix > sources are preserved by the SWH archive. I’m finally ready to share > some preliminary results! > > https://ngyro.com/pog-reports/2021-10-20/ > > This report is already quite

Re: Public guix offload server

Hi, >> Currently, guix offload requires mutual trust between the master and >> the build machines. If we could make the trust only one-way, security >> might be less of an issue. > > It might! It's easy to imagine a second, less powerful offload > protocol where clients can submit only

Re: --with-source version not honored?

Hi, Phil skribis: > Any ideas if I can create a new package with --with-source and then > substitute it in the same command for an input of another package? For historical reasons, ‘--with-source’ only applies to leaf packages, unlike most (all?) other transformation inputs. Concretely, this

Re: Incentives for review

Hi, Ricardo Wurmus skribis: > I was thinking in the opposite direction: not incentives to recognize > reviewers but a closer relationship to the patch submitters, > i.e. “patch buddies” or mentorship. If I made myself officially > responsible for reviewing commits by Simon and all commits

Re: Incentives for review

Hi! Arun Isaac skribis: >> Thiago’s idea to allow people to subscribe to certain *kinds* of >> issues when they are reported is also good. > > I agree this is a great idea. Recently, I unsubscribed from > guix-patches. It's just too high volume. These days, I prefer to just > search for issues

Re: Disarchive update

Hey, On Thu, 21 Oct 2021 at 21:41, Ludovic Courtès wrote: > Really cool of the SWH folks to give you a higher rate limit. It is not to me particularly. :-) Anyone can create an account via Software Heritage Authentication service. Then

Re: Disarchive and SHA

Hi, zimoun skribis: > Along the process, I also notice, > > $ guix download > https://cdn.zabbix.com/zabbix/sources/stable/5.2/zabbix-5.2.6.tar.gz > > Starting download of /tmp/guix-file.rcYxyF > From https://cdn.zabbix.com/zabbix/sources/stable/5.2/zabbix-5.2.6.tar.gz... > download failed >

Re: Using G-Expressions for public keys (substitutes and possibly more)

Hi! Liliana Marie Prikler skribis: > let's say I wanted to add my own substitute server to my config.scm. > At the time of writing, I would have to add said server's public key to > the authorized-keys of my guix-configuration like so: > (cons* (local-file "my-key.pub")

Re: Disarchive update

Hi! Ludovic Courtès skribis: > Then there’s the mcron job that runs it once a day on berlin: > > > https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=27dc74fbe33a9d929b37994e825dc202385f87c0 > > We could run it as well on bayfront so we have a backup. I did that without

Re: Disarchive update

Hi, zimoun skribis: > Using, the Authentication mode from SWH [1] and this trivial patch, the > rate limit is at 1200 which allows to check and archive some packages. > For instance, now, > > for p in $(guix package -A | cut -f1 | grep "julia-"); > do >./pre-inst-env guix lint -c archival

Re: Test parallelism with CMake

Hi Greg, Greg Hogan skribis: > As I read the source, cmake-build-system should by default both build and > check with parallelism enabled. When I locally build a package only the > build phase runs with parallelism and tests are being run in serial. > > When I run a manual build (stopping an

Re: Authenticated Boot and Disk Encryption

Hi Reza, Reza Housseini skribis: > I came across this blog post > > and was wondering what is the state of authenticated boot and encryption in > Guix System? Nothing’s been done wrt. to “authenticated boot” AFAIK

Re: Guix+Jenkins slides/video

Hi Reza, On Fri, 15 Oct 2021 at 08:59, Reza Housseini wrote: > @zimoun I would also prefer to use Cuirass, could you sketch a similar setup > with Cuirass? Well, it is really low on my TODO list. Do not hold your breath. :-) Maybe, you could give a try and report your progress to

Re: Guix+Jenkins slides/video

Hello! Phil skribis: > A few of you might know me from guix-help or the Guix reddit channel. > > I did a talk last week and there's been some interest so thought I'd > post the link here: > https://www.devopsworld.com/agenda/session/617842 I discover this pretty late, the slides are

Re: Incentives for review

Hi, > Thiago’s idea to allow people to subscribe to certain *kinds* of > issues when they are reported is also good. I agree this is a great idea. Recently, I unsubscribed from guix-patches. It's just too high volume. These days, I prefer to just search for issues using emacs-debbugs and mumi.

Re: Public guix offload server

Hi Tobias, On Thu, 21 Oct 2021 at 18:31, Tobias Geerinckx-Rice wrote: > zimoun 写道： >> If I understand correctly, if a committer offloads to say Berlin >> or >> Bayfront, your concern is that the output will be in the >> publicly >> exposed store. Right? > > No, that would be far worse. I'm

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: Incentives for review

Ricardo Wurmus writes: > Katherine Cox-Buday writes: > >>> It’s not about urgency but rather about not contributing to the growth >>> of our patch backlog, which is a real problem. >> >> I have often seen folks on various projects worried about the size of >> various backlogs: bugs, issues,

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

Re: Public guix offload server

Leo, Leo Famulari 写道： Interesting... I'm not at all familiar with how `guix offload` works, because I've never used it. But it's surprising to me that this would be possible. Although after one minute of thought, I'm not sure why it wouldn't be. Very quickly: - You send an offload request

Re: Public guix offload server

Joshua Branson 写道： I've got an old Dell Optiplex 7020 with 30 gigs of RAM with a 3TB hard-drive just sitting around. My landlord and ISP is ok with me running a server. I just set everything up. Would this be powerful/interesting to some? Well, not going to lie: yes. I've heard that US

Re: Public guix offload server

Hi Simon, zimoun 写道： If I understand correctly, if a committer offloads to say Berlin or Bayfront, your concern is that the output will be in the publicly exposed store. Right? No, that would be far worse. I'm considering only a ‘private’ offload server shared by several trusted users,

Re: Incentives for review

Hi, On Thu, 21 Oct 2021 at 16:06, Ricardo Wurmus wrote: > Perhaps issues.guix.gnu.org could offer atom feeds for certain > keywords (e.g. the name of the module touched by the commits?). For instance, let have some number over the last year and half: File:

Re: Preservation of Guix Report

Hi zimoun, zimoun writes: > 2. For still unknown reasons, the bridge between SWH and Disarchive has > some holes. For instance, > > $ guix lint -c archive znc > gnu/packages/messaging.scm:996:12: znc@1.8.2: Disarchive entry refers > to non-existent SWH directory

Re: Incentives for review

Katherine Cox-Buday writes: It’s not about urgency but rather about not contributing to the growth of our patch backlog, which is a real problem. I have often seen folks on various projects worried about the size of various backlogs: bugs, issues, etc. I think it is human to want to

Re: Incentives for review

Thiago Jung Bauermann writes: 2. Going through the guix-patches mailing list looking for submissions that touch the few areas of Guix where I have at least some experience. I don’t think I found an effective method yet (in part the problem is on my side because the search function of

Re: Public guix offload server

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 builds. > > I agree that the Guix project

Re: Incentives for review

Ludovic Courtès writes: >> On Tue, 19 Oct 2021 at 14:56, Ludovic Courtès > But I also view things from a different angle: everyone contributes in their > own way, and each contribution is a gift. Maybe selfishly, but I really agree with this. I think this is just the nature of

Re: --with-source version not honored?

Hi Phil, On Wed, 20 Oct 2021 at 20:46, Phil wrote: > guix environment --with-source=foobar@9.5.0=/path/to/package > some-package-that-depends-on-foobar --ad-hoc foobar Well, I do not know what you are trying to achieve. > This gives me the warning that with-source will have no effect on >

Re: Tricking peer review

Hi, On Wed, 20 Oct 2021 at 19:03, Leo Famulari wrote: > 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

Re: Public guix offload server

Hi Tobias, On Wed, 20 Oct 2021 at 23:06, Tobias Geerinckx-Rice wrote: > Giving access only to people with commit access is a given, but > any shared offload server is a huge shared security risk. > > Guix is not content-addressed. Any [compromised] user can upload > arbitrary malicious

Re: Preservation of Guix Report

Hi Timothy, On Wed, 20 Oct 2021 at 15:48, Timothy Sample wrote: > Early this summer I did a bunch of work trying to figure out which Guix > sources are preserved by the SWH archive. I’m finally ready to share > some preliminary results! > > https://ngyro.com/pog-reports/2021-10-20/ Cool!

Re: Tricking peer review

Hi, Leo Famulari skribis: > 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