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
> past
On 10 February 2015 at 03:58, James Haigh 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
> compilers. All that's rea
>> 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 e
>> 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 o
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 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 wrote:
>>> I have the bootstrap-tools for armv5tel, they build and the test passes.
>>>
>>> https://github.com/viric/nixpkgs/tree
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 9 February 2015 at 22:13, Christoph-Simon Senjak
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 it, but it would be
> nice
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.
https://github.com/dasuxullebt/nixpkgs/blob/master/pkgs/applications/networking/remote/x2goc
> 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 perf
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 sc
>> 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 p
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.
>
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
nix
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 :
> Hi guys,
>
> I would like to merge the staging branch back into master as soon as
> http://hydra.nixos.org/job
Hi guys,
I would like to merge the staging branch back into master as soon as
http://hydra.nixos.org/jobset/nixpkgs/staging has completed building
revision 7b99c149a4, i.e. in 2-3 days. Does anyone see a compelling
reason to postpone that merge?
Best regards,
Peter
__
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
>> 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 t
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
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
> 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 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 i
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 (backgroun
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
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 programm
On 30/01/15 19:16, Domen Kožar wrote:
> Maybe FOSDEM staff can help us out, did you try contacting them?
No. I asked on the Sunday but as expected they didn't. I don't really
think that that should be expected of them anyway. I asked around a
couple of tables over in AW block where the hardware sta
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 per
27 matches
Mail list logo
