SliTaz SliTaz Forum

You are not logged in.

#1 2020-07-09 10:14:07

mistfire
Member
Registered: 2018-08-17
Posts: 168

Online Slitaz Next/Next64 Cooker: Too many failed cooks

I noticed that online Slitaz Next Cooker (http://cook.slitaz.org/next/) and Next64 Cooker (http://cook.slitaz.org/next64/) was on the move, I noticed that there are many failed cooks. When I checked the logs, the most common problem on the failed cooks are here are follows

1. Missing GTK+ package (The same problem as the rolling one which was fixed)

2. Missing linux source code (especially linux-drm)

3. Missing kernel components (Some packages receipt look for files on /lib/modules/[kernel version]/)

4. Missing aufs patch

5. It always shows this error message

[c]stat: can't read file system information for '[filename]': No such file or directory[/c]

Offline

#2 2020-07-11 10:31:18

mistfire
Member
Registered: 2018-08-17
Posts: 168

Re: Online Slitaz Next/Next64 Cooker: Too many failed cooks

When I checked the compile logs of GTK+ applications that failed to compile on both next and next64. libffi was missing upon compiling GTK+ applications

Offline

#3 2020-07-11 15:14:21

mojo
Administrator
Registered: 2011-03-29
Posts: 2,173

Re: Online Slitaz Next/Next64 Cooker: Too many failed cooks

Out of courtesy and consideration for other slitaz users a contributor with hg credentials should never commit a package update or change without successfully building and testing the updated package on their own computer.

In most cases a failed build removes the package from tazpkg database files.

While the old package still exists on the mirror, tazpkg shows nothing Available.

Offline

#4 2020-07-12 12:34:57

mistfire
Member
Registered: 2018-08-17
Posts: 168

Re: Online Slitaz Next/Next64 Cooker: Too many failed cooks

It seems no one ever tried to fix these next/next64 online cooker issues.

Offline

Registered users online in this topic: 0, guests: 1
[Bot] ClaudeBot

Board footer

Powered by FluxBB
Modified by Visman

[ Generated in 0.017 seconds, 7 queries executed - Memory usage: 1.53 MiB (Peak: 1.77 MiB) ]