[00:31] <sistpoty> hi folks
[00:36] <ScottK> Hi sistpoty.  I've been waiting for you ....
[00:36] <sistpoty> hey ScottK
[00:36] <sistpoty> what's up?
[00:37] <ScottK> sistpoty: Could you have a look at http://revu.ubuntuwire.com/p/searchandrescue
[00:37] <ScottK> I got it as far as I could ...
[00:38] <ScottK> I just noticed someone proposed a patch.
[00:38] <sistpoty> ScottK: I'll give it a shot
[00:38] <ScottK> sistpoty: I'd settle for a review of the proposed patch.
[00:38] <ScottK> Thanks.
[00:54] <sistpoty> ScottK: after looking a bit, I guess the provided patch is brittle and might break later on. I'll try to fix it in a better way right now.
[00:54] <ScottK> sistpoty: Thanks.
[00:55] <ScottK> sistpoty: Feel free to take what I started and upload when you're done.  I mostly just want it taken care of.
[00:55] <sistpoty> ScottK: that means I must do rigourous testing though *g*
[00:56] <ScottK> Fortunately it doesn't require special hardware ....
[00:56] <ScottK> Yep
[00:56] <sistpoty> yeah, since I switch from nvidia to ati, I still failed to get gl working again... which is good for my productivity :)
[01:00] <sistpoty> ScottK: just uploaded a building version to revu, completely untested yet though (and missing documentation in changelog)...
[01:01]  * sistpoty will fix that after a smoke, unless someone beats him to it
[01:08] <quentusrex> How to I make sure a jaunty package is built with libtool 1.5 even though a newer one is out?
[01:11] <sistpoty> quentusrex: there only seems to be 2.2.6a-1ubuntu1 in jaunty, seems like you'll need to use that one
[01:11] <sistpoty> quentusrex: so I assume you'll need to adjust the build system if it fails with this version
[01:13] <sistpoty> ScottK: crack, I can't test searchandrescue... it seems to need opengl nowadays
[01:13] <quentusrex> sistpoty: I need to use the package from hardy
[01:13] <quentusrex> libtool 1.5.26
[01:14] <ScottK> quentusrex: You can't for the archive. It needs to be the current one.
[01:14] <sistpoty> ScottK: can you finish searchandrescue?
[01:15] <ScottK> sistpoty: Add a changelog entry and I can.
[01:15] <ScottK> I need to know what you did ....
[01:22] <sistpoty> ScottK: done, uploaded again to revu (this time w.o. .orig.tar.gz)
[01:22] <ScottK> OK.
[01:22] <ScottK> Thanks
[01:22] <sistpoty> you're welcome
[01:24] <sistpoty> urgh, revu is really getting low on disk space: /dev/md0              70568272  60785428   6226396  91% /srv
[01:24]  * sistpoty makes mental note to really run fdupes soonish
[01:27] <sistpoty> slangasek: that was a great idea to make a session regarding ftbfs here from you... I've been sponsoring a number of ftbfs uploads today :)
[01:45] <ScottK> Seriously, I think I should be able to reliably type the 4 letters in dpkg by now in the correct order.
[01:46] <sistpoty> heh
[01:56] <ScottK> sistpoty: Seems to work.  Uploaded.
[01:56] <sistpoty> thanks ScottK! :)
[01:57] <ScottK> sistpoty: I don't know why we don't use REVU that way more often.
[01:57] <ScottK> sistpoty: What do you think about the lubuntu meta FFe?
[01:59] <sistpoty> ScottK: 1) I think there's also a use case for a VCS here, but admitted, I don't like bzr too much... yet
[01:59] <ScottK> I think bzr is fine.  It's certainly easier to get started with than Git.
[01:59] <ScottK> VCS just seems like overkill for this though.
[02:00] <ScottK> debuild -S and dput revu just seems very easy.
[02:01] <sistpoty> if the package is already in a vcs, ready to be modified, known by a VCS that everyone uses, that would make things simpler
[02:01] <sistpoty> however I agree, right now revu is really a good option to do collaborative maintenance
[02:02] <sistpoty> a killer feature would be to just say "build this in a ppa" button, and let revu add a link to build log and download buttons
[02:04] <sistpoty> ScottK: lubuntu seems promising, but I must admit, that I'd like to see it covered by -mobile actually (I have no idea what -mobile needs in this regard)
[02:04] <sistpoty> ScottK: so I'm basically happy if ogra is happy with it (or lool) :)
[02:05] <ScottK> sistpoty: I see mobile as a Canonical effort and Lubuntu seems (at least significantly) community driven.  I don't think Ubuntu Mobile should get a veto on this (also it's from an approved spec from UDS, so I think that decision is made)
[02:05] <sistpoty> crap, it was StevenK who's delegate for -mobile nowadays (just to highlight even more people *g*)
[02:08] <sistpoty> ScottK: I must admit that I rather consider -mobile to get it shaped and help with working out processes (ogra did offer good guidance so far)... so I don't that there'll be a veto
[02:09] <ScottK> I think sooner is better than later.
[02:09] <sistpoty> ScottK: you mean to get it in/approved?
[02:09] <ScottK> Yes
[02:10] <sistpoty> ScottK: sure thing, I actually only ignored it so far, since I believed to be already approved *g*
[02:10] <ScottK> I think we've waited enough
[02:16] <sistpoty> ScottK: looking at the lengthy ffe, did I get it right that you already gave a +1 and I can grant the ffe?
[02:16] <ScottK> sistpoty: Yes.
[02:16] <ScottK> Package is on REVU too.
[02:16] <sistpoty> ScottK: ah, thanks!
[02:18] <sistpoty> (comment added)
[02:20] <ScottK> bddebian: What do you think about an NMU for http://packages.qa.debian.org/s/searchandrescue.html so it can get back in Testing?
[02:21] <ScottK> (sistpoty and I just fixed it for Ubuntu)
[02:21] <sistpoty> :)
=== pochu_ is now known as pochu
[02:52] <sistpoty> ScottK: what are the supported python versions atm? (looking at bug #424770, which only supports 2.5 as per debian's changelog)
[02:52] <ubottu> Launchpad bug 424770 in bpython "[FFe] Sync bpython 0.9.4-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/424770
[02:52] <ScottK> sistpoty: For us 2.6 is default and 2.5 is supported.
[02:53] <sistpoty> ScottK: so it wouldn't be a blocker to restrict it to 2.5?
[02:53] <ScottK> sistpoty: It's not a regression from where it is now, I guess.
[02:53] <sistpoty> ah, thanks!
[02:53] <ScottK> So I don't know that it's a blocker.
[02:54] <ScottK> I'm reluctant to expend a lot of effort on 2.5 only stuff.
[02:54] <sistpoty> heh
[03:01] <p3rror> hello how to sync a package into ubuntu from debian ?
[03:01] <ScottK> p3rror: What do you want to sync and why?
[03:02] <p3rror> well i was looking for a sponsor of a package for ubuntu, and it was listed in debian new packages
[03:03] <ScottK> What package?
[03:03] <p3rror> http://revu.ubuntuwire.com/p/python-ipcalc
[03:04] <ScottK> So it's just gotten into Debian.
[03:04] <ScottK> We are past the point in this release cycle where we are accepting new packages.  At the start of the next development cycle, it will automatically get synced from Debian.  There isn't anything you need to do.
[03:06] <p3rror> I see
[03:07] <p3rror> thanks ScottK
[03:07] <ScottK> You're welcome.
[03:08] <ScottK> Did Debian switch to gcc 4.4 in Sid?
[03:13] <sistpoty> ScottK: not yet, at least for my last dist-upgrade since two days ago
[03:14] <ScottK> Yep.  Just checked.
[03:42]  * sistpoty goes to bed... gn8 everyone
=== obama is now known as vorian
=== micahg1 is now known as micahg
=== Hobbsee is now known as Hobbsee_
=== Hobbsee_ is now known as Hobbsee
[07:18] <LLStarks> riddle me this.
[07:18] <LLStarks> why do flashplugin-installer and adobe-flashplugin exist?
[07:19] <dtchen> the former is available for both i386 and amd64; the latter is only available for i386
[07:20] <dtchen> flashplugin-installer provides an upgrade path (of sorts) for people using the older flashplugin-nonfree on either i386 or amd64
[07:20] <LLStarks> why is adobe-flashplugin in karmic older than the one in jaunty?
[07:20] <dtchen> more to the point, the latter exists in the partner repository and is Adobe-blessed
[07:21] <dtchen> the former is community-maintained (and not Adobe-blessed)
[07:21] <dtchen> also, the former will pull in nspluginwrapper
[07:21] <LLStarks> "also, the former will pull in nspluginwrapper" bull
[07:22] <LLStarks> only on x64 may that be true, if at all
[07:22] <dtchen> Depends: nspluginwrapper (>= 0.9.91.4-2ubuntu1) [amd64],
[07:24] <LLStarks> anyway, thanks for the clarifcation
[07:25] <dtchen> the outdated version in karmic is likely due to it not being copied/uploaded, it being karmic and all.
[07:26] <dtchen> it ultimately doesn't matter, since debian/postinst uses http://archive.canonical.com/pool/partner/a/adobe-flashplugin/
[07:26] <dtchen> (that's debian/postinst for flashplugin-installer, of course)
[08:45] <lool> ScottK: lubuntu > absolutely agreed with you
[08:46] <lool> ScottK: If LXDE folks are stuck or need help or dont know how to do specific things (e.g. seeds or cdimages) we're happy to help them there, but we dont want to shape LUbuntu entirely
=== yofel_ is now known as yofel
=== alefteris_ is now known as alefteris
[12:51] <ojwb> debian has a security fix for xapian-omega which ubuntu doesn't: http://www.debian.org/security/2009/dsa-1882
[12:52] <ojwb> is it preferred to just patch the fix, or sync the package from debian?  the one in debian doesn't have new features compared to the current karmic one
[12:53] <geser> sync to karmic and patch for release ubuntu versions
[12:54] <ojwb> ok, i'll file a ticket in launchpad
[12:54] <ojwb> oh, hmm
[12:54] <ojwb> the current debian one depends on a newer xapian-core, which is in main
[13:06] <ojwb> looks like that could be synced too - i'll file tickets and see - thanks geser
[13:07]  * ajmitch just loves the fun of setting up a new laptop with all its buggy hardware support
[13:08] <j^> hi,
[13:09] <j^> http://revu.ubuntuwire.com/p/oggvideotools - with all issues addressed it would be nice to see it in universe
[13:15] <debfx> how do I patch files that have mixed line endings (CRLF, LF)?
[13:17] <debfx> I can generate a diff using --ignore-all-space but patch won't apply it
[13:19] <c_korn> debfx: you can use fromdos/todos from the frotodos package to convert the line endings
[13:33] <debfx> c_korn: do I have to backup the file and restore it in the clean target?
[13:34] <c_korn> debfx: you can just do that in the patch. maybe I did not understand your problem correctly.
[13:41] <debfx> c_korn: you are suggesting to convert the line endings of the target file before patching it?
[13:42] <c_korn> debfx: eh, no. in the patch. I thought the line endings would cause trouble.
[13:42] <c_korn> so in case of the quilt build system.
[13:42] <c_korn> quilt new line_endings.patch
[13:42] <c_korn> quilt add file.bla
[13:42] <c_korn> fromdos file.bla
[13:42] <c_korn> quilt refresh
[13:51] <debfx> c_korn: I don't want to change the line endings. when I edit the file, the text editor saves the file with consitent line endings, so the diff gets huge
[13:51] <debfx> s/consitent/consistent/
[13:55] <debfx> patch should have an option to ignore the line ending type, but it doesn't
[13:57] <c_korn> debfx: hm, so you just need another editor which does not auto-convert them. maybe nano does not do that.
[14:03] <debfx> c_korn: nano auto-converts but vi doesn't, I think
[14:52] <Quintasan> http://pastebin.com/f50c38a87 <--- can anyone tell why debuild complains about missing separator? I'm using tabs there
[14:53] <Quintasan> line 26 exactly
[14:59] <Laney> has anyone noticed Artur Rona touching old bugs?
[14:59]  * Laney has had three bugmails now because he's been doing weird things
[15:00] <Laney> bug 233866 for example
[15:00] <ubottu> Launchpad bug 233866 in gnome-lokkit "Please merge gnome-lokkit 0.50.22-7.2 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/233866
[15:01] <azeem> Quintasan: maybe not in the lines before?
[15:02] <Quintasan> azeem: nvm, my vim had "set expandtab" option
[15:57] <geser> Adri2000: Hi, do you still use djplay? I've got a version build without glib1.2 and could need some more testing of it
=== yofel_ is now known as yofel
[18:18] <Rotund> Is it too late to package a new program to make it in for Karmic?
[18:20] <geser> yes
[18:21] <Rotund> Just looked at their page and they actually offer debs, so I'm not totally in the dark on it.
[18:21] <sebner> Rotund: upstream debs are usually in a very bad state though ;)
[18:22] <Rotund> sebner, better than if I'd checkinstall it ;)
[18:22] <sebner> geser: with sync requests/uploads I fixed ~10 FTBFS starting yesterday evening :D
[18:22] <sebner> Rotund: such packages won't enter the archive anyways ;)
[18:22] <geser> sebner: nice
[18:23] <sebner> geser: and now a great tip to reduce FTBFS significantly. don't do archive rebuilds :P
[18:23] <geser> bah
[18:24] <Rotund> what's an FTCFS?
[18:24] <Rotund> BFS
[18:24] <geser> Failed To Build From Source
[18:27] <sebner> geser: what can I do against http://launchpadlibrarian.net/31753888/buildlog_ubuntu-karmic-i386.cdk_1%3A1.0.2-2build1_FAILEDTOBUILD.txt.gz ? I just uploaded a -build1 version since it built locally so I thought it was a temporary issue :\
[18:29] <geser> this is from the main archive or the test-rebuild one?
[18:29] <sebner> geser: both
[18:30] <geser> sebner: run "apt-cache madison libjgrapht0.6-java" and look at the component of the source and the binary package
[18:32] <sebner> geser: multiverse for the b-d, the other thing is universe
[18:33] <geser> sebner: looking at http://packages.qa.debian.org/libj/libjgrapht-java/news/20081228T123018Z.html it should be in multiverse
[18:33] <geser> so the source is misplaced
[18:34] <geser> or at least some investigation is need if it's for universe or multiverse
[18:34] <sebner> geser: how can this happen (source in universe, binary in multiverse) ?
[18:35] <geser> oversight when processing NEW I guess
[18:35] <sebner> you are the last uploader btw, hihi
[18:36] <ScottK> Also sometime stuff gets moved and then all the BD don't get moved.
[18:36] <geser> this seems proper investigation: see Debian bug #546040
[18:36] <ubottu> Debian bug 546040 in ftp.debian.org "RM: libjgrapht-java -- NVIU; 5" [Normal,Open] http://bugs.debian.org/546040
[18:36] <geser> it mentions an improved packaging as libjgrapht0.6-java (not yet in Ubuntu)
[18:38] <sebner> geser: would it need a FFe?
[18:38] <ScottK> sebner: Yes.  Is it in Debian?
[18:39] <geser> ScottK: yes, it's in Debian
[18:39] <geser> ScottK: does a new packaging of the same upstream version need a FFe?
[18:39] <ScottK> I think sync of a missing BD is a good idea, but does need FFe.
[18:39] <ScottK> Oh
[18:39]  * ScottK didn't follow all the context.
[18:40] <ScottK> If it just needs binary new and it's repackaging, I think that's OK.
[18:40] <geser> ScottK: the situation is as following: we have libjgrapht-java with source in universe and binary split over universe and multiverse (in Debian the packages was uploaded to contrib)
[18:41] <ScottK> OK
[18:41] <geser> there is the above mentions removal bug in Debian for libjgrapht-java and a seperate packaging of the same upstream version as libjgrapht0.6-jave
[18:41] <ScottK> Split into a different source package then?
[18:43] <sebner> ScottK: source package has just been renamed
[18:43] <geser> sort of, as the API changed the new upstream version got uploaded as libjgrapht0.7-jave to experimental
[18:43] <ScottK> Even better.
[18:43] <ScottK> Then I think syncing the 0.6 one makes sense.  Are there other rdepends involved?
[18:43] <geser> and the 0.6 version packaged as libjgrapht0.6-java
[18:44] <geser> cdk, that's how it all started
[18:44] <geser> checking for more
[18:44] <sebner> heh
[18:44] <ScottK> Can be just change the BD on the one package to expect the old name for now?
[18:45] <ScottK> be/we
[18:45] <sebner> ScottK: it builds locally so imho yes
[18:46] <ScottK> If there's no other BD on the new package name, I think that's the best approach for now.
[18:47] <ScottK> It gets everything working with the least change (if I understand the situation correctly)
[18:48] <sebner> geser: what do you think?=
[18:48] <sebner> ScottK: so no FFe?
[18:49] <ScottK> Not for changing the BD to one that exists, no.
[18:50] <geser> and for syncing the new package (for the same upstream version we already have)? is a FFe needed
[18:50] <geser> it's a new source package after all
[18:52] <sebner> geser: New indeed but not something like that needs to be checked if it can enter the archive since we already know it's sane somehow :\
[18:52] <geser> FF is also about no new (source) packages
[18:53] <sebner> it's also no upstream though
[18:53] <sebner> *new upstream
[18:53] <sebner> +version
[18:53] <sebner> xD
[18:53] <ScottK> sebner: It needs an archive admin to review it.
[18:53] <geser> it's a uncommon case
[18:53] <ScottK> yes.
[18:54] <sebner> grrr, too strict imho but nvm
[18:55] <ScottK> sebner: The main reason to stop accepting new packages is archive admins have other stuff to do late in the cycle.  Why it's a new package affects if the FFe gets approved, but not if it should be reviewed.
[18:55] <ScottK> I still think it sounds WAY easier to just change the BD on one package.
[18:55] <geser> the current BD is correct (and would need to be changed if we sync)
[18:56] <geser> what needs to be figured out if we don't sync where the current package we have belongs: universe or multiverse
[18:57] <geser> and fix this mismatch of component of the source (universe) and the binaries (universe AND multiverse)
[18:58] <ScottK> I see.
[18:58] <sebner> geser: who is an expert with this stuff? We have to wait until tomorrow anyways to catch an archive admin
[18:58] <ScottK> Clearly this is more complex than I've been following.
[19:06] <geser> I don't understand why libjgrapht-java 0.6.0-5 went to contribg (the versions before that are in main, the upload to experimental (0.7) is also in contrib), libgrapht0.6-java 0.6.0-8 is in main again
[19:07] <sebner> geser: ?? -5 ist the old source package, -8 is already the renamed one (which is in main)
[19:08] <sebner> geser: Why -5 went to contrib is another secret x
[19:08] <sebner> xD
[19:08] <geser> yes -5 is the old (current in Ubuntu, requested for removal from Debian unstable), and -8 the renamed source package (not in Ubuntu, current in Debian unstable)
[19:09] <sebner> right
[19:55] <nicklas_>  hello, the built in update script for vuze dont work, it updates and all seems fine, but after the program restarts, it wants to do the same update again... now is this possible to fix or should i simply turn off the update thing in vuze?
[20:10] <nicklas_> you guys think its possible to get latest vuze version into repos?
=== lukjad007 is now known as Jimmy_Durante
=== Jimmy_Durante is now known as Schnozzola
=== Schnozzola is now known as lukjad007
[22:31] <AnAnt> should I subscribe u-u-s to this LP 429071 ?
[22:31] <ubottu> Launchpad bug 429071 in sl-modem "Bashim is DKMS script" [Undecided,New] https://launchpad.net/bugs/429071
[22:37] <AnAnt> note, I've attached a debdiff to fix that bug
=== Guest5227 is now known as santiago-ve