[01:06] <reggaemanu> yahoo \/
[01:08] <crevette> google \/
[01:35] <DarkSun88> Night
[01:58] <sacater> yays
[01:58] <sacater> my laptop went to tribe 3 without problems
[02:06] <TheMuso> Hey folks.
[02:30] <xtknight> TheMuso, hey
[02:30] <xtknight> one question if you don't mind
[02:30] <TheMuso> xtknight: Sure.
[02:32] <xtknight> TheMuso, so i'm modifying Adept to fix a translation.  the file i'm modifying is ./adept/installer/something.Desktop.  the folder ./debian/patches exists, indicating that it uses the patching system.  however, there is also ./adept/installer/debian, but with no patches subdirectory.  if i'm modifying something under ./adept/installer/debian, what should i do?
[02:32] <xtknight> scratch the last part.  that should read ./adept/debian
[02:33] <xtknight> there is not even a "debian" under "./adept/installer"
[02:34] <TheMuso> xtknight: Any modifications under the debian dir are done directly. The You never use patches to modify what is in the deian dir. Patches are only for the upstream source.
[02:34] <xtknight> TheMuso, however, what i'm modifying is not under a debian dir
[02:34] <TheMuso> xtknight: So you modify the .desktop file in the debian dir, and make a note of what you have done in the changelog.
[02:34] <TheMuso> Oh in that case, if the package already uses a patch system, you then create another patch to patch the desktop file.
[02:35] <TheMuso> sorry, I misread.
[02:35] <xtknight> adept-2.1.2ubuntu26.1/adept/installer/adept_installer.desktop 
[02:35] <xtknight> ya im just not sure if the ./installer/ dir uses a patch system also or not
[02:35] <TheMuso> Right so if you want to modify it, and there is debian/patches, then you make a patch.
[02:35] <xtknight> not too familiar with it
[02:35] <TheMuso> What file extension do the patches in debian/patches have?
[02:36] <xtknight> ok, if adept-2.1.2ubuntu26.1/debian/patches exists, then i must use that to modify adept-2.1.2ubuntu26.1/adept/installer/adept_installer.desktop?
[02:36] <TheMuso> Yes. You need to create a new patch.
[02:36] <xtknight> i ask because there is a "debian" also under "adept" with no "patches", but i guess that doesn't matter
[02:36] <xtknight> under that subdir adept
[02:36] <xtknight> right before installer
[02:36] <TheMuso> No. The debian dir in the top source directory is what is used.
[02:37] <xtknight> the debian/patches contains *.diff files
[02:37] <TheMuso> Right
[02:37] <xtknight> so looks like im all set.  col
[02:37] <xtknight> cool*
[02:37] <TheMuso> What build-depends does the package have? We need to know what patch system it uses.
[02:37] <xtknight> simplepatch sys i think
[02:37] <xtknight> one sec
[02:38] <xtknight> Build-Depends: cdbs, debhelper (>> 4.1), dh-buildinfo, libapt-front-dev (>= 0.3.9ubuntu1), libapt-front-dev (<< 0.4), libtool, kdelibs4-dev (>= 3.5.0)
[02:38] <TheMuso> Ok. Is there any mention of simple-patchsys in debian/rules?
[02:38] <xtknight> and in rules : include /usr/share/cdbs/1/rules/simple-patchsys.mk
[02:39] <TheMuso> Ok. You can then use the cdbs-edit-patch command to help you make your patch.
[02:39] <TheMuso> man cdbs-edit-patch for more info.
[02:40] <xtknight> ah, cool
[02:40] <xtknight> wow this is so much better than quilt
[02:40] <xtknight> ;)
[02:40] <xtknight> just seems more straight forward
[02:40] <TheMuso> heh
[02:41] <TheMuso> If I ever have to apply a patch system to a package that doesn't use cdbs, I always use dpatch. :)
[02:48] <xtknight> TheMuso, ok now the correct way to submit the patch is to do the usual debdiff?
[02:49] <xtknight> or..diff between the original adept dir and the one with my CDBS patch inside
[02:50] <TheMuso> The debdiff is between the two source packages. So "debdiff orig.dsc new.dsc"
[02:51] <TheMuso> for example
[02:51] <xtknight> diff'ing between the directories wouldn't be proper?
[02:55] <TheMuso> No.
[02:55] <TheMuso> You must use the dsc files with debdiff.
[03:03] <xtknight> TheMuso,  ok, if there is an XSBC-Original-Maintainer as the original deb maintainer, and a Maintainer as someone@ubuntu.com (not the generic MOTU address), then should i just leave it alone?
[03:04] <xtknight> there's also an Uploaders field
[03:04] <TheMuso> xtknight: Just leave it.
[03:05] <TheMuso> I think adept is in main anyway.
[03:06] <xtknight> ah, yup
[03:06] <TheMuso> c
[03:07] <TheMuso> arrrgh
[03:07] <xtknight> now if i'm modifying something in main, does that also have to wait for Gutsy?  i see stuff saying feisty-proposed in the changelog, should that be what my change is?  my change would affect all versions
[03:07] <xtknight> just a translation edit
[03:07] <TheMuso>  I'd get the gutsy one in first, and then worry about feisty
[03:08] <xtknight> about Bug 60258 (which was the one we were talking about the other day), i just have to wait for Sebastian Bacher to take a look at it?  we said there was something we needed to do about both feisty and gutsy and we'd deal with it later, just wondering what that would be
[03:08] <ubotu> Launchpad bug 60258 in gnome-art "Ruby crashes while using gnome-art-manager" [Medium,Confirmed]  https://launchpad.net/bugs/60258
[03:09] <TheMuso> Well if he is going to look at it, work it out with him.
[03:09] <TheMuso> Basically you need to determine whether its worth a Stable release update, SRU.
[03:09] <TheMuso> There is docs in the wiki about it.
[03:11] <xtknight> it looks like it has been Assigned to him.  so i shouldn't need to bother him right?  (i'd prefer not to to be polite)
[03:11] <TheMuso> I'd ask him about it to be sure.
[03:11] <xtknight> not to, to be polite*
[04:01] <xtknight> bug 95852
[04:01] <ubotu> Launchpad bug 95852 in adept "Translations Danish K-Menu" [Undecided,In progress]  https://launchpad.net/bugs/95852
[04:02] <xtknight> i should subscribe (or assign?) ubuntu-main-sponsors to the bug if there is a proposed patch?
[04:02] <xtknight> also, what should the status of the bug be at that point?
[04:02] <xtknight> (adept is in main)
[04:08] <xtknight> nevermind that.  i should have read the wiki :)  the answer is Subscribe ubuntu-main-sponsors, status: Confirmed, assigned to nobody.
[06:36] <RAOF> Happy birthday, BirthdayHobbsee?
[06:36] <RAOF> :)
[06:36] <BirthdayHobbsee> RAOF: :) thanks
[06:47] <minghua> Happy birthday, Hobbsee!
[06:47] <BirthdayHobbsee> thanks minghua :)
[06:48] <white> BirthdayHobbsee: happy bday
[06:50] <BirthdayHobbsee> white: :)
[06:50] <elkbuntu> happy birthday tooooo youuuuu... happy birthday toooo yoooooooou... happy biiiiirrrrrthdaaaaay ddeeeeeeeaaaar hobbseeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee... happy birthday tooooo yoooouuuu!
[06:50] <BirthdayHobbsee> :D :D :D 
[06:53] <BirthdayHobbsee> hehe
[07:02] <DarkMageZ> BirthdayHobbsee, check your myspace :P
[07:02] <BirthdayHobbsee> woo!  a blinding message!
[07:02] <BirthdayHobbsee> hahahhahahha :D
[07:06] <DarkMageZ> :P
[07:10] <tuxmaniac> BirthdayHobbsee, My best wishes for a long lasting Ubuntu addiction
[07:10] <BirthdayHobbsee> tuxmaniac: :D
[07:10] <BirthdayHobbsee> haha
[07:13] <ajmitch> happy birthday, BirthdayHobbsee 
[07:14] <ajmitch> ;)
[07:14] <BirthdayHobbsee> thanks ajmitch :)
[07:14] <tuxmaniac> :)
[07:14] <tuxmaniac> ajmitch, Hi. and Long time no see :-)
[09:10] <TheMuso> ~/c
[09:10] <TheMuso> ugh
[09:13] <TheMuso> StevenK: heh
[09:23] <elkbuntu> StevenK, what's this? an evil plan? and nobody invited me?!
[09:25] <StevenK> elkbuntu: Feel free to drive up and help. :-)
[09:26] <elkbuntu> ok. im just as lazy as i am evil
[09:29] <DarkMageZ> i'm more evil. what's the plan!
[09:31] <StevenK> Demoting yada to universe
[09:32] <TheMuso> haha
[09:32] <StevenK> Be glad
[09:32] <TheMuso> StevenK: So it seems.
[09:34] <minghua> Why was yada in main in the first place...
[09:35] <BirthdayHobbsee> evilness
[09:35] <BirthdayHobbsee> because someone was sadistic
[09:38] <TheMuso> i CAN BE EVIL IF i NEED TO BE.
 why /was/ yada in main?
