[00:15] <kklimonda> ScottK: I have patches ready but will wait for libclaw to be published so I can testbuild it in clean chroot (it's going to take less time for libclaw to be published then for me to configure pbuilder to use local repository)
[00:21] <ScottK> kklimonda: OK.  Thanks.  Let me know.
[01:17] <ajmitch> persia: congratulations on the CC appointment
[02:09] <kklimonda> ScottK: btw, can you take a look at bug 663624? I'd rather not touch boost myself.
[02:13] <ajmitch> probably a wise choice
[02:14] <ajmitch> nice of you to link the patch though
[02:14]  * ajmitch will have to setup a natty pbuilder to test it out
[03:05] <Guest71947> ajmitch: well, i did build both boost and mumble to see if the fix is correct - it's just that I'd rather not touch boost officially as I don't really understand it.
[03:09] <lifeless> kklimonda_: who does :)
[03:10] <ajmitch> noone sane
[03:10] <ScottK> kklimonda_: If no one touched boost without understanding it, the work would never get done.
[03:10] <ScottK> ajmitch: I'd be interested in your opinion too.
[03:12] <lifeless> ScottK: lol, true.
[03:12] <lifeless> whats the change?
[03:12] <lifeless> I ran into boosts build system and cried, some years ago
[03:12] <ScottK> https://svn.boost.org/trac/boost/changeset/61467
[03:14] <ajmitch> ScottK: I'm just doing a test build of it now
[03:14] <ScottK> Cool.
[03:15]  * ScottK has been a bit distracted today trying to get a sewage leak in the house stopped and cleaned up.
[03:15] <ScottK> It's just a "small" leak, but given the subject matter, even small is not minor.
[03:15] <ajmitch> not pleasant in any quantity
[03:15] <lifeless> ugh
[03:15] <lifeless> ScottK: hope its gone soon
[03:16] <psusi> anyone seen keybuck lately?  we so need to get this new release of lvm2 into the repos.... I just did a test dist-upgrade to natty after making a snapshot... reboot... looks good... schedule the snapshot to be merged back in, reboot, and I'm back in maverick
[03:16] <lifeless> ScottK: ajmitch: I've read the aptch, bug and bugzilla discussion
[03:16] <lifeless> it all scans for me
[03:16] <ScottK> lifeless: Should be.  The "flow" is stopped and the first round of contractors to start the cleanup were here today cutting holes in walls and ripping stuff out.
[03:16] <lifeless> I can get thumper who is more of a C++ head than I to eyeball too if you need, but I don't think thats needed.
[03:17] <ScottK> As long as I can say "It's lifeless' fault" I'm happy.
[03:17] <lifeless> hah
[03:17] <lifeless> sure
[03:17] <ajmitch> it looked sane enough, with what rusty C++ knowledge I have
[03:18] <ScottK> ajmitch: Hey, you're our boost expert.  You fixed the last one.
[03:18] <ajmitch> if that makes me an expert, then we're all doomed
[03:21] <ScottK> No.  Doomed would be if it were me.
[03:24] <ScottK> Nice.  Gizmod FTBFS due to not being explicitly linked to boost_system.  Turns out it's CMake doesn't even test for it's presence.
[03:24] <ScottK> Sigh.
[03:31] <ajmitch> ScottK: do you want to be the person that touched boost last, or shall I brave an upload?
[03:42] <psusi> eww... makes me glad I "only" had a water main leak and had to replumb the whole house recently
[03:47] <ScottK> ajmitch: Please upload.
[03:58]  * ajmitch would love to have the laptop not sound like it's taking off when compiling boost
[04:00]  * psusi still needs to get someone to review and/or sponsor launchpad.net/e2defrag
[04:03] <ajmitch> psusi: I'd suggest putting it on revu, but that would require us to actually review it on there :)
[04:04] <psusi> isn't that dead? ;)
[04:04] <ajmitch> no, just pining for the fjords :P
[04:05] <psusi> well I'd like SOMEONE to review my packaging, so I can make sure I have things down before it's uploaded to universe and I might actually become a motu myself to continue to maintain it ;)
[04:06] <psusi> and it seems that the most interested person, jdong, is too busy these days
[04:07] <RAOF> Is it up on revu?  I'll give it a once-over.
[04:07] <psusi> no, but it's on launchpad
[04:07] <psusi> launchpad.net/e2defrag
[04:07] <ajmitch> first thing I'd question is whyt is it a native package?
[04:07] <psusi> because there is no upstream ;)
[04:08] <ajmitch> not a good enough reason :P
[04:08] <psusi> it was abaonded decades ago and finally dropped from debian and ubuntu I think in 8.04 or 8.10
[04:08] <psusi> isn't that what native packages are for?  is packages with no upstream?
[04:08] <ajmitch> consider the forking from the old upstream & packaging it in debian/ubuntu as separate activities
[04:09] <ajmitch> no, it's for packages that would be tightly tied to the distro
[04:09] <RAOF> Native packages are for software that doesn't make sense outside of Debian/ubuntu.
[04:09] <ajmitch> e2defrag seems like it would be useful on any distro & you shouldn't have to do new 'upstream' releases to fix some packaging bugs
[04:10] <ajmitch> psusi: you aren't listed at all in debian/copyright?
[04:10] <micahg> RAOF: ajmitch: does that include packages that contain upstream stuff but there's no upstream tarball
[04:10] <psusi> hrm....
[04:11]  * ajmitch doesn't know what sort of copyright notices you'd put in the source when you've heavily modified it 
[04:11] <RAOF> micahg: How does that happen?  If you're packaging from VCS you generally just create an “upstream” tarball.
[04:11] <psusi> but why should I avoid keeping the proper packaging stuff in debian/ in my upstream release?  I just don't see any advantage to that other than allowing me to make more upstream releases WITHOUT uploading new revs to Ubuntu... which I see no reason to bother doing
[04:12] <micahg> RAOF: I'm specifically thinking of thunderbird-locales (which is the upstream xpis + packaging)
[04:12] <RAOF> micahg: It should probably not be native.  Ship the upstream xpis in a tarball?
[04:12] <psusi> I suppose I could add myself to the copyright file...
[04:12] <ScottK> psusi: It's also painful for downstreams that then have to rebuild the entire tarball for trivial changes.
[04:13] <ScottK> (which is why we like it when Debian doesn't do this to us)
[04:13] <micahg> RAOF: that's what it was before, but I thought since there's no upstream tarball that it shoudl be native
[04:13] <ajmitch> having debian/ in the upstream tarball isn't quite as painful as it used to be
[04:13] <RAOF> micahg: Nope.  You just create an upstream tarball in those cases.
[04:13] <psusi> micahg, that's exactly what I figured
[04:14] <ajmitch> fairly sure that the 3.0 source format allows proper file deletion now
[04:14] <micahg> RAOF: k, it seems I received wrong information before :), I'll fix it for Natty
[04:16] <psusi> so other than it being native, anything else?
[04:17] <ajmitch> export DH_COMPAT=4
[04:17] <ajmitch> that's somewhat old :)
[04:17] <psusi> and if I were to fix that... do I need to remove the debian/ directory, or can I just make a .orig.tar.gz with an empty diff?
[04:18] <psusi> hehe... well, yea... the package is from the 90s ;)
[04:18] <ajmitch> it shows - quite ancient build-depends
[04:18] <psusi> I couldn't even find an original upstream tarball source... it was only kept alive afaics in debian for many years
[04:19] <ajmitch> I hope that we've got rid of autoconf2.13 & automake1.4 in natty
[04:19] <psusi> auto* causes me much consternation
[04:19] <ajmitch> they're caollectively called autohell for a good reason
[04:19] <RAOF> psusi: Is the description accurate?
[04:20] <psusi> RAOF, what do you mean?
[04:20] <RAOF> *HIGHLY EXPERIMENTAL* do not use on a filesystem that you care
[04:20] <RAOF> 13		
[04:20] <RAOF>  about as it likely will destroy it.
[04:20] <RAOF> If that's accurate, do we even want it in the archive?
[04:20] <RAOF> If it's inaccurate, it should be removed :)
[04:20] <psusi> RAOF, yea... it directly manipulates the block device, so quite possible it can trash the fs
[04:21] <psusi> RAOF, that said, I am fairly satisfied that it is working enough for people to test on unimportant or recently backed up filesystems.. I fixed all the bugs I could find so...
[04:21] <psusi> but that doesn't mean there aren't others I didn't find
[04:22] <RAOF> So, there are no *known* data-eating bugs?
[04:22] <psusi> correct
[04:22] <RAOF> How safe is it with respect to error handling?
[04:23] <psusi> not at all ;)
[04:23] <psusi> if anything goes wrong, your fs is likely toast ;)
[04:23] <psusi> hence the warning
[04:23] <ajmitch> can you make it work with a slightly modern version of automake?
[04:24] <RAOF> Does it duplicate that warning on startup?
[04:24] <psusi> hrm... I dunno... I still don't really know much about autohell ;)
[04:24] <psusi> RAOF, no
[04:25] <RAOF> It may be obvious that I think that it should :)

