Re: [Nix-dev] Upcoming PyPi URL Scheme Change

[Graham Christensen]

Profpatsch  writes:

> Maybe it’s time to automate what we can? Similar to Hackage?

I'm not too familiar with what is done with Hackage, but I think what
we have for Python isn't a good approach. I have a meeting with dstufft
to try and come up with a better solution. It might be helpful to
understand what we have with Hackage to do a better job.

I know Domen has specific expertise here, and probably has some really
valuable feedback.

My problem with the current system is we have many arbitrarily versioned
python packages referencing each other in a haphazardly developed graph
of dependencies. Upgrading one package has a nasty cascading effect of
needing to upgrade each of the other ones depending on it. This has
stymied at least one of my attempts at contributing fixes.

For development dependencies, more fully automating it is probably the
best approach.

I think for applications, it would be more beneficial to take an
approach similar to Bundix, Npm2Nix, etc. The community's current tools
for Python (pypi2nix, pip2nix, others?) seem to work on some types of
packages, and sometimes not on others.

I have a prototype of an alternative method which leans harder on pip
to do the work than nix. Instead of building each python dependency in
its own derivation:

 1. it creates a fake Pypi mirror of all the dependent packages
 2. installs all of the packages at once with `pip install -r
 requirements.txt`

This avoids issues like circular dependencies and other complexities of
how python packaging works, but is a much heavier-weight installation
mechanism. I'll have to test more before saying it is good or not.

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

[Nix-dev] Pull request for sssd package, RFC

[Ben Booth]

Hi all,

I recently submitted a pull request to nixpkgs to add the sssd package:

https://github.com/NixOS/nixpkgs/pull/14697

For those not familiar, sssd is RedHat's daemon for managing LDAP 
authentication, automount maps, and other things. The website is here:

https://fedorahosted.org/sssd/

One troublesome thing about installing sssd on nix is that it requires a 
libnss_sss.so file to be installed in the dynamic linker lookup path, which on 
NixOS is limited to glibc's lib folder in /nix/store. More information on this 
problem is here:

https://github.com/NixOS/nixpkgs/issues/1868

There are a few ways I can think of to try and workaround/fix this problem:
1. set LD_LIBRARY_PATH in some global location like /etc/profile to point to 
the sssd lib folder in /nix/store
2. wrap every program that potentially uses glibc for nsswitch lookup in a 
script that sets LD_LIBRARY_PATH (e.g. perl, python, plus a lot more...)
3. modify the glibc nix expression to depend on sssd, and copy in the 
libnss_sss.so file from sssd (causes infinite recursion)
4. patch glibc to look in other places for libnss_sss.so
5. use the currently-unused ld.so.conf file in glibc's /etc/ folder in 
/nix/store to add system and profile lib folders to the search path

My pull request implements the fifth option, but since this changes glibc's 
build hash, and pretty much everything depends on glibc, it basically means 
rebuilding everything. I've had trouble testing the glibc changes adequately, 
since it will require rebuilding every package on my machine. I basically had 
to remount /nix/store as read-write and manually add ld.so.conf and cache file 
to the glibc folder.

I've gotten comments on the pull request that the ld.so.conf approach would not 
be well received by the NixOS devs. Does anyone know why using ld.so.conf could 
be a problem? If patching glibc would be preferable, I don't mind at all, I 
just want to understand the rationale, since ld.so.conf functionality already 
exists and serves the same purpose. One comment said to patch glibc to look in 
some place like /run/nss-modules for extra libnss_* modules, but that would 
only work on NixOS. I would like to get this working for nix installations on 
other OS's as well, so the search path would have to be somewhere in the nix 
prefix. 

I would like to get this pull request accepted, since all the other major linux 
distros have sssd support. We're using sssd at my work, and I'd like to start 
using NixOS VMs at work. But I think the glibc issue could be a blocker for 
this pull request.

Does anyone have any tips, comments, or ideas how to proceed?

Thanks!
Ben Booth
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] libxml2

