Tiny Core Linux
Tiny Core Base => TCB News => Alpha Releases => Topic started by: Juanito on January 01, 2024, 07:59:22 AM
-
Team Tiny Core is pleased to announce that Tiny Core 15.0 Alpha1 is available for public testing:
http://repo.tinycorelinux.net/15.x/x86/release_candidates/distribution_files
http://repo.tinycorelinux.net/15.x/x86_64/release_candidates/distribution_files
This is an alpha level cut. If you decide to help test, then please test carefully. We don't want anyone to lose data.
Since this is an alpha cut, we ask that only experienced users test. This cut is not for general use. The features in any alpha are not fixed and may change before a public release candidate is available.
We appreciate testing and feedback.
Changelog for 15.0 alpha1:
* kernel updated to 6.6.8
* glibc updated to 2.38
* gcc updated to 13.2.0
* binutils updated to 2.41
* e2fsprogs base libs/apps updated to 1.47.0
* util-linux base libs/apps updated to 2.39.2
* zlib base lib updated to 1.3
* busybox updated to 1.36.1
* tce-functions/setdrive/setup: use : in chown
* tce-audit: add md5check action from bdantas
* tce-audit: md5check update from bdantas
* tce-load: sudo touch from polikuo
* update-everything: handle missing or extraneous dep files from bdantas
* tce-update: allow tcedir/optional to be a symlink from bdantas
* update-everything: add safety checks from bdantas
-
I can't startx.
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Cannot open "/tmp/server-0.xkm" to write keyboard description
> Exiting
@
nvm, it was a permission problem on /tmp caused by my custom modules.gz
-
In the past the kernel was patched, per the tarball name. This one doesn't appear to have patches. Not only that, the tarball isn't the same version, 6.6.5 vs 6.6.8. Also, I didn't find kernel config files for download.
-
The kernel tarball under src/toolchain/ is only used for the headers (before compiling glibc). The kernel source, config and patches will be under src/kernel. Should be there soon.
edit: posted, please mention if anything's missing.
-
I noticed that atk.tcz and at-spi2-atk.tcz are present in TCL14 x86_64 repo but absent from TCL15 x86_64 repo. I also noticed that gtk2 and the recently-updated gtk3 no longer depend on *atk.tcz. So I guess nothing depends on *atk.tcz anymore?
I'm writing this post using brave-browser running in TCL15 x86_64 with wayland (labwc) and a wifi connection. Everything is working just fine as far as I can tell :)
P.S. I tested a few gtk2 and gtk3 applications in TCL15 x86_64 and all seems well.
-
atk and at-spi2-atk have been merged into at-spi2-core.
-
atk and at-spi2-atk have been merged into at-spi2-core.
Hi Juanito. Well, that explains it. Thanks for shedding some light.
-
Just in case it wasn’t clear, merged by gnome, not by me :)
-
I'm seeing a lot of this: "plugin needed to handle lto object". Recompiling extensions with the new gcc version is going poorly.
-
I just compiled gtk3 and deps on both x86 and x86_64 without problems - does ldd show all the deps are met for the lto plugin?
-
When I do this:
find /usr/local -regex '.*lto.*' -exec file {} \; | grep ELF | cut -d: -f1 | xargs ldd | grep foundnothing is returned, so I'm assuming all dependencies are met. If I need look at something else let me know.
-
The symlink /usr/local/lib/bfd-plugins/liblto_plugin.so was broken in the 64-bit gcc, reposted.
The symlink in the 32-bit gcc is OK - did you see errors in both 32/64-bit?
btw: there's no particular need for you to recompile your extensions for 15.x
strange how I didn't see any errors in 64-bit compiling with -flto...
-
32-bit gcc is ok, but this is back: http://forum.tinycorelinux.net/index.php/topic,25871.0.html (http://forum.tinycorelinux.net/index.php/topic,25871.0.html)
I'm recompiling extensions to make sure my build environment will still work (which I've found two issues so far). Xtable-addons will have to be recompiled against the new kernel once the source becomes available as it contains kernel modules.
-
As far as I can tell, the 64-bit readline-dev is OK, 32-bit readline-dev reposted - thanks
-
Hi andyj
... I left it so someone unfamiliar with Apache and PHP would have a go-by to build their own file. I apparently need to delete that file because it must be confusing to beginners. ...
Rather than deleting it, maybe rename it to something like:
httpd.conf.sample or httpd.conf.example or httpd.conf.reference
I think Xorg and some other packages include config files
with similar extensions tacked onto their config file names.
-
There are already sample files in the apache extension. This file is redundant.
-
It looks like you're using the httpd.conf file that the PHP make install copied into the PHP mod extension.
I just scoured the php 8.x sources and "surprisingly enough" cannot seem to find httpd.conf - nor am I aware of any PHP release which includes or has EVER included httpd.conf. What you are likely thinking of with the MOD extension is the httpd/conf.d/mod-php*.conf file which I believe is dynamically generated that adds PHP related support to the existing Apache configuration tree. But... according to you, I'm just a beginner with almost four DECADES in this business. My licenses, certificates and degrees must mean nothing.
To correct your misinformation: PHP does not require Apache. PHP doesn't require NGINX either... or any web server for that matter.
PHP DOES require autoconf 2.x, but that's the extent of dependencies until you start enabling modules.
(If you don't believe me, tce-load -i php-8.3.1.tcz and run php -a)
-
It looks like you're using the httpd.conf file that the PHP make install copied into the PHP mod extension.
I just scoured the php 8.x sources and "surprisingly enough" cannot seem to find httpd.conf - nor am I aware of any PHP release which includes or has EVER included httpd.conf. What you are likely thinking of with the MOD extension is the httpd/conf.d/mod-php*.conf file which I believe is dynamically generated that adds PHP related support to the existing Apache configuration tree.
You're right, PHP does not come with httpd.conf. What you are not getting is that in order to build the PHP module for Apache, PHP requires a working Apache dev install to build against, and when it's done it copies the httpd.conf file from the Apache dev tree as part of the PHP make install. They add one line to the file to load the module based on the Apache source path and not using the DESTDIR of the make install command. Why they think this is necessary I don't know, and it's become clear that it's a bad idea and one I will henceforth squash. The httpd-php8-mod.conf and httpd-php8-fpm.conf files are my contribution, these are not PHP provided files.
To correct your misinformation: PHP does not require Apache. PHP doesn't require NGINX either... or any web server for that matter.
Only the PHP module for Apache requires Apache, I don't know of any other program that can load and run Apache modules. The other PHP SAPI's like the CLI don't require anything, I know because I have scripts I've written for PHP I run from bash. So, no misinformation on my part.
Here's an idea: Slow down and actually read what I'm posting. I've been doing this since the '80s and when I went to college the language we used was FORTRAN. If you're like me like you say you are then you didn't learn any of this in college either because it didn't exist then.
If you are going to take over maintaining maria I can give you what I have that has a lot of workarounds to help you get up the learning curve. It worked for 10.x but enough has changed in 11 that the build script needs more time than I have desire to give it.
-
Hi andyj
... I left it so someone unfamiliar with Apache and PHP would have a go-by to build their own file. I apparently need to delete that file because it must be confusing to beginners. ...
Rather than deleting it, maybe rename it to something like:
httpd.conf.sample or httpd.conf.example or httpd.conf.reference
I think Xorg and some other packages include config files
with similar extensions tacked onto their config file names.
What happened to the post this quote refers to?
-
yes...what did happen to post:
https://forum.tinycorelinux.net/index.php/topic,26669.msg171921.html#msg171921
i have a tab open with the older version of the thread which contains the original « Reply #14 on: January 04, 2024, 10:46:34 AM »
i made a copy of the text and also did a screenshot as well
also will try to leave the tab unrefreshed until we determine what happened to @andyj post
-
There is no decision on the proposal to increase busybox's CONFIG_FEATURE_EDITING_HISTORY?
-
dialog is not working (got this after trying to run getdialog.sh but it wont output any error)
dialog: symbol lookup error: dialog: undefined symbol: acs_map
-
dialog is not working (got this after trying to run getdialog.sh but it wont output any error)
dialog: symbol lookup error: dialog: undefined symbol: acs_map
Alsamixer also dont runs for the same reason
-
What happened to the post this quote refers to?
The log shows CentralWare removed some posts here. CentralWare?
There is no decision on the proposal to increase busybox's CONFIG_FEATURE_EDITING_HISTORY?
Maybe just fell through the cracks, increasing it is fine to me. Juanito, what do you think?
-
What do we want to increase it to, 1000?
-
dialog is not working (got this after trying to run getdialog.sh but it wont output any error)
*getlocale.sh
-
@curaga:
The log shows CentralWare removed some posts here. CentralWare?
Yes, I was putting posts in the "Trash Cache" to have that conversation, unrelated to testing 15.x, moved to a different topic where the debate can continue if it must. I was pulled away from my desk, so it's still in limbo, but the posts themselves should still be waiting for maintenance.
CONFIG_FEATURE_EDITING_HISTORY how difficult would it be to make it cmdline or file based instead of a compiled-in value?
@andyj: If you're looking to unload MySQL/MariaDB please send along what you do have. Additionally, please send along your scripts for apache, php and svn as well. (It's always helpful if the build instructions/script is sent in for ./tcz/src/extension as it could save hours if not days worth of effort, whether for admins, maintainers or end users.) This is especially beneficial with config/compiler flags, patches, etc. as it shows areas which have already been covered instead of everyone having to recreate the same methods. (I did a quick scan of x86/x64 a few days back and noticed the last time build scripts were sent in for MariaDB dated back to TC 7.x, though I could have easily missed one somewhere.)
-
dialog updated and posted
-
If you're looking to unload MySQL/MariaDB please send along what you do have. Additionally, please send along your scripts for apache, php and svn as well. (It's always helpful if the build instructions/script is sent in for ./tcz/src/extension as it could save hours if not days worth of effort, whether for admins, maintainers or end users.) This is especially beneficial with config/compiler flags, patches, etc. as it shows areas which have already been covered instead of everyone having to recreate the same methods. (I did a quick scan of x86/x64 a few days back and noticed the last time build scripts were sent in for MariaDB dated back to TC 7.x, though I could have easily missed one somewhere.)
I put them all in github when TC 14 was released awhile ago but they are a little out of date. I'll try to update them this week and I'll post the URL where anyone who wants them can have them. The scripts are not wholly independent from each other. I have a build system because many of the extensions work together. Each of the extension scripts calls a number of smaller scripts that set variables or options to minimize the number of files I need to update when something changes. I build them all at the same time against the same libraries. This way we shouldn't (hopefully) run into our own version of Windoze dll hell (like openssl and pcre2). Basically, there is a script that builds one extension, and another that goes through the list calling the one-at-a-time script to build them all.
The maria script is 99% complete, meaning that that's the point in the compile where it dies and I had to manually finish it. I'll see if I can get that last bit updated. If you can figure out why maria db won't compile with lz4 enabled that would be really helpful, it wasn't an issue in 10.x, but in 11 it just doesn't like it.
BTW, SVN isn't mine.
-
svn and serf have been updated.
-
I put them all in github when TC 14 was released awhile ago but they are a little out of date.
Thank you for the update; when looking for build scripts I usually look in the repository ./tcz/src for scripts and patches. When looking for sources for something like tc-install-gui or tce I would look at github, I never thought to look for non-TCL build scripts at the hub - thank you for clarifying.
Maria + Lz4: I'll look into this as time permits. I had a strange experience with compression algo's where one (xz I think) depended on specific versions of others (lzo for example) which then affected specific versions of others and it was a race in a circle until all very specific versions were ironed out - I think we had to downgrade one to get a working combination. (Don't quote me here, I'm not reading from our journals and going by vague memory.)
SVN: I'm sorry, I thought I saw your handle on that one; not sure what I must have had open to think this way. No worries, I was planning to rebuild SVN from scratch as it were since we don't have an in-house script for that one and we use SVN from time to time.
-
@andyj: I checked with the tinycorelinux github and didn't see anything new that would have suggested build scripts and the likes; a search on git for your handle... that was funny, only 25+ pages of results to start off with. Thankfully, you had a recent post here (December 29 pertaining to curses) which you sent someone a link to git/andyj713 and voila... TCL14 build scripts! :) We need a better way of managing this sort of content as I'd imagine you're not the only person with their own GIT or other repository where TCL related items live and God forbid if something should happen to any one of you... the losses could be rather painful. Maybe adding repos to somewhere in the user profile here in the forum??
In any event, many thanks and I'll send along a PM should anything come up.
-
Maybe adding repos to somewhere in the user profile here in the forum??
I could/would add them to the TC github pages if I had permission. That's probably a can of worms for the TC maintainers so I wouldn't blame them for not going for that. I could send them a tarball but that's more work for them too. I'm open to suggestions if they're not complicated.
You probably noticed that the maria script wasn't in there, it's permanently in a "test" folder so it didn't get sync'ed. I'll have to do some rearranging so they all wind up available in one place.
You probably also noticed there aren't many comments. That's because if it was hard to write it should be hard to understand. 8) Seriously, though I'll get around to writing something like a quick start guide, but in the mean time if you see something that's completely non-obvious let me know.
-
Hello, andyj. I believe you didn't get my PM.
The latest rxvt update doesn't work on transparency.
CONFIG_FEATURE_EDITING_HISTORY how difficult would it be to make it cmdline or file based instead of a compiled-in value?
This is possible with $HISTFILESIZE (limited by CONFIG_FEATURE_EDITING_HISTORY)
-
You probably noticed that the maria script wasn't in there, it's permanently in a "test" folder so it didn't get sync'ed. I'll have to do some rearranging so they all wind up available in one place.
LOL - no, actually I had git sync your scripts/contrib directories, went into scripts and the first one listed was apache, so I skimmed that one to get a "feel" for how you do things (Nicely organized!) The main difference in our methodology I can see is versioning; there have been times where SO many things have changed between one version and the next (TCL 9.x to 10.x for example) trying to modify a builder to accommodate new and old could get hectic, so I tend to keep versioning separate -- but that's just me.
Scripts: Once things settle on my end (ETA: mid-Feb) I'm going put some vote suggestions up the pipeline to help organize things (including things such as build scripts) and see if we can't organize and optimize submissions. (For example, adding extension-src.tcz to a submission would in my opinion be the perfect means to maintain sources AND build scripts AND dependencies in one shot (which we have automated here when creating TCZs in the first place, but would require a little bit of tweaking to make it TCL repo friendly.)
Maria: When you get a chance, please edit (leave a note "Incomplete" after the she-bang followed by an exit statement) and add it to your ./scripts, then sync with git; drop me a note when it's uploaded; this way she's in the pot, just not part of the compilation recipe and should you run your entire package afterward, she shouldn't interfere with the outcome.
Comments: Not to worry in the least! It's a lot easier following along in a story when someone provides the "Once upon a time..." and build scripts all tell the same story (go from start (source) to finish (binary)) with an occasional patch here and there for climatic moments and a missing dependency, version conflict or seg-fault from time to time for suspense, drama, comedy or utter horror.
-
The latest rxvt update doesn't work on transparency.
That's because somewhere after 9.22 software transparency was dropped and now requires pixbuf and a compositor. I spent days on it and I think I got it to work once but couldn't reproduce it and the way they changed transparency added LOTS of dependencies. So the choice is to stay at 9.22 and not get the latest fixes, or loose transparency and at least not get the bloat. Or fork it from 9.22 and backport the changes, but I'm not about to start that. I liked transparency too, but it's a lose-lose situation as it is now. :(
And no, I didn't get a PM.
-
Hi Juanito. pinentry-gtk2.tcz and pinentry-gtk3.tcz both stopped working in TCL15-alpha x86_64:
symbol lookup error: dialog: undefined symbol: acs_mapI have recompiled pinentry-gtk2 and now it works fine. I've submitted the updated extension.
You are the maintainer of pinentry-gtk3.tcz. Would you like me to submit an updated pinentry-gtk3.tcz extension?
-
Yes please :)
-
Submitted. I'm glad I can help :)
-
I'm seeing these on 32 bit. 64 bit is OK.
1) gtk3-dev needs colord-dev and tiff-dev. It feels like the 32-bit dep file is the 64-bit file instead. If only the extension names were the same between them...
2) I get this with urxvt: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
Strange it doesn't happen on 64 bit.
-
3) I get this with urxvt: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
Strange it doesn't happen on 64 bit.
I tried to compile urxtv to try to apply transparency and got exactly the same error. It's strange that you don't have the error, since google results indicate that it's a problem related to the version of GCC.
In my case, I couldn't even try to compile URXVT, since the same error comes from libptytty.
Could you share the buildscript?
make install
[ 75%] Built target ptytty
[ 87%] Linking C executable c-sample
/usr/local/bin/ld: libptytty.so.0: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/c-sample.dir/build.make:98: c-sample] Error 1
make[1]: *** [CMakeFiles/Makefile2:114: CMakeFiles/c-sample.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
-
nvm
i got it with rxvt-dev but no trans
-
Hi andyj
I'm seeing these on 32 bit. 64 bit is OK.
... undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)' ...
I don't know if this helps, but it appears that function may be in libstdc++.so.6.
This is from the 32 bit TC15 rootfs.gz:
tc@E310:~/core15/tmp$ strings /usr/lib/libstdc\+\+.so.6 | grep throw_out_of_range_fmt
_ZSt24__throw_out_of_range_fmtPKcz
tc@E310:~/core15/tmp$
-
So, going into the weeds, yes, I'm getting the same error in libptytty in the same place, but I called it rxvt because it's part of the whole extension. Once upon a time it was part of the urxvt source, now it has been separated into it's own directory but is still required so I'm compiling them both then bundling them so rxvt won't have yet another dependency with one file that nothing else needs.
Looking through all the logs it apparently does also fail on 64-bit in TC 15, but it did not in TC 14, it works as expected. @CardealRusso if you want to experiment with transparency work in TC 14, at least it compiles there. FWIW I also experimented with 24 bit color (it worked) and sixel (crashed as often as worked). Arch Linux seems to have the most flavors of urxvt patches to try out.
-
Building libptytty from git on tc15.x x86_64 fails with:
[100%] Linking C executable c-sample
/tmp/tcloop/cmake/usr/local/bin/cmake -E cmake_link_script CMakeFiles/c-sample.dir/link.txt --verbose=1
/usr/local/bin/cc -flto -mtune=generic -Os -pipe "CMakeFiles/c-sample.dir/eg/c-sample.c.o" -o c-sample -Wl,-rpath,/usr/src/libptytty/build libptytty.so.0
/usr/local/bin/ld: libptytty.so.0: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
..but if you do this: cc -flto -mtune=generic -Os -pipe "CMakeFiles/c-sample.dir/eg/c-sample.c.o" -o c-sample -Wl,-rpath,/usr/src/libptytty/build libptytty.so.0 -lstdc++
..the build succeeds and libptytty installs: ldd /usr/local/lib/libptytty.so
linux-vdso.so.1 (0x00007fff15948000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f744428d000)
libc.so.6 => /lib/libc.so.6 (0x00007f744409a000)
/lib/ld-linux-x86-64.so.2 (0x00007f74442e2000)
-
..and urxvt-9.31 builds against libptytty and runs without errors
-
The question is what is different between TC 14 and TC 15 that libptytty compiles fine out of the box on TC 14 and not on TC 15? What is different about libstdc++?
-
It seems to be enough to do this before building libptytty:
export LDFLAGS="-lstdc++"
Which solves my immediate problem of getting the scripts to work in TC 15, but doesn't answer why it's now needed.
-
I guess you could see if the gcc-13.2.0 release notes throw up any libstdc++ changes since 12.2.0...
-
Compiling c++ code with gcc is not intended to work, and so having a gcc version break it would not be a bug. That program should use g++ to build since it's c++ code.
-
Is it this?
GCC:
For C++, construction of the global iostream objects std::cout, std::cin, etc. is now done inside the standard library, instead of in every source file that includes the <iostream> header. This change improves the start-up performance of C++ programs, but it means that code compiled with GCC 13.1 will crash if the correct version of libstdc++.so is not used at runtime. See the documentation about using the right libstdc++.so at runtime. Future GCC releases will mitigate the problem so that the program cannot be run at all with an older libstdc++.so.
Or this?
lisbstdc++:
Support for many previously unavailable features in freestanding mode, thanks to Arsen Arsenović. For example, std::tuple is now available for freestanding compilation. The freestanding subset contains all the components made freestanding by P1642, but libstdc++ adds more components to the freestanding subset, such as std::array and std::string_view. Additionally, libstdc++ now respects the -ffreestanding compiler option and so it is not necessary to build a separate freestanding installation of libstdc++. Compiling with -ffreestanding will restrict the available features to the freestanding subset, even if libstdc++ was built as a full, hosted implementation.
-
undefined symbol: acs_map on Python's 3.9 ncurses
-
I’m traveling for the next week, I’ll fix things as soon as I’m back.
-
It boots on my 486DX4 laptop, so the minimum CPU architecture settings are right first time with this release.
-
Good :)
-
undefined symbol: acs_map on Python's 3.9 ncurses
recompiled python3.9 posted