7:16 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
With the latest version of l-b-g, the "time of day" backgrounds were
added to the -gnome subpackage. This ballooned the package by 20+megs
and has caused some of the live images to overflow. Previously none of
the actual background files were in -gnome and I'm curious why the
change was made at this point, particularly when in previous releases
there were no images in the -gnome subpackage.
Care to shed some light?
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAky47tIACgkQ4v2HLvE71NVsoQCgj1Q2GQFT+MSbeIWrfDwk/EM/
DIMAoJCoDzBEDN6n6mM38N8SGpjC5VoB
=acUM
-----END PGP SIGNATURE-----
3:07 a.m.
On Fri, 2010-10-15 at 17:16 -0700, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
With the latest version of l-b-g, the "time of day" backgrounds were
added to the -gnome subpackage. This ballooned the package by 20+megs
and has caused some of the live images to overflow. Previously none of
the actual background files were in -gnome and I'm curious why the
change was made at this point, particularly when in previous releases
there were no images in the -gnome subpackage.
The reason why they're in -gnome subpackage is simple: this kind of
thing is supported in gnome only. The reason why this late is also
simple -- we (design-team) agreed on our regular IRC meeting that we
want to make the default wallpaper with time-of-day animation again and
this kind of improvement is always done last in wallpaper design. IIRC
last time we did time-of-day animation was Fedora 9 so you can imagine
why for the past few releases -gnome subpackage was image-empty.
I apologize for the inconvenience -- I should have probably notified the
desktop folks ahead that it was highly probable that l-b-g-gnome would
increase in size rather drastically (I myself had the info week ahead of
the packaging)...
Regards,
Martin
8:20 a.m.
On Sat, Oct 16, 2010 at 10:07:24 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
I apologize for the inconvenience -- I should have probably notified the
desktop folks ahead that it was highly probable that l-b-g-gnome would
increase in size rather drastically (I myself had the info week ahead of
the packaging)...
It's a bit more than an incovenience. It is breaking some spins. (In that
they aren't going to make their target size without changes.)
We either need a way to only get some of that stuff, or some way to not
use that package for at least a few spins. We only have a few days to react
to this. The two spins that went over size are probably going to have a problem
with removing other software and we will probably want to look at some way
to use a simpler backgrounds package. If you guys have some ideas in that
direction it would help.
10:04 a.m.
I looked and the key provides seems to be system-backgrounds-gnome. That is
provided only by laughlin-backgrounds-gnome and is required by
gnome-desktop and gnome-desktop3.
I didn't check for file dependencies, so I am not sure if XFCE pulls this
in via a file dependency or not.
But it does look like we need a package change to deal with this.
One option would be to have laughlin-backgrounds-single provide
system-backgrounds-gnome instead of laughlin-backgrounds-gnome and then
specifically include laughlin-backgrounds-gnome in the ks files for
the spins that want the full list of backgrounds.
I'd be willing to adjust the spin kickstart files, but I am not a proven
packager so I can't touch that laughlin-backgrounds packages. We'll also
need to round up some proven testers as these are critical path packages.
I have about 2.5 hours now I can be free to do stuff, otherwise it will
be late tonight (in about 14 hours) or tomorrow that I can work on this.
Another option would be to revert the update. That doesn't seem ideal,
but might be less work.
10:24 a.m.
On Sat, Oct 16, 2010 at 10:04:59 -0500,
Bruno Wolff III <bruno(a)wolff.to> wrote:
I didn't check for file dependencies, so I am not sure if XFCE
pulls this
in via a file dependency or not.
Unless I screwed up how I checked this, there don't appear to be any direct
file dependencies on files in laughlin-backgrounds-gnome.
10:36 a.m.
On Sat, 2010-10-16 at 10:24 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 10:04:59 -0500,
Bruno Wolff III <bruno(a)wolff.to> wrote:
> I didn't check for file dependencies, so I am not sure if XFCE pulls this
> in via a file dependency or not.
Unless I screwed up how I checked this, there don't appear to be any direct
file dependencies on files in laughlin-backgrounds-gnome.
There shouldn't be,
it's handled directly via package/virtual provides
(there is usually more than 1 file require so it would quickly get
messy). With that said, the default wallpaper selection could be handled
probably more cleanly, I have some ideas which I'd like to try for F15,
but they wouldn't prevent this case from happening as we never know
sufficiently far ahead whether we'll do time-of-day wallpaper and it
always appear no sooner than the final version of wallpaper...
Martin
11:02 a.m.
On Sat, Oct 16, 2010 at 17:36:53 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
There shouldn't be, it's handled directly via package/virtual
provides
(there is usually more than 1 file require so it would quickly get
messy). With that said, the default wallpaper selection could be handled
probably more cleanly, I have some ideas which I'd like to try for F15,
but they wouldn't prevent this case from happening as we never know
sufficiently far ahead whether we'll do time-of-day wallpaper and it
always appear no sooner than the final version of wallpaper...
As long as there is a way for ks files to get just the simpler wallpaper
the ones that are tight on space can be set to use the simpler one and
last minute changes in the package shouldn't be that big of a deal. (But
if there is a large change in size, it would still be best to get it in
a little bit earlier.)
We still need a plan to deal with the immediate problem. You mentioned some
areas I wasn't aware of when I made my previous proposal. Can you combine
what you described above with what I mentioned so far and propose a way
forward that we can implement this weekend?
11:32 a.m.
On Sat, 2010-10-16 at 11:02 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 17:36:53 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
> There shouldn't be, it's handled directly via package/virtual provides
> (there is usually more than 1 file require so it would quickly get
> messy). With that said, the default wallpaper selection could be handled
> probably more cleanly, I have some ideas which I'd like to try for F15,
> but they wouldn't prevent this case from happening as we never know
> sufficiently far ahead whether we'll do time-of-day wallpaper and it
> always appear no sooner than the final version of wallpaper...
As long as there is a way for ks files to get just the simpler wallpaper
the ones that are tight on space can be set to use the simpler one and
last minute changes in the package shouldn't be that big of a deal. (But
if there is a large change in size, it would still be best to get it in
a little bit earlier.)
We still need a plan to deal with the immediate problem. You mentioned some
areas I wasn't aware of when I made my previous proposal. Can you combine
what you described above with what I mentioned so far and propose a way
forward that we can implement this weekend?
For the immediate problem -- I'm
not sure what is better packaging-wise,
but I could do one of the following
* move -gnome into -gnome-tod (with the virtual provides and
perhaps obsolete -gnome < 14.1.0), create the needed xmls and
put them into -gnome
* create the needed xmls and put them into -gnome-simple (less
work)
In order to help you solve your problem the best would be to create
these two sub-packages in a way that the xmls would be the same and thus
in direct conflict. I'm not sure how to properly handle the defaults
yet. Perhaps adding the virtual provide to the -simple one as well, but
the we'd have to make sure to correct package is pulled in...
Any better ideas?
Martin
11:52 a.m.
On Sat, Oct 16, 2010 at 18:32:36 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
For the immediate problem -- I'm not sure what is better
packaging-wise,
but I could do one of the following
* move -gnome into -gnome-tod (with the virtual provides and
perhaps obsolete -gnome < 14.1.0), create the needed xmls and
put them into -gnome
* create the needed xmls and put them into -gnome-simple (less
work)
I don't think you need to make a laughlin-backgrounds-gnome-tod.
We should be able to properly spil stuff between laughlin-backgrounds-gnome
and laughlin-backgrounds-single as long as we can get a single xml file
to work for both cases.
In order to help you solve your problem the best would be to create
these two sub-packages in a way that the xmls would be the same and thus
in direct conflict. I'm not sure how to properly handle the defaults
yet. Perhaps adding the virtual provide to the -simple one as well, but
the we'd have to make sure to correct package is pulled in...
I'd rather not see a conflicts. That is going to cause problems.
Any better ideas?
Is there someplace that describes the details of that xml file?
I am trying to search through the gnome documentation but haven't found
the reference for that file yet.
12:17 p.m.
On Sat, 2010-10-16 at 11:52 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 18:32:36 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
> For the immediate problem -- I'm not sure what is better packaging-wise,
> but I could do one of the following
> * move -gnome into -gnome-tod (with the virtual provides and
> perhaps obsolete -gnome < 14.1.0), create the needed xmls and
> put them into -gnome
> * create the needed xmls and put them into -gnome-simple (less
> work)
I don't think you need to make a laughlin-backgrounds-gnome-tod.
We should be able to properly spil stuff between laughlin-backgrounds-gnome
and laughlin-backgrounds-single as long as we can get a single xml file
to work for both cases.
> In order to help you solve your problem the best would be to create
> these two sub-packages in a way that the xmls would be the same and thus
> in direct conflict. I'm not sure how to properly handle the defaults
> yet. Perhaps adding the virtual provide to the -simple one as well, but
> the we'd have to make sure to correct package is pulled in...
I'd rather not see a conflicts. That is going to cause problems.
> Any better ideas?
Is there someplace that describes the details of that xml file?
I am trying to search through the gnome documentation but haven't found
the reference for that file yet.
I have no idea :( These things are really badly
documented... Most you
can get is inspecting the code directly...
Martin
12:40 p.m.
On Sat, Oct 16, 2010 at 19:17:54 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
On Sat, 2010-10-16 at 11:52 -0500, Bruno Wolff III wrote:
>
> Is there someplace that describes the details of that xml file?
> I am trying to search through the gnome documentation but haven't found
> the reference for that file yet.
I have no idea :( These things are really badly documented... Most you
can get is inspecting the code directly...
Any pointers to where in the code I should be looking?
I am about out of time now, but can probably look at it tonight. It would
help to know where to start looking.
1:07 p.m.
On Sat, 2010-10-16 at 12:40 -0500, Bruno Wolff III wrote:
Any pointers to where in the code I should be looking?
I am about out of time now, but can probably look at it tonight. It would
help to know where to start looking.
Cannot say for sure, but this would probably
be a good start
http://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-bg.c
Martin
5:12 p.m.
On Sat, 2010-10-16 at 12:40 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 19:17:54 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
> On Sat, 2010-10-16 at 11:52 -0500, Bruno Wolff III wrote:
> >
> > Is there someplace that describes the details of that xml file?
> > I am trying to search through the gnome documentation but haven't found
> > the reference for that file yet.
> I have no idea :( These things are really badly documented... Most you
> can get is inspecting the code directly...
Any pointers to where in the code I should be looking?
I am about out of time now, but can probably look at it tonight. It would
help to know where to start looking.
What are you trying to find out about what xml file ?
8:42 p.m.
On Sat, Oct 16, 2010 at 18:12:06 -0400,
Matthias Clasen <mclasen(a)redhat.com> wrote:
What are you trying to find out about what xml file ?
The file that defines background theme information. In this particular case:
/usr/share/backgrounds/laughlin/default/laughlin.xml
What I was hoping to find out is if you could specify fallback images if
the first choice image files don't exist. The idea was to make a single
config file that would both with and without having
laughlin-backgrounds-gnome installed and get the time of day stuff if
it is installed.
10:42 a.m.
On Sat, Oct 16, 2010 at 10:04:59 -0500,
Bruno Wolff III <bruno(a)wolff.to> wrote:
But it does look like we need a package change to deal with this.
One option would be to have laughlin-backgrounds-single provide
system-backgrounds-gnome instead of laughlin-backgrounds-gnome and then
specifically include laughlin-backgrounds-gnome in the ks files for
the spins that want the full list of backgrounds.
I think we might also want to add laughlin-backgrounds-gnome to the
desktop-gnome comps group as a default package, so that people get
the full set of backgrounds by default when installing.
10:58 a.m.
On Sat, 2010-10-16 at 10:42 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 10:04:59 -0500,
Bruno Wolff III <bruno(a)wolff.to> wrote:
>
> But it does look like we need a package change to deal with this.
> One option would be to have laughlin-backgrounds-single provide
> system-backgrounds-gnome instead of laughlin-backgrounds-gnome and then
> specifically include laughlin-backgrounds-gnome in the ks files for
> the spins that want the full list of backgrounds.
I think we might also want to add laughlin-backgrounds-gnome to the
desktop-gnome comps group as a default package, so that people get
the full set of backgrounds by default when installing.
I believe they get it as
it's required by gnome-desktop(3). Try
yum-removing it ;-)
Martin
11:27 a.m.
On Sat, Oct 16, 2010 at 17:58:22 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
On Sat, 2010-10-16 at 10:42 -0500, Bruno Wolff III wrote:
> On Sat, Oct 16, 2010 at 10:04:59 -0500,
> Bruno Wolff III <bruno(a)wolff.to> wrote:
> >
> > But it does look like we need a package change to deal with this.
> > One option would be to have laughlin-backgrounds-single provide
> > system-backgrounds-gnome instead of laughlin-backgrounds-gnome and then
> > specifically include laughlin-backgrounds-gnome in the ks files for
> > the spins that want the full list of backgrounds.
>
> I think we might also want to add laughlin-backgrounds-gnome to the
> desktop-gnome comps group as a default package, so that people get
> the full set of backgrounds by default when installing.
I believe they get it as it's required by gnome-desktop(3). Try
yum-removing it ;-)
Part of my proposal was changing that. If we do that, then I think we
need it in comps.
The xml file is an issue though. Is there a way to do conditional code in
that file? Otherwise it looks like having a different default depending
on whether or not laughlin-backgrounds-gnome installed is going to be
difficult.
11:49 a.m.
On Sat, 2010-10-16 at 11:27 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 17:58:22 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
> On Sat, 2010-10-16 at 10:42 -0500, Bruno Wolff III wrote:
> > On Sat, Oct 16, 2010 at 10:04:59 -0500,
> > Bruno Wolff III <bruno(a)wolff.to> wrote:
> > >
> > > But it does look like we need a package change to deal with this.
> > > One option would be to have laughlin-backgrounds-single provide
> > > system-backgrounds-gnome instead of laughlin-backgrounds-gnome and then
> > > specifically include laughlin-backgrounds-gnome in the ks files for
> > > the spins that want the full list of backgrounds.
> >
> > I think we might also want to add laughlin-backgrounds-gnome to the
> > desktop-gnome comps group as a default package, so that people get
> > the full set of backgrounds by default when installing.
> I believe they get it as it's required by gnome-desktop(3). Try
> yum-removing it ;-)
Part of my proposal was changing that. If we do that, then I think we
need it in comps.
The xml file is an issue though. Is there a way to do conditional code in
that file? Otherwise it looks like having a different default depending
on whether or not laughlin-backgrounds-gnome installed is going to be
difficult.
The important xml for it to appear in backgrounds-chooser is this one:
/usr/share/gnome-background-properties/desktop-backgrounds-laughlin.xml
the xml that is selected as default background is this:
/usr/share/backgrounds/laughlin/default/laughlin.xml
The gnome-desktop(3) requires is because it explicitly selects the
background (in gconf schema file) to be
/usr/share/backgrounds/laughlin/default/laughlin.xml
I'm really not sure how to handle here two different defaults...
How it's done in spins with different default wallpaper (I believe the
education or security have one)?
Martin
11:58 a.m.
On Sat, Oct 16, 2010 at 18:49:12 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
The important xml for it to appear in backgrounds-chooser is this
one:
/usr/share/gnome-background-properties/desktop-backgrounds-laughlin.xml
the xml that is selected as default background is this:
/usr/share/backgrounds/laughlin/default/laughlin.xml
The gnome-desktop(3) requires is because it explicitly selects the
background (in gconf schema file) to be
/usr/share/backgrounds/laughlin/default/laughlin.xml
I'm really not sure how to handle here two different defaults...
I don't think there is a good way to have two defaults. I am hoping there
is a way to have one default that falls back to using different images
if the primary ones aren't available. The idea would be to use the
time of day background with the fallbacks all being the images in the
-single package (so the appearance would be constant, but the same
xml file could be used). I doubt that feature is there, but I am trying
to find more information.
How it's done in spins with different default wallpaper (I believe the
education or security have one)?
There are ways to run scripts as part of the builds. I don't exactly how
they implemented that though. However, different isn't enough. The package
needs to be removalable. And given that it is removable, it needs to work
sanely outside of the spins.
10:26 a.m.
On Sat, 2010-10-16 at 08:20 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 10:07:24 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
>
> I apologize for the inconvenience -- I should have probably notified the
> desktop folks ahead that it was highly probable that l-b-g-gnome would
> increase in size rather drastically (I myself had the info week ahead of
> the packaging)...
It's a bit more than an incovenience. It is breaking some spins. (In that
they aren't going to make their target size without changes.)
We either need a way to only get some of that stuff, or some way to not
use that package for at least a few spins. We only have a few days to react
to this. The two spins that went over size are probably going to have a problem
with removing other software and we will probably want to look at some way
to use a simpler backgrounds package. If you guys have some ideas in that
direction it would help.
It would help to list which spins went oversize and
what's their target
size. So general info:
For gnome we need a xml file which actually adds the wallpaper into
wallpaper chooser. The one in current package points to xml which
describes the time-of-day wallpaper version. If you'd need gnome desktop
without time-of-day wallpaper you'd need to add two new xmls (one which
would describe which images are used at which sizes and another one
which would add it to background chooser). In theory, we could split the
-gnome subpackage into -gnome and -gnome-tod which however isn't what we
(design team) want as we want the time-of-day wallpaper used by default
on Desktop spin. It's set not in kickstart, but in gnome-desktop(3),
hence the requires.
For KDE we need the wallpaper description via .desktop file (in -kde
sub-package). AFAIK, KDE does not have support for time-of-day animation
so it does not pull in everything.
For LXDE and XFCE neither -gnome nor -kde sub-packages should be pulled
in and if they are, then it's wrong.
Regards,
Martin
11:12 a.m.
On Sat, Oct 16, 2010 at 17:26:29 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
It would help to list which spins went oversize and what's their
target
size. So general info:
broffice and xfce are the two that went over their targets. They need to
get back under 703 MiB. Games was almost hit, but still has enough cushion
that I can handle the hedgewars small increase in size which will be
showing up in a push tomorrow unless it gets negative karma before then.
But I'm still pretty close and will probably still implement whatever
we do for broffice and xfce.
For gnome we need a xml file which actually adds the wallpaper into
wallpaper chooser. The one in current package points to xml which
describes the time-of-day wallpaper version. If you'd need gnome desktop
without time-of-day wallpaper you'd need to add two new xmls (one which
would describe which images are used at which sizes and another one
which would add it to background chooser). In theory, we could split the
-gnome subpackage into -gnome and -gnome-tod which however isn't what we
(design team) want as we want the time-of-day wallpaper used by default
on Desktop spin. It's set not in kickstart, but in gnome-desktop(3),
hence the requires.
Can you make some proposal here that we can relatively safely mplement this
weekend?
For KDE we need the wallpaper description via .desktop file (in -kde
sub-package). AFAIK, KDE does not have support for time-of-day animation
so it does not pull in everything.
Were probably OK on KDE as it is about 15 MiB under the limit right now.
I'd rather not make changes there right now if we don't have to. But there
probably should be a plan to allow for a simpler background on KDE based
spins for the future.
For LXDE and XFCE neither -gnome nor -kde sub-packages should be
pulled
in and if they are, then it's wrong.
Any ideas on how this is happening?
11:42 a.m.
On Sat, 2010-10-16 at 11:12 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 17:26:29 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
> It would help to list which spins went oversize and what's their target
> size. So general info:
broffice and xfce are the two that went over their targets. They need to
get back under 703 MiB. Games was almost hit, but still has enough cushion
that I can handle the hedgewars small increase in size which will be
showing up in a push tomorrow unless it gets negative karma before then.
But I'm still pretty close and will probably still implement whatever
we do for broffice and xfce.
AFAIK XFCE should require only -single, unless they pull
gnome-desktop(3) for some reason. That grew by 1MB, probably due to
increased complexity of the wallpaper. I'd investigate this one more
throughout if I were you.
Martin
11:59 a.m.
On Sat, Oct 16, 2010 at 18:42:10 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
On Sat, 2010-10-16 at 11:12 -0500, Bruno Wolff III wrote:
> On Sat, Oct 16, 2010 at 17:26:29 +0200,
> Martin Sourada <martin.sourada(a)gmail.com> wrote:
> > It would help to list which spins went oversize and what's their target
> > size. So general info:
>
> broffice and xfce are the two that went over their targets. They need to
> get back under 703 MiB. Games was almost hit, but still has enough cushion
> that I can handle the hedgewars small increase in size which will be
> showing up in a push tomorrow unless it gets negative karma before then.
> But I'm still pretty close and will probably still implement whatever
> we do for broffice and xfce.
>
AFAIK XFCE should require only -single, unless they pull
gnome-desktop(3) for some reason. That grew by 1MB, probably due to
increased complexity of the wallpaper. I'd investigate this one more
throughout if I were you.
That will be lower priority for me. Kevin knows that package better and
the solution there doesn't help broffice, whereas working on a general
solution will help xfce in the short run, even if there is also another
problem that can be fixed.
12:34 p.m.
Am Samstag, den 16.10.2010, 18:42 +0200 schrieb Martin Sourada:
On Sat, 2010-10-16 at 11:12 -0500, Bruno Wolff III wrote:
> On Sat, Oct 16, 2010 at 17:26:29 +0200,
> Martin Sourada <martin.sourada(a)gmail.com> wrote:
> > It would help to list which spins went oversize and what's their target
> > size. So general info:
>
> broffice and xfce are the two that went over their targets. They need to
> get back under 703 MiB. Games was almost hit, but still has enough cushion
> that I can handle the hedgewars small increase in size which will be
> showing up in a push tomorrow unless it gets negative karma before then.
> But I'm still pretty close and will probably still implement whatever
> we do for broffice and xfce.
>
AFAIK XFCE should require only -single, unless they pull
gnome-desktop(3) for some reason.
libgnome-desktop is required by cheese, control-center and
gnome-settings-daemon. We could drop cheese, but we wont get rid of the
rest:
* control-center is required by gnome-bluetooth
* gnome-settings-daemon is required by gdm
There is no alternative to gdm and gnome-blueetooth [1].
That grew by 1MB, probably due to
increased complexity of the wallpaper. I'd investigate this one more
throughout if I were you.
If I were or a member of the design team I would not push changes like
this one that late. I think this level of carelessness is inappropriate.
There are three solutions:
* A gnome-desktop-libs package, but it is too late to change for
F14.
* Make gnome-desktop not depend on system-backgrounds-gnome.
* Revert the changes on laughlin-backgrounds-gnome.
Regards,
Christoph
[1] blueman, the only alternative to gnome-bluetooth depends on
gnome-session which depends on control-center, so we end up with
gnome-desktop again.
12:48 p.m.
On Sat, 2010-10-16 at 19:34 +0200, Christoph Wickert wrote:
Am Samstag, den 16.10.2010, 18:42 +0200 schrieb Martin Sourada:
> On Sat, 2010-10-16 at 11:12 -0500, Bruno Wolff III wrote:
> > On Sat, Oct 16, 2010 at 17:26:29 +0200,
> > Martin Sourada <martin.sourada(a)gmail.com> wrote:
> > > It would help to list which spins went oversize and what's their
target
> > > size. So general info:
> >
> > broffice and xfce are the two that went over their targets. They need to
> > get back under 703 MiB. Games was almost hit, but still has enough cushion
> > that I can handle the hedgewars small increase in size which will be
> > showing up in a push tomorrow unless it gets negative karma before then.
> > But I'm still pretty close and will probably still implement whatever
> > we do for broffice and xfce.
> >
> AFAIK XFCE should require only -single, unless they pull
> gnome-desktop(3) for some reason.
libgnome-desktop is required by cheese, control-center and
gnome-settings-daemon. We could drop cheese, but we wont get rid of the
rest:
* control-center is required by gnome-bluetooth
* gnome-settings-daemon is required by gdm
There is no alternative to gdm and gnome-blueetooth [1].
> That grew by 1MB, probably due to
> increased complexity of the wallpaper. I'd investigate this one more
> throughout if I were you.
If I were or a member of the design team I would not push changes like
this one that late. I think this level of carelessness is inappropriate.
This is how design works. You cannot make time-of-day versions of the
wallpaper sooner than you have final design. You cannot make time-of-day
versions at all if you are late with the final design...
There are three solutions:
* A gnome-desktop-libs package, but it is too late to change for
F14.
That would be sensible and probably better solution F15 onward.
* Make gnome-desktop not depend on system-backgrounds-gnome.
That would work as short term solution, but we have to be very careful
to install s-b-g wherever gnome desktop is installed and uses
system-wide default wallpaper.
* Revert the changes on laughlin-backgrounds-gnome.
You'd have the whole design-team against you for that...
Martin
1:08 p.m.
On Sat, Oct 16, 2010 at 19:48:29 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
On Sat, 2010-10-16 at 19:34 +0200, Christoph Wickert wrote:
> * Make gnome-desktop not depend on system-backgrounds-gnome.
That would work as short term solution, but we have to be very careful
to install s-b-g wherever gnome desktop is installed and uses
system-wide default wallpaper.
You misunderstand. gnome-desktop is going to be installed without
laughlin-backgrounds-gnome being installed in this proposal. The question
would be how to make that work. One option is not having the time of
day based background the default.
1:37 p.m.
On Sat, 2010-10-16 at 13:08 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 19:48:29 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
> On Sat, 2010-10-16 at 19:34 +0200, Christoph Wickert wrote:
>
> > * Make gnome-desktop not depend on system-backgrounds-gnome.
> That would work as short term solution, but we have to be very careful
> to install s-b-g wherever gnome desktop is installed and uses
> system-wide default wallpaper.
You misunderstand. gnome-desktop is going to be installed without
laughlin-backgrounds-gnome being installed in this proposal. The question
would be how to make that work. One option is not having the time of
day based background the default.
I'm under the impression that you need to
avoid it for broffice an xfce
spins only. We definitely want it installed by default on desktop spin,
design suite, etc., i.e. everywhere where gnome desktop is installed and
size isn't an issue.
I.e. IMHO we need solve two cases:
* it is installed and used by default
* gnome-desktop is being installed, but not the time-of-day
wallpaper but it still works.
In short I don't see any other solution (that would satisfy both
parties) than two conflicting defaults... Yeah, if we could make one xml
work for both cases that would solve the issue nicely and in better way,
but I highly doubt that's possible.
Or maybe making it work using 'alternatives' (I totally don't know how
and for what this system works, but maybe worth investigating) -- having
one .xml symlinked to the simple .xml one unless the advanced package
gets installed (we could probably handle it via %post section) and then
add the advanced package to comps where desirable (would it work
correctly for spins?).
Martin
12:48 p.m.
On Sat, Oct 16, 2010 at 19:34:24 +0200,
Christoph Wickert <christoph.wickert(a)googlemail.com> wrote:
* Make gnome-desktop not depend on system-backgrounds-gnome.
I think that one is doable (slightly differently). But there is an issue with
the default them. At the worst I think the time of day theme could be made an
alternative instead of the default.
Reverting will probably be about as hard and will not even provide the
time of day theme as an alternate.
5:15 p.m.
On Sat, 2010-10-16 at 19:34 +0200, Christoph Wickert wrote:
> That grew by 1MB, probably due to
> increased complexity of the wallpaper. I'd investigate this one more
> throughout if I were you.
If I were or a member of the design team I would not push changes like
this one that late. I think this level of carelessness is inappropriate.
There are three solutions:
* A gnome-desktop-libs package, but it is too late to change for
F14.
* Make gnome-desktop not depend on system-backgrounds-gnome.
* Revert the changes on laughlin-backgrounds-gnome.
The system-backgrounds (-gnome) virtual provides were introduced with
for the explicit purpose of making gnome-desktop require them...
Imo, reverting the changes to the background packages is the most
conservative and appropriate action at this time.
3:22 a.m.
On Sat, 2010-10-16 at 18:15 -0400, Matthias Clasen wrote:
On Sat, 2010-10-16 at 19:34 +0200, Christoph Wickert wrote:
> > That grew by 1MB, probably due to
> > increased complexity of the wallpaper. I'd investigate this one more
> > throughout if I were you.
>
> If I were or a member of the design team I would not push changes like
> this one that late. I think this level of carelessness is inappropriate.
>
> There are three solutions:
> * A gnome-desktop-libs package, but it is too late to change for
> F14.
> * Make gnome-desktop not depend on system-backgrounds-gnome.
> * Revert the changes on laughlin-backgrounds-gnome.
The system-backgrounds (-gnome) virtual provides were introduced with
for the explicit purpose of making gnome-desktop require them...
Imo, reverting the changes to the background packages is the most
conservative and appropriate action at this time.
This is a big no-no because:
* it would degrade the quality of wallpaper (yes, the time-of-day
addition wasn't the only thing that was done to the wallpaper)
* it would reintroduce errors in cc-by attribution for the extras
subpackage
Since the time is tight I'm going now to do the following update
* move the time-of-day images to l-b-animated(-gnome), rename and
move there also current XMLs with description and info (so that
it can be installed concurrent with the default)
* recreate the XMLs for non-animated wallpaper and put them in
l-b-gnome
* run optipng on all images
This would effectively revert the size bump of l-b-gnome while keeping
the other changes and giving the user choice to use animated wallpaper.
Would be nice though, if you could then change the desktop spin
kickstart to use the animated version of the wallpaper by default as
we'd like to see it used on it.
Thanks,
Martin
4:28 a.m.
On Sun, 2010-10-17 at 10:22 +0200, Martin Sourada wrote:
On Sat, 2010-10-16 at 18:15 -0400, Matthias Clasen wrote:
> On Sat, 2010-10-16 at 19:34 +0200, Christoph Wickert wrote:
>
> > > That grew by 1MB, probably due to
> > > increased complexity of the wallpaper. I'd investigate this one more
> > > throughout if I were you.
> >
> > If I were or a member of the design team I would not push changes like
> > this one that late. I think this level of carelessness is inappropriate.
> >
> > There are three solutions:
> > * A gnome-desktop-libs package, but it is too late to change for
> > F14.
> > * Make gnome-desktop not depend on system-backgrounds-gnome.
> > * Revert the changes on laughlin-backgrounds-gnome.
>
> The system-backgrounds (-gnome) virtual provides were introduced with
> for the explicit purpose of making gnome-desktop require them...
>
> Imo, reverting the changes to the background packages is the most
> conservative and appropriate action at this time.
This is a big no-no because:
* it would degrade the quality of wallpaper (yes, the time-of-day
addition wasn't the only thing that was done to the wallpaper)
* it would reintroduce errors in cc-by attribution for the extras
subpackage
Since the time is tight I'm going now to do the following update
* move the time-of-day images to l-b-animated(-gnome), rename and
move there also current XMLs with description and info (so that
it can be installed concurrent with the default)
* recreate the XMLs for non-animated wallpaper and put them in
l-b-gnome
* run optipng on all images
This would effectively revert the size bump of l-b-gnome while keeping
the other changes and giving the user choice to use animated wallpaper.
Would be nice though, if you could then change the desktop spin
kickstart to use the animated version of the wallpaper by default as
we'd like to see it used on it.
Ok, I'm done with the packaging, just waiting for the optipng to finish
(the already processed images are all seeing slightly above 10% decrease
in size). Note that the changes are such that they revert the default
wallpaper "infrastructure" to beta version while keeping the new images,
move the time-of-day images into l-b-animated and introduce
l-b-animated-gnome which contains XMLs needed for gnome. So effectively
there is almost zero possibility breaking something by this change.
I'll let you know when the update is ready so you can give karma.
And I reiterate once again. Just un-pushing the previous update is *not*
an option.
Thanks,
Martin
6:09 a.m.
On Sun, 2010-10-17 at 11:28 +0200, Martin Sourada wrote:
On Sun, 2010-10-17 at 10:22 +0200, Martin Sourada wrote:
> On Sat, 2010-10-16 at 18:15 -0400, Matthias Clasen wrote:
> > On Sat, 2010-10-16 at 19:34 +0200, Christoph Wickert wrote:
> >
> > > > That grew by 1MB, probably due to
> > > > increased complexity of the wallpaper. I'd investigate this one
more
> > > > throughout if I were you.
> > >
> > > If I were or a member of the design team I would not push changes like
> > > this one that late. I think this level of carelessness is inappropriate.
> > >
> > > There are three solutions:
> > > * A gnome-desktop-libs package, but it is too late to change for
> > > F14.
> > > * Make gnome-desktop not depend on system-backgrounds-gnome.
> > > * Revert the changes on laughlin-backgrounds-gnome.
> >
> > The system-backgrounds (-gnome) virtual provides were introduced with
> > for the explicit purpose of making gnome-desktop require them...
> >
> > Imo, reverting the changes to the background packages is the most
> > conservative and appropriate action at this time.
> This is a big no-no because:
> * it would degrade the quality of wallpaper (yes, the time-of-day
> addition wasn't the only thing that was done to the wallpaper)
> * it would reintroduce errors in cc-by attribution for the extras
> subpackage
>
> Since the time is tight I'm going now to do the following update
> * move the time-of-day images to l-b-animated(-gnome), rename and
> move there also current XMLs with description and info (so that
> it can be installed concurrent with the default)
> * recreate the XMLs for non-animated wallpaper and put them in
> l-b-gnome
> * run optipng on all images
>
> This would effectively revert the size bump of l-b-gnome while keeping
> the other changes and giving the user choice to use animated wallpaper.
>
> Would be nice though, if you could then change the desktop spin
> kickstart to use the animated version of the wallpaper by default as
> we'd like to see it used on it.
>
Ok, I'm done with the packaging, just waiting for the optipng to finish
(the already processed images are all seeing slightly above 10% decrease
in size). Note that the changes are such that they revert the default
wallpaper "infrastructure" to beta version while keeping the new images,
move the time-of-day images into l-b-animated and introduce
l-b-animated-gnome which contains XMLs needed for gnome. So effectively
there is almost zero possibility breaking something by this change.
I'll let you know when the update is ready so you can give karma.
https://admin.fedoraproject.org/updates/laughlin-backgrounds-14.1.0-1.fc14
Please log in and give karma. Given the change is small I set the
autokarma threshold to 2. It should make the spins small enough again.
Given the nature of changes, the only packages that might need quick
test are l-b-gnome and l-b-animated-gnome
As I said before, this is IMHO the best short-term solution for the
problem, we should however rethink how the default wallpaper is selected
(especially given that some spins use different default wallpapers) for
F15 and onward. I'll propose something later (maybe today, maybe
tomorrow, maybe next week, next month, but definitely before F15 Alpha).
Martin
6:11 a.m.
On Sun, Oct 17, 2010 at 13:09:04 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
https://admin.fedoraproject.org/updates/laughlin-backgrounds-14.1.0-1.fc14
Please log in and give karma. Given the change is small I set the
autokarma threshold to 2. It should make the spins small enough again.
Given the nature of changes, the only packages that might need quick
test are l-b-gnome and l-b-animated-gnome
Thanks for doing this.
We need a proven packager since this package is on the crit path list.
6:44 a.m.
On Sun, 2010-10-17 at 06:11 -0500, Bruno Wolff III wrote:
On Sun, Oct 17, 2010 at 13:09:04 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
> https://admin.fedoraproject.org/updates/laughlin-backgrounds-14.1.0-1.fc14
>
> Please log in and give karma. Given the change is small I set the
> autokarma threshold to 2. It should make the spins small enough again.
> Given the nature of changes, the only packages that might need quick
> test are l-b-gnome and l-b-animated-gnome
Thanks for doing this.
We need a proven packager since this package is on the crit path list.
Is it? The
e-mails I get from bodhi are missing the [CRITPATH]
keyword...
Martin
7:05 a.m.
On Sun, Oct 17, 2010 at 13:09:04 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
Please log in and give karma. Given the change is small I set the
autokarma threshold to 2. It should make the spins small enough again.
Given the nature of changes, the only packages that might need quick
test are l-b-gnome and l-b-animated-gnome
I am not sure how to test the actual animation, but the animated stuff
is now optional (with gnome installed) and when it is installed can
be selected. So it looks good.
7:16 a.m.
On Sun, Oct 17, 2010 at 10:22:55 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
Would be nice though, if you could then change the desktop spin
kickstart to use the animated version of the wallpaper by default as
we'd like to see it used on it.
I changed the live desktop to include the animated backgrounds. I also
changed broffice to remove them. Once the animated backgrounds hits updates
they should be on live desktop based spins other than broffice.
I haven't made it the default yet on the desktop spin. I am looking for
the right way to do that and want it in a separate commit.
I didn't add it to the install image. Without a comps change, it won't
show up on the install image. I think it should be added to the gnome-desktop
group as a default package to get it installed by default with gnome.
That may affect what ends up on the live spins, but I think won't cause
a problem the way I changed things. If this change does get made it should
be done as soon after the animated packages are in stable as possible as
we may need a change to fix things. Desktop controls that comps group,
so I'll leave the decision there for someone in Desktop to decide.
(Note that changing it early could potentially break composes.)
The spin-kickstarts package will be out of date again. I'll look at getting
a new version of that into testing tomorrow.
7:38 a.m.
On Sun, Oct 17, 2010 at 10:22:55 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
Would be nice though, if you could then change the desktop spin
kickstart to use the animated version of the wallpaper by default as
we'd like to see it used on it.
I added a command in post that I think will use the animated laughlin
background by default in live desktop based spins. I added a similar
command to broffice to use the normal one. I think this will undo the
one in the included file. This will need testing, but until the
laughlin-backgrounds update gets in stable I am not sure if we can easily
do that.
3:35 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/17/2010 01:22 AM, Martin Sourada wrote:
Would be nice though, if you could then change the desktop spin
kickstart to use the animated version of the wallpaper by default as
we'd like to see it used on it.
Unfortunately the animated wallpapers on the desktop spin make it go
over in size, by just a few megs. We're still in a "no-go" state until
this gets fixed :/
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAky+ASYACgkQ4v2HLvE71NW22QCfRIWBXz659FN+qJ1lZ835Dlxn
zdoAoIjrPVST7hHb3fv1yEIpSGKY/AQe
=X+Rh
-----END PGP SIGNATURE-----
3:48 p.m.
On Tue, Oct 19, 2010 at 13:35:50 -0700,
Jesse Keating <jkeating(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/17/2010 01:22 AM, Martin Sourada wrote:
> Would be nice though, if you could then change the desktop spin
> kickstart to use the animated version of the wallpaper by default as
> we'd like to see it used on it.
>
Unfortunately the animated wallpapers on the desktop spin make it go
over in size, by just a few megs. We're still in a "no-go" state until
this gets fixed :/
I look at this later tonight, but want to give Desktop a change to make some
other change. Otherwise I'll try to use the same change to livecd-desktop
that I do for broffice.org. Apparently I have something in the wrong
place or otherwise wrong for broffice.org as my fix is breaking that build.
10:11 p.m.
On Tue, Oct 19, 2010 at 15:48:49 -0500,
Bruno Wolff III <bruno(a)wolff.to> wrote:
I look at this later tonight, but want to give Desktop a change to
make some
other change. Otherwise I'll try to use the same change to livecd-desktop
that I do for broffice.org. Apparently I have something in the wrong
place or otherwise wrong for broffice.org as my fix is breaking that build.
broffice.org seems OK now. I am doing a bit of testing with desktop livecd
not having the animated background installed. If that looks good and I
don't see a fix committed by the desktop team, I'll commit this one and
do a new spin-kickstarts package (with a patch). The one Jesse did earlier
is in stable so I won't block that one from getting used for the current
compose.
6:35 p.m.
New subject: laughlin-backgrounds-gnome size increase -- BLOCKER ISSUE --
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/19/10 1:48 PM, Bruno Wolff III wrote:
On Tue, Oct 19, 2010 at 13:35:50 -0700,
Jesse Keating <jkeating(a)redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/17/2010 01:22 AM, Martin Sourada wrote:
>> Would be nice though, if you could then change the desktop spin
>> kickstart to use the animated version of the wallpaper by default as
>> we'd like to see it used on it.
>>
>
> Unfortunately the animated wallpapers on the desktop spin make it go
> over in size, by just a few megs. We're still in a "no-go" state
until
> this gets fixed :/
I look at this later tonight, but want to give Desktop a change to make some
other change. Otherwise I'll try to use the same change to livecd-desktop
that I do for broffice.org. Apparently I have something in the wrong
place or otherwise wrong for broffice.org as my fix is breaking that build.
So the change makes the background on Gnome very plain blue, obviously
something isn't right :/
https://bugzilla.redhat.com/show_bug.cgi?id=645606 has been filed and
proposed as a blocker. Could be just as easy as fiddling with the ks
script in which case only the Desktop images would need to be respun.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkzAzigACgkQ4v2HLvE71NWeQwCgioRg5JjbUeD2/v49dgwTAZ2D
hmoAoIWJzW9AGlTJU0coxlrqf2/IFkcm
=UJac
-----END PGP SIGNATURE-----
6:47 p.m.
New subject: laughlin-backgrounds-gnome size increase -- BLOCKER ISSUE --
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/21/10 4:35 PM, Jesse Keating wrote:
So the change makes the background on Gnome very plain blue,
obviously
something isn't right :/
https://bugzilla.redhat.com/show_bug.cgi?id=645606 has been filed and
proposed as a blocker. Could be just as easy as fiddling with the ks
script in which case only the Desktop images would need to be respun.
Well this is strange. Trying to repeat the issue I'm no longer able to
reproduce...
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkzA0RMACgkQ4v2HLvE71NVaQQCfeLoGT0BNz+7vf4SRlr1fU7je
nvcAnjm/oBwRqfvYN/1xBvSvoRIu2unC
=I93P
-----END PGP SIGNATURE-----
10:48 p.m.
New subject: laughlin-backgrounds-gnome size increase -- BLOCKER ISSUE --
On Thu, 2010-10-21 at 16:47 -0700, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/21/10 4:35 PM, Jesse Keating wrote:
> So the change makes the background on Gnome very plain blue, obviously
> something isn't right :/
>
> https://bugzilla.redhat.com/show_bug.cgi?id=645606 has been filed and
> proposed as a blocker. Could be just as easy as fiddling with the ks
> script in which case only the Desktop images would need to be respun.
>
Well this is strange. Trying to repeat the issue I'm no longer able to
reproduce...
Perhaps the change to an xml file (or whatever) which defines what
wallpaper gets shown at what time of day is in another package and hence
still present, and so you'll see a blank blue background at some times
of the day (when the intended background file isn't present) and the
standard background at the times of day when that one is supposed to be
used?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:48 p.m.
New subject: laughlin-backgrounds-gnome size increase -- BLOCKER ISSUE --
On Thu, Oct 21, 2010 at 20:48:13 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
Perhaps the change to an xml file (or whatever) which defines what
wallpaper gets shown at what time of day is in another package and hence
still present, and so you'll see a blank blue background at some times
of the day (when the intended background file isn't present) and the
standard background at the times of day when that one is supposed to be
used?
That would be my guess as well.
3:37 a.m.
New subject: laughlin-backgrounds-gnome size increase -- BLOCKER ISSUE --
On Thu, 2010-10-21 at 20:48 -0700, Adam Williamson wrote:
On Thu, 2010-10-21 at 16:47 -0700, Jesse Keating wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/21/10 4:35 PM, Jesse Keating wrote:
> > So the change makes the background on Gnome very plain blue, obviously
> > something isn't right :/
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=645606 has been filed and
> > proposed as a blocker. Could be just as easy as fiddling with the ks
> > script in which case only the Desktop images would need to be respun.
> >
>
> Well this is strange. Trying to repeat the issue I'm no longer able to
> reproduce...
Perhaps the change to an xml file (or whatever) which defines what
wallpaper gets shown at what time of day is in another package and hence
still present, and so you'll see a blank blue background at some times
of the day (when the intended background file isn't present) and the
standard background at the times of day when that one is supposed to be
used?
The package with the xml that defines animated background requires the
packages that contain the images:
$ rpm -qf /usr/share/backgrounds/laughlin/default-tod/laughlin.xml
laughlin-backgrounds-animated-gnome-14.1.0-1.fc14.noarch
$ rpm -q --requires laughlin-backgrounds-animated-gnome
laughlin-backgrounds-animated = 14.1.0-1.fc14
$ rpm -q --requires laughlin-backgrounds-animated
laughlin-backgrounds-single = 14.1.0-1.fc14
So it could be broken only if there's a typo somewhere in the xml which
does not seem to be the case (I have quickly checked it).
Martin
8:42 a.m.
New subject: laughlin-backgrounds-gnome size increase -- BLOCKER ISSUE --
On Fri, Oct 22, 2010 at 10:37:29 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
$ rpm -qf /usr/share/backgrounds/laughlin/default-tod/laughlin.xml
laughlin-backgrounds-animated-gnome-14.1.0-1.fc14.noarch
$ rpm -q --requires laughlin-backgrounds-animated-gnome
laughlin-backgrounds-animated = 14.1.0-1.fc14
$ rpm -q --requires laughlin-backgrounds-animated
laughlin-backgrounds-single = 14.1.0-1.fc14
So it could be broken only if there's a typo somewhere in the xml which
does not seem to be the case (I have quickly checked it).
Not on the live spins. Because live-desktop is modified to try to use
the time of day background and livecd-desktop (and derivations such as
games and broffice.org) have the animated backgrounds removed and try to
override the live-desktop override. And something there might be broken.
It may be that all the overrides (in the %post sections) for the background
get pulled. (I think broffice.org has one as well, since at first there was
hope that livecd-desktop could have the animated backgrounds and still
fit.)
12:26 a.m.
On Tue, Oct 19, 2010 at 13:35:50 -0700,
Jesse Keating <jkeating(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/17/2010 01:22 AM, Martin Sourada wrote:
> Would be nice though, if you could then change the desktop spin
> kickstart to use the animated version of the wallpaper by default as
> we'd like to see it used on it.
>
Unfortunately the animated wallpapers on the desktop spin make it go
over in size, by just a few megs. We're still in a "no-go" state until
this gets fixed :/
I removed the animated backgrounds from the Desktop livecd image to get
it under size.
I noticed that at least on one machine that a dd'd image to a usb device
wouldn't boot because of an isolinux.bin issue. I filed a bug on this,
though I don't think it's a blocker.
12:50 a.m.
El mar, 19-10-2010 a las 13:35 -0700, Jesse Keating escribió:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/17/2010 01:22 AM, Martin Sourada wrote:
> Would be nice though, if you could then change the desktop spin
> kickstart to use the animated version of the wallpaper by default as
> we'd like to see it used on it.
>
Unfortunately the animated wallpapers on the desktop spin make it go
over in size, by just a few megs. We're still in a "no-go" state until
this gets fixed :/
Maybe too late for f14, but the following changes to comps could help:
* make planner (6 MiB) optional in office, same for openoffice.org-draw;
they're too specialized apps.
* make system-config-lvm optional (3.1 MiB) in admin-tools; obsoleted by
palimpsest
7:42 a.m.
New subject: OpenOffice or LibreOffice?
Perhaps I'm the only one that is wondering if we are we going to stick
with OpenOffice as our default or make LibreOffice our default and
migrate our users to LibreOffice?
It would be good to get the desktop members view on this for future
deployments.
JBG
7:47 a.m.
New subject: OpenOffice or LibreOffice?
On Wed, Oct 20, 2010 at 12:42:57PM +0000, "Jóhann B. Guðmundsson" wrote:
Perhaps I'm the only one that is wondering if we are we going
to stick
with OpenOffice as our default or make LibreOffice our default and
migrate our users to LibreOffice?
You're not. This has been asked on fedora-devel:
http://lists.fedoraproject.org/pipermail/devel/2010-October/143728.html
Summary: LibreOffice from F15 onwards
--
sven === jabber/xmpp: sven(a)lankes.net
7:53 a.m.
New subject: OpenOffice or LibreOffice?
On 10/20/2010 12:47 PM, Sven Lankes wrote:
On Wed, Oct 20, 2010 at 12:42:57PM +0000, "Jóhann B.
Guðmundsson" wrote:
> Perhaps I'm the only one that is wondering if we are we going to stick
> with OpenOffice as our default or make LibreOffice our default and
> migrate our users to LibreOffice?
You're not. This has been asked on fedora-devel:
http://lists.fedoraproject.org/pipermail/devel/2010-October/143728.html
Summary: LibreOffice from F15 onwards
Thanx for the heads up.
JBG
10:18 a.m.
New subject: OpenOffice or LibreOffice?
Perhaps I'm the only one that is wondering if we are we going
to stick
with OpenOffice as our default or make LibreOffice our default and
migrate our users to LibreOffice?
It would be good to get the desktop members view on this for future
deployments.
JBG
For the zero-added-value that my humble (or not so humble) response
represents, having not really looked around much but having seen the
announcement regarding LibreOffice in September/early October, I was
always assuming that LibreOffice was going to be "coming down the
pipeline" in Fedora ASAP given that Red Hat has squarely thrown its
support behind LibreOffice.
Of course I never questionned it not being in F14 for simple reasons of
logistics and the ensuing nightmare that would be created by the
replacement of such a major set of packages a couple of months after
branching off of Rawhide. I never had any specific notion in my head of
when it would be put into Fedora but I assumed "Well this is Fedora, and
further Red Hat is supporting LibreOffice, so LibreOffice will replace
OO.o as soon as it's seen to be practical based on whatever set of
criteria that TPTB see fit."
12:32 p.m.
I don't have much experience with pngout, but it claims to be able to
shave an extra 14% off these images' sizes. I tried it out on the
four images in standard/ and got this result:
% for foo in *png; do wine ~/bin/pngout.exe "$foo" out/"$foo"; done
In: 3811866 bytes laughlin-01-morning.png /c6 /f5
Out: 3305323 bytes out/laughlin-01-morning.png /c2 /f5
Chg: -506543 bytes ( 86% of original)
In: 3471621 bytes laughlin-02-noon.png /c6 /f5
Out: 3009028 bytes out/laughlin-02-noon.png /c2 /f5
Chg: -462593 bytes ( 86% of original)
In: 3254979 bytes laughlin-03-evening.png /c6 /f5
Out: 2822083 bytes out/laughlin-03-evening.png /c2 /f5
Chg: -432896 bytes ( 86% of original)
In: 3168173 bytes laughlin-04-night.png /c6 /f5
Out: 2735233 bytes out/laughlin-04-night.png /c2 /f5
Chg: -432940 bytes ( 86% of original)
On Sat, Oct 16, 2010 at 8:20 AM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Sat, Oct 16, 2010 at 10:07:24 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
>
> I apologize for the inconvenience -- I should have probably notified the
> desktop folks ahead that it was highly probable that l-b-g-gnome would
> increase in size rather drastically (I myself had the info week ahead of
> the packaging)...
It's a bit more than an incovenience. It is breaking some spins. (In that
they aren't going to make their target size without changes.)
We either need a way to only get some of that stuff, or some way to not
use that package for at least a few spins. We only have a few days to react
to this. The two spins that went over size are probably going to have a problem
with removing other software and we will probably want to look at some way
to use a simpler backgrounds package. If you guys have some ideas in that
direction it would help.
--
desktop mailing list
desktop(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
12:43 p.m.
On Sat, Oct 16, 2010 at 12:32:54 -0500,
Charles Kerr <charles(a)transmissionbt.com> wrote:
I don't have much experience with pngout, but it claims to be
able to
shave an extra 14% off these images' sizes. I tried it out on the
four images in standard/ and got this result:
While better lossless compression would be a good thing to be doing for
all of the artwork, I don't think that is going to help enough here.
Given the short amount of time, I don't think this approach (assuming it
was expanded to include a larger set of artwork) is going to be practical
as an immediate solution.
1:08 p.m.
On Sat, 2010-10-16 at 12:43 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 12:32:54 -0500,
Charles Kerr <charles(a)transmissionbt.com> wrote:
> I don't have much experience with pngout, but it claims to be able to
> shave an extra 14% off these images' sizes. I tried it out on the
> four images in standard/ and got this result:
While better lossless compression would be a good thing to be doing for
all of the artwork, I don't think that is going to help enough here.
Given the short amount of time, I don't think this approach (assuming it
was expanded to include a larger set of artwork) is going to be practical
as an immediate solution.
Once, we used optipng for that, but the savings really
aren't that much
(depending on picture, about 10%) plus they're time-intensive.
Martin
8:38 p.m.
On Sat, Oct 16, 2010 at 20:08:30 +0200,
Martin Sourada <martin.sourada(a)gmail.com> wrote:
On Sat, 2010-10-16 at 12:43 -0500, Bruno Wolff III wrote:
> On Sat, Oct 16, 2010 at 12:32:54 -0500,
> Charles Kerr <charles(a)transmissionbt.com> wrote:
> > I don't have much experience with pngout, but it claims to be able to
> > shave an extra 14% off these images' sizes. I tried it out on the
> > four images in standard/ and got this result:
>
> While better lossless compression would be a good thing to be doing for
> all of the artwork, I don't think that is going to help enough here.
> Given the short amount of time, I don't think this approach (assuming it
> was expanded to include a larger set of artwork) is going to be practical
> as an immediate solution.
Once, we used optipng for that, but the savings really aren't that much
(depending on picture, about 10%) plus they're time-intensive.
But it should only be time intensive creating the image. It saves space
on every machine that they are installed on. 10% accross the board is
pretty good and you probably should be doing that. Not necessarily when you
are reviewing stuff, but once you start using them in packages you really
should be doing the better compression.
7 a.m.
On Sat, Oct 16, 2010 at 8:08 PM, Martin Sourada
<martin.sourada(a)gmail.com> wrote:
On Sat, 2010-10-16 at 12:43 -0500, Bruno Wolff III wrote:
> On Sat, Oct 16, 2010 at 12:32:54 -0500,
> Charles Kerr <charles(a)transmissionbt.com> wrote:
> > I don't have much experience with pngout, but it claims to be able to
> > shave an extra 14% off these images' sizes. I tried it out on the
> > four images in standard/ and got this result:
>
> While better lossless compression would be a good thing to be doing for
> all of the artwork, I don't think that is going to help enough here.
> Given the short amount of time, I don't think this approach (assuming it
> was expanded to include a larger set of artwork) is going to be practical
> as an immediate solution.
Once, we used optipng for that, but the savings really aren't that much
(depending on picture, about 10%) plus they're time-intensive.
10% is a rather nice improvement ...
"plus they're time-intensive"
That doesn't matter the extra time is *buildtime* not actual runtime.
4934
days inactive
4940
days old
desktop@lists.fedoraproject.org
57 comments
12 participants
participants (12)
-
Adam Williamson -
Bruno Wolff III -
Charles Kerr -
Christoph Wickert -
Donald Buchan -
drago01 -
Iván -
Jesse Keating -
Jóhann B. Guðmundsson -
Martin Sourada -
Matthias Clasen -
Sven Lankes