Session Start: Mon Nov 27 22:02:19 2006 Session Ident: #twiki_edinburgh [22:02] * Now talking in #twiki_edinburgh [22:02] * Topic is 'http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x11x27' [22:02] * Set by SvenDowideit on Mon Nov 27 10:35:49 [22:02] Good evening everyone [22:02] Good evening [22:02] hi kenneth! [22:05] how is weather in denmark? [22:05] Grey and wet [22:05] i heard from a client in finland that there was already snow [22:06] Finland is far away :-) [22:06] We have 10.2 deg C right now [22:06] I can't tell how the whether in Munich is, because it is so foggy that I can't see across the street [22:07] last week my family and one more family went to shasta lake, up north in california [22:07] there is an interesting cave in limestones [22:07] http://caladventures.com/ShastaCaverns.htm [22:08] harald, with all this fox, you are still able to see the beer mug in front of you? :-) [22:08] s/fox/fog/ [22:08] Not yet. Maybe I'll have to go to the cellar first and fetch one :-) [22:09] oh, now is november, oktoberfest is gone... [22:09] we are a small group [22:09] and we are at +10 min [22:09] wait some more, start, or postpone? [22:10] tweigert has just left #twiki - I thought he and Sven would be the most needed persons [22:10] Because I do not understand anything about the templates stuff they are discussing [22:11] I never saw Thomas on IRC before. [22:11] I think it is new to him. [22:12] * terceiro has joined #twiki_edinburgh [22:13] hi antonio! [22:14] nice to see you here [22:14] i suggest that we start now, [22:14] we might need to defer some items to next meeting due to low participation [22:15] OK [22:15] so, kenneth for minutes and me for facilitation as usual? [22:15] Yes. I have started [22:16] ok, great [22:16] * tweigert has joined #twiki_edinburgh [22:16] btw, i have a hard stop at +105 min [22:16] oh, hi tomas! [22:16] good to have you here! [22:16] Hi Thomas. Nice to see you here [22:16] hi [22:16] s/tomas/thomas/ [22:16] Lavr = KennethLavrsen [22:17] minutes at http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x11x27 [22:17] which I edit on the fly [22:17] proposed agenda items: [22:17] # 1. Review Previous Action Items [22:17] # 2. Review Proposed Features of TWiki 4.1 [22:17] # 3. TWiki 4.1 Release Timing [22:17] PeterThoeny: hi :) [22:17] anything to add? [22:18] Not from me [22:18] ok, lets start [22:18] ---++ 1. Review Previous Action Items [22:18] - Kenneth: PostDakarTrackingAndDiscussion - review and enhance [22:18] this is done [22:18] YEs [22:19] next step is to actually enhance the tracker [22:19] Yes. [22:19] let me take this as a new action item to follow up with sam hasler [22:19] But right now I focus all my time on 4.1 [22:20] - Thomas W.: TemplatePathIsCounterintuitive - give overview of what has been implemented to we can give the feedback requested [22:20] You can find that in the topic, about 2/3 down [22:20] thanks thomas for posting your remarks, this helps speed up the meeting [22:21] http://twiki.org/cgi-bin/view/Codev/TemplatePathIsCounterintuitive [22:21] The only thing I have of input to the IMPLEMTATION is that I would move the config option to another section in configure. [22:21] no problem. any suggestion where? [22:21] The reason is that with the change Harald did the section with the paths is now very first time installer friendly. [22:22] And then this setting is the only one you should not touch. So any other section that you see fit will do. [22:22] check [22:24] i have not looked into detail, but thomas' change looks sound to me [22:24] what was sven's concern? [22:24] I think basically he felt that this was too late in the process to make such a big change [22:25] Well. This proposal is very old and has taken a long time to implement. And since we seem to be at the goal now - then lets get it tested in betas ASAP. [22:26] agreed, lets leave the code as is, test, and fix/enhance if needed [22:26] what about documentation? [22:27] Interesting question. All the config settings are documented in the *.spec file [22:27] I have written up this there, and can expand if that is not sufficient. [22:27] I think Peter is referring to TWiki.TWikiTemplates [22:27] Is there any cookbook needed like Arthur has done for skin customization? [22:28] yes, that is the topic that documents the templates [22:28] it should be updated as needed [22:28] I think that it would be best to put a comment into TWiki.TWikiTemplates referring users to the config setting [22:29] cookbook: good idea, best done as supplemental doc [22:29] The same should probably done for other settings that have migrated into config, such as Plugins doco [22:29] I think there should be a few lines describing how to take advantage of this new setting. It is not an obvious self explaning kind of feature [22:29] Will do in TWiki.TWikiTemplates [22:29] Great! [22:30] I have recorded actions... [22:30] * Thomas: Move config setting for TemplatePathIsCounterintuitive to another section in configure so it is not with the settings you setup as the first installation step. [22:30] * Thomas: Update TWiki.TWikiTemplates for the enhancement to Template path. [22:30] there is a skin supplement, http://twiki.org/cgi-bin/view/TWiki/TWikiSkinsSupplement [22:30] but not yet a template supplement [22:31] action item for pth: create supplemental doc for templates [22:31] and link to it from twikitemplates topic [22:31] Lavr: For Thomas' first action - I do not see a section which would fit better. Why not keep it where it is? [22:32] Because as it is now this setting is NOT one the newbie should touch during installation. It is the only one like that. I fear people will try and edit it. [22:32] And in fact 99% will never need to. [22:33] It is marked as EXPERT. So the only option I see is to move it down, so that it is the very last item of the section. [22:34] Most people never need to touch the other paths as well, because if TWiki guesses right, the correct values are shown [22:35] When you run configure first time you are asked to edit the stuff in "General Path Settings". And if you try and delete the LocalSite.cfg and look at the user interface for a first time installer then this field is a bit strange. [22:35] The only thing which I see changed here and then is {ScriptUrlPath} which sometimes is redirected to some "cgi-bin" value [22:35] Maybe if we just move it to the end. It is because it is in the middle of the green guessed values? [22:36] Try and delete LocalSite.cfg and you will see what I mean. [22:37] "Green" is just PATH as compared to Black for general strings [22:38] I would move the setting to miscellaneous settings where we also have a path setting for registration approvals. [22:38] i think kenneth has a good argument [22:39] any reason not to move it to the misc section? [22:40] Not really. If it is documented in TWiki.TWikiTemplates, that's fine. [22:40] personally i am fine with both, the end of path section or misc section [22:41] thomas, your preference? [22:41] Whatever is most intuitive is best. [22:41] Ken has a good point [22:42] ok, then lets do it as kenneth suggests [22:42] anything else on template path? [22:42] If we are done with the action items... I would still read TemplatePathBuginTWiki4x00. I think the changes made to the template lookup algorithm going from Cairo to Dakar where are somewhat unintuitive and inconsistent with the rest. They are implemented in the algorithm now (thanks to feedback), but I sure have a bad feeling about them. [22:42] I mean "suggest to read" [22:42] http://twiki.org/cgi-bin/view/Codev/TemplateAffectsTextarea [22:43] sorry, wrong link [22:43] http://twiki.org/cgi-bin/view/Codev/TemplatePathBuginTWiki4x00 [22:45] You only need to read as far as the Discussion start [22:45] thomas, could you state your concerns in the topic? [22:45] The two experts on these paths are Michael and Arthur. I think some of the rest of us that never do skins or templates are a bit lost in the discussion. [22:45] lets take this offline unless more input now [22:45] OK [22:46] do you want this as an action item for michael and arthur to review? [22:46] Can you request feedback as action. There has been no comment since I created the topic. All discussion is from factorization. [22:46] That would be great. [22:46] ok [22:47] - TemplateAffectsTextarea: [22:47] * Sven D: Add a proposal to meet Thomas actual need with existing features. [22:47] * DONE Thomas: Evaluate and see if this meets his need. [22:47] http://twiki.org/cgi-bin/view/Codev/TemplateAffectsTextarea [22:48] I think that discussion has been dragged too long with statements about the basic need behind the proposal having solutions within the existing feature set. [22:48] Sorry for the checkin. I am still not clear on the process. See next point... [22:48] No problem Thomas. We know it was a misunderstanding. [22:50] there are two questions: [22:50] 1. review/modify/accept proposal [22:50] 2. clarify process on accepting features [22:50] * terceiro has quit IRC ("Leaving") [22:50] The resistance against Thomas' feature has been based on the assumption that it was possible without the change. And I am sure the guys saying that believed that. [22:50] but did not take action to prove it [22:51] The last statement from Sven (are you here SvenDowideit?) was that if the proposals did not work there was a bug. [22:51] But I think Thomas has done a thorough work and at some point we as a community has to draw a line and get a solution and as it is Thomas has produced a solution. [22:52] We have to however recognize that accepting it means keeping it. Also even if the bug (if there is one) is later solved. [22:53] is there a middle ground? [22:53] such as keeping it as undocumented feature if that makes sense at all? [22:53] All the template tricks are undocumented. So this would be consistent. [22:54] That is possible. We can mark it as deprecated in the code and not write anything about it. [22:54] Please don't do that! [22:54] Harald? [22:54] If it is there, we should document why it is there. [22:55] Currently, nothing is documented about how templates actually work in detail. E.g., the similar %SPLIT% feature in search is not documented... nor is the way how we get %TEXT% into the templates in the first place. [22:55] Yes, Templates are voodoo. But that is really bad. [22:55] There are two things about templates: [22:55] 1. assumptions the core code makes about templates [22:56] 2. voodoo inside the templates [22:56] :-) [22:56] Assumptions in the core code are plenty: all the URL parameters, %SPLIT%, %TEXT%, %TEXTAREA%, etc. [22:57] That's true, and that's not one of the best features of TWiki. [22:57] All I am saying is that we cannot document just one tiny feature if we don't document all... [22:57] Good point. Sad point. [22:57] You would not even understand the document of the feature under discussion without understanding %TEXT% also. [22:58] Basically, the issue is that the core code has two parts: [22:58] 1. The code itself [22:58] 2. The assumptions about the template that is being manipulated. [22:58] (I am taking about the code in TWiki/UI [22:58] ) [22:58] So is accepting the code and not documenting STARTTEXT and STOPTEXT and put a note in the code that this feature may disappear again once an alternative approach to fixing the issue is implemented? [22:59] .. what we agree on? [22:59] Should we also put a note to %SPLIT% that it might disappear? Or %TEXT%... [22:59] i think that is a good middle ground solution [23:00] (my comment was to kenneth's statement) [23:00] The question is how many people (besides Thomas) will pick up STARTTEXT and STOPTEXT as requirements to their applications [23:00] This is not a question for %TEXT% [23:00] Anybody who want to use e.g., TOC on every topic without allowing the user to edit it out. [23:01] Anybody who wants to put the section edit command in every topic without wanting to allow the user to edit it in the text area... [23:01] With TEXT people know about it because it is used in the templates that come with TWiki. As long as Thomas never added STARTTEXT and STOPTEXT in any distributed template very few will know. [23:01] Basically, whenever you have a tag that needs to read the topic to do its work which is in the template. Then you need this feature. [23:02] I mean "when you want to place such tag in the template, rather than the topic text." [23:02] Yes, that's my point: I didn't see many users having a similarly sophisticated TWiki application set than Thomas [23:03] so if it is an obscure command i do not see an issue with leaving it in as an undocumented feature [23:03] shall we vote? [23:04] vote: [23:04] 1. leave as undocumented feature [23:04] 2. leave in, and document [23:04] 3. take out and review alternate solutions [23:04] 1 [23:04] Abstain [23:04] 1 [23:04] harald? [23:05] I can live perfectly with 1 because I am too lazy to to 2 [23:05] :-) [23:05] harlad, so it's not a 3 [23:05] "harald" [23:06] definitely not. If the code is there, and it works for Thomas, why not? [23:06] ok, so it is accepted in this meeting [23:06] For the notes. [23:06] * TemplateAffectsTextarea: Accepted: 3 votes to 0. The decision is to keep the checked in code but keep it as UNDOCUMENTED feature so we can later replace it by better implementation. Thomas to add note in code warning that feature may be removed again. [23:06] And Thomas get small action: * Thomas: Add small note in code implemting STARTTEXT and STOPTEXT that the feature is temporary and may be removed again. [23:07] now to clarifying process [23:07] The question was about when to check code in. [23:07] thomas, did you review the process doc? [23:08] The way I have been exercising the process is..... [23:08] I thought I did [23:08] http://twiki.org/cgi-bin/view/Codev/TWikiRelease04x01Process [23:08] If no concern raised I put a statement to go ahead. That actually rarely happens. [23:08] And when concern is raised these release meetings are the "authority" by simple vote like we just did. [23:09] if anything unclear we can enhance the doc [23:09] the process itself is sound [23:09] And last time there was no decision on this topic because Sven was very sure that he knew a way to solve your problem without the change which would have meant that the feature would probably have been voted NO. [23:10] thomas, could you review the process doc and enhance/add feedback? (offline) [23:10] I just reviewed. What is still unclear is when to checkin. Here is my dilemma: On the first topic the release meeting complained that I did not check the code in so there was nothing to review. On this topic Sven complained that I did check in. So I am confused. [23:10] But as we now know the altertive did not work to Sven's surprise. So that is why we bring it up again today. [23:10] Thomas. It was for TemplatePathIsCounterintuitive that this was the case. [23:11] Yes. But what is the difference? [23:11] Neither of the two features had the blessing of the release meeting. [23:11] We had agreed on the FEATURE. The goal. But people wanted to see your code to evaluate the actual implementation. So it was a yes. But with show ud the code. [23:12] The agreement was basically in the proposal topic. Noone was really against. It was only implementation that was discussed. [23:12] Well, Sven was questioning the feature on both. [23:12] Anyway, here is what I learned today: [23:13] Not the way I interpreted it. And as you saw noone complained that you checked in the other code. [23:13] 1. Code is to be checked in only (for new features) once the 2 week rule expired or the release meeting has agreed. [23:13] 2. For bug fixes code can be checked in any time. [23:13] Yes. [23:14] I think there's no doubt about that. [23:14] World is not black and white. And people have been sneaking in enhancements the past week on bug items. Which I have commented. [23:15] +75 min [23:15] I shall add a bullet to the "Process" section clarifying 1+2 if you don't mind. [23:15] That is the wiki way :-) [23:15] :-) [23:15] ---++ 2. Review Proposed Features of TWiki 4.1 [23:16] http://twiki.org/cgi-bin/view/Codev/WhatIsIn04x01 [23:16] we talked about the two open (under discussion) items [23:16] No more open. We discussed the two open. Which I will flip to accepted now. [23:17] there is a new one [23:17] which is for 4.2 [23:17] Yes [23:17] ---++ 3. TWiki 4.1 Release Timing [23:18] kenneth, the floor is your's [23:18] One moment need to update minutes [23:18] ok [23:19] OK. [23:19] Well. I have wanted to release a beta 2 but the build script is broken so the tgz gets the wrong access rights for all files from extensions. [23:20] And I have asked and begged for someone to fix it. [23:20] Does the build script still do a svn checkout before starting the build? [23:21] It checks out TWikiRelease04x00x03 which is the last full release that was tagged with ,v files. [23:21] And it does this part correctly because it builds the ,v files OK. [23:21] Ouch. That's what kept me from debugging it last time. On dialup, this takes about 4,5 hours. [23:22] I made a small hack when I test now. I change the svn co to a "cp -R ...." of an already checked out copy of 4.0.3 [23:23] In tools/build there is a line `svn co http://svn.twiki.org/svn/twiki/tags/TWikiRelease04x00x03/ .`; [23:23] You can replace that with `cp -R /var/www/TWikiRelease04x00x03/* .`; [23:23] assuming you have a svn checkout at that place. [23:23] Yes, but I need to spent the 4.5 hours once to get 4.0.3 [23:23] I am afraid yes. [23:24] But wait - maybe I can try to debug from SVN HEAD as well= [23:24] And just kill the cp -R as well, simply working from my checkout area? [23:24] Yes. For a debug of access rights you should be able to just copy from your current head. [23:25] The cp -R copies your SVN directory to the temp directory in which it does the build. So you need that. [23:26] Phone [23:26] can we ask crawford to help out? [23:26] Already did. [23:26] No luck [23:26] it looks like this is the only blocker for beta2 [23:26] yes [23:27] one moment phone [23:27] who else could help out on build script? [23:27] ok [23:27] who else is familiar with build script? [23:27] CDot complained in Item 3155 that unit tests don't pass, this should be another critical point [23:28] we also have many open bugs [23:28] we need toi focus on bug fixing [23:28] but i think it is also important to get a somewhat usable beta for people to test [23:32] +90 min [23:32] (i need to go in 15 min) [23:32] Are there many bugs regarding the engine? Most are build and extensions, IIRC [23:33] Back. [23:33] Actually many of the bugs are core or they are in the default plugins. [23:34] There are around 100 open bugs that affects core or default plugins. [23:34] which is a lot [23:34] Not as ReleaseBlockers. [23:34] do you think beta2 once done can be used on twiki.org? [23:34] that would be a good testbed [23:35] Hard to say. Probably. I would think it could. There are a few bugs affecting the looks of tables that Arthur is looking at which Thomas found. [23:36] back to help on build script [23:36] But we need to do something about configure. I cannot see how we can have a configure that should help non-geeks to install plugins. And then you have to install CPAN libs to get it to work. [23:37] that is a good point [23:37] lets first find a solution on build [23:37] And the worst is that all these special libs are doing is "tar -zxv filename" [23:37] zxf [23:37] who knows the build script besides crawford? [23:38] What the build should do os set the access rights as defined in the MANIFEST file of the extensions. That worked in 4.0.5 version. But was broken in connection with the work on the new extension installer. [23:39] svn praise build.pl has crawford and sven all over it [23:40] can we ask sven to look into it? [23:40] did you ask sven already? [23:41] No. But I asked on the bug item several times. And on #twiki. [23:41] could you send him an e-mail if he is willing to help out [23:41] ? [23:42] the build is now the critical path for beta2 [23:42] Sven will be reading the log. He is logging this meeting. [23:43] assuming the build script is fixed, how soon can you create beta2? [23:43] It takes around 5 minutes. I do not do any unit testing or anything for betas. [23:43] ok [23:44] ok, back to your question on installer and cpan [23:44] I could also manually edit the tgz right by unpacking and repacking but then I do not get the very important test to check if the rights are correct. [23:44] i totally agree, we have to make it as easy as possible for non-geeks [23:45] meaning, we need to ship all cpans the installer depends on in the twiki distribution [23:45] for example, theere should be a fallback if lwp is not available [23:45] and a fallback to unpack the zip file [23:46] i consider this a release blocker [23:46] (not for beta and rc) [23:47] If you look in tools/getutl.pl then it is 12-14 lines of code to avoid lwp. And the untar could be a simple condition that runs a system command instead if the CPAN lib is not there. [23:48] +107 min, i need to sign off now [23:48] I have the feeling this discussion is more a principle discussion about CPAN than anything else and I do not understand CDot's reaction. [23:48] please continue, i will read the logs [23:49] Anyone has any oppinions on this other than Peter and I? [23:50] The problem with CPAN libs is that it is not as easy at it may seem for many. [23:50] If you are behind a firewall which requires authentication like we have at Motorola, then it is quite an effort to setup CPAN so it can use the proxy and authenticate. [23:51] If you are on a shared host you have no root access and you then have to ask the host provider to install them. And they OFTEN say NO. [23:51] If you are in a company and have access to an existing webserver as a normal user but no root access then it can also be a pain to get permission to install CPAN libs. [23:52] But you can always download the libs and run the builds yourself... [23:52] And it is a bit sad that we create these problems because configure wants to untar the tgz with a CPAN lib. [23:53] If you know a lot about perl, then maybe. Many shared host users only have ftp. They cannot even run commands. [23:53] Other then CGI from browser. [23:54] And all these particular CPAN libs do is untar the tgz!!??! We really should not require non standard CPAN libs for that. [23:54] If you can't run commands, you can't run tar as well. [23:55] The CGI user can run I would think. [23:55] We can think all sorts of work arounds for these poor souls but it is a self-inflicted problem that we should avoid in the first place. [23:57] It comes back to the basic question: Why should you need exotic CPAN libs to run an installer? Why not let the installer install the CPAN libs? Why have an extension installer feature then? The whole point of helping the newbies is totally lost. [23:58] Remember that 95% (guess) of people downloading TWiki just want to install it and use it. They do not know programming. They do not know what Perl is. They do not know what CPAN is. Session Time: Tue Nov 28 00:00:00 2006 [00:00] Compare this with installing Firefox on a PC. Download an exe file. Double click it. Answer yes. And it is installed. No installing of mysterious libs first. [00:00] There's a big difference between installing something on your local PC or installing something on a world-accessible ISP server [00:01] If I want to install Apache on my RedHat and I do not have it all I have to do is... [00:01] yum install httpd [00:02] And then I have Apache! I need to configure it yes. But it runs out of the box. And so should TWiki. [00:02] Yes, but you would not want somebody to upgrade your Apache on the fly via a web interface [00:02] Yes. You can do that on RedHat. [00:03] Really? The apache user can overwrite apache code? [00:03] That would be more than crazy [00:03] We have made a huge step in the right direction when we replaced the file hacking in Cairo with Configure script in Dakar. So why sell out on this now. WHY? I do not understand it. [00:05] I still haven't tested it: Does configure break unless the CPAN dependencies are installed or does it work, only the extension installer doesn't? [00:05] The extension installer does not work. [00:05] But who is the extension installer made for? The advanced user? Or the less advanced? [00:06] All of US can install an extension manually in 10 seconds. It is not made for us. [00:06] In my not political correct opinion the extension installer is made for people who under no circumstances should be allowed to run it [00:07] The installer is for the TWiki admin. It is password protected. A normal user cannot install an extension. [00:07] But a TWiki admin is just a normal bloke. Normally not a perl programmer. [00:09] If we now require that a TWiki admin is a highly skilled perl programmer familiar with CPAN then we limit the potential customer base. [00:09] A normal bloke will not understand that he has to use a *good* password to protect configure [00:09] Then we should not have configure at all. [00:10] I know that this isn't agreeable, but in my TWiki installations I *do* not have configure at all. [00:10] You do not use it yourself? [00:11] Nope [00:11] But YOU are a perl programmer Harald. [00:11] Yep [00:12] But the reason is not related to programming. The reason is that my security policy does not allow Apache to run code which the apache user id can write [00:13] Well. In my oppinion we have 3 acceptable options. [00:13] 1. Fix configure so it does not need Archive::Tar to untar a tgz. [00:14] 2. Provide the needed CPAN stuff with the default TWiki [00:14] 3. Remove the extension installer from configure (which would be sad because it is a very nice feature). [00:15] You can't do 2. because some CPAN stuff needs to be compiled on the target architecture [00:15] So this would also mean that you could not always install this missing CPAN stuff on a shared host, right? [00:16] Only if you have access to a C compiler, in case of Archive::Tar [00:16] I am sure many shared hosts do not have gcc installed for security reasons. [00:16] Otherwise it would be dead simple to just add the libraries to lib/CPAN [00:17] But I would think that 95 % of shared hosts have tar installed. [00:18] I don't think it is "security reasons" that shared hosts don't offer gcc [00:18] Whatever. [00:18] But you may be right in that most shared hosts will run Linux, and hence have tar [00:19] Even plain Unix have tar. And also unzip. [00:19] But not all old UNIXes have a tar that can untar a tgz. [00:20] I think unzip is not on the debian VM? [00:21] I would propose that the configure first test for the Archive::Tar and use it if it is there. If not then try to unpack the downloaded tgz with tar -zxf [00:21] That sounds reasonable. [00:22] hi, i am back [00:22] good discussions here [00:22] With respect to lwp. This is not as rare. I think must Linux boxes have it. But not all Unixes have it. [00:22] solaris does not ship with lwp [00:23] But in tools/geturl.pl there is a simple piece of code that can get a file from a URL. But probably not through a firewall with proxy. [00:23] i think the right solution is to try to use lwp, and fall back to TWiki::Net::getUrl [00:23] if lwp is missing [00:24] Yes. That is also what I think. [00:24] one other point: we should switch from downloading .tgz to downloading .zip files [00:24] That would require either.... [00:24] because this is the documented archive format [00:24] 1. We always assume a specific set of file access rights for each directory. [00:25] not all extensions are packaged as .tgz, but all are as .zip [00:25] 2. We have to add a MANIFEST file in the zip with the right access rigts. Because zips cannot have access rights. [00:25] most extensions are no-brainer for permissions, so option 1 is viable [00:26] I think so too. [00:26] actually, i would go for 2 with fallback for 1 [00:26] design the system to be forgiving [00:26] And a plain unzip is more likely to be on a Sun OS or HPUX than a Gnu Tar. [00:27] yes, unzip is on twiki.org's solaris [00:27] as far as I remember. I remember having to install and compile Gnu Tar on our HPUX machines. [00:27] also here we can try one, and fallback to the other [00:27] Agree. [00:27] such as try using cpan unzip, and fall back to unzip command [00:28] Agree again [00:28] Agreeing is easy. Getting someone to code it. That is the difficult part. [00:28] :-) [00:29] Good point. There are very few coders actually hacking core code. [00:29] And many that do extensions. I wonder if some of the new guys feel that they are not allowed. [00:31] I tried to follow the configure code. But I find it extremely difficult to follow the program flow. [00:32] Yeah - took me some debugger sessions as well. [00:33] Are these proposed fall backs to unzip and TWiki::Net::getUrl something you dare trying to resolve Harald? (beg beg) [00:34]