tinycore_v3.8rc3

[roberts]

Obviously you can hack the system as you please but I am not going to bastardize the definition or expected behavior of mydata.tgz in the base system.

[quanpin]

and I don't want to hack the intrid tinycore.gz too.  like tc3.6 and before, they can mount tce and
mydata.tgz , but  they can not set the /opt/.tce_dir to /tem/tce . if tc3.8 can add the $MOUNTPOINTFS" == iso9660  check at last , they all can done.

someone want to burn his hard-disk system to .iso , It can add his tce and mydata.tcz to the CD directly . and other can share .iso  in VMware. just like a  pure tinycore.iso.

 

[bmarkus]

Icon definition in tinycore-appsaudit.desktop is buggy:

[Desktop Entry]
Name=AppsAudit
Exec=appsaudit
Icon=gear
X-FullPathIcon=/usr/share/pixmaps/appsaudit.png
Type=Application
Categories=System;

Proper one:

[Desktop Entry]
Name=AppsAudit
Exec=appsaudit
Icon=appsaudit
X-FullPathIcon=/usr/share/pixmaps/appsaudit.png
Type=Application
Categories=System;

[roberts]

Thanks. Updated the icon entry.

[roberts]

and I don't want to hack the intrid tinycore.gz too.  like tc3.6 and before, they can mount tce and
mydata.tgz , but  they can not set the /opt/.tce_dir to /tem/tce . if tc3.8 can add the $MOUNTPOINTFS" == iso9660  check at last , they all can done.

someone want to burn his hard-disk system to .iso , It can add his tce and mydata.tcz to the CD directly . and other can share .iso  in VMware. just like a  pure tinycore.iso.

I am not going to rehash 3.6 and the broken isos that could be created and resulting posts that many things did not work. Instead of hacking...

Convert mydata.tgz to a .gz    Voila!
   

[Lee]

Under 3.8rc3, the  environment that is set up in .profile does not seem to be in effect for an app loaded as an extension.

This is a change from 3.8rc2 and earlier and it breaks, for instance, some scripts associated with custom buttons in emelfm2.  I don't have a convenient way to test other extensions right now and this is not something that really lends itself to testing in a "base norestore" environment, however, the only difference between the two environments is the instance of bzImage and tinycore.gz (and the bzImage files do in fact match)... using the same tce directory with the same contents (including the same mydata.tgz).  emelfm2 is loaded from the  command line after bootup is complete.

Under 3.8rc3 -and- 3.8rc2, the PATH as reported in a shell is:
/home/tc/.local/bin
/usr/local/bin
/usr/local/sbin
/usr/sbin
/usr/bin
/sbin
/bin

Under 3.8rc3, the PATH as reported by emelfm2 is:
/usr/sbin
/usr/bin
/sbin
/bin
/usr/local/bin
/usr/local/sbin

But, under 3.8rc2, the PATH as reported by emelfm2 is:
/home/tc/.local/bin
/usr/local/bin
/usr/local/sbin
/usr/sbin
/usr/bin
/sbin
/bin

[quanpin]

I am not going to rehash 3.6 and the broken isos that could be created and resulting posts that many things did not work. Instead of hacking...

Convert mydata.tgz to a .gz    Voila!
  

ok , I convert mydata.tgz to data.gz in iso , but it also like not work .

Code: [Select]

# Process any .gzs before attempting to mount tce directory.
# /opt/tce support provided only for the purpose of a remaster.
if [ "$(ls -A "/opt/tce"/*.gz 2>/dev/null)" ]; then
process_gz "/opt/tce"
fi

[ -z "$TCE" ] && TCE="$(autoscan 'tce' 'd')"/tce
if [ "$TCE" != "/tce" ]; then
TCE_DEVICE="${TCE%%/*}"
TCE_DIR="${TCE#*/}"
if [ "$TCE_DEVICE" = "$TCE_DIR" ]; then TCE_DIR="tce"; fi
find_mountpoint "$TCE_DEVICE"
if [ -n "$MOUNTPOINT" ]; then
if [ "$MOUNTED" == "yes" ]; then
if [ ! -d "$MOUNTPOINT"/"$TCE_DIR"/optional ]; then
mkdir -p "$MOUNTPOINT"/"$TCE_DIR"/optional
fi
else
mount "$MOUNTPOINT"
if [ $? == 0 ]; then
UMOUNT="yes"
if [ ! -d "$MOUNTPOINT"/"$TCE_DIR"/optional ]; then
mkdir -p "$MOUNTPOINT"/"$TCE_DIR"/optional
fi
fi
fi
fi
else
   MOUNTPOINT="/tmp"; TCE_DIR="tce"
