kixik @ kixik @lemmy.ml

Posts

72

Comments

281

Joined

4 yr. ago

@infeeeee@lemm.ee, I think I got now why by default the keep strip and debug together. stripseems to be removing them only from the non -debug package generated, and not doing so on the -debug package generated. So they actually make sense together.

That said, you were right. If not interested on the -debug packages getting generated, just use !debug.

Greetings !

LTO is a different thing, and I'm not sure why it was enabled by default until now (well, It's said it doesn't play nice with clang), see this RFC from 2 years back. Also notice what current makepkg uses is LTOFLAGS="-flto=auto". The idea according to the RFC, is that for packages failing to use the default, options=('!lto') can be added to the PKGBUILD.

So that should be safe, and iif you're wondering, it stands for Link Time Optimization. On AUR, I guess users adding new packages or maintaining packages, should be aware, and add that option if they find out LTO by default is giving issues.

I guess the current defaults are sane. All I said the original post, is that the strip option, which is still enabled by default gets rid of the debug symbols. So yes, now they are getting generated by default, but also stripped off by default. And that's what I don't understand. Perhaps that's a good topic for the arch-general mailing list, hoping some developer is around to clarify things. Perhaps the current makepkg.conf is an intermediate one, and there will come another one using !strip instead. Or maybe currently strip doesn't get rid of all debug symbols generated by debug. But the current documentation on makepkg.conf is not clear enough...

So I would leave the current defaults if it's not clear yet if changing them is something that would help you out. As mentioned, with strip you shouldn't get that huge packages. But also it'd be good to make sure, asking on a Arch forum involving devs...

strip has need enabled since I can remember, so yes it was enabled. The change was from this:

    
OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug !lto)


  

To this:

    
OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge debug lto)


  

Actually enabling debug and lto, but keeping strip. So unless I'm missing something, what it adds on one side, it removes it on the other, :)

You can confirmed with the specif change on the referenced MR.

But strip is still enabled on new makepkg.conf, so all debug symbols get removed when packaging. Actually I don't get it why stripping debug symbols while also generating them first. So are those two actually compatible?

Will they keep doing that, is there a policy about it written somewhere? Have they expressed something about it in a forum or news, just like mint did at some point when ubuntu started with firefox mess and others. I can't find anything from their web site, and on this reddit post, Does Rhino Linux use Ubuntu mirrors for apt packages?, it seems they follow closely ubuntu's mirrors, and if they do so, whatever ubuntu stops supporting on APT, sounds like rhino will stop supporting on APT as well.

This would be very sad at least for me.

Besides !rhinolinux@lemmy.ml, which is not officially supported by rhino, there are 5 social media mechanisms they support, which I don't have account for neither I want to, and I don't want to subscribe to another mailing list either. Good old IRC is not one of the contact mechanisms supported BTW, neither email (but even if they did, I don't want to subscribe to yet another email list)... Perhaps someone on any of those official communication channels can ask and share what they answer, making a reference to what they answered already regarding repos...

Many thanks !

Are you looking to clean up your client inbox, or the server inbox?

If your client inbox, you don't need a plugin, on the account settings synchronization & storage, on the section disk space, select the synchronize the most recent and specify the amount days, months, years, whatever.

If you want to remove too old messages from the server, perhaps the server itself offers a way to do so...

I recommend you to explore sourcehut as well, if you're not afraid of something different to gitlab/github workflows.

Yes, I'm wishing Rhino does the same, so I'm asking if someone knows... Thanks !

Yeap, I just mentioned Mint because I'm aware about its policy, which is the one I'm hopping Rhino also follows, but I can't tell.

I read about its rhino-pkg, which is just a wrapper as I mentioned. My concern is not about not being able to use each package manager directly, but rather on its packaging policy. Is it to follow canonical/ubuntu decisions? Or will it keep packaging what it as a distro offers to users on deb packages controlled by apt?

Yes, I cross posted it to !rhinolinux@lemmy.ml once I noticed it had a community, though I guess that would be the 1st post ever, :)

Being using mull for so long, even when it was not available on f-droid official repos, but only divestos f-droid repo.

