[00:00] <sebner> Kopfgeldjaeger: maybe not that much, less. And cool, I know you from uu.de
[00:00] <Kopfgeldjaeger> ;)
[00:01] <DnaX> bye
[00:01]  * DnaX go to bed
[00:01] <sebner> DnaX: hf
[00:01] <Kopfgeldjaeger> bye
[00:16] <sebner> gn8 folks :)
[01:01] <Kopfgeldjaeger> good neight
[02:30] <bddebian> persia: You around by any chance?
[02:46] <orly_owl> So MOTU is the people who maintain ubuntu universe and multiverse?
[02:49] <Flannel> orly_owl: Yes
[03:06] <persia> bddebian: WIth a bit of a delay: what's up?
[03:23] <bddebian> persia: How much do you know about gettext/intltool?
[03:25] <persia> bddebian: As little as possible.  What seems to be the issue?
[03:26] <bddebian> persia: I'm trying to help upstream fix his build system to regenerate the .pot files and such and I've done what a lot of the docs say to do but it just doesn't seem like it's doing anything
[03:36] <persia> bddebian: Hrm.  That one is beyond me.  I don't seem to have the answer in any of my standard reference spots either.  Does the package use autotools?  If so, acl seems to do it.
[03:37] <bddebian> Yeah, it's autoconf.  acl the package?
[03:37] <persia> acl the package.  Look in po/Makefile for the sorts of hints that are being passed.
[03:37] <bddebian> OK, thanks man
[03:38] <persia> bddebian: No problem.  Note that $(TOPDIR)/include/builddefs is a generated file, so you may need to run some of a build in order to have the right information available.
[03:40] <bddebian> Well I added gettextize and intltoolize
[03:40] <bddebian> to autoge.sh
[03:40] <bddebian> +n jeez, I can't type
[03:43] <persia> Does the build now call xgettext?
[03:44] <bddebian> I don't think it calls shit.  He was calling intl-extract by hand to regenerage the files
[03:47] <persia> Have you tried a run with the modified autogen.sh?
[03:48] <bddebian> Oh yeah, I've hacked the crap out of it and the autotools files and it builds fine and runs fine, I just don't know if I'm actually getting the translations :-(
[03:49] <persia> heh.  Now I understand.
[03:50] <stefanlsd> the KDE stuff is a bit silly that ubuntu kde are following experimental by moving to KDE4 and sid is still got kde3.5 stuff
[03:50] <persia> Are the .po and .pot files updated during the build (based on timestamp comparison)?
[03:51] <persia> stefanlsd: Different release cycles: KDE4 wasn't ready early enough for Lenny, but is ready early enough for Intrepid.
[03:51] <bddebian> persia: I'm checking that now
[03:51] <stefanlsd> persia: yeah. just seems painful as we merge from sid against things that no longer exist in intrepid
[03:53] <persia> stefanlsd: I know, but that's part of what happens when a Debian release is pending.  When Debian releases in late September, we'll see *lots* of package bumps in sid, but won't want to sync/merge because Intrepid will be mostly frozen.
[03:53] <stefanlsd> persia: heh. fun :)
[04:02] <bddebian> Hmm, well it seems to generate a new .pot file
[04:08] <stefanlsd> persia: I was looking at merging showimg which is a kde package which seems dependant on libkonq4-dev which no longer exists in Intrepid (spoke with Riddell and its by design).  Any suggestions or options? It doesnt appear to compile under libkonq5-dev as once i move to kdelibs5-dev things break. I have emailed upstream author re KDE4 support.  I've tried to build it without libkonq and its also failing.
[04:18] <persia> stefanlsd: That happens sometimes.  You'll need to check how the API changed, and prepare a port.
[04:19] <stefanlsd> persia: port of what exactly?  the application in question?
[04:19] <persia> Indeed.  showimg.
[04:20] <stefanlsd> Wouldnt that be a function of the upstream app developer?  (No problem assisting, but he may not even want to continue the app...?)
[04:21] <persia> Well, maybe.  This is part of the collaborative interface.  The only reason the app needs porting is because Ubuntu ships a different library, so from that perspective, it's entirely our job.  On the other hand, the upstream for the library is moving on, and so the upstream for the client will need to move at some point, or become obsolescent, so from that perspective, it's upstream work.
[04:22] <persia> In cases like this, I think that the work ought be done by whoever can get it done first.
[04:24] <stefanlsd> yeah. ok. Let me see what upstream says. the package in question may of been replaced similair functionality in other software or kde core functionality and if upstream has abandoned the project, no use in maintaining it if I have no other interest except for trying the merge.
[04:42] <bddebian> Shite, it's not creating the .mo files though :-(
[05:13] <persia> bddebian: That's an easier problem though :)
[05:14] <bddebian> It is?
[05:14] <persia> msgfmt -o target.mo source.po
[05:16] <persia> %.mo : %.po
 msgfmt -t -o $@ $<
