[02:54] <CIA-33> Ubuntu Documentation: nixternal * r4317 kubuntu/index/C/index.xml: replaced some topics and added links to index
[02:55] <LaserJock> showoff
[03:07] <CIA-33> Ubuntu Documentation: nixternal * r4318 kubuntu/ (18 files in 18 dirs): update pot files
[06:33] <CIA-33> Ubuntu Documentation: sbalneav * r4319 edubuntu/handbook/C/server.xml: Added small section on Sabayon and Pessulus
[08:58] <LaserJock> mdke: it seems I forgot to reply to your Packaging Guide email
[08:58] <mdke> LaserJock: how dare you!
[08:59] <LaserJock> mdke: there is enough difference that keeping around the dapper version  is good
[08:59] <LaserJock> but after that people might as well be be using the latest
[09:00] <mdke> do people package things for dapper?
[09:00] <mdke> or rather
[09:00] <mdke> do people who are learning how to package for the first time do so on dapper?
[09:00] <LaserJock> probably rarely
[09:00] <LaserJock> usually we put them into the current dev release
[09:00] <LaserJock> i.e. right now everybody is learning on gutsy
[09:01] <mdke> that's what I thought
[09:01] <LaserJock> I would rather like to see the Packaging Guide not tied to releases
[09:01] <mdke> would it be possible to make it release neutral; i.e. including a section about how to package for previous releases?
[09:01] <LaserJock> yes, well
[09:02] <LaserJock> after dapper it pretty much is
[09:02] <mdke> right
[09:02] <mdke> and is it for the foreseeable future too?
[09:03] <LaserJock> the only time it becomes difficult is if there is some major change in the way we do things
[09:03] <LaserJock> for dapper->edgy some of the tools were made much easier
[09:03] <LaserJock> for feisty we added some Maintainer field stuff
[09:04] <LaserJock> but in princible these are minor things and should be dealt with by using notes
[09:04] <mdke> presumably in that case the packaging guide would simply be updated, and people packaging for previous releases would need to look at some specific information
[09:04] <LaserJock> right
[09:05] <LaserJock> but I also think the packaging guide could be totally reworked
[09:05] <LaserJock> so that it is more guide and less reference
[09:05] <LaserJock> in which case it could be even less release-specific
[09:05] <mdke> is anyone in motu interested in working on it? If it's sold as the definitive motu guide, perhaps people would be
[09:05] <LaserJock> well
[09:06] <mdke> jono could pimp it up as part of his motu push?
[09:06] <LaserJock> I've had three people show an interest in it
[09:06] <LaserJock> TheCore, bluekuja, and another fellow
[09:06] <LaserJock> but I honestly don't know where that's going to get
[09:06] <LaserJock> the emphasis seems to be much more into doing docs on the wiki
[09:07] <mdke> so there is an overlap between those and the packaging guide?
[09:08] <LaserJock> the wiki documentation, in general, seems to be more specific and less quality
[09:08] <LaserJock> sort of what we see in general
[09:09] <LaserJock> my concern is that a lot of people want to see some sort of guide through all this mess
[09:09] <LaserJock> and a fair amount want to print out a PDF as well
[09:10] <LaserJock> but as far as overlap of content there isn't a ton
[09:11] <mdke> we should try and get the packaging guide into the wiki and start people working on that
[09:12] <LaserJock> yes, I think that might be the way to go
[09:12] <LaserJock> I've never really gotten devs to help with content much
[09:16] <CIA-18> Ubuntu Documentation: mdke * r4320 ubuntu/printing/C/printing.xml: Ross's patch to update to new printing program
[09:18] <mdke> LaserJock: ok we agree :)
[09:20] <LaserJock> yes, but would still like to produce a nice looking doc
[09:20] <LaserJock> development on the wiki is nice
[09:20] <LaserJock> but end-user presentation on the wiki can be quite messy
[09:20] <LaserJock> especially for a largish doc
[09:21] <mdke> well, it wouldn't all be on one page, obviously
[09:22] <mdke> each chapter could be a page, or evensections
[09:25] <mdke> basically it would be nice to get to a place in docbook->wiki tolls that we can chunk the ouput in exactly the same way as we chunk html output
[09:33] <LaserJock> yep
[03:52] <glatzor> mdke: hello, could you please assist me in building translated html output of the documentation?
[03:52] <glatzor> I would like to use it for the review process
[03:52] <glatzor> The howto mentions to replace all C with de but this doesn't work.
[03:52] <glatzor> the translate,sh should still not be used?
[09:41] <mdke> glatzor: translate.sh should work fine. However there is no point using it with gutsy, we haven't even opened translations yet, let alone imported anything from rosetta. You can use it with feisty
[09:50] <mdke> glatzor: I'm going to look into translations soon though
[10:32] <glatzor> mdke: I was confused by acomment in the script "NB - DON'T ATTEMPT TO USE THIS YET, IT HASN'T BEEN TESTED MUCH." :)
[10:33] <mdke> glatzor: yeah, understandably
[10:33] <mdke> glatzor: anyway, that doesn't allow you to build html...
[10:34] <glatzor> mdke: It is quite late. see you.
[10:35] <glatzor> good night, mdke
[10:39] <mdke> glatzor: good night
[10:53] <CIA-18> Ubuntu Documentation: philbull * r4321 generic/server/C/web-servers.xml: Change php5-cgi to php5-cli (patch from Adam Sommer)
[10:58] <kylewilliams> nixternal, you there?
[10:58] <nixternal> kind of..what's up?
[10:59] <kylewilliams> ha, um...did you get my last email?
[11:00] <nixternal> yes I did...dunno how I missed that
[11:00] <nixternal> hey, with your sync, would your directions work for many?
[11:00] <kylewilliams> ok, was just wondering coz you're usually pretty quick to reply :)
[11:00] <nixternal> probably because Kontact in Gutsy has been broke for the past week :)
[11:01] <kylewilliams> that would ultimately be the idea, i'd need to test it a bit first though
[11:01] <kylewilliams> :D
[11:01] <nixternal> rock on...we only have a couple of days before all docs are frozen...did you do the sync in Gutsy?
[11:01] <kylewilliams> no, feisty - still have to test it on gutsy. was gonna do it this weekend
[11:02] <nixternal> we have 8 more days until the strings are frozen...so if you could rock up something with gutsy, a couple of screenshots (1024x768 with the default theme), I should be able to work it in
[11:02] <nixternal> it is definitely a topic I want to cover
[11:03] <nixternal> I could also work with my palm pilot here and work on syncing it as well
[11:03] <kylewilliams> ok, will get to working on it soon
[11:03] <kylewilliams> one problem though
[11:03] <nixternal> rock on, and just shoot me an email when you have something worked up
[11:03] <nixternal> not knowing docbook isn't a problem :)
[11:03] <nixternal> if that is what you were going to say
[11:03] <kylewilliams> the opensync-plugins-kdepim doesn't work with KDE > 3.5.5
[11:03] <nixternal> hehe
[11:03] <kylewilliams> sorry, trying to eat and type at the same time
[11:04] <kylewilliams> the package in the repos i mean
[11:04] <nixternal> are you sure? we just uploaded a new opensync everyone has been bragging about in gutsy
[11:04] <kylewilliams> oh, i tested against the package in the feisty repos
[11:04] <kylewilliams> i guess i should test it in gutsy first
[11:04] <nixternal> ya, give it a shot this week with gutsy and see what you can rock out
[11:05] <nixternal> hey, if this sync'ing stuff is up your alley, and you feel like doing some KDE 4 contributions, I might be able to pull a job for you
[11:05] <kylewilliams> ok cool...
[11:05] <kylewilliams> do by any chance know how kitchensync development is going?
[11:05] <nixternal> it is going..I know they are working hard on the "syncing" stuff with kdepim in KDE 4
[11:06] <kylewilliams> ya, well this weekend i really came to understand syncing
[11:06] <nixternal> awesome..I haven't messed with it in quite a few months actually, and I need to
[11:06] <kylewilliams> oh, and i'd love to do some KDE 4 stuff
[11:07] <nixternal> rock on, we hang out in #kde-docs
[11:07] <kylewilliams> i also tried synching a few months ago but got nowhere
[11:07] <nixternal> it is usually quiet, but my recent blog post started a lot of buzz
[11:07] <nixternal> so I am hurrying to finish the kubuntu docs so I can get back over to the KDE side for a while
[11:08] <kylewilliams> when's the kde4 doc freeze?
[11:08] <nixternal> we still have a couple of months, and a ton of work to do
[11:09] <kylewilliams> i'm sure...
[11:09] <kylewilliams> whenever i have time i'll try and get stuff down
[11:09] <kylewilliams> *done
[11:10] <kylewilliams> anyway, when the kde4 doc rush comes about I should be able to help out as I should be finished with exams by then
[11:10] <nixternal> groovy
[11:11] <nixternal> anywho, I need to roll for a bit here and finish up some work..just ping me if you need something
[11:11] <kylewilliams> one more question
[11:11] <nixternal> go for it
[11:11] <kylewilliams> any response to my question regarding the lack of a desktop guide for feisty?
[11:11] <kylewilliams> kubuntu feisty that is
[11:12] <nixternal> we dropped the desktop guides in favor of a topic based help setup
[11:13] <nixternal> however, I would like to someday work up another desktop guide as a side project because I get more emails and comments about bringing it back than anything else
[11:13] <kylewilliams> oh i see
[11:13] <nixternal> I have started working on a project and need to get the time to rock it out
[11:13] <kylewilliams> well where is the topic based help for feisty?
[11:13] <nixternal> need to speek with Jonathan Jesse a little more on the project first
[11:13] <nixternal> KMenu -> Help
[11:13] <nixternal> same spot the Desktop Guide was in
[11:13] <mdke> it's worth pointing out that there isn't really a proper distinction between a "desktop guide" and a "topic based help system"
[11:13] <kylewilliams> lol, oh there...i meant online
[11:14] <nixternal> mdke: true, but the requests I have been getting were something to read up on prior to installing, or something they could easily print out
[11:14] <mdke> the only difference is that the material which tells the user how to use their desktop is in more than one file, rather than in a single document
[11:14] <nixternal> so I have been messing around on the side just writing some stuff up that I am trying to get incorporated into the tbh for kubuntu
[11:15] <nixternal> the great thing with kde 4, is people will be able to go into one of the topics, and if they want to, they can press the "Export to PDF" button and have a PDF to do as they wish
[11:15] <mdke> nixternal: the response to that should be "we should develop a way to output our desktop help into a downloadable and printable format" rather than "we need to bring back the desktop guide"
[11:15] <nixternal> we don't need to bring back the desktop guide
[11:15] <mdke> I agree
[11:15] <nixternal> but I would like to do a free on the internet for all, Kubuntu Book like deal
[11:15] <mdke> but that was what you said a few lines up, so I wanted to clarify
[11:16] <nixternal> similar in style to that of the official ubuntu book, just more than one chapter for kubuntu :)
[11:16] <kylewilliams> yes, the official ubuntu book is good. would be nice to have one for kubuntu
[11:17] <kylewilliams> a whole one for kubuntu :D
[11:17] <nixternal> yes it would :)
[11:17] <mdke> there is an important difference between making a book out of our documentation (which just involves finding the right toolchain for pdf generation) and writing a desktop guide (which involves the extra and unnecessary step of writing more material and duplicating effort)
[11:17] <nixternal> who knows though, we are kind of processing one for KDE that might be good enough for all
[11:18] <kylewilliams> i've gotta go figure out how to implement serial communication on windows for a computer science project :(
[11:19] <kylewilliams> will be in touch nixternal
[11:19] <nixternal> fun, I am coding a bazillion lines of java right now for my comp sci project as well
[11:19] <nixternal> fun stuff...chat with ya later
[11:19] <kylewilliams> ha, enjoy


[10:42] <alkisg> stgraber: please upload packages for *both* ldm and ltsp to your ppa, so that I do a final clean ltsp-build-client test when I come back in about 3 hours from now.
[10:42] <alkisg> For the reboot/shutdown problem, I think the cleanest thing to do at this point is to create an init-ltsp.d script which will mv /sbin/nbd-client /sbin/nbd-client.real, and create a new /sbin/nbd-client wrapper,
[10:42] <alkisg> which will check if the parameters are "nbd-client -d /dev/nbd0", then "echo o > sysrq" etc, else chain to the real nbd-client
[10:43] <alkisg> I think `runlevel` will tell us if we need to reboot or shutdown
[10:46] <alkisg> I'll test + commit that when I get back in about 3 hours
[14:26] <stgraber> alkisg: ldm? I'm not planning an ldm upload today, the one in the archive should be good (unless you recently pushed something to ldm-trunk that we absolutely need)
[14:27] <alkisg> stgraber: I removed the -fp from all poweroff/reboots
[14:27] <alkisg> So that clients shut down properly - although we still need an nbd-client override
[14:27] <stgraber> alkisg: ok, is that all? if so, you should ask vagrant to push it to Debian when he has a moment and I'll sync it as bugfix
[14:28] <alkisg> Yup...
[14:29] <alkisg> I think the nbd-client override is a reasonable way to have clean shutdowns, until the nbd package is updated to handle it itself...
[14:29] <alkisg> I'm not sure if I'll have the time to do it before featurefreeze today, but that's a bugfix too, isn't it?
[14:30] <stgraber> I guess we can have it pass as bugfix yeah...
[14:35] <alkisg> Meh I think I'll just write a new /etc/init.d/nbd-client service, that we'll use to override the current one, and then propose it to Wouter so that it eventually goes upstream
[14:37] <alkisg> That /etc/nbd-client configuration file looks horrible


