| Commit message (Collapse) | Author | Age |
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=30240
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=30239
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=30237
|
|
|
|
|
|
|
|
| |
drbdsetup. Otherwise "drbdadm primary --force" won't work as
expected (the kernel will say "State change failed: Need access to
UpToDate data").
svn path=/nixpkgs/trunk/; revision=30195
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=30194
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=30173
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=30172
|
|
|
|
|
|
|
| |
* Fixed the "docbook2man --sgml" command in docbook2x.
* Fixed the module-init-tools manual pages.
svn path=/nixpkgs/trunk/; revision=30165
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=30163
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=30093
|
|
|
|
|
|
| |
use kernel mirror
svn path=/nixpkgs/trunk/; revision=30089
|
|
|
|
|
|
| |
for example.
svn path=/nixpkgs/trunk/; revision=30053
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=30036
|
|
|
|
|
|
|
| |
the Debian SVN tree had a version number attached that had to be
stripped out.)
svn path=/nixpkgs/trunk/; revision=30035
|
|
|
|
|
|
| |
checksum errors in tarball
svn path=/nixpkgs/trunk/; revision=30016
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=30011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
system
Replaced use of fetchsvn with fetchurl. Please note that machines behind a
company firewall usually cannot access svn://-style URLs, which means that
nixos-rebuild is going to fail. HTTP works fine, though.
The URL I used to download the tar.gz archive is probably not stable, or
rather, the tar.gz archive generated by Gitweb at that URL might have a
different checksum every time it's generated. I'm not sure what else to do,
though. Could a kind firmware expert please improve the situation further?
Also, I wonder what is the purpose of the sed expression in the command
cp $i $out/brcm/$(echo $i | sed 's/\(.*\.fw\).*/\1/')
...? The downloaded directory doesn't seem to contain any files that would
match that expression?
svn path=/nixpkgs/trunk/; revision=30010
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=30009
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=30008
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=30007
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=30002
|
|
|
|
|
|
|
|
|
|
| |
and lower quality than regular drivers. However, there are a lot of drivers
for wireless cards that we really need to have. And it doesn't really hurt
to have these drivers if you don't need them.
* Enable the Radeon KMS option. This shouldn't be a problem since the X driver
supports KMS (I think).
svn path=/nixpkgs/trunk/; revision=29994
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29993
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29978
|
|
|
|
|
|
| |
players.
svn path=/nixpkgs/trunk/; revision=29952
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29918
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29828
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29822
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29821
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29811
|
|
|
|
|
|
| |
INOTIFY_USER exists since 2.6.18
svn path=/nixpkgs/trunk/; revision=29810
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29807
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29806
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29779
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29778
|
|
|
|
|
|
| |
file.
svn path=/nixpkgs/trunk/; revision=29711
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29695
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29694
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29688
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29684
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29678
|
|
|
|
|
|
| |
I really should have done these changes in a topic branch, sorry
svn path=/nixpkgs/trunk/; revision=29567
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29564
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "unset MODULE_DIR" trick was enough to get Linux 3.x kernels compiling, but it was definitely the Wrong Thing
We NEED MODULE_DIR set so that depmod can store the right dependencies during the build. The REAL problem with the
3.x kernels was two-fold: Our module-init-tools was so old that the kernel build needed to introduce a hack when
calling depmod (involving creating a symlink prepending 99.98 to the version number), and the depmod wrapper was
moved out of the Makefile into scripts/depmod.sh, so our substituteInPlace to get rid of '-b $(INSTALL_MOD_PATH)' in
the Makefile was a noop and INSTALL_MOD_PATH was still being passed to depmod. This is now fixed and modprobe can
successfully find dependencies using the modules.dep created during install
svn path=/nixpkgs/trunk/; revision=29559
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29556
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29555
|
|
|
|
|
|
| |
sharing over Virtio - I/O virtualization framework)
svn path=/nixpkgs/trunk/; revision=29551
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29539
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29536
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=29535
|