text:
nixos/caddy: add environmentFile option

Things done
Added an environmentFile option that's passed to the systemd service unit.

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@ofborg test caddy
(just in case :p)

authors: cything getchoo


text:
pinentry_mac: enable xcbuild on darwin

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build gnupg

Success on x86_64-linux (full log)
Attempted: gnupg
Partial log (click to expand)
/nix/store/rqx2jzcylcl46p0agibzqfr1awikzmr6-gnupg-2.2.5

Success on aarch64-linux (full log)
Attempted: gnupg
Partial log (click to expand)
copying path '/nix/store/yh1249v82jg95f7z1j08k680pckl268l-libassuan-2.5.1' from 'https://cache.nixos.org'...
copying path '/nix/store/qlv3j06x2nnfvwqqxka97f4zzzbckm6y-libksba-1.3.5' from 'https://cache.nixos.org'...
copying path '/nix/store/j3x36mba7315zpcx8lm9k4xikqr97a4f-npth-1.5' from 'https://cache.nixos.org'...
copying path '/nix/store/lvplyayjbcpw40bg6bwgdpfxpr8i9dd7-pcsclite-1.8.23' from 'https://cache.nixos.org'...
copying path '/nix/store/11jkn8f137qccf7bgh6jygcyv1bqzy4h-cyrus-sasl-2.1.26' from 'https://cache.nixos.org'...
copying path '/nix/store/d3dxwqjncj429ql2jpqx796klhbpc0r6-libsecret-0.18.5' from 'https://cache.nixos.org'...
copying path '/nix/store/haq0rk04x756nv1y87zwcfiqqg54fss2-openldap-2.4.45' from 'https://cache.nixos.org'...
copying path '/nix/store/2ks78q5xy6j37r3xqznqc0glyqdrlg0x-pinentry-1.1.0' from 'https://cache.nixos.org'...
copying path '/nix/store/52yyaki6cd70k476ngyqrkcwpppmmjdv-gnupg-2.2.5' from 'https://cache.nixos.org'...
/nix/store/52yyaki6cd70k476ngyqrkcwpppmmjdv-gnupg-2.2.5