fi

MOUNTPOINTFS="$(grep ${MOUNTPOINT} /etc/fstab | awk '{print $3}')"
if [ "$MOUNTPOINTFS" == iso9660 ]; then
TCEDIR="$MOUNTPOINT"/"$TCE_DIR"
LOADFROM="$TCEDIR"/optional
[ -s "$TCEDIR"/"$TARGETLIST" ] && for FILE in `cat "$TCEDIR"/"$TARGETLIST"`; do FILE="$LOADFROM/$FILE" && process; done
TCEDIR=/tmp/tce
else
TCEDIR="$MOUNTPOINT"/"$TCE_DIR"
echo "$MOUNTPOINT" > /etc/sysconfig/tce.mount
sync
fi

echo "$TCEDIR" > /opt/.tce_dir
chown -R "$USER".staff "$TCEINSTALLED"

# Process any .gzs in tce directory before regular extensions.
if [ "$(ls -A "$TCEDIR"/*.gz 2>/dev/null)" ]; then
process_gz "$TCEDIR"
fi


Where can I put  .gz  in CD directory ?  add new directory /opt/tce/*.gz  in CD or /tce/*.gz in CD.

I tried it not work.

[maro]

Is there a reason why there are no '*.dep' files in the 'tce/optional' directory of 'multicore_3.8rc3.iso'?

I guess that will make it difficult for a system installed via 'tc-install' as all files from that directory are getting copied to the installation device. On second thoughts is forcing to copy all those files onto the target device really a good idea? Currently the user ends up with all those extensions on the target device (including those not required for the installation mode used).

Furthermore there are also no '*.md5.txt' files present, but maybe that's just me who thinks that those are useful. I'm not really a user of 'appsaudit', but I've got the hunch that the lack of those files might hamper the usefulness of that tool.


Note: I was not sure whether multicore related issues should be added here, or whether there is an already existing thread for them. So mods please move this one, if here is not the right place.

[roberts]

ok , I convert mydata.tgz to data.gz in iso , but it also like not work .

You should look at microcore_3.7.1.iso as it loads multiple .gzs

[roberts]

Under 3.8rc3, the  environment that is set up in .profile does not seem to be in effect for an app loaded as an extension.

This is a change from 3.8rc2 and earlier and it breaks, for instance, some scripts associated with custom buttons in emelfm2.  I don't have a convenient way to test other extensions right now and this is not something that really lends itself to testing in a "base norestore" environment, however, the only difference between the two environments is the instance of bzImage and tinycore.gz (and the bzImage files do in fact match)... using the same tce directory with the same contents (including the same mydata.tgz).  emelfm2 is loaded from the  command line after bootup is complete.

Under 3.8rc3 -and- 3.8rc2, the PATH as reported in a shell is:
/home/tc/.local/bin
/usr/local/bin
/usr/local/sbin
/usr/sbin
/usr/bin
/sbin
/bin

Under 3.8rc3, the PATH as reported by emelfm2 is:
/usr/sbin
/usr/bin
/sbin
/bin
/usr/local/bin
/usr/local/sbin

But, under 3.8rc2, the PATH as reported by emelfm2 is:
/home/tc/.local/bin
/usr/local/bin
/usr/local/sbin
/usr/sbin
/usr/bin
/sbin
/bin

Not being am emelfm user please provide specifics.

[roberts]

Is there a reason why there are no '*.dep' files in the 'tce/optional' directory of 'multicore_3.8rc3.iso'?

I guess that will make it difficult for a system installed via 'tc-install' as all files from that directory are getting copied to the installation device. On second thoughts is forcing to copy all those files onto the target device really a good idea? Currently the user ends up with all those extensions on the target device (including those not required for the installation mode used).

Furthermore there are also no '*.md5.txt' files present, but maybe that's just me who thinks that those are useful. I'm not really a user of 'appsaudit', but I've got the hunch that the lack of those files might hamper the usefulness of that tool.


Note: I was not sure whether multicore related issues should be added here, or whether there is an already existing thread for them. So mods please move this one, if here is not the right place.

The load lst files are simply the contents of the starter packs.  But I see your point for management after performing an installation.

Currently the user has the following Installation options available:
1. If one has wired ethernet, download tc-install.tcz
2. If you have an existing running system, Windows or any Linux distro with net (wired or wireless) access, download starter pack install.gz then boot tinycore, mount and loadpack
3. If you have neither of the above, then you are left with multicore.

You raise a valid point on installation, but perhaps not with regard to network.  The only real stumbling block to performing an installation is the case when no wired network (item 1 above) or no net access via alternate OS (item 2). Then perhaps multicore should only contain the network tools collection! As typically one would want those tools installed. The installation would then be relegated to item 1 & 2 above. Hopefully only item 1.

[Lee]

...
Under 3.8rc3, the PATH as reported by emelfm2 is:
/usr/sbin
/usr/bin
/sbin
/bin
/usr/local/bin
/usr/local/sbin

But, under 3.8rc2, the PATH as reported by emelfm2 is:
/home/tc/.local/bin
/usr/local/bin
/usr/local/sbin
/usr/sbin
/usr/bin
/sbin
/bin

Not being am emelfm user please provide specifics.

I have configured a pair of buttons on the central toolbar of emelfm2, each of which calls a script that is located in ~/.local/bin/

Since /.local/bin/ is added to the PATH by ~/.profile, it was not necessary to configure the buttons with the full path to the scripts because the application, emelfm2, used a PATH inherited (possibly indirectly) form the login shell.

With 3.8rc3, the buttons no longer work.  They do work in 3.8rc2.  A little investigation revealed the PATH listings shown above, which were generated from within emelfm2 under 3.8rc2 and 3.8rc3.

While it would be relatively simple to reconfigure the buttons to use full paths to the scripts they invoke, I worry that this or other environment settings required by this or other applications might cause problems if not set.

I'm supposing that the Xserver gets its initial environment from the login shell and the application gets its initial environment from the Xserver.  Since my working environment is the same other than the rc level of tinycore.gz, I'm wondering what change in tinycore.gz might have caused the observed behavior.

[coreplayer2]

Connection issues with AppBrowser!    Am using Virtual Box for both tc3.7.1  & tc3.8RC3 on a Windows7 machine.    Both VM's use the same hardware (Intel Pro1000) and both are assigned an IP address, yet while the 3.7.1 version 9of AppBrowser connects via the hard line eth0 immediately, the 3.8RC3 beta reports a connection issue when selecting "AppBrowser Connect"


Note: while I misinterpreted this as an internet connection issue it is not but only the App-browser in 3.8RC3 only is unable to connect.  In troubleshooting, I copied firefox.tcz over from the other installation loaded it and it connected as expected.

Even selecting a mirror the connect button fails to connect.

ok  try this!

tc@box:~$ tce-load -wi firefox.tcz
Downloading: firefox.tcz
wget: can't open 'firefox.tcz.md5.txt': Permission denied
Connecting to ftp.vim.org (192.87.102.43:80)
wget: can't open 'firefox.tcz': Permission denied
md5sum: firefox.tcz.md5.txt: No such file or directory
Error on firefox.tcz

tc@box:~$ tce-load -wi firefox.tcz
Downloading: firefox.tcz
wget: can't open 'firefox.tcz.md5.txt': Permission denied
Connecting to distro.ibiblio.org (152.19.134.43:21)
wget: can't open 'firefox.tcz': Permission denied
md5sum: firefox.tcz.md5.txt: No such file or directory
Error on firefox.tcz
tc@box:~$

[quanpin]

You should look at microcore_3.7.1.iso as it loads multiple .gzs

Thanks
I think another method will better
I set the MOUNTPOINTFS == iso9660 check before the file " tc-config " #After restore items

both mydata.tgz and *.gz  in CD all done. and I tested it like a pure tc.iso .

[curaga]

@Lee

I have a proper path (echo $PATH in mc 3.8rc3 after login). The path mentioned is only active during extension loading; does emelfm create a config file on load? Perhaps it grabs the wrong path there.

Could you check in a shell too?