Fedora Account System
Red Hat Associate
Red Hat Customer
Spec URL: http://cassmodiah.fedorapeople.org/surf/surf.spec SRPM URL: http://cassmodiah.fedorapeople.org/surf/surf-0.3-1.fc12.src.rpm Description: surf is a simple web browser based on WebKit/GTK+. Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1912057 http://koji.fedoraproject.org/koji/taskinfo?taskID=1912071
You're requiring webkitgtk-devel for the build. Shouldn't the package itself require webkitgtk then?
No, because rpmwill detect this dependencie automatically as it is a shared lib dep on libwebkit-1.0.so.2.11.3. These deps should never be listed explicitly.
Thanks very much for pointing this out Christoph. I'm sorry for the confusion. Here's my formal review: $ rpmlint surf.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. $ rpmlint surf-0.3-1.fc12.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. $ rpmlint surf-0.3-1.fc12.x86_64.rpm surf-debuginfo-0.3-1.fc12.x86_64.rpm surf-debuginfo.x86_64: E: debuginfo-without-sources 2 packages and 0 specfiles checked; 1 errors, 0 warnings. The error is referring to the debuginfo package and can be ignored afaik. Package Review ============== Key: - = N/A x = Check ! = Problem ? = Not evaluated === REQUIRED ITEMS === [x] Package is named according to the Package Naming Guidelines [x] Specfile name matches %{name}.spec [x] Package seems to meet Packaging Guidelines [x] Package successfully compiles and builds into binary RPMs on at least one supported architecture. Tested on: Fedora 12/x86_64 [x] Rpmlint output: source RPM: empty binary RPM: empty [x] Package is not relocatable. [x] License in specfile matches actual License and meets Licensing Guidelines License: MIT [x] License file is included in %doc. [x] Specfile is legible and written in AE [x] Sourcefile in the Package is the same as provided in the mentioned Source SHA1SUM of Source: c201a48e0b0e2de573b73e286ca4feda4f6df9a8 [x] Package compiles successfully [x] All build dependencies are listed in BuildRequires [-] Specfile handles locales properly [-] ldconfig called in %post and %postun if required [-] Package owns directorys it creates [-] Package requires other packages for directories it uses. [x] Package does not list a file more than once in the %files listing [x] %files section includes %defattr and permissions are set properly [x] %clean section is there and contains rm -rf %{buildroot} [x] Macros are consistently used [x] Package contains code, or permissable content. [-] Large documentation files are in a -doc subpackage [x] Program runs properly without files listed in %doc [-] Header files are in a -devel package [-] Static libraries are in a -static package [-] Package requires pkgconfig if .pc files are present [-] .so-files are put into a -devel subpackage [-] Subpackages include fully versioned dependency for the base package [-] Any libtool archives (*.la) are removed [x] contains desktop file (%{name}.desktop) if it is a GUI application [x] Package does not own files or directories owned by other packages. [x] %{buildroot} is removed at beginning of %install [-] Filenames are encoded in UTF-8 === SUGGESTED ITEMS === [x] Package contains latest upstream version [x] Package does not include license text files separate from upstream. [-] non-English translations for description and summary [x] Package builds in mock Tested on: F12/x86_64 [x] Package should compile and build into binary RPMs on all supported architectures. tested build with koji [x] Program runs [-] Scriptlets must be sane, if used. [-] pkgconfig (*.pc) files are placed in a -devel package [-] require package providing a file instead of the file itself no files outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin are required Obviously, the dependency to dmenu is missing, please add it before requesting CVS access. Anything else is fine, very good work Simon. The package is approved.
Thank you Dominic, I will add the missing dmenu dependency before i import this. Thank you for this hint New Package CVS Request ======================= Package Name: surf Short Description: Simple web browser Owners: cassmodiah Branches: F-12 InitialCC:
CVS done (by process-cvs-requests.py)
surf-0.3-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/surf-0.3-1.fc12
surf-0.3-1.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update surf'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0684
surf-0.3-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/surf-0.3-2.fc12
surf-0.3-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
Ah, I caught this by accident, but there's another software called surf: SURF is a set of programs for generating and displaying the solvent accessible surface of a molecule. A representation of a typical protein molecule can be generated in about a second, allowing near real-time response to changes in the surface parameters. http://www.ks.uiuc.edu/Research/vmd/extsrcs/surf.tar.Z Granted, it's obscure and I have only packaged it for internal purposes (so far), but it's still a (potential) conflict.
(In reply to comment #10) > but it's still a (potential) conflict. I don't see a conflict! surf is unique in fedora pkgdb there is no review request with another software called surf! first come, first served!
Simon, your statement "first come, first served" explicitly contradicts our existing guidenline and policy on the matter. Please read the relevant guidelines: http://fedoraproject.org/wiki/Packaging:Conflicts#Potential_Conflicting_Files "We don't just try to avoid conflicts with existing packages within Fedora but also potential conflicts. This is because the first package to enter Fedora is not always the one that should take on the name. There are several scenarios in which this could come into play:" I urge you to avoid pushing this package until the conflict can be worked out.
(In reply to comment #12) > I urge you to avoid pushing this package until the conflict can be worked out. Too late. $ yum info surf Available Packages Name : surf Arch : x86_64 Version : 0.3 Release : 2.fc12 Size : 16 k Repo : updates Summary : Simple web browser URL : http://surf.suckless.org/ License : MIT Description: surf is a simple web browser based on WebKit/GTK+. http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0785
Then you have some work to do to rectify this problem.
Some more information about surf: it was written in 1992 (so it's way older than surf-the-web-browser) and while it is open source, the licence has a non-commercial clause, so it won't end up in Fedora unless the authors relicense it. However, this doesn't stop anyone from packaging it for rpmfusion or some other repository. Also surf is used by VMD, which is a popular and actively developed molecular dynamics software.
Although Simons comments sound very uncouth to me, I have to defend him on the merits: (In reply to comment #12) > Simon, your statement "first come, first served" explicitly contradicts our > existing guidenline and policy on the matter. Please read the relevant > guidelines: IMHO Simon has acted IAW the guidelines. Quote: "In the second case, where there is no known package to conflict with at this time, it is up to the packager to make a decision." By the time of the review or when pushing the package to updates, nobody was aware of the other program, so it is Simon's decision. Where we go from here now depends on how constructive the suggestions are. Jason, what do you suggest? Simon, can you talk to upstream and ask him about renaming his package?
Christoph is right. From the reviewer point of view I also didn't know there is another package named surf which possibly could conflict with the web browser surf. To avoid any further conflicts I'd suggest to rename this package and maybe also the binary to "surf-browser".
(In reply to comment #16) > Although Simons comments sound very uncouth to me, Sorry, this was not intended. Please don't interpret something in my postings. > Simon, can you talk to upstream and ask him about renaming his package? I spoke with upstream (of the browser). He knows there is another software called 'surf', but he doesn't want to rename his project. It doesn't matter to me, what's the name of the package is, so I have no problem with a renaming in Fedora, but I can't see a reason for this. The current situation is that surf is fedora incompatible. Perhaps it will never be fedora compatible, but you say I have to rename it to $(whatever), because a 3rd party repo could package surf. Sorry but this argumentation doesn't look sane to me and I can't find this kind of argumentation in the guidelines. IMHO the fact that this isn't compatible licensed for more than 16 years without amendment would disqualify surf (not the browser) for the pkgname surf in fedora. surf (the webbrowser) in other OS: Archlinux: http://aur.archlinux.org/packages.php?ID=30009 -> surf! BSD: http://www.freshports.org/www/surf/ -> surf! Debian: http://suckless.debian-maintainers.org/ http://ftp-master.debian.org/new/surf_0.3-1.html -> surf!
Just to make sure this is clear through any language barriers, in the following statement from the guidelines: "In the second case, where there is no known package to conflict with at this time, it is up to the packager to make a decision." the word "known" is a general thing. It doesn't imply that it's OK if you simply offhand don't know that there are other pieces of software with conflicting names. When you see a four letter package name with a rather common usage in English, you should at least, you know, spend a minute or two over at Google. And simply making up your own rules, like "first come, first served" or your "16 years of incompatible licensing disqualifies it for the name" isn't how it's done. Build consensus, ask FESCo. It's supposed to be a community, not you doing whatever you feel like doing. It may be that you are correct, and since surf can't be included in our distribution that there's no point in working around it. It may also be that nobody bothered to ask the surf author to relicense his code.
(In reply to comment #18) > The current situation is that surf is fedora incompatible. Perhaps it will > never be fedora compatible, but you say I have to rename it to $(whatever), > because a 3rd party repo could package surf. Sorry but this argumentation > doesn't look sane to me and I can't find this kind of argumentation in the > guidelines. Jason already quoted the important bits from the guidelines: "We don't just try to avoid conflicts with existing packages within Fedora but also potential conflicts." Not only with existing packages in Fedora -> also 3rd party
The surf that Dominik mentioned is hard to find. It has no homepage and I doubt that the existence of an unversioned tarball surf.tar.Z one some universities webspace is prove that there actually is a project/program called "surf". But to make this even more fun, there is http://surf.sourceforge.net/ We really should go for remaning this package.
Imho this is the first valid comment in this discussion! Good hint Christoph, this surf is alive, FOSS and older than surf (the brwoser) This surf is packaged in opensuse and mandriva as surf. I can't find any reason to insist on surf as pkgname! Package Change Request ====================== Package Name: surf-browser
btw, this surf is listed in archlinux as surf-ag http://aur.archlinux.org/packages.php?ID=27365 Perhaps, if surf (algebraic) comes, it should be renamed, too.. It's a good compromiss and even Dominik can use the whatever-this-surf-is-for as surf on his system. This would make all happy!
wait a minute, today is FESCO meeting. I will ask FESCO!
(In reply to comment #21) > The surf that Dominik mentioned is hard to find. It has no homepage and I doubt > that the existence of an unversioned tarball surf.tar.Z one some universities > webspace is prove that there actually is a project/program called "surf". Well, the original source is no longer available. What I gave you was the mirror (and you can find the original URL in the README). > But to make this even more fun, there is http://surf.sourceforge.net/ > We really should go for remaning this package. This is interesting. Maybe it's related to the one I mentioned. I'll have a look at the sources.
FYI, I filed a ticket so we can discuss this in today's FeSCo meeting: https://fedorahosted.org/fesco/ticket/324
FESCO decided! Package Change Request ====================== Package Name: surf-browser
Unfortunately, the procedure for name changes is a re-review. ;( It should be an easy one since this was just approved.
The bug is NEEDINFO since 2010-12-11 18:11:09 EST (see history of this bug). I think it is valid to close the issue. Feel free to reopen in case of any concerns.
The package has not been renamed and re-reviewed yet. Simon, please rename the package and submit a new review. Post the bug number here, clear the NEEDINFO flag and close this bug again. Thanks!
Almost three years without any action on this? Maybe the current maintainer can take care of the rename.
Sorry for this belated reply, I'm busy recently but I immediately read the email from bugzilla when I first received it. (In reply to Dominik 'Rathann' Mierzejewski from comment #31) > Almost three years without any action on this? Maybe the current maintainer > can take care of the rename. Ooops, I won't do that. Let me show my opinion here: I glanced and found that the timestamp of that tar archive in comment 10 was from 2005, well it's 2014 now. A nearly abandoned project if you ask me about it when I saw the first link you provided. But then Simon pointed out the aur package and I checked again, alright it's another software. Now in Fedora it's called surf-geometry, see bug 840244(I assume that you've known it, right?). Latest version of it was from 2010. Ooops again, 4 years later, this bug is still open? Surf web browser is still being developed(not rapid releasing mode). Last version was released in Oct 2013. Having a look at the search results of "surf" amid distros: ======================================================== http://pkgs.org/download/surf RED TEAM: 2 seats || OpenMandriva + ROSA. They have packaged your "surf". BLU TEAM: 6 seats (if you agree that Ubuntu is a distro actually :D), plus looking at Gentoo, they packaged the browser surf as well, but since gentoo portage is another different mechanism, I will not include it. ;) No BSD please, different world. ======================================================== You should advise surf upstream(for your "surf", if the upstream is still alive or active) to rename their project, sometimes inventing(or, excogitating, whatever) a proper name is so easy(arbitrary, isn't it?) that they even don't care about the sequel. If people enjoy formulating their ideas in few alphabets, well, let they be. I don't quite understand the plan. Rename the surf to surf-browser, then place the surf-geometry into the surf slot? I think it's impossible, RPM obsoletes will not work. It's also dangerous to place a completely different software to the same name in one single distro. Therefore I guess you all want to do: surf -> surf-browser; retire surf slot in pkgdb; do nothing with the surf-geometry. Sounds true. Wait! Why should I do this? Rationality? Just because a name conflict? Don't you think it's futile and a kind of wasting time? One sentence: "Hello everyone, why should I rename a package already in Fedora for years but can't do anything after that for the existing name created in pkgdb?" Chances are finite, first come first served, Jason tried to prove that "well it's not always right". But the fact is true, you were late. FESCo ticket is a paradox IMO again, you can't do anything to the existing "surf" after the rename. Crux here.
(In reply to Christopher Meng from comment #32) > Therefore I guess you all want to do: > > surf -> surf-browser; > retire surf slot in pkgdb; > do nothing with the surf-geometry. Yes. > Sounds true. Wait! Why should I do this? Rationality? Just because a name > conflict? Don't you think it's futile and a kind of wasting time? Yes, we should resolve the name conflict. No, it's not futile. We are distribution maintainers and if upstreams don't make reasonable name choices, we should point it out to them and fix if they don't. > One sentence: "Hello everyone, why should I rename a package already in > Fedora for years but can't do anything after that for the existing name > created in pkgdb?" > > Chances are finite, first come first served, Jason tried to prove that "well > it's not always right". But the fact is true, you were late. FESCo ticket is > a paradox IMO again, you can't do anything to the existing "surf" after the > rename. Crux here. It's not true that you can't rename an existing package. We even had cases where approved packages were removed from distribution for various reasons. It doesn't matter that I was late to spot this package (by a couple of days, no less). You are free to run for FESCo yourself if you don't agree with their decision, but ignoring it is not right. This is part of being a package maintainer. If you don't want to do this, orphan the package and let someone else pick it up.
Everyone: a) the more-obscure software now is a dead URL b) I can't find it by searching on the description quoted above c) *This* package, with the name "surf" has been in Debian with this name for almost 7 years
Yeah, debian and ubuntu both have surf the browser. And everybody knows that there's more Ubuntu users than sand on the beach.
So in bug#1327911 (where I'm unretiring Surf), I will *not* be renaming it to surf-browser. I don't see the point of it, especially when I can't even find the other stuff, and other distros already use the name "surf" to mean the browser. Today, Mageia[0], Debian[1], and Ubuntu[2] use that name for the browser. I have no good reason to rename it. [0]: https://madb.mageia.org/package/show/name/surf [1]: https://packages.debian.org/jessie/surf [2]: http://packages.ubuntu.com/wily/surf