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>
Merging staging into staging-next even though we haven't merged staging-next into master yet.
The motivation for this merge is that it's been a while since we merged into master causing
the 3 branches to diverge too much.
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.
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.
* 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)
added openssh_gssapi to make it easier to test the patched version
the HPN edition isn't available on top of 7.9p1 yet
fix-host-key-algorithms-plus.patch didn't apply anymore, assuming it's
fixed.
release notes: https://www.openssh.com/txt/release-7.9
Usuage: Add breakpointHook to your `buildInputs` like this:
stdenv.mkDerivation rec {
# ...
buildInputs = [ breakpointHook ];
});
When the build fails as show in this example:
pkgs.hello.overrideAttrs (old: {
buildInputs = [ breakpointHook ];
postPatch = ''
false
'';
});
It will halt execution printing the following message:
build failed in patchPhase with exit code 1
To attach to this build run the following command as root:
cntr attach -t command cntr-/nix/store/ynyb4n82x2r7sldd58pbb405jdqh5f00-hello-2.10
Installing cntr and running the command will provide shell access to the
build sandbox of failed build:
sudo cntr attach -t command cntr-/nix/store/ynyb4n82x2r7sldd58pbb405jdqh5f00-hello-2.10
WARNING: bad ownership on /nix/var/nix/profiles/per-user/root, should be 1000
[nixbld@localhost:/var/lib/cntr]$
At /var/lib/cntr the sandbox filesystem is mounted. All commands and
files of the system are still accessible within the shell.
To execute commands from the sandbox use the `cntr exec` subcommand.
Removed the wxGUI switch because it was never working.
To build VeraCrypt text-only you still need wxGTK _and_ you need to
rebuild wxGTK without GUI too...
Moreover, the normal build provides both GUI and text-only interfaces
so it is already usable in pure CLI contexts.
TrueCrypt has been retired for a while now and the source archive we
pointed to is gone. Moreover the VeraCrypt fork is available, maintained
and fixes issues previous audits found in TrueCrypt.
'cloudflared' is a multi-purpose client-side tool for CloudFlare Argo
Tunnel, CloudFlare Access, as well as including a simple DNS-over-HTTP
(DoH) proxy tool as well.
However, 'cloudflared' is NOT available under an open source license.
Furthermore, the exact terms of redistribution (namely, if we are able
to redistribute binaries at all) are not entirely clear to me. As a
result, I have filed the following bug report concerning the terms of
redistribution for the source code and binaries:
https://github.com/cloudflare/cloudflared/issues/53
'cloudflared' does have source code available, however, and it
encourages users to use 'go install' in order to set it up, in fact (or
download their prebuilt, compiled binaries). So using the source seems
to be encouraged. Even then, I'm still not sure if Hydra can serve these
binaries.
In lieu of a more pointed answer regarding source/binary licensing, and
to avoid keeping this expression in my private tree, I've marked it as
'unfree' (to avoid Hydra serving it in any way) as well as compiled from
source (to avoid any 'redistribution allowed while unmodified' terms
that may crop up).
The dependencies for this build were generated using 'dep2nix'.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Rootston is just a reference compositor so it doesn't make that much
sense to have a module for it. Upstream doesn't really like it as well:
"Rootston will never be intended for downstream packages, it's an
internal thing we use for testing." - SirCmpwn [0]
Removing the package and the module shouldn't cause much problems
because it was marked as broken until
886131c243. If required the package can
still be accessed via wlroots.bin (could be useful for testing
purposes).
[0]: https://github.com/NixOS/nixpkgs/issues/38344#issuecomment-378449256
Even if infiniband support is enabled the option
is ignored by the configure script and no depencies
to libibverbs.so or librdmacm.so is contained in
the output.
Building stack with ghc-8.4.x requires a whole lot of version overrides -- most
notably Cabal 2.4.x --, so we don't bother and just use the one built with the
latest compiler instead.
