[00:01] <Legendario> lfaraone, that's the weird. There is no diff.gz
[00:01] <lfaraone> Legendario: did you run "debuild -S"? (upper case S)
[00:01] <persia> And did you get a message about trouble finding the orig.tar.gz?
[00:01] <Legendario> lfaraone, yes. debuild -S -sa
[00:01] <lfaraone> Legendario: like persia said, could dpkg find the orig.tar.gz?
[00:03] <Legendario> lfaraone, no. because it program is released as a simple bash script. It offered me the option to create a tar.gz file, which I accepted
[00:04] <azeem> what is "It" which offered this to you?
[00:04] <Legendario> azeem, debuild i guess
[00:05] <azeem> I never saw debuild offering options to accept
[00:05] <azeem> maybe it was dh_make?
[00:05] <persia> Um, for packaging a bash script, one needs to create one's own tarball.
[00:06] <persia> https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCompiling is a bit out of date, but not a bad outline.
[00:06] <persia> If doing it now, I'd be recommending DEP3, DEP5, and dh(1)
[00:07] <Legendario> persia, the tarball was created, but not the diff.gz
[00:07] <azeem> Legendario: because there was no .orig.tar.gz, it created a native package
[00:07] <azeem> i.e. just .tar.gz and .dsc
[00:07] <persia> I know.  But creating the tarball with debuild isn't the preferred method.  See the notes from my class.
[00:11] <Legendario> persia, ok. I'll give it a try. thanks
[00:49] <lfaraone> persia: is there a problem with using standards-version 3.8.4? REVU lintian complains.
[00:52] <persia> lfaraone: spooky only has lintian 2.2.17ubuntu1.1 : you could backport a newer one if it's easy, and we can request that it be installed.
[00:53]  * persia doesn't have permission to install stuff
[01:08] <lfaraone> In what cases is update-notifier's "you must restart foo" triggered? Groundcontrol's postinst copies /usr/share/groundcontrol/groundcontrol-restart-required.update-notifier to /var/lib/update-notifier/user.d but I don't get a popup.
[01:08] <lfaraone> (the app specifically to restart is nautilus)
[01:10] <persia> I remember being very confused by that before, although I don't remember the results of my research.  I believe I had to look at the update-notifier source to figure it out.
[01:11] <RAOF> IIRC you also need to actually trigger update-notifier in some way; simply dropping a file there doesn't trigger it.
[01:13] <persia> That sounds like something that would benefit from dpkg trigger support.
[01:13] <RAOF> It does, yes.
[01:13] <lfaraone> RAOF: I'm looking at firefox's packaging right now. it's a very very very complicated debian/ directory, but I don't *think* they are triggering anything.
[01:13] <hyperair> check the postinst.
[01:14] <lfaraone> hyperair: that's what I'm looking at.
[01:14] <hyperair> ah
[01:15] <lfaraone> Firefox <http://paste.ubuntu.com/371346/> vs groundcontrol <http://paste.ubuntu.com/371345/>
[01:16] <lfaraone> hyperair, RAOF, persia, am I missing something?
[01:17] <RAOF> That part of the postinst is actually getting triggered, right?  IE: you're seeing the updatenotifier file being copied?
[01:17] <hyperair> lfaraone: check the [ -d $UPDATENOTIFIERDIR ] block
[01:17] <persia> Both of those are horrible.  They should have case wrappers to handle the different sorts of arguments.
[01:17] <hyperair> it looks like it's copying a file into /var/lib/update-notifier/user.d
[01:18] <aaron> is there any page that show's packages up for adoptions?
[01:18] <persia> aaron: No, we don't have maintainers in Ubuntu.
[01:18] <TiMiDo> oh ic.
[01:18] <persia> TiMiDo: But, there's lots of work needs doing.  What sort of stuff would you like to do?
[01:19] <TiMiDo> persia, possible packaging and i do a lot of translations also
[01:20] <lfaraone> hyperair: yep. our file <http://paste.ubuntu.com/371347/> their file <http://paste.ubuntu.com/371350/>
[01:20] <persia> TiMiDo: Well, I can't tell you anything about translations (I think there's an #ubuntu-translators or some such for that, but I could be wrong).
[01:21] <hyperair> lfaraone: does it work?
[01:21] <TiMiDo> true. perhaps now i want to do packages now =)
[01:21] <persia> For packaging, most of the work is bugfixing, but there's also some package updates pending.  Which of those sound more interesting?
[01:21] <lfaraone> hyperair: firefox's does, I think.
[01:21] <TiMiDo> i will ove to do the updates pending =)
[01:21] <TiMiDo> that wi'll be cool
[01:21] <hyperair> lfaraone: read update-notifier's source then =p
[01:21] <persia> TiMiDo: Take a look at http://qa.ubuntuwire.com/uehs
[01:22] <persia> Packages not in sync with upstream is the most accessible list, but the other lists may be interesting to investigate as well.
[01:22] <TiMiDo> is html2ps already updated it?
[01:22]  * hyperair notices that lots of ubuntu-specific stuff seem to either be poorly documented, or written badly.
[01:22] <persia> hyperair: patches welcome :)
[01:22] <hyperair> usplash is one example of poor documentation
[01:22] <hyperair> notify-osd has endless leaks
[01:23] <hyperair> and this update-notifier is yet another example of poor documentation
[01:23] <hyperair> not to mention update-manager and its grinding of the CPU using Xorg
[01:23] <TiMiDo> persia, so i could update the package and after the update to where do i upload it?
[01:24] <kklimonda> hyperair, is usplash even actively developed anymore? I was under the impression that it was dropped in favor of the plymouth
[01:24] <hyperair> persia: it's easier to rewrite the whole thing than patch it up. notify-osd felt like hack upon hack while being implemented.
[01:24] <lfaraone> AHA. I need to "touch /var/lib/update-notifier/dpkg-run-stamp"!
[01:24] <hyperair> kklimonda: i'm not sure, but while i was trying to write up usplash support for uswsusp, i couldn't *any* documentation.
[01:24] <persia> TiMiDo: Attach the new diff.gz to a bug requesting the upgrade, and subscribe one of ubuntu-main-sponsors or ubuntu-universe-sponsors, and someone will review.
[01:24] <lfaraone> I have no idea where firefox is doing that, but as soon as I did that update-notifier started working!
[01:24] <TiMiDo> oh okey that's cool
[01:25] <persia> TiMiDo: rmadison can help you figure out which sponsor group to subscribe.
[01:25] <TiMiDo> rmadison?
[01:25] <TiMiDo> who is that?
[01:25] <persia> hyperair: Sure, but even rewrites tend to be accepted, if they are good.
[01:25] <persia> TiMiDo: rmadison is a command.
[01:25] <TiMiDo> oh
[01:26] <hyperair> persia: well, i'll look into it sometime, regarding notify-osd.
[01:26] <persia> heh.  Best of luck :)
[01:26] <hyperair> maybe i'll name it notify-osd++ or something lol
[01:26] <lfaraone> hyperair: tradition is to call it notify-osd-ng :)
[01:27] <hyperair> lfaraone: ah yes. of course. =p
[01:27] <lfaraone> hyperair: I'm personally planning on writing purity-ng when I get a Round Tuit.
[01:27] <hyperair> lfaraone: putty is awesome on windows. on linux it's just.. useless. redundant.
[01:28] <lfaraone> hyperair: purity, not putty. Purity is an interactive CLI test application.
[01:28] <lfaraone> hyperair: currently orphaned on Debian.
[01:28] <hyperair> oh whoops
[01:28] <hyperair> interactive CLI test eh
[01:28] <hyperair> interesting.
[01:29] <lfaraone> hyperair: it's really more of a game. see http://en.wikipedia.org/wiki/Purity_test
[01:29] <hyperair> basically to test interactive CLI apps non-interactively?
[01:29] <lfaraone> hyperair: no, it tests *you*.
[01:29] <hyperair> huh
[01:29] <hyperair> oh lol
[01:34] <lfaraone> persia: would it be a bad idea to try to run groundcontrol through NEW if I have any hope of meeting the Feature Freeze?
[01:34] <persia> Debian NEW or Ubuntu NEW?
[01:34] <lfaraone> persia: personally I prefer doing fixes/packaging through Debian when I can, and then backporting changes to Ubuntu releases / wait for them to sync.
[01:34] <lfaraone> persia: Debian, that is.
[01:35] <persia> I'm not sure of current Debian NEW latencies, but I think you'd be pushing it.
[01:35] <persia> For the new package I did last week, I uploaded to Ubuntu, and expect to send to Debian sometime this week.
[01:36] <persia> (I'm waiting for two people who said they would be users to install it and confirm it works)
[01:56] <lfaraone> persia: if you have a moment, I'd appreciate it if you could glance at http://revu.ubuntuwire.com/details.py?upid=7616
[01:57]  * persia sucks at python packaging, and hopes that someone else will jump up and offer to review before this is compelte
[01:57] <persia> lfaraone: maintainer should be "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[01:58] <persia> Upstream should grow some StartupNotify support :)
[01:58] <persia> Name, and Generic Name should be translated the same way that Comment is in the .desktop file.
[01:58] <persia> s/seemlessly/seamlessly/ in Comment[en] in the .desktop file
[01:59] <persia> X-Ubuntu-Gettext-Domain doesn't mean anything for stuff not in the langpacks
[01:59] <persia> Categories should be restricted to those in http://standards.freedesktop.org/menu-spec/latest/apa.html
[01:59] <persia> The .desktop file ought be upstream anyway, rather than in the diff.gz
[02:00] <persia> I prefer ([\d\.]+) to (.*) in watch files, just in case.
[02:00] <persia> Maintainer scripts should check arguments : see http://women.debian.org/wiki/English/MaintainerScripts
[02:01] <lfaraone> persia: odd, it is upstream, I wonder why .desktop is in the diff.gz...
[02:02] <persia> I'd prefer a get-orig-source that pulled released tarballs, rather than alternately pulling from bzr.
[02:02] <persia> I tend to prefer DEB5 copyright, but it's fine as-is.
[02:02] <lfaraone> persia: it only does that if you have bzr(revno) in changelog.
[02:02] <persia> I also prefer to use Name <email> consistently, rather than Name (email) (in debian/copyright)
[02:03] <persia> debian/copyright fails to specify where the upstream source lives.
[02:03] <persia> lfaraone: Yeah, well.  It also fails the works-from-any-directory test.
[02:04] <persia> Requiring both CDBS and debhelper (>=7.0.0) strikes me as odd.  Most CDBS packages are compat level 6 compliant, unless there is something fancy I don't see.
[02:05] <persia> Extra trailing comma in Build-Depends
[02:06] <persia> Changelog entry for "Misc packaging Fixes" seems pointless for an initial release.  nice to give credit, but I'm unsure if this is the best way.
[02:06] <lfaraone> persia: well, I don't know how else to give doctormo credit for doing 90% of the work :)
[02:06] <persia> Odd to see a polish translation for restart-required, but not the .desktop file, and no English translation for restart-required.
[02:07] <persia> lfaraone: Re-check the first line of debian/copyright :)
[02:07] <persia> And I'd probably set debian/compat to 6 unless there was some special reason to use 7.
[02:08] <persia> Obviously, check lintian -iIEV and --pedantic on source and binary changes :)  Fix all the rest, and I'll run builds and check that.
[02:08] <TiMiDo> persia, after the update i upload the package in launchpad?
[02:08] <persia> I've also not yet reviewed upstream licensing, although I suspect it's likely clean, given the identity of upstream.
[02:08] <lfaraone> persia: would you rather I remove the polish translations? I don't speak it :)
[02:09] <persia> TiMiDo: Not quite.  Once you get a working updated package, attach the diff.gz of the updated version to a bug in launchpad.  Make sure that you have a working watch file or get-orig-source rule.
[02:09] <TiMiDo> okey
[02:10] <persia> lfaraone: No, I just find it odd to have only that one bit available in polish, and not in english, the more so when the .desktop file is partially translated in English, and not Polish.
[02:10] <lfaraone> persia: what I really don't understand is why the desktop file ends up in the diff. It's part of upstream source!
[02:11] <persia> lfaraone: Maybe it's duplicated somewhere, or generated on clean somehow?
[02:11] <lfaraone> persia: if so, I'll stab the CDBS maintainers.
[02:12] <persia> Or switch to dh(1) :)  Mind you, you'd also have to switch to python-support.
[02:12] <persia> I do intend to fix python-distutils-extra at some point, as it gives me an excuse to learn python packaging, but that's not happening in the next couple days, and probably not for FF>
[02:15] <lfaraone> persia: does pysupport handle XS-Python-Versions: fields?
[02:15] <persia> No idea.  That's on my list of stuff to investigate :)
[02:23] <ddecator> persia, how soon would be too soon to ask? =p
[02:23] <persia> About 5 minutes ago :)
[02:23] <ddecator> perfect timing
[02:24] <persia> So, I don't recommend packaging new stuff until one has a fair bit of experience working with other people's packages, as this gives one a better feel for all the different ways to do things, and lets one develop a personal style.
[02:24] <lfaraone> persia: aha! "Found cached translation database" seems to be the culprit. It still happens when I'm using dh(1) however...
[02:24] <persia> That said, if one has something one *really* wants to package for some reason, the following process is what I use:
[02:24] <lfaraone> Merging translations into groundcontrol.desktop.
[02:25] <lfaraone> * "Found cached translation database\nMerging translations into groundcontrol.desktop."
[02:25] <persia> lfaraone: Hrm.  I'm not sure about that.  Might want to turn on DH_VERBOSE to find the culprit.
[02:25] <lfaraone> No idea what that means...
[02:25] <persia> ddecator: make a directory with the package name, and create a debian directory.
[02:25] <persia> ddecator: In that directory, create a watch file (man uscan can help).
[02:26] <persia> ddecator: run dch --create to create a debian/changelog, and use uscan to get the upstream source
[02:26] <persia> ddecator: unpack the upstream source, and move your debian directory into the unpacked directory.
[02:26] <lfaraone> ddecator: absolutely no change in the output. (this was on a source upload)
[02:26] <lfaraone> persia: you mean when DH_VERBOSE=1, right?
[02:26] <persia> ddecator: `echo 7 > debian/compat` and `cp /usr/share/doc/debhelper/examples/rules.tiny debian/rules`
[02:26] <persia> lfaraone: Yep.
[02:26] <lfaraone> s/ ddecator / persia /
[02:27] <persia> It *should* make it more verbose.
[02:27] <ddecator> lfaraone, haha, i wondered about that
[02:27] <lfaraone> persia: so yeah, no change. See bzr branch lp:~groundcontrollers/groundcontrol/debianfiles :)
[02:28] <persia> ddecator: use `licensecheck -r --copyright .` and `suspicious-source` to create and verify debian/copyright : I tend to use the format described at http://dep.debian.net/deps/dep5
[02:28] <persia> ddecator: Create a debian/control file based on http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.html/ch-controlfields.html
[02:29] <persia> Build the source, and you've created a buggy package.  That's it.
[02:29] <persia> Fixing the bugs is the fun bit :)  lintian -iIEV and --pedantic can help find some issues to think about.
[02:30] <ddecator> thanks persia, i'm trying to work my way into getting into some debugging, but i'm a little lost on where to start so i'm learning basic python so i can recognize code. and suggestions as to some files i can use to practice packaging?
[02:31] <persia> python-mkdebian automates it for most python programs.  Not into my favorite style, but it tends to mostly work.
[02:32] <ddecator> i wanna figure out how to do it manually though
[02:33] <persia> ddecator: Um, OK.  I think that you'd do much better to explore other existing packages for that, rather than trying to do it from scratch.
[02:34] <ddecator> any suggestions?
[02:35] <persia> Go find some bugs, and investigate them.  Pull the relevant sources.  Explore.  If they look like they can be fixed with packaging (fail to upgrade are common cases for this), try changing stuff.
[02:35] <ddecator> alright...thanks persia =)
[02:38] <lfaraone> persia: aha. upstream only ships a desktop.in file!
[02:40] <persia> lfaraone: Aha!  That's fine, but the upstream build system shouldn't be updating it on clean, which seems like the candidate culprit.
[02:40] <persia> Unless something else is happening deep within CDBS.
[02:40] <lfaraone> persia: well, now it's dh7 :)
[02:40] <lfaraone> persia: same problem.
[02:41] <persia> Well, same issue.  Either upstream is updating it on clean, or something else is happening deep within dh.
[02:41] <persia> pastebin the source build log with DH_VERBOSE=1?
[02:41] <lfaraone> persia: you're right, it happens on clean.
[02:43] <persia> lfaraone: So, it probably ought happen on build.  Having clean make it less clean just seems wrong somehow.
[02:43] <lfaraone> persia: right again. it's a python package, so there's something wrong with setup.py
[02:43] <lfaraone> looks like they run it regardless of what command is run.
[02:45] <lfaraone> persia: code in question: http://sprunge.us/EeZG?python lines 39 to 45
[02:46] <persia> Um, and this gets back to my plan to learn how python works :)
[02:47] <lfaraone> persia: setup.py is widely regarded as black magic.
[02:47] <lfaraone> if you consider wide to be {lfaraone}
[02:48] <persia> Well, some people say that about make, which I find trivial.  I think it depends on your background.
[03:03]  * ScottK finds setup.py generally pretty accessible.
[03:04] <persia> ScottK: Any idea why the .desktop file is reconstructed on clean for groundcontrol on REVU?
[03:04] <ScottK> persia: Nope.  Haven't looked.
[04:59] <mok0> jdong: ping
[06:26] <suji11> how to create man page?
[06:29] <suji11> Anyone Advocate/Review my package IOK http://revu.ubuntuwire.com/p/iok
[06:33] <slytherin> geser: FYI ... libpdfbox-java merge is done.
[07:39] <dholbach> good morning
[07:39] <ivoks> morning
[07:40] <dholbach> hey ivoks
[07:40] <ivoks> what's up daniel?
[07:40] <suji11> Anyone Advocate/Review my package IOK http://revu.ubuntuwire.com/p/iok
[07:41] <dholbach> ivoks: how are you doing?
[07:41] <ivoks> dholbach: fine, trying to implement two blueprints :)
[07:41] <ivoks> dholbach: you?
[07:42] <dholbach> ivoks: still a bit jetlagged, but I'm OK - and my luggage is supposed to arrive later today - YAY! :)
[07:43] <ivoks> dholbach: good luck with those; in dallas, i had to pick up my luaggage and i did that 2 days before departure :)
[07:43] <dholbach> ivoks: in Berlin it usually arrives the day later and they call you in advance to tell you they bring it - worked for me the last 3 times :)
[07:43] <ivoks> nice :)
[07:44] <dholbach> yeah, I'm grateful it always happened to me on the way back and not when I was going somewhere :)
[07:44] <ivoks> hehe
[07:45] <crimsun> heh, good thing I didn't do the corosync merge ;)
[07:46] <ivoks> crimsun: yeah, don't touch it :D
[07:47] <crimsun> ivoks: it would have been done at least a month ago, but I pinged chuck about it first.  good thing.
[07:56] <dholbach> do we have a revu hacker here? http://revu.ubuntuwire.com/p/zope.index gets redirected to http://revu.ubuntuwire.com/p/zope. which makes reviewing the package a bit hard!
[08:14] <TiMiDo> hey i have a question i was wondering if i can port up BitchX
[08:16] <crimsun> meaning take on maintainership of it? The best place to do it is probably in Debian; see Debian #451373
[08:18] <TiMiDo> well bx is back up and i'm one of there Developers
[08:19] <crimsun> again, the best place to take it up again is in Debian
[08:20] <TiMiDo> all those bugs are Fixed.
[08:20] <TiMiDo> =)
[08:21] <crimsun> great. Makes sense to prepare an upload to Sid, then.
[08:21] <TiMiDo> it's almost there =
[08:34] <Linux-CLI> hi
[08:34] <Linux-CLI> I'm having some trouble with my debian files
[08:34] <Linux-CLI> (trying to package a .deb)
[08:35] <Linux-CLI> Can I have a copy of your 'rules' file, please?
[08:47] <slytherin> Linux-CLI: Instead tell us what the problem is and we will try to solve it.
[08:48] <TiMiDo> Linux-CLI, lol why would you need another packages rules?
[08:48] <TiMiDo> that's seems odd.
[08:49] <Linux-CLI> slytherin & TiMiDo: I'll try one last time...
[08:49] <TiMiDo> last time of?
[08:52] <Linux-CLI> TiMiDo: Attempting without help :P
[08:52] <Linux-CLI> :p
[08:53]  * Linux-CLI is installing devscripts
[08:55]  * Linux-CLI is [still] installing devscripts (1min & 40secs)
[08:56] <Linux-CLI> (took 5min, installing now)
[08:59] <TiMiDo> cool
[08:59] <TiMiDo> did it .... finish?
[08:59] <TiMiDo> with 0 errors?
[09:04] <Linux-CLI> Nope
[09:04] <Linux-CLI> Could you please help me? - Here is my Terminal output: http://pastebin.com/d3b20a4ff
[09:07]  * Linux-CLI is uploading his /debian/ folder
[09:07] <persia> Linux-CLI: Upstream doesn't appear to provide a clean rule in the makefile.  Either another rule needs to be called, upstream needs to be fixed, another build system used, or cleanup done manually.
[09:08] <Linux-CLI> How do I do cleanup manually?
[09:08] <Linux-CLI> Also, do you know of a good free hosting site where I can put my tar.gz?
[09:08] <Linux-CLI> (just the /debian/ folder)
[09:09] <Linux-CLI> http://www.mediafire.com/?tjni1zzm2mj
[09:10] <Linux-CLI> ^There is the copy of my /debian/ folder
[09:10] <Linux-CLI> (Within the program directory)
[09:10] <persia> You can do whatever clean needs to do in the clean rule in debian/rules.
[09:10] <Linux-CLI> What type of clean is required?
[09:10] <persia> Ideally, it should put the source back into the state it was in prior to the build.
[09:11] <Linux-CLI> I don't understand
[09:11] <Linux-CLI> Can you show me an example of that type of rules file?
[09:14] <persia> I don't know of one offhand, but it's usually a number of -rm calls.
[09:14] <Linux-CLI> persia: I understand that the rules file needs to clean the source, reverting the source back to its prior state. Could you please take a look at my /debian/ subdirectory, and tell me what else needs to be changed?
[09:15] <Linux-CLI> persia: So it's just to install
[09:15] <persia> What?
[09:15] <Linux-CLI> persia: So it's just to uninstall
[09:15] <persia> apparently I can't look: attempting to see your debian/ folder shows me a poker advertisement.
[09:16] <persia> No, it's clean.  Has almost nothing to do with install.  Local stuff created during build.
[09:17] <Linux-CLI> persia: How about an xdcc?
[09:18] <Linux-CLI> 2KB btw
[09:20] <Linux-CLI> http://uploading.com/files/f6666e9e/debian.tar.gz/
[09:20] <persia> I'm not sure that works through the chain of bots and proxies I use to interact with communication services.
[09:21] <persia> That one takes me to a picture of an underdressed woman and a heap of text in a language I don't read.
[09:22] <persia> I'm not going to click on any more of your URLs.
[09:24] <Linux-CLI> Well it sounds like you're not recommending anyway for me to give you the files.
[09:24] <Linux-CLI> Goodbye.
[09:25] <persia> Bother.  I don't mean to be rude, I'm just tired and insufficiently motivated to do a review of a known broken package right now.
[09:25] <ogra> persia, bah, it doesnt take me to a naked woman !
[09:25] <persia> ogra: I didn't say "naked": she was in her underwear.  But I'm not surprised, as it seems to have extensive geolocation logic.
[09:26] <ogra> indeed, the ad changed for me
[09:26] <persia> So different places probably get different images, depending on local tolerances.
[09:26] <ogra> i can buy an iphone instead :)
[09:27] <ogra> its an upload service that keeps the upload for 30sec btw ...
[09:27] <ogra> err, "keeps you from getting the upload"
[09:28] <persia> So you can look at the advertisements?  Aha!
[09:28] <ogra> right, it puts up an ad that stays for 30sec before you can download the referred file
[09:29] <persia> The first one might have been the same thing.  I'm not sure I waited long enough.
[09:31]  * persia goes back to figuring out how to use a mandonline and lets backscroll accumulate
[09:32] <\sh> persia: "use a mandonline" you mean "mandoline"?
[09:44] <coolbhavi> hello I just reinstalled my system and i m getting a secret key not found error http://paste.ubuntu.com/371550/
[09:44] <coolbhavi>  I made a new key and uploaded it to lp
[09:45] <coolbhavi>   http://paste.ubuntu.com/371551/ <-- my .bashrc
[09:47] <coolbhavi> i sourced .bashrc too
[09:47] <coolbhavi> any ideas?
[10:03] <persia> rsajdok: I just write what it says on the labeling.  It's for cutting stuff.  Nifty, but the conclusion was to not cut stuff for this next meal :)
[10:18] <suji11> hi i'm creating man page for my package, here also any restriction for description like control file.
[10:19] <persia> Could you rephrase the question?
[10:21] <suji11> ya, in control file in description each line should be less than 75 characters, like that the man page description also each line should be less than 75 characters or any other condtions?
[10:22] <persia> I tend to prefer that all text files in source be less than 75 characters, as it makes it easier to quote chunks of stuff in email, etc.
[10:23] <persia> I don't think it's a firm rule though.  Just make sure you can parse it cleanly with nroff -man in a regular terminal.
[10:24] <suji11> ok
[10:39] <ScottK> james_w: Would you please have another look at 517161.  At least if I'm reading Launchpad right the "and move it to Multiverse" part of the bug doesn't seem to have been done.
[10:42] <james_w> ScottK: it hasn't, I missed that as it was requesting something that had already happened
[10:45] <james_w> done now
[11:05] <ScottK> james_w: Thanks.
[11:56] <corecode> hey
[11:57] <corecode> i'm wondering how to submit a bugfix to a package
[11:57] <corecode> i generated the source deb, should i just attach the .diff.gz to the bug report?
[11:58] <persia> corecode: Generally we prefer the output of the debdiff between the current version in the archive and your new candidate version.
[11:58] <persia> The exception would be for upstream version upgrades, where this gets extremely noisy.
[11:58] <corecode> okay
[12:00] <corecode> i just realized it is a main package, but the process will be the same
[12:01] <persia> Yeah, except you would have asked in #ubuntu-devel, and I would have answered the same way :)
[12:01] <persia> Remember to subscribe ubuntu-main-sponsors to the bug once you've attached the patch.  We7re always looking for better ways to track that, but haven't found a clean one yet.
[12:02] <EagleScreen> corecode: please read this guide https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[12:06] <corecode> doing so, thanks
[12:19] <corecode> so what do i do to get this processed?  should i just wait or contact somebody?
[12:23] <ScottK> Once you subscribe the appropriate sponsorship team to the bug, then you just wait.
[12:24] <corecode> i see
[12:26] <corecode> reading the wiki page, i'm not sure how to submit it for sponsorship
[12:35] <slytherin> corecode: in launchpad bug, click 'subscribe someone else' and then search for ubuntu-main-sponsors
[12:35] <corecode> ah
[12:35] <corecode> thanks!
[12:35] <corecode> because the wiki page says "don't subscribe anybody if the bug needs sponsorship"
[12:36] <slytherin> that is surely wrong
[12:36] <corecode> great, thanks
[12:37] <corecode> the workflow in ubuntu is so easy to use, it is a real joy
[12:37] <corecode> coming from bsd's packaging...
[12:37] <corecode> "Do not assign a bug to anyone if it needs sponsorship. "
[12:37] <corecode> is the wording
[12:42] <ScottK> corecode: Assign is different than subscribe.
[12:42] <ScottK> Subscribe is the right thing to do.
[13:04] <corecode> ah
[13:27] <Q-FUNK> could anyone with core-dev upload priviledges please act on bug #493628 ?
[13:27] <Q-FUNK> this one goes to main, so I cannot do anthing about it myself.
[13:38] <Laney> What's the proper way to record copyright status of a PD work in DEP5?
[13:38] <Laney> Copyright: none?
[13:40] <persia> Q-FUNK: You might want to ask in -devel for stuff that needs main, as many folk here also don't have that access.
[13:41] <Q-FUNK> ok, will do
[13:41] <persia> Laney: License: PD, etc.
[13:41] <persia> Laney: But note that PD isn't valid in all jurisdictions, and has different requirements in different jurisdictions.  It can be quite hard to properly document and demonstrate that something is truly PD.
[13:42] <persia> I'd drop the Copyright: header for that license, but, again, this isn't valid in some places: better to identify the copyright holder, if possible, and document that copyright has expired or is explicitly not claimed, or similar.
[13:42] <Laney> persia: This is just a simple shell script that I took from another source package (from the debian/ directory, even). I don't expect it to be contentious.
[13:42] <Laney> "If the work is truly public domain, this should be stated in the copyright field." from DEP5
[13:43]  * Laney will just explain a little
[13:43] <persia> It's unlikely that anything in a debian/ directory is in the public domain, unless the authors are from specific locations that still permit it (public domain requires lots more time than Debian has had in any jurisdiction where the Berne convention applies).
[13:44] <persia> Doesn't mean the authors don't think it is, of course :)
[13:44] <Laney> :)
[13:52] <dholbach> any revu hackers here?
[13:53] <persia> What do you need?  I'm not a REVU hacker, but I'm a REVU admin, so can do some stuff.
[13:53] <dholbach> http://revu.ubuntuwire.com/p/zope.index gets redirected to http://revu.ubuntuwire.com/p/zope.
[13:53] <dholbach> which doesn't help reviewing it :)
[13:54] <persia> pull-revu-source might work.
[13:54] <Laney> you should file a bug on lp/revu
[13:54] <persia> But yeah, file a bug.
[13:54]  * persia can't fix that: requires coding hackery, or at least webserver config hackery
[13:55] <Laney> can you see what the httpd logs say about the request?
[13:56] <dholbach> bug 518827
[13:56]  * persia tries
[13:57]  * Laney has access to that box, but no permissions to view logs
[13:57] <persia> Laney: I don't have sufficient permission to view the logs either.
[13:57] <persia> I suspect we're hitting some URL rewriting rule though, from the observed behaviour.
[13:57] <BlackZ> hi persia ;)
[13:58] <dholbach> htaccess.tmpl:#Get rid of "index" in directories:    <--   maybe?
[13:58] <Laney> sounds suspicious
[13:59] <dholbach> anyway, I managed to get the source which helped :)
[14:00] <persia> Submitted patches tend to get applied fairly smoothly.  I don't remember if there is a current staging server running though.
[14:00] <dholbach> I'm sorry, I don't have time for setting up a REVU instance and patching it now
[14:01] <persia> Heh.  Understood :)
[14:12] <statik> hello
[14:13] <statik> where is the current Standards-Version defined?
[14:13] <statik> I'm getting lintian warnings on debian packages that want Standards-Version: 3.8.4, but my lucid stuff seems to want to be at 3.8.3
[14:14] <persia> statik: That's hard to say precisely.  I tend to believe that the current version of the ubuntu-policy package represents the current standards version, but you may do as well with the current version of the debian-policy package, in case ubuntu-policy hasn't been updated recently.
[14:14] <statik> persia, thanks! i'll dig into those packages
[14:14] <persia> statik: Where do you see the warnings?
[14:14] <statik> persia, lintian I think
[14:14] <persia> statik: dpkg -l or apt-cache show ... | Version is likely a good way to check, rather than heavier digging.
[14:15] <persia> Which lintian?
[14:15] <statik> on mentors.debian.net it wants 3.8.4. when I build locally on lucid, lintian wants 3.8.3
[14:16] <persia> Well then :)  That tells you the versions of policy supported by lintian on mentors and lucid :)
[14:16] <statik> persia, yep, I already knew that. my question was where/how is it defined :)
[14:16] <persia> I doubt that many 3.8.4 compliant packages won't be 3.8.3 compliant in sufficiently significant ways to break lucid though :)
[14:18] <statik> yeah, i hope so
[14:19] <persia> Well, ask yourself a different question: Are you able to construct a package that is both 3.8.2 and 3.8.4 compliant?
[14:19] <statik> so this is weird, http://packages.debian.org/search?keywords=debian-policy is at 3.8.3 also. I wonder where 3.8.4 comes from
[14:19] <persia> It's in sid.
[14:20] <slytherin> statik: Standards version is as known to the lintian version on your machine. Usually lintian is updated after policy is updated.
[14:20] <persia> More than usually.  Always.  It's not possible to check compliance against unspecified policy.
[14:20] <slytherin> sid has policy version 3.8.4 and also lintian that knows about this policy.
[14:21] <statik> ah, so this page is outdated? http://packages.debian.org/sid/debian-policy it shows 3.8.3
[14:21] <slytherin> checking
[14:21]  * persia generally finds packages.${distro} to be out-of-date in all cases
[14:22] <Rhonda> statik: There is issues with the harddisk on packages.debian.org, currently worked on.
[14:22] <slytherin> statik: yes it is outdated. there seems to be problem for last few days. A more updated information is available here - http://packages.qa.debian.org/d/debian-policy.html
[14:22] <Rhonda> persia: It's even in testing already. :)
[14:22] <statik> thanks! i have learned a lot in just 5 minutes, I'm glad I asked
[14:22] <persia> Rhonda: See, this is why I should be using rmadison rather than apt-cache show :)
[14:23] <Rhonda> ;)
[14:23] <slytherin> And this problem is causing issues with requestsync tool when trying to request sync against package form unstable (instead of squeeze).
[14:23] <slytherin> requestsync detects version but can not retrieve changelog of latest version.
[14:33] <Rhonda> damnit. How many time do I have to fix 518829 for lucid?
[14:41] <Laney> Does anyone have access to an {hppa,kfreebsd-i386,ppc,s390} box with a sid environment, and the inclination to run a test build for me? :)
[14:42]  * persia can do sid/ppc, but will have some latency reporting results if the build takes longer than 20 minutes.
[14:42] <Laney> I just want to know if it starts really
[14:42] <persia> OK.  Where is it?
[14:42] <Laney> persia: git://git.debian.org/git/collab-maint/agda-stdlib.git (or I can sort out the source package if you want it)
[14:42] <persia> If you give me something to dget, I don't have to think about it, which I like :)
[14:43] <Laney> ok
[14:45] <Laney> persia: http://orangesquash.org.uk/~laney/agda-stdlib/agda-stdlib_0.3-2.dsc
[14:46] <Laney> as long as it gets past https://buildd.debian.org/fetch.cgi?pkg=agda-stdlib&arch=powerpc&ver=0.3-1&stamp=1265532637&file=log&as=raw and starts typechecking then I'll be happy
[14:52] <persia> Laney: http://paste.ubuntu.com/371732/
[14:52] <Laney> erm
[14:53] <Laney> I think I'd call that an external problem :)
[14:53] <Laney> thanks persia
[14:54] <persia> Laney: Yeah.  Doesn't really look like your script, but I built my chroot with debootstrap --variant=buildd and would expect a simiar model for other folk.
[14:54] <persia> Laney: Do you really need whatever pulls exim to build?
[14:55] <Laney> I don't even see exim being pulled in
[14:55] <ScottK> If so, it should pull in Postfix in any case.
[14:55] <ScottK> or default-mta
[14:55] <Laney> and no, most definitely not
[14:56] <persia> ScottK: For sid?
[14:56] <ScottK> persia: Oh, sorry.
[14:56] <ScottK> default-mta is good
[14:56] <ScottK> exim4 provides that in Debian
[14:57] <Laney> I wonder where that problem actually came from
[14:57] <Laney> it's before anything got installed
[14:57] <Laney> could be a broken chroot; can you build other packages with it?
[14:57] <persia> I could recently, but I dist-upgrade daily.  I'll check.
[15:01] <persia> Laney: Hrm.  Seems my chroot is indeed broken.  I'll sort it in the morning, and let you know (unless you find someone else to do a build sooner).
[15:01] <\sh> wth is the "bug elevation team"?
[15:02] <ddecator> \sh, ignore that
[15:03] <ddecator> \sh, some guy over the weekend made that team and invited a whole bunch of others to join, nobody knows why so they're trying to figure out what is going on
[15:03] <\sh> ddecator: grmpf...
[15:15] <dholbach> sistpoty|work, RainCT: good work on the fix!
[15:15] <sistpoty|work> dholbach: thanks for the bug report :)
[15:15] <dholbach> no worries
[15:16] <dholbach> that'll help to get schooltool into lucid, let's hope we get it done :)
[15:19] <slytherin> Laney: If you are still looking for a ppc build test I will be able to do that in an hour.
[15:31] <bddebian> Heya gang
[15:37] <bjsnider> siretart, ping
[15:43] <siretart> bjsnider: please ping again in 1h
[15:43] <sebner> huhu bddebian siretart sistpoty|work dholbach \sh :D
[15:43] <sistpoty|work> hi sebner
[15:43] <sistpoty|work> hi bddebian
[15:52] <bddebian> Heya sebner, sistpoty|work
[16:15] <fagan> hmmm has anyone tried packaging songbird yet?
[16:15] <fagan> or looked into it
[16:15] <micahg> fagan: yes
[16:15] <fagan> its not in the repos
[16:16] <micahg> we have dailies, but are broke at the moment
[16:16] <micahg> fagan: there are several upstream bugs that need to be fixed before it can get into repos
[16:16] <fagan> micahg: could we put the stable version though?
[16:16] <micahg> fagan: no, there are upstream bugs wrt packaging in Ubuntu
[16:17] <fagan> ah ok
[16:17] <hyperair> what are the issues?
[16:17] <sebner> hola hyperair :)
[16:18] <hyperair> hola sebner :)
[16:19] <fagan> micahg: have the bugs been reported on their bugzilla?
[16:19] <micahg> fagan: yes
[16:19] <micahg> bug 94494
[16:21] <fagan> micahg: how long do we have before the archive freeze to get it in
[16:21] <micahg> fagan: not going to happen this cycle
[16:21] <micahg> hopefully lucid +1
[16:21] <fagan> ah ok I was thinking of chasing it up myself
[16:22] <micahg> fagan: I hope to have to dailies back up before Lucid is released though
[16:23] <micahg> fagan: songbird 17708
[16:24] <micahg> hmm..that should be a registered tracker...
[16:24] <hyperair> banshee ftw.
[16:24]  * hyperair hides
[16:24] <micahg> fagan: http://bugzilla.songbirdnest.com/show_bug.cgi?id=17708
[16:24] <fagan> micahg: thanks
[16:25] <micahg> fagan: also, it won't build w/system sqlite anymore...
[16:25] <fagan> so they are after patching xul to get songbird working and didnt upstream it
[16:26] <micahg> fagan: yeah
[16:26] <fagan> micahg: well thats dumb
[16:26] <micahg> fagan: any further discussion probably should be in #ubuntu-mozillateam as this is OT for this channel
[16:26] <fagan> true
[16:39] <siretart> bjsnider: sorry, need to run home now. please write mail
[16:44] <sebner> bddebian: any thoughts on http://pastebin.com/m27558410  ?
[17:04] <anilg> Hi All
[17:05] <anilg> I'm a developer on the Nexenta Project (an Ubuntu port on opensolaris), and we are looking to hire folks well versed with ubuntu packaging.. is there a list I can post to reach interested ubuntu MOTUs?
[17:06] <azeem_> (there's debian-jobs@lists.debian.org as well, assuming that folks well versed in Debian packaging would be interesting as well)
[17:09] <anilg> azeem_: thanks, I'll ping there as well.. but ubuntu MOTUs would be perfect, as Nexenta is a port of Ubuntu
[17:09] <azeem_> anilg: anyway, is Nexenta a company? The website is a .org...
[17:09] <anilg> there's .com as well
[17:10] <azeem_> I tried that first, but it didn't look related
[17:10] <azeem_> "Enterprise class OpenStorage"?
[17:10] <anilg> A storage distribution on top of Nexenta
[17:10] <anilg> with commercial support
[17:10] <azeem_> oh
[17:10] <azeem_> so this company is looking for folks, or the Nexenta project?
[17:10] <azeem_> or is the company looking for folks to work on the Nexenta project?
[17:11] <anilg> Well the company is the sponsor of the Project :) So the company will pay for work to be done on the project
[17:11] <azeem_> ok
[17:11] <azeem_> anilg: so you're an employee?
[17:11] <azeem_> just curious :)
[17:11] <anilg> yes
[17:12] <anilg> I'm one of the Nexenta developers
[17:12] <azeem_> are there a lot of non-company people working on the Nexenta project?
[17:12] <azeem_> cool
[17:12] <anilg> yes.. usually they join comtribute for a while and lay low again
[17:13] <anilg> So what is the best way to reach Ubuntu MOTUs for this? (apart from this channel)
[17:13] <anilg> I was hoping there was a ubuntu-jobs list
[17:14] <azeem_> well, maybe there is, I don't have a good overview over all the lists
[17:15] <azeem_> I know about debian-jobs because I'm subscribed on it :)
[17:19] <geser> anilg: there is ubuntu-motu@lists.ubuntu.com but it's probably not the right list for job offers
[17:20] <anilg> geser: Yes i figured as much.. so wanted to confirm here before
[17:20] <anilg> how about a "meta" mail to this list .. "can you point me to the Jobs list"? :p
[17:21] <hyperair> anyone from motu-sru feel like looking into a borked bansheelyricsplugin which crashes banshee consistently on karmic? fixed in lucid, patch attached for karmic.
[17:21] <hyperair> bug #511868
[17:24] <geser> hyperair: motu-sru got merged into ubuntu-sru
[17:24] <hyperair> eh?
[17:24] <hyperair> seriously?
[17:24] <hyperair> hmm
[17:24]  * hyperair subscribes ubuntu-sru then
[17:25] <geser> hyperair: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-December/000650.html
[17:26] <hyperair> geser: thanks
[17:36] <dupondje> how to make a dpatch exactly for in the debian/patches folder ?
[17:39] <geser> dpatch-edit-patch
[17:50] <_stink_> question about pbuilder: i have a .pbuilderrc that sets up some shell variables used to rename the tarball/results directories.  i also have a script in my hook directory in which i'd like to use those same shell variables, but it seems like they're not getting "passed" to the hook script.  any idea how to do this?
[17:54] <_stink_> aha!  gotta export it in .pbuilderrc.
[18:19] <rmunn> Question about the Lucid release schedule: I have a new package up at http://revu.ubuntuwire.com/p/python-nltk waiting for advocates. To get it into Lucid, do I have to get two advocates before the Feature Freeze (Feb. 18th)? Or is the fact that it went onto REVU before Feature Freeze enough, even if the package only picks up advocates after Feature Freeze?
[18:21] <rmunn> NLTK is apparently a rather famous library in its field (computational linguistics), and there's been an O'Reilly book about it (http://oreilly.com/catalog/9780596516499) so I'd like to get it into Lucid if I can. The package looks good from what others have said about it, it just needs MOTU advocates.
[18:28] <crimsun> rmunn: please ping me in one hour if no one else has looked at it yet.
[18:41] <rmunn> crimsun: Will do.
[18:42] <crimsun> rmunn: thanks
[19:03] <dooooomi> hi, i'm looking for someone to review gtklick, a metronome for JACK: http://revu.ubuntuwire.com/p/gtklick
[19:04] <dooooomi> also, klick (the command line version) could use another review: http://revu.ubuntuwire.com/p/klick
[19:32] <geser> rmunn: python-nltk fails to build: ImportError: No module named yaml
[19:36] <jcfp> rmunn: added a few comments for python-nltk
[19:38] <rmunn> python-yaml is in Depends, does Build-Depends not inherit from Depends?
[19:38] <dupondje> ok, I created a dpatch, added it in debian/00list, now whats next ? dch -i (is there some specific layout for a patch update ?) and then a debdiff ?
[19:38] <rmunn> I assumed that Build-Depends would be a superset of Depends.
[19:39] <geser> rmunn: no, Depends is for runtime dependencies
[19:39] <geser> and a package can have totally different runtime and build dependencies
[19:40] <rmunn> Right, I'll need to upload a new version of the source package then.
[19:43] <geser> rmunn: why is there a Java .jar inside the python-nltk package?
[19:44] <rmunn> I was just looking at that... it's part of the upstream nltk-2.0b8 release, and I think it can probably be removed
[19:45] <rmunn> The upstream release includes a javasrc/ directory that looks like it contains the source to that nltk.jar file, so I'm guessing nltk.jar can be removed from the python-nltk source package and a separate package created for the Java stuff.
[19:46] <geser> yes (if there is need for it)
[19:46] <rmunn> I missed this earlier when I looked at the package (and here I was so proud of my detailed examination, catching all the different licenses for the debian/copyright file... *blush*)
[19:58] <asbin> Hi, I'm looking for someone to review my package "ushare", it's not a major change and it closes 3 LP bugs ...
[19:59] <randomaction> asbin: https://wiki.ubuntu.com/SponsorshipProcess
[20:02] <asbin> randomaction: thanks ! I've never uploaded a new version of an existing package ...
[20:03] <randomaction> yep, it's much easier
[20:03] <asbin> on the other side, I have 4 more (new) packages to review ... is it the right place ?
[20:16] <asbin> I'm looking for someone to review 3 new packages : libnfo, libplayer, and libvalhalla (libvalhalla needs libnfo to build ...). Thanks !
[20:23] <petski> Nine months ago I've submitted a patch to resolve a bug (LP: 371103). My patch was added in Karmic (which was the devel-release at that time), but was never included in Jaunty. Still, nine month later, no single response from motu-sru. Maybe the bug status is wrong for some motu-sru attention?
[20:26] <kklimonda> bug 371103
[20:27] <kklimonda> petski, afair the process has changed recently - now you first subscribe sponsors, they upload package to -proposed and SRU team accepts it
[20:28] <petski> thanks kklimonda, just subscribed ubuntu-universe-sponsors
[20:29] <petski> now let's wait for nine months again to see what happens :P
[21:00] <Zelut> I just uploaded the latest release of my project. Is it too late to have the package updated for Lucid?
[21:02] <randomaction> Zelut: no it's not, new features are accepted until Feb 18th: https://wiki.ubuntu.com/LucidReleaseSchedule
[21:03] <Zelut> great.
[21:03] <Zelut> I'm no packager so I'll need someone to pull it in for me. It is already packaged in Lucid, just dated, so I'm sure it'll be easy.
[21:10] <randomaction> Zelut: does your package have a maintainer? You might want to ping them so that they prepare a new version before the freeze, it's not like there's much time left.
[21:11] <Zelut> randomaction: i don't think the maintainer i worked with last is still around..
[21:12] <hakaishi> Hi everyone! Would anyone please advocate/review qt-shutdown-p? http://revu.ubuntuwire.com/p/qt-shutdown-p
[21:16] <hakaishi> ... because the deadline is drawing nearer, isn't it? https://wiki.ubuntu.com/LucidReleaseSchedule
[21:41] <lfaraone> Hey, does anybody have time to do a quick REVU of a package? http://revu.ubuntuwire.com/details.py?upid=7621
[21:44] <rmunn> Well here's an interesting situation. I'm going to have to either remove functionality from upstream's version of the package or else delay it past the Lucid freeze date.
[21:44] <lfaraone> rmunn: why's that?
[21:44] <rmunn> Reasons why are kind of long, so I'll just link to http://revu.ubuntuwire.com/details.py?upid=7593&deletecomment=7550 rather than repeat it here.
[21:44] <rmunn> Basically, they include a binary .jar file that I can't recreate from source because its dependencies aren't in Debian.
[21:45] <rmunn> It's all open-source so they're not breaking any licenses, or even the DFSG as far as I can tell, but it does present a problem for my creating a python-nltk package for Ubuntu.
[21:46] <lfaraone> rmunn: are all the binaries in upstream's package accompanied with source?
[21:46] <rmunn> I don't think it's acceptable to have binaries in the source package (how do you prove they aren't Trojaned?), so that means either removing the offending .jar and the functionality that depends on it (integration with Mallet), or else delaying until Lucid+1.
[21:46] <rmunn> lfaraone: Yes
[21:47] <lfaraone> rmunn: just repack mallet removing the binaries and give the package a "dfsg" extention.
[21:47] <rmunn> Upstream's tarball includes three .java files, and a .jar that's just those three files compiled. Problem is that they depend on mallet, which isn't avialable in Debian right now.
[21:47] <rmunn> lfaraone: Mallet is >10 megs, and I don't know Java enough to be certain I'd get everything right. I can try, but I'm not sure I'll make the Feature Freeze.
[21:48] <lfaraone> rmunn: sorry, I mean does Mallet have source in their upstream tarball?
[21:48] <lfaraone> rmunn: well, if it's between removing the package and losing a feature, I'd go for the latter short term.
[21:48] <rmunn> lfaraone: Ah, I see. I believe the answer is yes (they're an open-source project), but I'll double-check.
[21:49] <rmunn> lfaraone: Likewise, and I've told upstream about my intentions: "Remove Mallet support to get it into Lucid, put Mallet support back in Lucid+1".
[21:49] <lfaraone> rmunn: if mallet uses ant, CDBS has you covered :)
[21:51] <rmunn> lfaraone: Yeah, mallet uses ant. But it's been years since I've touched Java, not to mention I'm pretty new to Debian packaging. I'm going to make lots of newbie mistakes... :-)
[21:51] <lfaraone> jono: hi, doctormo told me you'd agreed to sponsor groundcontrol. it currently depends on python-xdgapp, which is in REVU. do you have a chance to take a look at it?
[21:52] <lfaraone> rmunn: ... and when you do, we're here to help!
[21:52] <lfaraone> (just not me personally, I try to avoid java too :)
[21:53] <rmunn> Guess I'm going to be asking lots of questions on #ubuntu-java, then.
[21:54] <jono> lfaraone, I am not sponsoring it myself, I am not a MOTU
[21:55] <jono> lfaraone, I am just trying to help doctormo be successful as part of a wider opportunistic developer project in Ubuntu
[21:56] <lfaraone> jono: mk. we have two packages to get reviewed and push through REVU before feature freeze, then :)
[21:56] <jono> lfaraone, :)
[21:56] <jono> is this something you can help coordinate?
[21:57] <lfaraone> jono: well, I built the packages and am willing to respond to any problems with them.
[21:57] <Zelut> nhandler: ping
[23:34] <nhandler> Zelut: Pong
[23:36] <Zelut> nhandler: haven't heard back from you on my last email regarding origami. think you can help get it updated for Lucid?
[23:37] <nhandler> Zelut: Ah yes. Let me look at it now
[23:38] <Zelut> nhandler: I just pushed 0.7.3 to the upstream download page. should be simple to update the package from 0.7.1.6 (or whatever it is that is packaged)