Re: [arch-general] Does LTS package really not fit to Rolling Release model and Arch Philosophy?
On Sat, Nov 19, 2016 at 08:31:22 +0900, Ken OKABE via arch-general wrote: > > The kernel is a different, as it can cause an unbootable situation. > > [...] > > On what reason or scenario, some LTS(maybe incompatible to the kernel) > will break kernel or make the system unbootable? Ideally never. The unbootable situation may be caused by the *kernel itself*. I admit I'm a little amused about my forum post sparking a ML discussion, but to quote another post on that same thread (by Jason): https://en.wikipedia.org/wiki/Straw_man Best, Tinu a.k.a. ayekat signature.asc Description: PGP signature
Re: [arch-general] Nvidia backlight control - acpi_video0/brightness changes - display doesn't?
On 11/18/2016 11:02 PM, David C. Rankin wrote: > I've got to get something figured out. This laptop will absolutely blind you > when you open a browser, or anything with a white background. I have the > backlight set at 40% in win10 and that works well. Here it looks like it is on > MAX continually. I will keep at it. If anyone has any other idea, let me know. > Thanks. I don't believe this! I have I can effect the brightness with xrandr, but the output name is 'LVDS-0' instead of 'LVDS' (as it is on my other laptops). I don't know if this could be the whole problem with the normal backlight controls not working -- anyone have any idea? I'll just modify the xbacklight script to call xrandr instead of xbacklight and pass it fractional values between 0.5 and 1.0. Strange indeed. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Nvidia backlight control - acpi_video0/brightness changes - display doesn't?
On 11/18/2016 03:56 AM, Warp wrote: > Do you use any special kernel boot parameters? > > Using "acpi_backlight=vendor" helped me in a similar situation, though it > was about another option interfering with backlight control. > > Sylvain Thanks Sylvain, I've tried with both "acpi_backlight=vendor" and "acpi_backlight=none", has no effect on backlight (except to remove the sysfs acpi defaults). I've also tried with xbacklight (and corrected the divide by zero in the script recommended on the Backlight wiki page) https://wiki.archlinux.org/index.php/Backlight#sysfs_modified_but_no_brightness_change xbacklight -get (reports nothing) So I really can't expect the -set option to set anything, frustrating... When I use the backlight keys, the 'brightness' and 'actual_brightness' values go up/down as it should AND the little screen indicator showing the level pops up and shows the current and correct level, but the display brightness never changes. I've got to get something figured out. This laptop will absolutely blind you when you open a browser, or anything with a white background. I have the backlight set at 40% in win10 and that works well. Here it looks like it is on MAX continually. I will keep at it. If anyone has any other idea, let me know. Thanks. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Does LTS package really not fit to Rolling Release model and Arch Philosophy?
>>The kernel is a different, as it can cause an unbootable situation. I can only imagine as follows: 1-a linux boot succesfully 1-b linux-lte boot succesfully 2 TYY or some DM load successfully 3-a Plasma might fail to launch 3-b Plasma-LTS might fail to launch On what reason or scenario, some LTS(maybe incompatible to the kernel) will break kernel or make the system unbootable? Regards, Ken On Sat, Nov 19, 2016 at 3:54 AM, Eli Schwartz via arch-general wrote: > On 11/18/2016 12:46 PM, Doug Newgard wrote: >> On Sat, 19 Nov 2016 02:34:08 +0900 >> Ken OKABE via arch-general wrote: >> >>> What kind of scenario in the real world to be problematic to maintain >>> KDE Plasma LTS line as separated packages from non-LTS? >> >> A whole lot more work for litte/no gain. The kernel is a different, as it can >> cause an unbootable situation. > > This. > > LTS releases are fundamentally in violation of the concept of "rolling > release" -- we sort of want the latest everything! > > Sometimes, other concerns necessitate doing something that isn't > strictly the Arch Way, however. The kernel is an excellent example -- as > Doug said, if you cannot boot your computer there isn't a lot else you > can do, it is time to pull out the installation media... > > For the firmware responsible for booting your computer and which is > required even to get access to the emergency root shell, it is worth > dealing with LTS. > If something goes wrong with the latest plasma, okay, fine, you can > revert the package update as a stopgap measure, debug plasma to submit > bug reports and get it fixed, google workarounds... but your computer is > not soft bricked (or hard bricked, but that is another matter entirely). > > Just like most LTS software, I do not see plasma-lts getting into the > repos. However, the AUR exists in part to give such pet projects a home. > Arch is ultimately whatever you make of it. But the [community] repo > isn't the right place for personal experiments. > > -- > Eli Schwartz
Re: [arch-general] Does LTS package really not fit to Rolling Release model and Arch Philosophy?
> Ralf, exactly, and that is to what I'm attracted. That they maintain it doesn't necessarily mean that they will also make sure that it works with new library versions. It sounded more like bug- and security fixes to me. Arch is not like Debian or even Ubuntu. Most libraries get updated as soon as upstream releases new versions, which is quite often. I doubt the KDE developers will guarantee that the LTS version will work with every library upgrade. It's just too much work. The kernel is not only critical, but also much easier to manage - compared to something like Plasma, which depends on anything and everything, the kernel is for most intents and purposes a self-contained, interchangeable box. Userspace software is an entirely different category, and a huge DE like Plasma makes things even harder. Someone might try to maintain it on the AUR, but that could easily mean upwards of 50 packages that constantly need to be tested against new versions of their dependencies. > In my experience, linux GUI environment(DE) > tends to be easily broken with frequent upgrades Early Plasma versions where horrible, but its much better now. If it's still not stable enough for you, you might want to consider switching to something lighter, like XFCE or even a simple window manager (WM). I have a full Plasma installation to play around with, but my day-to-day use is entirely in i3wm. Properly set up, that beats even as good a DE as Plasma for me. If tiling is not your thing, there are other options out there, such as Openbox. (And mny more: [0]) Cheers, Bennett [0]: https://wiki.archlinux.org/index.php/Window_manager -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Does LTS package really not fit to Rolling Release model and Arch Philosophy?
Bruno, >Yes, but what if plasma-lts doesn’t build with the new libwhatever? Will plasma-lts have updates that take care of this? Will they be available ahead of libwhatever release? >Then, consider the number of package plasma-lts represents. Multiply by their number of dependencies. Especially, kframeworks will continue moving ahead. Will compatibility with newer versions be assured? I’m not quite sure, since I don’t see why you would use lts plasma with latest frameworks. I do not know the detail of how the dependency/libs of Plasma-LTS managed by the KDE developers, but, again, it is LTS. https://community.kde.org/Schedules/Plasma_5 According to their time schedule, they will release 5.8* LTS and 5.9.* simultaneously. I'm sure they will work properly for QT5 or wayland etc. compatibility issue and that is their problem, not Arch package maintainers. Please note I'm not saying multiple versions of DE co-existing system, but simply alternative LTS DE package. If there is another, LTS specific, old lib (QT5 or wayland whatever) needed, that is the lib Plasma-LTS depends on. Regards, Ken On Sat, Nov 19, 2016 at 2:49 AM, Bruno Pagani wrote: > Le 18/11/2016 à 18:34, Ken OKABE via arch-general a écrit : > >> Arch-wiki suggests: >> https://wiki.archlinux.org/index.php/System_maintenance#Install_the_linux-lts_package >>> Tips and tricks >> The following tips are generally not required, but certain users may >> find them useful. >>> Install the linux-lts package >> The linux-lts package is an alternative Arch kernel package, and is >> available in the core repository. This particular kernel version has >> long-term support (LTS) from upstream, including security fixes and >> some feature backports. It is useful if you prefer the stability of >> less-frequent kernel updates or if you want a fallback kernel in case >> a new kernel version causes problems. >> >> and some guy told me >> >>> The LTS kernel is strictly speaking not in line with the "Arch philosophy" >>> (if you use that term to describe the rolling release nature of Arch) - but >>> it is also not a "typical" piece of software, for two reasons: >>> It is the kernel, i.e. the core building block of what makes this operating >>> system work. It is crucial to make sure it works correctly, so in case of >>> an issue, having the possibility to go back to an LTS release (or forward >>> to a non-LTS release) is in the interest of many users. >>> It is mostly not affected by dependency issues arising from version >>> mismatches (like soname bumps) - you can plug in any kernel you want >>> without any major issues (except maybe hardware support). >>> The second point also allows it to be packed in a rolling release >>> distribution like Arch without causing trouble for maintainers. Maintaining >>> an old user-space tool (i.e. backporting fixes, ensuring library version >>> compatibility, ... well, see Debian) is incompatible with Arch Linux. >> How hard or problematic to maintain a LTS package, for instance, KDE >> Plasma LTS edition package on Arch rolling-release-model? >> >> https://www.kde.org/announcements/plasma-5.8.0.php >>> Tuesday, 4 October 2016. Today KDE releases its first Long Term Support >>> edition of its flagship desktop software, Plasma. This marks the point >>> where the developers and designers are happy to recommend Plasma for the >>> widest possible audience be they enterprise or non-techy home users. >> What kind of scenario in the real world to be problematic to maintain >> KDE Plasma LTS line as separated packages from non-LTS? > > Well, first “affected by dependency issues arising from version > mismatches (like soname bumps)”. So every time something that any > plasma-lts package depends on require an ABI bump, you have to recompile > things. You might say, devs have tools to do so quite automatically. > Yes, but what if plasma-lts doesn’t build with the new libwhatever? Will > plasma-lts have updates that take care of this? Will they be available > ahead of libwhatever release? > > Then, consider the number of package plasma-lts represents. Multiply by > their number of dependencies. Especially, kframeworks will continue > moving ahead. Will compatibility with newer versions be assured? I’m not > quite sure, since I don’t see why you would use lts plasma with latest > frameworks. > > And that’s only one thing I can think of on the top of my head. > > So, lot of maintenance burden, for quite no gain. > > Bruno >
Re: [arch-general] Does LTS package really not fit to Rolling Release model and Arch Philosophy?
On 11/18/2016 12:46 PM, Doug Newgard wrote: > On Sat, 19 Nov 2016 02:34:08 +0900 > Ken OKABE via arch-general wrote: > >> What kind of scenario in the real world to be problematic to maintain >> KDE Plasma LTS line as separated packages from non-LTS? > > A whole lot more work for litte/no gain. The kernel is a different, as it can > cause an unbootable situation. This. LTS releases are fundamentally in violation of the concept of "rolling release" -- we sort of want the latest everything! Sometimes, other concerns necessitate doing something that isn't strictly the Arch Way, however. The kernel is an excellent example -- as Doug said, if you cannot boot your computer there isn't a lot else you can do, it is time to pull out the installation media... For the firmware responsible for booting your computer and which is required even to get access to the emergency root shell, it is worth dealing with LTS. If something goes wrong with the latest plasma, okay, fine, you can revert the package update as a stopgap measure, debug plasma to submit bug reports and get it fixed, google workarounds... but your computer is not soft bricked (or hard bricked, but that is another matter entirely). Just like most LTS software, I do not see plasma-lts getting into the repos. However, the AUR exists in part to give such pet projects a home. Arch is ultimately whatever you make of it. But the [community] repo isn't the right place for personal experiments. -- Eli Schwartz
Re: [arch-general] Does LTS package really not fit to Rolling Release model and Arch Philosophy?
>What's completely missing by the kernel related explanation is, that upstrem provides, IOW maintains longterm linux, https://www.kernel.org/ . Does KDE upstream maintain KDE Plasma LTS? Ralf, exactly, and that is to what I'm attracted. https://community.kde.org/Schedules/Plasma_5 According to the planned release schedule for Plasma 5, the 5.9.0, that is non-LTS will be released on 2017-01-31, but I simply want to stick to 5.8-LTS until the next Plasma-LTS release for the most concerned GUI stability of the system. In my experience, linux GUI environment(DE) tends to be easily broken with frequent upgrades, and I'm very happy to hear KDE project releases their first Long-Term-Support edition for Plasma. Regards, Ken On Sat, Nov 19, 2016 at 2:53 AM, Ralf Mardorf wrote: > On Sat, 19 Nov 2016 02:34:08 +0900, Ken OKABE via arch-general wrote: >>What kind of scenario in the real world to be problematic to maintain >>KDE Plasma LTS line as separated packages from non-LTS? > > Apart from the policy, the problem are maintainers willing it to do and > to provide it by a third party repository. It's not that much work > to provide it and all dependencies as separated packages, as long as > you don't want e.g. security patches. IOW if you expect some quality, > it's not just installing everything to /opt or providing it by > something like snaps, you also need to maintain it, e.g. if there > should be known vulnerabilities. > > What's completely missing by the kernel related explanation is, that > upstrem provides, IOW maintains longterm linux, > https://www.kernel.org/ . Does KDE upstream maintain KDE Plasma LTS? > > Regards, > Ralf
Re: [arch-general] Does LTS package really not fit to Rolling Release model and Arch Philosophy?
On Sat, 19 Nov 2016 02:34:08 +0900 Ken OKABE via arch-general wrote: > What kind of scenario in the real world to be problematic to maintain > KDE Plasma LTS line as separated packages from non-LTS? A whole lot more work for litte/no gain. The kernel is a different, as it can cause an unbootable situation.
Re: [arch-general] Does LTS package really not fit to Rolling Release model and Arch Philosophy?
On Sat, 19 Nov 2016 02:34:08 +0900, Ken OKABE via arch-general wrote: >What kind of scenario in the real world to be problematic to maintain >KDE Plasma LTS line as separated packages from non-LTS? Apart from the policy, the problem are maintainers willing it to do and to provide it by a third party repository. It's not that much work to provide it and all dependencies as separated packages, as long as you don't want e.g. security patches. IOW if you expect some quality, it's not just installing everything to /opt or providing it by something like snaps, you also need to maintain it, e.g. if there should be known vulnerabilities. What's completely missing by the kernel related explanation is, that upstrem provides, IOW maintains longterm linux, https://www.kernel.org/ . Does KDE upstream maintain KDE Plasma LTS? Regards, Ralf
Re: [arch-general] Does LTS package really not fit to Rolling Release model and Arch Philosophy?
Le 18/11/2016 à 18:34, Ken OKABE via arch-general a écrit : > Arch-wiki suggests: > https://wiki.archlinux.org/index.php/System_maintenance#Install_the_linux-lts_package >> Tips and tricks > The following tips are generally not required, but certain users may > find them useful. >> Install the linux-lts package > The linux-lts package is an alternative Arch kernel package, and is > available in the core repository. This particular kernel version has > long-term support (LTS) from upstream, including security fixes and > some feature backports. It is useful if you prefer the stability of > less-frequent kernel updates or if you want a fallback kernel in case > a new kernel version causes problems. > > and some guy told me > >> The LTS kernel is strictly speaking not in line with the "Arch philosophy" >> (if you use that term to describe the rolling release nature of Arch) - but >> it is also not a "typical" piece of software, for two reasons: >> It is the kernel, i.e. the core building block of what makes this operating >> system work. It is crucial to make sure it works correctly, so in case of an >> issue, having the possibility to go back to an LTS release (or forward to a >> non-LTS release) is in the interest of many users. >> It is mostly not affected by dependency issues arising from version >> mismatches (like soname bumps) - you can plug in any kernel you want without >> any major issues (except maybe hardware support). >> The second point also allows it to be packed in a rolling release >> distribution like Arch without causing trouble for maintainers. Maintaining >> an old user-space tool (i.e. backporting fixes, ensuring library version >> compatibility, ... well, see Debian) is incompatible with Arch Linux. > How hard or problematic to maintain a LTS package, for instance, KDE > Plasma LTS edition package on Arch rolling-release-model? > > https://www.kde.org/announcements/plasma-5.8.0.php >> Tuesday, 4 October 2016. Today KDE releases its first Long Term Support >> edition of its flagship desktop software, Plasma. This marks the point where >> the developers and designers are happy to recommend Plasma for the widest >> possible audience be they enterprise or non-techy home users. > What kind of scenario in the real world to be problematic to maintain > KDE Plasma LTS line as separated packages from non-LTS? Well, first “affected by dependency issues arising from version mismatches (like soname bumps)”. So every time something that any plasma-lts package depends on require an ABI bump, you have to recompile things. You might say, devs have tools to do so quite automatically. Yes, but what if plasma-lts doesn’t build with the new libwhatever? Will plasma-lts have updates that take care of this? Will they be available ahead of libwhatever release? Then, consider the number of package plasma-lts represents. Multiply by their number of dependencies. Especially, kframeworks will continue moving ahead. Will compatibility with newer versions be assured? I’m not quite sure, since I don’t see why you would use lts plasma with latest frameworks. And that’s only one thing I can think of on the top of my head. So, lot of maintenance burden, for quite no gain. Bruno signature.asc Description: OpenPGP digital signature
[arch-general] Does LTS package really not fit to Rolling Release model and Arch Philosophy?
Arch-wiki suggests: https://wiki.archlinux.org/index.php/System_maintenance#Install_the_linux-lts_package >Tips and tricks The following tips are generally not required, but certain users may find them useful. >Install the linux-lts package The linux-lts package is an alternative Arch kernel package, and is available in the core repository. This particular kernel version has long-term support (LTS) from upstream, including security fixes and some feature backports. It is useful if you prefer the stability of less-frequent kernel updates or if you want a fallback kernel in case a new kernel version causes problems. and some guy told me >The LTS kernel is strictly speaking not in line with the "Arch philosophy" (if >you use that term to describe the rolling release nature of Arch) - but it is >also not a "typical" piece of software, for two reasons: >It is the kernel, i.e. the core building block of what makes this operating >system work. It is crucial to make sure it works correctly, so in case of an >issue, having the possibility to go back to an LTS release (or forward to a >non-LTS release) is in the interest of many users. >It is mostly not affected by dependency issues arising from version mismatches >(like soname bumps) - you can plug in any kernel you want without any major >issues (except maybe hardware support). >The second point also allows it to be packed in a rolling release distribution >like Arch without causing trouble for maintainers. Maintaining an old >user-space tool (i.e. backporting fixes, ensuring library version >compatibility, ... well, see Debian) is incompatible with Arch Linux. How hard or problematic to maintain a LTS package, for instance, KDE Plasma LTS edition package on Arch rolling-release-model? https://www.kde.org/announcements/plasma-5.8.0.php >Tuesday, 4 October 2016. Today KDE releases its first Long Term Support >edition of its flagship desktop software, Plasma. This marks the point where >the developers and designers are happy to recommend Plasma for the widest >possible audience be they enterprise or non-techy home users. What kind of scenario in the real world to be problematic to maintain KDE Plasma LTS line as separated packages from non-LTS?
Re: [arch-general] Nvidia backlight control - acpi_video0/brightness changes - display doesn't?
On November 18, 2016 6:42:40 AM GMT+01:00, "David C. Rankin" wrote: >On 11/17/2016 04:31 PM, David C. Rankin wrote: >> All, >> >> Laptop: HP 8760w, Quadro 3000M, nvidia-340xx packages. >> >> The driver works perfectly (no errors in Xorg.0.log), but I have no >way to >> control the screen brightness. I've followed the suggestions in: >> >> https://wiki.archlinux.org/index.php/NVIDIA/Tips_and_tricks >> >> but I still have no backlight control. Using the laptop function >keys, the >> values in /sys/class/backlight/acpi_video0/brightness are properly >set, e.g. >> >> $ cat /sys/class/backlight/acpi_video0/brightness >> 8 >> >> (now tap the [func][F9], brightness lower, twice) >> >> $ cat /sys/class/backlight/acpi_video0/brightness >> 6 >> >> (actual_brightness value tracks brightness) >> >> $ cat /sys/class/backlight/acpi_video0/max_brightness >> 20 >> >> This works with OR without /etc/X11/xorg.conf.d/20-nvidia.conf: >> >> Option "RegistryDwords" "EnableBrightnessControl=1" >> >> Does anyone have any suggestions on anything else to try before I >start >> loading the aur nvidia-bl or nvidiabl packages? I don't mind adding >more >> software, but if there are a few more tweaks to try before going that >route, I >> would like to try them first. Anybody get backlight working with a >similar >> model laptop? >> > >Let me add to this, that powerdevil is seeing the screen brightness >changes >and Udev is evidently applying them correctly. For example, pressing >the >function key to raise/lower brightness seems to generate the correct >log entries: > >Nov 17 23:36:37 seidr org_kde_powerdevil[710]: powerdevil: Screen >brightness >value: 6 >Nov 17 23:36:37 seidr org_kde_powerdevil[710]: powerdevil: Screen >brightness >value max: 20 >Nov 17 23:36:37 seidr dbus[334]: [system] Activating service >name='org.kde.powerdevil.backlighthelper' (using servicehelper) >Nov 17 23:36:37 seidr org_kde_powerdevil[710]: powerdevil: set screen >brightness value: 7 >Nov 17 23:36:37 seidr org_kde_powerdevil[710]: powerdevil: Screen >brightness >value max: 20 >Nov 17 23:36:37 seidr dbus[334]: [system] Successfully activated >service >'org.kde.powerdevil.backlighthelper' >Nov 17 23:36:37 seidr org_kde_powerdevil[710]: powerdevil: Udev device >changed >"/sys/devices/pci:00/:00:01.0/:01:00.0/backlight/acpi_video0" >"/sys/devices/pci:00/:00:01.0/:01:00.0/backlight/acpi_video0" > > And, as noted above, the values in >/sys/class/backlight/acpi_video0/brightness are changing as they >should. > >I'll give both the aur packages a try (I have both built -- but the >nvidiabl >package is currently disowwned and needs a maintainer if anyone is >interested) Do you use any special kernel boot parameters? Using "acpi_backlight=vendor" helped me in a similar situation, though it was about another option interfering with backlight control. Sylvain
