6:12 p.m.
On the wishlist and/or dead reviews we have some re-distributable
packages such as skype, spotify and msttcore-fonts. After scratching my
head over these I've hacked some silly scripts , called them lpf (Local
package Factory) and made a package of it. It's on it's way into fedora,
currently in rawhide, f20 and f19 updates-testing.
Using this package it should be simpler to package a thing like spotify.
The downloader lpf-spotfy-client is also on it's way into fedora,
lpf-skype needs a review. The overall idea here is to have a common
framework for these packages simplifying for both users and packagers.
Since they by definition don't contain any upstream stuff they go into
fedora rather than rpmfusion, although they are on the rpmfusion wishlist.
I don't know if this is a good idea. Time will tell,
--alec
PS:
Blogpost:
http://leamasblog.wordpress.com/2013/10/30/getting-spotify-and-skype-into...
Upstream: https://github.com/leamas/lpf
6:30 p.m.
On 30 October 2013 19:12, Alec Leamas <leamas.alec(a)gmail.com> wrote:
On the wishlist and/or dead reviews we have some re-distributable
packages
such as skype, spotify and msttcore-fonts. After scratching my head over
these I've hacked some silly scripts , called them lpf (Local package
Factory) and made a package of it. It's on it's way into fedora, currently
in rawhide, f20 and f19 updates-testing.
Using this package it should be simpler to package a thing like spotify.
The downloader lpf-spotfy-client is also on it's way into fedora, lpf-skype
needs a review. The overall idea here is to have a common framework for
these packages simplifying for both users and packagers. Since they by
definition don't contain any upstream stuff they go into fedora rather than
rpmfusion, although they are on the rpmfusion wishlist.
I don't know if this is a good idea. Time will tell,
I can take the review for lpf-skype, I have already packaged Skype a
hundred times. Link?
I have a question regarding all of this. What prevents any kind of non-free
software like Nvidia drivers, Steam, RAR or whatever to go in Fedora with
the same approach?
It feels kind of strange that Fedora folks allowed this, but at least for
lfp-spotify-client it worked...
--Simone
6:50 p.m.
On 2013-10-30 19:30, Simone Caronni wrote:
On 30 October 2013 19:12, Alec Leamas <leamas.alec(a)gmail.com
<mailto:leamas.alec@gmail.com>> wrote:
On the wishlist and/or dead reviews we have some re-distributable
packages such as skype, spotify and msttcore-fonts. After
scratching my head over these I've hacked some silly scripts ,
called them lpf (Local package Factory) and made a package of it.
It's on it's way into fedora, currently in rawhide, f20 and f19
updates-testing.
Using this package it should be simpler to package a thing like
spotify. The downloader lpf-spotfy-client is also on it's way into
fedora, lpf-skype needs a review. The overall idea here is to
have a common framework for these packages simplifying for both
users and packagers. Since they by definition don't contain any
upstream stuff they go into fedora rather than rpmfusion, although
they are on the rpmfusion wishlist.
I don't know if this is a good idea. Time will tell,
I can take the review for lpf-skype, I have already packaged Skype a
hundred times. Link?
You are most welcome!
https://bugzilla.redhat.com/show_bug.cgi?id=1023714
I have a question regarding all of this. What prevents any kind of
non-free software like Nvidia drivers, Steam, RAR or whatever to go in
Fedora with the same approach?
Basically nothing. However, from a user perspective
I still think a
rpmfusion re-distrbutable package is preferred since lpf cannot really
hide the fact that packages must be downloaded and built -> user needs
to "push the button", long delays and build chain dependencies. Also,
lpf is primarely designed for leaf packages, I don't really sees how it
should work if something depends on a lpf package.
BTW, for other reasons Tom Callaway has decided that every lpf package
should have a legal review. So I feel pretty safe here :)
[cut]
--alec
8:37 p.m.
On 30 October 2013 19:50, Alec Leamas <leamas.alec(a)gmail.com> wrote:
You are most welcome!
https://bugzilla.redhat.com/show_bug.cgi?id=1023714
Taken. This time I will add also take a look on the "bundled" spec file and
post any comment in the review.
I will review it tomorrow early morning or my girlfriend will kill me :)
Regards,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
http://negativo17.org/
2:52 p.m.
Hello,
On 30 October 2013 21:37, Simone Caronni <negativo17(a)gmail.com> wrote:
On 30 October 2013 19:50, Alec Leamas <leamas.alec(a)gmail.com> wrote:
> You are most welcome!
> https://bugzilla.redhat.com/show_bug.cgi?id=1023714
>
Taken. This time I will add also take a look on the "bundled" spec file
and post any comment in the review.
I will review it tomorrow early morning or my girlfriend will kill me :)
sorry for the delay, I've been stuck in a meeting all day and finished now.
In 45 minutes I need to leave, so I will do something today and continue
tomorrow.
Thanks,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
http://negativo17.org/
3:13 p.m.
On 2013-10-31 15:52, Simone Caronni wrote:
Hello,
[cut]
sorry for the delay, I've been stuck in a meeting all day and finished
now. In 45 minutes I need to leave, so I will do something today and
continue tomorrow.
Thanks,
--Simone
Thanks again, and take your time! There is really no hurry, and the
legal review is pending anyway.
There is actually a risk that Spot blocks this package, although I
doubt it. And even if he does, we can submit it to rpmfusion and re-use
the review.
Cheers!
--alec
9:01 p.m.
2013/10/30 Alec Leamas <leamas.alec(a)gmail.com>
On the wishlist and/or dead reviews we have some re-distributable
packages
such as skype, spotify and msttcore-fonts. After scratching my head over
these I've hacked some silly scripts , called them lpf (Local package
Factory) and made a package of it. It's on it's way into fedora, currently
in rawhide, f20 and f19 updates-testing.
Using this package it should be simpler to package a thing like spotify.
The downloader lpf-spotfy-client is also on it's way into fedora, lpf-skype
needs a review. The overall idea here is to have a common framework for
these packages simplifying for both users and packagers. Since they by
definition don't contain any upstream stuff they go into fedora rather than
rpmfusion, although they are on the rpmfusion wishlist.
I don't know if this is a good idea. Time will tell,
Hello Alec,
I don't get the point to have non-free software "remotely within fedora".
But if acceptable I guess it could be possible to have
rpmfusion-*free-release in ? (the laters are freely redistributable).
Thx for this initiative...
---
Nicolas (kwizart)
9:29 p.m.
On 2013-10-30 22:01, Nicolas Chauvet wrote:
2013/10/30 Alec Leamas <leamas.alec(a)gmail.com
<mailto:leamas.alec@gmail.com>>
On the wishlist and/or dead reviews we have some re-distributable
packages such as skype, spotify and msttcore-fonts. After
scratching my head over these I've hacked some silly scripts ,
called them lpf (Local package Factory) and made a package of it.
It's on it's way into fedora, currently in rawhide, f20 and f19
updates-testing.
Using this package it should be simpler to package a thing like
spotify. The downloader lpf-spotfy-client is also on it's way into
fedora, lpf-skype needs a review. The overall idea here is to
have a common framework for these packages simplifying for both
users and packagers. Since they by definition don't contain any
upstream stuff they go into fedora rather than rpmfusion, although
they are on the rpmfusion wishlist.
I don't know if this is a good idea. Time will tell,
Hello Alec,
I don't get the point to have non-free software "remotely within
fedora". But if acceptable I guess it could be possible to have
rpmfusion-*free-release in ? (the laters are freely redistributable).
Thx for this initiative...
This outcome is kind of a surprise also for me; my gut feeling was that
these packages would end up in rpmfusion. However, the decision is
seemingly based on that lpf packages contains nothing from upstream and
nothing binary. What they generate is another issue, but Spot's
decision seems to be that doesn't really matter, it's not on Fedora
servers.
I guess that theoretically one could have lpf packages in fedora instead
of what's in *free now. However, like I said to Simone, for a user a
re-distributable binary rpmfusion package is a better solution than a
lpf package which basically is kind of a source distribution. lpf cannot
really hide the fact that the package must be built, it takes time and
gives build deps. And, also again, lpf is really designed for leaf
packages, I don't see what happens if something depends on a lpf package.
Also, the lpf build process is just semi-automated on purpose. A user
need to be present to accept EULA conditions if required.
Bottom line: lpf is designed as the last resort, when something can't be
hosted neither on fedora nor rpmfusion. I suggest that we keep it this way.
--alec
1:29 a.m.
Alec Leamas wrote:
This outcome is kind of a surprise also for me; my gut feeling was
that
these packages would end up in rpmfusion. However, the decision is
seemingly based on that lpf packages contains nothing from upstream and
nothing binary. What they generate is another issue, but Spot's
decision seems to be that doesn't really matter, it's not on Fedora
servers.
Huh? This is against:
https://fedoraproject.org/wiki/Packaging:Guidelines#Packages_which_are_no...
I'm going to complain about this to FPC, and if they ignore the issue,
escalate it to FESCo. This kind of package has no business being in Fedora!
Kevin Kofler
1:42 a.m.
PS:
I wrote:
I'm going to complain about this to FPC, and if they ignore the
issue,
escalate it to FESCo. This kind of package has no business being in
Fedora!
https://fedorahosted.org/fpc/ticket/362
Kevin Kofler
4:08 a.m.
On Fri, 2013-11-01 at 02:42 +0100, Kevin Kofler wrote:
I wrote:
> I'm going to complain about this to FPC, and if they ignore the
issue,
> escalate it to FESCo. This kind of package has no business being in
> Fedora!
https://fedorahosted.org/fpc/ticket/362
Thank you for filing the ticket, Kevin. Even if lpf makes it easier for
users to use skype/spotify/whatnot, it's promoting non-foss software.
Not only is it against the packaging guidelines, it's quite against our
foundation of freedom too.
I think packaging stuff up for rpmfusion as we've already been doing is
the way to go.
[1] http://fedoraproject.org/wiki/Foundations
--
Thanks,
Warm regards,
Ankur (FranciscoD)
http://fedoraproject.org/wiki/User:Ankursinha
Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG
8:56 a.m.
On 1 November 2013 02:42, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
> I'm going to complain about this to FPC, and if they ignore
the issue,
> escalate it to FESCo. This kind of package has no business being in
> Fedora!
https://fedorahosted.org/fpc/ticket/362
Apparently for the legal team this is acceptable. As I already stated
before I'm very surprised that it has passed legal review; but if it's
acceptable for them...
I would feel more comfortable though if these packages would go in
RPMFusion instead of Fedora. This way Fedora would promote only 100% free
software and all reviews would not have the FE-LEGAL burden.
Just my 2c.
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
http://negativo17.org/
4:35 a.m.
On Sex, 2013-11-01 at 09:56 +0100, Simone Caronni wrote:
On 1 November 2013 02:42, Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
> I'm going to complain about this to FPC, and if they ignore
the issue,
> escalate it to FESCo. This kind of package has no business
being in
> Fedora!
https://fedorahosted.org/fpc/ticket/362
Apparently for the legal team this is acceptable. As I already stated
before I'm very surprised that it has passed legal review; but if it's
acceptable for them...
I would feel more comfortable though if these packages would go in
RPMFusion instead of Fedora. This way Fedora would promote only 100%
free software and all reviews would not have the FE-LEGAL burden.
Hi, Simone, thanks for resuming this thread, I think lpf-skype is
welcome to RPMFusion nonfree , and 100% agree with you. Doesn't make
sense to me Fedora promoted nonfree software . Kelvin is right on saying
this goes against packages guidelines.
But lpf have the capacity to turn around Legal stuff, with
Non-redistributable software like Adobe flash and it is impossible live
without flash at least in my world, so Fedora lose many people, just
because, easily they can't install Non-redistributable software.
I think we should put it on tests on RPMFusion see how it goes and
discuss this with all Fedora community deeply, because it will be a big
change . We can't decide this alone I think.
Just my 2c.
--Simone
--
You cannot discover new oceans unless you have the courage to lose
sight of the shore (R. W. Emerson).
http://xkcd.com/229/
http://negativo17.org/
--
Sérgio M. B.
4:59 a.m.
On 11/14/2013 05:35 AM, Sérgio Basto wrote:
On Sex, 2013-11-01 at 09:56 +0100, Simone Caronni wrote:
> On 1 November 2013 02:42, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
> > I'm going to complain about this to FPC, and if they ignore
> the issue,
> > escalate it to FESCo. This kind of package has no business
> being in
> > Fedora!
>
>
> https://fedorahosted.org/fpc/ticket/362
>
>
> Apparently for the legal team this is acceptable. As I already stated
> before I'm very surprised that it has passed legal review; but if it's
> acceptable for them...
>
> I would feel more comfortable though if these packages would go in
> RPMFusion instead of Fedora. This way Fedora would promote only 100%
> free software and all reviews would not have the FE-LEGAL burden.
>
Hi, Simone, thanks for resuming this thread, I think lpf-skype is
welcome to RPMFusion nonfree , and 100% agree with you.
The problem is just that to
be welcome in rpmfusion, we must get a clear
statement that the lpf-* packages are not eligible for Fedora. At this
point, this is actually not clear since the review (including Spot's
legal check) has approved lpf-spotify-client.
Doesn't make
sense to me Fedora promoted nonfree software . Kelvin is right on saying
this goes against packages guidelines.
But lpf have the capacity to turn around Legal stuff, with
Non-redistributable software like Adobe flash and it is impossible live
without flash at least in my world, so Fedora lose many people, just
because, easily they can't install Non-redistributable software.
I think we should put it on tests on RPMFusion see how it goes and
discuss this with all Fedora community deeply, because it will be a big
change . We can't decide this alone I think.
See above. What we really need now is a fpc decision (#362). I'm
worried that this decision might be postponed without input from spot.
--alec
9:54 a.m.
2013/11/14 Alec Leamas <leamas.alec(a)gmail.com
...
The problem is just that to be welcome in rpmfusion, we must get a
clear
statement that the lpf-* packages are not eligible for Fedora. At this
point, this is actually not clear since the review (including Spot's legal
check) has approved lpf-spotify-client.
That's because FE-Legal answear questions about what is legally possible
whereas FESCO or the Board would create guidelines following our moral
principles.
It's possible to have lpf-spotify in a repository, but the fedora project
as a whole choose not to have it.
Nicolas (kwizart)
10:09 a.m.
On 11/14/2013 10:54 AM, Nicolas Chauvet wrote:
2013/11/14 Alec Leamas <leamas.alec(a)gmail.com
<mailto:leamas.alec@gmail.com>
...
The problem is just that to be welcome in rpmfusion, we must get a
clear statement that the lpf-* packages are not eligible for
Fedora. At this point, this is actually not clear since the
review (including Spot's legal check) has approved
lpf-spotify-client.
That's because FE-Legal answear questions about what is legally
possible whereas FESCO or the Board would create guidelines following
our moral principles.
It's possible to have lpf-spotify in a repository, but the fedora
project as a whole choose not to have it.
Nicolas (kwizart)
Long story short: I agree (longer explanation in ticket). That said, we
need a fpc decision.
--alec
7:29 p.m.
On Sex, 2013-11-15 at 19:21 +0100, Kevin Kofler wrote:
I wrote:
> And if FPC doesn't feel competent, they should say so so we can re-file
> the ticket with FESCo (or they could just forward it to FESCo directly).
Actually, I see FPC made a decision now, that's good.
And what was decision ? , I don't understand what is write in the
ticket .
--
Sérgio M. B.
8:36 p.m.
On 2013-11-18 20:29, Sérgio Basto wrote:
On Sex, 2013-11-15 at 19:21 +0100, Kevin Kofler wrote:
> I wrote:
>> And if FPC doesn't feel competent, they should say so so we can re-file
>> the ticket with FESCo (or they could just forward it to FESCo directly).
> Actually, I see FPC made a decision now, that's good.
And what was decision ? , I don't understand what is write in the
ticket .
It basically boils down to that the main lpf package is OK for fedora,
while lpf-* packages as lpf-skype and lpf-spotify-client should be in a
'more appropriate repository' (Don't mention the war...)
I have retired lpf-spotify-client from fedora. lpf-skype and
lpf-spotify-client are on their way into rpmfusion in tickets 3033 and
3034 in a joint venture between me and Simone Caronni.
--alec
8:51 p.m.
On Seg, 2013-11-18 at 21:36 +0100, Alec Leamas wrote:
On 2013-11-18 20:29, Sérgio Basto wrote:
> On Sex, 2013-11-15 at 19:21 +0100, Kevin Kofler wrote:
>> I wrote:
>>> And if FPC doesn't feel competent, they should say so so we can re-file
>>> the ticket with FESCo (or they could just forward it to FESCo directly).
>> Actually, I see FPC made a decision now, that's good.
> And what was decision ? , I don't understand what is write in the
> ticket .
>
It basically boils down to that the main lpf package is OK for fedora,
while lpf-* packages as lpf-skype and lpf-spotify-client should be in a
'more appropriate repository' (Don't mention the war...)
I have retired lpf-spotify-client from fedora. lpf-skype and
lpf-spotify-client are on their way into rpmfusion in tickets 3033 and
3034 in a joint venture between me and Simone Caronni.
I will join in with "Adobe flash reader", it is possible ?
Many thanks,
--
Sérgio M. B.
9:11 p.m.
On 2013-11-18 21:51, Sérgio Basto wrote:
On Seg, 2013-11-18 at 21:36 +0100, Alec Leamas wrote:
> On 2013-11-18 20:29, Sérgio Basto wrote:
>> On Sex, 2013-11-15 at 19:21 +0100, Kevin Kofler wrote:
>>> I wrote:
>>>> And if FPC doesn't feel competent, they should say so so we can
re-file
>>>> the ticket with FESCo (or they could just forward it to FESCo directly).
>>> Actually, I see FPC made a decision now, that's good.
>> And what was decision ? , I don't understand what is write in the
>> ticket .
>>
> It basically boils down to that the main lpf package is OK for fedora,
> while lpf-* packages as lpf-skype and lpf-spotify-client should be in a
> 'more appropriate repository' (Don't mention the war...)
>
> I have retired lpf-spotify-client from fedora. lpf-skype and
> lpf-spotify-client are on their way into rpmfusion in tickets 3033 and
> 3034 in a joint venture between me and Simone Caronni.
I will join in with "Adobe flash reader", it is possible ?
Many thanks,
You are welcome!. It should be possible as long as the license allows
us
to freely download and build a package i. e., there must be no
limitations on the downloader. The target package can have
limitations, I presume it's "non-redistributable, no modications permitted'.
Look at the two tickets for examples, there is also a commented template
in the lpf upstream at github which is reasonably up to date.
Preferably, use the lpf version in updates-testing while testing,
current lpf in main repo has some annoying glitches. Assume you will
find bugs...
If you submit a review request I can review it.
--alec
9:15 p.m.
Le 18 nov. 2013 21:52, "Sérgio Basto" <sergio(a)serjux.com> a écrit :
On Seg, 2013-11-18 at 21:36 +0100, Alec Leamas wrote:
> On 2013-11-18 20:29, Sérgio Basto wrote:
> > On Sex, 2013-11-15 at 19:21 +0100, Kevin Kofler wrote:
> >> I wrote:
> >>> And if FPC doesn't feel competent, they should say so so we can
re-file
> >>> the ticket with FESCo (or they could just forward
it to FESCo
directly).
> >> Actually, I see FPC made a decision now, that's
good.
> > And what was decision ? , I don't understand what is write in the
> > ticket .
> >
> It basically boils down to that the main lpf package is OK for fedora,
> while lpf-* packages as lpf-skype and lpf-spotify-client should be in a
> 'more appropriate repository' (Don't mention the war...)
>
> I have retired lpf-spotify-client from fedora. lpf-skype and
> lpf-spotify-client are on their way into rpmfusion in tickets 3033 and
> 3034 in a joint venture between me and Simone Caronni.
I will join in with "Adobe flash reader", it is possible ?
Is it possible to only handle the adobe-release* repositories instead ?
Unless all thoses adobe packages are really broken ?
Nicolas (kwizart)
9:34 p.m.
On 2013-11-18 22:15, Nicolas Chauvet wrote:
Le 18 nov. 2013 21:52, "Sérgio Basto" <sergio(a)serjux.com
<mailto:sergio@serjux.com>> a écrit :
>
> On Seg, 2013-11-18 at 21:36 +0100, Alec Leamas wrote:
> > On 2013-11-18 20:29, Sérgio Basto wrote:
> > > On Sex, 2013-11-15 at 19:21 +0100, Kevin Kofler wrote:
> > >> I wrote:
> > >>> And if FPC doesn't feel competent, they should say so so we
can re-file
> > >>> the ticket with FESCo (or they could just forward it to FESCo
directly).
> > >> Actually, I see FPC made a decision now, that's good.
> > > And what was decision ? , I don't understand what is write in the
> > > ticket .
> > >
> > It basically boils down to that the main lpf package is OK for fedora,
> > while lpf-* packages as lpf-skype and lpf-spotify-client should be
in a
> > 'more appropriate repository' (Don't mention the war...)
> >
> > I have retired lpf-spotify-client from fedora. lpf-skype and
> > lpf-spotify-client are on their way into rpmfusion in tickets 3033 and
> > 3034 in a joint venture between me and Simone Caronni.
>
> I will join in with "Adobe flash reader", it is possible ?
Is it possible to only handle the adobe-release* repositories instead
? Unless all thoses adobe packages are really broken ?
Nicolas (kwizart)
It was a long time since I looked into Adobe Reader... are you saying
there are already existing packages out there from Adobe?
If so, it does not fit that well into the lpf framework. One could
download the package, unpack it in %prep and rebuild it it %build and
%install - but doing this without adding value seems strange, and might
also cause legal concerns depending on the license.
OTOH such a recipe might e. g., generate more accurate dependencies if
upstream's are broken. Which, according to my *very* old Adobe
experiences would be as expected. In general, it makes a lot of sense
to treat an Ubuntu .deb package this way - this is what the spotify
package does.
--alec
10:29 p.m.
Once upon a time, Alec Leamas <leamas.alec(a)gmail.com> said:
It was a long time since I looked into Adobe Reader... are you
saying there are already existing packages out there from Adobe?
Both Flash and Acrobat Reader are available from Adobe repos. The only
issue is that Acrobat Reader is 32 bit only, and only available from
their 32 bit repo. So, if you want it on x86_64, you have to add both
the 32 and 64 bit repos.
There are some other odd things about their Acrobat Reader packaing:
- There's a different RPM for each language - AdobeReader_XXX (for
example, "AdobeReader_enu" for English).
- They bundle some libraries and didn't filter them from the RPM
provides, so if you are not careful, you can try to install something
and have yum/RPM think that the AdobeReader_XXX package provides the
necessary libs.
I don't think there's any major issue like that with the Flash plugin
RPM. I think it goes to the other extreme, filtering just about _all_
requirements and dependencies, but that's probably not an issue (since
the browser using Flash will probably have all the deps already loaded).
--
Chris Adams <linux(a)cmadams.net>
7:54 a.m.
On 18 November 2013 22:15, Nicolas Chauvet <kwizart(a)gmail.com> wrote:
Is it possible to only handle the adobe-release* repositories instead
?
Unless all thoses adobe packages are really broken ?
The flash plugin packages are really broken indeed. They ship a package
that is for all rpm based distributions, install in weird locations and do
everything with a setup that is run in the %post sections along with ln and
rm commands. Dependencies are missing and installs kde integration also on
gnome. Since dependencies are broken if you remove it you will have loose
directories all over.
If you have Redhat account, you can see that Redhat has a repackaged
version in the "Supplementary" channel of the base RHEL releases.
I've been mantaining the flash-plugin for quite few years now for personal
use and for the various companies I've worked for, so Alec/Sergio, if you
are interested I can lend some help. The resulting package is 90% close to
the RHEL one for which there is no spec file available.
The i686 bit package should also be in the x86_64 repository as Steam
requires the Flash plugin for playing videos in the game detail pages. I've
been doing this in my repository.
http://negativo17.org/adobe-flash-plugin/
http://negativo17.org/repos/flash-plugin/flash-plugin.spec
Regards,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
http://negativo17.org/
7:56 a.m.
Some details on the Adobe provided package:
$ rpm -qpl flash-plugin-11.2.202.327-release.x86_64.rpm
/usr/bin/flash-player-properties
/usr/lib64/flash-plugin
/usr/lib64/flash-plugin/LICENSE
/usr/lib64/flash-plugin/README
/usr/lib64/flash-plugin/homecleanup
/usr/lib64/flash-plugin/libflashplayer.so
/usr/lib64/flash-plugin/setup
/usr/lib64/kde4/kcm_adobe_flash_player.so
/usr/share/applications/flash-player-properties.desktop
/usr/share/doc/flash-plugin-11.2.202.327
/usr/share/doc/flash-plugin-11.2.202.327/readme.txt
/usr/share/icons/hicolor/16x16/apps/flash-player-properties.png
/usr/share/icons/hicolor/22x22/apps/flash-player-properties.png
/usr/share/icons/hicolor/24x24/apps/flash-player-properties.png
/usr/share/icons/hicolor/32x32/apps/flash-player-properties.png
/usr/share/icons/hicolor/48x48/apps/flash-player-properties.png
/usr/share/kde4/services/kcm_adobe_flash_player.desktop
$ rpm -qp --requires flash-plugin-11.2.202.327-release.x86_64.rpm
glibc >= 2.4
/bin/sh
/bin/sh
/bin/sh
/bin/sh
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
$ rpm -qp --scripts flash-plugin-11.2.202.327-release.x86_64.rpm
postinstall scriptlet (using /bin/sh):
if [ "$1" = "1" ]; then
/usr/lib64/flash-plugin/setup 64 install
fi
if [ "$1" = "2" ]; then
/usr/lib64/flash-plugin/setup 64 upgrade
fi
ln -f -s /usr/share/icons/hicolor/48x48/apps/flash-player-properties.png
/usr/share/pixmaps/
preuninstall scriptlet (using /bin/sh):
if [ "$1" = "0" ]; then
/usr/lib64/flash-plugin/setup 64 preun
fi
postuninstall scriptlet (using /bin/sh):
rm -f /usr/share/pixmaps/flash-player-properties.png
Some details from my package (and RHEL as well):
$ rpm -q --scripts flash-plugin
postinstall scriptlet (using /bin/sh):
touch --no-create /usr/share/icons/hicolor &>/dev/null || :
postuninstall scriptlet (using /bin/sh):
if [ $1 -eq 0 ] ; then
touch --no-create /usr/share/icons/hicolor &>/dev/null
gtk-update-icon-cache /usr/share/icons/hicolor &>/dev/null || :
fi
posttrans scriptlet (using /bin/sh):
gtk-update-icon-cache /usr/share/icons/hicolor &>/dev/null || :
postinstall scriptlet (using /bin/sh):
touch --no-create /usr/share/icons/hicolor &>/dev/null || :
postuninstall scriptlet (using /bin/sh):
if [ $1 -eq 0 ] ; then
touch --no-create /usr/share/icons/hicolor &>/dev/null
gtk-update-icon-cache /usr/share/icons/hicolor &>/dev/null || :
fi
posttrans scriptlet (using /bin/sh):
gtk-update-icon-cache /usr/share/icons/hicolor &>/dev/null || :
$ sudo yum list flash-plugin\*
Loaded plugins: langpacks, refresh-packagekit
Installed Packages
flash-plugin.i686 1:11.2.202.310-1.fc19
@fedora-flash-plugin
flash-plugin.x86_64 1:11.2.202.310-1.fc19
@fedora-flash-plugin
Available Packages
flash-plugin-kde.i686 1:11.2.202.310-1.fc19
fedora-flash-plugin
flash-plugin-kde.x86_64 1:11.2.202.310-1.fc19
fedora-flash-plugin
Regards,
--Simone
On 19 November 2013 08:54, Simone Caronni <negativo17(a)gmail.com> wrote:
On 18 November 2013 22:15, Nicolas Chauvet <kwizart(a)gmail.com>
wrote:
> Is it possible to only handle the adobe-release* repositories instead ?
> Unless all thoses adobe packages are really broken ?
>
The flash plugin packages are really broken indeed. They ship a package
that is for all rpm based distributions, install in weird locations and do
everything with a setup that is run in the %post sections along with ln and
rm commands. Dependencies are missing and installs kde integration also on
gnome. Since dependencies are broken if you remove it you will have loose
directories all over.
If you have Redhat account, you can see that Redhat has a repackaged
version in the "Supplementary" channel of the base RHEL releases.
I've been mantaining the flash-plugin for quite few years now for personal
use and for the various companies I've worked for, so Alec/Sergio, if you
are interested I can lend some help. The resulting package is 90% close to
the RHEL one for which there is no spec file available.
The i686 bit package should also be in the x86_64 repository as Steam
requires the Flash plugin for playing videos in the game detail pages. I've
been doing this in my repository.
http://negativo17.org/adobe-flash-plugin/
http://negativo17.org/repos/flash-plugin/flash-plugin.spec
Regards,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight
of the shore (R. W. Emerson).
http://xkcd.com/229/
http://negativo17.org/
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
http://negativo17.org/
9:22 a.m.
Hi Simone,
On Tuesday, 19 November 2013 at 08:54, Simone Caronni wrote:
[...]
I've been mantaining the flash-plugin for quite few years now for
personal
use and for the various companies I've worked for, so Alec/Sergio, if you
are interested I can lend some help. The resulting package is 90% close to
the RHEL one for which there is no spec file available.
The i686 bit package should also be in the x86_64 repository as Steam
requires the Flash plugin for playing videos in the game detail pages. I've
been doing this in my repository.
That's very nice and I've been actually doing the same thing, but I
don't advertise my repository on the open Internet, because distributing
Adobe's Flash plugin is against the licence. Or do you have a special
licence from Adobe to do so?
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
9:43 a.m.
On 21 November 2013 10:22, Dominik 'Rathann' Mierzejewski <
dominik(a)greysector.net> wrote:
That's very nice and I've been actually doing the same thing,
but I
don't advertise my repository on the open Internet, because distributing
Adobe's Flash plugin is against the licence. Or do you have a special
licence from Adobe to do so?
Nope, no licence, in fact I'm planning to delete them after the lpf*
packages are in. I discovered Alec's lpf work while proposing the packages
to RPMFusion.
Regards,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
http://negativo17.org/
11:08 p.m.
On Qui, 2013-11-21 at 10:43 +0100, Simone Caronni wrote:
On 21 November 2013 10:22, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
That's very nice and I've been actually doing the same thing,
but I
don't advertise my repository on the open Internet, because
distributing
Adobe's Flash plugin is against the licence. Or do you have a
special
licence from Adobe to do so?
Nope, no licence, in fact I'm planning to delete them after the lpf*
packages are in. I discovered Alec's lpf work while proposing the
packages to RPMFusion.
Hi, back to this point , no license doesn't mean you can. At least, is
what lawyers in my work said about other thing completely different.
So or we have permission or is not authorized, but I'm not a lawyer .
So I think we can call "Adobe's Flash plugin" not redistributable (by
omission in license ?! ).
Apart of this. RPMFusion have any other rule or restriction ? to not
ship this kind of software ? , because already have a repo ?
My idea was exactly not have to configure a dozen repositories, and
eventually an rpmfusion remix have it all out of the box .
--
Sérgio M. B.
7:47 a.m.
On 26 November 2013 00:08, Sérgio Basto <sergio(a)serjux.com> wrote:
Apart of this. RPMFusion have any other rule or restriction ? to not
ship this kind of software ? , because already have a repo ?
I've read the license text file and it seems that we can do what lpf
package does, i.e. the user downloads and installs the package on its own
system; so it should be coevered by the license.
My idea was exactly not have to configure a dozen repositories, and
eventually an rpmfusion remix have it all out of the box .
Would like to as well. It's not like having the package downloaded through
a yum repository, but it's better than nothing.
Regards,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
http://negativo17.org/
9:14 a.m.
On 2013-11-01 02:42, Kevin Kofler wrote:
PS:
I wrote:
> I'm going to complain about this to FPC, and if they ignore the issue,
> escalate it to FESCo. This kind of package has no business being in
> Fedora!
https://fedorahosted.org/fpc/ticket/362
Kevin Kofler
Answer in ticket. BTW, thanks for filing that!
--alec
9:46 a.m.
Alec,
I'm importing the lfp-skype package in CVS. I've added something more to
the spec file that is in the review; the skype.spec.in file now generate
separate skype.i686 and skype-data.noarch packages.
Before importing, I would like to know if it's possible with the current
lpf from fedora-updates-testing. Can it install multiple packages from the
generated spec.in file?
Regards,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
http://negativo17.org/
9:54 a.m.
On 2013-11-21 10:46, Simone Caronni wrote:
Alec,
I'm importing the lfp-skype package in CVS. I've added something more
to the spec file that is in the review; the skype.spec.in
<http://skype.spec.in> file now generate separate skype.i686 and
skype-data.noarch packages.
Before importing, I would like to know if it's possible with the
current lpf from fedora-updates-testing. Can it install multiple
packages from the generated spec.in <http://spec.in> file?
Regards,
--Simone
It's not as tested as it should be, but the code is there.
--alec
10:04 a.m.
On 21 November 2013 10:54, Alec Leamas <leamas.alec(a)gmail.com> wrote:
Before importing, I would like to know if it's possible with the current
lpf from fedora-updates-testing. Can it install multiple packages from the
generated spec.in file?
It's not as tested as it should be, but the code is there.
Ok, making a test.
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
http://negativo17.org/
10:13 a.m.
Seems to work, but the problem is the architecture. Skype is always i686
while my system is x86_64:
Getting requirements for /usr/share/lpf/packages/skype/skype.spec
--> Already installed : desktop-file-utils-0.21-2.fc19.x86_64
No uninstalled build requires
error: Architecture is not included: x86_64
Any hint on how to proceed?
Regards,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
http://negativo17.org/
3809
days inactive
3836
days old
rpmfusion-developers@lists.rpmfusion.org
35 comments
8 participants
participants (8)
-
Alec Leamas -
Ankur Sinha -
Chris Adams -
Dominik 'Rathann' Mierzejewski -
Kevin Kofler -
Nicolas Chauvet -
Simone Caronni -
Sérgio Basto