I subscribed to rss feeds to track x86 changes. However it displays news about other platforms. Go to URL http://packages2.gentoo.org/feed/arch/x86/stable You'll see mostly ppc64 packages instead of x86: app-text/hunspell-1.1.9 27 Nov 2007; Markus Rothe (corsair) hunspell-1.1.9.ebuild:Added ~ppc64 app-editors/emacs-22.1-r3 27 Nov 2007; Raúl Porcel (armin76) emacs-21.4-r14.ebuild,emacs-22.1-r3.ebuild:alpha/ia64/sparc stable
Invalid. Those packages have the x86 stable keyword, so they are included in the feed. Sure the change in this case did not affect the keyword, but that is not always teh case.
Sorry, I didn't get it. Let's take an example. I have received a notification today that x86 sys-kernel/gentoo-sources-2.6.22-r9 is stable. However, it got stable for ppc, and stabilized for x86 platform on 29 Oct 2007. In my opinion I should not receive any news if it's not about x86.
The feeds are not about the changes in keywords, but rather all packages that have that keyword. Consider if a commit is made to an already x86-stable package, that is a build-fix because of a breakage in a dependency. This does not require a revision bump, and it is still news of interest.
Well, that's the thing. If you have a look at diff http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-kernel/gentoo-sources/gentoo-sources-2.6.22-r9.ebuild?r1=text&tr1=1.5&r2=text&tr2=1.4&diff_format=h you'll find that only ppc64 flag has changed. So it's not build-fix for x86 ebuild and I should not see this change in x86-stable new feed. btw, I have filed that bug report because it was working as expected with old (before Aug) packages.g.o. Am I missing something?..
You're not getting it. The feed is NOT a) "new packages that have moved to stable x86". It's b) "changes to any package that are in stable x86 before or after the commit". This is because detecting what if the change is relevant to any given architecture is non-trivial. Say it included a build-fix behind an if ppc64; ... fi block, we'd have to parse the ebuild to know about it, and moreover, if it was an change applied globally, it could still break the existing stuff. The old version may have worked like a), but it's not a feature for feature identical site, and the old RSS feeds were never strongly defined - absolutely nowhere on the old site did it say that they were only those where the keyword had changed from unstable to stable.
thanks for the explanation, I understand non-trivial task in creating a). But you are wrong about old site. It was absolutely clear defined somewhere in www.gentoo.org/feeds (?) all feeds and the reason of each feed. It was something like: http://packages.gentoo.org/archs/{x86,amd,ppc,ppc64,etc}/{testing,stable}/{gentoo_simple, gentoo}.rss The page is gone now (or I can't find it), but I still subscribed on old rss: http://packages.gentoo.org/archs/x86/stable/gentoo_simple.rss http://packages.gentoo.org/archs/x86/testing/gentoo_simple.rss Now, let's have a look on http://gentoo-portage.com/RSS_Listing They have RSS for all arches too. But x86 arch, for example, displays new stable ebuilds only. Here is description: [quote] http://gentoo-portage.com/RSS/Newest/x86 The newest ebuilds to portage that are under the keyword: x86 [/quote] It does make sense. Can we have something like that on p.g.o? Could it be some other way to track arches changes instead of just parsing ebuilds?..
This is the source code to the original page that listed the feeds: http://sources.gentoo.org/viewcvs.py/gentoo/src/packages/genrsslist.py?rev=1.3&sortby=date&only_with_tag=v1_3&view=markup It does not contain the description you claim was there. The closest was the RSS rel links in the page header, generated here: http://sources.gentoo.org/viewcvs.py/gentoo/src/packages/mksite.py?rev=1.1.2.6&sortby=date&only_with_tag=v1_3&view=markup Which had a description in the form of "Portage Updates for $ARCH (stable)" Neither of those state that they are only packages that are 'newly stable'. I've added your request to the TODO list for packages2 - the site is very low on my priorities list at the moment, because there are other more pressing issues. I'll get to it when I get to it.
Thanks. Actually, it should be very trivial to implement a). We just have to track a keyword change for that version of ebuild. If it were some small changes after that (like dep-fixes), which doesn't require a revision bump then it's not so important and shouldn't be in feeds news. That would fix my problem and won't display changes in other platforms.
Please leave this bug alone now. The TODO list is in the source code, and will be done when it's done. It's trivial as a concept, but it is NOT trivial with some of the existing data decisions that were made.
