forked from NixOS/nixpkgs
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A small fix to fetchgit for git 2.18.0 update #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
9 tasks
dtzWill
pushed a commit
that referenced
this pull request
Jul 9, 2018
This adds some initial values for .dir-locals.el. Mainly this is useful for using bug-reference-mode. So if you have bug-reference-mode enabled - > M-x bug-reference-mode You will see as clickable text like this: Fixes NixOS#15 (NixOS#12) Closed NixOS#1252 issue #1
worldofpeace
pushed a commit
that referenced
this pull request
Dec 12, 2018
…g with it Change introduced in NixOS#50672. The patch does not apply on older protobuf like protobuf3_1 ``` $ nix-build -E 'with import ./. { }; python3Packages.protobuf.override { protobuf = protobuf3_1; }' unpacking sources unpacking source archive /nix/store/1zdyl0cxaa8ha2v1zp75zzdjd6j99d0m-source source root is source setting SOURCE_DATE_EPOCH to timestamp 315619200 of file source/util/python/BUILD patching sources applying patch /nix/store/yagx7hvylnnjq7lxbcia0y5lq1r736w3-0a59054c30e4f0ba10f10acfc1d7f3814c63e1a7.patch patching file google/protobuf/pyext/descriptor.cc Hunk #1 succeeded at 55 (offset -1 lines). patching file google/protobuf/pyext/descriptor_containers.cc patching file google/protobuf/pyext/descriptor_pool.cc Hunk #1 succeeded at 47 (offset -1 lines). patching file google/protobuf/pyext/extension_dict.cc Hunk #1 FAILED at 53. 1 out of 1 hunk FAILED -- saving rejects to file google/protobuf/pyext/extension_dict.cc.rej patching file google/protobuf/pyext/message.cc Hunk #1 succeeded at 82 (offset 3 lines). Hunk #2 succeeded at 1425 (offset -104 lines). ``` Since the patch isn't necessary on python versions older than 3.7, let's only apply it for version 3.7. This means that most things using older protobuf implementation will now be able to build when using an older pythonPackage set (as is most probably the case anyway). This still leaves protobuf 3.1 using packages hanging, but the errors will be localized to those that would be breaking anyway with the upgrade to 3.7 as default python.
dtzWill
pushed a commit
that referenced
this pull request
Mar 7, 2019
The sed expression actually caused an error on hydra: ``` sed: -e expression #1, char 18: Invalid collation character ``` It seems to build fine without it however.
dtzWill
added a commit
that referenced
this pull request
Jul 25, 2019
Jul 25 14:49:58 dtznix systemd[1825]: Started Compton X11 compositor. Jul 25 14:49:58 dtznix compton[20087]: [ 07/25/2019 14:49:58.615 glx_has_extension ERROR ] Failed get GLX extension list. Jul 25 14:49:58 dtznix compton[20087]: [ 07/25/2019 14:49:58.615 glx_has_extension ERROR ] Failed get GLX extension list. Jul 25 14:49:58 dtznix compton[20087]: [ 07/25/2019 14:49:58.616 glx_has_extension ERROR ] Failed get GLX extension list. Jul 25 14:49:58 dtznix compton[20087]: [ 07/25/2019 14:49:58.616 glx_has_extension ERROR ] Failed get GLX extension list. Jul 25 14:49:58 dtznix compton[20087]: [ 07/25/2019 14:49:58.616 glx_has_extension ERROR ] Failed get GLX extension list. Jul 25 14:49:58 dtznix compton[20087]: [ 07/25/2019 14:49:58.616 glx_init ERROR ] Root visual is not a GL visual. Jul 25 14:49:58 dtznix compton[20087]: [ 07/25/2019 14:49:58.616 initialize_backend FATAL ERROR ] Failed to initialize backend, abort> Jul 25 14:49:58 dtznix compton[20087]: ================================================================= Jul 25 14:49:58 dtznix compton[20087]: ==20087==ERROR: LeakSanitizer: detected memory leaks Jul 25 14:49:58 dtznix compton[20087]: Direct leak of 716 byte(s) in 16 object(s) allocated from: Jul 25 14:49:58 dtznix compton[20087]: #0 0x4f5f67 (/nix/store/zdk6cxvwjjni77g14ma6m1g1n29kms7a-compton-7/bin/compton+0x4f5f67) Jul 25 14:49:58 dtznix compton[20087]: #1 0x7ff287d3b27b (/nix/store/6c7qpk39yihg41ssdbzgd7g7nzfm3ic5-libxcb-1.13.1/lib/libxcb.s> Jul 25 14:49:58 dtznix compton[20087]: SUMMARY: AddressSanitizer: 716 byte(s) leaked in 16 allocation(s). Jul 25 14:49:58 dtznix systemd[1825]: compton.service: Main process exited, code=exited, status=1/FAILURE
dtzWill
pushed a commit
that referenced
this pull request
Dec 5, 2019
roundcube: tests - add space to db password, check setup script worked
dtzWill
pushed a commit
that referenced
this pull request
Feb 8, 2022
The test failed with > Test "test5 user should not be able to run commands under root" failed with > error: "invalid literal for int() with base 10: ''" since 2492da8. The reason for this is that `sudo(8)` writes the lecture to the tty[1] and only as a fallback to stdout[2]. This means that the `base64 --wrap 0` executed by `machine.execute()` doesn't affect the text written to the terminal, however the lecture is part of the string that's read from the VM via `shell.recv()`. I confirmed the problem in an interactive test session[3]: >>> command = "sudo -u test5 sudo -n -u root true" >>> out_command = f"( set -euo pipefail; {command} ) | (base64 --wrap 0; echo)\n" >>> machine.shell.send(out_command.encode()) 84 >>> machine # [ 99.015512] sudo[877]: root : TTY=hvc0 ; PWD=/tmp ; USER=test5 ; COMMAND=/run/wrappers/bin/sudo -n -u root true machine # [ 99.019373] sudo[877]: pam_unix(sudo:session): session opened for user test5(uid=1005) by (uid=0) machine # [ 99.038692] sudo[879]: pam_unix(sudo:auth): conversation failed machine # sudo: a password is required machine # [ 99.041860] sudo[879]: pam_unix(sudo:auth): auth could not identify password for [test5] machine # [ 99.046901] sudo[877]: pam_unix(sudo:session): session closed for user test5 >>> >>> x=machine._next_newline_closed_block_from_shell() >>> print(x) <newline> We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: <newline> #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. <newline> <newline> <newline> >>> Since the lecture isn't strictly necessary to confirm that `security.sudo` works as expected, I decided to disable lecturing inside the test, however we may want to fix the underlying problem in the test-driver at some point. [1] https://github.com/sudo-project/sudo/blob/SUDO_1_9_9/plugins/sudoers/check.c#L275-L283 [2] https://github.com/sudo-project/sudo/blob/SUDO_1_9_9/src/conversation.c#L95-L120 [3] I replaced each empty line with `<newline>` to make sure these aren't swallowed by git.
dtzWill
pushed a commit
that referenced
this pull request
Apr 6, 2022
This effectively fixes the majority of all VM tests which were broken because `/dev/vda` (or any other block device) wasn't mountable: machine # mounting /dev/vda on /... machine # mount: mounting /dev/vda on /mnt-root/ failed: No such device[ 2.820976] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 machine # [ 2.821757] CPU: 0 PID: 1 Comm: init Not tainted 5.10.72 #1-NixOS machine # [ 2.821757] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 machine # [ 2.821757] Call Trace: machine # [ 2.821757] dump_stack+0x6b/0x83 machine # [ 2.821757] panic+0x101/0x2c8 machine # [ 2.821757] do_exit.cold+0x14/0xb3 machine # [ 2.821757] do_group_exit+0x33/0xa0 machine # [ 2.821757] __x64_sys_exit_group+0x14/0x20 machine # [ 2.821757] do_syscall_64+0x33/0x40 machine # [ 2.821757] entry_SYSCALL_64_after_hwframe+0x44/0xa9 machine # [ 2.821757] RIP: 0033:0x7f67ec2800f6 machine # [ 2.821757] Code: 00 4c 8b 0d 2c 5d 11 00 eb 19 66 2e 0f 1f 84 00 00 00 00 00 89 d7 89 f0 0f 05 48 3d 00 f0 ff ff 77 22 f4 89 d7 44 89 c0 0f 05 <48> 3d 00 f0 ff ff 76 e2 f7 d8 64 41 89 01 eb da 66 2e 0f 1f 84 00 machine # [ 2.821757] RSP: 002b:00007fff8f5a71d8 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7 machine # [ 2.821757] RAX: ffffffffffffffda RBX: 0000000000699704 RCX: 00007f67ec2800f6 machine # [ 2.821757] RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 machine # [ 2.821757] RBP: 0000000000000004 R08: 00000000000000e7 R09: ffffffffffffff80 machine # [ 2.821757] R10: 00007f67ec33f3e0 R11: 0000000000000202 R12: 000000000000000b machine # [ 2.821757] R13: 00007fff8f5a75a8 R14: 0000000000000000 R15: 00000000004fc198 machine # [ 2.821757] Kernel Offset: 0x31e00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) machine # [ 2.821757] Rebooting in 1 seconds.. This happened because the kernel failed to load modules such as `ext4` from `boot.initrd.availableKernelModules`[1] on e.g. a `mount(2)` syscall. The problem is that `kmod` isn't linked against `libpthread.so.0` anymore because it got merged into `libc.so.6` (however, the .so still exists), but still needs it: machine # newfstatat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib/x86_64", 0x7ffd951114c0, 0) = -1 ENOENT (No such file or directory) machine # openat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib/x86_64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) machine # newfstatat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib/x86_64", 0x7ffd951114c0, 0) = -1 ENOENT (No such file or directory) machine # openat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) machine # newfstatat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib", 0x7ffd951114c0, 0) = -1 ENOENT (No such file or directory) machine # openat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) machine # writev(2, [{iov_base="/nix/store/kdc9n48ksdc1a8y8w512w"..., iov_len=69}, {iov_base=": ", iov_len=2}, {iov_base="error while loading shared libra"..., iov_len=36}, {iov_base=": ", iov_len=2}, {iov_base="libpthread.so.0", iov_len=15}, {iov_base=": ", iov_len=2}, {iov_base="cy machine # ) = 184 machine # exit_group(127) = ? machine # +++ exited with 127 +++ machine # mount: mounting /dev/vda on /mnt-root/ failed: No such device machine # [ 19.167180] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 machine # [ 19.167711] CPU: 0 PID: 1 Comm: init Not tainted 5.10.72 #1-NixOS This is not a problem * inside stage-1 because `LD_LIBRARY_PATH` points to `$out/lib` of extra-utils where `libpthread.so.6` also exists. * on a running system because `${pkgs.glibc}/lib` is part of kmod's rpath. However this is a problem inside the kernel which calls `modprobe` (in our case `kmod`) to load modules and doesn't know about `LD_LIBRARY_PATH`. Also, the rpath-reference was nuked. To work around this, the kernel's `modprobe` (i.e. `/proc/sys/kernel/modprobe`) now points to a wrapper which explicitly declares `LD_LIBRARY_PATH`. We can't use `makeWrapper` here because `modprobe` itself must not be renamed. Otherwise, `kmod` (which is the link-target of `modprobe`) won't work because it expects `argv[0] == "modprobe"` to perform modprobe's tasks. [1] https://nixos.org/manual/nixos/stable/options.html#opt-boot.initrd.availableKernelModules
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.