[00:42] whats the easiest way to get what functions are called when performing an action in a program [00:42] say i open a new IM window in empathy, how do I find out what functions are called ? [00:43] bcurtiswx: You trace it back or forward from something that you know must have happened [00:44] penguin42, so keep strace open, wait for it to stop then perform the action? [00:44] bcurtiswx: So if it was a menu item that triggered it you'd look for the menu code and what ever registered the action for it; or you could go the other way, you could set a breakpoint at some function in gnome you know must have got called - e.g. whatever opens a new window [00:44] bcurtiswx: strace is too low level really [00:45] bcurtiswx: gdb and breakpoint on a function you expect to get called and then do a backtrace [00:45] OK [00:45] just 'break' in a c file ? [00:45] yeh === cmagina-afk is now known as cmagina === oubiwann is now known as oubiwann_ === _LibertyZero is now known as [DooF][HC]Libert === [DooF][HC]Libert is now known as LibertyZero [07:08] Good morning [07:08] good morning [07:08] Hey pitti. [07:09] hey TheMuso, how are you? [07:15] pitti: Well thanks, yourself? [07:23] TheMuso: pretty well, thanks! [07:27] good morning [07:44] good morning [07:46] salut didrocks [07:46] hey dholbach === tkamppeter_ is now known as tkamppeter === mthaddon` is now known as mthaddon === smb` is now known as smb [09:31] pitti: Hi, as you dealt with hal in the past, is disabling the v4l code the right fix for the current hal FTBFS? (http://launchpadlibrarian.net/63796245/buildlog_ubuntu-natty-i386.hal_0.5.14-5_FAILEDTOBUILD.txt.gz) [09:32] geser: I filed bug 716275; if that is easy to do, I'd prefer that [09:32] Launchpad bug 716275 in linux (Ubuntu) "Please ship /usr/include/linux/videodev.h" [Undecided,New] https://launchpad.net/bugs/716275 [09:33] geser: if not, I'd add a patch upstream to check if it is available and disable it in configure if not, and ask mbiebl to cherrypick it [09:33] ok [09:35] I've attached a debdiff for natty in LP bug #552404, is there anything else I need to do? The https://wiki.ubuntu.com/StableReleaseUpdates wiki page doesn't apply for development releases, right? [09:35] Launchpad bug 552404 in dbus (Ubuntu) "dbus fails to be configured in chroots" [Medium,Confirmed] https://launchpad.net/bugs/552404 [09:37] So I can just re-subscribe ubuntu-sponsors? [09:39] alkisg, Yes. The sponsor will upload, and then the SRU process will resume. Do you need something for maverick as well? [09:39] persia: yes, but I don't have a maverick installation available for testing [09:39] My understanding of lucid SRU is that there is an expectation of fix in natty and maverick first. [09:40] alkisg, It's a chroot bug, right? Do you have disk space to create a maverick chroot? [09:41] pitti: /usr/include/linux/videodev.h is the header for the V4L API, which is entirely removed in 2.6.38 - we don't want to ship a header for code that can't work on Natty, do we? [09:42] persia: I guess I could ask someone over in #ltsp to try it in maverick, to save me the time of creating a maverick chroot, since I won't ever be using maverick... [09:42] alkisg, I've requested nomination for each release, which should make it easier to follow the correct status of SRU. Needs someone to approve the nominations, but the sponsor will probably do that as well. [09:42] Thank you :) [09:42] RAOF: ah, ok, good to know [09:43] alkisg, Good luck! [09:43] RAOF: I'll patch hal upstream then [09:43] pitti: The correct response is to port to V4L2 or, at a pinch, just disable V4L support. [09:43] Given hal's tremendous utility, I'd guess disabling V4L support is the winning move :) [09:44] Are there no devices that have V4L support, but not V4L2 support? [09:44] persia: Not anymore, no. [09:44] RAOF: absolutely [09:44] Cool! [09:44] Well, not with 2.6.38, at least, because it doesn't support V4L at all :) [09:45] heh. [09:45] So there might now be some *unsupported* devices, but I don't know of any offhand. [10:28] geser: ok, fixed upstream; I'll talk to Michael now [10:33] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: ev [10:34] * dholbach hugs ev [10:34] :-D [10:34] google calendar ftw [10:38] cjwatson, have you heard of any plymouth not working issues recently? for example: bug #718044 [10:38] Launchpad bug 718044 in plymouth (Ubuntu) "[Natty] New plymouth does not get loaded" [Undecided,Confirmed] https://launchpad.net/bugs/718044 [10:46] apw: nothing new [10:46] apw: the last several updates to plymouth weren't mine, though [10:48] apw: ask soren [10:48] cjwatson, will do thanks [10:50] whuh? [10:50] Oh, crap. [10:50] soren, there is a bug about the latest plymouth affecting some people [10:51] actaully ubuntu15 and up [10:51] cjwatson, is see in MoM that adduser need to merge, but an changelog says only undating translations. is aduser will be merge this time? [10:51] ubuntu15 was bit of a bust, but ubuntu16 should be fine. [10:51] Darn it. [10:51] I'm on it. [10:51] geser: pushed fix to Debian's hal svn; will wait for Michael to review/upload, though [10:52] udienz: we're after Debian import freeze, so merges are not a priority. Is there a particular reason why we should pay attention to this merge? [10:52] soren, there seems to be be little in the way of changes from the ubuntu14 which was claimed as working ... odd [10:52] udienz: the big merge push is in the first half of the release cycle, i.e. not now [10:53] cjwatson: ah ok. i think is not, because only updating translation from debian. [10:53] Ah [10:54] udienz: so just leave it, it'll happen in natty+1 [10:55] cjwatson: I've just seen util-linux gained armhf support in Debian and decided to merge it; in the merge, I ended up removing a lot of delta that I think we don't need anymore; do you mind these changes at this point? Maybe it would be best if these got peer reviewed, I've pushed them as UNRELEASED to the UDD branch [10:55] armhf support would be trivial to add on top of the Ubuntu package, but heck, I've merged it now :-) [10:55] lool: what sort of things? [10:56] cjwatson: upgrade snippets mostly [10:56] from pre-lucid? [10:56] or diff which didn't add any value to us [10:56] cjwatson: yes [10:56] I don't really care if we drop pre-lucid upgrade stuff [10:56] http://paste.ubuntu.com/566915/ [10:57] the stuff listed on https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/util-linux/natty seems generally fine [10:57] cjwatson: I usually review the full debian -> ubuntu diff when documenting remaining changes; the longer it is, the more painful for me [10:58] that's usually why I remove this stuff when I can, or to make maintainer scripts more readable [10:58] sure [10:58] apw: Yeah. /me investigates [10:59] cjwatson: Ok; will give it some testing now, and upload; thanks [10:59] soren, the linked internally bug for the kernel seems to be reporting grub2 showing corrupted display ... so there may be a grub2 connection in part [10:59] none of that has changed recently [11:00] cjwatson, yeah, the description is very hard to understand, i have requested much clarification on the linux bug [11:00] certainly not as recently as the plymouth changes mentioned [11:11] ev: Hi Evan, do you have time to sponsor a couple of MPs? Both are linked to from https://launchpad.net/bugs/666565 [11:11] Ubuntu bug 666565 in language-selector (Ubuntu) ""utf8" charmap in locale name is wrong" [Undecided,In progress] [11:12] GunnarHj: I'll have a look [11:13] ev: Great! [11:20] hi all [11:20] what's the relationship between Ubuntu and Linaro? [11:20] (ubuntu-mobile is closed and said to ask here) [11:21] sivang: Complex :) [11:21] persia: complex? [11:21] persia: it is for armel yes? [11:21] So, a number of folks involved in Linaro are also involved in Ubuntu. [11:21] does it use apt? [11:22] Linaro has some goals (see www.linaro.org), and tries to accomplish them within Ubuntu, releasing things based on Ubuntu. [11:22] So, from an Ubuntu perspective, Linaro just happens to be another project some folk are involved in. [11:22] From a Linaro perspective (I'm guessing), Ubuntu is distribution project that is one of the targets for their efforts. [11:23] Ubuntu supports armel, and tends to select the Linaro branches of tools to do so, because those tend to have the best performance on armel. [11:23] But I don't believe there exists any single interface, or anything, which is why I say "complex". [11:24] so when I do linaro stuff I work .deb and can use ubuntun repos? [11:25] Also, that's *completely* unrelated to ubuntu-mobile. ubuntu-mobile was part of an effort to make Ubuntu better for highly mobile and embedded uses. The consensus seemed to be that as the devices got better, it was more interesting to just deliver normal Ubuntu, than to try to make a special software stack. [11:25] You'd do better to ask the linaro folk, but I believe so. [11:26] apw: I think it [11:26] s all me, actually. [11:26] apw: I don't understand why at all, though. [11:28] apw: the avoid-sigpipe patch causes it. [11:28] apw: If I revert that, it works again [11:28] persia: thanks, makes sense. === MacSlow is now known as MacSlow|lunch [11:29] apw: It just don't understand. write(a,b,c) ought to be the same as send(a,b,c,0), but even that substitution causes it to fail. [11:35] soren: is 'a' a socket fd? [11:37] cjwatson: Let's pretend the answer is "no". [11:37] cjwatson: Just for giggles, let's say it's a pipe. [11:37] you can only use send() on sockets [11:38] Ah. [11:38] man send(2) is rather misleading, then. [11:38] Darn it. [11:38] depends how you look at it [11:39] it does start "send a message on a socket" [11:39] cjwatson: Is there any way I can get write() call to not SIGPIPE if the remote end of a pipe is closed? [11:39] I think "The only difference between send() and write(2)" is intended to be read as "(for sockets)" [11:39] cjwatson: I thought changing it to send and passing MSG_NOSIGNAL would do the trick. [11:40] And certainly it did in my tests, but they were using actual sockets :-/ [11:42] I'm surprised it isn't a socket, actually. ply_boot_client_connect calls ply_connect_to_unix_socket [11:42] Alternatively, some way to reliably determine if an fd is a socket. [11:42] I'm sure it is. [11:43] It's probably just that other things are using the same routine with non-sockets. [11:43] ah [11:43] ...which I hadn't expected, tbh. [11:43] yes, src/client/plymouth.c calls ply_open_unidirectional_pipe [11:43] and there are a couple of other calls [11:45] you probably get EBADF from send - you could just check for that and fall back to write [11:45] that would be OK [11:45] actually, you get ENOTSOCK [11:45] which is pretty clear [11:46] Heh. [11:47] cjwatson: Yeah, that's a good idea. I'll try that. [11:56] cjwatson: So if this were a pipe, the only way to avoid being SIGPIPE'd is to flush the fd first and see if it's closed? [11:57] * soren reboots to check this new patch [11:59] That seems to have done the trick. [11:59] soren: I guess so (or to ignore SIGPIPE, of course). The pipe uses are all internal to plymouth though, so I don't think we need to worry about that [12:00] cjwatson: Sure, I was just thinkin more gnerally. [12:06] geser, DMB meeting? === amitk is now known as amitk-afk [12:21] Hello [12:22] I'm working on packaging my app to deb packages [12:22] but have no idea how to create menu entry after install [12:23] could anybody send me link to the how to? I'm not so successful with google [12:23] thank you [12:23] PetrHH: Look at the .desktop files in /usr/share/applications [12:25] soren, Thank you! === oubiwann_ is now known as oubiwann [12:40] apw: Plymouth fix uploaded. Thanks for pointing it out. I've been watching the new bugs for plymouth, but it looks this this was filed as "confirmed" from the start. === amitk-afk is now known as amitk [12:44] cjwatson: Thanks for your help on that, by the way. [12:45] np [12:52] soren, Where should I put application icon, please? I've found a lot of directories where e.g. f-spot.png icon is. [12:52] I'm not entirely sure where it truly belongs. [12:53] * soren isn't a desktop person, really. === MacSlow|lunch is now known as MacSlow [13:23] PetrHH: apps usually ship their "canonical" icons in /usr/share/icons/hicolor/ [13:25] slangasek: kirkland: so, where did we decide qemu-kvm-ppc64 belongs? qemu-kvm, or qemu-user? [13:26] * hallyn objects to 'apt-get instlal tree' apparently having done an implicit 'apt-get dist-upgrade' [13:27] apt-get install never does an implicit dist-upgrade, but it may be necessary to upgrade other packages to fulfil dependencies. [13:27] I don't see why it would have done so for tree though. [13:28] cjwatson: it even updated my firefox [13:28] [13:31] i dunno, this thing's package mgr must still be ina funky state. it also refuses to install 2.6.38. i may just need to reinstall [13:33] hallyn: it might have attempted to continue a previously incomplete upgrade [13:33] 'apt-get -f install' might be a good idea [13:35] cjwatson: no, that didn't (and doesn't) seem to say anything other than about autoremove packages [13:36] guess I'll try another rm -rf /var/cache/apt* and retry without apt-cacher again [13:38] hallyn: qemu-kvm, as i recall [13:38] mvo, ping [13:39] mvo, do you have 3 minutes for a short brainstorm about dpkg? [13:39] kirkland: that's what I had thought. [13:40] kirkland: so should we reclasssify bug 717690 as against qemu-user ? [13:40] Launchpad bug 717690 in qemu-kvm (Ubuntu) "package qemu-kvm 0.13.0+noroms-0ubuntu12 [modified: usr/share/man/man1/qemu-user.1.gz] failed to install/upgrade: trying to overwrite '/usr/bin/qemu-ppc64', which is also in package qemu-user 0.13.50-2011.02-0-0ubuntu1" [Low,Confirmed] https://launchpad.net/bugs/717690 [13:45] kirkland: hm, so all of the arm-* patches should be removed from qemu-user, right? [13:45] \o/ [13:47] debfx: note that we already have python-gudev in the archive, which just like pyudev is obsolete [13:47] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: ev, zul [13:48] hallyn: should be fix released now [13:48] debfx: ah, sorry, it's libudev bindings, not libgudev; for the latter we have a GIR now [13:48] hallyn: my last upload fixes that [13:48] debfx: ok, so ignore me :) [13:48] hallyn: yes, all of the arm patches can go [13:48] kirkland: you re-uploaded qemu-user? [13:48] hallyn: no [13:48] hallyn: qemu-kvm [13:49] hallyn: we dropped that manpage from qemu-kvm (slangasek's patch) [13:49] so you removed qemu-ppc64 from qemu-kvm? [13:49] oh, it's the manpage! [13:49] doh [13:50] kirkland: at this particular moment, I'm down to two patches in qemu-kvm-0.14.0~rc1+noroms :) === warp10- is now known as warp10 [13:50] hallyn: rock [13:50] No doko? [13:50] kirkland: shoudl '~rc1' be in the name like that, btw? === dendro-afk is now known as dendrobates [13:53] Maybe someone else can help me out. [13:54] I thought he'd be back today (doko) [13:56] ScottK: You might be able to help me with this, actually. [13:56] Once upon a time, python-eventlet was built: https://edge.launchpad.net/ubuntu/+source/python-eventlet/0.9.13-0ubuntu1/+buildjob/2031930 [13:57] OK [13:57] The build log from amd64 shows that the .deb ended up containing a bunch of things in /usr/lib/python2.7/dist-packages/eventlet/ [13:57] in addition to the expected stuff in /usr/share/pyshared/eventlet/ === oubiwann is now known as oubiwann_ [13:58] I just built a newer version earlier today that didn't end up with stuff in /usr/lib/python2.7/dist-packages/eventlet/ [13:58] ..this makes upgrades suck because there are leftover .pyc files in /usr/lib/python2.7/dist-packages/eventlet/. [13:58] Where's the newer version? [13:59] https://edge.launchpad.net/ubuntu/+source/python-eventlet/0.9.14-0ubuntu1/+buildjob/2261008 [13:59] I tried rebuilding the old source package, and this time I didn't get anything in in /usr/lib/python2.7/dist-packages/eventlet/ so it looks like there was a toolchain problem at some point. [13:59] ...and I can't imagine I'm the only one having to deal with this fallout on upgrades. [14:00] soren, seems similar to the pywebkitgtk recent issues [14:01] soren, see the current upload of that one, the changelog has some details [14:02] seb128: The one from about two weeks ago? [14:02] Yeah, changelog entry sounds similar. Thanks. [14:02] soren, yes [14:02] soren, I think that was due to package rebuilt in natty when part of the python... didn't support 2.7 yet [14:03] soren: I agree it was a problem with the 0.9.13 upload's toolchain. [14:03] soren, was the "buggy" version uploaded around the time python2.7 landed? [14:03] Looks like it was. [14:04] soren, it's likely to be a similar issue, rebuilt at a time python2.7 was pulled it but part of the buildchain was not ready [14:04] 2010-10-31 17:05:06 CET [14:04] There was also a period where 2.7 was a supported version, but not all the helper tools had been updated to know about it yet. [14:04] ScottK: Now that sounds like trouble. [14:04] Uh, wrong timestamp. [14:05] soren, well, just add some code to clean it up on upgrade [14:05] Yeah. [14:05] we should likely check what packages got rebuilt around this time [14:05] it's 2 of those which are spotted as broken now [14:05] we might have some other ones [14:14] soren: I think seb128's suggestion is the right way. [14:16] soren: Alternatively, I think switching to dh_python2 would also fix this as, IIRC, that's where it puts it's .pyc files. [14:25] ScottK: I'll deal with dh_python2 some other day. :) [14:25] ScottK, seb128: Thanks, guys! [14:25] OK. [14:26] barry: ^^^ It would probably be a good idea for someone to do a methodical search for other misbuilt packages. [14:44] ScottK: misbuild in what way? I may be able to help here (got a VM image with maverick->natty upgraded *python*) [14:45] mvo: As soren and seb128 were discussing it looks like late Octoberish pysupport was installing files for python2.7 in the wrong place. === diwic is now known as diwic_afk === diwic_afk is now known as diwic [14:47] * mvo reads scrollback === jelmer_ is now known as jelmer [14:52] * barry reads scrollback too === cking is now known as cking-afk === herton is now known as herton_lunch [15:17] zul: Thanks once again for sponsoring :) [15:17] jelmer: no worries [15:20] pitti: hey, are you still around? [15:20] hi kirkland [15:21] pitti: i'm hoping there's an obvious fix for this ... [15:21] pitti: been broken for me for 1 month now; been hoping a magic update would just fix it [15:21] pitti: i can't alt-tab to switch windows, resize windows, move windows, etc. [15:21] pitti: this is natty gnome [15:22] pitti: perhaps i'm missing a package? or some configuration from day1 natty is not compatible with today? [15:22] kirkland: hm, that doesn't happen for me; seb128, didrocks, did you ever hear about alt+tab/resizing/moving windows being broken in natty? [15:23] kirkland: does it happen for a new user, too? [15:23] kirkland: that's usually the first litmus test whether it's package or config related [15:23] didn't read anything about that [15:23] I didn't see that either [15:23] kirkland, is that under unity or classic GNOME? [15:23] try to unity --reset maybe [15:23] kirkland: ok, so try with new user first, then let's bisect it todwn [15:23] down [15:24] seb128: "classic gnome" [15:24] pitti: that sounds like the start of a nercore rap :) [15:24] *nerdcore [15:24] pitti: not really about that, alt + tab can be very slow [15:25] kirkland: I got once a problem with alt-tab in unity too, I had to re-add the key shortcut as it was gone [15:25] pitti: okay, i'll create a new user [15:25] seb128: classic gnome [15:25] kirkland: normally, I tried to migrate uncompatible settings, but yeah, --reset is always better :) [15:25] kirkland, try a guest session to start I guess [15:25] didrocks, is there a compiz --reset? [15:26] guest session would start unity, though [15:26] seb128: not for that, unfortunately… [15:26] guest session should start the session your are in [15:26] you* [15:26] pitti, what didrocks said [15:26] didrocks: oh? clever [15:26] so, classic if you are in gnome-classic, unity if you are in ubuntu desktop… and so on :) [15:27] weird, unity was not installed [15:27] i did not uninstall it [15:27] pitti: I fixed it for alpha1, but didn't retest for alpha2 [15:28] so, in any case, it's in my checking TODO as it's often broken by inadvertance [15:28] didrocks, what? [15:28] seb128: the "start the corresponding guest session" === diwic is now known as diwic_afk [15:28] didrocks, that works, at least it starts the classic session for me [15:29] seb128: ok nice, not broken again yet :) [15:29] didrocks: seb128: pitti: okay, i installed unity, and then ran unity --reset and I can now move windows and resize them again! [15:29] i still can't alt-tab, though [15:29] kirkland: that's progress! [15:29] curious, though, as unity shouldn't be involved in classic gnome [15:30] kirkland: try to hang the alt + tab for few seconds [15:30] ok, need to finish early today, sorry [15:30] kirkland: I'll read backscroll [15:30] pitti, well, unity --reset starts compiz with a fresh profile [15:30] ah [15:30] so, compiz bug [15:30] kirkland: there is a performance issue with it, so maybe [15:30] jinkeys - requestsync failed with 'too many concurrent connections' to mx.launchpad.net:25 [15:30] didrocks: nope ... if I'm in the terminal, I get "^[ " in my window [15:30] pitti, "bug" or "config issue" [15:30] kirkland: staticswitcher in enabled in ccsm? [15:31] (it should as you just reset the value) [15:31] didrocks: what is ccsm? [15:31] kirkland: did you allow the latin keyboard thingie to misconfigure with alt perhaps? [15:31] hallyn: oh [15:31] kirkland: compizconfig-setting-manager, a way to change everything in compiz and break it :) [15:31] hallyn: maybe so [15:31] didrocks: not installed, installing now [15:31] kirkland: compizconfig-settings-manager and then, just launch "ccsm" [15:32] kirkland: you should ensure that the staticswitcher plugin is activated [15:32] didrocks: was not emabled [15:32] hum… [15:32] /!\ activating/deactivating plugin make compiz crash now [15:33] didrocks: got it, that works now [15:33] didrocks: seb128: pitti: thanks so much! [15:34] kirkland: that's really weird, unity.ini, debian/rules for autogeneration list, and the compiz gconf default are setting it… [15:34] kirkland: but well, nice that fixed it for you, I'll try again with a new user :) [15:34] didrocks: seb128: pitti: because of this, i have spent most of the last 4 weeks in tty1, with byobu+w3m+ irssi+mutt :-) [15:34] (which is actually pretty nice :-) [15:34] kirkland, don't hesitate to ask early when you have a such issue [15:35] kirkland: well, that's just a way for you to enjoy byobu a little more :) [15:35] seb128: thanks, will do [15:36] bdrung: ^5 (on ubuntu-sponsoring) === herton_lunch is now known as herton [15:39] bdrung, tumbleweed: are you both looking into the unicode problem right now? [15:39] I just wanted to take the dog for a walk real quick - I can review whatever you have when I'm back [15:40] it'd be nice to get the issue resolved :) [15:40] dholbach: at least I am :) [15:40] thanks muchly [15:40] I'll let you know when I'm back [15:46] dholbach: i am cooking [15:47] hey zyga - you pinged me earlier? [15:47] mvo, yes [15:48] mvo, I had this crazy idea of being able to install packages without invoking any scripts, then gathering the required scripts and executing them in sequence during first boot, I was wondering what kind of caveats would you think of in such design [15:48] barry: mind if I upload some rebuilds for python2.7 ? looks like python-oss is a candidate for this, probably more [15:51] zyga: you need to consider that pre-depends requires a package to be installed and configured, so you can only delay those with "regular" dependencies. then you need to run the configure scripts on bootup in the right order (well, dpkg --configure -a should actually handle this for you). and there is the issue that your daemon will not get restarted, so e.g. on security updates of libfoo the old copy keeps running [16:00] mvo, re, sorry about being missing [16:00] mvo, this about building system images "dry", without running the target system (pc->arm) [16:01] mvo, so issues such as running system are not important here [16:01] mvo, in fact we have a slightly easier work to perform, currently linaro has a tarball with the root fs created using lexbuilder/offspring with the regular method (which AFAIR depends on qemu faiking the target system) [16:02] mvo, then when you want to create a bootable media for your device you need to combine this filesystem with a "hardware pack" which is a tarball with extra packages and repository for anything that they might depend on [16:02] mvo, currently the procedure is somewhat complex because we need to install those hardware pack packages in the image we're building, I wanted to simplify that [16:03] mvo, up to a point that the whole procedure would not depend on anything apart from simple file manipulation tools === beuno is now known as beuno-lunch [16:17] GunnarHj: merged both branches and uploaded; great work on these! [16:30] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: zul [16:31] hum [16:31] is launchpad or launchpadlib known to be broken? [16:31] the retracers crash on "NotImplementedError: Can't look up definition in another url (https://api.launchpad.net/1.0/#distributions)" [16:32] seb128: leonardr is talking about this in #launchpad with apw. [16:33] seb128, login_*(name, service_root=EDGE_SERVICE_ROOT) needs to change EDGE_SERVICE_ROOT to "production" [16:35] james_w: thanks [16:35] james_w, so login_*(name, service_root="production") ?? [16:35] apw, yeah [16:35] if you are on a really old version of launchpadlib that will crash, let me know if so [16:36] james_w, how come they didn't keep it working for compatibility purpose? [16:36] it's breaking retracers and sponsoring queue and versions and... [16:36] like is there any need to force us to do review and fix everything now by breaking it? [16:37] seb128, they wanted to reassign the edge machines to the production, and a redirect broke some other things [16:38] seb128, I disagree with the way they have gone about it [16:38] james_w, ok, thanks [16:40] i am writing a package for my company that supplies the debconf values for ldap-auth-config (so that we can install this package to config a machine to use the company ldap for authentication) what's the best channel to get help for that? [16:42] in fairness the edge decommissioning was announced several months ago [16:44] seb128: apport trunk already uses production, so the natty chroot should be okay, and the crash-digger merely needs a bzr pull [16:44] seb128: the only problem is the maverick chroot, we'd need either an SRU or a backport of apport in my PPA; I'll handle that one tomorrow [16:45] dholbach, tumbleweed: merged [16:45] seb128: ok, branches updated and locks removed; let's see how it goes [16:45] pitti, thanks [16:46] seb128: ah, need to refresh the LP cookie, doing.. [16:51] seb128: did it crash right away? it's currently consolidating the dup db, but that already means lots of LP access [16:51] pitti, yes [16:52] ok, cool [16:52] pitti, thanks for the quick fixing [16:53] pitti: do you understand the relationship between udev and usb_modeswitch? i'm playing around with a new modem, which i'm pretty sure needs to be mode-switched. it was not originally listed in /lib/udev/rules.d/40-..., so i stuck an entry in there. yet, when i plug it in, i don't really see udev calling the proper script [16:53] udevadm monitor isn't really showing me anything interesting (or i don't know what i should be looking for) [16:54] achiang: I'm just logging out, can you please mail me? [16:54] pitti: ok, sure [16:54] cheers [16:54] thanks [16:55] hallyn: I thought the conclusion was that qemu*ppc64 rather belonged in /qemu-linaro/; is that not the plan? [16:57] kirkland: ^ [16:58] slangasek: that hadn't been what i remembered, and i *think* not what kirkland took away from it either, but waiting for him to confirm [16:58] slangasek: i thought we were putting any and all kvm-accelerated stuff in qemu-kvm [16:58] slangasek: where ppc64 is (or will very soon be) kvm-accelerated [17:03] bdrung, pulled [17:05] kirkland: well, we said that, yes... we also earlier discussed that powerpc support would be going directly against qemu upstream so it might be just as good to package it via qemu-linaro [17:05] kirkland: I guess I don't mind either way, but at this point you're missing a Replaces :) === deryck is now known as deryck[lunch] [17:09] seb128: re 717358: what does that have to do with this goofy menu bar? [17:10] bug #717358 [17:10] Launchpad bug 717358 in nautilus (Ubuntu) "nautilus puts a menu bar at the top of the desktop" [Low,Incomplete] https://launchpad.net/bugs/717358 [17:10] kees, I guess I didn't understand the issue, it seemed like you have the default config with a gnome-panel at the top of the screen and indicator-appmenu [17:11] nope. I have no panel on the top. [17:11] you can see in the screenshot that it's a menu bar [17:11] kees, well that could have been the indicator-appmenu applet on a panel weirdly themed as well [17:11] and if I select "Help / About" it says nautilus [17:11] slangasek: hrm, okay; please commit the Replaces that we need against lp:ubuntu/qemu-kvm [17:12] right, the default appmenu if you have nothing focussed is the nautilus one [17:12] I'm using classic desktop. [17:12] kees, do you have a dual screen config? [17:12] nope [17:12] slangasek: the ppc64 patches will be against HEAD, but we're shipping qemu-kvm-0.14 in 11.04, so we're not far off [17:12] kees, well, indicator-appmenu is in the default classic desktop applet list in natty [17:13] none of my other menu bar end up there (thank goodness). [17:13] slangasek: also, it's the server team doing the work and testing against ppc64/kvm, so i think it'll be better for us to work against qemu-kvm (ours) rather than stepping on qemu-linaro (yours) [17:13]