Re: Impossible to push patches to codeberg

Hello! Vagrant Cascadian writes: > > git push --set-upstream origin vagrantc-test > Enumerating objects: 44, done. > Counting objects: 100% (44/44), done. > Delta compression using up to 8 threads > Compressing objects: 100% (10/10), done. > Writing objects: 100% (35/35), 6.10 KiB |

Re: Committers: create and share your Codeberg account

Hi, "pelzflorian (Florian Pelz)" writes: > Could you add me as a contributor to > the artwork.git repo, because I would want to sync translations each > month. Done. Apologies for getting it wrong! Thanks, Ludo’.

Re: Broken pull requests

Hey, Noé Lopez via "Development of GNU Guix and the GNU System distribution." writes: > It’s fixed now! The pull requests can be accessed again, only the > requested team reviews have been lost. Great! Thanks for following up on this and apologies for breaking things! Ludo’.

Re: Problems with grafts and Gtk (and probably with most other dynamic things)

Hi Danny, I think you’re describing the problem that others pointed out earlier (there’s an open bug report IIRC) which is that grafting derivations do not necessarily produce all the outputs of the original derivation (so in one case you get a grafted ‘glib’ with just “out”, and in the other case

Re: Team members: create and share your Codeberg account

Hello, Ludovic Courtès writes: > Yes, definitely: if you’re a team member and not a committer, please > share your Codeberg account name here! I committed <https://issues.guix.gnu.org/78568> and added Codeberg account names for people who gave it here. So for instance Noé is now

Re: Committers: create and share your Codeberg account

Hi jgart, Could you sign your message? https://lists.gnu.org/archive/html/guix-devel/2025-05/msg00072.html Thanks in advance, Ludo’.

Spring cleanup: cut some branches!

Hello Guix, There are currently 109 branches in the repo: https://codeberg.org/guix/guix/branches I suspect that the previous mirroring job (from Savannah to Codeberg) would create branches but never propagate deletions. Anyway, that’s a lot of branches, so please take a look and delete those

Re: Migration to Codeberg effective on May 25th

Ludovic Courtès writes: > The main Guix repository will migrate to <https://codeberg.org/guix> in > a few days, on Sunday May 25th, 2025. > > At that point, its canonical URL will become: > > https://git.guix.gnu.org/guix.git The migration completed yesterday. Ple

Team members: create and share your Codeberg account

Hello, Noé Lopez writes: > Is it possible to do a similar thread for non-committers to get added to > our teams? Yes, definitely: if you’re a team member and not a committer, please share your Codeberg account name here! > AFAIK, getting added to a team on Codeberg does not necessarily give >

Re: Codeberg migration complete

Ludovic Courtès writes: > Definitely. We could take inspiration from the default sets of labels > they propose and tweak it? Hilton added labels, see <https://codeberg.org/guix/guix/issues/33>. Ludo’.

Re: I already broke master :)

Hello, Ian Eure writes: >> I temporarily disabled branch protection on ‘master’ so I could >> force-push and then re-enabled it; I also clicked on “require signed >> commits” there: >> >> https://codeberg.org/guix/guix/settings/branches/edit?rule_name=master > > Thank you very much for cleanin

Re: Committers: create and share your Codeberg account

Hello, John Kehayias writes: > Arg, this is a ProtonMail bridge issue, it drops the signature to use my > ProtonMail key. I've been meaning to go back to this issue to see what > the problem was with some encrypted emails in the past, but just now > found out this detail of rewriting messages (s

Re: Codeberg migration complete

Hi, Ian Eure writes: > Do we want to add some labels for the issue/PR types? Semes like > "security" and "bug" are two we’d want. Definitely. We could take inspiration from the default sets of labels they propose and tweak it? https://forgejo.org/docs/latest/user/labels/ https://codeberg

Re: I already broke master :)

