[spin-kickstarts] #33: QA spin can't be created
by fedora-badges
#33: QA spin can't be created
----------------------------+-----------------------------------------------
Reporter: kparal | Owner: kanarip
Type: defect | Status: new
Priority: major | Milestone:
Component: kickstart pool | Keywords:
----------------------------+-----------------------------------------------
{{{
# livecd-creator -c ./spin-kickstarts/custom/qa-test-day.ks
Traceback (most recent call last):
File "/usr/bin/livecd-creator", line 140, in <module>
sys.exit(main())
File "/usr/bin/livecd-creator", line 112, in main
ks = imgcreate.read_kickstart(options.kscfg)
File "/usr/lib/python2.6/site-packages/imgcreate/kickstart.py", line 56,
in read_kickstart
except IOError, (err, msg):
ValueError: need more than 1 value to unpack
}}}
The %include lines point to non-existing files. That is a recursive
problem, starting in custom/fedora-livecd-desktop.ks file.
--
Ticket URL: <https://fedorahosted.org/spin-kickstarts/ticket/33>
spin-kickstarts <https://fedorahosted.org/spin-kickstarts/>
Kickstarts that the Spin SIG reviews, tests, maintains and releases (as a package).
13 years, 8 months
Re: [Fedora-spins] Board SWG questions for Spins Owners
by Matt Domsch
Maybe Engineering Services could take this on.
-----Original Message-----
From: "Matt Domsch" <matt(a)domsch.com>
Date: Tue, 30 Mar 2010 16:38:08
To: The Spin Special Interest Group mailing list<spins(a)lists.fedoraproject.org>
Subject: Re: [Fedora-spins] Board SWG questions for Spins Owners
I ran into this just this week too. Isohybrid script is pretty small and could be re-written in C by someone who passed C 101 in a day or so I'd think.
-----Original Message-----
From: Peter Robinson <pbrobinson(a)gmail.com>
Date: Tue, 30 Mar 2010 17:08:06
To: The Spin Special Interest Group mailing list<spins(a)lists.fedoraproject.org>
Subject: Re: [Fedora-spins] Board SWG questions for Spins Owners
On Fri, Feb 26, 2010 at 4:41 PM, Bill Nottingham <notting(a)redhat.com> wrote:
> Christoph Wickert (christoph.wickert(a)googlemail.com) said:
>> > > > The first is a policy issue that could be redressed. The second is
>> > > > unlikely to change (and would imply you'd be signing up to write your
>> > > > own if you didn't want to use anaconda/firstboot, which I can't imagine
>> > > > is what you want), and the third probably requires patch submissions.
>> > > >
>> > > > (Note: due to the requirements for a window manager at installation
>> > > > time, anaconda may very well require metacity in the near future.)
>> > >
>> > > Why not a virtual provide and let the spin maintainers and users decide?
>> > > In F12 we changed anaconda to use any display manager that has a virtual
>> > > provides for "service(graphical-login)" instead of hardcoding a list of
>> > > display managers. We should do the same for window manager.
>> >
>> > anaconda, firstboot, and whatever would need a mechanism to start
>> > random-window-manager of the day and adjust the configuration as needed.
>> > If that's important to people, they should submit patches.
>>
>> It is not random but defined by the user or maintainer. All the spins
>> except the Desktop Spin already (have to) configure
>> /etc/sysconfig/desktop.
>
> Getting arbitrary things into the anaconda image isn't trivial - it involves
> explicitly listing packages and files to use. firstboot's a little better,
> as it's actually working on an installed system. As I said, if you or others have
> interest in making this possible, the way to start is with patches or patch proposals.
> Get all the WMs that people might want for this providing something that can
> automatically determine the command to run. Make sure that they all do the
> right thing without needing random arguments passed to them. Then work
> from there with patches to apps.
I would like to see it support at least mutter, not sure that this
should be too hard as its based on metacity anyway. For a gnome-shell
based gnome or Mobline/Meego it seems a little overkill having
metacity and deps just for install.
I'd also like to see the removal of the requirement of perl (via perl
scripts in syslinux) as it added about 10% to the F-12 test LiveCDs I
did off Moblin. Anaconda uses a single of these scripts and only for
the creation of hybrid boot cds (see bugs 544136 and 559644 ), This is
also relevant for the Sugar on a Stick spin as well. Its the last dep
remaining on perl in both those spins (and I suspect the desktop spins
as well).
Peter
_______________________________________________
spins mailing list
spins(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/spins
13 years, 8 months
Re: [Fedora-spins] Board SWG questions for Spins Owners
by Christoph Wickert
Am Mittwoch, den 24.02.2010, 23:38 -0600 schrieb Matt Domsch:
> These questions were originally posted to the Spins SIG a couple weeks
> ago. At the following SIG meeting, members suggested that these
> questions would be better posed to the individual spin owners, or
> teams that are working on the spins, in addition to the SIG.
The Spins SIG consists of the spin owners and we already discussed this
in the Spins SIG meetings of the last two weeks. I think most of the
spin owners already outlined their point of view in the meetings, some
also relied to your mail.
In addition to this I already wrote something on the board's mailing
list last week. Nevertheless I will try to answer the question once
again, this time a little more detailed.
[snipped]
> Board-level Question:
> Can Spins/SIGS or Fedora remixes define their own target audience?
>
> Background
>
[snipped]
>
> Possible Solutions
>
> 1. Board sets target audience broadly, spins tailor to a subset
> thereof.
>
> 2. Board sets target audience broadly, spins tailor to either a
> subset thereof, or to additional audiences outside that scope so
> long as there are no conflicts.
>
> 3. Board does not set target audience, leaves it to each Spin to
> set their specific target audience.
> 1. requires spins to be much more than consumers of Fedora
> content.
> 2. audience of some spins may overlap. That's OK.
> 3. audience of some spins may technically conflict. How to
> resolve conflicts? Spins -> FESCo -> Board.
>
>
> As members contributing to Spins, how do you view the above, and how
> would you like to see Spins interact with the larger Project with
> respect to defining target audiences?
I don't really understand all this discussion about a target audience or
potential problems. The definitions are on a completely different level.
The board is the political body of the Fedora Project. Thus their
definition of a target audience is a political decision. The Spins SIG
on the other hand works on technical implementations, this means their
definition of target audience is more technical.
So far, the board has defined a "working" target audience. Early
adopters who always want the latest and greatest technology and who are
not afraid of changes. Active users who are interested in development.
People who don't mind searching the net for a solution to a technical
problems. People who like to contribute.
I think all spin maintainers can subscribe to this point of view,
otherwise we would not contribute to Fedora. Same goes for the users:
They may want to use this or that spin, but first off all they want to
use Fedora as such. If they don't like Fedora, they will not use our KDE
Spin but another KDE-based distro.
Given the boards definition remains political, I have no problems with
ether one of the possible answers. The technical implementation of the
spins is automatically a subset of the board's definition. But if the
boards starts defining technical goals such as "lets prefer GNOME users
because Red Hat contributes to GNOME a lot and the Desktop Spin is our
flagship product" we will run into trouble. Then the spins must be able
to define their own target audience, even outside the audience defined
by the board.
Let's face it: Although we already have a target audience, we have case
3.3: Spins technically do conflict. I will explain this below. What I
want to say is that IMO the answers lack another possibility: The board
sets a target audience but still there are conflicts.
So before I can decide on one of the possible solutions, I'd like to
hear a definition of "target audience". I know this is a bit of a
chicken and egg problem, but I think at the current state the board
should be able to at least say on what level will this audience be
defined. Political and theoretical or technical and applied?
> Board-level Question:
> Can Spins/SIGS or Fedora remixes change the code enough to meet their
> goals?
>
> Background
>
[snipped]
>
> Given the present situation:
>
> 1. Has any Spin found the present situation unduly restrictive?
> 1. If so, how specifically?
A spin is defined as installable Live-CD. This means it must ship
anaconda and firstboot. firstboot requires system-config-keyboard
requires metacity requires GConf2 and tons of other GNOME stuff. There
are other dependency chains as well (e.g. notification-daemon), but this
is the worst one.
> 2. Has any Spin found they cannot address their target audience
> properly?
> 1. If so, in what way?
Xfce users want Xfce, LXDE users want LXDE. Both want a lightweight
system, otherwise they would likely be using GNOME. But what they get is
more or less GNOME. Without all the GNOME packages we would have
significantly more space on the media.
> 2. Is the root problem that all packages must be in the
> official repositories?
No, the root of the problems are the GNOME maintainers refuse to
consider other desktops and their users.
I'm convinced that we can address these issues on a technical level in
one repository. OpenSUSE already does a great job here: They have
different branding packages wich contain the SUSE specific changes. This
is similar to what we do with fedora-logos, but it's a more complete
approach.
For example, there is a package called gconf2-branding-openSUSE which
contains all the modified GConf schemas. By replacing this package, you
can change the complete settings of the GNOME desktop. This would be
useful for us too, think of a GNOME based Fedora Mini Spin for Netbooks,
that wants to use another other panel layout. We cannot do this in
Fedora ATM, but it is possible. For more info about OpenSUSE's branding,
see http://en.opensuse.org/Packaging/Branding
We must not break up into different projects like Ubuntu with Kubuntu,
Xubuntu and Lubuntu because this results in a duplication of work and
incompatible packages. Instead everything should happen under the
umbrella of the Fedora Project. We need to work out the problems on a
technical level instead of forking. I'm sure we can do it if all desktop
SIGs cooperate.
> 3. How are you addressing this today?
We cannot. Currently *all* spins must ship metacity and all it's
dependencies.
> 4. How would you like to address this in the future?
With more fine grained packaging. Introduce a virtual provides for
window-managers instead of hardcoding one. system-config-keyboard
maintainer refused to do this in the past, but now that we have the
critical paths set for each desktop, I don't see why the virtual
provides would introduce problems.
> 5. Are the resources you would need readily available?
> 1. If not, what would you need to properly address this?
* Webspace for direct downloads of the spins. not only torrents.
* A way to count these downloads.
* Officially labeled live media of the spins for promotion. In
EMEA we currently have GNOME, not even KDE.
> 6. Is the transition from "Spin" to "Remix" onerous?
> 1. If so, what can be done to make it less so?
I don't think the transition from a spin to a remix is onerous, but from
a remix to a spin it's problematic because one has to follow all the
Fedora guidelines and restrictions. This is why I think we need the
remixes and we cannot really forbid them.
However I think we should not advocate remixes, at least not if they are
questionable. I never understood why the board approved the Fedora
Russia Remix and allowed it to use the Fedora trademark. It contains
non-free software or codecs and thus violates our very basic
foundations.
As long as a spin follows the Fedora foundations, I have no problems
with it. Maybe it's necessary because some things are technically not
possible in Fedora ATM. This is one more reason why I think we need to
work on solving technical issues with the spins in Fedora: The more free
the spin maintainers are, the less reason they have to do a remix
instead of a proper spin.
Regards,
Christoph
13 years, 8 months
Re: [Fedora-spins] spin kickstart/minimization cleanups
by Colin Walters
[ dropping -devel since the comps changes are done, readding spins]
Ok so I pushed the spins commits with fixes suggested by people,
here's the current status. Both of these are x86_64, I'm doing a i386
now too (which I expect to be smaller).
-rw-r--r--. 1 root root 695205888 2010-03-24 15:00
livecd-fedora-livecd-desktop-201003241432.iso
-rw-r--r--. 1 root root 976224256 2010-03-24 15:45
livecd-fedora-live-desktop-201003241513.iso
But basically we have a CD image again for people who really need it.
What exactly the messaging on this should be is a bit up in the air;
I'd suggest it be positioned mainly as "rescue/barebones install".
I'm going to wrangle a bit and see if I can get the live-desktop down
more.
13 years, 8 months
Proposal: move comps to fedorahosted git
by Bill Nottingham
I'd like to propose moving comps to fedorahosted git.
Why? Because CVS is a pain.
I can work on fixing the automated releng tasks that use comps.
What I'd like to know is if doing this at some point over the
next few weeks (say, post-Alpha) would be a problem for people.
If it is, we can push it off until after F13 ships.
Bill
13 years, 9 months
