Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg
Hi Simon,
Simon Tournier skribis:
>>> 1. Drop the section of « Issue Tracker Migration Path ».
>>
>> To be clear, are you suggesting to not use Codeberg for bug reports at
>> all?
>
> To be clear, yes.
OK. So postponing bug/issue tracker migration to Jan. 2026 as the GCD
now states (based on what you proposed¹) doesn’t address your concerns?
Or perhaps I misinterpreted your proposal?
¹ https://issues.guix.gnu.org/76503#115-lineno87
>> We could change it to “Migrating repositories and patches to Codeberg”;
>> that has less appeal to me, because I’m confident that (1) this would
>> lead to confusion, and (2) we’d miss out on cross-referencing and other
>> niceties.
>
> Cross-referencing fully locked in the Codeberg web-interface, right?
>
> Which niceties do you speak about?
Off the top of my head:
• notifications (subscribe/unsubscribe to individual issues, ping
individual people or team);
• automatically notify the right people on PRs via ‘CODEOWNERS’;
• cross-referencing (see when someone refers to an issue/PR from
another issue/PR/commit; close issues when a commit messages says
so);
• tagging, classification;
• ability to use PR/issue templates to guide people and ease
onboarding;
• API access allowing bots to comment on PRs for instance (fresh from
the oven: Cuirass now sends comments indivicating build status on
PRs).
Many of these features may seem anecdotal, but IME they really help with
triage and with getting the attention of the right people, which I think
is critical for a project the size of Guix.
(All this information is available to all the user interfaces, not just
the web interface.)
> For instance, I cannot promote Free Software and advocate at length
> about user-autonomy.
[...]
> Because we have to be very clear: the migration from emails to Codeberg
> isn’t only the technical migration of the workflow. It’s much deeper:
> it’s a “philosophical” migration.
As you know, I very much understand these issues, I know why I chose
Debbugs at a time when Git{Hub,Lab} were already popular; they are
discussed (on your request) in the GCD. To me, it’s a compromise.
In an ideal world, we would self-host, which would address some of these
concerns. It doesn’t seem viable at this point, but if/when somebody
steps up, this remains open.
>> We could also set up our own thing; I’ll inquire to see if there are
>> tools to do that for regular users.
>
> This is what I have in mind. Please note I’m not considering this as
> blocking or something we must have on Day-1.
I did inquire on Mastodon: nobody came up with the ready-to-use tool to
do backup. We could use the HTTP API, which exposes everything, to
approximate it, but it’d be an approximation.
>> On experience: collectively, we have experience with Codeberg and with
>> other forges; many of us frequently interact with this kind of forge.
>
> Who is the ’collective’? How many of the current people with write
> access on Savannah have an account in Codeberg? And how many concretely
> did at least one review (with comments) and merged a PR?
It’s a small but strictly-positive number. But probably 100% of us have
experience with similar forges, many of us using them daily, that’s what
I meant; we cannot pretend that we’re all discovering this.
> Somehow, you developed a experience. Who Deliberation members might
> report a minimal experience?
Not sure what you mean.
> It’s not to make the decision bigger than it is. If I ask to the Ludo
> from one year ago (before investing time with Codeberg and propose to
> switch to the Guix-Science channel), do you want yo migrate? What would
> have been your answer? Probably the same as I am doing now: Euh, yes
> why not but hmm I am not sure, well I do not know.
You’re right: I’ve long been reluctant to forges of that kind, as I
wrote before. It’s been a process for me: that of seeing the
unsustainable situation Guix is in, looking at other projects do it
(check out Nixpkgs or Brew or whatever!), getting first-hand experience
with GitLab and Codeberg and how it leads to a smooth and approachable
workflow.
I understand it’s hard to “transfer” experience, and that’s why I was
hoping active contributors would give it a try to at least get a taste
of it.
Thanks for your feedback,
Ludo’.
Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg
Hi, Simon Tournier skribis: > I’m just discovering the Forgejo instance of sourceware: > > https://forge.sourceware.org/explore/organizations > > Here, mirror of GCC, Glibc and others are already hosted. > > Therefore, it would make sense to check their willing and capacity to > backup Guix; I have in mind to ask for hosting read-only copies of all > the PRs, i.e., a plan B for the history of all the PRs. Sure, sounds like a good idea. Ludo’.
Re: [PATCH 0/2] ffmpeg-7: Update to 7.1.1.
Hi Guix, So around 3 weeks ago, I sent a patch to bump ffmpeg-7 to the latest version, 7.1.1 [1]: 45mg <45mg.wri...@gmail.com> writes: > ffmpeg-7 is currently FFmpeg 7.0.2, which was released on 2024-08-03 - > 7 months ago. It's probably time for an update. > > Version 7.1 adds AAC USAC and VVC support. I also updated mpv to benefit > from this. > > When are we planning to make ffmpeg-7 the default ffmpeg? The current > default (6.1.1) was released on 2023-12-31 - over a year ago. > > 45mg (2): > gnu: ffmpeg-7: Update to 7.1.1. > gnu: mpv: Use ffmpeg-7. (ignore the second patch, its inclusion doesn't really make any sense tbh) It would, of course, cause a lot of rebuilds, and I don't really know how we handle that issue (maybe apply it to core-updates?). I didn't get a response there; probably in large part because nobody even got X-Debbugs-CC'ed for that patch series. So I thought I'd reiterate my original points for a wider audience here: > ffmpeg-7 is currently FFmpeg 7.0.2, which was released on 2024-08-03 - > 7 months ago. It's probably time for an update. > When are we planning to make ffmpeg-7 the default ffmpeg? The current > default (6.1.1) was released on 2023-12-31 - over a year ago. [1] https://yhetil.org/guix/cover.1741088958.git.45mg.wri...@gmail.com/
Re: chez scheme can't load system shared library
Hi Felix Lechner, Thanks for your response. Unfortunately, it does not work: `LD_LIBRARY_PATH' is empty in my shell: $ echo $LD_LIBRARY_PATH scheme can't start up with LD_LIBRARY_PATH set: $ LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH scheme Segmentation fault (core dumped) $ LD_LIBRARY_PATH='/usr/lib' scheme Segmentation fault (core dumped) `scheme' is the binary executable file of chez scheme. Chez scheme built directly from source code (no guix) can startup with above command line. Regards, Pan On 3/25/25 11:51 AM, Felix Lechner wrote: Hi Xie Pan, On Tue, Mar 25 2025, Pan Xie wrote: *this* chez scheme can not load system shared library correctly: I have never used Chez Scheme but suspect you have to set LD_LIBRARY_PATH. In Bash, it might look like something like this: $ LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH chez-scheme-executable Guix refers to prerequisites by absolute paths into the store whenever possible, including for shared libraries. Installing prerequisites into a profile, as you seem to have done, and then finding them in /usr/lib is known as "propagating" a prerequisite. It can be convenient, but people generally consider it subobtimal, because it tends to restrict the versions usable at the same time (although shared libraries employ a lesser versioning scheme of their own). I hope I was of help. Please stick around for answers from more competent contributors. Kind regards Felix
Re: Trying out Codeberg
Hi, On Thu, 13 Mar 2025 at 10:36, Adrien 'neox' Bourmault wrote: > the default CI recipes/code depends on > docker.io images Well, Cuirass (one CI tool used by the Guix project) is able to work with Forgejo. > nodeJS and npm. Also, the javascript generated by > Forgejo is minified, without a clear license header, making LibreJS > blocking it by default (and preventing people from being able to trust > it right away). Yeah, that’s annoying but the license header is fixable, no? Cheers, simon
Re: Thoughtful updates to TexLive
Hello, Andreas Enge writes: > So maybe once the fix for issue 75893 is pushed and the modular texlive > updated to version 2025, it will finally be time to retire the > monolithic package. Modular TeX Live 2025 is on its way! > Well, I do not know how complicated it will be to update the modular > texlive, with package additions, maybe removals, and updates of the > collections and schemes. The upgrade process is explained at length in the comments of the "tex.scm" module in case anyone is curious about it. > How do you keep track of the changes between one version and another > one? I don’t keep track of anything. I let the importer tell me what packages disappeared, and what are the new ones. > And does it make sense to follow the yearly release schedule? Texlive > has a Mastodon account, and they regularly post updates of single > packages. Currently, the `texlive' importer and updater is only able to handle "yearly" releases, but it is possible to specify manually any SVN revision for the TeX Live packages. I think this granularity is sufficient, in particular when we consider the sheer number of rebuilds changes to TeX Live packages usually entail. Regards, -- Nicolas Goaziou
Re: chez scheme can't load system shared library
Hello Sebastian Based on your suggestion, now I figure out that I have to install guix openssl, even though I already I have openssl libraries installed in "/usr/lib". The following works for me now: $ guix install openssl $ LD_LIBRARY_PATH=~/.guix-profile/lib scheme (load-shared-object "libssl.so") Thanks Pan On 3/25/25 6:25 PM, Sebastian Dümcke wrote: Not sure how to answer to a particular meesage from the digest emals I am receiving. Hope this finds the right person and thus not upset anyone. Hi Pan, you need to set LD_LIBRARY_PATH to your profile library path (and then load without absolute path in chez). The following works for me: > guix shell -CP coreutils-minimal chez-scheme openssl > ls ~/.guix-profile/lib csv10.1.0 engines-3 libcrypto.so libcrypto.so.3 libssl.so libssl.so.3 ossl-modules pkgconfig > LD_LIBRARY_PATH=~/.guix-profile/lib scheme (load-shared-object "libssl.so") Best Sebastian
Re: Scaling issues with forges Was: Trying out Codeberg
Hi, On Tue, 11 Mar 2025 at 13:12, Suhail Singh wrote: > Are the relevent portions of your .emacs or init.el accessible > somewhere? https://gitlab.com/zimoun/my-conf Cheers, simon
Wireshark with capabilities
Hello all,
recently I wanted to run Wireshark without using sudo (given that I am
on wayland it's a bit more involved to get apps run as other user,
though it is possible with root). Dumpcap is needed to have cap_net_raw
and cap_net_admin=eip so that it can work properly.
I faced two issues regarding this:
1. Wireshark references dumpcap directly from its output
2. dumpcap is wrapped with some qt wrapper stuff that's not
important for it as it is not a gui program like wireshark itself is.
I solved both issues, but not really ideally, I patched wireshark so
that it refers to /run/privileged/bin/dumpcap directly and unhwrapped
dumpcap by copying the .dumpcap-real to dumpcap.
I am now wondering what would be more idiomatic way to solve this.
Should we patch wireshark to first look into PATH and only then try
dumpcap from the output directory? This still keeps wireshark not
dependent on having its bin folder in PATH, but on the other hand,
it might happen that dumpcap from the system will be preferred, which
might in some cases be undesirable.
And regarding the undesired wrapping, shouldn't the qt build system have
a way to say which binaries should not be wrapped? I see that it is
currently possible to tell to not wrap specific outputs, but no way to
not wrap specific binaries. Unwrapping after it's wrapped feels more
like a hack.
I am attaching my current solution:
---
(define wireshark-patched
(package/inherit wireshark
(source (origin
(inherit (package-source wireshark))
(patches (cons*
(local-file "patches/wireshark.patch")
(origin-patches (package-source
wireshark))
(arguments
(substitute-keyword-arguments (package-arguments wireshark)
((#:phases original-phases)
#~(modify-phases #$original-phases
(add-after 'qt-wrap 'unwrap-dumpcap
(lambda _
(delete-file (string-append #$output
"/bin/dumpcap"))
(copy-file
(string-append #$output "/bin/.dumpcap-real")
(string-append #$output "/bin/dumpcap"))
---
Here is the patch:
---
>From cb326bf97c99ff73a0a8689304e3ad47aa59139f Mon Sep 17 00:00:00 2001
From: Rutherther
Date: Sat, 15 Feb 2025 11:39:38 +0100
Subject: [PATCH] Point dumpcap to privileged bin
---
capture/capture_sync.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/capture/capture_sync.c b/capture/capture_sync.c
index 946dc810db..2cc3d6f705 100644
--- a/capture/capture_sync.c
+++ b/capture/capture_sync.c
@@ -244,7 +244,7 @@ init_pipe_args(int *argc) {
char **argv;
/* Find the absolute path of the dumpcap executable. */
-exename = get_executable_path("dumpcap");
+exename = "/run/privileged/bin/dumpcap";
if (exename == NULL) {
return NULL;
}
@@ -270,9 +270,6 @@ init_pipe_args(int *argc) {
}
}
-/* sync_pipe_add_arg strdupes exename, so we should free our copy */
-g_free(exename);
-
return argv;
}
--
Privileged programs then looks like this
---
(privileged-programs
(cons*
(privileged-program
(program
(file-append wireshark-patched "/bin/dumpcap"))
(capabilities "cap_net_raw,cap_net_admin=eip"))
%default-privileged-programs))
---
Regards,
Rutherther
Re: Thoughtful updates to TexLive
On Tue, Mar 25, 2025 at 12:51:24PM +0100, Andreas Enge wrote: > Hello, > > Am Thu, Mar 20, 2025 at 07:09:46PM +0100 schrieb Nicolas Goaziou: > > > This looks a lot like https://issues.guix.gnu.org/75893 . > > > I should test with your fix on the tex-team branch. > > I would indeed appreciate some feedback! > > as mentioned in the issue, your fix appears to work very well. > > I have just pushed the 2025 update to the monolithic texlive. > This is the first time that the temxf tarball is bigger than 4GB > (the previous one was already bigger than 4*10^9, but still smaller > than 4*2^30). Unless I have made a mistake, I think this has had some > incidence: As usual, I had done a "guix download" from a local file, > but "guix shell -D texlive" has still downloaded the tarball again. > I wonder if there is a bug somewhere in the Guix code for files bigger > than 4GB. And I also wonder what will happen on 32 bit systems... Will probably run into something like this: https://issues.guix.gnu.org/65714 The last time I looked at the built monolithic texlive I saw there were almost 2GB of PDFs and other files which could be removed or moved to another output. It might be worth checking that out here too. > So maybe once the fix for issue 75893 is pushed and the modular texlive > updated to version 2025, it will finally be time to retire the > monolithic package. > > Well, I do not know how complicated it will be to update the modular > texlive, with package additions, maybe removals, and updates of the > collections and schemes. How do you keep track of the changes between > one version and another one? And does it make sense to follow the yearly > release schedule? Texlive has a Mastodon account, and they regularly > post updates of single packages. > > Andreas > > -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: [GCD deliberation] Set search paths without program wrappers
Janneke Nieuwenhuizen writes: > [...] >> And when the executable's `/proc/self/exe` matches `GUIX_INTERPRETER_FILE`, >> we can get the script file name from `GUIX_MAIN_SCRIPT_FILE`. Alternatively, >> we can try to construct the script file name from command line arguments, but >> that won't work when you run a script using a relative file name and its >> current working directory changed before we figure out the script file name. > > Would this work with `guix pack' tarball archives, esp. think > cross-built `guix pack' archives for MinGW? I think this should work for `guix pack' when the target is a linux system, MingGW won't work with '/proc/self/exe', but maybe we can find something similiar. I'll keep this in mind and do some tests later, thanks!
