[00:02] <blue_anna> libtool does :) compiled fine now
[01:16] <LLStarks> hi. how do i tag a bug requesting a package update?
[02:58] <crimsun> LLStarks: in .35? Should not be cause for alarm.
[03:19] <psusi> damn.... finally... got the new extent based mapping code working in e2defrag so instead of needing a gig of ram to map a 400 gig disk, it only needs 255 megs
[03:19] <psusi> only took me all week to get it working right...
[03:19] <psusi> blasted double binary tree forward and reverse indexes...
[03:20] <ion> :-)
[04:18] <Chipzz> psusi++ :)
[04:19] <psusi> testing on a 1.3 tb volume now ;)
[04:21] <psusi> hrm... now the allocation bitmaps are becoming a problem... need to do away with those....
[05:36] <pitti> Good morning
[06:11] <ajmitch> ls -la
[06:11] <ajmitch> oops :)
[08:10] <\sh> moins
[08:12] <\sh> pitti / doko: who is already awake and could point me to the changes in our default compile settings of maverick toolchain?
[08:23] <pitti> \sh: I don't know, I'm afraid
[08:29] <\sh> pitti, good morning :) well, then I'll wait for doko :)
[08:30] <geser> \sh: I've read on planet that maverick optimizes for 686 (-m686) on i386 now.
[08:30] <dholbach> good morning
[08:31] <hrw> geser: yes, thats true
[08:32] <pitti> hey dholbach
[08:33] <\sh> geser, yes..but I wonder what changed on amd64 because of this bug #585291
[08:34] <dholbach> hey pitti
[08:35] <\sh> or in other words, something strange happens on autotools front..because some values are not replaced correctly
[08:35] <RAOF> \sh: Does it build on i386?  Is that fallout of pkg-config being broken?
[08:37] <\sh> RAOF, just checking it...but I doubt pkg-config being broken, because all tests from configure regarding the libebook1.2{-dev} lib are correct..only the substituion of EBOOK_CFLAGS/EBOOK_LDFLAGS doesn't work somehow
[08:38] <RAOF> \sh: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583473 is the relevant bug.  We don't seem to have one in Ubuntu yet.
[08:39] <RAOF> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582995 being a better one.
[08:39] <RAOF> Is EBOOK_CFLAGS/EBOOK_LDFLAGS entirely unsubstituted, or does it contain improperly formatted stuff?  If the latter, blame pkg-config :)
[08:40] <\sh> RAOF, it's entirely unsubstituted...I build an amd64 chroot with all build-deps from giggle...and tried to compile manually
[08:41] <\sh> RAOF, same happens on i386
[08:41] <\sh> giggle-personal-details-window.c:30:29: error: libebook/e-book.h: No such file or directory
[08:42] <RAOF> I'd try building with pkg-config 0.25.
[08:42] <RAOF> That's not necessarily going to be the problem, but I know pkg-config is broken, so it's an easy target :)
[08:44] <RAOF> Would someone kindly kick off an autosync run?  It'd be nice for Xorg related packages to build, and the pkg-config 0.25 sync will accomplish that. ;)
[08:44] <hrw> guys - which doc you would suggest to get up to speed with bzr? I miss colored diffs, paged log/diff etc which I have outof-box with git
[08:45] <\sh> RAOF, hmm...0.25-1 in debian...we need a sync...I'll recompile 0.25 right now for me...and check if it help
[08:45] <\sh> s
[08:48] <\sh> ii  pkg-config                       0.25-1                    manage compile and link flags for libraries
[08:48] <\sh> giggle-personal-details-window.c:30:29: error: libebook/e-book.h: No such file or directory
[08:48] <\sh> it doesn't help
[08:51] <ttx> pitti: hey, is there some freeze in sync requests ? (or shortage of sync queue processors ?) I submitted bug 582312 two weeks ago... and it blocks the combined SRU for https://bugs.launchpad.net/ubuntu/lucid/+source/tomcat6
[08:52] <pitti> ttx: how does a maverick sync block an SRU?
[08:52] <pitti> there's no freeze, no
[08:52] <ttx> pitti: well, the fix is not in the development release yet, will be once the sync is done
[08:52] <pitti> ttx: that's ok at this time
[08:53] <pitti> ttx: the sync bug existence is sufficient for this
[08:53] <ttx> pitti: the SRU wasn't processed and I thought that was the reason why
[08:53] <pitti> SRU processing is a bit slow ATM, with Steve and me being in other teams now
[08:53] <ttx> pitti: that explains it, thanks
[09:02] <\sh> WTF...libunwind builds  with -U_FORTIFY_SOURCE on amd64...oh wow...I'm the road to success
[09:02] <\sh> I'm on the road ;)
[09:05] <pitti> \sh: the former too!
[09:05] <\sh> lol...now creating debdiff and hopeing for a sponsor ;)
[09:18] <\sh> dholbach, which sponsor team I need to subscribe for a main sponsor? ubuntu-sponsors or ubuntu-main-sponsors
[09:19] <dholbach> \sh: there only is ubuntu-sponsors now
[09:19] <\sh> dholbach, thx :)
[09:19] <dholbach> :)
[09:22] <\sh> so if some main uploaders are interested in giving me a hand, then bug #522106 is yours ;) thx
[09:59] <dupondje> When is the MoM page refreshed ?
[10:02] <ncopa> hi
[10:03] <ncopa> there was a web gui to browse the ubuntu kernel package build scripts
[10:03] <ncopa> i forgot where it was
[10:11] <sivang> morning all
[11:10] <ricotz> seb128, hello
[11:11] <ricotz> seb128, just want to point you to https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1154399/+listing-archive-extra, i have started gtk+3.0
[11:12] <seb128> ricotz, hi, ok
[11:12] <seb128> slomo, ^
[11:14] <ricotz> seb128, but there are some upstream issues which needs patched, but i386 should be fine
[11:15] <seb128> ricotz, ok
[11:16] <ricotz> seb128, there are surely still some conflicts with files of a gtk+2.0 installation, but it's a start
[11:16] <seb128> right
[12:57] <seb128> is some archive admin doing syncs?
[12:58] <seb128> I wanted to do some desktop ones but the queue is non empty
[13:24] <pitti> seb128: I did a few earlier on, let me check
[13:25] <seb128> pitti, danke
[13:25] <pitti> seb128: right, sorry; flushed now
[13:25] <seb128> danke
[13:38] <ebroder> kees: When you talk about "adding a kernel message" when the PTRACE fails, what do you mean? Something in dmesg?
[13:45] <sebner> pitti: ping
[13:51] <pitti> hello sebner
[13:51] <sebner> pitti: huhu :), just a quick question
[13:52] <sebner> pitti: https://bugs.edge.launchpad.net/docky/+bug/574003 , this still needs a SRU ack?! Besides debdiff should point to lucid-proposed?
[13:53] <pitti> sebner: someone else just asked me about that, I already ack'ed it
[13:53] <sebner> pitti: so *you* should upload it to proposed then?1
[13:53] <pitti> no, he said Laney was going to
[13:54] <sebner> pitti: laney is afk. So I'd do it. But I have to change it to lucid-proposed?!
[13:54] <pitti> yes
[13:57] <sebner> pitti: great, thx
[13:58] <ricotz> sebner, so you are on it now?
[13:58] <sebner> ricotz: you asked me to :P
[13:59] <ricotz> sebner, alright thanks!!!
[14:01] <sebner> ricotz: np, but your debdiff is b00rken. 2-3 things are targeted to 2.0.4 (directory-wise)
[14:01] <sebner> patching file docky-2.0.4/NEWS
[14:01] <sebner> bad ricotz :P
[14:01] <ricotz> sebner, please use from here https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1156209/+listing-archive-extra
[14:03] <sebner> ricotz: well, it's from 2.3.1 to 2.4 and not lucid version 2.0.2
[14:04] <pitti> sebner: you shouldn't attach the debdiff as it is
[14:04] <sebner> ricotz: nvm, give me some minutes
[14:04] <pitti> you need the new orig.tar.gz and a debdiff with just the debian/ changes
[14:04] <pitti> s/attach/apply/
[14:04] <sebner> pitti: I just thougth so :D
[14:19] <sebner> pitti: ricotz : Uploaded
[14:20] <ricotz> sebner, thank you!
[14:20] <sebner> ricotz: np, I hope I didn't break anything :P
[14:20]  * sebner forgot the -v flag. bad sebner
[14:23] <sebner> pitti: approve approve approve, mind giving a SRU for another app?
[14:23]  * pitti points out that he's on rotation this cycle, and thus not working in platform/SRU
[14:23] <pitti> at least not as main contributor
[14:24] <sebner> pitti: it's a veeeeeery smal one
[14:25] <sebner> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/themonospot/+bug/533747
[14:26] <pitti> if it's an appropriate SRU, please just get it uploaded to the queue for review
[14:26] <pitti> and someone will get to it
[14:28] <sebner> pitti: aye, thx
[15:48] <ebroder> Where's the right place to ask questions about how indicator-applet works? I'm staring at source code and not really understanding what's going on
[15:53] <\sh> stgraber, ping
[15:54] <hrw> doko_: can you take a look at https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/587851 patch?
[16:01] <\sh> stgraber, when you have time, I would like to talk to you about your changes inside initramfs and not using ipconfig for dhcp requests...
[16:10] <ScottK> pitti: Would you please rescore kde4libs on powerpc?
[16:11] <ScottK> pitti: Speaking of sru reviews, did you see the LP queue page provides a link to the package diff now?
[16:11] <pitti> ScottK: bumped
[16:11] <pitti> ScottK: ooh! no, I didn't
[16:11] <ScottK> pitti: Thanks.
[16:12] <pitti> nice; still missing the bug refs, but it's a step forward
[16:15] <pitti> mr_pouit: how are patches handled in the XFCE team? I reported bug 587933, should I subscribe or assign to a team etc.? Or do you guys read all bug mail?
[16:16] <ScottK> pitti: I suspect if you discuss the need with wgrant it would semi-magically happen.
[16:31] <\sh> bah....initramfs.conf: DEVICE=all -> dhcp requests on all NICs...when at least 2 NICs get the DHCP IP from the DHCP Server, kernel crashes
[16:31] <\sh> ipconfig is stupid
[16:38] <quadrispro> pitti, would you help me to maintain python-gudev in Debian?
[16:44] <pitti> quadrispro: can do, is there a request for it now?
[16:44] <pitti> quadrispro: it only got one upload ever, and basically "just works", so it's not a real effort anyway
[16:44] <pitti> so i'm happy to upload it to Debian if there's a demand for it (RFP?)
[16:44] <pitti> quadrispro: but NB that it will hopefully go away entirely with gobject introspection
[16:47] <quadrispro> pitti, there's an ITP bug -> #583863, I opened it today because a package of mine needs it as dependency
[16:48] <pitti> quadrispro: if you want me, I can upload it to Debian NEW with that ITP bug right now
[16:50] <quadrispro> pitti, I'm working on the packaging via git -> http://git.debian.org/?p=collab-maint/python-gudev.git and yes, I would be very happy, I've become DD just today but I'm waiting for getting my account works fine
[16:50] <pitti> quadrispro: ooh, congratulations!
[16:50] <zyga> mvo, hi could you please fix that apt bash_completion issue/
[16:50] <quadrispro> pitti, thanks :) can I add you as co-maintainer?
[16:51] <pitti> quadrispro: please do; I can sponsor it until you get your account
[16:52] <pitti> quadrispro: is it based on the Ubuntu packaging, or did you change a lot (in particular, structure of the packages)?
[16:52] <pitti> i. e. can we just sync this?
[16:53] <quadrispro> pitti, I've changed something, I think we can sync it without any problem
[16:53] <quadrispro> anyway
[16:54] <quadrispro> pitti, BTW, testbuilding for sure right now, I'll let you know
[16:56] <mvo> zyga: hello - which one?
[16:57] <mvo> zyga: is it a issue in apt or in bash-completion?
[16:57] <zyga> mvo, hi
[16:57] <zyga> mvo, the one that spams bash completion script syntax issue on each terminal
[16:57] <ebroder> mvo: bug #546794
[16:58] <zyga> http://pastebin.ubuntu.com/442337/
[16:59] <zyga> mvo, I could do it locally but I cannot upload anything to the archive and I image it annoys everyone on maverick
[16:59] <quadrispro> pitti, ready to go http://debomatic.debian.net/maverick/pool/python-gudev_147.1-1/
[17:00] <zyga> O_o!!!!
[17:00] <zyga> multiarch!?!?!
[17:00] <zyga>  :D
[17:00] <zyga> yeeeahhoooo
[17:00] <mvo> zyga: I check it out
[17:00] <zyga> mvo, thanks
[17:01] <mvo> zyga: it seems that ev uploaded it, if its not super anoying I would prefer to wait until tomorrow when he is availalble for comment?
[17:02] <mvo> zyga: I mark it as a alpha-1 target in the bug
[17:02] <zyga> mvo, sure, no rush - I thought you deal with that part
[17:02] <mvo> zyga: I do with the apt bits :)
[17:03] <zyga> mvo, err, I cannot target this for anything
[17:03] <mvo> thanks for brining it up, if ev does not come up with a nicer fix I will upload the revert
[17:07] <hrw> have a nice rest of day
[17:07] <hrw> doko__: I attached new version of patch to the bug
[17:10] <pitti> quadrispro: ok, will sponsor in a bit
[17:10]  * pitti waves good bye for toda
[17:10] <ogra_cmpc> ciao pitti
[17:14] <didrocks> have a good evening pitti
[17:32]  * quadrispro leaving
[17:46] <pitti> quadrispro: oh argh; debian/changelog says "maverick", so that sid upload will fail
[17:47] <pitti> quadrispro: shall I change it in git and reupload?
[17:47] <pitti> oh, it's already changed in git
[17:50] <maco> as of 10.10, u/k/x all use pulseaudio. festival umm...falls over.. if you have pulse running but it hasnt been configured to use it. so i want to make festival's default config be pulse-aware in mav. does this mean i should add a pulse recommends too, since the pulse-aware default config *wont* be happy without pulse? (its not a compile issue, its a text file issue)
[17:50] <mr_pouit> pitti: yeah, I read all bugmail
[17:52] <maco> pitti: by the way, bug 550145 ... should i upload with a modified version string? if so, should that be 0.9.9.8.6-2~ubuntu1 ?
[18:38] <\sh> is it possible to "echo foo" inside initramfs-tools shell scripts?
[18:45] <dupondje> seems like we need some sparc build boxes :D
[18:47] <micahg> dupondje: I think sparc is going away
[18:47] <dupondje> 772 jobs (three days) in queue now ... :(
[18:55] <pitti> quadrispro: I tagged debian/147.1-1 in git
[18:57] <ScottK> micahg: Unless someone appears to take over toolchain maintenance.
[18:58] <ScottK> If dupondje is volunteering for that, then build boxes can be made available, I'm confident.
[18:58] <kees> ebroder: yeah.  "user foo attempted to PTRACE process bar but sys.kernel.ptrace_scope is set to 1" or something
[18:59] <ebroder> kees: Ok, that's what I was figuring. I'm not a huge fan of that, because dmesg is not where I think to look when I get an EPERM
[18:59] <pitti> maco: how about 0.9.9.8.6-2~lucid1?
[18:59]  * pitti -> really off now
[18:59] <maco> pitti: can do
[18:59] <kees> ebroder: right, which is why I'm trying to solicit ideas.  this is a really awkward change in logic.
[19:00] <ebroder> kees: How do you feel about my idea to patch gdb and strace and possibly any other popular users of ptrace?
[19:00] <kees> ebroder: and it's possible everyone will hate it so much that it gets pulled from maverick.
[19:00] <ScottK> kees: Please don't do the "If you have package foo installed you're a developer and don't want that" approach.
[19:00] <kees> ebroder: yeah, that's another possibility.  (I'm on holiday today so I haven't read through the email thread yet)
[19:01] <ebroder> kees: Ah, right - I keep forgetting today's a holiday. I'll wait to pick your brain until tomorrow, then :)
[19:01]  * \sh hates initramfs and klibcs ipconfig crap
[19:02] <kees> ebroder: heh, no worries.  thanks for the idea, it seems like another good thing to add.
[19:11] <quadrispro> pitti, thank you very much!
[19:11] <sebner> quadrispro: congratulations from me too!
[19:12] <quadrispro> thanks sebner
[19:12] <sebner> quadrispro: DktrKranz told me to shower you with sponsoring requests :P
[19:12] <quadrispro> ahh lol
[19:12] <quadrispro> DktrKranz was drunk :P
[19:12]  * sebner pets hyperair 
[19:13] <sebner> quadrispro: DktrKranz is always drunk (at least if wine is near)+
[19:14] <quadrispro> sebner, you're right, take a look at this http://www.ipernity.com/doc/milo/8118610
[19:17] <sebner> quadrispro: lame. Don't you know the ubuntu-it meeting photos from a few days ago? :P
[19:21] <quadrispro> sebner, it's just of u-i-meeting, but this http://www.ipernity.com/doc/milo/8118618/in/album/189792 is my favorite one
[19:21] <quadrispro> an ubuntu-it-meeting without DktrKranz doesn't make sense at all :P
[19:21] <sebner> heh
[19:21] <sebner> full ack
[19:22] <quadrispro> eh eh eh
[19:23]  * quadrispro tries to see if alioth gets him as DD
[19:26] <iulian> quadrispro iz a deedee?
[19:27] <quadrispro> iulian, yep
[19:27] <iulian> Awesome.  Buy me a drink then?
[19:27] <iulian> :-)
[19:28] <quadrispro> of course!
[19:28] <sebner> iulian: lol, shouldn't it be the other way round?
[19:28] <ScottK> quadrispro: When you get it figured out how to change your alioth account, please let me know.  Congratulations.
[19:29] <iulian> quadrispro: Congratulations!
[19:29] <iulian> sebner: Hell no. :)
[19:29] <quadrispro> ScottK, congrats to you too! I'm trying, and trying, and trying
[19:30] <ScottK> Thanks.
[19:30] <iulian> Scott's a deedee as well?
[19:31] <iulian> Yikes!  New sponsors!
[19:31] <quadrispro> ScottK, does alioth already have our new account, isn'it?
[19:31] <iulian> ScottK: Congratulations to you to.
[19:31] <iulian> s/to/too/
[19:31] <ScottK> iulian: Thanks.
[19:31] <ScottK> quadrispro: I think you have to do some procedure to get it converted.
[19:34] <quadrispro> ScottK, have you already requested a new password?
[19:35] <ScottK> No.
[19:35] <ScottK> Didn't do anything yet, but this is also OT here.
[19:38] <quadrispro> yes, it is
[19:40] <sebner> ScottK: uhh, congratulations from me too. Trying to take over the world, hmm? =)
[19:40] <taavikko> Just a quick guestion, it is intended that ffmpeg-extras doesn't ship with the .so files atm in maverick?
[19:40] <ScottK> sebner: Thanks.
[19:40] <ebroder> taavikko: I think it's bug #587424
[19:41]  * hyperair pets sebner
[19:41] <taavikko> thanks, ebroder :)
[19:51] <\sh> ScottK, DD? Oh man...you rock :) Congrats :)
[19:51] <ScottK> \sh: Thanks.
[19:52]  * sebner waves at \sh :D
[19:52] <\sh> hey sebner
[19:53] <dupondje> When does the MoM pages get refreshed ?
[19:53] <dupondje> :)
[19:59] <ScottK> dupondje: It's either every hour or every 6 hours, I don't recall.
[20:01] <ari-tczew> dupondje: apart from MoM is exist lucas merges
[20:40] <apachelogger> jcastro: ping, ScottK suggested that summit.ubuntu.com might have advanced scheduling magic and is $free_software, is that true, if so, where to find the source?
[20:40] <sebner> beer + pink is a bad combination for apachelogger :P
[20:41] <apachelogger> fortunately I am all out of beer :P
[20:41] <sebner> heh
[20:57] <ScottK> pitti: Would you please rescore soprano on armel.
[21:21] <geser> apachelogger: https://edge.launchpad.net/summit
[21:30] <apachelogger> geser: thanks
[21:30] <apachelogger> jcastro: unping :)
[21:32] <bdrung> mdz: regarding de-native-ization (email): i didn't ask for de-native-ization lintian. most of the listed tools are useful for debian-based system. having it in debian first will have them in the derived distros easily. so i see no value of de-native-ization unless someone convinces me with good arguments.
[21:59] <psusi> how does one get autoconf to add a bloody -I to the cflags?
[21:59] <ebroder> CFLAGS="$CFLAGS -I/my/path"?
[21:59] <psusi> clfags is not defined in configure.in
[22:00] <psusi> it's all these damn macros that the man page doesn't document
[22:00] <hyperair> psusi: it should be automake, not autoconf.
[22:01] <Chipzz> hyperair: actually no, I think
[22:01] <hyperair> otherwise try using AC_SUBST with AM_CFLAGS or something.
[22:01] <psusi> don't have a .in
[22:01] <psusi> err, .am rather
[22:01] <hyperair> Chipzz: ?
[22:02] <Chipzz> hyperair: actually I *think* configure will pass on CFLAGS passed in to it to automake generated makefiles as default
[22:02] <psusi> just have configure.in that seems autoconf turns into configure
[22:02] <Chipzz> if I'm not mistaken
[22:02] <Chipzz> but I may be
[22:02] <hyperair> Chipzz: oh yeah, you're right, i forgot.
[22:02] <psusi> hrm...
[22:02] <hyperair> but the right place to be adding -I things is in automake
[22:02] <hyperair> in the Makefile.am files, not using autoconf.
[22:03] <Chipzz> true, but autoconf *can* be involved too :)
[22:03] <Chipzz> if you want it too :P
[22:03] <Chipzz> nasty sh**, auto* :)
[22:03] <Chipzz> but well-tested and good-working crossplatform sh** ;P
[22:03] <hyperair> lol
[22:04] <hyperair> autotools is powerful, if you've actually bothered to learn it properly.
[22:04] <hyperair> it's very easy to write a shitty build system using autotools.
[22:04] <hyperair> in the same way it's easy to write a shitty program in any programming language out there.
[22:05] <hyperair> and for that reason i'm saying -I should be in the Makefile.am files, and configure.in shouldn't be touching the CFLAGS.
[22:05] <hyperair> or configure.ac for that matter.
[22:05]  * psusi just wants to bloody stick with a Makefile
[22:06] <hyperair> ?
[22:06] <psusi> instead of using auto*
[22:06] <hyperair> custom-written Makefiles are more often than not, terrible.
[22:06] <psusi> damn annoying that you have to muck about with it
[22:06] <hyperair> go and read a proper tutorial
[22:06] <hyperair> adn learn it properly
[22:07] <psusi> compile object, link... why's it so difficult that you need a dozen damn tools to translate through 3 layers of macros before you get to a makefile?
[22:07] <hyperair> for cross platform things.
[22:07] <hyperair> and for cross-compilation support
[22:08] <hyperair> and for automatic dependency resolution (header files)
[22:08] <Chipzz> and for out-of-tree compilation support
[22:08] <hyperair> and it's not a dozen, mind.
[22:08] <hyperair> it's just two: autoconf, automake.
[22:08] <Chipzz> and libtool
[22:08] <hyperair> libtool is optional.
[22:08] <psusi> and pkg-tool
[22:08] <Chipzz> so is automake
[22:09] <hyperair> pkg-config is separate.
[22:09] <psusi> which I'm NOT bothering to use since it looks like I'd have to add a custom macro file for autoconf
[22:09]  * hyperair clubs psusi over the head and throws him into a ditch.
[22:09] <psusi> seems that just adding the two -I flags that glib needs to CFLAGS near the start of configure.in did the trick
[22:09] <psusi> hehe
[22:10] <Chipzz> naughty psusi :)
[22:10] <hyperair> i'm not touching any build system you write with a 10-metre long stick.
[22:10] <hyperair> use the damn PKG_CHECK_MODULES, it's automatically handled for you goddamnit
[22:10]  * psusi substitutes himself with a baby seal
[22:10] <Chipzz> s/psusi/baby seal/g ? :P
[22:10] <hyperair> sorry, i chattr +i'd psusi.
[22:11] <psusi> I don't want any build system... I just want a makefile, but this seems to already be using autoconf 2.13 and I used glib for the binary tree implementation
[22:11] <hyperair> a Makefile is a build system.
[22:11] <hyperair> a terribly primitive build system that won't scale
[22:11] <hyperair> and will not work with the next *nix platform.
[22:12] <hyperair> or even the same platform, but different architecture.
[22:12] <psusi> why not?
[22:12] <hyperair> well it might, through some stroke of luck.
[22:12] <hyperair> but it most probably won't, e.g. some distros have libs in /usr/lib64, some have it in /usr/lib
[22:12] <hyperair> some have /usr/lib32
[22:12] <hyperair> and so on
[22:13] <psusi> why do they have to do stupid things that need automagic configuration?  like putting the gconf headers in two different directories that are not already on the standard search path...
[22:13] <hyperair> namespace clashes.
[22:13] <hyperair> duh.
[22:14] <psusi> how many different gconf-2.0/xxxxx.h files are there? ;)
[22:14] <hyperair> many.
[22:14] <hyperair> and also to provide for the future.
[22:14] <psusi> how?  there should only be one gconf-2.0...
[22:15] <psusi> err, glib, not gconf...
[22:16]  * psusi facepalms
[22:16] <hyperair> it's glib-2.0/glib/xxx.h
[22:16] <hyperair> fyi.
[22:16] <hyperair> 2.0 is the API version
[22:16] <hyperair> there can be a glib-2.1
[22:16] <hyperair> or even a glib-3.0
[22:16] <hyperair> and it should co-exist.
[22:16] <psusi> I was in the wrong directory... built gparted instead of defrag... seems that defining CFLAGS in the configure.in did NOT get it
[22:17] <psusi> hence the -2.0 in the path name
[22:17] <hyperair> well duh.
[22:17] <psusi> so why can't you just include <glib-2.0/glib.h> and be done with it?
[22:18] <hyperair> i suppose you enjoy changing the pathnames of your header files when glib goes on to 2.1
[22:18] <psusi> apparently I specifically want 2.0, otherwise I'd have not been specific in the path name
[22:20] <hyperair> apparently you refuse to plan for the future.
[22:21] <hyperair> anyway, enough of this. i'm going to bed. you can continue with your stupid habits, or you can take the time to learn exactly why things are the way they are before blindly criticizing them.
[22:22] <psusi> I guess I'm going to have to since everyone uses it, I"m just sick and tired of having to jump through multiple hoops just to disable the damn optimizer so I can use gdb properly because of these things, and the man page is next to useless
[22:22] <hyperair> make CFLAGS="-O0"
[22:22] <hyperair> finish.
[23:07] <wgrant> pitti: Yeah, I thought about the bugs problem. It's a bit harder, and may have some performance implications, but it's something I want to do.