[03:03] <linos2> has anyone see an error like this X Error: BadDevice, invalid or uninitialized input device 168
[03:06] <Hobbsee> linos2: please see the /topic
[03:06] <Hobbsee> (and if you put that error into google, you'll find the answer, too)
[03:07] <linos2> Hobbsee, sorry about that..... thank you
[06:15] <monzie> Hi all
[06:15] <monzie> What happenned to the libapache-mod-ssl package?
[06:15] <monzie> It was there in 7.04 but is not in 7.10
[06:16] <monzie> If it has been taken out for a reason, can someone please tell me how to install mod-ssl on 7.10
[06:16] <monzie> !ubotu apache
[06:16] <ubotu> LAMP is an acronym for Linux-Apache-MySQL-PHP. However, the term is often used for setups using alternative but different software, such as Perl or Python instead of PHP, and Postgres instead of MySQL. For help with setting up LAMP on Ubuntu, see  https://help.ubuntu.com/community/ApacheMySQLPHP - See also the Server CD installation process (different in Edgy+)
[06:17] <StevenK> monzie: Use Apache 2, it includes SSL.
[06:17] <Mithrandir> monzie: apache 1 is dead and has been for a while; you should have migrated to Apache 2 by now.
[06:17] <ScottK> monzie: #ubuntu-server is a better place for that kind of question, but StevenK is, as usual, right.
[06:17] <Mithrandir> morning, StevenK
[06:17] <StevenK> morning Mithrandir
[06:18] <monzie> StevenK:  i have Apache2
[06:18] <StevenK> monzie: Then you don't need libapache-mod-ssl, that's for Apache 1
[06:18] <Mithrandir> all libapache-* modules are for apache 1
[06:19] <StevenK> That too.
[06:19] <monzie> ok
[06:19] <monzie> StevenK, Mithrandir: http://pastebin.ca/867200 ( that's the output of apache2 -l on my sytem)
[06:19] <monzie> I cant see SSL there
[06:20] <StevenK> Then the module isn't enabled.
[06:20] <StevenK> monzie: Run 'a2enmod ssl'
[06:20] <Mithrandir> : tfheen@xoog ~ > ldd =apache2 | grep ssl
[06:20] <Mithrandir>         libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00007fb5ae419000)
[06:21] <monzie> StevenK: thanks!
[06:21] <StevenK> monzie: No problem.
[06:21] <monzie> StevenK: I am sure there was a a reason for not having a "libapache2-mod-ssl" I guess
[06:22] <StevenK> Yes, because it's included in the Apache 2 package.
[06:22] <monzie> ok
[06:22] <monzie> Thanks room!
[07:00] <warp10> Good morning
[07:12]  * Mithrandir idly wonders when ooo-l10n is going to be fixed.
[08:49] <carlos> pitti: good morning
[08:55] <pitti> hey carlos, good morning
[08:56] <carlos> pitti: I wonder whether you managed to get .deb packages for Hardy language packs
[08:56] <carlos> or did you delegate it already ?
[08:56] <thegodfather> morning pitti
[08:58] <pitti> carlos: I just got jtv's /msg that they are ready
[08:58] <pitti> carlos: I think I'll sit down with Arne today and show him how to build them
[08:59] <carlos> ok, I thought you had your script executed automatically ;-)
[09:00] <carlos> pitti: I will need to ask you to remove all lang_country directories again as we did with latest Gutsy lang pack....
[09:00] <pitti> carlos: oh, thanks for the warning
[09:03] <carlos> pitti: btw, full Hardy export took only 15 hours 20 minutes
[09:03] <carlos> pitti: so we don't need to wait 2-3 days to get one
[09:03] <carlos> anymore
[09:04] <pitti> \o/
[09:04] <carlos> pitti: that's using production, no need to use a mirror so we get latest information available in Launchpad
[09:06] <carlos> pitti: btw, we are going to announce Hardy translations opening today and I wonder whether we could announce also that starting later today or tomorrow we would have language packs updated twice per week
[09:07] <pitti> carlos: yes, please do announce it; I'll either sit down with Arne today or do it myself
[09:08] <pitti> carlos: but it'll be a few hours/a day, since they take quite some time to build
[09:08] <carlos> ok, thank you
[09:08] <carlos> so we will say in next days
[09:08] <carlos> "in next days"
[09:08] <carlos> pitti: thanks for handling this
[09:09] <Robot101> "in the next few days" would be more idiomatic :)
[09:09] <carlos> Robot101: thanks ;-)
[09:15] <geser> good morning
[09:15] <geser> pitti: Hi, as you merged debhelper in the past have you time to review bug #184545?
[09:15] <ubotu> Launchpad bug 184545 in debhelper "[Merge] debhelper (6.0.2ubuntu1)" [Undecided,New] https://launchpad.net/bugs/184545
[09:16] <pitti> geser: I am fine to do it, I just don't know when I'll be able to; can you please subscribe me, so that I'll get a bug mail?
[09:17] <geser> pitti: done and thanks
[09:37] <geser> pitti: please give-back: haskell-cgi haskell-glut haskell-openal hslogger. Thanks
[09:38] <pitti> geser: done
[09:49] <dholbach> thekorn, bdmurray: could it be that pylpbugs broke?
[09:50] <dholbach> thekorn, bdmurray: http://paste.ubuntu.com/3743/
[09:58] <thekorn> dholbach, hi, will have a look at this during my lunch-break
[10:04] <dholbach> thekorn: you ROCK
[10:49] <LucidFox> Is https://wiki.ubuntu.com/No-Mono-by-Default relevant anymore?
[10:50] <ogra> LucidFox, look at the LP spec page, it should tell you the status
[10:50] <mjg59> LucidFox: What do you mean by relevant?
[10:50] <mjg59> It's not an approved spec
[10:51] <ogra> (if it was even approved to be implemented etc)
[10:51] <mjg59> So it's as relevant as it was when it was written (arguably not very)
[10:51] <LucidFox> it says review
[10:52] <LucidFox> The issue is, someone is asserting that Mono will be removed from the default installation, and points me to that page
[10:52] <ogra> thats nonsense
[10:52] <LucidFox> I want to repel his argument
[10:52] <ogra> we just moved f-spot to be the default photo app
[10:52] <ogra> would be silly to drop mono *now* :)
[10:53] <ogra> mjg59, do you plan to drop by this week in th eoffice ?
[10:54] <mjg59> ogra: With luck, on Wednesday
[10:55] <ogra> cool !
[10:55] <keescook> mjg59: saaay... is there a way to access the CPU thermal sensors on the core 2 duo/quad cpus?  (I don't seem to have an ACPI output for it on my desktop)
[10:56] <mjg59> keescook: Hm. I think someone wrote a driver to do that.
[10:56] <keescook> mjg59: ah, have an pointers to it?  I've been having a bad time googling for such things.  :P
[10:57] <mjg59> Yeah, having some trouble finding it
[10:58] <mjg59> keescook: http://www.lm-sensors.org/wiki/Devices suggests lm-sensors has one (coretemp)
[10:59] <keescook> ah!  I thought lm sensors was deprecated in favor of the acpi goo
[10:59] <mjg59> If acpi doesn't provide it, deprecation isn't helpful :)
[10:59] <keescook> well, heh, yeah.  :)
[10:59] <mjg59> We seem to ship a version of coretemp
[11:00] <mjg59> But it doesn't /seem/ to bind for me
[11:00] <mjg59> Oh, no, wait
[11:00] <mjg59> It just doesn't print anything to dmsg - I've got stuff in /sys/devices/platform
[11:01] <keescook> ah-ha!
[11:01] <keescook> one for each cpu.  :)  hmmm... which actually has the current value...
[11:02] <mjg59> temp1_input
[11:05] <Company> it works on my macbook
[11:05] <Company> with lmsensors
[11:05] <keescook> mjg59: cool, thanks.  "sensors" reports them all happily. whee
[11:11] <stgraber> moin
[11:17] <monzie> Hi all
[11:17] <monzie> how do i generated Apache certificates in Ubuntu 7.10?
[11:18] <monzie> apparently the "apache2-ssl-certificate" packages has been taken out
[11:18] <monzie> I am following https://help.ubuntu.com/community/forum/server/apache2/SSL
[11:55] <thekorn_> dholbach: this error is weird, I can't reproduce it,
[11:56] <thekorn_> which version of py-lp-bugs are you using, do you have local (uncommited) changes in sponsoring or py-lp-bugs?
[12:01] <dholbach> thekorn_:  no, none :-/
[12:57] <ganesh> i installed ubiquity & created a live cd but it is not installing from that cd , help me to resolve my problem
[12:57] <ganesh> ln-, yeah it a development question
[13:02]  * sistpoty|work is away: coffee break
[13:08] <calc> any ubuntustudio people here? i forgot who was nagging me about OOo before
[13:09] <calc> i have a question for them when/if they show up
[13:12] <zul> pitti: can we get xen-3.2 out of new?
[13:13] <pitti> zul: yes, it's just a matter of finding some time to attack NEW
[13:13] <_MMA_> calc: I'm in whatever channel you wanna talk in. :P
[13:14] <zul> pitti: great, no problem
[13:18] <TheMuso> calc: yes, I am around.
[13:33] <tbf> what's the rationale behind installing .la files?
[13:33] <tbf> they only cause trouble?
[13:34] <tbf> s/trouble?/trouble!/
[13:38] <Chipzz> tbf: I wouldn't say everyone here is positive about installing .la files (ie some/a lot of people here share your opinion)
[13:39] <tbf> Chipzz: well, that's why i ask for the rationale
[13:40] <seb128> you need those to do static building
[13:40] <slangasek> not if you have .pc files
[13:40] <seb128> right
[13:41] <slangasek> tbf: the sole rationale for installing .la files is that they facilitate static linking using metadata that's available in the same directory as the lib itself, without having to centrally register the information (i.e., with pkg-config)
[13:41] <slangasek> tbf: IMHO this doesn't outweigh the various disadvantages of installing them; so for the most part I would say there's no "rationale" for installing them in Ubuntu, they're just installed because this is what libtool does by default
[13:42] <Chipzz> tbf: oe of the problems with .la files is that if you wanted to get rid of them, you would have to do so top-down
[13:42] <tbf> seb128: the only guys how need static linking a propritary software vendors....
[13:42] <Chipzz> *one
[13:42] <tbf> seb128: and most of the time even they cannot make use of it, since the libs they want to link are LGPL
[13:42] <Mithrandir> tbf: no, that is wrong.
[13:43] <Mithrandir> like, sash is a perfectly good example of a tool that needs to be statically linked.
[13:43] <tbf> Mithrandir: ok, one additional case exists: boot imagges
[13:43] <Mithrandir> why would boot images need to be statically linked?
[13:43] <tbf> Mithrandir: but for the entire gnome stack for instance it is pointless to link statically
[13:43] <tbf> Mithrandir: 'cause you can strip unneeded symbols
[13:44] <tbf> Mithrandir: without dynamic linking you need the entire libc, with static linking you just need space for the code you really use
[13:44] <Mithrandir> tbf: I know how static linking works.  I was contradicting your claim that static linking is only useful for proprietary software authors.
[13:47] <tbf> hmm... maybe want some libtool switch "no, no f***ing .la file, please"
[13:47] <seb128> tbf: stop using libtool if you don't need it?
[13:47] <tbf> seb128: were is the camera?
[13:48] <seb128> ?
[13:50] <tbf> seb128: well, from your words i guess this is a hidden camera show
[13:51] <seb128> tbf: that's what Keybuk suggested previous time there was a similar discussion on this chan, if you don't want la files you don't need to use libtool there is easier way to get a library built
[13:51] <tbf> seb128: libtool does some useful stuff, and the only result of not using it, are many bug reports for your gnome packages
[13:51] <tbf> "migrate to libtool please"
[13:52] <tbf> seb128: well, but for gnome packages, libtool's la files don't make any sense, as gnome files have that information in their .pc files
[13:52] <tbf> s/gnome files/gnome libraries/
[13:52] <seb128> tbf: so why not stop building those?
[13:53] <tbf> seb128: the pc files?
[13:53] <seb128> no the la
[13:53] <tbf> seb128: well, stopping to build .la files is exactly what i want
[13:53] <ganesh> i installed ubiquity & created a live cd but it is not installing from that cd , help me to resolve my problem
[13:54] <tbf> seb128: i want to tell libtool "do not build .la files for this library"
[13:54] <seb128> tbf: you might get the "stop using libtool if you don't need it" reply
[13:55] <tbf> seb128: libtool knows how to build shared libraries on solaris and with mingw32 for instance...
[13:55] <tbf> seb128: also automake works much better with libtool, than without
[13:56] <seb128> I don't know enough about libtool to discuss that
[13:57] <Keybuk> tbf: don't use libtool
[13:57] <Keybuk> for gnome packages, pkg-config provides all the answers
[13:57] <Keybuk> libtool is unnecessary
[14:00] <tbf> Keybuk: the opensolaris guys will disagree, for instance
[14:00] <Keybuk> tbf: but you just said you don't care about portability
[14:00]  * sistpoty|work is back
[14:00] <tbf> Keybuk: how that?
[14:00] <Keybuk> you *need* .la files on solaris
[14:01] <Keybuk> if you delete them, you're declaring that you only care about Linux
[14:01] <tbf> nice
[14:01] <Keybuk> since you're using knowledge about the Linux dynamic link loader
[14:01] <tbf> Keybuk: so how can i rid of them on linux, please?
[14:01] <Keybuk> tbf: don't use libtool
[14:01] <tbf> Keybuk: why do you try to be an idiot?
[14:02] <Keybuk> tbf: ?  I'm not being an idiot
[14:02] <tbf> Keybuk: i never said you are one.
 Keybuk: why do you try to be an idiot?
