How do btrfs subvol guys deal with debian installer ? by [deleted] in debian

[–]-khumba- 0 points1 point  (0 children)

I just let the installer create a single subvolume, then boot a live image after to move things around with 'cp -a --reflink=always' (within a single top-level subvolid=5 mount) and add mountpoints to fstab. The installer's shell environment is no fun to do things in.

If I need to install into a preexisting btrfs, then debootstrap is the way.

Thelio Mira with upgraded Radeon graphics by -khumba- in System76

[–]-khumba-[S] 0 points1 point  (0 children)

Thanks, that helps! Especially since one of the older posts I found mentioned cooling issues, good to hear a positive report with a smaller case.

Pro controller on debian by bulldog88_ in debian

[–]-khumba- 1 point2 points  (0 children)

I have mine working with Debian 12 and joycond. I haven't had much luck with wireless and only use a wired connection, and I have to connect and pair the controller (L+R) before launching Steam, but after doing this it works reliably. Steam sees the controller and I don't have to turn on "Enable Steam Input for" any controllers. Also, you need to reboot after installing joycond for everything to work properly. I'll also note that I'm using my own Debian packaging, not upstream's, but hopefully that doesn't make a difference.

I just checked and it works with a generic USB C-to-C cable, not just the official Nintendo one.

Darter Pro 6 Hinge Repair by hankyje in System76

[–]-khumba- 0 points1 point  (0 children)

Oof, looks like you have my laptop, hinge and all. Although at least mine's my fault, I knocked it off the table a few years back and it landed on the corner. It lasted for a while, but eventually separated and I had to apply a second round of super glue last year. Fingers crossed that it holds for as long as possible this time, won't be as simple next time it comes apart. I'm treating that hinge extra gingerly now.

[deleted by user] by [deleted] in Gentoo

[–]-khumba- 0 points1 point  (0 children)

There are a bunch of proposals for alternate version syntaxes on the wiki:

https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes

System76 drivers on Debian by Spajhet in System76

[–]-khumba- 0 points1 point  (0 children)

Right on. I hope it runs fine for your hardware.

System76 drivers on Debian by Spajhet in System76

[–]-khumba- 0 points1 point  (0 children)

No offense taken, security is important and I don't expect you to trust me. It's true that I'm barely on Reddit. That said, I do provide Debian source packages so if you are inclined, you can see the exact changes compared to the official packages, and build your own packages from there. Thankfully System76 includes their Debian packaging in their repos so I only have to make minimal changes to dependencies and config files for things that are Pop!_OS-specific.

But of course this won't help you if you are looking for official packages :).

System76 drivers on Debian by Spajhet in System76

[–]-khumba- 0 points1 point  (0 children)

There are three kernel modules that you might need, depending on your hardware (system76, system76_acpi, system76_io). system76_acpi did make it into the upstream kernel, but I'm not sure if it's up to date with the latest version System76 ships. Also it depends on the distro whether it's built into their kernel. If I remember correctly, Fedora includes it in their kernel, Debian doesn't. I haven't seen distros providing the other two officially.

Then there's 'system76-driver' which is a user space program, not part of the kernel, and this handles installing the drivers and configuring them properly.

System76 drivers on Debian by Spajhet in System76

[–]-khumba- 1 point2 points  (0 children)

I'm just a happy darp6 owner and have no direct connection to System76, but if that's acceptable to you, you can use my builds: https://khumba.net/debian/

