[00:04] penguin42: excellent, thanks. It works using the Linaro PPA. I'll comment that on the bug [00:05] no problem [00:35] 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] broder: could be a load of differences I guess; don't the buildd's tend to run with fairly old kernels? [00:47] 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] broder: Or it could be an interaction of the upstart/packages on the laptop I guess [03:39] 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] Launchpad bug 885329 in eggdrop (Ubuntu) "eggdrop crash on i386" [Undecided,New] https://launchpad.net/bugs/885329 [03:39] debian/rules:4: /usr/share/cdbs/1/rules/debhelper.mk: No such file or directory [03:42] lacqui, install cdbs on your build system [03:42] apt-get build-dep eggdrop [03:42] bjsnider: thanks [03:42] like I said, first bug :P [05:38] Is this the right place to request a review for a bug fix? (#885329) [05:54] lacqui: let me have a look [06:03] sladen: thanks === yofel_ is now known as yofel [13:13] 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:13] Launchpad bug 886456 in witty (Ubuntu) "Built-in httpd does not render any widget" [Undecided,Fix committed] [13:16] pgquiles: request a rebuild in the bug and subscribe ubuntu-sponsors [13:16] tumbleweed: thank you [13:17] 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] pgquiles: actually it depends what you mean. You didn't specify if you wanted an update of your package or of jquery [13:18] Chipzz: my package [13:18] tumbleweed: witty symlinks to jquery on build, but it converts jquery to C++ and embeds it in the .so [13:18] tumbleweed: I was part of the discussion in debian-devel :-) [13:19] converts jquery to C++? eep [13:20] pgquiles: exactly how do you intend to convert jquery into C++?? [13:20] O_o [13:21] jQuery is a CLIENT-side javascript library. C++ is (at best) used in your software which is SERVER-side [13:21] maybe it's something elfrc [13:21] stuff the jquery source code into a .so file that can spit out things on the server side? [13:21] * hyperair shrugs [13:22] hyperair: jQuery will NEVER run server-side [13:22] because it operates on the DOM [13:22] Chipzz: read what i said carefully. [13:22] Chipzz: tumbleweed: on build, Wt takes jquery.min.js and generates a C++ file, which is compiled into the .so [13:23] 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] 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] right, see, that's what i said. [13:23] hyperair: that would be a big big BIG facepalm [13:23] 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] Chipzz: developing web apps with Wt is more like developing a desktop app with Qt [13:24] C++, a copycat of the Qt API, etc [13:24] :-) [13:24] great for embedded and/or high-performance [13:24] pgquiles: as someone who does web development as a full-time job I have 3 words for you: WHAT. THE. FUCK? [13:25] Chipzz: http://webtoolkit.eu [13:25] I gave up on Rails when I started using Wt [13:25] 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] it could turn out to be pretty performant. [13:26] it's not only native code, it's also the API: forget about pages, etc. It's like a desktop app. [13:26] hyperair: in fact, you can also compile the webapp to a FastCGI module instead of using the embedded HTTP server [13:26] 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] 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] Chipzz: *shrug* i'm talking about the idea of webtoolkit in general, not the jquery instance. [13:28] Chipzz: also a reverse proxy is sometimes a rather overengineered solution. [13:28] hyperair: not as overengineered as compiling jquery.min.js into a .so :| [13:28] Chipzz: because that way when you want to deploy your webapp, you only need to deploy ONE single executable that embeds everything [13:28] Chipzz: the framework's already there. i don't think it's really that overengineered. [13:28] Chipzz: it probably ends up even simpler. [13:29] Chipzz: especially at the deployment stage [13:30] pgquiles: which matters exactly nada since you're packaging it. you deploy your webapp by using apt-get install or dpkg -i [13:31] Chipzz: not everybody packages everything. Especially on embedded, Windows, mobile, etc [13:32] pgquiles: no, but you are asking specifically in the context of packaging it [13:32] pgquiles: does witty generate this one-executable-binary thing for new webapps? [13:32] Chipzz: sorry, I don't follow. The 'witty' package contains the libraries to develop webapplications, not an aplication [13:33] pgquiles: i.e. it generates the single-executable-webapp? [13:33] pgquiles: like a funky linker? [13:33] 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] wtfcgi [13:33] hyperair: Wt webapps are developed in C++ and compiled and linked using gcc and ld [13:33] i like that name. [13:34] pgquiles: same difference really. [13:34] it's not "link a funky linker" but "using a funky linker" :-) [13:34] Chipzz: so there you have it. witty isn't a web server. it provides the tools to make a one-executable webserver. [13:34] that's it [13:34] Chipzz: with embedded webapp. [13:34] hyperair: like I just said, same difference. unless witty is some sort of "compiler" instead of a "library" [13:34] Chipzz: that's exactly what i'm talking about. [13:35] Chipzz: more like a runtime that's statically linked with your webapp. [13:35] Chipzz: witty is a C++ library. You use it like you use Gtk+, Qt, libc, etc [13:35] static linking? this keeps getting better and better [13:35] Chipzz: or dynamic linking, your choice [13:35] Chipzz: it's a one-executable webapp-cum-server. wtf else do you expect it to be besides static linking?! [13:36] hyperair: do I need to point out debians and ubuntus stance about static linking? [13:36] it's something you throw at somebody and tell them to execute to host a web server with said webapp [13:36] libwt*-dev include the static libraries and the dynamic libraries [13:36] Chipzz: it's for *your own* web app. [13:36] Chipzz: something you're going to throw at $other_distro to run. [13:37] hyperair: what happens when it turns out the version of jquery witty is currently shipping turns out to be buggy? [13:37] Chipzz: then you binNMU. [13:37] Chipzz: actually, then you run into the discussion from debian-devel [13:38] all the reverse deps? including all the webapps you compiled against witty and you sent off god-knows-where? [13:38] Chipzz: if you replace jquery, probably the webapp breaks because it's not ready for that new version of the javascript library [13:38] Chipzz: just dynamic link, man [13:38] Chipzz: pgquiles said you can dynamically link your webapp anyways, so... [13:38] static linking is your choice and it's not the default [13:38] (CMake picks the so's by default) [13:39] 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] 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] your strawman is burning very brightly [13:40] Chipzz: try Wt, then tell me what you think. After using it :-) [13:41] pgquiles: he probably won't, due to his set preconceptions against it. [13:42] 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] i'll just say this out loud first: i dislike qt's way of reimplementing half the C++ standard library. [13:44] if wt does the same thing, i won't touch it with a 100-foot pole. [13:44] case in point QString [13:44] 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] pgquiles: that's in the past. qt4 could have dropped that. [13:45] hyperair: Wt uses Boost, it does not reimplement [13:45] oh goody. [13:45] hyperair: no, Qt 4 could not do that [13:45] case in point: Solaris [13:45] pgquiles: typedefs blah blah thin wrappers [13:45] HP-UX [13:45] AIX [13:45] people use that crap? [13:45] * hyperair coughs [13:45] you'd be surprised how many companies use Boost [13:45] i'm not talking about boost [13:46] i'm talking about solaris/hp-ux/aix [13:46] sure, less and less, but it's still widely used [13:46] boost is superbly awesome. [13:46] heck, even SCO still has some clients left! :-D [13:46] yes, why couldn't qt use boost? [13:46] 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] pgquiles: qt4 is fairly recent. boost was very mature by then [13:46] also, Boost does not promise binary compatibility across versions [13:46] not even now [13:46] oh right, that. [13:46] * hyperair sighs [13:47] Qt4 was released in 2005, started in 2003 [13:47] Qt 5 will be released early 2012 [13:47] also, C++ still does not provide introspection capabilities [13:47] nor will it ever. [13:47] which is one of the main features moc provides [13:47] i find it a disgusting bastardization of C++ [13:47] even Glib has resorted to invent a mechanism for introspection [13:48] that's because C has no OO capabilities. [13:48] the fact that C does not provide classes does not mean it has no OO capabilities [13:48] Glib and Gtk are OO with C [13:49] correction: with C/GObject. [13:49] it's all part of GObject's API [13:49] it's not pure C. [13:49] for the record, gobject's reference counting has driven me up the wall many a time [13:49] grammatically you are right [13:49] * hyperair sighs [13:50] my definition of standard C is what ##c has. [13:50] and my definition of standard C++ is what ##c++ has. [13:50] by those definitions, i am correct in saying that C has no OO capabilities, period. [13:50] not "grammatically" or "technically" or any crap like that. [13:54] 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] when you need a preprocessor that's not the standard C++ preprocessor, it's no longer C++. [13:57] What is moc? [13:59] hyperair: It's not too unusual to have preprocessed stuff before your lang [13:59] maco: the metaobject compoiler [13:59] hyperair: GObject introspection requires the use of the gir scanner, which is essentially the same as moc [14:00] pgquiles: there is a difference. [14:00] maco: http://doc.qt.nokia.com/latest/moc.html [14:00] pgquiles: the gir scanner scans the *exact* same thing as the input to gcc. [14:00] pgquiles: the input to moc isn't the same thing that goes into g++ [14:04] 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] hyperair: Which I guess is why you get things like Vala [14:05] penguin42: or people could use C#! \o/ [14:05] hyperair: Yeh [14:05] * hyperair holds up his evil mono supporter flag [14:05] * penguin42 burns it [14:05] >=O [14:06] penguin42: gtkmm is standard C++ though. [14:07] * penguin42 hasn't played with it [14:09] it's good stuff. unfortunately it doesn't work with gobject introspection [14:09] so C++-implemented widgets can only be used by other gtkmm things [14:40] 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] @? [14:41] Error: "?" is not a valid command. [14:41] that's pretty cool [14:42] hyperair: the subvolume tat holds "/" is named "@", yes. [17:19] May package in PPA depend in package in another PPA? (Or what is the right channel for this question?) [17:21] 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] thanks, broder [17:31] When will I be able to see my work items in http://status.ubuntu.com/ubuntu-precise/u/jonathan.html ? [17:31] Or should I be looking somewhere else? === emma is now known as Em [19:13] Empathy is broken since last upgrade it seems :( [19:13] [ 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 === lacqui_ is now known as lacqui [20:10] lifeless: lp:~vorlon/launchpad/sbuild-multiarch-syntax test case> where's the right place for me to add this? [20:11] slangasek: you know, I have no idea :) [20:12] 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] how soon do you need this change live? [20:20] 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] lifeless: indeed, 3 out of 5 Prio: required packages that I've looked at so far are affected (acl, attr, bash) [21:08] hello [21:08] could someone tell me where dh_make store the packager name information ? i'd to change it [21:09] marseillai_: debian/control [21:10] jbicha: i didn't explain weel sorry. [21:11] 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] it mispel my name [21:42] marseillai_: DEBFULLNAME environment variable [21:50] marseillai_, you can store that info in .bashrc, and it may be there [21:58] TheMuso: DktrKranz and bjsnider