I am trying to figure out a rather stable way to programmatically determine the latest release version number of the chrome browser.
It doesn't have to be failproof as it's only a nice-to-have-feature I can blend out whenever the result looks "suspicious".
There seems to be no API (is there?).
I dont want to rely on third parties handling that stuff manually.
I dont want to parse any website output.
So I ended up fetching git files.
My first approach was to fetch this file:
https://chromium.googlesource.com/chromium/src.git/+/master/chrome/VERSION?format=TEXT
Which gives the latest version number.
From there on the solution is just a preg_match_all away ...
Unfortunately its not the latest release version but the latest dev version.
There seems to be no "release" branch nor a "release" tag or something else I can think of neither.
You might answer "why?"... I know about feature detection, I know browser sniffing can be fooled and I am aware of the fact that (every) browser will notify their users when it's time to update. Still makes sense in my case. On the other hand its solely for display purposes. Nothing is going to depend on it later on – promise :-)
Any – even the faintest – ideas are highly appreciated!
The Chrome team uses the OmahaProxy dashboard to keep track of current versions in stable/beta/dev/canary. If you can scrape that you can get whatever version number you're looking for.
I've found the following endpoints from OmahaProxy that give the latest stable versions of the respective OS.
Windows: https://omahaproxy.appspot.com/win
Linux: https://omahaproxy.appspot.com/linux
Mac: https://omahaproxy.appspot.com/mac
Feel free to use my online service vergrabber to get latest versions of different kind of software in json format.
It's available at http://vergrabber.kingu.pl/vergrabber.json
If you're on debian based linux, you could install and update your chrome once a day, and somehow parse the version number, but this is not realtime.
For example:
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
dpkg -i google-chrome-stable_current_amd64.deb
Which will give a log like this:
(Reading database ... 113338 files and directories currently installed.)
Preparing to unpack google-chrome-stable_current_amd64.deb ...
Unpacking google-chrome-stable (48.0.2564.97-1) over (47.0.2526.111-1) ...
Setting up google-chrome-stable (48.0.2564.97-1) ...
Processing triggers for menu (2.1.47) ...
Then just parse it.
The ChromiumDash also makes the data available via an API. You can use that to fetch the latest tag for a platform and a channel.
Eg: https://chromiumdash.appspot.com/fetch_releases?channel=Stable&platform=Windows&num=1
Returns
[
{
"channel": "Stable",
"chromium_main_branch_position": 950365,
"hashes": {
"angle": "343b7bb57268e1cb47da26fcb0ed40fe47e8ff5d",
"chromium": "cab11adacc41ee856c79e669c2fd38d8864e52c4",
"dawn": "1b1b658d365591b6a8d4bfb0c3524832c89afc99",
"devtools": "b6f648d8921ea8be8f2b32c2061fec7503b56610",
"pdfium": "27cabf3dae38d0634a53316da0ad069bf0413495",
"skia": "a6986cd7224f104044fd5bc29cb5f80796d76f5a",
"v8": "db77a493a5595b835655b243202ac0c2fb1898a6",
"webrtc": "a6b138d6b4ef3a5b2c87f899b67f3b5c8dd3c002"
},
"milestone": 98,
"platform": "Windows",
"previous_version": "98.0.4758.81",
"time": 1643754840000,
"version": "98.0.4758.82"
}
]
Related
I note that when cygwin's setup.exe installs packages now, it looks for a file named "setup.zst.sig" first. What's the content and format of this binary file? How to produce a valid "setup.zst.sig"?
This must have been a recent change. Previously it looked for "setup.exe.sig" first. I use the feature (to detect whether "setup.exe.sig" changed) to decide whether my cygwin installation needs to be updated. See also this for an application example.
EDIT: #matzeri:
setup.zst.sig is not yet used.
The "zst" functionality was introduced in the program to eventually replace the
previous compression methods of setup.ini and the packages
const std::string setup_exts[] = { "zst", "xz", "bz2", "ini" };
For checking the update of setup-ARCH.exe you need to use the standard signature.
https://cygwin.com/setup-x86.exe.sig
https://cygwin.com/setup-x86_64.exe.sig
The pop up you shows seems to happen only on FTP mirror server, the HTTP servers
do not produce it.
It is clearly a bug in setup
https://cygwin.com/ml/cygwin/2019-02/msg00153.html
According to the documentation, the .sig files carry a SHA-512 hash of the respective file without that extension, signed with the private key available only to Cygwin the company.
https://www.cygwin.com/faq.html#faq.setup.install-security
Im trying to automate deployment of perforce (p4 & p4v) using puppet. For this I have created a perforce resource
perforce { 'p4' :
version => '>= 15.1',
ensure => 'present',
}
The problem I have is how to determine installed version. Perforce sort all tar balls in release order .../R15.1/... but running p4 -V yields a version number that looks more like date and build no , e.g. 2016.2.345671
Is there a way that I can get the release installed?
I'm not really sure what you're asking since it sounds like you already know about p4 -V, but will try to answer the implied question of "what do all the pieces of the version string mean"...
"2016.2" is the same as "r16.2" -- releases are named according to the year of release, and there have historically been two major releases most years so the version numbers tend to be of the form YEAR.1 and YEAR.2.
The number at the end of the version string in the binary is basically the patch level (it correlates with changes in the release notes).
Here's an example of using a regex to deconstruct a Perforce version string:
https://swarm.workshop.perforce.com/files/guest/sam_stafford/scripts/itest.pl#401
I've been trying for hours, but can't build and use Light Table. Every time I try to run deploy/LightTable, it hangs on a screen that simply says "Light Table". I receive this error*:
[14381:0519/204037:INFO:CONSOLE(27860)] "Uncaught TypeError: Cannot read property 'thread_STAR_' of undefined", source: file:///home/zaz/Desktop/LightTable/builds/lighttable-0.8.0-linux/resources/app/core/node_modules/lighttable/bootstrap.js (27860)
Here's what I've tried:
git clone https://github.com/LightTable/LightTable.git
cd LightTable
bash linux_deps.sh
./deploy/LightTable # creates frozen window, throws the error above
cd deploy
./LightTable # creates frozen window, throws the error above
./ltbin # creates frozen window, throws the error above
I also tried similar things after checking out the atom-shell branch and the 0.7.2 tag (and cleaning up all the files from the previous build). Each time, I received the error above.
Does anyone know what's going on here?
Has Light Table been completely abandoned? It seems the last commit was in March.
* Depending on the version I was trying to run, I also received other errors, but I don't think they're relevant (the error above was the only one that appeared for all versions):
[18593:0519/222845:INFO:gpu_info_collector_x11.cc(80)] NVCtrl extension does not exist.
[18593:0519/222845:ERROR:browser_main_loop.cc(226)] Gdk: gdk_window_set_icon_list: icons too large
Fontconfig warning: FcPattern object size does not accept value 11(i)
[14413:0519/204035:INFO:renderer_main.cc(212)] Renderer process started
A year later (question was written in May 2015, now is June 2016), LightTable 0.8.1 is out, and I tried both Linux binary and cloned it from git, and it works fine.
For complete info, I'm using also Atom, and although I had not problems with "Cannot read property 'something' of undefined"" in Atom core, I met such problems in two or three Atom packages.
Both editors are based on same electron platform, LightTable is beautiful eye candy with quite revolutionary REPL integration, but it needs more polish to be usable to same extent as Atom.
For example, LightTable does not have workspace saving by default, that is done via plugin. That's ridiculous.
But although Atom looks so nice and powerful compared to simple editors, with realy huuuge number of available packages/plugins, LightTable is more elegant.
As I don't want to start new semi-religious war Atom vs LightTable resembling vi-vs-emacs, I'll stop here. :)
I can't replicate your problems in LightTable v0.8.1, so I think that answers this question. If not, please add errors you get with v0.8.1.
For info about releases, please check: https://github.com/LightTable/LightTable/releases
Is it possible to bypass a flash player version check?
I'm using an old embedded Linux device with FF 2.0 and Flash Player 10. Unfortunately we cannot upgrade the existing version any further. YouTube and many other video sites are working fine when modifying the User Agent string of the browser. We only have problems with a few sites that check the Flash player version.
E.g. Flash player check in JavaScript:
if($('.video-player-container').length > 0){
if (swfobject.hasFlashPlayerVersion("10.2.0")) {
else { flashWarning.... }
Or is there a way to override the existing version number without upgrading the player?
You may use a little hack to change the displayed version number. Short indication to do it is to change the shared library file by replacing every occurrence of your old version number with the new one:
sudo sed -i -e 's/your_current_version/desired_version/g' /usr/lib/flashplugin-installer/libflashplayer.so
After this, restart your browser and go to Adobe flash "about" page to see if it worked.
Longer indications may be found in this blog post.
edit: I should add a word of caution here: it is a very dirty method, which will likely work only until the next update of your flash player. And it will likely work only as long as the original and desired versions number have the same number of digits ! So, please do a backup of the original file before attempting it, i.e.
sudo cp /usr/lib/flashplugin-installer/libflashplayer.so /usr/lib/flashplugin-installer/libflashplayer.so.backup
and to restore the original unaltered file, type:
sudo mv /usr/lib/flashplugin-installer/libflashplayer.so.backup /usr/lib/flashplugin-installer/libflashplayer.so
Not having any experience with couch and redis, this is becoming more than I can handle at this point.
The npm website allows you to search for packages by a keyword - https://npmjs.org/browse/keyword/awesome
However, it doen't provide any way of obtaining this information in json format - ideally, we could just do https://npmjs.org/browse/keyword/awesome.json but that is not the case :(
I know that the npm website is powered by couchdb and a local redis instance. The remote couchdb installation is http://registry.npmjs.org/ and powered by https://github.com/isaacs/npmjs.org
However, spending the day looking into this, I just cannot figure out how to get all packages of a particular keyword. Does anyone know how? Bonus points if you also explain the process that you went about finding out how to do it so I know for next time :)
Great question!
This will give you what you're looking for about a specific module:
npm view request
To get what you want for all modules you can hit the URL:
https://registry.npmjs.org/-/all/
After pouring through these two files:
https://github.com/isaacs/npm/blob/master/lib/search.js
https://github.com/isaacs/npm-www/blob/master/models/browse.js
I came to the following conclusions:
I'm super surprised there's not a better way to do search without hitting couchdb directly.
The command-line NPM client does search inside of node.js by sorting and filtering through the full results of that /all/ search listed above.
The website doesn't even bother with real search as it pawns it to a search engine
The search by keyword thing you want won't get the same results as command-line NPM. It's really limited in scope to the keyword attribute, other search options may be available through (see search.js above)
The query is going to look really weird.
Try this:
https://registry.npmjs.org/-/_view/byKeyword?startkey=["keyword"]&endkey=["keyword",{}]&group_level=3
Also, one quick note, this is the kind of question that would probably get answered in the node.js chat room or mailing list in about 4 seconds :)
Hope that helps.
Based on this answer I wrote a small lib for node, https://github.com/wires/npm-keywordsearch.
npm install npm-keywordsearch
then
var search = require('npm-keywordsearch')
search('my-plugin', function (error, packages) {
packages.forEach(function (pkg) {
console.log(pkg.name + ': ' + pkg.description)
})
})
Maybe useful for you
Sometime in 2018, npm retired the /-/_view/byKeyword API:
https://registry.npmjs.org/-/_view/byKeyword?startkey=%5B%22docpad-plugin%22%5D&endkey=%5B%22docpad-plugin%22,%7B%7D%5D&group_level=2
The new API is now: /-/v1/search:
https://registry.npmjs.org/-/v1/search?text=keywords:docpad-plugin&size=250
Documentation for it is here:
https://github.com/npm/registry/blob/master/docs/REGISTRY-API.md#get-v1search
I've updated the pluginclerk package accordingly. It is a node package that provides an API to hit that call, while providing caching, as well as dependency compatibility resolution.