[14:02] <Spads> Keybuk: why do you *fail* at being an idiot?
[14:02] <tbf> Keybuk: trying is different from being
[14:03] <Keybuk> tbf: http://www.ubuntu.com/community/conduct
[14:03] <Keybuk> tbf: please read that, carefully
[14:03] <tbf> Keybuk: guess you also should read it
[14:04] <ganesh> i installed ubiquity & created a live cd but it is not installing from that cd , help me to resolve my problem
[14:04] <Mithrandir> tbf: it would help if you stopped coming across as so agressive.
[14:04] <tbf> Keybuk: repeating "don't use libtool" really doesn't help, if the person you talk to repeatedly say, that he needs most features of libtool
[14:04] <Mithrandir> ganesh: you're off-topic for this channel; please take it elsewhere (#ubuntu-installer, possibly)
[14:05] <Keybuk> tbf: libtool has one feature
[14:05] <Keybuk> it provides a common interface to shared library generation across all platforms
[14:05] <Keybuk> you've said you do not want that feature
[14:05] <Keybuk> ergo you do not want to use libtool
[14:05] <Keybuk> libtool does *nothing* else
[14:05] <Keybuk> if you remove .la files, you are deliberately breaking libtool and attempting to circumvent it
[14:05] <Keybuk> at which point, why use it at all?
[14:05] <ganesh> Mithrandir, ok
[14:06] <Mithrandir> Keybuk: hmm?  Doesn't it track dependencies between static .a libraries and help you link them into a static object?
[14:06] <tbf> Keybuk: group pressure?
[14:06] <Keybuk> Mithrandir: only if you use .la files
[14:06] <Keybuk> as soon as you delete .la files, you can no longer do that
[14:06] <Chipzz> Keybuk: your argument is flawed; you do want the common interface, but you do not actually need the .la files for obtaining that goal *on linux*, just on *other platforms*
[14:06] <Keybuk> at which point, why use libtool at all
[14:06] <Chipzz> but since ubuntu is linux you don't need the .la files
[14:06] <Keybuk> Chipzz: but as Mithrandir points out, you actually *do* need them for that goal
[14:07] <Keybuk> otherwise you can't do static library linking
[14:07] <Chipzz> Keybuk: afaik not on linux; only on other platforms lacking certain features
[14:07] <Mithrandir> and then it comes down to whether we actually want to support people linking, say, gtk+ statically.
[14:07] <Keybuk> Chipzz: yes, you do
[14:07] <tbf> Keybuk: but why should i care about artifacts for building __static__ libraries, if i want a tool for building __shared__ libraries?
[14:07] <Keybuk> tbf: gcc is perfectly capable of building shared libraries
[14:07] <tbf> Keybuk: and why should i care about dependency tracking information, if i have a more reliable variant?
[14:07] <Mithrandir> tbf: libtool know what magic knobs you need to twiddle on different platforms for building shared libraries too.
[14:08] <Keybuk> tbf: so why use libtool if you have a more reliable variant?
[14:08] <tbf> Keybuk: well, and libtool doesn't only do dependency tracking. it also knows which commands to invoke with which arguments
[14:08] <Keybuk> tbf: so do you, since you know how the the linker works
[14:08] <Keybuk> and libtool's knowledge depends on it having its control files
[14:09] <Keybuk> as soon as you take away its control files, libtool's own commands it invokes don't function properly
[14:09] <tbf> Keybuk: well, and it takes care about injecting --rpath information, so you can use your shared libs from your source dir...
[14:09] <Keybuk> it just happens that they function "well enough"
[14:09] <Keybuk> tbf: that breaks if you remove .la files
[14:09] <tbf> Keybuk: so libtool does alot of useful stuff
[14:09] <Keybuk> tbf: and it cannot do *any* of that, if you remove the .la files
[14:09] <Keybuk> ergo : remove the .la files => why are you using libtool?
[14:10] <Mithrandir> I'm wondering if we could rip out the dependency tracking bits of libtool and have it use pkg-config for that, while retaining its knowledge on compiler flags to build shared libs.
[14:10] <tbf> well, then we are at the point that libtool most probably is seriously broken....
[14:10] <Keybuk> as soon as you remove .la files, libtool becomes nothing more than a very large, very complicated shell script that expands to a gcc invocation near-identical to the libtool invocation
[14:10] <Keybuk> (on Linux)
[14:10] <tbf> ....since it regularly uses the wrong .la files
[14:11] <Keybuk> tbf: it never uses the wrong .la files ;)  what happens is that libtool's generic interface requires you, when you rebuild a library, to rebuild all libraries and programs that depend on it
[14:11] <Keybuk> it happens that Linux's library implementation doesn't require this
[14:11] <Keybuk> but since many library implementations *do* require this, libtool requires it
[14:11] <tbf> Keybuk: i do that, i do that
[14:12] <tbf> Keybuk: nevertheless it regularly grabs .la files from /usr/lib, instead of whatever-dir i asked it to use
[14:12] <Keybuk> tbf: next time it does it, please feel free to tar up the image, and grab me on IRC -- I'll happily help debug it for you
[14:12] <Chipzz> Keybuk: but, often it's nogt a matter of you wanting or not wanting libtool, it's a matter of *upstream* wanting libtool; so you have no say in it
[14:13] <Keybuk> Chipzz: but we already change upstream by removing .la files
[14:13] <Keybuk> upstream probably use libtool because automake depends on it for libraries
[14:13] <Chipzz> Keybuk: yes, but that's related to what Mithrandir said:
[14:13] <Chipzz> 15:07 < Mithrandir> tbf: libtool know what magic knobs you need to twiddle on different platforms for building shared libraries too.
[14:13] <Keybuk> but we don't need those knobs
[14:14] <Chipzz> Keybuk: often, libtool is used for *that* purpose, and the things you say are actuall irrelevant
[14:14] <Keybuk> it's a trivial matter to replace the ltmain.sh in source packages with something that only has the magic knobs for ubuntu
[14:14] <Keybuk> (we replace it most of the time anyway, along with config.guess and config.sub -- we just replace it with the full libtool one)
[14:14] <Chipzz> Keybuk: upstream does, for portability to other platforms we don't care about
[14:14] <Keybuk> then we could cut libtool out entirely
[14:14] <Keybuk> automake would still work, things would get built relying on pkg-config, etc.
[14:15] <Mithrandir> I'm somewhat wondering what problem you're trying to solve then.
[14:15] <Mithrandir> apart from "libtool is a pile of spaghetti and I want tuna for lunch!"
[14:16] <Keybuk> there's tuna in libtool
[14:16] <Chipzz> Keybuk: the matter of fact is very simple IMO; libtool is often used because of the relative convenience (of not having to figure out 10 gcc switches) of the automake/libtool combo, and for portability; and most often not for the things you mention
[14:16] <Hobbsee> mmm...tuna
[14:16] <Mithrandir> Keybuk: there are also bits of metal and brains in libtool.
[14:16] <Keybuk> Chipzz: except those switches rely on the existance of a file that packagers subsequently delete
[14:16] <Keybuk> libtool *really* assumes it has a .la file
[14:17] <Keybuk> and its behaviour without one is quite undefined in many circumstances
[14:17] <Mithrandir> Keybuk: all of them at varying degrees of radioactivity, of course.
[14:17] <Chipzz> but it still works without?
[14:17] <Keybuk> no, it really breaks
[14:17] <Keybuk> it just happens to work on the buildds without
[14:17] <Keybuk> for example, when you don't ship a .la file in /usr/lib, a .la file *anywhere else in the path* will trump it
[14:17] <Keybuk> and you'll end up linking with the wrong libraries
[14:17] <Keybuk> so builds work on the buildd, since they're fresh
[14:17] <tbf> so how do i get back the .la files, after agressively erasing them from /usr/lib?
[14:17] <Chipzz> unless I'm grossly mistaken, I have build numerous libs in the past even with the .la files it depended on gone
[14:17] <Keybuk> but fail on people's machines
[14:18] <slangasek> Keybuk: er, but /usr/lib is normally the last dir in the lib search path anyway?
[14:18] <Mithrandir> tbf: reinstall the packages providing them.
[14:18] <slangasek> so if you have .la files elsewhere in the path, that's breaking things anyway
[14:18] <Chipzz> Keybuk: um yeah, but users shouldn't really be building from source anyway
[14:18] <tbf> Mithrandir: any magic for doing this automatically?
[14:19] <Keybuk> slangasek: not at all
[14:19] <aquo> i had a look at /var/log/dpkg.log and many lines are printed multiple times? is this a bug?
[14:19] <Keybuk> thanks to multi-arch weirdness, it's somewhere in the middle (it just happens to be specifically at the end too)
[14:20] <Keybuk> I've demonstrated the failures many times
[14:20] <Keybuk> and I've argued repeatedly about this
[14:20] <Keybuk> and people still ignore me, and still come to me with their problems afterwards
[14:20] <Keybuk> so meh
[14:20] <Mithrandir> tbf: cd /var/lib/dpkg/info; grep -lr la$ *.list | sed s/.list$//| xargs sudo apt-get --reinstall install
[14:20] <Mithrandir> tbf: untested, of course.
[14:21] <tbf> Mithrandir: looks reasonable - thank's alot
[14:21] <slangasek> Keybuk: not me, I just concatenate invectives and will libtool to implode
[14:21] <Mithrandir> possibly make that grep pattern \\.la$
[14:22] <Keybuk> I long ago came to the conclusion that libtool is the wrong solution
[14:22] <tbf> Mithrandir: already did that ;-)
[14:22] <Keybuk> and lost the will to care about writing the right solution ;)
[14:23] <slangasek> Keybuk: speaking of which, what would you recommend for a pair of libtool "module" .las where one requires symbols from the other, using the current sensible-libltdl behavior of RTLD_LOCAL?
[14:23] <slangasek> Keybuk: ... and the module .la doesn't have a name beginning with "lib"? :)
[14:23] <Keybuk> can't A needed B?
[14:24] <slangasek> (this apparently causes libtool to go stark raving at install time, and try to convert the .la file's path into a -l option)
[14:24] <Keybuk> foo_la_LDADD = bar.la
[14:24] <Keybuk> prog_LIBS = foo.la
[14:24] <Keybuk> doesn't that work?
[14:25] <slangasek> "prog_LIBS"?  that sounds like it's the wrong answer for a dlopen()ed module?
[14:25] <Keybuk> oh, dlopen
[14:25] <Keybuk> that should still work though?
[14:25] <slangasek> anyway, I suspect that doesn't work; from what I see, libtool says "oh, you linked with this thing called bar.la, we're relinking, let's turn that into a -l option and look for -lbar"
[14:26] <slangasek> the best workaround I've found is to provide a libbar.$mumble symlink
[14:26] <slangasek> (the naming scheme for the modules is set upstream, well-established and documented)
[14:31] <TheMuso> evand: for q quick start, you can find resources for developers on http://live.gnome.org/Accessibility
[14:54] <slangasek> calc: hoi, what news on ooo-l10n?
[14:56] <evand> thanks TheMuso!
[14:57] <calc> slangasek: its building... hasn't failed yet so that is good news
[14:58] <calc> slangasek: i remembered the fact we change some i18n stuff in ubuntu so i removed that patch and it seems to be working
[14:58] <calc> slangasek: so if it does work i will have to examine the patch closer to find what it is breaking
[14:59]  * calc needs a bigger box for OOo compiling
[14:59] <\sh_away> seb128, did you read #184607 and bug #184176? would you like to fix gconf ? :)
[14:59] <ubotu> Launchpad bug 184176 in gnucash "[hardy]Gnucash fails to build with libgconf2-dev 2.21.1-0ubuntu1" [Medium,New] https://launchpad.net/bugs/184176
[15:00] <\sh_away> bug #184607
[15:00] <ubotu> Launchpad bug 184607 in gconf "pkgconfig file says "Requires glib" instead of glib-2.0" [Undecided,New] https://launchpad.net/bugs/184607
[15:01] <calc> slangasek: is it safe for me to upload once i get it resolved (hopefully later today) or is there anything it would block thats important?
[15:02] <seb128> \sh: no I didn't read it yet looking now
[15:02] <slangasek> calc: er, I presume that once you have it fixed you *should* upload, since the lack of up-to-date l10n packages leaves ooo metapackage uninstallable and makes the hardy out-of-date list quite horrid :)
[15:03] <calc> slangasek: yea i was planning on it, but it will load a buildd for a while so wanted to make sure nothing else is pressing in the buildd queue right now
[15:04] <slangasek> ah, not from my POV
[15:05] <calc> ok
[15:05] <calc> i'll get it uploaded today then assuming it finishes build i should be able to resolve the bad patch issue fairly quickly (i hope)
[15:05] <bryce_> MacSlow: I didn't find anything in the -intel git log
[15:10] <MacSlow> bryce_ ok so we might get a point in the xorg-crowd for fixing that :)
[15:10] <bryce_> :-)
[15:10] <bryce_> fwiw, xrandr -o 1 still locks up X  :-P
[15:13] <Hobbsee> MacSlow: fixing what?  :)
[15:14] <MacSlow> Hobbsee, https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/175774
[15:14] <ubotu> Launchpad bug 175774 in xserver-xorg-video-intel "[hardy] Enabling "Normal" effects produces badly drawn window shadows." [Critical,Confirmed]
[15:17] <Hobbsee> MacSlow: nice!
[15:22] <bryce_> MacSlow: ok I've built a test deb for these changes
[15:23] <bryce_> brb
[15:27]  * calc noticed that his build hasn't actually reached where it failed before
[15:48] <slangasek> TheMuso: you may want to merge ubuntu.hardy seed changes into ubuntustudio change; pwlib had an ABI change that ekiga has just been rebuilt for, the seeding of the plugin packages needs to be updated to match
[15:50] <_MMA_> slangasek: joejaxx can also handle this. I'll make sure he knows.
[15:51] <slangasek> _MMA_: ok, cheers
[15:51] <slangasek> _MMA_: picking on TheMuso because I know what timezone he's currently in :)
[15:51] <_MMA_> Thanx for the heads up.
[15:52] <_MMA_> slangasek: hehe. :P
[15:53] <TheMuso> Actually, i need to talk to joejaxx about the way he is merging. He is not using bzr merge, which IMO he should be.
[15:53] <slangasek> heh
[15:53] <_MMA_> Oh ouch.
[15:53] <TheMuso> As it then shows parent commits from the ubuntu seeds.
[15:53]  * slangasek nods
[15:54] <TheMuso> slangasek: Picking on me? it seems like other people are more jetlagged than me, and they arrived earlier than I, and didn't have as far to go. :)
[15:55] <_MMA_> TheMuso: Well if you feel like kickin' ass and taking names while you're in London rock on. \m/ We should still talk to Joe.
[15:55] <TheMuso> _MMA_: Yes, I agree.
[15:57] <TheMuso> But, I won't rule out feeling tired some time this evening.
[15:57] <_MMA_> TheMuso: Sure.
[15:59] <slangasek> TheMuso: right, "picking on you" because I know you're in my timezone.  and in walking range.
[15:59] <TheMuso> Yes there is truth in that.
[16:01] <calc> i found that sleeping pills seem to somewhat help with jetlag
[16:01] <TheMuso> usually only takes me 1/2 nights, and I'm right.
[16:01] <TheMuso> of good sleep.
[16:01]  * Hobbsee finds not travelling the most effective form of jetlag avoidance
[16:01] <calc> though i didn't experience any nighttime kookiness
[16:02] <calc> Hobbsee: ;P
[16:02] <TheMuso> I would rather not use anything to artificially simulate the boy to either feel sleepy or more awake.
[16:02] <TheMuso> stimulate the body
[16:03] <calc> http://en.wikipedia.org/wiki/Crook_and_Ladder
[16:03] <TheMuso> I do have the fact that I sleep deeply on my side.
[16:04] <Hobbsee> calc: :)
[16:26] <Keybuk> Riddell: KDE 4 to have a six-monthly release schedule?
[16:26] <calc> i obviously still have jetlag as i have a strong desire to go back to the hotel and sleep :-\
[16:26] <calc> and all the caffeine doesn't seem to help much
[16:26] <Riddell> Keybuk: that's the rough plan
[16:26] <calc> Riddell: aligned with Gnome?
[16:26] <Riddell> Keybuk: but 4.1 still has some must have features so it could slip if they do
[16:27] <Riddell> calc: goodness no
[16:27] <Keybuk> Riddell: is there any particular reason, apart from sheer bloody-mindedness, that they didn't pick the same rough dates as GNOME? ;)
[16:27] <calc> Keybuk: because KDE != Gnome? ;-)
[16:27] <calc> and to cause Ubuntu pain
[16:27] <Keybuk> it isn't just Ubuntu though
[16:27] <Keybuk> it causes every distribution pain
[16:27] <TheMuso> I've noticed the amount of soft drink that is consumed around here. Its scary.
[16:27] <Riddell> well 4.0 happenes to come out in january so that sets the current schedule
[16:27] <Keybuk> TheMuso: I'm trying to move everyone onto jelly bellys
[16:28] <TheMuso> Keybuk: Oh yeah. Thats even better.
[16:28] <Keybuk> TheMuso: would you like some?
[16:28] <Riddell> calc: january and july would be a perfectly convenient schedule for us
[16:28] <calc> Riddell: maybe they could scedule 4.1 to come out in Sept then to give them extra time ;)
[16:28] <Riddell> calc: that might happen in its own course
[16:28] <Riddell> Keybuk: where are you reading this anyway?
[16:28] <TheMuso> Keybuk: Thanks for the offer, bt no thanks. I am trying to keep from using artificial/sugar stimulents.
[16:29] <Keybuk> Riddell: planet ubuntu, of course
[16:33] <calc> ok its past the failure point for ooo l10n (i think) so that is a good sign :)
[16:36] <TheMuso> calc: Do you have a beefy laptop, or are you building this on a fast home box?
[16:36] <calc> TheMuso: both, but i am building on my home box
[16:36] <TheMuso> right
[16:37] <calc> TheMuso: my laptop is core2duo 1.7GHz 4gb ram, my home machine is core2duo 2.8GHz 2GB ram
[16:37] <TheMuso> Ah ok.
[16:37] <calc> TheMuso: i already had ccache primed on my home system so i just used that
[16:37] <TheMuso> ah
[16:38] <calc> even with ccache its taking 5hr+ for the l10n build though
[16:38] <Keybuk> I built oo.o once
[16:38] <Keybuk> it took >5hr just for "apt-get build-dep" :)
[16:38] <calc> Keybuk: hehe
[16:38] <TheMuso> Keybuk: You were obviously somewhere with little/no bandwidth. :p
[16:38] <calc> TheMuso: ooo requires a LOT
[16:39] <TheMuso> calc: I doubt that not.
[16:39] <calc> though it wouldn't take 5hr at the office to download its build-deps
[16:45] <Keybuk> calc: one would hope not
[16:47] <calc> is it normal for a system to not allow access for the ~ 3300MB - 4096MB range?
[16:47] <calc> i have a i945 laptop and wasn't sure if it was a chipset or bios issue, at least when running x86_64
[16:48] <calc> in ia32 it probably is a issue due to needing space for pci map
[16:48] <RainCT> mvo: ping :)
[16:53] <mvo> RainCT: pong
[16:53] <RainCT> mvo: before I upload fusion-icon (to Debian).. is it's priority extra for some reason or did you just forget to change it? :P
[16:55] <mvo> RainCT: I think I forgot to change it (I can't remember any particular reason)
[16:58] <crimsun> is Ted Gould present at the sprint?
[16:59] <ogra1> crimsun, yup
[17:01] <calc> crimsun: need him?
[17:02] <crimsun> calc: yes please, concerning cleanup-audio-jumble
[17:03] <calc> crimsun: he said his irc client is currently broken but he would try to get online
[17:03] <crimsun> calc: many thanks!
[17:04] <calc> crimsun: you might try emailing him until then
[17:09] <calc> yipee! i got l10n debs being spit out
[17:09] <calc> now i just need to look through the diff to find the offending code
[17:09] <TheMuso> heh
[17:11] <TheMuso> is that for amd64, or i386?
[17:12] <calc> its being compiled on amd64 but is indep
[17:12] <calc> it looks like my patch didn't do anything
[17:12] <calc> so i am going to reapply it, maybe i forgot to regenerate ooo-build afterwards when i did it before
[17:13] <calc> i don't see how this patch could have done anything to cause it to fail where it did
[17:13] <TheMuso> Oh fun.
[17:13] <calc> but it is the only patch I made that I know of to the language stuff that isn't in debian which worked out of the box
[17:14] <TheMuso> Right.
[17:18] <calc> slangasek: so if you didn't see above i have made ooo l10n build but after looking at the patch I left out I am not sure why leaving out the patch helped, so i am going to try rebuilding with using the patch and regenerating the ooo-build build stuff
[17:19] <calc> slangasek: i wonder if it worked because of the aotcompile file change
[17:20] <calc> slangasek: since iirc language stuff is threaded it could have failed in a weird way due to running out of memory
[17:30] <agd5f> are there known issues with hardy and AMD64?  I've gotten a kernel panic with every image I've tried?
[17:31] <calc> running the full build if this works i will upload (probably in 5hr or so
[17:43] <pochu> soren: may I ask you to ACK bug 176007?
[17:43] <ubotu> Launchpad bug 176007 in vinagre "Please sponsor vinagre_0.4 into Hardy" [Wishlist,New] https://launchpad.net/bugs/176007
[17:47]  * seb128 kicks tracker
[17:48] <seb128> eating 100% cpu four hours and the applet has no label about it being indexing or anything
[17:48]  * pochu kicks seb128 :)
[17:48] <seb128> pochu: heh
[17:48] <seb128> what did I do?
[17:49] <pochu> kick tracker? ;)
[17:49] <seb128> its eating all the cpu without a good reason
[17:49] <pochu> seb128: tracker-status?
[17:49] <seb128> that deservers some good kicking
[17:49] <seb128> that hangs
[17:49] <seb128> and the applet has no label or count or anything
[17:49] <pochu> That's odd.
[17:50] <pochu> Do you mean the progress bar isn't there?
[17:50] <mjg59> It means the daemon has stopped responding
[17:51] <pochu> Here it works quite well... after I told it not to index ~/dev and ~/tmp
[17:51] <seb128> #8  0xb7ddb4d7 in sqlite3InvokeBusyHandler () from /usr/lib/libsqlite3.so.0
[17:51] <mjg59> seb128: What about the other threads?
[17:52] <seb128> mjg59: lack of debug packages I'll try to get debug backtrace
[17:53] <seb128> one thread has enough informations to indicate it was indexing INBOX
[17:53] <seb128> and there is 2 threads with libsqlite functions
[17:53] <seb128> one being stopped on sleep apparently
[17:53] <mjg59> Hm
[17:54] <seb128> oh
[17:54] <seb128> what my be an interesting detail is that my laptop is running on battery at the moment
[17:54] <seb128> so it should not start and eat batteries
[17:54] <seb128> what might be
[17:54] <mjg59> Yeah
[17:54] <soren> pochu: Sure thing!
[17:55] <soren> pochu: Done.
[17:55] <pochu> seb128: It doesn't do initial index on battery, but that's not the initial index I guess...
[17:56] <pochu> soren: thanks :)
[17:56] <mjg59> pochu: You can disable both types individually
[17:56] <pochu> seb128: You are using evo right? There's this crash in LP, although it doesn't mention libsqlite: bug 180220
[17:56] <ubotu> Launchpad bug 180220 in tracker "trackerd crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/180220
[17:56] <seb128> pochu: it should do nothing on battery
[17:56] <_MMA_> seb128: I added my xsession-errors to bug 183199. Might give you some idea. Hopefully I can track down more details with crimsun later.
[17:56] <seb128> pochu: yes
[17:56] <ubotu> Launchpad bug 183199 in gnome-control-center "System sounds aren't being played in Hardy." [Undecided,New] https://launchpad.net/bugs/183199
[17:57] <pochu> mjg59: Right. But do we disable both by default? I thought only initial index was deactivated.
[17:57] <mjg59> Yes
[17:58] <pochu> Ok, sorry then.
[17:58] <crimsun> _MMA_: (pointer for later:  check capplets/sound/ and libsounds/)
[17:59] <_MMA_> k
[18:00] <seb128> crimsun, _MMA_: I've no pulse running so it might use aplay
[18:00] <mjg59> seb128: No, I don't think that follows
[18:00] <seb128> _MMA_: do you have pulsesomething running?
[18:01] <mjg59> seb128: Even if I'm on battery, if I save a new file I want it indexed
[18:01] <seb128> mjg59: what?
[18:01] <seb128> mjg59: depending how much indexing takes
[18:01] <mjg59> seb128: Per-file, it should be very little
[18:02] <seb128> right
[18:02] <mjg59> The hard drive will be spun up anyway
[18:02]  * _MMA_ fires up the Hardy test box.
[18:03] <seb128> mjg59: not sure how much indexing a mail takes but you can easily have hundred of mails there
[18:03] <seb128> brb
[18:03] <seb128> restarting my session
[18:07] <seb128> _MMA_: do you have pulseaudio-esound-compat installed?
[18:08] <seb128> does installing it and restarting your session makes any difference?
[18:08]  * _MMA_ looks.
[18:08] <_MMA_> pulseaudio is running.
[18:08] <_MMA_> And we mirrored what Ubuntu had in its seed list sound-wise.
[18:08] <seb128> does paplay /usr/share/sounds/login.wav work correctly?
[18:14] <Keybuk> bryce: err, I've just had my external screen blank
[18:14] <Keybuk> how do I get it back?
[18:15] <_MMA_> seb128: pulseaudio-esound-compat is installed. paplay /usr/share/sounds/login.wav does yield sound. Playing that same file through gnome-sound-properties does not.
[18:16] <bryce_> Keybuk: restart X maybe?
[18:17] <Keybuk> bryce_: a less drastic solution? :p
[18:17] <bryce_> hehe
[18:17] <bryce_> Keybuk: there might be an xrandr incantation to bring it back
[18:18] <bryce_> Keybuk: any clues in Xorg.0.log?
[18:18] <Keybuk> no
[18:19] <Keybuk> at least nothing I understand
[18:21] <agd5f> bryce_: you know of any AMD64 issues with hardy?  I've get to find an image that boots.  stuff scrolls by pretty quick, but looks like something about the ioscheduler then I get a panic
[18:22] <bryce_> agd5f: hmm, I've not tested on my amd64 system lately
[18:23] <selckin> mine hanged somewhere after hd detection without any messages, started working when i used /dev in root= instead of UID
[18:23] <bryce_> agd5f: have you tried the 32bit x86 images or just 64bit?
[18:23] <agd5f> just 64 bit, I ran out of blank cds :)
[18:25] <bryce_> agd5f: which hardy version(s) have you tested on?
[18:25] <agd5f> alpha3 and yesterday's snapshot
[18:25] <bryce_> ok, that's a -4 kernel
[18:25] <seb128> _MMA_: I figured what is wrong
[18:26] <bryce_> can you send us a stack trace or dump?  (photo maybe?)
[18:26] <agd5f> yeah
[18:26] <agd5f> bryce_: I'll file a bug
[18:26] <seb128> crimsun, _MMA_: that's an esound bug
[18:28] <bryce_> agd5f: cool.  I'm sitting next to tim gardener, and he said he'll take a look
[18:28] <bryce_> brb, testing a 965 compiz fix...
[18:31] <BenderUnit22> ~/clear
[18:37] <_MMA_> seb128: Ok. Hopefully crimsun and I can sort it out.
[18:39] <_MMA_> seb128: I did get an odd issue when searching for pulseaudio-esound-compat in Synaptic. (not related to the package.) Synaptic completely locked until I killed update manager. I've never seen that before.
[18:45] <seb128> _MMA_: the bug is an esound one, I'm going to look at fixing it now
[18:45] <seb128> _MMA_: it's using .esd and not .esd-1000
[18:45] <_MMA_> seb128: Awesome. Thanx. Let me know if I can help.
[18:45] <seb128> _MMA_: you are welcome
[18:46]  * _MMA_ sends TheMuso to give Seb a hug. (If Sebastian is in London that is) :P
[18:47] <TheMuso> lol
[18:47] <_MMA_> ;)
[18:49] <slangasek> pitti: is the gnome-keyring-manager -> seahorse seed change ok for upload?
[18:50] <\sh> doko, reping crystalspace ... again the question you mentioned "configure --without-java" in your last upload..but it's commented...
[18:51] <doko> \sh: hmm, can't remember ... maybe just do what debian does
[18:51] <\sh> doko, k..:)
[18:51] <pitti> slangasek: yes, it is
[18:52] <slangasek> pitti: ok, ubuntu-meta uploaded then
[18:53] <pitti> yay
[19:32] <agd5f> bryce: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/184883
[19:32] <ubotu> Launchpad bug 184883 in linux "hardy AMD64 kernel panic on boot" [Undecided,New]
[20:48] <agd5f> bryce: looks like a bios issue
[20:48] <agd5f> I hardcoded the ram voltage and now it seems to boot ok
[22:01] <crimsun> _MMA_: didn't you test the /tmp/.esd symlink I suggested several days ago?
[22:03] <_MMA_> crimsun: I did. Lemmie see what I told you.
[22:04] <crimsun> _MMA_: did you log out and back in after creating the symlink (I don't see why that would have been necessary)?
[22:05] <_MMA_> crimsun: After doing that the sounds didnt play but I got "(gnome-sound-properties:6093): Gnome-WARNING **; error caching sample <-1>!"
[22:16] <pochu> soren: btw, and in case you missed it, I attached a debdiff to bug 183169 ;) I've of course tested it with vinagre 0.4, and it solves the issue (for "localhost:1" and for "ñlkjadf~@|#")
[22:16] <ubotu> Launchpad bug 183169 in gtk-vnc "Crash if hostname contains invalid characters" [Medium,Confirmed] https://launchpad.net/bugs/183169
[23:09] <basy> Are there any installers for man pages? I need to install man pages for develop with openGL, i have mangl.tar.Z and there are *html and *3gl manuals, any idea how to install that?
[23:10] <basy> plz
[23:11] <Seveas> basy, this is not a support channel
 and which one is for support?
