@trofi One open question I had, is that it seems all downstream users of poco now need utf8proc as a dependency. At what point should this become part of the propagatedBuildInputs? I haven't been able to find any enlightening documentation on that topic yet, so I would love some advice.

Sorry, forgot to mark it as draft immediately, as there are still some dependents I haven't gotten around to fixing.

Upstream bug reports I've already opened for this:

• Fix Pothos build with poco 1.14.1
• Fix poco when building with pkgsStatic.poco
• Fix craftos-pc to build with poco 1.14.1
• Fix collabora-online build with poco 1.14.1 -> Pull Request

@trofi One open question I had, is that it seems all downstream users of poco now need utf8proc as a dependency. At what point should this become part of the propagatedBuildInputs? I haven't been able to find any enlightening documentation on that topic yet, so I would love some advice.

The typical use case for propagatedBuildInputs is when a .dev output requires another .dev output. That could happen if poco's public headers use public headers of utf8string or installed poco's .pc file refers utf8string .pc files. I think it's a natural effect of fixed unbundling.

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 383163

x86_64-linux

The typical use case for propagatedBuildInputs is when a .dev output requires another .dev output. That could happen if poco's public headers use public headers of utf8string or installed poco's .pc file refers utf8string .pc files. I think it's a natural effect of fixed unbundling.

Looking at the dev derivation of poco I see that there are cmake files to find utf8proc:

❯ rg utf8proc  /nix/store/67f3dgynfwmhj4a02l4zvvd4dlhmaf72-poco-1.14.1-dev/
/nix/store/67f3dgynfwmhj4a02l4zvvd4dlhmaf72-poco-1.14.1-dev/lib/cmake/Poco/FindUtf8Proc.cmake
5:# Find utf8proc
20:#      UTF8PROC_INCLUDE_DIR - where to find utf8proc.h
21:#      UTF8PROC_LIBRARY     - the utf8proc library
39:    UTF8PROC_INCLUDE_DIR NAMES utf8proc.h DOC "The utf8proc include directory"
43:    UTF8PROC_LIBRARY NAMES utf8proc DOC "The utf8proc library"

I don't understand enough cmake however to deduce if that means all users of poco auto require this?

I'm also not quite sure if you say that this should mean utf8proc should be a propagated dependency? For example litebrowser does not seem to require it? It may however get it propagated from another input. How would I find that out?

The typical use case for propagatedBuildInputs is when a .dev output requires another .dev output. That could happen if poco's public headers use public headers of utf8string or installed poco's .pc file refers utf8string .pc files. I think it's a natural effect of fixed unbundling.

Looking at the dev derivation of poco I see that there are cmake files to find utf8proc:

❯ rg utf8proc  /nix/store/67f3dgynfwmhj4a02l4zvvd4dlhmaf72-poco-1.14.1-dev/
/nix/store/67f3dgynfwmhj4a02l4zvvd4dlhmaf72-poco-1.14.1-dev/lib/cmake/Poco/FindUtf8Proc.cmake
5:# Find utf8proc
20:#      UTF8PROC_INCLUDE_DIR - where to find utf8proc.h
21:#      UTF8PROC_LIBRARY     - the utf8proc library
39:    UTF8PROC_INCLUDE_DIR NAMES utf8proc.h DOC "The utf8proc include directory"
43:    UTF8PROC_LIBRARY NAMES utf8proc DOC "The utf8proc library"

I don't understand enough cmake however to deduce if that means all users of poco auto require this?

I'm also not quite sure if you say that this should mean utf8proc should be a propagated dependency?

utf8proc installs a single utf8proc.h header and utf8proc library.

Let's see if any headers are directly user by poco:

$ nix build github:NixOS/nixpkgs/pull/383163/merge#poco.dev

$ fgrep -R utf8proc.h result-dev/
result-dev/lib/cmake/Poco/FindUtf8Proc.cmake:#      UTF8PROC_INCLUDE_DIR - where to find utf8proc.h
result-dev/lib/cmake/Poco/FindUtf8Proc.cmake:    UTF8PROC_INCLUDE_DIR NAMES utf8proc.h DOC "The utf8proc include directory"

Looks like poco itself does not use it as is. But it installs FindUtf8Proc.cmake which other projects might use via find_package(UTF8Proc) (or something like that, my cmake is weak). If any of them does then adding utf8proc to propagatedBuildInputs sounds like a reasonable thing to do. It's a small depend anyway.

For example litebrowser does not seem to require it? It may however get it propagated from another input. How would I find that out?

I would query the derivation graph:

$ nix-store --query --graph $(nix-instantiate -A litebrowser) |& fgrep utf8

