SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Since hplip-3.21.x requires avahi for network-build support, in order to include hplip-3.21.8 version in current tree, the distributor (Patrick) need to consider not only hplip itself but also avahi. I think that's why the hplip version of slackware64-15.0.RC is staying at "3.20.5".
Preferably, hplip could be shipped with libavahi that is static and only used for hplip.
Otherwise, it'd introduce potential vulnerability to every program which auto-detects libavahi at build time.
That is a long list of programs which may need a recompile in order to remove libavahi from the system in the future.
Preferably, hplip could be shipped with libavahi that is static and only used for hplip.
Otherwise, it'd introduce potential vulnerability to every program which auto-detects libavahi at build time.
That is a long list of programs which may need a recompile in order to remove libavahi from the system in the future.
Preferably, hplip could be shipped with libavahi that is static and only used for hplip.
Otherwise, it'd introduce potential vulnerability to every program which auto-detects libavahi at build time.
That is a long list of programs which may need a recompile in order to remove libavahi from the system in the future.
Hi, elcore.
I understood the impact of avahi on the whole system.
Thanks for your comments.
I don't intend to ask Pat to adopt avahi into slackware-15.0.
I will use hplip with avahi at my own responsibility.
I understood the impact of avahi on the whole system.
Thanks for your comments.
I don't intend to ask Pat to adopt avahi into slackware-15.0.
I will use hplip with avahi at my own responsibility.
No problem, it's your right to use it the way you see fit.
It's just that Jeebizz keeps requesting it, possibly without even considering the consequence.
I just suggest that it might be best to package it the same way as firefox (it has libraries packaged that aren't used by the system).
Possibly, there's a long list of benefits that avahi brings. I just can't see any because I don't even own a printer.
I understood the impact of avahi on the whole system.
Thanks for your comments.
I don't intend to ask Pat to adopt avahi into slackware-15.0.
I will use hplip with avahi at my own responsibility.
Quote:
Originally Posted by elcore
No problem, it's your right to use it the way you see fit.
It's just that Jeebizz keeps requesting it, possibly without even considering the consequence.
I just suggest that it might be best to package it the same way as firefox (it has libraries packaged that aren't used by the system).
Possibly, there's a long list of benefits that avahi brings. I just can't see any because I don't even own a printer.
I honestly did not realize that version now requires avahi - if it is that much of a problem hopefully libavahi will suffice? I don't know - I know it is unfortunate that these projects are requiring more and bigger dependencies - but it is what it is. I don't know if hplip has an 'esr-like' release either, it is just hplip as is.
Yeah, hplip can easily be packaged with any library it depends on, without having that library proliferate across the entire system.
IMHO, that would suffice.
Quote:
Originally Posted by Jeebizz
I know it is unfortunate that these projects are requiring more and bigger dependencies - but it is what it is.
Depends on one's point of view, I'm sure everything "is what it is" somewhere but that totally depends on where that is.
Avahi's not going to be hosted on my server without a good reason, TBH "some random developer@hp.com says so" and "debian already ship this" are not good enough reasons.
The Plasma 5.23.0 was already built here and it works very nice - I found no issues, so far.
Looks like the KDE developers tried their best for this Plasma 25th Anniversary Edition.
And let's do not forget that only on the next month will follow another 3 patch releases on the weeks cadence: 1, 1, 2
In fact, I've already had several boxes with Plasma 5.23 Beta built by myself.
And even as Beta, it was impressively stable. On that Beta, the single bugs which I found was the failures to load the Fonts page on System Settings and the OpenGL page on Info Center - both also fixed in the final release, BTW...
Last edited by LuckyCyborg; 10-14-2021 at 11:24 AM.
Depends on one's point of view, I'm sure everything "is what it is" somewhere but that totally depends on where that is.
Avahi's not going to be hosted on my server without a good reason, TBH "some random developer@hp.com says so" and "debian already ship this" are not good enough reasons.
My primary reason is my HP printer; and maybe, maybe - VLC (which also has avahi listed as a dependency), but eh I find myself using mplayer more anyways so.... I mean if it comes down to it, I probably could fall back to just CUPs - but my only reason to even own a HP printer was their support for Linux.
4 October 2021: LLVM 13.0.0 is now available for download! LLVM is publicly available under an open source License. Also, you might want to check out the new features in Git that will appear in the next LLVM release. If you want them early, download LLVM through anonymous Git.
4 October 2021: LLVM 13.0.0 is now available for download! LLVM is publicly available under an open source License. Also, you might want to check out the new features in Git that will appear in the next LLVM release. If you want them early, download LLVM through anonymous Git.
It built fine here the day it was released, but spirv-llvm-translator wasn't compatible. There is a 13.0 branch for that, and it compiles, but it won't build against the SPIRV headers in vulkan-sdk, and that won't build against the updated headers.
I'd like to include it (which is why I built it here to test), but I'm not sure it's a good idea. But if anyone has solutions for those packages I'd be willing to look at it again.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
