[Bug 1413338] New: xmonad session doesn't support GNOME keyring
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1413338
Bug ID: 1413338
Summary: xmonad session doesn't support GNOME keyring
Product: Fedora
Version: 25
Component: xmonad
Assignee: mathstuf(a)gmail.com
Reporter: simon.guest(a)tesujimath.org
QA Contact: extras-qa(a)fedoraproject.org
CC: haskell-devel(a)lists.fedoraproject.org,
mathstuf(a)gmail.com, petersen(a)redhat.com
Description of problem:
No support for GNOME keyring, which would need to be in xmonad-start script.
Version-Release number of selected component (if applicable):
0.12-2.fc25
How reproducible:
Login using the xmonad session from xmonad-basic package. Observe that e.g.
ssh keys are not cached.
Steps to Reproduce:
1. Login with xmonad session from gdm
2. ssh <somewhere>
Actual results:
have to type ssh passphrase, aarggh! :-)
Expected results:
ssh passphrase is available in GNOME keyring via the GNOME keyring daemon
Additional info:
I currently have to use a user script (i.e. ~/.xsession) to do this, rather
than the xmonad session from xmonad-basic package. It would be better if
/usr/bin/xmonad-start contained the following lines (given that Fedora is a
GNOME-based distro, so GNOME based solutions such as keyring are preferable to
e.g. pam_ssh (which is a bit troublesome, actually)):
# for GNOME keyring, see
https://blog.san-ss.com.ar/2011/03/using-gnome-keyring-in-xmonad
eval $(gnome-keyring-daemon --start)
export GNOME_KEYRING_SOCKET
export GNOME_KEYRING_PID
--
You are receiving this mail because:
You are on the CC list for the bug.
6 years, 4 months
[Bug 1375825] New: ghc-webkit must not depend on webkitgtk
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1375825
Bug ID: 1375825
Summary: ghc-webkit must not depend on webkitgtk
Product: Fedora
Version: rawhide
Component: ghc-webkit
Assignee: petersen(a)redhat.com
Reporter: mcatanzaro(a)gnome.org
QA Contact: extras-qa(a)fedoraproject.org
CC: haskell-devel(a)lists.fedoraproject.org,
petersen(a)redhat.com
Blocks: 1375784 (webkit1-removal)
The webkitgtk package will be removed from rawhide after Fedora 26 is branched
due to the high number of unfixed security vulnerabilities. You must remove
this dependency or your package will not be present in Fedora 27.
Please refer to [1] for a FAQ on this matter and be advised that for some
packages this may require a substantial amount of work.
Note: if ghc-webkit is a bindings package specifically intended to provide
WebKit1 or GTK+ 2 bindings, then it can safely be retired.
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1375784
[Bug 1375784] Port applications to WebKit2
--
You are receiving this mail because:
You are on the CC list for the bug.
6 years, 4 months
[Bug 1252723] New: git annex addurl fails if quvi is not installed
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1252723
Bug ID: 1252723
Summary: git annex addurl fails if quvi is not installed
Product: Fedora
Version: 22
Component: git-annex
Assignee: mathstuf(a)gmail.com
Reporter: dcleal(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: haskell-devel(a)lists.fedoraproject.org,
mathstuf(a)gmail.com
Description of problem:
Since Fedora 22, git-annex addurl fails when the video download tool "quvi" is
not installed. It appears to try and run "quvi --version" and should handle it
being missing, but instead the whole git-annex command fails.
This works correctly on Fedora 21.
Version-Release number of selected component (if applicable):
git-annex-5.20140717-6.fc22
How reproducible:
Always
Steps to Reproduce:
1. Commit an ordinary file to a git repository.
2. git annex addurl --file test http://example.com
Actual results:
git-annex: quvi: createProcess: runInteractiveProcess: exec: does not exist (No
such file or directory)
failed
git-annex: addurl: 1 failed
Expected results:
addurl test (downloading http://example.com ...)
[..]
ok
Additional info:
An strace of both F22 and F21 versions shows the same, that it's trying to run
the quvi command. I guess something in the exception handling has changed.
2065 execve("/usr/libexec/git-core/quvi", ["quvi", "--version"], [/* 26 vars
*/]) = -1 ENOENT (No such file or directory)
2065 execve("/usr/local/sbin/quvi", ["quvi", "--version"], [/* 26 vars */]) =
-1 ENOENT (No such file or directory)
2065 execve("/usr/local/bin/quvi", ["quvi", "--version"], [/* 26 vars */]) =
-1 ENOENT (No such file or directory)
2065 execve("/usr/sbin/quvi", ["quvi", "--version"], [/* 26 vars */]) = -1
ENOENT (No such file or directory)
2065 execve("/usr/bin/quvi", ["quvi", "--version"], [/* 26 vars */]) = -1
ENOENT (No such file or directory)
2065 execve("/root/bin/quvi", ["quvi", "--version"], [/* 26 vars */]) = -1
ENOENT (No such file or directory)
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=m3WSuOwrGZ&a=cc_unsubscribe
6 years, 9 months