[SOLVED] Module creation - /var/log/scripts issue (?)

[Ahau]

I'm getting some strange behavior with a module that I'm trying to build, and I'm not sure if this is a bug or if there's something I'm leaving out of the module building process... I kind of think I'm neglecting something, so that's why I'm posting my question here instead of bug reports.

This issue is repeated in Porteus 09 64-bit and V1 alpha (both 32 and 64 versions)--haven't tested on v09 32 bit.

I am trying to build a module for GIMP. My process was to:
1. update slackyd (slackyd -u)
2. check for missing packages in the base system (slackyd -d)
3. download the gimp txz package (slackyd -g gimp)
4. convert gimp package to porteus module and activate it
5. check missing packages again (slackyd -d), and download packages that were added to the list since step no. 2
6. convert all dependencies (all libraries) to modules
7. activate all modules to test. Gimp worked successfully.
8. use porteus-module-tools to merge all modules together, to gimp-alldep.xzm

This module (gimp-alldep.xzm) will run gimp successfully if placed in /porteus/modules and injected at startup. If I leave it in /porteus/optional and activate it after startup, however, it gives me a missing dependency error. When I extract the module, I see that all of the required drivers are in place. And, they even show up in my live filesystem when I activate the module. But what is missing are links. Each of the original modules contained an install script, that gets placed in the module at /var/log/scripts. For example, the package aalib-1.4rc5-x86_64-3 puts in the following script:

Code: Select all

( cd usr/lib64 ; rm -rf libaa.so.1 )
( cd usr/lib64 ; ln -sf libaa.so.1.0.4 libaa.so.1 )
( cd usr/lib64 ; rm -rf libaa.so )
( cd usr/lib64 ; ln -sf libaa.so.1.0.4 libaa.so )

The links are properly installed if I have my "all deps" module in /porteus/modules, or if I do not merge the modules and activate them individually. The individual scripts do exist inside my merged module, so I'm clueless as to why this is occurring.

I'm looking forward to an "official module" HOWTO once we have a package manager

Thanks!

Posted after 2 hours 1 minute 26 seconds:
Should I be using installpkg -root /tmp/gimp on all of the txz's, and then dir2xzm? maybe that would create the links inside the module.

[brokenman]

Not sure what is causing this. It could be that you are unpacking on FAT32 and symbolic links are breaking. Could be that modtools is not using cp --preserve if it copies anything across which would break sym links too.

[Ahau]

Oh, that's true. I hadn't thought of that...I have been converting the modules and putting them on FAT32 before merging. I'll give it a shot keeping everything in the live filesystem. I have the txz's stored on FAT32, should I download fresh copies, or will links be preserved as long as I'm not extracting or converting them?

[fanthom]

"or will links be preserved as long as I'm not extracting or converting them?"
true, links are safe when stored in the tar archive.
Moreover, in case of slackware tgz/txz packages they are created by txz2xzm (installpgk in real) utility "on the fly" during conversion. have a look on some txz packages and /install/doinst.sh script for more info.

[Ahau]

thanks. When I was merging the modules, it used a /tmp folder that it placed inside the folder with all of the modules. All of that took place in my /porteus/optional folder, which is on a FAT32 device. So they were written to FAT before they got repackaged into the final .xzm.

Posted after 17 hours 8 minutes 46 seconds:
So, I tried this a few ways, all in my live filesystem (~/Desktop). If I convert the individual packages from txz to xzm and then use the "merge modules" function in porteus-module-tools, the links are copied and the module works when activated in an already running system. It also works if I use 'installpkg --root ~/Desktop/tmp' and then 'dir2xzm ~/Desktop/tmp ~/Desktop/gimp-alldeps.xzm'. However, it does not work (meaning, I get dependency errors) If I run the "merge txz2xzm to module" function. When I have more time, I will see if I can figure out what the problem is there.

Also, the module I created in 64-bit v09 seems to work great, but the one I built for 64-bit v1.0 beta will run, but doesn't display the gimp icon in the application menu when activated as guest (unless it is in /porteus/modules). When I log in as root and then activate it, it removes all of the application icons from my application menu...so I still have one minor bug to work out I did notice that my v09 files have one more package than my v1 files, so I must have missed one in the download (unless librsvg was installed by default in v1, but not in v09).