Hi, Ian Eure writes: > Well, I managed to push an unsigned commit > (ea779f0b6bf7954327671b98bb93482a28fad668) to master, since the > pre-push hook doesn’t work yet[1]. > > Ludo’, could you remove that commit and force-push? Or rebase and > sign it, then force-push? I temporarily disabled bran

Re: Problems with grafts and Gtk (and probably with most other dynamic things)

Hi Danny, Danny Milosavljevic writes: > There are multiple definitions (same package version) of the packages glib > (and gobject-introspection and python-pygobject), in the same Guix repo. So > far okay. > > But if you aren't very very careful [so basically always], you end up with > differ

Re: Committers: create and share your Codeberg account

Hi John, John Kehayias writes: > Mine is I can’t verify the signature on this message. Could you use a different method, for instance by using ‘gpg -s --clear-sign’ on the message? Thanks in advance, Ludo’.

Codeberg migration complete

Group memberEric Bavier View Skills Watch partner Group memberGiovanni Biscuolo Set to private Watch partner Group memberChristopher Baines Set to private Watch partner Group administrator Ludovic CourtèsSet to private --- Group memberChristine L

Re: Codeberg migration check list

Hi, Cayetano Santos writes: > Not directly related to guix maintained infra, but I think we need a > collaborative effort towards pining ancillary sites still referring to > former guix.savannah. Repology [0] is one of them, but I’m sure there > are many others around. I think this can be a dis

GNU Shepherd 1.0.5 released

We are glad to announce version 1.0.5 of the Shepherd, the next bug-fix release in the 1.0.x series. Check out the web site to learn more about the Shepherd 1.0.x series: https://gnu.org/software/shepherd/news/2024/12/the-shepherd-1.0.0-released/ It is also the first release made from its new

Re: Codeberg migration check list

Ludovic Courtès writes: > Tomas Volf <~@wolfsden.cz> writes: > >> I think before the import, you should remove write permissions from >> everyone (except you), to make sure people do not push to savannah by >> mistake. Sorry if that was already planned somewhere

Re: Codeberg migration check list

Hello, Noé Lopez writes: > Is it possible instead to rename guix-mirror to guix instead, as that > would create an http redirection? Yes! I had that thought overnight too, and indeed, that’s much better. I’ll do that. Thank you! Ludo’.

Re: Codeberg migration check list

Ricardo Wurmus writes: > Ludovic Courtès writes: > >> - [ ] Git repository imported *Sunday* >> - [ ] git.guix.gnu.org redirect changed to codeberg.org/guix >> *Sunday* > > I'm a little confused about this. We currently have > https://codeberg.or

‘guix_mirror_bot’ account on Savannah

Hello, I’ve created the ‘guix_mirror_bot’ account on Savannah and added it to the ‘guix’ group. On Sunday, once the repo has migrated, I’ll set up SSH-based mirroring on Codeberg so that it pushes to Savannah as ‘guix_mirror_bot’: https://forgejo.org/docs/latest/user/repo-mirror/#mirror-via-ss

Re: Codeberg migration check list

Hi, Tomas Volf <~@wolfsden.cz> writes: > I think before the import, you should remove write permissions from > everyone (except you), to make sure people do not push to savannah by > mistake. Sorry if that was already planned somewhere and I have just > missed that. I guess I’ll do that, but ke

Codeberg migration check list

Hello Guix! Ludovic Courtès writes: > The main Guix repository will migrate to <https://codeberg.org/guix> in > a few days, on Sunday May 25th, 2025. Here’s the check list I came up with for the main repository migration, based on <https://codeberg.org/guix/guix-consensus-docum

Migration to Codeberg effective on May 25th

As a reminder, migration of the Guix repositories to Codeberg as described by the Guix Consensus Document (GCD) 002 was accepted on May 7th: https://codeberg.org/guix/guix-consensus-documents/src/branch/main/002-codeberg.md The main Guix repository will migrate to i

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Hello, Ludovic Courtès writes: > If we choose to install this patch, we should IMO do it as before > guix.git is migrated to Codeberg (presumably on May 25th). That way, we > can use git.guix.gnu.org in (guix channels) instead of > codeberg.org/guix/guix.git. We had a bunch of i

