L. Arnold's picture

Hi,

I have wanted to work up some variations on the Odoo Application system, and do so with TKLDEV pulling different versions of Odoo into a Current 18.1 build system.

Unfortunately I cannot at present even build the full current Odoo build.

Getting the following error in tkldev after starting Make:

E: Unable to locate package odoo-16
Traceback (most recent call last):
  File "/usr/bin/fab-install", line 660, in 
    cmd_install(
  File "/usr/bin/fab-install", line 297, in cmd_install
    installer.install(packages, ignore_errors)
  File "/usr/lib/python3.11/dist-packages/fablib/installer.py", line 340, in install
    self._install(packages, ignore_errors)
  File "/usr/lib/python3.11/dist-packages/fablib/installer.py", line 187, in _install
    raise Error(
fablib.installer.Error: Errors encountered installing packages
make: *** [/usr/share/fab/product.mk:577: build/stamps/root.build] Error 1

Exploring this in the Debian Packages I am not finding an odoo-16 package. I do find an odoo-18 and odoo-14 on this Debian Package Search Page, but this does not appear correct: https://packages.debian.org/search?keywords=odoo

in my l-arnold/tkl-nomadic-odoo respository I see in some of my old branches:

old versions of the TKL Odoo app relied on the version "nightly" builds when being built by TKLDEV. (for Instance Odoo 11 was built by TKL 15.x)

I tried emulating that just now but basically getting tied up having or not having odoo-16 as a package defined in the plan/main file.

I also by bringing forward also overlay/etc/apt folder structure to emulate that structure in odoo-11 but towards an odoo-14 build. https://www.odoo.com/documentation/14.0/uk/administration/install/packag...

No Luck so far.

Thoughts on how to get a "multi-version" Odoo system working?

Thoughts even on how to simply get the current TKL-Odoo app build in TKLDEV?

Thanks, Jeremy, in advance. Sorry for the trouble.

Landis

Forum: 
L. Arnold's picture

I realize this is not enabled as the old editing system is not in this TKL system anymore.
Jeremy Davis's picture

I'll reply properly to your OP below...

Also sorry for such a slow response. I've been away but am now back on board.

PS no trouble at all mate. I'm pretty sure that other than me (perhaps including me?) you are the longest serving TurnKey community member - and a lovely guy to boot! :) So you at least deserve a little of my time!

L. Arnold's picture

I am seeing certain "bullseye-backports" as well as "stable-backports" for odoo 14 and odoo 16 I am not seeing stable for other versions (unstable shown for 17 and 18) https://tracker.debian.org/pkg/odoo/news/?page=1 Not sure how to direct this properly in TKLDEV. Ideally I would be able to make calls to version 14, 15, 16 to work through an OpenUpgrade path.
L. Arnold's picture

been trying variously with odoo-14 and odoo-16 Getting the following error which seems to be many faceted:

Reading package lists... Done
N: Repository 'http://deb.debian.org/debian bookworm InRelease' changed its 'Version' value from '12.1' to '12.8'
touch build/stamps/bootstrap
unit_plans=""; fab-plan-resolve plan/main $unit_plans  --bootstrap=/turnkey/fab/bootstraps/bookworm --output=build/root.spec -D 'FAB_ARCH=amd64' -D 'FAB_HTTP_PROXY=http://127.0.0.1:3128' -D 'AMD64=y' -D 'RELEASE=debian/bookworm' -D 'DISTRO=debian' -D 'CODENAME=bookworm' -D 'DEBIAN=y'
Traceback (most recent call last):
  File "/usr/bin/fab-plan-resolve", line 674, in 
    cmd_plan_resolve(args.output, args.bootstrap, args.pool,
  File "/usr/bin/fab-plan-resolve", line 319, in cmd_plan_resolve
    resolve.resolve_plan(output_path, bootstrap_path,
  File "/usr/lib/python3.11/dist-packages/fablib/resolve.py", line 58, in resolve_plan
    subplan = Plan.init_from_file(plan_path, cpp_opts, pool_path)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/dist-packages/fablib/plan.py", line 238, in init_from_file
    return cls(cls._parse_plan_file(plan_file_path, cpp_opts), pool_path)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/dist-packages/fablib/plan.py", line 210, in _parse_plan_file
    processed_plan = cpp.cpp(path, cpp_opts)
                     ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/dist-packages/fablib/cpp.py", line 45, in cpp
    raise Error(" ".join(command), c.returncode, c.stderr)
fablib.cpp.Error: ('cpp plan/main -Ulinux -DFAB_ARCH=amd64 -DFAB_HTTP_PROXY=http://127.0.0.1:3128 -DAMD64=y -DRELEASE=debian/bookworm -DDISTRO=debian -DCODENAME=bookworm -DDEBIAN=y -I/turnkey/fab/common/plans', 1, 'plan/main:5:2: error: invalid preprocessing directive #apt\n    5 | #apt install -t bullseye-backports odoo-14\n      |  ^~~\n')
make: *** [/usr/share/fab/product.mk:577: build/stamps/root.spec] Error 1
root@tkldev .../products/(my build) # make clean

The Error there being on the most recent test:

I/turnkey/fab/common/plans', 1, 'plan/main:5:2: error: invalid preprocessing directive #apt\n    5 | #apt install -t bullseye-backports odoo-14\n    

However there should be one there as in the one referenced here: https://packages.debian.org/bullseye-backports/odoo-14

Probably not calling it correctly.

L. Arnold's picture

I was able to add some backport entries into the fab/bootstraps/bookworm to get the odoo-14 bullseye-backports package to load. Have not yet found an active odoo-16 package even though I thought
Now having an issue with a python package. Not sure if it is the same approach or different but will spend some time on this today.
Using a fork of turnkeylinux-apps/odoo in TKLDEV 18.1 (the fork allows me to test tweaks in Github). Ideally I will have a series of builds using, minimally, Odoo,14, Odoo 15, Odoo 16, Odoo 17 and Odoo 18 so that upgrade processes can be understood.
Jeremy Davis's picture

You note that you are building on v18.1 TKLDev. I assume that you are trying to build a v17.x Odoo build? If so, building a v17.x appliance on v18.x will require some tweaks. It might be easier to just build on a v17.x TKLDev?

If you want to persevere with your v18.1 TKLDev, then try running this first:

BRANCH=17.x RELEASE=debian/bullseye tkldev-setup

Note that will (should?) setup your TKLDev to build 17.x builds (Bullseye based). Having said that, it's not well tested so there is a risk things might break - and you may not be able to build anything on your existing TKLDev. If you do run that on TKLDev v18.1 and it fails, it'd be great if you can post back with any errors you hit. If it succeeds, I strongly suggest trying to build core before you do anything else (if core works, you should be good to go).

Also do you have backports enabled in your Makefile? Make sure that your Makefile has 'BACKPORTS=y' near the top - like the v18.x one does - note that you shouldn't need the 'BACKPORTS_PINS' line, but if you do want to include it, be sure that the package name matches (i.e. 'odoo-14').

Jeremy Davis's picture

Unfortunately Odoo 16 missed the Bookworm release. But it had been backported to Bookworm and that's were we installed it from for v18.0 (bookworm-backports Debian package version: 16.0.0+dfsg.2-2~bpo12+1). But it appears to be gone from backports now!?

On the page you linked to, I can see that the most recent (2024-06-25) upload of odoo-16 to bookworm-backports (stable-backports) was the same version we installed. And there is no mention of it being removed. TBH I would have expected there to be a note that it was and why?!

Even if we can get Odoo v16 (which I'm very confident we can - one way or another) I think that the options for getting earlier versions will be limited. As you note, the older Debian release has Odoo v14 - but not v15. However the Odoo source code appears to still have all versions all the way back to v5! So that's probably an option? And IIRC way back when Ken first developed our Odoo app - and you helped battle test it - we installed from source then too?

And as you know (and have almost certainly been frustrated by), we've iterated through a number of different install paths since. IIRC it went:

source install >> Odoo nightly apt repo >> Debian package

So install from source may be the way to go? And as I hinted above, it's likely your only option if you want to upgrade major Odoo version by major Odoo version (14 >> 15 >> 16). My only other concern would be Odoo 14 compatibility with the python version in v18.x (Python v3.11). Although seeing as v14 was packaged in Debian 11/Bullseye, worst case scenario you may have to start with a v17.0 appliance (python 3.9)? With some adjustment, TKLDev v18.x should still be able to build a suitable v17.x base for a source install. Perhaps you could even find the old code and we could update it (if/as required) so you can build a custom appliance?

L. Arnold's picture

Fixes outside of TKLDEV are outlined here for Odoo-17 though this seems to apply to Odoo-14 (at least) forward. (---------------) https://www.odoo.com/forum/help-1/importerror-no-module-named-pypdf2-138813 (---------------)
Jeremy Davis's picture

I'm not sure that that is a relevant issue?
L. Arnold's picture

It's been a bit since I was on this, but basically I had been able to get a build together that patched and which I could use in TKLDEV root-patched.. The issue was the final part of the Odoo.py was calling PyPDF2-utils and there were issues with how that was referenced in that version of PYPDF. (seemed that odoo was looking for PyPDF2-utils and the Release actually had PyPDF2-_utils (note the underline character before _utils). At some point that change entered into PYPDF2 and it seems many others had had similar issues. An earlier version (say before 1.26 in my recollection) was supposed to be compatible.

I Need to come back around to this. Will definitely read through related posts you made above.

Jeremy Davis's picture

TBH, I doubt that the pypdf issue is related to the use of dash vs underline. Python modules can not include a dash in their name (i.e.: "-"). It's a quirk of python and I forget the reason. So instead of a dash, python modules that have a dash in their name have it replaced with an underscore when used . So the 2 different names should be exactly the same thing.

I think the pypdf2 issue is more likely related to the messy history and state of pypdf/pypdf2. If you are interested in the details, have a read about the history of pypdf here. The long and short of it is that pypdf2 is no longer a thing and the project name is now "pypdf" (as it was originally).

My guess is that the actual issue is that whichever version of TurnKey you are using doesn't have pypdf2 available. Or perhaps it just doesn't but it isn't installed?

Actually, I just did a quick google and found this StackOverflow QA page discussing the issue and some ideas on fixing and working around it. Perhaps some of those ideas might help?

L. Arnold's picture

Thank you Jeremy,

My apologies also for delayed response. I don't always see these notifications, but appreciate your comments.


I was wanting to have an "up to date" TKL Linux build series (18.x) that I could then have variations of calling

  • Odoo 14
  • Odoo 15
  • Odoo 16

and perhaps Odoo 17, and perhaps again Odoo 18?

As it is right now I have TKL 16.1 running Odoo 14

I have done installs of TKL 17.1 running Odoo 14 but the package differential on the 2 of Odoo 14 was always blocking any sort of migration from 16.1 to 17.1 builds.

I have of course done an TKL 18.0 Odoo 16 install but basically was wanting to use that generation (TKL 18) to make a series of Migrations.

First would be using Odoo 14 with the Package/Addon Set that I have in my TKL 16.1 version.
Second would be using some workable Odoo 15 build (seems to need to come from Nightly on Branch 15 Odoo)
Third would be a TKLDEV built version of TKL 18 Odoo 16, wanting to be able to also load some other OCA Addons into the TKLDEV version (branch of Turnkey Odoo)

Same Logic would follow also building Odoo 17 and Odoo 18.

Anyway, that has been the goal for a long time. OCA's Open Upgrade requires upgrading one version at a time. It is the only generally known method of open source upgrading of Odoo Community.

Those were the goals anyway.

Branches are clearly somehow missing so need to figure out how to emulate that. Seems to be the Odoo Nightly process that was used back in TKL 13 and some of the development I have seen along the way.

All for now. Thank You!
Landis

PS, not quite sure how to make Line Breaks in this editor. using ---- to show some sort of a break. We should work on subjects and happy to help.

Jeremy Davis's picture

Perhaps we should take our Odoo appliance back to it's roots and install from source code via git for v19.0? Then continue with that - rather than chopping and changing.

The reason that we have changed so many times is that with ~100 appliances to maintain I've trying to make it easier to maintain or appliance. I knew that it would be a bit of a PITA for end users to update initially. But in my (previous) naivety, each time we changed the install method, I thought "this will be easier for both us and users to maintain down the track". Unfortunately that has not been the case at all and it has become something of a nightmare - for all of us...

So moving forward, I'm inclined to think that we should go back to a similar install method to what Ken used originally, back when he first developed it - source code via git. That will make the process that you are wanting much easier to do. It still won't be perfect, but I think it will be MUCH better!

Another thing that Anton has been looking at is installing Odoo via Docker (actually Podman, but essentially same thing). We still need to think a bit more about that but I suspect that that would be an even better way for both us and users like you to maintain it - and change Odoo versions. It needs more thought and work though...

When I next speak with Anton (hopefully later this week) I'll see how he's going with that and if it's ready (or close) I'll build you a copy to play with and give me some feedback.


Re line breaks - yeah formatting sucks heaps since we had to disable to the old editor. :( We are hoping to move our forums to a completely new platform sometime soon, but until then there are a couple of workarounds:

  • Select "plain text" from the "text format" dropdown when you publish/save your post. That won't allow any of the other formatting, but will at least maintain line breaks in your post text. Or;
  • Use html tags - i.e. write your post in "raw" html. You can only use a limited set of html, but these are the few most useful ones you can:
    • <p> - start of a paragraph (technically it should be closed with a </p> at the end of the paragraph, but it's not required)
    • <br> - single line break (within a paragraph)
    • <hr> - horizontal line (useful for separating unrelated parts of a post)
    • <pre> & </pre> - code block - note must have </pre> at the end - otherwise all text after the first <pre> will be formatted as code
    • <strong> & </strong> - bold - must be closed as per "pre" (above)
    • <i> & </i> - italic - close as per "pre"
    • <u> & </u> - underline - close as per "pre"

There are a few others too, but that's likely enough (perhaps more than you want/need). TBH though, selecting "plain text" is probably the easiest solution...

Add new comment