[23:12] <Seveas> basy, #ubuntu
[23:13] <basy> i ll try  there sorry
[23:46] <Keybuk> ...we could always just remove openoffice from the seeds and replace it with abiword and gnumeric...
[23:46] <evand> seconded
[23:48] <LaserJock> gnumeric is pretty darn sweet, at least from my experience of scientific spreadsheet use
[23:50] <mjg59> gnumeric is fine. Abiword, less so.
[23:51] <LaserJock> I agree
[23:51] <LaserJock> although I've had Abiword do a little better with some things
[23:51] <LaserJock> as far as .doc compatibility
[23:52] <LaserJock> my only personal issue with s/openoffice/abiword+gnumeric/ is having an Impress replacement
[23:52] <Keybuk> mjg59: the abiword in gutsy/hardy is nice
[23:52] <Keybuk> I've found it much nicer for writing in
[23:52] <mjg59> It's nice, but it's not very /useful/
[23:53] <mjg59> At least, for the common case of dealing with .docs
[23:53] <Keybuk> yeah, the file format stuff maybe not
[23:53] <mjg59> (Yes, I know this is a ridiculously hard problem)
[23:53] <Keybuk> but openoffice is less useful since it's not INSTALLABLE :)
[23:54] <LaserJock> mjg59: have you seen any tests on that? I'd be interested in what abiword fails with regarding dealing with .docs
[23:54] <johanbr> In my limited experience, abiword handles .doc files fine. Although I never receive very complex documents...
[23:55] <mjg59> LaserJock: They look different to when I open them in OpenOffice :)
[23:55] <LaserJock> mjg59: yes, although in my experience Abiword actually looked closer to Word than OpenOffice did
[23:55] <mjg59> Hm. Mine's the opposite
[23:55] <LaserJock> but I only have a limited case
[23:55] <mjg59> But, as I said, this is hard
[23:56] <LaserJock> I have a book chapter I'm working on, so it's decently complicated but no graphics, just text
[23:57] <LaserJock> the only thing I really saw that Abiword failed at was in using multiple fonts at the same time, abiword just picked one whereas OO.o kept the font list
[23:57] <ScottK2> IMO, .doc compatibility is a must.
[23:58] <LaserJock> ScottK2: yeah, but it's kinda subjective, IMO, which is the problem
[23:58] <LaserJock> it'd be nice to have a systematic way of evaluating
[23:59] <ScottK2> OOO 2.3 has gotten it to a point where I almost never have a problem.