The base image is ubuntu, I believe, so you'll just have to add steps to the GitHub Actions workflows to apt-get install whatever.
On Fri, Apr 24, 2026 at 3:22 PM Andor Molnár <[email protected]> wrote: > > Somewhere here perhaps … > > https://github.com/apache/zookeeper/tree/master/.github/workflows > > Andor > > > > > On Apr 24, 2026, at 10:04, Enrico Olivelli <[email protected]> wrote: > > > > Il giorno ven 24 apr 2026 alle ore 16:49 Yurii Palamarchuk < > > [email protected]> ha scritto: > > > >> Hi everyone, > >> > >> To run the website tests, we must install the missing dependencies on the > >> remote runner. Can anyone help with this? > >> > >> > >> https://github.com/apache/zookeeper/actions/runs/24838423432/job/72730186177?pr=2373#step:5:7082 > > > > > > > > I would say that you have to update the CI job to setup the tools you need > > > > Enrico > > > > > >> > >> > >> Regards, > >> Yurii > >> > >> On Fri, Apr 17, 2026 at 4:27 PM Yurii Palamarchuk < > >> [email protected]> wrote: > >> > >>> Sure. I'm opening a PR now! > >>> > >>> On Thu, Apr 16, 2026 at 3:31 PM Andor Molnár <[email protected]> wrote: > >>> > >>>> Thanks David. > >>>> > >>>> Totally agree. > >>>> Can we move on with the new website Yurii? > >>>> What do you need to open pull request? What are the open questions? > >>>> > >>>> Andor > >>>> > >>>> > >>>> > >>>> > >>>>> On Apr 16, 2026, at 02:07, Dávid Paksy <[email protected]> wrote: > >>>>> > >>>>> Hi All, > >>>>> > >>>>> In the meantime the Apache Phoenix team merged the new website, you > >> can > >>>> see > >>>>> it here: https://phoenix.apache.org/. > >>>>> > >>>>> On the other day I had to wait for an hour and I only had my > >> smartphone > >>>> on > >>>>> me and I was able to read ZooKeeper documentation from the redesigned > >>>>> website and learn from it. While not impossible, it would be harder to > >>>> do > >>>>> this with the current documentation pages. > >>>>> > >>>>> Regarding security vulnerabilities, actually the current ZooKeeper > >>>> website > >>>>> page contains Bootstrap v4.1.3 which is end-of-life and contains one > >>>> known > >>>>> XSS vulnerability and jQuery v3.3.1 which contains 4 known security > >>>>> vulnerabilities, including the critical CVE-2019-11358 (Prototype > >>>>> Pollution) and multiple Cross-Site Scripting (XSS) issues. > >>>>> > >>>>> Personally I'd vote for technical modernization here to fix the > >> current > >>>>> CVE-s and because this also makes the documentation more easy to > >>>> approach. > >>>>> I can also offer my help in the website dependency updates. > >>>>> > >>>>> Best Regards, > >>>>> Dávid > >>>>> > >>>>> > >>>>> Yurii Palamarchuk <[email protected]> ezt írta (időpont: > >>>> 2026. > >>>>> ápr. 2., Cs, 10:48): > >>>>> > >>>>>> Here is the code: > >>>>>> > >>>>>> https://github.com/yuriipalam/zookeeper-website > >>>>>> > >>>>>> It's not a PR for the zookeeper repo yet. > >>>>>> > >>>>>> Regards, > >>>>>> Yurii > >>>>>> > >>>>>> On Thu, Apr 2, 2026 at 3:33 AM Christopher <[email protected]> > >>>> wrote: > >>>>>> > >>>>>>> Where is the code for the react version of the site? > >>>>>>> > >>>>>>> On Wed, Apr 1, 2026 at 2:53 AM Dávid Paksy <[email protected]> > >>>> wrote: > >>>>>>>> > >>>>>>>> Hi All, > >>>>>>>> > >>>>>>>> To have a sense about maintenance need, you can see the JavaScript > >>>>>>>> dependabot PR-s in the HBase repo here: > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>> > >> https://github.com/apache/hbase/pulls?q=is%3Apr+author%3Aapp%2Fdependabot+is%3Aclosed+label%3Ajavascript > >>>>>>>> > >>>>>>>> So yes, it requires some maintenance. > >>>>>>>> I'd also recommend to enable Dependabot dependency updates as they > >>>> are > >>>>>>>> helpful. But if not, running 'npm audit fix' manually is rather > >> easy. > >>>>>>>> > >>>>>>>> For how the sources look you can check here what Yuri implemented > >> for > >>>>>>> HBase: > >>>>>>>> > >>>>>>>> https://github.com/apache/hbase/tree/master/hbase-website > >>>>>>>> > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Dávid > >>>>>>>> > >>>>>>>> Christopher <[email protected]> ezt írta (időpont: 2026. márc. > >>>> 31., > >>>>>> Ke > >>>>>>>> 22:47): > >>>>>>>> > >>>>>>>>> It's also pretty easy to use dependabot on the website repo to > >> check > >>>>>>>>> for updated site dependencies. That should be easy to handle if > >> the > >>>>>>>>> assets are included in the repo itself, and not loaded from other > >>>>>>>>> domains, as per the ASF policy > >>>>>>>>> (https://privacy.apache.org/policies/website-policy.html) > >>>>>>>>> > >>>>>>>>> On Tue, Mar 31, 2026 at 11:05 AM Yurii Palamarchuk > >>>>>>>>> <[email protected]> wrote: > >>>>>>>>>> > >>>>>>>>>> I know about it, and we're not affected by it. This vulnerability > >>>>>>> allows > >>>>>>>>>> attackers to bypass the React's server authentication, but we > >> don't > >>>>>>> use > >>>>>>>>> it. > >>>>>>>>>> We don't have any runtime node.js server, so we aren't affected > >> by > >>>>>>> any of > >>>>>>>>>> these. > >>>>>>>>>> > >>>>>>>>>> Best Regards, > >>>>>>>>>> Yurii > >>>>>>>>>> > >>>>>>>>>> On Tue, Mar 31, 2026 at 4:38 PM Patrick Hunt <[email protected]> > >>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> this is from december :-) > >>>>>>>>>>> > >>>>>>> > >>>> https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182 > >>>>>>>>>>> > >>>>>>>>>>> Patrick > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Mar 31, 2026 at 7:27 AM Yurii Palamarchuk < > >>>>>>>>>>> [email protected]> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> You are right, there are almost no concerns. The entire website > >>>>>>> is > >>>>>>>>>>> static, > >>>>>>>>>>>> only the server providing the assets is running. The only issue > >>>>>>>>> could be > >>>>>>>>>>> if > >>>>>>>>>>>> some node.js package becomes vulnerable, allowing hackers to > >>>>>> run > >>>>>>>>> scripts > >>>>>>>>>>> on > >>>>>>>>>>>> users' machines, but this scenario is highly unlikely. > >>>>>>>>>>>> > >>>>>>>>>>>> Best Regards, > >>>>>>>>>>>> Yurii > >>>>>>>>>>>> > >>>>>>>>>>>> On Tue, Mar 31, 2026 at 4:22 PM Patrick Hunt <[email protected] > >>>>>>> > >>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> What are the security implications of running React on the ZK > >>>>>>>>> website? > >>>>>>>>>>> Is > >>>>>>>>>>>>> that going to mean additional concerns (eg cve tracking as > >>>>>>> well as > >>>>>>>>>>> source > >>>>>>>>>>>>> security bugs, tracking the "latest react" version and so > >>>>>>> on...). I > >>>>>>>>>>>>> believe right now we just have very simple static pages which > >>>>>>>>> require > >>>>>>>>>>>> very > >>>>>>>>>>>>> minimal oversight? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Patrick > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Tue, Mar 31, 2026 at 7:17 AM Yurii Palamarchuk < > >>>>>>>>>>>>> [email protected]> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks everyone for your reviews! > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The only approach I considered for updating the > >>>>>> documentation > >>>>>>>>> version > >>>>>>>>>>>> is > >>>>>>>>>>>>> a > >>>>>>>>>>>>>> manual one. It looks like this: > >>>>>>>>>>>>>> 1) Checkout to the `website` branch. > >>>>>>>>>>>>>> 2) Build the latest change for the current version, right > >>>>>>> before > >>>>>>>>> the > >>>>>>>>>>>>>> update. > >>>>>>>>>>>>>> 3) Move the build to `public/released-docs/` and rename the > >>>>>>>>> directory > >>>>>>>>>>>> to > >>>>>>>>>>>>>> the corresponding version. > >>>>>>>>>>>>>> 4) Update the `CURRENT_VERSION` constant, so now it matches > >>>>>>> the > >>>>>>>>> new > >>>>>>>>>>>>>> version. > >>>>>>>>>>>>>> 5) Open a PR. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The Java API docs are built by maven as far as I can tell, > >>>>>> so > >>>>>>>>> it's > >>>>>>>>>>> not > >>>>>>>>>>>>>> related to the website actually. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regarding the automatization of this process, I've never > >>>>>> done > >>>>>>>>>>> anything > >>>>>>>>>>>>> like > >>>>>>>>>>>>>> this before. Therefore, if you have any suggestions - I'm > >>>>>>> open to > >>>>>>>>>>> it, I > >>>>>>>>>>>>>> think it should be possible since the workflow is not > >>>>>>> complex at > >>>>>>>>> all. > >>>>>>>>>>>>> Most > >>>>>>>>>>>>>> likely a small bash script could be enough. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Best Regards, > >>>>>>>>>>>>>> Yurii > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Tue, Mar 31, 2026 at 3:09 AM Andor Molnár < > >>>>>>> [email protected]> > >>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Exactly. My 2 cents are: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 1. Storing the entire website at a single location is > >>>>>>>>> desirable. > >>>>>>>>>>>> Given > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>> proposed > >>>>>>>>>>>>>>> technology changes there’s no clear separation possible > >>>>>>> without > >>>>>>>>>>>>>> duplicating > >>>>>>>>>>>>>>> website core logic components which will be a maintenance > >>>>>>>>> nightmare > >>>>>>>>>>>> in > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>> long term. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 2. Separate ‘website’ branch or versioned branches. As > >>>>>>> Patrick > >>>>>>>>>>>>> mentioned > >>>>>>>>>>>>>>> the docs are versioned and the ability to accompany doc > >>>>>>> changes > >>>>>>>>>>> with > >>>>>>>>>>>>>>> code changes in the same PR is a big advantage. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Andor > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Mar 30, 2026, at 19:52, Patrick Hunt < > >>>>>>> [email protected]> > >>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> One reason I remember the docs/api/etc... are part of > >>>>>> the > >>>>>>>>> source > >>>>>>>>>>> is > >>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>> they are versioned along with it. PRs -- doc changes > >>>>>>> along > >>>>>>>>> with > >>>>>>>>>>>> code > >>>>>>>>>>>>>>>> changes also part of the release process. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Patrick > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Mon, Mar 30, 2026 at 5:39 PM Christopher < > >>>>>>>>> [email protected] > >>>>>>>>>>>> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I think it looks great, but I would really like to see > >>>>>>> the > >>>>>>>>> SCM > >>>>>>>>>>>>> source > >>>>>>>>>>>>>>>>> for this new site, so I can understand the > >>>>>>> maintenance/build > >>>>>>>>>>>>> workflow > >>>>>>>>>>>>>>>>> for it, before I'd have any useful opinion other than > >>>>>>>>> regarding > >>>>>>>>>>>>>>>>> aesthetics. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I definitely concur with moving the docs out to the > >>>>>>> site to > >>>>>>>>>>>>> centralize > >>>>>>>>>>>>>>> it. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Fri, Mar 27, 2026 at 3:03 PM Yurii Palamarchuk > >>>>>>>>>>>>>>>>> <[email protected]> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Thanks for your comment, Patrick. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Why React? > >>>>>>>>>>>>>>>>>> Building a website nowadays is not just HTML + CSS, > >>>>>>> because > >>>>>>>>>>> doing > >>>>>>>>>>>>> it > >>>>>>>>>>>>>>> this > >>>>>>>>>>>>>>>>>> way turns the developer experience into a nightmare. > >>>>>>> With > >>>>>>>>> React > >>>>>>>>>>>> we > >>>>>>>>>>>>>>>>>> effortlessly have consistent UI components across all > >>>>>>>>> pages, > >>>>>>>>>>>>>> including > >>>>>>>>>>>>>>>>>> buttons, tables, markdown rendering, colors, and much > >>>>>>>>> more. We > >>>>>>>>>>>> also > >>>>>>>>>>>>>> add > >>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> interactivity much more easily with React. A static > >>>>>>> website > >>>>>>>>>>>> doesn't > >>>>>>>>>>>>>>> mean > >>>>>>>>>>>>>>>>> it > >>>>>>>>>>>>>>>>>> lacks interactivity; it often has significant > >>>>>>>>> interactivity, > >>>>>>>>>>>>>> especially > >>>>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>> the documentation section. The difference is that we > >>>>>>> don't > >>>>>>>>> need > >>>>>>>>>>>> any > >>>>>>>>>>>>>>>>> runtime > >>>>>>>>>>>>>>>>>> environment, we just return the files generated at > >>>>>>> build > >>>>>>>>> time, > >>>>>>>>>>>>> which > >>>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>>>> ultimately just HTML, CSS, and JS. The website also > >>>>>> has > >>>>>>>>> dark > >>>>>>>>>>> mode > >>>>>>>>>>>>>>>>> support, > >>>>>>>>>>>>>>>>>> search in the documentation, smooth transitions > >>>>>> between > >>>>>>>>> pages > >>>>>>>>>>> (no > >>>>>>>>>>>>>> hard > >>>>>>>>>>>>>>>>>> reload), so it gives smooth and better user > >>>>>> experience > >>>>>>>>>>> overall. I > >>>>>>>>>>>>>> hope > >>>>>>>>>>>>>>>>> this > >>>>>>>>>>>>>>>>>> answers your question. Moreover, the website will > >>>>>> work > >>>>>>>>>>> absolutely > >>>>>>>>>>>>>> fine > >>>>>>>>>>>>>>>>> even > >>>>>>>>>>>>>>>>>> for those who have JS disabled, this is called > >>>>>>> progressive > >>>>>>>>>>>>>> enhancement. > >>>>>>>>>>>>>>>>>> Initially, the server returns HTML and CSS. The > >>>>>> browser > >>>>>>>>> renders > >>>>>>>>>>>>> them > >>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>> tries to fetch the JS files. If it doesn't succeed, > >>>>>> the > >>>>>>>>> page > >>>>>>>>>>>>> remains > >>>>>>>>>>>>>>>>>> accessible, though it obviously lacks interactivity. > >>>>>> I > >>>>>>> hope > >>>>>>>>>>> this > >>>>>>>>>>>>>>> answers > >>>>>>>>>>>>>>>>>> your questions, if not, feel free to ask more about > >>>>>> it! > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Is it hard for ZK devs to update the content? > >>>>>>>>>>>>>>>>>> Not at all! I tried to make it so the learning curve > >>>>>>> for > >>>>>>>>> non-JS > >>>>>>>>>>>>> devs > >>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>> almost 0. For the documentation you still just need > >>>>>> to > >>>>>>>>> edit the > >>>>>>>>>>>> MDX > >>>>>>>>>>>>>>>>>> (Markdown Extended) files and run the build command. > >>>>>> I > >>>>>>> will > >>>>>>>>>>> also > >>>>>>>>>>>>> add > >>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>> bash > >>>>>>>>>>>>>>>>>> script to automate the build process. For the landing > >>>>>>>>> pages, > >>>>>>>>>>> you > >>>>>>>>>>>>>> still > >>>>>>>>>>>>>>>>>> mostly only need to modify the markdown files. Only > >>>>>> the > >>>>>>>>> main > >>>>>>>>>>> page > >>>>>>>>>>>>>> isn't > >>>>>>>>>>>>>>>>>> markdown, modifying something small wouldn't be a > >>>>>>> problem. > >>>>>>>>> In > >>>>>>>>>>> the > >>>>>>>>>>>>>> worst > >>>>>>>>>>>>>>>>>> case, if something more complex is required, you can > >>>>>>>>> handle it > >>>>>>>>>>>> with > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> AI. > >>>>>>>>>>>>>>>>>> Nevertheless, the website hasn't been updated for > >>>>>>> years, > >>>>>>>>> so it > >>>>>>>>>>>>>> wouldn't > >>>>>>>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>> a big loss :) > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>> Yurii > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Fri, Mar 27, 2026 at 4:19 PM Patrick Hunt < > >>>>>>>>> [email protected] > >>>>>>>>>>>> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On Fri, Mar 27, 2026 at 3:32 AM Yurii Palamarchuk < > >>>>>>>>>>>>>>>>>>> [email protected]> wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Hi there, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I am proposing an upgrade to the ZooKeeper website > >>>>>>> and > >>>>>>>>>>>>>>>>> documentation. We > >>>>>>>>>>>>>>>>>>>> are moving to a modern React.js stack, which allows > >>>>>>>>> landing > >>>>>>>>>>>> pages > >>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>> versioned documentation to live in a single > >>>>>>> application > >>>>>>>>>>> sharing > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> same > >>>>>>>>>>>>>>>>>>> UI > >>>>>>>>>>>>>>>>>>>> components, libraries, colors, etc. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> The plan is to move all website and documentation > >>>>>>> source > >>>>>>>>> code > >>>>>>>>>>>> to > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> website branch and remove the zookeeper-docs Maven > >>>>>>>>> project > >>>>>>>>>>> from > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> master > >>>>>>>>>>>>>>>>>>>> branch. This decouples the Node/JS build > >>>>>> environment > >>>>>>>>> from the > >>>>>>>>>>>>> core > >>>>>>>>>>>>>>>>> Java > >>>>>>>>>>>>>>>>>>>> repository. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Versioned docs will be managed via archived folders > >>>>>>>>> within > >>>>>>>>>>> the > >>>>>>>>>>>>>>>>> website > >>>>>>>>>>>>>>>>>>>> branch. Documentation updates would move from > >>>>>> master > >>>>>>> to > >>>>>>>>> PRs > >>>>>>>>>>>>> against > >>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> website branch. Also I'm not planning to keep the > >>>>>>> app as > >>>>>>>>> a > >>>>>>>>>>>> maven > >>>>>>>>>>>>>>>>> project, > >>>>>>>>>>>>>>>>>>>> since it's fully JS based. To keep it simple, I > >>>>>> will > >>>>>>>>> write a > >>>>>>>>>>>> bash > >>>>>>>>>>>>>>>>> script > >>>>>>>>>>>>>>>>>>>> that installs the dependencies, runs the tests, and > >>>>>>> the > >>>>>>>>>>> build. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> What do you think about moving the docs out of > >>>>>>> master to > >>>>>>>>>>>>> centralize > >>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> site? > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Preview: https://zookeeper-website.vercel.app/ > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Looks pretty slick - nice update and visual refresh! > >>>>>>>>> Question > >>>>>>>>>>>>>> though - > >>>>>>>>>>>>>>>>> why > >>>>>>>>>>>>>>>>>>> React? This is a static website, what are the > >>>>>> pro/con > >>>>>>> of > >>>>>>>>> React > >>>>>>>>>>>>>> based? > >>>>>>>>>>>>>>>>> Can > >>>>>>>>>>>>>>>>>>> you explain the impact on common use cases like > >>>>>> making > >>>>>>>>>>> updates? > >>>>>>>>>>>> ZK > >>>>>>>>>>>>>>> team > >>>>>>>>>>>>>>>>>>> includes a number of people, not all of whom might > >>>>>>> know > >>>>>>>>> React, > >>>>>>>>>>>> how > >>>>>>>>>>>>>>> hard > >>>>>>>>>>>>>>>>>>> will it be for them to make changes? Impact on the > >>>>>>> release > >>>>>>>>>>>>> process? > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Patrick > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>> Yurii Palamarchuk > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>>> > >> >
