>> Issue pulseSupport -> does it make sense to have a global 'enable
>> pulse for all packgages' config.pulseSupport = true flag?
>>
>> packages could be using: config.pulseSupport or false to disable by
>> default then.
>
> In my opinion baking global implicit state into nixpkgs is not a good
>
> 9P is used by NixOS to share host's nix store with Qemu virtual
> machines. Such technique is used in the build process, in the
> test-driver, so to say in the critical places.
> Recently few bugs in 9P were found (#23957 #23020 #22695) which
> reveals that 9P code is not very mature and perhaps
> There are a few package groups that I believe are not used in NixOS
> core (boot, containers, ...) and are not updated as much as they could
> be. Node, Haskell, others?
Could the Haskell packages still be built by Hydra? I highly appreciate
that, because it makes Haskell development a very
>>> I dont want to be a 100% full time nixos developer / sysadmin just
>>> to solve such stupid problem. Except somebody would pay me for that,
>>> then I would think about it.
>>
>> Ah, so you won't do it for free but you expect the army of experts to
>> rush for help and do it for free for you,
> As far as I know, Nix has no way to gather statistics on how many people
> are using different architectures. This makes questions like this a bit
> awkward.
>
> One person on IRC said they think they may have used it once. Does
> anyone on this list use NixOS on i686? anyone on this list know
>> I ask you to PLEASE remove this installation method from the
>> recommendations on the page because it makes it look like you don't
>> care about computer secuirty one bit.
>
> Now, that's an interesting point. Are there many people who never
> installed nix because the installer is the
Hello fellow Haskellers,
I have a bunch of local Haskell packages, mostly libraries. The package
X lives in the directory `ertes-src/X/main`. There are lots of direct
and indirect dependencies between them. My current solution is ad hoc
and rather ugly. I'm using the following hand-crafted
I believe Peter's message 87mw5qvj9x@write-only.cryp.to could
answer my question. I will give it a try.
Hello fellow Haskellers,
I have a bunch of local Haskell packages, mostly libraries. The package
X lives in the directory `ertes-src/X/main`. There are lots of direct
and indirect
I believe Peter's message 87mw5qvj9x@write-only.cryp.to could
answer my question. I will give it a try.
It does and works well. Thanks anyway!
I have a bunch of local Haskell packages, mostly libraries. The package
X lives in the directory `ertes-src/X/main`. There are lots of
Hi Jeff,
I'm using a similar approach for non-Haskell packages. However, for
Haskell packages it doesn't interact well with cabal2nix. Hence my
question. I have now solved it the following way in
`~/.nixpkgs/config.nix`:
haskellPackageOverrides = self: super:
let asDarcs = path:
Assuming bigger things usually gives you a better or at least more
scalable result, and in most cases the additional cost is very close
to zero. For example every single-disk system I set up uses a
two-disk RAID array with one missing disk from the point of view of
mdadm. If it does
Once I wondered if using reflinks instead of hardlinks might be better
from some point of view, but it probably won't be a big difference.
Tl;dr: The current linking strategy has a noticable space and time
overhead that is large enough to be unacceptable for me, so I turned it
off. The
IMO much of the time overhead is basically unavoidable, as you need to
do lots of random probes to a huge table (order of million entries,
e.g. 1.5M in my case). Putting a single Bloom filter in front would
shave I/O of most *failed* probes, but otherwise we can't get much
better, I believe
NixOS noob here. I'm using NixOS on a machine with only one user (me).
What's the best strategy for installing packages?
[...]
Installing into a normal user profile
In general I tend to just assume that my system is an actual multi-user
system. I'm a normal user, so I don't make any
Hello fellow Haskellers,
how do I specify a Darcs repository on the local filesystem when
invoking haskell-ng's cabal2nix? Note: I need the Darcs variant, not
the local filesystem variant, so just giving a filesystem path does not
work.
Greets,
Ertugrul
signature.asc
Description: PGP
The way I do this is to fire up a Makefile from Emacs. The Makefile
uses nix-shell to start the actual builder:
nix-shell --pure --command ./Setup build
This is an indirection, but it makes sure that the environment the
builder sees is (fairly close to) the environment the build script
Hi there Eike,
I found out about the egg2nix program and saw, that the
'chicken-eggs.nix' file contains many eggs and that the egg2nix
program uses it. So, right now I'm starting a shell like this
nix-shell -p egg2nix
This drops me in a shell, where the eggs are setup via
Hello everybody,
today I've attempted to switch to Haskell NG again. The new tree itself
seems to work for me, but I'm still not getting prebuilt binary
packages. The only binary I get is GHC, while every other Haskell
package seems to be compiled from source code.
I've tried with the
Hi Peter,
nix-env \
--option extra-binary-caches https://hydra.nixos.org \
--option extra-binary-caches https://hydra.cryp.to \
-iA nixos.pkgs.hsEnv
what happpens when you use that command to install the attribute
nixos.pkgs.haskell-ng.ghc784.cabal-install and/or
That did it! Since I'm running NixOS I am indeed running
nix-daemon. The following setting did the trick:
nix.binaryCaches = [
https://cache.nixos.org/;
https://hydra.nixos.org/;
];
IMHO, nix-env should pass those options on to the daemon, i.e. it
should
Hello everybody,
is there a way to set a default binary cache for my regular user without
making it a systemwide default, perhaps in `~/.nixpkgs/config.nix`?
Basically I'd like to get rid of the --option argument when dealing with
Haskell packages.
Greets,
Ertugrul
signature.asc
Description:
Hi Kirill,
nix-env \
--option extra-binary-caches https://hydra.nixos.org \
--option extra-binary-caches https://hydra.cryp.to \
-iA nixos.pkgs.hsEnv
Might it be the case that you are running nix in daemon mode and thus it
ignores `binary-caches`?
That did it! Since I'm
This makes me wonder whether maybe we should switch all shell
scripting in Nixpkgs to csh? Wouldn't that solve a lot of problems?
I've heard experts say that csh is generally considered superior
for scripting tasks because of its more intuitive syntax.
I really dislike csh's syntax, and that
The last time I tried to switch, Nix started to build everything
from source, including GHC, even with the options described in the
Haskell NG thread.
what architecture do you use? Is it i686-linux by any chance? I'm
asking because Hydra isn't building binaries for that platform at the
If you haven't migrated to Haskell NG yet ... now would be a good time
to do it. (I'm looking at you, Agda.)
I'm currently forced to work on a rather weak machine, so building from
source is prohibitively expensive.
Is there a very short summary of how to do it and still get binary
packages?
I would like to add the IP address 172.16.48.17/28 to my enp0s3
interface but I would also like to keep the DHCP configured address.
[...]
Is this possible or should I use networking.localCommands?
The proper way to do this is to instruct the DHCP *server* to assign the
addresses. Most
What I want to say is that it might be boring to maintain such a
comprehensive help system, but it’s totally worth it, and it’s
wonderful that someone volounteers to do that. BTW it would be nice to
have a generic framework for writing docs and then doing things like
generating man-pages and
Umm, this is kinda the point that I was making, you were the one who
suggested to write that regular users should use this feature, so I
explained that you can't differentiate between regular and advanced
users to you need to treat all users equally and just document the
feature in a clear
Software should be fully documented. If you don't know where the
line between regular users and advanced users is, don't draw one
in the first place.
It's not so much a question of regular vs. advanced use, but whether
something is a stable interface. If we document a command like
Regarding --register-validity, it's a bit of internal command that I'm
not sure should be documented. But yeah, ‘exportReferencesGraph’
shouldn't refer to it :-)
Well, it is apparently a helpful utility when you change core parts of
NixOS, when you create your own Nix-based distribution or
I believe everything should be documented at least in a technical
manual. But there is nothing wrong with putting a note there:
Regular users should not need to use this command.
I wouldn't be in such a hurry to document things in this manner ,
because the basic assumption is if it's
+1 to doc fixes! :-) I'll gladly help with peer review for the content
or whatever I can within the prose capacity :-)
Nobody else? I would just do it, but at the very least I need an
explanation of the missing parts.
signature.asc
Description: PGP signature
+1 to doc fixes! :-) I'll gladly help with peer review for the
content or whatever I can within the prose capacity :-)
Nobody else? I would just do it, but at the very least I need an
explanation of the missing parts.
The best way to find out might be to use git blame and see commit
Hi everybody,
could someone please explain the `--register-validity` flag of
`nix-store` to me? I'm mostly interested in the format, because I need
to use `exportReferencesGraph` in a derivation. But most likely from
the search results I've got when searching for its documentation, later
I will
Hi again everybody,
I noticed that the documentation of various Nix tools is incomplete and
often too vague, so I'd like to contribute documentation patches. From
the top of my head the following two flags are currently undocumented:
* `nix-store --register-validity`
* `nix-env --set`
The
Remember that we're talking about very different paradigms. I can
totally see how you would want and love macros in CL. In CL you
encode your solution in such a way that using macros is the natural
thing to do, and then lexical manipulation is probably something that
comes in handy. In
I think you are thinking too big-system-design instead of
quick-scripting about that.
Let's say I don't draw a line between small systems and large systems
when it comes to abstractions, because algebraic abstractions are cheap.
IMO a minimum requirement for a language to be called functional
Data type declarations are not free in any case, I think.
Compared to what? Algebraic abstractions usually compile to exactly the
code you would have written if you had not used abstraction.
Well, you started talking like you were considering some limitation of
XMonad hard to work around.
Data type declarations are not free in any case, I think.
Compared to what? Algebraic abstractions usually compile to exactly
the code you would have written if you had not used abstraction.
Data type declarations have to be written. Store-everything-in-hash-
tables is slower but quicker
It's seldom that you have to write your own data types, if you don't
want to. Basic types, functions, products and coproducts can express
anything you want that isn't a tightly packed array of machine words.
But if you really want to dump everything into a table-like data
structure, you can
Also, I sometimes tend to use closing unneeded windows as a way of
keeping track of short-term TODO list.
I think there doesn't have to be semantic difference between closing a
window and dropping it into a virtual drawer. Your short-term to-dos
would be elsewhere.
Unfortunately it entails
Some of the shell tricks based on expansions are portable to Lisp,
not worth it in Julia and definitely too costly in Haskell (learning
Template Haskell is definitely outside my plans).
I don't really know TH either. Occasionally I use TH actions defined
in a library (for example to derive
Actually, my idea of the core boot sequence is contrary to your goals:
for core system I think in terms I want to easily run recovery after
a USB boot and I want to describe my system in terms of its imperative
recovery procedure started from initramfs. It is likely that my
service management
Oh, Common Lisp (CL) macros don't correspond to TH, but rather to
regular functions in Haskell. We have first class actions together
with lazy evaluation. What is code is data is code in CL is
actions are first class values in Haskell.
You only need TH when you need to generate something
Also the Nix model allows us to compile all our scripts easily (just
apply a function), which might hold some benefit in terms of startup
and switch times. There is little reason to use interpreted scripts
when you have a fast compiler.
So would you say that this is preferable to the
To be fair, there is also the GNU OS, which uses Guix, although the
underlying ideas and build system (nix-daemon) are the same.
[...] As such, it's probably best for me to not talk about GNU
OS, Guix, and Guile until I get the time/willpower to explain why my
viewpoint against that project
Maybe you need to script it properly? Maybe StumpWM is less rigid from
the beginning, though (I use it and extended it for my needs, so I can
probably answer your questions if you wonder about it; it is in Common
Lisp, by default all the splits are manual, and there are many hooks
to perform
My issue with text-only is that I don't know how to turn off
hard-wrapping in my client. By ‘hard-wrapping’ I mean:
That's always something that bothered me about e-mail (among other
things). There are only two formats that are widely supported, and none
of them get it right. The text/plain
In short: Better stop arguing against them, [...]
I'm not; [...]
Alright. =)
In the ideal graphical environment I wouldn't see any reason to close
or move a single window -- ever. Xmonad gets closer, but is still
far away.
What?!! That sounds very abstract and cool! Maybe esoteric.
Thanks! However, I'd better not switch to a WM that I wouldn't enjoy
configuring. Also I think that I've bent xmonad pretty much to its
limits and hit the abstraction wall. Nowadays my configuration is a
whole cabalised package that I install via Nix. If you're
interested, it's online
If only we had a way to produce multiple outputs from a single
package... :)
We have. The `derivation` function supports producing multiple outputs,
and I'm sure that `mkDerivation` forwards this ability.
Greets,
Ertugrul
signature.asc
Description: PGP signature
Yes, I’m planning to work on multiple outputs for ghc soon :)
Great! I'm looking forward to that. =)
signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
What about other languages as Python, Perl etc.? I know it is against
our purity standards, but they are a far superior to Bash scripting.
Well, that's the current state of the art. They are both used in
Nixpkgs and some Nix-related tools. They are an improvement over Bash
scripting, but I
Curry is indeed a beautiful language, and is essentially a
conservative extension of Haskell. I am surprised that more Haskell
folk have not adopted it.
Well, it does lack quite a few things right now, including on the
language level. For example its way to deal with ad-hoc polymorphism is
At this current point in time, GHC is packaged in a poor manner, with
GHC being unbelievably huge. Dynamic linking is the answer, which
isn't done by default.
I have actually experimented with using Haskell (and a few other FP
languages) as a substitute for shells. It is feasible if you
Hi Charles,
I'm happy to announce that support for the GHCJS compiler [...] has
been merged into master [...].
This introduces a new top-level package set: haskellPackages_ghcjs.
I was going to try it out and found the compiler itself, but couldn't
figure out how to make a derivation for a JS
Hi everybody,
I was going to try it out and found the compiler itself, but couldn't
figure out how to make a derivation for a JS package. Is there any
documentation on that? If not, in which files should I look? Something
like ghcjsWithPackages and cabal.mkJsDerivation would be great.
Hi Luca,
Let's not break the discussion in two places. It started on the github
issue and can be kept there.
one advantage of breaking it up is that I can take note of it and add
that I'm currently working on a prototype of my earlier algebraic
services proposal, which among other things
Hi Marc,
But don't hold your breath. It could take a week or two before I can
present my first prototype.
Maybe you can sketch your idea for the sake of discussion?
Allow me to send you to the thread in question:
http://lists.science.uu.nl/pipermail/nix-dev/2014-December/015362.html
Hi Charles,
Perhaps suggesting shell aliases would be sufficient for those that
may want the pager by default?
Yes, that's a good solution.
Greets,
Ertugrul
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
Hi Michael,
When I explicitly launch man, I am going to read the top of the man
page and some place in the middle, so less is useful.
Absolutely, `man` is supposed to be an interactive program, and it
usually displays formatted text that wouldn't fit on one page anyway.
But honestly I wouldn't
Hi Vladimír,
If you set PAGER=cat or PAGER= you get pretty much the old behavior.
Also, if the output isn't a terminal, less isn't used, e.g. ``nix-env -q
| cat`` or ``nix-env -q | grep foo`` works the old way for me.
I'm aware of that, and it's a terrible solution. I want to have
PAGER=less
Hi Paul,
No, they can't choose. I would choose to use `less` as a pager when
I need it, and otherwise I would use my terminal. I can't make that
choice without corrupting the PAGER variable (which I use for other
things!).
I'm not a fan of using less for nix tools. But it seems you're
Hi Michael,
I know; I was answering the question of why it is a problem to choose
a single PAGER value.
Sorry, I'm still getting used to my new mail setup. =)
nix-env --list-generations
I use ls instead of this command.
That's actually a good idea, thanks.
Well, systemd is
Hi Bjørn,
Hm, I've never thought of automatic less as a misfeature before. I
didn't have anything to do with its inclusion in nix, but I remember
when I started using git that I was pleasantly surprised by it's use
of less, which made git more fun to work with. (If I was a nix
developer I
Hi Domen,
My 2c: if Nix offers a way to disable the pager then I'd rather see 1% of
users for such needs to make the bash alias instead of the other way around.
why do you insist on an interactive-by-default Nix? There should be an
interactive frontend, something like an interactive nox.
Hi Eelco,
There is a very good reason for this principle. If a program does
more than what it's intended to do, then it hurts composability.
There shouldn't be an issue with composability here, because Nix will
only run the pager when stdout is a terminal. So things work fine if
you pipe
Hi Eelco,
If it helps at all, git seems to use GIT_PAGER first and then falls
back to PAGER and then to `less` for the commands that use
it. Perhaps nix could respect a NIX_PAGER env var?
I've implemented this now, with the same semantics as GIT_PAGER and
SYSTEMD_PAGER.
Thanks a lot!
What
Hi everybody,
since Nix 1.8 much of the output of nix commands is piped through
`less`, which is certainly meant to be a convenience, but that
convenience depends on a few assumptions:
* the user uses a crappy terminal emulator,
* the user is interested in all of the output,
* the user
Hi Ludovic,
As a first approximation there would be a Service monoid, which would
combine certain typical attributes about a service, including startup
scripts, required bind-mounts, required system resources and if
really necessary shutdown scripts (most programs should shutdown
properly
Hi Alexander,
We can use a monoid system to construct configurations, but the socket
activation standard for example, is centered on optimizing the
activation script itself. What are your thoughts on the activation
script?
I have no concrete thoughts at this point, just throwing around
Hi Ludovic,
FWIW, Guix uses an approach along these lines: the ‘bitlbee-service’
function, for instance, returns a ‘service’ object as a monadic value
(see
http://www.gnu.org/software/guix/manual/guix.html#Defining-Services
for details.)
The way I understand the section on the store monad
Hi Colin,
This sounds a lot like Disnix! How would it be similar? How would it
be different?
Disnix and NixOps are machine-oriented. You have a network of machines
with configurations. The goal is a service-oriented architecture.
Every service itself is a machine, and those machines can be
Hi Nicolas,
I think as a first step to get rid of systemd and gain a much more
sensible services model as well we should move away from NixOS
modules for services.
The module system is made in such a way that one can build on top of
the work of the other without having any computer
Hi Michael,
Well, with NixPkgs having multiple instances of a package installed
requires zero support from the package expression itself. I do think
that services becoming more like packages would be a good thing, but
currently I have no idea how to do this except by just giving up the
Hi there Tobias,
One thing most of us seem to agree about [...]
Maybe that's true (I don't see a consensus on the list, only the usual
sparse FUD. I don't follow IRC) but arguments that start this way
always give me the willies.
I understand why, but I'm not very good at English rhetoric.
Hi there Anderson,
I want to know if it's possible to use an alternate to Systemd as init
system on NixOS.
this has been asked many times now, and I'm in favour of switching to an
alternative. Unfortunately it's not easy, because a considerable
portion of NixOS currently depends on systemd,
script during the first boot of the container.
That's already most of what I need. What remains is a way to build
multiple configurations and deploy them to different systems in a
functional way, in particular without environment variables.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
-tarball.nix. No deep knowledge is required
and the instructions and relevant information can be put on a fairly
simple wiki page.
What do you think? I would love to provide a prototype, but I really
need help with this one.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
Key-ID: F9B5212A
. Until we have a caching solution of some sort, I'd prefer to
keep Nixpkgs slim.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
in your configuration.nix.
Greets,
Ertgrul
--
Ertugrul Söylemez ert...@gmx.de
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
install NixOS and pick a program that you would like to see
in Nixpkgs. Then just add it to your local installation and send a
patch/PR to Nixpkgs, just to get a feeling of how it works, both
technically and socially.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
and collaboration at the same time?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Ertugrul Söylemez ert...@gmx.de
___
nix-dev mailing list
nix-dev
(because of an actual project called
Nixpkgs). A name like @nixtips would be more appropriate, should you
decide to keep maintaining it.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
Key-ID: F9B5212A
Fingerprint: 8D89 7AC9 21CF F868 F074 9058 30CB D56F F9B5 212A
pgpGIcrt9i9qD.pgp
will send
them in seperate mails if you ACK this, as some of them may lead to
longer discussuions (who knows).
Go ahead. As Cillian noted there is also the #nixos channel, if you
prefer a less rigid form of communication.
Greets
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
virtualised environment. The Linux kernel has
the necessary support to implement this securely.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
of
data files, each optional and referring to each other, compressed to
save space. This is an actual design that I'm following in one of my
projects. I'll know to make it Nix-friendly, but non-NixOS developers
may fail to do so.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
at $out/.nixdeps.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
the path handling procedures of the libc.
Rewrite /nix/store to whatever is in the NIX_STORE variable. This
would be a lot of hard work, but would work much more reliably than
rewriting paths in binaries, and it would work without help from root.
Greets,
Ertugrul
--
Ertugrul Söylemez ert
on Freenode. Some of you may
know me as @ertesx, too.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
Key-ID: F9B5212A
Fingerprint: 8D89 7AC9 21CF F868 F074 9058 30CB D56F F9B5 212A
--
Ertugrul Söylemez ert...@gmx.de
Key-ID: F9B5212A
Fingerprint: 8D89 7AC9 21CF F868 F074 9058 30CB D56F
:-)
--
Ertugrul Söylemez ert...@gmx.de
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
and updates the channel. Then it goes to the next highest priority. That way
security updates won't take longer than necessary.
When we use priorities generously we could avoid a lot of delay even in less
critical cases.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
machines, so I think that
waiting for Hydra is the way to go, even when you can't watch the actual
build process and thus feel that nothing is happening.
All we need is to make sure that Hydra builds those quickly enough.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
wouldn't
like people to mistake NixOS as just another distro. It is, among
other things, a development and (continuous) deployment platform. The
homepage should make this clear.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
Key-ID: F9B5212A
Fingerprint: 8D89 7AC9 21CF F868 F074 9058
.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
appreciate the work, but the process behind it was
completely wrong. The website was switched before the community even had a
chance to review it. I'd ask all committers to pay more attention to what the
community says before applying patches.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
.
By the way, the Hydra frontend has the same issue.
Greets,
Ertugrul
--
Ertugrul Söylemez ert...@gmx.de
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
lightweight markup languages like
Markdown and generate CSS from something more modular like Clay. It does
require some basic Haskell knowledge though.
--
Ertugrul Söylemez ert...@gmx.de
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http
1 - 100 of 102 matches
Mail list logo