Does not seem to contain utf8proc in the closure (it's against nixpkgs/master).

@trofi Running this command after I've built litebrowser on this branch, I get this result:

❯ nix-store --query --graph (nix-instantiate -A litebrowser --system aarch64-linux) &| rg utf8
warning: you did not specify '--add-root'; the result might be removed by the garbage collector
"kq1w8y2ciyqxkz59x8xqisnc8yvd817w-utf8proc-2.10.0.drv" -> "fv4ay05c9hn3ip9y9jdrwjn3c80hj2pj-poco-1.14.1.drv" [color = "magenta"];
"kq1w8y2ciyqxkz59x8xqisnc8yvd817w-utf8proc-2.10.0.drv" [label = "utf8proc-2.10.0.drv", shape = box, style = filled, fillcolor = "#ff0000"];
"81lwjm4ijn2vz1wim8b96m83a3la88l3-bash-5.2p37.drv" -> "kq1w8y2ciyqxkz59x8xqisnc8yvd817w-utf8proc-2.10.0.drv" [color = "black"];
"gc2x3v0z9y5rm72lbjbbkdvqdcp8zang-stdenv-linux.drv" -> "kq1w8y2ciyqxkz59x8xqisnc8yvd817w-utf8proc-2.10.0.drv" [color = "red"];
"mphxjjp4jjgyq2mh28wxz01iw12dpcmd-source.drv" -> "kq1w8y2ciyqxkz59x8xqisnc8yvd817w-utf8proc-2.10.0.drv" [color = "green"];
"rjlqmzx73qzik0rpj44hc6dp6s4blpq0-cmake-3.31.3.drv" -> "kq1w8y2ciyqxkz59x8xqisnc8yvd817w-utf8proc-2.10.0.drv" [color = "blue"];
"shkw4qm9qcw5sc5n1k5jznc83ny02r39-default-builder.sh" -> "kq1w8y2ciyqxkz59x8xqisnc8yvd817w-utf8proc-2.10.0.drv" [color = "magenta"];
"vj1c3wf9c11a0qs6p3ymfvrnsdgsdcbq-source-stdenv.sh" -> "kq1w8y2ciyqxkz59x8xqisnc8yvd817w-utf8proc-2.10.0.drv" [color = "burlywood"];

Does that mean that indeed litebrowser does contain utf8proc here?

@trofi Running this command after I've built litebrowser on this branch, I get this result:

❯ nix-store --query --graph (nix-instantiate -A litebrowser --system aarch64-linux) &| rg utf8
"kq1w8y2ciyqxkz59x8xqisnc8yvd817w-utf8proc-2.10.0.drv" -> "fv4ay05c9hn3ip9y9jdrwjn3c80hj2pj-poco-1.14.1.drv" [color = "magenta"];

Does that mean that indeed litebrowser does contain utf8proc here?

No, it only means that poco now depends on utf8proc. What fails if you don't add it? litebrowser? And how does it fail?

The build succeeds, but I wasn't able to test it (haven't gotten around to setting up a non headless nix that can forward ui to me yet).

@trofi: litebrowser works fine without adding utf8proc as a dependency. Does that prove that utf8proc should not be a propagatedBuildInput?

@trofi Regarding the failure of collabora-online, as far as I can determine, that is actually a failure of libreoffice-collabora, which is currently broken on master. See:

nix build --system aarch64-linux github:NixOS/nixpkgs/master#libreoffice-collabora --print-build-logs
nix build --system x86_64-linux github:NixOS/nixpkgs/master#libreoffice-collabora --print-build-logs

Is that something that should stop this getting merged?

@trofi: litebrowser works fine without adding utf8proc as a dependency. Does that prove that utf8proc should not be a propagatedBuildInput?

I'd say it's fine to not include it to propagatedBuildInput until we have an evidence of at least one package needing it.

@trofi Regarding the failure of collabora-online, as far as I can determine, that is actually a failure of libreoffice-collabora, which is currently broken on master. See:

nix build --system aarch64-linux github:NixOS/nixpkgs/master#libreoffice-collabora --print-build-logs
nix build --system x86_64-linux github:NixOS/nixpkgs/master#libreoffice-collabora --print-build-logs

Is that something that should stop this getting merged?

I would say this should not be blocking this PR merge to master.

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 383163

x86_64-darwin

aarch64-darwin

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 383163

aarch64-linux

Not sure why, but my x86 builds keep failing because pkg-config and ld explode at unfortunate moments. Seems my Rosetta is acting up. :/

@trofi Is there anything else you would require to get this pull request merged? I would love some feedback.

@dwt It looks good to me. Note that I'm not a nixpkgs committer and can't merge any PRs.

Pinging Maintainers of the touched packages, to help me get this merged:

• poco: @orivej, @tomodachi94
• pothos: none
• craftos-pc: @siraben, @tomodachi94
• collabora-online: @xzfc
• mumble: @felixsinger, @Lilacious
• multipass: @jnsgruk

Changes to Poco and CraftOS-PC lgtm, with the added note that the patch should probably be submitted upstream (the upstream maintainer generally appreciates patches like this, that fix compatibility with bleeding-edge versions of libraries and the like).

• Poco: Already upstream, that's why I was able to use fetchpatch in the derivation
• craftos-pc: linked in the derivation

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/2274

@xzfc @siraben @Lilacious Friendly ping - do you have any input on this merge request?

Friendly note to maintainers with commit bit - this pull request is currently blocking my work on porting Mumble to Darwin. As far as I can see this pull request is fully reviewed and accepted.

Am I missing something?

Of course ne upstream package (collabora-online) is broken, but that was broken before this pull request, so nothing I can do about that here.

LGTM, thanks for your work on this!

utf8proc is an unconditional dependency of Poco Foundation and should be added to propagatedBuildInputs, see: pocoproject/poco@b380b57. Note how utf8proc is pulled in alongside pcre2 and zlib, which are both already propagated.

litebrowser only builds successfully because doesn't actually depend on Poco at all anymore, see: litehtml/litebrowser-linux@3741882

The other packages touched by this PR that depend on Poco but build without utf8proc do so because they don't use CMake to find Poco. This works because utf8proc is not part of the Poco public API, and therefore probably shouldn't be part of the CMake link interface, but this is an upstream Poco issue and we should still propagate utf8proc because this is what upstream expects.

edit: it looks like this applies to the PCRE2 and zlib dependencies as well and an upstream fix could allow us to get rid of propagation for these too.

#399346