[04:25] <ajmitch> there look to be about 12 source packages in the archive that still build-dep on automake1.4, it'd be nice to not increase that number :)
[04:27] <psusi> hrm... I also still need to figure out how to interface with initramfs-tools to get an alternate initramfs built so you can have a grub boot option to do a defrag of your root fs
[04:27] <RAOF> So, it seems like, at this current stage, it's only really useful for developers?
[04:28] <psusi> no... it's useful for anyone who wants to defrag their fs...
[04:28] <ajmitch> and risk having it chomped
[04:28] <RAOF> As long as they don't care about their data.
[04:28] <psusi> exactly
[04:28] <psusi> of course, EVERYONE makes regular backups right?  right? ;)
[04:28] <ajmitch> though it wouldn't be the easiest thing to get testers for
[04:30] <psusi> it might be worth mentioning that when combining the ureadahead pack file list with a good defrag, I was able to get my boot time on a rotational disk down to the 10-12 second range ;)
[04:30] <psusi> by placing all of the files read during boot in order at the start of the disk
[04:31] <ajmitch> right, then you can promote it in flashy lights on the fourms, omgubuntu, and other places where speed addicts like to congregate
[04:31] <psusi> hehe
[04:31] <ajmitch> good way to get some testers
[04:31] <psusi> yea... with the big flashing warning BACK UP YOUR DATA YOU FOOLS! ;)
[04:32] <ajmitch> do you have it available in a PPA?
[04:32] <psusi> eventually I'd like to get it to the point that you can just choose an alternate "optimize" boot option from the grub menu every once in a while that will automatically run a defrag and pack all of the boot files at the start of the disk with the ureadahead list
[04:32] <psusi> yes
[04:33] <ajmitch> to get to that point, you'd need to convince everyone that it was stable
[04:33] <psusi> that reminds me, I still need to get keybuck to review my ureadahead changes...
[04:34]  * ajmitch would just like a boot time under 1 min or so :P
[04:34] <psusi> to get it there as a default, sure.. but for those brave/wreakless individuals willing to test it now... hehe ;)
[04:34] <psusi> 1 minute?  really?
[04:34] <ajmitch> maybe a slight exaggeration
[04:35] <psusi> I get like 30 seconds on my slow ass 1 ghz netbook with a default install
[04:35] <ajmitch> but I've got apache, postgres, other tools installed
[04:35] <psusi> ahh
[04:35] <ajmitch> they can all add on a bit of time
[04:35] <psusi> how do your bootcharts look?
[04:35] <ajmitch> no idea
[04:35] <psusi> lots of IO wait time, or cpu pretty much maxed?
[04:36] <psusi> well, if it's IO bottlenecked, a defrag pass with the ureadahead list as input can help a good deal
[04:36] <ajmitch> probably lots of IO wait time, but I've never looked at bootchart stuff on this laptop
[04:36] <ajmitch> being a laptop, I believe the hard drive is 5400RPM
[04:37] <psusi> yea..
[04:37] <ajmitch> looks like it is from the model number
[04:37] <psusi> I ran it on my netbook and I think I got the boot time down to around 25 seconds... but it's a 5400 rpm drive and only a 1 ghz cpu so it's pretty much cpu bound at this point
[04:38] <ajmitch> 2.8ghz c2d in this
[04:39] <psusi> then I made some modifications to ureadahead to suck out that 1 second or so of almost 0 disk throughput that is typical for most people
[04:40] <psusi> lots of time staring at blktrace output...
[04:41] <psusi> and debugfs
[04:51]  * ScottK is learning about how a lot of different build systems specify linker options.
[04:52]  * ajmitch wonders how many packages just be rebuilt after this boost fix gets uploaded & built
[04:53] <ajmitch> I'm glad I've got a 3-day weekend coming up
[04:54] <psusi> ok, so if I want to make e2defrag not be a native package, what do I have to do?  establish a baseline upstream .orig.tar.gz that does NOT have the debian/ in it, and then add that when packaging it?
[04:55] <ajmitch> psusi: that would be the preferred option
[04:55] <psusi> I just hate to take something out, only to put it back in.. you know what I mean?
[04:56] <ajmitch> I can understand that
[04:56] <psusi> so assuming everything in debian/ is pulled out and only added with the .diff.gz, do you see anything else wrong?
[04:57]  * ajmitch has only taken a quick look for obvious problems so far
[04:57] <ajmitch> I'd prefer it if the packaging were updated to use tools from this century :)
[04:58] <ajmitch> it may be possible to simplify it a lot by using debhelper 7
[04:58] <psusi> what do you mean?
[04:58] <ajmitch> your debian/rules is a lot of boilerplate text
[04:59] <ajmitch> it may be simplified to a 3-line debian/rules
[04:59] <ajmitch> eg http://kitenet.net/~joey/blog/entry/cdbs_killer___40__design_phase__41__/
[04:59] <psusi> really?
[05:00] <ajmitch> possibly :)
[05:00] <ajmitch> having the usual case be this simple is a good thing
[05:00] <psusi> k... I'll have to read that and see if I can apply it when I'm sober ;)
[05:01] <ajmitch> heh
[05:02] <psusi> now where is sjr hiding?  he always seems to vanish from irc for a few weeks after a new release...
[05:02] <psusi> need to talk to him about some of these ubuntu quilt patches to lvm2 I disabled or modified and my modifications to ureadahead
[05:04] <psusi> because being able to revert borked updates is one of the coolest features I've seen in some time
[05:06] <psusi> and bloody hell, I need to get the new rev of gparted going that can supposedly properly understand dmraid disks without you first installing kpartx
[05:06] <psusi> that one has been on my todo list since 2005
[08:13] <dholbach> good morning!
[09:54] <delan_> hi, i'm not quite sure how the MOTU acceptance process works, but I have a couple of packages in my PPA and am looking for approval. could anyone please help?
[09:56] <persia> Just needs two folk to review and like your package.  We generally encourage folk to post something ready for upload directly into Ubuntu on REVU, and post a URL here asking for a review.
[09:56] <persia> We generally discourage anyone from posting a URL too frequently (more than once a day or so).
[09:56] <delan_> would two URLs now be okay?
[09:56] <persia> And be prepared for some folk to be busy or otherwise ignore it.
[09:56] <persia> Sure, but advertise your packages.  Describe them in a way that gets people excited.
[09:57] <persia> You want to end up with a developer who looks at it because they want it working, rather than just having it be out there.
[09:57] <delan_> hm, i'll probably copy the description from my website, with a bit more spice ;D
[09:57] <geser> delan_: you could also try to get your package into Debian and get it synced to Ubuntu afterwards
[09:58] <raywang> hi, anyway know how to whip the whole disk with zero very quickly, (except dd if=/dev/zero of=/dev/sda, that's so slow) :)
[09:58] <geser> but I'm not sure if Debian accepts new packages right now because of their freeze
[09:58] <raywang> s/anyway/anyone/
[09:58] <delan_> raywang, afaik that's the fastest...
[09:58] <delan_> geser, that's true, though i'm 'afraid' of venturing outside of Ubuntu ;)
[09:58] <delan_> three years using Ubuntu and nothing else
[09:58] <raywang> delan_, if I wipe out 160GB, how long will it take?
[09:59] <delan_> raywang, let's assume an average write speed of 50MB/s
[09:59] <delan_> that's 3200 seconds, which is almost an hour
[09:59] <raywang> delan_, can it be 50MB/s?
[09:59] <delan_> raywang, test it by doing:
[09:59] <raywang> I doubt :)
[09:59] <tumbleweed> delan_: Ubuntu largely comes unmodified from debian. universe packages that are ubuntu-only tend to get neglected. If you want to take care of your own package, Debian is a good option (probably the recommended one)
[10:00] <delan_> raywang, my caviar green (slow, 5400rpm) can do 60MB/s write easy
[10:00] <persia> raywang, What are you seeking to accomplish?  zeroing won't block data recovery
[10:00] <raywang> persia, yes, that's what I want
[10:00] <tumbleweed> geser: yes, the Debian NEW queue is currently backed up (got a package in there > 2 months)
[10:00] <delan_> tumbleweed, where should I find specifics to the debian repositories and how to attempt acceptance?
[10:00] <persia> My possibly faulty understanding is that ftpmasters aren't processing NEW until squeeze releases.
[10:01] <raywang> persia, just want to capture the whole data without noise in the future.
[10:01] <raywang> delan_, how do you test the write speed?
[10:01] <delan_> raywang,
[10:01] <delan_> uh
[10:01] <tumbleweed> persia: that wouldn't suprise me although I haven't seen it announced
[10:01] <delan_> dd if=/dev/zero of=whatever.file bs=512 count=2097152
[10:01] <delan_> raywang, that'll write a 1GiB file and print the speed
[10:01] <raywang> ok
[10:01] <delan_> Actually, I was thinking that now would be a good time to just work with Ubuntu as Natty has just started
[10:02] <raywang> delan_, is there any application to do this in fast way?
[10:03] <delan_> raywang, that's my favourite
[10:03] <delan_> if you want, you can write a shell script like this:
[10:03] <delan_> #!/bin/bash
[10:03] <delan_> dd if=/dev/zero of=whatever.file bs=512 count=2097152
[10:03] <delan_> rm whatever.file
[10:03] <delan_> that'll test, print speed and delete the file
[10:03] <delan_> probably best to stick the temporary testing file in /tmp
[10:03] <raywang> ok, but wipe the disk out is just dd if-=/dev/sda of=/dev/sda?
[10:04] <delan_> no
[10:04] <delan_> if=/dev/zero of=/dev/sda
[10:04] <raywang> delan_, oh, ? is just question mark. ;)
[10:04] <persia> delan_, Now is an excellent time to work on Ubuntu: we just aren't really organised in a way that tends to encourage entry of new code: this team focuses on improving the quality of stuff nobody else is looking at.  Most of the other teams focus on preparing specific flavours of Ubuntu.
[10:05] <raywang> to indicate, that was my question. :)
[10:05] <delan_> raywang, i know. you made the mistake of doing if=/dev/sda, when it should be if=/dev/zero
[10:05] <raywang> delan_, oh, my bad. :)
[10:05] <delan_> persia, so, in effect, bug fixes?
[10:05] <raywang> typo
[10:10] <tseliot> does anybody know why quilt complains that a patch has been previously applied when it's not? http://pastebin.ubuntu.com/516334/
[10:12] <delan_> hm, i've uploaded, but it's not on the list. might have to be approved first, hint hint ;D
[10:16] <delan_> actually, it's appeared now. all is fine.
[10:24] <delan_> so, the two packages are at:
[10:24] <delan_> http://revu.ubuntuwire.com/p/getbooru
[10:24] <delan_> http://revu.ubuntuwire.com/p/mathtext
[10:52] <persia> delan_, Indeed, and for this team, updates to unmaintained packages.  We've a list at UEHS.
[10:52] <persia> !uehs
[10:52] <persia> Grrr...
[10:52] <persia> http://qa.ubuntuwire.com/uehs/no_updated.html
[10:52] <persia> There's 100 packages that need review, update, cleanup, etc.
[12:14] <adhorden> the build queue seems slow today, 14 hours to build my package
[12:22] <persia> adhorden, It's generally slow as releases open.  This release is faster than normal, as there's less coming in from Debian.
[12:27] <hrw> hi
[12:27] <adhorden> I have been testing locally with pbuilder, but the packages I am working on have dependencies that I am also building packages for, what's the best way for pbuilder to get these dependencies inside the chroot?
[12:28] <hrw> to get vim from debian into ubuntu I should first extract ubuntu changes, then grab latest debian and check which ubuntu changes still apply, then create new source package for ubuntu, build it and then give for review/sponsor?
[12:44] <ScottK> adhorden: Use pbuilder login with --save-after-login, install the packages, and then exit.  Don't forget to reverse the process later so your pbuilder will be clean for other uses afterwards.
[12:45] <hrw> adhorden: other way is to make local apt repository with your packages and add it as OTHERMIRROR for pbuilder
[12:45] <ScottK> hrw: Yes, but if you look at merges.ubuntu.com there should be a draft package ready that is 'pre-merged'.  You can use the grab-merge script in ubuntu-dev-tools to grab the relevant bits.
[12:45] <persia> hrw, Roughly, yes.  I think geser was working on that: there may be an opportunity to collaborate.  merges.ubuntu.com has some handy prepared stuff (last common ancestor, both source packages, an attempt at an automated merge) that you may find helpful.
[12:46] <hrw> thx guys
[12:47] <geser> persia, hrw: yes, I'm working on the merging vim
[12:48] <hrw> geser: did you got debian version built at all? it fails on test here
[12:48] <geser> hrw: I'm almost done, I've included the remaining Ubuntu changes into a new package (and forwarded some of the remaining Ubuntu delta to Debian) and I'm currently waiting on the Debian vim maintainer to help fixing a FTBFS with gcc-4.5 in natty
[12:51] <geser> hrw: with a "buffer overflow"? yes that's the problem I'm waiting on getting fixed. The resulting binary doesn't work at all because the glibc catches an strcpy that will overflow on purpose
[12:52] <hrw> geser: same
[12:52] <hrw> geser: trying HEAD of vim hg repo now
[12:53] <hrw> geser: 7.3.029 in other words
[12:54] <ScottK> debfx: Thanks for taking care of ball.
[12:54] <ScottK> (now you can tell what my bug mail latency is at the moment)
[12:56] <ScottK> maco: Would you be up for looking into Bug 660363 and seeing if an SRU is appropriate?
[12:56] <geser> hrw: unlikely that it will succeed as  http://code.google.com/p/vim/source/browse/src/structs.h didn't change since August (the di_key[1] and similar are the problem)
[12:57] <hrw> ok
[12:57] <geser> hrw: sort of workaround is to build with -O0 or gcc-4.4 (I don't understand why disabling optimization makes gcc-4.5 not catch that "buffer overflow")
[13:02] <hrw> geser: right - same problem
[13:13] <persia> -O0 seems preferable to 4.4, if that's the only choice.
[13:14] <ScottK> If one picked 4.4, it would at least force the issue to be re-addressed later.
[13:15] <geser> according to the Debian vim maintainer this is a problem with -D_FORIFY_SOURCE=2 and the vim Makefile forces it to < 2 but he overwrites that with CFLAGS in the packaging. He is going to fix it
[13:15] <persia> Oh, that's a better solution indeed.
[13:17] <ScottK> Agreed.
[13:18] <kklimonda_> ScottK: I have prepared a fix for plee-the-bear (bug 663485), built it in natty pbuilder, installed and ran on maverick (as I don't have a natty vm yet). Haven't had any problems
[13:19] <ScottK> kklimonda_: Sounds good.  I'll have a look.
[13:24] <bilalakhtar> geser: ping, I got a mail from you, but its in some language other than English!
[13:24] <sebner> bilalakhtar: german? ^^
[13:24] <bilalakhtar> probably
[13:24] <Laney> silly website
[13:25] <Laney> it's a call for votes for the vacant developer membership board seeat
[13:25] <Laney> -e
[13:25] <geser> I know, CIVS sent out german mails because my preferred language in my browser is german :(
[13:25] <Laney> Followup to the -devel thread would probably be appropriate
[13:25] <sebner> Oh, right. I just noticed that this mail is in german =)
[13:25]  * sebner waves at geser 
[13:26] <bilalakhtar> Laney: ah, there you are, you are also an applicant, right?
[13:26] <bilalakhtar> Laney and bdrung :)
[13:26] <Laney> apparently so. :)
[13:26] <geser> but the website when one follows the link is in English right?
[13:26] <Laney> yes
[13:27]  * persia waits for the day that !en becomes a factoid sending folk to #ubuntu-uk because the channel expects folk to write in German :)
[13:27] <bilalakhtar> !en
[13:28] <bilalakhtar> persia: its already a factoid :)
[13:28] <popey> !uk
[13:28] <popey> hehe
[13:28] <bilalakhtar> lol
[13:28] <Laney> pip pip
[13:28] <popey> Tally ho!
[13:28] <persia> Neither of those are in the same class as !de
[13:28] <persia> !de
[13:28]  * popey fires up google translate
[13:29] <tumbleweed> !za
[13:29] <tumbleweed> hmm, we should add one
[13:29] <Laney> .!learn za is ...
[13:29] <bilalakhtar> !sa
[13:29] <bilalakhtar> COOL!
[13:29] <tumbleweed> I doubt our IRC channel can support all 11 official languages...
[13:29] <persia> tumbleweed, heh.
[13:29] <persia> Anyway, folks playing with the bot ought do it in /msg
[13:30] <bilalakhtar> tumbleweed: you can add it yourself, but it would have to be approved by jussi01
[13:30] <tumbleweed> bilalakhtar: there's nothing to add - we don't have any regular trickle of south africans asking for help in non-za channels
[14:10] <OpenAccessSTB> http://proxy.lib.sun.ac.za:8800/open-access/
[14:10] <OpenAccessSTB> our university is going opensource
[14:11] <OpenAccessSTB> live video stream of the event
[14:19] <sladen> openaccessstb: "resource unknown
[14:27] <ari-tczew> geser: heh, I'm not sure whether I voted correctly. List shows: 1. other 2. Ian 3. Benjamin.  All 3 options has got value '3'. I chose Benjamin with value 3. is it correct?
[14:28] <geser> ari-tczew: you should have changed the values: your first choice should get the 1, the second choice the 2 and so on
[14:29] <bilalakhtar> ari-tczew: Just rank them , ^^ is right way
[14:29] <geser> choice with the same value are equal
[14:29]  * bilalakhtar voted for bdrung 
[14:29] <ari-tczew> geser: ehh :/ could you reset my vote and send me new link?
[14:29] <geser> sorry, I can't
[14:29] <stefanlsd> Anyone got a suggestion - using sbuild to test build and it runs invoke-rc.d: initscript gdomap, action "start" failed. Which fails the sbuild
[14:30] <bilalakhtar> brb, have to reboot after updates
[14:31] <ari-tczew> geser: did someone DMB member leave a team, or is it a place for new member?
[14:33] <geser> ari-tczew: nixternal left a couple months ago, but till now nobody set up the vote (the call for nominees is some weeks old already). So I volunteered to set it up (my first vote) with the known german/english mail :)
[14:34] <bilalakhtar> ah, nixternal left? when?
[14:34] <bilalakhtar> geser: ^^
[14:34] <bilalakhtar> He attended the September 14 meeting, IIRC
[14:34] <ari-tczew> hmm, I remember that he did a vote for me.
[14:34] <ari-tczew> yea
[14:34] <geser> Date: Mon, 12 Jul 2010 11:13:11 -0500
[14:35] <geser> he helps out sometimes till we find a replacement for him
[14:35] <bilalakhtar> aha
[14:36] <bilalakhtar> and why did nixternal drop out from UCC? Any idea?
[14:36] <ari-tczew> bilalakhtar: UCC?
[14:37] <geser> sorry, no idea. But I guess the same reason as from DMB.
[14:37] <geser> ari-tczew: Ubuntu Community Council
[14:37] <bilalakhtar> ari-tczew: Did I answer your query?
[14:37] <ari-tczew> bilalakhtar: geser did that.
[14:38] <bilalakhtar> ok
[14:56] <tumbleweed> sladen: btw OpenAccessSTB turned up in our loco channel again and pointed to http://oa.sun.ac.za/instructions.htm - but he didn't really mean his unviersity was going OSS, just Open Access (although they are have some decent-size dual-boot-Ubuntu labs)
[14:56] <tumbleweed> (and that video stream is boring, even though digital repositories is my current research field)
[14:57] <tumbleweed> oh sabdfl has a recorded segment that is about to play in that stream
[15:13] <debfx> ScottK: you're welcome
[15:14] <debfx> ScottK: do you know if boost can be built with threading libs other than pthread?
[15:15] <ScottK> I don't.
[15:16] <debfx> the problem is that applications that use boost threads need to link to pthread
[15:17] <debfx> but I doubt unconditionally linking to pthread is the right way
[15:26] <ScottK> kklimonda_: plee-the-bear uploaded.  Thank you for your contribution to Ubuntu.  In the future, there's no need to mention the maintainer change in debian/changelog.
[15:44]  * chrisccoulson_ must remember to review debfx ff-4.0 merge request for KDE this week
[15:46] <kklimonda_> ScottK: ok, noted :)
[16:24] <adhorden>  hi all, I have been working on a package for msp430-gcc, a cross compiler based on gcc for the msp430 arch, problem is I keep getting: cd /tmp/buildd/msp430-gcc-4.4.4/debian/msp430-gcc && /usr/bin/make install
[16:24] <adhorden> make[1]: *** No rule to make target `install'.  Stop any ideas? I checked the paths and they look fine, the rules is here http://paste.ubuntu.com/516877/ thanks
[16:24] <adhorden> configure runs in the correct location as well as make
[16:40] <geser> you sure that the upstream makefile has an "install" target?
[16:44] <adhorden> its essentially gcc with a patch applied, so I would hope so and according to the gcc manual make DESTDIR=path-to-rootdir install
[16:45] <geser> hmm
[16:48] <adhorden> I can build it fine from source using essentially the same commands as the ones in the rules files to ensure I did not do something stupid, so I know make install works fine from testing the patches worked before working on the package
[16:55] <xteejx> Hi all. How do I go about getting a package upgraded? Debian is on the older one as are we
[16:55] <micahg> xteejx: helpl Debian release squeeze :)
[16:55] <xteejx> Latest release of said package was 8th Jan 2010
[16:55] <micahg> xteejx: which package?
[16:56] <xteejx> linthesia - the one we have has probs with libpango
[16:58] <xteejx> actually the dev upstream one does too, just compiled it :(
[16:58] <micahg> xteejx: it's actually packaged, see debian 597189
[16:59] <xteejx> micahg: Seems someone is working on it :)
[17:00] <xteejx> bug 663962, it's annoying :(
[17:02] <xteejx> looking at the source, the error is with     main_loop.run(window);
[17:07] <geser> xteejx: if you're interested in an easy FTBFS, you might want to look at pybliographer
[17:07] <xteejx> geser: I'd rather get linthesia working at the moment, but I'll take a look at that ftbfs later on :)
[17:11] <geser> it's not urgent. I know how to fix pybliographer, but it's also a good one for any prospective contributor to gain experience
[17:12] <xteejx> Ok geser, I will def look later on :)
[17:12] <xteejx> I really wanna fix linthesia. I have dreams of music stardom lol
[17:12] <Rhonda> Does anyone know if someone from Ubuntu is attending the openSUSE conference, like sabdfl invited in his blog?
[17:14] <xteejx> I found the problem!!!!!!!!!
[17:14] <geser> that was fast
[17:14] <xteejx> If the font for linthesia is set with gconf-editor to Serif it works perfectly
[17:14] <xteejx> pango can't use the default Arial font
[17:16] <stefanlsd> Anyone got a suggestion - using sbuild to test build and it runs invoke-rc.d: initscript gdomap, action "start" failed. Which fails the sbuild. This a sbuild problem?
[17:18] <geser> who wants to run the initscript? a dependency or the package itself?
[17:19] <stefanlsd> geser: looks like dep during dpkg configure.  http://paste.ubuntu.com/516818/
[17:22] <geser> I don't about sbuild but in my pbuilder the initscript doesn't get started
[17:24] <xteejx> Ok, I'm gonna generate a debdiff for linthesia and attach it, can anyone check it in a min please?
[17:24] <stefanlsd> geser: yeah, figured as much. thanks
[17:26] <xteejx> bug 663962, can anyone check everything's ok there for me please?
[17:37] <geser> xteejx: done :)
[17:38] <xteejx> geser: Jesus christ!! that was quick!!
[17:38] <xteejx> Thank you geser, I'll report it upstream to dev and debian in a bit
[17:59] <xteejx> Reported upstream to Deb and dev
[19:32] <ari-tczew> lucas: is your merge script pointed to natty?
[19:44] <c_korn> where can I find the class RevuKeyUpdater ?
[19:51] <lucas> ari-tczew: I think so
[19:53] <bdrung> tumbleweed: i am around. i was at the Ubucon last weekend.
[19:53] <tumbleweed> oh, right, you said something about that
[19:56] <achiang> how does one create a natty pbuilder environment? debootstrap doesn't seem to know about it. [host machine is lucid]
[19:57] <achiang> oh, i guess i can just fake it by creating a symlink in /usr/share/debootstrap/scripts/natty -> gutsy
[19:59]  * geser copies the pbuilder chroot and dist-upgrades it :)
[20:00] <bdrung> geser: why wasn't you at the Ubucon?
[20:01] <DktrKranz> ari-tczew: hi! have you looked at the gnustep stack yet?
[20:01] <geser> bdrung: when and where was it?
[20:01] <ari-tczew> DktrKranz: Hi. I'm sorry, nope. I'm busy till friday.
[20:02] <bdrung> geser: last weekend in Leipzig.
[20:03] <DktrKranz> ari-tczew: no big problem. If you want, I can give it a go myself, I've become used to do them lately :)
[20:04] <ari-tczew> DktrKranz: would be nice! I'm not addicted to this package. I just work on reducing merges.
[20:04] <DktrKranz> ok then, there will be a lot of work to do :)
[20:05] <bdrung> geser: http://ubucon.de/ - there was only one Ubuntu developer and no Canonical employee.
[20:05] <geser> bdrung: a little bit to far for me to get there for one day (or two) (and I was busy till Friday)
[20:07] <ari-tczew> DktrKranz: good luck!
[20:08] <geser> bdrung: I might be perhaps at OpenRheinRuhr in November (next to the German Ubuntu booth :)
[20:09] <bdrung> geser: never heard of it.
[20:10] <xteejx> geser: I've picked up the ftbfs on pybliographer - simple d/control fix I think
[20:11] <geser> bdrung: it's rather small: http://www.openrheinruhr.de/
[20:11] <geser> xteejx: yes, you just need to figure what's missing :)
[20:12] <xteejx> geser: gnome-doc-utils (>= 0.3.2) in build-dep
[20:13]  * ari-tczew counts that 47% of remaining merges include new upstream releases
[20:13] <geser> xteejx: yes, but the version is unneeded as all supported Ubuntu (and Debian) versions have a newer one
[20:14] <xteejx> geser: Oops :) hehe does it matter that I've put it in already?
[20:15] <xteejx> It's ok I'll rebuild the source package
[20:16] <fabrice_sp> geser, please ignore my last email: I've just seen that you sent another email explaining the german email
[20:18] <geser> fabrice_sp: at least I know that way that people are participating in the vote :)
[20:18] <fabrice_sp> :-)
[20:22] <xteejx> bug 664108 complete
[20:23] <geser> xteejx: have you checked that this fixes it?
[20:23] <geser> xteejx: hint: gnome-doc-utils is not enough
[20:28] <xteejx> geser: It builds perfectly fine locally
[20:29] <xteejx> just adding that to the build-dep fixed it,  tested build before, same failure, and with that in d/c it worked
[20:33]  * ajmitch wonders where this followup explanation about the german email is :)
[20:37] <xteejx> Ich weiss es nicht lol
[20:43] <geser> ajmitch: ubuntu-devel
[20:43] <geser> xteejx: in a natty pbuilder?
[20:44] <xteejx> geser: no in natty in a vm
[20:44] <xteejx> natty is the vm
[20:44] <geser> minimal vm or desktop?
[20:44] <xteejx> desktop
[20:44] <ajmitch> geser: ok, was just thunderbird being hopeless & not telling me of new mail :)
[20:45] <geser> xteejx: you might then have one of the other missing dependencies installed
[20:45] <geser> xteejx: do you have pkg-config and rarian-compat installed in your natty vm?
[20:46] <xteejx> huh??
[20:46] <xteejx> i dunno what they are
[20:46] <geser> those are two other missing build-dependencies
[20:46] <xteejx> oh :s
[20:47] <xteejx> geser: I'll reinstall the vm, this shouldn't be happening
[20:47] <geser> xteejx: or use pbuilder inside the vm
[20:48] <xteejx> it doesnt work :(
[20:48] <xteejx> brb
[21:00]  * fabrice_sp uses pbuilder in a vm in some cases
[21:01] <xteejx> Is it not possible to build natty packages in maverick with pbuilder??
[21:01] <fabrice_sp> of course it is
[21:01] <xteejx> oh...why the hell am I running a natty vm then?? lol
[21:01] <fabrice_sp> specify natty as distribution in pbuilder params
[21:01]  * ajmitch is building natty packages on lucid
[21:01] <fabrice_sp> only you know the answer to that question :-D
[21:01]  * xteejx is so dumb
[21:02] <xteejx> lol
[21:02] <ajmitch> it is useful to have a VM for testing though
[21:02] <xteejx> thanks :)
[21:02] <jcastro> not dumb, just working too hard for the simple answer. :)
[21:02] <xteejx> jcastro: hahaha I like that one, I might have to use it in future ;)
[21:03] <xteejx> Unrelated question: Is UDS going to be streamed? (I don't have much input, just want to see what happens)
[21:03] <jcastro> audio streams always
[21:03] <jcastro> video streams likely for the plenary sessions
[21:03] <xteejx> jcastro: What are plenary sessions?
[21:03] <jcastro> http://uds.ubuntu.com/participate/remote/
[21:04] <jcastro> the big meetings with everyone
[21:04] <xteejx> Ohh I see :)
[21:05] <ajmitch> plus realtime discussion on irc as well
[21:05] <xteejx> I don't plan on getting involved, another couple of years maybe ;)
[21:06] <ajmitch> why wait?
[21:07] <xteejx> I don't see an intermediate user like myself has much to say to Canonical about where they're taking Ubuntu
[21:08] <ajmitch> everyone has a say in how things are done. whether they agree with you is another matter, but you can at least be heard :)
[21:08] <xteejx> ajmitch: Hmm, I suppose so
[21:08] <xteejx> sudo pbuilder cteate --distribution natty << will that work?
[21:08]  * ajmitch has been to UDS a few times now & didn't feel like he was ignored
[21:08] <ajmitch> I think it should work
[21:09] <xteejx> If  I typed it correctly I mean :P
[21:09] <xteejx> Cool :)
[21:09] <micahg> xteejx: take a look at pbuilder-dist
[21:09] <fabrice_sp> I was going to say that :-)
[21:09] <xteejx> I'll man it
[21:11] <xteejx> micahg: That's pretty clever :) Thanks micah
[21:12] <micahg> xteejx: np
[21:13] <xteejx> Does pbuilder remove any build-deps for the next build you do?
[21:14] <ajmitch> every build is done in a clean chroot
[21:15] <xteejx> So it's just the base install then?
[21:15] <ajmitch> yes
[21:15] <xteejx> Oh that's good, much easier than doing it in a vm
[21:15] <fabrice_sp> yep: the build build is tarball is used as a basis for the build each time
[21:15] <ajmitch> it does cache copies of build-dependencies, so you don't have to download them for every build
[21:15] <xteejx> :)
[21:16] <geser> xteejx: pbuilder uses a base.tgz (which gets created with "create" :) which gets unpackage before build, chrooted into, build-deps installed, the package build (or not) and thrown away afterwards
[21:16] <xteejx> Andif the base files get updated, I just do pbuilder update ?
[21:17] <geser> exactly
[21:17] <xteejx> I think Mr Castro was right...doing things the hard way for an easy solution hehe
[21:17] <ari-tczew> xteejx: for forwarding changes to Debian you could use command: submittodebian
[21:17] <ajmitch> yep :)
[21:18] <xteejx> So another easy way instead of keep emailing them heh
[21:18] <geser> xteejx: and also "pbuilder-dist natty update" to update the Packages files (for apt) *inside* the pbuilder (so it knows about updated packages)
[21:18] <xteejx> I suppose with the repetitive stuff, things have to be made to make it easier :)
[21:19] <xteejx> geser: I get it :D
[21:19] <xteejx> Well this is definitely going to save time
[21:19] <ari-tczew> xteejx: or send mail to bug tracker in the form: http://paste.ubuntu.com/517032/ attaching patch(es)
[21:20] <xteejx> ari-tczew: I've been doing that, well without the tag bit :)
[21:20] <ari-tczew> I use above mail template. It's easier for me than milion questions from submittodebian.
[21:20] <xteejx> :D
[21:21] <ajmitch> or just do it manually if you like hard solutions :)
[21:21] <xteejx> hahaha ;)
[21:22] <xteejx> Is everyone here cheeky but funny? :P
[21:22] <ajmitch> no, I don't pretend to be funny
[21:22] <ari-tczew> ;o
[21:23] <xteejx> Well it's not working hehe
[21:23] <xteejx> or is...
[21:23] <xteejx> I hate double negatives, it always comes out wrong
[21:23] <ari-tczew> xteejx: are you going to do another MOTU activities as well?
[21:24] <xteejx> ari-tczew: I'm thinking of doing merges, have done 1 small bugfix (mostly luck with that one)
[21:24] <xteejx> I don't know really, I suppose I'll see which way the feeling takes me :)
[21:25] <ari-tczew> xteejx: we are looking for new contributors
[21:25] <xteejx> ari-tczew: Well I definitely try to muck in and help how I can
[21:25] <ari-tczew> within some days I'll start encourage on Polish forum to contribute to Ubuntu
[21:26] <xteejx> I'm not Polish
[21:26] <ari-tczew> xteejx: I just said where I want to look for new contributors.
[21:27] <xteejx> Ohh, sorry, I didn't understand :)
[21:27] <ari-tczew> xteejx: I noticed that there is a language problem in your communication.
[21:27]  * ajmitch should stir up some interested people in the loco channel :)
[21:27] <ari-tczew> as few minutes ago
[21:27] <xteejx> Mine?
[21:27] <xteejx> My English is perfect
[21:28] <xteejx> I was born and live here lol
[21:28] <ari-tczew> heh
[21:28] <xteejx> I'm just a little lazy with typing :P
[21:29] <xteejx> Am I right in thinking that pbuilder builds the .dsc's?
[21:29] <ari-tczew> xteejx: yes
[21:29] <xteejx> ari-tczew: Thank you :)
[21:35] <xteejx> If I make changes in the source, how do I create the .dsc to use pbuilder with?
[21:36] <micahg> xteejx: take a look at the options for debuild
[21:36] <xteejx> micahg: Is it debuild -S - I just want to ask first before I mess it up
[21:36] <geser> xteejx: debuild -S
[21:37] <micahg> xteejx: yeah, that'll make a source build
[21:37] <xteejx> Thanks guys :)
[21:37] <geser> you might want to add -us -uc if you don't want to get asked for signing it
[21:37] <xteejx> Ok :)
[21:38] <xteejx> "sudo pbuilder-dist natty build pybliographer_1.2.14-1ubuntu1.dsc" will test it right?
[21:39] <geser> yes
[21:39] <xteejx> I think I've got the hang of it now :)
[21:50] <xteejx> geser: pbuilder is still saying gnome-doc-utils not found
[21:50] <xteejx> I used debuild -S
[21:51] <geser> xteejx: as I said, gnome-doc-utils isn't enough
[21:51] <geser> look at the check before the check for gnome-doc-utils
[21:52] <xteejx> ahhh pkg-config I didn't see that :)
[21:52] <geser> you should see that it checks for pkg-config but doesn't find it
[21:58] <xteejx> hmm - "/bin/sh: scrollkeeper-config: not found" maybe scrollkepper too
[21:58] <xteejx> will have to check pkg name
[21:58] <geser> yes
[21:59] <xteejx> is it just scrollkeeper?
[21:59] <xteejx> ahh its a transitional pkg
[22:00] <geser> use packages.ubuntu.com to search which package contains such a named file (or use apt-file)
[22:00] <xteejx> ok thanks geser
[22:02] <xteejx> rarian-compat - apt-file, another thing being kept and used hehe
[22:14] <ajmitch> ScottK: sorry, I got distracted by a meeting at work as well this morning ;)
[22:14] <ScottK> ajmitch: No problem.
[22:16] <xteejx> bug 664108 updated and *really* fixed now :)
[22:16] <ScottK> Slow hard drive.  Still unpacking ...
[22:17]  * ajmitch would love an SSD to build on
[22:17]  * xteejx agrees with ajmitch
[22:17] <xteejx> bang, done
[22:17] <geser> xteejx: putting it in Build-Depends-Indep would be better
[22:17] <xteejx> geser: Really? What's the difference?
[22:18] <xteejx> Doing it now
[22:19] <geser> in practice it won't make any difference for this package but Build-Depends are build-dependencies for arch-dependent stuff while B-D-Indep for arch-independent stuff
[22:19] <xteejx> geser: Done
[22:20] <geser> xteejx: you know that you can delete attachments from a bug?
[22:20] <xteejx> so b-d-i would be more for python, i.e. xxx.yubuntuz_all packages?
[22:20] <ScottK> Yes.  Although anything needed for the clean rule to run goes in b-d and not b-d-i.
[22:20] <xteejx> geser: I do now
[22:20] <xteejx> Right, got it :)
[22:21] <geser> xteejx: the last debdiff is now the same as mine (modulo the changelog entry)
[22:21] <xteejx> geser: Woohoo, got there eventually ;)
[22:22] <geser> as usual don't forget to forward it to Debian
[22:22] <xteejx> And now I understand *why* it's like that, so it's win-win :)
[22:22] <xteejx> geser: Yup, already on it ;)
[22:22] <geser> will sponsor it tomorrow (if nobody beats me)
[22:22] <xteejx> Ok no probs
[22:36] <ScottK> ajmitch: Looks like it's not hard coded anymore, so a rebuild should do it.
[22:37] <ajmitch> yep
[22:37] <ajmitch> I'm just doing a rebuild locally after adding some patch header info
[22:37] <ScottK> Cool.
[22:37] <ajmitch> won't be long before I upload & you can find & retry those build failures
[22:41] <tumbleweed> xteejx: When you forward a bug to debian please link it to the lp bug. Also this one really should be serious in debian - FTBFS is RC.
[22:42] <xteejx> tumbleweed: Oops. RC?
[22:42] <tumbleweed> release critical
[22:43] <xteejx> Oh, I didn't realise :S
[22:52] <ScottK> Make sure it's FTBFS in Debian too.
[22:52] <tumbleweed> ScottK: it does :)
[22:52] <ajmitch>     ln -f -s 'libboost_python-py27.so.1.42.0' '/tmp/buildd/boost1.42-1.42.0/debian/tmp/usr/lib/libboost_python-py27.so'
[22:52] <ajmitch> looks like it's building with python 2.7 at least
[22:53] <ajmitch> still going of course :)
[22:56] <xteejx> How do I set critical when filing a bug to deb via email?
[22:57] <tumbleweed> xteejx: BTS is entirely e-mail driven http://www.debian.org/Bugs/ (I've bumped this ones severity for you)
[22:57] <micahg> xteejx: Debian actually has a larger range of Importance than LP, so you'll want to make sure it's actually critical
[22:57] <xteejx> So do it manually on the site?
[22:58] <micahg> xteejx: there's a BTS cli utility if you have a mail server set up
[22:58] <xteejx> micahg: I don't, and not sure how to do it
[22:58] <tumbleweed> the initial severity, tags, etc are set in the top of the body of your e-mail (psuedo-headers). You can change them later by mailing control@bugs.debian.org
[22:58] <xteejx> Too much messing around
[22:58] <xteejx> Oh right ok :)
[22:59] <tumbleweed> xteejx: you do run lintian, right? W: pybliographer: debian-changelog-line-too-long line 1
[22:59] <tumbleweed> ^ that's your entry
[22:59] <xteejx> :(
[23:01] <xteejx> Can I not just add + and paste it in?
[23:01] <tumbleweed> xteejx: I fixed it on upload. But if I don't tell you about it, you'll never know
[23:02] <xteejx> tumbleweed: Ok, I'll check the lintian errors in future, sorry about that
[23:03] <tumbleweed> most packages already cause lintian to complain. You just want to check that none of the (potential) issues are a problem for us, and that you aren't responsible for any of them
[23:06] <xteejx> tumbleweed: I understand :)
[23:34] <xteejx> bug 664209, another ftbfs fixed, debdiff should be perfect now
[23:49] <xteejx> What is the LDFLAGS for /usr/lib/libHalf.so.6 ?
[23:50] <tumbleweed> xteejx: do you notice that the -dev package for that has a .pc file, you should use that
[23:50] <xteejx> tumbleweed: I don't get what you mean
[23:52] <tumbleweed> dpkg -L libilmbase-dev | grep pc <- that file will help you
[23:53] <xteejx> tumbleweed: With that /usr/lib/libHalf.so.6 ?
[23:53] <tumbleweed> dpkg -S /usr/lib/libHalf.so.6 says libilmbase6
[23:53] <xteejx> Ohhhh, I thought you meant the bug I filed, sorry not thinking clearly
[23:54] <xteejx> So that package provides that file?
[23:54] <tumbleweed> read up on pkg-config
[23:55] <xteejx> I'm really confused, its cimg I'm doing now, it's a binutils-gold one
[23:55] <xteejx> I thought we had to add the appropriate -lXXX ?
[23:56] <tumbleweed> I haven't looked at this one, but presumaly they aren't using -lHalf like they should, and even the .pc file includes it, so they should probably be using pkg-config
[23:56] <xteejx> I don't understand enough about this to know why, or even what it is/does
[23:56] <xteejx> :(
[23:57] <tumbleweed> libraries are sometimes a little complex to use, so some provide scripts to output th ecorrect CFLAGS and LDFLAGS to link against them.
[23:57] <tumbleweed> pkg-config attempts to provide a common infrastructure for this
[23:58] <xteejx> so pkg-config when used in a package automatically configures the correct flags?
[23:59] <tumbleweed> $ pkg-config --libs IlmBase
[23:59] <tumbleweed> -lImath -lHalf -lIex -lIlmThread -lpthread
[23:59] <tumbleweed> of course not all libraries provide .pc files, and many are simple enough that they probably don't need to.
[23:59] <xteejx> do you mean that IlmBase provides those linker flags
[23:59] <xteejx> ?