[00:28] <RoAkSoAx> 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] <RoAkSoAx> 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] <micahg> RoAkSoAx: use apt-file to search for the library that provides that?
[00:32] <james_w> 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] <RoAkSoAx> james_w: i did that with this result: http://pastebin.ubuntu.com/532677/
[00:34] <ebroder> RoAkSoAx: It's in lib/pengine/utils.{h,c}
[00:34] <james_w> RoAkSoAx, ok, so depending on the buildsystem there is probably a missing dependency between parts of the project
[00:34] <james_w> RoAkSoAx, is it autotools?
[00:35] <RoAkSoAx> james_w: yes it is
[00:35] <RoAkSoAx> ebroder: right, but that's the thing, libpengine says those are missing symbols of itself?
[00:36] <james_w> RoAkSoAx, it probably doesn't link utils.o in to libpengine.so
[00:37] <RoAkSoAx> james_w: so what could be the possible fix? patch the makefile somehow?
[00:38] <RoAkSoAx> james_w: or telling it to use that utils.o by passing it through LDFLAGS?
[00:38] <james_w> RoAkSoAx, I'm just trying to remember how all this works
[00:44] <RoAkSoAx> james_w: this is the makefile btw http://pastebin.ubuntu.com/532685/
[00:47] <james_w> RoAkSoAx, that doesn't seem to build libpengine
[00:47] <james_w> RoAkSoAx, can you grep for libpengine in all Makefile.am in the tree?
[00:48] <achiang> RoAkSoAx: what package are you actually building? libpengine?
[00:49] <james_w> achiang, pacemaker
[00:50] <achiang> is there a full build log available somewhere?
[00:50] <RoAkSoAx> james_w: the only one that list libpengine i a makefile is this one: http://pastebin.ubuntu.com/532686/
[00:51] <RoAkSoAx> achiang: i'll get it for you :)
[00:52] <james_w> RoAkSoAx, line 59 has utils.c, which is what I would have suggested you add :-)
[00:52] <RoAkSoAx> achiang: http://launchpadlibrarian.net/59133765/buildlog_ubuntu-natty-amd64.pacemaker_1.0.9.1%2Bhg15626-2ubuntu1_FAILEDTOBUILD.txt.gz
[00:52] <RoAkSoAx> james_w: indeed, and yet it still FTBFS
[00:54] <james_w> RoAkSoAx, ah, it's building the executable when it fails
[00:57] <james_w> RoAkSoAx, now I'm even more confused :-)
[00:58] <james_w> it seems to link pengine fine the line before, then fail when linking ptest
[01:00] <RoAkSoAx> 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] <ebroder> RoAkSoAx: That seems almost certainly like obscuring the problem...
[01:03] <RoAkSoAx> 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] <ebroder> resource_location isn't declared static or something like that, is it?
[01:06] <RoAkSoAx> 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] <achiang> this looks like an optimizer problem to me
[01:06] <ebroder> ...it's declared extern?
[01:06] <RoAkSoAx> ebroder: and in utils.c is just a simple voide resource_location...
[01:06] <achiang> 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] <achiang> otherwise, the optimizer strips out all unused symbols from foo.o
[01:08] <achiang> sorry, the optimizer strips out unused symbols from bar.[s]o
[01:08] <RoAkSoAx> achiang: could you provide an example cause I don't seem to follow :S
[01:08] <achiang> RoAkSoAx: let's say ptest.o needs a symbol from libpengine.so
[01:09] <achiang> that means when you link it, you must say: bla bla bla -lpengine -o ptest.o
[01:10] <achiang> 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] <achiang> "no problem" says the linker, i'll find it later somewhere up the line
[01:11] <achiang> if you do it the other way around, the linker looks at libpengine.so, and sees a symbol called "resource_location"
[01:11] <achiang> it says, "hm, no one is using this symbol yet, so i can just optimize it out"
[01:11] <RoAkSoAx> 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] <achiang> then when you try and link ptest.o, you get the undefined reference
[01:12] <achiang> RoAkSoAx: that is my theory without actually looking at any code. it's a simple test to try for now
[01:12] <achiang> 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] <ebroder> 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] <RoAkSoAx> achiang: so how would I do that, fixing up the Makefile?
[01:15] <achiang> RoAkSoAx: let me try and find an example
[01:15] <RoAkSoAx> achiang: thanks :)
[01:15] <achiang> ebroder: like i said, it's just a theory
[01:17] <achiang> RoAkSoAx: here's one that i fixed a while ago... https://bugs.launchpad.net/ubuntu/+source/alpine/+bug/668499
[01:18] <achiang> RoAkSoAx: hm, that is not very instructive, is it? :-/
[01:20] <achiang> feh, my natty pbuilder seems busted. can't do a test build of pacemaker due to unmet dependencies
[01:21] <RoAkSoAx> achiang: more or less :/ I'd just need to find where to patch it :)
[01:27] <achiang> RoAkSoAx: as a quick test for my theory, i think you can try adding this:
[01:29] <RoAkSoAx> achiang: yes....?
[01:29] <achiang> ptest_LDFLAGS = -l$(top_builddir)/lib/...
[01:29] <achiang> sorry, trying to figure out the relative path of libpengine.so
[01:30] <RoAkSoAx> achiang: cool I will. Thanks for the help :)
[01:30] <achiang> RoAkSoAx: sorry, that's not complete yet
[01:31] <achiang> still trying to figure out the answer
[01:31] <achiang> ah, ok. there it is
[01:31] <achiang> add this to the proper makefile:
[01:31] <achiang> ptest_LDFLAGS = libpengine.la
[01:31] <achiang> i *think* that should force the library *before* ptest.o
[01:32] <achiang> RoAkSoAx: if you try that, can you please show me the build output afterwards, whether it works or not?
[01:33] <RoAkSoAx> achiang: i will
[01:41] <RoAkSoAx> achiang: I added this, but shows same error: http://pastebin.ubuntu.com/532712/
[01:41] <achiang> RoAkSoAx: ok, i need to see the complete build log please
[01:41] <RoAkSoAx> http://pastebin.ubuntu.com/532713/
[01:41] <RoAkSoAx> achiang: oh ok, give me a sec
[01:42] <achiang> RoAkSoAx: nm, i see it didn't make it onto the linker line
[01:44] <achiang> 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] <RoAkSoAx> achiang: yest that's what I was thinking off
[01:46] <RoAkSoAx> achiang: something like  LDFLAGS += -Wl,--no-as-needed -libpengine.la -Wl,--as-needed ?
[01:47] <achiang> RoAkSoAx: well... i would not use -Wl,--no-as-needed because as mentioned earlier, that masks the real problem.
[01:47] <achiang> RoAkSoAx: try LDFLAGS += -llibpengine.la
[01:48] <achiang> 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] <RoAkSoAx> achiang: haha that's fine :)... I'm in same situation (GMT-5)
[01:50] <achiang> :) speaking of which, time to go a-foraging
[01:52] <RoAkSoAx> achiang: i'll try that but im too tired and too hungry to keep on fighting with it. Thanks for your help :)
[01:53] <RoAkSoAx> ebroder: james_w thank you to you too guys :)
[03:22] <ScottK> 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:45] <ebroder> 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] <ScottK> ebroder: I think without a script to file such bugs they will be too error prone to rely on the tags.
[03:46] <ScottK> If we have proper tool support, then I think it's all good.
[03:47] <ebroder> ScottK: Ok, fair enough. I guess I'll have my "backport-helper" script prompt for now
[03:48] <ScottK> OK.
[08:04] <dholbach> good morning!
[08:11] <pitti> Good morning
[08:20] <dholbach> barry, do you know what still needs to happen wrt bug 663343?
[08:20] <dholbach> your merge proposal is marked as 'merged' - can we close the bug? what about Clint's merge proposal?
[08:30] <wgrant> mvo: Hi.
[08:33] <mvo> hey wgrant
[08:34] <wgrant> mvo: I just saw your comment on bug #45129.
[08:35] <wgrant> 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] <wgrant> The latter is better for us, but just wanted to confirm that that's still the case.
[08:37] <mvo> 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] <wgrant> mvo: Yep, that's what I thought.
[08:38] <mvo> wgrant: i.e. update-manager can construct the url without the need for a deb-src line
[08:38] <mvo> wgrant: I just checked the code, the sourcepkg and sourcever should be enough
[08:39] <mvo> wgrant: to make u-m work
[08:39] <wgrant> 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] <mvo> !!!
[08:41]  * mvo hugs wgrant
[08:41] <wgrant> deathrow might be a bit of a challenge, but we'll see.
[08:42] <mvo> that is the orphan cleanup part of soyuz? or punishment if tests fail?
[08:42] <wgrant> It's the bit that removes orphaned files from the pool.
[08:42]  * mvo nods
[10:32] <TLE> 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] <pitti> TLE: building and uploading the sources takes about 3 hours; getting them built about half a day
[10:33] <pitti> a full base export takes a bit longer
[10:33] <TLE> 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] <pitti> TLE: your first "the build" is for the LP export, or langpack-o-matic?
[10:36] <TLE> langpack-o-matic
[10:36] <TLE> the exports seems to have a welldefined timeframe for them in this schedule: https://dev.launchpad.net/Translations/LanguagePackSchedule
[10:38] <pitti> 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] <TLE> ok, then after they are built, how much time for you to upload to proposed and circulate between mirrors, roughly?
[10:40] <TLE> What'm really interested in is when we can tell users they can start testing them
[10:40] <pitti> TLE: those 12/20 hours include the total turnaround starting from langpack-o-matic cron job
[10:41] <pitti> until you can apt-get them on clients
[10:41] <TLE> ahh ok, I thought that you would have to manually intervene to upload to proposed
[10:42] <pitti> TLE: I do, but that's part of the process
[10:42] <pitti> TLE: we never upload anything to -proposed automatically
[10:43] <pitti> 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] <TLE> 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] <pitti> right
[10:46] <pitti> TLE: more precisely, the cron jobs will build them automatically from Launchpad and upload into the test PPA
[10:46] <pitti> TLE: and from there I'll copy them to -proposed at the agreed dates
[10:48] <TLE> 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] <TLE> I just don't want to set to tight deadlines for us
[10:50] <TLE> I mean to copy them from the ppa to -proposed
[10:51] <TLE> sorry if I'm a little dense today, I just want to get it right
[10:56] <pitti> 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] <pitti> I'm not notified when all the builds are finished, though
[10:56] <pitti> one can find out by looking at https://launchpad.net/builders
[10:59] <TLE> pitti: ok, cool thanks
[11:00] <pitti> tkamppeter: I am currently debugging why jockey takes so long to detect hardware
[11:00] <pitti> tkamppeter: I shaved off 5 seconds, now I'm down to about 15.5 seconds on my system
[11:00] <pitti> tkamppeter: of which 15 seconds is cupshelpers.getDevices(), all the rest is trivial
[11:00] <pitti> tkamppeter: i. e. this takes 15 seconds here: python -c 'import cups, cupshelpers; print cupshelpers.getDevices(cups.Connection())'
[11:01] <pitti> tkamppeter: do you know what takes it so long?
[11:01] <pitti> tkamppeter: should jockey perhaps not do that in the first place? s-c-p always calls it with a particular printer model already, right?
[11:08] <didrocks> doko_: hey, around? I'm fighting with a gcc 4.5 build issue
[11:09] <doko_> didrocks: still firefox?
[11:10] <didrocks> 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] <didrocks> 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] <didrocks> 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] <didrocks> doko_: I confirm it's still building fine with gcc 4.4
[11:12] <doko_> didrocks: would be nice to see how pkg-config expands ...
[11:12] <didrocks> doko_: sure: http://paste.ubuntu.com/532927/ nothing to worry about it seems
[11:14] <cjwatson> 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] <cjwatson> something to do with symlinked changelogs between multi-binary sources maybe?
[11:16] <cjwatson> pitti: I bet the symlink is broken so test -e fails.  perhaps:
[11:16] <cjwatson> -if [ ! -e "$dch" ]; then
[11:16] <cjwatson> +if [ ! -e "$dch" ] && [ ! -h "$dch" ]; then
[11:16] <pitti> cjwatson: right, it shouldn't touch symlinks at all
[11:17] <pitti> cjwatson: thanks for pointing out; I'll add a test case and fix it
[11:17] <cjwatson> ta, just noticed 'cos new-binary-debian-universe complained at me
[11:22] <YokoZar> pitti: ~branding-ubuntu -- do you think we can put pngcrush in there too?
[11:22] <YokoZar> also kudos on the improvement ;)
[11:22] <pitti> YokoZar: do you think pngcrush does anything good on top of optipng and advancecomp? (which are already done in pkgbinarymangler)
[11:22] <YokoZar> actually maybe branding-ubuntu doesn't have any png, only svg...
[11:23] <YokoZar> pitti: actually, good question, I'm not sure if pngcrush -9 is better than optipng
[11:23] <YokoZar> maybe binary mangler could just run both and compare
[11:25] <YokoZar> and shouldn't optipng be in main if it's done in pkgbinarymangler?
[11:25] <pitti> YokoZar: optipng is in main
[11:26] <YokoZar> oh, just not in maverick
[11:26] <YokoZar> err nevermind
[11:29] <joaopinto> mvo, hi, attempting to upgrade a package using a .deb,  using software center should work ?
[11:44] <pitti> 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] <pitti> ah, seems we already dropped it, nevermind
[11:54] <bdrung> 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.
[12:20] <jml> cjwatson: just to be crystal clear, this week is not a week before an alpha is it?
[12:20] <jml> cjwatson: nm
[12:21] <mvo> joaopinto: is that not working?
[12:22] <cjwatson> jml: no
[12:43] <joaopinto> mvo, nope, at least not on maverick, it just shows the installed button disabled
[12:43] <joaopinto> the install
[13:20] <hallyn> 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] <stgraber> ogra_ac: Any change you can try to build https://launchpad.net/ubuntu/+source/lightspark on something faster than my Beagleboards/EfikaMX ?
[13:21] <bdrung> hallyn: is that really a bug in sdl?
[13:22] <ogra_ac> stgraber, will tyr to
[13:22] <stgraber> ogra_ac: cool, thanks
[13:23] <DktrKranz> stgraber: please consider it won't build other than i386 and amd64 (ppc port is still WIP)
[13:26] <stgraber> DktrKranz: ah, ok. Any plan for an ARM port ?
[13:29] <hallyn> bdrung: yes, that's the explanation by upstream on why they won't take it
[13: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
[13:30] <DktrKranz> someone, even
[13:30] <hallyn> 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] <hallyn> 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] <bdrung> 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] <bdrung> hallyn: in NEO2 the caps lock key is used as modifier (similar to shift and ctrl)
[13:47] <hallyn> bdrung: now, as a workaround, using vnc should work correctly for you, right?
[13:47] <bdrung> hallyn: how do i use vnc with kvm?
[13:49] <Keybuk> cjwatson: I was looking for a way for Launchpad to show me the merge preview in the review interface
[13:50] <davmor2> Keybuk: mad fool
[13:54] <cjwatson> Keybuk: it would do if not for the Launchpad bug I linked to in my comment
[13:54] <Keybuk> heh
[14:04] <hallyn> 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] <hallyn> bdrung: it's particularly useeful as it makes it easy to cross ssh tunnels
[14:09] <jturek> 310
[14:10] <bdrung> hallyn: thanks. i tested vinagre and in vinagre the caps lock behave correct. what does this tell us?
[14:11] <hallyn> bdrung: only that you have a workaround
[14:12] <hallyn> bdrung: well, kirkland supports putting the patch back in, so maybe we'll end up doing that
[14:12] <soren> hallyn: Don't use xvncviewer :)
[14:13] <soren> hallyn: gvncviewer uses gtk-vnc which is What You Want To Use[tm]. I believe it supports "-via", too, just like xvncviewer.
[14:13] <hallyn> soren: think i use tightvncviewer
[14:14] <hallyn> and actually i don't use -vio
[14:14] <soren> hallyn: Same deal.
[14:14] <hallyn> via
[14:14] <hallyn> hm, why?
[14:14] <soren> hallyn: So you do the ssh forwarding manually? dude, you're missing out :)
[14:14] <soren> hallyn: Lots of things are simply not supported properly in clients other than gtk-vnc.
[14:15] <soren> raw key codes, for instance, which is a deal breaker for many use cases.
[14:15] <hallyn> 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] <hallyn> 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] <hallyn> i wonder whether that's been mostly addressed by now
[14:16] <hallyn> soren: so package gtkvncviewer ?
[14:16] <kirkland> lool: did you push your changes for qemu-kvm (0.13.0+noroms-0ubuntu3) to lp:ubuntu/qemu-kvm ?
[14:16] <soren> hallyn: There's an interesting intersection of people working on gtk-vnc and on various virt technology.
[14:16] <kirkland> lool: i just had an upload conflict
[14:16] <soren> hallyn: Like danpb and aliguori.
[14:17] <soren> hallyn: It's packaged.
[14:17] <hallyn> yeah, but there are at least 2 that sound like it :)
[14:17] <hallyn> gtkvncviewer and gvncviewer
[14:17] <soren> hallyn: Both should be fine.
[14:18] <soren> hallyn: They both use gtk-vnc.
[14:18] <soren> hallyn: gvncviewer is just more familiar if you're used to xvncviewer.
[14:20] <hallyn> all right, installed, i'll give it a spin, thanks :)
[14:20] <soren> sure :)(
[14:21] <soren> :)
[14:21] <bregma> I'm looking for some guidance on filing an SRU in maverick, is there anyone around to give me some advice?
[14:21] <kirkland> hallyn: okay, mouse fixes uploaded
[14:21] <kirkland> hallyn: i had to resolve a conflict with lool's last qemu-kvm upload
[14:22] <hallyn> kirkland: oh?  i had just fetched the tree late last night
[14:22] <kirkland> hallyn: yup, you did the right thing
[14:22] <hallyn> <big sigh> i'm getting just about burned out on bugs for the week
[14:23] <zul> hggdh: ping
[14:23] <kirkland> hallyn: it's tuesday :-)
[14:23] <zul> hallyn: bugs are to be taken orally not rectally ;)
[14:24] <hallyn> doh!
[14:37] <NoobFukaire1> anyone know of a PPA or something with an ubuntu kernel and the new wonder UI patch applied?
[14:38] <bdrung> NoobFukaire1: you may ask in #ubuntu-kernel
[14:38] <NoobFukaire1> thx
[14:54] <pitti> kees, cjwatson, mdz: TB in 5 mins, right? or in an hour?
[14:55] <cjwatson> my belief is 5mins
[14:59] <ogra_ac> stgraber, omg ... 700M build deps ?
[15:01] <highvoltage> ogra_ac: do you perhaps have a minute to shed some insight on a classmate issue in #edubuntu?
[15:02] <stgraber> 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] <stgraber> 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] <ogra_ac> stgraber, assembly ???
[15:04] <stgraber> 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] <stgraber> apparently, yes ...
[15:04] <ogra_ac> bah
[15:05] <ogra_ac> there should really be no assembly
[15:06] <stgraber> I agree :) I'm guessing it's meant for performance optimization or whatever.
[15:06] <ogra_ac> thats nonsense in times of gcc 4.5 ;)
[15:07] <hggdh> zul: consider yourself ponged
[15:09] <zul> hggdh: sorry i figured it out :)
[15:09] <hggdh> zul: heh
[15:11] <kirkland> hallyn: qemu-kvm FTBFS: http://launchpadlibrarian.net/59199370/buildlog_ubuntu-natty-i386.qemu-kvm_0.13.0%2Bnoroms-0ubuntu4_FAILEDTOBUILD.txt.gz
[15:12] <ogra_ac> stgraber, so there isnt really any point in me doing a testbuild
[15:12] <stgraber> 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] <hallyn> kirkland: i think that has nothing to do with us...
[15:15] <kirkland> hallyn: interesting, alright ...
[15:15] <hallyn> 'gcc: Internal error: Killed (program cc1)
[15:15] <kirkland> kees: toolchain issues in natty at the moment?
[15:15] <kirkland> doko_: ?
[15:15] <hallyn> kirkland: and too bad, bc i'm about to propose another little merge for the same tree
[15:18] <kees> kirkland: not sure; I just got back from holiday
[15:20] <hallyn> kirkland: wonder whether the amd64 will pass
[15:20] <kirkland> hallyn: doubtful
[15:20] <kirkland> hallyn: did you try a pbuild local?
[15:20] <hallyn> pessemist
[15:20] <kirkland> hallyn: heh
[15:20] <hallyn> yeah, but against maverick
[15:20] <kirkland> hallyn: ah
[15:21] <hallyn> (so i could run it)
[15:21] <kirkland> hallyn: yeah
[15:21] <ogra_ac> pfft, thats so unimportant, important is if armel will pass
[15:21] <hallyn> a build is under way in a natty schroot
[15:21] <ogra_ac> :)
[15:21] <kirkland> ogra: ;-)
[15:21] <hallyn> ogra_ac: so true
[15:22] <hallyn> kirkland: if you're not on a call right now, interesting conversation on qemucall (about distro bugs)
[15:22] <kirkland> hallyn: hmm, no i didn't join today
[15:27] <ScottK> 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] <pitti> ScottK: that sounds fine to me, thank you
[15:31] <ScottK> pitti: Thanks for checking.
[15:32] <hallyn> kirkland: ha!  https://launchpad.net/~serge-hallyn/+archive/virt?field.series_filter=natty
[15:32] <hallyn> kirkland: last night it compiled fine for natty
[15:32] <pitti> ScottK: added to https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[15:33] <ScottK> Cool.
[15:33] <ScottK> That's only been on my TODO for a year and a half ....
[15:39] <ogra_ac> stgraber,
[15:39] <ogra_ac> CMake Error at CMakeLists.txt:96 (MESSAGE):
[15:39] <ogra_ac>   Platform armv7l not supported
[15:57] <kirkland> hallyn: weird
[15:58] <dholbach> pitti, can we reset the burn down line of canonical-community?
[15:58] <dholbach> pitti, I tried to find a way, but there seems to be no natty.cfg
[15:58] <pitti> dholbach: there is, on lillypilly
[15:59] <pitti> dholbach: sudo -u platform -i, then you can edit natty.cfg there
[15:59] <pitti> dholbach: (sorry, in meeting)
[15:59] <pitti> dholbach: lillypilly is people.c.c.
[15:59] <dholbach> aha, I was looking in ~pitti ;-)
[16:00] <tkamppeter> pitti, hi
[16:01] <tkamppeter> pitti, sorry for not having followed IRC.
[16:01] <tkamppeter> pitti, cupshelpers.getDevices(
[16:01] <pitti> hello tkamppeter, how are you? (no problem, it's not that urgent)
[16:01] <dholbach> thanks pitti
[16:01] <pitti> tkamppeter: I disabled cupshelpers from normal jockey operation for now, since printer drivers are almost always installed via s-c-p
[16:02] <tkamppeter> pitti, cupshelpers.getDevices() takes 15 seconds like "lpinfo -v" does as CUPS waits 15 sec for answers of network and Bluetooth printers.
[16:02] <pitti> tkamppeter: ah, that explains it
[16:03] <tkamppeter> 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] <pitti> tkamppeter: that's what I thought
[16:03] <pitti> tkamppeter: ok, thanks for confirming
[16:05] <tkamppeter> 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] <tkamppeter> 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] <pitti> right
[16:08] <doko_> kirkland: preprocessed source?
[16:20] <didrocks> 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] <pitti> didrocks: oh, nice
[16:20] <didrocks> also Quickly trunk now support installing in that prefix
[16:21] <didrocks> (and upgrade existing projects)
[16:31] <smoser> in a debian 3.0 quilt format, stored in bzr, should i store the bzr with the patches applied ?
[16:32] <smoser> i think the answer is yes
[16:33] <cjwatson> didrocks: we should be moving to dh_python2/dh_python3, though, right?
[16:33] <cjwatson> smoser: yes (IMO)
[16:33] <smoser> cjwatson, and store the .pc directory also ?
[16:34] <cjwatson> I don't, normally, although the importer does
[16:34] <cjwatson> it's an open question
[16:34] <didrocks> 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] <smoser> or were there fixes to that bug you had opened to have rules force-apply them.
[16:34] <cjwatson> I find it easier not to
[16:34] <cjwatson> 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] <cjwatson> but that's just my opinion
[16:35] <smoser> i prefer no .pc, so i'll go with that. and add a rule to force fix .pc.
[16:35] <smoser> thanks.
[16:35] <ogra_ac> 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
[17:47] <RoAkSoAx> 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] <kirkland> RoAkSoAx: hmm, i'm not too sure about that
[18:05] <kirkland> RoAkSoAx: maybe in a future iteration
[18:05] <kirkland> RoAkSoAx: lets focus on hardware hacks for now
[18:08] <RoAkSoAx> 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] <RoAkSoAx> from memory to disk
[18:11] <RoAkSoAx> kirkland: by reducing the dirty page writeback frequency
[18:53] <seb128> ev: could you review https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/661289 when you have time?
[20:04] <rsajdok> how to get access to send email to https://lists.ubuntu.com/archives/ubuntu-devel/ ?
[20:05] <micahg> rsajdok: anyone can send, but it's moderated for non-developers AFAIK
[20:10] <rsajdok> micahg: I sent email yesterday. It is not yet approved
[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] <seb128> lamont, invalid
[20:45] <lamont> seb128: thanks
[20:45] <seb128> the apt task was invalid at least, you can add a comment saying that
[20:45] <highvoltage> e/win 19
[20:46] <lamont> seb128: commented that it was actually an archive issue on old-releases, which I have now fixed.
[20:47] <seb128> lamont, ok, thanks
[20:47] <lamont> so amusingly,  while it's not a bug in ubuntu, it is my bug.
[20:47] <lamont> for sad values of 'amusingly'
[20:49] <smoser> cjwatson, is bug 581760 testable without a windows installation ?
[21:00] <geser> 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] <kees> geser: hmm... IIRC, it was supposed to go to the mailing list for further discussion?
[21:09] <jdstrand> wendar: fyi, I add PostReleaseApps/SecurityChecklist today
[21:10] <wendar> jdstrand: excellent, thanks! I'll read through it now
[21:11] <geser> kees: the TB mailing list?
[21:12] <kees> geser: yeah
[21:13] <geser> kees: I don't see anything in the archives for Oct and Nov
[21:13] <highvoltage> ddd/win 13
[21:13] <highvoltage> (bah)
[21:15] <kees> geser: yeah, best to bring it up on the list then.
[21:15] <wendar> jdstrand: also sending the link on to the ARB list, for all members to review
[21:15] <jdstrand> wendar: cool, thanks
[21:16] <geser> 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] <kees> okay
[21:17] <ajmitch> jdstrand: some of the social items in there will need more discussion, like the developer contract & $
[21:17] <jdstrand> ajmitch: oh absolutely
[21:18] <jdstrand> 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] <ajmitch> jdstrand: thanks for putting it together
[21:19] <jdstrand> ajmitch: sure np. I wrote it up, but everyone on the ubuntu-security contributed
[21:20] <jdstrand> the ubuntu-security *team* that is
[21:45] <wendar> jdstrand: the comments on socially encouraging good security behavior by preventing anonymous contributions are an important addition too, thanks!
[21:46] <wendar> 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] <wendar> 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] <jdstrand> wendar: regarding 'anonymous contributions'-- thank mdeslaur (but we all agree :)
[21:48] <jdstrand> 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] <jdstrand> wendar: but all the PPA business was that we don't want their software changing the upgrade system, etc
[21:49] <jdstrand> well, you probably ment that the PPA is one deterrent
[21:50] <jdstrand> 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] <jdstrand> /get/keep malicous software out/
[21:51] <jdstrand> mind you, *tend* :)
[21:51] <jdstrand> a really bad guy will find a way
[21:51] <wendar> jdstrand: aye, there's always a way, but we can prevent/discourage as much as possible
[21:52] <jdstrand> absolutely! (hence the checklist ;)
[21:52] <cjwatson> rsajdok: then it's in the queue - I'll look at it next time I'm at my laptop
[21:52] <cjwatson> smoser: no
[21:53] <wendar> jdstrand: and, on PPAs, yes, meant the fact that they have to set up account with valid email and sign the code of conduct, etc, etc, is a beginning of social pressure for good behavior
[21:54] <jdstrand> wendar: we discussed that and recognize it is the beginning, but that alone is a pretty low barrier in our opinion
[21:55] <wendar> wendar: agreed, it's possible to complete with entirely fake identity
[21:55] <jdstrand> wendar: anyhoo, it seems we are on the same page for that. certainly worht more discussion for more social pressure
[21:56] <wendar> jdstrand: very much so. will loop back with you once ARB has had a chance to discuss. thanks for putting it together!
[21:56] <jdstrand> sure! :)
[22:21] <lifeless> kees: ping
[22:22] <lifeless> pitti: ping
[22:22] <kees> lifeless: sup?
[22:22] <lifeless> please try your private files thing
[22:22] <lifeless> on launchpad production
[22:23] <kees> oh, is it live?
[22:23] <lifeless> just now
[22:23] <lifeless> evaluating whether we broke anything
[22:23] <kees> one moment...
[22:24] <kees> *drum roll*
[22:25] <kees> no 503!
[22:25] <kees> \o/
[22:25] <lifeless> kees: faster ?
[22:25] <kees> lifeless: looks great for the one smaller package we've got in a secppa
[22:26] <lifeless> \o/
[22:26] <kees> lifeless: dunno about actual transfer through-put, but yeah, when 5 out of every 6 downloads don't have to retry 3 times with a 10 second pause between each attempt, it's much faster ;)
[22:26] <lifeless> kees: awesome. Feel free to blog about lp awesomeness :)
[22:27] <lifeless> kees: though we may have to roll it back - dunno yet :)
[22:27] <kees> heh, d'oh
[22:29] <kees> lifeless: well, FWIW, this is the first time in maybe a year (or more?) where there have been no 503 retries. well done! :)
[22:29] <lifeless> rolling it back
[22:29] <lifeless> would break apport right now
[22:29] <lifeless> actually
[22:29] <lifeless> I think we can avoid this.
[22:30] <kees> oh? bummer.
[22:34] <lifeless> kees: keeping it live
[22:34] <lifeless> please let me know how it goes
[22:35] <ScottK> wendar: Having a PPA is not related to not being anonymous.
[22:36] <ScottK> The fact that there is a valid email address doesn't help that at all.
[22:46] <kirkland> kees: fyi, your dmesg change will break kvm-ok, at least until you get the changes checked in to check kvm in bios outside of dmesg ;-)
[23:07] <SpamapS> is anyone else overjoyed that we actually have v3 of mdadm in natty?
[23:18] <kees> kirkland: yeah, I've been making a list. I intend to replace kvm-ok and the nx test with proper MSR calls anyway.
[23:19] <ebroder> kees: Does that mean that I'll be able to detect if the BIOS disabled HW virt without loading the kvm modules? Because that would be awesome
[23:19] <kees> ebroder: yes, I think so. As I understand it, the kvm modules are just checking a specific MSR.
[23:20] <kees> ebroder: it'll look something like this: http://bazaar.launchpad.net/~cpu-checker-dev/cpu-checker/trunk/annotate/head%3A/check-nx
[23:20] <kees> except I'll be adjusting it to not do all that crazy stuff at the start and just expects to run as root with msr-tools installed.
[23:20] <ebroder> kees: Oh, I can do this now? Even better
[23:21] <kees> ebroder: yup, if you can find the MSR you need to read, it should be trivial. It just hasn't bubbled to the top of my TODO yet.
[23:21] <kees> ebroder: but if you do get it written, please share. I want to get it in there. :)
[23:21] <kees> (I also need to write an MIR for msr-tools)
[23:22] <ebroder> kees: Will do. Shouldn't be too hard - last time I looked at this I gave up when I found that the instruction the kernel used was privileged only. Hooking the bits together should be easy, though
[23:23] <kees> ebroder: well, that part isn't much different, only root can read the msr device.
[23:24] <ebroder> kees: That's fine. I can arrange to be root for my use case. I didn't want to arrange to be the kernel
[23:24] <kees> haha yeah
[23:24] <kees> well, while I'm waiting, now I want to go look
[23:24] <ebroder> rdmsrl(MSR_VM_CR, vm_cr); is one of the manufacturers
[23:24] <ebroder> That's AMD
[23:25] <ebroder> is_disabled in arch/x86/kvm/svm.c
[23:25] <ebroder> And vmx_disabled_by_bios in arch/x86/kvm/vmx.c
[23:26] <RoAkSoAx> kirkland: btw.. just saw you gonna work on cobbler. You might wanna take a look at: http://www.threedrunkensysadsonthe.net/2010/07/installing-cobbler-on-ubuntu
[23:30] <kees> MSR_IA32_FEATURE_CONTROL
[23:30] <ebroder> kees: I think rdmsr --bitfield 4:4 0xc0010114 will work for AMD
[23:30] <ebroder> Still working on understanding the logic for Intel, but it's various bits of 0x3a
[23:33] <RoAkSoAx> kirkland: seems unaccessible for now, but that guy branched cobbler and made changes that supposedly enabled it to work in Ubuntu
[23:34] <kirkland> RoAkSoAx: where at?
[23:34] <RoAkSoAx> kirkland: http://www.threedrunkensysadsonthe.net/2010/07/installing-cobbler-on-ubuntu (Seems unaccessible for me, for now)
[23:36] <RoAkSoAx> kirkland: I read it like couple weeks ago or so
[23:38] <kees> ebroder: when svm is disabled in the BIOS, does it still show up in /proc/cpuinfo?
[23:39] <ebroder> kees: Not sure
[23:39] <kees> kirkland: ?
[23:39] <ebroder> kees: vmx definitely does
[23:39] <kirkland> kees: huh?
[23:39] <kirkland> kees: oh, yes, it does
[23:39] <kees> ah, yeah, looking at kvm-ok, it does. okay
[23:40] <kirkland> kees: see the current logic in kvm-ok
[23:40] <kirkland> kees: that logic is correct
[23:40] <ebroder> kees: I take it you're writing the code at this point so I shouldn't?
[23:48] <kees> ebroder: I think I'm close. I just need hw to test with
[23:48] <kees> ebroder: I'll continue in a bit
[23:49] <ebroder> kees: I have Intel hw I can reboot repeatedly if that helps, although I don't think I can test any of the trusted boot stuff