Cannot install go package go.net/html - go

I use go.net/html in my project on work and everything is ok. But when I try to install this package on my laptop I get a error:
termith#termith-laptop:~/go$ go get code.google.com/p/go.net/html
# code.google.com/p/go.net/html
src/code.google.com/p/go.net/html/token.go:304: undefined: io.ErrNoProgress
My system:
termith#termith-laptop:~/go$ uname -a
Linux termith-laptop 3.2.0-51-generic-pae #77-Ubuntu SMP Wed Jul 24 20:40:32 UTC 2013
i686 i686 i386 GNU/Linux
Thanks in advance!

You most likely have an outdated Go version (see for example this GitHub issue).
Check the output of go version and update if necessary.

Beware: the go.net package url will change with Go 1.4:
code.google.com/p/go.net => golang.org/x/net
If you update (again) your go version (to 1.4, once released, November 9th, 2014), you might have to change that import path.
See "Go 1.4 subrepo renaming".

Related

What is the message when it is building on Golang?

When I build source on Golang, I saw the warning message, but I couldn't find answer about it.
$ go build --mod=mod -o main main.go
# command-line-arguments
ld: warning: -no_pie is deprecated when targeting new OS versions
specs
version : go version go1.18 darwin/amd64
os : Monterey 12.6
build command : go build --mod=mod -o [binary name] main.go
From GitHub: link
There are a few options:
- wait for the next Go 1.19.x and 1.18.x releases, probably early next month
- build Go from the master branch
- pass -buildmode=pie flag to go build and go test for a workaround
- use older version of the system linker
This seems to be a known issue. See Github for more information.
As a workaround you can pass the -buildmode=pie flag to your go build command.

OSX fix Selenium Chromedriver launch error spawn Unknown system error -86 Bad CPU type in executable?

