Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: polikuo on November 02, 2020, 05:02:11 AM
-
I think there should be a dedicated Child Board for dependence reporting.
Just like [Extension requests]
Anyway ~
CorePure64 11.1
gnome-shell-gir needs network-manager-applet-gir (not copied)
gnome-session uses xdg-user-dirs (not copied)
-
We could use TCE Bugs for dependency problems?
For network-manager-applet-1.8.10 in CorePure-10.x, dev and gir files were produced by the build. For network-manager-applet-1.16.0 in CorePure-11.x, no dev or gir files were produced. I don't see any errors when using network-manager in gnome-session?
I didn't include xdg-user-dirs in the gnome-session deps because xdg-user-dirs-update is only required once if you have a backup.
Edit: $ g-ir-inspect Shell --print-typelibs
typelib: xlib-2.0
typelib: GDesktopEnums-3.0
typelib: GModule-2.0
typelib: xfixes-4.0
typelib: Meta-6
typelib: Clutter-6
typelib: Gtk-3.0
typelib: GObject-2.0
typelib: Gck-1
typelib: St-1.0
typelib: GL-1.0
typelib: CoglPango-6
typelib: Json-1.0
typelib: Cogl-6
typelib: PolkitAgent-1.0
typelib: GLib-2.0
typelib: cairo-1.0
typelib: Atk-1.0
typelib: Gvc-1.0
typelib: Polkit-1.0
typelib: Gdk-3.0
typelib: ClutterX11-6
typelib: Gio-2.0
typelib: NM-1.0
typelib: Gcr-3
typelib: Pango-1.0
typelib: Cally-6
typelib: GdkPixbuf-2.0
typelib: PangoCairo-1.0
typelib: Graphene-1.0
NM-1.0 is supplied by networkmanager-gir
-
Hi polikuo
I think there should be a dedicated Child Board for dependence reporting. ...
Missing dependencies belong in TCE Bugs.
-
For network-manager-applet-1.8.10 in CorePure-10.x, dev and gir files were produced by the build. For network-manager-applet-1.16.0 in CorePure-11.x, no dev or gir files were produced. I don't see any errors when using network-manager in gnome-session?
So somewhere in the gnome-session tree need some fixing ?
It's been a long time since I last use Corepure64.
I'm starting fresh and tce-install -w gnome-session reports they are missing
I didn't include xdg-user-dirs in the gnome-session deps because xdg-user-dirs-update is only required once if you have a backup.
OK~
tce-load reports not found back then, a typo perhaps ?
-
Hi polikuo
I think there should be a dedicated Child Board for dependence reporting. ...
Missing dependencies belong in TCE Bugs.
what if there is bloat and too many dependencies? that's not a bug or?
i tried installing gparted on the latest release over an LTE modem, had to give up in the end :D
-
Hi hiro
... what if there is bloat and too many dependencies? that's not a bug or? ...
If the dependency doesn't belong, it's a minor bug.
If the extra dependency can't coexist with another installed extension, maybe not so minor.
If it's a build leftover (gtk3-dev.tcz instead of gtk3.tcz), it pulls in an extra 140 MB of dependencies.
-
Missing dependencies belong in TCE Bugs.
So ~
A child board of TCE Bugs ::)
Just speaking out my thought, cause there are so many posts related to dependence
It kinda make sense to have a special place to sort things out...
To me, bug sounds like typo in start-up scripts, program having weird behaviors,
missing files here and there, incompatible libraries ...etc
Dependence is just a portion of it...
-
So somewhere in the gnome-session tree need some fixing ?
gnome-shell-gir deps adjusted
-
Hi
A quick one, binutils depends on flex.
Just extracting some simple archives with ar command
ar: error while loading shared libraries: libfl.so.2: cannot open shared object file: No such file or directory
On both PiCore port, the deps are OK
On both x86 x86_64, binutils.tcz.dep isn't presented.
-
dep files adjusted - thanks
-
@Juanito, @Curaga and everyone else:
We're currently re-designing the functionality of tce-load/tce-ab which has the ability to back-step into older repository versions in order to find files which may not yet have made it into the latest version's repo directory (or TCZ's which have simply fallen through the cracks and forgotten about.) HOWEVER, there's a debate as to how things should be prioritized, so I'm throwing this out there for everyone else to put in their two cents:
Installed TCL: v11.1 x86_64
Version_Max then defaults to 11.x (the highest version in the repo to hunt through) and Version_Min is set to 5.x by default; both are command-line controlled
Extension: busybox-httpd.tcz
Scenario: Let's say this extension does not exist in tinycorelinux/11.x/x86_64/tcz but DOES exist in 9.x/x86_64 as well as 10.x/x86; merely as an EXAMPLE.
- I'm "assuming" most x86 extensions are just copied or linked from x86 into x86_64, but since we don't compile the masses, it's just an assumption.
- I'm "assuming" most people would want the newest, MATCHING platform (x86_64) even if there was a newer NON-MATCHING (x86)?? (Toss-up here!)
- I'm picking on busybox-httpd simply because busybox exists in all platforms and httpd relies on internal busybox functions, some of which may break over time as busybox evolves.
Please give your opinions, experiences, thoughts, etc. in relation to "if it were you, what would you do?"
-
Hi centralware
I'll start by expressing an opinion. I suspect this type of function would not be incorporated into Tinycore due to the
potential of users installing incompatible extensions causing breakage or inconsistent system behavior. This in turn
would likely lead to bug reports due to problems the users themselves created. End of opinion.
Pitfalls:
Dependency versions change causing breakage. Examples that have caused issues include libffi, libpng, openssl,
and ncurses. Those came to mind because they affected a fairly large number of extensions.
Extensions get refactored into multiple smaller extensions, resulting in missing dependencies.
Extensions get combined (ipv6 and netfilter) resulting in a name change, dependencies no longer exist.
Extensions get dropped, dependencies no longer exist. Now you need to copy them too with the possible
issues listed above.
... I'm "assuming" most people would want the newest, MATCHING platform (x86_64) even if there was a newer NON-MATCHING (x86)?? (Toss-up here!) ...
I don't understand this. You can't mix 32 and 64 bit extensions.
... I'm picking on busybox-httpd simply because busybox exists in all platforms and httpd relies on internal busybox functions, some of which may break over time as busybox evolves. ...
I'm pretty sure busybox-httpd does not use the system supplied busybox if that's what you are implying. Based on
the .info file, it's a tiny version of busybox with only 2 applets compiled.
-
@Rich: Opinion received and well taken.
Argument: The next time there's an ARM kernel compilation, a new(ish) version is presented in the repo (say 14.x) and people start learning of its existence.. while Béla is getting nailed to the cross with the barrage of posts saying "where's this extension?" and "isn't it compiled yet?" this is where we decided to leave the poor guy alone and experiment with tce-load/ab and more times than not, it's successful. Yes, there are going to be those extensions which get broken when ncurses.tcz gets revamped and renamed to ncursesw.tcz and a few of the functions which used to be part of the package are now found in separate dependencies scattered around the universe (etc. -- that's just a rant from a recent TCL Apache/LAMP build that went South. :) )
Example: We use dropbear for in-house SSH; back in v6 through v8 it went MIA within the repo; and I think it reappeared in 9.x. Instead of hunting, or God forbid hounding an already overworked crew "Hey, where's my bear?" we re-used 5.x's copy throughout the different versions without a hitch. Actually, 9.x might have even been our submission; I can't recall.
As for x86/x64 "...you can't mix..." maybe you can clarify something for me?
I recall posts from WAY back when that had discussed opting for x86_64 to be created in TC, different approaches, etc. and maybe there's been assumptions fed from dusty memories, but if x86 is strictly 32 bit kernel/user and x64 is strictly 64 bit kernel/user, what are the filename64 items doing in 12.x/x86/release/distribution_files? (I thought these were supposed to be something like 64b kernel / 32b userspace where x86 extensions would operate, but I also recall someone noting it wasn't like M$'s WoW/emulation/etc.?)
Regardless, thanks for your input and efforts!
Mr. T. J. Glawitsch -- President
American Networks, Assoc.
CentralWare Development Centers
-
what are the filename64 items doing in 12.x/x86/release/distribution_files? (I thought these were supposed to be something like 64b kernel / 32b userspace where x86 extensions would operate, but I also recall someone noting it wasn't like M$'s WoW/emulation/etc.?)
Those files do indeed allow running Core64 - i.e. 64bit kernel with 32bit userspace
There was also a somewhat hacked 32/64 bit multi-lib "demo" at http://tinycorelinux.net/11.x/x86_64/tcz/src/multilib/
-
Core64 = 64-bit kernel and 32-bit userspace. But that uses the x86 repo natively, it can't use the x86_64 repo.
-
@Curaga & @Juanito: Thanks for clarifying! I haven't tinkered in the 86/64 transition era in so long... so many (dusty!) memories...
-
HEllo
Cross compliance.
Dusty memories.........try seeing WHeely Bins "filled" with thrown---out fully working Ram memory sticks........
"Dusty memory's"e
Thx.
C.
-
If memory serves, I believe I still have a couple 20/40Megabyte MFM hard drives, weighing in around 10-12lbs each sitting in storage.
...
I've been doing this far too long!
...
If you know of anyone in need, there's a 22gal plastic bin about to go to the landfill with ISA, AGP, PCI-x and other similar vintage cards (...anyone remember Sound Blaster? LMAO... 19.9 FAX MODEMS??? :^) )
-
Pci-x and agp are of little use, but isa and pci cards do have some value still, if you want to ebay/etc them. Retro gamers building DOS boxes, etc.
-
Pci-x and agp are of little use, but isa and pci cards do have some value still, if you want to ebay/etc them. Retro gamers building DOS boxes, etc.
Will take that into account if/when I find the free time to post them online. :)
Probably the same reason they are still sitting in plastic tubs after all these years!
-
Pci-x and agp are of little use, but isa and pci cards do have some value still, if you want to ebay/etc them. Retro gamers building DOS boxes, etc.
Will take that into account if/when I find the free time to post them online.
some computer recycling places also build functioning machines from the donated parts to sell to hobbyists and such.