Dear BDFL, and we upgraded ICU in -current because of what shocking new advantages?
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.
Dear BDFL, and we upgraded ICU in -current because of what shocking new advantages?
Just asking: what advantages gives us icu4c-61.1, compared with icu4c-60.0, excluding that everything is a mess? From your PHP to Eric's Plasma 5, everything is nuts.
Be kind to says us WHY you considered is proper to update this package?
I tell you with all respect: you have NO advantages on upgrading to icu4c-61.1. Nothing, nada, zero. Show me at least one CVE and I will be happy, but there is nothing to gain.
At least please be kind to communicate (not with me! but) with your close collaborators and warn them about your intentions, then everyone to do the updates in sync.
Last edited by Darth Vader; 04-01-2018 at 04:37 AM.
Just asking: what advantages gives us icu4c-61.1, compared with icu4c-60.0, excluding that everything is a mess? From your PHP to Eric's Plasma 5 everything is nuts.
Be kind to says us WHY you considered is proper to update this package?
I tell you with all respect: you have NO advantages on upgrading to icu4c-61.1. Nothing, nada, zero.
Darth, a personal curiosity: have you started using current now?
are you aware that on the development branch things might break (not that they do this time, php works fine here)?
Darth, a personal curiosity: have you started using current now?
are you aware that on the development branch things might break (not that they do this time, php works fine here)?
Sure thing I am aware that things can be broken in -current. BUT, I am not aware about the advantages of ICU 61.1, which are glorious NULL, compared with previous shipped version.
Oh, I got it. Maybe our BDFL loves to torpedo the Eric's efforts on Plasma5. NOT that I disagree, as I hate with passion this particular DE.
BUT, the the innocent Qupzilla or Palemon which fault had?
PS. Like I shown in another thread:
Code:
bash-4.4# ./server.php
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/lib64/php/extensions/intl (/usr/lib64/php/extensions/intl: cannot open shared object file: No such file or directory), /usr/lib64/php/extensions/intl.so (libicui18n.so.60: cannot open shared object file: No such file or directory)) in Unknown on line 0
Usage: php yourfile.php {start|stop|restart|reload|status|connections} [-d]
That's the glorious standard PHP CLI, aka /usr/bin/php, in a standard -current machine, with the INTL extension loaded.
Last edited by Darth Vader; 04-01-2018 at 05:10 AM.
Just asking: what advantages gives us icu4c-61.1, compared with icu4c-60.0, excluding that everything is a mess? From your PHP to Eric's Plasma 5, everything is nuts.
Be kind to says us WHY you considered is proper to update this package?
I tell you with all respect: you have NO advantages on upgrading to icu4c-61.1. Nothing, nada, zero. Show me at least one CVE and I will be happy, but there is nothing to gain.
At least please be kind to communicate (not with me! but) with your close collaborators and warn them about your intentions, then everyone to do the updates in sync.
According to the release notes "ICU 61 upgrades to CLDR 33 locale data, has a new Java implementation for number and currency parsing, and includes many small API additions, improvements, and bug fixes.".
For many people that is a valid change, warranting an upgrade. And since this is the Slackware development tree, you have to be prepared to swallow an incompatible, library-breaking update from time to time.
If you have an issue with that, stick to any of the recent stable Slackware releases please.
BUT: do not spread FUD here. Pat is not torpedo-ing my packaging efforts. This was not the first time and it will not be the first time that people running Slackware-current have some homework to do
Be glad it is the Easter weekend so you have one additional day to recompile all that's broken.
/usr/bin/php, in a standard -current machine, with the INTL extension loaded.
You skipped upgrading php?
There used to be CURRENT.WARNING in the current ftp directory. Here's a 2010 copy of it:
Code:
[Standard disclaimer follows... ]
Welcome to Slackware-current!
*** Please note that you must already be ***
*** running a 2.6.x kernel before ***
*** upgrading to Slackware-current! ***
*** ***
*** upgradepkg glibc-solibs before other ***
*** packages. Take care not to miss new ***
*** packages that were split from old ***
*** ones: upgradepkg --install-new is ***
*** (as always) the safest approach. ***
Slackware-current is a snapshot of the active Slackware development tree.
It is intended to give developers (and other Linux gurus) a chance to test
out the latest packages for Slackware. The feedback we get will allow us
to make the next stable release better than ever.
See the ChangeLog.txt for a list of changes in Slackware-current.
Please note that the code in this directory is unstable. It might be
inconsistent about which version of the Linux kernel is required, could be
incomplete because it's in the process of being uploaded, or might not work
for other reasons. In most cases, we know about these things and are working
to correct them, but still -- feel free to point out the bugs.
Production use is AT YOUR OWN RISK and is not recommended.
Security is NOT GUARANTEED. In -current, forward progress often takes
priority. Security fixes take time and resources, and would often have to
be done more than once. It's more efficient to build the system and secure
it as time permits and/or the development cycle nears completion.
We do not promise to issue security advisories for Slackware-current.
Slackware-current might DELETE FILES WITHOUT WARNING when packages are
upgraded. (If, for example, a directory location is replaced by a symbolic
link to a new location.) Upgrade packages carefully. Examine incoming
updates first if your machine's data is not expendable. Again, we do not
recommend using Slackware-current to store or process valuable data.
It is a system in testing, not one that is ready to go (though often it does
work just fine... BUT DON'T COUNT ON IT)
#include BSD license warranty disclaimer here...
Enjoy! :)
---
Patrick J. Volkerding
volkerdi@slackware.com
I agree. P. Volkerding's detonation of a Tsar Bomba right over the headquarters of your KDE5 clearly does not qualify as torpedo-ing, but as genocide.
I wish you to thank you guys from all my heart, about this fine Easter surprise. My kids love to stare to a black Linux console instead to watch cartoons.
Of course, is all my fault that I trusted you, no laments here.
I agree. P. Volkerding's detonation of a Tsar Bomba right over the headquarters of your KDE5 clearly does not qualify as torpedo-ing, but as genocide.
I wish you to thank you guys from all my heart, about this fine Easter surprise. My kids love to stare to a black Linux console instead to watch cartoons.
Of course, is all my fault that I trusted you, no laments here.
It's your fault that you are running -current not knowing the caveats.
I agree. P. Volkerding's detonation of a Tsar Bomba right over the headquarters of your KDE5 clearly does not qualify as torpedo-ing, but as genocide.
I wish you to thank you guys from all my heart, about this fine Easter surprise. My kids love to stare to a black Linux console instead to watch cartoons.
Of course, is all my fault that I trusted you, no laments here.
You are disqualified. You should have read the disclaimer.
In the meantime, use XFCE, that still works. Or go back to what we advise to everyone: use a stable release if you are not able or willing to fix the occasional breakage in -current.
Well, the break of Qt5 and Plasma5 by this ICU update is not supposed to leave you literally with a black Linux console.
BUT, I will assume that you boot in runlevel 4 and, in your particular system, the SDDM manage somehow to drag the X11 server with it, when dies of ICU failure. It is your enemy.
All you have is to do is to avoid the launching the SDDM, going right on runlevel 3, with adding literally the 3 on kernel command line. For example
Code:
Linux 3
This will boot you directly to console login prompt, without touching Plasma things.
From here you can temporary edit your /etc/inittab for runlevel 3, then to use xwmconfig to chose XFCE, like Eric said, and finally running the good old startx you can start your graphical desktop.
Then, the mission "kids must watch cartoons" could be accomplished in several minutes.
Last edited by Darth Vader; 04-01-2018 at 08:49 AM.
Well, the break of Qt5 and Plasma5 by this ICU update is not supposed to leave you literally with a black Linux console.
BUT, I will assume that you boot in runlevel 4 and, in your particular system, the SDDM manage somehow to drag the X11 server with it, when dies of ICU failure. It is your enemy.
All you have is to do is to avoid the launching the SDDM, going right on runlevel 3, with adding literally the 3 on kernel command line. For example
Code:
Linux 3
This will boot you directly to console login prompt, without touching Plasma things.
From here you can temporary edit your /etc/inittab for runlevel 3, then to use xwmconfig to chose XFCE, like Eric said, and finally running the good old startx you can start your graphical desktop.
Then, the mission "kids must watch cartoons" could be accomplished in several minutes.
Thank you, your procedure made the trick.
Also, I confirm that what happened was some kind of system crash when X started to KDE5, it is amazing how you figured out where the lock was.
Well, that shouldn't be hard. Not all mirrors are synced simultaneous and the package was removed pretty recently.
BTW, I for one I discovered that Qt5 wants to compile, if you removed previously its old package. Now I building it in the offended computer.
I know, I know, that Qt5 building in really a long run process, maybe better Eric can launch his Ryzen too, because I really believe that this is The Single Breaking Point of this Easter ICU Affair.
Last edited by Darth Vader; 04-01-2018 at 09:30 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