[01:48] <skay> any idea when the pure-python branch of lp:charms/python-django will land?
[01:49] <skay> I'd like to consider a change in how python-django pip installs things. I'd like it to be able to pip install from local wheels.
[15:04] <johnmce> Hi guys. Is anyone free to answer a quick question about the nova-cloud-controller charm and the new neutron-api charm?
[15:27] <mbruzek1> We have 30 minutes until the Juju Big Data UOS session.  Please attend if you are interested in BIG DATA
[15:27] <mbruzek1> http://summit.ubuntu.com/uos-1411/meeting/22392/big-data-and-juju/
[15:33] <gnuoy> johnmce, hi, what's the question?
[15:36] <johnmce> gnuoy: Hi. I'm upgrading my test cluster from Icehouse to Juno. HAd a few breakages along the way. Now deploying updated nova-cc charm and neutron-api. nova-cc charm fails to establish mysql relationship due to failed neutron db upgrade.
[15:37] <johnmce> Was wondering if nova-cc should still be fiddling with the neutron db in the presence of neutron-api
[15:38] <gnuoy> johnmce, unfortunately, yes. the nova-cc charm is in charge of running db migrations for neutron for os >= Juno
[15:39] <gnuoy> johnmce, from a juju pov there is a relation between nova-cc and mysql but the neutron db migration was not run, is that right ?
[15:39] <johnmce> gnuoy: OK, I don't suppose you would know how to work around for this failure. Command-line being run on nova-cc node is "/usr/bin/neutron-db-manage --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/ml2_conf.ini upgrade head"
[15:40] <johnmce> gnuoy: Error is "sqlalchemy.exc.OperationalError: (OperationalError) (1050, "Table 'agents' already exists") '\nCREATE TABLE agents ......"
[15:40] <johnmce> gnuoy: So, I seem to have at least a partial schema update
[15:41] <gnuoy> johnmce, is it definitely partial ?
[15:41] <gnuoy> I mean, are you sure the migration hasn't run through?
[15:41] <johnmce> gnuoy: Well, I seem to have a table that it thinks I shouldn't have.
[15:42] <johnmce> gnuoy: Presumably that table didn't exist pre-Juno, yet I seem to have it.
[15:42] <johnmce> gnuoy: If I don't need a schema update (migration), then the logic that determines when an upgrade should be performed must be broken.
[15:43] <gnuoy> johnmce, that is possible. Do you see any other evidence that the neutron db is not in the state it should be?
[15:43] <gnuoy> errors from neutron-server etx
[15:44] <johnmce> gnuoy: I'm not familiar with the db changes required for a Juno migration, so I wouldn't know what to look for. I've not check the neutron server logs.
[15:45] <gnuoy> johnmce, I'm just wondering if everything is rosy but, as you say, the logic around when to run the migration is broken
[15:46] <johnmce> gnuoy: Things are pretty broken generally right now, so I'm just taking it one step at a time. Been fixing up other charms as I go.
[15:47] <johnmce> gnuoy: Keystone, glance, horizon are all good, but nova_cc can't get past this
[15:48] <gnuoy> johnmce, when you say it can't get passed it do you mean a juju hook keeps erroring ?
[15:49] <johnmce> gnuoy: I've destroyed the nova-cc service and re-deployed numerous times, so mayb the migration happened before. The juju hook for shaed-db always fails. "'hook failed: "shared-db-relation-changed" for percona-cluster:shared-db'"
[15:51] <gnuoy> johnmce, right, I see. Sounds like a charm bug that migrations fail if the schema is already present.
[15:52] <gnuoy> johnmce, I can work on trying to reproduce and getting a fix tomorrow.
[15:52] <gnuoy> johnmce, could you raise a bug report please ?
[15:54] <johnmce> gnuoy: I don't mind fixing it myself, if I can get a handle on what it's doing. Do you have any idea offhand what clues the charm looks for the decide a migration is needed, or does it just unconditionally call the neutron-db-manage script?
[15:54] <lazyPower> Greetings #juju - UOS 1114 - Big Data track is goign to start in about 6 minutes.  If you'd like to participate - https://plus.google.com/hangouts/_/hoaevent/AP36tYfh0sDqCTgtXmsp4LRdu4lnwysNlJ0jMTS7tlh8HNWfgen-Tw?authuser=0&hl=en
[15:54] <gnuoy> johnmce, I think it blindly call it on the establishment of a relation with percona
[15:54] <johnmce> gnuoy: Mybe the logic should be in neutron-db-manage?
[15:55] <gnuoy> johnmce, yes, I think that is true. I wonder if the nova db manage utility can be rerun without explosions
[15:57] <johnmce> gnuoy: I'll try commenting that 'create table' bit out for now and see if I get to to progress to completion. Looks like it's got some broken logic somewhere though.
[15:59] <gnuoy> johnmce, I'm not sure I'd want to comment that 'create table' out tbh, you might get some unexpected results from neutron-db-manage
[15:59] <gnuoy> I'd be temted to mark the failed hook as resolved and see if things continue from there
[16:00] <johnmce> gnuoy: I've already tried repeatedly to say it's resolved, but it always re-runs that script. You'd think there'd use an "if not exists" type option on table creation.
[16:01] <gnuoy> yeah, that's be good
[16:01] <gnuoy> s/that's/that'd/
[16:09] <johnmce> gnuoy: This goes well beyond a single table. It's trying to create every table from scratch, when they already exist.
[16:12] <jamespage> gnuoy, dosaboy: did you have any thoughts on tuning down the log level across the openstack charms?
[16:12] <jamespage> dosaboy, just thinking about it in the context of the ceph-broker work but we probably need to discuss more generally on what's the right level
[16:13] <jamespage> dosaboy, I personally think our default level should be DEBUG with only end-user usefull info going at INFO level
[16:16] <dosaboy> jamespage: agreed
[16:16] <dosaboy> same as openstack
[16:16] <jamespage> dosaboy, oo - do they have that documented somewhere?
[16:16] <dosaboy> hmm lemme dig
[16:17] <jamespage> dosaboy, so a end use message would be "Configuring ceph storage pools with name XX, replicas XX"
[16:17] <jamespage> and "Storage pools configured, starting cinder volume service"
[16:17] <jamespage> maybe
[16:17] <jamespage> not use
[16:17] <jamespage> not sure
[16:18] <gnuoy> johnmce, I'm wondering if the stamp didn't get run
[16:19] <dosaboy> jamespage: *some* info here - http://docs.openstack.org/openstack-ops/content/logging_monitoring.html
[16:19] <dosaboy> lemme find better
[16:19] <dosaboy> https://wiki.openstack.org/wiki/LoggingStandards
[16:20] <gnuoy> neutron-db-manage --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/ml2_conf.ini stamp icehouse then upgrade head
[16:20] <dosaboy> jamespage: ^^
[16:21] <gnuoy> johnmce, ok, I think I see the bug
[16:22] <gnuoy> can you try running: neutron-db-manage --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/ml2_conf.ini stamp icehouse and see if the migration then runs cleanly ?
[16:23] <johnmce> gnuoy: Not read this properly yet, but it is related: http://www.gossamer-threads.com/lists/openstack/dev/42070
[16:25] <johnmce> gnuoy: Response to command: INFO  [alembic.migration] Context impl MySQLImpl. INFO  [alembic.migration] Will assume non-transactional DDL.
[16:26] <gnuoy> johnmce, yes, that thread looks to be the same issue
[16:28] <johnmce> gnuoy: Seems to be working now!
[16:28] <johnmce> gnuoy: thanks for your help
[16:28] <gnuoy> johnmce, np, I will fix that in the charms tomorrow
[16:30] <gnuoy> johnmce, sorry that you hit a bug. fwiw the bug is with line 522 of hooks/nova_cc_utils.py. that conditional shouldn't be there and was left over from when nova-cc and neutron-api where deciding between them on who should run the migration
[16:41] <johnmce> gnuoy: OK, I see the problem now. Thanks for the info. I'll modify my copy.
[16:46] <whit> working on aws, does anyone ever get a machine that reports itself as one  public ip, but when you ssh in, ssh thinks it's a different public ip?
[16:52] <lazyPower> whit: i've seen this behavior before - whats weird was querying the metadata url caused the ip's to correct themselves.
[16:53] <whit> lazyPower, tell me more about this metadate url?
[16:53] <lazyPower> whit: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
[16:53] <whit> lazyPower, danke
[16:54] <lazyPower> whit: no idea what caused the voodoo tbh - it was an isolated incident from another user that joined #juju ~ a week ago.
[16:54] <whit> lazyPower, wonder if that force the route to get set?
[16:55] <lazyPower> well, a curl tot he metadata url shouldn't have any effect - thats all set during cloud init
[16:55] <whit> I've seen it 3 times in the last week
[16:55] <whit> dunno
[16:59] <jose> whit: status will give the public IP, ssh will use the internal IP
[16:59] <jose> whit: or at least that's the behaviour I'm seeing on AWS
[16:59] <jose> probably using the bootstrap node as a proxy
[17:34] <lazyPower> jose: juju ssh does
[17:34] <lazyPower> all connectivity between the workstation and nodes proxies through the state server
[17:34] <jose> there it is
[19:00] <lazyPower> Juju Open feedback session is about to get started
[19:00] <lazyPower> https://plus.google.com/hangouts/_/hoaevent/AP36tYdwa3d9A4ohXuoRdM-SQCQSJUzu4xgEflvg996V8rMyAw427g?authuser=0&hl=en
[19:01] <lazyPower> if you'd like to join and add your view/comments/feedback we'd love to hear from you
[22:06] <whit> cmars, the one thing that comes to mind is that it might make sense to not run the collectic-metrics hook if a charm does not define any metrics