Re: 504 Gateway Time-out on https://qa.guix.gnu.org/

Hi, "nomike (they/them)" writes: > qa.guix.gnu.org is unreachable for at least 18+ hours, probably longer. > Could someone have a look at what's up? There have been troubles with bayfront, the server hosting this service and a few others, including guix.gnu.org. However I believe qa.guix.gnu.o

Re: branch master updated (a98cd5a6bd -> 57ea6d3d59)

Hello, Danny Milosavljevic writes: > Ok, guix time-machine with local directory ran through successfully. > > Can you confirm that it works for you, too? It’s all good, thank you! It’s a massive rebuild though, ~20k builds: https://ci.guix.gnu.org/eval/2059220 Any idea what causes this?

Re: branch master updated (a98cd5a6bd -> 57ea6d3d59)

Hi Danny, guix-comm...@gnu.org writes: > dannym pushed a change to branch master > in repository guix. > > from a98cd5a6bd gnu: emacs-org-node: Update to 2.4.2. [...] > new 7ba6e6f090 gnu: Add rust-gix-worktree@0.39.0. > new a80e6deb7d gnu: Add rust-gix-worktree-state@0.17.0. >

Re: bug#78047: WiFi stops working if managed with NetworkManager after migration to unprivileged guix daemon

Hello, Ludovic Courtès writes: >>> 2025-04-24 10:34:15 localhost NetworkManager[852]: >>> [1745483655.8537] plugin: skip invalid file >>> /gnu/store/agadky1p0ba367avf524sh5wmcdxcxb1-network-manager-1.52.0/lib/NetworkManager/1.52.0/libnm-device-plugin-wwan.so: >>

Re: branch master updated: gnu: rlottie-for-telegram-desktop: Do not inherit.

Hey Oleg, guix-comm...@gnu.org writes: > commit 475e8802c3d2c67c84cedfda4e66b6b59d8a9e36 > Author: Sharlatan Hellseher > AuthorDate: Sun May 18 20:32:37 2025 +0100 > > gnu: rlottie-for-telegram-desktop: Do not inherit. The other option (probably more common and preferable) is to move the pa

