https://github.com/NixOS/nixpkgs/pull/3504#issuecomment-54260503
I asked the author to provide stable URLs and I thought that he agreed to
do this, but then he disappeared and didn’t respond to my last email. I’m
not sure what was going on. You might try to ask him too, I hope you’ll be
able to
Hi Georges,
There's a curl update PR (https://github.com/NixOS/nixpkgs/pull/6171).
Can it board that train, or should it wait for the next?
IMHO, it looks innocent enough to be included: 7fc94dd3.
Best regards,
Peter
___
nix-dev mailing list
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
On 09/02/2015 15:57, James Haigh wrote:
On 09/02/15 14:16, Harald van Dijk wrote:
On 09/02/2015 14:55, James Haigh wrote:
On 28/01/15 07:42, Luke Clifton wrote:
Hi Bjørn,
I have read that thread. I agree with you 100% that native builds
(on real or virtual hardware) is the only way this can
The 02/08/2015 12:21, Jeffrey David Johnson wrote:
Nice! I'm currently binding gksu 'i3lock -c00
pm-suspend' to a hotkey using i3, but this is better. Is
there a standard way to get it in my fork of nixpkgs, which is
tracking the release-14.12 branch? (I could just copy and
paste but
There's a curl update PR (https://github.com/NixOS/nixpkgs/pull/6171). Can
it board that train, or should it wait for the next?
Georges Dubus
2015-02-09 17:08 GMT+01:00 Peter Simons sim...@cryp.to:
Hi guys,
I would like to merge the staging branch back into master as soon as
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
On 09/02/15 15:22, Ertugrul Söylemez wrote:
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
On 10 February 2015 at 03:58, James Haigh james.r.ha...@gmail.com wrote:
Even for bootstrapping, it should still be possible to do without package
support for cross-compilation. Compiling entirely within Qemu is one,
perhaps crude, way of ‘fixing’ the build platform isolation problem in
On 9 February 2015 at 22:13, Christoph-Simon Senjak
christoph.sen...@googlemail.com wrote:
Hello.
I am new to NixOS, and I am currently trying to build a package for the
x2goclient.
Cool! Somewhere on my TODO list is writing an x2go service module :-)
I brought it to a state where I can use
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
Hello.
I am new to NixOS, and I am currently trying to build a package for the
x2goclient. I brought it to a state where I can use it, but it would be
nice if you could give me some comments about them.
On 28/01/15 07:42, Luke Clifton wrote:
Hi Bjørn,
I have read that thread. I agree with you 100% that native builds (on
real or virtual hardware) is the only way this can work. Upstream
doesn't usually care if their software can cross compile, and they
can't maintain it themselves even if
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
On 09/02/2015 14:55, James Haigh wrote:
On 28/01/15 07:42, Luke Clifton wrote:
Hi Bjørn,
I have read that thread. I agree with you 100% that native builds (on
real or virtual hardware) is the only way this can work. Upstream
doesn't usually care if their software can cross compile, and they
Hello,
How many NixOS users have an ARM-based Android smartphone and prefer
NixOS to Android? Being able to chroot NixOS to Android in the same
manner as the Lil' Debi chroot installer application to have a decent
GNU+Linux distribution running alongside the default Linux-based system
would be
On 09/02/15 19:56, Ertugrul Söylemez wrote:
[...]
In short: Better stop arguing against them, regardless of what your
reasons are. [...]
I'm not; I'm avoiding argument. Please don't make assumptions as to what
my reasons are! Otherwise your mind is arguing ‘for me’, but not
necessarily with
On 03/02/15 13:59, Lluís Batlle i Rossell wrote:
On Mon, Feb 02, 2015 at 04:16:07PM +0100, Bjørn Forsman wrote:
On 2 February 2015 at 01:17, Lluís Batlle i Rossell vi...@viric.name wrote:
I have the bootstrap-tools for armv5tel, they build and the test passes.
On 30/01/15 16:02, Joe Hillenbrand wrote:
http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html
Time to replace all shell scripts in Nix with Haskell?
No, certainly _now_ is way too early to replace _all_, but possibly
_some_, and starting with just the functional
benefits text:
- minimal bandwidth
- user can configure his/her client how to view - looks always the same
- no js
Thus why are discussing HTML at all - for making some texts *bold*?
HTML also runs the risk to not be displayed the same everywhere - eg
google mail rewrites inline styles
On 09/02/15 16:01, Harald van Dijk wrote:
On 09/02/2015 15:57, James Haigh wrote:
[...]
But what I'm saying is that if the package succeeds in compiling
natively but fails to cross-compile, then this is an issue with the
compiler/toolchain. Yes it can be solved by writing configure scripts
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.
On 06/02/15 12:41, Matthias Beyer wrote:
Hi,
can we please have text-only on this ML? Maybe even through a mailman
setting, so it rejects non-text-only-mail?
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:
this is
hard-
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
On 09/02/15 14:16, Harald van Dijk wrote:
On 09/02/2015 14:55, James Haigh wrote:
On 28/01/15 07:42, Luke Clifton wrote:
Hi Bjørn,
I have read that thread. I agree with you 100% that native builds
(on real or virtual hardware) is the only way this can work.
Upstream doesn't usually care if
25 matches
Mail list logo
