[00:00] <psusi> no, it's an issue for internal disks too... see what happens is udev runs dmraid-activate which runs dmraid with the -Z switch to delete the kernel partition table from the underlying physical disks, so that you no longer see an /dev/sda1
[00:01] <TheMuso> right
[00:01] <psusi> and this causes a change event... I'm not sure why but in 9.10 it only makes a change event on the device being processed, so while processing the add for sda, it makes  change only for sda, which it seems udev is smart enough not to recursively process
[00:01] <TheMuso> ah ok
[00:01] <psusi> but in Karmic it causes a change event for sdb as well, which in turn causes dmraid-activate sdb to be called, which changes sda, and so on
[00:02] <psusi> my guess is there was an upstream bug that got fixed in dmraid where it used to only apply the -Z to the device it was passed, and now it applies to all the underlying devices in the set being activated
[00:04] <rurti> seb128: putting it /etc/environment didn't work, i had to back out the changes in terminal mode, I am just going to do the script; should i possibly add this as a bug?
[00:04] <psusi> so do you think just dropping the |change part from the udev rule would do the trick, or are there other changes that should trigger an activate?
[00:04] <seb128> no idea but I guess it's not a bug no
[00:05] <rurti> seb128: design flaw?
[00:05] <seb128> dunno
[00:05] <cjwatson> rurti: /etc/environment is KEY=VALUE as well, not a shell script
[00:05] <seb128> enough for today anyway, good night everybody
[00:07] <rurti> cjwatson: can i use other variables in it like a script, ie: path=$ToolDir/tool1/bin
[00:08] <cjwatson> as I think I said above: no.
[00:10] <TheMuso> psusi: yes sounds sane.
[00:10] <rurti> cjwatson: thanks, for the information.  I will have to think this over a bit, without the scripting variables it means i have to rethink where i put the tools, as well as whom has access.  I suppose i could add a dev group who is the only one with access to them.
[00:11] <cjwatson> there are other less elegant ways to do it, usually involving a single (shell-script-format) file that you source from multiple places, such as .bash_profile and .xsession
[00:13] <rurti> cjwatson: .bash_profile does not exist and i put it in .profile but that does not get run for apps.  As for .xsessions is that run at login?
[00:14] <cjwatson> the fact that .bash_profile does not exist by default does not mean that it isn't read if it exist.  Please read the bash(1) manual page for specific information
[00:15] <cjwatson> .xsession (no trailing s) is sourced as part of standard X session startup
[00:15] <cjwatson> .bash_profile is not sourced until you start an interactive login shell
[00:16] <rurti> cjwatson: is .bash_profile any different from .profile?
[00:16] <cjwatson> read the manual page
[00:16] <cjwatson> it's just bash-specific - you can use either, and they're sourced at around the same place
[00:17] <cjwatson> you may also need to get .bashrc to read the file in question
[00:18] <cjwatson> personally, I have my .bash_profile do little else apart from read .bashrc, and in fact that appears to be how we ship .profile by default these days
[00:18] <rurti> cjwatson: well i know that putting it in .profile does not work. and putting it in .bashrc only works if opening a terminal window.
[00:18] <cjwatson> .profile does work, just not for things that are spawned without going through an interactive login shell!
[00:18] <cjwatson> what I'm telling you is that there is no one place (other than .pam_environment) where you can put this change without having to change multiple files!
[00:19] <cjwatson> this is unfortunate
[00:19] <cjwatson> but in order to cover all the bases, you need to arrange for the variable to be set from both .bashrc and .xsession
[00:19] <cjwatson> (I think I've got the file names right, stuff changes from time to time, adjust to taste)
[00:21] <rurti> cjwatson: so putting the script lines in .xsession and .profile should cover it?  also is there a way to change how an app spawns?
[00:21] <cjwatson> .xsession and .bashrc
[00:21] <rurti> ok
[00:21] <cjwatson> and check that .profile sources .bashrc
[00:22] <cjwatson> "change how an app spawns"?  BTW this is getting well off-topic for #-devel
[00:22] <rurti> cjwatson: yes .profile does source .bashrc i know that.
[00:24] <rurti> cjwatson: its ok ill not bother you anymore ill check into the information you have given me and try some things out then come back to irc if i need more help.
[00:25] <rurti> thanks for the help guys :)
[00:25] <cjwatson> I suggest that #ubuntu would be better for future questions
[00:26] <cjwatson> this isn't really a development topic
[00:27] <rurti> cjwatson: thats where i started, then they sent me to #bash, whom sent me to #ubuntu-desktop, whom sent me here.
[00:27] <cjwatson> grrr
[00:27] <rurti> sorry
[00:27] <cjwatson> boo @ #ubuntu-desktop, that was inappropriate IMO
[00:27] <cjwatson> not your fault if you were told that
[00:28] <rurti> yea unfortunately no one has the answer i need lol, may i add some times gui's are a pain
[00:28] <rurti> thanks anyway for the help
[00:29] <rurti> i will take a look at .session
[00:29] <rurti> sorry .xsession
[00:31] <chrisccoulson> doko - FYI, it seems to be the latest version of llvm which breaks the openjdk-6 build
[00:31] <chrisccoulson> the current version of openjdk-6 in the archive is not built with the latest version of llvm
[00:32] <chrisccoulson> heh, i see you've just uploaded another new version of that too
[00:56] <lamalex> is cowbuilder-dist broken in lucid? I'm getting tons of errors  like cp: cannot create link `/var/cache/pbuilder/build//cow.14578/lib/libnss_files.so.2': Invalid cross-device link
[00:57] <slangasek> cjwatson: syncing pinyin-database 1.2.99-3 from unstable, per the discussion last night (looks like cjohnston struck again :-)
[00:59] <cjwatson> oh yes, thanks
[00:59] <cjwatson> I did actually see it, but forgot
[00:59] <cjwatson> will you also deal with main promotion now that pitti's objection in the MIR bug is resolveD?
[00:59] <cjwatson> resolved
[01:00] <slangasek> cjwatson: how was it resolved? I don't see the resolution mentioned in the bug
[01:01] <cjwatson> the problem was that ibus-pinyin was depending on pinyin-database but not appearing to actually use it, because the dangling symlink it shipped wasn't actually pointing to anything in the pinyin-database package
[01:02] <cjwatson> (there was also some confusion about build-dependencies - from a casual grep it *looked* as though ibus-pinyin was using pinyin-database at build-time, although it wasn't actually)
[01:02] <cjwatson> now, pinyin-database ships the file that's the target of the symlink in ibus-pinyin-db-open-phrase
[01:02] <slangasek> hmm - I understood pitti's objection as "described as a build-dep, not a runtime dep, do we want 10MB more on the dVD"
[01:02] <cjwatson> so the dependency is correct
[01:02] <cjwatson> my understanding was that he didn't want 10mb more on the dvd without this confusion being resolvd
[01:02] <slangasek> oh, no, I see what he's said
[01:03] <cjwatson> *resolved
[01:03] <slangasek> ack, will promote
[01:03] <cjwatson> but I'm happy to wait until tomorrow morning and ask him
[01:03] <cjwatson> there doesn't appear to be much of a compilation step, so if we're short on space then the question needs to become whether we want ibus-pinyin-db-open-phrase or not, rather than whether we want pinyin-database or not, IYSWIM
[01:03] <cjwatson> ibus-pinyin-db-open-phrase is non-functional without pinyin-database
[01:04] <slangasek> right
[01:36] <poolie> superm1: hi, in the tip of usb-creator trunk it still seems to prefer a local cd device to the specified ios
[01:36] <poolie> therefore i think hiding the list would be bad
[01:36] <superm1> poolie, local cd device?
[01:37] <superm1> i didn't realize that's even an option.  i thought it only populated ~/Downloads ?
[01:37] <poolie> it does
[01:37] <poolie> that's the problem in bug 477529 that i was trying to fix
[01:38] <superm1> interesting.
[01:38] <poolie> this little sandisk device pretends to also have a usb cd drive
[01:38] <poolie> containing win32 stuff
[01:39] <poolie> superm1: istm that if --iso is given, we want to absolutely force the iso to be taken from that value
[01:39] <poolie> and avoid this whole messy issue of trying to force that list to have the right value selected
[01:39] <superm1> yes
[01:39] <poolie> superm1: you can probably reproduce this yourself by having a cd mounted when you run the program
[01:40] <superm1> poolie, great.  i'll take a look this week and see if I can
[01:40] <superm1> i'll hold off reverting the GUI to be hidden until I can sort that out
[01:40] <poolie> yeah, my fix is very far from ideal, but at least it makes the error a bit less confusing
[01:40] <poolie> but i had a train to catch
[01:41] <poolie> and just haven't come back to it since then
[02:31] <smoser> slangasek, finally bug 532682 was fixed, which allowed me to try the old upstart.  reverting from 0.6.5-4 ro 0.6.5-3 made me unable to reproduce bug 531494
[03:18] <ScottK> doko: Would you please look at Bug 525547 and let us know what you think?
[06:58] <pitti> Good morning
[07:01] <pitti> cjwatson, slangasek: thanks for resolving the ibus-pinyin-db; if that's the actual runtime data file, it's fine of course; it just was described differently, so I didn't want to spend the space for an useless dependency (which it isn't apparently)
[07:21] <pitti> cjwatson: wrt udisks, yesterday I committed the b-dep change to libparted-2.1-dev to Debian git; do you plan to introduce libparted0 into unstable soon as well?
[07:22] <pitti> (then I can do that in Debian git and get back in sync)
[07:23] <superm1> pitti, i thought it was in debian's NEW right now still
[07:23] <pitti> ah, great
[07:23] <lifeless> NEW seems to be backlogged again
[07:40] <dholbach> good morning
[07:42] <dottedmag> p
[07:42] <dottedmag> -ECHAN
[09:22] <cjwatson> pitti: parted 2.2 (a.k.a. libparted0-dev) is currently in NEW for Debian experimental; I would like to get parted 1.8.8.git.2009.07.19-6 into testing to simplify the upgrade process before uploading 2.2 to unstable, but other than that there are no blockers
[09:22] <cjwatson> pitti: (2.1 is in experimental too, and will never be in unstable ...)
[09:25] <mvo> DktrKranz: hi, I think lp:gdebi is looking good now for a debian upload (and a sync to ubuntu) - to you want to do the upload? or shall I?
[09:25] <siretart`> seb128: who is caring for gst-ffmpeg these days?
[09:26] <seb128> siretart`, slomo
[09:26] <seb128> siretart`, we get in sync from debian
[09:26] <siretart`> seb128: do you know if gst-ffmpeg for lucid is going to use the system or the internal copy of ffmpeg?
[09:26] <seb128> whatever we have now
[09:26] <seb128> I don't expect any other change, we synced yesterday
[09:27] <seb128> usually it's using the system ffmpeg IIRC
[09:27] <seb128> I've not looked to it for a while though
[09:27] <siretart`> seb128: the thing is that upstream is pretty vocal against using our system ffmpeg copy
[09:28] <siretart`> which I can understand to some extend, but updating it is not an option at this point
[09:28] <seb128> siretart`, why?
[09:28] <seb128> why are they vocal about it?
[09:29] <siretart`> bilboed explicitly states using ffmpeg 0.5 is absolutely unsupported with the current gst-ffmpeg
[09:30] <siretart`> I expect many crashes will occur because of that, but that's what time will show
[09:31] <seb128> siretart`, I guess debian will have the same issue
[09:32] <seb128> siretart`, can you try to talk to slomo about it?
[09:34] <siretart`> seb128: sure, if I catch him. although I don't think there is much to discuss
[09:34] <siretart`> the debian package is compiled against 0.5
[09:35] <seb128> siretart`, so you would recommend using the gst-ffmpeg copy?
[09:35] <siretart`> seb128: if you manage to convince the security team to support both versions of ffmpeg, that would be an option
[09:36] <seb128> siretart`, what else is an option?
[09:36] <seb128> pitti, kees: ^
[09:37] <siretart`> move gst-ffmpeg from official repo to an PPA with a ffmpeg 0.6 backport from lucid+1?
[09:37] <siretart`> or live with crashers
[09:38] <seb128> using the copy seems to best option we have there
[09:38] <seb128> having a ppa will not work, most users will never find it
[09:39] <DktrKranz> mvo: I can do it this evening, unless you've got some time to manage it yourself. is version = 0.6.0 fine for you?
[09:39] <mvo> DktrKranz: 0.6.0 is fine yes - thanks
[09:41] <cjwatson> pitti: so can we remove devicekit-disks from lucid yet?
[09:42] <cjwatson> pitti: oh, never mind, I just realised somebody already did :)
[09:42] <DktrKranz> mvo: have you had the chance to see if python-apt 0.8 api is suitable for merging?
[09:43] <mvo> DktrKranz: for gdebi? well, yes and no. we will have to port DebPackages.py back to python-apt, its more featureful and contains fixes that the python-apt version does not have
[09:43] <mvo> that is going to be a bit of work as the python-apt version contains a bunch of formating/variable name changes as well
[09:43] <mvo> once that is done, the rest is trivial
[09:46] <persia> mvo: Have you had a chance to review my python-apt ports stuff for the SRU?
[09:46] <persia> (and do you have any idea why it FTBFS in lucid?)
[09:46] <mvo> persia: sorry, doing that now. i forgot about that
[09:46] <persia> mvo: Thanks.  Be warned that I couldn't build in lucid (older releases work), so there's something else odd there.
[09:47] <persia> mvo: Also, the information isn't strictly correct for warty (but I don't imagine that matters that much).
[09:47]  * persia hasn't dug out the correct information yet
[09:48] <cjwatson> debootstrap should have canonical information
[09:48]  * persia looks at debootstrap
[09:48] <cjwatson> (modulo bugs obviously ...)
[09:54]  * persia is amused by the logic in debootstrap/scripts/ubuntu/gutsy
[09:54] <persia> mvo: Let me update those branches again quickly, now that I have authoritative information
[09:58] <DktrKranz> mvo: ok, let's keep it out for a while then, after all it won't change before {Squeeze,Lucid} + 1
[09:58] <mvo> DktrKranz: yeah, I need to get to it at some point, but its not super urgent IMO
[09:59] <mvo> DktrKranz: uploaded and I file a sync request now
[09:59] <DktrKranz> great!
[09:59] <cjwatson> http://norvig.com/21-days.html # great page for all the people who show up here asking how to learn enough programming to contribute to Ubuntu
[10:00] <persia> mvo: Nevermind.  debootstrap doesn't have the bits that I don't know.
[10:00] <cjwatson> persia: which bits don't you know?
[10:00] <persia> cjwatson: Modern debootstrap (properly) points at old-releases.ubuntu.com for warty/hoary, and dapper debootstrap doesn't seem to know about ports.
[10:01] <persia> cjwatson: I don't know whether ia64 or hppa existed for warty.
[10:01] <cjwatson> persia: they didn't
[10:01] <persia> My previous information is that they did for hoary.  Does that match your understanding?
[10:01] <cjwatson> pretty sure ia64 did; I'll have to check back to remember for hppa
[10:02] <DktrKranz> mvo: I'm going to remove bzr branch on bzr.d.o/collab-maint, just to use a unique location
[10:02] <cjwatson> ubuntu-meta (0.17) hoary; urgency=low
[10:02] <cjwatson>   * Added ia64 support.  No changes to dependencies.
[10:02] <cjwatson>  -- LaMont Jones <lamont@canonical.com>  Sun,  9 Jan 2005 14:45:39 -0700
[10:02] <cjwatson> ubuntu-meta (0.53) breezy; urgency=low
[10:02] <persia> cjwatson: lamont said that ia64 and hppa came at the same time, and thought it was hoary.  No need to check.
[10:02] <cjwatson>   * Add hppa, no dependency changes.
[10:02] <cjwatson>  -- LaMont Jones <lamont@ubuntu.com>  Thu, 30 Jun 2005 23:25:54 -0600
[10:02] <mvo> DktrKranz: ok, fine with me.
[10:02] <persia> cjwatson: Oh, thanks :)
[10:02] <cjwatson> persia: my memory and the ubuntu-meta changelog respectfully disagree with lamont ;-)
[10:03] <persia> And ubuntu-meta ought be authoritative
[10:03]  * persia edits the hint files
[10:03] <persia> (not that I'm expecting anyone to really do upgrades from warty with do-release-upgrade or anything)
[10:04] <cjwatson> hm, apparently there was some hppa support in hoary
[10:04] <cjwatson> I applied a patch from lamont to debian-installer in hoary to add hppa support
[10:04] <persia> Then for safety, I'll assume there may have been stuff on ports.ubuntu.com then.
[10:05] <mvo> the whole ports/old-releases/archive is a bit of a problem for update-manager (and users). I hope we can use something like "mirrors.ubuntu.com" for the next release that does auto detection on this and just brings us to the right place
[10:05] <mvo> there is some support for this in apt for this already
[10:05] <cjwatson> persia: what tool is this?
[10:05] <cjwatson> oh, u-m
[10:06] <persia> cjwatson: python-apt
[10:07] <persia> Oddly, debootstrap claims that powerpc was on archive.ubuntu.com for feisty, but there's a TB ruling that powerpc was on ports for 7.04
[10:07] <persia> I think that's probably a bug in debootstrap (not that it matters much now)
[10:08] <DktrKranz> mvo: some months ago I asked to insert gdebi in blacklist because of difference between Debian and Ubuntu versions. That is no longer true, I'll ask to remove such entry.
[10:08] <cjwatson> persia: the archive didn't catch up with the TB ruling
[10:09] <cjwatson> I checked that one quite carefully :)
[10:09] <persia> cjwatson: Thanks.  I'll put powerpc on archive for feisty then.
[10:10] <cjwatson> persia: ports.ubuntu.com itself wasn't created until October 2005, confusing the issue a bit; I think ia64 and hppa initially lived on people.ubuntu.com, and my mail records indicate that hppa was just a sketch in hoary
[10:11] <DktrKranz> Riddell (or another archive-admin available): mind removing gdebi from sync-blacklist? Current versions are now in sync, thus blacklist is no longer needed.
[10:12] <persia> cjwatson: If ports.ubuntu.com existed in October 2005, then I'm willing to claim that entries in sources.list pointing to ports.ubuntu.com for hppa and ia64 for a hoary install are correct.  Do you see any reason I shouldn't?
[10:13] <cjwatson> I don't think it matters if you add those, so go for it
[10:21] <mvo> DktrKranz: yeah, its no longer true, but I think it was also not done, gdebi in ubuntu/lucid got auto synced
[10:22] <DktrKranz> mvo: that's why I asked to blacklist it after it got autosynced (that's why of the 0.5.9debian2 package currently available in Lucid)
[10:22] <DktrKranz> I figured out only later :(
[10:22] <mvo> DktrKranz: aha, ok :)
[10:23] <mvo> DktrKranz: thanks! we can unblacklist now - I'm pretty happy about the unifcation release
[10:23] <DktrKranz> me too
[10:24] <mvo> I also like "look inside files in the deb" feature that we got recently, also seeing what is done in the postinst so easily is sometimes scary (at least for certain third party debs ;)
[10:25] <DktrKranz> tonight I will have a triage run at outstanding bugs, to see if we can close some
[10:25] <mvo> DktrKranz: great!
[10:25] <mvo> persia: I looked at the diff, looks fine to me. if there is consensus on the exact times when stuff moved/was created I'm happy to upload
[10:26] <persia> mvo: All branches should be updated to reflect powerpc on archive for feisty and no ports for warty.  Please double-check my syntax :)
[10:26] <mvo> persia: just let me know
[10:26] <mvo> persia: ok, I will :)
[10:26] <mvo> persia: will you do the update for this?
[10:26] <persia> mvo: Might take a few minutes for bzr to sync, but they should all be good to upload.
[10:26] <persia> mvo: I'm not a core-dev even though LP thinks I am.
[10:26] <mvo> persia: ok, no worries. I can take the upload (thats the easy bit)
[10:28] <persia> mvo: OK.  Please upload for all releases: I'll chat with the SRU team.  Also, if you have any suggestions for dapper, I'd be glad to hear them :)
[10:28] <ogra> W: Failure while configuring base packages.  This will be attempted 5 times.
[10:28] <ogra> hmm, seems debootstrap is missing something
[10:29] <cjwatson> should be more in the log file it leaves around
[10:29] <ogra> heh, if that wouldnt live inside a vm image i would be able to read it :)
[10:30] <persia> ogra: can't you mount the VM image as a secondary disk in another VM and then mount it as a filesystem to check that?
[10:30] <mvo> persia: ok, I have a look at the dapper problem too
[10:30] <ogra> persia, the prob is that rootstock dies to fast because glib is also out of sync ...
[10:30]  * ogra tries to save the img somewhere
[10:31] <persia> ogra: Ah.  That makes it tricky.  If you can capture the image, it should be easy to use -hdb or something in kvm to dig into it.
[10:31] <ogra> cjwatson, /var/log/bootstrap.log  ?
[10:31]  * ogra got it quick enough
[10:32] <ogra> oh, its actually glib's fault ... i wasnt aware debootstrap pulls that in
[10:32] <cjwatson> plymouth
[10:33] <ogra> well, i gave it back already and its currently building ... so should be fine later today again
[10:33] <ogra> ah, the root of all evil, plymouth :)
[10:34] <persia> Works for some folk, and is even essential for some use cases.
[10:34]  * ogra wonders if he should somehow cat the bootstrap.log into the rootstock log for such cases
[10:38] <ttx> pitti: updated the servlet-api dependencies, you should be able to demote libservlet2.{3,4}-java in a few.
[10:43] <persia> mvo: You figured out the python-apt FTBFS in lucid, or will we plan another upload for that?
[10:47] <lool> Something is adding massive load to my laptop since the latest upgrade
[10:47] <lool> I can't figure out what it is; I see one of my CPU is busy in kernel space
[10:47] <lool> iotop shows nothing (nor top obviously)
[10:48] <soren> If I want to have a python package work with python2.4, do I really have to rebuild it with an explicit b-d on python2.4?
[10:48] <lool> I have a long list of console-kit processes though
[10:48] <lool> soren: You mean only python2.4?
[10:48] <soren> lool: No.
[10:49] <soren> lool: python2.4 in addition to whatever it supports now (which is just 2.6).
[10:49] <lool> soren: problem is that it's not really supported to rebuild modules for python2.4 anymore
[10:49] <soren> lool: The available python versions at build time mandates which of /usr/lib/python* it gets installed to.
[10:50] <lool> soren: in theory you should intersect the supported versions wiht the ones available (which you bdep on)
[10:50] <soren> lool: ..so if I have something that only really works with python2.4, and I want to use twisted with it, I'm kind of screwed, AFAICT.
[10:50] <lool> soren: pyversions shouldn't return 2.4 anymore
[10:50] <lool> soren: Yes
[10:51] <soren> Hm. Ok.
[10:51] <lool> You have to install a local python2.4 and the relevant packages
[10:52] <lool> Well I guess I'll just reboot *sigh*
[10:53]  * soren builds an Intrepid VM to play with python 2.4
[10:53] <soren> lool: Thanks.
[11:09] <awoodland> is it possible to request debian->ubuntu syncs for packages in lucid still if they fix ubuntu bugs?
[11:09] <cjwatson> yes
[11:09] <cjwatson> if they introduce new features, they'll need a feature freeze exception; if they're bug-fixes alone, that's fine
[11:10] <awoodland> I can split them out, I wanted to add a feature but I can do that once the fix has hit testing
[11:11] <persia> awoodland: If you're really confident, it's possible to sync the bugfixes from unstable.
[11:11] <awoodland> it's a pretty trivial change, developed by upstream not me
[11:12] <awoodland> so that probably makes sense. I'll upload the fix only with a reference to the LP bug in the changelog shortly then
[11:18] <mvo> persia: FTBFS> let me check
[11:18] <persia> mvo: Thanks.  I'm stumped.  The prior version FTBFS on rebuild in lucid also.
[11:19] <persia> mvo: The karmic branch builds in karmic though, so I'm convinced it's a change to the build-deps.
[11:19] <mvo> persia: thanks, I think I have a idea about this, I will work on it
[11:19] <persia> mvo: Oh, excellent.  Thanks!
[11:21] <amitk> pitti: I've pushed a bzr branch for pm-utils-powersave-policy (https://code.edge.launchpad.net/~amitk/ubuntu/lucid/pm-utils-powersave-policy/amit). I'm still testing it, but I'd like you to have a look when you have time.
[11:21] <amitk> pitti: I was thinking of uploading it to a PPA to allow for wider testing prior to integration
[11:37] <kermiac> sladen: sorry for the pm. this chan didn't show in whois
[11:48] <lamont> cjwatson: hppa/hoary was outside the datacenter, and lived under people.u.c/~lamont/hppa for quite some time (I noticed it and killed it within the last year)
[11:49] <apw> cjwatson, wondering what the right approach with linux-tools package.  seems it ended up in universe.  as it carries useful but not necessary things i wonder if i should move it to Recommends: ... though that would leave a binary in main with its manuals in universe
[11:49] <lamont> at least I'm pretty sure it was hoary...
[11:50] <cjwatson> apw: any particular reason for Recommends as opposed to explicitly seeding it?  (there might be but I want to make sure you've thought about it)
[11:51] <cjwatson> apw: for example, does it need to be on CDs?  I think probably not
[11:51] <apw> cjwatson, no i'm not sure as to the right approach at all, i suspect it needs to be with linux-image policy wise
[11:52] <apw> no its not needed on a CD, but currently is Depends: from linux-image so causing issues for netboot
[11:52] <cjwatson> so why not just seed it as a supported thing for developers?
[11:52] <cjwatson> e.g. in platform.lucid/supported-kernel-common
[11:52] <cjwatson> linux-doc and linux-source are already there
[11:53] <cjwatson> Depends from linux-image sounds wrong; that means that it MUST be on the CD
[11:53] <cjwatson> I would weaken that to Suggests if I were you
[11:53] <apw> seems completely reasonable to me
[11:53] <cjwatson> I've promoted it to main for now anyway
[11:53] <apw> ok thanks for that
[11:54]  * apw has no idea as to the process for handling seed updates
[11:54] <cjwatson> and I've seeded it explicitly in platform.lucid/supported-kernel-common
[11:54] <apw> ahh i see, waiting a bit ... thanks
[11:54] <cjwatson> core-dev commit access
[11:54] <apw> i'll move it to Suggests: then
[11:54] <cjwatson> (lp:~ubuntu-core-dev/ubuntu-seeds/platform.lucid)
[11:54] <cjwatson> thanks, that should complete it
[12:09] <Riddell> DktrKranz: gdebi removed from sync-blacklist
[12:16] <al-maisan> hello geser, thank you very much for the vim fix!
[12:28] <zubin71> hi, will ubuntu be taking part in gsoc this year?
[12:29] <pitti> cjwatson: thanks for the heads-up; yes, I removed dk-disks on the day when I did the udisks migration :)
[12:29] <pitti> ttx: yay you!
[12:29] <pitti> amitk: thanks, I'll have a look; PPA for wider testing sounds good
[12:40] <DktrKranz> Riddell: thanks
[12:50] <cjwatson> mvo: so I'm currently trying a hardy->lucid upgrade using dselect (yes I know, but I thought it might be amusing ...).  I ran into an interesting loop and wondered if we ought to solve it some other way.  libc6 Depends: findutils (newer than hardy), because old xargs breaks with new libc6; findutils Depends: dpkg (>= 1.15.4) | install-info for the install-info transition; dpkg Pre-Depends: libc6 (>= 2.11), presumably due ...
[12:50] <cjwatson> ... to newer symbols
[12:50] <cjwatson> mvo: are you familiar with this problem?  I was wondering if we could break it at findutils somehow, to simplify things
[12:52] <cjwatson> It can be done if you know what you're doing but it does require --force-depends once.
[12:52] <cjwatson> and apt refuses to perform immediate configuration on libc6
[12:56] <mvo> cjwatson: its showing up at http://people.ubuntu.com/~mvo/automatic-upgrade-testing/current/ since a couple of days, but I have not looked at it in details yet. I can give it some time today and see what can be done, but my gut-feeling is that findutils is the best choice for a fix
[12:57] <cjwatson> I'm very much inclined to just remove that dependency
[12:57] <cjwatson> the policy directive is:
[12:57] <cjwatson>      The `install-info' program maintains a directory of installed info
[12:57] <cjwatson>      documents in `/usr/share/info/dir' for the use of info readers.[1]
[12:57] <cjwatson>      This file must not be included in packages.  Packages containing info
[12:57] <cjwatson>      documents should depend on `dpkg (>= 1.15.4) | install-info' to ensure
[12:57] <cjwatson>      that the directory file is properly rebuilt during partial upgrades
[12:57] <cjwatson>      from Debian 5.0 (lenny) and earlier.
[12:58] <cjwatson> but (a) it's not the end of the world if it isn't and (b) in these upgrades it will be taken care of anyway
[12:58] <cjwatson> findutils.postinst doesn't call install-info itself now - it's done with dpkg triggers
[12:59] <cjwatson> mvo: I think I've convinced myself :-) I'll make that change
[13:00] <mvo> cjwatson: I have no objections :) thanks, I will trigger another upgrade test run once its uploaded to see if its happy
[13:16] <cjwatson> mvo: source uploaded
[13:45] <primes2h> seb128: Hello, who could I address this to, please? bug 535041
[13:48] <seb128> primes2h, hi, why do you ask me?
[13:48] <seb128> primes2h, try asking ccheney or kwwii they are openoffice and artwork maintainers there
[13:53] <primes2h> seb128: Thank you very much. Sorry if I bothered you. :-)
[13:53] <seb128> primes2h, no bothering don't worry
[14:13] <fatal^> hello. is syncing from debian currently frozen?
[14:13] <pitti> fatal^: no, why?
[14:13] <pitti> we got a whole slew of syncs just today
[14:13] <fatal^> could you please sync rygel which has a small but important fix.
[14:14] <SwedeMike> February 11th was "LTSdebianimportfreeze" according to the release schedule, what does that mean?
[14:14] <pitti> it means that we stopped syncing from Debian automatically
[14:14] <SwedeMike> ah
[14:14] <pitti> manual syncs upon explicit request are still handled
[14:14] <SwedeMike> thanks.
[14:14] <fatal^> also, you might want to consider syncing libarchive which brings the much requested ISO9660 joliet extension support.
[14:14] <pitti> fatal^: can you please file a bug about it? (requestsync is handy for this, in ubuntu-dev-tools)
[14:15] <fatal^> I'm not running ubuntu... just trying to give you some hints for packages I maintain in debian.
[14:15] <pitti> fatal^: we are in FF, so the latter might not be approved (but that needs a bug for documentatino/review in any case)
[14:15] <pitti> fatal^: ah, ok; thanks
[14:15] <pitti> rygel looks fine
[14:16] <pitti> fatal^: rygel synced
[14:16] <ogra> fatal^, https://wiki.ubuntu.com/SyncRequestProcess
[14:16] <geser> fatal^: ubuntu-dev-tools is also in Debian
[14:17] <fatal^> ogra: thanks... (but unfortunately I'll probably forget it before next time I consider looking at which version of packages ubuntu is carrying. :P)
[14:17] <ogra> fatal^, for libarchive a feature freeze exception is needed, that requires a bug
[14:33] <ttx> pitti: the ubuntu-server dailies are borken ?
[14:34] <persia> ttx: For image build or image install?  If install, you need the new glib (recently building)
[14:35]  * persia thought the images built, from the logs
[14:35] <ttx> image build: http://cdimage.ubuntu.com/daily/20100309/
[14:35] <cjwatson> no, they failed
[14:35] <cjwatson> should be fixed though
[14:35] <ttx> I mean, http://cdimage.ubuntu.com/ubuntu-server/daily/20100309/
[14:35] <cjwatson> it's just d-i kernel version desync
[14:36] <ttx> cjwatson: OK, I assume it was fixed today ?
[14:36] <persia> Oh, that explains why the architecture I checked appeared to have worked :)
[14:36] <cjwatson> late last night, I probably just missed the server build
[14:36] <ttx> cjwatson: ok, thx !
[14:49] <alkisg> In LTSP, when running `ck-list-sessions` we're getting "active = FALSE" possibly because `ck-launch-session` sets the display-device instead of the x11-display-device. Could someone tell me how to tell ck-launch-session to set x11-display-device?
[15:34] <kees> seb128: I would prefer a single copy of ffmpeg.  :P
[15:37] <primes2h> ccheney: kwwii: Hello, about the new theme - icon set, I see this bug 535041,  bug 535061
[15:51] <nxvl> james_w: ppa's don't get automagic branches, do they?
[15:51] <ccheney> primes2h: ok, if kwwii gets me a new splash screen for it I will update it in the next upload
[15:51] <james_w> nxvl: correct
[15:51] <nxvl> james_w: correct as in they don't or as in they do?
[15:52] <james_w> they do not
[15:52] <primes2h> ccheney: That's nice, what about the icon? It looks a bit weird (and with a low resolution i UNE). :-)
[15:52] <nxvl> ok, thanks
[15:53] <nxvl> james_w: are there plans to make them get it?
[15:53] <james_w> nxvl: no
[15:53] <nxvl> :(
[15:53] <primes2h> ccheney: Have I to report it to kwwii?
[15:54] <primes2h> ccheney: it's even always present on desktop using live cd
[15:57] <ccheney> kwwii: see above about the splash screen for OOo not fitting in with new theme
[15:57] <ccheney> primes2h: i don't think there is an actual package to assign bugs to him with, letting him know is probably enough
[15:58] <kwwii> ccheney: the first thing we can do to improve that is change the color of the progress bar ;)
[15:58] <kwwii> primes2h, ccheney: I'll push this out to my colleagues on the design team
[16:00] <ccheney> kwwii: iirc there is a file that you can modify the placement and color of the bar with
[16:00] <ccheney> i don't remember where/how to do it though
[16:01] <ccheney> i can ask around and see if i can find out
[16:01] <kwwii> ccheney: if you don't know how would I ever find out?
[16:01] <ccheney> :)
[16:01] <ccheney> digging through the source, which would take longer
[16:02] <ccheney> oh sorry misread
[16:02]  * ccheney needs more caffeine
[16:04] <bdrung> pitti: the units policy is finally gone gold?
[16:04] <pitti> bdrung: yes, with two modifications; the original one was too strong to find TB approval
[16:05] <pitti> bdrung: but better start a bit smaller and fix the GUI portions first, but get going
[16:05] <pitti> bdrung: thanks for your persistence, took a while :)
[16:05] <bdrung> pitti: i saw you changes.
[16:06] <bdrung> pitti: great.
[16:07] <bdrung> pitti: we can fix most of the gui portions with bug #369525
[16:07] <pitti> bdrung: right, I remember that one; it's somewhat stuck upstream, but I think we'll go ahead and JFDI it
[16:08] <pitti> bdrung: I put that one on the lucid list now
[16:08] <bdrung> pitti: JFDI?
[16:09] <pitti> bdrung: just f* do it, without getting it upstream first
[16:10] <pitti> bdrung: it might create just the right amount of nudging for them, too :)
[16:10] <bdrung> pitti: and it's small enough for beeing maintained by us ;)
[16:10] <ccheney> kwwii: i think this is the information: http://www.oooninja.com/2008/03/change-remove-splash-screen.html
[16:10] <pitti> that, too; I'm more worried about the behavioural difference, not the patch maintenance
[16:11] <primes2h> kwwii: btw, did you see this too? it looks a bit weird. bug 535061
[16:12] <ccheney> kwwii: and its already in the /etc/openoffice/sofficerc with values you can tweak
[16:12] <kwwii> primes2h: hrm, seems that icon is not at the right size
[16:12] <kwwii> primes2h: but that bug has nothing to do with the ubuntu-mono set
[16:13] <kwwii> ccheney: ok, I will edit that and get back to you
[16:13] <primes2h> kwwii: in fact it has because the HD pic in comes about human theme
[16:13] <primes2h> d/about
[16:14] <primes2h> s/about/from
[16:14] <kwwii> primes2h: right
[16:14] <pitti> bdrung: hah, you missed a "KB" in the description comment :)
[16:14] <pitti> bdrung: (don't worry, I'll fix it when I sponsor)
[16:14] <primes2h> kwwii: it should be updated.
[16:17] <bdrung> pitti: you are right ;)
[16:17] <ev> slangasek: you're a star; thanks for the Kashmir advice
[16:19] <kwwii> primes2h: yes, it should ;)
[16:49] <asac> Riddell: so thats just a helper for the kde dialogs?
[16:50] <asac> Riddell: why isnt that done inside the mozillatree?
[16:50] <asac> e.g. is that also distributed by opensuse etc.?
[16:50] <Riddell> asac: yes it is.  opensuse package it separately so we followed them
[16:51] <asac> Riddell: ok. just curious ... do you see any mid term reason to keep that out of mozilla tree? is it useful for anything else?
[16:52] <Riddell> asac: it's not really useful for anything else I can forsee
[16:52] <Riddell> asac: but mozilla uses autotools and KDE doesn't so that could be fiddly to integrate
[16:53] <asac> approved
[16:57] <Riddell> asac: if you're in a MIR mood bug 533990 is wanting looked at too
[17:00] <debfx> mdeslaur: the 62_tray_icon_size_kde.patch can dropped from the pidgin package since the eggtrayicon isn't used anymore
[17:01] <mdeslaur> debfx: ok, thanks
[17:03] <asac> Riddell: i assume drkonqi could also e used to put that code in long run?
[17:03] <asac> e.g. adding a kubuntu backend etc.
[17:04] <Riddell> asac: I don't follow
[17:04] <Riddell> asac: this app is run by drkonqi
[17:04] <asac> Riddell: right. but why not ship this as part of drkonqi ;)
[17:04] <asac> thats what i wondered about
[17:05] <asac> e.g. kubuntu should be important enough to justify such code
[17:05] <asac> anyway approved.
[17:05] <Riddell> oh I see, yeah we should merge it upstream for the next KDE
[17:05] <asac> commented on that in MIR bug
[17:05] <Riddell> thanks asac
[17:05] <asac> anything else to make KDE happy ;)?
[17:06] <Riddell> asac: I think that's all thanks, until that gcc ARM segfault manages to fix itself
[17:06] <asac> hehe
[17:06] <asac> are there still bad things left? from what i understood most kde things are working now
[17:07] <asac> well at least building. kdeedu is still on our list in main
[17:07] <asac> anything that popped up today?
[17:07] <Riddell> yeah  kdeedu is the issue.  I removed the edu packages from the images so they won't block that but it would be nice to get them back
[17:08] <asac> Riddell: on ftbfs kdeedu seems to have built
[17:08] <asac> http://qa.ubuntuwire.com/ftbfs/
[17:08] <mikebuntu> when I start up my eeePC, I see the ubuntu splash screen then I get a black screen and all I see is the mouse and cursor. I can hit Ctrl+T, then type gdm-restart (even though I can't see anything I'm typing) and then the login screen comes up and everything works... Any ideas?
[17:09] <Riddell> asac: "Finished 21 hours ago " interesting
[17:09] <asac> yeah ;)
[17:09] <Riddell> asac: I wonder if that means kdebindings would build
[17:09] <asac> Riddell: they are building since a few days already
[17:09] <asac> i dont have anything i nmain kde related left from what i see
[17:09] <Riddell> asac: but only because I disabled smoke from kdebindings.  I might try it in the PPA with smoke enabled
[17:10] <awoodland> can someone sync blcr-0.8.2-10 from Debian/Unstable into Lucid please? It fixes an Ubuntu bug http://packages.qa.debian.org/b/blcr/news/20100309T120216Z.html
[17:10] <asac> Riddell: do you have a armel ppa somewhere?
[17:10] <asac> otherwise i can upload to one of mine
[17:10] <Riddell> asac: the canonical-arm-devs one or whatever its called
[17:10] <asac> gimme the .dsc
[17:10] <asac> oh ok
[17:10] <asac> if that works go for it
[17:10] <asac> would be lovely to have a fully working kde on armel ;)
[17:10] <asac> and kde-netbook
[17:11] <Riddell> awoodland: please file a bug and subscribe ubuntu-archive
[17:11] <awoodland> file a bug against ubuntu-archive?
[17:11] <Riddell> ev: did today's ubiquity upload include the fix to the language selection crash?
[17:11] <Riddell> awoodland: file a bug on the package
[17:11] <asac> Riddell: xul 1.9.2 is in NEW in case you do an archive run today still ;)
[17:11] <awoodland> there is a bug on the package
[17:11] <awoodland> that's why I found it :)
[17:11] <Riddell> awoodland: a sync request bug
[17:12] <awoodland> ah ok
[17:12]  * asac takes a break
[17:13] <awoodland> so you mean subscribe ubuntu-archive to the bug?
[17:13] <Riddell> awoodland: that's ok if it's clear to a busy archivev admin that it is a sync request
[17:14] <asac> there probably is a wiki page about how to request a sync
[17:14] <asac> awoodland: https://wiki.ubuntu.com/SyncRequestProcess
[17:17] <awoodland> Thanks (I'm kind of new to doing anything more with Ubuntu development than watching my packages come in from Debian)
[17:19] <jcastro> awoodland: this might be useful to you: https://wiki.ubuntu.com/Ubuntu/ForDebianDevelopers
[17:20] <awoodland> yeah I read that, and I've taken advantage of the time period before "DebianImportFreeze" by putting LP bugs in changelogs
[17:29] <didrocks> kirkland: hey. What is the official way to know for both connected and not connected user those who use an encrypted home? (I want to prevent them to set autologin in gdmsetup)
[17:30] <kirkland> didrocks: boy that would be phenomenal
[17:31] <didrocks> kirkland: should be easy on the gdmsetup side, but first, I have to grab the list. Tired of getting but report and tell to people "reboot in recovery mode… , vim /etc/gdm/custom.conf, urgh :-)"
[17:31] <kirkland> didrocks: right-o
[17:31] <kirkland> didrocks: okay, well, it's easy from the ecryptfs side too, so let's hook it up
[17:31] <Keybuk> pitti: I've discovered something annoying about the fact the Dell Minis need you to press Ctrl-Alt-Fn-F1 to get to a console
[17:31] <kirkland> didrocks: ls -alF /home/.ecryptfs/$USER/.ecryptfs
[17:31] <Keybuk> pitti: ...try it on your D420 ;-)
[17:32] <kirkland> Keybuk: you can change the Fn bit in the BIOS, fyi
[17:32] <kirkland> Keybuk: ie, make the sound controls secondary and the F-keys primary (if that's your gripe)
[17:33] <Keybuk> kirkland: the gripe is more that on the other Dells, that's HIBERNATE! :p
[17:33] <kirkland> Keybuk: doh!  :-)
[17:33] <kirkland> Keybuk: ie, "take my console away from me" rather than "give me a console"
[17:33] <Keybuk> more "take my laptop away from me for a few minutes"
[17:34] <kirkland> didrocks: so if that directory is well-populated (at least has a wrapped-passphrase file), then the user has an encrypted setup
[17:34] <kirkland> didrocks: if the contents of Private.mnt are equal to the user's $HOME, then they have an encrypted home
[17:34] <kirkland> didrocks: note that the contents of Private.mnt can be any directory the user owns
[17:35] <didrocks> kirkland: just tested on two box. awesome, that will be more than easy to fix :)
[17:35] <kirkland> didrocks: which people like pitti set to $HOME/Private, rather than just $HOME
[17:35] <kirkland> didrocks: and for older installs (upgrades), if Private.mnt is omitted, it's assumed to be $HOME/Private
[17:35] <kirkland> didrocks: see also the auto-mount and auto-umount files
[17:35] <didrocks> kirkland: oh ok, so, looking at that file should be good
[17:36] <pitti> Keybuk: I switched off the Fn function key thing in the bios
[17:36] <didrocks> kirkland: auto-mount and auto-umount are empty for me
[17:36] <pitti> Keybuk: hm, ctrl+alt+hibernate? does that work? :-)
[17:36] <kirkland> didrocks: right, it's a presence test
[17:36] <pitti> ah, apparently it does
[17:36] <kirkland> didrocks: the pam_ecryptfs module will skip it's work, if those are missing on login/logout
[17:37] <kirkland> didrocks: cool, i think you're money
[17:37] <kirkland> didrocks: let me know if there's anythign else
[17:37] <Keybuk> pitti: the problem is I need to switch it off in my BRAIN
[17:37] <didrocks> kirkland: I guess I just have to look at Private.mnt for each user, see if this corresponds to their home, and not show them in that case. Does that sound correct?
[17:38] <pitti> Keybuk: just press F2 while you wake up in the morning!
[17:38] <kirkland> didrocks: yup
[17:38] <Keybuk> F2?
[17:38] <kirkland> didrocks: that should do it
[17:39] <didrocks> kirkland: perfect, thanks a lot, good task for tomorrow morning with a fresh brain :)
[17:39] <kirkland> didrocks: if $(cat /home/$USER/.ecryptfs/Private.mnt) = $HOME then don't set autologin!
[17:39] <kirkland> didrocks: good plan
[17:40] <didrocks> kirkland: agreed ;) of course, gdmsetup is in C with glib, but the idea is there ;)
[17:40] <kirkland> right
[17:44]  * ogra lols about pitti'S last comment ... 
[17:45] <ogra> Keybuk, btw, did i show you that one ? http://people.canonical.com/~ogra/celeron-M-lucid-20100308-3.png
[17:46] <ogra> ureadahed seems to not really like if L2 cache is only 64k
[17:47] <Keybuk> ogra: ureadahead --dump | head -2
[17:50] <ogra> /var/lib/ureadahead/pack: created Mo, 08 Mär 2010 12:51:39 +0000 for hdd 8:1
[17:50] <ogra> 19 inode groups, 1878 files, 1933 blocks (102236 kB)
[17:50] <ogra> Keybuk, ^^^
[17:51] <Keybuk> ogra: how much memory does that box have?
[17:51] <ogra> 512
[17:51] <Keybuk> output of "free" ?
[17:51] <ogra> MB
[17:51] <ogra> Mem:        500752     486256      14496          0      44972     138744
[17:51] <Keybuk> can't see any issue there
[17:51] <ogra> ogra@ogra-laptop:~$ cat /proc/cpuinfo |grep cache
[17:51] <ogra> cache size	: 64 KB
[17:51] <ogra> cache_alignment	: 64
[17:51] <Keybuk> are you sure it's not just a stupidly slow drive?
[17:52] <ogra> sure, its not a fast drive additionally
[17:52] <Keybuk> what debugging have you done to ascertain that this is an L2 cache issue?
[17:52] <Keybuk> you seem *very* certain
[17:52] <ogra> Keybuk, no debugging at all ...
[17:52] <Keybuk> could you describe to me what effect the size of the L2 cache would have on the kernel's CFQ algorithms?
[17:53] <ogra> no idea but i have other machines with similar setup that are way faster L2 is the one big difference
[17:53] <Keybuk> have you put the drive from this machine in the others?
[17:53] <ogra> no, its a little laptop and requires some screwdriver work i havent had time for yet to replace the drives
[17:54] <Keybuk> ok
[17:54] <Keybuk> well, I think it's a shit drive
[17:54] <ogra> but you think it clearly is a drive issue ?
[17:54] <ogra> ok
[17:54] <Keybuk> your pack size isn't huge (100MB)
[17:54] <Keybuk> it's smaller than your page cache after you've been running
[17:54] <Keybuk> so it's not an issue with that
[17:54] <Keybuk> the throughput profile shape looks normal
[17:54] <Keybuk> it's just very long
[17:54] <Keybuk> and very low throughput
[17:54] <Keybuk> that to me says shit drive or shit I/O controller
[17:55] <ogra> /dev/sda1:
[17:55] <ogra>  Timing buffered disk reads:   70 MB in  3.07 seconds =  22.77 MB/sec
[17:55] <ogra> yeah, iirc its attached to USB
[17:55] <ogra> internally
[17:55] <Keybuk> *facepalms*
[17:55] <Keybuk> there you go then
[17:55] <Keybuk> you could read from that drive faster with a magnet and a tweed jacket
[17:55] <ogra> seems more and more manufacturers fake SATA on a USB port
[17:57] <ogra> its very intresting though that my ARM board has faster readahead (other speed issues though) with a similar drive setup and throughput
[17:57] <ogra> http://people.canonical.com/~ogra/babbage2-lucid-20100211-3.png
[17:58] <Keybuk> ARM manufacturers would fake SATA using ancient egyptian canal and aqueduct systems if they thought it'd save them a cent on production costs
[17:58] <ogra> it peaks even 10MB less
[17:58] <ogra> Keybuk, note, the first bootchart is a celeron :)
[17:58] <Keybuk> ogra: you're getting much faster seek times
[17:59] <Keybuk> ie. it costs less to skip the bits of the files you don't need
[17:59] <ogra> no arm involved ... and the celeron is actually 1/2 min slower
[18:00] <Keybuk> I don't think the processor is relevant, as I said
[18:00] <Keybuk> it's the I/O controller through to the drive
[18:00] <ogra> right
[18:09] <Keybuk> ogra: another possibility could be syscall time
[18:10] <Keybuk> to read 1,933 blocks, ureadahead has to make 1,933 syscalls
[18:10] <Keybuk> if that round trip and context switch time is high - that'd make it slower
[18:11] <ogra> yeah
[18:16] <Q-FUNK> call me silly, but where does the patch being edited go to when we call 'edit-patch'?  debian/patches ends up empty in the working directory created by edit-patch.
[18:45] <Q-FUNK> ah.  it applies the patches and tries to rebuild them afterwards.  hmm.  ok.  this will take some getting used to.
[19:23] <\sh> guys...did anyone had a look at the problem described in bug #527666 ? creating VGs + LVs + update-initramfs could not be a valid solution for this...
[19:48] <Keybuk> since discovering the gdb "handle" command, my debugging productivity has increased at least 5%!
[21:36] <Caesar> wtf. nano has equal alternatives priority to vim-nox?
[21:37] <Caesar> but vim-gnome has higher
[21:37] <slangasek> for sensible-editor?
[21:37] <Caesar> editor
[21:37]  * slangasek nods
[21:37] <Caesar> When does editor come into play versus sensible-editor?
[21:38] <Caesar> Ah, sensible-editor is that fandangled wrapper
[21:38] <Caesar> editor is the alternative
[21:38] <ccheney> is there a way to keep light-themes from continously resetting button layout, or do I just need to someone rip it out of the install?
[21:39] <slangasek> Caesar: yes; sensible-editor is what you're meant to invoke, it honors $EDITOR as a per-user pref
[21:40] <Caesar> Yeah I note that that uses one's homedir
[21:40] <Caesar> Again, not ideal on a server
[21:40] <slangasek> hmm?
[21:40] <Caesar> We don't automount /home on servers
[21:40] <Caesar> You just don't get a homedir on servers by default
[21:41] <slangasek> ... eew :)
[21:41] <jdong> can't you initialize the environment at the PAM level in that case?
[21:41] <Caesar> Consider the alternative: you're homedir is in Mountain View and you log into a server in Bangalore
[21:41] <slangasek> Caesar: I'm not arguing for automounting, but not having a homedir == eew
[21:42] <Caesar> We seem to survive
[21:42] <slangasek> jdong: why would you do that instead of adjusting the alternative?
[21:42] <Caesar> I guess the path of least resistance here is to adjust the alternative with Puppet
[21:42] <Caesar> But the whole thing makes me sad
[21:42] <jdong> slangasek: the use case where each user has his own editor preference
[21:42] <directhex> that was unpleasant
[21:43] <directhex> total lucid upgrade failure on 2 different issues
[21:43] <jdong> directhex: apport is refusing to process a upowerd assertion failure here...
[21:43] <directhex> jdong, at least your system boots! i was unbootable :'(
[21:45] <slangasek> jdong: so you'd rather write a PAM module to pull in per-user environment settings from $arbitrary_store, instead of allowing for some sort of stub homedir that would provide the settings?
[21:46] <\sh> Caesar: is there any reason why you don't share a centralized home for your users on servers? just out of curiosity
[21:46] <jdong> slangasek: well a stub-home would be nice. I'd like that option too :)
[21:46] <Caesar> \sh: latency
[21:47] <Caesar> I described the situation earlier
[21:47] <Caesar> Basically we have the home directories close to the user, but if the user (usually) an admin has to log into a server that is not local to them, they're not going to want the added latency of their home directory
[21:48] <Caesar> Sorry, that should have been (usually an admin)
[21:49] <Caesar> Gah. Trying to manage alternatives with Puppet is going to suck :-(
[21:50] <\sh> hmmmm...latency can be fixed ;) just put some more 10GbE to the cores and sides ;)
[21:50] <Caesar> \sh: there's this speed of light thing
[21:51] <Caesar> Asia is always going to be about 130ms from the US
[21:51] <directhex> hm, this really hasn't gone smoothly :(
[21:51] <Caesar> 130-210ms for me from my desk to servers in Taiwan and Bangalore for example
[21:52] <\sh> oh well...I
[21:53] <\sh> 'm a child of old analog lines...130ms is nothing ;)
[21:53] <\sh> but depending on the work I need to do remotely...it can be a problem agreed...
[21:54] <\sh> that reminds me, to solve this problem, too
[21:55] <Caesar> Anyway, back to the problem at hand
[21:55] <Caesar> I would argue that if someone has gone to the trouble of installing vim-nox they probably want that to be their editor
[21:55] <Caesar> That logic seems to extend to vim-gnome, but not vim-nox
[21:57] <Caesar> In fact, looking at vim-nox's postinst, it seems kinda crazy how the priority of the alternative varies wildly depending on the package variant installed
[21:58] <Caesar> Maybe the real issue is nano's priority is too high...
[21:59] <Caesar> slangasek: if I do the work for either change (lowering nano's priority or raising vim-nox's) can that make 10.04?
[22:00] <slangasek> "if someone has gone to the trouble of installing vim-nox" - no, because if you apply that reasoning equally to any package that provides the alternative, you wind up with whatever arbitrary editor one of the admins *personally* prefers being used as the default for all users on the system
[22:00] <slangasek> currently I'm reviewing what policy has to say about this particular alternative, if anything
[22:01] <Caesar> ok
[22:02] <slangasek> hmm, no guidance there; I guess it's list archaeology to recover the rationale for the current values, then
[22:02] <Caesar> :-(
[22:02] <Caesar> I bet they were all arrived at independenty
[22:03] <slangasek> personally, I hold the view that nano is a much better value for a "sensible" editor, on the grounds that it has a low learning curve compared to vim (self documenting, etc)
[22:03] <Caesar> I agree, but I disagree about visudo for example using it
[22:03] <slangasek> ah, heh
[22:04] <Caesar> I guess we could set EDITOR in /etc/bashrc
[22:05] <Caesar> That doesn't appear to do the trick though
[22:08] <slangasek> /etc/bashrc, or /etc/bash.bashrc?
[22:08] <Caesar> I just tried setting the environment variable and then running visudo
[22:08] <slangasek> and it wasn't honored?
[22:08] <Caesar> Simulating having added it to /etc/whatever it is
[22:08] <Caesar> No it was not
[22:09] <Caesar> sudo liking to strip environment variables and all
[22:09] <Caesar> We have "Defaults env_reset,always_set_home" in our sudoers file
[22:09] <slangasek> heh, ironic
[22:09] <Caesar> I might be able to use env_keep though
[22:15] <Caesar> Woot
[22:15] <Caesar> That seems to work
[22:15] <cjwatson> somebody at some point wrote an extensive justification of all the editor alternative priorities
[22:16] <cjwatson> I distinctly remember reading it about five years ago
[22:16] <Caesar> I have a workaround that doesn't require me to write gobs of Ruby to try and manage alternatives properly with Puppet
[22:16] <cjwatson> Steve Greenland maybe?
[22:17] <cjwatson> the modern numbers were certainly not all arrived at independently - somebody sat down and thrashed out a list of rules
[22:17] <Caesar> I just find it weird that vim-nox and nano have the same priority, but vim-gnome is higher
[22:17] <cjwatson> there's a bit of a danger of hard cases making bad law
[22:18] <cjwatson> better to find the ruleset, tweak it if necessary, and get a global view of what that would mean for all the editors
[22:18] <Caesar> I've found something on -policy from 2000 from Steve Greenland
[22:18] <cjwatson> that might be it ...
[22:18] <cjwatson> at least that sounds like it'll be what our current numbers evolved from
[22:19]  * Caesar goes and reads the thread
[22:21] <Caesar> Heh. 1997
[22:21] <Caesar> http://lists.debian.org/debian-policy/2000/06/msg00122.html
[23:37] <cousteau> is there a place to submit hand-drawn ideas of an interface?
[23:38] <cousteau> I've been playing with a small idea I had for the netbook edition and I think it could be interesting
[23:40] <cousteau> don't know much about programming, I would just do it if I knew
[23:45] <cousteau> maybe I just post it on Ubuntu Brainstorm, but I don't feel like it's the right place for these kind of things
[23:45] <vorian> cousteau: you can use a "whiteboard" on launchpad.net
[23:46] <vorian> start a project page, and recruit developers who may also share an intrest in your idea
[23:47] <cousteau> well, I don't think it might require quite a big development, it's more a look for the UNE launcher
[23:48] <vorian> cousteau: there are many projects on lanchpad that aren't "big"
[23:48] <vorian> it's just a place to develop an idea, track progress and bugs
[23:49] <cousteau> it's an interface that could be also controlled wit the keyboard, in case you don't have a tablet pc
[23:49] <wgrant> cjwatson: Argh, that custom upload breakage is due to a last-minute change requested by the reviewer :(
[23:53] <vorian> cousteau: sound interesting, gtk or qt?
[23:54] <cousteau> that's the problem, I've no idea about programming... my idea was to modify the current launcher
[23:54] <vorian> in gnome or kde?
[23:55] <cousteau> gtk, I guess...
[23:55] <cousteau> well, the current one is done in gtk, right?
[23:55] <vorian> in gnome, yes
[23:55] <vorian> i suppose this is ubuntu-devel
[23:56] <cousteau> http://img214.imageshack.us/img214/5690/ubuntunetbooklauncher2.png
[23:57] <cousteau> the idea was to control the upper tabs with the F-keys and escape, the app buttons with 1-7, Q-U, A-J and Z-M
[23:57] <vorian> ah
[23:57] <cousteau> and space bar to give focus to the "Search" bar
[23:59] <cousteau> which would be used to filter apps, files, do internet searches and open web pages, much like gnome-do or gnome launcher