[Karn Kallio]

The file xml2-config will not report the path to xml2-config itself
since that was moved to the dev output.  The attached patch sets
exec_prefix to match the executable files placed in the dev output.
>From ddd8f1a6c52be129be73faf023f9769cede75042 Mon Sep 17 00:00:00 2001
From: Karn Kallio 
Date: Wed, 20 Apr 2016 17:58:19 -0430
Subject: [PATCH] libxml2 : Have exec_prefix match the location of
 bin/xml2-config.

---
 pkgs/development/libraries/libxml2/default.nix | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pkgs/development/libraries/libxml2/default.nix b/pkgs/development/libraries/libxml2/default.nix
index f7e1753..8eedf50 100644
--- a/pkgs/development/libraries/libxml2/default.nix
+++ b/pkgs/development/libraries/libxml2/default.nix
@@ -20,7 +20,7 @@ stdenv.mkDerivation rec {
 
   propagatedBuildInputs = [ zlib findXMLCatalogs ];
 
-  configureFlags = "--with-python=${python}";
+  configureFlags = "--with-python=${python} --exec_prefix=$dev";
 
   enableParallelBuilding = true;
 
-- 
2.8.0

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

Re: [Nix-dev] Upcoming PyPi URL Scheme Change

[Profpatsch]

On 16-04-20 11:41am, Graham Christensen wrote:
> I recently got word that PyPi is changing their URL scheme.
> 
> Old example:
> https://pypi.python.org/packages/source/a/ansible/ansible-1.8.2.tar.gz#md5=c2ac0e5a4c092dfa84c7e9e51cd45095
> 
> New example:
> https://pypi.python.org/packages/62/18/91f0e5059373e9b87588c2a1c3b4c3c08ee89e0443aa2017469a4cdae41c/SCRY-1.1.2-py2-none-any.whl#md5=a3c636c4e94df1f0644b6917a9c05e67

This is going to be a lot of work.

> Yet another option is to run a sort of "translator" service that can 
> consume
> the PyPI JSON API and will output the URLs in whatever format best suites 
> you.
> An example of this is pypi.debian.net (which I don't know where the code 
> base
> for it is, but the proof of concept I wrote for it is at
> https://github.com/dstufft/pypi-debian). These translators are fairly 
> simple,
> they take an URL, pull the project and filename out of it and then use 
> the JSON
> API to figure out the "real" URL and then just simply redirects to that.

Maybe it’s time to automate what we can? Similar to Hackage?

-- 
Proudly written in Mutt with Vim on NixOS.
Q: Why is this email five sentences or less?
A: http://five.sentenc.es
May take up to five days to read your message. If it’s urgent, call me.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Why not use SONAME instead of RPATH

[Wout Mertens]

Woah I love that! +1, I don't see why we can't do that…

Wout.

On Wed, Apr 20, 2016 at 1:52 PM Silvio Frischknecht  wrote:

> Hello,
>
> I recently found out that if you set the SONAME of a library to an
> absolute path.
>
> gcc --shared -Wl,-soname="$(pwd)/libxyz.so" -o libxyz.so  libxyz.c
>
> and then later link to it
>
> gcc main.c -L. -lxyz
>
> the dynamic linker will only look for the library in the exact path
> specified when compiling the library.
>
> Advantages over RPATH:
> + probably faster since rpaths in nixos tend to be quite long and every
> library has to be looked for in every folder (linear vs quadratic
> complexity)
> + only has to be setup once per library - all referrers will
> automatically work correctly
>
> In this case the path can't be overwritten by LD_LIBRARY_PATH. I guess
> that could be an advantage or a disadvantage depending on how you look
> at it.
>
> Cheers
>
> Silvio
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Upgrade from 15.09 to 16.03 with NixOps

[Wout Mertens]

The expressions are evaluated from the coordinator, so either you upgrade
the channel there or you check out nixpkgs somewhere and set
`NIX_PATH=nixpkgs=/path/to/your/clone` before running nixops.

On Wed, Apr 20, 2016 at 1:52 PM Teo Klestrup  wrote:

> I believe the channels are taken from the coordinator, so when the
> coordinator is upgraded then the other machines should be, too.
> On 18 Apr 2016 19:20, "4levels" <4lev...@gmail.com> wrote:
>
>> Hi Nix'ers,
>>
>> This is an Nix Ops related question.
>>
>> How can I specify which channel to use inside the nix expressions (*.nix
>> files) for nixops?
>>
>> Thanks in advance!
>>
>> Erik
>>
>> ___
>> 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
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] ioquake3 on nixos

[Nikolay Amiantov]

Hi,

On 04/19/2016 07:20 AM, Máté Kovács wrote:
> (In case you're wondering: I didn't yet figure out what's wrong with my
> channels, so I'm pointing to a clone of the nixpkgs github repo using
> the -I option for building the game.)

Try my fix, I think it might work. My theory is that  points to
your 15.09 channel because we have
/nix/var/nix/profiles/per-user/root/channels/nixos in NIX_PATH by
default. When nix sees , it tries to find directory "foo" in all
paths listed in NIX_PATH. "nixos" channel has "nixpkgs" symlink inside
which points to itself:

/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs -> ..

So that's what gets found when you do `import `. Renaming
"nixpkgs-small" channel to "nixpkgs" should fix this because it gets
higher priority.

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

[Nix-dev] Upcoming PyPi URL Scheme Change

[Graham Christensen]

Hello Nixers,

I recently got word that PyPi is changing their URL scheme.

Old example:
https://pypi.python.org/packages/source/a/ansible/ansible-1.8.2.tar.gz#md5=c2ac0e5a4c092dfa84c7e9e51cd45095

New example:
https://pypi.python.org/packages/62/18/91f0e5059373e9b87588c2a1c3b4c3c08ee89e0443aa2017469a4cdae41c/SCRY-1.1.2-py2-none-any.whl#md5=a3c636c4e94df1f0644b6917a9c05e67

This is just a heads-up for anyone who updates the next python package.

>From Donald Stufft, of PyPa:

So, previously PyPI used URLs like :
/packages/{python version}/{name[0]}/{name}/{filename}

Now it uses:
/packages/{hash[:2]}/{hash[2:4]}/{hash[4:]}/{filename}
Where hash is blake2b(file_content, digest_size=32).hexdigest().lower()

There are a few reasons for this:

* We generally do not allow people to delete a file and re-upload the same
  version again. However the old lay out generally means that we *can't* do
  that even if we wanted to because HTTP clients will use the URL as the key
  for a cache and thus it can never change (other than to be deleted).

* The file system is not transactional and isn't part of the database, which
  means we get put in a funny pickle where we have to decide if we persist 
the
  change to the file system *prior* to committing the transaction or *after*
  committing. Both ways have their ups and downs and neither solves all of 
the
  issues. In general, on upload we try to save the file prior to committing
  because once it's been committed downstream users will expect it to exist
  and if we haven't saved the file to disk yet it may not yet exist yet (and
  if saving fails, it may never exist).

  However, this raises a problem. We're currently using Amazon S3 to save
  files which is an eventually consistent data store. When writing a brand
  new file it will be (in the S3 region we're using) available immediately
  after writing a *new* file, however for writing a file that has already
  existed it can take some time for it to be consistent (reportedly being 
able
  to take up to hours for this to occur). This leaves us in a sticky 
situation
  where someone can run this:

  setup.py sdist upload

  And have PyPI accept the upload, write it to S3 and then fail to commit 
the
  upload. Then when the user re-runs that we'll write the file to S3 again
  (however it will have changed contents because ``setup.py sdist`` is not
  deterministic) and then commit the database, succeeding this time. If this
  happens then in the time period between when the database commits and when
  Amazon S3 has yet to update the file to the latest version (possibly 
taking
  hours) everyone is going to fail downloading/installing that file because
  the hash we're getting from Amazon S3 isn't going to match the hash that 
we
  have recorded in the PyPI database. To make this even more painful, we
  utilize download caching of the files pretty heavily and to do that we 
make
  the assumption that the contents at the URL will never change. So not only
  will it be broken in that window before Amazon S3 has become consistent, 
it
  will be persistently broken for anyone who attempted to install it until
  they go out of their way to delete their cache. By making the URL 
determined
  by the *contents* of the file, we make it so repeating the same upload 
with
  different contents will by definition end up with a different URL side
  stepping the entire problem.

* When a file gets deleted from PyPI we have to delete it from the backing
  store too because the URL is predictable and people attempt to short 
circuit
  the Simple Repository API and we want a file deletion to, by default, mean
  that people don't discover that version. However, this flies in the face 
of
  people who use the simple repository API to resolve a version (or the Web 
UI)
  who then want to resolved URL into something with the expectation it will 
not
  change or go away. This change allows us to simply stop deleting files, so
  that if someone bakes a file URL into something it can continue to work 
into
  perpetuity without people accidentally installing that through simple URL
  building in the end user software.


Now even though the specific location of the file has not been considered 
part
of our "API" nonetheless people have over time baked in assumptions about 
that
URL scheme in various things, and obviously this change will break those
things. So then how should someone deal with this change?

Well, the simplest (though perhaps not the least effort) is to remove 
whatever
assumptions have been made and replace them with the new URL structure. This
will fix things today, but it may or may not be the case that tomorrow the 
URL
structure changes again.

Another option is to 

Re: [Nix-dev] Why not use SONAME instead of RPATH

[Kevin Cox]

On 17/04/16 12:02, Silvio Frischknecht wrote:
> 
> Advantages over RPATH:
> + probably faster since rpaths in nixos tend to be quite long and every
> library has to be looked for in every folder (linear vs quadratic
> complexity)
> + only has to be setup once per library - all referrers will
> automatically work correctly
> 

TBH I've been wondering the same thing when reading documentation talked
about rpath. This seems like the simpler more direct method. It also
avoid the theoretical problem where there are two libraries of the same
name in different folders, this allows you to specify exactly which one
although that is unlikely to ever become a real problem.

But in general in my Nix usage I try to avoid long search paths such as
rpath and PATH, instead preferring to use absolute paths everywhere with
no search just because it is simpler, and probably more performant.

Cheers, Kevin



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] few questions before migrating from Debian…

