<br>No dia Sexta-feira, 13 de Janeiro de 2012, Phil <a href="mailto:Perryphil@elrepo.org">Perryphil@elrepo.org</a> escreveu:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 13/01/12 00:29, Nelson Marques wrote:<br>
&gt; Hi all,<br>
&gt;<br>
&gt; I&#39;m a Enterprise Linux user and I do maintain a few a packages for personal<br>
&gt; usage (and I&#39;m also a casual client from a few kernel modules on ELREPO).<br>
&gt; What would be the best way to submit a few packages?<br>
&gt;<br>
&gt; NM<br>
&gt;<br>
<br>
Hi Nelson,<br>
<br>
Welcome to elrepo.<br>
<br>
There are a number of ways you can contribute depending upon your<br>
experience and how involved you wish to get:<br></blockquote><div><br></div><div>Hi Phil,</div><div><br></div><div>Well, I&#39;m far from being the supra-sumo packager and most of my experience is actually around (open)SUSE Linux where I maintain a few packages and projects, though more oriented to the GNOME Desktop Environment.</div>
<div><br></div><div>I don&#39;t have extensive experience for Fedora/RHEL as a packager (though I do work with it for the past 12 years), but I think I can manage :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
1. You could put in an RFE request at <a href="http://elrepo.org/bugs" target="_blank">elrepo.org/bugs</a> and ask one of the<br>
existing packagers/developers to pick up the package.<br><br>
2. You could develop/maintain the package yourself and contribute it via<br>
our github repository and have one of the developers build and sign it<br>
for you and push it into the repo. See here:<br>
<br>
<a href="https://github.com/elrepo/packages/" target="_blank">https://github.com/elrepo/packages/</a><br>
<br>
3. Finally you could become an elrepo developer, and build/maintain the<br>
package yourself on the elrepo build systems, then only requiring an<br>
elrepo admin to sign and push the finished packages.<br>
<br>
All of which hopefully provides enough options to suit most needs.<br></blockquote><div><br></div><div>As long as reviews/commits are done in less time than EPEL, that&#39;s cool with me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Please keep in mind elrepo is primarily a repository for packages that<br>
provide improved hardware support for RHEL. These will mostly be kernel<br>
driver (kmod) packages. We only provide non-kmod packages where there is<br>
a very specific need such as an updated lm_sensors package required to<br>
support some hwmon kmod drivers, or some Xorg drivers in reqular RPM<br>
packages. All other packages would be better maintained in other<br>
dedicated repositories such as rpmforge (repoforge) or EPEL.<br></blockquote><div><br></div><div><br></div><div>Another question, for example, I would like to submit an updated package of DAHDI (system space and userland) which is somehow more complete than the current that you offer and has been properly tested. As some might be aware, this kernel module is used by Asterisk (either to load hardware drivers or a dummy/pseudo software driver). Your current package has a few nasty flaws which I can point:</div>
<div><br></div><div> * It doesn&#39;t provide the udev rules which has a dreadful impact on the system: devices are created owned by root:root and using 0600 permissions, which makes it rather unusable with Asterisk. It should be owned by user &#39;asterisk&#39; and group &#39;asterisk&#39; and created with permissions 0660 (upstream default). If people want to use it for the pseudo driver, there&#39;s a huge change it&#39;s not gonna work &#39;out of the box&#39; without some tinkering (ex: hack the dahdi-tools sysv init scripts to change the permissions). If you use real hardware, you don&#39;t ship with the firmware, leading to another problem.</div>
<div><br></div><div>Would an updated (2.4.1.2 for kmod and 2.4.1 for tools) package which provides a more complete set of options and which is actually according to Red Hat packaging rules (the current one does&#39;t offer the dahdi-kmod-common which is mandatory according to Fedora EPEL documentation) be of any interest?</div>
<div><br></div><div>I am ready to submit at least this package soon. I could submit to EPEL, but EPEL reviews take way too much time and I have a load of packages pending there.</div><div><br></div><div>NM</div><div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hope that helps.<br>
<br>
Regards,<br>
<br>
Phil<br>
_______________________________________________<br>
elrepo-devel mailing list<br>
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;elrepo-devel@lists.elrepo.org&#39;)">elrepo-devel@lists.elrepo.org</a><br>
<a href="http://lists.elrepo.org/mailman/listinfo/elrepo-devel" target="_blank">http://lists.elrepo.org/mailman/listinfo/elrepo-devel</a><br>
</blockquote><br><br>-- <br>Nelson Marques<br><br>/* <a href="http://www.marques.so" target="_blank">http://www.marques.so</a><br>   <a href="mailto:nmo.marques@gmail.com" target="_blank">nmo.marques@gmail.com</a> */<br>