Porteus

Having PPM just download all the deps for v1.0 is a good idea. If this is the case i can polish it now, and have it ready in a day or two. At the moment i have added activation also, but not deactivation ... this will take a while as need to search for other modules that require anything being deactivated. Having activation iss good because user can activate after downloading. If they want to activate something else, it will know about dependencies that are already activated.

For gksu i was trying to think of how to see which window manager is active and only came up with using the process ID of startkde. I didn't think about second Xsessions. What about the /tmp/ksocket- which we could read display ID from, and then check which display we are in. Maybe we can leave this for after v1.0 too ... it is an extra 1.5Mb.

Ok, i will start rounding the PPM up now and release final shortly.

Posted after 1 minute 59 seconds:
I should also mention i have done nothing on 32bit since i started PPM. It may take a couple of days for me to go through bug reports and requests.

Posted after 1 hour 44 minutes 32 seconds:
OK Latest version is uploaded ... i have added activation of modules and this will do for version 1.

I have a few dependencies to upload to the server so thorough testing can begin. After that i will re-issue xzmteam with latest conversion scripts so they can start producing modules.

At the moment i still have a kdesu call at the beginning, so you'll have to test inside KDE. I wil wait to see if fanthom has enough space to implement gksu, if not i will remove the kdesu thing and stay with terminal switch to root function.

Sorry, I have already made ~50 modules for both architecture.

Do I need to convert them to proper porteus module with your script ?

"I should also mention i have done nothing on 32bit since i started PPM. It may take a couple of days for me to go through bug reports and requests."
i'm up to date with bugs/fixes/requests. Will send you all updates on Thursday so pls focus on PPM till then (need to fix avahi first).

gksu will require rewriting of all scripts... maybe for 1.1?

What about releasing unplanned rc3 for both arch on Friday/Saturday just to be sure that all is perfect? kernel 2.6.38.8 + PPM + latest fixes. one rule which can't be broken: no new features from rc3 to FINAL.
1.0 could be made a week after - let's say 17th of June. Ahau needs 1 week notice for updating docs.

not sure if "Porteus Settings Assistant" and netinstall could be ready on Friday so maybe it could be Sunday for rc3?
If you dont agree on rc3 then all will have to go with 1.0-FINAL 17-20th of June.

I started updating docs anyway, before you gave me official notice . I could probably get docs up to snuff in less time than that. Just need to know for sure which version of tweakUAC we're using, if sys/extlinux will be compiled as static, and I'm good to go. Big docs I would like to get out are porteus features (I have half of an ugly draft) and documentation for PPM, which I'll develop from within RC3 if you release it (personally, I recommend RC3, we've had a lot of changes in RC2's).

Sorry, I have already made ~50 modules for both architecture.
Yes all official modules need to be created using conversion script slackonverter.sh. This is the only way they will work with PPM.

gksu will require rewriting of all scripts... maybe for 1.1?
Yep ok, lets go with current method for now.

What about releasing unplanned rc3 for both arch on Friday/Saturday just to be sure that all is perfect?
It is a good idea. Final rc3 with no new features.

I thought I saw an option in slackonverter to use an existing xzm file. Would that option work to add the needed files to Hamza's modules, without the need to recreate them from scratch?

The existing .xzm function will work provided it already has the slackware base. /var/log/packages and var/log/scripts files in place. Previous to the rcX releases we were deleting the /var/log/scripts files, but after your modtools discovery we now keep those files.

Posted after 4 hours 20 minutes 7 seconds:
What i consider to be the final product is now on the server awaiting thorough testing. During the rc3 release stage i will begin populating the server with modules. This would be a good time to start getting stuff up there for the 64bit modules. Some minor tweaks will need to be made to the script for 64bit stuff.

Please give it a good thorough testing and report any bugs here. I have included a bug report function in the PPM just in case users want to report something. It will take them to the currently locked 'bug reports' thread depending on which $ARCH they are on.

Last thing for me to do now is add some icons, and perhaps remove the merge module function .... or leave it in place with a stern warning?

ok - i'll start producing modules after releasing rc3 when i get PPM updated for 64bits.

"remove the merge module function .... or leave it in place with a stern warning?"
people get used to have one module with all deps. let's go with warning first and see if deps are still conflicting (we could remove this function in 1.1 and perhaps drop it from modtools as well?)

please send me 64bit PPM when ready and i'll start preparation for rc3 in 64bit edition.

Cheers

Final version is up there. Just need to fix some text in merge function. I've added graphics and the main file is now an ELF 32-bit LSB executable.

I'm going to release this to the users for as sneak preview, and more thorough testing, and to see how it effects bandwidth on ponces server.