Seems cleaner.
Hm, there are also loadfiles in $out/share/doc/dbench/loadfiles/
(installed by the upstream build system), but there is no iscsi/
directory in there.
Since 74209a4 we have initial support for the "vboxsf" (VirtualBox
shared folder) file system support. This will be cherry-picked to
release-15.09 so we need to notice people about the change.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
There were quite a few configuration options which were tagged via
<literal/>, so in order to keep consistency with other docbook manuals
in the source tree, let's use <option/> here.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
A `thunar` plugin that adds archive manipulation features to
right click on file/directory menu. It can use either gnome or
kde archive managers. Detection of backend based on
`*.desktop` files mime types.
Should supercede non-functional pre-existing
`xfce.thunar_archive_plugin` (which for some
unknown reason is building the volume manager
plugin).
Also removed `xfce.thunar_archive_plugin` because
superceded.
Tests:
- When plugin package is installed, the supplementary
menu entries appear in thunar.
- Succesfully extracted an archive using backend
`file-roller` through thunar menu entry.
+ minor changes from vcunat, mainly meta.
- Use postPatch for patching, so don't need to manually override
configurePhase and installPhase.
- Add python to buildInputs, so fio2gnuplot gets patchShebangs'd.
- Add platforms, so it gets built by Hydra.
The patch only applies for Firefox versions between 37.0 and 40.1.
Because we're on version 41.0 the changes are already included upstream
and thus the patch doesn't apply and is even unnecessary.
As for version 38.3 for ESR, the patch doesn't apply as well if compiled
with enableGTK3. Of course, this is a bit unfortunate but I don't have
the time right now to properly rebase the patch on 38.3.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: devhell <"^"@regexmail.net>
I'm not quite sure why the official Hydra gets a kernel panic in one of
two VMs using the exact same kernels:
https://hydra.nixos.org/build/26339384
Because the kernel panic happens before stage 1, let's wait for the
first VM to boot up and after the bootup is done, start the second one
in hope that it won't trigger the panic.
Oddly enough, whenever I run the test on my own Hydra and on my local
machines, I don't get anything like that.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This update was generated by hackage2nix v20150922-6-g5d5ccfe using the following inputs:
- Nixpkgs: eaa43c65b3
- Hackage: c048a402d3
- LTS Haskell: c7012a704b
- Stackage Nightly: a74568b554
