http://dev.gentoo.org/distfile-mirroring/failure.xml is 404; horkage point seems to have been 02/06/06 going by google cache roughly (last copy it knows of). Sucker works by generating reports and shoving them in a dir, then said dir is rsync pulled from d.g.o- since dev.gentoo.org/distfile-mirroring/ is 404 (rather then 403, which is what it used to chuck since there was no index), looks like either url rewriting got screwed up, or directories were shifted around. Report generation is fine (zmedico verified it)- most likely the transfer to wood pecker left out this specific bit (first bet would be the cronjob'd rsync'ing got left out). Meanwhile, cc'ing QA- y'all probably would have use for the report for spotting folks commiting ebuilds without uploading for when upstream SRC_URI is extremely crappy (berlios.de, in this case).
I suggest we move the file from syncing on dev.g.o to www.g.o much like how the devaway stuff is. It should be a simple thing to add to the nodes for the most part. That way its much more centralized and zmedico/qa can create a page linking to it. Thoughts?
works for me (the d.g.o location was a bit obscure/hackish anyways ;)
(In reply to comment #2) > works for me (the d.g.o location was a bit obscure/hackish anyways ;) Yup, totally agree. I'll put that on the todo list.
*nudge* status? see bug #134938, easy to state what's going on if the report is available (no report, means have to track down zmedico which wastes his time for trivial stuff)....
As a temporary solution, until we have an official place for this, I've setup a local cron job so that osprey.gentoo.org:/home/distfiles/reports/ is synced to my dev space: http://dev.gentoo.org/~zmedico/infra/distfiles/failure.xml
(In reply to comment #3) > (In reply to comment #2) > > works for me (the d.g.o location was a bit obscure/hackish anyways ;) > > Yup, totally agree. I'll put that on the todo list. any progress?
(In reply to comment #6) > (In reply to comment #3) > > (In reply to comment #2) > > > works for me (the d.g.o location was a bit obscure/hackish anyways ;) > > > > Yup, totally agree. I'll put that on the todo list. > > any progress? Nope, still on the todo list. Don't expect this to get done quickly. We have several other things on our list to get done before this. So please be patient
(In reply to comment #7) > Nope, still on the todo list. Don't expect this to get done quickly. We have > several other things on our list to get done before this. So please be patient H'okay... been 3 months for a one line cronjob entry. Seriously, what's the hold up here?
where's the script that needs to be run and what's the cronjob entry for running it? I know nothing about this whole thing (first time I've seen the bug) but if this is just a matter of adding another script to the www.g.o rotation and someone can provide some pretty clear instructions on what needs to be done, I'll add it.
The report, located at osprey.gentoo.org:/home/distfiles/reports/failure.xml, is generated every 4 hours by the distfiles user's only cron job: 20 */4 * * * /usr/local/bin/pidlock /home/distfiles/scripts/update_distfiles.sh The failure.xml file should be synced to some webspace somewhere. A cronjob on my desktop system currently syncs it to my dev space: http://dev.gentoo.org/~zmedico/infra/distfiles/failure.xml
ok, some notes: a) this doesn't belong on www.g.o. It's for dev use, not general user consumption. (no big deal if they see it, but www.g.o should contain things primarily aimed at our user base) b) it's already working on woodpecker. It's just apache that's screwed up and not displaying it. See: woodpecker distfile-mirroring # pwd /var/www/dev.gentoo.org/distfile-mirroring woodpecker distfile-mirroring # ls -alh failure.xml -rw-r--r-- 1 root root 28K Aug 13 17:00 failure.xml So, I'll beat on apache a bit and see if I can get it to show up correctly. --kurt
amazing what happens when you move the directory to the correct location (i.e. under htdocs/) works now, kind of. images are still screwed up, but that's XSL-fu. Anyone know how to fix that? http://dev.gentoo.org/distfile-mirroring/failure.xml
changed /etc/crontab entry on woodpecker to sync to the correct path. that's why this wasn't working before.
The latest copy of failure.xml might be better. I've updated the xml to use "/xsl/guide.xsl" instead of just "guide.xsl".
(In reply to comment #12) > works now, kind of. images are still screwed up, but that's XSL-fu. Anyone > know how to fix that? It would work if it was allowed to work its fu on it :) 1. Remove the processing instruction from the file (2nd line) or use "/xsl/guide.xsl" 2. Let the server process it, ?passthru=1 does not work which tells me it's not being passed to gorg Same file with the p.i. http://dev.gentoo.org/~neysx/failure.xml
(In reply to comment #15) > 1. Remove the processing instruction from the file (2nd line) or use > "/xsl/guide.xsl" OK, so can the folks responsible for the upstream script on osprey take care of this? Once it's changed there, it should propogate down to woodpecker the next time it syncs.
Just before I leave, > 2. Let the server process it Same files, different locations: http://dev.gentoo.org/~neysx/failure.xml http://dev.gentoo.org/distfile-mirroring/failure.xml Check the apache config, look for "handler .xml"
Ping. How many Gentoo devs does it need to change one config line in an Apache config?
(In reply to comment #18) > Ping. > How many Gentoo devs does it need to change one config line in an Apache > config? > Can you find me on IRC in the next few hours? I'll see if I can resolve this. I tried mucking with it, and its still working. I'm kind of busy, so I can't spend a lot of time debugging it, but I'm sure its a one-off thing. Thanks.
(In reply to comment #19) > Can you find me on IRC in the next few hours? I'll see if I can resolve this. I > tried mucking with it, and its still working. I'm kind of busy, so I can't > spend a lot of time debugging it, but I'm sure its a one-off thing. Thanks. I'll try later. Could I have a look at the vhost config for a start? distfile-mirroring is not under htdocs and I guess gorg is only set as a handler for xml files under htdocs.
*bump* status?
file is back, but now is giving the finger for xslt transformation...
(In reply to comment #22) > file is back, but now is giving the finger for xslt transformation... Infra: woodpecker-admin required
So...its been quite awhile since the last comment on here, it this still looks like its broken. Could someone please fix this? :)
after a LOT of head scratching, I finally figured out what the problem was - and Apache was NOT any help at all. The gorg handler was undefined in that part of the Apache config.
(In reply to comment #25) > after a LOT of head scratching, I finally figured out what the problem was - > and Apache was NOT any help at all. > > The gorg handler was undefined in that part of the Apache config. Reading the comments above would have saved you a lot of head scratching. Thanks for fixing this.
neysx: In answer to your comment, I did read the entire bug, including your comment #17. "AddHandler gorg .xml" existed already in the relevant section of the Apache config. However it did NOT do anything: No XML processing, nor error messages. ?passthru=1 worked fine, but served the identical, non-processed XML. I had to add "Action gorg /fcgi-bin/gorg.fcgi" in the relevant scope for Apache to do anything. That is what I meant that the handler was undefined. Somebody please skewer upsteam Apache for not giving errors when you use AddHandler with an undefined value.
