[09:53] <noodles775> marcoceppi: Hi! So with 1.17.0 I get a bit further with amulet - now jujuclient is erroring with 'state watcher was stopped' - http://paste.ubuntu.com/6766988/ If that's familiar, let me know. I'll start digging.
[13:37] <marcoceppi> noodles775: it's a know dwployer/juju bug
[13:39] <noodles775> marcoceppi: OK, so how are you working around it when you test amulet using juju 1.17.0??
[13:40]  * noodles775 checks for the bug (sorry, the two ?? there is just because of net-lag :P)
[13:40] <marcoceppi> just run the rest a second time without destroying env
[13:42] <marcoceppi> noodles775: let me see if i can find it
[13:44] <noodles775> marcoceppi: oh - as in, you write your first amulet test to simply create the environment, then other files in tests/* are run with the existing already-setup env? (I'd assumed each file would be run with a freshly-bootstrapped env)
[13:45] <marcoceppi> noodles775: you /can/ do that, but juju-test is designed to destroy environment before each test file
[13:45] <marcoceppi> noodles775: what you can do is just run the tests again without destroying environment, IE: tests/01-amulet-test-name
[13:45] <marcoceppi> it'll fail with https://bugs.launchpad.net/juju-deployer/+bug/1269519
[13:45] <_mup_> Bug #1269519: Error on allwatcher api <juju-core:In Progress by rogpeppe> <juju-deployer:Confirmed> <https://launchpad.net/bugs/1269519>
[13:46] <marcoceppi> then just run the test again and deployer will pick up where it left off
[13:46] <noodles775> marcoceppi: oh? Let me try that (I'd assumed it creates a separate deployment).
[13:47] <marcoceppi> noodles775: no, juju test files expect to have a clean environment, they don't actually destroy anything
[13:47] <marcoceppi> noodles775: since amulet uses deployer, deployer just picks up where it left off
[13:48] <noodles775> Yeah, I was assuming that the test files expect a clean env (and wasn't doing any destroying), but didn't realise I could re-run the test and have it pick up where it left off. Great. Thanks!
[13:52] <marcoceppi> noodles775: np! Just know that's not normal behavior of the juju test plugin, the test plugin (which executes each test file) does the destroying, bootstrapping, and log archival. The tests can be written in anything (amulet, for example)
[13:56] <rogpeppe> marcoceppi: can you reproduce that bug?
[13:56] <rogpeppe> marcoceppi: i really don't have much to go on until i see a way to reproduce it - nothing jumps out in the code
[13:56] <marcoceppi> rogpeppe: not personally, but lazypower and mbruzek both can
[13:56] <marcoceppi> and noodles775 just encountered the issue as well
[13:57] <mbruzek> Hello rogpeppe which bug are we talking about
[13:57] <rogpeppe> lazypower, mbruzek: it would be great if you could add the way you can reproduce the bug to the #1269519
[13:57] <_mup_> Bug #1269519: Error on allwatcher api <juju-core:In Progress by rogpeppe> <juju-deployer:Confirmed> <https://launchpad.net/bugs/1269519>
[13:58] <mbruzek> rogpeppe, I just did it today, it happens when I run an amulet test on my local juju environment
[13:59] <mbruzek> 1.17.0-trusty-amd64
[13:59] <mbruzek> I can send you the amulet test if you like?
[13:59] <rogpeppe> mbruzek: if you could post a from-scratch way that you can reproduce it to that bug, that would be marvellous, thanks!
[14:00] <rogpeppe> mbruzek: better to attach it to the bug report, i think
[14:00] <mbruzek> Yes absolutely.  My only concern is there is nothing special I am doing, no complicated setup.
[14:01]  * noodles775 can do that too, I've got a public branch.
[14:01] <mbruzek> And I have not committed my amulet test
[14:01] <mbruzek> no wait it is committed just not pushed,  will update bug
[14:26] <noodles775> rogpeppe: my repro instructions too - I'll add them to the bug. http://paste.ubuntu.com/6768177/
[14:55] <Ming_> What is best way to layout my charm source if I want to support multiple Ubuntu release?  I see most charm has precise/<charm name>. But seems I need change it saucy/<charm name> if want to deploy the charm on Ubuntu 13.10
[14:56] <Ming_> at lest with local provider
[15:01] <marcoceppi> Ming_: that's correct, typically people will create ~/charms/{precise, saucy}, then put their charm in precise, and symlink it to saucy
[15:03] <Ming_> k. thx
[15:17] <Ming_> Does charm must use suggested template for the shape?  Our company has rule on logo/icon. I have hard time to select background color.
[15:18] <Ming_> I mean charm icon
[15:21] <marcoceppi> Ming_: yes, if you want the charm in the charm store it should follow our charm icon guidelines. Depending on the icon we may be able to make exceptions
[15:21] <marcoceppi> Ming_: you should email<EMAIL_ADDRESS>about that
[15:23] <Ming_> Thanks Marco.  We talked before in the workshop you and Jorge provided.
[15:23] <marcoceppi> o/ awesome welcome back
[16:03] <noodles775> marcoceppi: after calling d.configure() to change some charm configs after an initial deployment, what needs to be called to do the juju set's? (I expected d.configure() to do that, but it just sets some state in a local dict).
[16:13] <lazypower> d.setup() i believe
[16:14]  * noodles775 tried that, but the expected config change didn't happen... it works fine with juju set though. I'll keep digging, thanks lazypower
[16:18] <marcoceppi> noodles775: this is a bug atm
[16:20] <mbruzek> So configure does not set the values?
[16:25] <Ming_> Can I call "relation-get" and "relation-set" in config-changed hook?
[16:27] <marcoceppi> mbruzek: it does, just not after deployment
[16:27] <marcoceppi> Ming_: not easily
[16:28] <marcoceppi> noodles775: https://bugs.launchpad.net/amulet/+bug/1270174
[16:28] <_mup_> Bug #1270174: Post deployment commands <Amulet:Triaged by marcoceppi> <https://launchpad.net/bugs/1270174>
[16:28] <lazypower> Ming_, Its best practice to create relational hooks to work with any data coming over the wire for the relationship.
[16:30] <Ming_> but I cannot configure our cluster when all nodes are ready. I want to manually trigger the action through configure-changed
[16:31] <mbruzek> Hello Juju.  I am encountering a problem with my local LXC environment.  When I run juju status I see
[16:31] <mbruzek> agent-state-info: '(error: container "mbruzek-local-machine-1" is already cr
[16:31] <mbruzek> eated)'
[16:31] <marcoceppi> mbruzek: you had a dirty stage
[16:31] <mbruzek> I recognized this as a clean up error that jorge reportd in bug 1227145
[16:31] <_mup_> Bug #1227145: Juju isn't cleaning up destroyed LXC containers <cts-cloud-review> <local> <papercut> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1227145>
[16:32] <mbruzek> Marco I cleaned up since my last bootstrap and I watched the script remove those files
[16:32] <marcoceppi> Ming_: there is a way to do this, the relation hooks set special environment variables, so you'll need to record these for each unit then when you want to run the commands you'll need to loop through the available units on the relation and set the -r flag for relation-get/set
[16:33] <marcoceppi> Ming_: I don't know off the top of my head and I'm not at my main computer to get you exact details, you may want to mail<EMAIL_ADDRESS>or ask on http://askubuntu.com/ with the tag juju and Ican get back to you (or someone else) with more details
[16:33] <mbruzek> marcoceppi, you are right I remembered to run the script
[16:33] <Ming_> Sure. thx
[16:34] <mbruzek> But I see they were directories rather than files
[16:34] <marcoceppi> mbruzek: yes, they're the contents of the LXC container
[16:35] <mbruzek> my scritpt tried to rm those rather than rmdir or rm -rf
[16:35] <mbruzek> Thanks
[16:35] <mbruzek> fixing that
[16:51] <rogpeppe> noodles775: i didn't get too far with your instructions - i get this error when trying to run 00-single-node-install: http://paste.ubuntu.com/6768907/
[16:51] <rogpeppe> noodles775: is "requests" a python module that i should apt-get from somewhere?
[16:51] <rogpeppe> mbruzek: ^
[16:52] <lazypower> rogpeppe, sudo apt-get install python-requests
[16:52] <rogpeppe> lazypower: ta!
[16:53] <mbruzek> rogpeppe, I don't have import requests in my code
[16:53] <mbruzek> Do I ?
[16:53] <rogpeppe> mbruzek: the third line in 00-single-node-install ?
[16:53] <mbruzek> 00-single-node-install is not my code
[16:54] <mbruzek> Not the one I posted.  basic_deploy_test.py
[16:54] <mbruzek> That is the one in the tests directory
[16:54] <marcoceppi> mbruzek: I think it's a bad dep on the amulet package
[16:54] <mbruzek> OK
[16:55] <marcoceppi> since amulet uses requests
[16:55] <mbruzek> yeah I got it
[16:56] <rogpeppe> ha, it barfs on my environments.yaml
[16:56] <Ming> Is there a way to broadcast an event to every node? change configuration variable persist the change so is not desired in this case
[16:57] <Ming> HI Marco, I sent the email to<EMAIL_ADDRESS>[16:57]  * rogpeppe hates yaml, once more
[16:58] <mgz> rogpeppe: when in doubt, just write json :)
[16:59] <rogpeppe> mgz: i do, and i did
[16:59] <rogpeppe> mgz: but the python yaml parser barfed on it
[16:59] <rogpeppe> mgz: it didn't like my tab characters
[16:59] <rogpeppe> mgz: perfectly valid json :-)
[17:00] <rogpeppe> mbruzek: i was trying to follow Michael Nelson's (noodles775?) instructions, since they seemed a little more specific, but it's not working for me; i'll try yours
[17:02] <rogpeppe> mbruzek: should i get juju-deployer via apt-get or branching a repo?
[17:03] <mbruzek> I am in a meeting, I didn't do anything to juju-deployer
[17:04] <mbruzek> I used apt-get to get juju-deployer
[17:04]  * mbruzek is in a meeting
[17:07] <rogpeppe> mbruzek: thanks
[17:08] <rogpeppe> mbruzek, noodles775: i got a traceback from the code, but the issue itself doesn't seem to have reproduced (i don't see the "state watcher was stopped" error mentioned in the bug description and logs)
[17:15] <rogpeppe> ah, sorted that out
[17:19] <rogpeppe> mbruzek, noodles775: reproduced! thanks v much for the test case
[17:19] <mbruzek> great
[18:42] <rogpeppe> mbruzek, noodles775: found the bug, i'm pretty sure
[18:42] <mbruzek> Great
[18:42] <rogpeppe> marcoceppi: ^
[18:42] <marcoceppi> rogpeppe: excellent!!!!!
[18:43] <rogpeppe> marcoceppi: the issue is that if a client connection goes three minutes without sending a Ping, it gets terminated
[18:43] <rogpeppe> i'm not sure that's actually what we should do for a client connection, but i'm pretty sure that's the culprit
[18:47] <marcoceppi> rogpeppe: is it something we can patch in on jujuclient python lob? to juat send a ping
[18:47] <rogpeppe> marcoceppi: probably
[18:48] <rogpeppe> marcoceppi: except that the python library doesn't allow concurrent requests, which is a bit of a problem
[18:48] <rogpeppe> marcoceppi: so no, i think it might not be possible to fix without fixing that client lib
[18:50] <rogpeppe> marcoceppi: we could probably just turn off the ping requirement for non-agents.
[18:50] <rogpeppe> marcoceppi: it's really there so that we know when agents are still alive
[18:50] <marcoceppi> rogpeppe: thatd be great
[18:51] <rogpeppe> marcoceppi: i objected to this feature when it was implemented originally FWIW
[18:51]  * rogpeppe likes naivity
[19:07] <mbruzek> Hello Juju.  I am trying to use juju 1.17.0-trusty-amd64 with trusty and a local lxc environment.
[19:07] <mbruzek> I am aware of the clean up commands that Jorge put on askubuntu
[19:08] <mbruzek> When I bootstrap a clean local environment it comes up ok, but when I try the first deploy I see the following in my juju status
[19:08] <mbruzek> agent-state-info: '(error: symlink /var/lib/lxc/mbruzek-local-machine-1/co
[19:08] <mbruzek> nfig
[19:08] <mbruzek>       /etc/lxc/auto/mbruzek-local-machine-1.conf: no such file or directory)'
[19:08] <mbruzek> I can paste bin the whole thing, if that helps
[19:10] <mbruzek> I am certain the /var/lib/lxc/mbruzek-local-machine-1 directory was cleaned up from the script
[19:10] <mbruzek> http://paste.ubuntu.com/6769679/  <- Whole juju status
[19:10] <mbruzek> Does anyone on the juju team have an idea?
[19:10] <mbruzek> of what is wrong
[19:12] <mbruzek> It looks similar to Jorge's bug 1227145
[19:12] <_mup_> Bug #1227145: Juju isn't cleaning up destroyed LXC containers <cts-cloud-review> <local> <papercut> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1227145>
[19:12] <mbruzek> But I used the commands he has to clean up after a destroy-environment and can not get anything to deploy on my local env
[19:14] <mbruzek> That bug is linked to 1238541
[19:16] <rick_h_> mbruzek: yea, I have the same issue. I assumed it was trusty/lxc bits getting sync. Looking at that bug looks ilke it's set for 1.17.1
[19:16] <mbruzek> is there any way I can get that version?
[19:16] <rick_h_> sinzui: what's the next release timeframe that might include that?
[19:16] <mbruzek> Can I add the dev repository ?
[19:17] <sinzui> rick_h_, maybe next week.
[19:18] <mbruzek> What package is it in so I can watch for it?  juju-core?
[19:18] <sinzui> mbruzek, you can add the dev repo. 1.17.x does not work with 1.16.x and it is unstable; it is not suitable for production use yet
[19:18] <sinzui> mbruzek, that's right, juju-core
[19:19] <mbruzek> I am trying to make progress on amulet tests for the eco team
[19:19] <rick_h_> mbruzek: bring up a non-trusty venv?
[19:19] <mbruzek> Right will do that.
[19:24] <mbruzek> Thanks for clarification rick_h_ and sinzui
[19:24] <mbruzek> I will look for this next week
[19:24] <mbruzek> and work on a different env in the mean time
[19:25] <sinzui> mbruzek, I can provide precise, saucy, and trusty debs that we build for testing
[19:26] <sinzui> mbruzek, http://<IP_ADDRESS>:8080/job/prepare-new-version/ always shows what we built for testing
[19:26] <mbruzek> That is great now I know where to look.
[19:32] <jcastro> marcoceppi, this one is all you: http://askubuntu.com/questions/407010/413-request-entity-too-large-nginx-1-1-19
[19:44] <rogpeppe> mbruzek, marcoceppi: i've proposed a fix: https://codereview.appspot.com/53810045
[21:01] <adam_g> the mysql charm is not deployable on newer ubuntu versions. when can we expected trusty charms to start showing up?
[21:55] <jcastro> adam_g, probably in the next few weeks
[23:21] <arosales> does anyone know what the tools-url for aws is off hand?
[23:22]  * arosales is working around https://bugs.launchpad.net/juju-core/+bug/1254401
[23:22] <_mup_> Bug #1254401: error reading from streams.canonical.com <bootstrap> <juju-core:Fix Committed by wallyworld> <https://launchpad.net/bugs/1254401>
[23:22] <arosales> I thought it was tools-url: http://juju-dist.s3.amazonaws.com/tools
[23:47] <wallyworld_> arosales: try http://juju-dist.s3.amazonaws.com/
[23:47] <wallyworld_> without the /tools at the end
[23:48] <arosales> wallyworld_, thanks I did get aws bootstrapped with     tools-url: https://juju-dist.s3.amazonaws.com/tools
[23:48] <arosales> I needed to remove .juju/environments/aws.jenv first though
[23:48] <wallyworld_> ok


[03:32] <jbl> Hi. I'm trying to install the ee5 SDK on edgy. I'm getting the "insufficient disk partition space" at the end of the installer. Any suggestions?


[18:18] <tertitten> Can someone help me with what I'm sure is a simple problem? I'm trying to build something on my ppa, it's just some copy "this to there" simple stuff really, but I keep getting this error: dh_usrlocal: error: debian/xfce4-docklike-plugin/usr/local/share/locale/bg/LC_MESSAGES/bg/xfce4-docklike-plugin.mo is not a directory
[18:19] <tertitten> my compat is 13 in my control file
[18:20] <tertitten> is it because im copying into a usr directory?
[18:24] <cjwatson> The standard packaging toolchain deliberately takes steps to prevent you installing stuff in /usr/local, since .debs aren't supposed to install there.
[18:25] <cjwatson> If you know what you're doing enough to do it anyway, then there are ways to override individual debhelper commands ... but it would probably be better to change the package to install in a standard location for .debs.
[18:27] <cjwatson> But your package claims to be GPL and yet appears to have no source code.  If you're the licensor as it says, then of course you can't be violating your own copyright; but it's probably against Launchpad's terms of service.
[18:27] <cjwatson> And it's not clear that Launchpad can legally redistribute it.
[18:28] <cjwatson> (Also, too late now, but you probably meant to ask in #launchpad.  This channel is meant to be for development of Launchpad itself)
[18:29] <tertitten> allright, I see, humm, so installing to something like /usr/lib or somewhere would probably be better then
[18:29] <tertitten> oh, thanks :)
[18:29] <cjwatson> The only reason I noticed the lack of source code is that normally dh_auto_configure would do "./configure --prefix=/usr" or similar for you.
[18:30] <cjwatson> So I wondered why that wasn't happening.
[18:30] <tertitten> aha :)
[18:30] <tertitten> thanks for your help anyway :)
[18:31] <cjwatson> (This is in https://launchpad.net/~tertitten/+archive/ubuntu/focuspoint-linux/+packages if anyone wants to check whether they're addressing the probable non-redistributability.)


[14:26] <t1mp> $ LD_LIBRARY_PATH=src/plugin/file-qml-plugin/:$LD_LIBRARY_PATH qmlscene -P src/plugin/file-qml-plugin/ -I src/plugin/file-qml-plugin/ src/app/qml/ubuntu-docviewer-app.qml
[14:26] <t1mp> file:///home/ubuntu/dev/ubuntu-docviewer-app/src/app/qml/ubuntu-docviewer-app.qml:20 module "DocumentViewer" is not installed
[14:26] <t1mp> what else do I need to configure to find the DocumentViewer module?
[14:32] <t1mp> ah, the directory names for docviewer are wrong.
[20:17] <t1mp> who is working on ubuntu-document-viewer?
[20:17] <t1mp> popey: I have a workaround for https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1577277
[20:18] <popey> t1mp: effectively, nobody
[20:18] <popey> or, you, now :)
[20:20] <t1mp> popey: this fix should avoid the crash https://code.launchpad.net/~tpeeters/ubuntu-docviewer-app/bug1577277-workaround/+merge/304561
[20:20] <t1mp> I don't know the policy for that app to get the fix in.


[14:53] <maxolasersquad> https://www.zdnet.com/article/eu-to-fund-bug-bounty-programs-for-14-open-source-projects-starting-january-2019/
 https://www.tomshardware.co.uk/banana-pi-24-core-server-arm,news-59648.html
 Oh...
 lol
 NVMe and TensorFlow...  Thanks @KMyers
[22:00] <maxolasersquad> 🎉🥳
[22:01] <maxolasersquad-k> 🎉🥳
 Happy birthday Aaron!
 what they said
 :-P
 Thanks @RazPi and @Ivoriesablaze
 And Max
 Lol. Web server issues
 Battery started swelling and required $3 replacement
 @KMyers picked up a book on your suggestion
 May revisit my drawing again since I want to get back to those robot plans


[02:09] <akgraner> posted the announcement about the new app developer site to the Fridge - http://fridge.ubuntu.com/2011/09/27/announcing-the-ubuntu-app-developer-site/
[05:12] <nlsthzn> o/
[08:16] <akgraner> pleia2, monthly news reports are we still sending out reminders to the teams to have them ready by the first sunday of each month?
[08:16] <akgraner> or do we need to get back into the habit of doing that
[08:18] <akgraner> I can send out the reminders from now on if you want...wasn't sure if nhandler was still handling that or not - and if not who was...
[14:30] <nhandler> akgraner: I stopped when we got into that long period of not publishing UWN monthly, and they never really started up
[14:31] <nhandler> I also think it might be easier to setup some cron jobs to send out all of our reminder emails
[14:36] <akgraner> nhandler, no worries - I as just wanting to make sure we pick it back up again
[14:36] <akgraner> I know it's helpful to the LoCo Council and to the other teams
[14:36] <akgraner> I can send out reminds until we can get it automated
[14:36] <akgraner> How's College life treating you?
[14:40] <nhandler> akgraner: That would be great. College life is great, just occupying most of my time. I've discovered the beauty of naps, which have taken the place of most of my computer time
[14:42] <akgraner> :-)
[14:42] <akgraner> good for you!
[14:43] <akgraner> enjoy life while you can you'll be old before you know it
[14:43] <nhandler> I'm just glad that my time away from IRC is not overlapping with your time ;)
[14:43] <akgraner> :-)
[14:44] <akgraner> you are missed around here - but I know you'll be doing great and wonderful thing at school then in the real world in no time....that will be equal or greater than the awesomeness you provide for the Ubuntu Community


[05:37] <hyperair> bleh i just tried creating a nonpae build, but the package build is failing with ls: cannot access ../linux-image-3.11.0-15-generic-nonpae_3.11.0-15.23_i386.deb: No such file or directory
[05:37] <hyperair> =\
[05:38] <hyperair> weird
[05:38] <hyperair> how does one introduce a new kernel flavour?
[06:22] <hyperair> aha, debian.master/rules.d/i386.mk
[06:22] <hyperair> dat elusive flavours variable
[07:19] <hyperair> oh gawd ccache, why won't you play properly with sbuild
[16:32] <jsalisbury> ##
[16:32] <jsalisbury> ## Kernel team meeting in 30 minutes
[16:32] <jsalisbury> ##
[16:34] <kdub> sforshee, i'm trying to tighten up/fix bugs around turning the phone's display on/off (from mir's perspective), and i'm trying to get some insight into powerd... would you be the one to bounce questions off of?
[16:36] <sforshee> kdub: I can try, but if the questions are specifically about the integration with unity8 then ricmm is the one who worked on that
[16:38] <kdub> sforshee, okay
[16:40] <kdub> sforshee, so you wouldn't know if its a hard guarantee that the system is active (out of suspend) before powerd goes and requests the display on?
[16:40] <sforshee> kdub: the system can't really request the display on if suspended ...
[16:41] <sforshee> kdub: if you're talking about autosuspend, then the answer is that autosuspend is disabled before powerd would request the display on
[16:42] <sforshee> however, there's one possible issue that I can warn you about
[16:42] <kdub> i don't really know the terminology very well in this area... to me there's 'system on' or 'system off'
[16:42] <kdub> and 'system off + mir attempting to display a frame == bad'
[16:42] <kdub> :)
[16:42] <sforshee> so here's the case which might be problematic
[16:43] <sforshee> android uses this file in sysfs, I don't recall the exact path off the top of my head, but basically it says whether or not the display device is ready
[16:43] <sforshee> there's a short period on some devices after disabling autosuspend where the device might not be ready yet, so you have to wait until that file says it's ready before you try to draw
[16:44] <kdub> oh, wake_lock?
[16:44] <sforshee> no
[16:44] <sforshee> let me look
[16:45] <kdub> okay, thanks
[16:45] <sforshee> kdub: /sys/power/wait_for_fb_sleep
[16:45] <sforshee> I know that when powerd talked to surface flinger it waited on that file, but I don't know if that's the case with the unity8 integration
[16:46] <sforshee> oh, actually /sys/power/wait_for_fb_wake
[16:46] <kdub> sforshee, excellent, sounds like what I need
[16:47] <kdub> let me tinker with that file to see if i can avert the problet
[16:47] <sforshee> kdub: actually it looks to me like powerd still waits on that before requesting the display be turned on
[16:50] <kdub> i see that in the startup, but not on every display on/off request
[16:51] <kgunn> sforshee: thanks for helping kdub...this thing has been a bear
[16:51] <kdub> yes, thanks sforshee
[16:52] <sforshee> kdub: I know the code worked when talking to sf, and the only part that's changed is that it now calls into unity instead
[16:52] <kdub> yeah, let me dig into what exactly goes on there
[16:52] <kdub> in the SF path
[16:52] <sforshee> good luck
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ## Meeting starting now
[17:00] <jsalisbury> ##
[17:14]  * jsalisbury makes his first s/2013/2014/ mistake
[17:15] <sforshee> jsalisbury: woah, no more meetings until Dec 2014? ;-)
[17:15] <jsalisbury> sforshee, an another whoops :-)
[17:16] <jsalisbury> sforshee, changing the month and year at the same time caused an overload
[17:17] <sforshee> I just guessed it was consecutive copy/paste errors
[17:17] <jsalisbury> heh, yup
[17:21] <antarus> was teh meeting exceeding short, or am I missing something?
[17:22] <sforshee> antarus: our meetings are always exceedingly short
[18:09] <antarus> kees: or apw how do I go about getting https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts-saucy/+bug/1244627 fixed?
[18:09] <ubot2`> Launchpad bug 1244627 in linux-meta-lts-saucy (Ubuntu) "Please enable CONFIG_IMA in the ubuntu kernel" [Undecided,Confirmed]
[18:09] <antarus> I might have filed it against the wrong thing (I am really aiming for Trusty I guess.)
[18:09] <antarus> I wonder if there is a more generic pkg name
[18:11] <apw> antarus, i seem to remember that was the one which in the past has caused terrible performance issues, and so it is enforced off, and i am guessing i said we would need some benchmarks to convince us it didn't
[18:11] <apw> still cause the same degredation
[18:11] <antarus> apw: I think we looked and it doesn't do anything without a policy loaded
[18:11] <antarus> and it doesn't load a policy by default
[18:12] <apw> antarus, iirc it made osmething bigger and the effect was devistating to performance (back when we tested it before)
[18:12] <antarus> (the user has to load one)
[18:12] <apw> even thought it really shouldn't be ... that is my worry
[18:15] <antarus> so I'm going to clone trusty and enable it then
[18:15] <antarus> and boot into it..and probably break my graphics ;p
[18:23] <kees> antarus: if you can show benchmarks without CONFIG_IMA, with CONFIG_IMA, and with CONFIG_IMG + policy, in a bug comment, that should be sufficient.
[18:30] <antarus> kees: that is what I am doing
[18:30] <antarus> I'm still curious what benchmarks you want
[18:30] <antarus> do you have any recommendations?
[18:30] <antarus> (io? memory? something else?)
[18:34] <kees> antarus: it was memory consumption in the past.
[18:34] <mjg59> kees: Also intrested in those results
[18:36] <antarus> kees: ok
[18:36] <kdub_> sforshee, just to pick your brain some more... do you know  why powerd sometimes sends consecutive 'display on' signals?
[18:36] <kdub_> i don't know if it means something by that, or if the second 'on' signal can safely be ignored
[18:37] <kees> mjg59: subscribe to 1244627! :)
[18:38] <antarus> wow, I do not understand your kernel build system..
[18:38] <antarus> heh
[18:38] <antarus> config.common.amd64 and config.common.ubuntu
[18:39] <antarus> are they merged together when the kernel is built?
[18:39] <kees> antarus: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[18:39] <antarus> yeah I'm following that
[18:40] <kees> cool
[18:40] <kees> there are scripts that do the merge, yes.
[18:40] <antarus> ok
[18:40] <antarus> I was confused because half of my change landed in common, and the other half in teh per-arch configs
[18:44] <antarus> thanks for your patience with me
[18:46] <kees> no problem! the more people can build the kernel the better :)
[18:50] <pkern> If we'd get one howto out of it that it's actually current. <insert xkcd about standards here>
[18:59] <sforshee> kdub_: are the flags changing? That would be my guess.
[19:02] <antarus> pkern: the kernel howto is fine
[19:02] <antarus> pkern: also, stop working ;p
[19:02] <kdub_> sforshee, i'll check... thats kinda my guess too
[19:03] <sforshee> kdub_: it shouldn't emit a new event if nothing has changed, so if it's doing that then it's a bug
[19:03] <sforshee> but if the flags are changing, well, then something changed ;-)
[19:03] <pkern> antarus: This is my personal IRC. o_O
[19:03] <antarus> pkern: sure it is ;)
[19:04] <kdub_> from my end, (mir/unity-mir) i see two on's in a row, not sure how to interpret the second one
[19:05] <sforshee> kdub_: how about this: if (signal.state == on && my_screen_state == on) return;
[19:06] <sforshee> ;-)
[19:06] <sforshee> that is if you don't care about any of the flags
[19:07] <antarus> man this build takes its sweet time
[19:08] <antarus> I have 64 cores
[19:08] <antarus> I can do better
[19:08] <kdub_> sforshee, yeah, i'll try something like that
[19:20] <Sarvatt> antarus: dont build under fakeroot, makes it take 10x longer
[19:20] <Sarvatt> aka, debian/rules do_tools=0 do_extras_package=0 no_dumpfile=1 build-arch then fakeroot debian/rules do_tools=0 do_extras_package=0 no_dumpfile=1 binary-debs
[19:22] <antarus> lol
[19:22] <antarus> my build failed
[19:22] <antarus> missing moduels tpm_tis
[19:22] <antarus> god I hate the tpm
[19:23] <antarus> hrm, all the other tpm modules are there, but not tis
[19:23] <antarus> weird
[19:23] <antarus> anyway, lunch
[19:23] <antarus> Sarvatt: thanks for the tips
[19:23] <antarus> I'll try em next time
[19:31] <antarus> ahh I see my error
[19:37] <antarus> ok so tpm_tis used to be a module
[19:37] <antarus> and it can't be with IMA on
[19:37] <antarus> and IMA is not able to be compiled as a module
[19:37] <antarus> and so I broke the kernel abi
[19:40] <antarus> oh
[19:40] <antarus> dch -i
[19:40]  * antarus tsks
[22:45] <spideyman> Hello! does anyone have any quick tips on debugging a compile failure of: make[1]: *** [sub-make] Error 2
[22:45] <spideyman> how do I get more info?