Re: Seeking "complex" system examples / guixops
Le 1 août 2019 19:55:54 GMT+02:00, Hartmut Goebel a écrit : >Hi Ricardo, >> the Guix sysadmins are using Guix to build complex systems. Our >> configurations are available in the “hydra” directory of the >maintenance >> repository: > >Many thanks for pointing me there. In dded this grow quite complex >since >I checked last time. > >And it's complex enough to convince me that some "GuixOps" would be >helpful, implementing hight level abstraction and more defaults. (This >is what I applied for at NGI Zero PET just today). I don't know if that's complex enough for you, but here are my system definitions: https://framagit.org/tyreunom/system-configuration
Re: Seeking "complex" system examples / guixops
Hi Ricardo, > the Guix sysadmins are using Guix to build complex systems. Our > configurations are available in the “hydra” directory of the maintenance > repository: Many thanks for pointing me there. In dded this grow quite complex since I checked last time. And it's complex enough to convince me that some "GuixOps" would be helpful, implementing hight level abstraction and more defaults. (This is what I applied for at NGI Zero PET just today). -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Ideas for security grant (was Re: Deadline security grant is August 1st.)
Am 31.07.19 um 14:28 schrieb Hartmut Goebel: > Am 29.07.19 um 18:22 schrieb Pierre Neidhardt: >> Did anyone else apply? I applied last-minute with GuixOp - abstraction layers for defining complex systems on a higher level -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Will August 16-18, Berlin actually happen?
Hartmut, Hartmut Goebel 写道： /gnunet-events Just in case it was a typo: did you mean to send this to guix-devel? Kind regards, T G-R signature.asc Description: PGP signature
Re: Will August 16-18, Berlin actually happen?
Am 01.08.19 um 18:12 schrieb Hartmut Goebel: > I consider traveling to the August 16-18 Meeting in Berlin. Sorry, I did send this to the wrong list! This meeting is planned for GNUet! Sorry for disturbing. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | signature.asc Description: OpenPGP digital signature
Re: Will August 16-18, Berlin actually happen?
Hi Hartmut, Hartmut Goebel writes: > Hi, > > I consider traveling to the August 16-18 Meeting in Berlin. > https://md.darmstadt.ccc.de/gnunet-events# state this will "happen", > but the announcements sounds more like "planning" for me. (Also I > would need to fill the gap from Sunday to Wednesday, when cccamp > starts, which is a bit unfortunate.) > > Will this meeting actually happen? Is there some kind of agenda > already? Who//How many will attend? This is my first time hearing of this event, so I'm afraid I can't answer any of your questions. Coincidentally, I will be in Berlin those three days, so please let me know if you hear back -- I'm interested in attending. (On that note, who is sva? Perhaps I should sign up.) Regards, Jakob signature.asc Description: PGP signature
Please merge wip-haskell-updates (Re: [bug#36807] remove obsolete broken haskell packages)
Hi all, Timothy, On 25. Jul 2019, at 15:29, Timothy Sample wrote: > Other than that, LGTM. Thanks! (Do you have commit access now or > should I push these?) I do have commit access now, but for the moment I’m keeping to the branch wip-haskell-updates. Thus, I’d ask you (or someone) to merge that (or the parts you deem appropriate). I’ve incorporated your comments, and removed ghc-packedstring. In addition, the branch incorporates some other patchsets: #36493: updating GHC-included haskell dependencies (this one is already in core-updates) #36562: downgrade ansi-terminal to be compatible with the package set #36663: adding elm compiler dependencies (just a few extra ghc packages) #36692: GHC version 8.6.5 (just as a package for now, not used to build anything) #36807: this bug report, removing three deprecated packages no ticket: Skip tests for three Haskell packages that fail on i686 only (and seem harmless): ghc-trifecta, ghc-yaml, ghc-libmpd-haskell. Cheers Robert > Hi Robert, > > Robert Vollmert writes: > >> This series removes some outdated packages that don’t build and >> aren’t depend on. > > I remember that we intended to remove these last year. Indeed, Ricardo > mentioned it when we were finishing up the upgrade to GHC 8.4: > >https://lists.gnu.org/archive/html/guix-devel/2018-09/msg00330.html > > Based on that, we could also get rid of “ghc-packedstring” if it doesn’t > have any dependants.
Will August 16-18, Berlin actually happen?
Hi, I consider traveling to the August 16-18 Meeting in Berlin. https://md.darmstadt.ccc.de/gnunet-events# state this will "happen", but the announcements sounds more like "planning" for me. (Also I would need to fill the gap from Sunday to Wednesday, when cccamp starts, which is a bit unfortunate.) Will this meeting actually happen? Is there some kind of agenda already? Who//How many will attend? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | signature.asc Description: OpenPGP digital signature
Re: Support rsync to help Chinese users to setup mirrors
Hi, > We've encountered some issues when mirroring Guix replated repos in China. > https://github.com/ustclug/mirrorrequest/issues/96 > https://github.com/tuna/issues/issues/199 > https://github.com/ustclug/mirrorrequest/issues/96 > > Is there any plan to support rsync recently? What exactly is required from us? If it helps I would like to make it possible for others to sync the nar cache on berlin with some other locations. Perhaps that would already be an improvement. -- Ricardo
Re: bug#36878: guix system reconfigure broken
Robert Vollmert writes: > Yes, it seems it does! Great :) CC'ing Chris and Dave since I don't have write access -- can we fast-track #36880 into master? I'd consider this to be a high-priority bug fix. Regards, Jakob signature.asc Description: PGP signature
Re: Does it make sense to package debops?
Hi Hartmut, > I just wonder whether I should package debops, a collection of ansible > roles for managing Debian systems. > > Shall I? > > I'm curious since you this is not to support guix. OTOH, ansible is > packaged, too, which is not of much use for guix IMHO . I think it’s useful to have Ansible installable via Guix. You can use it to deploy remote machines. While you probably wouldn’t use Ansible to modify your Guix System it can still be valuable in a mixed environment where the other machines don’t use Guix. I think it’s fine to add debops to Guix. It’s free software, uses free software, and is used to manage free software distributions. It’s all good in that regard. -- Ricardo
Does it make sense to package debops?
Hi, I just wonder whether I should package debops, a collection of ansible roles for managing Debian systems. Shall I? I'm curious since you this is not to support guix. OTOH, ansible is packaged, too, which is not of much use for guix IMHO . -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Support rsync to help Chinese users to setup mirrors
Hi folks! We've encountered some issues when mirroring Guix replated repos in China. https://github.com/ustclug/mirrorrequest/issues/96 https://github.com/tuna/issues/issues/199 https://github.com/ustclug/mirrorrequest/issues/96 Is there any plan to support rsync recently? I'm doing an experiment to use Guix in our product development, but we need China mirrors. The connection outside China is utterly unstable because of some reasons. In the Chinese discussion, someone mentioned that @Ludo had given them a config script, however, it's just a reverse-proxy, and China servers have problems to visit upstream because of the firewall. If Guix upstream support rsync, then it's easier for us to mirror. Feedbacks are welcome. Best regards. -- GNU Powered it GPL Protected it GOD Blessed it HFG - NalaGinrut Fingerprint F53B 4C56 95B5 E4D5 6093 4324 8469 6772 846A 0058 signature.asc Description: PGP signature
Re: bug#36878: guix system reconfigure broken
Thanks for reporting this, I experienced the same issue but blamed it on my own infrastructure instead! Good to hear it's resolved now. Alex Robert Vollmert writes: > Hi, > > it appears that commit 5c8c8c455420af27189d6045b3599fe6e27ad012 > > guix system: Reimplement 'reconfigure’. > > breaks guix system reconfigure. In particular, after reconfiguring, > shepherd doesn’t know about the updated versions of services. > > The usual output below is missing; after reverting the commit it’s > fine again. > > guix system: loading new services: … > To complete the upgrade, run 'herd restart SERVICE' to stop, > upgrade, and restart each service that was not automatically restarted. > shepherd: Evaluating user expression (let* ((services (map primitive-load > (?))) # ?) ?). > shepherd: Service user-homes has been started. > shepherd: Service term-auto could not be started. > bootloader successfully installed on '/dev/sda’ > > I see that some system tests for “guix system reconfigure” were added > after this change. Might I suggest adding them before the change next > time around, and making sure they pass both before and after? > > Cheers > Robert
Re: bug#36878: guix system reconfigure broken
> On 31. Jul 2019, at 20:16, Jakob L. Kreuze > wrote: > > Hi Robert, > > Robert Vollmert writes: > >> The concrete problem is this: >> >> 1. nginx is running with config file A >> 2. make some change to nginx config >> 3. run guix system reconfigure (which builds a new nginx config file B) >> 4. run herd restart nginx >> 5. nginx is still running with config file A >> >> After reverting this commit, if I perform these steps, I end up with >> nginx running with config file B in 5. > > Okay, I see now. Thank you clarifying. Would you be willing to see if > the patch provided by #36880 fixes this issue? Yes, it seems it does!
