Re: [Toolserver-l] What happened to user_properties_anonym?
Hello, At Monday 05 March 2012 13:57:41 DaB. wrote: Hey all, I used to periodically run some stats on preference usage (mostly skin-preferences and gadget usage), but it appears the custom user_properties_anonym table view Toolserver used to have no longer exists ? Testing here: https://toolserver.org/~krinkle/tmp/user_properties_anonym.php fixed with https://jira.toolserver.org/browse/MNT-1216. Please tell the next time, WHERE a view is missing (and better open a bug in jira). -- Krinkle Sincerlery, DaB. -- Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885 signature.asc Description: This is a digitally signed message part. ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Debian (Linux) is coming back
On 05/03/12 15:20, DaB. wrote: In puppet (our server-managment-programm) I have now a HUGE list of liberies and software to install for the solaris-server – but the names of the packages does not match with the debian-package-names of course. I would need weeks to figure out what belongs to what – I do not have to time (and to admit: also not the motivation) to do this. Is the list available somewhere, to crowdsource the mapping? (the plan of starting from basic things looks good, too) At the end, only the following stuff will remain at willow: *tools of people who are stoo lazy/stoo busy to move their stuff *tools which can not run on Debian for some reasons *tools of users who left the TS Remember that some TS-specific programs like setpass or acctrenew can only work in Solaris. They don't seem hard to rewrite, but it's something to keep into account. That is a nice plan, but it would not work, because most users are not capable to tell what liberies they need. And it is BTW not a problem to have a libery installed that is not used (because we have enough free space for that). Some automatic non-exhaustive dependency check would be easy. ldd on elf files, grep import on .py ones, etc. ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Debian (Linux) is coming back
DaB. w...@daniel.baur4.info wrote: [...] I believe we had several issues already in the past when the installed soft- ware differed between the Solaris servers. Which brings me to: Does anyone know an established format a) in which pro- jects could write down their requirements and b) that covers both Debian and Solaris? So when admins need to (re-)in- stall a server, they wouldn't have to guess which packages are (still) required, but could just collect all $HOME/.requirements for active accounts and when one of these could not be satisfied, there would also be a person to contact before tools get broken. That is a nice plan, but it would not work, because most users are not capable to tell what liberies they need. And it is BTW not a problem to have a libery installed that is not used (because we have enough free space for that). [...] It's not only a question of space, but also of availability. I don't know about Debian or Solaris, but on Fedora some packages are sent to a farm up north when they don't compile in the current release and noone volunteers to fix it. I wouldn't want the admins in this case to work on such prob- lems if there is no existing demand. I'm more optimistic regarding the abilities of the tool- server users - if someone can write import x or use y; they should be able to copy and paste that to another file. And if they don't, that'd be a nice opportunity to ask for and share some knowledge. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Debian (Linux) is coming back
Jeremy Baron jer...@tuxmachine.com wrote: Which brings me to: Does anyone know an established format a) in which pro- jects could write down their requirements and b) that covers both Debian and Solaris? So when admins need to (re-)in- stall a server, they wouldn't have to guess which packages are (still) required, but could just collect all $HOME/.requirements for active accounts and when one of these could not be satisfied, there would also be a person to contact before tools get broken. I assume this is one of the reasons to use puppet? Puppet manifests can have comments and the roots could establish a standardized way of writing (inline) why a package is needed. (e.g., a) assumed to be widely used like sed, grep or b) needed by the roots or a process that doesn't belong to a particular user or MMP or c) needed by users/MMP foo, baz, bar or some combination of those.) Of course most people (whether roots or users or anyone else) won't do a very thorough job of enumerating dependencies when installing, updating, hacking software unless they first do an installation of that version on a brand new Debian install with a limited set of installed packages. i.e. most people won't notice that a package is needed or not already picked up some other way until they see something is broken because it's missing. I'm not sure if I like ~/.requirements (and maybe it could be something like ~/.package-depends instead?) in place of puppet but at least it could be used as a failsafe if a root wanted to check after installing a new box or before removing a package. [...] I wouldn't want to put the burden on the roots because that would mean that they have to mangle all the small notes that project X needs package Y into the puppet manifest which in most cases - as you noted - will not have much effect. If instead it'd be up to the project's developers, the workload lies with who has a) the information needed and b) the moti- vation. On second thought though, I think ~/.something is too hidden. We already have the nice [[Template:Tool]] on the Toolserver Wiki; it would be much better to store the depen- dencies as fields thus encouraging developers to update (or create) their pages there and give them more publicity. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Debian (Linux) is coming back
On 05/03/12 23:36, Tim Landscheidt wrote: It's not only a question of space, but also of availability. I don't know about Debian or Solaris, but on Fedora some packages are sent to a farm up north when they don't compile in the current release and noone volunteers to fix it. I wouldn't want the admins in this case to work on such prob- lems if there is no existing demand. I'm more optimistic regarding the abilities of the tool- server users - if someone can write import x or use y; they should be able to copy and paste that to another file. And if they don't, that'd be a nice opportunity to ask for and share some knowledge. Tim That assumes they know what they are doing, instead of blindly copypasting recipes. I know that's not true for many toolserver users, where we have very valued developers. But I'm sure there is also a bunch of people which copied pywikipediabot following some instructions, and are only experts on its command line. Don't misinterpret me, I'm not meaning that they shouldn't have an account in the TS, or that they are second-class users. It's good to have them on board, each one has its own know-how, very much as not every php coder is a perl guru. But not everyone has the experience to identify the dependencies of what they're doing. And then, even for those writing their own scripts, having to copy the requisites to a separate file and keeping them up-to-date is a burdensome task. I prefer the autodetection way as far as it's possible (which in most cases looks simple). ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
[Toolserver-l] Rewrite of status.toolserver.org is done
Hello all, as you may know status.toolserver.org was only a static page for some days, because the original site with the dynamic code went down. I promised a rewrite and that is done now, the new dynamic page is in place and working – I switched to it some minutes ago. I tried to keep as much backwards- compatibilty as possible, but it is not 100% the same old page (if you need the same old page for a quickdirty fix in your tools, you can find it at [1]). I changed many things in the backparts, that will make the live of the roots easier, but I also added some features at the fronside: XML-, JSON- and a plain-output. Please notice that the page runs on a external server of mine, that has not the performance of the toolserver – so please keep the access-rates civil (not more than 1/minute) and provide a useful user-agent (I will block unuseful ones). I plan to setup a cache-instance of it in the toolserver-cluster to allow more accesses; but not at the moment. If you find a problem, please fill in a ticket at JIRA (in the TS-queue). Sincerley, DaB. [1] http://status.toolserver.org/static/old.html -- Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885 signature.asc Description: This is a digitally signed message part. ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
