[00:06] kees: #273761> yeah, that ought to get in [00:08] slangasek: okay, it's uploaded and waiting for you. :) [00:09] yep, seen :) [00:09] seb128: I don't see gnome-build in the queue; did someone already accept it? [00:09] slangasek: apparently yes, there was a batch of updates accepted a few minutes after I asked apparently [00:09] asac: ok, will look at the NM uploads, thanks; btw, I'm seeing that the system-level secret store for NM doesn't seem to be working, every time I reboot I get prompted for the wep key before I can connect :/ do you know if there's a bug about this? [00:10] slangasek: I did an accept-everything-for-universe pass which included gnome-build [00:10] ah, sure [00:10] thanks :) [00:13] slangasek: i think that secret issue should be fixed now [00:14] asac: in your current upload, you mean? [00:14] slangasek: yes. [00:14] cool [00:14] slangasek: there was definitly an issue in the applet with regards to writing secrets which is in the diff [00:14] ah; as far as I could tell it was an issue reading, not writing, the secret [00:15] (at least, I saw the secret was written to a file) [00:15] asac: Have you tried flash with recent pulseaudio updates I've made by any chance? I have some users saying that since a recent update to pulse I made, flash and pulse via alsa plugin are not working as they should... [00:16] slangasek: + - (nm_gconf_write_connection, write_one_secret_to_keyring): split out [00:16] + writing of secrets into it's own function for clarity. Fixes a [00:16] + regression introduced in r875 where secrets wouldn't get saved. [00:16] slangasek: oops ;) [00:16] ok [00:16] TheMuso: i tried it a bit ... my sound worked nicely [00:17] TheMuso: (after removing my asoundrc ... which should be enough?) [00:17] asac: Right, I'll have to keep digging then. [00:17] pitti: I'd like to fix an ice-on-invalid bug in gcc-4.2 in hardy (seen when working with eclipse). do you want to move the packages to -updates first? [00:17] calc: so OOo is ftbfs on all !x86 right now? [00:18] slangasek: please accept ant and libxerces2-java [00:19] doko: is there an associated, beta-blocking bug? [00:20] slangasek, calc: I did talk with calc about powerpc; didn't look at sparc yet [00:20] slangasek: yes, mentioned in the changelog [00:20] doko: but, notably, not tracked on https://bugs.launchpad.net/ubuntu/intrepid/+bugs?field.milestone=1325 ? :) [00:21] https://bugs.edge.launchpad.net/ubuntu/+source/ant/+bug/264808 [00:21] Launchpad bug 264808 in libxerces2-java "ant does not work with JDK 5" [Undecided,New] [00:22] milestone is ubuntu-8.10-beta [00:22] what did I miss? [00:23] 'target to release' [00:27] nominate? [00:28] Due to an LP bug, yes. [00:29] it's "nominate for release" if you aren't in ubuntu-drivers or ubuntu-release or whatever team it is [00:29] wgrant: is this LP bug filed? [00:29] wgrant: what LP bug? [00:29] just that the text is different? [00:30] TheMuso: hrm, after my latest reboot, audio seems to have regressed somewhere for me; is this a known issue? [00:30] doko: I don't think so. [00:30] cjwatson: Right - it only checks if you're a driver, but there are special privileges for distros. [00:31] no, I was surprised that just setting the milestone is not enough [00:31] Only the text is wrong, however. [00:31] doko: http://wiki.ubuntu.com/RCBugTargetting [00:31] that part at least is not an LP bug, it's intentional [00:31] "Only those milestoned bugs which are also marked as release-critical, by way of targeting to the release, will be managed by the release team" [00:31] and this was because developers not on the release team asked for this [00:32] ok, wasn't aware about the history [00:32] the idea is that targeted + milestoned == release-critical for milestone, not targeted + milestoned == developer planning own work but might slip [00:35] slangasek: What were you trying to play audio with, and how were things set up? [00:35] TheMuso: quodlibet, which uses gstreamer and has worked previously; through pulseaudio, which is running; consolekit has the correct perms on the devices; that's as far as I've looked so far [00:36] slangasek: Yeah its known, I haven't been able to pin it down yet, and I can't seem to reproduce locally. Just updating an intrepid install to the latest updates now, and I will see what I can find. [00:36] ok [00:37] is there a bug number for this? [00:37] slangasek: in gnome-sound-properties, you are using pulseaudio or auto detect are you not? [00:37] slangasek: one sec, I'll fetch. [00:38] autodetect [00:38] shall I try to hard-code to pa? [00:39] ah, the 'test' button gives me: 'audiotestsrc wave=sine freq=512 ! audioconvert ! audioresample ! gconfaudiosink: Failed to connect stream: Invalid argument [00:39] ' [00:40] slangasek: did nominate the bug [00:40] doko: thanks [00:40] slangasek: I think bug 274124 is the most relevant. [00:40] Launchpad bug 274124 in pulseaudio "Sound no longer working after kernel upgrade to 2.6.27-4" [High,Confirmed] https://launchpad.net/bugs/274124 [00:40] slangasek: there is a libasound2-plugins package I linked to in that bug, install that and see if that helps you. [00:41] TheMuso: hmmm, I can neither confirm nor deny that this was my first reboot to 2.6.27-4 [00:41] It sounds like autodetect for most people is defaulting to alsa which then attempts to use the alsa pulse plugin. [00:41] slangasek: I am almost 100% sure it is not kernel related, but the bug reporter thought it was. [00:41] well, I get the same error with the 'test' button if I manually select pulseaudio instead of autodetect [00:41] I think I even said as much in the bug./ [00:41] it's not related to the kernel; it's an alsa-plugins issue. [00:43] crimsun: but alsa-plugins doesn't make sense for straight pulse not working... [00:44] TheMuso: but pulseaudio seems to have problems when swfdec is attempting to play audio, so I'm going to take a look there. [00:44] ok, here's what I have in the log: [00:45] Sep 29 15:53:36 dario pulseaudio[7368]: alsa-util.c: Error opening PCM device hw:0: Device or resource busy [00:45] Sep 29 15:53:36 dario pulseaudio[7368]: module.c: Failed to load module "module-alsa-sink" (argument: "device_id=0 sink_name=alsa_output.pci_8086_27d8_alsa_playback_0"): initialization failed. [00:45] slangasek: SOunds like you have something else that is holding the hardware open, and pulse hasn;'t been able to grab itr. [00:45] nothing else has the hardware open at this point [00:45] $ sudo fuser -v /dev/dsp /dev/snd/pcmC0D* [00:45] $ [00:45] hrm. [00:46] if so, then you should be able to restart pulseaudio from the cli successfully [00:46] if I kill and restart pulseaudio, it works,y es [00:48] so: device contention at login time, wih the startup sounds? [00:48] slangasek: Do you happen to have any .asoundrc files in your home directory? [00:49] yes [00:49] (for trying to configure bluetooth audio) [00:49] Ah ok. [00:49] Try moving them away for now... [00:50] they probably may have somethign to do with it, depending on whether they alter the default device used. [00:50] they don't [00:50] ok they shouldn't be a problem then. [00:50] do you still want me to try moving it aside, and re-logging in? [00:51] No if they don't alter the default device used I don't think they are a problem. === macd__ is now known as macd [01:49] asac: how thoroughly has this NM build been tested? it's a rather large change to drop this close to beta [02:50] slangasek: it did build on amd64/lpia last time i built it from what i recall [02:50] * calc looks at the build logs === jamesh_ is now known as jamesh [02:51] slangasek: yea it builds on the supported archs :\ [02:51] slangasek: i think i can get it working on powerpc again, if nothing else by disabling java (which makes is of questionable use) [02:51] slangasek: hppa doesn't work at all, its unsupported platform [02:51] er unsupported all around i mean, not by sun/go-oo/us etc [02:52] not sure about the ia64/sparc issue will have to see if it is due to the same basic problem affecting powerpc [02:52] but sparc generally doesn't build OOo either, it has failed nearly every time generally in ICEs [02:56] calc: I'm happy to do a test build of OpenOffice on PowerPC again if that is of any help... [02:56] TheMuso: the problem was it couldn't find libjawt and i think i know how to fix it properly now [02:57] TheMuso: i missed a patch that was needed when adding support for openjdk [02:57] calc: Ah ok. [02:57] slangasek: ia64 fails due to what seems like is probably an openjdk issue [02:58] "error (RuntimeException): [jni_uno bridge error] UNO calling Java method initialize: java.lang.StackOverflowError" [02:58] slangasek: well. beta is supposed to bring the testing. [02:59] yea sparc looks like it is probably the same issue as powerpc, even after fixing i would be surprised if they build correctly though [03:01] slangasek: the core features (wired and wifi) are unlikely to have regressed much [03:03] slangasek: there is one known regression ... it sets the hostname to localehost.localdomain in /etc/hosts [03:04] that is because we are lacking a system integration part that reads /etc/hostname [03:04] slangasek: except from that most changes in ChangeLog are either from me or about non-core features like VPN, etc. and a bit polishing [03:04] (from me -> upstreamed) [03:32] slangasek: I took a brief look at Intrepid uninstallables and the solution for ubuntu-virt-management is to demote it to Universe. The MIR (Bug #274053) says that binary should not be promoted. [03:32] Launchpad bug 274053 in ubuntu-virt "main inclusion request: ubuntu-virt-server" [Undecided,Fix released] https://launchpad.net/bugs/274053 [03:52] calc: yes, amd64 and lpia are also "x86" :) [03:53] slangasek: ok so yea more or less :) [03:54] asac: "beta is supposed to bring in the testing" -- yes, but testing of things that we have some assurance are solid; not things that have been dropped in hours before the CD builds need to start [03:54] slangasek: powerpc has had java issues forever, sparc has had compiler broken issues forever, hppa is completely unsupported, and ia64 appears to have broken openjdk [03:54] so yep x86 is about all OOo will work on [03:55] asac: uhhh. why is NM touching /etc/hosts *at all*? That alone sounds like a major regression to me that's going to have lots of knock-on effects :/ [03:59] ScottK: thanks, demoted [04:39] ok i think i have the patch that should help for powerpc and sparc [04:41] slangasek: so i take i should NOT upload the OOo fix until after beta release, correct? [04:54] * calc takes no answer as a no unless he hears otherwise later [04:55] i'm doing a build to verify i didn't break anything on amd64 with the patch but i think it will at least fix the current cause of failure on powerpc/sparc === jono_ is now known as jono [05:54] calc: hum, yeah, let's hold off on the OOo powerpc/sparc fix === superm1|away is now known as superm1 [06:10] good morning [06:59] should I file a bug for this? type-handling any linux-gnu generates a list which contains i686 and lintian throws error invalid-arch-string-in-source-relation i686 [07:35] Good morning [07:36] doko: yes, I'd prefer that, if they got verified by someone? [07:43] pitti, good morning. i've been reluctant to milestone a bug that i've subscribe ubuntu-release to (bug 274950), but given the amount of churn it will cause if it's done, i'm thinking feedback sooner (before beta would be better), would you agree that i should milestone it in this case so that it shows up on more people's radars? [07:43] Launchpad bug 274950 in obex-data-server "Look into switching to bluez 4.x" [Undecided,In progress] https://launchpad.net/bugs/274950 [07:45] (i'm not trying to queue jump and get you to exert ubuntu-release decisions right now, just whether i should put it into the milestone queue in the first place) [07:47] superm1: I think just pinging slangasek and me will do; right now there seems to be much discussion and testing, and thus too early to make a decision (that was my impression anyway) [07:49] superm1: I don't see this as critical for beta, so we shouldn't risk disrupting the CD prep [07:49] pitti, yeah i just haven't seen any constructive criticisms at this point, so i wanted to make sure it doesn't just show up as a big "surprise" [07:49] slangasek, okay, but you think it will still be feasible to possibly squeeze between beta and release still though? [07:49] superm1: didn't I see a comment in the bug log that the only regression presented as justification for the update could also be addressed by twiddling a conffile and starting hidd? [07:50] I think it's not entirely out of the question [07:50] the testing seems pretty thorough, judging by how often I'm getting bug mail about it :;;-) [07:50] * slangasek thwaps his semicolon key [07:50] slangasek, not that i'm aware. regarding hidd. [07:51] it at least crashes hcid when you pair with a keyboard too, so that would be masking the problem [07:51] or "try" to pair with the keyboard [07:52] ah [07:54] slangasek, something else that i don't see brought up on this bug is that it will bring an soname bump (libbluetooth2->libbluetooth3). should I add tasks for the rebuilding of those applications to ensure that there are no possible compile failures on them with API changes? [07:54] superm1: ah, that would be good, yes [07:54] hi mvo [07:55] slangasek, okay that list of bugmail will grow a bit then :) that'll be a task for tomorrow morning [07:56] * StevenK checks for a list of rdepends [07:57] okay one last question; the old bluez-utils package was providing an initscript called "bluetooth" which is now provided by the "bluez" package. if "bluez-utils" isn't purged and they share the same init script name - that causes complications where you can't purge bluez-utils later. i worked around it by making a new bluetoothd init script instead for the bluez package. upstream prefers to use the same init script name instead though. [07:57] is the proper way to clean up between the two by using a transitional bluez-utils dummy package then? [07:58] superm1: the problem on purge is that the postrm update-rc.d fails? [07:59] slangasek, yup [07:59] transitional bluez-utils package would be ok. Why are we reorganizing binary packages at all, though? [07:59] because that package provides more than just utlities [08:00] it's the whole stack that doesn't need more dependencies sans libbluetooth [08:00] again, that's how upstream wants to see it instead [08:00] that's how it's being implemented in F10 too [08:00] well, F10 package splits are usually crack [08:01] s/F10/Fedora/ [08:01] so I don't think that's a compelling argument for changing the split in Ubuntu [08:02] well it really doesn't make sense to have a separate binary package for a single .so though that has no other dependencies [08:02] eg what bluez-input and bluez-serial etc were [08:03] also how it's being implemented in suse from what I understand too. [08:04] is this change also being made in Debian? I care a lot more about how it's going to affect interdependencies with packages from a distro we actually sync from :) [08:04] debian isn't packaging 4.x for some time [08:04] and godog hasn't been responding to pings about it at all [08:04] so the packaging change isn't coordinated, then :/ [08:04] so perhaps this does make most sense to keep the same binary packages as close to prior as possible [08:05] at least until debian has a decision about how they want to do it [08:05] i'll reorganize it again then tomorrow [08:06] hey dholbach [08:07] There are 39 sources that rdepend on libbluetooth2 [08:07] peanuts [08:07] i [08:07] Hi [08:07] I can pick out 2 from the list that don't build from my dealing with NBS [08:08] StevenK, is that on hardy or intrepid? [08:08] superm1: The latter [08:08] yeesh [08:09] superm1: I have a bunch of scripts that automates most of it [08:09] Can you tell I've been doing NBS stuff for a while? :-P [08:09] i'v tested daily-livre intrepid desktop on (for the forst time for me) raid 1 (nvidia). I had to manually install dmraid on livecd (partition ...), and manually install dmraid on installed system (to boot). SO my question : why dmraid is not automatically installed ? [08:09] superm1: Has the library package in your PPA been bumped to 3? [08:09] StevenK, so can you do a test against libbluetooth-dev from the bluetooth PPA and see which failed? [08:09] StevenK, yeah it has [08:10] superm1: ~bluetooth/+archive ? [08:10] StevenK, yup [08:10] superm1: I'll set it up and kick it off. [08:10] StevenK, thanks, that will be a big help [08:11] superm1: Let me pastebin the list I got, some of them you will update, so I don't need to touch [08:11] StevenK, yeah at this point i can tell you that gnome-user-share, gvfs, obex-data-server and bluez-gnome don't need to be on it [08:11] (i've already touched all of them) [08:12] superm1: http://paste.ubuntu.com/52382/ [08:13] pitti: hmm, not yet applied upstream, lets wait a bit [08:13] StevenK, okay then this list should be reflective of what still needs testing: http://paste.ubuntu.com/52383/ [08:13] superm1: I guess bluez-* can pretty much be ignored. Do you want to dump out the things I don't care about and re-pastebin it? [08:13] kagou: dmraid is on the alternate CD. You can use the alternate CD now to install onto dmraid arrays. Unfortunately the live CD won't get dmraid till Jaunty. [08:14] ok TheMuso. Why not providing dmraid on desktop. It's a very small package :) [08:15] kagou: It has to do with implementing support into the installer. It was relatively easy to do for the alternate CD, but from what I've been told, work has to be done on ubiquity to properly support device-mapper devices, such as dmraid arrays. [08:15] TheMuso, oh I understand. Thanks ! [08:26] Ew. [08:26] Evolution needs a rebuild [08:26] * StevenK quietly sobs === tkamppeter_ is now known as tkamppeter === wgrant_ is now known as wgrant [09:13] seb128: was there a sync request for anjuta? (getting ready to NBS out libgdl-gnome-1.0) [09:14] slangasek: no, I didn't bother filing a bug and just synced directly [09:14] seb128: ok - so it's synced now? [09:14] slangasek: yes, I did it one hour ago [09:14] cool [09:15] hmm, ftbfs though [09:16] seb128: well, I guess you've seen the ftbfs, and it's somewhere in your todo, so I'll kick the gdl NBS out now [09:16] which failed to build grrr, fixing that [09:16] slangasek: yes, stupid scrollkeeper, it built fine locally because I'm using rarian-compat [09:17] oh, so we could fix this by making the scrollkeeper package go away? :) [09:17] I thought we did ages ago? [09:18] pitti: it's still in universe [09:19] oh, I have it installed [09:19] ubuntu-desktop pulls it in [09:19] rarian-compat | 0.8.1-1ubuntu1 | intrepid | amd64, i386 [09:19] ^ maihn [09:19] main, too [09:22] pitti: ubuntu-desktop pulling it in won't make much difference on a buildd though [09:23] right, just noting that I still think it's our current default [09:23] yes, no question of that === dholbach_ is now known as dholbach [09:24] asac: thx for your kind sponsoring ;-) [09:25] slangasek: would you please take a look at bug 274238? [09:25] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/274238/+text) [09:26] ubottu: you have all my sympathy [09:26] Error: I am only a bot, please don't think I'm intelligent :) [09:29] james_w: midori is in universe so it doesn't really require my approval - but if this is xubuntu-affecting, the xubuntu team should have their say [09:29] slangasek: it is, and Michael is a Xubuntu developer, but I can check with the rest of the team. It's on the CDs though I believe, so I thought it was your juristiction. [09:30] ah, I wasn't aware he was xubuntu-dev [09:31] slangasek: so you see no problem? [09:31] james_w: well, I don't think it's a wise decision to push back the xubuntu beta build for this change; but it's not my decision [09:31] is there a way to provide a migration path for changing the priority of an alternative? [09:31] slangasek: ok, I'll talk to them, thank you === pbn_ is now known as pbn [09:46] slangasek: ok. so no NM in beta. perfect. === cjwatson_ is now known as cjwatson [10:48] cjwatson, i have a slight prob with user-setup in ubiquity ... "d-i passwd/auto-login boolean true" doesnt appear to do what i expect [10:49] though i see user-setup-apply DTRT in the code [10:49] but the checkbox in ubiquity isnt set (just doing an install to see if that matters) [10:50] ogra: ubiquity is only checking for passwd/auto-login to set that. [10:50] well, thats what i set [10:52] ogra: It's controlled by ubiquity/components/usersetup.py in ubiquity, if you want to look at the details. [10:53] oh, ok [10:53] so the standard user-setup is ignored ? [10:53] No. ubiquity mitigates user interaction with the standard user-setup. [10:54] ogra: Mind you, it doesn't seem to work for me either, oddly. [10:55] right, I bet ubiquity doesn't check for the preseeded value of that question to initialise the UI [10:55] that sort of thing needs to be done explicitly === giskard_ is now known as giskard [10:55] explicitly eaning not through preseeding here ? [10:55] *meaning [10:55] Looking at the code it seems ubiquity needs to more carefully read the incoming preseed values, and explicity activate them. [10:55] err [10:56] don't try to work out what I meant, I'm partly talking to myself [10:56] persia: umm. sort of. [10:56] how dumb can one possibly be ... [10:56] actually the reason it's tricky is that auto-login isn't explicitly asked by user-setup, but is for preseeding only [10:56] tjaalton, i see a lot of race conditions with hal on the mobile image ... sometimes i dont even get a keyboard (seems to depend on bootspeed) [10:57] ogra: does the mobile image still move the gdm init priority further up? [10:57] cjwatson, so is there a way for me to set it somehow without hacking ubiquity ? [10:57] pitti, i dont touch gdm [10:57] ogra: no, we need to fix ubiquity [11:02] cjwatson, bug 276247 [11:02] Launchpad bug 276247 in ubiquity "preseeding autologin should set the checkbox in the UI" [Undecided,New] https://launchpad.net/bugs/276247 [11:03] thanks [11:03] is this beta-critical? [11:03] since if it is I have to drop everything to do it [11:04] well, it would be a nice to have but after beta should suffice [11:04] yeah, I can't justify nice-to-have uploads right now [11:05] final should have it though [11:06] UMPCs not necessarily have a keyboard and i havent hacked gdm to support cellwriter for password input in this release [11:06] so its critical for final [11:06] easy to fix for final [11:06] I'll show you the patch in a few minutes [11:06] * ogra nominates for intrepid [11:08] * ogra wonders why the wlan gets dropped several times during install [11:08] pitti, it seems to largely depend on CPU speed, while i see it failing only from time to time, persia seems to see that issue constantly [11:09] (my Q1 only has a 800MHz cpu, his is a fast atom) [11:11] persia, what about the installed system ? [11:11] ogra: I haven't tried an installed system: I can't navigate the installer with no keyboard and no mouse. [11:13] hmm [11:13] the builtin kbd doesnt work on the Q1 [11:13] which is kind of fatal without autologin :P [11:13] ugh [11:13] not even a usb kbd does [11:14] oh, fun, i can switch consoles but i cant type anything [11:14] well, only in X apparently [11:15] i can log in at the console [11:15] no kbd ... even after gdm restart [11:16] hmm ... we dont have a milestone for rc [11:16] ogra: That sounds like my experience. [11:16] no mouse either [11:16] milestone it for final - not many things should be RC as distinct from final (i.e. bugs milestoned for final should typically land by RC) [11:17] ok. just thought we had rc milestones in the past [11:17] but makes sense [11:17] RC should be RC bug free ;) [11:19] pitti, hmm, seems hal is completely broken here, it used to work some days ago [11:19] (or X) [11:21] shriek [11:22] who added evtouch to xserver-xorg-input-all ?? [11:22] sigh [11:22] thats not right [11:22] Why not? [11:22] it's in universe last I checked ... [11:22] Ah. That would be a good reason. [11:23] i am trying to install gimp 2.5.4 but i told i need to install gtk along with a million other libraries does ubuntu store libraries somewhere else and do i need to point make to that PATH?? [11:23] roachmmflhyr: This isn't a support channel; you likely want #ubuntu. [11:23] roachmmflhyr: 'sudo apt-get build-dep gimp' will help you alone [11:24] along [11:24] sorry i thought this was support for dev [11:24] no, it isn't [11:24] cjwatson, right, but i just tried to remove it to make sure i didnt break anything with my .fdi files ... it wants to remove all xserver-xorg-input* and -video* pacages [11:24] it's for people developing Ubuntu, not for people developing *on* Ubuntu [11:24] if you catch the distinction [11:25] With recommends-by-default, shouldn't xserver-xorg-*-all be recommending stuff now? [11:25] xserver-xorg depends: xserver-xorg-input-all|xserver-xorg-input-2.1 .... [11:25] evtouch provides -input-2.1 [11:25] persia: no, I don't think so; otherwise the -all would be pretty pointless [11:25] hmm [11:26] and -all isnt installed [11:26] persia: however, you should be able to uninstall {video,input}-all [11:26] pitti: Hrm. OK. [11:26] * ogra guesses he should drop the provides then [11:26] hmm [11:27] Provides: ${xinpdriver:Provides} [11:27] cjwatson, wow so your saying ive wasted 4 hours of my life installing libraries, gtk, cairo, freetype, fontconfig, expat, tiff libs, jpeg libs, png libs, atk, pango, gegl, babl, dbus-glib, glib......? [11:28] well, i actually want it pulled in by -all if somenone installs that ... [11:29] roachmmflhyr: you installed them all from upstream tarballs?? [11:29] pitti, yes [11:29] roachmmflhyr: we have libfoo-dev packages for that [11:29] ah, well, -all doesnt even depend on it [11:30] * ogra giggles evlish [11:30] persia, found the prob :P [11:30] elvish? [11:30] pitti, they werent working...when i ran ./configure in the package i was trying to install it said it couldnt find the libraries [11:30] Treenaks, isnt that the same (according to terry pratchett at least :P) [11:31] superm1: I think libbluetooth-dev should provide libbluetooth2-dev too [11:31] persia, seems the task change for ubuntu-mobile is at fault [11:31] pitti, there isnt a libfoo for gegl [11:31] pitti, sorry, not hals fault at all [11:31] ogra: That explains why I wasn't seeing it with other flavours. [11:31] roachmmflhyr: libgegl-0.0-dev [11:32] persia, the only xserver-xorg-input-* package thats installed *is* evtouch [11:32] no keyboard or touchpad drivers [11:32] ogra: Yeah. That's not ideal :) [11:32] roachmmflhyr: "apt-cache search gegl dev" is your friend, or use synaptic (the graphical package manager) [11:32] yay for provides [11:32] but i thought we install the xorg metapackage [11:33] * ogra changes seeds [11:33] roachmmflhyr: I expect it would have been a lot easier to figure out why it wasn't finding the system libraries (e.g. config.log) than to spend hours installing libraries by hand [11:33] cjwatson, i did check the config.log it told me certain libraries werent found [11:33] cjwatson, so i googled for them [11:34] remember that we build gimp by installing libraries from .debs, so we know it can be made to work [11:34] pitti, apt-cache search gegl dev gives me nothing... :( [11:34] anyway, not this channel [11:35] We only have gegl in Intrepid. [11:35] cjwatson, well thats what im trying to learn how to do...i would like to become a dev for ubuntu...but i need to figure everything out [11:36] roachmmflhyr: ok, that's fine - one of the skills you need is to learn how to troubleshoot problems without going off and installing gtk from source, though :) [11:36] cjwatson, lol i see that now [11:36] roachmmflhyr, #ubuntu-motu might be a better choice for such discussions (its at least less off topic there) [11:36] usually you need to find the code that's failing, drill down, and run it by hand with added verbosity or debugging or whatever [11:37] cjwatson, at least ive gotten real good at compiling source... [11:37] lol [11:37] roachmmflhyr: 2.4.5 is available in hardy. Are you not using hardy (Ubuntu 8.04)? [11:38] slytherin, yes i was using that...but i was feeling a bit frisky and wanted to test out some stuff [11:38] slytherin, kinda sucks that gimp doesnt support CMYK coloring [11:39] slytherin, thats one of the reasons i was trying 2.5 [11:39] ok [11:39] how are we supposed to use usbfs with Intrepid now? [11:39] VBox still requires it... [11:41] alex-weej: /dev/bus/usb? [11:41] old-style /proc i guess [11:41] alex-weej: or does it need the counterpart of /proc/bus/usb/devices? [11:41] devices file in proc [11:42] yes [11:42] i have tried following some "guides" people have posted but none of them are working and i'm wondering if something changed in 8.10 [11:44] ah i may have figured it... let's see [11:44] meh, i get weird germinate errors [11:45] cjwatson, any idea ? http://paste.ubuntu.com/52421/ [11:45] i get that running the update script in mobile-meta [11:45] oh, wait ... probably Packages are just regenerated [11:46] * ogra waits a moment to try again [11:46] ogra: http://paste.ubuntu.com/52423/ is the auto-login fix, FYI [11:46] yeah, that suggests unlucky timing [11:47] ah, neat ... seems small enough [11:48] pitti: the hal/f-spot stuff seems to work, thanks very much for fixing that :) [11:55] hmm, how do i revert ownership in a metapackage the right way if someone ran sudo ./update [11:56] just chown it [11:56] ok [11:57] just wanted to make sure people dont need to be ogra in the future if they update :) [11:58] and that also made ./update work again :) [11:58] you realise that that sort of ownership change doesn't get preserved in souece packages? [11:58] source [11:58] well, root did though [11:58] only if you unpack as root [11:59] i didnt [11:59] a user cannot create files owned by root so it would be physically impossible for that change to be preserved [11:59] but my predecessor i guess [11:59] apt-get source mobile-meta && cd mobile-meta-1.118 && ./update [12:00] thats all i did [12:00] any Unix system that supports quotas either forbids non-root chowning to other users, or else has a very obvious security hole :) [12:00]