[00:20] <emgent> http://www.antsonthemelon.com/gallery/albums/misc/sudo.jpg
[00:20] <emgent> haahah
[00:22] <Flannel> emgent: Surely you mean: http://xkcd.com/149/
[00:22] <emgent> yea :)
[00:30] <pochu> TheMuso: nevermind, rainct already acked and uploaded it (I had acked it too)
[01:07] <Legendario> hello everyone!
[01:08] <Legendario> my flashplugin was working fine, but i guess it was updated today through update-manager and now it's not working anymore. Anyone else with the same problem?
[01:09] <RAOF> (1) This isn't a support channel (you want either #ubuntu or #ubuntu+1 if you're running Hardy) and (2) you haven't yet provided enough information to make any useful diagnosis :)
[01:11] <slangasek> it's likely enough, however, that this is bug #173890
[01:11] <ubotu> Launchpad bug 173890 in flashplugin-nonfree "flashplugin-nonfree fails to install... new version?" [High,Confirmed] https://launchpad.net/bugs/173890
[01:11] <Legendario> RAOF, i thought i could ask it here because the package is in the universe. sorry
[01:12] <Legendario> thanks, slangasek
[01:12] <RAOF> Legendario: That's OK.  But almost all Ubuntu packages are in universe, so... :)
[01:12] <RAOF> I thought there was a recent upload that fixed that bug (I don't notice, I'm using gnash)
[01:13] <slangasek> "recent" as in "this morning", I think
[01:13] <slangasek> so there'll still be echoes of the breakage since not everyone's mirror updates at the same time
[01:14] <RAOF> Does that mean that we found a way to update it while not breaking !firefox browsers?  Cool.
[01:14] <slangasek> oh, I have no idea on that
[01:14] <Legendario> slangasek, but this upload had the problem. Mine was working fine before, and it's not anymore...
[01:14] <slangasek> Legendario: what version do you have?
[01:15] <Legendario> slangasek, 9.0.48.0.2+really0ubuntu12
[01:17] <slangasek> well, that's not either of the updated versions; that's the old version from October
[01:17] <slangasek> the newest is 9.0.48.0.2+really0ubuntu12.2
[01:18] <Legendario> the interesting is that my version was installed this morning... :-(
[01:20] <protonchris> Legendario: It just happened to me.  The work around listed on launchpad did the trick.
[01:22] <Legendario> protonchris, is there a way to fix it? Manual download it?
[01:24] <protonchris> Legendario: https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/173890/comments/202
[01:24] <ubotu> Launchpad bug 173890 in flashplugin-nonfree "flashplugin-nonfree fails to install... new version?" [High,Confirmed]
[01:27] <protonchris> Legendario: Actually, I updated my sources to the main server and I upgraded to the new 12.2 version that works.  Looks like the mirror I was using was out of date.
[01:29] <Legendario> protonchris, thanks for the hint
[01:30] <protonchris> Legendario: no problem
[01:41] <bddebian> Heya gang
[01:42] <RAOF> Howdie bddebian.
[01:42] <RAOF> linux-nouveau-modules-2.6.24-5-generic
[01:42] <RAOF> xserver-xorg-video-nouveau
[01:42] <RAOF> linux-nouveau-modules-2.6.24-5-generic
[01:42] <RAOF> xserver-xorg-video-nouveau
[01:42] <bddebian> Hi RAOF
[01:42] <RAOF> Ehem.
[01:46] <rjmyst3> superm1: any news on why wxformbuilder was rejected?
[01:48] <Legendario> does anyone here know the Wuala? www.wua.la
[01:52] <Legendario> i have 5 invitation codes to be sent. Anyone interested?
[01:53] <rjmyst3> my package was sponsored into the archive, but has since been moved to the Rejected queue.
[01:53] <rjmyst3> https://launchpad.net/ubuntu/hardy/+queue?queue_state=4&queue_text=wxformbuilder
[01:53] <rjmyst3> can anyone tell me how to find out why?
[01:53] <RAOF> rjmyst3: I know that superm1 has been asking the archive admins, but hadn't yet tracked down the one who rejected it.
[01:54] <rjmyst3> RAOF: thank you, superm1 had told me that he would look into it, but with the feature freeze approaching, i'm getting nervous
[01:56] <rjmyst3> is there anything I can do while I wait to find out?
[01:58] <RAOF> Um... not that I can think of, no.
[01:58] <rjmyst3> ok, thanks
[02:11] <superm1> rjmyst3, its a licensing thing
[02:11] <superm1> i emailed you
[02:11] <superm1> after i found out
[02:13] <superm1> rjmyst3, you didn't include a copy of the license in the root of the orig.tar.gz
[02:13] <superm1> and several source files are missing licenses
[02:15] <superm1> rjmyst3, https://lists.ubuntu.com/archives/ubuntu-archive/2008-February/015359.html
[02:16] <superm1> er maybe that was still in the queue to be headed out, oops :)
[02:16] <superm1> but that was it ^
[02:20] <q_a_z_steve> ok, so I tried to jump from dapper to alpha 4... X is obviously out of the question for now. My question, then is: How do I get dpkg --configure -a to run successfully to fix that which definitely didn't install correctly prior to my reboot (which was necessary due to power issues in my area)
[02:20] <q_a_z_steve> What can I tell you about what I see, in order for some help ?
[02:24] <rjmyst3> superm1: ok, i'll fix it, thanks
[02:24] <superm1> rjmyst3, okay thanks.  let me know when its fixed and i'll be able to ack it for you
[02:49] <protonchris> Is this really a bug since postgres 8.2 is in hardy: https://bugs.launchpad.net/ubuntu/+source/glom/+bug/188939
[02:49] <ubotu> Launchpad bug 188939 in glom "Glom should depend on postgresql-8.3" [Undecided,New]
[02:51] <leonel> protonchris: postgresql 8.3  is already in hardy
[02:53] <protonchris> Yeah, I know.  So what you are saying is that the glom package should use 8.3 even though 8.2 is available as well?
[02:54]  * protonchris is a packaging newb
[02:56] <leonel> protonchris: well postgresql 8.2  have been moved to universe  and 8.3 is in main  ..
[02:56] <protonchris> Ah.  Thanks for the info.
[03:21] <rhpot1991_laptop> Can someone re-sync the REVU uploaders keyring?
[05:10] <ScottK> protonchris: Having it depend on postgres 8.3 | postgres 8.2 would make sense then.
[05:10] <ScottK> That way people can choose.
[05:11] <joejaxx> anyone have an example of an autogen package that does NOT use that cdbs nonsense? :P
[05:21] <LucidFox> joejaxx> CDBS is not nonsense
[05:22] <joejaxx> LucidFox: :P
[05:22] <LucidFox> By an autogen package, you mean a package that runs autotools first besides just running ./configure?
[05:23] <joejaxx> yeah or there is a ./autogen.sh script
[05:23] <joejaxx> s/a/an/g
[05:23] <LucidFox> hmm, let me see
[05:24] <joejaxx> i am trying to package audit
[05:24] <joejaxx> :)
[05:24] <joejaxx> and some other packages
[05:24] <ScottK> LucidFox: It may not be nonsense, but it is black magic.
[05:24] <LucidFox> heh
[05:24] <RAOF> joejaxx: They're just like regular debhelper packages, but you call autogen rather than configure (generally).
[05:25] <joejaxx> ah bah wth
[05:25] <joejaxx> it is in debian already
[05:25] <LucidFox> heh
[05:25] <joejaxx> :( fail :(
[05:25] <joejaxx> :P
[05:25] <LucidFox> anyway, per RAOF :)
[05:25] <RAOF> Also, I was under the impression that re-autotooling during package build was frowned upon as a Bad Thing.
[05:25] <joejaxx> oh well i can still apply those policycoreutils gui patches
[05:25] <joejaxx> RAOF: oh ok
[05:26] <joejaxx> RAOF: no i just wanted an example as dpkg-buildpackage kept stopping
[05:26] <LucidFox> As for CDBS, I used to hate it and avoid it like plague. Now I use it whenever I can - and I usually can't only for _really_ screwed up upstream build systems
[05:26] <joejaxx> oh wow the version in debian is super old
[05:26] <joejaxx> :\
[05:26] <joejaxx> even in unstable
[05:27] <joejaxx> LucidFox: oh ok
[05:27] <RAOF> LucidFox: Whereas I went the other way; I used to preferentially use CDBS.  Until I started to do non-trivial things, at which point I was just fighting the undocumented magic.
[05:27] <LucidFox> joejaxx> Can't you take the Debian package as a basis and just update it to a new upstream version?
[05:27] <LucidFox> RAOF> heh
[05:28] <joejaxx> LucidFox: maybe
[05:28] <RAOF> At least debhelper is *documented* magic :)
[05:28] <joejaxx> RAOF: :D
[05:28]  * joejaxx does not like blacboxes
[05:28] <joejaxx> blackboxes*
[05:29] <LucidFox> For example, I had to switch from CDBS to debhelper for kde4-style-qtcurve, because I couldn't find any way to do double builds in CDBS
[05:30] <RAOF> It's probably possible, but why fight your tools?
[05:30] <LucidFox> (although the original CDBS packaging wasn't mine)
[05:30] <LucidFox> RAOF> Exactly.
[05:30] <ScottK> joejaxx: If it's in Debian, please don't redo the packaging.  Minimize the diff with Debian.
[05:32] <joejaxx> ScottK: redo the packaging?
[05:33] <joejaxx>  /win 64
[05:33] <joejaxx> bah
[05:33] <ScottK> joejaxx: I may have misunderstood, but I thought you were considering packaging a newer version of something in Debian without using the package in Debian as a basis.
[05:33] <RAOF> That's an unhealthy number of irc windows :)
[05:33] <joejaxx> ScottK: i just found out it was in debian :P
[05:34] <joejaxx> ScottK: it was not there last time i looked at packaging it
[05:34] <ScottK> I see.
[05:34] <joejaxx> albeit might have been a while
[05:34] <joejaxx> lol
[05:34] <ScottK> Good night.  I'm off to bed.
[05:34] <joejaxx> Goodnight
[05:36] <joejaxx> RAOF: lol
[05:36] <joejaxx> how does this work if i want to package a newer version?
[05:37] <joejaxx> and it is not in the archive
[05:38] <joejaxx> well actually
[05:38] <joejaxx> hmm
[05:38] <joejaxx> oh well
[05:38] <joejaxx> lo
[05:39] <joejaxx> l
[05:39] <LucidFox> joejaxx> I think it can be managed like a regular upstream update, except if you're submitting an interdiff, use the last Debian version as the basis instead of the last Ubuntu version. I may be wrong, though.
[05:40] <LucidFox> Or it may be better to sync the current Debian version first, and then update.
[05:40] <joejaxx> i do not know if i want audit in the archive yet :\
[05:40] <joejaxx> the selinux stuff has not made it in yet
[05:41] <LucidFox> joejaxx> So the package in question is audit?
[05:41] <joejaxx> i was actually only going to upload this to a ppa since this is my first time packaging python software, revu has passed :P and there are hardly any days left
[05:41] <LucidFox> audit is already in the archive: https://launchpad.net/ubuntu/+source/audit
[05:42] <joejaxx> until feature freeze
[05:42] <joejaxx> oh
[05:42] <joejaxx> is there anyway to find out who requested that?
[05:42] <mkoehler> Evening - I'm trying to learn the packaging process, and I'm running into trouble with the hello package.  When I get to the point of running pbuilder, it ends up giving the following error "gzip: debian/tmp/usr/share/man: No such file or directory make: *** [binary-arch] Error 1:dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2"  Can anyone offer any suggestions?
[05:43] <joejaxx> oh no wonder
[05:43] <joejaxx> apparmor :\
[05:43] <LucidFox> joejaxx> look at the uploaders
[05:43]  * joejaxx cringes
[05:43] <LucidFox> the first version was autosynced
[05:43] <LucidFox> Subsequent ones were uploaded by Mathias Gug
[05:43] <joejaxx> lol i wonder if setroubleshoot is in there now
[05:44] <LucidFox> mkoehler> You probably should just move to hello-debhelper; packaging without debhelper is pretty pointless anyway
[05:44] <joejaxx> nope it is not in there
[05:44] <joejaxx> maybe i will package that :\
[05:44] <mkoehler> sure, thanks
[05:44] <rhpot1991_laptop> Can someone re-sync the REVU uploaders keyring?
[05:46]  * LucidFox pings Hobbsee
[05:50] <RAOF> LucidFox: You're going to add some context to that ping, right? :P
[05:51] <LucidFox> If she replies, I'll explain :)
[05:51]  * RAOF finds that sort of ping really annoying.
[05:52] <LucidFox> I see.
[05:52] <RAOF> Because I then go hunting through backscroll to find the context... and it's not there!
[06:12] <mkoehler> Can somebody re-sync the REVU uploaders keyring?
[06:28] <vemon> why are packages kept in the ppa's pool dir even after they been deleted from the launchpad ppa user interface?
[06:28] <q_a_z_steve> http://qaz.pastebin.org/18670
[06:28] <vemon> this apparently keeps me from uploading a new version with the same versino number and/or upstream version
[06:31] <vemon> and if i need to change the version number every time then what would be a good base version to use for packages still in revu?
[07:15] <Hobbsee> You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
[07:15] <Hobbsee> LucidFox: ^
[07:15] <Hobbsee> RAOF: or i can just not reply
[07:15] <superm1> Hobbsee, could you sync the revu keyring (in case you didnt see the above requests)?  There were a few new contributors looking to add some stuff
[07:15] <LucidFox> Hobbsee> mkoehler requests the REVU keyring synced
[07:16] <LucidFox> heh, superm1 beat me to it
[07:16] <Hobbsee> superm1: i did yesterday.  i'll do so again
[07:16] <LucidFox> sorry for the contentless ping
[07:16] <superm1> Hobbsee, new people today :)
[07:16] <Hobbsee> woot :)
[07:17]  * Hobbsee thwacks smarter with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! ™
[07:17]  * Hobbsee thwacks  Albert Santoni too
[07:17] <Hobbsee> superm1: were either of those on your sync list?
[07:18] <superm1> i dont think so :)
[07:18] <superm1> rhpot1991_laptop, was the one who had something i was gonna look at
[07:18] <Hobbsee> good
[07:18] <superm1> what'd they break?
[07:18] <Hobbsee> uploaded binaries to REVU
[07:18] <superm1> bah.  silly people
[07:19] <Hobbsee> the nutter on hte ML earlier uploaded 3 different versions of a package, without realising what was wrong, either
[07:47] <LucidFox> dpkg depends on lzma now? What for? orig.tar.7z?
[07:47] <LucidFox> :)
[07:48] <RAOF> LucidFox: Indeed :)
[07:48] <man-di> LucidFox: for the content in the *.deb
[07:48] <RAOF> Well, rather for packing .debs with lzma so as to reduce size by some tens of percent.
[07:50] <LucidFox> heh
[07:50] <LucidFox> by the way, is orig.tar.bz2 allowed now?
[07:55] <dholbach> good morning
[07:55] <RAOF> Evening dholbach!
[07:56] <dholbach> hey RAOF
[08:00] <Hobbsee> LucidFox: no
[08:01] <HighNo> good morning
[08:01] <LucidFox> :(
[08:13] <HighNo> if someone is feeling bored and has a bluetooth device would he like to check out http://revu.tauware.de/details.py?package=blueproximity for advocating? Formal errors should be almost gone as mok0 has given many advices...
[08:14] <HighNo> (it's cool stuff to have installed anyway ^_^)
[08:16] <warp10> Good morning!
[08:16] <RAOF> Why must copyright be so hard :/
[08:20] <HighNo> RAOF: what you write is yours. that's not too hard :-) [I know what lawyers make of it... )
[08:21] <RAOF> HighNo: Yup, that's easy.  What is less easy is when other people write things, intending for them to be used by others, but have no license headers.
[08:25] <LucidFox> If someone feels like reviewing/advocating a REVU package, I'd recommend http://revu.tauware.de/details.py?package=qdevelop
[08:25] <LucidFox> (not my package)
[08:26] <LucidFox> I like IDEs that are written in the same language/framework they're designed for.
[08:27] <Fujitsu> Except when it's Java.
[08:27] <LucidFox> Even when it's Java.
[08:27] <Fujitsu> Eclipse is slow.
[08:27]  * LucidFox uses Eclipse
[08:27] <LucidFox> Not for me :)
[08:27] <LucidFox> On computers low on memory, yes, it _is_ slow
[08:28] <DarkMageZ> um... when a single application can sit there and eat 250MB of ram...
[08:28] <DarkMageZ> i think it's not the system, it's the app.
[08:28] <RAOF> One of my friends uses Eclipse, and he has occasionally complained that it eats multiple gigabytes of ram in some cases.
[08:28]  * Fujitsu points DarkMageZ at Firefox.
[08:29] <DarkMageZ> bloody azureus...
[08:29] <RAOF> Disclaimer: I don't know what he's actually trying to do with it, or what version.
[08:29] <DarkMageZ> Fujitsu, mozilla team fails at coding.
[08:29] <Fujitsu> Indeed.
[08:30] <DarkMageZ> i mean xul? what on earth were they smoking... probably high quality stuff funded by google. (don't correct my timeline)
[08:31] <LucidFox> Well, XUL was conceived back when GTK was ugly and Qt was proprietary
[08:31] <RAOF> DarkMageZ: Cross platform, performant, native-looking guis described by XML are easy!
[08:31] <DarkMageZ> yeah, but it's like communism. you give it a shot then realise it sucks and move on.
[08:31] <LucidFox> Although I'll probably retire Firefox once midori or epiphany-webkit reaches a usable state
[08:32] <DarkMageZ> or rewrite it from scratch with a superior design :p
[08:33] <RAOF> Firefox wouldn't be so annoying if gecko was an actual library.  With a soname.  In LDPATH.
[08:33] <LucidFox> well, there's libxul
[08:33] <LucidFox> and now Firefox 3 atop xulrunner
[08:33]  * RAOF laughs derisively.
[08:33] <DarkMageZ> this is why webkit it awesome ?
[08:34] <RAOF> So, they satisfy part 1.  They're nearly libraries.
[08:34] <DarkMageZ> is*
[08:34] <LucidFox> Webkit is awesome because it's FAST.
[08:34] <RAOF> And small, and apparently a joy to GTK in.
[08:34] <LucidFox> Indeed.
[08:35] <DarkMageZ> webkit is getting a lot of focus as of late. isn't QT 4.4 integrating it?
[08:35] <RAOF> Oh, really?
[08:35] <LucidFox> Indeed. And Phonon.
[08:36] <LucidFox> _And_ it's going to be GPLv3.
[08:36]  * RAOF still doesn't get phonon.
[08:36] <DarkMageZ> QT's gonna be a development platform of its own at this rate.
[08:36] <LucidFox> DarkMageZ> You mean it already isn't?
[08:37] <LucidFox> RAOF> NIH syndrome, it seems
[08:37] <DarkMageZ> LucidFox, not till it has phonon and a few other things.
[08:38] <DarkMageZ> RAOF, the idea behind phonon is that you won't need to code for multiple audio backends. you code for phonon, phonon calls various audio backends to do its bidding.
[08:38] <RAOF> LucidFox: But then QT went ahead and made sure that GStreamer worked nicely on windows & os:x, so they've got gstreamer->phonon->qt everywhere.
[08:38] <RAOF> DarkMageZ: ^^^.  Or you could use gstreamer everywhere, and not need to care.
[08:39] <DarkMageZ> RAOF, gstreamer is complex to code for directly. having a childsplay to code for toy like phonon is good.
[08:39] <RAOF> Maybe.  From what I've seen, gstreamer is pretty easy to do simple things in.  But it would, of course, need C++ bindings.
[08:40] <LucidFox> The problem with thin wrappers for native subsystems is, they will always have different bugs on different platforms
[08:40] <LucidFox> (look no further than SWT and wxWidgets)
[08:40] <DarkMageZ> very true
[08:41] <RAOF> And, in the case of those, the native widgets will just plain behave differently so you're fighting uphill all the way.
[08:43] <DaveMorris> can someone do a quick check on the questions I have at the bottom of http://revu.tauware.de/details.py?package=gtkglextmm please
[08:43] <LucidFox> gtkglext STILL isn't in the archive? o_O
[08:43] <DaveMorris> no
[08:43] <DaveMorris> it's in dapper
[08:44] <LucidFox> oh, wait, gtkglext _is_ in the archive - gtkglextmm isn't
[08:44] <DaveMorris> I only realised yesterday when I went to install it for my project thats going to be targeting hardy (after dapper)
[08:44] <LucidFox> misread the package name
[08:44] <DaveMorris> oh yeah, this is c++ bindings
[08:46] <DaveMorris> LucidFox: you able to answer my questions on the package regarding the changelog and if I need a bug report for it
[08:57] <LucidFox> DaveMorris> No, I'm afraid I'm in no position to answer these questions
[09:01]  * DaveMorris off to work :)
[09:11] <RAOF> Dear kern.log: stop filling up my /
[09:19] <HighNo> RAOF: hehe, I know what you mean: df -h: /dev/sda5              20G   19G  122M 100% /
[09:23]  * Fujitsu doesn't think his is eating much.
[09:24] <Fujitsu> .... or maybe it is. A few hundred megabytes in 2 days.
[09:26] <Yagisan> my logs go nuts when I put my bluetooth dongle in. It spams the hell out of it.
[09:43] <HighNo> Yagisan: that does not sound healthy
[09:43] <Yagisan> HighNo, it certainly isn't. It's a great way to up the load average
[09:44] <Yagisan> walk over - attach dongle - watch system slow down, and the disk light turn on
[09:45] <HighNo> Yagisan: do you have some lines for me?
[09:45] <Yagisan> one moment - I'll plug it in
[09:46]  * HighNo awaits your ping timeout :-)
[09:47] <HighNo> this seems way off topic for this channel, maybe we should do that in private
[09:47] <Yagisan> HighNo, http://rafb.net/p/tlLPhX50.html
[09:49] <Yagisan> HighNo, you can see how fast it spams
[09:49] <HighNo> Yes
[10:01] <TuxCrafter> hello everybody,
[10:02] <HighNo> btw, is there is list with all MOTUs on there?
[10:02] <TuxCrafter> is there a motu that has the time to package the latest maxima program http://sourceforge.net/project/showfiles.php?group_id=4933 for http://packages.ubuntu.com/hardy/math/
[10:02] <TuxCrafter> HighNo: a list of the moto can be found on the launchpad motu pages
[10:03] <TuxCrafter> s/moto/motu/
[10:03] <HighNo> just to get an idea of how many of you exist... cool Tux
[10:03] <TuxCrafter> HighNo: if you can find the list of active users that update using Apt-get on ubuntu this will be great for me
[10:04] <TuxCrafter> Unique IP logins on the repos
[10:04] <TuxCrafter> the fedora project has a very nice stat page
[10:05] <TuxCrafter> http://fedoraproject.org/wiki/Statistics
[10:05] <luisbg_> how do I make a cdbs created package run a .install I just created for it?
[10:06] <TuxCrafter> fedora has now 1,920,667 computer users
[10:06] <HighNo> yeah, that's very cool. Shouldn't you talk to some canonical guy to get this going?
[10:07] <sladen> TuxCrafter: I think Canoincal enjoy the fact that they have more, alot more, but don't feel the need to show their hand
[10:08] <TuxCrafter> sladen: i would would really appreciate if they share the info
[10:08] <sladen> TuxCrafter: then make the case to them
[10:08] <Aloha> Please review http://revu.tauware.de/details.py?package=sadms :)
[10:08] <TuxCrafter> sladen: jups sorry i went offtopic
[10:09] <TuxCrafter> back to the maxima package, is there a motu that is willing to do a upgrade
[10:10] <TuxCrafter> or should i do a bug report that there is a newer version on launchpad
[10:15] <Fujitsu> TuxCrafter: Ideally, Debian would do the upgrade and we would merge from them.
[10:15] <TuxCrafter> maxima is an very important package for people doing technical education
[10:16] <mok0> TuxCrafter: Maxima is pending a merge. It's free for you to do afaics: http://dad.dunnewind.net/maxima/
[10:17] <Fujitsu> mok0: Isn't the only change in Debian a dash-related NMU?
[10:17] <TuxCrafter> mok0: 5.13 is still to old
[10:17] <TuxCrafter> 5.14 is the new one
[10:17]  * TuxCrafter is compiling them now
[10:17] <mok0> Is it in SId?
[10:17] <Fujitsu> It'd be optimal if you could convince Debian to upgrade it first.
[10:17] <Fujitsu> mok0: It's not.
[10:17] <Fujitsu> Neither is the new gEDA :(
[10:18] <TuxCrafter> gEDA is also very importand
[10:18] <Fujitsu> Yes, I'm talking with one of the upstream devs about that.
[10:18] <TuxCrafter> if i become a motu
[10:18] <Fujitsu> I'm expecting to upload 1.4.0 in the next couple of days if Debian doesn't get to it first.
[10:18] <TuxCrafter> i will do the technical packages
[10:18] <TuxCrafter> geda maxima etc
[10:18] <TuxCrafter> but i am still in training
[10:18] <TuxCrafter> and i have to see were xubuntu and ubuntu is heading to this year
[10:19] <TuxCrafter> else i go to back to fedora
[10:19] <mok0> Yuc
[10:21] <HighNo> did anyone just use the bad word in here? :-)
[10:21] <TuxCrafter> or i will start my very long awaiting ubuntu based distro :-p
[10:22] <mok0> TuxCrafter: Why don't you contact the Debian maintainer of maxima and ask what the plans are. If (s)he is busy, perhaps you can do a NMU
[10:23]  * Yagisan deployed xubuntu and ubuntu into the wild. Still not yet ready to send my pet project back to revu
[10:25] <TuxCrafter> mok0: i sent a mail to the debian maintanner
[10:25] <TuxCrafter> maintainer
[10:25] <mok0> TuxCrafter: and...?
[10:25] <TuxCrafter> mok0: i have to get a mail back first :-p
[10:26] <TuxCrafter> but i just compiled and installed it on my own machine
[10:27] <TuxCrafter> perfect this is more like it
[10:40] <HighNo> do motu's own bluetooth'able machines?
[10:44]  * RAOF does
[10:51] <HighNo> RAOF: now if you are motu then you probably don't have the time to check my package right? http://revu.tauware.de/details.py?package=blueproximity
[10:52] <RAOF> Not right now, no.  I'm off to bed.
[10:52] <HighNo> RAOF: how can you go to bed now? it's not even 12pm :-) [in Germany]
[10:53] <RAOF> Whereas it's 10pm in .au :)
[10:53] <Yagisan> oh another tpg user RAOF ?
[10:54] <Yagisan> night - I may bug you for war stories with tech support later
[10:54] <HighNo> which is also a nice place to live. Can you tell me how you guys manage not to fall of the earth, it's all upside down, isn't it? 8-)
[10:55] <Yagisan> HighNo, I'm not sure, it's not us on the bottom - how do you stay down :P
[10:58] <HighNo> hehe, good point
[11:02] <gnudles> when will you publish amarok KDE4 build?
[11:02] <gnudles> hi :)
[11:12] <HighNo> Did I say good night at RAOF? Think of me tomorrow :-)
[11:33] <DaveMorris> can I have a quick answer to the questions I've raised in my package upload please.  at http://revu.tauware.de/details.py?package=gtkglextmm
[11:37] <shibata> Hi, all.
[12:06] <asabil> hi all
[12:06] <asabil> anyone to review
[12:06] <asabil> http://revu.tauware.de/details.py?package=json-glib
[12:06] <asabil> thanks
[12:33] <mruiz> hi all
[12:33] <mruiz> ping DktrKranz
[12:37] <norsetto> bidibibodibibu
[12:41] <slytherin> persia: Do you think now is the good time to preseed debconf for j2sdk1.4 also?
[12:42] <persia> slytherin: Absolutely no idea.  If there are a number of FTBFS issues due to the lack of preseeding that cannot be solved with other javac implementations, the answer may be yes.
[12:43] <slytherin> persia: one of them which I consider important is batik and its fop which depends on batik for building
[12:44] <DktrKranz> hey mruiz :)
[12:44] <DaveMorris> persia: you able to spare 5 mins to answer my questions on http://revu.tauware.de/details.py?package=gtkglextmm ?
[12:44] <mruiz> DktrKranz, I have uploaded a new revision of mnemosyne :-)
[12:45] <DktrKranz> mruiz, nice! what about upstream?
[12:46] <mruiz> DktrKranz, he didn't notice about issues with python 2.5 :D
[12:47] <DktrKranz> mruiz, if upstream is comfortable with 2.5, you should adjust pyversions accordingly
[12:48] <persia> DaveMorris: My only real issue was that it was removed as being hopelessly buggy.  Have all the RC bugs been addressed?  How is this package useful?
[12:48] <mruiz> DktrKranz, ups... I forget it
[12:49] <DktrKranz> mruiz, I don't remember the right syntax, though. You'll need to browse python policy for that
[12:49]  * mruiz updating pyversions
[12:50] <DaveMorris> persia: do I continue the same changelog and do I need to open a bug for it?
[12:50] <ScottK> mruiz: Are you using pycentral or pysupport?
[12:50] <DaveMorris> re is it useful?  Well if 3rd party developers are only targeting LTS platforms, then they could be in for a shock, when they find it's no longer in the next LTS
[12:50] <dholbach> MOTU Q&A session in #ubuntu-classroom in 10 minutes
[12:54] <persia> DaveMorris: I'd continue the changelog, and open a bug "Please restore the package" to be closed with the changelog.  Also, I strongly advise you examine the bugs that led to removal: if they are still open, we will have the same issue for the next LTS, and it may be better to have the pain now, rather than once Ubuntu adoption is even more widespread.
[12:57] <DaveMorris> ok, still struggling to find the bugs with it which are open
[12:58] <DaveMorris> the RC bug was a FTBFS on the 1.0 version
[12:58] <persia> DaveMorris: http://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=1;version=;dist=unstable;package=gtkglextmm;repeatmerged=1 is likely the appropriate place to start.  These bugs look closed, but may well have been closed by the package removal.
[13:00] <DaveMorris> yeah, I can only find FTBS and missing dependencies (and wishlists to upgrade to 1.2 )
[13:02] <persia> Those would all be RC, and would have to be fixed to get through REVU.  Sounds fine to me: you might want to leave a comment indicating that you've addressed all the outstanding Debian & Ubuntu bugs you could find with the package update.
[13:02] <DaveMorris> yeah thanks
[13:02] <DaveMorris> btw, how come it appears as a new package rather than an update.  Is it because it's not currently in Hardy
[13:03] <persia> DaveMorris: It is also absent from feisty and gutsy, but yes.
[13:11] <DaveMorris> can you set a bug to depend on another bug been fixed in LP?
[13:16] <persia> DaveMorris: Nope.
[13:17] <DaveMorris> hmmm, shame
[13:19] <persia> DaveMorris: There was a recent thread about this somewhere (ubuntu-bugs@ ubuntu-motu@?  Ask google) in which the difficulty in understanding the meaning of such a dependency for a wide number of use cases was discussed.
[13:20] <DaveMorris> I'll dig out the threads, thanks
[13:39] <proppy> oy
[13:47] <RainCT> Hey
[13:48] <jdong> hi
[14:02] <mruiz> DktrKranz, please review the new upload of mnemosyne :-)
[14:02] <DktrKranz> mruiz, sure
[14:02] <mruiz> DktrKranz, thanks
[14:10] <DktrKranz> mruiz, erm... I fear I'll have a look at it later, sorry :(
[14:10] <mruiz> DktrKranz, no worries :) The package will be waiting for you
[14:11] <dcordero> hi
[14:11] <DktrKranz> mruiz, thanks for your patience :)
[14:11]  * mruiz hugs DktrKranz 
[14:12] <DktrKranz> hola dcordero :)
[14:12] <dcordero> hi DktrKranz  :)
[14:13] <DktrKranz> dcordero, will you be there in a hour? I'd like to work at 187356, it's quite close to be solved :)
[14:14] <dcordero> yep, i'll be there, i have some question
[14:14] <DktrKranz> fire them
[14:15] <dcordero> it's on the bug comments :) I have 2 problems with this bug
[14:16] <dcordero> and another thing, can i run a package with X from a debootstrap chroot ?
[14:16] <DktrKranz> IIRC, outdated-autotools-helper-file can be solved adding autotools-dev to build-depends
[14:26] <persia> DktrKranz: Rather, it can be worked around by doing that, and copying the files included in that package in the configure: rule.  Fixing it requires one of 1) an upstream update, 2) upstream not shipping the helper files, 3) manually updating the files at packaging time, or 4) copying the updated files in the clean rule (please don't do this).
[14:28] <persia> dcordero: To run X clients from a chroot, you either need to pass your environment variables into the chroot or have the chroot open a new display (VT8 or VT9 are popular choices, unless you have extra graphics cards and display hardware).
[14:30] <dcordero> :/ Ok, i'll search about it, thanks
[14:37] <lar2> Hi, tried my first revu upload this morning.  dput seemed happy, but I'm told by a human that the upload was rejected.  Trying again, dput says "Already uploaded to revu.tauware.de".  I guess I missed something?
[14:37] <persia> dcordero: http://www.debian-administration.org/articles/566 may have some useful hints.
[14:38] <man-di> lar2: 'rm *.upload' helps
[14:38] <dcordero> thanks persia
[14:38] <persia> lar2: Delete sun-javadb_10.3.2.1-0ubuntu1_source.upload and try again
[14:39] <DaveMorris> lar2: or use the -f flag
[14:40]  * persia doesn't like the -f flag, it becomes a habit, and leads to a mistake (or at least did for me)
[14:40] <lar2> Thanks for the tips - but now I got a network issue ;)
[14:50]  * RainCT tries to figure out why ushare was rejected.. http://paste.ubuntu.com/4341/plain
[14:53] <persia> RainCT: If the reason doesn't appear in https://lists.ubuntu.com/archives/ubuntu-archive/2008-February/thread.html fairly soon, complain to today's archive-admin about why it wasn't reported.
[14:53] <persia> RainCT: Ideally, you'd see something like https://lists.ubuntu.com/archives/ubuntu-archive/2008-February/014953.html
[14:56] <RainCT> persia: ok, thanks
[14:57] <ScottK> The only time I got rejected pitti mailed me directly.  Do they not do that anymore?
[14:58] <jdong> Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)
[14:58] <jdong> thanks, bzr.
[14:59] <jdong> format: [ f for f in all_formats] ?
[14:59] <persia> ScottK: From what I understand from the documentation, they are supposed to mail all of Changed-By, Uploaded-By, and the mailing list.  The first two seem to be a one or the other or both in a somewhat random fashion, but the mailing list is a constant.
[14:59]  * ScottK does the clamav on dapper victory dance.
[15:00] <persia> So, if you are both Changed-By, and Uploaded-By, you're very likely to get the mail, but this isn't so true for REVU uploads always.
[15:00] <ScottK> For those not following, the current clamav and suitable rdepends updates just got published to dapper-updates.
[15:00] <persia> ScottK: Congratulations!  Impressive coordination.
[15:02] <dholbach> ScottK: good work!
[15:02] <ScottK> As it happens the timing is good for me personally since my core-dev application goes to the tech board on Tuesday.  That effort is my masters thesis on distro integration.
[15:02] <ScottK> Thanks.
[15:02] <dholbach> hehe :)
[15:04] <huats_> ScottK: great work
[15:04] <HighNo> I've got a question - does a package for ubuntu need to run with kubuntu (kde desktop only?) As I have noticed my package would not because e.g. the icon for the notification area is a format (svg) that only gnome likes, kde doesn't
[15:04] <ScottK> Thanks.
[15:05] <Amaranth> HighNo: KDE works with svg icons
[15:07] <slytherin> HighNo: Beasides you can have a package for only GNOME. It is not a crime. :-)
[15:07]  * persia remembers something funny about KDE3 and special directories for svg icons, but the details are fuzzy, outdated, and possibly completely wrong.
[15:11] <HighNo> slytherin: pehw, I was kind of scared I would have to rewrite my software...
[15:32] <pi-meson> This is off-topic, but I can't seem to find a good channel -- can anyone recommend a channel for dealing with autotools/automake/autoconf issues?
[15:32]  * persia thought there was a dedicated freenode channel for just that purpose
[15:34] <pi-meson> persia, any idea what it's named? I've both googled and text searched the channel list on freenode with limited success
[15:35] <sistpoty|work> hi folks
[15:36] <persia> pi-meson: My apologies, but no.  I don't see anything that seems to have the right name on either freenode or oftc, even including goat-themed channels :(
[15:37] <persia> pi-meson: http://sourceware.org/autobook/autobook/autobook.html might be useful though, if non-interactive works for you.
[15:37]  * DaveMorris knows it's late in the day but wonders if someone could review http://revu.tauware.de/details.py?package=gtkglextmm to get it back into Ubuntu
[15:37] <persia> DaveMorris: Do you know of any external ISVs that depend on that?
[15:37] <DaveMorris> ISV?
[15:38] <pi-meson> persia, it's okay, thank you for looking! I've looked at the autobook a bit, but it's woefully short
[15:38] <pi-meson> DaveMorris, oh my, I just packaged gtkglextmm the other day for my project, I was really sad when it fell out of ubuntu!
[15:38] <persia> DaveMorris: Somebody who writes software not included in the distribution
[15:38]  * DaveMorris points at pi-meson
[15:39] <DaveMorris> bug #104804 has been around for a whle aswell.  That makes reference to sharpconstruct needing it
[15:39] <ubotu> Launchpad bug 104804 in gtkglextmm "gtkglextmm-1.2.0 is missing in feisty" [Wishlist,In progress] https://launchpad.net/bugs/104804
[15:39] <persia> pi-meson: You need it?  Please comment on the bug to indicate support.
[15:40] <pi-meson> persia: bug 104804?
[15:40] <persia> pi-meson: Yep.  That's the bug that needs enough support to get someone to upload.
[15:41] <pi-meson> I'm sorry, I'm somewhat new to this, everything I've ever wanted has always been packaged by default :) do I just add a "me too" note to the bug with a description of my app?
[15:42] <persia> pi-meson: That would work.  The package was removed previously because it was broken and didn't work.  Having multiple users indicate they want it helps get it back.
[15:42] <bddebian> Heya gang
[15:42] <sistpoty|work> hi bddebian
[15:42] <bddebian> Hi sistpoty|work
[15:44] <pi-meson> done!
[15:45] <DaveMorris> pi-meson: could you stick that comment on the revu page as well?
[15:46] <geser> Hi bddebian!
[15:46] <bddebian> Heya geser
[15:48] <pi-meson> DaveMorris: I don't seem to be able to login to revu, is there a url for account creation you could point me to?
[15:48] <DaveMorris> you need to upload a package afaik
[15:49] <DaveMorris> leave it on the bug report then, that'll do
[15:49] <DaveMorris> then we can nicely ask someone to review it ;)
[15:49] <pi-meson> wow, though, great timing, today must be my lucky day
[15:50] <DaveMorris> yeah, I forgot it needed packaging, till I went to build my software on another machine yesterday and had to build it myself
[15:51] <LucidFox> If I become a MOTU before FF, gtkglextmm will be the third REVU package I'll review - after qdevelop and tomboy-blogposter.
[15:51] <DaveMorris> LucidFox: you have programs that depend on it then?
[15:51] <LucidFox> No
[15:52] <pi-meson> Is the hope that we can get gtkglextmm into the next LTS? or is it too late?
[15:52] <DaveMorris> pi-meson: FF is the 14th
[15:53] <pi-meson> FF == Final Freeze, not "Feisty Fawn", i'm realizing now
[15:53] <LucidFox> heh
[15:53] <LucidFox> actually, it's Feature Freeze
[15:54] <pi-meson> okay, that makes even more sense
[15:56] <pi-meson> LucidFox, could I then beg you to review libdc1394-22 as well? you know, maybe bribe you with food or something
[15:57] <LucidFox> lol
[16:08] <HighNo> hehe, that's it. speed up the motus by sponsoring them directly. wasn't there a world wide pizza delivery service? MOTUs! Go and advocate blueproximity - a free pizza is going to you! :-)
[16:08] <HighNo> (I guess free beer would be a better motivation to most :-)
[16:11] <LucidFox> HighNo> Not to me. I don't drink alcohol.
[16:12]  * DaveMorris will REVU for food
[16:14] <mruiz> if there is no revision number in debian, the first revision in ubuntu should be X.Y-0ubuntu1 ?
[16:15] <DaveMorris> yes
[16:18] <ScottK> Is there a documented procedure for testing to see if a package builds with GCC 4.3?
[16:19] <jdong> nscreen -x
[16:19] <HighNo> DaveMorris: You got a bluetooth machine?
[16:19] <linux__alien> hey friends
[16:20] <DaveMorris> HighNo: yeah, and a blue toothphone.  But I'm not a MOTU yet
[16:21] <HighNo> DaveMorris: Darn, you fault you told me first :-) there goes your pizza...
[16:21] <geser> ScottK: install gcc-snapshot in your pbuilder and update the gcc symlink
[16:21] <\sh> ScottK, yes
[16:21] <\sh> ScottK, take the toolchain from ubuntu-toolchain team, and add them to your pbuilder/sbuild
[16:21]  * ScottK waits for geser and \sh to agree.
[16:22] <\sh> doko had written a mail for this
[16:22] <\sh> ScottK, I'm using the gcc 4.3 stuff from https://edge.launchpad.net/~ubuntu-toolchain/+archive, which is dokos and others playground for new toolchar
[16:22] <\sh> toolchain
[16:23] <geser> ScottK: then do what \sh said, my test-build with gcc 4.3 is some time ago
[16:23] <jdong> "64 bit CPU and 64 bit OS. I don't even think of using 32 bit OS anymore.
[16:23] <jdong> All the 64 bit vs 32 bit compatibilty issues are easily solvable via dpkg --force or dpkg -X in my case."
[16:23] <jdong> dear.... effing... loard
[16:23] <jdong> lord*
[16:25] <\sh> ScottK, and check the dbts, a good reference is martin michlmayr (his bug page: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.3;users=tbm@cyrius.com)
[16:25] <\sh> ScottK, and check out his blog (http://www.cyrius.com/journal) a very good source for how to fix 4.3 ftbfs bugs
[16:26] <ScottK> Thanks.
[16:27] <\sh> ScottK, I started 2 weeks ago to check some packages of us, where bug fixes were filed from martin, and many of those fixes are already applied by doko or others
[16:27] <broonie> Lots of teh fixes for 4.3 should be in Debian already.
[16:27] <linux__alien> hey norsetto
[16:27] <linux__alien> hey LucidFox
[16:28] <DaveMorris> HighNo: I've buillt and installed your package, how do I configure it?
[16:28] <DaveMorris> found it
[16:28] <HighNo> DaveMorris:  When started for the first time it should give settings
[16:28] <ScottK> broonie: I just took over a package in Debian that's got a GCC 4.3 FTBFS bug on it and I'm trying to make sure.
[16:29] <ScottK> \sh: Since you're already set up for it, would you mind doing a test build for me?
[16:29] <\sh> ScottK, sure...when I'm coming home I can do that :)
[16:29] <ScottK> \sh: Thanks.
[16:29] <\sh> ScottK, just send me a mail or something with the package :)
[16:29] <DaveMorris> HighNo: it doesn't run, you tried it on hardy?
[16:30] <\sh> ScottK, ah wait...just give me the package :)
[16:30] <ScottK> \sh: OK.  It's the current klamav package in Hardy.
[16:30] <broonie> ScottK: Ah, I see. I'd been working on some of those bugs but IIRC the packages that remained weren't overcoming my enthusiasm/apathy limits
[16:30] <HighNo> DaveMorris: no, because I am bound to Feisty due to limited drive space
[16:30] <HighNo> DaveMorris: tell me more
[16:30] <\sh> ScottK, give me a sec :)
[16:31] <ScottK> broonie: The old klamav maintainer hadn't touched the package in over a year, so it isn't suprising no one was excited about digging into it.
[16:31] <DaveMorris> "The program cannot import the module bluetooth"
[16:31] <\sh> ScottK, 0.42-0ubuntu1?
[16:32] <broonie> ScottK: Yeah, and the KDE bit tends to be a bit of a turn-off for me.
[16:32] <\sh> ScottK, most propably some bug like described on this page: http://www.cyrius.com/journal/gcc/gcc-4.3-include.html
[16:33] <ScottK> \sh: Yes, but the Debian vesion is ancient and I'm hoping the one just released last month works.
[16:33] <\sh> it's building :)
[16:33] <ScottK> Great.  Thanks.
[16:34] <HighNo> DaveMorris: ehm, ok. I'll look which package supports it with feisty and we can look what is missing...
[16:34]  * DaveMorris is off home in 45 mins though
[16:34] <\sh> ScottK, ok...I need to leave the office...I let it build, and when I'm coming home, I have my buildlog file in my inbox :)
[16:35] <ScottK> \sh: Sounds good.  Thanks.
[16:35] <\sh> ScottK, you're welcome .)
[16:35] <mok0> Does anyone here remember a package that employs chrpath? I'd like to peek at it
[16:35] <\sh> grmpf...damn keyboard from dell
[16:35]  * \sh needs to needs his logitech back
[16:36] <HighNo> DaveMorris: it must be in python-bluez
[16:36] <DaveMorris> that package is installed, since that's what it recommends I install
[16:36] <\sh> ScottK, bad luck...
[16:36] <HighNo> DaveMorris: /usr/share/pycentral/python-bluez/site-packages/bluetooth.py
[16:36] <\sh> ScottK, eMail address to send you the buildlog?
[16:37] <ScottK> \sh: scott at kitterman dot com
[16:38] <\sh> ScottK, send...
[16:38] <ScottK> I don't know why I do that.  That's been my address for a decade and I'm already on every spammer list in the world.
[16:38] <ScottK> Thanks.
[16:38] <ScottK> \sh: Is it a happy ending or a sad one?
[16:38] <\sh> ScottK, sad one
[16:38] <ScottK> Thanks.
[16:38] <ScottK> Urgh.
[16:38] <\sh> ScottK, if you need an i386 build please let me know...I set up an i386 sbuild for gcc43 work then
[16:39] <ScottK> Thanks.
[16:39] <DaveMorris> HighNo: nope, different path
[16:39] <\sh> ok...rushing home :)
[16:39] <\sh> bbl
[16:39] <DaveMorris> /usr/share/pycentral/python-bluez/site-packages/bluetooth/bluez.py
[16:39] <HighNo> DaveMorris: different path could be - this is feisty. And managed by pycentral, the used file is at /usr/lib/python2.5/site-packages/bluetooth.py
[16:40] <HighNo> DaveMorris: ahh, so that package changed after feisty. good to know.
[16:40] <HighNo> DaveMorris:  I'll dissect that package, I know I have 30 mins left...
[16:43] <HighNo> Hm, I am in a pbuilder environment logged in. I am using feisty but the environment is setup for hardy. I want to install python-bluez but it's not found. Did they change the name=
[16:43] <HighNo> ?
[16:44] <gpocentek> HighNo: is universe enabled in your pbuilder ?
[16:45] <HighNo> ahh, thx - i forgot to enable it...
[16:47] <mok0> Is there a way to find reverse Build-Depends?
[16:47] <Amaranth> mok0: grep through Sources.gz
[16:47] <mok0> Amaranth: thx
[16:48] <linux__alien> LucidFox, I am going through the Packaging Guide. Once i am done with, i would need your advice to go further
[16:49] <linux__alien> please LucidFox
[16:49] <LucidFox> linux__alien> whatever I can help with
[16:50] <LucidFox> it's better, however, to refer to the channel in general
[16:50] <LucidFox> rather than specifically to one person
[16:50] <HighNo> Hm, there is probably an error with python-bluez. The docs are only partly included. the html manual consists of just one file that links to several non existant ones...
[16:50] <ion_> amaranth: grep-dctrl -FBuild-Depends -sPackage ghc /var/lib/apt/lists/*_Sources
[16:50] <linux__alien> ya sure but want to contribute to Ubuntu and want to be a part of the team, but i dont have a mentor unfortunately :(
[16:50] <Amaranth> ion_: Yeah, I can never remember that, I wonder why :P
[16:52] <linux__alien> LucidFox, I ve generated the basic files for packaging for an example but the rules file which is got generated does not have much contents, should i manually type or can i generate that too ?
[16:53] <LucidFox> linux__alien> Are you using dh_make?
[16:53] <linux__alien> yes
[16:53] <mok0> dh-make, yeechh
[16:54] <linux__alien> i ve the other files proper but the rules files contains two include files thats it
[16:55] <linux__alien> cant the rules file be generated at all ?
[16:55] <mok0> linux__alien: you're using cdbs, that
[16:55] <mok0> is cool
[16:55] <linux__alien> mok0, so am i on the right track ? :)
[16:56] <mok0> linux__alien: yeah
[16:56] <LucidFox> o_O
[16:56] <LucidFox> so abruptly
[16:56] <mok0> hehe
[16:56] <mok0> The old ^D
[16:56] <mok0> Here he is again
[16:56] <linux__alien> mok0, sorry got disconnected . i am using cdbs
[16:56] <LucidFox> linux__alien> CDBS isn't very newbie-friendly, though
[16:57] <HighNo> DaveMorris: Sorry, I had to file the bug first... I'm looking for the manual of that package...
[16:57] <LucidFox> it introduces a lot of "magic"
[16:57] <linux__alien> LucidFox, what should i use ?
[16:57] <linux__alien> any suggestions or advice?
[16:57] <mok0> Look at the wiki: https://wiki.ubuntu.com/PackagingGuide/Howtos/CDBS
[16:57] <ion_> I find quite easy to use CDBS, as long as i know which dh_* i need for what. But you need to know that when not using CDBS, too.
[16:58] <linux__alien> mok0, is there any other alternative for cdbs
[16:58] <linux__alien> ?
[16:58] <mok0> linux__alien: basically, you control things using the *install etc. files
[16:58] <linux__alien> in cdbs is it?
[16:58] <DaveMorris> HighNo: no probs
[16:59] <ScottK> CBDS works very well for some things.  I can do a python module package in an hour with it (and most of that time is spent on debian/copyright), but then somethig weird happens and you're stuck reading the source.
[16:59] <LucidFox> linux__alien> there is also debhelper, which uses longer but more manually-tweakable rules files
[16:59] <mok0> linux__alien: the alternative is using the straight Makefile with direct calls to the debhelper scripts
[16:59] <linux__alien> so what do you advice . I am a newbie so kindly guide me
[16:59] <linux__alien> to ubuntu packaging
[17:00] <mok0> ScottK: Actually, I expanded the cdbs howto a while ago, and now it covers a lot more
[17:01] <ScottK> mok0: That's great.  I may have to look at it then.  My standard CDBS approach is spend 5 minutes searching the official docs, fail to find what I want and then start grepping the source.
[17:01] <mok0> linux__alien: I advice you to stick to your guns and use cdbs
[17:01] <mok0> ScottK: Heh, that's what I did, and then I wrote it down
[17:01] <ScottK> mok0: You might want to consider sending documentation patches upstream.
[17:02] <linux__alien> moko ok sure thanks for it coz i just want to contribute to Ubuntu . So desparate :)
[17:02] <sistpoty|work> doing packaging completely from scratch is a great learning experience (i.e. no dh_make, no cdbs, no debhelper, just plain make)
[17:02] <mok0> ScottK: The problem with the official cdbs manual is not that it's lacking information, it's just badly organized.
[17:02] <ScottK> mok0: My problems have been that it's lacking information.
[17:03] <mok0> ScottK: Oh? Like what?
[17:03] <LucidFox> sistpoty|work> I disagree, I think it's better to start with debhelper
[17:03] <LucidFox> Not so long ago, I saw a package on REVU that used a low-level debian/rules without debhelper
[17:03] <mok0> LucidFox: the advantage with that approach is that you are forced to learn the debhelper tools. Which sux.
[17:04] <sistpoty|work> LucidFox: I guess if you want to make an actual package w.o. too much fuss, debhelper (or even cdbs) seems more suitable. nonetheless doing it completely w.o. is a great learning experience
[17:04] <ScottK> mok0: The last I needed to figure out what how to add an extra configuration option to an autotools package (DEB_CONFIGURE_EXTRA_FLAGS).
[17:05]  * mok0 looks
[17:05] <linux__alien> for a hello world program i have the rules file which has this
[17:05] <linux__alien> #!/usr/bin/make -f (-)
[17:05] <linux__alien>                                 
[17:05] <linux__alien> include /usr/share/cdbs/1/rules/debhelper.mk
[17:05] <linux__alien> include /usr/share/cdbs/1/class/autotools.mk
[17:05] <linux__alien> is that all i need for it to be packaged?
[17:05] <ScottK> !pastebin | linux__alien
[17:05] <ubotu> linux__alien: pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[17:05] <mok0> ScottK: It's in there ;-)
[17:06] <ScottK> OK.  Maybe you're right then.
[17:06] <linux__alien> am sorry ScottK didnt see that
[17:06] <mok0> ScottK: Like I said, it's poorly organized, which is why our wiki is needed. What people want to know is: "what do I do if..." and there should be some examples
[17:07] <ScottK> Sounds good.
[17:07] <HighNo> DaveMorris: I don't know what's going on there - even the newest examples show one has to "import bluetooth"
[17:07] <linux__alien> mok0, The link you gave me sounds useful and its good too but the tutorial says that these 2 lines are whats needed . Is that all what we need ?
[17:08] <mok0> linux__alien: depends on how your package is built. Does it use "configure; make; make install" ?
[17:09] <ion_> linuxalien: Depends on your upstream source. If it uses autotools and does the right thing, that’s probably most of the debian/rules you’ll need.
[17:09] <linux__alien> mok0, its that packaging guide example the hello example
[17:09] <mok0> linux__alien: link?
[17:09] <LucidFox> linux__alien> to my knowledge, the hello example doesn't use CDBS
[17:09] <linux__alien> https://wiki.ubuntu.com/PackagingGuide/Complete
[17:10]  * mok0 looks...
[17:10] <LucidFox> so you probably selected the wrong package type in dh_make - it should have been "single binary" instead of "cdbs"
[17:11] <linux__alien> LucidFox, ok but the control file didnt get generated when i chose that option and also want to know if i select single binary will the files still continue to get auto generated?
[17:11] <norsetto> hi linux__alien
[17:11] <linux__alien> hi norsetto
[17:11] <linux__alien> how are you doin
[17:12] <mok0> linux__alien: from what I can see it uses gnu autotools, which is perfect for cdbs
[17:12] <mok0> linux__alien: then you only need to includes in your rules file:
[17:12] <linux__alien> yes but curious to know if i had selected the single binary option will i still get the files auto generated ?
[17:12] <doko> \sh_away: all packages in main should be buildable with 4.3
[17:13] <DaveMorris> HighNo: where is the bluepromity python file stored?
[17:13] <mok0> cdbs knows because control tells it how many packages to make.
[17:13] <HighNo> DaveMorris: I even checked the examples in the docs. there must be an "import bluetooth" possible...
[17:14] <HighNo> DaveMorris: /usr/share/blueproximity/proximity.py
[17:14] <linux__alien> mok0, so i can use cdbs for most of the packaging right?
[17:14] <mok0> Yep
[17:15] <HighNo> DaveMorris: maybe we could find another package using python-bluez and check whether that one works
[17:16]  * DaveMorris fixed it
[17:16] <HighNo> DaveMorris: so what was it?
[17:16] <mok0> linux__alien: If you just use a makefile with debhelper calls, the MOTUs are gonna crawl all over it like ants on a lollypop
[17:16] <DaveMorris> how do I find out the current line in vim?
[17:17] <linux__alien> mok0, why ? :)
[17:17] <mok0> linux__alien: with cdbs, they leave it alone
[17:17] <mok0> linux__alien: because there are so many ways to tweak it
[17:18] <linux__alien> DaveMorris, Ctrl + G
[17:18] <ScottK> \sh_away: And there's even a build with GCC 4.3 patch on sourceforge already, so I'll have a updated package for you to test shortly.
[17:18] <mok0> linux__alien: the template you get from dh-make has a lot of cruft that you need to get rid of
[17:18]  * linux__alien is confused :(
[17:18] <DaveMorris> HighNo: comment out line 97, and remove the underscore in line 98
[17:18] <linux__alien> i am sorry mok0 :(
[17:19] <linux__alien> i ve got confused :(
[17:19] <mok0> linux__alien: just stick to using cdbs for now
[17:19] <sistpoty|work> mok0: heh, that's the worst argument I've heard in favor of cdbs so far *g*
[17:19] <mok0> sistpoty|work: I've lots of bad arguments, which one do you mean :-)
[17:20] <sistpoty|work> mok0: the one you wrote just now... that MOTUs will do less criticism to cdbs rules than to debhelper rules ;)
[17:20] <mok0> sistpoty|work: heh. Strange but true.
[17:21] <ion_> “Drink fluids regularly. I’m doing it, too.” “That’s the worst argument i’ve heard in favor of drinking so far.” “Oh, you’ll stay alive, too.”
[17:21] <mok0> sistpoty|work: I mean, it only has 2 lines...
[17:21] <linux__alien> mok0, i get this error when i try to builld the source package
[17:21] <linux__alien> /usr/bin/dpkg-buildpackage: 224: fakeroot: not found
[17:21] <mok0> linux__alien: apt-get install fakeroot
[17:21] <DaveMorris> HighNo: actually, that just makes it load, but not work :(
[17:22] <mok0> sistpoty|work: the sad truth is the cdbs just calls _all_ of the debhelper scripts :-)
[17:22] <mok0> sistpoty|work: ... it also includes the ones that MOTUs normally have you weed out
[17:22] <mok0> Hehe
[17:22] <DaveMorris> HighNo: you just need to remove the underscore on line 98
[17:22] <DaveMorris> then it works
[17:23] <jcfp> MOTUs, please take a look at http://revu.tauware.de/details.py?package=sabnzbdplus (time constraints, weather, and blood alcohol level permitting)
[17:23] <linux__alien> mok0, now i get a different error
[17:23] <linux__alien> debian/rules:3: /usr/share/cdbs/1/rules/debhelper.mk: No such file or directory
[17:23] <linux__alien> debian/rules:4: /usr/share/cdbs/1/class/autotools.mk: No such file or directory
[17:23] <sistpoty|work> mok0: yes, heh
[17:23] <mok0> linux__alien: apt-get install cdbs
[17:23] <ion_> Install cdbs (and add it as a build dep).
[17:23] <HighNo> DaveMorris: I know, that's because both lines are there...
[17:23] <HighNo> DaveMorris: but that shows the problem is import _bluetooth
[17:24] <linux__alien> mok0, how do i know that my build is complete
[17:24] <mok0> linux__alien: if it creates a .deb file?
[17:25] <linux__alien> where would that be?
[17:25] <linux__alien> placecd
[17:25] <linux__alien> placed
[17:25] <DaveMorris> well I can now start it and connectr to my phone
[17:25] <ion_> In ..
[17:25] <mok0> ... normally the parent of the directory that has debian/
[17:25] <linux__alien> dpkg-source: building hello in hello_2.1.1.dsc
[17:25] <linux__alien> dpkg-source: unrepresentable changes to source
[17:25] <linux__alien> i get this
[17:26] <DaveMorris> although I get an error when trying to scan for a channel
[17:26] <mok0> It means that you have generated a binary or something that is not being removed by the script
[17:27] <ScottK> Lutin or Adri2000: I have a DaD feature request when you have a moment.
[17:28] <HighNo> DaveMorris: correct, that's one place where it is used
[17:28] <DaveMorris> but I can scan for the device
[17:28] <HighNo> DaveMorris: the other one is when actually connecting to the phone
[17:28] <Adri2000> ScottK: yes? (likely to become a MoM feature request though)
[17:28] <ScottK> Adri2000: No problem.
[17:28] <mok0> linux__alien: ... is not being removed by upstreams Makefile is more accurate...
[17:29] <HighNo> DaveMorris: try to set it to your phone's mac and close the dialogue. it should go into connection mode
[17:29] <ScottK> Adri2000: I just had to split Debian's amavisd-new package into two to get part of it in Main.
[17:29] <ScottK> Adri2000: So it would be great if MoM/DaD (whichever) would look to amavisd-new in Main as the merge source for both amavisd-new and amavisd-new-milter source packages in Ubuntu.
[17:29] <HighNo> DaveMorris: hover the mouse over the tray icon and it should show connected and a value
[17:30] <DaveMorris> HighNo: http://pastebin.com/f2929c662
[17:31] <DaveMorris> when running it can't establish a connection (they are inches apart) but no error messages
[17:31] <sistpoty|work> Adri2000: that sounds like there are news in MoM/DaD merging process?
[17:32] <Adri2000> ScottK: amavisd-new is one source package in debian, and is splitted in ubuntu between amavisd-new (main) and amavisd-new-milter (universe). right? could you file a bug in LP please?
[17:33] <linux__alien> mok0, i am upset that i am not able to understand this part :(
[17:33] <mok0> linux__alien: explain
[17:33] <linux__alien> why is this error coming
[17:33] <Adri2000> sistpoty|work: yes. MoM source released. we are starting to work on patching MoM with DaD features
[17:33] <linux__alien> it didnt show me any sort of compilation error
[17:33] <ScottK> Adri2000: That's right.
[17:33] <sistpoty|work> Adri2000: cool, great :)
[17:33] <ScottK> Adri2000: Where to file the bug?
[17:33] <mok0> linux__alien: is it still the unrepresentable ... etc?
[17:34] <linux__alien> yes\
[17:34] <linux__alien> whats that i ve to do to correct this
[17:34] <mok0> linux__alien: I'll give it one line at a time
[17:34] <mok0> linux__alien: dpkg-source wants to make a diff between the current dir and the tar file
[17:34] <linux__alien> you want me to paste it ?
[17:34] <linux__alien> ok..
[17:34] <mok0> linux__alien: no, just say "yes" ;-)
[17:35] <Adri2000> ScottK: merge-o-matic
[17:35] <linux__alien> yes...
[17:35] <ScottK> Adri2000: Thanks.
[17:35] <mok0> linux__alien: It has found some files in the current tree that are not in the .orig.tar.gz
[17:35] <sistpoty|work> linux__alien: dpkg-source basically builds a unified diff between the orig-tarball and the extracted directory. This is what will become the .diff.gz. This means that anything that cannot be represented in a unified diff (e.g. no-text stuff, or permission changes of files) won't go into the .diff.gz
[17:36] <mok0> sistpoty|work: yeah but the build fails
[17:36] <HighNo> DaveMorris: I know that problem (pastebin) but it should also not be able to connect.
[17:36] <linux__alien> i ve an other tar file as a backup called hello_orig.tar.gz
[17:36] <linux__alien> but thats outside the directory
[17:36] <linux__alien> will it harm it ?
[17:36] <mok0> linux__alien: the ONLY difference between the upstream tarball and your directory should be the debian/ dir
[17:36] <sistpoty|work> mok0: why?
[17:37] <linux__alien> ok here it is
[17:37] <HighNo> DaveMorris: funky, i found another example from the package itself and it also uses "import _bluetooth"
[17:37] <mok0> sistpoty|work: why it fails?
[17:37] <linux__alien> this is what i ve
[17:37] <linux__alien> hello-2.1.1          hello_2.1.1.dsc          hello-2.1.1.tar.gz
[17:37] <linux__alien> hello_2.1.1.diff.gz  hello_2.1.1.orig.tar.gz
[17:37] <linux__alien> the first one is a directory
[17:37] <sistpoty|work> mok0: yep
[17:37] <linux__alien> the next file is generated i believe
[17:37] <DaveMorris> any more quick testing you want?
[17:38] <HighNo> DaveMorris: could you try running this one: /usr/share/doc/python-bluez/examples/l2-unreliable-client.py
[17:38] <mok0> linux__alien:  lsdiff -z hello_2.1.1.diff.gz
[17:38] <DaveMorris> I suggest you grab a hardy livecd and test it though,
[17:38] <HighNo> DaveMorris: that's a good idea. Will download it tonight.
[17:38] <ScottK> Adri2000: Bug #190244
[17:38] <ubotu> Launchpad bug 190244 in merge-o-matic "Please use amavisd-new as merge source for both amavisd-new and amavisd-new-milter in Ubuntu" [Undecided,New] https://launchpad.net/bugs/190244
[17:39] <mok0> sistpoty|work: when you run a debuild, it fails on "unrepresentable... " etc.
[17:39] <joejaxx> is there anything special you have to do when packaging a python application?
[17:39] <linux__alien> shall i paste the list in pastebin?
[17:39] <mok0> sistpoty|work: maybe my memory is failing me
[17:39] <Adri2000> ScottK: thanks
[17:39] <linux__alien> shall i paste the list in pastebin?
[17:39] <mok0> linux__alien: yes
[17:40] <DaveMorris> HighNo: fails, with no module named _bluetooth
[17:40] <sistpoty|work> mok0: I'm used to that error (for me it means: Close the vi on the file you've just patched! *g*)
[17:40] <linux__alien> http://pastebin.com/m4bf6d670
[17:40] <joejaxx> or  anyone have a link to the ubuntu policy on packaging python apps?
[17:41] <ScottK> joejaxx: It's the same as the Debian policy
[17:41] <sistpoty|work> joejaxx: iirc the debian-policy package contains the python policy as well
[17:41] <mok0> linux__alien: looks great. It has only files in debian/* , you see?
[17:41] <linux__alien> yes
[17:41] <linux__alien> so what does that mean
[17:41] <HighNo> DaveMorris: download started. Thanks for your efforts anyway. I hope to have a solution for you tomorrow. It is a nice tool :-)
[17:41] <linux__alien> the other things are perfect
[17:41] <linux__alien> ie there are no other extra files in the other directories right?
[17:41] <linux__alien> thats what it means right?
[17:42] <joejaxx> which is better? python-support? or python-central?
[17:42]  * DaveMorris makes sure he takes the usb bluetooth stick home
[17:42] <mok0> linux__alien: it is a diff that can add the debian directory to upstreams tarball
[17:42] <linux__alien> ok now whats the  next step
[17:42]  * DaveMorris would hook the tool up to the bosses phone so you know when they are coming :)
[17:42] <linux__alien> how will i get the deb file ? :) just want to have one packaging done before i go to bed and tomorrow will try few more :)
[17:42] <mok0> linux__alien: you must try to generate a binary .deb file.
[17:42] <HighNo> DaveMorris: where are you located?
[17:43] <mok0> linux__alien: go into the top directory and do "debuild"
[17:43]  * sistpoty|work heads home now
[17:43] <DaveMorris> UK
[17:43] <HighNo> DaveMorris: hehe, that's probably the most geekish use I could think of :-)
[17:43] <sistpoty|work> later folks
[17:43] <linux__alien> ok will do that . That would give me the binary package is it?
[17:43] <mok0> sistpoty|work: see you
[17:43] <mok0> linux__alien: it should
[17:44] <linux__alien> http://pastebin.com/m4bf6d670
[17:44] <linux__alien> debuild: fatal error at line 1247:
[17:44] <linux__alien> dpkg-source -b hello-2.1.1 failed
[17:44] <mok0> linux__alien: can you pastebin that output?
[17:44] <linux__alien> sure
[17:44] <mok0> linux__alien: (I have to go soon)
[17:45] <linux__alien> one sec
[17:45] <linux__alien> http://pastebin.com/mad6fcb8
[17:46] <ion_> .rules.swp probably comes from vim.
[17:46] <ion_> :%bd and then try to build the source package.
[17:46] <mok0> linux__alien: You have a strange file called debian/.rules.swp What is that?
[17:46] <linux__alien> ok deleted that possibly because of vim
[17:47] <linux__alien> i believe
[17:47] <mok0> linux__alien: get rid of it and try again
[17:47] <linux__alien> now it moves one sec
[17:47] <ion_> You don’t need to delete it (unless vim has crashed), just remove the equivalent buffer.
[17:47] <ion_> Vim takes care of removing the swap file.
[17:47] <linux__alien> debsign: gpg error occurred!  Aborting....
[17:47] <linux__alien> debuild: fatal error at line 1174:
[17:47] <linux__alien> running debsign failed
[17:48] <mok0> Hrmmph
[17:48] <mok0> linux__alien: debuild -us -uc
[17:48] <ion_> You probably got a package, you just didn’t sign it.
[17:48] <linux__alien> oh ok i ll learn that a little later
[17:48] <linux__alien> hello_2.1.1_i386.deb
[17:48] <linux__alien> fine ?
[17:49] <ion_> less the file, make sure its contents are ok.
[17:49] <mok0> looks like it. Now use dpkg -c hello_2.1.1_i386.deb
[17:49] <linux__alien> it shows lot of files
[17:49] <ion_> (If less doesn’t give nice output, you haven’t enabled lesspipe.)
[17:50] <linux__alien> it shows something like this
[17:50] <mok0> ion_: Hey! that's a cool trick I didn't know
[17:50] <linux__alien> drwxr-xr-x root/root         0 2008-02-08 23:18 ./usr/share/locale/fr/LC_MESSAGES/
[17:50] <linux__alien> -rw-r--r-- root/root      3883 2008-02-08 23:18 ./usr/share/locale/fr/LC_MESSAGES/hello.mo
[17:51] <linux__alien> something like this
[17:51] <mok0> linux__alien: yeah, you got your package.
[17:51] <linux__alien> oh Thanks got it finally . Thanks a lot
[17:51] <mok0> linux__alien: now you can install it using dpkg -i (as root)
[17:51] <linux__alien> I am really sorry i guess i ve troubled you
[17:51] <mok0> linux__alien: You're going to help someone else another time. That's the price :-)
[17:52] <linux__alien> yes sure
[17:52] <ion_> Or gdebi foo.deb, or dpkg --unpack foo.deb and apt-get -f install to handle dependencies (not necessary in this case).
[17:52] <linux__alien> i am ready for it and want to help others and want to be part of the Ubuntu team :)
[17:52] <mok0> Well gotta go, see you later
[17:52] <linux__alien> its got installed
[17:52] <mok0> linux__alien: :-)
[17:52] <linux__alien> cya mok0
[17:52] <linux__alien> ya executed it also it says hello world :)
[17:53] <linux__alien> got to go now
[17:53] <linux__alien> cya thanks for your help cya tomorrow have a nice dya
[17:53] <linux__alien> have a nice day
[17:53] <linux__alien> cya ion_
[18:35] <vemon> revu? http://revu.tauware.de/details.py?package=lashwrap
[18:35] <vemon> or: http://revu.tauware.de/details.py?package=ghostess
[18:36] <vemon> good audio production related stuff to add to hardy
[18:51] <mruiz> hi all
[19:02] <jeromeg> jdong: hello, I'm testing some backports, what do you thnik of bug 189708 ?
[19:02] <ubotu> Launchpad bug 189708 in gutsy-backports "Please backport tcl/tk 8.5" [Undecided,New] https://launchpad.net/bugs/189708
[19:02] <jeromeg> it has a huge number of rdepends
[19:02] <jeromeg> it builds fine, and upgrade doesn't seem to make other programs unusable
[19:04] <jdong> jeromeg: it seems like tcl8.5 is a separate source package and doesn't conflict namespace with existing 8.4
[19:04] <jdong> jeromeg: but I'm not 100% confident of that, it'd be better if you can find another developer to say what I just said :)
[19:05] <jdong> at that point, I would be happy to approve
[19:05] <jeromeg> jdong: ok
[19:06] <kdu1> while trying to make my first debian package using dh_make/debuild, its complaining that I don't have a secret gpg key, despite the fact that I do....
[19:11] <kdu1> its saying something about signing it under the name "Kevin" when my key is under my full name, how do i fix that?
[19:12] <sistpoty> kdu1: not exactly sure, but imo setting the environment var DEBEMAIL to your email address should fix it
[19:14] <kdu1> sistpoty: that didnt work...
[19:15] <sistpoty> kdu1: you could also try to set DEBSIGN_KEYID to your key id
[19:15] <sistpoty> (and make sure to export these variables, so that a subshell will see them)
[19:21] <jeromeg> jdong: bug 190055 seems fine to me, it already has three testers
[19:21] <ubotu> Launchpad bug 190055 in gutsy-backports "Please backport audacity 1.3.4 from Hardy" [Undecided,Confirmed] https://launchpad.net/bugs/190055
[19:24] <jeromeg> got to go
[19:24] <jeromeg> bye
[19:25] <kdu1> anyone have any ideas about my signing problem with debuild?
[19:26] <ScottK> kdu1: Pass the key id to be used using the -k option.
[19:28] <jdong> ScottK: isn't the only time debuild can't auto-detect when the e-mail in the changelog doesn't correspond with any e-mails in the private keyring?
[19:28] <jdong> i.e. passing in -k is just a workaround?
[19:28] <jdong> (of course for sponsoring this is normal/expected)
[19:28] <ScottK> It's not just the email.  It's also the name.
[19:28] <jdong> ScottK: ah, ok, didn't think of that
[19:29] <jdong> ScottK: but still... wouldn't it be good practice for those to match?
[19:29] <mruiz> is interdiff a patch ?
[19:30] <ScottK> jdong: Yes, but for the name, I don't think it's essential.
[19:30] <jdong> mruiz: a special form. see InterDiff on the wiki
[19:30] <jdong> ScottK: reluctantly agree :)
[19:30] <ScottK> \sh_away: Please let me know when you're around for another gcc 4.3 test build.
[19:31] <mruiz> jdong, I prepared one and I was thinking about the "patch" checkbox on LP gui
[19:31] <jdong> mruiz: I think that'd be appropriate
[19:32] <DaveMorris> HighNo: got a working package for me to test yet :)
[19:46] <mruiz> bye all
[19:55] <HighNo> oh, hi DaveMorris
[19:56] <HighNo> DaveMorris:  sorry, not yet - had to bring my kids to bed and wife too, now I get back to work...
[19:57] <DaveMorris> where are you based then?
[19:58] <sistpoty> cedricv: you want to join the uncommon-proglang team?
[20:00] <cedricv> hi sistpoty!  yeah, i'd like to update the boo package to the newly released 0.8.1 version
[20:00] <sistpoty> hi cedricv ;)
[20:01] <sistpoty> *trying to remember who knows about boo*
[20:01] <HighNo> DaveMorris: Germany
[20:03] <sistpoty> cedricv: iirc slomo should know the boo package, maybe you could talk to him about it?
[20:04] <sistpoty> slomo: ^^ ;)
[20:05] <cedricv> i hope it is not too late to submit at revu for being included in hardy? :)   we still receive reports for the 1-year old version available in the repos
[20:05] <sistpoty> cedricv: well... it's almost too late for it, as FeatureFreeze is approaching soon :/
[20:06] <cedricv> even if i (or slomo? ;) ) submit for review tonight or tomorrow ?
[20:07] <sistpoty> cedricv: I won't make promises for that... but there is still a chance ;)
[20:07] <sistpoty> cedricv: of course slomo can upload till FF w.o. problems *g*
[20:10] <HighNo> DaveMorris: I'm booting hardy live cd in vmware right now. This should not take too long now...
[20:16] <sistpoty> cedricv: oh, there's a newer debian version (0.8.0.2730)... is that up to date enough? maybe it could then just get synced
[20:17] <cedricv> oh it would already be a nice improvement :)    i'm currently trying to build source package for 0.8.1.2865      (binary deb packages available on the website)
[20:17] <cedricv> 0.8.0.2730 is the version on debian unstable repo?
[20:18] <sistpoty> cedricv: yes
[20:20] <Coper> Can some MOTU review console-freecell?
[20:22] <sistpoty> Coper: I'll give a quick look
[20:22] <Coper> sistpoty: thanks
[20:24] <kdub> i'm still having that signing problem, and its driving me up a wall
[20:24] <sistpoty> Coper: you don't have any patches, so I guess simple-patchsys.mk is not needed (not a blocker though)
[20:25] <sistpoty> Coper: oh, forget it, didn't saw the manpage patch when looking at the .diff.gz
[20:28] <sistpoty> Coper: debian/copyright: I'd put the link to GPL (as you write in there, that it is GPL-2 or above)... but that's a matter of taste
[20:32] <sistpoty> Coper: I'd also install the upstream changelog into the package (seems to be a cdbs bug FWIW)
[20:33] <sistpoty> Coper: others than that, looks fine
[20:34] <ScottK> \sh_away: http://revu.tauware.de/revu1-incoming/klamav-0802082120/klamav_0.42-1.dsc (or anyone else who's set up to do gcc 4.3 test builds).
[20:34] <HighNo> DaveMorris: please change line 98 from "import _bluetooth as bluez" to "import bluetooth._bluetooth as bluez" and try again. start it from the commandline via "blueproximity" to check console output.
[20:35] <sistpoty> Coper: advocated, since all these points are no major blockers
[20:46] <DaveMorris> HighNo: that seems to be working now, I can connect to the phone etc
[20:47] <HighNo> DaveMorris: cool - even though they should have updated their own examples...
[20:48] <DaveMorris> only prob is it doesn't seem to have detected my phone on the other side of the flat
[20:49] <HighNo> DaveMorris: I will try to find a way to support both variants in one source and build a new package....
[20:49] <HighNo> DaveMorris: Other side of the flat? How many meters and walls is that?
[20:49] <DaveMorris> why do you need both variants
[20:49] <DaveMorris> 5M, I'm gonna chuck it outside in a mo?
[20:50] <DaveMorris> working now
[20:51] <HighNo> DaveMorris: because I'm also upstream author so I want to keep the supported stuff as big as possible. The same stuff is included in to orig.tar.gz and should run if it's just unpacked, which I know now will not work with hardy.
[20:52] <DaveMorris> ahh, for now I suggest using a patch for hardy so it can get in before FF
[20:53] <HighNo> DaveMorris: hm, how would I do that?
[20:53] <nxvl_work> i'm having a weird problem with gedit
[20:54] <nxvl_work> i'm editing the version needed of 2 packages on the debian/control file
[20:54] <DaveMorris> what packaging system are you using?
[20:54] <nxvl_work> but when i build it (using dpkg-builpackage or debuild) they undo the changes i have made
[20:54] <nxvl_work> so the change is not shown on the debdiff
[20:55] <sistpoty> ScottK: can you archive klamav? that way links are still the same, but it won't show up in the review page
[20:55] <HighNo> DaveMorris: I'm not quite sure what you mean, but would cdbs be a legitimate answer?
[20:55] <DaveMorris> yeah
[20:56] <DaveMorris> cdbs patches are easy
[20:56] <DaveMorris> make a cp of your pkg dir incase you make a mistake
[20:56] <HighNo> DaveMorris: I guess that's why everybody loves it?!
[20:56]  * sistpoty doesn't *g*
[20:56]  * jpatrick does
[20:57] <ScottK> sistpoty: Sure
[20:57]  * HighNo starts a flame war?
[20:57] <DaveMorris> then in the package base, use the command cdbs-edit-patch <patch-name>.patch
[20:57] <sistpoty> HighNo: the only answer is vim *g*
[20:57] <DaveMorris> then make the changes required to the file, and exit using ctrl + D
[20:57] <albert23> nxvl_work: maybe there is a debian/control.in file
[20:58] <HighNo> DaveMorris: is the patchname to obey a naming policy?
[20:58] <DaveMorris> the patch is created in debian/patches
[20:58] <nxvl_work> albert23: oh i haven't notice it, thanks :D
[20:58] <DaveMorris> I tend to number them, and have a short description of the change
[20:58] <albert23> nxvl_work: that caught me a few times as well :-)
[20:59] <DaveMorris> maybe 01-patch-bluetooth-module-for-hardy.patch
[20:59]  * nxvl_work HUGS albert23
[20:59] <HighNo> DaveMorris: thx, i'll try
[20:59]  * albert23 hugs nxvl_work back
[20:59] <slangasek> cdbs patches are easy because cdbs's simple-patchsys is only used by people who have easy patches; it scales like a bivalve climbs a mountain :-P
[21:00] <sistpoty> heh
[21:00] <ScottK> slangasek: Are you a quilt fanboy?
[21:01] <ScottK> I've got a question about it I've been looking for someone to answer
[21:01]  * sistpoty prefers a VCS, but debian(ubuntu) games only allow changes inside debian/
[21:01] <slangasek> ScottK: you could say that
[21:01] <DaveMorris> HighNo: I'll have to grab a backport for gutsy and use this at work, save me locking my session as I walk away
[21:02] <ScottK> slangasek: OK.  One workflow I use somewhat frequently is to figure out a fix, make a diff, then fire up dpatch-edit-patch or cdbs-edit-patch (as appropriate), throw the diff into the chroot, exit, and bang I have my patch.  Is there a near equivalent for quilt?
[21:03] <slangasek> ScottK: so you've prepared your patch already, external to the package, and just want to suck it into quilt?
[21:04] <ScottK> I guess that's one way to look at it.  *-edit-patch is like a qa buffer to make sure I get something that will apply when I build the package.
[21:04] <slangasek> oh.  well, to just import the patch, you can use quilt push -a && quilt import -P <name-to-use-in-quilt> <existing-patch>
[21:05] <slangasek> then quilt push again to make sure it really applies
[21:05] <slangasek> all this assumes you have QUILT_PATCHES=debian/patches (or wherever it needs to point) set correctly in your environment
[21:05] <ScottK> Ah.  That's sounds like it.  Right.
[21:06] <ScottK> I've only used quilt a few times.  I think I would like it if I used it more so it was more natural, but that was the one bit I was missing.  Thanks.
[21:06] <slangasek> 'quilt fold' seems to be an option that would let you pull a patch on stdin into the current patch and apply it, but I've never used that option and can't vouch for its sanity
[21:07] <slangasek> (that then would be quilt push -a && quilt new <name> && quilt fold < <existing-patch>)
[21:09] <ScottK> slangasek: Thanks.  I've copied that into one of my notes files and I'll fiddle with it next time I hit a quilt package.
[21:09] <slangasek> ok, enjoy :)
[21:13] <HighNo> DaveMorris: grrr, had my changes made, saved, then typed 'exit' -> no patch created. does exit exit with an errorlevel != 0?
[21:13] <DaveMorris> I guess so
[21:13] <DaveMorris> you can make your changes external, and copy them into the `cleaned environment'
[21:20] <slangasek> no, 'exit' alone exits 0
[21:27]  * HighNo is ashamed because he can't read properly
[21:28] <HighNo> the patch was there already
[21:29] <HighNo> ok, should I just repackage it and the patch is applied automatically
[21:29] <HighNo> ?
[21:29] <DaveMorris> you need to include a line in your rules file
[21:30] <DaveMorris> include /usr/share/cdbs/1/rules/simple-patchsys.mk
[21:30] <HighNo> DaveMorris: ok, dh_applypatch or something like that?
[21:30] <HighNo> ah, ok
[21:35] <HighNo> hm, now how do I repackage it in a way that won't slow down the approval process?
[21:38] <DaveMorris> just do it as normal and I'll check it over
[21:38] <HighNo> ok
[21:42] <HighNo> DaveMorris: the new package just made it into REVU - now for the 10 minute cool down phase... :-)
[21:46] <sistpoty> HighNo: your package is not kde4-style-bespin, is it?
[21:48] <HighNo> sistpoty: no, it is 'blueproximity'
[21:49] <sistpoty> HighNo: ah, k... should be up on revu already (at least it's not in the queue)
[21:49] <HighNo> but I just got a message from 'bounces@canonical' telling me my package has been rejected - where does that come from?
[21:50] <jpatrick> HighNo: you probably uploaded to ubuntu...
[21:50] <sistpoty> HighNo: you uploaded to the archive instead of to revu, I guess (dput revu changesfiles=
[21:50] <ScottK> HighNo: That means you tried to upload to ubuntu
[21:50] <HighNo> http://pastebin.com/d5dec2538
[21:50] <HighNo> doh
[21:50] <ScottK> HighNo: It's harmless, but to try to avoid it.
[21:50] <HighNo> I forgot to change the dput default destination
[21:51] <sistpoty> anyone knows, to whom the key 3AA736D6 belongs? (can't find it on the ubuntu keyserver)
[21:51] <HighNo> ScottK: sistpoty: DaveMorris: OK, now the package went to REVU :-)
[21:52] <ScottK> We've all done that at least once I think.
[21:52] <HighNo> I consider that to be training for my later MOTU being :-)
[21:52] <ScottK> sistpoty: It's not on the MIT keyserver either.
[21:52] <DaveMorris> it's when you have permission to upload to there and do it
[21:53] <sistpoty> ScottK: hm... then I'll just nuke the upload (binary upload with that key)
[21:53] <ScottK> Sounds reasonable to me.
[21:53] <jpatrick> sistpoty: smarter
[21:53] <jpatrick> (says google)
[21:53] <sistpoty> jpatrick: thanks
[21:53] <sistpoty> smarter: please upload only source packages to revu, not binary ones
[21:55] <smarter> sistpoty: sorry, I probably pressed tab 2 times instead of one ;)
[21:56] <sistpoty> smarter: no problem, just that you know that your upload won't make it ;)
[21:57] <sistpoty> HighNo: should be up on revu (out of order run of move_uploads ;))
[22:00] <HighNo> sistpoty: ??? ahhh, got it. It is so cool to have a package without a trailing zero at the timestamp :-)
[22:01] <sistpoty> heh, /me always wanted to find out how to manually trigger the upload processing (strange enough I wrote the script once, and even added the cronjob, but I didn't recall that w.o. looking)
[22:01] <geser> sistpoty: http://pgpkeys.pca.dfn.de/pks/lookup?search=0x3AA736D6&op=vindex
[22:01] <Coper> Anymore MOTU that can review my package console-freecell
[22:01] <sistpoty> thanks geser: already clear :)
[22:01] <sistpoty> +ed
[22:05] <ScottK> Coper: Did it get advocated?
[22:05] <Coper> ScottK: I got one. :)
[22:06]  * ScottK will look at console-freecel.
[22:06] <Coper> sistpoty: I change the link to GPL-2 becurse a comment in the review.
[22:11] <sistpoty> Coper: neither GPL-2 nor linking to GPL is wrong from a copyright POV (it falls under *GPL-2* but can also distributed under any later version)
[22:11] <warp10> My package gbemol (a graphical frontend for MPD) http://revu.ubuntuwire.com/details.py?package=gbemol is on REVU waiting for reviews.
[22:12] <sistpoty> Coper: so as I wrote, it's really a personal preference
[22:13] <sistpoty> Coper: in other words: if the sources is *only* GPL-2 then you'll need to put the link to that file, but not the other way round ;)
[22:13] <DaveMorris> HighNo: commented
[22:16] <ScottK> Coper: Congratulations.  Uploaded.  Thank you for your contribution to Ubuntu.
[22:16] <KenSentMe> I have an inconcistancy for installed webcam apps. Cheese goes in the Accessories menu, xawtv in Sound and Video and Camorama in graphics. What is the best place to report this so a unified menu folder is used?
[22:16] <ScottK> KenSentMe: File one bug and use 'also affects' to mark the bug against all of them.
[22:17] <KenSentMe> ScottK, ok, will do
[22:19] <Coper> ScottK: Wohoo time for celebrating.. :)
[22:20] <sistpoty> congrats, Coper!
[22:20] <Coper> What do you mean by install upstream changelog?
[22:21] <ScottK> Coper: The file Changelog isn't in the binary package.  It should be.
[22:23] <Coper> okey, so it should be added to /usr/share/doc/<package>/changelog?
[22:23] <ScottK> Yes
[22:23] <ScottK> Coper: I don't feel you need to worry about another upload for that just now.  Just keep it in mind for when you next need to touch the package.
[22:28] <sistpoty> meh... /me hates incomplete debian/copyright notes (even if these would not harm redistribution, due to missing only BSD stuff)
[22:29] <ScottK> sistpoty: It'd still get rejected by an archive admin.
[22:29] <ScottK> All the licenses listed is a must.
[22:29] <sistpoty> ScottK: sure, because nvidia-settings (source) will end up in new *g*
[22:29] <ScottK> Ah
[22:30] <sistpoty> and its debian/copyright (unstable version) is far from exhaustive *g*
[22:33] <geser> HighNo: blueproximity commented
[22:33] <DaveMorris> HighNo: suggestion for your program, have a checkbox so you can make it easily launched on startup
[22:34] <HighNo> thx, I'll look into it
[22:37]  * DaveMorris has now learnt you can use the desktop-valadiate tool
[22:39] <HighNo> DaveMorris: the only line that is beyond 80 chars is the depends line - how can add line breaks there?
[22:39] <DaveMorris> I'm sure I've done it in my opensg package, let me check
[22:39] <geser> HighNo: it's RFC822 format
[22:40] <geser> indent with spaces
[22:40] <DaveMorris> yeah, what geser said :)
[22:40] <sistpoty> heh, even nowadays 80 lines is s.th. I very much want to have in source files, because I then can do a vsplit on every file with my resolution *g*
[22:41] <smarter> Is requestsync borken in hardy?
[22:41] <HighNo> ok, i didn't find good information on the doc-base stuff regarding html and png files. Can I add two entries, one for html and the other one for png?
[22:41] <smarter> "socket.error: (113, 'No route to host')"
[22:41] <DaveMorris> Can someone please revu this package so we can close some bugs which have been open since feisty http://revu.tauware.de/details.py?package=gtkglextmm
[22:41] <sistpoty> DaveMorris: is this already present in the archive? if so, is it a new upstream version?
[22:42] <DaveMorris> well, it's in Edgy, but nothing since
[22:42] <DaveMorris> but it's a new version compared to the one there
[22:43] <sistpoty> ok, I'll take a look in a few minutes
[22:43] <DaveMorris> cheers
[22:46] <Coper> I was reading on a page about sending a new package to ubunut and after I got 2 MOTU to review the package I should change status in LP. anyone know what page that was?
[22:46] <HighNo> hm, what does lintian try to tell me with wrong-name-for-upstream-changelog?
[22:47] <geser> smarter: shouldn't be
[22:47] <HighNo> Coper: sounds like the Ubuntu wiki packaging howto entry
[22:47] <DaveMorris> I think because you have it all in caps
[22:47] <ScottK> Coper: Your (LP: #nnn) entry will close the bug.
[22:47] <DaveMorris> prob should of been Changelog
[22:47] <smarter> geser: how does it know my smtp server?
[22:47] <smarter> geser: I tried with --lp too and I got: "launchpadbugs.bughelper_error.LPUrlError: 'An internal server error occurred. Please try again later. (url: https://bugs.launchpad.net/ubuntu/+source/plptools/+filebug-advanced)'"
[22:47] <Coper> ScottK: okey, so I don't have to change anything?
[22:48] <geser> either you set DEBSTMP or it uses the default (fiordland.ubuntu.com)
[22:48] <ScottK> Coper: Shouldn't.
[22:48] <HighNo> DaveMorris:  hm, should I change the name in upstream itself or does a patch fix that?
[22:48] <HighNo> DaveMorris: (I would change that in upstream for future versions anyway)
[22:49] <DaveMorris> well since you are upstream, might be easier to do it
[22:49] <geser> smarter: I've no sync request right now to test it myself
[22:50] <smarter> geser: I use -s to request sponsorship
[22:50] <HighNo> DaveMorris: Funny, I thought about fixing the other bug in upstream too - until you suggested using a patch for it to keep the timeline :-)
[22:51] <DaveMorris> well I thought you'd wanna use the same original source for the different versions of Ubuntu
[22:51] <HighNo> Does RFC822 need an additional single dot line or is the end of indention enough?
[22:52] <HighNo> DaveMorris: yes, but my changes are made in a way that would work with both variants :-)
[22:52] <DaveMorris> ahh, I didn't relaise
[22:52] <HighNo> DaveMorris: actually tries to import both but counts the number of successes. if less then 1-> error
[22:55] <geser> HighNo: end of indention is enough (like in email headers)
[22:56] <sistpoty> DaveMorris: gtkglextmm was dropped from debian, why should we restore it?
[22:56] <crimsun> in short, new version.  maintained.
[22:57] <sistpoty> crimsun: what needs it?
[22:57] <DaveMorris> was dropped due to FTBFS in rc and the mainator was MIA.  The are multiple requests for it's reinclusion and this version is working
[22:57] <crimsun> sistpoty: apparently something (s)he's using.
[22:57] <DaveMorris> bug #104804
[22:57] <ubotu> Launchpad bug 104804 in gtkglextmm "gtkglextmm-1.2.0 is missing in feisty" [Wishlist,In progress] https://launchpad.net/bugs/104804
[22:57] <sistpoty> DaveMorris: seen that one... but there is no rationale why we should ship it again
[22:58] <geser> smarter: requestsync --lp -s works for me without problems
[22:58] <DaveMorris> sistpoty: but whats the rationale for not shipping it?
[22:58] <smarter> geser: strange...
[22:58] <sistpoty> DaveMorris: oh, looked at a different bug... *looking*
[22:59] <sistpoty> DaveMorris: ok, enough rationale in this bug report... looking at the candidate
[23:00] <smarter> geser: are you running hardy?
[23:00] <DaveMorris> note I'm not closing that bug, since thats for it to be in Feisty, which would be done with a backport
[23:00] <geser> smarter: yes
[23:01]  * DaveMorris is finding Hardy very very good on his laptop
[23:01] <DaveMorris> I might upgrade my work desktop soon
[23:02] <ScottK> DaveMorris: You should close that bug as we mark bugs fix released when fixed in the developmental release.  Then we open tasks against earlier releases if appropriate.  In this case, after it's fix released, I'd use also affects project to add feisty-backports and gutsy-backports to the bug.
[23:02] <DaveMorris> ScottK: I opened a new bug for it, just seemed wrong to close that bug when it gets into Hardy
[23:03] <HighNo> Hm, can anyone tell me why I have a 'files' file in debian dir - and what it dows there since it has only nonsense content
[23:03] <ScottK> DaveMorris: What I'm describing to you is standard Ubuntu bug policy.  I understand what you are saying, but that's not Ubuntu policy.
[23:04] <DaveMorris> I'll try and remember that for future (even though I don't fully understand it atm - I should think about it for a bit)
[23:05] <sistpoty> DaveMorris: did you do an ABI check on the library?
[23:06] <DaveMorris> no, how do you do that?
[23:07] <DaveMorris> also what does ABI stand for in this context?
[23:08] <sistpoty> DaveMorris: since there is a feisty version with the same SONAME, you must ensure that the ABI didn't change
[23:08] <geser> ABI: Application Binary Interface
[23:08] <sistpoty> DaveMorris: https://wiki.ubuntu.com/MOTU/School/LibraryPackaging should give you clues on ABI and how to check it
[23:08] <azeem> didn't change in an incompatible way, anyway
[23:09] <DaveMorris> azeem: you've already checked it then?
[23:09] <sistpoty> azeem: can you guarantee? (if so, I won't do an abi check myself for reviewing *g*)
[23:12] <azeem> no, I just said that you should check for incompatible ABI changes, not any kind of ABI changes
[23:12] <sistpoty> heh
[23:13] <sistpoty> DaveMorris: you debian/rules seems strange (from looking at the diff so far): you seem to call configure outside of any rule?
[23:14] <sistpoty> heh, no... confused by .diff.gz *g*
[23:14] <DaveMorris> tbh I just took the packaging from the Edgy version,\changed the bits requiring it
[23:15] <DaveMorris> seemed the path of least resistance at the time
[23:15] <sistpoty> sure, makes sense
[23:19] <DaveMorris> the ABi stuff makes sense, and I'll run through the examples since I've only packaged libs so far :)
[23:20] <sistpoty> :)
[23:21] <DaveMorris> and I'll have to remember it for the libs we build at work
[23:22] <HighNo> hm, in a desktop file, Categories: Application;Utility <- Application is deprecated? What should I use in exchange?
[23:22] <sistpoty> !desktop file
[23:22] <ubotu> Sorry, I don't know anything about desktop file - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[23:22] <sistpoty> grml
[23:27] <vemon> i'm attaching a patch to an ubuntu package to launchpad bug. i know that when adding new upstream versions i upload the .diff.gz resulting from "debuild -S -sa" but is it the same when the upstream version stays the same but i've just added a patch?
[23:27] <sistpoty> HighNo: see http://standards.freedesktop.org/desktop-entry-spec/latest/
[23:27] <HighNo> sistpoty: thx
[23:27] <RAOF> vemon: In that case, you just want to add a debdiff
[23:27] <vemon> ok
[23:28] <RAOF> vemon: As generated by "debdiff <oldpackage> <newpackage>"
[23:28] <vemon> and the package in your example is a .dsc file?
[23:28] <RAOF> debdiff accepts quite a number of ways to specify <package>, but I generally use the .dsc, yes.
[23:29] <vemon> thanks!
[23:36] <sistpoty> DaveMorris: the good news so far: your version changes the SONAME (so we don't need to care about ABI incompatibilities)
[23:37] <sistpoty> DaveMorris: the bad news: you need to adjust the (binary) package name of the library package
[23:37] <DaveMorris> to what?
[23:38] <geser> DaveMorris: increase the SONAME in the package name so it matches the library
[23:39] <DaveMorris> sorry, I meant, what has the SONAME changed to?
[23:39] <geser> DaveMorris: check in the library
[23:39] <sistpoty> objdump -p <shared object> | grep SONAME
[23:40] <DaveMorris> yeah, I've used that before to track down missing symbols
[23:42] <DaveMorris> so you suggest changing the package name so it doesn't seem to have any relation to the source package name.  Source package name is gtkglextmm and soname is libgtkglext-x11
[23:42] <slangasek> DaveMorris: there's no number in the soname field?
[23:43] <DaveMorris> yeah, a -1.0
[23:43] <sistpoty> DaveMorris: no, -x11 is not in either SONAME
[23:43] <slangasek> that's the principal problem
[23:43] <sistpoty> and actually, there are *two* shared objects in the library package
[23:43] <DaveMorris>   SONAME      libgdkglext-x11-1.0.so.0
[23:43] <sistpoty> DaveMorris: oh, right
[23:43] <slangasek> if that were the only lib in the package, the customary package name would be libgdkglext-x11-1.0-0
[23:44] <vemon> just uploaded a patch which adds LASH support for ZynAddSubFX: https://bugs.launchpad.net/ubuntu/+source/zynaddsubfx/+bug/180967. Any motu's care to take a look at it? :)
[23:44] <ubotu> Launchpad bug 180967 in zynaddsubfx "ZynAddSubFX has no LASH support" [Undecided,Confirmed]
[23:44] <DaveMorris> there is that and libgtkglext-x11-1.0.so.0
[23:44] <vemon> already subscribed to the sponsors queue
[23:44] <slangasek> the most important thing isn't to make the package name match the soname, though; it's to make sure that there's a 1:1 mapping between library ABIs (=SONAMEs) and package names
[23:44] <slangasek> so when the soname changes, the package name should also change
[23:45] <DaveMorris> ok, will people be able to find these though when they search for `gtklextmm' ?
[23:46] <slangasek> if that's a string that people are likely to be searching for, perhaps you can put it in the package description?
[23:47] <DaveMorris> ok I'll sort that out now
[23:48] <slangasek> DaveMorris: so I'm confused about something. if this is "gtkglextmm", why are the sonames the same as for "gtkglext"?
[23:50] <DaveMorris> gtkglext is the C bindings, these are c++ bindings
[23:50] <slangasek> yes, so why do they have the same soname?
[23:50] <DaveMorris> one has the mm in there the other doesn't
[23:51] <slangasek> oh? the soname you cited didn't mention 'mm'
[23:53] <DaveMorris> the c++ ones are libgtkglextmm-x11-1.0.so.0 and the C ones are libgtkglext-x11-1.0.so.0
[23:53] <slangasek> ok, so libgtkglextmm-x11-1.0-0 is the most appropriate name for the C++ bindings
[23:54] <slangasek> in which case, a search for 'gtkglextmm' will definitely match
[23:54] <DaveMorris> hmm, just checked the Edgy package, and that had sonames the same (different version though) both in the same package name as what I have here
[23:55] <slangasek> what package name is that?
[23:56] <sistpoty> hm... the new sonames are actually libgdkglextmm-x11-1.0.so.0 and libgtkglextmm-x11-1.0.so.0
[23:56] <DaveMorris> also the C bindings both seem to be in the package libgtkglext1 and libgtkglext1-dev
[23:57]  * DaveMorris is confused
[23:57] <slangasek> ok, since that's the soname that was used for a previous version of the package in the archive, it's best to restore that same soname
[23:57] <slangasek> sorry, s/soname/package name/
[23:57] <sistpoty> DaveMorris: sorry, /me was confused, wrong shell
[23:57] <geser> DaveMorris: the -dev package is only needed during build, so it's ok (unless there is a packaging error)
[23:58] <sistpoty> the new ones are libgdkglextmm-x11-1.2.so.0 and libgtkglextmm-x11-1.2.so.0
[23:59] <DaveMorris> currently the package libgtkglext1 on gutsy (C bindings) contains libgtkglext-x11-1.0.so.0 and libgdkglext-x11-1.0.so.0