[00:35] <up_the_irons> hey guys, am I right in seeing that "/usr/bin/man" doesn't appear in any package (in Hardy)?
[00:35] <up_the_irons> dpkg -S /usr/bin/man, does not return any package
[00:36] <up_the_irons> so, how do I get that binary short of copying it from another machine?  is there some "base files" package I should look at?
[00:36] <up_the_irons> I don't know why it wasn't installed on this Xen guest I just created, weird
[00:36] <directhex> man-db: /usr/lib/man-db/man
[00:37] <directhex> lrwxrwxrwx 1 root root 17 2008-08-02 19:28 /usr/bin/man -> ../lib/man-db/man
[00:37] <up_the_irons> ah!
[00:38] <up_the_irons> directhex: thanks, I should checked to see if it was a symlink!
[02:33] <rockstar> Can I get a motu to look at https://bugs.edge.launchpad.net/entertainer/+bug/262235
[02:34] <rockstar> It's actually a bug in a universe package, and I've already gotten the fix.
[02:36] <Hobbsee> hm.
[02:37]  * Hobbsee wonders how that works with https://bugs.edge.launchpad.net/ubuntu/+source/pyclutter/+bug/267478
[02:41] <Hobbsee> oh, right.  hardy only.
[02:44] <Hobbsee> rockstar: editing bug.
[02:45]  * Hobbsee flips more switches for it
[02:47] <Hobbsee> dude, way bad web design for the clutter site :(
[02:48] <Hobbsee> james_w: looks like clutter (if it's the same as pyclutter) is out at 0.8.2?
[02:49] <RAOF> Clutter isn't the same as pyclutter; pyclutter is the python bindings.
[02:49] <RAOF> And there still aren't 0.8 python bindings.
[02:50] <Hobbsee> ahh
[02:50] <RAOF> At least, not on their ftp site.
[02:50] <RAOF> Hobbsee: You wanted the waiting for approval message bounced to you?
[02:50] <Hobbsee> RAOF: no.  just tell me you have it.
[02:50] <RAOF> Ah.  I've got it :)
[02:51]  * Hobbsee loads the queue
[02:51] <Hobbsee> Accepting Results:
[02:51] <Hobbsee> OK: glipper
[02:51] <Hobbsee> RAOF: there you go
[02:51] <RAOF> Woot.
[02:52]  * ajmitch spots a Hobbsee 
[02:52] <RAOF> On closer inspection, I probably don't want to adopt glipper; it appears dead upstream.
[02:52] <Hobbsee> hey ajmitch!
[02:52] <Hobbsee> rockstar: eww.  Yay for completely unhelpful upstream CVS commits!
[02:54]  * Hobbsee glares at http://bugzilla.o-hand.com/show_bug.cgi?id=923#c3 and gives up
[02:55] <ajmitch> Hobbsee: what's the problem there?
[02:55] <Hobbsee> ajmitch: try to extract the patch out.  you'll see.
[02:57] <RAOF> Man.  Is python-gtk ever going to be fixed on hppa?
[02:57] <ajmitch> s/python-gtk/anything/
[02:59] <ajmitch> Hobbsee: you wouldn't be meaning the lack of a visible place to grab the source?
[03:00] <Hobbsee> ajmitch: that too.  but I did find that.
[03:00] <ajmitch> doibg better than me then
[03:00] <Hobbsee> ajmitch: http://clutter-project.org/download.html
[03:00] <Hobbsee> ajmitch: well, it did take me a while to find the menu, too
[03:04] <ScottK> superm1|away: I do have bluetooth, but I haven't used it much.  If someone has a test procedure, I can do it.
[03:05] <ajmitch> Hobbsee: so with that, only took about 5 min to find the patch
[03:05] <ajmitch> no time at all... :)
[03:05] <Hobbsee> ajmitch: heh.  how'd you manage?
[03:05]  * Hobbsee wonders what file it was against.
[03:06] <ajmitch> svn diff -r2770:2771 http://svn.o-hand.com/repos/clutter/branches/pyclutter-0-6 |less
[03:06] <ajmitch> I looked at svn log for commits around that date, this one matched
[03:07] <ajmitch> the changelog entry says which file, too
[03:08] <Hobbsee> didn't seem to exist for me.
[03:08] <ajmitch> pyclutter-0-6 branch, not clutter-0-6
[03:09] <Hobbsee> ahhhh
[03:09] <ajmitch> small but important difference
[03:12] <nxvl> slangasek: ping
[03:17] <slangasek> nxvl: hi
[03:17] <nxvl> slangasek: were are the bugs milestoned for beta?
[03:17] <Hobbsee> nxvl: u-d-a mailing list archives, ftw?
[03:18] <nxvl> Hobbsee: right
[03:18] <nxvl> slangasek: sorry about that
[03:18] <nxvl> :D
[03:18] <nixternal> shh, quit making so much noise
[03:19] <Hobbsee> !visternal | visternal
[03:20] <nixternal> yay, gimme some of that free money!
[04:23] <superm1> ScottK, i know nothing of the bluetooth experience on KDE
[04:23] <superm1> ScottK, i could help wtih a test case on gnome, but the kde one is more important right now as I don't think anyone has done anything there
[04:24] <ScottK> superm1: OK.  Well tell me what needs testing and I'll see what I can do.
[04:24] <superm1> ScottK, attempt to pair an input device and make sure it still works
[04:24] <superm1> ScottK, is there normally a KDE gui tool for doing such things?
[04:24] <ScottK> Yes.
[04:24] <ScottK> Unfortunately all I have to pair with is my phone and it doesn't qualify as an input device.
[04:25] <superm1> ScottK, well that's another use case worth testing though, sending a file to the phone
[04:25] <ScottK> I can do that one.
[04:25] <superm1> i'd actually expect some breakage there too possible since OBEX was a big change from BlueZ 3.x to 4.x
[04:26] <ScottK> superm1: Please send me an email with what needs tested and where to find the packages and I'll try to do it tomorrow.
[04:26] <superm1> ScottK, will do
[04:26] <superm1> ScottK, i might just send a generic call for testing to ubuntu-devel
[04:26] <ScottK> superm1: Send to kubuntu-devel too.
[04:26] <superm1> ScottK, okay will do
[04:26] <superm1> have a good evening then
[04:27] <maccam-sager> i heard that the intel eeprom corruption issue was fixed in git, is the kernel going to be rebuilt soon?
[04:27] <ScottK> Thanks.  Trying to get to bed soon ...
[04:28] <ScottK> maccam-sager: #ubuntu-kernel would be a better place to ask, but I'd say it's a safe bet they'll field that fix as soon as they consider it safe to do so.
[04:28] <maccam-sager> ScottK: ah gotcha. thanks for the info
[04:29] <StevenK> Bah, I was just about to answer him
[04:29] <RAOF> Oh, there is an answer? :)
[04:32] <StevenK> There is.
[04:32] <ScottK> And the answer is?
[04:33] <StevenK> From what I can, it's in unapproved, waiting for beta
[04:33] <StevenK> *can see
[04:48] <Elbrus> just to be sure: a binary-indep rule should not depend on a/the clean rule, right? At least in a PPA the binary-indep is build after binary-arch for i386 and the debian/files is removed by dh_clean removing the information about the binary-arch target...
[04:49]  * Elbrus still tries to build lazarus-ide for i386 in his PPA
[04:49] <RAOF> Elbrus: binary-indep depending on clean: would be utter crack.
[04:50] <RAOF> Or, rather, a translation into what that means is "In order to build the arch-independent package from our built source tree, we must first remove all the binaries we built".
[04:50] <Elbrus> RAOF: thought so, but the maintainer of lazarus does that to remove the build binaries from the tree to put the source in lazarus-src
[04:50] <RAOF> Intriguing.
[04:51] <StevenK> Argh
[04:51] <Elbrus> and I just don't get it to work properly
[04:51] <RAOF> Sorry, why is there a lazarus-src package which is distinct from lazarus.orig.tar.gz, then?
[04:51] <StevenK> Elbrus: If binary-indep is after binary-arch, reorder them in the binary target
[06:19] <rockstar> Hobbsee, I have a patch for the package if you'd like, and I can write a VERY descriptive summary of the problem and the solution.
[06:21] <Elbrus> \me finally succeeded in building PPA build of lazarus-ide on i386... thanks to StevenK.
[06:22]  * Elbrus finally succeeded in building PPA build of lazarus-ide on i386... thanks to StevenK.
[06:22] <Elbrus> :)
[06:57] <dholbach> good morning
[06:58] <iulian> G'morning Daniel.
[06:58]  * iulian yawns!
[06:58] <dholbach> hiya iulian
[06:59] <iulian> How are you this morning?
[06:59] <dholbach> good good - how 'bout you?
[07:00] <iulian> I'm doing good too, preparing for school.
[07:06] <Hobbsee> rockstar: i try to avoid SRUs as much as possible.  But I would suggest adding that to the bug, so MOTU SRU can look at it ;)
[07:08] <geser> good morning dholbach
[07:09] <dholbach> hi geser
[07:19] <k00n> sorry, power cut
[07:21] <Koon> good morning everyone :)
[07:22] <Hobbsee> heya Koon!
[07:49] <didrocks> hi everyone!
[07:51] <geser> apachelogger: Hi, could it be that libsmokeqt4-2-dev (kde4bindings) is missing a dependency on libsmokeqt4-2?
[07:51] <geser> Hi didrocks
[09:15] <huats> morning everyone
[09:30] <didrocks> hi huats :)
[09:30] <huats> hey didrocks
[09:30] <huats> :)
[10:39] <gnomefreak> anyone else having issues setting up gpg key in claws-mail and getting it to work?
[12:45] <sirex`> I'm trying to build binary package of php 5.2.6.
[12:46] <sirex`> I apt-get sourced current source package, then kopied debian derectory to new sources and when I try to run dpkg-buildpackage -rfakeroot on new sources, I got errors about patches.
[12:47] <sirex`> Maybe some one knows how can I avoid it?
[12:47] <directhex> so turn off patches that are no longer needed
[12:47] <directhex> look in debian/patches/
[12:47] <sirex`> directhex: yes, I tried it, removed all patches, but still getting errors:
[12:47] <sirex`> Patch disable_dl_by_default.patch does not remove cleanly (refresh it or enforce with -f)
[12:49] <sirex`> directhex: any suggestions?
[12:49] <sirex`> How can I refresh patchas?
[12:49] <directhex> start again
[12:50] <directhex> and make sure you work on the patch manifest, if php's patchsys uses one (e.g. 00list for dpatch)
[12:50] <sirex`> Running that command again, gives same error.
[12:53] <sirex`> hm, now I getting this: dpkg-source: unrepresentable changes to source
[12:55] <directhex> that's because you didn't start again properly
[12:56] <sirex`> directhex: so I should remove every thing and start again?
[12:56] <directhex> yes
[12:56] <directhex> i have to ask though... what ARE you doing?
[12:56] <directhex> intrepid already has php 5.2.6
[12:57] <sirex`> But now I'm using Hardy.
[12:57] <sirex`> Which has only 5.2.4
[12:57] <directhex> so build the intrepid package on hardy
[12:58] <sirex`> directhex: but how can I get intrepid source package on hardy?
[12:58] <directhex> http://archive.ubuntu.com/ubuntu/pool/main/p/php5/php5_5.2.6-2ubuntu3.dsc
[12:58] <directhex> dget that.
[12:58] <sirex`> directhex: ah, ok, thanks.
[12:59] <highvoltage> sirex`: you could add a source-uri for hardy in your /etc/apt/sources.list file and then apt-get source it
[12:59] <highvoltage> for intrepid, I mean
[12:59] <directhex> you COULD, but it'd probably only lead to confusion in the future
[13:00] <directhex> and confusion is bad
[13:00] <sirex`> Well, I just need newes php version, so I will probably just dget sources from that link.
[13:04] <apachelogger> geser: looks like it, I will address the issue once beta freeze is lifted
[13:06] <slytherin> when is beta freeze supposed to be lifted?
[13:14] <Hobbsee> slytherin: after the beta release...
[13:15] <slytherin> Hobbsee: when is beta release then? I mean what exact time?
[13:15] <Hobbsee> slytherin: "when it's ready".  There is no exact time.
[13:17] <slytherin> Ok. Does beta freeze affect universe packages? Can I attach a debdiff for some bugfix and request for sponsorship?
[13:18]  * Hobbsee thought those questions, and many others, were answered in the beta freeze announcement, which can be found in hte ubuntu-devel-announce archives.
[13:19] <directhex> mailing lists. how debian!
 obviously PEOPLE ARE JUST NOT LISTENING! </theo>
