Re: Non-responsive Maintainer: mediawiki
On 02/15/2013 05:11 PM, Michael Cronenworth wrote: Ping. I'd like to finish up the NRM process. What have I not done? Do I need to CC FESCo members directly? Create a trac ticket? The current maintainer has gone without replying to my messages for a month now. My FAS name is mooninite and I have been awaiting the commit ACL for just as long. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 25 February 2013 06:37, Michael Cronenworth m...@cchtml.com wrote: On 02/15/2013 05:11 PM, Michael Cronenworth wrote: Ping. I'd like to finish up the NRM process. What have I not done? Do I need to CC FESCo members directly? Create a trac ticket? I believe you need to file a trac ticket. That should get this on a FESCo meeting agenda and get this dealt with. The current maintainer has gone without replying to my messages for a month now. My FAS name is mooninite and I have been awaiting the commit ACL for just as long. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
Stephen John Smoogen wrote: I believe you need to file a trac ticket. That should get this on a FESCo meeting agenda and get this dealt with. Created. Thanks. https://fedorahosted.org/fesco/ticket/1091 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On Mon, 25 Feb 2013, Michael Cronenworth wrote: I'd like to finish up the NRM process. What have I not done? Do I need to CC FESCo members directly? Create a trac ticket? The current maintainer has gone without replying to my messages for a month now. My FAS name is mooninite and I have been awaiting the commit ACL for just as long. +1 to fixing up mediawiki and phase out mediawiki1XX packages. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 25 February 2013 13:28, Paul Wouters pwout...@redhat.com wrote: On Mon, 25 Feb 2013, Michael Cronenworth wrote: I'd like to finish up the NRM process. What have I not done? Do I need to CC FESCo members directly? Create a trac ticket? The current maintainer has gone without replying to my messages for a month now. My FAS name is mooninite and I have been awaiting the commit ACL for just as long. +1 to fixing up mediawiki and phase out mediawiki1XX packages. Good luck with that. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On Mon, 25 Feb 2013 13:31:18 -0700 Stephen John Smoogen smo...@gmail.com wrote: On 25 February 2013 13:28, Paul Wouters pwout...@redhat.com wrote: On Mon, 25 Feb 2013, Michael Cronenworth wrote: I'd like to finish up the NRM process. What have I not done? Do I need to CC FESCo members directly? Create a trac ticket? The current maintainer has gone without replying to my messages for a month now. My FAS name is mooninite and I have been awaiting the commit ACL for just as long. +1 to fixing up mediawiki and phase out mediawiki1XX packages. Good luck with that. I think thats a fine goal/plan for Fedora. I don't know that it would work out for EPEL. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 08/02/13 01:36 PM, Pete Travis wrote: On Feb 8, 2013 12:54 PM, Stephen John Smoogen smo...@gmail.com mailto:smo...@gmail.com wrote: . Two the fix is to upgrade to a very new version which will break everyone who upgrades until they (or the first person who gets to the website :) ) runs the upgrade mode.. which might not work due to either custom changes or the fact that it is a large upgrade change. -- Stephen J Smoogen. I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. I may be misunderstanding you, but I _think_ you've got the wrong end of the stick here. Fedora webapps are indeed packaged to be served out of /usr/share/whatever . They ship with /etc/httpd/conf.d config files which point to the /usr/share location where they are installed. This is all by policy and How It's Supposed To Be. Only files that absolutely need to be actually inside /var/www for some reason or another are supposed to be packaged there. In general, the idea is that webapp files are just static data files like any others and belong in /usr/share . See https://fedoraproject.org/wiki/Packaging:Guidelines#Web_Applications . You can copy the whole thing to somewhere else (e.g. /var/www) and nerf/adjust the conf.d file if you really want to use the Fedora package only as a base for your own deployment, but that's not the 'normal way'. In general you're expected to simply install the package and use it; that way you get the benefit of packaged updates. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 15/02/13 03:02, Adam Williamson wrote: On 08/02/13 01:36 PM, Pete Travis wrote: I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. I may be misunderstanding you, but I _think_ you've got the wrong end of the stick here. Fedora webapps are indeed packaged to be served out of /usr/share/whatever . They ship with /etc/httpd/conf.d config files which point to the /usr/share location where they are installed. This is all by policy and How It's Supposed To Be. Only files that absolutely need to be actually inside /var/www for some reason or another are supposed to be packaged there. In general, the idea is that webapp files are just static data files like any others and belong in /usr/share . See https://fedoraproject.org/wiki/Packaging:Guidelines#Web_Applications . You're both kind of right - the README.RPM file that comes in the mediawiki package tells you to run mw-createinstance path to create an instance and that sets up a document root in the specified path by both copying some files, like LocalSettings.php, and symlinking others to the /usr/share code. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On Feb 15, 2013 5:34 AM, Adam Williamson awill...@redhat.com wrote: On 08/02/13 01:36 PM, Pete Travis wrote: . I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. I may be misunderstanding you, but I _think_ you've got the wrong end of the stick here. Fedora webapps are indeed packaged to be served out of /usr/share/whatever . They ship with /etc/httpd/conf.d config files which point to the /usr/share location where they are installed. This is all by policy and How It's Supposed To Be. Only files that absolutely need to be actually inside /var/www for some reason or another are supposed to be packaged there. In general, the idea is that webapp files are just static data files like any others and belong in /usr/share . See https://fedoraproject.org/wiki/Packaging:Guidelines#Web_Applications . You can copy the whole thing to somewhere else (e.g. /var/www) and nerf/adjust the conf.d file if you really want to use the Fedora package only as a base for your own deployment, but that's not the 'normal way'. In general you're expected to simply install the package and use it; that way you get the benefit of packaged updates. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- Thanks for straightening me out, Adam. I'll have to poke at this to better understand it when I get the chance. Interestingly, 'repoquery -l' does show some of the mediawiki packages owning files in /var/www/. Whether grandfathered, broken, or just misconception, I'll keep further comment to myself until I can play with a VM. Thanks, --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 15/02/13 05:44 AM, Tom Hughes wrote: On 15/02/13 03:02, Adam Williamson wrote: On 08/02/13 01:36 PM, Pete Travis wrote: I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. I may be misunderstanding you, but I _think_ you've got the wrong end of the stick here. Fedora webapps are indeed packaged to be served out of /usr/share/whatever . They ship with /etc/httpd/conf.d config files which point to the /usr/share location where they are installed. This is all by policy and How It's Supposed To Be. Only files that absolutely need to be actually inside /var/www for some reason or another are supposed to be packaged there. In general, the idea is that webapp files are just static data files like any others and belong in /usr/share . See https://fedoraproject.org/wiki/Packaging:Guidelines#Web_Applications . You're both kind of right - the README.RPM file that comes in the mediawiki package tells you to run mw-createinstance path to create an instance and that sets up a document root in the specified path by both copying some files, like LocalSettings.php, and symlinking others to the /usr/share code. Huh. That sounds...interesting. I haven't run mediawiki itself, so I wasn't aware of that, I was just referring to my general knowledge of how webapps are packaged in Fedora (e.g. wordpress, which I do run). Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 15/02/13 09:49 AM, Pete Travis wrote: Interestingly, 'repoquery -l' does show some of the mediawiki packages owning files in /var/www/. Whether grandfathered, broken, or just misconception, I'll keep further comment to myself until I can play with a VM. There are cases when there really has to be a file in /var/www for some reason or another. Wordpress has one or two files there too, but almost everything in /usr/share. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On Fri, Feb 15, 2013 at 11:24:31AM -0800, Adam Williamson wrote: On 15/02/13 05:44 AM, Tom Hughes wrote: You're both kind of right - the README.RPM file that comes in the mediawiki package tells you to run mw-createinstance path to create an instance and that sets up a document root in the specified path by both copying some files, like LocalSettings.php, and symlinking others to the /usr/share code. Huh. That sounds...interesting. I haven't run mediawiki itself, so I wasn't aware of that, I was just referring to my general knowledge of how webapps are packaged in Fedora (e.g. wordpress, which I do run). Thanks. Trac behaves similarly. There is also some environment setup and deployment involved that creates/copies files, which are usually not common to all instances. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 02/08/2013 08:46 AM, Michael Cronenworth wrote: The mediawiki package is severely outdated. I have attempted to contact the maintainer and received only one reply in a couple of weeks. He has ignored my requests for co-maintainership. I commented on the NRM bug[1] two weeks ago with no response. The bug itself is months old, but he pops in to keep from having the package taken. At this point it is time for someone to update the package as it is currently a security hazard. I have already built the latest mediawiki package and have it ready to rock-and-or-roll once the NRM procedure is finished. Michael [1] https://bugzilla.redhat.com/show_bug.cgi?id=850937 Ping. I'd like to finish up the NRM process. Thanks, Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 15 February 2013 12:24, Adam Williamson awill...@redhat.com wrote: On 15/02/13 05:44 AM, Tom Hughes wrote: On 15/02/13 03:02, Adam Williamson wrote: On 08/02/13 01:36 PM, Pete Travis wrote: I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. I may be misunderstanding you, but I _think_ you've got the wrong end of the stick here. Fedora webapps are indeed packaged to be served out of /usr/share/whatever . They ship with /etc/httpd/conf.d config files which point to the /usr/share location where they are installed. This is all by policy and How It's Supposed To Be. Only files that absolutely need to be actually inside /var/www for some reason or another are supposed to be packaged there. In general, the idea is that webapp files are just static data files like any others and belong in /usr/share . See https://fedoraproject.org/wiki/Packaging:Guidelines#Web_Applications . You're both kind of right - the README.RPM file that comes in the mediawiki package tells you to run mw-createinstance path to create an instance and that sets up a document root in the specified path by both copying some files, like LocalSettings.php, and symlinking others to the /usr/share code. Huh. That sounds...interesting. I haven't run mediawiki itself, so I wasn't aware of that, I was just referring to my general knowledge of how webapps are packaged in Fedora (e.g. wordpress, which I do run). Thanks. So one of the issues that Axel's mediawiki package is trying to solve is the 1 server, many mediawikis problem. Many servers will run multiple mediawikis at the same time with each one having a different customer. This requires doing copies to different trees and such. Of course it makes it a pain in ass when upgrading because you end up with stuff in your tree which may not match what /usr/share/mediawiki/ provides etc etc. The preferred upstream solution was at one point to just stick it in /var/www and skip links etc. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Non-responsive Maintainer: mediawiki
The mediawiki package is severely outdated. I have attempted to contact the maintainer and received only one reply in a couple of weeks. He has ignored my requests for co-maintainership. I commented on the NRM bug[1] two weeks ago with no response. The bug itself is months old, but he pops in to keep from having the package taken. At this point it is time for someone to update the package as it is currently a security hazard. I have already built the latest mediawiki package and have it ready to rock-and-or-roll once the NRM procedure is finished. Michael [1] https://bugzilla.redhat.com/show_bug.cgi?id=850937 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
Hi On Fri, Feb 8, 2013 at 9:46 AM, Michael Cronenworth wrote: At this point it is time for someone to update the package as it is currently a security hazard. I have already built the latest mediawiki package and have it ready to rock-and-or-roll once the NRM procedure is finished. There is no need to wait on the NRM process for fixing security bugs. I recommend you just go ahead and push out a build asap Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 8 February 2013 12:15, Rahul Sundaram methe...@gmail.com wrote: Hi On Fri, Feb 8, 2013 at 9:46 AM, Michael Cronenworth wrote: At this point it is time for someone to update the package as it is currently a security hazard. I have already built the latest mediawiki package and have it ready to rock-and-or-roll once the NRM procedure is finished. There is no need to wait on the NRM process for fixing security bugs. I recommend you just go ahead and push out a build asap This package is a bit difficult to fix. One it has custom patches that upstream doesn't accept. Two the fix is to upgrade to a very new version which will break everyone who upgrades until they (or the first person who gets to the website :) ) runs the upgrade mode.. which might not work due to either custom changes or the fact that it is a large upgrade change. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
Stephen John Smoogen wrote: This package is a bit difficult to fix. One it has custom patches that upstream doesn't accept. Two the fix is to upgrade to a very new version which will break everyone who upgrades until they (or the first person who gets to the website :) ) runs the upgrade mode.. which might not work due to either custom changes or the fact that it is a large upgrade change. Stephen, 1. The two patches are for hard-coding defaults. We shouldn't be in the business of doing this. I've dropped the two patches in my 1.19 build. 2. The upgrade mode is executed for the user when they upgrade by a post-install scriptlet. In any case the upgrade procedure is no different from an upgrade in PostgreSQL or any other app that requires user-interaction on upgrades. This is no reason to keep mediawiki at 1.16. I don't see any reason to keep mediawiki at 1.16 other than a NRM. If any FESCo member wants to orphan the package I'll push the update ASAP. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 8 February 2013 13:15, Michael Cronenworth m...@cchtml.com wrote: Stephen John Smoogen wrote: This package is a bit difficult to fix. One it has custom patches that upstream doesn't accept. Two the fix is to upgrade to a very new version which will break everyone who upgrades until they (or the first person who gets to the website :) ) runs the upgrade mode.. which might not work due to either custom changes or the fact that it is a large upgrade change. Stephen, 1. The two patches are for hard-coding defaults. We shouldn't be in the business of doing this. I've dropped the two patches in my 1.19 build. I thought it was more in the past. I dropped them from the various ones that were in the old 1.14 tree that tried to allow for multihosting-mutliwiki easily. There were also TeX parts in the past which were finicky. 2. The upgrade mode is executed for the user when they upgrade by a post-install scriptlet. In any case the upgrade procedure is no different from an upgrade in PostgreSQL or any other app that requires user-interaction on upgrades. This is no reason to keep mediawiki at 1.16. I don't think that it does either. However, having gotten the emails for it not always working etc etc.. I get a little gunshy of just pushing it out without some strong testing. My email was more of a this isn't a simple security fix. It is a major upgrade of the software. I don't see any reason to keep mediawiki at 1.16 other than a NRM. If any FESCo member wants to orphan the package I'll push the update ASAP. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On Feb 8, 2013 12:54 PM, Stephen John Smoogen smo...@gmail.com wrote: . Two the fix is to upgrade to a very new version which will break everyone who upgrades until they (or the first person who gets to the website :) ) runs the upgrade mode.. which might not work due to either custom changes or the fact that it is a large upgrade change. -- Stephen J Smoogen. I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
I've handed up with this question when I first request for an upgrade of mediawiki. I remember someone told me that upgrading may cause errors of custom css or custom theme,is it true? 在 2013-2-9 AM5:37，Pete Travis li...@petetravis.com写道： On Feb 8, 2013 12:54 PM, Stephen John Smoogen smo...@gmail.com wrote: . Two the fix is to upgrade to a very new version which will break everyone who upgrades until they (or the first person who gets to the website :) ) runs the upgrade mode.. which might not work due to either custom changes or the fact that it is a large upgrade change. -- Stephen J Smoogen. I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
I've handed up with this question when I first request for an upgrade of mediawiki. I remember someone told me that upgrading may cause errors of custom css or custom theme,is it true? 在 2013-2-9 AM5:37，Pete Travis li...@petetravis.com写道： On Feb 8, 2013 12:54 PM, Stephen John Smoogen smo...@gmail.com wrote: . Two the fix is to upgrade to a very new version which will break everyone who upgrades until they (or the first person who gets to the website :) ) runs the upgrade mode.. which might not work due to either custom changes or the fact that it is a large upgrade change. -- Stephen J Smoogen. I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
