[00:08] <slangasek> pitti: hmm, sqlite is still in main for intrepid; I think that was only needed for transitioning, and needs to be dropped now
[00:08] <slangasek> pitti: (throwing this at you on IRC because I'm in the middle of three other things, feel free to bounce it back at me later ;)
[00:36] <User546> anyone know anything about checksums?
[00:36] <slangasek> ... yes?
[00:56] <wgrant> Hmm. It is not encouraging to see somebody like that coming from a US tertiary institution.
[01:18] <LaserJock> wgrant: how so?
[01:21] <slangasek> eew, intrepid is creating /initrd.img and /vmlinuz symlinks in my root
[01:33] <wgrant> LaserJock: I would have thought that university students should be smart enough to ask smart questions and not leave after 31 seconds.
[01:33] <LaserJock> uhhh
[01:34] <LaserJock> sorry, I just got done teaching 20 freshmen how to use Excel, I better keep my mouth shut
[01:34] <wgrant> Hah.
[01:34] <nixternal> gahahahha
[01:34] <nixternal> and they taught LaserJock why he loves windows so much!
[01:34] <bryce> ScottK-laptop: xorg uploaded; displayconfig-gtk is a thing of the past.
[01:36] <LaserJock> what was most disturbing is that they were having a hard time figuring out Office 2003 as they were only used to Office 2007
[01:36] <wgrant> LaserJock: Wow.
[01:37] <wgrant> That's interesting.
[01:37] <wgrant> I didn't realise that we already had people who have only used Office 2007...
[01:37] <LaserJock> apparently
[01:39] <LaserJock> and I haven't even used Office 2003 so I'm not much help
[01:39] <LaserJock> next week though I'm hoping we have our Xubuntu lab finished
[02:19] <f4hy> Hi all, What is the correct course of action to request for a newer version of a package for ibex, or better yet how would I package it myself and get it included?
[02:21] <slangasek> f4hy: we're in FeatureFreeze for intrepid, so all new packages need to go through https://wiki.ubuntu.com/FreezeExceptionProcess
[02:22] <f4hy> slangasek, hmm, well thats too bad. BOINC is at an unstable pre-release version in 8.10, was hoping to fix that
[02:23] <slangasek> uhm, why doesn't the version number look like an unstable pre-release?
[02:23] <slangasek> 6.2.12-1
[02:24] <f4hy> slangasek,  would have to talk to the boinc guys about that, because 6.2.12 is not a full release for it.
[02:24] <f4hy> slangasek, even when your run it, under "about" for the manager it says everywhere "pre-release"
[02:25] <f4hy> also, messages get sent from the server asking to upgrade from the unstable version
[02:25] <f4hy> "This is a development version of BOINC and may not function properly" is displayed under messages when first run.
[02:26] <f4hy> So, to me that sounds like a bad thing, and do you think it would be reason enough for a freeze exception on it? or is the freeze a pretty hard limit
[02:27] <slangasek> the guidelines for freeze exceptions are explained on the wiki page; the final decision on the risk/reward of any particular freeze exception here would be made by the motu-release team
[02:27] <f4hy> 6.2.15 is the next stable release, and i think 6.3.0 is out. But i think it should at least get to the next stable
[02:28] <f4hy> slangasek, alright thanks. I guess I will look into it. I think 6.2.15 is upstream in the debian repos so hopfully that will help
[02:29] <slangasek> actually, Debian has 6.2.14 in unstable and 6.2.18 in experimental
[02:29] <slangasek> I wouldn't dare to guess which of those are unstable pre-releases or not
[02:30] <f4hy> slangasek, *sigh* that is unfortunate.
[04:56] <calc> hi
[05:01] <TheMuso> calc: Hi/ Are you safe?
[05:01] <TheMuso> calc: As in, has your home been spared?
[05:02] <superm1> well it's not hitting until tomorrow/saturday i thought?
[05:02] <superm1> at least that's when we're getting all the rain resulting from it.....
[05:16] <calc> TheMuso: yea, for now the hurricane will start to hit around 6pm tomorrow it looks like
[05:16] <calc> TheMuso: but it looks like it is going east of us which is good if it does
[05:16] <TheMuso> calc: GOod to hear.
[05:17] <calc> i went back to my place for now, if it looks bad tomorrow around noon i'll head back out
[05:17] <calc> fortunately the evacuation routes were much better this time, last time it took upwards of 20hrs to get to shelter for some people
[05:17] <calc> i think they didn't really have a plan before, heh
[05:18]  * calc headed to bed, bbl
[05:18] <calc> i evacuated earlier than need be due to the bad experience before and the fact i have 1yr old son this time
[05:18] <calc> it would have been bad to have him on the road that long
[05:18]  * calc really gone to bed now :)
[05:45] <dholbach> good morning
[06:04] <doko> cjwatson: yes, waiting on 255275 (pitti needs to handle this, won't approve myself)
[06:13] <ScottK-laptop> pitti: I've left you Bug 269272 as a present for your archive day.  Enjoy.
[06:13] <ScottK-laptop> bryce: ^^^
[06:14]  * ScottK-laptop no goes to sleep and dreams of it going away while he is sleeping.
[06:14] <ScottK-laptop> no/now
[06:25] <wgrant> It had a short life.
[07:15] <TheMuso> 5~/c
[08:11] <persia> doko: The python-2.5 and openjdk-6-jre packages include some .desktop files to launch the interpreters.  These are not shown by default.  Is there a reason we want to ship the files?
[08:12] <doko> persia: why do you care if these are not shown by default?
[08:13] <doko> hmm, I would be surprised by a .desktop file for a java interpreter
[08:14] <StevenK> mobile-basic-flash shows them
[08:15] <persia> doko: I care only because we're using a different menu system :)  I was surprised by both interpreter entries.  I see the point to openjdk-6-policytool.desktop, but not to python-2.5.desktop, openjdk-6-java.desktop or openjdk-6-javaws.desktop
[08:16] <doko> well, it's policytool, not the interpreter
[08:17] <persia> -policytool is, but openjdk-6-java.desktop execs /usr/lib/jvm/java-6-openjdk/bin/java -jar
[08:17] <persia> Perhaps that's only supposed to be a MimeType registration entry?
[08:18] <persia> similarly, python-2.5.desktop execs /usr/bin/python2.5 in a terminal, which seems a little odd.
[08:35] <wgrant> So we have no significant theme changes for Intrepid, again?
[08:35] <ion_> That’s awesome, considering the theme that was the default in intrepid for a while. :-)
[08:36] <wgrant> Not a fan of NewHuman?
[08:37] <ion_> I could live with it if everything else didn’t have an eye-hurting contrast against it, most of the websites i frequent for instance. :-)
[08:37] <wgrant> Right.
[08:40] <pitti> Good morning
[08:40] <ion_> ing
[08:40] <wgrant> Evening pitti.
[08:41] <StevenK> Morning pitti
[08:45] <pitti> slangasek: hm, but it still has 4 reverse dependencies
[08:45] <pitti> slangasek: one of which is bacula, which we promoted fairly recently; sorry, didn't catch that in the MIR
[08:47] <pitti> ScottK-laptop: yay! I'll hand this to StevenK who is craving for killing something :-P
[08:47]  * Hobbsee looks up
[08:47] <Hobbsee> did someone mention killing?
[08:50]  * NCommande wakes up
[08:50] <NCommande> Killing?
[08:50] <NCommande> Can we use a chainsaw ;_0
[08:50] <NCommande> morning ScottK
[09:34] <sleepster> how does one help the ubuntu dev?
[09:36] <dholbach> sleepster: check out https://wiki.ubuntu.com/MOTU/GettingStarted - it links to a lot of important information
[09:39] <sleepster> thanks
[09:47] <atari2600a> hey
[09:47] <atari2600a> don't mean to be annoying
[09:47] <atari2600a> but what's that apt-get arguement to get a system up into the 8.10 repositories?
[09:49] <Treenaks> atari2600a: this is not the channel for support, try #ubuntu+1
[09:49] <atari2600a> fail
[09:49] <atari2600a> kay, thanks
[09:49] <atari2600a> leaving
[10:02] <wgrant> Why is there Landscape advertising every time I log in?
[10:02] <cjwatson> bug 268447
[10:03] <sleepster> so I should just help debugging MOTDs
[10:03] <sleepster> in order to contribute
[10:05] <Hobbsee> wgrant: because mneptok wants to deal with more painful users?
[10:07] <persia> sleepster: I'd recommend finding anything that annoys you, and which you can understand, and fixing that.  You'll get more involved from there.
[10:07] <Q-FUNK> hi! could anyone chekc bug #241307 and tell me what else I could do to help get this fixed at least for Intrepid (and preferably Hardy too, since Hardy is what broke it and it's LTS)?
[10:07] <wgrant> cjwatson: Thanks.
[10:07] <sleepster> thanks persia
[10:08] <sleepster> I just have all this time, so I am trying to contribute to a project I like.. which is this
[10:09] <cjwatson> pitti: FYI firefox is in new with abrowser (in place of webbrowser); does it meet with your approval? I'd rather not approve it myself since I was involved in the naming discussion
[10:14] <pitti> cjwatson: yes, I quickly discussed that with Alex a couple of days ago, and I can live with it
[10:14] <pitti> cjwatson: I'll shove it through NEW today
[10:14] <cjwatson> great
[10:41] <asac> pitti: thanks ;)
[11:03] <tkamppeter> pitti, did you also package Jockey 0.5alpha1 for Ubuntu Intrepid?
[11:04] <pitti> tkamppeter: yes, just uploaded
[11:04] <tkamppeter> pitti, Thanks
[11:06] <Riddell> pitti: about bug 269314, who's alberto?
[11:06] <pitti> Riddell: tseliot
[11:06] <Riddell> ah, top bloke
[11:06] <pitti> :)
[11:06] <tseliot> Riddell: right
[11:06] <tseliot> ;)
[11:06] <cjwatson> I always thought he was a bit of a waste land
[11:06] <tseliot> cjwatson: that's a good one
[11:07] <cjwatson> sorry, short notice and all that :)
[11:07]  * Riddell doesn't get it
[11:07] <cjwatson> oh, I should have used "a bit hollow", that's a much better reference
[11:07] <cjwatson> Riddell: "The Waste Land" by T. S. Eliot
[11:07]  * pitti is confused
[11:07] <pitti> aah
[11:07] <tseliot> Riddell, pitti: http://en.wikipedia.org/wiki/T._S._Eliot
[11:08] <tseliot> and http://en.wikipedia.org/wiki/The_Waste_Land
[11:09] <tseliot> cjwatson: how come do you know Eliot?
[11:12] <cjwatson> tseliot: I don't particularly well, but it's hard to grow up in the UK without at least picking up a few references
[11:14] <pitti> cjwatson: oh, did you clean up NEW? when I looked earlier, there were still 44 packages, and now my current accept tells me it's down to 8
[11:14] <pitti> cjwatson: thank you
[11:15] <tseliot> cjwatson: aaah. I studied Eliot in my 1st exam at the university but I had never heard of him before. I live in Italy, after all
[11:15] <cjwatson> pitti: I did language packs and smart, yes
[11:15] <cjwatson> only five minutes or so
[11:16] <pitti> asac: just looked at NEW; I still don't understand the structure
[11:16] <pitti> asac: abrowser-3.0-branding says "This is a meta package that will point to the latest abrowser package"
[11:17] <pitti> asac: neither is true, it's not a meta package, and is specific to 3.0
[11:17] <pitti> asac: and there is no actual metapackage for it which would serve that purpose
[11:17] <pitti> so how is this meant to work?
[11:22] <pitti> asac: i. e. will you remove that bit from the abrowser-3.0-branding description and upload another version which actually *has* an "abrowser" metapackage?
[11:25] <pitti> cjwatson: since you were involved in the discussion, do you happen to know how that's supposed to look like? ^
[11:25] <asac> pitti: there should be an abrowser package
[11:25] <pitti> oh, of course, it's arch:all, sorry
[11:25] <asac> pitti: description can be fixed afterwards (when i fix the branding package)
[11:25] <asac> please dont block this on that
[11:25] <pitti> asac: no, I won't; sorry, I missed that one
[11:26] <asac> the branding package still ships files called awesome- ... basically because fixing that requires a new orig.tar.gz
[11:26] <asac> ok thanks
[11:27] <pitti> asac: oh, both packages replace firefox-3.0? is that intended?
[11:28] <pitti> asac: NEWed to main
[11:29] <asac> pitti: thanks. ill look at the replaces. i didnt touch them since i first did those packages (just renamed). so i dont remember for sure right now
[11:30] <asac> pitti: ah .. yes both branding packages replaces firefox-3.0 because they ship files previously in that package
[11:30] <tkamppeter> pitti, downloaded Jockey 0.5 from Launchpad and rebuilt, "Details" button at "License: Free" does not work (driver splix from OP).
[11:30] <pitti> asac: ah, maybe it should be versioned then
[11:30] <pitti> tkamppeter: ah, indeed, that still needs to be fixed
[11:31] <pitti> tkamppeter: second
[11:31] <asac> pitti: yeah. but i ran into versioned replaces issues in the past ... basically because hardy firefox will get a higher version on new security uploads
[11:31] <asac> pitti: so thats the best i could come up here (without risking to break hardy -> intrepid)
[11:31] <pitti> asac: should be (<< 3.0.2+build3+nobinonly-0ubuntu2)
[11:31] <pitti> asac: i. e. the current version that has the split packages
[11:31] <asac> pitti: yes. but hardy will soon have 3.0.3
[11:31] <pitti> oh, if hardy gets 3.0.3
[11:31] <pitti> indeed, nevermind then
[11:32] <asac> pitti: i know its not nice. but its ok that way imo
[11:33] <pitti> tkamppeter: bug 269352
[11:33] <tkamppeter> pitti, and the new driver list display is a one-timer. I run jockey-gtk twice, the first time all is OK, the second time only "splix" appears at the top and the details do not appear, also the action button stays grayed out, containing the label "Action".
[11:34] <pitti> tkamppeter: where do you run that from? the current 0.5 intrepid package, or a bzr branch, or trunk?
[11:35] <pitti> liw: does python-fstab have a FF exception? is it needed for intrepid?
[11:35] <tkamppeter> Current 0.5 Intrepid package. I downloaded the source package from LP, as it is not on the mirrors yet. Then I rebuilt on an Intrepid box.
[11:35] <pitti> liw: (it's in source NEW)
[11:36] <bigon> could someone uplaod my SRU for bug 255307 to -update as the fix has been confirmed to fix the issue
[11:36] <pitti> tkamppeter: hm, can you please file a bug about it with the details? please also include "jockey-gtk --list" output
[11:36] <pitti> bigon: will walk over SRU in a bit
[11:45] <ogra> pitti, is the code jckey uses to determine if restricted HW is there big ? i wonder if we could use that same code in the lrm initscript/initramfs scripts ... lrm eats at least about 5secs of your boottime for initializing even if teher is no HW that it needs
[11:47] <pitti> ogra: what is "restricted hardware"?
[11:47] <ogra> well, HW that needs restricted drivers i meant indeed :)
[11:47] <ogra> i would like to see lrm off by default until uts actively used
[11:47] <ogra> *its
[11:47] <pitti> ogra: hm, what does lrm do during that time, link the .ko for the various wifi drivers?
[11:48] <ogra> it mounts the tmpfs etc
[11:48] <pitti> ogra: it does not install/contain the video drivers any more
[11:48] <ogra> and wastes your ram and your bootime
[11:48] <pitti> and the wifi drivers should by and large be handled like normal kmods
[11:49] <ogra> imho it shoulndt bs sued/started at all until jockey has the chekmark set for the first time
[11:49] <pitti> ogra: yes, indeed it should check whether it already built the .ko files and don't do all that magic then
[11:49] <ogra> *used
[11:49] <ogra> right
[11:49] <pitti> ogra: but jockey depends on the .ko files and the modules.aliases to be present and current
[11:49] <ogra> http://mg.pov.lt/hardy-20080822-1.png ... that wastes 5 secs for lrm-manager and friends
[11:49] <pitti> so jockey can't know whether your wifi card needs a restricted driver, unless we have it available already
[11:50] <pitti> ogra: well, that's not entirely true actually, since eventually we can use an online DB, but ATM we don't, we just use local modalises
[11:50] <pitti> ogra: so one possibility would be that lrm shipd the modaliases pre-generated and then checks whether there is hardware which matches any of those, and then builds the .ko files
[11:51] <pitti> ogra: that part of the code is reasonably isolated
[11:51] <pitti> but it still takes a second or two
[11:51] <ogra> well, i see S07linux-restricted-modules running there, firing off lrm-manager which then spawns ld_static
[11:52] <ogra> imho S07linux-restricted-modules shouldnt happen at all i.e. only if enabled deliberately through an /etc/default file
[11:52] <ogra> which can be seeded by jockey
[11:52] <pitti> ogra: but we don't want all users to use jockey just to get their wifi card working, which would otherwise Just Work(tm) out of the box
[11:53] <ogra> hmm
[11:53] <ogra> i think i misunderstood jockey then ... i thought its for all restricted drivers, not only fglrx and nvidia
[11:53] <ogra> but indeed that wlan example makes sense
[11:54] <pitti> ogra: you can indeed use it to disable those restricted drivers, yes
[11:54] <ogra> yeah
[11:56] <doko> oha, a user submitting a bug report about a failed gmail login \o/
[11:56] <Q-FUNK> :D
[11:59] <pitti> ogra: the problem is that jockey relies on modalias files (it needs to get the hardware -> driver mapping from somewhere, after all, and so far modalias files are the standard means to do it
[12:00] <pitti> ogra: but as I said, I think the built .ko files should be cached and not rebuilt/rechecked on every boot
[12:00] <ogra> ok, i'll take a look at that in jaunty ...
[12:00] <ogra> my usecase is that i want to just install linux-generic in ubuntu-mobile for netbooks but 90% of them dont use restricted HW at all
[12:01] <ogra> though there might be someone with a USB nvidia card or somehing similar weird so i dont want to lose the functionallity in general
[12:01] <pitti> USB gfx!
[12:01] <pitti> does that actually exist? :-)
[12:01] <ogra> yep
[12:01] <pitti> ogra: wifi driver might be an issue
[12:02] <ogra> i doub you find nvidia though
[12:02] <pitti> ogra: NB that we don't install *any* nvidia bits by default in intrepid any more
[12:02] <pitti> well, except their modalias lists
[12:02] <ogra> yeah, it wasnt a really serious example :)
[12:02] <ogra> but in any case lrm is quite a serious waste of ram and bootime
[12:03] <ogra> so it should work more fine grained
[12:09] <asac> ogra: ltsp installs > 30 users + firefox
[12:09] <asac> ogra: what are your experiences?
[12:09] <ogra> i have no 30 clients :)
[12:09] <asac> ogra: you shoujld be subscribed to a bug of a user
[12:09] <ogra> asac, i saw the bug and i see complaints on the ltsp ML
[12:10] <asac> ogra: sure. i thought you might know people that have such installs
[12:10] <ogra> one thing is that the session killig doesnt properly work if users just shut down the cliet HW
[12:10] <asac> ogra: ok. so its a confirmed bug? i hoped its an issue in how its setup
[12:10] <ogra> so you might have FF processes hanging around and keeping the lock
[12:11] <ogra> another issue might be that these admins dont regard that you cant use 30 times the same user
[12:11] <ogra> and anoter might be that /home gets mounted dynamically on login from an nfs share
[12:12] <ogra> it really needs more research
[12:12] <ogra> one simple fact is that gnome-session doesnt seem to clean up properly on exit
[12:17] <pitti> ogra: I think the main problem is that the license doesn't allow us to ship the .ko files pre-linked; that would make it so much more efficient and avoid all this runtime linking stuff
[12:18] <ogra> pitti, well, but it should be easy to add a check to the lrm initscript and make it just exit if lrm isnt required ... i'll look into that for the jackalope :)
[12:18] <pitti> ogra: not as easy as you think IMHO
[12:19] <pitti> ogra: but it should indeed be easy to make the boot check much more efficient (if the .ko files are already there, do nothing)
[12:19] <ogra> right
[12:19] <liw> pitti, python-fstab hasn't got an FFe, I am going to ask for an FFe for system-cleaner once mvo (or someone) uploads it, and system-cleaner needs python-fstab
[12:19] <ogra> i'm sure *something* will be possible :)
[12:20] <pitti> ogra: indeed
[12:20] <pitti> ogra: and since Jaunty's goals include "boot-faster stripes", it's an adequate target :)
[12:21] <ogra> yep, and falls into my duties for ubuntu-mobile as well
[12:21] <ogra> thoug we might not define startup as boot ...
[12:22] <persia> That's best bit about jackaloupes being mythical: one can use allegory to redefine the user experience.
[12:23] <liw> persia, er, a non-existent user experience does not sound good
[12:23] <ogra> but that might even make sense for ubuntu as a default (never shutdown after first boot of the system but hibernate and make that very fast)
[12:24] <liw> ogra, is there a power use difference between hibernation and shutdown? I guess not
[12:24] <ogra> hibernate writes the ram to your disk and shuts down
[12:24] <pitti> ogra: I almost always hibernate, yes (except for kernel updates, or from some time to time when there's a new X or large GNOME changes)
[12:24] <ogra> but you can very likely make the resuming extremely fast
[12:24] <pitti> liw: no, it's completely off
[12:24] <ogra> if you profile and adjust that a bit
[12:24] <pitti> and booting from hibernation is faster than a "cold boot" (for me, anyway)
[12:25] <pitti> but it still takes ages
[12:25] <ogra> so boot time only affects you on first reboot after install and for HW changes
[12:25] <pitti> (compared to windows)
[12:26] <wgrant> Suspend serves me fine.
[12:26] <ogra> pitti, i bet that depends... virgin windows is actually fast ... my GF boots way slower than ubuntu on her XP with 5 years of installed apps though
[12:26] <ogra> wgrant, suspend needs power
[12:26] <wgrant> Except it takes ages (15-20 seconds) to suspend, but just a couple of seconds to resume.
[12:27] <liw> I have no machines on which hibernation works reliably, but resuming from hibernation always seemed to take more frustratingly long than just booting
[12:27] <ogra> but from a user POV there is no real difference between hibernate and boot
[12:27] <pitti> ogra: there is a lot, it keeps all your apss open
[12:27] <pitti> apps
[12:27] <wgrant> ogra: True, but I can leave this laptop for a couple of days without it going flat.
[12:27] <pitti> whereas gnome-session entirely forgot how to save/restore your session in intrepid, unfortunately
[12:27] <liw> ogra, some tasks like cleaning up /tmp and periodic fsck needs to be handled in some useful way, if there are no semi-frequent boots
[12:28] <pitti> wgrant: I don't use suspend at home, because I take out the battery at home
[12:28] <liw> of course, those tasks should be handled in some useful way separate from booting anyway
[12:28] <pitti> and I don't want to waste power over night by leaving the plug and thus the AC adapter on
[12:28] <persia> liw: Depends.  Having a non-existent user-experience of booting might just be fixing /tmp and fsck differently.  What else is routine and need not be exposed to users?
[12:30] <pitti> doko: BTW, there is no need to create separate "SRU" bugs like bug 269299
[12:30] <pitti> doko: please just create hardy tasks for the actual bugs you fix
[12:30] <pitti> and sub ubuntu-sru to them
[12:34] <pitti> mvo_: is bug 268052 relevant for intrepid? if not, please close the intrepid task
[12:37] <pitti> mvo_: also, any idea about the failure in bug 241431 ?
[12:38] <mvo_> pitti: let me check
[12:38] <mpt> pitti, yes, that rosette icon
[12:39] <mpt> pitti, having it scalable is a good idea, but I don't think it's as important as having the right icon in the first place
[12:39] <pitti> mpt: hello
[12:39] <mpt> Using an Ubuntu icon isn't particularly meaningful in this context
[12:39] <pitti> mpt: I sent you an updated status yesterday with an updated screenshot; let me know what you think
[12:40] <pitti> mpt: well, I initially thought "tested by the %(os) developers", so I used "distributor-logo"
[12:40] <mpt> slangasek, why do you take issue with it?
[12:40] <pitti> but the certification icon is nice as well
[12:42] <pitti> Riddell: hm, did you accept the hardy SRUs in https://edge.launchpad.net/ubuntu/+source/kio-umountwrapper ? there is no LP # associated with them
[12:44] <Riddell> pitti: let me look
[12:44] <mpt> pitti, yep, that looks good
[12:44] <pitti> \o/
[12:45] <mpt> though those not-installed icons are pretty alarming for something that's not even being used
[12:45] <Riddell> pitti: bug 186729
[12:45] <mpt> pitti, is there a grey equivalent?
[12:45] <pitti> mpt: the red bullet?
[12:45] <mpt> yes
[12:46] <pitti> Riddell: ah, it got positive feedback; I'd move this to updates, unless you object?
[12:46] <Riddell> pitti: yeah please do, sorry about the missing bug number not sure how I forgot that
[12:46] <pitti> Riddell: no problem, it just leads to stalled processing; I'm just walking over all the old ones
[12:47] <mpt> pitti, would you prefer feedback here or by e-mail?
[12:48] <pitti> mpt: by email actually, so that I can work on it in the plane on Monday
[12:48] <mpt> ok
[12:48] <pitti> mpt: thanks
[12:48] <asac> if i do cat /proc/locks i get numbers like: 08:06:4767745 ... those include major/minor device ids
[12:49] <asac> any idea how i can see what major/minor device a nfs mounted partition has
[12:50] <Hobbsee> evand: how much has the installer changed since alpha 5?  I installed off it today, and noticed some bugs in it.
[12:51] <ogra> asac, ?? nfs is a filesystem
[12:51] <ogra> there is no devices
[12:51] <ogra> *device
[12:51] <ogra> so no major minor device number
[12:52] <asac> ogra: how would nfs locks show up in /proc/locks
[12:52] <asac> ogra: ok. but is there something similar to a minor number?
[12:52] <ogra> no idea
[12:52] <ogra> for either of the questions
[12:52] <asac> too bad.
[12:52] <mvo_> asac: the nfs root mini howto says "mknod /dev/nfsroot b 0 255"
[12:52] <asac> ;)
[12:53] <asac> mvo_: ah
[12:53]  * asac looks at nfsroot
[12:53] <asac> hmm ... doesnt exist here
[12:53] <ogra> well, thats for rootfs on nfs afaik
[12:53] <pitti> mpt: I didn't find another matching stock icon; "stop" maybe (gray rectangle, as in music players)
[12:54] <pitti> mpt: but then I'd rather make the icon consistent to what is shown on the "Turn on/off" button
[12:54] <mvo_> ogra: (I missed most context and thought I just add the snippet of information I have :)
[12:54] <ogra> :)
[12:54] <mpt> pitti, actually I'd rather that button didn't have any icons at all :-)
[12:54] <pitti> mpt: and that uses the 8-edge red sign wiht a white X
[12:54] <mpt> pitti, because it competes for attention with the actual status icon
[12:55] <pitti> mpt: if you say so
[12:55] <ogra> asac, i case you look for firefox context, i think the /proc/locks stuff is kernel only
[12:56] <ogra> based on the flock system call
[12:56] <asac> ogra: ffox uses fcntl and the locks show up as posix locks
[12:56] <asac> ogra: the current issue i have is sqlite
[12:56] <pitti> mpt: oh, another possibility: I could use the stock icons for "connected" and "not connected" (the plug)
[12:56] <asac> which appears to use flock and somehow breaks on nfs
[12:57] <asac> ogra: well. i still want to verify that that lock without running pid is on that nfs partition
[12:57] <asac> but i ma quite sure
[12:57] <ogra> asac, http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html
[12:57] <ogra> look for flock
[12:57] <siretart> asac: flock() does not lock files over NFS.  Use fcntl(2) instead
[12:57] <siretart> asac: see flock(2), section NOTES, first paragraph
[12:57] <asac> siretart: exactly
[12:57] <ogra> In Unix, there are two flavours of file locking, flock() from BSD and lockf() from System V. It varies from system to system which of these mechanisms work with NFS.
[12:57] <asac> siretart: i know about that
[12:57] <mvo_> asac: flock does not work on nfs (see flock(2))
[12:58] <asac> siretart: however since 2.6.12 client its supposed to be supported
[12:59] <mpt> pitti, is the "stop" icon the one Empathy uses for "Offline"?
[12:59] <ogra> asac, lockd is usually responsible for locking on nfs btw
[12:59] <ogra> might be that we dont enable it by default
[12:59] <ogra> since ltsp switched from nfs to nbd i'm not up to date anymore :/
[13:00] <asac> ogra: so. disregarding that sqlite should probably use fnctl, http://nfs.sourceforge.net/ says that flock is supported since 2.6.12 clients ... where can i see the client version?
[13:00] <siretart> locking is btw the only reason why linux needs portmapper as nfs client...
[13:00] <ogra> ogra@osiris:~$ apt-cache show nfs-common|grep Version
[13:00] <ogra> Version: 1:1.1.2-4ubuntu1
[13:00] <amitk> cjwatson: FYI: LPIA kernel is ready to be uploaded. This is an ABI bump.
[13:01] <asac> ogra: is that really the client version?
[13:01] <cjwatson> amitk: thanks
[13:01] <ogra> asac, thats cntaining nfs-client
[13:01] <asac> ogra: i looked at it and assumed that its too low given that nfs refers to 2.6.12
[13:01] <cjwatson> amitk: 2.6.27-3, I take it?
[13:02] <amitk> cjwatson: yes. persia will upload it soon.
[13:03] <pitti> mpt: http://people.ubuntu.com/~pitti/tmp/STOCK_STOP.png and http://people.ubuntu.com/~pitti/tmp/STOCK_DISCONNECT.png
[13:03] <pitti> mpt: DISCONNECT's counterpart (CONNECT) is a plug which is plugged in, STOP's counterpart would be "PLAY" (gray triangle, as in totem/rhythmbox)
[13:03] <mpt> pitti, eek, stop definitely
[13:03] <cjwatson> amitk: cool, thanks
[13:04] <mpt> I mean, STOCK_STOP definitely
[13:05] <pitti> mpt: and for enabled ones, STOCK_PLAY (more consistent counterpart) or STOCK_OK (the green check mark, better contrast)
[13:05] <pitti> mpt: i. e. the one on http://people.ubuntu.com/~pitti/tmp/jockey-new.png on the button
[13:06] <mpt> pitti, neither, whatever Empathy uses for "Available"
[13:07] <pitti> is there a screenshot anywhere? otherwise I'll install it
[13:07] <mpt> or, if it exists, the green opposite of the red ones in that screenshot
[13:07] <pitti> ah
[13:07] <pitti> it doesn't exist as a stock icon
[13:07] <pitti> but I can grab it from somewhere, of course
[13:07] <mpt> ok
[13:09] <zul> cjwatson: can we get the tomcat-server added to tasksel please?
[13:09] <pitti> mpt: heh, tango has nice icons for sun and moon as well :-P
[13:09] <ogra> asac, i think that refers o the kernel module side
[13:10] <ogra> (sorry in a call)
[13:10] <asac> ogra: no problem.
[13:10] <asac> ogra: ill ask the reporter to go the hardway (e.g. find / -inum inode_no)
[13:14] <pitti> mpt: ok, using empathy-available.svg then (copying)
[13:16] <mpt> pitti, where did you get the bulbous red one from?
[13:16] <pitti> mpt: that's one of GTK's stock icons (STOCK_STOP)
[13:16] <Riddell> how do I report a bug in a translation?
[13:17] <pitti> Riddell: against language-pack-LL
[13:17] <pitti> and subscribe ubuntu-l10n-LL
[13:17] <mpt> pitti, so is there a GO opposite?
[13:18] <pitti> mpt: erm, sorry, stock icon for "No"
[13:18] <pitti> mpt: and the opposite, yes, is the green check mark
[13:18] <mpt> oh, bother
[13:18] <mpt> ok
[13:18] <tseliot> Riddell: I have solved the problem with the label in jockey-kde
[13:18] <pitti> ATM jockey uses NO/YES
[13:19] <pitti> mpt: so now I could change it to STOP (the grey square) and the green round "available" one
[13:19] <Riddell> tseliot: ooh, how
[13:19] <Riddell> ?
[13:19] <Riddell> pitti: thanks
[13:19] <tseliot> Riddell: somehow an additional vertical layout ended up in the ui and prevented the ui from resizing properly
[13:19] <pitti> mpt: you don't like the green check mark for enabled drivers? it's a stock one, so jockey wouldn't need to ship it
[13:20] <Riddell> tseliot: ah, how annoyingly fiddly
[13:21] <tseliot> Riddell: yes, I was looking anywhere but in the right place...
[13:21] <pitti> mpt: oh, I just saw that the official GTK upstream GTK_STOCK_YES is indeed a green round circle, apparenlty that has been replaced with a checkmark in our ubuntu theme
[13:21] <mpt> pitti, what I think would make most sense is a small, round, light grey bulb that becomes a small, round, glowing gren bulb when it's activated.
[13:22] <mpt> green, rather
[13:23] <mpt> I don't think it makes sense to use a checkmark, because it's too similar to a checkbox and because it understates the effect of the change.
[13:25] <pitti> ok
[13:26] <norsetto> zul: hi, was wondering if you could check bug 268762? Don't know much about xen myself so I could just talk rubbish
[13:26] <soren> zul: ^^
[13:27] <zul> norsetto: yeah Ill try to have a look at it today
[13:27] <norsetto> zul: much obliged
[13:31] <pitti> mpt: http://people.ubuntu.com/~pitti/tmp/jockey-new-stop_connected-icons.png
[13:32] <mpt> Oh, they're not even the same size :-(
[13:33]  * wgrant cries.
[13:33] <wgrant> Why is there a checkbox labeled "This driver is not installed"?
[13:33] <pitti> wgrant: it's not a checkbox, it's a "stop" icon
[13:33] <mpt> Yeah, that's a very Windows XP checkbox
[13:33] <pitti> bwah, icons
[13:33] <wgrant> Ohh.
[13:33] <wgrant> I thought it was a nice double-negative checkbox.
[13:33] <mpt> or a Mac OS 8/9 close box
[13:34] <mpt> kwwii!!!
[13:34] <mpt> We need halp
[13:34] <pitti> I can has an icon?
[13:34] <Hobbsee> pitti: noes.  no gummy bear, either.
[13:34] <pitti> wgrant: http://people.ubuntu.com/~pitti/tmp/jockey-new.png is the current state
[13:34] <wgrant> What's wrong with a checkbox?
[13:34] <pitti> wgrant: s/box/mark/?
[13:35] <wgrant> pitti: That looks dangerous.
[13:35] <mpt> wgrant, it's not momentous enough
[13:35]  * mpt continues to suffer from a lack of good words to describe these issues
[13:35] <wgrant> Do those that aren't enabled actually need an icon?
[13:36] <mpt> wgrant, I think that would look unnervingly like this window didn't know whether they were activated or not
[13:36] <pitti> I think the best way forward right now is to have lunch, before I entirely miss preparing myself for the release meeting later on
[13:36] <mpt> wgrant, especially if all the drivers in the list happen to be turned off.
[13:37] <wgrant> mpt: True.
[13:37] <wgrant> Anyway, /me -> bed. Have fun working it out.
[13:39] <kwwii> mpt: wassup?
[13:40] <mpt> kwwii, do you have time to draw us four small icons?
[13:40] <mpt> for the Hardware Drivers window
[13:42] <_MMA_> mpt: They have to be custom? There's nothing that conforms to FreeDesktop we can use?
[13:43] <mpt> _MMA_, no, see the previous 59 minutes discussion
[13:45] <mpt> (Also, it's an awkward choice of words to imply that "confirms to FreeDesktop" requires using no custom icons. The standard icon names never have covered, and never will cover, all the icons every app ever needs.)
[13:47] <_MMA_> mpt: I've seen most of it. And sure, not everything is covered there. I just don't wanna see more icons that cant be themed. As I'm heading an effort currently for a new set.
[13:47] <_MMA_> *new set for Ubuntu.
[13:47] <ogra> as the guy who works wiht desktops that use 48px panels on touchscreens i'd like to bg you guys to use scalable icons :)
[13:47] <kwwii> mpt: send me an email with the description of what you need and/or a screenshot of the current stuff and I will see what I can do
[13:47] <ogra> *beg even
[13:47] <ogra> the human theme is a mess with that
[13:47] <mpt> thanks kwwii, will do
[13:48] <ogra> i have to use gnome on ubuntu-mobile to make te icons usable eith fingers
[13:48] <ogra> *with
[13:50]  * norsetto wonders about the size of ogra's fingertips
[13:51] <Robot101> huge, in comparison to the pixels on a high-res mobile lcd touchscreen
[13:51] <ogra> norsetto, they are 48x48px on 1024x600 7" screens :)
[13:51] <Robot101> :)
[13:51] <ogra> well, index is probably 36x36 :) but i use my fat thumb quite often
[13:57] <cjwatson> zul: somebody needs to create the seed
[14:00] <zul> cjwatson: its already done in my branch ready to be merged
[14:02] <evand> Hobbsee: There were a few changes that went in after alpha-5.  Have you created bug reports for these issues?
[14:02] <ScottK-laptop> StevenK: If you're still about, I also have Bug 269393 for you.
[14:03] <Hobbsee> evand: not yet.
[14:03] <StevenK> ScottK-laptop: Always happy to remove stuff
[14:04]  * ScottK-laptop figured.
[14:05] <norsetto> StevenK: If you're still about, I also have Bug 268713 for you.
[14:06] <cody-somerville> norsetto, let the man sleep :P
[14:06] <StevenK> norsetto: Aye, will do.
[14:06] <norsetto> cody-somerville: why!? :-)
[14:07] <cody-somerville> norsetto, A tired StevenK is a grumpy StevenK :P
[14:07] <norsetto> StevenK: thx, I knew I could count on you :-D
[14:08] <norsetto> cody-somerville: just trying to make him happy ;-) (<StevenK> ScottK-laptop: Always happy to remove stuff)
[14:08] <cody-somerville> hehe
[14:08] <Hobbsee> evand: ah, so i'm not mad.  I hit https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/264599 too
[14:08] <cjwatson> zul: /wg 112
[14:08] <cjwatson> oops
[14:12] <evand> Hobbsee: hrm, ok
[14:12] <Hobbsee> evand: ah, most of the stuff I found seems to already be reported.  I hit  https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/259713 (before a resize), and https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/264595 (after doing a resize), and found that / doesn't get automatically ticked to format by default.  I'm sure there's a bug for that somewhere too, but I can't find it right now.
[14:12] <ion_> 112? Dayum.
[14:13] <Hobbsee> evand: I also had X blow up twice during the install, so had to install a second time, but I doubt that's due to you.
[14:14] <Hobbsee> evand: FWIW, i also found it non-obvious how to leave a partition the current size - it seems the field is there to only change it - i was afraid it would randomly resize my partitions if i did, or did not, change the values in that field - it's all just a bit unclear - particularly when it says sizes like '0' to start with
[14:14] <evand> I sure hope it isn't :)
[14:14] <Hobbsee> fortunately, my
[14:14] <Hobbsee> fortunately, my 'doze still works.  I was half expecting it not to, after dying the first time while partitioning.
[14:16] <evand> Leaving it untouched *should* leave it as is, but a bug like this throws everything out the window.
[14:16] <Hobbsee> evand: yeah....i think it probably would have, it was just the GUI that was unclear.
[14:17] <Hobbsee> evand: oh, and the timezone setter map thing is a nightmare - maybe it was because the window wasn't properly done, or something.  I'm not sure, but I found it very hard to actually select my location on it.  I thought there was a ffe bug to fix that, a while ago.
[14:17] <Hobbsee> so perhaps that's the improved version
[14:17] <Hobbsee> it also picked the wrong time, the first time around.
[14:17] <evand> Yeah, there's still at least one fix needed for that, which will go in before release.
[14:18] <Hobbsee> cool :)
[14:18] <evand> It was supposed to be replaced by a *much* better version, but I ran out of time in implementing it.
[14:18] <evand> so that will happen for Jaunty.
[14:18] <Hobbsee> ah, yes.
[14:19] <Hobbsee> I see that bug now.
[14:20] <norsetto> evand: is bug 268115 relevant for you ?
[14:21] <mdz> asac: the most recent firefox update gave me ugly widgets.  I don't see a bug report about it; am I the only one?
[14:21] <asac> mdz: ugly widgets?
[14:21] <mdz> asac: http://people.ubuntu.com/~mdz/temp/Screenshot-firefox.png
[14:22] <evand> Hobbsee: That sounds very similar to a bit from ubiquity-visual-refresh that mpt suggested, which I hope to sneak in with a UI freeze exception.
[14:22] <ogra> looks more like a theme issue
[14:22] <mdz> different shade of gray, different drop shadow
[14:22] <Hobbsee> evand: interestingly, a friend of mine recently installed ubuntu, and got very confused on the partitioning section - had no idea what it was, so went with the defaults - all was fine, but there might be more you can do to make it newbie-friendly - maybe add a link with an explanation somewhere, or something.
[14:22] <Hobbsee> evand: good luck :)
[14:22] <mdz> ogra: it's only firefox...but then, that's the only app I restarted
[14:22] <asac> mdz: yeah. thats the "default" gtk theme ... looks like your gnome theme is somehow not honoured
[14:23] <mdz> yeah, it affects rhythmbox as well
[14:23] <asac> hmm ... at least the widgets. the icons are right
[14:23] <mdz> anything I start since the update
[14:23] <evand> Hobbsee: I did add a visual representation of the partition table on both the automatic partitioning page (shows you the disk before and after) and the manual partitioning page (shows you what the disk will look like as you chang eit)
[14:23] <asac> mdz: sounds more like a theme bustage
[14:23] <Hobbsee> that looks like motif.  I saw that on hte livecd today, and wondered why that was there.
[14:23] <evand> Hobbsee: so hopefully that's a helpful start
[14:23] <asac> mdz: what else was upgraded?
[14:23] <Hobbsee> evand: oh, that'd be good - but i think this particular one was the screen first.
[14:23] <asac> maybe you need a restart of gnome session?
[14:23] <mdz> asac: lots
[14:23] <evand> ok
[14:23] <mdz> I just tried restarting gnome-settings-daemon and that made it worse
[14:24] <seb128> mvo__: there?
[14:24] <mdz> I need to reboot for the new kernel anyway, I'll just do that and it will probably sort itself out
[14:24] <ogra> human-theme was updated on wed.
[14:24] <asac> mdz: thanks. lets hope ;)
[14:24] <Hobbsee> mdz: if you open up the appearances section, do you get a message saying human-murrine or something isn't installed?
[14:24] <Hobbsee> bah.
[14:24] <mvo> seb128: yes
[14:24] <asac> ogra: but does a theme update require a restart?
[14:24] <asac> ogra: engine update i could imagine
[14:24] <ogra> it shouldnt
[14:24] <seb128> mvo: bug #269215 looks weird, just to let you know in case you screwed something
[14:25] <ogra> asac, well: * Added gtk2-engines-ubuntulooks to Conflicts and Replaces
[14:25] <ogra> not sure what that implies though
[14:25] <asac> oh ... so the engine has been removed ;)
[14:25] <ogra> the old one
[14:25] <ogra> it shuld use murrine afaik
[14:25] <asac> ogra: is there a replacement?
[14:25] <asac> ah ok
[14:25] <ogra> since a while already
[14:26] <ogra> but only kwwii could tell :) i'm only following artwork loosely
[14:26] <asac> ok. feels like changing engine during upgrade can cause such issues
[14:26] <mvo> seb128: thanks, I check it out, the diff http://launchpadlibrarian.net/17534395/gconf_2.23.2-0ubuntu2_2.23.2-0ubuntu3.diff.gz looks pretty safe though
[14:26] <ogra> well, the gtkrc shouldnt point to that engine anymore
[14:27] <ogra> but if you use a theme that does this might break it
[14:27] <mdz> nope, that didn't fix it
[14:27] <seb128> mvo: indeed
[14:27] <Hobbsee> [23:24] <Hobbsee> mdz: if you open up the appearances section, do you get a message saying human-murrine or something isn't installed?
[14:27] <seb128> mdz: try opening the appearance capplet and see what is selected there?
[14:27] <mdz> seb128: my theme is set to 'custom' now
[14:27] <mdz> Hobbsee: ^^
[14:27] <Hobbsee> hm.
[14:27] <mdz> but I have not changed it
[14:28] <mdz> "this theme wil not look as intended because the required GTK+ theme 'Human-Murrine' is not installed"
[14:28] <seb128> mdz: grep for gtk in the dpkg.log so see which themes got installed or removed?
[14:28] <Hobbsee> ah yes, that's the error message.
[14:28] <mdz> ii  gtk2-engines-murrine                      0.53.1+svn20080529-0ubuntu3           cairo-based gtk+-2.0 theme engine
[14:28] <ogra> ouch
[14:28] <Hobbsee> seb128: fwiw, that's also on an alpha5 cd, at least some of the time.
[14:29] <mdz> perseus:[~] grep 'remov.*gtk' /var/log/dpkg.log
[14:29] <mdz> 2008-09-08 09:56:26 remove libgtk2.0-dev 2.14.1-0ubuntu1 2.14.1-0ubuntu1
[14:29] <ogra> -dev
[14:29] <mvo> Riddell: could you please commit your changes to compiz into the compiz bzr?
[14:29] <mvo> Riddell: (probably just a forgotten bzr push)
[14:29] <Hobbsee> tjaalton: oh, is there a new mesa to test?
[14:29] <ogra> mdz,
[14:30] <ogra> human-theme (0.24) intrepid; urgency=low
[14:30] <ogra>  .
[14:30] <ogra>    * fixing problem in setup.cfg
[14:30] <Riddell> mvo: to compiz?
[14:30] <ogra> night have a typo or some such
[14:30] <ogra> the same upload removed ubuntulooks
[14:30] <Riddell> mvo: oh, that right, hang on
[14:30] <tjaalton> Hobbsee: yes, but if the drirc trick didn't work, maybe the new mesa won't either. but please, do test :)
[14:30] <mvo> Riddell: thanks
[14:30] <Hobbsee> tjaalton: got a location?
[14:30] <tjaalton> Hobbsee: the archive?
[14:30] <mdz> Hobbsee: you saw this as well? is there a bug open?
[14:31] <Hobbsee> mdz: i saw it on a live cd today.  I've nto reported a bug so far.
[14:31] <asac> mdz: apparently the old engine was replaced by murrine
[14:31] <Hobbsee> mdz: I've just checked the ISO testing thing, where nothing was raised - which is surprising.
[14:31] <ogra> but probably not in gtkrc
[14:32]  * ogra just runs a dist.-upgrade and will debig if seeing the same
[14:32] <Hobbsee> tjaalton: oh, i didn't think you'd uploaded it yet, with the upcomming alpha, and being uncertain as to whether it fixes the problem or not.  My mistake.
[14:32] <ogra> but i use human-dark here by default
[14:32] <asac> mdz: ah sorry. you already dealt with that
[14:32] <ogra> *debug :)
[14:32] <asac> (didnt see in my scrollback)
[14:32] <tjaalton> Hobbsee: it fixes the problem for me, and a couple of other users
[14:32] <Hobbsee> tjaalton: ah, right.
[14:32] <norsetto> ogra: you should really do something about your fingertips ;-)
[14:32] <Hobbsee> zomg, argh!  human-dark!
[14:33] <ogra> norsetto, well, i'm better with cellwriter :)
[14:33]  * Hobbsee curses custom-made white-on-white text.
[14:33] <ogra> Hobbsee, i use it on ubuntu-mobile so i try to keep it on my lappie as well to see issues
[14:33]  * jdong ponders the wording human-dark a bit....
[14:33] <Hobbsee> I don't have a human-murrine after installing.  I wonder if that's intentional.
[14:33] <Hobbsee> ogra: ahhh
[14:34] <ogra> beyond that i really got used to the dark one, its slick
[14:34] <Riddell> mvo: hmm, ~compiz/compiz/ubuntu/ ?  I'm not in that team
[14:34] <jdong> how come nobody ever told me about the dark variant?
[14:34] <ogra> jdong, it was the default for quite some time during intrepid
[14:35] <jdong> ogra: guess I've been out of touch then :)
[14:35] <pitti> sorry, my computer crashed over my lunch break; I probably lost some IRC pings
[14:35] <jdong> silly migrating hardy settings to intrepid :)
[14:35] <mvo> Riddell: ok, could you please push to oyur peronal repo and I will merge?
[14:35] <dholbach> soren: what do I do about "serial0 console" in KVM again?
[14:35] <mvo> Riddell: or if you don't have it in bzr, I will do a debdiff and merge myself
[14:36] <mvo> Riddell: I can add you to the team too if you want
[14:36] <soren> dholbach: -v
[14:36] <dholbach> soren: I have a intrepid session open in virt-manager and hit some keys and now it just says "serial0 console"
[14:36] <soren> dholbach: Oh. Heheh..
[14:36] <soren> dholbach: ctrl-alt-1
[14:36] <dholbach> soren: it's a black screen and whatever I press it won't let me go back to do my work again
[14:36] <dholbach> it sucks!
[14:37] <dholbach> thanks a lot soren :)
[14:37] <soren> dholbach: :)
[14:37] <mvo> Riddell: nevermind, I merged it manually
[14:38] <pitti> mpt: I looked through the Tango icons; they do have an off bulb, but not a lighted bulb
[14:38] <Riddell> mvo: ok, i put it in ~jr/compiz/ubuntu/
[14:38] <pitti> mpt: the closest I can find is a sun and a moon, as I said, but in small sizes they look clumsy
[14:38] <Riddell> mvo: including the change from the previous upload
[14:39] <Hobbsee> dholbach: is it possible to get an address set for the ubuntu-core-dev team, or something?  I saw you did some team mangling, but it appears we're still getting mail from uninformed people assigning/subscribing us to bugs.
[14:40] <dholbach> Hobbsee: I didn't do any team mangling
[14:40] <mpt> pitti, ok, I'll sort this out with kwwii
[14:40] <pitti> mpt: many thanks
[14:40] <dholbach> Hobbsee: and I'm not a team admin, I think somebody on the TB might know better
[14:41] <mvo> thanks Riddell
[14:41] <Hobbsee> dholbach: ah.  Could you get it sorted out, or should I poke? :)
[14:41] <dholbach> Hobbsee: it'd be great if you could ask what the status is there
[14:42]  * ogra grumbles about the reboot notiifcation
[14:42] <Hobbsee> dholbach: OK, will do - although i'm planning to head to bed.  Monday it is.
[14:42] <Hobbsee> ogra: be greatful it's not like XP's...
[14:42] <dholbach> Hobbsee: ROCK
[14:44] <Hobbsee> dholbach: PAPER.
[14:44] <infinity> Hobbsee: SCISSORS
[14:45] <Hobbsee> infinity: *grin*.  I was wondering if someone would get the reference
[14:45] <ogra_> mdz, g-s-d doesnt start at all for me ...
[14:45] <ogra_> so my themeing is broken as well now
[14:47] <mdz> ogra: it starts fine for me
[14:47] <mdz> but the theming is not right
[14:48] <ogra> it segfaults for me
[14:49] <ogra> oh, no it doesn, but exists
[14:49] <ogra> getsockname(12, {sa_family=AF_FILE, path="/tmp/orbit-ogra/linc-292e-0-4cae298d9ba0e"}, [44]) = 0
[14:49] <ogra> writev(11, [{"GIOP\1\2\1\0\220\1\0\0", 12}, {"@J\303\277\0\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\315\340\270"..., 400}], 2) = 412
[14:49] <ogra> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb6e41748) = 10545
[14:49] <ogra> exit_group(0)                           = ?
[14:49] <ogra> Process 10542 detached
[14:52] <ogra> aha!
[14:52] <ogra> logout/in fixed it
[14:53] <ogra> and i found that gnome-panel couldnt resolve my hostname on login
[14:54] <ogra> but my dark theme is ok again
[14:54] <ogra> theme switching works as well
[15:01] <RicardoPerez> hi! anybody knows when will be the intrepid translations opened?
[15:01] <cjwatson> they already are
[15:02] <cjwatson> first language packs went into intrepid last week, and https://translations.launchpad.net/ubuntu/intrepid is open
[15:02] <cjwatson> ArneGoetje: did you mail ubuntu-translators@ to let them know about this?
[15:02]  * ogra tries of the theme survives a new boot
[15:03] <cjwatson> I've changed the translation focus (https://translations.launchpad.net/ubuntu) to intrepid now
[15:04] <RicardoPerez> cjwatson: great, thanks a lot for the response :)
[15:05] <ogra> all fine even on a second boot
[15:05] <ogra> though i had no usplash on shutdwom
[15:45] <slangasek> mpt: because drivers are not something that one turns on
[15:46] <mpt> slangasek, that's begging the question a little, isn't it? :-) You do *something* to them to make Ubuntu think about using them when it wouldn't have before.
[15:47] <pitti> argh, again
[15:47] <mpt> "Activate" might be better, though I'm a little concerned that it's too close to "Use", when it doesn't necessarily mean that Ubuntu will end up using the driver at all.
[15:47] <mpt> Then again, maybe "Turn On" has the same problem.
[15:47] <pitti> bryce, tjaalton: since today, my computer hard-locks at some point of idling, I strongly assume it happens when X tries to switch off the monitor for screensaver
[15:48] <slangasek> mpt: well, the English center of my brain goes "hnyaaaaah" at the use of the phrase.  I can't offer you a more substantial argument. :)
[15:48] <persia> How about "Enable"/"Disable" ?
[15:48] <Koon> slangasek: about likewise-open, dendrobates told me you were working on a more-compatible PAM fix -- do you still want me to file a FFe for the 4.1.2982 update proposed on bug #262264 or would that be orthogonal to your efforts ?
[15:49] <slangasek> persia: that's what was there before, and has been rejected :)
[15:49] <persia> But there aren't any other good words that are both accurate and short :(
[15:49] <mpt> persia, "disable" is ok, but "enable" tends to be unhelpfully vague.
[15:49] <slangasek> I think 'Activate' is closer
[15:49] <mpt> ok, fair enough
[15:49] <mpt> "Activate" it shall be
[15:50] <persia> But what if the user "Activates" it, and it doesn't actually get loaded or used?
[15:50] <slangasek> Koon: ah, hold off on filing an FFe for the moment, please
[15:50] <slangasek> persia: how is that different than enabling it and having it not be loaded or used?
[15:50] <mpt> persia, then the status text will say "This driver is activated but not being used."
[15:50] <Koon> slangasek: ok
[15:53] <persia> slangasek: Well, when something is enabled, it might be active and it might not be: it's correctly vague.  When something is activated, yet inactive, it seems wrong.
[15:53] <persia> mpt: How can something be activated but not active?
[15:54] <slangasek> to me, activated means that it's in a state that's ready for use, not that it's in use
[15:54] <mathiaz> slangasek: I've reworked the landscape-client package, splitting it in two packages - here is the changelog http://paste.ubuntu.com/46261/
[15:54] <ogra> pitti, do you have an intel card and use compiz ?
[15:54] <mathiaz> slangasek: do I need to request a FFexception ?
[15:55] <tseliot> persia: enabled (e.g. in the xorg.conf) but not in use i.e. the module is not loaded (e.g. if blacklisted, etc.)
[15:55] <slangasek> mathiaz: hrm, I thought splitting the package had been rejected as a solution
[15:56] <ogra> pitti, there is a bug in compiz apparently that causes such things, i switched to metacity and the prob went away, Ng had a similar issue
[15:56] <mathiaz> slangasek: hm - which solution are you refering to then ?
[15:56] <pitti> ogra: yes
[15:56] <Ng> ogra: pitti: see https://bugs.launchpad.net/bugs/262605
[15:56] <pitti> ogra: ah, indeed
[15:57] <persia> tseliot: Precisely.
[15:57] <pitti> until yesterday I had metacity
[15:57] <pitti> since gnome-session didn't get along with the compiz startup detection magic
[15:57] <pitti> Ng, ogra: thanks!
[15:57] <ogra> :)
[15:57] <Ng> I believe tjaalton tracked it down to some mesa vblank thing
[15:57] <pitti> bryce, tjaalton: this seems to be it
[15:58] <slangasek> mathiaz: the solution that was being discussed the other day was to adjust smartpm (as depended on by landscape-client) so that it's only available under /usr/share/landscape/, and proceeding with an MIR, I thought
[15:58] <slangasek> mathiaz: or is the smartpm dep itself an issue for CD size?
[15:59] <mathiaz> slangasek: the pkg split for smartpm has already happened
[15:59] <mathiaz> slangasek: this is another pkg split for the landscape-client.
[15:59] <cjwatson> slangasek: this is arising from landscape-client having had a stub in desktop for a long time
[15:59] <pitti> slangasek, mathiaz: and to keep the landscape-client stub on new desktop installs and upgrades, and only ship the sysinfo part on servers (AFAIUI)
[16:00] <mathiaz> slangasek: ^^ - correct
[16:00] <cjwatson> slangasek: we were just talking about this on the phone, and agreed to exchange mail about exactly what all the desired upgrade behaviours were before committing to a split
[16:00] <cjwatson> AIUI
[16:00] <cjwatson> smartpm is a separate deal but also required
[16:00] <cjwatson> anyway, we have a release meeting now ...
[16:02] <tjaalton> pitti: try upgrading mesa and tell me if it still hangs
[16:03] <pitti> tjaalton: oh, very fresh mesa? I dist-upgraded like 3 hours ago
[16:03] <tjaalton> pitti: 7.1-1ubuntu2
[16:03] <pitti> tjaalton: and restarted my session today due to the kernel update, which caused compiz to run now; that's what triggered it, I assume
[16:03] <tjaalton> pitti: yes
[16:03] <pitti> tjaalton: awesome, will try (still have ubuntu1)
[16:04] <tjaalton> pitti: the real fix will land in the kernel drm once upstream figures out what it is :)
[16:10] <pitti> tjaalton: ah, the changelog has an ill-formatted bug, thus the bug is still oopen
[16:11] <tjaalton> pitti: I left it on purpose, since someone said that the drirc workaround didn't work
[16:12] <pitti> tjaalton: ah, ok; I'll restart X and my session after the meeting and try, and comment on the bug
[16:12] <pitti> to collect some testing data
[16:12] <tjaalton> pitti: great, thanks
[16:13] <mpt> kwwii, e-mailed
[16:14] <slangasek> persia: are you available to stand in for mobile on the release meeting?
[16:15] <persia> slangasek: Sure, although I've not prepared things.  Let me try to get someone else (or I'll stand in in a few minutes)
[16:16] <cjwatson> sbeattie: (from #ubuntu-meeting) it's more or less http://people.ubuntu.com/~cjwatson/bzr/britney/cdimage/ with configuration tweaks)
[16:16] <slangasek> persia: well, see mail from lool that he can't make it and he doesn't think davidm is available
[16:17] <persia> Heh.  OK :)
[16:17] <sbeattie> cjwatson: thanks!
[16:19] <kwwii> mpt: got it, I'll see what I can come up with and we can discuss it more per email
[16:21] <ogra> kwwii, did you notice mdz's theme probs (apparently showing up also on the liveCD)
[16:22] <tkamppeter> pitti, I have reported some bugs on Jockey
[16:22] <pitti> tkamppeter: I saw them, thank you
[16:23] <pitti> tkamppeter: something to play with on my long 11 hour flight to Portland next Monday :)
[16:25] <tkamppeter> pitti, WDYT when will you have the D-Bus API and the asynchronous D-Bus call bug ready so that I can make the patch for s-c-p and hal-cups-utils to ask Jockey for drivers?
[16:26] <pitti> tkamppeter: you mean the bugs fixed? I hope I can do it next week, doesn't sound too hard; the general functionality is there, after all
[16:26] <tkamppeter> pitti, I would like to do the s-c-p and hal-cups-utils part then and post an FFe.
[16:28] <pitti> tkamppeter: nice; in either case it could already go upstream then
[16:28] <pitti> tkamppeter: since I'll continue to develop jockey upstream independently of the intrepid release, too
[16:29] <tkamppeter> pitti, it will naturally go also upstream into s-c-p.
[16:32] <tkamppeter> pitti, it cannot even break Fedora when they do not ship Jockey, as if the D-Bus call does not succeed to contact Jockey I will simply let the error get ignored.
[16:32] <cjwatson> zul: updated tasksel on its way
[16:33] <zul> cjwatson: thanks
[16:40] <calc> yea this storm is looking nasty, i think i'm going to go to dallas after all, it circled back to try to hit us :\
[16:40] <calc> and i only have about 6-8hr left to get out before the wind starts picking up a lot
[16:41] <davidm> come on up
[16:41] <calc> the current model moved it back directly on top of our place (or within 1/2 mile anyway)
[16:42] <calc> last night it had moved all the way east of houston, so i was hoping it would be safe enough, heh
[16:42] <davidm> calc, will you be bringing your sister too?  We have room
[16:42] <calc> i can see if she wants to come along
[16:45] <liw> calc, good luck
[16:46] <tedg> calc: Oh, still choosing him over me -- I see how it is ;)  Drive safe!
[16:47] <calc> ok well can't reach her right now so i'll ask her in person
[16:47] <calc> tedg: its a matter of driving time, thank you very much for the offer though :)
[16:47]  * calc hugs tedg 
[16:47] <tedg> I understand, I was just harassing you.  I do think you should stop tying and go though :)
[16:47] <tedg> typing.
[16:47] <calc> yep, i am breaking the stuff down now
[16:48] <calc> wind speed here will be TS level by 4pm
[16:48] <tedg> Nice, current models don't have us getting over 30 mph.  They were predicting 50 mph last nigh.
[16:48] <tedg> night.
[16:49] <calc> hmm i'm surprised it went down for you overnight since the hurricane strenghtened since then
[16:51] <tedg> It's going further east for us.  More missing us than less strength.
[16:53] <sbeattie> calc: good luck!
[16:56]  * calc shutting down now, should be leaving in 30m or so
[17:20] <pitti> dendrobates: FYI, smart promoted, bug 260443 commented
[17:21] <dendrobates> pitti: could you please look at the update-motd mir as well?
[17:21] <pitti> dendrobates: just did, see the bug :)
[17:22] <cjwatson> pitti: is xinput OK to promote, do you think? xorg depends on it now
[17:22] <cjwatson> it's pretty trivial
[17:22] <dendrobates> pitti: you are great, thanks.
[17:22] <pitti> cjwatson: oh, sure; thought it was already
[17:23] <cjwatson> I'll do that
[17:24] <pitti> dendrobates: don't thank me until you see my ramblings about it :)
[17:25] <cjwatson> heno: ^- xinput should fix xorg installability I think
[17:27] <heno> cjwatson: great, thanks
[17:28] <radix> pitti: heyo, there seems to have been a problem uploading a change to smart that seems to have happened just as it was being added to main
[17:28] <radix> we got some strange errors
[17:28] <pitti> radix: ah, "failed to upload"?
[17:28] <radix> pitti: sec, I'll find an URL for you
[17:28] <radix> I have email logs from the buildd talking about it
[17:29] <radix> the state is "Failed to upload"
[17:29] <pitti> radix: yes, that happens if you promote a source while binaries are currently being built; soyuz quirk
[17:29] <radix> aha
[17:29] <pitti> radix: right, known issue
[17:29] <radix> whew, I'm glad you know about it
[17:29] <pitti> radix: the easiest solution is to just have them be built again in about... 1:30 hours
[17:29] <radix> pitti: do I have to do something for that?
[17:30] <radix> or is it automatic?
[17:30] <pitti> radix: just ask any core developer to do so
[17:30] <pitti> you can't do it yourself, I think
[17:30] <radix> right ,I'm not even a MOTU yet :)
[17:30] <pitti> radix: I think I'll still be online at that time, so shold I forget, just prod me
[17:30] <heno> cjwatson: any chance we could respin a few images with these fixes so we can test our testing?
[17:30] <cjwatson> radix: why the Pre-Depends?
[17:30] <cjwatson> heno: sure, if I'm still around when it's time
[17:30] <heno> great, thanks!
[17:31] <hunger> Is it possible to turn of stack smashing protection when building a deb for intrepid?
[17:31] <radix> cjwatson: ok, so smartpm-core installs a symlink /usr/bin/smart -> /usr/share/smart/smart; python-smartpm installs /usr/share/smart/smart
[17:31] <radix> cjwatson: smartpm-core invokes 'smart' in its own postinst
[17:31] <cjwatson> hunger: -fno-stack-protector
[17:31] <cjwatson> radix: that only requires Depends
[17:31] <dendrobates> pitti: those are completely reasonable and helpful comments on update-motd.
[17:32] <radix> cjwatson: does a Depend guarantee that the depended-upon package will be unpacked before the depending package?
[17:32] <cjwatson> radix: you would only need Pre-Depends if you were invoking smart in smartpm-core's preinst
[17:32] <cjwatson> radix: yes, absolutely!
[17:32] <radix> humm, we actually found an error
[17:32] <cjwatson> Pre-Depends is usually not the right fix, and policy explicitly says that you must discuss new Pre-Depends
[17:32] <cjwatson> precisely because they're usually the wrong fix and complicate upgrades
[17:32] <radix> ah. woops. :-(
[17:33] <cjwatson> what was the error?
[17:33] <pitti> radix: so, even easier then -- just get a fixed package uploaded, it should build fine
[17:34] <mathiaz> radix: are you refering to the python-gobject bug ?
[17:34] <mathiaz> cjwatson: https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/268838
[17:34] <radix> mathiaz: no, this is about the smartpm-core/python-smartpm split
[17:34] <radix> sec
[17:34] <mathiaz> cjwatson: I've used a Pre-Depends to fix the bug above ^ ? Is this correct ?
[17:34] <cjwatson> no, it is not
[17:35] <mathiaz> cjwatson: what would be the correct fix ?
[17:35] <cjwatson> I'm not sure, but it ain't pre-dep
[17:36] <cjwatson> seems like bug 121341
[17:36] <cjwatson> in any case having smartpm-core pre-depend on python-smartpm is a really nonintuitive approach to fixing a bug that's to do with the interaction between landscape-client and python-gobject!
[17:37] <pitti> slangasek, tjaalton: can I have some 15 mins to catch up with some stuff and take a quick break?
[17:37] <tjaalton> pitti: sure
[17:37] <cjwatson> you use python-central for python-smartpm so shouldn't run into this problem there
[17:37] <mathiaz> cjwatson: hm - I think I've stepped in the middle of a conversation
[17:38] <mathiaz> cjwatson: I think we're discussing two issues here.
[17:38] <mathiaz> cjwatson: but you're right that the issue I ran into (landscape-client) is related to bug 121341
[17:38] <persia> mathiaz: The quick & dirty solution to your issue is for python-gobject to use python-central
[17:39] <cjwatson> agreed, but we probably don't have the effort to do that across the board
[17:40] <radix> cjwatson: the smartpm-core -> python-smartpm is unrelated to the landscape-core -> gobject
[17:40] <radix> pre-depends
[17:40] <radix> however, mathiaz and I are in the same office and may have created a shared misunderstanding of ideal solutions to these kinds of problems :)
[17:40] <cjwatson> the reason why Pre-Depends is generally undesirable is that it forces dpkg not to be able to use the usual approach of "unpack everything, configure everything"
[17:41] <cjwatson> but instead partitions the package set being upgraded into multiple unpack/configure chunks
[17:41] <cjwatson> sometimes it is necessary, but should be kept to a minimum and other approaches found where possible
[17:41] <cjwatson> loops involving Pre-Depends are much harder to solve, and sometimes impossible
[17:42] <niemeyer> cjwatson: I'm investigating the issue here with radix and andreas
[17:42] <cjwatson> Pre-Depends/Pre-Depends loops are irresolvable, and Pre-Depends/Conflicts is a pain
[17:42] <cjwatson> niemeyer: right, I'm just giving advice on the packaging metadata
[17:42] <niemeyer> cjwatson: What should be the correct order if there are two packages depending on each other?
[17:42] <cjwatson> niemeyer: undefined
[17:43] <niemeyer> cjwatson: Not saying this is the case, just trying to figure it out
[17:43] <cjwatson> niemeyer: in practice dpkg configures the ones without postinsts first, if any
[17:43] <cjwatson> packages do sometimes do that, and it's OK as long as it doesn't matter at maintainer-script time
[17:43] <niemeyer> cjwatson: Ok, so the Depends unpack ordering is advisory only?
[17:43] <cjwatson> err, you misunderstand
[17:43] <cjwatson> Depends enforces configure ordering
[17:43] <niemeyer> cjwatson: So what's the ordering when there's a loop?
[17:44] <cjwatson> you don't care about unpack unless you have preinsts
[17:44] <cjwatson> like I say: undefined (unless one package is missing a postinst)
[17:44] <niemeyer> cjwatson: Ok, I guess I see
[17:44] <slangasek> cjwatson: Depend doesn't guarantee unpack ordering, no...
[17:44] <cjwatson> and that's an implementation detail of dpkg rather than a policy definition
[17:45] <cjwatson> A Depends: B guarantees B unpacked before A configured
[17:45] <infinity> cjwatson: It's totally defined! *cough*
[17:45] <cjwatson> infinity: undefined by policy :)
[17:45] <infinity> cjwatson: Though I don't recall if it's alphabetical, or order passed to dpkg on the command line...
[17:45] <infinity> (often the same thing, when debootstrap is involved)
[17:46] <niemeyer> cjwatson: Cool, so I believe it's a bug in the ordering of Smart then
[17:46] <cjwatson> niemeyer: I'm curious why you think you're relying on unpack ordering
[17:46] <cjwatson> are you *sure* it's unpack ordering? python packages often do lots of work at the configure stage
[17:46] <niemeyer> cjwatson: For Smart that ordering is advisory but breakable depending on other relations
[17:46] <pitti> mvo: as for your current compiz 1:0.7.7+git20080807-0ubuntu7 upload, it already does start automatically again?
[17:46] <cjwatson> niemeyer: can you give me an example?
[17:46] <niemeyer> cjwatson: I'm not entirely sure yet, no.. I'll join radix and andreas on debugging now
[17:47] <mathiaz> persia: right - I'll ask lool or seb128 about it
[17:47] <mvo> pitti: there is a gnome-control-center upload needed for this. I'm doing that now
[17:47] <niemeyer> cjwatson: I can't yet, but will have a better idea (and perhaps a fix) later today
[17:47] <slangasek> unpack ordering should really never matter except in cases where you do have a preinst, AFAICS
[17:48] <infinity> Even then, it almost never matters, unless your preinst does some pretty vile stuff.
[17:48] <slangasek> s/pretty vile //
[17:48] <cjwatson> in the absence of loops: A Depends: B guarantees A configured after B configured. A Pre-Depends: B guarantees A unpacked after B configured. A Conflicts: B guarantees B removed (not unpacked) when A unpacked. A Breaks: B guarantees B not configured when A unpacked.
[17:48] <mvo> pitti: gnome-c-c uploaded, should be good now (compiz should start again)
[17:49] <infinity> slangasek: Well, most of my preinsts only depend on Essential.
[17:49] <slangasek> infinity: debconf preinst ftw :)
[17:49] <mvo> pitti: actually, the compiz change is probably enough to make it auto-start, but it can't be turned off anymore :) that is the g-c-c upload for
[17:50] <infinity> slangasek: debconf hasn't been around for a decade, I refuse to acknowlege its existence.
[17:50]  * slangasek blinks at bug #268364
[17:50] <pitti> asac: bah, with the new ffox I constantly get the EULA displayed on startup
[17:50] <pitti> mvo: hm, I thought the problem was in gnome-session; I dist-upgraded yesterday, and this morning I got compiz automatically
[17:51] <niemeyer> cjwatson: Thanks for the summary, I'll ensure this is the case
[17:52] <cjwatson> niemeyer: seriously though, if somebody actually tells me what the problem is, I may be able to help rather than just spewing rules :)
[17:53] <niemeyer> cjwatson: That's the output they radix and ahasenack got: https://pastebin.canonical.com/9112/
[17:53] <niemeyer> s/they/that/
[17:54] <ahasenack> cjwatson: the actual error is at line 115 of that pastebin
[17:55] <cjwatson> niemeyer: oh, wow, definitely a Smart bug. It should pass *everything* to dpkg --unpack in one go unless there are packages there that declare Pre-Depends: on something that isn't configured yet.
[17:57] <niemeyer> cjwatson: Cool.  I'm surprised that this didn't break up before.
[17:57] <cjwatson> so am I
[17:58] <niemeyer> cjwatson: Luckily, the ordering logic in Smart is done in about 50 lines with a high-level description
[17:58] <cjwatson> however, you need a correct high-level description before this is an advantage :-)
[17:58] <niemeyer> cjwatson: I'll just check which constraint from your description above is missing, and then post the fix
[17:58] <niemeyer> cjwatson: That's what I was trying to say, but you beat me to it
[17:59] <cjwatson> heh
[17:59] <pitti> tjaalton: screensaver hasn't blown up yet, so this looks good
[17:59] <niemeyer> cjwatson: I've tried to follow the policy document entirely, but I probably misunderstood it
[17:59] <tjaalton> pitti: good :)
[17:59] <cjwatson> niemeyer: you may have misread "installed" as "unpacked"
[18:00] <cjwatson> hmm, no
[18:00] <pitti> tjaalton: bug commented
[18:01] <cjwatson> anything in policy that uses the word "installed" requires careful reading, but it does actually often mean "unpacked"
[18:01] <pitti> tseliot: I'll disconnect my laptop from the dock and reboot, to do the test Bryce asked me to do; back in 5
[18:01] <cjwatson> should probably get that fixed ...
[18:09] <ykphuah> asac: are you around?
[18:13] <niemeyer> cjwatson: I think we found the issue
[18:14] <niemeyer> cjwatson: The new python-smartpm package has a Conflicts relation with the old smartpm-core package
[18:14] <cjwatson> ah, heh, that's a bug in the package
[18:14] <cjwatson> I actually thought about mentioning that when I saw it in NEW
[18:14] <cjwatson> silly me for not doing so
[18:14] <cjwatson> Replaces is quite sufficient
[18:15] <niemeyer> cjwatson: Doesn't that mean that both might be installed at the same time?
[18:15] <niemeyer> cjwatson: Should we use Breaks perhaps?
[18:15] <cjwatson> Replaces is good enough.
[18:15] <cjwatson> it's just a file move
[18:16] <niemeyer> cjwatson: Ok, cool
[18:16] <cjwatson> I think this is still a smart bug, mind
[18:16] <niemeyer> cjwatson: Right, that's what I was going to ask
[18:16] <niemeyer> cjwatson: What's the specification about this situation?
[18:17] <cjwatson> let me just construct a test case and see what apt+dpkg does: I suspect it's: unpack smartpm-core, unpack python-smartpm, configure python-smartpm, configure smartpm-core
[18:17] <cjwatson> I think that's the correct resolution
[18:17] <niemeyer> cjwatson: Due to the Conflicts relation, Smart has put the upgrade before the actual installation of the secondary package
[18:17] <cjwatson> right, but in the process it broke Depends
[18:18] <niemeyer> cjwatson: Could be.. it depends mostly on what's the expected outcome
[18:18] <cjwatson> if it had been Pre-Depends, it ought to have refused entirely
[18:18] <cjwatson> but Depends/Conflicts should be resolvable while satisfying both constraints
[18:18] <niemeyer> cjwatson: Like, is it ok to have the conflicting package present during unpack?
[18:18] <cjwatson> no, but in my proposed resolution you don't
[18:19] <niemeyer> cjwatson: I guess you do
[18:19] <cjwatson> no. the new smartpm-core is unpacked first and that's the only thing being conflicted on.
[18:19] <niemeyer> cjwatson: Or maybe I misunderstood it
[18:19] <pitti> mvo: hm, compiz seems to have forgotten to not start if it is already running in another X? I just get a blank screen now in the guest session
[18:19] <niemeyer> cjwatson: Ah, gotcha
[18:19] <niemeyer> cjwatson: I'll review the ordering for this case then
[18:20] <mvo> pitti: and no fallback to metactiy either?
[18:20] <niemeyer> cjwatson: Thanks a lot for these details
[18:21] <mvo> pitti: compiz works only on the first head that is a know issue
[18:21] <pitti> tjaalton: I commented on bug 267628
[18:21] <niemeyer> We'll have lunch and fix it once we're back.
[18:21] <mvo> pitti: but it should fallback to metactiy
[18:21] <pitti> mvo: well, maybe it does fallback, but since it at first tries to start as compiz, I get the white screen and can't see anything
[18:22] <mvo> pitti: can you give me the output of ~/.xsession-errors in the guest session?
[18:22] <pitti> mvo: while it failed? sure, let me try
[18:25] <pitti> mvo: http://people.ubuntu.com/~pitti/tmp/xsession-errors
[18:26] <pitti> mvo: this is after a full startup of guest, judging by the changing mouse cursor (which is the only thing I see)
[18:27] <mvo> pitti: that is on your intel i945 or 965?
[18:28] <liw> mvo, any progress on system-cleaner? (still not pushing :)
[18:29] <pitti> mvo: 945GM/GMS, 943/940GML Express Integrated Graphics Controller
[18:29] <cjwatson> mvo: he may not be pushing, but I am. :)
[18:29] <mvo> *cough*
[18:29] <mvo> ok
[18:30] <cjwatson> (feature goal, already late)
[18:30] <mvo> I have a look in some minutes
[18:31] <mvo> pitti: thanks, I suspect its a x bug that it pretends to be able to have a second dri capable head. what is the output of glxinfo in the guest
[18:32] <asac> ykphuah: more or less
[18:34] <pitti> mvo: I guess that I can do that with metacity, too?
[18:34] <mvo> pitti: yes that should work
[18:34]  * pitti h4x0rs /usr/bin/compiz again
[18:35] <cjwatson> mvo: thanks
[18:36] <mvo> np
[18:36] <pitti> mvo: http://people.ubuntu.com/~pitti/tmp/glxinfo.primarysession.txt and http://people.ubuntu.com/~pitti/tmp/glxinfo.guest-session.txt
[18:38] <mvo> pitti: hm, that looks like X pretends to be able to deal with that, I ask on #ubuntu-x
[18:38] <pitti> mvo: shall I file a bug about this? with those two files attached?
[18:40] <mvo> pitti: yes, I think that is a good idea, we can then reassign between x and compiz if needed, but for now I think its X :)
[18:41]  * mvo wonders if it is just him or if the name "easystroke" sounds slightly odd
[18:42] <cjwatson> it sounds like it would be best-placed in Soho
[18:48] <mvo> pitti: it looks like tjaalton found the answer already I will add a workaround to the compiz wrapper
[18:48] <pitti> mvo: bug 269509
[18:49] <pitti> tjaalton: you rock, fixing bugs faster than I can even report them :)
[18:49] <tjaalton> pitti: heh :)
[18:49]  * mvo hugs tjaalton
[18:49]  * tjaalton hugs mvo
[18:50] <pitti> mvo, tjaalton: so is it actually a bug in the driver, and mvo's change in compiz is just a workaround? or shall we assing above bug to compiz straight away?
[18:51] <mvo> pitti: I would maintain its a driver bug, but it seems to be easy enough in compiz to work around it
[18:51] <mvo> pitti: so a x and a compiz task is probably the right answer
[18:52] <mvo> I would still be interessted in the answer from X upstream if the glxinfo output shoudl be "DRI: no" or not
[18:52] <pitti> mvo: right, agreed
[18:59] <pitti> doko: ppl binary-NEWed (just libppl-doc, rest was already from libppl), and libppl removed
[19:00] <doko> pitti: binary libppl-c-dev removed as well? and the ppl blacklist for syncs removed?
[19:00] <rom1v> hi
[19:00] <tjaalton> pitti: it's a driver bug, but it's also well known upstream. Needs all the new stuff that's been on the works (and that might not be enough.. not sure)
[19:00] <pitti> doko: yes and yes
[19:01] <doko> thanks
[19:01] <rom1v> is there a way to disable the history (logfile) which logs every task we do on the computer : ~/.recently-used and ~/.recently-used.xbel
[19:01] <JontheEchidna> pitti: about bug 263017, should I just attach a debdiff to the bug or would a jockey-hacker have to make the changes in bzr?
[19:02] <pitti> JontheEchidna: debdiffs are fine; you can of course also create your own branch, fix it there, and propose for merging, but that's quite some effort for a two-line patch :)
[19:02] <pitti> JontheEchidna: please assign the bug to me if you attach a patch; thanks!
[19:03] <JontheEchidna> pitti: ok, I'll attach it in a second
[19:03] <pitti> JontheEchidna: ah, seems easy enough; no debdiff required
[19:03] <JontheEchidna> ok
[19:03] <pitti> JontheEchidna: if you have fun doing them, go ahead, but "missing dependency" is trivial enough
[19:03] <JontheEchidna> see, that's why I asked ;-)
[19:05] <pitti> JontheEchidna: fixed in bzr
[19:05] <JontheEchidna> cool
[19:06] <pitti> JontheEchidna: I'll also adapt the dependency description upstream in README.txt
[19:08] <mathiaz> seb128: lool: I'm currently blocked by bug 121341. What do you think about moving python-gobject to use python-central rather then python-support ?
[19:08] <mvo> liw: do you have a packaging branch for system-cleaner?
[19:09] <pitti> mathiaz, seb128: could then also use DH_PYCENTRAL=nomove if it is enough to work with python 2.5 (and not with 2.4)
[19:09] <liw> mvo, bzr+ssh://bazaar.launchpad.net/%7Esystemcleaner-hackers/systemcleaner/trunk.deb-packaging/
[19:09] <pitti> but for such a central package this might not be an option
[19:12] <pitti> so long, good bye everyone! I'm off next week for the Linux Plumbers Conf
[19:18] <slangasek> mathiaz: ping
[19:18] <mathiaz> slangasek: yop
[19:18] <slangasek> mathiaz: are you set up to be able to test likewise-open?
[19:18] <mathiaz> slangasek: not really :/
[19:19] <slangasek> I'm not, someone's changed around the VMware guests again
[19:19]  * slangasek mumbles 
[19:19] <mathiaz> slangasek: dendrobates may be
[19:19] <slangasek> ok, I can't really check whether likewise-open dtrt with PAM if I can't do a test join
[19:19] <slangasek> nah, he pointed me at you ;)
[19:19] <slangasek> well, for the moment I'll resort to old-fashioned code inspection then
[19:19] <geser> when a package gets added to P-a-S are the debs for the other archs automatically removed on the next upload?
[19:20] <slangasek> geser: no
[19:20] <dendrobates> slangasek: coffedude is on and off line today, due to a family issue, but you might email him the diff.
[19:20] <slangasek> geser: only the buildds look at P-a-s, package removals from the archive have to be done by an archive admin
[19:20] <slangasek> dendrobates: it's his diff that I'm trying to vet :)
[19:20] <slangasek> I haven't even gotten that far yet
[19:21] <geser> slangasek: so a removal request should be filed for the now unsupported archs?
[19:21] <slangasek> geser: yes, please
[19:32] <cjwatson> niemeyer: I've verified that the behaviour of 'dpkg -i' in this case (when given both packages on the command line at once) is as I described (unpack smartpm-core, unpack python-smartpm, configure python-smartpm, configure smartpm-core), so that should be considered canonical
[19:36] <cjwatson> niemeyer: http://people.ubuntu.com/~cjwatson/smartbug.tar.gz contains test cases; run 'make test'
[19:38] <niemeyer> cjwatson: Wow, that's awesome.  Thanks a lot.
[20:01] <geser> kees: re bug 262843: have you tried already 2.6.27-3.4? I'm using it now (for some hours) and didn't see this problem yet with this version
[20:09] <kees> geser: yeah, I pulled it down last night, but haven't rebooted yet (I'm on 1.2 at the moment)
[20:17] <bigBear> why did they choose 2.6.27?
[20:48] <geser> kees: looks like -3.4 has still the problem :(
[21:03] <jlc> Is there a list of boot options some were for the install cd?  Alpha 5 installer crashes on my system, I'll need to reboot and capture the error again, just wondering what options there are for kernel boot
[21:04] <Treenaks> jlc: have you tried the 'photo camera' option? :P
[21:04] <jlc> :)
[21:05] <jlc> i come from a rh/fedora side, and have used ubuntu off/on but dont know all the options yet
[21:05] <kees> geser: feh.  that sucks
[21:06] <jlc> is #ubuntu-testing channel more for users using testing releases?
[21:07] <thom> or #ubuntu+1
[21:07] <jlc> cool, thanks
[21:07] <jlc> I'll just lurk here
[21:26] <lfaraone|ffm> Hey, how do I request that my wikiusername be changed?
[21:30] <cjwatson> it's just your Launchpad username now isn't it?
[21:34] <lfaraone|ffm> cjwatson: I changed my lp name, and that didn't cross over to w.u.o
[21:35] <cjwatson> lfaraone|ffm: hmm, I don't know; try #canonical-sysadmin
[21:49] <psufan> which one of you canucking geniuses decided it would be cut to turn on super anal justify mode in 6.06 lts
[21:49] <psufan> nano
[21:49] <psufan> so that every goddamn time I try to move a line it puts them all together
[21:49] <psufan> what trhe fuck
[21:50] <psufan> this had to have been someone's idea of a joke
[21:50] <norsetto> yawn
[21:52] <psufan> 8.x is way better but 6.06 should have been named
[21:52] <psufan> CRACKY CRACKMONKEY
[21:52] <ScottK-laptop> !ops
[21:53] <ScottK-laptop> PriceChild: Thanks.
[22:13] <pwnguin> anyone know how big ubuntu-minimal is today?
[22:13] <bcurtiswx> My question: bug 269226 has been confirmed by me, but I've found its not a firefox issue but a font issue.  Nobody in the bugs channel knows which package to assign, any advice?
[22:19] <toresbe> I'm still not getting any sensible data off the current loop console line on the PDP-11. I think it might be a wiring issue...
[22:19] <toresbe> oops, ECHAN
[22:21] <_MMA_> bcurtiswx: It's late in alot of the world, and a Friday. It might be slow to get an answer.
[22:22] <bcurtiswx> thankfully its not that important of a bug
[22:22] <bcurtiswx> :-)