Tiny Core Linux
dCore Import Debian Packages to Mountable SCE extensions => dCore X86 => Topic started by: Jason W on June 28, 2013, 09:15:02 AM
-
Team Tinycore is pleased to announce the testing release of dCore-5.0.alpha1, Core made from Debian Wheezy compatible files that uses import and the SCE package format. Features include:
- Debian Wheezy (Debian Stable) library compatibility.
- Fully functional toolchain when importing build-essential and pertinent development packages.
- Support for custom packages that are not available via Debian.
- SCE package format: imported packages include the package and it's needed dependencies in one file, files contained are symlinked to live filesystem.
- Meta packages to simplify usage are available.
- Support for custom startup scripts.
- Premade SCE packages for kernel modules and wireless.
Files can be found at:
http://tinycorelinux.net/5.x/x86/release_candidates/
A brief intro to the use of import:
The command as regular user "import iceweasel" will import iceweasel and it's needed dependencies and place them in an sce file in the sce/ directory in the users TCE directory. "import -b iceweasel" will import it and add it to the sceboot.lst file to be loaded at boot. The command "loadsce iceweasel" will install it.
For efficiency, a file list can be made of one's favorite packages and import can be used to make one mega package out of the list. Example, a file named mydesktop that contains xfce4, leafpad, iceweasel, exaile, smplayer, etc, etc , one package per line, will make an sce of those packages that will be named mydesktop.sce. If the file is located on /mnt/sda2, the usage would be:
import -f /mnt/sda2/mydesktop
Premade SCE packages are available at:
http://tinycorelinux.net/5.x/x86/sce/
Fetching them is done with the sce-fetch.sh command. "sce-fetch.sh wireless-tools" will fetch wireless-tools.sce, the command "loadsce wireless-tools" will install it.
Needed for X desktop use are the SCE packages:
Xprogs.sce
Xtc.sce
A simplified manner of installing Xorg is using the Xsetup.sh script:
http://tinycorelinux.net/5.x/x86/Xsetup.sh
Download it, use the command "chmod +x Xsetup.sh" and run it. This will install the familiar flwm_topside window manager and xorg-all, the Xorg meta package that contains support for all the Xorg video drivers. Also needed may be graphics-3.8.10-tinycore for some hardware.
Readmes are available at:
http://tinycorelinux.net/5.x/x86/README/
The command "readme.sh wireless-tools" will display that readme.
-
I’m really impressed with this project. The possibility to pick any debian package and make a TC package out of it is excellent!
I can’t help wondering, though, what will happen to this project from TC5 on, as I gathered that the SCM package format will be dropped, or won’t it?
-
dCore-5.0.alpha1.iso
isolinux.cfg configured to load core.gz but there are no such only dCore.gz therefore boot fails.
-
Awesome, that's why you were so busy jason! Effectively a feature like that could fully replace the scm packages, but could you explain me how work these packages? :
1) you can choose whether to install them in a loop or in ram?
2) you can uninstall (as the scm) during the execution time of the os?
3) apart for the support of debian packages, the dcore is fully compatible with the core features?
I can’t help wondering, though, what will happen to this project from TC5 on, as I gathered that the SCM package format will be dropped, or won’t it?
I think the scm has been abandoned for the lack of interest by packagers, but if this new system works well I think it will maintain itself
-
Thanks bmarkus, I have not tried the ISO only the dCore.gz so I did not catch that.
vinnie and theYinYeti,
The SCM has been dropped, basically since without an automated way to make them like the CDE model it was just too time intensive once you get past the simple apps. The SCE has replaced the SCM, as it contains all it's needed dependencies in one file.
The SCE only uses mount mode, it is not copied to RAM. They cannot be uninstalled since like the TCZ the files exist in the regular filesystem, the SCE is not self contained although it contains multiple packages inside of it. And dCore aims to support all core features, it simply draws on the Debian repo for it's extensions. But the extension installing/updating features of the TCZ are not all supported by the SCE, but that is partially due to the differences in package type.
-
Thank you for the clarification Jason W.
Let me repeat: it is an awesome project! :-)
One thing I liked a lot about DSL, years ago, was that it was light enough to support my 24MB RAM Toshiba laptop, but I still could enable “Debian compatibility mode” and install packages from Debian Woody repositories :-p
Nice work!
-
And dCore aims to support all core features, it simply draws on the Debian repo for it's extensions. But the extension installing/updating features of the TCZ are not all supported by the SCE, but that is partially due to the differences in package type.
So there are only sce extensions in dcore and not tcz?
-
dCore-5.0.alpha1.iso
isolinux.cfg configured to load core.gz but there are no such only dCore.gz therefore boot fails.
Fixed on server for next iso creation.
-
And dCore aims to support all core features, it simply draws on the Debian repo for it's extensions. But the extension installing/updating features of the TCZ are not all supported by the SCE, but that is partially due to the differences in package type.
So there are only sce extensions in dcore and not tcz?
That's why sces are not just merged into Core.
dCore the 'd' is for Debian and also for different from Core.
no tcz support in dCore.
You may want to read http://forum.tinycorelinux.net/index.php/topic,14332.msg91108.html#msg91108
which explains why sce.
The concept behind dCore is to more easily maintain the Core philosophy across many platforms without having to build and maintain many platform specific repositories
-
Some unordered questions, simply in as they occurred to me.
Once an SCE app is imported is it possible to apply a security upgrade (issued by Debian) to an active dCore system, or is a rebuild of the SCE app required to incorporate it?
...dCore aims to support all core features, it simply draws on the Debian repo for it's extensions.
As it draws on Debian Stable does this imply an app in SCE format inherits the same degree of app stability? Is it vulnerable to upgrade changes at an OS (dCore) level?
The SCE has replaced the SCM, as it contains all it's needed dependencies in one file.
Does this mean an SCE app is resistant to breakage? For example is it vulnerable to SCEs created from custom packages that are not available via Debian? Is there any degree of sharing common dependencies in an SCE?
Can an SCE be managed a single entity? e.g. can it be removed (not unloaded/uninstalled) from a system as a single unit in a similar manner that an SCM was? How do a user do it?
Have any tentative comparisons been done of RAM usage for similar SCE v TCZ systems? If so the figures might be informative.
-
That's why sces are not just merged into Core.
dCore the 'd' is for Debian and also for different from Core.
no tcz support in dCore.
You may want to read http://forum.tinycorelinux.net/index.php/topic,14332.msg91108.html#msg91108
which explains why sce.
interesting, thanks roberts
-
Some unordered questions, simply in as they occurred to me.
Once an SCE app is imported is it possible to apply a security upgrade (issued by Debian) to an active dCore system, or is a rebuild of the SCE app required to incorporate it?
dCore is not Debian. Nor is it traditionally "installed". dCore uses mounted squashfs as tcz and scms did. There is no rebuild, as apps are typically imported. We are only supplying scripts ( the import suite in the base of dCore ) and some server side typically setup/data scripts. You might want to think download script as used for flash.
...dCore aims to support all core features, it simply draws on the Debian repo for it's extensions.
As it draws on Debian Stable does this imply an app in SCE format inherits the same degree of app stability? Is it vulnerable to upgrade changes at an OS (dCore) level?
Stability was another reason of our choice of Debian stable. Also, like the scm format, sces are not subject to the rolling release breakage of tcz dependencies. dCore is an embedded Linux with mainly busybox calls to ash and awk. Changes in the base should have little to do with applications. Same as Core.
The SCE has replaced the SCM, as it contains all it's needed dependencies in one file.
Does this mean an SCE app is resistant to breakage? For example is it vulnerable to SCEs created from custom packages that are not available via Debian? Is there any degree of sharing common dependencies in an SCE?
Can an SCE be managed a single entity? e.g. can it be removed (not unloaded/uninstalled) from a system as a single unit in a similar manner that an SCM was? How do a user do it?
sces can be removed as a single entity without breakage, although not dynamically. Like tczs, a reboot is needed to effect., i.e.,simply rm the target sce and reboot, if such was loaded.
Have any tentative comparisons been done of RAM usage for similar SCE v TCZ systems? If so the figures might be informative.
I doubt much change, but like scms, sces are larger physically and require similiar persistent storage.
Not mentioned but another area that may be of interest is that sce, even custom compiled, unlike tczs do not need to be relocated to /usr/local/. Standard compilation methods, when required, are supported.
Sces have been used in the Allwinner A10 port since its initial post and now Jason has implemented them for x86. The goal being to preserve Core's philosphy while trying to support multiple platforms without the need to do relocate compiliations for tcz respositories for each and every platform.
-
dCore-5.0.alpha2 now available:
* Fixed bug in sce-fetch.sh, -i now works, added -b to add to sceboot.lst
* Fixed bug in isolinux.cfg on server to specify dCore.gz
* Added initial sceboot.lst to tce-setdrive.
Files available at:
http://tinycorelinux.net/5.x/x86/release_candidates/
As a result, these files have also changed:
http://tinycorelinux.net/5.x/x86/Xsetup.sh
http://tinycorelinux.net/5.x/x86/README/README-X-Desktop.txt
-
In addition to Robert's more thorough explaining of the dCore philosophy and design, one thing that import and dCore share in common with Core is the support of things that are either too new or too old for Debian. Gtk1 is available in dCore, XMMS is already there and can be fetched with the command "import xmms". Same with Firefox and Emelfm2, neither of which are in Debian. Iceweasel is frozen at version 10, and a Firefox at version 10 is quite dated though stable. "import firefox" and "import emelfm2" will get those packages at their latest upstream versions. The latest firefox will be maintained since it is popular. More Gtk1 apps can be built and made available. The rule there is that extra packages need to be not available in Debian nor should they conflict with existing Debian packages.
-
dCore-5.0.alpha3 now available:
* Fixed bug in tce-setup to quiet terminal output from startup scripts
Files available at:
http://tinycorelinux.net/5.x/x86/release_candidates/
Use the command "loadsce -d pkgname" for debug mode if you want to log the output of startup scripts to /var/log/sce.log.
-
Once an SCE app is imported is it possible to apply a security upgrade (issued by Debian) to an active dCore system, or is a rebuild of the SCE app required to incorporate it?
dCore is not Debian. Nor is it traditionally "installed". dCore uses mounted squashfs as tcz and scms did. There is no rebuild, as apps are typically imported. We are only supplying scripts ( the import suite in the base of dCore ) and some server side typically setup/data scripts. You might want to think download script as used for flash.
If I understand this correctly...
If a security upgrade for an app is released into Debian Stable (of course not a feaure upgrade) it would require the app to be imported again in order for the upgrade to be included within an SCE.
If the above is correct, in a case where an app was not re-imported might it be stable but one or more of the constituent packages might have unaddressed vulnerabilities. Does it follow that SCEs may need to be regularly re-imported in order to remain both stable and have addressed vulnerabilities?
-
Not sure of your position... But I see it as another advantage.
It is quite simple to import versus asking and waiting for a community member to recompile for relocation on current native Core, unless, perhaps, you are the type that perfers to compile everything.
Also on native Core to implement a security upgrade not only depends on a community member being available, it may also lead to breakage.
This versus the vast community of Debian developers who maintain Debian.
But the choice is yours. We are only offering an additional Core.
If you prefer native Core you have it. It is not going away as witnessed by the on going development of Core 5. If on the other hand you had have issues with rolling release libraries and such, or your favorite package is no longer being maintained in native Core, you may want to consider dCore.
-
I had thought of security updates, but I think most security fixes for Debian apply to server use and not standard desktop use, especially with how TC is used 99 percent of the time. And as Robert pointed out, there are upsides and downsides to keeping with stable versions versus the latest versions of packages.
But it was simple to code in an option in import that would provide info in the SCE to allow a check for packages that an SCE is comprised of which have been updated upstream in Debian since the SCE was imported. A simple tool then could be ran against an SCE to inform the user which packages have been updated, and then the user can view the Debian changelog of updated packages to determine if there is need for an update based on the users particular situation. I will consider it to be included in alpha4.
-
Not sure of your position...
The questions are not intended to be disparaging. They are motivated by a desire to understand the newly introduced SCE format. The ability to use Core (dCore) together with apps drawn from the Debian stable repo is very appealing.
Here, TinyCore and other distros based on Debian stable are widely used. The ability for each of them to draw apps from a common repo is a welcome simplification.
The following comments are made without having tested a dCore system yet.
Security Upgrades
The Debian stable based distros referred to above, download and install any given security upgrade only once. This is done using a single command i.e. apt-get upgrade. Because of their traditional installation model, this is then available system-wide.
From our previous discussion, I am guessing a dCore system might have a repeated re-import process to achieve a simalar result, i.e. once for each SCE.
From the original post announcing the SCE format a mega package can be created....a file list can be made of one's favorite packages and import can be used to make one mega package out of the list. Example, a file named mydesktop that contains xfce4, leafpad, iceweasel, exaile, smplayer, etc, etc , one package per line, will make an sce of those packages that will be named mydesktop.sce.
In such a case I'm guessing that only a single re-import is required to incorporate a given security upgrade.
A dCore system might comprise multiple SCEs. In this case I'm guessing that multiple re-imports are required to incorporate a given upgrade. If this guess is correct might it be worth considering an OS level command to enable all SCEs within the system to be upgraded from a single command.?
...I think most security fixes for Debian apply to server use and not standard desktop use...
I'm not sure about this. This post is being made from a general purpose desktop system running Debian 7 stable. It has security upgrades applied regularly.
A simple tool then could be ran against an SCE to inform the user which packages have been updated, and then the user can view the Debian changelog of updated packages to determine if there is need for an update based on the users particular situation. I will consider it to be included in alpha4.
See the suggestion above re automating the upgrade process in a single command for multiple SCEs. While I am in favour of user choice, I also support user friendliness of operation.
Edited to improve clarity.
-
Samk,
I am sure that there are Debian desktops all over the world that receive security updates regularly. My point is that I am sure most of the updates are not NEEDED for desktop use. A vulnerability in samba is not going to all of a sudden render a standard home desktop useless due to security exploits. Even if that user runs samba to read windows shares every day on their home network. Most dCore desktops will not have services running at all that are open to login from the outside world.
I am not trying to trivialize security exploits, but for the typical desktop user, Linux or otherwise, by far your biggest security risk is related to behavior as in password habits and such. And when it is all said and done, security is simply a feeling of trust and a state of mind, in life as well as Linux.
That being said, I am testing an option in import that will let those who are security minded run a simple tool against their SCEs to list which packages contained in them have had updates since the SCE was imported, making use of the existing import structure. And it would be simple to allow a tool to automatically re-import any SCEs that have had updates. But I almost see it as foolish to re-import anything just because of upstream updates that have occurred when I don't even know if they apply to my situation. I am not focusing much time on this, the option to generate the needed info took less than an hour to make and test. But I knew the question of updates would come up. And an option to re-import everything will not be in it's initial conception, I don't want to promote that as a needed behavior.
What may materialize in the near future is a simple tool that will list each component of an SCE that has been updated in Debian, and then the user can review the below page to see if there is a vulnerability found that may apply to a package that they feel warrants keeping a close eye on updates, for instance if they were running an SSH server of critical importance.
http://www.debian.org/security/2013/
But to be honest I would rather attention be placed on finding bugs in imported packages or the dCore import tools. In this early stage, things may change quick enough that would require re-importing SCEs long before security concerns are justifiable.
-
- Jason W[/b]
Thanks for your detailed response.
My point is that I am sure most of the updates are not NEEDED for desktop use.
...for the typical desktop user, Linux or otherwise, by far your biggest security risk is related to behavior as in password habits and such.
A reasonable assessment. Whether or not the security upgrades are needed is not always apparent to a user with limited knowledge. In such a case the safer option is to install them.
...an option to re-import everything will not be in it's initial conception, I don't want to promote that as a needed behavior.
The idea was offered as I have an unmeasured feeling that many users of Debian stable simply accept all security upgrades as a matter of course via apt or synaptic. As the upgrades come from the stable repository this can be done without adversely affecting the system, which is not the case if using a non-stable Debian repo. As its is safe, although possibly uneeded behaviour on the part of the user, it would make dCore friendlier and familiar to them.
...the user can review the below page to see if there is a vulnerability found that may apply to a package that they feel warrants keeping a close eye on updates...
That assumes the user has sufficient expertise to interpret the information and the ramifications it has on the local system. While this may be fine for experts and enthusiasts, it may be less suitable for users who want to use their system rather than having to learn about the finer point of system management. After all that may be one of the reasons they were drawn towards the stable repo in the first place.
...I would rather attention be placed on finding bugs in imported packages or the dCore import tools.
Perfectly understandable. You are of course in the ideal position to judge where the time and effort is best directed to get dCore up and running.
-
There is a command to browse, find and install from the debian repository list, or you have to search from the site http://www.debian.org/distrib/packages ?
ok, I see the menu when I'm importing the file :)
-
Hi Jason W!
I just gave alpha3 a shot. It’s plain that it’s a work in progress. And yet, I was very impressed with the result!
From memory and a bit of script-exploring, I managed to type the commands to install elinks (import -b elinks; loadsce elinks). From there, I was able to find this topic and follow the directions of the first post: Xprogs+Xtc, then Xsetup.sh.
The only real difficulty I encountered was that X refused to start. That was due to Xorg not having the “s” bit set. I went into savage mode :D In /usr/bin, I removed everything linking to /tmp/tcloop/xorg-all, then copied the files over, and ran “sudo chmod +s *” Then X started (startx).
I found myself on an all-black desktop, found out that there was a mouse-click menu, from which I could open a terminal (Xterm), and thus launch wbar. I did not try everything, but I saw that the import icon failed to do anything (apart from a quick flicker of a terminal window, I think).
All in all, I tried only 2 imports: elinks, and xorg-all (using Xsetup.sh). I was at first a bit worried by all the many warnings, mostly about permission denied to create links. But in the end, elinks worked right from the first attempt! And Xorg too… mostly ;) And XOrg is quite a beast!
Very good job Jason W! Keep up like that!
I won’t be using dcore before probably at least a year: I wouldn’t know where to replicate all the nice customizations I did to my TinyCore (see signature). But I sure will keep an eye on the project :)
[edit: for your information, my sce directory with Xprogs, Xtc, elinks, and xorg-all, was about 115 MB in size]
-
You need a window manager installed. Some are fluxbox, openbox, icewm, flwm. Or xfce4 and lxde are available as larger desktops, I have even run gnome and kde on dCore.
The error messages you see are from startup scripts. They are almost purely cosmetic and in time they will be cleaned up more.
I have never seen the Xorg issue on any of my machines, but I will look into a "chmod +s" option to avoid this for others.
EDIT: "chmod +s" command added to startup script of xorg
-
If one runs Xsetup.sh, then flwm-topside.sce is downloaded and added to sceboot.lst. However, no matter which window manager one chooses, via import or prebuilt sce, you will need to specify it via the desktop bootcode, e.g., desktop=flwm_topside
-
Thanks Robert for pointing that out, I forgot that flwm_topside was loaded as part of Xsetup.sh. Maybe as part of each window manager or desktop environment package the startup script could contain " [ -s /etc/sysconfig/desktop ] || echo fluxbox > /etc/sysconfig/desktop " substituting fluxbox for whatever appropriate name. That way if the preferred DE or WM package is specified at boot, that would hold regardless of what is later imported and installed. And if no DE or WM is specified at boot, importing and loading one would just work but none would overwrite an existing /etc/sysconfig/desktop entry that is either set at boot or with a previously loaded WM/DE package.
-
I can't find anything that sets /etc/sysconfig/Xserver, so how do you get X to start at login?
I stuck something in bootlocal.sh to create it, but that doesn't seem right.
-
It will be fixed in next cut. As there is no Xvesa in dCore, .profile can be adjusted as follows.
[ ! -f /etc/sysconfig/Xserver ]
with
[ ! -f /usr/local/tce.installed/xorg ]
This will allow X to start upon login.
This change can be effected now in your .profile and backup will restore it.
Without the change just typing startx at the prompt works as expected
-
RE: desktop specification...
I left it to be user specified by boot code to be consistent. Otherwise every possible WM/DE that could be imported would have to have a local server startup script be created and merged during import's sce creation. Of course, it can be done. The question is the effort worth the result?
-
First, I tried dcore through virtualbox on fat32 flash stick with creation of a vmdk disk image (VBoxManage internalcommands createrawvmdk -filename ./gialla.vmdk -rawdisk /dev/sdc1).
I did start the distro through an iso (mounted as cd) and installed the packages in the tce directory inside the pen usb.
After I tried to run it directly on the pc.
Ok, after some testing:
1) I saw that during the import of packets in an error like this, also these are purely cosmetic?:
...
Connecting to ftp.us.debian.org (64.50.233.100:00)
libcairo2_1.12.2-3_1 100% |*******************************| 921k 0:00:00 ETA
Merging libcairo2: cpio: can't create symlink from usr/lib/i386-linux-gnu/libcairo.so.2 to libcairo.so.2.11200.2: Operation not permitted
2146 blocks
...
2)I am currently using unetbootin, is there any automated way to install dcore on flash memory or what procedure should I follow?
3)imported wbar seems not to work
4)imported firefox return this error:
tc@box:~$ firefox
XPCOMGlueLoad error for file /tmp/tcloop/firefox/usr/lib/firefox/libxul.so:
libdbus-glib-1.so.2: cannot open shared object file: No such file or directory
Couldn't load XPCOM.
5)Uxterm in flwm menu return this error:
UXterm da questo errore (xmessage)
uxterm tried unsuccessfully to use locale en_US.UTF-8 by setting $LANG to "en_US.UTF-8"
6) the wm clfswm seems not work
7) how I use wifi, I can not find the script wifi.sh, I have installed this packages:
firmware-atheros
wl-modules-3.8.10-tinycore
wireless-3.8.10-tinycore
wireless-tools
-
Hi vinnie
... Operation not permitted
Maybe a permission problem?
libdbus-glib-1.so.2: cannot open shared object file: No such file or directory
Looks like you are missing dbus-glib
-
@Vinnie
3)imported wbar seems not to work
NMI, after what procedure? Seems to be working fine here, Tested now on 4 different machines. All "real" x86 machines.
5)Uxterm in flwm menu return this error:
Unicode is not imported, nor has been tested. Use the non Unicode Xterm or import aterm, evilvte, or other.
6) the wm clfswm seems not work
Is is a freedesktop compliant WM? Otherwise would need Core interface scripts.
7) how I use wifi, I can not find the script wifi.sh
wifi.sce is just now posted and should be available via sce-fetch.sh
-
Uxterm works for me after doing what the message instructed.
Add 'export $LANG en_US.UTF-8' to your .profile.
-
Would like to try this. I like to get the MC files, boot, then load Xlibs, Xorg, jwm, opera.
So can I just replace core with dcore and then "install" those, using my 4.7 kernel?
Should I make a new tce dir, to keep from mixing tce and sce.
Would like to be able to boot both versions with my grub.
-
dCore uses the 'sce' directory in place of the 'optional' directory and 'sceboot.lst' instead of 'onboot.lst'.
Just make sure to specify a new 'mydata' backup file.
-
dbus-glib added to firefox's deps.
-
In regards to the WM startup scripts, flwm.sce and flwm_topside.sce already had a line echoing to /etc/sysconfig/desktop, flwm_topside had a test condition and flwm did not. I spent about 3 minutes adding the line with a test condition to the existing supported WM's and lxde and xfce4.
I just figured folks may like to boot dCore, import a window manager and xorg-all, load Xtc/Xprogs, and then be able to use X without having to reboot. It could also be one less potential cause for X not starting and the time spent troubleshooting that goes along with it, especially among newcomers. And since that line, albeit without a test condition, is in all the regular TC window manager and desktop extensions as well as the use of the boot code, I think being consistent across Core and dCore would only be of benefit.
Also, I have made use of the unicode and language support as well as uXterm by installing the locales-all package.
EDIT: for 5.x, we could consider removing that startup script code from Core and have both Core and dCore use only the boot specified option. That way the expected behavior is the same across Core and dCore.
-
RE clfswm:
I added the needed dep cl-asdf to clfswm's dependencies so it will start when clfswm is the chosen window manager. I did test and run it, it is very unfamiliar so I don't know if I was seeing full intended functionality minus the TC specific stuff.
-
- Can I squash files into an sce as with tcz?
- Can the tool install local .deb files? I have cedarview drivers from ubuntu that are not on debian.
- Can TC 4.7 load an sce? Or convert to tcz. Would be nice in the interim.
-
@rich
Maybe a permission problem?
I do not know
Looks like you are missing dbus-glib
If I load the distro without firefox, dbus is already installed.
I do not know which package dbus is the dependence, However, if I try to import dbus.sce generated separately, this is not possible:
tc@box:~$ loadsce dbus
dbus is already installedI think it's a control over programs (rather than packets) installed, dbus is in fact present in controlpanel -> stats -> installed
@roberts
NMI, after what procedure? Seems to be working fine here, Tested now on 4 different machines. All "real" x86 machines.
I just tried again (but with tcWbar) and this time it works. Perhaps it was due to the lack of the file xwbar.lst (or the necessity to restart the window manager?)
s is a freedesktop compliant WM? Otherwise would need Core interface scripts.
What is "Core interface scripts" ?
wifi.sce is just now posted and should be available via sce-fetch.sh
I'll try and let you know
@gerald_clark
Add 'export $LANG en_US.UTF-8' to your .profile.
$ echo"
export $LANG en_US.UTF-8
" >> ./.profileexit-->exit to prompt
$ exit
tc
$ startx
menu-->applications-->UXTerm:
Same error
I do something wrong?
@Jason W
dbus-glib added to firefox's deps.
I will try to re-import the sce
RE clfswm:
I added the needed dep cl-asdf to clfswm's dependencies so it will start when clfswm is the chosen window manager. I did test and run it, it is very unfamiliar so I don't know if I was seeing full intended functionality minus the TC specific stuff.This is the "Core interface scripts" mentioned by roberts? I'll try to re-import it
thanks to all
-
Oh, I meant to say clfswm has no Core interface scripts (menu, icon related) and it appears the design of it does not have a typical menu anyway so I don't think we will pursue adding interface scripts for clfswm.
-
@jason
firefox gives me the exact same error
Clfswm works fine, but when you do the import there are two homonyms indistinguishable, I downloaded the first and I've got it right.
Perhaps we should describe the packages list specifying whether the packet is deb version or core modified version.
@roberts
I can not put into operation wifi.sh, click on the image to see a picture of the error (sorry for the poor quality)
(http://i40.tinypic.com/dcznep_th.jpg) (http://oi40.tinypic.com/dcznep.jpg)
-
It would appear that you need to import wpasupplicant
-
Vinnie,
I too see two entries for clfswm, it appears that one is from the Debian package list and the other comes from the dependency file containing that name. There won't be custom packages that share the same name as a Debian package, so no need to specify as far as knowing if a Debian package name comes from Debian or is cutsom. But I see a simple code change to let the user know during import if a package being imported is a custom built one versus a TC created meta package versus a standard Debian one. It won't be listed in the package list to choose from as that would slow down performance, but it will be before answering the final "yes" before import does it's thing.
I will look into the firefox deps thing again.
-
@roberts
ok, wifi works great with wpasupplicant, this would be a package to add to the pre-generated sce?
@jason
In the meantime I also tried iceweasel and even it works.
tc@box:~$ iceweasel
sh: iceweasel: not found
tc@box:~$ firefox
/usr/bin/firefox: exec: line 6: iceweasel: not found
-
Iceweasel has always worked here. I will try again with flwm to make sure there is no dependency issue.
-
Iceweasel working fine here on x86 dCore with flwm_topside. I am posting from it now.
-
Vinnie - I added libdbus-glib-1-2 to Firefox's deps and now it is working with xorg-all, flwm_topside, Xtc, Xprogs, and firefox loaded.
-
[UPDATE] Toying around with dCore since yesterday and it still works like a charm!
One question: Can we unpack&modify the .sce extension as we could with the .tcz/.scm in TinyCore v4.6+?
This gives me an idea to strip my xorg-all.sce to only support 2 or 3 graphic chipsets...
_____________________________________
5:00am and I can't believe what I just read...
Congratulations guys! Another hit! ;D
-
dCore-5.0.alpha4 now available:
Changes for alpha2:
* Fixed bug in sce-fetch.sh, -i now works, added -b to add to sceboot.lst
* Fixed bug in isolinux.cfg on server to specify dCore.gz
* Added initial sceboot.lst to tce-setdrive.
Changes for alpha3:
* Fixed bug in tce-setup to quiet terminal output from startup scripts
Changes for alpha4:
* Added full path suport to loadsce. Patch via Gerald Clark
* Updates pretce, httplist and tftplist to work with loadsce instead of tce-load via Gerald Clark
* Add option to track md5sums to enable update checking of SCE components
* /usr/bin/ondemand: Remove unsupported tcz references.
* rc.shutdown changed references tcz to sce
* tcemirror.sh changed tcz to sce
* deb2sce: import -o fix
* .profile: added LANG=en_US.UTF8 to support default uxterm
* deb2sce: Now specifying to user during import whether package is standard, dCore meta, or dCore premade.
* Quieted an unneeded echo to output and prevented duplicate entries in the Select Package list
* tc-functions: launchApp support both /usr and /usr/local
Files can be found at:
http://www.tinycorelinux.net/5.x/x86/release_candidates/
-
@jason
ok firefox work! :)
Today I tried the alpha 4 and and you forgot to update the version number :P
-
Reuploaded dCore.gz and the alpha4 iso's to fix the version number.
-
Can dcore work as an arm CPU build?
-
Actually, dCore is an x86 port of the armv7 Allwinner core that uses import for it's packages. The import scripts are by design non arch specific so they can be ported to other arch's. And the external package data and startup scripts located in http://tinycorelinux.net/5.x/import/ is also arch agnostic supporting all existing Core ports that use import.
-
OK Jason
Without complicating things
I think the question should have been
Can the army-core allwinner 10 version of TCL "import" any app from the Debian repo?....and is it
currently possible to do that?
Thanks
Vi
-
Yes, it is mentioned in the Allwinner section of the forum as well, this thread in particular:
http://forum.tinycorelinux.net/index.php/topic,14130.0.html
-
Right Jason
So that potentially gives you a vast array of software tools for use on your allwiner device
It seems Worth Persuing as the best Linux for these devices then.........allwinner tablets
Thanks
V
-
ok, wifi works great with wpasupplicant, this would be a package to add to the pre-generated sce?
+1
-
i don't currently use wpasupplicant nor have means of testing it. But if someone can verify that an imported version works then I don't see why we can't host.
-
I tried to import wpasupplicant myself and it resulted in a 22 Mb large sce. That's huge compared with wpa_supplicant.tcz (268 Kb). Is really all those dependencies necessary with wireless_tools.sce and wireless-3.8.10-tinycore.sce loaded?
-
Not all of the dependencies, like libc6, will be needed to include in a premade sce. Openssl and some others are in the dep file of wpa_supplicant.tcz, so the total size is almost 2mb. We can trim a premade sce to be much smaller than the 22mb you are seeing.
-
premade wpasupplicant is very important because (for example) I would not have been able to connect if I had not previously used virtualbox to import wpasupplicant
-
I get some grey text during boot complaining something about zswap, is that normal?
-
A bit more precision/details might be helpful.
-
Sorry,I didn't look very closely the first time. This is the exact words.
Unable to find swap-space signature
swapon: /dev/zram0: Invalid argument
-
I get swapon: /dev/zram0: Invalid argument when booting the iso in Virtualbox aswell.
-
I've done some testing.
1. How do I change keymap? I can't make the xorg.conf I use on core work with dcore. I've tried to set the lang and kmap bootcodes and alsp changed LANG in .profile to sv_SE.UTF8.
2. I imported xarchiver and were able to open mydata.tgz with it but was unable to extract.
3. I miss flit and fluff.
Overall, dcore seems very promising. :)
-
To use locales, the locales-all package is needed, that should make it work.
I will look at Xarchiver.
We will see about getting flit and fluff.
Thanks!
-
Imported locales-all and added to sceboot.lst. Checked the spelling with locale -a and updated bootcode and .profile. Running locale everything seems ok, but I still have wrong keymap in both X and prompt. :(
-
10-keyboard.conf
Section "InputClass"
Identifier "Keyboard Defaults"
MatchIsKeyboard "on"
Option "XkbLayout" "es"
EndSection
------------------------------------------------------------------------------
.filetool.lst
opt
home
usr/share/X11/xorg.conf.d/10-keyboard.conf
-
Thanks Beroje!
Now I have the correct keyboard in X, but it's still wrong when I exit to prompt.
-
How do I install non-free packages like Flash and Acrobat Reader?
How do I make applications appear in the menu and on wbar?
-
opt
home
usr/share/X11/xorg.conf.d/10-keyboard.conf
usr/share/kmap/fi-latin1.kmap
#!/bin/sh
# put other system startup commands here
loadkmap < /usr/share/kmap/fi-latin1.kmap
-
Some more observations:
1. Only apps loaded at boot appears in the application meny and none (imported) is shown in wbar.
2. Imported libreoffice-gnome is unable to create new documents.
-
Which desktop or WM does not show menu when loaded on the fly? I will look into wbar.
I will import and test libreoffice-gnome and see what is going on.
Thanks.
-
I'm running xorg-intel with flwm_topside.
Gpicview and firefox has wbar icons but xarchiver, libreoffice, iceweasel, rox-filer does not.
-
Wireless is working fine when wireless-tools, wireless-3.8.10-tinycore, firmware-iwlwifi and wpasupplicant is loaded individually at boot but it does not when they are part of a mega-package.
-
It sounds like you have a permissions problem of your /home/tc directory, that would explain why you can't save a new file as user, and it also explains what you are seeing with wbar. Both are working fine here.
Do you mean you are putting the kernel modules into a big mega package with the others, one big sce file?
-
It sounds like you have a permissions problem of your /home/tc directory, that would explain why you can't save a new file as user, and it also explains what you are seeing with wbar. Both are working fine here.
I will test with non-persistent home.
Do you mean you are putting the kernel modules into a big mega package with the others, one big sce file?
Exactly.
-
I noticed that flwm_topside is only downloadable with fetchsce and not with import, making it impossible to include in a mega-package.
-
I redid some of my testing, now with persistent /opt and /tce but non-persistent /home. And no mega-packages.
My extlinux.conf:
LABEL dcore
KERNEL /tce/boot/dcore/vmlinuz
APPEND initrd=/tce/boot/dcore/dCore.gz quiet host=zepto tz=CET-1CEST,M3.5.0,M10.5.0/3 opt=sda6 tce=sda6 psmouse.proto=imps nodhcp
My sceboot.lst (no mega-packages):
wireless-tools
wireless-3.8.10-tinycore
firmware-iwlwifi
wpasupplicant
xorg-intel
wbar
flwm_topside
Xtc
Xprogs
Directly after boot I ran:
import -b libreoffice-gnome
loadsce libreoffice-gnome
Then I looked at my wbar, no libreoffice icon. But in the Application menu libreoffice had appeared. I started libreoffice from the application menu. I found that I still was unable to create new documents from the welcome screen. All buttons/links were greyed out except the ones labeled Open... and Templates... I then took a screenshot. I got the popup saying the screenshot was saved to my home. I checked my home directory, no screenshot found. Running screenshot.sh from prompt gave me the same result and an error: imlib2_grab: not found.
I then ran:
import -b firefox
loadsce firefox
I checked my wbar and no Firefox icon, it was present in the application menu though. By accident I then happened to right click my wbar. Wbar reloaded and the Firefox icon appeared (but still no libreoffice icon).
Now you should be able to reproduce some of my issues.
Regarding the inability to import flwm_topside, the same goes for Xtc and Xprogs.
Regards
Uggla
-
flwm_topside, Xprogs, and Xtc are not debian packages so, of course you cannot import them from debian wheezy repository. However sce packages are squashfs just like tcz, except sce tries to contain its dependencies. Therefore it is quite trivial to unpack using unsquahsfs the sce and cpio any other directories you wish to construct a mega package and repack with mksquashfs. Of course such meta packages are not required.
-
flwm_topside, Xprogs, and Xtc are not debian packages so, of course you cannot import them from debian wheezy repository. However sce packages are squashfs just like tcz, except sce tries to contain its dependencies. Therefore it is quite trivial to unpack using unsquahsfs the sce and cpio any other directories you wish to construct a mega package and repack with mksquashfs. Of course such meta packages are not required.
Then please tell me why it's possible to import some other non-debian packages like f ex wireless-3.8.10-tinycore, wireless-tools and firefox?
-
Apparently a data format that was intended for additional Core specific files to be merged with a debian package is now being used to offer full packages. Something needs to be worked out during this alpha phase.
-
We will plan to drop premade sces and sce-fetch in favor of allowing all access via import.
-
Great! :)