When a new Odoo version is released, the displayed version in the
Windows NSIS installer has to be manually updated.
With this commit, the displayed version is computed from the release.py
file.
Part-of: odoo/odoo#78386
Quick fix that need to be automated.
Closes#77981closesodoo/odoo#77994
X-original-commit: 0a07ddbc750e561b63f6f12568baa66eba7c3ba2
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When using the windows installer in French language, the `Hôte` label
used to configure postgresql server does not display correctly.
The LangString documentation does not specify how to use the special
characters but after some tests, specifying a BOM for the nsi file seems
to be the way to go.
closesodoo/odoo#65370
X-original-commit: 3d0871d1d5895f0f04175f2633344f2f1b05a081
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Up to Odoo 13.0, the windows setup is 32 bits and embeds an old
postgresql 9.5 32 bits version too.
With this commit, the postgresql server is no longer embedded in the
resulting setup file. Instead, if the user choose to install the
postgresql server, the 12.4 version is downloaded from the official site
(version 10.14 in the case of a 32 bits windows).
Also, the Python target achitecture is choosen based on the Windows
system on which Odoo is installed.
This imply changes on the KVM images used to build the installer:
- The Windows system on the KVM as to be 64 bits.
- A 32 bits WinPython version must be in `c:/odoobuild/WinPy32`
- A 64 bits WinPyhton version must be in `c:/odoobuild/WinPy64`
A little bit of cleaning also comes with this commit to get rid of the
old `openerp` references.
closesodoo/odoo#57727
X-original-commit: c47d7c67066ff15602b16f18c4c3acebfd3a2755
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
As this file was only used as a one shot for the windows pacakging, it
can be removed from the code.
closesodoo/odoo#55307
X-original-commit: 19b44653fef85a851239c656b1fdf4798ab83f34
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
At 795c7b0a94 the external dependencies was changed from trying
to import 'ldap' to checking than 'pyldap' package was installed.
The problem is that pyldap is a unmaintained library that should no
longer be used, as explained on the package page:
https://pypi.org/project/pyldap/
"The pyldap fork was merged back into python-ldap, and released as
python-ldap 3.0.0."
Having pyldap version >= 3.0 installs python-ldap automatically and
will not cause any issue.
The Debian control file package name is adapted to use the latest.
The "ldap" externalm dependency defined in __manifest__.py will cause
pkg_resources.get_distribution() to fail in both case ("python-lap" or
"pyldap"), but the "import" fallback will succeed. For that reason, the
log warning is turned into a log info.
closesodoo/odoo#43769
Note: This library should be replaced by the pure python "ldap3" library.
X-original-commit: 1afd0ccf20881ba97e3c07dffb33e9a3a0b2cda4
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When building the MS Windows package, the PYTHON_VERSION variable is not
used and the WinPython path is hard coded in the Makefile and NSI file.
This prevent the usage of a newer version of Python.
With this commit, the PYTHON_VERSION is used to compute the WinPython
Python directory. That way, this directory can be derived from
package.py command line argument --vm-winxp-python-version.
Also the less windows binaries are not packaged anymore.
closesodoo/odoo#39821
X-original-commit: ac90d8584f99e24aed931eb5186c360f9dfbf399
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Packaging oversight, the displayed version in the installer window was still
12.0.
closesodoo/odoo#38486
X-original-commit: c5bd1a4f9730064f53ff633592dbf83ca7c1e4f7
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Recommended by GitHub's repository alerts.
We normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 11.0 that would be Debian 9
(stretch) and thus Jinja 2.8 (with security backports).
However Jinja2 before 2.10.1 suffers from a few issues that could lead
to crashes of Odoo processes.
It seems it's worth an exception to our rule for pip users, similarly to
previous bump up at d2605bccdb.
closesodoo/odoo#32601
Signed-off-by: Christophe Simonis <chs@odoo.com>
Commit cf853a785b removed all yml tests
and the yml import engine from Odoo forever, however PyYAML remains a
dependency even though it's not used anymore.
This commit removes any reference to this lib that could be found.
closesodoo/odoo#27563
When building the Windows installer, a virtual machine is used with
prepackaged python modules.
With this commit, the packaging script will try to install on the
virtual machine the python packages specified in requirements.txt.
Each package is installed individually, that way, if an install fails,
the install of the other packages continues.
At the end of the process, successfully packages are listed so that they
will appear in the build log files.
Also, the Makefile was cleaned in this commit (removal of py2exe stuffs).
Nsis installer was installing the wrong MS Visual C++ redistributable
file. Python 3.6 needs MS Visual C++ 2015 redistruibutable files.
Also, Nsis now differentiate Windows architecture for the nssm service
and the MS C++ redist.
Purpose:
The psycogreen module is unmaintained. Last source update was in
2015 and last pypi package was in 2012. Odoo only use a small
part of the psycogreen module that could be written directly in
the odoo code. This commit reproduce the small function from
psycogreen used in ODoo and remove all depencies from it.
Also the copyright and license are honored and the documentation
is updated accordingly.
pypi pckage: https://pypi.python.org/pypi/psycogreen
bitbucket repos: https://bitbucket.org/dvarrazzo/psycogreen/
Purpose: for multiple reasons (bytecode change in python 3.6,
missing files for some packages, py2exe is unmaintained
...) the py2exe solution cannot be used anymore.
Odoo for windows will now use a portable Python that
will be shipped with the Windows installer.
For that purpose, a Winpython 3.6.2 is used.
In order to build the Windows installer, a Winpython dir
with all the Odoo requirements fullfilled, must exists on
the build system (qemu-kvm VM).
* nsis installer:
- Only the python dir is used to avoid packaging too much stuffs
- better compression level
- starts the Odoo service using nssm
- bump to V11
* change the default win10 build vm path
* print a warning when uncomplete addon move
* try to force remove of addon path:
when the addons are moved to Odoo/addons, it happens that the
destination already exists. In that case, the source addon was not
deleted, resulting in a uneeded file duplication.
* fix version string to avoid invalid chars in windows service
* Add requirements adpated for WinPython
* package.py now shows the traceback when a build fails
* verify that a file exists before publishing
* debuild now creates an .xz file instead of .gz
* package: use logging module
* kvm CPU that works with older versions.
* fix a pexpect encoding bug
* fix the version to remove special chars '~' which is not appreciated
by windows services
[REM] win32setup: Remove win32 python service
Purpose:
Before this commit, the win32 service was managed by an executable
builded from those two files with the help of py2xe.
The win32 service is now managed by nssm which starts Odoo and therefore, those
files are not needed anymore.
The use of an entry point was considered in order to provide
an `odoo` command in the path for the packages users, but the
generated entry point will first check that all the things in
install_requires were provided in a not bright way: it'll check
that it matches a distribution name. This does not work because
python-chart does not have the distrubtion name "pychart" which
is provided by the python-pychart package in debian jessie. Same
for suds-jurko which is provided by python-suds in debian stretch
but does not have the distribution name "suds".
Also, adapted the packages tests to these cli changes.
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
The openerp-server.conf now generates the bin_path record, in order
to resolve calls to external binaries served in the thirdparty dir.
Adpated report.py to use find_in_path and not directly which.
Christophe Monniez