[00:00] <cjwatson> jibel: also I backported from git - I didn't apply a patch from the bug report
[00:00] <cjwatson> jibel: so I would assume that Guillem would not have committed to git unless he thought it was OK
[00:02] <jibel> see last comment on the upstream report.
[00:02] <jibel> I had no news from him since then.
[00:02] <cjwatson> jibel: see git.
[00:02] <cjwatson> http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=62668eb422853854976560949f95a5afcc6a8677
[00:02] <jibel> I'll test the latest git
[00:02] <cjwatson> thanks
[00:03] <cjwatson> you could test http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/dpkg/lucid/ too if you like ...
[00:03] <cjwatson> (er, in shorter form, lp:ubuntu/dpkg)
[00:06] <jibel> cjwatson, ok, I'll run my use case and let you know about the results. thanks
[00:06] <jibel> s/case/cases
[00:08] <cjwatson> I test-built and test-double-installed it, but didn't do performance testing
[00:12] <jibel> cjwatson, I test install/upgrade/removal/purge followed by a crash and check if all the files are there and in good shape
[00:12] <jibel> cjwatson, and then I'll check the performance.
[00:33] <psusi> is there anyone who can give me some tips on debugging what appears to be an infinite udev loop?  lucid alpha 3 hangs during boot for me with dmraid enabled and when I run udevadm monitor from the busybox after it times out, it appears to be processing infinite change events from sda and sdb
[00:51] <psusi> I guess what I need is to see exactly what udev is attempting to do to process the events, and exactly what the events are... udevadm monitor just mentions they are change events... I need more details... any ideas on how to get some?
[01:38] <jibel> cjwatson, the latest git does not work.
[01:38] <jibel> cjwatson, There is a missing fsync on the dpkg database directory and the status file is not the right one after a crash.
[01:38] <jibel> I'll report to upstream.
[03:05] <psusi> is there anyone who can give me some tips on debugging what appears to be an infinite udev loop?  lucid alpha 3 hangs during boot for me with dmraid enabled and when I run udevadm monitor from the busybox after it times out, it appears to be processing infinite change events from sda and sdb
[03:08] <persia> psusi: I'm 90% sure you want to ask that question between 10:00 and 17:00 UTC.  Someone might swing by, or read backscroll, but repetitions at this time of day aren't likely to find that many new readers.
[03:15] <psusi> persia, yea I figured... the usual 2-3 guys working on dmraid are euro tz and don't appear to be active atm...
[03:17] <psusi> it's frustrating that I have an idea of what's wrong but do not know where to proceed from here... I can't see any changes done to the dmraid udev rules or initrd scripts since it worked yet the new version definitely hangs up on it...
[04:54] <lifeless> whats the new magic to do patch system abstraction
[05:01] <persia> lifeless: edit-patch or format:3.0
[05:02] <lifeless> uhm, must be neewer dev-tools.Thanks
[05:03] <persia> just the most recent upload.
[06:05] <emgent> FYI, http://www.backtrack.it/~emgent/stuff/facebook_USA_intelligence_guide.pdf
[06:07] <persia> emgent: Please don't post stuff which potentially violates the content to read, even if it is interesting.
[06:17] <alkisg> cjwatson: could you please excuse a direct question about update-binfmts? `chroot "$ROOT" mount -t proc proc /proc  && chroot "$ROOT" update-binfmts --import wine && umount "$ROOT/proc"` ==> this complains about $ROOT/proc being in use.
[06:17] <alkisg> So I'd like to prevent update-binfmts from executing `if (system ('/bin/mount', '-t', 'binfmt_misc',  '-o', 'nodev,noexec,nosuid', 'binfmt_misc', $procdir))`
[06:17] <alkisg> Is there any way to do that (or any other way to cleanly umount $CHROOT/proc)?
[06:23] <micahg> pitti: is the retracer working?
[06:27] <alkisg> cjwatson: If I try to divert `mount` and put `true` in its place, I'm getting "update-binfmts: warning: binfmt_misc initialized, but /proc/sys/fs/binfmt_misc/register missing! Giving up.". So I haven't found _any_ way at all to use update-binfmts in a chroot...
[06:28] <dholbach> good morning
[06:51] <alkisg> I've submitted my problem as a bug (or should I file it as a question instead?): https://bugs.launchpad.net/ubuntu/+source/binfmt-support/+bug/534211
[07:44] <pitti> Good morning
[07:46] <RAOF> Good morning pitti
[07:46] <pitti> hey RAOF, how are you?
[07:48] <RAOF> Slightly frazzled.  I seem to be leaking memory in f-spot, file-backed undo shouldn't impact performance so badly, and I haven't moved around much today.
[07:48] <lifeless> RAOF: walk to the shops and back
[07:48] <lifeless> gets the blood moving. good for you
[07:49] <RAOF> lifeless: My running shoes are already on...
[07:54] <\sh> mahlzeit
[08:44] <lifeless> seb128: https://code.edge.launchpad.net/~lifeless/ubuntu/lucid/glib2.0/subunit/+merge/20879
[08:48] <seb128> hi
[08:48] <seb128> will look at that later, could you open a bug about it?
[08:56] <lifeless> seb128: there's an upstream bug
[08:56] <lifeless> seb128: or do you mean an ubuntu one, just to track it ?
[08:56]  * lifeless thinks merge proposals shouldn't also need bugs; its redundant
[09:00] <seb128> we don't track merge proposal so it's just going to be ignored the current way
[09:00] <pitti> they are on the sponsoring queue righht now
[09:00] <seb128> our current workflow is designed around bug reports and sponsoring
[09:00] <seb128> pitti, well I don't track that either atm, ETOOMUCH
[09:00] <pitti> but there are so many, that they get lost in the crowd
[09:00] <seb128> but if somebody else do good
[09:00] <pitti> seb128: *nod*
[09:01] <seb128> I'm just telling that you of having a bug it will fell of my radar
[09:01] <seb128> but if it's coming from upstream no need to bother about it
[09:01] <seb128> new tarballs are due today
[09:01] <persia> seb128: Have you looked at dholbach's sponsoring overview page?  Does that not work for you?  It's supposed to simplify stuff.
[09:01] <seb128> persia, I did, I'm just so overloaded with tasks that I've no time to look at sponsoring recently
[09:02] <lifeless> seb128: they are putting it *after* the new release.
[09:02] <seb128> why?
[09:02] <lifeless> dunno
[09:02] <lifeless> 'Looks like an ok addition to me, but at this point, it should wait until we get
[09:02] <seb128> in which case do we want it in lucid if upstream thinks it's not suitable for the current serie?
[09:02] <lifeless> 2.24 out.'
[09:02] <persia> seb128: OK.  When you have a chance, please file bugs, as making your life easy is important.
[09:02] <lifeless> seb128: I think we do
[09:03] <lifeless> seb128: because it lets the dx stuff - dbusmenu etc - have their tests introspected by hudson
[09:03] <seb128> persia, will do, one issue right now is the number of random bzr junks listed there and finding items revelant to you or your team too
[09:03] <lifeless> njpatel: ^ look up for the merge proposal
[09:03] <seb128> shrug
[09:03] <seb128> open a bug with a rational
[09:03] <lifeless> seb128: doing so
[09:03] <seb128> so we can discuss ffe there
[09:03] <njpatel> oh, seb128's here! morning dude :)
[09:04] <seb128> hey njpatel
[09:04] <persia> seb128: OK.  Thanks.  The "finding relevant stuff" one is something that's widely important.  I haven't investigated the bzr branches yet.  I'll see if I can understand the state.
[09:05] <al-maisan> Is there any particular reason why the most recent vim version in lucid was compiled w/o python support?
[09:08] <persia> al-maisan: The latest upload was supposed to be a no-changes rebuild.  Check the build-log (I'm sure it wasn't intentional)
[09:08]  * al-maisan looks at the build log
[09:09] <al-maisan> In any case, it breaks plugins like vim-pyflakes and I guess quite a few Ubuntu users would be using vim along with python
[09:09] <persia> al-maisan: Please fix :)
[09:10] <persia> (although I think geser was also doing some vim work: check the sponsors queue)
[09:10] <al-maisan> persia: let me have a look first, maybe something is in the pipeline already.
[09:14] <dholbach> persia: james_w has landed a fix in LP that will remove the irrelevant branches
[09:14] <geser> al-maisan: my vim merge awaiting sponsoring fixes this problem
[09:14]  * dholbach really goes out now
[09:14] <persia> dholbach: Cool.  Thanks for pulling that off my TODO list :)
[09:14] <al-maisan> geser: great!
[09:15]  * al-maisan takes a look at vim-nox (a separate package with built-in python support but no gui)
[09:16] <geser> al-maisan: the problem is that vim uses MODLIBS from python (which should be only used by python itself) and tries to link with -lssl (and libopenssl-dev is not installed). all vim flavours are affected
[09:17] <al-maisan> geser: ah, I see. Thanks for the explanation.
[09:20] <geser> al-maisan: http://bazaar.launchpad.net/~geser/ubuntu/lucid/vim/merge-7.2.330-1/revision/55 if you want to cherry-pick from my merge
[09:20] <al-maisan> geser: thanks!
[09:59] <pitti> Riddell: ok to remove polkit-qt from lucid? no rdepends at all, and superseded by polkit-qt-1
[10:01] <lifeless> seb128: bug filed - bug 534257
[10:01] <seb128> thank you
[10:13] <cjwatson> alkisg: the contract for update-binfmts --import is that the new format ends up enabled in the kernel at the end of it; I'm not sure how to satisfy that contract withoutmounting binfmt_misc
[10:14] <alkisg> cjwatson: could I just divert update-binfmts to work around it?
[10:14] <cjwatson> alkisg: you could umount /proc/sys/fs/binfmt_misc afterwards
[10:14] <alkisg> I think I tried that but it didn't work, /me looks again...
[10:14] <cjwatson> don't see why it shouldn't
[10:17] <alkisg> cjwatson: worked fine, thanks a lot. I'll convert the bug into a question :)
[10:18] <cjwatson> uh
[10:18] <cjwatson> just 'cos there's a workaround doesn't necessarily mean that it isn't a bug
[10:18] <cjwatson> of some kind
[10:18] <alkisg> cjwatson: ah, should I leave it open then?
[10:18] <alkisg> Ok, I'll comment about the workaround there and leave it open.
[10:19] <cjwatson> I've commented
[10:20] <cjwatson> we could for example alleviate the unmounting problem by automatically unmounting after an import if it wasn't mounted before
[10:20] <cjwatson> but leaving it mounted on normal init script startup
[10:20] <alkisg> Yeah, that sounds good
[10:20] <alkisg> Another way could be to check for an environment variable
[10:21] <alkisg> E.g. "IN_CHROOT=True" or something...
[10:25] <cjwatson> alkisg: I don't want to require an environment variable to work "properly", whatever properly might be
[10:25] <cjwatson> particularly not a non-standard one that might end up varying between programs
[10:26] <cjwatson> IN_CHROOT=True RUNNING_IN_CHROOT=true CHROOT_SAFE=1 ARGH=foo
[10:26] <alkisg> Sure, it would be a hack, not a proper solution.
[10:27] <cjwatson> I won't add that
[10:27] <cjwatson> there are certainly better ways
[10:28]  * ogra thinks if linux containers would be easier to use that would solve a lot chroot /proc probs :)
[10:28] <cjwatson> the kernel should just do the right thing by default
[10:28] <ogra> or that
[10:28] <cjwatson> it shouldn't require special action from userspace
[10:28] <mok0> Why am I getting 2 popup notifications? It really bugs me
[10:29] <alkisg> Linux containers would be a fine way to create/maintain ltsp chroots, but it would require a lot of rewriting. :-/
[10:29] <ogra> alkisg, yeah, thats my complaint
[10:30] <ogra> lxc shoudl *just work* without extra setup being needed
[10:30] <ogra> imagine: lxc-mount proc -t proc /proc :)
[10:30] <ogra> and it just vanishing if you exit the chroot
[10:34] <mok0> Ah, I have 2 panels on top of each other
[10:34] <Riddell> pitti: yes polkit-qt can go thanks
[10:39] <ara> soren, hello
[10:39] <soren> ara: Hey.
[10:41] <slacker_nl> mvo: ping
[10:42] <mvo> hello slacker_nl
[10:43] <slacker_nl> mvo: hi, i send you an e-mail yesterday about update-manager
[10:43] <slacker_nl> mvo: i've also added a -V option to do-release upgrade, do I need to create a new bug to submit the patch, just mail it to you?
[10:44] <mvo> slacker_nl: thanks, the patch looks fine, I will apply it (the -c one)
[10:44] <mvo> slacker_nl: best is either to submit a bzr branch or mail me
[10:45] <mvo> slacker_nl: I'm usually slow with the bugreports (unfortunately :(
[10:45] <slacker_nl> mvo: i don't agree with the last thing, i've seen your quick responses ;). I'll mail you the patch for -V
[10:46] <mvo> slacker_nl: cool, thanks!
[10:46] <mvo> slacker_nl: for patches and the like you can also always ping me on irc :)
[10:46] <slacker_nl> mvo: cool
[10:47] <slacker_nl> last question, manpages, I know I read the bug report with missing manpages, and now it seems you have manpages already, do you still need docbook manpages (started on it anyways, for the heck of it)
[10:50] <slacker_nl> mvo: ^^
[10:50] <mvo> slacker_nl: docbook is nice becasue it makes translations of the manpage easier, but because we are releatively late in the cycle I think its not critical to convert it now
[10:50] <mvo> in the longer run using a xml format like docbook is nice, maybe you can get in touch with the ubuntu documentation team?
[10:51] <slacker_nl> mvo: I will, I'll keep working on them, submit them, you decide when it will hit the shops :)
[10:52] <mvo> slacker_nl: heh :) ok, cool! many thanks for working on this (and the previous patches)
[10:52] <slacker_nl> np, glad to help!
[10:56] <cjwatson> lidaobing: I'm trying to resolve bug 530178.  ibus-pinyin-db-open-phrase currently (a) ships a dangling open-phrase.db symlink and (b) depends on a version of pinyin-database that's not in Debian yet.  Did you by any chance just forget to upload a newer version of pinyin-database that ships the main.db file in unpacked form, or is something else going on?
[11:00] <lidaobing> cjwatson, wait a minute
[11:08] <lidaobing> cjwatson, bug confirmed, I'll fix it ASAP
[11:08] <lidaobing> cjohnston, thanks for your information
[11:11] <cjwatson> lidaobing: cool, give me a shout and I'll pull the fix into lucid - I want to unbreak our DVD builds :)
[11:11] <lidaobing> cjwatson, ok
[11:14] <pitti> Riddell: do you think we should aim to drop Qt3 from lucid main?
[11:16] <lidaobing> cjohnston, I have uploaded the new version, but you still need wait some time before it is ready.
[11:17] <Riddell> pitti: it would be nice, let's see what's still in rdepends
[11:17] <pitti> Riddell: I listed them on https://wiki.ubuntu.com/Specs/Lucid/DuplicatedPackages
[11:17] <pitti> Riddell: many are supposedly just bindings (avahi, poppler, etc.)
[11:18] <pitti> Riddell: e. g. libavahi-qt3-1 is not used by anything in main, just from the old kdelibs4c2a
[11:18] <Riddell> pitti: lsb-desktop and scribus are the tricky areas I'd think
[11:18] <pitti> Riddell: cases like these (source in main, binary which could go to universe) the resolution is a little tricky, though
[11:19] <pitti> Riddell: since you would need the Qt3 b-dep in main if you want to build avahi-qt3 at all
[11:19] <pitti> Riddell: oh, lsb still requires Qt3?
[11:20] <Riddell> yes, it's part of the standard (LSB seems to be unmaintained as far as I can tell)
[11:20] <pitti> well, it's maintained, but I guess they are slow to catch up
[11:21] <pitti> Riddell: lsb-dekstop depends on lsb-qt4, though
[11:21] <pitti> Riddell: where do you see the lsb qt3 rdep?
[11:22] <Riddell> it Provides lsb-qt4, it depends on libqt3-mt and libqt4-gui
[11:22] <pitti> that sounds wrong
[11:26] <Riddell> why?  qt3 and qt4 are both part of LSB
[11:26] <pitti> in the same version? (4.0)
[11:27] <Riddell> I believe so yes
[11:27] <Riddell> although I can't actually find it online to confirm, but I'm sure we looked at it last UDS
[11:29] <Riddell> yes http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Desktop-generic/LSB-Desktop-generic/tocqt.html and http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Desktop-generic/LSB-Desktop-generic/tocqt3.html
[11:30] <mvo> what is the kernelcommandline to disable frambuffer loading these days? it seems like nofb is not honored in current lucid and something swtich video modes (plymouth is already removed)
[11:32] <Riddell> mvo: nomodeset ?
[11:34] <mvo> Riddell: thanks, that was the one
[11:39] <seb128> slangasek, sorry about the over reassigning to plymouth, I just tried to cut through the some hundred bug emails from the weekend and 90% of the gdm bugs we get atm are plytmouth issues
[11:39] <seb128> ie people getting a text vt with a mouse cursor
[11:39] <seb128> or people having gdm crash on enter
[11:44] <amitk> Keybuk: cjwatson: should I have to update initramfs if I add a new disk to my Lucid server setup that was LVM at install?
[11:44] <amitk> I see the new bootsplash with "Waiting for /home [SM]"
[11:45] <cjwatson> I'm not sure.  Theoretically you probably ought not to have to, but there might be bugs ...
[11:47] <\sh> amitk: the same issue I had with newly created LVM devices during boot up in lucid server...
[11:47] <chrisccoulson> does anybody know if doko is likely to be around today?
[11:47] <amitk> cjwatson: the init goes by too quickly to tell me what the real problem is (in recovery mode) and break=init doesn't hit the problem. Any other ways to store the messageS?
[11:47] <amitk> \sh: how did you solve it?
[11:48] <amitk> AFAICT the only thing I did to get it "working" was update-initramfs
[11:48] <\sh> amitk: I didn't .. I removed the lvm devices (I was lucky to not have /home or whatever important on it)
[11:48] <\sh> amitk: and asked here...but nobody had problems at this time...
[11:52] <\sh> amitk: what I did was creating a new volume group on /dev/cciss/c0d0p9 + adding some logica volumes, adding them (xfs fs) to fstab and hit reboot...machine came up and was "waiting...."
[11:54] <amitk> \sh: sounds like what I did. Added a new VG, some LVs, formatted them and added them to /etc/fstab with the right /dev/mapper/foo paths
[11:54] <\sh> amitk: well I used /dev/<vg identifier>/<lv identifier> same thing....
[11:55] <\sh> amitk: funny part, I did a reinstall, d-i partitioner got the vg device and failed somehow...I didn't check the logfiles (my bad) because I had no time...needed to bring the machine up and running
[11:56] <\sh> ah it failed installing grub at the end of reinstall...neither adding (hd0) manually helped here
[12:16]  * pitti yays the "upgrade branch" button in LP
[12:36] <nicknewbie> http://pastie.org/859350 -- This is a multiwan script I'm working on, based on the info on this page http://lartc.org/howto/lartc.rpdb.multiple-links.html -- I'm trying to take these instructions, and turn them into a script that can just be edited with the right variables to give multiwan setup. I think it would be good for the community, but I do need some help, can someone take a quick look?
[12:43] <apw> TheMuso, just a heads up we have a new kernel abi
[12:48] <pedro_> pitti, hello! may you please have a look into bug 532924 later?
[13:19] <pitti> hey pedro_
[13:20] <pitti> pedro_: argh timing -- I just did a tzdata update for all stables yesterday
[13:20] <pitti> pedro_: sure, I'll look at it; I'll contact upstream first, to coordinate a patch
[13:20] <pedro_> pitti, thanks a lot!
[13:21] <pitti> pedro_: ah, upstream is aware -- http://article.gmane.org/gmane.comp.time.tz/3124
[13:22] <pedro_> \o/ awesome
[13:22] <nicknewbie> http://pastie.org/859350 -- This is a multiwan bash script I'm working on, based on the info on this page http://lartc.org/howto/lartc.rpdb.multiple-links.html -- I'm trying to take these instructions, and turn them into a script that can just be edited with the right variables to give multiwan setup. I think it would be good for the community, but I do need some help, can someone take a quick look? #mwan-script
[13:22] <nicknewbie> OH??!
[13:23] <jarnos>  My remote control stopped working, after I upgraded to 9.10. I hope my remote control (= vlsystem mplay mini) works in 10.4 again.
[13:23] <nicknewbie> Is this channel for people developing ubuntu, or developing ON ubuntu!?
[13:23] <asac> nicknewbie: the first
[13:24] <jarnos> Also it would be nice, if my tv-tuner would work in 10.4: http://ubuntuforums.org/showthread.php?t=1420878
[13:26] <jdstrand> ScottK: please see my email to you and cemc and also the different bug #533423 regarding the recent clamav update
[13:28] <nicknewbie> asac, Oh right! that would explain why a lof of questions don't get answered!
[13:29] <nicknewbie> because they are not the right ones. -- Guys, I'll go track down the right room!
[13:30] <asac> ack
[13:36] <persia> For the reference of anyone answering questions like nicknewbie's, there's the shiny new #ubuntu-app-deve;
[13:36] <persia> Err, #ubuntu-app-devel
[13:40] <asac> gtk
[13:40] <asac> maybe we hsould include that in the /topic part that deals with this?
[13:40] <asac> persia: ?
[13:40] <persia> I did a few weeks back :)
[13:40] <asac> hmm
[13:40] <asac> hehe
[13:41] <asac> ok Development of Ubuntu (not support, not app development)
[13:41] <asac> made me stop reading
[13:41] <persia> RIght before the pointers for support & app development :)
[13:42] <pitti> Riddell: kdeedu currently b-deps on libreadline5-dev, but should b-dep on libreadline-dev (to build against libreadline6); I can't commit to the branch; want me to upload and propose a merge, or do you want to "just do" it?
[13:43] <Riddell> pitti: I can do it
[13:43] <pitti> Riddell: cheers
[13:44] <pitti> Riddell: want a bug for it?
[13:44] <Riddell> pitti: no thanks
[13:44]  * pitti uploads transitions for the other 5ish packages
[13:47] <pitti> robbiew_: can you please take a look at/approve https://blueprints.edge.launchpad.net/ubuntu/+spec/lucid-duplicated-packages?
[13:52] <mdeslaur> seb128: I've built test packages that backport GtkStatusIcon support into the liferea and pidgin versions we have in Lucid in order to fix the tray icons not being transparent with the new themes. (see bugs 529375 and 191980)
[13:52] <mdeslaur> sorry, bug 101980
[13:52] <mdeslaur> seb128: what would you think about this going into lucid?
[13:53] <seb128> mdeslaur, would be nice to have indeed
[13:53] <seb128> mdeslaur, feel free to upload
[13:54] <mdeslaur> cool, thanks seb128
[13:56] <pitti> Riddell: thanks; I did the other uploads, so another duplicate library bites the dust \o/
[13:57] <sebner> pitti: something interesting; 2 days ago I attached my external harddrive and nothing happened (as I told you once) then I unplugged it, started ubuntu-bug storage, plugged it in again and it worked ..
[13:59] <Riddell> pitti: awooga
[13:59] <pitti> sebner: I sometimes get a similar effect as well, I'll debug that on my devices here
[13:59] <pitti> Riddell: saves you a whopping 147 kB :)
[14:00] <sebner> pitti: cool, just wanted to let you know :)
[14:00] <amitk> cjwatson: how do feel about turning on dpms on all virtual consoles (/etc/kbd/config)?
[14:03] <mdeslaur> pitti, seb128: I get that also with my kindle
[14:03] <pitti> mdeslaur: same for my sony ebook
[14:03] <cjwatson> amitk: no opinion
[14:04]  * pitti thinks mdeslaur meant sebner, not seb128
[14:04] <seb128> right
[14:04] <mdeslaur> oh, right, darn autocompletion :)
[14:05] <sebner> mdeslaur: pretty annoying, isn't it?
[14:05] <mdeslaur> sebner: it's only annoying when it gets it wrong :)
[14:07] <sebner> mdeslaur: heh
[14:36] <Riddell> pitti: for my work item on https://blueprints.edge.launchpad.net/ubuntu/+spec/lucid-duplicated-packages shouldn't it be marked postponed due to lsb requirements?
[14:37] <pitti> Riddell: oh, if the decision is made to keep it, then the "decide.." is DONE
[14:37] <bdrung> bryceh: do you have time to sponsor bug #534026?
[14:37] <pitti> Riddell: so we're going to keep it then?
[14:37] <Riddell> pitti: I assume we want to stay within LSB
[14:38] <pitti> Riddell: agree
[14:38] <Riddell> pitti: and I don't see a point in getting rid of the bindings in that case, it's just deviation from Debian
[14:39] <pitti> Riddell: agreed; I updated the spec
[14:39] <Riddell> thanks
[14:39] <pitti> thanks to you
[14:44]  * _UsUrPeR_ tips his hat
[14:44] <_UsUrPeR_> I would like some help with preseeding. Could somebody take a look at my preseed.conf and tell me what I am doing wrong please?
[14:45] <cjwatson> sure
[14:45] <_UsUrPeR_> it's here: http://pastebin.com/QPhxM4MB
[14:46] <_UsUrPeR_> cjohnston: for some reason, I cannot get this to partition an LVM correctly
[14:46] <cjwatson> I'm cjwatson not cjohnston; careful with that tab-completion :)
[14:47] <cjwatson> can I also see the syslog and partman logs from the installer, please?
[14:47] <_UsUrPeR_> cjwatson: right now, with the current configuration, it makes a boot partition, a single LVM, and a root directory inside the LVM.
[14:47] <_UsUrPeR_> hah. whoops
[14:47] <_UsUrPeR_> sorry mr. johnston
[14:48] <_UsUrPeR_> cjwatson: can I get back to you with those in a bit? I need to re-run the installation with the seed I sent you.
[14:48] <robbiew> pitti: https://blueprints.edge.launchpad.net/ubuntu/+spec/lucid-duplicated-packages has been approved ;)
[14:48] <pitti> robbiew: schweet
[14:49] <pitti> robbiew: that was a hard debate :-P
[14:49] <robbiew> lol
[14:49] <cjwatson> _UsUrPeR_: at a first glance, I think you should remove $lvmok{ } from /boot (assuming that you don't want it to be a logical volume?) and add $defaultignore{ } to the other partitions you want to be LVs as well as /
[14:49]  * _UsUrPeR_ follows advise
[14:49] <cjwatson> that may not be enough though - logs may help
[14:50] <cjwatson> I think that will probably amount to tidying up rather than actually fixing your problem, although I always have to look up the exact semantics of $defaultignore{ } and friends
[14:51] <_UsUrPeR_> cjwatson: ok, I'm running through an install with the new settings now
[14:51] <_UsUrPeR_> I'll get the logs as soon as the installation is complete
[14:52] <cjwatson> ok
[14:58] <mpt> ev, https://bugzilla.gnome.org/show_bug.cgi?id=99604#c7
[15:05] <pitti> ttx: thanks for the asm research
[15:06] <ttx> pitti: easy one, I already did it :)
[15:06] <pitti> yep, just saw
[15:06] <ttx> pitti: the goal is to demote to universe, or get rid of them ?
[15:06] <pitti> ttx: primarily, universe
[15:06] <pitti> if we can remove any of those completely, bonus of course
[15:06] <pitti> ttx: any hope for the three servlet APIs?
[15:07] <ttx> pitti: There is some concerted effort between ubuntu and debian java to get rid completely of 2.3 and 2.4, but it's blocking on some packages (struts for 2.3, eclipse for 2.4)
[15:07] <ttx> however, keeping them out of main might be doable
[15:08] <ttx> (especially 2.3)
[15:08] <pitti> ttx: if we can migrate away at least some, then this would at least help with bug fixing (you need to fix bugs in just one place, not three)
[15:08] <pitti> so there's some benefit even if there's one remaining sucker package which needs the old API still :)
[15:08] <ttx> pitti: that was the original goal of https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-java-library-fixes
[15:08] <pitti> ttx: dom4j is pretty strange though
[15:08] <kirkland> pitti: http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html
[15:09] <ttx> pitti: java is strange, in general.
[15:09] <pitti> ttx: ah, good; if that one has WIs for the same issue, please feel to drop the ones from the lucid-dups spec
[15:09] <ttx> pitti: no, I missed a few targets, so it's in addition to that spec (which is complete)
[15:09] <pitti> kirkland: pah -- I'll catch you again!
[15:09] <kirkland> pitti: hehe :-)
[15:10] <ttx> pitti: you can't win, eucalyptus is a unlimited source of bugs.
[15:10] <pitti> heh
[15:22] <mvo> tseliot: I get a fsck while plymouth is running - all I see on the screen is a big [C] in the center. is this a known bug? are you the right person to ask?
[15:22] <tseliot> mvo: what graphics driver are you using?
[15:23] <mvo> tseliot: this time I booted with nofb, before I was using nouveau but only got a blank screen
[15:23] <mvo> tseliot: I also have a flickering  bar (in ascii)
[15:23] <tseliot> mvo: I guess this time you used the text plugin
[15:23] <mvo> right, but shouldn't it show me something else in addition to the [C] ?
[15:24] <tseliot> Keybuk: ^^
[15:24] <Keybuk> mvo: yes, eventually ;)
[15:24] <mvo> Keybuk: aha, known issue? thats fine then
[15:24]  * tseliot 's theme is supposed to work with drm renderers
[15:24] <Keybuk> tseliot: sounds like he's got the text plugin
[15:25] <tseliot> right
[15:25]  * mvo waits until the fsck finishes
[15:25] <tseliot> which is why I asked you
[15:25] <Riddell> ev: any plans to review shtylman's ubiquity changes?
[15:27] <sebner> tseliot: btw, using the actual nvidia driver it's ~1-2° hotter than usual but nothing serious. + I heard you are working also for a nice booting experience for nvidia driver users ;D
[15:27] <pitti> james_w: ok to flush your redntoebook sync?
[15:27] <pitti> james_w: (I have another sync I need to do)
[15:27] <shtylman> Riddell: I think he has reviewed them... just not merged yet? <-- ev
[15:27] <tseliot> sebner: yes, I'm working on it. It should be 16 colours though
[15:27] <james_w> pitti: I was in the middle of a mass-sync but LP is broken
[15:28] <james_w> pitti: so, fine
[15:28] <sebner> tseliot: wondering what level of "nice" that'll be ^_^
[15:28] <tseliot> sebner: better than ascii
[15:28] <tseliot> ;)
[15:28] <sebner> tseliot: that certainly nice but we live in 2010 :P
[15:29] <tseliot> right and drivers use KMS now...
[15:29] <Keybuk> sebner: get a graphics card supported by free software then
[15:30] <sebner> tseliot: plymouth and that stuff should have used technologies that also 3D blob drivers can use
[15:30]  * sebner is afraid of Keybuk and hides :P
[15:30] <tseliot> sebner: you can always use vesafb or some other module if you want more colours
[15:31] <Keybuk> (and don't want suspend/resume :P)
[15:31] <Keybuk> tseliot: I wonder why the nvidia blob doesn't provide a framebuffer
[15:31] <sebner> it seems either way a lot stuff is b0rken on linux
[15:32] <tseliot> Keybuk: who needs suspend/resume anyway :-P ?
[15:32] <sebner> tseliot++
[15:32]  * sebner doesn't use it
[15:32] <sebner> also hibernate takes longer than a reboot :P
[15:34] <_UsUrPeR_> cjwatson: the changes appear to have worked! :D
[15:34] <cjwatson> _UsUrPeR_: cool
[15:35] <_UsUrPeR_> It seemed that $defaultignore { } would ignore lvm settings, but it's the opposite. I had read over preseeding docs a few times, and I guess I never grasped the concept :/
[15:37] <_UsUrPeR_> cjwatson: thanks for your help.
[15:37] <cjwatson> _UsUrPeR_: the naming is definitely suboptimal.  glad to help
[15:38] <_UsUrPeR_> cjwatson: one question though: My partitions were created strangely. I had specified the max for swap to be 300% (Of total RAM, if I read the docs correctly), but the swap partition was created as 122 gigs.
[15:38] <_UsUrPeR_> cjwatson: while the /home directory was created with 10 gigs.
[15:39] <_UsUrPeR_> how did swap exceed the RAM count by almost 110 gigs? :)
[15:39] <cjwatson> that's almost certainly a bug, but you might try making the swap partition not the last one in the recipe
[15:39] <cjwatson> oh, or alternatively
[15:39] <cjwatson> set bigger weights (second field) for the partitions you want to grow more
[15:40] <cjwatson> you probably want /home's priority/weight to be rather closer to the maximum size than the minimum size
[15:41] <_UsUrPeR_> cjwatson: Yeah, I just hard-coded the swap partition's max, and added another 0 to /home
[15:41] <_UsUrPeR_> which would put it around 100 gigs :)
[15:42]  * _UsUrPeR_ looks for a preseed project on launchpad
[15:42] <cjwatson> the maximum isn't so important in this case (you already have it set to a terabyte).  worry about the priority
[15:42] <cjwatson> you don't want the preseed project on launchpad
[15:42] <_UsUrPeR_> ok
[15:42] <cjwatson> if you're looking to file a bug report, it would go on the partman-auto package in Ubuntu
[15:42] <_UsUrPeR_> cjwatson: ahh. ok, cool. thanks for the pointer
[15:48] <chrisccoulson> hi doko, i'm trying to investigate an openjdk-6 build failure as part of the xulrunner-1.9.2 migration, and wondered if you had any pointers to what might be going wrong?
[15:48] <chrisccoulson> the build log is here: http://launchpadlibrarian.net/40287073/buildlog_ubuntu-lucid-amd64.openjdk-6_6b18~pre1-1ubuntu1.0ffox36.1_FAILEDTOBUILD.txt.gz
[15:49] <chrisccoulson> and i can also recreate the issue with the current version in the archive with the current xulrunner version too
[15:53] <doko> chrisccoulson: ENOCLUE. are there other packages in the ppa? : Unknown command line argument '-mcpu=k8-sse3'.  Try: ' -help'
[15:54] <chrisccoulson> doko - my local uild environment isn't pulling in any PPA packages
[15:54] <chrisccoulson> s/uild/build
[15:55] <chrisccoulson> doko - I've still got a shell open in the broken build environment, and if I call "./gamm" (with no arguments), I get the same error
[15:55] <chrisccoulson> sorry, i meant "./gamma"
[15:55] <chrisccoulson> (keep missing keys today)
[15:56] <doko> chrisccoulson: and does strings ./gamma |grep mcpu show something?
[15:57] <chrisccoulson> doko - it doesn't show anything
[15:58] <doko> chrisccoulson: please try stracing ./gamma
[15:59] <chrisccoulson> doko - http://paste.ubuntu.com/391125/
[16:02] <doko> chrisccoulson: no clue yet; maybe search the string in the linked libs? in the Makefile/config.status?
[16:03] <chrisccoulson> doko - will do. thanks
[16:25]  * pitti hugs mvo -- my  hero!
[16:26] <mvo> heh .) thanks pitti
[16:26] <mvo> only a small contribution
[16:27] <pitti> mvo: I'll change g-p-extras to drop python-gtkhtml2 then
[16:27] <pitti> ah, oops
[16:27] <pitti> a handful of universe packages needs it as well
[16:27] <pitti> hmm
[16:27] <pitti> but nothing too interesting
[16:27] <pitti> mvo: gnome-app-install is the only interesting universe package which still uses it
[16:28] <pitti> mvo: but in the light of software-center (which is like its successor), shoudl we even keep that one?
[16:28] <mvo> pitti: I can port that too
[16:28] <juliank> pitti, mvo: How about dropping gnome-app-install; I've already done it in Debian.
[16:28] <pitti> if we can just remove it, that would be even easier
[16:28] <pitti> juliank: my thought
[16:28] <mvo> yeah, the only reason to keep it is that the a11y is better than in software-center
[16:28] <pitti> s-c FTW :)
[16:29] <mvo> but its now pretty much unmaintained :)
[16:29] <pitti> right
[16:29] <mvo> so better fix s-c
[16:29] <pitti> or use apt-get install.. :)
[16:29] <mvo> heh :)
[16:29]  * pitti removes
[16:30] <juliank> mvo: pochu said for the Debian package we should be thinking about a transitional package (aka http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572941); maybe the same for the Ubuntu one?
[16:30] <pitti> yes, that'd make sense
[16:30]  * mvo nods
[16:31] <juliank> mvo: When you add one, could you add a 'Closes: #572941' for the Debian bug, to make this close automatically when I backmerge it into Debian.
[16:32] <mvo> juliank: sure
[16:39] <mvo> juliank: commited as r637
[16:41] <mvo> juliank: it uses "section: transitional" so that apt does not mark s-c as auto-installed
[16:47] <pitti> mvo: oh, that exists now? I still use "oldlibs" for those
[16:48] <mvo> pitti: well, not officially…
[16:49] <pitti> mvo: does it check for oldlibs as well?
[16:49] <mvo> pitti: but I think it really should be there so that the automatic install magic can be prevented, otherwise gnome-app-install -> software-center will mark software-center as auto installed
[16:51] <mvo> pitti: hm, good point about oldlibs
[16:52] <mvo> pitti: it seems like nowdays its pretty much only used for transtional package, I guess I should use that instead
[16:52] <mvo> pitti: what do you think?
[16:54] <pitti> mvo: you could check for both
[16:55]  * mvo nods
[17:11] <geser> doko: do we keep python3.0 for lucid or is it planned to get removed before release?
[17:12] <doko> geser: remove definitely. could you care about it?
[17:12] <geser> doko: sure, will file a removal bug
[17:32] <geser> cjwatson: thanks for sponsoring the vim merge
[17:33] <cjwatson> that's ok - I looked through it and agreed there didn't seem to be a need for an FFE given the nature of the changes
[17:43] <kasi> does anyone know whether apache 2.2.12-1ubuntu is affected by this? http://www.senseofsecurity.com.au/advisories/SOS-10-002
[17:44] <mdeslaur> kasi: only on windows, so, no
[17:44] <kasi> oops. my bad.
[17:44] <kasi> thanks
[17:44]  * kasi stands ashamed in a corner and things of the common saying "reading helps".
[17:46] <cjwatson> geser: can you see why it fails to build on i386?  the log is uninformative, and I had test-built it locally already.  http://launchpadlibrarian.net/40508406/buildlog_ubuntu-lucid-i386.vim_2%3A7.2.330-1ubuntu1_FAILEDTOBUILD.txt.gz
[17:47] <cjwatson> geser: oh, maybe needs rm -f?
[17:48] <cjwatson> except I can't see where that rm is being called, maybe internal to make?
[17:50] <cjwatson> or parallelisation or something?
[17:53] <cjwatson> I think that rm is internal for intermediate files, and it's in fact more closely equivalent to rm -f; it ignores ENOENT, at any rate
[17:54] <_UsUrPeR_> cjwatson: I have one more question about preseeding. I am attempting to create a seed that partitions in LVM (works! thanks :D), and am also trying to have all the packages for LTSP installed + build an LTSP image. I attempted to use the LTSP preseed (on the installation CD) as an example, but it does not appear to be building a client image like I had expected.
[17:55] <cjwatson> _UsUrPeR_: I'll need syslog again
[17:55] <cjwatson> ltsp is not really my area but I can have a look
[17:56] <_UsUrPeR_> cjwatson: ok. I'll get that for you now. Here's my present preseed: http://pastebin.com/i0mJ9BSe
[17:56] <_UsUrPeR_> cjwatson: the commands for building/installing ltsp are at the bottom of the .seed
[17:56]  * _UsUrPeR_ goes to get the syslog post-install
[17:57] <cjwatson> looks ok on the face of it
[17:58] <_UsUrPeR_> cjwatson: here's the syslog post-install: http://pastebin.com/w2b4xZ31
[17:58] <cjwatson> no, that's not the one I need - it winds up in /var/log/installer/syslog post-install
[17:58] <cjwatson> (dinner, back later)
[18:04] <mterry> ccheney, you recently updated the openoffice.org thesauruses to not depend on language-support-writing-*.  Now language-support-writing-* packages pull in all of OO.o.  Was that intended?
[18:06] <_UsUrPeR_> cjwatson: ok, here's the correct log (sorry I sent you the wrong one before): http://pastebin.com/neVSXq1M
[18:18] <ccheney> mterry: yes and no, i will be fixing it soon again, there was a misunderstanding that all language-support-* was going away when it was only language-support-translations-*
[18:18] <geser> cjwatson: I assume too that it's because of parallel building as the log contains "*** DEBIAN *** CONFIGURING VARIANT vim-tiny" directly followed by "*** DEBIAN *** CONFIGURING VARIANT vim-gtk"
[18:18] <ccheney> mterry: or something to that effect
[18:18] <mterry> ccheney, ah, cool.  Thanks!
[18:34] <geser> cjwatson: I could reproduce the problem with DEB_BUILD_OPTIONS="parallel=2" inside my pbuilder
[18:46] <lamalex> Hey sponsors, can someone (when they get a moment) take a look at https://code.edge.launchpad.net/~alexlauni/ubuntu/lucid/gnome-power-manager/gpm-fix-530751/+merge/20920 ? fixes another g-p-m papercut
[18:47] <chrisccoulson> lamalex, the gpm fix should wait really, as I'll have some other fixes to upload this week
[18:48] <shtylman> is the latest kernel (16) giving anyone problems with the nvidia-current drivers?
[18:48] <lamalex> chrisccoulson, right on
[18:48] <chrisccoulson> lamalex, and we're in to UI freeze now, we really should stop making string changes
[18:49] <chrisccoulson> they break translations
[18:49] <chrisccoulson> so the translation team needs to be notified really
[18:49] <Riddell> mvo: I just added this to packagekit http://people.canonical.com/~jriddell/tmp/fix_upgrade_distro.diff and put update-manager-kde back into main with kpackagekit depending on it
[18:49] <Riddell> just FYI
[18:49] <lamalex> we're not far into UI freeze.. so merge soon! it seems odd that we'd break our own notify-osd spec
[18:51] <chrisccoulson> lamalex, being "not far in to UI freeze" isn't a good excuse for breaking it
[18:51] <chrisccoulson> if it was ok, then we'd shift UI freeze back a few days
[19:23] <mvo> Riddell: nice, thanks
[19:26] <cjwatson> geser: so we should just disable parallel building?
[19:27] <cjwatson> _UsUrPeR_: try putting anna/choose_modules=ltsp-client-builder on the kernel command line
[19:27] <_UsUrPeR_> cjwatson: rgr. Uno momento
[19:27] <sebner> sebner: " - Put tabs at the top again" *WUHUHUHUUUUUUHUHH*
[19:28] <sebner> urgh. /me seems to be egocentric xD
[19:28] <_UsUrPeR_> cjohnston: command not found.
[19:28] <_UsUrPeR_> fuuu
[19:29] <_UsUrPeR_> cjwatson: ^^^
[19:29] <_UsUrPeR_> mr. johnston: again, I apologize
[19:29] <_UsUrPeR_> cjwatson: hmm. I know that the LTSP build in 9.10 alternate works when run from a normal CD.
[19:29] <_UsUrPeR_> cjwatson: Where is that command stored? :/
[19:30] <geser> cjwatson: unless you know how to debug this (I don't), commenting out line 32 in debian/rules seems to be sufficient to disable the parallel build and make the package build
[19:30] <cjwatson> _UsUrPeR_: um, what command
[19:30] <cjwatson> ?
[19:31] <_UsUrPeR_> d'oh type. Let me try that again
[19:31] <cjwatson> _UsUrPeR_: what I mean is to append that string as a kernel parameter
[19:31] <_UsUrPeR_> cjwatson: ahh. Will do.
[19:31] <geser> cjwatson: and I couldn't find yet the change between the recent rebuild upload and the merge which explains the problem as the previous version supported parallel building too
[19:31]  * _UsUrPeR_ makes the seed changes
[19:32] <cjwatson> geser: right, I can't see anything relevant either.  can you give me a branch?
[19:33] <_UsUrPeR_> cjwatson: so that will replace the following command already in the preseed: "d-i     anna/choose_modules     string ltsp-client-builder"
[19:33] <_UsUrPeR_> is that correct?
[19:33] <cjwatson> it should not go in the preseed file
[19:33] <shtylman> bug #534469 is hot :)
[19:33] <cjwatson> it's a kernel parameter
[19:34] <_UsUrPeR_> cjwatson: oh. My apologies. How/where should I input that change? I am not sure where I would add that.
[19:35] <Chipzz> grub
[19:35] <Chipzz> pxelinux
[19:35] <Chipzz> isolinux
[19:35] <Chipzz> pick one :P
[19:37]  * _UsUrPeR_ points ant himself and mouths "me?"
[19:37] <cjwatson> _UsUrPeR_: usually goes in pxelinux.cfg, on the append line
[19:37] <cjwatson> you should have something like url=http://url/of/your/preseed/file there already
[19:39] <_UsUrPeR_> ahh! Ok, I gotcha. That would be in /syslinux/text.cfg on the edited menu system I set up to run the preseed, then.
[19:40] <_UsUrPeR_> ok, so here's what I have for the menu.txt right now: http://pastebin.com/QK0AtRF7
[19:40] <_UsUrPeR_> this is run upon boot
[19:41] <_UsUrPeR_> I just added that parameter to the end
[19:56] <geser> cjwatson: https://code.edge.launchpad.net/~geser/ubuntu/lucid/vim/disable-parallel-building/+merge/20925
[19:58] <mvo> Riddell: if you have nothing else pending I will upload update-manager now
[20:00] <ScottK> mvo: I don't suppose you'll have any time to squeeze the backports not-automatic fixes ....
[20:02] <cjwatson> _UsUrPeR_: looks fine.  you can shorten debian-installer/locale= to locale= if you like
[20:02] <_UsUrPeR_> oh nice. I'll do that later. Thanks for the pointers. I'm running the installation process now.
[20:42] <jbebel> apw, are you aware of bug 534635
[21:10] <TheMuso> apw: I know.
[21:45] <apw> jbebel, hrm ... no, thanks
[21:55] <sits> can someone say if https://bugs.launchpad.net/ubuntu/+source/gnome-media/+bug/532095 really is an upstream issue?
[23:01] <Beaver> www.search2.net (new search engine)
[23:21] <rurti> hello
[23:23] <rurti> is anyone here available to help me with a problem, i have already been on the #ubuntu,  #ubuntu-desktop and #channels and then was finally directed here
[23:26] <rurti> what i am trying to do is to add my own dir to the PATH variable, i put it in the .profile file however applications like gedit do not see the bin when execute the make within it.
[23:27] <kirkland> jcastro: yo
[23:27] <kirkland> jcastro: tell me about your experience with Bug 530289
[23:27] <jcastro> kirkland: sure, so I did a reinstall on this machine
[23:27] <jcastro> and then wanted to test something
[23:28] <jcastro> kirkland: after it installed I tried to fire it up, but it told me kvm was busted, so I modprobed like it said
[23:28] <jcastro> but I didn't do "kvm_intel" just "kvm"
[23:29] <rurti> is there anyone here that can help me with this problem/
[23:29] <rurti> ?
[23:30] <jcastro> kirkland: I think for me it was just user error
[23:30] <jcastro> kirkland: I assumed modprobing kvm would take care of the right bits
[23:31] <kirkland> jcastro: gotcha; okay, i'm going to fix this in kvm-ok with better instructions
[23:31] <kirkland> jcastro: thanks!
[23:31] <kirkland> jcastro: sorry about that
[23:31] <jcastro> kirkland: no worries, I was using it to test for something else so glad I found it!
[23:32] <rurti> jcastro may i bother you for a moment please?
[23:33] <jcastro> rurti: you're probably better off on a mailing list
[23:33]  * jcastro can't remember the last time he messed with PATH
[23:34] <rurti> jcastro: what mailing list should post this on?
[23:34] <jcastro> rurti: ubuntu-users most likely
[23:35] <jcastro> http://lists.ubuntu.com
[23:35] <rurti> jcasstro: thank your very much for your advice.
[23:35] <jcastro> good luck!
[23:35] <kirkland> rurti: have you logged out and back in?
[23:36] <Riddell> ev: not merging roman's ubiquity branch?
[23:37] <rurti> kirkland: yes i have, it shows up in the terminal fine, however when apps like gnome execute it i know see the parameters et by ENV_PATH in /etc/login.defs
[23:38] <kirkland> rurti: you're going to need to ask one of the desktop guys about that ...  pitti, seb128: how does a user affect their $PATH env within Gnome?
[23:39] <seb128> kirkland, I don't know
[23:39] <seb128> I told him to ask there that might somebody would know
[23:39] <kirkland> seb128: there = here?
[23:39] <seb128> I would have changed it in profile or gnomerc
[23:39] <seb128> but apparently that doesn't work
[23:39] <rurti> kirkland: i was just talking with seb128 he told me to come here
[23:39] <seb128> kirkland, he asked in #ubuntu-desktop first and I bounced him to #ubuntu-devel
[23:40] <kirkland> seb128: okay, hrm, interesting
[23:40] <seb128> not sure why changing .profile doesn't work
[23:40] <kirkland> rurti: ls -alF /etc/profile.d
[23:40] <rurti> yes it is an interesting problem in deed
[23:40] <persia> Does ${foo}-session source .profile?  I thought such variables had to be set in the Xsession files or ${foo}-session specific files.
[23:41] <chrisccoulson> for changing $PATH, i normally define it in /etc/environment
[23:41] <rurti> kirkland: trying it one second
[23:41] <persia> chrisccoulson: That's a big hammer.
[23:42] <rurti> Kirkland: there is nothing in there
[23:42] <seb128> rurti, changing /etc/environment should work
[23:42] <kirkland> persia: agreed, and requires admin privilege
[23:43] <rurti> seb128: that will change it for all accounts though wont it?
[23:43] <seb128> rurti, yes
[23:43] <rurti> seb128: i guess we cannot change it just for one profile?
[23:44] <chrisccoulson> i'm not sure of any other way of doing it, which is picked up in the enviorment of the various session components
[23:44] <persia> kirkland: For ~/.Xsession ?
[23:44] <kirkland> hrm, you know, i've gotten a strange byobu bug report recently, about .profile settings not being respected ....
[23:44] <kirkland> persia: i was supporting your "big hammer" comment
[23:45] <persia> Oh yeah.
[23:45] <seb128> kirkland, he's using hardy not lucid and other env variable are set correctly it's only a path issue
[23:45] <kirkland> seb128: ah, okay
[23:45] <seb128> rurti, change the launcher to the application you want to start this way by a wrapper?
[23:45] <seb128> rurti, ie a small script setting path and running the binary
[23:46] <chrisccoulson> which application has the wrong $PATH?
[23:46] <chrisccoulson> and how is it launched?
[23:46] <rurti> seb128: I am thinking that may have to be the route i go.
[23:47] <rurti> seb128: i could change the commands to go "setToolEnv; make all"
[23:47] <rurti> just some people use different tools
[23:48] <rurti> i was hoping that the path could make it happen for all apps
[23:48] <rurti> sorry .profile not path
[23:50] <cjwatson> I believe you can edit .pam_environment and that'll apply to all PAM sessions
[23:50] <cjwatson> same format as /etc/environment
[23:51] <cjwatson> note that it is not a shell script, it's just KEY=VALUE, so don't expect e.g. shell variable expansions to work
[23:51] <cjwatson> though I think you can substitute environment variables with ${var}, according to /usr/share/doc/libpam-doc/html/sag-pam_env.html
[23:51] <cjwatson> ... actually skip that last part, misreading
[23:52] <rurti> ok
[23:52] <rurti> one quick question, is /etc/environment a regular script file?
[23:53] <psusi> TheMuso, ping
[23:54] <TheMuso> psusi: Just ask your question/make your statement, and I'll respond when I get to it, but yes, I am around now. Whats up?
[23:54] <psusi> TheMuso, cool... long time no see... been tracking down a dmraid bug in Karmic and I finally found the problem and was wondering if I could get your opinion on what the solution should be
[23:55] <psusi> it seems dmraid is causing a udev event feedback loop in Karmic... my first thought was to change the udev rule to only activate on add events, not change events as well
[23:55] <psusi> but I'm not sure if that could have other consequences
[23:58] <TheMuso> psusi: Hrm. I guess the whole change events would only be an issue for externally connected disks. Have you checked to see whether anyone using Debian are also experiencing this bug?