Re: Guix on aarch64
Hi Leo, > On Sun, Aug 26, 2018 at 12:13:44PM -0400, Mark H Weaver wrote: >> Regardless, I think we should seriously consider moving the Aarch64 >> build slave(s) to Hydra for now, until Cuirass is more mature. > > I agree with your points about why berlin.guixsd.org makes it harder to > maintain the aarch64 port. I use Berlin substitutes alongside those of > Hydra but I don't actually do any build debugging with Berlin yet > because I don't know how to use the interface effectively. I think our use of Hydra is not sustainable. It requires regular manual intervention by Mark, careful tuning of SQL queries, conscientious clean up of old substitutes, and we have not a single person familiar with the Perl code. We do have people working on Cuirass, though. Let’s add important missing features to Cuirass instead of making efforts to keep Hydra on life support. > It would be really great to get another pair of machines with similar > capabilities. I agree. We need volunteers to pick a particular configuration (my suggestion is to start with an Overdrive 3000 rack server[1]) and find a place to host these servers. We have not been successful in delegating this to other people and unfortunately the maintainers cannot take care of this themselves. [1]: https://shop.softiron.com/product/overdrive-3000/ -- Ricardo
Re: [Next browser] Common Lisp: mgl-pax: Package SWANK-BACKEND does not exist.
Hi all, There are a few different messages in this thread that I could reply to, but I'll do my best to address them all here. On Fri, 24 Aug 2018 14:56:19 +0200 l...@gnu.org (Ludovic Courtès) wrote: > Hi Pierre, > > Pierre Neidhardt skribis: > > > I have no clue what this SWANK-BACKEND is. I can find > > SWANK/BACKEND in the source however. Maybe my misunderstanding of > > Common Lisp... > > > > Any clue? > > I’m clueless ;-) but I’ve Cc’d one of our local CL experts. > Any ideas, Andy? Expert is a bit strong, but I'll try my best. I wasn't able to dive deep into this particular issue this weekend, but I did try to bring myself back up to speed by rebuilding the currently upstreamed CL packages as well as my local additions. The good news here is that I've finally found out why our slynk package doesn't build on sbcl, and that might be relevant to this problem. As for the initial error - it looks like it's because swank's system definition file only compiles swank-loader, which I guess is because it wants to use that loader to load the rest of the system. As a result the swank-backend package never gets added to the built swank package. The PR linked in the upstream bug report looks like it addresses that issue by adding all of the source files to the system's components. The log listed in the report when using that PR doesn't show the full details - but I've just found out that some warnings are being treated as errors by sbcl. It might be that there's some warning shown earlier on which is causing the reported compilation failure, despite the fact that it's reported as a benign-seeming warning. I haven't been able to figure out whether or not this is a guix-specific problem. I haven't forgotten that I'd promised to deliver some build system improvements a while back - I've gotten that all formatted into commits now so I'll try to send that in later this week if I can find time. > > Ludo’. Hoping that helps, -- Andy
Re: Email address update
Hi Pierre, You have 2 options: 1: Just send a patch against all headers you are in and do the .mailmap part as well. 2: Don't update the headers and until your next commit in one of those files. Update .mailmap only. Pierre Neidhardt transcribed 826 bytes: > Hi Guix! > > I've switched to a new email address (this one). What's the procedure > to update it in the headers of the Guix source? > > -- > Pierre Neidhardt > https://ambrevar.xyz/
Re: Email address update
Pierre Neidhardt transcribed 906 bytes: > > > 1: Just send a patch against all headers you are in and do the .mailmap > >part as well. > > I can do that. Any recommendation for the commit message? I know GNU and > Guix > are quite strict in that regard. There are enough examples for .mailmap and header changes. Recently I made a batch change on my email, and there are too much commits for my lines on .mailmap. headers are still a bit more formal, mailmap just needs to make sense. > -- > Pierre Neidhardt > https://ambrevar.xyz/
Re: A major milestone in bootstrapping
jerem...@pdp10.guru writes: > Today I am proud to announce a combo of releases with major milestones. > > First stage0, reached Release version 0.2.0; which includes the following: > A 250byte hex0 bootstrap binary that is self-hosting and builds hex1, > which builds hex2, which bootstraps M0 macro assembly which has been > used to make: > > The world's FIRST C compiler written in M0 macro assembly, supporting: > structs > unions > inline assembly > function pointers > > http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage2/cc_x86.s > > which is capable of compiling reproducibly: > > The newly released M2-Planet V1.0 > https://github.com/oriansj/M2-Planet > > Which is a self-hosting C compiler which is 100% deterministic by design > with support for all the features needed to build the pieces of: > > mescc-tools > https://savannah.nongnu.org/projects/mescc-tools > > which is capable of building M2-Planet from it's M1 macro seed. > > Soon we hope to finish the MesCC bootstrap from M2-Planet and then we > will have a complete bootstrap path from 250byte hex0 all the way up to > gcc ^_^ > > -Jeremiah Orians Interesting... I'm looking at https://github.com/oriansj/M2-Planet/blob/master/seed.M1 How was it written? It seems like a monumental task to write all that and keep enough context in one's head! Then again, I have never written assembly before...
Re: Email address update
Pierre Neidhardt writes: > Ok, so that would be one commit per file then. No! One commit for everything.
Re: Email address update
Pierre Neidhardt writes: >> 1: Just send a patch against all headers you are in and do the .mailmap >>part as well. > > I can do that. Any recommendation for the commit message? I know GNU and > Guix > are quite strict in that regard. See commit 4a78fd4617908546be15d2c101f5cab512c71f8e :-)
RE: [rb-general] A major milestone in bootstrapping
> Interesting... I'm looking at > https://github.com/oriansj/M2-Planet/blob/master/seed.M1 > How was it written? It seems like a monumental task to write all that and > keep enough context in one's head! > Then again, I have never written > assembly before... If you'll notice https://github.com/oriansj/M2-Planet/blob/master/seed.M1#L2 It explicitly says it was generated from stage0 https://savannah.nongnu.org/projects/stage0/ Specifically cc_x86 http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage2/cc_x86.s Which was built by M0: http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage1/M0-macro.hex2 Which was built by hex2: http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage1/stage1_assembler-2.hex1 Which was built by hex1: http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage1/stage1_assembler-1.hex0 Which was built by hex0: http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage1/stage1_assembler-0.hex0 Which was the 250byte seed used Well the work started back in 2016 with http://git.savannah.nongnu.org/cgit/stage0.git/tree/Linux%20Bootstrap/hex0.s and http://git.savannah.nongnu.org/cgit/stage0.git/tree/Linux%20Bootstrap/hex0.hex It was written one function at a time, with the arguments passed in registers and careful preservation of everything passed. - Jeremiah Orians
FOSDEM 2019 - dev-room proposal
* Minimalistic Languages Every year FOSDEM allows for dev-rooms that need to appeal to a wider audience and do not overlap with other dev-rooms. Programming languages are popular and some of the large languages get their own, such as Python and Rust. See the devrooms section on https://archive.fosdem.org/2018/schedule/ Manolis and I want to submit a plan for 'Minimalistic Languages - for big ideas' dev-room. Good examples that fit the room are - mes and reproducible builds - Guile and Guix - Guile JIT - Lua JIT - Lua for scriptable projects (example?) Anyone anything to add to this list? More ideas is better. Other languages that could fit are Forth, Smalltalk, Tcl, Rebol. Provided they have a big idea. Note that JVM languages and languages that compile to Javascript do not fit the room. They probably have their own dev-rooms anyway. Haskell and other Lisps may fit too (if they don't get their own room). We think with enough good projects our dev-room will be of interest. Pj & Manolis
Re: Guix on aarch64
Hi Ricardo, Ricardo Wurmus writes: >> On Sun, Aug 26, 2018 at 12:13:44PM -0400, Mark H Weaver wrote: >>> Regardless, I think we should seriously consider moving the Aarch64 >>> build slave(s) to Hydra for now, until Cuirass is more mature. >> >> I agree with your points about why berlin.guixsd.org makes it harder to >> maintain the aarch64 port. I use Berlin substitutes alongside those of >> Hydra but I don't actually do any build debugging with Berlin yet >> because I don't know how to use the interface effectively. > > I think our use of Hydra is not sustainable. It requires regular manual > intervention by Mark, careful tuning of SQL queries, conscientious > clean up of old substitutes, and we have not a single person familiar > with the Perl code. > > We do have people working on Cuirass, though. Let’s add important > missing features to Cuirass instead of making efforts to keep Hydra on > life support. I fail to see how moving the Aarch64 build slaves to Hydra in the short term would constitute an "effort to keep Hydra on life support", nor how this would hinder efforts to improve Cuirass. I agree that we should retire Hydra when Cuirass matures. My proposal is not about helping Hydra, but rather about *using* Hydra, our only sufficiently useful CI system right now, to make our Aarch64 port usable. It currently isn't. If anyone believes that I'm mistaken about our Aarch64 port being unusable, then please help Benjamin Slade install Guix on his Aarch64 system. I'd be glad to be proved wrong. https://lists.gnu.org/archive/html/help-guix/2018-08/msg00085.html Mark
Re: Guix on aarch64
Hi again, Ricardo Wurmus writes: > We do have people working on Cuirass, though. Let’s add important > missing features to Cuirass instead of making efforts to keep Hydra on > life support. Perhaps the idea is to use the fact that Aarch64 is unusable to motivate people to work on Cuirass? If that's the idea, then we could go further. We could bring Hydra offline right now, and subject all Guix users to the same problems that Aarch64 users are experiencing today. That ought to help motivate people to work on Cuirass with even greater urgency. If that's not the idea, then I'm not sure what advantage you see in leaving Aarch64 in a bad state, until some unknown date in the future when Cuirass becomes sufficiently mature. Mark
Re: Guix on aarch64
Hi Mark, I think you are overreacting and I really don’t think the sarcastic response is justified. This kind of communication is very demotivating to me. If this is an urgent problem (and your hostility indicates that it is) then by all means go ahead and add one of the aarch64 build nodes to hydra and remove the same from berlin. Please note that I cannot take care of this myself right now. My statement about Hydra was merely to clarify our short-term strategy. That’s all I have to say about this. -- Ricardo
Re: Guix on aarch64
On Mon, Aug 27, 2018 at 10:04:12AM +0200, Ricardo Wurmus wrote: > I think our use of Hydra is not sustainable. It requires regular manual > intervention by Mark, careful tuning of SQL queries, conscientious > clean up of old substitutes, and we have not a single person familiar > with the Perl code. True, but in the meantime the Hydra web interface makes it relatively easy to judge when a branch is ready to merge into master. Can you recommend a workflow for doing this with Cuirass on berlin? > I agree. We need volunteers to pick a particular configuration (my > suggestion is to start with an Overdrive 3000 rack server[1]) and find a > place to host these servers. We have not been successful in delegating > this to other people and unfortunately the maintainers cannot take care > of this themselves. In my home I can host small-ish systems that don't require serious climate control. So, not the Overdrive 3000, but perhaps the Overdrive 1000. signature.asc Description: PGP signature
Re: Guix on aarch64
Leo Famulari writes: >> I agree. We need volunteers to pick a particular configuration (my >> suggestion is to start with an Overdrive 3000 rack server[1]) and find a >> place to host these servers. We have not been successful in delegating >> this to other people and unfortunately the maintainers cannot take care >> of this themselves. > > In my home I can host small-ish systems that don't require serious > climate control. So, not the Overdrive 3000, but perhaps the Overdrive > 1000. Thank you for the offer, Leo. Shall we discuss the details on guix-sysadmin? -- Ricardo
Re: Guix on aarch64
Hi Ricardo, Ricardo Wurmus writes: > I think you are overreacting and I really don’t think the sarcastic > response is justified. This kind of communication is very demotivating > to me. Believe it or not, I wasn't conscious of the fact that I was being sarcastic or hostile. Sorry about that. I'm grasping at straws trying to understand your reasoning. In general, I _do_ think that sometimes it's better to motivate people to work on a proper solution, by refusing temporary workarounds. > If this is an urgent problem (and your hostility indicates that it is) > then by all means go ahead and add one of the aarch64 build nodes to > hydra and remove the same from berlin. I lack access to both Berlin and to the Aarch64 build slaves, so I can't do this. Note that I'm not asking for access; I actively do not want it. Also, Ludovic has stated multiple times that he prefers for the Aarch64 build slaves to be connected to Berlin, not Hydra, and I would not implement a contrary policy without his consent. Mark
Re: Guix on aarch64
Hi again, > Ricardo Wurmus writes: >> I think you are overreacting and I really don’t think the sarcastic >> response is justified. This kind of communication is very demotivating >> to me. > > Believe it or not, I wasn't conscious of the fact that I was being > sarcastic or hostile. I should clarify. I wasn't trying to be sarcastic when I wrote this: > Perhaps the idea is to use the fact that Aarch64 is unusable to > motivate people to work on Cuirass? because, as I said, I think it's sometimes justified to block a temporary workaround to motivate implementation of a proper fix. My suggestion that perhaps we should take Hydra offline was an attempt to argue against the idea by reductio ad absurdum, but I can see how it came off as sarcastic and hostile. Anyway, I guess I'm under too much stress and hostility is leaking out. Sorry. I should probably take a break from communicating for a while. Regards, Mark
Re: Guix on aarch64
Mark H Weaver writes: > Ricardo Wurmus writes: >> I think you are overreacting and I really don’t think the sarcastic >> response is justified. This kind of communication is very demotivating >> to me. > > Believe it or not, I wasn't conscious of the fact that I was being > sarcastic or hostile. Oh, who am I kidding? No one but myself, I expect. You're right. My message was sarcastic and hostile. I'm embarrassed to have been in denial about that fact for any length of time. Please accept my sincere apologies. Thank you for your consistently level-headed communications, even in the face of hostility. This is not an urgent matter. Do as you think is best. I trust your judgment more than my own at this point. Mark