[02:11] <hyperair> argh
[02:11] <hyperair> is indicator-application meant to be started via dbus or upstart?
[02:12] <hyperair> i see an upstart job and no dbus job, but if you start indicator-application after it's crashed out via upstart, it refuses to stay alive
[02:12] <hyperair> it just says (process:1679): libindicator-WARNING **: No watchers, service timing out.
[02:12] <hyperair> and then it dies and gets restarted
[02:12] <hyperair> pfft
[02:16] <infinity> hyperair: Maybe restart unity-panel-service?
[02:17] <infinity> (shot in the dark, based on event deps)
[02:17] <hyperair> infinity: this is exactly what caused the problem in the first place
[02:17] <infinity> Oh. :)
[02:17] <hyperair> you restart unity-panel-service, and indicator-application goes down and refuses to come back up
[02:18]  * hyperair is affected by a compiz bug where it hangs when you change your screen configuration
[02:18] <hyperair> plug in external monitor -> hang
[02:18] <hyperair> unplug external monitor -> hang
[02:18]  * hyperair has a hotkey defined in compiz that allows me to kill compiz, so it's not like compiz itself is hung, just the displaying portion of it
[02:19] <hyperair> but it doesn't work if unity's running the lock screen
[02:19] <hyperair> oh wait a second...
[02:19] <hyperair> IT FINALLY STARTED
[02:19] <hyperair> YAY
[06:02] <pitti> Good morning
[06:51] <RAOF> pitti: Good morning!
[06:52] <pitti> hey RAOF, how are you?
[06:52] <RAOF> Surprisingly well, given Zoe's sleeping patterns of late :/
[06:53] <pitti> RAOF: heh, you are learning to sleep really fast?
[06:54] <RAOF> :)
[06:54] <RAOF> So, I've got two fun things for you! Firstly, I don't know why http://paste.ubuntu.com/7144964/ hangs in the read() of errfd.
[06:55] <RAOF> Secondly, if you comment out that read (and the associated check), you find that umockdev's evemu playback doesn't round-trip.
[07:00] <pitti> RAOF: the delays in the events are almost zero; could it be that the startup of evemu-record takes longer than 0.07 seconds, so it doesn't see any event any more?
[07:00] <pitti> RAOF: can you try replacing teh "0." with "1.", does it work then?
[07:00] <RAOF> pitti: I don't think so, because the first event matches up. I'll give that a whirl, though.
[07:00] <pitti> RAOF: instead of starting to replay events immediately it probably should wait some time before it starts the playback
[07:01] <pitti> RAOF: ah, nevermind, that was bogus
[07:01] <pitti> RAOF: playback starts when the client program open()s the device
[07:01] <pitti> RAOF: -EMONDAYMORNING
[07:01] <RAOF> :)
[07:01] <pitti> RAOF: do you actually expect any stderr output?
[07:01] <RAOF> No.
[07:02] <pitti> RAOF: I mean, SIGINT doesn't actually terminate the program, does it? that's like Ctrl+Z, or is that still Monday morning?
[07:02] <UserError> Has anyone ever looked at how insane the new deps for bamfdaemon and libunity-webapps0 are?
[07:02] <pitti> ah it is, that's SIGSTOP
[07:03] <RAOF> SIGINT is ctrl-C; it generally does terminate the program.
[07:03] <RAOF> (It terminates evemu-record)
[07:03] <UserError> Pulling in hundreds of megs of packages for no reason on non-Qt platforms sounds like a wonderful idea.
[07:04] <pitti> RAOF: do you have the output of evemu-record (i. e. "sout") when disabling the stderr read()?
[07:04] <pitti> RAOF: i. e. in what way it doesn't match up? (other than slightly different timestamps)
[07:05] <RAOF> pitti: I'll grab it again from gdb, but when I inspected it it terminated early.
[07:05] <pitti> RAOF: but that's a nice test, thanks for that
[07:07] <RAOF> pitti: Output is: http://paste.ubuntu.com/7145011/
[07:07] <doko> lool, gstreamer ping
[07:08] <RAOF> pitti: ie: we get the first 3 packets fine, and then stop for some reason.
[07:09] <pitti> RAOF: ok; I have no off-hand idea about that, that needs some in-depth debugging
[07:11] <infinity> UserError: Which Qt libs would those be?
[07:12] <UserError> All of them (Only half kidding)
[07:12] <UserError> do the chain of deps
[07:12] <UserError> http://packages.ubuntu.com/en/trusty/bamfdaemon
[07:12] <UserError> libunity should be a recommends to begin with, or hell even a suggests
[07:13] <UserError> but the service on libunity-webapps0 should be a recommends
[07:15] <UserError> having a library != wanting a service
[07:16] <infinity> UserError: unity-webapps-service links with libunity, you can't just magically make a linked library not necessary by changing the packaging.
[07:17] <infinity> UserError: And I'm still not seeing the Qt-related complaint...
[07:17] <RAOF> pitti: (a) Do you want this formalised somewhere (github issue, merge request?) and (b) are you in the mood for debugging it? :)
[07:18] <UserError> infinity because you failed to follow the dep chain
[07:18] <UserError> all the way down
[07:18] <pitti> infinity: would you have a minute to accept the postgresql-8.4 lucid/precise SRUs for bug 1294006, or tell me that I can/should self-review them? (bdmurray already accepted the corresponding -9.1 uploads)
[07:18] <UserError> i followed every fork in the road until i saw the insanity
[07:19] <pitti> RAOF: (a) can't hurt, git pull request sounds nice, then I have the new test ready for examination; (b) later today, yes; not right away I'm afraid
[07:19] <infinity> UserError: That's nice.  How about a hint, then.
[07:19] <UserError> bamfdaemon -> libunity-webapps0 -> unity-webapps-service -> webapp-container =
[07:19] <UserError>     libqt5core5a , libqt5gui5 , libqt5network5 , libqt5qml5 , libqt5quick5 , libqt5widgets5 , unity-webapps-qml.
[07:19] <infinity> pitti: If they match the ones bdmurray did, just self-accept.
[07:19] <UserError> and because ubuntu and debian now pull in recommends by default, just imagine
[07:19] <RAOF> pitti: Ok. I'll do (a) and then EOD; (b) is therefore not important :)
[07:20] <UserError> andddddd the library does indeed work without the service
[07:20] <infinity> UserError: So, perhaps you could have started with "does webapp-container really need to be installed" instead of where you did? :P
[07:20] <UserError> 0 for 2
[07:22] <UserError> just like bamfdaemon works without the webapp stuff they added in some 13.xx version
[07:22] <UserError> Are you people still depends-ing xprint6 too?
[07:22] <infinity> Though, it only seems to be installed by default on ubuntu-desktop anyway.
[07:23] <UserError> Right however sane package structure is the norm for a distribution with official and community spins
[07:23] <infinity> Fine.  File a bug.
[07:23] <UserError> It looks like it probably came in like that on some ubuntu-touch stuff because I recall it from around that time period
[07:24] <infinity> Yeah, it would have come from touch/unity8 integration.  Qt is sort of here to stay for Ubuntu.
[07:25] <UserError> So by default, 14.04 is using three frameworks?
[07:25] <UserError> unity*
[07:27] <RAOF> pitti: Enjoy your shiny new pull request!
[07:28]  * RAOF EOD
[07:31] <pitti> RAOF: thanks, good night!
[07:39] <dholbach> good morning
[07:40] <pitti> infinity: ack, done (postgresql SRU)
[08:07] <Noskcaj> Does anyone want to update clutter-gst-2.0 to 2.0.10? It fixes a memory leak and adds a few new interfaces
[08:11] <darkxst> Noskcaj, we are past feature freeze, and that doesn't look like a bug fix only reales
[08:11] <Noskcaj> darkxst, My thoughts too. I'll see how hard it would be to cherry pick the memory leak fix
[08:15] <darkxst> that said, it might be ok
[08:20] <infinity> pitti: Oh, Merry Christmas, BTW.  You have an autopkgtest flood.
[08:51] <lool> doko: pong
[08:52] <doko> lool, solved, problem introduced by siretart
[08:56] <Noskcaj> dholbach, Is there anything i should be doing to try and improve my chance of getting MOTU tomorrow morning?
[08:56] <Noskcaj> Or at least xubuntu packageset, since all my uploads there have been high quality
[08:58] <dholbach> Noskcaj, you could ask your sponsors to see if they update their testimonials?
[08:58] <dholbach> Noskcaj, I could have a look at updating mine if you give me the link to your application again
[09:00] <pitti> infinity: eglibc o'clock? :-)
[09:00] <doko> pitti, is the autopkgtest for mysql-5.6 5.6.16-1~exp1: RUNNING? blocks ncurses
[09:00] <seb128> crazy the number of uploads we get on freeze days :p
[09:01] <doko> pitti: python-flake8 autopkgtest always fails
[09:01] <pitti> doko: yep, that's a new test which is broken
[09:02] <pitti> doko: mysql-5.6 is actually running, yes; but for quite a while already
[09:02] <pitti> doko: eek, started two days ago; I suppose something in the test hangs and also kills the timeout timer, I kill it
[09:04] <doko> zul, python-taskflow autopkg test fails
[09:04] <Noskcaj> dholbach, https://wiki.ubuntu.com/Noskcaj#MOTU
[09:05] <Noskcaj> Although you testimonial is pretty good, maybe mention that there's around 100 sponsorings from you
[09:06] <Noskcaj> I've batch pinged a fair few other sponsors, no one replied, except logan, who said he wasn't ready to leave a testimonial
[09:07] <seb128> Noskcaj, one note from me is that you should be more selective in your updates after ff, you tend to merge on Debian when there are not so many useful changes that we need/the changes don't bring any real value (that adds reviews etc load which is not spent on bugfixes)
[09:08] <Noskcaj> seb128, That's actually something that's been making me think recently, just what level of fixes are worth uploads for
[09:08] <doko> Noskcaj, cherrypy3 autopkg test is failing
[09:08]  * Noskcaj looks
[09:09] <Noskcaj> I'm going to guess it's not from my change though
[09:10] <Noskcaj> um. link to tests plz
[09:12] <doko> Noskcaj, you should know about http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html ...
[09:13] <Noskcaj> doko, I've seen it before, just didn't know the location
[09:16] <apachelogger> Sweetshark: ping, when/why/how did the libreoffice package start recommending default-jre?
[09:18] <pitti> Noskcaj: what was the intention of the "make basic autopkgtest" in python-flake8?
[09:18] <pitti> Noskcaj: it just calls "flake8" without any arguments, but it should ceratinly be called on some python tree?
[09:19] <Noskcaj> Sounds like something i shouldn't have done, but i'm not allowed to be on the computer at the moment
[09:20] <Noskcaj> same applies to the cheerypy3 test failure
[09:20] <pitti> Noskcaj: I'll create some test files and run flake8 on that, and send it to Debian
[09:20] <Noskcaj> ty
[09:30] <Sweetshark> apachelogger: http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=06cc27ab781946cf92bc45dbf48fdd2ff8a46b0f;hp=ba56ec3d266f5f232304b13a80bb19b86e02c172
[09:30] <apachelogger> Sweetshark: is that absolutely necessary to be recommends? it made kubuntu amd64 go oversized quite a bit
[09:32] <Laney> doko: are you planning on fixing plainbox for 3.4?
[09:33] <pitti> doko: python-flake8 autopkgtest fix uploaded, and bug/patch sent to debian
[09:33] <doko> Laney, ugh, wasn't aware that it is broken ...
[09:33] <Laney> I don't know if the code is, but X-Python3-Version << 3.4
[09:33] <Laney> zyga: ^?
[09:34] <zyga> Laney: we're uploading 0.5 without that today
[09:34] <zyga> Laney: which is okay on 3.4
[09:34] <zyga> Laney, doko: so please hold on and approve the sync request from debian instead
[09:34] <doko> zyga, debian only has beta2
[09:35] <doko> zyga, do you want to have a look at the bzr test failures?
[09:35] <zyga> doko: yes, we've fixed the final i18n bug on Sunday
[09:35] <zyga> doko: gladly but I need to upload 0.5 first, give me one hour please
[09:42] <pitti> zul: python-taskflow autopkgtest failure shows the missing new dependency on -kazoo; I filed bug 1296607
[09:44] <doko> Laney, https://bugs.launchpad.net/ubuntu/+bug/1282837 is this approved by you?
[09:46] <Laney> doko: yes, but why has it lingered for a month?
[09:46] <doko> ask ubuntu-archive?
[09:47] <Laney> doesn't seem to be in their queue
[09:48] <Laney> also you ∈ ubuntu-archive :P
[09:48] <doko> no, just for test rebuilds and mir
[09:48] <Laney> hmm
[09:49] <doko> we really need to revisit all these teams, and who is working when on things ...
[09:50] <Laney> maybe I should have subscribed the sponsors
[09:50] <Laney> how did you come across it?
[09:55] <ogra_> xnox, it looks like your autopilot change causes some havoc ...
[09:56] <ogra_> xnox, if you look at the .crash files on all these failed tests on http://ci.ubuntu.com/smokeng/trusty/touch/mako/255:20140323:20140304/7336/
[09:56] <ogra_> the error is always: apparmor.click.AppArmorException: "Could not find '/usr/share/autopilot-touch/apparmor/click.rules'"
[10:11] <rbasak> stokachu: ^^ who are you expecting to land bug 1282837?
[10:17] <zequence> any archive admins around?
[10:18] <zequence> ubuntustudio-live needs approval, getting close to release time and it would be nice to have it on our ISO ASAP :)
[10:19] <Laney> zequence: it is already in
[10:19] <Laney> laney@iota> rmadison -S trusty ubuntustudio-live                                                                                ~ ubuntustudio-live | 1 | trusty/universe | source, all
[10:19] <zequence> Laney: Ah, great. Missed it. Thanks!
[11:42] <zul> pitti:  i saw thanks
[12:10] <ogra_> do we have any bootchart specialists ? i'm wondering why --crop-after is racy for me ... i sometimes get http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-255.png ... which is properly cropped after unity8 ... but http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-256.png then again doesnt crop at all
[12:19] <marga> Hey all, we are seeing trusty installs failing due to python 3.4 change.
[12:19] <marga> I'm about to report a bug, but wanted to know if this was a known issue already.
[12:22] <seb128> doko, ^
[12:23] <seb128> marga, hey, I noticed the daily iso failed on some python error as well, so I guess it's somewhat known
[12:23] <marga> Yes, pkern had already pinged doko privately.  In any case, I'll just file the bug :)
[12:23] <marga> seb128, known but not reported?
[12:25] <seb128> marga, there is at least one reported against plainbox it seems
[12:26] <marga> Yeah, I'm looking at https://bugs.launchpad.net/ubuntu/+source/plainbox/+bug/1289334, but it's older
[12:26] <marga> This one: https://bugs.launchpad.net/ubuntu/+source/plainbox/+bug/1296588
[12:27] <jibel> marga, could you file a bug and we'll duplicate if it is already known.
[12:27] <marga> jibel, it's this second one.
[12:28] <jibel> marga, okay. zyga will upload plainbox .5 to fix this.
[12:28] <marga> Ok, good
[12:29] <zyga> hmm
[12:30] <zyga> I'm seeing strange failures on precise that weren't there before
[12:30] <doko> zyga, please can we fox this now?
[12:30] <zyga> doko: trying to
[12:30] <zyga> doko: but this prevents us landing stuff to trunk
[12:30] <zyga> sphinx fails to build correct documentation with nothing but 'error: None' and return code1
[12:30] <zyga> nothing in sphinx changelog seems to explain why
[12:31] <doko> zyga: do you have a candidate package?
[12:32] <zyga> doko: in debian svn, the only thing I need is the documentation update and the final tarball that cannot generate because of that sphinx failure
[12:33] <zyga> ohhh, I think i found it
[12:33] <doko> zyga, I don't care, I would rather upload an interim package to fix the installation failure first
[12:33] <maxiaojun> any news for usb-creator?
[12:34] <zyga> doko: sync 0.5b2 from unstable
[12:34] <zyga> doko: I fixed the issue
[12:35] <zyga> doko: give me 3 minutes and everything will be ready
[12:40] <maxiaojun> xnox: ping
[12:43] <zyga> doko: plainbox-0.5 upstream released, debian packaging updated, request for sync sent, looking at the ubuntu package now
[12:52] <zyga> doko: so how should we release plainbox-0.5 into ubuntu now? can you somehow sponsor it to debian? or would you rather sync 0.5b2 which is in unstable already?
[12:52] <doko> zyga, already synced
[12:52] <zyga> doko: thanks
[12:52] <zyga> doko: will you fix 0.5 once it lands, it fixes i18n bugs that we'd like to see in 14.04
[12:52] <doko> zyga, sure I can do that, just put a signed dsc somewhere
[12:53] <zyga> doko: I never uploaded plainbox to debian myself, I always requested sponsorship, not sure what I need to do to give you the final .dsc
[12:54] <doko> zyga, who did in the past?
[12:54] <zyga> doko: p1otr (Piotr Ożarowski)
[12:54] <zyga> doko: I sent him RFS a few minutes ago
[13:06] <cjwatson> infinity: thanks for sorting out the coreutils build failure, I'd been stuck on that
[13:35] <sforshee> pitti: I'm trying to work out how to trigger a bug report for a certain condition from the kernel. One possible trigger would be the appearance of a certain file in /var/log - does apport support anything like that?
[13:45] <stokachu> rbasak: smoser was handling it i thought
[13:46] <doko> stokachu, rbasak: cloud-installer (- to 0.1+bzr111-0ubuntu1)
[13:46] <doko>     Maintainer: Ubuntu Developers
[13:46] <doko>     Section: universe/admin
[13:46] <doko>     0 days old
[13:46] <doko>     cloud-install-landscape/amd64 unsatisfiable Depends: cloud-installer
[13:46] <doko>     cloud-install-multi/amd64 unsatisfiable Depends: cloud-installer
[13:46] <doko>     cloud-install-single/amd64 unsatisfiable Depends: cloud-installer
[13:46] <doko>     cloud-install-landscape/arm64 unsatisfiable Depends: cloud-installer
[13:46] <doko>     cloud-install-multi/arm64 unsatisfiable Depends: cloud-installer
[13:46] <doko>     cloud-install-single/arm64 unsatisfiable Depends: cloud-installer
[13:46] <doko>     cloud-install-landscape/ppc64el unsatisfiable Depends: cloud-installer
[13:47] <doko>     cloud-install-multi/ppc64el unsatisfiable Depends: cloud-installer
[13:47] <doko>     cloud-install-single/ppc64el unsatisfiable Depends: cloud-installer
[13:47] <doko>     Not considered
[13:47] <stokachu> doko: nice
[13:51] <doko> stokachu, well, only nice if you fix it ;p
[13:51] <stokachu> doko: yea i think its b/c of the architecture set in it
[14:04] <pitti> sforshee: we'd need to wire that through an upstart job
[14:04] <pitti> sforshee: that's fairly similar to what we are already doing with pretty much all other crashes
[14:05] <pitti> sforshee: e. g. /usr/share/upstart/sessions/update-notifier-crash.conf
[14:06] <pitti> sforshee: we also used to have (not sure if it still works) integration with kerneloops which calls /usr/share/apport/kernel_crashdump on an oops
[14:08] <sforshee> pitti: I'm looking at kerneloops too but the spewage in dmesg would need to be changed to be more consistent
[14:08] <sforshee> pitti: but the upstart job might work, I'll play with that. Thanks.
[14:09] <pitti> sforshee: another option might be to send an uevent, if you can do that in that situation
[14:09] <sforshee> pitti: there is a uevent, another option I'm considering :-)
[14:09] <pitti> sforshee: wiring through an udev rules avoids assuming a particular init system, if you want to use this for other distros (e. g. upstreaming to linux), and in ubuntu's future
[14:10] <sforshee> pitti: do you know of an example of doing it that way from a udev rule?
[14:11] <pitti> sforshee: in the past we used to have that for missing firmware
[14:11] <pitti> sforshee: e. g. the hplip bits listened for that, and we also plumbed it into jockey
[14:11] <pitti> sforshee: but no existing example for something crash-y
[14:12] <sforshee> pitti: okay, thanks. I'll look into doing it that way too.
[14:20] <dholbach> seb128, not sure if I read the excuses list correctly, but python3-defaults not moving out of -proposed is because of dh-python tests failing somehow? seb128, looks like dh-python failed somehow? https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-dh-python/ARCH=amd64,label=adt/ - not sure if I read the excuses list properly
[14:20] <dholbach> oops
[14:21] <doko> dholbach, correct, apparently I'm still missing some tests. but maybe barry can help ;p
[14:22] <dholbach> doko, great - I was just looking at why this was one failing https://launchpadlibrarian.net/170552764/buildlog_ubuntu-trusty-i386.click-reviewers-tools_0.6-0~181~ubuntu14.04.1_FAILEDTOBUILD.txt.gz - but I guess the two are related :)
[14:24] <doko> dholbach, it did succeed here: https://launchpad.net/ubuntu/+source/click-reviewers-tools/0.5build1
[14:24] <barry> doko: hi
[14:24] <seb128> doko, dholbach: the ppa doesn't use trust-proposed so it still tries to build for the old python version
[14:24] <doko> ahh, ok
[14:24] <dholbach> ah, that makes sense then
[14:24] <dholbach> thanks guys :)
[14:24] <doko> which ppa?
[14:25] <dholbach> doko, https://launchpad.net/~ubuntu-sdk-team/+archive/staging
[14:25] <seb128> it probably makes sense for a ppa you recommend to users
[14:25] <seb128> you don't want the to get proposed updates with it
[14:25] <doko> sure
[14:27] <glambert> hi, how do you generate a new random-seed file?
[14:30] <cjwatson> glambert: it's done at every shutdown by /etc/init.d/urandom
[14:31] <cjwatson> sudo dd if=/dev/urandom of=/var/lib/urandom/random-seed bs="$(( ($(cat /proc/sys/kernel/random/poolsize) + 7) / 8 ))" count=1
[14:31] <cjwatson> should do it manually
[14:32] <cjwatson> I don't see why you would need to do it manually though, given that it's only read on startup
[14:32] <cjwatson> And all that's done at startup is to shove it back into /dev/urandom
[14:32] <glambert> cjwatson, I'm writing a version of the virt-sysprep tool from libguestfs that I'm tweaking to suit my needs but also trying to port all of the tools they have
[14:33] <glambert> generating a new random-seed file is one of the things on there
[14:33] <cjwatson> Ah, makes sense
[14:33] <glambert> but given that I'm going to be running my version on the guest rather than on the host
[14:33] <glambert> if it's all done at startup I don't suppose I need to do anything
[14:33] <cjwatson> I think you need to run it on the host - until you've seeded the RNG you don't have meaningful entropy in the guest, surely
[14:34] <cjwatson> Well, it's done at startup/shutdown, but you might well end up with a weak RNG in the guest if you don't do anything
[14:34] <cjwatson> It's good practice to give it some entropy from an environment that actually has some
[14:35] <glambert> cjwatson, I can't run it on the host, the virtual machines are running in network storage and the virt-sysprep tool can't connect to them
[14:35] <glambert> hence the reason for going it alone so to speak
[14:35] <cjwatson> You might consider installing something like haveged in the guest to assist
[14:35] <cjwatson> (Though IANA cryptographer)
[14:54] <shadeslayer> seb128: seems that protocol handling is semi working now
[14:54] <shadeslayer> for firefox
[14:54] <shadeslayer> seb128: however firefox is still not reading /etc/firefox/pref/apturl.js
[14:54] <shadeslayer> symlinking it to /usr/lib/firefox/browser/defaults/preferences/apturl.js makes stuff work
[14:54] <seb128> shadeslayer, it's not supposed to
[14:55] <shadeslayer> but as noted before, that's wrong :P
[14:55] <seb128> yeah
[14:55] <seb128> chrisccoulson said that firefox needs to be fixed
[14:56] <shadeslayer> chrisccoulson: ^^ when you fix apturl , please poke me too, I'd like to register some extra protocols for KDE like magnet link handling and such
[14:58] <seb128> shadeslayer, I don't think apturl needs fixing, it's firefox which does, nothing prevents you do add handlers to KDE meanwhile
[14:58] <shadeslayer> seb128: sure, but how do I do that?
[14:58] <shadeslayer> I mean, I can do them via browser/defaults/preferences
[14:59] <chrisccoulson> application/x-scheme-handler, like every other handler ;)
[14:59] <chrisccoulson> you don't add them in firefox
[14:59] <shadeslayer> okay, ktorrent for eg doe register magnet links in application/x-scheme-handler
[14:59] <seb128> shadeslayer, you add e.g "x-scheme-handler/apt" to the MimeType of the .desktop
[14:59] <shadeslayer> but firefox doesn't open it
[15:00] <seb128> right, firefox needs to be fixed
[15:00] <seb128> the url handler code is buggy
[15:00] <seb128> that's what chrisccoulson said at least
[15:00] <chrisccoulson> it used to work, and then regressed over a year ago
[15:00] <chrisccoulson> it's only the last few weeks that people have been mentioning it ;)
[15:11] <stgraber> cjwatson: just sent an e-mail to u-d-a if you have a sec to approve
[15:13] <cjwatson> stgraber: done
[15:14] <stgraber> thanks
[15:17] <pitti> hallyn: congratulations to your shiny new core-dev badge!
[15:18] <ogra_> pitti, i know you are familiar how bootchart works, do you know whats the condition for the --crop-after arg ? i suddenly got a bootchart like http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-255.png (properly cropped) while they usually look like http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-25&.png
[15:18] <ogra_> err
[15:19] <ogra_> while they usually look like http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-256.png
[15:22] <pitti> ogra_: it's a list of process names at whose appearance (any, not all) the boot is considered "done"
[15:22] <ogra_> pitti, right, i added unity8 to that
[15:22] <pitti> ogra_: e. g. the cron job does --crop-after=compiz,metacity,mutter,kwin,xfwm4,unity8
[15:22] <pitti> and all CPU usage after that is attributed to user action
[15:22] <ogra_> (and i'm actually creating the png locally with pybootchartgui with that arg)
[15:23] <pitti> ogra_: but I'm actually not entirely sure how that works entirely, as normally cropping should happen once the CPU goes idle
[15:23] <ogra_> right
[15:23] <ogra_> thats what the documentation says
[15:23] <pitti> oh right, the documentation even says that
[15:23] <pitti> that process runs AND CPU is idle
[15:23] <ogra_> and there is no CPU use ...
[15:23] <pitti> as it can be idle in between (like, waiting for a driver to load or so)
[15:24] <pitti> ogra_: so I do see unity8 on the second chart; was that done with the same parameters?
[15:25] <ogra_> pitti, yes, its a script i run locally on a N4 with broken screen (great use for the broken phones)
[15:25] <ogra_> all bootcharts in that dir are created by the same script
[15:25] <pitti> heh
[15:26] <ogra_> http://paste.ubuntu.com/7146809/
[15:26] <ogra_> thats the script
[15:38] <ogra_> hallyn, OOOH !congrats !
[15:38] <highvoltage> hallyn: congrats!
[15:58] <cjwatson> doko: dh-python autopkgtest still fails - maybe try http://paste.ubuntu.com/7146925/ ?
[15:59] <cjwatson> doko: t204 looks a bit dodgy too
[16:00] <hallyn> thanks :)
[16:01] <doko> cjwatson, hmm, but it's strange that it did succeed earlier this release cycle ...
[16:02] <barry> cjwatson, doko yeah, they do.  i need to finish up something in progress, and get lunch, but i can start to look afterward
[16:03] <doko> thanks, afk now for some hours
[16:05] <cjwatson> doko: well there was a non-trivial merge in there IIRC
[16:17] <cjwatson> barry: ok, soon would be good since it's making click tests fail
[16:17] <barry> cjwatson: ack
[16:38] <asac> awe_: cyphermox: do you know if NM is going to ofono or
[16:38] <asac> is MM still the focus for dan?
[16:39] <awe_> asac, not sure...
[16:39] <pitti> doko: dh-python autopkgtest fixed, FTR
[16:39] <asac> awe_: got pinged by debian about updating MM package to 1.0+
[16:39] <awe_> I know he was interested in our ofono support, but not sure if he has plans to merge any of it soon?
[16:39] <asac> so wondered if we rather want to drop it and go ofono.. but seems not
[16:40] <asac> ok so surely not yet superseded upstream. thats enough info
[16:40] <cyphermox> no, it's MM
[16:40] <awe_> yea, that might be too premature
[16:40] <asac> cyphermox: would the 1.0 package we have in trusty be good for debian?
[16:40] <cyphermox> asac: it's already in experimental
[16:40] <awe_> also there's always going to a be a set of modems that MM will support better than ofono
[16:40] <asac> cyphermox: i know. but people want it in sid i guess
[16:40] <cyphermox> and we'll upload 1.2 to experimental or unstable soon too
[16:40] <cyphermox> yes
[16:40] <asac> what is holding that back?
[16:40] <asac> ah good
[16:40] <asac> ETA?
[16:40] <cyphermox> as I recall it was breaking parts of KDE
[16:40] <cyphermox> maybe this week?
[16:40] <cyphermox> depends how much time I can spend on that
[16:40] <asac> cyphermox: you work with mbiebl on this in debian?
[16:41] <cyphermox> yeah
[16:41] <asac> kk
[16:41] <asac> will forwar that info to richi then
[16:41] <cyphermox> I already told him
[16:42] <asac> kk
[17:19] <vlad_starkov> QUESTION (cross-post): Can't boot on freshly installed 12.04.4 64bit. Got multiple CPU soft lockup messages. Could someone point me how to boot in verbose/debug mode to figure out what's going on?
[17:46] <barry> cjwatson, doko dh-python 1.20140128-1ubuntu8 passed dep8 and is being propomted
[17:46] <cjwatson> yay, thanks
[17:46] <barry> cjwatson: i can't take any credit.  looks like pitti fixed the 2.6 bits
[17:46] <cjwatson> transfer as appropriate :)
[17:47] <pitti> :)
[17:47] <barry> :)
[17:47] <pitti> that should also make python-defaults go in finally
[17:47] <ScottK> barry: It fails in Debian CI too, so please fix there as well.
[17:47] <barry> ScottK: ah
[17:48] <pitti> barry: well, it rather just disables three explicit "2.6" checks; I'm not entirely sure how that's supposed to work in dh-python (e. g. if you have an explicit python2.6 shebang, but 2.6 isn't supported)
[17:48] <pitti> but as ScottK says, it's failing in Debian as well, so I hope Piotr will fix it properly
[17:55] <infinity> mwhudson: I assume you're keeping an eye on https://sourceware.org/bugzilla/show_bug.cgi?id=16629 for me so I don't have to, and you'll let me know when Will has a patch that actually works for you? :P
[18:11] <cjwatson> doko: did you notice the arm64 build failure in your gluegen2 sync?
[18:58] <kirkland> glambert: cjwatson: is someone in need of an RNG seed at first boot?  :-)
[18:58] <kirkland> there's an app for that :-)
[18:59] <kdeuser56> somehow I get the impression apport is buggy as hell:  it overwrites existing reports in /var/crash if the same binary crahes again
[19:00] <kdeuser56> that way I cannot keep record of crashes happened on my system ...
[19:04] <kdeuser56> pitti: any idea?
[19:09] <doko> cjwatson, yes, known. regression when we switch from zero to hotspot. will need to fix this next week with an openjdk-7 update
[19:17] <doko> cjwatson, can you give me a hint why python3-stdlib-extensions won't migrate?
[19:19] <kdeuser56> how does the naming scheme of apport work? what means 1000.crash?
[19:20] <ogra_> kdeuser56, thats the UID
[19:21] <kdeuser56> ogra: always the same here ...
[19:21] <ogra_> always the same user then
[19:21] <kdeuser56> ogra_: okay ... but what happens if the same program crashes again?
[19:21] <kdeuser56> ogra_: I suppose the file gets overwritten?
[19:22] <ogra_> might be, ask the author :)
[19:22] <ogra_> i would guess they are though
[19:23] <kdeuser56> ogra_: it is certainly like that... now I am asking myself whether apport is that sophisticated that it automatically tries to detect if a backtrace is similar and if not ... write a new file ...
[19:23] <kdeuser56> ogra_: but I can't imagine that ...
[19:23] <kdeuser56> ogra_: there would be a very simple solution to that: simply add a time stamp in the filename ...
[19:24] <ogra_> apport surely knows if a backtrace is identical ... well, at least the launchpad side of it does (so i guess the local one does too)
[19:25] <kdeuser56> ogra_: do you have any idea how I could simulate crashes?
[19:26] <ogra_> easiest is to kill a python app that creates a traceback i think
[19:26] <ogra_> (also wont make the backtras so big)
[19:26] <ogra_> *backtrace
[19:26] <kdeuser56> ogra_: will the trace always be identical if I kill the same application?
[19:27] <ogra_> if you kill it at the same point
[19:27] <kdeuser56> ogra_: do you know some example python app from the repos that is not that big?
[19:28] <ogra_> not of the top of my head ... juust take something installed
[19:29] <dobey> i think apport auto-increments
[19:30] <dobey> or maybe not
[19:31] <kdeuser56> dobey: then why is there only one timestamp in one file?
[19:31] <dobey> but you shouldn't be crashing the same app in 10 different ways so often anyway
[19:31] <kdeuser56> dobey: that should not matter
[19:31] <dobey> then file a bug against apport if it doesn't handle some case as well as it should
[19:37] <kdeuser56> dobey: could the file ./usr/lib/python2.7/dist-packages/apport_python_hook.py
[19:37] <kdeuser56> be responsible for writing the files?
[19:37] <kdeuser56> ./usr/lib/python3/dist-packages/apport_python_hook.py is the same ...
[19:38] <cjwatson> doko: it makes idle-python3.3 uninstallable, and proposed-migration doesn't know that you're intending to get rid of python3.3
[19:39] <cjwatson> doko: (can't look further now)
[19:40] <doko> cjwatson, well, ok to remove python3.3? will make pystache uninstallble. nothing else
[19:40] <dobey> kdeuser56: i don't know what code exactly is responsible for generating the file names. it should be obvious. and you should work against a bzr branch of apport, not against the installed files
[19:40] <cjwatson> doko: ask me tomorrow
[19:40] <doko> ok
[19:41] <kdeuser56> dobey: yeah, but this looks like it is what I am looking for:  pr_filename = '%s/%s.%i.crash' % (os.environ.get(
[19:41] <kdeuser56>             'APPORT_REPORT_DIR', '/var/crash'), mangled_program, user)
[19:42] <dobey> ok
[19:42] <dobey> then file a bug and make a branch
[19:42] <kdeuser56> dobey: okay I have the bzr branch ... it is in the file apport_python_hook.py
[19:43] <kdeuser56> dobey: how can I regenerate the package and install to test my changes?
[19:43] <Noskcaj> pitti, From yesterday, the flake8 autopkgtest was taken from somewhere, i forget where
[19:43] <dobey> kdeuser56: many ways. i don't know how apport is built exactly though
[20:07] <smoser> stupid question. is there an easy way to ask dpkg "is package foo installed with 'ii'" ?
[20:12] <rbasak> smoser: I looked at dpkg-query -W --showformat. Something like dpkg-query -W --showformat '${Status}\n' foo or dpkg-query -W --showformat '${db:Status-Abbrev}\n' foo seems cleaner.
[20:12] <rbasak> smoser: (but I'm not sure that's really any better)
[20:40] <dakira> Hi. I found a bug in a totem plugin (subtitle downloader) and fixed it. I added a patch to the package and proposed it for merging. Whats the next step?
[20:41] <dakira> https://code.launchpad.net/~mniess/ubuntu/trusty/totem/fix-lp1292262/+merge/212324
[20:41] <Noskcaj> dakira, Wait
[20:41] <Noskcaj> Someone will eventually upload it
[20:42] <dakira> Noskcaj: you mean if it's any good ;)
[20:42] <Noskcaj> I'll do a quick review, but i can't upload
[20:42] <dakira> Noskcaj: okay.. but that answers my question. I don't need to subscribe anyone.
[20:42] <dakira> Thanks!
[20:42] <Noskcaj> Ubuntu-branches autosubscribes to it
[20:44] <Noskcaj> But you need to make "trusty" the target release, and if possible, fill out the dep-3 header
[20:44] <Noskcaj> Also the patch should be forwarded to debian and gnome
[20:47] <dakira> Noskcaj: the bug was fixed in gnome. but only in 3.12. So I just took the fix to 3.10.
[20:48] <Noskcaj> dakira, ok. Make sure you mention that in the patch dep3 header
[20:53] <dakira> Noskcaj: I'm reading up on dep3 right now. That header goes at the beginning of the patch file?
[20:53] <Noskcaj> yep
[20:53] <Noskcaj> The header isn't really needed, but it makes your work better and others can understand the patch
[20:53] <Noskcaj> Plus it's good to practise
[20:55] <dakira> Noskcaj: okay. So after I pushed my changes, do I need to resubmit the merge proposal?
[20:55] <Noskcaj> you shouldn't have to
[20:57]  * hallyn feeling no love for whoever decided a terminal shouldn't be a default icon in unity
[21:01] <dakira> Noskcaj: if the description gets longer, can I just split lines or does it all have to be in one line?
[21:03] <Noskcaj> dakira, use http://paste.ubuntu.com/7148240/ as a template for that bit
[21:03] <Noskcaj> and http://dep.debian.net/deps/dep3/ is the page about dep3
[21:03] <Noskcaj> thanks for your work
[21:12] <dakira> Noskcaj: thanks for the pointers. I pushed the changes.
[21:13] <Noskcaj> :)
[21:14] <Noskcaj> looks all good. It should get sponsored this week. thanks
[21:15] <dakira> So how do I forward this to Debian? The Gnome folks only fixed this in 3.12
[21:16] <Noskcaj> dakira, debian's in the process of packaging 3.12, i don't think you need to
[21:16] <dakira> okay ;)
[23:51] <sarnold> infinity: is the archive supposed to still be frozen after the beta 1 has been released?
[23:52] <infinity> sarnold: It will be, yes.  Same as we did last cycle.
[23:52] <infinity> sarnold: As my email reads, unseeded stuff will auto-accept, but we'll be reviewing seeded uploads.
[23:52] <sarnold> ah and there's the explanatory mail :)
[23:53] <sarnold> thanks infinity


