Is there a particular version of JRuby in the project timeline when default will be changed to 1.9?
JRuby 1.7. And here's the rest of my 30 characters.
There is no set plan for that yet, but if there is enough push from the users, I bet Charlie and Tom can be persuaded. I opened http://bugs.jruby.org/6387 for this topic. There is probably enough time for it before the 1.7 release.
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
How can I know the latest protractor version that can work with 51 version chrome?
Wish if there is any easier way to figure that out but there is none. Its at best trial and error effort.
The only way that i can think of is going by the chrome release dates Here (if you trust wikipedia).
Then portractor release dates here.
Start from a protractor release that was just prior to Chrome52 release date and try it.
From the question, looks like you dont have the webdriver information either. The drivers need to be downloaded for that particular Chrome version. See if they are available here. Its again trial and error based on the date of driver release you find in there.
If not from the starting of time, little bit of Webdriver version to Chrome version information can be found here.
To download a specific version of webdriver, use
npx webdriver-manager clean
npx webdriver-manager update --versions.chrome=76.0.3809.68
Having said all that, i am not optimistic at all that you are looking at an easy task :(
Good luck...
When trying to use ChromeDriver 2.31 in CentOS 7 I get the following error:
version 'GLIBC_2.18' not found
ChromeDriver developers confirm that glibc library dependency has been promoted to 2.18, while CentOS 7 has version 2.17.
Related links:
Announcing ChromeDriver 2.31
ChromeDriver Issue #1894
ChromeDriver Issue #1772
Is there a way to make it work without switching to another OS?
The Chromium developers are aware of the issue and working on a fix:
glibc dependency creeped up to 2.18 in M61, breaking EL7 support
During the switch to libc++, they accidentally referenced a new symbol from the glibc version in their sysroot, __cxa_thread_atexit_impl. But this was only introduce in glibc 2.18, and Red Hat Enterprise Linux 7 only has version 2.17. Apparently, for their use cases, libc++ works well enough without this symbol (similar to libstdc++ from GCC), so they just need to tweak their build not to use it, and Chromium (and thus Chrome Driver and Chrome unstable) should work again soon.
As an end user or even software developer who cannot rebuild the software in question (or maybe just does not want to invest such a non-trivial effort), there is little one can do about such glibc version dependencies. Therefore, it is pretty much a requirement that all builds happen against a build environment which matches the oldest operating system version one wants to support.
Dependency to GLIBC 2.18 have been removed in Chromedriver 2.32, so that version is safe to use on Centos 7.
Back to chromedriver 2.30 and it work with google-chrome-stable.x86_64 0:60.0.3112.113-1 on CentOS 7
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.
I was wondering which steps are the best to upgrade hudson and the plugins.
I'm running 1.347 at the moment. I once tried to update which resulted into a mess because some plugins were incompatible.
Also i want to delete some plugins is it appropriate to just delete the hpi file? It would be nice to know how other people do this step and in which order.
Should i first upgrade hudson and then plugin by plugin?
And if a plugin breaks something downgrade it again? It seems to be a lot of work.
Or is there any easy way?
Also is it enough to save all the xml configuration files in case something breaks that i can recover?
Thanks in advance.
My solution is overkill, but I was burned twice (once by a Hudson bug and once by plugin incompatibilities) and learned my lesson.
I have Hudson installed on a VM with the same plugins as my production instance and a couple of simple builds. When I feel it's time to upgrade, or want to check out the latest release, I upgrade Hudson on the VM and verify that it starts up and can do builds. I only upgrade the production system that all of our developers use after I've upgraded my test system. I generally don't do exhaustive tests on my test system; it's enough to make sure the combination of upgraded Hudson and plugins starts up properly.
When upgrading either the VM or the main system, I upgrade all the plugins, then upgrade Hudson itself and restart. (Since I have a test system, I'm not particularly worried about doing things step by step.)
I came up with my process before Hudson introduced downgrade support. I still use this process because it's important to me to have confidence that an upgrade is not going to break the system that other developers use. This setup also allows me to have an experimental setup that's separate from the main Hudson system, which I find useful.
I usually update Hudson first, then the plugins.
The recent versions of Hudson have some support for this process:
the Hudson 1.376 added downgrade support for the core and plugins.
That means after upgrading a plugin, you have a button which allows you to downgrade to the previous installed version if needed.
the Hudson 1.369 Avoid error with invalid or null primary view, such as in upgrade from older Hudson
And the upcoming Hudson 1.387 will avoid littering HUDSON_HOME with atomic *.xml files, which should make the backup process of critical config files that much easier.
(Currently, with an Hudson 1.386, I see under HUDSON_HOME:
com.mtvi.plateng.hudson.ldap.LdapMailAddressResolver.xml
config.xml hudson.scm.SubversionSCM.xml
de.fspengler.hudson.pview.PViewProjectProperty.xml hudson.tasks.Ant.xml
hudson.maven.MavenModuleSet.xml hudson.tasks.Mailer.xml
hudson.model.UpdateCenter.xml hudson.tasks.Maven.xml
hudson.plugins.clearcase.ClearCaseInstallation.xml hudson.tasks.Shell.xml
hudson.plugins.clearcase.ClearCaseSCM.xml hudson.triggers.SCMTrigger.xml
hudson.plugins.git.GitTool.xml nodeMonitors.xml
hudson.plugins.sonar.SonarPublisher.xml proxy.xml
hudson.scm.CVSSCM.xml
)