Success on x86_64-darwin (full log)
Attempted: gnupg
Partial log (click to expand)
make[1]: Leaving directory '/private/tmp/nix-build-gnupg-2.2.5.drv-0/gnupg-2.2.5'
post-installation fixup
gzipping man pages under /nix/store/174zbf3xqm7l5lwrsvg2m5zy1iri3966-gnupg-2.2.5/share/man/
strip is /nix/store/kdff2gim6417493yha769kh00n63lnrw-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/174zbf3xqm7l5lwrsvg2m5zy1iri3966-gnupg-2.2.5/lib  /nix/store/174zbf3xqm7l5lwrsvg2m5zy1iri3966-gnupg-2.2.5/libexec  /nix/store/174zbf3xqm7l5lwrsvg2m5zy1iri3966-gnupg-2.2.5/bin  /nix/store/174zbf3xqm7l5lwrsvg2m5zy1iri3966-gnupg-2.2.5/sbin
patching script interpreter paths in /nix/store/174zbf3xqm7l5lwrsvg2m5zy1iri3966-gnupg-2.2.5
/nix/store/174zbf3xqm7l5lwrsvg2m5zy1iri3966-gnupg-2.2.5/sbin/applygnupgdefaults: interpreter directive changed from "/bin/sh" to "/nix/store/r8bx3qf1bpncb14i9gzma4vr089pc3pv-bash-4.4-p19/bin/sh"
/nix/store/174zbf3xqm7l5lwrsvg2m5zy1iri3966-gnupg-2.2.5/sbin/addgnupghome: interpreter directive changed from "/bin/sh" to "/nix/store/r8bx3qf1bpncb14i9gzma4vr089pc3pv-bash-4.4-p19/bin/sh"
moving /nix/store/174zbf3xqm7l5lwrsvg2m5zy1iri3966-gnupg-2.2.5/sbin/* to /nix/store/174zbf3xqm7l5lwrsvg2m5zy1iri3966-gnupg-2.2.5/bin
/nix/store/174zbf3xqm7l5lwrsvg2m5zy1iri3966-gnupg-2.2.5

source: gharchive/pull-request

repo: NixOS/nixpkgs

license: MIT

license_type: permissive

license_source: github-api


text:
kde_applications: 17.12.3 -> 18.04.0

Motivation for this change
New release.
@ttuegel @adisbladis @peterhoeg
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

@bkchr looks like okteta needs a little love

Success on x86_64-linux (full log)
Attempted: okteta
Partial log (click to expand)
shrinking /nix/store/3dh084djlsdix3cdmzqf1cykqjz8css8-okteta/lib/libkasten3okteta1gui.so.0.3.1
shrinking /nix/store/3dh084djlsdix3cdmzqf1cykqjz8css8-okteta/lib/libkasten3okteta1controllers.so.0.3.1
shrinking /nix/store/3dh084djlsdix3cdmzqf1cykqjz8css8-okteta/bin/okteta
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/3dh084djlsdix3cdmzqf1cykqjz8css8-okteta/lib  /nix/store/3dh084djlsdix3cdmzqf1cykqjz8css8-okteta/bin
patching script interpreter paths in /nix/store/3dh084djlsdix3cdmzqf1cykqjz8css8-okteta
/nix/store/3dh084djlsdix3cdmzqf1cykqjz8css8-okteta/bin/struct2osd: interpreter directive changed from "/bin/sh" to "/nix/store/xn5gv3lpfy91yvfy9b0i7klfcxh9xskz-bash-4.4-p19/bin/sh"
checking for references to /build in /nix/store/3dh084djlsdix3cdmzqf1cykqjz8css8-okteta...
postPatchMkspecs
postPatchMkspecs

Success on aarch64-linux (full log)
Attempted: okteta
Partial log (click to expand)
shrinking /nix/store/3y1yc0imkd5q07q7g39pa8jdsr24snqd-okteta/lib/libkasten3controllers.so.0.3.0
shrinking /nix/store/3y1yc0imkd5q07q7g39pa8jdsr24snqd-okteta/lib/libkasten3gui.so.0.3.0
shrinking /nix/store/3y1yc0imkd5q07q7g39pa8jdsr24snqd-okteta/lib/libkasten3core.so.0.3.0
strip is /nix/store/j7d4mr0ikv974ig7yzhknpsq288js4bs-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/3y1yc0imkd5q07q7g39pa8jdsr24snqd-okteta/lib  /nix/store/3y1yc0imkd5q07q7g39pa8jdsr24snqd-okteta/bin
patching script interpreter paths in /nix/store/3y1yc0imkd5q07q7g39pa8jdsr24snqd-okteta
/nix/store/3y1yc0imkd5q07q7g39pa8jdsr24snqd-okteta/bin/struct2osd: interpreter directive changed from "/bin/sh" to "/nix/store/adw9jx59wnrh5659wz43nbjya3m4b3gl-bash-4.4-p19/bin/sh"
checking for references to /build in /nix/store/3y1yc0imkd5q07q7g39pa8jdsr24snqd-okteta...
postPatchMkspecs
postPatchMkspecs

@peterhoeg I don't have any idea why ofborg fails currently, but locally okteta still builds.

Ohh :pensive: Thanks for fixing this embarrassing error :+1:

Had some time to look at the remaining failure.
Maintainers in kholidays was not a list.
Fixed and squashed with the commit that moved kholidays.

authors: GrahamcOfBorg adisbladis bkchr peterhoeg


text:
byacc: 20170709 -> 20180510

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/byacc/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 20180510 with grep in /nix/store/z8i5f145zpz750hvcbjlncy8kqak8zv2-byacc-20180510
directory tree listing: https://gist.github.com/328d2b1900cfb911e7567cabf95d80c3
du listing: https://gist.github.com/cc161fe31193017387ae25b64829aaf2

meta.description for byacc is: '"Berkeley YACC"'.

Success on x86_64-linux (full log)
Attempted: byacc
Partial log (click to expand)
/nix/store/jy9knxp7nmw80jkf932axrs1b4p9k4hi-coreutils-8.29/bin/install -c yacc /nix/store/z8i5f145zpz750hvcbjlncy8kqak8zv2-byacc-20180510/bin/`echo yacc        | sed 's/$//'       |sed 's,x,x,'|sed 's/$//'`
/nix/store/jy9knxp7nmw80jkf932axrs1b4p9k4hi-coreutils-8.29/bin/install -c -m 644 ./yacc.1 /nix/store/z8i5f145zpz750hvcbjlncy8kqak8zv2-byacc-20180510/share/man/man1/`echo yacc.1| sed 's/1$//'|sed 's,x,x,'|sed 's/$/1/'`
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/z8i5f145zpz750hvcbjlncy8kqak8zv2-byacc-20180510
shrinking /nix/store/z8i5f145zpz750hvcbjlncy8kqak8zv2-byacc-20180510/bin/yacc
gzipping man pages under /nix/store/z8i5f145zpz750hvcbjlncy8kqak8zv2-byacc-20180510/share/man/
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/z8i5f145zpz750hvcbjlncy8kqak8zv2-byacc-20180510/bin
patching script interpreter paths in /nix/store/z8i5f145zpz750hvcbjlncy8kqak8zv2-byacc-20180510
checking for references to /build in /nix/store/z8i5f145zpz750hvcbjlncy8kqak8zv2-byacc-20180510...

Success on x86_64-darwin (full log)
Attempted: byacc
Partial log (click to expand)
mkdir -p /nix/store/007a2iam04iav56ss8bsfjxb45x44rdm-byacc-20180510/bin
mkdir -p /nix/store/007a2iam04iav56ss8bsfjxb45x44rdm-byacc-20180510/share/man/man1
/nix/store/5lkrw9dnsgy62qm1ampvww1c5n1pdm4b-coreutils-8.29/bin/install -c yacc /nix/store/007a2iam04iav56ss8bsfjxb45x44rdm-byacc-20180510/bin/`echo yacc        | sed 's/$//'       |sed 's,x,x,'|sed 's/$//'`
/nix/store/5lkrw9dnsgy62qm1ampvww1c5n1pdm4b-coreutils-8.29/bin/install -c -m 644 ./yacc.1 /nix/store/007a2iam04iav56ss8bsfjxb45x44rdm-byacc-20180510/share/man/man1/`echo yacc.1| sed 's/1$//'|sed 's,x,x,'|sed 's/$/1/'`
post-installation fixup
gzipping man pages under /nix/store/007a2iam04iav56ss8bsfjxb45x44rdm-byacc-20180510/share/man/
strip is /nix/store/kdff2gim6417493yha769kh00n63lnrw-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/007a2iam04iav56ss8bsfjxb45x44rdm-byacc-20180510/bin
patching script interpreter paths in /nix/store/007a2iam04iav56ss8bsfjxb45x44rdm-byacc-20180510
/nix/store/007a2iam04iav56ss8bsfjxb45x44rdm-byacc-20180510

Success on aarch64-linux (full log)
Attempted: byacc
Partial log (click to expand)
/nix/store/k6pzkhdivfd205wg942m98n198pklhg3-coreutils-8.29/bin/install -c -m 644 ./yacc.1 /nix/store/0f0zqi48rj7frjx5wdj1mr2i73y8pnm2-byacc-20180510/share/man/man1/`echo yacc.1| sed 's/1$//'|sed 's,x,x,'|sed 's/$/1/'`
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/0f0zqi48rj7frjx5wdj1mr2i73y8pnm2-byacc-20180510
shrinking /nix/store/0f0zqi48rj7frjx5wdj1mr2i73y8pnm2-byacc-20180510/bin/yacc
gzipping man pages under /nix/store/0f0zqi48rj7frjx5wdj1mr2i73y8pnm2-byacc-20180510/share/man/
strip is /nix/store/gp7fylxwn18b7pl2c18ks89hsiaxyfvf-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/0f0zqi48rj7frjx5wdj1mr2i73y8pnm2-byacc-20180510/bin
patching script interpreter paths in /nix/store/0f0zqi48rj7frjx5wdj1mr2i73y8pnm2-byacc-20180510
checking for references to /build in /nix/store/0f0zqi48rj7frjx5wdj1mr2i73y8pnm2-byacc-20180510...
/nix/store/0f0zqi48rj7frjx5wdj1mr2i73y8pnm2-byacc-20180510

authors: GrahamcOfBorg r-ryantm


text:
any-nix-shell: init at 1.1.0

Motivation for this change
This adds fish and zsh support for both nix run and nix-shell. More supported shells can be added in the future.
Supersedes #46630 as this is version 1.1.0
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[X] Fits CONTRIBUTING.md.

@grahamcofborg any-nix-shell

@GrahamcOfBorg build any-nix-shell

Success on aarch64-linux (full log)
Attempted: any-nix-shell
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/m0f347mldvgh93frg60gbryq6rz754lb-any-nix-shell-1.1.0
strip is /nix/store/428gs2z4b8f9byvghzlpbjwjb3a7jwxx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/m0f347mldvgh93frg60gbryq6rz754lb-any-nix-shell-1.1.0/bin
patching script interpreter paths in /nix/store/m0f347mldvgh93frg60gbryq6rz754lb-any-nix-shell-1.1.0
/nix/store/m0f347mldvgh93frg60gbryq6rz754lb-any-nix-shell-1.1.0/bin/.any-nix-shell-wrapped: interpreter directive changed from "/bin/sh" to "/nix/store/017xymp5i03qzigafnfx7sgf6602gmzq-bash-4.4-p23/bin/sh"
/nix/store/m0f347mldvgh93frg60gbryq6rz754lb-any-nix-shell-1.1.0/bin/nix-shell-info: interpreter directive changed from "/bin/sh" to "/nix/store/017xymp5i03qzigafnfx7sgf6602gmzq-bash-4.4-p23/bin/sh"
/nix/store/m0f347mldvgh93frg60gbryq6rz754lb-any-nix-shell-1.1.0/bin/.any-nix-shell-wrapper: interpreter directive changed from "/bin/sh" to "/nix/store/017xymp5i03qzigafnfx7sgf6602gmzq-bash-4.4-p23/bin/sh"
/nix/store/m0f347mldvgh93frg60gbryq6rz754lb-any-nix-shell-1.1.0/bin/.any-nix-run-wrapper: interpreter directive changed from "/bin/sh" to "/nix/store/017xymp5i03qzigafnfx7sgf6602gmzq-bash-4.4-p23/bin/sh"
checking for references to /build in /nix/store/m0f347mldvgh93frg60gbryq6rz754lb-any-nix-shell-1.1.0...
/nix/store/m0f347mldvgh93frg60gbryq6rz754lb-any-nix-shell-1.1.0

Success on x86_64-darwin (full log)
Attempted: any-nix-shell
Partial log (click to expand)
installing
post-installation fixup
strip is /nix/store/9xjkb4xz0b5lmizij9ppxy7lkxdxhx6b-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/fwnjppny28ryfql8rmg4746x47jg5z94-any-nix-shell-1.1.0/bin
patching script interpreter paths in /nix/store/fwnjppny28ryfql8rmg4746x47jg5z94-any-nix-shell-1.1.0
/nix/store/fwnjppny28ryfql8rmg4746x47jg5z94-any-nix-shell-1.1.0/bin/.any-nix-run-wrapper: interpreter directive changed from "/bin/sh" to "/nix/store/f2lp21azk4w88f17zgf4mji64agb18ga-bash-4.4-p23/bin/sh"
/nix/store/fwnjppny28ryfql8rmg4746x47jg5z94-any-nix-shell-1.1.0/bin/.any-nix-shell-wrapped: interpreter directive changed from "/bin/sh" to "/nix/store/f2lp21azk4w88f17zgf4mji64agb18ga-bash-4.4-p23/bin/sh"
/nix/store/fwnjppny28ryfql8rmg4746x47jg5z94-any-nix-shell-1.1.0/bin/.any-nix-shell-wrapper: interpreter directive changed from "/bin/sh" to "/nix/store/f2lp21azk4w88f17zgf4mji64agb18ga-bash-4.4-p23/bin/sh"
/nix/store/fwnjppny28ryfql8rmg4746x47jg5z94-any-nix-shell-1.1.0/bin/nix-shell-info: interpreter directive changed from "/bin/sh" to "/nix/store/f2lp21azk4w88f17zgf4mji64agb18ga-bash-4.4-p23/bin/sh"
/nix/store/fwnjppny28ryfql8rmg4746x47jg5z94-any-nix-shell-1.1.0

authors: GrahamcOfBorg haslersn joachifm matthewbauer


text:
copyq: 3.6.1 -> 3.7.0

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/copyq/versions.
meta.description for copyq is: '"Clipboard Manager with Advanced Features"'.
Release on GitHub
Compare changes on GitHub

Checks done (click to expand)

built on NixOS
/nix/store/7jwf5x7fpiycjbxm3niyv0v9hk078vvy-CopyQ-3.7.0/bin/copyq passed the binary check.
1 of 1 passed binary check by having a zero exit code.
0 of 1 passed binary check by having the new version present in output.
found 3.7.0 with grep in /nix/store/7jwf5x7fpiycjbxm3niyv0v9hk078vvy-CopyQ-3.7.0
directory tree listing: https://gist.github.com/b204af13580672244ea804489e835c94
du listing: https://gist.github.com/2b836870a7bdd0fd58765e506269e82b

Outpath report (click to expand)

Outpath difference report
3 total rebuild paths
1 package rebuilds
1 x86_64-linux rebuilds
1 i686-linux rebuilds
0 x86_64-darwin rebuilds
1 aarch64-linux rebuilds
First ten rebuilds by attrpath
copyq

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/7jwf5x7fpiycjbxm3niyv0v9hk078vvy-CopyQ-3.7.0 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A copyq https://github.com/r-ryantm/nixpkgs/archive/1bbcda6171d325ee331f8c5d346666f1531b9fca.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/7jwf5x7fpiycjbxm3niyv0v9hk078vvy-CopyQ-3.7.0
ls -la /nix/store/7jwf5x7fpiycjbxm3niyv0v9hk078vvy-CopyQ-3.7.0/bin

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: copyq
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: copyq
Partial log (click to expand)
shrinking /nix/store/7jwf5x7fpiycjbxm3niyv0v9hk078vvy-CopyQ-3.7.0/lib/copyq/plugins/libitemsync.so
shrinking /nix/store/7jwf5x7fpiycjbxm3niyv0v9hk078vvy-CopyQ-3.7.0/lib/copyq/plugins/libitemimage.so
shrinking /nix/store/7jwf5x7fpiycjbxm3niyv0v9hk078vvy-CopyQ-3.7.0/lib/copyq/plugins/libitempinned.so
gzipping man pages under /nix/store/7jwf5x7fpiycjbxm3niyv0v9hk078vvy-CopyQ-3.7.0/share/man/
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/7jwf5x7fpiycjbxm3niyv0v9hk078vvy-CopyQ-3.7.0/lib  /nix/store/7jwf5x7fpiycjbxm3niyv0v9hk078vvy-CopyQ-3.7.0/bin
patching script interpreter paths in /nix/store/7jwf5x7fpiycjbxm3niyv0v9hk078vvy-CopyQ-3.7.0
checking for references to /build in /nix/store/7jwf5x7fpiycjbxm3niyv0v9hk078vvy-CopyQ-3.7.0...
postPatchMkspecs
/nix/store/7jwf5x7fpiycjbxm3niyv0v9hk078vvy-CopyQ-3.7.0


text:
freetds: 1.00.94 -> 1.00.108

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/freetds/versions.
meta.description for freetds is: '"Libraries to natively talk to Microsoft SQL Server and Sybase databases"'.

Checks done (click to expand)

built on NixOS
Warning: no invocation of /nix/store/7fj9gii9h019whigi7mxiw9am3lj0nxm-freetds-1.00.108/bin/tdspool had a zero exit code or showed the expected version
/nix/store/7fj9gii9h019whigi7mxiw9am3lj0nxm-freetds-1.00.108/bin/fisql passed the binary check.
Warning: no invocation of /nix/store/7fj9gii9h019whigi7mxiw9am3lj0nxm-freetds-1.00.108/bin/tsql had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/7fj9gii9h019whigi7mxiw9am3lj0nxm-freetds-1.00.108/bin/freebcp had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/7fj9gii9h019whigi7mxiw9am3lj0nxm-freetds-1.00.108/bin/bsqldb had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/7fj9gii9h019whigi7mxiw9am3lj0nxm-freetds-1.00.108/bin/defncopy had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/7fj9gii9h019whigi7mxiw9am3lj0nxm-freetds-1.00.108/bin/datacopy had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/7fj9gii9h019whigi7mxiw9am3lj0nxm-freetds-1.00.108/bin/bsqlodbc had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/7fj9gii9h019whigi7mxiw9am3lj0nxm-freetds-1.00.108/bin/osql had a zero exit code or showed the expected version
1 of 9 passed binary check by having a zero exit code.
0 of 9 passed binary check by having the new version present in output.
found 1.00.108 with grep in /nix/store/7fj9gii9h019whigi7mxiw9am3lj0nxm-freetds-1.00.108
directory tree listing: https://gist.github.com/5f1298cd1a86f560edf5d1aac02a95d7
du listing: https://gist.github.com/94d09e25faf4b8a78c71849d334a3187

Rebuild report (click to expand)

155 total rebuild path(s)
110 package rebuild(s)
110 x86_64-linux rebuild(s)
21 i686-linux rebuild(s)
3 x86_64-darwin rebuild(s)
21 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
arcanist
check-mssql-health
drush
freetds
hhvm
kcachegrind
kdeApplications.kcachegrind
limesurvey
lsp-plugins
matomo
nagios
nextcloud-news-updater
perl526Packages.DBDsybase
perl528Packages.DBDsybase
perldevelPackages.DBDsybase
php
php-embed
php71
php71-embed
php71Packages.apcu
php71Packages.apcu51
php71Packages.apcu_bc
php71Packages.ast
php71Packages.box
php71Packages.composer
php71Packages.couchbase
php71Packages.igbinary
php71Packages.imagick
php71Packages.mailparse
php71Packages.memcached
php71Packages.memcachedPhp7
php71Packages.oci8
php71Packages.pcs
php71Packages.php-cs-fixer
php71Packages.php-parallel-lint
php71Packages.php_excel
php71Packages.phpcbf
php71Packages.phpcs
php71Packages.redis
php71Packages.redis31
php71Packages.v8
php71Packages.v8js
php71Packages.xdebug
php71Packages.xdebug26
php71Packages.yaml
php71Packages.yaml20
php71Packages.zmq
php72
php72-embed
php72Packages.apcu

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/7fj9gii9h019whigi7mxiw9am3lj0nxm-freetds-1.00.108 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A freetds https://github.com/r-ryantm/nixpkgs/archive/9d034578dc8cccef6a8b8b53bb03f274c2e724fc.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/7fj9gii9h019whigi7mxiw9am3lj0nxm-freetds-1.00.108
ls -la /nix/store/7fj9gii9h019whigi7mxiw9am3lj0nxm-freetds-1.00.108/bin

cc @peterhoeg for testing.

master is at .94 but staging is already at .104 since #48520


text:
linux_latest-libre: update patchset for kernel version

Motivation for this change
fixes #51219
cc @alyssais
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Thanks! I wonder if we should have a comment somewhere to bump the linux-libre rev when updating the kernel?

Sounds like a good idea, along with this to find the latest revision.
$ curl https://www.fsfla.org/svn/fsfla/software/linux-libre/releases/tags/ | grep -Eo 'Revision [0-9]+'

```console

TIL :)


text:
octoprint: 1.3.8 -> 1.3.9

Motivation for this change
Apart from upgrading octoprint, perform a number of cleanups concerning dependencies and constraints.
Cc: @abbradar
Also add octoprint-mqtt.
I haven't actually tried all this out yet (tests pass though) as our printer just arrived y'day.
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

@GrahamcOfBorg build python2.pkgs.flask_login python3.pkgs.flask_login

I think flask-login had running tests before. Tests will only be included in the PyPI tarball from the next version on: https://github.com/maxcountryman/flask-login/blob/master/MANIFEST.in#L2.
Therefore, I think it's okay to leave it like that and have the tests run again after the next upgrade. However, you could alternatively override src by providing a complete src = fetchFromGitHub { ... }.

Thanks for the mkOverride trick from HA @dotlambda - it's really nice pattern to follow for python applications

However, you could alternatively override src by providing a complete src = fetchFromGitHub

I'm very much in favour of simply ignoring the tests for one cycle as it will "fix itself" as you say.

Regarding mkOverride, the only thing I'm worried about is the possible increase in evaluation time due to lib.composeExtensions. But noone seems to have complained yet :)

authors: dotlambda peterhoeg


text:
ruby: fix cross-build

Enable autoreconfHook by default: The build tried to execute autoconf, which was
in the wrong build input. Regenerating autotools configure files is always a good
idea since it delivers fixes.
Also move groff to the native since it is only used at build-time
Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

The cross-build existed already before but was just broken. buildRubyGems will be more complex since we would need something like https://github.com/rake-compiler/rake-compiler

After a very long git bisect session, I found that this commit, more specifically the --destdir $GEM_HOME  is responsible for breaking bundlerEnv in cases where the ruby (minor) version is not the latest one. I tested it with https://git.immae.eu/?p=perso/Immae/Config/Nix.git;a=tree;f=nixops/modules/websites/tools/diaspora;hb=61199e9367515ec28f2a24903ea12a7b6747c9c0 , but all my bundler applications in a similar situation (not the latest ruby version) broke at once after an upgrade, and reverting the destdir addition makes them work again ( https://git.immae.eu/?p=perso/Immae/Config/Nix.git;a=commitdiff;h=3345e58db4e8364a9561dc3d488da2438aca982a ).
The error only happens at runtime (in the systemd service, defined in default.nix in my example), while similar commands at build time (for instance railsRoot in diaspora.nix) work correctly. I tried multiple options and flags in vain, but I may have missed the "right" way to use bundlerEnv that would make it work...
Before reporting it as a regression issue, I’d appreciate a confirmation that it is actually a regression and not just me misusing  bundlerEnv.

I'm hitting an issue relating to this change. Before this change, bundler was made available in the output, while after the change it doesn't. It seems related to how the bundled gems (site_ruby) stuff is now in probably erroneously nested subpaths of the output. See the following diff of the outputs with the commit, and with it reverted.

https://gist.github.com/aff578283e627b5befcadee5cf909cb6

Though, I'm unsure whether this is really an issue or not, but it breaks what was previousy working, and (while quite late) the backport to 18.09 changes its behaviour compared to the branch off point.
Should bundle have been available there? Does it make sense when the globally available bundler might not be using the same ruby as a specific one? (Though other than closure size issues, not sure it's an issue.)
Though, one thing is clear, this breaks assumptions between 18.03 and 18.09 and apparently broke an assumption between the release of 18.09 and now :/.

@samueldr the symptom is the same for me, but I think it comes from hardcoded paths somewhere (see my comment above your). Does it appear only when you use a version of bundler that is different from the latest (currently 2.6) one? If so, you should try the "patch" that I quote there: https://github.com/NixOS/nixpkgs/issues/54303#issuecomment-478392848

@immae I'm not using it with bundlerEnv, it's for providing bundler as an executable on the CLI, so the issue for me is the disappearance of bundler. Though, it might also be closely related to your issue, I just haven't really checked.

I actually jumped the gun here. I wasn't done with the complete testing and assumed that bundler + bundler deps installing would be fine.
With this merged, and a buildEnv:
buildEnv {
  name = "ruby-with-bundler";
  paths = [ bundler ruby ];
};

Traceback (most recent call last):
        2: from bin/cap:15:in `<main>'
        1: from /nix/store/rwp5fpzqssf5m9dzbgbwsfgdzw8xajra-ruby-2.5.5/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
/nix/store/rwp5fpzqssf5m9dzbgbwsfgdzw8xajra-ruby-2.5.5/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot load such file -- bundler/setup (LoadError)

While with this reverted locally it works fine. Ruby 2.6 (without this reverted) works fine too. This makes me think there really is a regression here.

Tried a build without --destdir $GEM_HOME and the native build's file listing is not identical to the previously working one.
diff --git a/pkgs/development/interpreters/ruby/default.nix b/pkgs/development/interpreters/ruby/default.nix
index e7aedfc0750..4d1775db8c7 100644
--- a/pkgs/development/interpreters/ruby/default.nix
+++ b/pkgs/development/interpreters/ruby/default.nix
@@ -146,7 +146,7 @@ let
         postInstall = ''
           # Update rubygems
           pushd rubygems
-          ${buildRuby} setup.rb --destdir $GEM_HOME
+          ${buildRuby} setup.rb
           popd

           # Remove unnecessary groff reference from runtime closure, since it's big

@immae if you're interested in trying.
Waiting on a cross aarch64 build to see. how it reacts.
Though, quoting @Mic92

Without --destdir it tries to install gemspec files in buildRuby.

Makes me think there will be an issue.

Sorry to bump this, but wondering if anyone took a look and see what's going on.

Sorry to bump this, but wondering if anyone took a look and see what's going on.

@samueldr could you summarise what isn't working as expected? I'd be happy to take a look, but it's difficult for me to understand from the thread what the issue has been determined to be.

What seems to happen, is that since this patch added --destdir $GEM_HOME, bundler/setup cannot be found when required. In my use case, it's for standard bundle install imperative use when working on a ruby codebase. It seems to also affect bundlerEnv, at least according to #54303, where @immae found the same cause to the issue.
This seems to have been caused by how gems are installed into what looks like an incorrectly nested absolute path:
-result/lib/ruby/gems/2.5.0/gems/bundler-1.16.2
+result/lib/ruby/gems/2.5.0/nix/store/rwp5fpzqssf5m9dzbgbwsfgdzw8xajra-ruby-2.5.5/lib/ruby/gems/2.5.0/nix/store/rwp5fpzqssf5m9dzbgbwsfgdzw8xajra-ruby-2.5.5/lib/ruby/gems/2.5.0/specifications/gems/bundler-1.16.2

Thanks very much — that gives me a much better place to start. I’ll look into this when I have a chance.

authors: Mic92 alyssais immae samueldr


text:
patchShebangs: Allow multiple args

Motivation for this change
It's tempting to think patchShebangs supports multiple arguments.
Without this patch it just silently ignores all but the first. Now it
patches the shebangs in all of its arguments.
Fixes: #57695
Obviously I haven't tested it on nixpkgs because it rebuilds everything. Please check whether there might be some edge cases that I forgot which could break with these changes.
I tried the function on its own (copied tothe patchPhase of a derivation) and it seems to work as intended.
Seems like there's no docbook documentation for this function. I think I'll do that next.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Waiting for reviews before merging.

@matthewbauer Do you still approve?
Does anyone else have any thoughts?
@chreekat Does this address your concerns?

Lgtm, yep

https://github.com/NixOS/nixpkgs/pull/60559#discussion_r287837965 ?

authors: FRidh Infinisil JohnAZoidberg chreekat


text:
rtmidi: 2.1.1 -> 4.0.0

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/rtmidi/versions.
meta.description for rtmidi is: '"A set of C++ classes that provide a cross platform API for realtime MIDI input/output"'.
Release on GitHub
Compare changes on GitHub

Checks done (click to expand)

built on NixOS
/bin/sh passed the binary check.
1 of 1 passed binary check by having a zero exit code.
0 of 1 passed binary check by having the new version present in output.
found 4.0.0 with grep in /nix/store/hkqd7dsrl1q14mapy83nj45qnnd8njgw-rtmidi-4.0.0
directory tree listing: https://gist.github.com/7babff04bf4fad84c8ae9d177521363c
du listing: https://gist.github.com/f2d5a3b87bf7ae6a8ebe5f944fd5613a

Rebuild report (if merged into master) (click to expand)

20 total rebuild path(s)
7 package rebuild(s)
7 x86_64-linux rebuild(s)
6 i686-linux rebuild(s)
2 x86_64-darwin rebuild(s)
5 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
csound-qt
i-score
milkytracker
muse
rtaudio
rtmidi
vcv-rack

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/hkqd7dsrl1q14mapy83nj45qnnd8njgw-rtmidi-4.0.0 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A rtmidi https://github.com/r-ryantm/nixpkgs/archive/ec2fb52b43a5da0854fa757670a5eb68d8a33fdd.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/hkqd7dsrl1q14mapy83nj45qnnd8njgw-rtmidi-4.0.0
ls -la /nix/store/hkqd7dsrl1q14mapy83nj45qnnd8njgw-rtmidi-4.0.0/bin

cc @magnetophon for testing.

nox-review builds for me, downstream binaries seem to work - non-nixos linux x86_64

authors: r-ryantm risicle


text:
WIP unifont: 12.0.01 -> 12.1.01

Bump unifont.

@ofborg build unifont unifont_upper

Rebased to master in 0c7704df0ca0754d59745f386701181d7cb55f52.


text:
cargo-edit: 0.3.2 -> 0.3.3

Motivation for this change
upstream update that simplifies nix build
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build cargo-edit

Thank you!

authors: dywedir killercup


text:
pam_mount: change order of lines in pam_mount.conf

Change order of pam_mount.conf.xml so that users can override the preset configs.
My use case is to mount a gocryptfs (a fuse program) volume. I can not do that in current order.
Because even if I change the <fusermount> and <fuserumount> by add below to extraVolumes
<fusemount>${pkgs.fuse}/bin/mount.fuse %(VOLUME) %(MNTPT) "%(before=\"-o \" OPTIONS)"</fusemount>
<fuseumount>${pkgs.fuse}/bin/fusermount -u %(MNTPT)</fuseumount>

mount.fuse still does not work because it can not find fusermount. pam_mount will told stat /bin/fusermount failed.
Fine, I can add a <path> section to extraVolumes
<path>${pkgs.fuse}/bin:${pkgs.coreutils}/bin:${pkgs.utillinux}/bin</path>

but then the <path> section is overridden by the hardcoded <path>${pkgs.utillinux}/bin</path> below. So it still does not work.

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Notify maintainers
cc @flokli

If I understand correctly your problems is you need to change the path but it's hardcoded.
Why not add an option to let users change it?

Yeah. My current problem is that I can not modify path. The curent file also has a few other option specified. I think in rare situation, some other people may want to chang those options.

Looks good. We always want to give manual configuration higher precedence over preset configuration.

authors: contrun matthewbauer rnhmjoj


text:
cfn-lint: propagate setuptools

Motivation for this change
cfn-lint fails:
Traceback (most recent call last):
  File "/nix/store/xmg2xz7n128fwhl9hw06hp1qf3x42cs7-python3.7-cfn-lint-0.24.5/bin/.cfn-lint-wrapped", line 6, in <module>
    from cfnlint.__main__ import main
  File "/nix/store/xmg2xz7n128fwhl9hw06hp1qf3x42cs7-python3.7-cfn-lint-0.24.5/lib/python3.7/site-packages/cfnlint/__init__.py", line 27, in <module>
    import cfnlint.helpers
  File "/nix/store/xmg2xz7n128fwhl9hw06hp1qf3x42cs7-python3.7-cfn-lint-0.24.5/lib/python3.7/site-packages/cfnlint/helpers.py", line 32, in <module>
    import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @

do you mind rebasing this onto staging? it causes a lot of rebuilds

@jonringer sure, rebased and retargeted the PR (not sure though if it's what you meant).

For PRs which cause more than ~100 rebuilds they should be made against staging so that people on master don't have to wind up in a situation where they need to rebuild a lot of packages just to do their dev.
https://nixos.org/nixpkgs/manual/#submitting-changes-staging-branch

python packages are "light" in compute resources, but I was afraid it was closer to the 500ish rebuilds range

Thanks for the explanation!

authors: jonringer rtimush


text:
hopper: fix libxml2 dynamic linking issue

port to qt5.callPackage / mkDerivation
format derivation

Motivation for this change
On channel: nixpkgs-20.03pre202154.58fb23f72ad hopper currently fails to start:
$ hopper
/etc/profiles/per-user/ente/bin/hopper: error while loading shared libraries: libxml2.so.2: cannot open shared object file: No such file or directory

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @Luis-Hebendanz (Maintainer)
@ttuegel (Contributor)

@jtojnar all review comments were implemented, please merge.


text:
Make python interpreters manylinux aware

Motivation for this change
Following up on https://github.com/NixOS/nixpkgs/pull/73866 this PR makes python interpreters announce manylinux compatibility when actually necessary (ie when a manylinux package is a build input). The way this works is:

manylinux packages set NIX_PYTHON_MANYLINUX in a setupHook
Python interepreters have a _manylinux.py file that checks the presence of the environment variable and its value and set the support level accordingly

Things done

Tested in combination with current work on https://github.com/nix-community/poetry2nix

@zimbatm there are some parts in the various interpreters that can be factored out. These parts have grown over time so now it makes sense. That's out of scope of this PR though.
I think it is hard to decide on whether we should protect our users (by writing a _manylinux.py with False) or not. Environment variables give freedom, but they always leak. If we claim compatibility, all that happens is that when users use a manylinux wheel, it will fail during runtime. When building wheels there is no issue actually; in order to have them manylinux compatible you use the auditwheel utility which will notice it is not compatible and fail as it should.
All in all, I am leaning now more to removing _manylinux.py again. It makes sense when only dealing with pure builds, but with impure it's harder, and at that point users are on their own anyway, so let's not hinder them.

@zimbatm there are some parts in the various interpreters that can be factored out. These parts have grown over time so now it makes sense. That's out of scope of this PR though.
I think it is hard to decide on whether we should protect our users (by writing a _manylinux.py with False) or not. Environment variables give freedom, but they always leak.
If we claim compatibility, all that happens is that when users use a manylinux wheel, it will fail during runtime. When building wheels there is no issue actually; in order to have them manylinux compatible you use the auditwheel utility which will notice it is not compatible and fail as it should.

What am I missing here?
I've seen a few build-time errors while we were working on this. Since you have to patch the binaries (for example with the autoPatchElfHook) it will be pretty obvious if there is some library dependencies that can not be provided. And of course you only will know if that works if you try to run the application. That is no different from current python packaging. You always have to execute the code and/or run tests to see if it works or just builds. (As with all/most other programming languages…)
An alternative approach would probably to provide a tailor made _manylinux.py with the manyLinuxPackages that pip then picks up during installation to figure out if manylinux is supported. I am not sure how much effort that would require and if it could work without patching pip (expressions). Idea?

All in all, I am leaning now more to removing _manylinux.py again. It makes sense when only dealing with pure builds, but with impure it's harder, and at that point users are on their own anyway, so let's not hinder them.

:+1: to this, it makes things much easier going forward.

it will be pretty obvious if there are some library dependencies that were not provided.

When you don't claim manylinux compatibility, it won't even try to use those wheels and build from source instead. Thus the failure happens during build-time instead of run-time.

An alternative approach would probably to provide a tailor made _manylinux.py with the manyLinuxPackages that pip then picks up during installation to figure out if manylinux is supported. I am not sure how much effort that would require and if it could work without patching pip (expressions). Idea?

The essential part to achieve that is in this PR.

If we claim compatibility, all that happens is that when users use a manylinux wheel, it will fail during runtime

In our experience that isn't actually true. What will happen is that autoPatchElfHook is going to fail and your entire build will fail.

All in all, I am leaning now more to removing _manylinux.py again. It makes sense when only dealing with pure builds (but we don't really need the info then either), but with impure it's harder, and at that point users are on their own anyway, so let's not hinder them.

I want to provide users the ability to make use of wheels. There are packages that only provide wheel files and no source at all. Is using source packages the preferred option from our point of view? Sure, but that doesn't mean we cannot or should not provide users with the ability to make use of the manylinux feature. If a wheel is built correctly according to the spec defined in the PEP it will work.
This change doesn't make python use wheel files in some sneaky fashion. The use of environment variables sure isn't air-tight but it doesn't seem likely to me that this would lead to random accidental misbehavior and runtime errors unless users explicitly set out to use some manylinux stuff that ends up failing.

In our experience that isn't actually true. What will happen is that autoPatchElfHook is going to fail and your entire build will fail.

If you use it in a nix-build, yes. I was talking about impurely using wheels.
So, I propose we:

remove _manylinux.py
have separate derivations for each spec that propagate the libs and autoPatchelfHook. These can be manylinux1, manylinux2010 and manylinux2014. The lists could then be put in a let...in.

Is there anything that is not considered?

I guess i need to be careful not to fall into the sunken-cost fallacy trap here but... we have consistently worked on several incremental steps to support manylinux in poetry2nix and in nixpkgs and it feels a bit late into the game to now state that manylinux support should be dropped altogether...
Is manylinux a fantastic concept? Nope. Is it being used? Yes, and i would like for Nix users to be able to use them if they want to.
The changes that this PR introduces don't disrupt anything unless someone adds one of the pythonManylinuxPackages as to buildInputs somewhere. You don't just do that by accident.

@FRidh I'm being told via side-channels that i am missing your point about what you were suggesting, but your last comment (which i saw just now) makes it a bit clearer.

Lets continue this in https://github.com/NixOS/nixpkgs/pull/75763

authors: FRidh adisbladis andir gilligan


text:
vector: 0.7.1 -> 0.7.2

Motivation for this change
This PR updates Vector to version 0.7.2. It also enables the tests.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Sorry for leaving this around -- yes, looks like a strange test failure. Maybe something to do with parallelism (complete speculation)? Either way, if we could get the tests enabled, that would be great!

@thoughtpolice It turns out that all tests failures are caused by the fact that checkPhase runs in an environment which doesn't have file /etc/resolve.conf (and it was present when the tests were running inside a Docker container with official NixOS image, which made the issue uncaught). This file path is hardcoded in rust-dns-resolver which Vector uses.
I wonder is there a way to have file /etc/resolv.conf in the test environment.

Superseded by https://github.com/NixOS/nixpkgs/pull/81040.

authors: a-rodin thoughtpolice


text:
libgsf: 1.14.46 -> 1.14.47

Semi-automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/libgsf/versions.
meta.description for libgsf is: "GNOME's Structured File Library"
meta.homepage for libgsf is: "https://www.gnome.org/projects/libgsf"
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.14.47 with grep in /nix/store/i7mncvcql22d99bx7720pch8j74sqi9m-libgsf-1.14.47

directory tree listing: https://gist.github.com/6e3b35a5767207c90af515b22e8e4dd5

du listing: https://gist.github.com/dfa7decc716182a371aca2e9017b1afb

Rebuild report (if merged into master) (click to expand)

559 total rebuild path(s)

186 package rebuild(s)

186 x86_64-linux rebuild(s)
172 i686-linux rebuild(s)
31 x86_64-darwin rebuild(s)
170 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
abiword
adapta-gtk-theme
aesop
arc-icon-theme
arc-theme
arx-libertatis
asciidoc-full
asciidoc-full-with-plugins
bibata-cursors
bibata-cursors-translucent
bibata-extra-cursors
bookworm
btrbk
capitaine-cursors
chrome-gnome-shell
clevis
crackxls
dblatexFull
deepin.dde-control-center
deepin.dde-daemon
deepin.dde-dock
deepin.dde-file-manager
deepin.dde-kwin
deepin.dde-launcher
deepin.dde-session-ui
deepin.deepin-desktop-schemas
deepin.deepin-icon-theme
deepin.startdde
deja-dup
disorderfs
doodle
dropbox-cli
elementary-planner
elementary-xfce-icon-theme
emojione
empathy
faba-icon-theme
faba-mono-icons
fim
flat-remix-icon-theme
gnome-photos
gnome3.cheese
gnome3.empathy
gnome3.file-roller
gnome3.gnome-books
gnome3.gnome-boxes
gnome3.gnome-contacts
gnome3.gnome-control-center
gnome3.gnome-documents
gnome3.gnome-photos

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/i7mncvcql22d99bx7720pch8j74sqi9m-libgsf-1.14.47 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libgsf https://github.com/r-ryantm/nixpkgs/archive/0eea0c8d44835b6a4c5341194af35f139ce69c88.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/i7mncvcql22d99bx7720pch8j74sqi9m-libgsf-1.14.47
ls -la /nix/store/i7mncvcql22d99bx7720pch8j74sqi9m-libgsf-1.14.47/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the change, simply because they are already broken on the target branch.

Maintainer pings
cc @lovek323 for testing.

	(https://ftp.gnome.org/pub/GNOME/sources/libgsf/1.14/libgsf-1.14.47.news)
	libgsf 1.14.47

	Allin Cottrell:
		* GsfOutputMemory improvement.
		* Teach GsfOutputGzip to control compression level.

	Marc-André Lureau:
		* Cleanups.  See merge request 5.

	Morten:
		* Fix fuzzed-file crash.  [#19]

	--------------------------------------------------------------------------

authors: jtojnar r-ryantm


text:
nixos/lib/make-ext4-fs: fix after mkfs.ext4 refactoring

In 9ac1ab10c963a86457c2c9b1edf31542ff3737cd  / #82718 make-ext4-fs was refactored to use mkfs.ext4 instead of cptofs. This introduced two problems:

If populateImageCommands would create no files (which is fine), a cp
invocation would fail due to missing source arguments.

Also cross compiling failed, because fakeroot is not working in that
setup. As the fakeroot call is not needed, I removed it as well.

With these changes, I can build a Raspberry Pi 4 sd-card image again on my x86 laptop.
I've used the following command for testing on a system with aarch64-linux binfmt emulation enabled:
% nix-build nixos -I nixos-config=nixos/modules/installer/cd-dvd/sd-image-raspberrypi4.nix -A config.system.build.sdImage --argstr system aarch64-linux

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

This fix should also make this Hydra job happy again: https://hydra.nixos.org/job/nixos/trunk-combined/nixos.sd_image_raspberrypi4.aarch64-linux/

I've verified that the resulting SD-Card image boots on my Raspberry Pi 4. :champagne:

For me sudo didn't work any more. Could this possibly be because of this change?

For me sudo didn't work any more. Could this possibly be because of this change?
I think some shared library wasn't owned by the correct user (root).
Edit: Can you confirm this behavior?

fakeroot call is required if If you're using Single User nix.

I'm cross-compiling on NixOS. What do you mean with single-user nix?

I'm cross-compiling on NixOS. What do you mean with single-user nix?

I had this issue when using https://nixos.org/nix/manual/#sect-single-user-installation on Ubuntu, that's why there is a fakeroot call.

As far as I understand https://git.qemu.org/?p=qemu.git;a=commit;h=d8c08b1e6c7b1a5be1ec70e339437823a41b1946 a new version of qemu might fix that and allow us to use fakeroot again? Also I consistently get an image file with invalid permissions inside (the ones from my user) with this patch.

As far as I understand https://git.qemu.org/?p=qemu.git;a=commit;h=d8c08b1e6c7b1a5be1ec70e339437823a41b1946 a new version of qemu might fix that and allow us to use fakeroot again? Also I consistently get an image file with invalid permissions inside (the ones from my user) with this pull request.

@mohe2015 I also see issues with building this from a multi-user install:
[julian@nixos:~]$ sudo ls
sudo: error in /etc/sudo.conf, line 0 while loading plugin "sudoers_policy"
sudo: /nix/store/dga8f95c24vziiir8xalmrfay4f3jxhg-sudo-1.8.31p1/libexec/sudo/sudoers.so must be owned by uid 0
sudo: fatal error, unable to load plugins

[julian@nixos:~]$ ls -lh /nix/store/dga8f95c24vziiir8xalmrfay4f3jxhg-sudo-1.8.31p1/libexec/sudo/sudoers.so
-r--r--r-- 1 julian users 393K Jan  1  1970 /nix/store/dga8f95c24vziiir8xalmrfay4f3jxhg-sudo-1.8.31p1/libexec/sudo/sudoers.so

Mmh. I think this can be fixed by using mkfs.ext4 options:
                   root_owner[=uid:gid]
                          Specify the numeric user and group ID of the root directory.  If no UID:GID is  specified,
                          use  the user and group ID of the user running mke2fs.

Will try this later. Converting this PR to a draft until then to prevent people from merging it. :)

I couldn't get it to work with the root_owner option. I think it's result is the following:
[moritz@nixos:~/nixpkgs]$ ls -l /run/media/moritz/
total 8
drwxr-xr-x 3 moritz users 4096 Jan  1  1970 NIXOS_BOOT
drwxr-xr-x 4 root   root  4096 Jan  1  1970 NIXOS_SD

[moritz@nixos:~/nixpkgs]$ ls -l /run/media/moritz/NIXOS_SD/
total 236
drwx------ 2 root   root   16384 Jan  1  1970 lost+found
drwxr-xr-x 3 moritz users   4096 Jan  1  1970 nix
-r--r--r-- 1 moritz users 217404 Jan  1  1970 nix-path-registration

So the root directory is owned by the specified user but not the files in it. Maybe I did something wrong so you should still try it out.

@mohe2015 You are right, the root_owner option is not good enough to do what we want. What does confuse me is how the store paths in the image actually have my user's UID, even through they are built by a nixbuild user.

@mohe2015 I'm not sure how we ever end up with sane uid/gids using mkfs.ext4:
In the build sandbox the nixbld user is 1000:100, but outside of the sandbox this is usually the uid/gid of the first user in the system. Hence we get the broken owners in the image.
Ideally, mkfs.ext4 would support a uid mapping configuration, but unfortunately it doesn't. Manually doing chown -R root:root before packing it into the file system also doesn't work, because it ends up with lots of invalid argument errors.
I'm open to ideas...

For me it worked with qemu 5.1.0-rc1 and normally using fakeroot. At least sudo worked and I couldn't find something nonworking.

For me it worked by building with qemu 5.1.0-rc1 and normally using fakeroot. At least sudo worked and I couldn't find something nonworking.

Ah, because fakeroot makes stat etc return uid 0 for files owned by the current user (nixbld) these end up being owned by root in the generated image. It feels a bit accidental. :)

Yeah, I think the problem is that running chown root:root without root permissions doesn't work so you use fakeroot to fool mkfs.ext4 into thinking its a file owned by root so it can build the correct file system.

I think the problem is that running chown root:root without root permissions wouldn't work so you use fakeroot to fool mkfs.ext4 into thinking its a file owned by root so it can build the correct file system.

Yes, that's also my current understanding. Not an ideal situation.

I've added the fakeroot call again. This doesn't make the cross-compilation setup painless, but should work for native builds of the raspberry pi 4 install image at least.

You need to also add back fakeroot in two other places.

I think you need to also add back fakeroot in two other places.

You were too fast, I fixed it right after @GrahamcOfBorg complained. :)

And also do you know more whether qemu 5.1.0-rc1 would be accepted in nixpkgs unstable? I assume I will have to wait for the release until it gets incoporated here but I don't know.

The binfmt emulation is pretty nice and having it fail in weird ways definitely sucks. No idea whether this counts as good reason to include a RC into unstable.
Btw, with the current version of this PR and qemu 5.1-rc1 on the build host, I can build a SD Card image that works. Finally!

Thanks for this fix -- I ran into this breakage locally and this worked like a charm to fix it.

As the pr became quite uncontroversial now, i would merge this in the next days if no one objects.

FWIW, the Debian maintainers decided to backport the QEMU fix @mohe2015 mentioned in their stable QEMU 5.0 package (original issue). Perhaps we can reuse the same patch and apply it on top of the current QEMU 5 package in nixpkgs?
https://sources.debian.org/patches/qemu/1:5.0-14/linux-user-refactor-ipc-syscall-and-support-of-semtimedop.patch/

In the meantime, is this ready to merge @tfc? I just got a Raspberry Pi 4B in the mail, and I'm hyped :eyes:

authors: Robertof aaronjanse blitz misuzu mohe2015 purcell tfc


text:
cudatext: init at 1.110.0

Motivation for this change
CudaText is a cross-platform text editor, written in Lazarus.
Resolves #56339.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

FYI @Alexey-T

some things don't work like install plugins,

It works, after you configure the "pylib__linux" option
https://wiki.freepascal.org/CudaText#Python_on_Linux.2C_BSD.2C_Solaris

scroll tab left/right buttons,

It works. on your screen, we have little count of tabs so they don't scroll.

It works, after you configure the "pylib__linux" option

Before build, I set full path to libpython3.so in https://github.com/Alexey-T/CudaText/blob/3cbe36fb8aa3ee67262fc6079335259c0589edeb/app/proc_globdata.pas#L976
Am I right that after that it's not needed to specify full path in settings_default?
$ grep "\"pylib__linux\":" result/share/cudatext/settings_default/default.json
  "pylib__linux": "libpython3.so",

Steps to reproduce:

Plugins -> Addons Manager -> Install (Nix lexer) - "Package installed", no errors.
Open some flake.nix file, dialog "Lexer(s) for flake.nix", choose "Download lexer: Nix", no errors, nothing happens, no highlighting.

I found the root cause, CudaText on first start create ~/.config/cudatext/data/lexlib with 555 permissions, instead of 755.

It works, after you configure the "pylib__linux" option

Before build, I set full path to libpython3.so in https://github.com/Alexey-T/CudaText/blob/3cbe36fb8aa3ee67262fc6079335259c0589edeb/app/proc_globdata.pas#L976
Am I right that after that it's not needed to specify full path in settings_default?

IMO yes, it should work.

$ grep "\"pylib__linux\":" result/share/cudatext/settings_default/default.json
  "pylib__linux": "libpython3.so",

but default.json is not read by program, it's only for user reference.

I've just found the root cause, CudaText on first start copy data folder from nix store into ~/.config/cudatext/data with 555 permissions, instead of 755.

Cud runs this:
  {$ifdef linux}
  if OpDirLocal<>OpDirExe then
    if IsDistroUpdateNeeded then
      if DirectoryExistsUTF8(OpDirPrecopy) then
        RunCommand('cp', ['-R', '-u', '-t',
          OpDirLocal,
          '/usr/share/cudatext/py',
          '/usr/share/cudatext/data',
          '/usr/share/cudatext/settings_default'
          ], S);
  {$endif}

so permissions 555 is copy from your dir, which is 555.

so permissions 555 is copy from your dir, which is 555.

Indeed, folder in nix store have 555 permissions. IMHO, It would be good if CudaText would make no assumtion about source permissions and force 755 while copying. What do you think?

Yes, agree. Will try to change that code part.

Made this change. do you need new linux build?

Made this change.

Thanks!

do you need new linux build?

No, nix package doesn't use binary CudaText packages, but build it from sources. So I can just apply your patch.

Nix lexer is now installed by default, just for convenience of Nix users.

I built it again, but can't see the changes. Plugins still don't appear and Nix is not known.
davidak@gaming:~/code/nixpkgs]$ nix-shell -p nixpkgs-review --run "nixpkgs-review pr 97063"

Check that file Nix.lcf exists in the .config/cudatext/data/lexlib.

Plugins don't appear? But python console panel input works OK? press Ctrl+tilde - input works ok?

I built it again, but can't see the changes. Plugins still don't appear and Nix is not known.
davidak@gaming:~/code/nixpkgs]$ nix-shell -p nixpkgs-review --run "nixpkgs-review pr 97063"

I've not commited yet, wait a bit...

@davidak Check it now, it works for me.

Just note that currrent  version is 1.111.0.

Just note that currrent version is 1.111.0.

I don't see 1.111.0 in https://github.com/Alexey-T/CudaText/tags.

Ah, "tag" will be little later, in 1-2 days.

TODO for future:

[ ] build on darwin (requires fpc/lazarus support on darwin)
[ ] optional build with qt5 widgetset (requires libqt5pas missed in nixpkgs)

It still don't work.
It is definitely build from a15ce2e and i have done a nix-collect-garbage -d to actually build it again.
[davidak@nixos:~]$ tree .config/cudatext/data/lexlib
.config/cudatext/data/lexlib
├── Assembly.cuda-lexmap
├── Assembly.lcf
├── Bash script.cuda-lexmap
├── Bash script.lcf
├── Batch files.cuda-lexmap
├── Batch files.lcf
├── C++.cuda-lexmap
├── C.cuda-lexmap
├── C++.lcf
├── C.lcf
├── CSS.cuda-lexmap
├── CSS.lcf
├── HTML.cuda-lexmap
├── HTML.lcf
├── Ini files.cuda-lexmap
├── Ini files.lcf
├── JavaScript.cuda-lexmap
├── JavaScript.lcf
├── JSDoc.cuda-lexmap
├── JSDoc.lcf
├── JSON.cuda-lexmap
├── JSON.lcf
├── Lua.cuda-lexmap
├── Lua.lcf
├── Markdown.cuda-lexmap
├── Markdown.lcf
├── PHP.cuda-lexmap
├── PHP_.cuda-lexmap
├── PHP.lcf
├── PHP_.lcf
├── Python.cuda-lexmap
├── Python.lcf
├── RegEx.cuda-lexmap
├── RegEx.lcf
├── reStructuredText.cuda-lexmap
├── reStructuredText.lcf
├── Search results.cuda-lexmap
├── Search results.lcf
├── VBScript.cuda-lexmap
├── VBScript.lcf
├── XML.cuda-lexmap
├── XML.lcf
├── YAML.cuda-lexmap
└── YAML.lcf

0 directories, 44 files

It still don't work.

Remove your old ~/.config/cudatext folder.

Yeah, they had the wrong permission.
rm: cannot remove '/home/davidak/.config/cudatext/py/cuda_tree_markdown/__init__.py': Permission denied
Now it works.

Also tested on different system.

Ah, "tag" will be little later, in 1-2 days.

Well, I will update this PR with new version as it will be out.

@Alexey-T Just in case, is there any repo where I can find CudaText translations other than https://sourceforge.net/projects/cudatext/files/addons/translations/? I can't find it in https://github.com/CudaText-addons as well. I want to allow users to optionally install more languages by default, like it's done for libreoffice https://github.com/NixOS/nixpkgs/blob/ccf01af387838dc451283e50a64dbe83b1899474/pkgs/applications/office/libreoffice/default.nix#L16.
The problem is that we need somehow versioned permanent links, but sourceforge files are not (after translations files update, links will be the same, but sha256 will be changed).

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/295

@davidak I've added libqt5pas, so now CudaText can be built with qt5 widgetset as well. And I've switched default widgetset from gtk2 to qt5, it looks a bit better for me.

With the dark theme "sub", the menu text is now black on dark grey.

terminal output:
[nix-shell:~/.cache/nixpkgs-review/pr-97063-7]$ cudatext
QApplication: invalid style override 'adwaita' passed, ignoring it.
	Available styles: Breeze, Windows, Fusion

Hmm, here is my (qt5, there is no errors in terminal):

Maybe it makes sense to switch default option back to gtk2.

I'm using the GTK-based Pantheon desktop.

@davidak Maybe you need to install the Adwaita theme files?
@sikmir do you think this is ready to merge as it is (mention me once you have a follow-up PR with more improvements), or is it better to wait for some soon-to-happen debugging/polishing?

@sikmir do you think this is ready to merge as it is (mention me once you have a follow-up PR with more improvements), or is it better to wait for some soon-to-happen debugging/polishing?

1.111.0 is out meanwhile (fixes problem with permissions, so we can remove patching), so let me to update and I thnk we are ready to proceed.

@7c6f434c Update to 1.111.0 is done and verified, feel free to proceed with merge.

authors: 7c6f434c Alexey-T davidak nixos-discourse sikmir


text:
🛑 ProxiTok proxitok.privacydev.net is down

In cfde6a0, ProxiTok proxitok.privacydev.net (https://proxitok.privacydev.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ProxiTok proxitok.privacydev.net is back up in a584eb9.

source: gharchive/issue

repo: NoPlagiarism/services-personal-upptime


text:
🛑 WikiLess wiki.privacytools.io is down

In 101e0c7, WikiLess wiki.privacytools.io (https://wiki.privacytools.io) was down:

HTTP code: 0
Response time: 0 ms

Resolved: WikiLess wiki.privacytools.io is back up in 2f82cc0.


text:
🛑 WikiLess wiki.froth.zone is down

In 9a04b3a, WikiLess wiki.froth.zone (https://wiki.froth.zone) was down:

HTTP code: 0
Response time: 0 ms

Resolved: WikiLess wiki.froth.zone is back up in e3989d3.


text:
🛑 ProxiTok tok.habedieeh.re is down

In a1d2f08, ProxiTok tok.habedieeh.re (https://tok.habedieeh.re) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ProxiTok tok.habedieeh.re is back up in 0b2b7c0 after 2 hours, 47 minutes.


text:
🛑 ProxiTok cringe.whatever.social is down

In b083920, ProxiTok cringe.whatever.social (https://cringe.whatever.social) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ProxiTok cringe.whatever.social is back up in 5e2e96b after 6 hours, 50 minutes.


text:
Crash with Aether Redux seems to still happen in Mythic Metals - 0.19.5

It seems that Aether Redux and Mythic Metals are still crashing even after the latest update.
Crash Log: https://pastebin.com/mdT9NjG5
I loaded an installation with only those two mods present to confirm the issue is solely between these two. The ticked entity seems to always be a vanilla mob but alas I don't know if it's this issue is only on my part u-u

Thanks for the crashlog. I think I know where this issue happens. I will close this as a duplicate of #229 and track it there.

authors: AndreaSpaghetti Noaaan

repo: Noaaan/MythicMetals


text:
CP for level 30+

Can we implement cp notification for level 30+/-
https://github.com/mathiasbynens/pogocpm2level
Required encounter parameter: pokemon_info.get('cp', 0) pokemon_info.get('cp_multiplier', 0)
if ('player_level' not in account or account['player_level'] >= 30):
similar to this: https://twitter.com/pokemarin

All the code seems to missing from this...

Can we reverse the CP for other levels? Seems like there is an equation for it but I'm not sure I've seen it or if it has been reversed?

This shouldn't be in pull requests, as there's no code involved. But anyway, I would like to see CP values as well, not just in notifications but in map popups too. Implementing that should be relatively easy. Leveling accounts to 30 with Monocle will take some time, though.
(For those who didn't know: CPs are the same for level 30+ accounts.)

authors: Jabsu baskettcase leppie pokejayjay

repo: Noctem/Monocle


text:
Should Multi Commands be synchronous

var redis = require('redis');
var client = redis.createClient(config.redisPort, config.redisServer);

// start a separate multi command queue
var multi = client.multi();
multi.incr('incr thing', redis.print);
multi.incr('incr other thing', redis.print);

// runs immediately
client.get('incr thing', redis.print); // 100

// drains multi queue and runs atomically
multi.exec(function (err, replies) {
    console.log(replies); // 101, 2
});

I get to notice, multi commands are Asynchronous just like their sibling redis commands.
multi.incr('incr other thing', redis.print);
client.get('incr thing', redis.print);

Should the multi commands be synchronous, except for the exec() command
multi.incr('incr thing');
multi.incr('incr other thing');
multi.exec(function (err, replies) {
    console.log(replies); // 101, 2
});

I am using node redis with promises, and currently use it the way below
return bPromise.map(items, item => {
             return redisMulti.zaddAsync(sprintf('venue_tag_%s_score', item.tag_id), item.score, item.venue_id);
            })
            .then(() => {
              return redisMulti.execAsync();
            });
// if the mutli commands were synchronous, i would use something like
for(let item of items) {
redisMulti.zadd(sprintf('venue_tag_%s_score', item.tag_id), item.score, item.venue_id);
}
 return redisMulti.execAsync();

The callbacks at the end of a command in a multi don't work the way you think they work. They all execute after exec and really exist to only isolate the result of that particular command result. That's just the way Redis works.
Otherwise, I'm not sure I really follow what you're trying to ask nor do here.

Thank you for clarifying my question. You were right, i was assuming that these multi command callbacks fire independently just like most node functions() that take callback.
Do you think, i could use the below code and safely believe it works the desired way (i.e execute all the commands in execAsync)
for(let item of items) {
redisMulti.zadd(sprintf('venue_tag_%s_score', item.tag_id), item.score, item.venue_id);
}
 return redisMulti.execAsync();

authors: jaladankisuresh stockholmux


text:
%player% placeholder doesn|t seem to work.

I am trying to use a commandsign to execute a command from Random Teleport plugin. The command for random tp is /rtp player world.
So when I try to type in this in the command section in edit mode: rtp %player% vanaheim
Then I get the message in chat: ERROR: That player isn|t online!
What am I doing wrong?
I need some help.

No news from the author, closing the ticket.

authors: CptLancelotWitty Nokorbis

repo: Nokorbis/ar-command-signs

license_source: bigquery


text:
突然性的bug，封面卡了大半截看不见

前几天还好好的。今天打开突然就这样了，刷新换浏览器也不行

侧边栏收起

authors: Danborad Nolovenodie

repo: Nolovenodie/emby-crx


text:
Can we run revm with and without optimism enabled side-by-side?

Definition of Done
Answer the question: Can we compile two different version of revm and run them side-by-side?

Research results are summarised in #411

repo: NomicFoundation/edr


text:
Emit events in debug_traceTransaction and debug_traceCall

This used to work with HH+EJS but it doesn't with HH+EDR, and we need it for #299.

Done in https://github.com/NomicFoundation/edr/pull/469


text:
Support solhint

We surface hardhat compiler errors and warnings, we should consider doing the same for solhint.
Consideration should be given to how solhint + prettier-solidity + vscode plugins interact.

Another option is to make sure the solhint extension is compatible with ours. Then we can point people in the docs.

Can we use solhint in hardhat-vscode now?

Can we use solhint in hardhat-vscode now?

Solhint support has not been started yet, and won't be in the next few months at least.

As a workaround solhint/slither can be set up as a standalone thing. My solution prioritizes Neovim so it won't be as good as native VSCode extension but daemonizing it is on my backlog.

authors: gzliudan kanej llllvvuu

repo: NomicFoundation/hardhat-vscode


text:
update NodeJS version used in CI

As the version we request is already deprecated:

The following actions uses node12 which is deprecated and will be forced to run on node16: actions/checkout@v2. For more info: https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

:exclamation: No coverage uploaded for pull request base (development@6c7d5b6). Click here to learn what that means.

:exclamation: Current head 3f9a58a differs from pull request most recent head 2f491c9. Consider uploading reports for the commit 2f491c9 to get more accurate results

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@              Coverage Diff               @@
##             development     #533   +/-   ##
==============================================
  Coverage               ?   53.19%
==============================================
  Files                  ?      188
  Lines                  ?     4824
  Branches               ?      793
==============================================
  Hits                   ?     2566
  Misses                 ?     2020
  Partials               ?      238

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

cc @kanej for review.

authors: OmarTawfik codecov-commenter


text:
Corrected sizing of the image, and changed to the correct image

Fix the height of the image, and changed it from a test-image to the correct one.

Why did you close it without approving and merging it?

Was there are reason for closing this PR ?
If everything is fine with this PR, can this be aproved and merged ? :)

Was there are reason for closing this PR ? If everything is fine with this PR, can this be aproved and merged ? :)

Done, sorry for the delay :)

authors: EmmaCaroline Whisperpiano annechh

license: Unlicense


text:
Add a further lock on row parsing to prevent errors when loading from multiple threads.

The XIV Stream Deck plugin requires the use of an embedded web server for the purposes of the plugin and interfacing with the Elgato software. As the EmbedIO server is in a different thread (for obvious reasons), data access to sheets may be called from multiple threads. This added lock prevents threads from modifying the RowParser's seek position while reading is taking place.

do you know if this has fixed the issue btw?

i think it's a fair change to make I'm just curious if it has made a difference

KazWolfe (the stream deck plugin dev) posted this example code:
using Lumina;
using Lumina.Data;
using Lumina.Excel.GeneratedSheets;

public class Sandbox {
    private const string GAME_PATH = "H:/Steam/steamapps/common/FINAL FANTASY XIV Online/game/sqpack";
    private static GameData lumina;

    public static bool resume = false;

    public static void Main() {
        lumina = new GameData(GAME_PATH);

        // test retrieving data from a different sheet
        PrintItem101();

        for (int i = 0; i < 5; i++) {
            Thread t = new Thread((seq) => {
                PrintNameForEmote((int) seq + 1);
            });

            t.Start(i);
        }
    }

    private static void PrintNameForEmote(int emoteId) {
        var sheet = lumina.GetExcelSheet<Emote>(Language.English);
        var emote = sheet!.GetRow((uint) emoteId);

        Console.WriteLine($"Emote ID {emoteId} is \"{emote!.Name.RawString}\"");
    }

    private static void PrintItem101() {
        var itemSheet = lumina.GetExcelSheet<Item>(Language.English);
        var item = itemSheet.GetRow(101);

        Console.WriteLine($"Item 101 is \"{item.Name.RawString}\"");
    }
}

which will intermittently produce the issue for me on master, but I have not had any issues in hundreds of runs with this on the thread branch

ah nice, thanks

authors: NotAdam lmcintyre

repo: NotAdam/Lumina

license: WTFPL


text:
[Marker.io] cant see the "X" icon on the card which has long text

Steps to reproduce:

scroll down and  click "You inspire me"
notice the X" icon

Actual result: cannot see the X icon
Expected result:

i think you will have to add the internal scroll on the card for such cases so that user can scroll to see entire text (if it is long) and can also see the "X" icon

Reported by: vinod (vinod@na.studio) - Contact via Marker.io
Source URL: https://wf-b.stg.prezzee.com/en-us/brands
Issue details: Open in Marker.io
Device typedesktopBrowserChrome 130.0.0.0Screen Size1366 x 768OSWindows 10 (10.0.0)Viewport Size1366 x 641Pixel Ratio@1x

still exists

@Druhin13


text:
[Marker.io] buttons are displayed again below the cards when the user scrolls down on the page

Steps to reproduce:

scroll down on the page
notice the buttons below the card tiles again

Actual result:buttons are shown again below the cards
Expected result: they should not see it
https://go.screenpal.com/watch/cZXh11nckE5

Reported by: vinod (vinod@na.studio) - Contact via Marker.io
Source URL: https://na13-prezzee.webflow.io/en-us/use-cases
Issue details: Open in Marker.io
Device typedesktopBrowserChrome 130.0.0.0Screen Size1366 x 768OSWindows 10 (10.0.0)Viewport Size1517 x 712Pixel Ratio@0.8999999761581421x

🤖 Marker.io bot - This issue was marked as ✅ Resolved in Marker.io


text:
Updating .gitignore + Pull Request Template Files.

💡 Motivation, context, additional details, changes proposed

This PR is going to update the .gitignore file and also the Pull Request Template.
✏ Checklist

[X] I've checked my code.
[X] I've tested the change manually.
[ ] I've invoked unit tests: ./gradlew testStagingDebug testStagingDebugUnitTest
[ ] I've invoked instrumentation tests:

🔮 Next steps

📸 Screenshots, GIFs

Maybe GitHub has some issues. This build action run on PR and I also ran it manually now, but still, its status is not updating in PR. Maybe I'll need to deselect Required status checks to pass before merging

Maybe GitHub has some issues. This build action run on PR and I also ran it manually now, but still, its status is not updating in PR. Maybe I'll need to deselect Required status checks to pass before merging

Maybe GitHub has some issues. This build action run on PR and I also ran it manually now, but still, its status is not updating in PR. Maybe I'll need to deselect Required status checks to pass before merging

Will look into this yml also.

authors: hadiyarajesh sumanabhi

repo: NoteXCommunity/note-x


text:
URLs in email confirmation email differ

Hi,
If you register at nuget.org, you need to confirm your email address. Nuget sends you an email for that. Now, I'm an old fart from the old days where you read your email using 'mail' on a shell prompt so I read all my emails in plain text. When I got the confirmation email, I saw this: (url changed to protect the innocent)
https://www.nuget.org/account/confirm/SomeName/uiRHuje67GrebnZIJMFA2 <https://www.nuget.org/account/confirm/SomeName/uiRHuj_e67Grebn_ZIJMFA2>
So I copied the first URL, and it failed with the message it's been expired. Puzzled, I clicked the resend confirmation email link. To my surprise I received a new email with the exact same URL. Of course it still failed. I thought I was going crazy (some might think I'd reached that point many years ago, but let's say I'm sane here), so I again requested an email, same url, same story. The reason I retried the URL was that I thought it might be a problem in the service.
After more than half an hour I realized there were two '_' in the second URL, the one inside the <> characters. Using that URL worked.
Now, for the love of everything that's holy, please, make both URLs the same. Not everyone reads their email in HTML format, some of us like it when the email text they're seeing is the actual email text, stripped from all hiding HTML mess that caused and still causes so much problems in the world.
Thank you.

Seems to be an issue with the Markdown mailer which uses the underscore as italic indicator. That means that either the MarkdownSharp property StrictBoldItalic should be set (which is not accessible from the MarkdownMailer), or the underscore need to be escaped.

Thanks for reporting this - at this time, this doesn't meet our bar.

Wait, someone created a PR for you and you still refuse to fix it, even though the PR fixes it? Why? If it takes weeks to fix something, and you're nearing a deadline, sure, but the fix is right there!

@FransBouma we missed the fact that you had a PR, reactivating.

The PR has been merged into master now

authors: ChrisSfanos FransBouma Niels-V RanjiniM yishaigalatzer

repo: NuGet/NuGetGallery


text:
Update signed package verification information

Addresses: https://twitter.com/brungarc/status/1342208607962726400
/cc @bruno-garcia

Docs Build status updates of commit 7b15b5c:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/reference/Signed-Packages-Reference.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


text:
Implement list_parts for s3s-fs

This PR implement list_parts for the file system crate. I also ended up fixing a bug for the copy_object operation (dst object directory not created)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

CI failed due to fmt and typeck.

CI failed due to typeck.
You can run just dev to check locally.

(thx, I'm on a laptop without rust toolchain atm, this is back-porting some diffs I had before. sorry about the iteration.

authors: Nugine simon-mo


text:
No module named X when using nuitka with setuptools / wheels (setup.cfg vs setup.py)

$ python -m nuitka --version
0.7.5
Commercial: None
Python: 3.10.2 (main, Jan 15 2022, 19:56:27) [GCC 11.1.0]
Flavor: Unknown
Executable: /usr/bin/python
OS: Linux
Arch: x86_64
Distribution: Arch None

How did you install Nuitka and Python
Arch repositories, no venv

pyproject.toml:
[build-system]
requires = ["setuptools>=42", "wheel", "nuitka"]
build-backend = "nuitka.distutils.Build"
setup.cfg:
[metadata]
name = hello
version = 0.0.1
author = Example Author
description = A small example package
long_description = file: README.md
long_description_content_type = text/markdown
classifiers =
Programming Language :: Python :: 3
License :: OSI Approved :: MIT License
Operating System :: Linux
[options]
package_dir =
= src
packages = find:
python_requires = >=3.10
#install_requires =
[options.packages.find]
where = src
[options.entry_points]
console_scripts =
hello = lib.hello:hello_world
ISSUE:
I tried to build a test project with Nuitka and setuptools. I do get a error:
$ hello
Traceback (most recent call last):
File "/home/archie/.local/bin/hello", line 5, in
from lib.hello import hello_world
ModuleNotFoundError: No module named 'lib.hello'
It probably doesn't follow the module imports?
$ ls .local/bin/
hello
$ ls .local/lib/python3.10/site-packages/
build                                  jedi                   psutil                  _yaml
build-0.7.0.dist-info                  jedi-0.18.1.dist-info  psutil-5.9.0.dist-info  yaml
hello-0.0.1.dist-info                  LICENCE                PyYAML-5.4.1.dist-info
hello.cpython-310-x86_64-linux-gnu.so  parso                  xdg
hello.pyi                              parso-0.8.3.dist-info  xdg-5.1.1.dist-info
Here is the testing project:
https://github.com/avlap/setuptools_testing/tree/nuitka
In the manual there is only a example of a setup.py for such a use case:
https://nuitka.net/doc/user-manual.html#use-case-5-setuptools-wheels
Can someone give me pointers on how to make this work with a setup.cfg file?

The thing it is ignoring, not aware of is this:
[options.packages.find]
where = src

Not of the current test cases have that.
Also, not sure what this is supposed to be
[options]
package_dir =
    = src
packages = find:

None of the test cases have a package_dir assignment, either.
Maybe it means the same. Since Nuitka never handles find: but I think only sees package names, it may be necessary that you repeat yourself there or not, will have to test that too.
So it just won't find that. I wonder if this is something akin to a PYTHONPATH, and if Nuitka would have to amend the existing one, or override it. This would of course be easy to add, once the information is found.
If you moved lib to top level, and remove those, it would work. Should be an easy fix to Nuitka, likely even hotfix material to solve this, but needs a bit of research on what to do.

This is working now: https://nuitka.net/doc/factory.html
Let me know if that's working for you, I think I can include it in the next hotfix, even.

The thing it is ignoring, not aware of is this:
[options.packages.find]
where = src

"packages is a list of all Python [import packages](https://packaging.python.org/en/latest/glossary/#term-Import-Package)

that should be included in the [distribution package](https://packaging.python.org/en/latest/glossary/#term-Distribution-Package).
Instead of listing each package manually, we can use the find: directive to automatically discover all packages and
subpackages and options.packages.find to specify the package_dir to use. In this case,
the list of packages will be example_package as that’s the only package present"

https://packaging.python.org/en/latest/tutorials/packaging-projects/

>
> Not of the current test cases have that.
>
> Also, not sure what this is supposed to be
>
> ```
> [options]
> package_dir =
>     = src
> packages = find:
> ```

"package_dir is a mapping of package names and directories. An empty package name represents the “root package” —
the directory in the project that contains all Python source files for the package — so in this case the src directory is
designated the root package."

https://packaging.python.org/en/latest/tutorials/packaging-projects/
>
> None of the test cases have a `package_dir` assignment, either.
>
> Maybe it means the same. Since Nuitka never handles `find:` but I think only sees package names, it may be necessary that you repeat yourself there or not, will have to test that too.
>
> So it just won't find that. I wonder if this is something akin to a `PYTHONPATH`, and if Nuitka would have to amend the existing one, or override it. This would of course be easy to add, once the information is found.
>
> If you moved `lib` to top level, and remove those, it would work. Should be an easy fix to Nuitka, likely even hotfix material to solve this, but needs a bit of research on what to do.

Thanks will do some testing.
I'm fairly new to python and so to packaging, but they move away from setup.py,
at least for the configuring part.

Some resources:
https://packaging.python.org/en/latest/tutorials/packaging-projects/
https://setuptools.pypa.io/en/latest/userguide/declarative_config.html
https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html

It's part of the current hotfix, I am assuming it fixes that. I am not dealing with the dictionary nature of things there, just accepting the root change, which is in the examples, and basically I doubt it matters, and I didn't want to create a test case. Can deal with package_dir as an actual dictionary when real users have that.

Hm could be me, but I can't get this to work.
$ python -m nuitka --version
0.8rc6
Commercial: None
Python: 3.10.2 (main, Jan 15 2022, 19:56:27) [GCC 11.1.0]
Flavor: Unknown
Executable: /usr/bin/python
OS: Linux
Arch: x86_64
Distribution: Arch None
$ hello
Traceback (most recent call last):
File "/home/archie/.local/bin/hello", line 5, in
from hello import hello_world
ImportError: cannot import name 'hello_world' from 'hello' (/home/archie/.local/lib/python3.10/site-packages/hello.cpython-310-x86_64-linux-gnu.so)
https://github.com/avlap/setuptools_testing/tree/nuitka_factory

Yes, could be you, impossible to tell from what you provided, raise a new issue and make sure you use the Nuitka you cite in the build actually.

Got it working, thx.

"If you moved lib to top level, and remove those, it would work. Should be an easy fix to Nuitka, likely even hotfix material to solve this, but needs a bit of research on what to do."
It looks indeed, that it's not working when having a separate lib folder.
I think the whole idea of the new setup.cfg / pyproject.toml mechanism, is that you can keep the same setup (folder tree / module setup), and use different build tools for it. This also would be a ideal scenario for Nuitka I can imagine. It makes it easy for people to switch to Nuitka, having the same setup. I'm a bit surprised that it doesn't seems to work that way at the moment.
Now it seems I've to make one step up in the folder tree to get it build with: python -m nuitka --follow-imports program.py
If I'm right, I think that needs a fix.

authors: avlap kayhayen

repo: Nuitka/Nuitka