Re: [Nix-dev] [***SPAM***] A bunch of patches to nixpkgs and questions
Ah, looks like Peter beat me too it. Peter, have you committed/opened pull requests for all of Jan's patches or are there some more that need looking over? ~Shea On Jun 26, 2012, at 11:09 PM, Shea Levy s...@shealevy.com wrote: Anyway, I don't have any meaningful change history. I can make one up if you insist, but this could get another year or two. I'm not hurrying anyone, but if you merge the current set of patches in sometime I promise to carefully fake meaningful history for the next one. :) OK, fair enough. No need to fake up a commit history for the other changes that you've already made, but for future changes nice granular commits would be appreciated. If no one else has merged this by next week, I'll take a look at the patches and respond then (I'm on vacation now :)). ~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] [***SPAM***] A bunch of patches to nixpkgs and questions
Hello.
I've made a bunch of changes to nixpkgs that I would like to share.
* new-and-fixes.patch
* adds
* libraries
* gconfmm -- This
* gtkglextmm -- and this are not used by any package that I'm ready to
share. They are for lintesia game that doesn't run nicely for me yet. Nice to
have anyway.
* gtkdatabox -- Used by klavaro.
* applications/games
* mirage -- Pretty slow, but small and simple (!) image viewer that plays
animated gifs (!).
* mcomix -- Like comix, but better; builtin library feature is turned
off, because I don't use it (slow) and too lazy to add a on/off flag.
* transmission-remote-gtk -- Self descriptive.
* remmina -- The only VNC client I know that allows sending special keys
(e.g. bound by local window manager) to the remote machine (has a special GUI
button that grabs all the keys).
* klavaro -- Touch typing tutor that doesn't depend on a fixed keyboard
layout, i.e. it's very helpful if you want to learn to touch type with your own
original (twisted) keyboard layout.
* kernel
* linux-3.2-xen -- Self descriptive; I would also suggest to generate
-xen versions for all the kernels automatically.
* patches and fixes
* kernel
* no-xsave.patch -- (xen needs this) fetchurl for no-xsave.patch is dead,
I found the original version, tested it to work and placed there. Would be nice
if someone who has the previous version could check that it's the same patch
(hashes are not equal probably because it had comments at the top).
* applications
* freerdp -- I have no idea why the hash has changed without version
bumping. This bugs me, can anyone check what have changed? Anyway, remmina
needs this.
* firefox-12.0 -- fetchurl is dead, now fetches from archive mirror.
* others
* SDL_net -- include header fix.
* ati-drivers -- fetchurl fix.
* libdrm -- add support for radeon experimental api.
* libvdpau, ffmpeg -- prettify libvdpau arguments, ffmpeg support for
libvdpau acceleration.
* I've placed all the new packages at the end of top-level.nix to prevent
local merge conflicts (I have no idea how items are sorted there anyway).
* version-bump-tested-to-work.patch
* wine -- 1.3.32 -- 1.5.5, winetricks complains that 1.3.* up to .39 or
something is buggy and should be updated.
* psmisc -- 22.13 -- 22.19, 22.13 is so out of date that it was deleted
from sourceforge.
* version-bump-xen-fail.patch -- 4.0.3 -- 4.1.2, while linux-3.2-xen works
fine (for dom0) xend from 4.1.2 doesn't want to start with the current
nixos-generated upstart rules. It fails somewhere, upstart job hangs in
starting state, system doesn't reboot/halt nicely because of that. I have no
clear idea why this happens. Would be nice if someone could fix that.
* compilers.patch -- allows to compile /dev/null, sounds crazy, but this
feature is used in some configure scripts (e.g. xbmc). This patch causes almost
complete rebuild of nixpkgs and is not needed by any current package, but it
would be if I make xbmc to work. By the way, why the same file is duplicated 4
times?
Now, the questions:
* Is there a nice way to download a file, compute a hash, place the hash into
the fetchurl nix-expression and to build it without redownloading the file
again?
* I found a pretty funny contradiction that makes me belive that some of the
user dotfiles should be bulit with nix. remmina wouldn't start without a gtk
icon theme avalible. Theme could be changed and/or installed (into $HOME (!))
by the user. I.e., you could not depend on a fixed (or even avaliable, if you
don't bulid user's dotfiles with nix) theme in a nix expression, yet you depend
on it anyway. Is there a solution?
* I saw something like nix-env -iA haskellPackages.xmonad somewhere, but it
fails for me with
error: attribute `haskellPackages' in selection path `haskellPackages' not
found
nix-build -A haskellPackages.xmonad works (I have default.nix in $HOME
symlinked to nixpkgs). Why is that?
Best regards,
Jan
Index: pkgs/build-support/gcc-wrapper/utils.sh
===
--- pkgs/build-support/gcc-wrapper/utils.sh (revision 34573)
+++ pkgs/build-support/gcc-wrapper/utils.sh (working copy)
@@ -17,6 +17,7 @@
# Otherwise, the path should refer to the store or some temporary
# directory (including the build directory).
test \
+$p != /dev/null -a \
${p:0:${#NIX_STORE}} != $NIX_STORE -a \
${p:0:4} != /tmp -a \
${p:0:${#NIX_BUILD_TOP}} != $NIX_BUILD_TOP
Index: pkgs/build-support/gcc-upc-wrapper/utils.sh
===
--- pkgs/build-support/gcc-upc-wrapper/utils.sh (revision 34573)
+++ pkgs/build-support/gcc-upc-wrapper/utils.sh (working copy)
@@ -17,6 +17,7 @@
# Otherwise, the path should refer to the store or some temporary
# directory (including the build
Re: [Nix-dev] [***SPAM***] A bunch of patches to nixpkgs and questions
Hi Jan, On Jun 26, 2012, at 8:52 AM, Jan Malakhovski o...@oxij.org wrote: Hello. I've made a bunch of changes to nixpkgs that I would like to share. Thanks for contributing! * new-and-fixes.patch * adds * libraries * gconfmm -- This * gtkglextmm -- and this are not used by any package that I'm ready to share. They are for lintesia game that doesn't run nicely for me yet. Nice to have anyway. * gtkdatabox -- Used by klavaro. * applications/games * mirage -- Pretty slow, but small and simple (!) image viewer that plays animated gifs (!). * mcomix -- Like comix, but better; builtin library feature is turned off, because I don't use it (slow) and too lazy to add a on/off flag. * transmission-remote-gtk -- Self descriptive. * remmina -- The only VNC client I know that allows sending special keys (e.g. bound by local window manager) to the remote machine (has a special GUI button that grabs all the keys). * klavaro -- Touch typing tutor that doesn't depend on a fixed keyboard layout, i.e. it's very helpful if you want to learn to touch type with your own original (twisted) keyboard layout. * kernel * linux-3.2-xen -- Self descriptive; I would also suggest to generate -xen versions for all the kernels automatically. * patches and fixes * kernel * no-xsave.patch -- (xen needs this) fetchurl for no-xsave.patch is dead, I found the original version, tested it to work and placed there. Would be nice if someone who has the previous version could check that it's the same patch (hashes are not equal probably because it had comments at the top). * applications * freerdp -- I have no idea why the hash has changed without version bumping. This bugs me, can anyone check what have changed? Anyway, remmina needs this. * firefox-12.0 -- fetchurl is dead, now fetches from archive mirror. * others * SDL_net -- include header fix. * ati-drivers -- fetchurl fix. * libdrm -- add support for radeon experimental api. * libvdpau, ffmpeg -- prettify libvdpau arguments, ffmpeg support for libvdpau acceleration. * I've placed all the new packages at the end of top-level.nix to prevent local merge conflicts (I have no idea how items are sorted there anyway). * version-bump-tested-to-work.patch * wine -- 1.3.32 -- 1.5.5, winetricks complains that 1.3.* up to .39 or something is buggy and should be updated. * psmisc -- 22.13 -- 22.19, 22.13 is so out of date that it was deleted from sourceforge. * version-bump-xen-fail.patch -- 4.0.3 -- 4.1.2, while linux-3.2-xen works fine (for dom0) xend from 4.1.2 doesn't want to start with the current nixos-generated upstart rules. It fails somewhere, upstart job hangs in starting state, system doesn't reboot/halt nicely because of that. I have no clear idea why this happens. Would be nice if someone could fix that. * compilers.patch -- allows to compile /dev/null, sounds crazy, but this feature is used in some configure scripts (e.g. xbmc). This patch causes almost complete rebuild of nixpkgs and is not needed by any current package, but it would be if I make xbmc to work. By the way, why the same file is duplicated 4 times? Wow, this is a lot of changes. Would it be possible for you to make them available as git trees with decent commit history that can be pulled from, or better open up some pull requests on github? If not I'll take a look through the patches later, but it will be a lot easier for me to see them that way. Now, the questions: * Is there a nice way to download a file, compute a hash, place the hash into the fetchurl nix-expression and to build it without redownloading the file again? nix-prefetch-url does what you're looking for. * I found a pretty funny contradiction that makes me belive that some of the user dotfiles should be bulit with nix. remmina wouldn't start without a gtk icon theme avalible. Theme could be changed and/or installed (into $HOME (!)) by the user. I.e., you could not depend on a fixed (or even avaliable, if you don't bulid user's dotfiles with nix) theme in a nix expression, yet you depend on it anyway. Is there a solution? * I saw something like nix-env -iA haskellPackages.xmonad somewhere, but it fails for me with error: attribute `haskellPackages' in selection path `haskellPackages' not found nix-build -A haskellPackages.xmonad works (I have default.nix in $HOME symlinked to nixpkgs). Why is that? My guess is you need something like nix-env -iA nixpkgs_unstable.haskellPackages.xmonad, if you've set up the nixpkgs channel. nix-build by default looks in your current directory, but nix-env looks in ~/.nix-defexpr unless you pass it a path with -f. Best regards, Jan compilers.patch new-and-fixes.patch version-bump-tested-to-work.patch version-bump-xen-fail.patch ___
Re: [Nix-dev] [***SPAM***] A bunch of patches to nixpkgs and questions
2012/6/26 Jan Malakhovski o...@oxij.org I'm kind of confused with gist vs. pull request controversy. I did carefully read the thread about moving to github, but still don't get this nonlinear history/merge problem. No offense, but I feel that gists somehow diminish contributions (or maybe I don't understand the idea behind them). By the way, https://gist.github.com/2995911 says Sorry, this Gist contains too many files. Delete some to view it. (Consider creating a GitHub repository instead!). Just to note: I don't get this gist idea either. Gist is, you know, slightly enhanced pastebin, and using it for collecting contributions looks weird. P.S. The question that doesn't leave my mind alone: How should I sort the items in top-level/all-packages.nix? At first I thought they are placed lexicographically, but they are not. https://github.com/NixOS/nixpkgs/pull/19#discussion_r1037351 -- Кирилл Елагин ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [***SPAM***] A bunch of patches to nixpkgs and questions
Excerpts from Jan Malakhovski's message of Tue Jun 26 18:56:26 +0200 2012: I'm kind of confused with gist vs. pull request controversy. I did carefully read the thread about moving to github, but still don't get this nonlinear history/merge problem. Well - the gist was meant to also take care about your dirty things while pull requests should be clean patches ready to merge with upstream. Its about a central place we can share code - and look for code if something doesn't work suspecting somebody might already have found a solution. No offense, but I feel that gists somehow diminish contributions (or maybe I don't understand the idea behind them). Some patches take time - take many iterations - and are controversy. Eg in your case if I find a small thing to fix I could just fix it without asking anybody creating a new commit. By the way, https://gist.github.com/2995911 says Sorry, this Gist contains too many files. Delete some to view it. (Consider creating a GitHub repository instead!). Yes - but the git access (cloning / pushing) should still work. I know that the gist git interface is lacking features (no commenting etc). But its a place people can push their current versions of patches while waiting for feedback on the mailinglist - so things don't get losts. Well - important patches should still be sent to the mailinglist. P.S. The question that doesn't leave my mind alone: How should I sort the items in top-level/all-packages.nix? If you're using Vim get github.com/MarcWeber - vim-addon-nix which introduces folding based on ### markers. If not just grep for those - they split the file into pieces by category. Within those categories all derivations having indenting level of two spaces should be ordered lexicographically. There are some exceptions - sometimes it makes sense to put a related derivation nearby the other one so that it doesn't get missed when patching etc. I mostly search with regerx ^spacespaceclojure for example which is almost always a fast match. I even created a mapping in Vim.. There is/was somewhere a document helping you to find the right location. But current discussion about whether there should be a top level fonts. attribute show that we don't know either in all cases :( Thus do whatever makes sense applies very often. In fact there are battles ( :) ) going on about how much should be packaged manually or automatically (eg hack-nix vs the haskell-packages.nix implementations) same happens with ruby packages (my ruby overlay). That's one of the reasons why I feel its too early for too many policies. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [***SPAM***] A bunch of patches to nixpkgs and questions
Anyway, I don't have any meaningful change history. I can make one up if you insist, but this could get another year or two. I'm not hurrying anyone, but if you merge the current set of patches in sometime I promise to carefully fake meaningful history for the next one. :) OK, fair enough. No need to fake up a commit history for the other changes that you've already made, but for future changes nice granular commits would be appreciated. If no one else has merged this by next week, I'll take a look at the patches and respond then (I'm on vacation now :)). ~Shea___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
