Suggest an idea or search for an existing one

arch linux binary doesn't work

Enable some kind of logging so I can figure out and help debug the problem.

The application started up one time, and I typed in my credentials and clicked the remember me check box. I clicked sign in and it failed to sign in. After I closed the application it will no longer open up at all.

I am using Arch Linux x64 (with AIR app working fine)

48 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • sso
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    ChrisChris shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ian MonroeAdminIan Monroe (Admin, HipChat) responded  · 

    Hey Arch Linux and Gentoo users,
    I’ve pushed out a new version of HipChat, 1.98.663. I think this should resolve the SSL certificate problems that was blocking sign in. Once you login, double check that HipChat is able to use https by ensuring an emoticon like (lol) displays correctly.

    (Basically Qt was built on Debian 6, which uses OpenSSL 0.9.8. If you have OpenSSL 0.9.8 installed, Qt would then prefer that version over OpenSSL 1.0.0. And for whatever reason SSL is then broken. I just reordered the logic to make it prefer 1.0.0. Thanks to Jonathan Dance for helping me reproduce the issue.)

    27 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • sso
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • ChrisChris commented  ·   ·  Flag as inappropriate

        Thanks jon!

        I uninstalled that openssl (no package required it).

        Hipchat 1.98.653 opened with nothing required on my part!

      • Jonathan DanceJonathan Dance commented  ·   ·  Flag as inappropriate

        Hi all- I reached out via support and worked with Ian on my issue - it seems openssl 0.9.8 is causing problems if you have that and openssl 1.0.0 installed. If you can live without it, try removing it:

        $ sudo pacman -R openssl098

      • ChrisChris commented  ·   ·  Flag as inappropriate

        Reverting back to 1.96.524 and moving out the shared libraries and I can at least use the app again.

        Are there any post install things I can do to get the latest version to work? Every time I upgrade I operate under the assumption that the package works with no modifications, but that is simply not the case for me.

        Is there anything I can provide to help debug this problem?

      • ChrisChris commented  ·   ·  Flag as inappropriate

        I just installed the latest version 1.97.610-1

        It still doesn't work for me. I'm not missing any dependencies

        [ccooper@ccooper-laptop ~]$ LD_LIBRARY_PATH=/opt/HipChat/lib/ ldd /opt/HipChat/lib/hipchat.bin

        no libraries reported missing

      • Ian MonroeAdminIan Monroe (Admin, HipChat) commented  ·   ·  Flag as inappropriate

        Chris, it works fine for me with Arch Linux x86_64. Probably the issue is one of the dependencies we don't provide. libxcb-sync.so.0 is the most likely candidate.

        If you run `hipchat --ldd` you can see if you are missing anything.

        John, trying to use it with Qt 5.0 will likely not be pretty. HipChat requires Qt 5.1 beta1.

      • Chris CooperChris Cooper commented  ·   ·  Flag as inappropriate

        I can no longer use the official package since 1.96.524

        Can you stop bundling system provide-able dependencies? What you are doing is a very mac/windows way of bundling. Do you guys test on arch linux 64? I can't be the only person this is broken for on this architecture.

      • ChrisChris commented  ·   ·  Flag as inappropriate

        why can't this package rely on and use the system packages? you are already going through the effort to make a package that is installable with arch linux package manager, just add the correct depends, etc and stop bundling them

        Also, how can a 64-bit architecture be causing problems in this day and age? Nearly all new systems support it, and I haven't used x86 in years

      • Jonathan DanceJonathan Dance commented  ·   ·  Flag as inappropriate

        Latest version adds qt5 libraries, which poses a new problem. The `qt5` package does not install all the required libraries as libQt5Sensors is missing. Installing this from AUR (qt5-sensors-git) is not much fun - it's currently in progress.

        Ian, It'd be great if you could fix the underlying problem here. I'm guessing that has to do with x86_64 compatibility.

      • Jordan EarlsJordan Earls commented  ·   ·  Flag as inappropriate

        @Jonathon That fixed everything for me! I also had problems with smileys not displaying. After moving the libraries so it uses my system's libraries, it now works perfectly :)

      • Jonathan DanceJonathan Dance commented  ·   ·  Flag as inappropriate

        Oops. Have a different system I was setting this up on, so following my own directions. So close. Last command should be:

        $ mv /opt/HipChat/lib/lib{Qt,ogg,vorbis}* /opt/HipChat/lib/bak

      • Jonathan DanceJonathan Dance commented  ·   ·  Flag as inappropriate

        Ok, I admit I didn't test that except with `ldd`. My current configuration is as follows:

        $ mkdir /opt/HipChat/lib/bak
        $ mv /opt/HipChat/lib/lib{Qt4,ogg,vorbis}* /opt/HipChat/lib/bak

        Naturally, you'll also need the qt4, libvorbis, and libogg packages installed:

        $ pacman -S qt4 libvorbis libogg

      • ChrisChris commented  ·   ·  Flag as inappropriate

        Setting the LD_LIBRARY_PATH did not work for me

        [ccooper@ccooper-laptop HipChat]$ hipchat
        /usr/bin/hipchat: symbol lookup error: /usr/bin/hipchat: undefined symbol: _ZN11ApplicationC1ERiPPc
        [ccooper@ccooper-laptop HipChat]$ cat /usr/bin/hipchat
        #!/bin/bash

        thisfile="`readlink -f "$0"`"
        thisdirectory="`dirname "$thisfile"`"
        hipchatRoot=$thisdirectory/../
        export LD_LIBRARY_PATH=/usr/lib:/opt/HipChat/lib
        unset QT_PLUGIN_PATH
        exec -a "$0" "$hipchatRoot/lib/hipchat.bin" "$@"

      • Jonathan DanceJonathan Dance commented  ·   ·  Flag as inappropriate

        I think the problem here is the libraries included with HipChat. By moving libraries out of /opt/Hipchat/lib that can already be installed in the system (I moved libQt, libogg, and libvorbis), HipChat will pick up these libraries from /usr/bin. Of course, for this to work for you you'll need to have these libraries installed from pacman.

        I'm guessing HipChat is using libQtNetwork for networking calls, which must be doing something different with SSL than my system libssl. Only with these libraries moved out of the way does `ldd` pick up libssl, so one of these libraries must be compiled statically with a different version of libssl in place.

        Ian, would it be possible to package HipChat with `qt4` as a dependency and not include the qt4 libraries? You could also do with `libvorbis` and `libogg`.

        Better yet would be to use `-R` when building HipChat so LD_LIBRARY_PATH is not needed, but I'm speaking out of my element here.
        http://xahlee.info/UnixResource_dir/_/ldpath.html

        For users looking for a quick fix, setting LD_LIBRARY_PATH to /usr/lib:/opt/HipChat/lib in /usr/bin/hipchat should also fix this.

      • Will BondWill Bond commented  ·   ·  Flag as inappropriate

        I am running a fully-patched Arch x64 install and getting SSL errors trying to log in. I also ran into the download link issue.

      • Jordan EarlsJordan Earls commented  ·   ·  Flag as inappropriate

        For those struggling to get this to work. Here is a grand list of issues and how to fix it.

        The x86_64 and i686 downloads are reversed. If you need x86_64, download from link labeled i686 and vice-versa.

        After installing with pacman -U, something will be wrong with SSL. It appears to look in the wrong place for certificates their particular certificate authority.

        Fix that by running

        sudo ln -s /etc/ssl/certs/DigiCert_High_Assurance_EV_Root_CA.pem /etc/ssl/certs/81b9768f.0

        To symlink the actual certificate file to where they expect to find it.

        Finally, after doing all that it worked perfectly. Hopefully they fix this to work right out of the box sometime soon.

      • Jonathan DanceJonathan Dance commented  ·   ·  Flag as inappropriate

        From strace, it's trying to verify a particular CA cert:

        ...
        stat("/etc/ssl/certs//81b9768f.0", 0x7fff1aebe340) = -1 ENOENT (No such file or directory)
        ...

        A quick Google search shows this should be "Digicert High Asurance EV Root CA" Cert:
        https://github.com/Tragidy/LightELF/blob/master/system/etc/security/cacerts/81b9768f.0

        More here:
        https://www.digicert.com/digicert-root-certificates.htm

        I do have that CA cert, but not with that signature:

        /etc/ssl/certs % ls -al | grep DigiCert_High
        lrwxrwxrwx 1 root root 38 Jan 24 21:13 244b5494.0 -> DigiCert_High_Assurance_EV_Root_CA.pem
        lrwxrwxrwx 1 root root 73 Jan 24 21:13 DigiCert_High_Assurance_EV_Root_CA.pem -> /usr/share/ca-certificates/mozilla/DigiCert_High_Assurance_EV_Root_CA.crt

        Strangely, I can't find any difference between this file and the 81b9 cert found on Github, and OpenSSL confirms that the 244b hash is correct for both files.

        ~ % openssl x509 -subject -hash -in ./81b9768f.0 -out /dev/null
        subject= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
        244b5494
        ~ % openssl x509 -subject -hash -in /etc/ssl/certs/DigiCert_High_Assurance_EV_Root_CA.pem -out /dev/null
        subject= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
        244b5494

        Obviously, a quick symlink will fix the issue here, but I'm a bit lost as to what the real cause of this issue is.

      ← Previous 1

      Feedback and Knowledge Base