Re: [Nix-dev] Nix for internal projects and monorepos

[Luke Clifton]

On 26 Mar. 2017 3:17 am, "Tikhon Jelvis"  wrote:

Instead, we're shipping statically linked Haskell executables that are then
run with Hadoop. Building statically linked Haskell binaries with Nix was a
bit of a pain, but now that it works deployment is easy. Also, it still
doesn't build statically on OS X, but we don't care because we're not
deploying to OS X servers :).


Building statically linked Haskell binaries with Nix has been on my todo
list for a while now. Any hints?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] AwesomeWM

[Luke Clifton]

On 13 February 2017 at 15:33, Jörg Thalheim  wrote:
> But I can also run awesome wm in xephir without problems.
> Maybe you can take a look at the file `icon_theme.lua` at line 95 and see 
> what table entry is nil.||
> `lookup_category_icons` seems like there is a problem with finding some icons.

Yep. We have been discussing off list, and this is the problem (as far
as I can tell). Installing hicolor icon set fixed the problem in my
reproduction. Was waiting for Nathans confirmation that it fixed his
problem before posting solution to the list.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] AwesomeWM

[Luke Clifton]

Correction:

sudo nixos-rebuild switch

You can also do a

sudo nixos-rebuild dry-build -v

which will show you exactly which packages are being built. Search around
in the output for awesome.


On 12 February 2017 at 09:57, Luke Clifton  wrote:

> Can you be a little more precise?
>
> I don't use awesome myself, but you probably need to install it in
> configuration.nix via the `services.xserver.windowManager.awesome` set of
> options.
>
> You then need to
>
> sudo nixos-rebuild --switch
>
> This uses the nixpkgs version that the root user has configured, rather
> than what your user has configured.
>
> So double check the output of
>
> sudo nix-channel --list
>
> You can also dig around in ~/.nix-defexpr/channels_root/.
>
> On 12 February 2017 at 09:29, Nathan Owens 
> wrote:
>
>> I installed it through local clone of nixpkgs and also tried though
>> nix-env and also through configuration.nix; All same results
>>
>> On Sat, Feb 11, 2017 at 7:10 PM, Luke Clifton 
>> wrote:
>>
>>> How are you installing it?
>>>
>>> On 12 Feb. 2017 3:13 am, "Nathan Owens"  wrote:
>>>
>>>> I have tried asking in IRC  and on reddit.com/r/nixos and nobody can
>>>> tell me about this issue
>>>>
>>>> awesome says it is version 4.0 but it looks like 3.5.9 and acts like
>>>> it, meaning using copycat's rc.lua file used for version 4.0 gives errors.
>>>> On my ArchLinux install the rc.lua file works fine and even the
>>>> inital(without copycat's themes) look different than it did on 3.5.9
>>>>
>>>> I have tried installing awesome from local clone repo of nixpkgs and
>>>> same issue.
>>>>
>>>> Copying error from reddit post I made :
>>>>
>>>> ..8n5-awesome-4.0/share/awesome/lib/menubar/icon_theme.lua:95: table index 
>>>> is nil
>>>>
>>>> error while running function!
>>>> stack traceback:
>>>> ..8n5-awesome-4.0/share/awesome/lib/menubar/icon_theme.lua:95: table index 
>>>> is nil
>>>> ..h68n5-awesome-4.0/share/awesome/lib/menubar/menu_gen.lua:59: in function 
>>>> ' lookup_category_icons'
>>>>  h68n5-awesome-4.0/share/awesome/lib/menubar/menu_gen.lua:59: in 
>>>> function ''generate'
>>>>  ../.config/awesome/freedesktop/menu.lua:59: in function 'build'
>>>>  ../.config/awesome/rc.lua:170: in main chunk
>>>>  error8n5-awesome-4.0/share/awesome/lib/menubar/icon_theme.lua:95: 
>>>> table index is nil
>>>>
>>>>
>>>> ___
>>>> nix-dev mailing list
>>>> nix-dev@lists.science.uu.nl
>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>>
>>>>
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] AwesomeWM

[Luke Clifton]

Can you be a little more precise?

I don't use awesome myself, but you probably need to install it in
configuration.nix via the `services.xserver.windowManager.awesome` set of
options.

You then need to

sudo nixos-rebuild --switch

