Bug 1155228 - put variant-specific gfx in img dirs for correct product
Summary: put variant-specific gfx in img dirs for correct product
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-logos
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
Depends On: 1166175 1166176 1166177
Blocks: F21FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2014-10-21 15:36 UTC by Máirín Duffy
Modified: 2014-12-04 23:57 UTC (History)
12 users (show)

Fixed In Version: fedora-logos-21.0.5-1.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-04 23:57:52 UTC
Type: Bug


Attachments (Terms of Use)
bits for product img (945 bytes, application/x-gzip)
2014-11-14 22:26 UTC, Máirín Duffy
no flags Details
artwork for f21 anaconda themes (fedora flavors) (988.53 KB, application/x-gzip)
2014-11-14 22:27 UTC, Máirín Duffy
no flags Details

Description Máirín Duffy 2014-10-21 15:36:42 UTC
Description of problem:

we now have 3 fedora products.

the various applications that display our branding (eg grub syslinux anaconda plymouth gdm etc) were built and designed for a one product world.

it doesn't make sense to modify those products to pick between multiple products. rather, we should ship the appropriate images at the same path (e.g., /usr/share/pixmaps/logo.svg or whatever) depending on the product image that is. so /usr/shar/epixmaps/logo.svg might be the workstation logo on the workstation ISO and /usr/share/pixmaps/logo.svg might be the server logo on the server ISO.

i dont know what kind of magic has to happen for this to work, but i'm guessing it's releng related.

Comment 1 Tom "spot" Callaway 2014-10-21 15:51:12 UTC
The problem is with the pathing. We can't just have subpackages with files the same pathing, not without doing disgusting scriptlet hacks and that would screw-up rpmdb verification.

I think the cleanest solution is to have:

/usr/share/pixmaps/logo-$product.svg

Then, for each compose, either search on that syntax and use the found file or make the symlink to logo.svg.

We could also have independent fedora-logos-$product packages, but I'm really trying very hard to keep the logos contained in one SRPM for a number of reasons.

Comment 2 Máirín Duffy 2014-10-22 12:55:36 UTC
let's do the symlink way then.

how do we make this work without separate product packages?

Comment 3 Stephen Gallagher 2014-10-22 13:09:51 UTC
Just as a data point, we *do* want all of the Products to be able to see all of the logos for the other Products. Two examples of where this might be useful: Boxes and Cockpit, to display the logo of the connected server or guest.

Comment 4 Matthew Miller 2014-10-22 13:54:18 UTC
I guess this gets generally filed under "Stuff we should have figured out about two months ago". Whelp, here we are. :)

I agree that having all the logos together makes sense.

For anaconda, I think possibly the release-engineering thing to do is to create a per-product product.img in each tree, copying in the appropriate graphics -> the generic name. 

product.img is an existing anaconda feature that works exactly like updates.img http://fedoraproject.org/wiki/Anaconda/Updates but uses a different name so it doesn't collide with actual updates. So I think all we need to do is create one in each tree with the appropriate logo.

Comment 5 Matthew Miller 2014-10-22 14:44:18 UTC
Can we get a list of what graphics are shown in anaconda and which ones might need to be overridden in this way? Basically, for making rel-eng's life easy, a list of source file names from the fedora-logo and the final file name they need inside anaconda.

Comment 6 Máirín Duffy 2014-10-28 14:40:00 UTC
snipped to show the logos of concern


