Re: "guix potluck", a moveable feast
l...@gnu.org (Ludovic Courtès) writes: > Beside, related to Chris’ comment, I’m a bit concerned about versioning > in such a widely distributed repo. The package graph in Guix has zero > degrees of liberty: every package is connected to other packages; every > Guix user sees the exact same graph. > > Here, we’d have to be more flexible and allow potluck.scm files to just > say “import guile” or “import guile@2.0”; “import guile” might provide > 2.0 on a machine running an older Guix, and it might give 2.2.9 on an > up-to-date machine. > > IOW, we’re no longer describing one specific graph, but instead > describing a family of graphs with some constraints. The benefits are > decentralization, but the main drawback is non-reproducibility: the > result would depend on the user machine’s initial state. > > To work around that, I think the server should resolve package > specifications when the potluck.scm file is submitted, and insert each > package in the Guix package graph of the moment. Does that make sense? > Maybe that’s what you were describing when you talk about rewriting > potluck.scm files so? When you say "insert each package in the Guix package graph," do you mean, "add the package definition to the Guix source tree"? What if "the potluck" maintained a pointer to the version (i.e., the commit) of the Guix package definitions that it uses as its "base"? From time to time, the potluck could update its pointer to point to a more recent version of Guix's package definitions. In this way, every version of the potluck would precisely specify the dependencies of all the packages in that version of the potluck, including any transitive dependencies that ultimately come from the official Guix package definitions (as defined in the "base" version); there would be no surprising version drift. I wonder if that would work? What if someone wants to add a package definition to the Guix source tree which depends on a package that is defined in the potluck? -- Chris signature.asc Description: PGP signature
"Perfect Setup" for hacking on Nix?
Hi, The Guix manual has a fantastic section on the "Perfect Setup" for hacking on Guix ((guix) The Perfect Setup). This section provides excellent guidance for a newbie on how they can set up their development environment for hacking on Guix. I found it tremendously useful when I was starting out as a Guile and Guix newbie. I have sometimes found myself looking at the Nix source code that is embedded in the Guix repository. However, I don't have a lot of experience with C++, so I don't really know how I should set up my development environment for hacking on (or just browsing) that code. So, what's the "Perfect Setup" for hacking on Nix? -- Chris signature.asc Description: PGP signature
'guix build' and garbage collection
Hi, I saw this in guix/scripts.build.scm: --8<---cut here---start->8--- (and (build-derivations store drv mode) (for-each show-derivation-outputs drv) (for-each (cut register-root store <> <>) (map (lambda (drv) (map cdr (derivation->output-paths drv))) drv) roots)) --8<---cut here---end--->8--- Here, we build the derivations, and then we add indirect GC roots. My question is: what guarantee is there that the output paths will not be garbage collected after we build the derivations but before we add the indirect GC roots? -- Chris signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
On Sun, Apr 02, 2017 at 12:30:28AM +0200, Ludovic Courtès wrote: > Hi! > > It looks like we’re doing okay now? There are still a number of > armhf-linux builds pending, but if everything goes well, I think we > should merge tomorrow (Sunday). WDYT? Yes, I like this plan. signature.asc Description: PGP signature
Re: "guix potluck", a moveable feast
Hello!
Andy Wingo skribis:
> As an interlude, here is how a user would enter an environment that has
> a potluck package "foo" using Guix (using a pack is also possible). We
> start with setup steps:
>
> (1) Install Guix as a user. (This needs to be easier.)
> (2) guix channel add potluck https://gitlab.com/potluck/potluck master
> (3) guix channel enable potluck
So users would see the union of independent potluck “dishes”, right?
> A packaging language for stability and security
> ---
>
> So how do packages enter the potluck channel? Good question, fictional
> reader! This is the tricky bit. There are some concerns here:
>
> (1) The Guix API is not stable and has no plans to be stable. This
> works great for now because all packages are in one atomic
> repository and people work on making the whole thing make sense
> together. One of the goals of the potluck effort is to
> decentralize things a bit, so we have an impedance mismatch
> between potluck packages and Guix itself.
>
> (2) Potluck package definitions will live in many different git
> repositories across the internet, and anyone should be able to
> make a potluck package. Some potluck package authors will be
> malicious. They could:
>
>1. Damage the server that manages the potluck channel
>
>2. Damage the users that run Guix commands with the potluck
> channel enabled
>
>3. Damage the users that install potluck packages
>
> I think we need to forget about 3, for now at least. (Flatpak
> solves this, more or less; Guix has ongoing work to do here I
> think.)
>
> Both of these large issues point to the need for careful design of the
> language that potluck packages are written in. The language that Guix
> packages are written in is inappropriate because of (1). In particular
> we should not depend on which module a package comes from, and what
> identifier binds any given package. For (2), packages are currently
> written in full Scheme, staged between the Guix command itself and the
> sandbox that runs inside guix-daemon. Full Scheme might be OK in the
> daemon but it's not OK in the Guix command itself.
>
> Concretely I would propose that the language that potluck files are
> written in is like this:
>
> (1) It's code, not inert data.
>
> (2) It's a subset of Scheme, like core Guix packages.
>
> (3) The general structure looks like this:
>
> (import-guix-packages ((guile "guile@2.0")
> (glibc "glibc")))
> (import-potluck-packages ((foo "foo")))
>
> (define bar
> (package
> (name "guile-bar")
> (version "1.0.0")
> (build-system gnu-build-system)
> (inputs `(("guile" ,guile))
> )))
That makes sense to me.
The sandbox would have transitive access to a lot of modules; I wonder
if this might somehow make it easier to escape the sandbox, by
increasing the attack surface. For instance,
(source-module-closure '((guix packages)) #:select? (const #t))
contains (system foreign). That’s probably more of a topic for
guile-devel though.
Beside, related to Chris’ comment, I’m a bit concerned about versioning
in such a widely distributed repo. The package graph in Guix has zero
degrees of liberty: every package is connected to other packages; every
Guix user sees the exact same graph.
Here, we’d have to be more flexible and allow potluck.scm files to just
say “import guile” or “import guile@2.0”; “import guile” might provide
2.0 on a machine running an older Guix, and it might give 2.2.9 on an
up-to-date machine.
IOW, we’re no longer describing one specific graph, but instead
describing a family of graphs with some constraints. The benefits are
decentralization, but the main drawback is non-reproducibility: the
result would depend on the user machine’s initial state.
To work around that, I think the server should resolve package
specifications when the potluck.scm file is submitted, and insert each
package in the Guix package graph of the moment. Does that make sense?
Maybe that’s what you were describing when you talk about rewriting
potluck.scm files so?
> There is a particular concern about staging: there is staged Scheme code
> in these modules that runs inside build processes in guix-daemon. I
> don't have any nice solution here.
What’s the problem anyway? The build environment is a “sandbox” so it’s
not a problem if staged code attempts to do nasty things.
> A potluck channel manager
> -
>
> The "guix potluck manage-channel" command manages a registry of sources
> of potluck definitions and turns them into a git branch of package
> files. This is the web service.
>
> The idea is that as a developer, you should be able to do:
>
> guix potluck add https://gitlab.com/wingo/foo master
>
> This causes the client to make a request to
Re: Let’s freeze and build ‘core-updates’!
Hi! It looks like we’re doing okay now? There are still a number of armhf-linux builds pending, but if everything goes well, I think we should merge tomorrow (Sunday). WDYT? Thanks, Ludo’.
Re: the importance of rust-build-system [Fwd: [tor-dev] Tor in a safer language: Network team update from Amsterdam]
Leo Famulari skribis: > On Sat, Apr 01, 2017 at 07:58:41AM +, ng0 wrote: >> tor is seriously considering to switch to rust. I have my own open >> bugs / roadmap points which depend on our rust-build-system working. >> tor will not switch immediately, but it shows the importance of having a >> working rust-build-system. Firefox will switch at some point. > > It's immediately important because the latest version of librsvg (used > to create the GuixSD GRUB background image) is written in Rust. We could > even update that package "the hard way", without a full > rust-build-system. For librsvg and Tor, a switch to Rust is both good news and bad news: it’s good news because using a memory-safe language is indeed a wise decision, but it’s bad news because it introduces a single point of trust (opaque Rust binaries built by Mozilla) in our dependency graph. Ludo’.
Re: bug#26308: [PATCH -v2] services: dict.scm: Support more dicod configuration
Hello, "Huang, Ying" skribis: > l...@gnu.org (Ludovic Courtès) writes: [...] >> While I was at it, I wrote a simple test for the dicod service: >> >> >> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=985a8599ed742053b52ac85f753c4feb54af93cb >> >> It uses the example handler that you gave in the doc, but I think this >> handler actually does nothing because WordNet does not provide data in >> the dict.org format AIUI (and its data is under “/dict” anyway.) Is >> that correct? >> >> Do you have another example in mind that could use a dict.org-formatted >> database? > > There are dict.org dict for wordnet and foldoc in Debian. Some > conversion tool is needed to convert the dict database file. OK. Any idea of a DICT database file that we could use as an example and as a test? Thanks, Ludo’.
Staying on-topic
Hello Taylan, This is guix-devel and this discussion is off-topic. Furthermore: taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis: > Lastly, a trivial data point about possible effects of inclusivity or > exclusivity, should our Code of Conduct mandate obeying a certain > position on this ideological split: [...] I've run a poll > asking women how willing they would be to contribute to a project whose > code of conduct disallows the use of sex-based pronouns This is obviously far from the reality of the project’s code of conduct: https://git.savannah.gnu.org/cgit/guix.git/tree/CODE-OF-CONDUCT So please let’s stop it and get back on topic. Thanks in advance, Ludo’.
GSoC build tool clarification
The description of "replaces the likes of autools, cmake" makes sense, but I'm not sure I understand the more advanced features being described - specifically "... should ultimately be able to run complex workflows on multiple servers...". Does that just mean that the build process should be able to be distributed across systems, or is there more to that implied by the "complex" part? By the way, hi everyone!
Re: question about pty,agetty for an intermediate virtual server image
On Sat, Apr 01, 2017 at 07:27:40AM +, ng0 wrote: > Leo Famulari transcribed 2.8K bytes: > > And you will probably want a non-graphical GRUB menu as well (this > > should be parameterized eventually...): > > Yeah, that would be useful as it is not uncommon for servers. Here's a patch that works in my tests: https://bugs.gnu.org/26334 signature.asc Description: PGP signature
Re: the importance of rust-build-system [Fwd: [tor-dev] Tor in a safer language: Network team update from Amsterdam]
On Sat, Apr 01, 2017 at 07:58:41AM +, ng0 wrote: > tor is seriously considering to switch to rust. I have my own open > bugs / roadmap points which depend on our rust-build-system working. > tor will not switch immediately, but it shows the importance of having a > working rust-build-system. Firefox will switch at some point. It's immediately important because the latest version of librsvg (used to create the GuixSD GRUB background image) is written in Rust. We could even update that package "the hard way", without a full rust-build-system.
Re: updating gdk-pixbuf for epiphany
On Sun, Apr 02, 2017 at 10:55:27AM +0200, Ricardo Wurmus wrote: > Hi, > > I’d like to update Epiphany to the latest release but noticed that it > needs a slightly younger version of gdk-pixbuf. Updating gdk-pixbuf to > 2.36.6 would result in *many* rebuilds. “guix refresh -l gdk-pixbuf” > tells me this: > > Building the following 324 packages would ensure 630 dependent packages > are rebuilt… > > So, should this be done in a separate branch along with other GNOME > updates or can this go to staging after merging core-updates? We should update all the GNOME stuff, but that requires some focused work. So, if you or somebody else is up for it, great :) If not, I think it's fine to put it on a staging branch. signature.asc Description: PGP signature
Re: question about pty,agetty for an intermediate virtual server image
On Sat, Apr 01, 2017 at 07:27:40AM +, ng0 wrote: > Leo Famulari transcribed 2.8K bytes: > > And you will probably want a non-graphical GRUB menu as well (this > > should be parameterized eventually...): > > Yeah, that would be useful as it is not uncommon for servers. I'm working on it today... > > Finally, you can test it in QEMU by appending '-serial pty' to the > > QEMU invocation. When it starts, QEMU will tell you which pty it's > > using, and you can connect to it with something like `screen`. > > Thanks! I'll give it a try and get back to you when I run into problems. Hopefully it's "if", not "when" ;) signature.asc Description: PGP signature
Re: "guix potluck", a moveable feast
Christopher Allan Webber transcribed 1.8K bytes: > Andy Wingo writes: > > > Hi! > > Hi! > > > potluck.guixsd.org needs to be isolated from other hosts because it will > > load potluck.scm files from untrusted sources; we hope the sandbox works > > but we need a bit of defense-in-depth. > > Well now I see the motivation behind (ice-9 sandbox) ... :) > > > As I mentioned, I think it would be nice to be able to install some > > potluck packages directly from git, without requiring those packages to > > make releases and update the potluck.scm. But until then, we can make > > it so that the source is fixed in the potluck.scm as it is with other > > Guix packages, and therefore that any update to potluck.scm in the > > source git branch registered with potluck.guixsd.org constitutes a new > > release which replaces the old one. A developer should signal > > potluck.guixsd.org about the update via a re-invocation of "guix potluck > > add". Maybe "guix potluck add" could remember the branch, dunno. > > > > Anyway! The result of the "guix potluck channel-manager" is a stream of > > guix modules as a continually updated git tree -- a guix channel. I am > > thinking that we need to rewrite these files to be more "normal" -- like > > starting with a (define-module), but a #:pure module and an appropriate > > set of imports to enforce the sandbox. We should be able to compile > > this module, to prevent the potluck channel from slowing things down. > > So basically the channel-manager rewrites the potluck.scm files. > > It sounds nice! > > One challenge though... what do we do about multiple channels > introducing version skew? (Maybe I'm abusing that term?) This isn't > something we've dealt with before in Guix... if my channel adds > something that depends on your channel's package definition, do I > explicitly set a revision for your channel? Otherwise else, your > channel could change as you upgrade your software version, and that > might unexpectedly break my channel... > I think there's something we can learn from Gentoo here. You might or might not know their 'overlays' (I don't know the exact gentoo rfc when they introduced them but it's been very long ago). They do this kind of thing. They have no opinion other than that 'portage', in Guix terms 'master branch at savannah', takes the highest priority by default. You can explicitly change this. If you start using a specific overlay and use a software recipe from it which does exists in multiple overlays, it's like this: - if you don't edit the specific file which tells portage about this recipe, it picks the highest stable version. - if you get rid of stable and allow everything, it picks the highest version and has no opinion from where it comes. - if you specifically point out the overlay for it, it picks the version from there, no questions asked. well actually it asks questions if you tell it to do so ;) So I think we could have some way to define the priority of the channel, a value to define stable / unstable (similar to Gentoo's "experimental" and "official" classification of overlays). No warranty that this is accurate, I tried to explain Gentoo overlays without assuming too much or explaining too much of it. In case I misunderstood the question, enjoy your 2 minutes of 'Things Gentoo did excellent'.
Re: "guix potluck", a moveable feast
Andy Wingo writes: > Hi! Hi! > potluck.guixsd.org needs to be isolated from other hosts because it will > load potluck.scm files from untrusted sources; we hope the sandbox works > but we need a bit of defense-in-depth. Well now I see the motivation behind (ice-9 sandbox) ... :) > As I mentioned, I think it would be nice to be able to install some > potluck packages directly from git, without requiring those packages to > make releases and update the potluck.scm. But until then, we can make > it so that the source is fixed in the potluck.scm as it is with other > Guix packages, and therefore that any update to potluck.scm in the > source git branch registered with potluck.guixsd.org constitutes a new > release which replaces the old one. A developer should signal > potluck.guixsd.org about the update via a re-invocation of "guix potluck > add". Maybe "guix potluck add" could remember the branch, dunno. > > Anyway! The result of the "guix potluck channel-manager" is a stream of > guix modules as a continually updated git tree -- a guix channel. I am > thinking that we need to rewrite these files to be more "normal" -- like > starting with a (define-module), but a #:pure module and an appropriate > set of imports to enforce the sandbox. We should be able to compile > this module, to prevent the potluck channel from slowing things down. > So basically the channel-manager rewrites the potluck.scm files. It sounds nice! One challenge though... what do we do about multiple channels introducing version skew? (Maybe I'm abusing that term?) This isn't something we've dealt with before in Guix... if my channel adds something that depends on your channel's package definition, do I explicitly set a revision for your channel? Otherwise else, your channel could change as you upgrade your software version, and that might unexpectedly break my channel...
Re: [PATCH 5/5] gnu: Add python-sphinx-rtd-theme-0.1.9
Apologies. I sent the patch for mando on the wrong thread. I have re-sent it on the appropriate thread, so you can ignore this.
Re: [PATCH 1/5] gnu: Add python-mando-0.3.1
>From cece7ce7a1847bebf83ec83ce822313be86b2e62 Mon Sep 17 00:00:00 2001 From: Muriithi Frederick Muriuki Date: Sat, 1 Apr 2017 13:26:21 +0300 Subject: [PATCH 1/5] gnu: Add python-mando-0.3.1 * gnu/packages/python.scm (python-mando-0.3.1): New variable. --- gnu/packages/python.scm | 17 + 1 file changed, 17 insertions(+) diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm index 7dfe4ba..9dd045a 100644 --- a/gnu/packages/python.scm +++ b/gnu/packages/python.scm @@ -13956,3 +13956,20 @@ recognize TestCases.") (define-public python2-mando (package-with-python2 python-mando)) + +(define-public python-mando-0.3.1 + ;; python-radon (version 1.5.0) has a requirement + ;; for mando<0.4,>=0.3 + (package +(inherit python-mando) +(name "python-mando") +(version "0.3.1") +(source + (origin + (method url-fetch) + (uri (string-append "https://github.com/rubik/mando/archive/v"; + version + ".tar.gz")) + (sha256 +(base32 + "17jlkdpqw22z1nyml5ybslilqkzmnk0dxxjml8bfghav1l5hbwd2")) -- 2.10.2
Re: [PATCH 5/5] gnu: Add python-sphinx-rtd-theme-0.1.9
>From cece7ce7a1847bebf83ec83ce822313be86b2e62 Mon Sep 17 00:00:00 2001 From: Muriithi Frederick Muriuki Date: Sat, 1 Apr 2017 13:26:21 +0300 Subject: [PATCH 1/5] gnu: Add python-mando-0.3.1 * gnu/packages/python.scm (python-mando-0.3.1): New variable. --- gnu/packages/python.scm | 17 + 1 file changed, 17 insertions(+) diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm index 7dfe4ba..9dd045a 100644 --- a/gnu/packages/python.scm +++ b/gnu/packages/python.scm @@ -13956,3 +13956,20 @@ recognize TestCases.") (define-public python2-mando (package-with-python2 python-mando)) + +(define-public python-mando-0.3.1 + ;; python-radon (version 1.5.0) has a requirement + ;; for mando<0.4,>=0.3 + (package +(inherit python-mando) +(name "python-mando") +(version "0.3.1") +(source + (origin + (method url-fetch) + (uri (string-append "https://github.com/rubik/mando/archive/v"; + version + ".tar.gz")) + (sha256 +(base32 + "17jlkdpqw22z1nyml5ybslilqkzmnk0dxxjml8bfghav1l5hbwd2")) -- 2.10.2
[PATCH 1/5] gnu: Add python-mando-0.3.1
* gnu/packages/python.scm (python-mando-0.3.1): New variable. --- gnu/packages/python.scm | 17 + 1 file changed, 17 insertions(+) diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm index 7dfe4ba..9dd045a 100644 --- a/gnu/packages/python.scm +++ b/gnu/packages/python.scm @@ -13956,3 +13956,20 @@ recognize TestCases.") (define-public python2-mando (package-with-python2 python-mando)) + +(define-public python-mando-0.3.1 + ;; python-radon (version 1.5.0) has a requirement + ;; for mando<0.4,>=0.3 + (package +(inherit python-mando) +(name "python-mando") +(version "0.3.1") +(source + (origin + (method url-fetch) + (uri (string-append "https://github.com/rubik/mando/archive/v"; + version + ".tar.gz")) + (sha256 +(base32 + "17jlkdpqw22z1nyml5ybslilqkzmnk0dxxjml8bfghav1l5hbwd2")) -- 2.10.2
Re: bug#26308: [PATCH -v2] services: dict.scm: Support more dicod configuration
l...@gnu.org (Ludovic Courtès) writes:
> Hello,
>
> Huang Ying skribis:
>
>> * gnu/services/dict.scm (): Add handlers to configure
>> handlers (module instances).
>> (): Add new record type to describe handler (module
>> instance).
>> (): Add more fields.
>> (dicod-configuration-file): Support convert handlers and enhanced databases
>> configuration to config file.
>>
>> * doc/guix.text: Add description of newly added dicod configuration.
>
> I’ve committed with a few adjustments to the commit log and cosmetic
> changes:
>
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9af7ecd9591b4eff41389291bbc586dcf09e2665
>
>> +@example
>> +(dicod-service #:config
>> + (dicod-configuration
>> + (handlers
>> + (list
>> +(dicod-handler
>> + (name "wordnet")
>> + (module "dictorg")
>> + (options
>> + '("dbdir=/gnu/store/-wordnet")
>
> I’ve changed this to use a real example instead of “xxx”.
>
>> (define-record-type*
>>dicod-database make-dicod-database
>>dicod-database?
>>(namedicod-database-name)
>> - (module dicod-database-module)
>> + (handler dicod-database-handler)
>> + (complex dicod-database-complex(default #f))
>
> I changed that to ‘complex?’, to make it clear that it’s a Boolean.
>
> While I was at it, I wrote a simple test for the dicod service:
>
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=985a8599ed742053b52ac85f753c4feb54af93cb
>
> It uses the example handler that you gave in the doc, but I think this
> handler actually does nothing because WordNet does not provide data in
> the dict.org format AIUI (and its data is under “/dict” anyway.) Is
> that correct?
>
> Do you have another example in mind that could use a dict.org-formatted
> database?
There are dict.org dict for wordnet and foldoc in Debian. Some
conversion tool is needed to convert the dict database file.
Best Regards,
Huang, Ying
> Thank you!
>
> Ludo’.
updating gdk-pixbuf for epiphany
Hi, I’d like to update Epiphany to the latest release but noticed that it needs a slightly younger version of gdk-pixbuf. Updating gdk-pixbuf to 2.36.6 would result in *many* rebuilds. “guix refresh -l gdk-pixbuf” tells me this: Building the following 324 packages would ensure 630 dependent packages are rebuilt… So, should this be done in a separate branch along with other GNOME updates or can this go to staging after merging core-updates? -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: Gender politics
Just a few things: 1. We were done with this topic. For real. Don't throw gasoline at the fire. 2. Looking at the past commits of your taylanub.github.io blog adds just to what I thought when I read your very long reply. 3. You could've just written the last paragraph, that you agree with neutral.. but that wouldn't add up to your views you moved 21 days ago somewhere else. So everybody.. please stop pushing this topic. If you keep pushing it there's reason to rethink the outcome whole topic. If that's your goal, please keep pushing and you'll see where it leads.
the importance of rust-build-system [Fwd: [tor-dev] Tor in a safer language: Network team update from Amsterdam]
tor is seriously considering to switch to rust. I have my own open bugs / roadmap points which depend on our rust-build-system working. tor will not switch immediately, but it shows the importance of having a working rust-build-system. Firefox will switch at some point. Danny, could you list what's left for completion? Is it just circular dependencies? I'm about to publish my project page within the next few days. I hope you don't mind if I list you as a go-to person for getting involved in upstream (Guix) to fix up the rust-build-system. If you do mind, please let me know. I will not publish your email address, I'll rather point to a git commit. - Forwarded message from Sebastian Hahn - From: Sebastian Hahn To: tor-...@lists.torproject.org Subject: [tor-dev] Tor in a safer language: Network team update from Amsterdam Hi there tor-dev, as an update to those who didn't have the chance to meet with us in Amsterdam or those who haven't followed the efforts to rely on C less, here's what happened at the "let's not fight about Go versus Rust, but talk about how to migrate Tor to a safer language" session and what happened after. Notes from session: We didn't fight about Rust or Go or modern C++. Instead, we focused on identifying goals for migrating Tor to a memory-safe language, and how to get there. With that frame of reference, Rust emerged as a extremely strong candidate for the incremental improvement style that we considered necessary. We were strongly advised to not use cgo, by people who have used it extensively. As there are clearly a lot of unknowns with this endeavor, and a lot that we will learn/come up against along the way, we feel that Rust is a compelling option to start with, with the caveat that we will first experiment, learn from the experience, and then build on what we learn. You can also check out the session notes on the wiki (submitted, but not posted yet).[1] The real fun part started after the session. We got together to actually make a plan for an experiment and to give Rust a serious chance. We quickly got a few trivial things working like statically linking Rust into Tor, integrating with the build system to call out to cargo for the Rust build, and using Tor's allocator from Rust. We're planning to write up a blog post summarizing our experiences so far while hopefully poking the Rust developers to prioritize the missing features so we can stop using nightly Rust soon (~months, instead of years). We want to have a patch merged into tor soon so you can all play with your dev setup to help identify any challenges. We want to stress that this is an optional experiment for now, we would love feedback but nobody is paid to work on this and nobody is expected to spend more time than they have sitting around. We have committed to reviewing any patch that includes any Rust code to provide feedback, get experience to develop a style, and actually make use of this experiment. This means we're not ready to take on big patches that add lots of tricky stuff quite now, we want to take it slow and learn from this. We would like to do a session at the next dev meeting to give updates on this effort, but in the meantime, if team members would like to start learning Rust and helping us identify/implement small and well-isolated areas to begin migration, or new pieces of functionality that we can build immediately in Rust, that would be really great. So, for a TLDR: What has already been done: - Rust in Tor build - Putting together environment setup instructions and a (very small) initial draft for coding standards - Initial work to identify good candidates for migration (not tightly interdependent) What we think are next steps: - Define conventions for the API boundary between Rust and C - Add a non-trivial Rust API and deploy with a flag to optionally use (to test support with a safe fallback) - Learn from similar projects - Add automated tooling for Rust, such as linting and testing Cheers Alex, Chelsea, Sebastian [1]: Will be visible here https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/Notes ___ tor-dev mailing list tor-...@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev - End forwarded message -
Re: question about pty,agetty for an intermediate virtual server image
Leo Famulari transcribed 2.8K bytes:
> On Fri, Mar 31, 2017 at 12:59:56PM +, ng0 wrote:
> > before I go ahead and create an intermediate image - I'd like to explore
> > the option of getting IN-Berlin closer into the creation of the 'deploy'
> > process of Guix which is being worked on - I need to find out how the
> > redirection to "/sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt102"
> > can be honored.
> > As far as I understand, we use mingetty which according to the mingetty
> > manpages is not suited for tasks agetty can do.
> >
> > IN-Berlin runs a Consoleserver which redirects ssh logins to it via
> > "virsh console $vserver" to the /sbin/agetty (on debian vservers) on
> > your server. The KVM configuration can be seen below.
> >
> > How can I achieve this (the agetty part) with GuixSD?
>
> You can use the agetty-service, like this
>
> (kernel-arguments
> ;; Adjust these arguments as desired.
> '("console=ttyS0,115200n8 gfxpayload=text earlyprintk=serial,tty,115200"))
>
> (services
> (cons (agetty-service (agetty-configuration
> (tty "ttys0")
> (term "vt102")
> (keep-baud? #t)
> (baud-rate "115200,38400,9600)))
> %base-services))
>
> And you will probably want a non-graphical GRUB menu as well (this
> should be parameterized eventually...):
Yeah, that would be useful as it is not uncommon for servers.
> diff --git a/gnu/system/grub.scm b/gnu/system/grub.scm
> index b18b8be6d..d94b1a266 100644
> --- a/gnu/system/grub.scm
> +++ b/gnu/system/grub.scm
> @@ -197,7 +197,7 @@ system string---e.g., \"x86_64-linux\"."
> insmod efi_uga
>fi
>
> - terminal_output gfxterm
> + terminal_output console
> "
> ""))
>
> Finally, you can test it in QEMU by appending '-serial pty' to the
> QEMU invocation. When it starts, QEMU will tell you which pty it's
> using, and you can connect to it with something like `screen`.
Thanks! I'll give it a try and get back to you when I run into problems.
Re: Planning for the next release
Leo Famulari transcribed 2.2K bytes: > On Fri, Mar 31, 2017 at 04:33:24PM +, ng0 wrote: > > Ludovic Courtès transcribed 0.6K bytes: > > > > On my side, people will and have asked for the intermediate time how/if > > > > the http_proxy of Guix works. If someone has been using it with an > > > > SOCKS5 proxy successfully, I'd would like to have this added to > > > > documentation as well. My own experiment ended up with a shot in the > > > > foot where I had to roll back because Guix was now unable to do anything > > > > at all. > > > > > > The guix-service in GuixSD now allows you to specify an HTTP proxy quite > > > easily, for substitutes and downloads (commit 93d32da9f8). I haven’t > > > tried it but it Should Work Fine. > > > > That's the commit after which I've tried to make it work, reconfigured > > the system with it and failed. > > If I remember correctly, I simply added this to the config of guix, as > > suggested in the config. > > For what I really did and if you require an error output, I can provide > > this to you within the next 2 weeks. > > Since that's my commit, I'm happy to debug / test it, but I don't have > an HTTP proxy or know how to set one up. > > If you can share the proxy server with me, or explain how to create one, > I'll test it. To put it simple, my use case is tor. I thought it would be enough to point to the host:port like I do for socks5 settings of applications. (tor-service (plain-file "torrc" "SocksPort 127.0.0.1:9050\n")) could be a config (not my config). Step one is to test it with tor, afterwards comes testing with gnunet socks. If you can not use tor, I can't help to provide a different example. The machine where the old configs are is down at the moment, but I've added it to config of guix similar to how you extend the list of substitute machines in the config.
