Re: [Nix-dev] Problems while packaging Lumina Desktop on NixOS

2016-08-20 Thread Shell Turner
On 20 August 2016 at 20:03, Anderson Torres
 wrote:
> Hello, Nixers!
>
> I am porting Lumina Desktop on NixOS[1]. After some hard work, it is
> building fine, but I can't run it. When I tested it on a qemu vm, the
> command start-lumina-desktop barfs:
>
> `QCoreApplication::applicationDirPath: Please instantiate the
> QApplication object first`
>
> Can you help me, please?

Reading Lumina's source code, it appears it only calls that function
before creating a QApplication if DISPLAY isn't set. Basically - you
have to run Lumina from inside an X session to avoid that, attempting
to have it start one itself seems to have a bug.

>
>
> 1 - https://github.com/AndersonTorres/nixpkgs/tree/lumina-on-nixos
> ___
> 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] Malicious installation methods

2016-06-17 Thread Shell Turner
>>> Is the nix root dir configurable? Would it be that horrible to have
>>> /opt/nix or /var/lib/nix or something else be the nix root on Debian?
>>
>> It's not strictly required, but it would mean losing out on all the binary
>> packages provided by the CI.
>
> Aren't they built in a chroot like Guix does? Why would anything break
> just because you change where they are installed?

All Nix packages refer to their dependencies by their full path. It's
embedded in binaries, config files, etc etc.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-dev] bower

2014-11-07 Thread Shell Turner
Hey,

I'm trying to get Bower running under NixOS. After installing it with
nix-env -iA nixos.pkgs.nodePackages.bower, running bower outputs:

module.js:340
throw err;
  ^
Error: Cannot find module 'es5-ext/object/assign'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object.anonymous
(/nix/store/2pnixcmhgdmjpriprszjfsabva07j5bh-node-d-0.1.1/lib/node_modules/d/index.js:3:21)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)

Any ideas?
Shell
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Is systemd a benefit or a liability?

2014-10-19 Thread Shell Turner
On 19 October 2014 10:48, Peter Simons sim...@cryp.to wrote:
 Hi guys,
 If you have systemd installed, then half of your Unix ecosystem is
 locked into one particular implementation of services that used to be
 diverse, modular, and replaceable.

I'll note that there's a couple of re-implementations of parts of
systemd. There's Debian's systemd-shim, and the higher-level
systembsd. There's also nosh, a small, simpler init system that allows
for automatically converting some types of systemd unit file to its
own format, which allows for configurable logging, and a few more
interesting things.

That's not to disagree with you entirely - I'm no fan of how systemd
appears to be taking every core service and bringing it under its
umbrella and forcing them to depend on systemd (udev being a
particularly irritating one - Unless the systemd-haters prepare
another kdbus userspace until then this will effectively also mean
that we will not support non-systemd systems with udev anymore
starting at that point).

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


Re: [Nix-dev] Firefox

2014-10-12 Thread Shell Turner
firefox-with-plugins is actually firefoxWrapper, and doesn't
actually have any plugins enabled by default. firefoxWrapper simply
creates a shell script which launches firefox with various paths
allowing it to load plugins. It changes depending on what plugins you
enable, so it doesn't make much sense to provide it as a binary.
Firefox itself is provided as a binary (firefox-32.0.3), and that's
what firefoxWrapper wraps.

In order to configure those plugins, you have to edit
~/.nixpkgs/config.nix to enable various options - the details are in
the wiki: https://nixos.org/wiki/Firefox

Shell

On 12 October 2014 09:03, Catonano caton...@gmail.com wrote:
 Hello,

 why is firefox-with-plugins not available as a binary ?

 me@my-machine ~$ nix-env -qas | grep firefox
 --S  firefox-32.0.3
 --S  firefox-bin-32.0.3
 ---  firefox-with-plugins-13.0.1
 ---  firefox-with-plugins-32.0.3

 and what's the difference between firefox and firefox-with-plugins ?

 I can't find firefox-with-plugins in the nixpkgs repository

 ___
 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] Reconsidering dash in package names

2014-10-10 Thread Shell Turner
Wouldn't it make more sense to simply map foo-bar on a derivation to
foo_bar as a shell variable? Are there any significant cases where
this would be problematic?

