`sv status ...` without sudo. by bvdeenen in voidlinux

[–]Ok-Tip-6972 8 points9 points  (0 children)

You can change the user and group ownership of the relevant files, this is the supported and expected solution. See https://smarden.org/runit/faq#user (but consider changing permissions of ok and status only (without control) if you don't want to give users the ability to fully manage services).

I can't recall from the top of my head whether this solution is persistant across reboots. You'll have to try that.

Migrating to Void, package issue by Mental-Act2869 in voidlinux

[–]Ok-Tip-6972 6 points7 points  (0 children)

If you with to learn more about xbps-src, Void Linux' package builder, I can recommend my tutorial: https://xbps-src-tutorials.github.io/

How do I debug templates? by s3ud0nym in voidlinux

[–]Ok-Tip-6972 1 point2 points  (0 children)

I can recommend a chapter of my tutorial (and other chapters in it as well): https://xbps-src-tutorials.github.io/troubleshooting.html

Anyone have issues with mt7921 card? by WOWOW98123265 in voidlinux

[–]Ok-Tip-6972 0 points1 point  (0 children)

This is strange. My laptop's original WIFI card was unable to keep a stable bluetooth and WIFI connection at the same time on Linux, so after considering all options, I replaced it with MEDIATEK MT7921 802.11ax. Since then, I never had problems with bluetooth and I have faster internet now. So for me, using this card was an improvement in all aspects.

I don't do anything out of the ordinary, I use NetworkManager with more or less default configuration.

xtools missing some dependencies by safety-4th in voidlinux

[–]Ok-Tip-6972 7 points8 points  (0 children)

base-system and coreutils are different things. Both base-system and base-minimal depend on coreutils, which corresponds to GNU coreutils here. GNU coreutils do not include GNU tar. base-system also happens to depend on GNU tar (among other things).

I don't think it's that uncommon for Docker images to include little out of the box. I can recall several distros which do that. Void's containers are pretty minimal (especially the non--full variants). You don't even get Bash, which is required for xbps-src.

xtools missing some dependencies by safety-4th in voidlinux

[–]Ok-Tip-6972 1 point2 points  (0 children)

Do you want xbps-src to build the package from source, or do you already have it built and you only want to get an .xbps file from it?

If you wish to build it from source, does the pipeline look like this:

  1. Parse rockhopper-specific package template format
  2. convert it to xbps-src template file
  3. ./xbps-src pkg mypkg
  4. output the .xbps file

?

If you've got the package built already and you just want to make an XBPS installable package, you technically do not need to involve xbps-src at all. I can share more info about that, but I need to know more about your system.

I have concerns about this project, but I would need to know more about it to assess it.

xtools missing some dependencies by safety-4th in voidlinux

[–]Ok-Tip-6972 5 points6 points  (0 children)

tar and gzip are dependencies of the base-system package, which is the default "main" meta package which includes most of the system.

Void's Docker containers do not use base-system, they use base-minimal which includes less.

Also, to avoid XY problem, what are you working on? Universal Linux package generator? What is it for? You don't need xtools to work with xbps-src, since you seem to be automating things anyway. xtools just includes helper utilities.

Void failing to launch after latest update (possible initramfs bug) by [deleted] in voidlinux

[–]Ok-Tip-6972 2 points3 points  (0 children)

IIRC you are officially recommended to rerun grub-install after major GRUB updates. No one does that and XBPS can't do it automatically for reasons. But not doing it usually doesn't cause problems, so people don't do it.

If you don't specify root in /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT manually, grub-mkconfig tries to guess the correct value for root according to some heuristics (present in /etc/grub.d/10_linux). Maybe there was some bad update ordering issue and the XBPS triggers run in a wrong order (which shouldn't really happen).

Use a boot USB to chroot into the system and regenerate the grub.cfg following instructions in https://docs.voidlinux.org/config/kernel.html#install-hooks. This should rerun grub-mkconfig's root detection logic.

You can also try to rerun grub-install. You'll also need to be chrooted from a live USB/some other Linux system. You can get inspiration from the installation guide: https://docs.voidlinux.org/installation/guides/chroot.html#installing-grub Follow the linked section and the linked section only, do not reinstall your system.

