| ../irclogs/#mantishelp.2009-06-10.log | ||
| --- scribe started --- | 00:00 | |
| mantisbot | New bug: Bug 10574 - Jimi_Joma - open - new | 06:58 |
|---|---|---|
| mantisbot | New bug: Tableheader are not generated - http://www.mantisbt.org/bugs/view.php?id=10574 | 06:58 |
| dhx_m | can we have another look at 10330 for the 1.2 release? (would it be better if I split the renaming of constants for a later release?) | 08:12 |
| giallu | bug 10330 | 08:48 |
| giallu | wake up mantisbot! | 08:49 |
| dhx_m | haha | 09:05 |
| giallu | bug 10330 | 09:05 |
| dhx_m | it was the one where I went through and removed all hardcoded uses of enum levels within the source code | 09:05 |
| dhx_m | and replaced them with thresholds/etc from the config file | 09:06 |
| giallu | ah it's mantisbt.org that is dead... | 09:06 |
| dhx_m | it is a serious bug IMO to use hardcoded values | 09:06 |
| wuehli | what's with mantisbt.org? | 10:13 |
| wuehli | i cannot reach it | 10:13 |
| wuehli | i better use googles cache then | 10:14 |
| dhx_m | yeah it's dead at the moment | 10:17 |
| wuehli | i am a total mantis newbie, just try it out at my local computer | 11:13 |
| wuehli | now i wanted to change the administrator password to something else | 11:14 |
| wuehli | and now i cannot even log in | 11:14 |
| wuehli | how can i fix this? | 11:14 |
| dhx_m | using administrator/root as the login? | 11:14 |
| wuehli | that doesn't work sadly :( | 11:14 |
| wuehli | it worked two minutes ago | 11:14 |
| dhx_m | what did you do in that time? | 11:15 |
| wuehli | try to change the password | 11:15 |
| wuehli | but it doesn't work to log in now :( | 11:15 |
| dhx_m | sounds like you might have mistyped the new password or something | 11:15 |
| dhx_m | so you might need to manually reset the password | 11:15 |
| wuehli | perhaps | 11:15 |
| wuehli | how to do that? | 11:16 |
| dhx_m | are you using MySQL? | 11:19 |
| dhx_m | or do you have some other way to edit your database manually? | 11:19 |
| wuehli | dhx_m: yes, mysql | 11:35 |
| AzaTht | site down? | 11:35 |
| wuehli | dhx_m: i am away for a bit, come back soon | 11:35 |
| dhx_m | AzaTht: yep | 11:36 |
| AzaTht | dhx_m: severe or temp? | 11:36 |
| dhx_m | wuehli: ok, but seeing as you just installed it, it might be easier to just reinstall over-the-top? | 11:36 |
| wuehli | dhx_m: okay | 11:36 |
| dhx_m | AzaTht: will most likely be fixed in a few hours when paul_ is about :) | 11:36 |
| AzaTht | heh | 11:36 |
| dhx_m | AzaTht: assuming it isn't a datacentre problem or something more severe | 11:36 |
| AzaTht | [13:37:00] -NickServ- paul_ is not registered. | 11:37 |
| AzaTht | people should remember to register alt nicks | 11:37 |
| dhx_m | I must admit I haven't bothered registering here yet | 11:39 |
| dhx_m | was waiting for another nick to possibly become available after the FreeNode cleanup :D | 11:39 |
| AzaTht | hehe | 11:40 |
| AzaTht | when is the purge going to take place now again | 11:41 |
| dhx_m | not sure, messages said it'd be "today" or "very soon" | 11:41 |
| dhx_m | might have already happened for all I know :) | 11:41 |
| AzaTht | # It will take place at 9am UTC on Thursday 11th June 2009. | 11:42 |
| AzaTht | gonna try register AzaToth then :) | 11:45 |
| dhx_m | ./nickserv info something | 11:45 |
| dhx_m | will return the status of the nick "something" | 11:45 |
| AzaTht | I know | 11:46 |
| AzaTht | /ns info AzaToth | 11:46 |
| AzaTht | -NickServ- Last seen : Feb 20 15:05:25 2009 (15 weeks, 4 days, 20:39:20 ago) | 11:46 |
| dhx_m | yep | 11:46 |
| dhx_m | 60 days seems a very short period for deregistering nicknames | 11:47 |
| dhx_m | what if you go overseas for 3 months and don't use IRC in that time? etc | 11:47 |
| AzaTht | if you have an project cloak, then you are rather safe | 11:48 |
| dhx_m | ah ok, that makes sense then | 11:48 |
| AzaTht | # We will try avoid expiring project cloaked user nicknames. | 11:48 |
| nuclear_eclipse | AzaTht: that would be nice if they ever got around to approving my project group.... | 11:54 |
| dhx_m | hey :) | 11:54 |
| dhx_m | hah | 11:54 |
| nuclear_eclipse | I think it's been about a year now since I submitted a request for a FreeNode group, and bugged them in #support multiple times since then, and it's always "they're really buy, yours is still in the queue...." | 11:55 |
| nuclear_eclipse | I eventually just gave up all hope of ever getting a project registered here... | 11:56 |
| dhx_m | must be a very complex and time consuming process :rolleyes: :p | 11:57 |
| dhx_m | do they run a DNA check on you first? | 11:57 |
| nuclear_eclipse | well, the problem is that they actually have somebody *call* you about the project, and whatever else to make sure it's legitimate, so it can't be automated in any way... | 11:58 |
| dhx_m | ah ok | 11:58 |
| dhx_m | seems odd that they don't accept a statement/password provided on the official website of the project | 11:59 |
| dhx_m | or something to that effect | 11:59 |
| nuclear_eclipse | I've been tempted to just bomb their project submission form in hopes that they'll actually notice it, but I'm sure it won't help my chances, and it would take more effort =\ | 11:59 |
| dhx_m | hah | 12:00 |
| AzaTht | heh | 12:04 |
| nuclear_eclipse | wow, how did I miss the fact that mantisbt.org was down? | 13:03 |
| nuclear_eclipse | I just restarted httpd there; it's back up now | 13:03 |
| kenguest | nuclear_eclipse: there's no nagios or other type of monitoring set up to watch it? | 13:05 |
| nuclear_eclipse | no, not currently | 13:05 |
| nuclear_eclipse | no my server :P | 13:06 |
| nuclear_eclipse | not* | 13:06 |
| nuclear_eclipse | might look into it though | 13:06 |
| dhx_m | yay thanks :) | 13:10 |
| nuclear_eclipse | np dhx_m ;0 | 13:10 |
| dhx_m | got any small coding tasks that need doing? :) | 13:11 |
| dhx_m | I'm in the mood for doing something | 13:11 |
| nuclear_eclipse | yeah, fix paul_ | 13:11 |
| dhx_m | haha | 13:11 |
| dhx_m | what are your thoughts on ripping out the old SVN integration? | 13:12 |
| dhx_m | to me it sounds like it'll confuse a lot of users | 13:12 |
| dhx_m | and it really isn't something that I think anyone will want to maintain | 13:12 |
| nuclear_eclipse | dhx_m: I think we need to officially deprecate it for 1.2, to give peolpe time to get set up with the new plugin framework, and have an official plan to rip it out for 1.x | 13:13 |
| dhx_m | is there any sort of upgrade path needed? | 13:14 |
| dhx_m | I haven't used the inbuilt one before so I'm not really sure how it works | 13:14 |
| dhx_m | but I imagine there is some data that needs porting across? | 13:14 |
| nuclear_eclipse | the built-in itnegration is rather primitive; your VCS hook executes a CLI PHP script, passing it a text body that Mantis a) parses for related issue #s, and then b) attaches a note to each related issue containing the entire text body passed to the script | 13:15 |
| dhx_m | ah, so there isn't really an upgrade path then | 13:16 |
| dhx_m | because data has already been lost in the old plugin | 13:16 |
| dhx_m | s/plugin/implementation | 13:16 |
| nuclear_eclipse | so afaic, there is no upgrade path other than to tell users how to configure the source-integration plugin to use the same regexes/features that the built-in integration uses | 13:16 |
| dhx_m | then is there any benefit of keeping two implementations around at once? | 13:17 |
| dhx_m | if someone asks for help on the deprecated feature, they're not going to get assistance | 13:17 |
| dhx_m | and I would have thought most people would do the upgrade to the new plugin based VCS feature when going from 1.1 to 1.2 | 13:18 |
| nuclear_eclipse | the benefit is that existing users are expecting 1.2 to continue functioning like 1.1 -- by officially deprecating the feature for 1.2, it keeps existing users happy, while letting them know that the feature is getting EOL'd, and giving them direction on where to look in the future | 13:18 |
| dhx_m | although a lot of things aren't functioning like 1.1 - dates for example | 13:18 |
| nuclear_eclipse | dhx_m: to the users, dates function just like 1.1 | 13:18 |
| dhx_m | and I don't see anything wrong with that, as long as users are notified that upgrading to 1.2 will break X, Y and Z | 13:19 |
| dhx_m | ah ok, so you're only talking about user-visible changes? | 13:19 |
| nuclear_eclipse | right | 13:19 |
| dhx_m | wouldn't there be an equal/greater concern for in house plugins/modifications made by people for 1.1 that no longer work with 1.2? | 13:19 |
| dhx_m | IMO if the changes are clearly spelled out for people looking to upgrade to 1.2, there shouldn't be an issue | 13:20 |
| nuclear_eclipse | true, but considering we've never supported anyone with a modified install anyways, I don't see how that's relevant | 13:20 |
| dhx_m | true | 13:20 |
| dhx_m | but it seems a little unfair to me that we'd keep a deprecated feature and every time someone asks for support, they're told to upgrade to the new thing | 13:21 |
| dhx_m | it seems like someone they should of been told about when upgrading to 1.2 so they could perform the upgrade straight away | 13:21 |
| nuclear_eclipse | dhx_m: that's how deprecation works, and I never said we wouldn't support their use of the deprecated feature... | 13:22 |
| dhx_m | hmm I don't really have a problem myself (I track the master repo) | 13:22 |
| dhx_m | but I thought it might make support/maintenance easier | 13:23 |
| dhx_m | although I doubt anyone uses it, so the number of bugs being filed for that feature will likely be low :) | 13:23 |
| nuclear_eclipse | dhx_m: coming from the point of view of users that don't track Mantis development, they see that 1.2 is out, download it, and start to upgrade their site, and then find out that source integration no longer works would cause a lot of a) user frustration, and b) support requests for users thinking it's broken -- by making the deprecation part of the release announcements and so forth, it will a) let them know that it's going to be removed, and b) | 13:26 |
| dhx_m | shouldn't users be reading the release notes before upgrading, so they know that as part of the upgrade, they need to switch to use the new VCS integration | 13:26 |
| dhx_m | I always thought the kernel API approach to deprecation was used when it was possible to use both the old and new approaches at the same time | 13:27 |
| Ronald | Hi, is there documentation about what is possible how regarding plugins? --- Looking for chained dynamic allocation of 'custom' fields.... (Custom field 1 filled from mysql; field 2 gets allocated depending on selected value in field 1, etc) | 13:27 |
| dhx_m | whereas in this case, that makes no sense... users will only use one approach (either old or new) | 13:27 |
| nuclear_eclipse | Ronald: http://docs.mantisbt.org/master/en/developers | 13:27 |
| nuclear_eclipse | dhx_m: the reason it maeks sense is because source-integration is not included with mantisbt | 13:28 |
| nuclear_eclipse | if source-integration was a core feature, then it wouldn't be an issue -- it would just be a feature upgrade | 13:28 |
| dhx_m | true... you could always kill the project by disappearing as the lead maintainer, and Mantis would be left with nothing | 13:29 |
| paul_ | nuclear_eclipse: what projgect group? | 13:29 |
| nuclear_eclipse | but since the integration is a separate component, and because there's no immediate upgrade path, we have to be able to maintain compatibility with existing installations long enough for people to investigate and migrate | 13:29 |
| dhx_m | so maybe source-integration should be considered part of the official Mantis project? | 13:29 |
| paul_ | nuclear_eclipse: I couldn't access box earlier | 13:30 |
| paul_ | had httpd crashed? | 13:30 |
| nuclear_eclipse | paul_: was trying to get a project set up for my leetcode site, where I run/work on multiple open source stuffs | 13:30 |
| paul_ | so for 'leetcode'? | 13:30 |
| Ronald | nuclear_eclipse, could it be the docs are somewhat incomplete for now ;)? | 13:30 |
| nuclear_eclipse | paul_: httpd was pegging all four cores on the vps | 13:30 |
| dhx_m | Ronald: yeah, they're a little behind | 13:30 |
| paul_ | nuclear_eclipse: what was mysql doing? | 13:30 |
| dhx_m | Ronald: but still contain a lot of useful/relevant info | 13:31 |
| nuclear_eclipse | Ronald: it definitely is incomplete, but the events are the truly relevant bits, and they are completely documented | 13:31 |
| nuclear_eclipse | paul_: mysql was sitting at 0% cpu, it was all apache | 13:31 |
| dhx_m | I wouldn't mind fixing some documentation... maybe I should try rewriting documentation for config_defaults | 13:31 |
| dhx_m | and syncing it with the docbook stuff | 13:32 |
| paul_ | nuclear_eclipse: HMM | 13:32 |
| nuclear_eclipse | dhx_m: it's been considered making it part of core, but I'm not sure that something that full-featured/heavy-weight belongs in core... | 13:32 |
| paul_ | nuclear_eclipse: if so, that would be 'different' | 13:32 |
| dhx_m | nuclear_eclipse: all I was trying to get at is having it use http://www.mantisbt.org/bugs/ and so forth would be better than relying on an external tracker | 13:33 |
| nuclear_eclipse | dhx_m: admin/configuration documentation is all based on 1.0.x manual, so we could certainly use some time/energy spent on reworking, updating, and such on the admin guide | 13:33 |
| dhx_m | nuclear_eclipse: unless of course we implement remote relationships to bugs on different trackers :) | 13:33 |
| nuclear_eclipse | dhx_m: you lost me now :P | 13:34 |
| paul_ | we need to convert manual to xml docbook files | 13:34 |
| nuclear_eclipse | paul_: you need to stop focusing on inconsequential details... | 13:34 |
| dhx_m | nuclear_eclipse: well let's say you want to create a relationship between a bug in source-integration and the plugin framework in Mantis core | 13:34 |
| paul_ | nuclear_eclipse: well, I can't edit the existing manual ;/ | 13:34 |
| nuclear_eclipse | it doesn't really matter whether manual is in SGML or XML... | 13:34 |
| nuclear_eclipse | paul_: any text editor can edit the damn manual, it's no harder than editing HTMl.... | 13:35 |
| paul_ | the docbook editors that support wysiwyg all require .xml | 13:35 |
| nuclear_eclipse | paul_: you don't need wysiwyg... | 13:35 |
| * paul_ lazy | 13:35 | |
| Ronald | nuclear_eclipse, looks like it; bit abstract without any examples; I assume this is all for 1.2.x? | 13:36 |
| dhx_m | nuclear_eclipse: you could either do that normally by linking between two bug IDs on the same tracker... or do what launchpad does, and allow relationships to be created with bugs on remote trackers (maybe not even Mantis) | 13:36 |
| nuclear_eclipse | paul_: the problem with XML docbook is that it requires a whole new toolchain to be investigated, set up, and tested | 13:36 |
| nuclear_eclipse | Ronald: yes, 1.2 -- if you want examples, look at http://git.mantisforge.org :P | 13:37 |
| Ronald | alright. and as for 1.2; best to go from the a3 release or something nightly? | 13:37 |
| nuclear_eclipse | dhx_m: yes, I would really like to have remote relationships; see http://www.mantisbt.org/bugs/view.php?id=10543 :P | 13:37 |
| paul_ | nuclear_eclipse: I dont necessarily see that as a major hurdle | 13:37 |
| nuclear_eclipse | of course you wouldn't... | 13:37 |
| nuclear_eclipse | but it works perfectly fine in SGML at the moment... | 13:38 |
| dhx_m | nuclear_eclipse: yep, that would be very nice :) | 13:39 |
| nuclear_eclipse | dhx_m: it's all down to the implementation now... ;) | 13:39 |
| dhx_m | dhx_m: to me it sounds like the relationships API needs reworking along with a new mantis_relationship_table schema | 13:41 |
| dhx_m | here I am talking to myself now :p | 13:42 |
| Ronald | nuclear_eclipse, did you see my last Q? ---- and finally is it likely I won't have to redo all my plugin work as 1.2 development goes along? (I have this 'fine' coworker insisting on something imho irrelevant for which i'd need all this) | 13:42 |
| nuclear_eclipse | Ronald: yes, nightly builds are definitely "preferred" at this point; we should have been making more test releases all along.... | 13:43 |
| nuclear_eclipse | and yes, the existing portions of the plugin system should be rather stable | 13:43 |
| Ronald | excelent :) | 13:43 |
| Ronald | thanks | 13:43 |
| nuclear_eclipse | np | 13:43 |
| dhx_m | nuclear_eclipse: example schema: relationship_id, source_bug_id, relationship_type, destination_bug_id, destination_type, destination_url, ... | 13:43 |
| nuclear_eclipse | dhx_m: that's why I don't think it'll be making it into 1.2 unless it's a completely standalone plugin | 13:44 |
| dhx_m | nuclear_eclipse: although maybe it'd be better to have a table of "remote bug trackers" so that you have a central place to change URLs, user/pass things to update the remote repo, etc | 13:44 |
| dhx_m | nuclear_eclipse: yep, there is no chance for it in 1.2... too much work | 13:45 |
| nuclear_eclipse | ie, if it's fully self-contained, than any 1.2 install can use it if they want it | 13:45 |
| dhx_m | I'm not sure it can be fully contained, unless it completely replaces the existing relationships support in Mantis | 13:45 |
| nuclear_eclipse | yeah, I think that defining a set of "blessed" remote trackers/types would be the most prudent... | 13:45 |
| dhx_m | but would that mean users have to first add a remote tracker before they can create a relationship with it | 13:46 |
| nuclear_eclipse | which makes sense IMO | 13:46 |
| dhx_m | assuming of course Mantis couldn't just add it automatically on the first use | 13:46 |
| dhx_m | yep | 13:46 |
| dhx_m | from a user standpoint, they'd just want to punch in the URL to the bug and let Mantis do the rest for them | 13:46 |
| dhx_m | the admin of the local tracker can come along later and clean it up/adjust sync settings/etc later? | 13:47 |
| nuclear_eclipse | eg, if the plugin new about a basic set of tracker "types" (such as Trac, BugZilla, Launchpad, etc), then an admin could simply define a list of remote trackers, each of a given type with a specific base url pattern, and then the plugin can figure out the rest | 13:47 |
| dhx_m | would it only be a pull system where Mantis pulls from the remote tracker? or would it also push changes? | 13:47 |
| dhx_m | yep | 13:47 |
| nuclear_eclipse | depends on how ambitious the plugin author is :P | 13:48 |
| dhx_m | but what if some of those are private and need a user/pass to view it? | 13:48 |
| dhx_m | that is why I think it needs to be possible to define some "sync settings" on a per-tracker basis | 13:48 |
| dhx_m | not just per-tracker-type basis | 13:48 |
| dhx_m | the architecture to me sounds like it should be like source-integration | 13:49 |
| nuclear_eclipse | well, that's what I meant | 13:52 |
| dhx_m | yep :) | 13:52 |
| nuclear_eclipse | eg, have a few base tracker types, and allow an admin to create information about a remote tracker, giving it a base type, a base url, and any other necessary info, and then users just select a remote tracker by name and tell it was the remote bug # is | 13:52 |
| dhx_m | although I see victor mentioned some work he did on the SOAP feature in Mantis (on the ML) | 13:53 |
| dhx_m | I guess that would be something that is used where possible to talk to other bug trackers that also support SOAP | 13:55 |
| dhx_m | but most trackers don't support SOAP (afaik) so it'd still be necessary to communicate via other ugly means | 13:55 |
| wuehli | Fatal error: Cannot access private property PHPMailer::$smtp in /usr/share/mantis/www/core/email_api.php on line 805 | 14:59 |
| wuehli | what can i do then? | 14:59 |
| mantisbot | New bug: Bug 10575 - buknon - open - new | 15:02 |
| mantisbot | New bug: autocomplete for profile with full test search in all related field - http://www.mantisbt.org/bugs/view.php?id=10575 | 15:02 |
| wuehli | i was trying to create a new account | 15:02 |
| nuclear_eclipse | wuehli: what version are you using? | 15:34 |
| wuehli | the version, that debian testing did provide | 15:36 |
| wuehli | 1.1.6 | 15:37 |
| wuehli | anyway i managed to create that new account nevertheless | 15:38 |
| wuehli | don't know what i did exactly :) | 15:38 |
| nuclear_eclipse | I think it's a problem with phpmailer that we fixed in the version we include in our releases, but I can't remember | 15:38 |
| wuehli | okay | 15:38 |
| nuclear_eclipse | my only suggestion is to try running an official 1.1.8 release tarball from our site, and see if you still have the same problem | 15:39 |
| wuehli | i think as my company uses debian i stick with that debian version for now | 15:39 |
| wuehli | nuclear_eclipse: but thanks for answering! | 15:39 |
| nuclear_eclipse | dhx_m: I think you just increased the scope of #10543 by about three orders of magnitude with your comment :P | 15:40 |
| nuclear_eclipse | wuehli: you're welcome; the debian maintainer sometimes idles here (aptituz), so you might try sticking around and asking him if he knows about the problem | 15:40 |
| wuehli | nuclear_eclipse: ah, cool | 15:41 |
| nuclear_eclipse | actually, aptituz_ is here right now, but not sure if he's afk | 15:41 |
| wuehli | i just come back to #freenode in the next days and listen to you, i might learn something :) | 15:44 |
| dhx_m | nuclear_eclipse: haha | 15:44 |
| dhx_m | nuclear_eclipse: although it is harder than it initially sounds with pushing/pulling | 15:45 |
| nuclear_eclipse | dhx_m: I think that push/pull balloons complexity far too large | 15:45 |
| dhx_m | nuclear_eclipse: I think things should only ever happen on a push basis anyway | 15:46 |
| nuclear_eclipse | or at least push/pull with automatic status setting, etc | 15:46 |
| dhx_m | nuclear_eclipse: in terms of efficiency and scaling | 15:46 |
| nuclear_eclipse | the most I'd like to see is a note/notification if the remote issue changes, and otherwise leave it up to the local site/users to update the local issue as needed | 15:46 |
| dhx_m | nuclear_eclipse: although that is an unrealistic dream, so I guess pulling is required... even though it is an ugly approach | 15:46 |
| dhx_m | yep I think I agree with you there | 15:47 |
| dhx_m | otherwise it gets too complex | 15:47 |
| dhx_m | and you suddenly need 150 new settings to toggle for each bug tracker you link in | 15:47 |
| dhx_m | what is the closed or resolved status on the remote tracker? 2 settings | 15:48 |
| nuclear_eclipse | yeah, I don't like lots and lots of settings | 15:48 |
| dhx_m | what is the URL? HTTP or HTTPS? etc | 15:48 |
| dhx_m | then you can get into even more fun... TLS certificates (client side, server side, etc) | 15:49 |
| nuclear_eclipse | source-integration has more settings than a like, but it's the only way to do that much without assuming too much | 15:49 |
| dhx_m | I think it is OK myself | 15:49 |
| dhx_m | it's not like you have "Number of changesets to import each cycle" :D | 15:51 |
| nuclear_eclipse | lol | 15:52 |
| * paul_ pokes nuclear_eclipse | 17:30 | |
| nuclear_eclipse | hi paul_ | 17:40 |
| paul_ | did you see http://www.theregister.co.uk/2009/06/08/webhost_attack/ ? | 17:41 |
| nuclear_eclipse | ouch | 17:42 |
| paul_ | some of the flaws (http://securityreason.com/wlb_show/WLB-2009060016) e.g number 8 look quite cute ;p | 17:43 |
| paul_ | nuclear_eclipse: did you look at the url then when your network came back last night/ | 18:05 |
| nuclear_eclipse | paul_: yeah, it's the same paste you gave me from the previous day? | 18:06 |
| paul_ | probably | 18:06 |
| nuclear_eclipse | disregarding function naming, I just still don't understand why you're so opposed to what I've done | 18:07 |
| paul_ | because I think we should go through properly | 18:08 |
| paul_ | the visible bugs are mainly fixed already | 18:08 |
| paul_ | for example | 18:08 |
| paul_ | atm, we we use str_pad to display a seperator under heading in changelog | 18:08 |
| paul_ | as a question, couldn't we do that with CSS? | 18:08 |
| paul_ | then people could format the header | 18:08 |
| nuclear_eclipse | well, let's ignore roadmap/changelog; they're rubbish anyways | 18:09 |
| nuclear_eclipse | I just think that it's the wrong approach to use two different variants of the same function throughout the code based on the context of what's in the variable -- what's so bad about always using a utf8-capable string function, other than the very slight performance drop? I think the added simplicity/consistency in the codebase more than makes up for that... | 18:11 |
| paul_ | I'm more saying it's a manual job | 18:13 |
| paul_ | for example | 18:13 |
| paul_ | utility_api defines is_blank (is blank looks for empty string and can't use empty as empty matches (string)"0" as true | 18:14 |
| paul_ | mantisenum.class.php calls if ( strlen( trim( $enumString ) ) == 0 ) { | 18:14 |
| nuclear_eclipse | paul_: I fixed the issue with utility api | 18:14 |
| paul_ | the implementation of that is basicalyl what we define is_blank for | 18:14 |
| paul_ | bah, dinner brb | 18:15 |
| nuclear_eclipse | paul_: I still don't see how that case has anything to do with why my branch is "wrong" -- that's a problem with that portion of the code, and has no bearing on how we replace strlen with a utf8-capable variant... | 18:15 |
| paul_ | right bug objects | 18:28 |
| paul_ | and issue with utility api? | 18:29 |
| paul_ | nuclear_eclipse: can you remind me | 18:32 |
| paul_ | the tests stuff | 18:32 |
| paul_ | are you able to clarify what the function should return ? | 18:33 |
| nuclear_eclipse | I have no clue how any of testing stuff works anymore | 18:34 |
| paul_ | ignoring that a sec :P | 18:34 |
| paul_ | url_sanitize('') should return index.php right? | 18:35 |
| nuclear_eclipse | I don't remember, and I wasn't the one that set the basic logic anyways; I only fixed some of the problems with it's parsing or whatever | 18:36 |
| markw_ | is there any way to log what users login? | 18:40 |
| markw_ | I see a "last login time" but is there any logging functionality built into mantisbt? | 18:40 |
| nuclear_eclipse | there is debug logging for emails and filters, but no real audit logging for authentication or other things, no | 18:41 |
| markw_ | nuclear_eclipse: yeah, trying to track down a session problem. | 18:42 |
| nuclear_eclipse | however, with the new debug logging system in place, it should be possible to extend that to the authentication modules | 18:42 |
| nuclear_eclipse | markw_: what session problem? | 18:42 |
| markw_ | nuclear_eclipse: I think they're trying to use a shared login, but they're saying they're not. | 18:42 |
| paul_ | expected string <abc.php?#a> | 18:42 |
| paul_ | difference < xx?> | 18:42 |
| paul_ | got string <abc.php#a> | 18:42 |
| paul_ | I guess that's valid | 18:43 |
| nuclear_eclipse | right, the ? is supelfluous/unneeded | 18:43 |
| markw_ | nuclear_eclipse: I was looking at checking the logins and say "yeah, right here, you had 3 different systems login in the last 5 minutes" | 18:45 |
| markw_ | nuclear_eclipse: they try to go to the "view my items" page and it sounds like it kicks them back to the login. | 18:46 |
| nuclear_eclipse | markw_: with mantis, that should actually work just fine, assuming that they're using the correct username/password | 18:46 |
| markw_ | using the same username/password? | 18:46 |
| nuclear_eclipse | are they getting an error about an "invalid session"? | 18:46 |
| paul_ | nuclear_eclipse: is the expectation we encode array( 'plugin.php?page=Source/list&id=1 to %2F ? | 18:47 |
| nuclear_eclipse | paul_: I don't know | 18:47 |
| paul_ | well, you modified it ;/ | 18:47 |
| nuclear_eclipse | lies | 18:47 |
| markw_ | nuclear_eclipse: problem is that it's developers in japan trying to read what the fieldtesters in the US are submitting. | 18:48 |
| markw_ | Here's the description of the "problem" | 18:48 |
| markw_ | This message is displayed as soon as changing to other ID. | 18:49 |
| markw_ | However, it is possible to change to a detailed page on each page once every 30 | 18:49 |
| markw_ | times. | 18:49 |
| markw_ | And other members except me(they have already registered) cannot access the page | 18:49 |
| markw_ | of My view page. | 18:49 |
| paul_ | & in url's should be encoded & ? | 18:50 |
| markw_ | so there's an japanese<>english translation problem going on here. | 18:50 |
| nuclear_eclipse | markw_: I'm not sure what to say then =\ | 18:51 |
| markw_ | nuclear_eclipse: neither am I, since it works fine for the 50+ other users in the system. | 18:51 |
| markw_ | except they're not behind a corporate firewall in japan. | 18:51 |
| nuclear_eclipse | markw_: what version are you using? | 18:54 |
| markw_ | 1.2 | 18:54 |
| nuclear_eclipse | how new? | 18:54 |
| markw_ | hmm. | 18:54 |
| markw_ | a3? | 18:54 |
| nuclear_eclipse | eg, official 1.2a3 release, or something newer from git/snapshot? | 18:54 |
| markw_ | official | 18:54 |
| markw_ | we needed some of the fancy exporting stuff. | 18:55 |
| markw_ | meeting... | 18:55 |
| markw_ | bbl | 18:55 |
| nuclear_eclipse | you could try setting $g_session_validation = OFF in your config_inc | 18:55 |
| markw_ | ok, will try. | 18:55 |
| markw_ | but that could introduce security risks right? | 18:55 |
| markw_ | japan doesn't come back online until 4-5pm | 18:56 |
| nuclear_eclipse | if you were running latest snapshot, it actually allows individual users to disable validation for their own session, and would allow most users to retain the security | 18:56 |
| markw_ | anyway, have a noon meeting. | 18:56 |
| nuclear_eclipse | cheers | 18:56 |
| markw_ | hmm. | 18:56 |
| markw_ | I'll have to look at that. | 18:56 |
| markw_ | bbl | 18:56 |
| paul_ | nuclear_eclipse: what do you think the purpose of string_sanitise_url is? | 18:57 |
| nuclear_eclipse | no freakin clue | 18:57 |
| paul_ | but you fixed it last! | 18:57 |
| paul_ | nuclear_eclipse: are you able to fix the function for me? | 19:05 |
| nuclear_eclipse | that doesn't mean I understand *why* we use the function, I just understand what it's doing and how to make it behave... | 19:05 |
| paul_ | expected string <abc.php#a> | 19:05 |
| paul_ | difference < xx?> | 19:05 |
| paul_ | got string <abc.php?#a> | 19:05 |
| paul_ | could you fix that then? :) | 19:05 |
| paul_ | and you strip <script> from urls? | 19:08 |
| paul_ | and do we escape " in query strings to \" then urlencode that? | 19:12 |
| nuclear_eclipse | I don't know anymore; it's been a long time since I touched that... | 19:12 |
| nuclear_eclipse | I think right now is hardly the time to bring up random stuffs; you still need to fix/commit bug objects and due dates.... | 19:13 |
| paul_ | it's not really that random | 19:13 |
| paul_ | it means my automated cc stuff fails every build | 19:14 |
| paul_ | which means the scripts i've got to pick up formatting errors dont run | 19:14 |
| nuclear_eclipse | so stop cc from checking the url tests for the time being... | 19:15 |
| nuclear_eclipse | it's really not that hard of a concept ;) | 19:15 |
| paul_ | if ( !empty( $t_clean_pairs ) ) { | 19:19 |
| paul_ | $t_query = '?' . join( '&', $t_clean_pairs ); | 19:19 |
| paul_ | } | 19:19 |
| paul_ | shouldn't we check it's not empty before adding ? ? | 19:19 |
| Roell | I have a question | 19:36 |
| Roell | is Git supported with Mantis? | 19:36 |
| Roell | like Svn is | 19:37 |
| nuclear_eclipse | Roell: depends on how you mean | 19:38 |
| nuclear_eclipse | for 1.1.7, any VCS is supported that can use a commit hook to execute the checkin script | 19:38 |
| nuclear_eclipse | 1.1.x* | 19:38 |
| nuclear_eclipse | for 1.2.x, there is a plugin available called Source Integration (used on mantisbt.org) that has a lot more functionality, and is currently compatible with both SVN and Git | 19:39 |
| nuclear_eclipse | for the latter option, see http://leetcode.net/blog/2009/01/integrating-git-svn-with-mantisbt/ | 19:40 |
| nuclear_eclipse | for the former, see the mantisbt manual at mantisbt.org | 19:40 |
| Roell | gee thanks! | 19:47 |
| nuclear_eclipse | hmm, paul_ have you gotten any git mails? | 19:51 |
| nuclear_eclipse | just realized that the last two commits haven't triggered mails or CIA-61 | 19:52 |
| nuclear_eclipse | paul_: httpd is pegging cpu again... | 19:52 |
| nuclear_eclipse | server's still responding though atm, so can you investigate? | 19:53 |
| nuclear_eclipse | ~10 httpd processes are together pulling 100% on all four cores | 19:54 |
| nuclear_eclipse | paul_: getting a bunch of these in the log: | 19:58 |
| nuclear_eclipse | [Wed Jun 10 15:57:53 2009] [error] [client 65.55.106.242] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/bugs/core/lang_api.php on line 104 | 19:58 |
| markw_ | nuclear_eclipse: any db changes between the latest and 1.2.0a3? | 20:10 |
| nuclear_eclipse | markw_: lots and lots; we rearranged the way dates worked -- if you're actually using the due date field, latest git is currently broke on that, but otherwise it should be fine after you do a schema upgrade -- *highly reccommend* that you back up your database and installation before upgrading, just in case | 20:13 |
| markw_ | yeah, I snapshot everything nightly. I'd do a dump beforehand. I'll let the field test manager know that it may solve our problem. | 20:14 |
| nuclear_eclipse | ok | 20:14 |
| paul_ | nuclear_eclipse: sure | 20:21 |
| paul_ | nuclear_eclipse: have you updated mantis on live site? | 20:22 |
| nuclear_eclipse | paul_: it's running the 'live' branch from git, which is master from mid-may (before your date changes) with a couple small changes cherry-picked | 20:24 |
| nuclear_eclipse | do `git log live` on your local to see | 20:24 |
| paul_ | msn search ;/ | 20:26 |
| paul_ | mid may? | 20:27 |
| nuclear_eclipse | sorry, mid-april | 20:28 |
| paul_ | before or after 13th? | 20:29 |
| nuclear_eclipse | according to `git log live`, last commit from master before cherry-picking started was: | 20:30 |
| nuclear_eclipse | commit 085f672d06d774d1e2d4bffe093bf7e2579fb2fb | 20:30 |
| nuclear_eclipse | Author: Siebrand Mazeland <s.mazeland@xs4all.nl> | 20:30 |
| nuclear_eclipse | Date: Wed Apr 15 09:36:57 2009 +0200 | 20:30 |
| nuclear_eclipse | Localisation updates from http://translatewiki.net (2009-04-15 07:04 UTC) | 20:30 |
| paul_ | anyway, it's msn trying to word export everything | 20:31 |
| nuclear_eclipse | ah... | 20:31 |
| paul_ | probably cause coreformatting plugin could do with being optimised | 20:31 |
| nuclear_eclipse | or we could add rel="nofollow" to links like that... | 20:31 |
| markw_ | nuclear_eclipse: just curious, if they were sharing a login on the other end and they were using the same proxy to access mantis, would that cause session issues? Session data looks to be tracked/stored by ip in php's session dir. | 20:32 |
| nuclear_eclipse | no, mantis should handle simultaneous login on the same account just fine | 20:33 |
| nuclear_eclipse | PHP tracks session by cookie ID | 20:33 |
| markw_ | I know it did funny things with two different instances of mantis, but that was because of a session name variable or something. | 20:33 |
| nuclear_eclipse | yeah, between two installs of mantis on the same domain, you need to set them to have different cookie prefixes | 20:34 |
| markw_ | yeah, found that out. but this is the same instance. | 20:34 |
| nuclear_eclipse | yeah, in that case, the problem with proxies is when the proxy has multiple possible exit nodes with different IP addresses, in which case the session validation in mantis suspects a session hijack -- setting $g_session_validation = OFF or (in latest git) having the user uncheck "Secure Session" at login will disable that validation | 20:36 |
| markw_ | I wonder if something is being filtered at the proxy, I could see corp doing some sort of filtering. | 20:37 |
| nuclear_eclipse | paul_: http://git.mantisforge.org/w/mantisbt/jreese.git?a=shortlog;h=refs/heads/utf8 | 20:40 |
| nuclear_eclipse | paul_: http://git.mantisforge.org/w/mantisbt/jreese.git?a=commitdiff;h=8a523c480ffa7f2b97537d8695d0bac3116e3ea4;hp=265e689944698b99d412c5b14b0b5d2b366e17e4 | 20:41 |
| paul_ | nuclear_eclipse: I still think we should do it gradually :P | 20:53 |
| paul_ | albeit, plugins etc should use the public functions | 20:53 |
| nuclear_eclipse | paul_: we don't have time for gradual, and I still don't think we should have half the core using a different variant from the other... | 20:53 |
| nuclear_eclipse | I don't even understand what the point of that would be, other than performance at the expense of consistency... | 20:54 |
| paul_ | for example | 20:55 |
| paul_ | http://git.mantisforge.org/w/mantisbt/jreese.git?a=commitdiff;h=8a523c480ffa7f2b97537d8695d0bac3116e3ea4;hp=265e689944698b99d412c5b14b0b5d2b366e17e4#patch18 | 20:55 |
| paul_ | - header( 'Content-Length: ' . strlen( $t_dot_output ) ); | 20:55 |
| paul_ | + header( 'Content-Length: ' . utf8_strlen( $t_dot_output ) ); | 20:55 |
| paul_ | if that content-length is binary object, do we know utf8_strlen is safe to call on it | 20:55 |
| nuclear_eclipse | I don't see how that would mean anything... | 20:56 |
| nuclear_eclipse | if it's binary data, then there won't be any utf8 encoding, so it'll work just like strlen.... | 20:57 |
| paul_ | I still think your partly missing the point ;/ | 21:00 |
| paul_ | changing strlen->utf8_strlen on it's own is unlikely to fix utf8 bugs | 21:00 |
| nuclear_eclipse | I think you're focusing too much on picky details ;) | 21:00 |
| nuclear_eclipse | facepalm | 21:00 |
| paul_ | well, i've grepped for strlen here | 21:00 |
| paul_ | before | 21:01 |
| nuclear_eclipse | like I've told you before paul_, this is only the first step.... | 21:01 |
| paul_ | yep | 21:01 |
| paul_ | my point is i've grepped for all the non-utf8 php functions we have here | 21:01 |
| paul_ | printed them out | 21:01 |
| paul_ | and started to highlight which ones require utf8 and which ones dont | 21:01 |
| paul_ | and what ones need fixing to support utf8 | 21:01 |
| nuclear_eclipse | paul_: my point is that devs shouldn't have to look at each use and decide if it needs utf8 support or not! | 21:02 |
| paul_ | where is_blank gets called 7000 times on some pages | 21:02 |
| paul_ | i'd rather the faster version personally | 21:02 |
| nuclear_eclipse | if we just use a utf8-capable function across the board, it makes sure we never have a problem... | 21:02 |
| nuclear_eclipse | paul_: if the string is not utf8-encode, mb_strlen is just as fast as strlen.... | 21:03 |
| paul_ | the compat version isn't | 21:03 |
| nuclear_eclipse | arg | 21:03 |
| paul_ | i've spent quite a chunk of time looking at utf8 stuff over last few months | 21:03 |
| nuclear_eclipse | performance is not the only thing to worry about anyways | 21:04 |
| paul_ | for example | 21:04 |
| nuclear_eclipse | paul_: you've spent quite a chunk of time and got nothing to show but some highlighted pieces of paper; I spent an afternoon and have a patch that fixes three functions across the board, with a path for continuing the work for any other string function | 21:04 |
| paul_ | http://git.mantisforge.org/w/mantisbt.git?a=commit;h=49ca189e400a20fb4dc9ea64c61525a2cf3c5e92 | 21:05 |
| nuclear_eclipse | ok, what does that have to do with anything? | 21:05 |
| paul_ | those sort of commits are actually fixing issues | 21:05 |
| paul_ | it takes about 10 seconds to string replace strlen -> utf8_strlen | 21:06 |
| nuclear_eclipse | yes, but that has nothing to do with utf8 | 21:06 |
| paul_ | actually it does | 21:06 |
| paul_ | as wordwrap doesn't support utf8 | 21:06 |
| paul_ | but the phpmailer code to wrap text appears to | 21:06 |
| nuclear_eclipse | so that's just the next step for utf8_api.... | 21:06 |
| paul_ | no, we dont use the wordwrap function anywhere in mantis anymore | 21:07 |
| nuclear_eclipse | then who cares? you're putting up these "examples" that don't actually make a point as to why my approach is incorrect... | 21:07 |
| paul_ | i've already said i'd rather the performance increase of using strlen for core api functions where we dont require utf8 support | 21:08 |
| nuclear_eclipse | that just makes the core apis harder to understand and work with though, and I'm not sure why we should lose that for some very slight performance gains.... | 21:09 |
| nuclear_eclipse | and btw, is_blank shouldn't be using strlen anyways -- it only needs to know if the string contains any characters at all... | 21:10 |
| paul_ | !empty isn't any faster | 21:10 |
| paul_ | (as if str = "0"; then empty(str) == true, and if you add the || str == "0" check, the speend gain of empty balances out) | 21:11 |
| paul_ | unless I'm missing something | 21:11 |
| nuclear_eclipse | is_string() && isset( $s[0] )` gets around the empty('0') issue, and doesn't require counting.... | 21:11 |
| nuclear_eclipse | strlen() is linear time based on the length of the string, versus isset( $s[0] ) is constant time... | 21:12 |
| nuclear_eclipse | eg, if you have a string (like description field) that has a really long string in it, strlen() will run considerably slower than isset( s[0] ) | 21:13 |
| nuclear_eclipse | anywho, time to head home again... | 21:14 |
Generated by irclog2html.py