Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
On Wed, Jan 05, 2011 at 07:42:37PM +0100, Alexander Kurtz wrote: b) I'm thinking about not setting any default background colors and just using GRUB's defaults. I was just bitten by the black/black nonsense myself, and was unable to see anything useful until I typed 'set color_normal=white/black' blind. If I can be bitten by this, others definitely can! I'm going to change this to just use the defaults, as you suggest. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
Am Montag, den 17.01.2011, 12:26 + schrieb Colin Watson: On Wed, Jan 05, 2011 at 07:42:37PM +0100, Alexander Kurtz wrote: b) I'm thinking about not setting any default background colors and just using GRUB's defaults. I was just bitten by the black/black nonsense myself, and was unable to see anything useful until I typed 'set color_normal=white/black' blind. As mentioned earlier[1] there are valid reasons for using 'black/black'. And there are valid reasons against using these colors. This simply depends on the background image. I therefore agree with Mario's position[2] that we shouldn't set any background colors at all. If I can be bitten by this, others definitely can! I'm going to change this to just use the defaults, as you suggest. Have you read my last mail[3] with the proposed patch? What do you think of it? Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608263#52 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608263#57 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608263#87 signature.asc Description: This is a digitally signed message part
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
On Mon, Jan 17, 2011 at 02:00:10PM +0100, Alexander Kurtz wrote: Am Montag, den 17.01.2011, 12:26 + schrieb Colin Watson: On Wed, Jan 05, 2011 at 07:42:37PM +0100, Alexander Kurtz wrote: b) I'm thinking about not setting any default background colors and just using GRUB's defaults. I was just bitten by the black/black nonsense myself, and was unable to see anything useful until I typed 'set color_normal=white/black' blind. As mentioned earlier[1] there are valid reasons for using 'black/black'. There are certainly valid reasons for having black as the foreground colour. I don't agree that it makes sense to use black as the foreground *and* background colour. The black border around the image is just a bug. The menu entry being transparent seems essentially coincidental to me (perhaps you can track down where this happens?), and I don't think it's worth the risk of an unreadable boot loader (again, this happened to me). And there are valid reasons against using these colors. This simply depends on the background image. I therefore agree with Mario's position[2] that we shouldn't set any background colors at all. Likewise. If I can be bitten by this, others definitely can! I'm going to change this to just use the defaults, as you suggest. Have you read my last mail[3] with the proposed patch? What do you think of it? I missed that due to the new thread, sorry. Please use the portable [ ... ] [ ... ] rather than [ ... -a ... ] (I'll correct this locally). This looks fine to me, and I'll merge it pretty much as-is for experimental. I'd like to minimise the code change for squeeze (I'm not even sure that I can get another upload into squeeze now), but I can take care of that. I think I will reduce it to these parts: b) drops the possibly unnecessary (opinions???) default background colors e) changes 05_debian_theme to not try the other alternatives when $GRUB_BACKGROUND is set. This should close #608263. You can now simply add GRUB_BACKGROUND= to /etc/default/grub if you don't want any background image. Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
This looks fine to me, and I'll merge it pretty much as-is for experimental. I'd like to minimise the code change for squeeze (I'm not even sure that I can get another upload into squeeze now), but I can take care of that. I think I will reduce it to these parts: Great! Don't hesitate to tell me if I can assist you in any way! Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
Am Dienstag, den 04.01.2011, 01:04 +0100 schrieb Mario 'BitKoenig' Holbe: IMHO, 05_debian_theme should simply do nothing if GRUB_BACKGROUND is set (empty or not), because this one is for and handled by 00_header already (not as sophisticated as 05_debian_theme does it, but ... well...). Well, I think that 05_debian_theme should keep handling $GRUB_BACKGROUND at least for now because it a) can handle upper case file extensions (like DC01234567.JPEG from digital cameras). b) can handle files which aren't directly readable by GRUB (for example a picture in your encrypted home directory). c) keeps /boot/grub/ clean by only having *one* cache file. It even removes that cache file if it isn't necessary anymore. Btw: testing for an empty but set environment variable is not that easy... :) 'if env | grep -q ^GRUB_BACKGROUND=; then ...' comes to my mind... Colin already answered that - it's actually really easy! IMHO, the same applies for the case where 05_debian_theme chooses the lexically first image in /boot/grub - just don't do it: if the user copied one there, he had to configure it somewhere anyways. No, the whole point is that there is no extra configuration necessary, simply doing this sudo cp foo.jpeg /boot/grub/ sudo update-grub should be enough. My intention was to a) allow the user to use a custom background image without thinking much about it b) support what the user might have tried intuitively It's all about the magic words It Just Works™. Furthermore, the default colors set by 05_debian_theme for the three alternatives to grub_background.sh: GRUB_BACKGROUND, the lexically first image in /boot/grub, and for desktop-grub.png if no grub_background.sh exists are simply ... well, useless: black/black - hmmm :) I've chosen those colors because a) that's what the old 05_debian_theme did and I wanted to stick as close to that behavior as possible b) because they are usually sane - black font is readable almost always (unless you use a very dark background image) and magenta clearly indicates the highlighted character of the selected entry. c) setting the second part of the colors (FIRSTPART/SECONDPART) to black removes the frame (I don't know a better word) and makes the entry transparent, which definitely looks better. Btw2: I guess, #581049 could be closed now where 05_debian_theme deals with the desktop-grub alternative. Closed, thanks! Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
On Wed, Jan 05, 2011 at 02:32:47PM +0100, Alexander Kurtz wrote: Well, I think that 05_debian_theme should keep handling $GRUB_BACKGROUND at least for now because it a) can handle upper case file extensions (like DC01234567.JPEG from b) can handle files which aren't directly readable by GRUB (for c) keeps /boot/grub/ clean by only having *one* cache file. It even Hmmm, probably we have different opinions about the focus of 05_debian_theme? What do you intend it to be for? My personal opinion is: 05_debian_theme is Debian-specific, it is not pushed upstream. Hence, it should handle the Debian-specific things, but nothing more. I know, 05_debian_theme is currently a very sophisticated variant of GRUB's comparably basic background-handling and I honestly like the work you did - especially the caching. I know it does some things better than upstream. And, of course, I understand that you like to have this work to be applied to the non-Debian-specific cases as well. However, I personally believe you implemented this the wrong way: If you like to have upper case file extensions handled, if you like to have a cute caching for files not directly readable by GRUB, if you like to have a garbage collection in /boot/grub, why don't you report it upstream? Why do you like to keep it Debian-specific? I.e.: why do you put all this in 05_debian_theme instead of giving upstream a chance to adopt it? IMHO, the same applies for the case where 05_debian_theme chooses the lexically first image in /boot/grub - just don't do it: if the user copied one there, he had to configure it somewhere anyways. No, the whole point is that there is no extra configuration necessary, But there was. You changed that. simply doing this sudo cp foo.jpeg /boot/grub/ sudo update-grub should be enough. My intention was to ... b) support what the user might have tried intuitively Strange users who try copying things somewhere and expect anything to happen :) ... The wall needs to be painted. Hey, let's put a bucket of color close to it, I guess this will do the trick. But well - they must be strange, they use sudo :)= scnr. It's all about the magic words It Just Works???. I understand all this. But why on Debian only? scnr again: Why on Debian at all? Doesn't this look more Ubuntu-like? :) Furthermore, the default colors set by 05_debian_theme for the three I've chosen those colors because a) that's what the old 05_debian_theme did and I wanted to stick as close to that behavior as possible H, wait... no, you didn't :) This color was *only* installed for the moreblue-orbit theme (and is good for it) - which you remove from /boot/grub now :) b) because they are usually sane - black font is readable almost always There is no sane default: black isnt readable on dark backgrounds, white isn't readable on light backgrounds, etc. If you don't agree with upstreams defaults, ... well, u know :) GRUB's default colors are btw. even terminal-specific (well, at least in principle). Mario -- Tower: Say fuelstate. Pilot: Fuelstate. Tower: Say again. Pilot: Again. Tower: Arghl, give me your fuel! Pilot: Sorry, need it by myself... signature.asc Description: Digital signature
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
Am Mittwoch, den 05.01.2011, 17:00 +0100 schrieb Mario 'BitKoenig' Holbe:
Hmmm, probably we have different opinions about the focus of
05_debian_theme?
No, actually we don't ;-). In a perfect world 05_debian_theme would look
like this:
#!/bin/sh
if [ -n ${GRUB_BACKGROUND} ]; then
GRUB_BACKGROUND=/usr/share/images/desktop-base/desktop-grub.png
fi
But, unfortunately this isn't a perfect world. So we have to deal with
GRUB's shortcomings (in particular those from 00_header)
What do you intend it to be for?
My personal opinion is: 05_debian_theme is Debian-specific, it is not
pushed upstream. Hence, it should handle the Debian-specific things, but
nothing more.
I intend it to do exactly what you think it should do. But since we
don't live in that perfect world that requires more code than it
actually should.
I know, 05_debian_theme is currently a very sophisticated variant of
GRUB's comparably basic background-handling and I honestly like the work
you did - especially the caching. I know it does some things better than
upstream. And, of course, I understand that you like to have this work
to be applied to the non-Debian-specific cases as well. However, I
personally believe you implemented this the wrong way: If you
like to have upper case file extensions handled, if you like to have a
cute caching for files not directly readable by GRUB, if you like to
have a garbage collection in /boot/grub, why don't you report it
upstream? Why do you like to keep it Debian-specific?
I.e.: why do you put all this in 05_debian_theme instead of giving
upstream a chance to adopt it?
I absolutely agree. Let me make this clear: Making 05_debian_theme more
or less obsolete is definitely my long term goal. But I'd also like to
have a working background image, preferably in time for squeeze. So I
chose the pragmatic way and fixed 05_debian_theme. This doesn't mean
that 00_header doesn't also need fixing. Again: I plan to do that.
No, the whole point is that there is no extra configuration necessary,
But there was. You changed that.
Is that good or bad?
Strange users who try copying things somewhere and expect anything to
happen :) ... The wall needs to be painted. Hey, let's put a bucket of
color close to it, I guess this will do the trick.
I think Tom Sawyer would have liked that ;-)
It's all about the magic words It Just Works???.
I understand all this. But why on Debian only?
scnr again: Why on Debian at all? Doesn't this look more Ubuntu-like? :)
Again: Pushing this upstream by including it in 00_header is planned.
And why can't Debian for once be more user-friendly than Ubuntu? ;-)
a) that's what the old 05_debian_theme did and I wanted to stick as
close to that behavior as possible
H, wait... no, you didn't :)
Well, I tried avoiding the bugs of course...
There is no sane default: black isnt readable on dark backgrounds, white
isn't readable on light backgrounds, etc. If you don't agree with
upstreams defaults, ... well, u know :)
Ok, I can give you another reason:
Without default values GRUB would throw out syntax errors, because the
lines would look like this
set color_normal=
So I'd have to add another if-clause to check whether there have been
colors supplied and change the output accordingly. Did I mention that
I'm sometimes lazy? ;-)
GRUB's default colors are btw. even terminal-specific (well, at least in
principle).
Well, in that case I may actually re-think my laziness. This sounds like
a good argument to me.
Best regards
Alexander Kurtz
signature.asc
Description: This is a digitally signed message part
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
On Wed, Jan 05, 2011 at 05:39:33PM +0100, Alexander Kurtz wrote: Am Mittwoch, den 05.01.2011, 17:00 +0100 schrieb Mario 'BitKoenig' Holbe: My personal opinion is: 05_debian_theme is Debian-specific, it is not pushed upstream. Hence, it should handle the Debian-specific things, but I intend it to do exactly what you think it should do. But since we don't live in that perfect world that requires more code than it actually should. That's not the point... I personally pretty much like the way you encapsulated set_background_image() - this makes it easier to move it upstream some day. The point is that you re-use this more code to (re-)do non-Debian-specific things, too. You re-do GRUB_BACKGROUND because you think you can do better than 00_header - which may not be wrong (except the colors :)), but it's not 05_debian_theme's job and may clash with others not expecting it. You do handle images in /boot/grub unsolicited a) without even knowing them, for example, without knowing what colors would make sense for them. b) without others knowing or even expecting that you do this (see below). Btw: Both could IMHO be a reason for upstream not to accept such behaviour. I absolutely agree. Let me make this clear: Making 05_debian_theme more or less obsolete is definitely my long term goal. But I'd also like to have a working background image, preferably in time for squeeze. So I Let me guess - another one than spacefun from Squeeze? :) chose the pragmatic way and fixed 05_debian_theme. This doesn't mean that 00_header doesn't also need fixing. Again: I plan to do that. For the meantime not to mix them both up too much, how about using something like GRUB_DEBIAN_BACKGROUND or DEBIAN_GRUB_BACKGROUND instead of GRUB_BACKGROUND for the more sophisticated Debian way to handle GRUB images? You wouldn't even have to care about migration: if somebody uses it, he has to modify /etc/default/grub manually anyways - which would later come back to his attention through debconf. No, the whole point is that there is no extra configuration necessary, But there was. You changed that. Is that good or bad? I don't like to decide that. IMHO it's bad for existing systems which now unexpectedly get a graphical console just because they had something lingering around in /boot/grub they probably didn't even know about. I mean, if you install desktop-base you expect (to some extent) to get a shiny gleamy look everywhere, but if you don't... Probably it's also bad for systems that have other ways of setting up a grub-background which includes copying images to /boot/grub. You now set them up a graphical console and you don't know if you (re-)do it before or after them, i.e. if you probably make it worse. Directory-based plugin-mechs are never easy, as all the *.d directories and their different behaviour show, but they all start with a very basic principle: everybody has to know that something is a plugin-directory. a) that's what the old 05_debian_theme did and I wanted to stick as close to that behavior as possible H, wait... no, you didn't :) Well, I tried avoiding the bugs of course... But you removed my line which explained what I really meant with wait... no: The previous behaviour of 05_debian_theme was to install moreblue-orbit-grub.png from desktop-base with matching colors if possible. If not, set colors for the text interface. But now you even remove moreblue-orbit-grub.png (which is fine with me, btw.) - thats not close to the previous behaviour :) Btw: Even though the removal of moreblue-orbit-grub.png is fine with me, I personally don't like the way to do it: it was installed in a package control script, it should be removed in a package control script. Without default values GRUB would throw out syntax errors, because the ... So I'd have to add another if-clause to check whether there have been Great idea! ...scnr :) Mario -- We know that communication is a problem, but the company is not going to discuss it with the employees. -- Switching supervisor, ATT Long Lines Division signature.asc Description: Digital signature
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
Am Mittwoch, den 05.01.2011, 19:03 +0100 schrieb Mario 'BitKoenig' Holbe: You re-do GRUB_BACKGROUND because you think you can do better than 00_header - which may not be wrong (except the colors :)), but it's not 05_debian_theme's job and may clash with others not expecting it. You have to remove exactly one line to disable that feature. You do handle images in /boot/grub unsolicited You have to remove exactly one line to disable that feature. For the meantime not to mix them both up too much, how about using something like GRUB_DEBIAN_BACKGROUND or DEBIAN_GRUB_BACKGROUND instead of GRUB_BACKGROUND for the more sophisticated Debian way to handle GRUB images? No, I can't just introduce new configuration variables[1]. I don't like to decide that. IMO it's more comfortable - that can't be a bad thing. IMHO it's bad for existing systems which now unexpectedly get a graphical console just because they had something lingering around in /boot/grub they probably didn't even know about. Oh come on! If you have an image file in /boot/grub/, you probably have put it there yourself. I mean, if you install desktop-base you expect (to some extent) to get a shiny gleamy look everywhere, but if you don't... ...then you won't get any GRUB background image, unless you specifically asked for it. Probably it's also bad for systems that have other ways of setting up a grub-background which includes copying images to /boot/grub. You now set them up a graphical console and you don't know if you (re-)do it before or after them, i.e. if you probably make it worse. Those packages would have to hack grub.cfg manually. I really don't care about such broken packages. The previous behaviour of 05_debian_theme was to install moreblue-orbit-grub.png from desktop-base with matching colors if possible. If not, set colors for the text interface. But now you even remove moreblue-orbit-grub.png (which is fine with me, btw.) - thats not close to the previous behaviour :) Yes it is. It's just that the default background now has a different name. Btw: Even though the removal of moreblue-orbit-grub.png is fine with me, I personally don't like the way to do it: it was installed in a package control script, it should be removed in a package control script. Installing it in the postinst was wrong. Removing it there would be even more. However, as said earlier[2] this code will be removed once squeeze is released. Still, feel free to submit a patch which moves the code to the postinst. Let me summarise: a) I intend to give the user the possibility to have no background image at all. b) I'm thinking about not setting any default background colors and just using GRUB's defaults. If you have anything else you want to discuss, please file separate bug reports. Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608283#36 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608519#56 signature.asc Description: This is a digitally signed message part
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
On Wed, Jan 05, 2011 at 07:42:37PM +0100, Alexander Kurtz wrote: Am Mittwoch, den 05.01.2011, 19:03 +0100 schrieb Mario 'BitKoenig' Holbe: 00_header - which may not be wrong (except the colors :)), but it's not 05_debian_theme's job and may clash with others not expecting it. You have to remove exactly one line to disable that feature. Yeah, that's great with what you did. But - what do you mean with you? Do you expect me (user!) to modify 05_debian_theme? Or do you mean it's easy for you (maintainer!, yes, I know you aren't but for 05_debian_theme you currently act like one :)) to disable it? I never doubt the latter :) Oh come on! If you have an image file in /boot/grub/, you probably have put it there yourself. Oh come on! You (maintainer!) put one there yourself! :) Probably it's also bad for systems that have other ways of setting up a grub-background which includes copying images to /boot/grub. You now set them up a graphical console and you don't know if you (re-)do it before or after them, i.e. if you probably make it worse. Those packages would have to hack grub.cfg manually. I really don't care about such broken packages. Nope, They would plug a script into /etc/grub.d, as you do. Mario -- You know, people think mathematics is complicated. Mathematics is the simple bit. Its the stuff we can understand. Its cats that are complicated. I mean, what is it in those little molecules and stuff that make one cat behave differently than another, or that make a cat? And how do you define a cat? I have no idea. -- John Conway signature.asc Description: Digital signature
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
Am Mittwoch, den 05.01.2011, 19:57 +0100 schrieb Mario 'BitKoenig' Holbe: Yeah, that's great with what you did. But - what do you mean with you? Do you expect me (user!) to modify 05_debian_theme? Or do you mean it's easy for you (maintainer!, yes, I know you aren't but for 05_debian_theme you currently act like one :)) to disable it? I never doubt the latter :) No, I meant that it's really easy for the GRUB maintainers to disable that feature, if they think it is necessary. Oh come on! If you have an image file in /boot/grub/, you probably have put it there yourself. Oh come on! You (maintainer!) put one there yourself! :) No, that's not true. The picture copied by the postinst (moreblue-orbit-grub.png) will be deleted and the cache file is a dotfile and will therefore not be considered. Nope, They would plug a script into /etc/grub.d, as you do. Yes, but if that script is well-written then there should be no problems. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
Hi,
I know this is a bit off-topic, but while I've been trying to solve this
bug, I noticed that 00_header uses
background_image -m stretch `make_system_path_relative_to_its_root
$GRUB_BACKGROUND`
while 05_debian_theme currently uses
background_image `make_system_path_relative_to_its_root ${1}
I'd also like to use `-m stretch' because that removes the black frame
around the image (at least on my laptop) which definitely looks better.
I guess this should be ok, right?
Best regards
Alexander Kurtz
signature.asc
Description: This is a digitally signed message part
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
On Tue, Jan 04, 2011 at 05:53:25PM +0100, Alexander Kurtz wrote:
I know this is a bit off-topic, but while I've been trying to solve this
bug, I noticed that 00_header uses
background_image -m stretch `make_system_path_relative_to_its_root
$GRUB_BACKGROUND`
while 05_debian_theme currently uses
background_image `make_system_path_relative_to_its_root ${1}
I'd also like to use `-m stretch' because that removes the black frame
around the image (at least on my laptop) which definitely looks better.
I guess this should be ok, right?
-m stretch does more than that; it scales the whole image to fit the
screen. I imagine that this will look good with some images but not
with others, which makes it kind of awkward that we didn't have -m
stretch in there to begin with since it's hard for me to say which
images will deal well with this. Do you have any way to analyse the
existing set of widely-deployed background images?
(And, of course, people will have different screen resolutions, etc.)
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
Am Dienstag, den 04.01.2011, 17:00 + schrieb Colin Watson:
Do you have any way to analyse the
existing set of widely-deployed background images?
Well, GRUB defaults to 640x480...
$ grep GFXMODE /etc/default/grub
#GRUB_GFXMODE=640x480
$ grep GFXMODE /etc/grub.d/00_header
if [ x${GRUB_GFXMODE} = x ] ; then GRUB_GFXMODE=640x480 ; fi
set gfxmode=${GRUB_GFXMODE}
$
... and most background images also seem to be 640x480:
$ cd /usr/share/images/desktop-base/
$ file debian-blueish-wallpaper-640x480.png moreblue-orbit-grub.png
spacefun-grub.png
debian-blueish-wallpaper-640x480.png: PNG image data, 640 x 480,
8-bit/color RGB, non-interlaced
moreblue-orbit-grub.png: PNG image data, 640 x 480,
8-bit/color RGB, non-interlaced
spacefun-grub.png:PNG image data, 640 x 480,
8-bit/color RGB, non-interlaced
$
$ cd /usr/share/images/grub/
$ file *
050817-N-3488C-028.tga: Targa image data - RGB 640 x 424
2006-02-15_Piping.tga: Targa image data - RGB 640 x 480
Aesculus_hippocastanum_fruit.tga: Targa image data - RGB 640 x 480
Apollo_17_The_Last_Moon_Shot_Edit1.tga: Targa image data - RGB 602 x 480
B-1B_over_the_pacific_ocean.tga:Targa image data - RGB 640 x 425
BonsaiTridentMaple.tga: Targa image data - RGB 640 x 417
Flower_jtca001.tga: Targa image data - RGB 640 x 480
Fly-Angel.tga: Targa image data - RGB 640 x 426
Glasses_800_edit.tga: Targa image data - RGB 640 x 480
Hortensia-1.tga:Targa image data - RGB 640 x 480
Lake_mapourika_NZ.tga: Targa image data - RGB 640 x 480
Moraine_Lake_17092005.tga: Targa image data - RGB 640 x 480
Plasma-lamp.tga:Targa image data - RGB 640 x 480
Sparkler.tga: Targa image data - RGB 640 x 480
TulipStair_QueensHouse_Greenwich.tga: Targa image data - RGB 640 x 480
Windbuchencom.tga: Targa image data - RGB 639 x 480
$
(And, of course, people will have different screen resolutions, etc.)
Yes, but the upstream authors probably considered that when they wrote
00_header and used `-m stretch'.
However, it's not really that important after all. I just thought it
would be more consistent to use `-m stretch' both in 00_header and
05_debian_theme...
signature.asc
Description: This is a digitally signed message part
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
Hello, I guess I can avoid a new bugreport since this one matches somehow... On Sun, Jan 02, 2011 at 05:17:05PM +0100, Alexander Kurtz wrote: Am Mittwoch, den 29.12.2010, 12:57 +0100 schrieb Miros??aw Zalewski: There is brand new 05_debian_theme in newest grub-pc. Unfortunetly, it does not allow user to have no background splash image at all, unless Yep, that's true. I'm currently thinking how the user could specify that he doesn't want a background image at all. Would it be ok, if you had to put a line like this into /etc/default/grub: GRUB_BACKGROUND= IMHO, 05_debian_theme should simply do nothing if GRUB_BACKGROUND is set (empty or not), because this one is for and handled by 00_header already (not as sophisticated as 05_debian_theme does it, but ... well...). Btw: testing for an empty but set environment variable is not that easy... :) 'if env | grep -q ^GRUB_BACKGROUND=; then ...' comes to my mind... IMHO, the same applies for the case where 05_debian_theme chooses the lexically first image in /boot/grub - just don't do it: if the user copied one there, he had to configure it somewhere anyways. Furthermore, the default colors set by 05_debian_theme for the three alternatives to grub_background.sh: GRUB_BACKGROUND, the lexically first image in /boot/grub, and for desktop-grub.png if no grub_background.sh exists are simply ... well, useless: black/black - hmmm :) Btw2: I guess, #581049 could be closed now where 05_debian_theme deals with the desktop-grub alternative. thanks for your work regards Mario -- You know, people think mathematics is complicated. Mathematics is the simple bit. Its the stuff we can understand. Its cats that are complicated. I mean, what is it in those little molecules and stuff that make one cat behave differently than another, or that make a cat? And how do you define a cat? I have no idea. -- John Conway signature.asc Description: Digital signature
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
On Tue, Jan 04, 2011 at 01:04:49AM +0100, Mario 'BitKoenig' Holbe wrote:
On Sun, Jan 02, 2011 at 05:17:05PM +0100, Alexander Kurtz wrote:
Am Mittwoch, den 29.12.2010, 12:57 +0100 schrieb Miros??aw Zalewski:
There is brand new 05_debian_theme in newest grub-pc. Unfortunetly, it
does not allow user to have no background splash image at all, unless
Yep, that's true. I'm currently thinking how the user could specify that
he doesn't want a background image at all. Would it be ok, if you had to
put a line like this into /etc/default/grub:
GRUB_BACKGROUND=
IMHO, 05_debian_theme should simply do nothing if GRUB_BACKGROUND is
set (empty or not), because this one is for and handled by 00_header
already (not as sophisticated as 05_debian_theme does it, but ...
well...).
I'm inclined to agree (pending arguments to the contrary) that
05_debian_theme should do nothing if GRUB_BACKGROUND is set to a
non-empty value. I quite like GRUB_BACKGROUND= as a way to disable
it, though.
Btw: testing for an empty but set environment variable is not that
easy... :) 'if env | grep -q ^GRUB_BACKGROUND=; then ...' comes to my
mind...
$ unset GRUB_BACKGROUND
$ [ ${GRUB_BACKGROUND+unset} ]; echo $?
1
$ GRUB_BACKGROUND=
$ [ ${GRUB_BACKGROUND+unset} ]; echo $?
0
$ GRUB_BACKGROUND=foo
$ [ ${GRUB_BACKGROUND+unset} ]; echo $?
0
IMHO, the same applies for the case where 05_debian_theme chooses the
lexically first image in /boot/grub - just don't do it: if the user
copied one there, he had to configure it somewhere anyways.
Furthermore, the default colors set by 05_debian_theme for the three
alternatives to grub_background.sh: GRUB_BACKGROUND, the lexically first
image in /boot/grub, and for desktop-grub.png if no grub_background.sh
exists are simply ... well, useless: black/black - hmmm :)
Yes - it would be better to leave them at their built-in defaults,
surely?
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
On Sun, Jan 02, 2011 at 11:22:39PM +0100, Mirosław Zalewski wrote: Since you are considering there moving GRUB_BACKGROUND_COLOR_NORMAL and GRUB_BACKGROUND_COLOR_HIGHLIGHT into /etc/default/grub, you should also consider deleting /usr/share/desktop-base/grub_background.sh file. Right now that file contains variables for splash image and colors. If these variables were to set in /etc/default/grub (which I find much more intuitive), there would be no more need of grub_background.sh file. The reason that this exists as a separate file is that it is owned by a separate package. This is deliberate - putting it in /etc/default/grub would oblige the grub2 maintainers to track desktop-base changes. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
tag 608263 confirmed thanks Am Mittwoch, den 29.12.2010, 12:57 +0100 schrieb Mirosław Zalewski: There is brand new 05_debian_theme in newest grub-pc. Unfortunetly, it does not allow user to have no background splash image at all, unless user seriously mess up with files. Yep, that's true. I'm currently thinking how the user could specify that he doesn't want a background image at all. Would it be ok, if you had to put a line like this into /etc/default/grub: GRUB_BACKGROUND= Also, it should be noted that currently there is no way to specify custom colors for GRUB2 without using background image (lines 94-99 in 05_debian_theme). That's #608283[1]. Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608283 signature.asc Description: This is a digitally signed message part
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
W dniu 2 stycznia 2011 17:17 użytkownik Alexander Kurtz kurtz.a...@googlemail.com napisał: Yep, that's true. I'm currently thinking how the user could specify that he doesn't want a background image at all. Would it be ok, if you had to put a line like this into /etc/default/grub: GRUB_BACKGROUND= I don't think that really matters. There could be just empty variable in /etc/default/grub, or that variable may contain some special keyword (none, empty” or blank comes to mind). I think that you should choose the one that you find the easiest in implementation. What is more important, that option should be somehow documented, at least in grub-pc's README.Debian file. Also, it should be noted that currently there is no way to specify custom colors for GRUB2 without using background image (lines 94-99 in 05_debian_theme). That's #608283[1]. I don't think that one was around when I was filing my bug report, but that's alright. Just wanted to point it out by the way. Since you are considering there moving GRUB_BACKGROUND_COLOR_NORMAL and GRUB_BACKGROUND_COLOR_HIGHLIGHT into /etc/default/grub, you should also consider deleting /usr/share/desktop-base/grub_background.sh file. Right now that file contains variables for splash image and colors. If these variables were to set in /etc/default/grub (which I find much more intuitive), there would be no more need of grub_background.sh file. Cheers Mirosław Zalewski -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image
Package: grub-pc
Version: 1.98+20100804-11
Severity: normal
File: /etc/grub.d/05_debian_theme
There is brand new 05_debian_theme in newest grub-pc. Unfortunetly, it
does not allow user to have no background splash image at all, unless
user seriously mess up with files.
In previous version, in order to have no background image, user had to
comment out or make empty WALLPAPER variable in
/usr/share/desktop-base/grub_background.sh
In new version if WALLPAPER variable is empty or commented out,
05_debian_theme will return an error in step two (line 51) and fall back
to set
/usr/share/images/desktop-base/desktop-grub.png
as default background (line 133). If this fails, then GRUB will fall
back to default theme without background image. But it will never fail
if desktop-base is installed.
So, in order to have no background image on GRUB2, user have to either:
a) remove desktop-base from system
b) manually edit 05_debian_theme file (i.e. commenting out lines 130-133)
c) rename /usr/share/images/desktop-base/desktop-grub.png file, so it
would not exist
I don't think that any of these is an option. First one is perhaps least
obtrusive, but I can imagine an user that wants one of themes provided by
desktop-base, but doesn't want any image on GRUB.
Also, it should be noted that currently there is no way to specify
custom colors for GRUB2 without using background image (lines 94-99 in
05_debian_theme).
I think that there could be special keyword for WALPAPER in
grub_background.sh for 05_debian_theme to just use colors from
grub_background.sh without any background image. Much as there is 'saved'
for GRUB_DEFAULT in /etc/default/grub.
Cheers
Mirosław Zalewski
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/disk/by-uuid/2e9337c0-168e-4bb8-9814-937eb6f458fa / ext4
rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
/dev/sda3 /boot ext2 rw,relatime,errors=continue 0 0
/dev/sda7 /home ext4 rw,noatime,barrier=1,data=ordered 0 0
/dev/sdc1 /mnt/zewnetrzny fuseblk
rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/disk/by-id/ata-TOSHIBA_MK3265GSX_50B8BC79B
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default=${saved_entry}
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}
function load_video {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}
insmod part_msdos
insmod ext2
set root='(hd0,msdos5)'
search --no-floppy --fs-uuid --set 2e9337c0-168e-4bb8-9814-937eb6f458fa
if loadfont /usr/share/grub/unicode.pf2 ; then
set gfxmode=640x480
load_video
insmod gfxterm
fi
terminal_output gfxterm
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
search --no-floppy --fs-uuid --set c672121e-260f-4456-a635-25890f0f6233
set locale_dir=($root)/grub/locale
set lang=pl
insmod gettext
set timeout=2
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='(hd0,msdos5)'
search --no-floppy --fs-uuid --set 2e9337c0-168e-4bb8-9814-937eb6f458fa
insmod png
if background_image /usr/share/images/desktop-base/spacefun-grub.png; then
set color_normal=black/black
set color_highlight=magenta/black
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux, with Linux 2.6.36-0.dmz.15-liquorix-amd64' --class
debian --class gnu-linux --class gnu --class os {
savedefault
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
search --no-floppy --fs-uuid --set c672121e-260f-4456-a635-25890f0f6233
echo'Loading Linux 2.6.36-0.dmz.15-liquorix-amd64 ...'
linux /vmlinuz-2.6.36-0.dmz.15-liquorix-amd64
root=UUID=2e9337c0-168e-4bb8-9814-937eb6f458fa ro acpi=copy_dsdt quiet
echo'Loading initial ramdisk ...'
initrd /initrd.img-2.6.36-0.dmz.15-liquorix-amd64
}
menuentry 'Debian GNU/Linux, with Linux 2.6.36-0.dmz.15-liquorix-amd64
(recovery mode)' --class debian --class gnu-linux --class gnu --class os {
savedefault
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
search --no-floppy --fs-uuid --set c672121e-260f-4456-a635-25890f0f6233
echo'Loading Linux 2.6.36-0.dmz.15-liquorix-amd64 ...'
linux /vmlinuz-2.6.36-0.dmz.15-liquorix-amd64
