I have installed in my arch system code-oss following this guide https://wiki.archlinux.org/title/Visual_Studio_Code i have also modified product.json ,installed code-features and code-marketplace but doesn't work, i read a lot of thread about this topic but i don't found any solution Those are the error
Unfortunately, it looks like the latest upgrade of the icu package to version 71.1 broke some dependency requirements for the live share extension.
There is already some discussion happening in the official Github live-share feedback repository, most notably here. As of now, no general fix is available, but what seems to work for now is to install the old version 70 of icu from the AUR.
Example if you have trizen installed:
trizen -S icu70
This might take a while because it has to be compiled. Alternatively, there is also a binary build available for version 69:
trizen -S icu69-bin
I've just installed Haskell Platform 8.6.5 in Windows 10 (latest download from https://www.haskell.org/platform/), and when trying "cabal new-update" or "cabal v1-update", it answers with the following error message.
Downloading the latest package list from hackage.haskell.org
cabal.exe: Could not read index. Did you call 'checkForUpdates'?
I have found no other question regarding this issue here, and although there is one on GitHub (https://github.com/haskell/cabal/issues/5574), no solutions so far, at least for Windows.
Can I use cabal on Windows at all?
I have searched and read all cabal related problems I could, both on here and on GitHub, but most are either for Linux or OS. No good answers for Windows...
I have tried the "cabal -v3 v2-update" and it showed me the file that was missing and its path. At first I tried to restore the file by hand, but someone suggested erasing all the files related to the missing one, and, voilá, cabal regenerate all of them and started to work.
The file missing was called 001-index.cache, and I erased all the files 001-index*.
The path was C:\Users\fidel\AppData\Roaming\cabal\packages\hackage.haskell.org.
Thanks everybody for the suggestions and help.
I tried to upgrade Perl and put my computer into a complete mess
I am currently running RHEL6.5, 64bits, and this is the thing:
I had perl-5.10.1 installed, and working nice. this came installed,
and I could see it from yum
I wanted to install Padre, an Perl IDE, but that required at least v5.11 [I was so close! :( ]
There were no newer version for Perl in the repos that I have access to (and I have a limitation that I can't add new repos)
I got approval from my boss to download perl-5.20 .0 from www.perl.org and tried to install it
... and the mess begins!
First I installed the new perl with my own id, and that pushed perl to somewhere under my home dir
I tested with 'perl -v' and could see that my env was pointing to the newer install, however, yum never recognized it (not really a problem)
When I tried to install Padre, seems somehow it had the hardcoded the original perl (from /usr/bin) and still claiming for something as newer as 5.11.
Trying to fix it, I did installed the new perl again, now using root, to make it push perl under /usr tree ... it installed, but pushed perl to /usr/local/bin, instead of /usr/bin
So again, I had one more perl install but Padre still looking for the one on /usr/bin
I give up about Padre, and deleted the files related to it, as well as the perl installed on my home dir, however a couple of perl scripts that I had already coded now are throwing errors like:
perl -cw "xmltest.pl" (in directory: /home/myid/scripts/xmltest.pl)
perl: symbol lookup error: /usr/lib64/perl5/auto/Data/Dumper/Dumper.so: undefined symbol: Perl_Istack_sp_ptr
Compilation failed.
... and Data::Dumper in not the only one ... every time I disable one of the modules, another one hangs in the same, or similar way
From what I read about this, seems that this issue is related to modules that were originally installed for one perl version, and are being called by another, however, I already forced the modules that I use to be reinstalled directly from CPAN, and they still failing
Question: How can I, safely, get free from this current perl installs, and perform a new clean install be able to use it w/o these versions conflicts?
My major concern are about the numerous apps that I have that depends on Perl, and I my not broke then on a uninstall
Any help will be much appreciate.
You should:
cleanup
clean (comment out) your ~/.profile from any unwanted paths, and so on
clean any new perl installation from your $HOME (move to safe place for sure)
in short, try return your environment into previous working state
relog, (logout, login)
repair your system perl. Thats mean,
read #Sam Varshavchik's answer
reinstall it from your distribution, using your package manager (5.10).
this step should overwrite the mess you caused.
test it !
don't continue until youre ensured, everything working right as before.
Lesson learned: never overwrite your system perl
learning
read thru perlbrew.pl
repeat previous step once again, especially with the
the homepage
http://perlbrew.pl/Perlbrew-and-Friends.html
https://metacpan.org/pod/App::perlbrew
https://metacpan.org/pod/perlbrew
installing perlbrew
run the installation command \wget -O - http://install.perlbrew.pl | bash
should finished without errors
follow the instructions how to modify your startup file e.g. ~/.profile or such... (you need to add one line to the end)
check your ~/perl5/perlbrew/bin should contain prelbrew and patchperl
relog
setup new perl, run
perlbrew init #init environment
perlbrew available #show what perl you can install
perlbrew install 5.20.0 #will take few minutes - depends on your system speed
perlbrew install-cpanm
perlbrew list #check
perlbrew switch perl-5.20.0 #activate newly installed perl 5.20
Check your installation
in the ~/perl5/perlbrew/bin you should have 3 scripts: prelbrew , patchperl , cpanm
perl -v should return 5.20
type cpanm - should return ~/perl5/perlbrew/bin/cpanm
You're done.
CPAN modules
You can install new modules with cpanm, like:
applications
cpanm cpan-outdated
cpanm App::Ack
cpanm Unicode::Tussle
cpanm Perl::Tidy
cpanm Perl::Critic
collections
cpanm Task::Moose
cpanm Task::Plack
cpanm Task::Unicode
modules
cpanm Path::Tiny
cpanm Try::Tiny
cpanm JSON
cpanm YAML
etc...
Check the ~/perl5/perlbrew/perls/perl-5.20.0/bin/ for new commands
You will need update your own perl script's shebang line to
#!/usr/bin/env perl
I hope don't forget anything, maybe other more experienced perl-gurus will add/edit/correct more.
Anyway, in the reality the steps 5,6,7 are much easier as sounds (by reading this) and could be done in few minutes.
On rpm-based Linux distributions, you should never install system software manually, like this, by trying to compile and build it yourself. RHEL's package management tool, rpm, performs an important function of keeping track of dependencies between packages, and prevent package conflicts.
The errors you showed are precisely the symptoms of a corrupted system Perl installation, and rpm exists precisely to avoid this sort of thing happening. Manually building and installing random tarballs completely bypasses the safety net that rpm provides.
There's no cookie-cutter recipe for recovering from a corrupted system install of a critical system rpm like perl, but in general:
1) run "rpm -q" perl, this will show you the exact version of the perl rpm package that rpm thinks should be installed.
2) go to the RHEL installation media/directory, verify that it contains the same perl-.x86_64.rpm package. If you previously installed RHEL updates, it's possible that you already updated perl, so look for the version that rpm tells you have installed in the RHEL update directory, and verify that you have the correct rpm package.
3) Execute:
rpm -ivh --force perl-<version>.x86_64.rpm
This will reinstall the original perl RPM package that was previously installed. Your problem is not only that you have extra versions of perl installed, but that it's likely that some of your custom perl builds have clobbered the system perl package, and uninstalling them won't help, you have to reinstall the system perl.
4) In RHEL, many perl modules are installed as separate packages. The above process should be used to reinstall every perl rpm package that you have installed. Execute:
rpm -q -a | grep '^perl'
This will give you a list of all Perl packages you have installed. You will need to repeat this procedure for every Perl rpm package.
It's not a 100% guarantee that this will fix everything, there could be other things wrong too, but this is a good first step towards recovery.
What I have done:
From #Sam-Varshavchik answer:
Found the previous perl rpm in my yum cache, and installed ...
rpm -ivh --force perl-<version>.x86_64.rpm
Checked for others "perl*" previously installed packages ... there were +260 so saved it in a file rpm -qa "perl*" > /tmp/perl.pkgs
With +260 packages to install, I realized that do it manually would take too much time, so it was time to put some ksh skills in practice ...
I checked at my yum cache and found ~130 of the +260 packages, so
took out from the list the base perl package (that I already have installed);
for those in the cache, I decided to install then with rpm, in the same way as the base package;
for those that I did not have handy, I used yum, which would download and do the same
of rpm, so ...
CACHE="/var/cache/yum/x86_64"
for perlpkg in $(cat /tmp/perl.pkgs)
do
FILE=$(find $CACHE -name "${perlpkg}.rpm")
if [[ ${FILE} != "" ]] ; then
rpm -ivh --force ${FILE}
else
yum -y reinstall ${perlpkg}
fi
done
From #jm666:
Installed perlbrew (was able to got it from my auth repos, so got it using yum) and using perlbrew, installed 5.20.0 localy
TODO: Didn't got any additional modules and neither Padre yet ... need to learn more about the way perlbrew works and isolate the installed version away from the system perl
Once again, thanks #Sam-Varshavchik and #jm666 for your support ang guidance
I'm running an ancient Ubuntu and after the automatic update, git-gui stopped working and complains instead:
Error in startup script: expected version number but got "1.7.0-"
while executing
"package vsatisfies $_git_version 1.7.0-"
(file "/usr/local/libexec/git-core/git-gui" line 1)
My "fix" was to revert /usr/lib/git-core/git-gui as follows
1286c1286
< if {[package vsatisfies $_git_version 1.7.0]} {
---
> if {[package vsatisfies $_git_version 1.7.0-]} {
1542c1542
< if {[package vsatisfies $::_git_version 1.6.3]} {
---
> if {[package vsatisfies $::_git_version 1.6.3-]} {
The sad thing is that after the next update it happened again. This problem seems to be rare, the only relevant link from this year I found was this a deleted question on SO. I'm using git 2.0.0, tclsh 8.4.
There was a change to the package version number satisfaction logic in Tcl 8.5 which allowed it to support more complex version expressions. It appears that git-gui is using this extended syntax (unnecessarily as it happens) and as such, you're going to be fighting this fight with it every time you update it until you upgrade your system to have Tcl 8.5.
This is recommended anyway; Tcl 8.4 is out of support, there will be no future releases of it, and the changes to the package version logic will not be backported.
There is a bug in the git-gui code; it should say in itself somewhere (probably at the top of its main script) exactly this:
package require Tcl 8.5
since it uses functionality from Tcl 8.5. That wouldn't fix things for you, but would tell you the correct thing you need to do about it.
Does anyone know how to get cabal install to exploit parallelism? I'm compiling with GHC, and while I don't know if GHC itself can do parallel builds, surely cabal install could run multiple compilations in parallel, no? At least for distinct, independent packages?
Does anyone know if it is possible and how to do it?
I'm the one who was working on this Summer of Code project. The patches have been sent to Duncan, but he hasn't reviewed them yet. Note that my code works at the package granularity, so you won't get any speedup when building a single package. I'm currently working on a parallel wrapper around ghc --make, which will solve this problem (I hope to get it merged into the mainline cabal-install eventually).
Update (Feb. 2012): Duncan has reviewed my patches, I need to incorporate his feedback and resubmit them. I hope to get this done before the end of this month.
Update (Apr. 2012): I've updated my patches in response to Duncan's comments. The new code is a bit slower, but requires much less changes to the Cabal library.
Update (Jun. 2012): Duncan Coutts just merged the parallel branch into Cabal HEAD. Parallel install will be available in the next cabal-install release.
Update (Oct. 2012): cabal-install1.16.0 has just been released. This is the first official release that includes my parallel patches.
Completing Mikhail Glushenkov's answer to document the usage a bit:
As of cabal 1.16.0, you can now use
cabal install -j [pkgs…]
This defaults to one job per core. It also gives much cleaner output.
You can make parallel installs the default with:
echo "jobs: $(getconf _NPROCESSORS_ONLN)" >> ~/.cabal/config
Or (cabal-install 1.18+):
echo 'jobs: $ncpus' >> ~/.cabal/config
Get the latest cabal-install with:
cabal update
cabal install cabal-install --bindir ~/bin --upgrade-dependencies
There was a Google Summer of Code project this summer to parallelize cabal-install. While it hasn't been merged into the mainline yet, the linked article provides instructions for grabbing the source and building it yourself.