The per-version `default.nix`es just fill in default arguments. It is
much more useful to have the `.override` from the inner `callPackage`,
for finer control. Converting the outer `callPackage` to a plain import
makes the inner one the only one, revealing its `.override`.
This tool is necessary in order to update the firmware of the secoder.
The reason I've added this to a separate output "tools" is because it
clearly is not relevant for the PCSC driver itself and it's also very
rarely needed.
I've also verified wether the closure of the PCSC plugin env still only
contains the main output and that's the case.
There are also other tools - cjBingoTest and cjgeldkarte, where the
former doesn't compile due to cjeca32.h not being found and cjgeldkarte,
which does compile but tries to dlopen() the library and subsequently
fails.
Both of these tools however look like they're just performing tests and
are not very useful outside of development, so I opted to not include
them.
Signed-off-by: aszlig <aszlig@nix.build>
3.99.5_SP12:
* Add support for cyberJack one MF
3.99.5_SP11:
* Add support for cyberJack one
3.99.5_SP10:
* Add support for SHUReader and SISReader
* Update to the Reiner-SCT repository rev cyberJack@1305
Signed-off-by: aszlig <aszlig@nix.build>
/cc @Ericson2314
PR was https://github.com/NixOS/nixpkgs/pull/46857
This line broke MacOS cross compilation. paxctl cannot be built on
macOS. Maybe it can be fixed, but no reason to break things
unnecessarily.
Regardless, you definitely need to be more careful about backporting.
I think it’s fine to move fast and break things on master but
with release-18.09 we should be more careful. Something like more
automated testing for cross compilation would also be
helpful (hopefully even making it block).
(cherry picked from commit f9c4075873cb56464126f993d22a1a72f7cfac45)
/cc @Ericson2314
This line broke MacOS cross compilation. paxctl cannot be built on
macOS. Maybe it can be fixed, but no reason to break things
unnecessarily.
Regardless, you definitely need to be more careful about backporting.
I think it’s fine to move fast and break things on master but
with release-18.09 we should be more careful. Something like more
automated testing for cross compilation would also be
helpful (hopefully even making it block).
Thanks to @symphorien for this work, which apart from the update itself
includes a few more fixes and cleanups.
I've tested building and running the upgraded Paperwork and while I
haven't done extensive testing on every little feature it seems to work
so far.
The changes also include an addition to fetchFromGitLab, which allows to
specify a group.
Merges: #46487
Similar to some other builds, sdl-config gets stuck and times out.
checking for sdl-config... /nix/store/q2hm1ka0qxs2gv5bmrxj7j80lygk4b5z-SDL-1.2.15-dev/bin/sdl-config
building of '/nix/store/m2d7v0n5hd2498vfxp18i37p7r1lf76p-freedroidrpg-0.16.1' timed out after 7200 seconds of silence
/cc ZHF #45961
Doesn't build on darwin and probably other platforms.
GsWidget.H:26:3: error: 'Atom' does not name a type; did you mean 'tm'?
Atom atoms[5];
^~~~
tm
GsWidget.cxx: In member function 'void GsWidget::setProps()':
GsWidget.cxx:47:2: error: 'atoms' was not declared in this scope
atoms[0] = XInternAtom(fl_display,"GHOSTVIEW" , false);
^~~~~
/cc ZHF #45961
Undefined symbols for architecture x86_64:
"_MPCreateSemaphore", referenced from:
FX::FXSemaphore::FXSemaphore(int) in FXThread.o
FX::FXSemaphore::FXSemaphore(int) in FXThread.o
"_MPDeleteSemaphore", referenced from:
FX::FXSemaphore::~FXSemaphore() in FXThread.o
FX::FXSemaphore::~FXSemaphore() in FXThread.o
"_MPSignalSemaphore", referenced from:
FX::FXSemaphore::post() in FXThread.o
"_MPWaitOnSemaphore", referenced from:
FX::FXSemaphore::wait() in FXThread.o
FX::FXSemaphore::trywait() in FXThread.o
ld: symbol(s) not found for architecture x86_64
/cc ZHF #45961
* needs at least qtgraphicaleffects not mentioned in docs
* doesn't want to use our libqmatrixclient, so let it use bundled
* took a few runs (or perhaps just patience with one) to populate,
when my profile icon appeared it seemed ready-- then click it
to see list of rooms and such.
* podofo: fix library linkage on Darwin
Because the library is not yet installed when the tools are build, it does not contain its final store path as its install name. Linking the tools picks up this incorrect install name and needs to be fixed after installing.
The patchPhase wasn't being applied at all.
This patch re-enables that and also re-thinks the setting that we want
to have. Turning off the auto-update is more accurate and doesn't lose
information like it did before.
- build fails with qt511 and qt59
(it used to build with qt510 which is not available anymore)
- no nixpkgs maintainer
- upstream repo looks inactive, last commit a year ago
- New dependency on 'getconf' binary for
3aa619e9ef/src/vm_memory_monitor.erl (L448)
- New dependency on 'socat' for systemd notifications
4a3ee3a336/src/rabbit.erl (L361)
- elixir_1_6 for a new 'rabbitmqctl' tool
- Replace patching with providing custom PATH, as we already have some
other things here
- Renamed package in all-packages.nix from a legacy spelling
This reverts commit f777d2b719.
cc #34409
This breaks evaluation of the tested job:
attribute 'diskInterface' missing, at /nix/store/5k9kk52bv6zsvsyyvpxhm8xmwyn2yjvx-source/pkgs/build-support/vm/default.nix:316:24
Only apply w/musl since while it's wrong everywhere it apparently
hasn't broken things entirely w/glibc so keep things as they were.
Patch regenerated from original so that it applies
which isn't saying much since it's simple :).
Source:
https://patchwork.ozlabs.org/patch/154298/
IRC chat on #musl with Rich and others endorses this,
at least at the conceptual level of no shared library
should be using initial-exec TLS.
Fixes various uses of libgomp that previously crashed (before 1.1.20)
or encounter errors (post-1.1.20), such as pythonPackages.cython .
This includes the initialy commit was done by @Mic92 plus a few fixes
from my side. So essentially this avoids patching statically linked
executables and also speeds up searching for ELF files altogether.
I've tested this by comparing the outputs of all the derivations which
make use of this hook using the following Nix expression:
let
getPackagesForRev = rev: with import (builtins.fetchGit {
url = ./.;
inherit rev;
}) { config.allowUnfree = true; }; [
cups-kyodialog3 elasticsearch franz gurobi javacard-devkit
masterpdfeditor maxx oracle-instantclient powershell reaper
teamviewer unixODBCDrivers.msodbcsql17 virtlyst wavebox zoom-us
];
pkgs = import <nixpkgs> {};
baseRev = "ef764eb0d8314b81a012dae04642b4766199956d";
in pkgs.runCommand "diff-contents" {
chset = pkgs.lib.zipListsWith (old: new: pkgs.runCommand "diff" {
inherit old new;
nativeBuildInputs = [ pkgs.nukeReferences ];
} ''
mkdir -p "''${NIX_STORE#/}"
cp --no-preserve=all -r "$old" "''${NIX_STORE#/}"
cp --no-preserve=all -r "$new" "''${NIX_STORE#/}"
find "''${old#/}" "''${new#/}" \
\( -type f -exec nuke-refs {} + \) -o \( -type l -delete \)
mkdir "$out"
echo "$old" > "$out/old-path"
echo "$new" > "$out/new-path"
diff -Nur "''${old#/}" "''${new#/}" > "$out/diff" || :
'') (getPackagesForRev baseRev) (getPackagesForRev "");
} ''
err=0
for c in $chset; do
if [ -s "$c/diff" ]; then
echo "$(< "$c/old-path") -> $(< "$c/new-path")" \
"differs, report: $c/diff" >&2
err=1
fi
done
[ $err -eq 0 ] && touch "$out"
''
With these changes there is only one derivation which has altered
contents, which is "franz". However the reason why it has differing
contents is not directly because of the autoPatchelfHook changes, but
because the "env-vars" file from the builder is in
"$out/opt/franz/env-vars" (Cc: @gnidorah) and we now have different
contents for NIX_CFLAGS_COMPILE and other environment variables.
I also tested this against a random static binary and the hook no longer
tries to patch it.
Merges: #47222
The unfree variant of elasticsearch uses autoPatchelfHook and since we
removed the dependency on file for the hook itself in
58a97dfb49 we no longer have zlib
propagated.
So we need to explicitly state that dependency here.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @apeschar, @basvandijk
The "maxx" package recursively runs isExecutable on a bunch of files and
since the change to use "readelf" instead of "file" a lot of errors like
this one are printed during build:
readelf: Error: Not an ELF file - it has the wrong magic bytes at the
start
While the isExecutable was never meant to be used outside of the
autoPatchelfHook, it's still a good idea to silence the errors because
whenever readelf fails, it clearly indicates that the file in question
is not a valid ELF file.
Signed-off-by: aszlig <aszlig@nix.build>
If the ELF file is not an executable, we do not get a PT_INTERP section,
because after all, it's a *shared* library.
So instead of checking for PT_INTERP (to avoid statically linked
executables) for all ELF files, we add another check to see if it's an
executable and *only* skip it when it is and there's no PT_INTERP.
Signed-off-by: aszlig <aszlig@nix.build>
Fixes a critical issue with macOS
[NEWS](https://bitbucket.org/mituharu/emacs-mac/raw/master/NEWS-mac)
* emacs-26.1-mac-7.2 (2018-09-09)
** Fixed bugs
*** Buffer contents are not displayed on macOS 10.14.
This is mainly because now NSViews are backed by Core Animation Layer
(layer-backed) by default and non-deferred drawing into views no
longer works. Instead of switching to deferred drawing (i.e., draw
only inside -[NSView drawRect:]), we draw into our own backing bitmap
in a non-deferred way as before, and update the view contents with the
resulting image via -[NSView updateLayer]. This "application-side
double buffering" is also available on OS X 10.8 - macOS 10.13 if you
set the frame parameter `inhibit-double-buffering' to nil when
creating a frame. Just like on macOS 10.14, such a frame does not do
LCD smoothing.
*** Screenshot grabbed via Services is displayed in wrong size when we
have display mirroring between Retina and non-Retina displays.
*** Cursor movement just after frame resize sometimes leaves garbage.
*** Crash by the Fall_threads call from the GUI thread at the select
emulation when there are multiple Lisp threads.
*** Info title has ASCII underline unlike other window systems.
*** Vertical scroll bar is created as horizontal if frame font height
is short.
** Improvements
*** macOS 10.14 adds property :appearance to (mac-application-state).
The value may be "NSAppearanceNameAqua" or "NSAppearanceNameDarkAqua".
*** Add new color format "mac:COLOR-LIST-NAME:COLOR-NAME" and
"mac:COLOR-NAME" (shorthand for "mac:System:COLOR-NAME"). The actual
color may be different depending on the global appearance setting on
macOS 10.14. For example, "mac:textColor" is black on the Light Mode
but is white on the Dark Mode.
*** Default frame colors respect appearance setting on macOS 10.14.
Now the default frame foreground/background color is
"mac:textColor"/"mac:textBackgroundColor", respectively. Changes of
the system setting of the global appearance are dynamically reflected.
*** New function `mac-color-list-alist' to get the available
combinations of COLOR-LIST-NAMEs and COLOR-NAMEs. Note that this
value is dependent on user environment and OS version. Also, some
combinations may represent image patterns rather than colors. For the
former cases, `(color-values "mac:COLOR-LIST-NAME:COLOR-NAME")'
returns nil.
The compilers themselves can pull them from `bootPkgs`, where they
should always come from anyways. This enforces that, simplifies that
code, and allows use to avoid more `rec { ... }` too.
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/libtins/versions.
These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 4.0 with grep in /nix/store/izz1bkj35g5bb6kvqa5kqgb376xhardg-libtins-4.0
- found 4.0 in filename of file in /nix/store/izz1bkj35g5bb6kvqa5kqgb376xhardg-libtins-4.0
- directory tree listing: https://gist.github.com/26990576c9472ca38b4d21613157856b
The `overrideScope` bound by `makeScope` (via special `callPackage`)
took an override in the form `super: self { … }`. But this is
dangerously close to the `self: super { … }` form used by *everything*
else, even other definitions of `overrideScope`! Since that
implementation did not even share any code either until I changed it
recently in 3cf43547f4, this inconsistency
is almost certainly an oversight and not intentional.
Unfortunately, just as the inconstency is hard to debug if one just
assumes the conventional order, any sudden fix would break existing
overrides in the same hard-to-debug way. So instead of changing the
definition a new `overrideScope'` with the conventional order is added,
and old `overrideScope` deprecated with a warning saying to use
`overrideScope'` instead. That will hopefully get people to stop using
`overrideScope`, freeing our hand to change or remove it in the future.