The only thing really bothering on mull is a config one really must change, security.OCSP.require, the default to true prevents reaching several sites. But other than that mull shouldn't get in your way, and one can change other config to one's liking if in need.

understood, so no big issue with grub, cool !

I'm wondering how both mkinitcpio alternatives work on non systemd boxes with full disk encryption. With both, I refer to dracut and booster. On its origins I believe dracut was pretty tight involved with systemd, and booster is developed/maintained by an arch developer/user if not mistaken, and arch supposes systemd, though none of those things actually mean non systemd boxes are not supported.

I'm also wondering if the initrds generated can be launched by grub (I do /boot partition encryption/decryption with grub), and I also do / full partition encryption with luks. This booster issue sort of indicates as of now booster initrd images can't be loaded by grub...

I see, I didn't dig into the cause, being sort of a buffer overflow. Indeed that would be prevented by other languages, sorry for my misinterpretation. Other vulnerabilities unintentionally introduced by developers on logging what shouldn't are not dependent on anything other than auditing them, but that was not the case then.

True, the logging is part of the library, but it's totally centered on what the developers are logging. It's a bad practice to log sensitive information, which can be used by someone with access to the logs for sure, but that doesn't mean the library is broken and has to be replaced. The library's logs need to be audited, and this as true for glibc as it is for musl, no exception, and it's not a one time thing, since as the libraries evolve, sensitive information can be introduced unintentionally (perhaps debugging something required it on some particular testing, and it was forgotten there).

BTW, what I meant with the language, is that no matter the language, you might unintentionally allow some sensitive information in the logs, because that's not a syntactic error, and it's not violating any compiling rules. It's that something is logged that shouldn't.

Also, the report indicates that the vulnerability can't be exploited remotely, which reduces the risk for several systems...

That's why I said library or language (someone else suggested rust).

The vulnerability is on logs, and that has nothing related to the library. Even less with the language...

Using wayfire (disabling the fancy resources eating plugins) + waybar + plus a bunch wlr utilities (some from sway).

I'm using integrated intel gpus. There's a laptop with both the integrated intel gpu and a nvidia discrete one, but I had to configure the bios to only use the inegrated one, both the binary nvidia drivers, and the open source nvidia drivers fail to set fbdev=1 (the external hdmi monitor is the one associated to the nvidia gpu, and it gets a blank screen), which is required for enabling KMS, which is required for wayland, so no luck. Nouveau actually works, but it's not stable enough, after some time of use the monitor turn off and there's no way to turn it back on, and it feels slow or lagging compared to the intel gpu, although it should be the opposite. So I gave up on nvidia on that laptop, and any other box only has the integrated intel gpu anyways. I've read of successful stories with nvidia, both with the binary and the open drivers, but I think it's not a generic thing that all nvidia gpus will work well on wayland with nvidia drivers. The noveau drivers are the only ones working for some gpus, but not stable enough. So I stick with the recommendation to stay away from nvidia if using wayland...

I guess although WM still applies, on the wayland jargon they're called compositors, and the wayland compositors are not as light as the Xorg WMs, since there's no Xorg server, and part of the responsibility of the server goes to the compositors on wayland...

There's labwc, which is the compositor I would have chosen, but the developer decided to stick with xml configuration equivalent to the the openbox one, and also with the openbox themes/styles, which I never liked. On Xorg I used fluxbox + tint2 + ..., and I tried openbox, but totally disliked it compared to fluxbox... But other than config and theming, I like its idea of being a light compositor.

Actually by disabling the plugins I am on wayfire, it's pretty much labwc but with new decent config (I really like its config BTW), and using the gui toolkit theming, so no specific wayfire theming at all, which is nice, as opposed to the labwc own theming... Still, labwc is also an option for some.

Wayfire and labwc are not tiling compositors as most of all others, :)

I like the SMS gate app from f-droid suggested.

A different approach to read SMS from other devices, for example your PC, would be using kdeconnect. It's supposed to allow you to read current messages, receive messages, and reply to messages, even send messages I believe. So perhaps an option, though not a syncing tool to keep SMS messages somewhere else, and I can't tell about the encryption involved...

I'll take a look at iosevka fonts, thanks !