Login: fedora.pl pass: fedora I am sorry but can not set anonymous access so i`d appreiate if someone could host it. Spec URL: ftp://ftp.mklich.hejnet.pl/SynapticsConfig.spec SRPM URL: ftp://ftp.mklich.hejnet.pl/SynapticsConfig-0.1.3-1.src.rpm Description: Tool written in PyQt4 for configuring touchpads. It simply creates 10-synaptics.fdi file according to user preferences. Hi, This is my first package and i`d like a sponsor please. I am developer of this app.
Is it also possible to create .conf files for the touchpad? fdi files won't be used, starting at F-13, so your programm should also create a 10-synaptics.conf file. See https://fedoraproject.org/wiki/Input_device_configuration
Thanks. I did not know about this change however my brother mentioned about Ubuntu making a switch and i thought about this in Fedora. I have to add this feature and i will. Thanks again
(I'm not a sponsor, just a fellow requestor trying to perform a peer review so that I can also get sponsored) rpmlint -v of SPECfile and SRPM: # rpmlint -v SynapticsConfig.spec SynapticsConfig-0.1.3-1.src.rpm SynapticsConfig.spec:23: W: setup-not-quiet SynapticsConfig.spec: W: no-cleaning-of-buildroot %install SynapticsConfig.src: I: checking SynapticsConfig.src:23: W: setup-not-quiet SynapticsConfig.src: W: no-cleaning-of-buildroot %install 1 packages and 1 specfiles checked; 0 errors, 4 warnings. It would appear that your .SPEC needs some cleanup.... 1. remove the %defines at the top for the version, name, release and put them directly in the corresponding tags (Name, Version, Release) 2. not 100% sure about the "unmangled_version" - suspect it needs to go away in favor of a straight "version" 3. It's complaining about the setup -n...... once you perform step 1 above, you can replace this simply with a %setup -q and the rpmlint warning disappears 4. the Source0 should be a publicly accessible URL to the source code I think rather than just the local filename 5. I think you need to leave out the Vendor tag 6. the %install section needs to clean the buildroot - rm -rf %{buildroot} This is an initial pass at the SPEC. I'll try to delve more into a review over the next day or two...
you'll need a "BuildRequires:" tag to include python and python-devel. Without it, mock will not complete properly (mock can't find python interpreter).... As-is without the BuildRequires: python python-devel ...... # mock --rebuild SynapticsConfig-0.1.3-1.src.rpm INFO: mock.py version 1.0.2 starting... State Changed: init plugins State Changed: start INFO: Start(SynapticsConfig-0.1.3-1.src.rpm) Config(fedora-12-x86_64) State Changed: lock buildroot State Changed: clean State Changed: init State Changed: lock buildroot Mock Version: 1.0.2 INFO: Mock Version: 1.0.2 INFO: enabled root cache INFO: root cache aged out! cache will be rebuilt INFO: enabled yum cache State Changed: cleaning yum metadata INFO: enabled ccache State Changed: running yum State Changed: creating cache State Changed: setup State Changed: build ERROR: Exception(SynapticsConfig-0.1.3-1.src.rpm) Config(fedora-12-x86_64) 2 minutes 1 seconds INFO: Results and/or logs in: /var/lib/mock/fedora-12-x86_64/result ERROR: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/SynapticsConfig.spec'] With the BuildRequires: python python-devel ...... # mock --rebuild SynapticsConfig-0.1.3-1.src.rpm INFO: mock.py version 1.0.2 starting... State Changed: init plugins State Changed: start INFO: Start(SynapticsConfig-0.1.3-1.src.rpm) Config(fedora-12-x86_64) State Changed: lock buildroot State Changed: clean State Changed: init State Changed: lock buildroot Mock Version: 1.0.2 INFO: Mock Version: 1.0.2 INFO: enabled root cache State Changed: unpacking root cache INFO: enabled yum cache State Changed: cleaning yum metadata INFO: enabled ccache State Changed: running yum State Changed: setup State Changed: build INFO: Done(SynapticsConfig-0.1.3-1.src.rpm) Config(default) 0 minutes 33 seconds INFO: Results and/or logs in: /var/lib/mock/fedora-12-x86_64/result
I think you're also going to need to decide if this is under GPLv2+ or GPLv3. The SPEC states GPLv2+ and a "strings" on the embedded SynapticsConfig_pl_PL.qm denotes: "Software is distributed under GPLv3 license Copyright 2009 Michal Klich" Whatever is decided, the license file needs to be included in the source and added to a %doc section in the SPECfile.
you should have a dist tag (Release: 1%{?dist} ) also they'll need a koji scratch build completed with output included in the case here.
just a little note about the %files section... the %defattr should be: %defattr(-,root,root,-) Please reference: http://fedoraproject.org/wiki/PackagingGuidelines#File_Permissions Also, please change my item #6 in my first post to be "rm -rf $RPM_BUILD_ROOT" -for the %install - either that or use the macro style suggested - but of course then you will need to change the other occurences of $RPM_BUILD_ROOT in the SPEC. They're looking for consistency - it doesn't matter which style, just that there is consistency. Please reference: http://fedoraproject.org/wiki/PackagingGuidelines#Macros
Thank you for your suggestions. I have altered my SPEC file and rebuilt SRPM file. Both are know hosted on http://rudebwoy.fedorapeople.org/. Please do not use locations from my first comment. http://rudebwoy.fedorapeople.org/SynapticsConfig.spec http://rudebwoy.fedorapeople.org/SynapticsConfig-0.1.3-1.fc12.src.rpm
Please find link to koji buld https://koji.fedoraproject.org/koji/taskinfo?taskID=2001833 And also attached build.log
Created attachment 395293 [details] koji build.log
You realize that starting with f13, this setup will no longer work, right? See: http://who-t.blogspot.com/2010/02/fedora-rawhide-and-x-server-input.html Given that, does it make sense to include this now? Or will upstream for this project set it up to work with the new /etc/xorg.conf.d/ ?
Thank you, i already know about this. Well, i am working on version that would allow to configure touchpads in F13 and i think that it would be nice to have this tool also in F12. I want to have ability to support both versions.
Is there any point in moving forward with this given that F12 goes EOL in 2 weeks and we no longer accept new F12 packages?
No, there is none.
OK, I'll close this ticket.