[Roger Qiu]

UEFI requires a separate ESP partition anyway. Unless you plan on running
on FAT32.
On 16/04/2016 9:35 PM, "Saša Janiška"  wrote:

> Roger Qiu  writes:
>
> > Will you be using UEFI?
>
> Yes, on my single-disk netbook…any gotcha in regard?
>
>
> Sincerely,
> Gour
>
> --
> Just try to learn the truth by approaching a spiritual master.
> Inquire from him submissively and render service unto him.
> The self-realized souls can impart knowledge unto you because
> they have seen the truth.
>
> ___
> 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] Nix-like npm replacement (NodeJS)

[Roger Qiu]

Yep and it (along with nixpkgs and git) is one of the few package managers
that focus on content addressability.
On 20/04/2016 7:50 PM, "Wout Mertens"  wrote:

> I thought this would be interesting for some people on this list:
>
> http://gugel.io/ied/ :
>
> Under the hood, ied maintains an "object database", similar to git.
> Instead of storing packages by some arbitrary name, a SHA1-checksum is
> being generated to approximate their contents. The checksums can not only
> be used for guaranteeing a certain level of trust and consistency, but they
> also simplify the algorithm through which dependencies are being managed.
>
> The algorithm through which packages are being installed guarantees
> consistency through atomic installs. The installation of a package either
> fails or succeeds, but at no point in time can a dependency itself be
> required without having its own sub-dependencies installed (with the
> exception of shared circular dependencies).
>
> The checksum of a package is based on the contents of the package itself,
> not of its sub-dependencies. Therefore the validity of a package can be
> verified by hashing the package itself. Subsequent dependency updates have
> no effect of the generated checksum.
>
> Since node_modules is essentially a file-system based content addressable
> storage, multiple versions of the same package can co-exist in the same
> project.
> --
>
> Wout.
> (typed on mobile, excuse terseness)
>
> ___
> 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] few questions before migrating from Debian…

