[00:06] <slangasek> kees: #273761> yeah, that ought to get in
[00:08] <kees> slangasek: okay, it's uploaded and waiting for you.  :)
[00:09] <slangasek> yep, seen :)
[00:09] <slangasek> seb128: I don't see gnome-build in the queue; did someone already accept it?
[00:09] <seb128> slangasek: apparently yes, there was a batch of updates accepted a few minutes after I asked apparently
[00:09] <slangasek> 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] <cjwatson> slangasek: I did an accept-everything-for-universe pass which included gnome-build
[00:10] <slangasek> ah, sure
[00:10] <slangasek> thanks :)
[00:13] <asac> slangasek: i think that secret issue should be fixed now
[00:14] <slangasek> asac: in your current upload, you mean?
[00:14] <asac> slangasek: yes.
[00:14] <slangasek> cool
[00:14] <asac> slangasek: there was definitly an issue in the applet with regards to writing secrets which is in the diff
[00:14] <slangasek> ah; as far as I could tell it was an issue reading, not writing, the secret
[00:15] <slangasek> (at least, I saw the secret was written to a file)
[00:15] <TheMuso> 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] <asac> slangasek: +               - (nm_gconf_write_connection, write_one_secret_to_keyring): split out
[00:16] <asac> +                       writing of secrets into it's own function for clarity.  Fixes a
[00:16] <asac> +                       regression introduced in r875 where secrets wouldn't get saved.
[00:16] <asac> slangasek: oops ;)
[00:16] <slangasek> ok
[00:16] <asac> TheMuso: i tried it a bit ... my sound worked nicely
[00:17] <asac> TheMuso: (after removing my asoundrc ... which should be enough?)
[00:17] <TheMuso> asac: Right, I'll have to keep digging then.
[00:17] <doko> 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] <slangasek> calc: so OOo is ftbfs on all !x86 right now?
[00:18] <doko> slangasek: please accept ant and libxerces2-java
[00:19] <slangasek> doko: is there an associated, beta-blocking bug?
[00:20] <doko> slangasek, calc: I did talk with calc about powerpc; didn't look at sparc yet
[00:20] <doko> slangasek: yes, mentioned in the changelog
[00:20] <slangasek> doko: but, notably, not tracked on https://bugs.launchpad.net/ubuntu/intrepid/+bugs?field.milestone=1325 ? :)
[00:21] <doko> https://bugs.edge.launchpad.net/ubuntu/+source/ant/+bug/264808
[00:22] <doko> milestone is ubuntu-8.10-beta
[00:22] <doko> what did I miss?
[00:23] <slangasek> 'target to release'
[00:27] <doko> nominate?
[00:28] <wgrant> Due to an LP bug, yes.
[00:29] <cjwatson> it's "nominate for release" if you aren't in ubuntu-drivers or ubuntu-release or whatever team it is
[00:29] <doko> wgrant: is this LP bug filed?
[00:29] <cjwatson> wgrant: what LP bug?
[00:29] <cjwatson> just that the text is different?
[00:30] <slangasek> TheMuso: hrm, after my latest reboot, audio seems to have regressed somewhere for me; is this a known issue?
[00:30] <wgrant> doko: I don't think so.
[00:30] <wgrant> cjwatson: Right - it only checks if you're a driver, but there are special privileges for distros.
[00:31] <doko> no, I was surprised that just setting the milestone is not enough
[00:31] <wgrant> Only the text is wrong, however.
[00:31] <cjwatson> doko: http://wiki.ubuntu.com/RCBugTargetting
[00:31] <cjwatson> that part at least is not an LP bug, it's intentional
[00:31] <cjwatson> "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] <cjwatson> and this was because developers not on the release team asked for this
[00:32] <doko> ok, wasn't aware about the history
[00:32] <cjwatson> the idea is that targeted + milestoned == release-critical for milestone, not targeted + milestoned == developer planning own work but might slip
[00:35] <TheMuso> slangasek: What were you trying to play audio with, and how were things set up?
[00:35] <slangasek> 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] <TheMuso> 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] <slangasek> ok
[00:37] <slangasek> is there a bug number for this?
[00:37] <TheMuso> slangasek: in gnome-sound-properties, you are using pulseaudio or auto detect are you not?
[00:37] <TheMuso> slangasek: one sec, I'll fetch.
[00:38] <slangasek> autodetect
[00:38] <slangasek> shall I try to hard-code to pa?
[00:39] <slangasek> ah, the 'test' button gives me: 'audiotestsrc wave=sine freq=512 ! audioconvert ! audioresample ! gconfaudiosink: Failed to connect stream: Invalid argument
[00:39] <slangasek> '
[00:40] <doko> slangasek: did nominate the bug
[00:40] <slangasek> doko: thanks
[00:40] <TheMuso> slangasek: I think bug 274124 is the most relevant.
[00:40] <TheMuso> slangasek: there is a libasound2-plugins package I linked to in that bug, install that and see if that helps you.
[00:41] <slangasek> TheMuso: hmmm, I can neither confirm nor deny that this was my first reboot to 2.6.27-4
[00:41] <TheMuso> It sounds like autodetect for most people is defaulting to alsa which then attempts to use the alsa pulse plugin.
[00:41] <TheMuso> slangasek: I am almost 100% sure it is not kernel related, but the bug reporter thought it was.
[00:41] <slangasek> well, I get the same error with the 'test' button if I manually select pulseaudio instead of autodetect
[00:41] <TheMuso> I think I even said as much in the bug./
[00:41] <crimsun> it's not related to the kernel; it's an alsa-plugins issue.
[00:43] <TheMuso> crimsun: but alsa-plugins doesn't make sense for straight pulse not working...
[00:44] <crimsun> 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] <slangasek> ok, here's what I have in the log:
[00:45] <slangasek> Sep 29 15:53:36 dario pulseaudio[7368]: alsa-util.c: Error opening PCM device hw:0: Device or resource busy
[00:45] <slangasek> 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] <TheMuso> slangasek: SOunds like you have something else that is holding the hardware open, and pulse hasn;'t been able to grab itr.
[00:45] <slangasek> nothing else has the hardware open at this point
[00:45] <slangasek> $ sudo fuser -v /dev/dsp  /dev/snd/pcmC0D*
[00:45] <slangasek> $
[00:45] <TheMuso> hrm.
[00:46] <crimsun> if so, then you should be able to restart pulseaudio from the cli successfully
[00:46] <slangasek> if I kill and restart pulseaudio, it works,y es
[00:48] <slangasek> so: device contention at login time, wih the startup sounds?
[00:48] <TheMuso> slangasek: Do you happen to have any .asoundrc files in your home directory?
[00:49] <slangasek> yes
[00:49] <slangasek> (for trying to configure bluetooth audio)
[00:49] <TheMuso> Ah ok.
[00:49] <TheMuso> Try moving them away for now...
[00:50] <TheMuso> they probably may have somethign to do with it, depending on whether they alter the default device used.
[00:50] <slangasek> they don't
[00:50] <TheMuso> ok they shouldn't be a problem then.
[00:50] <slangasek> do you still want me to try moving it aside, and re-logging in?
[00:51] <TheMuso> No if they don't alter the default device used I don't think they are a problem.
[01:49] <slangasek> asac: how thoroughly has this NM build been tested?  it's a rather large change to drop this close to beta
[02:50] <calc> slangasek: it did build on amd64/lpia last time i built it from what i recall
[02:50]  * calc looks at the build logs
[02:51] <calc> slangasek: yea it builds on the supported archs :\
[02:51] <calc> 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] <calc> slangasek: hppa doesn't work at all, its unsupported platform
[02:51] <calc> er unsupported all around i mean, not by sun/go-oo/us etc
[02:52] <calc> not sure about the ia64/sparc issue will have to see if it is due to the same basic problem affecting powerpc
[02:52] <calc> but sparc generally doesn't build OOo either, it has failed nearly every time generally in ICEs
[02:56] <TheMuso> calc: I'm happy to do a test build of OpenOffice on PowerPC again if that is of any help...
[02:56] <calc> TheMuso: the problem was it couldn't find libjawt and i think i know how to fix it properly now
[02:57] <calc> TheMuso: i missed a patch that was needed when adding support for openjdk
[02:57] <TheMuso> calc: Ah ok.
[02:57] <calc> slangasek: ia64 fails due to what seems like is probably an openjdk issue
[02:58] <calc> "error (RuntimeException): [jni_uno bridge error] UNO calling Java method initialize: java.lang.StackOverflowError"
[02:58] <asac> slangasek: well. beta is supposed to bring the testing.
[02:59] <calc> 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] <asac> slangasek: the core features (wired and wifi) are unlikely to have regressed much
[03:03] <asac> slangasek: there is one known regression ... it sets the hostname to localehost.localdomain in /etc/hosts
[03:04] <asac> that is because we are lacking a system integration part that reads /etc/hostname
[03:04] <asac> 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] <asac> (from me -> upstreamed)
[03:32] <ScottK> 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:52] <slangasek> calc: yes, amd64 and lpia are also "x86" :)
[03:53] <calc> slangasek: ok so yea more or less :)
[03:54] <slangasek> 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] <calc> 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] <calc> so yep x86 is about all OOo will work on
[03:55] <slangasek> 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] <slangasek> ScottK: thanks, demoted
[04:39] <calc> ok i think i have the patch that should help for powerpc and sparc
[04:41] <calc> 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] <calc> 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
[05:54] <slangasek> calc: hum, yeah, let's hold off on the OOo powerpc/sparc fix
[06:10] <dholbach> good morning
[06:59] <slytherin> ﻿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] <pitti> Good morning
[07:36] <pitti> doko: yes, I'd prefer that, if they got verified by someone?
[07:43] <superm1> 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:45] <superm1> (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] <pitti> 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] <slangasek> superm1: I don't see this as critical for beta, so we shouldn't risk disrupting the CD prep
[07:49] <superm1> 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] <superm1> slangasek, okay, but you think it will still be feasible to possibly squeeze between beta and release still though?
[07:49] <slangasek> 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] <slangasek> I think it's not entirely out of the question
[07:50] <slangasek> 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] <superm1> slangasek, not that i'm aware.  regarding hidd.
[07:51] <superm1> it at least crashes hcid when you pair with a keyboard too, so that would be masking the problem
[07:51] <superm1> or "try" to pair with the keyboard
[07:52] <slangasek> ah
[07:54] <superm1> 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] <slangasek> superm1: ah, that would be good, yes
[07:54] <dholbach> hi mvo
[07:55] <superm1> 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] <superm1> 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] <superm1> is the proper way to clean up between the two by using a transitional bluez-utils dummy package then?
[07:58] <slangasek> superm1: the problem on purge is that the postrm update-rc.d fails?
[07:59] <superm1> slangasek, yup
[07:59] <slangasek> transitional bluez-utils package would be ok.  Why are we reorganizing binary packages at all, though?
[07:59] <superm1> because that package provides more than just utlities
[08:00] <superm1> it's the whole stack that doesn't need more dependencies sans libbluetooth
[08:00] <superm1> again, that's how upstream wants to see it instead
[08:00] <superm1> that's how it's being implemented in F10 too
[08:00] <slangasek> well, F10 package splits are usually crack
[08:01] <slangasek> s/F10/Fedora/
[08:01] <slangasek> so I don't think that's a compelling argument for changing the split in Ubuntu
[08:02] <superm1> 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] <superm1> eg what bluez-input and bluez-serial etc were
[08:03] <superm1> also how it's being implemented in suse from what I understand too.
[08:04] <slangasek> 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] <superm1> debian isn't packaging 4.x for some time
[08:04] <superm1> and godog hasn't been responding to pings about it at all
[08:04] <slangasek> so the packaging change isn't coordinated, then :/
[08:04] <superm1> so perhaps this does make most sense to keep the same binary packages as close to prior as possible
[08:05] <superm1> at least until debian has a decision about how they want to do it
[08:05] <superm1> i'll reorganize it again then tomorrow
[08:06] <mvo> hey dholbach
[08:07] <StevenK> There are 39 sources that rdepend on libbluetooth2
[08:07] <slangasek> peanuts
[08:07] <kagou> i
[08:07] <kagou> Hi
[08:07] <StevenK> I can pick out 2 from the list that don't build from my dealing with NBS
[08:08] <superm1> StevenK, is that on hardy or intrepid?
[08:08] <StevenK> superm1: The latter
[08:08] <superm1> yeesh
[08:09] <StevenK> superm1: I have a bunch of scripts that automates most of it
[08:09] <StevenK> Can you tell I've been doing NBS stuff for a while? :-P
[08:09] <kagou> 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] <StevenK> superm1: Has the library package in your PPA been bumped to 3?
[08:09] <superm1> StevenK, so can you do a test against libbluetooth-dev from the bluetooth PPA and see which failed?
[08:09] <superm1> StevenK, yeah it has
[08:10] <StevenK> superm1: ~bluetooth/+archive ?
[08:10] <superm1> StevenK, yup
[08:10] <StevenK> superm1: I'll set it up and kick it off.
[08:10] <superm1> StevenK, thanks, that will be a big help
[08:11] <StevenK> superm1: Let me pastebin the list I got, some of them you will update, so I don't need to touch
[08:11] <superm1> 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] <superm1> (i've already touched all of them)
[08:12] <StevenK> superm1: http://paste.ubuntu.com/52382/
[08:13] <doko> pitti: hmm, not yet applied upstream, lets wait a bit
[08:13] <superm1> StevenK, okay then this list should be reflective of what still needs testing: http://paste.ubuntu.com/52383/
[08:13] <StevenK> 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] <TheMuso> 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] <kagou> ok TheMuso. Why not providing dmraid on desktop. It's a very small package :)
[08:15] <TheMuso> 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] <kagou> TheMuso, oh I understand. Thanks !
[08:26] <StevenK> Ew.
[08:26] <StevenK> Evolution needs a rebuild
[08:26]  * StevenK quietly sobs
[09:13] <slangasek> seb128: was there a sync request for anjuta? (getting ready to NBS out libgdl-gnome-1.0)
[09:14] <seb128> slangasek: no, I didn't bother filing a bug and just synced directly
[09:14] <slangasek> seb128: ok - so it's synced now?
[09:14] <seb128> slangasek: yes, I did it one hour ago
[09:14] <slangasek> cool
[09:15] <slangasek> hmm, ftbfs though
[09:16] <slangasek> 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] <seb128> which failed to build grrr, fixing that
[09:16] <seb128> slangasek: yes, stupid scrollkeeper, it built fine locally because I'm using rarian-compat
[09:17] <slangasek> oh, so we could fix this by making the scrollkeeper package go away? :)
[09:17] <pitti> I thought we did ages ago?
[09:18] <seb128> pitti: it's still in universe
[09:19] <pitti> oh, I have it installed
[09:19] <pitti> ubuntu-desktop pulls it in
[09:19] <pitti> rarian-compat | 0.8.1-1ubuntu1 |      intrepid | amd64, i386
[09:19] <pitti> ^ maihn
[09:19] <pitti> main, too
[09:22] <slangasek> pitti: ubuntu-desktop pulling it in won't make much difference on a buildd though
[09:23] <pitti> right, just noting that I still think it's our current default
[09:23] <slangasek> yes, no question of that
[09:24] <norsetto> asac: thx for your kind sponsoring ;-)
[09:25] <james_w> slangasek: would you please take a look at bug 274238?
[09:26] <norsetto> ubottu: you have all my sympathy
[09:29] <slangasek> 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] <james_w> 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] <slangasek> ah, I wasn't aware he was xubuntu-dev
[09:31] <james_w> slangasek: so you see no problem?
[09:31] <slangasek> 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] <james_w> is there a way to provide a migration path for changing the priority of an alternative?
[09:31] <james_w> slangasek: ok, I'll talk to them, thank you
[09:46] <asac> slangasek: ok. so no NM in beta. perfect.
[10:48] <ogra> 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] <ogra> though i see user-setup-apply DTRT in the code
[10:49] <ogra> but the checkbox in ubiquity isnt set (just doing an install to see if that matters)
[10:50] <persia> ogra: ubiquity is only checking for passwd/auto-login to set that.
[10:50] <ogra> well, thats what i set
[10:52] <persia> ogra: It's controlled by ubiquity/components/usersetup.py in ubiquity, if you want to look at the details.
[10:53] <ogra> oh, ok
[10:53] <ogra> so the standard user-setup is ignored ?
[10:53] <persia> No.  ubiquity mitigates user interaction with the standard user-setup.
[10:54] <persia> ogra: Mind you, it doesn't seem to work for me either, oddly.
[10:55] <cjwatson> right, I bet ubiquity doesn't check for the preseeded value of that question to initialise the UI
[10:55] <cjwatson> that sort of thing needs to be done explicitly
[10:55] <ogra> explicitly eaning not through preseeding here ?
[10:55] <ogra> *meaning
[10:55] <persia> Looking at the code it seems ubiquity needs to more carefully read the incoming preseed values, and explicity activate them.
[10:55] <cjwatson> err
[10:56] <cjwatson> don't try to work out what I meant, I'm partly talking to myself
[10:56] <cjwatson> persia: umm. sort of.
[10:56] <norsetto> how dumb can one possibly be ...
[10:56] <cjwatson> actually the reason it's tricky is that auto-login isn't explicitly asked by user-setup, but is for preseeding only
[10:56] <ogra> 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] <pitti> ogra: does the mobile image still move the gdm init priority further up?
[10:57] <ogra> cjwatson, so is there a way for me to set it somehow without hacking ubiquity ?
[10:57] <ogra> pitti, i dont touch gdm
[10:57] <cjwatson> ogra: no, we need to fix ubiquity
[11:02] <ogra> cjwatson, bug 276247
[11:03] <cjwatson> thanks
[11:03] <cjwatson> is this beta-critical?
[11:03] <cjwatson> since if it is I have to drop everything to do it
[11:04] <ogra> well, it would be a nice to have but after beta should suffice
[11:04] <cjwatson> yeah, I can't justify nice-to-have uploads right now
[11:05] <ogra> final should have it though
[11:06] <ogra> UMPCs not necessarily have a keyboard and i havent hacked gdm to support cellwriter for password input in this release
[11:06] <ogra> so its critical for final
[11:06] <cjwatson> easy to fix for final
[11:06] <cjwatson> 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] <ogra> 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] <ogra> (my Q1 only has a 800MHz cpu, his is a fast atom)
[11:11] <ogra> persia, what about the installed system ?
[11:11] <persia> ogra: I haven't tried an installed system: I can't navigate the installer with no keyboard and no mouse.
[11:13] <ogra> hmm
[11:13] <ogra> the builtin kbd doesnt work on the Q1
[11:13] <ogra> which is kind of fatal without autologin :P
[11:13] <ogra> ugh
[11:13] <ogra> not even a usb kbd does
[11:14] <ogra> oh, fun, i can switch consoles but i cant type anything
[11:14] <ogra> well, only in X apparently
[11:15] <ogra> i can log in at the console
[11:15] <ogra> no kbd ... even after gdm restart
[11:16] <asac> hmm ... we dont have a milestone for rc
[11:16] <persia> ogra: That sounds like my experience.
[11:16] <ogra> no mouse either
[11:16] <cjwatson> 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] <asac> ok. just thought we had rc milestones in the past
[11:17] <asac> but makes sense
[11:17] <asac> RC should be RC bug free ;)
[11:19] <ogra> pitti, hmm, seems hal is completely broken here, it used to work some days ago
[11:19] <ogra> (or X)
[11:21] <ogra> shriek
[11:22] <ogra> who added evtouch to xserver-xorg-input-all ??
[11:22] <ogra> sigh
[11:22] <ogra> thats not right
[11:22] <persia> Why not?
[11:22] <cjwatson> it's in universe last I checked ...
[11:22] <persia> Ah.  That would be a good reason.
[11:23] <roachmmflhyr> 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] <wgrant> roachmmflhyr: This isn't a support channel; you likely want #ubuntu.
[11:23] <cjwatson> roachmmflhyr: 'sudo apt-get build-dep gimp' will help you alone
[11:24] <cjwatson> along
[11:24] <roachmmflhyr> sorry i thought this was support for dev
[11:24] <cjwatson> no, it isn't
[11:24] <ogra> 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] <cjwatson> it's for people developing Ubuntu, not for people developing *on* Ubuntu
[11:24] <cjwatson> if you catch the distinction
[11:25] <persia> With recommends-by-default, shouldn't xserver-xorg-*-all be recommending stuff now?
[11:25] <ogra> xserver-xorg depends: xserver-xorg-input-all|xserver-xorg-input-2.1 ....
[11:25] <ogra> evtouch provides -input-2.1
[11:25] <pitti> persia: no, I don't think so; otherwise the -all would be pretty pointless
[11:25] <ogra> hmm
[11:26] <ogra> and -all isnt installed
[11:26] <pitti> persia: however, you should be able to uninstall {video,input}-all
[11:26] <persia> pitti: Hrm.  OK.
[11:26]  * ogra guesses he should drop the provides then 
[11:26] <ogra> hmm
[11:27] <ogra> Provides: ${xinpdriver:Provides}
[11:27] <roachmmflhyr> 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] <ogra> well, i actually want it pulled in by -all if somenone installs that ...
[11:29] <pitti> roachmmflhyr: you installed them all from upstream tarballs??
[11:29] <roachmmflhyr> pitti, yes
[11:29] <pitti> roachmmflhyr: we have libfoo-dev packages for that
[11:29] <ogra> ah, well, -all doesnt even depend on it
[11:30]  * ogra giggles evlish
[11:30] <ogra> persia, found the prob :P
[11:30] <Treenaks> elvish?
[11:30] <roachmmflhyr> 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] <ogra> Treenaks, isnt that the same (according to terry pratchett at least :P)
[11:31] <StevenK> superm1: I think libbluetooth-dev should provide libbluetooth2-dev too
[11:31] <ogra> persia, seems the task change for ubuntu-mobile is at fault
[11:31] <roachmmflhyr> pitti, there isnt a libfoo for gegl
[11:31] <ogra> pitti, sorry, not hals fault at all
[11:31] <persia> ogra: That explains why I wasn't seeing it with other flavours.
[11:31] <pitti> roachmmflhyr: libgegl-0.0-dev
[11:32] <ogra> persia, the only xserver-xorg-input-* package thats installed *is* evtouch
[11:32] <ogra> no keyboard or touchpad drivers
[11:32] <persia> ogra: Yeah.  That's not ideal :)
[11:32] <pitti> roachmmflhyr: "apt-cache search gegl dev" is your friend, or use synaptic (the graphical package manager)
[11:32] <ogra> yay for provides
[11:32] <ogra> but i thought we install the xorg metapackage
[11:33]  * ogra changes seeds
[11:33] <cjwatson> 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] <roachmmflhyr> cjwatson, i did check the config.log it told me certain libraries werent found
[11:33] <roachmmflhyr> cjwatson, so i googled for them
[11:34] <cjwatson> remember that we build gimp by installing libraries from .debs, so we know it can be made to work
[11:34] <roachmmflhyr> pitti, apt-cache search gegl dev gives me nothing... :(
[11:34] <cjwatson> anyway, not this channel
[11:35] <wgrant> We only have gegl in Intrepid.
[11:35] <roachmmflhyr> 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] <cjwatson> 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] <roachmmflhyr> cjwatson, lol i see that now
[11:36] <ogra> roachmmflhyr, #ubuntu-motu might be a better choice for such discussions (its at least less off topic there)
[11:36] <cjwatson> 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] <roachmmflhyr> cjwatson, at least ive gotten real good at compiling source...
[11:37] <roachmmflhyr> lol
[11:37] <slytherin> roachmmflhyr: 2.4.5 is available in hardy. Are you not using hardy (Ubuntu 8.04)?
[11:38] <roachmmflhyr> slytherin, yes i was using that...but i was feeling a bit frisky and wanted to test out some stuff
[11:38] <roachmmflhyr> slytherin, kinda sucks that gimp doesnt support CMYK coloring
[11:39] <roachmmflhyr> slytherin, thats one of the reasons i was trying 2.5
[11:39] <slytherin> ok
[11:39] <alex-weej> how are we supposed to use usbfs with Intrepid now?
[11:39] <alex-weej> VBox still requires it...
[11:41] <pitti> alex-weej: /dev/bus/usb?
[11:41] <alex-weej> old-style /proc i guess
[11:41] <pitti> alex-weej: or does it need the counterpart of /proc/bus/usb/devices?
[11:41] <alex-weej> devices file in proc
[11:42] <alex-weej> yes
[11:42] <alex-weej> 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] <alex-weej> ah i may have figured it... let's see
[11:44] <ogra> meh, i get weird germinate errors
[11:45] <ogra> cjwatson, any idea ? http://paste.ubuntu.com/52421/
[11:45] <ogra> i get that running the update script in mobile-meta
[11:45] <ogra> oh, wait ... probably Packages are just regenerated
[11:46]  * ogra waits a moment to try again
[11:46] <cjwatson> ogra: http://paste.ubuntu.com/52423/ is the auto-login fix, FYI
[11:46] <cjwatson> yeah, that suggests unlucky timing
[11:47] <ogra> ah, neat ... seems small enough
[11:48] <Ng> pitti: the hal/f-spot stuff seems to work, thanks very much for fixing that :)
[11:55] <ogra> hmm, how do i revert ownership in a metapackage the right way if someone ran sudo ./update
[11:56] <cjwatson> just chown it
[11:56] <ogra> ok
[11:57] <ogra> just wanted to make sure people dont need to be ogra in the future if they update :)
[11:58] <ogra> and that also made ./update work again :)
[11:58] <cjwatson> you realise that that sort of ownership change doesn't get preserved in souece packages?
[11:58] <cjwatson> source
[11:58] <ogra> well, root did though
[11:58] <cjwatson> only if you unpack as root
[11:59] <ogra> i didnt
[11:59] <cjwatson> a user cannot create files owned by root so it would be physically impossible for that change to be preserved
[11:59] <ogra> but my predecessor i guess
[11:59] <ogra> apt-get source mobile-meta && cd mobile-meta-1.118 && ./update
[12:00] <ogra> thats all i did
[12:00] <cjwatson> any Unix system that supports quotas either forbids non-root chowning to other users, or else has a very obvious security hole :)
[12:00] <ogra> the package already had all files owned by root
[12:00] <StevenK> ogra: 1.118?
[12:00] <ogra> yes
[12:00] <StevenK> ogra: Then it wasn't me
[12:00] <StevenK> My tarball of 1.118 has steven/users
[12:00] <cjwatson> <cjwatson@sarantium ~>$ apt-get source mobile-meta
[12:00] <cjwatson> dpkg-source: info: unpacking mobile-meta_1.118.tar.gz
[12:00] <cjwatson> <cjwatson@sarantium ~>$ cd mobile-meta-1.118/
[12:01] <cjwatson> <cjwatson@sarantium ~/mobile-meta-1.118>$ ls -l mobile-i386
[12:01] <cjwatson> -rw-r--r-- 1 cjwatson cjwatson 1699 2008-09-27 07:40 mobile-i386
[12:01] <StevenK> ogra: You looz.
[12:01] <ogra> mobile-meta (1.118) intrepid; urgency=low
[12:01] <ogra>   * Have ubuntu-mid Conflicts against xfce4-panel. (LP: #274825)
[12:01] <ogra>  -- Steve Kowalik <stevenk@ubuntu.com>  Sat, 27 Sep 2008 18:34:23 +1000
[12:01] <cjwatson> ogra: it's a local problem on your system. or else you're unpacking as root.
[12:01] <ogra> i dont
[12:01] <ogra> definately
[12:02] <cjwatson> pastebin a transcript that demonstrates the problem
[12:02] <StevenK> ogra: Well, I didn't do it
[12:02] <jcristau> alias ls='fakeroot ls'
[12:03] <ogra> cjwatson, i did the above triplet and ran into the update-metapackage.py error i pasted ... after some looking i recognized all files are owned by root ... i am not root and didnt sudo
[12:03] <cjwatson> ogra: in any case, it doesn't really matter since nobody else's system is broken this way, as far as I know
[12:04] <cjwatson> ogra: do you understand why I'm saying this can't happen on a properly functioning system?
[12:04] <ogra> well, essintially i found it because rm -rf mobile-meta-1.118 complained
[12:04] <ogra> cjwatson, i do, but why did it happen then :)
[12:04] <slytherin> seb128: Can you please take a look at the debdiff attached to bug #260765 when you have time.
[12:05] <cjwatson> ogra: that's why I'm trying to get you to *investigate your local system*
[12:05] <cjwatson> only you can debug this
[12:05] <cjwatson> for example, 'touch new-file; ls -l new-file'
[12:05]  * ogra doesnt want to stop the working ./update atm
[12:05] <ogra> i'll investigate afterwards
[12:05] <cjwatson> or 'touch new-file; chown root new-file' which should return an error
[12:05]  * StevenK blinks at two symlinks in his home dir
[12:05] <StevenK> lrwxrwxrwx 1 steven users 1 2008-05-13 00:41 a -> b
[12:05] <StevenK> lrwxrwxrwx 1 steven users 1 2008-05-13 00:41 b -> a
[12:06] <ogra> ogra@osiris:~/Devel/packages$ touch new-file; LANG=C chown root new-file
[12:06] <ogra> chown: changing ownership of `new-file': Operation not permitted
[12:06] <ogra> seems its all fne
[12:06] <ogra> *fine
[12:06] <seb128> slytherin: after beta, such uploads will not be accepted now for beta so there is no hurry
[12:07] <ogra> hrm
[12:07] <ogra> and newly unpacking the source doesnt expose that either
[12:08] <slytherin> seb128: Ok. I thought that since we were not updating to pre-release the backported fix would be acceptable.
[12:09] <ogra> ok, i ran: sudo apt-get update ... and out of lazyness i replaced s/update/source mobile-meta/
[12:09] <ogra> StevenK, sorry
[12:10] <ogra> my own fault
[12:10] <StevenK> Heh
[12:13] <seb128> slytherin: it's a bit late for changes now, doing updates require to rebuild CD images, restart testing for the new images etc
[12:13] <seb128> slytherin: the bug is not really an import one for beta
[12:15] <slytherin> seb128: right, I forgot about the CD images. No issues. Meanwhile I will backport the resindvd changes also in my PPA so both are ready with some testing and can be uploaded post beta.
[12:34] <ogra> cjwatson, can you let mobile-meta through once you find time (no hurry, need to get susie to a doctors appointment now anyway)
[12:37] <cjwatson> ogra: done
[12:44] <stgraber> stgraber@castiana:~$ xterm
[12:44] <stgraber> No protocol specified
[12:44] <stgraber> xterm Xt error: Can't open display: :0.0
[12:44] <stgraber> asac: ^ could that be your fault ? :)
[12:44] <asac> stgraber: yeah. ppa has the fix
[12:45] <stgraber> I just updated from the PPA
[12:45] <asac> stgraber: version?
[12:45] <stgraber> 0.7~~svn20080928t225540+eni0-0ubuntu2~nm1
[12:45] <asac> stgraber: did you properly restart everything?
[12:45] <stgraber> I also restarted NM (kill all process and restart it in init.d) and killed my X session
[12:45] <cjwatson> that NM bug isn't in intrepid is it?
[12:46] <asac> cjwatson: no
[12:46] <cjwatson> good :)
[12:46] <asac> not in
[12:46] <asac> stgraber: is your hostname correct?
[12:48] <stgraber> /etc/hostname is castiana, so that's correct. I just scped a /etc/hosts from a hardy computer and replaced my computer name in it so this one should be good now too.
[12:48] <stgraber> I'll just restart NM again and hope it doesn't destroy it :)
[12:48] <asac> stgraber: no /etc/hosts
[12:52] <stgraber> asac: didn't work ... as soon as NM connected to the wireless network I lost the ability to start new X applications
[12:52] <asac> stgraber: so what does "hostname" commadn give you?
[12:53] <stgraber> castiana.local (instead of castiana)
[12:56] <asac> stgraber: so the nm1 version worked better?
[12:56] <stgraber> when was nm1 released ?
[12:57] <stgraber> hmm, nm1 is what I have :)
[12:57] <asac> stgraber: ok ... anyway. you get "from address lookup" ?
[12:57] <asac> in the syslog?
[12:58] <stgraber> Sep 30 07:55:18 castiana NetworkManager: <info>  Setting system hostname to 'castiana.local' (from address lookup)
[13:01] <asac> stgraber: castiana.local ... what IP is that?
[13:01] <asac> i guess 127.0.0.1?
[13:01] <Ng> it should be his LAN IP
[13:01] <Ng> .local is zeroconf/bonjour jazz
[13:02] <asac> right
[13:02] <Ng> so his mdns name would now either not work, or be castiana.local.local or something like that ;)
[13:03] <asac> so changing hostname _after_ login will always break X or only if you change the hostname in a way that it resolves to a different IP?
[13:04] <stgraber> asac: yes
[13:04] <stgraber> stgraber@castiana:~$ ping castiana.local
[13:04] <stgraber> PING castiana.local (127.0.0.1) 56(84) bytes of data.
[13:04] <asac> stgraber: and when you log in its castiana which also is 127.0.0.1 right?
[13:05] <stgraber> yes
[13:05] <Ng> ehh, a 127 .local address makes no sense
[13:05] <stgraber> and xauth shows castiana/unix:0
[13:05] <stgraber> adding castiana.local/unix:0 with the same magic cookie makes X to work fine again
[13:05] <asac> Ng: strager got that through a reverse lookup for his wifi ip
[13:06] <Nafallo> Ng: I got my reverse set as hostname you know... ;-)
[13:07] <Ng> Nafallo: indeed
[13:07]  * Nafallo should get the PTR fixed anyway :-)
[13:07] <stgraber> I usually have:
[13:07] <stgraber> stgraber@castiana:~$ cat /root/hosts
[13:07] <stgraber> 127.0.0.1	localhost
[13:07] <stgraber> and now I get:
[13:08] <stgraber> stgraber@castiana:~$ cat /etc/hosts
[13:08] <stgraber> 127.0.0.1	castiana.local	localhost.localdomain	localhost
[13:09] <stgraber> (I don't understand why NM would change /etc/hosts at all ...)
[13:09] <Ng> stgraber: for dynamic hostnames, apparently
[13:09] <Spads> Nafallo: are you sure it updated /etc/hosts, or did it just affect the running hostname?
[13:10] <Nafallo> Spads: both running hostname and /etc/hosts
[13:10] <asac> stgraber: the idea is to all dhcp to provide your hostname
[13:10] <Spads> ow
[13:11] <Ng> that clearly shouldn't be a default, imho
[13:11] <stgraber> +1
[13:11] <asac> Ng: yeah. i am trying to get that out of tambeti ;)
[13:11] <stgraber> I don't want DHCP assigned hostname
[13:12] <stgraber> only half of the network I connect to give me the right hostname and I'd prefer not to have stgraber@dhcp123 :)
[13:12] <Nafallo> stgraber: I had nafallo@reserved fwiw... :-P
[13:13]  * Nafallo likes his wizard
[13:13] <stgraber> or if I connect directly to my ISP I'd have some like stgraber@dsl-35-95-230 :)
[13:14] <asac> stgraber: the only problem is the authority i think
[13:14] <asac> stgraber: otherwise its just an optical issue ;)
[13:14] <stgraber> yeah, well just make that an option and disable it by default and I'll be happy :)
[13:15] <stgraber> anyway, got to go to work. I'll check how bad things work and see if I need to reinstall NM from Intrepid in order to work (I'm doing some thin client testing and changes network all the time)
[13:19] <asac> stgraber: you can add to nm-system-settings.conf:
[13:19] <asac> [keyfile]
[13:19] <asac> hostname=yourpreferredhostname
[13:20] <asac> until nm3 is there
[13:21] <Riddell> pitti: apport seems to think this crash doesn't belong to an Ubuntu package http://muse.19inch.net/~jr/tmp/_usr_bin_python2.5.1000.crash
[13:21] <Riddell> pitti: also jockey doesn't seem to say anything about having a broadcom wireless on my girlfriend's laptop (only a driver called wl)
[13:22] <pitti> Riddell: the latter is bug 263097
[13:22] <pitti> Riddell: (currently working on it for hardy)
[13:23] <pitti> Riddell: do you have a locally built .deb for /usr/bin/guidance-power-manager
[13:23] <pitti> ?
[13:23] <Riddell> pitti: no, this is a newly installed intrepid system
[13:25] <pitti> Riddell: ok, I'll need to reproduce this then; can you please drop me an email with that link?
[13:25] <Riddell> ok
[13:31] <asac> stgraber: nm3 uploaded. let me know if that fixes all corner cases
[13:31] <asac> Nafallo: Ng: ^^
[13:32] <Ng> k :)
[13:33] <Nafallo> asac: will do once I've had lunch :-)
[13:34] <Nafallo> oh. uploaded isn't built :-)
[13:34] <Nafallo> goy ya
[13:34] <Nafallo> s/y/t/
[13:42] <asac> bryce: tjaalton: fedora and opensuse have no problem when you update "hostname" in a running session. any idea what they have done to auto-add the new hostsnames to .Xauthority (which appears to be what happens for them)
[14:21] <soren> I'm trying to help a guy mount a USB memory stick. It works for him locally at the machine, but not when connected to a vnc session (vncserver style, not vino). He gets org.freedesktop.DBus.Error.AccessDenied. I presume this is policykit and/or consolekit doing its thing. What's the magic words to shout at the thing to get it to work?
[14:22] <pitti> soren: hm, I thought VNC was merely a remote "view" onto a local session?
[14:22] <pitti> soren: (in that case it shuold "just work")
[14:22] <soren> pitti: As i said: It's not vino.
[14:23] <soren> pitti: It's a proper vnc-only desktop.
[14:23] <pitti> so there's someone at the other end plugging in the USB stick for him?
[14:24] <soren> He's at the machine.
[14:24] <pitti> so ck-list-sessions probably doesn't show a local session for him then
[14:24] <soren> Probably not.
[14:25] <pitti> one possibility is to use "sudo gnome-mount", the more proper one to use polkit-gnome-authorization to grant the privilege for mounting devices to the remote user
[14:26] <pitti> (you need admin privileges in both cases)
[14:26] <soren> polkit-gnome-authorization is probably the magic incantation I was looking for.
[14:26] <soren> so "sudo polkit-gnome-authorization", I presume.
[14:26] <soren> ?
[14:26] <pitti> a non-admin user cannot magically get that privilege from a remote session
[14:26] <pitti> soren: sudo isn't required, that thing itself uses policykit, too, to ask you for your admin password
[14:26] <soren> pitti: Ah, I see.
[14:28] <pitti> soren: (System -> Administration -> Authorizations)
[14:29]  * soren still hasn't realised the problem polkit+consolekit are trying to solve
[14:30] <liw> I need an icon for system-cleaner -- rather than make one with /dev/urandom, I'd like some help with it: any suggestions?
[14:30] <pitti> liw: you can ask kwwii
[14:32] <persia> liw: You can ask in #ubuntu-artwork
[14:32] <liw> thanks, I'll do both :)
[14:37] <tjaalton> asac: nothing comes to mind..
[14:38] <pitti> asac, tjaalton: is it possible to use IP-based xauth?
[14:38] <pitti> OTOH, "xauth list" also shows "tick/unix:0"
[14:39] <StevenK> soren: Only allow access to devices for the currently locally logged-in user on, not a unix group any user can join
[14:42] <soren> StevenK: That's not a "problem".
[14:42] <cjwatson> soren: the problem is that there's no reliable way to revoke group membership
[14:42] <soren> StevenK: Not from where I'm sitting, anyway.
[14:43] <cjwatson> once you're a member of a group, you can create a setgid executable and retain membership indefinitely
[14:43] <cjwatson> or simply leave a process running
[14:43] <cjwatson> all the solutions that have been tried beforehand have security flaws to one extent or another
[14:43] <persia> That means that if you and I both have access to the same machine, I won't be able to read your keystrokes easily when you're at the console.
[14:45] <soren> I just don't really get the idea that any local user should have access to all these things, and noone else. I used to rather like that fact that I wasn't tied to my chair to be able to do stuff.
[14:46] <cjwatson> policykit makes it configurable
[14:46] <cjwatson> so actually it's not as restrictive as all that, it's just a sane default
[14:47] <soren> cjwatson: Do you happen to know how?
[14:48] <cjwatson> System -> Administration -> Authorisations
[14:48] <soren> cjwatson: All I've seen so far is ways to grant a user access to do one tiny thing.
[14:48] <cjwatson> (insane GUI alert)
[14:48] <soren> I'm specifically looking for the button that gives me the same privileges that I had a year ago.
[14:48] <pitti> soren: PK is quite a lot more flexible than unix system groups, and avoids overloading unix groups with "access permissions", where their original idea is "groups of people"
[14:49] <asac> tjaalton: ok thanks. Ill see if redhat/opensuse devs have more info (though the suse NM developer didnt know how this happens)
[14:49] <soren> pitti: I've just never seen a scenario where that's actually a problem.
[14:49] <pitti> soren: the old groups still work, we just stop putting the default use into it
[14:49] <pitti> soren: it is a problem for things which you can't control through group memberships
[14:50] <cjwatson> soren: there was a major problem that came up in lots of 8.04 reviews that was essentially due to this
[14:50] <soren> pitti: Most often, I don't actually want to grant a privilege at the rather extreme granularity that polkit offers, and not just to a single individual.
[14:50] <pitti> soren: like "this should only work for a local user", or "only for an active console", or "only these guys should be able to configure the system clock"
[14:50] <soren> I want to allow a group of folks privileges to perform a set of related actions.
[14:50] <cjwatson> soren: the default user isn't in the sambashare group by default, and adding them to it requires logging out and logging back into the session, so the widget in the desktop GUI to configure sharing didn't work unless all the sambashare stuff was installed right from the start, which it wasn't
[14:51] <cjwatson> there is simply no way to fix that with Unix groups without installing everything you could possibly need by default
[14:51] <pitti> soren: with groups you'd also need to add them one by one
[14:51] <pitti> soren: let alone the fact that unix groups don't stack, you can't e. g. put the "students" group into "plugdev"
[14:51] <cjwatson> pitti: I think it's a fair criticism that it's too hard to configure groups of authorisations with pk
[14:52] <soren> pitti: Yes. Once. Not once for each tiny, little action they might want to do.
[14:52] <pitti> cjwatson: it is, yes; hard with PK, impossible with unix groups
[14:52] <cjwatson> pitti: I don't think that's actually true in practice
[14:52] <soren> cjwatson: I think there are better approaches to fix the sambashare issue. I believe we've discussed this before? Or was that someone else?
[14:52] <cjwatson> soren: the "better approach" I've seen is to create the sambashare group at installation time and add the default user to it
[14:52] <cjwatson> which is not really all that great
[14:52] <soren> My major problem with polkit is that it introduces a granularity, I've *never* seen a demand for.
[14:53] <pitti> cjwatson: (which we do ATM)
[14:53] <cjwatson> pitti: with PK, when an application adds a new action you have to go and configure it all over agin
[14:53] <cjwatson> again
[14:53] <cjwatson> which is a new problem
[14:53] <cjwatson> anyway, I have to run
[14:53] <soren> o/
[14:53] <pitti> right (although our goal should be to not require that)
[14:53] <pitti> after all, it's similar to adding new system groups
[14:53] <pitti> which you have to put existing people into
[14:54] <StevenK> pitti: And running 'id' and having the output be four lines isn't great either
[14:54] <soren> Except there seemed to be a natural limit to the amount of groups people felt like adding.
[14:54] <superm1> StevenK, why should it Provides: libbluetooth2-dev?  It doesn't contain the SONAME that matches to that.
[14:54] <soren> People don't seem to restrict themselves from adding lots and lots of polkit "actions" (or whatever the lingo is).
[14:56] <pitti> soren: yes, the idea was to get away from the almighty root and (1) only allow them to do what they need, and more importantly, (2) get rid of the recurrent gksu dialogs for stuff they need every day
[14:56] <StevenK> superm1: Well, I've had to change 9 packages from libbluetooth2-dev to libbluetooth-dev.
[14:56] <superm1> StevenK, ah so you are saying just more of an interim solution to prevent diffs when rebuilding
[14:57] <pitti> and (3) provide control of privileges you can't express through groups, as I already said
[14:57] <StevenK> superm1: I see your point, though.
[14:57] <superm1> but long term they really should correct themselves
[14:57] <soren> I mean... Honestly, when have you *ever* wanted to grant a person access to "Directly access digital cameras" and not "directly access audio players"?
[14:57] <StevenK> superm1: It's a tiny diff, so *shrug*
[14:58] <pitti> soren: that's rare in practice, yes; that's why we have default privs you don't normally need to touch
[14:58] <StevenK> superm1: obex_socket.c:(.text+0x97a): undefined reference to `hci_remote_name'
[14:58] <StevenK> superm1: A bunch of failures with that error or similar
[14:58] <superm1> StevenK, yeah there may be a few apps that fail related to OBEX.  It's generally pretty easy to patch around, but i'll have to look at the cases.  OBEX has changed significantly
[14:58] <glatzor> hello mvo, are there any concerns using the force-confdef and force-confold option of dpkg in a non-interactive apt session?
[14:59] <superm1> StevenK, any other standouts other than the libbluetooth2-dev -> libbluetooth-dev & the OBEX stuff?
[14:59] <mvo> glatzor: its not ideal, but its the only way with PL
[14:59] <mvo> PK
[15:00] <soren> pitti: but that's my point: It offers a granularity that noone has ever demanded, and it does so at the expense of people who actually need to deviate from the defaults.
[15:00] <glatzor> mvo, luckily dpkg still sends the conffile-prompt status in this case. So we get notified. I replaced the "send n\n" by setting the mentioned dpkg options in packagekit
[15:01] <glatzor> mvo, just wanted to be sure doing the right thing.
[15:01] <mvo> glatzor: ok, that is good to hear that it does that
[15:02] <StevenK> superm1: If you'd rather not do libbluetooth2-dev -> libbluetooth-dev, that's cool. For each of those 9, the diff is tiny.
[15:02] <pitti> soren: so then your problem is not PK itself, but the current set of too granular privileges
[15:02] <pitti> soren: and I tend to agree to that, yes
[15:03] <superm1> StevenK, yeah I think it sends a mixed message to do so
[15:04] <soren> pitti: Actually, it's not just the privileges that are too granular.
[15:05] <pitti> soren: (that problem would correspond to splitting plugdev into camera, usbstick, scanner, etc.)
[15:05] <soren> pitti: The only case where I've ever wanted to only give a single person access to something (rather than a group of people) is the case where I've wanted to do so temporarily so that he could do that one thing and then revoke the privilege again.
[15:05] <pitti> soren: ah; so you actually can do that with PK, but not with unix groups
[15:05] <soren> pitti: And the only part of that problem polkit solves is that it removes the need to log out and back in again.
[15:06] <seb128> could somebody having a clue about python-support look at bug #276324
[15:06] <seb128> doko, mvo: read that?
[15:06] <pitti> soren: you don't need that with unix groups, btw, there's newgrp
[15:07] <pitti> soren: but as I said, groups only work for things like /dev access, not for things like package installation or system time setting
[15:07] <soren> pitti: I need sudo to do that.
[15:07] <mvo> seb128: is that reproducable?
[15:08] <pitti> soren: right, but you don't want to give sudo to everyone who just wants to be able to access a camera or set the system clock, or do you?
[15:08] <seb128> mvo: no clue, I've no hardy machine here to update to try, but the packages moved to updates some days ago and that's the first bug so I would say "no"
[15:08] <soren> pitti: No, precisely.
[15:08] <pitti> (and you can't ever revoke sudo privileges or groups)
[15:08] <soren> pitti: hence, newgrp won't do.
[15:08] <pitti> soren: hm?
[15:08] <pitti> soren: newgrp doesn't need sudo
[15:09] <pitti> (I thought you referred to somethign else with "I need sudo to do that"
[15:09] <soren> pitti: Oh, right, newgrp is suid root.
[15:09] <soren> pitti: I forgot about that.
[15:09] <soren> Er... Yeah, that wouldn't make sense at all.
[15:09]  * soren clearly wasn't thinking straight
[15:10] <soren> pitti: Why can't I revoke sudo privileges?
[15:10] <pitti> soren: once you are root, you can make sure to stay root, same as with groups
[15:11] <soren> pitti: Erm.. sudo is not limited to allowing people to switch to root.
[15:11] <pitti> create suid/sgid binaries, create another user with uid 0 and your password, leave processes running, etc.
[15:11] <soren> pitti: ...and you don't have to grant people access to run stuff like su or whatever.
[15:12] <pitti> soren: well, sure, you can configure it to run certain apps with certain arguments, but don't tell me that's easier :)
[15:12] <soren> pitti: If I want to give that privilege to 50 users?
[15:12] <soren> pitti: I'll argue that it's waaay easier.
[15:12] <pitti> (and it's still not flexible enough to tell apart remote from local sessions, or active from inactive ones)
[15:13] <soren> That's another thing I've never really needed :)
[15:13] <soren> I *liked* that there was no difference between local and remote sessions.
[15:13] <pitti> soren: on a desktop you do :)
[15:14] <pitti> but anyway, if you have 50 users, you'd probably stick them in a group ("teachers" or whatever) and then grant privileges to that group
[15:14] <soren> I can do that with polkit?
[15:14] <pitti> of course you can add 50 indiviual lines to /etc/sudoers, too
[15:14] <pitti> or call pk-auth 50 times
[15:14] <pitti> same complexity, but nobody would actually do that
[15:14] <soren> Can I grant privileges to groups with polkit?
[15:15] <pitti> yes, you can, although not (yet) with the GNOME tool
[15:15] <soren> Ok. That helps quite a bit. I didn't think so.
[15:15] <pitti> but only in /etc/PolicyKit/PolicyKit.conf
[15:15] <pitti> (which is the sudoers counterpart)
[15:15] <pitti> I'd really like the GUI tool to be able to do that too
[15:15] <soren> How do I do this?
[15:16] <soren> <match group="something"> ?
[15:16] <soren> The man page only mentions groups in the context of define_admin_auth.
[15:17] <pitti> soren: yes, match can match on users, groups, and actions
[15:17] <soren> It would be wicked cool if the man page had mentioned that :)
[15:17] <pitti> erm, hm, at least it should
[15:18] <pitti> soren: sorry, might be it doesn't do that so far
[15:18] <pitti> there is no reason it shouldn't, though
[15:19] <soren> I'm almost sure I've had this part of the discussion before with Keybuk.
[15:19] <soren> and I seem to remember that he disagreed.
[15:19]  * soren consults logs
[15:20] <norsetto> glatzor: if bug 276264 is meant for motu-release perhaps its a good idea to subscribe them
[15:20] <glatzor> norsetto, thanks. I just want to add more information before subscribing the moto-release team
[15:21] <norsetto> glatzor: ok, I'll set it to in-progress then
[15:21] <glatzor> norsetto, thanks
[15:21] <norsetto> glatzor: my pleasure
[15:23] <pitti> soren: there's no upstream bug asking for that so far
[15:25] <ScottK-laptop> slangasek: To fix the kleopatra uninstallable needs Bug #267555 approved by ubuntu-mir.
[15:26] <norsetto> ScottK-laptop: how was the holiday?
[15:27] <ScottK-laptop> norsetto: It was very nice.  Nothing like a complete lack of electricity to enforce actually being on vacation.
[15:27] <norsetto> ScottK-laptop: hehe, seems you had fun
[15:28] <ScottK-laptop> Yes.
[15:30] <pitti> soren: also, just FAOD: we didn't kill any udev rules to assign groups to devices, and neither sudoers nor those groups will go away; we just don't want to put users into all of those groups by default, because (1) it gives a wrong semantics, and (2) it is clutter, but nobody stops you from manually adding those to groups (or sudoers)
[15:31] <pitti> soren: just for the desktop case we try to unify on one auth system instead of all three
[15:32] <ScottK-laptop> pitti: Could you have a look at Bug #267555 and see if it could be approved so we could resolve an uninstallable problem?
[15:33] <sladen> what a horrible name for a package
[15:33] <ScottK-laptop> Fortunately it's not one a user would invoke directly and it is the upstream name....
[15:34] <pitti> erm, a daemon running as root, downloading stuff from the internet?
[15:34] <pitti> that's not something we can approve with the snap of a finger
[15:35] <norsetto> seb128: are nice-to-have fixable now?
[15:36] <seb128> norsetto: well, they can be fixed and uploaded but CD packages will probably not be accepted before beta
[15:37] <asac> tjaalton: pitti: http://mail.gnome.org/archives/networkmanager-list/2008-September/msg00291.html
[15:37] <norsetto> seb128: ok, this is not a real problem, its for nautilus-sendto, which still refers to and Suggests sylpheed-claws (which is since long obsolete)
[15:37] <persia> unless they are targeted fixes to fix some issue that broke the CDs.
[15:37] <seb128> norsetto: ah ok, feel free to do a patch and subscribe the sponsor team, I'll upload that later
[15:37] <asac> ^^ the reason why fedora and suse dont have a problem with changing hostnames during X session ;)
[15:37] <norsetto> seb128: willco
[15:38] <asac> "Xauth is completely unecessary with local
[15:38] <asac> users.  The fact that Xauth depends on hostname is bogus and has always
[15:38] <asac> been bogus.
[15:38] <asac> "
[15:38] <asac> ;)
[15:38] <pitti> asac, tjaalton: ah, so it *does* have to do with xauth list showing an entry for unix:0, too
[15:38] <ScottK-laptop> pitti: Understand it'll take some looking at.  It's a mature project and pretty widely used, so I suspect it's in good shape, but who knows.
[15:39] <asac> pitti: yeah. thats what strikes us here
[15:39] <pitti> apparently it doesn't work for us
[15:40] <asac> pitti: http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-xinit/devel/localuser.sh?revision=1.1&view=markup ... thats what they do for local users
[15:40] <asac> are we doing the same?
[15:41] <pitti> asac: I don't think so; looks like an Xsession.d script?
[15:41] <asac> pitti: install -m 755 %{SOURCE17} $RPM_BUILD_ROOT%{_sysconfdir}/X11/xinit/xinitrc.d/localuser.sh
[15:42] <tjaalton> asac: thanks for digging it up.. and yes, looks like a candidate to put in Xsession.d (we don't have xinitrc.d)
[15:42] <pitti> asac: we don't have that, but it's strikingly similar to Xsession.d
[15:42] <asac> yeah
[15:42] <Riddell> evand: am I right in thinking we can install to an existing partition now, and it'll wipe /usr et al but keep /home ?
[15:42] <pitti> tjaalton: any idea why xauth list already has it, but it doesn't work?
[15:43] <pitti> Riddell: if you don't tick "format", it should
[15:43] <cjwatson> yes, that's correct
[15:43] <asac> pitti: (disclaimer: i have no real clue, but) from what i understood the xhost -si:localhost... stuff will make X ignore Xauthority completely for local users
[15:44] <tjaalton> pitti: xhost != xauth
[15:44] <cjwatson> it removes bin dev etc lib lib32 lib64 proc sbin usr var sys
[15:44] <tjaalton> pitti: so xhost allows the user to connect to the server, regardless of what xauth has (AIUI)
[15:45] <evand> indeed, what everyone else said :)
[15:46] <pitti> aaah
[15:47] <asac> tjaalton: which package is the one to file a bug against?
[15:48] <tjaalton> asac: xorg
[15:48]  * pitti -> off for a long phone call
[15:49] <Keybuk> soren: not that I remember
[15:50] <Keybuk> there's certainly been a longer meta-conversation about it
[15:50] <Keybuk> ie. should we do device access by group
[15:50] <Keybuk> davidkit may certainly have been involved
[15:52] <norsetto> seb128: its strange, ScottK already did that change in bug 138010 but it went lost apparently
[15:52] <seb128> norsetto: we probably synced on debian since and judged that a suggests was not worth have ubuntu specific changes
[15:53] <seb128> norsetto: should really be fixed in debian
[15:53] <norsetto> seb128: well, so, its not worth doing it again, I'll see if it is reported to the debian bts
[15:53] <seb128> ok
[15:55] <asac> tjaalton: 276357
[16:11] <tjaalton> asac: thanks
[16:33]  * ogra notices that ubiquity talks about "LiveCD" on the greeting screen despite it is run off a USB key :P
[16:34] <evand> hrm
[16:34] <ogra> evand, on ubuntu-mobile though
[16:34] <jdong> s/LiveCD/LiveMedium/g okdone.
[16:34] <jdong> lol
[16:34] <evand> right, I'm just thinking about usb-creator.
[16:34] <ogra> yep
[16:35] <ogra> well, you could check the mountpoints
[16:35] <geser> zul: Hi, can I ask you about http://launchpadlibrarian.net/17272861/xen-3.3_3.3.0-1ubuntu4_3.3.0-1ubuntu5.diff.gz? as this seem to be the reason for bug 264554
[16:35] <ogra> or follow jdong's suggestion
[16:35] <geser> zul: do you remember why you added that line?
[16:35] <evand> AIUI, we've been trying to move away from "Live CD" to "Desktop CD" for some time.  Perhaps we should follow jdong's suggestion.
[16:35] <evand> cjwatson: mpt: thoughts?
[16:36] <norsetto> RAOF: ping
[16:36] <zul> geser:  Im kind of busy right now but no I dont remember why, if you want can you submit a diff thanks
[16:37] <ogra> hrm
[16:37] <ogra> why does my device drop its wlan during partitioning
[16:37] <ogra> thats reproducable
[16:38] <ogra> does ubiquity restart udev or something like that ?
[16:38] <evand> it does udevtrigger; udevsettle
[16:39] <ogra> ah
[16:39] <ogra> should be udevadm trigger/settel btw
[16:39] <ogra> it changed some time ago
[16:39] <mpt> evand, I suggest calling it "Test Drive" rather than "Live CD"
[16:40] <jdong> mpt: I like the pun too!
[16:41] <evand> ogra: noted; perhaps we should make that udevadm trigger --subsystem-nomatch=net (or whatever it may be)
[16:41] <ogra> yeah, seems to make sense
[16:41] <evand> ok
[16:44] <cjwatson> evand: I don't like wiki case here, and I think we should avoid "live" jargon altogether
[16:44] <cjwatson> test drive WFM
[16:45] <cjwatson> evand: I thought it did use udevadm
[16:45] <mpt> evand, previously: <http://osdir.com/ml/linux.ubuntu.devel.desktop/2006-08/msg00017.html>, <https://bugs.edge.launchpad.net/ubuntu-cdimage/+bug/109064/comments/35>, <https://lists.ubuntu.com/archives/ubuntu-devel/2008-March/025159.html>
[16:46] <norsetto> ScottK-laptop: I wonder if bug 276364 should teach us to ask for an upgrade log too
[16:46] <cjwatson> mpt: although perhaps we should be consistent with what was implemented in the end, i.e. "Try Ubuntu"
[16:46] <evand> cjwatson: so it does
[16:46] <cjwatson> actually, "Try Ubuntu without any change to your computer"
[16:47] <cjwatson> personally, I prefer that to the more metaphorical "test drive"
[16:47] <evand> ogra: FWIW, I've filed your issue as bug 276383
[16:47] <ogra> evand, merci :)
[16:48] <cjwatson> partly because a lot of other languages are going to end up rendering it as something more like "try" anyway, but in general I prefer avoidance of idiom
[16:48]  * ogra subscribes
[16:48] <evand> test drive works for me
[16:49] <evand> I'll create a bug report to track it.
[16:53] <mpt> If there was a simple non-metaphorical way to express it I'd be all in favor, but I haven't come across one in the past three years :-)
[16:55] <mpt> Possibly it will require a little more creativity on the part of translators, but I don't think that's a bad thing (and they can still go long-and-literal as a last resort)
[16:58] <cjwatson> mpt: I think "test drive" is unfortunate here because it implies that you can't do anything persistent
[16:59] <evand> Filed as bug 276387
[16:59] <cjwatson> mpt: in the case of usb-creator, that isn't true
[16:59] <mpt> hmm, good point
[16:59] <evand> Yeah, that had crossed my mind, though we might have to do some text substitution there anyway, as we either need to add a persistence option...
[17:00] <evand> or leave it as is, where it modifies the existing options to add persistence (bug perhaps we should change the wording here?)
[17:00] <mpt> There should be some very obvious distinction between an Ubuntu session where stuff you create or change will be remembered, and one where it won't be
[17:00] <mpt> using the live CD is the latter
[17:00] <cjwatson> ... sometimes
[17:00] <mpt> using a USB key is sometimes the former and sometimes the latter
[17:01] <cjwatson> (it's possible to set up a customised live CD with persistence)
[17:01] <mpt> It is?
[17:01] <mpt> With a CD-RW?
[17:01] <cjwatson> you can store the information on an accompanying USB stick
[17:01] <cjwatson> I think somebody did try doing it with multi-session CDs as well but I don't think that got finished
[17:01] <mpt> well sure, but you can do that with a non-customized live CD too, right?
[17:01] <cjwatson> err, right, indeed
[17:02] <cjwatson> and indeed some people explicitly cite that as something they like to do with the Ubuntu live CD
[17:02] <mpt> or do you mean it's customized to assume that $HOME is on the USB stick?
[17:02] <cjwatson> sorry, I shouldn't have said "customised". I'm on the phone so distracted
[17:02] <cjwatson> I meant that you need to do some setup and boot with non-default options
[17:03] <mpt> ok
[17:05] <evand> (creating a casper-rw ext2/3 file on a disk, or making a partition with the casper-rw label, then adding "persistent" to the kernel command line options)
[17:05] <cjwatson> right, it's essentially the same as doing it on a USB stick, we just wrap it up more nicely for the latter now
[17:07] <mpt> So just using "live CD" everywhere is ~98% accurate (inaccurate in the USB and customized-boot cases), but meaningful to ~0.5% of people
[17:08] <mpt> Using "test drive" everywhere would be meaningful to many many more people, but would be less accurate
[17:08] <Spads> clearly "test drive" is the verb and "Live CD" is the noun
[17:10] <_MMA_> slangasek: Can Studio's disks be respun? We had a important update just hit the archive that we need on the beta disks.
[17:14] <mpt> evand, was this something you were intending to change at all for 8.10? If not, perhaps we can sort it out at UDS
[17:14] <evand> No, I imagine it is quite late for 8.10, so yes, I think we can discuss this at UDS at length.
[17:16] <mpt> ok, I'll register it for discussion
[17:17] <evand> much appreciated
[17:21] <mpt> evand, <https://blueprints.edge.launchpad.net/ubuntu/+spec/ubiquity-sans-live-session> is already implemented, right?
[17:21] <cjwatson> Spads: "Desktop CD" is the noun :-)
[17:22] <cjwatson> mpt: yes, it is - I don't think evand will have privileges to close it though, I'll do it
[17:22] <kees> cjwatson: question about overrides, why are some binary packages listed in multiple repos?  e.g. mpg123 is in both multiverse and universe.
[17:22] <kees> override.gutsy.multiverse:mpg123	optional	multiverse/sound
[17:22] <kees> override.gutsy.universe:mpg123	optional	universe/sound
[17:23] <cjwatson> kees: I'm betting on different architectures
[17:23] <kees> blarg.
[17:23] <cjwatson>     mpg123 |   0.59r-21 | gutsy/multiverse | hppa
[17:23] <cjwatson>     mpg123 |     0.66-1 | gutsy/universe | source, amd64, i386, ia64, powerpc, sparc
[17:24] <cjwatson> happens sometimes, sorry
[17:24] <kees> whee
[17:24] <cjwatson> you could grab the Packages files and use madison-lite on them
[17:24] <cjwatson> it will give you output like the above
[17:24]  * kees nods
[17:24] <cjwatson> (or just grep-dctrl or whatever)
[17:28] <kees> cjwatson: is the above mpg123 disparity due to hppa being out of date?  i.e. if it built mpg123 0.66-1, it'd end up in universe, or does each arch have its own set of overrides?
[17:31] <\sh> asac, doko: somehow I'm missing {ia32-}sun-java{5,6}-plugin ... any clue if it's reaching intrepid before release?
[17:33] <cjwatson> kees: ultimately, it's because we have no mechanism at the archive level to ensure that overrides are in sync across architectures
[17:33] <cjwatson> kees: combined with (probably) some subtle Soyuz bugs
[17:34] <kees> cjwatson: okay, so it sounds like the only way for me to predict where a given binary will go is to pull all arch Packages files and look at the prior release.
[17:34] <kees> cjwatson: I'm basically trying to create the list of files to check for on the archive to confirm that mirroring has finished before sending a USN.
[17:35] <kees> cjwatson: it's designed to fight both human and soyuz glitches.
[17:35] <asac> \sh: ia32- like in "a amd64 package"?
[17:35] <siretart> kees: even then you cannot be sure because some archive admin might change the override just before you upload the package ;)
[17:35] <\sh> asac: yes
[17:35] <cjwatson> kees: yeah, we discussed it so I guessed
[17:35] <\sh> asac: and like in "it was in hardy"
[17:35] <cjwatson> siretart: in theory; but pretty unlikely for stable releases, in practice
[17:35] <siretart> indeed
[17:35] <kees> siretart: right, but those are one-offs that we can fix manually in the USN
[17:36] <\sh> siretart: hey...sorry to not phoned you back the last days..but we were more bound to IPX then planned :( you can ask nobse he actually saw us three times a day (when he entered the office, when he left, and when he entered it the next morning again ;))
[17:37] <siretart> \sh: no problem. The next time then!
[17:37] <\sh> siretart: sure...the next racks are already planned I just need to wait for the hardware ;))
[17:38] <siretart> :)
[17:40] <doko> \sh: we never had an ia32-plugin afaik
[17:44] <asac> ack ... i think only icedtea
[17:45] <\sh> doko: right, we only had ia32-sun-java*-bin *grmpf*
[17:46] <\sh> doko: but then we have to remove somehow the suggest from sun-java6-jre
[17:46] <\sh> doko: because it mentiones ia32-sun-java{5,6}-plugin
[17:46]  * ogra just had to fiddle with his heating and really doesnt think its the time of year for icedtea
[17:46] <asac> arch dependent suggests? ;)
[17:47] <\sh> hmm...lemme check the source ;()
[17:48] <\sh> doko: any clue how to make the ilo2 java applet fly on openjdk?
[17:48] <\sh> or better to say, any applet which doesn't work on openjedk?
[17:48] <\sh> jdk even
[17:48] <asac> \sh: applets that use avascript to interact with browser wont work
[17:49]  * \sh doesn't want to install i386 ubuntu now :(
[17:50] <\sh> asac: but btw...even if  suggest is arch dependent, it should mention a package which doesn't exists, or?
[17:51] <\sh> and no it's not arch dependent...Suggests: sun-java6-plugin | ia32-sun-java6-plugin, sun-java6-fonts, ttf-baekmuk | ttf-unfonts | ttf-unfonts-core, ttf-kochi-gothic | ttf-sazanami-gothic, ttf-kochi-mincho | ttf-sazanami-mincho, ttf-arphic-uming,
[17:52] <asac> not sure ... its not uncommon to mention packages that only exists outside the archive as a suggests
[17:54] <pitti> BenC: hello Ben; if you have a minute, I'd appreciate an ack/nack from you in bug 271956
[17:56] <BenC> pitti: ok
[18:03] <cody-somerville> slangasek, cjwatson: Why is the date on the manifest file from yesterday in current?
[18:03] <cody-somerville> ie. http://cdimages.ubuntu.com/xubuntu/daily-live/current/
[18:05] <cjwatson> cody-somerville: that indicates a livefs build failure
[18:05] <cjwatson> well, not always
[18:05] <cjwatson> actually today I did a mass build just to update the ISO wrappers, not the livefs, because there was a bug in those
[18:06] <cjwatson> (p.s. cdimages is for compatibility only, official name is cdimage)
[18:06] <slangasek> ah, so no one did livefs rebuilds for xubuntu/kubuntu yet
[18:06] <cody-somerville> : (
[18:06] <slangasek> those should be done, particularly kubuntu which has ~100 packages out-of-date on the CD...
[18:07] <slangasek> I'll schedule those now
[18:07] <lool> bryce: I've committed the fix for #274833; I see other bits are pending, is it because they would be disruprive right now?
[18:07] <lool> *disruptive
[18:10] <slangasek> asac: no, not "perfect", but you can't hand me a massive diff for a component as critical as NM within hours of the CD builds (i.e., well in the beta freeze), and expect me to be able to be able to drop it in :/
[18:11] <slangasek> ScottK-laptop: meh, I don't remember kleopatra being uninstallable yesterday, is that a new dep due to the new KDE drop?
[18:15] <bryce> lool, was just waiting for some more significant changes to include with it
[18:15] <lool> Cool
[18:16] <lool> bryce: Mind if I upload it?  I'm seeking release ack ATM
[18:16] <bryce> lool: certainly, go ahead
[18:16] <lool> Thanks
[18:16] <bryce> those changes are just some usability frosting for the failsafe mode; pretty low risk
[18:17] <ScottK> slangasek: Kleopatra wasn't on the list yesterday, but the dirmngr MIR's been outstanding for some time.  I'm not sure why it's not on the list.  We wrote the MIR after I saw it on the list for one of the alphas.
[18:17] <BenC> wow...virtualbox seamless mode is pretty impressive
[18:19] <pitti> Riddell, ScottK: do you know a good kubuntu person to poke about a qt4-x11 packaging bug? (bug 261380)
[18:19] <slangasek> jdstrand, kees: have you seen pitti's request for security review on bug #267555 (MIR), and when do you think you'd have time for that?  (it's not on the CDs, so that can be fixed for beta any time before beta, effectively)
[18:19] <bryce> lool: out of curiosity, what is the kernel bug that is preventing -psb from working?
[18:20] <pitti> slangasek: is it actually critical for beta? I mean, such a dependency doesn't come up two days before beta, or did it?
[18:20] <lool> bryce: It needs portin
[18:20] <lool> *porting
[18:20] <pitti> slangasek: if it breaks stuff, we could temporarily promote it, but TBH I really don't like it
[18:20] <lool> bryce: You might recall the drms are incompatible, and we use linux-lpia for non-psb chips
[18:20] <pitti> slangasek: ("it" being the package, not the "temporary in main" cowboying)
[18:21] <bryce> lool, ahh
[18:21] <ScottK> pitti: I'll see if I can dig someone up.
[18:21] <lool> We didn't want to carry the lpia hack forward in intrepid, so we don't have the psb drm and associated libdrm in intrepid main
[18:21] <lool> bryce: Intel will start development of an intrepid driver this week and will deliver in december
[18:21] <asac> slangasek: all fine. ;)
[18:21] <lool> Which is probably pointless
[18:21] <asac> slangasek: and of course you were right :)
[18:21] <bryce> lool, just in time for jaunty, eh?
[18:23] <lool> bryce: :-/
[18:26] <slangasek> pitti: two days before beta - KDE had a pre-agreed code drop at the beginning of this week, and apparently kleopatra grew a dependency in the process; it's not critical for beta /because/ it's not on the CDs, but it would be nice to fix up that uninstallables list
[18:26] <kees> slangasek: I haven't reviewed MIRs in a bit.
[18:26] <kees> slangasek: I can look into that probably next week
[18:26] <slangasek> ok
[18:27] <slangasek> that'll be fine, thanks
[18:27] <pitti> slangasek: ah, ok; it just looks a bit curious to me, since it looks like it wouldn't work out of the box for normal users anyway, and thus a strict depends: might be too much?
[18:27] <Riddell> slangasek: kleopatra can just be moved to universe
[18:27] <pitti> slangasek: (unless there is some other suid-root-ness which I missed)
[18:29] <ion_> Hm. Updated to intrepid and now X doesn't seem to find any input devices.
[18:30] <jdstrand> slangasek: I have the same timeframe as kees
[18:30] <ScottK> Riddell: kleopatra is seeded on the Kubuntu DVD.
[18:30] <Riddell> ion_: I got that
[18:31] <jdstrand> kees: we can discuss who does it when we are closer to being able to do it (unless of course, you really *want* to do it :P)
[18:31] <Riddell> ion_: I filed it as bug 275825, bryce know anything about it?
[18:31] <kees> jdstrand: cool, yeah
[18:32] <kees> jdstrand: I'm not itching for an audit :)
[18:32] <jdstrand> :)
[18:33] <bryce> Riddell: what kind of keyboard is it?  the bug's a bit sketchy on details
[18:33] <bryce> also I'd like to see the xorg.conf there
[18:33] <ion_> riddell: The output of lshal and startx -- -verbose 999 2>&1 might be useful. I'll be able to add that later, but if you can do it immediately, go ahead.
[18:33] <Riddell> ion_: I can't, computer has been reinstalled since
[18:33] <Riddell> bryce:
[18:34] <Riddell> bryce: keyboard is just a laptop one, I also plugged in a hal one and restarted X
[18:35] <slangasek> Riddell: "can just be moved to universe" - ok, do you want to unseed it then? :)
[18:35] <bryce> Riddell: well, in general upgrades to intrepid don't lose the keyboard like this normally, so there is something unusual about your system
[18:35] <bryce> Riddell: it looks like the touchpad got detected okay; I assume that works?
[18:36] <Riddell> bryce: yes the touchpad worked, nothing unusal it's an HP laptop and it works fine from a fresh install.  I also deleted the xorg.conf and restarted X but no difference
[18:36] <bryce> ah that's interesting
[18:38] <bryce> Riddell: the next step would be to review your lshal output and see what it shows for your keyboard
[18:38] <slangasek> james_w: I see midori in the queue; so there was a consensus among the xubunters?
[18:39] <Riddell> bryce: can't do that immediately I'm afraid, computer has gone back to girlfriend, I'll be doing more upgrade testing tomorrow and will add more details then
[18:39] <bryce> Riddell: my guess is that some bad hal data got stuck in there somewhere.  Might be interesting to compare what's in your /etc/hal with an upgrade vs. fresh install
[18:39] <ion_> bryce: Please see http://heh.fi/tmp/x-problem/ – the config/hal lines at the end of x.log are interesting.
[18:39] <Riddell> pitti: I have no idea where to start with that qt debug bug
[18:39] <bryce> Riddell: ah ok
[18:40] <ion_> bryce: Btw, is there hope of getting MPX support for intrepid?
[18:40] <bryce> ion_: so it looks like you need to have 'evdev' set as the input.x11_driver for your keyboard
[18:40] <bryce> ion_: no
[18:40] <james_w> slangasek: there wasn't
[18:41] <slangasek> james_w: oh.  what was there in its place? :)
[18:41] <slangasek> (i.e., should I go ahead and accept this now?)
[18:41] <james_w> slangasek: oh, you *do* see it in the queue, sorry :-)
[18:41] <james_w> slangasek: I didn't upload
[18:41] <james_w> slangasek: cody-somerville did I guess
[18:42] <ion_> bryce: I wonder why x11_driver isn't set?
[18:42] <bryce> ion_: it wasn't required to be set in hardy
[18:42] <slangasek> james_w: ah, let me check the sig and we'll see :)
[18:42] <bryce> ion_: can you check if you have -evdev installed?  dpkg -l xserver-xorg-input-evdev
[18:42] <ion_> It is.
[18:43] <kees> is there some kind of sound regression?  I can't get anything using gstreamer to play...
[18:43] <slangasek> james_w: yep, cody-somerville uploaded, so I'll take that as an indicator of consensus and push it in
[18:43] <james_w> slangasek: I agree
[18:45] <ion_> bryce: Hm. In lshal output, xkb.model is 'evdev' instead of 'pc105'.
[18:46] <bryce> ion_: more interestingly is the lack of an input.x11_driver entry
[18:46] <bryce> which *should* be 'evdev'
[18:46] <bryce> I think the model being 'evdev' is probably ok
[18:47] <bryce> ion_: you might want to come to #ubuntu-x
[19:04] <pitti> Riddell: I wonder how it installs the files, does upstream do that? dh_strip --dbg-package doesn't do it that way
[19:06] <Riddell> pitti: yes upstream does that I believe, I just spoke to an upstream person who suggested using -no-separate-debuginfo and stripping it ourselves
[19:21] <ion_> pitti: I was told to bug you about this. After an upgrade from a fresh hardy installation to intrepid, HAL had old information in /var/cache/hald/fdi-cache. It only stat()d most of the FDI files without opening them, and never took /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi into account, which caused X not to find any input devices. I renamed the cache file away and everything works now.
[19:22] <ion_> pitti: Perhaps hald's postinst should just remove the cache file.
[20:09] <Sonne> hi
[20:09] <Sonne> i've found a bug in a package in intrepid after backporting it to hardy
[20:10] <Sonne> how should i report it?
[20:10] <Sonne> my best idea since now is to use reportbug and write in the notes that it has been backported from intrepid
[20:10] <Sonne> maybe there's some better solution :)
[20:10] <infinity> Sonne: Does the bug exist if built for intrepid, or is it a result of running it on hardy?
[20:11] <infinity> Sonne: If the bug exists when running in Intrepid, just report it in launchpad like any other bug.
[20:11] <Sonne> ah, they can be reported via web?
[20:11] <Sonne> cool
[20:11] <infinity> Sonne: If it only shows up on hardy, you could still report a bug, I suppose (especially if you have a simple fix to provide to make it happy), but make it very clear that it only breaks in a hardy environment.
[20:11] <Sonne> well, the bug is a typo in a script in cmake, so i guess the problem would show up on intrepid too :)
[20:12] <infinity> Sonne: Which package?
[20:12] <Sonne> cmake
[20:12] <infinity> http://launchpad.net/ubuntu/+source/cmake/+bugs
[20:12] <Sonne> /usr/share/cmake-2.6/Modules/FindLua51.cmake
[20:13] <Sonne> it reports lua51 as lua50
[20:13] <Sonne> yep, let me submit it :)
[20:17] <Sonne> done
[20:49] <Adri2000> bug #254905 < needs review from an -sru person
[20:50] <Adri2000> btw, why is registry a member of ubuntu-sru in LP?
[21:00] <AlinuxOS> hello all, asac is there some news from Bug #256054 ?
[21:02] <asac> AlinuxOS: i will follow up on the bug
[21:03] <slangasek> asac: should we drop that one in the beta errata, I guess, since it's slipping until post-beta?
[21:03] <AlinuxOS> asac, ok :) I discovered some minutes ago that I cant use static IP.
[21:03] <asac> slangasek: yes push ahead. doing that now
[21:04] <asac> slangasek: do you need any info for the errata?
[21:04] <asac> AlinuxOS: have you tried the workaround posted?
[21:04] <slangasek> asac: someone needs to distill the bug into a user-friendly description; that can be you or me
[21:05] <AlinuxOS> asac, on the same page ?
[21:06] <AlinuxOS> asac, which one?
[21:06] <asac> AlinuxOS: ,ifupdown to make NM honour your interfaces
[21:06] <AlinuxOS> asac, ah ok..
[21:06] <AlinuxOS> I see now..
[21:06] <asac> not sure if that helps in your bridge setup ... what you need is the ability to unmanage interfaces most likely
[21:06] <AlinuxOS> is intrepid beta ?
[21:07] <asac> AlinuxOS: not yet, but soon
[21:07] <AlinuxOS> or are we in alpha 6 ?
[21:07] <AlinuxOS> ah ok
[21:07] <AlinuxOS> asac, thank you for your time.
[21:24] <calc> is there a way to get the old logout screen back in intrepid?
[21:24] <james_w> no, not without some coding as far as I know
[21:25] <calc> ok :\
[21:26] <liw> if I want to have foo-gtk depend on foo, should I use source:Version or binary:Version? the latter sounds more binNMU-friendly (which may matter only to Debian, perhaps)
[21:26] <slangasek> liw: that depends on which of the packages are arch: all and which are arch: any
[21:27] <slangasek> (the difference does only matter in Debian, though)
[21:27] <liw> slangasek, both are arch:all
[21:27] <slangasek> liw: then it doesn't matter at all, since arch: all packages are never binNMUed
[21:27] <liw> oh, right
[21:27] <liw> thanks
[21:28] <asac> slangasek: http://paste.ubuntu.com/52586/
[21:29] <asac> slangasek: if its ok, i will update the bug description like that
[21:29] <slangasek> asac: for the bug description, that looks fine to me.  For the errata, I'll want to condense it further.
[21:29] <NCommander> ScottK, ping
[21:30] <asac> slangasek: sure go ahead.
[21:30] <asac> updated bug
[21:45] <NCommander> Anyone know how I get a machine added to acpi-support?
[21:45]  * NCommander isn't quite sure what information he has to provide
[21:46] <kees> slangasek, smb: I can't reproduce this: 276299
[21:50] <NCommander> lool, can you help me get a machine added to acpi-support so sleep.sh force isn't needed
[22:02] <persia> NCommander: Does the source not help you find the info?
[22:05] <NCommander> persia, Sorta, I'm kinda afraid to try and provide a patch for the ACPI scripts due to the possibility of breaking things :-)
[22:06] <persia> NCommander: I'd recommend preparing a patch for discussion and review.  It might be horribly wrong, but at least it's a starting point.
[22:07] <NCommander> persia, my "patch" at the moment is just hard coding force to true so I can suspend from within Xfce ;-). Once I figure out the specifics, I'll cook up a patch
[22:16] <slangasek> kees: that's been marked as a dupe of the one that was fixed already?
[22:17] <slangasek> kees: is the implication that it's not really fixed?
[22:17] <kees> slangasek: that would be how I'm reading it, but I can't reproduce the crash with -8.  :(
[22:18] <Ng> NCommander: isn't pm-utils the new hotness? I don't think acpi-support is used very much anymore
[22:18] <NCommander> Ng, pm-utils doesn't work on any machine I ever tried it on. (a few apples, and three sony laptops).
[22:18] <slangasek> kees: ok, well, pochu's not around to ask; I wonder if apport is wrongly reporting the current version when the crash really happened with the old version?
[22:19] <NCommander> pm-is-supported --suspend returns 1 which means my hardware is unsupported
[22:19] <slangasek> NCommander: have you filed bug reports about these failures?  pm-utils is the supported Thing
[22:19] <Ng> NCommander: aiui acpi-support is targetted to disappear in jaunty, so getting whatever quirks are required in place would seem like a good solution
[22:19] <NCommander> slangasek, there are already a bunch for the Macs, and one for my sony laptop
[22:19] <slangasek> ah
[22:19]  * NCommander no longer has the other laptop to file a report
[22:20] <NCommander> Ng, it doesn't require any quarks, it checks for the existence of /dev/pmu, which doesn't exist for me
[22:20] <NCommander> Thus no suspend support
[22:20] <NCommander> ACPI works properly however
[22:20] <Ng> I dont have pmu and -is-supported returns 0
[22:21] <slangasek> acpi-support doesn't implement suspend/resume anyway in the current incarnation, afaik
[22:21] <NCommander> Ng, looking at the code, it checks for the existance of /dev/pmu it seems
[22:21] <NCommander> Ng, are you on intrepid?
[22:21] <Ng> NCommander: yep
[22:21] <NCommander> slangasek, /etc/acpi/sleep.sh is owned by acpi-support
[22:21] <NCommander> Ng, lucky then
[22:22] <Ng> hardy used pm-utils to sleep, afaik
[22:22] <NCommander> It worked on Hardy only after I did some nutty hacking
[22:22] <Ng> but ultimately both of them just do some magic and echo something into proc or sys
[22:22] <NCommander> It broke on intrepid after alpha 2 or 3 completely, but I only just got around to fixing it
[22:22] <Ng> (where "magic" means "run scripts")
[22:23] <NCommander> If I can figure out how to make pm-is-supported return 0, I could suspend
[22:24] <NCommander> + ARG=suspend
[22:24] <NCommander> + check_suspend
[22:24] <NCommander> + command_exists s2ram
[22:24] <NCommander> + type s2ram
[22:24] <NCommander> It seems pm-is-supported checks force the existence of s2ram which was removed ...
[22:25] <slangasek> do you have uswsusp installed?
[22:25] <sbeattie> kees|slangasek: that's my belief as well, that the apport crash detection stuff gets run after upstart gets updated, and is reporting the fixed version rather than the buggy one. I've seen that with other apport crash reports.
[22:25] <Ng> s2ram is old and busted too
[22:25] <slangasek> sbeattie: yeah, annoying :/
[22:25] <NCommander> Ng, s2ram worked.
[22:25]  * NCommander doesnt' give a damn if its old if the new solution works
[22:25] <NCommander> -_-;
[22:25] <kees> sbeattie, slangasek: I hope that's the case.  :)
[22:25] <NCommander> I thought pm-utils was a complete replacement though
[22:26] <NCommander> I can't even understand why its checking for s2ram
[22:26] <slangasek> do you have uswsusp installed?
[22:26] <NCommander> slangasek, yes
[22:26] <NCommander> slangasek, but the s2ram command was removed from that package in Ubuntu
[22:26] <slangasek> try uninstalling it
[22:26] <Ng> NCommander: I think that's a debian patch, going by 20080926112602.GA4015@srcf.ucam.org
[22:26] <NCommander> (its still there in Debian)
[22:26] <sbeattie> slangasek: I tried to have apport filter out those dupes, but I explicitly checked for -7 because the stacktrace is so useless. If you've got better ideas for a regex to match that, I'd be happy to improve it.
[22:27] <NCommander> slangasek, removing ...
[22:27]  * NCommander waits on initrd ...
[22:28] <slangasek> NCommander: there's an open bug about pm-utils' support for backend selection; uswsusp deliberately doesn't support suspend, and pm-utils doesn't fall through to another backend in this case
[22:28] <Ng> I'm not sure how pm selects which "module" it uses for suspend, but the options I have are uswsusp (old and busted), tuxonice (crack) and kernel (correct hotness). the latter checks for suspendability by grepping in proc
[22:28] <slangasek> (was discussed on ubuntu-devel last week)
[22:28] <NCommander> Now I'm getting 0 from pm-is-supported
[22:28] <NCommander> which means ACPI should start working
[22:28] <NCommander> er
[22:28] <NCommander> suspend
[22:28] <NCommander> slangasek, I've still dealing with my inbox, I've been somewhat MIA all week ;-)
[22:29] <NCommander> Hold on, testing suspend
[22:29]  * NCommander hugs slangasek 
[22:29] <NCommander> WOOO
[22:29] <NCommander> That fixed it
[22:29]  * NCommander checks the seed on Xubuntu
[22:30] <slangasek> ah, right, xubuntu; where the main/universe barrier doesn't stop the pm-utils Recommends: uswsusp from being honored
[22:30] <slangasek> that'll be fixed post-beta
[22:31] <slangasek> (by demoting the Recommends, since it's not Recommended at all)
[22:31] <Ng> NCommander: :)
[22:32] <NCommander> slangasek, I'm going to ask Cody put it on our blacklist just so it doesn't get pulled in period. We got a rash of bug reports about sleep, but most of them were written off as 2.6.27, not Xubuntu related ;-)
[22:32] <NCommander> hey BenC
[22:32] <cody-somerville> blacklist doesn't quite work like that
[22:33] <NCommander> cody-somerville, ?
[22:33] <cody-somerville> A package on the blacklist does not prevent a package from being included in a build IIUC.
[22:33] <NCommander> cody-somerville, then what's the point of blacklists?
[22:34] <NCommander> slangasek, the uswsusp problem will be resolved before Intrepid ships, right?
[22:34] <Ng> can we just remove it alltogether?
[22:35] <ogra-maemo> ++
[22:35] <NCommander> Ng, if you want to help remove the rdepends ;-)?
[22:36] <ogra-maemo> drop it from the archive
[22:36] <slangasek> NCommander: yes
[22:36] <NCommander> slangasek, \o/
[22:36]  * NCommander hugs sladen 
[22:36] <NCommander> er
[22:36]  * NCommander hugs slangasek 
[22:36] <slangasek> what are the reverse-depends?  Looks like 'hibernate', and that should probably go away too :-P
[22:37] <sladen> NCommander: perhaps whilst you're politely hugging vorlon you could whisper something about changing his nick
[22:38] <slangasek> sladen: someone else already has the nick 'vorlon' on this network ;P
[22:38] <NCommander> slangasek, aw, but my 1993 Thinkpad wants to sleep too ;-)
[22:39] <Ng> NCommander: I suspect much of the rdepends are suggests
[22:40] <sladen> slangasek: 22:38 [Freenode] -!- There is no such nick vorlon
[22:40] <NCommander> I thought apt-cache rdepends showed only actual depends
[22:40] <sladen> slangasek: grab it quick
[22:40] <NCommander> sladen, its registered to a freenode staffer I thought
[22:40] <Ng> in fact they're all recommends or susggests if a quick for loop is to be trusted
[22:40] <slangasek> sladen: oops, it's back
[22:40] <sladen> vorian [i=steve@freenode/staff/vorian]  is
[22:41] <sladen> slangasek: "/nick vorlin" /msg Nickserv register
[22:41] <sladen> meh
[22:41] <ogra-maemo> heh
[22:41]  * NCommander prefers outside of an encounter suite ;-)
[22:42] <NCommander> ^slangasek
[22:42] <soren> NCommander: It's worse than that.
[22:42] <soren> NCommander: It also lists conflicts, breaks, etc.
[22:42] <NCommander> ewwwwwwww
[22:42] <soren> Basically anything that states a relationship with the package, AFAIR.
[22:43] <Ng> getting recommends and suggests is nice, but it might be better if it listed the relationship
[22:43] <soren> Oh, wait.
[22:43] <NCommander> Do you think we could remove uwsusp for this release?
[22:43] <NCommander> Or should it wait for 9.04?
[22:43] <soren> Perhaps I'm confused. I might be thinking of the dotty output.
[22:44] <slangasek> NCommander: well, see the feedback on bug #264311; some people are quite attached to uswsusp
[22:44] <slangasek> I also don't think it's worth removing && blacklisting the package, instead of just fixing it so nothing else pulls it in
[22:45] <cjwatson> NCommander: I invented the blacklist syntax for a single special case
[22:45] <NCommander> slangasek, well, if its feasible,
[22:45] <cjwatson> NCommander: most of the other uses people have tried to put it to don't work
[22:46]  * NCommander notes thats why warning labels were invented
[22:46] <cjwatson> NCommander: a blacklist entry is a big hammer which causes things to break if a package that isn't supposed to be installed gets into germinate's output, so that you can go and fix the packages to stop that happening
[22:46] <soren> NCommander: Sorry, I was indeed mistaken. I was thinking of the dotty output.
[22:46] <cjwatson> NCommander: trying to use it instead to work around package relationships doesn't work, because apt doesn't (and can't) know about blacklist entries in seeds
[22:47] <slangasek> cjwatson: by 'blacklist' I meant 'sync blacklist', fwiw
[22:47] <cjwatson> NCommander: so in particular you would find that the package keeps on being pulled into livefses
[22:47] <cjwatson> 22:32 <NCommander> slangasek, I'm going to ask Cody put it on our blacklist just so it doesn't get pulled in period. We got a rash of bug reports about sleep, but most of them were written off as 2.6.27, not
[22:48] <slangasek> ah
[22:48] <cjwatson>                    Xubuntu related ;-)
[22:48] <cjwatson> slangasek: ^- that was what I was replying to
[22:56]  * cjwatson adds some documentation based on the above description of the purpose of blacklist entries to germinate(1)
[23:07] <infinity> cjwatson: Dude, why haven't we fixed that gaping OpenSSH hole yet, WTF?!
[23:07] <cjwatson> haha
[23:07] <infinity> (For the confused, the above is sarcastic spillover from another channel)
[23:12] <slangasek> infinity: #ubuntu-security-theater?
[23:16] <asac> tjaalton: so debian appears to not have an issue with changing hostname in-session :/
[23:16] <asac> tjaalton: and the debian guy that said that didnt find anything about xhost in Xsession.d/
[23:19] <kirkland> slangasek: hiya, could you perhaps help sponsor two minor uploads, one to landscape-client, and one to update-motd ?
[23:21] <kirkland> slangasek: landscape-client change in https://code.launchpad.net/~kirkland/landscape-client/270862
[23:21] <kirkland> slangasek: update-motd change in https://code.launchpad.net/~kirkland/update-motd/main
[23:21] <slangasek> kirkland: hmm, they won't go anywhere until after beta (due to the archive freeze); I have a long list of other things to try to get done between now and beta
[23:21] <slangasek> so if you can find someone else to sponsor, that's probably preferable
[23:22] <kirkland> slangasek: okey doke, no problem.  i think mathiaz can help with that
[23:22] <kirkland> slangasek: what do i need in terms of "approval"?
[23:22]  * persia points at ~ubuntu-main-sponsors, and encourages everyone to use that to keep the queue small.
[23:22] <kirkland> slangasek: note that not making the beta is not an issue
[23:22] <slangasek> kirkland: bugfixes don't need any approval, just sponsorship; they just don't clear the queue until after beta
[23:22] <slangasek> s/any approval/any central approval/
[23:23] <kirkland> slangasek: gotcha, thanks
[23:23] <kirkland> persia: i've had relatively little success in several months of subscribing ~ubuntu-main-sponsors or ~ubuntu-universe-sponsors to bugs
[23:24] <kirkland> persia: i find i have to talk to people in real time, synchronously on irc to get patches sponsored
[23:24] <ogra-maemo> thats what persia hopes to change
[23:24] <persia> kirkland: Understood, but the way to make them work is for everyone to use them.  The more people that don't use them, the more they get ignored.
[23:24] <wgrant> Then this problem should be fixed, rather than likely diverting potential spponsor attention away even further.
[23:26] <jcristau> asac: 'sudo hostname foo; xlogo' sure fails here, on sid.
[23:27] <ogra-maemo> why would you do that?
[23:27]  * ogra-maemo wonders about the usecase
[23:27] <asac> ogra-maemo: hostname?
[23:27] <wgrant> ogra-maemo: Because NM does it.
[23:27] <asac> correct ;)
[23:27] <ogra-maemo> ah
[23:28] <asac> ogra-maemo: it works on fedora and suse
[23:29] <ogra-maemo> why does it call  hostname explicitly ?
[23:29] <ogra-maemo> to change ti ?
[23:29] <ogra-maemo> *it
[23:29]  * slangasek gets a silver bullet for NM
[23:30] <jcristau> asac: 'it works' doesn't mean it's a good idea..
[23:31]  * ogra-maemo holds his lighter at the edge of the archive to distract slangasek
[23:31] <asac> jcristau: its understood that its not what most users want
[23:31] <asac> jcristau: but there are several users that constantly ask for that feature
[23:31] <asac> otherwise that wouldnt have been added
[23:31] <ogra-maemo> well, you need to  update Xauthority i guess
[23:32] <asac> ogra-maemo: fedora doesnt use xauthority for local users
[23:32] <liw> er, why is NM changing the hostname?
[23:32] <asac> ogra-maemo: they use xhost in xinitrc
[23:32] <ogra-maemo> asac, bbut we do
[23:32] <persia> liw: DHCP provided hostnames, perhaps?
[23:32] <slangasek> liw: Chronic Batshit Syndrome
[23:32] <ogra-maemo> just addd a proper xauth entry
[23:33] <asac> ogra-maemo: yea wich is the bug
[23:33] <liw> persia, does DHCP provide hostnames or just domain names? (system hostname and network interface domain names have zilch to do with each other...)
[23:33] <asac> ogra-maemo: http://mail.gnome.org/archives/networkmanager-list/2008-September/msg00291.html
[23:34] <persia> liw: It provides network node names.  There's no reason that one can't use that to populate the system host name (and many environments choose to do this).
[23:34] <ogra-maemo> we do that in ldm, subscribe me to the bug, i'll take a look tomorrow
[23:34] <infinity>   option host-name "S01060005023e7454";
[23:34] <persia> liw: Note that the DHCP node name may have absolutely nothing to do with the value of the PTR record for the provided IP address.
[23:34] <ogra-maemo> thats a silly statement in that mail
[23:35] <infinity> liw: host-name is provided by many providers and on many corporate networks, so forward/reverse all match your IP.
[23:35] <asac> ogra-maemo: which?
[23:35] <infinity> liw: Whether or not this should be USED on a sane UNIX-like system is an entirely different story.
[23:35] <liw> infinity, yeah, and that has nothing to do with what the computer is called
[23:35] <asac> ogra-maemo: i think he means "hostname" vs. "ip"
[23:35] <infinity> asac: Does NM not use the provided hostname if a static one is set in /etc/hostname?  Please tell me it doesn't...
[23:35] <ogra-maemo> asac, the one about the issue indeed :)
[23:35] <slangasek> yes, the network I'm connecting my laptop to should *not* get a vote on my hostname
[23:35] <persia> liw: Well, it may.  Many large corporate environments enforce identity between host name, node name, and PTR reference.
[23:36] <asac> infinity: thats my ttask ;)
[23:36] <slangasek> persia: that's fine, but it's not a sane default
[23:36] <liw> persia, then they can go and enable things and let the sane parts of the world have a sensible default
[23:36] <asac> infinity: e.g. to do that in the debian backend
[23:36] <persia> slangasek: No disagreement.  I'm just defending the existence of the use case, not the sanity thereof.
[23:37] <liw> persia, I note that many large corporations do lots of other insane things that most others should not do...
[23:37] <infinity> slangasek: I like it for cluster/node computing, where the system knows nothing about itself, except what the boot server told it.  But, yeah, for a worksation/laptop, it's ludicrous.
[23:37] <jcristau> surely they can also run xhost in their session scripts, then
[23:37] <infinity> slangasek: I just about choked when I powered up my YDL machine here, and saw that it was called "masq-012" (the forward/reverse for the IP it got on my internal network)
[23:38] <persia> Well, it's rather unlikely one is running an X server on a cluster node anyway.
[23:38] <jcristau> persia: or NM
[23:38] <infinity> ... which just makes the NM usecase that much more ludicrous, but whatever. :)
[23:39] <ogra-maemo> asac, i meant the statement that xauth isnt needed with local users above too be silly btw
[23:39] <wgrant> NM isn't just for the X-dwelling universe any more, is it?
[23:39] <asac> ogra-maemo: whats the problem with that? do fedora and opensuse have a security issue?
[23:40] <ogra-maemo> is unix multiuser or what ?
[23:40] <ogra-maemo> i would call it one, yes
[23:40] <wgrant> Permissions on UNIX sockets work well.
[23:40] <ogra-maemo> well ...
[23:40] <asac> ogra-maemo: http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-xinit/devel/localuser.sh?revision=1.2&view=markup
[23:41] <asac> thats the proposed implementation
[23:41] <asac> ogra-maemo: its bug 276357
[23:43] <wgrant> Won't this break sudo in some circumstances?
[23:44] <ogra-maemo> asac, i'd go with xauth add with a fresh cookie... but xhost migth serve the same purpose
[23:45] <asac> ogra-maemo: sounds more difficult to set a fresh cookie
[23:45] <asac> ogra-maemo: to fix the general issue we would need to have a hook that gets triggered when hostname is updated
[23:45] <ogra-maemo> mcookie is your friend, you  just add it to the existing set
[23:46] <ogra-maemo> yeah
[23:46] <asac> ogra-maemo: how to trigger the update. NM is probably not the right place
[23:46] <ogra-maemo> might be, i have to look at it with less wine in my blood :)
[23:47] <ogra-maemo> i'll take a look tomorrow
[23:47]  * ogra-maemo notices that on screen keyboards help  his typoing :)
[23:47] <asac> ogra-maemo: if you have ideas post them in the bug ;)
[23:48] <ogra-maemo> i will
[23:49] <wgrant> ogra-maemo: Do they help your typoing, or did you typo typing?
[23:49] <ogra-maemo> the former :)
[23:50] <ogra-maemo> the thing is  that if you have to look at the keys, yor fingers  can't misbehave silently :)
[23:51] <ogra-maemo> heh, i typoed :)
[23:52] <Ng> persia: maybe not a cluster node, but you might on a machine in a large pool of thin clients, for example
[23:52] <ogra-maemo> though it's stil impressive how fast and precise you get with some training
[23:52] <persia> Ng: Indeed.  Classroom environments would be a good model.
[23:53] <Ng> persia: yeah
[23:53] <ogra-maemo> yeah.. and you might  have apps that only pulled the hostname on startup and cache it