[02:04] <CarlFK> "If you have a dvgrab binary which is linked against a libraw1394 v1, then it won't use libraw1394 v2"  how do I tell if it is that ?  or, I have the source.  how do I make it use v2?
[02:08] <jmarsden> CarlFK: ldd /path/to/dvgrab  # will show you what it is linked against
[02:11] <CarlFK> $ ldd /usr/bin/dvgrab |grep raw1394
[02:11] <CarlFK> 	libraw1394.so.11 => /usr/lib/libraw1394.so.11 (0x00682000)
[02:11] <CarlFK> 	libraw1394.so.8 => /usr/lib/libraw1394.so.8 (0x004b2000)
[02:11] <CarlFK> so that looks like the "wont use v2" case, right?
[02:12] <CarlFK> .8 is v1, .11 is v2 (i think...)
[02:12] <directhex> your numbers are correct
[02:26] <CarlFK> building dvgrab deps on libavc1394-dev, which deps on libraw1394-8... how can I tell the build process to ignore libraw1394-8 and use -11?
[02:29] <directhex> an interesting packaging conundrum!
[02:33] <CarlFK> mak'n me grumpy
[02:34] <directhex> there's one way. it's messy though
[02:35] <directhex> you can generally force autofoo variables by passing them to configure
[02:35] <directhex> i.e. if there's an AC_PATH_PROG check which stores in the FOOBAR variable, then ./configure FOOBAR=baz works
[02:35] <RAOF> But that won't work, surely.  You'll have two different ABI-incompatible versions of libra1394 trying to load in the same process.
[02:35] <directhex> so you can force the variable which defines the includes for libraw, to essentially hide the v1 include
[02:37]  * RAOF reads some more scrollback, and is surprised that dvgrab works.  Clearly, he is insufficiently awesome at ELF semantics.
[02:38] <directhex> happy little ELF!
[02:59] <directhex> okay, 3am means sleeps
[03:34] <MTecknology> Any ideas how to fix this? http://pastebin.com/m79b8c728
[03:34] <MTecknology> not a motu question really, but you guys are smart :)
[03:36] <Hobbsee> MTecknology: install libx11-dev for a start
[03:37] <RAOF> MTecknology: Really, really not a motu question, but "apt-file search xft.pc" will be useful for you.
[03:38] <RAOF> The makefile is very considerately telling you what packages you need to install, too.
[03:38] <RAOF> Also, howdie Hobbsee.
[03:39] <Hobbsee> heya!
[03:39] <MTecknology> Hobbsee: RAOF: thanks ;)
[03:40] <MTecknology> :)*
[03:40] <MTecknology> make file doesn't have anything in it - I'm running apt-file update atm
[03:41] <RAOF> I mean: the makefile is telling you what it needs: "package x11 not found... directory containing 'x11.pc'"
[03:41] <MTecknology> oh
[03:42] <RAOF> Man, we should totally see if the awesome font guy would be willing to licence some of his fonts under a free license.  Museo Sans makes an excellent desktop font.
[03:43]  * RAOF is aware that statement lacked precision.
[03:43] <MTecknology> RAOF: I installed the package it listed but still have that error
[03:43] <MTecknology> libx11-dev fixed the other
[03:44] <RAOF> You've installed libxft-dev, right?
[03:44] <MTecknology> ya
[03:44] <RAOF> Want to pastebin the build error again?  It really should be different :)
[03:45] <MTecknology> doh....
[03:45] <MTecknology> I did something really moronic
[03:46] <MTecknology> I have this now - http://pastebin.com/m5b590c21
[03:58] <RAOF> MTecknology: apt-file search X11/StringDefs.h -> libxt-dev
[03:59] <RAOF> apt-file.  It's your one-stop "what package do I need to install to make this build" shop.
[04:01] <MTecknology> thanks :)
[04:01] <MTecknology> more errors, but it builds now - that's what I care about :P
[04:01] <MTecknology> appreciate the help :)
[04:19] <StevenK> invalid conversion from 'void*' to 'GtkWidget*'
[04:19] <StevenK> Bah
[04:20] <StevenK> But it's just a pointer?
[04:22] <RAOF> Unless it's a magical different-sized pointer?
[04:22] <RAOF> Or unless it's a pointer with a different stride?
[04:23]  * RAOF forgets some of that detailed C knowledge.
[04:27] <StevenK> RAOF: Different stride?
[04:29] <RAOF> I think I was mis-remembering.  I was thinking "how many bytes does pointer++ move by", and architectural alignment restrictions, and stuff.
[04:30] <StevenK> A pointer is a pointer?
[04:30] <RAOF> Not always?  I mean, you can't do void * arithmetic?
[04:31] <StevenK> You can have maintainable code, or you can have pointer arithmetic
[04:31] <RAOF> Heh.
[04:32]  * StevenK adds an explicit cast
[06:07] <fabrice_sp> Good morning
[06:08] <fabrice_sp> a 'morning' question: a bug report I sent to debian has been closed on the 13th, with a new version of the package, but it's not yet in Ubuntu. The autosync wasn't supposed to run on a daily basis?
[06:09] <ajmitch> no, it is run manually by an archive admin
[06:09] <ajmitch> especially around alpha freeze time
[06:10] <fabrice_sp> ohhh. I really thought it was a kind of cron job or similar... I'll wait then. Thanks!
[06:21] <dholbach> good morning
[06:33] <fabrice_sp> Hey dholbach
[06:33] <dholbach> hiya fabrice_sp
[06:38] <fabrice_sp> dholbach, by the way, Debian adopted the changes to solve Bug #384936, but they didn't put any Replaces in the control file...
[06:38] <fabrice_sp> when this package will be synced, I'll close the bug report
[06:38] <dholbach> fabrice_sp: is there files that are moved from one package to the other?
[06:40] <fabrice_sp> dholbach, yes: the solution is the same as the one I gave (moving /usr/lib/gmerlin/plugins from gmerlin to libgmerlin0 package)
[06:40] <fabrice_sp> clearly, he should have added it
[06:41] <dholbach> fabrice_sp: just drop them a quick email or follow up on the bug report - it should be easy for them to still add it :)
[06:41] <fabrice_sp> ok: will do :-) Thanks
[06:41] <dholbach> rock!
[06:41] <dholbach> hiya ara!
[06:42] <ara> hey dholbach
[07:51] <jmarsden> If upstream accidentally includes a .o file in their source tarball, what is the best way to handle things -- aside from waiting until their next tarball release?
[07:52] <geser> remove it in the clean target to it gets rebuild
[07:52] <lifeless> jmarsden: is it accidental ?
[07:52] <lifeless> jmarsden: or deliberate
[07:53] <jmarsden> I'll ask to be sure, but I'm fairly sure it is accidental.  The source .cpp is there for it...
[07:54] <lifeless> then as geser says, though that will cause 'unrepresentable changes' to turn up.
[07:55] <jmarsden> OK, thanks.
[08:26] <siretart> revu is back now, sorry for the inconvenience
[09:02] <wlx> How should do with the wrong directory layout? I want to create a package for ncview(http://meteora.ucsd.edu/~pierce/ncview_home_page.html), the source .tar.gz include three sub-directories, what I want to do is on one of them(the ncview-1.93g directory)
[09:09] <siretart`> wlx: talk to upstream to release 2 or 3 tarballs then?
[09:10] <wlx> siretart, ok, I will try that. thanks.
[09:10] <wlx> and no any other technical method to deal this case?
[09:14] <siretart`> wlx: of course there are, you could repackage the tarball yourself. In most cases, upstream has reasons for that, and the fact that you're asking indicates that you don't understand them
[09:16] <wlx> siretart, if I repackage the tarball myself, where should I indicate it in the debian directory?
[09:18] <siretart`> wlx: the debian directory should not go into the tarball, but in the .diff.gz
[09:20] <wlx> siretart, yes, I know that. I mean in which file I could told other people what I do.
[09:21] <siretart`> wlx: I thing the developer's reference recommends debian/README.source
[09:22] <siretart`> wlx: and I find it convenient to provide an get-orig-source target in debian/rules that actually does the tarball remangling. For more complicated package I write that make target to call a script debian/get-orig-source.sh. Shell is often easier to implement that
[09:23] <AnAnt> is there something wrong with packages.ubuntu.com ?
[09:24] <Hobbsee> AnAnt: no.  and we don't run it, btw
[09:24] <AnAnt> Hobbsee: ?
[09:24] <AnAnt> Hobbsee: who runs it
[09:24] <AnAnt> Hobbsee: try searching for byobu on packages.ubuntu.com
[09:25] <Hobbsee> Please contact Frank Lichtenheld if you encounter any problems!
[09:25] <Hobbsee> third line down, on the page
[09:26] <Hobbsee> AnAnt: it comes up correctly.
[09:27] <Hobbsee> er, almost correctly
[09:27] <AnAnt> ?
[09:27] <AnAnt> Hobbsee: I get, that it does not exist
[09:27] <Hobbsee> wonder where the binaries are for that, in karmic
[09:27] <AnAnt> Hobbsee: actually for any search I don't get results for intrepid, jaunty, nor karmic
[09:28] <Hobbsee> AnAnt: are you looking in jaunty?  it's a new addition to karmic.
[09:28] <Hobbsee> if you search by source, it's there
[09:28] <Hobbsee> not by binary, for some reason
[09:28] <trip0-nb1> in the control file, should the src package depend on all the build deps of the package (ie libgtk2.0-dev) ?
[09:28] <AnAnt> ah, that's the problem them
[09:29] <Hobbsee> the lack of binaries shown there is a bug, though
[09:29] <Hobbsee> and would be worth contacting Frank for
[09:29] <AnAnt> probably, it's a temp. problem
[09:30] <AnAnt> thanks
[10:17] <kmdm> Anyone around who I can /msg to check if a security bug has already been raised against a package before I log it?
[10:20] <lifeless> just log it
[10:20] <lifeless> if its a dup the security team will be able to dup it quickly
[10:28] <kmdm> done, ta. Just thought I'd try and remove dups since it's likely to have a dup given it has a CVE number :)
[11:07] <Jomyoot> does apt-build really improve performance?
[11:08] <Jomyoot> Hello
[11:09] <james_w> probably not for most packages
[11:49] <james_w> the sponsoring queue is huge
[11:50] <james_w> if you have a spare 10 minutes please review something from it
[11:50] <mok0> I'm on the ftbfs list currently
[11:50]  * iulian has just started.
[11:51] <mok0> The sponsoring list is full of crud
[11:51] <mok0> It should be cleaned out
[14:47] <Laney> thekorn: can you comment on bug 387297?
[14:49] <thekorn> Laney: sure, later today when I'm back home
[14:49] <Laney> thanks
[15:02] <rmcbride> Hi! I did a dput of what I thought was a perfectly good python-configglue package to REVU, but it hasn't turned up. Anyone able to fish it out of rejects and give feedback on what I screwed up?
[15:03] <bddebian> Heya gang
[15:53] <james_w> would someone have a couple of minutes to review http://revu.ubuntuwire.com/p/python-oauth please?
[15:53] <james_w> it's another new launchpadlib dependency
[15:53] <james_w> (I think there's just one more after this)
[16:19] <stefanlsd> james_w: what about a get-orig-source rule?
[16:19] <james_w> stefanlsd: true, it should probably have one
[16:19] <james_w> I don't like them much though
[16:20] <stefanlsd> james_w: yeah. you can see my gears rules on revu for one that i did against google code...
[16:21] <james_w> well I've uploaded now :-)
[16:22] <stefanlsd> james_w: kk :)
[16:24] <Laney> james_w: will this allow us to replace manage-credentials?
[16:24] <Laney> (if oauth stuff is in lplib)
[16:24] <james_w> they have oauth stuff now
[16:25] <james_w> I think this is just because they ported to using a library
[16:25] <james_w> rather than making the HTTP calls themselves
[16:25] <Laney> alright
[17:13] <siretart`> is there some special magic I need to do in order to get an entry appear in gnome-panel besides installing the .desktop file into /usr/share/applications?
[17:13] <siretart`> I've isntalled a file there, but it just doesn't want to appear :(
[17:14] <RainCT> siretart`: I think you need to put some file in /usr/lib or something like that
[17:14] <siretart`> RainCT: err, uh?
[17:15] <RainCT> err nevermind
[17:15] <RainCT> I thought you meant an applet :P
[17:15] <RainCT> siretart`: can you paste the .desktop file somewhere?
[17:18] <siretart`> RainCT: sure: http://pbot.rmdir.de/faa426681382140304069f10ee6302ce
[17:19] <RainCT> siretart`: do you have gmplayer installed?
[17:19] <RainCT> siretart`: the TryExec= line is looking if the command "gmplayer -fontconfig" works and only if it does the entry is displayed
[17:20] <RainCT> (s/works/is found and the user has rights to execute it/)
[17:20] <siretart`> oh, that's interesting to know...
[17:21] <james_w> Path to an executable file on disk used to determine if the program is actually installed. If the path is not an absolute path, the file is looked up in the $PATH environment variable. If the file is not present or if it is not executable, the entry may be ignored (not be used in menus, for example).
[17:21] <james_w> so I think it should just be "gmplayer"
[17:21] <james_w> (that's TryExec_
[17:22] <siretart`> okay, I've edited my /usr/share/doc/applications/mplayer.desktop file
[17:23] <siretart`> do I need something else to "activate" the new file?
[17:23] <RainCT> siretart`: it's /usr/share/applications/, not /usr/share/doc/applications/
[17:23] <siretart`> arg
[17:23] <RainCT> hehe
[17:23] <siretart`> yes, it is in /usr/share/applications
[17:23] <siretart`> not in doc
[17:24] <siretart`> http://pbot.rmdir.de/401f39be843eef87448745042ff1936f
[17:24] <RainCT> siretart`: No. It shows up here if I remove the TryExec line
[17:25] <siretart`> hm. I've removed that and it still doesn't for me...
[17:25] <siretart`> wtf?
[17:27] <RainCT>  (btw, the Comment is wrong, it should start with a verb and explains what you can do with the applicaion, eg. "Play movies and songs", and the Name should be more descriptive: "MPlayer Media Player", although this sounds a bit redundant :P)
[17:28] <ivoks> Chritope Sauthier?
[17:28] <ivoks> Christophe
[17:29] <RainCT> ivoks: that's huats, doesn't seem to be online right now
[17:29] <ivoks> ah, thanks
[17:29] <RainCT> no problem
[17:30] <ivoks> what's the procedure with motu mentorship?
[17:30] <ivoks> i have a candidate that's more than good for motu status
[17:30] <ivoks> i've been mentoring him for a month
[17:31]  * RainCT looks at porthose 
[17:31] <james_w> ivoks: if you think they are ready for MOTU then you should encourage them to apply
[17:31] <ivoks> oh, i see
[17:37] <james_w> any REVU admins around?
[17:38] <RainCT> james_w: yes?
[17:38] <stefanlsd> ivoks: https://wiki.ubuntu.com/UbuntuDevelopers has the details of applying
[17:38] <james_w> RainCT: could you find out why the upload of python-configglue isn't showing up?
[17:40] <RainCT> james_w: because the _amd64.changes file was uploaded, instead of _source.changes
[17:40] <james_w> thanks RainCT
[17:40] <james_w> rmcbride ^
[17:41] <rmcbride> ah, thanks both
[17:41] <RainCT> you're welcome
[17:41] <RainCT> oh, and I can tell you now that I don't like the short description of the package :P
[17:42] <siretart`> RainCT: patches against the mplayer packages in karmic welcome :-P
[17:42] <rmcbride> RainCT: I'll update that. Thanks. I also know what I screwed up with my new package workflow.
[17:43] <RainCT> siretart`: aren't you going to upload?
[17:44] <siretart`> I'd love to be able to verify that the .desktop file is working, then I'll commit to git and then upload the beast
[17:45] <RainCT> siretart`: so you can improve the Name and Comment while you're at it ;)
[17:45] <RainCT> (I can also give you Catalan translations for them if you want)
[17:45] <siretart`> RainCT: as said, patches welcome
[17:48] <stefanlsd> Does anyone else have issues with staging.launchpad.net, i get so many timeouts when testing things..
[17:49] <RainCT> siretart`: http://pbot.rmdir.de/5a56874f08049908851c37d6bd3b9efd
[17:58] <siretart`> RainCT: okay, I've installed now that file, but it still doesn't love me
[17:58] <siretart`> I'll continue tomorrow
[17:59] <siretart`> thanks for your file!
[17:59] <RainCT> sure
[19:12] <hemanth> hi , how do i pack a sh file to a deb file ?
[19:15] <directhex> hemanth, by writing a package
[19:15] <hemanth> directhex, did not get u :(
[19:16] <directhex> hemanth, a .deb isn't just a compressed archive. there's lots of other things that go with it. you need to create a source package.
[19:17] <hemanth> directhex, any automated script for doing that , i tried giftwrap didnt work
[19:19] <hemanth> directhex, dh_make is the only go is it ? , i need to create debian related directories and then pack it is it ?
[19:21] <azeem> hemanth: are you trying to contribute to Ubuntu, or is this for your own stuff?
[19:21] <azeem> if the latter, something like checkinstall might work as well
[19:21] <hemanth> azeem, for ubuntu
[19:24] <azeem> hemanth: in that case, there is nothing besides dh_make and/or doing it yourself
[19:25] <hemanth> azeem, ok just to test , i tired checkinstall and it saysmake: *** No rule to make target `install'.  Stop.
[19:31] <azeem> hemanth: maybe it can only do Makefile-oriented packages, dunno
[19:31] <azeem> never used checkinstall myself
[19:31] <hemanth> azeem, ok
[19:47] <hemanth> azeem, i made a sudo checkinstall make install_package , a bed file is ready and is installed , as it's a script there is no effect of the installation, so what is the remedy ?
[20:04] <blizzkid> kirkland: you here?
[20:08] <blizzkid> or anyone else who knows a lot about encrypted Private folder?
[20:19] <azeem> hemanth: as I said, I don't know about checkinstall
[20:20] <Nafallo> blizzkid: how about just asking the question and anyone that might now the answer can shim in.
[20:20] <Nafallo> ?
[20:20] <dupondje> https://bugs.launchpad.net/ubuntu/+source/audacious-plugins/+bug/383307 <- somebody will plz ever accept this :(
[20:20] <blizzkid> Nafallo: you're right :)
[20:21] <blizzkid> I switched from ubuntu to mint as a test, but now when I "ecryptfs-mount-private" I get "ERROR: Encrypted Private is not setup properly"... Is my data lost or is there a solution?
[20:21] <Nafallo> blizzkid: that sounds like a question for #ubuntu to me... this is a development channel.
[20:21] <kirkland> blizzkid: -> #ecryptfs on irc.oftc.net might be best
[20:21] <kirkland> blizzkid: http://blog.dustinkirkland.com/2009/03/mounting-your-encrypted-home-from.html
[20:22] <kirkland> blizzkid: ^ how to access your data from a Jaunty livecd
[20:22] <blizzkid> I'll take a look at that
[20:22] <blizzkid> kirkland: I hope the lack of /var/lib/ecryptfs won't cause me too much trouble?
[20:23] <kirkland> blizzkid: some minor trouble, yes, please ask in #ecryptfs on oftc.  this is *not* the appropriate channel
[20:23] <blizzkid> ok, I'll go there
[20:43] <gaspa> geser: is your code that feed harvest 'ftbfs' column?
[21:00] <Nrrd> stefanlsd: He man, I'm looking at that patch again now
[21:01] <stefanlsd> Nrrd: k. great. The patch applied cleanly. the problem was that the package currently uses a patch system, so when you tried to build the package, it tries to apply patches to the stuff you have modified, and it cant and breaks. Ideally, we want to apply the patch via the patch system...
[21:03] <Nrrd> stefanlsd: that sent my head in circles :) but I kinda get ya, any guesses where I should start looking?
[21:07] <stefanlsd> Nrrd: you want to start by getting the current source. apt-get source blogtk (assuming you have src in your /etc/apt/sources.list) - if not, you can apt-get install ubuntu-dev-tools and run pull-lp-source blogtk
[21:07] <Nrrd> stefanlsd: got the source :)
[21:10] <stefanlsd> Nrrd: ok, great. from there you can see the debian/ directory. beneath that is a patches directory. those patches get applied when the .dsc is built. Have a look here - https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[21:10] <Nrrd> stefanlsd: cool, cheers
[21:12] <stefanlsd> Nrrd: https://wiki.ubuntu.com/PackagingGuide/Howtos/CDBSSimplePatchsys is pretty concise...
[21:21] <rmcbride> Hi again. Would anyone care to review http://revu.ubuntuwire.com/p/python-configure ? I have one advocation already.
[21:29] <james_w> I'm sure rmcbride does know what the name of his package is, but the link should be http://revu.ubuntuwire.com/p/python-configglue :-)
[21:29] <siretart> RainCT: hm. your desktop file doesn't work for me even after a reboot
[21:29] <siretart> is there any way to debug why a .desktop file does not work?
[21:30] <rmcbride> oops
[21:30] <rmcbride> thanks james_w. I have IRC on a seperate other machine than the dev box.
[21:30] <rmcbride> and my brain didn't quite bridge the copy-paste right :)
[21:30] <james_w> heh
[21:31] <RainCT> siretart: and there should be no need to reboot, gnome-panel looks for changed .desktop files all the time
[21:31] <siretart> but why the heck it doesn't for me?!
[21:36] <geser> gaspa: I don't understand your question
[21:38] <bdrung_> is here a motu around, who wants to sponsor a merged package?
[21:38] <gaspa> geser: is this your? http://qa.ubuntuwire.com/ftbfs/source/
[21:38] <geser> gaspa: yes, the code behind is written by me
[21:39] <gaspa> geser: ok, and is the  .csv  in harvest-data your, as well??
[21:40] <bdrung_> can someone have a look at bug #383307?
[21:40] <geser> gaspa: no, I didn't even know about it
[21:41] <gaspa> geser: fine. I was asking if code of both lists is the same.
[21:41] <gaspa> just it
[21:42] <geser> gaspa: the FTBFS page gets its data directly from LP (uses the LP API). you can look at source if you want (see the source link at the bottom of the page)
[21:42] <gaspa> already done ;)
[21:43] <gaspa> geser: I've a couple of ideas to improve your page... do you mind a proof of concept, in the next days?
[21:45] <geser> gaspa: go on, I don't mind. you can branch from https://code.edge.launchpad.net/~geser/+junk/qa-ftbfs if you want
[21:47] <gaspa> geser: ah, cool. thanks.
[21:51] <siretart> RainCT: bah! I had a broken mplayer.desktop file in my ~/.local
[22:00] <RainCT> heh
[22:00] <RainCT> btw, someone remembers what's the website where you can browse and install (with apturl) Ubuntu packages=
[22:00] <RainCT> ?
[22:38] <stefanlsd> RainCT: can you add me as a reviewer on revu please?
[22:41] <RainCT> stefanlsd: done
[22:41] <stefanlsd> RainCT: thanks!
[22:41] <RainCT> no problem :)
[22:41] <ajmitch> RainCT: does that part still have to be done manually?
[22:44] <RainCT> ajmitch: Yes, but it can be done from the web now
[22:45] <RainCT> ajmitch: if you want to write a cronjob or getting it at login time or whatever, patches welcome
[22:46] <ajmitch> :)
[22:56] <thekorn> Laney, I will comment on the bug you mentioned earlier tomorrow, too much text from leonard, I have to think about it a bit more,
[22:57] <thekorn> but you are basically right, manage-credentials can easily be removed from u-dev-tools
[22:58] <Laney> I just meant the --password param, but yeah
[23:35] <RainCT> omg, I already like git more than SVN :/