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.
The Manjaro patch and kernel setting all fix upower-0.9.23, at least on my end anyway. I'll probably drop this into Slackworks for the time being unless/until it goes official.
Suspend works and Hibernate works, though I did have to add the resume=/dev/<swap_partition> to the boot loader command line for the kernel for pm-utils to work properly.
* upower 0.99.3 ?? This has a minor (IMHO) regression with respect to 0.9.23, but we would get a maintained version instead of an abandoned-by-upstream branch. The regression is basically this: upower-0.9.23 advised whether suspend/hibernate was possible itself, i.e. apps like xfce4-power-manager asked upower if it was possible and then invoked the suspend/hibernate by some means (in the case of xfpm, via pm-(suspend|hibernate)). That ability was removed from upower, so now ConsoleKit2 handles that side of things. However, CK2 only implemented a check for whether the hardware is *capable* of suspend/hibernate, which means that there is *not* a check for whether hibernate is actually *possible* - i.e. is there enough swap space available? The result is that in e.g. xfce, the hibernate option is always present in the logout dialog if the system is capable of hibernating, even though the system may not have enough swap space to do so (in my case, there is zero swap space). Is this a sufficient regression to avoid upower-0.99.3? Alternatively, does someone with more time want to grab the code from upower-0.99.3 and make whatever changes are needed to merge it into upstream CK2 (assuming license compatibility) and do a pull request with them? I glanced over it, and it looks relatively trivial to do for someone competent (I think even I can do it, so competence isn't necessarily a requirement ;-) - I just don't have time at the moment). If so, there's already an open issue there on the CK2 github page - just reference that in your PR. I'll be happy to test and add a Signed-Off-By on the PR if you'd like.
Robby, you might want to let Eric know Manjaro has some interesting KDE/Plasma5 patches especially for sddm which might promote some better compatibility in future releases.
Is there a possibility of including a 4.3 Kernel, maybe in testing? Slackware would have skylake compatibility (i'm getting a skylake laptop next month from work).
Robby, you might want to let Eric know Manjaro has some interesting KDE/Plasma5 patches especially for sddm which might promote some better compatibility in future releases.
Robby, can you let ReaperX7 know that the only relevant patch I found is the one that removes support for upower? Probably caused by them supporting systemd instead?
While you're at it, can you also tell ReaperX7 that I might take his posts more seriously if they contain more than just hot air, i.e. where are the pointers to those patches he is talking about?
Robby, can you let ReaperX7 know that the only relevant patch I found is the one that removes support for upower? Probably caused by them supporting systemd instead?
While you're at it, can you also tell ReaperX7 that I might take his posts more seriously if they contain more than just hot air, i.e. where are the pointers to those patches he is talking about?
Considering the fact you work on KDE/Plasma5 I figured I'd try and be nice and a good sport and at least tell you and others about the patches so you see about if they could fit into your work, if they didn't already, and maybe, just maybe be helpful.
Considering the fact you work on KDE/Plasma5 I figured I'd try and be nice and a good sport and at least tell you and others about the patches so you see about if they could fit into your work, if they didn't already, and maybe, just maybe be helpful.
Maybe next time I won't post a goddamned thing!
I think he was more annoyed with you mentioning patches without providing a link to said patches...
As he said in his post, he could only find one relavent patch that removed upower support.
The link was already there from gmgf's post, just to a subdirectory for upower only. Why should I have to repost something if he can't search the archive himself and do a bit of legwork? Sorry, but I'm not one of those who hand-holds. And besides, if you see my OS posting icon, it was done on my phone so honestly...
On my machine Slackware64-current as of now doesn't boot in UEFI mode, only Legacy.
Am I alone?
Also, I do not see the usefulness of the hardlinks /EFI/BOOT/{huge.s,initrd.img} as grub accepts paths to locations outside /EFI/BOOT and the paths in grub.cfg didn't change since 14.1 anyway.
I am not saying that these hard links are harmful, just wondering. Anyway I will try removing them and see if that makes a difference. Just puzzled as that seems to be the only difference with 14.1 in the /EFI and /isolinux directories.
EDIT: bad mkisofs command, sorry. Still, I will correct it and see what I get with vs without the hard links
EDIT2: booting on UEFI mode works with and without the hard links, that are thus useless unless I miss something.
Last edited by Didier Spaier; 12-18-2015 at 12:15 PM.
On manjaro all patches are not applied it's like fedora patches,
you have to look in the 'PKGBUILD', too see those used
some patch are obsolet
I always tend to look over patches and dry test them before committing them to a SlackBuild of my own. Mostly to see if they work at all. Yes, a lot of stuff gets pushed out over time and across versions, but often I find it useful to see if the patches have internal documentation. I did look over the PKGBUILD scripts. I do this even scanning archives from Fedora, Gentoo, LFS, and even upstream grabs from forums and mailing lists (which is how I got that quirky little Grub-2.02~beta2 btrfs-as-root-on-gpt detection fix patch of mine).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
