2:48 p.m.
As I'm trying to create gtk-/gnome-/kde*-free environment (QtDesktop) -
I tested - what about Fedora without them?
So:
1. yum remove gtk3:
...
* gvfs
* qt-mobility
* qtwebkit
* ffmpeg
* ffmpeg-libs
* mplayer
* phonon
* smplayer
2. yum remove gtk2:
<all above>+
* ImageMagic
3. rpm -qa | grep gnome | xargs sudo yum remove
* git (???)
* gvfs
Question is: why?
3:58 p.m.
Eugene Pivnev wrote:
As I'm trying to create gtk-/gnome-/kde*-free environment
(QtDesktop) -
I tested - what about Fedora without them?
So:
1. yum remove gtk3:
...
* gvfs
* qt-mobility
* qtwebkit
* ffmpeg
* ffmpeg-libs
* mplayer
* phonon
* smplayer
2. yum remove gtk2:
<all above>+
* ImageMagick
The yum output from the above commands gives the why (admittedly in great
detail, so it's probably difficult to make sense of), but...
At least, one chain of dependencies is:
qtwebkit/qt-mobility/phonon -> ... -> gstreamer
and
gstreamer -> ... -> gtk2/gtk3
-- rex
4:07 p.m.
On 04/28/2013 10:58 PM, Rex Dieter wrote:
Eugene Pivnev wrote:
> As I'm trying to create gtk-/gnome-/kde*-free environment (QtDesktop) -
> I tested - what about Fedora without them?
> So:
> 1. yum remove gtk3:
> ...
> * gvfs
> * qt-mobility
> * qtwebkit
> * ffmpeg
> * ffmpeg-libs
> * mplayer
> * phonon
> * smplayer
> 2. yum remove gtk2:
> <all above>+
> * ImageMagick
The yum output from the above commands gives the why (admittedly in great
detail, so it's probably difficult to make sense of), but...
At least, one chain of dependencies is:
qtwebkit/qt-mobility/phonon -> ... -> gstreamer
and
gstreamer -> ... -> gtk2/gtk3
gtk or glib? imho gstreamer requires only glib...
--
Levente "Si vis pacem para bellum!"
5:16 p.m.
As pcmafm developer said - gvfm use gobject - but not gtk or gnome libs.
I showed only packages that I was surprised.
E.g. "ffmpeg requires gtk".
Very nice.
On 04/28/2013 10:58 PM, Rex Dieter wrote:
> Eugene Pivnev wrote:
>
>> As I'm trying to create gtk-/gnome-/kde*-free environment (QtDesktop) -
>> I tested - what about Fedora without them?
>> So:
>> 1. yum remove gtk3:
>> ...
>> * gvfs
>> * qt-mobility
>> * qtwebkit
>> * ffmpeg
>> * ffmpeg-libs
>> * mplayer
>> * phonon
>> * smplayer
>> 2. yum remove gtk2:
>> <all above>+
>> * ImageMagick
> The yum output from the above commands gives the why (admittedly in great
> detail, so it's probably difficult to make sense of), but...
>
> At least, one chain of dependencies is:
>
> qtwebkit/qt-mobility/phonon -> ... -> gstreamer
> and
> gstreamer -> ... -> gtk2/gtk3
gtk or glib? imho gstreamer requires only glib...
5:21 p.m.
2013/4/29 Eugene Pivnev <ti.eugene(a)gmail.com>
As pcmafm developer said - gvfm use gobject - but not gtk or gnome
libs.
I showed only packages that I was surprised.
E.g. "ffmpeg requires gtk".
Very nice.
It's probably because of opencv,
It can probably be spitted carefully at runtime, but opencv-devel cannot be
splitted yet.
(so patch welcomed).
Nicolas (kwizart)
11:59 a.m.
Whether it is possible to sane gsteamer and try to remove gtk?
And gvfs - removing *gnome*.
29.04.2013 01:07, Farkas Levente:
On 04/28/2013 10:58 PM, Rex Dieter wrote:
> Eugene Pivnev wrote:
>
>> As I'm trying to create gtk-/gnome-/kde*-free environment (QtDesktop) -
>> I tested - what about Fedora without them?
>> So:
>> 1. yum remove gtk3:
>> ...
>> * gvfs
>> * qt-mobility
>> * qtwebkit
>> * ffmpeg
>> * ffmpeg-libs
>> * mplayer
>> * phonon
>> * smplayer
>> 2. yum remove gtk2:
>> <all above>+
>> * ImageMagick
> The yum output from the above commands gives the why (admittedly in great
> detail, so it's probably difficult to make sense of), but...
>
> At least, one chain of dependencies is:
>
> qtwebkit/qt-mobility/phonon -> ... -> gstreamer
> and
> gstreamer -> ... -> gtk2/gtk3
gtk or glib? imho gstreamer requires only glib...
12:37 p.m.
On Mon, 2013-04-29 at 20:59 +0400, Eugene Pivnev wrote:
Whether it is possible to sane gsteamer and try to remove gtk?
And gvfs - removing *gnome*.
It appears that out of the entire gvfsd package, only:
/usr/libexec/gvfsd-recent
requires GTK libraries. Everything else is strictly non-GUI. That
could potentially be split out to a gvfs-recent that something GNOME-ish
then depends on perhaps.
Dan
29.04.2013 01:07, Farkas Levente:
> On 04/28/2013 10:58 PM, Rex Dieter wrote:
>> Eugene Pivnev wrote:
>>
>>> As I'm trying to create gtk-/gnome-/kde*-free environment (QtDesktop) -
>>> I tested - what about Fedora without them?
>>> So:
>>> 1. yum remove gtk3:
>>> ...
>>> * gvfs
>>> * qt-mobility
>>> * qtwebkit
>>> * ffmpeg
>>> * ffmpeg-libs
>>> * mplayer
>>> * phonon
>>> * smplayer
>>> 2. yum remove gtk2:
>>> <all above>+
>>> * ImageMagick
>> The yum output from the above commands gives the why (admittedly in great
>> detail, so it's probably difficult to make sense of), but...
>>
>> At least, one chain of dependencies is:
>>
>> qtwebkit/qt-mobility/phonon -> ... -> gstreamer
>> and
>> gstreamer -> ... -> gtk2/gtk3
> gtk or glib? imho gstreamer requires only glib...
>
12:50 p.m.
On Tue, 2013-04-30 at 19:38 +0400, Eugene A. Pivnev wrote:
30.04.2013 19:26, David Howells:
> Eugene Pivnev <ti.eugene(a)gmail.com> wrote:
>
>> 3. rpm -qa | grep gnome | xargs sudo yum remove
>> * git (???)
> gitk, I imagine.
>
> David
No. Exactly gnome:
bash-4.2$ rpm -q --requires git | grep gnome
libgnome-keyring.so.0
This could probably be ported to libsecret
2:46 a.m.
Whether I have to create bugreports?
BTW - gvfs requires as libsecret as libgnome-keyring.
30.04.2013 21:50, Matthias Clasen:
On Tue, 2013-04-30 at 19:38 +0400, Eugene A. Pivnev wrote:
> 30.04.2013 19:26, David Howells:
>> Eugene Pivnev <ti.eugene(a)gmail.com> wrote:
>>
>>> 3. rpm -qa | grep gnome | xargs sudo yum remove
>>> * git (???)
>> gitk, I imagine.
>>
>> David
> No. Exactly gnome:
> bash-4.2$ rpm -q --requires git | grep gnome
> libgnome-keyring.so.0
This could probably be ported to libsecret
1:01 p.m.
01.05.2013 23:07, Matthias Clasen:
On Wed, 2013-05-01 at 11:46 +0400, Eugene Pivnev wrote:
> Whether I have to create bugreports?
Creating patches would be more interesting.
Creating patches is greate idea - but
is too hard for one man.
I created dependency graph for some qt-based applications (green color)
against gtk*/*gnome* ones (red).
Sorry for big picture - it is because of loopbacks.
Problematic dependencies that I found:
qgit -> git -> libgnome_keyring
opencv -> gtk2;
xscreensaver_base -> libglade2 -> gtk2;
librsvg2 -> gtk3;
The question is - are these dependencies unbreakable?
2:22 p.m.
On Sat, 2013-05-11 at 22:01 +0400, Eugene Pivnev wrote:
01.05.2013 23:07, Matthias Clasen:
> On Wed, 2013-05-01 at 11:46 +0400, Eugene Pivnev wrote:
>> Whether I have to create bugreports?
> Creating patches would be more interesting.
Creating patches is greate idea - but is too hard for one man.
I created dependency graph for some qt-based applications (green color)
against gtk*/*gnome* ones (red).
*gnome* is too simplistic. There are 'GNOME' things that aren't really
that GNOME-y...
Sorry for big picture - it is because of loopbacks.
Problematic dependencies that I found:
qgit -> git -> libgnome_keyring
...like this one, for instance. libgnome-keyring's dependencies are
pretty modest:
/sbin/ldconfig
/sbin/ldconfig
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libdbus-1.so.3()(64bit)
libgcrypt.so.11()(64bit)
libgcrypt.so.11(GCRYPT_1.2)(64bit)
libglib-2.0.so.0()(64bit)
libgobject-2.0.so.0()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1
You can rip out gtk2 without losing libgnome-keyring.
opencv -> gtk2;
xscreensaver_base -> libglade2 -> gtk2;
librsvg2 -> gtk3;
These ones look a bit more significant. xscreensaver-base's dep on gtk2
in particular looks odd.
The question is - are these dependencies unbreakable?
Indeed...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:19 p.m.
Adam Williamson wrote, at 05/12/2013 04:22 AM +9:00:
On Sat, 2013-05-11 at 22:01 +0400, Eugene Pivnev wrote:
> Problematic dependencies that I found:
> xscreensaver_base -> libglade2 -> gtk2;
These ones look a bit more significant. xscreensaver-base's dep
on gtk2
in particular looks odd.
> The question is - are these dependencies unbreakable?
Indeed...
xscreensaver-demo, which is for configuring xscreensaver (daemon),
requires gtk2.
Regards,
Mamoru
10:59 p.m.
On 05/11/2013 11:19 PM, Mamoru TASAKA wrote:
xscreensaver-demo, which is for configuring xscreensaver (daemon),
requires gtk2.
IIRC KDE can use xscreensaver modules and if so, the user has no real
need of the demo command. It may be better to move xscreensaver-demo
into its own package
Rahul
4:21 a.m.
Rahul Sundaram wrote, at 05/12/2013 12:59 PM +9:00:
On 05/11/2013 11:19 PM, Mamoru TASAKA wrote:
>
> xscreensaver-demo, which is for configuring xscreensaver (daemon),
> requires gtk2.
IIRC KDE can use xscreensaver modules and if so, the user has no real need
of the demo command. It may be better to move xscreensaver-demo into its own package
Rahul
In this discussion xscreensaver dependency is not for xscreensaver modules
in KDE, but for razorqt{-panel}. It seems that razorqt _really_ wants to
launch xscreensaver daemon, so splitting out xscreensaver-demo from xscreensaver-base
does not help here.
Regards,
Mamoru
4:49 a.m.
Hi
On Sun, May 12, 2013 at 5:21 AM, Mamoru TASAKA wrote:
>>
In this discussion xscreensaver dependency is not for xscreensaver modules
in KDE, but for razorqt{-panel}. It seems that razorqt _really_ wants to
launch xscreensaver daemon, so splitting out xscreensaver-demo from
xscreensaver-base
does not help here.
I understand that. I was pointing out that it might be useful to split it
for the KDE case. If razor wants to provide its own gui to control the
daemon, it would help them as well.
Rahul
8:06 a.m.
Sorry, but as I found in xsceensaver-base (not xscreensaver itself!) -
it contains as xsceensaver as xscreensaver demo
(/usr/bin/xscreensaver-demo, glade based).
And no one xscreensaver config tool.
12.05.2013 13:21, Mamoru TASAKA:
Rahul Sundaram wrote, at 05/12/2013 12:59 PM +9:00:
> On 05/11/2013 11:19 PM, Mamoru TASAKA wrote:
>>
>> xscreensaver-demo, which is for configuring xscreensaver (daemon),
>> requires gtk2.
>
> IIRC KDE can use xscreensaver modules and if so, the user has no real
> need
> of the demo command. It may be better to move xscreensaver-demo into
> its own package
>
> Rahul
In this discussion xscreensaver dependency is not for xscreensaver
modules
in KDE, but for razorqt{-panel}. It seems that razorqt _really_ wants to
launch xscreensaver daemon, so splitting out xscreensaver-demo from
xscreensaver-base
does not help here.
Regards,
Mamoru
8:16 a.m.
No top-post please.
Eugene Pivnev wrote, at 05/12/2013 10:06 PM +9:00:
Sorry, but as I found in xsceensaver-base (not xscreensaver itself!)
- it contains as xsceensaver as xscreensaver demo (/usr/bin/xscreensaver-demo, glade
based).
And no one xscreensaver config tool.
xscreensaver-demo is the xscreensaver daemon configuration tool.
12.05.2013 13:21, Mamoru TASAKA:
> Rahul Sundaram wrote, at 05/12/2013 12:59 PM +9:00:
>> On 05/11/2013 11:19 PM, Mamoru TASAKA wrote:
>>>
>>> xscreensaver-demo, which is for configuring xscreensaver (daemon),
>>> requires gtk2.
>>
>> IIRC KDE can use xscreensaver modules and if so, the user has no real need
>> of the demo command. It may be better to move xscreensaver-demo into its own
package
>>
>> Rahul
>
> In this discussion xscreensaver dependency is not for xscreensaver modules
> in KDE, but for razorqt{-panel}. It seems that razorqt _really_ wants to
> launch xscreensaver daemon, so splitting out xscreensaver-demo from
xscreensaver-base
> does not help here.
Regards,
Mamoru
8:23 a.m.
Eugene Pivnev wrote, at 05/12/2013 10:09 PM +9:00:
12.05.2013 13:21, Mamoru TASAKA:
> It seems that razorqt _really_ wants to launch xscreensaver daemon, so splitting out
xscreensaver-demo from xscreensaver-base
> does not help here.
>
You mean - xscreensaver daemon depends on glade and/or gtk2 too?
Again xscreensaver configuration tool is written using glade and gtk2.
Regards,
Mamoru
8:28 a.m.
12.05.2013 17:23, Mamoru TASAKA:
Eugene Pivnev wrote, at 05/12/2013 10:09 PM +9:00:
> 12.05.2013 13:21, Mamoru TASAKA:
>> It seems that razorqt _really_ wants to launch xscreensaver daemon,
>> so splitting out xscreensaver-demo from xscreensaver-base
>> does not help here.
>>
> You mean - xscreensaver daemon depends on glade and/or gtk2 too?
Again xscreensaver configuration tool is written using glade and gtk2.
Regards,
Mamoru
Ok, I grasp it, thank you (too slow connection).
But if DE (like KDE) has its xscreensaver config tool...
11:29 p.m.
11.05.2013 23:22, Adam Williamson:
> qgit -> git -> libgnome_keyring
...like this one, for instance. libgnome-keyring's dependencies are
pretty modest:
As I found in git.spec - git's gnome-keyring suff is optional.
Is it possible to move them into separate package (for gnome users)?
5:31 p.m.
Eugene Pivnev wrote:
11.05.2013 23:22, Adam Williamson:
>> qgit -> git -> libgnome_keyring
> ...like this one, for instance. libgnome-keyring's dependencies are
> pretty modest:
As I found in git.spec - git's gnome-keyring suff is optional.
Is it possible to move them into separate package (for gnome users)?
This doesn't sound too unreasonable at first (and wasn't hard to do; I
tested it locally).
I am not convinced that it's worth the effort, though. All the
dependencies of libgnome-keyring are included in the minimal install.
So what would be the gain? (Splitting the package only to avoid
pulling in something with gnome in the name isn't enough. ;)
The cost would be causing users who want to use the git gnome
credential helper to install an additional package.
If this wasn't already in place, I'd probably be more inclined to add
it as a subpackage from the start. But now that it's included, I'm
not as sure that the costs are outweighed by any benefits.
I could be completely wrong, of course.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ocean, n. A body of water occupying about two-thirds of a world made
for man -- who has no gills.
-- Ambrose Bierce, "The Devil's Dictionary"
3:23 a.m.
13.05.2013 02:31, Todd Zullinger:
Eugene Pivnev wrote:
> 11.05.2013 23:22, Adam Williamson:
>>> qgit -> git -> libgnome_keyring
>> ...like this one, for instance. libgnome-keyring's dependencies are
>> pretty modest:
> As I found in git.spec - git's gnome-keyring suff is optional. Is it
> possible to move them into separate package (for gnome users)?
This doesn't sound too unreasonable at first (and wasn't hard to do; I
tested it locally).
I am not convinced that it's worth the effort, though. All the
dependencies of libgnome-keyring are included in the minimal install.
So what would be the gain? (Splitting the package only to avoid
pulling in something with gnome in the name isn't enough. ;)
The cost would be causing users who want to use the git gnome
credential helper to install an additional package.
If this wasn't already in place, I'd probably be more inclined to add
it as a subpackage from the start. But now that it's included, I'm
not as sure that the costs are outweighed by any benefits.
I could be completely wrong, of course.
The problem is that Fedora is too Gnome distro.
And instead of as Gnome/GTK spin builder as non-G* ones have clean
system and add required packages - G* users are happy but non-G* must to
pick out gtk/gnome from _clean_ system.
My aim is to create pure Qt4 spin (similar to pure KDE one).
As you can see - this task is not trivial. In contrast with pure GTK or
Gnome.
But - no pasaran!
8:57 a.m.
Eugene Pivnev wrote:
13.05.2013 02:31, Todd Zullinger:
> Eugene Pivnev wrote:
[...]
>> As I found in git.spec - git's gnome-keyring suff is
optional. Is
>> it possible to move them into separate package (for gnome users)?
>
> This doesn't sound too unreasonable at first (and wasn't hard to
> do; I tested it locally).
>
> I am not convinced that it's worth the effort, though. All the
> dependencies of libgnome-keyring are included in the minimal
> install. So what would be the gain? (Splitting the package only
> to avoid pulling in something with gnome in the name isn't enough.
> ;)
[...]
The problem is that Fedora is too Gnome distro.
And instead of as Gnome/GTK spin builder as non-G* ones have clean
system and add required packages - G* users are happy but non-G* must
to pick out gtk/gnome from _clean_ system.
My aim is to create pure Qt4 spin (similar to pure KDE one).
As you can see - this task is not trivial. In contrast with pure GTK
or Gnome.
Perhaps I wasn't clear about what I meant by "minimal install." I
performed a text mode install of F18, which consists of 235 packages.
(This is not a Gnome or KDE spin by any means.)
All of libgnome-keyring's dependencies are included in the minimal
spin. And as Florian pointed out, those dependencies would be pulled
in by Qt as well.
Splitting the credential helper from the git package just because the
dependency has the word gnome in it is not productive. Unless there's
some other compelling reason to split this out which has not been
mentioned yet, I don't have any plans to look at it further.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A little inaccuracy sometimes saves a ton of explanation.
-- H. H. Munro (Saki) (1870-1916)
10:30 a.m.
On Mon, 2013-05-13 at 12:23 +0400, Eugene Pivnev wrote:
13.05.2013 02:31, Todd Zullinger:
> Eugene Pivnev wrote:
>> 11.05.2013 23:22, Adam Williamson:
>>>> qgit -> git -> libgnome_keyring
>>> ...like this one, for instance. libgnome-keyring's dependencies are
>>> pretty modest:
>> As I found in git.spec - git's gnome-keyring suff is optional. Is it
>> possible to move them into separate package (for gnome users)?
>
> This doesn't sound too unreasonable at first (and wasn't hard to do; I
> tested it locally).
>
> I am not convinced that it's worth the effort, though. All the
> dependencies of libgnome-keyring are included in the minimal install.
> So what would be the gain? (Splitting the package only to avoid
> pulling in something with gnome in the name isn't enough. ;)
>
> The cost would be causing users who want to use the git gnome
> credential helper to install an additional package.
>
> If this wasn't already in place, I'd probably be more inclined to add
> it as a subpackage from the start. But now that it's included, I'm
> not as sure that the costs are outweighed by any benefits.
>
> I could be completely wrong, of course.
>
The problem is that Fedora is too Gnome distro.
That is a rant, not a description of a problem. The simple fact that the
package "libgnome-keyring" has the word "gnome" in it is not
sufficient
to qualify as a problem. As Todd wrote, libgnome-keyring itself has very
minimal dependencies, it does not require the rest of the GNOME
components. So the fact that git depends on it is not really a problem.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11:41 a.m.
13.05.2013 19:30, Adam Williamson:
> The problem is that Fedora is too Gnome distro.
That is a rant, not a description of a problem. The simple fact that the
package "libgnome-keyring" has the word "gnome" in it is not
sufficient
to qualify as a problem. As Todd wrote, libgnome-keyring itself has very
minimal dependencies, it does not require the rest of the GNOME
components. So the fact that git depends on it is not really a problem.
libgnome-keyring is minimal problem (ok - is _not_ problem at all;
although I'm surprised that _console_ git depends on DE-specific library).
Try "sudo yum remove gtk2 gtk3" at you host.
And then try to make job with this host.
6:38 p.m.
Eugene Pivnev wrote:
libgnome-keyring is minimal problem (ok - is _not_ problem at all;
although I'm surprised that _console_ git depends on DE-specific
library).
I just recently made use of libgnome-keyring via python-keyring for a
console application I wrote. I thought it was quite handy to be able
to add this ability and save a little effort for something I use
regularly for work (a paste app). Like git's use, my usage of the
keyring libraries was entirely optional and falls back gracefully to
other methods. The cost in code and time would be far greater to make
that optional bit a plugin or a subpackage. It was definitely not
worth my time to save < 300k of disk for the mythical system I might
want to install where I try to trim down the minimal install even
further.
We can stop talking about git using libgnome-keyring now, right? :)
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Anyone who is capable of getting themselves made President should on
no account be allowed to do the job.
-- Douglas Adams
2:02 a.m.
14.05.2013 03:38, Todd Zullinger пишет:
Eugene Pivnev wrote:
> libgnome-keyring is minimal problem (ok - is _not_ problem at all;
> although I'm surprised that _console_ git depends on DE-specific
> library).
I just recently made use of libgnome-keyring via python-keyring for a
console application I wrote. I thought it was quite handy to be able
to add this ability and save a little effort for something I use
regularly for work (a paste app). Like git's use, my usage of the
keyring libraries was entirely optional and falls back gracefully to
other methods. The cost in code and time would be far greater to make
that optional bit a plugin or a subpackage. It was definitely not
worth my time to save < 300k of disk for the mythical system I might
want to install where I try to trim down the minimal install even
further.
We can stop talking about git using libgnome-keyring now, right? :)
No problem!
Subject was "qt without gtk".
I can recall other problems:
* librsvg2 -> gtk3 - (as I know - fixed, but for F19+)
* xscreensaver_base -> libglade2 -> gtk2 (demo/configure tool)
* opencv -> gtk2
7:07 a.m.
Todd Zullinger wrote:
Eugene Pivnev wrote:
> 11.05.2013 23:22, Adam Williamson:
>>> qgit -> git -> libgnome_keyring
>> ...like this one, for instance. libgnome-keyring's dependencies are
>> pretty modest:
> As I found in git.spec - git's gnome-keyring suff is optional.
> Is it possible to move them into separate package (for gnome users)?
This doesn't sound too unreasonable at first (and wasn't hard to do; I
tested it locally).
I am not convinced that it's worth the effort, though.
Me either. keyring support is important, and it isn't onerous dependency-
wise (only pulls in glib2)
-- rex
7:27 a.m.
On 05/13/2013 02:07 PM, Rex Dieter wrote:
Todd Zullinger wrote:
> Eugene Pivnev wrote:
>> 11.05.2013 23:22, Adam Williamson:
>>>> qgit -> git -> libgnome_keyring
>>> ...like this one, for instance. libgnome-keyring's dependencies are
>>> pretty modest:
>> As I found in git.spec - git's gnome-keyring suff is optional.
>> Is it possible to move them into separate package (for gnome users)?
>
> This doesn't sound too unreasonable at first (and wasn't hard to do; I
> tested it locally).
>
> I am not convinced that it's worth the effort, though.
Me either. keyring support is important, and it isn't onerous dependency-
wise (only pulls in glib2)
... which Qt depends on for its event loop anyway.
--
Florian Weimer / Red Hat Product Security Team
2:59 p.m.
On 11/05/13 20:01, Eugene Pivnev wrote:
librsvg2 -> gtk3;
I have done a librsvg2 build which should fix this -- can you confirm if
it fixes it for you, and leave karma at Bodhi, please?
https://admin.fedoraproject.org/updates/librsvg2-2.37.0-3.fc19
--
Hope this helps,
Kalev
11:15 p.m.
11.05.2013 23:59, Kalev Lember:
On 11/05/13 20:01, Eugene Pivnev wrote:
> librsvg2 -> gtk3;
I have done a librsvg2 build which should fix this -- can you confirm if
it fixes it for you, and leave karma at Bodhi, please?
https://admin.fedoraproject.org/updates/librsvg2-2.37.0-3.fc19
Can't - I use F18, sorry :-(
1:33 p.m.
On 30.04.2013 17:49, Eugene A. Pivnev wrote:
30.04.2013 19:26, David Howells:
> Eugene Pivnev <ti.eugene(a)gmail.com> wrote:
>
>> 3. rpm -qa | grep gnome | xargs sudo yum remove
>> * git (???)
> gitk, I imagine.
>
> David
BTW - try to remove libgnome-keyring.
I'm surprised:
* PyQt4
* git
* gvfs
* kdelibs :-)))
* phonon
* qt-config
Even though it's called libGNOME-keyring, libgnome-keyring isn't GNOME
specific. But like Matthias said, porting to libsecret (which doesn't
have the unfortunate name) is definitely the way forward.
Cheers,
Stef
3993
days inactive
4009
days old
37 comments
14 participants
participants (14)
-
Adam Williamson -
Dan Williams -
David Howells -
Eugene Pivnev -
Farkas Levente -
Florian Weimer -
Kalev Lember -
Mamoru TASAKA -
Matthias Clasen -
Nicolas Chauvet -
Rahul Sundaram -
Rex Dieter -
Stef Walter -
Todd Zullinger