Core v7.0rc2

[Juanito]

Team Tiny Core is pleased to announce that Tiny Core 7.0 rc2 is available for public testing:

http://repo.tinycorelinux.net/7.x/x86/release_candidates/
http://repo.tinycorelinux.net/7.x/x86_64/release_candidates/

This is a release candidate. If you decide to help test, then please test carefully. We don't want anyone to lose data.

We appreciate testing and feedback.

If you use distribution files note that you need a new vmlinuz and core.gz (or rootfs.gz + modules.gz)

Changelog for 7.0 rc2:
* glibc patched for dns vunerability
* tc-config: use full path for hwclock, from Misalf

Changelog for 7.0 rc1:
* kernel updated to 4.2.9 with the latest stable patch, with these config changes:
  - minstrel enabled for some wireless cards
  - vmmouse disabled for VMWare + Xvesa
  - the cpu limit on the 64-bit kernel raised to 64
* busybox updated to 1.24.1
* busybox patched to fix "crontab -e" error
* glibc updated to 2.22
* gcc updated to 5.2.0
* e2fsprogs base libs/apps updated to 1.42.13
* util-linux base libs/apps updated to 2.27

Note:

* there is a drm/i915 kernel driver error pending a fix
* the alsa extensions have been refactored and updated
* the Xorg-7.7 extensions have been updated.
* there is a significant (+/-20mb) increase in CorePlus iso size due to an increase in firmware extension size
* most other extensions have been copied over from the 6.x repo

[andyj]

vsock.ko.gz is missing from the 64-bit core.gz. The companion module vmw_vsock_vmci_transport.ko.gz is there. Kind of a show stopper for open-vm-tools testing on 64-bit.

[coreplayer2]

There is a discrepancy in Apps when browsing corepure64 and x86 repo dep files



Local deps report correct module dependency "module-4.2.9" (shown in background), however when browsing the repo (shown in foreground) the deps indicate modules for previous kernel "module-4.2.7" yet the system variable KERNEL is used in all dep files

This anomaly occurs in at least these extensions:
also.tcz
cifs-utils.tcz
iptables.tcz


Also note: this is simply an indication issue within Apps, as the correct module is downloaded from repo when requested

[andyj]

In 7.x 64-bit repository libfreetype.so.6 and libharfbuzz.so.0 are mutually dependent (per ldd), which isn't the case in 7.x 32 bit. Why is this? I have a dependency tree walking script that went into a loop.

[curaga]

vsock.ko.gz is missing from the 64-bit core.gz. The companion module vmw_vsock_vmci_transport.ko.gz is there. Kind of a show stopper for open-vm-tools testing on 64-bit.

Code: [Select]

$ grep VSOCK config-4.2.9-tinycore*
config-4.2.9-tinycore:CONFIG_VSOCKETS=m
config-4.2.9-tinycore:CONFIG_VMWARE_VMCI_VSOCKETS=m
config-4.2.9-tinycore64:CONFIG_VSOCKETS=y
config-4.2.9-tinycore64:CONFIG_VMWARE_VMCI_VSOCKETS=m
It's built-in, seems.

@coreplayer2

The tree files are just for viewing, and they'll get refreshed via natural updates.

[andyj]

I'll need to have different startup scripts for 32 and 64 bit because of the differences in the kernel modules versus compiled in. I've also discovered that the dependency files will need to be different because the extension names are different (procps-ng <> procps, gtk2mm <> gtkmm-2.24) and the dependencies are different. gtkmm-2.24 is missing a dependency on gtk2 so I need to specify it explicitly (until it's fixed because I'm pointing it out now ) 

[Juanito]

In 7.x 64-bit repository libfreetype.so.6 and libharfbuzz.so.0 are mutually dependent (per ldd), which isn't the case in 7.x 32 bit. Why is this? I have a dependency tree walking script that went into a loop.

This has been the case in corepure64 since about tc-5.x.

It was done to see if the resultant fonts looked any better.

Note that this kind of circular dependency is not that uncommon (cf cyrus-sasl and ldap), but we cannot have circular deps in tinycore dep files.

[Juanito]

I've also discovered that the dependency files will need to be different because the extension names are different (procps-ng <> procps, gtk2mm <> gtkmm-2.24) and the dependencies are different. gtkmm-2.24 is missing a dependency on gtk2 so I need to specify it explicitly

I suspect procps-ng and procps are not the same thing?

As a general rule, we should name the extension gtk2mm (to make the difference between gtkmm for gtk2 and gtkmm for gtk3) and not gtkmm-2.24 - if only for the fact that we would have to change the name of the extension (and any deps that reference it) each time it is updated.

In addition to the missing a dep on gtk2,  the gtkmm-2.24 dep file should also be expressed recursively (it is not) for the sake of efficiency, smaller tree files, etc.

All this being said, we are still grateful for any and all extension submissions from tinycore users 

Edit: corrected gtkmm-2.24 and gtkmm-2.24-dev dep files in corepure64 5.x, 6.x and 7.x repos.

[andyj]

According to the 64-bit procps description, it is procps-ng. For open-vm-tools I don't think it matters anyway. The making of the recursive dep files for my upcoming extension submissions is how this began. I'm trying to automate the process as much as possible. I've updated my tree walking script to detect circular references so it can get out of it's otherwise infinite loop. I'm using ldd and following the libraries to their extensions instead of unwinding the .dep files, which is how I found that gtk2 wasn't being specified where it should have been. Generally I agree that minor numbers aren't needed or desired for extension names, but at least for database related extensions it's very important. There is usually a very tight relationship between the data files and the software version, which is why when I submit my postgresql extensions they will include all three version level numbers.

[Juanito]

Doesn't the existing postgresql extension work?

[andyj]

Unless it has been updated to support 128 character length object names (default it 64) then no. Also I'm testing 9.5.1, which is why I say that version numbers on database extensions matter. I don't see a 32 bit version in the repository, and I didn't have a 64 bit TC VM until a few days ago so I didn't even know it existed. There isn't a 64 bit PHP or apache in 6.x or 7.x either so unless I want to build those too I'm stuck in 32 bit land for now.