Olga Abdala | 7 May 2012 10:56
Favicon

Windows search on Windows 7

Hello,

As mentionned in the object, I want to know more about the Windows search on Windows 7.
I want to be able to search .xml files. I know that there is a box to check in the control panel, but that can be embarrassing for me since I'm moving about 20 computers from Windows XP to Windows 7.
 The aim would be to write a short installer that makes that possible. But the problem is that I don't know if there's any registry key that I could change in order to activate that without letting eveyone check the box in the control panel.
You can see the installers that were written for Windows XP, down here:






So, can anyone help me with that please?I really need it!
Your answers and suggestions are more than welcome!

Thanks in advance

-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
_______________________________________________
wpkg-users mailing list
wpkg-users <at> lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
Olga Abdala | 7 May 2012 15:48
Favicon

Script execution: failure. Exit code: 1 Windows 7

Hello,
 
My computer is  running Windows 7-64 bin Pro and WPKG Client 1.3.14-x64 and I am getting  this error: "Script execution: failure. Exit code: 1".
And when I check the system configuration, I find out that the WPKG Service is stopped.
 
Does anyone have an idea of what this might be?
Thanks!
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
_______________________________________________
wpkg-users mailing list
wpkg-users <at> lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
bugzilla-daemon | 8 May 2012 11:27
Favicon

[Bug 260] Feature Request - WPKG to automatically create variables

http://bugzilla.wpkg.org/show_bug.cgi?id=260

--- Comment #3 from Peter Hoeg <peterhoeg <at> 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/
bugzilla-daemon | 8 May 2012 11:53
Favicon

[Bug 260] Feature Request - WPKG to automatically create variables

http://bugzilla.wpkg.org/show_bug.cgi?id=260

--- Comment #4 from Rainer Meier <r.meier <at> 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/
bugzilla-daemon | 8 May 2012 14:33
Favicon

[Bug 260] Feature Request - WPKG to automatically create variables

http://bugzilla.wpkg.org/show_bug.cgi?id=260

--- Comment #5 from Rainer Meier <r.meier <at> 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/
bugzilla-daemon | 8 May 2012 16:49
Favicon

[Bug 260] Feature Request - WPKG to automatically create variables

http://bugzilla.wpkg.org/show_bug.cgi?id=260

--- Comment #6 from Peter Hoeg <peterhoeg <at> 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/
Olga Abdala | 9 May 2012 10:46
Favicon

Having a problem installing Visual C++ 2010 SP1

Hello,

I have a question concerning the silent installer of one of my WPKG packages, XLite 4.1.

While installing XLite, I get a message telling me that the package requires .NET Framework 4 and Visual C++ 2010 SP1, and if I click on OK, it installs the 2 packages by itself.
So I decided to put dependencies in the XLite installer for it to install the 2 packages without showing the small window with the message.
 The problem is that, with the dependencies, .NET Framework 4 gets installed without any problem, but Visual C++ 2010 SP1 doesn't for an unknown reason to me, which makes that XLite doesn't get installed neither.

Since XLite can install it, I would like to know if there's an option that I can put in the installer to allow XLite to install Visual C++2010, without even asking me to click on the OK Button.

Can anyone please tell me if there's a way?And if yes, which one?
Thanks!

-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
_______________________________________________
wpkg-users mailing list
wpkg-users <at> lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
Stefan Pendl | 9 May 2012 20:38
Picon

Re: Having a problem installing Visual C++ 2010 SP1

Am 09.05.2012 10:46, schrieb Olga Abdala:
>
> Since XLite can install it, I would like to know if there's an option
> that I can put in the installer to allow XLite to install Visual
> C++2010, without even asking me to click on the OK Button.
>
> Can anyone please tell me if there's a way?And if yes, which one?
> Thanks!
>

Are we talking about the VC++ runtime redistributable?

If so use the /? command line switch for the EXE and you will get a 
window showing the command line switches for the EXE.

--
Stefan P.

Top-posting:
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
Olga Abdala | 9 May 2012 21:03
Favicon

Re: Having a problem installing Visual C++ 2010 SP1

>Are we talking about the VC++ runtime redistributable?

Yes, that's it! I'll try it and let you know!Thanks !

On Wed, May 9, 2012 at 8:38 PM, Stefan Pendl <stefan.pendl.71 <at> gmail.com> wrote:
Am 09.05.2012 10:46, schrieb Olga Abdala:


Since XLite can install it, I would like to know if there's an option
that I can put in the installer to allow XLite to install Visual
C++2010, without even asking me to click on the OK Button.

Can anyone please tell me if there's a way?And if yes, which one?
Thanks!


Are we talking about the VC++ runtime redistributable?

If so use the /? command line switch for the EXE and you will get a window showing the command line switches for the EXE.


--
Stefan P.

Top-posting:
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
_______________________________________________
wpkg-users mailing list
wpkg-users <at> lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
_______________________________________________
wpkg-users mailing list
wpkg-users <at> lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
bugzilla-daemon | 10 May 2012 00:23
Favicon

[Bug 260] Feature Request - WPKG to automatically create variables

http://bugzilla.wpkg.org/show_bug.cgi?id=260

Rainer Meier <r.meier <at> wpkg.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |FIXED

--- Comment #7 from Rainer Meier <r.meier <at> wpkg.org>  ---
Hi Peter,

I was thinking a bit about your request to support a config file which
overrides the defaults. Initially I was thinking about implementation of some
kind of "include" statement in config.xml so we could point it to
"config.custom.xml" and then read it if it exists and ignore it if it doesn't
exist.

But actually I think it should not be required. First of all you will not have
to update config.xml for a new WPKG version usually as WPKG perfectly works
with the old config.xml.
If you like to merge to the latest version it makes sense to include the
comments as well, so you should merge anyway.

Adding include capability adds a couple of nasty if/else checks for file
existence which might slow down startup, especially on slow network
connections.

So currently I believe that such a feature is not generally required. Note that
you could also achieve the same using XML transforms (which are applied by
WPKG) in order to include additional config files. So XML already supports
including additional files inherently. So if you want to move some of your
params to an external file just use XSLT to include your configuration file. So
on next release you could simply use the default config.xml and add one single
line to it in order to include your customization.

Small note: I've just checked in 1.3.1-RC12 but it's unrelated to this
discussion as I've just added another feature to support regular expression
matching for registry value equal checks.

Also I am changing this report to "fixed" rather than "wontfix" as some
modification has actually been implemented.

--

-- 
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/

Gmane