# /srv/irclogs.ubuntu.com/2013/04/23/#ubuntu-devel.txt

mwhudson mwhudson vanhoof === wedgwood is now known as wedgwood_away are there netinstall images for installing raring on highbank around anywhere? 02:06 http://ports.ubuntu.com/dists/raring/main/installer-armhf/current/images/generic/netboot/ looks promising 02:11 mwhudson: ack 02:11 rarara why do netinstalls have to take so long 02:12 Because you're in NZ? :-P 02:13 the server i'm installing isn't 02:13 ... details 02:14 mwhudson: only remaining oddity is https://bugs.launchpad.net/bugs/1171582 02:15 Launchpad bug 1171582 in linux (Ubuntu) "[highbank] hvc0 getty causes random hangs" [High,Incomplete] 02:15 mwhudson: but yeah installs are good now w/ the flash-kernel update today 02:15 how was one nominate a bug as a potential raring blocker? (or if not blocker, fix ASAP) 02:26 s/was/does/ 02:26 [reed]: What bug? 02:35 RAOF: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1108056 -- summary/title sucks, but basically, Pidgin doesn't work at all on 13.04 (just hangs) 02:35 Launchpad bug 1108056 in pidgin (Ubuntu) "fetching URLs freezes pidgin" [Undecided,Confirmed] 02:35 there's a debdiff already posted with a fix 02:36 That's not a raring blocker. 02:36 it's seeded in lubuntu 02:36 Raring blockers at this point are going to be on the order of “Inserting the CD causes the Old Ones to rise and tentacles to emerge from my laptop” 02:37 That looks like it's a fine category for an SRU, though, which only requires someone to upload that debdiff. 02:37 RAOF: The reporters aren't going to be any position to file that one ... 02:38 StevenK: THAT'S THE BEAUTY OF IT! 02:38 Haha 02:38 RAOF: perhaps you'd like to upload it? :P 02:38 [reed]: uploaded, but someone will need to reformat the bug description section according to SRU guidelines 02:42 ...which I'll do in 12 hours if someone doesn't beat me to it within 12 hours. 02:43 dtchen: thanks! 02:45 Good morning 03:38 ScottK: you mean merely installing bcmwl-kernel-source makes it work at instant? 03:41 pitti: Yes. 03:41 ScottK: perhaps the package does the unbind/rebind itself these days, then jockey wouldn't need to any more indeed 03:42 * pitti checks 03:42 sudo apt-get install bcmwl-kernel-source and wait while it does it's magic is enough. 03:42 ah, so it does 03:42 I guess we did that for the migration to ubuntu-drivers-common, but never adjusted the old jockey handler 03:43 I attempted to make it not do the bind/unbind, but didn't seem to be able to manage it. 03:43 ScottK: I'll upload a fix now 03:43 pitti: Great.  Thanks. 03:43 ScottK: http://bazaar.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/revision/648, if you want to apply it inline on the live system and try 03:55 I was checking whether we should completely skip the KernelModuleHandler.enable() bits, but we need some of them 03:56 so that's the simplest fix which only suppresses the rebinding 03:56 I already tried that particular change and it still did the rebind somewhere. 03:57 uh? 03:57 That's what I said. 03:57 right, I interpreted "I attempted to make it not do the bind/unbind" as "I didn't know how to do that" 03:58 we use the very same approach in the nvidia handler 03:58 I'm assuming that the segfault in the bug can only come from an attempt to unbind/rebind. 03:59 correct 03:59 unless the driver internally calls any of those on loading/unloading 03:59 it seems the wl driver doesn't really like to be unloaded, too 04:00 Except if it did that, you'd think just installing the package would cause a failure. 04:00 i. e. if you try loading/unloading it twice in the same session it might do the same? 04:00 booting a live session, applying that change, and enabling wl in jockey should not do any module unloading or rebinding 04:01 Let me try it again. 04:02 ScottK: also, it's important to set self._do_rebind = False after the KernelModuleHandler.__init__ call 04:02 I already started it. 04:05 And it died. 04:06 so I suppose the rmmodding/modprobing in jockey is bad as well, as the postinst duplicates it 04:06 * pitti does V2 04:07 You may be able to make V2 faster than my system boots. 04:08 ScottK: can I give you a proposed broadcom_wl.py file on people.u.c. for testing? 04:09 I don't have network on the system, so a diff is easier. 04:09 Hopefully it's not large. 04:10 If I have to, I can copy it onto my USB stick and boot the live system again. 04:10 it's not that large 04:11 ScottK: http://paste.ubuntu.com/5594596/ 04:13 ScottK: quite hackish, but *shrug* 04:13 Should be the last cycle for jockey ... 04:14 ah, is Kubuntu moving to u-d-common? 04:14 it shouldn't even be too hard to port the jockey UI to use u-d-common 04:15 Running 04:19 I hope so.  We had some python3/KCM integration issues that blocked us most of the cycle. 04:19 Resolved now, but too late to do anything in raring. 04:19 lifeless: oh, not sure, call it a megabyte maybe? 04:20 pitti: Still crapped out. 04:20 ScottK: u-d-common works with py2 as well, BTW 04:20 ScottK: urgh, what now; exact same dmesg? 04:21 Yes.  Exact same. 04:21 Interesting.  I don't think we realized that. 04:21 ScottK: or could it perhaps be that jockey-backend was already running when you applied the change? 04:21 Not unless it runs automatically on boot. 04:21 ScottK: could you check "ps aux|grep jockey" after a boot? something during live boot might ask it for something on d-bus perhaps 04:21 Sure. 04:22 Let me restart 04:22 thanks 04:22 === salem_ is now known as _salem That's it.  It's running already. 04:26 Sigh. 04:26 pitti: Which fix to you want me to retry? 04:28 ScottK: the latter is more comprehensive 04:28 ScottK: it also avoids duplicate unloading/reloading, which it seems we should better avoid 04:28 ok 04:28 ScottK: you can just kill it, it'll respawn from dbus 04:28 (it also times out after 10 mins or so) 04:29 Running 04:32 pitti: worked. 04:33 \o/ 04:33 thanks for your patience 04:33 I'll be glad to review/accept that one. 04:33 uploaded 04:34 In a way it's better I didn't think to check if it was running already because I'd have stopped at the less correct solution. 04:34 Excellent. 04:34 === rsalveti_ is now known as rsalveti morning 05:57 asac, happy birthday! :) 06:36 good morning 06:41 === security is now known as baba === smb` is now known as smb === brendand_ is now known as brendand === amitk is now known as amitk-afk === ckpringle_ is now known as ckpringle === jamesh_ is now known as jamesh Mirv: did you see my qtbase merge? I've just rebased it on 5.0.2+dfsg1-3 09:17 === ckpringle_ is now known as ckpringle === amitk-afk is now known as amitk dholbach: :) 09:24 thx 09:24 Mirv: and I have yet another Vcs fields fix for you: http://paste.ubuntu.com/5595113/ 09:45 mitya57: looks excellent, thanks. I was hesitating another resync because we shuffled with the some options, but it should be fine now 09:48 mitya57: I'll also take that qttools one 09:48 Mirv: we'll be able to sync all qt5 packages (except qtbase) when S opens, right? 09:54 or do we have any delta? 09:54 mitya57: thanks for spotting and syncing perl 5.14.2-21 last week 09:56 I noticed that when upgrading a wheezy system this morning and went to check whether we'd picked it up for raring ... 09:56 mitya57: there is some delta like the one srgb patch in qtdeclarative (loicm should be looking at that) and so on, but in general a sync when S opens (preserving the small delta where it exists) sounds really good 09:57 === ara is now known as Guest91539 mitya57: but for many modules a straight-forward sync would be all that is needed 09:58 lool: I guess we are going to re-target https://blueprints.launchpad.net/ubuntu/+spec/client-1303-converged-network-stack to squishy after this week? 09:58 cjwatson: I always look at upgrade logs of my sid system and file SRs for ubuntu-relevant fixes :) 09:58 lool: or do you want to create a BP copy for the squishy bits, to keep the old raring spec for WI trackign/historical purposes? 09:59 Mirv: thanks 10:02 mitya57: thanks to you 10:02 === baba is now known as cod3r === Guest43339 is now known as zumbi === ckpringle_ is now known as ckpringle === MacSlow is now known as MacSlow|lunch === mmrazik is now known as mmrazik|afk jodh: having any luck with that upstart bug? 11:17 pitti: I'd suggest marking the WIs as postponed for r and copy-pasting them as TODO for S 11:42 lool: so into a new BP then? 11:58 pitti: yeah; does that make sense? 11:58 lool: sure 11:58 === MacSlow|lunch is now known as MacSlow === highvolt1ge is now known as highvoltage stgraber: not really - if you've got spare cycles and want to get involved, let me know. 12:05 jodh: starting an ISO install and then I can take a look. 12:07 === amitk is now known as amitk-afk === mmrazik|afk is now known as mmrazik === _salem is now known as salem_ === highvolt1ge is now known as highvoltage lool, rsalveti, sforshee: ready for in 15m? 12:45 ooh fun, 3.5 kernel won't boot on 32-bits for me :> 12:47 === cod3r is now known as Guest34392 oh right, probably need pae kernel 12:53 dholbach: yup 12:57 wrt https://bugs.launchpad.net/ubuntu/+source/workrave/+bug/1154647 the problem translation lines are coming from .po files - can these just be changed or does it happen through launchpad or something? 12:58 Launchpad bug 1154647 in workrave (Ubuntu) "workrave does not appear in dash due to 2 multiline Comments in workrave.desktop (Comment[pl] & Comment[ru]" [Undecided,Confirmed] 12:58 *no idea how translation works* 12:58 === ckpringle_ is now known as ckpringle cjwatson, Laney: I see my systemd SRU was already accepted into raring (bug 1171691); was that intended, or is our migration blocker broken? 13:03 bug 1171691 in systemd (Ubuntu Raring) "Removing libpam-systemd (without purge) breaks system" [Medium,Fix released] https://launchpad.net/bugs/1171691 13:03 i. e. we need to respin now? 13:04 pitti: we needed to respin anyway for bug 1080701 13:10 bug 1080701 in partman-auto (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [Critical,In progress] https://launchpad.net/bugs/1080701 13:10 pitti: and infinity and I reckoned that the consequences of your bug were serious enough that they were worth riding along 13:10 so I manually unblocked systemd 13:11 or actually Adam did 13:12 cjwatson: thanks for confirming 13:20 === amitk-afk is now known as amitk smoser: ping 13:55 stgraber, here 13:57 === wedgwood_away is now known as wedgwood smoser: hey, so I'm poking at the cloud-init bugs. How do I reset cloud-init so that it re-runs apt-get update + apt-get dist-upgrade on reboot? 14:03 rm -Rf /var/lib/cloud will do it. 14:04 there are specific files you could remove for that specific action, or you could change that action to run every boot via config. 14:05 but i often do the 'rm -Rf /var/lib/cloud && rm -Rf /var/log/cloud-init* && reboot' 14:05 smoser: then I need to manually copy the cloud config file right? 14:06 ? 14:07 the userdata file 14:07 === jbicha_ is now known as jbicha stgraber, you were using nocloud i guess? 14:09 ah. or you were doing lxc (which uses nocloud) 14:09 yes, you do have to avoid rm'ing the /var/lib/cloud/data/seed path. 14:09 (that is somewhat annoying) 14:10 ok, good, looks like it's working 14:11 smoser: ok, so the good news is that we confirmed that the two bugs are actually the same (stateful re-exec and reload-configuration), now we just need to find a fix, make sure we don't break anything else with it and see whether we can land that stuff 14:19 jodh is now working on a potential fix, we've got a new test added to upstart to test the fix and I've got the lxc environment setup to test the specific case as it happens for cloud-init 14:20 ev, the top "colord" error on the leaderboard (#41) is marked as unsuccessfully fixed because it's "still" occurring in 0.1.16-2ubuntu0.1. But the bug report says it was fixed in 0.1.21-1ubuntu2. Is that a version comparison bug, or what? 14:24 jodh, Is there a library to emit upstart events?  Or does everyone just shell out to initctl? 14:32 you can just prod dbus 14:33 Yeah, that's what I was thinking.  But curious if someone already wrapped that :-) 14:34 /com/ubuntu/Upstart com.ubuntu.Upstart0_6 EmitEvent 14:34 (the versioning there is a bit of a warning sign I guess) 14:34 In general, we've tried to always wrap the DBus interfaces in libraries just because the versioning is more well defined with libs. 14:35 True 14:35 === chuck__ is now known as zul === tkamppeter_ is now known as tkamppeter === rickspencer3_ is now known as rickspencer3 === kentb-out is now known as kentb hallyn: for bug 1171866 can't we say "Container isn't started" or similar if we can't connect to the abstract socket? 15:39 bug 1171866 in lxc (Ubuntu) "lxc-stop ignores invalid container names" [Undecided,Invalid] https://launchpad.net/bugs/1171866 15:39 that'd cover the case of a non-existing container at least 15:40 or maybe: if we can't connect to the socket and the container isn't defined => container doesn't exist 15:40 if we can't connect to the socket and the container is defined => container isn't started 15:40 barry: could you have a look at bug 1051935 again? somebody has a couple of branches for it - maybe something for S 15:41 bug 1051935 in python-apt (Ubuntu) "Fails with SystemError when too many files are open" [Medium,Triaged] https://launchpad.net/bugs/1051935 15:41 bdmurray: no time right now, but it's in a browser tab ;) 15:42 barry: sounds good, thanks 15:42 pitti: is there any chance you'll merge my calibre changes in time for raring? 15:47 stgraber: what does it mean for the container to be defined? 15:48 mitya57: ah, you updated that, indeed; sorry for the delay! 15:48 mitya57: what is the preinst snippet about? (removing /usr/share/calibre/viewer/mathjax) 15:50 pitti: dpkg doesn't like when one is replacing a directory with a symlink, so we need to remove it before installing the new version 15:50 mitya57: oh, I just saw the corresponding line in debian/rules 15:51 hallyn: directory exists in the config dir (/var/lib/lxc) 15:52 stgraber: i'm not entirely opposed though. 15:52 "! -h" checks (I hope) that it's argument is not a symlink 15:52 it's just the conatiner not being 'defined' is not technically an error 15:52 so we'd be introducing different behavior for 'permanent' contaienrs and 'temporary' ones on lxc-stop when already stopped 15:53 pitti: I forgot to mention that use_system_markdown.patch only touches the file that is used during build, other files are modified using a sed call in d/rules 15:53 mitya57: right, thanks 15:53 mitya57: yeah, I was going to ask -- shouldn't the sed cover the bit what the patch does, too? 15:54 hallyn: well, I think in general we should be returning non-zero and show an error when commands are expecting to do something against a running container and that container clearly isn't running (because the abstract socket doesn't exist) 15:54 pitti: sed is called after the package is built, and touches already installed files 15:55 mitya57: so that particular piece of code is run during build then 15:55 yes 15:55 alright, thanks! 15:55 stgraber: and that's what i do in the api.  but we'd be changing behavior.  but soy ou're saying always return -1 if already stopped - i'm ok with that, if noone on the list objects 15:55 mitya57: if you want, you can already upload that to Ubuntu 15:56 mitya57: I'll do a new Debian upload with a newer upstream version 15:56 flattened my raring laptop (long story), and after reinstall, all it finds in the sound category is "Dummy Output"...  thoughts on how to get sound back? 15:56 (but I guess that's too late for the freeze now) 15:56 hallyn: right and I'd expect freeze/unfreeze to do that too. I believe we already do something like that in lxc-shutdown 15:56 hallyn: (would be great if we could make that kind of thing consistent for 1.0 ;)) 15:57 pitti: another note: now it should crash when opening a .rar file, probably my suggestion in MP comment will fix that, but it's not tested 15:57 lxc-shutdown is newer which is why i felt free to use sensible behavior :) 15:57 pitti: bundled unrar-nonfree is a release-critical bug (which is never late), but I want someone else to test it before upload 15:58 mitya57: hm, that's unfortunate; I was hoping we can eventually use the unrar program if it is installed, but not a biggie for the release indeed 15:59 (I never used calibre, so for example I don't know how it uses markdown/mathjax/etc) 15:59 pitti: my change makes it not build the python extension for unrar 16:00 mitya57: ok; I need to run away for a bit, but I'll get to it ASAP (first thing in the morning) 16:00 mitya57: yes, I know; I mean for a longer-term fix 16:00 the *only* way to avoid that is to move it to contrib/multiverse 16:00 pitti: if you have any comments/questions, please comment on the mp 16:00 stgraber: go ahead and mark it confirmed if you like.  I don't know if we should then just make lxc_stop.c use the API while we're at it... 16:02 hallyn: probably wouldn't be a bad idea, I'd kind of like all of those tools use the API instead of duplicating the code 16:03 hallyn: I'll update the meeting once I'm done with a meeting 16:03 but when will you update teh bug :) 16:03 j/k 16:03 === doko_ is now known as doko hallyn: ;) 16:05 === deryck is now known as deryck[lunch] cjwatson: has the installer fix already been verified? 17:06 jtaylor: not yet 17:06 Well, not with the actual images 17:07 should I try it on a image from yesterday (patching it myself) or wait until we have a ready image? 17:08 oh well I guess I can do both brb 17:10 === mmrazik is now known as mmrazik|afk cjwatson: works thx 17:20 funnily I tried to play with those descriptors yesterday, but only removed them from mount instead of adding them to grub-mount :) 17:20 I should probably read up on what that actually does :) 17:21 there should be a ready image now 17:22 the current daily? 17:22 yeah 17:22 in the mount case it only matters if mount happens to spawn a fuse process, i.e. ntfs-3g in practice 17:22 current> Ubuntu desktop 20130423.1 17:23 in the grub-mount case, it's always fuse 17:23 I'll load it and try it later 17:23 the problem is that that involves a process in the background and any fds from the parent that aren't close-on-exec (which they typically aren't from shell) get inherited 17:23 3 is debconf, 6/7 are parted_server 17:24 if we need to read all output from an fd, that blocks until all processes that have the other end open for writing have closed it 17:24 hence this deadlock 17:24 once I noticed the structure of the problem I recognised it because I've fixed it before :) 17:25 [5~/wg 34 17:26 oops 17:26 === deryck[lunch] is now known as deryck stgraber: howdy! So I have a couple fixes i'd like to get in in MAAS, but these are not required for the CD, so they would be for 0-day SRU. Should I upload now and specify they are for this purpose so they remain in the queue and are taken care of once we release raring (the fixes are mainly improvements that fix issues in corner cases that we found when running automated tests) 18:08 roaksoax: yep, just upload. We'll have someone that has both release and SRU hats do the review and accept it into raring-proposed. Then if we need to respin we may decide to include it anyway, otherwise it's going as 0-day SRU. 18:10 stgraber: ok awesome. TBH, don't think this requires a re-spin because doesn't really break maas or make it unusable, we just want to make sure that these corner cases don't affect users in the long run. 18:13 roaksoax: yep, that's why we usually keep those around as things to include if we need to respin for something else (our "nice to have" list) 18:14 stgraber: oh ok!! cool :) 18:14 Install of  13.03 from this iso http://releases.ubuntu.com/13.04/ubuntu-13.04-beta2-desktop-i386.iso  gksu is not installed.  Is this a bug or a deliberate change? 18:27 If not a bug why was gksu removed 18:27 could you avoid spanning that question across all ubuntu channels ? 18:28 oh 18:28 sorry, i see jtaylor pointed you here 18:28 warren-hill: as I understand, pkexec is more flexible and The Preferred Mechanism 18:29 I though it was a valid question 18:29 http://cdimage.ubuntu.com/daily-live/current/raring-desktop-i386.manifest shows gksu is installed 18:29 I'm concerned gksu is very useful gksu gedit path_to_file is much easier than pkexec 18:29 same for amd64 18:29 sarnold, it is and it would be good to drop gksu ... but there are issues with pkexec ... you need to export a lot of stuff 18:30 The beta I installed last night does not have gksu 18:30 well, the current image surely does ... as you can see in the manifest 18:33 I'm happy to tell people to use pkexec but there are a lot of questions on Ask Ubuntu or Launchpad which ask users to use gksu and to be honest I don't know to use it. 18:33 the beta manifest lists it too 18:33 warren-hill: can you try a current daily image? 18:33 yeah, would be news that it was dropped 18:33 * ogra_ was actually looking into dropping it at the beginning of the cycle ... since it breaks touch input completely 18:34 but we cant yet 18:34 I't will take some time but I can update my test machine and try   Where do I find the latest 18:34 and nobody but me was pushing for it ... so it would be surprising if it wasnt there anymore 18:35 http://cdimage.ubuntu.com/daily-live/current/ 18:35 I almost forgot we had a release tomorrow 18:36 * vibhav puts on pary hat 18:36 downloading now I'll install on my test machine and get back to you when done.  May be tomorrow now 18:37 These 6 months were so quick :) 18:38 === cod3r is now known as baba I've just installed Raring i386 from today's daily build.  Not real hardware Virtual box on 12.04.2 host.  Still no gksu 19:00 If I type gksu in a terminal it tells me not found and how to install it "sudo apt-get install gksu" 19:03 file a bug? though not sure why gksu needs to be installed by default 19:03 It's the easiest way to run say for example "gksu gedit path_to_file" to edit a config file. 19:04 Which package should I file the bug against? 19:05 ubuntu-desktop i guess 19:05 funny, I've always thought 'sudo vim path_to_file' was easiest; it's also two fewer characters _and_ an editor I'm familiar with :) 19:05 which i think is ubuntu-meta for the source package 19:05 sarnold: and it doesn't open a separate window to ask for you password… 19:05 dobey: with all the fun of changing focus.. 19:06 sarnold: twice! 19:06 Like you I am happy with command line but many users on Launchpad and Ask Ubuntu are scared of it 19:06 hehe :) 19:06 IIRC, pkexec(1) is the preferred replacement for gksu/gksudo, as they (again, IIRC) do really ugly screen-scrapey things. 19:07 sbeattie: oh god, that sounds horrible 19:08 mdeslaur is the expert on that. 19:08 if that's the way those are implemented, he'd be in one heck of a stabby mood if I asked... seems best to avoid that. 19:09 warren-hill: i would generally avoid telling anytong to "edit this file as root" if they aren't comfortable enough with using sudo and vim to do it 19:10 warren-hill: because, they probably shouldn't be doing it 19:10 Most users on Launchpad and Ask Ubuntu would not have a clue with vim.  I have got some to s 19:12 use nano 19:12 similarly people use "gksu nautilus" to change ownership, permissions etc. 19:13 who is the victim of the day for asking why raring (fresh install) doesn't find my built-in speakers for output, but an upgrade from the dark ages to raring does? 19:14 warren-hill, well, http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntu/20130423.1/livecd-20130423.1-amd64.out clearly shows gksu is being installed 19:15 stgraber: i should upload to raring-proposed right? 19:15 (same ofr i386) 19:15 *for 19:15 === salem_ is now known as _salem ogra_: is that specific to the livecd images though? 19:16 === _salem is now known as salem_ * Laney boots a daily from today 19:16 roaksoax: doesn't matter, raring is always being rewritten to raring-proposed 19:17 sarnold, server has no X .... so no gksu 19:17 ogra_: is that the live image, or the actual install? 19:17 roaksoax: since we opened raring you can technically upload to "precise" and it'll end up in "precise-proposed". I know some have actually been doing that as they find the changelog entries prettier :) 19:17 dobey, thats the squashfs that gets copied by ubiquity 19:17 ogra_: ubiquty depends on gksu for some reason, which would explain that. but it's not installed to the system, so gksu wouldn't be either. 19:18 All I did was install to a fresh system, noticed some packages were removed as part of set up but did not see all names.  Then in a terminal typed "gksu" and it is not recognised I'm using i386 19:18 ubiquity-frontend-gksu depends on gksu, that is 19:18 err 19:18 -frontend-gtk 19:18 ah, that could be it 19:19 we dropped all gksu deps in the seeds 19:19 right, that's the only reason it's installed here 19:19 stgraber: hehe :) 19:19 so ... if you want to be able to use gksu, install it 19:19 though i suppose it's a bug that ubiquity requires gksu 19:20 that should probably get fixed, but i guess not a good time for that to happen in 13.04 19:21 So should I file a bug or get all the documentation pages such as this one https://help.ubuntu.com/community/RootSudo updated to tell people to install it? 19:24 Just installed gksu on my test system -- it works 19:25 well, better have the docs say to use sudo instead of gksu 19:25 There is a difference between sudo and gksu and that document specifically advises against using sudo with graphical programs 19:26 I'm not a developer: I just want to make sure we give the best advice on forums and websites 19:28 sudo su -c $program 19:28 or sudo -i 19:28 yeah, or that 19:29 so the advice to use gksu is outdated? 19:29 * jtaylor was also told don't use gksu for guis or bad things will happen 19:29 *sudo 19:30 sudo -i will work 19:30 So I should advise that while gksu can be installed in 13.03 its no longer preferred and to use sudo i or sudo su -c$program 19:30 and plain sudo as well if you know what you are doing 19:30 (i.e. no such insanities like sudo nautilus) 19:30 jtaylor: eh. depends on the app. but the ones that write data under ~/ can cause problems by changing ownership of files to root in some cases 19:30 warren-hill, right 19:31 OK I'll update this question http://askubuntu.com/questions/284306/why-is-gksu-no-longer-installed-by-default and pass the info onto the documentation team 19:32 The Xauthority and ~ arguments are still valid, AFAIK. 19:34 Honestly, telling people to run GUI apps as root was always the wrong answer, though. 19:34 infinity, yeah its more for people doing sudo nautilus ... 19:34 people will continue to do so until Nautilus supports policykit 19:35 infinity: indeed 19:35 or whatever the new thing is 19:35 jcastro: or we stop shipping nautilus? :) 19:35 lol 19:35 stgraber: uploaded! thanks! 19:42 for the input 19:42 guys, have a quick look at my answer herehttp://askubuntu.com/a/284717/107450 just to make sure you are happy before I pass this information onto the other forums and the web page guys.  Let me know if you agree with what I have said 19:57 warren-hill: i'd remove the bit about "sudo su -c" and just use "sudo -i \$program" instead, rather than telling them how to use the shell as root 20:00 OK done.  Thanks for your help I'll pass this on to the Ubuntu documentation team, Ubuntu Forum and Launchpad 20:02 === Sweetsha1k is now known as Sweetshark === glebihan_ is now known as glebihan === salem_ is now known as _salem === broder_ is now known as broder === Nisstyre-laptop is now known as Nisstyre === kentb is now known as kentb-out === Quintasan_ is now known as Quintasan === wedgwood is now known as wedgwood_away

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!