| 08:00.49 | *** join/#hhwiki Transputer2001 (~Transpute@pD9E2982D.dip.t-dialin.net) |
| 08:53.10 | *** join/#hhwiki cosmo (~eis@24-116-141-54.cpe.cableone.net) |
| 09:16.38 | *** join/#hhwiki pb_ (~pb@dsl-62-3-66-201.zen.co.uk) |
| 09:16.41 | pb_ | morning |
| 09:24.31 | Transputer2001 | morning :) |
| 13:29.58 | *** join/#hhwiki kencausey (ken@ken.mojodata.com) |
| 13:31.03 | *** topic/#hhwiki by kencausey -> The hh.org wiki is a mess. Let's rebuild. What functions does the wiki serve that aren't better served elsewhere? Let's try to pare the site down to 2 or 3 or 4 major sections and try to simplify things. Please see http://handhelds.org/z/wiki/WikiReorganization . Wiki janitors needed! Development version of new ipkgfind with browsing up at http://handhelds.org/~nikos/ipkgfind/htdocs/ |
| 14:07.27 | kencausey | I'm guessing http://www.emacs.org is not the official emacs website... |
| 14:40.04 | kencausey | OK, I think the tree walking is fixed now, I think I'd better fake a deeper sections table to test it more thoroughly thouhg. |
| 14:49.18 | pb_ | argh! some dude has created about a million new "Describe <foo> here" pages in the wiki. |
| 14:51.15 | pb_ | ah, hm, maybe it was a webcrawler of some kind. |
| 14:52.14 | kencausey | Yeah, I've been going through and un-wiki wording links as I find them. |
| 14:52.51 | pb_ | Look for 210.82.40.161 in the RecentChanges. |
| 14:53.40 | kencausey | Do you know how that is done? Even if it's a wikiname, stick a bang (!) in front of it |
| 14:54.58 | pb_ | kencausey: yep, I've been doing some of that myself. |
| 14:55.03 | kencausey | cool |
| 14:55.40 | pb_ | It's not all that intuitive though. Some people obviously don't really understand what the bang is for, and put it in places that weren't wikinames to start with, so you get the occasional stray ! showing up in the resulting page. |
| 14:56.24 | kencausey | Yeah, that's another reason to upgrade, I'm not sure it's out but there is/was a next generation structured text under development, not clear on what the improvements are though. |
| 14:58.18 | pb_ | Right, yeah. |
| 15:00.18 | pb_ | Did we decide on a way to handle news items, by the way? There seemed to be a general consensus that a weblog would be worth a try. Maybe we should set up geeklog and see how we get on with that. |
| 15:01.12 | kencausey | I think it was left at 'we need to install something' and it wasn't decided what. I don't think it makes a whole lot of difference. Let's try something and see how it goes. |
| 15:01.29 | kencausey | So yes, let's try geeklog. |
| 15:02.09 | kencausey | damn, my algo has an infinite recursion somewhere... |
| 15:03.45 | kencausey | ah, uncorrected typo |
| 15:04.11 | kencausey | Give http://handhelds.org/~nikos/ipkgfind/htdocs/test.phtml a try |
| 15:04.22 | kencausey | technology test for section tree traversal |
| 15:04.24 | kencausey | Seems to work |
| 15:41.25 | kencausey | hmm is php call by reference or call be value? |
| 15:43.38 | kencausey | defaults to value it seems |
| 17:07.30 | kencausey | OK |
| 17:07.39 | kencausey | I think I might have the browsing support completed |
| 17:07.51 | kencausey | Please take a look and see if anything is missing. |
| 17:08.42 | kencausey | oops, found an unfixed path bug |
| 17:10.22 | kencausey | Also I need to look at the other templates, that shouldn't take long |
| 17:16.47 | kencausey | path bug fixed |
| 18:01.46 | *** join/#hhwiki pb_ (~pb@pc2-cmbg4-3-cust239.cmbg.cable.ntl.com) |
| 18:02.00 | kencausey | The source brouhaha came to #hh |
| 18:02.11 | kencausey | Reasonably calm though |
| 18:02.28 | kencausey | What about adding the maintainer to ipkgfind package output and point to that on familiar.handhelds.org? |
| 18:02.41 | kencausey | As a temporary measure. |
| 18:04.08 | kencausey | cmarqu: Have any feelings about it? |
| 18:04.55 | cmarqu | kencausey: Seems resonable. |
| 18:05.14 | kencausey | cmarqu: Just something to tide us over for a few weeks at least. |
| 18:05.26 | cmarqu | I see MARC mangle emails like this: Josh Fryman <fryman () cc ! gatech ! edu> |
| 18:05.42 | kencausey | So you think that would be acceptable to most? |
| 18:06.05 | cmarqu | I'd hope... |
| 18:06.35 | kencausey | An alternate might be to simply have a link to a simple form which emails them, doesn't actually show the email anywhere. |
| 18:06.40 | kencausey | Clearly that's more work though. |
| 18:06.57 | cmarqu | I mean, most people's emails appear many times in ChangeLogs, unmangled. |
| 18:07.22 | kencausey | Indeed, I don't care myself, I can't live in this world without getting some amount of spam. |
| 18:07.42 | cmarqu | And with a form, the sender doesn't have "proof", as thin as the proof is in any case. |
| 18:08.15 | cmarqu | Right. In getting an email address in the first place, you kind of have opted to be contacted. |
| 18:08.21 | kencausey | Proof? The email could be emailed to both the maintainer and the sender. |
| 18:09.29 | cmarqu | Hmm, yes indeed. |
| 18:11.04 | cmarqu | I'd still say mangled and not hyperlinked would be okay. |
| 18:11.29 | kencausey | Are we assuming that any user that wants source can demangle? :) |
| 18:11.49 | kencausey | Perhaps its a good twit filter... |
| 18:11.57 | pb_ | Well, users who want source would usually have the binary package anyway, and of course they can just look at the control file for the un-mangled address. |
| 18:11.58 | cmarqu | And then document that we plan to add Source: and License: tags to the control files by sending mail to the fam list? |
| 18:12.49 | kencausey | pb_: Are you saying we should just tell them to use ipkg to query the package info? |
| 18:13.42 | kencausey | cmarqu: We have a couple more issues to, and I was hoping to deal with all at once. |
| 18:13.45 | pb_ | kencausey: I think that'd be an acceptable response. Making the information available on the web is a nice extra touch, but I don't think we need to go to heroic lengths in that regard. |
| 18:14.06 | kencausey | cmarqu: We need to get the Section: fields sorted out so that they form a more sensible tree. |
| 18:15.40 | cmarqu | kencausey: I see. |
| 18:15.47 | pb_ | fwiw, I agree with Colin that having addresses mangled and not hyperlinked is probably the best form. Debian has just been going through a bout of soul-searching w.r.t. publishing the addresses of individual maintainers on the web, and some people clearly feel strongly that this is a bad practice. |
| 18:16.21 | kencausey | 'this is a bad practice'? unmangled email addresses? |
| 18:16.50 | pb_ | Yeah. Although the majority of maintainers probably don't care at all, for the sake of an easy life it'd be best not to upset those who don't like their addresses published. |
| 18:17.46 | kencausey | So, should I or should I not add mangled address output to ipkgfind details? |
| 18:19.11 | pb_ | If it's easy to do so, my vote would be yes. |
| 18:19.27 | kencausey | Shouldn't be a big deal. |
| 18:19.33 | pb_ | Okay, cool. |
| 18:19.46 | kencausey | Let me clean up the templates first and then I'll add that. |
| 18:25.36 | kencausey | Hmm |
| 18:25.42 | kencausey | I wish Jacmet was around |
| 18:25.53 | kencausey | Do I add the browsing interface to the PDA theme? |
| 18:26.06 | kencausey | What's the criterion for HTML in the PDA theme? |
| 18:26.35 | kencausey | are tables verboten? |
| 18:27.17 | kencausey | must not be, used in query results... |
| 18:27.26 | cmarqu | I didn't even know there was a PDA theme until two days ago. |
| 18:28.46 | cmarqu | FWIW, I dislike the JavaScript "Go back" link, and I want to see the Search field on every page. But that's not important right now. |
| 18:29.06 | kencausey | Doing the browsing in the same way I did on the main page for PDAs would likely make the page too wide. |
| 18:29.39 | kencausey | cmarqu: You want the full search form on every page? |
| 18:29.48 | cmarqu | Could it just be an extra page? |
| 18:29.57 | kencausey | That's an idea... |
| 18:30.17 | kencausey | Still, you have the menu and then you have the package list... |
| 18:30.24 | kencausey | It's quite a lot of info |
| 18:30.26 | cmarqu | kencausey: Ideally, yes. Are you adding many more search options? |
| 18:30.35 | kencausey | cmarqu: None |
| 18:30.44 | kencausey | Not at the moment anywazy |
| 18:31.41 | kencausey | I;m inclined to offer them browsing but point out that they have to leave the PDA them to use it. |
| 18:31.49 | kencausey | s/them/theme/ |
| 18:33.21 | cmarqu | What does the PDA theme look like? I.e., where do I find it? |
| 18:33.36 | kencausey | add ?format=pda |
| 18:33.59 | kencausey | or &format=pda if there are existing query vars |
| 18:37.03 | kencausey | well, that's a cop out, let's see if I get any complaints. ;) |
| 18:37.16 | cmarqu | I'd give the browse column as a separate page, then open a new one for the results and provide a backlink to the browse page again. |
| 18:38.13 | kencausey | That defeats a lot of the functionality, curently if you select a section taht contains other sections you see all packages in that section and all subsections, also the list expands into a tree. |
| 18:38.38 | kencausey | But then again a huge list of packages is less that useful I guess. |
| 18:38.49 | kencausey | On a small screen. |
| 18:38.58 | cmarqu | Ah. I didn't stumble across this yet. |
| 18:39.18 | kencausey | You at my dev version? |
| 18:39.23 | kencausey | Click opie, qpe, or sword |
| 18:40.03 | cmarqu | Aha, now. |
| 18:40.33 | kencausey | That's part of what I meant about fixing the Section: field |
| 18:40.45 | kencausey | Too deepen and decrease the width of the tree |
| 18:40.49 | kencausey | s/Too/To/ |
| 18:41.54 | cmarqu | We probably can't make sure that if there are subsections, no package may appear directly under the section but has to use a subsection? |
| 18:44.18 | kencausey | Say that again? |
| 18:44.19 | cmarqu | Wishlist: I'd like to see "Information updated <date><time>" at the bottom of each package page. |
| 18:44.35 | kencausey | One thing at a time... ;) |
| 18:45.15 | cmarqu | Well, if there is "opie/applications" etc., then no package may use "opie" as "Section:" |
| 18:45.32 | kencausey | I think you miss what is happening. |
| 18:45.41 | cmarqu | Might well be :) |
| 18:45.41 | kencausey | When you click opie |
| 18:45.57 | kencausey | You see all packages that have sections that start with 'opie' |
| 18:46.08 | kencausey | So you see all packages in opie/games |
| 18:46.12 | kencausey | opie/whatever |
| 18:46.29 | kencausey | Not having packages with only opie as the section specifier is fine |
| 18:46.37 | kencausey | But it won't make the list any smaller. |
| 18:46.51 | kencausey | Or maybe I'm missing your point. |
| 18:47.45 | cmarqu | My point was, don't show any packages yet when only opie is selected (at least in the PDA theme) but force the user to choose a subsection. |
| 18:48.06 | cmarqu | Then, the "separate" page thing would work. |
| 18:48.21 | kencausey | Yes, that would be a reasonable solution. |
| 18:48.46 | kencausey | But you are also right in saying that that are packages with only 'opie' or even 'opie/' as the section specifier currently. |
| 18:48.49 | cmarqu | Maybe some usability experts would have better ideas. |
| 18:48.55 | kencausey | s/that that/that there/ |
| 18:51.33 | cmarqu | Maybe create a virtual "unfiled" section... (only half serious) |
| 18:51.58 | kencausey | And what is in that section? |
| 18:52.03 | cmarqu | But we might need to collapse sections like lib, library, libs anyway. |
| 18:52.24 | cmarqu | All packages with just "opie" or "opie". |
| 18:53.04 | cmarqu | So these would go in "opie/unfiled"... but it's ugly. |
| 18:53.19 | kencausey | I see |
| 18:53.59 | kencausey | It would have problems in general though since I see the tree getting deeper, three maybe even four levels. |
| 18:54.45 | cmarqu | Do you intend to have a set of "allowed" top level sections? |
| 18:54.54 | kencausey | That needs to be discussed. |
| 18:55.09 | kencausey | I don't want to be too fascist about it. |
| 18:55.32 | kencausey | But it would be nice to at least have some good guidelines we can point people toward and bug them individually if we need to. |
| 18:56.37 | cmarqu | If we at least could get rid of sections like "comm", "communication", "Communications"... we might repackage them. |
| 18:57.08 | kencausey | crap |
| 18:57.22 | kencausey | Looks like some people are already obfuscating their email address in the control file |
| 18:57.31 | cmarqu | Oh. |
| 18:57.34 | kencausey | | nano-stable | Martijn Mooijman <foobar at obit dot nl> | |
| 18:59.22 | cmarqu | That's from a private feed though, right? Maybe we need a lintian equivalent for familiar. |
| 18:59.44 | cmarqu | Not that it would help much in such cases... |
| 19:01.06 | kencausey | I think if the maintainter field does not include an '@' I will just ouput it as is, if it does, I'll obfuscate |
| 19:01.24 | pb_ | Good plan. |
| 19:02.56 | kencausey | Ha! |
| 19:03.03 | kencausey | The maintainer is already being shown |
| 19:03.12 | kencausey | But Jacmet didn't convert the brackets |
| 19:03.20 | kencausey | So the email can only be seen in the source |
| 19:03.23 | pb_ | Aha :-) |
| 19:03.42 | kencausey | surely php has a function for that... |
| 20:00.39 | kencausey | OK, I think the email obfuscation is working |
| 20:00.48 | kencausey | Take a look at let me know if that seems acceptable |
| 20:01.40 | kencausey | hmm |
| 20:01.50 | kencausey | http://handhelds.org/~nikos/ipkgfind/htdocs/details.phtml?package=pscalc&official=&format= |
| 20:02.01 | kencausey | I made the assumption that they would follow correct "name <email>" format |
| 20:03.22 | kencausey | Well, I'm inclined to go ahead and install as is. |
| 20:03.34 | kencausey | pb_: Not sure if you caught it, but I copped out on the PDA theme |
| 20:04.42 | kencausey | pb_: Do you have perms to modify /etc/httpd/conf/vhosts/Vhosts.conf? I would like to change DocumentRoot if so. |
| 20:05.07 | kencausey | Not until we decide to install though. |
| 20:06.12 | kencausey | And modify the cronjob path |
| 20:07.45 | pb_ | kencausey: yes, I can modify that file. |
| 20:07.57 | kencausey | Cool |
| 20:08.16 | kencausey | It's ready if everyone is satiisfied with my devel copy. |
| 20:08.29 | pb_ | Great. I'm just looking at it now. |
| 20:08.48 | pb_ | I think we'd be justified in filing bugs against packages in Familiar proper that have the Maintainer: field in a weird format. |
| 20:09.02 | pb_ | Obviously for packages in other private feeds, we'll just have to grin and bear it. |
| 20:09.15 | kencausey | Yeah, sounds fine to me |
| 20:10.43 | pb_ | Would it be easy to provide an override file to allow similar sections to be collapsed together for viewing? I'm thinking of, for example, merging "Communications" in with "communication", and so on. |
| 20:11.08 | kencausey | hmm, let me give that some though |
| 20:11.09 | kencausey | thought |
| 20:11.15 | pb_ | I think you could do it just by having a list of regexp replacements to be performed on the Section: header. |
| 20:12.14 | pb_ | i.e. make a file that says "s/Communications/communication/; s/interpreters/interpreter/", and apply that to the values as you read them from the database. |
| 20:12.32 | kencausey | Are you thinking about doing it to the packages file as they are processed and the database is setup or on the database each time a page is rendered? |
| 20:12.42 | kencausey | s/file/files/ |
| 20:12.49 | pb_ | Dunno. I think either would be fine. |
| 20:12.52 | cmarqu | Would be cool if ipkgfind supported "This package is being replaced by <foo>". |
| 20:13.00 | kencausey | If we are going to do it, it seems like it makes sense to do it one time at file processing point. |
| 20:13.24 | pb_ | Actually, I suppose it'd be desirable for the package information page to show the unadulterated Section: header from the real package. That'd militate against doing it at database build time. |
| 20:13.27 | kencausey | cmarqu: Doesn't sound hard if specified in the control file |
| 20:13.36 | pb_ | cmarqu: Yes, good thinking. |
| 20:14.04 | cmarqu | And "File bug against this package" :) |
| 20:14.08 | kencausey | pb_: Yes that's true, but the section table is used seperately from the section field in the packages table. So the first could be modified and not the second, I think. |
| 20:14.23 | cmarqu | Since I just noted that pscalc2 should replace pscalc. |
| 20:15.46 | pb_ | kencausey: Ah, okay. |
| 20:16.18 | kencausey | actually, I don't think that will work after all. |
| 20:16.25 | pb_ | cmarqu: heh. you could even provide a hyperlink to the bugzilla submit form. |
| 20:16.29 | kencausey | On searches they are compared. |
| 20:16.38 | kencausey | pb_: Exactly, no problem. |
| 20:17.02 | kencausey | I really think ipkgfind should become the hub for looking at thiings from a package centric view. |
| 20:17.03 | pb_ | In fact, it'd also be nice to have a link for "search for bugs in this package". The bugzilla query page is quite scary for new users. |
| 20:17.15 | cmarqu | Yes, right. |
| 20:18.42 | cmarqu | The bug reporting URL should be settable per feed though. |
| 20:19.13 | kencausey | It should be a per package field in the control file |
| 20:19.25 | kencausey | If not specified, then it could default to bugzilla |
| 20:19.33 | MonMotha | pb_: actually, the ultrimate would be to tie the package listing to bugzilla directly |
| 20:19.41 | cmarqu | Hmm, not sure about that. People will not care. |
| 20:19.48 | MonMotha | that way, the instant a package is uploaded to the feed, bugzilla adds the appropriate info for it |
| 20:20.01 | cmarqu | Ha, yes. |
| 20:20.24 | cmarqu | With correct version numbering - this is always behind. |
| 20:22.01 | cmarqu | I'd argue that everything in an official familiar feed should use the hh.org bugzilla. Same as in Debian - the maintainer will forward to upstream as necessary. |
| 20:23.18 | cmarqu | Package upload time would also be interesting info. I always look into the feed directory to find that out. |
| 20:33.02 | pb_ | cmarqu: Yes. There's already a script to refresh the bugzilla package information from Packages; it just doesn't get run very often. |
| 20:33.09 | pb_ | Maybe we could try to do that once per day or something. |
| 20:33.34 | pb_ | cmarqu: the other piece of interesting information (at least for me) would be the person who actually uploaded each version of the package. |
| 20:33.53 | cmarqu | Hmm. bugzilla doesn't know about pscalc2, how can that be? |
| 20:34.03 | cmarqu | pb_: Ah, yes, that is also interesting. |
| 20:34.29 | pb_ | cmarqu: bugzilla's database probably hasn't been updated since pscalc2 was uploaded. |
| 20:38.53 | MonMotha | pb_: do you have the access to add people to the upload keyring? |
| 20:42.38 | pb_ | MonMotha: yes, but I'd prefer to leave that up to Jamey if possible. |
| 20:42.58 | MonMotha | pb_: is jamey around, haven't seen him today |
| 20:43.44 | MonMotha | I send it to france, but he seems to be very busy with other things :) |
| 20:45.08 | pb_ | MonMotha: I think he was on earlier. He often reads his email even when he's away from IRC, anyway. |
| 20:45.18 | MonMotha | k |
| 20:45.20 | MonMotha | I'll email him |
| 23:36.30 | *** join/#hhwiki dataworm (~dataworm@216.126.80.153) |
| 23:37.06 | *** part/#hhwiki dataworm (~dataworm@216.126.80.153) |