SliTaz Forum
You are not logged in.
[SOLVED] the upper panel has disappeared
Hi there,
The problem comes from libfm; downgrading libfm + libfm-extra + libfm-gtk to release 1.2.5 (from ISO 170930) solved the problem.
Offline
New problem:
xorg-server breaks X; have to go back to xorg-server 1.19.3
Offline
Hi Ceel,
Thank you for the reports.
I just want to tell you about SliTaz Next current state…
And it's currently broken. I know it, you can see it.
It will be cool. I know it too. And you will see it some day :-)
For some time I use information from the Repology to find outdated packages and to search a helping hand in the other Open Source distributions in the hard cases when only patches can help…
Currently I do what I can to do, and what I do well: I update the packages.
And I know that it is not enough to make a distribution.
There's a problems exists with C++ based packages like WebkitGtk and Qt4 and Qt5 and some other.
I think the problems are come from building environment, from toolchain, from GCC…
I think I should update the toolchain and I hope it will fix C++ based packages.
But, maybe you know it already, upgrading the toolchain require the total rebuilding.
I know it. It's unavoidable. But this task is great. It is very important. I just can not start. Procrastination… And I do all sorts of other things, putting off a big update for later.
Currently I make a "spring-cleaning" in the SliTaz Next repository. Just reformat the code without updates. I have not pushed yet, but great updates will come to the Cook Utils that will handle SliTaz architectures really better, finally providing packages with the "any" architecture ready both for i486 and x86_64 architectures supported by SliTaz Next. I develop the "badges" concept when all the packages are examined after the build is over and the system give some badges to the package signaling about some sort of the general problems to make packages better…
I do not know for sure, but I hope I will do the things in the next order:
First, I'll finish my "spring-cleaning" and will push it to the Mercurial with auto-build previously disabled on the cook.slitaz.org.
Then I'll finish better architecture support including TazPkg support (CookUtils support is almost 100% I believe). Will update the packages mirror (single mirror folder for both SliTaz Next and Next64 including [c]‹pkg›-i486.tazpkg[/c], [c]‹pkg›-x86_64.tazpkg[/c], and [c]‹pkg›-any.tazpkg[/c] packages that will save some space in the united packages repository) with two (i486 and x86_64) packages databases. Keeping Repology database support (I've made [c]repo.json.gz[/c] for both SliTaz Cooking and SliTaz Next describing the packages helping Repology to process SliTaz packages: see SliTaz Cooking and SliTaz Next pages).
Then I'll try to update the toolchain and will try it in action to build that problem C++ based packages. If all will be OK, then I'll push new toolchain to the Cook site and will start to rebuild all the packages.
When some certain packages will be built then I will have the great possibility to make a new ISO and to share it with you. I think, currently this task has no sense until the great updates are coming…
And now a couple of sentences about your suggests…
You suggest me to downgrade some packages. I can't believe it a right way. I trust the Repology, and I can see so many distributions use the latest libfm and xorg-server. Some extra work is required to make the packages to work together. It is the sense of the distribution :-)
As usually, I'm the worst time-manager on the Earth :-D and I can't say when I will move to the steps I describe. Anyway I sit here literally everyday and make my imagine distribution a bit better from day to day.
I know the task is great and very important. But I just can't…
Thanks for reading!
Offline
Exciting times ahead for NEXT
Aleksej, thanks for your time to push this forward.
I guess you will tell us when you need help?
Offline
Hi Erkan,
A bit more info about SliTaz Next for your blog.
The goal is to have new and updated software that cannot be build on the regular SliTaz Cooking.
It takes more time than expecting to revive it. First, I'm bad with my time-management. Second, I want that work brought pleasure. SliTaz Next made great steps forward but (after the short period about a year ago) is still not ready to use. Here I'll write my TODO like I see it today.
I want to update the toolchain. After this step the whole repository should be rebuilt. Also I have some improvements after which the total rebuilding is also required. So I'll provide the improvements first, then update the toolchain.
"SliTaz Next" and "SliTaz Next64" isn't two different repositories. The repository is single, but supporting two different architectures. Recipes catalogue (wok) is single. It would be logical to provide single web interface to the cooker, as well as single folder for the packages on the mirror server.
Some packages are architecture-independent, like icon themes, fonts, or native Python and Perl libraries. So let's keep the rule for the packages naming:
[*]librsvg-2.42.2-i486.tazpkg is for "i486" architecture
[*]librsvg-2.42.2-x86_64.tazpkg is for "x86_64" architecture
[*]librsvg-dev-2.42.2-any.tazpkg is architecture-independent
In the most cases *-dev packages are arch-independent (if static libs are not inside), so we can save some space on the mirror reusing "*-any" packages for both architectures. And it is true for aforementioned icons, fonts, some Python and Perl packages. And we can split out the common architecture-independent part to the separated package, like here: http://cook.slitaz.org/next/nano/files
I already have a working functional script to determine the package's arch automatically after the compiled files has been split into sub-packages. It require some improvements (I have not yet realized the fact that not only the files may be architecture-dependent, but the paths too! See, for example, here: .pm file stands for "Perl Module", is a arch-independent script, text. But we can't pack similar files as arch-independent package due to arch-dependent path.)
It would be great to have some another entity above the two cookers (Chef or chief-cooker ☺) that will process all the queried packages one by one for both architectures, in parallel or sequentially:
[*]pkg1-i486 (in the i486 build environment)
[*]pkg1-x86_64 (in the x86_64 build environment)
[*]pkg2-i486
[*]pkg2-x86_64
[*]...
If all the sub-packages are arch-independent (that we can mark with HOST_ARCH="any" in the receipt) it have sense to build it only in one build environment skipping it in other: result will be the same.
Currently tazpkg support is poor. It can only work with local cooker repository, and not trained to work with real remote repository (which isn't exists yet anyway).
Maintaining reliefs
Currently SliTaz Next web interface has some advantages over SliTaz Cooking one in the question of maintaining the packages. All the split packages in one place. As well as all the dependencies. All the files on the single page giving you information if you accidentally don't packed some files, or packed them twice. All files attributes also here, and wrong (or unusual) are red: (1) (2). But it will help you a bit when you need to review one-two hundreds of fresh built (for example, updated) packages. So I have a conception of post-build checks for many aspects (permissions, ownership and much more) that will give some "badges" to the package. These badges will be visible on the package's page, on the packages lists, and these badges will be search-able (like tags). You will find the problems on the first sight!
Little improvements
Such are not blocks the toolchain update, but here just for the record.
Advanced checking of the URLs (both home page and tarball). Sometimes projects moved from one web site to another, sometimes web site become HTTPS. In the most cases web servers send back the 301/302 and other HTTP codes to another locations, or 404/403/408 and other codes... To have actual and precise information is advantage. And Repology marks these "bad" cases as problems (not all the receipts was checked yet, updating in progress!), so we need to fix them.
Advanced helper. When you made brand new package, in most cases you'll find the dependencies. You found one, add it to receipt, start it, and it need some more. Repeat... It would be great to analyze common mistake messages and advice which package we need to add to BUILD_DEPENDS, or maybe it will be trained to add it automatically and to re-run the process! :-D
Advanced collision detector. Some different files with the similar path and name may be present in more that one package. It is bad situation. Don't ask me why. You know. But there's another, "advanced" problem that the different executables with the same name may be present in /bin/, /sbin/, /usr/bin/, /usr/sbin/, and... /usr/games/! To check these cases is to path to solve some odd problems.
Instead of conclusion
As always I have a lot of ideas, and a bit less free time and a will to implement them.
But I am stubborn :-D
Have a nice day!
Offline
[ Generated in 0.017 seconds, 7 queries executed - Memory usage: 1.55 MiB (Peak: 1.77 MiB) ]