This uses the nixpkgs version that the root user has configured, rather
than what your user has configured.

So double check the output of

sudo nix-channel --list

You can also dig around in ~/.nix-defexpr/channels_root/.

On 12 February 2017 at 09:29, Nathan Owens  wrote:

> I installed it through local clone of nixpkgs and also tried though
> nix-env and also through configuration.nix; All same results
>
> On Sat, Feb 11, 2017 at 7:10 PM, Luke Clifton  wrote:
>
>> How are you installing it?
>>
>> On 12 Feb. 2017 3:13 am, "Nathan Owens"  wrote:
>>
>>> I have tried asking in IRC  and on reddit.com/r/nixos and nobody can
>>> tell me about this issue
>>>
>>> awesome says it is version 4.0 but it looks like 3.5.9 and acts like it,
>>> meaning using copycat's rc.lua file used for version 4.0 gives errors. On
>>> my ArchLinux install the rc.lua file works fine and even the inital(without
>>> copycat's themes) look different than it did on 3.5.9
>>>
>>> I have tried installing awesome from local clone repo of nixpkgs and
>>> same issue.
>>>
>>> Copying error from reddit post I made :
>>>
>>> ..8n5-awesome-4.0/share/awesome/lib/menubar/icon_theme.lua:95: table index 
>>> is nil
>>>
>>> error while running function!
>>> stack traceback:
>>> ..8n5-awesome-4.0/share/awesome/lib/menubar/icon_theme.lua:95: table index 
>>> is nil
>>> ..h68n5-awesome-4.0/share/awesome/lib/menubar/menu_gen.lua:59: in function 
>>> ' lookup_category_icons'
>>>  h68n5-awesome-4.0/share/awesome/lib/menubar/menu_gen.lua:59: in 
>>> function ''generate'
>>>  ../.config/awesome/freedesktop/menu.lua:59: in function 'build'
>>>  ../.config/awesome/rc.lua:170: in main chunk
>>>  error8n5-awesome-4.0/share/awesome/lib/menubar/icon_theme.lua:95: 
>>> table index is nil
>>>
>>>
>>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] AwesomeWM

[Luke Clifton]

How are you installing it?

On 12 Feb. 2017 3:13 am, "Nathan Owens"  wrote:

> I have tried asking in IRC  and on reddit.com/r/nixos and nobody can tell
> me about this issue
>
> awesome says it is version 4.0 but it looks like 3.5.9 and acts like it,
> meaning using copycat's rc.lua file used for version 4.0 gives errors. On
> my ArchLinux install the rc.lua file works fine and even the inital(without
> copycat's themes) look different than it did on 3.5.9
>
> I have tried installing awesome from local clone repo of nixpkgs and same
> issue.
>
> Copying error from reddit post I made :
>
> ..8n5-awesome-4.0/share/awesome/lib/menubar/icon_theme.lua:95: table index is 
> nil
>
> error while running function!
> stack traceback:
> ..8n5-awesome-4.0/share/awesome/lib/menubar/icon_theme.lua:95: table index is 
> nil
> ..h68n5-awesome-4.0/share/awesome/lib/menubar/menu_gen.lua:59: in function ' 
> lookup_category_icons'
>  h68n5-awesome-4.0/share/awesome/lib/menubar/menu_gen.lua:59: in function 
> ''generate'
>  ../.config/awesome/freedesktop/menu.lua:59: in function 'build'
>  ../.config/awesome/rc.lua:170: in main chunk
>  error8n5-awesome-4.0/share/awesome/lib/menubar/icon_theme.lua:95: table 
> index is nil
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Logo improvement ideas

[Luke Clifton]

Hi Tim,

Nice work, I quite like the look of the 'hex' variations.

Regards,

Luke


On Mon, 24 Aug 2015 at 13:14 Tim Cuthbertson  wrote:

> Hello all,
>
> I'm a big fan of Nix / NixOS, but I've long felt that the logo could
> do with a bit of work. So I toyed about a bit with inkscape, and came
> up with a few ideas:
>
> https://github.com/gfxmonk/nixos-logo-ideas/tree/master/exports
>
> They mostly keep to the existing logo structure, but with some changes:
>
>  - Make the lines wider, and remove the rounded caps. The existing
> logo feels too thin, as if it's made of lines rather than shapes. This
> feels fragile, particularly when scaled down.
>
>  - Made the lambda structure more obvious. To be honest, it wasn't
> until fairly recently that I noticed that the logo was made of
> lambdas. I've added gaps between each one so they don't run into a
> single shape as much. I've also added some subtle gradients at the top
> of each, to turn it into more of a woven structure, rather than a
> snowflake.
>
>  - Rotated the shape so that there's an upright lambda, and the shape
> fits better into a restricted-height context (e.g a header bar).
>
> # Shape variants:
>
> "straight": More or less equivalent to the current logo, but with
> straight (not rounded) edges
>
> "hex": Blockier in general, and gives the short foot of the lambda a
> triangular edge. This aligns all outer points to a hexagon shape,
> mirroring the inner hexagon.
>
> "slant": The lambdas in this one have a fatter head and thinner feet.
> This makes the overall structure look more dynamic and organic, but
> de-emphasizes the clean lambda shape somewhat. The shapes on this one
> may need some tweaking, as the outer shape (made by the feet) still
> seems a little disorganized still.
>
> # Highlight variants:
>
> "none": every lambda has the same shading
>
> "half": every second shape is darker (as in the current logo)
>
> "feature": the right-way-up lambda is the only darker shape. This
> makes the repeating lambda structure more obvious, but obviously
> affects symmetry.
>
> I haven't done too much experimentation with the colours, but feel
> free to crack open the svgs (in the parent directory) and try whatever
> you like.
>
> Let me know what you think!
>
> Cheers,
>  - Tim.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] i686 Builds?

