Bug 1155228

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.

let's do the symlink way then.

how do we make this work without separate product packages?

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.

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.

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.

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

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.

We do need to resolve this for the login screen, don't we?

(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?

(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?

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)

(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. >:-[

(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.

Ah, yes, I completely am.  All right — back to f21 is appropriate. :)

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?

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 can, however, add rotating banner art that describes all three products, right? That's not ideal, but at least it won't be _nothing_.

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).

(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?

(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.

(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).

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.

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.

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.

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?

(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.

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.

(In reply to David Shea from comment #27)
> To confirm Matt's points about products.img:

typo, I meant product.img.

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).

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.

(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.

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.

(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.

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!

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.

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}/

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

Pushed that artwork in fedora-logos.git. Waiting on product specific ones.

Here are mockups for the product-specific branding. Looking for some feedback on these:

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

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.

(And Tom, sorry for hijacking the fedora-logos bug for coordination. Needs to be coordinated _somewhere_. :) )

No worries. Just a drop in the bucket in the torrent that is my INBOX. ;)

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.

(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.

(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,)

Changing the subject as I don't think we will actually need anything from releng here.

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

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.

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

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.

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).

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.

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

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.

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).

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!

lorax-21.30-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/lorax-21.30-1.fc21

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.

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.

(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?

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.

(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.

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.

Re-opening as it seems https://admin.fedoraproject.org/updates/lorax-21.30-1.fc21 is also needed for this.

also needed via dependent bugs: https://admin.fedoraproject.org/updates/FEDORA-2014-15599/fedora-productimg-workstation-21-6.fc21 , https://admin.fedoraproject.org/updates/FEDORA-2014-15632/fedora-productimg-cloud-21-6.fc21 , https://admin.fedoraproject.org/updates/FEDORA-2014-15568/fedora-productimg-server-21-6.fc21 .

Bit of side followup in https://bugzilla.redhat.com/show_bug.cgi?id=1168079 - mainly for Fedora 22.

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.

(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.

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.

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.

all relevant stuff has now been pushed stable, I believe.