Suddenly on the afternoon of January 6, 2021, my Selenium Protractor tests under OSX stopped working with the mysterious error
spawn Unknown system error -86
I did some research and discovered that error number 86 is the same as
Bad CPU type in executable
and ran the following to compare the cpu architecture of my chromedriver binary to my system:
% file chromedriver_87.0.4280.88
chromedriver_87.0.4280.88: Mach-O 64-bit executable arm64
% uname -a
Darwin kobl179273m 19.6.0 Darwin Kernel Version 19.6.0: Thu Oct 29 22:56:45 PDT 2020; root:xnu-6153.141.2.2~1/RELEASE_X86_64 x86_64
% uname -p
i386
How can I fix the chromedriver binary used by my Selenium so that it will run on my Intel x64 mac and clear the "system error -86" or "Bad CPU type" message?
The issue is described in https://github.com/angular/webdriver-manager/issues/476.
This has been now fixed in 12.1.8 so just update to that webdriver manager.
For most users this can be accomplished with
npm uninstall protractor && npm install protractor
Edit: this answer should be considered deprecated now that the underlying bug in webdriver-manager has been fixed. A better solution would be to upgrade to the newest version of webdriver-manager. The answer below may be useful if people need to use an older version of webdriver-manager which still has the bug.
As per Deepak Srinivasan's comment above, this error is caused by https://github.com/angular/webdriver-manager/issues/476
Root Cause:
The ChromeDriver team added "_m1" to the end of the filename for their Apple Silicon ARM builds of Chromedriver -- but both the Silicon and Intel versions of chromedriver have "mac64" in the filename, and the version number is exactly the same. This causes webdriver-manager to always download the Silicon build of Chromedriver, even on Intel macs. As a general solution, simply avoid using the chromedriver that has _m1 in its filename if you are on an Intel mac.
Solution 1: Downgrade to Chrome 86.0.4240.198 and Chromedriver 86.0.4240.22. These versions work together and are the most recent versions prior to the new and problematic support for Silicon ARM
Chrome 86 download page:
https://google-chrome.en.uptodown.com/mac/download/2920124
Disable auto-updates in Chrome: https://superuser.com/questions/1359017/how-do-i-disable-automatic-updates-of-google-chrome-on-mac-os-x
Chromedriver 86: https://chromedriver.storage.googleapis.com/index.html?path=86.0.4240.22/
% webdriver-manager update --versions.chrome=86.0.4240.22
Solution 2: Modify the webdriver-manager npm package to point to the correct chromedriver (thanks to ciekaway from the angular github issue page for this fix)
Modify the following file
node_modules/webdriver-manager/built/lib/files/file_manager.js
or, if using protractor
node_modules/protractor/node_modules/webdriver-manager/built/lib/files/file_manager.js
Near the top of the downloadFile method around line 166, add the following line to remove "_m1" from the name of the file:
fileUrl.url = fileUrl.url.replace(/_m1/, '');
It needs to be after the beginning of the .then block that starts with
binary.getUrl(binary.version()).then(fileUrl => {
it also needs to be before the next reference to fileUrl.
For example:
binary.getUrl(binary.version()).then(fileUrl => {
binary.versionCustom = fileUrl.version;
fileUrl.url = fileUrl.url.replace(/_m1/, '');
let filePath = path.resolve(outputDir, binary.filename());
Note that this solution is temporary. It will be overwritten by an npm install. The Chromedriver and/or the webdriver-manager team will probably fix this issue, at which point you should clear the modified version of your webdriver-manager and download the fix from npm.
For macOS Catalina Version 10.15.6 (19G73)
In my case I was working with Rails and Capybara for feature tests. What worked for me was
First, find the actual chromedriver location running:
which chromedriver
# Which returned:
/Users/alex/.webdrivers/chromedriver
Then, install chromedriver via Homebrew:
brew install chromedriver
Then, remove old chromedriver reference found at previous location with:
rm /Users/alex/.webdrivers/chromedriver
Now, link the old chromedriver reference to the one installed with brew:
ln -s /usr/local/bin/chromedriver /Users/alex/.webdrivers/chromedriver
Then, open Finder app, then click on Go menu and then click Go to folder ... option, and enter this route:
/usr/local/Caskroom/chromedriver/
There you should see a folder with the chromedriver version you have installed, something like this:
88.0.4324.96
Enter that folder and you should see the chromedriver binary file.
Right click on it, and click on Open
Now, you should get a terminal window popping up with the output:
Last login: Sun Jan 31 12:29:15 on ttys001
/usr/local/Caskroom/chromedriver/88.0.4324.96/chromedriver ; exit;
  ~  /usr/local/Caskroom/chromedriver/88.0.4324.96/chromedriver ; exit;
Starting ChromeDriver 88.0.4324.96 (68dba2d8a0b149a1d3afac56fa74648032bcf46b- refs/branch-heads/4324#{#1784}) on port 9515
Only local connections are allowed.
Please see https://chromedriver.chromium.org/security-considerations for suggestions on keeping ChromeDriver safe.
ChromeDriver was started successfully.
Finally, press Ctrl+C to stop the execution and quit the terminal window.
Now, you should be able to run capybara tests.
npm uninstall protractor && npm install protractor
If you use webdrivers gem, upgrade it:
bundle update webdrivers

Broke yum on Centos 6.10, cannot install missing GLIBC in error due to missing libunwind

I was installing nvidia-drivers on Centos 6.10 which included a --skip-broken flag and may have broken yum. Whenever I ran yum commands this error pops up.
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
/lib64/libc.so.6: version `GLIBC_2.14' not found (required by /lib64/libgcc_s.so.1)
Please install a package which provides this module, or
verify that the module is installed correctly.
It's possible that the above module doesn't match the
current version of Python, which is:
2.6.6 (r266:84292, Jun 20 2019, 14:14:55)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-23)]
If you cannot solve this problem yourself, please go to
the yum faq at:
http://yum.baseurl.org/wiki/Faq
I stumbled upon this thread which talks about installing the missing GLIBC version, but I ran into this error in step 8 ../configure --prefix=/opt/glibc-2.14
checking for forced unwind support... no
configure: error: forced unwind support is required
Which then took me to this forum thread that states I should install libunwind via yum. Which was my original problem, thus leaving me at an impasse. What should I do?
You need to reinstall GCC, or more precisely the libgcc package. Something overwrote /lib64/libgcc_s.so.1 with an incompatible version. You should be able to download the libgcc RPM package from a mirror, and then run:
# rpm --reinstall libgcc-4.4.7-23.el6.x86_64.rpm
This should still work because RPM itself does not depend on libgcc_s.
In general, if you need newer versions of these core system libraries (glibc, libstdc++, libgcc_s), you need to upgrade the entire operating system. Even if you manage to replace them in a consistent fashion, you are running something that isn't very close to the original operating system anymore. At that point, it is more prudent to upgrade, because that will give you a consistent system that has been tested by many others.

DAL-script is different between the one in github and pip install

I am trying to follow the Django-autocomplete-light tutorial
However, when I try to run the test_project, I get the following error.
AttributeError: module 'dal.autocomplete' has no attribute
'Select2GenericForeignKeyModelField'
When I check the dal/autocomplete.py which was installed through pip command, I could not find any attribute Select2GenericForeignKeyModelField.
On the other hand, when I check the one in github, I could find this attribute.
I am guessing that the version which is in pip is older than the one in github.
Does anyone know how I can solve this problem?
The latest stable version is DAL 3.2.10, it was released at Aug 28, 2017 and Select2GenericForeignKeyModelField was added at Mar 30, 2018. It's not available even in pre-releases as the most recent pre-release now is 3.3.0rc6 released at Mar 6, 2018.
It seems you have to use older API or install DAL from Github:
pip install -U git+https://github.com/yourlabs/django-autocomplete-light#egg=django-autocomplete-light

stack is not working after upgrading platform to 8.0.2 from 8.0.1

After upgrading haskell platform package, stack command does not work.
$ stack path
No compiler found, expected minor version match with ghc-8.0.1 (x86_64) (based on resolver setting in /home/eii/exercism/haskell/linked-list/stack.yaml).
To install the correct GHC into /home/eii/.stack/programs/x86_64-linux/, try running "stack setup" or use the "--install-ghc" flag.
$
I tried stack setup but it is trying to download an old GHC (ghc-8.0.1). I just installed Haskell platform 8.0.2 (haskell-platform-8.0.2-unknown-posix--full-x86_64.tar.gz). I am using a 64 bit Linux.
$ stack setup
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
ghc-8.0.1: 15.69 MiB / 108.01 MiB ( 14.52%) downloaded...^Cuser interrupt
$
I can compile with ghc-8.0.2 and ghci is working fine.. but I can't use stack nor install new packages.
$ stack update
Downloading package index from https://s3.amazonaws.com/hackage.fpcomplete.com/00-index.tar.gz
Updating package index Hackage (mirrored at https://s3.amazonaws.com/hackage.fpcomplete.com/00-index.tar.gz) ...
$ stack upgrade
Current Stack version: 1.3.2, available download version: 1.3.2
Skipping binary upgrade, your version is already more recent
$ which stack
/usr/local/bin/stack
$ ls -la /usr/local/bin/stack
lrwxrwxrwx. 1 root root 45 Feb 1 18:39 /usr/local/bin/stack -> /usr/local/haskell/ghc-8.0.2-x86_64/bin/stack
$ which ghc
/usr/local/bin/ghc
$ ls -la /usr/local/bin/ghc
lrwxrwxrwx. 1 root root 43 Feb 1 18:39 /usr/local/bin/ghc -> /usr/local/haskell/ghc-8.0.2-x86_64/bin/ghc
$
Please help.
I encountered this the other day on Arch Linux 4.17.4. The error was:
No setup information found for ghc-8.4.3 on your platform.
This probably means a GHC bindist has not yet been added for OS key 'linux64-ncurses6', 'linux64-tinfo6'.
Supported versions: ghc-7.8.4, ghc-7.10.2, ghc-7.10.3, ghc-8.0.1, ghc-8.0.2, ghc-8.2.1, ghc-8.2.2, ghc-8.4.1, ghc-8.4.2
As a workaround, I edited stack.yml to change
lts-12.0
to
lts-11.15

Resources