WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: microcore_v2.10rc1  (Read 11737 times)

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7361
  • Founder Emeritus
microcore_v2.10rc1
« on: March 08, 2010, 12:22:06 PM »
The First Release Candidate of Micro Core v2.10 (microcore_2.10rc1.iso), is now posted and ready for testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/release_candidates/microcore/

microcore_2.10rc1.iso
microcore_2.10rc1.iso.md5.txt

Change Log for Micro Core v2.10

* Updated tce-load - much improved recursion support.
* Added missing rule for mmc support.
* Updated tc-config PXE tftp http for onboot.lst support.
* Updated tce-audit to download dep to /tmp then move to tce dir.
* Removed unneeded libthread_db* from base.

Updated Xprogs.gz with all the changes as listed for Tiny Core v2.10rc1 see:
http://forum.tinycorelinux.net/index.php?topic=5310.0
10+ Years Contributing to Linux Open Source Projects.

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14516
Re: microcore_v2.10rc1
« Reply #1 on: March 08, 2010, 10:48:38 PM »
Using appbrowser to load local, I like that you just need to double-click on an extension and it's loaded - no more clicking on "OK" afterwards  :)

Starting with no backup (and also with "base norestore") I only get a black background with Xvesa.

.setbackground does not exist in /home/tc - copying it from /etc/skel results in a seg fault when I try to run it.

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7361
  • Founder Emeritus
Re: microcore_v2.10rc1
« Reply #2 on: March 09, 2010, 08:19:16 AM »
base norestore on microcore would imply no window manager as no extensiona are being loaded therefore a black screen. Might try to manually load flwm & wbar extensions?
10+ Years Contributing to Linux Open Source Projects.

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14516
Re: microcore_v2.10rc1
« Reply #3 on: March 09, 2010, 09:36:54 AM »
base norestore on microcore would imply no window manager as no extensiona are being loaded therefore a black screen. Might try to manually load flwm & wbar extensions?

Sorry - I should have said I tried two ways:

"base norestore" then "tce-setup"
normal boot loading extensions and X*gz from tce, but with no backup being restored

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7361
  • Founder Emeritus
Re: microcore_v2.10rc1
« Reply #4 on: March 09, 2010, 09:26:41 PM »
Got it! Thanks. Fixed in rc2.
10+ Years Contributing to Linux Open Source Projects.

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14516
Re: microcore_v2.10rc1
« Reply #5 on: March 10, 2010, 06:08:53 AM »
Are we looking to have recursive deps load extensions in the order listed in the dep file as per "standard" deps?

If we assume for a moment that the avahi or dbus extensions try to start the dbus daemon from the start-up script (they no longer do this, but just for the sake of an example) and load rhythmbox using a recursive dep file, then the load order is:

avahi
dbus
expat2

..which means it wouldn't work.

Code: [Select]
$ cat rhythmbox.dep
totem-pl-parser.tcz
gnome-media.tcz
libsoup-gnome.tcz
gst-plugins-good.tcz
gst-plugins-bad.tcz
gst-plugins-ugly.tcz
gst-python.tcz
gmime.tcz
pygtk.tcz
pyorbit.tcz
gnome-python.tcz
libnotify.tcz
libgpod.tcz
gnome-icon-theme.tcz
shared-mime-info.tcz


Offline bmarkus

  • Administrator
  • Hero Member
  • *****
  • Posts: 7183
    • My Community Forum
Re: microcore_v2.10rc1
« Reply #6 on: March 10, 2010, 06:13:00 AM »
As far as I know startup scripts executed after all extensions are loaded in alphabetic order. Maybe I'm wrong...
Béla
Ham Radio callsign: HA5DI

"Amateur Radio: The First Technology-Based Social Network."

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14516
Re: microcore_v2.10rc1
« Reply #7 on: March 10, 2010, 07:17:17 AM »
Here's what I see when testing:
Code: [Select]
$ tce-load -i /mnt/sda1/tmp/rhythmbox_rec/rhythmbox.tcz
shared-mime-info.tcz OK.
gnome-icon-theme.tcz OK.
libgpod.tcz OK.
libnotify.tcz OK.
popt.tcz OK.
libbonobo.tcz OK.
audiofile.tcz OK.
esound.tcz OK.
gamin.tcz OK.
udevadm.tcz OK.
libusb.tcz OK.
usb-utils.tcz OK.
libpci.tcz OK.
pci-utils.tcz OK.
hal.tcz OK.
nss-mdns.tcz OK.
libdaemon.tcz OK.
gcc_libs.tcz OK.
/usr/local/tce.installed/avahi: line 14: dbus-daemon: not found
avahi-daemon: error while loading shared libraries: libexpat.so.1: cannot open shared object file: No such file or directory
avahi.tcz OK.
gnome-vfs.tcz OK.
...
dbus.tcz OK.
...
expat2.tcz OK.
...
rhythmbox.tcz OK.

again, I modified avahi to attempt to start dbus for the sake of testing
« Last Edit: March 10, 2010, 07:52:00 AM by Juanito »

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7361
  • Founder Emeritus
