=== superm1 is now known as superm1|away === quadrispro is now known as alessio === alessio is now known as Alessio === Alessio is now known as `Alessio` === `Alessio` is now known as quadrispro [02:16] * pochu waves good night [03:17] ember: ping? [03:22] ember: please deal with https://bugs.edge.launchpad.net/ubuntu/+source/meta-gnome2/+bug/273015 - you should not be requesting syncs, when the synced packages do not install. Thankyou. [03:22] Launchpad bug 273015 in meta-gnome2 "cannot install gnome & gnome-office packages" [High,Confirmed] [03:24] * Hobbsee advises that we're in a beta freeze, and should really not be having these sorts of errors this close to release. These are simple errors, guys! [03:33] pochu: please don't sponsor sync requests, when the resulting packages do not build. [03:33] sorry, install. [03:33] or build. either way. [03:34] (seeing as it appears to be you) === macd_ is now known as macd === superm1|away is now known as superm1 [03:54] Hobbsee: thanks for the head up, i'm taking care of it [03:55] ember: cool [03:55] ember: how *did* you test install that? [03:56] Hobbsee: i did a manual install of the package, but mostly on a base system we only have gnome-core or gnome-devel [03:56] so gnome-desktop-environment ended up not beeing upgrade [03:56] ember: and gnome-office? [03:57] same as desktop-env, upgraded gnome-core gnome-devel and desktop-data [03:58] ember: how does that work? it had a dependancy on a package that doesn't exist here. [03:59] i really don't understand, ive ended up filling&fixing at bug #273387 [03:59] Launchpad bug 273387 in meta-gnome2 "meta-gnome2 have unmet deps" [Undecided,New] https://launchpad.net/bugs/273387 [04:02] ember: that won't install all the metapackages in meta-gnome2. [04:02] ember: try installing them all in a clean chroot. Not an upgrade. [04:02] Hobbsee: i will try that, thanks [04:03] ember: that's how you should be testing *all* packages. [04:03] not just upgrades. [04:03] ember: pbuilder will do a lot of this for you, if you didn't know. I'm sending a mail about it soon. [04:05] i usually test install&upgrades on a vm or on a my lap [06:25] G'morning. [07:35] morning [07:35] jdong: so you mean green light for vlc 0.9.3? did you verify that it is really a bugfix only release? [08:11] persia, i've been poking back and forth with bluez 4.x this evening, and should have a mostly functional solution on the ~bluetooth PPA at this point (including working keyboard support :)) [08:12] superm1: Excellent. Bits of documentaiton of your effort had completely destroyed my motivation to document the freeze exception issues for 0.28, and I'm glad the results are ready for testing so soon. [08:13] persia, there is one point i haven't added to the bug yet (since i believe it is still solvable). [08:13] it appears that obex might need obexd rather than obex-data-server [08:13] but i haven't verified that yet [08:13] otherwise this solution appears to work significantly better [08:13] Better is good :) [08:14] I'll check the UI in hildon in KVM in a few minutes, and get you an opinion on how badly it looks. [08:15] i expect the main thing is that the new wizard is too tall, but i dont know that's for sure [08:16] How tall? I don't have anything with Ubuntu with less than 600 vertical pixels, but I know some people are fiddling with things as low as 640x480. [08:16] its really hard to gauge how tall it really is. i'm operating on a 1920x1080 16" screen, so i'm not really sure [08:17] heh [08:18] One of my wishlists for the SDL kvm front-end is to have it take arguments to force a given resolution. I know I can do this with VNC, but then I have to organise a VNC server, etc. [08:24] * siretart ponders if he should upload vlc 0.9.3 to ~motumedia or interpid. opinions? [08:27] I'd say intrepid. Changing between beta and release seems more risky than changing pre-beta, unless you expect significant regression. [08:27] From traffic I saw from j-b, it looked like mostly just bugfix work from responses to the 0.9.2 release. [08:28] yeah. I was worried about beta freeze [08:28] but its multiverse anyway, okay [08:30] Well, sure, you'll need to have a release manager approve the upload, but it's unlikely to affect much of anyone. Just make sure to time the builds to not break superm1's images. [08:31] well in theory all binaries would clear at the same time, so hopefully shouldn't be too much of a cause for breakage [08:33] superm1: Hrm? I thought that binaries cleared as they built. Is this not the case? I've often seen arch: any / arch: all skew on amd64. [08:33] ah that's right, amd64 [08:34] so yeah there could be cause for cd breakage - but i wouldnt say its that big a deal - we can just generate again if one gets times poorly [08:35] superm1: And I presume I want to unblacklist btusb for testing from the PPA, right? [08:35] persia, yeah [08:35] i did all my testing using btusb [08:36] persia, rtg will be pulling in some suspend related quirks when we rebase to rc8, so btusb should be fairly stable at that point [08:36] Great. bluez has a missing conflicts: on bluez-network [08:37] yeah that.... [08:37] i forgot those were added in for intrepid [08:37] And bluez-input ... [08:37] i talked to upstream today and they didnt want it done that way [08:37] i'll put the conflicts in then [08:38] Great. I'm discovering them one-by-one when trying to upgrade. [08:38] Upstream wants it as done for the candidate? [08:38] well they'd like to see the packaging similar to how it is in F10 [08:38] so i renamed and put files how i saw them in the spec file [08:39] probably also saw one on bluez-serial i imagine? [08:39] superm1: And ignoring what Debian are doing with Bluetooth? [08:39] Yep. [08:39] superm1: That's going to suck when Jaunty opens [08:39] StevenK, the debian guy is in #bluez, but wasn't around atm [08:39] StevenK: Debian hasn't looked at 4.x yet. [08:40] given he hangs out in #bluez, i'm thinking he'd listen to upstream's recommendations too for this [08:43] superm1: I'm hoping we aren't trying for BlueZ 4.x in Intrepid? :-) [08:43] StevenK, well considering it - keyboard pairing appears to be broken in 3.x right now [08:43] StevenK: That's exactly what's being testing. There is a significant regression with the current stack: keyboards don't work. [08:44] Hmmm [08:47] superm1: Well, the pairing wizard works at 600 vertical pixels, but I still can't type. [08:47] persia, give it a sec, it took a moment for it to get connected on mine [08:48] OK. Any suggestions on a reasonable waiting time? It's been a couple minutes. [08:48] oh, seconds for me [08:48] it wasn't close to minutes at all [08:49] then that's not good :( [08:49] Yeah. I even set it to "trusted" in the preferences panel. [08:49] i have a second BT keyboard here, let me grab that for another data point [08:49] Ah. Found it. I needed to set the "Other Devices can Connect" preference. I can type now. [08:50] oh good [08:50] so perhaps setting that default in the packaging if possible would be a good idea [08:50] OK. Now to reboot and try under hildon at 600 vertical pixels. [08:50] Yeah. Don't set visible by default, but set connectable by default. [08:52] persia, did you get bluez-gnome 1.4 or 1.5 installed? I'm not sure at what point the publisher did 1.5 [08:52] (so as to see if it was a problem only in 1.4) [08:52] * persia checks [08:55] oh actually i just reproduced that in 1.5 myself too by clearing /var/lib/bluetooth [08:55] it looks like you get a config file /var/lib/bluetooth/[mac]/config that controls it's behavior [08:55] and it's made when you choose a mode of operation [08:55] I seem to have gotten 1.4. [08:56] Right, and if you don't choose a mode of operation, it doesn't work out of the box, which is probably not what we want. === Hew__ is now known as Hew [09:18] superm1: Without the hildonisation patches it looks *very* cramped in hildon at 600 pixels. [09:18] persia, could you adapt the hildonisation patches for 4.x? [09:18] Erm. Not in a reasonable amount of time. [09:19] it looks cramped, but that's just the preference tab that looks cramped? [09:19] or the wizard? [09:20] The preferences tab. The wizard looks OK, but there's not much content. [09:20] On the other hand, it works, which is kinda nice given the keyboards some some of my laptops. [09:21] I'm just reviewing the 0.27 interface now to see how much worse 1.5 looks. [09:21] and in all honestly with the wizard there, you won't be spending much time in the preferences tab anyhow [09:21] assuming there's a doable way to patch or script the pre-selection of connectable [09:22] It's the "bonded devices" list that is the main difference. With the hildonisation patch, that moves to the right under hildon, so it can show more than one at a time. [09:22] Yeah. The Connectable-by-default thing needs hinting, as a naive user (like me) won't look at the Preferences before trying to pair a device. [09:23] * persia looks at the hildonisation patch to understand how much code would need to change [09:25] That's not much code, but it's UI fiddling, which always confuses me. [09:28] did anyone miss a52 and faad support in ubuntu's ffmpeg and wants to test some packages for that? [09:29] superm1: It might not be so bad after all. Much of the code looks mostly the same. I'll fiddle a bit, and let you know if it's quickly portable. [09:29] * siretart is also considering a patch for amr support provided by altlinux... [09:29] persia, okay sounds good. i'll keep trying to find a way to get this to start up discoverable, and then tomorrow see about the obex stuff [09:30] persia, it'd be worthwhile to add your keyboard data point to the bug at least though [09:30] superm1: OK. Are you sure this is easier than trying to fix keyboard support in 3.x? [09:31] persia, well given how much delta there is from the latest 4.x to 3.36, i'm thinking it is [09:31] but i'm not positive [09:32] especially since the code changed API's so drastically [09:32] superm1: OK. It just seems you're the only person with both a bluetooth keyboard and sufficient knowledge to hack this stuff. Most of the people with whom I've chatted have not had keyboards or couldn't hack. [09:32] Ah, you think the massive API change is sufficiently reflected in the kernel that we'd have to revert lots of stuff there to make it work? [09:33] persia, that's what i'm thinking at this point at least [09:34] OK. I fear breaking stuff, or not having time to fix stuff. At this point, it seems there are no good choices :) [09:34] * persia starts porting the patch. [09:34] well just need to keep in mind; it's already fairly broke [09:34] Right. That's why there are no good choices. [09:34] can't really break it much more [09:35] Well, we could make audio or comms stop working. [09:35] ah right [09:36] conveniently i've got a headset and can do rfcomm via my phone, so i can at least look at those too [09:36] the branch is owned by ~ubuntu-dev - so if you get the hildonization patch together you should just be able to merge it in yourself [09:37] * persia likes pastebins, but may look at the branch in a bit [09:37] or if you see anything that you feel like !stab'ing about the packaging and all too :) [09:38] * persia is unlikely to find time for a proper packaging review [09:38] Well, unless it takes a *very* long time to process, but that means we'd miss the deadlines. [09:39] its mostly a merge of bluez-lib and bluez-utils, so it should be sanish [09:39] and if there are things that stick out, they likely were artifacts from those previous packages too [09:54] Hrm. I think maybe the changes to general.c are useless. [09:55] okay i've got a patch that appears to set the default connectable now [09:55] assuming that's a software setting and my BT chip doesnt need to be reset, it appears to work [09:56] Shouldn't be an on-chip thing, as booting off different USB keys re-breaks it each time for me. [09:57] okay good [09:59] * Hobbsee waves [10:06] What would be the best way of testing patches / software. I have an intrepid system, so i normally install the old version - test to confirm the problem. I then use pbuilder to build my new version and then install the resulting .deb and check to see if the problem is fixed. How should i be testing similair fixes for hardy and earlier? [10:11] stefanlsd: On a hardy system. If you don't have one, and it's not a hardware-related issue, virtualisation is a good solution. For CLI-only stuff, chroots work well. Some people also have gotten X to work in their chroots: you might try that, but it's trickier. For stuff that uses system services (e.g. dbus), you really want virtualisation or real hardware. [10:12] persia: i agree that the vm route works well, just bandwidth is pretty costly here still, and i dont particularly want to be keeping whole systems up to date... are there any caveats to doing it via pbuilder --login ? [10:13] stefanlsd: If you've a chroot already, there's no reason you can't use that to generate your virtual image. [10:16] persia: thanks. i will try using the chroot with pbuilder and see how it goes [10:17] stefanlsd: If you need a virtual environment, just copy the contents of the chroot into an empty virtual disk, add a kernel, and boot off that. [10:19] Anyone good with autoconf? There's no configure.in with the new bluez-gnome, and I'm wondering if the patch fragment in http://paste.ubuntu.com/51200/ should work with configure.ac [10:51] Hobbsee: which package? === asac_ is now known as asac [11:06] Hobbsee: sorry for that, I'll reply on the ML [11:06] is release.ubuntu.com dead for anybody else? [11:09] Burgundavia: its releases. [11:10] I kan spel, honest gov [11:10] hmm, intrepid folder is empty [11:11] they'd be on cdimage [11:11] wouldn't they? [11:12] http://cdimage.ubuntu.com/releases/intrepid/alpha-6/ [11:15] Burgundavia: it's releases, not release ;-) [11:15] bah, Flannel already said so [11:15] yep, but previous alphas used to be on releases [11:20] Is a security update allowed to fix a bug? Or do i need to do an SRU and then the security update? [11:21] laga, fun fact: due to the way launchpad works, mister "IT R 2.0 DAMNIT!" has 10x my karma, because he spends a lot of time on Answers giving answers of dubious value. [11:22] directhex: well, it's just karma. [11:23] directhex: or LP saw you yelling at people in #mythtv-users. [11:24] laga, they deserve it! they're *SO STUPID* >_< [12:35] hm, only 76 packages which aren't installable. [12:37] Hobbsee: you have some work to do then. There are thousands more to put into that state [12:37] Burgundavia: no, i'm on the release team. i can't do that :) [12:37] Burgundavia: i'm one of those who yells at people for uploading crack :) [12:37] Hobbsee: I see 79. [12:37] (well, http://qa.ubuntuwire.com/debcheck/ does) [12:38] wgrant: hmm. amd64 specific ones, apparently. [12:39] * StevenK blinks. gcc-4.2 ? [12:40] Right, debcheck is on crack [12:40] wgrant: I've managed to test my touchpad on an alpha 6 live usb - Sys->Preferences->Mouse has no touchpad tab there, either. It doesn't look like a configuraiton problem. [12:40] lib{32,64}ffi4 aren't built by gcc-4.2 [12:40] RAOF: OK, tjaalton thinks he's seen why. [12:40] RAOF: Maybe. [12:41] hmm, one i've uploaded to a ppa. that won't be helping. [12:41] wgrant: Yay! I'll be available to test, then. [12:42] wgrant: I question that 79 number. [12:42] StevenK: https://edge.launchpad.net/ubuntu/intrepid/i386/lib64ffi4/4.2.3-2ubuntu7 [12:42] "gcc-4.2 4.2.3-2ubuntu7 (source) in Ubuntu" [12:43] "i386 build of gcc-4.2 4.2.3-2ubuntu7 in ubuntu hardy RELEASE produced these files: " [12:43] So why does that line say Hardy? [12:44] StevenK: Because it built in Hardy, probably. [12:44] Then was copied to Intrepid. [12:44] * wgrant looks. [12:44] Yes, that's why. [12:44] StevenK: Why do you question the number? It seems quite clear to me. [12:44] It ought to have been killed, 4.2.3-2ubuntu7 is in Hardy, 4.2.4-3ubuntu2 is in Intrepid [12:45] StevenK: But the binary is still there. [12:45] StevenK: NBS, I presume. [12:45] https://edge.launchpad.net/ubuntu/intrepid/i386/lib64ffi4 clearly shows that it's still published, so debcheck is right. [12:45] It isn't listed in NBS, though [12:45] Then NBS might be buggy. [12:45] Or Soyuz might be. [12:46] Um. [12:46] That's very strange. [12:47] wgrant: Hm? [12:47] How is the NBS list generated? [12:47] There's a bug somewhere, and it's not in debcheck. [12:47] Doesn't look like it's in Soyuz either. [12:49] * Hobbsee files a removal request [12:49] * StevenK is checking [12:49] Hobbsee: For? [12:49] oh dear. this package has been kmos'd. [12:50] wgrant: kionjb [12:50] wgrant: I'm not sure how NBS is generated [12:50] StevenK: Buggily, at any rate. [12:51] Hm. [12:51] Might it be because it's only on some archs? [12:51] Hm, possibly, but lib32ffi4 should show up [12:51] W: Unable to locate package lib64ffi4 [12:51] But my Intrepid chroot can't find it [12:55] I see lib32ffi4 in intrepid/amd64/universe's Packages. [12:56] And lib64ffi4 is in intrepid/i386/universe, as Soyuz says. [12:56] StevenK: ^^ [12:58] I see that [12:58] I'll raise that with pitti [12:58] Thanks. [12:59] StevenK: can you fix ggz-grubby please? looks like you've been one of the last people to touch it, and it doesn't install now. Hopefully you can sync it? [13:00] (looks like you wrote the changes in the first place) [13:01] I did? [13:01] StevenK: i think so [13:02] StevenK: yep, you did. [13:03] StevenK: https://bugs.edge.launchpad.net/ubuntu/+source/ggz-grubby/+bug/230016 is for you to close when you do :) [13:03] Hobbsee: Requires an FFe [13:03] Launchpad bug 230016 in libb-size-perl "[intrepid] Rebuild with perl 5.10" [Undecided,Confirmed] [13:03] StevenK: even for stuff that does'nt build? [13:03] Latest source in Debian is a new upstream version [13:04] StevenK: meh. [13:04] StevenK: maybe ubuntu release should declare a standing FFe for stuff that doesn't build, and makes most sense to sync for, or something. [13:05] StevenK: i presume the changes *can* be dropped? [13:05] * Hobbsee notes then we can boot libperl5.8 from the archive, too [13:05] * StevenK hasn't checked yet [13:05] ah [13:05] Right, ggz-grubby is the last package [13:06] yep [13:06] * wgrant would be in favour of getting things to build. [13:07] * Hobbsee too. [13:07] preferably, stuff that has been known to debian for a while, and is fine there, rather than a rebuild of what we currently have, which may, or may not, work well. [13:07] The last uploader of ggz-grubby is \sh, and it needs a merge [13:07] <\sh> if that works, yes... [13:08] Perhaps the patch can be dropped, since it's from upstream SVN [13:08] <\sh> but ggz-grubby doesn't build on ubuntu anymore... [13:08] * StevenK grabs the source from Debian [13:08] <\sh> nccommander wanted to take it [13:08] \sh: that's why it's on my list - it doesn't install, for one. [13:09] <\sh> Hobbsee: well, debian version doesn't build too [13:09] <\sh> and I don't have any clue how to fix it [13:09] Removal! [13:09] stefanlsd: a -security update can only contain a security fix. other fixes need to go through SRU [13:09] Kill kill kill. [13:09] jdstrand: Unless you're Linux or Firefox... [13:10] jdstrand: thanks. you are subscribed. Hopefully i've added enough info to the wordnet bug to get the fixes applied. [13:10] <\sh> wgrant: *eg* [13:10] StevenK, \sh: one of you file a removal request, the other remove it, then? :) [13:10] \sh: Hm? [13:10] :P [13:10] I'll file the request [13:10] :-P [13:10] <\sh> Hobbsee: well.... [13:11] <\sh> if I file the request, I'll be blamed again for removing a necessary package for kids or so...and then I'm named "you murder of my child" or so [13:11] * wgrant murders \sh preemptively. [13:11] <\sh> ah that's good...now I don't need to play around with my new toys anymore... [13:12] <\sh> I can sleep now forever ... which is good... but then, I'm dead, which is bad...hmm [13:12] stefanlsd: I also just read #ubuntu-hardened... is it possible that the patches were already applied inline? (this sometimes happens when people use patch/ or patches/ for showing what's applied) [13:13] jdstrand: Those people sound like they need... "reeducation". [13:13] though the build-dep on cdbs suggests otherwise... [13:13] wgrant: totally [13:13] <\sh> jdstrand: a build dep on cdbs doesn't count ,-) [13:14] * Hobbsee wonders why hardy-proposed has later versions of packages than intrepid does. [13:14] Hobbsee: Because people are strange. [13:14] <\sh> because -proposed is more crackful then latest devel release? [13:15] * \sh is missing sun-java{5,6}-plugin or ia32-sun-java{5,6}-plugin..without it, I can't even administer my server via ilo2 anymore [13:16] jdstrand: heh. they arent inline. (shew) [13:17] stefanlsd: it's a bit of an oddcase, but does sometimes happen [13:17] stefanlsd: good work on bug #267067 btw :) [13:17] jdstrand: and they did build, i dont think it would of patched succesfully if they we're already in. [13:17] Launchpad bug 267067 in wordnet "[CVE-2008-2149] wordnet 2.0, 2.1, 3 affected by multiple buffer overflows" [Undecided,In progress] https://launchpad.net/bugs/267067 [13:17] stefanlsd: I'll take a closer look and likely push it out on Monday [13:18] jdstrand: thanks! would be happy to get it closed. was a lot more work than i anticipated. :) [13:18] I have the gutsy patch ready, just need the SRU to go in first. [13:19] Hi, I'm trying to build OOo3 for hardy in my PPA. There is a build-dependency on libcups-dev so I took the files verbatim from intrepid and tried to recompile cups in the PPA first. [13:20] Laibsch: Try libcupsys-dev [13:20] For some strange reason, it fails: https://launchpad.net/~r0lf/+archive/+build/724898 [13:20] OK [13:20] Thanks [13:20] Shoot, that means, I will have to reupload those 300MB again [13:20] No, not the .orig.tar.gz. [13:21] Unless you've done something very bad. [13:21] stefanlsd: yeah-- but you'll be able to sleep better at night because of it [13:22] ;) [13:22] jdstrand: hehe. yeah. i actually. i hate having open bugs assigned to me. I think part of the problem was i didnt really have a process. I think I have that now, so it should get easier. (I also have the 4 different chroots!) [13:23] stefanlsd: I have 18 chroots plus 20 virtual machines :P [13:23] and that's just for Ubuntu [13:24] actually that's not true-- 3 chroots are for Debian [13:24] wgrant: Well, you are right. But I already aborted the upload (at 75%). Stupid mistake ;-) [13:24] jdstrand: heh. i have bandwidth issues. (south africa). [13:25] * jdstrand nods [13:25] motu-release: for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496618 should we sync or remove the package? [13:25] Debian bug 496618 in viruskiller "viruskiller: Contains non-free sound and music" [Serious,Closed] [13:26] stefanlsd: with the good work you've done, I recommend you take a look at https://wiki.ubuntu.com/UbuntuDevelopers [13:27] stefanlsd: you'll need to demonstrate a sustained contribution, but definitely consider it :) [13:27] bug 275131 if anyone wants to weigh in [13:27] Launchpad bug 275131 in viruskiller "Contains non-free data files" [Critical,New] https://launchpad.net/bugs/275131 [13:27] james_w: i'd sync, personally. [13:28] james_w: assuming all the nonfree files are actually gone [13:28] So would I [13:28] jdstrand: yeah. thanks. I am working towards MOTU. Will prob apply for U-U-C after Intrepid sometime :) [13:28] Hobbsee: at this point I'm just trusting Debian and deciding what to do, but I would agree. [13:28] james_w: request away, then :) [13:29] stefanlsd: great! keep up the good work and you can add me to your list of fans :) [13:30] jdstrand: thanks. might just CC you on my application request one day then :P [13:30] great! (that's really what I was getting at ;) [13:33] * StevenK blinks at ggz-grubby [13:35] * Hobbsee glares at echelon [13:35] * wgrant closes his eyes at .* [13:36] Way cool, ggz-grubby fail the same way [13:36] And now gnuradio fails with a C++ error I don't get [13:41] * Hobbsee strikes another off the list [13:41] perhaps we need a 5-a-day for packages that don't install [13:43] * Hobbsee wishes htere was a motu-hopeful around to help with this [13:44] i'm UUC-hopeful, but very busy ;) [13:44] Hobbsee: IE, "minion" [13:45] * wgrant renames ~ubuntu-universe-contributors to ~universe-minions [13:46] Heh [13:46] Hobbsee: what do u need help with? [13:47] Umm. Careful there. Last time we tried something of the sort, there were complaints. [13:47] stefanlsd: a whole lot of 'apt-cache unmet -i' [13:47] stefanlsd: a whole lot of it is replacing ice* with the respective packages for ubuntu [13:47] wgrant: you can be my minion when we meet :-) [13:47] iirc, it's replaced with webbrowser or something. [13:47] * wgrant sends some minions after the complainants. [13:48] * wgrant is intimidated. [13:48] wgrant: in like... 3 months :-) [13:48] Hobbsee: wasnt it abrowser ? [13:48] abrowser | firefox [13:48] stefanlsd: probably :) [13:48] But they also need source changes, sometimes. [13:49] Hobbsee: ok, do you have any example debdiff up already? then i'll have a look and see if i can jump in. [13:50] stefanlsd: no - but it's just debian/control changes [13:50] Hobbsee: Not necessarily. [13:50] wgrant: well, normally is [13:51] anyone got any particular attachment to arpack++? [13:52] Ah ha. [13:52] I know why ggz-grubby fails to build [13:52] (intrepid)root@liquified:/ggz-grubby-0.0.14/games/guru-ttt# ls -lh /G* [13:53] -rw-r--r-- 1 root root 254 Sep 27 22:50 /Guru Chess.module.dsc [13:53] -rw-r--r-- 1 root root 257 Sep 27 22:52 /Guru TicTacToe.module.dsc [13:53] What is wrong with this picture? [13:53] * persia loves whitespace === Czessi_ is now known as Czessi [13:53] Um. [13:54] It isn't the whitespace [13:54] Why are they in the root? [13:54] Exactly [13:54] I smell a murder coming on.; [13:54] Oh my. [13:54] * StevenK is sharpening his daggers [13:55] * wgrant keeps some presharpened. [13:55] My daggers are fairly sharp, but that calls for some extra prep-work [13:56] * Hobbsee die packages, die! [13:56] Red? Blue? Purple? [13:58] ggz-config, die in a large chemical fire [13:58] You have the power. Kill it. Kill it severely dead. [13:59] * RainCT doesn't know what you are talking about but is getting scared *g* [13:59] RainCT: It's a package. [14:00] yea, figured that out [14:01] wgrant is trying to goad me into removing packages from the archive. [14:01] Is that not reason enough? [14:01] It's working. [14:02] StevenK: Are you removing packages that are in lenny, or just annoying ones? [14:03] * wgrant can use the presharpened daggers on archive admins too. [14:03] Hobbsee: hi, do you use B91dpkg-i to test installability? it seems to be a bit stupid and doesn't install run-time dependencies before calling 'dpkg -i', so it fails [14:04] persia: I've removed one so far, and it hasn't been in Debian since 2007 [14:04] That counts as annoying :) [14:04] pochu: that, or another one, yes. [14:04] i think i was using another one [14:04] wgrant: I've heard a rumor that you know lots about synaptics. Any idea why they might not be recognised at all? [14:05] persia: These dirty lies seem to spread well. I touched it a couple of times, and hope to care for it properly at some point. [14:05] persia: How undetected is it? [14:06] Hobbsee: ah, likely B92test-pkg [14:06] Very. dmesg shows it. X doesn't register it. [14:06] persia: Pastebin your xorg log, please. [14:07] * persia preps an affected system [14:07] pochu: that sounds familiar, yes [14:09] Hobbsee: it seems to install dependencies and the packages, then remove the packages, and run some test suites [14:10] pochu: that's it, then. [14:11] thanks [14:13] does anyone document these common changes? like libkonq4 doesnt exist and you must use libkonq5 etc? [14:14] anybody want to play a game? [14:15] please test viruskiller from https://edge.launchpad.net/~james-w/+archive [14:15] (or build the Debian version for yourself) [14:15] wgrant: http://paste.ubuntu.com/51251 [14:15] james_w: The builds aren't published yet, but I'll hack URLs... [14:16] stefanlsd: Nope. There's lots of them that nobody even notices when Debian does the work before we start autosync when a cycle opens. [14:17] persia: Does lshal see the touchpad? [14:17] persia: mm. just seems silly that one of us know a common answer, and i spend an hour trying to work it out kinda thing... [14:19] * persia balks at parsing lshal output, but gnome-device-manager displays it, and is supposed to be a HAL gui. [14:20] Hobbsee: normal process for these umet dep problems? File a bug, apply the debdiff, and subscribe sponsors? [14:20] stefanlsd: yes [14:20] The other two mice in the device work OK, just not the SynPS/2 Synaptics TouchPad. [14:20] james_w: It gives me a nice corrupt screen, just readable as asking me to press space, and hitting space causes it to segfault. [14:20] \o/ [14:20] wgrant: nice, thanks [14:21] persia: Pastebin the output of lshal, or relevant sections thereof? [14:22] * persia tries to extract the useful bits [14:25] wgrant: http://paste.ubuntu.com/51255 Let me know if I cropped too much. [14:26] persia: Hmm, the difference from mine is: [14:26] input.x11_driver = 'synaptics' (string) [14:26] * wgrant checks a few things. [14:26] So HAL is supposed to provide that? [14:27] I presume an FDI file is borked. [14:27] wgrant: Note that the hardware works: whether it appears seems to depend on the booted dpkg-architecture [14:27] Right. Which package needs to be thwacked? [14:28] persia: Do you have /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi? [14:28] I don't. In that directory I only have 10-wacom.fdi [14:29] Erm. [14:29] Do you have xserver-xorg-input-synaptics actually installed? [14:29] 23:29:16 < wgrant> Do you have xserver-xorg-input-synaptics actually installed? [14:30] No. It appears not to exist. Thanks. Now I can fix it. [14:30] Ah, not built on lpia? [14:31] No. [14:33] It appears that the attempt to not provide it for s390 hit me. Thanks for the pointing. [14:33] How? [14:34] It's excluded in P-a-s, and the source's arch list, AFAICT. [14:35] I didn't see xserver-xorg-input-synaptics in P-a-s [14:35] Yep. Since I have two devices that Intel claims to be lpia, and both have Synaptics touchpads, I think that's likely a bug. [14:35] StevenK: xfree86-driver-synaptics [14:35] Oh, right [14:35] There was a source by the binary name, and hopefully will be again soon. [14:35] But it's something else ATM. [14:36] * persia is testing a build now, and will be *very* happy to have a working mouse on the D4, for which all the current mouse-like input devices don't work [14:37] darn, u-u-s is over 100 again. [14:38] * Hobbsee kills a few [14:38] Hurrah! Smaller UUS means better release and happier developers [14:39] wish i had removal powers, though [14:39] * StevenK whistles innocently [14:40] StevenK: hush, lucky canonicalite :) [14:41] StevenK: besides, you have a list of bugs i'd like you to action - have you done them yet? :) [14:41] Nope [14:41] aww [14:42] apt is ever so helpful. Your network cable appears to have been knocked out. Please try again with --fix-missing [14:47] AH HA! [14:47] wgrant. That did it. Thanks. [14:47] # /usr/bin/ggz-config --noregistry=/usr/share/ggz/modules/ggz-grubby --install --modfile=module.dsc --force [14:47] (line 476) /usr/share/ggz/modules/ggz-grubby [14:47] (line 478) /Guru TicTacToe.module.dsc [14:47] persia: Excellent. [14:48] StevenK: /Guru Stab.module.dsc [14:48] Sigh [14:48] sprintf(global_pathname, "%s/%s%s", global_pathname, fixedmodname, suffix); [14:48] Let me count why this is bad [14:49] * wgrant eagerly awaits. [14:49] Isn't that going to screw up global_pathname? [14:49] My printf debugging shows it is [14:50] Um, yes. [14:50] Maybe. [14:50] * Hobbsee finds another incorrect bug on the sponsorship queue [14:50] Depends what you mean by "screw up" [14:51] It seems to set global_pathname == "" [14:51] Not the behaviour that I would expect. [14:51] But I don't often do strange things like that. [14:51] I wouldn't either, it just reads wrong [14:54] StevenK: You haven't unleashed appropriate torrents of hate onto it yet? [14:54] * Hobbsee knocks another bug off the queue [14:54] wgrant: I think I've fixed it, just testing it [14:56] (line 476) /usr/share/ggz/modules/ggz-grubby [14:56] (line 478) /usr/share/ggz/modules/ggz-grubby/Guru TicTacToe.module.dsc [14:56] HATE HATE HATE [14:56] Yay. [15:09] \sh: ggz-grubby fixed [15:09] StevenK: excellent! You can kill libperl5.8 from NBS now, too! [15:10] I have to wait for the publisher, but yes [15:12] <\sh> StevenK: dude..you are a rockstar..how did you solve it? [15:13] \sh: I fixed ggz-config in ggz-client-libs [15:13] <\sh> grmpf.../me doesn't have a clue about ggz-config [15:15] <\sh> but I have a clue how to lb adobe fms edges via heartbeat and ldirector -) [15:16] EPARSE [15:16] <\sh> see [15:16] * \sh is just playing with a bunch of hardware, all ubuntu powered...and I have to configure it to loadbalance... [15:17] <\sh> this is done via heartbeat and ipvs and ldirectord...with nifty workarounds [15:17] * \sh needs to be finished with that monday morning [16:01] Hobbsee: do you have the powers to reject meta-gnome2 which is in the unapproved queue? I missed James' comment about abiword, so you if you can reject it I'll reupload with abiword in depends. === smarter_ is now known as smarter [16:19] superm1: On the bluez-gnome hildonisation patch. It doesn't actually hildonise anything. How do you think having the "Known Devices" list to the right of the rest of the Preferences panel would look on a high-resolution, moderate DPI screen? [16:20] persia, just fine I think. [16:20] superm1: OK. I'll fiddle the patch a bit more and push to bzr then. [16:21] persia, sounds good [16:21] It should be something we can eventually upstream, which would make it even easier. [16:22] persia, one we have this in a state we're ready to accept, definitely [16:23] i dont see why upstream would be very critically tied to the shape of the preferences window [16:23] superm1: Right. No point upstreaming until we know it works. [16:23] I have a fairly compelling use case too: I've two different computers on which the default applet layout is hard to view. === emma_ is now known as emma === smarter_ is now known as smarter === asac_ is now known as asac [17:10] how to use pbuilder with several chroots? [17:11] o.0 [17:12] nedko: i have a script i use for use several roots [17:12] ive made it for me, so have no doc :] [17:12] let me paste it [17:13] nice [17:13] nedko: http://pastebin.com/f6980710a [17:14] s/# Para criar as gaiolas:/# To create jails/g [17:14] s/# Ooooooou/or/g [17:15] leleobhz, nedko: see also pbuilder-dist and pbuilder-dist-simple from ubuntu-dev-tools [17:15] nedko: this code sucks, but can give you a idea how pbuilder can work [17:15] o.0 [17:15] nedko: https://wiki.ubuntu.com/PbuilderHowto#Multiple%20pbuilders, and pbuilder-dist in the ubuntu-dev-tools package [17:15] geser: i dont know this code [17:16] its close of what i did [17:16] but my script sucks a lot :] [17:17] Does make-kpkg not work with the git sources? After taking the debian dir from the latest intrepid package. [17:27] i want to have several chroots for same distro and arch, can pbuilder do this? [17:49] superm1: hello [17:49] hi crevette [17:50] so i'm sure you've been watching the activity floating on bluez 4.x? [17:50] superm1: yeah [17:50] I'm building gnome-user-share [17:50] crevette, how are you feeling about it thus far? [17:50] file sending and receiving doesn't not work but it seems you're working on it [17:51] yeah it looks like a newish obex-data-server is required. i tried to just patch around it, but it's a bit complex [17:51] okay [17:51] other than that- anything else negative standing out? [17:52] I'm don"t have input devices so I can't test that [17:52] except wiimotes [17:52] :p [17:53] crevette, okay well persia and i have both tested input devices thus far, and they're looking better (after a patch to bluez-gnome to ensure it starts up in a connectable mode) [17:53] okay [17:53] superm1: how can I push g-u-share to your ppa ? [17:53] crevette, it's a team PPA [17:54] your in ~bluetooth right? [17:54] let me check [17:55] superm1: I joined it, but apprently approval is required [17:56] crevette, okay for now then, just push it to your personal PPA, and i'll copy it into ~bluetooth when it finishes building [17:56] crevette, poke Mithrandir to ack your joining [17:56] oky docky [17:56] superm1: https://launchpad.net/~bmillemathias/+archive [17:57] superm1: I think the versioning of the package is wrong, right? [17:57] of gnome-user-share? [17:57] yep [17:57] if it works properly on the first try, i guess that would be fine .... [17:57] but if you've got some bugs then it will be troublesome [17:57] you normally want a ~ppaX added [17:58] yep [17:58] I'll redo it [18:00] crevette, are there any applicable patches on bluez-gnome 0.28's package on your PPA that make sense for 4.x? [18:00] hum, let me look [18:02] superm1: not from 0.28 [18:02] but fedora has a patch http://cvs.fedoraproject.org/viewvc/rpms/bluez-gnome/devel/bluetooth-sendto-ods-svn.patch?view=log [18:02] hmm, it's for svn obex-data-server [18:02] crevette, i was just looking for that - it's needed with these obex snapshots [18:03] thanks :) [19:16] crevette, i've got a few things i just pushed to the PPA re gvfs, obex-data-server and a new bluez-gnome [19:16] should fill in the missing gaps regarding obex, but i cant verify with my phone atm [19:18] crevette, i copied in your gnome-user-share stuff to the PPA too [19:23] superm1: wonderful [19:23] crevette, i you can check file sending now, hopefully it's better once all that stuff is published [19:23] superm1: okay [19:25] superm1: one thing ro consider is when file receiving between gnome-user-share and bluez-gnome are conficting, can we do like fedora and disable file-receiving in bluez-gnome and pull gnome-user-share as dependecy of bluez-gnome? [19:25] s/when// [19:25] crevette, there is no more file receiving in bluez-gnome [19:25] so that's probably a sensible idea [19:25] superm1: ah I didn't know [19:25] crevette, it changed for 4.x [19:25] you applied the fedora patch for that N [19:25] ah [19:26] there is a patch for bluez-gnome 0.28 in fedora to do that [19:26] crevette, well the problem is that gnome-user-share is universe though [19:26] so that would require some more paperwork here for the MIR [19:26] this whole switchover is turning out way larger than i anticipated [19:27] yeah :/ [19:52] is there a channel to help me with a linux problem ? === paul__ is now known as Elbrus [22:32] hi, I was directed here after asking about installing a package with optional packages that aren't included in the .deb [22:33] it's audacity, and I am trying to add the soundtouch libraries, specifically.. also on amd64, if that makes a difference.. did apt-get source audacity, and after ./configuring I got "/lib/cpp" fails sanity check [22:51] uouou: apt-get build-dep audacity [22:53] libsoundtouch isn't in the debian/rules file though === macd_ is now known as macd [22:58] which is weird, because it used to be part of the main package.. I don't know if someone at some point decided that changing pitch and changing speed is the same thing? :P I do a lot of transcription, so slowing down speed while maintaining pitch is important for me