Re: upstream wants me to rename my package
On Fri, Sep 7, 2012 at 10:54 PM, Gary Gatling gsgat...@ncsu.edu wrote: If a upstream project somehow objects to someone packaging their software should you just give up and tell people that the upstream would prefer you download their self created rpms or is it considered acceptable to go ahead and package their software over their objections? He says at the end of his email: 'I'm willing to help out in any way I can, within reason, but I will also re-iterate that VirtualGL was never really designed to be integrated into an O/S distribution. Thanks for any thoughts you guys might have about this surprising reaction... The classic 0.02: Now, I don't really get the not designed to be integrated in a distro part, but since he obviously wants to offer RPMs for his project, maybe he could be interested in becoming the (co)maintainer in Fedora? Being in the distro's official repo has several advantages (exposure, easy installation, etc) that any upstream should be very keen about. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstream wants me to rename my package
I don't see the reason for someone to install and use two versions of the same thing and I think that renaming the package other than project name is a bad idea... Besides that, if the developer doesn't want that others redistribuite his program he can always change the license or become co-maintainer of the package in fedora repos. Il 07/09/2012 22:54, Gary Gatling ha scritto: Hello, I am working on a package called VirtualGL: https://bugzilla.redhat.com/show_bug.cgi?id=834127 After contacting the upstream on their mailing list, they seem obsessed with being able to install their own rprms and my package together at the same time. This seems odd / bad to me since only one vglrun could be in the path. He keeps talking about using symlinks in /opt and so forth to to somehow make my package able to co-exists with his package downloadable at: http://www.virtualgl.org/ He does want me to change the package name also. Is it too late for me to that after that package has been accepted into fedora? Here is what he says about that: In terms of naming, I would suggest naming your RPM something besides VirtualGL. If you are splitting it into multiple RPMs, then this is easy. Just ship RPMs named VirtualGL-common, VirtualGL-client, VirtualGL-utils, VirtualGL-server, VirtualGL-devel, etc., and none of them will actually be named VirtualGL. Or maybe use VirtualGL-fedora or some alternative (even lowercase virtualgl, perhaps.) If a upstream project somehow objects to someone packaging their software should you just give up and tell people that the upstream would prefer you download their self created rpms or is it considered acceptable to go ahead and package their software over their objections? He says at the end of his email: 'I'm willing to help out in any way I can, within reason, but I will also re-iterate that VirtualGL was never really designed to be integrated into an O/S distribution. Thanks for any thoughts you guys might have about this surprising reaction... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Alpha Test Compose 6 (TC6) Available Now!
2012/9/6 Andre Robatino robat...@fedoraproject.org: As per the Fedora 18 schedule [1], Fedora 18 Alpha Test Compose 6 (TC6) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5284#comment:13 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Alpha Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. Create Fedora 18 Alpha test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/5284 Current Blocker and NTH bugs: http://qa.fedoraproject.org/blockerbugs/current F18 Alpha Blocker tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752654 F18 Alpha Nice-To-Have tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752662 [1] http://jreznik.fedorapeople.org/schedules/f-18/f-18-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC6/Live/i386/ Are those TC5 images hosted there? Or just mislabeled? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstream wants me to rename my package
On Fri, 7 Sep 2012, Ken Dreyer wrote: With VirtualGL, if his main concern is that Fedora's RPMs will overwrite the ones that he sells, could he just bump the Epoch tag in his copies? This is exactly what I did with custom rpms for opendnssec that depended on proprietary PKCS#11 drivers and some different dependancies. I set the epoch to 42 and that's what they have in their private repo. It will never conflict with their RHEL/EPEL repositories. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On 09/07/2012 03:34 PM, Dan Williams wrote: And here comes the bigger question what is keeping all you networking guys from simply combine all that effort and coming up with one single network application that everybody can use happily from embedded to servers to desktop? There's room to work towards consensus on functionality, but at the moment I don't see a lot of momentum towards a Grand New Unified Plan, partially because that's how free software works. It would be great if we had one, and I'm certainly willing to entertain changes to NetworkManager that make it more capable for anyone's use-cases. Nobody thinks NM has reached perfection, least of all me. As someone who recently needed some pretty niche functionality if you ask me. I was amazed at the amount of help and open-mindedness of Dan. He helped me learn where stuff was in the tree, and gave me pseudo code. Walked me through some parts and spoon fed me other pieces of code necessary to make what I needed happen with NM. It was then merged into NetworkManager. Of any project that could potentially do all the things that are necessary, I'd vote for NM. It'd be a shame that the other projects couldn't work together towards a common goal. I can't imagine how it wouldn't be possible to get NM to the point where it does do everything one needs it to do. Especially with the lead developers it has. My 2cents. -- Nathanael d. Noblet t 403.875.4613 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 852503] Review Request: perl-Net-Radius - Object-oriented Perl interface to RADIUS
https://bugzilla.redhat.com/show_bug.cgi?id=852503
Eduardo Echeverria echevemas...@gmail.com changed:
What|Removed |Added
CC||echevemas...@gmail.com
--- Comment #1 from Eduardo Echeverria echevemas...@gmail.com ---
$ rpmlint -i perl-Net-Radius-2.103-1.fc17.src.rpm
perl-Net-Radius.src:7: W: mixed-use-of-spaces-and-tabs (spaces: line 7, tab:
line 1)
The specfile mixes use of spaces and tabs for indentation, which is a cosmetic
annoyance. Use either spaces or tabs for indentation, not both.
I am not sponsor so this is an informal review.
Package Review
==
Key:
- = N/A
x = Pass
! = Fail
? = Not evaluated
Generic
[x]: EXTRA Rpmlint is run on all installed packages.
Note: There are rpmlint messages (see attachment).
[x]: EXTRA Spec file according to URL is the same as in SRPM.
[ ]: MUST Package is licensed with an open-source compatible license and meets
other legal requirements as defined in the legal section of Packaging
Guidelines.
[x]: MUST Package successfully compiles and builds into binary rpms on at
least one supported primary architecture.
[ ]: MUST %build honors applicable compiler flags or justifies otherwise.
[x]: MUST All build dependencies are listed in BuildRequires, except for any
that are listed in the exceptions section of Packaging Guidelines.
[ ]: MUST Package contains no bundled libraries.
[ ]: MUST Changelog in prescribed format.
[ ]: MUST Sources contain only permissible code or content.
[!]: MUST Each %files section contains %defattr if rpm 4.4
Note: defattr() present in %files section. This is OK if packaging
for EPEL5. Otherwise not needed
[ ]: MUST Macros in Summary, %description expandable at SRPM build time.
[ ]: MUST Package contains desktop file if it is a GUI application.
[ ]: MUST Development files must be in a -devel package
[ ]: MUST Package requires other packages for directories it uses.
[ ]: MUST Package uses nothing in %doc for runtime.
[ ]: MUST Package is not known to require ExcludeArch.
[x]: MUST Permissions on files are set properly.
[x]: MUST Package does not contain duplicates in %files.
[ ]: MUST Package complies to the Packaging Guidelines
[x]: MUST Spec file lacks Packager, Vendor, PreReq tags.
[!]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
beginning of %install.
Note: rm -rf is only needed if supporting EPEL5
[ ]: MUST Large documentation files are in a -doc subpackage, if required.
[ ]: MUST If (and only if) the source package includes the text of the
license(s) in its own file, then that file, containing the text of the
license(s) for the package is included in %doc.
[!]: MUST License field in the package spec file matches the actual license.
Note: Checking patched sources after %prep for licenses. No licenses
found. Please check the source files for licenses manually.
[ ]: MUST Package consistently uses macro is (instead of hard-coded directory
names).
[x]: MUST Package is named using only allowed ascii characters.
[ ]: MUST Package is named according to the Package Naming Guidelines.
[ ]: MUST Package does not generate any conflict.
Note: Package contains no Conflicts: tag(s)
[ ]: MUST Package obeys FHS, except libexecdir and /usr/target.
[ ]: MUST If the package is a rename of another package, proper Obsoletes and
Provides are present.
[ ]: MUST Package must own all directories that it creates.
[ ]: MUST Package does not own files or directories owned by other packages.
[x]: MUST Package installs properly.
[ ]: MUST Package is not relocatable.
[ ]: MUST Requires correct, justified where necessary.
[x]: MUST Rpmlint is run on all rpms the build produces.
Note: There are rpmlint messages (see attachment).
[x]: MUST Sources used to build the package match the upstream source, as
provided in the spec URL.
[ ]: MUST Spec file is legible and written in American English.
[x]: MUST Spec file name must match the spec package %{name}, in the format
%{name}.spec.
[ ]: MUST Package contains systemd file(s) if in need.
[x]: MUST File names are valid UTF-8.
[x]: SHOULD Reviewer should test that the package builds in mock.
[!]: SHOULD Buildroot is not present
Note: Buildroot is not needed unless packager plans to package for EPEL5
[!]: SHOULD Package has no %clean section with rm -rf %{buildroot} (or
$RPM_BUILD_ROOT)
Note: Clean is needed only if supporting EPEL5
[ ]: SHOULD If the source package does not include license text(s) as a
separate file from upstream, the packager SHOULD query upstream to
include it.
[x]: SHOULD Dist tag is present.
[x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin,
/usr/sbin.
[ ]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q
--requires).
[ ]:
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the F-18 tree: On x86_64: perl-PDL-2.4.10-1.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-PDL-2.4.10-1.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-OpenOffice-UNO
perl-OpenOffice-UNO has broken dependencies in the F-18 tree: On x86_64: perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-OpenOffice-UNO-0.07-3.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2) perl-OpenOffice-UNO-0.07-3.fc17.i686 requires libsal_textenc.so Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-OpenOffice-UNO
perl-OpenOffice-UNO has broken dependencies in the rawhide tree: On x86_64: perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-OpenOffice-UNO-0.07-3.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2) perl-OpenOffice-UNO-0.07-3.fc17.i686 requires libsal_textenc.so Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: cpanspec
cpanspec has broken dependencies in the epel-6 tree: On x86_64: cpanspec-1.78-6.el6.noarch requires perl(Parse::CPAN::Packages) On i386: cpanspec-1.78-6.el6.noarch requires perl(Parse::CPAN::Packages) On ppc64: cpanspec-1.78-6.el6.noarch requires perl(Parse::CPAN::Packages) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Authen-Simple
perl-Authen-Simple has broken dependencies in the epel-6 tree: On ppc64: perl-Authen-Simple-0.4-5.el6.noarch requires perl(Crypt::PasswdMD5) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
