I fixed issue for lib64 dir in slitaz-base-files and tazpkg.
Git and packages repo, both as up to date.
I fixed issue for lib64 dir in slitaz-base-files and tazpkg.
Git and packages repo, both as up to date.
@shann
Thanks.
slitaz-basevm.iso 2021-Mar-04 09:12:16 10.5M
root@slitaz:~# slitaz
SliTaz GNU/Linux ================================================================================ Release : cooking Architecture : x86_64 Kernel : 5.4.101-vm Machine type : x86_64 Home path : /home/slitaz Configs : /etc/slitaz Main config : /etc/slitaz/slitaz.conf Log files : /var/log/slitaz Packages DB : /var/lib/tazpkg Installed : 22 packages Mirror : http://people.slitaz.org/~shann/slitaz64-stuff/repo/packages/unstable/ System date : Fri Mar 5 05:21:52 UTC 2021 -------------- Boot options : initrd=/boot/rootfs.gz rw root=/dev/null BOOT_IMAGE=/boot/bzImage ================================================================================
Hi alanyih,
Notice for create env with my mirror ;)
tazdev gen-chroot {name_env} --mirror="http://people.slitaz.org/~shann/slitaz64-stuff/repo/packages/unstable/"
I'm curious.
Filou and shann seem to be doing a great job, but on separate ways.
1) are the packages from
https://c.web.de/@337942326598965997/QhaNFMiJQhuEqY3q66F8Xg
and
http://people.slitaz.org/~shann/slitaz64-stuff/repo/packages/unstable/
compatible? (Filou mentioned in a previous post that they were built using different libraries).
2) are you guys somehow coordinating your efforts toward the creation of a single, base x86_64 Slitaz version?
@shann
tazdev gen-chroot {name_env} --mirror="http://people.slitaz.org/~shann/slitaz64-stuff/repo/packages/unstable/"
Ref:
82 check_mirror() {
http://hg.slitaz.org/slitaz-dev-tools/file/3a966a7b4ac9/tazdev/tazdev#l82
20 # Main mirror to push and download (ISO, rootfs. etc).
21 MIRROR="mirror.slitaz.org"
22 MIRROR_PKGS="/var/www/slitaz/mirror/packages"
23 MIRROR_SOURCES="/var/www/slitaz/mirror/sources"
http://hg.slitaz.org/slitaz-dev-tools/file/3a966a7b4ac9/tazdev/tazdev.conf#l20
@sofia-m:
Your curiosity is perfectly right. shann and I had a couple of contacts through this forum a couple of weeks ago and I learned, that his first steps, on the basis of alanyih's previous work, went into the same direction, using LFS as a basis for further development.
As I have to admit, I didn't understand (and up to now don't) where any x86_64 version of SliTaz was / is developed, I started over with the latest LFS version in order to build a wok up to what you can download from my webspace (and I still to improve).
My intent was, when switching over to 64bit with what our / my very positive experience with Slitaz32 were, why change anything but the packages themselves, when we can keep all the principles and scripts? So I try to stick as close to Slitaz32, build the 64bit packages and slowly replacing the 32bit ones one by one, maybe patching some of the scripts, to achieve a working Slitaz64.
I also see that shann and alanyih proceed in parallel, but don't understand how to switch over to support their work and judging if I'd better put my efforts in their work or proceeding with mine.
@shann/alanyih: I see your conversation but lack the basis to understand it. Do you work on any already working 64bit basis? Should I / we cease to work on the "latest LFS wok / packages" and support you or should be proceed and later join the packages and experiences?
@Filou
Thanks a lot for your explanation. I think your your initiative is admirable.
Beside its practical value, it must have a great learning experience.
I was able to install many packages from your website, and they seem to work well.
On the other hand, I imagine that creating a distribution and, above all, maintain it up to date, requires so much work that coordinated help is always welcome.
I assume is just a matter of communication.
The next64 repo, for instance, is quite complete but a bit outdated. Also, as shann explained in a previous reply: "used 'old' toolchain GCC8, kernel 4.*."
It makes sense to have an x64 Slitaz built on up-to-date libs in a standardized way.
shann seems to have taken steps to create a x64 repo at: http://people.slitaz.org/~shann/slitaz64-stuff/repo/packages/unstable/
so, perhaps, that could be the place were to add newly created packages.
@shann
I didn't really understand this part:
"slitaz_x64 tarball doesn't have kernel because goal to can be used as this on any distribution."
Shouldn't a slitaz64 kernel be the base of the whole distro?
@shann
Okay, I think I got it now. You meant the slitaz_x64 tarball is meant to be used in a chroot from another Linux distribution.
I tried to install the slitaz-basevm.iso on the hard disk using the slitaz installer 'install iso' moede from a live system.
It worked well, apparently, but when I rebooted I discovered that it had installed basevm but with the live systems' kernel, which of course made the system unbootable. Weird.
@shann
I made a test, tried to install python3 from your repo on basevm
It worked well, you can see the output at:
Hi sofia-m,
Sorry for inconvenient, infact kernel i build is custom for vm, slitaz-basevm.iso goal to used as vm not on hardware and rootfs for chroot.
I check history of forum for curiosity, not parsed all topics :), but begin of work of x86_64 isn't new it's few 8 years ago, i find this topic "https://forum.slitaz.org/topic/64-bit-version"
~2013 pankso begin work on cross tools for ARM / x86_64 support, first step as build x86_64 kernel and continue use 32bits userland.
Of course, we need coordonate.
I suggest this guidelines :
- define toolchain used, need fixed and also improved.
- works on same wok, also synchronize with hg.slitaz.org/wok or wok-next
- use same dev env and slitaz tools (tazdev, cooker, ...)
- have cooker env (https://cook.slitaz.org)
- define milestones to split work, "base bootable" (aka slitaz base cli), justx, ...
In my case my wok use receipt v1, and not follow SliTaz 5.0 base files, based on slitaz 4.0/cooking.
I go to rework them with 5.0 and receipt v2.
I am open to all suggestions so that we define and build a common guideline.
@Filou, @alanyih, any member who wants to get involved.
@shann
Thanks for your answer, it's much clearer now. I didn't catch the 'vm' significance in the ISO's name :)
I think your guidelines make sense. Well defined goals and unified tools would speed up progress and optimize the effort.
As Filou pointed out in previous posts, Slitaz is a well thought-out distro, there is little need to change its structure, except for bringing it up to date and make it full x64.
Short update: just reached >900 x86_64 packages in my webspace, proceeded alphabetically up to py, will push on.
After the first iteration through to z, I'll concentrate on the necessary packages to finish a working wok, after that I'll try to further contribute the up to now failing packages...
@Filou
Congratulations!
980 of 980 Download
@Filou
980 of 980 Download
please check pkgdb
bandle.tar.lzma 03/08/21 92.3kb packages.info 02/13/21 41.3kb packages.list 02/13/21 0 Byte packages.md5 02/13/21 0 Byte $ tar tvf bundle.tar.lzma -rw-r--r-- root/root 783 2021-02-09 17:53 mirrors -rw-r--r-- root/root 4860 2021-02-09 17:53 extra.list -rw-r--r-- root/root 32 2021-02-09 17:53 files-list.md5 -rw-r--r-- root/root 1892 2021-02-09 17:53 packages.info -rw-r--r-- root/root 286552 2021-02-09 17:53 descriptions.txt -rw-r--r-- root/root 1646 2021-02-09 17:53 packages.desc -rw-r--r-- root/root 0 2021-02-09 17:53 packages.md5 -rw-r--r-- root/root 1076 2021-02-09 17:53 packages.txt -rw-r--r-- root/root 0 2021-02-09 17:53 packages.list -rw-r--r-- root/root 0 2021-02-09 17:53 packages.equiv $ cat packages.info | wc -l 14 $ tar tvf bundle-0213.tar.lzma -rw-r--r-- root/root 783 2021-02-13 21:27 mirrors -rw-r--r-- root/root 4860 2021-02-13 21:28 extra.list -rw-r--r-- root/root 32 2021-02-13 21:27 files-list.md5 -rw-r--r-- root/root 42338 2021-02-13 21:27 packages.info -rw-r--r-- root/root 286552 2021-02-13 21:27 descriptions.txt -rw-r--r-- root/root 35148 2021-02-13 21:27 packages.desc -rw-r--r-- root/root 0 2021-02-13 21:27 packages.md5 -rw-r--r-- root/root 25359 2021-02-13 21:27 packages.txt -rw-r--r-- root/root 0 2021-02-13 21:27 packages.list -rw-r--r-- root/root 228 2021-02-13 21:27 packages.equiv
@alanyih:
You're right, I always only upload the packages and don't update the absolutely old pkgdb (it's because I treat the webspace as a package collection rather than a repository...).
I'll try to update these files during the next update, too...
Thank you for the hint!
You must log in to post.