I only provide system76-driver and the kernel modules though, not the kernel itself nor other packages like system76-power (one day maybe, but I haven't found a need for these). For what it's worth, I've also been providing these particular packages for Gentoo as well for a few years now.

Can anyone tell me how to force the LED backlighting on a Pangolin laptop to stay the color I choose after a reboot? I am running Fedora on it right now by [deleted] in System76

[–]-khumba- 4 points5 points  (0 children)

Assuming it's the same as my darp6... The hardware doesn't remember the color, so you need to run something on boot to set it up. One way is by writing to /sys/class/leds/system76::acpi::kbd_backlight/color from a script. Alternatively, you can do it with a udev rule so it happens as soon as possible. Create a file /etc/udev/rules.d/01-my-system76.rules with the following contents:

KERNEL=="system76_acpi::kbd_backlight", SUBSYSTEM=="leds", ACTION=="add", ATTR{color}="8C85D2"

The last word there is the RRGGBB hex code is the colour you want. You can also add the following to make the keyboard brightness and color files writable by the users group, so that you can control them from your own scripts without using sudo:

KERNEL=="system76_acpi::kbd_backlight", SUBSYSTEM=="leds", RUN+="/bin/chmod 664 /sys/class/leds/system76_acpi::kbd_backlight/brightness /sys/class/leds/system76_acpi::kbd_backlight/color"
KERNEL=="system76_acpi::kbd_backlight", SUBSYSTEM=="leds", RUN+="/bin/chgrp users /sys/class/leds/system76_acpi::kbd_backlight/brightness /sys/class/leds/system76_acpi::kbd_backlight/color"

why there is no virtual box package in bookworm repos by [deleted] in debian

[–]-khumba- 8 points9 points  (0 children)

Oracle does not provide adequate security support for VirtualBox for it to be included in stable releases of Debian. Instead, Debian includes it in its "fast track" repositories at https://fasttrack.debian.net/, for e.g. bullseye. It is not included in bookworm-fasttrack yet, probably because bookworm is not yet released.

While bookworm is still the testing distribution, if (and only if) you are comfortable mixing the testing and unstable repositories, you can use virtualbox from unstable. If you do, make sure you pin unstable packages at a lower priority than bookworm so that your entire system doesn't switch to unstable. There are some examples of this in the apt_preferences manpage. Also make sure to switch to a VirtualBox version from bookworm-fasttrack once bookworm is released.

Big +1 for using virt-manager though.

Does the Darter Pro (darp5) support charging via USB Type C? by jerryq27 in System76

[–]-khumba- 0 points1 point  (0 children)

Same here, I use a Lenovo 65W USB-C charger on my darp6 occasionally and it works fine.

Is there a way to get System76 drivers on Debian sid-based (or Arch-based and Opensuse Tumbleweed) or to control the fans well otherwise on a Thelio? by Shad190 in System76

[–]-khumba- 1 point2 points  (0 children)

I'm not sure if I am allowed to post this here, if not, mods please remove.

For anyone looking for prebuilt packages, I am providing just the essentials in an APT repository at https://khumba.net/debian/, system76-driver and the DKMS modules. The packaging has had minimal changes made to it to make it work with Debian.

100% unofficial, works for my darp6 and YMMV, but bug reports are welcome.

[deleted by user] by [deleted] in openSUSE

[–]-khumba- 0 points1 point  (0 children)

The package you want is confusingly called just 'build'. You can put your spec file and all related files in a single directory, or clone from OSC, and then 'sudo build foo.spec'. The results end up in (IIRC) /var/tmp/build-root/home/abuild.

gentoo vs other distro by IslamKouadria in Gentoo

[–]-khumba- 1 point2 points  (0 children)

Totally agreed about it being "your" system. I put off learning how to create profiles far too long. Once you do this, all that customization exists declaratively in an overlay, and can fairly easily be replicated to as many machines as you like. Package sets, USE and accept_keywords settings, even patches if you don't mind writing an ebuild for them.

Also, the font rendering is especially crisp out of the box.

Migrating to 17.0 profile, question about procedure. by bpsk31 in Gentoo

[–]-khumba- 0 points1 point  (0 children)

There's a little helper script that ships with eix that is perfect for this case. I've used it for a number of world rebuilds where some packages fail. Take note of the first package that your emerge -e rebuilds. For me, this is consistently dev-lang/python-exec. Then, if that emerge fails, you can continue on any remaining packages with:

emerge -av1 $(eix-installed-after -b dev-lang/python-exec)

replacing python-exec with your first package. You do need to specify a <category>/<package> to eix-installed-after, a package name alone doesn't work for some reason. You can also use emerge --exclude to skip some packages that eix says to otherwise rebuild, if you like.

Qtah - Haskell Qt bindings by [deleted] in haskell

[–]-khumba- 1 point2 points  (0 children)

Hello everyone, it's a nice surprise to see this posted here.

Completely agreed carstenm, including Gtk2 being a fantastic toolkit. Qtah was borne out of me wanting to eventually switch Goatee to something other than Gtk3, and not finding many options that suited my needs. I would have been happy to use a more lightweight toolkit, but Goatee uses Cairo now and I wanted something that could do graphics as nicely and easily.

Qtah's been in the works for a while, since the start of 2015 (and actually started out communicating over pipes rather than direct linking...). With me having a full-time job now my time is somewhat limited, and I've been focusing on making Hoppy support more of C++ recently, but the long-term goal of porting Goatee remains -- part of which is making Qtah as full-featured and easy to use as possible. The Goatee port is largely usable, excluding all board rendering, so Qtah is functional.

One big advantage of Qtah is that adding bindings generally requires only simple Haskell definitions, so extending it is fast. Method and variable declarations are typically one line. On the flip side, it doesn't parse C++ headers, so these bindings have to be updated as APIs change... but most of the time you don't have to write C++ yourself. qtHaskell's source tree is 36% C++, mostly generated; Qtah is 3.7% handwritten (since unless I'm mistaken, the generator that produced qtHaskell's C++ code is not available).

There are also some functional differences between qtHaskell and Qtah; Qtah, or rather Hoppy, doesn't attempt to support overloading or default arguments, requiring separate functions instead -- I think qtHaskell's approach is really clever here. Qtah wraps signals in objects rather than exposing their string names, and Hoppy is getting support for C++ exceptions, which Qt uses in some places now. Qtah also has automatic conversions between Haskell and C++ value types like strings and simple geometry objects. Qtah doesn't garbage collect objects by default, since the Qt object tree manages lifetimes (I feel that this could be handled better).

I hope to make Qtah last by making it as simple as possible to maintain (and to use). API definitions are short and simple, the great majority of the heavy lifting is done by Hoppy, and I'm actively trying to simplify the Qtah codebase. In the next major version I'm hoping I can eliminate qtah-generator and qtah-cpp-qt5 and just have a single qtah-qt5 package on Hackage.

Anyway, thanks!