[00:28] hi all... after the recent change to the linker (passing --as-needed by default) I have a package that is FTBFS with something like "./.libs/libpengine.so: undefined reference to `resource_location'." So I was wondering how can I find where are those symbols located (or in which library), so that I can add that to LDFLAGS? [00:29] before the change, the message was "warning: symbol resource_location used by debian/libpengine3/usr/lib/libpengine.so.3.0.0 found in none of the libraries." however it didn't FTBFS [00:31] RoAkSoAx: use apt-file to search for the library that provides that? [00:32] RoAkSoAx, that's rather a generic name for a symbol, so it might be supposed to come from the package itself. Might be worth grepping the package source first [00:33] james_w: i did that with this result: http://pastebin.ubuntu.com/532677/ [00:34] RoAkSoAx: It's in lib/pengine/utils.{h,c} [00:34] RoAkSoAx, ok, so depending on the buildsystem there is probably a missing dependency between parts of the project [00:34] RoAkSoAx, is it autotools? [00:35] james_w: yes it is [00:35] ebroder: right, but that's the thing, libpengine says those are missing symbols of itself? [00:36] RoAkSoAx, it probably doesn't link utils.o in to libpengine.so [00:37] james_w: so what could be the possible fix? patch the makefile somehow? [00:38] james_w: or telling it to use that utils.o by passing it through LDFLAGS? [00:38] RoAkSoAx, I'm just trying to remember how all this works [00:44] james_w: this is the makefile btw http://pastebin.ubuntu.com/532685/ [00:47] RoAkSoAx, that doesn't seem to build libpengine [00:47] RoAkSoAx, can you grep for libpengine in all Makefile.am in the tree? [00:48] RoAkSoAx: what package are you actually building? libpengine? [00:49] achiang, pacemaker [00:50] is there a full build log available somewhere? [00:50] james_w: the only one that list libpengine i a makefile is this one: http://pastebin.ubuntu.com/532686/ [00:51] achiang: i'll get it for you :) [00:52] RoAkSoAx, line 59 has utils.c, which is what I would have suggested you add :-) [00:52] achiang: http://launchpadlibrarian.net/59133765/buildlog_ubuntu-natty-amd64.pacemaker_1.0.9.1%2Bhg15626-2ubuntu1_FAILEDTOBUILD.txt.gz [00:52] james_w: indeed, and yet it still FTBFS [00:54] RoAkSoAx, ah, it's building the executable when it fails [00:57] RoAkSoAx, now I'm even more confused :-) [00:58] it seems to link pengine fine the line before, then fail when linking ptest [01:00] james_w: indeed it is confusing... I think I'll just opt for a ' -Wl,--no-as-needed' to disable the '--as-needed' [01:01] RoAkSoAx: That seems almost certainly like obscuring the problem... [01:03] ebroder: indeed... but upstream doesn't even know why it may be failing and I can't seem to find a solution for the problem :( [01:03] resource_location isn't declared static or something like that, is it? [01:06] ebroder:in utils.h is extern void resource_location(resource_t *rsc, node_t *node, int score, const char *tag, pe_working_set_t *data_set); [01:06] this looks like an optimizer problem to me [01:06] ...it's declared extern? [01:06] ebroder: and in utils.c is just a simple voide resource_location... [01:06] if object file foo.o requires symbols from object file (or library) bar.[s]o, then foo.o must come to the *right* of bar.[s]o in the linker invocation [01:07] otherwise, the optimizer strips out all unused symbols from foo.o [01:08] sorry, the optimizer strips out unused symbols from bar.[s]o [01:08] achiang: could you provide an example cause I don't seem to follow :S [01:08] RoAkSoAx: let's say ptest.o needs a symbol from libpengine.so [01:09] that means when you link it, you must say: bla bla bla -lpengine -o ptest.o [01:10] what happens is the linker looks at the symbols in ptest.o; it sees something called "resource_location", and it's undefined in ptest.o [01:10] "no problem" says the linker, i'll find it later somewhere up the line [01:11] if you do it the other way around, the linker looks at libpengine.so, and sees a symbol called "resource_location" [01:11] it says, "hm, no one is using this symbol yet, so i can just optimize it out" [01:11] achiang: so this should be changed from: -o .libs/ptest ptest.o ../lib/common/.libs/libcrmcommon.so ../lib/pengine/.libs/libpe_status.so ./.libs/libpengine.so -lncurses /usr/lib/libhbclient.so /usr/lib/libccmclient.so -lcoroipcc ../lib/cib/.libs/libcib.so ../lib/transition/.libs/libtransitioner.so /usr/lib/libgnutls.so /usr/lib/libplumb.so /usr/lib/libpils.so -lbz2 /usr/lib/libxslt.so /usr/lib/libxml2.so -lc -luuid -lpam -lrt -ldl /usr/lib/libgl [01:11] then when you try and link ptest.o, you get the undefined reference [01:12] RoAkSoAx: that is my theory without actually looking at any code. it's a simple test to try for now [01:12] RoAkSoAx: in one sentence, the linker reads from right to left, not left to right. so you must arrange your objects that way [01:12] achiang: AFAICT, pengine is using automake+libtool in the way that the docs recommend. If you're right, then all automake+libtool things should be breaking [01:14] achiang: so how would I do that, fixing up the Makefile? [01:15] RoAkSoAx: let me try and find an example [01:15] achiang: thanks :) [01:15] ebroder: like i said, it's just a theory [01:17] RoAkSoAx: here's one that i fixed a while ago... https://bugs.launchpad.net/ubuntu/+source/alpine/+bug/668499 [01:18] RoAkSoAx: hm, that is not very instructive, is it? :-/ [01:20] feh, my natty pbuilder seems busted. can't do a test build of pacemaker due to unmet dependencies [01:21] achiang: more or less :/ I'd just need to find where to patch it :) [01:27] RoAkSoAx: as a quick test for my theory, i think you can try adding this: [01:29] achiang: yes....? [01:29] ptest_LDFLAGS = -l$(top_builddir)/lib/... [01:29] sorry, trying to figure out the relative path of libpengine.so [01:30] achiang: cool I will. Thanks for the help :) [01:30] RoAkSoAx: sorry, that's not complete yet [01:31] still trying to figure out the answer [01:31] ah, ok. there it is [01:31] add this to the proper makefile: [01:31] ptest_LDFLAGS = libpengine.la [01:31] i *think* that should force the library *before* ptest.o [01:32] RoAkSoAx: if you try that, can you please show me the build output afterwards, whether it works or not? [01:33] achiang: i will [01:41] achiang: I added this, but shows same error: http://pastebin.ubuntu.com/532712/ [01:41] RoAkSoAx: ok, i need to see the complete build log please [01:41] http://pastebin.ubuntu.com/532713/ [01:41] achiang: oh ok, give me a sec [01:42] RoAkSoAx: nm, i see it didn't make it onto the linker line [01:44] RoAkSoAx: i don't know how to force libpengine.la before ptest.o to test my idea. perhaps whereever you were going to add "-Wl,--no-as-needed", you could instead add the reference to the library instead [01:44] achiang: yest that's what I was thinking off [01:46] achiang: something like LDFLAGS += -Wl,--no-as-needed -libpengine.la -Wl,--as-needed ? [01:47] RoAkSoAx: well... i would not use -Wl,--no-as-needed because as mentioned earlier, that masks the real problem. [01:47] RoAkSoAx: try LDFLAGS += -llibpengine.la [01:48] RoAkSoAx: but i must admit, you might have to play around with that a little. sorry, i'm not giving very good advice right now, a little distracted and thinking about dinner (i'm GMT-7) [01:50] achiang: haha that's fine :)... I'm in same situation (GMT-5) [01:50] :) speaking of which, time to go a-foraging [01:52] achiang: i'll try that but im too tired and too hungry to keep on fighting with it. Thanks for your help :) [01:53] ebroder: james_w thank you to you too guys :) === sanchaz is now known as sanchaz-away [03:22] doko_: It looks like the Qt patch to add the missing IT instructions for Thumb2 support is ~working well enough to let it build. The problem I thought was related to lack of implicit-it=thumb in the new gcc-4.5 is actually a different problem. So Bug #675347 is blocking us now on getting qt4-x11 and the rest of the Qt/KDE stuff building on arm. [03:22] Launchpad bug 675347 in gcc-4.5 (Ubuntu Natty) "volatile int causes inline assembly build failure" [High,Confirmed] https://launchpad.net/bugs/675347 [03:45] ScottK: In the interests of making backports bugs more machine-parseable, what would you think of adding tags to indicate the source release? i.e. from-natty, etc. [03:46] ebroder: I think without a script to file such bugs they will be too error prone to rely on the tags. [03:46] If we have proper tool support, then I think it's all good. [03:47] ScottK: Ok, fair enough. I guess I'll have my "backport-helper" script prompt for now [03:48] OK. === jelmer is now known as Guest86531 === amitk is now known as amitk-afk === amitk-afk is now known as amitk [08:04] good morning! [08:11] Good morning [08:20] barry, do you know what still needs to happen wrt bug 663343? [08:20] Launchpad bug 663343 in cheetah (Ubuntu) "Please merge cheetah 2.4.2.1-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/663343 [08:20] your merge proposal is marked as 'merged' - can we close the bug? what about Clint's merge proposal? [08:30] mvo: Hi. [08:33] hey wgrant [08:34] mvo: I just saw your comment on bug #45129. [08:34] Launchpad bug 45129 in Soyuz "FFe: update-manager should have per-package changelog locations (was: uses changelogs.ubuntu.com for all packages)" [Low,Triaged] https://launchpad.net/bugs/45129 === smb` is now known as smb [08:35] mvo: In the IRC discussion you said you'd have to use the binary name and version in the changelog path. But the update-manager diff uses source name and version. [08:35] The latter is better for us, but just wanted to confirm that that's still the case. [08:37] wgrant: let me double check, but iirc my concern was cases like "gcc-defaults" with src_ver != bin_ver. but because the Source: field contains the src-ver it should work just fine [08:37] mvo: Yep, that's what I thought. [08:38] wgrant: i.e. update-manager can construct the url without the need for a deb-src line [08:38] wgrant: I just checked the code, the sourcepkg and sourcever should be enough [08:39] wgrant: to make u-m work [08:39] mvo: Perfect, thanks. [08:40] * mvo goes and implements that in apt-get changelog too [08:41] * wgrant goes and implements that in Soyuz. [08:41] !!! [08:41] * mvo hugs wgrant [08:41] deathrow might be a bit of a challenge, but we'll see. [08:42] that is the orphan cleanup part of soyuz? or punishment if tests fail? [08:42] It's the bit that removes orphaned files from the pool. [08:42] * mvo nods === rraphink is now known as raphink === Guest86531 is now known as jelmer === MacSlow is now known as MacSlow|afk === jjohansen1 is now known as jj-afk === MacSlow|afk is now known as MacSlow [10:32] pitti: Hallo, I'm presently working on the schedule for language packs updates for Maverick. I was wondering how long it takes to build them and distribute to the proposed update repositories [10:33] TLE: building and uploading the sources takes about 3 hours; getting them built about half a day [10:33] a full base export takes a bit longer [10:33] pitti: more specifically, if the build starts on wednesdays at 1400 UTC at which time can I then plan on those packages being built, you copying them to proposed and finally them being distributed among the mirrors? [10:34] TLE: your first "the build" is for the LP export, or langpack-o-matic? [10:36] langpack-o-matic [10:36] the exports seems to have a welldefined timeframe for them in this schedule: https://dev.launchpad.net/Translations/LanguagePackSchedule [10:38] TLE: it wildly depends on the load of the buildds, but I'd say 12 hours in good circumstances (by and large idle buildds), and 20 in peak times [10:39] ok, then after they are built, how much time for you to upload to proposed and circulate between mirrors, roughly? [10:40] What'm really interested in is when we can tell users they can start testing them [10:40] TLE: those 12/20 hours include the total turnaround starting from langpack-o-matic cron job [10:41] until you can apt-get them on clients [10:41] ahh ok, I thought that you would have to manually intervene to upload to proposed [10:42] TLE: I do, but that's part of the process [10:42] TLE: we never upload anything to -proposed automatically [10:43] we do (or at least, want to, it's broken right now) upload to the daily PPA, and from there it's a manual process to copy to -proposed [10:45] I'm a little confused, so as it is right now, you start a process at the dates we agree on that builds the latest exported files from launchpad and puts them in proposed, and that takes <24 hours, correct? [10:45] right [10:46] TLE: more precisely, the cron jobs will build them automatically from Launchpad and upload into the test PPA [10:46] TLE: and from there I'll copy them to -proposed at the agreed dates [10:48] All right, but you are in some way informed when the builds are done or something, so you don't need much time to do the uploads [10:49] I just don't want to set to tight deadlines for us [10:50] I mean to copy them from the ppa to -proposed [10:51] sorry if I'm a little dense today, I just want to get it right [10:56] TLE: the point where I need to do manual action is to issue the copy from PPA to -proposed; the rest happens automatically [10:56] I'm not notified when all the builds are finished, though [10:56] one can find out by looking at https://launchpad.net/builders [10:59] pitti: ok, cool thanks [11:00] tkamppeter: I am currently debugging why jockey takes so long to detect hardware [11:00] tkamppeter: I shaved off 5 seconds, now I'm down to about 15.5 seconds on my system [11:00] tkamppeter: of which 15 seconds is cupshelpers.getDevices(), all the rest is trivial [11:00] tkamppeter: i. e. this takes 15 seconds here: python -c 'import cups, cupshelpers; print cupshelpers.getDevices(cups.Connection())' [11:01] tkamppeter: do you know what takes it so long? === MacSlow is now known as MacSlow|lunch [11:01] tkamppeter: should jockey perhaps not do that in the first place? s-c-p always calls it with a particular printer model already, right? === diwic is now known as diwic_afk [11:08] doko_: hey, around? I'm fighting with a gcc 4.5 build issue [11:09] didrocks: still firefox? [11:10] doko_: ? I'm not maintaining firefox :) no, it's about gnome-settings-daemon: http://launchpadlibrarian.net/59165700/buildlog_ubuntu-natty-i386.gnome-settings-daemon_2.32.1-0ubuntu1_FAILEDTOBUILD.txt.gz [11:10] doko_: as you can see we are building an additional file called debian/gnome-update-wallpaper-cache.c (http://paste.ubuntu.com/532905/) which simple options [11:11] doko_: we were already building the package for --as-needed for quite a long time. I tried even --no-as-needed without any success [11:11] doko_: I confirm it's still building fine with gcc 4.4 === asac_ is now known as asac [11:12] didrocks: would be nice to see how pkg-config expands ... [11:12] doko_: sure: http://paste.ubuntu.com/532927/ nothing to worry about it seems [11:14] pitti: pkgstripfiles seems to still be removing changelog.Debian.gz in the odd case, e.g. https://launchpad.net/ubuntu/+source/biococoa/2.2.1-1/+build/2048985 [11:15] something to do with symlinked changelogs between multi-binary sources maybe? [11:16] pitti: I bet the symlink is broken so test -e fails. perhaps: [11:16] -if [ ! -e "$dch" ]; then [11:16] +if [ ! -e "$dch" ] && [ ! -h "$dch" ]; then [11:16] cjwatson: right, it shouldn't touch symlinks at all [11:17] cjwatson: thanks for pointing out; I'll add a test case and fix it [11:17] ta, just noticed 'cos new-binary-debian-universe complained at me [11:22] pitti: ~branding-ubuntu -- do you think we can put pngcrush in there too? [11:22] also kudos on the improvement ;) [11:22] YokoZar: do you think pngcrush does anything good on top of optipng and advancecomp? (which are already done in pkgbinarymangler) [11:22] actually maybe branding-ubuntu doesn't have any png, only svg... [11:23] pitti: actually, good question, I'm not sure if pngcrush -9 is better than optipng [11:23] maybe binary mangler could just run both and compare [11:25] and shouldn't optipng be in main if it's done in pkgbinarymangler? [11:25] YokoZar: optipng is in main [11:26] oh, just not in maverick [11:26] err nevermind [11:29] mvo, hi, attempting to upgrade a package using a .deb, using software center should work ? [11:44] mvo: ^ I tried software-center yesterday to install a .deb from firefox, worked great; is that meant to make gdebi obsolete, or was it just an accident? [11:44] ah, seems we already dropped it, nevermind === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [11:54] hallyn: you dropped the capslock patch in qemu-kvm 0.12.4+noroms-0ubuntu1, which let bug #427612 reappear in maverick. i am using the NEO2 layout, where the caps lock key is a normal key. [11:54] Launchpad bug 427612 in qemu-kvm (Ubuntu) "does not pass pressed caps lock to client" [Low,Fix released] https://launchpad.net/bugs/427612 === MacSlow|lunch is now known as MacSlow [12:20] cjwatson: just to be crystal clear, this week is not a week before an alpha is it? [12:20] cjwatson: nm [12:21] joaopinto: is that not working? [12:22] jml: no === diwic_afk is now known as diwic [12:43] mvo, nope, at least not on maverick, it just shows the installed button disabled [12:43] the install === amitk is now known as amitk-afk [13:20] bdrung: yes, that's what i said yesterday. Someone needs to explain in the other bug: if we're going to carry a patch somewhere, why shouldn't it be in SDL to fix the root cause. [13:21] ogra_ac: Any change you can try to build https://launchpad.net/ubuntu/+source/lightspark on something faster than my Beagleboards/EfikaMX ? [13:21] hallyn: is that really a bug in sdl? [13:22] stgraber, will tyr to [13:22] ogra_ac: cool, thanks [13:23] stgraber: please consider it won't build other than i386 and amd64 (ppc port is still WIP) [13:26] DktrKranz: ah, ok. Any plan for an ARM port ? [13:29] bdrung: yes, that's the explanation by upstream on why they won't take it [13:29] stgraber: most of the code is portable (C++), but it also has a per-architecture portion of code written in assembly, which requires soneone to write it [13:30] someone, even [13:30] bdrung: and we really don't want to have patches which were rejected by upstream. we'd *like* to follow their guidance to pursue the proper fix. Unfortunately I haven't had time yet to look into the SDL code for more background. [13:31] bdrung: if you have time, that'd be *awesome*. In fact, if in the end you can explain why SDL must be so, and why there's no other way, then we can (grudgingly) take the patch back into qemu. [13:32] hallyn: i have not enough time to dig into it, but i am offer testing. my testcase: set keyboard layout to NEO2 (in host and vm) and press caps+t (result should be "-") [13:33] hallyn: in NEO2 the caps lock key is used as modifier (similar to shift and ctrl) [13:47] bdrung: now, as a workaround, using vnc should work correctly for you, right? [13:47] hallyn: how do i use vnc with kvm? [13:49] cjwatson: I was looking for a way for Launchpad to show me the merge preview in the review interface [13:50] Keybuk: mad fool [13:54] Keybuk: it would do if not for the Launchpad bug I linked to in my comment [13:54] heh === xfaf is now known as zul [14:04] bdrung: if you're using kvm from cmline, you do 'kvm -vnc :1' (or :2, etc) then from the host 'vncviewer :1' to connect to it [14:04] bdrung: it's particularly useeful as it makes it easy to cross ssh tunnels [14:09] 310 [14:10] hallyn: thanks. i tested vinagre and in vinagre the caps lock behave correct. what does this tell us? [14:11] bdrung: only that you have a workaround [14:12] bdrung: well, kirkland supports putting the patch back in, so maybe we'll end up doing that [14:12] hallyn: Don't use xvncviewer :) [14:13] hallyn: gvncviewer uses gtk-vnc which is What You Want To Use[tm]. I believe it supports "-via", too, just like xvncviewer. [14:13] soren: think i use tightvncviewer [14:14] and actually i don't use -vio [14:14] hallyn: Same deal. [14:14] via [14:14] hm, why? [14:14] hallyn: So you do the ssh forwarding manually? dude, you're missing out :) [14:14] hallyn: Lots of things are simply not supported properly in clients other than gtk-vnc. [14:15] raw key codes, for instance, which is a deal breaker for many use cases. [14:15] hm. allright, i'll try it sometime. but as for forwarding, doing it manually means i can just do it the same way on my n900, on my mom's windows machine, etc. [14:16] soren: in the past, i had a lot of trouble with mix-matching vnc's, and back then i just settled on xtight as something that works everywhere [14:16] i wonder whether that's been mostly addressed by now [14:16] soren: so package gtkvncviewer ? [14:16] lool: did you push your changes for qemu-kvm (0.13.0+noroms-0ubuntu3) to lp:ubuntu/qemu-kvm ? [14:16] hallyn: There's an interesting intersection of people working on gtk-vnc and on various virt technology. [14:16] lool: i just had an upload conflict [14:16] hallyn: Like danpb and aliguori. [14:17] hallyn: It's packaged. [14:17] yeah, but there are at least 2 that sound like it :) [14:17] gtkvncviewer and gvncviewer [14:17] hallyn: Both should be fine. [14:18] hallyn: They both use gtk-vnc. [14:18] hallyn: gvncviewer is just more familiar if you're used to xvncviewer. === bregma_ is now known as bregma [14:20] all right, installed, i'll give it a spin, thanks :) [14:20] sure :)( [14:21] :) [14:21] I'm looking for some guidance on filing an SRU in maverick, is there anyone around to give me some advice? [14:21] hallyn: okay, mouse fixes uploaded [14:21] hallyn: i had to resolve a conflict with lool's last qemu-kvm upload [14:22] kirkland: oh? i had just fetched the tree late last night [14:22] hallyn: yup, you did the right thing [14:22] i'm getting just about burned out on bugs for the week [14:23] hggdh: ping [14:23] hallyn: it's tuesday :-) [14:23] hallyn: bugs are to be taken orally not rectally ;) [14:24] doh! === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [14:37] anyone know of a PPA or something with an ubuntu kernel and the new wonder UI patch applied? [14:38] NoobFukaire1: you may ask in #ubuntu-kernel [14:38] thx === jam1 is now known as jam [14:54] kees, cjwatson, mdz: TB in 5 mins, right? or in an hour? [14:55] my belief is 5mins === chrisccoulson_ is now known as chrisccoulson [14:59] stgraber, omg ... 700M build deps ? [15:01] ogra_ac: do you perhaps have a minute to shed some insight on a classmate issue in #edubuntu? [15:02] ogra_ac: I'm guessing it build-deps on gstreamer and a few similar stuff :) Though as mentioned by DktrKranz earlier, it'll fail anyway as the code needs to be "ported" to ARM (as in, add a bit of ARM assembly in the code). [15:03] ogra_ac: they support x86 32/64bit and seem to be working on a powerpc port, maybe we can find someone willing to do the work (or at least look at it) to make it compatible with ARM [15:03] stgraber, assembly ??? [15:04] 14:29 < DktrKranz> stgraber: most of the code is portable (C++), but it also has a per-architecture portion of code written in assembly, which requires soneone to write it [15:04] apparently, yes ... [15:04] bah [15:05] there should really be no assembly [15:06] I agree :) I'm guessing it's meant for performance optimization or whatever. [15:06] thats nonsense in times of gcc 4.5 ;) [15:07] zul: consider yourself ponged [15:09] hggdh: sorry i figured it out :) [15:09] zul: heh [15:11] hallyn: qemu-kvm FTBFS: http://launchpadlibrarian.net/59199370/buildlog_ubuntu-natty-i386.qemu-kvm_0.13.0%2Bnoroms-0ubuntu4_FAILEDTOBUILD.txt.gz [15:12] stgraber, so there isnt really any point in me doing a testbuild [15:12] ogra_ac: I'd guess it's simply going to fail on the ASM part. I haven't looked at the code but based on DktrKranz's comment earlier, I wouldn't think it's going to fallback to "less efficient" c++ code [15:14] kirkland: i think that has nothing to do with us... [15:15] hallyn: interesting, alright ... [15:15] 'gcc: Internal error: Killed (program cc1) [15:15] kees: toolchain issues in natty at the moment? [15:15] doko_: ? [15:15] kirkland: and too bad, bc i'm about to propose another little merge for the same tree === diwic is now known as diwic_afk [15:18] kirkland: not sure; I just got back from holiday [15:20] kirkland: wonder whether the amd64 will pass [15:20] hallyn: doubtful [15:20] hallyn: did you try a pbuild local? [15:20] pessemist [15:20] hallyn: heh [15:20] yeah, but against maverick [15:20] hallyn: ah [15:21] (so i could run it) [15:21] hallyn: yeah [15:21] pfft, thats so unimportant, important is if armel will pass [15:21] a build is under way in a natty schroot [15:21] :) [15:21] ogra: ;-) [15:21] ogra_ac: so true [15:22] kirkland: if you're not on a call right now, interesting conversation on qemucall (about distro bugs) [15:22] hallyn: hmm, no i didn't join today [15:27] pitti: Would you please review the paragraph I added to https://wiki.kubuntu.org/Kubuntu/UpdatesPolicy (at the end of the policy section) and make sure I captured it correctly. [15:31] ScottK: that sounds fine to me, thank you [15:31] pitti: Thanks for checking. [15:32] kirkland: ha! https://launchpad.net/~serge-hallyn/+archive/virt?field.series_filter=natty === sanchaz-away is now known as sanchaz [15:32] kirkland: last night it compiled fine for natty [15:32] ScottK: added to https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions [15:33] Cool. [15:33] That's only been on my TODO for a year and a half .... === zyga is now known as zyga-afk === dholbach_ is now known as dholbach [15:39] stgraber, [15:39] CMake Error at CMakeLists.txt:96 (MESSAGE): [15:39] Platform armv7l not supported [15:57] hallyn: weird [15:58] pitti, can we reset the burn down line of canonical-community? [15:58] pitti, I tried to find a way, but there seems to be no natty.cfg === tkamppeter_ is now known as tkamppeter [15:58] dholbach: there is, on lillypilly [15:59] dholbach: sudo -u platform -i, then you can edit natty.cfg there [15:59] dholbach: (sorry, in meeting) [15:59] dholbach: lillypilly is people.c.c. [15:59] aha, I was looking in ~pitti ;-) === jj-afk is now known as jjohansen [16:00] pitti, hi [16:01] pitti, sorry for not having followed IRC. [16:01] pitti, cupshelpers.getDevices( [16:01] hello tkamppeter, how are you? (no problem, it's not that urgent) [16:01] thanks pitti [16:01] tkamppeter: I disabled cupshelpers from normal jockey operation for now, since printer drivers are almost always installed via s-c-p [16:02] pitti, cupshelpers.getDevices() takes 15 seconds like "lpinfo -v" does as CUPS waits 15 sec for answers of network and Bluetooth printers. [16:02] tkamppeter: ah, that explains it [16:03] pitti, Jockey does not actually need to look for printers. Local printers are handled via UDEV when plugged or via CUPS startup during boot. [16:03] tkamppeter: that's what I thought [16:03] tkamppeter: ok, thanks for confirming [16:05] Remote printers printers should not be set up non-interactively. One usually sets them up on one or two boxes and then one activates CUPS browsing. Therefore these printers should only get set up on explicit request by the user (via s-c-p). [16:06] So for printers Jockey should only get called for the actual driver download for an already detected printer, not for finding the printers. [16:06] right [16:08] kirkland: preprocessed source? [16:20] pitti: cjwatson: FYI (just saw the meeting and the /opt discussion), I've implemented a tentative of getting prefix support for python-support and such. It's on my ppa now: https://launchpad.net/~didrocks/+archive/ppa/ [16:20] didrocks: oh, nice [16:20] also Quickly trunk now support installing in that prefix [16:21] (and upgrade existing projects) === You're now known as ubuntulog [16:31] in a debian 3.0 quilt format, stored in bzr, should i store the bzr with the patches applied ? [16:32] i think the answer is yes [16:33] didrocks: we should be moving to dh_python2/dh_python3, though, right? [16:33] smoser: yes (IMO) [16:33] cjwatson, and store the .pc directory also ? [16:34] I don't, normally, although the importer does [16:34] it's an open question [16:34] cjwatson: I have a work item to prepare dh_python* to support prefix. But not sure with unity and such I'll have the time to support it this cycle. So, I've just keep with what exists [16:34] or were there fixes to that bug you had opened to have rules force-apply them. [16:34] I find it easier not to [16:34] and cope with the fact that other people working on the branch will have to do a little bit of fiddling after checkout/update [16:35] but that's just my opinion [16:35] i prefer no .pc, so i'll go with that. and add a rule to force fix .pc. [16:35] thanks. [16:35] stgraber, hmm, i get it to compile but on my ac100 it triggers compiler errors (which are more likely kernel errors with the tegra kernel), i will try it on a panda soon === You're now known as ubuntulog_ === You're now known as ubuntulog === yofel_ is now known as yofel === zyga-afk is now known as zyga === Claudinux_ is now known as Claudinux [17:47] kirkland: howdy!! For PowerNap I was thinking if it would be a good idea to turn off some services when on powersave mode... such as stopping logging or things that can still cause disk I/O or something... would that e something easily doable? [18:05] RoAkSoAx: hmm, i'm not too sure about that [18:05] RoAkSoAx: maybe in a future iteration [18:05] RoAkSoAx: lets focus on hardware hacks for now [18:08] kirkland: yeah the problem is that I've been trying to spin down the harddrive but it gets woken up. Maybe I'm not doing it right... Other thing I thought about is extend the time on which the data is actually written into disk [18:08] from memory to disk [18:11] kirkland: by reducing the dirty page writeback frequency [18:53] ev: could you review https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/661289 when you have time? === dendrobates is now known as dendro-afk === Claudinux_ is now known as Claudinux === dendro-afk is now known as dendrobates === blueyed_ is now known as blueyed === hanska is now known as dapal [20:04] how to get access to send email to https://lists.ubuntu.com/archives/ubuntu-devel/ ? [20:05] rsajdok: anyone can send, but it's moderated for non-developers AFAIK === dendrobates is now known as dendro-afk [20:10] micahg: I sent email yesterday. It is not yet approved === dendro-afk is now known as dendrobates [20:43] * lamont has a question... https://bugs.launchpad.net/ubuntu/+source/apt/+bug/673446 is, in fact, not an apt bug, but was an archive issue. does that mean it should get closed as 'invalid', or would 'fix released' be more accurate? [20:45] lamont, invalid [20:45] seb128: thanks [20:45] the apt task was invalid at least, you can add a comment saying that [20:45] e/win 19 [20:46] seb128: commented that it was actually an archive issue on old-releases, which I have now fixed. [20:47] lamont, ok, thanks [20:47] so amusingly, while it's not a bug in ubuntu, it is my bug. [20:47] for sad values of 'amusingly' [20:49] cjwatson, is bug 581760 testable without a windows installation ? [20:50] Launchpad bug 581760 in grub2 (Ubuntu Lucid) "[Wubi] when updating it advices to install grub on all partitions" [High,Fix committed] https://launchpad.net/bugs/581760 === ximion is now known as ximion1 === ximion1 is now known as ximion [21:00] kees: do you know what happened to the 'Dynamic "per package upload permissions" for Debian Developer' topic on the TB agenda? From a look at the wiki edits it looks like it simply got dropped without getting discussed. Sylvestre is asking about any information of the outcome. [21:09] geser: hmm... IIRC, it was supposed to go to the mailing list for further discussion? [21:09] wendar: fyi, I add PostReleaseApps/SecurityChecklist today [21:10] jdstrand: excellent, thanks! I'll read through it now [21:11] kees: the TB mailing list? [21:12] geser: yeah [21:13] kees: I don't see anything in the archives for Oct and Nov [21:13] ddd/win 13 [21:13] (bah) [21:15] geser: yeah, best to bring it up on the list then. [21:15] jdstrand: also sending the link on to the ARB list, for all members to review [21:15] wendar: cool, thanks [21:16] kees: looks like it was discussed during the meeting on 2010-11-02. Will reply to Sylvestre with the link to the meeting log. [21:17] okay [21:17] jdstrand: some of the social items in there will need more discussion, like the developer contract & $ [21:17] ajmitch: oh absolutely [21:18] ajmitch: I imagine that document to be refined after further discussion, but based on our team's current understanding, etc, etc that is what we came up with [21:18] jdstrand: thanks for putting it together [21:19] ajmitch: sure np. I wrote it up, but everyone on the ubuntu-security contributed [21:20] the ubuntu-security *team* that is [21:45] jdstrand: the comments on socially encouraging good security behavior by preventing anonymous contributions are an important addition too, thanks! [21:46] jdstrand: at the moment we require a PPA, which is a certain level of "verification" of a real human. and in the future it looks like we'll be integrating ARB with our commercial signup process, which is another level of verification [21:47] jdstrand: we may not charge a dollar for submitting an application, but we may very well take financial information from some developers, if they want to accept donations for their free software [21:47] wendar: regarding 'anonymous contributions'-- thank mdeslaur (but we all agree :) [21:48] wendar: it doesn't have to be a dollar-- it could be $.01. the idea is that it makes it harder to be anonymous (unless you are being seriously criminal) [21:49] wendar: but all the PPA business was that we don't want their software changing the upgrade system, etc [21:49] well, you probably ment that the PPA is one deterrent [21:50] wendar: anyhoo, yes it is, but it is easy to miss intentionally malicious software without a very thorough and time-consuming review. with social deterrents, you tend to get for free [21:51] /get/keep malicous software out/ [21:51] mind you, *tend* :) [21:51] a really bad guy will find a way [21:51]