10:36 a.m.
On Fri, Jan 21, 2011 at 11:03:02 -0500,
"Clyde E. Kunkel" <clydekunkel7734(a)cox.net> wrote:
Should they be visible?
I am not sure, but on a possibly related note, neither metacity nor
gnome-panel end up running and I have to manually start them to get
a usable desktop. I am not sure if they don't get started or crash.
I filed bugs for both of these.
11:08 a.m.
2011/1/21 Bruno Wolff III <bruno(a)wolff.to>
On Fri, Jan 21, 2011 at 11:03:02 -0500,
"Clyde E. Kunkel" <clydekunkel7734(a)cox.net> wrote:
> Should they be visible?
I am not sure, but on a possibly related note, neither metacity nor
gnome-panel end up running and I have to manually start them to get
a usable desktop. I am not sure if they don't get started or crash.
I filed bugs for both of these.
it may be related to a message about rt-kit being unable to become
<something i
don't remember>.
anyway, gnome + openbox works, somehow.
12:12 p.m.
On 01/21/2011 12:36 PM, Andre Robatino wrote:
Wow, this bug is four months old and no indication what is actually
wrong except maybe something to do with nautilus. The workarounds in
the bz don't work for me. Do we ping Tomáš Bžatek? Maybe he has more
information. I'll include him on this reply.
Regards,
OldFart
9:44 a.m.
2011/1/22 Matthias Clasen <mclasen(a)redhat.com>
On Fri, 2011-01-21 at 11:03 -0500, Clyde E. Kunkel wrote:
> Should they be visible?
GNOME 3 will not start nautilus by default.
Sorry, I should have probably announced this change hitting rawhide.
oh, but should it start panels? or at least the gnomeshell?
12:18 p.m.
On Sat, Jan 22, 2011 at 10:51:20 -0500,
Matthias Clasen <mclasen(a)redhat.com> wrote:
On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
>
> oh, but should it start panels? or at least the gnomeshell?
Yes, it starts gnome-shell, unless your system is not capable of running
it, in which case it starts gnome-panel+metacity.
There perhaps needs to be a check that gnome-shell is installed as well.
As I don't seem to have it installed and I don't get gnome-panel+metacity
started.
12:43 p.m.
On Sat, Jan 22, 2011 at 10:51:20 -0500,
Matthias Clasen <mclasen(a)redhat.com> wrote:
On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
>
> oh, but should it start panels? or at least the gnomeshell?
Yes, it starts gnome-shell, unless your system is not capable of running
it, in which case it starts gnome-panel+metacity.
I did a yum upgrade from F14 to rawhide a month or so ago and have been doing
contunuous updates since then. Nothing seems to have dragged in gnome-shell.
It's probably worth thinking about a way to it installed for people doing
yum upgrades from F13 or F14. I am not sure if using preupgrade has the same
issue or not.
1:05 p.m.
On Sat, 2011-01-22 at 12:43 -0600, Bruno Wolff III wrote:
On Sat, Jan 22, 2011 at 10:51:20 -0500,
Matthias Clasen <mclasen(a)redhat.com> wrote:
> On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
>
> >
> > oh, but should it start panels? or at least the gnomeshell?
>
> Yes, it starts gnome-shell, unless your system is not capable of running
> it, in which case it starts gnome-panel+metacity.
I did a yum upgrade from F14 to rawhide a month or so ago and have been doing
contunuous updates since then. Nothing seems to have dragged in gnome-shell.
It's probably worth thinking about a way to it installed for people doing
yum upgrades from F13 or F14. I am not sure if using preupgrade has the same
issue or not.
That is a good point. We should perhaps add a gnome-session ->
gnome-shell dependency.
1:16 p.m.
On Sat, Jan 22, 2011 at 7:05 PM, Matthias Clasen <mclasen(a)redhat.com> wrote:
On Sat, 2011-01-22 at 12:43 -0600, Bruno Wolff III wrote:
> On Sat, Jan 22, 2011 at 10:51:20 -0500,
> Matthias Clasen <mclasen(a)redhat.com> wrote:
> > On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
> >
> > >
> > > oh, but should it start panels? or at least the gnomeshell?
> >
> > Yes, it starts gnome-shell, unless your system is not capable of running
> > it, in which case it starts gnome-panel+metacity.
>
> I did a yum upgrade from F14 to rawhide a month or so ago and have been doing
> contunuous updates since then. Nothing seems to have dragged in gnome-shell.
> It's probably worth thinking about a way to it installed for people doing
> yum upgrades from F13 or F14. I am not sure if using preupgrade has the same
> issue or not.
That is a good point. We should perhaps add a gnome-session ->
gnome-shell dependency.
Please don't. There's a lot of devices that can't run gnome-shell but
can run the gnome 2 configuration perfectly. With dependencies like
that on devices with small amounts of space you end up with a lot of
extra stuff you don't want or need. There must some other way to
achieve it for those that want it without forcing those that can't
have or don't want it to have unnecessary isssues and deps.
Given that "yum upgrade" isn't a fully supported method for upgrade I
don't see any issue with documenting that they then need to do a "yum
groupinstall gnome3" as the documented ways of doing yum upgrade have
always suggested to do similar to get new apps that weren't previously
installed.
Peter
1:31 p.m.
On Sat, Jan 22, 2011 at 19:16:59 +0000,
Peter Robinson <pbrobinson(a)gmail.com> wrote:
Please don't. There's a lot of devices that can't run gnome-shell but
can run the gnome 2 configuration perfectly. With dependencies like
that on devices with small amounts of space you end up with a lot of
extra stuff you don't want or need. There must some other way to
achieve it for those that want it without forcing those that can't
have or don't want it to have unnecessary isssues and deps.
Ideally, I'd think you'd want to have it pulled in by default when going from
F13 or F14 to F15 (and probably F16) and then be able to removed it manually.
I don't know if there is some trickery with obsoletes that might get this
to work.
Given that "yum upgrade" isn't a fully supported method
for upgrade I
don't see any issue with documenting that they then need to do a "yum
groupinstall gnome3" as the documented ways of doing yum upgrade have
always suggested to do similar to get new apps that weren't previously
installed.
Preupgrades are officially supported. Do preupgrades have a way of specifying
that certain packages should be included without creating a hard dependency?
Also it seems that right now gnome-shell is a hard dependency for gnome as
metacity (at least, I don't know about compiz) doesn't get started by
default when gnome-shell is missing. I think that's probably just an oversight,
but they may be something more complex going on.
2:32 p.m.
On Sat, Jan 22, 2011 at 7:31 PM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Sat, Jan 22, 2011 at 19:16:59 +0000,
Peter Robinson <pbrobinson(a)gmail.com> wrote:
>
> Please don't. There's a lot of devices that can't run gnome-shell but
> can run the gnome 2 configuration perfectly. With dependencies like
> that on devices with small amounts of space you end up with a lot of
> extra stuff you don't want or need. There must some other way to
> achieve it for those that want it without forcing those that can't
> have or don't want it to have unnecessary isssues and deps.
Ideally, I'd think you'd want to have it pulled in by default when going from
F13 or F14 to F15 (and probably F16) and then be able to removed it manually.
I don't know if there is some trickery with obsoletes that might get this
to work.
Well you'd want to be able to exclude it as well and adding it as an
artificial dep to something like gnome-session won't allow it to be
removed.
> Given that "yum upgrade" isn't a fully supported
method for upgrade I
> don't see any issue with documenting that they then need to do a "yum
> groupinstall gnome3" as the documented ways of doing yum upgrade have
> always suggested to do similar to get new apps that weren't previously
> installed.
Preupgrades are officially supported. Do preupgrades have a way of specifying
that certain packages should be included without creating a hard dependency?
Also it seems that right now gnome-shell is a hard dependency for gnome as
metacity (at least, I don't know about compiz) doesn't get started by
default when gnome-shell is missing. I think that's probably just an oversight,
but they may be something more complex going on.
Metacity works fine for me in rawhide
Peter
2:56 p.m.
On Sat, Jan 22, 2011 at 14:32, Peter Robinson <pbrobinson(a)gmail.com> wrote:
Well you'd want to be able to exclude it as well and adding it as
an
artificial dep to something like gnome-session won't allow it to be
removed.
GNOME Shell is the shell of GNOME 3 and thus depending on the GNOME Shell
from the gnome-session from GNOME 3 is not artificial but rather a
requirement. The fallback mode is intended as a fallback for driver and VM
problems, not as first-class desktop environment. You will be allowed to
force it to use the fallback mode should the detection fail to understand
your hardware but that's not quite there yet. See here:
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00008.html
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00138.html
So, doing what you describe from the UI makes a lot more sense (and
explaining why) from a user perspective than, "If you drivers don't work do
this magic with the package manager." The former is helpful; the later is
pain.
4:22 p.m.
On Sat, Jan 22, 2011 at 8:56 PM, Jason D. Clinton <me(a)jasonclinton.com> wrote:
On Sat, Jan 22, 2011 at 14:32, Peter Robinson
<pbrobinson(a)gmail.com> wrote:
>
> Well you'd want to be able to exclude it as well and adding it as an
> artificial dep to something like gnome-session won't allow it to be
> removed.
GNOME Shell is the shell of GNOME 3 and thus depending on the GNOME Shell
from the gnome-session from GNOME 3 is not artificial but rather a
requirement. The fallback mode is intended as a fallback for driver and VM
problems, not as first-class desktop environment. You will be allowed to
force it to use the fallback mode should the detection fail to understand
your hardware but that's not quite there yet. See here:
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00008.html
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00138.html
So, doing what you describe from the UI makes a lot more sense (and
explaining why) from a user perspective than, "If you drivers don't work do
this magic with the package manager." The former is helpful; the later is
pain.
what about users choice? Isn't that what free software is about?
Peter
4:29 p.m.
On Sat, Jan 22, 2011 at 11:22 PM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Sat, Jan 22, 2011 at 8:56 PM, Jason D. Clinton
<me(a)jasonclinton.com> wrote:
> On Sat, Jan 22, 2011 at 14:32, Peter Robinson <pbrobinson(a)gmail.com> wrote:
>>
>> Well you'd want to be able to exclude it as well and adding it as an
>> artificial dep to something like gnome-session won't allow it to be
>> removed.
>
> GNOME Shell is the shell of GNOME 3 and thus depending on the GNOME Shell
> from the gnome-session from GNOME 3 is not artificial but rather a
> requirement. The fallback mode is intended as a fallback for driver and VM
> problems, not as first-class desktop environment. You will be allowed to
> force it to use the fallback mode should the detection fail to understand
> your hardware but that's not quite there yet. See here:
>
> http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00008.html
>
> http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00138.html
>
> So, doing what you describe from the UI makes a lot more sense (and
> explaining why) from a user perspective than, "If you drivers don't work do
> this magic with the package manager." The former is helpful; the later is
> pain.
what about users choice? Isn't that what free software is about?
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html
4:57 p.m.
On Sat, Jan 22, 2011 at 10:22:28PM +0000, Peter Robinson wrote:
what about users choice? Isn't that what free software is about?
You have the freedom to modify the packages to remove any dependencies
you want to. You don't have the freedom to insist that packagers support
that use case.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
5:05 p.m.
On Sat, Jan 22, 2011 at 10:57 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Sat, Jan 22, 2011 at 10:22:28PM +0000, Peter Robinson wrote:
> what about users choice? Isn't that what free software is about?
You have the freedom to modify the packages to remove any dependencies
you want to. You don't have the freedom to insist that packagers support
that use case.
So what are all the people that don't have video cards suppose to do
that don't support 3D. Use KDE? I thought gnome was continuing to
support that use case?
Peter
5:07 p.m.
On Sun, Jan 23, 2011 at 12:05 AM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Sat, Jan 22, 2011 at 10:57 PM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> On Sat, Jan 22, 2011 at 10:22:28PM +0000, Peter Robinson wrote:
>
>> what about users choice? Isn't that what free software is about?
>
> You have the freedom to modify the packages to remove any dependencies
> you want to. You don't have the freedom to insist that packagers support
> that use case.
So what are all the people that don't have video cards suppose to do
that don't support 3D. Use KDE? I thought gnome was continuing to
support that use case?
And it still does ... in that case it will start metacity and
gnome-panel even without user interaction. (which has nothing to do
with package dependencies other than a few megabytes of disk space
that aren't worth worrying about imo).
9:12 a.m.
Am Sonntag, den 23.01.2011, 00:07 +0100 schrieb drago01:
On Sun, Jan 23, 2011 at 12:05 AM, Peter Robinson
<pbrobinson(a)gmail.com> wrote:
> On Sat, Jan 22, 2011 at 10:57 PM, Matthew Garrett <mjg59(a)srcf.ucam.org>
wrote:
>> On Sat, Jan 22, 2011 at 10:22:28PM +0000, Peter Robinson wrote:
>>
>>> what about users choice? Isn't that what free software is about?
>>
>> You have the freedom to modify the packages to remove any dependencies
>> you want to. You don't have the freedom to insist that packagers support
>> that use case.
>
> So what are all the people that don't have video cards suppose to do
> that don't support 3D. Use KDE? I thought gnome was continuing to
> support that use case?
And it still does ... in that case it will start metacity and
gnome-panel even without user interaction. (which has nothing to do
with package dependencies other than a few megabytes of disk space
that aren't worth worrying about imo).
It's not (only) about a few megabytes on installed system but about
space on the install media and especially on the spins. With this
change, we would get gnome-shell on almost any spin and they all would
be larger than CD size then.
Regards,
Christoph
5:40 p.m.
On 1/22/2011 6:05 PM, Peter Robinson wrote:
On Sat, Jan 22, 2011 at 10:57 PM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> On Sat, Jan 22, 2011 at 10:22:28PM +0000, Peter Robinson wrote:
>
>> what about users choice? Isn't that what free software is about?
>
> You have the freedom to modify the packages to remove any dependencies
> you want to. You don't have the freedom to insist that packagers support
> that use case.
So what are all the people that don't have video cards suppose to do
that don't support 3D. Use KDE? I thought gnome was continuing to
support that use case?
IMO.
t is the users of KDE that are entwined with K<some_name> applications. :-)
That is not the case with Gnome users. When Fedora 'broke'? the Gnome
Desktop in Fedora 15/Rawhide I switched to XFCE. I still use the same
major applications. The same Fedora GUI configuration applications. The
only 'new things' <gasp> that I had to get used to was a slightly
different looking terminal window, a slightly different looking file
manger, and a slightly different looking desktop. That took about 10
minutes.
--
David
5:58 p.m.
On Sat, 2011-01-22 at 23:05 +0000, Peter Robinson wrote:
On Sat, Jan 22, 2011 at 10:57 PM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> On Sat, Jan 22, 2011 at 10:22:28PM +0000, Peter Robinson wrote:
>
>> what about users choice? Isn't that what free software is about?
>
> You have the freedom to modify the packages to remove any dependencies
> you want to. You don't have the freedom to insist that packagers support
> that use case.
So what are all the people that don't have video cards suppose to do
that don't support 3D. Use KDE? I thought gnome was continuing to
support that use case?
Yes, thats the much-talked about fallback. Supporting that does not mean
that we have to support only installing the half of the desktop you
want.
12:58 a.m.
> So what are all the people that don't have video cards suppose to do
> that don't support 3D. Use KDE? I thought gnome was continuing to
> support that use case?
Yes, thats the much-talked about fallback. Supporting that does not mean
that we have to support only installing the half of the desktop you
want.
maybe the problem is somewhere else: why gnome does not switch to plan b if
gnome-shell is not installed?
10:28 a.m.
Am Samstag, den 22.01.2011, 14:56 -0600 schrieb Jason D. Clinton:
On Sat, Jan 22, 2011 at 14:32, Peter Robinson
<pbrobinson(a)gmail.com>
wrote:
Well you'd want to be able to exclude it as well and adding it
as an
artificial dep to something like gnome-session won't allow it
to be
removed.
GNOME Shell is the shell of GNOME 3 and thus depending on the GNOME
Shell from the gnome-session from GNOME 3 is not artificial but rather
a requirement.
There is not technical reason why gnome-session needs to depend on
gnome-shell, this the dependency is artificial.
If the only purpose is is to pull something in during an update there
are smarter ways, e.g. let a virtual package that depends on gnome-shell
provide/obsolete something that was installed before.
The fallback mode is intended as a fallback for driver and VM
problems, not as first-class desktop environment.
But that doesn't mean that the default always needs to be installed,
does it?
Also keep in mind that there are other "first-class desktop
environment". Moblin is just as much a GNOME based first-class desktop
environment as gnome-shell, just for a different use-case (Netbooks).
There are other use cases as well, say computers with limited hardware.
I really hope GNOME has learned a lesson from the KDE4 transition and
will work on providing a sane fallback, otherwise they will loose many
users just as KDE did.
You will be allowed to force it to use the fallback mode should the
detection fail to understand your hardware but that's not quite there
yet. See here:
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00008.html
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00138.html
So, doing what you describe from the UI makes a lot more sense (and
explaining why) from a user perspective than, "If you drivers don't
work do this magic with the package manager." The former is helpful;
the later is pain.
It's not "If you drivers don't work do this magic with the package
manager." but more "Our fallback doesn't work properly and we use the
package manager to fix it."
Regards,
Christoph
10:29 a.m.
On Sun, Jan 23, 2011 at 17:28:03 +0100,
Christoph Wickert <christoph.wickert(a)googlemail.com> wrote:
If the only purpose is is to pull something in during an update there
are smarter ways, e.g. let a virtual package that depends on gnome-shell
provide/obsolete something that was installed before.
I was wondering if there would be a tricky way to do this kind of thing. Is
there a more detailed write up of this procedure on the wiki somewhere?
It seems like it would be good to capture this knowledge and try to put it
somewhere where packages can find it.
11:12 a.m.
On 01/23/2011 09:58 PM, Christoph Wickert wrote:
Also keep in mind that there are other "first-class desktop
environment". Moblin is just as much a GNOME based first-class desktop
environment as gnome-shell, just for a different use-case (Netbooks).
I don't think that's the case. GNOME Shell is a integral part of GNOME
3. Moblin upstream seems only interested in being a complete OS and
haven't cooperated well with other projects which want to include Moblin
as a alternative UI in their distributions. Conman, trademark
shenanigans etc. I understand the point you are trying to make but
Moblin is really a poor example to pick.
Rahul
11:28 a.m.
On Sun, Jan 23, 2011 at 5:12 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
On 01/23/2011 09:58 PM, Christoph Wickert wrote:
>
> Also keep in mind that there are other "first-class desktop
> environment". Moblin is just as much a GNOME based first-class desktop
> environment as gnome-shell, just for a different use-case (Netbooks).
I don't think that's the case. GNOME Shell is a integral part of GNOME
3. Moblin upstream seems only interested in being a complete OS and
haven't cooperated well with other projects which want to include Moblin
as a alternative UI in their distributions. Conman, trademark
shenanigans etc. I understand the point you are trying to make but
Moblin is really a poor example to pick.
Moblin is dead. MeeGo is somewhere between both arguments and there's
network-manager-netbook replacement for connman, and the trademark
issues are well and being dealt with and should be a non issue in time
for F-15. Its also based on mutter, so its not that different from
gnome-shell (hopefully even the fork might soon be resolved).
Peter
11:34 a.m.
On 01/23/2011 10:58 PM, Peter Robinson wrote
Moblin is dead. MeeGo is somewhere between both arguments and
there's
network-manager-netbook replacement for connman, and the trademark
issues are well and being dealt with and should be a non issue in time
for F-15. Its also based on mutter, so its not that different from
gnome-shell (hopefully even the fork might soon be resolved)
Good to know but so far I have been disappointed with them. Did the
problem of srpm's having newer versions than what was available in their
git branches get resolved as well?
Rahul
12:19 p.m.
Am Sonntag, den 23.01.2011, 22:42 +0530 schrieb Rahul Sundaram:
On 01/23/2011 09:58 PM, Christoph Wickert wrote:
>
> Also keep in mind that there are other "first-class desktop
> environment". Moblin is just as much a GNOME based first-class desktop
> environment as gnome-shell, just for a different use-case (Netbooks).
I don't think that's the case. GNOME Shell is a integral part of GNOME
3. Moblin upstream seems only interested in being a complete OS and
haven't cooperated well with other projects which want to include Moblin
as a alternative UI in their distributions. Conman, trademark
shenanigans etc. I understand the point you are trying to make but
Moblin is really a poor example to pick.
I agree it's a poor example and Ubuntu's Unity is yet another one
because they don't cooperate well ether. Nevertheless all these are user
interfaces based on GNOME technology. They are not default and seriously
shouldn't be but it is a fact that there is more than just one desktop,
more than just gnome-shell. Thus we should not force our users to
install things they cannot use or don't want to.
Regards,
Christoph
1:01 p.m.
On Sun, Jan 23, 2011 at 7:19 PM, Christoph Wickert
<christoph.wickert(a)googlemail.com> wrote:
Am Sonntag, den 23.01.2011, 22:42 +0530 schrieb Rahul Sundaram:
> On 01/23/2011 09:58 PM, Christoph Wickert wrote:
> >
> > Also keep in mind that there are other "first-class desktop
> > environment". Moblin is just as much a GNOME based first-class desktop
> > environment as gnome-shell, just for a different use-case (Netbooks).
>
> I don't think that's the case. GNOME Shell is a integral part of GNOME
> 3. Moblin upstream seems only interested in being a complete OS and
> haven't cooperated well with other projects which want to include Moblin
> as a alternative UI in their distributions. Conman, trademark
> shenanigans etc. I understand the point you are trying to make but
> Moblin is really a poor example to pick.
I agree it's a poor example and Ubuntu's Unity is yet another one
because they don't cooperate well ether. Nevertheless all these are user
interfaces based on GNOME technology. They are not default and seriously
shouldn't be
gnome-shell *is* the default gnome user interface starting with gnome3.
2:10 p.m.
Am Sonntag, den 23.01.2011, 20:01 +0100 schrieb drago01:
On Sun, Jan 23, 2011 at 7:19 PM, Christoph Wickert
<christoph.wickert(a)googlemail.com> wrote:
> Am Sonntag, den 23.01.2011, 22:42 +0530 schrieb Rahul Sundaram:
>> On 01/23/2011 09:58 PM, Christoph Wickert wrote:
>> >
>> > Also keep in mind that there are other "first-class desktop
>> > environment". Moblin is just as much a GNOME based first-class
desktop
>> > environment as gnome-shell, just for a different use-case (Netbooks).
>>
>> I don't think that's the case. GNOME Shell is a integral part of GNOME
>> 3. Moblin upstream seems only interested in being a complete OS and
>> haven't cooperated well with other projects which want to include Moblin
>> as a alternative UI in their distributions. Conman, trademark
>> shenanigans etc. I understand the point you are trying to make but
>> Moblin is really a poor example to pick.
>
> I agree it's a poor example and Ubuntu's Unity is yet another one
> because they don't cooperate well ether. Nevertheless all these are user
> interfaces based on GNOME technology. They are not default and seriously
> shouldn't be
gnome-shell *is* the default gnome user interface starting with gnome3.
I didn't claim something different. I said that *Unity and Moblin* are
not default, but regardless of what is default, we shouldn't force users
to install something they ether don't want to use or cannot even use.
Regards,
Christoph
10:56 p.m.
On Sun, 2011-01-23 at 22:42 +0530, Rahul Sundaram wrote:
On 01/23/2011 09:58 PM, Christoph Wickert wrote:
>
> Also keep in mind that there are other "first-class desktop
> environment". Moblin is just as much a GNOME based first-class desktop
> environment as gnome-shell, just for a different use-case (Netbooks).
I don't think that's the case. GNOME Shell is a integral part of GNOME
3. Moblin upstream seems only interested in being a complete OS and
haven't cooperated well with other projects which want to include Moblin
as a alternative UI in their distributions. Conman, trademark
shenanigans etc. I understand the point you are trying to make but
Moblin is really a poor example to pick.
I can cite Unity, if you think it would help.
(runs away laughing maniacally)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:45 p.m.
On Sat, Jan 22, 2011 at 8:16 PM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Sat, Jan 22, 2011 at 7:05 PM, Matthias Clasen
<mclasen(a)redhat.com> wrote:
> On Sat, 2011-01-22 at 12:43 -0600, Bruno Wolff III wrote:
>> On Sat, Jan 22, 2011 at 10:51:20 -0500,
>> Matthias Clasen <mclasen(a)redhat.com> wrote:
>> > On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
>> >
>> > >
>> > > oh, but should it start panels? or at least the gnomeshell?
>> >
>> > Yes, it starts gnome-shell, unless your system is not capable of running
>> > it, in which case it starts gnome-panel+metacity.
>>
>> I did a yum upgrade from F14 to rawhide a month or so ago and have been doing
>> contunuous updates since then. Nothing seems to have dragged in gnome-shell.
>> It's probably worth thinking about a way to it installed for people doing
>> yum upgrades from F13 or F14. I am not sure if using preupgrade has the same
>> issue or not.
>
> That is a good point. We should perhaps add a gnome-session ->
> gnome-shell dependency.
Please don't. There's a lot of devices that can't run gnome-shell but
can run the gnome 2 configuration perfectly. With dependencies like
that on devices with small amounts of space you end up with a lot of
extra stuff you don't want or need.
gnome-shell should not end up being a space problem, if it is you'd be
worried where the user is supposed to store his/here data ...
2:34 p.m.
On Sat, Jan 22, 2011 at 7:45 PM, drago01 <drago01(a)gmail.com> wrote:
On Sat, Jan 22, 2011 at 8:16 PM, Peter Robinson
<pbrobinson(a)gmail.com> wrote:
> On Sat, Jan 22, 2011 at 7:05 PM, Matthias Clasen <mclasen(a)redhat.com> wrote:
>> On Sat, 2011-01-22 at 12:43 -0600, Bruno Wolff III wrote:
>>> On Sat, Jan 22, 2011 at 10:51:20 -0500,
>>> Matthias Clasen <mclasen(a)redhat.com> wrote:
>>> > On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
>>> >
>>> > >
>>> > > oh, but should it start panels? or at least the gnomeshell?
>>> >
>>> > Yes, it starts gnome-shell, unless your system is not capable of
running
>>> > it, in which case it starts gnome-panel+metacity.
>>>
>>> I did a yum upgrade from F14 to rawhide a month or so ago and have been
doing
>>> contunuous updates since then. Nothing seems to have dragged in gnome-shell.
>>> It's probably worth thinking about a way to it installed for people
doing
>>> yum upgrades from F13 or F14. I am not sure if using preupgrade has the same
>>> issue or not.
>>
>> That is a good point. We should perhaps add a gnome-session ->
>> gnome-shell dependency.
>
> Please don't. There's a lot of devices that can't run gnome-shell but
> can run the gnome 2 configuration perfectly. With dependencies like
> that on devices with small amounts of space you end up with a lot of
> extra stuff you don't want or need.
gnome-shell should not end up being a space problem, if it is you'd be
worried where the user is supposed to store his/here data ...
On something like an XO-1 where it only has 1gb of storage anything
extra removes space for user data. And you could have a different
device for /home anyway
Peter
11:38 a.m.
Peter Robinson (pbrobinson(a)gmail.com) said:
> gnome-shell should not end up being a space problem, if it is
you'd be
> worried where the user is supposed to store his/here data ...
On something like an XO-1 where it only has 1gb of storage anything
extra removes space for user data. And you could have a different
device for /home anyway
An XO-1 is a special-purpose device that is probably best served by a
special-purpose OS in any case, IMO.
Bill
11:58 a.m.
On Mon, Jan 24, 2011 at 5:38 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Peter Robinson (pbrobinson(a)gmail.com) said:
> > gnome-shell should not end up being a space problem, if it is you'd be
> > worried where the user is supposed to store his/here data ...
>
> On something like an XO-1 where it only has 1gb of storage anything
> extra removes space for user data. And you could have a different
> device for /home anyway
An XO-1 is a special-purpose device that is probably best served by a
special-purpose OS in any case, IMO.
we've had that discussion, please go and read back through the list archives.
Peter
12:06 p.m.
Peter Robinson (pbrobinson(a)gmail.com) said:
>> > gnome-shell should not end up being a space problem, if
it is you'd be
>> > worried where the user is supposed to store his/here data ...
>>
>> On something like an XO-1 where it only has 1gb of storage anything
>> extra removes space for user data. And you could have a different
>> device for /home anyway
>
> An XO-1 is a special-purpose device that is probably best served by a
> special-purpose OS in any case, IMO.
we've had that discussion, please go and read back through the list archives.
Sure, but compare the space used by gnome-shell + mutter, vs the space
used by xorg-x11-drivers and its dependencies, or all the other kernel
modules that don't serve a purpose on a hardware platform like XO.
Bill
12:12 p.m.
On Mon, Jan 24, 2011 at 6:06 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Peter Robinson (pbrobinson(a)gmail.com) said:
> >> > gnome-shell should not end up being a space problem, if it is you'd
be
> >> > worried where the user is supposed to store his/here data ...
> >>
> >> On something like an XO-1 where it only has 1gb of storage anything
> >> extra removes space for user data. And you could have a different
> >> device for /home anyway
> >
> > An XO-1 is a special-purpose device that is probably best served by a
> > special-purpose OS in any case, IMO.
>
> we've had that discussion, please go and read back through the list archives.
Sure, but compare the space used by gnome-shell + mutter, vs the space
used by xorg-x11-drivers and its dependencies, or all the other kernel
modules that don't serve a purpose on a hardware platform like XO.
Yes, I agree wholeheartedly, but that's not what I'm asking for. I'm
asking that gnome 2 desktop, that works very well in the non 3D
desktop space like the XO, not to be coupled with gnome-shell / gnome
3 dependencies :-) nothing more than that.
Peter
9:03 a.m.
Am Samstag, den 22.01.2011, 14:05 -0500 schrieb Matthias Clasen:
On Sat, 2011-01-22 at 12:43 -0600, Bruno Wolff III wrote:
> On Sat, Jan 22, 2011 at 10:51:20 -0500,
> Matthias Clasen <mclasen(a)redhat.com> wrote:
> > On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
> >
> > >
> > > oh, but should it start panels? or at least the gnomeshell?
> >
> > Yes, it starts gnome-shell, unless your system is not capable of running
> > it, in which case it starts gnome-panel+metacity.
>
> I did a yum upgrade from F14 to rawhide a month or so ago and have been doing
> contunuous updates since then. Nothing seems to have dragged in gnome-shell.
> It's probably worth thinking about a way to it installed for people doing
> yum upgrades from F13 or F14. I am not sure if using preupgrade has the same
> issue or not.
That is a good point. We should perhaps add a gnome-session ->
gnome-shell dependency.
Please don't. GDM already requires gnome-session and with gnome-shell
and it's deps the Xfce spin would be way over CD size.
Regards,
Christoph
9:32 a.m.
On Sun, Jan 23, 2011 at 3:10 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
On 01/23/2011 08:33 PM, Christoph Wickert wrote:
> Please don't. GDM already requires gnome-session and with gnome-shell
> and it's deps the Xfce spin would be way over CD size.
Any particular reason, Xfce spin is not using a different DM?
Both Sugar and MeeGo use GDM as well because they both have
dependencies on gtk and other similar deps to gnome so you don't pull
in more deps, and its also the best supported.
Peter
10:05 a.m.
Am Sonntag, den 23.01.2011, 20:40 +0530 schrieb Rahul Sundaram:
On 01/23/2011 08:33 PM, Christoph Wickert wrote:
> Please don't. GDM already requires gnome-session and with gnome-shell
> and it's deps the Xfce spin would be way over CD size.
Any particular reason, Xfce spin is not using a different DM?
Because there is no good alternative:
* SLIM has problems with ConsoleKit and is dead upstream
* LXDM is does not offer a keyboard selection and is broken in
many ways, too.
* Light-DM is not yet packaged but also kind of broken
Regards,
Christoph
2:16 p.m.
On 01/23/2011 09:35 PM, Christoph Wickert wrote:
* Light-DM is not yet packaged but also kind of broken
Would be useful to know what is broken. My understanding is that Ubuntu
(and variants) are keen on using this as a replacement for GDM
(http://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00226.html)
and I would have expected it to be functional. Perhaps the way forward
for the "lighter" desktop environments is to switch to something like
this.
Rahul
1:48 a.m.
just curious, after gnome-shell starts, should i see a network manager icon
somewhere? because the internet connection fails here, by default.
9:53 a.m.
On Sun, Jan 23, 2011 at 16:03:13 +0100,
Christoph Wickert <christoph.wickert(a)googlemail.com> wrote:
Please don't. GDM already requires gnome-session and with gnome-shell
and it's deps the Xfce spin would be way over CD size.
Note that live spins should be getting back some space (probably about 50 MB
for CD size images) this release as the xz stuff is coming together. I have
already had a successful test fo a spin using xz and have asked nirik to
start using xz for the nightly composes. So hopefully they'll be a noticeable
drop in spin sizes in the next couple of days.
10:17 a.m.
Am Sonntag, den 23.01.2011, 09:53 -0600 schrieb Bruno Wolff III:
On Sun, Jan 23, 2011 at 16:03:13 +0100,
Christoph Wickert <christoph.wickert(a)googlemail.com> wrote:
>
> Please don't. GDM already requires gnome-session and with gnome-shell
> and it's deps the Xfce spin would be way over CD size.
Note that live spins should be getting back some space (probably about 50 MB
for CD size images) this release as the xz stuff is coming together. I have
already had a successful test fo a spin using xz and have asked nirik to
start using xz for the nightly composes. So hopefully they'll be a noticeable
drop in spin sizes in the next couple of days.
Glad to hear that, but it's not really a solution. In the past we had to
reduce the number of applications with every release because the
dependency footprint became worse and worse. Now we cannot even ship
gnumeric in the Xfce spin any longer. I am pretty sure our users don't
want us to spend the new space with an additional desktop they cannot /
don't want use.
BTW: FESCo started an effort to cut excessive dependencies. Looking at
https://bugzilla.redhat.com/showdependencytree.cgi?id=661442 you will
see that our GNOME maintainers are very unresponsive to the bugs we
file.
Regards,
Christoph
10:18 a.m.
On Sun, Jan 23, 2011 at 17:17:38 +0100,
Christoph Wickert <christoph.wickert(a)googlemail.com> wrote:
Glad to hear that, but it's not really a solution. In the past we had to
reduce the number of applications with every release because the
dependency footprint became worse and worse. Now we cannot even ship
gnumeric in the Xfce spin any longer. I am pretty sure our users don't
want us to spend the new space with an additional desktop they cannot /
don't want use.
It buys time. In this case I think it makes sense to have a dependency for
two release to help people upgrading. After that I would expect the dependency
to be dropped as people should have already upgraded or be doing fresh
installs, so that they have gnome shell.
8:13 a.m.
On Sun, 2011-01-23 at 17:17 +0100, Christoph Wickert wrote:
Glad to hear that, but it's not really a solution. In the past we
had to
reduce the number of applications with every release because the
dependency footprint became worse and worse. Now we cannot even ship
gnumeric in the Xfce spin any longer. I am pretty sure our users don't
want us to spend the new space with an additional desktop they cannot /
don't want use.
The only way to avoid this continuing slide is to find somebody who is
willing to work on language packs.
1 p.m.
Am Montag, den 24.01.2011, 09:13 -0500 schrieb Matthias Clasen:
On Sun, 2011-01-23 at 17:17 +0100, Christoph Wickert wrote:
> Glad to hear that, but it's not really a solution. In the past we had to
> reduce the number of applications with every release because the
> dependency footprint became worse and worse. Now we cannot even ship
> gnumeric in the Xfce spin any longer. I am pretty sure our users don't
> want us to spend the new space with an additional desktop they cannot /
> don't want use.
The only way to avoid this continuing slide is to find somebody who is
willing to work on language packs.
What language packs? AFAICS it's mostly input methods and I'm afraid we
cannot exclude people here. Therefor cutting the dependency bload
becomes more important. If you look at the depchain tracker you will see
that some of the deps are not serving any purpose and are just wrong.
I'd appreciate if people looked at the bugs we file.
Regards,
Christoph
8:11 a.m.
On Sun, 2011-01-23 at 16:03 +0100, Christoph Wickert wrote:
Am Samstag, den 22.01.2011, 14:05 -0500 schrieb Matthias Clasen:
> On Sat, 2011-01-22 at 12:43 -0600, Bruno Wolff III wrote:
> > On Sat, Jan 22, 2011 at 10:51:20 -0500,
> > Matthias Clasen <mclasen(a)redhat.com> wrote:
> > > On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
> > >
> > > >
> > > > oh, but should it start panels? or at least the gnomeshell?
> > >
> > > Yes, it starts gnome-shell, unless your system is not capable of running
> > > it, in which case it starts gnome-panel+metacity.
> >
> > I did a yum upgrade from F14 to rawhide a month or so ago and have been doing
> > contunuous updates since then. Nothing seems to have dragged in gnome-shell.
> > It's probably worth thinking about a way to it installed for people doing
> > yum upgrades from F13 or F14. I am not sure if using preupgrade has the same
> > issue or not.
>
> That is a good point. We should perhaps add a gnome-session ->
> gnome-shell dependency.
Please don't. GDM already requires gnome-session and with gnome-shell
and it's deps the Xfce spin would be way over CD size.
I've added the dependency to gnome-panel. That should achieve the same
for gnome users on upgrade, without affecting other spins.
9:48 a.m.
On 01/24/2011 07:41 PM, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same
for gnome users on upgrade, without affecting other spins.
What about gnome-themes-standard? I had to install the package manually
after a yum upgrade from Fedora 14
Rahul
10:30 a.m.
On Mon, 2011-01-24 at 21:18 +0530, Rahul Sundaram wrote:
On 01/24/2011 07:41 PM, Matthias Clasen wrote:
>
> I've added the dependency to gnome-panel. That should achieve the same
> for gnome users on upgrade, without affecting other spins.
What about gnome-themes-standard? I had to install the package manually
after a yum upgrade from Fedora 14
I've asked Ray to sort out theme dependencies.
12:59 a.m.
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the
same
for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require
gnome-shell. We really shouldn't just go around abusing dependencies to
make upgrades 'work', even if it is convenient.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:34 a.m.
Dne 25.1.2011 07:59, Adam Williamson napsal(a):
But it doesn't make any sense. gnome-panel does *not* require
gnome-shell. We really shouldn't just go around abusing dependencies to
make upgrades 'work', even if it is convenient.
I would suggest just to give up. Dependencies in RPM packages in Fedora
haven't meant anything for a long time already. Improvements are ignored
(am I allowed to say Suggests/Recommends here?), bugs against broken
dependencies WONTFIXed or ignored as well (try to run Rawhide and
upgrade just some packages and do it repeatedly for a long time ... you
will collect a lot of nice WONTFIXes).
They mean only whatever form of abuse anybody treats them to currently.
Matěj
4:41 a.m.
On Tue, Jan 25, 2011 at 8:34 AM, Matej Cepl <mcepl(a)redhat.com> wrote:
Dne 25.1.2011 07:59, Adam Williamson napsal(a):
> But it doesn't make any sense. gnome-panel does *not* require
> gnome-shell. We really shouldn't just go around abusing dependencies to
> make upgrades 'work', even if it is convenient.
I would suggest just to give up. Dependencies in RPM packages in Fedora
haven't meant anything for a long time already. Improvements are ignored
(am I allowed to say Suggests/Recommends here?), bugs against broken
dependencies WONTFIXed or ignored as well (try to run Rawhide and
upgrade just some packages and do it repeatedly for a long time ... you
will collect a lot of nice WONTFIXes).
Actually if your speaking for the Red Hat desktop team I agree with
your point because its clear they have an "I'm right Jack, everything
for gnome shell attitude so screw everyone else" and it seems from my
point of view that they clearly couldn't give a stuff about anyone
else but themselves. And that attitude sucks and I'm getting sick of
going around my packages and spending a lot of time cleaning up the
mess of when one of that team comes and makes a mess all over the
place.
In terms of dependencies for gnome 3 you may be right but for every
other part of the distribution you are completely wrong, at least on
this space time continuum. There are quite a number of people fixing
dependency problems and its attitudes like this that really piss me
off. We got finally rid of perl in the last release which regained
quite a bit of space for just about all spins for a net win. The
Mobility SIG (mostly me but others as well), the server SIG and the
AOS/JeOS/Virt SIG have been working consistently for a long time (me
for 3 or more years) to try and fix these issues so that is why I'm
getting a little upset on the attitude.
Just because in your world you have terabytes of space and internet
connections in the tens or even hundreds of megs a second there's a
LOT of places in the world that don't have that luxury or have to pay
a lot (like multiple dollars per gig of download) for bandwidth so
saving a 100 meg here and there is worthwhile. I've spoken to a lot of
people that are moving from Fedora to Debian and other distros for
this exact reason. Another classic example of this is updates to
openoffice. There have been 10 updates @ 200Mb odd MB each for oo.o
since the release of F-14 for such critical bugs as "background isn't
transparent" [1] surely these could be bundled together once a month
or so (I thought there was suppose to be a policy about this but I
can't find it).
Peter
They mean only whatever form of abuse anybody treats them to
currently.
[1] https://admin.fedoraproject.org/updates/openoffice.org-3.3.0-20.1.fc14
5:19 a.m.
On 01/25/2011 04:11 PM, Peter Robinson wrote:
this exact reason. Another classic example of this is updates to
openoffice. There have been 10 updates @ 200Mb odd MB each for oo.o
since the release of F-14 for such critical bugs as "background isn't
transparent" [1] surely these could be bundled together once a month
or so (I thought there was suppose to be a policy about this but I
can't find it).
There isn't any such policy suggesting or requiring bundling of bug
fixes and trying to mandate it via policy doesn't really seem
feasible. We could talk to the maintainers in question and understand
what happened first before trying to stop it. If it isn't a one off
problem, then it makes sense to discuss it in the broader context.
Rahul
5:34 a.m.
On Tue, Jan 25, 2011 at 11:19 AM, Rahul Sundaram <metherid(a)gmail.com> wrote:
On 01/25/2011 04:11 PM, Peter Robinson wrote:
>
> this exact reason. Another classic example of this is updates to
> openoffice. There have been 10 updates @ 200Mb odd MB each for oo.o
> since the release of F-14 for such critical bugs as "background isn't
> transparent" [1] surely these could be bundled together once a month
> or so (I thought there was suppose to be a policy about this but I
> can't find it).
There isn't any such policy suggesting or requiring bundling of bug
fixes and trying to mandate it via policy doesn't really seem
feasible. We could talk to the maintainers in question and understand
what happened first before trying to stop it. If it isn't a one off
problem, then it makes sense to discuss it in the broader context.
The number of updates in a stable release has been discussed, at
length. There was even discussion of implementing a policy for it but
it clearly was never done.
Peter
5:59 a.m.
On 01/25/2011 05:04 PM, Peter Robinson wrote:
The number of updates in a stable release has been discussed, at
length. There was even discussion of implementing a policy for it but
it clearly was never done
A policy does exist but says nothing about bundling bug fixes
http://fedoraproject.org/wiki/Updates_Policy
Rahul
7:19 a.m.
New subject: What has happened to desktop icons in rawhide? {Updates Policy}
On 01/25/11 06:59, Rahul Sundaram wrote:
On 01/25/2011 05:04 PM, Peter Robinson wrote:
> The number of updates in a stable release has been discussed, at
> length. There was even discussion of implementing a policy for it but
> it clearly was never done
A policy does exist but says nothing about bundling bug fixes
http://fedoraproject.org/wiki/Updates_Policy
Rahul
Two related policies are kind-of/sort-of there. The document does state
that "Package maintainers MUST: {...} Avoid updates that are trivial or
don't affect any Fedora users." The tough question is to define
"trivial", and perhaps there may need to be some threshold of expected
affected users before a patch is rolled out to everyone.
There also is the philosophy for stable releases that "The update rate
for any given release should drop off over time," which presumes that as
bugfixes are added less future ones should be needed. (Not that
everyone is working on the next release, which probably is also true.)
6:21 a.m.
2011/1/25 Peter Robinson <pbrobinson(a)gmail.com>
On Tue, Jan 25, 2011 at 11:19 AM, Rahul Sundaram
<metherid(a)gmail.com>
wrote:
> On 01/25/2011 04:11 PM, Peter Robinson wrote:
>>
>> this exact reason. Another classic example of this is updates to
>> openoffice. There have been 10 updates @ 200Mb odd MB each for oo.o
>> since the release of F-14 for such critical bugs as "background isn't
>> transparent" [1] surely these could be bundled together once a month
>> or so (I thought there was suppose to be a policy about this but I
>> can't find it).
>
> There isn't any such policy suggesting or requiring bundling of bug
> fixes and trying to mandate it via policy doesn't really seem
> feasible. We could talk to the maintainers in question and understand
> what happened first before trying to stop it. If it isn't a one off
> problem, then it makes sense to discuss it in the broader context.
The number of updates in a stable release has been discussed, at
length. There was even discussion of implementing a policy for it but
it clearly was never done.
another thing that can be done is somehow encouraging the creation of delta
rpms, especially for big packages (like ooo).
7:33 a.m.
2011/1/25 Rahul Sundaram <metherid(a)gmail.com>
On 01/25/2011 05:51 PM, cornel panceac wrote:
>
>
>
> another thing that can be done is somehow encouraging the creation of
> delta rpms, especially for big packages (like ooo).
We already do generate deltarpm. There was a bug in the process which
has been fixed.
thank you
8:30 a.m.
On Tue, 2011-01-25 at 10:41 +0000, Peter Robinson wrote:
Actually if your speaking for the Red Hat desktop team I agree with
your point because its clear they have an "I'm right Jack, everything
for gnome shell attitude so screw everyone else" and it seems from my
point of view that they clearly couldn't give a stuff about anyone
else but themselves. And that attitude sucks and I'm getting sick of
going around my packages and spending a lot of time cleaning up the
mess of when one of that team comes and makes a mess all over the
place.
Is that really necessary ? Can we have at least one mailing list where
we refrain from name-calling and accusatory language, please ?
In terms of dependencies for gnome 3 you may be right but for every
other part of the distribution you are completely wrong, at least on
this space time continuum. There are quite a number of people fixing
dependency problems and its attitudes like this that really piss me
off. We got finally rid of perl in the last release which regained
quite a bit of space for just about all spins for a net win. The
Mobility SIG (mostly me but others as well), the server SIG and the
AOS/JeOS/Virt SIG have been working consistently for a long time (me
for 3 or more years) to try and fix these issues so that is why I'm
getting a little upset on the attitude.
The desktop team has not brought perl back. It is getting pulled in by
cups, indirectly. Please be at least a little more careful with your
accusations. Thanks.
8:42 a.m.
On Tue, Jan 25, 2011 at 2:30 PM, Matthias Clasen <mclasen(a)redhat.com> wrote:
On Tue, 2011-01-25 at 10:41 +0000, Peter Robinson wrote:
> Actually if your speaking for the Red Hat desktop team I agree with
> your point because its clear they have an "I'm right Jack, everything
> for gnome shell attitude so screw everyone else" and it seems from my
> point of view that they clearly couldn't give a stuff about anyone
> else but themselves. And that attitude sucks and I'm getting sick of
> going around my packages and spending a lot of time cleaning up the
> mess of when one of that team comes and makes a mess all over the
> place.
Is that really necessary ? Can we have at least one mailing list where
we refrain from name-calling and accusatory language, please ?
> In terms of dependencies for gnome 3 you may be right but for every
> other part of the distribution you are completely wrong, at least on
> this space time continuum. There are quite a number of people fixing
> dependency problems and its attitudes like this that really piss me
> off. We got finally rid of perl in the last release which regained
> quite a bit of space for just about all spins for a net win. The
> Mobility SIG (mostly me but others as well), the server SIG and the
> AOS/JeOS/Virt SIG have been working consistently for a long time (me
> for 3 or more years) to try and fix these issues so that is why I'm
> getting a little upset on the attitude.
The desktop team has not brought perl back. It is getting pulled in by
cups, indirectly. Please be at least a little more careful with your
accusations. Thanks.
I wasn't accusing the desktop team of bringing back perl, I'm well
aware where the dependency lies (plus net-snmp and others). It was the
point above the one you cut out where one of the desktop team said "I
would suggest just to give up. Dependencies in RPM packages in Fedora
haven't meant anything for a long time already."
Peter
8:44 a.m.
On 01/25/2011 08:12 PM, Peter Robinson wrote:
I wasn't accusing the desktop team of bringing back perl, I'm
well
aware where the dependency lies (plus net-snmp and others). It was the
point above the one you cut out where one of the desktop team said "I
would suggest just to give up. Dependencies in RPM packages in Fedora
haven't meant anything for a long time already."
I think you are missing context there. I read it as frustration from
someone who works as a full time bug triager for that team rather than a
serious suggestion. Let's stick to the technical discussions.
Rahul
10:31 a.m.
Dne 25.1.2011 15:44, Rahul Sundaram napsal(a):
I think you are missing context there. I read it as frustration
from
someone who works as a full time bug triager for that team rather than a
serious suggestion. Let's stick to the technical discussions.
Yes, sorry for my sarcasm not being obvious enough. However, I would
strongly disagree with accusing only desktop team of this. IMHO, whole
Fedora is to be blamed for this in all its parts.
Matěj
10:28 a.m.
Dne 25.1.2011 11:41, Peter Robinson napsal(a):
In terms of dependencies for gnome 3 you may be right but for every
other part of the distribution you are completely wrong, at least on
this space time continuum. There are quite a number of people fixing
dependency problems and its attitudes like this that really piss me
off.
Try that experiment with Rawhide (updating just individual packages when
you feel like you need more modern version of the particular pacakge;
the trick is never to run unqualified yum upgrade for whole system).
for 3 or more years) to try and fix these issues so that is why
I'm
getting a little upset on the attitude.
Just to emphasize, I used to use Debian for many years, so I completely
don't agree with the level of brokeness all Fedora packages requirements
have IMHO.
openoffice. There have been 10 updates @ 200Mb odd MB each for oo.o
since the release of F-14 for such critical bugs as "background isn't
transparent" [1] surely these could be bundled together once a month
or so (I thought there was suppose to be a policy about this but I
can't find it).
Fortunately, presto makes miracles about OpenOffice, but again only if
you regularly update complete distro.
Matěj
11:34 a.m.
On Tue, Jan 25, 2011 at 4:28 PM, Matej Cepl <mcepl(a)redhat.com> wrote:
Dne 25.1.2011 11:41, Peter Robinson napsal(a):
> In terms of dependencies for gnome 3 you may be right but for every
> other part of the distribution you are completely wrong, at least on
> this space time continuum. There are quite a number of people fixing
> dependency problems and its attitudes like this that really piss me
> off.
Try that experiment with Rawhide (updating just individual packages when
you feel like you need more modern version of the particular pacakge;
the trick is never to run unqualified yum upgrade for whole system).
> for 3 or more years) to try and fix these issues so that is why I'm
> getting a little upset on the attitude.
Just to emphasize, I used to use Debian for many years, so I completely
don't agree with the level of brokeness all Fedora packages requirements
have IMHO.
> openoffice. There have been 10 updates @ 200Mb odd MB each for oo.o
> since the release of F-14 for such critical bugs as "background isn't
> transparent" [1] surely these could be bundled together once a month
> or so (I thought there was suppose to be a policy about this but I
> can't find it).
Fortunately, presto makes miracles about OpenOffice, but again only if
you regularly update complete distro.
There's places where presto doesn't work well. And until recently it
didn't work at all on openoffce because of the size. And in cases
where you get lots of updates in a short period of time your out of
luck. Which in a case where bandwidth is expensive you might not
upgrade every time a patch comes our your in the situation where you
have to download the whole thing. My point was that the kernel team
for example commit a series of patches for a number of bugs and push a
new version occasionally as opposed to pushing out multiple large
updates to fix each corner case bug.
Peter
5:24 a.m.
On 01/25/2011 12:29 PM, Adam Williamson wrote:
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
> I've added the dependency to gnome-panel. That should achieve the same
> for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require
gnome-shell. We really shouldn't just go around abusing dependencies to
make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the
fallback mode unless they do a group installation or try to install
GNOME Shell specifically. A upgrade needn't pull in GNOME Shell.
GNOME Panel is a particularly bad place to have that additional
dependency because if I have a system that doesn't support GNOME Shell
or I just don't prefer to use it yet and I am only using the GNOME
Panel, it doesn't make sense to keep GNOME Shell installed.
Rahul
7:34 a.m.
On Tue, Jan 25, 2011 at 12:24 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
On 01/25/2011 12:29 PM, Adam Williamson wrote:
> On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
>
>> I've added the dependency to gnome-panel. That should achieve the same
>> for gnome users on upgrade, without affecting other spins.
> But it doesn't make any sense. gnome-panel does *not* require
> gnome-shell. We really shouldn't just go around abusing dependencies to
> make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the
fallback mode unless they do a group installation or try to install
GNOME Shell specifically.
A upgrade needn't pull in GNOME Shell.
No users upgrading should not get a degraded user experience (that is
what the fallback supposed to be),
to save a few MB of disk space for some users that care about every
single MB on their hard drive.
7:39 a.m.
On Tue, Jan 25, 2011 at 1:34 PM, drago01 <drago01(a)gmail.com> wrote:
On Tue, Jan 25, 2011 at 12:24 PM, Rahul Sundaram
<metherid(a)gmail.com> wrote:
> On 01/25/2011 12:29 PM, Adam Williamson wrote:
>> On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
>>
>>> I've added the dependency to gnome-panel. That should achieve the same
>>> for gnome users on upgrade, without affecting other spins.
>> But it doesn't make any sense. gnome-panel does *not* require
>> gnome-shell. We really shouldn't just go around abusing dependencies to
>> make upgrades 'work', even if it is convenient.
>
> I think users upgrading from a previous release can continue to get the
> fallback mode unless they do a group installation or try to install
> GNOME Shell specifically.
> A upgrade needn't pull in GNOME Shell.
No users upgrading should not get a degraded user experience (that is
what the fallback supposed to be),
to save a few MB of disk space for some users that care about every
single MB on their hard drive.
I've not ever asked for a "degraded user experience" what I'm asking
for it not to put dependency hacks to fix a problem that should be
fixed in some other way. Please don't put this out of context.
Peter
7:43 a.m.
On Tue, Jan 25, 2011 at 2:39 PM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Tue, Jan 25, 2011 at 1:34 PM, drago01 <drago01(a)gmail.com>
wrote:
> On Tue, Jan 25, 2011 at 12:24 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
>> On 01/25/2011 12:29 PM, Adam Williamson wrote:
>>> On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
>>>
>>>> I've added the dependency to gnome-panel. That should achieve the
same
>>>> for gnome users on upgrade, without affecting other spins.
>>> But it doesn't make any sense. gnome-panel does *not* require
>>> gnome-shell. We really shouldn't just go around abusing dependencies to
>>> make upgrades 'work', even if it is convenient.
>>
>> I think users upgrading from a previous release can continue to get the
>> fallback mode unless they do a group installation or try to install
>> GNOME Shell specifically.
>> A upgrade needn't pull in GNOME Shell.
>
> No users upgrading should not get a degraded user experience (that is
> what the fallback supposed to be),
> to save a few MB of disk space for some users that care about every
> single MB on their hard drive.
I've not ever asked for a "degraded user experience" what I'm asking
for it not to put dependency hacks to fix a problem that should be
fixed in some other way. Please don't put this out of context.
I have replied to *Rahul's* mail not yours where he said "A upgrade
needn't pull in GNOME Shell" (I didn't even mention how this should be
done but having the user installing it by hand post upgrade is just
wrong).
So please don't put this out of context.
8:41 a.m.
On Tue, 2011-01-25 at 13:39 +0000, Peter Robinson wrote:
I've not ever asked for a "degraded user experience" what I'm asking
for it not to put dependency hacks to fix a problem that should be
fixed in some other way. Please don't put this out of context.
I've yet to see a proposal for what that 'other way' would be.
I'm open to dropping the dependency when such a proposal surfaces...
8:01 a.m.
On 01/25/2011 07:04 PM, drago01 wrote
No users upgrading should not get a degraded user experience (that
is
what the fallback supposed to be),
to save a few MB of disk space for some users that care about every
single MB on their hard drive.
That is a gross mischaracterization of people are expecting in this
discussion. For one, the fallback mode provides pretty much the same
experience as before the upgrade and doesn't degrade it. I don't care
about every single MB on my hard drive however randomly adding
artificial dependencies to packages cannot be the solution for providing
the upgrade experience you want to provide. If you want to tackle that
problem, it is a much bigger one (defaults change, new packages get
added, some cleanup might be needed etc) and needs to be handled
differently.
Rahul
8:24 a.m.
On Tue, Jan 25, 2011 at 19:31:51 +0530,
Rahul Sundaram <metherid(a)gmail.com> wrote:
That is a gross mischaracterization of people are expecting in this
discussion. For one, the fallback mode provides pretty much the same
experience as before the upgrade and doesn't degrade it. I don't care
I think you want the future tense there. The fallback mode doesn't work
currently if you don't have gnome-shell installed.
about every single MB on my hard drive however randomly adding
artificial dependencies to packages cannot be the solution for providing
the upgrade experience you want to provide. If you want to tackle that
problem, it is a much bigger one (defaults change, new packages get
added, some cleanup might be needed etc) and needs to be handled
differently.
I believe there was a claim that proper obsoletes and provides could
potentially handle upgrades from older Fedora releases while not using
hard dependencies. I did not see a detailed proposal on how this would
be done though.
8:34 a.m.
On 01/25/2011 07:54 PM, Bruno Wolff III wrote:
On Tue, Jan 25, 2011 at 19:31:51 +0530,
Rahul Sundaram wrote:
> That is a gross mischaracterization of people are expecting in this
> discussion. For one, the fallback mode provides pretty much the same
> experience as before the upgrade and doesn't degrade it. I don't care
I think you want the future tense there. The fallback mode doesn't work
currently if you don't have gnome-shell installed.
That will be fixed before release. So the discussion has to take that
into account.
Rahul
12:57 p.m.
On Tue, 2011-01-25 at 14:34 +0100, drago01 wrote:
On Tue, Jan 25, 2011 at 12:24 PM, Rahul Sundaram
<metherid(a)gmail.com> wrote:
> On 01/25/2011 12:29 PM, Adam Williamson wrote:
>> On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
>>
>>> I've added the dependency to gnome-panel. That should achieve the same
>>> for gnome users on upgrade, without affecting other spins.
>> But it doesn't make any sense. gnome-panel does *not* require
>> gnome-shell. We really shouldn't just go around abusing dependencies to
>> make upgrades 'work', even if it is convenient.
>
> I think users upgrading from a previous release can continue to get the
> fallback mode unless they do a group installation or try to install
> GNOME Shell specifically.
> A upgrade needn't pull in GNOME Shell.
No users upgrading should not get a degraded user experience (that is
what the fallback supposed to be),
to save a few MB of disk space for some users that care about every
single MB on their hard drive.
I think we should ensure the supported upgrade methods - installer
upgrade, preupgrade - do the right thing somehow, but yum doesn't have
to.
If there isn't a mechanism to deal with this situation via anaconda,
well, it seems like a deficiency in our upgrade process which should be
remedied, not something to work around by abusing package dependencies.
If we really have to work around it, though, there must be a better
workaround than making up dependencies for gnome-shell; I don't recall
who suggested it, but something involving a meta-package should work
more elegantly.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:18 p.m.
Tue, Jan 25, 2011 at 6:57 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Tue, 2011-01-25 at 14:34 +0100, drago01 wrote:
> On Tue, Jan 25, 2011 at 12:24 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
> > On 01/25/2011 12:29 PM, Adam Williamson wrote:
> >> On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
> >>
> >>> I've added the dependency to gnome-panel. That should achieve the
same
> >>> for gnome users on upgrade, without affecting other spins.
> >> But it doesn't make any sense. gnome-panel does *not* require
> >> gnome-shell. We really shouldn't just go around abusing dependencies to
> >> make upgrades 'work', even if it is convenient.
> >
> > I think users upgrading from a previous release can continue to get the
> > fallback mode unless they do a group installation or try to install
> > GNOME Shell specifically.
> > A upgrade needn't pull in GNOME Shell.
>
> No users upgrading should not get a degraded user experience (that is
> what the fallback supposed to be),
> to save a few MB of disk space for some users that care about every
> single MB on their hard drive.
I think we should ensure the supported upgrade methods - installer
upgrade, preupgrade - do the right thing somehow, but yum doesn't have
to.
If there isn't a mechanism to deal with this situation via anaconda,
well, it seems like a deficiency in our upgrade process which should be
remedied, not something to work around by abusing package dependencies.
If we really have to work around it, though, there must be a better
workaround than making up dependencies for gnome-shell; I don't recall
who suggested it, but something involving a meta-package should work
more elegantly.
My understanding of the anaconda upgrade process is that it installed
any missing packages from an installed group (such as gnome-desktop),
but I may be misinformed there.
Peter
8:33 a.m.
On Tue, 2011-01-25 at 16:54 +0530, Rahul Sundaram wrote:
On 01/25/2011 12:29 PM, Adam Williamson wrote:
> On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
>
>> I've added the dependency to gnome-panel. That should achieve the same
>> for gnome users on upgrade, without affecting other spins.
> But it doesn't make any sense. gnome-panel does *not* require
> gnome-shell. We really shouldn't just go around abusing dependencies to
> make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the
fallback mode unless they do a group installation or try to install
GNOME Shell specifically. A upgrade needn't pull in GNOME Shell.
GNOME Panel is a particularly bad place to have that additional
dependency because if I have a system that doesn't support GNOME Shell
or I just don't prefer to use it yet and I am only using the GNOME
Panel, it doesn't make sense to keep GNOME Shell installed.
No, it is really required that an upgrade gives you the intended
experience of the release you are upgrading to. We are working very hard
to make GNOME 3 good, and would like people to actually get whats on the
label when the upgrade to F15. I don't want to see reactions like
'Hey, I upgraded to F15 and really like that new GNOME 3 experience'
'Really ? I just upgraded, and it looks the same it always did :-('
8:37 a.m.
On 01/25/2011 08:03 PM, Matthias Clasen wrote
No, it is really required that an upgrade gives you the intended
experience of the release you are upgrading to. We are working very hard
to make GNOME 3 good, and would like people to actually get whats on the
label when the upgrade to F15. I don't want to see reactions like
'Hey, I upgraded to F15 and really like that new GNOME 3 experience'
'Really ? I just upgraded, and it looks the same it always did :-('
Add a note to the release notes or handle it in a different manner.
GNOME Shell is a alternative to GNOME Panel. Adding a dependency from
the latter to the former doesn't make any sense. It is a misuse of
dependency mechanism.
Rahul
8:47 a.m.
On Tue, Jan 25, 2011 at 3:37 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
On 01/25/2011 08:03 PM, Matthias Clasen wrote
> No, it is really required that an upgrade gives you the intended
> experience of the release you are upgrading to. We are working very hard
> to make GNOME 3 good, and would like people to actually get whats on the
> label when the upgrade to F15. I don't want to see reactions like
>
> 'Hey, I upgraded to F15 and really like that new GNOME 3 experience'
>
> 'Really ? I just upgraded, and it looks the same it always did :-('
Add a note to the release notes or handle it in a different manner.
GNOME Shell is a alternative to GNOME Panel. Adding a dependency from
the latter to the former doesn't make any sense. It is a misuse of
dependency mechanism.
It is not indented as alternative to in the way you might think it is
just a fallback for older hardware and/or crappy drivers.
Hence the name "fallback". If you really care that much about it
suggest a better way (no a release note entry is not it).
8:48 a.m.
On 01/25/2011 08:17 PM, drago01 wrote:
It is not indented as alternative to in the way you might think it
is
just a fallback for older hardware and/or crappy drivers.
Hence the name "fallback".
Call it whatever you want. It is a alternative in the sense that you
cannot run both at the same time. There is absolutely no technical
reason why GNOME Panel would require GNOME Shell as a dependency.
If you really care that much about it
suggest a better way (no a release note entry is not it)
If you are going to dismiss suggestions without any explanation, why
would I bother? If you insist that a artificial dependency is the right
way, then not much can be done about it.
Rahul
8:57 a.m.
On Tue, Jan 25, 2011 at 3:48 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
On 01/25/2011 08:17 PM, drago01 wrote:
> It is not indented as alternative to in the way you might think it is
> just a fallback for older hardware and/or crappy drivers.
> Hence the name "fallback".
Call it whatever you want. It is a alternative in the sense that you
cannot run both at the same time. There is absolutely no technical
reason why GNOME Panel would require GNOME Shell as a dependency.
> If you really care that much about it
> suggest a better way (no a release note entry is not it)
If you are going to dismiss suggestions without any explanation, why
would I bother?
I though it was obvious that requiring the user to go read the release
notes to get the expected user experience is just wrong.
If you insist that a artificial dependency is the right
way, then not much can be done about it.
It isn't ideal but the costs are few megabytes of disk space versus
the benefit of a better upgrade experience.
Unless we have a better way (which we should have to handle cases like
this), I'd take that cost.
9:09 a.m.
On 01/25/2011 08:27 PM, drago01 wrote:
I though it was obvious that requiring the user to go read the
release
notes to get the expected user experience is just wrong.
I thought It was obvious that adding a dependency from GNOME Panel to
GNOME Shell is just wrong too. It is natural that GNOME Shell
developers want to provide that experience but that doesn't mean just
adding a dependency somewhere randomly is the right idea. If users
don't read the release notes, they are missing a number of changes in
the user experience all the time. For instance, we change the default
or add additional apps to the desktop group often and the users are
missing that.
> If you insist that a artificial dependency is the right
> way, then not much can be done about it.
It isn't ideal but the costs are few megabytes of disk space versus
the benefit of a better upgrade experience.
Unless we have a better way (which we should have to handle cases like
this), I'd take that cost
Others have explained what problems they are trying to solve other than
disk space already.
Rahul
10:01 a.m.
Rahul Sundaram (metherid(a)gmail.com) said:
> But it doesn't make any sense. gnome-panel does *not*
require
> gnome-shell. We really shouldn't just go around abusing dependencies to
> make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the
fallback mode unless they do a group installation or try to install
GNOME Shell specifically.
How so? When we included KDE 4, we didn't leave users on KDE 3 on
upgrade.
Similarly, when a user has GNOME installed (and yes, the gnome-panel
is GNOME), and they upgrade, they'll get the current version of GNOME.
And that's GNOME Shell.
Bill
10:11 a.m.
On Tue, Jan 25, 2011 at 10:01, Bill Nottingham <notting(a)redhat.com> wrote:
Rahul Sundaram (metherid(a)gmail.com) said:
> > But it doesn't make any sense. gnome-panel does *not* require
> > gnome-shell. We really shouldn't just go around abusing dependencies to
> > make upgrades 'work', even if it is convenient.
>
> I think users upgrading from a previous release can continue to get the
> fallback mode unless they do a group installation or try to install
> GNOME Shell specifically.
How so? When we included KDE 4, we didn't leave users on KDE 3 on
upgrade.
Similarly, when a user has GNOME installed (and yes, the gnome-panel
is GNOME), and they upgrade, they'll get the current version of GNOME.
And that's GNOME Shell.
Thank you for repeating this. It appears to not be common knowledge--in this
conversation--that gnome-panel is deprecated and, essentially, in deep
maintenance mode. GNOME Shell is the UI of GNOME 3 and you only land on the
fallback gnome-panel if your hardware doesn't support it or, if the
detection logic doesn't guess your hardware correctly, you force GNOME in to
fallback mode (modulo this UI being created before the release).
10:17 a.m.
On 01/25/2011 09:31 PM, Bill Nottingham wrote:
How so? When we included KDE 4, we didn't leave users on KDE 3 on
upgrade.
KDE 4 components obsoleted the KDE 3 equivalents. GNOME wants to
provide both GNOME Shell and GNOME Panel for Fedora 15 users. So not
quite the same situation.
Similarly, when a user has GNOME installed (and yes, the gnome-panel
is GNOME), and they upgrade, they'll get the current version of GNOME.
And that's GNOME Shell.
I might agree with the end result. Disagree with the implementation.
Rahul
10:29 a.m.
Does not this discussion belong on [1] were the Red Hat Desktop Team
resides....
JBG
1. https://admin.fedoraproject.org/mailman/listinfo/desktop
11:28 a.m.
On Tue, Jan 25, 2011 at 4:01 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Rahul Sundaram (metherid(a)gmail.com) said:
> > But it doesn't make any sense. gnome-panel does *not* require
> > gnome-shell. We really shouldn't just go around abusing dependencies to
> > make upgrades 'work', even if it is convenient.
>
> I think users upgrading from a previous release can continue to get the
> fallback mode unless they do a group installation or try to install
> GNOME Shell specifically.
How so? When we included KDE 4, we didn't leave users on KDE 3 on
upgra
Similarly, when a user has GNOME installed (and yes, the gnome-panel
is GNOME), and they upgrade, they'll get the current version of GNOME.
And that's GNOME Shell.
I mostly agree but the difference in this case there is essentially a
fork as the newer interface won't work on all devices that the old one
previously did so you have circumstances where it just won't work or
will crash horribly even on devices that are suppose to work (and to
see that go and check the abrt bugs against mutter that say "just
crashed when I tried gnome-shell" and the, in some cases, 100s of
dupes). I see them every day when they hit my inbox as I originally
packaged mutter and most of the gnome shell components for moblin (and
now meego) so I'm well aware of the problems there are. Where as KDE 3
- 4 didn't have hardware incompatibilities and gnome has said they'll
maintain both of the interfaces.
Peter
12:36 p.m.
Peter Robinson (pbrobinson(a)gmail.com) said:
I mostly agree but the difference in this case there is essentially
a
fork as the newer interface won't work on all devices that the old one
previously did so you have circumstances where it just won't work or
will crash horribly even on devices that are suppose to work (and to
see that go and check the abrt bugs against mutter that say "just
crashed when I tried gnome-shell" and the, in some cases, 100s of
dupes). I see them every day when they hit my inbox as I originally
packaged mutter and most of the gnome shell components for moblin (and
now meego) so I'm well aware of the problems there are. Where as KDE 3
- 4 didn't have hardware incompatibilities and gnome has said they'll
maintain both of the interfaces.
That doesn't mean the interfaces are separate products, or
need to be seperable components. Certainly not on upgrade.
Bill
11:31 a.m.
On Tue, Jan 25, 2011 at 4:01 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Rahul Sundaram (metherid(a)gmail.com) said:
> > But it doesn't make any sense. gnome-panel does *not* require
> > gnome-shell. We really shouldn't just go around abusing dependencies to
> > make upgrades 'work', even if it is convenient.
>
> I think users upgrading from a previous release can continue to get the
> fallback mode unless they do a group installation or try to install
> GNOME Shell specifically.
How so? When we included KDE 4, we didn't leave users on KDE 3 on
upgrade.
Similarly, when a user has GNOME installed (and yes, the gnome-panel
is GNOME), and they upgrade, they'll get the current version of GNOME.
And that's GNOME Shell.
Unless of course they have no gnome-shell-capable hardware which may
not be insignificant numbers!
--
mike c
11:33 a.m.
On Tue, Jan 25, 2011 at 6:31 PM, mike cloaked <mike.cloaked(a)gmail.com> wrote:
On Tue, Jan 25, 2011 at 4:01 PM, Bill Nottingham
<notting(a)redhat.com> wrote:
> Rahul Sundaram (metherid(a)gmail.com) said:
>> > But it doesn't make any sense. gnome-panel does *not* require
>> > gnome-shell. We really shouldn't just go around abusing dependencies to
>> > make upgrades 'work', even if it is convenient.
>>
>> I think users upgrading from a previous release can continue to get the
>> fallback mode unless they do a group installation or try to install
>> GNOME Shell specifically.
>
> How so? When we included KDE 4, we didn't leave users on KDE 3 on
> upgrade.
>
> Similarly, when a user has GNOME installed (and yes, the gnome-panel
> is GNOME), and they upgrade, they'll get the current version of GNOME.
> And that's GNOME Shell.
Unless of course they have no gnome-shell-capable hardware which may
not be insignificant numbers!
In that case gnome-session will detect that and start the fallback
(still no valid case against it being installed).
8:35 a.m.
On Mon, 2011-01-24 at 22:59 -0800, Adam Williamson wrote:
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
> I've added the dependency to gnome-panel. That should achieve the same
> for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require
gnome-shell. We really shouldn't just go around abusing dependencies to
make upgrades 'work', even if it is convenient.
Make a better proposal then. Just doing nothing is not an option.
The 'natural' place for the dependency would be gnome-session. I have
put it in gnome-panel to help other spins who use gdm and might not want
the extra baggage - and see how warmly probinson thanked me for it :-(
8:46 a.m.
On Tue, Jan 25, 2011 at 2:35 PM, Matthias Clasen <mclasen(a)redhat.com> wrote:
On Mon, 2011-01-24 at 22:59 -0800, Adam Williamson wrote:
> On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
>
> > I've added the dependency to gnome-panel. That should achieve the same
> > for gnome users on upgrade, without affecting other spins.
>
> But it doesn't make any sense. gnome-panel does *not* require
> gnome-shell. We really shouldn't just go around abusing dependencies to
> make upgrades 'work', even if it is convenient.
Make a better proposal then. Just doing nothing is not an option.
The 'natural' place for the dependency would be gnome-session. I have
put it in gnome-panel to help other spins who use gdm and might not want
the extra baggage - and see how warmly probinson thanked me for it :-(
But gnome-panel is the old way. It means anyone who can't use gnome-3
gets it and all its dependencies anyway. Its not a direct attack on
you but there must be a better way to provide a "seemless upgrade"
using comps groups or something similar.
Peter
9:31 a.m.
On 01/25/2011 08:35 AM, Matthias Clasen wrote:
Make a better proposal then. Just doing nothing is not an option.
Why not? Please point to the Fedora policy that says this.
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
========================================================================
10:04 a.m.
Ian Pilcher (arequipeno(a)gmail.com) said:
On 01/25/2011 08:35 AM, Matthias Clasen wrote:
> Make a better proposal then. Just doing nothing is not an option.
Why not? Please point to the Fedora policy that says this.
What? We need a written policy that states 'a user that has version X
of a desktop should cleanly upgrade to the next version of it properly'?
I really didn't think we needed that level of pedanticism in our policies.
Bill
10:02 a.m.
On Tue, Jan 25, 2011 at 09:35:27 -0500,
Matthias Clasen <mclasen(a)redhat.com> wrote:
On Mon, 2011-01-24 at 22:59 -0800, Adam Williamson wrote:
> On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
>
> > I've added the dependency to gnome-panel. That should achieve the same
> > for gnome users on upgrade, without affecting other spins.
>
> But it doesn't make any sense. gnome-panel does *not* require
> gnome-shell. We really shouldn't just go around abusing dependencies to
> make upgrades 'work', even if it is convenient.
Make a better proposal then. Just doing nothing is not an option.
The 'natural' place for the dependency would be gnome-session. I have
put it in gnome-panel to help other spins who use gdm and might not want
the extra baggage - and see how warmly probinson thanked me for it :-(
How about this for a proposal:
Have gnome shell obsolete gnome-panel < 2.90 and require gnome-panel,
metacity (since it needs these for fall back). I think that will do what
you want. (Note there isn't a 2.9x version of metacity, so you obsoleting
that gets a lot trickier.) As long as gnome-panel-2.9x isn't packaged
in F13 or F14 as an update this should work.
11 a.m.
On Tue, 2011-01-25 at 10:02 -0600, Bruno Wolff III wrote:
On Tue, Jan 25, 2011 at 09:35:27 -0500,
Matthias Clasen <mclasen(a)redhat.com> wrote:
> On Mon, 2011-01-24 at 22:59 -0800, Adam Williamson wrote:
> > On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
> >
> > > I've added the dependency to gnome-panel. That should achieve the
same
> > > for gnome users on upgrade, without affecting other spins.
> >
> > But it doesn't make any sense. gnome-panel does *not* require
> > gnome-shell. We really shouldn't just go around abusing dependencies to
> > make upgrades 'work', even if it is convenient.
>
> Make a better proposal then. Just doing nothing is not an option.
> The 'natural' place for the dependency would be gnome-session. I have
> put it in gnome-panel to help other spins who use gdm and might not want
> the extra baggage - and see how warmly probinson thanked me for it :-(
How about this for a proposal:
Have gnome shell obsolete gnome-panel < 2.90 and require gnome-panel,
metacity (since it needs these for fall back). I think that will do what
you want. (Note there isn't a 2.9x version of metacity, so you obsoleting
that gets a lot trickier.) As long as gnome-panel-2.9x isn't packaged
in F13 or F14 as an update this should work.
I'm not sure that such an Obsoletes will do anything, as long as a
gnome-panel >= 2.90 is in F15.
12:35 p.m.
Matthias Clasen (mclasen(a)redhat.com) said:
> How about this for a proposal:
> Have gnome shell obsolete gnome-panel < 2.90 and require gnome-panel,
> metacity (since it needs these for fall back). I think that will do what
> you want. (Note there isn't a 2.9x version of metacity, so you obsoleting
> that gets a lot trickier.) As long as gnome-panel-2.9x isn't packaged
> in F13 or F14 as an update this should work.
I'm not sure that such an Obsoletes will do anything, as long as a
gnome-panel >= 2.90 is in F15.
I checked with Seth et. al.; something like:
Obsoletes: gnome-panel < 2.90
Requires: gnome-panel >= 2.90
*will* work. (Adjust for any epochs, of course.)
Bill
9:33 a.m.
On Tue, 2011-01-25 at 13:35 -0500, Bill Nottingham wrote:
Matthias Clasen (mclasen(a)redhat.com) said:
> > How about this for a proposal:
> > Have gnome shell obsolete gnome-panel < 2.90 and require gnome-panel,
> > metacity (since it needs these for fall back). I think that will do what
> > you want. (Note there isn't a 2.9x version of metacity, so you obsoleting
> > that gets a lot trickier.) As long as gnome-panel-2.9x isn't packaged
> > in F13 or F14 as an update this should work.
>
> I'm not sure that such an Obsoletes will do anything, as long as a
> gnome-panel >= 2.90 is in F15.
I checked with Seth et. al.; something like:
Obsoletes: gnome-panel < 2.90
Requires: gnome-panel >= 2.90
*will* work. (Adjust for any epochs, of course.)
I'll give it a try when gnome-panel 2.90 arrives
1:06 p.m.
On Tue, 2011-01-25 at 12:00 -0500, Matthias Clasen wrote:
> How about this for a proposal:
> Have gnome shell obsolete gnome-panel < 2.90 and require gnome-panel,
> metacity (since it needs these for fall back). I think that will do what
> you want. (Note there isn't a 2.9x version of metacity, so you obsoleting
> that gets a lot trickier.) As long as gnome-panel-2.9x isn't packaged
> in F13 or F14 as an update this should work.
I'm not sure that such an Obsoletes will do anything, as long as a
gnome-panel >= 2.90 is in F15.
I agree, but I think the approach possibly has merit with a tweak. How
about gnome-panel is renamed gnome-panel-legacy , gnome-shell obsoletes
gnome-panel and requires gnome-panel-legacy ? I think that way you'd get
gnome-shell on upgrade but at least would be able to remove it, and it's
at least a _more_ correct description of the relationships.
(Side note: I think we might all have found things rather easier if we
used a meta-package approach rather than comps; for me, one thing this
discussion exposes is that things are a lot harder because comps -
obviously - isn't considered by yum. If we had a 'task-gnome'
metapackage which expressed what packages are required for the desired
GNOME desktop experience, it'd make things a lot easier, because that
could require gnome-shell , but you could always remove the task-gnome
metapackage if you wanted to...people who didn't fiddle with anything
would get gnome-shell on upgrade, people who fiddle with things get to
keep both pieces.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:08 a.m.
At this point I would appreciate if people would focus on generating potential
solutions that work well for everyone. Until we find there is no such solution
it's premature to be arguing which compromise we should make. And the
discussion is getting a bit heated worrying about decisions that may not
even be needed.
9:58 a.m.
On 01/22/2011 10:10 AM, Matthias Clasen wrote:
On Fri, 2011-01-21 at 11:03 -0500, Clyde E. Kunkel wrote:
> Should they be visible?
GNOME 3 will not start nautilus by default.
Sorry, I should have probably announced this change hitting rawhide.
The startup applications menu selection has gone away also...so how do
we start nautilus when gnome is loaded? Used to be able to put a
startup cmd in the startup apps dialogue.
Regards,
OldFart
11:53 a.m.
On Sat, Jan 22, 2011 at 09:58, Clyde E. Kunkel <clydekunkel7734(a)cox.net>wrote:
The startup applications menu selection has gone away also...so how
do
we start nautilus when gnome is loaded? Used to be able to put a
startup cmd in the startup apps dialogue.
http://specifications.freedesktop.org/autostart-spec/autostart-spec-lates...
Short version: ln -s /usr/share/applications/name.desktop
~/.config/autostart
10:17 a.m.
On 01/22/2011 12:53 PM, Jason D. Clinton wrote:
On Sat, Jan 22, 2011 at 09:58, Clyde E.
Kunkel<clydekunkel7734(a)cox.net>wrote:
> The startup applications menu selection has gone away also...so how do
> we start nautilus when gnome is loaded? Used to be able to put a
> startup cmd in the startup apps dialogue.
>
http://specifications.freedesktop.org/autostart-spec/autostart-spec-lates...
Short version: ln -s /usr/share/applications/name.desktop
~/.config/autostart
Thanks for the suggestion. It didn't work and the discussion on this
thread has gone in a different direction.
I can get a startup application for nautilus (that used to work) to
execute when rawhide gnome is loaded since my home directory is shared
with F14,and other RH and Fedora installations. But the desktop icons
do not show up in rawhide.
Does anyone have any other workarounds?
TIA
Regards,
OldFart
8:23 a.m.
On Sun, 2011-01-23 at 11:17 -0500, Clyde E. Kunkel wrote:
On 01/22/2011 12:53 PM, Jason D. Clinton wrote:
> On Sat, Jan 22, 2011 at 09:58, Clyde E. Kunkel<clydekunkel7734(a)cox.net>wrote:
>
>> The startup applications menu selection has gone away also...so how do
>> we start nautilus when gnome is loaded? Used to be able to put a
>> startup cmd in the startup apps dialogue.
>>
>
>
> http://specifications.freedesktop.org/autostart-spec/autostart-spec-lates...
>
> Short version: ln -s /usr/share/applications/name.desktop
> ~/.config/autostart
>
>
Thanks for the suggestion. It didn't work and the discussion on this
thread has gone in a different direction.
I can get a startup application for nautilus (that used to work) to
execute when rawhide gnome is loaded since my home directory is shared
with F14,and other RH and Fedora installations. But the desktop icons
do not show up in rawhide.
Does anyone have any other workarounds?
gsettings set org.gnome.desktop.background show-desktop-icons true
Note that nautilus seems to crash when the key is changed while it is
running, so do it before starting nautilus.
12:01 p.m.
Matthias Clasen (mclasen(a)redhat.com) said:
> Does anyone have any other workarounds?
gsettings set org.gnome.desktop.background show-desktop-icons true
Note that nautilus seems to crash when the key is changed while it is
running, so do it before starting nautilus.
If this is the sort of thing that people who have set up their desktop with
icons may want, but we don't want as the normal way going forwards, why
not set this key to be enabled in the gconf->gsettings migration schema, but
off in the actual schema default for new installs?
Bill
3:35 p.m.
On Mon, 2011-01-24 at 13:01 -0500, Bill Nottingham wrote:
Matthias Clasen (mclasen(a)redhat.com) said:
> > Does anyone have any other workarounds?
>
>
> gsettings set org.gnome.desktop.background show-desktop-icons true
>
> Note that nautilus seems to crash when the key is changed while it is
> running, so do it before starting nautilus.
If this is the sort of thing that people who have set up their desktop with
icons may want, but we don't want as the normal way going forwards, why
not set this key to be enabled in the gconf->gsettings migration schema, but
off in the actual schema default for new installs?
Migration just copies whatever value you had in your gconf db, it is not
set up to 'inject' new values. And since the old default was 'true', few
people will have it in their local db (unless they set it to false...).
1:56 p.m.
On 01/24/2011 09:23 AM, Matthias Clasen wrote:
<snip>
gsettings set org.gnome.desktop.background show-desktop-icons true
Note that nautilus seems to crash when the key is changed while it is
running, so do it before starting nautilus.
Many, many, many thanks!
Shouldn't this be the default? Don't most folks want desktop icons?
Regards
OldFart
10:18 a.m.
Am Samstag, den 22.01.2011, 11:53 -0600 schrieb Jason D. Clinton:
On Sat, Jan 22, 2011 at 09:58, Clyde E. Kunkel
<clydekunkel7734(a)cox.net> wrote:
The startup applications menu selection has gone away
also...so how do
we start nautilus when gnome is loaded? Used to be able to
put a
startup cmd in the startup apps dialogue.
http://specifications.freedesktop.org/autostart-spec/autostart-spec-lates...
Short version: ln -s /usr/share/applications/name.desktop
~/.config/autostart
1. With that 'fix' nautilus won't work correctly.
2. I don't think that opening a terminal to make a symlink is the
kind of user friendly fall-back we want.
Regards,
Christoph
12:15 p.m.
On Sat, Jan 22, 2011 at 10:10:32 -0500,
Matthias Clasen <mclasen(a)redhat.com> wrote:
On Fri, 2011-01-21 at 11:03 -0500, Clyde E. Kunkel wrote:
> Should they be visible?
GNOME 3 will not start nautilus by default.
Sorry, I should have probably announced this change hitting rawhide.
What about people who want to continue running (or were running) metacity.
For the last week or two, none of metacity, nautilus and nautlius appear
to be getting started after logging in with gdm. I have to escape back to
a vt to start at least metacity and gnome-panel to be able to do anything.
It may be because I have been doing continuous upgrades, that I am seeing
something different than people who do fresh rawhide installs today.
4836
days inactive
4841
days old
112 comments
19 participants
participants (19)
-
Adam Williamson -
Andre Robatino -
Bill Nottingham -
Bruno Wolff III -
Christoph Wickert -
Clyde E. Kunkel -
cornel panceac -
David -
drago01 -
Ian Pilcher -
Jason D. Clinton -
Jóhann B. Guðmundsson -
Matej Cepl -
Matthew Garrett -
Matthias Clasen -
mike cloaked -
Peter Robinson -
Rahul Sundaram -
Samuel Greenfeld