[11:15] <Laney> If I have an upload to Ubuntu that was binary copied from a PPA, how can I find out which PPA it was copied from? We've got something in proposed-migration which is looking at 'build_link' of the BPPHs, but that is of course wrong if the upload was binary copied through multiple archives since it shows the one it was built in initially.
[11:15] <Laney> A few days ago we had an upload mis-copied due to this
[11:16] <cjwatson> I am not completely sure that you can find out the path
[11:16] <cjwatson> I think we only track the initial upload archive and the current one
[11:21] <Laney> Looks like it - I couldn't find anything in there anyway
[13:05] <seb128> hey there :)
[13:05] <seb128> where is the right place to report bugs https://dev.launchpad.net/Getting ?
[13:05] <seb128> that page is still suggesting checking the source from bzr, that's wrong right?
[13:19] <wgrant> seb128: Ah, /Running was updated but not /Getting. Thanks; fixing.
[13:19] <seb128> wgrant, thanks
[13:22] <wgrant> Fixed.
[13:30] <seb128> wgrant, thanks
[13:30] <seb128> next question, following https://dev.launchpad.net/Running/LXD ... should ssh to the lxc instance work out of the box?
[13:31] <seb128> it didn't here, I had to lxc shell and ssh-import-id to get it working
[13:34] <wgrant> seb128: Hm, it's possible LXD config has drifted, but the given config is meant to mount your home directory... I guess it assumes that your SSH key is in your own authorized_keys, which is perhaps an erroneous assumption.
[14:37] <seb128> hum
[14:38] <seb128> make schema failed for me
[14:38] <seb128>   File "security.py", line 62, in _split_postgres_aclitem
[14:38] <seb128>     ACLITEM_RE.match(aclitem).groups())
[14:38] <seb128> AttributeError: 'NoneType' object has no attribute 'groups'
[14:38] <seb128> Makefile:111: recipe for target 'create' failed
[14:43] <wgrant> seb128: Which Ubuntu series, which PostgreSQL version?
[14:44] <seb128> wgrant, I'm following the website, it's a xenial lxc container
[14:44] <seb128> wgrant, ii  postgresql-10                        10.9-0ubuntu<IP_ADDRESS>~ubuntu16.04.1        amd64        object-relational SQL database, version 10 server
[14:45] <wgrant> Hm, very strange. Full make schema output?
[14:46] <seb128> wgrant, https://people.canonical.com/~seb128/launchpadlog
[14:47] <wgrant> seb128: Very, very strange. What's your username in the container?
[14:48] <seb128> wgrant, seb128
[14:51] <wgrant> I wonderif the regex doesn't like digits. Testing.
[14:55] <wgrant> seb128: Can you add "print aclitem" at the start of _split_postgres_aclitem?
[14:55] <wgrant> And rerun and show me the output
[14:56] <wgrant> Oh i see
[14:56] <wgrant> QUOTED_STRING_RE = '(?:([a-z_]+)|"([^"]*(?:""[^"]*)*)")?'
[14:57] <wgrant> seb128: If you change that to '(?:([a-z0-9_]+)|"([^"]*(?:""[^"]*)*)")?' it should work
[14:59] <wgrant> if (!isalnum((unsigned char) *src) && *src != '_')
[15:07] <seb128> wgrant, no crash, thanks
[15:11] <wgrant> https://code.launchpad.net/~wgrant/launchpad/+git/launchpad/+merge/380297
[15:13] <seb128> wgrant, k, so I've it running but not happy, the launchpad.test resolution doesn't work, and connecting to the IP of the lxc instance I've a launchpad frontpage but with an error, I don't know if that's a side effect for the schema problem
[15:13] <seb128> Traceback (most recent call last):
[15:13] <seb128>     Module zope.publisher.publish, line 144, in publish
[15:13] <seb128>     result = publication.callObject(request, obj)
[15:13] <seb128>     Module lp.services.webapp.servers, line 1526, in callObject
[15:13] <seb128>     raise NotFound(self, '', request)
[15:13] <seb128> NotFound: Object: <lp.services.webapp.servers.ProtocolErrorPublication object at 0x7fdf1a4e6090>, name: ''
[15:13] <wgrant> seb128: Launchpad requires a valid Host header
[15:14] <wgrant> id you set up /etc/hosts on the host?
[15:14] <seb128> there is one which has been created for me
[15:14] <seb128> it has a line
[15:14] <seb128> # Launchpad virtual domains. This should be on one line.
[15:14] <seb128> <IP_ADDRESS>      launchpad.test....
[15:14] <wgrant> ("Amending the hosts file" on https://dev.launchpad.net/Running/RemoteAccess, linked from Running/LXD)
[15:14] <wgrant> Right, rocketfuel-setup does that in the container
[15:15] <wgrant> RemoteAccess tells you to add a similar thing to the host's /etc/hosts.
[15:16] <seb128> wgrant, that's step 6 on https://dev.launchpad.net/Running/LXD and I was still at step 5
[15:17] <wgrant> seb128: Hm, did something tell you to visit the webapp before then?
[15:17] <seb128> step 5 points to https://dev.launchpad.net/Running
[15:17] <seb128> the "running section on this page"
[15:17] <seb128> Point your usual web browser at https://launchpad.test, and accept the local self-signed certificate. You can log in as<EMAIL_ADDRESS>without a password.
[15:18] <seb128> after make run
[15:18] <wgrant> Ah
[15:37] <seb128> wgrant, bah, now firefox refuses to load the page with a SSL_ERROR_RX_RECORD_TOO_LONG
[15:38] <seb128> which it doesn't let me ignore/override
[15:38] <wgrant> seb128: Try restarting (not reloading) apache2 in the container
[15:38] <wgrant> Sometimes mod_ssl doesn't load properly the first time. It's a bit weird.
[15:40] <seb128> wgrant, that doesn't help :/
[15:41] <wgrant> seb128: Oh, did you set LISTEN_ADDRESS properly?
[15:42] <wgrant> What does the apache config look like? local-launchpad site
[15:42] <seb128> wgrant, I guess not, https://dev.launchpad.net/Running/RemoteAccess is not clear about where that make install should be run from
[15:42] <seb128> I guess from launchpad/launchpad?
[15:42] <wgrant> seb128: Almost all operations on Launchpad should run from the root of the Launchpad source tree.
[15:42] <wgrant> SuSame place the rest of the build rocess was run from
[15:43] <seb128> k, that was it
[15:43] <seb128> sorry for overlooking this one
[15:43] <seb128> wgrant, thanks for the help, I've a working instance now!
[15:44] <wgrant> Given almost everyone uses LXD now, it may make sense to merge these pages
[16:44] <seb128> wgrant, minor but on https://dev.launchpad.net/Getting it still states 'Launchpad's branches are hosted in Bazaar.' also a checkout is around 300M nowadays
[16:45] <wgrant> seb128: It's 210M download + 90MB of source tree; I updated the numbers just now
[16:45] <wgrant> And meant to s/Bazaar/Git/ but apparently failed, good catch
[16:46] <wgrant> Fixed
[20:55] <gouthamr> Hi, i have an issue with private security bugs on launchpad that seem to be discoverable
[20:56] <gouthamr> should i report this issue via https://answers.launchpad.net/launchpad/+addquestion ?
[21:01] <sarnold> gouthamr: could you email<EMAIL_ADDRESS>I don't think there's a mechanism for private questions on launchpad's questions interfaces, and this feels like it might be worth keeping it private, at least initially
[21:01] <gouthamr> sarnold: ack, ty will do
[21:01] <sarnold> (launchpad's bugs mechanism does, but I'm not sure if the launchpad team actively tracks those or not)
[21:01] <sarnold> thanks gouthamr :)
[21:04] <gouthamr> you're welcome!
[22:19] <cjwatson> sarnold,gouthamr: We track private security bugs on Launchpad
[22:20] <gouthamr> cjwatson: oh, should i report one as a private security bug against https://bugs.launchpad.net/launchpad ?
[22:20] <cjwatson> gouthamr: That's the right place, yes
[22:20] <gouthamr> cool ty cjwatson
[23:06] <cjwatson> gouthamr: OK, after investigation, closed with advice on project configuration fixes.  Let us know if you need further help.  CC sarnold
[23:08] <gouthamr> cjwatson: awesome - thank you for the detailed explanation! i wasn't aware of this config on our end :)
[23:26] <sarnold> cjwatson, gouthamr, wonderful, thanks both :)


