[00:04] <sveinse> penguin42: excellent, thanks. It works using the Linaro PPA. I'll comment that on the bug
[00:05] <penguin42> no problem
[00:35] <broder> ugh. looks like upstart's test suite works fine on the buildds, but errors out on my oneiric laptop: http://paste.ubuntu.com/729586/
[00:46] <penguin42> broder: could be a load of differences I guess; don't the buildd's tend to run with fairly old kernels?
[00:47] <broder> penguin42: they do - i believe they're generally the previous lts. i know that libnih and upstart's test suites have caught weird kernel bugs in the past and i'm afraid i'm going to end up chasing a similar rabbit hole or something. trying to get a minimal test case
[00:47] <penguin42> broder: Or it could be an interaction of the upstart/packages on the laptop I guess
[03:39] <lacqui> Hi.  Trying to fix my first bug here (bug #885329).  I've followed the instructions on https://wiki.ubuntu.com/Bugs/HowToFix but I'm getting the following error:
[03:39] <lacqui> debian/rules:4: /usr/share/cdbs/1/rules/debhelper.mk: No such file or directory
[03:42] <bjsnider> lacqui, install cdbs on your build system
[03:42] <bjsnider> apt-get build-dep eggdrop
[03:42] <lacqui> bjsnider: thanks
[03:42] <lacqui> like I said, first bug :P
[05:38] <lacqui> Is this the right place to request a review for a bug fix? (#885329)
[05:54] <sladen> lacqui: let me have a look
[06:03] <lacqui> sladen: thanks
[13:13] <pgquiles> I'm the maintainer of the 'witty' package. In Oneiric, the package does not work because it was apparently built against a buggy jQuery ( https://bugs.launchpad.net/ubuntu/+source/witty/+bug/886456 ). How can I get an update (actually, a rebuild) included in oneiric-updates :-?
[13:16] <tumbleweed> pgquiles: request a rebuild in the bug and subscribe ubuntu-sponsors
[13:16] <pgquiles> tumbleweed: thank you
[13:17] <tumbleweed> it probably should symlink to libjs-jquery's jquery rather than bundling it, although that's not without caveats either (see the recent discussion in debian-devel)
[13:17] <Chipzz> pgquiles: actually it depends what you mean. You didn't specify if you wanted an update of your package or of jquery
[13:18] <pgquiles> Chipzz: my package
[13:18] <pgquiles> tumbleweed: witty symlinks to jquery on build, but it converts jquery to C++ and embeds it in the .so
[13:18] <pgquiles> tumbleweed: I was part of the discussion in debian-devel :-)
[13:19] <tumbleweed> converts jquery to C++? eep
[13:20] <Chipzz> pgquiles: exactly how do you intend to convert jquery into C++??
[13:20] <hyperair> O_o
[13:21] <Chipzz> jQuery is a CLIENT-side javascript library. C++ is (at best) used in your software which is SERVER-side
[13:21] <hyperair> maybe it's something elfrc
[13:21] <hyperair> stuff the jquery source code into a .so file that can spit out things on the server side?
[13:21]  * hyperair shrugs
[13:22] <Chipzz> hyperair: jQuery will NEVER run server-side
[13:22] <Chipzz> because it operates on the DOM
[13:22] <hyperair> Chipzz: read what i said carefully.
[13:22] <pgquiles> Chipzz: tumbleweed: on build, Wt takes jquery.min.js and generates a C++ file, which is compiled into the .so
[13:23] <hyperair> Chipzz: elfrc embeds arbitrary files into elf objects. since it's a built-in httpd, it wouldn't be unplausible to have it serve jquery.js from a static string somewhere
[13:23] <pgquiles> Wt is not like PHP. Webapps using Wt are real programs (binaries), the result of compiling C++. Instead of reading jquery.min.js every time from disk, it is streamed from memory
[13:23] <hyperair> right, see, that's what i said.
[13:23] <Chipzz> hyperair: that would be a big big BIG facepalm
[13:23] <hyperair> Chipzz: it's serving jquery.min.js from memory instead of reading from disk.
[13:23]  * Chipzz starts to understand the sentiment against web developers on #debian-devel
[13:24] <pgquiles> Chipzz: developing web apps with Wt is more like developing a desktop app with Qt
[13:24] <pgquiles> C++, a copycat of the Qt API, etc
[13:24] <pgquiles> :-)
[13:24] <pgquiles> great for embedded and/or high-performance
[13:24] <Chipzz> pgquiles: as someone who does web development as a full-time job I have 3 words for you: WHAT. THE. FUCK?
[13:25] <pgquiles> Chipzz: http://webtoolkit.eu
[13:25] <pgquiles> I gave up on Rails when I started using Wt
[13:25] <hyperair> Chipzz: hey it's not so bad, it's like CGI except without the exec() overhead?
[13:25]  * hyperair wouldn't mind doing native code webapps.
[13:25] <hyperair> it could turn out to be pretty performant.
[13:26] <pgquiles> it's not only native code, it's also the API: forget about pages, etc. It's like a desktop app.
[13:26] <pgquiles> hyperair: in fact, you can also compile the webapp to a FastCGI module instead of using the embedded HTTP server
[13:26] <hyperair> pgquiles: in all my life in web development, i've always looked down upon *anything* that autogenerates my html code for m.e
[13:26] <Chipzz> hyperair: for what gain exactly? serving jquery.min.js a couple of ms faster? taking in mind that jquery.min.js is minized already... if performance REALLY matters that much, put a reverse proxy in front of it. but for the love of god, why obscure your web application in such a way???
[13:27] <hyperair> Chipzz: *shrug* i'm talking about the idea of webtoolkit in general, not the jquery instance.
[13:28] <hyperair> Chipzz: also a reverse proxy is sometimes a rather overengineered solution.
[13:28] <Chipzz> hyperair: not as overengineered as compiling jquery.min.js into a .so :|
[13:28] <pgquiles> Chipzz: because that way when you want to deploy your webapp, you only need to deploy ONE single executable that embeds everything
[13:28] <hyperair> Chipzz: the framework's already there. i don't think it's really that overengineered.
[13:28] <hyperair> Chipzz: it probably ends up even simpler.
[13:29] <hyperair> Chipzz: especially at the deployment stage
[13:30] <Chipzz> pgquiles: which matters exactly nada since you're packaging it. you deploy your webapp by using apt-get install or dpkg -i
[13:31] <pgquiles> Chipzz: not everybody packages everything. Especially on embedded, Windows, mobile, etc
[13:32] <Chipzz> pgquiles: no, but you are asking specifically in the context of packaging it
[13:32] <hyperair> pgquiles: does witty generate this one-executable-binary thing for new webapps?
[13:32] <pgquiles> Chipzz: sorry, I don't follow. The 'witty' package contains the libraries to develop webapplications, not an aplication
[13:33] <hyperair> pgquiles: i.e. it generates the single-executable-webapp?
[13:33] <hyperair> pgquiles: like a funky linker?
[13:33] <pgquiles> hyperair: yes, it does. Just like against wthttp and it will embed the HTTP(S) server. If you'd rather generate a FastCGI module, just link to wtfcgi.
[13:33] <hyperair> wtfcgi
[13:33] <pgquiles> hyperair: Wt webapps are developed in C++ and compiled and linked using gcc and ld
[13:33] <hyperair> i like that name.
[13:34] <Chipzz> pgquiles: same difference really.
[13:34] <pgquiles> it's not "link a funky linker" but "using a funky linker" :-)
[13:34] <hyperair> Chipzz: so there you have it. witty isn't a web server. it provides the tools to make a one-executable webserver.
[13:34] <pgquiles> that's it
[13:34] <hyperair> Chipzz: with embedded webapp.
[13:34] <Chipzz> hyperair: like I just said, same difference. unless witty is some sort of "compiler" instead of a "library"
[13:34] <hyperair> Chipzz: that's exactly what i'm talking about.
[13:35] <hyperair> Chipzz: more like a runtime that's statically linked with your webapp.
[13:35] <pgquiles> Chipzz: witty is a C++ library. You use it like you use Gtk+, Qt, libc, etc
[13:35] <Chipzz> static linking? this keeps getting better and better
[13:35] <pgquiles> Chipzz: or dynamic linking, your choice
[13:35] <hyperair> Chipzz: it's a one-executable webapp-cum-server. wtf else do you expect it to be besides static linking?!
[13:36] <Chipzz> hyperair: do I need to point out debians and ubuntus stance about static linking?
[13:36] <hyperair> it's something you throw at somebody and tell them to execute to host a web server with said webapp
[13:36] <pgquiles> libwt*-dev include the static libraries and the dynamic libraries
[13:36] <hyperair> Chipzz: it's for *your own* web app.
[13:36] <hyperair> Chipzz: something you're going to throw at $other_distro to run.
[13:37] <Chipzz> hyperair: what happens when it turns out the version of jquery witty is currently shipping turns out to be buggy?
[13:37] <hyperair> Chipzz: then you binNMU.
[13:37] <pgquiles> Chipzz: actually, then you run into the discussion from debian-devel
[13:38] <Chipzz> all the reverse deps? including all the webapps you compiled against witty and you sent off god-knows-where?
[13:38] <pgquiles> Chipzz: if you replace jquery, probably the webapp breaks because it's not ready for that new version of  the javascript library
[13:38] <pgquiles> Chipzz: just dynamic link, man
[13:38] <hyperair> Chipzz: pgquiles said you can dynamically link your webapp anyways, so...
[13:38] <pgquiles> static linking is your choice and it's not the default
[13:38] <pgquiles> (CMake picks the so's by default)
[13:39] <Chipzz> I think I'm going to retract from this discussion in order not to induce self-inflicted harm by repeatedly banging my head against the wall. laters
[13:39] <hyperair> Chipzz: i don't know much about wt, this being the first time i'm hearing about it, but all your points so far has been off-mark.
[13:39] <hyperair> your strawman is burning very brightly
[13:40] <pgquiles> Chipzz: try Wt, then tell me what you think. After using it :-)
[13:41] <hyperair> pgquiles: he probably won't, due to his set preconceptions against it.
[13:42] <pgquiles> I have to admit the first time I read about Wt I thought it was crazy or plain stupid. Turns out it works beautifully and it's extremely performant.
[13:43] <hyperair> i'll just say this out loud first: i dislike qt's way of reimplementing half the C++ standard library.
[13:44] <hyperair> if wt does the same thing, i won't touch it with a 100-foot pole.
[13:44] <hyperair> case in point QString
[13:44] <pgquiles> hyperair: Qt needed to do that. Back then, C++ compilers were so broken and/or incomplete there was no other way to support other Unices.
[13:45] <hyperair> pgquiles: that's in the past. qt4 could have dropped that.
[13:45] <pgquiles> hyperair: Wt uses Boost, it does not reimplement
[13:45] <hyperair> oh goody.
[13:45] <pgquiles> hyperair: no, Qt 4 could not do that
[13:45] <pgquiles> case in point: Solaris
[13:45] <hyperair> pgquiles: typedefs blah blah thin wrappers
[13:45] <pgquiles> HP-UX
[13:45] <pgquiles> AIX
[13:45] <hyperair> people use that crap?
[13:45]  * hyperair coughs
[13:45] <pgquiles> you'd be surprised how many companies use Boost
[13:45] <hyperair> i'm not talking about boost
[13:46] <hyperair> i'm talking about solaris/hp-ux/aix
[13:46] <pgquiles> sure, less and less, but it's still widely used
[13:46] <hyperair> boost is superbly awesome.
[13:46] <pgquiles> heck, even SCO still has some clients left! :-D
[13:46] <hyperair> yes, why couldn't qt use boost?
[13:46] <pgquiles> back then Boost did not provide all it provides now
[13:46]  * hyperair mumbles something about how it should die in a fire already
[13:46] <hyperair> pgquiles: qt4 is fairly recent. boost was very mature by then
[13:46] <pgquiles> also, Boost does not promise binary compatibility across versions
[13:46] <pgquiles> not even now
[13:46] <hyperair> oh right, that.
[13:46]  * hyperair sighs
[13:47] <pgquiles> Qt4 was released in 2005, started in 2003
[13:47] <pgquiles> Qt 5 will be released early 2012
[13:47] <pgquiles> also, C++ still does not provide introspection capabilities
[13:47] <hyperair> nor will it ever.
[13:47] <pgquiles> which is one of the main features moc provides
[13:47] <hyperair> i find it a disgusting bastardization of C++
[13:47] <pgquiles> even Glib has resorted to invent a mechanism for introspection
[13:48] <hyperair> that's because C has no OO capabilities.
[13:48] <pgquiles> the fact that C does not provide classes does not mean it has no OO capabilities
[13:48] <pgquiles> Glib and Gtk are OO with C
[13:49] <hyperair> correction: with C/GObject.
[13:49] <hyperair> it's all part of GObject's API
[13:49] <hyperair> it's not pure C.
[13:49] <hyperair> for the record, gobject's reference counting has driven me up the wall many a time
[13:49] <pgquiles> grammatically you are right
[13:49]  * hyperair sighs
[13:50] <hyperair> my definition of standard C is what ##c has.
[13:50] <hyperair> and my definition of standard C++ is what ##c++ has.
[13:50] <hyperair> by those definitions, i am correct in saying that C has no OO capabilities, period.
[13:50] <hyperair> not "grammatically" or "technically" or any crap like that.
[13:54] <hyperair> but GObject/C is better than Qt/Moc in the sense that it is implemented in standard C, rather than requiring some funky preprocessor to do stuff prior to compilation.
[13:54] <hyperair> when you need a preprocessor that's not the standard C++ preprocessor, it's no longer C++.
[13:57] <maco> What is moc?
[13:59] <penguin42> hyperair: It's not too unusual to have preprocessed stuff before your lang
[13:59] <pgquiles> maco: the metaobject compoiler
[13:59] <pgquiles> hyperair: GObject introspection requires the use of the gir scanner, which is essentially the same as moc
[14:00] <hyperair> pgquiles: there is a difference.
[14:00] <pgquiles> maco: http://doc.qt.nokia.com/latest/moc.html
[14:00] <hyperair> pgquiles: the gir scanner scans the *exact* same thing as the input to gcc.
[14:00] <hyperair> pgquiles: the input to moc isn't the same thing that goes into g++
[14:04] <penguin42> hyperair: All of these things are just signs that neith C or c++ quite fits into the view of what the GUI programmers need
[14:05] <penguin42> hyperair: Which I guess is why you get things like Vala
[14:05] <hyperair> penguin42: or people could use C#! \o/
[14:05] <penguin42> hyperair: Yeh
[14:05]  * hyperair holds up his evil mono supporter flag
[14:05]  * penguin42 burns it
[14:05] <hyperair> >=O
[14:06] <hyperair> penguin42: gtkmm is standard C++ though.
[14:07]  * penguin42 hasn't played with it
[14:09] <hyperair> it's good stuff. unfortunately it doesn't work with gobject introspection
[14:09] <hyperair> so C++-implemented widgets can only be used by other gtkmm things
[14:40] <mewerner_arand> When was the installer modified to use @ + @home subvolumes for btrfs? Did it appear in natty? I'm making a layout section on the wiki: https://help.ubuntu.com/community/btrfs#Ubuntu-specific_subvolume_layout
[14:41] <hyperair> @?
[14:41] <udevbot_> Error: "?" is not a valid command.
[14:41] <hyperair> that's pretty cool
[14:42] <mewerner_arand> hyperair: the subvolume tat holds "/" is named "@", yes.
[17:19] <hlamer> May package in PPA depend in package in another PPA? (Or what is the right channel for this question?)
[17:21] <broder> hlamer: at the top-right of the PPA page should be an "Edit PPA dependencies" link. (for reference #launchpad is probably a better channel for discussing PPAs, though)
[17:22] <hlamer> thanks, broder
[17:31] <highvoltage> When will I be able to see my work items in http://status.ubuntu.com/ubuntu-precise/u/jonathan.html ?
[17:31] <highvoltage> Or should I be looking somewhere else?
[19:13] <dupondje> Empathy is broken since last upgrade it seems :(
[19:13] <dupondje> [   88.095003] type=1400 audit(1320603235.045:21): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/telepathy/telepathy-*" name="/etc/default/apport" pid=1857 comm="telepathy-butte" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[20:10] <slangasek> lifeless: lp:~vorlon/launchpad/sbuild-multiarch-syntax test case> where's the right place for me to add this?
[20:11] <lifeless> slangasek: you know, I have no idea :)
[20:12] <lifeless> rather than flailing around with grep etc, I will ask some folk that have done a lot in this area, in a couple of hours
[20:12] <lifeless> how soon do you need this change live?
[20:20] <slangasek> lifeless: the sooner it can go live, the better; there are a number of packages in the base system that need to be switched to make use of this syntax to be cross-buildable
[20:27] <slangasek> lifeless: indeed, 3 out of 5 Prio: required packages that I've looked at so far are affected (acl, attr, bash)
[21:08] <marseillai_> hello
[21:08] <marseillai_> could someone tell me where dh_make store the packager name information ? i'd to change it
[21:09] <jbicha> marseillai_: debian/control
[21:10] <marseillai_> jbicha: i didn't explain weel sorry.
[21:11] <marseillai_> when dh_make build my package it store a wrong name in debian/control I'd like to change the source of this information
[21:11] <marseillai_> it mispel my name
[21:42] <DktrKranz> marseillai_: DEBFULLNAME environment variable
[21:50] <bjsnider> marseillai_, you can store that info in .bashrc, and it may be there
[21:58] <marseillai_> TheMuso: DktrKranz and bjsnider