Tiny Core Linux
Tiny Core Base => TCB News => Release Candidate Testing => Topic started by: Juanito on January 14, 2020, 07:15:48 AM
-
Team Tiny Core is pleased to announce that Tiny Core 11.0 Beta1 is available for public testing:
http://repo.tinycorelinux.net/11.x/x86/release_candidates/
http://repo.tinycorelinux.net/11.x/x86_64/release_candidates/
This is an beta level cut. If you decide to help test, then please test carefully. We don't want anyone to lose data.
Extensions are in the process of being copied over from the 10.x repo.
We appreciate testing and feedback.
If you use distribution files note that you need a new vmlinuz and core.gz (or rootfs.gz + modules.gz)
Changelog for 11.0 beta1:
* kernel updated to 5.4.3
* glibc updated to 2.30
* gcc updated to 9.2.0
* e2fsprogs base libs/apps updated to 1.45.4
* util-linux base libs/apps updated to 2.34
* busybox updated to 1.31.1
* .ashrc removed #alias d='dmenu_run &'
Note:
* we discovered a bug on the 32-bit version, in Intel IOMMU, preventing boot. If you have a high-end Intel system with IOMMU and VT-D, you may need intel_iommu=off to boot the 32-bit version
* the nouveau kernel module is now enabled, but it is in a separate extension and not in graphics-KERNEL. The nvidia binary driver is still recommended.
* Intel compute sticks, etc should now detect their embedded mmc flash
* for 64 bit version only: task_xacct and ipmi are enabled
* we will move extensions from linking to openssl-1.0.2 -> 1.1.1 as 1.0.2 is at end of life
* Xorg-7.7 will move from using the depreciated xf86-input-evdev to xf86-input-libinput, it is still possible to use xf86-input-evdev if required
-
Thanks, juanito. Everything that I've tested in the 64-bit version is working:
- flwm.tcz with Xfbdev.tcz
- fluxbox.tcz (from 10.1) with Xfbdev.tcz
- connecting to WiFi using wpa_supplicant-dbus.tcz and its dependencies
I will test flwm and fluxbox with Xorg-7.7 once xf86-video-intel.tcz is available (Xorg-7.7.tcz doesn't work for me without xf86-video-intel.tcz).
I saw an old post or wiki entry somewhere saying there's a place for users to report extensions from prior TCL versions that work as-is in new TCL version (e.g., fluxbox from Pure64 10.1 works in Pure64 11). Is it still helpful to provide this kind of information? If so, where to report?
-
Please report extensions from tc-10.x that work with tc-11.x here:
http://forum.tinycorelinux.net/index.php/topic,23440.0.html
fluxbox and xf86-video-intel copied over.
-
The fluxbox.tcz that was in the Pure64 11-beta repo before (version 1.3.5, last updated 2013/11/10) was working fine with Xorg-7.7.
The fluxbox.tcz that showed up in Pure64 11-beta repo today (version 1.3.5, last updated 2014/11/30) is badly broken for me: Neither the panel nor the pointer appear.
-
Another small thing:
The sshpass.tcz extension in the Pure64 11.x repo has an actual md5sum of ...ffaa8 but sshpass.tcz.md5.txt says it should be ...6c795
This causes an error when installing the extension.
-
fluxbox and sshpass should be OK now
-
Yes, looks good :)
-
iptables.tcz lists netfilter-KERNEL.tcz as a dependency but there is no such extension. Maybe what was meant was ipv6-netfilter-KERNEL.tcz
-
Hi GNUser
There was talk about combining ipv6-KERNEL.tcz and netfilter-KERNEL.tcz due to a dependency issue. Based on the description
in the .info file it looks like that happened.
-
Hi Juanito
It looks like ipset.tcz.dep is the only other .dep file with this issue in the 32 and 64 bit repositories.
-
I see ipset.tcz.dep, iptables.tcz.dep, l2tp-5.4.3-tinycore.tcz.dep, net-bridging-5.4.3-tinycore.tcz.dep, net-sched-5.4.3-tinycore.tcz.dep and sctp-5.4.3-tinycore.tcz.dep contain netfilter-KERNEL.tcz
Also, frr-dev.tcz.dep, quagga-dev.tcz.dep and strongswan-dev.tcz.dep contain ipv6-KERNEL.tcz.
Maybe @curaga could confirm the intent?
-
Hi Juanito
I see ipset.tcz.dep, iptables.tcz.dep, l2tp-5.4.3-tinycore.tcz.dep, net-bridging-5.4.3-tinycore.tcz.dep, net-sched-5.4.3-tinycore.tcz.dep and sctp-5.4.3-tinycore.tcz.dep contain netfilter-KERNEL.tcz
But only ipv6-KERNEL.tcz and netfilter-KERNEL.tcz had incorrect .dep files in my search. The others appear to have been corrected.
But only ipset.tcz and iptables.tcz had incorrect .dep files in my search. The others appear to have been corrected.
Also, frr-dev.tcz.dep, quagga-dev.tcz.dep and strongswan-dev.tcz.dep contain ipv6-KERNEL.tcz.
Missed those in my search. I typed ipv5 instead of ipv6. :-[
[EDIT]: Correction "ipset.tcz and iptables.tcz". Rich
-
The dep files I have in my 5.4.3 build folder all have the combined extension.
-
dep files adjusted
-
Seems the TinyCore* isos are missing libfontenc, X doesn't start.
-
'seems the tree files for Xvesa and Xfbdev are incorrect - probably because libXfont wasn't around when they were created.
It'd be nice if they could use libXfont2 :P
-
TinyCore and TinyCorePure64 iso's reposted
-
tested x86_64, and found that wpa_supplicant-dbus is updated to 2.9
http://repo.tinycorelinux.net/11.x/x86_64/tcz/wpa_supplicant-dbus.tcz.info
but looks 802.11r FT feature is not enabled:
1579687810.193462: Line 10: invalid key_mgmt 'FT-EAP'
1579687810.193470: Line 10: no key_mgmt values configured.
1579687810.193475: Line 10: failed to parse key_mgmt 'FT-EAP'.
1579687810.193496: Line 17: failed to parse network block.
802.11r/FT and bgscan was enabled at 9.x/x86_64 update, but the doc http://repo.tinycorelinux.net/9.x/x86_64/tcz/src/wpa_supplicant-dbus/compile_wpa_supplicant-dbus was not updated at the timing of tcz update. I attached build-dep file - could you rebuild with updated build options in build-dep ?
Also please make sure to apply security patch for 2.9 (https://w1.fi/security/2019-7/0001-AP-Silently-ignore-management-frame-from-unexpected-.patch) as well.
Thanks!
-
Specifically which additional options in the config are you looking for?
-
following 2 options in .config at build:
CONFIG_BGSCAN_SIMPLE=y
CONFIG_IEEE80211R=y
-
posted
-
posted
thanks! confirmed it works with 802.11r/FT enabled network, also bgscan check the better AP periodically and roam.
Can we get update firmware-iwlwifi package ? files for new Intel wifi cards (AX200/AX201) are missing.
ref: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi
-
firmware-iwlax20x posted
You might also need ibt-20* from firmware-intel for bluetooth
-
firmware-iwlax20x posted
You might also need ibt-20* from firmware-intel for bluetooth
thanks a lot, confirmed AX200 can find firmware and recognized as wlan0 properly.
-
ezra master ! :( "ezre master" :(
-
ezra master ! :( "ezre master" :(
x86-32-bit
does not appear in the list of applications, does not exist
-
Latest Stable Kernel: 5.5 ( https://www.kernel.org/ )
-
There are no plans to change the kernel version at the moment
-
It would be much appreciated if somebody could convert ezremaster from fltk-1.1.10 to fltk-1.3.5
-
I'll work on it today.
-
I'll work on it today.
Latest Stable Kernel: 5.5 ( https://www.kernel.org/ )
OK :)
-
ezremaster extension for TCL 10.x/fltk-1.3.5 submitted (both 32-bit and 64-bit).
I don't use ezremaster, so testing was limited. Nevertheless, I can confirm that the extension loads, .desktop file works, and application starts without issue in 10.x 32-bit, 10.x 64-bit, and 11.0beta1 64-bit.
If extension turns out to be broken, let me know and I'll try to fix it.
-
Thanks for the help - ezremaster posted to tc-11.x x86 and x86_64 repos.
Are there any volunteers to take on the conversion of fluff to fltk-1.3.5?
-
I'd like to help with fluff. I found source code for 1.0.7 here, which I assume is the latest version:
http://forum.tinycorelinux.net/index.php/topic,12928.45.html
I can compile it in 11.0beta1 64-bit after fixing a small typo in fluff.cpp . However, linking step fails:
$ tce-load -i compiletc fltk-1.3-dev Xorg-7.7-dev
$ sed -i 's|Fl/Fl_Hold_Browser|FL/Fl_Hold_Browser|' fluff.cpp
$ g++ -mtune=generic -Os -pipe -Wno-narrowing `fltk-config --cxxflags` -Wall -c fluff.cpp
...
$ g++ `fltk-config --use-images --ldflags` -lfltk_images -lm fluff.o -o fluff
/usr/local/bin/ld: fluff.o:(.rodata._ZTI17Fl_Select_Browser[_ZTI17Fl_Select_Browser]+0x10): undefined reference to `typeinfo for Fl_Browser'
/usr/local/bin/ld: fluff.o:(.rodata._ZTI16Fl_Multi_Browser[_ZTI16Fl_Multi_Browser]+0x10): undefined reference to `typeinfo for Fl_Browser'
/usr/local/bin/ld: fluff.o:(.rodata._ZTI10Fl_DND_Box[_ZTI10Fl_DND_Box]+0x10): undefined reference to `typeinfo for Fl_Box'
/usr/local/bin/ld: fluff.o:(.rodata._ZTI17File_Props_Window[_ZTI17File_Props_Window]+0x10): undefined reference to `typeinfo for Fl_Window'
/usr/local/bin/ld: fluff.o:(.rodata._ZTI16Open_With_Window[_ZTI16Open_With_Window]+0x10): undefined reference to `typeinfo for Fl_Window'
/usr/local/bin/ld: fluff.o:(.rodata._ZTI26Manage_Associations_Window[_ZTI26Manage_Associations_Window]+0x10): undefined reference to `typeinfo for Fl_Window'
/usr/local/bin/ld: fluff.o:(.rodata._ZTI23Manage_Filetypes_Window[_ZTI23Manage_Filetypes_Window]+0x10): undefined reference to `typeinfo for Fl_Window'
/usr/local/bin/ld: fluff.o:(.rodata._ZTI12Fluff_Window[_ZTI12Fluff_Window]+0x10): undefined reference to `typeinfo for Fl_Double_Window'
collect2: error: ld returned 1 exit status
Any ideas why linking is failing? Only fltk-1.3 extensions are loaded:
bruno@box:~$ tce-status -i | grep fltk
fltk-1.3
fltk-1.3-dev
-
Hi GNUser
The dev files used to be at /usr/include /usr/lib but are now in /usr/local/include /usr/local/lib. See if the makefile has a bad path.
-
Thanks, Rich. I'll investigate that. However, note that in the commands above I didn't use the makefile.
-
Rich, I added a bunch of symlinks, but no joy.
I found this build script: http://tinycorelinux.net/5.x/x86_64/tcz/src/fluff/fluff_build.sh
Compiling and linking in one step as shown in the script works, but the binary segfaults:
bruno@box:~/Downloads/fluff_1_0_7_src$ tce-load -i fltk-1.3-dev compiletc Xorg-7.7-dev
bruno@box:~/Downloads/fluff_1_0_7_src$ g++ -mtune=generic -Os -fno-exceptions -fno-rtti -fpic -Wno-narrowing -L/usr/lib -lfltk -lfltk_images -lfltk_forms -lpng -o fluff fluff.cpp
fluff.cpp: In member function ‘void Manage_Associations_Window::update()’:
fluff.cpp:2361:40: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
2361 | cmd_list_p->data(n, (void*)i);
| ^
fluff.cpp: In member function ‘void Manage_Filetypes_Window::update()’:
fluff.cpp:2532:45: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
2532 | hint_list_p->data(n, (void*)fh);
| ^~
bruno@box:~/Downloads/fluff_1_0_7_src$ ./fluff
Segmentation fault
Perhaps there is some code in fluff.cpp that relies on functions that are no longer available in the new fltk library? Alas, I have no experience with fltk.
-
Hi GNUser
... Compiling and linking in one step as shown in the script works, but the binary segfaults:
bruno@box:~/Downloads/fluff_1_0_7_src$ g++ -mtune=generic -Os -fno-exceptions -fno-rtti -fpic -Wno-narrowing -L/usr/lib -lfltk -lfltk_images -lfltk_forms -lpng -o fluff fluff.cpp
I just tried that under TC10 x86. It compiled with no errors and runs.
-
I just tried it in TC10 x86. It compiles without errors but segfaults when I try to run it. Mysterious.
Since you cannot reproduce my issue, I may have to throw in the towel here. I would have liked to help :'(
-
Hi GNUser
I just tried it in TC10 x86. It compiles without errors but segfaults when I try to run it.
Try it like this:
g++ -march=i486 -mtune=i686 -Os -fno-exceptions -fno-rtti -fpic -Wno-narrowing -L/usr/lib -lfltk -lfltk_images -lfltk_forms -lpng -o fluff fluff.cpp
Maybe the -mtune=generic is causing some goofy behavior from your 64 bit processor.
-
I booted into TC10 x86 and tried
g++ -march=i486 -mtune=i686 -Os -fno-exceptions -fno-rtti -fpic -Wno-narrowing -L/usr/lib -lfltk -lfltk_images -lfltk_forms -lpng -o fluff fluff.cppSame result: No compilation errors, but segfault when I try to run the binary. It sure seems like a hardware issue.
I already have everything for the 32bit and 64bit extensions except for the fluff binary itself. If you email me the x86 and x86_64 binaries, I can package them up with supporting files into extensions, test everything, then pass it on to juanito. My email: gnuser at dantas dot airpost dot net
-
Hi GNUser
I only did x86 (32 bit). Email sent with attached binary.
I also attached the result of:
ls -1 /usr/local/tce.installed/ > installed.txtIf the binary I attached segfaults, run a diff against your installed extensions. Maybe you you are missing something, or have fltk-1.1
installed in addition to fltk1.3.
-
Rich,
I received the binary, thanks. It segfaults when I try to run it on TC10 32bit.
Nevertheless, I packaged it up into a 32bit extension and forwarded it to juanito. If it works for him as well as you, it suggests a problem with my machine or TCL configuration.
Juanito,
Sorry I couldn't provide a 64bit extension (and only a 32bit one that segfaults for me) :-\ Hopefully having source code, tentative build directions, and extension "rough draft" is some help.
P.S. I'm out of time today for troubleshooting today. Even though I don't use fluff, eventually I will try to figure out why compiling and running this binary are problematic for me. If I find answers, I will share them in a new thread so that I don't hijack this beta announcement.
-
64bit fluff extension submitted.
It turns out that fluxbox and fluff butt heads for some reason. Until smarter folks than I figure out why, fluxbox users should use a different file manager.
Ref: http://forum.tinycorelinux.net/index.php/topic,23484.msg147155.html#new
-
We'll need the xf86-video-vmware extension at some point, soon if possible.
-
On 64 bit it's icu61.tcz, and on 32 bit it's icu62.tcz. Current version of ICU is 65. Could we get them sync'ed up to the latest version, and have the same name?
-
Yes, at some point it will get done (after ncurses, openssl, etc) :)
-
We'll need the xf86-video-vmware extension at some point, soon if possible.
'not sure why they were missing - done now
-
More beta issues:
Wget needs to be recompiled against openssl-1.1.1. It currently wants 1.0, which doesn't exist and this breaks submitqc and certainly other things.
Gvim needs gnome-icon-theme.tcz. The toolbar is all placeholders without it.
This is back http://forum.tinycorelinux.net/index.php/topic,22312.msg139801.html#msg139801 (http://forum.tinycorelinux.net/index.php/topic,22312.msg139801.html#msg139801). This breaks open-vm-tools-desktop.
-
wget reposted - one more extension where the breakage is masked by recursive deps..
adwaita-icon-theme substituted for the depreciated gnome-icon-theme
I don't see that .xsession was changed - was it the removal of "-print" in the last two lines you were looking for?
-
I don't see that .xsession was changed - was it the removal of "-print" in the last two lines you were looking for?
Yes.
I also just noticed that glibmm in the 32-bit repo is the 64-bit version, or so ld and ldd seem to think.
-
I just downloaded glibmm from the tc-11.x x86 repo - it's 32-bit..
-
I deleted mine and redownloaded and it seems find now. :o
-
I noticed that the 32-bit repo has several (29) extensions that end in -tinycore64.tcz
Is that intended?
-
Hi GNUser
... Is that intended?
Yes, those are kernel modules. They are needed if you are running Core64 (not CorePure64) which is a 64 bit kernel with 32 bit
extensions.
-
Got it, thank you. I've often wondered about the significance of "Pure" in Pure64. Glad I asked :)
-
.xsession adjusted and Xlibs reposted
-
Hi, @andyj. I see you are the maintainer of one of my favorite extensions, rxvt.tcz
It seems that rxvt.tcz needs to be rebuilt for tc-11 because it's only able to show Unicode characters if I copy over my old mylocale.tcz extension from Pure64 10.1. Unfortunately, the old mylocale.tcz breaks some things (e.g. http://forum.tinycorelinux.net/index.php/topic,23484.msg147289.html#msg147289).
If I use the new mylocale.tcz that I generated in Pure64 v11.0beta1, no Unicode characters show up in rxvt.
-
Already done. Which font are you using? Are you setting lang in the kernel command line? Remember, rxvt supports true type fonts if you have one that you know has the glyphs you need.
-
andyj, I set the terminal font with this in my ~/.Xdefaults:
URxvt*font: xft:Luxi Mono:pixelsize=14This font was working fine with rxvt in Pure64 10.1
I set the lang with this boot code: lang=en_US.UTF-8 (the locale in mylocale.tcz).
Is this worrisome:
$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=?
Maybe rxvt.tcz is innocent and the problem is that getlocale.tcz is not generating the locale files properly?
-
Your mylocale extension is broken. Did you download the latest getlocale, and remember to select en_US.UTF-8 before you hit OK? Did you load it in onboot.lst?
-
I had done all of that twice without success. But on your say so I decided to try again. This time I made sure to start from scratch: Removed mylocale.tcz from onboot.lst, deleted all mylocale* and getlocale* files from tce/optional, rebooted. Then I created a new mylocale.tcz by running $ tce-load -wi getlocale. Lo and behold, after another reboot everything works.
Thank you! :)
-
What I see is the following:
If you load the extension, the getlocale script runs automatically and makes a 4k extension that doesn't work.
If you run the getlocale script at some point after loading it makes a 652k extension that does work.
Whilst the tc-10.x mylocale extension is of a similar size, the tc-9.x extension is 324k.
-
In TC11.0beta1 (x86)
There is missig dependency in mc.tcz, it require libgcrypt.tcz
In TC11.0beta1 (x86_64) mc.tcz works OK.
In TC11.0beta1 (x86_64) I can't install midori.tcz
tc@box:~$ tce-load -iw midori
midori.tcz.dep OK
gcr.tcz.dep OK
gnupg.tcz.dep OK
libassuan.tcz.dep OK
libksba.tcz.dep OK
libusb.tcz.dep OK
Downloading: webkitgtk.tcz
Connecting to repo.tinycorelinux.net (89.22.99.37:80)
wget: server returned error: HTTP/1.1 404 Not Found
md5sum: webkitgtk.tcz.md5.txt: No such file or directory
Error on webkitgtk.tcz
In TC11.0beta1 (x86_64) qemu.tcz require libssl.so.1.0.0
-
I did more experiments. If I try generating a new mylocale.tcz without any mylocale.tcz currently loaded, the process succeeds (a 667k mylocale.tcz extension is created):
$ tce-status -i | grep locale
[note no hits]
$ tce-load -wi getlocale
getlocale.tcz.dep OK
Downloading: getlocale.tcz
Connecting to gnuser.ddns.net (192.168.10.1:80)
saving to 'getlocale.tcz'
getlocale.tcz 100% |********************************| 4096 0:00:00 ETA
'getlocale.tcz' saved
getlocale.tcz: OK
[The below shows up in a different terminal after I've selected the locale I want]
Now processing... /
Locales installed. Creating extension... \
Done. The extension is at /mnt/sda3/tce/optional/mylocale.tcz and in onboot.lst
Reboot with lang=xyz (for example lang=en_US.UTF-8) to start using this.
Press enter to quit.
If I try generating a new mylocale.tcz with mylocale.tcz already loaded, the process fails (a 4k mylocale.tcz extension is created):
$ tce-status -i | grep locale
mylocale
$ tce-load -wi getlocale
getlocale.tcz.dep OK
Downloading: getlocale.tcz
Connecting to gnuser.ddns.net (192.168.10.1:80)
saving to 'getlocale.tcz'
getlocale.tcz 100% |********************************| 4096 0:00:00 ETA
'getlocale.tcz' saved
getlocale.tcz: OK
[The below shows up in a different terminal after I've selected the locale I want]
Now processing... cannot open locale archive "/usr/lib/locale/locale-archive": Read-only file system
Locales installed. Creating extension... \
Done. The extension is at /mnt/sda3/tce/optional/mylocale.tcz and in onboot.lst
Reboot with lang=xyz (for example lang=en_US.UTF-8) to start using this.
Press enter to quit.It seems the script should error-out if it "cannot open locale archive"--as it is, the script seems to succeed in the end (causing user to interpret "cannot open locale archive" as a benign warning).
-
mc updated in the x86 repo.
midori and spice updated in the x86_64 repo - qemu seems to work now.
-
Now, TC11.0beta1 (x86)
There is missing dependency in mc.tcz, libgpm.so.2
There is also problem with appbrowser, when I click "Size" all extensions have zero MB.
-
dep file corrected