[05:17] <persia> Err, except without the -t :)
[05:17] <bddebian> weird, that is all in po/Makefile
[05:17] <persia> OK.  Does anything depend upon the .mo files so that they get built?
[05:18] <bddebian> Hmm, no clue
[05:18] <persia> pastebing po/Makefile
[05:20] <pyc> howdy, is it OK to ask PPA failed build related questions here?
[05:21] <persia> pyc: We much prefer questions about builds that fail in the primary repositories, but it depends on the nature of the problem: stuff that's too PPA specific usually gets ignored.
[05:21] <bddebian> persia: http://paste.debian.net/14957/
[05:22] <pyc> persia,  i see, so would be much better to ask SOYUZ?
[05:22]  * persia wants a browser that cannot crash.
[05:23] <persia> pyc: It depends on the nature of the problem.  Things that are too packaging-specific tend to get ignored there.  Better to just ask, and see what people say.
[05:23] <pyc> ok
[05:23] <pyc> was wondering what's wrong with this
[05:24] <pyc> http://launchpadlibrarian.net/16877126/buildlog_ubuntu-hardy-lpia.revel_1.1.0-1_FAILEDTOBUILD.txt.gz
[05:25] <pyc> so far i can only comprehend that the build failed because ..
[05:25] <persia> pyc: It's an XviD issue.  Modify the build to echo config.log, and examine it.  Alternately, try building in a local lpia chroot.
[05:25] <pyc> ok
[05:30] <persia> bddebian: From the stamp-po rule it looks like you might want to fiddle with LINGUAS or POFILES, but I'm not sure (and I've run out of time for this session).
[05:31] <bddebian> persia: NP, thanks man
[05:31] <persia> To me it looks like it's configured to generate the files on request, rather than at build time.
[05:31] <bddebian> Yeah, that was the issue
[05:31] <persia> Fixing it is probably just a matter of adding some dependencies to the rules, so that when the .pot files are updated, it regenerates $(DOMAIN).pot, etc.
[05:32] <bddebian> Uhm, yeah sure :)
[05:32] <persia> (this is an expensive operation, but may be what you seek)
[05:32] <persia> Also, right now all translations are copyright Yoyodyne, Inc. which may not be correct :)
[05:33] <persia> "Uhm, yeah sure :)"?  Read the comment about $(DOMAIN).pot which describes it in some detail.
[05:33] <bddebian> OK, will do, thanks
[05:33] <persia> From line 410 or so.
[05:34] <persia> Might just be resetting the definition of POFILES to not be empty.
[05:34] <persia> Anyway, I'm off.
[05:40] <bddebian> Laterz, thanks again
[05:45] <superm1> hum what's the point of this motu membership renewal email if I'm just able to do it myself?  wouldn't it make more sense to default to yes, and have me opt out when I don't want in anymore?
[05:46] <superm1> or to make me appear across some council that affirms my worthiness at least
[05:46] <ScottK-laptop> superm1: No, just makes you need to at least care enough to answer a mail if you want to stay in.
[05:46] <ScottK-laptop> Not everyone does.
[05:47] <ScottK-laptop> superm1: IIRC you're maintaining DKMS now, right?
[05:47] <superm1> ScottK-laptop, yup
[05:47] <superm1> got some qualms?
[05:47] <superm1> :)
[05:47] <ScottK-laptop> Nope.  Need some help.
[05:47] <superm1> sure what's up?
[05:48] <ScottK-laptop> Klamav depends on the Dazuko modules for auto scanning.
[05:48] <ScottK-laptop> AFAICT it's never worked in Debian/Ubuntu.
[05:48] <ScottK-laptop> I'd like to make it work.
[05:48] <superm1> dauko kernel modules i'm assuming?
[05:48] <ScottK-laptop> Yes
[05:48] <ScottK-laptop> http://dazuko.dnsalias.org/wiki/index.php/Main_Page
[05:49] <ScottK-laptop> http://dazuko.dnsalias.org/files/patch-dazuko-linux-2.6.26.diff.gz is the patch.
[05:49] <superm1> well the obvious first question will be is it possible to get these kernel modules upstream?
[05:49] <superm1> as in mainline kernel
[05:49] <ScottK-laptop> Not for Intrepid.  That's for sure.
[05:49] <superm1> well at least in the ubuntu/ part of the tree?
[05:50] <ScottK-laptop> Dunno.  I'm just sorting this out now and you suddenly appeared.
[05:50] <superm1> IIRC server folk don't like compiling kernel modules on their systems
[05:50] <superm1> and i would think that is a big target for this
[05:51] <superm1> ah from what it appears this is nearly ready to drop into a 2.6.26 kernel tree like is present
[05:51] <ScottK-laptop> That's what they claim, but I know zip about kernel modules.
[05:51] <superm1> Kconfig and all
[05:52] <superm1> well lets step into #ubuntu-kernel and I can try to get you started doing that first instead.  it's the better solution if possible
[05:52] <ScottK-laptop> OK.  There.
[05:53] <ScottK-laptop> LWN describes them as a "having relatively hostile attitude towards the suggested ways of moving their code into the treea"relatively hostile attitude towards the suggested ways of moving their code into the tree"
[06:19] <pyc> a very stupid question , what is a local lpia?
[06:19] <pyc> i know what a chroot is
[06:19] <pyc> but local lpia ,  i really have no idea :))
[06:21] <ScottK-laptop> The only LPIA I know is the Intel Low Power Architecture.  It's one of the archs that Ubuntu is built on.
[06:21] <Hobbsee> lpia is an architecture used for -mobile
[06:22] <pyc> how do i set that up? to debug a ppa?
[06:23] <pyc> or is this a FAQ?
[06:24] <Hobbsee> i assume you'd have to build a mobile thing - it might be in the #ubuntu-mobile FAQ
[06:24] <superm1> you can build lpia chroot's though
[06:25] <superm1> just need to point to the proper archive mirror on ports
[06:25] <superm1> ubuntu-dev-tools in intrepid has support in mk-sbuild-lv to make one
[06:25] <pyc> i'll have to wait for intrepid then? ;)
[06:26] <superm1> pyc, well you can grab the ubuntu-dev-tools package from intrepid and run it on hardy
[06:26] <superm1> its mostly a collection of scripts anyhow
[06:26] <pyc> superm1,  i see :)
[06:26] <superm1> but you should be able to build one yourself too if need be just with debootstrap
[06:26] <superm1> just need to tweak the right arguments
[06:27] <superm1> but if you've already got sbuild+LVM setup, the former that i suggested is much more preferable
[06:27] <superm1> far easier
[06:27] <pyc> superm1, do you have any idea why ppa would fail, even if its succeed on mine?
[06:27] <superm1> pyc, depends on the build log on the PPA
[06:27] <superm1> pyc, got a link?
[06:28] <pyc> http://launchpadlibrarian.net/16877126/buildlog_ubuntu-hardy-lpia.revel_1.1.0-1_FAILEDTOBUILD.txt.gz
[06:28] <pyc> persia already pointed out the xvid issue
[06:29] <pyc> but why would it fail anyway, if the configure says xvid >= 1.x.x ?
[06:29] <superm1> so is that xvid library not available on lpia then?
[06:29] <pyc> in ppa?
[06:29] <superm1> well did you add it to the dependencies in debian/control?
[06:29] <superm1> that xvid library
[06:29] <pyc> oops..
[06:29] <superm1> and if you have, did you mistakingly indicate it for amd64, i386 only?
[06:30] <pyc> no, i specify "any"
[06:30] <pyc> that's most likely the problem not specifying xvid in control
[06:30] <pyc> thanks ;)
[06:31] <superm1> yup
[06:31] <superm1> np
[06:32] <nxvl> why i'm still a contributor for revu?
[06:32] <nxvl> do i need to do something special?
[07:17] <RAOF> Anyone feel like revuing a new mono package?
[07:41] <RAOF> Failing that, anyone want to dispense copyright advice? :)
[07:56] <RAOF> Hobbsee: I know you're here, so there's no use hiding.  Do you know of any tools for determining whether a library's ABI/API has changed?
[07:57] <Hobbsee> RAOF: no.
[07:57] <orly_owl> heh
[07:57] <RAOF> Curses!
[07:57] <Hobbsee> :)
[07:58] <RAOF> I suppose I'll diff the headers, then :/
[08:02] <RAOF> Well, that was painless :)
[08:02] <RAOF> Here, shlibs file!  Come to me.
[08:03] <ion_> raof: dpkg-gensymbols(1) might be useful.
[08:04] <RAOF> Cool.
[08:11] <rebel_kid> hey im a new programming, i know the basics of python and study more everyday, im looking to get involved in the devel of ubuntu and/or its applications
[08:21] <RAOF> rebel_kid: You have a common misunderstanding of what we actually do as a part of Ubuntu; we generally don't actually _develop_ anything.
[08:21] <RAOF> rebel_kid: That said, if you want to help, there's plenty to do :)
[08:21] <RAOF> !contribute | rebel_kid
[08:27] <rebel_kid> RAOF: thanks, the devel room topic said to go here, i would love to help in anyway, in development or here
[08:28] <RAOF> rebel_kid: If you actually want to _program_, the way to help would generally be to find an upstream project and start helping there.
[08:28] <rebel_kid> what do u mean upstream project?
[08:29] <RAOF> I mean: none of the software in Ubuntu is actually _written_ by Ubuntu; we simple package up other people's work so that it's easy to use.
[08:30] <rebel_kid> oh i understand that
[08:30] <RAOF> So, if you want to do programming, you probably want to find a piece of software that you'd like improved, and improve it :)
[08:30] <rebel_kid> speaking of which, want to package up one of my programs lol
[08:31] <rebel_kid> jk, it doesnt even have a GUI yet
[08:31] <RAOF> _Now_ we're cooking with #ubuntu-motu :)
[08:31] <rebel_kid> if thats the kind of thing you guys do i would love to learn how
[08:32] <rebel_kid> especially when i decide to distribute my program, i got couldnt find a good inventory program for ubuntu, so im writing it
[08:43] <emgent`> moin
[09:06] <gnomefreak> anyone have a clue why ubuntu-restricted-extras installs atles one .exe
[09:07] <gnomefreak> ok scratch that most of the packages are .exe
[09:10] <gnomefreak> here is a post of what it does http://pastebin.mozilla.org/517785
[09:11] <geser> msttcorefonts
[09:11] <gnomefreak> geser: i thought that was in archive
[09:12] <ion_> The license forbids from even renaming them IIRC, so they aren’t compatible for the archive.
[09:12] <ion_> ...or putting into a package
[09:13] <geser> but the "windows" fonts are only available as .exe from microsoft, so it downloads them and extracts the .ttf files
[09:13] <gnomefreak> its in multiverse
[09:15] <gnomefreak> geser: yeah i saw that
[10:27] <foxbuntu> if anyone would be willing to take a peak at this for a revu for me, great appreciated: http://revu.ubuntuwire.com/details.py?package=mythbuntu-log-grabber
[11:27] <askand> Is there a reason msttcorefonts is not included in kubuntu-restricted-extras or can I go ahead and fix bug 231094 ?
[11:30] <jpds> askand: Since u-r-e has it, yes, please do.
[11:42] <askand> Does this debdiff look ok http://pastebin.com/m57c51bcc
[11:46] <jpds> askand: Could you possible attach it to Launchpad?
[11:47] <jpds> possibly*
[11:49] <geser> askand: the debdiff looks ok, so you can attach it to the bug for sponsorship (don't forget to subscribe the correct sponsor team)
[11:54] <RAOF> Right.  One gnome-main-menu uploaded.  Yay.
[11:56] <askand> jpds: it is attached now, wanted to know it was ok before attaching :P
[11:57] <askand> geser: hm what would be the correct sponsor team for ubuntu-restricted-extras? Its in multiverse
[11:58] <jpds> askand: ubuntu-universe-sponsors
[11:58] <askand> jpds: tanks
[12:53] <Hobbsee> askand: because i've long not seen teh point of installing non-free fonts, as u-r-e seems to be the more for enhancements of the non-free variety.
[12:53] <Hobbsee> askand: i'd prefer to install ttf-liberation or something :)
[13:26] <askand> Hobbsee: I guess it is for people who need to use msfonts, me for example have to use times new roman in the essays at my university
[13:27] <Hobbsee> askand: ah yes, i guess there isn't a TNR font for htat.
[13:28] <StevenK> But the liberation fonts are metrically equivalent.
[13:28] <StevenK> That's the entire point of them
[13:46] <askand> Isnt it better that liberation fonts are installed by default then and ms fonts is still in restricted package? Or is liberation fonts also restricted somehow?
[13:46] <wgrant> Liberation was non-free a while ago, but IIRC that might have changed.
[13:49] <ion_> Seems like Liberation is GPL-2 with an exception.
[15:19] <stefanlsd> Has anyone got a suggestion as to why I am getting a build failure. http://pastebin.ubuntu.com/38217/   (i havent made any mods yet. just apt-get source, debuild -S -sa, and using pbuilder).
[15:22] <gnomefreak> problem with zaptel package? as in there is a problem within that package
[15:23] <stefanlsd> gnomefreak: that version is in intrepid. So i assume of would of built?
[15:23] <stefanlsd> gnomefreak: or if its a sync, do we just use the deb as is from Debian?
[15:24] <gnomefreak> 1.4.11~dfsg-1
[15:24] <stefanlsd> yeah...
[15:24] <gnomefreak> your using the right package
[15:28] <gnomefreak> i thought it was a newline issue but its not, i dont think that warning means anything that would cause FTB
[15:29] <gnomefreak> stefanlsd: does it build in chroot?
[15:29]  * gnomefreak tries not to use pbuilder but its just me
[15:29] <stefanlsd> gnomefreak: only tried my intrepid pbuilder...
[15:30] <gnomefreak> it failed while trying to build zaptel
[15:31] <stefanlsd> yeah
[15:32] <gnomefreak> but the only thing that jumps out is the new line warning
[15:32] <stefanlsd> gnomefreak: ok. thanks.  let me see if i can find out why thats happening
[15:33] <gnomefreak> i would say try to build zaptel
[15:33] <gnomefreak> ok im gone its weekend
[15:47] <geser> stefanlsd: looks like the package FTBFS twice in a row
[15:48] <geser> stefanlsd: pbuilder has a bug that it builts every package twice (pbuilder build --twice will build it once :)
[15:49] <sebner> geser: still thinking about an ACK-script? ^^
[15:49] <geser> sebner: yes, I just need a py-lp-bugs which works with current LP
[15:50] <emgent> evening
[15:50] <sebner> emgent: \o/
[15:50] <emgent> heya sebner :)
[15:50] <sebner> geser: ask \sh ^^
[15:50] <stefanlsd> geser: aah yeah. that worked using --twice
[15:51] <stefanlsd> here i am removing all these duplicate links and fixing all the errors :)
[15:51] <emgent> stefanlsd: o/
[16:03] <ScottK> mok0: I had done a detailed copyright review of gamgi that I thought I submitted to REVU, but either I didn't submit it or it was eaten.
[16:04] <ScottK> mok0: Do grep -ir copyright * on the gamgi source and you'll find a number of additional licenses you duon't currently list.
[16:04] <ScottK> mok0: You will also find one file that is not distributable and will have to be removed.
[16:07] <ScottK-laptop> mok0: It's dat/cell/polymers/polyethylene_sulfide.cif that's not distributable.
[16:09] <ScottK-laptop> OK, looks like the comment didn't get eaten, just I was dealing with a cached copy of the page.
[17:05] <mok0> ScottK-laptop: I didn't see your message until now, thanks
[17:05] <ScottK> Sorry to have bad news.
[17:06] <mok0> ScottK: that's life :-)
[17:06] <mok0> ScottK: I will contact upstream about the non-distributable file, it is probably a mistake
[17:06] <ScottK> That would certainly be the best answer.
[17:07] <mok0> ScottK: yeah, he updates his distro quite often, so he may do it quickly
[17:14] <mok0> ScottK: Good you spotted that file. It is from the damned CCDC, it is outrageous that they impose this kind of copyright on public research data. Grrrrr
[17:15] <ScottK> mok0: I highly recommend running grep -ir copyright * over any package you make.  It's often very instructive.
[17:16] <mok0> ScottK: I thought I did, apparently not on the data files :-(
[17:16] <ScottK> Well there are a number of other licenses that need to be added to debian/copyright too, so ...
[17:17] <mok0> *blush*
[17:46] <mok0> ScottK: the bitstream font files in the package are md5-identical to the ones in the package ttf-bitstream-vera
[17:47] <mok0> ScottK: These font files are not installed by the gamgi package, however, instead there is a dependency on ttf-bitstream-vera
[17:47] <ScottK> mok0: Then they should not be installed and you should use the packaged ones already.
[17:47] <ScottK> Ah.
[17:47] <ScottK> OK.
[17:48] <ScottK> It still needs mentioning in debian/copyright (I think) since it's distributed in the source package.
[17:48] <mok0> ScottK: I will look at the ttf-bitstream-vera package and see what they do about the license there.
[17:48] <ScottK> OK.
[17:48] <mok0> ScottK: yes I will mention it in copyright
[17:49] <ScottK> Sounds good.
[17:50] <mok0> ScottK: Have we started to use the Debian.source file now?
[17:50] <mok0> It's been discussed on the dd list
[18:23] <__iron> hi just a question, who can i get a listing about linux-interfaces
[18:27] <laga> "redrum" like in "the shining"?
[18:27] <Treenaks> also, why would you sponsor it
[19:33] <therealnanotube> hey guys... so let's say i have a package, that depends on say, package A. but there are two actual packages that provide package A. how can i specify that my package "prefers" one of the two that provide package A?
[19:33] <therealnanotube> is that even possible?
[19:33] <laga> say A is provided by B and C
[19:33] <therealnanotube> ok
[19:33] <laga> then you can just say: depend on "B | A"
[19:34] <laga> or "B | C | A"
[19:34] <laga> not sure if that's a good idea, but it should work ;)
[19:34] <therealnanotube> so then if i have "B | C | A", that means that it will try B, and will try for C only if B is not available?
[19:35] <laga> i think so
[19:35] <therealnanotube> what if B happens not to provide A in some cases - will it recognize that? or will it just go for B first no matter what?
[19:36] <laga> that escapes my knowledge ;)
[19:37] <therealnanotube> the actual situation is this: in gutsy 64bit, package linux32 is provided by unix-util, and by linux32. in all other versions of ubuntu, it is provided either by linux32 (feisty and earlier), or unix-util (hardy), but not both.
[19:37] <therealnanotube> on gutsy, if i depend on linux32, it conflicts with unix-util, and removes a whole bunch of other stuff from unix-util as a result, which is undesirable.
[19:37] <therealnanotube> so how do i make a package that says "depend on linux32, and take it from unix-util if it provides it, otherwise, take it from linux32" ?
[19:38] <geser> therealnanotube: have you tried versioned dependencies?
[19:39] <geser> Depends: util-linux (>= version_with_linux32) | linux32
[19:42] <therealnanotube> geser: ah, interesting idea. that just might work! thanks :)
[19:43] <therealnanotube> laga: thanks to you to, for trying :)
[19:43] <therealnanotube> laga: *too
[19:57] <CarlF1> i want to try building a .deb from http://debian.cs.binghamton.edu/debian/pool/main/c/couchdb/ - the .gz is sources that I need to apt-get suorce?
[19:57] <tillux> heya. supposed I wanted to 'create' a gui for cloneZilla. what'd be the first step I'd have to make? or... what would you recommend me to read?
[19:58] <andrew_sayers> I think I've found a bug in Vino with security implications - should it be filed in Ubuntu, and can someone confirm that I'm not being ridiculous?
[19:59] <andrew_sayers> Basically, vino checks your password before asking the user whether to allow a connection, meaning that attackers can brute force passwords even if you specify to ask for a connection.
[20:00] <andrew_sayers> Er, ask to confirm incoming connections.
[20:01] <Laney> Probably best to talk to upstream first
[20:01] <Laney> But LP has a facility for security bugs too, so you can put it there too
[20:01] <andrew_sayers> Fair enough.  I'll go and create yet another account and password I'll never use again... :s
[20:02] <CarlF1> what is the sources.list line?  this aint it: deb http://debian.cs.binghamton.edu debian main
[20:50] <TomJaeger> Okay, I'm going to plead my case one last time.
[20:50] <TomJaeger> The package that I'd like to advocate: http://revu.ubuntuwire.com/details.py?package=easystroke
[20:51] <TomJaeger> It's a gesture recognition application for X11 with a gtk interface.
[20:53] <TomJaeger> It's not one of those programs that does the same thing as a million others before, there really isn't anything comparable in the archive.
[20:53] <TomJaeger> The program closest to it is probably strokeit for windows, but I think easystroke is a lot more sophisticated by now.
[20:56] <TomJaeger> It doesn't require editing config files and it can deal with arbitrary strokes, as it doesn't try to dissect them into line segments.
[20:58] <TomJaeger> Reviewing the package should be very easy, I've looked over a lot of suggestions that were made for other packages and incorporated what was applicable to my package.
[20:58] <TomJaeger> I've just released a new upstream version in which I got rid of all the code from other people, so the copyright file is really simple now.
[21:00] <TomJaeger> There's a clear demand for the package to be intrepid: http://ubuntuforums.org/showthread.php?t=837032  (or you could google for strokit and linux)
[21:01] <highvoltage> Goodnight.
[21:02] <TomJaeger> Plus, I've put a lot of effort into this package (I even released a new (now obsolete) upstream version at one point because of licensing issues)
[21:03] <TomJaeger> The package is also in my PPA if you want to check it out: https://launchpad.net/~thjaeger/+archive
[21:03] <TomJaeger> So yeah, I'd really appreciate it if a MOTU would find the time to review the package and I won't bother you any longer. Thanks.
[21:19] <CarlF1> http://packages.ubuntu.com is mia - should I tell anyone?
[21:19] <CarlF1> im guessing there is a #u-admin or something
[21:28] <cody-somerville> no, there isn't
[21:28] <jpds> CarlF1: Close, #canonical-sysadmin, but I think they may be out for the weekened.
[21:29] <CarlF1> thanks
[21:42] <TomJaeger> Any tablet pc users in here at all?
[22:26] <RAOF> CarlF1: That site is run by a volunteer, whose server is getting overwhelmed; he recently posted that he couldn't reasonably continue providing it.
[22:26] <wgrant> RAOF: No it isn't.
[22:27] <wgrant> It's now hosted by Canonical.
[22:27] <RAOF> wgrant: Oh, cool.  That got resolved!
[22:27] <wgrant> A while ago now, but yes.
[22:27] <wgrant> So it's a bit more reliable now.
[22:27] <jpds> It's been down for weeks.
[22:30] <directhex> i use it all the time. it's most certainly NOT weeks
[23:28] <SolarWar> once your package is uploaded from revu- what is the next step?
[23:29] <Kopfgeldjaeger> Wait, and wait, and... or annoy some MOTUs so that they have a look at your package :)
[23:34] <SolarWar> no, i mean, after it has been advocated by two MOTUs
[23:34] <Kopfgeldjaeger> ah, ok
[23:35] <SolarWar> :)
[23:35] <Kopfgeldjaeger> A MOTU will archive it and then it comes into NEW. When the archive admins accept it, it will come into universe
[23:35] <Kopfgeldjaeger> afaik
[23:37] <SolarWar> is there a way to track its acceptance after its left the revu listing?
[23:38] <Laney> SolarWar: You can look at the queues on LP
[23:39] <Laney> Ubuntu -> Intrepid -> Show uploads  on the right, I think
[23:39] <SolarWar> :)
[23:39] <SolarWar> thanks
[23:41] <TomJaeger> SolarWar, how /did/ you get two MOTUs to review your package?
[23:43] <SolarWar> I filled a LP packaging bug, and then packaged it my self- the bug got assigned to someone and i had them look at my (got some comments) and then the bug got assigned to me
[23:43] <SolarWar> and from there it was a bit of waiting and requesting people to review here
[23:43] <SolarWar> i hear people have been really busy with the intrepids release and they haven't been having regular review days this cycle
[23:45] <TomJaeger> Thanks
[23:46] <SolarWar> np
[23:50] <TomJaeger> trying to ask people here to review my package really hasn't worked out very well for me.