unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Csepp <raingloom@riseup.net>
To: Christina O'Donnell <cdo@mutix.org>
Cc: guix-devel@gnu.org
Subject: Re: Kdump
Date: Mon, 31 Jul 2023 19:45:10 +0200	[thread overview]
Message-ID: <87leew9dhj.fsf@riseup.net> (raw)
In-Reply-To: <7b70e742-73e0-7171-1167-f5690bc634f7@mutix.org>


Christina O'Donnell <cdo@mutix.org> writes:

> Hi guix and guixesses,
>
> I'm still enjoying my guix machine crashing every other week despite changing all the software and half the hardware. So I'm trying to get kdump
> working so I can get to the real reason behind it. However I see that kdump-tools haven't been packaged yet. I see this as an opportunity for me to
> contribute to Guix, but it'll be my first time.
>
> - How interested would people be in me packaging kdump and related tools?

More debugging tools (and docs!) are always welcome IMHO.

> - Is there a reason why it's not there already?
>
> - Has it been tried before?

Searching the mailing lists doesn't turn up much, so I assume no one has
tried it:
https://yhetil.org/guix/?q=kdump

> The scope seems to be around 3-4 packages and a system service. Does that sound about right or could there be more I'm missing?
>
> On Debian there's:
>
> crash/testing,now 8.0.2-1 amd64 [installed,automatic]
>   kernel debugging utility, allowing gdb like syntax
>
> kdump-tools/testing,now 1:1.8.1 amd64 [installed]
>   scripts and tools for automating kdump (Linux crash dumps)
>
> libkdumpfile-dev/testing 0.5.1-1 amd64
>   libkdumpfile development libraries and header files
>
> libkdumpfile-doc/testing,testing 0.5.1-1 all
>   Kernel coredump file access (documentation)
>
> libkdumpfile10/testing 0.5.1-1 amd64
>   Kernel coredump file access
>
> python3-libkdumpfile/testing 0.5.1-1 amd64
>   Python bindings for libkdumpfile
>
> I'd want to package all of these except the python bindings. I see that kexec-tools is already in guix which is good!
>
> Is this a sensible direction?
>
> Kind regards,
>  - Christina

I'd say go for it!  If they are mostly written in C then you probably
don't have to package a lot of transitive dependencies.  Looking in
gnu/packages/linux.scm could be a good starting point for packaging
kernel related tools.


  reply	other threads:[~2023-07-31 17:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-30 12:36 Kdump Christina O'Donnell
2023-07-31 17:45 ` Csepp [this message]
2023-08-02 20:33   ` Kdump Christina O'Donnell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87leew9dhj.fsf@riseup.net \
    --to=raingloom@riseup.net \
    --cc=cdo@mutix.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).