[00:08] <mathiaz> slangasek: is there a reason why the openldap group is not allowed to read the content of /var/lib/ldap ?
[00:08] <mathiaz> slangasek: in intrepid, the openldap group is allowed to read /etc/ldap/slapd.d/
[00:08] <slangasek> mathiaz: I'm gonna say "bug"
[00:09] <slangasek> well, "oversight"
[00:09] <slangasek> since the only user in the openldap group is normally the 'openldap' user, and that user /owns/ the dir, it's not an issue anyone's noticed before
[00:09] <mathiaz> slangasek: ok - so the permissions on /etc/ldap/slapd.d/ and /var/lib/ldap/ should be 0750 ?
[00:10] <slangasek> whereas openldap did specifically have read rights on /etc/ldap/slapd.conf before, because the config was owned by root and read-only by the openldap user
[00:10] <slangasek> yes, that sounds appropriate to me
[00:10] <mathiaz> slangasek: ok - however /var/run/slapd/ needs to be rx for other too
[00:11] <mathiaz> slangasek: since the ldapi socket is located in there.
[00:11] <slangasek> true
[00:11] <mathiaz> slangasek: ok - I'm going to fix all of this then.
[00:17] <cjwatson> hmm, strace of bash reading a pound sign (U+00A3 POUND SIGN, not #) typed at a prompt:
[00:17] <cjwatson> 18:11:14.527910 read(0, "\302", 1)      = 1
[00:17] <cjwatson> 18:11:16.898828 write(2, "\302", 1)     = 1
[00:17] <cjwatson> 18:11:16.899325 read(0, "\243", 1)      = 1
[00:17] <cjwatson> 18:11:16.899872 read(0, "\r", 1)        = 1
[00:17] <cjwatson> 18:11:19.818306 write(2, "\n", 1)       = 1
[00:17] <cjwatson> so where did \243 go, eh?
[00:58] <mathiaz> slangasek: while trying to fix dpkg-reconfigure slapd, I've run into the issue of backups. dpkg-reconfigure slapd works the first time, but fails the second time since there is already a backup directory in /var/backups/.
[00:58] <slangasek> mathiaz: hrm, interesting
[00:58] <mathiaz> slangasek: should the backup directory be erased ? or create another one ?
[00:59] <mathiaz> slangasek: the naming scheme of backup directory allow for one backup per package version.
[01:00] <mathiaz> slangasek: could a timestampt be added to the directory name ?
[01:00] <slangasek> right; I don't think we want to overwrite in all cases, because in some of those cases that means overwriting a good backup with a bad
[01:00] <slangasek> timestamp could be ok, I suppose
[01:01] <mathiaz> slangasek: if so what about proliferation of backup directories ?
[01:01] <mathiaz> slangasek: It's a corner case though.
[01:02] <slangasek> <punt> :)
[01:16] <hikenboot> can anyone tell me if the python provided in ubuntu has been packaged so one could select a minimum for use with xen and xen tools currently I am building a distro with  something called T2 which is based on  slackware and it has a 40 MB install of python that I would like to minimize and am looking for a distro that might have already done this work
[01:19] <mathiaz> slangasek: hm - the issue comes from the database backup from /var/lib/ldap. Adding a timestamp is implemented in the script but it won't work as expected.
[01:19] <slangasek> mathiaz: because we need to be able to read from it again in a different script?
[01:19] <mathiaz> slangasek: dumping a database and loading a database happened at different times
[01:19] <mathiaz> slangasek: yes
[01:19]  * slangasek nods
[01:20] <mathiaz> slangasek: however the use of a timestamp is conditional
[01:20] <mathiaz> slangasek: if OLD_VERSION is not set then a timestamp is used
[01:20] <slangasek> ok
[01:21] <mathiaz> slangasek: so that's not a problem on upgrades.
[01:21] <slangasek> in this case, I guess $OLD_VERSION is set to the current version?
[01:21] <mathiaz> slangasek: right
[01:21] <mathiaz> slangasek: so the timestamp is never used IIUC.
[01:22] <mathiaz> slangasek: and when you run dpkg-reconfigure slapd the second time, it fails.
[01:22] <slangasek> I guess it would be used if /var/lib/ldap somehow existed, but the package wasn't previously installed
[01:22] <slangasek> but having it be used when $OLD_VERSION == $current_version sounds like it might be a good idea
[01:23] <mathiaz> slangasek: may be - I'd have to look into that.
[01:23] <mathiaz> slangasek: I've also read some code that checks for reconfigure as the mode
[01:24] <mathiaz> slangasek: or checks for DEBCONF_RECONFIGURE
[01:24] <slangasek> reconfigure as the mode doesn't actually work today
[01:24] <slangasek> I'm not sure if DEBCONF_RECONFIGURE is something that gets set
[01:24] <slangasek> but that could be a good option, yes
[01:24] <mathiaz> slangasek: I think that DEBCONF_RECONFIGURE works.
[01:38] <slangasek> lool: was elisa-plugins-ugly meant to have an 0.5.9 version in Debian? (bug #262805)
[01:38] <ubottu> Launchpad bug 262805 in elisa-plugins-ugly "Please sync elisa and plugin packages from Debian experimental" [Undecided,Confirmed] https://launchpad.net/bugs/262805
[01:48] <slangasek> superm1|away: what's "the ogre mdel"?
[01:48] <slangasek> model
[01:54] <wgrant> slangasek: ogre-model is Soyuz's mangling of sources.list.
[01:55] <wgrant> slangasek: Particularly the set of components that a component is allowed to build against.
[01:55] <wgrant> (or other archives in the case of non-primary)
[01:55] <slangasek> ah.  where does the "ogre" fit in? :)
[01:56] <ajmitch> the ogre chews stuff up & spits it out?
[01:56] <wgrant> Same way gina, kate, britney, Soyuz, etc. do, I guess.
[01:56] <wgrant> *katie
[01:56] <wgrant> But I don't know.
[01:56] <wgrant> Nobody ever said that archive manager component names had to be sensible.
[01:56] <slangasek> hmm, all those others I know the etymology of. :)
[01:57] <wgrant> I guess you'll have to poke cprov. I'd be interested to know too.
[02:13] <wgrant> Aha, it's a cprov.
[02:14] <cprov> wgrant: yes, can I help you ?
[02:15] <wgrant> cprov: slangasek and I were wondering what the ogre in ogre-model meant.
[02:22] <cprov> wgrant: see http://en.wikipedia.org/wiki/Shrek_(character)
[02:23] <cprov> wgrant: "...similarities between ogres and onions, observing both have *layers*..."
[02:23] <wgrant> cprov: Aha, nice.
[02:23] <cprov> wgrant: ubuntu components too ;)
[02:23] <wgrant> Good choice.
[02:23] <cprov> dsilvers idea ;)
[02:31] <wgrant> Any other strange etymologies to be aware of?
[03:38] <apachelogger> slangasek: hi, I attached a revised patch to bug 272383
[03:38] <ubottu> Launchpad bug 272383 in kdebase-runtime "package kdebase-runtime 4:4.1.1-0ubuntu1~hardy1~ppa1 [modified: usr/lib/kde4/lib/kde4/libexec/kdesu] failed to install/upgrade: tentative de remplacement de ??/usr/bin/ksvgtopng??, qui appartient aussi au paquet kdelibs4-dev" [High,In progress] https://launchpad.net/bugs/272383
=== superm1|away is now known as superm1
=== thegodfather is now known as fabbione
[05:35] <dholbach> good morning
=== persia_ is now known as persia
[06:56] <persia> TheMuso: There's been a rash of requests from ~teresadd1-0 to be unsubscribed from bugs.  Would you mind deactivating the user from ~ubuntu-audio?
[07:04] <TheMuso> persia: Sure.
[07:05] <persia> TheMuso: Thanks.  Sorry for the confusion.  Please feel free to direct them my way if there are questions about the deactivation.
[07:05] <TheMuso> persia: is that possible?
[07:06] <TheMuso> hang on, getting used to the new interface.
[07:06] <persia> TheMuso: When you deactivate someone, there is a text entry box for a comment.
[07:06] <TheMuso> persia: Right.
[07:07] <persia> So, since you might not be tracking all the "Please unsubscribe" bugs, if you want to blame me, that's fine :)
[07:07] <TheMuso> Done.
[07:08] <TheMuso> no I have seen a few of them, and thought they were only subscribed to the bugs themselves. Obviously they didn't know what they were getting themselves into. Many a time someone adds themselves to ubuntu-audio, only to leave a short time later due to the massive amounts of bug mail.
[07:08] <anilg> how do I regenerate release and release.gpg using debarchiver?
[07:08] <anilg> I have a .conf in my incoming directoty
[07:09] <anilg> which specifies the gpg key, repository, etc
[07:09] <persia> heh.  Yeah.  I remember hearing that the audio bugmail had reached a million messages around feisty :)
[07:11] <TheMuso> persia: Wouldn't surprise me. I think I was a member then, but can't remember.
[07:15]  * TheMuso uploads the last of several packages to tie some loose ends with audio, at least for the beta.
[07:16] <Treenaks> *\o/*
[07:17] <RAOF> Woo!
[07:18] <RAOF> TheMuso: Incidentally, should I be upstreaming my pulseaudio 0.9.12 bugs or leaving them to you to do? :)
[07:18] <TheMuso> RAOF: If you are still using pa 0.9.12, you ya not see some of these changes immediately. I need to port them to the package in my PPA.
[07:18] <TheMuso> RAOF: Feel free to leave them with me, as I have a few other things to deal with upstream about.
[07:23] <RAOF> TheMuso: Cool.  I'll leave them with you then.
[07:29] <pitti> Good morning
[07:29] <dholbach> hi pitti
[07:30] <pitti> kirkland: https://wiki.ubuntu.com/DesktopTeam/Specs/Intrepid/DevicePermissions describes our current efforts
[07:31] <TheMuso> Anybody got any idea whats going on with scrollkeeper here? http://www.pastebin.ca/1209060
[07:31] <TheMuso> This is a local build on my machine.
[07:32] <nxvl> TheMuso: it's not calling sudo or something like that?
[07:33] <dholbach> TheMuso: I'd not run scrollkeeper-update during the build (is there a --disable-scrollkeeper?)
[07:33] <nxvl> TheMuso: or you are running it as normal user and it's not that inteligent to ask for root privileges
[07:34] <slangasek> that doesn't really explain the "/luke" directory; but yeah, running scrollkeeper-update in a build is pointless
[07:34] <dholbach> makes no sense to update the scrollkeeper index stuff on a build machine - dh_scrollkeeper should generate the maintainer script snippets
[07:34] <dholbach> when are we using rarian fully instead of scrollkeeper? :)
[07:34] <nxvl> well
[07:34] <nxvl> time to sleep
[07:34] <nxvl> have a nice day!
[07:35] <dholbach> sleep tight nxvl
[07:35] <nxvl> thank you!
[07:35] <slangasek> dholbach: afaik we already are?
[07:36] <TheMuso> dholbach: Gotcha there probably is, I'll have a look, thanks.
[07:37] <dholbach> slangasek: OK, good :)
[07:37] <dholbach> slangasek: seems it's still in main though
[07:38] <slangasek> I still parse the name "rarian" as "a Debian derivative using rar as the archive format", though
[07:39] <dholbach> hehe
[07:40] <dholbach> I had some time getting used to the name, I packaged it when it was still called spoon and then went for rarian :)
=== superm1 is now known as superm1|away
[08:12] <lool> slangasek: Yes, I'll still work on elisa-plugins-ugly; I didn't have time before going to Berlin, and it's just a set of additional plugins which don't prevent the player from working
[08:12] <slangasek> lool: ok - I was just noticing the task was still open
[08:13] <lool> Yup
[08:13] <lool> slangasek: (Did you see the python-dateutil MIR?)
[08:13] <lool> I need to do the python-cssutil one as well
[08:13] <slangasek> MIR team is --> that way
[08:13] <slangasek> (i.e., in Germany)
[08:20] <persia> slangasek: on bug #271627: it's really a release-manager call.  If you're happier to wait and hope someone uploads linux-ports-meta and fixes everything, we may want to keep the arch-specific NBS stuff.  If you'd rather expose the problem now, and point out that the current model isn't supportable for updates or security, it may be good to push it sooner.
[08:20] <ubottu> Launchpad bug 271627 in linux-meta "Please remove outdates ports binaries for linux-meta" [Undecided,New] https://launchpad.net/bugs/271627
[08:20] <Koon> slangasek: could you please have a look at bug 272134 ? It's the likewise-open microrelease I told you about last week
[08:20] <ubottu> Launchpad bug 272134 in likewise-open "[FFe] Update to 4.1.2982 bugfix microrelease" [Undecided,New] https://launchpad.net/bugs/272134
=== dholbach_ is now known as dholbach
=== Ng_ is now known as Ng
[10:07] <davmor2> I got a memory leak in an app that I use all day but I don't know which what's the best tool to use to find out?
[10:09] <wgrant> top
[10:09] <wgrant> M
[10:10] <seb128> valgrind
[10:21] <RicardoPerez> hi! anybody knows who's the xdg-user-dirs package maintainer?
[10:22] <seb128> RicardoPerez: there is none
[10:23] <seb128> RicardoPerez: I do the update but that's about it
[10:24] <RicardoPerez> seb128: thanks for the answer. I opened a bugreport (bug #271466) about the translations update. Is it what you're talking about?
[10:24] <ubottu> Launchpad bug 271466 in xdg-user-dirs "Please, update the xdg-user-dirs translations before Intrepid release" [Undecided,New] https://launchpad.net/bugs/271466
[10:24] <tjaalton> pitti: are you available to discuss about the hal/acpi-support/keymap-mess?
[10:25] <seb128> RicardoPerez: there is no need to open bugs every cycle about xdg-user-dirs, yelp, etc
[10:26] <seb128> RicardoPerez: we do update those translations before beta and before stable usually
[10:26] <seb128> we should probably get a list of packages that need translations update before beta and stable somewhere
[10:26] <Mirv> seb128: is there some process written down so all those are remembered and not depending on some developer's own memory?
[10:26] <seb128> Mirv: read what I just wrote? ;-)
[10:27] <RicardoPerez> seb128: ok, sorry about that. I opened that bug because the xdg-user-dirs was not updated on hardy & intrepid, and I didn't knew if it was normal. but again, sorry for that
[10:27] <Mirv> seb128: right :) so, not yet. but a really good idea to have something like that.
[10:27] <pitti> tjaalton: hi
[10:27] <seb128> RicardoPerez: no problem
[10:27] <liw> is there a wiki page that lists the members of the ubuntu release team?
[10:27] <pitti> tjaalton: it's indeed a mess; I wasn't too surprised that uninstalling acpi-support actually fixed it for one reporter
[10:27] <seb128> RicardoPerez: the translations should be in the language packs though no?
[10:28] <seb128> RicardoPerez: language-pack-gnome-en-base: /usr/share/locale-langpack/en_GB/LC_MESSAGES/xdg-user-dirs.mo
[10:28] <RicardoPerez> seb128: the xdg-user-dirs translations are in the xdg-user-dirs package, as I can see
[10:28] <Mirv> RicardoPerez: the source package should be updated so that live cd has all languages with up-to-date translations for xdg-user-dirs so that correct directories are created
[10:28] <RicardoPerez> $ dpkg -L xdg-user-dirs | grep "/es/LC_MESSAGES/xdg-user-dirs.mo"
[10:28] <RicardoPerez> /usr/share/locale/es/LC_MESSAGES/xdg-user-dirs.mo
[10:28] <davmor2> wgrant: top doesn't show it up it's only a small amount that I think simply isn't closing once used and all the apps I use all day bounce position valgrind one app at a time is more tempting though.  Thanks for the info
[10:29] <seb128> RicardoPerez: right, read the changelog about that
[10:29] <Mirv> to seb128, that is.
[10:29]  * liw finds https://launchpad.net/~ubuntu-release/+members
[10:29] <tjaalton> pitti: yeah.. I'd like to understand the role that hal plays with it, and how it all _used_ to work together in hardy
[10:29] <seb128> Mirv: right, I said before I'll update those before beta
[10:29] <RicardoPerez> seb128: oh, great. I just read it, I now know what you say
[10:30] <tjaalton> pitti: but if you are here in, say, 20min, I'll go and grab some lunch first?
[10:30] <pitti> tjaalton: yes, I will be
[10:30] <RicardoPerez> seb128: so, are the xdg-user-dirs.mo file in both xdg-user-dirs package and the langpacks?
[10:31] <tjaalton> pitti: ok cool, later
[10:31] <liw> pitti, other release team members: I'd like to upload a new system-cleaner to fix #271234 and #271390, but they change the UI (command line and GTK both); would that be acceptable?
[10:31] <seb128> RicardoPerez: right, and in such case the system one is used first so we need to update the package
[10:31] <seb128> RicardoPerez: I'll do that before beta
[10:31] <RicardoPerez> seb128: great, I understand now!
[10:31] <RicardoPerez> seb128: thanks for the explanation
[10:31] <seb128> no problem
[10:32] <RicardoPerez> thanks again to everybody, cheers :)
[10:32] <Mirv> seb128: what would be a good wiki page name for the "translation stuff that needs manual intervention for a release". though it's partially the same as https://wiki.ubuntu.com/NonLanguagePackTranslationDeadline
[10:33] <Mirv> for example debian installer translations have to be manually exported and imported (not done for intrepid)
[10:33] <pitti> liw: if the doc team is ok with that, fine for me; I don't expect that ubuntu-docs mentions the system cleaner yet, but it would be worth pinging them
[10:33] <Mirv> and ddtp needs manual syncinc from Debian and upload to repos
[10:33] <liw> pitti, ack, thanks
[10:33]  * liw now needs to find the doc team
[10:36] <murdok> Hey pitti , could you mark my bug 270335 as wishlist? Someone told me to ask it to you
[10:36] <ubottu> Launchpad bug 270335 in apport "Feature: Support saving bug reports" [Undecided,New] https://launchpad.net/bugs/270335
[10:37] <pitti> murdok: done, thanks
[10:37] <murdok> pitti: thank you
[10:43] <bigon> does anybody know where the perl function Dpkg::Changelog::find_launchpad_closes is defined?
[10:44] <jcristau> bigon: /usr/share/perl5/Dpkg/Changelog/mumble.pm?
[10:46] <jcristau> or just Changelog.pm actually...
[10:52] <bigon> jcristau, thx
[11:07] <pitti> didrocks: there?
[11:08] <didrocks> pitti: yes, hi :)
[11:08] <pitti> didrocks: just doing your g-v-m sponsoring
[11:08] <pitti> didrocks: you kept 02_fix_autokeyboard_gconf.patch, but upstream already applied a fix
[11:08] <didrocks> pitti: thx, is everything ok?
[11:08] <pitti> didrocks: did you test this without the patch, is it really not working still?
[11:08] <TheMuso> asac: FYI if you hadn't noticed already, I uploaded changes earlier so that all alsa apps will use pulse if pulse is running. If pulse is not running/not installed, there will be no change, apps will still use alsa/dmix.
[11:08] <didrocks> pitti: let me check
[11:09] <pitti> didrocks: if not, it should be reported to gnome bug 525345 and reopened
[11:09] <ubottu> Gnome bug 525345 in general "AUTOKEYBOARD missing in gconf enum" [Major,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=525345
[11:09] <asac> TheMuso: rock!
[11:09] <asac> TheMuso: which package and version am i looking for (to test)?
[11:10] <pitti> didrocks: also, your patch includes it in ENABLE_AUTOMOUNT, it shouldn't
[11:12] <TheMuso> asac: alsa-lib 1.0.17a-0ubuntu2, alsa-plugins 1.0.17-0ubuntu2, and pulseaudio 0.9.10-2ubuntu4. Alsa-plugins is not so important, but its useful as I updated the code for the pulse plugin to the latest code, which performs much better.
[11:13] <didrocks> pitti: yes, that's the reason, I was waiting it for found it in ENABLE_AUTOMOUNT
[11:13] <TheMuso> asac: binary packagse for alsa are libasound2 and libasound2-plugins
[11:13] <didrocks> strange that I didn't see it in searching over it with vi
[11:14] <didrocks> pitti: so, the patch can be removed
[11:14] <pitti> didrocks: ok, thanks for checking
[11:14] <didrocks> pitti: sorry for the mistake
[11:14] <pitti> didrocks: no problem
[11:15] <didrocks> pitti: do you want me to redo a new diff.gz?
[11:15] <pitti> didrocks: don't worry, already on it
[11:15] <didrocks> pitti: thx :)
[11:18] <pitti> didrocks: uploaded
[11:18] <didrocks> pitti: thanks a lot!
[11:22] <tkamppeter> pitti, I tried the new Jockey yesterday but it FTBFS, both on my box and on buildds, Have you fixed it?
[11:22] <pitti> tkamppeter: locally, I'll do an upload today
[11:26] <ogra> cjwatson, i copied the task headers into the mid seed as well, can you do the soyuz stuff for ubuntu-mid as well please ?
[11:26] <ogra> (tell me if you need another reminder mail :) )
[11:27] <cjwatson> ogra: it's done at a seed collection (or branch) level, not an individual seed level
[11:27] <cjwatson> ogra: so we just need to get the whole mobile.intrepid seeds honoured, and then individual seeds within that will happen automatically
[11:27] <ogra> ah, k so it happens automatically, great
[11:29] <asac> cjwatson: pitti: bug 273514
[11:29] <ubottu> Launchpad bug 273514 in libmbca "MIR - include libmbca and mobile-broadband-provider-info in main" [Undecided,Confirmed] https://launchpad.net/bugs/273514
[11:40] <pitti> asac: ack
[11:41] <tjaalton> pitti: back. Booted hardy livecd, and confirmed that xev does not show any of the hotkeys, which is not that surprising. but they do work though
[11:42] <pitti> tjaalton: oh, it doesn't? so in hardy they were consumed directly by acpid or hal?
[11:42] <tjaalton> pitti: yes
[11:42] <pitti> tjaalton: it almost seems to me that acpi-support scripts and hal/hal-infoquirks/pm-utils are working/racing against each other
[11:42] <tjaalton> pitti: now evdev grabs the input device created by thinkpad_acpi, so they are not passed on
[11:42] <pitti> but that shouldn't have changed since hardy
[11:43] <tjaalton> not all of them anyway
[11:45] <kwwii> mvo, pitti: just wondering about the packages that I discussed per email...did they all make it in?yet?
[11:46] <pitti> kwwii: haven't caught up with that yet; I sent you a reply with some change requests over the weekend
[11:48] <kwwii> pitti: right, I was waiting to make sure that mvo didn't do it already :-)
[11:49] <kwwii> pitti: I will fix up that stuff and add another package with a wallpaper, finished later today
[11:49] <ogra> in which order do i have to do the bzr tagging ? changelog entry first an then bzr tag or the other way round ?
[11:50] <pitti> ogra: "use debcommit -r, Luke"
[11:50] <ogra> hmm
[11:50] <kwwii> no doubt...debcommit is the way to go
[11:50] <ogra> i have done dch already, will that mess up anything ?
[11:50] <kwwii> then just do debcommit
[11:50] <ogra> (i.e. do i need to revert that before =
[11:50] <pitti> ogra: dch -r will do the UNRELEASED -> intrepid bit
[11:50] <pitti> ogra: and debcommit -r will commt that change and tag it
[11:50] <ogra> i always do -i :)
[11:51] <pitti> ogra: no, dch is fine
[11:51] <ogra> ok
[11:51] <ogra> pffft
[11:51] <pitti> ogra: but in general, I think it's "commit, then tag"
[11:51] <ogra> yeah
[11:51] <pitti> that's what I use anyway
[11:51] <ogra> i already commited :/
[11:52]  * ogra uncommits 
[11:52] <ogra> ah, that looks better
[11:54] <ogra> grrr
[11:55]  * ogra curses ... 
[11:55]  * soren pats ogra on the head
[11:55] <ogra> setting DEBEMAIL helps :/
[11:56] <ogra> sigh, and teher is no bzr untag
[11:56] <Keybuk> ogra: bzr tag --delete
[11:56] <ogra> ah
[11:56] <ogra> gracias
[11:57] <siretart> Keybuk: if you have a minute, could you have a look and give your opinion on bug #71418 please?
[11:57] <ubottu> Launchpad bug 71418 in sysvinit "/etc/init.d/(halt|reboot) disables WoL" [Low,Confirmed] https://launchpad.net/bugs/71418
[11:58] <ogra> grmbl ... doesnt work for pushed changes indeed :/
[11:59] <Keybuk> siretart: my opinion can be found at https://bugs.edge.launchpad.net/upstart/+bug/92685 already ;)
[11:59] <ubottu> Ubuntu bug 92685 in upstart "noisy halt if /proc/ide doesn't exist" [Wishlist,Invalid]
[11:59] <Keybuk> "both downing drives and interfaces should be things the kernel does these days"
[12:00] <siretart> Keybuk: I read this as agreement that the NETDOWN variable should default to 'no'. right?
[12:00] <Keybuk> siretart: no, I'll just take the -i option out of reboot one day so it won't matter what the NETDOWN variable is :p
[12:00] <Keybuk> it's too late to change that variable for intrepid anyway
[12:02] <siretart> Keybuk: I still don't get how removing the '-i' can potentially harmful. could you elaborate a bit?
[12:03] <Keybuk> siretart: the fact you don't understand why it is yes is precisely the reason it shouldn't be changed this late in a cycle
[12:03] <Keybuk> *I* don't understand why it is yes either
[12:03] <Keybuk> but clearly someone felt it was important
[12:03] <Keybuk> and since it has always been yes, that means by changing it, you may turn up new bugs
[12:04] <siretart> so lets set it to yes after jaunty opens and see what breaks?
[12:08] <Keybuk> siretart: that would be my choice
[12:08] <siretart> ok. I'll copy that to the bug
[12:12] <pitti> cjwatson, slangasek: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt -> that's just too good to be true, so I guess something went wrong?
[12:13] <cjwatson> pitti: I'll fix it, thanks
[12:13] <cjwatson> IOError: [Errno 2] No such file or directory: '/srv/launchpad.net/ubuntu-archive/ubuntu-germinate//all_edubuntu_intrepid_i386'
[12:13] <pitti> ah :)
[12:13] <pitti> cjwatson: cheers
[12:13] <StevenK> Is component-mismatches-mobile.txt now dead, too?
[12:14] <StevenK> I remember pitti raising that, but didn't see if it was resolved.
[12:14] <cjwatson> yes
[12:14] <cjwatson> cron.germinate is failing, that's the real problem
[12:15] <cjwatson> RuntimeError: maximum recursion depth exceeded
[12:15] <cjwatson> oopsie
[12:15]  * cjwatson may have, err, slightly broken germinate
[12:16] <ogra> infinity1, (oh, are there multiple ?) ... ping ... i added ubuntu-mobile to livecd-rootfs can you update teh build server to 0.69 so i can get a squashfs, looking at how the livecd imges are built though you seem to rename te resultig files though, tat might be something to talk about (as mine would also be called i386.*)
[12:16] <cjwatson> ogra: it's updated from a daily cron job, IIRC
[12:16] <ogra> ah, cool
[12:16] <cjwatson> oh, well, not sure if the mobile one is
[12:16] <cjwatson> the livefs buildds are
[12:16] <ogra> though that still doesnt solve the file naming
[12:16] <StevenK> The mid one is, but that's for lpia only
[12:16] <cjwatson> our livefses are renamed too
[12:16] <cjwatson> can't you just deal with it? :)
[12:17] <StevenK> I think it's keyed off $PROJECT, though
[12:17] <ogra> i just fear we use the same names
[12:17]  * ogra goes to take a look
[12:21] <ogra> aahhh ... its done in a per rpject subdir anyway ... ok
[12:21] <ogra> *project
[12:21] <StevenK> Like I said, keyed off $PROJECT
[12:21] <ogra> right
[12:22] <ogra> well, i have to see code to understand sometimes :)
=== Nafallo_ is now known as Nafallo
[12:39] <ulaas> hi! 2.6.27-4-generic missing nvidia kernel module. correct?
[12:40] <pitti> ulaas: no, they aren't in the kernel any more
[12:40] <pitti> ulaas: nvidia and fglrx are packaged separately now, independently from the kernel and its abi
[12:40] <ulaas> pitti: very good. are packages rolled out already?
[12:41] <pitti> ulaas: nivida-glx-{71,96,173,177}
[12:41] <pitti> ulaas: jockey handles them quite nicely nowadays, so maybe just use the hardware drivers app
[12:41] <pitti> ulaas: yes, they've been in intrepid for months
[12:42] <stefanlsd> is the jockey* stuff the preferred way?
[12:43] <pitti> stefanlsd: it's the most GUI friendly way, anyway; and I appreciate feedback whether it works :)
[12:44] <stefanlsd> k. is it the default or something we should install?
[12:44] <ulaas> pitti: it does not for me.
[12:44] <ulaas> pitti: when i click install and turn on nothing happens.
[12:45] <pitti> stefanlsd: we ship jockey by default, and nvidia detection and driver installation sohuld work out of the box
[12:45] <pitti> ulaas: hm, interested in debugging it?
[12:45] <ulaas> pitti: thats why i use intrepid :)
[12:45] <ulaas> hmm just clicked the older one on the list which was 173
[12:45] <ulaas> now it downloads
[12:46] <ulaas> lemme get back with the results
[12:46] <pitti> ulaas: which versions does it offer to you?
[12:47] <ulaas> 177 and 173
[12:47] <ulaas> 177 was already looked installed in synaptic
[12:47] <pitti> and both are disabled, and clicking on 177 doesn't do anything?
[12:47] <pitti> oh
[12:47] <ulaas> so thats why clicking that one did not do anything but also did not report
[12:48] <pitti> ulaas: so it was shown as disabled, the package is installed, and enabling it didn't work? (i. e. it was still shown as disabled afterwards)
[12:48] <ulaas> pitti: exactly
[12:48] <pitti> ok, I'd like to debug this, it should certainly at least give you an error message
[12:49] <ulaas> pitti: i am your man... jockey just died on me now. i was trying to switch to 177 after a succesfull enable to 173
[12:50] <pitti> ulaas: ok, let's do that in /query
[12:52] <asac> pitti: i assume you still have too much backlog from plumbers to do MIRs today?
[12:52] <asac> err MIRs == this MIR ;)
[12:52] <pitti> asac: I can do high urgency stuff
[12:52] <pitti> rest on Friday on archive day
[12:53] <asac> pitti: yeah its high urgency ;) ... needs to be in for BETA and i need some broader testing before that
[12:53] <pitti> asac: ok
[12:53] <asac> pitti: but i think cjwatson also offered to help out
[12:55] <pitti> tseliot, superm1|away: hm, seems that ulaas installed two nvidia driver versions at the same time; shouldn't they conflict to each other?
[12:56] <tseliot> pitti: yes, they Conflct/Replace each other
[12:56] <pitti> tseliot: oh, indeed, sorry; "rc" != "ii: :)
[12:57] <tseliot> pitti: ???
[12:57] <pitti> tseliot: (dpkg -l output)
[12:57] <tseliot> aaah
[12:57] <tseliot> ok
=== warp10_ is now known as warp10
[13:21] <pitti> hey warp10
[13:22] <warp10> hi pitti
[13:24] <digistyl3> hi everyone, does your gnome session remember the last used applications?
[13:26] <digistyl3> i mean the running applications
[13:26] <jerone> digistyl3: it can if you check the option "Automatically remember running applications when logging out" under the Session options
[13:26] <digistyl3> jerone: i did
[13:27] <seb128> digistyl3: no, it's not working in gnome-session 2.24
[13:27] <digistyl3> seb128: so it's a gnome bug and we should wait for upstream to release a fix?
[13:28] <seb128> digistyl3: right, bug or feature not implemented in the gnome-session rewrite
[13:28] <digistyl3> ok, thanks :)
[13:28] <digistyl3> anyone tried running vmware with intrepid as host?
[13:30] <jerone> digistyl3: shouldn't you be using KVM ;-) ... havn't tried it but I can imagine that vmware modules don't compile with 2.6.27
[13:30] <pitti> digistyl3: on my amd64 machine, but it has a pretty old install (alpha2 or so)
[13:31] <digistyl3> jerone: i've got some new module sources, it compiles and runs but keyboard doesn't work in the VM
[13:32] <digistyl3> i think i'll give virtualbox a shot, although i had some problems with it in kubuntu intrepid
[13:36] <siretart> seb128: I hope you don't mind that I cc'ed you ;)
[13:36] <seb128> siretart: not at all, thanks for sending this email!
=== LucidFox_ is now known as LucidFox
[13:49] <tseliot> seb128: I have noticed that stable releases of some gnome packages are available in Intrepid. Does this mean that I'll have to rewrite my patch for the gnome-control-center to be Ubuntu specific?
[13:49] <seb128> tseliot: yes
[13:50] <tseliot> seb128: ok, I'll do it, thanks
[13:50] <seb128> thank to you for working on those changes ;-)
[13:53] <tjaalton> is SJC the closest airport to Mountain View?
[13:57] <TheMuso> ./c
=== luisbg_ is now known as luisbg
=== pedro__ is now known as pedro_
[14:00] <lool> seb128: Something really weird is happening to glib2.0's builds
[14:00] <lool> http://launchpadlibrarian.net/17838229/buildlog_ubuntu-intrepid-amd64.glib2.0_2.18.1-1_CHROOTWAIT.txt.gz
[14:01] <seb128> lool: that was an is issue, I'll retry everything which failed due to that yesterday
[14:01] <seb128> lool: how did you notice? ;-)
[14:02] <lool> libglib-data uninstallable since multiple runs
[14:02] <lool> seb128: Who's supposed to reschedule the glib builds?  (I understand the issue has been fixed)
[14:03] <seb128> lool: I just did
[14:03] <lool> Ah thanks
[14:03] <seb128> no problem, thanks for pointing it, I was not sure if the soyuz guys were going to kick everything which failed due to that or not and apparently they didn't
[14:09] <dholbach> pitti: what does RoQA in removals.txt mean?
[14:10] <cjwatson> dholbach: "request of QA", i.e. Debian QA team
[14:10] <dholbach> ah ok - thanks a lot
[14:23] <Keybuk> ScottK-vacation: if you change a 3 year old bug from Fix Released to Incomplete ... it helps to offer an explanation
[14:24] <Hobbsee> Keybuk: surely not!  He's testing your skill of mindreading!
[14:34] <jdong> heh, what's up with this whole e1000e fiasco?
[14:48] <ogra> tjaalton, are there plans for fixing the psb driver ? seems it doesnt work for many people on i386
[14:48] <ogra> (teh 2D one)
[14:49] <tjaalton> ogra: the mobile guys have a newer version "somewhere"
[14:49] <ogra> tjaalton, i am a "mobile guy" :)
[14:50] <ogra> lool, ^^ do we have anything newer than whats in current xorg for 2D ?
[14:53] <tjaalton> ogra: a simple rebuild should make it work again, I think
[14:53] <ogra> yeah, thats what i thought
[14:53] <tjaalton> oh sorry, no it wouldn't
[14:54] <tjaalton> I'll try
[14:55] <tjaalton> ogra: see bug 235288 about the "new" driver..
[14:55] <ubottu> Launchpad bug 235288 in xserver-xorg-video-psb "X doesn't autodetect PSB driver" [Undecided,New] https://launchpad.net/bugs/235288
[14:55] <tjaalton> should be hidden in the PPA ;)
[14:55] <lool> ogra: Well the psb driver doesn't come from xorg, but I'm happy if the xorg people can help us
[14:55] <lool> ogra: There are many components involved
[14:55] <lool> ogra: One being drm
[14:55] <ogra> well, i'd like at least 2D
[14:55] <ogra> which shouldnt need drm
[14:55] <lool> ogra: psb needs the psb drm for modesetting I think
[14:56] <ogra> hrm
[14:56] <lool> 3D is yet another beast, but I can tell you for sure the kernel bits are in use even if you don't do 3D; and I think the psb drm is part of them
[14:57] <ogra> damned
[14:57] <ogra> thats the one that wont be ready before release, right ?
[14:57] <lool> Now the psb drm has been tentatively ported over by amitk for intrepid
[14:57] <ogra> but only to lpia i guess
[14:57] <lool> It's in linux-lpia, which we could build for i386
[14:57] <lool> (which is why I suggested it should really be linux-intel-mid)
[14:58] <ogra> it would be great to have in i386
[14:58] <lool> (or similar)
[14:58] <lool> Now, another bit which needs porting from hardy is ... libdrm
[14:58] <lool> And finally, xserver-xorg-video-psb might need an update in intrepid for xserver 1.5; not sure how things break there, but it's likely to take some little fixing at least
[14:59] <amitk> lool: no it isn't in lpia yet. I was away all of last week in Portland.
[14:59] <lool> amitk: Hope you're not too much jetlagged
[14:59] <ogra> bah, kernel guys always on holiday ...
[14:59]  * ogra hides
[15:00] <lool> amitk: persia mentionned that missing linux-meta for lpia prevent completing the install and subsequent boot of the lpia images   :-/
[15:00] <ogra> amitk, if you put it in, can you do it in a way that its built for i386 as well, or is that much effort ?
[15:00] <amitk> ogra: kernel sprint + plumbers conf
[15:00] <ogra> amitk, i know, i was just joking badly :)
[15:01] <amitk> lool: over the jet lag and back in action today. working on aufs and meta today
[15:01] <ogra> was hard to miss the plumbers conf ... thanks to greg
[15:01] <lool> amitk: Perfect, these are the ones I care about
[15:01] <lool> psb is the responsability of Intel to provide, so it's nice if we get it from you, but many things seem to be required to get it to work   :-/
[15:01] <lool> I think it's unlikely we get it for intrepid
[15:03] <lool> smarter, that's a good acronym
[15:04] <Treenaks> c
[15:04] <ogra> bah, mobile-default-settings-0.4 missed the publisher by a minute
[15:04] <ogra> grmbl
[15:11] <ogra> so if i get it right a first step is to have the psb.ids file in the package, right ?
[15:11]  * ogra adds that to xserver-xorg-video-psb
[15:11] <tjaalton> it still won't build
[15:12] <tjaalton> I gues..
[15:12] <tjaalton> +s
[15:13] <ogra> oh, right, the last build is from gutsy
[15:13] <ogra> sigh
[15:14] <tjaalton> right, won't build with the libdrm intrepid has, and it's not even ported to use libpciaccess
[15:15] <ogra> yeah, i had that issue with Xorg -configure ...
[15:15]  * ogra remembers
[15:15] <seb128> ogra: btw did you fix you epiphany-browser being triggered by something issue?
[15:16] <ogra> seb128, yep, the ubuntu-mobile metepackage did use tasks ... so it forcefully fulfilled the first recommends before looking at the second
[15:17] <ogra> seb128, btw, is teher a way o get the show desktop button tranparent without much hacking ? (see http://people.ubuntu.com/~ogra/mobile/) ... not urgent for intrepid though, but if it would be a small thing i'd love to have it
[15:17] <seb128> ok, so not a buggy recommends on the GNOME side, good ;-)
[15:17] <ogra> yeah
[15:17] <ogra> i'm waiting for soyuz and the metapackage should be fine
[15:18] <seb128> ogra: the button is transparent, that's the icon which is not, and I don't think so
[15:18] <ogra> ah
[15:18] <ogra> i'll try with a differet icon
[15:27] <Keybuk> wonder whether the reporter of bug #272744 is just complaining that we name wireless cards eth*, or am I missing a real issue?
[15:27] <ubottu> Launchpad bug 272744 in udev "Intrepid: Wireless card shows up as eth1" [Undecided,New] https://launchpad.net/bugs/272744
[15:37] <broonie> Keybuk: Is he not complaining that he can't work out how to rename it?
[15:37] <asac> Keybuk: yes, invalid i would say
[15:37] <asac> or wontfix :)
[15:38] <asac> Keybuk: but maybe he really has issues connecting now (given that its broadcom) and just doesnt get it right in the description ;)
[15:39] <Keybuk> broonie: right, if he changes it (why?!) and it gets unchanged, that would be a bug
[15:39] <Keybuk> asac: yeah, could be a bug caused by another problem
[15:40] <broonie> Some people like plain text names (I use them on big boxes since it was easier than remembering WTF eth0 is plugged into).
[16:02] <ogra> kwwii, heh, just editing the gtkrc of NewHuman for ubuntu-mobile ... i didnt know you changed your last name :)
[16:02] <ogra> # Authors:
[16:02] <ogra> # Kenneth Wimar <kwwii@ubuntu.com>
[16:03] <cjwatson> he's in the transition process to become a republic; one letter at a time
[16:04] <ogra> lol
[16:06] <jdong> ok I'm a total idiot
[16:07] <jdong> I forgot I VMWare suspended a physical partition from VMWare and booted it natively.
[16:07] <jdong> e2fsck is done ravaging through and I've got a lot of presents in /lost+found
[16:07] <jdong> which seems to include most of /var/lib/dpkg because I ran a dist-upgrade
[16:08]  * jdong wonders if we have a "stupidest thing done to an Ubuntu install" wiki page
[16:09] <jdong> now I could just restore from a 1-month-old full backup, but before that it's time for more idiocy... building a hashtable of md5's to filenames based on the backup, seeing if I can find what this stuff in lost+found is :D
[16:10] <geser> jdstrand: have you time to look on bug 271020? From a quick look at the jhead source it looks to me as this bug might have be also a security issue
[16:10] <ubottu> Launchpad bug 271020 in jhead "jhead static string for -cmd too small" [Undecided,New] https://launchpad.net/bugs/271020
[16:12] <geser> jhead tries to strcpy() FileName (comes from argv[]) into a 400 byte large array on the stack
[16:13] <geser> so if one manages to construct the "correct" filename one might smash the stack
=== superm1|away is now known as superm1
[16:14] <munckfish> Which package owns/creates /etc/modules? I presumed it would be the kernel but I can't find ref to it in the maintainer scripts there. Also dpkg -S /etc/modules returns nothing.
[16:15] <jdong> *** stack smashing detected ***: jhead terminated
[16:16] <jdong> geser: confirmed; it is asking for a stack smashing attack
[16:17] <geser> munckfish: see the postinst for module-init-tools
[16:17] <fbond> Hi.  The apt configuration on Hardy has some Install-Recommends-Sections that I'd really like to override on the command-line (read: not by modifying a configuration file).  Is there *any* reasonable way to do this?
[16:17] <munckfish> geser: thx
[16:17] <fbond> In other words, I want to do an apt-get run that doesn't install any recommends at all, even if from these sections.
[16:18] <fbond> It is apparently not sufficient to use --no-install-recommends, I assume that is due to this configuration option (which overrides APT::Install-Recommends).
[16:18] <fbond> (Where "this configuration option" means APT::Install-Recommends-Sections)
[16:19] <fbond> Anybody have any advice?
[16:20] <psyke83> TheMuso, good work on the PA/ALSA updates, just want to ping you on a small patch that I recommend: attached to bug #258581
[16:20] <ubottu> Launchpad bug 258581 in alsa-utils "Please expand {set|unset}-pulseaudio macros (debdiff attached)" [Wishlist,Triaged] https://launchpad.net/bugs/258581
[16:23] <jdstrand> geser: looking...
[16:24]  * MacSlow almost cannot believe it
[16:25] <jdong> MacSlow: it is quite shocking to see code like that :D
[16:25] <jdstrand> geser: without looking at the code, the patch is just a bandaid, no? we really need to check the length of the copy to the static buffer
[16:26] <cjwatson> fbond: -o APT::Install-Recommends-Sections=#clear, I think
[16:26] <MacSlow> jdong, no... I just successfully logged in using the face-browser for the first time
[16:26] <fbond> cjwatson: thanks, I'll try it.
[16:26] <cjwatson> fbond: see apt.conf(5)
[16:26] <jdong> jdstrand: as I commented yeah, the patch is insufficient and probably a bad idea
[16:26] <jdong> jdstrand: should probably be malloc'ed instead at runtime
[16:26] <MacSlow> if I would drink (alcohol) I would do that now ... but being me I just celebrate it using a kiba
[16:26] <jdstrand> jdong: sorry, I didn't see your comment
[16:27] <pitti> MacSlow: congrats!
[16:27] <jdstrand> jdong: I see it now-- I just skipped to the bt
[16:27] <pitti> MacSlow: so you tamed it after all? :-)
[16:27] <jdong> jdstrand: how has this not been noticed for the past 5 years :-/
[16:27] <jdstrand> jdong: heh
[16:27] <jdong>     char TempName[200];
[16:27] <jdong>     strcpy(TempName, FileName);
[16:27] <jdong> *smack*....
[16:28] <MacSlow> pitti, well let's say I got around the biggest shortcoming of all ... no docs ... and Jon being on vacation/away (not sure)
[16:28] <jdstrand> jdong: this does not run with privileges, correct?
[16:28] <jdong> jdstrand: correct
[16:28] <pitti> MacSlow: McCann you mean?
[16:28] <pitti> MacSlow: he was at the Plumbers Conf, I spoke with him
[16:28] <jdong> jdstrand: most probably this will just lead to stack-protector tripping
[16:29] <MacSlow> pitti, now that I know what works how I can finally start giving the code shape, style and then focus on blinging it up as intended (and maybe give it a few MacSlow-twist)
[16:29] <MacSlow> pitti, ah he was there *sigh*
[16:29] <jdstrand> jdong: ok, then it isn't particularly serious-- user can much more easily destroy his system than via this overflow
[16:29] <jdstrand> jdong: but it obviously needs to be fixed
[16:29] <MacSlow> pitti, anyhow I feel like a mountain of rocks fell of my shoulders
[16:29] <MacSlow> off
[16:29] <jdong> jdstrand: right; the risk factor will be if it's used in some sort of CGI script
[16:29] <jdong> (which I hope nobody does...)
[16:30] <jdstrand> jdong: re stack-protector-- yes, but we didn't have that in dapper
[16:30] <jdstrand> jdong: oh, is jhead common in CGI?
[16:31] <jdong> jdstrand: I'm not sure; it is the most obvious way of parsing out EXIF tags from JPEG files so I wouldn't be surprised if various thumbnailersand photo gallery apps might use it
[16:31] <jdstrand> jdong: makes sense. I'll get a CVE for it
[16:32] <jdong>     // Make a temporary file in the destination directory by changing last char.
[16:32] <jdong>     TempName[a] = (char)(TempName[a] == 't' ? 'z' : 't');
[16:32] <jdong> for god's sake!
[16:32] <jdong> want a CVE for unsafe tempfile creation too? :D
[16:34] <pitti> lol
[16:34] <pitti> jdong: and that's in /tmp, of course, right?
[16:34] <jdong> pitti: it's in the destination directory of the jhead command
[16:34] <pitti> what is jhead?
[16:35] <pitti> oh, nevermind
[16:35] <pitti> found the package
[16:35] <jdong> jdstrand: add shell escape to the list too
[16:35] <jdong>                 e += sprintf(ExecString+e, "\"%s\"",TempName);
[16:35] <jdong>     a = system(ExecString);
[16:35] <jdong> ok can we just call this entire DoCommand function broken? :)
[16:35] <jdstrand> note to self, do not promote jhead to main...
[16:36] <pitti> jdstrand: yeah, not that an accident in the archive happens and it disappears entirely, or so
[16:37] <jdstrand> heh
[16:37] <Riddell> doko: is python3 for main or universe?
[16:38] <cjwatson> Riddell: universe
[16:39] <jdong> jdstrand / pitti: yeah looking through jhead.c it's just broken everywhere. For auto-resizing and other actions it builds unchecked lenght strings to send to DoCommand too
[16:39] <fbond> cjwatson: Eh, #clear doesn't work with -o (and the correct syntax is #clear APT::Install-Recommends-Sections;).
[16:39] <fbond> -o only expects to set values, from what I can tell.
[16:39] <cjwatson> fbond: oh, ok. just trying to be helpful
[16:39] <fbond> cjwatson: Yeah, thanks.
[16:39] <cjwatson> if it doesn't work I'm not sure, sorry
[16:39] <fbond> cjwatson: #clear works fine as part of a config, so I guess I'll just create a temporary config file and use that with -c.
[16:40] <fbond> cjwatson: Thanks for your help.
[16:40] <cjwatson> fbond: yeah, temporary configuration files work well enough even if they are a hassle
[16:40] <doko> Riddell: universe
[16:40] <jdstrand> jdong: perhaps the best course of action would be to contact upstream with all your concerns, then coordinate on oss-security (http://oss-security.openwall.org/wiki/mailing-lists)
[16:41] <jdstrand> jdong: that way you can get the nifty 'Discovered by' :)
=== jkakar_ is now known as jkakar
[16:43] <ldp> ...
[16:43] <jdong> jdstrand: what is the general procedure for doing this? First contact upstream, correct?
[16:43] <jdstrand> jdong: the is the responsible thing, yes
[16:44] <jdong> jdstrand: ok, will do
[16:44] <jdstrand> jdong: if they are unresponsive, go straight to oss-security
[16:44] <jdstrand> (give 'em a little time though ;)
[16:44] <jdstrand> jdong: cool, thanks!
[16:49] <jdstrand> pitti, tkamppeter: gotta tell you-- over the weekend my wife got an off-the-shelf HP J4580 All-in-One printer from Target. It was *very* impressive to turn on the ptinter and plug it in (usb) to my laptop and have printing just work a few seconds later
[16:49] <pitti> \o/
[16:49] <pitti> jdstrand: file a bug
[16:50] <jdstrand> pitti: a 'pat on the back' bug?
[16:50] <pitti> "current Ubuntu makes support center earn no $$$"
[16:50] <jdstrand> heh
[16:50] <jdstrand> well-- the scanner I had to tinker with, slightly-- but nothing the wiki couldn't solve
[16:51] <jdstrand> ;)
[16:51] <pitti> oh, what, out of interest?
[16:51] <jdstrand> pitti: needed to add hpaio to dll.conf
[16:51] <pitti> jdstrand: that might be worth a bug report then
[16:51] <jdstrand> pitti: that and I didn't have xsane or sane-utils installed
[16:51] <pitti> jdstrand: hm, xsane is in ubuntu-desktop
[16:52] <pitti> actually, sane-utils should be as well now, it's a recommends of libsane
[16:53] <jdstrand> pitti: well, there is slightly more to the story
[16:53] <jdstrand> pitti: my laptop runs intrepid, so perhaps it was just hpaio and sane-utils (would need to check)
[16:53] <jdstrand> pitti: my wife's laptop, which is where I spent most of the time, is hardy
[16:53] <jdong> jdstrand: ugh the rdepends show that gallery/gallery2 and dvd-slideshow both use it :(
[16:53] <jdong> jdstrand: the former two I'm MOST worried about
[16:54] <jdong> jdstrand: those are PHP photo galleries that allow user uploads
[16:54] <pitti> jdong: right, hardy did install xsane, but not sane-utils
[16:54] <jdstrand> pitti: so I just backported hplip to hardy, which is where I remember needing sane-utils and xsane
[16:54] <jdong> pitti: sorry for talking and ruining your jd<tab> workflow :D
[16:54] <pitti> jdong: argh, 'zcuse me, sir
[16:55] <kwwii> ogra: yeah, that is typo :-(
[16:55] <pitti> jdong: yay for history sensitive tab expansion
[16:55] <jdstrand> jdong: nice work-- now it really depends on if gallery[2] and dvd-slideshow give jhead unfiltered input
[16:55] <ogra> kwwii, so cjwatson isnt right ? phew :)
[16:55] <kwwii> lol
[16:56] <jdstrand> pitti: I needed 1.8.7 for the printer (well, at least not 1.8.2)
[16:56] <jdong> jdstrand: well right now I'm reasonably certain that char[500] in editing the description tags means big JPEG metadata does bad stuff too.
[16:57] <jdong> jdstrand: I wouldn't expect these limitations of jhead to be obvious enough for the gallery folks to foresee
[16:57] <jdstrand> jdong: yeah, crafted images
[16:57] <jdstrand> jdong: that's certainly true
[17:00] <pitti> jdstrand: hm, so it wasn't just plug'n'play after all :(
[17:00] <jdstrand> pitti: well, baring hpaio for the scanner bit, on intrepid, it was
[17:01] <jdstrand> the printer was too new for hardy
[17:01] <jdstrand> (but I knew that when buying it)
[17:01] <pitti> jdstrand: that sounds like an easy fix in intrepid, unless it breaks other HP printers
[17:01] <jdstrand> pitti: I found that by using hp-check-- and it recommended it
[17:02] <jdstrand> pitti: I don't know if you do any hp-check foo in your magic configuration...
[17:06] <pitti> tkamppeter: ^
[17:11] <geser> jdong: sounds like you have fun with the jhead :)
[17:13] <jdong> geser: lol. worst part is i used gallery a lot in the past
[17:14] <geser> I hope without jhead installed
[17:21] <kirkland> pitti: thanks for the link ... very informative
[17:23] <pitti> kirkland: so the goal is to stop using groups and controlling privileges through PolicyKit
[17:23] <kirkland> pitti: gotcha, seems noble
[17:23] <pitti> kirkland: sensible "by default just works" settings, and using the PK GUI where neceary
[17:23] <pitti> necessary
[17:24] <pitti> kirkland: primarily because (1) to avoid the overloading of groups with assigning permissions, and (2) to allow programs to allow things to the user which he couldn't have in the default install
[17:24] <pitti> kirkland: e. g. postinsts can't just put existing users into 'kvm' or so
[17:24] <dholbach> jdstrand: unsubscribed ubuntu-universe-sponsors from the jhead bug too
[17:24] <kirkland> pitti: right, that one is a PITA
[17:25] <kirkland> pitti: what would it take to solve the kvm/libvirt group problem in Intrepid?
[17:25] <jdstrand> dholbach: oh! thanks :)
[17:25] <kirkland> pitti: is that doable?
[17:25] <pitti> kirkland: so if we say "a local console user can use kvm" there isn't much to loose in terms of security
[17:25] <kirkland> right
[17:25] <kirkland> pitti: i'm picking up kvm for soren while he's out on paternity leave
[17:26] <pitti> kirkland: e. g. audio, usb, and firewire devices (/dev/bus/usb/..., for example) are accessible as root:plugdev/root:audio, and *additionally* for the current foreground session, via a dynamic ACL
[17:27] <pitti> kirkland: we can say "foreground only", or for kvm "local session" (which would make more sense in this case, IMHO)
[17:27] <jcastro> kirkland: are you watching virt-manager while he's away too?
[17:27] <kirkland> jcastro: yeah, sort-of ;-)
[17:27] <kirkland> jcastro: more focus on kvm, but virt-manager too
[17:27] <pitti> kirkland: so remote users can still be put into kvm (as now), or they get the relevant polkit privilege assigned in the PK GUI
[17:28] <kirkland> pitti: what can be done legally in the postinst?
[17:28] <kirkland> pitti: so that kvm works out of the box?
[17:28] <pitti> kirkland: first, do you think such a semantics would make sense?
[17:29] <kirkland> pitti: i think "local users" does make sense
[17:29] <kirkland> pitti: and i think we can document that remote users would need kvm groupage
[17:29] <kirkland> pitti: we can add that to the Server Guide documentation
[17:29] <jcastro> kirkland: virt-manager currently has 75 open bugs, of which 0 are marked upstreamable, if you've got someone interested in at least determining if they're upstream that would really help.
[17:29] <pitti> kirkland: (or using the PK GUI to assign the privilege)
[17:30] <lucas> is there a server with binary packages from (very) old ubuntu releases?
[17:30] <kirkland> jcastro: i'll go through virt-manager next...  i reduced the kvm queue from 63 to 43 yesterday, marking some duplicates, fixed, wont-fix; and getting a couple of minor patches sponsored
[17:30] <lucas> like edgy?
[17:30] <kirkland> lucas: edgy is going to be tough to find...  it's unsupported
[17:31] <jcastro> lucas: http://old-releases.ubuntu.com/releases/
[17:31] <kirkland> lucas: dapper is still supported (and older than edgy) though
[17:31] <jcastro> oh, you mean packages.
[17:31] <pitti> kirkland: did you ever see a hal fdi?
[17:31] <lucas> jcastro: that's ISO images, but apparently http://o-r.u.c/ubuntu/ has the source packages?
[17:31] <kirkland> pitti: negative
[17:31] <pitti> kirkland: anyway, take a look at /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi
[17:32] <cjwatson> lucas: should have the binaries too
[17:32] <lucas> ah binary too. perfect.
[17:32] <pitti> kirkland: that's an XML file which matches on hal devices and puts access_control.{file,type} attributes to it
[17:32] <lucas> thanks a lot to everybody ;)
[17:32] <kirkland> pitti: interesting
[17:32] <cjwatson> Launchpad used to have some of them but they had to clear up some space on the librarian recently. still has the old sources though
[17:32] <jcastro> kirkland: all that's needed to get started is at least opening an upstream task for it if it's determined to be upstream - even if you don't have a link to the upstream bugzilla bug.
[17:32] <pitti> kirkland: there you see how hal adds e. g. access_control.type.sound to alsa devices
[17:33] <pitti> kirkland: every hal device with the access_control will be considered for dynamic ACL management
[17:33] <kirkland> pitti: where are the possible values of these fields documented?
[17:33] <kirkland> jcastro: cool, i'll see what I can do
[17:34] <kirkland> jcastro: unfortunately, virt-manager kinda sucks, so most of us core kvm users tend to use the kvm command line :-/
[17:34] <kirkland> jcastro: i'll throw some attention at it this week, though
[17:34] <pitti> kirkland: http://people.freedesktop.org/~david/hal-spec/hal-spec.html#spec-device-info describes the structure and syntax
[17:34] <pitti> kirkland: hm, one problem is that current hal doesn't actually know about /dev/kvm, so we need to teach it about it
[17:35] <pitti> kirkland: but that should be simple
[17:35] <jcastro> kirkland: if you can make a determination of what is upstream and what isn't I can find someone who cares about virt-manager enough to make the linkages.
[17:35] <kirkland> pitti: is that done in HAL, or in KVM?
[17:35] <kirkland> jcastro: sounds like a plan
[17:35] <jcastro> kirkland: if in bugs you find someone that cares about virt-manager send them my way and I'll convince them to help. :p
[17:35] <kirkland> pitti: so hal provides /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi ...  is that changed in the source package itself, or generated?
[17:36] <pitti> kirkland: kvm should ship an FDI file which assings access_control.file=/dev/kvm and access_control.type=kvm, and an "access_control" capability
[17:36] <jcastro> right now it sticks out as "we're not even trying" wrt. forwarding bugs upstream.
[17:36] <kirkland> jcastro: well, i have some buddies that care about virt-manager, but they work for Red Hat :-P
[17:36] <pitti> kirkland: hm, maybe .type=virtual_machine, or so (slightly more generic)
[17:36] <pitti> kirkland: there's a second piece of the puzzle
[17:36] <kirkland> pitti: that makes sense
[17:37] <pitti> kirkland: so the fdi says which devices are which type and declares it for ACL management
[17:37] <pitti> kirkland: and /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy assingns those types to a description and default values
[17:37] <cjwatson> kirkland: virt-manager> my sentiments exactly
[17:37] <pitti> kirkland: the existing one for cdrom looks fairly good for this use cases
[17:38]  * kirkland snorts :-)
[17:38] <pitti> kirkland: in principle kvm could ship its own .policy and .fdi, but if you prefer we can also patch hal for that
[17:39] <kirkland> cjwatson: <aside>I did get to play with Ubuntu inside Parallels on a Mac OSX machine...frigging great VM management interface</aside>
[17:39] <kirkland> pitti: i think it would make more sense inside of kvm
[17:39] <kirkland> pitti: or, there's one other option....
[17:39] <kirkland> pitti: we have two meta packages, ubuntu-virt-server, and ubuntu-virt-mgmt
[17:40] <kirkland> pitti: right now, they just depend on a couple of packages necessary to make virtualization 'useful'
[17:40] <kirkland> pitti: we intend on putting some tools there to simplify bridged networking setup, etc.
[17:40] <pitti> kirkland: as for teaching hal about the device, you can call "sudo hal-device --add /some/sensible/UDI" for creating it, and "sudo hal-set-property" to add the access_control capability and access_control.file=/dev/kvm and access_control.type=cdrom
[17:41] <kirkland> pitti: i *think* what you're talking about makes more sense in kvm itself, but i just thought i'd throw that out there
[17:41] <pitti> kirkland: then, after logging out and back in, you should get an ACL on /dev/kvm
[17:41] <pitti> kirkland: yes, it would avoid centralizing knowledge about /dev/kvm in hal, shipping its own snippet is perfectly reasonable
[17:42] <kirkland> pitti: okay, so the hal-device && hal-set-property commands are what would need to be called in kvm's postinst?
[17:42] <pitti> kirkland: and an FDI for /dev/kvm should be in kvm, not in a metapacakge
[17:42] <pitti> kirkland: no, that's just for playing around
[17:42] <kirkland> pitti: understood on the kvm vs. metapackage bit
[17:42] <pitti> kirkland: hal-device --add is not persistent
[17:42] <cjwatson> gar, why does germinate work when run manually on drescher but not when run from cron.germinate?
[17:42] <pitti> kirkland: but you can use it from the shell without recompiling anything
[17:43] <jdstrand> 'virt-manager sucks' is kinda strong-- I use it daily...
[17:43] <pitti> cjwatson: $PATH or so?
[17:43] <kirkland> pitti: okay, so the work item is 1) add .policy and .fdi to kvm
[17:43] <kirkland> pitti: 2) (do something in postinst)
[17:43] <cjwatson> pitti: don't believe so, we consistently just use the germinate from /usr/bin
[17:43] <cjwatson> I don't think there are any other installations kicking around
[17:44] <pitti> kirkland: if you got it working with a manual hal-device add (working fdi/policy), I'll help you with getting the device into hal permanently
[17:44] <cjwatson> pitti: and it's not broken as in "completely fails to work" anyway, it's hitting some kind of infinite recursion in the dependency resolver
[17:44] <kirkland> jdstrand: hold on now...  quote me correctly
[17:44] <kirkland> jdstrand: "virt-manager kinda sucks"
[17:44] <jdstrand> heh, true enough
[17:45] <kirkland> pitti: awesome, sounds like a deal
[17:45] <kirkland> pitti: let me try this out
[17:45] <pitti> kirkland: btw, that's chapter 3 in the link I gave you
[17:45] <pitti> (directly after the fdi spec)
[17:45] <kirkland> pitti: cool, i'll dig there
[17:46] <kirkland> pitti: how much longer are you around today?
[17:48] <pitti> kirkland: probably some 2 hours at least (my wife just left for meeting with a friend, so I'll have some time this evening :) )
[17:49] <pitti> kirkland: i just don't feel very well, so I'll call it a day in 2 hours or so
[17:49] <kirkland> pitti: understood
[17:49] <kirkland> pitti: i'm updating my test hardware right now to latest intrepid
[17:49] <kirkland> pitti: i never do this sort of testing on my primary laptop :-P
[17:50] <pitti> kirkland: hal-device --add is purely temporary, don't worry
[17:50] <pitti> kirkland: oh, hold on, you need --disable-purge-rootfs --really-dont-zap
[17:51] <kirkland> pitti: great options
[17:51] <kirkland> pitti: is there a --please-dont-fry-my-disk option too?
[17:51] <kirkland> :-P
[17:51] <pitti> kirkland: uh, forgot that, sorry
[18:09] <kirkland> pitti: when you say "you should get an ACL on /dev/kvm", do you mean an extended attribute that I can view with getfacl?  or something else?
[18:10] <pitti> kirkland: yes, I mean a file system ACL (getfacl, and little + in ls -l)
[18:10] <kirkland> pitti: thx
[18:13] <zul> slangasek: ping I know you are busy but did you have a chance to look at Christian Perrier's email from pkg-samba ml?
[18:14] <slangasek> zul: about the patch that doesn't apply cleanly to 3.2.4?
[18:14] <slangasek> zul: sure, I've looked at the email ;)
[18:14] <zul> slangasek: yeah is it still necessary?
[18:14] <slangasek> I don't know, I've not looked at samba 3.2.4
[18:14] <zul> slangasek: k
=== andreas__ is now known as ahasenack
[18:27] <ahasenack> pitti: I'm seeing a bunch of tickets opened by apport that report conflicting package names
[18:27] <ahasenack> pitti: https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/273655 for example,
[18:27] <ubottu> Ubuntu bug 273655 in landscape-client "package landscape-common 1.0.21-0ubuntu1 failed to install/upgrade: Versuche, ?/usr/lib/python2.5/site-packages/landscape/patch.py? zu ?berschreiben, welches auch in Paket landscape-client ist" [Undecided,New]
[18:27] <ahasenack> it says the package is landscape-client-1.0.21-0ubuntu1
[18:27] <ahasenack> but the dpkg logs show the failure while installing some 1.0.18 version
[18:31] <kirkland> pitti: should `hal-device --add /org/freedesktop/Hal/devices/kvm` return, or just run in the foreground?
[18:32] <pitti> kirkland: no, it's an one-shoot thing, afterwards you should see it in lshal
[18:32] <kirkland> pitti: I get:
[18:32] <kirkland> root@ubuntu:~#  hal-device --add /org/freedesktop/Hal/devices/kvm
[18:32] <kirkland> tmp udi: /org/freedesktop/Hal/devices/tmp198ee
[18:32] <kirkland> and it just sits there
[18:34] <kirkland> pitti: oh, sorry
[18:37] <kirkland> pitti: kvm installed, module loaded, /dev/kvm exists
[18:42] <tkamppeter> pitti, I do not do any hp-check foo for HPLIP
[18:42] <pitti> kirkland: hm, weird
[18:43] <pitti> kirkland: oh, forgot that bit
[18:43] <kirkland> pitti: is there a "verbose"
[18:43] <pitti>   Reads property list in 'lshal' syntax from stdin.
[18:43] <pitti> ^ from --help
[18:43] <tkamppeter> jdstrand, pitti:
[18:43] <pitti> kirkland: so you can give it some initial properties even
[18:43] <tkamppeter> till@till-laptop:~/ubuntu/pxljr/pxljr-1.1$ dpkg -S /etc/sane.d/dll.d/hplip
[18:43] <tkamppeter> hplip: /etc/sane.d/dll.d/hplip
[18:43] <tkamppeter> till@till-laptop:~/ubuntu/pxljr/pxljr-1.1$
[18:44] <tkamppeter> This file is part of HPLIP and makes our SANE finding hpaio.
[18:44] <tkamppeter> You do not need to edit dll.conf
[18:45] <kirkland> pitti: vvv
[18:45] <kirkland> #  hal-device --add kvm < /dev/null
[18:45] <kirkland> tmp udi: /org/freedesktop/Hal/devices/tmp0a4ae
[18:45] <kirkland> created: /org/freedesktop/Hal/devices/kvm
[18:45] <tkamppeter> But note that it is a conffile, so if you accidentally remove it, an update will not recover the file.
[18:48] <tkamppeter> jdstrand, pitti: HPLIP depends only on libsane, not on any SANE frontends. Should I let it depend on xsane | kooka and/or sane-utils?
[18:50] <jdstrand> tkamppeter: so it sounds like hp-check complaining about hpaio was a false negative
[18:50] <jdstrand> tkamppeter: sounds like it just checks dll.conf and nothing else
[18:51] <jdstrand> tkamppeter: note that I only used hp-check at all because the wiki told me too, and there was no feedback that the (awesome btw) auto0-configuration of the printer also setup the scanner
[18:51] <jdstrand> pitti: ^
[18:54] <kirkland> pitti: # hal-set-property --udi /org/freedesktop/Hal/devices/kvm --key info.capabilities --strlist-post access_control
[18:54] <kirkland> pitti: that look right?
[19:00] <cjwatson> pitti: so, I just worked out why cron.germinate is crashing
[19:01] <sebner> DktrKranz: \o/
[19:02] <kirkland> pitti: # hal-set-property --udi /org/freedesktop/Hal/devices/kvm --key access_control.file --string /dev/kvm
[19:02] <cjwatson> pitti: it's trying to follow the following dependency chain (note that this includes build-dependencies and recommendations):
[19:02] <cjwatson> anna -> libc6-udeb -> autoconf -> perl -> perl-base -> libc6 -> libgcc1 -> gcc-4.3-base -> dpkg-dev -> dpkg -> coreutils -> libacl1 -> libattr1 -> debhelper -> file -> libmagic1 -> zlib1g -> quilt -> patch -> ed -> dpatch -> fakeroot -> libacl1-dev -> libattr1-dev -> libc6-dev -> linux-libc-dev -> module-init-tools -> lsb-base -> sed -> texinfo -> gettext -> gettext-base -> libexpat1-dev -> libexpat1 -> docbook-to-man -> ...
[19:02] <cjwatson> ... sp -> libsp1c2 -> dh-buildinfo -> build-essential -> g++ -> cpp -> cpp-4.3 -> libgmp3c2 -> automake1.9 -> cdbs -> intltool -> libxml-parser-perl -> liburi-perl -> perl-modules -> gcc -> gcc-4.3 -> binutils -> bash -> libncurses5 -> libgpmg1-dev -> libgpm-dev -> libgpm2 -> texlive-base -> texlive-doc-base -> texlive-common -> tex-common -> debconf -> debconf-i18n -> po-debconf -> libmail-box-perl -> netbase -> ifupdown ...
[19:02] <kirkland> pitti: # hal-set-property --udi /org/freedesktop/Hal/devices/kvm --key access_control.type --string cdrom
[19:02] <cjwatson> ... -> nowebm -> noweb -> iconx -> libx11-6 -> libxcb-xlib0 -> libxcb1 -> libxau6 -> pkg-config -> libglib2.0-0 -> libselinux1 -> python-all-dev -> python-all -> python -> python2.5 -> python2.5-minimal -> blt-dev -> blt -> tk8.5 -> libfontconfig1 -> libfreetype6 -> libx11-dev -> libxcb-xlib0-dev -> libxcb1-dev -> xcb-proto -> libxml2-utils -> libreadline5 -> readline-common -> lsb-release -> apt -> ubuntu-keyring -> ...
[19:02] <cjwatson> ... gnupg -> libcurl3-gnutls -> libgnutls13 -> libgcrypt11 -> texlive-latex-base -> texlive-latex-base-doc -> findutils -> dejagnu -> expect -> tk8.4-dev -> tk8.4 -> xterm -> libxft2 -> libfontconfig1-dev -> defoma -> whiptail -> libnewt0.52 -> libslang2 -> libpng12-0 -> libtool -> libltdl7-dev -> libltdl7 -> gfortran -> gfortran-4.3 -> libmpfr1ldbl -> libgmp3-dev -> libstdc++6-4.2-dev -> gcc-4.2-base -> autogen -> ...
[19:02] <cjwatson> ... base-files -> base-passwd -> sgmltools-lite -> docbook-dsssl -> openjade -> libosp5 -> jadetex -> texlive-fonts-recommended -> tipa -> texlive-base-bin -> libkpathsea4 -> libgd2-xpm-dev -> libgd2-xpm -> devscripts -> at -> libpam0g -> libpam-runtime -> libcrack2-dev -> libcrack2 -> cracklib-runtime -> miscfiles -> dictionaries-common -> elinks -> libgnutls26 -> libtasn1-3 -> gtk-doc-tools -> gnome-common -> ...
[19:02] <cjwatson> ... gnome-pkg-tools -> svn-buildpackage -> libsvn-perl -> libapr1 -> libuuid1 -> passwd -> libpam-modules -> libdb4.7 -> default-jdk-builddep -> default-jdk -> default-jre -> default-jre-headless -> openjdk-6-jre-headless -> openjdk-6-jre-lib -> wget -> groff -> groff-base -> gs -> ghostscript -> libgs8 -> libcups2 -> libkrb53 -> libldap2-dev -> libldap-2.4-2 -> libsasl2-2 -> libsasl2-modules -> libpq-dev -> libpq5 -> ...
[19:02] <cjwatson> ... libxml2-dev -> libxml2 -> python-all-dbg -> python-dbg -> debiandoc-sgml -> texlive-latex-extra -> preview-latex-style -> emacs22 -> emacs22-bin-common -> emacs22-common -> libgtk2.0-dev -> libgtk2.0-0 -> libgtk2.0-common -> libpango1.0-dev -> libpango1.0-0 -> libpango1.0-common -> libthai-dev -> libthai0 -> libdatrie0 -> doxygen -> libqt3-mt-dev -> libcupsys2-dev -> libcups2-dev -> libavahi-compat-libdnssd-dev -> ...
[19:02] <cjwatson> ... libavahi-compat-libdnssd1 -> libavahi-client3 -> libavahi-common3 -> libavahi-common-data -> python-dbus -> python-epydoc -> graphviz -> libgraphviz4 -> swig -> gcj -> gij -> libgcj-bc -> libgcj9-0 -> gcj-4.3-base -> libecj-java -> libecj-java-gcj -> ant -> ant-optional -> ant-optional-gcj -> libbsf-java -> jython -> jython-gcj -> java-gcj-compat -> java-gcj-compat-headless -> gjdoc -> antlr -> nant -> mono-runtime -> ...
[19:03] <cjwatson> ... mono-jit -> mono-common -> librsvg2-dev -> librsvg2-2 -> libgsf-1-114 -> libgsf-1-common -> libgnomevfs2-dev -> libgnomevfs2-0 -> gnome-mount -> hal -> udev -> initramfs-tools -> klibc-utils -> libklibc
[19:03] <cjwatson> hmm, oops, I didn't expect it to spill over quite so many lines!
[19:03] <cjwatson> sorry :)
[19:03] <cjwatson> I love the way there are a couple of places where it wanders through a succession of library packages, then through some minimally-related stuff, then through the corresponding development packages; and goes through tex several times
[19:07] <kirkland> pitti: i'm still not seeing the extended ACLs on /dev/kvm... at what point shouldthose take place?
[19:08] <sebner> cjwatson: you paid freenode stuff a beer to avoid the kick? ^ ^
[19:14] <jdong> sebner: I gotta say without the paste the comedic effect would not be the same.
[19:14] <sebner> jdong: hrhr ^^
[19:19] <calc> wow e1000e thing is a mess :\
[19:20] <kirkland> calc: agreed...  the least they could have done was switch on character and make it a palindrome
[19:21]  * sebner is just wondering that the crisis came up *now* with rc6 and not earlier
[19:21] <directhex> pitti, ping
[19:23] <mathiaz> ahasenack: I'm going to look into the landscape-client bugs.
[19:24] <ahasenack> mathiaz: I don't understand those apport reports, it's the third or fourth one which reports one package in the summary but the logs show a different one
[19:24] <mathiaz> ahasenack: radix: did you get a chance to comment on my suggestion to run a daily cron job to update smart package data instead of hourly ?
[19:25] <mathiaz> ahasenack: right - I haven't looked at the log yet - but apport is not an issue here.
[19:25] <radix> mathiaz: I didn't, sorry, I have been off the computer for being sick
[19:25] <ahasenack> I just commented on the cronjob itself
[19:25] <radix> mathiaz: niemeyer probably has a comment about the frequency of the job
[19:26] <mathiaz> ahasenack: right - slangasek suggestion should also be implemented.
[19:26] <ahasenack> mathiaz: having the daemon run smart update?
[19:26] <radix> I'm stepping away again
[19:26] <mathiaz> ahasenack: just checking if landscape-client is running is enough for now
[19:27] <ahasenack> right, so I pasted something for that
[19:27] <mathiaz> ahasenack: great.
[19:27] <mathiaz> ahasenack: I think your suggestion for the cronjob works well.
=== njpatel is now known as njpatel_away
[19:27] <mathiaz> ahasenack: I'd like to have feedback on the frequency of the cron job.
[19:31] <ahasenack> mathiaz: so, I don't know the origin of that frequency or why it's hourly. I guess there is an expectation of things to work "faster" with landscape, since there is someone sitting in front of a web ui
[19:31] <ahasenack> mathiaz: also considering it's a paid service
[19:31] <slangasek> the frequency doesn't seem unusual at all to me
[19:32] <niemeyer> There's also an important distinction between Smart updates and APT updates
[19:32] <slangasek> oh?
[19:32] <niemeyer> When smart update is run, it will download the Release file
[19:32] <niemeyer> If the Release file has the same digest of the one previously downloaded, nothing else is downloaded
[19:32] <slangasek> ah
[19:32] <slangasek> I'm not sure that's actually different than apt?
[19:32] <ahasenack> I thought apt did that too
[19:33] <niemeyer> So the actual operation is quite lightweight when there are no changes
[19:33] <niemeyer> I don't think so
[19:33] <niemeyer> But maybe it changed since I last looked at it
[19:33] <mathiaz> niemeyer: apt and update-notifier are run on a daily basis
[19:33] <slangasek> I'm pretty sure apt is smart enough to not re-download unchanged files
[19:33] <niemeyer> If it does, even better :-)
[19:33] <liw> slangasek, it is
[19:34] <niemeyer> slangasek: I think it does that based on file timing only
[19:34] <niemeyer> Anyway.. I'm sure APT is great. :-)
[19:34] <niemeyer> So..
[19:35] <niemeyer> What's the actual problem we're trying to prevent?
[19:35] <mathiaz> niemeyer: I've asked about that yesterday -> http://paste.ubuntu.com/49783/
[19:35] <mathiaz> niemeyer: the concern is to put too much load on the servers and mirrors
[19:35] <slangasek> mathiaz: I agree that if you're managing a bunch of workstations centrally, you want the average latency to be much lower than 12h
[19:35] <niemeyer> mathiaz: Well, I agree.. it would consume less resources from the server
[19:36] <niemeyer> mathiaz: The question, though, is if it makes an important difference or not
[19:36] <niemeyer> mathiaz: It does make a difference for Landscape usability
[19:37] <mathiaz> niemeyer: the main raise I'm asking is that the default ubuntu install (with apt) doesn't update on a hourly basis.
[19:37] <niemeyer> mathiaz: If you're concerned about it, we can ask elmo about it
[19:37] <niemeyer> mathiaz: It's a slightly different use case I guess
[19:37] <mathiaz> niemeyer: right - if it makes a difference for landscape usability than a hourly cron job is the best option
[19:38] <niemeyer> mathiaz: We can always fire APT/Synaptic/whatever and get the current infomration
[19:38] <niemeyer> mathiaz: For a server-side solution that's not so practical
=== warp10_ is now known as warp10
[19:40] <slangasek> hmm, on-demand triggering of an update check isn't possible?
[19:40] <niemeyer> slangasek: It is definitely possible, but it's a bad UI
[19:41] <slangasek> ok.  I imagine it would be a suboptimal user experience regardless, due to the latency of checking
[19:41] <niemeyer> slangasek: Try to imagine something like "The information you're looking at is 20h old.  If you want to know the current updates, click on Update All Systems and come back in a few minutes."
[19:41] <slangasek> right :)
[19:42] <pitti> re (sorry, got some spontaneous guests)
[19:42] <slangasek> anyway, I'm certainly not arguing against the 1h cronjob
[19:43] <pitti> cjwatson: dep chain> oof! so it's actually just a livelock, not a crash or so?
[19:44] <pitti> kirkland: did you set access_control.type, too? (to 'cdrom' should work)
[19:44] <pitti> directhex: contentless pong
[19:44] <kirkland> pitti: i did
[19:44] <pitti> kirkland: and restarted your session?
[19:44] <kirkland> pitti:
[19:44] <kirkland> # hal-device  | grep kvm0: udi = '/org/freedesktop/Hal/devices/kvm'
[19:44] <kirkland>   info.udi = '/org/freedesktop/Hal/devices/kvm'  (string)
[19:44] <kirkland>   access_control.file = '/dev/kvm'  (string)
[19:45] <mathiaz> ahasenack: it seems that most of the apport bugs are due to the fact they're not using the latest package.
[19:45] <kirkland> pitti: well, i'd expect the extended acl would show up before I restart a session, no?
[19:45] <kirkland> pitti: i'd think that change should be immediate
[19:46] <pitti> kirkland: no, they aren't ATM; the acl helper just reacts to ConsoleKit changes
[19:46] <pitti> kirkland: but you can fake it
[19:46] <pitti> kirkland: run 'ck-launch-session'
[19:46] <ahasenack> mathiaz: you mean latest landscape-c* package or latest apport package?
[19:46] <directhex> pitti, you've sponsored a couple of my mono-related merges in the past, is there any chance you could work your magic on one? it's the last obsolete package in intrepid's core mono stack
[19:47] <mathiaz> ahasenack: oh right - I see what you mean now :D
[19:47] <pitti> kirkland: that creates another COnsoleKit session for you and launches a sub-shell in it
[19:47] <slangasek> mathiaz: I think the only confusion was that apport will list the currently-installed package version in the report, but the log shows the problem for a previous failed upgrade attempt
[19:47] <pitti> directhex: please assign the sponsor bug to me, can do
[19:47] <slangasek> apport's analysis of upgrade failures seems to be a bit suboptimal
[19:47] <ahasenack> slangasek: that's what I thought
[19:47] <pitti> slangasek: yes, it is unfortunately; planned to improve on next UDS
[19:48] <directhex> pitti, fantastic. thanks for your help!
[19:48] <kirkland> pitti: hmm, still no ext'd acl
[19:49] <geser> doko: is it save to disable building libgcj-doc in gcj-4.2? libgcj-doc gets also build from gcj-4.3
=== ivoks_ is now known as ivoks
[19:52] <pitti> directhex: ah, got the bug mail
[19:55] <ahasenack> mathiaz: about other landscape-client bugs, I'm puzzled by #270007. I don't know how or what triggers landscape-client (or any of its components) to be run by non-root
[19:55] <ahasenack> oh, wait, wrong bug number
[19:55] <ahasenack> #268879
[19:56] <ahasenack> mathiaz: some people said they didn't try to run landscape-client as a regular user: the crash was just there
[19:57] <ahasenack> we have 5 duplicates of that one already
[19:57] <kirkland> pitti: dude, i think its working!!!!
[19:57] <pitti> james_w, seb128: so, is there any better rationale than "it's the newest version" for consolekit which I could give in the FF exception request?
[19:57] <pitti> kirkland: yay!
[19:58] <seb128> pitti: being close of upstream makes easier to send them bugs which is nice especially when everybody is busy on the ubuntu side to backport interesting changes
[19:58] <kirkland> pitti: yup, it's working, launched a kvm as "dustin", full acceleration
[19:58] <kirkland> pitti: ext acl's present
[19:58] <kirkland> pitti: now what?  :-)
[19:58] <pitti> kirkland: so, next step is to use a real "type", such as "kvm" or maybe something more generic; maybe "vm_host" or "virtual_machine" or so?
[19:59] <seb128> pitti: and that also reduces upstream rants about ubuntu shipping outdated versions ;-)
[20:00] <kirkland> pitti: okay, what's the advantage of going generic here, with something like "virtual_machine" rather than specific, like "kvm"?
[20:01] <directhex> pitti, sorry to single you out for it, but the thought of intrepid shipping with a doc package documenting something 20,000 revisions older than the actual software fills me with bile and rage. and strangely it seems a mono-related package isn't the top of anyone's sponsorship lists
[20:01] <pitti> kirkland: as for creating the device, there's two options: patch hal to create it, or add the hal-device --add call to the init script (and thus introduce a hal dependency to the init script)
[20:02] <kirkland> pitti: kvm init script sounds most appropriate, no?
[20:02] <kirkland> pitti: or do you prefer them to be concentrated?
[20:04] <kirkland> pitti: uh-oh.... this might be a sticking point
[20:04] <kirkland> pitti: i seem to recall some resistance of hal on the server :-/
[20:04] <pitti> kirkland: and you e. g. couldn't restart hal after kvm is running
[20:05] <pitti> (sorry if that came through twice, my network just had yet another glitch)
[20:05] <mathiaz> kirkland: correct - that's the main reason for the split of landscape-client
[20:06] <mathiaz> kirkland: landscape-common is installed by default on the server, but doesn't pull in hal
[20:06] <mathiaz> kirkland: while landscape-client pulls in hal (and dbus, etc...)
[20:06] <mathiaz> ahasenack: yes - that's because they
[20:06] <mathiaz> ahasenack: yes - that's because they're running intrepid and got upgraded during the dev cycle
[20:06] <pitti> kirkland: there's a third way which is even cleaner IMHO, but slightly more effort
[20:07] <kirkland> mathiaz: i've worked a solution with pitti to handle the requirement we have for group membership in kvm
[20:07] <kirkland> mathiaz: but it depends on hal to handle the perms
[20:07] <mathiaz> ahasenack: they got 18-0ubuntu2 which fails to install
[20:07] <kirkland> pitti: i'm listening......
[20:07] <ahasenack> mathiaz: right, but it's a different bug. See https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/268879
[20:08] <ubottu> Ubuntu bug 268879 in landscape-client "Shouldn't crash when run as user instead of root" [Low,Confirmed]
[20:08] <mathiaz> ahasenack: and then upgraded to 21
[20:08] <ahasenack> mathiaz: that error is about running landscape-c* as non-root
[20:08] <ahasenack> mathiaz: and I have no idea how that could happen other than a user directly invoking the program
[20:08] <geser> I see you are discussing how to add acls on a device for the user. Is there some good guide how to do it? I want finally fix bug 57755 that way but I'm missing some starting point on how to do it.
[20:08] <ubottu> Launchpad bug 57755 in gnupg "Udev Rules for SmartCard Support" [Wishlist,Confirmed] https://launchpad.net/bugs/57755
[20:08] <mathiaz> ahasenack: hm - I'll have a look at it.
[20:08] <mathiaz> kirkland: right - I read the conversation - I think it makes sense for a desktop environment
[20:08] <pitti> kirkland: so, you could write the hal-device --add into a shell script which is installed as a hal addon (/usr/lib/hal/kvm-device or so)
[20:09] <mathiaz> kirkland: however for a server environment it may not work well :/
[20:09] <kirkland> mathiaz: good point
[20:09] <kirkland> pitti: that sounds much better
[20:09] <pitti> kirkland: and in your fdi, add the addon to the computer hal entry
[20:09] <pitti> kirkland: then the addon will be called on hal startup
[20:09] <pitti> kirkland: and you can ship all parts of it in the kvm package, completely independent of hal
[20:10] <pitti> kirkland: and it's just text files
[20:10] <pitti> kirkland: yes, in fact I think that's how it should be done
[20:10] <kirkland> pitti: given what mathiaz has mentioned, we can add a "Suggests hal" to kvm, but we don't want to necessarily bring it in
[20:10] <kirkland> pitti: so i think this enablement should go into hal rather than kvm
[20:10] <pitti> kirkland: right; if you don't have hal installed, you'd use the group method
[20:10] <kirkland> pitti: thus, if a user has "hal", we use this, otherwise, what you just said :-)
[20:10] <liw> mvo, ping?
[20:10] <pitti> kirkland: why? it's just shipping three text files
[20:10] <pitti> kirkland: (fdi, .policy, shell script)
[20:11] <kirkland> pitti: okay, and nothing that actually does anything with them
[20:11] <pitti> they are like 100 bytes each, but they leave the knowledge and policy in the package they belong to
[20:11] <pitti> kirkland: so, if you really don't like them being there, we can add it to our hal package, too
[20:11] <kirkland> pitti: the code that codes them will be in hal
[20:11] <pitti> I'm not too fussed abou tit
[20:11] <pitti> but I think we should maintain policy together with the packages, that seems cleaner to me
[20:12] <kirkland> pitti: i think those 3 files would be fine in kvm, as long as we avoid a dependency on hal
[20:12] <kirkland> pitti: fair enough
[20:12] <pitti> kirkland: yes, if you don't have hal installed, you'd just have an extra 3 text files laying around
[20:12] <kirkland> pitti: okay, can i somehow "export" those files from my working setup?
[20:12] <pitti> no dependency needed (well, a suggests dounds fine)
[20:12] <kirkland> pitti: that sounds perfectly reasonable
[20:12] <kirkland> pitti: agree on the Suggests
[20:13] <pitti> kirkland: copy the hal-device call into a shell script (/usr/lib/hal/debian-setup-keyboard might be a good template)
[20:14] <pitti> kirkland: and once you wrote a .policy and .fdi file that work, just copy them into the package and install them, yes
[20:14] <mvo> liw: pong
[20:14] <pitti> kirkland: for bonus points, create a .policy.in and intltoolize it, for translation love, but don't worry too much about that
[20:14] <liw> mvo, would you be willing to sponsor an upload of system-cleaner tonight or tomorrow?
[20:15] <kirkland> :-)
[20:15] <mvo> liw: sure, is the bzr current, can I upload from it?
[20:15] <pitti> kirkland: use the existing .fdi/.policy files as a template, that should be easy then
[20:15] <pitti> kirkland: hardest part is probably to invent a sensible name for "type" :)
[20:15] <kirkland> :-P
[20:16] <liw> mvo, not yet -- I'm still pondering on how to deal with having a single apt.Cache instance (after being side tracked by my real estate agent showing my apartment to a potential buyer)
[20:16] <kirkland> pitti: i'm inclined to use "kvm" for the same reasons that "cdrom" is "cdrom" and not "optical_drive"
[20:16] <kirkland> pitti: but I really don't care
[20:16] <mvo> liw: sure, no problem
[20:17] <pitti> kirkland: they are sticky in the sense that you could manually assign the privilege to somebody, thus it's hard to change it later
[20:17] <pitti> kirkland: but kvm sounds fine
[20:17] <mvo> liw: just give me a shout when its ready
[20:17] <liw> mvo, I'll do that, thank you
[20:17] <superm1> kirkland, perhaps a dumb question, but why would there be opposition to including hal in server installs in the first place?
[20:17] <kirkland> pitti: i'm trying to think of what kind of virtualization device might pop up in the future, that would work along side kvm?
[20:17] <pitti> kirkland: virtualbox?
[20:17]  * kirkland points superm1 to mathiaz 
[20:18] <kirkland> pitti: does that have a device or something associated with it?
[20:18] <pitti> kirkland: vmware has them as well, but I think it's installed as something insane, like 777 or so
[20:18] <liw> superm1, hal is a moving part, and the more you have, the more likely it is that one of them breaks
[20:18] <kirkland> pitti: okay, that's perfectly reasonable to me
[20:18] <pitti> kirkland: it's been a while, but IIRC yes
[20:18] <kirkland> pitti: it would be advantageous to do this in a way that other virt solutoins can leverage
[20:18] <pitti> anyone using virtualbox here?
[20:18] <pitti> kirkland: they could use the same .policy file, which is beneficial for shaing translations
[20:19] <pitti> kirkland: they'd need a separate fdi, but those are cheap (no user visible strings)
[20:19] <superm1> liw, but what about HAL brings up the potential for breakage is what i'm getting at?
[20:20] <kirkland> pitti: "virt-hw"
[20:20] <kirkland> pitti: "virtualization" or "virtualisation" :-)
[20:20] <liw> superm1, everything -- it's code in the box, and that means there's a risk it will break
[20:20] <kirkland> pitti: "virtual-machine"
[20:20] <liw> superm1, it's not hal in particular
[20:20] <pitti> kirkland: (not that it doesn't need to be overly short; nobody ever types this)
[20:20] <kirkland> grep access_control.type /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi
[20:20] <pitti> kirkland: well, virtual-machine in particular sounds a bit misleading to me
[20:20] <kirkland> pitti: those look like the others in use
[20:21] <kirkland> pitti: sound, cdrom, camera, scanner, pda
[20:21] <siretart> pitti: I used to use virtual box. why do you ask?
[20:21] <pitti> kirkland: vm-host or virtualization WFM
[20:21] <kirkland> pitti: "vm-acceleration"
[20:21] <pitti> siretart: there's something like /dev/virtualbox, right?
[20:22] <pitti> kirkland: well, it's really vm-make-bearable-in-the-first-place :)
[20:22] <kirkland> pitti: ;-)
[20:22] <superm1> pitti, yeah /dev/vboxdrv
[20:22] <pitti> kirkland: (I *told* you it'd be the hardest part!)
[20:22] <siretart> pitti: yes, I think it was called /dev/vboxdrv and /dev/vboxnet or something
[20:22] <pitti> superm1: cheers
[20:22] <kirkland> pitti: no kidding ;-)
[20:22] <superm1> pitti, it used to need permissions management, but no longer does
[20:23] <pitti> superm1: how does it now? ConsoleKit magic or 777?
[20:23] <pitti> superm1: I still remember adding myself to a vbox group, but that might be half a year ago already
[20:23] <superm1> pitti, upstream requires that you use their hardening system on the package and run the VirtualBox binary suid
[20:23] <kirkland> pitti: "virtual-machine-extensions"
[20:23] <superm1> pitti, its as of the last release or two that they added these requirements
[20:24] <pitti> superm1: eww; I thought being able to run a vm as user would be a great thing
[20:25] <superm1> pitti, yeah wishful thinking
[20:27] <pitti> seb128, james_w: sorry, repeated network outage; did I miss a reply from you wrt. ck 0.3 justification?
[20:27] <james_w> <seb128> pitti: being close of upstream makes easier to send them bugs which is nice especially when everybody is busy on the ubuntu side to backport interesting changes
[20:28] <james_w> seb128> pitti: and that also reduces upstream rants about ubuntu shipping outdated versions ;-)
[20:28] <james_w> I don't really have anything to add
[20:28] <pitti> james_w: wel,l the latter doesn't count, that's always the case :)
[20:28] <pitti> james_w: thanks for the quoting
[20:28] <seb128> pitti: I closed IRC since but I said basically that "since nobody is actively working on it in ubuntu and backporting change we would benefit of having the current version to be able to send bugs upstream without getting a "could you try a recent version" reply"
[20:28] <james_w> we have a bunch of crashers that are beyond me, and I would like to ask them, and so having them reproduced on the latest version would help me there
[20:29] <seb128> ditto
[20:29] <seb128> imho consolekit crash too often for something which is a base infrastructure component
[20:29] <seb128> ie when it crashes you can't get credentials since you have no session
[20:30] <seb128> and since we have nobody working actively on it having something we can send upstream would be better
[20:30] <slangasek> cjwatson, pitti, mathiaz: is landscape sorted now to the point where it should be re-added to desktop-common?
[20:31] <kirkland> pitti: do you think i need the /etc/default/kvm conffile?
[20:31] <pitti> slangasek: landscape-common should be fine, except that I seriously question it's Pre-Depends
[20:31] <pitti> mathiaz: ^ any idea why it has those pre-depends? that looks just wrong
[20:32] <pitti> slangasek: s/it's/its/, duh
[20:32] <slangasek> mm, indeed
[20:32] <pitti> same for -client
[20:32] <mvo> oh, is the plan to re-add it to -desktop? then I need to update update-manager, it is removing it on desktop installs (the sub that is)
[20:33] <slangasek> mvo: it was removed from desktop due to a transient installability issue during a key testing window; AFAIK it's supposed to go back in
[20:33] <pitti> slangasek: hm, indeed, I thought we just want to ship it on servers? or has that changed again?
[20:33] <pitti> cjwatson: halp plz
[20:34] <mvo> I read the last mail exchange that way (that its for the servers)
[20:34] <slangasek> pitti: you thought that based on what?  That had never been my understanding, and I thought mdz's last email confirmed that it had always been intended to be included on the desktop
[20:34] <slangasek> it was in the desktop-common seed, after all
[20:34] <pitti> slangasek: based on that phone confcall, but ICBW
[20:35] <slangasek> ah, well, I wasn't on that phone call, so it didn't happen ;)
[20:35] <kirkland> pitti: what about "virt-technology"
[20:35] <kirkland> pitti: which is inline with AMD-V and Intel-VT
[20:35] <pitti> kirkland: well, virt-hw is a bit less marketingish (or what about "awesome-virt")
[20:35] <tkamppeter> jdstrand, pitti, hp-check does not know about the Debianism(?)/Ubuntuism /etc/sane.d/dll.d/. It only knows about /etc/sane.d/dll.conf.
[20:36] <kirkland> pitti: i'm good with "virt-hw" if you ware
[20:36] <slangasek> pitti: who all was on that call, then?
[20:36] <pitti> kirkland: sure; btw, I don't have an /etc/default/kvm
[20:36] <kirkland> pitti: no, it doesn't exist
[20:36] <pitti> slangasek: hm, niemeyer, cjwatson, me, someone else I forgot
[20:36] <kirkland> pitti: http://pastebin.ubuntu.com/49804/
[20:36] <slangasek> frankly, I find it very strange that we would give desktop farms less landscape support out-of-the-box than servers, particularly given the push-back on landscape deps has been from the server team
[20:37] <tkamppeter> If the Ubuntu Wiki tells about hp-check you should modify it telling that hp-check does not know about our SANE changes.
[20:37] <pitti> slangasek: ok, let's add back -common then; that might have been my misunderstanding (-common is at least useful to some degree, while -client doesn't give you anything in the default install)
[20:37] <tkamppeter> HP's MF devices on USB are fulkl Plug'n'Print (and Plug'n'Scan) under Ubuntu.
[20:38] <pitti> kirkland: you need the hal-device --add call; and in that you can feed the properties to stdin
[20:38] <pitti> kirkland: (more efficient than calling hal-set-p three times)
[20:38] <kirkland> pitti: good point, let me rework
[20:38] <pitti> kirkland: feed it "foo.bar = 'baz'" lines
[20:38] <slangasek> pitti: hmm, what's the net size difference if we include -client as well, and are certain that we don't want it included by default?  I didn't think -common gave you anything by default either, unless you were a landscape customer
[20:39] <pitti> slangasek: I was told that "common" has a "sysinfo" component which works everywhere
[20:39] <jdstrand> tkamppeter (and pitti): when I get a chance, I set this up again on my Intrepid laptop, and update the wiki accordingly
[20:39] <slangasek> I would rather put in -client for the moment if there's any question at all, so that we see what the size constraints are
[20:39] <pitti> slangasek: and I'm not certain (that's why I called cjwatson for help)
[20:39] <slangasek> ok :-)
[20:39] <pitti> slangasek: right
[20:40] <slangasek> ok, so until we get a clarification from cjwatson, I'm going to add -client back into the seed so we can see what it does to sizes
[20:40] <pitti> slangasek: well, it pulls in smart and twisted, another 500 KB or so; not too bad, but if we can avoid it, I'd like to do it
[20:40] <slangasek> then if we replace it with -common later, the worst case is that we have free space that we have to fill
[20:40] <mvo> ok, then I remove the update-manager rule on it again
[20:41] <kirkland> pitti: do I need to append to info.capabilities, or is overwrite okay?
[20:41] <pitti> kirkland: overwriting should be ok, it's entirely under your control
[20:41] <kirkland> pitti: http://pastebin.ubuntu.com/49806/
[20:42] <pitti> slangasek: what a luxury problem :)
[20:42] <kirkland> pitti: http://pastebin.ubuntu.com/49808/
[20:42] <pitti> kirkland: (isn't it <<EOF? )
[20:42] <slangasek> pitti: exactly :)
[20:42] <kirkland> pitti: ah yes ;-)
[20:43] <pitti> kirkland: restart hal, and sudo execute it, to test
[20:48] <kirkland> pitti: hmm, no luck yet
[20:49] <pitti> kirkland: property setting doesn't work?
[20:49] <pitti> brb
[20:50] <kirkland> pitti: the script executed correctly
[20:50] <kirkland> pitti: and # hal-device  | grep kvm
[20:50] <kirkland> 0: udi = '/org/freedesktop/Hal/devices/kvm'
[20:50] <kirkland>   info.udi = '/org/freedesktop/Hal/devices/kvm'  (string)
[20:50] <kirkland>   access_control.file = '/dev/kvm'  (string)
[20:50] <kirkland> looks right
[20:50] <kirkland> but I don't have access to the kvm as 'dustin'
[20:50] <kirkland> and i did restart my session
[20:54] <superm1> pitti, will bumping these extra bluez packages that were introduced in intrepid require a MIR?  the same functionality got split out into plugins, so they were split into extra binary packages that ended up in universe
[20:54] <pitti> kirkland: hm, where's the control.type?
[20:54] <superm1> *bumping = moving them into main
[20:54] <pitti> superm1: no, they don't need an MIR, just dependencies to them
[20:55] <pitti> superm1: I already moved them to main
[20:55] <superm1> pitti, ah okay.  well i'm sorting out a different bug on bluez so i'll get the dependencies added for them too at the same time. thanks
[20:55] <pitti> kirkland: and did you set access_control.type to cdrom or virt-whatever? (in the latter case you need a matching FDI and a .policy)
[20:55] <kirkland> pitti: i thought it was "access_control.type"
[20:55] <pitti> kirkland: yes, I'm just lazy
[20:55] <pitti> kirkland: actually...
[20:55] <kirkland> pitti: ah, that's probably it
[20:56] <pitti> kirkland: hang on
[20:56] <pitti> kirkland: if you set the correct properties right away, you don't need a separate .fdi file
[20:56] <kirkland> that sounds like a good plan
[20:56] <pitti> kirkland: i. e. everything that the .fdi file would merge to that devices can be set right at the hal-device --add call
[20:57] <kirkland> pitti: sounds simpler
[20:57] <pitti> kirkland: but you still need to add the "access_control" capability
[20:57] <pitti> kirkland: (the one which the fdi merged)
[20:57] <pitti> kirkland: so it should work with type == cdrom, and adding the capability
[20:57] <pitti> kirkland: if that works, change crdom to virt-awesome and add a corresponding .policy
[20:58] <mathiaz> pitti: slangasek: about the pre-depends in landscape: the reason is outlined in bug 268838
[20:58] <ubottu> Launchpad bug 268838 in landscape-client "registrating clients doesn't work when installing the package" [High,Fix released] https://launchpad.net/bugs/268838
[20:58] <pitti> seb128, james_w: argh, 0.3 seems to break hal (the ACL management)
[20:59] <mathiaz> pitti: slangasek: I should file a bug about using a pre-depends and fix it later once the python-support/python-gobject packages are fixed.
[20:59] <seb128> pitti: I told you about it this afternoon, the patch has been discussed on the upstream mailing list I think?
[20:59] <james_w> pitti, seb128: is it http://lists.freedesktop.org/archives/hal/2008-August/012124.html?
[20:59] <kirkland> pitti: where can i find the policy templates?
[21:00] <seb128> pitti: at least the mandriva packager complain to jon on IRC about sending those patches on the list next time, but I think that has been discussed there too
[21:01] <pitti> james_w: seems to be it, thanks
[21:02] <slangasek> mathiaz: I don't think that explains landscape-client Pre-Depends: debconf
[21:02] <james_w> pitti: a later message refers to a policykit patch as well, we will probably want that
[21:02] <slangasek> mathiaz: likewise the landscape-common pre-dep
[21:02] <pitti> this is not just a simple update any more
[21:02] <pitti> james_w: lots of things are using CK nowadays, not sure what else could break
[21:02] <james_w> pitti: http://cvs.fedoraproject.org/viewvc/rpms/PolicyKit/devel/pk-ck-api-change.patch?view=markup
[21:03] <mathiaz> slangasek: hm - debconf must be added by ${misc:Depends} then
[21:04] <seb128> pitti: there is at least fedora and mandriva using it for a while now
[21:04] <pitti> seb128, james_w: keeping track of it in bug 273711; I didn't subscribe slangasek yet, I want to see this working first
[21:04] <ubottu> Launchpad bug 273711 in policykit "New upstream release 0.3" [Undecided,In progress] https://launchpad.net/bugs/273711
[21:04] <slangasek> mathiaz: um... putting the ${misc:Depends} token in the Pre-Depends: line is... strange?
[21:04] <pitti> but not today any more, need some sleep to cure my fever and cold :(
[21:04] <seb128> pitti: feel free to use a ppa, I'll upgrade and confirm if it works for me or not
[21:04] <james_w> pitti: sure, I'm happy to test tomorrow
[21:05] <seb128> pitti: take care!
[21:05] <pitti> seb128: 0.3 is in my PPA
[21:05] <james_w> pitti: get well soon
[21:05] <seb128> pitti: ok, I'll try and comment then!
[21:05] <kirkland> pitti: okay, this script does work: http://pastebin.ubuntu.com/49822/
[21:05] <pitti> well, at least I uploaded it
[21:05] <mathiaz> slangasek: correct.
[21:05] <pitti> seems it didn' thit yet?
[21:05] <kirkland> pitti: i think the problem is in info.capabilities = 'access_control'
[21:05] <kirkland> pitti: that needs to be an "append", rather than an "overwrite" as I mentioned before
[21:06] <kirkland> pitti: is there a += ?
[21:06] <pitti> kirkland: well, it needs to be an array, not a string
[21:06] <kirkland> pitti: how does that look in the heredoc ?
[21:06] <pitti> kirkland: I don't know; hal-device claims it's using lshal syntax, so maybe "info.capabilities = {'access_control'}" works?
[21:07] <pitti> kirkland: if not, just use hal-set-property, it's not a problem
[21:10] <pitti> seb128: argh, got rejected; "Could not find person '<your-launchpad-id>'" WTH?
[21:10] <pitti> ah, -ENODPUTRC, sorry
[21:10] <seb128> ah ;-)
[21:11] <kirkland> pitti: bingo!
[21:11] <kirkland> pitti: success with: http://pastebin.ubuntu.com/49825/
[21:11] <pitti> kirkland: rocking
[21:12] <jdstrand> slangasek: so your sentinels are what you match on in create_from_template (in pam-auth-update)
[21:12] <jdstrand> ?
[21:12] <slangasek> jdstrand: yes
[21:12] <kirkland> pitti: okay, so i put that in the kvm package as debian/setup-kvm-hal ?
[21:13] <jdstrand> slangasek: I see 4 of them-- if I comment those out via a-c-c, it should all work again-- correct?
[21:13] <pitti> kirkland: yep, install it to /usr/lib/hal/, and have a .fdi file to add that addon to startup (like in /usr/share/hal/fdi/policy/10osvendor/10-cpufreq.fdi)
[21:14] <pitti> kirkland: but remember to change s/cdrom/virt-awesome/ and provide a .policy file
[21:14] <slangasek> jdstrand: correct
[21:14] <kirkland> pitti: sample policy file?
[21:15] <slangasek> jdstrand: if they're commented out, pam-auth-update will know this is an externally-modified config, and will prompt before overwriting
[21:15] <kirkland> pitti: /usr/lib/hal/hal-system-kvm ?
[21:15] <pitti> kirkland: /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy
[21:15] <pitti> kirkland: sounds good
[21:15] <pitti> sorry, really need to crash now, I feel terrible, and it's late
[21:15] <kirkland> pitti: cool
[21:15] <pitti> kirkland: feel free to mail/leave backscroll; good luck!
[21:15] <kirkland> pitti: i'll drop you some patches
[21:15] <kirkland> pitti: thanks soooooooooooooo much
[21:16] <pitti> kirkland: you're welcome! glad to get rid of another system group (for desktops, anyway)
[21:16] <kirkland> ;-)
[21:16] <pitti> of course we still need the group, but not the hassle to add people to it normally
[21:16]  * kirkland wonders if superm1 might kill off the mythtv group next :-P
[21:17] <superm1> haha kirkland
[21:18] <kirkland> heh
[21:18] <geser> kirkland: as you know now how to do it, can I bug you to teach me how to do it for usb smart card readers (used e.g. by gnupg)?
[21:18] <kirkland> geser: :-)  let me prove i know how to do it by finishing off kvm, and then, sure!
[21:19] <Keybuk> siretart: after some thought, I've reverted your udev change
[21:20] <Keybuk> (for the reasons we discussed - I just don't like ignoring genuine errors to work around vserver's brokenness)
[21:26] <norsetto> siretart: its bug 237830 (was in my email)
[21:26] <ubottu> Launchpad bug 237830 in extremetuxracer "package planetpenguin-racer-gimp-dev None [modified: /var/lib/dpkg/info/planetpenguin-racer-gimp-dev.list] failed to install/upgrade: trying to overwrite `/usr/share/gimp/2.0/palettes/PPRacer---Default.gpl', which is also in package extremetuxracer-gimp-dev" [High,Fix released] https://launchpad.net/bugs/237830
[21:27] <sebner> aloha norsetto btw ;)
[21:27] <sebner> tseliot: alberto \o/
[21:27] <norsetto> aloha aloha sebner
[21:28] <tseliot> sebner: hi
[21:29] <sebner> tseliot: you broke again my 3D (nvidia) xD
[21:29] <tseliot> sebner: can you file a bugreport? I'll have a look at it tomorrow
[21:30] <sebner> tseliot: sure. just wanted to blame you ^^ (don't take it seriously) ;)
[21:33] <tseliot> sebner: ;)
[21:33] <siretart> Keybuk: I disagree that vserver is being broken in this regard. the vserver instances don't have the mknod capability on purpose and udev's postinst is the only package in the archive insisting to have that capability
[21:33] <Keybuk> that's fair enough
[21:33] <Keybuk> in which case your patch should have either
[21:33] <norsetto> doko: when you have time, could you look at bug 273677? I'm not 100% sure that that fix would be correct
[21:33] <ubottu> Launchpad bug 273677 in wxwidgets2.6 "bitpim closeing unexpectedly" [Undecided,Confirmed] https://launchpad.net/bugs/273677
[21:33] <Keybuk> 1) skipped device creation on vserver
[21:33] <Keybuk> or even better
[21:33] <seb128> hey norsetto
[21:34] <Keybuk> 2) attempted it, and ignored *only* EPERM *if* on vserver
[21:34] <norsetto> seb128: hi seb, any task for me ;-)?
[21:34] <seb128> norsetto: thanks for your work on the desktop team organisation, I've been really busy on the GNOME 2.24 updates but I'll reply on the list tomorrow
[21:34] <Keybuk> instead your patch ignores utterly genuine failures
[21:34] <seb128> norsetto: how do you get the list of packages and versions now? I think we should have a collection of watch files in bzr
[21:34] <norsetto> seb128: well, there is still a lot to be done on the wiki pages I'm afraid
[21:35] <siretart> Keybuk: can udev.postinst safely assume that /proc is being mounted?
[21:35] <seb128> norsetto: this way we could easily update packages list and the series numbers
[21:35] <norsetto> seb128: for most packages I just use ftp.gnome.org, for the depends I have some sort of "watch" files
[21:35] <Keybuk> siretart: I suspect many packages already assume that, yes ;)
[21:35] <Keybuk> it seems like a valid assumption to me
[21:36] <seb128> norsetto: we need to figure a way to claim updates though, we want something which allow to list packages which have usual updaters and those which can be claimed by the first to start working on the update
[21:38] <norsetto> seb128: I can look at adding a tick box to say "this update is being worked on, but then I would have to save the results locally since the page is regenerated daily
[21:39] <norsetto> seb128: dunno if I can do that with just javascript, have to check it out
[21:40] <siretart> Keybuk: okay, in that case I'd like to add a check to grep for ^VxId in /proc/self/status and skip the device creation if found. is that acceptable to you?
[21:40] <Keybuk> siretart: yup, entirely
[21:40] <siretart> Keybuk: VxId contains the "Context Id" of vservers
[21:40] <seb128> norsetto: let me think about that and comment the list tomorrow, what do you think about using a directory of watch files to describe the packages and versions to list?
[21:41] <norsetto> seb128: if we have a list of usual updaters I can add those very easily to the page
[21:41] <siretart> Keybuk: okay, I'll implement then that change
[21:42] <seb128> norsetto: can easily do, we just need to figure where to store it, probably bzr, not sure if we should use the ubuntu-desktop or the desktop-bugs team though
[21:42] <norsetto> seb128: it won't hurt, mind you that not all have a watch file right now
[21:42] <norsetto> seb128: ubuntu-desktop looks reasonable to me
[21:42] <seb128> right, but having the watch in the sources is annoying
[21:43] <seb128> it requires changing the source, which doesn't work when we sync on debian which tracks only stable version
[21:43] <seb128> and also require uploads to do changes
[21:43] <seb128> it would be easier to have the watch in bzr somewhere, we could do changes easily there
[21:43] <seb128> ubuntu-desktop has limited commit access where desktop-bugs is rather open to contributors
[21:44] <seb128> so it depends if we want some moderation or let contributors do changes
[21:44] <norsetto> seb128: for watch files there is not much they can screw up I guess
[21:44] <Keybuk> siretart: of course, I'm not even sure how you expect a vserver to boot with that change <g>
[21:45] <Keybuk> since it won't have /lib/udev/devices/null
[21:45] <seb128> norsetto: right, but on another side there is no so many changes and it's not really up to contributors to decide what packages the team is working on or the series to use
[21:45] <siretart> Keybuk: vservers have a rather special boot procedure. they don't use sysvinit nor upstart, but a custom "fakeinit" process.
[21:46] <Keybuk> but they use udev?
[21:46] <siretart> no. why should they?
[21:46] <Keybuk> err, if they're not using udev
[21:46] <Keybuk> why is a failure to install udev a problem? :p
[21:46] <siretart> think of vservers like 'chroot on steriods'
[21:47] <slangasek> pitti: well, looks like the latest GNOME drop already ate up any space we would use for landscape-client on the liveCD, hmm
[21:47] <norsetto> seb128: hmmm, having warnings in the wiki (and other appropriate places) and reminding at desktop meeting won't be enough you mean?
[21:47] <siretart> udev is installed by debootstrap, no? and has a rather large amount of reverse dependencies. (*sigh*)
[21:47] <Keybuk> siretart: well, yes, it's a required part of our system ;)
[21:48] <Keybuk> sounds like vservers aren't even Ubuntu
[21:48] <siretart> chicken&egg problem, eh?
[21:48] <Keybuk> "DSA keys not accepted anymore" oh, fd.o
[21:48] <siretart> I maintain a (small) vserver farm running hardy here just fine, btw.
[21:49] <siretart> since warty!
[21:49] <seb128> norsetto: no, I mean the watch updates are not often and it's probably better to have some moderation than let any bug triager to be able to do changes
[21:49] <Keybuk> but it can't be Ubuntu if it doesn't use things like sysvinit/upstart and udev <g>
[21:49] <siretart> it can be
[21:49] <norsetto> seb128: ah yes, if its bug triager please, don't :-)
[21:50] <seb128> desktop-bugs is the team for triagers
[21:50] <seb128> rather ubuntu-desktop then ;-)
[21:50] <norsetto> seb128: agreed!
[21:50] <Nafallo> siretart: they've been running hardy since warty? :-P
[21:51] <slangasek> Nafallo: f33r the power of vservers
[21:51] <Nafallo> servers from the future! :-P
[21:51] <Nafallo> see.. there are reasons I like bare-metal the best ;-)
[21:51] <norsetto> seb128: I was thinking maybe about another possibility, I could scan the TODO list and if we agree that all updates have to be loggen there, I can use that info when making the packages page
[21:51] <Keybuk> bare metal makes the best restraints
[21:56] <siretart> Keybuk: just to make sure we don't play ping pong here longer, I'm going to upload this: http://paste.ubuntu.com/49839/ (unless you object now, that is)
[21:57] <siretart> I expect this to be fairly safe, and even create the devices if /proc is not mounted
[22:00] <Hydrant> how do I regenerate ld.so.conf after putting an entry into ld.so.conf.d ?
[22:02] <mathiaz> ahasenack: is there a reason why in the cronjob you 2> /dev/null ?
[22:02] <mathiaz> ahasenack: I refer the landscape-client cronjob
[22:02] <ahasenack> mathiaz: well
[22:03] <ahasenack> mathiaz: not really now that I think of it
[22:03] <ahasenack> mathiaz: fear probably
[22:03] <mathiaz> ahasenack: if there is an error I'd rather have it printed
[22:03] <ahasenack> emailed, in this case
[22:03] <mathiaz> ahasenack: right
[22:06] <ahasenack> mathiaz: the worst case would be a bug or some other condition which would happen every time. In this case, this would mean an email every hour
[22:07] <niemeyer> mathiaz,andreas: I think there was some kind of issue that actually lead us to do it
[22:07] <siretart> how are (former) e1000e users supposed to get their nic working if e1000 doesn't work for them? is there a (non-obvious) workaround somehow?
[22:07] <niemeyer> About buffer size, IIRC
[22:08] <niemeyer> mathiaz: If possible, I recommend not changing this script too much at this point
[22:09] <niemeyer> mathiaz: We can perhaps review this for the next release, if you'd like to, but we won't have time to figure out issues at this point
[22:09] <slangasek> siretart: downgrade the kernel
[22:09] <mathiaz> niemeyer: hm. It's just a cron job.
[22:10] <mathiaz> niemeyer: right - I get what you mean.
[22:10] <niemeyer> mathiaz: Yes, it is, and I do remember that the 2>/dev/null was added to prevent the process from locking up.
[22:10] <mathiaz> niemeyer: ok
[22:11] <niemeyer> mathiaz: We can look for the bug and try to recall what was the problem, and fix it in a different way if you'd like to
[22:11] <mathiaz> niemeyer: well - it's a bug in smart
[22:11] <niemeyer> mathiaz: But we've been changing landscape-client in a different way every day in the last several weeks, so I'd like to try to walk towards stabilization as much as possible
[22:12] <niemeyer> mathiaz: It may be, and it may not be
[22:12] <niemeyer> mathiaz: It may also be about the way in which stderr and stdout are read by the parent process
[22:12] <mathiaz> niemeyer: right - in that case it's a bug in crond.
[22:13] <mathiaz> niemeyer: I don't see how this is related to landscape-client though.
[22:14] <niemeyer> mathiaz: All I want is to keep the cronjob working.  If you promise it will work, you can do anything you want with it.  If we get locked up processes that'll be *really* *really* bad.
[22:14] <siretart> slangasek: to 2.6.24?
[22:14] <mathiaz> niemeyer: right.
[22:14] <ogra> dont forget that we dont have any mailserver on desktop ... in case landscape-client is installed there ,,,
[22:20] <kirkland> any other hal experts here, in pitti's absence?
[22:21] <norsetto> does anyone know where pycentral installs pth files!?
[22:23] <superm1> kirkland, maybe post your question to pitti and if someone else knows the answer before pitti gets back they'll speak up?
[22:23] <kirkland> superm1: ;-)
[22:23] <kirkland> superm1: i'm trying to figure out what runs the stuff in /usr/lib/hal/*
[22:25] <superm1> kirkland, as in what executes it directly, or as in how to get hal to execute it?
[22:26] <kirkland> superm1: if i run my script in there by hand, i get exactly what i want
[22:26] <kirkland> superm1: now, i'm trying to figure out how to make that happen automagically on boot
[22:26] <superm1> okay so more so the latter then
[22:26] <kirkland> superm1: perhaps it just goes in the kvm init script?
[22:26] <superm1> kirkland, you'll need to set an info.addons key i believe
[22:26] <superm1> kirkland, and for the udi
[22:27] <kirkland> superm1: oh, maybe that's it
[22:27] <kirkland> i had info.callouts.add
[22:27] <superm1> if I look at lshal output for say my lcd_panel, i get a key that looks like this http://paste.ubuntu.com/49845/
[22:27] <superm1> where the addon in /usr/lib/hal is hald-addon-dell-backlight
[22:27] <kirkland> k, let me try that
[22:36] <kirkland> superm1: that's not quite it...  http://paste.ubuntu.com/49847/
[22:37] <superm1> kirkland, well is there actually a device that is showing up to identify that you are running kvm though?
[22:37] <kirkland> superm1: do you mean, does /dev/kvm exist?  it does.
=== beuno_ is now known as beuno
[22:38] <kirkland> superm1: but `hal-device | grep kvm` doesn't show any matches
[22:38] <kirkland> superm1: it's still not running /usr/lib/hal/hal-system-kvm
[22:38] <kirkland> superm1: on boot
[22:39] <superm1> kirkland, okay so you are missing something that spawns the udi then i believe
[22:40] <superm1> kirkland, by matching another hal key when booted from KVM.  are there any other things identifiable in lshal that can indicate that you are booted into kvm?
[22:40] <kirkland> superm1: http://paste.ubuntu.com/49848/
[22:41] <superm1> kirkland, oh is this for within the VM or outside the VM then?
[22:41] <kirkland> superm1: i'm running this on real hardware, not in a kvm
[22:41] <superm1> it looks like for outside the VM, i see...
[22:41] <kirkland> superm1: right
[22:41] <kirkland> superm1: generally, you have to be in the kvm group to actually use /dev/kvm
[22:41] <kirkland> superm1: i'm trying to solve that ;-)
[22:43] <kirkland> superm1: maybe this bit is wrong?  +    <match key="info.udi" string="/org/freedesktop/Hal/devices/kvm">
[22:43] <kirkland> superm1: i'm not entirely sure what belongs in the fdi
[22:44] <superm1> kirkland, well so if this fdi is only shipped w/ the kvm package, I believe that what you want to do is unconditionally spawn the new hal udi, and then have that match go into it
[22:44] <superm1> kirkland, grep through /usr/share/hal for some examples about how udi's are spawned
[22:45] <superm1> information/10freedesktop/10-dell-rfkill-switch-wlan.fdi is an example i'm looking at
[22:45] <kirkland> superm1: that's what I do in /usr/lib/hal/hal-system-kvm
[22:45] <superm1> kirkland, so what i'm thinking is that you wouldn't have any of those match keys in the first section, but ou would have the spawn udi key in the first device section
[22:45] <superm1> and the second one you would do the matching that adds in your hal-system-kvm
[22:46] <superm1> and I want to say it should spawn the binary all on its own after that
[22:46] <kirkland> superm1: where is information/10freedesktop/10-dell-rfkill-switch-wlan.fdi ?
[22:46] <superm1> /usr/share/hal
[22:47] <superm1> I still might be a little off on this solution though
[22:47] <cjwatson> pitti: not a livelock - python has a recursion limit, and because germinate 1.9 added an extra level of function calls for each package in the recursive dependency resolver, we ended up overflowing it and python raised an exception
[22:47] <superm1> at that point you wouldn't necessarily even need that info.addons i suppose, but instead you would just put in your two keys that were added in that binary
[22:48] <cjwatson> pitti: I was out, but retroactively, slangasek's plan for landscape-client is reasonable
[22:49] <cjwatson> Keybuk: of course, not accepting DSA keys makes them non-spec-compliant ;-)
[22:49] <kirkland> superm1: i'm thorough confused...  if i did that, what would actually call my binary?
[22:50] <superm1> kirkland, nothing would, i'm not sure the binary would even be needed
[22:50] <superm1> kirkland, because all the binary is doing is registering keys in the UDI right?
[22:50] <kirkland> superm1: right
[22:50] <superm1> kirkland, so you can just explicitly define those keys directly in the FDI
[22:50] <superm1> and you should have the same result
[22:50] <Keybuk> cjwatson: would that be the "oops, where did that go?" plan :)
[22:51] <nxvl> Keybuk: that plan always work :P
[22:52] <Keybuk> cjwatson: we clearly can't add any more packages to the CD!
[22:52] <Keybuk> We've exceeded germinate's limits! :p
[22:52] <cjwatson> not any more ;-)
[22:53] <kirkland> superm1: http://paste.ubuntu.com/49851/ ?
[22:53] <cjwatson> though I did notice several transitional packages in that dep chain that clearly shouldn't be there :)
[22:53] <kirkland> superm1: actually, i dropped the addons
[22:53] <kirkland> http://paste.ubuntu.com/49852/
[22:53] <superm1> kirkland, yeah that's the sort of thing I had in mind
[22:54] <kirkland> superm1: lemme build that
[22:58] <kirkland> superm1: that might have worked ;-)
[22:58] <kirkland> superm1: i'm rebooting to make sure
[23:04] <mathiaz> niemeyer: http://paste.ubuntu.com/49853/ <- this is the hourly cronjob I'm about to upload
[23:15] <kirkland> superm1: success!!!
[23:15] <superm1> kirkland, awesome :)
[23:16] <superm1> kirkland, you'll have to make sure that's within policy to do that in the FDI file like  that, but I think since it's opt-in only when you install the KVM package, I dont see why it wouldn't be
[23:16] <kirkland> superm1: sure, i'm going to leave a debdiff in pitti's inbox
[23:16] <kirkland> superm1: if it's okay, he can sponsor it
[23:16] <kirkland> superm1: if not, he can modify it appropriately, or punt it back to me
[23:17] <superm1> kirkland, right
[23:17] <superm1> kirkland, i'm curious on the second half of that I didn't see, what controls someone's rights exactly?
[23:18] <superm1> is there a GUI tool to figure this kind of stuff?
[23:18] <kirkland> superm1: huh?
[23:18] <kirkland> superm1: no idea
[23:18] <nxvl> superm1: someone's rights as in permissions?
[23:19] <superm1> nxvl, yeah in this particular case where you aren't actually settings permissions on the device file
[23:19] <kirkland> superm1: i think that's the "policy" file
[23:19] <superm1> does hal end up owning the device file and then handling permissions itself then?
[23:19] <kirkland> superm1: not, it's still owned root:kvm
[23:19] <kirkland> superm1: but there's an extended attribute on it
[23:20] <kirkland> superm1: http://pastebin.ubuntu.com/49860/
=== cr3_ is now known as cr3
[23:21] <superm1> kirkland, ah interesting
[23:22] <superm1> kirkland, well that's pretty neat
[23:23] <cjwatson> doesn't that rely on extended attributes being enabled in the filesystem?
[23:23] <kirkland> cjwatson: on /dev ?
[23:23] <cjwatson> oh, it's a tmpfs I suppose
[23:23] <superm1>  /dev should be tmpfs, I had assumed tmpfs had them enabled
[23:23] <kirkland> i assumed it was given
[23:25] <superm1> kirkland, so when you run kvm, does some sort of PolicyKit type of thing go off to ack you into the policy?
[23:25] <superm1> or is that a separate piece that will still need to be developed?
[23:25] <kirkland> superm1: i think that's still tbd
[23:30] <cjwatson> right, sorry, I was thinking of / where I don't think xattrs are reliably available
=== fta_ is now known as fta
[23:31] <slangasek> siretart: 2.6.24> if that's what you have available, yeah
[23:32] <kirkland> superm1: in case you're interested ... https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/273764
[23:32] <slangasek> cjwatson: s/reasonable/desired/? :)
[23:32] <ubottu> Ubuntu bug 273764 in kvm "add hal/PolicyKit support to kvm" [Wishlist,In progress]
[23:32] <kirkland> superm1: that has the debdiff that's working for me for kvm
[23:32] <cjwatson> slangasek: I was carefully not specifying :)
[23:32] <kirkland> geser: you asked as well, see the debdiff for https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/273764
[23:32] <kirkland> geser: that's "working" for me for kvm
[23:32] <cjwatson> slangasek: I think probably desired, though
[23:32] <kirkland> geser: but I'm awaiting pitti's review and blessing there of
[23:32] <calc> hmm my power company claims they completely fixed power for my zipcode but my neighbor tells me the power is still out just as badly as before
[23:34]  * calc considers making the 1.5hr drive to see how what is up
=== superm1 is now known as superm1|away
=== cr3__ is now known as cr3