Tiny Core 15.0 Alpha 1 Testing

[CentralWare]

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.

[CentralWare]

@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.

[andyj]

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. 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.

[CardealRusso]

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)

[CentralWare]

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.

[andyj]

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.

[GNUser]

Hi Juanito. pinentry-gtk2.tcz and pinentry-gtk3.tcz both stopped working in TCL15-alpha x86_64:

Code: [Select]

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?

[Juanito]

Yes please

[GNUser]

Submitted. I'm glad I can help

[andyj]

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.

[CardealRusso]

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?

Code: [Select]

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


[CardealRusso]

nvm
i got it with rxvt-dev but no trans

[Rich]

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:

Code: [Select]

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$

[andyj]

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.

[Juanito]

Building libptytty from git on tc15.x x86_64 fails with:

Code: [Select]

[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:

Code: [Select]

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:

Code: [Select]

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)