Re: [bug#76296] [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

I wanted to deploy this patch now so we can start testing it and since the goal was to migrate guix.git next Sunday (May 25th). Unfortunately, we seem to be unable to connect to the machine hosting our DNS service (bayfront) so I’m not sure when we’ll be able to deploy it. Bad timing. :-/ Ludo’.

Re: [bug#76296] [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Hello, Ahmad Draidi writes: > I guess this would make switching, in case of disasters, seamless for > the user, which is probably something we want. The URL doesn't > change. On Guix project's side, it's a relatively quick change. The > extra load is probably negligible also. No need to proxy th

Re: Preparing for Git repository migration

Hello, Rutherther writes: > see > https://blog.codeberg.org/new-storage-limits-on-codeberg-what-you-need-to-know.html > for news on codeberg storage usage - 750 MB for git repos per user/org. I hadn’t realized this was also per-org. I filed a request for more storage, as the blog post suggests

Re: guix.vim repository

Hello, Efraim Flashner writes: > Currently I'm the only contributor to guix.vim. Seeing how much action > the emacs-guix plugin has been getting over the past few days now that > it's at codeberg I think it would be good if we were to move the > upstream repo to be under the guix organization.

Re: Improve guix-daemon by new C++ features

Hi, Congcong Kuo writes: > For path manipulating function they are not related to read/write > files and path is just a kind of data structure. In > nix/libutil/libutil.cc, paths are simply represented and processed as > string. I think it can be easily replaced using C++ standard library > with

Re: Improve guix-daemon by new C++ features

Hi, Congcong Kuo writes: > In nix/libutil/util.cc there are lots of functions related to > copy/delete files and manipulate file paths. In C++ 17 the standard > library’s provides the same functionality which is more > reliable. > > guix-daemon uses Boost.Format to generate formatted string. Th

The 🐑 Shepherd on Codeberg

Hello Guix, I have migrated the Shepherd repositories to Codeberg, where they’re now in good company: https://codeberg.org/shepherd I restored commit rights for the handful of people who had commit rights on Savannah, and also updated the web site. Let me know if you spot any issues! Ludo’.

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Hi, Ricardo Wurmus writes: > Noé Lopez writes: > >> I guess its for style points, which I’m all for. I do think it would >> be >> better to set the URL to git.guix.gnu.org/guix/guix.git and just a >> DNS >> redirect to codeberg to avoid the extra connection. > > I second this. > > I think a DNS

Re: Preparing for Git repository migration

Arun Isaac writes: >> I’m also happy to add your account to the “owners” team; let me know >> when you have one. > > I already have an account. Here it is: https://codeberg.org/arunisaac Added, thanks!

Resource usage on Codeberg

For the record, I reached out to Codeberg e.V. regarding storage and bandwidth usage induced by Guix, to which they replied that they “expect this to be fine”: https://codeberg.org/Codeberg-e.V./requests/issues/784 Ludo’.

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

Hi Steve, Steve George skribis: > Reflecting things that we agree on: I will try and avoid the word 'vote'. > I'll rename to 'deliberation-record' (1). And, will use 'Deliberation record' > elsehwere. Sounds great to me. > Things we don't agree on: I don't see a way to avoid the verb "vote"

Re: Preparing for Git repository migration

Hello, Arun Isaac writes: >> Looking at , there’s one >> repository I forgot to mention (shame on me): mumi. >> >> Arun, should I let you migrate it? Let me know what you prefer. > > Since you're already familiar with the process, it might be easier for

Re: Preparing for Git repository migration

Hello, Efraim Flashner writes: > Can we also ask the Savannah admins to change the cgit clone URIs for > the repos that have been moved over? Is it feasible? I would think that Cgit has those hardcoded, no? Ludo’.

Re: Preparing ungrafts

Greg Hogan writes: > On Mon, May 12, 2025 at 11:34 AM Ludovic Courtès wrote: [...] >> Also, once ‘core-packages-team’ is merged (or with a tweak to exclude >> the glibc graft), I’d like to resume my experiment in auto-ungrafting: >> >> https://issues.guix.gnu

Re: Emacs-Only Guix Reporting and Development Under Codeberg

Hi, Christopher Howard writes: > Hi, for those of us who do everything in Emacs and despise Web > browsers, where should we be looking for information on adapting to > the Codeberg migration? Like, what Emacs and/or shell interfaces will > be available? Will "guix-report-bug" continue to work?

Re: Preparing ungrafts

Hello, Greg Hogan writes: > I would like to second Leo's idea from the kernel-team branch discussion: > > Changing the subject, it would be nice if grafts were committed > along with an ungrafting > commit to the team branch that would be responsible for the code, > assuming such a team

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

Hi, Steve George writes: > Note that 'Deliberate' means to "consider or discuss", and a person > would "vote" at the end of a deliberation period to "to express your > choice or opinion". That is the standard use in English. One doesn't > keep a "Deliberation" as a record of choices (e.g. tally

Re: Preparing for Git repository migration

Hi, "nomike (they/them)" writes: > On 09.05.25 10:34, Noé Lopez wrote: >> That would make a ton of dead links to cgit. How about writing on the >> savannah page and README that the repository is archived with the new >> url? > > If I have a clone of the guix and still have savannah as origin aft

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

Hi Steve, Ludovic Courtès writes: > I think it would make sense to add it in a sub-directory of > guix-consensus-documents.git, and IMO does not require a change of > GCD 001 (though we could eventually propose to amend GCD 001 to > explicitly mention said sub-directory). I saw

Re: Preparing for Git repository migration

Hello, Ludovic Courtès writes: > Ludovic Courtès skribis: > >> For now, I’m happy to start migrating the dormant repositories >> (bootstrappable, dhcp, gnunet, videos, emacs-guix). > > Done. > >> A few days later I can move the rest (guix-artwork, guix-cuiras

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Hi Noé, Noé Lopez writes: > As you said, this adds an extra point of failure. It seems that there is > no real issue with changing URL right now as shown by GCD 002. So what > is the benefit of this patch? This was originally proposed as a way to facilitate Git migration—should we decide in a y

Re: Committers: create and share your Codeberg account

Ludovic Courtès writes: > I won’t reply to every message but basically, I’ll be adding “Owners” > (people who currently commit to several repositories) as I receive them. Quick update: note that team members are currently visible only to logged-in org members: https://codeberg.org/Co

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Hi, Christopher Baines writes: > I wonder how this compares to storing and serving a mirror of the Git > repository. Maybe that's a bit more complicated in terms of the setup, > but it may perform better than a redirect and actually provide > redundancy? Good point. I think mirroring would be

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Hello, Now that GCD 002 has been accepted, I’d like to restart discussions around this patch, which adds the git.guix.gnu.org DNS entry and HTTP(S) redirects to codeberg.org/guix: https://issues.guix.gnu.org/76296 > This patch implements that; technically we have to have an HTTP redirect, > wh

Re: Preparing for Git repository migration

Ludovic Courtès skribis: > For now, I’m happy to start migrating the dormant repositories > (bootstrappable, dhcp, gnunet, videos, emacs-guix). Done. > A few days later I can move the rest (guix-artwork, guix-cuirass, > maintenance, guix-consensus-documents). > > Chris, ca

Re: Committers: create and share your Codeberg account

Vagrant Cascadian skribis: > On 2025-05-09, Ludovic Courtès wrote: >> To avoid problems, I suggest you send your account name as a public >> reply to this message, in a signed message. > > I have noticed that several of the replies have expired keys, and I have > not f

Re: Committers: create and share your Codeberg account

I won’t reply to every message but basically, I’ll be adding “Owners” (people who currently commit to several repositories) as I receive them. I (or someone else) will add people who only commit to guix.git as “Collaborators” of that repo once it has been migrated. Ludo’.

Re: Preparing for Git repository migration

Noé Lopez writes: >> An open question is the strategy to adopt for migrated repositories >> (apart from guix.git); do we: >> >> 1. remove them entirely from Savannah? >> >> 2. “fork” them by adding a commit in their Savannah copy that removes >> all files and/or amends README to state th

Re: SSH bad owner when running rootless guix-daemon

Hi Kjartan, Kjartan Oli Agustsson writes: > I have been trying out the new option to run the guix daemon as > non-root. Everything had been going just fine untill I tried to SSH > into another machine. My SSH configuration is managed by guix home so > ~/.ssh/config is of course a symlink to a

Re: Preparing for Git repository migration

Hi, Christopher Baines writes: > Ludovic Courtès writes: > >> Chris, can you migrate data-service, build-coordinator, nar-herder, and >> qa-frontpage whenever is convenient for you? > > Yep, I just need access, I'm cbaines on Codeberg: > https://codeberg.org/cba

Committers: create and share your Codeberg account

Hello Guix! If you’re a committer, please consider creating an account on Codeberg. To avoid problems, I suggest you send your account name as a public reply to this message, in a signed message. You will be given rights on Codeberg according to the “Rights and Privileges” section of GCD 002. T

Preparing for Git repository migration

Hello Guix, Key dates defined in GCD 002 are: • By June 5th, all Git repos are migrated to Codeberg; • On a flag day between May 21st and June 5th, guix.git is migrated (meaning that nobody pushes to Savannah after that date). How about Sunday May 25th for the guix.git migration? (We c

Re: Practical consensus building, was: Deliberation period for GCD 003 "Rename the default branch" has technically started

Hi reza, Thanks for your thoughtful comment. reza writes: > 1. Consensus building needs necessary conditions to be met before > starting, this is not mentioned in the GCD process and should probably > be checked before every GCD The GCD process refers to

Re: github updater doesn't behave well when "releases" have been abandonned

Hi, Nicolas Graves writes: > It's not the first time I run into something like this : > > $ ./pre-inst-env guix refresh emacs-haskell-mode > > [...]/gnu/packages/emacs-xyz.scm:2971:13: warning: 17.5 is greater than > the latest known version of emacs-haskell-mode (16.1) > > This happens when the

Re: Substitutes mirror available in Japan! (and questions regarding mirroring)

Hi, Maxim Cournoyer writes: >> We could consider setting up a rsync module on ci.guix (aka. berlin) if >> that helps. > > The main issue I had seen (but it seems that'd affect most rsync > mirroring scheme) is that the files could be updated while an rsync > client is syncing them, which could p

Re: Alternative way to make compilers (e.g. Rust, Zig) available for more architectures.

Hi, Efraim Flashner writes: >> > 2. Cross compile them from x86_64-linux, add the outputs into a git >> > repository, distribute them with ‘guix time-machine’ invocations and >> > hashes recorded. > > Tossing them into a git repository wouldn't be that great for the git > repository. We could u

Re: Data corruption on reboot

Hi Danny and all, Maxim Cournoyer writes: > Danny Milosavljevic writes: > > [...] > >> Anyway, after the updated e2fsck the machine has no problems anymore >> (so far...). >> >> Docs: >> >> >> Kernel bugfix: >>

Re: Substitutes mirror available in Japan! (and questions regarding mirroring)

Simon Josefsson writes: > Ludovic Courtès writes: > >>> The nar-herder which handles serving substitutes for the bordeaux build >>> farm is meant to enable high performance mirroring, and that's what's >>> used for the mirrors listed on https://bor

Re: issue on postgresql

Ludovic Courtès writes: > Antonio Carlos Padoan Junior writes: > >> I'm having a problem with guix system containers, but not sure if it a >> bug or mis-configuration. I can't start postgres shepherd service >> because system-log service is not starting. A pe

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

Hello, Steve George writes: > I collated the results of the voting on GCD 002. [...] > Voting result: > - 67% (33 votes) voted to pass the GCD > - 0% disapproved > - 33% abstained by not voting > > As more than 25% of members voted to pass, and there were no disapprovals > this GCD is

Re: Why YOU should join a Team!

Hi Denis, Denis 'GNUtoo' Carikli writes: > On Sun, 27 Apr 2025 14:37:24 +0100 > Steve George wrote: >> There's no particular rule on how much you need to have contributed >> to become a Team member. Personally, I think that if you consider >> yourself as someone who's working on the project the

Re: Substitutes mirror available in Japan! (and questions regarding mirroring)

Hello, Christopher Baines writes: > Hilton Chain writes: > >> Recently, I got in touch with Jing Luo on mirror hosting. They have >> hosted mirrors for various distributions[1], and it's really kind of >> them to still[2] be willing to help out. >> >> As a result, here are two new mirrors: >>

Re: Deliberation period for GCD 003 "Rename the default branch" has technically started

Hello, I see much discussion of the deliberation, framed as a vote, but that’s not what it is. I think mentions of votes, opposition, veto, and similar phrases miss the point. The deliberation is meant as a way to get a clear understanding of what people have said and done before—a show of hands

Re: Questions and Bugs for 'emacs-guix'

Hi Andrew, A bit of a late reply… Andrew Wong writes: > Recently I've been trying to streamline my package development > workflow, and one tool I've been trying to use is `emacs-guix'. In > particular, I'd like to use it to build packages from within emacs > (instead of running ./pre-inst-env g

Re: Alternative way to make compilers (e.g. Rust, Zig) available for more architectures.

Hi, Hilton Chain writes: > Currently we have Zig only available for x86_64-linux and aarch64-linux. > Our Rust doesn't support 32 bit either. Are 32-bit architectures supported upstream? > 1. Support cross-compilation of these compilers. > > 2. Cross compile them from x86_64-linux, add the out

CI for the unprivileged daemon?

Hello Guix, While discussing build environment discrepancies that keinflue found with the unprivileged daemon¹, we came up with the idea that having CI in place to rebuild packages with the unprivileged daemon would be helpful. In essence, I think this could be a VM running Cuirass (building all

Re: How do we flag a feature as implemented for GNU Guile cond-expand in Guix packages?

Hi, Yuval Langer writes: > I have added: > > (cond-expand-provide (current-module) '(srfi-78)) > > to the top of the `./srfi/srfi-78.scm` file, right after > `(define-module (srfi srfi-78) ...)`, but I see that within the `guix > shell -L . guile guile-srfi-78` environment, GNU Guile's `cond

Re: Data corruption on reboot

Hi Danny, Danny Milosavljevic writes: > Found something new: [...] > Output: > hello world after sync! > hzllo world ports gone! > # > hello world end! > [177.726300] EXT4-fs error (device dm-0): > ext4_mark_recovery_complete:6276: comm shepherd: Orphan file not empty on > read-only fs. That

Re: Data corruption on reboot

Hi, Danny Milosavljevic writes: > Since I think I know what causes it that should be easy enough. I added a simple ‘lsof’ invocation and displayed the list of remaining processes: diff --git a/gnu/services/base.scm b/gnu/services/base.scm index 8c6563c99d..8b383e3d81 100644 --- a/gnu/services/

Re: How do we flag a feature as implemented for GNU Guile cond-expand in Guix packages?

Hi, Yuval Langer writes: > Is there a way of adding cond-expand features to GNU Guile, maybe in > the Guix package definitions? Yes, you can add this line in your module: (cond-expand-provide (current-module) '(srfi-135)) HTH! Ludo’.

Re: issue on postgresql

Hi, Antonio Carlos Padoan Junior writes: > I'm having a problem with guix system containers, but not sure if it a > bug or mis-configuration. I can't start postgres shepherd service > because system-log service is not starting. A permission issue on the > container: > > Status of system-log: >

Re: Data corruption on reboot

Hi Danny, Danny Milosavljevic writes: > I've now implemented the relevant parts of fuser in guile, see > . I've tested it as a standalone > module and it seems to work fine. However, I need help to integrate > something like that into guix (and/or shepherd, h

Re: Setting procedure properties for build-system builders

Hello, Nicolas Graves writes: > Actually the thunk was not necessary because args were already passed to > the build-bag procedure, and modules and imported-modules were already > used in every bag-build procedures, except for trivial and raw > build-systems. > > Patch should look like the one a

Re: Data corruption on reboot

Danny Milosavljevic writes: > The more I think about it the more it seems we should re-enter our > initramfs on shutdown. Unfortunately, the Linux kernel frees it when > switching to the real root fs. Not sure how to get Linux to find it again > (or how to get Linux to not free it in the first

Re: Data corruption on reboot

Hey, Danny Milosavljevic writes: > If you want to debug that live, you can log to the console: switch to the > console (Ctrl-Alt-F1), set the kernel console loglevel to maximum (alt > print 9), and then watch what it says there. > > I currently use the following shell script to halt without powe

Re: Data corruption on reboot

Hello, "Ryan Schanzenbacher" writes: > To throw my hat into the ring with this,, I can confirm I've been seeing the > same for a while now (past 3-ish months?) I have a laptop that doesn't exhibit > this behavior that is a bit out of date, and one that does. Something I can > look into doing whe

Re: Shepherd: flaky self tests

Hi Simon, Simon Josefsson via "Development of GNU Guix and the GNU System distribution." writes: > log-rotation: > > https://buildd.debian.org/status/fetch.php?pkg=shepherd&arch=arm64&ver=1.0.4-1&stamp=1744885841&raw=0 > https://buildd.debian.org/status/fetch.php?pkg=shepherd&arch=armel&ver=1.0

Re: Regarding removal of the rottlog-service-type

Hello, Tomas Volf <~@wolfsden.cz> writes: > I have to admit I just do not fully get the thought process behind the > current design, so I wanted the option of "keep X old" to work around my > ignorance. :) Right now, the initial rotation is based on *size*, but > the number of kept old files is b

Re: Regarding removal of the rottlog-service-type

Z572 writes: > Ludovic Courtès writes: [...] >> There’s an undocumented way to rewrite the service graph: see >> ‘define-service-type-mapping’. >> >> We could perhaps make it “first-class” so one can more easily make this >> kind of customization. > >

Re: [shepherd] Setting up a queue for tasks

Nicolas Graves writes: > Maybe the recent work of Noé makes it simpler to implement as an > extension? > > https://codeberg.org/cons-town/guile-debugger/src/branch/main/shepherd-nrepl/ Dunno, I’m not sure how nREPL relates to this. Anyhow, like I wrote, it’s already possible to define this kind

Re: Regarding removal of the rottlog-service-type

Z572 writes: > Currently, it is not possible to simply modify an extended service to a > variant. For example, I want to use a modified log-rotation-service-type > (NL) to replace the original log-rotation-service-type (OL). > > (someone-service-type) --extension--> (OL) --extension--> > (shephe

Re: Regarding removal of the rottlog-service-type

Hello, Z572 writes: > I think our modify-services may lack a function to replace the > service-type, so that we can easily experiment with new service-types, > inherit and modify them to the behavior we want. I’m not sure what you mean. You could always (with or without ‘modify-services’) remo

Re: Deliberation period for GCD 003 "Rename the default branch" has technically started

Hi, Vagrant Cascadian writes: > Only in retrospect of having encountered this situation did I realize > there is a fundamental flaw in the GCD process (at least in my > opinion)... in that there is a presumption of moving forward and > accepting the proposed changes (in some capacity), rather th

Re: Regarding removal of the rottlog-service-type

Tomas Volf <~@wolfsden.cz> writes: > 1. Per-log file settings. Some files I want to never rotate (the data >has sentimental value). Some files I want to rotate, but keep *all* >previous versions (if I would be using Guix at work, this is required >for auditing reasons). OK. > 2. Op

Re: Looking for a mentor for PackageKit/Appstream integration

Hello Noé, Noé Lopez writes: > I’m not far from having everything working but I need help for the > PackageKit guile library, I’m having trouble implementing the different > operations. Currently, I got installing to work[1] but I think I’m > breaking my profile at the same time, so I would lik

Re: Regarding removal of the rottlog-service-type

Hi Tomas, Tomas Volf <~@wolfsden.cz> writes: > --8<---cut here---start->8--- > Warning: The Rottlog service presented here is deprecated in favor > of ‘log-rotation-service-type’ (see above). The > ‘rottlog-service-type’ variable and related too

Re: [shepherd] Setting up a queue for tasks

Hi Nicolas, Nicolas Graves writes: > I recently tried to use the task-spooler package, and realized that it > shouldn't be too hard to have the same kind of queue extending the GNU > Shepherd API. > > I came up with that, which is not complete, at least because I have no > clue as to how to laun

Re: How to move forward about Rust? antioxidant, cargo2guix, etc.

Hilton Chain writes: > 153k -> 42k lines for dependencies, sounds good? :) Awesome. :-)

  1   2   3   4   5   6   7   8   9   10   >