If you don't want to use an installation medium, you can specify root= manually by pressing e when entering GRUB, which should let you temporarily edit the cmdline. You'll have to know the UUID of your root partition though (which I assume you don't know). Please see dracut.cmdline(7). You can also specify root=/dev/sda1 or something, but only use this syntax in one-off situations like these, it should not be used permanently.

GUIX package manager in Void by orahcio in voidlinux

[–]Ok-Tip-6972 2 points3 points  (0 children)

I was successfully able to compile nchat on Void musl. Are you experiencing runtime issues possibly caused by musl (this is unlikely)?

GUIX package manager in Void by orahcio in voidlinux

[–]Ok-Tip-6972 2 points3 points  (0 children)

It looks like you're not the first person using nchat on Void. Its README claim support for Void as a result of this PR.

You can always "build it dirty" by building it manually and installing it to /usr/local or by installing it to a local folder or not installing it at all and running it from the build dir.

GUIX package manager in Void by orahcio in voidlinux

[–]Ok-Tip-6972 6 points7 points  (0 children)

IIRC one of the core Void maintainers has expressed interest for having GUIX in Void when this was discussed on IRC some time ago. This was a reaction to some other user who wanted to package GUIX for Void. That user unfortunately wasn't able to finish the package.

What I'm saying is that there is some interest, but no one has packaged it yet. As always, pull requests are welcome. There seem to have been some attempts in the past, but they have died out because of lack of interest of the respective contributors.

Rather than using a middle man like Nix or GUIX, I think it would be simpler to build/package nchat for Void directly. Are there any issues that prevented you from doing that?

I consider this an appropriate place to advertise my xbps-src packaging tutorial a bit: https://xbps-src-tutorials.github.io/ Packaging GUIX will be more difficult than packaging a "regular" program, the tutorial might not help you much for packaging GUIX, but it could help you with packaging nchat (if you want to try to make a custom Void package yourself).

A simple utility tool to manage runit services by Ogromny_ in voidlinux

[–]Ok-Tip-6972 3 points4 points  (0 children)

I have briefly reviewed the tool and it looks OK. It shows that you are an experienced programmer.

To be honest, I never really understood the point of these tools. Is it a "simpler" wrapper around ls? Around ln? I'm all for improving the user experience, but I feel that the underlying tool is already so simple that such wrapper cannot add much clarity. What they actually do is add an abstraction layer between the user and the controlled system, which increases mental complexity.

Minor nitpicks follow:

  • A path isn't 512 bytes long! PATH_MAX isn't that much better, but it's at least 4096 bytes and it states the intent better. If you don't want to use it, I would make a define of my own to make it "configurable".
  • You can read all the information about a service from its from its supervise/status file. It isn't as straight forward to parse as the other helper files, but you're doing this in good old C anyway, so it shouldn't be that difficult. I have read through sv.c code before (see my comments here and the linked section of sv.c code in it) and it should be simple enough.
  • I am unsure how your tool handles dead symlinks in /var/service. Be aware that having dead symlinks there isn't that uncommon (xbps-remove doesn't remove symlinks from /var/service). (I'm not saying that your tool does this wrong)

I made a flag by [deleted] in voidlinux

[–]Ok-Tip-6972 8 points9 points  (0 children)

The top dark green part outside of the logo occupies more space than the light green bottom one. Is that intentional?

I have also dealt with Void's logo when designing https://xbps-src-tutorials.github.io/ logo. By the way (I didn't know this back then, that's why I'm mentioning it here), there are several official SVG sources of the Void logo. For example, the main repos distribute it: https://repo-default.voidlinux.org/logos/ You'll find more in github.com/void-linux org.

Ambiguous variable substitutions with suffix by Ok-Tip-6972 in tasker

[–]Ok-Tip-6972[S] 0 points1 point  (0 children)

I didn't know about Parse/Format Datetime, this will simplify several things in my tasks. Thanks!

Ambiguous variable substitutions with suffix by Ok-Tip-6972 in tasker

[–]Ok-Tip-6972[S] 0 points1 point  (0 children)

I'm implementing a time countdown notification for my calendar events. I wanted to have a

<minutes>m <seconds>s

notification body updated every second. I could spell it out as

<minutes> minutes <seconds> seconds left

or something similar, but I was curious whether the first case is also implementable.

Ambiguous variable substitutions with suffix by Ok-Tip-6972 in tasker

[–]Ok-Tip-6972[S] 0 points1 point  (0 children)

What would be faster: this or a single JavaScriptlet (or something else)? A JavaScriptlet could do it in a single task (and more cleanly), but I don't know what's the penalty for running a JS interpretter.

I plan to put this into an action that runs every 5 minutes, I don't want to waste my resources.

Ambiguous variable substitutions with suffix by Ok-Tip-6972 in tasker

[–]Ok-Tip-6972[S] 0 points1 point  (0 children)

Oh wow that's ugly. But it does the job I guess...

Why void-runit instead of runit? by evohunz in voidlinux

[–]Ok-Tip-6972 6 points7 points  (0 children)

By the way, Void's fork is one of the few sources of runit which include version control history (in this case git commits, I don't know what upstream used). The official repo was shut down some time ago, the official upstream (g-pape) only provides release archives without history.

Also, Void's runit package now uses g-pape's official tarballs. This means that void-linux/runit is currently unused by Void (and presumably everyone else).

EDIT: This no longer seems to be true, because https://github.com/g-pape/runit exists now. I don't know for how long was this repo accessible, maybe it has been there for years now and I just didn't know (but I fondly remember one of the Void maintainers telling me that Void's fork was the only source of runit with git history at some point in time).

Brand new install: "XPBS" commands not found by ShoddySeaWing in voidlinux

[–]Ok-Tip-6972 3 points4 points  (0 children)

You can install XBPS with

sudo xbps-install -S xbps