Re: microcore_v2.10rc1
« Reply #8 on: March 10, 2010, 07:38:43 AM »
I would be happy to look at a tarball of your test case, perhaps if posted bmarkus and myself could look at it. However avahi should not be a dependency of rythmbox. Look at Debian, avahi is a recommends. Additionally startup scripts should be for extensions and not embedded within the dependency chain. The dependecny chain is recusred in order load all reuired files needed by the requested extension. The requested extension is always loaded last, and therefore its startup script should be successful.
10+ Years Contributing to Linux Open Source Projects.

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7361
  • Founder Emeritus
Re: microcore_v2.10rc1
« Reply #9 on: March 10, 2010, 07:59:51 AM »
To explain more look at:
http://packages.debian.org/sid/rhythmbox
and
http://packages.debian.org/sid/avahi-daemon
It would seem therefore they are separate and both would require a dependency chain that would be necessary, (and which happens to have many dependencies in common), for their startup script to be successful.

I would need to see a tarball(s) in order to more fully understand what is being attempted.


10+ Years Contributing to Linux Open Source Projects.

Offline Jason W

  • Administrator
  • Hero Member
  • *****
  • Posts: 9730
Re: microcore_v2.10rc1
« Reply #10 on: March 10, 2010, 09:45:35 AM »
I have also tested various extensions and noticed that with the current RC recursion method, and noticed startup scripts in the dependency chain that depend on either their deps to be loaded or their deps' startup scripts to be run may not work.  Since duplicates are not echoed into /tmp/deplist, an existing listing of expat will be lower in the list than some deps that need expat loaded for its startup script to function instead of it being echoed again above the extension that needs it. 

We currently with simple dep files support startup scripts that require either their deps to be loaded or the startup scripts of their deps to be run, whether during boot or appbrowser use.  And since the simple dep files determine the order of loading, startup scripts in the dependency chain are also supported.

What this means for extensions is that each dep file needs to contain all the needed functions for it to work, including any needed startup functions of its dependencies.  Instead of depending on a dependency to run it's startup script first. 

No big deal, but it is to be noted as a change in startup script behavior. 

Offline bmarkus

  • Administrator
  • Hero Member
  • *****
  • Posts: 7183
    • My Community Forum
Re: microcore_v2.10rc1
« Reply #11 on: March 10, 2010, 10:20:37 AM »
I didn't check actual code, but I think this is  simple.

Extension loading and startup script execution are two different thing and must be separated.

First, ALL extensions must be loaded. Order is not important, it may happen in any sequence, depending on definition order, recursion method, etc. Don't care.

Next, when all extensions are loaded, startup scripts are executed. At this point can't be missing extensions, so startup scripts must work. The only issue is their execution order. Easiest way is alphabetic order. There are two prerequists:

1) An extension is allowed to install a startup script with any name independently of extensions name

2) There must be a cooperation between extension maintainers and core team to  keep it working.
« Last Edit: March 10, 2010, 10:24:30 AM by bmarkus »
Béla
Ham Radio callsign: HA5DI

"Amateur Radio: The First Technology-Based Social Network."

Offline Jason W

  • Administrator
  • Hero Member
  • *****
  • Posts: 9730
Re: microcore_v2.10rc1
« Reply #12 on: March 10, 2010, 10:38:31 AM »
Running all startup scripts after all deps and extension is loaded would work as far as the needed dependencies being loaded, but as you said it wouldn't control order of loading. 

But one thing I ask to be tested.  And that is not suppressing duplicate entries in /tmp/deplist during the recursive scan routine.  In my testing it has produced dep-first loading and startup script execution that would support things like the rhythmbox example.  I could be wrong, but I think it is worth a try.


Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7361
  • Founder Emeritus
Re: microcore_v2.10rc1
« Reply #13 on: March 10, 2010, 10:57:47 AM »
I don't think duplicates are helpful, as once loaded any duplicate is ignored.
Order is defined by recursion as added to deplist in 'stack' order. If any extension has a startup script then that script should be satisfied if its own .dep (list of dependencices required of its startup script) is loaded, which is currently the default. It will be most helpful if test case data is supplied.
10+ Years Contributing to Linux Open Source Projects.

Offline bmarkus

  • Administrator
  • Hero Member
  • *****
  • Posts: 7183
    • My Community Forum
Re: microcore_v2.10rc1
« Reply #14 on: March 10, 2010, 11:00:45 AM »
For sure there are different solutions. However separation of loading and startup execution into two phases makes it more transparent and simple. Also it is much closer to usual persistent installation where no loading, everything is there.

Coordination is not a problem. First, there is a limited number of extension makers. Second, there can be ranges defind for system processes, like dbus, hal, etc. and for user level applications and for other necessary startartup levels. It would reduce risk for simple applications to mismatch system.

BTW, there are cases where a shutdown script would be necessary .

All together this would be a similar to the traditional redhat-like startup within a single run level. It works, flexible, ...
Béla
Ham Radio callsign: HA5DI

"Amateur Radio: The First Technology-Based Social Network."