[Nix-dev] libnotify notifications with icons not displaying
I'm attempting to get notifications setup for when I use the volume keys on my keyboard, like in Ubuntu. I've setup xbindkeys, but the when I run notify-send -t 1000 -i multimedia-volume-control --hint=int:transient:1 --hint=int:value:$CURVOL --hint=string:synchronous:volume "Volume up $PERC%" "" No notification is displayed and in the logs I see Dec 12 20:19:35 tealc org.freedesktop.Notifications[1812]: ** (.notify-osd-wrapped:1922): WARNING **: WARNING: No layout defined!!! I haven't been able to find any reference to this on the web and am unsure what to do. Any tips would be appreciated. Rich ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
> - hackage-packages.nix is generated automatically by the "hackage2nix"
> utility
>from the "v2.x" branch of the cabal2nix repository [2]. The file defines
>builds for the respective latest version of every Hackage package.
>hackage2nix can include some older package versions, too, if necessary.
So does the spirit behind hack-nix win finally? Finally? :)
If we "rewrite" the stuff we should get it right this time.
I feel getting this right means
1) versioning hackage
2) implement a way to retrieve hackage packages (either by api or from
versioned hackage dump)
3) share package resolution with cabal (don't invent our own stuff -
because it will always be a lot of work and be totally different)
AFAIK Shea has added a way to load .dll functions. I think I remember it
is possible to call Haskell from C code. Thus what about collaborating
on the implementation sketched above?
It would serve as "sample" which could be adopted for the other
universes (perl/python/ruby/java/scala/rust/vim/emacs/whatever).
Thus how could usage look like?
haskellPackages {
hackage-dbs: [
"http://some-mirror/version/2014-12-10-hackage-packages.tar.gz";)
"my custom stuff"
]
resolve: "bytestring"
}
Due to referencing a hackage like database by date it should be
deterministic.
Fetching all versions of a package could be done by API (HTTP) or such -
thus downloading hackage would no longer be necessary.
Thoughts?
This is the next thing I'd try trying to learn from hack-nix.
For all of you who don't know what hack-nix is: Its a brute for
dependency solver written in Nix reading a hackage database which was
serialized to a .nix file doing exactly what Peter wants to implement:
Latest versions + some manually added older versions to make packages
resolve. Additionally its easy to add your own packages (eg dev
versions) and call the solver as well as patch packages (eg .cabal
files, especially its dependency information) before turning it into a
huge .nix file.
You can find a short description https://nixos.org/wiki/Nixpkgs-haskell-overlay
It was meant to be a proof of concept. Now I'd like to ask you whether
you would prefer joining a common effort which is most likely to work.
Its too painful to role my own solutions for everything (haskell, ruby
overlay etc - even though it often works nicely - and fails due to lack
of man power).
Peter: Please comment on the proposal, I'd rather join than keeping my
own stuff, but your attempt just seems to be another "hack-nix" with all
of its problems.
Who would join implementing the design I've sketched above?
Live is too short IMHO. My point of view might be limited - thus if I
make any bad assumptions please tell me.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Build $USER
Hi. On 12/12/2014 05:15 AM, Brandon Barker wrote: how do you get the correct $USER from within the nix build expression? As Peti explained in there, we strive to avoid the output depending on such things (purity, determinism, etc.). Best define USER=nobody or something similar. 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] Haskell NG
Not related to your central goals (which are awesome), but can we take this
opportunity to dashify attribute names as well?
> On Dec 12, 2014, at 2:38 PM, Peter Simons wrote:
>
> Hi guys,
>
> in the spirit of "release early, release often", I'd like to inform everyone
> with an interest in the Haskell part of Nixpkgs about the ongoing effort to
> re-factor both cabal2nix and the code in Nixpkgs to achieve ...
>
> 1) support for all of Hackage,
>
> 2) death to the ghc-wrapper, and
>
> 3) easier and more reliably customization of the package set.
>
> The Nixpkgs code lives in the "haskell-ng" branch of my Github clone [1]. In
> that branch, Haskell related code is in pkgs/development/haskell-modules:
>
> - hackage-packages.nix is generated automatically by the "hackage2nix" utility
> from the "v2.x" branch of the cabal2nix repository [2]. The file defines
> builds for the respective latest version of every Hackage package.
> hackage2nix can include some older package versions, too, if necessary. (I
> need to add code to hackage2nix to configure the choice of generated
> packages conveniently.)
>
> Note that a significant portion of those builds will not succeed because
> they depend on system libraries that we don't have. Finding those broken
> packages and fixing them (or adding meta.broken = true) will need a
> community effort once this setup has stabilized. The Hydra job [3] builds
> these packages to give us feedback on the state of affairs.
>
> - default.nix imports the contents from hackage-packages.nix, applies (a
> sequence of) configuration functions, and makes the result available as a
> "haskellPackages" set suitable for nix-env and friends. The purpose of those
> configurations is to adapt the package set for different compiler versions,
> i.e. you can think of this file as a simplified version of what used to be
> haskell-defaults.nix.
>
> In the new setup, it will no longer be possible to install Haskell libraries
> by name: you must access them by their attribute path. This is necessary for
> performance reasons, because nix-env won't like us to bring an additional
> 7000+ packages into scope. The big advantage of this change is that we can
> drop all that freaky name-mangling as package names no longer need to be
> unique in the global scope.
>
> - generic-builder.nix is a vastly simplified build function for Haskell
> packages. It's main feature is that it works with plain GHC -- meaning that
> ghc-wrapper is no longer required anywhere in Nixpkgs. Furthermore, builds
> are simple non-recursive attribute sets now; there is no more of that
> recursive tying-the-knot stuff the old 'cabal' function used to require.
>
>> From the user's point of view, there are two important changes:
>
> 1) No more ghc-wrapper, i.e. we no longer support non-deterministic setups
>where people install random packages into random places and expect them to
>know about each other. Instead, 'ghcWithPackages' is the tool of choice to
>create a deterministic Haskell environment. I plan to add support to
>cabal2nix for generating appropriate build instructions for use with
>nix-shell. It might also be nice to have a tool "nix-cabal-shall" that
>combines cabal2nix and nix-shell into one.
>
> 2) Haskell packages support 'deepOverride'. Suppose package 'foo' requires a
>non-default version of 'binary'. Then
>
> foo.deepOverride { binary = self.binary_0_4_0_1; };
>
>gives a derivation that uses this particular version to build 'foo' as well
>as all of foo's build inputs.
>
> The current state of the repository is "work in progress". I don't use this
> code for production yet, and neither should you. :-) I just wanted to share
> the
> effort to keep everyone in the loop and to encourage you to provide feedback.
>
> Best regards,
> Peter
>
>
> [1] https://github.com/peti/nixpkgs/tree/haskell-ng
> [2] https://github.com/NixOS/cabal2nix/tree/v2.x
> [3] http://hydra.nixos.org/jobset/nixpkgs/haskell-updates
>
> ___
> 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] Haskell NG
Hi guys,
in the spirit of "release early, release often", I'd like to inform everyone
with an interest in the Haskell part of Nixpkgs about the ongoing effort to
re-factor both cabal2nix and the code in Nixpkgs to achieve ...
1) support for all of Hackage,
2) death to the ghc-wrapper, and
3) easier and more reliably customization of the package set.
The Nixpkgs code lives in the "haskell-ng" branch of my Github clone [1]. In
that branch, Haskell related code is in pkgs/development/haskell-modules:
- hackage-packages.nix is generated automatically by the "hackage2nix" utility
from the "v2.x" branch of the cabal2nix repository [2]. The file defines
builds for the respective latest version of every Hackage package.
hackage2nix can include some older package versions, too, if necessary. (I
need to add code to hackage2nix to configure the choice of generated
packages conveniently.)
Note that a significant portion of those builds will not succeed because
they depend on system libraries that we don't have. Finding those broken
packages and fixing them (or adding meta.broken = true) will need a
community effort once this setup has stabilized. The Hydra job [3] builds
these packages to give us feedback on the state of affairs.
- default.nix imports the contents from hackage-packages.nix, applies (a
sequence of) configuration functions, and makes the result available as a
"haskellPackages" set suitable for nix-env and friends. The purpose of those
configurations is to adapt the package set for different compiler versions,
i.e. you can think of this file as a simplified version of what used to be
haskell-defaults.nix.
In the new setup, it will no longer be possible to install Haskell libraries
by name: you must access them by their attribute path. This is necessary for
performance reasons, because nix-env won't like us to bring an additional
7000+ packages into scope. The big advantage of this change is that we can
drop all that freaky name-mangling as package names no longer need to be
unique in the global scope.
- generic-builder.nix is a vastly simplified build function for Haskell
packages. It's main feature is that it works with plain GHC -- meaning that
ghc-wrapper is no longer required anywhere in Nixpkgs. Furthermore, builds
are simple non-recursive attribute sets now; there is no more of that
recursive tying-the-knot stuff the old 'cabal' function used to require.
>From the user's point of view, there are two important changes:
1) No more ghc-wrapper, i.e. we no longer support non-deterministic setups
where people install random packages into random places and expect them to
know about each other. Instead, 'ghcWithPackages' is the tool of choice to
create a deterministic Haskell environment. I plan to add support to
cabal2nix for generating appropriate build instructions for use with
nix-shell. It might also be nice to have a tool "nix-cabal-shall" that
combines cabal2nix and nix-shell into one.
2) Haskell packages support 'deepOverride'. Suppose package 'foo' requires a
non-default version of 'binary'. Then
foo.deepOverride { binary = self.binary_0_4_0_1; };
gives a derivation that uses this particular version to build 'foo' as well
as all of foo's build inputs.
The current state of the repository is "work in progress". I don't use this
code for production yet, and neither should you. :-) I just wanted to share the
effort to keep everyone in the loop and to encourage you to provide feedback.
Best regards,
Peter
[1] https://github.com/peti/nixpkgs/tree/haskell-ng
[2] https://github.com/NixOS/cabal2nix/tree/v2.x
[3] http://hydra.nixos.org/jobset/nixpkgs/haskell-updates
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] New darwin binary cache from Zalora
On 12 December 2014 at 05:18, Shea Levy wrote: > My employer, Zalora, has made our darwin binary cache > http://zalora-public-nix-cache.s3-website-ap-southeast-1.amazonaws.com > publicly accessible. It is populated from our private hydra, and currently > contains builds from git://github.com/joelteon/nixpkgs.git. Once darwin > builds are fixed on 10.10 on master, we will also be building that branch. > Please feel free to use this cache directly, or if desired to mirror it over > to cache.nixos.org. Yeah, this is fantastic. Should prevent some of the friction in getting some of my colleagues using nix. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