[Luke Clifton]

+1

This seems like a good idea.

On 12 May 2015 at 06:45, William Kennington  wrote:

> Maybe it would make more sense to only build the i686 builds if our tested
> set of x86_64 binaries build correctly. We would still release with both
> but it would cut down on a lot of redundant failures.
>
> On Mon, May 11, 2015 at 3:39 PM Ryan Trinkle 
> wrote:
>
>> I encountered an i686 user just the other day!  I don't use it
>> personally, but having solid support in Nix was fantastic, especially
>> because older, 32-bit machines tend to be slower, which makes Nix's binary
>> caching functionality even more important.
>>
>> On Mon, May 11, 2015 at 6:36 PM, Shea Levy  wrote:
>>
>>> Hi all,
>>>
>>> Do we still have users running 32-bit machines? It would reduce the load
>>> on
>>> hydra significantly if we could drop support for i686, though of course
>>> if
>>> people are still relying on it we shouldn't make the change yet.
>>>
>>> ~Shea
>>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] HaskellNG and taffybar

[Luke Clifton]

This is also a problem with the Yi editor which also uses Dyre.


On 24 February 2015 at 04:18, Kirill Elagin  wrote:

> Well, the author of the issue I pointed out is correct in saying that they
> use Dyre which in turn uses ghc-paths. I checked ghc-paths and I believe
> what they do is store the path to GHC _they were compiled with_.
>
> So errr... Looks like we are stuck in a loop. I guess your best bet is to
> patch Dyre not to use ghc-paths.
>
> On Mon Feb 23 2015 at 23:59:51 Arseniy Seroka 
> wrote:
>
>>
>> 2015-02-23 22:55 GMT+03:00 Kirill Elagin :
>>
>>> Does XMonad work in your case?
>>> Can you import `System.Taffybar` in `ghci`?
>>>
>>
>> Yes, xmonad works and I can import `System.Taffybar` in ghci.
>>
>>
>> Might it be that, unlike XMonad, they do something more complicated to
>>> invoke GHC? I didn’t check the source, but looks like they do.
>>> Are you running this on a non-NixOS distro? In that case, the issue
>>>  probably explains
>>> what’s going
>>>
>>
>> I'm using Nixos.
>> That's what they are doing. [1]
>>
>> [1] https://github.com/travitch/taffybar/blob/master/src/
>> System/Taffybar.hs#L204
>>
>>
>> --
>> Sincerely,
>> Arseniy Seroka
>>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] A few questions about ARM support and NixOS on a Chromebook

[Luke Clifton]