[Online Touch | Danny Wilson]

ZFS is the best :-)

My gist ( https://gist.github.com/vizanto/7374277 ) is still relevant. With 
slight modifications you don’t need a separate /boot filesystem since recent 
Grub can read ZFS filesystems (mirrors, not sure about RAID-Z) just fine.
Basically just skipping the partitioning steps and creating a whole disk zpool.

A few months ago I've installed NixOS on ZFS root (mirrored disks) so I know 
it’s possible.


Cheers,
Danny


On 9 apr. 2016, at 21:07, Saša Janiška  wrote:

> Hello,
> 
> for some time I’m considering which Linux distro to use to have
> relatively fresh packages as well as not to waste too much time for
> admin work.
> 
> Morever, it would be ideal to have same distro for the machine of my
> relative’s to make it easier during trouble.shooting session. So, in
> order to fulfill those two requirements I did consider to stay with
> Debian (Sid) on my desktop and netbook machines, but put Debian Stable
> on the machines of my relatives.
> 
> However, after checking about NixOS which I tried many years ago, I’ve
> concluded it’s the best option at the moment since I learnt that
> nixos-stable might be good-enough for other’s machine requiring not much
> admin time, while I can use nixos-unstable if stable channel is not
> fresh–enough for my own needs.
> 
> So, before jumping to install on real hardware - today I did install
> under vbox, I’ve few questions…
> 
> My desktop is i7 2.8G/16G machine having 1xTB+1x2TB disks which are
> assembled in btrfs raid1 with / and /home as btrfs subvolumes (the
> remaining 1TB is used for daily backups.)
> 
> I’m delighted that NixOS provides ZFS as filesytem option since it was
> one of the reasons why I was evaluating Free/PC-BSD option in the past.
> 
> a) do you, in general, recommend using ZFS over Btrfs for NixOS desktop
> machine?
> 
> b) is ZFS good option even for single-disk netbook machine with 4G of
> memory?
> 
> c) can one use ZFS on root *without* usage of separate /boot partition?
> I use same disk layout on Debian, but with btrfs and do not have any
> experience with ZoL, although I’ve found that there is
> ’boot.loader.grub.zfsSupport’ option?
> 
> Any doc/tutorial explaining how to do such install?
> 
> I’ve found: https://gist.github.com/vizanto/7374277 but wonder if it is
> still relevant?
> 
> There are of course few packages I do miss in NixOS, but everything else
> is so great, so that I’m very enthusiastic to put NixOS on all my
> relative’s  machines very soon.
> 
> On all machines, I plan to use GNOME3, so wonder if there are some
> gotchas in regard - someone on #nixoes mentioned that GTK does not like
> custom paths as used by Nix and recommended i3 instead which is, atm,
> not option considering that other family members also use my machine and
> relatives are not savvy-enough for that tiling wm.
> 
> 
> Sincerely,
> Gour
> 
> -- 
> Therefore, without being attached to the fruits of activities,
> one should act as a matter of duty, for by working without
> attachment one attains the Supreme.
> 
> ___
> 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] PolicyKit timeout after upgrade to 16.03

