I am trying to do this patch to the 2.2 version of zabbix, but i dont know to apply the patch to the frontends version 2.2 because there are differents .php elements that what are indicated for modify in the patch.
The url of the patch: https://support.zabbix.com/browse/ZBXNEXT-245
I really need this improvement to my front-ends, can anyone say me if is possible to apply this patch in zabbix 2.2, and how to proceed?
Thank you a lot.
You need some dev work, because you want to apply patch for Zabbix 1.8 to Zabbix 2.2 -> difference is two major releases.
Related
Some years ago, Mercurial | TortoiseHG could exchange data bidirectionally easy with at least 2 Big Brothers:
Subversion, using HGSubversion
Git, using HG-Git
Current (6.0 versions of family) state - the ordinary users have none:
hg-subversion is broken (extension can't be loaded), bundled with THG (Mercurial ???) extension not updated since 2019 hgsubversion: 6a6ce9d9da35 2019-04-19 (extraction from my TortoiseHg\extension-versions.txt), external SVN-bindings exist only for Python 2.7 (while py3-movement inside Mercurial is live and active)
hg-git got some big troubles, starting from THG 4.9 (manual patching of library.zip was required), on 6 version the situation has gotten better (no patching), but still unsatisfactory for the common user - installing Python 2.7 (for single-user) and using pip isn't The Right Way (tm)
Are there any comments, additions, clarifications, recommendations on how to do it (if what I am doing is wrong)?
Addition after some testing: special verson tortoisehg-6.0hggit-x64.msi from Matt Harbison at least allow using hg-git with ssh-transport (not http yet) and can be recommended for every-day usage by ordinary user.
So, as a current maintainer of hg-git and former contributor to hgsubversion, I think I can provide some context here.
Regarding hgsubversion, the short answer that it is either dead or — at best — extremely dormant. Personally, I have not interacted with a Subversion repository in years, and that's a common experience. No-one has been sufficiently motivated to fix bugs, keep it working, and — last, but not least — make it work with Python 3.
For hg-git, a period of semi-dormant state meant that the TortoiseHg maintainers stopped bundling it. We now keep up with Mercurial releases, and I've requested that they reverse that decision. I believe they bundle Dulwich, but as I don't use Windows, I can't say for sure. That said, it's quite reasonable to want to use hg-git with TortoiseHg, and if you run into any specific issues, I'd suggest you file a bug with them — or perhaps add a comment to the bug I linked earlier.
Generally speaking, you should be able to use 0.10.x version of hg-git with most versions of TortoiseHg, as I believe they bundle Dulwich. In that case, enabling the extension should be as simple as:
hg clone -u 0.10.x http://foss.heptapod.net/mercurial/hg-git /path/to/repo
And then adding the following to your .hgrc:
[extensions]
hggit = /path/to/repo/hggit
Once TortoiseHg moves to Python 3.x, the default branch of hg-git will work with it again.
EDIT: I was wrong; they don't bundle Dulwich, it seems. On the bug for this, one of the maintainers posted a link to a packaged installer that includes hg-git & Dulwich. The next release, 6.1, should fix this. Please consider testing the installer, and report to the TortoiseHg maintainers whether it works as expected.
EDIT²: Please note that only SSH works with that installer, as they ran into some issues bundling urllib3, which is necessary for HTTP support.
TortoiseHG 6.2
Bundled hg-git works (at least with GitHub), but for now only for https:// repos:
old worked ssh-access failed with complaining about my keys
With the new keypair (still RSA) and PageAnt-x64 (for THG-x64) I got both access-methods in game
I am installing the orion pep proxy but I think that I have not downloaded the correct version and I am having errors when using a local instance of KeyRock to validate and generate tokens.
I know that the latest version is 0.6.0 but i do not know how to complete the following command to obtain the last version:
./create-rpm.sh
Which is the difference between version and number?
Could you help me with this?
Thanks in advance
The idea of having those two numbers is to help the Release Engineer in debugging their releases, or changes they make to the packagin process itself. The "release number" indicates the version of the package, not the one of the software. E.g.: if you are packaging version 0.6.0, you usually will use release number 1; but, if you find out that you want to add some dependencies for the spec, or you want to update the package to change part of the packaging process, for example, and you try to replace the installed version with a new one, the system will claim the package is up-to-date; in that case, you increase the release number (as the software itself, that is, the Node.js files that constitute the PEP Proxy) hasn't change.
Hope this clarifies the behavior.
I got a site using Symfony 2.0 and want to upgrade it to last version of Symfony (2.4 from what I see on github).
I have already done one step: upgrade to 2.1. I fixed all issues and now I am ready to upgrade to 2.2 (I am not sure I could go to the current version directly). From my understanding, to do so, I need to retrieve the composer.json on github and add my own dependencies (only one). Is that right?
I tried to do it and it failed. Furthermore Symfony folder under vendor is empty after this attempt. I checked the composer.json for 2.2 and I do not see any symfony specified in it. Did I miss something?
Any help would be more than welcome :o)
ok the problem was only due to the fact that I was getting the composer.json from the wrong github repository. Be sure to use the one from the symfony-standard repository.
You can update from Symfony 2.0 to Symfony 2.4 directly. And yes, for it you need original composer.json file of Symfony 2.4 in symfony/symfony-standard repository and add to it your own dependencies if you have
I was using Hudson for doing my project builds and now planning to migrate to Jenkins.
The build server time is not in sync with the developer machines, and hence svn update does not work correctly. In Hudson, I was able to set the revision policy to HEAD, whereas its missing in Jenkins.
I searched a bit and saw that a Jira is created for this issue, but did not find a working solution for the problem.
I tried to manually install the Hudson subversion plugin in Jenkins, and the Revision policy option came up, but for some reason it caused an exception while setting the svn authentication info.
If anyone knows a solution to make this change in Jenkins, kindly reply.
Figured out. Append all SVN urls with #HEAD and svn update will happen from HEAD!
The plugin doesn't offer such feature but you might find useful this jira issue. There is a patch in the comments for that purpose. See Issue 1241.
Hudson ver. 1.353
Sventon ver. 2.14
I just cannot figure out how to configure Hudson to work with Sventon. It seems that the path format that Hudson expects from Sventon is not the format used by Sventon.
Any ideas?
Thanks.
UPDATE
Given an SVN repository with the name of windows, the Sventon URL path to the repository is http://dev-builder:8080/svn/repos/windows/list/
However, Hudson expects something like
http://dev-builder:8080/svn/repobrowser.svn?name=windows
Can anyone explain how this should be configured?
Regarding configuration, under the Source Code Management section of a job configuration, the Repository Browser dropdown lists Sventon 2.x as one of the options. (Not trying to be snarky, just making sure you're using the correct configuration.)
There are some Hudson bugs (search for sventon) in various states that might be related to your issue.
It's not clear to me whether this is a configuration problem or a Hudson bug. You could post the relevant configuration and both the paths that Hudson generates and Sventon expects. If it is a reproducible Hudson bug, reporting it to the Hudson bug database is the best bet.
Update with my experience: Under Source Code Management, I configured my Repository Browser to be Sventon 2.x and set the Repository URL to http://localhost:8080/svn and Repository Instance to windows. Hudson then listed changes with Sventon links as http://localhost:8080/svn/repos/windows/info?revision=XYZ
I think this means you should set:
Repository Browser to Sventon 2.x
Repository URL to http://dev-builder:8080/svn, and
Repository Instance to windows
Beware that the Hudson inline documentation for Sventon 2.x is wrong about the URLs that will be generated. It looks like this was never updated from 1.x.
You should however be aware that Sventon does not integrate well with projects that have multiple modules from different repositories. We for example use repositories A, B and C. And we've set our repository instance to A so that we can browse to things in that repository but not in any of the other.
Otherwise I really like Sventon as a svn browser.