Yes, I have done this method in the past as well, but like you say, it only
helps with C and C++. I'd rather have a set up which works for everything
first, and then selectively try and optimise pieces of it (like using
distcc). Although I was wondering how this would play with Nix and getting
"reproducible" builds. I assume that the cross compilers aren't set up by
nix, and that some sort of override is happening? I'll take a look at the
notes on the wiki.

On 10 February 2015 at 23:14, Wout Mertens  wrote:

> There's another option : build natively with distcc pointing to
> cross-compilers on x86 boxes. All the configuration etc happens natively
> and the compiles themselves are sped up. I wonder if that's the approach
> Vladimír Čunát took earlier? He made the notes on how to set up distcc for
> raspberry pi on the wiki iirc.
>
> Yet another option : run the above option in qemu, running the whole thing on
> an x86 box with the heaviest lifting done natively.
>
> These only speed up C/C++ of course.
>
> Wout.
>
> On Mon, Feb 9, 2015, 5:01 PM Harald van Dijk  wrote:
>
>> 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 work. Upstream doesn't
>> usually care if their software can cross compile, and they can't maintain
>> it themselves even if they did. Sometimes it isn't even an option, e.g. GHC
>> still can't cross compile template Haskell yet.
>>
>> I don't understand why cross-compilation is even a thing, other than
>> decades of false assumptions being baked into compilers.
>> As I understand, if a compiler (and by ‘compiler’ I'm referring to
>> the whole toolchain required for compilation) is taking source code and
>> compilation options as input, and giving object code for the specified
>> platform as output, it is called ‘cross-compiling’ if the specified target
>> platform is different to the platform that the compiler is running on. If
>> GCC is running on ARM, compiling code ‘natively’ to ARM successfully, it is
>> counterintuitive that it would fail to build for ARM if GCC is running on
>> x86. And vice versa. A compiler should produce object code for a target
>> platform that implements the source code – it may not have the same
>> efficiency as the output of other compilers (or with other compilation
>> options), but should have the same correctness when execution completes. If
>> the source code being compiled is a specific version of the GCC source code
>> itself, and it is compiled for both x86 and ARM, then if the compilation is
>> computationally correct, both compilations of GCC should produce programs
>> that, although will compute in a different way and with different
>> efficiency, should give the exact same object code when given the same
>> source code and parameters. So if the target platform parameter is ARM,
>> they should both build exactly the same ARM machine code program.
>>
>> All of this is true, but the toolchain usually doesn't have any problems
>> with cross-compilations.
>>
>> However, evidently this is not the case unfortunately. So the
>> compilers or their toolchains are, in essence, receiving the platform that
>> they are running on as ‘input’ to the build, and making assumptions that
>> this build platform has something to do with the target platform. I.e. they
>> are _aware_ of the platform that they're building on, whereas
>> theoretically, they shouldn't be. Apparently this has a lot to do with
>> configure scripts.
>>
>> The configure scripts, or similar machinery in non-autoconf packages, are
>> part of the package, not part of the toolchain. Many programs use runtime
>> checks in configure scripts. A trivial example that hopefully doesn't exist
>> in any real package:
>>
>> If a package only compiles on platforms where sizeof(int) == 4, or where
>> special code is needed on platforms where sizeof(int) != 4, might try to
>> detect those platforms by compiling and linking
>>
>> int main(void) {
>>   return sizeof(int) != 4;
>> }
>>
>> and then executing it. If the execution succeeds (i.e. returns zero),
>> then sizeof(int) == 4. If the execution doesn't succeed, then the configure
>> script assumes that sizeof(int) != 4, even though it's very well possible
>

Re: [Nix-dev] A few questions about ARM support and NixOS on a Chromebook

[Luke Clifton]

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 really needed is for the configuration checks and
> tests to be ‘given’ the answers that would be obtained on the target
> system, yet the tools that are running them could still be compiled to and
> running in the architecture of the build system. Theoretically, there may
> be no virtual machine involved at all, and hence no architecture
> bootstrapping problem.
> However, seeing as, when bootstrapping, the package that we want to
> compile is the compiler itself, it doesn't really matter whether this is
> done by having package support for cross-compilation (in the compiler
> package), or by implementing the isolation in such a way as to allow the
> compiler to run natively while compiling. In other words, in this specific
> case, whether it is the compiler or the package that is the one supporting
> the cross-compilation, it is the same thing! :-D The difference being which
> way is easiest to implement reliably versus which is most efficient.
> I'd imagine that an implementation that only isolates the calls to the
> build system and does not require running the compiler in the target
> architecture would be the absolute the most efficient, but that the method
> where everything beyond the bootstrap is run in a virtual machine is the
> easiest to implement. There are probably also quite a few middle-ground
> options where some components are running natively and some are being
> virtualised.
>

