[wpkg-users] [Bug 278] Wrong host match
http://bugzilla.wpkg.org/show_bug.cgi?id=278 --- Comment #3 from Stefan Pendl pendl2mega...@yahoo.de --- Rainer, how about the following match: ^\d\d*\.\d\d*\.\d\d*\.\d\d*$ So if the match pattern of the name attribute matches that pattern, then it is an IP, else it is a host name match. -- Stefan -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 278] Wrong host match
http://bugzilla.wpkg.org/show_bug.cgi?id=278 --- Comment #2 from Stefan Pendl pendl2mega...@yahoo.de --- Hi Rainer, yes, I have replaced the old name attribute with the new hostname attribute, so it is all good now. How about adding a deprecated message to the log file, if the old name attribute is used? Something like: The name attribute is deprecated in WPKG 1.3.0 and will be removed in WPKG x.x.x Use the new hostname and/or ip attribute instead. This will make users aware of it being dangerous and allow them to migrate to the new attributes. In my case three machines have had important software removed, but it could have been twenty too. -- Stefan -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 278] New: Wrong host match
http://bugzilla.wpkg.org/show_bug.cgi?id=278
Summary: Wrong host match
Product: WPKG
Version: other
Platform: PC
OS/Version: All
Status: NEW
Severity: critical
Priority: P2
Component: wpkg.js
AssignedTo: man...@wpkg.org
ReportedBy: pendl2mega...@yahoo.de
QAContact: wpkg-users@lists.wpkg.org
Hi Rainer,
I encountered a new wrong host match.
The log file contains:
2012-12-12 08:18:26, DEBUG : WPKG 1.3.0 starting...
2012-12-12 08:18:26, DEBUG : Reboot-Cmd is standard.
2012-12-12 08:18:26, DEBUG : Base directory is
'\\Haidlfs02\Software$\AppDeploy\WPKG Server'.
2012-12-12 08:18:26, DEBUG : Log level is 255
...
2012-12-12 08:18:27, DEBUG : Host operating system: microsoft windows xp
professional, , sp3, 5.1.2600
2012-12-12 08:18:28, DEBUG : Found network service:
{9577CC0B-2328-42D3-84F6-DD03882BFD98}
2012-12-12 08:18:28, DEBUG : Reading DHCP address.
2012-12-12 08:18:28, DEBUG : Found DHCP address: 129.0.40.169
2012-12-12 08:18:28, DEBUG : Domain Name: nussbach.haidlmair.at
2012-12-12 08:18:28, DEBUG : Found computer group: Domänencomputer
2012-12-12 08:18:28, DEBUG : Found user locale: 407
2012-12-12 08:18:28, DEBUG : Found system locale: 407
2012-12-12 08:18:28, DEBUG : Host properties:
hostname='kst3303'|architecture='x86'|os='microsoft windows xp professional, ,
sp3, 5.1.2600'|ipaddresses='129.0.40.169'|domain
name='nussbach.haidlmair.at'|groups='Domänencomputer'|lcid='407'|lcidOS='407'
2012-12-12 08:18:28, DEBUG : Found host
'MAIL00\|Haidl.*\|PPS2.*\|Optis01\|DMS.+\|vCenter\|MATRIX01' matching IP
'129.0.40.169'
Notice the last line, which matches host names against an IP.
I have reported a similar issue a while back, which got resolved, seems some
latest changes removed that correction.
I will now convert the old host attributes to the new hostname attribute to
avoid this in the future.
--
Stefan
--
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug.-
wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 277] New: createSettings can cause crash if not all values could be detected
http://bugzilla.wpkg.org/show_bug.cgi?id=277
Summary: createSettings can cause crash if not all values could
be detected
Product: WPKG
Version: other
Platform: PC
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: wpkg.js
AssignedTo: man...@wpkg.org
ReportedBy: john.spack...@zenesis.com
QAContact: wpkg-users@lists.wpkg.org
On line 2033 of wpkg.js (v1.3.0) attributes are copied into newSettings
regardless of whether they are null or null - but null values cause the script
to crash saying this:
Message: Type mismatch
Description: Type mismatch
Error number: 800a000d
Stack:undefined
Line: undefined
We have several Windows XP Embedded boxes on which some of the detection
routines in wpkg fail - for example, we get these messages:
Error when searching registry sub-keys at 'HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\NetworkCards\'
Code: 800a01ad; Descriptions: Automation server can't create object
Message: Unable to get domain information.
Message: Unable to get domain information.
Message: Unable to fetch computer membership groups. Probably not a domain
member.
The errors all seem to have no lasting effect except that createSettings later
crashes. The fix is easy:
function createSettings() {
var newSettings = createXml(wpkg:wpkg, namespaceSettings);
if (settingsHostInfo) {
// Add host attributes.
// NOTE: These attributes are currently not used by WPKG but might be
// useful if wpkg.xml is copied to an external system so wpkg.xml
// will include some host information.
var hostInformation = getHostInformation();
var attributes = hostInformation.keys().toArray();
for (var i=0; iattributes.length; i++) {
var value = hostInformation.Item(attributes[i]);
if (value) {
newSettings.setAttribute(attributes[i], value);
}
}
}
return newSettings;
}
--
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug.
-
wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 276] pre-download tag
http://bugzilla.wpkg.org/show_bug.cgi?id=276 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|NEW |RESOLVED CC||r.me...@wpkg.org Resolution||WONTFIX --- Comment #1 from Rainer Meier r.me...@wpkg.org --- Hi Rob, I thought about this for a while and came to the conclusion that this request insn't helpful to provide stable and reliable software deployment. I am going to explain in a bit more detail. First of all WPKG can't just look for such outstanding commands which need to be run before. Implementing this would require to run these commands in parallel thread (which is not supported in WSH) and moreover to keep track of execution of each single command (which also might have dependencies between each other). As a result your package install commands will anyway have to wait for the completion of these commands before the package commands itself can run and install the package. Even worse such detached tasks would require detailed additional checks to verify if they completed properly in background or if they have been interrupted (process termination, timeouts, reboot, shutdown...). So in any case the package won't be able to install before your pre-run commands actually finished doing its task. Moreover if you really want to decouple download from installing, then you can actually do already using current WPKG implementation. Here's some suggestion how you could do it: First create a command which is handling the download. This command could run detached download process. For example use: command type=install cmd=\\path\to\download-script.cmd / Within the script use something like @echo off start %dp0detached-download-job.cmd Note that start does not use the /wait argument, so it's running the job in detached mode, not waiting for its termination. And detached-download-job.cmd containing something like: @echo off if exist %TEMP%\download-target\setup.exe goto skipDownload robocopy . echo complete %TEMP%\download-target\done :skipDownload So detached-download-job.cmd will run in background without WPKG waiting for it since download-script.cmd will terminate immediately. Of course now the download is not finished when WPKG start the next command: command type=install cmd=\\path\to\silentInstaller.cmd / While silentInstaller.cmd just contains some lines like: @echo off if exist %TEMP%\download-target\complete ( echo Found downloaded installer start /wait Installer %TEMP%\download-target\setup.exe /silentSwitch ) else ( echo Download not available, maybe not finished yet exit /b 1 ) So of course the WPKG will report the package as being failed to install on first run since silentInstaller.cmd will return exit code 1 immediately. But this is exactly what we want to achieve here. The package will have to wait for the download to finish before it can install. And it's also correct in terms of WPKG package database maintenance since the package won't be inserted to local wpkg.xml until it's fully installed. So the package will perhaps be applied next time WPKG is run. If the download in previous run completed corretly it will make detached-download-job.cmd not performing any action and the second command (silentInstaller.cmd) starting the actual installation. These 2 commands now entirely make sure the download is completely detached from install. It just needs (at least) two WPKG runs to complete installation. There is nothing wrong in allowing WPKG to fail on purpose while installing the package. You could also slightly modify the approach and start silent install in detached process (right after robocopy completes in detached cmd script). This would perhaps allow early-installation of the software. WPKG will still fail on first run since obviously installation is not done yet. But on next run it will succeed if your checks properly check for correctly installed software. In this case you basically just need one single command: command type=install cmd=\\path\to\download-script.cmd / Within the script use something like @echo off if exist %ProgramFiles%\application\application.exe goto skipInstall start %dp0detached-download-job.cmd :skipInstall And detached-download-job.cmd containing something like @echo off if exist %TEMP%\download-target\setup.exe goto skipDownload robocopy . :skipDownload start /wait install %TEMP%\download-target\setup.exe /silentSwitch In this script set WPKG will initiate detached wonload/install process on each run. If it completes successfully, then on next WPKG run the command just terminates (exit code 0) and WPKG then verifies (using its checks) that the software is applied correctly. As a result on first run WPKG will report an install error (which is exactly what we want since the application IS
[wpkg-users] [Bug 276] New: pre-download tag
http://bugzilla.wpkg.org/show_bug.cgi?id=276 Summary: pre-download tag Product: WPKG Version: other Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: wpkg.js AssignedTo: man...@wpkg.org ReportedBy: rbos-w...@novylen.net QAContact: wpkg-users@lists.wpkg.org It would be helpful, for very large packages, if I could specify commands that take place BEFORE the package install commands are executed, and can safely time out without generating an error, and can run in a forked background process. For instance, copying Creative Suite from the central server with robocopy can easily take over an hour if a couple hundred computers try to do it simultaneously, and hit the timeout. A preinstall cmd='robocopy blah blah' / could be forked off WPKG and deferred until the next run. If, on the next run, the preinstall commands have succeeded, then the install lines can run. Alternatively, WPKG could look for any preinstall lines in outstanding packages, execute them as background tasks, and allow them to run in the background while available install lines run sequentially, then run the particular packages' install as preinstall routines complete. It would be especially helpful in situations where WPKG runs on startup. Any long downloading operation can extend the run time unreasonably. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 275] New: Bullet-proofing log files.
http://bugzilla.wpkg.org/show_bug.cgi?id=275 Summary: Bullet-proofing log files. Product: WPKG Version: other Platform: PC OS/Version: All Status: NEW Severity: trivial Priority: P2 Component: wpkg.js AssignedTo: man...@wpkg.org ReportedBy: k.e.jo...@brighton.ac.uk QAContact: wpkg-users@lists.wpkg.org WPKG makes a great job of handling log file output but some days people do stupid things and can kill it quite easily ;-) I added a package that installed updated network drivers. As you can imagine, at some point during their installation the network was dropped and when WPKG tried to write to the logfile that I'd redirected to a server share it just crashed and burned. The error wasn't bubbled through to error handlers so I'm guessing I need to dig a bit further. In the interrim, might I suggest that logfile writes get wrapped with a try/catch just in case something happens out of the normal context of wpkg's actions and error reporting model? As Confuscious says, happens life goes on... and so should WPKG :-) Keith -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 273] Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273 --- Comment #18 from Keith Jones k.e.jo...@brighton.ac.uk --- Hi, Sorry. RL intervened so I haven't yet done any coding to try and help out. I did notice some caveats that are edge-case problems and need documentation and thought. I haven't written them down properly yet, so please accept this as work-in-progress and vague I've-got-ten-minutes-spare update. If you dedicate an instance of WPKG to a per-user install with the advice given, you have to be wary that the name matching process is still key to how WPKG works. I had a simple hosts file for my second user instance; host environment=USERNAME=^MyUser$ profile-id=blah / host environment=USERNAME=^MyUser2$ profile-id=blah2 / That worked... but because the name matching is a separate system you get some wierd effects. If no match is made you get an error and wpkg.js exits with an installation failure rather than the no match exit path that you'd expect. That, in turn, means that you can't do some of the basic moves such as commenting out a host element in hosts.xml and having WPKG remove software because a system doesn't match a host. I think that's pretty obviously because all the flow control is centred around around the name matching process and the extended matching is still an add-on. I haven't had time to test Stefan's use of condition or how adding a wildcard value for the name attribute works. I'm pretty confident they'd work well but I'm still thinking it's worth considering treating the name attribute just like all the new extented attributes. I think the name attribute can be refactored as another attribute (albeit a rather special one) and all the workflow from the name macthing process could be factored into the attribute macthing process,. I'll work on some coding examples when I get the chance (RL is not playing fair at the moment). It's a big leap but refactoring has a lot of potential. Keith -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 273] Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273 --- Comment #17 from Keith Jones k.e.jo...@brighton.ac.uk --- Hi, I did start to do some coding on Wednesday. Unfortunately, I only had a short time avaialable and the awkward thing was that I ran into some issues in testing out Stefan's suggestions. I'll bug them tomorrow. They don't affect the usual behaviour of WPKG but they illustrate that attribute matching might need to be integrated on a different level. Keith -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 274] New: WPKG still installs packages of previous profile after pc name renaming.
http://bugzilla.wpkg.org/show_bug.cgi?id=274 Summary: WPKG still installs packages of previous profile after pc name renaming. Product: WPKG Version: other Platform: PC OS/Version: All Status: NEW Severity: minor Priority: P2 Component: wpkg.js AssignedTo: man...@wpkg.org ReportedBy: sash...@ukr.net QAContact: wpkg-users@lists.wpkg.org I had a pc with name '02-109-89'. WPKG used 'profile-1' profile. But later, I renamed pc to '02-106-89' name and manualy removed all unnecessary software. With new name applied new profile 'profile-2'. But after rebooting I see wpkg still installs packages from previous profile. In log file I see it uses new profile 'profile-2'. But why then it installs packages of 'profile-1' profile? WPKG 1.3.14 -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 274] WPKG still installs packages of previous profile after pc name renaming.
http://bugzilla.wpkg.org/show_bug.cgi?id=274 --- Comment #1 from Kalyniak Oleksandr sash...@ukr.net --- I'm sorry, I mean WPKG 1.3.1-RC11 -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 274] WPKG still installs packages of previous profile after pc name renaming.
http://bugzilla.wpkg.org/show_bug.cgi?id=274 Stefan Pendl pendl2mega...@yahoo.de changed: What|Removed |Added CC||pendl2mega...@yahoo.de --- Comment #2 from Stefan Pendl pendl2mega...@yahoo.de --- Never remove software under WPKG control manually. If you do this, WPKG will check that the software to remove isn't installed properly, so it will be installed again before it will be finally removed. If a system is moving from one profile to another, run WPKG manually to apply the profiles changes. If you use WPKG, let WPKG do the work. If you like to do things manually, don't use WPKG. -- Stefan -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 274] WPKG still installs packages of previous profile after pc name renaming.
http://bugzilla.wpkg.org/show_bug.cgi?id=274 --- Comment #3 from Kalyniak Oleksandr sash...@ukr.net --- (In reply to comment #2) Never remove software under WPKG control manually. If you do this, WPKG will check that the software to remove isn't installed properly, so it will be installed again before it will be finally removed. If a system is moving from one profile to another, run WPKG manually to apply the profiles changes. If you use WPKG, let WPKG do the work. If you like to do things manually, don't use WPKG. -- Stefan So! What I need to do now? -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 274] WPKG still installs packages of previous profile after pc name renaming.
http://bugzilla.wpkg.org/show_bug.cgi?id=274 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|NEW |RESOLVED CC||r.me...@wpkg.org Resolution||INVALID --- Comment #4 from Rainer Meier r.me...@wpkg.org --- (In reply to comment #3) So! What I need to do now? In general you wont't have to do anything. Just accept that WPKG will first verify all packages before doing any action. Therefore WPKG will (in your case) first make sure that the packages listed in wpkg.xml (here, still the packages of profile-1 are listed) are applied correctly. This is the only way to assure for WPKG that it is in defined state. Then WPKG will automatically start to remove software. If WPKG would not check whether a specified software is installed, then very likely the software removal will fail as well which would make WPKG believe that the software could not have been uninstalled properly. So assuming you have package-1 listed in profile-1 but not in profile-2 then you're supposed just to switch the profile. WPKG will then on next run verify that package-1 is still installed properly if it's listed to be installed in local wpkg.xml database. And then as a next step it will remove it. So no manual action is required. If you want to do things manually, then uninstall package-1 and also remove its DB entry from the local wpkg.xml database. So WPKG will not try to remove it again (which includes first to verify that it is properly installed, see above). So it's not a bug that if you uninstalled package-1 manually then WPKG does not know about it and according to local wpkg.xml it's supposed to be installed. Therefore WPKG first tries to re-establish a defined state by re-installing package-1 before finally removing it (in one step). If your packages are well-defined and install/remove works properly, then this is not an issue and in both cases you will end up with package-1 removed properly. As Stefan already said: It's recommended either to manage software manually or using WPKG, but you should not mess manually with software installed by WPKG. Actually this functionality can be partially disabled by the noUpgradeBeforeRemove switch (command line or config.xml). When disabled, then WPKG will not make sure that a package is properly installed (and upgraded to latest version) before the removal takes place. Please keep in mind that in your case this would very likely yield errors since you have removed the package manually. So WPKG thinks it's still installed, then tries to remove it by launching remove commands. These remove commands would likely fail since the software is not installed any more. Failing remove commands typically yield non-zero exit code and therefore WPKG would report an error on removal. So very likely the approach of WPKG to re-install it and then remove it properly is better also in your case. So the bottom line is that this is exactly the intended behavior of WPKG and therefore not a bug. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 273] Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273 --- Comment #13 from Keith Jones k.e.jo...@brighton.ac.uk --- (In reply to comment #11) Hi Keith, I will have to go through all these comments in a bit more detail. But currently the summary to me really looks as follows: No matter if a context switch for user|machine would be implemented you would be strongly advised to set up an independent instance of WPKG with an independent package/profile/configuration structure due to a couple of reasons: - access permissions to the user-space WPKG shares and definitions are likely different from access-rights to the software repository - WPKG in user-mode should also allow configure where wpkg.xml is stored and how it's named, so an independent config.xml should be used - Also logging configuration would require some adaptation in config.xml - Defining user-space and machine-space packages in one single WPKG database (packages.xml) would technically be possible but I would strongly recommend to separate it As already pointed out by Stefan you could set up a WPKG instance to perfectly work with username-based profile assignment using conditional host/profile definition. Matching by environment variable USERNAME perfectly works from within WPKG and would allow you to do the same as I have outlined it using the /host:%USERNAME% launch switch. So if you don't like command-line switches, then just filter in code which means using conditional expressions. As said above I would really strongly recommend to keep user-space packages defined in an independent instance of WPKG and not mix machine and user packages in packages.xml. If you're running an independent instance you will also have independent config.xml files (one for machine-instance another for user-instance on a different share). In each config.xml you can define the name and location of the local wpkg.xml differently. You have also asked whether a missing hostname conditional attribute equals to hostname=* somehow. Actually WPKG only filters for values which are existing. So if you omit the hostname attribute, then WPKG will not filter for it. Therefore you're right, if you omit hostname, then this means the condition does not depend on hostname at all. WPKG internally just matches all the attributes in the condition and if one of them does not match, then it entirely ignores the statement in which the condition appears. So if you add a condition to a host definition and one of the conditions do not match, then for WPKG it looks internally like this host definition is not in the file at all (removed from internal structures before processing). So for me still it feels like you can easily use the full power of WPKG in user-space even without any change. The only two items where I see improvement are: - Scanning of HKCU uninstall keys - Query group membership of executing user rather than machine The first one could be enabled/disabled by a config.xml switch. Or (more preferrable to me) not even introducing a switch and just scan this key in addition to machine uninstall keys. WPKG implements some new caching mechanisms for uninstall keys which might not have a big impact any more. Alternatively you can use simple registry checks already right now. The second one will have to be evaluated. I would like not to mix the current group matching (machine group matching) and a user matching. Maybe a simple additional conditional-check attribute like usergroup could match for user groups rather than machine groups. So one could even combine user and machine group membership filters. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 273] Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273 --- Comment #5 from Keith Jones k.e.jo...@brighton.ac.uk --- Hi Rainer, Thanks for responding with such depth. I do appreciate the attention you're giving to this idea. (In reply to comment #3) I know :-) ...but from my lazy point of view, a switch and a bit of extra code could do all those changes for me in a consistent documented way ;-) And especially the documentation is one of the items I would be afraid of. It would be hard to explain why WPKG uses username as hostname when the /context:user switch is used. But if the user on purpose adds /host:%USERNAME% then it's clear that he just want to enforce WPKG to use the username as host name string. I mean it's not hidden in some program code but obviously stated at the command line. Yes. I think documentation could be an issue. I would have thought that WPKG appeals to people with some experience in the field though. At least, I would hope they would have enough experience to separate the idea of running a script at per-machine level (startup) as opposed to per-user level (login). (Not that there is too much difference in reality). I think it could be explained well though. It could still be listed as Experimental in the current RC. I can have a stab at the documentation if you like. In general I am very concerned about such a change introducing issues and pretty obscure concepts for a use-case where WPKG was not intended to be used. To state it clearly, WPKG from my point of view is a tool for system administrators to maintain system-wide settings. There are other mechanisms like policies, ActiveSetup, Logon-Scripts etc. which are designed to target enforcing user settings. Hrmmm.. I probably don't see it as obscure. At least one other person doesn't anyway ;-) IMHO, it fleshes out WPKG to be an all-round deployment system. One one hand it's a powerful, reliable tool for administering system-wide settings but it's also a very well engineered and thought out job management system. I am very conscious that it's not a task that it was originally intended for but, the functionality is so close in nature that it feels like it's just a simple step away. There are many ways to achieve the same effect (as you mention) but from personal experience they're flawed, limited and rarely as easy to work with as WPKG (Certainly not as integrated or centralised). I use GPO's to hand out policies, preferences, shortcuts and files but it does get complex handling those settings in the precise way that WPKG does. It usually ends up with some careful and complex layering of policies and some rather interesting uses of permissions and filters to stop GPO's being applied when my AD structure is more logical than my users are :-) As for login scripts, well, that's exactly where I see WPKG making an important impact for myself (and many others I hope!). Our central IT support team don't support roaming profiles. Every user login has things prepared by a rather dauntingly long logon script. The script is full of checks for ABC file being present, DEF user being logged in, GHI machine being the machine they logged in on and then does something because of it. It's a huge amount of wasted coding time when WPKG already has that built-in in simple definitions. When I throw in ExecuteOnce, reboot control etc, it just becomes a cool repalcement for logon scripts. Obviously WPKG can also be used in such environment already using special configuration. But honestly I don't feel like we should document and support this use case officially as it's clearly very limited use-case and requires extremely careful package definition and WPKG configuration to work properly. True. and I've got a test setup going out tomorrow based on your suggestions. It's actually going to very successful I hope. I think there's a potential case here, I'm hoping there'll be some comments from the list at least :-) As you say, it can all be done with different config file settings and different instances of WPKG. Having WPKG do it for me though... well, it'd be another magical moment where WPKG saves the day :-) Even if WPKG would implement such a context switch it would still require to independent instances. Unless we just duplicate the configuration parameters and allow then to be defined independently. For example the location of wpkg.xml would have to be configurable in config.xml as well (unless it's hardcoded to %AppData% in user context, but this is something I really wouldn't recommend). Yes, totally. You'd still need to run the original copy via startup scripts, WPKG Client or WPKG-GP and then run the second as a user logon script. The beauty of it is that you could add the second instance directly as a single line in a global GPO and let WPKG handle the structure you've set up. Choosing locations for files for the wpkg.xml file actually doesn't seem to much of a problem in my head. I
[wpkg-users] [Bug 273] Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273 --- Comment #6 from Stefan Pendl pendl2mega...@yahoo.de --- One thing has not been discussed yet, the security. For machine software repositories there is no need to grant access for regular users and there shouldn't be access for them anyways. User software repositories will need at least read access for every user. Since we are now maintaining separate repositories, we do not get the problem of users applying machine profiles and vice versa. Maintaining two repositories is not so much work, than getting a bunch of machine installations corrected due to some configuration error. Food for thought ;-) -- Stefan -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 273] Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273 --- Comment #7 from Stefan Pendl pendl2mega...@yahoo.de --- (In reply to comment #5) As for login scripts, well, that's exactly where I see WPKG making an important impact for myself (and many others I hope!). Our central IT support team don't support roaming profiles. Every user login has things prepared by a rather dauntingly long logon script. The script is full of checks for ABC file being present, DEF user being logged in, GHI machine being the machine they logged in on and then does something because of it. So this is possible with WPKG too, since it supports the new condition/ where you can concatenate multiple checks together. host profile-id=OfficeSimple condition check type=host condition=hostname value=^OFFICE/ check type=host condition=environment value=USERNAME=^(Admin|Georg)$/ check type=file condition=exists path=C:\config\HereIam.txt/ /condition /host The above is written down of the top of my head, so you will have to look the correct syntax up, but you should get the picture. -- Stefan -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 273] Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273
--- Comment #8 from Keith Jones k.e.jo...@brighton.ac.uk ---
Hi Stefan,
Wow that's thinking out of the box and elegant too!
(In reply to comment #4)
(In reply to comment #1)
cscript.exe \\path\to\wpkg.js /config:config-usermode.xml /host:%USERNAME%
Thats a really dirty hack, since WPKG already supports environment variable
matching.
Example:
hosts:wpkg
xmlns:hosts=http://www.wpkg.org/hosts;
xmlns:wpkg=http://www.wpkg.org/wpkg;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=../xsd/hosts.xsd
host hostname=^VM\-.+ profile-id=VirtuelleRechner
os=6\.[1-9]\.\d{4}
/
host hostname=^VM\-.+ profile-id=VirtuelleRechnerRemoveAll
os=(5\.\d|6\.0)\.\d{4} environment=VM_WPKG_PROFILE=^1$ /
host hostname=^VM\-.+ profile-id=VirtuelleRechnerSmallTest
os=(5\.\d|6\.0)\.\d{4} environment=VM_WPKG_PROFILE=^2$ /
host hostname=^VM\-.+ profile-id=VirtuelleRechner
os=(5\.\d|6\.0)\.\d{4} /
/hosts:wpkg
Depending on the value of an environment variable the profile to apply will be
selected.
So the following is already possible:
host profile-id=AdminUser environment=USERNAME=^Administrator$ /
--
Stefan
Sorry for the slow reponse, I've been trying to think out my response to
Rainer's replies and your solution did need a few coffees before I could work
any of it out :-)
Am I right to assume that if you don't supply the hostname then it's the
equivalent of hostname=*? I think that's the case. I'm still a bit confused
by the ^Administrator$ bit though. I've yet to look deeply at the code. Does
that work out as an expansion of group membership? Is it really that easy? It
definately looks elegant if it is!
I think I can see where you're going; selecting a profile for all hosts but
only applying it if the filter is valid ie the environment variable USERNAME
equals the user I want to apply it to. I'm still a bit confused by the black
magic of filters :-}
I guess I'd still need to follow Rainer's advice and use an alternate config
to ensure WPKG.XML went somewhere into the user space though, otherwise WPKG
will keep trying to apply the rules every time someone logs in as they won't be
able to overwrite the system one.
Please feel free to stick your oar in with the comments I've made to Rainer
today. I can only see it from my perspective, I can easily be barking up the
wrong tree.
Keith
--
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug.
-
wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 273] Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273 --- Comment #9 from Keith Jones k.e.jo...@brighton.ac.uk --- Hi, (In reply to comment #6) One thing has not been discussed yet, the security. For machine software repositories there is no need to grant access for regular users and there shouldn't be access for them anyways. User software repositories will need at least read access for every user. Since we are now maintaining separate repositories, we do not get the problem of users applying machine profiles and vice versa. Maintaining two repositories is not so much work, than getting a bunch of machine installations corrected due to some configuration error. Food for thought ;-) -- Stefan Understood :-) Well sort of... I'm not sure how this fits in with the request. I can understand having two repositories with appropriate ACLs on the shares and folders should be implemented (actually one repository would suffice if you're careful with access permissions) but I'm not seeing the connection with machine vs user installs. Surely you'd set up things as you need them to be for security/your package needs/your licensing needs? ...Having said that... I've run into a few MSI machine level installs that fall over and need the original source MSI files to made available to them (bad caching!). The end reult is that the user fires the program up, it self-heals and ask for access to the source files which need admin credentials to get access. You can't handle that in a script! Security isn't easy to wave a magic wand over, sometimes you have to absorb that idea and work with the experiences :-( Keith -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 273] Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273 --- Comment #3 from Rainer Meier r.me...@wpkg.org --- I know :-) ...but from my lazy point of view, a switch and a bit of extra code could do all those changes for me in a consistent documented way ;-) And especially the documentation is one of the items I would be afraid of. It would be hard to explain why WPKG uses username as hostname when the /context:user switch is used. But if the user on purpose adds /host:%USERNAME% then it's clear that he just want to enforce WPKG to use the username as host name string. I mean it's not hidden in some program code but obviously stated at the command line. In general I am very concerned about such a change introducing issues and pretty obscure concepts for a use-case where WPKG was not intended to be used. To state it clearly, WPKG from my point of view is a tool for system administrators to maintain system-wide settings. There are other mechanisms like policies, ActiveSetup, Logon-Scripts etc. which are designed to target enforcing user settings. Obviously WPKG can also be used in such environment already using special configuration. But honestly I don't feel like we should document and support this use case officially as it's clearly very limited use-case and requires extremely careful package definition and WPKG configuration to work properly. As you say, it can all be done with different config file settings and different instances of WPKG. Having WPKG do it for me though... well, it'd be another magical moment where WPKG saves the day :-) Even if WPKG would implement such a context switch it would still require to independent instances. Unless we just duplicate the configuration parameters and allow then to be defined independently. For example the location of wpkg.xml would have to be configurable in config.xml as well (unless it's hardcoded to %AppData% in user context, but this is something I really wouldn't recommend). For Host matching; a) Group matching uses a hardcoded $ to retrieve groups the machine is a member of so it'll never retrieve groups a user is a member of. b) Some matches could be skipped (IP matching etc) c) People would have to be careful about wildcard matches, particularly where they've used * as a catch-all match. A separate equivalent to HOSTS.XML file could be important. (handling this might not be trivial) I guess this all refers to extended host attribute matching. In a) I guess you refer to group membership checks which should apply then to the local user rather than the machine. One could also use a simple cmd script to check for user group membership and use execute type checks rather than extended host matching. For b) I can only say that IP matching and also other host attribute matching is only performed if such checks/matches are used in packages. So we don't gain anything if we disable these checks globally. Not sure about c). The matching in hosts.xml and profiles.xml would be the same as for hosts if the username is used as hostname. Moreover if you use the /profile switch then this is ignored and WPKG selects a profile directly. For general issues; b) *Some* extremely badly designed installers still write to HKCU\Software\Microsoft\Windows\Current Version\Uninstall when they do a per-user install. Perhaps the ScanKeys could do with adding HKCU to the search? I think I have disabled this mainly due to performance issues. Scanning the HKCU keys adds performance penalty. However in user-mode of course you might want to check for uninstall entries. But you can still do this using a very simple registry existence check. Those issues (and I'm using the phrase very loosely, they're not issues with WPKG's core use) would benefit from having a little more code and a corresponding setting to switch them on and off. And this is the key point here I guess. The use of WPKG in userspace is not intentional even if it might work already very well. Officially supporting this use (or even encourage it) would require all features to be tested in another completely different environment. I doubt that the amount of installations using WPKG in userspace justify this additional complexity and test effort. Especially since WPKG even with the current features set is able to deal with all use-cases I can think about right now. Maybe you have a concrete use case which does not work in userspace with the current implementation. Up to now I just see a big source for confusion in special user-context mode and added test/development effort for the purpose of supporting an environment which is perhaps better maintained using different technology like Group Policies or ActiveSetup. The use of WPKG in userspace is very, very limited: - System administrators do not want to maintain software (core purpose of WPKG) in userspace - System admins would rather use Group Policies or ActiveSetup to enforce user settings (no WPKG needed here) Moreover WPKG
[wpkg-users] [Bug 273] Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273
Stefan Pendl pendl2mega...@yahoo.de changed:
What|Removed |Added
CC||pendl2mega...@yahoo.de
--- Comment #4 from Stefan Pendl pendl2mega...@yahoo.de ---
(In reply to comment #1)
cscript.exe \\path\to\wpkg.js /config:config-usermode.xml /host:%USERNAME%
Thats a really dirty hack, since WPKG already supports environment variable
matching.
Example:
hosts:wpkg
xmlns:hosts=http://www.wpkg.org/hosts;
xmlns:wpkg=http://www.wpkg.org/wpkg;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=../xsd/hosts.xsd
host hostname=^VM\-.+ profile-id=VirtuelleRechner os=6\.[1-9]\.\d{4}
/
host hostname=^VM\-.+ profile-id=VirtuelleRechnerRemoveAll
os=(5\.\d|6\.0)\.\d{4} environment=VM_WPKG_PROFILE=^1$ /
host hostname=^VM\-.+ profile-id=VirtuelleRechnerSmallTest
os=(5\.\d|6\.0)\.\d{4} environment=VM_WPKG_PROFILE=^2$ /
host hostname=^VM\-.+ profile-id=VirtuelleRechner
os=(5\.\d|6\.0)\.\d{4} /
/hosts:wpkg
Depending on the value of an environment variable the profile to apply will be
selected.
So the following is already possible:
host profile-id=AdminUser environment=USERNAME=^Administrator$ /
--
Stefan
--
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug.
-
wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 273] New: Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273 Summary: Per user install support Product: WPKG Version: other Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: wpkg.js AssignedTo: man...@wpkg.org ReportedBy: k.e.jo...@brighton.ac.uk QAContact: wpkg-users@lists.wpkg.org I wasn't sure if this thought was on the roadmap already. I suspect it is or I've missed something along the journey. Please ignore this if it's a waste of thinking time :-) I've now started seeing smaller software developers adapt their products to be installed by non-privileged users to cope with Windows 7's security model. For instance, I now have a piece of software that is basically an MSAccess .accde file installed into the users %APPDATA% folder and not the machine's one. Desktop shortcuts are added to the user's profile to point to that file which circumvents the need for a per-machine install. As far as I can see WPKG still doesn't formally support per-user installs.I think it's definately robust enough to handle that with trivial changes and some subtle thinking :-) I would like to suggest the implementation of a /context switch with values machine or user. The /context:machine being assumed as the default value and keeping WPKG compatible with current setups. The /context:user being an option you'd add if you run WPKG.JS as a user logon script. In theory, when supplied with the user value WPKG would only need to change two things; a) redirect the WPKG.XML path to the user's %appdata% folder. b) switch host matching to use the currently logged on user instead of the host machine/IP/etc. I appreciate that this trivialises many things but I can't actually see many coding hurdles. I can't actually see many operational issues either. In theory, it should all work already it just boils down to how people implement their WPKG setups :-) I have an awful feeling that I'm missing something... surely it can't be that easy? There might be some performance issues but WPKG really is self-healing so it could actually survive very well. Am I being awfully stupid? Keith -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 273] Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added CC||r.me...@wpkg.org --- Comment #1 from Rainer Meier r.me...@wpkg.org --- I am not closing this issue yet as I might not get the full request correctly. But basically I would say this is already implemented and working. For instance, I now have a piece of software that is basically an MSAccess .accde file installed into the users %APPDATA% folder and not the machine's one. Desktop shortcuts are added to the user's profile to point to that file which circumvents the need for a per-machine install. This is an awful way of deploying software. Especially in professional environments (what WPKG targets to support) per-user installation is really really a bad thing. It opens security holes and issues on many levels. Some examples: - Users might run outdated/vulnerable software - Users might infect their profile but for admin it looks all fine - Different users run different versions of the same software, which is a nightmare re to support I personally usually block execution of binaries in data folders like user profile to prevent this. Although installers like the Skype installer and Chrome are doing exactly this. Chrome offers a business version at least which deploys as MSI machine-wide. And even the default chrome installer installs globally when run as admin with elevation. As far as I can see WPKG still doesn't formally support per-user installs.I think it's definately robust enough to handle that with trivial changes and some subtle thinking :-) WPKG never prevents running as non-privileged user. So you can entirely run it as non-privileged user. The only issue you have to keep in mind is to create packages which run unprivileged as well (do not ask for elevation and do not terminate unexpectedly). Configured this way you can run WPKG in user context or during logon script (user context too) or any other way. I think somebody on the mailing list also reported he's using WPKG to deploy user settings. Therefore creating packages which do nothing more than dealing with user settings. I would like to suggest the implementation of a /context switch with values machine or user. The /context:machine being assumed as the default value and keeping WPKG compatible with current setups. The /context:user being an option you'd add if you run WPKG.JS as a user logon script. I don't think such a switch is required. When run in user context then WPKG just executes as normal. You just need to make sure that if you're running in user context you're not executing any action which requires elevation. Therefore you should not run the same packages. I would recommend running an entirely independent installation of WPKG (from different folder with different packages and profiles). You can also just run the same WPKG instance and use the /config switch to point it to another configuration file. In theory, when supplied with the user value WPKG would only need to change two things; a) redirect the WPKG.XML path to the user's %appdata% folder. b) switch host matching to use the currently logged on user instead of the host machine/IP/etc. Redirection is not required. In user context you can run WPKG with a different config.xml. Either by running a completely separated installation of WPKG (different installation folder) or using the /config command-line switch. Just make sure WPKG does not try to write wpkg.xml into the system32 folder by setting the settings_file_path correctly in config.xml: param name='settings_file_path' value='%AppData%' / The second point I did not get correctly. Why should WPKG match the host for the user? If you mean to fake hostnames in order to match the right profile, then you can simply use the /host command line switch. For example in your cmd script which launches wpkg.js you can write the following: cscript.exe \\path\to\wpkg.js /config:config-usermode.xml /host:%USERNAME% This would allow you to use the username instead of host matching if you wish to do so. Alternatively just use the /profile switch to select the profile directly - you might create a profile per user (profile name = user name) and use /profile:%USERNAME%. I appreciate that this trivialises many things but I can't actually see many coding hurdles. I can't actually see many operational issues either. In theory, it should all work already it just boils down to how people implement their WPKG setups :-) If you do it as proposed, then there is no coding needed to run WPKG in user context. I am personally even running machines with multiple WPKG instances run on system level - just because my sysadmins in the office use WPKG but they don't deploy all software I like. So I just installed my own instance and configured it
[wpkg-users] [Bug 272] New: Wrong exit code from *.cmd files
http://bugzilla.wpkg.org/show_bug.cgi?id=272 Summary: Wrong exit code from *.cmd files Product: WPKG Version: other Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: wpkg.js AssignedTo: man...@wpkg.org ReportedBy: sash...@ukr.net QAContact: wpkg-users@lists.wpkg.org I decided to update my LibreOffice to 3.5. On http://wpkg.org/LibreOffice I've found a good solution. But when wpkg run my custom cmd file, it always return 0 (From log: Command in installation of LibreOffice package returned exit code [0]. This exit code indicates success.). I wrote a cmd file with only one row: exit /B 1616 and even then wpkg indicate success (returned exit code equal 0). Why? I'm using the latest WPKG 1.3.1-RC11. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 272] Wrong exit code from *.cmd files
http://bugzilla.wpkg.org/show_bug.cgi?id=272 Malte Starostik ma...@malte.homeip.net changed: What|Removed |Added CC||ma...@malte.homeip.net --- Comment #1 from Malte Starostik ma...@malte.homeip.net --- Not a WPKG bug IMHO. Assuming your script is called test.cmd: cmd /c test.cmd echo %errorlevel% will yield 0, too. You cannot reliably return an exit code 255 from cmd. Return a lower code or rewrite the script in JScript/VBScript/Powershell/whatever. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 272] Wrong exit code from *.cmd files
http://bugzilla.wpkg.org/show_bug.cgi?id=272 --- Comment #2 from Malte Starostik ma...@malte.homeip.net --- Sorry, got that mixed up somehow. The problem is not the code, but the /b. While exit /b is great to ensure you're not leaving the whole cmd shell, it breaks passing the exit code. Change it to just exit 1616 and try again. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 272] Wrong exit code from *.cmd files
http://bugzilla.wpkg.org/show_bug.cgi?id=272
Rainer Meier r.me...@wpkg.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||r.me...@wpkg.org
Resolution||INVALID
--- Comment #3 from Rainer Meier r.me...@wpkg.org ---
Hi Kalyniak,
Let me guess: You're running your script on Windows XP.
This seems to be a speciality of Windows XP cmd.exe. When you use the /b
parameter it only works when terminating a sub-script. But if you're
terminating the main cmd.exe process in your main script with the /b parameter,
then it always returns exit code 0.
The solution is simply not to use the /b parameter.
I've quickly tested with a simple package executing the following script:
--- exit-code-test.cmd ---
@echo off
exit 1616
--- exit-code-test.cmd ---
WPKG logs the following error:
2012-05-11 18:43:29, DEBUG : Executing command:
'%SOFTWARE%\software.free\test\exit-code-test.cmd'
('\\skynet\reminst\software\software.free\test\exit-code-test.cmd').
2012-05-11 18:43:30, ERROR : Could not process (install) package 'tst
package' (tst):|Exit code returned non-successful value (1616) on command
'%SOFTWARE%\software.free\test\exit-code-test.cmd'.
When using the /b parameter then WPKG always gets exit code 0 from the OS. So
this is a cmd.exe limitation on Windows XP.
By the way, the /b argument works fine when executed on Windows 7. So Windows 7
cmd.exe correctly returns the specified exit code even if exit /b xx is used
to terminate the main cmd script.
--
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug.
-
wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 272] Wrong exit code from *.cmd files
http://bugzilla.wpkg.org/show_bug.cgi?id=272 --- Comment #4 from Rainer Meier r.me...@wpkg.org --- The eample of Malte can also easily be reproduced: -- exit-code-test.cmd -- @echo off exit 1616 -- exit-code-test.cmd -- -- exit-code-test-b.cmd -- @echo off exit /b 1616 -- exit-code-test-b.cmd -- On Windows XP Command Shell: cmd /c exit-code-test.cmd echo %ERRORLEVEL% 1616 cmd /c exit-code-test-b.cmd echo %ERRORLEVEL% 0 On Windows 7 Command Shell: cmd /c exit-code-test.cmd echo %ERRORLEVEL% 1616 cmd /c exit-code-test-b.cmd echo %ERRORLEVEL% 1616 -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 272] Wrong exit code from *.cmd files
http://bugzilla.wpkg.org/show_bug.cgi?id=272 --- Comment #5 from Kalyniak Oleksandr sash...@ukr.net --- Yes it works. Thanks for good answer. I'm working on windows 7 machine. So I was testing this script on it. And of course it worked (exit /B 1616). But almost all computers in my network is Windows XP based. Thanks again :-) -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 260] Feature Request - WPKG to automatically create variables
http://bugzilla.wpkg.org/show_bug.cgi?id=260 --- Comment #3 from Peter Hoeg peterh...@gmail.com --- I hope it's ok to re-open this FR after so long, but I thought the case wasn't completely closed. Basically, I think that adding the complexity to WPKG itself is a good idea. There are 3 places it can happen: 1) in WPKG itself 2) in the recipes 3) in a wrapper script Now, option 2 makes no sense (far too much duplication) and option 3 adds the extra complexity of having to test and support another component. From my point of view, the ideal world would be that the recipes themselves are as clean and minimal as possible as it makes it so much easier to maintain and manage. When the recipes become mere wrappers for scripts that do all the heavy lifting, then you are spreading out the work that needs to be done. I know it's easy to ask for stuff without providing patches, but for the future success of this project, I think it is important to make recipe handling as easy (and non-repeated) as possible. Regarding my first example (with the SomeSoftware part), the SomeSoftware part was just to illustrate how it would be used. The idea would of course be to abstract PROGRAM_FILES and PROGRAM_FILES(x86) themselves. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 260] Feature Request - WPKG to automatically create variables
http://bugzilla.wpkg.org/show_bug.cgi?id=260 --- Comment #4 from Rainer Meier r.me...@wpkg.org --- I still believe that option 1 (hard-coding such variables in WPKG) is the worst out of all. I am not even saying that it would be hard to implement, but not everything which can be implemented does make sense. In the initial request there were already some sniplets provided which are samples of variables like PKG_DESTINATION which is pointing to the 32-bit program files folder on 32-bit and 64-bit installations. These sniplets can easily be added to the host or profile definition to make them globally available to all packages. So it's not true that you would have to repeat them over and over again in all packages. Placing them in one single location (profile I recommend) would be absolutely sufficient. Such variables are always specific to a target environment and for me it just does not make any sense to hard-code them in WPKG in order to enforce specific variable names (which might also collide with some existing installations). Moreover there will be an almost infinite list of helper variables one could think of. If WPKG starts to implement some of them we will have to release WPKG more frequently just to update variables which happened to come to the mind of some WPKG user just because he thinks it's useful or he might use in more than one package. One more reason would be language-specific variables as they are required for example to support the location of the public start menu location on different languages. As WPKG itself is language-neutrally implemented in general it would have to be extended for every language. If not, then users will start to complain that in their environment %STARTMENU% does not work while for others it's working perfectly, just because a specific locale edition uses different folder names. So I still believe adding such variables to profiles or hosts is much more efficient. Maybe supplying some example profiles with generic global variables might help assisting users on the idea of profile variables. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 260] Feature Request - WPKG to automatically create variables
http://bugzilla.wpkg.org/show_bug.cgi?id=260 --- Comment #5 from Rainer Meier r.me...@wpkg.org --- OK, I am back with one additional response. In fact I did not want to force-close the issue without re-thinking about a proper solution. So there was one more potential improvement coming to my mind which might satisfy all requirements. I thought if we would have the possibility to define WPKG-wide variables directly in wpkg.xml it would perfectly allow to evaluate global variables within WPKGs own logic without even having to modify WPKG and hard-code some variables. So I did implement exactly this. Now WPKG 1.3.1-RC11 allows to define variables globally in config.xml. It even allows some program logic (conditional variables) to be applied. Therefore it provides quite a flexible way of doing exactly what you have asked for. In addition it will not break any existing installation since by default config.xml does not come with globally-defined variables. This implementation would also allow one to define the SOFTWARE variable or any other global variable which is traditionally defined by WPKG-client before wpkg.js is invoked. Thus effectively removing the requirement to write a wrapper scripts. At least as long as the conditional-variable possibilities of WPKG are sufficient to handle the variable evaluation. Change notes: NEW: Added possibility to specify variables in config.xml. All variables defined in config.xml are WPKG-wide and globally defined during WPKG execution. However these variables might be overwritten by host-, profile- or package variables. Configuration variables are an alternative way to specify global environment variables in central location when not using a WPKG wrapper script or WPKG-client or any other WPKG launcher with capabilities to define global environment variables before wpkg.js is launched. Variables are also allowed to use conditional expressions and therefore allow variable evaluation based on system parameters like architecture, file existence etc. Example: config variables variable name=PROG_FILES32 value=%ProgramFiles% architecture=x86 / variable name=PROG_FILES32 value=%ProgramFiles(x86)% architecture=x64 / /variables /config The example above defines the PROG_FILES32 environment variable to point to the 32-bit program installation folder on 64-bit and 32-bit Windows. Example: config variables variable name=DESKTOP value=%ALLUSERSPROFILE%\Desktop os=windows xp / variable name=DESKTOP value=%PUBLIC%\Desktop os=Windows 7 / /variables /config The example above defines a variable named DESKTOP which points to the location of the public desktop. Therefore accessing %DESKTOP% in packages will point to the right location on either Windows XP or 7. This is supposed to support an enhancement request reported in Bug 260. Thanks to Peter Hoeg for reporting. I have also checked in an updated wpkg.xml which includes some example variables. The XSD files for config.xml have been updated as well in terms of new nodes and documentation. As usual you can get the updated code from SVN: http://wpkg.svn.sourceforge.net/viewvc/wpkg/wpkg/stable/src/main/resources/wpkg/ -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 260] Feature Request - WPKG to automatically create variables
http://bugzilla.wpkg.org/show_bug.cgi?id=260 --- Comment #6 from Peter Hoeg peterh...@gmail.com --- This is truly stellar, thanks Rainer, that solves it nicely. One tiny request now - I would imagine that most people are happy with using config.xml with its defaults, so could we possible have support for config.local.xml which can be used to override settings? I know we can make changes to config.xml directly, but in case there are changes from upstream, those changes would then need merging into the locally adjusted file when a new version is released. Possible? -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 271] downloader.cmd too strict with MD5 pattern matching, causes false negative
http://bugzilla.wpkg.org/show_bug.cgi?id=271 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|NEW |RESOLVED CC||r.me...@wpkg.org Resolution||FIXED --- Comment #1 from Rainer Meier r.me...@wpkg.org --- Although I do not fully agree that we should support any non-standard output I did relax the checks to allow the checksum appearing anywhere in the checksum tool output. This applies to MD5 as well as SHA1. There is however a small risk that the checksum string appears somewhere else in the output and therefore the checksum would be accepted even if the tool prints a different one. However this is very unlikely. That's why I've accepted your change request. We will revert the changes if somebody reports invalid matches in the future. MOD: Relaxed MD5/SHA1 checks to allow checksums appearing anywhere in the output of the MD5/SH1 checksum tool. This might be required for some tools printing checksums at the end of the line instead of standard unix-like output with the checksum at the beginning of the line. This change introduces a small risk of overmatching if the checksum string appears somewhere else on the output as downloader.cmd will just check that the required checksum appears anywhere in the checksum tool output. Fixes Bug 271. Thanks to Neil for reporting. http://wpkg.svn.sourceforge.net/viewvc/wpkg/wpkg/stable/src/main/resources/wpkg/tools/downloader/ br, Rainer -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 270] New: RFE: Bugzilla has no mechanism to submit bugs in `tools' package(s)
http://bugzilla.wpkg.org/show_bug.cgi?id=270 Summary: RFE: Bugzilla has no mechanism to submit bugs in `tools' package(s) Product: wpkg.org web site Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: web site AssignedTo: man...@wpkg.org ReportedBy: 39tk3s7...@snkmail.com QAContact: wpkg-users@lists.wpkg.org Request for enhancement: Bugzilla has no ability to let users enter a bug/RFE for the `tools' group of files/programs. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 271] New: downloader.cmd too strict with MD5 pattern matching, causes false negative
http://bugzilla.wpkg.org/show_bug.cgi?id=271 Summary: downloader.cmd too strict with MD5 pattern matching, causes false negative Product: WPKG Version: other Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: config files AssignedTo: man...@wpkg.org ReportedBy: 39tk3s7...@snkmail.com QAContact: wpkg-users@lists.wpkg.org Created attachment 237 -- http://bugzilla.wpkg.org/attachment.cgi?id=237 Log showing default output of `pc-tools.net' md5sums tool Downloader.cmd can reject a file that has correct MD5 if the checksum doesn't start the line. I use the md5sums tool from http://www.pc-tools.net/win32/md5sums/ (currently version 1.2) and the default output puts the generated checksum at the end of the line (see attached). However, downloader.cmd (line ~337) uses 'findstr /B' to restrict searching for the checksum at the start of the line. This particular md5 tool does support a command-line option to mimic Unix behavior and put the checksum at the start, but I propose removing the '/B' option to provide better drop-in support for other MD5 tools that may also have a default format different from Unix. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 269] config.xml file has wrong encoding
http://bugzilla.wpkg.org/show_bug.cgi?id=269 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|NEW |RESOLVED CC||r.me...@wpkg.org Resolution||FIXED --- Comment #2 from Rainer Meier r.me...@wpkg.org --- I've saved it using eclipse which does not seem to use BOM. It looks like it was stored using UTF-8 but without BOM. Opening it with PSPad in UTF-8 mode does not show any issues with German, French or Spanish translations. Also your sample shows that special characters are encoded using two bytes (UTF-8). But likely your editor translated the characters using ANSI or any other 8-bit charset which makes UTF-8 characters 2-byte characters appear wrongly. Just out of curiosity, which editor are you using? It seems to ignore the encoding header in the XML header too. Nevertheless I've added the BOM header and committed it. FIX: Fixed UTF-8 with BOM encoding for config.xml. Fixes Bug 269. Thanks to Stefan Pendl. br, Rainer -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 208] domain group is not correctly retrieved
http://bugzilla.wpkg.org/show_bug.cgi?id=208 Stefan Pendl pendl2mega...@yahoo.de changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 268] Patch for package templates
http://bugzilla.wpkg.org/show_bug.cgi?id=268 Stefan Pendl pendl2mega...@yahoo.de changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 269] config.xml file has wrong encoding
http://bugzilla.wpkg.org/show_bug.cgi?id=269 Stefan Pendl pendl2mega...@yahoo.de changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Stefan Pendl pendl2mega...@yahoo.de --- Hi Rainer, In general Notepad++ is happy with ANSI as UTF-8 encoded files, but this seems not to be the case for this file. The BOM doesn't hurt and makes sure that any editor, not just only specialized ones, display and edit the text correctly. -- Stefan -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 269] New: config.xml file has wrong encoding
http://bugzilla.wpkg.org/show_bug.cgi?id=269 Summary: config.xml file has wrong encoding Product: WPKG Version: other Platform: PC OS/Version: All Status: NEW Severity: major Priority: P2 Component: config files AssignedTo: man...@wpkg.org ReportedBy: pendl2mega...@yahoo.de QAContact: wpkg-users@lists.wpkg.org The config.xml file is encoded as ANSI, which renders the foreign characters for German and Spanish useless. The file must be saved as UTF-8 with BOM to correct this. Spanish example: La utilidad de instalación automática de software está actualizando el sistema. Thanks in advance, Stefan -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug.- wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 269] config.xml file has wrong encoding
http://bugzilla.wpkg.org/show_bug.cgi?id=269 --- Comment #1 from Loren M. Lang lor...@north-winds.org --- On 4/8/2012 11:14 AM, bugzilla-dae...@bugzilla.wpkg.org wrote: http://bugzilla.wpkg.org/show_bug.cgi?id=269 Summary: config.xml file has wrong encoding Product: WPKG Version: other Platform: PC OS/Version: All Status: NEW Severity: major Priority: P2 Component: config files AssignedTo: man...@wpkg.org ReportedBy: pendl2mega...@yahoo.de QAContact: wpkg-users@lists.wpkg.org The config.xml file is encoded as ANSI, which renders the foreign characters for German and Spanish useless. The file must be saved as UTF-8 with BOM to correct this. Spanish example: La utilidad de instalación automática de software está actualizando el sistema. And on that note, bugzilla should be properly declaring it's content type and charset for UTF-8 with something like this: Content-Type: text/plain; charset=utf-8 Thanks in advance, Stefan - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug.- wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 190] Can not use variables in path for logfile or offline script
http://bugzilla.wpkg.org/show_bug.cgi?id=190 KT le.da...@laposte.net changed: What|Removed |Added CC||le.da...@laposte.net --- Comment #1 from KT le.da...@laposte.net --- The option settings_file_path is also concerned by this bug. Uncommenting param name='settings_file_path' value='%SystemRoot%\\system32' / leads to a File not found error. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 190] Can not use variables in path for logfile or offline script
http://bugzilla.wpkg.org/show_bug.cgi?id=190 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added CC||r.me...@wpkg.org --- Comment #2 from Rainer Meier r.me...@wpkg.org --- Concerning settings_file_path: This issue has been fixed already with WPKG 1.3.1-RC1. See changelog: Changes 2011-12-08, v1.3.1-RC1 by Rainer Meier r.meier (at) wpkg.org MOD: Disable Legend in XSD documentation as it's not meaningful to WPKG. FIX: Fixed environment variable expansion in settings_file_path parameter within config.xml. Functionality has been lost when introducing [HOSTNAME] and [PROFILE] expansion in settings file name. Thanks to Daniel Rickenbacher for reporting. Admittedly WPKG 1.3.1 has not been released yet. You might get it from SVN: http://wpkg.svn.sourceforge.net/viewvc/wpkg/wpkg/stable/src/main/resources/wpkg/ I recommend to get latest version 1.3.1-RC6 from SVN. Regarding variable expansion in WPKG client Tomasz might be able to answer. br, Rainer -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 268] New: Patch for package templates
http://bugzilla.wpkg.org/show_bug.cgi?id=268 Summary: Patch for package templates Product: WPKG Version: other Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: documentation AssignedTo: man...@wpkg.org ReportedBy: pendl2mega...@yahoo.de QAContact: wpkg-users@lists.wpkg.org Created attachment 236 -- http://bugzilla.wpkg.org/attachment.cgi?id=236 patch for package templates Include destination folder in install switches for NSIS template to make sure the destination is the same as used with the remove switch. Remove /COPYALL switch from RoboCopy template to make sure access rights are inherited from destination folder. -- Stefan -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 268] Patch for package templates
http://bugzilla.wpkg.org/show_bug.cgi?id=268 Stefan Pendl pendl2mega...@yahoo.de changed: What|Removed |Added Attachment #236 is|0 |1 patch|| Attachment #236|application/octet-stream|text/plain mime type|| -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 267] New: In a system where a package was installed and after uninstalled, the 3rd execution of wpkg.js cause the installation and the uninstallation of this package instead of no ac
http://bugzilla.wpkg.org/show_bug.cgi?id=267 Summary: In a system where a package was installed and after uninstalled, the 3rd execution of wpkg.js cause the installation and the uninstallation of this package instead of no action Product: WPKG Version: other Platform: PC OS/Version: other Status: NEW Severity: major Priority: P2 Component: wpkg.js AssignedTo: man...@wpkg.org ReportedBy: w...@scuolacarovana.it QAContact: wpkg-users@lists.wpkg.org Created attachment 234 -- http://bugzilla.wpkg.org/attachment.cgi?id=234 snapshot of log files and wpkg.xml files I'm new of wpkg and i've played with the basic config and the Dia example package. So, i've setup the environment and i've tried to install and uninstall Dia on a target PC. wpkg.js version: 1.3.0 SO: Win7 Pro Client: both WPKG-GP and direct call via cscript # host.xml: host name=win7pro profile-id=profilo-comune profile id=profilo-specifico / /host # profile.xml: profile id=profilo-comune variable name=SOFTWARE value=\\debian-host1\dallolio\wpkg\software / package package-id=dia / /profile # package.xml: package id=dia name=Dia Diagram Editor revision=0.97.2-20111223 reboot=false priority=1 check type=logical condition=or check type=file condition=exists path=%PROGRAMFILES%\dia\dia-0.97.2-uninstall.exe / check type=file condition=exists path=%PROGRAMFILES(x86)%\dia\dia-0.97.2-uninstall.exe / /check install cmd='%SOFTWARE%\dia\dia-setup-0.97.2.exe /S' / upgrade cmd='%SOFTWARE%\dia\dia-setup-0.97.2.exe /S' / remove cmd='%PROGRAMFILES%\dia\dia-0.97.2-uninstall.exe /S' / remove cmd='%PROGRAMFILES(x86)%\dia\dia-0.97.2-uninstall.exe /S' / /package I've found this issue by the wpkg-gp client and after i've debug in cscript # Step 1: Starting in a clean system cscript \\server\path\wpkg.js /synchronize /query:i : package currently installed: [none] so, from an administrative cmd.exe shell i've run cscript \\server\path\wpkg.js /synchronize /debug and the dia package went correctly installed (see step1_*.* attachments) # Step 2: from profile.xml, i've remove the dia package line: profile id=profilo-comune variable name=SOFTWARE value=\\debian-host1\dallolio\wpkg\software / /profile and i've run the same command: cscript \\server\path\wpkg.js /synchronize /debug the dia prg was succesfully removed (see step2_*.* attachments) i've manually removed the c:\%programfiles%\dia folder because uninstaller not did # Step3: i've run the same command cscript \\server\path\wpkg.js /synchronize /debug and i was especting a no action result instead an installation and a uninstallation action (see step3_*.* attachments) Sorry in advance if the problem is in my side... Tnx -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 267] In a system where a package was installed and after uninstalled, the 3rd execution of wpkg.js cause the installation and the uninstallation of this package instead of no action
http://bugzilla.wpkg.org/show_bug.cgi?id=267 --- Comment #1 from Stefano w...@scuolacarovana.it --- executing cscript \\server\path\wpkg.js /synchronize /query:i after the step3 i obtain: Microsoft (R) Windows Script Host Versione 5.8 Copyright (C) Microsoft Corporation 1996-2001. Tutti i diritti riservati. Packages currently installed: Dia Diagram Editor ID:dia Revision: 0.97.2-20111223 Reboot:false Execute: - Priority: 1 Status:Installed -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 267] In a system where a package was installed and after uninstalled, the 3rd execution of wpkg.js cause the installation and the uninstallation of this package instead of no action
http://bugzilla.wpkg.org/show_bug.cgi?id=267 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|NEW |RESOLVED CC||r.me...@wpkg.org Resolution||INVALID --- Comment #2 from Rainer Meier r.me...@wpkg.org --- Hi Stefano, WPKG in this case works perfectly as expected. Step 1 performs correctly (honestly I did not even check). Step 2 is supposed to remove the package. Looking at the log I see the following: ... 2012-02-07 09:59:30, DEBUG : Executing command: '%PROGRAMFILES(x86)%\dia\dia-0.97.2-uninstall.exe /S'. 2012-02-07 09:59:30, ERROR : Command '%PROGRAMFILES(x86)%\dia\dia-0.97.2-uninstall.exe /S' was unsuccessful.|Impossibile trovare il file specificato.| 2012-02-07 09:59:30, DEBUG : Command returned result: -1 2012-02-07 09:59:30, ERROR : Exit code returned non-successful value: -1|Package: Dia Diagram Editor.|Command:|%PROGRAMFILES(x86)%\dia\dia-0.97.2-uninstall.exe /S ... 2012-02-07 09:59:30, DEBUG : The path 'C:\Program Files\dia\dia-0.97.2-uninstall.exe' exists and is a file: the test was successful. ... 2012-02-07 09:59:30, ERROR : Could not process (remove) Dia Diagram Editor.|Package still installed. ... The uninstall commands failed. I think the translation of Impossibile trovare il file specificato. is File not found in short. As a result the exit code of the command is -1. Your package does not specify that -1 is a success exit code (see exit / node for commands). Then WPKG executes the check to verify that the software was properly uninstalled. Which seems not to be the case: The path 'C:\Program Files\dia\dia-0.97.2-uninstall.exe' exists and is a file: the test was successful. So WPKG thinks that Dia is still installed properly and properly returns an error: Could not process (remove) Dia Diagram Editor.|Package still installed. As a result WPKG will not remove Dia from the local wpkg.xml file. So remember that for WPKG the Dia package is still installed. It will try over and over again to perform proper uninstall on subsequent synchronization until it succeeds. Next step (as you write) is that you were going to delete the Dia folder manually. On subsequent WPKG run WPKG will first verify that checks for packages supposed to be installed do properly succeed. In your case remember again that Dia is still a package which is supposed to be installed for WPKG as it has not been properly uninstalled. As you manually removed a file which is essential for Dia (the uninstaller as specified by your checks) WPKG will first try to repair the broken Dia package. And yes, this is intended behavior as WPKG first needs to ensure consistent system state and it verifies all packages to be properly installed. Hence it's going to re-install it first to make sure it can be properly removed by specified uninstall procedures. After installation it will immediately execute the remove commands to do a proper removal. This removal will fail again due to not working remove commands (see above). SOLUTION To get this fixed you only need to make sure the uninstall procedure (remove commands) do work properly. Unfortunately Dia is one of the applications suffering from the NSIS fork bug or design flaw. The uninstaller will terminate immediately and spawn a child process which performs the removal of application files. As a result WPKG will continue processing before the uninstaller finishes removing the files. There are several options known to help in most cases. Some say the _=%ProgramFiles%\Dia\ command line parameter helps the uninstaller to wait for the Dia folder to be removed before exiting. I personally use a small cmd script which uninstalls Dis correctly and waits for the uninstaller to disappear before it continues. I am going to attach this script to this report. Basically the script is also used for other tricky applications facing the same bug (NSIS based) like VLC. In order to use it update your package: # package.xml: package id=dia name=Dia Diagram Editor revision=0.97.2-20111224 reboot=false priority=1 check type=logical condition=or check type=file condition=exists path=%PROGRAMFILES%\dia\dia-0.97.2-uninstall.exe / check type=file condition=exists path=%PROGRAMFILES(x86)%\dia\dia-0.97.2-uninstall.exe / /check install cmd='%SOFTWARE%\dia\dia-setup-0.97.2.exe /S' / upgrade cmd='%SOFTWARE%\dia\dia-setup-0.97.2.exe /S' / remove cmd='%SOFTWARE%\dia\unattended-uninstall.cmd' / /package NOTE: You should also increment the package revision. So WPKG will automatically upgrade to the latest and fixed package before doing proper uninstall this time. PS: Please post such questions to the mailing list first in the future. Installer-Related issues are
[wpkg-users] [Bug 267] In a system where a package was installed and after uninstalled, the 3rd execution of wpkg.js cause the installation and the uninstallation of this package instead of no action
http://bugzilla.wpkg.org/show_bug.cgi?id=267 --- Comment #3 from Rainer Meier r.me...@wpkg.org --- Created attachment 235 -- http://bugzilla.wpkg.org/attachment.cgi?id=235 My Dia uninstaller script As promised please find attached my Dia uninstaller script. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 267] In a system where a package was installed and after uninstalled, the 3rd execution of wpkg.js cause the installation and the uninstallation of this package instead of no action
http://bugzilla.wpkg.org/show_bug.cgi?id=267 --- Comment #5 from Rainer Meier r.me...@wpkg.org --- Thank you for the complete explanation and for the right uninstall script. You're very welcome. In the future i'll post first in the mailing list. This will assure fast response and usually leads to quick resolution of issues. If the conclusion on the list is that it's a bug or if you're sure it's a bug, then the bug tracker is of course the right location. May I suggest you to change the first installation example in the site with something that surelly works at the first attempt. I guess you refer to http://wpkg.org/Dia. It seems to be incorrect and identical to your initial package which is clearly not working properly. The package definitions on wpkg.org are free to change by anyone. So feel free to update it immediately (as you seem to be the first one spotting some issue with the provided package). There might be also multiple valid packages as the VLC package demonstrates: http://wpkg.org/Vlc But the one for Dia seems to be broken. It's late for me now so I won't update it, feel free to do it or to ask on the list whether somebody could do it using information from this thread. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 266] Feature: enhanced logging per package
http://bugzilla.wpkg.org/show_bug.cgi?id=266 --- Comment #2 from wpkg_bugzilla.20.ko...@xoxy.net --- Thank you for the long and details explanation! I understand now why this feature is not helpful and what I can do to archive my wish! -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 266] Feature: enhanced logging per package
http://bugzilla.wpkg.org/show_bug.cgi?id=266 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Rainer Meier r.me...@wpkg.org --- So I think you're fine if I close this issue :) -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 266] New: Feature: enhanced logging per package
http://bugzilla.wpkg.org/show_bug.cgi?id=266 Summary: Feature: enhanced logging per package Product: WPKG Version: other Platform: PC OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: wpkg.js AssignedTo: man...@wpkg.org ReportedBy: wpkg_bugzilla.20.ko...@xoxy.net QAContact: wpkg-users@lists.wpkg.org At the moment it is possible to create a log for every client and save this log to a network destination. An admin has then to watch all client-logs to get an overview where a packaged is already installed and if the installation was successful. I would like to suggest to optionally create a additional log file for every package. After installation of a package wpkg should write a single line to a logfile (with the name of the package) and add the name of client, result (error, success) and date/time. Note: I guess, in my environment there should be no problems with concurrent file access. However, for big environments there should be a logic how often wpkg tries to open the file and how log it has to wait between the retries. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 266] Feature: enhanced logging per package
http://bugzilla.wpkg.org/show_bug.cgi?id=266 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|NEW |RESOLVED CC||r.me...@wpkg.org Resolution||WONTFIX --- Comment #1 from Rainer Meier r.me...@wpkg.org --- I do not have any plans to implement such a feature. For me it's very prone to errors and moreover it overlaps with existing WPKG functionality. Some details: WPKG 1.3.0 was heavily improved on reporting. Please have a close look at the /query parameter. It allows you to analyze the current state of any client of which you have the package database (wpkg.xml). From the request I understood you want to have better reporting on which package is installed on certain clients (list of packages currently installed) - or get a report of a package to see on which clients it's deployed. For both queries there are tools which can do this using existing functionality. You might want to have a look at wpkgCreateReport: http://wpkg.org/User_contributed_software#wpkgCreateReport It has been updated recently to support the new /query functionality of WPKG 1.3.0 and prepares a report of packages, in addition it shows graphical report of pending updates/downgrades/removes in addition to current installation state. Additional notes. I believe it does not make much sense to have clients running WPKG adding lines to marker log files on the server. One of the problems you have already indicated: Concurrent access. While it's unlikely to garble a file during concurrent write with just a few clients the probability of issues increases with number of clients if there is no transaction oriented concurrent access middle-ware. In addition WPKG internally does not distinguish updates from installs and you will have multiple entries about a single client within these files. In general I just think it's bad design to get the install state this way. This does not mean you should get the install state from log files (which was never the purpose of the log files either). Instead the local database (wpkg.xml) represents precise state of the client. In order to know the install state just copy wpkg.xml to a share where you can acceess it. There are multiple ways to do this: - Simply create wpkg-package which copies the file to a share - If you use WPKG client you might use a post-execute command to copy wpkg.xml to a share - You might allow wpkg to store wpkg.xml directly on a share (refer to config.xml) Having a copy of wpkg.xml for each client on the server allows you to know exactly what is currently really installed. Moreover you can even use wpkg.js to analyze these logs which will also work in the future in case the structure changes. If you insist on having some logs when install commands are executed, then there is also another option (not recommended though): Just add another install/upgrade/downgrade/remove command to your package which appends a line to your log file. Something like install cmd='...' / install cmd='cmd /C echo Installation of package X finished \\server\share\logs\package-X.log' / This will simply append one line to the package-X.log file after all commands have been executed. Due to the fact that WPKG stops execution of install commands when they fail the line is only executed if all previous install commands succeed. Although there is one limitation: The install commands might be successful but checks might still fail. So WPKG might still detect the software is not installed properly but you get an entry in your log file. So I strongly recommend to look for official interfaces and deal with wpkg.xml. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 263] New: very small inconsequential white space correction
http://bugzilla.wpkg.org/show_bug.cgi?id=263 Summary: very small inconsequential white space correction Product: WPKG Version: other Platform: PC OS/Version: All Status: NEW Severity: trivial Priority: P2 Component: config files AssignedTo: man...@wpkg.org ReportedBy: urs@om.org QAContact: wpkg-users@lists.wpkg.org Created attachment 231 -- http://bugzilla.wpkg.org/attachment.cgi?id=231 minor whitespace removal both the sample hosts.xml and profiles.xml files have an extraneous trailing space before a closing double quote. (the space between URL and path is needed and part of the correct syntax) -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 264] New: wpkg-1.3.1-RC2 correction of spelling and grammar and whitespace
http://bugzilla.wpkg.org/show_bug.cgi?id=264 Summary: wpkg-1.3.1-RC2 correction of spelling and grammar and whitespace Product: WPKG Version: other Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: wpkg.js AssignedTo: man...@wpkg.org ReportedBy: urs@om.org QAContact: wpkg-users@lists.wpkg.org Created attachment 232 -- http://bugzilla.wpkg.org/attachment.cgi?id=232 spelling + grammar + whitespace corrections have gone through and corrected spelling, grammar and whitespace issues I have come across. german: eventuell != english: eventually (very different meaning) -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 265] New: removed br html markup tag
http://bugzilla.wpkg.org/show_bug.cgi?id=265 Summary: removed br html markup tag Product: WPKG Version: other Platform: PC OS/Version: All Status: NEW Severity: trivial Priority: P2 Component: wpkg.js AssignedTo: man...@wpkg.org ReportedBy: urs@om.org QAContact: wpkg-users@lists.wpkg.org Created attachment 233 -- http://bugzilla.wpkg.org/attachment.cgi?id=233 removed html markup tag br maybe this is wrong and I misunderstood why it's there , but I removed the seemingly superfluous html markup for paragraph breaks br I ketp all of these in one diff file in case I got it all wrong and they are needed afterall? -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 265] removed br html markup tag
http://bugzilla.wpkg.org/show_bug.cgi?id=265 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|NEW |RESOLVED CC||r.me...@wpkg.org Resolution||FIXED --- Comment #1 from Rainer Meier r.me...@wpkg.org --- Hi Urs I would like to keep this manual breaks. The comments in function headers are formatted as JavaDoc. JavaDoc tool uses the characters in the commend and copies them 1:1 into a HTML documentation. Therefore line breaks are removed which makes some comments very hard to read in HTML format. Moreover also some formatters (like Eclipse JS formatter) do remove manual line breaks in javadoc headers. Although they are kept if pre-formatted or br is used. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 263] very small inconsequential white space correction
http://bugzilla.wpkg.org/show_bug.cgi?id=263 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|NEW |RESOLVED CC||r.me...@wpkg.org Resolution||FIXED --- Comment #1 from Rainer Meier r.me...@wpkg.org --- Thanks for corrections. Applied in version 1.3.1-RC3 update: Changes 2012-01-29, v1.3.1-RC3 by Rainer Meier r.meier (at) wpkg.org FIX: Fixed extraneous trailing space in hosts.xml. Fixes Bug 263. Thanks to Urs Rau. FIX: Fixed extraneous trailing space in profiles.xml. Fixes Bug 263. Thanks to Urs Rau. FIX: Fixed spelling and whitespace issues (cosmetic fixes, no functional impact) in wpkg.js. Fixes Bug 264. Thanks to Urs Rau. Thank you! -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 264] wpkg-1.3.1-RC2 correction of spelling and grammar and whitespace
http://bugzilla.wpkg.org/show_bug.cgi?id=264 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|NEW |RESOLVED CC||r.me...@wpkg.org Resolution||FIXED --- Comment #1 from Rainer Meier r.me...@wpkg.org --- Most fixes have been applied in WPKG 1.3.1-RC3 update: Changes 2012-01-29, v1.3.1-RC3 by Rainer Meier r.meier (at) wpkg.org FIX: Fixed extraneous trailing space in hosts.xml. Fixes Bug 263. Thanks to Urs Rau. FIX: Fixed extraneous trailing space in profiles.xml. Fixes Bug 263. Thanks to Urs Rau. FIX: Fixed spelling and whitespace issues (cosmetic fixes, no functional impact) in wpkg.js. Fixes Bug 264. Thanks to Urs Rau. Thank you! -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 264] wpkg-1.3.1-RC2 correction of spelling and grammar and whitespace
http://bugzilla.wpkg.org/show_bug.cgi?id=264 --- Comment #2 from Urs Rau urs@om.org --- you are welcome. the one part where I was not sure if it did have a small functional impact was: -dinfo(The registry path ' + checkPath+ ' could be read.); +dinfo(The registry path ' + checkPath + ' could be read.); -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 264] wpkg-1.3.1-RC2 correction of spelling and grammar and whitespace
http://bugzilla.wpkg.org/show_bug.cgi?id=264 --- Comment #3 from Rainer Meier r.me...@wpkg.org --- Hi Urs, No, it does not have any functional impact. I have applied your additional space. Thanks again for your review. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 --- Comment #15 from Rainer Meier r.me...@wpkg.org --- After having a look at the code I think it's currently not working correctly with conditional variables. The reason is that WPKG first fetches a list of variables and then defines them. This makes the host/profile variables unavailable during evaluation of package variable conditions. I am working on an improvement right now. Moreover it seems that more users want to override package variables (mainly version) with profile or host variables. So I am thinking about reverting the evaluation order to pre-1.3 behavior (reverse order). Some additional changes will hopefully allow to use conditions in profiles in order to detect whether a variable is set/unset or set to specific value in the package. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 --- Comment #14 from Steve steve.kers...@keble.ox.ac.uk --- (In reply to comment #13) I think check type=host condition=environment value=MY_VAR=^$ / should be correct; but as I am on the road right now I cannot test it. This appears to work in that, with my package, it now does install the version number defined in the host/profile in preference to the one defined in the package. However: it now seems to always run the install actions, regardless of whether the version in the package is installed. This may be an issue with my package, but it didn't do this before changing the version variable definition to include the condition. In the package definition (for the Java runtime, pretty much copied from one of the examples in the wiki with minor modifications), I have: variable name=JAVA_VERSION value=29 condition check type=host condition=environment value=JAVA_VERSION=^$ / /condition /variable I also set 'revision' in the package header to %JAVA_VERSION%. It looks as though with the condition present in the package definition, this variable is not getting expanded, but without the condition, it is. From the debug logs of a machine that is not overloading the variable, with the condition tag: Got variable 'JAVA_VERSION' of value '29' Setting variable: 'JAVA_VERSION=29'. Comparing version: '%JAVA_VERSION%' = '29'. Comparing version fragments: 'JAVA' = '29' Package 'Java Runtime Environment 6' (JRE6): Already installed but version mismatch. Installed revision: '29' Available revision: '%JAVA_VERSION%'. Preparing upgrade. Whereas, on the same machine after just deleting the 'condition' tag from the package: Got variable 'JAVA_VERSION' of value '29' Setting variable: 'JAVA_VERSION=29'. Comparing version: '29' = '29'. Checking existence of package: Java Runtime Environment 6 Is this another issue, or is there something else that needs to be done to change the revision definition so that it expands correctly in addition to adding the condition in order to get variable overloading within host/profile definitions working as it did previously? -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 --- Comment #2 from Kalyniak Oleksandr sash...@ukr.net --- It's OK. But in release note to version 1.3.0 you wrote: Note that this version still includes 100% compatibility with previous WPKG 1.2.0. So upgrading is supposed to be as easy as replacing wpkg.js with the latest version. I understand, I should to read a complete list of changes since WPKG 1.2.0 release. But MOD: Changed variable expansion order was not very clearly to me. Thanks for response. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 --- Comment #3 from Kalyniak Oleksandr sash...@ukr.net --- However, I disagree with I still believe this makes most sense since packages are the most detailed leaf-entity in WPKG.. This way, variables defined in host or profile level, with the same names as in the package level, do not have sence. It's naturally, when I define variable in profile or host level - I define it for override. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 --- Comment #4 from Rainer Meier r.me...@wpkg.org --- OK. I perfectly understand your input. I do declare full compatibility with earlier versions since I always tried to keep compatibility in the code. Variable expansion however was pretty special regarding the fact that it was not clearly specified how variables got expanded in version 1.2.x. Depending on package installation order the results might have changed. So the complete system of variable handling was re-checked. I do also fully understand that the evaluation order now was changed (which admittedly breaks the 100% compatibility rule). Actually both ways of evaluating variables have advantages and disadvantages. WPKG also allows to do any package implementation with either evaluation order (see conditional variables). So personally I am even fine if the order is reverted to WPKG 1.2.x order. Options are: - Host - Profile - Package or - Package - Profile - Host The first one makes sure variables defined in the package are really set as specified in the package and not just accidentally all packages get re-installed since somebody used %VERSION% in the revision attribute and then defined VERSION on profile level. But it does not allow overriding of variables which are not designed to be overridden (e.g. by condition). The second option allows overriding of package variables easily but might result in unexpected effects if a profile or host defined variables which are used by a package. As I said I am open to discuss this; the changes to WPKG would be pretty minimal I would say. Is anybody else using heavy variable overriding? @Stefan: I think you might use it. Which variable overriding policy would you opt for? ;) -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 --- Comment #5 from Kalyniak Oleksandr sash...@ukr.net --- Thank's for this: But it does not allow overriding of variables which are not designed to be overridden (e.g. by condition). Now, I fully agree with you. It's wonderfull. I didn't understand it until you wrote that phrase. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262
--- Comment #6 from Stefan Pendl pendl2mega...@yahoo.de ---
Rainer,
I have used variable overriding before the extended host matching and advanced
property checks have been included.
I am currently in the process to consolidate profiles and use check conditions
to determine, if a package should be applied or not, especially for those which
apply to more than one group of hosts.
Since I have a structured environment and my host groups are mostly recognized
by the host names, it is easy to move the whole variable assignment to the
package level.
In other environments it is easier to override variables in the order: read
package - read profile - read host - apply.
Since it seems to be easy to implement both ways how about the following
change:
//---code start (watch for line wraps)
function loadPackageEnv(packageNode) {
// Array to store all variables found.
var variables = new Array();
// Host variables first...
if (gReverseVariableReadOrder == true) {
variables = getPackageVariables(packageNode, variables);
} else {
variables = getHostsVariables(variables);
}
// ...then profile variables...
variables = getProfileVariables(variables);
// ...and lastly package variables.
if (gReverseVariableReadOrder == true) {
variables = getHostsVariables(variables);
} else {
variables = getPackageVariables(packageNode, variables);
}
// Apply variables to environment.
//---code end
This way one can choose which read order to use.
What do you think?
--
Stefan
--
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug.
-
wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 --- Comment #7 from Kalyniak Oleksandr sash...@ukr.net --- Stefan, For my opinion - it's unnecessary. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 --- Comment #8 from Rainer Meier r.me...@wpkg.org --- I was thinking about an option as well, but I would rather like not to do it. First of all it needs more code maintenance and secondly it needs more testing. In fact you would have to provide all tests which deal with variables in to variants in order to prove that everything works as expected for all users. Moreover as stated already you can use either implementation and achieve all goals, it just depends on package definition. So I think it makes no sense to provide two different ways which both allow to do the same thing. So I think we have to decide for one solution. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 Steve steve.kers...@keble.ox.ac.uk changed: What|Removed |Added CC||steve.kers...@keble.ox.ac.u ||k --- Comment #9 from Steve steve.kers...@keble.ox.ac.uk --- (In reply to comment #3) However, I disagree with I still believe this makes most sense since packages are the most detailed leaf-entity in WPKG.. This way, variables defined in host or profile level, with the same names as in the package level, do not have sence. It's naturally, when I define variable in profile or host level - I define it for override. I'd agree with this too - I ran into this problem this morning. I've written a number of my packages such that I can perform test installs of new versions of software by overriding the package-defined version number with a profile or host-defined version before I update the version number in the package to push the software out to all computers. Since this is the main example use case given on the 'Variables' wiki page and had been working with 1.2, I had assumed that this was the way it was intended to work. At least I can stop pulling my hair out now trying to work out why it was installing the wrong version and look at rewriting my packages to use conditional variable definitions and see whether that works. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 Stefan Pendl pendl2mega...@yahoo.de changed: What|Removed |Added CC||pendl2mega...@yahoo.de --- Comment #10 from Stefan Pendl pendl2mega...@yahoo.de --- Keeping the current order of read host - read profile - read package - apply, where the last variable read will override the previous variables, we just need to change the Wiki to reflect this now defined read order. To have a variable at a higher level override the ones below, a conditional check needs to be added to the variable definitions on the lower levels. I envision a check like below: !-- code start (watch for line wraps) -- variable name=MY_VAR value=true condition check type=host condition=environment value=MY_VAR=^$ /condition /variable !-- code end -- Is this correct Rainer? -- Stefan -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 --- Comment #11 from Kalyniak Oleksandr sash...@ukr.net --- I'm confused. Which one is right? 1. check type=host condition=environment value=VAR=^%VAR%$ / Or 2. check type=host condition=environment value=MY_VAR=^$ Please, write topic about conditional variables on wiki. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 --- Comment #12 from Stefan Pendl pendl2mega...@yahoo.de --- Your first example checks, if a variable has a value that is expanded from an existing environment variable. The second example checks if the variable is empty or not set. -- Stefan -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 --- Comment #13 from Rainer Meier r.me...@wpkg.org --- I think check type=host condition=environment value=MY_VAR=^$ / should be correct; but as I am on the road right now I cannot test it. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] New: Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 Summary: Wrong variable apply order Product: WPKG Version: other Platform: PC OS/Version: All Status: NEW Severity: major Priority: P2 Component: config files AssignedTo: man...@wpkg.org ReportedBy: sash...@ukr.net QAContact: wpkg-users@lists.wpkg.org Created attachment 230 -- http://bugzilla.wpkg.org/attachment.cgi?id=230 wpkg-02-105-01.log I've upgraded wpkg to new version 1.3.0. And now, everyday, I have calls from coworkers, which say that they can't see their usb-storages (flash drive). In my packages.xml I have this one package: package id=usb name=Enable/Disable USB Mass Storage revision=1 reboot=false priority=1 !-- 4 - disable, 3 - enable -- variable name=SET_USBSTOR value=4 / check type=registry condition=equals path=HKLM\SYSTEM\CurrentControlSet\Services\USBSTOR\Start value=%SET_USBSTOR% / install cmd='%comspec% /c reg add HKLM\SYSTEM\CurrentControlSet\Services\USBSTOR /v Start /t REG_DWORD /d %SET_USBSTOR% /f' / upgrade cmd='%comspec% /c reg add HKLM\SYSTEM\CurrentControlSet\Services\USBSTOR /v Start /t REG_DWORD /d %SET_USBSTOR% /f' / /package and in hosts.xml: host name=02-105-01 profile-id=finance variable name=SET_USBSTOR value=3 / variable name=SelectLibOffApps value= / /host As said in http://wpkg.org/Variables In which order are they applied. The level below another will overwrite the previous definition. operating system WPKG client package profile host See fragment of log file. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 262] Wrong variable apply order
http://bugzilla.wpkg.org/show_bug.cgi?id=262 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||r.me...@wpkg.org --- Comment #1 from Rainer Meier r.me...@wpkg.org --- The issue is a bit more complex. Initially Brent A Nelson brought up an issue in WPKG 1.2.0 about variable resolve and recursive substitution. Actually WPKG 1.2.0 had no clearly defined way of evaluating variables. So in WPKG 1.2.1-RC27 an improvement on variable resolving was done. The order of resolving (including support for recursive resolve) was clearly defined. See the full conversation here: http://lists.wpkg.org/pipermail/wpkg-users/2011-October/008096.html Here's the change log entry: Changes 2011-10-20, v1.2.1-RC27 by Rainer Meier r.meier (at) wpkg.org MOD: Changed variable expansion order. Now the order is clearly defined as follows: - Host variables - Profile variables (in reverse order, dependencies first) - Package variables This way package variables can refer to profile variables. Profile variables in turn can refer to host variables. Variables can always also include the value of variables already defined using the %VARIABLE% syntax in the value attribute of the variable definition. So for example a package variable can refer to a profile variable. A package variable can also refer to a variable defined within the same package as long as the variable it refers to appears before the one referring to it. Thanks to Brent A Nelson for pointing us to the issue. Thanks to Stefan Pendl for analyzing the issue. MOD: Improved variable reading using caches for host and profile variables. So to summarize the wiki entry currently seems to be just wrong at time of writing. For WPKG 1.2.0 variable resolve order was not defined and recursive substitution did not work. Now WPKG 1.3.0 clearly defines that first the host variables are read, then the profile variable and at the end the package variables. This means that in all cases packages can overwrite variables. I still believe this makes most sense since packages are the most detailed leaf-entity in WPKG. Doing evaluation the other way around. If you want to define a variable in a package which can be overriden by a previously evaluated definition (e.g. on host or profile level) then you can use conditional variables in WPKG 1.3.0 or newer in order to define the variable only if it has not been defined already. Potentially the following (untested) might do it on package level: variable name=VAR value=test condition check type=host condition=environment value=VAR=^%VAR%$ / /condition /variable However it's untested by me. But you get the idea. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 261] What about wpkg.js compression?
http://bugzilla.wpkg.org/show_bug.cgi?id=261 --- Comment #3 from Kalyniak Oleksandr sash...@ukr.net --- Thank you for complete answer. I agree with like 100Mbps environment it allows us to transfer WPKG core component about 40 times per second and any file server I know will have the file in cache. I've just thought why not. I knew nothing about minification tool which states to be completely WSH-compliant. I have no questions about this any more. Thank's again. P.S. I was a professional developer in the past and that's why I love to optimize everything. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 261] What about wpkg.js compression?
http://bugzilla.wpkg.org/show_bug.cgi?id=261 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #4 from Rainer Meier r.me...@wpkg.org --- Marking as resolved as we found agreement that supporting minified version for WPKG does not make too much sense. I was always delighted by demo parties and similar code contests where where size limited contests took place. Amazing what one can fit in a 64kB or even 1kB boundary. But for sure the goal for such demos is another one than maintainability and does not target similar use-cases like WPKG where in the overall use-case size of the application itself does not matter too much. I will re-think about re-structurings if WPKG grows to several megabytes ;) -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 261] New: What about wpkg.js compression?
http://bugzilla.wpkg.org/show_bug.cgi?id=261 Summary: What about wpkg.js compression? Product: WPKG Version: 1.2.1-RCx Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: wpkg.js AssignedTo: man...@wpkg.org ReportedBy: sash...@ukr.net QAContact: wpkg-users@lists.wpkg.org New version of WPKG (1.3.0) has more than 300 KB in size. So why not to release compressed version of wpkg.js. Using YUICompressor-2.4.7 allow me to shrink wpkj.js from 337 KB to 114 KB. I think it will be some sort of performance enhancement in large environments (currently I'm working in company with over than 200 computers). P.S. Maybe I'm wrong and Windows is caching file which was request through file sharing mechanism, so it doesn't rereading from storage. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 261] What about wpkg.js compression?
http://bugzilla.wpkg.org/show_bug.cgi?id=261 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added CC||r.me...@wpkg.org --- Comment #1 from Rainer Meier r.me...@wpkg.org --- Hi, At the beginning when I've joined WPKG development I've been thinking about minification (not compression) as well. But there are several drawbacks using such automatic minification tools. Maybe the most important one is that nowadays most networks run at gigabit speed and in worst case at 100Mbps speed. So in a 100Mbps environment it allows us to transfer WPKG core component about 40 times per second (~25ms transfer time). Moreover the purpose of WPKG is to perform complex operations (synchronizing software). The processing done on client side takes far more processing time. Even worse if there is something to be installed most applications are by far more heavy than WPKG itself. Most applications are in the 5-100MB range, requiring transfer and installation. So I think in today networks (even if on VPN connection with typical DSL speed of 5Mbps WPKG transfers in less than 1 second). VPN often also uses compression. Since wpkg.js is pure text it typically transfers even much faster. Applying standard ZIP compression it transfers in ~80kB. If anybody is worried on the server load this imposes, then let me tell you that disk I/O on server side is for sure not a problem. If wpkg.js is requested many times then any file server I know will have the file in cache in order not to load it from disk each time. One more aspect is the size of the WPKG database (XML files) on server-side. In some environments WPKG will have to load hundreds of small files (or one large packages.xml) from network. Here it might make a bit more sense to combine packages to single XML files as SMB2 is pretty slow (especially over small VPN links) in accessing many small files. It might even be possible to use a HTTP service instead to present a minified package database to the client requesting it which contains only the packages used by this specific client. Unfortunately all these optimizations have an impact on a very important aspect of the deployment: Maintainability. In case of error it's much harder to debug a minified wpkg.js. If the package database is optimized it's getting even worse. Now we also come to another aspect of JavaScript minification. I've been unable to find a minification tool which states to be completely WSH-compliant. Remember that wpkg.js is using JavaScript language but WSH is not 100% ECMA-Script-compatible. So most minifiers I've tried did not work properly when applied to wpkg.js. So if we would officially deliver a minified version of wpkg.js we would have to fully support it and test every single aspect of wpkg.js with the normal and the minified version which is simply too much effort to be justified by a size reduction of 200kB. I am not sure about YUICompressor, but I think I've tried this one as well and it failed to compress the code responsible for environment variable management (it was broken after minification). Maybe it works with the latest version. But I am not planning to support it. The bottom line is that size saved by minifcation would not justify potential trouble in WPKG use-case. Remember that we are not talking about a JavaScript tool which is deployed by hundreds or thousands of page requests per second. Compared to the use-case of WPKG transfer volume and time just does not matter in most cases. If you still think it does in your case. Then feel free to use any working minifier out there and apply it to the official WPKG distribution. Just remember that in case you run into problems try running the non-minified WPKG distribution and if the problem goes away do not file a bug for such issues. One might save already a lot of size if a minifier is used which is just removing the comments in the file. As I have added a lot of documentation in comments this might already reduce the size to ~150kB, so further code minification like variable rename etc. might not add a lot more gain. Removing comments is pretty safe operation. Again, I don't think saving a couple of kB justifies potential problems in WPKG use case. I am not closing the issue yet as I want to keep the discussion open. Asking for more opinion on this issue. Does anybody else feel that size of wpkg.js matters in their environment? -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org
[wpkg-users] [Bug 261] What about wpkg.js compression?
http://bugzilla.wpkg.org/show_bug.cgi?id=261 --- Comment #2 from Tomasz Chmielewski man...@wpkg.org --- I agree with Rainer. Not only would it make no real/measurable difference; it could cause some potential incompatibility, and also error tracking harder. If anyone wants to compress/minify wpkg.js, feel free to do so, and post your results here (minifier used, if it works well, and if there is any measurable difference). -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 260] New: Feature Request - WPKG to automatically create variables
http://bugzilla.wpkg.org/show_bug.cgi?id=260 Summary: Feature Request - WPKG to automatically create variables Product: WPKG Version: other Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: wpkg.js AssignedTo: man...@wpkg.org ReportedBy: peterh...@gmail.com QAContact: wpkg-users@lists.wpkg.org A number of variables are often defined in recipes which would benefit from having WPKG auto-create them. Here are two common patterns: variable name=PKG_DESTINATION value=%PROGRAMFILES%\SomeSoftware architecture=x86 / variable name=PKG_DESTINATION value=%PROGRAMFILES(x86)%\SomeSoftware architecture=x64 / If would could have WPKG automatically create 32BIT_PROGRAMFILES and 64BIT_BITPROGRAMFILES (or some other name), we wouldn't have to check in every recipe. And this case (similar thing applies to 'Start Menu' although the path is different): variable name=DESKTOP value=%ALLUSERSPROFILE%\Desktop os=windows xp / variable name=DESKTOP value=%PUBLIC%\Desktop os=windows 7 / Here WPKG create SHARED_DESKTOP. /Peter -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 259] Feature Request - configuration elements for common operations
http://bugzilla.wpkg.org/show_bug.cgi?id=259 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|NEW |RESOLVED CC||r.me...@wpkg.org Resolution||WONTFIX --- Comment #1 from Rainer Meier r.me...@wpkg.org --- To be honest I currently dislike this idea. And I am going to tell you why. Currently WPKG is developed as platform-independent as possible. What you're asking for is to add a couple of special action which YOU think are often used. These actions will heavily depend on the use-case and if we start to implement shorthand actions in WPKG for commands which are heavily used by any WPKG user, then I will end up in spending my whole spare time to fix these commands on every possible environment out there. In addition some people will start complain that the copy special command does not work in their special setup where they copy from FTP, others will complain because it does not work with HTTP, RSYNC or whatever. In addition this makes WPKG dependent on external tools which might not even be available on some systems. Even worse, on future systems (e.g. Windows 8) all this functionality will have to be tested or even re-written/extended to the new system; which is simply not the goal of WPKG. I think in such case it's much more flexible to provide a couple of tools which are maintained by WPKG community or specific users. As an example there was a similar request for the download tag which is still supported by WPKG since very early days of WPKG. Unfortunately we run exactly into the problem described above. The download functionality was too limited for some users. So we have created a simple tool called downloader (find it in tools/downloader/ folder of the distribution package). Now all users willing to download files (which included doing copies from UNC paths by the way) can use a single syntax for it: install cmd='%SOFTWARE%\downloader\downloader.cmd %SOFTWARE%\source %TEMP%\destination / So for current WPKG versions using the well-known command syntax is much more flexible than using built-in limited download functionality using the download / tag. This script performs the job well and even supports advanced features like SHA1 and MD5 verification which WPKG itself could not even do if we would (implementing SHA1 in WSH is not practically feasible). So I strongly recommend to create simple helper scripts for common tasks, so you will have to write them only once and re-use them. But moving all this platform-dependent functionality into WPKG code makes it big, prone to errors, platform-dependent and hard to maintain while still being extremely limited to the intersection of functions available on all systems where WPKG is supported. Another note: WPKG also supports XML transforms on package XML files (actually on all XML files read). So you might even move common commands to templates and include them on demand using XSLT. Have a look at Bug 257 - Falko was using this functionality already. I personally recommend the solution to create helpers for common actions. Please feel free to comment further if you believe WPKG would really need to go down this road. But likely we would need additional code maintainers to deal with these extensions. Alternatively feel free to contribute simple helpers (like downloader.cmd) for your purposes and provide support for them in the future. If they are generically usable then we might just add them to the tools/ section of WPKG shipment. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 260] Feature Request - WPKG to automatically create variables
http://bugzilla.wpkg.org/show_bug.cgi?id=260 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|NEW |RESOLVED CC||r.me...@wpkg.org Resolution||WONTFIX --- Comment #1 from Rainer Meier r.me...@wpkg.org --- Hi Peter, Also here (much like your request in bug 259). I see the largest drawback in having to support such things for many different platforms (OS/Architecture etc). Also here I think it would be much more helpful to provide a couple of helpers to do the job. Your first example of a common pattern has the issue that it contains the SomeSoftware folder which WPKG does not know and therefore is unable to create. The second example just deals with the fact that %DESKTOP% is on a different location on Windows XP and on Windows Vista and newer. Also here WPKG would be made platform-dependent if it starts to implement such automatic variables. However there is a better solution for it I believe. Use template scripts. I am going to attach a script to this bug report which you can perfectly use for this purpose. I am using a all to evaluateFolders.cmd in all installer scripts which require access to such common folders. It currently supports Windows 2000 and newer with English and German locale. And yes, this is another issue I would not like having to deal with the main wpkg.js code: Language-specific settings. I want to avoid having to update wpkg.js just because someone is using it on a system with some locale setting which has never been used by anybody else. The result will be very frequent releases with adaptations to special environments. I mean we could provide such services on request; but definitely only as part of some commercial agreement. In respect to your bug 259 request where I suggested to use simple scripts you could very easily use the evaluateFolders.cmd helper to get correct paths. e.g. install cmd='%SOFTWARE%\tools\copyToDesktop.cmd %SOFTWARE%\software\software.lnk' / Then the copyToDesktop.cmd script could be simply made up of the following lines: --- @echo off call %SOFTWARE%\tools\evaluateFolders.cmd copy /Y %~1 %DESKTOP% NUL --- That's all required to copy a file to the desktop. Alternatively I repeat again that you could use XSLT in order to include common variables like the DESKTOP variables from an external XML file. So you would have to write only one single XML file which defines the DESKTOP variable for all the systems you intend to support. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 260] Feature Request - WPKG to automatically create variables
http://bugzilla.wpkg.org/show_bug.cgi?id=260 --- Comment #2 from Rainer Meier r.me...@wpkg.org --- Created attachment 229 -- http://bugzilla.wpkg.org/attachment.cgi?id=229 Evaluate common variables Script which evaluates common variables such as %DESKTOP%, %STARTMENU%, %STARTMENU_PROGRAMS% etc. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 258] New: Windows 7 64 bit not correctly detected
http://bugzilla.wpkg.org/show_bug.cgi?id=258 Summary: Windows 7 64 bit not correctly detected Product: WPKG Version: 1.2.1-RCx Platform: PC OS/Version: other Status: NEW Severity: critical Priority: P2 Component: wpkg.js AssignedTo: man...@wpkg.org ReportedBy: bruno.choq...@unicaen.fr QAContact: wpkg-users@lists.wpkg.org Hello, With the version WPKG 1.2.1-RC49 my Windows 7 64 bit (french) is detected as x86 and not x64 : 011-12-05 15:09:10, DEBUG : Host properties: hostname='test128254'|architecture='x86'|os='microsoft windows 7 professionnel, , sp1, 6.1.7601'|ipaddresses='xxx.xxx.xxx.xxx'|domain name='enseignement.local'|groups='Ordinateurs du domaine'|lcid='40c'|lcidOS='40c' -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 258] Windows 7 64 bit not correctly detected
http://bugzilla.wpkg.org/show_bug.cgi?id=258 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||r.me...@wpkg.org --- Comment #1 from Rainer Meier r.me...@wpkg.org --- Are you able to reproduce this by switching between WPKG 1.2.0 and 1.2.1-RC49? I am asking because on all my Win7 Pro x64 machines the architecture is detected properly: 2011-12-04 12:17:50, DEBUG : Host properties: hostname='pc01'|architecture='x64'|os='microsoft windows 7 professional, , sp1, 6.1.7601'|ipaddresses='0.0.0.0,10.0.1.168,192.168.56.1,10.0.1.113'|domain name='domain'|groups=''|lcid='807'|lcidOS='409' Moreover the code to detect the host architecture has not been changed since a while. WPKG is using the value of %PROCESSOR_ARCHITECTURE% system environment variable to detect the architecture. Is it set to AMD64 on your system? Maybe you have set up Windows 7 32-bit on a x86 hardware. In this case Windows reports x86 as a value of PROCESSOR_ARCHITECTURE, even if the hardware is capable of x64/AMD64/EM64T instruction set. br, Rainer -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 258] Windows 7 64 bit not correctly detected
http://bugzilla.wpkg.org/show_bug.cgi?id=258 bruno.choq...@unicaen.fr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from bruno.choq...@unicaen.fr --- Oups, sorry, it' my fault !!! Wpkg Client 32bit installed on windows 7 64bit cause this reaction : architecture is detected as x86. With Wpkg Client 64 bit installed on windows 7 64bit, architecture is correctly detected as x64. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 258] Windows 7 64 bit not correctly detected
http://bugzilla.wpkg.org/show_bug.cgi?id=258 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Rainer Meier r.me...@wpkg.org --- Oh, I did not even think about this. But sure this is a good explanation too :) Closing this issue. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 257] XML error when using templates
http://bugzilla.wpkg.org/show_bug.cgi?id=257 --- Comment #6 from Rainer Meier r.me...@wpkg.org --- I have added some more changes and fixes in order to restore query functionality (host information was lost when reading wpkg.xml due to XML transform apply). @Stefan: Would you mind performing some more extensive tests and let me know whether it's better or worse than before? ;) Also I ask Falko to perform some tests on his use-case. Actually I did test the XSLT listed here already and it worked fine for me. But this is just one single test case... Changes in 1.2.1-RC48: FIX: Fixed invalid regular expression in host matching (within hosts.xml) would exit WPKG. Now a warning about invalid expression is printed. FIX: Fixed lost host information in settings (wpkg.xml) due to applied XML transforms. Bug was introduced in transforms processing added due to request in bug 257. Thanks to Stefan Pendl for reporting. NEW: Using correct name space in settings (wpkg.xml) written locally. NEW: Added proper processing information to settings (wpkg.xml). br, Rainer -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 257] XML error when using templates
http://bugzilla.wpkg.org/show_bug.cgi?id=257 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #7 from Rainer Meier r.me...@wpkg.org --- I have added some more changes and fixes in order to restore query functionality (host information was lost when reading wpkg.xml due to XML transform apply). @Stefan: Would you mind performing some more extensive tests and let me know whether it's better or worse than before? ;) Also I ask Falko to perform some tests on his use-case. Actually I did test the XSLT listed here already and it worked fine for me. But this is just one single test case... Changes in 1.2.1-RC48: FIX: Fixed invalid regular expression in host matching (within hosts.xml) would exit WPKG. Now a warning about invalid expression is printed. FIX: Fixed lost host information in settings (wpkg.xml) due to applied XML transforms. Bug was introduced in transforms processing added due to request in bug 257. Thanks to Stefan Pendl for reporting. NEW: Using correct name space in settings (wpkg.xml) written locally. NEW: Added proper processing information to settings (wpkg.xml). br, Rainer -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 257] XML error when using templates
http://bugzilla.wpkg.org/show_bug.cgi?id=257 --- Comment #9 from Rainer Meier r.me...@wpkg.org --- So if I understand you properly the errors you discovered were referring to broken packages and not related to any WPKG bug. So it helped you to fix your packages. Please let me know if you discover any further issues. But I am sure you will :) Thank you! -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 257] XML error when using templates
http://bugzilla.wpkg.org/show_bug.cgi?id=257 --- Comment #10 from Rainer Meier r.me...@wpkg.org --- Just noticed. The error message contains a typo. Fixed in 1.2.1-RC49. No functional changes. FIX: Fixed minor typo in error message about invalid XML structure loaded. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 257] New: XML error when using templates
http://bugzilla.wpkg.org/show_bug.cgi?id=257 Summary: XML error when using templates Product: WPKG Version: 1.2.1-RCx Platform: PC OS/Version: Windows XP Status: NEW Severity: major Priority: P2 Component: wpkg.js AssignedTo: man...@wpkg.org ReportedBy: ftroj...@smi-softmark.de QAContact: wpkg-users@lists.wpkg.org Starting with 1.2.1-RC42 up to RC46, I get the following error when using XML templates: 2011-11-21 09:34:12, DEBUG : Reading XML file: //smilux/install/packages/firefox-ext-aardvark.xml 2011-11-21 09:34:12, ERROR : Message: Versuch, einen schreibgeschFCtzten Knoten zu E4ndern.||Description: Versuch, einen schreibgeschFCtzten Knoten zu E4ndern.||Error number: 80004005|Stack: undefined|Line: undefined contents of firefox-ext-aardvark.xml: !DOCTYPE firefoxextension [ !ENTITY ext-name aardvark !ENTITY ext-key 3.0_ff8 !ENTITY ff-extension SYSTEM ../templates/ff-extension.xml ] packagesff-extension;/packages contents of templates/ff-extension.xml package id='firefox-ext-ext-name;' name='Firefox Extension ext-name;' revision='ext-key;' priority='15' variable name='fxext' value='ext-name;-ext-key;'/ variable name='fxname' value='ext-name;-'/ check type=logical condition=or check type=file condition=exists path=%CommonProgramFiles%\Mozilla Shared\Extensions\%FXEXT%\install.rdf / check type=file condition=exists path=%CommonProgramFiles(x86)%\Mozilla Shared\Extensions\%FXEXT%\install.rdf / /check depends package-id=firefox-check / install cmd='%SOFTWARE%\packages\mozilla\install-extensions.cmd Firefox %FXEXT% c:\netinst\logs\%FXEXT%-install.log'/ upgrade cmd='%SOFTWARE%\tools\pskill.exe firefox.exe' exit code=-1 / /upgrade upgrade cmd='%SOFTWARE%\packages\mozilla\clean-extensions.cmd Firefox %FXEXT% %FXNAME%c:\netinst\logs\%FXNAME%-upgrade.log'/ upgrade cmd='%SOFTWARE%\packages\mozilla\install-extensions.cmd Firefox %FXEXT% c:\netinst\logs\%FXEXT%-upgrade.log'/ downgrade cmd='%SOFTWARE%\tools\pskill.exe firefox.exe' exit code=-1 / /downgrade downgrade cmd='%SOFTWARE%\packages\mozilla\clean-extensions.cmd Firefox %FXEXT% %FXNAME%c:\netinst\logs\%FXNAME%-downgrade.log'/ downgrade cmd='%SOFTWARE%\packages\mozilla\install-extensions.cmd Firefox %FXEXT% c:\netinst\logs\%FXEXT%-downgrade.log'/ remove cmd='%SOFTWARE%\packages\mozilla\remove-extensions.cmd Firefox %FXEXT% c:\netinst\logs\%FXEXT%-remove.log'/ remove cmd='cmd /c if exist %CommonProgramFiles%\Mozilla Shared\Extensions\%FXEXT%\ rmdir /s /q %CommonProgramFiles%\Mozilla Shared\Extensions\%FXEXT%\' / remove cmd='cmd /c if exist %CommonProgramFiles(x86)%\Mozilla Shared\Extensions\%FXEXT%\ rmdir /s /q %CommonProgramFiles(x86)%\Mozilla Shared\Extensions\%FXEXT%\' / /package Don't know if this is a bug in wpkg.js or if I have to change my XML files. Further informations what I use here: http://wpkg.org/Firefox_ext_install_downloads Thanx, Falko -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 257] XML error when using templates
http://bugzilla.wpkg.org/show_bug.cgi?id=257 --- Comment #2 from Rainer Meier r.me...@wpkg.org --- OK; I think I know what's happening here. Earlier versions of WPKG were using XSLT to read XML files from packages/* folder. But this caused some issues with merging of different namespaces (XML files with namespaces and XML files without namespaces). At the end the implementation now does not use XSLT any more to read the files. Instead it opens the XML structure and merges them programmatically. Unfortunately this means your firefox-ext-aardvark.xml will not be transformed and therefore it won't be executed to include the contents of ff-extension.xml. I am investigating if there is a way to support both by applying transforms to the files loaded. But this would impose some performance hit which I was hoping to avoid with the current implementation. Let's see whether I could support your packages too... -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 257] XML error when using templates
http://bugzilla.wpkg.org/show_bug.cgi?id=257 Rainer Meier r.me...@wpkg.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Rainer Meier r.me...@wpkg.org --- Hi Falko, This looks slightly more complex than I've initially thought. Anyway I have re-written the XML reading functionality of WPKG in order to re-introduce XSLT processing which allows you to use constructs as in your firefox-ext-aardvark.xml. I really hope it's not breaking any packages or other XML readings. Currently I've done some quick test with plain XML files and using namespaces as you can find it in the new templates included in WPKG 1.2.1 RC. @Stefan Pendl: Would you mind running your test suite against WPKG 1.2.1-RC47 again? Changes 2011-11-21, v1.2.1-RC47 by Rainer Meier r.meier (at) wpkg.org FIX: Re-implemented XSL transforms when reading XML files. This allows some more special XML definitions which include content from other files or the use of XML templating. The implementation might require some more through testing to verify it does not breask any existing package definitions. Especially when using mixed package definition, some using namespaces and others who don't use. Fixes bug 257. Thanks to Falko Trojahn. br, Rainer -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