[duffy@pandafortress ~]$ rpm -ql fedora-logos
/boot/grub2/themes/system/background.png
/boot/grub2/themes/system/fireworks.png
/etc/favicon.png
/usr/share/anaconda
/usr/share/anaconda/boot
/usr/share/anaconda/boot/splash.lss
/usr/share/anaconda/boot/splash.png
/usr/share/anaconda/boot/syslinux-splash.png
/usr/share/anaconda/pixmaps
/usr/share/anaconda/pixmaps/anaconda_header.png
/usr/share/anaconda/pixmaps/progress_first.png
/usr/share/anaconda/pixmaps/rnotes
/usr/share/anaconda/pixmaps/rnotes/en
/usr/share/anaconda/pixmaps/rnotes/en/AskFedoraprojectorg.jpg
/usr/share/anaconda/pixmaps/rnotes/en/Cd-or-dvd.jpg
/usr/share/anaconda/pixmaps/rnotes/en/Libreoffice.jpg
/usr/share/anaconda/pixmaps/rnotes/en/Make-Fedora-Better.jpg
/usr/share/anaconda/pixmaps/rnotes/en/Rhythmbox.jpg
/usr/share/anaconda/pixmaps/rnotes/es
/usr/share/anaconda/pixmaps/rnotes/es/AskFedoraProjectorg.jpg
/usr/share/anaconda/pixmaps/rnotes/es/Cd-or-dvd.jpg
/usr/share/anaconda/pixmaps/rnotes/es/Libreoffice.jpg
/usr/share/anaconda/pixmaps/rnotes/es/Make-Fedora-Better.jpg
/usr/share/anaconda/pixmaps/rnotes/es/Rhythmbox.jpg
/usr/share/anaconda/pixmaps/rnotes/fr
/usr/share/anaconda/pixmaps/rnotes/fr/AskFedoraprojectorg.jpg
/usr/share/anaconda/pixmaps/rnotes/fr/Cd-or-dvd.jpg
/usr/share/anaconda/pixmaps/rnotes/fr/Libreoffice.jpg
/usr/share/anaconda/pixmaps/rnotes/fr/Make-Fedora-Better.jpg
/usr/share/anaconda/pixmaps/rnotes/fr/Rhythmbox.jpg
/usr/share/anaconda/pixmaps/rnotes/ja
/usr/share/anaconda/pixmaps/rnotes/ja/AskFedoraprojectorg.jpg
/usr/share/anaconda/pixmaps/rnotes/ja/Cd-or-dvd.jpg
/usr/share/anaconda/pixmaps/rnotes/ja/Libreoffice.jpg
/usr/share/anaconda/pixmaps/rnotes/ja/Make-Fedora-Better.jpg
/usr/share/anaconda/pixmaps/rnotes/ja/Rhythmbox.jpg
/usr/share/anaconda/pixmaps/rnotes/uk
/usr/share/anaconda/pixmaps/rnotes/uk/AskFedoraprojectorg.jpg
/usr/share/anaconda/pixmaps/rnotes/uk/Cd-or-dvd.jpg
/usr/share/anaconda/pixmaps/rnotes/uk/Libreoffice.jpg
/usr/share/anaconda/pixmaps/rnotes/uk/Make-Fedora-Better.jpg
/usr/share/anaconda/pixmaps/rnotes/uk/Rhythmbox.jpg
/usr/share/anaconda/pixmaps/rnotes/zh_CN
/usr/share/anaconda/pixmaps/rnotes/zh_CN/AskFedoraprojectorg.jpg
/usr/share/anaconda/pixmaps/rnotes/zh_CN/Cd-or-dvd.jpg
/usr/share/anaconda/pixmaps/rnotes/zh_CN/Libreoffice.jpg
/usr/share/anaconda/pixmaps/rnotes/zh_CN/Make-Fedora-Better.jpg
/usr/share/anaconda/pixmaps/rnotes/zh_CN/Rhythmbox.jpg
/usr/share/anaconda/pixmaps/rnotes/zh_TW
/usr/share/anaconda/pixmaps/rnotes/zh_TW/AskFedoraprojectorg.jpg
/usr/share/anaconda/pixmaps/rnotes/zh_TW/Cd-or-dvd.jpg
/usr/share/anaconda/pixmaps/rnotes/zh_TW/Libreoffice.jpg
/usr/share/anaconda/pixmaps/rnotes/zh_TW/Make-Fedora-Better.jpg
/usr/share/anaconda/pixmaps/rnotes/zh_TW/Rhythmbox.jpg
/usr/share/anaconda/pixmaps/splash.png

/usr/share/fedora-logos
/usr/share/fedora-logos/css3
/usr/share/fedora-logos/css3/README
/usr/share/fedora-logos/css3/demo.html
/usr/share/fedora-logos/css3/fedora-logo.css
/usr/share/fedora-logos/fedora_logo.svg
/usr/share/fedora-logos/fedora_logo_darkbackground.svg

/usr/share/firstboot
/usr/share/firstboot/themes
/usr/share/firstboot/themes/fedora-sphericalcow
/usr/share/firstboot/themes/fedora-sphericalcow/firstboot-left.png
/usr/share/firstboot/themes/fedora-sphericalcow/workstation.png

