[spin-kickstarts/f17] Add ConsoleKit for now until we move away from gdm.
by Kevin Fenzi
commit 4fe4f2d055944416e0e0d786bec3b815e6a15cb4
Author: Kevin Fenzi <kevin(a)scrye.com>
Date: Mon Mar 12 09:40:56 2012 -0600
Add ConsoleKit for now until we move away from gdm.
fedora-livecd-xfce.ks | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
---
diff --git a/fedora-livecd-xfce.ks b/fedora-livecd-xfce.ks
index 6c0b8eb..79aee90 100644
--- a/fedora-livecd-xfce.ks
+++ b/fedora-livecd-xfce.ks
@@ -69,6 +69,7 @@ setroubleshoot
catfish
galculator
seahorse
+ConsoleKit
# More Desktop stuff
# java plugin
12 years, 1 month
[spin-kickstarts] (14 commits) ...Merge branch 'f17'
by Amit Saha
Summary of changes:
7b49a5c... robotics: add pcl-devel to default packages (*)
a3302bb... Merge branch 'master' into f17 (*)
4f68698... Revert "robotics: add pcl-devel to default packages" (*)
dcce713... robotics: add pcl-devel to default packages (*)
821fa0f... specspo is no longer in repo, so stop excluding it (*)
0f1ceca... wormux has been renamed warmux (*)
398fef3... Games: Still oversize so drop FlightGear (*)
f1ed2cf... fedora-livecd-kde.ks: Remove the commented out -konq-plugin (*)
b87c0bb... fedora-live-kde.ks: Update list of kdeedu apps. (*)
3cc088b... fedora-livecd-kde.ks: Readd amarok and update comment. (*)
59118f7... fedora-livecd-kde.ks: Don't explicitly blacklist kdeedu*. (*)
8a879a6... kde: s/koffice/calligra/ (*)
83a5d2d... Scientific spin: include SAGE, python-pp and some meta-data (*)
a1fb14d... Merge branch 'f17'
(*) This commit already existed in another branch; no separate mail sent
12 years, 1 month
[spin-kickstarts/f17] Scientific spin: include SAGE, python-pp and some meta-data editing
by Amit Saha
commit 83a5d2d46bd6c0c4687e41134d502200dd85060f
Author: Amit Saha <amitksaha(a)fedoraproject.org>
Date: Sat Mar 10 23:50:58 2012 +1100
Scientific spin: include SAGE, python-pp and some meta-data editing
fedora-livedvd-scientific-kde.ks | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
---
diff --git a/fedora-livedvd-scientific-kde.ks b/fedora-livedvd-scientific-kde.ks
index f33bbd6..f544872 100644
--- a/fedora-livedvd-scientific-kde.ks
+++ b/fedora-livedvd-scientific-kde.ks
@@ -5,11 +5,12 @@
# Fedora-Scientific aims to create a Fedora which has the generic
# toolset for the researcher
# Web: https://fedoraproject.org/wiki/Scientific_Spin
+# Web: http://spins.fedoraproject.org/scientific-kde/
-# Maintainer: Amit Saha <droidery(a)gmail.com>
-# FAS username: amitksaha
+# Maintainer: Amit Saha <amitksaha(a)fedoraproject.org>
+# https://fedoraproject.org/wiki/User:Amitksaha
-# Last modified: October 23, 2011.
+# Last modified: March 10, 2012.
%include fedora-live-kde.ks
@@ -21,6 +22,11 @@ part / --size 10000
# Installing the default/mandatory packages from engineering & scientific
@engineering-and-scientific
+# scilab
+scilab
+scilab-devel
+scilab-doc
+
#Devel tools
#Install the mandatory packages from dev-tools and dev-libs
@@ -68,8 +74,11 @@ pdfshuffler
# Parallel/Distributed computing libraries/tools
openmpi
valgrind-openmpi
+pvm
pvm-gui #will install 'pvm' as well
libgomp
+python-pp
+
#Version control- a GUI for each as well
12 years, 1 month
Unquarantined: Re: [Yum-devel] Forwarding on a Fedora discussion - Packaging & installation
by James Antill
On Fri, 2012-03-02 at 14:13 -0500, Bill Nottingham wrote:
> Forwarding this along, as we may need yum changes for what's being proposed
> here. See the questions at the end, especially.
Thought about it a bit, hopefully not lost the plot...
[...]
> David Lehman (dlehman(a)redhat.com) said:
> Bill Nottingham wrote:
> > In theory, what we need is two new meta-group types: variant (aka spin)
> > and addon. Each is a set of groups. You can only have one variant
> > selected or installed at any given time. Each variant defines a set of
> > addons, of which any number may be selected/installed. Regular groups
> > and packages are only exposed via kickstart, if at all.
> >
> > Once we have the groups set up and accompanying kickstart support, the
> > spins should end up being exactly the same package set as you'd get by
> > choosing the same variant+addons in the anaconda software selection ui.
> > The addition of meta-packages and/or kickstart script snippets (perhaps
> > per variant?) could bridge the gap so that the spins end up identical to
> > the corresponding anaconda variant/addon selections.
> >
> > How does this fit with your proposal and your concerns?
>
> I can see this working. Initial concerns:
>
> - Would we need to drive the variants and add-ons into first class objects
> in yum as well (such that, if intstalled, they're marked on the system in
> some way (yumdb, etc.), and that they can be installed post-install, etc?)
> The simplest solution is add these as additional sections in the comps file,
> and parse them with yum's comps module - the question is whether this info
> is used in yum itself outside of that, or if it's left for higher-level tools.
Yeh, we basically have four general approaches (that I can
see/think-of):
1. Have yum.comps parse out the new "variant" and "add-on" groups,
providing some API way to see what they are ... but have anaconda map
those to groups, and just have the yum internals (including the new
groups as objects code) know about the groups.
pros:
p1. This is a trivial yum change.
p2. Kind of easy to explain as "this is an install thing", post
install just use groups.
cons:
c1. Yum won't be able to "upgrade" a variant/add-on if new groups are
desired to be added post install.
c2. Yum won't be able to "install" a variant/add-on post install.
c3. Kickstart will have to do @foo lookups before passing them to yum
(or not have variant/add-on installs via. kickstart).
c4. Nothing will be able to know what variant/add-ons were installed.
2. #1 but also have yum do the variant/add-on mapping ... we mostly keep
p1/c1/c4 from #1 but we can install post and can easily have them in
kickstart. But it's harder to explain where the line is, and it's
basically the same mistake we made with current groups (people expect
them to not just be references, but that's what they are).
3. Have yum.comps create new groups, containing packages, for the
variant/add-ons. anaconda/etc. will just tell yum to install the variant
but it'll be a single giant group containing all the packages.
pros:
p1. Again, fairly trivial change.
p2. Kind of easy to explain as "these are just groups, that are
created a bit special".
p3. Yum can install them post install.
p4. Yum can upgrade them post install (ie. add groups/packages to
an add-on and "yum upgrade" will get them).
p5. Not much needs to be done to anaconda.
p6. User/API/whatever can mostly see which variant/add-ons were
installed, assuming it knows what it is looking for (Eg. current
GUIs will mostly show it, albeit in a somewhat confusing way).
cons:
c1. Add-ons will mostly _be_ groups. Eg. with "groups as objects"
packages can only belong to a single group (don't ask for this
to change, unless you have patches). This means that if you have
an add-on called "Developer Workstation" which includes
"gnome-desktop" and "rhel-developer" ... then the later two groups
_won't_ be installed, just the single "Developer Workstation"
group will be (but it'll automatically contain all the packages
of all the groups it refers to -- so "upgrade" will work the same
it'll just look "different").
4. Have yum.comps create variant/add-on "groups", containing just
references to other groups.
pros:
p1. Yum can install them post install.
p2. Yum can upgrade them post install (ie. add groups/packages to
an add-on and "yum upgrade" will get them).
p3. User/API/whatever can see which variant/add-ons were installed
easily (Eg. subscription manager might have a _much_ easier time).
p4. Groups still exist, and are what a package belongs to.
p5. Not much needs to be done to anaconda.
cons:
c1. A bunch more code has to be written, to save/integrate these
special groups into yum (so Eg. "install @foo" does multiple
lookups). Esp. need to save them specially.
c2. A bunch more code would need to be written for any GUIs to show
these special groups, and how you can manipulate them.
c3. We have a tree mapping: variant _ group1 => package
\_ group2 => package
add-on1 _ group3 => package
\_ group4 => package
\_ group5 => package
...which we'll need to make the user aware of, and is not as simple
concept wise.
...option #4 seems "obviously" the best, where even c1 and c2 are really
just specific instances of c3 ... but it is the most code, and a big
model change. #2 and #3 seem like hacks, but hacks with somewhat
desirable behaviour ... #1 is the "this will cleanup anaconda code, but
not really change much else" option.
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
12 years, 1 month
Re: [Fedora-spins] [Yum-devel] Forwarding on a Fedora discussion - Packaging & installation
by James Antill
On Fri, 2012-03-02 at 14:13 -0500, Bill Nottingham wrote:
> Forwarding this along, as we may need yum changes for what's being proposed
> here. See the questions at the end, especially.
Thought about it a bit, hopefully not lost the plot...
[...]
> David Lehman (dlehman(a)redhat.com) said:
> Bill Nottingham wrote:
> > In theory, what we need is two new meta-group types: variant (aka spin)
> > and addon. Each is a set of groups. You can only have one variant
> > selected or installed at any given time. Each variant defines a set of
> > addons, of which any number may be selected/installed. Regular groups
> > and packages are only exposed via kickstart, if at all.
> >
> > Once we have the groups set up and accompanying kickstart support, the
> > spins should end up being exactly the same package set as you'd get by
> > choosing the same variant+addons in the anaconda software selection ui.
> > The addition of meta-packages and/or kickstart script snippets (perhaps
> > per variant?) could bridge the gap so that the spins end up identical to
> > the corresponding anaconda variant/addon selections.
> >
> > How does this fit with your proposal and your concerns?
>
> I can see this working. Initial concerns:
>
> - Would we need to drive the variants and add-ons into first class objects
> in yum as well (such that, if intstalled, they're marked on the system in
> some way (yumdb, etc.), and that they can be installed post-install, etc?)
> The simplest solution is add these as additional sections in the comps file,
> and parse them with yum's comps module - the question is whether this info
> is used in yum itself outside of that, or if it's left for higher-level tools.
Yeh, we basically have four general approaches (that I can
see/think-of):
1. Have yum.comps parse out the new "variant" and "add-on" groups,
providing some API way to see what they are ... but have anaconda map
those to groups, and just have the yum internals (including the new
groups as objects code) know about the groups.
pros:
p1. This is a trivial yum change.
p2. Kind of easy to explain as "this is an install thing", post
install just use groups.
cons:
c1. Yum won't be able to "upgrade" a variant/add-on if new groups are
desired to be added post install.
c2. Yum won't be able to "install" a variant/add-on post install.
c3. Kickstart will have to do @foo lookups before passing them to yum
(or not have variant/add-on installs via. kickstart).
c4. Nothing will be able to know what variant/add-ons were installed.
2. #1 but also have yum do the variant/add-on mapping ... we mostly keep
p1/c1/c4 from #1 but we can install post and can easily have them in
kickstart. But it's harder to explain where the line is, and it's
basically the same mistake we made with current groups (people expect
them to not just be references, but that's what they are).
3. Have yum.comps create new groups, containing packages, for the
variant/add-ons. anaconda/etc. will just tell yum to install the variant
but it'll be a single giant group containing all the packages.
pros:
p1. Again, fairly trivial change.
p2. Kind of easy to explain as "these are just groups, that are
created a bit special".
p3. Yum can install them post install.
p4. Yum can upgrade them post install (ie. add groups/packages to
an add-on and "yum upgrade" will get them).
p5. Not much needs to be done to anaconda.
p6. User/API/whatever can mostly see which variant/add-ons were
installed, assuming it knows what it is looking for (Eg. current
GUIs will mostly show it, albeit in a somewhat confusing way).
cons:
c1. Add-ons will mostly _be_ groups. Eg. with "groups as objects"
packages can only belong to a single group (don't ask for this
to change, unless you have patches). This means that if you have
an add-on called "Developer Workstation" which includes
"gnome-desktop" and "rhel-developer" ... then the later two groups
_won't_ be installed, just the single "Developer Workstation"
group will be (but it'll automatically contain all the packages
of all the groups it refers to -- so "upgrade" will work the same
it'll just look "different").
4. Have yum.comps create variant/add-on "groups", containing just
references to other groups.
pros:
p1. Yum can install them post install.
p2. Yum can upgrade them post install (ie. add groups/packages to
an add-on and "yum upgrade" will get them).
p3. User/API/whatever can see which variant/add-ons were installed
easily (Eg. subscription manager might have a _much_ easier time).
p4. Groups still exist, and are what a package belongs to.
p5. Not much needs to be done to anaconda.
cons:
c1. A bunch more code has to be written, to save/integrate these
special groups into yum (so Eg. "install @foo" does multiple
lookups). Esp. need to save them specially.
c2. A bunch more code would need to be written for any GUIs to show
these special groups, and how you can manipulate them.
c3. We have a tree mapping: variant _ group1 => package
\_ group2 => package
add-on1 _ group3 => package
\_ group4 => package
\_ group5 => package
...which we'll need to make the user aware of, and is not as simple
concept wise.
...option #4 seems "obviously" the best, where even c1 and c2 are really
just specific instances of c3 ... but it is the most code, and a big
model change. #2 and #3 seem like hacks, but hacks with somewhat
desirable behaviour ... #1 is the "this will cleanup anaconda code, but
not really change much else" option.
12 years, 1 month
[spin-kickstarts/f17] kde: s/koffice/calligra/
by Kevin Kofler
commit 8a879a6e77597897fe331cbcfaff6c527e91c896
Author: Rex Dieter <rdieter(a)fedoraproject.org>
Date: Wed Feb 29 11:51:58 2012 -0600
kde: s/koffice/calligra/
fedora-live-kde.ks | 4 ++--
fedora-livecd-kde.ks | 9 ++++-----
2 files changed, 6 insertions(+), 7 deletions(-)
---
diff --git a/fedora-live-kde.ks b/fedora-live-kde.ks
index 222dfd7..4c1b5af 100644
--- a/fedora-live-kde.ks
+++ b/fedora-live-kde.ks
@@ -22,7 +22,7 @@ kde-wallpapers
# Additional packages that are not default in kde-desktop but useful
k3b # ~15 megs
-koffice-suite
+calligra
#kdeartwork # only include some parts of kdeartwork
#twinkle # (~10 megs)
fuse
@@ -60,7 +60,7 @@ octave # runtime dependency of the Cantor Octave backend
# KDE 4 translations
kde-l10n-*
-koffice-langpack-*
+calligra-l10n-*
# use yum-presto by default
yum-presto
diff --git a/fedora-livecd-kde.ks b/fedora-livecd-kde.ks
index 82fc7c4..0b359c9 100644
--- a/fedora-livecd-kde.ks
+++ b/fedora-livecd-kde.ks
@@ -27,11 +27,10 @@
# Additional packages that are not default in kde-desktop but useful
k3b # ~15 megs
--koffice-suite # don't include whole koffice-suite, just parts of it
-koffice-kword
-koffice-kspread # ~1 megs
-koffice-kpresenter # ~3 megs
-koffice-filters
+-calligra # don't include whole calligra, just parts of it
+calligra-words
+calligra-tables # ~1 megs
+calligra-stage # ~3 megs
#kdeartwork # only include some parts of kdeartwork
#twinkle # (~10 megs)
fuse
12 years, 1 month
Packaging & installation
by Bill Nottingham
Prompted by David Lehman's patch set, I wanted to discuss how we're
building what we're installing in Fedora and RHEL, and how we might need to
represent that both in the media and in the UI.
What we've got now exposed at the lowest level (yum/kickstart) and supported
as first-level objects throughout the system:
1. packages
2. groups (of packages)
3. repos (which contain group lists, and packages)
What we additionally expose only in anaconda, and lose post-install:
4. tasks in install classes (lists of groups)
What we expose in Fedora:
5. spins (live ISO via kickstart file)
6. 'the install DVD' (a package set via a kickstart file)
What we expose in RHEL:
7. variants (essentially, a spin that's a package set instead of a live ISO)
8. add-ons (repos, with groups, that apply to specific variants)
All of these use the comps file, which is a list of groups.
Now, as we rework anaconda's UI (and backend, per dlehman's patches), we
need to make sure not to break everything horribly.
In Fedora, spins and the install DVD are driven off of kickstart files. This
was done because it's the only thing pungi and livecd-creator supports, and
because each spin/install DVD is a distinct object that can have its own
kickstart. Anaconda doesn't need to worry about separately consuming them,
as there's only one repo to ever pull from, and the spins are live images.
In RHEL, variants and add-ons are driven off of a different set of files,
for assorted historical reasons. Kickstart files don't directly work here
because they don't allow you to define intermediate objects (add-ons) that
are presented in the installer. Anaconda processes variants and add-ons via
code that reads .treeinfo.
PROPOSAL GIVEN THE NEW UI
For reference, the proposed new UI is at:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Live%20Prototypes/07-sof...
As you'll notice, it contains something that looks like a spin or variant on
the left, and things that could be considered 'add-ons' on the right. These
apply to the choices on the left.
This would seem to fit nicely into the variants + add-ons model that RHEL
uses. However, there are a couple of problems:
- The code that parses the variants/add-on information and creates the
appropriate .treeinfo bits does not exist in Fedora
This is obviously a simple matter of not-so-simple code.
- It requires creating a separate set of metadata (the variants file) that
does not currently exist.
This is relatively trivial.
- It can cause skew between the live and not-live spins if this variants file
falls out of sync with the kickstarts in spin-kickstarts.
This is ugly - how can we get these to use a single set of data?
Unfortunately, kickstart's %packages model doesn't give us an easy way to
define a variant and its add-ons in a kickstart file. Ideas?
Bill
12 years, 1 month
[spin-kickstarts/f17] fedora-livecd-kde.ks: Don't explicitly blacklist kdeedu*.
by Kevin Kofler
commit 59118f72cc2a92c105204cc3c232a666f58fefc2
Author: Kevin Kofler <Kevin(a)tigcc.ticalc.org>
Date: Thu Mar 1 02:11:26 2012 +0100
fedora-livecd-kde.ks: Don't explicitly blacklist kdeedu*.
kdeedu is not installed by default in the first place anyway, and if it were,
the kdeedu* wildcard would not match the new split packages anymore.
fedora-livecd-kde.ks | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
---
diff --git a/fedora-livecd-kde.ks b/fedora-livecd-kde.ks
index ef6dea6..82fc7c4 100644
--- a/fedora-livecd-kde.ks
+++ b/fedora-livecd-kde.ks
@@ -16,7 +16,6 @@
# don't include these for now to fit on a cd
-desktop-backgrounds-basic
-kdeaccessibility*
--kdeedu* # kdeedu is too big for the live images
-scribus # scribus is too big for the live images
-kdeartwork-screensavers # screensavers are not needed on live images
#-ktorrent # kget has also basic torrent features (~3 megs)
12 years, 1 month
[spin-kickstarts/f17] fedora-livecd-kde.ks: Readd amarok and update comment.
by Kevin Kofler
commit 3cc088bb120330ed6b31ed2445d052d87fcdb822
Author: Kevin Kofler <Kevin(a)tigcc.ticalc.org>
Date: Thu Mar 1 02:10:07 2012 +0100
fedora-livecd-kde.ks: Readd amarok and update comment.
Let's try readding Amarok again, now that JuK is gone. Hopefully the comps
changes were sufficient to make it fit.
fedora-livecd-kde.ks | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/fedora-livecd-kde.ks b/fedora-livecd-kde.ks
index d718c6a..ef6dea6 100644
--- a/fedora-livecd-kde.ks
+++ b/fedora-livecd-kde.ks
@@ -21,7 +21,7 @@
-kdeartwork-screensavers # screensavers are not needed on live images
#-ktorrent # kget has also basic torrent features (~3 megs)
-digikam # digikam has duplicate functionality with gwenview (~28 megs)
--amarok # amarok has duplicate functionality with juk (~23 megs)
+#-amarok # ~23 megs (mysql-embedded etc.)
-kipi-plugins # ~8 megs + drags in Marble
#-kdeplasma-addons # ~16 megs
#-krusader # ~4 megs
12 years, 1 month
[spin-kickstarts] fedora-livecd-kde.ks: Don't explicitly blacklist kdeedu*.
by Kevin Kofler
commit e2aaa5cc6e9278e3329b1c575672f56996bf20d5
Author: Kevin Kofler <Kevin(a)tigcc.ticalc.org>
Date: Thu Mar 1 02:11:26 2012 +0100
fedora-livecd-kde.ks: Don't explicitly blacklist kdeedu*.
kdeedu is not installed by default in the first place anyway, and if it were,
the kdeedu* wildcard would not match the new split packages anymore.
fedora-livecd-kde.ks | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
---
diff --git a/fedora-livecd-kde.ks b/fedora-livecd-kde.ks
index 72d596f..0b359c9 100644
--- a/fedora-livecd-kde.ks
+++ b/fedora-livecd-kde.ks
@@ -16,7 +16,6 @@
# don't include these for now to fit on a cd
-desktop-backgrounds-basic
-kdeaccessibility*
--kdeedu* # kdeedu is too big for the live images
-scribus # scribus is too big for the live images
-kdeartwork-screensavers # screensavers are not needed on live images
#-ktorrent # kget has also basic torrent features (~3 megs)
12 years, 1 month