[00:00] <Mikeulus> I found the information I was looking for in reset_unity_compiz_profile function.
[00:01] <Mikeulus> thanks
[07:05] <dholbach> good morning
[07:07] <geser> good morning dholbach
[07:08] <dholbach> hi geser
[08:30] <mpt_> ev, I'm pretty sure the dip on the errors.ubuntu.com graph for the current day is because it's not dividing by the elapsed proportion of the day
[08:30] <mpt_> ev, we weren't sure about that before because the dip didn't seem as big as it should be if that was the reason
[08:31] <ev> mpt_: I thought we tried factoring that in and it swung wildly in the other direction?
[08:31] <ev> I can't remember the numbers to back that up
[08:31] <mpt_> But the dip isn't as big as it should be because of the wrong-denominator problem -- at the very start of the day it's 1
[08:32] <mpt_> So our correction probably put it up to ~24 at the very start of the day, explaining the wild swing :-)
[08:32] <mpt_> Once the denominator is right, the correction will work too.
[08:32] <ev> well, it all goes away once we fix the denominator, as that calculation cannot be made in realtime. So the data will only go as far as the day past.
[08:32] <ev> yup
[08:33] <mpt_> oh, true
[08:33] <mpt_> Well, it *could* be made in real time, it would just be a lot of work
[10:19] <jamespage> any autoconf gurus around? struggling to see how 'if test "$HAVE_SYS_SOCKET_H"; then' in an acinclude.m4 would ever work
[10:25] <cjwatson> jamespage: That does look wonky since $HAVE_SYS_SOCKET_H is 0 if you don't have the header, and test "anything_non_empty" is true.
[10:26] <cjwatson> The usual version would be test "$HAVE_SYS_SOCKET_H" = 1
[10:27] <jamespage> cjwatson, that is what is confusing me; the header is checked for using AC_CHECK_HEADERS
[10:28] <jamespage> cjwatson, that is then used to wrap a call to AC_EGREP_HEADER to check for a feature
[10:28] <jamespage> but it never gets executed :-(
[10:29] <jamespage> cjwatson, I can't see $HAVE_SYS_SOCKET_H getting set at all (although the #define doe get set correctly)
[10:36] <jamespage> hmm - I think I see the issue
[10:36] <cjwatson> jamespage: Point me at the branch or something?  I don't know if I'm an autoconf guru, but I can probably play one on TV for the purposes
[10:36] <cjwatson> OK :)
[10:39] <jamespage> check should be looking for "$ac_cv_header_sys_socket_h"
[10:39] <jamespage> so "$ac_cv_header_sys_socket_h" == yes works OK
[10:42] <cjwatson> Ah yes.  Although that should be =
[10:43] <cjwatson> (== is a bashism)
[11:24] <pcarrier> hey!
[11:24] <pcarrier> anybody would know why xulrunner isn't packaged in precise anymore?
[11:27] <cjwatson> pcarrier: https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-mozilla-rapid-release-maintenance
[11:28] <pcarrier> cjwatson: that doesn't really explain what the overall choice is. getting rid of xulrunner altogether?
[11:28] <pcarrier> cjwatson: it's useful for projects like kiwix
[11:29] <cjwatson> I wasn't involved and don't know any more.  Just providing you a reference.
[11:48] <jamespage> cjwatson, bah - missed your last comment
[11:48]  * jamespage makes a note to fix that later today
[12:03] <xnox> pcarrier: while it is useful, it was a pain to depend on. My package would randomly start segfaulting after e.g. security update to xulrunner and my package had to be rebuild, bumping exact version mathing xulrunner stings each time.
[12:04] <xnox> pcarrier: plus xulrunner is abandoned upstream and is no longer updated/released/supported/security-supported
[12:04] <xnox> as a stand-alone / embedable product
[12:04] <xnox> pcarrier: you should switch to webkit, as it is meant for embeding.
[12:04] <pcarrier> xnox: sounds like a good answer, thanks :)
[12:04] <pcarrier> xnox: well, it's not my project
[12:04] <xnox> pcarrier: or you can become a firefox addon.
[12:04] <pcarrier> xnox: but thanks
[12:04] <pcarrier> xnox: that's very much not where those guys want to go, I'm afraid
[12:05] <xnox> pcarrier: well then them and us go separate ways =) we have OS to support.
[12:05] <pcarrier> xnox: I know that :) could be a universe package though :)
[12:05] <pcarrier> xnox: not ranting
[12:05] <xnox> pcarrier: there are expectations of packages to work in universe as well.
[12:06] <pcarrier> xnox: I know that ;)
[12:06] <xnox> if universe is broken it looks bad on the whole distro + all our derivatives + upstreams
[12:06] <pcarrier> xnox: absolutely
[12:56] <jamespage> @pilot in
[13:31] <green7> can someone help me in fixing the bug #923932.
[13:41] <green7> can someone help me in fixing the bug #923932.
[13:50] <xnox> cjwatson: jodh: is sendsigs.omit.d honored in ubuntu (i.e. upstart)?
[14:10] <xnox> nevermind, as long as /etc/init.d/sengsigs is till used it is honored, but if a script that uses it is converted to an upstart job, it should stop on correctly.
[14:12] <green7> can someone help me in fixing the bug #923932.
[14:23] <mpt> ev, any ETA for the next rollout? Or are you still working on the 90-day actives?
[14:23] <ev> mpt: one just happened, but I'm still working on the 90 days stuff
[14:23] <ev> the greyed out lines are there though
[14:23] <ev> let me know what you think
[14:24] <ev> I need to get a better caching deployment done today too
[14:24] <ev> as we're not paying any attention to etags from launchpad at the moment
[14:31] <jodh> xnox: that logic assumes jobs specify an explicit 'stop on' condition; if they don't, they are in limbo land as sendsigs ignores them FWICS. Therefore sendsigs is making a potentially incorrect assumption (upstart_jobs() should parse 'initctl show-config' for each job and check if it does have a 'stop on' before omitting it).
[14:32] <xnox> jodh: ah. ok. it's just mdmon should still be running after rootfs is unmounted, otherwise mdmon will not manage to stop the underlying RAID array
[14:32] <xnox> which is hosting the rootfs for example.
[14:33] <xnox> and mdmon is spawned/started automatically by mdadm, i.e. the udev rule. so it's ok if the pid is in the sendsigs and there is no upstart job.
[14:35] <Riddell> tkamppeter: my printer doesn't get a driver auto-detected by s-c-p-udev but it works fine when I set it up manually, should I report?
[14:42] <mpt> ev, whoo, y axis starting at zero. Oddly it seems to have brought the 12.04 line down with it.
[14:43] <mpt> ev, at least the 12.04 values on the main graph are consistently 1.0 greater than those on the zoom graph.
[14:45] <tkamppeter> Riddell, which printer do you have and how is it connected?
[14:45] <Riddell> tkamppeter: USB, epson stylus SX130
[14:48] <ev> mpt: https://bugs.launchpad.net/errors/+bug/1035866
[14:59] <seb128> bdmurray, hey, your bot keeps commenting on bug #1035952 in loop for some reason
[15:00] <bdmurray> seb128: thanks, looking
[15:01] <dupondje> 19 UTC is within 4 hours right ? :)
[15:01] <seb128> bdmurray, thank you
[15:01] <seb128> dupondje, yes
[15:01] <dupondje> so I don't come late for my MOTU application :)
[15:04] <bdmurray> seb128: it is commenting on it because of the bug pattern for that "master" bug - http://bazaar.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns/view/head:/bugpatterns.xml#L1777
[15:06] <seb128> bdmurray, hum, the bug only has 1 comment, I wonder why I received 4 emails about it today
[15:06] <seb128> they seems to be every second hour at :47
[15:07] <bdmurray> seb128: oh, maybe the actually marking it as a duplicate failed
[15:07] <seb128> bdmurray, seems likely
[15:07] <seb128> hum
[15:07] <seb128> wth, http://pastebin.ubuntu.com/1144977/
[15:08] <seb128> "Rejected:
[15:08] <seb128> dpkg-source failed for file-roller_3.5.4-0ubuntu3.dsc [return: 2]
[15:08] <seb128> [dpkg-source output:   dpkg-source: info: extracting file-roller in file-roller-3.5.4"
[15:08] <seb128> but I can dpkg-source -x that source file locally
[15:08] <seb128> fine
[15:10] <cjwatson> seb128: can you put the source package somewhere for me to look at?
[15:12] <seb128> cjwatson, dget http://people.canonical.com/~seb128/file-roller_3.5.4-0ubuntu3.dsc and the orig is in quantal
[15:13] <seb128> cjwatson, do you want the full reject email for launchpad as well?
[15:13] <cjwatson> seb128: no, I can get that from production logs
[15:13] <cjwatson> or near neough
[15:13] <seb128> ok
[15:13] <cjwatson> *enough
[15:14] <seb128> there is no actual error in the email
[15:14] <seb128> just blank lines
[15:31] <jibel> bdmurray, about bug 1029046 I am not sure about the test case
[15:31] <jibel> bdmurray, shouldn't it be tested with an upgrade from Oneiric to Precise ?
[15:32] <jibel> bdmurray, instead of Precise to Quantal
[15:32] <jibel> because the version of the upgrader used during an upgrade is the version from the target release
[15:34] <bdmurray> jibel: yes, you are correct
[15:35] <bdmurray> jibel: do you want me to fix the description?
[15:35] <jibel> bdmurray, that's fine. thanks, I'll do the verification
[15:44] <seb128> cjwatson, do you want me to open a bug or something about the file-roller upload issue? I've an updated version (got an extra git commit), should I try to upload that one or do you want to keep the issue as a testcase?
[16:11] <cjwatson> seb128: sorry for the delay, I'm in roaming mode this afternoon and I got locked out of library wifi
[16:11] <cjwatson> I'll be back on it in a moment
[16:21] <GrueMaster> So, with Unity-2d being dropped, what is the preffered solution for remote desktop usage?  Unity/Compiz currently fails, unless using VNC, which is a bandwidth hog.
[16:22] <cjwatson> seb128: here's the actual error from dpkg-source:
[16:22] <cjwatson> dpkg-source: error: expected [ +-] at start of line 11232 of diff `file-roller-3.5.4/debian/patches/git_src_update.patch'
[16:22] <cjwatson> seb128: I suspect you'll find that dpkg-source -x would fail likewise in a lucid chroot
[16:23] <cjwatson> yep, it does
[16:23] <cjwatson> -</interface>
[16:23] <cjwatson> \ Pas de fin de ligne à la fin du fichier
[16:23] <cjwatson> +</interface>
[16:24] <cjwatson> so it objects to that - simplest fix might be to strip the trailing newline from that file and rediff (or just delete the \-prefixed line from that patch)
[16:24] <cjwatson> kind of surprised we haven't encountered this before mind you
[16:24] <cjwatson> it'll be fixed once LP moves to precise, since precise's dpkg-source doesn't object to this
[16:25] <cjwatson> ah
[16:25] <cjwatson> or you could regenerate that patch in LANG=C
[16:26] <cjwatson> here's lucid's dpkg-source code:
[16:26] <cjwatson>                 next if /^\\ No newline/;
[16:26] <cjwatson> in precise it's just:
[16:26] <cjwatson>                 next if /^\\ /;
[17:17] <seb128> cjwatson, thanks
[17:18] <xnox> Anyone has a spare intel matrix raid controller?
[17:18] <tumbleweed> you get them as standalone controllers? I thought that was just a bios thing
[17:23] <xnox> tumbleweed: well system which has an intel matrix raid controller, it's not stand alone but can be build into cpu/bios, bridge, intel sata controller cards as far as I understand it.
[17:23] <xnox> tumbleweed: if you know how to *find* hw capable of intel matrix raid, i'd love my next laptop to have it =)
[17:26] <stgraber> xnox: they usually appear as "00:1f.2 RAID bus controller: Intel Corporation 82801 SATA Controller [RAID mode] (rev 02)"
[17:26] <xnox> stgraber: thanks!
[17:28] <stgraber> xnox: pciid is 8086:2822 here. You might be able to find some matching hardware in the lab by looking for that on hexr.canonical.com, if you're lucky there's a server in the lab that you can get access to
[17:30] <xnox> stgraber: sweet!
[17:50] <barry> jdstrand: ping
[17:51] <jdstrand> barry: hey
[17:51] <barry> jdstrand: hi.  there's a bug in https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment
[17:51] <jdstrand> barry: is this for quantal?
[17:51] <barry> jdstrand: yep
[17:51] <barry> jdstrand: script-get-ddebs can't source /etc/schroot/default/config because that file does not exist
[17:52] <jdstrand> barry: may I direct you to tyhicks? he was looking at fixing those things
[17:52] <barry> tyhicks`: ^^ (thanks jdstrand)
[17:52] <tyhicks`> hey barry
[17:52] <jdstrand> barry: I think tyhicks` is afk atm, but he'll be back in a bit
[17:53] <barry> tyhicks`: just pointing out that /etc/schroot/default/config doesn't exist in quantal afaict
[17:53] <tyhicks`> barry: You're right. The schroot configuration dir was shuffled around a bit.
[17:53] <tyhicks`> barry: I have things working pretty well on my system now
[17:53] <barry> tyhicks`: cool.  do you have an update for script-get-ddebs?
[17:54] <tyhicks`> barry: Would it be ok if I got the wiki updated over the next 20 minutes or so and then pointed you at the updated page?
[17:54] <tyhicks`> (I don't know how urgent you need things to be working again)
[17:54] <barry> tyhicks`: whatever is easiest for you.  i was going to do a test build of a package i need to update (just updated my main box to quantal).  but i think the patch is good so i'll forgo the test build for now and just upload it :)
[17:55] <barry> tyhicks`: can you ping me when the page is updated?  my email is temporarily down
[17:55] <tyhicks`> barry: Will do
[17:55] <barry> tyhicks`: thanks!
[17:55] <tyhicks`> np
[18:07] <shadeslayer> cjwatson: pingly
[18:10] <shadeslayer> cjwatson: let's say I wanted to add a couple of 3rd party archives using live build, but some of the repos have a different component than the others, how can I accomplish that?
[18:10] <shadeslayer> because using --archives foo --archive-areas bar for every repo makes it choose the last repo
[18:11] <shadeslayer> and all other repos are overwritten
[18:12] <shadeslayer> oh, hmm
[18:15] <shadeslayer> there we go \o/
[18:16] <shadeslayer> though I'm still certain that it'll fail since it won't find the main component on archive.canonical.com
[18:16] <shadeslayer> or the partner component on the PPA's
[18:48] <Peace-> byzanz-record is not in the repository
[18:48] <Peace-> why?
[18:48] <Peace-> there was
[18:48] <Peace-> on 12.04 there is not
[18:48] <Peace-> thre is a ppa that work for 12.10 too btw
[18:51] <tyhicks> barry: Ok, finally got it finished: https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Upgrading_to_Quantal_.2812.10.29
[18:51] <tyhicks> barry: Please make a backup of everything and proceed with caution
[18:52] <barry> tyhicks: thanks, trying...
[18:52] <tyhicks> barry: You're the first one to follow my instructions on this, so you may hit some bumps :/
[18:52] <barry> tyhicks: "guinea pig" is my middle name!
[18:52] <tyhicks> barry: Exactly! :)  Let me know of any problems and we'll work through them
[18:53] <barry> tyhicks: i've always stopped reading at "umt" :)
[18:54] <tyhicks> barry: Hmm.. well do you need the whole script-get-ddebs magic? I assumed it was for umt.
[18:55] <barry> tyhicks: maybe i don't and didn't know it
[18:56] <barry> tyhicks: anyway, let me play around with it and see
[18:56] <tyhicks> jdstrand: Do you know if /etc/schroot/script-get-ddebs is only for umt?
[18:57] <tyhicks> barry: The core of the problem is that schroot deprecated the script-config option in schroot.conf, in favor of the profile option, and then /etc/schroot/ was shuffled around to match that
[18:57] <tyhicks> barry: That's all you need to work around
[18:58] <barry> tyhicks, jdstrand: maybe if i don't use umt, i don't need script-config at all and can just comment it out?
[18:59] <tyhicks> barry: That's what I'm wondering, as well. I don't know the history of script-get-ddebs well enough to say for sure though :/
[18:59] <jdstrand> tyhicks: ah sorry-- script-get-ddebs shouldn't strictly be needed even for umt
[18:59] <tyhicks> jdstrand: Is it needed at all anymore?
[19:00] <jdstrand> it is just there to snag the ddebs
[19:00] <jdstrand> well, if you want ddebs it is needed
[19:01] <tyhicks> Ok. I updated the wiki page to provide an equivalent setup to what was already described.
[19:01] <barry> so perhaps that's just not needed for ordinary test builds
[19:01] <tyhicks> barry: If you don't need access to the ddebs, then you should be fine just removing the script-config option from schroot.conf.
[19:02] <barry> tyhicks: gotcha.  i'm going to just try that and see how it goes
[19:02] <tyhicks> sounds good
[19:02] <barry> tyhicks, jdstrand thanks!
[19:02] <tyhicks> np
[21:11] <robert_ancell> @pilot in
[21:13] <mdeslaur> barry: any idea how I can decode a hex string that works in both python 2 and python 3?
[21:13] <barry> mdeslaur: string or bytes? ;)
[21:14] <barry> mdeslaur: do you have an example?
[21:14] <mdeslaur> it's a result from re.findall
[21:15] <mdeslaur> ie: "4a4b4c"
[21:15] <mdeslaur> I used to be able to do .decode("hex")
[21:15] <mdeslaur> and now I can do bytes.fromhex("4a4b4c").decode('utf-8')
[21:15] <mdeslaur> but, is there a way that works in both?
[21:17]  * barry thinks
[21:18] <mdeslaur> you can say no too :)
[21:18] <barry> mdeslaur: off-hand i don't ;)
[21:18] <mdeslaur> ok, thanks :)
[21:54] <GrueMaster> mdeslaur: What are you trying to decode it to?  Can you use int('4a4b4c',16)?
[21:58] <GrueMaster> I just tried it in both 2.7 & 3.2.  Seems to work for me.
[22:55] <mdeslaur> GrueMaster: it's a text string that's hex encoded, so no, not an int
[22:56] <GrueMaster> int converts text strings to integers.
[22:56] <GrueMaster> >>> int('4a4b4c',16)
[22:57] <GrueMaster> 4868940
[22:57] <GrueMaster> Thisis what I get when I run this in "python -i".
[23:20] <mdeslaur> GrueMaster: I don't want an integer, I want a string back
[23:20] <mdeslaur> ie: '5468697320697320736f6d652074657874'.decode('hex')
[23:21] <GrueMaster> Oh.  Give me a sec, I might have a solution.