[09:40] <StevenK> It's in main since 3 things in main Build-Depend on it
[09:40] <vorlon> which ones?
[09:41] <StevenK> % 
[09:41] <StevenK> grep-dctrl -sPackage -FBuild-Depends 'yada' <(wget -qO - http://archive.ubuntu.com/ubuntu/dists/gutsy/main/source/Sources.gz | gunzip)
[09:41] <StevenK> Package: libapache2-mod-auth-pam
[09:41] <StevenK> Package: libapache2-mod-auth-plain
[09:41] <StevenK> Package: libnss-db
[09:41] <vorlon> ah, heh
[09:41] <vorlon> all dexter's, of course
[09:41] <StevenK> Ahhh
[09:42] <StevenK> Mr. yada him bloody self
[09:42] <vorlon> well when you fix their build dependencies in Ubuntu, don't forget to helpfully send your patches to the BTS ;)
[09:42] <StevenK> I can NMU them. :-P
[09:42] <StevenK> I have a 24K diff for libapache2-mod-auth-plain
[09:42] <vorlon> you can't /properly/ NMU them
[09:43] <StevenK> Why not?
[09:43] <vorlon> because that's not a proper change to make in an NMU
[09:43] <StevenK> Surely the RMs can make an exception for ridding the archive of the pox that is yada?
[09:43] <vorlon> (or maybe you misspelled "hijack"? :)
[09:43] <StevenK> Oh, blah, I'm not hijacking. :-P
[09:44] <vorlon> well, getting rid of yada is on the RMs wishlist. :)
[09:44] <vorlon> but I think they stopped short of putting it as a lenny release goal without the consent of the maintainer. ;)
[09:45] <StevenK> Isn't dexter all but MIA anyway?
[09:45] <vorlon> dunno
[09:45] <StevenK> Anyway, I shall do as you said. I'll upload the bunch of 3, get yada demoted, and send 3 patches helpfully to the BTS.
[09:46] <StevenK> Maybe starting the bug report with "Since yada is such a useless sack of sh...." isn't a good idea. :-)
[09:59] <jeromeg> hello all
[10:00] <jeromeg> I need some help about bug 114534
[10:00] <jeromeg> it's fixed in gutsy (normally)
[10:00] <ubotu> Launchpad bug 114534 in gimmie "Suggested patches for gimmie" [Undecided,New]  https://launchpad.net/bugs/114534
[10:01] <jeromeg> but it's still sending a huge amount of duplicates to the gnome BTS
[10:01] <jeromeg> could it be possible to apply the patches to the feisty package and have an updated package ?
[10:02] <RAOF> jeromeg: Yes; that'd be an SRU.
[10:02] <BirthdayHobbsee> jeromeg: not to feisty.  see !timebasedreleases
[10:02] <BirthdayHobbsee> would it be a SRU candidate?
[10:02] <minghua> BirthdayHobbsee: patch looks small and sane enough for a SRU.
[10:02] <jeromeg> SRU ?
[10:03] <BirthdayHobbsee> ah, fair enough
[10:03] <RAOF> Stable Release Update
[10:03] <minghua> jeromeg: stable release update
[10:03] <jeromeg> thx
[10:03] <jeromeg> I think the gnome folks would be really pleased of that
[10:03] <jeromeg> I can do something for that ?
[10:04] <minghua> jeromeg: Do you have a patch with proper spacing to attach to that bug?
[10:04] <jeromeg> minghua: appart the one given in the report no
[10:04] <minghua> LP eating space indents is really bad for python patches.
[10:05] <jeromeg> minghua : I can maybe mail the reporter and ask him to attach the patches ?
[10:05] <minghua> jeromeg: the one in the report is copied and pasted, an attachment would be much better.
[10:05] <jeromeg> minghua: ok I will ask for that
[10:06] <jeromeg> and after that I can do something ?
[10:06] <jeromeg> or it's a motu task ?
[10:07] <minghua> jeromeg: The process is described in https://wiki.ubuntu.com/MOTU/SRU
[10:07] <jeromeg> minghua: thx
[10:08] <minghua> After reading it, I am not sure this qualify an SRU, though.
[10:10] <jeromeg> minghua: well it has a high-impact on the BTS :)
[10:10] <minghua> jeromeg: I don't approve SRUs, no point persuading me. :-P
[10:10] <jeromeg> minghua: ah :)
[11:41] <DarkSun88> Hi all
[02:43] <bmm> Hi everybody. I'm a newbie as for drupal development and I was wondering the following: I want to add a rating like system to some of the book pages but not all. How should I go about doing this: a new content type, a block or filter??
[02:44] <zul> bmm: totally offtopic
[02:46] <man-di> bmm: you should probably ask the drupal people
[02:52] <bmm> Oh, my bad: wrong channel :-D
[02:52] <bmm> sorry!
[03:00] <LucidFox> If I'm updating a package that has a Maintainer field in debian/control, what should I set XSBC-O-M to?
[03:00] <LucidFox> myself or that maintainer?
[03:02] <StevenK> That Maintainer
[03:04] <LucidFox> ok
[03:40] <TheMuso> c
[03:40] <TheMuso> ugh
[04:17] <geser> zul_: why didn't you follow standard procedures to sync a package from Debian and did a direct upload? (btw: pigment got already synced and is currently in NEW)
[04:36] <sacater> imbrandon: 
[04:36] <sacater> what was that link you gave gazzak or something
[04:36] <sacater> the simpsons thing
[04:37] <jsgotangco> create your own simpsons character? heh
[04:39] <_wattazoum_> Hello there
[04:41] <elkbuntu> sacater, you're thinking of the simpsonizeme.com link he blogged about?
[04:41] <elkbuntu> it kills my firefox every time :(
[05:32] <ScottK> geser: Why did you change the tags on Bug 127548
[05:32] <ubotu> Launchpad bug 127548 in libdatetime-locale-perl "New version 0.34 of DateTime::Locale is available." [Wishlist,New]  https://launchpad.net/bugs/127548
[05:35] <geser> isn't needs-packaging only for new software?
[05:36] <geser> and shouldn't new versions get "upgrade" as tag?
[05:37] <ScottK> Since Debian doesn't have this version, someone would need to package it, right?
[05:37] <ScottK> Is the upgrade tag documented anywhere?
[05:38] <geser> https://wiki.ubuntu.com/Bugs/Tags
[05:39] <ScottK> geser: OK.  Fair enough.  Upgrade is the right tag.  Thanks.
[05:41] <xtknight> the proper procedure for a Main bug is to subscribe to ubuntu-main-sponsors and do the rest the same, right?
[05:41] <xtknight> the rest being set to Confirm and Assign to nobody after a patch has been posted (but not reviewed)
[05:41] <geser> yes
[05:42] <xtknight> k
[05:42] <xtknight> maybe this should be in the docs somewhere (even though this is MOTU)?
[05:44] <jwendell> in order to make a new version of a package, the things to do are the same as if it was a new package, right (REVU stuff, etc)?
[05:45] <ScottK> jwendell: Yes, but new versions only need one MOTU advocating, not two.
[05:46] <jwendell> ScottK, thanks
[05:46] <ScottK> It's helpful to mention in a comment on REVU that it's an update to an existing package.
[05:48] <jwendell> right
[06:16] <LucidFox> When packaging a Java project that depends on external JAR libraries, can these libraries be distributed in JAR form in the upstream tarball?
[06:16] <LucidFox> What do I need to ask upstream? To remove the JARs, or to replace them with source, or nothing?
[06:17] <ScottK> man-di: LucidFox has a question up your alley^^^
[06:25] <LucidFox> Apparently, the amount of jackassery of upstream maintainers is a gaussian function of the project's obscurity.
[06:26] <LucidFox> That is, very obscure and very mainstream projects are the most likely to make the suggested changes, while those in the middle will have a knee-jerk reaction.
[06:39] <man-di> LucidFox: build the 3rd party jars from source as extra packages
[06:39] <man-di> LucidFox: other packages might need them too
[06:39] <man-di> and build your package with the packaged versions of these jars
[06:40] <man-di> LucidFox: I know this is a lot of work but the only solution that helps all on the long run
[06:40] <LucidFox> man-di> thanks
[06:40] <man-di> LucidFox: packaging java software is not easy as most upstreams miss the glue on how to release software
[06:40] <LucidFox> can these jars remain in the tarball, or should I get upstream to remove them?
[06:40] <man-di> LucidFox: we normally remove them
[06:40] <LucidFox> ok
[06:41] <man-di> and repackage orig.tar.gz
[06:41] <man-di> and write this into debian/README.Debian-source
[06:41] <LucidFox> well, it's better if upstream removes them, isn't it?
[06:42] <man-di> LucidFox: sure
[06:42] <man-di> LucidFox: but that defeats their goal for the need to download one ZIP and all works
[06:43] <man-di> LucidFox: Java releases normally contain all dependencies
[06:46] <LucidFox> where do jar libraries go? /usr/lib?
[06:48] <man-di> LucidFox: /usr/share/java
[06:49] <man-di> LucidFox: please read the Debian Java Policy
[06:49] <man-di> LucidFox: its outdated and some things are not correct anymore, but its mostly correct
[06:54] <ScottK> man-di: Mostly correct documentation is the most dangerous kind.
[06:55] <man-di> ScottK: I know...
[06:55] <man-di> we are currently figuring out what to do
[06:55] <man-di> with other distros
[06:55] <man-di> to get a Linux Java Platform that behaves the same on all major Linux distros
[07:00] <LucidFox> Will I need to file a separate needs-packaging LP bug for every dependency?
[07:05] <man-di> LucidFox: yes, as all are separate packages
[07:08] <ScottK> Does the Ubuntu MOTU process documenation require Needs Packaging bugs now?  They used to be optional.
[07:14] <LucidFox> man-di> Hmm. One of these libraries hasn't had new releases since 2000.
[07:20] <AndyP> ScottK: i didn't think so. i personally picked up a couple of needs packaging bugs just to broaden my education
[07:21] <man-di> LucidFox: if you need it, package it
[07:21] <man-di> LucidFox: either package it or dont package the software you want to package
[07:24] <LucidFox> all right
[07:33] <jwendell> ajmitch, around?
[07:34] <jwendell> raphink, around?
[07:35] <jwendell> i uploaded a new package (with dput), but it didn't appear on revu page
[07:43] <effie_jayx> !best
[07:43] <ubotu> Usually, there is no single "best" application to perform a given task. It's up to you to choose among a number of different applications, depending on your preferences, the features you require, and other factors.
[08:28] <blueyed> If I make a change to debian/init in a package, this is not represented in a debdiff, is it? Do I miss an option to debuild?
[08:29] <blueyed> I mean debian/init.d
[08:32] <ScottK> It should be.
[08:35] <blueyed> Oh.. I think I've messed things up.. using "debuild -S" before "dch -i" already.
[08:35] <ScottK> That'll do it.
[08:39] <blueyed> Does Debian use a tmpfs for /var/run?
[08:55] <ScottK> blueyed: Not normally.
[09:46] <Nightrose> A
[09:56] <nuut> someone may re-sync the REVU uploaders keyring?
[09:57] <RainCT> can somebody tell me on what wiki page backports are explained (basically how to request them)?
[09:58] <nuut> have someone from REVU admins?
[09:58] <RainCT> ah, nevermind. didn't see there's a search box lol
[10:20] <RainCT> can anyone please check if bug #127612 is ok?
[10:20] <ubotu> Launchpad bug 127612 in feisty-backports "Please backport translate-toolkit" [Undecided,New]  https://launchpad.net/bugs/127612
[10:53] <ScottK> RainCT: Looking
[10:54] <ScottK> RainCT: All it needs is someone to say they've installed the backported package and it works.
[11:10] <Kmos> RainCT: http://sharkattack.media.mit.edu:8080/feisty-debs/translate-toolkit/
[11:13] <RainCT> Kmos: Should I test this, or someone else?
[11:13] <Kmos> yeah
[11:13] <Kmos> and add comment
[11:13] <Kmos> see if it works fine in feisty
[11:28] <blueWorking> Is it a bad thing to redistribute .pc files in a non-dev package?
[11:28] <RainCT> Kmos: works fine, writting a comment now :)
[11:29] <Kmos> :)
[11:31] <RainCT> (posted)
[11:35] <geser> blueWorking: do you have a separate -dev package?
[11:35] <blueWorking> Yes
[11:36] <geser> then it's better to ship them in the -dev package
[11:36] <blueWorking> But the other applications that use this particular package needs to locate this package
[11:36] <nuut> why all my uploaded packages to REVU goto 'rejected' directory
[11:36] <blueWorking> And pkg-config seems to be a nice clean way of doing this
[11:36] <geser> blueWorking: what kind of package is this?
[11:36] <blueWorking> geser, Think webserver
[11:36] <blueWorking> And it needs to know the webroot
[11:36] <blueWorking> It's called Simias
[11:37] <geser> and it uses pkgconfig files for that?
[11:37] <blueWorking> Well, it has those
[11:37] <blueWorking> I need a way to locate the webroot in packages that uses Simias
[11:37] <blueWorking> Which they include a pc-file to
[11:38] <geser> does it have a config file?
[11:38] <geser> so when you want to have the webroot somewhere else you modify the .pc file?
[11:38] <blueWorking> Well, sort of.
[11:39] <blueWorking> The PC file now doesn't do much as long as no packages are dependant.
[11:39] <man-di> blueWorking: I would call this "Very broken software"
[11:40] <blueWorking> man-di, Oh, you have no idea. It wanted to install the webroot in /usr/libexec first
[11:40] <man-di> blueWorking: you better teach upstream before you package it
[11:40] <blueWorking> man-di, I talk with upstream on a daily basis
[11:41] <man-di> blueWorking: otherwise it looks like rewriting the software from scratch is more simple ;-)
[11:41] <blueWorking> I've told them and they sortof listen
[11:41] <blueWorking> man-di, Well, not really. It's pretty fine so far, but this is the full information:
[11:41] <blueWorking> I have this startscript for iFolder, an application using Simias.
[11:42] <blueWorking> It's a mono-application, and therefor uses MONO_PATH to locate it's assembiles. The simias assemblies are in /usr/lib/cli/simias-X.Y
[11:42] <blueWorking> The only clean way I can get those assemblies is to ask pkg-config atm
[11:43] <nuut> siretart: Please re-sync the REVU uploaders keyring
[11:45] <man-di> blueWorking: I dont know anything about mono, but I would consider usage of pkg-config for this as severely broken
[11:48] <blueWorking> man-di, I'll look into GAC a bit more, I'm pretty sure it can solve this. Thanks anyway
[11:48] <ScottK> RainCT: Acked to ubuntu-archive.  Now we wait for them to upload the backport.
[11:48] <RainCT> ScottK, Kmos: ok, thanks
[11:49] <blueWorking> man-di, FYI:
[11:49] <blueWorking> All GAC library packages should have a pkg-config .pc file located in /usr/lib/pkgconfig. The filename must be named: package-X.Y.pc including the versioning. The version must reflect the same X.Y version as the package name. There should also be a symlink without the version to the latest version, as follows: from package.pc to package-X.Y.pc
[11:49] <blueWorking> So I need to package the pc file apparentlf
[11:51] <man-di> blueWorking: what is GAC?
[11:51] <blueWorking> Global Assembly Cache
[11:53] <ajmitch> blueWorking: you've looked at the licensing of simias?
[11:54] <blueWorking> ajmitch, GPL
[11:54] <ajmitch> last I recall it's wasn't completely
[11:54] <blueWorking> It is nowadays
[11:55] <blueWorking> I even confirmed by email
[11:55] <ajmitch>  *  THIS WORK IS AN UNPUBLISHED WORK AND CONTAINS CONFIDENTIAL,
[11:55] <ajmitch>  *  PROPRIETARY AND TRADE SECRET INFORMATION OF NOVELL, INC. ACCESS TO
[11:55] <ajmitch>  *  THIS WORK IS RESTRICTED TO (I) NOVELL, INC. EMPLOYEES 
[11:55] <ajmitch> etc...
[11:55] <blueWorking> Version?
[11:55] <ajmitch> so unless you're looking at a newer version
[11:56] <ajmitch> simias-1.2.5347.1
[11:56] <blueWorking> I'm using 1.5
[11:56] <ajmitch> perhaps they have finally cleared things up, but please check it throughout the source
[11:59] <blueWorking> ajmitch, I did that at 1.4, no problems. Haven't done it in 1.5 I have to admit