In order to compile within Qemu, you first need to build the kernel, and
the compiler (and a few other base tools). This is what is meant by
bootstrapping, and you have to do this with real cross-compilation because
you don't yet have a virtual machine on which to natively run the build
process. Luckily, these basic bootstrapping packages have very good support
for cross-compilation upstream. The Linux kernel is a breeze to cross
compile. Once you have the kernel, gcc, binutils and make, you are more or
less ready to proceed with building any package natively (in a virtualised
environment).

The problem with your suggestion of a method which "isolates the calls to
the build system" is that because we don't have control over what build
systems other people are using (CMake, make, just a bash script, their own
bootstrap language) we have no way of controlling what they do in there
(anything can call uname -a, but what where they trying to discover?), and
there are about 37 bazzillion ways that things can go wrong. Trust me, I
have tried. In fact, Linux has great support for emulation at the exec
level. You can make your x86 linux platform understand ARM binaries and
execute them. This get's you a long way, the issue with sizeof(int) == 4 is
solved, but there are still 37 bazzillion - 1 other things that can still
go wrong.

At one point I had a chroot which contained an ARM system, but some of the
binaries I replaced with native versions for speed increases. I had built
GCC so that it would work in an ARM chroot, building ARM binaries, but
itself an x86 binary. This system actually worked really well... until I
hit the next problem. I can't remember exactly what it was now, but even
with a chroot, you had to bind a whole bunch of other files into the chroot
(some /dev/ stuff etc.). Eventually packages manage to find some way of
figuring out that they are not really running on an ARM machine, and your
build fails (in sometimes not obvious ways).

The problem is, we have no way of knowing what information the build
scripts are trying to figure out when they call something like uname -a.
Maybe they did want to know what the build machine was, maybe they wanted
to find out what the target was. Or, as is often the case, they wanted to
determine both. We can't just put a version of uname into the environment
that does the "right thing" because there is no "right thing" because
everyone is using it for a different purpose.

So basically, the only way that I can see this working is to have proper
cross compilation support for the basic stuff, and the run the rest
natively.

Regards,

Luke
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] A few questions about ARM support and NixOS on a Chromebook

[Luke Clifton]

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 they did. Sometimes it isn't even an option, e.g. GHC
still can't cross compile template Haskell yet.

I once used to think that full system cross compilation was the only way
you should do things (I was an idealist). But it is a dead end. Unless you
have thousands of hours to throw at the problem, it won't work.

Have you made any progress on this yourself?

Regards,

Luke



On 28 January 2015 at 15:08, Bjørn Forsman  wrote:

> On 28 January 2015 at 02:49, Luke Clifton  wrote:
> ...
> > My plan, should I ever get the time, is to set up a virtual machine, try
> and
> > bootstrap NixOS for ARM in that, set up hydra, build nixpkgs and then
> serve
> > the results to my embedded platforms. I also have dreams of creating
> > firmware images from a configuration.nix which are ready to flash onto
> the
> > boards.
>
> Me too.
>
> Related: https://github.com/NixOS/nixpkgs/issues/4963
>
> Best regards,
> Bjørn Forsman
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] A few questions about ARM support and NixOS on a Chromebook

[Luke Clifton]

Hi James,

I too am interested in getting NixOS running on ARM, but unfortunately I am
currently unable to dedicate time to the project.

My problem has always been lack of RAM in my ARM devices. I work mostly
with embedded Linux platforms where RAM is < 256MB. To provide perspective,
my Laptop (core i7) with 2GB of RAM fails to build some nixpkgs packages.
Small CPU just means longer build time, small RAM means no build.

My plan, should I ever get the time, is to set up a virtual machine, try
and bootstrap NixOS for ARM in that, set up hydra, build nixpkgs and then
serve the results to my embedded platforms. I also have dreams of creating
firmware images from a configuration.nix which are ready to flash onto the
boards.

Keep us in the loop on your progress; I'd be keen to follow along, and
maybe help out a bit where I can.