On 10 October 2014 22:39, Luca Bruno lethalma...@gmail.com wrote:
 derivation {
   inherit foo-bar;
   buildPhase = ''
 use $foo-bar...
   '';
 }

 Apart ${foo-bar}.

 On Fri, Oct 10, 2014 at 11:18 PM, Bjørn Forsman bjorn.fors...@gmail.com
 wrote:

 On 10 October 2014 22:56, Luca Bruno lethalma...@gmail.com wrote:
  Dash in package names are cool, because they map to the real package
  name.
  However I just found a breaker: bash does not support variables with
  dash.
  $foo-bar or ${foo-bar} or whatever does not work.

 I don't understand. Why/when do we need bash variable _identifiers_
 named like packages (with dashes)? And what values would those
 package name variables contain?

 Best regards,
 Bjørn Forsman




 --
 www.debian.org - The Universal Operating System

 ___
 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] New website

2014-05-30 Thread Shell Turner
So I just had a look at the new NixOS website, and I have a major
problem with it... I can't find the documentation. And that's as
someone who already knows what NixOS is and why I'd want to use it.
Worse, anything about NixOps/etc is hidden away in a menu in the top
right corner!

I didn't even notice the top bar until I'd gone to look a few more
times. Why can't we have a Debian-style places to go menu on the
front page, front and centre? https://www.debian.org/
 Even FreeBSD's
is better in terms of being able to figure out where to go.
http://www.freebsd.org/


The current front page has a huge amount of fluff, but the call to
action (get it) is all wrong; nobody downloads new operating systems
on a whim, they want to see examples of what it would do for them. The
getting started section on the Debian front page goes a long way to
fixing this.

So basically, what the front page needs is (a) a fairly comprehensive
and obvious menu of things a user would want from the site, and (b)
links off to places where a new user can find out more. Probably a
hook (NixOS is a Linux distribution which uses a fully declarative
package manager and integrated configuration management system, making
system configuration and upgrades painless), maybe a snippet of a
configuration.nix showing off how easy it is to set up, say, a simple
web server or a desktop environment, and maybe a little widget saying
what the current version is + a couple of titles of the latest news
articles. I'm not sure the declarative, reliable, devops-friendly
fluff helps anybody.

Just my two cents,
Shell