[4levels]

Hi Roger,

the weird thing is that my local vm, the machine that actually deploys the
servers, doesn't have this issue.  This instance also runs nixos-16.03 and
uses the same nixos-16.03-small channel.

This issue started when trying to upgrade to 16.03  I was not really clear
about how to do this so I ended up running nix-channel add ... nixos on all
deployed servers, causing all the nixops deployed config to be lost,
resulting in having to redeploy every server.  Currently I'm still unsure
how to upgrade machines deployed with nixops :-(

I don't mind redeploying every machine to solve this, as the issues are
piling up now: I need to reboot a server because I can't do any systemctl
call anymore that requires root privileges.  Even when first switching to
the root account (I know the password), this issue persists.  I'm still
completely unsure where this issue comes from.  Googling this error "Error
getting authority: Error initializing authority: Error calling
StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached
(g-io-error-quark, 24)" gives me tons of pages with polkit, dbus and
systemd things that go far beyond my understandings.

When running the polkit service with strace, I can see loads of errors
about files not being found and the trace ends with

write(2, "Error switcing to user polkituse"..., 98Error switcing to user
polkituser: Error changing to home directory /var/empty: Permission denied
) = 98

Please find attached the full strace log.  I really hope someone can assist
further in this nasty issue.  Maybe it is related to the use of
nixos-16.03-small instead of nixos-16.03.  But since I'm using nixos for
servers only, without the need for a desktop environment, I was expecting
the small channel to be better..

Kind regards!

Erik

On Wed, Apr 13, 2016 at 12:57 PM Roger Qiu  wrote:

> Have you tried rolling back to 15.09, does it still happen?
>
>
> On 13/04/2016 4:47 PM, 4levels wrote:
>
> Hi Nix'ers,
>
> No one? Im I the only one who's experiencing this?
>
> This timeout still occurs and makes every call to systemctl at least 30
> seconds slower, pretty annoying actually..
>
> Hope someone with understanding can shed some light on what might be going
> on here.
>
> Erik
>
> On Tue, Apr 12, 2016 at 3:00 AM 4levels < <4lev...@gmail.com>
> 4lev...@gmail.com> wrote:
>
>> Hi Nix'ers,
>>
>> After upgrading to version 16.03 I'm facing timeouts whenever I try to
>> restart a service via systemctl restart.
>> I might be overlooking something obvious here, as I just ran
>> nix-channel-add https://nixos.org/channels/nixos-16.03-small nixos
>> nixos-rebuild boot --upgrade
>>
>> Any hints in what could be the issue?
>> This is the full error message on the console:
>>
>> Error getting authority: Error initializing authority: Error calling
>> StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached
>> (g-io-error-quark, 24)
>>
>> I can run other commands through sudo though.
>>
>> Thanks!
>>
>> Erik
>>
>>
>
> ___
> nix-dev mailing 
> listnix-...@lists.science.uu.nlhttp://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
> --
> Founder of Matrix AIhttps://matrix.ai/
> +61420925975
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
[root@administration:/root]# strace /nix/store/wb07v337r8d6l4g5pqns364qpajnw57n-polkit-0.113/lib/polkit-1/polkitd
execve("/nix/store/wb07v337r8d6l4g5pqns364qpajnw57n-polkit-0.113/lib/polkit-1/polkitd", ["/nix/store/wb07v337r8d6l4g5pqns3"...], [/* 51 vars */]) = 0
brk(NULL)   = 0xe33000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8e94895000
access("/etc/ld-nix.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/nix/store/wb07v337r8d6l4g5pqns364qpajnw57n-polkit-0.113/lib/tls/x86_64/libpolkit-gobject-1.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/nix/store/wb07v337r8d6l4g5pqns364qpajnw57n-polkit-0.113/lib/tls/x86_64", 0x7ffc0a8379c0) = -1 ENOENT (No such file or directory)
open("/nix/store/wb07v337r8d6l4g5pqns364qpajnw57n-polkit-0.113/lib/tls/libpolkit-gobject-1.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/nix/store/wb07v337r8d6l4g5pqns364qpajnw57n-polkit-0.113/lib/tls", 0x7ffc0a8379c0) = -1 ENOENT (No such file or directory)
open("/nix/store/wb07v337r8d6l4g5pqns364qpajnw57n-polkit-0.113/lib/x86_64/libpolkit-gobject-1.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/nix/store/wb07v337r8d6l4g5pqns364qpajnw57n-polkit-0.113/lib/x86_64", 0x7ffc0a8379c0) = -1 ENOENT (No such file or directory)
open("/nix/store/wb07v337r8d6l4g5pqns364qpajnw57n-polkit-0.113/lib/libpolkit-gobject-1.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\~\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0555, 

Re: [Nix-dev] Upgrade from 15.09 to 16.03 with NixOps

[Teo Klestrup]

I believe the channels are taken from the coordinator, so when the
coordinator is upgraded then the other machines should be, too.
On 18 Apr 2016 19:20, "4levels" <4lev...@gmail.com> wrote:

> Hi Nix'ers,
>
> This is an Nix Ops related question.
>
> How can I specify which channel to use inside the nix expressions (*.nix
> files) for nixops?
>
> Thanks in advance!
>
> Erik
>
> ___
> 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] Why not use SONAME instead of RPATH

[Silvio Frischknecht]

Hello,

I recently found out that if you set the SONAME of a library to an
absolute path.

gcc --shared -Wl,-soname="$(pwd)/libxyz.so" -o libxyz.so  libxyz.c

and then later link to it

gcc main.c -L. -lxyz

the dynamic linker will only look for the library in the exact path
specified when compiling the library.

Advantages over RPATH:
+ probably faster since rpaths in nixos tend to be quite long and every
library has to be looked for in every folder (linear vs quadratic
complexity)
+ only has to be setup once per library - all referrers will
automatically work correctly

In this case the path can't be overwritten by LD_LIBRARY_PATH. I guess
that could be an advantage or a disadvantage depending on how you look
at it.

Cheers

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

Re: [Nix-dev] Accessing files in derivations.

[Vladimír Čunát]

On 04/20/2016 10:20 AM, Guillaume Maudoux (Layus) wrote:
> If providing default outputs is just a question of symlinking attributes
> to existing derivations, the following (pseudo)code would do, right ?

Yes, something like that would work in most cases. It would redirect
incorrectly in cases where e.g. man location is overridden by setting
outputMan variable - that's why I said the related selection code would
have to be moved from a builder hook (written in bash) to the evaluation
level (written in nix).

--Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Nix-like npm replacement (NodeJS)

[Wout Mertens]

I thought this would be interesting for some people on this list:

http://gugel.io/ied/ :

Under the hood, ied maintains an "object database", similar to git. Instead
of storing packages by some arbitrary name, a SHA1-checksum is being
generated to approximate their contents. The checksums can not only be used
for guaranteeing a certain level of trust and consistency, but they also
simplify the algorithm through which dependencies are being managed.

The algorithm through which packages are being installed guarantees
consistency through atomic installs. The installation of a package either
fails or succeeds, but at no point in time can a dependency itself be
required without having its own sub-dependencies installed (with the
exception of shared circular dependencies).

The checksum of a package is based on the contents of the package itself,
not of its sub-dependencies. Therefore the validity of a package can be
verified by hashing the package itself. Subsequent dependency updates have
no effect of the generated checksum.

Since node_modules is essentially a file-system based content addressable
storage, multiple versions of the same package can co-exist in the same
project.
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Monitoring by default

[Rok Garbas]

+1 for the initiative. i don't believe personally enabling monitoring
by default should be the right way to go (since we all use nixos in
different contexts), but having a commented instructions in generated
configurations.nix would be the way to go.

it would be nice if systemd monitoring stuff could be used as well:
https://github.com/garbas/dotfiles/blob/master/nixos/rok.nix#L236
above line makes systemd-cgtop showing numbers.



On Wed, Apr 20, 2016 at 8:44 AM, Alexei Robyn  wrote:
> Seems interesting. You mention alerts for "System software too old.", but
> the only vaguely-universal definition of "too old" I can think of would be
> "missing security updates", and that's both debatable and an area where
> NixOS is currently fairly lacking in infrastructure and tooling.
>
> Default collection of metrics beyond what is necessary to provide useful
> alerts is a bad idea. Alerts have essentially universal usefulness,
> statistics less so - they're unnecessary for most desktops and small
> servers. At least until you have issues, so of course it'd be nice if they
> were easy to switch on :p.
>
> - Alexei
>
>
> On Wed, Apr 20, 2016, at 12:40 AM, Svein Ove Aas wrote:
>
> Hi all,
>
> People who are not interested in reliability or monitoring can stop reading
> now.
>
> --
>
> I've written up a "design doc" (statement of intent?) for how we might do
> monitoring-by-default. Once I think there is a reasonable level of consensus
> about how we should do this, I'll go ahead and implement what's in the
> document, but I'd like to make sure we're all on the same page first;
> especially as I want this to be on by default.
>
> So I'd like your input. Can you take a look?
>
> --
> Svein Ove Aas
> ___
> 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
>



-- 
Rok Garbas
http://www.garbas.si
r...@garbas.si
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Accessing files in derivations.

[Guillaume Maudoux (Layus)]

Le 20/04/16 08:59, Vladimír Čunát a écrit :
> On 04/19/2016 10:03 PM, Layus wrote:
>> But your description made me think of a viable workaround.
>> We could ensure that every derivation has a fixed set of known outputs,
>> like dev, lib, out and man.
>> If there is no "lib" output, then the lib attribute could be an alias
>> for out.
> Yes, that has been suggested already and it's the current longer-term
> plan, at least as I see it. It requires nontrivial code rewrite, due to
> $outputLib and similar needing to be selected during evaluation and not
> during build.
>
> --Vladimir
If providing default outputs is just a question of symlinking attributes
to existing derivations, the following (pseudo)code would do, right ?

let
  selectFirst = drv: attrs:
if (empty attrs) then drv else
  if set ? (head attrs) then set.(head attrs) else selectFirst (tail
attrs);
  wrapDerivation = drv: {
out = selectFirst drv ["out"];
dev = selectFirst drv ["dev" "out"];
man = selectFirst drv ["man" "out"];
lib = selectFirst drv ["lib" "dev" "out"];
devdoc = selectFirst drv ["dev" "man" "out"];
  } // drv;
in
  mkDerivarion = drv: wrapDerivation (oldMkDerivation drv);

-- Layus.

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

Re: [Nix-dev] Accessing files in derivations.

[Vladimír Čunát]

On 04/19/2016 10:03 PM, Layus wrote:
> But your description made me think of a viable workaround.
> We could ensure that every derivation has a fixed set of known outputs,
> like dev, lib, out and man.
> If there is no "lib" output, then the lib attribute could be an alias
> for out.

Yes, that has been suggested already and it's the current longer-term
plan, at least as I see it. It requires nontrivial code rewrite, due to
$outputLib and similar needing to be selected during evaluation and not
during build.

--Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Monitoring by default

[Alexei Robyn]

Seems interesting. You mention alerts for "System software too
old.", but the only vaguely-universal definition of "too old" I can
think of would be "missing security updates", and that's both
debatable and an area where NixOS is currently fairly lacking in
infrastructure and tooling.
 
Default collection of metrics beyond what is necessary to provide useful
alerts is a bad idea. Alerts have essentially universal usefulness,
statistics less so - they're unnecessary for most desktops and small
servers. At least until you have issues, so of course it'd be nice if
they were easy to switch on :p.
 
- Alexei
 
 
On Wed, Apr 20, 2016, at 12:40 AM, Svein Ove Aas wrote:
> Hi all,
>
> People who are not interested in reliability or monitoring can stop
> reading now.
>
> --
>
> I've written up a "design doc" (statement of intent?) for how we might
> do monitoring-by-default. Once I think there is a reasonable level of
> consensus about how we should do this, I'll go ahead and implement
> what's in the document, but I'd like to make sure we're all on the
> same page first; especially as I want this to be *on* by default.
>
> So I'd like your input. Can you take a look[1]?
>
> --
> Svein Ove Aas
> _
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
 

Links:

  1. https://goo.gl/wmsWpY
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev