SliTaz Forum
You are not logged in.
I think it would look more professional ;^)
As long as it doesn't cause a future updating problem.
Offline
OK, issue now fixed. New package is at SliTaz Cooker.
Thank you, Richard.
Can you drive tazpkg-beta in different modes in a testing environment?
Offline
Thank you!
Sure, give me a link to fetch tazpkg-beta and I'll build it into my daily core iso.
Offline
Thank you so much.
Tazpkg-beta package is called "tazpkg-test" and can be downloaded from the Cooker site:
http://cook.slitaz.org/cooker.cgi?download=tazpkg-test-851.tazpkg
Offline
Hi Ceel,
I can't confirm bug with package removal with the [c]--root[/c] option.
I tested it in a bit different way.
[*]Install "gnumeric" in a testing non-existent folder [c]/tmp/1[/c]. Here used options:
[c]--root=/tmp/1[/c] to point tazpkg to new root;
[*][c]--nodeps[/c] to install only "gnumeric" without a thousand of other dependencies (faster testing);
[*][c]--debug[/c] to show debugging messages (they are sometimes unclear even for me :-D and fairly poor).
[c]# tazpkg -gi gnumeric --root=/tmp/1 --nodeps --debug[/c]
[*]Read the log:
[c]# cat /tmp/1/var/log/slitaz/tazpkg.log
2015-10-29 00:13:51 - Installed - gnumeric (1.10.17) - a09af18c077f77c75eb29018bef4076f[/c]
Looks logical.
[*]Remove "gnumeric" from testing folder:
[c]# tazpkg -r gnumeric --root=/tmp/1 --debug[/c]
[*]Read the log:
[c]# cat /tmp/1/var/log/slitaz/tazpkg.log
2015-10-29 00:13:51 - Installed - gnumeric (1.10.17) - a09af18c077f77c75eb29018bef4076f
2015-10-29 00:20:06 - Removed - gnumeric (1.10.17)[/c]
Looks good too.
[*]Read regular log:
[c]# tail -n6 /var/log/slitaz/tazpkg.log
2015-10-27 03:38:55 - Removed - cups-doc (2.0.2)
2015-10-27 03:38:58 - Removed - cups-filters (1.0.71)
2015-10-27 03:39:01 - Removed - docbook-xml (4.5)
2015-10-27 01:44:28 - Removed - glibc-locale (2.14.1)
2015-10-28 15:45:15 - Installed - dosbox (0.74) - e3ff8652797a01ed05f506f1578436b1
2015-10-28 15:45:41 - Removed - dosbox (0.74)[/c]
So... I can't imagine how to get this error.
________
Second take.
Previously I installed "gnumeric" to my regular system.
Then I installed it into "/tmp/1", and then removed it.
In the regular system I see no "gnumeric" deletion all these ways:
[*][c]tazpkg -a[/c]
[*][c]cat /var/log/slitaz/tazpkg.log[/c]
[*][c]tazpkg -l | grep gnumeric[/c]
[*][c]grep ^gnumeric /var/lib/tazpkg/installed.info[/c]
[*][c]ls /var/lib/tazpkg/installed/gnumeric[/c]
All here, and nothing was removed.
BTW I use the latest version of the "tazpkg-test" (while I developed it) and not update "tazpkg" package on my system.
Oh, maybe "tazpkg" package on your system has been updated and replaced the "tazpkg-test" files?.. Yes, it may be an answer.
Offline
Oooh yes, you're right again !
Aleksej 2 | Ceel 0
I remember now I left the installation with tazpkg-test to see if the warning message existed too with tazpkg.
Then I wrote the first post and then... I tested the root option but in the "bad" installation...
Sorry.
I hope you enjoyeded your cup of coffee at least ;-)
Offline
Hi Ceel!
It's okay, no need to make excuses. Here's my fault in the fact that one package overwrites files of another package. And tester needs to block original "tazpkg"…
Nevertheless, testing was stretched. Let's wait what mojo to say, and perhaps update the "tazpkg" to the latest version.
(Nevertheless I drink too much coffee :-D)
Offline
Hi Aleksej,
This is not a bug report, just a warning for those who have removed tazpkg and install tazpkg-test for... tests :-)
When tazpgk-test upgrades sliatz-config-base it re-installs tazpkg:
Tracking dependencies for package "slitaz-configs-base"
================================================================================
Missing package "tazpkg"
================================================================================
1 missing package to install.
Package "tazpkg-839" already in the cache
Checksum error for "tazpkg-839.tazpkg"
Recharging repository "Main"
================================================================================
Checking... [ Done ]
Database timestamp: 11/04/15 02:01
================================================================================
Repository "Main" is up to date.
Installation of package "tazpkg"
================================================================================
SliTaz packages manager
--------------------------------------------------------------------------------
Copying package... [ Done ]
Extracting package... [ Done ]
Remember modified packages... [ Done ]
Installing package... [ Done ]
Removing all tmp files... [ Done ]
Execute post-install commands... [ Done ]
Update system databases... [ Done ]
================================================================================
Package "tazpkg" (839) is installed.
Offline
Used: Rolling, 08. Nov.
Boot: Live CD Core-Live
In /var/lib/tazpkg/installed there are 249 packages but the 'My packages' list in TazPanel only displays 246: xorg-xsetroot, yad and zlib are missing at the bottom of the list.
Offline
P.S.:
I forgot to mention that 'tazpkg -l' from the terminal displays a list with 247 packages, with zlib included but xorg-xsetroot and yad still missing.
Offline
Hi Darjeeling,
Thank you for the reporting.
But, why do I have so different results with you? I write here using that ISO now.
[*]http://cook.slitaz.org/cookiso.cgi?distro=rolling-core
[c]Packages: 247[/c]
[*]PCManFM /var/lib/tazpkg/installed
[c]247 items[/c]
[*]tazpkg -l
[c]247 packages installed.[/c]
[*]
[c]tux@slitaz:~$ wc -l < /var/lib/tazpkg/installed.info
247[/c]
[*]TazPanel. "Packages > Summary":
[c]Installed packages: 247[/c]
[*]and packages list now. A bit tricky how to determine the number of displayed packages in the list. Go to "Packages > Administration", scroll to bottom, change "100" packages per page into "500". Click again "Packages > My packages". Click button "Toggle all".
[c]Selected packages: 246[/c]
Yes, last package in the list, "zlib" is lost. And it lost before, on the default "100 packages per page" settings.
And default Rolling Core ISO have no packages you listed: "xorg-xsetroot" and "yad". Do you installed them later? There are only similar "xorg-xset" and "yad-html".
I confirm that TazPanel shows not full list and missed the last entry in the list.
Thank you!
________
PS. Now I recharged TazPkg databases using TazPanel, and installed packages "xorg-xsetroot" and "yad". There "247" changed into "249" everywhere. But TazPanel "Packages > My packages" now ends with:
[c]xorg-xset
xorg-xsetroot
xterm
yad
yad-html[/c]
Last entry "zlib" is still missed (compared to output of "[c]tazpkg -l[/c]").
Then I updated all available updates (15 packages) and installed "tazpkg-test". A bit better in the TazPanel, but still "zlib" missed.
________
PPS. This issue fixed in the "tazpkg-test-859". I do not want to backport all the fixes back to the "tazpkg" package because I plan to remove "tazpkg-test" and to update "tazpkg" to the latest version from day to day.
Offline
Hi Aleksej,
Just saw on Hg your huge improvement to "remove" command. Very instructive reading!
Two suggestions:
- I think you can avoid the [c]printf "%s%s\n", root,...[/c] thing by using this: [c]xargs -I filename rm -f "$root"/filename < "$files2remove"[/c]
- you can avoid the [c]while [ -n "$dir" ];[/c] loop thanks to [c]rmdir -p[/c]
Offline
Hi Lucas,
Thank you!
I can use your first suggestion. Just I not well familiar with the "xargs" command 
But in the second suggestion I see no point. Loop here is to remove only empty sub-folders and folders.
Imagine, we have a large number of files in the "faenza-icon-theme":
[c]/usr/share/icons/Faenza/actions/16/add.png
/usr/share/icons/Faenza/actions/16/add-files-to-archive.png
...[/c]
We have [c]/var/lib/tazpkg/installed/faenza-icon-theme/files.list[/c] where all that files are listed. Note, the folders aren't listed here.
Then we removed all the files, but it's folders still here.
So we tried to remove [c]/usr/share/icons/Faenza/actions/16[/c].
It will error if it not empty (if for example, I put here my own file), and loop will break.
But in the normal case we will remove:
[c]/usr/share/icons/Faenza/actions/16[/c]
and then (because it now empty)
[c]/usr/share/icons/Faenza/actions[/c]
and
[c]/usr/share/icons/Faenza[/c]
and stop. We can't remove
[c]/usr/share/icons[/c]
because it contains some other folders.
Can you simplify the algorythm? Current works well as we normally have not very large number of the folders in the packages.
Offline
Many thanks to all who participated in the testing!
From now package "tazpkg-test" discontinued, and maybe used in the future to test some extremely updates.
On the other hand, package "tazpkg" updated to the latest current version (859).
And this tazpkg-859 now installed on our cooking bot http://cook.slitaz.org/ (I was afraid not to break it.)
All of your bug reports / feature requests you can write here as always.
Have a nice day! 
Offline
Thanks for investigating and for your reply, Aleksej. So, we've both been using this ISO ...
http://cook.slitaz.org/cookiso.cgi?distro=rolling-core
http://mirror1.slitaz.org/iso/rolling/slitaz-rolling.iso
... and yet, we get different numbers of installed packages? Weird. Except for our different keyboard settings, which don't require the installation of a package, the two live sessions should be identical. Is it possible that, depending on the found hardware, the boot procedure pulls in additional packages?
I will download a fresh copy of the ISO and test everything again thoroughly later this afternoon and let you know if there's any difference.
P.S.:
Are xorg-xsetroot and yad displayed in both, your TazPanel and your 'tazpkg -l' lists?
Offline
P.S.:
My last question was stupid as you had already answered this. I'm getting a new ISO now and check everything again.
Offline
No, my Rolling Core a bit different
http://mirror1.slitaz.org/iso/rolling/slitaz-rolling-core.iso
I preferring it because I don't need 4-in-1 feature provided by "slitaz-core.iso" (without "core" in the name).
OK, I'll test it now too, out of curiosity...
________
PS. No, 247 packages too, and no "xorg-xsetroot" and "yad" in the Core session.
These packages belongs only to "Gtkonly" session, but absent on a "higher layer" "Core".
Maybe you extracted four rootfs*.gz by hands and concatenated them to single rootfs.gz?
(I just run ISO using Grub4dos without any extractions from ISO.)
Offline
> Maybe you extracted four rootfs*.gz by hands and concatenated them to single rootfs.gz?
Nah, I didn't do this. I'm using a script that downloads and verifies the latest rolling ISO and then extracts a special justX ISO for my own experiments. I've been using this script for some time and it's been working well. The original ISO is not altered by the procedure. I have checked the md5 again earlier this afternoon and it was ok. So, here are the latest results of my investigation :-) ...
pcmanfm /var/lib/tazpkg/installed => 249
present: xorg-xsetroot
present: yad
present: zlib
tazpkg -l => 247
missing: xorg-xsetroot
missing: yad
present: zlib
wc -l < /var/lib/tazpkg/installed.info => 247
missing: xorg-xsetroot
missing: yad
present: zlib
TazPanel Summary => 247
TazPanel My packages (manually counted, 500 lines pp) => 246
missing: xorg-xsetroot
missing: yad
missing: zlib
I've also checked in /usr/bin and in /usr/lib and found that xorg-xsetroot, yad and zlib are definitely installed in the latest rolling ISO (08. Nov.). This means that at some stage /var/lib/tazpkg/installed.info hasn't been updated properly which is a corruption of the package database. The missing zlib in TazPanel is probably just a harmless bug in the page code.
Offline
Seems it will not working this way. I only can suggest you to tweak your script.
You may know it already that every rootfs*.gz has it's own packages database in the /var/lib/tazpkg.
"Graphical" rootfs has some different configuration files (now I writing from smartphone and can't recall) in the /usr/share/applications/ (something like "...default...").
If you unpack "base" flavor, then unpack "justx" over it, then "gtkonly" — all new files will overwrite it's old content, and any problem. No, really problems will appear if you'll unpack rootfs*.gz in a wrong order...
But I don't know how it works (but it works like a charm) that packages "yad" and "xorg-xsetroot" present only on the layer number 3. Next layer, number 4, Core, adds more packages, files, but these two packages not present on this layer. It works when you boot official ISO. But it not works if you (or your script) unpacking rootfs*.gz files.
Bug with missing last list entry I already fixed, you can update tazpkg manually from cook.slitaz.org or wait tomorrow (or maybe later, when this package will appear in mirror you use).
Offline
Thanks for your reply, Aleksej, but I think there's been a misunderstanding. In my previous post I was referring to the original, unaltered rolling ISO (08. Nov.) as it can be downloaded from the mirror. I only mentioned my own private justX extract because you had asked whether I might have been using such a self-made rootfs-gz for these tests. I haven't.
This is about the rolling ISO (08. Nov.) that's currently on the mirror ...
http://mirror1.slitaz.org/iso/rolling/slitaz-rolling.iso
... the packages xorg-xsetroot and yad are pre-installed on this ISO as can be seen in /var/lib/tazpkg/installed. The files of these two installed packages can be found in /usr/bin and in /usr/lib. The problem is that the index file /var/lib/tazpkg/installed.info doesn't match the package-db in /var/lib/tazpkg/installed ...
- 249 entries in /var/lib/tazpkg/installed
- 247 entries in /var/lib/tazpkg/installed.info
... because the entries for xorg-xsetroot and yad are missing in the index file. I think this is the reason why TazPanel and 'tazpkg -l' don't display the complete list of all installed packages. At some stage /var/lib/tazpkg/installed.info hasn't been updated properly which is a corruption of the package database.
Offline
Can you simplify the algorythm?
Not the algo which finds unique dirs, for sure. But the "remove empty parents" thing is implemented in rmdir:
[c]@@ -166,11 +166,7 @@
debug 'Removing folders...'
for dir2r in $(cat "$dirs2remove"); do
- dir="$dir2r"
- while [ -n "$dir" ]; do
- rmdir "$dir" 2>/dev/null || break
- dir="${dir%/*}"
- done
+ rmdir -p "$dir2r" 2>/dev/null
done
rm "$files2remove" "$dirs2remove"
unset IFS[/c]
Offline
Lucas,
I need to test it. Looks great.
Darjeeling,
Yeah, really misunderstanding 
Please, boot this original unaltered SliTaz Rolling ISO! Please, select different flavors: base, justx, gtkonly, core. Every time, please check the content of /var/lib/tazpkg (hint: it's 247 packages for Core, about 150 packages for Gtkonly, a very handful for Base, and so on). Please, check that Gtkonly has yad and xorg-xsetroot installed, but Core — haven't. In other hand, Core has installed yad-html package, tazweb, midori and other. Then you can return to your custom justx...
I think the best solution for you is prepare your own ISO with your flavor of choice.
Or, as option, you can boot your flavor of choice and then use one of the SliTaz tool: installer, tazlito, or just copy entire filesystem from inside booted flavor to your place. But please, understand that there are two differences: flavor you boot from Live CD and your custom extraction.
Offline
Hi Aleksej,
I confirm the bug seen by Darjeeling. In fact he stated his tweaks just to add confusion :-D. Let me state the bug clearly: "If you boot Live rolling at the "core" stage (not rolling-core), packages yad and xorg-xsetroot are installed but do not appear in installed.info."
Details of my procedure. I use my hard disk where grub is installed to boot this.
- download rolling ISO (not rolling-core)
- mount it, copy the 4 rootfs files into /boot
- copy grub4dos.exe into /boot
- add this entry to /boot/grub/menu.lst:
[c]title rolling via Grub4Dos
root (hd0,2)
kernel /boot/grub4dos.exe --config-file="root (hd0,2); kernel /boot/vmlinuz-3.2.71-slitaz root=/dev/null lang=fr kmap=fr-latin1; initrd /boot/rootfs4.gz /boot/rootfs3.gz /boot/rootfs2.gz /boot/rootfs1.gz"[/c]
Note, this is the correct order for initrd: strangely enough, rootfs4 is the first layer (base), rootfs1 is the last (core).
My guess is there is no mean to hide/remove files of a previous layer when you add one. So the core "stage" cannot have less packages than gtkonly. (It's only my guess based on using unionfs, I don't know at all how the initramfs is actually built, it probably doesn't use unionfs.)
Offline
Hi Lucas,
Thank you! It is clearly and simply written.
In fact, I thought that described behavior is related to non-official bootloader.
So the core "stage" cannot have less packages than gtkonly. (It's only my guess...)
I'll show you
A little background. I went through several steps to boot new SliTaz images.
At first, I unpacked the ISO, and joined four rootfs*.gz files into one by using the command cat. If I'm not mistaken, it was not yet released the slitaz-rolling-core.iso image, and the thing is, I did not know how to fit four rootfs*.gz files into my bootloader menu.list. In all my existing examples used only a single file. You know, it the wrong way. Not least because I was unpacking files in numerical order: 1, 2, 3, 4
Further, when the slitaz-rolling-core.iso image appeared on a regular basis, I began to use it. At the same time my menu.list looks like this:
[c]title SliTaz Rolling 150426
rootnoverify (hd0,6)
kernel (hd0,6)/rolling/bzImage rw root=/dev/null lang=ru_RU kmap=ru
initrd (hd0,6)/rolling/rootfs.gz[/c]
Here two files used: bzImage and rootfs.gz both just extracted from the ISO.
And this year I learned that I can just run ISO without unpacking. I have a netbook, CD drive is not here. I do not buy and do not burn discs for many years. But thanks to this method, I can run the ISO in a way that was originally intended ISO creators! I see menu from ISO, it's dark image on background, I can check memory using ISO menu entry, I can select the language from the language menu, I can edit commandline... This method works very well because SliTaz ISO is so small to fit in the my not-so-big 1GB RAM. So, the lines in the menu.lst is not very complicated, and they are like as follows:
[c]title SliTaz Rolling 151108 ISO
map --mem --heads=0 --sectors-per-track=0 (hd0,6)/rolling/slitaz-rolling.iso (hd32)
map --hook
chainloader (hd32)[/c]
Using this method you'll boot the «official way», as it intended by the SliTaz creators, as it written in the flavors. And you'll see all I tell about previously.
Thanks for your attention!
Offline
Hi Lucas,
It's me again. I implemented your code here: http://hg.slitaz.org/tazpkg/rev/b278bf56267b
Removing time decreased from 6 seconds to 3 seconds (on such big package as faenza-icon-theme is, and on my not-so-powerful hardware). Thank you!
Offline
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 1.61 MiB (Peak: 1.77 MiB) ]