1:39 a.m.
Hi,
I have been keep a tab on rpmfusion progress by reading the archives and
it seems the repository is getting reading for launch soon. Congrats
on that.
My primary interest here at the moment is creating a spin based on
rpmfusion and Fedora which Thorsten Leemhuis mentioned as desirable in
one of his earlier mails to this list.
So before I put in some effort, a few questions:
* Is this seen as a worthwhile effort by rpmfusion contributors?
* My primary effort would be around a live cd based on the desktop
live cd from Fedora but I would like to hear your thoughts on other
variants as well.
* What should the package content be? Should both rpmfusion-free and
rpmfusion-nonfree repository installed by default? What are the
important packages you want to see included? Keep in mind that in the
live cd atleast, we would have to drop some existing packages to
accommodate new ones.
* What do you want to call the spin as? My idea was that the spin name
should be different the repository name to avoid confusion and unique
identify what we are talking about easily. Does freefusion sound good?
Any other feedback is welcome as well. Finally, it would also be useful
I can get some hosting space to upload content as we test the spins.
Thanks.
Rahul
5:13 a.m.
Rahul Sundaram wrote:
Hi,
I have been keep a tab on rpmfusion progress by reading the archives and
it seems the repository is getting reading for launch soon. Congrats on
that.
My primary interest here at the moment is creating a spin based on
rpmfusion and Fedora which Thorsten Leemhuis mentioned as desirable in
one of his earlier mails to this list.
So before I put in some effort, a few questions:
* Is this seen as a worthwhile effort by rpmfusion contributors?
Yes!
* My primary effort would be around a live cd based on the desktop
live
cd from Fedora but I would like to hear your thoughts on other variants
as well.
No other idea.
* What should the package content be? Should both rpmfusion-free and
rpmfusion-nonfree repository installed by default? What are the
important packages you want to see included? Keep in mind that in the
live cd atleast, we would have to drop some existing packages to
accommodate new ones.
Only the free repo should be used IMHO. But we could have the non-free one
enabled I guess.
It should atleast have the gstreamer-* packages from rpmfusion added, as
gstreamer-plugins-bad drags in quite some deps, I guess that will need to be
split up a bit.
As well as all the *-freeworld packages for things which are standard in the
livecd, basicly I would like to see it enable playback of all multimedia
formats which we can support using packages from rpmfusion-free.
* What do you want to call the spin as? My idea was that the spin
name
should be different the repository name to avoid confusion and unique
identify what we are talking about easily. Does freefusion sound good?
freefusion sounds good!
Thanks & Regards,
Hans
2:50 p.m.
2008/8/26 Rahul Sundaram <metherid(a)gmail.com>:
Hi,
I have been keep a tab on rpmfusion progress by reading the archives and it
seems the repository is getting reading for launch soon. Congrats on that.
My primary interest here at the moment is creating a spin based on rpmfusion
and Fedora which Thorsten Leemhuis mentioned as desirable in one of his
earlier mails to this list.
I don't know if Thorsten ever mention such
"spin" but having both
rpmfusion and fedora on the same media is a very hard legal issue.
Actually that's even not possible at all without removing the name
Fedora from such spin. (meaning removing artworks and some others
packages i don't remember).
To be more accurate: You can do such spins for yourself (either with
free only or with nonfree packages), but you cannot redistribute the
spin telling it is Fedora. (because it won't be fedora anymore). But
you can (have to ?) tell this work is based (derived?) on Fedora.
Instead we (since we already discuss this some time ago, and Mathias
seems to have answered the same as I will), "decided" to do an
additional media with RPMFusion packages at the release date of each
Fedora version.
This media will be used along with the official Fedora installation
media to provides additional packages for RPMFusion and will be useful
for people that doesn't have a fast internet connexion.
So before I put in some effort, a few questions:
* Is this seen as a worthwhile effort by rpmfusion contributors?
* My primary effort would be around a live cd based on the desktop live cd
from Fedora but I would like to hear your thoughts on other variants as
well.
Not trivial at all because of theses Legal issues.
Would be better to stay at the documentation step and leave end-users
with building their own spins. (not redistributable in anycases as
soon as there is non-fedora packages).
But we can provide a .ks file instead.
* What should the package content be? Should both rpmfusion-free
and
rpmfusion-nonfree repository installed by default? What are the important
packages you want to see included? Keep in mind that in the live cd atleast,
we would have to drop some existing packages to accommodate new ones.
Not desirable
at all.
If we stay at the documentation step, we can tell end-users to only
install it own localization files. This will save around 200Mo from
the official Fedora livecd. Then, end-users will be able to add
whatever they want.
* What do you want to call the spin as? My idea was that the spin
name
should be different the repository name to avoid confusion and unique
identify what we are talking about easily. Does freefusion sound good?
Any other feedback is welcome as well. Finally, it would also be useful I
can get some hosting space to upload content as we test the spins. Thanks.
Having
space dedicated for RPMFusion packagers would be a good thing
(review)... but that's another problem.
Rahul
3:16 p.m.
CC'ing the Fedora Spins SIG mailing list as this concerns most of the
subscribers there as well.
KH KH wrote:
2008/8/26 Rahul Sundaram <metherid(a)gmail.com>:
> Hi,
>
> I have been keep a tab on rpmfusion progress by reading the archives and it
> seems the repository is getting reading for launch soon. Congrats on that.
>
> My primary interest here at the moment is creating a spin based on rpmfusion
> and Fedora which Thorsten Leemhuis mentioned as desirable in one of his
> earlier mails to this list.
I don't know if Thorsten ever mention such "spin" but having both
rpmfusion and fedora on the same media is a very hard legal issue.
Actually that's even not possible at all without removing the name
Fedora from such spin. (meaning removing artworks and some others
packages i don't remember).
FWIW, if RPMFusion wishes to provide and distribute their own version of
Fedora, including whatever packages not in Fedora, either Free or free
or not free at all, right now this is enough:
%packages
# Remove the fedora-logos package and include something without
# Fedora trademarked material
-fedora-logos
generic-logos (or: rpmfusion-logos if you have the artwork)
# Include rpmfusion-release as well
rpmfusion-release
%end
%post
# Substitute the Fedora name in /etc/fedora-release and /etc/issue,
# which are both owned by package fedora-release, so that it doesn't
# pop up in all kinds of weird places such as when booting the machine
# ("Welcome to .... Press I to start interactive ..." comes to mind).
# Note that _all_ trademarks are supposed to be in fedora-logos.
sed -i -e 's/Fedora/RPMFusion/g' /etc/fedora-release /etc/issue
%end
And you're done.
To be more accurate: You can do such spins for yourself (either with
free only or with nonfree packages), but you cannot redistribute the
spin telling it is Fedora. (because it won't be fedora anymore). But
you can (have to ?) tell this work is based (derived?) on Fedora.
This (being able to say "based on Fedora") is pending the new trademark
policy at
https://fedoraproject.org/wiki/User:Pfrields/NewTrademarkGuidelines
I hope this clarifies some of the issues wrt. a RPMFusion spin.
Kind regards,
Jeroen van Meeuwen
-kanarip
3:02 p.m.
On Tue, 2008-08-26 at 17:16 +0200, Jeroen van Meeuwen wrote:
%post
...
sed -i -e 's/Fedora/RPMFusion/g' /etc/fedora-release /etc/issue
%end
It's bad idea because some software uses /etc/fedora-release
or /etc/issue to determine name and version of current distribution (for
example to build kernel modules with specific patches/configuration).
--
Nikolay Ulyanitsky <lystor(a)lystor.org.ua>
3:08 p.m.
On Fri, 12 Sep 2008, Nikolay Ulyanitsky wrote:
It's bad idea because some software uses /etc/fedora-release
or /etc/issue to determine name and version of current distribution (for
example to build kernel modules with specific patches/configuration).
That software is severly broken.
Therefore, there's no need to concern ourselves with such software.
regards,
andreas
3:41 a.m.
KH KH wrote:
I don't know if Thorsten ever mention such "spin" but
having both
rpmfusion and fedora on the same media is a very hard legal issue.
Actually that's even not possible at all without removing the name
Fedora from such spin. (meaning removing artworks and some others
packages i don't remember)
As Jeroen van Meeuwen, this is not a big deal
technically as you make it
out to be. Sure, we have to make some changes but generic-logos makes it
easy to do the rebranding. If there are other issues, we will deal with
them as we come across them. Part of my interest in this effort is as a
test case for the tools and fleshing out new trademark guidelines in
progress for Fedora. We can't use Fedora infrastructure or call the
spin Fedora but that is already well known.
Rahul
4:05 a.m.
On Wed, 2008-08-27 at 09:11 +0530, Rahul Sundaram wrote:
KH KH wrote:
> I don't know if Thorsten ever mention such "spin" but having both
> rpmfusion and fedora on the same media is a very hard legal issue.
> Actually that's even not possible at all without removing the name
> Fedora from such spin. (meaning removing artworks and some others
> packages i don't remember)
As Jeroen van Meeuwen, this is not a big deal technically as you make it
out to be. Sure, we have to make some changes but generic-logos makes it
easy to do the rebranding. If there are other issues, we will deal with
them as we come across them. Part of my interest in this effort is as a
test case for the tools and fleshing out new trademark guidelines in
progress for Fedora. We can't use Fedora infrastructure or call the
spin Fedora but that is already well known.
I can certainly try to help provide some insight into things based on my
own experiences doing a non-Fedora-branded respin... (MythDora 5 being
essentially Fedora 8 + multimedia bits and all, with a Fedora 9 or
10-based version currently in the works).
--jarod
4:24 a.m.
Jarod Wilson wrote:
I can certainly try to help provide some insight into things based on my
own experiences doing a non-Fedora-branded respin... (MythDora 5 being
essentially Fedora 8 + multimedia bits and all, with a Fedora 9 or
10-based version currently in the works).
Great. Is MythDora, a live cd? Is there
any documentation you have
written down on the steps? We can probably share a lot of same content.
Rahul
2:05 p.m.
On Wed, 2008-08-27 at 09:54 +0530, Rahul Sundaram wrote:
Jarod Wilson wrote:
>
> I can certainly try to help provide some insight into things based on my
> own experiences doing a non-Fedora-branded respin... (MythDora 5 being
> essentially Fedora 8 + multimedia bits and all, with a Fedora 9 or
> 10-based version currently in the works).
Great. Is MythDora, a live cd?
Not yet, only installable media. Although we did produce a mostly
functional live CD at one point...
Is there any documentation you have
written down on the steps? We can probably share a lot of same content.
No step-by-step guide written down anywhere, mostly just lingering
evidence of how we did things on the build/spin host and in my skull. :)
--
Jarod Wilson
jarod(a)wilsonet.com
9:41 a.m.
2008/8/27 Rahul Sundaram <metherid(a)gmail.com>:
KH KH wrote:
>
> I don't know if Thorsten ever mention such "spin" but having both
> rpmfusion and fedora on the same media is a very hard legal issue.
> Actually that's even not possible at all without removing the name
> Fedora from such spin. (meaning removing artworks and some others
> packages i don't remember)
As Jeroen van Meeuwen, this is not a big deal technically as you make it out
True.
It is easier than I thought..
At least we can first works at the documentation step providing a .ks
and a "replacement package" for the fedora-logos (outside of the
RPMFusion repository?)
Most of the work will be between .ks and the comps.xml for default
packages installation per group.
I can help with my experience of doing Localized (French) LiveCD.
9:51 a.m.
KH KH wrote:
True. It is easier than I thought..
At least we can first works at the documentation step providing a .ks
and a "replacement package" for the fedora-logos (outside of the
RPMFusion repository?)
You can only build a rpmfusion-logos package after you have
enough
artwork to do the rebranding. Otherwise we have to use generic-logos.
Rahul
9:58 a.m.
Rahul Sundaram schrieb:
> At least we can first works at the documentation step providing a
.ks
> and a "replacement package" for the fedora-logos (outside of the
> RPMFusion repository?)
You can only build a rpmfusion-logos package after you have enough
artwork to do the rebranding. Otherwise we have to use generic-logos.
If necessary I could try and help out with some artwork.
Felix
10:23 a.m.
Felix Kaechele wrote:
If necessary I could try and help out with some artwork
That would be great. Take a
look at
http://fedoraproject.org/wiki/Artwork/ThemingOverview
If you have questions, post in fedora-art list or login to #fedora-art
in freenode.
Rahul
10:28 a.m.
KH KH wrote:
2008/8/27 Rahul Sundaram <metherid(a)gmail.com>:
> KH KH wrote:
>> I don't know if Thorsten ever mention such "spin" but having both
>> rpmfusion and fedora on the same media is a very hard legal issue.
>> Actually that's even not possible at all without removing the name
>> Fedora from such spin. (meaning removing artworks and some others
>> packages i don't remember)
> As Jeroen van Meeuwen, this is not a big deal technically as you make it out
True. It is easier than I thought..
At least we can first works at the documentation step providing a .ks
and a "replacement package" for the fedora-logos (outside of the
RPMFusion repository?)
The Spin SIG is interested in assisting you if you want to, and we in
turn would appreciate your inquiries because of possible precedents
being formed. I'm on this list as well so I'm certainly keeping an eye
on how things are going.
Most of the work will be between .ks and the comps.xml for default
packages installation per group.
The kickstart file or kickstart files I presume has two separate
purposes; one is to create the Live Media with, doing all kinds of
tweaking and configuration to the soon-to-be-live system -besides the
package selection, whereas the other purpose of a kickstart is to select
packages and groups to be included on the Installation Media. FWIW, most
people use separate kickstart files for these two different types of
media (live and installation).
These kickstarts could be distributed and included in the
rpmfusion-release package, which then also gives you a central spot to
maintain the configuration files. If access to the source tree of the
rpmfusion-release package is a problem (because you do not want to give
too many people too much access), maybe GIT submodules can be a solution.
It'll also be interesting to examine how the product can be treated from
the installation procedure (install media) point of view; there's two or
three products right now, each having their own little private
settings/routines for reading repodata from one or more locations, and
default group selection (or "install types", like "Office &
Productivity"). Including a product.img during the compose of the
Installation Media could solve this problem pretty easily, including the
problem of merging comps.xml (and possible conflicts that arise during
the merge). Compose tools very efficiently merge comps files from
different repositories into what ends up to be repodata/comps.xml[.gz],
but obviously that has some requirements to both comps files. Let's not
get into those details right now ;-)
I'm also curious how RPMFusion intends, that is if it even viable, to
compose the "additional media" CD to a genuine Fedora installation media
(set) as well, since this is a first (and afaik the dialog for using
additional media after the initial installation has been removed from
Fedora). This however does not apply to the use case where a genuine
Fedora installation is installed and running and having a .repo file
point to the media from RPMFusion, but solely to the installation
procedure itself.
Kind regards,
Jeroen van Meeuwen
-kanarip
2:03 a.m.
On Tue, 2008-08-26 at 07:09 +0530, Rahul Sundaram wrote:
Hi,
I have been keep a tab on rpmfusion progress by reading the archives and
it seems the repository is getting reading for launch soon. Congrats
on that.
My primary interest here at the moment is creating a spin based on
rpmfusion and Fedora which Thorsten Leemhuis mentioned as desirable in
one of his earlier mails to this list.
So before I put in some effort, a few questions:
* Is this seen as a worthwhile effort by rpmfusion contributors?
Definitely! Lack of media codecs, etc is (as far as I know) the most
common user complaint about Fedora. This would be great and make it
easy newcomers to Linux to get stated with Fedora (minus the Fedora
logos ;) ).
* My primary effort would be around a live cd based on the desktop
live cd from Fedora but I would like to hear your thoughts on other
variants as well.
That sounds fine - I think maybe a DVD spin with all the rpmfusion
packages would be useful as well for offline installs.
This is thinking way ahead, but while we're on the topic of spins do you
think it's fair to say we should respin once every 2-3 months? That
means we could have (roughly) the gold release + 2 respins along the way
per release of Fedora. Until DRPM support gets into the build infra, I
think this would be a good thing to do since another really annoying
thing for users is having to wait 4 hours for a large DVD iso to
download, then after installing they find they need some 150 updates!
* What should the package content be? Should both rpmfusion-free
and
rpmfusion-nonfree repository installed by default? What are the
important packages you want to see included? Keep in mind that in the
live cd atleast, we would have to drop some existing packages to
accommodate new ones.
Just to be on the safe(r?) legal side, maybe we should preinstall
packages from only rpmfusion-free but have the rpmfusion-nonfree repo
enabled.
* What do you want to call the spin as? My idea was that the spin
name
should be different the repository name to avoid confusion and unique
identify what we are talking about easily. Does freefusion sound good?
freefusion sounds good, but I think the name might be a bit misleading
if we enable or preinstall nonfree packages, or users might ask about a
"nonfreefusion" spin.
Any other feedback is welcome as well. Finally, it would also be
useful
I can get some hosting space to upload content as we test the spins.
Thanks.
Rahul
Stewart
2:15 a.m.
Stewart Adam wrote:
That sounds fine - I think maybe a DVD spin with all the rpmfusion
packages would be useful as well for offline installs.
My experience (with xfce, games and other locale specific spins) is
limited to the Live media spins. I haven't looked into Pungi much. If
anyone else wants to help by maintaining a dvd spin, I would appreciate
that.
This is thinking way ahead, but while we're on the topic of spins
do you
think it's fair to say we should respin once every 2-3 months? That
means we could have (roughly) the gold release + 2 respins along the way
per release of Fedora. Until DRPM support gets into the build infra, I
think this would be a good thing to do since another really annoying
thing for users is having to wait 4 hours for a large DVD iso to
download, then after installing they find they need some 150 updates!
Yeah, we should be able to generate images very easily. Testing can be a
problem since updates have before introduced regressions that affect the
way the installation works (or does not for that matter). I hope others
can help with that.
Just to be on the safe(r?) legal side, maybe we should preinstall
packages from only rpmfusion-free but have the rpmfusion-nonfree repo
enabled.
This is what I am going with as of now.
freefusion sounds good, but I think the name might be a bit
misleading
if we enable or preinstall nonfree packages, or users might ask about a
"nonfreefusion" spin.
I looked a while back and realized freefusion.org
is unavailable as
well. Who wants to name the baby?
Rahul
10:33 a.m.
Rahul Sundaram wrote:
Stewart Adam wrote:
>
> That sounds fine - I think maybe a DVD spin with all the rpmfusion
> packages would be useful as well for offline installs.
>
My experience (with xfce, games and other locale specific spins) is
limited to the Live media spins. I haven't looked into Pungi much. If
anyone else wants to help by maintaining a dvd spin, I would appreciate
that.
I have some experience in this area and I can assist in maintaining the
configuration files needed to compose whatever (really, whatever).
FWIW, both pungi and Revisor can be used for creating / respinning spins.
FWIW^2, Red Hat Emerging Technologies' Genome project as well as the
Fedora Unity project use a simple configuration file which is
distributed in a package to users as well, for use with Revisor.
Kind regards,
Jeroen van Meeuwen
-kanarip
5:52 p.m.
On Wed, Aug 27, 2008 at 10:15 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
Stewart Adam wrote:
>
> That sounds fine - I think maybe a DVD spin with all the rpmfusion
> packages would be useful as well for offline installs.
>
My experience (with xfce, games and other locale specific spins) is limited
to the Live media spins. I haven't looked into Pungi much. If anyone else
wants to help by maintaining a dvd spin, I would appreciate that.
>
> This is thinking way ahead, but while we're on the topic of spins do you
> think it's fair to say we should respin once every 2-3 months? That
> means we could have (roughly) the gold release + 2 respins along the way
> per release of Fedora. Until DRPM support gets into the build infra, I
> think this would be a good thing to do since another really annoying
> thing for users is having to wait 4 hours for a large DVD iso to
> download, then after installing they find they need some 150 updates!
Yeah, we should be able to generate images very easily. Testing can be a
problem since updates have before introduced regressions that affect the way
the installation works (or does not for that matter). I hope others can help
with that.
>
> Just to be on the safe(r?) legal side, maybe we should preinstall
> packages from only rpmfusion-free but have the rpmfusion-nonfree repo
> enabled.
>
This is what I am going with as of now.
>
> freefusion sounds good, but I think the name might be a bit misleading
> if we enable or preinstall nonfree packages, or users might ask about a
> "nonfreefusion" spin.
I looked a while back and realized freefusion.org is unavailable as well.
Who wants to name the baby?
Total Fusion. But that sounds a bit unprofessional. Fused Hat?
Though an RPMfusion companion CD with a user-friendly installer is
probably a more appropriate short-term goal
.
--
Michel Salim
http://hircus.jaiku.com/
11:36 p.m.
Michel Salim wrote:
Though an RPMfusion companion CD with a user-friendly installer is
probably a more appropriate short-term goal.
Just curious, how would the genuine Fedora DVD or CD set know about the
extra media during the installation? Of course additional media is
useful *after* the initial installation where people can point a repo to
the media:// url, possibly that .repo file could even be included in the
rpmfusion-release package.
Kind regards,
Jeroen van Meeuwen
-kanarip
11:55 p.m.
On Fri, 29 Aug 2008, Jeroen van Meeuwen wrote:
Just curious, how would the genuine Fedora DVD or CD set know about
the
extra media during the installation? Of course additional media is
useful *after* the initial installation where people can point a repo to
the media:// url, possibly that .repo file could even be included in the
rpmfusion-release package.
It wouldn't, if I'm reading this correctly.
You install your fedora whatever, pop the matching livna cd into the
drive, autostart crap does it's thing and some gtk frontend comes up,
showing a nice little animal saying "It seems you want to install some
additional 3rd party software. Do you want mp3, dvd or divx support? Or do
you want your nvidia card to work?".
If the livna-assistant sounds overblown, a small gtk installer might do
it's thing as well, could even be scripted with the
dialog-de-jour-pour-x11 or whatever it's called today. Timidity or so was
it the last time I looked.
Personally speaking:_WHY_ we'd need such a cd however is beyond me, I
haven't touched a CD or DVD in years. PXE does that to you....
regards,
andreas
12:49 a.m.
Andreas Thienemann wrote:
On Fri, 29 Aug 2008, Jeroen van Meeuwen wrote:
> Just curious, how would the genuine Fedora DVD or CD set know about the
> extra media during the installation? Of course additional media is
> useful *after* the initial installation where people can point a repo to
> the media:// url, possibly that .repo file could even be included in the
> rpmfusion-release package.
It wouldn't, if I'm reading this correctly.
You're right, I'm unable to think of a way that would currently work. It
could be done, but it'd reintroduce the "Do you want to use any
additional media (...)" dialog in anaconda and would only appear *after*
the initial installation is done already.
You install your fedora whatever, pop the matching livna cd into the
drive, autostart crap does it's thing and some gtk frontend comes up,
showing a nice little animal saying "It seems you want to install some
additional 3rd party software. Do you want mp3, dvd or divx support? Or do
you want your nvidia card to work?".
Instead, I'd just recreate the Fedora released media to include the
RPMFusion Free/Non-Free additional repositories (with a product.img) and
be done with it (of course, rebrand the lot).
If the livna-assistant sounds overblown, a small gtk installer might
do
it's thing as well, could even be scripted with the
dialog-de-jour-pour-x11 or whatever it's called today. Timidity or so was
it the last time I looked.
Really, if a GUI is going to pop up on inserting some media with
software, PackageKit should be the one taking it on.
Personally speaking:_WHY_ we'd need such a cd however is beyond
me, I
haven't touched a CD or DVD in years. PXE does that to you....
It's a good thing everyone has PXE at home these days ;-)
Kind regards,
Jeroen van Meeuwen
-kanarip
1:15 a.m.
On 08/29/2008 03:49 AM, Jeroen van Meeuwen wrote:
Andreas Thienemann wrote:
> On Fri, 29 Aug 2008, Jeroen van Meeuwen wrote:
>
>> Just curious, how would the genuine Fedora DVD or CD set know about
>> the extra media during the installation? Of course additional media
>> is useful *after* the initial installation where people can point a
>> repo to the media:// url, possibly that .repo file could even be
>> included in the rpmfusion-release package.
>
> It wouldn't, if I'm reading this correctly.
>
You're right, I'm unable to think of a way that would currently work.
It could be done, but it'd reintroduce the "Do you want to use any
additional media (...)" dialog in anaconda and would only appear
*after* the initial installation is done already.
> You install your fedora whatever, pop the matching livna cd into the
> drive, autostart crap does it's thing and some gtk frontend comes up,
> showing a nice little animal saying "It seems you want to install
> some additional 3rd party software. Do you want mp3, dvd or divx
> support? Or do you want your nvidia card to work?".
>
Instead, I'd just recreate the Fedora released media to include the
RPMFusion Free/Non-Free additional repositories (with a product.img)
and be done with it (of course, rebrand the lot).
> If the livna-assistant sounds overblown, a small gtk installer might
> do it's thing as well, could even be scripted with the
> dialog-de-jour-pour-x11 or whatever it's called today. Timidity or so
> was it the last time I looked.
>
Really, if a GUI is going to pop up on inserting some media with
software, PackageKit should be the one taking it on.
> Personally speaking:_WHY_ we'd need such a cd however is beyond me, I
> haven't touched a CD or DVD in years. PXE does that to you....
>
It's a good thing everyone has PXE at home these days ;-)
Yup. Especially for
those who make use of
http://fedoraproject.org/wiki/Distribution/FreeMedia
1:17 a.m.
On Fri, 29 Aug 2008, Jeroen van Meeuwen wrote:
You're right, I'm unable to think of a way that would
currently work. It
could be done, but it'd reintroduce the "Do you want to use any
additional media (...)" dialog in anaconda and would only appear *after*
the initial installation is done already.
Exactly. Furthermore, it's questionable if we'd ever get this code into
upstream anaconda.
[The rpmfusion assistant... ]
Instead, I'd just recreate the Fedora released media to include
the
RPMFusion Free/Non-Free additional repositories (with a product.img) and
be done with it (of course, rebrand the lot).
More pain, less gain. This sounds as if you're just rolling a spin with a
changed fedora-artworks package and a rpmfusion-release rpm added into the
mix.
I'm a bit concerned that this will result in a lot of technically
illiterate users installung "our fedora" because "it just
works!!!111!!"
and then come crying back to usthat it doesn't look like fedora, that we
broke something or whatever else they can come up with.
In the end we either ignore this resulting in a lot of frustration vented
on digg or ./. Or alternatively, we spent lots of our limited time helping
these guys.
So I'd personally prefer to just offer an add-on disk and be done with it.
But on the other hand... Talk is cheap. If you wanna run with it, hey,
knock yourself out. :-)
Really, if a GUI is going to pop up on inserting some media with
software, PackageKit should be the one taking it on.
Ohhh right, the .*Kit madness. Does PackageKit works nowadays? I installed
F9 on my workstation some time ago and found the only way to get it to
work was to configure both PackageKit and NetworkManagerKit with "rpm -e
--with-prejudice=extreme". Then my problems went away. :-)
I'm not to fond of this Kit stuff... But that's just me going off on a
rant... I'm sure these tools work just splendid for everyone else.
> Personally speaking:_WHY_ we'd need such a cd however is
beyond me, I
> haven't touched a CD or DVD in years. PXE does that to you....
It's a good thing everyone has PXE at home these days ;-)
Hey, don't knock it. The time setting up a PXE server at home (takes what?
15min for the uninitiated?) is well spent...
regards,
andreas
1:39 a.m.
Andreas Thienemann wrote:
I'm a bit concerned that this will result in a lot of technically
illiterate users installung "our fedora" because "it just
works!!!111!!"
and then come crying back to usthat it doesn't look like fedora, that we
broke something or whatever else they can come up with.
In the end we either ignore this resulting in a lot of frustration vented
on digg or ./. Or alternatively, we spent lots of our limited time helping
these guys.
The artwork for the most part is going to be the same if we use
generic-logos. Rest of the packages from Fedora are not modified and
will work exactly the same. You only would have to deal with bugs from
RPMFusion specific packages which you would have to do anyway.
Ohhh right, the .*Kit madness. Does PackageKit works nowadays?
Yes, it does and it is getting adopted by others like Opensuse,
Mandriva, Ubuntu etc. If you have a actual problem, file a bug report.
Hey, don't knock it. The time setting up a PXE server at home (takes what?
15min for the uninitiated?) is well spent...
Not everybody has network access and
spare systems. The audience for
live cd's are entirely different from the end users who have the
knowledge, inclination and infrastructure to setup pxeboot servers.
Rahul
4:30 a.m.
Ralf Corsepius wrote:
Define "works".
Works for me and I am using it on a regular basis for the usual tasks. I
have bugs filed for some instances where it does not.
So far, I am having a lot of problems with PackageKit as well as
NetworkManager, ...
Make sure you have the latest updates and file bug reports otherwise.
Rahul
4:38 a.m.
On Fri, 2008-08-29 at 10:00 +0530, Rahul Sundaram wrote:
Ralf Corsepius wrote:
> Define "works".
>
Works for me and I am using it on a regular basis for the usual tasks.
Single user
desktop, I suppose?
I
have bugs filed for some instances where it does not.
I have removed them - Too
immature, too little usefulness.
> So far, I am having a lot of problems with PackageKit as well
as
> NetworkManager, ...
>
Make sure you have the latest updates and file bug reports otherwise.
I am using
vanilla FC9.
4:51 a.m.
Ralf Corsepius wrote:
On Fri, 2008-08-29 at 10:00 +0530, Rahul Sundaram wrote:
> Ralf Corsepius wrote:
>
>> Define "works".
>>
>>
> Works for me and I am using it on a regular basis for the usual tasks.
>
Single user desktop, I suppose?
Yes and otherwise as well.
> Make sure you have the latest updates and file bug reports
otherwise.
>
I am using vanilla FC9
Without the updates? There was a number of issues fixed in the later
updates. Anyway, if you aren't running it at all, no point discussing it.
Rahul
5:34 a.m.
On Fri, 2008-08-29 at 10:21 +0530, Rahul Sundaram wrote:
Ralf Corsepius wrote:
> On Fri, 2008-08-29 at 10:00 +0530, Rahul Sundaram wrote:
>
>> Ralf Corsepius wrote:
>> Make sure you have the latest updates and file bug reports
otherwise.
>>
> I am using vanilla FC9
>
Without the updates?
Updated, until RH decided to close down the repos and to
expose FC user
to the vulnerabilities of such kind of setup contains.
There was a number of issues fixed in the later
updates. Anyway, if you aren't running it at all, no point discussing it.
Like
most recent new developments (NM, PA, PK, SELinux) in Fedora these
tool all lack a concept of "multi-user capability", "user roles" and
networked setups - If they have them (e.g. PA) then they are well
hidden :/
Things like gnome applets "molesting" "ordinary users" with
"SELinux
alerts", "Update alerts" or NM showing up on machines with static
wireless setups, to me, simply are fundamental design flaws,
disqualifying these applications, to me.
10:04 a.m.
Rahul,
On Fri, 29 Aug 2008, Rahul Sundaram wrote:
We're getting rapidly off-topic here, but I'll state my general opinion of
the current state and attitude of fedora and most likely not contribute to
this OT thread any further. Let's hope I won't pull a Bryan Smith having
to reply to myself. :-)
>>> Define "works".
>> Works for me and I am using it on a regular basis for the usual tasks.
> Single user desktop, I suppose?
Yes and otherwise as well.
Something "working" only for single user desktops is considered broken.
It is a complete surprise to me how this focus on single-desktop to the
detriment of multi-user machines slipped into our distribution.
>> Make sure you have the latest updates and file bug reports
otherwise.
Uhhh. No. Sorry. I've grown older since I started using Linux ages ago.
I'm already having too little time to do all the things I'd like to do,
there's no way I'm going to file bugs for .*Kit programs anymore. It's
just not worth it. I'm not any longer wasting time to file bugs against
non-working, ill-designed software which was slipped into the distribution
replacing a perfectly working, universal system with something bolted onto
the system as a GTK-frontend needing X11 to even start up supporting only
a subset of the earlier available features.
I've seen it too often lately that bugs referring to features which were
previously working and after the inclusion of one of the .*Kit tools
suddenly broke beeing closed. While I just get a fuzzy feeling over
the WONTFIX tag being applied to such bugs together with the explanation
"You don't need this feature" I have an equally sweet spot for the
increasingly common "Yes, we know this. Will be fixed in one of the next
releases".
WTF? You're knowingly breaking stuff which worked before in order to push
your half-baked "solution"?
Nice example: Bridging? Who would ever need this. Or why the hell would we
_EVER_ need networking before logging in a user under gdm.
WHO THE FUCK is replacing working stuff with broken crap in our
distribution?
Have we really reached the point where we need something like our RHEL
product management to veto software inclusion which breaks existing stuff?
Regression is a serious problem in RHEL but it seems that fedora happily
charges ahead and pisses of it's experienced users expecting more then the
ubuntu experience from their systems.
> I am using vanilla FC9
Without the updates? There was a number of issues fixed in the later
updates. Anyway, if you aren't running it at all, no point discussing it.
See above, why are updates needed to restore previously working
functionality? Something in our development process seems to be severly
broken. I've been working with computers for a long time now and I
unquestionally accept the need for updates. Hell, my own tools need
updates as well.
But shoving broken cruft down our users throats should not be the fedora
experience we strive for.
PackageKit, NetworkManager, PulseAudio, ConsoleKit, DeviceKit,
gnome-power-manager are all perfect illustrations for my cases above. It
seems camel case and the Kit monicer are increasingly serving as warning
signs to stay away. Why is that? And is that the state we want things to
be?
Go talk to some of our own base os developers. There's lots and lots of
love for our desktop team going round... If this rant should be over the
top, sorry, I've been hanging out the last year with these guys... It was
an eye-opening experience about the sorry state of our desktop stack and
by extension our future direction.
regards,
andreas
I think I should put this up as a blog post for better circulation... /me
goes to ponder...
2:19 p.m.
On Fri, 29 Aug 2008, Ralf Corsepius wrote:
On Fri, 2008-08-29 at 07:09 +0530, Rahul Sundaram wrote:
> Andreas Thienemann wrote:
>> Ohhh right, the .*Kit madness. Does PackageKit works nowadays?
> Yes, it does
Define "works".
So far, I am having a lot of problems with PackageKit as well as
NetworkManager, ...
Maybe we should stop making mixed-case named tools ?
--
-- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
4 p.m.
On Fri, Aug 29, 2008 at 10:19 AM, Dag Wieers <dag(a)wieers.com> wrote:
On Fri, 29 Aug 2008, Ralf Corsepius wrote:
> On Fri, 2008-08-29 at 07:09 +0530, Rahul Sundaram wrote:
>>
>> Andreas Thienemann wrote:
>
>>> Ohhh right, the .*Kit madness. Does PackageKit works nowadays?
>>
>> Yes, it does
>
> Define "works".
>
> So far, I am having a lot of problems with PackageKit as well as
> NetworkManager, ...
Maybe we should stop making mixed-case named tools ?
The naming (branding) of the tools does not matter so much;
NetworkManager is network-manager on Debian/Ubuntu. If the packages
are installed by default anyway, normal users won't notice.
--
Michel Salim
http://hircus.jaiku.com/
4:05 p.m.
On Fri, 29 Aug 2008, Michel Salim wrote:
On Fri, Aug 29, 2008 at 10:19 AM, Dag Wieers <dag(a)wieers.com>
wrote:
> On Fri, 29 Aug 2008, Ralf Corsepius wrote:
>> On Fri, 2008-08-29 at 07:09 +0530, Rahul Sundaram wrote:
>>> Andreas Thienemann wrote:
>>
>>>> Ohhh right, the .*Kit madness. Does PackageKit works nowadays?
>>>
>>> Yes, it does
>>
>> Define "works".
>>
>> So far, I am having a lot of problems with PackageKit as well as
>> NetworkManager, ...
>
> Maybe we should stop making mixed-case named tools ?
>
The naming (branding) of the tools does not matter so much;
NetworkManager is network-manager on Debian/Ubuntu. If the packages
are installed by default anyway, normal users won't notice.
Welcome to sarcasm, please read between the lines :)
--
-- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
2:15 p.m.
Andreas Thienemann wrote:
On Fri, 29 Aug 2008, Jeroen van Meeuwen wrote:
> You're right, I'm unable to think of a way that would currently work. It
> could be done, but it'd reintroduce the "Do you want to use any
> additional media (...)" dialog in anaconda and would only appear *after*
> the initial installation is done already.
Exactly. Furthermore, it's questionable if we'd ever get this code into
upstream anaconda.
I think that if this is the absolute best way to provide an add-on
product to genuine Fedora, for use during the installation procedure,
there's a solid case to make for getting the code in.
[The rpmfusion assistant... ]
> Instead, I'd just recreate the Fedora released media to include the
> RPMFusion Free/Non-Free additional repositories (with a product.img) and
> be done with it (of course, rebrand the lot).
More pain, less gain. This sounds as if you're just rolling a spin with a
changed fedora-artworks package and a rpmfusion-release rpm added into the
mix.
Point taken, and you're right; it would just be a spin without
fedora-logos and with a rpmfusion-release package (and a product.img).
But it's an alternative to consider ;-)
I'm a bit concerned that this will result in a lot of technically
illiterate users installung "our fedora" because "it just
works!!!111!!"
and then come crying back to usthat it doesn't look like fedora, that we
broke something or whatever else they can come up with.
In the end we either ignore this resulting in a lot of frustration vented
on digg or ./. Or alternatively, we spent lots of our limited time helping
these guys.
Well, in the end, even if you do a show-case live spin, which people
will be able to install from, unless you disable that feature, you are
going to attract users that seek support for their running systems that
are, at that point, not running Fedora.
So I'd personally prefer to just offer an add-on disk and be done
with it.
Which I guess is the big other alternative (to distributing the
packages, that is) ;-)
But on the other hand... Talk is cheap. If you wanna run with it,
hey,
knock yourself out. :-)
> Really, if a GUI is going to pop up on inserting some media with
> software, PackageKit should be the one taking it on.
Ohhh right, the .*Kit madness. Does PackageKit works nowadays?
If it doesn't, have you logged a bug? ;-)
I installed
F9 on my workstation some time ago and found the only way to get it
to
work was to configure both PackageKit and NetworkManagerKit with "rpm -e
--with-prejudice=extreme". Then my problems went away. :-)
I'm not to fond of this Kit stuff... But that's just me going off on a
rant... I'm sure these tools work just splendid for everyone else.
This (handling the add-on CD) just seems right up their sleeve, that's all.
>> Personally speaking:_WHY_ we'd need such a cd however is
beyond me, I
>> haven't touched a CD or DVD in years. PXE does that to you....
> It's a good thing everyone has PXE at home these days ;-)
Hey, don't knock it. The time setting up a PXE server at home (takes what?
15min for the uninitiated?) is well spent...
True, assuming you have at least two PCs. Kinda moot point wrt. the
original topic in this thread anyway, don't you think?
Kind regards,
Jeroen van Meeuwen
-kanarip
5914
days inactive
5931
days old
rpmfusion-developers@lists.rpmfusion.org
34 comments
13 participants
participants (13)
-
Andreas Thienemann -
Dag Wieers -
Felix Kaechele -
Hans de Goede -
Jarod Wilson -
Jeroen van Meeuwen -
manuel "lonely wolf" wolfshant -
Michel Salim -
Nicolas Chauvet -
Nikolay Ulyanitsky -
Rahul Sundaram -
Ralf Corsepius -
Stewart Adam