4:56 p.m.
Hi all,
I'm looking to become involved as a package maintainer at
rpmfusion/livna. I haven't previously submitted packages to Fedora so
I'll be looking for a sponsor - I know you guys are busy with the
migration to rpmfusion but I'm hopeful someone can spend some time with
a new contributor. Initially I'd like to submit a new package: the new
Broadcom drivers kernel module that does away with requiring ndiswrapper
for those chipsets unsupported by b43. I have used this driver on F9 and
it works beautifully so IMO it would be a great addition to rpmfusion/livna.
Here's a bit about my background:
By day I'm a systems admin looking after OS X server and workstations as
well as a handful of Linux servers including YDL 6 and RHEL. I'm also a
PHP/MySQL developer and a server admin on a couple of CentOS 5.x boxes.
As a hobbyist I love Fedora and I've spent many many hours helping to
make it work properly on MacBooks (I don't like OS X!).
My experience of creating RPMs is largely limited to patching and
rebuilding existing SRPMs - I have done this a lot with packages ranging
from kernels to gstreamer, synaptics, openoffice etc. I have never built
my own RPMs "from scratch" but I'm confident in my ability and I've read
and largely absorbed the Fedora Packaging Guidelines.
So, as I said, I'd really like to see the new Broadcom kernel module
make it into a mainstream repo such as rpmfusion/livna and I'm happy to
take this on. I've already gone as far as finding the patches to make
the module build properly on F9 and have written a how-to that covers
this topic
(http://www.cenolan.com/2008/10/installing-the-broadcom-sta-driver-fedora-9/).
I haven't yet turned this into an RPM (probably can't get time to do it
until after this weekend).
Please let me know what should be my next steps (I've got a rpmfusion
bugzilla account) and I'd be really grateful if a sponsor was willing to
spend a little time with me on the finer points of RPM building. I'll
try to make myself available on this list and in the IRC rooms (cnolan).
All the best
Chris
6:44 p.m.
Chris Nolan wrote:
Hi all,
I'm looking to become involved as a package maintainer at
rpmfusion/livna. I haven't previously submitted packages to Fedora so
I'll be looking for a sponsor - I know you guys are busy with the
migration to rpmfusion but I'm hopeful someone can spend some time with
a new contributor. Initially I'd like to submit a new package: the new
Broadcom drivers kernel module that does away with requiring ndiswrapper
for those chipsets unsupported by b43. I have used this driver on F9 and
it works beautifully so IMO it would be a great addition to
rpmfusion/livna.
Hi,
First of all welcome to the rpmfusion community / project!
Please let me know what should be my next steps (I've got a rpmfusion
bugzilla account) and I'd be really grateful if a sponsor was willing to
spend a little time with me on the finer points of RPM building. I'll
try to make myself available on this list and in the IRC rooms (cnolan).
One of the things you also want to do is create an account in the account system:
https://fas.rpmfusion.org/accounts
As for looking for a sponsor, as your main interest at the moment seems to be
getting the bcm module packaged (which I think is great, many people will like
that), I think it would be best if Thorsten works with you to get that kmod
package in to shape, as he knows most about kmods.
Regards,
Hans
6:44 a.m.
On 23.10.2008 20:44, Hans de Goede wrote:
Chris Nolan wrote:
> I'm looking to become involved as a package maintainer at
> rpmfusion/livna. I haven't previously submitted packages to Fedora so
> I'll be looking for a sponsor - I know you guys are busy with the
> migration to rpmfusion but I'm hopeful someone can spend some time with
> a new contributor. Initially I'd like to submit a new package: the new
> Broadcom drivers kernel module that does away with requiring ndiswrapper
> for those chipsets unsupported by b43. I have used this driver on F9 and
> it works beautifully so IMO it would be a great addition to
> rpmfusion/livna.
First of all welcome to the rpmfusion community / project!
+1
> Please let me know what should be my next steps (I've got a
rpmfusion
> bugzilla account) and I'd be really grateful if a sponsor was willing to
> spend a little time with me on the finer points of RPM building. I'll
> try to make myself available on this list and in the IRC rooms (cnolan).
[...]
As for looking for a sponsor, as your main interest at the moment seems to be
getting the bcm module packaged (which I think is great, many people will like
that), I think it would be best if Thorsten works with you to get that kmod
package in to shape, as he knows most about kmods.
Yeah, I'm willing to help and to act as sponsor. But I don't mind if I
get help from existing contributors/other interested parties in getting
the userland into shape -- which at least in the case of open-vm-tools
https://bugzilla.rpmfusion.org/show_bug.cgi?id=67 is a lot more
complicate then the kmod package.
I in fact had packaging the driver pretty high on my own todo list and
talked to Makurin Roman (CCed) a few days ago already when he added the
driver to our steadily growing wishlist ( http://rpmfusion.org/Wishlist
). He offered help with testing the driver (and with packaging later
maybe as well). I'd say with three people we hopefully should get that
driver into the repos quickly.
Chris, I'll just wait for review request in bugzilla then. If you need
help with that let me know; contact data can be found on
http://fedoraproject.org/wiki/ThorstenLeemhuis
CU
knurd
7:38 p.m.
Hello, sorry to bothers you in this email but I really want to be a
package maintainer at rpmfusion/livna. My experience for package
maintainer it's NULL, :D, but I know c++ and I have a lot of fun
building the latest packages of many programs.
Please anyone can help me to be a package maintainer??
I propose to be package maintainer of VirtualBox. It's possible to make it?
Salu2...
On Fri, Oct 24, 2008 at 4:44 AM, Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
On 23.10.2008 20:44, Hans de Goede wrote:
>
> Chris Nolan wrote:
>>
>> I'm looking to become involved as a package maintainer at rpmfusion/livna. I
haven't previously submitted packages to Fedora so I'll be looking for a sponsor -
I know you guys are busy with the migration to rpmfusion but I'm hopeful someone can
spend some time with a new contributor. Initially I'd like to submit a new package:
the new Broadcom drivers kernel module that does away with requiring ndiswrapper for those
chipsets unsupported by b43. I have used this driver on F9 and it works beautifully so IMO
it would be a great addition to rpmfusion/livna.
>
> First of all welcome to the rpmfusion community / project!
+1
>> Please let me know what should be my next steps (I've got a rpmfusion
bugzilla account) and I'd be really grateful if a sponsor was willing to spend a
little time with me on the finer points of RPM building. I'll try to make myself
available on this list and in the IRC rooms (cnolan).
> [...]
>
> As for looking for a sponsor, as your main interest at the moment seems to be getting
the bcm module packaged (which I think is great, many people will like that), I think it
would be best if Thorsten works with you to get that kmod
> package in to shape, as he knows most about kmods.
Yeah, I'm willing to help and to act as sponsor. But I don't mind if I get help
from existing contributors/other interested parties in getting the userland into shape --
which at least in the case of open-vm-tools
https://bugzilla.rpmfusion.org/show_bug.cgi?id=67 is a lot more complicate then the kmod
package.
I in fact had packaging the driver pretty high on my own todo list and talked to Makurin
Roman (CCed) a few days ago already when he added the driver to our steadily growing
wishlist ( http://rpmfusion.org/Wishlist ). He offered help with testing the driver (and
with packaging later maybe as well). I'd say with three people we hopefully should get
that driver into the repos quickly.
Chris, I'll just wait for review request in bugzilla then. If you need help with that
let me know; contact data can be found on
http://fedoraproject.org/wiki/ThorstenLeemhuis
CU
knurd
10:14 a.m.
Hi!
On 24.10.2008 21:38, Mario Chacon wrote:
Hello, sorry to bothers you in this email but I really want to be a
package maintainer at rpmfusion/livna. My experience for package
maintainer it's NULL, :D, but I know c++ and I have a lot of fun
building the latest packages of many programs.
First of all welcome to the rpmfusion community / project!
Please anyone can help me to be a package maintainer??
Sure, we can and will help, but most of us are quite busy and I'm not
sure what you exactly expect from us.
Afaics most contributors became package maintainers by simply "doing it"
-- e.g. reading some articles/guides/howtos/books on RPM packaging (¹)
and then start to package something. When they were ready they put the
package up for review and that's the point where you get help, as the
reviewer will tell you want needs to be improved (hence you learn from
the reviewers experience).
(¹) You can find alot of help and how things work in the Fedoraproject
wiki; especially here:
https://fedoraproject.org/wiki/PackageMaintainers
http://fedoraproject.org/wiki/Packaging/Guidelines
RPM Fusion round about works just like Fedora and follows the Fedora
packaging guidelines with some very small exceptions (e.g. Licensing)
I propose to be package maintainer of VirtualBox. It's possible
to make it?
That's likely not a good choice as it's likely complicate to package
(especially as it involved kernel-modules). Also note that there are
VirtualBox packages for Fedora floating around on the net; one of them
are iirc from Xavier Lamien (CCed; he is a RPM Fusion contributer
already), who wanted to put them up for review. Maybe you can help him
with it (especially with testing and getting the packages in shape to
make them "just work) and in parallel you might want to look around for
other software to package for Fedora and/or RPM Fusion.
CU
knurd
1:21 p.m.
Hi Thorsten and Hans, thanks for the responses.
Looking at packaging the RPM: the main thing that sticks out is that
there are two different source tarballs for 32 and 64 bit systems. The
only difference between the two tarballs is the hybrid binary driver
itself - the rest of the source is the same. What would be the
recommended way to proceed with this type of scenario?
I was wondering whether to include both binary files (they would need
renaming to distinguish which is which) within a new single tarball and
then use a patch for the Makefile to ensure it uses the correct binary
driver. This seems a bit "hacky" so I wondered if anyone could think of
a more elegant solution?
Cheers
Chris
1:55 p.m.
On 25.10.2008 15:21, Chris Nolan wrote:
Looking at packaging the RPM: the main thing that sticks out is that
there are two different source tarballs for 32 and 64 bit systems.
Joy and fun with proprietary vendor drivers :-/
The
only difference between the two tarballs is the hybrid binary driver
itself - the rest of the source is the same. What would be the
recommended way to proceed with this type of scenario?
Good question. I'm unsure myself.
I was wondering whether to include both binary files (they would need
renaming to distinguish which is which) within a new single tarball and
then use a patch for the Makefile to ensure it uses the correct binary
driver.
Things like that makes it really hard for others to modify or update the
package later -- every time I run into hacks like this while updating a
package I'd like to cry. Hence I'd say: lat way lie dragons, don't go
into that direction.
This seems a bit "hacky" so I wondered if anyone could
think of
a more elegant solution?
I'd download both tarballs and give them a x86-32 and x86-64 suffix.
Then I'd include them as Source0 and Source1; in the spec use some
ifarch trickery around the setup macro to extract the right one. Also
not really nice (and it makes the SRPM a bit bigger), but it's a lot
more clean afaics.
But there are likely a few other more clean ways to solve the problem;
maybe someone else on this list comes up with a better idea?
CU
knurd
10:06 p.m.
On Saturday 25 October 2008 06:55:34 am Thorsten Leemhuis wrote:
On 25.10.2008 15:21, Chris Nolan wrote:
> Looking at packaging the RPM: the main thing that sticks out is that
> there are two different source tarballs for 32 and 64 bit systems.
Joy and fun with proprietary vendor drivers :-/
> The
> only difference between the two tarballs is the hybrid binary driver
> itself - the rest of the source is the same. What would be the
> recommended way to proceed with this type of scenario?
Good question. I'm unsure myself.
> I was wondering whether to include both binary files (they would need
> renaming to distinguish which is which) within a new single tarball and
> then use a patch for the Makefile to ensure it uses the correct binary
> driver.
Things like that makes it really hard for others to modify or update the
package later -- every time I run into hacks like this while updating a
package I'd like to cry. Hence I'd say: lat way lie dragons, don't go
into that direction.
> This seems a bit "hacky" so I wondered if anyone could think of
> a more elegant solution?
I'd download both tarballs and give them a x86-32 and x86-64 suffix.
Then I'd include them as Source0 and Source1; in the spec use some
ifarch trickery around the setup macro to extract the right one. Also
not really nice (and it makes the SRPM a bit bigger), but it's a lot
more clean afaics.
But there are likely a few other more clean ways to solve the problem;
maybe someone else on this list comes up with a better idea?
CU
knurd
This idea seems the best route to go to me (the "Fedora way" is to go with
pristine source tarballs and patches / spec file changes to make it work, not
to "fix" the tarball). It's also much less painful to do updates with.
Regards,
--
Conrad Meyer <konrad(a)tylerc.org>
5660
days inactive
5663
days old
rpmfusion-developers@lists.rpmfusion.org
7 comments
5 participants
participants (5)
-
Chris Nolan -
Conrad Meyer -
Hans de Goede -
Mario Chacon -
Thorsten Leemhuis