| sveinse | penguin42: excellent, thanks. It works using the Linaro PPA. I'll comment that on the bug | 00:04 |
|---|---|---|
| penguin42 | no problem | 00:05 |
| 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:35 |
| penguin42 | broder: could be a load of differences I guess; don't the buildd's tend to run with fairly old kernels? | 00:46 |
| 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 | 00:47 |
| 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 |
| ubottu | Launchpad bug 885329 in eggdrop (Ubuntu) "eggdrop crash on i386" [Undecided,New] https://launchpad.net/bugs/885329 | 03:39 |
| lacqui | debian/rules:4: /usr/share/cdbs/1/rules/debhelper.mk: No such file or directory | 03:39 |
| 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 | 03:42 |
| lacqui | Is this the right place to request a review for a bug fix? (#885329) | 05:38 |
| sladen | lacqui: let me have a look | 05:54 |
| lacqui | sladen: thanks | 06:03 |
| === yofel_ is now known as yofel | ||
| 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:13 |
| ubottu | Launchpad bug 886456 in witty (Ubuntu) "Built-in httpd does not render any widget" [Undecided,Fix committed] | 13:13 |
| tumbleweed | pgquiles: request a rebuild in the bug and subscribe ubuntu-sponsors | 13:16 |
| pgquiles | tumbleweed: thank you | 13:16 |
| 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:17 |
| 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:18 |
| tumbleweed | converts jquery to C++? eep | 13:19 |
| Chipzz | pgquiles: exactly how do you intend to convert jquery into C++?? | 13:20 |
| hyperair | O_o | 13:20 |
| 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:21 | |
| 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:22 |
| 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:23 | |
| 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:24 |
| 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:25 |
| 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:26 |
| hyperair | Chipzz: *shrug* i'm talking about the idea of webtoolkit in general, not the jquery instance. | 13:27 |
| 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:28 |
| hyperair | Chipzz: especially at the deployment stage | 13:29 |
| Chipzz | pgquiles: which matters exactly nada since you're packaging it. you deploy your webapp by using apt-get install or dpkg -i | 13:30 |
| pgquiles | Chipzz: not everybody packages everything. Especially on embedded, Windows, mobile, etc | 13:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| pgquiles | Chipzz: try Wt, then tell me what you think. After using it :-) | 13:40 |
| hyperair | pgquiles: he probably won't, due to his set preconceptions against it. | 13:41 |
| 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:42 |
| hyperair | i'll just say this out loud first: i dislike qt's way of reimplementing half the C++ standard library. | 13:43 |
| 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:44 |
| 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:45 |
| 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:46 | |
| 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:47 |
| 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:48 |
| 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:49 | |
| 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:50 |
| 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:54 |
| maco | What is moc? | 13:57 |
| 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 | 13:59 |
| 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:00 |
| 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:04 |
| 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:05 |
| hyperair | penguin42: gtkmm is standard C++ though. | 14:06 |
| * penguin42 hasn't played with it | 14:07 | |
| 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:09 |
| 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:40 |
| hyperair | @? | 14:41 |
| udevbot_ | Error: "?" is not a valid command. | 14:41 |
| hyperair | that's pretty cool | 14:41 |
| mewerner_arand | hyperair: the subvolume tat holds "/" is named "@", yes. | 14:42 |
| hlamer | May package in PPA depend in package in another PPA? (Or what is the right channel for this question?) | 17:19 |
| 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:21 |
| hlamer | thanks, broder | 17:22 |
| 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? | 17:31 |
| === emma is now known as Em | ||
| 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 | 19:13 |
| === lacqui_ is now known as lacqui | ||
| slangasek | lifeless: lp:~vorlon/launchpad/sbuild-multiarch-syntax test case> where's the right place for me to add this? | 20:10 |
| lifeless | slangasek: you know, I have no idea :) | 20:11 |
| 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:12 |
| 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:20 |
| slangasek | lifeless: indeed, 3 out of 5 Prio: required packages that I've looked at so far are affected (acl, attr, bash) | 20:27 |
| marseillai_ | hello | 21:08 |
| marseillai_ | could someone tell me where dh_make store the packager name information ? i'd to change it | 21:08 |
| jbicha | marseillai_: debian/control | 21:09 |
| marseillai_ | jbicha: i didn't explain weel sorry. | 21:10 |
| 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:11 |
| DktrKranz | marseillai_: DEBFULLNAME environment variable | 21:42 |
| bjsnider | marseillai_, you can store that info in .bashrc, and it may be there | 21:50 |
| marseillai_ | TheMuso: DktrKranz and bjsnider | 21:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!