Regards,

Luke




On 28 January 2015 at 08:46, James Haigh  wrote:

>  Hi,
> I forgot to say, that was my first email to the list. So hi everyone!
> I was told about NixOS by Doaitse Swierstra at Summer School Utrecht 2013
> on the Applied Functional Programming course. I went to FOSDEM for the
> first time last year, seeing Domen's excellent talk, and I've been in
> Freenode/#nixos since the previous Saturday night. I subscribed to this
> list in June. I'm going again to FOSDEM this year, so hope to see some of
> you there!
> I immediately realised the significance of NixOS and knew straight
> away that I was eventually going to use it as my primary OS, but I didn't
> get round to trying it until last year. However, so far I've only installed
> it on one device and the majority of my hardware is ARM, especially if you
> count in cores or computational performance. Here's a list:
>
> ARMv6 hardware:
>
>- ×1, 700MHz: Raspberry Pi (Broadcom BCM2835)
>
>
> ARMv7-A hardware:
>
>- ×1, 1GHz: BeagleBone Black (open hardware; Sitara AM3358/9, ARM
>Cortex-A8)
>- ×2, 1GHz: LG Optimus 3D (runs Android; TI OMAP4430, ARM Cortex-A9)
>- ×2, 1.2GHz: PandaBoard ES (open hardware; TI OMAP4430, ARM Cortex-A9)
>- ×2, 1.5GHz: Archos 101 G9 Turbo 250GB (runs Android; TI OMAP4460,
>ARM Cortex-A9)
>- ×2, 1.7GHz: Samsung Series 3 Chromebook (Samsung Exynos 5250, ARM
>Cortex-A15)
>- ×4, 1.3GHz: Acer Iconia Tab A500 (runs Android; Nvidia Tegra 3)
>- ×4, 2.2GHz: Sony Xperia Z1 (runs Android; Qualcomm Krait MSM8974)
>
>
> That's 18 ARM cores in total! (Not counting those embedded in whatever
> other devices such as hard disk drives, and I think even my old Nokia 6300
> has an ARM9 processor.)
>
> x86 hardware:
>
>- ×2, 1.66GHz: ThinkPad X60 Tablet (L2400, Intel Core Duo)
>
>
> x86-64 hardware:
>
>- ×2, 1.5GHz: ThinkPad X60 Tablet (L7400, Intel Core 2 Duo)
>
>
> Total 4 x86(-64) cores.
>
> I have had other x86 devices, but they either broke or I gave away my
> working x86 hardware to family. The ThinkPad X60 Tablets are the only
> x86(-64) hardware that I actually intend to keep on using and that I'm
> willing to replace if they break, and even then, that's only until I'm
> eventually in a position to design an ARM-based motherboard for them. I'm
> also rather fond of the PowerPC I-Mac G3, despite having never owned one,
> so I may aquire one of those at some point and attempt to install GNU+Linux
> on it (NixOS?). I have a couple of 680MHz MIPS routers installed with
> OpenWrt, but they're probably not worth the effort or suitable for NixOS
> due to having only 64MiB of RAM (comparable to personal computers of the
> late 1990s or early 201st decade) and I'm unlikely to buy any new MIPS
> devices anyway, instead opting for ARM devices.
> I intend to eventually install NixOS on all of the devices listed
> above. However, for the Android devices, that would preferably be in the
> form of a chroot so that I still have Android on those devices.
>
> On 26/10/14 01:26, Mateusz Kowalczyk wrote:
>
> [...] You'd have to find an ARM machine strong enough to build nixpkgs,
> even if only sometimes. I believe machines of that power are very
> expensive. I might be wrong. Or maybe you know someone who would be happy
> to donate such a monster ;) [...]
>
> So, that monster you speak of. I have 18 modern ARM cores, and counting –
> that is a fairly beastly amount of computational resource. But can it all
> be pooled together as a distributed build farm? It surely makes it easier
> if NixOS is installed or chroot'd on all of those, right?
>
> On 08/11/14 10:43, Tim Barbour wrote:
>
> [...]
> I also would prefer to avoid x86 PC hardware in the future, the problem
> being the power consumption (100-200W per box). ARM seems much better in
> this regard. From a very rough estimate, I think an MK802IV has about 10%
> of the processing power of a PC, for about 2.5% of the power consumption
> (5W max). I think we will see the day when ARM will out-perform x86,
> because it will be able to process more instructions per second without
> melting.
>
> Indeed. And this year wi

