Not quite yet. Will get that note in Release Notes and Errata today sometime.
Edit: There really isn’t a place in Release Notes for issues with an application. I added note about KMail to Errata for Lx 3, Lx 3.01, Lx 3.02, and Lx 3.03.
Not quite yet. Will get that note in Release Notes and Errata today sometime.
Edit: There really isn’t a place in Release Notes for issues with an application. I added note about KMail to Errata for Lx 3, Lx 3.01, Lx 3.02, and Lx 3.03.
fcitx works fine now. .
The I586 ISO # 1464 will install on a x86_64 desktop pc. To bad no one with i586 hardware is testing it. Or am I wrong? (And I hope I am).
Finally I obtained not empty logs, even if I don’t understand how . I simply installed all plymouth* and lib64ply packages but I can’t explain why now it is working
.
There are several ways to obtain a log from plymouth, here I report the two I consider the most convenient igf someone else would get a try.
The first will save a log in a file on the system. Justs adding
plymouth.debug
as a boot code cause all debug informations be saved at /var/log/plymouth-debug.log. In a similar way the path and the name of the file can be provided by hand with:
plymouth.debug=file://path/where/to/save/filename
An interesting alternative is to send the debug informations throw the kerneò messages so they can be read with dmesg or journalctrl -ak
plymouth.debug=stream:/dev/kmsg
This is interesting because you will find the plymouth generated debug and kernel infos together ordered according to time.
All is need is the plymouth-debuginfo package can be found on ABF (and maybe with tracing option enabled at compilation time) .
The link /boot/initrd-desktop.img is broken since initrdtop.img has been moved into a random named subdirectory:
$ ls -lh /boot/initrd*
lrwxrwxrwx 1 root root 30 ott 19 23:16 /boot/initrd-desktop.img -> initrd-4.13.8-desktop-1omv.img
Also vmlinuz in installed twice with different name in different places:
$ ls -lh /boot/vmlinuz-4.13.8-desktop-1omv /boot/2bb1afab10e04e6da333141c2bff01f1/4.13.8-desktop-1omv/linux
-rw-r--r-- 1 root root 5,5M ott 19 23:16 /boot/2bb1afab10e04e6da333141c2bff01f1/4.13.8-desktop-1omv/linux
-rw-r--r-- 1 root root 5,5M ott 19 06:55 /boot/vmlinuz-4.13.8-desktop-1omv
$ sha1sum /boot/vmlinuz-4.13.8-desktop-1omv /boot/2bb1afab10e04e6da333141c2bff01f1/4.13.8-desktop-1omv/linux
e789f42aab2c5de31c3aa6f4a6866f7e2f5620e2 /boot/vmlinuz-4.13.8-desktop-1omv
e789f42aab2c5de31c3aa6f4a6866f7e2f5620e2 /boot/2bb1afab10e04e6da333141c2bff01f1/4.13.8-desktop-1omv/linux
Is that right?
Things are under control and environment is stable. What are the blockers to release 3.03 this year ?
@Colin Can we have this release out in the wild ?
Tomek,
No blockers here unless you count the systemd-235 issue. If we want to ship with 235 then we have to put it in the main repos which may break peoples boxes. I suggest we ship with 234. WDYT?
I am waiting for final reports.
I’m in agreement with Colin, no blockers other than systemd-235. I’m inclined to think we don’t want to put that in main-updates as users will have problems that a lot of them won’t be able to fix. It is fixable but not easy to do for “regular” OpenMandriva users. Just my opinion.
One thing we need to do before release is move the kernel-4.13.9 packages to main-update so people can install kernel-release-desktop-devel for kernel modules. Unless that’s already been done.
I had one install where Calamares would not format a /home partition complaining of it already being mounted but I have done 3 install since and /home formatted without incident on all 3 so I can’t reproduce that issue, it even is an issue. I followed exact same procedure and sequence on all installs as I was trying to reproduce the problem. But since I can’t reproduce it isn’t a problem. Just my weird luck that happened on first install attempt.
I’m fine with that. Let’s first release others from testing repos.
Me too. Or is that a +1.
@TPG looks like you made a new x86_64 ISO # 1520. Any special reason, any thing to look for or check.
Full disclosure: I have yet to test the i586 ISO # 1511. I usually do and have tested # 1481 and # 1490 and they booted and installed here. I will test the one we release when I get time but I’m jammed up for time right now. Hoping someone else can test it before release. What would be just swell is if someone with i586 hardware would test but that never seems to happen…
In the case someone has some time to spent around plymouth issue I filed a bug report hare here with some logs. It is not a blocking bug but it will be great to have ISOs with working plymouth.
Also I noticed buttons in oma-welcome disappeared so maybe something, maybe_htmlscript_, should be rebuilt. Also qupzilla shows some minor (i.e. related to style) in some pages (for instance search area in left side panel of ABF web interface).
Worse than style I can’t log in to ABF in Qupzilla because I can’t type anything in the dialog boxes. It’s broke.
Yep that too.
Ben this is for my own testing. Final Isos will be build on Sunday.
I can’t make sense of Z’s French post. With ISO 1529 Calamares segfaults (core dump) on hardware and in VBox.
I messed up getting journalctl logs will get them and post here in a bit.
ISO 1529 does not start installation from ISO menu nor from live system.
Screenshots show segfault in live mode, while from ISO menu calamares does not display at all.
Test in virtualbox.
This is logs for Calamares core dump from ISO 1529 on hardware.
Calamares-Konsole.txt (756 Bytes)
journalctl-e.txt (125.4 KB)
Look at lines 970-978. Unfortunately this doesn’t look like it tells much.
Hello,
As proposed (for any issue), I post here problems for downloading ISO, in lines command, or via Firefox.
For LXQt-64, i don’t remember the number :slight_smile
Firefox : ~ 30 %
terminal : 6 MB
Now, my provider is Orange, better (max 2.1/0.7) than SFR.
Why the download is stopped for ABF?
Thanks,
PS : is 1512 stable?