SRPM file: http://liangsuilong.fedorapeople.org/shutter/perl-Goo-Canvas-0.05-2.fc11.src.rpm Description: GTK+ does't has an buildin canvas widget. GooCanvas is wonderful. It is easy to use and has powerful and extensible way to create items in canvas. Just try it. For more documents, please read GooCanvas Manual and the demo programs provided in the source distribution in both perl-Goo::Canvas and GooCanvas. Shutter depends on it.
Well, ! You can base your spec file on what is created from cpanspec (in cpanspec rpm): https://fedoraproject.org/wiki/Perl/cpanspec Then some notes: - The license tag "GPL" is invalid https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#GPL_and_LGPL (looks like "GPL+ or Artistic" for this package) - Your package does not build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1270974 At least BR: perl(ExtUtils::Depends) is needed - I doubt explicit "Requires: gtk2, glib, cairo" are needed. Such library related dependencies are automatically checked by rpmbuild itself and automatically added to binary rpms. Also I guess "Requires: perl-Gtk2" is also automatically checked by rpmbuild. - Please make the sentence in %description devided into several lines. Fedora suggests one line should not contain more than 79 characters. - Please add dome documents as %doc. - The directory %{perl_vendorarch}/auto/ should not be owned by this package.
By the way please also upload the spec file so that we can browse it on the browser.
SPEC: http://liangsuilong.fedorapeople.org/shutter/perl-Goo-Canvas.spec SRPM: http://liangsuilong.fedorapeople.org/shutter/perl-Goo-Canvas-0.05-3.fc10.src.rpm I have uploaded a new RPM to my fedorapeople's space. Now I just build these packages on my local machine. Because I has not a high-rated Internet connection. It takes me too much time to wait mock or koji system to build a package. I tried to run mock once. But mock had run the processor of yum for more than 2 hours. The yum of mock was still running. Later I killed mock. I do not know why mock takes so much time to run yum and it seemed that the program had crashed. This is the reason that I can not use mock or koji system. You said that - The directory %{perl_vendorarch}/auto/ should not be owned by this package. I think it is needed by this package. Because I removed this directory from %file. Rpmbuild will failed to build this package, Therefore, We can not delete this directory.
Looks much better. Some points * Explicit Requires: ----------------------------------------------------- Requires: perl(Cairo) >= 1.00 Requires: perl(ExtUtils::Depends) >= 0.2 Requires: perl(ExtUtils::PkgConfig) >= 1.0 Requires: perl(Glib) >= 1.103 Requires: perl(Gtk2) >= 1.100 Requires: gtk2, glib, cairo ----------------------------------------------------- - All of these should be removed. Such perl module related dependencies and library related dependencies are automatically detected by rpmbuild itself. (By the way, I think perl(ExtUtils::Depends), perl(ExtUtils::PkgConfig) is really unneeded) * Directory ownership issue - This package should not own the following directories _themselves_ ----------------------------------------------------- %{_bindir}/ %{_mandir}/man3/ %{_mandir}/man1/ %{perl_vendorarch}/auto/ ----------------------------------------------------- ! Note For example, this package should own %_bindir/perlmine.pl, however should not own the directory %_bindir itself. i.e. change the %files entry to %{_bindir}/* or so. CCing to spot: To spot: This package contains a perl script named "/usr/bin/perltetris.pl". Is this allowed on Fedora?
Ehhh. The rule about trademarks is that the program cannot refer to itself as the trademark in a user visible way. Except for the documentation, the only references to the "Tetris" trademark are in code functions or filenames, which is not a problem. The documentation would need to be changed, and since it refers to the filename, the filename needs to be changed as well. However, it is worth noting that the perltetris.pl did not work for me in rawhide. It may be safer to omit it.
ping?
Mamoru Tasaka I am so sorry that I am busy for studying in the university. And the school network is so bad that I can not connect to this page. As I see, perltetris.pl is running well on my Fedora. This is no reason to omit it. And the other users told me it is OK to them. So if we remove it, and Shutter can not run because of omitting this file, we will add it again. I think it does not need to do it.
new SRPM http://liangsuilong.fedorapeople.org/shutter/perl-Goo-Canvas-0.05-4.fc10.src.rpm SPEC http://liangsuilong.fedorapeople.org/shutter/perl-Goo-Canvas.spec I do not omit the perltetris.pl, because I think that it is OK on Fedora 10. And no netizen tell me that it can not run on their Fedora.
perltetris.pl definitely does not work in rawhide (x86_64): [spot@velociraptor ~]$ /usr/bin/perltetris.pl GLib-GObject-WARNING **: cannot derive `GooCanvasWidgetAccessible' from non-fundamental parent type `GooCanvasItem' at /usr/bin/perltetris.pl line 761, <DATA> line 35. GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed at /usr/bin/perltetris.pl line 761, <DATA> line 35. GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed at /usr/bin/perltetris.pl line 761, <DATA> line 35. CRITICAL **: atk_object_initialize: assertion `ATK_IS_OBJECT (accessible)' failed at /usr/bin/perltetris.pl line 761, <DATA> line 35. You also have not resolved the legal issue here. There are two ways you can resolve it: 1) Remove perltetris.pl (and the perltetris.pl manpage) from the package. 2) Rename perltetris.pl (and the perltetris.pl manpage) to something that does not contain the trademark "Tetris", and go through both files and remove the trademark "Tetris" from every user visible location. This would mean that you'd need to take it out entirely from the manpage. I can't advise you on where it needs to come out of the .pl file, because, well, it doesn't work for me.
(In reply to comment #9) > perltetris.pl definitely does not work in rawhide (x86_64): > > [spot@velociraptor ~]$ /usr/bin/perltetris.pl > GLib-GObject-WARNING **: cannot derive `GooCanvasWidgetAccessible' from > non-fundamental parent type `GooCanvasItem' at /usr/bin/perltetris.pl line 761, > <DATA> line 35. > GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' > failed at /usr/bin/perltetris.pl line 761, <DATA> line 35. > GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT > (object_type)' failed at /usr/bin/perltetris.pl line 761, <DATA> line 35. > CRITICAL **: atk_object_initialize: assertion `ATK_IS_OBJECT (accessible)' > failed at /usr/bin/perltetris.pl line 761, <DATA> line 35. Well, - Confirmed that perltetris.pl works with F-10 goocanvas, does not work with F-11 goocanvas (I am using i586) - Even demo/widgets-demo in goocanvas 0.13 tarball does not work and this shows the same warnings, where widgets-demo in goocanvas 0.10 tarball (used on F-10) works. Filed against goocanvas (bug 497274)
Again: (In reply to comment #9) > perltetris.pl definitely does not work in rawhide (x86_64): Would you test if perltetris.pl works if you have "Assistive Technologies" disabled? (although I don't know what at-spi exactuly does, disabling "Assistive Technologies" works).
Mamoru Tasaka Is your mean that the latest goocanvas causes perltetris.pl does not work. Perl on my F-10: If I type /usr/bin/perltetris.pl into terminal, perltetris.pl will show a GUI window. It looks running well. Terminal do not show any error messages. If I close the window, terminal will show many messages. You see: [fedora@fedora-desktop ~]$ /usr/bin/perltetris.pl Use of uninitialized value $config_file in -e at /usr/bin/perltetris.pl line 1135, <DATA> line 35. Use of uninitialized value $config_file in concatenation (.) or string at /usr/bin/perltetris.pl line 1155, <DATA> line 35. Use of uninitialized value $config_file in concatenation (.) or string at /usr/bin/perltetris.pl line 1155, <DATA> line 35. Can't create file : 没有那个文件或目录 at /usr/bin/perltetris.pl line 1155, <DATA> line 35. END failed--call queue aborted, <DATA> line 35. PS："没有那个文件或目录" means No that files or directories.
Created attachment 341238 [details] Patch to remove warnings on perltetris.pl exit (In reply to comment #12) > Is your mean that the latest goocanvas causes perltetris.pl does not work. I guess so. Once bug 497274 is resolved perltetris.pl should work also on rawhide. > If I close the window, terminal will show many messages. The attached patch should remove these messages.
Mamoru Tasaka Your diff file seems not to be patched into the source code. the terminal showed me that: [fedora@fedora-desktop SPECS]$ rpmbuild -ba perl-Goo-Canvas.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.PE41w0 + umask 022 + cd /home/fedora/rpmbuild/BUILD + cd /home/fedora/rpmbuild/BUILD + rm -rf Goo-Canvas-0.05 + /usr/bin/gzip -dc /home/fedora/rpmbuild/SOURCES/Goo-Canvas-0.05.tar.gz + /bin/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd Goo-Canvas-0.05 + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #0 (perltetris_pl-undefined.diff):' Patch #0 (perltetris_pl-undefined.diff): + /bin/cat /home/fedora/rpmbuild/SOURCES/perltetris_pl-undefined.diff + /usr/bin/patch -s -p1 --fuzz=0 missing header for unified diff at line 3 of patch The text leading up to this was: -------------------------- |--- perltetris.pl.orig 2009-04-23 03:22:43.000000000 +0900 |+++ perltetris.pl 2009-04-25 03:34:38.000000000 +0900 -------------------------- File to patch: The process is still stopping at here until I press Ctrl+C.
Please check the header of the patch, not -p1 patch.
How should I use your patch? I really do not know. I find that line 3 and line 12 of the patch lack something, Could you help me?
Just use -p0, like: $ cd bin/ $ patch -p0 -b --suffix .warning < MY_PATCH
Mamoru Tasaka Thank you. Your patch works so well. The koji build is excellent. https://koji.fedoraproject.org/koji/taskinfo?taskID=1368171
Well * Please address the issues of - directory ownership (mentioned in my comment 4) - and changing "tetris" word on script name and in documents (mentioned in spot's comment 5) * About patching ------------------------------------------------------- patch -p0 -b --suffix .warning < %{SOURCE1} ------------------------------------------------------- - This can be replaced by ------------------------------------------------------- %patch1 -p0 -b .warning ------------------------------------------------------- * Make build log more verbose - This package also shows build log like: ------------------------------------------------------- 77 /usr/bin/perl -MExtUtils::Command -e mkpath blib/lib/Goo/Canvas 78 [ CC xs/goocanvas.c ] 79 [ CC xs/goocanvasbounds.c ] 80 [ CC xs/goocanvasellipse.c ] 81 [ CC xs/goocanvasgroup.c ] ------------------------------------------------------- which is not so useful. Please make build.log more verbose, to show if Fedora specific compilation flags are correctly honored, for example. For this package the following works. ------------------------------------------------------- make %{?_smp_mflags} NOECHO= ------------------------------------------------------- And please change the release number.
(In reply to comment #20) > - and changing "tetris" word on script name and > in documents (mentioned in spot's comment 5) Is your mean that I should rename perltetris.pl as tetris.pl? I do not think it is needed, Because if it runs well, we will not need to change anything. Also I think that we just need to add what we change into Changelog is OK..
(In reply to comment #21) > (In reply to comment #20) > > - and changing "tetris" word on script name and > > in documents (mentioned in spot's comment 5) > > Is your mean that I should rename perltetris.pl as tetris.pl? > > I do not think it is needed, Because if it runs well, we will not need to > change anything. This is not related to whether this program works well or not, but to legal issue (see spot's comment 5)
OK.. But after I rename perltetris.pl, Should I create symbolic link whose name is perltetris.pl to connect the new file. I think that if some applications need perltetris.pl, it will appear some errors.
(In reply to comment #23) > OK.. > > But after I rename perltetris.pl, Should I create symbolic link whose name is > perltetris.pl to connect the new file. No. In such cases the application using this perl script needs modification on Fedora.
Mamoru Tasaka If patch -p0 -b --suffix .warning < %{SOURCE1} is replaced by %patch1 -p0 -b .warning , koji will appear errors. You see: https://koji.fedoraproject.org/koji/getfile?taskID=1378575&name=build.log Here is my SPEC file and SRPM: http://liangsuilong.fedorapeople.org/shutter/perl-Goo-Canvas.spec http://liangsuilong.fedorapeople.org/shutter/perl-Goo-Canvas-0.05-5.fc10.src.rpm
(In reply to comment #25) > Mamoru Tasaka > > If patch -p0 -b --suffix .warning < %{SOURCE1} is replaced by %patch1 -p0 -b > .warning > , koji will appear errors. I said so and I did not say that "cd bin/" can be dropped .... And still directory ownership issue is not addressed correctly.
Also ----------------------------------------------------- mv %{_bindir}/perltetris.pl %{_bindir}/perlfangkuang.pl ----------------------------------------------------- this is not right.
Mamoru Tasaka, Just need I replace rename with mv? and %file should like this? %files %defattr(-,root,root,-) %doc Changes goocanvas.typemap maps README %{_bindir}/* %{_mandir}/man3/ %{_mandir}/man1/ %{perl_vendorarch}/auto/
(In reply to comment #29) > Just need I replace rename with mv? - Well, I don't know what you meant here, however the problem on the my comment 27 is that after "perl pure_install" the installed scripts are actually under %buildroot%_bindir, not under %_bindir > > and %file should like this? > > %files > %defattr(-,root,root,-) > %doc Changes goocanvas.typemap maps README > %{_bindir}/* > %{_mandir}/man3/ > %{_mandir}/man1/ > %{perl_vendorarch}/auto/ - No. Still the directories %_mandir/man3 %_mandir/man1 %perl_verdorarch/auto _themselves_ are owned, which should not. Note: --------------------------------------------------- %files foo/ --------------------------------------------------- (where foo is a directory) means the directory foo/ itself and all files/directories/etc under foo/, while --------------------------------------------------- %files foo/* --------------------------------------------------- means all files/directories/etc under foo/ (if no hidden files are under foo/), but does not contain foo/ directory itself.
Mamoru Tasaka I updated a new SRPM. SPEC:http://liangsuilong.fedorapeople.org/shutter/perl-Goo-Canvas.spec SRPM:http://liangsuilong.fedorapeople.org/shutter/perl-Goo-Canvas-0.05-6.fc10.src.rpm Is it OK?
For 0.05-6: - The directory %{perl_vendorarch}/Goo/ should be owned by this package as currently no package owns this directory. - By the way it seems that latest version is 0.06. Would you upgrade your srpm?
Mamoru Tasaka I have updated perl-Goo-Canvas to 0.06, It is looks very OK! SRPM:http://liangsuilong.fedorapeople.org/shutter/perl-Goo-Canvas-0.06-1.fc11.src.rpm SPEC:http://liangsuilong.fedorapeople.org/shutter/perl-Goo-Canvas.spec koji build report: http://koji.fedoraproject.org/koji/taskinfo?taskID=1410282
you have small typo in %description
Well, again the directory %{perl_vendorarch}/Goo/ should be owned by this package, so the %files entry should be: %files .... %{perl_vendorarch}/Goo/
(In reply to comment #34) > you have small typo in %description you say that you have small tupo in %description. What do you mean? Do you mean that %description should be longer? Would I add this paragraph into %description? GTK+ does't has an buildin canvas widget. GooCanvas is wonderful. It is easy to use and has powerful and extensible way to create items in canvas. Just try it. For more documents, please read GooCanvas Manual and the demo programs provided in the source distribution in both perl-Goo::Canvas and GooCanvas. Or do you mean that I should set every line of %description longer than the present version?
no, you have "does't" and probably you mean "doesn't".
Created attachment 347924 [details] perl-Goo-Canvas 0.06-2 spec Now I upload the latest spec file Jan Klepek, Now is %description right? Mamoru Tasaka, Now I correct %file %{perl_vendorarch}/Goo/ is here.
(In reply to comment #38) > Created an attachment (id=347924) [details] > perl-Goo-Canvas 0.06-2 spec > > Now I upload the latest spec file > > Jan Klepek, > > Now is %description right? Did you uploaded correct version? I see in your attachment "does't"
Here is the latest spec file. SPEC:http://liangsuilong.fedorapeople.org/shutter/perl-Goo-Canvas.spec If there are errors in %description, Could you teach me how to write it in right way? I seems not to know how I should write it.
Okay! -------------------------------------------------------- This package (perl-Goo-Canvas) is APPROVED by mtasaka --------------------------------------------------------
New Package CVS Request ======================= Package Name: perl-Goo-Canvas Short Description: Perl interface to the GooCanvas Owners: liangsuilong Branches: F-10 F-11 devel InitialCC: liangsuilong Cvsextras Commits: yes
CVS done.
Now I have imported the source code to CVS repository and try to build it on koji. It is OK on dist-f11 and devel But not dist-f10. The reason is lack of BR:gtk2-devel I think. Should I add it into spec file? Build of perl-Goo-Canvas-0.06-2 on devel, dist-f11 and dist-f10 devel:http://koji.fedoraproject.org/koji/buildinfo?buildID=111197 F-11:http://koji.fedoraproject.org/koji/buildinfo?buildID=111201 F-10:http://koji.fedoraproject.org/koji/buildinfo?buildID=111202 In fact, there is no need to add BR: gtk2-devel on F-11 and devel. But if I do not add it, It will not build on F-10 successfully. So what should I do? add it directly? As I wish, after adding BR: gtk2-devel, it is successful on F-10 http://koji.fedoraproject.org/koji/taskinfo?taskID=1427450 I upgrade the SRPM and SPEC file SRPM:http://liangsuilong.fedorapeople.org/shutter/perl-Goo-Canvas-0.06-3.fc11.src.rpm SPEC:http://liangsuilong.fedorapeople.org/shutter/perl-Goo-Canvas.spec
You can add "BR: gtk2-devel" only on F-10 branch. In that case please use "2%{?dist}.1" as release number of the spec file to make EVR (Epoch-Version-Release) path between F-10 -> F-11 work correctly: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches
Okay, now closing.