[01:17] <hallyn> arges: the one thing i'd say is that buffer_find_nonzero_offset() could be static, and can_use_buffer_find_nonzero_offset() only needs to exist righ tabove that in the same file, but it's no big deal
[01:18] <hallyn> arges: looks good to me, thanks.
[01:30] <vish> pitti: hi.. how are you?  Bug #1231763 oops..! :(
[03:27] <pitti> Good morning
[03:29] <pitti> vish: ack, will do; thanks!
[03:30] <pitti> vish: hm, we used SVG before too, but apparenlty a less complex one?
[03:37] <pitti> vish: ack, I'll keep the SVG ones in scalable/ then
[03:43] <mdeslaur> good morning pitti
[03:44] <vish> pitti: i think, it might be better if we kept the scalable as PNG too, just so that we dont have to revisit it again... it might just be the layers that i used
[03:44] <pitti> vish: but I want to ship the "source" of the PNGs too, and with these sizes we shoudl have the common use cases covered?
[03:45] <pitti> PNG isn't scalable
[03:45] <vish> yea, isnt good with scaling
[03:46] <vish> pitti: ok, SVG in scalable sounds fine.. :)
[03:49] <vish> thanks..
[06:45] <dholbach> good morning
[06:51] <pitti> Laney, infinity: is it ok if I accept the langpack uploads in saucy? I guess saucy will not thaw any more, i. e. freeze until release?
[07:03] <tjaalton> doko_: the -ati update was unnecessary, as xorg-server got fixed..
[07:03] <tjaalton> I was about to respin the builds
[07:44] <doko_> tjaalton, does this mean you'll have time to look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130917/+build/5005733 ? ;)
[07:46] <tjaalton> doko_: ouch :)
[07:49] <tjaalton> "bus error", isn't that a hit-or-miss failure?
[07:50] <doko_> I can give it back
[07:53] <tjaalton> hmm we didn't merge 1.6.x
[08:02] <doko_> tjaalton, persists
[08:03] <tjaalton> dunno then, at least 1.6.1 builds fine on sbuild
[08:07] <tjaalton> 1.5.0-0u1 fails right in the beginning
[08:07] <tjaalton> nls/Makefile.am:41: error: using '$(srcdir)' in TESTS is currently broken: '$(srcdir)/compose-check.pl'
[08:08] <tjaalton> oh that was fixed in -0u2
[08:10] <pitti> cjwatson: do you already have a debdiff for the missing *_id in udev-udeb, or want me to work on that now?
[08:16] <Laney> pitti: langpacks> I think we're basically released modulo announcements, so seems fine to me
[08:17] <pitti> Laney: can't parse "basically released modulo announcements", but I take the "seems fine" :)
[08:18] <Laney> I mean that the release is rolled but couldn't be announced because it required London people for whom it was too late
[08:18] <pitti> Laney: oh, the final beta
[08:18] <Laney> yeah
[08:18] <pitti> right, accepting then
[08:18] <pitti> thanks
[08:18] <pitti> Laney: are we going to thaw again then, or will it stay frozen?
[08:19] <Laney> It'll stay frozen now
[08:20] <infinity> pitti: Staying frozen, but unseeded is now auto-accepted, thanks to some hackish new magic.
[08:20] <infinity> pitti: So, vaguely a best of both worlds.
[08:20] <seb128> pitti, infinity: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/16775 \o/
[08:20] <Laney> I divined that from #-release backlog but probably worth mailing -release about it
[08:21] <seb128> "[r=wgrant][bug=1201485] Packages copied from PPAs to archive now have
[08:21] <seb128>  their translations copied as well."
[08:21] <pitti> seb128: en effet, j'ai le vu !
[08:21] <infinity> Laney: I'll do that after I get the release announce out.
[08:21] <seb128> pitti, is that enough to get the templates automagically updated again?
[08:21] <Laney> sweet
[08:21] <pitti> seb128: shoudl be
[08:21] <pitti> seb128: I'm just uploading new langpacks (they were supposed for final beta, but apparently LP had a hiccup and didn't give me an export until last night)
[08:22] <infinity> seb128: Oh shiny, that got done?  Yay.
[08:22] <pitti> seb128: but of course that won't have the new translations yet; but after that I'll re-enable the daily cron, so we should get the new love ASAP
[08:23] <seb128> pitti, ok, thanks
[08:24] <infinity> seb128: Be sure to thank Ursinha for that when you see her. :)
[08:24] <seb128> infinity, will do
[08:30] <cjwatson> pitti: I don't (just to close the thread from another channel ...)
[08:30] <cjwatson> seb128: Note that that isn't QAed/deployed yet
[08:30] <cjwatson> http://lpqateam.canonical.com/qa-reports/deployment-stable.html
[08:31] <cjwatson> But yeah, excellent to have that
[08:32] <seb128> cjwatson, ok, thanks for pointing it out ... I've no clue about lp deployments, but I guess I can keep watching that page to know when it really lands?
[08:33] <cjwatson> seb128: yes, once that clears it's landed, give or take half an hour or so
[08:33] <seb128> great
[08:33] <seb128> cjwatson, thanks
[08:35] <diwic> didrocks, hi, is it okay to upload a PulseAudio if the only changes are bug fixes in modules we don't make use of on the phone?
[08:36] <didrocks> diwic: yeah, please go ahead
[08:36] <diwic> didrocks, thanks, will do that later today then
[08:38] <pitti> cjwatson: all prepared (also the cleanup of the two unneeded rules, thanks for pointing out); doing test build now, etc., and standing by for ogra's "go" (for the stack of packages for bug 1227520)
[08:43] <infinity> pitti: Did you change timezones between apport releases? :)
[08:44] <infinity> pitti: (The git log -> ChangeLog autogenration threw everything out by a day, which is entertaining)
[08:55] <pitti> infinity: yes, I did the previous apport release in New Orleans
[08:55] <pitti> infinity: git log? apport is in bzr
[08:55] <infinity> pitti: bzr log, whatever. :P
[08:55] <infinity> pitti: Maybe your ChangeLog export magic should set TZ=UTC, so ChangeLog doesn't get a 20k diff when you move around. :)
[08:56] <pitti> infinity: urgh, I didn't consider that it would do that, sorry
[09:01] <infinity> pitti: No big deal.  Was fascinating reading for the first few entries until I noticed the +/- markers and realised the next 20k of diff was useless. :)
[09:02] <pitti> infinity: yeah, TBH I just skipped over it and didn't even notice
[09:02]  * pitti uses "/^--- " to jump to the next file in a diff
[09:03] <infinity> I was reading it in firefox, which was my first mistake.
[09:22] <pitti> seb128: new gvfs packaged, tested, uploaded FYI
[09:22] <seb128> pitti, \o/
[09:22] <seb128> pitti, danke
[09:32] <cjwatson> pitti: Great, thanks
[10:19] <labsin> mardy, I have a question about online accounts. I try to add my mobile provider to online accounts, but it fails.
[10:20] <labsin> It uses OATH1.0 like the twitter plugin and I've tested my keys and the twitter keys with a Python library and there they both work the same.
[11:43] <smartboyhw> Which package is the GRUB "Ubuntu" item information put in?
[11:49] <cjwatson> smartboyhw: Could you elaborate?
[11:55] <smartboyhw> cjwatson, like, when I select the "Ubuntu" option in the GRUB menu, what's the settings and parameters behind? And which package are these parameters defined?
[11:56] <cjwatson> smartboyhw: Well, you can press 'e' on it to see the settings
[11:56] <cjwatson> smartboyhw: They're defined in the grub2 source package
[12:02] <smartboyhw> cjwatson, OK, but it's difficult to find out the patch that defines it...
[12:04] <cjwatson> smartboyhw: It's mostly upstream behaviour
[12:04] <cjwatson> util/grub.d/10_linux
[12:05] <smartboyhw> cjwatson, what about the UEFI option?
[12:05] <cjwatson> Well, you can just look at the unpacked source package which will unpack with all the patches applied
[12:06] <cjwatson> There's some UEFI code added by things like mkconfig_signed_kernel.patch, certainly
[13:58] <xnox> zul: how about I just take the cherrypy3 autopkgtest into debian & sync into ubuntu, instead of introducing delta?
[13:58] <zul> xnox:  sure
[15:04] <mdeslaur> tkamppeter: hi! Is there a public repo for hplip somewhere?
[15:25] <tkamppeter> mdeslaur, no, there are only the releases. Is there a new security bug?
[15:25] <mdeslaur> tkamppeter: no, I'm just looking at an old security bug I have not fixed yet, and wanted to look at some historical commits
[15:25] <mdeslaur> tkamppeter: thanks!
[15:40] <stokachu> what do we do if a package doesn't have a changelog entry for the series its released in? keepalived for both raring and quantal are exactly the same, should i bump raring to a higher SRU number?
[15:41] <mdeslaur> stokachu: append the version number of the release. For example: 1ubuntu1 becomes 1ubuntu1.12.10.1 for quantal and 1ubuntu1.13.04.1 for raring
[15:42] <stokachu> mdeslaur: ah ok thanks!
[15:43] <cjwatson> stokachu: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging has detailed recommendations
[15:43] <cjwatson> (which agree with what mdeslaur said, of course, but go into more detail)
[15:43] <stokachu> cjwatson: thanks i got it bookmarked
[17:38] <stokachu> doko: would you be able to get to bug 995719 by today or monday?
[21:57] <eLpm> Hello. After the latest saucy update, I receive this error on startup: Sep 27 17:40:57 pc4 kernel: [   42.380067] [drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.flags (expected 2, found 0)
[21:58] <eLpm> Ubuntu logs in normally so I am not sure about the severity...
[22:27] <rohan> hi.. does anyone know what power backed does ubuntu 13.10 use? does it still use pm-utils?
[22:48] <Noskcaj> rohan, It depends on the flavour, i think ubuntu itself does
[22:49] <rohan> Noskcaj: ubuntu uses pm-utils still?! it has been dead since 2010
[22:49] <Noskcaj> rohan, I think so (not sure). Xubuntu is missing it and needs it to fix some bugs
[22:51] <rohan> that's a shame.. pm-utils also doesn't support in-kernel hybrid suspend
[22:53] <slangasek> Ubuntu uses upower, with pm-utils as the actual low-level "suspend now" interface
[22:54] <slangasek> I don't think it's interesting that pm-utils is "dead", that just means there are no changes needed
[22:54] <slangasek> we don't support hibernation on the Ubuntu desktop, period, so in-kernel hybrid suspend is also not interesting
[22:58] <rohan> slangasek: pm-utils is "dead" dead, because they haven't been accepting patches for a while now.
[22:59] <rohan> slangasek: on a laptop, not supporting hibernate can be crucially dangerous
[22:59] <slangasek> rohan: nonsense.  We support suspend, followed by shutdown on critical power
[23:00] <rohan> slangasek: and how is that a better solution than hybrid suspend?
[23:00] <slangasek> because it doesn't go pearshaped when the sizing of your swap partition is wrong
[23:00] <rohan> you end up losing state, when you don't have to
[23:00] <slangasek> we disabled the hibernate option because it was *unreliable*
[23:00] <sarnold> are you telling me this sixteen gig swap partition wasn't necessary? :)
[23:01] <slangasek> sarnold: I assume you're using yours steganographically :P
[23:01] <rohan> slangasek: i'd love to know more about why it was determined to be unreliable. any links i could read?
[23:01] <slangasek> rohan: none that I have to hand; I believe there was a blueprint and possibly a UDS discussion at the time the decision was taken
[23:02] <rohan> also, how is the "critical battery" check done? using timers?
[23:02] <slangasek> it uses the ACPI support for this
[23:02] <rohan> seems so much more inefficient and counter-intuitive, than just having hybrid suspend.
[23:03] <slangasek> hybrid suspend relies on the kernel taking the time to write out the entire system's memory to swap, which a) is slow, b) may not finish before your battery runs out anyway, resulting in even greater risk of data loss than if we'd just done a controlled shutdown
[23:03] <stgraber> there were talks at last vUDS to support Intel's hardware hybrid-suspend equivalent that got introduced with Ivy Bridge and comes with the relatively sane restriction of working only on machines with <= 8GB of RAM
[23:04] <rohan> slangasek: i don't mean doing hybrid suspend when battery is critical, i mean doing a hybrid suspend always. just like windows and Mac OS do it.
[23:04] <stgraber> so on those systems it may be reasonable to allocate 8GB of space for suspend (assuming the user doesn't care about disk encryption, in which case they should opt out of it as the state isn't encrypted)
[23:05] <stgraber> and there's nothing for the OS to do, the firmware does it all, so we don't have to care about it from our side of things (just need to create the partition with the right label/guid at install time)
[23:05] <slangasek> rohan: ah, right - sorry, of course hybrid suspend means that you don't actually suspend until you've first written the hibernate image to disk
[23:05] <slangasek> so you don't have the "wake up, hibernate, run out of time" problem
[23:05] <rohan> right
[23:05] <slangasek> but you do have the "takes forever to suspend because it has to write to swap first" problem
[23:07] <rohan> it will happen after you close the lid, so you're unlikely to notice the higher time anyway. in the long run, it's safer because then your state is saved even if the battery runs out
[23:07] <stgraber> anyone who doesn't completely trust their hardware will notice. I never put a machine in a bag until I see the suspend led confirming it's fully suspended
[23:08] <stgraber> I've got way too many machines almost burning me because they didn't suspend properly
[23:10] <rohan> fair enough. i guess people who took decision are more informed and have done more testing than me; and this channel is probably not the best channel to argue about it :)
[23:12] <slangasek> The decision was taken directly because hibernate ws found to be unreliable.  Now that's something that could be revisited, but there's a lot of developer time that would have to go into *making* it reliable before we would flip the switch again
[23:15] <rohan> if your system ACPI is wonky, sleep will be as unreliable as hibernate. as far as i understand, only reason hibernate will be more unreliable is if you have a wrongly sized partition, a case which should be handled by pm-utils (and is, iirc)