[13:22] <siretart> anyone wants to try out some unstripped (read: mpeg2 encoder enabled) ffmpeg packages?
[13:22]  * siretart is considering uploading them to intrepid, depending on feedback
[13:24] <icf7> I'm packaging a C library. Its symbols (generated by dpkg-gensymbols) contain lots of internal stuff. Do I remove this stuff manually, let it stay or fix upstream(how?)?
[13:25] <siretart> icf7: best is to fix it upstream. non exported functions and variables should be declared static
[13:25] <siretart> icf7: for more complicated cases you probably need to write a linker script
[13:26] <stefanlsd> icf7: not sure if its what u need, but i wrote this and it may help - https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols
[13:27]  * slytherin wonders why all the songs have suddenly started playing at more than normal speed >-(
[13:27] <icf7> siretart: these internal functions are scattered in a lot of helper files, therefore static would hide them from the other code files of the library too, wouldn't it?
[13:27] <slytherin> :-(
[13:28] <siretart> icf7: indeed. in that case, things get more complicated.
[13:29] <icf7> stefanlsd: Thanks. I read parts of it, but I'm now going to read it in-depth. Sorry for my ignorance, I'm used to Java
[13:30] <stefanlsd> icf7: may need some work also. its still very much a draft...
[13:37] <sirex`> /tmp/php/php5-5.2.6/ext/zip/lib/zip_close.c:252: internal compiler error: in adjust_add_sorted_back_dep, at sched-deps.c:1886
[13:38] <sirex`> Is this some thing wrong with code or this is something wrong with build system?
[13:40] <siretart> 'internal compiler error' is pretty clear, isn't it?
[13:42] <sirex`> siretart: no it isn't, actualy I don't understand this message.
[13:43] <sirex`> Does it means, that problem not with source, but with compiler?
[13:43] <siretart> the latter
[13:43] <siretart> err, yes
[13:44] <sirex`> Well, trying one more time, maybo this time it will finish succesfully.
[13:49] <icf7> siretart: As far as I understand, using a linker script is pretty complicated and not common. Is there any other way? How do popular libraries solve this (Don't they have any helper function files?)?
[13:50] <siretart> icf7: careful planning when designing a shared library helps pretty much here
[13:51] <siretart> icf7: you could also experiment with the default visibility flag of gcc. set the default to 'not visible', and mark public and exported functions as such.
[13:52] <icf7> siretart: Thanks, I'll try that
[13:52] <siretart> icf7: but this is again something that really should be done upstream, not in a debian package
[13:54] <icf7> siretart: ok. Is there any chance to get a package with a symbol like stack_create accepted without waiting for upstream? It's a pretty new and small project, I suppose it could take weeks to integrate that
[13:56] <siretart> icf7: not without effords less than comparable to forking upstream, I'd say.
[13:58] <icf7> siretart: Thanks, I'll take that into account
[14:16] <es> Anyone knows how to get the configure option used to build a deb? And what action dpkg-reconfigure do?
[14:17] <slytherin> es: You can download respective source package from repositories, extract the .diff.gz file and check debian/rules file for configure options.
[14:18] <slytherin> es: dpkg-reconfigure is not at all related to it. It helps you reconfigure the application already installed on your machine.
[14:20] <es> slytherin: thanks, about  dpkg-reconfigure I'd like to know what action is taken by a  particular package to manually run them stepby step
[14:21] <es> I'm in the need to try out latest version of sympa the version in the tree  it's old andnot working
[14:21] <slytherin> es: I don't understand
[14:22] <es> slytherin: sorry I reformulate. I wan't to know what dpkg-reconfigure will do toconfigure a package since I'll  have to install from source and I don't want to follow what dpkg-reconfigure normally do for it
[14:24] <slytherin> es: That do I think you can find in the source package in postinst file. But since you are installing from source dpkg-reconfigure won't come into picture unless you explicitely call it.
[14:29] <es> slytherin: thanks, however after apt-get source <package> I still don't see where are stored the configure option used to build
[14:30] <slytherin> es: go the directory that contains extracted source and then debian/rules file
[14:31] <es> slytherin: great thanks!
[14:39] <slytherin> Can anyone please tell me how to setup requestsync?
[14:40] <StevenK> What's to set up? You just run it.
[14:40] <slytherin> StevenK: I tried in past but the bug reports didn't show up on launchpad. So I usually manually copy all the content it creates.
[14:40] <Laney> slytherin: Do you use --lp?
[14:40] <slytherin> Laney: no
[14:41] <slytherin> doesn't it work without --lp?
[14:41] <Laney> It should do, but it uses the email interface then
[14:41] <Laney> --lp uses py-lp-bugs, which I've found to be more reliable
[14:41] <slytherin> Laney: which package contains py-lp-bugs?
[14:42] <slytherin> oops, it is already installed
[14:47] <slytherin> wow, --lp worked. :-)
[15:19] <morgs> I want to upload a package from debian into my PPA. I ran dpkg-source -x *.dsc, then debuild -S -sa - but debsign failed since I'm not the debian maintainer. What do I need to change to use my identity?
[15:19] <cody-somerville> morgs, -kyour.email@address.com
[15:20] <directhex> is it worth getting a pet DD to sign my key?
[15:21] <morgs> cody-somerville: thanks
[15:31]  * RainCT is either going to kill himself or kill Samsung.. argh!!    xDD
[15:33] <huats> nxvl: around ?
[15:47] <norsetto> huats!
[15:47] <huats> norsetto: !
[15:47] <norsetto> gotcha ...
[15:48] <huats> I did it willingly
[15:48] <huats> since you seems a bit unhappy yesterday :)
[15:57] <slytherin> persia: can you please give back jhove - https://edge.launchpad.net/ubuntu/intrepid/+source/jhove/+builds Not sure why it picked up JAVA_HOME as openjdk directory even though it depends on sun-java5-jdk.
[16:00] <bddebian> Heya gang
[16:04] <morgs> How do I upload a package (from debian) into my ppa for both hardy and intrepid?
[16:04]  * norsetto doesn't bow to super master bddebian
[16:05] <slytherin> morgs: launchpad allows copying a source package form one ubuntu release to another.
[16:05] <bddebian> Hrmph :)
[16:05] <morgs> slytherin: using +copy-packages? same as for copying from one ppa to another?
[16:06] <morgs> ah, nice.
[16:06] <morgs> Thanks
[16:06] <smagoun> maybe a dumb question, is there someplace I can search the full source of Ubuntu (Hardy)? For example I want to find the definition of xf86HandleColormaps(...), or I want to find the package that contains gdk_x11_drawable.c.
[16:07] <smagoun> (I don't need help finding these particular things - they're just examples)
[16:07] <slytherin> smagoun: what do you mean by full source?
[16:08] <azeem> unpacked source trees of all the source packages, maybe
[16:08] <smagoun> slytherin: like, all the source in Ubuntu. I could apt-get source every package then just run grep/find, but that sounds like lots of disk/lots of work
[16:08] <azeem> smagoun: the latter (finding files in packages) can be done via apt-file or http://packages.ubuntu.com
[16:08] <azeem> the former not
[16:09] <norsetto> devfil_: any luck with wxwidgets2.6 ?
[16:09] <slytherin> smagoun: I don't think there is any complete source cd anywhere. You can find which package contains particular files from http://packages.ubuntu.com
[16:10] <devfil_> norsetto: pochu is working on it https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.6/+bug/274619 I've seen this bug and so I haven't looked at the code
[16:11] <norsetto> devfil_: ah yes
[16:12] <superm1> smagoun, use apt-file search to look for it
[16:12] <superm1> or packages.ubuntu.com has it
[16:12] <superm1> oh azeem already said that
[16:12] <superm1> my bad :)
[16:14] <norsetto> devfil_: that would have to be done for wxwidget2.8 too then
[16:15] <devfil_> norsetto: I prefer to see pochu fix firstly in order to do it also in wxwidgets2.8
[16:16] <norsetto> devfil_: yes, thats what I mean
[16:16] <smagoun> azeem slytherin superm1: Thanks all.
[16:16] <devfil_> norsetto: ok ;)
[16:30] <henux> Hello. I am an able Linux programmer with knowledge of computer languages. I am looking for a mentor for me as I would like to try contributing into Ubuntu.
[16:34] <slytherin> henux: it really depends on which are you want to contribute to.
[16:36] <henux> slytherin: i have no idea
[16:36] <henux> slytherin: im just looking for something
[16:36] <slytherin> henux: check the Contributing link in the topic.
[16:37]  * slytherin has to go.
[16:45] <henux> so this crap is truly what you call a mentorship program?
[16:45] <jdong> oh that's a great attitude :)
[16:45] <azeem> henux: I'm sure you can pay for better programs
[16:45] <persia> Bother.  slytherin left.
[16:46] <henux> in the web page there is a message explaining that everyone is given a mentor, then when i ask one you say "take this link, read it, knock yourself off, its fun, i gotta go, bye"
[16:46] <persia> Anyway, I'm not giving back jhove : it FTBFS because ant depends on "default-jre-headless | java1-runtime-headless | java2-runtime-headless", none of which is supplied by sun-java5-jdk, which is why it gets openjdk, and fails.
[16:46] <jdong> henux: umm... he took the time to answer your question, then had to leave for unrelated reasons.
[16:47] <jdong> the links he gave you help YOU figure out what area you'd like to contribute in
[16:47] <jdong> once you have a better idea of that, we can give you more applicable advice.
[16:47] <persia> henux: There is a mentoring program, to which you can sign up, and wait for a mentor to be assigned.  This may take a fairly long time.
[16:47] <henux> okay then i will come back here later and we will see about what comes
[16:48] <persia> henux: On the other hand, if you're interested in something specific, jump right in, and ask questions here, and a variety of people will help you.
[16:48] <henux> i will ask when there is a specific interest
[16:49] <jdong> henux: look forward to that :). Thanks for your interest in contributing!
[16:49] <henux> i joined the channel in the hopes that somebody could have given me pointers, and this one did, and i will read it so we may perhaps discuss about this later on
[17:03] <iulian> Hi
[17:05] <Allah> hi
[17:05] <es> it's there a way to build from source without a gpg key?
[17:09] <DktrKranz> es: debuild -uc -us
[17:09] <es> thanks
[17:21] <bfiller> general packaging question for anyone: does debian/postinst script get passed any args that it can determine whether the package is being installed for the first time or upgraded?
[17:21] <bfiller> I know preinst gets these args, but does not appear for postinst
[17:22] <bfiller> http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html talked about "configure" and "abort-remove", but not sure about these
[17:25] <persia> bfiller: Heaps of them.  Best resource i know is http://women.debian.org/wiki/English/MaintainerScripts
[17:25] <bfiller> persia: great, thanks
[17:25] <persia> That has nice graphs and stuff, although is otherwise just a restatement of policy.
[17:26] <nxvl> huats: ping
[17:26] <geser> but it's probably easier to understand than the policy
[17:26] <huats> hey nxvl
[17:26] <huats> how are you ?
[17:27] <nxvl> good
[17:27] <nxvl> just come back home
[17:27] <huats> ok
[17:28] <huats> nxvl: regarding the mentoring reception meeting, any prefered time ?
[17:28] <huats> day ?
[17:28] <nxvl> i will prefer from Tue to Thu at 13:00 UTC
[17:29] <nxvl> actually from 13:00
[17:29] <bfiller> persia: looks like from the flowchart that only "configure" is passed to postinst on both install and upgrade (assuming no errors)
[17:30] <persia> bfiller: That's a dangerous assumption, but yes, the common case.
[17:30] <huats> nxvl: ok
[17:30] <huats> (I'll do my best...)
[17:31] <bfiller> persia: so how does the postinst script tell if it's being run during an upgrade as opposed to an install?
[17:31] <nxvl> huats: \o/
[17:32] <persia> bfiller: $2
[17:32] <persia> (it even knows whether it's being upgraded or downgraded, and by how much)
[17:33] <bfiller> persia: ah, $2 is the previous package version or null?
[17:33] <persia> bfiller: It is always the previous package version: null simply indicates the absence of a previous package :)
[17:33] <bfiller> persia: excellent, thanks for the help
[17:59] <ScottK> norsetto: Since you've got amd64 and that seems to be where the issues are, would you mind sorting through Bug 257403 and seeing what we need to do to update it?  Releasing with an old Flash is not a good plan.
[18:00] <directhex> agreed
[18:00] <norsetto> ScottK: I don't use flash myself, but what the guy is saying is that there is a lib missing in ia32-libs
[18:00] <directhex> rc2 is much much better
[18:00] <ScottK> norsetto: Right, but someone who understands this stuff and has amd64 needs to test it.  I've got no amd64.
[18:01] <directhex> oh, is he saying lubcurl is missing?
[18:01] <directhex> because that's true
[18:01]  * directhex checks bug
[18:01] <norsetto> ScottK: oh gosh, you want me to install something that I wouldn't touch with a pole 1 mt long?
[18:01] <ScottK> Just for testing.
[18:02] <ScottK> norsetto: We need someone with amd64 to do it.
[18:02] <norsetto> ScottK: I don't kno why \sh hasn't included that lib, and if that was on purpose
[18:02] <directhex> flash 10 definitely needs libcurl
[18:02] <ScottK> ping \sh ^^^^ ?
[18:02] <ScottK> We'll see what he has to say then.
[18:04] <directhex> wait, hang on... it certainly USED to...
[18:05] <norsetto> ScottK: hmm, I don't think that omission was on purpose, there is no mention of that lib being needed in bug 246911
[18:18] <norsetto> ScottK: this is funny, I don't understand why libgnutls is not picked up by shlibs for libnss-ldap
[18:20] <ScottK> norsetto: I have no idea what the right answer is, but I'm pretty sure you'll have a better shot than me and we (somehow) need to get this sorted before release.
[18:21] <norsetto> ScottK: it is required anyhow, ldd clearly shows it for the stock one
[18:22] <norsetto> ScottK: oh well, what would happen to include that in ia32-libs, beside yet another one that we 64 bit users have to live with?
[18:22] <norsetto> (for the sake of flash, of all things ....)
[18:22] <ScottK> I think it's better to add stuff and be sure than not.
[18:25] <norsetto> ScottK: right, so, I'd rather have \sh look into it since he did the last update, or at least talk with him before I can upload an updated ia32-libs with that myself
[18:26] <ScottK> OK.  We just need to make sure we don't forget it before release.
[18:27] <norsetto> ScottK: np, I'm subscribing to that bug
[18:27] <ScottK> Great.
[18:27] <ScottK> Thanks.
[18:29] <norsetto> ScottK: np
[19:46] <kirkland> DktrKranz: hey, i was trying to fix a trivial manpage bug in kmediafactory, but I can't get it to build for intrepid, depends on libdvdread3-dev, which doesn't exist
[19:48] <DktrKranz> kirkland, did you notice issues with newer libdvdread-dev?
[19:48] <kirkland> DktrKranz: i couldn't get it to build at all in intrepid
[19:48] <DktrKranz> do you have buildlogs available?
[19:48] <kirkland> DktrKranz: checking the build logs, i see that it's not built thus far in intrepid
[19:49] <kirkland> DktrKranz: https://bugs.launchpad.net/ubuntu/+source/kmediafactory/+bug/277200
[19:49] <kirkland> DktrKranz: that has the tail of the build log, just the error
[19:49] <kirkland> DktrKranz: i can rebuild again, and capture the build log
[19:49] <DktrKranz> oh... API change
[19:51] <DktrKranz> kirkland, seems something similar to http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-July/032901.html
[19:51] <kirkland> DktrKranz: hrm
[19:54] <DktrKranz> kirkland, try passing -fno-inline to CFLAGS, just to see it it builds
[19:54] <DktrKranz> but it's definitely ugly
[19:58] <kirkland> DktrKranz: rebuilding....
[20:09] <kirkland> DktrKranz: no luck
[20:14] <DktrKranz> kirkland, I'm leaving for a couple of hours, I'll have a look later
[20:14] <kirkland> DktrKranz: no problem, very, very low priority, as far as i'm concerned
[20:15] <kirkland> DktrKranz: i was just trying to fix a misplaced manpage
[20:18] <asomething> james_w: thanks for the uploads!
[20:18] <james_w> asomething: thanks for the fixes!
[20:19]  * ScottK notes that asomething has an UCD application pending and now that james_w is one of his sponsors, he may want to comment.
[20:20] <james_w> ScottK: ah, thanks
[20:20] <james_w> asomething: drop me links to the bugs that I just sponsored in PM and I'll comment
[20:20] <ScottK> james_w: No problem.
[20:20] <asomething> ScottK: thanks, my app has seemed to have stalled, i could use a little positive feedback =)
[20:21] <asomething>  james_w: will do
[20:21] <ScottK> asomething: Yes, I'd noticed.  Hopefully this will help.
[20:21] <james_w> oh, in fact it's a UCD application
[20:21] <james_w> asomething: forget the bugs
[20:22] <james_w> I need to eat first though
[20:22] <ScottK> Didn't I say UCD?
[20:22] <james_w> you did, I'm just low on calories
[20:22] <ScottK> Ah.  Fair enough.
[20:37] <sebner> kirkland: still around?
[20:41] <kirkland> sebner: hi
[20:42] <sebner> kirkland: hi, do you still plan to do something with bug #243205 ?
[20:42] <kirkland> sebner: yeah, i'll fix it
[20:42] <kirkland> sebner: unless you want it :-)
[20:43] <sebner> kirkland: not if you want ;) at least anyone of us should do it ^^
[20:43] <kirkland> sebner: i need to update the patch
[20:43] <kirkland> sebner: i'll do that and upload tonight
[20:43] <sebner> kirkland: great :)
[20:44] <kirkland> sebner: thx for the reminder
[20:44]  * sebner hugs kirkland :)
[21:03] <fabrice_sp> Hi. I received an email saying that kdenlive didn't build correctly on hppa (http://launchpadlibrarian.net/18102379/buildlog_ubuntu-intrepid-hppa.kdenlive_0.5.svn20071228-0.0ubuntu2_FAILEDTOBUILD.txt.gz). I think that's because missing packages, that don't built on hppa, but can someone confirm that? Thanks
[21:05] <persia> fabrice_sp: I think you want to port to kdelibs5-dev, as I don't think kdelibs4-dev works properly anymore, but I'm not much of a KDE person.
[21:07] <persia> fabrice_sp: I think the libmlt issue is hppa-only: you might see if you can figure out how to get that built for hppa.
[21:07] <ScottK> Actually kdelibs4-dev is still mostly around.
[21:07] <fabrice_sp> persia: this package build successfully on all arch, except hppa, so you think that it could be because of kdelibs4-dev?
[21:07] <fabrice_sp> I'll check anyway
[21:07] <persia> fabrice_sp: Not any more.  If ScottK says it's around, then it's around.
[21:08] <persia> On the other hand, there's something broken for hppa for that package, which probably needs to be fixed.
[21:08] <ScottK> Since it's an installability problem it's almost certainly something didn't build on hppa.
[21:09] <fabrice_sp> Where can I check the package build status for hppa? I've not been able to find it in the source package page
[21:10] <fabrice_sp> (for the missing packages)
[21:12] <ScottK> fabrice_sp: kdelibs build for hppa: https://launchpad.net/ubuntu/+source/kdelibs/4:3.5.10-0ubuntu5/+build/714435
[21:12] <ScottK> fabrice_sp: Do you have hppa hardware?
[21:14] <fabrice_sp> thanks ScottK: I'll check if kdelibs4c2a is there (if the build is ok, it should be the case)
[21:14] <ScottK> fabrice_sp: Check and see if it's actually installable or not.
[21:14] <fabrice_sp> ok
[21:23] <fabrice_sp> ScottK: The build is successful, and the package is listed in the build log. How do I check if it's installable or not? (I can't find hppa in the general repository)
[21:24] <ScottK> fabrice_sp: If you're on hppa, just install it.
[21:25] <fabrice_sp> ScottK: I'm on i386 (not even amd64 :-/ ). Should I install a VM for that?
[21:29] <ScottK> It's hard to test hppa installability without hppa.  You might ask NCommander to check.  IIRC he has access to hppa hardwar.
[21:29] <ScottK> e.
[21:29] <NCommander> ew, wait?
[21:29] <NCommander> argh
[21:29]  * NCommander runs
[21:29] <fabrice_sp> lol
[21:29] <NCommander> damn you HP, you made me the victum of more work by granting my HPPA request
[21:30] <NCommander> What package do you need to test installability of on HPPA?
[21:30] <ScottK> kdelibs4c2a
[21:31] <fabrice_sp> NCommander: it's just a matter of checking that packages kdelibs4c2a, libopenexr-dev, libmlt++0.2.5 and libmlt0.2.5
[21:31] <fabrice_sp> (according to build log of kdenlive: http://launchpadlibrarian.net/18102379/buildlog_ubuntu-intrepid-hppa.kdenlive_0.5.svn20071228-0.0ubuntu2_FAILEDTOBUILD.txt.gz)
[21:32] <fabrice_sp> are installable
[21:32]  * NCommander checks
[21:33] <NCommander> Testing installability
[21:34]  * fabrice_sp waves NCommander
[21:35] <NCommander> HPPA is evil
[21:35] <NCommander> hold on, had to enable universe
[21:36] <NCommander> fabrice_sp, not installable
[21:37] <NCommander>   kdelibs4c2a: Depends: libopenexr2ldbl (>= 1.2.2) which is a virtual package.
[21:37] <NCommander>   libglib2.0-data: Depends: libglib2.0-0 (>= 2.18.1-1) but 2.17.3-1ubuntu1 is to be installed.
[21:38] <ScottK> Looks like most of KDE Is currently uninstallable on hppa: http://people.ubuntu.com/~ubuntu-archive/testing-ports/intrepid_probs.html
[21:39] <fabrice_sp> NCommander: Thanks for the test. As KDE seems to be uninstallable on hppa, I won't worry about that.
[21:39] <fabrice_sp> ScottK: Thanks also for the link
[21:39] <ScottK> fabrice_sp: Or you could help fix it.
[21:40] <NCommander> \p/
[21:40] <fabrice_sp> ScottK: I'll try, but as I don't have a hppa, it will be difficult to follow the build dependencies.
[21:41] <fabrice_sp> but with the link you sent, it will be easier
[21:43] <ScottK> NCommander: OK, Mr. FTBFS, what's your diagnosis: http://launchpadlibrarian.net/18079762/buildlog_ubuntu-intrepid-hppa.glib2.0_2.18.1-1_FAILEDTOBUILD.txt.gz
[21:43] <sebner> ScottK: we two need a FTBFS hero, hmm? :)
[21:44] <ScottK> sebner: Go for it.
[21:44] <NCommander> You have an infinite loop :-)
[21:44] <sebner> ScottK: hmm? ^^
[21:44] <NCommander> or something equivelent
[21:44]  * directhex hands NCommander cake
[21:45] <NCommander> ScottK & directhex, can I ask you to look over my wiki page?
[21:45] <directhex> NCommander, up to 8700 users of my mono repo \o/
[21:45] <directhex> NCommander, sure
[21:45] <NCommander> https://wiki.ubuntu.com/MichaelCasadevall#preview
[21:45] <sebner> directhex: O_o
[21:45] <NCommander> o_o;
[21:45] <ScottK> NCommander: You can ask.
[21:45] <ScottK> ;-)
[21:45]  * NCommander throws his RS/6000 at ScottK 
[21:45] <sebner> let's make a "Ask ScottK session"
[21:46] <NCommander> The RS/6000 goes klunk. The ScottK's foot is injuried! He curses loudly!
[21:46] <ScottK> Cursing loudly is pretty normal for me.
[21:46] <sebner> lol
[21:47] <directhex> sebner, that's for i386 and amd64 combined
[21:47] <sebner> directhex: /me is still impressed
[21:47] <directhex> exact numbers on http://directhex.mfgames.com/hardy.html
[21:48] <sebner> directhex: O_o enemy of getdeb? ^^
[21:48] <NCommander> I think the day I go apt-get remove nethack, it will be a good thing
[21:50] <directhex> sebner, not per se, i just wanted a small focused repo. i don't really see getdeb as the right place for "major frameworks"
[21:51] <directhex> sebner, still, 8700 people can't be wrong... right?
[21:51] <sebner> directhex: ^^, sure but you also have normal apps (ok, mono related but nvm)
[21:52] <directhex> sebner, the only "app" app is tangerine, which is patched with some patches i wrote. they've been added to pkg-cli-apps svn now though, so i can start syncing the jaunty package once it exists
[21:52] <sebner> directhex: kk, \o/ sync \o/
[21:53]  * sebner loves syncs ^^
[21:53] <ScottK> NCommander: You need some insure/ensure I think in there.
[21:53] <directhex> sebner, i've been working on making mono syncable for jaunty, which will be nice
[21:53]  * NCommander super-hugs didrocks 
[21:53] <NCommander> ...
[21:53] <NCommander> damn it
[21:53] <NCommander> directhex,
[21:53] <ScottK> NCommander: Also you need to fix glib2.0 on hppa is you want to live up to your claims.
[21:53] <ScottK> is/if
[21:54] <NCommander> You don't ask little things do you :-P
[21:54] <sebner> directhex: really? syncable? GREAT. mono and sync? I love you :D
[21:54] <directhex> sebner, there's one remaining "real" merge reason, which i'm working on with upstream
[21:55] <ScottK> NCommander: Other than that, I think it looks good.
[21:55] <directhex> sebner, the "symlinked doc dirs" one i want to drop - the disk space rise will be MORE than offset by the mono 2.0 package transition savings
[21:55] <sebner> directhex: \o/ \o/ \o/
[21:56] <directhex> sebner, mono20transition should save 10-20 meg or so on the jaunty cd
[21:57] <sebner> directhex: sounds great :) /me uses trunk though ^^
[21:57] <directhex> sebner, well i obviously can't help (or support) that
[21:59] <sebner> directhex: ^^, kk. But I really appreciate your work with mono(-related) stuff :)
[21:59] <directhex> sebner, meebey's the real brains, i'm just a contributor
[22:00] <directhex> sebner, but i like to think of myself as the force behind keeping mono on ubuntu in good shape
[22:00] <sebner> directhex: that's what I mean ;)
[22:01] <directhex> and i try where i can to make those improvements using "svn ci" in pkg-mono and pkg-cli-apps
[22:02]  * sebner hugs directhex :)
[22:08] <NCommander> directhex, any comments of my wiki page
[22:08] <directhex> NCommander, needs pictures!
[22:08] <cody-somerville> Oops
[22:08] <cody-somerville> I just accidentally deleted it.
[22:08] <sebner> gn8 folks :)
[22:08] <NCommander> o_O;
[22:08] <NCommander> what did you accidently delete
[23:29] <radix> hey, what's the best channel for general Ubuntu packaging help?
[23:29] <leleobhz> here?
[23:30] <leleobhz> #ubuntu-devel maybe
[23:30] <radix> welp, ok :-)
[23:30] <persia> No.  Here.
[23:31] <radix> I'm not a MOTU or core-dev, but I'm trying to package some stuff that I'll publish in a PPA
[23:31] <mathiaz> radix: here is the best place
[23:31] <radix> thanks :-)
[23:31] <persia> radix: Then you'll get limited help, but still some, and this is the closest to the right place you'll find.
[23:31] <leleobhz> radix: this dont matter :]
[23:31] <leleobhz> matter you attempt to devel under/for ubuntu :]
[23:32] <leleobhz> radix: what is?
[23:32] <radix> I'm making some new packages for some existing software, and I've built lots of packages before, but I'm getting an "cannot represent change to .bzr/blahblah"
[23:32] <persia> radix: debuild -I -i
[23:32] <radix> and I've built other packages from bzr branches, so I'm not sure what I'm doing different now
[23:32]  * radix reads manpage for those options
[23:33] <mathiaz> radix: I've this line to ~/.devscripts DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I.bzr -I.svn -ICVS -k0x${GPGKEY}"
[23:33] <radix> I wonder why I never had to do that
[23:33] <mathiaz> radix: so that whenever I build a source package .bzr .svn and CVS are not included.
[23:34] <persia> mathiaz: Most of that is hardcoded into the scripts anyway: you only need -i -I
[23:35] <persia> mathiaz: Also, you really don't want -k unless you're sponsoring : it will bite you on a changelog entry eventually.
[23:35] <radix> ok, welp, it worked
[23:35] <mathiaz> persia: -k -> howc come ?
[23:36] <persia> mathiaz: -k is to sponsor an upload.  If you need it normally, either your debian/changelog entry is wrong, or your key is misconfigured.
[23:36] <persia> It also *always* signs the packages, so if you have a mistake with your changelog entry, it signs the package anyway, without any warning.
[23:37] <mathiaz> persia: hm - I usually debuild -S -uc -us
[23:37] <persia> If, for some reason, your DEBEMAIL isn't set when you run dch, this may result in unexpected values in the package changelog.
[23:37] <mathiaz> persia: and then sbuild _sources.changes.
[23:37] <ajmitch> like persia@localhost.localdomain? :)
[23:37] <persia> mathiaz: How do you upload?
[23:38] <mathiaz> persia: via dput
[23:38] <persia> ajmitch: Well, that one got sponsored by someone, but yes :)
[23:38] <mathiaz> persia: dput local _source.changes.
[23:38] <persia> mathiaz: OK.  When do the packages get signed?
[23:38] <mathiaz> persia: but true then I have to sign them.
[23:38] <mathiaz> persia: right - I sign the _sources.changes and dsc on a different machine.
[23:38] <slangasek> I set -k consistently; there's no reason I would not have my environment right when running dch, and it saves history completion hassle
[23:38] <persia> Right.  If you're signing them separately from building source, -k is not only dangerous, but wrong.
[23:38] <persia> s/wrong/useless/
[23:39] <persia> slangasek: Ah.  I sometimes build source in chroots when the dependencies for debian/rules clean are onerous.
[23:39] <slangasek> persia: I frequently build source in chroots; my chroots mount /home :)
[23:40] <persia> My chroots mount home, but don't preserve my environment (so I lose DEBEMAIL, etc.).  This is somewhat intentional, as I don't pass the environment preservation flag.
[23:41] <slangasek> oh, well, I don't preserve my environment, it's just re-sourced from ~ when chrooting
[23:41] <persia> Hrm.  Most of my environment doesn't get resourced.  Perhaps I'm keeping things in a different place.