I also want to see what happens if I remove any libraries that I can find in the packages that are not specifically required for gimp, to see if I can trim the module size down a little. This is good practice for me

[fanthom]

@Ahau
"Also, the module I created in 64-bit v09 seems to work great, but the one I built for 64-bit v1.0 beta will run, but doesn't display the gimp icon in the application menu when activated as guest"
crap - sounds like another 'guest account' specific bug. please do an experiment for me: activate GIMP from guest account, then open console and run 'kbuildsycoca4' command (still as a guest). if that works then i'll try to incorporate one extra function to 'activate' script which runs 'kbuildsycoca4' with caller's privileges and not root ones.

"When I log in as root and then activate it, it removes all of the application icons from my application menu..."
Got that issue as well. KDE-4.6.x is damn buggy. if such kind of issues wont be fixed in 4.6.1 then i'll release 64bit Porteus-1.0 with 4.5.5.

(unless librsvg was installed by default in v1, but not in v09).
it is (even mentioned in the changelog )

[Ahau]

Thanks, fanthom...and sorry for not checking the changelog

I'll try the kbuildsycoca4 command this afternoon.

Posted after 6 hours 6 minutes 46 seconds:
running kbuildsycoca4 as guest, after activating GIMP actually breaks my app menu--it removes all icons, similar to activating the module when logged in as root. I may have just isolated the other issue

kbuildsycoca4 does not break my menu if I do not activate GIMP first.

If I activate GIMP, run sycoca (which breaks the menu) as guest, then run it again as root, I get:

'kbuildsycoca4(3425) KConfigGroup::readXdfListEntry: List entry MimeType in ".hidden/kommander.desktop" is not compliant with XDG standard (missing trailing semi colon).

I can also get a similar error to spit out for /usr/share/applications/leafpad.desktop if I go back to guest account and deactivate GIMP. mmm, this one is turning out to be more fun than I bargained for

Posted after 15 minutes 3 seconds:
sometimes I surprise myself--

I opened /usr/share/applications/leafpad.desktop. About two lines from the bottom is the line 'type=text/plain'. Other .desktop entries have a semicolon after that line, so I added one there (type=text/plain;) and saved. I activated GIMP, reran kbuildsycoca4, and all icons, incliding GIMP came back. I got off the bus before I could test more thoroughly, but will do so within the next day or so and report back.

[fanthom]

WOW - nice finding
if 'leafpad.desktop' really caused this issue then i'll be back in love with KDE-4.6.x.

Great job!

[Ahau]

Ugh, I spoke too soon. It DID work, but when I tried testing again, it did not. I don't get the mimetype errors anymore, but the icons still disappear when I run kbuildsycoca4. I'm going to keep playing with it.

Posted after 55 minutes 9 seconds:
Yeah, I cannot repeat whatever I did to make it work that one time. Adding a semicolon to leafpad.desktop stops the error message when running kbuildsycoca4, but nothing else changes.

A couple of things--
GIMP icon is not added to the menu when I activate the module in LXDE (as either guest or root).
update-desktop-database hangs if I try to run it while the GIMP module is active.

All issues go away if I add GIMP to /porteus/modules to have it injected at startup (it works in KDE, kbuildsycoca4 doesn't remove icons from the menu, and the icon shows up in LXDE). kbuildsycoca4 has no affect in LXDE, which I would imagine is due to it being a KDE specific tool--correct?

/usr/share/applnk/.hidden/kommander.desktop is missing a trailing semi-colon--also when I double click it, it doesn't find the application it is looking for (kommander?)--is this a dead link? Has kommander been removed?

Is anyone noticing similar issues with other modules? I just tried VLC from ponce's repository, and had the same problem.
32-bit alpha does not seem to have this issue.

Sorry I'm only asking questions here, and not answering any...

EDIT: I'm marking this thread solved because creating the module in a linux filesystem fixed my missing dependencies/symlink problems. moving the rest of the conversation to the thread about v1.0 alpha.