Re: GOOPS-less Shepherd
Thanks, makes sense.
Re: GOOPS-less Shepherd
Bodertz writes: > I don't have strong feelings either way, and the change won't really > affect me too much, but what benefit is there in breaking things? From > what I understand from your message, users' configs will stop working in > a few months when 1.0.x releases (or with the macro would "kinda work"), > which is at least a short-term con, so what's the long-term benefit of > this change? Is GOOPS so bad a thing to require? If I understand correctly, that will allow Shepherd to run on GNU Mes, a Scheme interpreter written for Guix bootstraping.
Help wanted: search paths for Erlang and Elixir
Hello, Guixers!
Erlang/OTP has notion of applications [1], they are usually installed in
$PREFIX/lib/erlang/lib in the form of directories named APP-VERSION,
e.g. asn1-5.0.19.
In order for the Erlang runtime to find the installed application it
must appear in the load path. If there is ERL_ROOTDIR in the
environment, erl(1) will search for application directories in
$ERL_ROOTDIR/lib and will add them to the load path. ([2] mentions
$OTPROOT but it's probably an error in the documentation.) The
following will do for Erlang:
(search-path-specification
(variable "ERL_ROOTDIR")
(files '("lib/erlang"))
(separator #f))
However, Elixir usually installs its applications in
$PREFIX/lib/elixir/lib, and $ERL_ROOTDIR cannot contain a list. Thus,
the environment variable ERL_LIBS [2] seems to be the most fitting way
to compose the load path for our purpose.
Is there a way to write a search-path-specification that will only yield
application directories? I could not write such. Listing
$PREFIX/lib/erlang/lib recursively is a bad option, because OTP
application can contain arbitrary resources. And it will probably slow
down modules resolution.
Thanks in advance!
[1]: https://www.erlang.org/doc/man/application.html
[2]: https://www.erlang.org/doc/man/code.html#code-path
Re: [gnome-team] gtk+ on core-updates
Hi Andreas, Andreas Enge writes: > Hello Maxim, > > your gtk+ update on core-updates broke gnome packages since it somehow > moved the bin/ subdirectory from the bin to the out output, so that > gtk-update-icon-cache is not found any more by packages using gtk+:bin > as input. > > Should the split not happen automagically? Maybe this is a deficiency of > the meson build system? I think you or a gnome team member will be much > quicker than me to fix it. I assumed it would happen automagically, like it does for gnu-build-system, but it doesn't. I've rectified this locally for our meson-build-system, I'm building a bunch of packages with the change and if it works, I'll push (probably in a few hours). -- Thanks, Maxim
Re: [RFC] Cosmetic changes to define-configuration usage
Hi Bruno, Bruno Victal writes: > On 2023-03-31 15:46, Maxim Cournoyer wrote:> I have some apprehension > that if we start adding white space between the >> fields here, we'll soon have people adding white space to many other >> places (for consistency or other reasons), which I wouldn't welcome (I >> value compactness, and since in Scheme a single newline is used to >> delimit things at the top level, too much of white space can make things >> less readable in my opinion). > > I don't think it needs to be an all-or-nothing situation, > the spacing rules can be always applied selectively “when it makes sense”. > > I think spaces between fields is consistent with the general way of things, > for instance, throughout Guix, sections that are only scheme code often do > have some spaces here and there that were added without any adherence to some > rigid criteria but the programmer found it to be an adequate point to > partition the logic. > > The same reasoning applies here, the logic partitioning is done per field > instead. > Objectively, there's also a small quantitative difference that's not commonly > present in the rest of the codebase. define-configuration handles both code > and documentation, > or putting it another way, it intersperses code and (rather long) strings. > The result > is that it's particularly information-dense compared to any other part of the > guix codebase. You make convincing arguments. If it's understood that it makes sense in this specific case and not to be taken as "let's add white space to all the records in the Guix code base", I don't oppose the change, if people find it makes a difference for the better in terms of readability. Are there people who would like to block the change? Otherwise, I'll contribute it as-is in a few days. -- Thanks, Maxim
Re: 09/09: lint: Append "/info/refs" to git-reference-url.
Hi Sergey,
Sergey Trofimov writes:
> Maxim Cournoyer writes:
>
>> Hello,
>>
>> guix-comm...@gnu.org writes:
>>
>>> lint: Append "/info/refs" to git-reference-url.
>>>
>> After this fix, I'm now seeing warnings from Github, e.g.:
>>
>> gnu/packages/rails.scm:675:2: ruby-activejob@7.0.4.3: scheduled
>> Software Heritage archival
>> gnu/packages/rails.scm:282:2: ruby-activemodel@7.0.4.3: URI
>> https://github.com/rails/rails/info/refs not reachable: 403
>> ("Forbidden")
>
>
> It seems that the `service=git-upload-pack` is important as it
> switches the protocol to "smart-http".
>
> ~/devel/ext λ curl
> 'https://github.com/sarg/dotfiles/info/refs?service=git-upload-pack'
> 001e# service=git-upload-pack
> Warning: Binary output can mess up your terminal. Use "--output -"
> to tell
> Warning: curl to output it to your terminal anyway, or consider
> "--output
> Warning: " to save to a file.
>
>
> ~/devel/ext λ curl 'https://github.com/sarg/dotfiles/info/refs'
> Please upgrade your git client.
> GitHub.com no longer supports git over dumb-http:
> https://github.com/blog/809-git-dumb-http-transport-to-be-turned-off-in-90-days
>
>
> Maybe the linter should just use `git ls-remote` instead of
> guessing the url?
>
> ~/devel/ext λ git ls-remote https://github.com/sarg/dotfiles
> 7707f77e8d9c11b5435c5901eca45be1a72d2054 HEAD
> 7707f77e8d9c11b5435c5901eca45be1a72d2054 refs/heads/master
That sounds like a better way to me!
--
Thanks,
Maxim
[core-updates] qtbase 6 ssl tests fail.
Hi Guix, on core-updates qtbase 6.3 fails its test suite. The tst_QSslKey group of tests has 122 failures that all look like this: FAIL! : tst_QSslKey::passphraseChecks(DES) '!key.isNull()' returned FALSE. () Loc: [/tmp/guix-build-qtbase-6.3.2.drv-0/qtbase-everywhere-src-6.3.2/tests/auto/network/ssl/qsslkey/tst_qsslkey.cpp(626)] The tst_QSslKey failures are the only tests that fail. I’m currently working on upgrading linphone-desktop (I’ve upgraded all its dependencies already, but haven’t pushed them yet) and the current version needs Qt 6. Is anyone of you working on Qt 6 on core-updates? -- Ricardo
Re: GOOPS-less Shepherd
I don't have strong feelings either way, and the change won't really affect me too much, but what benefit is there in breaking things? From what I understand from your message, users' configs will stop working in a few months when 1.0.x releases (or with the macro would "kinda work"), which is at least a short-term con, so what's the long-term benefit of this change? Is GOOPS so bad a thing to require?
Re: [GSoC 23] distributed substitutes, cost of storage
> Haven't read the Swarm thing, going more off of the general vibe of > these cryptocurrency related projects that keep popping up: > Using some kind of (optional) web of trust for clients makes more sense > to me than making people pay with cryptocurrencies. > > I should be able to set up two computers on a LAN in the middle of > nowhere without having to care about some blockchain's global > consistency. yes, but those are different tasks, solved by different tools. Swarm (and IPFS, and their ilk) solve large-scale cooperation in storing content. and the larger the scale of cooperation, the larger the benefits (redundance, fault tolerance, speed due to automatic caching, etc). > NDN can do this right and has been able to for a while. > Personally, I would try that and other established non-ponzi > technologies first for distributed substitutes. > Not being "permissionless" should not be considered a must have. no, it's not a must have. it's just one more storage backend for storing substitutes -- once an abstraction layer like ERIS is installed. without using ERIS, i wouldn't advocate for adding Swarm as the sole p2p backend integrated into Guix. there are better candidates for such a hypothetical singular position, or even as the first backend to get integrated. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The greatest crimes in the world are not committed by people breaking the rules. It's people who follow orders that drop bombs and massacre villages. As a precaution to ever committing major acts of evil it is our solemn duty never to do what we're told, this is the only way we can be sure.” — Banksy, a graffiti artist from Bristol, 'Wall and Piece'
Re: Fix for librsvg 2.40 on core-updates
--- Original Message --- On Saturday, April 8th, 2023 at 9:52 AM, Andreas Enge wrote: > > > Hello, > > Am Fri, Apr 07, 2023 at 04:53:15PM + schrieb Kaelyn: > > > On core-updates, librsvg-2.40 fails to compile due to a single failing test > > (I've confirmed the failure on x86_64 and i686, though the package is only > > used/needed on non-x86_64 systems for gtk+ and others; it also affects wine > > and wine-staging on x86_64 as they are 32-bit packages). I was able to > > track down the test failure to a text rendering difference between Pango > > 1.48 and 1.50, which led to the text being one pixel line higher between > > the reference and output images. On Monday I submitted > > https://issues.guix.gnu.org/62646 which adds a phase to librsvg-2.40 to > > adjust the output Y coordinate of the SVG transformation matrix by one for > > the failing test so that it passes with Pango 1.50. > > > thanks a lot, I added a copyright line for you and pushed. Thank you! (I often forget the copyright line, so thanks for that as well.) > > Wine still fails to build due to autogen not building on i686: > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts > -DPKGDATADIR=\"/gnu/store/6i60j0fxdsg4qwymas4ymfqlv1azidnc-autogen-5.18.16/share/autogen\" > -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -Wall -Werror > -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow > -Wstrict-prototypes -Wwrite-strings -Wstrict-aliasing=3 -Wextra > -Wno-cast-qual -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -c > libopts.c -fPIC -DPIC -o .libs/libopts_la-libopts.o > In file included from libopts.c:48: > usage.c: In function ‘prt_extd_usage.isra’: > usage.c:736:38: error: ‘s ’ directive output may be truncated writing 2 bytes > into a region of size between 0 and 9 [-Werror=format-truncation=] > 736 | snprintf(vfmt, sizeof(vfmt), vfmtfmt, (unsigned int)nmlen + 4); > | ^~~ > usage.c:736:9: note: ‘snprintf’ output between 9 and 18 bytes into a > destination of size 12 > 736 | snprintf(vfmt, sizeof(vfmt), vfmtfmt, (unsigned int)nmlen + 4); > | ^~ > > Just in case you wish to continue investigating :) I probably will. :) My goal has been to build my home and system profiles from core-updates, including wine64-staging. Cheers, Kaelyn > > Andreas
Re: [GSoC 23] distributed substitutes, cost of storage
> Yes, it is the task of P2P storage system. Is Guix one P2P storage > solution? Or should Guix exploit already implemented P2P storage > systems? i automatically assumed the latter, because p2p storage is a non-trivial task that multiple teams are working to solve, and it's yet to be seen which one will work out in the long run. BTW, due to this it's a good idea to have ERIS between Guix and the various storage backends. a Guix-specific p2p storage solution would be less exposed to abuse initially, but probably not forever. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Heroes are heroes because they are heroic in behavior, not because they won or lost.” — Nassim Taleb (1960–), 'Fooled by Randomness' (2004)
Re: Building more of ‘core-updates’ on ci.guix
Hi Andreas and everyone, Andreas Enge writes: > Ludovic and Chris have corrected a problem in dune.scm in commit >01d9859821c5df6cc76c59e48fddd3c8cfa88ff0 > Now all of core-updates is being built, and the dashboard is back. > Thanks a lot! > > This means that people can now work on repairing their favourite missing > package, while having substitutes available from berlin (there are also > some on bordeaux). Should we organize a code sprint soon to bring the community together and try and get this finally merged? I can take care of sending a mail to guix-devel, as long as we have enough helping hands for the fateful day(s). If so, would next week-end (15-16 april) work? Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging
Hi Andreas, Andreas Enge writes: > Am Fri, Apr 07, 2023 at 05:24:41PM -0400 schrieb Maxim Cournoyer: >> Reviewing the list of newly broken things, there was a flaky test spot >> in python-pyopenssl (IIRC!) that led me to attempt to upgrade >> python-cryptography, which is a bit more involved than I'd like. > > Okay, so I cherry-picked your staging commits for extra-cmake-modules > and kcodecs to core-updates, which should bring us further in building KDE > (once gtk+ is sorted out). Is gtk+@3 not sorted out? I have it built on my machine. gtk@4 is also available from bordeaux. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guidelines for pre-trained ML model weight binaries (Was re: Where should we put machine learning model parameters?)
>From my point of view, the tackle of such biased weights is not via re-learning because how to draw the line between biased weights, mistakes on their side, mistakes on our side, etc. and it requires a high level of expertise to complete a full re-learning. This strikes me as similar to being in the 80s, when Stallman was writing the GPL, years before Nix was invented, and saying "the solution to backdoors in executables is not access to source code due to the difficulty of compiling from scratch for the average user and due to the difficulty of making bit-reproducible binaries." Like, bit reproducibility WAS possible, it was just difficult, so practically speaking users had to use distro binaries they couldn't fully trust. So some of the benefits of the source code being available were rather theoretical for a while. So this argument strikes me as pre-emptively compromising one's principles based on the presumption that a new technology will never come along that allows one to practically exploit the benefits of said principles. >Instead, it should come from the ML community that should standardize formal methods for verifying that the training had not been biased, IMHO. What "formal methods" for that are known? As per the article, the hiding of the backdoor in the "whitebox" scenario is cryptographically secure in the specific case, with that same possibility open for the general case. On Fri, Apr 7, 2023 at 5:53 AM Simon Tournier wrote: > > Hi, > > On ven., 07 avril 2023 at 00:50, Nathan Dehnel wrote: > > > I am uncomfortable with including ML models without their training > > data available. It is possible to hide backdoors in them. > > https://www.quantamagazine.org/cryptographers-show-how-to-hide-invisible-backdoors-in-ai-20230302/ > > Thanks for pointing this article! And some non-mathematical part of the > original article [1] are also worth to give a look. :-) > > First please note that we are somehow in the case “The Open Box”, IMHO: > > But what if a company knows exactly what kind of model it wants, > and simply lacks the computational resources to train it? Such a > company would specify what network architecture and training > procedure to use, and it would examine the trained model > closely. > > And yeah there is nothing new ;-) when one says that the result could be > biased by the person that produced the data. Yeah, we have to trust the > trainer as we are trusting the people who generated “biased” (*) genomic > references. > > Well, it is very interesting – and scary – to see how to theoretically > exploit “misclassify adversarial examples“ as described e.g. by [2]. > > This raises questions about “Verifiable Delegation of Learning”. > > From my point of view, the tackle of such biased weights is not via > re-learning because how to draw the line between biased weights, > mistakes on their side, mistakes on our side, etc. and it requires a > high level of expertise to complete a full re-learning. Instead, it > should come from the ML community that should standardize formal methods > for verifying that the training had not been biased, IMHO. > > 2: https://arxiv.org/abs/1412.6572 > > (*) biased genomic references, for one example among many others: > > Relatedly, reports have persisted of major artifacts that arise > when identifying variants relative to GRCh38, such as an > apparent imbalance between insertions and deletions (indels) > arising from systematic mis-assemblies in GRCh38 > [15–17]. Overall, these errors and omissions in GRCh38 introduce > biases in genomic analyses, particularly in centromeres, > satellites, and other complex regions. > > https://doi.org/10.1101/2021.07.12.452063 > > > Cheers, > simon
Re: Fix for librsvg 2.40 on core-updates
Hello, Am Fri, Apr 07, 2023 at 04:53:15PM + schrieb Kaelyn: > On core-updates, librsvg-2.40 fails to compile due to a single failing test > (I've confirmed the failure on x86_64 and i686, though the package is only > used/needed on non-x86_64 systems for gtk+ and others; it also affects wine > and wine-staging on x86_64 as they are 32-bit packages). I was able to track > down the test failure to a text rendering difference between Pango 1.48 and > 1.50, which led to the text being one pixel line higher between the reference > and output images. On Monday I submitted https://issues.guix.gnu.org/62646 > which adds a phase to librsvg-2.40 to adjust the output Y coordinate of the > SVG transformation matrix by one for the failing test so that it passes with > Pango 1.50. thanks a lot, I added a copyright line for you and pushed. Wine still fails to build due to autogen not building on i686: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts -DPKGDATADIR=\"/gnu/store/6i60j0fxdsg4qwymas4ymfqlv1azidnc-autogen-5.18.16/share/autogen\" -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -Wall -Werror -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Wstrict-aliasing=3 -Wextra -Wno-cast-qual -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -c libopts.c -fPIC -DPIC -o .libs/libopts_la-libopts.o In file included from libopts.c:48: usage.c: In function ‘prt_extd_usage.isra’: usage.c:736:38: error: ‘s ’ directive output may be truncated writing 2 bytes into a region of size between 0 and 9 [-Werror=format-truncation=] 736 | snprintf(vfmt, sizeof(vfmt), vfmtfmt, (unsigned int)nmlen + 4); | ^~~ usage.c:736:9: note: ‘snprintf’ output between 9 and 18 bytes into a destination of size 12 736 | snprintf(vfmt, sizeof(vfmt), vfmtfmt, (unsigned int)nmlen + 4); | ^~ Just in case you wish to continue investigating :) Andreas
Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging
Am Fri, Apr 07, 2023 at 05:24:41PM -0400 schrieb Maxim Cournoyer: > Reviewing the list of newly broken things, there was a flaky test spot > in python-pyopenssl (IIRC!) that led me to attempt to upgrade > python-cryptography, which is a bit more involved than I'd like. Okay, so I cherry-picked your staging commits for extra-cmake-modules and kcodecs to core-updates, which should bring us further in building KDE (once gtk+ is sorted out). Andreas
[gnome-team] gtk+ on core-updates
Hello Maxim, your gtk+ update on core-updates broke gnome packages since it somehow moved the bin/ subdirectory from the bin to the out output, so that gtk-update-icon-cache is not found any more by packages using gtk+:bin as input. Should the split not happen automagically? Maybe this is a deficiency of the meson build system? I think you or a gnome team member will be much quicker than me to fix it. Andreas