[06:10] <ubotu> New bug: #144174 in malone ""Launchpad Janitor" for Bugs v. "Launchpad Answers Janitor"" [Undecided,New]  https://launchpad.net/bugs/144174
[10:15] <ubotu> New bug: #144190 in soyuz "New distrosourcepackage page has misleading dates in version history" [Undecided,New]  https://launchpad.net/bugs/144190
[11:11] <ubotu> New bug: #144194 in rosetta "Source package +translate page asks me to log in even if I already have" [Undecided,New]  https://launchpad.net/bugs/144194
[04:11] <italian> hello
[04:12] <italian> any1 alive here
[04:12] <italian> i need help at launchpad
[04:13] <italian> no 1 help here or wat ?
[04:14] <martalli_> Is launchpad open-source or available to companies if they would like to use an installation for their own purposes?
[04:14] <martalli_> italian: What do you need?
[04:14] <italian> i made account on launchpad
[04:15] <italian> i recieved email
[04:15] <italian> when i follow link ... nothing happen .. it doesn't activate
[04:15] <italian> it links me to page make new account
[04:15] <radix> martalli_: It's not open source, but for commercial use you should contact Elliot Murphy<EMAIL_ADDRESS>[04:16] <martalli_> radix: are there similar programs in the oss arena?
[04:17] <martalli_> italian: Maybe you are not getting the entire link (such as if the line is overrunning your screen)
[04:18] <radix> martalli_: depends what features you need
[04:19] <radix> apparently the old open source version of sourceforge was forked to a project called "Savane"...
[04:20] <martalli_> My Dadis looking fo a program that will help him follow issues on engineering (structural, mech, etc) projects and be able to link to dhort discussions, emails and such
[04:21] <radix> dhort?
[04:21] <martalli_> I was thinking egroupware, but then I showed him launchpad he thought that fit many of the requirements that he was thinking of
[04:22] <martalli_> radix: woops - short
[04:22] <radix> hm
[04:22] <radix> I don't really understand that bit
[04:22] <radix> what do you mean, "be able to link to short discussions"? link from where?
[04:24] <martalli_> I mean that they want something like a wiki, where they can record progress of projects, and be able to record pertinent things like emails or communications.  My Dad liked the idea of launchpad being able to assign tasks to individuals and track the status of the projects or individual issues as they arise
[04:25] <martalli_> This would be something that would just stay within his company
[04:25] <martalli_> Hosted on a local/LAN webserver
[04:25] <radix> oh, ok, a wiki
[04:25] <martalli_> Yes, much like a wiki, but more of a purpose-driven wiki
[04:26] <radix> a purpose-driven wiki is just a wiki that was put to a purpose, right? :) or are you thinking of something with more enforced structure?
[04:27] <radix> I'm just trying to figure out whether Launchpad actually offers this feature for you.
[04:27] <radix> Launchpad doesn't offer any sort of wiki hosting or web content hosting right now.
[04:28] <martalli_> radix - that's right
[04:28] <martalli_> radix: Is thaqt right?  It runs on the internet off a webserver, so I guess I just figured that it was a variation of a wiki or discussion group software
[04:30] <radix> ... nope...
[04:31] <radix> not everything that is run on the internet off a webserver is discussion or wiki software :-)
[04:31] <martalli_> Well, maybe I should just install egroupware and give it a closer look
[04:32] <martalli_> lol I know.  I am no expert, but I run a joomla website and realize that most websites simply are a frontend for a database of whatever different types.
[05:55] <ubotu> New bug: #144246 in launchpad "Pulldown menu headers should be multiline if necessary" [Undecided,New]  https://launchpad.net/bugs/144246
[06:00] <popey> 7~
[07:15] <ubotu> New bug: #144257 in soyuz "[PPA]  some packages not queued/built" [Undecided,New]  https://launchpad.net/bugs/144257
[08:10] <synic> anyone here?
[08:19] <pochu> synic: 92 people... what do you need?
[08:19] <pochu> a little less if you don't count bots ;)
[08:19] <synic> I've uploaded a messages.pot to be translated, but it's now out of date.
[08:19] <synic> any way I can update it?
[09:43] <ScottAS> Hello. Is it possible to talk to an Administrator?
[09:47] <lifeless> ScottAS: best way to get an admin is to file a question on the launchpad project
[09:48] <ScottAS> OK. Thank you.
[09:50] <ScottAS> lifeless: I would be able to ask a question however my question is about my Login details in the first place! :D
[09:53] <lifeless> ScottAS: have you tried password recovery?
[09:53] <lifeless> ScottAS: what are you wanting the admin to do?
[09:55] <ubotu> New bug: #144291 in launchpad "Bug nickname feature is hard to discover and use" [Undecided,New]  https://launchpad.net/bugs/144291
[09:59] <ScottAS> lifeless: The E-Mail Address associated with my Account no longer exists therefore I can't reset my Account Password.
[10:00] <lifeless> can you create a new account?
[10:01] <ScottAS> I'd rather not, in fact I'd rather have my Account removed.
[10:01] <lifeless> and then ask for it to be merged with the old account?
[10:01] <lifeless> uh interesting, I can see the challenge then
[10:02] <lifeless> unfortunately its sunday for most of the admins
[10:02] <lifeless> or *very* early monday
[10:02] <pochu> The question there is, how to prove you own the other account?
[10:02] <lifeless> indeed
[10:03] <ScottAS> The E-Mail Address used for my Account was via a personal Domain.
[10:38] <siretart> Uploading to ubuntu (via ftp to upload.ubuntu.com):
[10:38] <siretart> Connection failed, aborting. Check your network (111, 'Connection refused')
[10:38] <siretart> launchpad's down?
[10:39] <geser> browsing bugs works
[10:40] <lifeless> there is some admin going on right now
[10:41] <lifeless> backend stuff only, main service is not affected
[10:43] <siretart> ok
[11:43] <elmo> ** the Launchpad website is going down for 5 minutes for emergency maintenance
[11:45] <SteveA> thanks elmo
[11:45] <gnomefreak> elmo: thanks fort the warning
[11:45] <gnomefreak> s/fort/for
[11:48] <gnomefreak> that was fast
[11:48] <Nafallo> that was four minutes :-)
[11:49] <Nafallo> topic to topic :-)
[11:49] <gnomefreak> i went to 2 book stores looking for a book here in US there were more ubuntu books on shelves than fedora/suse/RHEL
[11:50] <SteveA> gnomefreak: no way!?  got a photo?
[11:50] <gnomefreak> SteveA: i will next run there
[11:50] <SteveA> cool
[11:50] <gnomefreak> i was like holy crap
[11:51] <gnomefreak> i was just informed its still down
[11:51] <gnomefreak> its == LP
[11:51] <gnomefreak> yep it is
[11:52] <gnomefreak> Ubulette: i guess hes still working on it
[11:52] <Martinp23> edge.lp was down for me just then
[11:52] <gnomefreak> maybe waiting to refresh
[11:53] <Martinp23> just timing out, it seems.  Main lp site still works
[11:53] <Martinp23> ff says "failed to estabilish connection to server"
[11:53] <gnomefreak> yeah
[11:54] <lifeless> hi SteveA
[11:54] <elmo> looking into it
[11:54] <gnomefreak> elmo: thank you :)
[11:55] <Martinp23> thanks elmo :)
[11:56] <elmo> should all be back now, sorry about that
[11:57] <gnomefreak> elmo: it is ty for the quick responce
[11:57] <lifeless> the price of security is eternal patching
[12:07] <DaveMorris> Hi, I've been using thye ppa system now for a couple of weeks expect for I'm now getting 'Connection failed, aborting. Check your network (111, 'Connection refused')' error, although it worked fine last night.  Anyone got any ideas?
[12:11] <lifeless> DaveMorris: there was some emergency maintenance a few minutes ago
[12:11] <lifeless> DaveMorris: is it still not working for you?
[12:18] <DaveMorris> no
[12:19] <DaveMorris> still no working
[12:22] <lifeless> elmo: ^
[12:23] <DaveMorris> I was about to ask who I need to speak to about it
[12:23] <lifeless> elmo: any chance its still what you were doing, or should I point DaveMorris at the usual 'I have a problem' channels ?
[12:31] <gnomefreak> theres i have a problem channels?
[12:32] <pkern> Is it possible to contact people like https://launchpad.net/~elias-asb-online who have no email address listed?
[12:32] <gnomefreak> pkern: find out thier irc nick and look for them
[12:34] <pkern> Hm, otoh it could be deduced from the account name.
[12:37] <pkern> And blueprints could only be removed via admin request?


