=== wedgwood is now known as wedgwood_away
[02:06] <mwhudson> are there netinstall images for installing raring on highbank around anywhere?
[02:11] <mwhudson> http://ports.ubuntu.com/dists/raring/main/installer-armhf/current/images/generic/netboot/ looks promising
[02:11] <vanhoof> mwhudson: ack
[02:12] <mwhudson> rarara why do netinstalls have to take so long
[02:13] <StevenK> Because you're in NZ? :-P
[02:13] <mwhudson> the server i'm installing isn't
[02:14] <StevenK> ... details
[02:15] <vanhoof> mwhudson: only remaining oddity is https://bugs.launchpad.net/bugs/1171582
[02:15] <ubottu> Launchpad bug 1171582 in linux (Ubuntu) "[highbank] hvc0 getty causes random hangs" [High,Incomplete]
[02:15] <vanhoof> mwhudson: but yeah installs are good now w/ the flash-kernel update today
[02:26] <[reed]> how was one nominate a bug as a potential raring blocker? (or if not blocker, fix ASAP)
[02:26] <[reed]> s/was/does/
[02:35] <RAOF> [reed]: What bug?
[02:35] <[reed]> 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] <ubottu> Launchpad bug 1108056 in pidgin (Ubuntu) "fetching URLs freezes pidgin" [Undecided,Confirmed]
[02:36] <[reed]> there's a debdiff already posted with a fix
[02:36] <RAOF> That's not a raring blocker.
[02:36] <[reed]> it's seeded in lubuntu
[02:37] <RAOF> 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] <RAOF> That looks like it's a fine category for an SRU, though, which only requires someone to upload that debdiff.
[02:38] <StevenK> RAOF: The reporters aren't going to be any position to file that one ...
[02:38] <RAOF> StevenK: THAT'S THE BEAUTY OF IT!
[02:38] <StevenK> Haha
[02:38] <[reed]> RAOF: perhaps you'd like to upload it? :P
[02:42] <dtchen> [reed]: uploaded, but someone will need to reformat the bug description section according to SRU guidelines
[02:43] <dtchen> ...which I'll do in 12 hours if someone doesn't beat me to it within 12 hours.
[02:45] <[reed]> dtchen: thanks!
[03:38] <pitti> Good morning
[03:41] <pitti> ScottK: you mean merely installing bcmwl-kernel-source makes it work at instant?
[03:41] <ScottK> pitti: Yes.
[03:42] <pitti> 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] <ScottK> sudo apt-get install bcmwl-kernel-source and wait while it does it's magic is enough.
[03:42] <pitti> ah, so it does
[03:43] <pitti> I guess we did that for the migration to ubuntu-drivers-common, but never adjusted the old jockey handler
[03:43] <ScottK> I attempted to make it not do the bind/unbind, but didn't seem to be able to manage it.
[03:43] <pitti> ScottK: I'll upload a fix now
[03:43] <ScottK> pitti: Great.  Thanks.
[03:55] <pitti> 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:56] <pitti> I was checking whether we should completely skip the KernelModuleHandler.enable() bits, but we need some of them
[03:56] <pitti> so that's the simplest fix which only suppresses the rebinding
[03:57] <ScottK> I already tried that particular change and it still did the rebind somewhere.
[03:57] <pitti> uh?
[03:57] <ScottK> That's what I said.
[03:58] <pitti> right, I interpreted "I attempted to make it not do the bind/unbind" as "I didn't know how to do that"
[03:58] <pitti> we use the very same approach in the nvidia handler
[03:59] <ScottK> I'm assuming that the segfault in the bug can only come from an attempt to unbind/rebind.
[03:59] <pitti> correct
[03:59] <pitti> unless the driver internally calls any of those on loading/unloading
[04:00] <pitti> it seems the wl driver doesn't really like to be unloaded, too
[04:00] <ScottK> Except if it did that, you'd think just installing the package would cause a failure.
[04:00] <pitti> i. e. if you try loading/unloading it twice in the same session it might do the same?
[04:01] <pitti> booting a live session, applying that change, and enabling wl in jockey should not do any module unloading or rebinding
[04:02] <ScottK> Let me try it again.
[04:02] <pitti> ScottK: also, it's important to set self._do_rebind = False after the KernelModuleHandler.__init__ call
[04:05] <ScottK> I already started it.
[04:06] <ScottK> And it died.
[04:06] <pitti> so I suppose the rmmodding/modprobing in jockey is bad as well, as the postinst duplicates it
[04:07]  * pitti does V2
[04:08] <ScottK> You may be able to make V2 faster than my system boots.
[04:09] <pitti> ScottK: can I give you a proposed broadcom_wl.py file on people.u.c. for testing?
[04:09] <ScottK> I don't have network on the system, so a diff is easier.
[04:10] <ScottK> Hopefully it's not large.
[04:10] <ScottK> If I have to, I can copy it onto my USB stick and boot the live system again.
[04:11] <pitti> it's not that large
[04:13] <pitti> ScottK: http://paste.ubuntu.com/5594596/
[04:13] <pitti> ScottK: quite hackish, but *shrug*
[04:14] <ScottK> Should be the last cycle for jockey ...
[04:14] <pitti> ah, is Kubuntu moving to u-d-common?
[04:15] <pitti> it shouldn't even be too hard to port the jockey UI to use u-d-common
[04:19] <ScottK> Running
[04:19] <ScottK> I hope so.  We had some python3/KCM integration issues that blocked us most of the cycle.
[04:19] <ScottK> Resolved now, but too late to do anything in raring.
[04:20] <cjwatson> lifeless: oh, not sure, call it a megabyte maybe?
[04:20] <ScottK> pitti: Still crapped out.
[04:20] <pitti> ScottK: u-d-common works with py2 as well, BTW
[04:21] <pitti> ScottK: urgh, what now; exact same dmesg?
[04:21] <ScottK> Yes.  Exact same.
[04:21] <ScottK> Interesting.  I don't think we realized that.
[04:21] <pitti> ScottK: or could it perhaps be that jockey-backend was already running when you applied the change?
[04:21] <ScottK> Not unless it runs automatically on boot.
[04:21] <pitti> 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:22] <ScottK> Sure.
[04:22] <ScottK> Let me restart
[04:22] <pitti> thanks
=== salem_ is now known as _salem
[04:26] <ScottK> That's it.  It's running already.
[04:26] <ScottK> Sigh.
[04:28] <ScottK> pitti: Which fix to you want me to retry?
[04:28] <pitti> ScottK: the latter is more comprehensive
[04:28] <pitti> ScottK: it also avoids duplicate unloading/reloading, which it seems we should better avoid
[04:28] <ScottK> ok
[04:28] <pitti> ScottK: you can just kill it, it'll respawn from dbus
[04:29] <pitti> (it also times out after 10 mins or so)
[04:32] <ScottK> Running
[04:33] <ScottK> pitti: worked.
[04:33] <pitti> \o/
[04:33] <pitti> thanks for your patience
[04:33] <ScottK> I'll be glad to review/accept that one.
[04:34] <pitti> uploaded
[04:34] <ScottK> 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] <ScottK> Excellent.
=== rsalveti_ is now known as rsalveti
[05:57] <mlankhorst> morning
[06:36] <dholbach> asac, happy birthday! :)
[06:41] <dholbach> good morning
=== 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
[09:17] <mitya57> Mirv: did you see my qtbase merge? I've just rebased it on 5.0.2+dfsg1-3
=== ckpringle_ is now known as ckpringle
=== amitk-afk is now known as amitk
[09:24] <asac> dholbach: :)
[09:24] <asac> thx
[09:45] <mitya57> Mirv: and I have yet another Vcs fields fix for you: http://paste.ubuntu.com/5595113/
[09:48] <Mirv> mitya57: looks excellent, thanks. I was hesitating another resync because we shuffled with the some options, but it should be fine now
[09:48] <Mirv> mitya57: I'll also take that qttools one
[09:54] <mitya57> Mirv: we'll be able to sync all qt5 packages (except qtbase) when S opens, right?
[09:54] <mitya57> or do we have any delta?
[09:56] <cjwatson> mitya57: thanks for spotting and syncing perl 5.14.2-21 last week
[09:56] <cjwatson> I noticed that when upgrading a wheezy system this morning and went to check whether we'd picked it up for raring ...
[09:57] <Mirv> 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
=== ara is now known as Guest91539
[09:58] <Mirv> mitya57: but for many modules a straight-forward sync would be all that is needed
[09:58] <pitti> 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] <mitya57> cjwatson: I always look at upgrade logs of my sid system and file SRs for ubuntu-relevant fixes :)
[09:59] <pitti> 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?
[10:02] <mitya57> Mirv: thanks
[10:02] <Mirv> mitya57: thanks to you
=== 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
[11:17] <stgraber> jodh: having any luck with that upstart bug?
[11:42] <lool> pitti: I'd suggest marking the WIs as postponed for r and copy-pasting them as TODO for S
[11:58] <pitti> lool: so into a new BP then?
[11:58] <lool> pitti: yeah; does that make sense?
[11:58] <pitti> lool: sure
=== MacSlow|lunch is now known as MacSlow
=== highvolt1ge is now known as highvoltage
[12:05] <jodh> stgraber: not really - if you've got spare cycles and want to get involved, let me know.
[12:07] <stgraber> jodh: starting an ISO install and then I can take a look.
=== 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
[12:45] <dholbach> lool, rsalveti, sforshee: ready for in 15m?
[12:47] <mlankhorst> ooh fun, 3.5 kernel won't boot on 32-bits for me :>
=== cod3r is now known as Guest34392
[12:53] <mlankhorst> oh right, probably need pae kernel
[12:57] <lool> dholbach: yup
[12:58] <leighman> 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] <ubottu> 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] <leighman> *no idea how translation works*
=== ckpringle_ is now known as ckpringle
[13:03] <pitti> 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] <ubottu> bug 1171691 in systemd (Ubuntu Raring) "Removing libpam-systemd (without purge) breaks system" [Medium,Fix released] https://launchpad.net/bugs/1171691
[13:04] <pitti> i. e. we need to respin now?
[13:10] <cjwatson> pitti: we needed to respin anyway for bug 1080701
[13:10] <ubottu> 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] <cjwatson> pitti: and infinity and I reckoned that the consequences of your bug were serious enough that they were worth riding along
[13:11] <cjwatson> so I manually unblocked systemd
[13:12] <cjwatson> or actually Adam did
[13:20] <pitti> cjwatson: thanks for confirming
=== amitk-afk is now known as amitk
[13:55] <stgraber> smoser: ping
[13:57] <smoser> stgraber, here
=== wedgwood_away is now known as wedgwood
[14:03] <stgraber> 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:04] <smoser> rm -Rf /var/lib/cloud will do it.
[14:05] <smoser> 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] <smoser> but i often do the 'rm -Rf /var/lib/cloud && rm -Rf /var/log/cloud-init* && reboot'
[14:06] <stgraber> smoser: then I need to manually copy the cloud config file right?
[14:07] <smoser> ?
[14:07] <stgraber> the userdata file
=== jbicha_ is now known as jbicha
[14:09] <smoser> stgraber, you were using nocloud i guess?
[14:09] <smoser> ah. or you were doing lxc (which uses nocloud)
[14:09] <smoser> yes, you do have to avoid rm'ing the /var/lib/cloud/data/seed path.
[14:10] <smoser> (that is somewhat annoying)
[14:11] <stgraber> ok, good, looks like it's working
[14:19] <stgraber> 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:20] <stgraber> 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:24] <mpt> 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:32] <tedg> jodh, Is there a library to emit upstart events?  Or does everyone just shell out to initctl?
[14:33] <cjwatson> you can just prod dbus
[14:34] <tedg> Yeah, that's what I was thinking.  But curious if someone already wrapped that :-)
[14:34] <cjwatson> /com/ubuntu/Upstart com.ubuntu.Upstart0_6 EmitEvent
[14:34] <cjwatson> (the versioning there is a bit of a warning sign I guess)
[14:35] <tedg> 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] <cjwatson> True
=== 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
[15:39] <stgraber> 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] <ubottu> bug 1171866 in lxc (Ubuntu) "lxc-stop ignores invalid container names" [Undecided,Invalid] https://launchpad.net/bugs/1171866
[15:40] <stgraber> that'd cover the case of a non-existing container at least
[15:40] <stgraber> or maybe: if we can't connect to the socket and the container isn't defined => container doesn't exist
[15:40] <stgraber> if we can't connect to the socket and the container is defined => container isn't started
[15:41] <bdmurray> barry: could you have a look at bug 1051935 again? somebody has a couple of branches for it - maybe something for S
[15:41] <ubottu> bug 1051935 in python-apt (Ubuntu) "Fails with SystemError when too many files are open" [Medium,Triaged] https://launchpad.net/bugs/1051935
[15:42] <barry> bdmurray: no time right now, but it's in a browser tab ;)
[15:42] <bdmurray> barry: sounds good, thanks
[15:47] <mitya57> pitti: is there any chance you'll merge my calibre changes in time for raring?
[15:48] <hallyn> stgraber: what does it mean for the container to be defined?
[15:48] <pitti> mitya57: ah, you updated that, indeed; sorry for the delay!
[15:50] <pitti> mitya57: what is the preinst snippet about? (removing /usr/share/calibre/viewer/mathjax)
[15:50] <mitya57> 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:51] <pitti> mitya57: oh, I just saw the corresponding line in debian/rules
[15:52] <stgraber> hallyn: directory exists in the config dir (/var/lib/lxc)
[15:52] <hallyn> stgraber: i'm not entirely opposed though.
[15:52] <mitya57> "! -h" checks (I hope) that it's argument is not a symlink
[15:52] <hallyn> it's just the conatiner not being 'defined' is not technically an error
[15:53] <hallyn> so we'd be introducing different behavior for 'permanent' contaienrs and 'temporary' ones on lxc-stop when already stopped
[15:53] <mitya57> 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] <pitti> mitya57: right, thanks
[15:54] <pitti> mitya57: yeah, I was going to ask -- shouldn't the sed cover the bit what the patch does, too?
[15:54] <stgraber> 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:55] <mitya57> pitti: sed is called after the package is built, and touches already installed files
[15:55] <pitti> mitya57: so that particular piece of code is run during build then
[15:55] <mitya57> yes
[15:55] <pitti> alright, thanks!
[15:55] <hallyn> 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:56] <pitti> mitya57: if you want, you can already upload that to Ubuntu
[15:56] <pitti> mitya57: I'll do a new Debian upload with a newer upstream version
[15:56] <lamont> 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] <pitti> (but I guess that's too late for the freeze now)
[15:56] <stgraber> hallyn: right and I'd expect freeze/unfreeze to do that too. I believe we already do something like that in lxc-shutdown
[15:57] <stgraber> hallyn: (would be great if we could make that kind of thing consistent for 1.0 ;))
[15:57] <mitya57> 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] <hallyn> lxc-shutdown is newer which is why i felt free to use sensible behavior :)
[15:58] <mitya57> pitti: bundled unrar-nonfree is a release-critical bug (which is never late), but I want someone else to test it before upload
[15:59] <pitti> 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] <mitya57> (I never used calibre, so for example I don't know how it uses markdown/mathjax/etc)
[16:00] <mitya57> pitti: my change makes it not build the python extension for unrar
[16:00] <pitti> mitya57: ok; I need to run away for a bit, but I'll get to it ASAP (first thing in the morning)
[16:00] <pitti> mitya57: yes, I know; I mean for a longer-term fix
[16:00] <mitya57> the *only* way to avoid that is to move it to contrib/multiverse
[16:00] <mitya57> pitti: if you have any comments/questions, please comment on the mp
[16:02] <hallyn> 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:03] <stgraber> 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] <stgraber> hallyn: I'll update the meeting once I'm done with a meeting
[16:03] <hallyn> but when will you update teh bug :)
[16:03] <hallyn> j/k
=== doko_ is now known as doko
[16:05] <stgraber> hallyn: ;)
=== deryck is now known as deryck[lunch]
[17:06] <jtaylor> cjwatson: has the installer fix already been verified?
[17:06] <cjwatson> jtaylor: not yet
[17:07] <cjwatson> Well, not with the actual images
[17:08] <jtaylor> should I try it on a image from yesterday (patching it myself) or wait until we have a ready image?
[17:10] <jtaylor> oh well I guess I can do both brb
=== mmrazik is now known as mmrazik|afk
[17:20] <jtaylor> cjwatson: works thx
[17:20] <jtaylor> funnily I tried to play with those descriptors yesterday, but only removed them from mount instead of adding them to grub-mount :)
[17:21] <jtaylor> I should probably read up on what that actually does :)
[17:22] <cjwatson> there should be a ready image now
[17:22] <jtaylor> the current daily?
[17:22] <cjwatson> yeah
[17:22] <cjwatson> in the mount case it only matters if mount happens to spawn a fuse process, i.e. ntfs-3g in practice
[17:23] <cjwatson> current> Ubuntu desktop 20130423.1
[17:23] <cjwatson> in the grub-mount case, it's always fuse
[17:23] <jtaylor> I'll load it and try it later
[17:23] <cjwatson> 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:24] <cjwatson> 3 is debconf, 6/7 are parted_server
[17:24] <cjwatson> 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] <cjwatson> hence this deadlock
[17:25] <cjwatson> once I noticed the structure of the problem I recognised it because I've fixed it before :)
[17:26] <cjwatson> [5~/wg 34
[17:26] <cjwatson> oops
=== deryck[lunch] is now known as deryck
[18:08] <roaksoax> 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:10] <stgraber> 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:13] <roaksoax> 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:14] <stgraber> 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] <roaksoax> stgraber: oh ok!! cool :)
[18:27] <warren-hill> 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] <warren-hill> If not a bug why was gksu removed
[18:28] <ogra_> could you avoid spanning that question across all ubuntu channels ?
[18:28] <ogra_> oh
[18:28] <ogra_> sorry, i see jtaylor pointed you here
[18:29] <sarnold> warren-hill: as I understand, pkexec is more flexible and The Preferred Mechanism
[18:29] <jtaylor> I though it was a valid question
[18:29] <ogra_> http://cdimage.ubuntu.com/daily-live/current/raring-desktop-i386.manifest shows gksu is installed
[18:29] <warren-hill> I'm concerned gksu is very useful gksu gedit path_to_file is much easier than pkexec
[18:29] <ogra_> same for amd64
[18:30] <ogra_> 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] <warren-hill> The beta I installed last night does not have gksu
[18:33] <ogra_> well, the current image surely does ... as you can see in the manifest
[18:33] <warren-hill> 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] <jtaylor> the beta manifest lists it too
[18:33] <jtaylor> warren-hill: can you try a current daily image?
[18:33] <ogra_> yeah, would be news that it was dropped
[18:34]  * ogra_ was actually looking into dropping it at the beginning of the cycle ... since it breaks touch input completely
[18:34] <ogra_> but we cant yet
[18:34] <warren-hill> I't will take some time but I can update my test machine and try   Where do I find the latest
[18:35] <ogra_> and nobody but me was pushing for it ... so it would be surprising if it wasnt there anymore
[18:35] <ogra_> http://cdimage.ubuntu.com/daily-live/current/
[18:36] <vibhav> I almost forgot we had a release tomorrow
[18:36]  * vibhav puts on pary hat
[18:37] <warren-hill> downloading now I'll install on my test machine and get back to you when done.  May be tomorrow now
[18:38] <vibhav> These 6 months were so quick :)
=== cod3r is now known as baba
[19:00] <warren-hill> 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:03] <warren-hill> If I type gksu in a terminal it tells me not found and how to install it "sudo apt-get install gksu"
[19:03] <dobey> file a bug? though not sure why gksu needs to be installed by default
[19:04] <warren-hill> It's the easiest way to run say for example "gksu gedit path_to_file" to edit a config file.
[19:05] <warren-hill> Which package should I file the bug against?
[19:05] <dobey> ubuntu-desktop i guess
[19:05] <sarnold> 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] <dobey> which i think is ubuntu-meta for the source package
[19:05] <dobey> sarnold: and it doesn't open a separate window to ask for you password…
[19:06] <sarnold> dobey: with all the fun of changing focus..
[19:06] <dobey> sarnold: twice!
[19:06] <warren-hill> Like you I am happy with command line but many users on Launchpad and Ask Ubuntu are scared of it
[19:06] <sarnold> hehe :)
[19:07] <sbeattie> IIRC, pkexec(1) is the preferred replacement for gksu/gksudo, as they (again, IIRC) do really ugly screen-scrapey things.
[19:08] <sarnold> sbeattie: oh god, that sounds horrible
[19:08] <sbeattie> mdeslaur is the expert on that.
[19:09] <sarnold> 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:10] <dobey> 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] <dobey> warren-hill: because, they probably shouldn't be doing it
[19:12] <warren-hill> Most users on Launchpad and Ask Ubuntu would not have a clue with vim.  I have got some to s
[19:12] <warren-hill> use nano
[19:13] <warren-hill> similarly people use "gksu nautilus" to change ownership, permissions etc.
[19:14] <lamont> 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:15] <ogra_> 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] <roaksoax> stgraber: i should upload to raring-proposed right?
[19:15] <ogra_> (same ofr i386)
[19:15] <ogra_> *for
=== salem_ is now known as _salem
[19:16] <sarnold> ogra_: is that specific to the livecd images though?
=== _salem is now known as salem_
[19:16]  * Laney boots a daily from today
[19:17] <stgraber> roaksoax: doesn't matter, raring is always being rewritten to raring-proposed
[19:17] <ogra_> sarnold, server has no X .... so no gksu
[19:17] <dobey> ogra_: is that the live image, or the actual install?
[19:17] <stgraber> 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] <ogra_> dobey, thats the squashfs that gets copied by ubiquity
[19:18] <dobey> 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] <warren-hill> 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] <dobey> ubiquity-frontend-gksu depends on gksu, that is
[19:18] <dobey> err
[19:18] <dobey> -frontend-gtk
[19:19] <ogra_> ah, that could be it
[19:19] <ogra_> we dropped all gksu deps in the seeds
[19:19] <Laney> right, that's the only reason it's installed here
[19:19] <roaksoax> stgraber: hehe :)
[19:19] <Laney> so ... if you want to be able to use gksu, install it
[19:20] <dobey> though i suppose it's a bug that ubiquity requires gksu
[19:21] <dobey> that should probably get fixed, but i guess not a good time for that to happen in 13.04
[19:24] <warren-hill> 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:25] <warren-hill> Just installed gksu on my test system -- it works
[19:25] <ogra_> well, better have the docs say to use sudo instead of gksu
[19:26] <warren-hill> There is a difference between sudo and gksu and that document specifically advises against using sudo with graphical programs
[19:28] <warren-hill> I'm not a developer: I just want to make sure we give the best advice on forums and websites
[19:28] <dobey> sudo su -c $program
[19:28] <ogra_> or sudo -i
[19:29] <dobey> yeah, or that
[19:29] <jtaylor> 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:30] <jtaylor> *sudo
[19:30] <ogra_> sudo -i will work
[19:30] <warren-hill> 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] <ogra_> and plain sudo as well if you know what you are doing
[19:30] <ogra_> (i.e. no such insanities like sudo nautilus)
[19:30] <dobey> 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:31] <ogra_> warren-hill, right
[19:32] <warren-hill> 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:34] <infinity> The Xauthority and ~ arguments are still valid, AFAIK.
[19:34] <infinity> Honestly, telling people to run GUI apps as root was always the wrong answer, though.
[19:34] <ogra_> infinity, yeah its more for people doing sudo nautilus ...
[19:35] <jcastro> people will continue to do so until Nautilus supports policykit
[19:35] <dobey> infinity: indeed
[19:35] <jcastro> or whatever the new thing is
[19:35] <dobey> jcastro: or we stop shipping nautilus? :)
[19:35] <ogra_> lol
[19:42] <roaksoax> stgraber: uploaded! thanks!
[19:42] <roaksoax> for the input
[19:57] <warren-hill> 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
[20:00] <dobey> 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:02] <warren-hill> OK done.  Thanks for your help I'll pass this on to the Ubuntu documentation team, Ubuntu Forum and Launchpad
=== 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