Spec URL: http://deji.fedorapeople.org/compat-tracker.spec SRPM URL: http://deji.fedorapeople.org/compat-tracker-0.6.96-1.fc13.src.rpm Description: Tracker is a powerful desktop-neutral first class object database, tag/metadata database, search tool and indexer. It consists of a common object database that allows entities to have an almost infinite number of properties, metadata (both embedded/harvested as well as user definable), a comprehensive database of keywords/tags and links to other entities. THIS PACKAGE ONLY PROVIDES COMPATIBILITY FOR APPLICATIONS AND LIBRARIES THAT DEPENDS ON THE TRACKER-0.6 SERIES API. NOTICE: The main aim of this package proposal is to provide support for application(s) within Fedora that depend on the tracker-0.6.x series APIs, while the main tracker package itself is updated to the latest 0.7/0.8 series. The 0.7/0.8 series is in a lot ways a rewrite of tracker which provides substantial improvements to the operation of tracker over the 0.6.x series.
I get the following error when trying to rebuild the srpm: Processing files: compat-tracker-debuginfo-0.6.96-1.fc13.i686 Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/maxx/rpmbuild/BUILDROOT/compat-tracker-0.6.96-1.fc13.i386 error: Installed (but unpackaged) file(s) found: /usr/lib/deskbar-applet/modules-2.20-compatible/tracker-module.py /usr/lib/deskbar-applet/modules-2.20-compatible/tracker-module.pyc /usr/lib/deskbar-applet/modules-2.20-compatible/tracker-module.pyo
(In reply to comment #1) > I get the following error when trying to rebuild the srpm: > > Processing files: compat-tracker-debuginfo-0.6.96-1.fc13.i686 > Checking for unpackaged file(s): /usr/lib/rpm/check-files > /home/maxx/rpmbuild/BUILDROOT/compat-tracker-0.6.96-1.fc13.i386 > error: Installed (but unpackaged) file(s) found: > /usr/lib/deskbar-applet/modules-2.20-compatible/tracker-module.py > /usr/lib/deskbar-applet/modules-2.20-compatible/tracker-module.pyc > /usr/lib/deskbar-applet/modules-2.20-compatible/tracker-module.pyo This error does not (and wouldn't have) occur in koji (or clean mock) builds because we don't buildrequires deskbar-applet. You most likely have deskbar-applet installed on the system where you rebuild the srpm. I will explicitly disable build the deskbar module in the next revision of the srpm.
After removing deskbar-applet-devel it now correctly compiles on my system. Running rpmlint gives the following output: compat-tracker.i686: W: spelling-error Summary(en_US) Compatibilty -> Compatibility, Compatibly, Compatible compat-tracker.i686: W: spelling-error %description -l en_US metadata -> meta data, meta-data, metatarsus compat-tracker.i686: W: spelling-error %description -l en_US infinte -> infinite, infinity, infinitive compat-tracker.i686: W: spelling-error %description -l en_US abiword -> afterword, Abidjan, abiding compat-tracker.i686: W: no-version-in-last-changelog compat-tracker.i686: W: non-conffile-in-etc /etc/ld.so.conf.d/tracker-0.6-i386.conf compat-tracker.i686: W: devel-file-in-non-devel-package /usr/lib/tracker/libtracker-db.so compat-tracker.i686: W: devel-file-in-non-devel-package /usr/lib/tracker/libstemmer.so compat-tracker.i686: W: devel-file-in-non-devel-package /usr/lib/tracker/libtracker-data.so compat-tracker.i686: W: devel-file-in-non-devel-package /usr/lib/tracker/libtracker-common.so compat-tracker.i686: W: devel-file-in-non-devel-package /usr/lib/tracker/libtracker-module.so compat-tracker-debuginfo.i686: W: no-version-in-last-changelog compat-tracker-devel.i686: W: no-version-in-last-changelog compat-tracker-devel.i686: W: no-documentation 3 packages and 0 specfiles checked; 0 errors, 14 warnings. They are mainly minor issues however it would be nice to add the version number to the changelog and fix the "Compatibilty" spelling error. As I read the -devel guidelines (https://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages) I guess the .so files are fine in the main package as they are internal to tracker itself. The package succesfully builds in koji. In regards to the naming it appears to me that it should really be called tracker0696 to comply with the naming guidelines (see https://fedoraproject.org/wiki/Packaging/NamingGuidelines#MultiplePackages and http://lists.fedoraproject.org/pipermail/packaging/2009-August/006431.html). After building I installed compat-tracker and did a yum install paperbox which went fine. So the package works in that regard. However upon starting paperbox the trackerd-daemon from compat-tracker started up and began indexing my files - alongside the version of tracker 0.8 I already had running. And due to the way the compat-tracker package is made I didn't even have the old command-line tools to check the status and more of trackerd. My suggestion would be to at least very, very clearly state that by installing this package you will end up having two different indexers running - which will most likely bring any system to its knees. Given that it is most likely only paperbox that will require this package I think it would be a good idea to make a plan for either bringing paperbox up to the new version of tracker or deprecate paperbox in the near future.
(In reply to comment #3) > > They are mainly minor issues however it would be nice to add the version number > to the changelog and fix the "Compatibilty" spelling error. > Fixed. > > In regards to the naming it appears to me that it should really be called > tracker0696 to comply with the naming guidelines (see > https://fedoraproject.org/wiki/Packaging/NamingGuidelines#MultiplePackages and > http://lists.fedoraproject.org/pipermail/packaging/2009-August/006431.html). > I was trying to avoid using a name that confuses it with the actual tracker package (as it is a package that users might try to find and install as opposed to a library that's just pulled in to satisfy dependencies). > After building I installed compat-tracker and did a yum install paperbox which > went fine. So the package works in that regard. However upon starting paperbox > the trackerd-daemon from compat-tracker started up and began indexing my files > - alongside the version of tracker 0.8 I already had running. And due to the > way the compat-tracker package is made I didn't even have the old command-line > tools to check the status and more of trackerd. > > My suggestion would be to at least very, very clearly state that by installing > this package you will end up having two different indexers running - which > I've made this to explicitly 'Conflicts' with the actual/latest tracker package. As a result of this, I've re-added some files that were not package earlier to prevent simultaneous installation conflict with tracker. > Given that it is most likely only paperbox that will require this package I > think it would be a good idea to make a plan for either bringing paperbox up to > the new version of tracker or deprecate paperbox in the near future. That's exactly why this package was created. Paperbox upstream doesn't have plans to update to newer tracker API (not to continue the app development); and the Fedora maintainer is not willing to deprecate it yet. Update files at; Spec URL: http://deji.fedorapeople.org/compat-tracker.spec SRPM URL: http://deji.fedorapeople.org/compat-tracker-0.6.96-4.fc13.src.rpm Thanks.
I don't see any blocker for this package, I will do a formal review soon
But first, please provide the full list of packages that still depend on tracker-0.6.x.
(In reply to comment #6) > But first, please provide the full list of packages that still depend on > tracker-0.6.x. See https://bugzilla.redhat.com/show_bug.cgi?id=569302#c12 and https://bugzilla.redhat.com/show_bug.cgi?id=569302#c14
on my system, here is what i get : repoquery --whatrequires tracker rygel-tracker-0:0.5.2-1.fc13.i686 rygel-tracker-0:0.5.0-1.fc13.i686 tracker-search-tool-0:0.6.96-4.fc13.i686 catfish-engines-0:0.3.2-3.fc12.noarch tracker-devel-0:0.6.96-4.fc13.i686
i don't think paperbox is an issue since it doesn't even build
(In reply to comment #9) > i don't think paperbox is an issue since it doesn't even build It doesn't really need a rebuild, it works as it is now. However updating tracker from 0.6.x to 0.8.x will break it. Since it is already in the repo, it needs to be taken care of. See the daily rawhide report's broken dep list for instance (paperbox-0.4.4-2.fc12.i686 requires libtrackerclient.so.0). Try 'repoquery --whatrequires --alldeps tracker' to see the full list.
(In reply to comment #10) > (In reply to comment #9) > > i don't think paperbox is an issue since it doesn't even build > > It doesn't really need a rebuild, it works as it is now. However updating > tracker from 0.6.x to 0.8.x will break it. Since it is already in the repo, it > needs to be taken care of. See the daily rawhide report's broken dep list for > instance (paperbox-0.4.4-2.fc12.i686 requires libtrackerclient.so.0). I am talking about F-13 only. http://koji.fedoraproject.org/koji/buildinfo?buildID=158025
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > i don't think paperbox is an issue since it doesn't even build > > > > It doesn't really need a rebuild, it works as it is now. However updating > > tracker from 0.6.x to 0.8.x will break it. Since it is already in the repo, it > > needs to be taken care of. See the daily rawhide report's broken dep list for > > instance (paperbox-0.4.4-2.fc12.i686 requires libtrackerclient.so.0). > > I am talking about F-13 only. > > http://koji.fedoraproject.org/koji/buildinfo?buildID=158025 Yes it currently doesn't build but it exists in the F-13 repo (as paperbox-0:0.4.4-2.fc12).
repoquery --whatrequires --alldeps tracker rygel-tracker-0:0.5.0-1.fc13.i686 tracker-search-tool-0:0.6.96-4.fc13.i686 catfish-engines-0:0.3.2-3.fc12.noarch tracker-devel-0:0.6.96-4.fc13.i686 rygel-tracker-0:0.5.2-1.fc13.i686 paperbox-0:0.4.4-2.fc12.i686
the maintainer of paperbox should fix the build issue, because it is unacceptable for a package to exist on a branch, while it doesn't even build on it.
(In reply to comment #14) > the maintainer of paperbox should fix the build issue, because it is > unacceptable for a package to exist on a branch, while it doesn't even build on > it. That's a completely tangent issue, please don't make it block the review of this package. It is very important that I can update tracker to 0.8.x for F-13 (the 0.6.x is really not good for user experience).
I am interested also in seeing tracker-0.8.x in F-13, but without seeing a real need for this package, i don't see a reason to approve it : - catfish is dead upstream - catfish can be used without tracker - upstream paperbox is inactive for more than six months. - paperbox doesn't build on F-13 : https://bugzilla.redhat.com/show_bug.cgi?id=564997 I don't think you should care about two packages ( paperbox, catfish ) that are almost dead upstream, to push a compat package, correct me if i am wrong. I don't think also that paperbox not building in F-13 is a tangent issue, because we are all responsible for insuring Fedora QA. Conclusion : - Unless https://bugzilla.redhat.com/show_bug.cgi?id=564997 is really fixed, I don't think I will approve that package.
(In reply to comment #16) > Conclusion : > - Unless https://bugzilla.redhat.com/show_bug.cgi?id=564997 is really fixed, I > don't think I will approve that package. Which means ;) ; i. You're holding me responsible for a bug which is not mine ii. Preventing update of tracker to tracker-0.8.x in F-13, because the update rule in Fedora is not to issue an update that breaks other packages. Note that the fact that paperbox-0.4.4-1.fc13 doesn't build doesn't mean the 'paperbox' package is broken (ATM), the version currently in F-13 repo works as it was intended. iii. Reducing the quality of F-13 release by denying users improvements in tracker-0.8.x (see bugz.fedoraproject.org/tracker for list of potential fixes). PS: I don't think the Fedora maintainer for paperbox is capable of fixing its current build issues and/or updating it for tracker >= 0.7. Upstream paperbox maintainer has stated he has no interest in maintaining the package anymore (personal communication), and the Fedora maintainer is not interested in deprecating it yet (really it still 'works').
(In reply to comment #17) > (In reply to comment #16) > > > Conclusion : > > - Unless https://bugzilla.redhat.com/show_bug.cgi?id=564997 is really fixed, I > > don't think I will approve that package. > > Which means ;) ; > > i. You're holding me responsible for a bug which is not mine I am not, I just want to make sure that the package that you are packaging this for is worth it. > ii. Preventing update of tracker to tracker-0.8.x in F-13, because the update > rule in Fedora is not to issue an update that breaks other packages. Packages that are worth it ( maintained upstream at least ) > Note that the fact that paperbox-0.4.4-1.fc13 doesn't build doesn't mean the > 'paperbox' package is broken (ATM), the version currently in F-13 repo works as > it was intended. It works, doesn't mean it is OK. Most probably the missing method in new gtkmm that paperbox relies on will cause trouble at some point during runtime. > iii. Reducing the quality of F-13 release by denying users improvements in > tracker-0.8.x (see bugz.fedoraproject.org/tracker for list of potential > fixes). That is another reason to wipe tracker-0.6.x off F-13. > > > PS: I don't think the Fedora maintainer for paperbox is capable of fixing its > current build issues and/or updating it for tracker >= 0.7. Upstream paperbox > maintainer has stated he has no interest in maintaining the package anymore > (personal communication), and the Fedora maintainer is not interested in > deprecating it yet (really it still 'works'). Two solutions then : ( I don't see any other ) - Patch it to build - Kill it Personal opinion : Just update to tracker-0.8.x in F-13 and let the maintainer of paperbox assume his responsibilities. I don't like the idea of creating conflicts between packages just for a single package that is dead upstream. I will try to get more information about what to do in this case from Fedora Board.
Breaking ABI breakage at this time is _forbidden_, really. i.e. If tracker is to be upgraded to 0.8 and it causes ABI breakage, compatibility package _must_ be prepared. Unless preparing compatibility package updating tracker to 0.8 on F-13 is not allowed.
> Breaking ABI breakage at this time is _forbidden_, really. Actually "breaking ABI compatibility at this time is forbidden" By the way for build issue of paperbox on F-13, please see bug 564997 comment 9
(In reply to comment #20) > > Breaking ABI breakage at this time is _forbidden_, really. > Actually "breaking ABI compatibility at this time is forbidden" > > By the way for build issue of paperbox on F-13, please see > bug 564997 comment 9 Thanks for fixing the build issue. Now there is at least one reason to ship this package
Well, if (and ONLY if) all the apps using tracker can be fixed to work with the new version, the ABI change could go in, possibly as a post-release update. But as this does not seem the case at this time, unless and until this is fixed, it is NOT possible to upgrade tracker without introducing a compat package.
On the other hand, if paperbox (and everything else using tracker) rebuilds fine against tracker 0.8, I don't see a need for this compat package at all.
running rpmlint gives the following : rpmlint *.rpm compat-tracker.i686: W: spelling-error %description -l en_US metadata -> meta data, meta-data, metatarsus compat-tracker.i686: W: spelling-error %description -l en_US infinte -> infinite, infinity, infinitive compat-tracker.i686: W: spelling-error %description -l en_US abiword -> afterword, Abidjan, abiding compat-tracker.i686: W: incoherent-version-in-changelog 0.6.96-4.1 ['0.6.96-4.fc13', '0.6.96-4'] compat-tracker.i686: W: non-conffile-in-etc /etc/ld.so.conf.d/tracker-0.6-i386.conf compat-tracker.i686: W: devel-file-in-non-devel-package /usr/lib/tracker/libtracker-db.so compat-tracker.i686: W: devel-file-in-non-devel-package /usr/lib/tracker/libstemmer.so compat-tracker.i686: W: devel-file-in-non-devel-package /usr/lib/tracker/libtracker-common.so compat-tracker.i686: W: devel-file-in-non-devel-package /usr/lib/tracker/libtracker-data.so compat-tracker.i686: W: devel-file-in-non-devel-package /usr/lib/tracker/libtracker-module.so compat-tracker.src: W: spelling-error %description -l en_US metadata -> meta data, meta-data, metatarsus compat-tracker.src: W: spelling-error %description -l en_US infinte -> infinite, infinity, infinitive compat-tracker.src: W: spelling-error %description -l en_US abiword -> afterword, Abidjan, abiding compat-tracker.src:17: W: mixed-use-of-spaces-and-tabs (spaces: line 17, tab: line 1) compat-tracker-devel.i686: W: no-documentation 4 packages and 0 specfiles checked; 0 errors, 15 warnings. please fix the incoherent version in changelog and the mixed use of tabs and spaces.
(In reply to comment #24) > running rpmlint gives the following : > ... > please fix the incoherent version in changelog and the mixed use of tabs and > spaces. Those are very trivial fixes. Please continue with the package review, I promise to apply the fix on package import (if all else is good).
I see no further issues with this package, so it is APPROVED.
(In reply to comment #26) > I see no further issues with this package, so it is APPROVED. Thanks for the review Hicham. Can you please set the appropriate fedora-review flag?
New Package CVS Request ======================= Package Name: compat-tracker Short Description: Compatibility libraries and tools for tracker-0.6.x Owners: deji Branches: F-12 F-13 InitialCC:
Why do we need this compat package at all if everything was fixed to rebuild against the current tracker? IMHO, we should just issue a grouped update with everything and forget about the compat package.
no, paperbox was fixed to rebuild with old tracker (aka 0.6.x series ), and it is the package this compat is created for.
CVS done (by process-cvs-requests.py).
Built for rawhide and F-13
Just a remark, shouldn't compat-tracker replace tracker < 0.7 ? I mean, in the spec, sthg like : Obsoletes: tracker < 0.7
(In reply to comment #33) > Just a remark, shouldn't compat-tracker replace tracker < 0.7 ? > NO. We want people to update from tracker-0.6.x to tracker-0.8.x. compat-tracker is really on there for folks who wants to use paperbox. > I mean, in the spec, sthg like : > > Obsoletes: tracker < 0.7
Ok, here is the use case that I imagine : someone is using paperbox on fedora 13 with tracker-0.6.x, he wants to install a package which depends on tracker-0.8.x, so yum will try to update tracker-0.6.x to tracker-0.8.x which will then results in a broken dependency, and a failed installation. What is the best way to make users aware of this and its solution ?
Automatically-detected soname dependencies will automatically drag in compat-tracker in that case. It should just work.
(In reply to comment #36) > Automatically-detected soname dependencies will automatically drag in > compat-tracker in that case. It should just work. You suppose that the user will **install** tracker for the first time, not **upgrade**, which will work fine of course with soname deps. I thought I was clear with my use case, but I will go again : - The user has tracker-0.6.x-x.fc13 - The user has paperbox-0.4.4-x.fc12 ( no tagged fc13 build for the moment ) - The user wants to install solang-0.4.1-6.fc13 ( which will land soon in fc13 ) : yum will try to bring tracker-0.8.x, but due to soname change, paperbox will be broken, so the transaction will be aborted. --> The user won't understand what is happening
> - The user wants to install solang-0.4.1-6.fc13 ( which will land soon in fc13 > ) : yum will try to bring tracker-0.8.x, but due to soname change, paperbox > will be broken, so the transaction will be aborted. No. Due to the soname change, yum will notice that paperbox needs compat-tracker and drag it in automatically. Try it. This is handled perfectly fine in yum.
(In reply to comment #38) > > - The user wants to install solang-0.4.1-6.fc13 ( which will land soon in fc13 > > ) : yum will try to bring tracker-0.8.x, but due to soname change, paperbox > > will be broken, so the transaction will be aborted. > > No. Due to the soname change, yum will notice that paperbox needs > compat-tracker and drag it in automatically. Try it. This is handled perfectly > fine in yum. Thanks Kevin, that would cause a conflict which is more informative than the supposed broken deps.
What conflict? You'd just end up with both tracker and compat-tracker installed, as required in that setup.
(In reply to comment #40) > What conflict? You'd just end up with both tracker and compat-tracker > installed, as required in that setup. No compat-tracker and tracker can't be installed both as there is an explicit conflict introduced by compat-tracker against tracker > 0.7 See in the compat-tracker.spec : ********************************** Conflicts: tracker >= 0.7 ********************************** Reason why Deji opted to introduce that conflict is in comment #4
Then this package should never have passed review! It is completely unacceptable for a compatibility package to conflict with the main version. (Conflicts in -devel are tolerated for compat packages, but this is about a runtime conflict.) It means you cannot use paperbox if you use anything which requires the current tracker and pretty much defeats the point of having this compat package at all. > I've made this to explicitly 'Conflicts' with the actual/latest tracker > package. As a result of this, I've re-added some files that were not package > earlier to prevent simultaneous installation conflict with tracker. That's not a proper solution, sorry.
(In reply to comment #42) > Then this package should never have passed review! > > It is completely unacceptable for a compatibility package to conflict with the > main version. (Conflicts in -devel are tolerated for compat packages, but this > is about a runtime conflict.) It means you cannot use paperbox if you use > anything which requires the current tracker and pretty much defeats the point > of having this compat package at all. > I think I've tried to make it clear throughout the review that this package is essentially for paperbox. We needed to update tracker to tracker-0.8.x (tracker-0.6.x is just not good), and paperbox can't be made to work with tracker >= 0.7. IMO, paperbox needs to be dropped; most (nearly all) of its functionalities are handled by the tracker-search-tool and tracker's nautilus plugin, and its upstream developer had made it clear he had no intention of working on it anymore. I have gently asked the paperbox maintainer to obsolete it, but got no response. A lot of tracker internals have changed from 0.6.x to 0.7, they really can't work together (I can made them parallel installable). > > I've made this to explicitly 'Conflicts' with the actual/latest tracker > > package. As a result of this, I've re-added some files that were not package > > earlier to prevent simultaneous installation conflict with tracker. > > That's not a proper solution, sorry.
I think making them parallel-installable as you initially had them would be a better solution than the Conflicts. Sure, having multiple file indexers running at the same time is a resource hog, but there's nothing stopping you from having e.g. strigi, beagle and tracker all running at the same time either. Does PaperBox require indexing in order to be functional? If not, it might make sense to just disable indexing / empty the list of directories to index by default.
(In reply to comment #42) > Then this package should never have passed review! > I was fundamentally against this package at first, but since it seems that Fesco insisted on ABI compatibility ( for a single package which is dead upstream ), instead of taking a brave action and drop paperbox, I had no choice but help introducing it. > It is completely unacceptable for a compatibility package to conflict with the > main version. (Conflicts in -devel are tolerated for compat packages, but this > is about a runtime conflict.) It means you cannot use paperbox if you use > anything which requires the current tracker and pretty much defeats the point > of having this compat package at all. I agree on this point, but having two indexers running will bring most machines to their knees as mentioned earlier, in fact only one tracker is eating enough of my cpu. > > > I've made this to explicitly 'Conflicts' with the actual/latest tracker > > package. As a result of this, I've re-added some files that were not package > > earlier to prevent simultaneous installation conflict with tracker. > > That's not a proper solution, sorry. There is still room for improvement if you have a better solution, a package that passed review doesn't mean it is perfect.
(In reply to comment #44) > Does PaperBox require indexing in order to be functional? If not, it might make > sense to just disable indexing / empty the list of directories to index by > default. That is the whole point of paperbox, rely on tracker indexing to view documents by tags and other metadata.
And to add up to this, here is how upstream paperbox responds when it comes to a trivial bug : https://bugzilla.gnome.org/show_bug.cgi?id=610804 I was really hoping fesco will react to this, but anyway, it is up to you.
> That is the whole point of paperbox, rely on tracker indexing to view documents > by tags and other metadata. There's a difference between tags, which you manually add, and automatic indexing of all files. I haven't tried the program, but judging from the UI in their screenshot, it seems to focus on tags, not so much on indexed metadata. But of course it's quite possible that disabling the automatic indexing would significantly degrade its functionality. Are you familiar with PaperBox? As for FESCo, we didn't actually vote on this because we got the impression the issue at hand was already resolved. If you want this to be addressed, please reopen the FESCo ticket or file a new one, either way with a clear proposal of what you want FESCo to decide (e.g. revoke the approval of compat-tracker and retire paperbox). Of course I can't tell you in advance whether the vote will end up in favor of your proposal or not. It also depends on how well you can make your case.
(In reply to comment #48) > > That is the whole point of paperbox, rely on tracker indexing to view documents > > by tags and other metadata. > > There's a difference between tags, which you manually add, and automatic > indexing of all files. I haven't tried the program, but judging from the UI in > their screenshot, it seems to focus on tags, not so much on indexed metadata. > But of course it's quite possible that disabling the automatic indexing would > significantly degrade its functionality. Are you familiar with PaperBox? > I don't use it, but its page says "detects your documents using tracker". What is that supposed to mean other than indexing ? > > As for FESCo, we didn't actually vote on this because we got the impression the > issue at hand was already resolved. If you want this to be addressed, please > reopen the FESCo ticket or file a new one, either way with a clear proposal of > what you want FESCo to decide (e.g. revoke the approval of compat-tracker and > retire paperbox). Of course I can't tell you in advance whether the vote will > end up in favor of your proposal or not. It also depends on how well you can > make your case. Well, I would rather respect paperbox' packager decision, he is the owner of the package after all ( if he is still alive ).
Here is one artifact : https://bugzilla.redhat.com/show_bug.cgi?id=586660
Hi Deji, Please remove the conflict with current tracker.
Deji & Hicham, I will retire paperbox tonight. I was stuck in the position as Deji rightly said of paperbox being in perfect working order apart from the new tracker release I have no way of fixing myself. As you say from informal comms and I have found out from gnome bugzilla upstream is dead. Is tracker 8 being pushed to f12 & f11? If so I will retire from there also.
Deji, Does this package have a reason to stay now ?
(In reply to comment #52) > Deji & Hicham, > > I will retire paperbox tonight. I was stuck in the position as Deji rightly > said of paperbox being in perfect working order apart from the new tracker > release I have no way of fixing myself. As you say from informal comms and I > have found out from gnome bugzilla upstream is dead. Is tracker 8 being pushed > to f12 & f11? If so I will retire from there also. There is no plan to have tracker-0.8.x in F-11, F-12 is doable but needs patches to be back-ported to gtk, nautilus, and totem. I'm already in contact with the maintainers, so it may or may not happen.
(In reply to comment #53) > Deji, > > Does this package have a reason to stay now ? No it doesn't, will get it pulled as soon as paperbox is properly dropped.
Well, we can't properly kill paperbox in released distros. I guess we could have tracker obsolete it, but it's quite harsh on users to remove their existing software with no replacement in an update!
To be clear, software can be removed from devel, and I think it can still be removed from F13 (but you need to be quick, we're entering the hard final freeze soon), but not F11 or F12.
(In reply to comment #57) > To be clear, software can be removed from devel, and I think it can still be > removed from F13 (but you need to be quick, we're entering the hard final > freeze soon), but not F11 or F12. Can you intervene on this Kevin ? Gareth expressly said he will retire it, so if someone with appropriate privilegies can do that for him it will be really nice. This will avoid an unnecessary mess on F-13+.
(In reply to comment #54) > (In reply to comment #52) > > Deji & Hicham, > > > > I will retire paperbox tonight. I was stuck in the position as Deji rightly > > said of paperbox being in perfect working order apart from the new tracker > > release I have no way of fixing myself. As you say from informal comms and I > > have found out from gnome bugzilla upstream is dead. Is tracker 8 being pushed > > to f12 & f11? If so I will retire from there also. > > There is no plan to have tracker-0.8.x in F-11, F-12 is doable but needs > patches to be back-ported to gtk, nautilus, and totem. I'm already in contact > with the maintainers, so it may or may not happen. I prefer to not touch F-12 and F-11, as it will affect the users experience.
File a ticket with rel-eng to get the stuff blocked from F13 and devel.
(In reply to comment #60) > File a ticket with rel-eng to get the stuff blocked from F13 and devel. Done already : https://fedorahosted.org/rel-eng/ticket/3684
@ Deji, Please make new tracker obsolete paperbox to insure a proper upgrade path and the best user experience.
@ Deji, and of course, retire compat-tracker
@Deji, paperbox have been blocked from F-13+, please act
I must admit I did a terrible mistake by approving this package. So my sincere apologies to all of the members of fedora community.
(In reply to comment #65) > I must admit I did a terrible mistake by approving this package. > You made it seem as if the idea behind the package is a terrible one. Anyway, you are perfectly entitled to your opinion(s). For the record, I don't regret submitting the package for review or importing it after review. In fact I'm happy its introduction helped getting tracker-0.8 into F-13, and also helped convincing paperbox maintainer that the app is no longer necessary (and thus rendering this package obsolete).
(In reply to comment #66) > You made it seem as if the idea behind the package is a terrible one. Anyway, > you are perfectly entitled to your opinion(s). I am not judging by the intents, but rather by the consequences. Anyway, I see compat-tracker is still in F-12, do you plan to push it there ?
compat-tracker now isn't (and IMHO shouldn't be) actually anywhere, the F13 update was unpushed from testing and deleted, I untagged the one Rawhide build.