[00:20] <blitzkrieg3> does anyone know a new version of phb crystal ball?
[05:26] <pitti> Good morning
[06:24] <dholbach> good morning
[07:50] <pitti> cjwatson: to follow the tradition we will wait until you do the vim upload, to get your #1 place in saucy/+queue :-)
[07:51] <pitti> oh noes, seems infinity already broke that and uploaded vim in raring
[07:56]  * geser tries to get vim (from experimental) merged over the weekend
[08:03] <geser> is the mailing list title for saucy-changes on purpose? :) (see https://lists.ubuntu.com/mailman/listinfo/Saucy-changes and compare it with e.g. raring-changes)
[08:23] <sunweaver> dbarth: morning!!! I sent some merge requests last night (remote-login-service, unity-greeter). If you have any questions contact me via IRC. Thanks
[09:19] <dbarth> sunweaver: ok, seen it; will review next week during our sprint
[10:20] <ogra_> gah
[10:21] <ogra_> so i upgraded to raring final and my chromebook doesnt boot anymore :(
[10:24] <xnox> ogra_: I think you want to talk to ogra on #ubuntu-arm =)
[10:24] <ogra_> haha
[10:25] <ogra_> he ignores me !
[10:25] <Nafallo> ogra_: clever guy :-)
[10:31] <rbasak> Hmm. I haven't upgraded to raring final yet, though I've got everything on --download-only already. Perhaps I should hold off a bit? Or clone my SD card and try and narrow it down?
[10:31] <rbasak> Thanks for the warning :)
[10:31]  * mpt misses mvo
[10:42] <ogra_> rbasak, well, i use the preinstalled chromeos kernel ... i fear upstart grew some requirements that one cant fulfill :/
[10:43] <rbasak> I'm using the chromeos kernel too. THanks for the warning - I'll experiment when I get round to it
[10:44] <ogra_> i couldnt use the kbd anymore ... USB kbd works
[10:44] <ogra_> and modemmmanager as well as NM respawn until they die
[10:45] <ogra_> X doesnt start either ...
[10:45] <sunweaver> dbarth: awesome.
[10:45] <xnox> ogra_: upstart didn't grow anything in the default install. but i guess pr_ctl call is compiled in. What kernel is chromeos one?
[10:45] <rbasak> Sounds pretty severe
[10:45] <ogra_> 3.4.0
[10:46] <ogra_> well, i wonder if i didnt get a full upgrade yet
[10:46] <rbasak> I'm using Linux chromebook 3.4.0 #1 SMP Sat Nov 24 23:10:02 PST 2012 armv7l armv7l armv7l GNU/Linux on mine, but AIUI there is a newer build (same base version though)
[10:46] <sunweaver> in the process of reviewing, please contact me on any question that comes up. I have a focussed disposition on getting X2Go remote-login support into saucy (and finally into the next LTS).
[10:46] <sunweaver> dbarth: ^^^
[11:46] <ogra_> rbasak, so i had the phablet ppa in my sources ... seems there was the whole of unity touch added to it the last days ... thats what broke it... if you dont have it you should be safe to upgrade
[12:03] <kaleo> didrocks: do you know who is the bamf expert? trevinho?
[12:09] <didrocks> kaleo: yeah, he's the right guy to poke about it :)
[12:09] <kaleo> didrocks: what's his nick
[12:10] <kaleo> Trevinho
[12:10] <kaleo> :)
[12:10] <didrocks> kaleo: yep ;)
[12:10] <didrocks> kaleo: you can catch him on #ubuntu-unity as well FYI
[12:14] <kaleo> thx
[12:38] <rbasak> ogra_: got it. Thanks!
[12:47] <caribou> what is the best course of action to get a fix present in Quantal into precise-updates ?
[12:47] <caribou> for a fairly small package (i.e. cifs-utils)
[12:48] <caribou> doing mount -o remount {cifs share} {mountpoint} adds a shadow entry in /etc/mtab so it appears mounted twice
[12:48] <caribou> lp: #1144612
[12:51] <seb128> caribou, do a SRU for it?
[12:51] <seb128> caribou, not sure to understand the question ;-)
[12:51] <xnox> caribou: please complete the template on the bug description as per: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
[12:51] <caribou> seb128: yeah; I meant is it better to get the whole version present in Q (i.e. cifs-util 5.5.1) or just SRU the single patch that fixes the issue
[12:52] <seb128> caribou, the smaller the diff the better
[12:52] <xnox> caribou: single patch, as small as possible.
[12:52] <caribou> seb128: xnox: ok, I'll work on it & hopefully can backport that single commit
[12:52] <xnox> caribou: editing the bug description with a testcase is small and first step.
[12:53] <caribou> xnox: it's in my last comment on the bug
[12:53] <xnox> caribou: that way you or anyone else can work on patch and it will be easy sailing from there.
[12:53] <caribou> xnox: but I'll add it in the SRU template for better visibility
[12:53] <xnox> caribou: bug description that is =) don't edit the template ;-)
[12:54] <caribou> xnox: yep :)
[12:54] <caribou> xnox: I got a clipper note for the SRU template
[12:57] <caribou> xnox: seb128 thanks for the inf
[12:57] <caribou> s/inf/info
[13:36]  * ogra_ wonders if the guy asking for developer inteviews will be done with cross posting to all possible lists on lists.ubuntu.com at any point 
[13:50]  * xnox ponders how i got into juju charm authors =)
[13:54] <mardy> seb128: hi! I wrote a message this morning to the ubuntu-devel ML, but it's still waiting for moderation
[13:54] <mardy> seb128: it was about libproxy: Qt 5.1 it will most likely depend on it
[13:55] <mardy> seb128: so maybe if there are issues, it's better to try to fix them in libproxy itself
[13:55] <seb128> mardy, hey, I saw your message
[13:55] <mardy> seb128: ah, OK, I thought it was still waiting
[13:56] <seb128> mardy, it's not, I read it this morning
[13:58] <GridCube> tedg, hi, could i bother you in pm for a moment?
[13:59] <tedg> GridCube, Sure, or you can bother me here :-)
[13:59] <GridCube> :) ok, hi
[14:56] <bdmurray> infinity: do you have any ideas about bug 1105137?
[14:58] <infinity> bdmurray: Haven't had a chance to have ideas.  But my maintainer scripts check for desktop upgrade modes.  Did update-manager regress?
[14:58] <bdmurray> infinity: not from what I can tell RELEASE_UPGRADE_MODE is set to desktop
[15:00] <bdmurray> infinity: I added some details to the bug
[15:03] <infinity> bdmurray: Hrm.  Curious.
[15:15] <ev> bdmurray: hm, https://errors.ubuntu.com/api/1.0/package-version-new-buckets/?package=ubiquity&previous_version=2.12.14&new_version=2.14.6&format=json doesn't return anything though.
[15:17] <bdmurray> ev: hmm, I'll have a look in a bit.  I noticed some false positives with jockey and 0.9.7-0ubuntu7.7 vs ubuntu7.8
[15:18] <ev> bdmurray: cool, thanks
[15:19] <ev> added the results of that run to the bottom of https://wiki.ubuntu.com/ErrorTracker/CassandraQueries, so we're keeping track of how fast these things are and saving ourselves from having to dig through old RT emails when trying to estimate/optimise.
[15:21] <bdmurray> jamespage: you might want to have a look at bug 1173240
[15:34] <jodh> smoser: your Friday treat - https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1124384/comments/15
[15:35] <jamespage> bdmurray, well thats annoying
[15:36] <smoser> jodh, hooray
[15:36] <ev> mpt: remind me what colour you wanted for saucy? I hope it was a saucy one.
[15:40] <mpt> ev, continuing through the spectrum from green to blue to indigo, we arrive at ... ketchup
[15:40] <ev> lol
[15:40] <ev> and what's the hex code for a bottle of Heinz?
[15:41] <ev> (and its "by 12.04 standards" variant)
[15:42] <mpt> ev, roughly #d20700
[15:42] <bdmurray> I was hoping for brown sauce
[15:42] <ev> hahahaha
[15:42] <mpt> I'm not fussy
[15:43] <ScottK> Should be this color: http://theoatmeal.com/comics/sriracha
[15:46] <ev> Oh how I love The Oatmeal
[15:50] <ckpringle> irwed
[16:43] <Laney> bdrung: here?
[16:43] <bdrung> Laney: yes
[16:43] <Laney> bdrung: do you know what's up with this? http://paste.debian.net/467
[16:46] <bdrung> Laney: dch defaults to the current ubuntu devel release instead of hardcoding one. what do you want? do you want a different behaviour?
[16:46] <Laney> bdrung: no, I'm showing you that there's a difference between the installed executable and the script in the source package
[16:49] <bdrung> Laney: the first hunk is deliberately, let me check the other two
[16:50] <bdrung> Laney: the other two are deliberately, too. see in the Makefile:
[16:50] <bdrung> # On Ubuntu always default to targeting the release that it's run from,
[16:50] <bdrung> # not the current devel release, since its primary use on stable releases
[16:50] <bdrung> # will be for preparing PPA uploads.
[16:50] <bdrung> get_ubuntu_devel_distro() is only used on Debian
[16:51] <Laney> I see
[16:51] <Laney> that's an interesting way of making that change!
[16:52] <Laney> I don't think the comment is right - it's the release that it's built on, isn't it?
[16:53] <bdrung> yes, built on (not run from). i will change that
[16:54] <Laney> merci
[16:54] <Laney> bdrung: or you could fix it to actually do what the comment says and then we won't have to do a no-change rebuild
[16:57] <borior> hey all. I'm just getting started with debuild and friends (and debian packaging more generally) and have a question: is there a way I can get the shlibs for some files put into my control file as "Suggests" rather than "Depends"?
[16:57] <borior> I'm building collectd, which has a few core binaries and then a bunch of plugins
[16:57] <bdrung> Laney: fix pushed. does a no-change rebuild that much?
[16:57] <bdrung> *hurt that much
[16:57] <Laney> Might as well save some CO2 if we can
[16:58] <xnox> borior: split them into multiple binary packages? collectd and collectd-plugins, collectd-plugins-extra ?
[16:58] <borior> I'd like the things the core binaries link against to be in "Depends", but things the plugins link against to be in "Suggests", as in the stock collectd-core package, but I'm not sure how to do that with dh/debuild. If someone can point me to the right docs that would be much appreciated.
[16:58] <xnox> borior: see other similar packages which do that, e.g. nagios & it's plugins.
[16:59] <xnox> borior: in general if you link against it & ship in the package and it's not in the depends, then it's a policy violation. You can really link against things and then downgrade them to suggests =)
[17:00] <borior> xnox: I could do that, but I'd pretty much need a package for every plugin, whereas just making the relevant shlibs "Suggests" solves my problem ...
[17:00] <borior> and it's what the ubuntu stock collectd-core does
[17:00] <infinity> borior: Short answer, you'd call dh_shlibdeps twice.  Once with a -X to exclude the plugins (see dh_shlibdeps(1)), and the second time with "-- -dshlibs:plugins" (see dpkg-shlibdeps(1)), and then put ${shlibs:plugins} in suggests in control.
[17:01] <borior> infinity: thank you very much, that's the bit I was missing
[17:01] <infinity> borior: I'd rather see people split plugins out and have proper deps, though.  Since suggesting libraries won't enforce installation and people will just be grumpy when the plugins don't load.
[17:01] <borior> infinity: okay, I'll look at that as a possibility
[17:01] <borior> this is an internal package only at the moment, though
[17:02] <borior> infinity, xnox: thanks for the help
[17:10] <xnox> infinity: interesting didn't know that trick.
[17:18] <bdmurray> ev: from what I can tell there are no buckets that were first reported about version 2.14.6 of ubiquity all the buckets were already known
[17:22] <slangasek> tedg: I don't suppose you'd like to generalize your apport hook for upstart user job logs, so that any package that contains any user jobs automatically gets any logs attached?
[17:23] <tedg> slangasek, Uhm, sounds cool.  Not sure quite how to do that thought.
[17:23] <tedg> Perhaps pitti could give pointers :-)
[17:23] <tedg> I think that the hook gets run based on the source package name.
[17:23] <xnox> i guess it should go into apport proper -> check package for user jobs & find and attach logs.
[17:23] <tedg> So I don't know how you'd have a hook that would work across all of them.
[17:24] <slangasek> the apport hook can query dpkg for the current package for a list of any files matching /usr/share/upstart/sessions/, then check for any corresponding files matching ~/.cache/upstart/$foo.log
[17:24] <xnox> to be honest that should be done for system pacakges as well, cause not many attach the upstart/job.log
[17:24] <slangasek> hmm, doesn't apport have the binary package name at some point?
[17:24] <slangasek> fwiw, /usr/share/apport/package-hooks/ is full of symlinks for binary package names
[17:24] <tedg> I'd imagine that it does, but I don't know that it exports it as a hook.
[17:25] <tedg> As xnox said, I think it'd have to be in apport proper.
[17:25] <slangasek> right, that's what I had in mind
[17:25] <tedg> I don't patch Python programs.  People always argue about style on Python patches.  I hate arguing over how many foreach's I should use.
[17:26]  * slangasek hehs
[17:26] <tedg> :-)
[17:26] <tedg> I don't see any issue with it, but considering the day and time, I'd probably just delay to ask pitti is thoughts next week.
[17:27] <tedg> his thoughts
[17:27] <slangasek> sure
[17:27] <slangasek> just wanted to plant the seed for discussion while I saw you :)
[17:27] <tedg> Heh, cool.  Sounds good.
[17:28] <tedg> Speaking of that, xnox we should talk about acc stuff next week too.  I know tvoss is interested.
[17:28] <dobey> hrmm, if updates require a restart, isn't the system indicator supposed to turn red and show that? update-manager just showed me the restart dialog, but indicator shows nothing about needing a reboot
[17:28] <seb128> tedg, slangasek: note that apport never attached ~/.xsession-errors to avoid sending "private datas", so that's smething we should think about
[17:28] <seb128> dobey, it is
[17:29] <seb128> tedg, slangasek: currently apport has a regexp and "grep" for specific knowing warnings (like the glib/gtk ones)
[17:29] <seb128> and just attach that
[17:29] <dobey> seb128: ok, thought so. guess i'll file a bug if it happens again next time there's an update that requires reboot
[17:29] <slangasek> seb128: why would private data be written to stderr, ever?
[17:30] <seb128> slangasek, define "private", some users consider their username to be private info ...
[17:30] <seb128> or path to files
[17:30] <seb128> or filenames
[17:30] <tedg> slangasek, Perhaps "Authenticating Facebook account 'bob.jones'" ?
[17:30] <slangasek> seb128: to me, the stronger rationale for not including .xsession-errors is "it's full of irrelevant garbage"
[17:30] <dobey> all data is private data
[17:30] <slangasek> well
[17:30] <dobey> and yeah, there is a lot of crap in .xsession-errors :(
[17:31] <tedg> seb128, But bugs with that data are private by default, right?
[17:31] <seb128> slangasek, well, between too much infos and not enough I lean toward the first one, at least it gives me a chance to find what I need
[17:31] <slangasek> given that users have the option to review the contents of the bug report before it's sent, I think they can at least make an informed decision
[17:31] <seb128> tedg, no
[17:31] <seb128> tedg, or pretty much every single bug would be private, seeing how much spamming we have in .xsession-errors
[17:31] <seb128> tedg, a good part being indicators btw ;-)
[17:31] <tedg> seb128, It'd be mostly stacktraces, no?
[17:31] <seb128> tedg, bugs with a dump are private yes
[17:31] <tedg> Heh, we're fixing that with upstart ;-)
[17:32] <seb128> bugs including ~/.xsession-errors errors are not
[17:32] <dobey> restarting indicators makes them not spew data?
[17:32] <slangasek> if they choose not to submit the bug report because it exposes filenames or such, chances are they're not going to be working with us to flesh out an actionable bug report anyway
[17:32]  * dobey runs pkill -9 indicator right now
[17:32] <slangasek> but in any event, I think this is premature optimization
[17:32] <tedg> But what other types of bugs use apport hooks besides stack traces and user initiated ones?
[17:33] <tedg> dobey, It does, but it'll be to the upstart logs here soonish.
[17:33] <seb128> slangasek, well, I'm not against adding the logs, I would have attached .xsession-errors by default before, I'm just saying "talk to pitti, he made apport not do that on purpose" ;-)
[17:33] <dobey> tedg: well, anyone can use ubuntu-bug to add data to a bug. so it doesn't have to only be at initial reporting time
[17:33] <slangasek> k :)
[17:33] <seb128> tedg, what bugs don't use apport?
[17:34] <tedg> seb128, Submitted on LP, no?
[17:34] <dobey> seb128: the ones where apport crashes because the hook uses something not available in python3 because the package only works on python2 ;)
[17:35] <seb128> hehe
[17:36] <tedg> Nobody important uses Python 2.
[17:36]  * slangasek high-fives tedg 
[17:36] <tedg> :-)
[17:36] <seb128> slangasek, "users have the option to review the contents of the bug report before it's sent" ... they do, but in practice there is so much information there that's impossible to review it
[17:36] <dobey> compiz (core) - Warn: this should never happen. you should probably file a bug about this.
[17:36] <dobey> those are my favorite ones
[17:36] <xnox> tedg: sure, talking about acc is always interesting =)
[17:37] <dobey> the "hey, there's a bug here!" in stderr/stdout
[17:37] <seb128> slangasek, and with whoopsie we made efforts to not expose technical details, sure there is a button you can click to get that suboptimal UI...
[17:37] <sarnold> .. and there's no way to elide specific bits of the report with that UI
[17:38] <seb128> tedg, btw
[17:38] <seb128> $ grep indicator dbus.log | wc -l
[17:38] <seb128> 2409
[17:38] <slangasek> seb128: I review this information before every bug report I submit
[17:38] <dobey> seb128: and even if users reviewed it, they may not even know they are giving up private data, because much of it can be quite technical and not easily understandable
[17:38] <seb128> slangasek, you have lot of spare time I can see :p
[17:39]  * seb128 hides
[17:39] <tedg> seb128, Yeah, I know.
[17:39] <dobey> it's also really hard to review some of it in the apport UI
[17:39] <slangasek> seb128: no, I just don't submit so many bugs anymore because you never fix them ;-)
[17:39] <seb128> ahah
[17:39] <dobey> because a 500 line stack trace in a single treeview cell is not fun
[17:39] <slangasek> seriously, it doesn't take me that long to review the list of attachments for things that are sensitive
[17:40] <seb128> slangasek, great to see that me not fixing bugs is a win for you ;-)
[17:40] <seb128> right
[17:40] <seb128> I just doubt non-technical users do that
[17:40] <seb128> Stacktrace.txt wouldn't speak to them, even if they would try
[17:40] <dobey> pretty sure they don't
[17:40] <slangasek> granted, not all users will do this or know how, but I think anyone who's actually worried about data leakage will
[17:40] <dobey> otherwise they wouldn't file bugs with private ppa passphrase hashes in them
[17:42] <slangasek> ... which was a bug in the apport hook which has been fixed
[17:42] <slangasek> I don't think it's a tall order to demand that software not spit confidential information out on stdout/stderr
[17:43] <dobey> slangasek: indeed. i'd consider it a critical bug for anything that does
[17:43] <seb128> slangasek, dobey: well, even in debug mode?
[17:44] <seb128> ted was considering turning debug mode on in the upstart job for indicators
[17:44] <seb128> to max out the debug infos in bug reports
[17:44] <slangasek> hm
[17:44] <slangasek> well in that case he was already planning to attach that info :)
[17:44] <slangasek> so it's orthogonal to the question of whether this is a sane default for apport global behavior
[17:44] <dobey> seb128: yes.
[18:24] <Vanderson> Hi, I have a simple doubt.  I trying to start in Ubuntu Dev and I get this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-screenshot/+bug/1169904 and make a pacth to it : https://code.launchpad.net/~vandersonmr/gnome-screenshot/bugfix1169904 ; So what should I do next?
[19:37] <iBelieve> I've noticed there is a new version of git-cola available (1.8.2). I checked Debian and it is available in sid. I'm not very sure how new package versions work - will this automatically make it into 13.10 or do I need to file a bug to get it upgraded?
[19:39] <slangasek> iBelieve: it will be automatic because there are no Ubuntu-specific changes to the package
[19:39] <slangasek> if there had been Ubuntu changes, it would not be automatic; a developer would have to merge it
[19:41] <iBelieve> slangasek: Okay, thanks.
[20:35] <dobey> can someone sponsor the debdiff on bug #1173249 into raring-proposed please? since i don't have upload privs to pygobject
[21:54] <Daviey> Logan_: You are keen.  Already running saucy i see :-).
[21:54] <Logan_> lol, you know it. :P
[22:40] <Vanderson>  Hi, I have a simple doubt.  I trying to start in Ubuntu Dev and I get start with this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-screenshot/+bug/1169904 and make a pacth to it : https://code.launchpad.net/~vandersonmr/gnome-screenshot/bugfix1169904 ; So what should I do next? How  do I sent this pacth to the mainstream?
[22:42] <ScottK> Vanderson: I would ask in #ubuntu-desktop next week.  We just had a release so very few people are around now.