[11:25] <QuanQeng> Having read the docs, I can't seem to tell if I need CONFIG_COMPACTION and CONFIG_MIGRATION and KSM Page Merging, what are the pros and is it recommended to enable these options?


[14:55] <sadmac2> Keybuk: how's the code?
[16:04] <Keybuk> sadmac2: finished the refactoring
[16:04] <Keybuk> just got to finish d-bus stuff
[16:04] <sadmac2> very nice
 Keybuk: I'm still unhappy with the idea of nfs-server having content in portmaps' job file.
[17:06] <wasabi>  I just cann't imagine how packagers will deal with it.
[17:06] <wasabi> Make my fears go away!
[17:07] <ion_> Are they just additions or larger changes?
[17:07] <Keybuk> well, it does anyway, since it needs to be in the portmap maps file
[17:08] <Keybuk> portmap is _really_ the only example of this kind of job I can think of
[17:09] <wasabi> It fails with more than one thing depending on portmap, doesn't it?
[17:09] <ion_> Have update-portmap-job within the portmap package, which combines files from .../portmap/job.d/* to /etc/init/jobs.d/portmap?
[17:09] <wasabi> You know. I guess it doesn't really matter. Mine as well just run portmap when portmap is installed, period.
[17:10] <wasabi> And just rely on the package manager to enable/disable it.
[17:10] <ion_> Or have upstart read /etc/init.d/jobs.d/portmap.d/* as a single job? :-)
[17:11] <Keybuk> wasabi: why would it fail?
[17:12] <Keybuk> there _is_ a much more entertaining way to do it
[17:12] <Keybuk> /etc/init/jobs.d/nfs-server:
[17:12] <Keybuk>     env REQUIRE_PORTMAP=1
[17:12] <Keybuk>     export REQUIRE_PORTMAP
[17:12] <Keybuk> /etc/init/jobs.d/portmap:
[17:12] <Keybuk>     start on starting REQUIRE_PORTMAP=1
[17:13] <Keybuk> you don't _have_ to match on the job name ;)
[17:13] <wasabi> oh that's crazy
[17:13] <wasabi> dude. that's slick.
[17:13] <wasabi> though how do you make it stop? :0
[17:13] <Keybuk> if there's really a large number of jobs that should behave like this, we can codify that
[17:13] <Keybuk> ie. have a "depends portmap" type syntax
[17:13] <Keybuk> which adds to the job event environment
[17:13] <wasabi> oh you could also have portmap's job file keep a ref count.
[17:13] <wasabi> or something
[17:13] <Keybuk> yeah
[17:14] <Keybuk> that'd work with states too
[17:14] <Keybuk>   state portmap-dependency
[17:14] <Keybuk>       from starting REQUIRE_PORTMAP=1
[17:14] <wasabi> start could increment the count, and run the daemon. pre-stop could decrement it and only allow stopping when it hits 0
[17:14] <Keybuk>       until stopped $JOB
[17:14] <Keybuk>   end state
[17:14] <Keybuk> then portmap would have
[17:14] <Keybuk>   while portmap-dependency
[17:15] <Keybuk> (theoretical)
[17:15] <wasabi> that is intriguing. i have yet to read about states.
[17:15] <Keybuk> I've yet to invent them properly
[17:15] <Keybuk> you and I did the ground work back in SF
[17:15] <wasabi> I remember that much
[17:15] <Keybuk> over very hot thai
[17:16] <wasabi> The next morning was not pleasant.
[17:16] <Keybuk> when I realised that upstart's design allows it to do dependency-based init with _no_ special contortions, I knew we'd reached elegance
[17:16] <Keybuk> events can be used to emulate them just fine
[17:17] <wasabi> design nirvana.
[17:31] <ion_> A bit like doing sequential code with side-effects using monads in a functional programming language. Good, clean architecture that doesn't restrict your choices when you need to have something the worse architecture does well. :-)
[19:09] <sadmac2> Keybuk: get a chance to look at that email I sent?
[19:14] <Keybuk> not yet
[19:14] <Keybuk> this week is performance review week
[19:14] <Keybuk> and UDS planning
[19:14] <sadmac2> Ahh
[19:15] <Keybuk> and I wanted to get 0.5.0 out before worrying too much about what comes after ;)
[19:15] <Keybuk> I'm stuck in a hotel in london next week, so bar going out skating, I'll have plenty of time to code that and reply to mails :)
[19:17] <sadmac2> sweet
[19:17] <sadmac2> what's still loose in the dbus code?
[19:19] <Keybuk> just the writing of the functions now
[19:19] <Keybuk> it registers the objects on the bus
[19:19] <Keybuk> and maintains a connection to the bus, dropping it and reopening when necessary
[19:19] <Keybuk> so just need to write the actual methods ;)
[19:30] <sadmac2> heh. cool
[19:33] <ion_> So Upstart will be the first program ever not to crap itself when dbus goes for a short walk? :-)
[19:37] <wasabi> You writing the dbus integrating in pid 1?
[19:38] <Keybuk> wasabi: yeah
[19:38] <wasabi> scary.
[19:38] <wasabi> linking to libdbus?
[19:39] <ion_> Scary?
[19:40] <Keybuk> wasabi: yup
[19:40] <wasabi> That sounds frightening for some reason.
[19:41] <ion_> Frightening?
[19:41] <wasabi> Uh huh. Just ot have that much complexity in pid 1.
[19:44] <ion_> Well, for it to talk with other processes, there must be *some* implementation of *some* protocol anyway in pid 1. :-)
[19:47] <Keybuk> wasabi: libdbus is nice enough
[19:48] <Keybuk> having our own ipc implementation was scarier, since it's not as audited
[19:52] <wasabi> It might scare people who don't want dbus on their systems (server installs)
[19:52] <ion_> Do you mean dbus-the-protocol or dbus-the-daemon?
[19:53] <wasabi> I have no practical claims. Only political claims.
[19:56] <Keybuk> wasabi: those people won't get a choice?
[19:59] <wasabi> Well, is libdbus.so required?
[20:03] <Keybuk> yes
[20:12] <AlexExtreme> libdbus.so? surely it would be safer to statically link /sbin/init to libdbus.a rather than use the shared library?
[20:18] <Keybuk> why safer?
[20:18] <Keybuk> shared libraries are safer since they can be updated for security updates
[20:35] <AlexExtreme> Keybuk: libdbus upgrade, .so version changes (e.g. from .so.3 to .so.4), upstart package isn't upgraded, reboot, *won't boot because of missing lib*
[20:36] <Keybuk> that's what we have package managers for
[20:36] <Keybuk> upstart would depend on libdbus3 and so libdbus.so.3 would be still installed
[20:36] <Keybuk> while libdbus4 containing libdbus.so.4 would be used by the other apps
[20:36] <ion_> Yeah, soname bumps never break anything.
[20:36] <AlexExtreme> but then again I'm speaking from my experience in a smaller distro where maintainers didn't get dependencies right and sometimes forgot to rebuild packages :)
[20:37] <Keybuk> happily dbus isn't due for a soname change
[20:37] <ion_> It's not their job to get the dependencies right, the packaging tools make the shlibdeps.
[20:37] <Keybuk> and if it were, it's maintainers have very very carefully made sure it would not be a problem
[20:37] <Keybuk> even the include files are parallel installable
[20:38] <AlexExtreme> ion_: debian's packaging tools may do that, pacman's packaging tools don't
[20:39] <ion_> alexextreme: Just copy the functionality from $other_distro. :-)
[20:39] <AlexExtreme> hah
[21:01] <sadmac2> that was interesting
[21:11] <ion_> alexextreme: Well, nothing prevents you from linking statically, it's just safer the other way. :-)
[21:14] <suihkulokki> the main worry of linking external libraries to process runnning pid 1, is that pid 1 should never ever crash
[21:14] <suihkulokki> so one needs to be sure the libraries linked to are rock solid
[21:14] <suihkulokki> and aren't built on assumptations like "it's ok to crash if malloc() fails"
[21:21] <Keybuk> suihkulokki: see also, Why Keybuk Does Not Like GLib :)
[21:22] <Keybuk> the only doofus assumption in libdbus was that it could call exit() if the connection to the bus was dropped
[21:22] <Keybuk> and that was at least an option
[21:22] <Keybuk> (but the code that set the option for bus connection was in the wrong place, which I had to fix)
[22:16] <wasabi> I think limiting scope of exposure is important. If every libdbus version upgrade is vetted by a team of trained professionals before being deployed, so as not to break upstart, then it's good.
[22:16] <wasabi> But I think in reality that does not happen, and it could break.
[22:16] <wasabi> Hence you'd limit scope in order to reduce the maintenance burden on the maintainer. upstart is super critical.
[22:26] <Keybuk> not so much
[22:26] <Keybuk> if every Upstart upgrade was vetted by the team of trained professionals
[22:26] <Keybuk> who carefully read through my IPC codfe
[22:27] <Keybuk> then I might feel happy ;)
[22:27] <Keybuk> since they don't, using a shared IPC protocol that has had more eyes over it is better
[22:28] <ion_> ...or just switch to a language that simply won't have any buffer overflows or stuff like that. :-)
[22:28] <Keybuk> then I'd have to put my faith into that language interpreter
[22:28] <Keybuk> and they really don't tend to be great ;)
[22:29] <ion_> :-)
[22:31] <Keybuk> D-Bus over homebrew IPC is compelling for several reasons
[22:32] <Keybuk> 1) security - D-Bus is used more widely and has had more people look at the code, including NSA verification, it's less likely to have extant security flaws than the homebrew
[22:32] <Keybuk> 2) response to flaws when they are found - D-Bus has active maintainership, when flaws are found the response will be rapid and a matter of replacing the library
[22:33] <Keybuk> 3) maintainability - homebrew IPC is a bitch to maintain, and touches lots of areas of UNIX that are unpleasant ;)
[22:33] <Keybuk>    much better to let someone else worry about those issues
[22:33] <Keybuk> 4) compatibility - there are already bindings for d-bus in most languages, and it's well known
[22:33] <Keybuk>    means more people will write software that talks to upstart
[22:33] <ion_> (I actually didn't mean an interpreted language, but the same of course applies to higher-level language compilers.)
[22:34] <Keybuk> 5) authentication - D-Bus already solved the authentication issues for individual connections *and* for messages
[22:34] <Keybuk> ion_: are there higher level compilers that remove the risk of buffer overflows?
[22:34] <ion_> As i said, the same (what you mentioned) applies to them. :-)
[22:34] <Keybuk> well, that and they don't exist? :p
[22:35] <Keybuk> I'm not writing Upstart in Pascal <g>
[22:35] <ion_> I've been trying to study Haskell recently with great interest, incidentally.
[22:36] <ion_> The more bits and pieces about it i get into my blob of grey matter, the more awesome it seems. :-)
[22:36] <ion_> Still, i have no idea whether the compiler (well, the glasgow compiler in this case, probably) contains bugs that could lead to security holes.
[22:36] <Keybuk> hmm, Haskell
[22:37] <Keybuk> that's basically writing in spreadsheets isn't it? :)
[22:37] <ion_> Well, something like that. :-P
[22:39] <Keybuk> I've yet to see someone implement something useful in Haskell that doesn't have very very scary end-of-the-universe problems
[22:40] <ion_> end-of-the-universe? :-)
[22:41] <Keybuk> as in, there's no point the program saying "Please wait"
[22:41] <Keybuk> it won't be done before you are
[22:42] <ion_> Sorry, i don't see what you mean.
[22:43] <Keybuk> that it's easy to write programs that have very difficult upper bounds
[22:44] <Keybuk> and can end up stuck resolving their next course of action
[22:44] <Keybuk> they do complete
[22:44] <Keybuk> but it can, in extreme cases, be calculated to require billions of years
[22:44] <ion_> Oh, ok
[23:09] <Amaranth> you could use ada :P


[07:48] <sakrecoer> hi guys! i'll be away from computer untiÃ¶ l sunday. but i'll check in everyday with my phone to parround for someone who can upload for us.
[07:49] <sakrecoer> aut
[07:49] <sakrecoer> autumna: sorry i messed the website deadline, i'll go through it (the mobile version anyways) during theb trip today.
[07:50] <sakrecoer> i rerendered the audio version andwity avdifferent angle but i haven't uploadee id , sunday you'll have it
[07:51] <sakrecoer> sorry, my irssi shell has a locale issue,Ã¤ and goes baas if i hit swedish letters
[07:52] <sakrecoer> banas even
[07:52] <sakrecoer> gah..
[07:53] <sakrecoer> any news from geirdal?
[07:57] <sakrecoer> whatever happened with zequence is very unfortunate. i was preperared to see him step away, but i'm sure we all would have liked to see it happen smoother. i don't have much to say except that i hope everyone will be nice to him would he check in on us  again
[07:59] <sakrecoer> ftr, he handed over every access to me and asked me not to reach out with questions unless they were dirrectly related to something he would have forgotten to give us.
[09:31] <eylul> sakrecoer: don't worry too much about the website deadline, after all the point of putting such a early deadline was to build in some delays. We are fine probably as long as we sort it out after you are back within a week or so. :)
[09:31] <eylul> sakrecoer: also no news from geirdal
[09:31] <eylul> :(
[14:24] <eylul> hi JLye9
[14:26] <JLye9> Hi


[19:30] <harlowja> arg, harmw so close, except need to modify the ufs image and rhel doesn't come with ufs module that seems to work, lol
[19:40] <SnoFox> No topic ...? I didn't realize that was possible.
[19:53] <harlowja> seems like even ubuntu creates a RO ufs module, arg
[20:29] <harmw> harlowja: what do you try to do?
[20:30] <harlowja> need to put some files in /tmp (jsonpatch...), but instance under libvirt doesn't have networking yet, and durn RH and ubuntu ship read-only ufs modules
[20:30] <harmw> why doesn't it have networking?
[20:31] <harlowja> ya, not sure, haven't investigated that much yet :-P
[20:31] <harmw> i can imagine rc.conf lacking some networking settings, though running dhclient should just give you an adress
[20:31] <harlowja> kk, let me try
[20:35] <harlowja> ah, it works
[20:35] <harlowja> sweet
[20:36] <harlowja> arg, of course no wget, lol
[20:43] <harmw> fetch :)
[20:43] <harmw> and perhaps even curl, not sure though
[20:47] <harlowja> hmmm
[20:47] <harlowja> this should let me download jsonpatch and stuff
[20:47] <harlowja> pita, lol
[20:47] <harmw> this beeing fetch?
[20:47] <harlowja> ah, i got wget installed :-P
[20:48] <harmw> in usr/local/sbin perhaps?
[20:48] <harlowja> let me check
[20:48] <harlowja> crazy bsd, lol
[20:48] <harlowja> ;)
[20:49] <harlowja> oh, i guess i can put all the needed files that aren't installed on a fat disk, and then avoid all this stuff, hmmm
[20:50] <harmw> or you just wget/fetch the jsonpatch and cloudinit tarballs and unzip those ;)
[20:50] <harlowja> ya ya :)
[20:51] <harlowja> gonna get this to work :-P
[20:58] <harmw> harlowja: http://paste.openstack.org/show/59693/ I'm seeing this on accasion, while creating/destroying instances
[20:58] <harlowja> ah, good ole neutron
[20:58] <harlowja> :-/
[20:58] <harmw> any ideas where/how to debug this? since it doesn't always happen
[20:59] <harlowja> hmmm
[20:59] <harlowja> i bet thats your keystone timing out
[20:59] <harmw> lol, i thought the same thing
[20:59] <harlowja> how are u setting up keystone?
[21:00] <harmw> mysql+memcached
[21:00] <harlowja> multi-process?
[21:00] <harlowja> 1 process?
[21:00] <harmw> no, just 1
[21:00] <harmw> keystone-all
[21:00] <harlowja> ya, i bet thats causing it
[21:00] <harmw> hm, is multi-process something new in havana?
[21:01] <harlowja> nah, its been an ongoing fight for that
[21:01] <harmw> because this only started since after the upgrade from grizzly
[21:02] <harlowja><EMAIL_ADDRESS>[21:02] <harmw> keystone token-get is slow aswell, sometimes it returns in <1s while it can also take an average of 10s
[21:02] <harlowja> hmmm
[21:02] <harmw> (I should mention its a rather old Atom cpu though)
[21:02] <harlowja> do u have a script running that cleans up the token database?
[21:02] <harmw> keystone is running 100%cpu most of the time
[21:02] <harmw> my token table is empty
[21:02] <harlowja> k
[21:03] <harmw> since memcached takes care of that
[21:03] <harlowja> right
[21:03] <harlowja> 100%cpu  not good
[21:03] <harlowja> http://docs.openstack.org/developer/keystone/apache-httpd.html
[21:03] <harlowja> u can try that
[21:04] <harlowja> so much stuff hits keystone that its a good idea to scale it > 1
[21:04] <harmw> true
[21:04] <harlowja> its the first thing to fall over really
[21:04] <harmw> though why didn't this happen with grizzly?
[21:05] <harlowja> unsure
[21:05] <harmw> mind you, I'm running a tiny tiny cloud with just 2 nodes
[21:05] <harlowja> :-/
[21:05] <harlowja> and its running at 100%
[21:05] <harmw> indeed
[21:05] <harlowja> that seems off :-/
[21:05] <harlowja> bb, food
[21:06] <harlowja> keystone logs useful?
[21:06] <harmw> :)
[21:06] <harmw> ahno
[21:06] <harmw> i had verbose+debug on, nothing interesting
[21:09] <harmw> i think this Atom just sucks bigtime at doing all the PKI stuff, causing it to max at 100
[21:38] <harmw> bedtime now harlowja, let me know how your fbsd stuff ends
[22:31] <harlowja> ends, probably never ends, haha :-P


[01:39] <h00k> hi, crog
[01:59] <crog> hi h00k - sorry delayed reaction....
[01:59] <crog> (or 20 min lag...)
[02:04] <h00k> crog: it happens, no prob
[02:05] <crog> h00k: helping the old man fix his xp machine
[02:07] <h00k> crog: Cool, I'm just doing some webde
[02:07] <h00k> v
[03:08] <h00k> aaaaaaand done.
[03:08] <h00k> now to a personal project
[03:13] <crog> Yay!
[03:14] <crog> I'm finally done too - so if I may monopolize the channel for a sec
[03:14] <h00k> It hhappens
[03:14] <crog> Hi all.  I'm Craig... crog
[03:14] <crog> just joined the loco like 2-3 days ago
[03:14] <h00k> crog: Cool, how'd you hear about us?
[03:14] <h00k> Also, are you on the mailing list?
[03:15] <crog> since this isn't a meeting, I assume folks are working on stuff
[03:15] <crog> cause you're not all bots.
[03:15] <crog> Heard about via the ubuntu community pages
[03:15] <crog> Yes, on the mailing list
[03:15] <h00k> we have lubotu1, ubuntulo12, and ubuntulo12 as bots, the rest are real-live-people
[03:15] <h00k> !bot
[03:16] <crog> Been a linux user about 12 yrs... debian, redhat, and then ubuntu since 4.10
[03:16] <h00k> sweet action.
[03:17] <crog> usually just lurk - but sortof board with that
[03:18] <crog> bored
[03:18] <crog> looking to help fix bugs, and eventually find a prj to hack away on
[03:19] <h00k> crog: Cool.  For the Global Jam, we're actually doing a bug fix session
[03:19] <crog> h00k: is that 9/3 or 9/4?
[03:19] <h00k> The 4th
[03:19] <h00k> http://loco.ubuntu.com/events/ubuntu-us-wisconsin/1178/detail/
[03:19] <h00k> http://loco.ubuntu.com/teams/ubuntu-us-wisconsin/events
[03:20] <crog> will join if I can
[03:22] <h00k> Awesome
[03:22] <h00k> Not sure what you use for an IRC client, but we usually hang out here all the time, I'm usually here on evenings
[03:22] <h00k> and then during the day, depending on how work is ;)
[03:22] <crog> using irssi right now
[03:23] <crog> I'm working about 55hrs/week, and then kids until bedtime...
[03:25] <crog> re: client - any suggestions?  generally don't use irc enough to bother with scripting, etc.
[03:25] <crog> but once i settle in will start looking for keyboard shortcuts, etc.
[03:31] <h00k> I use irssi, anyway
[03:31] <h00k> I like it
[03:34] <h00k> crog: so, where about in the state are you from?
[03:34] <crog> madison
[03:34] <crog> grew up in green bay, college in waukesha
[03:36] <crog> h00k: you?
[03:36] <h00k> crog: Rhinelander
[03:36] <h00k> Up north.
[03:39] <h00k> crog: they do Ubuntu Hours down there, too
[03:40] <crog> http://www.hodagpress.com/images/Hodag_1.jpg
[03:40] <crog> That Rhinelander?
[03:40] <h00k> That one
[03:40] <crog> Been there for a wedding, and mosquitos
[03:41] <h00k> :D Mosquitos, that's for sure.
[04:17] <crog> well, evening all
[13:13] <h00k> oi
[13:18] <mikeputnam> hallo
[13:19] <h00k> bossman said I look srs today.
[13:19] <mikeputnam> srsly?
[13:19] <h00k> Yep.
[13:19] <h00k> "What's going on, you actually look serious today?"
[13:19] <h00k> said the general manager
[13:20]  * mikeputnam stops messing aroung
[13:20] <mikeputnam> *around
[13:20] <mikeputnam> h00k don't play
[13:20] <h00k> I said "Yeah, It doesn't happen often."
[13:20] <h00k> Actually, it's probably because I was up until 3 last night ;)
[13:20] <mikeputnam> srs = hungover!
[13:21] <h00k> HAH! Nah, I was out of beer :(
[13:21] <h00k> drank water
[13:45] <mikeputnam> h00k: your (important) apache's hotfixed?
[13:45] <mikeputnam> http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/browser
[14:01] <h00k> mikeputnam: is this the incomplete-packet-website-freezer thing?
[14:01] <h00k> where it opens a bunch of half-requests, hangs apache?
[14:01] <h00k> and no...on the servers I control, I should do this
[14:07] <h00k> here I am!
[14:08] <mikeputnam> Marco!
[14:10] <h00k> POLO
[16:52] <h00k> Booted Windows today, had a terrible experience.
[16:53] <h00k> Right after login, "You need to restart for the changes to take effect/"
[16:53] <h00k> What did I change?! No new hardware.
[16:53] <h00k> Nothing.
[16:53] <h00k> THEN! Windows Live Essentials needed an update (Windows Live Messenger) and required an update.
[16:57] <h00k> 2 penalties. Horrible.
[16:57] <h00k> It didn't even upgrade the kernel :(
[18:04] <h00k> I keep trying to ctrl+alt+arrow to an alternative desktop. Not working in Windows. Ends up adjusting the rotation of my monitor, and it throws me off every time.