On 30 May 2014 14:26, Ertugrul Söylemez ert...@gmx.de wrote:
 Hello there,

 I'm looking at the new website with mixed feelings.  Being less static is a 
 good idea, so I appreciate the news, blog posts and commits sections.  On the 
 other hand it's way uglier and less lucid compared to the old website.  These 
 are minor design issues that we can talk about and fix.

 However, one issue with the new site I would rate as critical:

 As a good web developer NEVER EVER download anything from external servers 
 unless it is necessary, especially not from entities like Google, Facebook or 
 Twitter.  If at all, do it server-side.  The new website unnecessarily 
 downloads jQuery from the Google servers, not only compromising our privacy, 
 but also every NoScript or Ghostery user will be told: This website 
 compromises your privacy!.  And for what?  For a dropdown menu?  Come on!  
 You don't even need JavaScript for that.  CSS alone can handle it much nicer.

 I have managed to keep my browser from sending my browsing habits to Google 
 for a long time now.  Indeed, I don't even use Google as a search engine 
 (there's DuckDuckGo).  And today my very Linux distribution forces me to 
 allow access to Google servers.  That's not going to happen, so currently I'm 
 unable to navigate the website at all.  This is the top issue, so as kindly 
 as my current anger allows, I'm asking you to fix this as soon as possible.  
 I hope I'm not the only privacy-minded NixOS user.

 As SPJ once said, avoid success at all costs, because this is what happens 
 when you don't.  I'm not sure the old website really needed to be replaced, 
 but since it was, please remove the badies and bring back the goodies.

 Also in this case please don't tell me to send a pull request.  This is web 
 development!  What would take the original developer five minutes would take 
 me hours.

 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
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Installing wireless drivers

2014-04-02 Thread Shell Turner
Relevant issue re vmware video driver not building:
https://github.com/NixOS/nixpkgs/issues/2099

(Just posted this off-list by mistake, oops.)

On 2 April 2014 08:59, Raahul Kumar raahul.ku...@gmail.com wrote:
 I have discovered the vmware video driver won't build. How do I dfisable
 this driver from being loaded? I only have an ATI card, I don't need these
 superflous video card drivers being built. This also explains why the
 wireless doesn't work .. it never finishes the upgrade.


 On Tue, Apr 1, 2014 at 4:16 PM, Sergey Mironov grr...@gmail.com wrote:

 Probably, you have made a mistake in the configuration.nix. Here is my
 config which enables wicd, please re-check your layout.

 https://github.com/grwlf/nixpkgs/blob/local/machines/samsung-np900x3c.nix

 And here is another config, this time containing NetworkManager


 https://github.com/grwlf/nixpkgs/blob/local/machines/samsung-np900x3c-v2.nix

 Hope, they help.

 Regards,
 Sergey

 2014-04-01 5:39 GMT+04:00 Raahul Kumar raahul.ku...@gmail.com:
  I have Sergey, unfortunatley nixos is saying it doesn't recognize those
  options.
 
  error: user-thrown exception: The option `wicd' defined in
  `/etc/nixos/configuration.nix' does not exist.
  (use `--show-trace' to show detailed location information)
  building the system configuration...
  error: The option `wicd' defined in `/etc/nixos/configuration.nix' does
  not
  exist.
 
  Looks like all the options have changed. So how do I setup using
  NetworkMangager?
 
 
  On Mon, Mar 31, 2014 at 9:27 PM, Sergey Mironov grr...@gmail.com
  wrote:
 
  Hi. Have you checked this wiki?
 
  https://nixos.org/wiki/WICD
 
  By the way, NetworkManager or KDE's equivalent may be a better choice
  for managing wireless networks. Wicd worked for me too, but it looks
  abandoned by it's developers.
 
  Regards,
  Sergey
 
 
  2014-03-31 10:10 GMT+04:00 Raahul Kumar raahul.ku...@gmail.com:
   Hi guys,
  
   i've recently switched to a wireless configuration. Where can I
   download
   the
   WICD and other wireless packages? I'm on 64bit nixos. And after
   downloading,
   how do I install them? I do have a windows laptop to download
   packages
   with.
  
   Aloha,
   RK.
  
   ___
   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] NiJS package manager

2014-04-01 Thread Shell Turner
 http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html

 I have discovered that the Nix expression language is complicated and
 difficult to learn. Like Haskell, it has a solid theoretical foundation
 and powerful features (such as laziness), but it's too hard to learn by
 developers without an academic background.

I entirely disagree with this. From my perspective, Nix is a great
language which covers the simple cases simply. I've been building an
OpenVPN+VNC server (the equivalent of Terminal Services in the Windows
world) with Nix, with no prior experience of either Nix or functional
programming past the more functional bits of Python. It's been
remarkably easy to define my own extensible services and extend
packages when I need to, and I've had no problem doing so.

Perhaps more complicated use cases are significantly more complicated
to implement, but I'm not sure optimizing for them at the expense of
the simplicity of Nix is a good idea. Part of what attracted me to
NixOS in the first place was the simplicity of configuring it.

 But anyway: We have 3 solutions for describing packages:
 nix, guix, nixjs

 Thus eventually its time to think about which information could be
 shared. Who would join a software version documentation project
 allowing people to upload the most recent version of my software is X,
 and it requires Z, FOO, BAR ?

 Then some nix, nijs, guix packages could be derived automatically (like
 haskell, ruby, xorg, .. packages). And all the other package systems
 such as debian could benefit eventually, too.

I would prefer that we simply work on making these interoperable. That
is, define an API - packages can include each other, have things like
mkDerivation, etc - build a library that implements that API, and
allow languages to plug into that library. You would then be able to
write in whichever language you chose, and include expressions from
other languages. The system could even automatically build the runtime
for whichever languages I use.

Then, Disnix could be written in NiJS, and some packages I want could
be written in Guix, some interesting library could be written in
something else entirely, but I could write my configuration in Nix.

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