=== asac_ is now known as asac
[01:04] <hggdh> folks, there is a binary package called timeout, and it seems the source points to tct, a completely different package. What to do?
[01:04] <hggdh> !info timeout
[01:04] <ubottu> timeout (source: tct): run a command with a time limit. In component universe, is optional. Version 1.18-2 (jaunty), package size 23 kB, installed size 84 kB
[01:05] <hggdh> TCT is The Coroner's Toolkit, has nothing to do with timeout
[01:07] <hggdh> bah, forget
=== asac__ is now known as asac
=== dmb_ is now known as dmb
[04:34] <AnAnt> Hello, I have filed a merge request for mutt, also I have submitted the changes to Debian, and the maintainer accepted them and said that they will be in the next debian release of the package
[04:35] <AnAnt> so, should the debian bugs be attached to the merge request bug ?
[04:35] <AnAnt> or what ?
[04:35] <nhandler> AnAnt: I normally add a bug watch in the merge request bug
[04:35] <AnAnt> ok
[04:41] <AnAnt> but there are two bugs on Debian
[04:41] <AnAnt> since there are two changes now
[04:41] <ScottK> It's not critical about linking bugs for a merge.
[04:41] <AnAnt> ok
[04:42] <AnAnt> thanks
[04:42] <nhandler> Very true. I like to do it mainly to make it easier for me to see what patches got forwarded upstream for a merge
[04:42] <ScottK> Personally I think it's pretty pointless and I wouldn't worry about it.
[04:43] <nhandler> It is just something for organizational purposes
[04:47] <AnAnt> ok, thanks
[06:32] <dholbach> good morning
[06:35] <nellery> hi dholbach
[06:36] <dholbach> hey nellery!
[06:37] <ajmitch> morning dholbach
[06:38] <dholbach> hey ajmitch!
[07:10] <nellery> should new packages be uploaded the same as packages already in the archive?
[08:56] <dstansby> Hi guys, just wondering if anyone can help me with a slight problem I'm having
[08:57] <dstansby> I get this error message when trying to 'apt-get source' anything:
[08:57] <dstansby> Can't locate Dpkg/Vendor.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/local/bin/dpkg-source line 21.
[08:57] <dstansby> BEGIN failed--compilation aborted at /usr/local/bin/dpkg-source line 21.
[08:57] <dstansby> Unpack command 'dpkg-source -x qemu-launcher_1.7.4-1.dsc' failed.
[08:59] <soren> Yikes.
[08:59] <soren> Which version of Ubuntu are you running?
[08:59] <dstansby> 9.10
[09:00] <dstansby> It might be something to do with me patching and installing my own version of dpkg the other day, but I only made changes to .po files.
[09:01] <dstansby> Actually come to think of it, I might have accidentally installed the latest git release from debian :S
[09:01] <soren> You think? :)
[09:01] <dstansby> Yes
[09:01] <dstansby> How would I replace it with the latest ubuntu release?
[09:03] <soren> "sudo apt-get install dpkg/karmic" and hope for the best.
[09:03] <dstansby> Hmm, Selected version 1.14.24ubuntu2 (Ubuntu:9.10/karmic) for dpkg
[09:03] <dstansby> dpkg is already the newest version.
[09:04] <soren> `which dpkg`?
[09:05] <dstansby> What do you mean by which dpkg?
[09:05] <soren> Run the command: which dpkg
[09:06] <soren> And tell me what it says.
[09:06] <dstansby> /usr/local/bin/dpkg
[09:06] <soren> You're on your own :)
[09:06] <dstansby> Why, what have I done?
[09:07] <soren> You've installed a random version of dpkg in /usr/local.
[09:07] <dstansby> Where should it be installed?
[09:07] <soren> Heh..
[09:07] <soren> This is going to sound rude, but it really isn't meant to:
[09:08] <soren> If you don't know the answer to that question, you shouldn't be installing it *at all*.
[09:08] <dstansby> I've heard that kind of phrase several times in the forums
[09:09] <soren> Why were you installing dpkg from git in the first place?
[09:09] <dstansby> Because I was patching it for debian
[09:10] <dstansby> I downloaded it, changed some files and then foolishly and accidentally installed it
[09:10] <soren> Well.. Uninstall it somehow.
[09:11] <soren> Until you do, your (apparantly) broken version is likely to be causing you grief.
[09:11] <dstansby> I presume I'm going to have to chroot from another install/liveCD then
[09:11] <soren> Or change your PATH or use the correct dpkg explicitly (with full path).
[09:13] <dstansby> So where should the correct dpkg be installed to?
[09:13] <soren> I'm getting increasingly curious.. What exactly were you patching in dpkg?
[09:14] <dstansby> I was just correcting a grammatical error.
[09:15] <soren> Ah.
[09:15] <dstansby> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533171 If you're interested
[09:15] <ubottu> Debian bug 533171 in dpkg "Grammar mistake in dpkg" [Minor,Open]
[09:15] <soren> The "real" dpkg is in /usr/bin/dpkg
[09:15] <soren> ..but I'm not sure what you need that information for.
[09:16] <ajmitch> taking an axe to /usr/local could be fun
[09:17] <soren> sudo mv /usr/local /usr/local.oh.dear.I.shouldnt.have.done.that
[09:17] <soren> ftw
[09:18] <dstansby> At the risk of sounding like a complete idiot, would moving the dpkg files from /usr/bin to /usr/local/bin (thus replacing my broken ones) help at all?
[09:18] <soren> Yes, but I really, really recommend removing the one in /usr/local instead.
[09:18] <soren> Otherwise, dpkg updates will not take effect on your system.
[09:19] <soren> ...because most people have /usr/local before /usr in their $PATH.
[09:19] <soren> Wel... /usr/local/bin, and /usr/bin, obviously.
[09:20] <soren> If dpkg is the only piece of software you've compiled and installed yourself, the above mentioned "sudo mv /usr/local /usr/local.oh.dear.I.shouldnt.have.done.that" would actually fix it for you.
[09:23] <dstansby> soren: Thanks for helping me that fixed it. Sorry for my stupidity, but I'm learning all the time. And I am aware of the risks or fiddling with source and dev releases.
[09:24] <soren> *Especially* dpkg. You can really get yourself into trouble messing with dpkg.
[09:26] <dstansby> Now I know :) So am I right in thinking that in moving my version of dpkg to oh.dear. that ubuntu falls back onto the other version that is installed?
[09:27] <soren> Yes.
[09:28] <dstansby> Good, and thanks again for your help
[09:58] <Stupendoussteve> Who is the person to contact to get a build added again when it was previously deleted?
[09:58] <Stupendoussteve> Specifically bug 198724 which was marked as fixed but was not, because the previous version was deleted in Hardy and the fixed version was never built later on
[09:59] <ubottu> Launchpad bug 198724 in partimage "[amd64] partimage not synced" [Undecided,Confirmed] https://launchpad.net/bugs/198724
[10:03] <Hobbsee> that's a bit odd
=== Quintasan_ is now known as Quintasan
[10:05] <maxb> !?!??! How on earth is partimage being built in debian *despite* the fact that it is P-a-s-ed?
[10:05] <Stupendoussteve> What is P-a-s, btw?
[10:06] <Hobbsee> maxb: is it pas'd in ubuntu only, or both?
[10:06] <Hobbsee> Stupendoussteve: package arch specific - it's a list
[10:06] <Stupendoussteve> Ah
[10:06] <Stupendoussteve> Well the old version was
[10:07] <maxb> It still seems to be P-a-s-ed in debian git
[10:08] <Stupendoussteve> The old, deleted version would segfault when you started it, only worked if you used a static 32 bit. 64 support has been present since 0.6.7
[10:08] <Stupendoussteve> 0.6.6 I believe, actually
[10:15] <Stupendoussteve> maxb: As it appears they have no problem with building binaries, is getting P-a-s removed from git something that needs a bug, and would this most likely result in the amd64 version being pulled into Ubuntu?
[10:18] <maxb> Well, the procedure is approximately: (1) Figure out what on earth is going on with the current binaries in debian, (2) file a debian bug requesting P-a-s change, (3) ask cjwatson to pull changes and update ubuntu's, (4) it might then be necessary to ask cprov to run queue-builder if there isn't going to be another ubuntu upload soon
[10:30] <Stupendoussteve> maxb: Where can I see their list of P-a-s packages?
[10:30] <maxb> Well, oftc/#debian-devel can't seem to figure out how partimage/amd64 is present in debian either :-)
[10:31] <Stupendoussteve> lol I see
[10:31] <maxb> Stupendoussteve: https://lists.ubuntu.com/archives/ubuntu-devel/2008-December/027076.html
[10:33] <maxb> ubuntu's version is here
[10:33] <maxb> https://code.launchpad.net/~ubuntu-core-dev/packages-arch-specific/ubuntu
[10:43] <cjwatson> maxb: it's not getting autobuilt in Debian (see https://buildd.debian.org/build.php?arch=&pkg=partimage), so I assume somebody is building it by hand
=== ShadowChild is now known as lukjad007
[10:44]  * cjwatson goes to update Ubuntu's P-a-s while he's thinking about it
[10:52] <cjwatson> (done)
[10:53] <cjwatson> Stupendoussteve: bugs on Debian P-a-s should go on the 'buildd.debian.org' pseudopackage, BTW
[10:53] <joaopinto> kklimonda, ping
[10:54] <Stupendoussteve> I'm double checking with the original reporters to see if they are able to use the one in Debian, then will file one
[11:32] <binarymutant> I would appreciate a revu on http://revu.ubuntuwire.com/p/pidgin-mbpurple if anyone has the time :)
[11:34] <joaopinto> binarymutant, why pidgin-mbpurle an not piding-miicroblogging or something else that matchs the software purpose ?
[11:35] <binarymutant> joaopinto, I wanted to stick with the upstream's name
[11:36] <joaopinto> the tarball name is not upstream name
[11:37] <joaopinto> you have a pidgin-microblog (.exe)
[11:37] <joaopinto> and from "microblog-purple", the microblog word is the most meaninfull, specially if you already have "pidgin" on it
[11:38] <joaopinto> meaningful
[11:38] <joaopinto> IMHO :)
[11:39] <binarymutant> the dev's refer to it as mbpurple though
[11:39] <joaopinto> I alsoo see that there are fedora packages using pidgin-microblog
[11:39] <binarymutant> joaopinto, see http://somsaks.blogspot.com/
[11:39] <joaopinto> binarymutant, package names are not for developers, they are for users :)
[11:40] <binarymutant> joaopinto, right but essentially that is like packaging apache as http-server (or something to that effect), would it not?
[11:42] <binarymutant> who am I to change their name?
[11:42] <joaopinto> ok ok :P
[11:48] <juanje> anyone up to review this? -> http://revu.ubuntuwire.com/p/mount-systray  ;-)
[11:49] <juanje> or/and this -> http://revu.ubuntuwire.com/p/backintime :-P
[11:53] <slytherin> binarymutant: can you please point to the upstream url of this software?
[11:53] <binarymutant> slytherin, http://code.google.com/p/microblog-purple/
[11:55] <slytherin> binarymutant: the upstream tarball is named mbpurple.
[11:56] <slytherin> I gather it is supposed to work with any libpurple based client. If you name it pidgin-mbpurple, it sounds like it will only work with pidgin.
[11:58] <binarymutant> I used the pidgin-* naming scheme as defined by the pidgin policy
[11:59] <slytherin> binarymutant: where is the policy? Does it say you should also rename source package? And as I said what if the software if not pidgin specific but works with all libpurple based clients. Would you still keep pidgin in name?
[12:00] <binarymutant> slytherin, I found it here http://svn.debian.org/wsvn/collab-maint/deb-maint/pidgin/trunk/debian/README.Debian.dev
[12:03] <slytherin> binarymutant: IMHO, this is not a policy. It is just a guideline doc created pidgin package maintainers in Debian. Further, it does not say that you should rename source package. Source package and binary packages can have different names. And my question about if the package only works with pidgin, still stands.
[12:04] <kklimonda> joaopinto: pong
[12:05] <binarymutant> slytherin, what would you name it?
[12:06] <slytherin> binarymutant: I would keep source package name same as upstream and make binary package name as close as possible to the binary (or .so) it creates.
=== asac_ is now known as asac
[12:42] <maxb> slytherin: Hi. On the matter of those non-ascii characters causing the libjaudiotagger-java FTBFS, turns out it's merely a case of the debian/build.xml failing to declare which character encoding the source files use, which is dangerous if they are non-ASCII. (Well, technically dangerous full stop, but it's a rare system which has a default character set which isn't a superset of ASCII)
[12:45] <slytherin> maxb: I will report all our findings when I file a bug in Debian.
[12:58] <geser> slytherin: any idea how we can bootstrap the build of maven-plugin-tools? (it build-depends on itself :( )
[13:01] <slytherin> geser: nope. haven't looked at maven packages in long time. You should perhaps ask Debian maintainer.
[13:01] <geser> ok
[13:07] <geser> slytherin: perhaps I try the same trick as doko did with cup (uuencode the Debian deb and use it on the first "build")
[13:19] <slytherin> geser: that is nice trick. If it works you will probably need to apply it to few more maven packages
[13:23] <VK7HSE> I'm wondering if some kind ubuntu sponsor could please have a look at https://bugs.edge.launchpad.net/ubuntu/+source/me-tv/+bug/379706
[13:23] <ubottu> Launchpad bug 379706 in me-tv "Me TV 0.9.3 into Karmic?" [Undecided,Fix committed]
[13:39] <slytherin> VK7HSE: why is it marked fix commited?
[13:39] <VK7HSE> slytherin: er.. cause I submitted a fix? i can revert if needed..
[13:41] <slytherin> VK7HSE: submitted where? You just attached the diff.gz. What you should do is mark the bug confirmed (because you attached .diff.gz), assign it to nobody.
[13:41] <slytherin> VK7HSE: also mark importance as wishlist.
[13:43] <Hew> vorian, bug 387231
[13:43] <ubottu> Launchpad bug 387231 in revelation "revelation 0.4.11-4ubuntu1 FTBFS" [Medium,Confirmed] https://launchpad.net/bugs/387231
[13:44]  * vorian tries again
[13:44] <Hew> thanks :-)
[13:45] <VK7HSE> slytherin: Ok.. have made changes, unable to set to wishlist it won't allow me ???
[13:45] <slytherin> VK7HSE: I will do that for you.
[13:46] <VK7HSE> slytherin: Thanks...
[13:51] <vorian> hew
[13:51] <vorian> I get the same fail on both i386 and amd64
[13:52] <Hew> vorian, it works for me locally and works in my PPA..
[13:53] <vorian> http://paste.ubuntu.com/198516/
[13:53] <Hew> thanks
[13:56] <Hew> vorian, I'm not sure what's going on there, it looks like a problem with pbuilder dependencies? It doesn't look like the same problem that fails to apply the patch. I used debuild on the source and it was fine. Again, it's fine in the PPA. Any ideas?
[13:57] <ttx> geser: for the xmlbeans package (which also depended on itself) I uploaded it to multiverse (and kept using the oldxmlbean.jar bundled in source)... then fixed it to build-depend on itself... then promoted it to universe.
[13:59] <ttx> Not sure that would work for maven-plugin-tools though, since it's more than just a jar, I presume
[13:59] <Hew> vorian, I'm not familiar with pbuilder. Is it possible it's a problem with pbuilder itself, rather than the sourcepackage/debdiff?
[13:59] <geser> as I'm stuck at another build-dependency from that packages I seem to move it to the future :(
[13:59] <ttx> geser: welcome to hell :)
[14:00] <geser> the hell are the arch:all uploads in Debian :(
[14:09] <Ampelbein> hew, vorian: revelation FTBFS because it depends on python-gdl, which in reverse depends on libgdl-1-0. when you look at https://edge.launchpad.net/ubuntu/+source/gdl/ you see that the soname and thus package name has changed in gdl, so python-gdl (meaning the source package, gnome-python-extras) has to be rebuilt against the new gdl.
[14:20] <Hew> Ampelbein, thanks for your help. So, this is a problem with gnome-python-extras, and not with the revelation itself?
[14:21] <Ampelbein> Hew: from what i can tell: yes. gnome-python-extras does not build with the new gdl.
=== dholbach_ is now known as dholbach
=== ripps_ is now known as ripps
=== jcfp is now known as Guest12357
=== Guest12357 is now known as jcfp
=== Nafallo_ is now known as Nafallo
[15:15] <bddebian> Heya gang
[15:16] <NCommander> hey bddebian
=== ssweeny_ is now known as ssweeny
[15:16] <bddebian> Hi NCommander
[15:16] <NCommander> bddebian, how goes it?
[15:17] <bddebian> NCommander: Same old shite, you?
[15:17] <NCommander> bddebian, I learned a painful lesson in data backup and recovery
[15:17] <bddebian> Doh :(
[15:17] <NCommander> Well, the irreplacables are safe
[15:18] <NCommander> But its still a PITA rebuilding everything else
=== freeflyi1g is now known as freeflying
[15:39]  * mok0 is puzzled: if we are still in auto-sync mode what are all those sync request s doing on the sponsor queue?
=== yofel_ is now known as yofel
[15:41] <soren> mok0: If Ubuntu specific patches can be dropped...
[15:41] <mok0> soren: yeah but some of them are pure sync requests
[15:42] <soren> mok0: Well, people are nuts.
[15:42] <mok0> soren: I guess
[15:43] <Laney> mok0: kill them please
[15:43] <Laney> the queue is big enough as it is
[15:43] <mok0> Laney: I will
[15:48] <mok0> Laney: Queue is shorter now :-)
[15:49] <Laney> mok0: good work \o
[15:50] <mok0> Laney: of course we still have all those bogus entries at the top that we can't do anything about
[15:50] <Laney> pfft, who cares about those main jokers?
[15:52] <mok0> Laney: we ought to have an online session one day where we work in common to clean out that queue
[15:52] <Laney> I think we could do with a few weekly "sponsorship days"
[15:52] <Laney> much like revu days
[15:52] <mok0> Laney: Indeed!
[15:53] <mok0> Laney: it would be nice to discuss some of the entries, and what to do about them
[15:56] <mok0> Laney: we can unsubscribe from the bugs "In Progress"
[15:57] <Laney> mok0: Sometimes people forget to change the status though
[15:58] <mok0> Laney: what about bug 319327 ?
[15:58] <ubottu> Launchpad bug 319327 in guifications "Update pidgin_guifications to 2.16" [Wishlist,In progress] https://launchpad.net/bugs/319327
[15:58] <Laney> there's a diff there
[15:59] <Laney> but he did change the status after he uploaded it, so a ping could be good
[15:59] <vorian> some people don't know to 1) set bug to confirmed and 2) unassign themselves
[15:59] <mok0> Laney: You're right
[15:59] <vorian> actually, a lot of people
[15:59] <al-maisan> Hello there, can somebody explain what the '-s' arg for dh_shlibdeps does? It's not explained in the man page..
[15:59] <mok0> Laney: I'll ping him
[16:00] <mok0> al-maisan: It restricts the action to arch -dep packages, look at man debhelper
[16:00] <Laney> I notice this bug was set to "In Progress" after the patch was attached. Are you ready for it to be reviewed for spnosorship? Please set the bug to 'Confirmed' or 'Triaged' if so.
[16:00] <al-maisan> mok0: thanks, will do.
[16:00] <Laney> something like that
[16:02] <mok0> Laney: oh, didn't see your sentence before the fact
[16:02] <Laney> no worries
=== proppy1 is now known as proppy
=== azeem_ is now known as azeem
[16:48] <dholbach> can somebody from motu-sru have a look at  https://bugs.edge.launchpad.net/netbook-remix-launcher/+bug/358641 ?
[16:48] <ubottu> Launchpad bug 358641 in netbook-launcher "Incorrect Translation in Spanish Network (ENG)->Red (SPA) ¿?-> Rojo (red colour)" [Undecided,Confirmed]
=== YDdraigGoch is now known as WelshDragon
=== WelshDragon is now known as YDdraigGoch
[17:16] <bin1010> howdy all, not sure which ubuntu IRC this should go on...
[17:16] <bin1010> I have a package dependency problem....Luckily they are development libraries, so not so bad.  Apparrently when I installed kompozer-dev and later mozilla-dev I have libnss3-dev: Depends: libnspr4-dev but it is not installed, xulrunner-1.9-dev: Depends: libnspr4-dev but it is not installed....If I run apt-get -f install, it tries to install that package, but fails with dpkg: error processing /var/cache/apt/archives/libnspr4-dev_4.7.3-0u
[17:23] <bin1010> k. tried sudo aptitude -f remove and sudo dpkg --configure -a and they don't seem to work either
[17:42] <kb9vqf> Hey, would anyone be up for reviewing a few packages early? :)
[18:21] <kb9vqf> Hey, would anyone be up for reviewing a few packages "early"? :)
[18:21] <kb9vqf> It's for a rather old bug: https://bugs.launchpad.net/ubuntu/+bug/27463
[18:21] <ubottu> Launchpad bug 27463 in ubuntu "[needs-packaging] Fedora Directory Server for Ubuntu" [Wishlist,In progress]
[18:22] <kb9vqf> The packages are: adminutil, fedora-directory-server, idm-console-framework, jss, ldapjdk, libapache2-mod-nss, libmozilla-ldap-perl, mozilla-ldap-sdk, and svrcore
=== dyfet_ is now known as dyfet
[19:52] <RainCT> can someone from backports please "won't fix" bug #286337 again?
[19:52] <ubottu> Launchpad bug 286337 in hardy-backports "Please backport OpenSSH 5.1 to Hardy" [Wishlist,New] https://launchpad.net/bugs/286337
[19:53] <siretart`> RainCT: that would probably end in status ping-pong. please add a fitting comment first
[19:54] <RainCT> siretart`: I'm on it
[19:58]  * RainCT wonders why there are that many guys doing security audits who don't even know that distributions have something called "security updates" :P
[19:58] <ScottK> RainCT: Check my comment first.
[19:58]  * kees wonders the same thing
[19:58] <ScottK> kees: It's pretty standard idiocy though.
[19:58] <RainCT> ScottK: hah! nice comment :)
[19:59] <kees> yeah
=== rmcbride_ is now known as rmcbride
=== DrKranz is now known as DktrKranz
[20:11] <ximion> Could someone (who has the time ;-)) please look at my Smile-package on REVU? ( http://revu.ubuntuwire.com/p/smile ) I's waiting there for ca. 5 moths and the last two months I only updated to new upstream releases without changig the package code.
[20:14] <RainCT> ximion: Have you seen the Warning smile gives you (about the GPL)?
[20:15] <RainCT> err, s/smile/REVU/
[20:16] <ximion> Yes, I have. The whole project is licensed under GPL, but no license file is included in the original source.
[20:17] <ximion> Every code file of the smile project has a valid header, containing a link to the GPLv2.
[20:18] <ximion> So, I think there's no licensing problem.
[20:18] <ScottK> ximion: You absolutely MUST include a full copy of the license.
[20:19] <ximion> Is it okay if I include a copy of the GPLv2 in the debian directory?
[20:19] <ximion> Or must I modify the original source.tar.gz file?
[20:19] <ScottK> ximion: No.  You need to ask upstream to add it to their tarball (perferred) or alternately repack the orig.tar.gz yourself and document what you did.
[20:21] <ximion> Do I need to use the get-orig-source rule, or can I simply include a copy directly to the orig.tar.gz? (I'll write an e-mail to the author, asking for adding the GPLv2)
[20:25] <ScottK> Since it should be a one time thing, I think as long as you document what you did and why (IIRC debian/copyright is the place to do it, but it's been a while since I needed to know that) doing it manually should be fine.
[20:35] <RainCT> ximion: btw, I've given the package a quick review; see my comment on REVU
[20:36] <RainCT> ScottK: you've got an answer on bug #286337 :)
[20:36] <ubottu> Launchpad bug 286337 in hardy-backports "Please backport OpenSSH 5.1 to Hardy" [Wishlist,Won't fix] https://launchpad.net/bugs/286337
[20:39] <ScottK> RainCT: I've subscribed to the bug now, so I should get any more responses in my inbox.  Thanks.
[20:41] <ximion> @RainCT: The license is now upstream, so the problem doesn't exists anymore!
[20:48] <kb9vqf> Would anyone care to give Fedora Directory Server a quick review?
[20:49] <kb9vqf> The packages are: adminutil, fedora-directory-server, idm-console-framework, jss, ldapjdk, libapache2-mod-nss, libmozilla-ldap-perl, mozilla-ldap-sdk, and svrcore
[20:49] <kb9vqf> :)
[20:50] <ajmitch> it's not something that could ever be given a "quick review"
[20:51] <kb9vqf> OK, sorry about that.  I am still new to this whole process, and just know that FDS has been requested for quite some time.
[20:51] <kb9vqf> So there's probably not much hope of getting it into Karmic then?
[20:51] <ajmitch> it's ok, it's just too big to be given a 5-minute lookever :)
[20:51] <ajmitch> no there's still hope if there's someone with enough time
[20:52] <ajmitch> & if you have time to fix up any problems that come up
[20:52] <kb9vqf> Yeah, I should have the time to fix them--I just need to know what they are first ;-)
[20:52] <ajmitch> first things are getting versioning right, at a glance
[20:52] <ajmitch> packages new to ubuntu generally get a -0ubuntu1 debian version
[20:53] <kb9vqf> OK
[20:54] <kb9vqf> Anything else glaringly wrong?
[20:55] <ajmitch> not that I can look into in a 30 second glace before I run to work :)
[20:56] <ajmitch> especially when there's a mix of java & perl, each with their own packaging policies
[20:57] <kb9vqf> OK :) I'll fix that and reupload by tonight; maybe then someone will have time to look a bit deeper.  Thanks!
[20:57] <ajmitch> things like +Depends: ${misc:Depends}, ${shlibs:Depends}, libnss3-1d, libsvrcore0, libmozldap-0d, libsnmp15, libicu38, libdb4.6, libdirsrv0 (= ${binary:Version}), adduser, libmozilla-ldap-perl
[20:57] <ajmitch> all those should be picked up by ${shlibs:Depends}
[20:58] <ajmitch> not all, but at least the lib*
[20:58] <kb9vqf> OK, and I'll run that change through a build/install just to be sure all the dependecies still work
[21:00] <ajmitch> was this getting put into debian?
[21:04] <kb9vqf> ajmitch: I'm not a Deian developer, unfortunately
[21:04] <kb9vqf> Debian
[21:04] <kb9vqf> It would take some time before I could do that
[21:05] <ajmitch> no, but I saw mention of someone else's name throughout a lot of that, who I wondered if you were working with
[21:06] <ScottK> ajmitch: kb9vqf's perspective on what's easy is probably warped by the fact that he repackaged all of KDE3 for Jaunty.  After that it's all easy.
[21:06] <kb9vqf> I took his initial (and apparently abandoned) packaging efforts, and fixed them up quite a bit to even get them to compile, as well as adding new packages for the missing Mozilla libs
[21:06] <kb9vqf> ScottK: :-)
[21:07]  * kb9vqf wonders what "easy" is...
[21:07] <ajmitch> dh 7 debian/rules
[21:10]  * ajmitch also had an (outdated now) set of FDS packages that were missing a reasonable amouunt of the useful stuff
[21:11] <kb9vqf> ajmitch: Those were probably the old alien-converted RPMs, right?
[21:11] <ajmitch> of course not
[21:11] <kb9vqf> ??
[21:11] <ajmitch> these were packages I was working on
[21:11] <kb9vqf> Ahh...sorry about that...
[21:12] <kb9vqf> The only thing I saw was the converted RPMs and the Debian attempt I worked off of
[21:12] <kb9vqf> things
[21:12]  * ajmitch had stopped with them after the need for trying out FDS at work sort of disappeared
[21:12] <kb9vqf> I always thought FDS and Samba 4 would be a powerful system
[21:13] <kb9vqf> Hence my interest ;-)
[21:13] <ajmitch> yeah, I'd hoped to have the same
[21:13] <ajmitch> though openldap picked up a number of the features which made FDS attractive at the time
[21:14] <kb9vqf> The biggest one is multi-master support, though I can't remember if openldap now has that feature as well
[21:14] <ajmitch> I believe it does
[21:14] <ajmitch> been awhile now, I'd have to check :)
[21:15] <kb9vqf> The other is that the FDS GUI is quite nice for everyday use ;-)
[21:15] <ajmitch> assuming you like GUIs, sure :)
[21:16] <ajmitch> when I was working on the packaging of it, only the core parts had been cut out & converted to an FHS-compliant layout
[21:16] <ajmitch> so that's what I was focusing on
[21:17] <kb9vqf> BTW it looks like they added multimaster to openldap in 2008 or so, but it is still a bit buggy
[21:18] <ajmitch> given my background with FDS packages, I probably ought to try & review what you've done when I find time
[21:18] <kb9vqf> Sure, that'd be great!
[21:18] <kb9vqf> You could poke me when you do have time...
[21:18] <ajmitch> I'll try & find time for it in the weekend, must run off to work now
[21:18] <kb9vqf> OK; thanks for the help so far!
[21:32] <pingswept> I've written a Python library that I'd like to make easily installable on (at least) Ubuntu, but I'm confused by the different options for Python packaging.
[21:32] <pingswept> Do I want a deb? Or an egg? or is setuptools falling out of favor?
[21:33] <pingswept> Or am I asking in the wrong place?
[21:34] <ScottK> pingswept: For Ubuntu you want a debian package.
[21:36] <pingswept> ScottK: Thanks. I'll ask Google for the details.
=== sdh is now known as the-old-sdh
[21:43] <ajmitch> kb9vqf: quick question, where did you find the initial packaging you started from?
=== nxvl_ is now known as nxvl
=== ivoks_ is now known as ivoks
[22:13] <Laney> geser: you here?
[22:14] <Laney> geser: I think the lp api wrapper has broken requestsync(!)
[22:14] <Laney> http://paste2.org/p/271612
[22:15] <geser> Laney: yes, I'm here and already encountered this problem today myself
[22:15] <geser> give me a minute to commit my changes
[22:16] <Laney> cool
[22:20] <geser> Laney: with the two changes I just pushed to trunk you should be able to use requestsync again (at least I was)
[22:20] <Laney> geser: let me try
[22:21] <ScottK> You didn't take away the submit by email option did you?
[22:22] <Laney> bug 389215
[22:22] <ubottu> Launchpad bug 389215 in avahi-sharp "Sync avahi-sharp 0.6.19-4 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/389215
[22:22] <soren> ScottK: Why do you prefer e-mail over lp's api?
[22:22] <Laney> ScottK: No, that's still there and is still the default
[22:22] <Laney> geser: works, thanks
[22:22] <soren> ScottK: I'm just curious.
[22:22] <ScottK> soren: It just works and isn't tied to how fast or slow LP is that day.
[22:22] <ScottK> Laney: Great.
[22:22] <soren> ScottK: "just works" is a bit of an exaggeration, IMO.
[22:23] <soren> ScottK: It depends on a working MTA, doesn't it?
[22:23] <ScottK> soren: In my experience it's been pretty good.
[22:23] <Laney> what do you think to making LP the default?
[22:23] <ScottK> soren: I generally have one of those, so that's not a problem for me.
[22:23] <soren> ScottK: When it comes to working MTA's, you're hardly the average user :)
[22:23] <geser> ScottK: it was just an small error in the LP API code path that I introduced in my recent commits
[22:23] <ScottK> The LP one may be better for most people, but for me I like the email version.
[22:24] <ScottK> soren: certainly.
[22:25] <Laney> we should probably resolve that manage-credentials bug before switching the default
[22:33] <jacob> gtksourcecompletion has a bunch of outdated copyright headers in source, but they are all of the LGPL [version] *or later* type. the overall project is LGPL3+. I've filed an upstream task, but in the event that this doesn't get fixed, is this technically still packagable?
[22:33] <jacob> here's licensecheck and the bug for context: http://is.gd/15CvI
[23:08] <kb9vqf> ajmitch: http://wiki.debian.org/Teams/DebianFDSPackaging
[23:09] <kb9vqf> ajmitch: There's not much there to go on, and quite a few items didn't work ( the FDS startup scripts, admin console, etc.)
[23:09] <kb9vqf> But it was a good start ;-)
[23:10] <ajmitch> right, because I saw that the previous packager that you said was inactive was posting on the listrrecently
[23:18] <kb9vqf> ajmitch: Well, maybe I was wrong...I just hadn't seen much progress when I pulled the packaging a couple of months ago.  I can be quite impatient at times! :-)
[23:20] <directhex> pfft. men! too impulsive
[23:21]  * kb9vqf forgot to mention the dead giveaway of inactivity...the version numbers on that Wiki page
[23:21] <kb9vqf> We're on 1.2.0 now! :)
[23:22] <ajmitch> because there's a big rename in progress
[23:22] <ajmitch> it's no longer fedora directory server
[23:22] <kb9vqf> Yeah, but it hasn't reached a release yet
[23:22] <kb9vqf> That is, the current release branding is still 1.2.0
[23:22] <kb9vqf> That is, the current release branding is still FDS
[23:22] <ajmitch> so it's probably better not to get packages in which will need a major renaming just yet
[23:23] <ajmitch> depends on how long it takes them to rename
[23:24] <kb9vqf> Ahh...what if I changed the naming to 389-directory-server in the packaging, even though the program branding is still FDS?  Would that suffice or maybe it's just too unstable for inclusion?
[23:25] <ajmitch> suggestion there is to coordinate on the debian mailing list & work in SVN there
[23:26] <kb9vqf> Well, maybe I'll leave it in the PPA for now; the Debian approval process looks very lengthy and I probably won't be able to help for a while.
[23:26] <kb9vqf> That is, Debian developer approval
[23:27] <kb9vqf> Should I just leave the packages on REVU or should I delete them?
[23:28] <directhex> the problem being you need re-approval when things get renamed
[23:30] <kb9vqf> I would try renaming everything now, at 1.2.0, but I don't know if that's a big no-no
[23:30] <ajmitch> you don't need to be a debian developer to work on them in debian
[23:31] <kb9vqf> I thought SVN access was restricted to Debian developers, no?
[23:31] <ajmitch> no
[23:31] <kb9vqf> Ahh
[23:31]  * kb9vqf looks over at Debian policies again
[23:31] <ajmitch> it's restricted to team members for the project, and you can join the team on alioth.debian.org
[23:32] <ajmitch> this is separate from usual debian policies, though it's a service provided by them
[23:32] <kb9vqf> that explains it
[23:33] <kb9vqf> I guess I'll create the upstream (Debian) bug report again as well
[23:33] <kb9vqf> Thanks for the education!
[23:34] <mrooney> anyone willing to mentor me on creating a ppa of a nautilus branch? I've got the branch running on my machine, I'm just not sure how to combine that branch with the current nautilus packaging
[23:34] <ajmitch> kb9vqf: reopen it
[23:34] <ajmitch> if there's not an ITP bug open
[23:35] <kb9vqf> all those bugs expired--I'll see if I have permissions to re-open or not
[23:35] <ajmitch> anyone does
[23:35] <kb9vqf> good
[23:35]  * kb9vqf is completely unfamiliar with Debian's policies, etc.
[23:39] <ajmitch> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386206 is that one I found
[23:39] <ubottu> Debian bug 386206 in wnpp "ITP: fedora-directory-server -- An LDAP server designed to manage large" [Wishlist,Closed]