/usr/share/pixmaps/fedora-gdm-logo.png
/usr/share/pixmaps/fedora-logo-small.png
/usr/share/pixmaps/fedora-logo-sprite.png
/usr/share/pixmaps/fedora-logo-sprite.svg
/usr/share/pixmaps/fedora-logo.png
/usr/share/pixmaps/system-logo-white.png

Comment 7 Matthew Miller 2014-10-29 13:11:30 UTC
It appears that the current plan is to deemphasize the installer for Workstation (live image) and Cloud (also images), so I think we don't need to scramble to resolve this for F21. Moving to Rawhide.

Comment 8 Máirín Duffy 2014-10-29 14:57:29 UTC
We do need to resolve this for the login screen, don't we?

Comment 9 Stephen Gallagher 2014-10-29 15:07:40 UTC
(In reply to Matthew Miller from comment #7)
> It appears that the current plan is to deemphasize the installer for
> Workstation (live image) and Cloud (also images), so I think we don't need
> to scramble to resolve this for F21. Moving to Rawhide.

So will Server at least get its logo in the installer?

Comment 10 Matthew Miller 2014-10-29 15:12:41 UTC
(In reply to Stephen Gallagher from comment #9)
> So will Server at least get its logo in the installer?

Maybe we need to split this into separate bugs for f21 and for glorious future?

Comment 11 Máirín Duffy 2014-10-29 18:41:58 UTC
I'm assuming based on punting the ability to select the correct artwork that it's going to make the most sense to have a generic Fedora logo for F21 and wait until F22+ for product specific logos (as sad as that makes me)

Comment 12 David Shea 2014-10-29 18:50:53 UTC
(In reply to Matthew Miller from comment #7)
> It appears that the current plan is to deemphasize the installer for
> Workstation (live image)

The first thing you see when you start Workstation is a big "Install to Hard Drive" button. If you hit it, it starts the installer. The same installer. >:-[

Comment 13 Stephen Gallagher 2014-10-29 19:07:12 UTC
(In reply to Matthew Miller from comment #7)
> It appears that the current plan is to deemphasize the installer for
> Workstation (live image)

Live image still uses Anaconda to do "install to disk", so it's not "de-emphasized" at all. You are confusing this with them deciding not to ship a network install.

Comment 14 Matthew Miller 2014-10-29 19:19:47 UTC
Ah, yes, I completely am.  All right — back to f21 is appropriate. :)

Comment 15 Stephen Gallagher 2014-10-29 19:28:45 UTC
After a conversation on IRC today, I think that the early comments here are correct:

We need rel-eng to make a change to the compose process while generating product.img that includes a symlink from the product-specific art to the anaconda install art for each of the products (defaulting to a generic one for non-Products).

Dennis, can you please comment on whether this is technically feasible and available in the schedule?

Comment 16 Matthew Miller 2014-10-29 20:05:56 UTC
Note that if rel-eng says that this request might put the release in greater danger of slipping, I'm strongly inclined to keep generic installer branding for F21, and do it better for F22.

Comment 17 Matthew Miller 2014-10-29 20:07:24 UTC
We can, however, add rotating banner art that describes all three products, right? That's not ideal, but at least it won't be _nothing_.

Comment 18 Tom "spot" Callaway 2014-10-29 20:07:41 UTC
FWIW, if rel-eng can agree on a layout/naming syntax within fedora-logos for the product specific art to be used, I'm happy to add it asap (assuming that it actually exists).

Comment 19 Peter Robinson 2014-10-29 20:11:55 UTC
(In reply to Tom "spot" Callaway from comment #18)
> FWIW, if rel-eng can agree on a layout/naming syntax within fedora-logos for
> the product specific art to be used, I'm happy to add it asap (assuming that
> it actually exists).

Isn't that some what dependent on anaconda functionality as isn't it what consumes it and then the product fedora-release or kickstart then just includes the correct sub package?

Comment 20 David Shea 2014-10-29 20:15:49 UTC
(In reply to Matthew Miller from comment #16)
> Note that if rel-eng says that this request might put the release in greater
> danger of slipping, I'm strongly inclined to keep generic installer branding
> for F21, and do it better for F22.

We're still talking about a symlink, right? And will anything really be better for F22? You've had a really long time to figure it out for F21! And right now it kind of looks like crap so it'd be real nice if we didn't just keep kicking this can right through final.

(In reply to Peter Robinson from comment #19)
> Isn't that some what dependent on anaconda functionality as isn't it what
> consumes it and then the product fedora-release or kickstart then just
> includes the correct sub package?

Yes when this is done please ask us to change the string that points to the image stuff thx. I'm not real sure what you expect to be going on with subpackages though tbh.

Comment 21 Stephen Gallagher 2014-10-29 20:16:23 UTC
(In reply to Peter Robinson from comment #19)
> (In reply to Tom "spot" Callaway from comment #18)
> > FWIW, if rel-eng can agree on a layout/naming syntax within fedora-logos for
> > the product specific art to be used, I'm happy to add it asap (assuming that
> > it actually exists).
> 
> Isn't that some what dependent on anaconda functionality as isn't it what
> consumes it and then the product fedora-release or kickstart then just
> includes the correct sub package?

There are no sub-packages for the logos they are all in the fedora-logos package. Anaconda has a special spot in its configuration that it reads the image from and displays it. This is part of product.img. We need to make sure that the compose process puts the right image into that well-known location. (Of course with Matthew's caveat about not risking release slippage if this is too difficult).

Comment 22 Dennis Gilmore 2014-10-30 05:00:42 UTC
I do not know what is involved in making product.img files, we have never made them in Fedora before. This is all feature work and is not appropriate for Fedora 21 It will effect delivering of Fedora 21. we will need development time to figure out how to do all the different pieces needed. This is something that should have landed prior to alpha and as such I will be inclined to strongly push back on doing any changes for Fedora 21. Any change needs to be handled in packaging to make Fedora 21.

For Fedora 22 we need to be talking to the anaconda devs to work out how best to handle the different products. The good news is now is a great time for Fedora 22 feature development.

Comment 23 Chris Lumens 2014-10-30 13:59:26 UTC
Yes, it is appropriate for F21 given that it is branding for this split product thing.  Yes, it should have been handled prior to alpha.  Yes, you should have been talking to us the entire time about how to do this.  Given how F21 has been handled with the amount of time provided, I see no hope or evidence that F22 is going to go any differently in a shorter schedule.  But it's okay, we'll be the ones getting reviews talking about how dumb the sidebar looks.  You guys don't need to worry about little things like branding.

Comment 24 Matthew Miller 2014-10-30 14:12:19 UTC
Chris: I'm quite sure that we shouldn't ship with the (apparently intentionally ugly, someone said?) placeholder branding. The fallback should be to _generic_ (but beautiful) Fedora branding.

Dennis: product.img files are just gzipped cpio archives of replacement files. The releng changes would be:

a) _possibly_ something to automatically generate these from fedora-logos for each product, although this could be done externally. I don't think we expect rel-eng to write this alone in either case. (I guess these could even be sub-packages of fedora-logos and generated in the rpm?)

b) pulling that product.img into the images/ directory in each install tree. This is loaded at runtime from that directory by Anaconda.

Comment 25 Matthew Miller 2014-10-30 14:17:39 UTC
Mo, can you identify which graphics from the above list are essential for theming the installer? (I think not all of them are. I see on my rawhide system that 
progress_first.png still has a "17" in it.) And the rnotes images are a separate concern (as noted above, one option would be to _just_ update those, for all products together).

Spot asked for an appropriate path in the spec file: I think /usr/share/fedora-logos/{cloud,server,workstation}/ is as good as any. Mo, do we _have_ the artwork ready to go there?

Comment 26 David Shea 2014-10-30 14:40:04 UTC
(In reply to Matthew Miller from comment #24)
> Chris: I'm quite sure that we shouldn't ship with the (apparently
> intentionally ugly, someone said?) placeholder branding. The fallback should
> be to _generic_ (but beautiful) Fedora branding.

So what you're saying is that it's ok to deemphasize the product split that was supposed to be the big deal of F21. The different composes are doing a pretty crummy job of identifying themselves as different *at all*, other than one starts in GNOME and one don't. See also bug 1157685.

Comment 27 David Shea 2014-10-30 15:04:12 UTC
To confirm Matt's points about products.img:

- It is the exact same format as updates.img, a gzipped cpio file, and like updates.img whatever is in product.img will be copied onto the stage2 filesystem. So if something is in usr/share/anaconda/pixmaps in the image it will be available in /usr/share/anaconda/pixmaps in stage2.

- Anaconda+dracut looks for product.img in the images/ directory on the install media

- and to add on about bug 1157685, anaconda looks for data in /tmp/product/.buildstamp before /.buildstamp, so that's an option for delivering the Workstation buildstamp data.

Comment 28 David Shea 2014-10-30 15:14:11 UTC
(In reply to David Shea from comment #27)
> To confirm Matt's points about products.img:

typo, I meant product.img.

Comment 29 Matthew Miller 2014-10-30 16:48:03 UTC
So, we _are_ going to eventually need a product.img for differentiation, whether we rush it for F21 or plan it for F22.

That image will need to contain symlinks to the right graphics (pointing to the right graphics, with the generic name). Máirín is working on the graphics, with highest priority for nice-looking generic fedora ones, so that we will have those for final no matter what. (I guess at this point we will request an early test candidate to verify.) (Thanks Máirín!)

It will also need to contain the proper buildstamp data for each product. (Bug #1157685)

It *could* also contain other files overriding default filesystems; components, packages, or environments to be selected by default; and so on.

My suggestion is that this be generated in the fedora-release-$product RPMs, with a fedora-release-$product-productimg subpackage or the like.

Rel-eng compose scripts will find this RPM in the repo, download it, extract that product.img from the RPM, and copying into the tree under images/ (such that it gets included on the mirrors and in the live image).

Comment 30 Máirín Duffy 2014-10-31 16:26:17 UTC
For anaconda specifically, the main branding elements we need:

/usr/share/anaconda/pixmaps/sidebar-bg.png
/usr/share/anaconda/pixmaps/sidebar-logo.png
/usr/share/anaconda/pixmaps/topbar-bg.png

for (old skool) firstboot:

/usr/share/firstboot/themes/fedora-sphericalcow/firstboot-left.png

do we care about grub2 and syslinux or are we just going to leave them?

I do not know which of the multiple files I listed above GDM actually pulls to display the Fedora logo. 

This is more than anaconda tho.

If we do a logo on the wallpapers, we'd need those too.

Comment 31 David Shea 2014-10-31 16:29:43 UTC
(In reply to Máirín Duffy from comment #30)
> for (old skool) firstboot:
> 
> /usr/share/firstboot/themes/fedora-sphericalcow/firstboot-left.png

Firstboot is no longer a thing in Fedora. initial-setup uses the anaconda GUI so it would share the same images.

So I guess that's another problem, getting the productized images onto the installed system so that initial-setup can use them.

Comment 32 Matthew Miller 2014-11-03 13:25:28 UTC
To break this down further, to do this, we need:

I. Actual images, and the path they should be at in product.img
   a. images come from Design
   b. are added to fedora-logos 
        -- under /usr/share/fedora-logos/{cloud,server,workstation}
   c. question for anaconda team: can product.img contain symlinks?
        -- if so, to what exactly?
   d. if not symlinks, need exact path in cpio archive for images

II. Create product.img, put it somewhere.
   a. many possibilities for creation, ranging from
      1. I create it manually
      2. Created as part of releng process
      3. Created by an RPM
          -- either fedora-release subpackage
           -- or a new package
   b. put it somewhere could be...
      1. A fixed location on a web site
      2. In some git repo
      3. In an RPM actually in the distro

III. Releng scripts to choose appropriate img, get it, put it in place
   a. choose cloud/server/workstation as appropriate
   b. get from website, git, or rpm
   c. put into install tree in appropriate places
       -- for the mirrors, this is "os/images"
       -- not sure where for the live

Note that the product.img can be made and tested manually by putting it into a local install tree before we get to III. The releng phase is part III, and, releng people, I really don't think this is a big, dangerous, or risky change. We can try things and back it out if it doesn't work, and we can do it in a somewhat kludgy way this time around if we make a better plan for f22. However, if there isn't releng _time_ to do it, we need someone to devel exactly the patches for III for releng to apply.

Comment 33 David Shea 2014-11-03 14:47:53 UTC
(In reply to Matthew Miller from comment #32)
>    c. question for anaconda team: can product.img contain symlinks?

Yeah.

>         -- if so, to what exactly?

Whatever you need. Right now anaconda is only using /usr/share/anaconda/pixmaps/logo.png (which doesn't exist), but if the images are done more the way that RHEL was (sidebar background, sidebar logo, topbar background), we just need to uncomment the block of code that looks for /usr/share/anaconda/pixmaps/sidebar-bg.png, /usr/share/anaconda/pixmaps/sidebar-logo.png, and /usr/share/anaconda/pixmaps/topbar-bg.png.

Comment 34 Matthew Miller 2014-11-03 15:17:29 UTC
Let me clarify my concern with symlinks a little bit more. Is everything from fedora-logos available, or are just named files copied in? That is, if we have fedora-logos contain e.g.

/usr/share/anaconda/pixmaps/workstation/logo.png

and then have product.img contain a symlink:

/usr/share/anaconda/pixmaps/logo.png -> /usr/share/anaconda/pixmaps/workstation/logo.png

will that work? (And, should the path be absolute like that, or relative, and if so, relative to what?)

Thanks!

Comment 35 David Shea 2014-11-03 15:25:37 UTC
The product.img file is unpacked and blasted across the stage2 filesystem, just like updates.img, with no regard to what is already there. Dangling symlinks (in the sense that product.img contains a symlink to something not in product.img) in product.img that point to items in the stage2 filesystem are perfectly cromulent. Symlinks in product.img can overwrite paths (files or symlinks) that exist in the original stage2 filesystem. Symlinks can be absolute or relative, as long as they resolve to an actual file by the time anaconda gets to them. So

/usr/share/anaconda/pixmaps/logo.png -> /usr/share/anaconda/pixmaps/workstation/logo.png
/usr/share/anaconda/pixmaps/logo.png -> workstation/logo.png
/usr/share/anaconda/pixmaps/logo.png -> ../../anaconda/pixmaps/../pixmaps/workstation/logo.png

are all equivalent. The world is your oyster.

Comment 36 Matthew Miller 2014-11-03 15:54:28 UTC
David tells  me in IRC that everything in /usr/share/anaconda/pixmaps should be available, so for I.b., let's put the anaconda-specific product logos under

/usr/share/anaconda/pixmaps/cloud
/usr/share/anaconda/pixmaps/server
/usr/share/anaconda/pixmaps/workstation

in the fedora-logos package.

Other non-anaconda logo art can go in /usr/share/fedora-logos/{cloud,server,workstation}/

Comment 37 Máirín Duffy 2014-11-04 16:35:42 UTC
Here is the artwork with general Fedora logos (no product-specific stuff.) Will follow up with product specific ones in a bit.

https://fedorahosted.org/design-team/ticket/343#comment:1

Comment 38 Tom "spot" Callaway 2014-11-05 15:48:20 UTC
Pushed that artwork in fedora-logos.git. Waiting on product specific ones.

Comment 39 Máirín Duffy 2014-11-05 16:20:46 UTC
Here are mockups for the product-specific branding. Looking for some feedback on these:

https://fedorahosted.org/design-team/ticket/341#comment:3

Comment 40 Matthew Miller 2014-11-05 16:56:42 UTC
From IRC:

bcl │ mattdm: I just sent a couple lorax patches to the list that should make producing product.img  a bit easier.
bcl │ basically, if a package installs files to /usr/share/lorax/product/ (or ./updates/) lorax will make a product.img and/or updates.img as part of the build process.
mattdm │ bcl thanks! is that with the product or updates image rooted at that point?
bcl │ yes, the top of the directory corresponds to / on the booted rootfs

So, I'll make three packages:

fedora-productimg-workstation
fedora-productimg-server
fedora-productimg-cloud

which create the right symlinks, and then the only thing releng will need to do is to make sure the right one of these is installed at build time.

Comment 41 Matthew Miller 2014-11-05 16:57:51 UTC
(And Tom, sorry for hijacking the fedora-logos bug for coordination. Needs to be coordinated _somewhere_. :) )

Comment 42 Tom "spot" Callaway 2014-11-05 17:01:52 UTC
No worries. Just a drop in the bucket in the torrent that is my INBOX. ;)

Comment 43 Matthew Miller 2014-11-06 21:25:22 UTC
Bug #1161291, bug #1161292, and bug #1161293 give us

fedora-productimg-cloud
fedora-productimg-workstation
fedora-productimg-server

These create the symlinks in the directory given by bcl above. Right now, they're dangling, but presuming the right fedora-logos package with 

/usr/share/anaconda/pixmaps/cloud/sidebar-bg.png
/usr/share/anaconda/pixmaps/cloud/sidebar-logo.png
/usr/share/anaconda/pixmaps/cloud/topbar-bg.png

(and server and workstation, of course) is used in building anaconda, they will be valid.

So, once those packages are built, all we need is for the compose process to install the appropriate one along with lorax. I'll file a releng ticket for that once the packages are built.

Comment 44 David Shea 2014-11-06 21:41:24 UTC
(In reply to Matthew Miller from comment #43)
> These create the symlinks in the directory given by bcl above. Right now,
> they're dangling, but presuming the right fedora-logos package with 

You cool with adding a stylesheet for these, too? The design for the product-specific images involved the use of two logos (the product logo and the fedora logo), so we ended up making a couple changes to anaconda to support that kind of thing. /run/install/product/anaconda-gtk.css is loaded into anaconda, and I believe mduffy is working on the content of those.

Comment 45 Matthew Miller 2014-11-07 04:43:27 UTC
(In reply to David Shea from comment #44)
> You cool with adding a stylesheet for these, too? The design for the
> product-specific images involved the use of two logos (the product logo and
> the fedora logo), so we ended up making a couple changes to anaconda to
> support that kind of thing. /run/install/product/anaconda-gtk.css is loaded
> into anaconda, and I believe mduffy is working on the content of those.

Sure. I'm not sure if the stylesheet logically belongs in the product.img itself or in the logos. If anyone has a strong opinion, let me know, or else I'll just pick something (probably putting the css in each productimg as a file,)

Comment 46 Matthew Miller 2014-11-10 04:06:23 UTC
Changing the subject as I don't think we will actually need anything from releng here.

Comment 47 Máirín Duffy 2014-11-11 13:47:26 UTC
Matt - for whatever it's worth putting the CSS in logo seems really weird to me. I think it'd be better in product.img

Comment 48 Máirín Duffy 2014-11-14 22:26:21 UTC
Created attachment 957728 [details]
bits for product img

Matt, this tarball has a README that outlines what symlinks need to be set up and also includes the anaconda-gtk.css to theme anaconda with the fedora flavors images.

Comment 49 Máirín Duffy 2014-11-14 22:27:42 UTC
Created attachment 957729 [details]
artwork for f21 anaconda themes (fedora flavors)

Tom, can you packages these up in fedora-logos? I was thinking you could put them in /usr/share/fedora-logos

Comment 50 Matthew Miller 2014-11-17 21:19:02 UTC
Thanks Máirín!

Spot, as I understand it from David, everything in /usr/share/anaconda/pixmaps will be copied into the installer from fedora-logos. So, it's okay to put these whereever seems logical under there, and I'll adjust the product.img symlinks appropriately.

Comment 51 Mike Ruckman 2014-11-19 18:27:35 UTC
Discussed in 2014-11-19 blocker review meeting. This is accepted if the updated package is available soon enough, before TC3 compose request (Monday 2014-11-24).

Comment 52 Tom "spot" Callaway 2014-11-20 02:58:07 UTC
The update inbound has:

/usr/share/anaconda/pixmaps/cloud/
/usr/share/anaconda/pixmaps/server/
/usr/share/anaconda/pixmaps/workstation/

Within each of those dirs are these three images that correspond to that product:

sidebar-bg.png
sidebar-logo.png
topbar-bg.png

In the /usr/share/anaconda/pixmaps (topdir), the "no product" artwork is present with the same filenames.

Hopefully, this will make it "easy" for the product.img generation to do the right thing for each product. Please advise if this is not ideal.

Comment 53 Fedora Update System 2014-11-20 03:02:16 UTC
fedora-logos-21.0.5-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/fedora-logos-21.0.5-1.fc21

Comment 54 Matthew Miller 2014-11-20 03:19:01 UTC
https://admin.fedoraproject.org/updates/fedora-productimg-workstation-21-3.fc21

Note that I just built that and looked at it locally -- have not yet tested in anaconda, although I have high confidence that it will work. Will test tomorrow, as well as updating cloud and server productimg packages.

Comment 55 Fedora Update System 2014-11-20 09:06:53 UTC
Package fedora-logos-21.0.5-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing fedora-logos-21.0.5-1.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-15444/fedora-logos-21.0.5-1.fc21
then log in and leave karma (feedback).

Comment 56 Matthew Miller 2014-11-20 19:59:11 UTC
So, to bring this all together, the packages needed here are:

fedora-logos-21.0.5-1.fc21
fedora-productimg-cloud-21-5.fc21
fedora-productimg-server-21-5.fc21
fedora-productimg-workstation-21-5.fc21

thanks everyone!

Comment 57 Fedora Update System 2014-11-20 23:14:32 UTC
lorax-21.30-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/lorax-21.30-1.fc21

Comment 58 Brian Lane 2014-11-20 23:16:33 UTC
lorax will now include anything which provides lorax-product-* or lorax-updates-* and build product.img and/or updates.img from the files included in /usr/share/lorax/product and updates. Hopefully this helps resolve this.

Comment 59 Dennis Gilmore 2014-11-21 04:14:29 UTC
pungi by necessity passes a repo with Everything in it to lorax. so lorax will pull in all three fedora-productimg-<product> packages for every compose. we would really need a way to tell lorax which product we are making an install tree for.

Comment 60 Matthew Miller 2014-11-21 12:36:49 UTC
(In reply to Dennis Gilmore from comment #59)
> pungi by necessity passes a repo with Everything in it to lorax. so lorax
> will pull in all three fedora-productimg-<product> packages for every
> compose. we would really need a way to tell lorax which product we are
> making an install tree for.

Pungi does already get a "flavor" on the command line -- that's basically exactly it, right?

Comment 61 Matthew Miller 2014-11-21 12:38:33 UTC
PS: because it's done in the livecd kickstart, for F21, Workstation doesn't have the complication, so pulling the updated fedora-logos and fedora-productimg-workstation into stable doesn't need to wait on the rest.

Comment 62 Brian Lane 2014-11-21 20:46:53 UTC
(In reply to Dennis Gilmore from comment #59)
> pungi by necessity passes a repo with Everything in it to lorax. so lorax
> will pull in all three fedora-productimg-<product> packages for every
> compose. we would really need a way to tell lorax which product we are
> making an install tree for.

I've finally gotten pungi to work locally for me and figured out that the yum object passed to lorax includes all the repos from the kickstart and the local repo (to speed things up since they're already downloaded?).

This means we can use --excludepkgs in the pungi kickstart to exclude the other fedora-productimg- packages. The only drawback here is that when more are added more need to be excluded from each kickstart. But for now this will work and is minimally invasive.

So for server add:

--exclude=fedora-productimg-cloud,fedora-productimg-workstation to each repo line used, and do the similar thing for cloud and workstation.

Comment 63 Fedora Update System 2014-11-22 00:46:18 UTC
fedora-logos-21.0.5-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 64 Adam Williamson 2014-11-24 20:16:27 UTC
Re-opening as it seems https://admin.fedoraproject.org/updates/lorax-21.30-1.fc21 is also needed for this.

Comment 66 Colin Walters 2014-11-26 04:15:13 UTC
Bit of side followup in https://bugzilla.redhat.com/show_bug.cgi?id=1168079 - mainly for Fedora 22.

Comment 67 Adam Williamson 2014-11-26 04:43:47 UTC
when you say "mainly", what do you mean? if anything beyond what's listed in this bug and its dependencies needs to be included in F21, it needs to be covered by this bug or another accepted FE/blocker, or else it won't go in.

Comment 68 Matthew Miller 2014-11-26 14:25:51 UTC
(In reply to Adam Williamson (Red Hat) from comment #67)
> when you say "mainly", what do you mean? if anything beyond what's listed in
> this bug and its dependencies needs to be included in F21, it needs to be
> covered by this bug or another accepted FE/blocker, or else it won't go in.

There was some spec file logic to pregenerate a product.img to be included in the package. There was a wrong path (oops) and also an unescaped %P, strongly suggesting that the packager hadn't actually tested that part. *cough*. However, that pregenerated image isn't actually used either by lorax or by the workstation kickstart, so I think it's largely cosmetic (slash-embarrasing-for-said-packager). If getting them in can be done non-disruptively, awesome, but shouldn't get anywhere near blocking anything.

Comment 69 Adam Williamson 2014-11-28 00:03:11 UTC
I think we'd better follow strict policy and stick with -6, if they work. I don't see that fixing the product.img qualifies as FE if it isn't actually needed to address the bug.

So, we're only waiting to push lorax stable to close this, now. It should be 'addressed' in RC1.

Comment 70 Fedora Update System 2014-12-02 03:03:24 UTC
lorax-21.30-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 71 Adam Williamson 2014-12-04 23:57:52 UTC
all relevant stuff has now been pushed stable, I believe.


Note You need to log in before you can comment on or make changes to this bug.