#foswiki 2017-09-21,Thu

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***ChanServ sets mode: +o Lynnwood__
ChanServ sets mode: +o Lynnwood
[01:37]
ChanServ sets mode: +o Lynnwood__
ChanServ sets mode: +o Lynnwood_
[01:52]
ChanServ sets mode: +o Lynnwood [02:02]
GithubBot[distro] gac410 pushed 1 new commit to Release02x01: https://git.io/v5jEO
distro/Release02x01 de67310 George Clark: Item13883: Correct some documentaiton issues:...
[02:03]
***GithubBot has left [02:03]
FoswikiBothttps://foswiki.org/Tasks/Item13883 [ Item13883: Documentation changes for master and 2.1 ] [02:03]
***ChanServ sets mode: +o Lynnwood__ [02:04]
GithubBot[distro] vrurg pushed 1 new commit to Item14237: https://git.io/v5jEs
distro/Item14237 108ffae Vadim Belman: Item14237: More extension manager documentation
[02:04]
***GithubBot has left [02:04]
FoswikiBothttps://foswiki.org/Tasks/Item14237 [ Item14237: Implement Development.OOConfigSpecsFormat proposal ] [02:04]
GithubBot[distro] gac410 pushed 1 new commit to master: https://git.io/v5jEW
distro/master 8a292e6 George Clark: Item13883: Merge branch 'Release02x01'
[02:06]
***GithubBot has left [02:06]
ChanServ sets mode: +o Lynnwood [02:13]
ChanServ sets mode: +o Lynnwood__ [02:18]
ChanServ sets mode: +o Lynnwood
ChanServ sets mode: +o Lynnwood__
ChanServ sets mode: +o Lynnwood_
ChanServ sets mode: +o Lynnwood
ChanServ sets mode: +o Lynnwood__
[02:23]
ChanServ sets mode: +o Lynnwood
ChanServ sets mode: +o Lynnwood__
ChanServ sets mode: +o Lynnwood_
ChanServ sets mode: +o Lynnwood
[02:38]
ChanServ sets mode: +o Lynnwood__ [02:55]
...... (idle for 25mn)
ChanServ sets mode: +o Lynnwood [03:20]
ChanServ sets mode: +o Lynnwood__ [03:32]
......... (idle for 41mn)
ChanServ sets mode: +o Lynnwood [04:13]
...... (idle for 28mn)
ChanServ sets mode: +o Lynnwood
ChanServ sets mode: +o Lynnwood__
[04:41]
........... (idle for 52mn)
ChanServ sets mode: +o Lynnwood [05:34]
........... (idle for 51mn)
GithubBot[distro] MichaelDaum pushed 1 new commit to Item14288: https://git.io/v5jKN
distro/Item14288 3d9656a MichaelDaum: Item14288: Merge 'origin/master'
[06:25]
***GithubBot has left [06:25]
FoswikiBothttps://foswiki.org/Tasks/Item14288 [ Item14288: rewrite to support pluggable edit engines ] [06:25]
***ChanServ sets mode: +o MichaelDaum [06:25]
......................... (idle for 2h2mn)
stefan_slight has left [08:27]
.................................... (idle for 2h56mn)
ChanServ sets mode: +o Lynnwood [11:23]
ChanServ sets mode: +o Lynnwood__ [11:30]
................... (idle for 1h33mn)
ChanServ sets mode: +o gac410 [13:03]
.... (idle for 16mn)
zak256I see the .changes file differs in syntax between our old version (1.1.2) and the latest 2.1.
Can I migrate, i.e. copy it nevertheless or should I convert it to the new format?
[13:19]
gac410I'm not really sure what the best recommendation is. There is a backwards compatiblity (expert) option under the RCSStoreContrib. [13:22]
zak256Does that have to do with RCS ? [13:23]
gac410PlainFile store didn't exist on 1.x, so no need for backwards compat.
The code that reads .changes attempts to determine the format and will read the old format, and then write out the updated file per the TabularFormat setting.
[13:25]
zak256Ah, cool. So I can just copy it then. Thanks. [13:26]
gac410However I have seen one issues where that didn't work. ... on foswiki.org / trunk.foswiki.org But couldn't recreate it.
but yes, just copy it.
[13:26]
zak256As long as nothing seriously goes wrong... [13:27]
gac410worst case just remove it. You will mis email notification of changes across the conversion boundary but if you run a mailnotify before you convert. that should be covered. [13:28]
zak256Ah... mailnotifications are least important. I will just skip those files then. [13:31]
gac410The "WebChanges" page use search for modified dates. the old (mostly unused afaik) bin/changes script uses the .changes files, as does mailnotify. I'm not aware of other users. [13:33]
zak256ok
I am just looking at the new SmiliesPlugin and realize all those smilies are now much bigger and animated.
I must admit in most cases I prefer the smaller ones. But I will see later how the integrate into the topics.
*they*
[13:34]
gac410The old ones are 15x15, some are animiated, but not as many. The new ones are 19x19 [13:38]
zak256We have some pages with tables and a :) resp. :( gives a state of some kind.
Maybe the animations will be a bit noisy in the page then.
But I will just create new ones in a template then, no problem.
[13:39]
.... (idle for 19mn)
vrurggac410: Good morning! :) Small question: do you remember how to quickly check if fastcgi is in action? [14:00]
gac410vrurg: Check the current value of Engine config variable?
That one is never saved. It's set during initialization
[14:05]
vrurgI thought about checking on apache level but Engine might be sufficient.
Thanks!
[14:07]
gac410yw [14:09]
vrurgA coworkern is trying to convert our local wiki to fastcgi. Of course he failed! ;) [14:13]
gac410If it's 2.x, it should be pretty simple. [14:13]
vrurgI didn't use fastcgi for too long now. Forgot everything except the basic concepts. [14:14]
gac410It's really just apache config. Nothing to configure in foswiki. On foswiki 1.x, you need to install FastCGIEngineContrib, but 2.x bundles it.
On 2.x, The System.FoswikiServerInformation shows the engine status.
(When you asked how to check, I assumed you were askgin about code, not from an end user perspective )
[14:14]
vrurggac410: Do I need to start the .fgci manually? Apache claims to handle it but it doesn't. Though I didn't find FcgiWrapper config... [14:16]
gac410No apache should do it automatically.
I've never needed to start it. it "just works"
[14:17]
vrurggac410: It was correct assumption. I'm rarely putting my hands on apache config. Especially with 3.0/PSGI in mind. ;) [14:17]
gac410Foswiki:Support.ApacheConfigGenerator .... it will generate a correct apache configuration [14:18]
FoswikiBothttps://foswiki.org/Support.ApacheConfigGenerator [ ApacheConfigGenerator ] [14:18]
vrurgThat ... guy... He left the old CGI-based config loadable. So, that was the one working, not FastCGI. Now it just fails and this is much easier to trace down. ;)
gac410: He used the generator. But currently something went wrong as .fcgi is not started. Anyway, thanks! I will proceed on my own from this moment. Thanks a lot!
[14:18]
gac410you can indeed have fcgi and cgi exist. I've done it when debugging reusable code issues. have /cgi/bin url path point to handler for cgi rather than fastcgi [14:19]
vrurgBut this is not what I need. I told the guy to abandon CGI and he choose to go with fcgi. [14:25]
gac410y fcgi is probably a better choice than mod_perl [14:26]
zak256Can anybody verify that there are indeed no cell borders in the calendar from https://foswiki.org/Extensions/CalendarPlugin ?
Even in the example on this page?
[14:28]
vrurgzak256: I don't see any borders. [14:30]
zak256There are none in my test installation of Foswiki 2.1.4 with the plugin installed as well, but in our old wiki there are borders.
Now I am trying to figure out why.
[14:30]
gac410What version is your old wiki running? [14:31]
zak256CalendarPlugin 2.000, $Rev: 8058 (2010-07-07)
Wiki is 1.1.2
[14:31]
gac410I don't know. There were a bunch of changes done by SvenDowideit on Item11202 ... they were abandoned. The plugin still seemed to work and I had to update it for compatibility, and those changes were included. [14:34]
FoswikiBothttps://foswiki.org/Tasks/Item11202 [ Item11202: modernise CalendarPlugin ] [14:34]
zak256Hmm... right now I first try to identify the css responsible for the border first.
Maybe I can track that down afterwards.
[14:34]
I think the default is to show borders, but those are somehow removed by something in styles.css...
style.css
[14:41]
gac410gac410 is very limited with css knowledge. Leaves it to others whenever possible. MichaelDaum: .... iirc, you wanted to release some extensions before I updated blog.foswiki.org to the latest. Do you still have things to finish up? [14:42]
zak256the rules are border-collapse:collapse and border-spacing:0
unfortunately style.css is not very readable because it doesn't have line breaks
[14:44]
MichaelDaumgac410, which plugins are you gonna upgrade? [14:45]
gac410gac410 has to go look. Right now I'm re-uploading UpdatesPlugin on f.o from testing. [14:45]
MichaelDaumy [14:46]
gac410DBCache* Filter, FlexForm, JQDataTables JQSerialPager, MimeIcon, MoreFormfields, MultiLingual, TopicInteraction, WebFonts [14:47]
MichaelDaumplease wait for NatSkin/NatSkinPlugin having aired [14:48]
gac410okay will do.
MichaelDaum: message now says: Warning: Updates found for 1 extension(s): 11 Upgrade Ignore for 7 days
Oh... no... it's fixed
I did a refresh=cache, but I didn't click the button to re-check for changes.
[14:49]
MichaelDaum: Something very strange is going on. I installed Testing UpdatesPlugin to blog.foswiki.org, restarted apache and refreshed cache. But... On foswiki.org cookie "value" contains FilterPlugin, and message is correct.
But on blog.f.o, cookie value contains 11, and message shows the "11" as the list of extensions.
[15:00]
MichaelDaumdid you update UpdatesPlugn on b.f.o as well?
they probably both write to the same cookie ...
[15:04]
gac410yes. And I just checked. Loaded module is 1.04.
Yes same cookie. But I delete the UPDATESPLUGIN cookie then go to the other site and test
I just restarted apache a 2nd time. and re-refreshed cache. This is really strange.
[15:04]
MichaelDaumthey write to different domains: this version of natskin does not yet display the new UpdatesPlugin message
so it only reports the number of updates only
hm still
[15:06]
gac410Ah... it's a skin issue. I didn't realize that the plugin had components in the skin. [15:07]
MichaelDaum... [15:07]
gac410Strange that the cookie is different Value="FilterPlugin" vs. Value="11" [15:07]
MichaelDaumy
for some reason blog.foswiki.org writes cookies for domain foswiki.org
[15:07]
gac410Yes it's supposed to.
Otherwise you have to sign in twice
[15:08]
MichaelDaumgot a call ... laters [15:08]
gac410laters [15:08]
hm I think that it's a js issue. If the json array returned by the "check" handler is > 1 entry, it's saving the count rather than the list of plugins into the cookie.
But my js skills are about as good as my css skills ... non-existent
[15:22]
...... (idle for 25mn)
As far as cooike domain, The js writes the cookie, so maybe in this case, it should force the full host.domain. Since it is most likely host specific
Commenting out a line in the updates plugin js fixes the realm issue
//self.options.cookieDomain = foswiki.getPreference('COOKIEREALM');
[15:47]
........ (idle for 38mn)
zak256Why are there three variants of css files? file.css, file.css.gz and file.uncompressed.css ?
Ah, first one seems to be the one-liner
uncompressed is readable, and gz is clear.
[16:29]
...... (idle for 26mn)
vrurgAny idea why would apache be leaving behind a number of foswiki.fcgi processes after stopping? [16:56]
gac410vrurg: they should eventually clean up.
zak256: gz is compresses, uncompressed is for debugging .css is minified for efficiency
[17:10]
vrurgAt some point I've got more than a dozen of them. It was worrying. ;) Ok, thanks. I guessed it should be this way but wanted to make sure. [17:11]
gac410There are ways to tell foswiki to use the uncompressed version, or you can copy the uncompressed over the top of the minified version. It should work [17:11]
zak256Ok, I just had to change max-height:19px to 22px because the old confused.gif would otherwise be scaled down.
...in smilies.css
Luckily there are only two rules in there, so no problem editing the main file.
And I recognized the SmiliesPlugin doesn't support png files :(
[17:11]
gac410vrurg I have seen them hang around. I'm not sure why. You can always safely kill fcgi processes and apache will restart as needed. That's an advantage of fcgi vs mod_perl You can reload without restarting/reloading apache
zak256: Did it used to?
[17:13]
zak256I don't know, probably not. The old icons were all gif, the new ones are png.
I couldn't figure out why that is, looked at the perl file... but nevermind, I just converted the file to gif and it works.
Now all those small issues pop up when looking at our pages in the new wiki :-/
[17:13]
vrurggac410: I know. Actually, it's ok and rather good to have a number of them when apache runs – it usually means requests are load-balanced (more/less). I was just wondering if that's ok for them to stick around after httpd shutdown. [17:14]
gac410zak256: was it causing a 404, or just not displaying. Really it should not care The browser usually figures out the graphic format from magic. [17:15]
vrurgvrurg is trying to trace down a problem and cannot use FOSWIKI_ASSERTS as the code fails with a taint issue. :( [17:16]
zak256No, it wasn't displayed. Using my firefox debugger I saw that it somehow added .gif to the filename, although I wrote .png in the topic
Now I realize maybe I should SHIFT-Reload the page again...
[17:16]
gac410vrurg, remove the Taint::Runtime
Now that we don't use the -t switch on the perl options, it's established dynamically if Taint::Runtime is available. otherwise it warns.
There is an upstream bug in CGI::Session which upstream does not want to fix. Really annoying.
Both TWiki and Foswiki have run into it.
[17:17]
vrurggac410: I'm about to do it... [17:19]
zak256Ok... png is indeed supported, sorry for the noise. SHIFT+Refresh worked. [17:19]
gac410https://rt.cpan.org/Public/Bug/Display.html?id=80346 [17:19]
vrurgOk, it's a bug... Damn. Thanks again! [17:19]
gac410The TWiki bug is claiming its not reproducable on the latest debian Stretch. http://develop.twiki.org/do/view/Bugs/Item7721
I tried n ways to sunday to untaint the session id, but it gets re-tainted in CGI::Session::Driver so nothing Foswiki can do about it.
[17:23]
From what I can gather, the bug is related to this change in PathTools 3.62
- ensure File::Spec::canonpath() preserves taint (CVE-2015-8607)
[17:30]
vrurgHm, that's no good news for me as I'm using File::Spec quite heaviliy. Though, luckily, never needed canonpath() yet. [17:33]
***zak256 has left [17:43]
vrurgfastcgi and its famous tied STDERR... Damn it... [17:48]
gac410That's why on occaision I leave an alternate aliase for /cgi/... enabled for non-fcgi access [17:49]
vrurgUnfortunately, I'd have to switch to mod_perl now. Cannot allow it using different engines for different topics. [17:52]
....... (idle for 30mn)
***ChanServ sets mode: +o Lynnwood [18:22]
....................... (idle for 1h53mn)
ChanServ sets mode: +o Lynnwood__ [20:15]
........... (idle for 52mn)
daemon has quit IRC (Read error: Connection reset by peer) [21:07]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)