My exit from the house that belongs to RPMfusion. Likely will be censored by RPMf.
by Kelsie Flynn
Over the past year I've been working with both external major build RPM
systems to build RPMS for the projects I've been working on.
If posts appears incomplete, it was probably edited by the upstream admin.
Previously, I've had some (naive) idea's of bridging the two repo's to some
extent.
However, that idea was soley mine and did not receive support from where it
needed to be. I also recently had ambitions to move off of el6 completely
and jump on the bandwagon to see if it was a smooth ride. That was also
overly idealistic and naive of me to think.
Given this.
I now no longer ride this fence and try to please both parties. I now will
focus on
ATrpms compatible packages only.
If posts appears incomplete, it was probably edited by the upstream admin.
What does this mean technically?
It means I will not be using any Source RPMS they have been built at
RPMfusion.
I will still build missing packages that are not in ATrpms from EPEL or
upstream.
It means the ffmpeg and other similar "moving target" packages that Axel
and the international community chooses will be matched to all projects
ELmythOS project uses.
It means RedHat EL6 based systems will still be supported to run additional
Qt 4.7/4.8 along side the builtin qt-4.6.2 in el6 proper.
It means I don't have to "reshape a wheel" too often and the result could
be a more robust system.
If your more conservative than the most and prefer to use older versions
for stability over NEW functionality, look no further. Use el6 and
mythtv-0.25.x.
If you want to play in the devel sandbox with the latest toys and look
really cool doing so, you should be on the latest releases of everything.
Regarding that, el7 is where the NEW fuctionality will be so if you want to
play in the mythtv, qt sandbox, use el7 and repos.
If posts appears incomplete, it was probably edited by the upstream admin.
***Everyone understands devs want everyone to use their latest work, that
they can be proud of.
So I do not attempt to insult their innovation, but instead will offer
alternatives
of their older work, that I deem still relevently funtional.
I make my own decisions based on my experiences:
as an End User,
then as a Computer Technician,
then as a former Technical Support worker,
then as Linux Systems Admin
and now as an aspiring Systems Builder, packager and developer.
If posts appears incomplete, it was probably edited by the upstream admin.
Note:
I do not call myself an Engineer because I'm finishing my education still
and it would an insult to repected Engineers to do so. I've learned
everything I know with GED as my current HIGHEST EDUCATION.
If I ever call myself an Engineer , you can bet your $T#$ I will back it up
with a Eng.Degree in Mathematics. For now I'm just a passionate volunteer
Gnobody systems builder with many opinions and high expectations.
I know enough about C/C++ Software development right to be objective, as my
skills improve I will make patches as needed from upstream. This should
help the project stay updated with security updates.
I'm not running a popularity contest. Plenty do that already and miss the
details I'm passionate about.
If posts appears incomplete, it was probably edited by the upstream admin.
10 years, 4 months
MythTV 0.27.3 ???
by Dave Ulrick
A few weeks ago, MythTV 0.27.3 was released upstream. Are there any plans
for the RPM Fusion RPMs to be upgraded to this release? The current RPMs
are from 0.27.1.
Thanks,
Dave
--
Dave Ulrick
Email: d-ulrick(a)comcast.net
10 years, 4 months
In Like Flynn - ? Out Like Flynn ?
by Bob Lightfoot
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/15/2014 06:00 AM, rpmfusion-users-request(a)lists.rpmfusion.org wrote:
> Send rpmfusion-users mailing list submissions to
> rpmfusion-users(a)lists.rpmfusion.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-users or, via
> email, send a message with subject or body 'help' to
> rpmfusion-users-request(a)lists.rpmfusion.org
>
> You can reach the person managing the list at
> rpmfusion-users-owner(a)lists.rpmfusion.org
>
> When replying, please edit your Subject line so it is more
> specific than "Re: Contents of rpmfusion-users digest..."
>
>
> Today's Topics:
>
> 1. My exit from the house that belongs to RPMfusion. Likely will be
> censored by RPMf. (Kelsie Flynn)
>
>
> ----------------------------------------------------------------------
>
> Message: 1 Date: Thu, 14 Aug 2014 10:35:53 -0700 From: Kelsie
> Flynn <kelsiegflynn(a)gmail.com> To:
> rpmfusion-users(a)lists.rpmfusion.org Subject: My exit from the house
> that belongs to RPMfusion. Likely will be censored by RPMf.
> Message-ID:
> <CAAk+JN_bXzzx7T8tKrWK609MqfDzr21NthLWSXaCtsMk6rkRjQ(a)mail.gmail.com>
>
>
Content-Type: text/plain; charset="utf-8"
>
> Over the past year I've been working with both external major build
> RPM systems to build RPMS for the projects I've been working on.
>
> If posts appears incomplete, it was probably edited by the upstream
> admin.
>
> Previously, I've had some (naive) idea's of bridging the two repo's
> to some extent. However, that idea was soley mine and did not
> receive support from where it needed to be. I also recently had
> ambitions to move off of el6 completely and jump on the bandwagon
> to see if it was a smooth ride. That was also overly idealistic and
> naive of me to think.
>
> Given this. I now no longer ride this fence and try to please both
> parties. I now will focus on ATrpms compatible packages only.
>
> If posts appears incomplete, it was probably edited by the upstream
> admin.
>
> What does this mean technically?
>
> It means I will not be using any Source RPMS they have been built
> at RPMfusion. I will still build missing packages that are not in
> ATrpms from EPEL or upstream.
>
> It means the ffmpeg and other similar "moving target" packages that
> Axel and the international community chooses will be matched to all
> projects ELmythOS project uses.
>
> It means RedHat EL6 based systems will still be supported to run
> additional Qt 4.7/4.8 along side the builtin qt-4.6.2 in el6
> proper.
>
> It means I don't have to "reshape a wheel" too often and the result
> could be a more robust system.
>
> If your more conservative than the most and prefer to use older
> versions for stability over NEW functionality, look no further. Use
> el6 and mythtv-0.25.x.
>
> If you want to play in the devel sandbox with the latest toys and
> look really cool doing so, you should be on the latest releases of
> everything. Regarding that, el7 is where the NEW fuctionality will
> be so if you want to play in the mythtv, qt sandbox, use el7 and
> repos.
>
> If posts appears incomplete, it was probably edited by the upstream
> admin.
>
> ***Everyone understands devs want everyone to use their latest
> work, that they can be proud of. So I do not attempt to insult
> their innovation, but instead will offer alternatives of their
> older work, that I deem still relevently funtional.
>
> I make my own decisions based on my experiences: as an End User,
> then as a Computer Technician, then as a former Technical Support
> worker, then as Linux Systems Admin and now as an aspiring Systems
> Builder, packager and developer.
>
> If posts appears incomplete, it was probably edited by the upstream
> admin.
>
> Note: I do not call myself an Engineer because I'm finishing my
> education still and it would an insult to repected Engineers to do
> so. I've learned everything I know with GED as my current HIGHEST
> EDUCATION. If I ever call myself an Engineer , you can bet your
> $T#$ I will back it up with a Eng.Degree in Mathematics. For now
> I'm just a passionate volunteer Gnobody systems builder with many
> opinions and high expectations.
>
> I know enough about C/C++ Software development right to be
> objective, as my skills improve I will make patches as needed from
> upstream. This should help the project stay updated with security
> updates.
>
> I'm not running a popularity contest. Plenty do that already and
> miss the details I'm passionate about.
>
> If posts appears incomplete, it was probably edited by the upstream
> admin. -------------- next part -------------- An HTML attachment
> was scrubbed... URL:
> <https://lists.rpmfusion.org/pipermail/rpmfusion-users/attachments/2014081...>
>
> ------------------------------
>
> _______________________________________________ rpmfusion-users
> mailing list rpmfusion-users(a)lists.rpmfusion.org
> http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-users
>
> End of rpmfusion-users Digest, Vol 616, Issue 1
> ***********************************************
>
Not sure what packages you maintained for RPMFusion Kelsie, but I
hope you have better luck at ATRpms than I have of late. The last
ATRPMs Mailing list digest came out 7 days ago 8-8-14 and they have
not released thru the repos and Mythtv 0.26 or 0.27 update in several
months. RPMFusion may be slow moving to support el7, but their fedora
work marches forward and I am still hoping that el7 support will
flourish. Best of luck.
Bob
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJT7fe5AAoJEKqgpLIhfz3XV8oH/20yZ27ypjEQy3BtmwpYGn8R
cxTUVUHt9GPFCePxLr9Sr5fusYya5vQG6XzuLU/oFvbRiXf+e5fJbERuXajMuYDW
oUDH1Y+k/drAE8YkVqvAOtMuNvoFuaAFgqicERnTwF5xW94dlaoFvs+R4sqJYwmw
zCccLpaZSwR0XbBBxaBP8RckbMvT/mPNRGktuIoCNqSG5opEpjG5wAYwwzcB6Jlf
zpjrnIlQqhT6VYHkJltr6bHDaO6ZUCEd31x3C36dKymob2L76Cmdd2SapmVU+DEq
SXg2rdYiBNli1JpL43nNxF29zFNf8aD14Jc9ntgBzXsWJskAcVulr5ai1T+duEw=
=OqeJ
-----END PGP SIGNATURE-----
10 years, 4 months
MythTV 0.27.3 ???
by Kelsie Flynn
Regardless of the measure you compare me to Richard, yes I failed your
expectations of communication with you.
I tried very hard even though it's probably hard for you to tell.
If you would like to talk privately let's do and work towards a common
goal. I will give you the up most respect and try to explain anything I've
said if you wish.
By phone preferred, with direct email or chat there is a very high
probability of failure.... because of my limitations, not yours. Email
tone and effectiveness is a failure of mine that I openly admit in certain
circumstances such as this.
I'll email your private email with my cell phone number and hope for the
best.
I don't want this to go on for days and days and possibly have you get
more bitter at me.... because of my Cowboy/JohnWayne nature.
I know I'm no Saint or Wordsmith.
Please give me the chance again directly and then ...perhaps I can appeal
to your intellect. I'm frustrated by problems as most problem solvers are
and I am seeking out other capable people to work with on common projects.
From what I read, you were the person I needed to contact at RPMf, not J
or C.
Kelsie
------------------------------
On Wed, Aug 13, 2014 at 3:20 PM, Kelsie Flynn <kelsiegflynn at
gmail.com <http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-users>>
wrote:
>* Regarding
*>>* https://lists.rpmfusion.org/pipermail/rpmfusion-users/2014-August/000429....
<https://lists.rpmfusion.org/pipermail/rpmfusion-users/2014-August/000429....>
*>>* [SNIP]
*>>>* Richard,
*>>* While what you said is not "incorrect". I want to add some things. My
*>* opinions are directed towards RPMfusion and all members with decision
*>* making power
*>* for building packages, not just you.
*>
Thanks for casting a wide net and including me...
>>* My uncle Doodle used to say:
*>>* "Opinions are like *ss#holes, Everybody has one!".
*>>* Like it or not.
*>* I don't come out from behind my rock too much.
*>* But when I do, I have some things to say and this is my opinion!
*>>>* *>That's currently not possible because the version of QT in
RHEL is too old and the version in EPEL (QT5) is too new.*
*>>>>* **Don't use qt5 with EL6. It's not binary compatible directly
with el6's qt4-6.2 but qt4-4.8.X is. Someone told you wrong to try
it.*
*>>No one suggested I try it, it was just a statement. Both versions are
available and neither work.
>* **Use this repo instead. Created by SIC from Fedora # This was built isolated in /opt, I have rebuilt it against 4.8.5 with Axels' reference system for qt47.*
*>>>* *https://repos.fedorapeople.org/repos/sic/qt48/epel-qt48.repo
<https://repos.fedorapeople.org/repos/sic/qt48/epel-qt48.repo>
<https://repos.fedorapeople.org/repos/sic/qt48/epel-qt48.repo
<https://repos.fedorapeople.org/repos/sic/qt48/epel-qt48.repo>>*
*>>
>* *You have to force it(unless you rebuilt it) because mythtv packages from Axel and RPMf are built against the qt*-* and not qt48-qt-*.*
*>>>* *My qt48-4.8.5 spec/build that I upgraded from (sics) previous
great work on this subject will be turned over to Axel with a matter
of days. And then it will *
*>>If someone wants to develop a parallel installable package that's compliant
with the guidelines (i.e., not installing into /opt) then I would welcome
it. I don't personally have the time to do that with what little time I'm
left with after work and home life.
>* *Back on point:*
*>>>>* *>Since RPM Fusion has a policy not to replace currently
shipping packages we're at an impasse!
*>>* *
*>>>>>* *RPMfusion already has other qt4's in the RPMfusion repo
Richard. As you know, they just don't work(very well), even though
they sit there...like they might.Fact is:Axels 4.7 worked. Up to the
change upstream in mythtv.*
*>>What qt'4 are you talking about? RPM Fusion AFAIK does not provide ANY qt4
packages, 4.6 is in RHEL and 5 is in Fedora EPEL...
>* *>Since RPM Fusion has a policy not to replace currently shipping packages we're at an impasse.*
*>>>>>* *I'm sorry again Richard. ....No direct disrespect intended as
I like you and all the peps at RPMfusion and Axels group. Even though
I only know you by reading posts/notes from your work!*
*>>Indirect disrespect then? I understand your point of view on the policy and
I'm frustrated by it a bit as well, bug I only maintain the package at RPM
Fusion. I have no leadership position there whatsoever.
>* In all fairness,
*>>* *This is by choice or technical decision based solely on the
decision making processes' of the past and is now technically a MOOT
point.*
*>>I don't think it was ever a technical issue to begin with but a policy
choice, and I don't see RPM Fusion shipping packages that install into /opt
anytime soon.
>* *I'm not religious, but here's My philosophy, Regarding the ongoing pissing contest between RPMf and ATrpms.*
*>>Is it ongoing? The result may be unfortunate but I think it's pretty well
settled. Personally, I have learned some of the history but I was not a
packager (for Fedora or RPM Fusion) at the time it happened.
Ok, snipping the rest of the message as it's not technically relevant to
this thread. If you want to have a philosophical discussion about the
history of ATrpms and RPM Fusion and your problems with RPM Fusions
policies, feel free to do so, but please don't hijack this thread to do it.
Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.rpmfusion.org/pipermail/rpmfusion-users/attachments/2014081...>
10 years, 4 months
re:MythTV 0.27.3 ???
by Kelsie Flynn
Regarding
https://lists.rpmfusion.org/pipermail/rpmfusion-users/2014-August/000429....
On 2014-08-01 07:03, Richard Shaw wrote:
>* On Thu, Jul 31, 2014 at 1:45 PM, Brady, Mike <mike.brady at devnull.net.nz <http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-users>> wrote:
*> >>* Are there any plans for Centos/RHEL 6/7 0.27.x packages?
*> >
* That's currently not possible because the version of QT in RHEL is
too old and the version in EPEL (QT5) is too new. **Since RPM Fusion
has a policy not to replace currently shipping packages we're at an
impasse.
*> >* Once RPM Fusion branches for EPEL 7 I plan to support the
package there though.
*> >* Thanks,
*>* Richard
*
Thanks Richard. I suspected that that may have been the case. My plan
for my next build was to go with Centos 7 anyway so that works for me.
Richard,
While what you said is not "incorrect". I want to add some things. My
opinions are directed towards RPMfusion and all members with decision
making power
for building packages, not just you.
My uncle Doodle used to say:
"Opinions are like *ss#holes, Everybody has one!".
Like it or not.
I don't come out from behind my rock too much.
But when I do, I have some things to say and this is my opinion!
*>That's currently not possible because the version of QT in RHEL is
too old and the version in EPEL (QT5) is too new.*
**Don't use qt5 with EL6. It's not binary compatible directly with
el6's qt4-6.2 but qt4-4.8.X is. Someone told you wrong to try it.
*
**Use this repo instead. Created by SIC from Fedora # This was built
isolated in /opt, I have rebuilt it against 4.8.5 with Axels'
reference system for
qt47.https://repos.fedorapeople.org/repos/sic/qt48/epel-qt48.repo
<https://repos.fedorapeople.org/repos/sic/qt48/epel-qt48.repo>
*
*You have to force it(unless you rebuilt it) because mythtv packages
from Axel and RPMf are built against the qt*-* and not qt48-qt-*.*
*My qt48-4.8.5 spec/build that I upgraded from (sics) previous great
work on this subject will be turned over to Axel with a matter of
days. And then it will
*
*start populating the el6 repos as things always have. Axel's
obviously busy or he'd had make this work already and we wouldn't be
discussing it.*
*It's my opinion that Axel was ok with having a couple small rpm
issues in qt47(which is why it was in atrpms-testing)
I'm sure Axel probably expected the Open Source Community and peers
like us to fix that and contribute and not just try and fix it and NOT
contribute, and then complain.*
*Axels "vacations" to me ...have proven that we need him around to
keep the flow moving.
*
*I'm no Axel, but I am one of his biggest fans.*
*Back on point:*
*>Since RPM Fusion has a policy not to replace currently shipping
packages we're at an impasse!
*
*RPMfusion already has other qt4's in the RPMfusion repo Richard. As
you know, they just don't work(very well), even though they sit
there...like they might.Fact is:Axels 4.7 worked. Up to the change
upstream in mythtv.
It just needed a few minor things addressed, which has been done.
This and Sics work are the basis for a now working qt48 kit on el6.
Without any openGL or Webkit or slow mythweb related issues.*
*>Since RPM Fusion has a policy not to replace currently shipping
packages we're at an impasse.I'm sorry again Richard. ....No direct
disrespect intended as I like you and all the peps at RPMfusion and
Axels group. Even though I only know you by reading posts/notes from
your work!
*
In all fairness,
*This is by choice or technical decision based solely on the decision
making processes' of the past and is now technically a MOOT point.*
*If any of you don't believe me or you or anyone at RPMf want to engage.
Email me. I will not debate these facts and my personal opinions no
more than this on this point here.*
*Lets fix what needs to be fixed as FSF loving people and drop the
non-relevant explanations from the past.
I'm not religious, but here's My philosophy, Regarding the ongoing
pissing contest between RPMf and ATrpms.*
*It's not helping either or both sides.*
*Consider this:
I got a big ego and I think highly of myself ...but **Stubbornness and
Rigidity is my default nature! *
*I'm faulty. I have made mistakes. I'm not perfect. I have done things
I'm not proud of. I have even bullied and been bullied.
*
*I value intelligence though I am sometimes inconsistent and
contradictory. I value respect, even though I have disrespected many.*
*These things do not make, nor define me though, because I adapt and
continue to learn, instead of becoming rigid and more stubborn.
*
*We are all human!Lets put it all together and just make it work. RPMf
and ATrpms can both PISS very, very , very far. We really don't need
to prove it.*
*
Sincerely,*
*Kelsie FlynnKelsie(a)elmythos.org <Kelsie(a)elmythos.org>*
*ELmythOS.org*
*MythPidora.org*
10 years, 4 months
testing GTX 750 TI
by Norman Goldstein
Just want to let you guys know I am running on F20, x86-64, with the
rawhide nvidia driver.
My card is a GTX 750 TI
10 years, 4 months
Nvidia 340.x legacy driver and dropped hardware...
by Alex G.S.
Dear List,
Wondering if anyone has any information about this. Nvidia is dropping a
series of older graphics cards and as of 343.x these cards will only get
updates up until 2019 through a new legacy 340.x driver branch. The
following hardware is now in the legacy 340.x branch: G8x, G9x, and GT2xx.
Unfortunately I have one of these cards and now I'm wondering how I will
get the latest drivers from RPMFusion as the newest Rawhide release is at
343.x which is not supported by my hardware. Will there be a new legacy
branch package for this series in addition to the others already on
RPMFusion?
akmod-nvidia-340xx - Akmod package for nvidia-340xx kernel module(s) <---
Will we see this ???
akmod-nvidia-304xx - Akmod package for nvidia-304xx kernel module(s)
akmod-nvidia-173xx - Akmod package for nvidia-173xx kernel module(s)
[1]
http://nvidia.custhelp.com/app/answers/detail/a_id/3142/related/1/session...
[2] http://www.nvidia.com/object/unix.html
Thanks!
10 years, 4 months
default rompath in mame and mess 0.154 has changed
by Andre Robatino
Prior to 0.154, the default rompath and mame and mess were
/usr/share/mame/roms/ and /usr/share/mess/roms/ , resp. These dirs
currently belong to the mame-data package, suggesting they are intended
to be used. However, in 0.154, the mame and mess man pages indicate that
the default rompath is now a dir called "roms" in the same directory as
the corresponding executable (meaning they both now default to
/usr/bin/roms/ , which doesn't seem sane). I see no bug in
bugzilla.rpmfusion.org. Is this a bug, or is the user expected to
specify the rompath now?
10 years, 4 months
VirtualBox 4.3.14
by Bruno Taglienti
I updated VirtualBox from the repository to 4.3.14. (Fedora 20)
It happens that no USB device is available to guest
operating systems.
Downgrading to 4.3.12 solves the problem.
Bruno Taglienti
10 years, 4 months
