Closed Romane-T closed 7 years ago
Did a fresh install of Ubuntu 15.04. Problem mention here is happening.
@luisalvarado try installing libgcrypt11 version 1.4.5 from http://ftp.acc.umu.se/mirror/cdimage/snapshot/Debian/pool/main/libg/libgcrypt11/ and it should work
@sarangbaheti Thank you. It did.
Installing a package which is not in the repo is not a good solution. Software are upgraded for a good reason, like bugs and security issues.
The suggested workaround (extract .deb, modify dependancies and rebuild) doesn't work for me :
/usr/bin/brackets: error while loading shared libraries: libgcrypt.so.11: cannot open shared object file: No such file or directory
Same dependency issue here, on latest Ubuntu, fresh install. This is not a low priority bug anymore. Please update the label.
:+1: @sarangbaheti ! Installing this package: libgcrypt11_1.5.4-3_amd64.deb solved my problem of not beeing able to install Bracket 1.3 on Ubuntu Mate 64-bit
Thank you @sarangbaheti, It's worked for me.
Same dependency issue, with a Ubuntu 15.04 64 bits Installing libgcrypt11 through the .deb file solves the problem.
Yes, installing the older package makes this problem go away. No, I do not think requiring users to manually install an outdated package is a good solution. Furthermore: it's a crypto package, meaning that security is at stake when not using the most recent version.
It's been 7 months since this bug was reported, some sources mention a fix in version 1.3, but progress on an actual fix is not really reported. What is the status?
@dwilmer i agree this needs to be fixed !
I say -- if they don't watch this thread, let's hijack it for something remotely useful. :facepunch:
My first question, what's the general opinion on blogging software/tools? I want to revive my old forgotten blog, but I've no idea what's the kosher way to do it?
All these PHP Wordpress and Ruby 'simple tools' look a bit clunky to my untrained eye. Or am I looking the wrong way?
Hi @mihailik i'm not sure that i agree with your proposition but i don't mind answering it: i suggest you to take a look at http://nibbleblog.com (a nifty blog/cms written in php without database) or, from the same creator: http://www.bludit.com (same kind, in beta for now, you can check the differences between the two projects here: http://blog.nibbleblog.com/post/bludit-my-new-project/) Cheers +++
@mihailik I would be happy to discuss this on Slack or in the Google Groups... but hijacking this issue is not cool.
Not cool why? Are you still hoping a real Adobe dev can stray over here to comfort us with empty promises?
Accept it, we're all alone here, nobody can hear our screams. Can as well fill the thread will ASCII art and Pentagon interrogation transcripts -- still nobody would ever turn up. It's a dead issue, they've just forgotten to close it.
what I see is a medium priority issue open in a repo that has 1300+ open issues, with a viable workaround, on a platform that only 6% of Brackets users care about (and I am one of them, btw, and have been very vocal about Linux support and have Linux on 4 of my 6 computers between work and home).
Yes, we would all like to see the issues we care about fixed first, but the above factors make this issue farther down the triage list than we would like. Adobe has 6 resources working on Brackets afaik. They aren't the only ones who can fix issues. The community could fix this issue and jump the triage queue just like that... know anyone who can build stuff on Linux?
@mackenza Thanks for chiming in and we are a 6 member team, which takes care of everything relating to Brackets.
@zaggino @MarcelGerber Does it make any sense to spawn an experimental bracketron
Linux build and distribute that?
@mihailik Right now we are very tight on the resourcing and we are trying really hard to complete our existing stories. As mentioned by @mackenza, we have called for help multiple times, but we could not get anyone from the community, you could actively look into this issue. I did spend couple of days looking into issue(the related CEF 2171 migration issue) and realized that needs more time. We are willing to collaborate if there is anyone interested in taking the lead in fixing the issue. Thanks!
I haven't touched bracketron
for a while now, I'm not sure what Linux users would be missing if we went that way. @mackenza you use Linux right? how does bracketron
compare to the brackets-linux
? And I mean what's missing in bracketron
, not what's better there (native menus and so...)
@zaggino I have not tried Bracketron recently. I feel like it's a waste of time if it's not going to be used by core. We proved it's worth in the PoC but it needs to be completed or dropped. I don't think it's ready for production on Linux or any platform as is. Do you?
@nethip while I believe Bracketron is the right solution for Brackets moving forward, I don't think it makes sense to introduce it as an answer to this thread as you then have a 4th platform and it wouldn't be clear when/if Linux users were to use Brackets or Bracketron.
@mackenza Our primary goal is to unblock folks who are running Brackets on Linux. I was only throwing one of the options that we could exercise. It could be a bad idea too :smile: .
Of course, there might be some brackets-shell
specific things(like live developement) that need to be matched. IMHO, if all the workflows are met, we should think about this approach.
About electron-shell
replacing brackets-shell, the only blocker (which kind of is a big one), is the dark UI not present in electron-shell
. I did have a look at electron-shell
and porting our dark UI to electron-shell is not going to be that trivial as electron-shell
is completely dependent on chromium
to manage the window unlike brackets-shell
which does window management.
Why not embed the libraries in Brackets, like Atom does ?
A symbolic link ln -s /path/to/atom/libgcrypt.so.11 /lib/x86_64-linux-gnu/
make Brackets work.
@nethip I don't think your idea is bad, I am just thinking of the logistics here. Taking Bracketron beyond a PoC to complete all Brackets functionality is an effort. I am not sure @zaggino and @MarcelGerber (who have been the primary contributors to it) are going to be super interested in putting their efforts into completing Bracketron if the final use is only going to be for Linux which is such a small percentage of users (even less if it's as an experimental build for only those Linux users unwilling to install libgcrypt11).
So while the idea is fine, I think the execution of it would be problematic.
but that is my opinion.
download install libgcrypt11.xx.deb using Debian 7 version deb package url:https://packages.debian.org/search?keywords=libgcrypt11 1.5.0-5+deb7u3 i tested,it's working.
@ProfitHunter don't come here to leave a comment with a bad solution without reading what have already been answered.
Take a good look. This is the solution - install libgcrypt11 from the earlier version of Debian - that has been touted from the start when I first reported this issue all them months ago, of which this thread is a spinoff. In fact, it is about the only solution that is actually successful for everybody
So perhaps your criticism is completely unhelpful - clearly you yourself have been "without reading what have already been answered."
On 29/07/15 17:31, Nicolas wrote:
@ProfitHunter https://github.com/ProfitHunter don't come here to leave a comment with a bad solution without reading what have already been answered.
— Reply to this email directly or view it on GitHub https://github.com/adobe/brackets/issues/10255#issuecomment-125869407.
This is not the solution, this is just a bad workaround.
Already been answered : https://github.com/adobe/brackets/issues/10255#issuecomment-104398810 https://github.com/adobe/brackets/issues/10255#issuecomment-123216549
Edit : what is really unhelpful is to ask people to install an outdated package (which may harm their system and/or security), instead of trying to find solutions (not bad workarounds) for developers of Brackets.
Anyone can criticise, so at least I know your name - Anyone.
If you have a better solution, post it, or, even better, learn how to fix it and offer it to the team. THAT would be useful !!! Far more useful than one of the umpteen variations of the word "Bullshit".
On 29/07/15 17:52, Nicolas wrote:
This is not the solution, this is just a bad workaround.
Already been answered :
10255 (comment)
https://github.com/adobe/brackets/issues/10255#issuecomment-104398810
10255 (comment)
https://github.com/adobe/brackets/issues/10255#issuecomment-123216549
— Reply to this email directly or view it on GitHub https://github.com/adobe/brackets/issues/10255#issuecomment-125873406.
My suggestion for a better solution have already been posted : https://github.com/adobe/brackets/issues/10255#issuecomment-124482843 (did you read the thread instead of annoying me ?)
Have a nice bullshitting day :wink:
Guys please maintain the house rules @nethip @ryanstewart we need to adopt the open code of conduct similar to this. http://todogroup.org/opencodeofconduct/#Atom/opensource@github.com
Any suggestion, however minute is welcome in the group, a workaround/ a bad workaround is a workaround none the less. Please keep posting your findings/suggestions in the thread. Help is always welcome here :)
My apologies, my answer to ProfitHunter may have been rude in the form. But I maintain my statement that install the libgcrypt11 deb package is a very bad solution. You install a (may be) outdated and not maintained package with security issues and/or bugs. And because it is installed manually it will never be upgraded. So your system is vulnerable and could be considered as compromise.
A better way for this workaround would be to add in your sources.list
the Debian (or Ubuntu) repo where this libgcrypt11 package is still maintained, and configure APT pinning to use just this package in this repository. This way would be far more secure and viable.
To get back to my suggestion, embed the library in Brackets (like Atom does) will avoid OS/distro dependency on this point.
@abose that is a good idea. Let us discuss this offline.
@nikaro I would request you to calm down. All the people on the thread know the solution, please be courteous to people who are trying to help you, even if the proposed solution is wrong. Thanks!
@nethip I'm calm, just a little bit annoyed by these already known and already posted "install libgcrypt11.deb" workarounds. I follow this issue to know the progression of the work on this, not to keep receiving "install libgcrypt11.deb" notifications.
And I'm more into Crocker's rules than OpenCodeOfConduct.
@nikaro I have gone ahead and updated your comment from cocker's rule to Crocker's rule. Please take care of typos for especially words like these. This is a very respectable community. Even Crocker's rule clearly says
"Note that Crocker's Rules does not mean you can insult people; it means that other people don't have to worry about whether they are insulting you."
The bottom line is be courteous to folks whether it is Crocker's rule or something else. If you have a different opinion, then we are sorry to say that we will not be able to encourage your participation here.
Guys, please be nice to each other :)
:)
@nethip thanks for fixing the typo. But a cocker is just a dog, why would I be especially vigilant for this word ? Did I insult someone in my comments ? I just have been rude to @ProfitHunter, and I apologized as soon as @abose call us to order. What do you want more ?
Crocker's rules put aside. Please note that not everybody is fluent in english and have the vocabulary to put these "courteous" (<-- you make me discovered this one) words and make nice sentences.
Here is a sad crocker for all people I annoyed with this discussion :
@nikaro Sorry if I sounded hurting/rude. That was not my intention. I just want to make sure we have a friendly community and that everyone is respected. I am going to stop with this :+1:
Yes, I do recall your suggestion, but also recall the reasons it has not yet been taken up.
Just roll your eyes and delete the messages that annoy you about libgcrypt11. Going to be a few more of them before this issue is resolved by the Brackets team.
Those issues you raise don't bother all that many, who will and are quite happily (and without problems) running a version of libgcrypt11 from pre-jessie days; even if they are aware of the issues, most don't care or have the interest. The reality is that it works and is simple, and that is all most are interested in. So far as apt-pinning - another reality is that not too many interested in going through the effort, myself included. And until the team do put in place a better solution, just being able to get Brackets running will be all that is needed to make most happy.
Just for those interested, running the 1.4 Windows version under Wine fails with an exception. Of course, a virtual Windows machine will not have this problem :)
On 29/07/15 18:34, Nicolas wrote:
My apologies, my answer to ProfitHunter may have been rude in the form. But I maintain my statement that install the libgcrypt11 deb package is a very bad solution. You install a (may be) outdated and not maintained package with security issues or bugs. And because it is installed manually it will never upgraded. So your system is vulnerable and could be considered as compromise.
A better way for this workaround would be to add in your |sources.list| the Debian (or Ubuntu) repo where this libgcrypt11 package is still maintained, and configure APT pinning to use just this package in this repository. This way would be far more secure and viable.
To get back to my suggestion, embed the library (like Atom does) will avoid OS/distro dependency on this point.
— Reply to this email directly or view it on GitHub https://github.com/adobe/brackets/issues/10255#issuecomment-125880737.
The biggest problem on this thread is that not one person explained what is the reason for this bug, what is the workaround, and what is the downside of the workaround.
Giving a link to some weird page on Internet, and hand-waiving 'frob that blick but not schmob that driubit' is next to nothing. Normal people don't know your lingo, and aren't into intimate relationship with deb/conf/sudo sex toys.
@mihailik I'm not an Adobe developer, but here is a short answer from what I have understood :
sources.list
and configure APT pinning to get libgcrypt11 from itSo to fix this issue, it seems that they need to upgrade their CEF version and dependencies of the package. A quick fix waiting for CEF upgrade could be to embed the libgcrypt11 library.
It's well versed, but still not something a web developer would comprehend.
@mihailik your sarcastic responses to this thread are not welcome. Please observe some level of community respect and stop your antagonistic replies. Thank you in advance.
@mackenza please don't let my manners stop you from addressing the underlying issue.
It'll soon be a year since the issue reported, so I am sure you're eager to break the silence now.
If by "soon be a year" you mean 5 months from now, you are bang on. Also, the issue was logged against an unreleased version of debian. It wasn't actually released until late april this year.
Just an observation or three. Nothing more. nothing less.
On 29/07/15 21:34, mihailik wrote:
The biggest problem on this thread is that not one person explained what is the reason for this bug, what is the workaround, and what is the downside of the workaround.
Giving a link to some weird page on Internet, and hand-waiving /'frob that blick but not schmob that driubit'/ is next to nothing. Normal people don't know your lingo, and aren't into intimate relationship with deb/conf/sudo sex toys.
Of course Adobe developers are real culprits here. You guys have time to make ridiculously dismissive statements, but no time to clarify the situation?
Suggesting someone steps up and fixes the bug requires you, Adobe making it clear what the bug is, why it happens, and ideally outlining a plan to fix it.
Or not. Keep it muddled, that works for me. Much fun looking at how public gets really annoyed and hurts your public image by something that I suspect is a minute issue. Good luck!
— Reply to this email directly or view it on GitHub https://github.com/adobe/brackets/issues/10255#issuecomment-125925100.
@Romane-T wins this thread... he is exactly bang on 1-8
'5 months' stretching February — July, 'only tiny minority' including every single one on the latest Ubuntu, the issue 'being kept on the forefront' of what exactly?
I can't imagine writing a concise explanation in layman's terms is a task worthy all this bickering.
The work on including the new CEF, which (among others) removes the dependency on libgcrypt11, is tracked in issue #11047. They want to include the new version, but there are still some problems before doing so. The aforementioned issue tracks and details those problems, so you can understand what is going on and, if you have the time and skills needed, contribute.
For anyone running into this issue on Slackware-current, I have a build for the old libgcrypt that will ONLY install the necessary libraries, and coexist with the newer libgcrypt.
https://github.com/ryanpcmcquen/ryanpc-slackbuilds/tree/master/unofficial/libgcrypt15
EDIT Moved to SBo: https://slackbuilds.org/cgit/slackbuilds/tree/libraries/libgcrypt15
Brackets will not run by altering the dependency in the installation files to work with libgcrypt20.
You'll need to manually install libgcrypt11 for your architecture from the debian packages. Alternatively, add the wheezy repository in your sources.list file and apt-get install -f will solve the dependency problem.
Tested on Debian Jessie i386 and Stretch amd64.
Brackets not currently installable on Jessie. Brackets has dependency on libgcrypt11, which is not available in the Jessie repositories. Jessie repositories have libgcrypt20. Brackets can be installed if user locates a copy of libgcrypt11, which can be co-installed with libgryypt20, but considering Jessie in freeze to become stable, doing this this should be unnecessary. Removing libgcrypt11 from system removes Brackets at the same time. Romane