ation: zfs-auto-snapshot
doesn't depend on any specific kernel versions, but zfs itself does. For
example, zfs 2.2.3 supports up to kernel 6.7, and zfs 2.2.4 supports up to
kernel 6.8 (ref: https://github.com/openzfs/zfs/releases). I suspect zfs is
failing to build with the default kernel as a depend
ences to pango (which is what
makes me think the pango propagated-input is needed elsewhere, and not actually
in librsvg--but I also don't know Rust or what dependencies the rust code in
librsvg has).
Cheers,
Kaelyn
> This blocks further progress
>
> What builds so far:
>
> - gcc-to
te paths e.g. under /usr and Guix executable
paths generally don't match the patterns checked for.
Cheers,
Kaelyn
> Stay safe!
> Reza
>
> [1] https://www.openwall.com/lists/oss-security/2024/03/29/4
> [2] https://access.redhat.com/security/cve/cve-2024-3094#cve-cvss-v3
ng of ML model
training is that it cannot maintain enough of a trace between GPLed input code
and its (modified) use in the output to maintain the licensing and distribution
requirements from either the GPL 3 sections above or the GPL 2 sections 2 and
3. I also believe that section 4 of the GPL 2 directly applies to these LLM
code models.
There is also the potential licensing issues of mixing (potentially)
incompatible licenses in the training data sets, such as GPL and CDDL code,
with no way to distinguish or separate the (arguably) modified sources from
each.
Just my $0.02 USD on the LLM side of matter, as much of the discussion seems to
be around the cost vs benefit of rewriting the git history for updating
personally identifying information.
Cheers,
Kaelyn
>
> Cheers,
> simon
On Monday, January 29th, 2024 at 9:49 AM, John Kehayias
wrote:
>
>
> Hi Kaeylyn,
>
>
> On Monday, January 29th, 2024 at 12:26 PM, Kaelyn kaelyn.al...@protonmail.com
> wrote:
>
> > Hi Efraim and guix-devel,
> >
> > Based on my lo
o I wanted to bring it to
folks' attention since the failure appears to affect a great many packages (I
noticed it in an ffmpeg build failure on my local cuirass instance).
Cheers,
Kaelyn
). I wanted to bump this 2+ week old
update to wine-staging since dxvk is the only dependent on wine-staging and it
does not currently build (and the QA status of bug #66936 is still "Pending").
Cheers,
Kaelyn
On Saturday, December 9th, 2023 at 10:11 AM, Kaelyn Takata
wrote:
ut please chime in. If I
> don't hear anything too urgent I'll update the mesa-updates branch to
> start builds at least. I've also cc'ed some names I think will be
> knowledgeable about some current branches.
>
> And thanks to Kaelyn (also cc'ed) for the pending xwayland patches!
Hi,
On Tuesday, November 14th, 2023 at 12:36 PM, Kaelyn
wrote:
>
> Hi John,
>
> On Tuesday, November 14th, 2023 at 12:11 PM, John Kehayias
> john.kehay...@protonmail.com wrote:
>
> > Hi Kaelyn,
> >
> > On Sun, Nov 12, 2023 at 08:01 PM, Kaelyn wrote:
&
mage (with
grub-install once again being sufficient in 2.12rc1), though I don't know if
the Guix bootloader machinery addresses that shortcoming or not.
Please take the above with a grain of salt, as I have only ever used LUKS1 with
Grub (and I've recently started moving away from Grub). HTH!
Che
server" reports 125 rebuilds. I also checked
and the update to xorg-server does not appear to alter the derivation for the
xorg-server-for-tests (which is still at version 21.1.1).
Cheers,
Kaelyn
Hi John,
On Tuesday, November 14th, 2023 at 12:11 PM, John Kehayias
wrote:
>
> Hi Kaelyn,
>
> On Sun, Nov 12, 2023 at 08:01 PM, Kaelyn wrote:
>
> > Hi,
> >
> > I've just submitted a pair of patches for the mesa-updates branch:
> > https://issue
ebuilt), but required to update to the latest xwayland as xwayland requires a
newer version of presentproto than in the current guix xorgproto package. The
updating and ungrafting of mesa and a number of X.org related libraries seemed
like a good time (and place) to update xorgproto as well.
Cheers,
Kaelyn
Chromium, Firefox,
and Icecat based on the packaged install_host_app.sh script (note: I have only
used it with Icecat).
Cheers,
Kaelyn
> >
> > ./pre-inst-env guix show passff-host
> > name: passff-host
> > version: 1.2.3
> > outputs:
> > + out: everything
s)
In my opinion the second option is probably the easiest and safest to work
with. #1 and #3 both suffer from needing to specially craft the incoming
argument to handle being evaluated twice. For #1, the argument has to be a list
after being evaluated twice (the first evaluation is of the
byte prefix (counting the dash), 255 chars is still quite a bit.
Specifically, the extracted quote above--without the "> " prefixes and with
line breaks treated as single characters--is exactly 255 characters. (I find a
bit of readable text to be helpful for wrapping my brain arou
y) are often visually
identical but programmatically distinct. If not handled well, it could
lead to untypable package or store names by virtue of the user having to
guess which Unicode code point(s) is/are the correct one(s) for a certain
visual glyph.
Cheers,
Kaelyn
[1] https://en.wikipedia.org/wik
m 650KB/s to 3+MB/s. Below are my results,
along with a 4th result downloading a kernel tarball from kernel.org which
shows a more typical speed for me.
Cheers,
Kaelyn
$ wget -O/dev/null
https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.
guix.gnu.org/cookbook/en/html_node/Guix-Profiles-in-Practice.html.
On a different tack, if you have no issue with installing all of the packages
you need in a single profile using a manifest, and you'd like a way of managing
at least some of your home configuration (shell aliases, simple c
tories, and run each "/gnu/store/*-profile/etc/profile"?
This is a very bad idea, as many or most of those "/gnu/store/*-profile"
directories are different generations of the same profile, and sourcing them
all would result in many conflicts and other trouble
s, but my
rule of thumb is that if the package depends on and is linking to a library
then the library package is an input, and if the dependency is a program that
needs to be run as part of the build (such as the rustscan package trying to
run perl and python3) it should be a native-input. HTH!
Cheers,
Kaelyn
Hi,
--- Original Message ---
On Tuesday, May 9th, 2023 at 4:51 AM, John Kehayias
wrote:
>
> Hello,
>
> On Tue, Apr 25, 2023 at 04:40 PM, Kaelyn wrote:
>
> > Hi,
> >
> > --- Original Message ---
> > On Tuesday, April 25th, 2023 at 2:15
--- Original Message ---
On Friday, May 5th, 2023 at 8:59 PM, John Kehayias
wrote:
>
>
> Hi Kaelyn,
>
> On Thu, May 04, 2023 at 11:45 PM, Kaelyn wrote:
>
> > --- Original Message ---
> > I wasn't sure the best place to share it, so I'v
t;) in place of "gcc:lib". Internally it resolves package strings
> > to packages with specification->package, then passes the package and
> > optional output specifier to package->manifest-entry. But I digress a
> > little...
>
>
> Nice little hack
lutions, I would prefer to have libstdc++ in it's own package or
output rather than bundled into gcc-toolchain:out; it feels messy and against
the grain of isolating programs in containers if I have to make the gcc and g++
compilers available in the container in order to run a program that needs
libstdc++.
Cheers,
Kaelyn
Hi,
--- Original Message ---
On Tuesday, April 25th, 2023 at 2:15 PM, Andreas Enge wrote:
>
>
> Hello Kaelyn,
>
> thanks for your research!
You're welcome! :)
> Am Wed, Apr 19, 2023 at 04:07:51PM +0000 schrieb Kaelyn:
>
> > * https://issues.guix.gnu.o
--- Original Message ---
On Wednesday, April 19th, 2023 at 3:26 PM, Andreas Enge wrote:
>
>
> Hello,
>
> thanks for bringing this back to our attention!
You're welcome! :)
>
> Am Wed, Apr 19, 2023 at 02:41:57PM + schrieb Kaelyn:
>
> > While I
ging
includes a similar phase for fixing the layer object path in its layer
manifest.)
Thanks,
Kaelyn
--- Original Message ---
On Sunday, April 16th, 2023 at 5:06 PM, Andreas Enge wrote:
>
>
> Am Sat, Apr 15, 2023 at 06:25:52PM + schrieb Kaelyn:
>
> > I tried to update the package definition to be able to build from git but
> > it became a much bigger
--- Original Message ---
On Saturday, April 15th, 2023 at 4:37 PM, Kaelyn
wrote:
>
>
> Hi,
>
> --- Original Message ---
> On Saturday, April 15th, 2023 at 10:43 AM, Andreas Enge andr...@enge.fr wrote:
>
> > Am Fri, Apr 14, 2023 at 08:51:18PM -0
are seeing. It looks like
https://gitlab.com/gnuwget/wget/-/merge_requests/31 was merged to fix the issue
about a month after 1.21.3 was released (I haven't tested yet since the package
definition downloads a release tarball instead of building from git).
Cheers,
Kaelyn
dist_patch_DATA): Register it.
> ---
> Hey Andreas and Kaelyn,
>
> This should also fix it without bumping python-pytest to a new version (since
> it
> has so many dependents, don't want to introduce new breakage now).
>
> Best,
> Josselin
>
> gnu/local.mk | 1 +
> gnu/p
abling TestKind.test_all for armhf might not be needed, but
the Gentoo package definition suggests the huge array test will fail for armhf
as well).
Cheers,
Kaelyn
>
> Andreas
Hi,
--- Original Message ---
On Wednesday, April 12th, 2023 at 9:31 PM, Andreas Enge wrote:
>
>
> Hello,
>
> Am Wed, Apr 12, 2023 at 04:11:58PM + schrieb Kaelyn:
>
> > For the actual failures in python-numpy[2]:
>
>
> you could always try
ct
values for objects coming from Fortran code. Perhaps a type size mismatch for
32-bit platforms, but hard for me to say since I don't know Fortran and I
haven't had luck finding other reports of that test failing.
Cheers,
Kaelyn
[1] https://ci.guix.gnu.org/build/843194/details
[2] https://ci.gu
--- Original Message ---
On Saturday, April 8th, 2023 at 3:55 PM, Kaelyn
wrote:
>
> --- Original Message ---
> On Saturday, April 8th, 2023 at 9:52 AM, Andreas Enge andr...@enge.fr wrote:
>
>
>
> > Hello,
> >
> > Am Fri, Apr 07, 202
--- 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
> &g
the output Y coordinate of the SVG
transformation matrix by one for the failing test so that it passes with Pango
1.50.
Cheers,
Kaelyn
the standard "strtof"/"strtod"/"strtold" conversion functions), the function
returns a double value. Depending on the specific code, it could be
encountering inconsistencies comparing a double to a float (non-double)
constant due to the difference in types' precision.
Cheers,
Kaelyn
>
> Kind regards
> Felix
version on a small Cuirass server I've set up so
that I could update the system to versions of Guix newer than late January, and
have confirmed the graphs display properly again with the newer Zabbix release.
Cheers,
Kaelyn
[1] https://support.zabbix.com/browse/ZBXNEXT-8204
[2] https
--- Original Message ---
On Saturday, March 18th, 2023 at 8:56 AM, Andreas Enge wrote:
>
>
> Hello,
>
> Am Fri, Mar 17, 2023 at 08:43:13PM + schrieb Kaelyn:
>
> > I'm at least a little in favor of that, as the commit message for
> > cc56be2f38
Hi Felix and Andreas,
--- Original Message ---
On Friday, March 17th, 2023 at 8:27 PM, Felix Lechner
wrote:
>
>
> Hi Andreas and Kaelyn,
>
> On Fri, Mar 17, 2023 at 1:18 PM Kaelyn kaelyn.al...@protonmail.com wrote:
>
> > sorry about "git am" not
--- Original Message ---
On Friday, March 17th, 2023 at 8:01 PM, Andreas Enge wrote:
>
> Am Wed, Mar 15, 2023 at 05:59:12PM + schrieb Kaelyn:
>
> > 1) glib-networking has a 32-bit-only patch left over from the upgrade from
> > 2.70.0 to 2.72.2, which d
her data is flowing out of berlin to the build node?
You may be able to use jnettop to see the network streams (it does need
superuser privileges to run). Not sure how readable/useful it might be if
berlin has a lot of active connections, though.
HTH,
Kaelyn
>
> Andreas
xception:
%exception #< program: "make" arguments: ("partcheck" "-j" "12"
"prefix=/gnu/store/xr6s773c3d62g9aynydp1h6231p42ixn-libaio-0.3.113" "CC=gcc")
exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 0.3 seconds
-potr is listed as an optional dependency in poezio's setup.py (for its
OTR plugin).
Cheers,
Kaelyn
>
> Andreas
sounds like a patch applied to multiple existing release branches, with
openjdk@14 and @16 being at older point releases from prior to the patch being
applied upstream.
HTH! (And I apologize for the noise if not!)
Cheers,
Kaelyn
> Well, in @17, @18 and @19 the patch seems to be definitely integrated
> into the source code.
>
> Andreas
--- Original Message ---
On Tuesday, February 14th, 2023 at 8:29 PM, Kaelyn
wrote:
>
> --- Original Message ---
> On Tuesday, February 14th, 2023 at 2:50 PM, Efraim Flashner
> efr...@flashner.co.il wrote:
>
> [snip]
>
> > I ended up going a differe
--- ##
Failed tests:
GNU tar 1.34 test suite test groups:
NUM: FILE-NAME:LINE TEST-GROUP-NAME
KEYWORDS
151: time01.at:20 time: tricky time stamps
time time01
Cheers,
Kaelyn
>
> --
> Efraim Flashner efr...@flashner.co.il אפרים פלשנר
>
>
--- Original Message ---
On Monday, February 13th, 2023 at 8:04 PM, Efraim Flashner
wrote:
>
>
> On Sun, Feb 12, 2023 at 06:29:04PM +0000, Kaelyn wrote:
>
> > Hi,
> >
> > --- Original Message ---
> > On Sunday, February 12th, 2023 at 5
c/file -C -m magic
/tmp/guix-build-file-5.44.drv-0/file-5.44/src/.libs/file: symbol lookup error:
/gnu/store/s4yd6ibxsh5q1j9ipygb9vpjj4g00wc9-glibc-mesboot-2.16.0/lib/libpthread.so.0:
undefined symbol: h_errno, version GLIBC_PRIVATE
make[2]: *** [Makefile:863: magic.mgc] Error 127
Cheers,
Ka
e. If your terminal can't show
> these characters and you have a UTF-8 locale (you'd run echo $LANG to
> know that), please report your config (name of terminal app, locale,
> fonts, …)!
I can see those characters in both xfce4-terminal and kitty.
Cheers,
Kaelyn
Hi Guix devs,
Now that it's been a couple of months, I wanted to bump my core-updates patch
to Mesa which fixes the library paths in Mesa's Vulkan layer manifest files
(https://issues.guix.gnu.org/59453). The patch also resolves
https://issues.guix.gnu.org/58251.
Cheers,
Kaelyn
at-patch/send-email to achieve that though.
On a side note, I'd recently discovered the flag to pass. To have a subject
prefix like "[PATCH core-updates]" (as mentioned in the manual for staging and
core-updates patches) instead of the default "[PATCH]", one can pass
"--subject-prefix="PATCH core-updates" to git format-patch.
Cheers,
Kaelyn
>
> 1: https://issues.guix.gnu.org/55227
h" "no matching pattern" ())'.
> ٭٭
I believe the build fails because the guile-build-system deletes the 'check
phase. From guix/build/guile-build-system.scm:
(define %standard-phases
(modify-phases gnu:%standard-phases
(delete 'bootstrap)
(delete 'configure)
(add-before 'install-locale 'set-locale-path
set-locale-path)
(replace 'build build)
(add-after 'build 'install-documentation
install-documentation)
(delete 'check)
(delete 'strip)
(delete 'validate-runpath)
(delete 'install)))
Hope that helps!
Cheers,
Kaelyn
>
>
> Thanks in advance.
>
>
> ---
> Luis Felipe López Acevedo
> https://luis-felipe.gitlab.io/
ch=version-1.4.0 -- system reconfigure
>
> but then I do not know how it goes for switching back.
I've not tried guix time-machine to reconfigure a system, but once it is done,
the same "guix system roll-back" should work for switching back to your
previous system generation (pre-1.4.0-branch).
HTH!
Cheers,
Kaelyn
>
> Cheers,
> simon
r the file-wide option in the future for
transformations that wouldn't work on a per-package basis, e.g. cleaning up
unused module imports).
Cheers,
Kaelyn
rministic order imposed on them to get import
results that are consistent across systems. HTH!
Cheers,
Kaelyn
On Tuesday, June 7th, 2022 at 10:42 AM, Kaelyn
wrote:
[snip]
> > > I just took a few minutes and checked both repos out into a single
> > > working tree, and there aren't many commits unique to each
> > > repository. The official savannah repo has 5 commits since they
Hi Ludo'
Sorry for taking a while to send a reply!
On Monday, May 30th, 2022 at 8:33 AM, Ludovic Courtès wrote:
> Hello Kaelyn,
>
> Kaelyn kaelyn.al...@protonmail.com skribis:
>
> > > First, we need to cherry-pick relevant commits from gitlab.com. Any
> > > tak
Hello Gio'
On Thursday, May 26th, 2022 at 8:01 AM, Giovanni Biscuolo
wrote:
> Hello Kaelyn and Ludo'
>
> thank you for your help!
>
> Kaelyn kaelyn.al...@protonmail.com writes:
>
>
> [...]
>
> > > First, we need to cherry-pick relevant commits from
(file-system
(mount-point "/gnu")
(device "/dev/mapper/cryptroot1")
(type "btrfs")
(check? #f)
(options "compress=zstd,subvol=@gnu_store")
(dependencies (cons rootfs mapped-
` with `system`:
While `system` may not show the problem that `system*`, note that they aren't
strictly interchangeable. To quote
https://www.gnu.org/software/guile/manual/html_node/Processes.html#index-system_002a:
"system* is similar to system, but accepts only one string per-argument, and
pe
age-use-name-at-point' variable (12 months ago)
* e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months
ago)
* 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3
months ago)
* fbc2bbc - elisp/ui-package: Use thing at point for 'guix-packages-by-name'
co
) Using config file:
"/gnu/store/w1zvqxc4vzkifpjrs07is7qs3h3x3g1x-xserver.conf"
[30.068] (++) Using config directory:
"/gnu/store/srgk57icx1mv689ildw2937ik6pyw9q3-xorg.conf.d"
[30.068] (==) Using system config directory
"/gnu/store/hllpqzv60p9vakrb2p98fvfksdqwcc9j-xorg-server-21.1.2/share/X11/xorg.conf.d"
HTH!
Cheers,
Kaelyn
he correct syntax instead of relying
on error messages for that information makes for a much nicer user experience,
as do better/clearer exceptions when a tool fails.
Cheers,
Kaelyn
>
> all best,
>
> jgart
>
> https://whereis.みんな/
> gemini://whereis.みんな/
> http://litterbox.whereis.みんな/
depends on another channel. Basically
in the top-level folder of your channel's git repo, you need a .guix-channel
file declaring the dependency (in a fashion similar to channels.scm). For
example, for my-channel:
(channel
(version 0)
(dependencies
(channel
(name other-channel)
(url "http://other-channel;)
(branch "master"
HTH!
Cheers,
Kaelyn
fields can be found at
https://guix.gnu.org/en/manual/devel/en/html_node/Base-Services.html#Base-Services
:)
Hope that helps!
Cheers,
Kaelyn
lar function. In the above example, imagine if a developer wants to
debug my-package using lldb instead of gdb--the developer-inputs would require
transforming the package definition, but the ad-hoc invocation could simply be
`guix shell lldb lcov -D my-package`.
Cheers,
Kaelyn
>
> Regards,
>
> old
>
> --
>
> Olivier Dion
>
> Polymtl
.
Cheers,
Kaelyn
te slow and consume a lot of memory, causing significant,
intense swapping with less than 64GB of memory in a parallel build (and
sometimes eventually trigger the OOM killer). As I recall, using ld.bfd for the
build was by far the slowest, ld.gold was noticeably better, and ld.lld was
showing
f merged back into master sooner, as master lacks support
for newer hardware while also getting regular package updates that are only
periodically merged to core-updates-frozen. Even before the c-u-f sprint last
month where I switched all of my systems to c-u-f, I had one system that was
first
e with reversing the naming or other improvements to
the CLI experience, because I do agree it could use some QoL polish. I only
wanted to chime in about the complexities of providing better integrations.
Cheers,
Kaelyn
> Would it break anything if we changed the metadata order like:
>
Hi Guix!
I just received my pinephone this morning, so I'm going to be interested in
bringing Guix to the pinephone as well. I hope to have the capacity to help
with the efforts, even if it's just the occasional testing.
Cheers,
Kaelyn
Sent with ProtonMail Secure Email.
‐‐‐ Original
ix-build-libfaketime-0.9.9.drv-0/source/test/timetest
>
> /bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not found
> (required by ../src/libfaketime.so.1) /bin/sh:
> /lib/powerpc64le-linux-gnu/libc.so.6: version` GLIBC_2.32' not found
> (required by
> /gnu/
of the use cases.
For example, with the original output that showed 100% substitute availability
from ci.guix.gnu.org and 0% availability from bordeaux.guix.gnu.org for a
single package and exited 1 as a result:
* "guix weather -a 1" would exit 0
* "guix weather -a 2" would e
76 matches
Mail list logo
