Re: [Nix-dev] string vs path hell
OK, you are right. My code snippet really works fine. So I feel I must
post a part of my real code which still doesn't work for me. It is a
bit long, but maybe you will be able to help me find a mistake. Here
it is (below). This expression takes a set of paths to the executables
(exe // setuids) and builds the initrd image. Every attribute of (exe
// setuids) is either a string like [adduser =
"${busybox}/sbin/adduser";] or the result of mkDerivation producing
the single binary in it's $out.
Note the "dummy" expression. If I uncomment "builtins.trace dummy"
line, it will show me the expected result (string "dummy" for every
list item). But in the same time, "builtins.trace fn" shows that fn is
evaluated incorrectly. Every time it contains full Nix path
("/nix/strote/...", see example at the end of the letter) instead of
the filename part. It looks like 'splitString' doesn't recognize it's
argument as a string.
Please, comment!
Sergey
--
the code
...
img = makeInitrd {
compressor = "${gzip}/bin/gzip --fast";
contents = with all.ipkgs;
[{ symlink = "/init";
object = exe.init;
}
{ symlink = "/bin/sh";
object = exe.shell;
}] ++
map (v :
let
takeFileName = p : let
fl = lib.splitString "/" p;
in lib.last fl;
fn = takeFileName "${v}";
dummy = takeFileName "/a/string/encoded/path/dummy";
in
# builtins.trace fn # < see example output below
# builtins.trace dummy
{
symlink = "/bin/${fn}";
object = v;
}) (lib.attrValues (exe // setuids));
};
--
example output of "builtins.trace fn":
trace: /nix/store/sx19dvnv3wi2j8pvyra8npl9vdwdbmrk-busybox-1.21.1/sbin/addgroup
trace: /nix/store/sx19dvnv3wi2j8pvyra8npl9vdwdbmrk-busybox-1.21.1/sbin/adduser
trace: /nix/store/sx19dvnv3wi2j8pvyra8npl9vdwdbmrk-busybox-1.21.1/bin/false
trace: /nix/store/sx19dvnv3wi2j8pvyra8npl9vdwdbmrk-busybox-1.21.1/bin/true
trace: /nix/store/sx19dvnv3wi2j8pvyra8npl9vdwdbmrk-busybox-1.21.1/bin/awk
trace: /nix/store/sx19dvnv3wi2j8pvyra8npl9vdwdbmrk-busybox-1.21.1/bin/cat
trace: /nix/store/sx19dvnv3wi2j8pvyra8npl9vdwdbmrk-busybox-1.21.1/bin/chmod
trace: /nix/store/sx19dvnv3wi2j8pvyra8npl9vdwdbmrk-busybox-1.21.1/bin/chown
trace: /nix/store/sx19dvnv3wi2j8pvyra8npl9vdwdbmrk-busybox-1.21.1/bin/cp
trace: /nix/store/h8rs91fjivsh6wakmwmpkca31wfp38g0-msr-tools-1.3/bin/cpuid
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Fonts
>On 06/10/2014 02:29 AM, Daniel Bergey wrote: >> A few weeks back I struggled with fonts, asked some questions on IRC, >> and wrote up what I learned on the wiki: >> >> https://nixos.org/wiki/Fonts >> >> I should add some notes on packaging fonts there, too. >> >> I have no idea why Cantata and chromium aren't picking up fonts, though; >> I don't use either one. >> >> cheers, >> bergey >> > >Ah, I wasn't sure whether I should be adding things to fonts.fonts, >clearly I am. I should have a go and getting some extra fonts and >putting them there to see if that works. Thank you for putting up the >wiki page. > > >If you guys have some knowledge that's not searchable on the web at the >moment then please do make wiki pages! It's frustrating to get stuck on >something and then asking on IRC for hours, waiting for mailing list >replies, source diving, …, knowing that *someone* already knows! Well, not all knowledge is easily transferrable… Maybe the good habit to start would be blindly pasting to the wiki whatever conversation was deemed helpful by the asking person (because arguably the description in it is already somewhat useful and it can be edited later). ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] (Optionally) Build same package multiple ways on Hydra
>Consider the emacs-23 package as an example, it has an optional ‘gtk’
>argument we can set and is checked for null.
>
>So in a config one might have something like
>
> (emacs23.override { gtk = gtk3; })
>
>Unfortunately this means that one always has to build emacs themselves.
>It would be great if package maintainers could provide some default
>arguments with which Hydra will build.
>This is only an idea at this point but what do you think? Yes, there
>would be extra things to build by Hydra, can it afford it? I don't
>imagine the implementation would be extremely difficult but I don't have
>experience here.
If the option combination deserves its own Hydra job, it deserves
a top-level attribute in all-packages.nix (which is a one-line addition)
for ease of use with «nix-env -i».
If there are specific packages you think were missed by such treatment,
please provide a list/pull-request/link to pastebin… I personally don't
think we need a new mechanism here, but evaluating what was missed over
time is probably a good idea.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Fonts
On 06/10/2014 02:29 AM, Daniel Bergey wrote: > A few weeks back I struggled with fonts, asked some questions on IRC, > and wrote up what I learned on the wiki: > > https://nixos.org/wiki/Fonts > > I should add some notes on packaging fonts there, too. > > I have no idea why Cantata and chromium aren't picking up fonts, though; > I don't use either one. > > cheers, > bergey > Ah, I wasn't sure whether I should be adding things to fonts.fonts, clearly I am. I should have a go and getting some extra fonts and putting them there to see if that works. Thank you for putting up the wiki page. If you guys have some knowledge that's not searchable on the web at the moment then please do make wiki pages! It's frustrating to get stuck on something and then asking on IRC for hours, waiting for mailing list replies, source diving, …, knowing that *someone* already knows! > On 2014-06-09 at 06:30, Mateusz Kowalczyk wrote: >> Hi, >> >> In some applications (Cantata, chromium) I get squares instead of >> Japanese characters. In others (emacs, urxvt, firefox, uzbl (ugly)) I >> get actual characters. >> >> Does anyone know what I need to do to get Japanese to show up? In other >> distros I would normally install every font available ever, run >> fontconfig and hope for the best. >> >> Similarly, I was watching something with subtitles the other day and mpv >> was struggling to find some fonts even though I seemed to have them in >> ~/nix-profile/share/fonts/truetype . It might have needed some special >> variety however so don't hold me on this one. >> >> What's the procedure of installing fonts? In my configuration.nix I have >> >> fonts.enableCoreFonts = true; >> fonts.enableFontConfig = true; >> fonts.enableFontDir = true; >> fonts.enableGhostscriptFonts = true; >> >> I seem to get squares whether I have all of the above or none at all. >> >> I also was installing separate packages for fonts previously but it did >> not seem to matter. >> >> I tried to find some info online on this but I was only ever able to >> come across discussion whether unfree fonts should be included and >> nothing else. > -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] (Optionally) Build same package multiple ways on Hydra
Greetings,
Consider the emacs-23 package as an example, it has an optional ‘gtk’
argument we can set and is checked for null.
So in a config one might have something like
(emacs23.override { gtk = gtk3; })
Unfortunately this means that one always has to build emacs themselves.
It would be great if package maintainers could provide some default
arguments with which Hydra will build.
Continuing with the emacs23 example, both the GTK and no-GTK ways would
be common so perhaps we could state something like
meta {
hydraBuildWays = [ ({ gtk = gtk3; }) ({ gtk = null; }) ];
};
For packages with more options and asserts, it would still work:
meta {
hydraBuildWays = [ ({ withSDL = false; withQt4 = true; }) ({ withSDL =
false; withQt = true; }) ];
};
Consider a large package (say webkit) that someone took effort to
provide configurable flags for but you're never going to use them
because it's too much effort to build yourself.
This would then build both of the above packages at least twice (3 times
if the defaults up top are different) and whether the user wants emacs23
with or without GTK, they wouldn't have to build it themselves. It's a
bit like building the Haskell libraries with profiling, without
profiling, shared, …, except selectively.
The package maintainers would be the ones responsible for deciding
what's sensible: we don't want to build with every configuration of
boolean flags possible but only the common ones.
This is only an idea at this point but what do you think? Yes, there
would be extra things to build by Hydra, can it afford it? I don't
imagine the implementation would be extremely difficult but I don't have
experience here.
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Fonts
A few weeks back I struggled with fonts, asked some questions on IRC, and wrote up what I learned on the wiki: https://nixos.org/wiki/Fonts I should add some notes on packaging fonts there, too. I have no idea why Cantata and chromium aren't picking up fonts, though; I don't use either one. cheers, bergey On 2014-06-09 at 06:30, Mateusz Kowalczyk wrote: > Hi, > > In some applications (Cantata, chromium) I get squares instead of > Japanese characters. In others (emacs, urxvt, firefox, uzbl (ugly)) I > get actual characters. > > Does anyone know what I need to do to get Japanese to show up? In other > distros I would normally install every font available ever, run > fontconfig and hope for the best. > > Similarly, I was watching something with subtitles the other day and mpv > was struggling to find some fonts even though I seemed to have them in > ~/nix-profile/share/fonts/truetype . It might have needed some special > variety however so don't hold me on this one. > > What's the procedure of installing fonts? In my configuration.nix I have > > fonts.enableCoreFonts = true; > fonts.enableFontConfig = true; > fonts.enableFontDir = true; > fonts.enableGhostscriptFonts = true; > > I seem to get squares whether I have all of the above or none at all. > > I also was installing separate packages for fonts previously but it did > not seem to matter. > > I tried to find some info online on this but I was only ever able to > come across discussion whether unfree fonts should be included and > nothing else. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] string vs path hell
Yeah. nix-repl> lib.splitString "/" (toString ./some/vaild/path) [ "" "tmp" "some" "vaild" "path" ] -- Кирилл Елагин On Mon, Jun 9, 2014 at 5:13 PM, Luca Bruno wrote: > On 09/06/2014 15:01, Sergey Mironov wrote: > > 2014-06-09 16:34 GMT+04:00 Luca Bruno : > >> On 09/06/2014 14:32, Sergey Mironov wrote: > >>> lib.splitString "-" (toString (./some/valid/path)) > >> Perhaps you should split by "/" instead of "-"? > > Sorry, this is my copypaste mistake. I've meant another file name. The > > correct code is > > > > lib.splitString "/" (toString (./some/valid/path)) > > > > the problem does exist for me. > Works fine for me in nix-repl. > ___ > 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] Fonts
Hi, In some applications (Cantata, chromium) I get squares instead of Japanese characters. In others (emacs, urxvt, firefox, uzbl (ugly)) I get actual characters. Does anyone know what I need to do to get Japanese to show up? In other distros I would normally install every font available ever, run fontconfig and hope for the best. Similarly, I was watching something with subtitles the other day and mpv was struggling to find some fonts even though I seemed to have them in ~/nix-profile/share/fonts/truetype . It might have needed some special variety however so don't hold me on this one. What's the procedure of installing fonts? In my configuration.nix I have fonts.enableCoreFonts = true; fonts.enableFontConfig = true; fonts.enableFontDir = true; fonts.enableGhostscriptFonts = true; I seem to get squares whether I have all of the above or none at all. I also was installing separate packages for fonts previously but it did not seem to matter. I tried to find some info online on this but I was only ever able to come across discussion whether unfree fonts should be included and nothing else. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] multiple-ouputs branch
Hi. Currently noone worked on that branch, I believe, but Eelco (and also me) thinks that we should (attempt to) integrate it before 14.10. On 06/09/2014 06:18 PM, Mateusz Kowalczyk wrote: I think [1] is relevant. My personal take on this is that if we don't want to pull in Python with glib then the maintainer should offer a configurable flag in the glib package which when set, passes the appropriate flags to the build process. Think Gentoo USE flags. No, it's about something else. Especially for development/library packages, there's lots of stuff that isn't needed at runtime (headers, generators, etc.). These are supposed to be split, mostly automatically, into a separate output. Other distros often have *-dev variants of packages for the same purpose. Referred [1] is work on one particular package, but we want to (attempt to) do this for almost all packages by shared code, probably by stdenv modification. Vlada 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] multiple-ouputs branch
On 06/09/2014 05:35 PM, Pieter Noordhuis wrote: > Hi all, > > The nixpkgs repository has a branch called "multiple-outputs", with > the objective to split packages up into multiple ones. For example: > instead of having a single glib package, you would have one containing > run-time dependencies (shared libraries), and one you need to build > code that depends on it (header files, code generation, propagated > build inputs). This can be further extended into splitting out > documentation, or man pages specifically, and so forth. > > The reason for doing this is quite clear: cut down on the byte size of > a package's closure. Right now, a package that uses glib pulls in a > dependency on Python, because that happens to be used by a dbus code > generation utility that sits in the glib tree. Or, by compiling C++ > code and linking to libstdc++, you pull in a dependency on GCC as a > whole, instead of just GCC's shared libraries. > > My question: is the work in the multiple-outputs branch ongoing and > will it be merged to master one day? If not, what would be needed to > reboot an effort to split up packages? > > Cheers, > Pieter > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > I think [1] is relevant. My personal take on this is that if we don't want to pull in Python with glib then the maintainer should offer a configurable flag in the glib package which when set, passes the appropriate flags to the build process. Think Gentoo USE flags. The downside of this is that Hydra only ever builds with default flags. I admit that in the past I nearly made packages foo-Qt4, foo-Qt5 and foo-SDL just because of this. It'd be great if we could specify that Hydra should build the package in multiple configurations: if the user picks non-default flag then they have to build it themselves. I am not very well informed in the multiple outputs process being proposed however so don't pay me too much mind. [1]: https://github.com/NixOS/nixpkgs/pull/2063 -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Openssl and fast security updates
In the meanwhile I've merged system.replaceRuntimeDependencies. Here's some docs: https://nixos.org/wiki/Security_Updates On Fri, Jun 6, 2014 at 3:20 PM, Eelco Dolstra wrote: > Hi, > > On 06/06/14 13:57, Mathijs Kwik wrote: > > > So server systems need to start following a channel that does not run > > lengthy tests? > > The NixOS system tests actually aren't very lengthy (though they do suffer > from > non-deterministic failures). It's more the latency of having to wait for > 20,000 > package builds. > > Obviously, a better solution would be to: > > * Throw more hardware at the problem. > > * Start mirroring NARs to cache.nixos.org before the jobset eval has > finished > building. > > -- > Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- 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
Re: [Nix-dev] Extra manpage per service?
Hi Bjørn, that sounds amazing, I would love that. I wouldn't know where to start either, though. Greets, Ertugrul On Mon, 9 Jun 2014 12:02:35 +0200 Bjørn Forsman wrote: > I've been messing around with the nixos 'graphite' service lately. I > thought the module was a bit thin on the documentation side, so I > started to search online. I came across this graphite puppet > module[1], and what struck me is that there is no way that our current > "man configuration.nix" can provide that kind of detail for each > service, without being completely unreadable. > > So, how about we add a manpage for each service.? I think it > would be a good idea to still have everything in man > configuration.nix, although "man nixos-service-TAB-TAB" would probably > be just as easy to navigate. > > Does that sound like a good idea to you? Is it easy to do? I don't > know where to begin :-) -- Ertugrul Söylemez ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] multiple-ouputs branch
Hi all, The nixpkgs repository has a branch called "multiple-outputs", with the objective to split packages up into multiple ones. For example: instead of having a single glib package, you would have one containing run-time dependencies (shared libraries), and one you need to build code that depends on it (header files, code generation, propagated build inputs). This can be further extended into splitting out documentation, or man pages specifically, and so forth. The reason for doing this is quite clear: cut down on the byte size of a package's closure. Right now, a package that uses glib pulls in a dependency on Python, because that happens to be used by a dbus code generation utility that sits in the glib tree. Or, by compiling C++ code and linking to libstdc++, you pull in a dependency on GCC as a whole, instead of just GCC's shared libraries. My question: is the work in the multiple-outputs branch ongoing and will it be merged to master one day? If not, what would be needed to reboot an effort to split up packages? Cheers, Pieter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] string vs path hell
On 09/06/2014 15:01, Sergey Mironov wrote: > 2014-06-09 16:34 GMT+04:00 Luca Bruno : >> On 09/06/2014 14:32, Sergey Mironov wrote: >>> lib.splitString "-" (toString (./some/valid/path)) >> Perhaps you should split by "/" instead of "-"? > Sorry, this is my copypaste mistake. I've meant another file name. The > correct code is > > lib.splitString "/" (toString (./some/valid/path)) > > the problem does exist for me. Works fine for me in nix-repl. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] string vs path hell
2014-06-09 16:34 GMT+04:00 Luca Bruno : > On 09/06/2014 14:32, Sergey Mironov wrote: >> lib.splitString "-" (toString (./some/valid/path)) > Perhaps you should split by "/" instead of "-"? Sorry, this is my copypaste mistake. I've meant another file name. The correct code is lib.splitString "/" (toString (./some/valid/path)) the problem does exist for me. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] string vs path hell
On 09/06/2014 14:32, Sergey Mironov wrote: > lib.splitString "-" (toString (./some/valid/path)) Perhaps you should split by "/" instead of "-"? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] string vs path hell
Hi. I've faced a path/string problem. Looks like the code lib.splitString "-" (toString (./some/valid/path)) returns [ "./some/valid/path" ] instead of [ "some" "valid" "path" ] in other words, looks like paths are treated in a some special way. Is it a known issue? Regards, Sergey ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Extra manpage per service?
Hi all, I've been messing around with the nixos 'graphite' service lately. I thought the module was a bit thin on the documentation side, so I started to search online. I came across this graphite puppet module[1], and what struck me is that there is no way that our current "man configuration.nix" can provide that kind of detail for each service, without being completely unreadable. So, how about we add a manpage for each service.? I think it would be a good idea to still have everything in man configuration.nix, although "man nixos-service-TAB-TAB" would probably be just as easy to navigate. Does that sound like a good idea to you? Is it easy to do? I don't know where to begin :-) [1]: https://forge.puppetlabs.com/dwerder/graphite Best regards, Bjørn Forsman ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
