Undefined symbols for architecture x86_64:
"_NSDefaultRunLoopMode", referenced from:
_X11ApplicationMain in libXquartz.a(X11Application.o)
"_OBJC_CLASS_$_NSArray", referenced from:
objc-class-ref in libXquartz.a(X11Application.o)
objc-class-ref in libXquartz.a(X11Controller.o)
objc-class-ref in libxpbproxy.a(x-selection.o)
"_OBJC_CLASS_$_NSData", referenced from:
objc-class-ref in libxpbproxy.a(x-selection.o)
"_OBJC_CLASS_$_NSDictionary", referenced from:
objc-class-ref in libxpbproxy.a(x-selection.o)
"_OBJC_CLASS_$_NSMutableArray", referenced from:
objc-class-ref in libXquartz.a(X11Application.o)
objc-class-ref in libXquartz.a(X11Controller.o)
"_OBJC_CLASS_$_NSMutableDictionary", referenced from:
objc-class-ref in libXquartz.a(X11Application.o)
"_OBJC_CLASS_$_NSRunLoop", referenced from:
objc-class-ref in libXquartz.a(X11Application.o)
"_OBJC_CLASS_$_NSURL", referenced from:
objc-class-ref in libXquartz.a(X11Application.o)
"_OBJC_EHTYPE_$_NSException", referenced from:
GCC_except_table29 in libxpbproxy.a(x-selection.o)
ld: symbol(s) not found for architecture x86_64
Undefined symbols for architecture x86_64:
"_NSDefaultRunLoopMode", referenced from:
_X11ApplicationMain in libXquartz.a(X11Application.o)
"_OBJC_CLASS_$_NSArray", referenced from:
objc-class-ref in libXquartz.a(X11Application.o)
objc-class-ref in libXquartz.a(X11Controller.o)
objc-class-ref in libxpbproxy.a(x-selection.o)
"_OBJC_CLASS_$_NSData", referenced from:
objc-class-ref in libxpbproxy.a(x-selection.o)
"_OBJC_CLASS_$_NSDictionary", referenced from:
objc-class-ref in libxpbproxy.a(x-selection.o)
"_OBJC_CLASS_$_NSMutableArray", referenced from:
objc-class-ref in libXquartz.a(X11Application.o)
objc-class-ref in libXquartz.a(X11Controller.o)
"_OBJC_CLASS_$_NSMutableDictionary", referenced from:
objc-class-ref in libXquartz.a(X11Application.o)
"_OBJC_CLASS_$_NSRunLoop", referenced from:
objc-class-ref in libXquartz.a(X11Application.o)
"_OBJC_CLASS_$_NSURL", referenced from:
objc-class-ref in libXquartz.a(X11Application.o)
"_OBJC_EHTYPE_$_NSException", referenced from:
GCC_except_table29 in libxpbproxy.a(x-selection.o)
ld: symbol(s) not found for architecture x86_64
Undefined symbols for architecture x86_64:
"_CFNotificationCenterAddObserver", referenced from:
_main in main.o
"_CFNotificationCenterGetDistributedCenter", referenced from:
_main in main.o
"_OBJC_CLASS_$_NSTimer", referenced from:
objc-class-ref in main.o
objc-class-ref in x-screen.o
"_OBJC_EHTYPE_$_NSException", referenced from:
GCC_except_table25 in main.o
ld: symbol(s) not found for architecture x86_64
Undefined symbols for architecture x86_64:
"_CFNotificationCenterAddObserver", referenced from:
_macfont_copy_available_families_cache in macfont.o
"_CFNotificationCenterGetLocalCenter", referenced from:
_macfont_copy_available_families_cache in macfont.o
"_NSDefaultRunLoopMode", referenced from:
_ns_send_appdefined in nsterm.o
-[EmacsApp run] in nsterm.o
"_OBJC_CLASS_$_NSArray", referenced from:
objc-class-ref in nsterm.o
objc-class-ref in nsmenu.o
objc-class-ref in nsselect.o
"_OBJC_CLASS_$_NSData", referenced from:
objc-class-ref in nsimage.o
"_OBJC_CLASS_$_NSDate", referenced from:
objc-class-ref in nsterm.o
"_OBJC_CLASS_$_NSDictionary", referenced from:
objc-class-ref in macfont.o
"_OBJC_CLASS_$_NSLocale", referenced from:
objc-class-ref in nsterm.o
"_OBJC_CLASS_$_NSMutableArray", referenced from:
objc-class-ref in nsterm.o
objc-class-ref in nsmenu.o
"_OBJC_CLASS_$_NSMutableDictionary", referenced from:
objc-class-ref in nsmenu.o
objc-class-ref in nsselect.o
"_OBJC_CLASS_$_NSMutableSet", referenced from:
objc-class-ref in nsterm.o
"_OBJC_CLASS_$_NSRunLoop", referenced from:
objc-class-ref in nsmenu.o
"_OBJC_CLASS_$_NSTimer", referenced from:
objc-class-ref in nsterm.o
objc-class-ref in nsmenu.o
"_OBJC_CLASS_$_NSURL", referenced from:
objc-class-ref in nsterm.o
objc-class-ref in nsfns.o
"_OBJC_CLASS_$_NSUserDefaults", referenced from:
objc-class-ref in nsterm.o
objc-class-ref in nsfns.o
"_OBJC_EHTYPE_$_NSException", referenced from:
GCC_except_table8 in nsterm.o
GCC_except_table1 in nsselect.o
ld: symbol(s) not found for architecture x86_64
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_NSArray", referenced from:
objc-class-ref in contacts.o
objc-class-ref in FormatHelper.o
"_OBJC_CLASS_$_NSMutableArray", referenced from:
objc-class-ref in FormatHelper.o
ld: symbol(s) not found for architecture x86_64
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_NSArray", referenced from:
objc-class-ref in os_macosx.o
ld: symbol(s) not found for architecture x86_64
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_NSArray", referenced from:
objc-class-ref in GPGDefaults.o
"_OBJC_CLASS_$_NSDictionary", referenced from:
objc-class-ref in PinentryController.o
objc-class-ref in GPGDefaults.o
objc-class-ref in KeychainSupport.o
"_OBJC_CLASS_$_NSMutableDictionary", referenced from:
objc-class-ref in GPGDefaults.o
"_OBJC_CLASS_$_NSSet", referenced from:
objc-class-ref in GPGDefaults.o
"_OBJC_CLASS_$_NSUserDefaults", referenced from:
objc-class-ref in GPGDefaults.o
ld: symbol(s) not found for architecture x86_64
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_NSDictionary", referenced from:
objc-class-ref in nsfile.o
objc-class-ref in nsimage.o
ld: symbol(s) not found for architecture x86_64
This tool was initially built specifically for nixcloud to prevent a few
annoying programs from binding to IP sockets.
While initially only accepting a JSON file as input, the tool now has a
proper command line interface and it's also generally usable to turn IP
sockets of any program into Unix sockets.
Another thing that might be even useful for NixOS modules is the
possibility to bend programs into using systemd socket activation.
Signed-off-by: aszlig <aszlig@nix.build>
It's not included implicitly by the frameworks anymore.
Undefined symbols for architecture x86_64:
"_NSDefaultRunLoopMode", referenced from:
_QZ_PumpEvents in SDL_QuartzEvents.o
"_OBJC_CLASS_$_NSArray", referenced from:
objc-class-ref in SDL_QuartzEvents.o
"_OBJC_CLASS_$_NSDate", referenced from:
objc-class-ref in SDL_QuartzEvents.o
ld: symbol(s) not found for architecture x86_64
It's not included implicitly by the frameworks anymore.
Undefined symbols for architecture x86_64:
"_NSDefaultRunLoopMode", referenced from:
_Cocoa_PumpEvents in SDL_cocoaevents.o
"_NSURLIsAliasFileKey", referenced from:
-[SDLWindow performDragOperation:] in SDL_cocoawindow.o
"_OBJC_CLASS_$_NSArray", referenced from:
objc-class-ref in SDL_cocoaclipboard.o
objc-class-ref in SDL_cocoakeyboard.o
objc-class-ref in SDL_cocoawindow.o
"_OBJC_CLASS_$_NSData", referenced from:
objc-class-ref in SDL_cocoamouse.o
"_OBJC_CLASS_$_NSDate", referenced from:
objc-class-ref in SDL_cocoaevents.o
"_OBJC_CLASS_$_NSDictionary", referenced from:
objc-class-ref in SDL_cocoaevents.o
"_OBJC_CLASS_$_NSMutableArray", referenced from:
objc-class-ref in SDL_cocoawindow.o
"_OBJC_CLASS_$_NSURL", referenced from:
objc-class-ref in SDL_cocoawindow.o
"_OBJC_CLASS_$_NSUserDefaults", referenced from:
objc-class-ref in SDL_cocoaevents.o
"_OBJC_EHTYPE_$_NSException", referenced from:
GCC_except_table67 in SDL_cocoawindow.o
ld: symbol(s) not found for architecture x86_64
Python 3.4 will receive it's final patch release in March 2019 and there won't
be any releases anymore after that, so also not during NixOS 2019.03.
Python 3.4 is not used anymore in Nixpkgs. In any case, migrating code from
3.4 to 3.4+ is trivial.
ee58a5b30d broke the plv8 build because it
upgraded the v8_6_x expression everywhere to the 6.9 branch, which came
with API changes. Notably, it seems plv8 only supports up-to v8 6.4.x at
this time.
This keeps a copy of the plv8_6_x expression inside the same directory
as the other v8 versions (so patches, etc are easy to apply), but it is
not exposed to the top-level of all-packages.nix.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The package is out-of-date and has no maintainer.
I don't own a chromebook device and therefore don't know
if an mainline kernel could be used instead.
cc @lheckemann @zohl
The package is out-of-date and has no maintainer.
It should be now possible to just mainline kernel.
Support for that could be added by copying the right dtb file in our linux_rpi kernel.
I do not have the hardware to test this.
cc @dezgeg @dhess
Removes the old UI build tooling; it is no longer necessary
because as of 1.2.0 it's bundled into the server binary.
It doesn't even need to have JS built, because it's bundled into
the release commit's source tree (see #48714).
The UI is enabled by default, so the NixOS service is
updated to directly use `ui = webUi;` now.
Fixes#48714.
Fixes#44192.
Fixes#41243.
Fixes#35602.
Signed-off-by: Niklas Hambüchen <mail@nh2.me>
We keep the latest minor release of each one of the last 3 major releases,
which currently are GHC versions 8.2.2, 8.4.4, and 8.6.1. We also have
ghc-HEAD, but this doesn't count.
Dropping these compilers implied that we have to drop the corresponding
versions of ghcjs, too. We can also drop a shitload of obsolete compiler
patches that newer versions no longer need.
At some point, we can probably simplify the generic builder, too.
Packages mainly the nxplayer part of the client, since the tray
doesn't work very well without the server / a complete installation.
Use the shipped libs, since nxplayer really doesn't like any others. I
believe they use internally modified versions of many libs.
Audio doesn't work: the libasound.so shipped looks for the alsa config
files in the wrong place, and even if it finds them, it still doesn't
work. Using the one from alsaLib doesn't work either and adds
instability.
These are the old tools that later became part of ACPICA.
It is obsolete and we already have newer acpica-tools.
Alias to acpica-tools for out of tree backward-compat
gImageReader is a GUI for tesseract, an optical character recognition engine.
While the UI supports Qt/Gtk, I have only added the gtk one in the nix derivation.
This commit renames the pythondaemon module to match its module name, github
name, and pypi name, which makes it easier to find and reference. In order to
avoid breaking any external users, I've left an alias with a deprecated warning.
These packages should in theory work with our GCC toolchains, but
there are some definite breakages that need to be tracked down.
Comparing output of these to old gcc-arm-embedded is important.
Affected packages include:
- axolooti
- avrdudess
- opentx
- microscheme
- betaflight
- inav
- blackmagic
- simavr
- gnuk
Rationale
---------
Currently, tests are hard to discover. For instance, someone updating
`dovecot` might not notice that the interaction of `dovecot` with
`opensmtpd` is handled in the `opensmtpd.nix` test.
And even for someone updating `opensmtpd`, it requires manual work to go
check in `nixos/tests` whether there is actually a test, especially
given not so many packages in `nixpkgs` have tests and this is thus most
of the time useless.
Finally, for the reviewer, it is much easier to check that the “Tested
via one or more NixOS test(s)” has been checked if the file modified
already includes the list of relevant tests.
Implementation
--------------
Currently, this commit only adds the metadata in the package. Each
element of the `meta.tests` attribute is a derivation that, when it
builds successfully, means the test has passed (ie. following the same
convention as NixOS tests).
Future Work
-----------
In the future, the tools could be made aware of this `meta.tests`
attribute, and for instance a `--with-tests` could be added to
`nix-build` so that it also builds all the tests. Or a `--without-tests`
to build without all the tests. @Profpatsch described in his NixCon talk
such systems.
Another thing that would help in the future would be the possibility to
reasonably easily have cross-derivation nix tests without the whole
NixOS VM stack. @7c6f434c already proposed such a system.
This RFC currently handles none of these concerns. Only the addition of
`meta.tests` as metadata to be used by maintainers to remember to run
relevant tests.
Initially the expression was quite small (just inherited properties from
`pkgs.dlib`), but the more it grows the better it is to store it into
its own file.
* the jre is no longer an official part of the jdk (jmod is
recommended as a replacement when needing to create smaller runtime
images)
* darwin continues to use zulu from azul
* apps that used 10 now use 11 (eclipse, bazel, josm)