Re: [Nix-dev] A Journey into the Haskell NG infrastructure: Part I

[Luke Clifton]

This looks really nice.

  The NG package set contains the latest version of every package available
>   from Hackage
>

How difficult would it be to track a different repository? Say, Stackage?

I'd love the convenience of being able to simple switch between the two, or
maybe even my own set of curated packages.

Regards,

Luke
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] less: When assumptions ruin the world

[Luke Clifton]

Forgot the list...

> On 02/01/2015 9:36 am, "Ertugrul Söylemez"  wrote:
>
> > Feature request 1:  Please do your part in saving the software world and
> > remove this anti-feature.  Don't even consider making it optional.  It's
> > useless.  Remove it.  In the future, whenever you think that some
> > UX-related automation will make things easier, think again.  You are
> > most likely wrong.  Just look at the huge damage that Microsoft has done
> > by assuming that users are complete idiots.
> >
> > Feature request 2:  Also I strongly believe that `--help` should
> > absolutely never open a man-page.  When we need a manual, we will use
> > the `man` command, but in most cases we just need a quick reminder of
> > what that one option was called that we're failing to recall, so I would
> > much prefer the original purpose of the `--help` option:  Print a short
> > summary to the terminal.
>
> > I hope that some people agree with me, and if yes, I will turn these
>
> > into actual feature requests on Github.  I'm also happy to help with
> > implementing the latter one, because writing a good `--help` system for
> > commands with subcommands is not necessarily easy.
>
> I agree with your sentiment on both points.
>
> Luke
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Current state about Android development on NixOS

[Luke Clifton]

Having never owned, or programmed an android device before, and not being a
Java developer, this took me quite some time to get working, but it turned
out to be simple.

The androidsdk does not include some tools that you will probably need such
as ant and openjdk.

Don't use the update facility provided with the SDK. If you want to use
multiple versions of the SDK use a myEnvFun.

My configuration.nix looks like this.

environment.systemPackages = with pkgs; [
# Other packages here ...
(myEnvFun {
  name = "android43";
  buildInputs = [ androidenv.androidsdk_4_3
  ant
  openjdk
];
})
];

So when I want to start developing for android targeting 4.3 I do a

$ load-env-android43

And I'm ready to go.

Hope that helps you get started.

Good luck.


On Fri, Jul 18, 2014 at 5:40 AM, Lluís Batlle i Rossell 
wrote:

> I didn't do development, but run android apps in an emulator.
>
> I installed one android SDK (nix-env -iA
> nixos.pkgs.androidenv.androidsdk_4_1),
> and the 'android', 'emulator', commands work fine.
>
> Others may tell about developing.
>
>
> On Thu, Jul 17, 2014 at 07:57:03PM +0200, Jascha Geerds wrote:
> > Hi there,
> >
> > I would like to start Android developement as a hobby. Has anyone
> > experience with that on NixOS? I already saw the
> > "pkgs/development/mobile/androidenv" section in nixpkgs but I don't know
> > the usage of all these *.nix files.
> >
> > It would be nice if someone share his workflows on this topic.
> >
> > Jascha Geerds
> >
> > --
> >   Jascha Geerds
> >   j...@ekby.de
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Picocom and /run/lock permissions

[Luke Clifton]

Hi,

I just installed picocom and ran into a small problem (which I have
encountered before on other distributions [0]) to do with lock files in
/run/lock.

The issue is that picocom is creating its lock files directly in /run/lock,
which is only root writeable. Requiring root to run picocom is not really
ideal. According to [0] device locks should be in /run/lock/lockdev. This
directory would be group writeable, and be owned by group "lock". I would
then recompile picocom to use /run/lock/lockdev instead and make sure I
belong to the "lock" group.

So it seems NixOS is doing the right thing with the permissions, I'm just
wondering what the deal is with creating extra directories in the /run/lock
directory which can be used by non-root programs, or whether locks should
be placed somewhere else in NixOS.

Regards,

Luke

[0]
http://lists.freedesktop.org/archives/systemd-devel/2011-March/001823.html
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev