[08:55] <lordievader> Good morning
[09:49] <MJCD_> hey all
[09:49] <MJCD_> i'm still on a CLI based quickmenu style thing
[09:49] <MJCD_> a basic gui that probably implements menu.lst or w/e
[09:50] <MJCD_> but for the command line, there were many pre-windows things like this
[09:50] <MJCD_> searching it I only really find "install xorg"
[09:50] <MJCD_> and that's not at all what i'm after
[11:53] <thelounge7666> I'm still having an issue where systemd-networkd will not re-aquire an IP address if the link goes down, even after restarting the service. only a reboot works. any thoughts?
[17:42] <rbasak> ahasenack: do we understand enough about bug 1865900 to mark it Triaged? I think we do?
[17:46] <teward> rbasak: mind if I take a look at that?
[17:46] <teward> because i've been doing client auth stuff regularly currently and might be able to provide insight/debugs
[17:46] <teward> on ${MULTIPLE_SOFTWARE_ENDPOINTS)
[17:47] <teward> rbasak: is it possible that the issue isn't Apache side?  (https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1834671 is linked by mdeslaur)
[17:53] <rbasak> teward: indeed
[17:53] <rbasak> I just wanted it out of Incomplete status :)
[17:54] <teward> rbasak: well if the issue is $CLIENT and not $SERVER then it's Invalid for Apache
[17:54] <teward> not Triaged.
[17:54] <teward> unless i'm missing something?
[17:54] <teward> (has Apache2 been rebuilt against OpenSSL 1.1.1?)
[17:55] <sdeziel> teward: yes, rebuilt after having TLS 1.3 support backported to Bionic
[18:24] <ahasenack> rbasak: just saw your ping now
[18:24] <ahasenack> teward: I think it's not an apache issue, unless we are willing to disable TLS 1.3
[18:24] <ahasenack> which defeats the point of the SRU that brought it in
[18:24] <teward> ahasenack: well for nginx
[18:25] <teward> in the SRU we *disabled* NGINX TLS 1.3 by default by simply rebuilding against SSL
[18:25] <ahasenack> well, apache had an sru specifically to enable tls1.3, with backported patches and all
[18:25] <teward> yeah i'd nACK that
[18:25] <teward> a similar SRU came in for NGINX
[18:26] <teward> to enable 1.3 by default
[18:26] <teward> and we NACK'd that
[18:26] <ahasenack> that's the only remaining reason to have an apache task: if we want to revert that
[18:26] <ahasenack> rbasak: ^
[18:26] <ahasenack> if not, then we will need tasks for all clients that broke
[18:27] <ahasenack> the fix for that could be to implement pha, or not not use tls1.3 when doing certificate auth
[18:27] <ahasenack> s/not not/to not/
[18:35] <teward> ahasenack: with nginx, we simply disabled TLS1.3 in the ssl_protocols - is there a way to do that in Apache, that is keep TLS1.3 support but disable it on the default available protocols
[18:35] <teward> that way users can still *enable* TLS1.3 but on a selective basis instead of by default
[18:35] <teward> I had extensive discussion with mdeslaur and rbasak and sarnold on this from a security perspective
[18:36] <teward> and we decided to not backport the TLSv1.3 enablement
[18:36] <teward> (but compile nginx against TLS1.3 so we can allow availability)
[18:37] <mdeslaur> I don't think we should revert tlsv1.3 just for the few uses of client side certs
[18:37] <ahasenack> teward: maybe if it's removed from the "ALL" keyword
[18:37] <rbasak> I just wanted to get past triage!
[18:37] <rbasak> Can I mark it New again at least, pending further discussion?
[18:37] <ahasenack> rbasak: if you mark it new, it will get back into triage
[18:37] <teward> ahasenack: well replace "ALL" with -SSLv2 -SSLv3 +TLS1.0 +TLS1.1 +TLS1.2 for the defaults
[18:38] <teward> which is, you know, what we do in nginx-conf
[18:38] <teward> because otherwise it defaults to "ALL" behind the scenes
[18:38] <teward> which for obvious reasons is "Bad"
[18:38] <ahasenack> if pha is part of tls1.3, and some client can't do pha, then that client should perhaps have tls 1.3 removed from its list of protocols it can speak
[18:38] <ahasenack> since it can't, fully
[18:41] <mdeslaur> well then firefox and chromium would get tlsv1.3 removed :P
[18:41] <ahasenack> these clients would break if they talked to an apache server out there that didn't come from ubuntu. They might break if they talk to apache from focal, right? In the same way
[18:42] <ahasenack> mdeslaur: at least firefox supports pha, I haven't checked if anything changed in the chromium side
[18:42] <ahasenack> last I looked they were waiting for some spec
[18:42] <mdeslaur> ahasenack: not by default, you have to enable it in settings because it breaks http2
[18:42] <ahasenack> mdeslaur: ah, that was chromium's wait iirc
[18:43] <mdeslaur> client side certs aren't common enough for them to care about it
[18:43] <mdeslaur> and the workaround to disable tlsv1.3 on the server works
[18:44] <ahasenack> ok, my point is that the same bionic client who fails to do post-handshake-auth in tls1.3 with client certs while talking to the new apache shipped with bionic, will also break when talking to a random web server out there who also offers tls v1.3
[18:44] <mdeslaur> yes
[18:45] <ahasenack> but there was a change in behavior
[18:45] <ahasenack> "stuff was working inside my local net; update apache, stuff broke"
[18:48] <rbasak> ahasenack: back into triage> that's OK - I tagged it server-next, so we can just treat it in our backlog - further triage doesn't really matter then, except to respond to further comments
[18:48] <ahasenack> rbasak: what do you think about the bug being on the server and the client? The quick discussion above
[18:48] <rbasak> I agree it's a regression
[18:49] <rbasak> But equally sometimes we decide to not fix regressions. When it's complicated. This is complicated :-(


[02:20] <stunatra> Is there an easy way to figure out what is causing xubuntu to lockup? Error/event log somewhere?
[02:23] <transfusion> /var/log/syslog, dmesg
[02:30] <stunatra> [    2.784796] input: USB OPTICAL MOUSE as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/0003:093A:2521.0001/input/input2
[02:30] <stunatra> [    2.784812] gpio_ich: GPIO from 436 to 511 on gpio_ich
[02:30] <stunatra> [    2.784908] hid-generic 0003:093A:2521.0001: input,hidraw0: USB HID v1.11 Mouse [USB OPTICAL MOUSE] on usb-0000:00:1a.0-1.5.1/input0
[02:30] <stunatra> [    2.784980] sd 6:0:0:0: [sdc] No Caching mode page found
[02:30] <stunatra> [    2.784984] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[02:31] <stunatra> only error I can find in dmesg
[04:22] <xubuntu21i> hi
[11:33] <CrazyTux> please suggest a good mindmapping application that works on xubuntu.
[14:20] <xubuntu06i> hallo
[14:20] <xubuntu06i> somebody here ?
[14:20] <diogenes_> yes
[14:20] <Spass> hello xubuntu06i, there are 104 people in this room, but probably most of them are idling
[14:22] <pleia2> !ask
[14:22] <pleia2> is the best way to get help :)
[14:50] <TheWild> hello
[14:51] <TheWild> oh never mind, I just realized I have Ubuntu with xfce4 installed, not Xubuntu.
[19:11] <Kumool> thunar seems to scroll to top everytime a file is erased
[19:19] <brainwash> Kumool: probably fixed in version 1.8
[20:27] <Kumool> I doubt I can upgrade xubuntu without screwing up my entire system
[20:28] <brainwash> maybe not worth it
[20:28] <brainwash> however, you can install Thunar 1.8 from the Xubuntu experimental PPA I think
[20:29] <Kumool> naa, not risking it


[00:23] <catbus1> Hi, I am using juju-deployer to deploy workload in lxc containers. I have containers all created and started in RUNNING state, but some of them got IP addresses, some don't. For those that don't have IP addresses, there is no corresponding /var/log/juju/machine-#-lxc-#.log.
[00:24] <catbus1> How do I find out why those containers didn't get an IP?
[00:36] <catbus1> http://pastebin.ubuntu.com/15020637/
[00:40] <catbus1> There is enough IP address in the DHCP pool.
[00:47] <apuimedo> jamespage: the three charms have been updated
[00:54] <apuimedo> jamespage: I put https://bugs.launchpad.net/charms/+bug/1453678 back to new so that you see the new message I wrote
[00:54] <mup> Bug #1453678: New charms: midonet-host-agent, midonet-agnet, midonet-api <Juju Charms Collection:New> <https://launchpad.net/bugs/1453678>
[00:54] <apuimedo> I couldn't assign it to you somehow
[00:54] <apuimedo> I'll not be reachable tomorrow, public holiday
[08:41] <jamespage> dosaboy, your MP's need to be synced from lp:charm-helpers for the source configuration stuff (just spotted that)
[09:18] <dosaboy> jamespage: they are already synced
[09:18] <dosaboy> jamespage: in fact i just re-synced and there was still no diff
[09:18] <jamespage> dosaboy:
[09:18] <jamespage> -branch: lp:charm-helpers
[09:18] <jamespage> 6	+branch: lp:~hopem/charm-helpers/lp1518975
[09:19] <dosaboy> jamespage: hmm that must have crept through, lemme check
[09:20] <dosaboy> jamespage: ah its just the cinder MP, i'll fix that one
[09:20] <jamespage> dosaboy, hah - that was the first I looked at :-)
[09:21] <jamespage> dosaboy, if they are passing please merge away - I have a few xenial fixes to follow up with once you have that landed
[09:21] <dosaboy> jamespage: sure, atcually there are a couple of amulet failures, heat and nova-compute
[09:22] <dosaboy> jamespage: heat is a test that was previously broken but i'm gonna see if i can fix
[09:22] <dosaboy> nova-compute not sure yet
[09:22] <jamespage> dosaboy, I can re-run if need be
[09:22] <dosaboy> jamespage:  k i'll ping when ready
[09:34] <gnuoy> dosaboy, jamespage, got any time for https://code.launchpad.net/~gnuoy/charm-helpers/keystone-v3-support/+merge/285689 ?
[09:42] <dosaboy> jamespage: gonna merge all but heat until it passes since the rest are +1 now
[09:42] <dosaboy> gnuoy: maybe soon...
[09:43] <gnuoy> ta
[10:14] <jamespage> gnuoy, maybe in a bit - on a half day today and wading through midonet reviews atm
[10:14] <gnuoy> ok np
[11:25] <wesleymason> Well here's an odd one
[11:26] <wesleymason> it seems every time I've invoked charm build since the last time I rm -rf'd the built charm, I've ended up with an embedded build inside the last one
[11:26] <wesleymason> so I have: trusty/errbot/trusty/errbot/trusty/errbot/trusty/errbot/trusty/errbot/
[11:26] <wesleymason> 5 levels deep
[11:26] <wesleymason> bet if I call charm build again I end up witha  6th
[11:27] <wesleymason> That can't be expected behaviour, right?
[11:30] <wesleymason> I'm guessing it's not blacklisting the trusty and deps dirs when building in "." (as opposed to a JUJU_REPOSITORY)
[11:35] <wesleymason> https://github.com/juju/charm-tools/issues/106
[12:10] <jamespage> thedac, thanks for the reviews - I've landed swift-storage, nova-* are updated and I've added neutron-gateway which I missed befor
[12:10] <jamespage> I've disable mitaka tests for now; we can re-enable once all of those land
[13:33] <icey> Ursinha: do you by chance have a bundle of what you deployed yesterday that ran into #1517940 ?
[13:33] <mup> Bug #1517940: workload-status is wrong <landscape> <openstack> <sts> <ceph-radosgw (Juju Charms Collection):New> <https://launchpad.net/bugs/1517940>
[13:40] <Ursinha> icey: let me check
[13:42] <icey> Ursinha: I just had it hang for a while at blocked: mon relation missing, and then start executing
[13:45] <Ursinha> icey: so... we don't do bundles
[13:45] <icey> thought that may be the case, no worries
[13:45] <icey> do you have any special config on the mon or radosgw side?
[13:45] <icey> (feel free to pastebin them and PM me)
[13:45] <icey> Ursinha:
[13:55] <Ursinha> icey: done :)
[13:56] <icey> thanks Ursinha, will keep digging
[13:56] <Ursinha> icey: thanks for looking into that
[13:58] <Ursinha> icey: out of curiosity, for how long you waited until the relations settled?
[13:59] <icey> 5 minutes? on AWS
[13:59] <icey> will try to test on OpenStack in a bit
[13:59] <Ursinha> ah, right,
[14:01] <sparkiegeek> icey: the unit should transition out of blocked as *soon* as it sees the relation is established - it should go into maintenance state when it's busy doing things but no longer requires action from the user
[14:02] <icey> sparkiegeek: agreed, and that's what I saw happen
[14:02] <sparkiegeek> 5m is way too long for the charm to spend /noticing/ that it has the relation (even if it has a bunch of stuff to do before all the work for that relation is still ongoing)
[14:02] <icey> but it did take a few minutes between adding the relation and the state changing / hook running
[14:03] <icey> sparkiegeek: I'm curious about how long juju took to trigger the hook execution
[14:03] <icey> I've seen hook execution take a long time to start when juju is fairly heavily loaded before
[14:04] <icey> and not just with the radosgw charm sparkiegeek
[14:04] <icey> either way, need to do mroe digging though
[14:04]  * sparkiegeek nods
[14:04] <sparkiegeek> FWIW we've only seen this with ceph-mon charm, none of the others
[14:04] <sparkiegeek> hence the belief it's a charm bug :)
[14:05] <icey> I've seen it with other charm relations, just not for /that/ long
[14:07] <sparkiegeek> sorry, I mean with radosgw charm relation to ceph-mon
[14:23] <jcastro> http://www.jorgecastro.org/2016/02/12/super-fast-local-workloads-with-juju/
[14:23] <jcastro> jamespage: ^^^
[14:23] <jcastro> I set it all up yesterday
[14:24] <rick_h__> jcastro: <3
[14:24] <jamespage> jcastro, nice...
[14:25] <rick_h__> jcastro: safe to share out or still in editing?
[14:28] <jcastro> share like the wind
[14:47] <stub> icey, sparkiegeek: Was the hook you expected to be triggered actually triggered, or was it the update-status hook? If something was messed up, such as a hook missing executable permissions, the update-status hook kicks in every five minutes or so and can hide the problem.
[14:49] <icey> stub: the hook is a relation joined hook
[14:49] <icey> and the hook usualyl runs fine
[14:50] <icey> occaisonally, it seems like the hook doesn't run (or just takes forever to run)
[14:50] <icey> well, it's a relation-changed and relation-joined so it should have been run
[14:50] <stub> Hooks running on subordinates block other hooks running on the same unit, which might apply here
[14:51] <icey> both of the sides of the relation are primary charms
[14:51] <icey> no subordinates deployed
[14:51] <stub> I think juju run might block hooks too
[14:51] <icey> no juju run
[14:51] <icey> juju deploy x3
[14:51] <icey> juju add-relation(s)
[14:51] <icey> one of the relations never seems to  get related
[14:52] <icey> Ursinha: correct me if I'm wrong
[14:53] <Ursinha> icey: it's like the relation exists but isn't relating :)
[14:53] <Ursinha> I have to remove it and readd
[14:54] <icey> jcastro: already top 10 on HN
[15:13] <jose> freyes: ping
[15:13] <freyes> jose, pong
[15:13] <jose> freyes: hey! I have a quick question on a merge you proposed
[15:13] <jose> have a couple mins to figure this out?
[15:13] <freyes> jose, sure, which one?
[15:14] <jose> freyes: https://code.launchpad.net/~freyes/charms/trusty/memcached/lp1525026/+merge/281254
[15:14] <jose> there's a test in there, test 20. it checks for the 'public-address' on the instance and makes sure it's the same on the memcached.conf file, however, could it work with the private address instead of the public one as well?
[15:16] <freyes> jose, right, that is failing for AWS, because the replication is configured over the private address, and I changed the test to use private-address, the problem with it is that the sentry doesn't have 'private-address'
[15:16] <jose> I thought it did...
[15:16] <freyes> I have to dig in it yet, not sure why that happens
[15:16] <freyes> yup, I thought the same
[15:16] <jose> marcoceppi: do sentries in amulet have private addresses? e.g. AWS with public-address and private-address on config-get
[15:17] <jose> freyes: the other option would be to have it as a `juju-run` and get it from there
[15:18] <freyes> jose, yes, not happy with that approach, but could be enough to get it passing
[15:21] <sparkiegeek> icey: Ursinha: stub: there /are/ subordinates in play here
[15:31] <thedac> jamespage: wrt, xenial MPs. great. I'll shepherd any remaining ones in today.
[15:42] <rick_h__> juju on hackernews ftw #4 atm make sure to vote and keep an eye out in case of questions and such https://news.ycombinator.com/news
[15:57] <marcoceppi> rick_h__: you mean #2 :)
[15:57] <rick_h__> marcoceppi: it's moving up and up wheeee
[15:59] <sparkiegeek> I need to find where jcastro keeps his bug tracker
[15:59] <sparkiegeek> jcastro: s/ubuntu-trust/ubuntu-trusty/ in the lxc launch command
[16:05] <marcoceppi> sparkiegeek: he's at an appointment, atm but his bug tracker is overflowing - best to just ping him directly ;)
[16:21] <marcoceppi> rick_h__: how do i make a charm I published public?
[16:21] <marcoceppi> what's the change-perms encantation?
[16:23] <rick_h__> marcoceppi: charm2 change-perm cs:xxxx --add-read=everyone ?
[16:23] <rick_h__> atm I think
[16:23] <marcoceppi> thta's it
[16:24] <marcoceppi> rick_h__: all I have to do now is create an account in juju with the username "everyone" ;) ;)
[16:24] <rick_h__> marcoceppi: pretty sure it's not allowed
[16:24] <rick_h__> marcoceppi: oh you mean juju...but you have to charm login so it's not the same
[16:25] <marcoceppi> rick_h__: everyone worked, thanks! I love the instant gratification of stuff landing in the sore
[16:25] <marcoceppi> stor
[16:25] <marcoceppi> e
[16:25] <rick_h__> marcoceppi: instant gratification is most gratifying
[16:25]  * rick_h__ runs for lunchables
[16:27] <cory_fu> marcoceppi: Did you by chance get the juju-deployer apt package updated for the plebs like me that occasionally still use it?  :)
[16:27] <marcoceppi> cory_fu: no, not yet
[16:27] <marcoceppi> I've had to run errands all day
[16:27] <bdx> icey, jamespage: I'm getting "No block devices detected using current configuration" Message for one of my ceph-osd nodes  .... I'm wondering if there is some insight you can give on this before I jump in .... you can see my devices all exist -> http://paste.ubuntu.com/15025182/
[16:28] <cory_fu> marcoceppi: No worries.  Just keeping it on your radar.  :)
[16:28] <icey> bdx what's your config look like for osd-devices?
[16:28] <cory_fu> marcoceppi: btw, I'm going to be spending time today on these issues for the charm-tools deadline: https://github.com/juju/charm-tools/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.0
[16:28] <icey> bdx: can look after lunch, solid meetings around lunchtime so be back soon
[16:29] <cory_fu> Let me know if you disagree with any of those being required for 2.0
[16:29] <bdx> icey: http://paste.ubuntu.com/15025196/
[16:35] <marcoceppi> cory_fu: LGTM make sure to target the road-to-2.0 branch for these
[16:36] <cory_fu> Will do, thanks
[17:03] <icey> bdx: any chance that it has settled and found the devices now?
[17:07] <bdx> icey: https://bugs.launchpad.net/charms/+source/ceph-osd/+bug/1545079
[17:07] <mup> Bug #1545079: "No block devices detected using current configuration" <ceph-osd (Juju Charms Collection):New> <https://launchpad.net/bugs/1545079>
[17:12] <icey> bdx: the charm won't get around to adding storage until it can confirm that the cluster is bootstrapped, which requires the osd be able to talk to the mon quorum
[17:16] <bdx> icey: it can talk to the mons just fine .... it just didn't have dhcp assigned to its repl/cluster interface
[17:17] <bdx> icey: now that it has an ip on the cluster network ... it deploys.
[17:17] <icey> yeah bdx, if it can't talk on its cluster network, it won't bootstrap :-P
[17:18] <icey> glad it works now!
[17:21] <bdx> icey: yeah ... totally .. didn't pay attention to the node interfaces getting wiped clean at commissioning. thanks!
[18:45] <jcastro> sparkiegeek: I fixed that, my CDN might or might not be caught up wherever you are
[19:00] <cory_fu> lazyPower: Do you have a copy of the stacktrace for https://github.com/juju/charm-tools/issues/102
[19:00] <lazyPower> cory_fu not off hand but i can make one really quick, gimme a sec to fire up a container and pip install charm-tools without git installed
[19:01] <cory_fu> Thanks
[19:21] <cory_fu> lazyPower: Nevermind, I reproduced it
[19:29] <lazyPower> cory_fu - awesome, sorry i got distracted
[19:30] <cory_fu> lazyPower: No worries.  Your explanation on how to reproduce it clued me in
[19:35] <cory_fu> marcoceppi: The road-to-2.0 branch is behind master by several commits.  Any objection to me bringing it up to date before I start creating MPs against it?
[19:36] <marcoceppi> cory_fu: not at all
[19:37] <cory_fu> marcoceppi: It won't ff merge.  Do you prefer a rebase or non-ff merge?
[19:37] <marcoceppi> cory_fu: rebase, tbh
[19:37] <marcoceppi> since it's a feature branch
[19:37] <cory_fu> Ok, that's my preference as well, but they were your commits that will be rewritten
[19:47] <admcleod-> is there a document which lists environment variables that should be set for juju2.0?
[19:48] <jcastro> 10 minute warning until office hours!
[19:54] <jcastro> jose: around?
[19:56] <marcoceppi> jcastro: you setting up the hangout?
[19:56] <marcoceppi> cory_fu: I seem to agree that charms.layer should be split to it's own library at this point
[19:57] <jcastro> https://plus.google.com/hangouts/_/j74qty46pdo6how2xcj4j573aea
[19:57] <jcastro> marcoceppi: ^^^
[19:57] <jcastro> anyone who wants to join the office hours hangout is welcome to do so, see the above link
[20:04] <lazyPower> urgh, i want to attend but the hangout plugin keeps crashing here :( i guess i'll just listen
[20:04] <marcoceppi> o/
[20:09] <lazyPower> man! Even hacking around on maas 1.9, nicely done Gilbert!
[20:14] <MemeTeam6> who /tpg/ here
[20:14] <marcoceppi> https://lists.ubuntu.com/archives/juju/2016-February/006447.html
[20:15] <arosales> https://lists.ubuntu.com/archives/juju/2016-February/006447.html
[20:16] <lazyPower> MemeTeam6 - thinkpad user?
[20:16] <marcoceppi> ppa:juju/devel
[20:21] <lazyPower> wooo multi-model-stateserver!
[20:21]  * lazyPower throws confetti
[20:21] <kwmonroe> woohooo juju deploy bundle!
[20:21] <lazyPower> argh i said it again... i mean multi-model-controller
[20:22] <lazyPower> All these awesome features in succession, i wonder if the watchers really get how much progress this really is we just showed in under 60 seconds
[20:29] <arosales> https://lists.ubuntu.com/archives/juju/2016-February/006498.html  -- juju release notes
[20:39] <lazyPower> marcoceppi - charms.ansible landed during the summit, which is a supporting extension of michael nelsons work
[20:40] <lazyPower> https://github.com/chuckbutler/charms.ansible - readme and proper documentation forthcoming in ~ a week
[20:41] <lazyPower> it'll move to juju-solutions after its documented
[20:41] <lazyPower> and put under CI
[20:42]  * lazyPower fanfares @ NS950 and their doc contributions
[20:49] <arosales> "ERROR the name of the model must be specified"
[20:49] <arosales> on juju bootstrap
[20:49] <rick_h__> arosales: have to give the controller a name on bootstrap
[20:50] <rick_h__> arosales: because now you can bootstrap several times, each with their own name e.g. staging and production
[20:50] <marcoceppi> arosales: juju bootstrap -m "environment-name"
[20:50] <rick_h__> arosales: the error should be 'controller name' vs 'model name'
[20:50] <rick_h__> which is interesting, will have to talk to wallyworld about that one.
[20:50] <arosales> -m was the key there
[20:50] <rick_h__> oh hmm, shouldn't be behind a flag according to the spec
[20:51] <arosales> note the juju docs for "juju help bootstrap" does not state the -m is mandatory
[20:51]  * rick_h__ goes and double checks
[20:51] <arosales> so "juju bootstrap -m aws-east1" is what worked for me
[20:52] <arosales> given my environment.yaml file in ~/.local/share/juju and has a aws-east1 stanza
[20:52] <rick_h__> arosales: ok yea, that'll turn ingo "juju bootstrap $controllername $credentialname"
[20:52] <rick_h__> arosales: but looks like it's not there yet
[20:54] <arosales> rick_h__: ack, juju help bootstrap just told me "usage: juju bootstrap [options]" which I am sure is just a case of the alpha help commands not being updated
[20:54] <rick_h__> arosales: yea
[20:55]  * arosales finally bootstrapping though after moving my environments.yaml file and appending -m <env-name> on bootstrap
[20:55] <arosales> thanks rick_h__ and marcoceppi
[20:56] <lazyPower> arosales - we both hit that today :D rick_h__ showed me up by sneaking out -alpha2 with a full announcement while i wasn't watching
[20:56] <lazyPower> awesome office hours gents!
[20:56] <arosales> +1
[20:56]  * arosales learned a lot
[20:56] <lazyPower> arosales - know what my favorite part was?
[20:57] <arosales> lazyPower: mbruzek orange shirt?
[20:57] <lazyPower> arosales - thats a close second -  jujusolutions/charmbox:devel already had *everything* i needed :P  simply update an alias and we're ready to goooooooo
[20:57] <rick_h__> lazyPower: is the recording up?
[20:57] <lazyPower> rick_h__ if you hit ubuntuonair.com its there and ready for you
[20:57]  * lazyPower is currently watching a resources demo
[20:58]  * lazyPower is pretty excited about this!
[20:58] <arosales> lazyPower: nice
[20:58]  * rick_h__ loads it up
[20:58] <arosales> man jorge I should have mentioned how folks can try xenial in AWS
[20:58]  * arosales to send that to the list
[20:59] <arosales> xenial with juju that is.
[20:59] <lazyPower> arosales oh yeah!! do that!
[20:59] <arosales> will do
[20:59] <lazyPower> i'll send you a pizza :D
[21:04] <jcastro> omg
[21:05] <jcastro> on the flipside of the create-model being fast
[21:05] <jcastro> destroy-model is instant
[21:05] <arosales> mmmm pizzza :-)  lazyPower
[21:05] <arosales> all meat please
[21:06] <jrwren> do pizza bribes work well here, I'll start using them often if they do.  ;]
[21:06] <marcoceppi> rick_h__: does the gui team know of the alpha2 login issues?
[21:07] <cloudguru_> Need to know who is working on a layer-docker charm for openVswitch as an SDN layer for MWC
[21:07] <jrwren> marcoceppi: yes, we know. we cry about it every night. I'm filling a bucket with tears as i write this.
[21:08] <marcoceppi> cloudguru_: you should ping lazyPower
[21:08] <cloudguru_> thx.  already done.
[21:08] <lazyPower> cloudguru_ o/ heyo
[21:08] <lazyPower> i'm still here
[21:09] <rick_h__> jrwren: this is that the gui isn't 2.0 api ready? Or something else?
[21:10] <jrwren> rick_h__: it is that exactly. Better not be something else.
[21:10] <rick_h__> jrwren: k
[21:10] <lazyPower> cloudguru_ i'm really out/offline today, but i stuck around to do office hours. anything specific I can answer? is this coming up to crunch time and causing an issue?
[21:10] <rick_h__> jrwren: yea, just making sure it's not a different bug/etc. I'd not heard of anything there.
[21:12] <cloudguru_> @lazyPower .. all good.  We can the scripts but docker charm for OVS is preferred
[21:12] <lazyPower> cloudguru_ that initial stab at the layer for OVS was basically an encapsulation of that script
[21:12] <lazyPower> should be able to juju deploy the built charm --to 0 and bypass the entirety of running the script
[21:13] <cloudguru_> re: lxc lBR clusters for openstack .. you guys are right.  I'm pretty such this is how the nebula appliance worked under the covers on a single (huge) appliance.
[21:13] <lazyPower> as its delivered on furst run
[21:13] <lazyPower> *first run
[21:14] <cloudguru_> Nice !!!
[21:14] <lazyPower> i need to step out, i have somewhere to be in 45 minutes across pittsburgh, but i left you my # in an im cloudguru_  - feel free to call
[21:14] <lazyPower> sorry i'm pressed for time :\
[21:14] <cloudguru_> LXC OpenStack on full killer .. pretty much OpenStack Magnum
[21:15] <rick_h__> lol at marcoceppi wanting to make sure "no one wants to look at my face"
[21:34] <jose> jcastro: just got your ping, was stuck at work with no internet
[21:38] <jcastro> no worries, I was just editing ubuntuonair
[21:58] <cory_fu> marcoceppi: Did you see I updated https://github.com/juju/charm-tools/pull/108 ?
[22:00] <jcastro> ok with a new machine I need to test it, any hardcore bundles that can exercise my system?
[22:00] <rick_h__> jcastro: I'd think kwmonroe's would be best
[22:00] <marcoceppi> cory_fu: thanks!
[22:01] <marcoceppi> jcastro: juju deploy -n 1000 cs:~jorge/trusty/boinc
[22:01] <jcastro> rick_h__: that didn't really break a sweat
[22:01] <rick_h__> jcastro: add moar units?
[22:01] <jcastro> I suppose I could actually run something in hadoop
[22:01] <rick_h__> jcastro: was that the realtime-syslog-analytics?
[22:02] <jcastro> yeah
[22:26] <marcoceppi> hey cory_fu
[22:27] <cory_fu> Yes?
[22:27] <marcoceppi> https://github.com/juju/charm-tools/issues/115 should we just create a `$JUJU_REPOSITORY/build/<charm_name>` instead? or just put <charm_name> in JUJU_REPOSITORY?
[22:28] <rick_h__> marcoceppi: cory_fu just a heads up on the series in metadata. The UI team was working on updating the charmstore to support that and the jujucharms.com website
[22:28] <rick_h__> marcoceppi: cory_fu and I'm not 100% sure where that's left off (e.g. might be comitted but not yet deployed)
[22:28] <marcoceppi> rick_h__: right, but it will make it to 2.0 ?
[22:28] <rick_h__> marcoceppi: cory_fu definitely
[22:28] <marcoceppi> this is all work planned for charm-tools 2.0
[22:28] <marcoceppi> not the 1.11.2 release
[22:28] <rick_h__> marcoceppi: cory_fu ah ok np then
[22:29] <cory_fu> marcoceppi: Crap.  I would have liked to get some of these changes that I landed today into 1.11.2.  I assume we can backport them?
[22:29] <marcoceppi> cory_fu: we can totally backport
[22:29] <marcoceppi> cory_fu: 2.0 will be released with the new charm command from uros team
[22:29] <marcoceppi> cory_fu: which I need to get into xenial like tomorrow
[22:30] <marcoceppi> cory_fu: so I will upload charm/charm-tools 2.0 to the juju/devel ppa
[22:30] <marcoceppi> but we can still do 1.X releases
[22:30] <cory_fu> marcoceppi: Cool.  And as for the directory layout, I'm not sure.  I guess we should come up with a different recommendation than suggesting $LAYER_PATH etc be subdirectories of $JUJU_REPOSITORY
[22:30] <marcoceppi> and we can worry about backports later
[22:30] <marcoceppi> cory_fu: I think it's a good idea still, tbh
[22:31] <cory_fu> marcoceppi: What's still a good idea?
[22:31] <marcoceppi> cory_fu: it's kind of like the GOPATH stuff
[22:31] <marcoceppi> cory_fu: $JUJU_REPOSITORY being an umbrella for stuff
[22:31] <marcoceppi> cory_fu: though, it doesn't have to live in JUJU_REPOSITORY, since LAYER_PATH and INTERFACE_PATH are individual settings
[22:31] <cory_fu> Ok, but how is the new juju going to handle "juju deploy foo" where foo is checked out locally?
[22:32] <marcoceppi> cory_fu: gooooood point
[22:32] <marcoceppi> cory_fu: so we could just put the charm_name in the $JUJU_REPOSITORY
[22:33] <marcoceppi> $JUJU_REPOSITORY/charm
[22:33] <cory_fu> There's nothing really stopping us from keeping the same pattern and having a "layers" directory under $JR.  It just means no one can have a charm named "layers" (or "interfaces")
[22:33] <marcoceppi> right
[22:33] <marcoceppi> which seems silly
[22:33] <marcoceppi> cory_fu: I could also see someone doing $JR/src/layers,interfaces
[22:33] <cory_fu> I like something like $JR/{layers,interfaces,charms}
[22:33] <cory_fu> I'd be ok with that, too
[22:34] <marcoceppi> cory_fu: we should figure out how juju will handle $JR now in 2.0 though
[22:34]  * marcoceppi is off to #juju-dev unless rick_h__has feedback
[22:35] <marcoceppi> cory_fu: as a work around we could do $JR="$HOME/stuff/charms"; $LAYER_PATH=$JR/../layers; etc
[22:36] <cory_fu> I guess.  Though that breaks my handy dev env switching aliases that change $JR and allow me to have, e.g., a pristine $JR for RQ
[22:36] <cory_fu> Including layers, interfaces, etc
[22:36] <cory_fu> But I can work around it
[22:37] <marcoceppi> cory_fu: well would ranter not do that then
[22:37] <cory_fu> Also, this only really applies to the default values for LAYER_PATH etc.  If they're set manually, they can be whatever the user wants
[22:39] <marcoceppi> true
[22:46] <apuimedo> jcastro: nice article about the juju lxd that jamespage told me he was using
[22:46] <apuimedo> I'm getting some issue when doing the bootstrap
[22:46] <apuimedo> ERROR there was an issue examining the model: invalid config: Can not change ZFS config. Images or containers are still using the ZFS pool
[22:49] <cory_fu> marcoceppi: Updated https://github.com/juju/charm-tools/pull/113
[22:52] <apuimedo> any idea about that error?
[23:03] <koaps> hi guys, I'm having an issue with juju ha, wondering if anyone could help me troubleshoot
[23:04] <apuimedo> koaps: juju ha? hacluster?
[23:09] <koaps> apuimedo: juju ha
[23:09] <koaps> my two addition servers just stay in adding-vote
[23:09] <apuimedo> koaps: servers of which charm?
[23:10] <koaps> juju ensure-availability --to 1,2
[23:10] <koaps> the server 1 and 2 never get vote
[23:10] <koaps> this has worked
[23:10] <koaps> but we are rebuilding the environment, now it's not
[23:10] <aisrael> marcoceppi: I got it working \m/
[23:11] <koaps> seems like some software package changed and mongodb isn't working right
[23:12] <apuimedo> sorry, I've only got experience developing charms with ha support, haven't tried the "ensure-availability" command


[00:03] <slangasek> pitti, cjwatson: hmm, so I notice that the startup time is the same if I call update-manager with --no-update as without; so whatever it's doing takes a long time, and the question of whether it checks the server for updates seems to have no impact
[03:56] <infinity> jbicha: Please don't arch restrict just to hide build failures.
[03:57] <infinity> jbicha: porters use the FTBFS list as a TODO list, there's no harm in having things not build that need porting/fixing.
[03:57] <infinity> jbicha: (Backing out your openimageio diff)
[03:59] <infinity> jbicha: One of those build failures is a simple qreal porting exercise, the other is just using GCC intrinsics properly, neither one is a fundamental "this can only work on x86" issue (like, say, nvidia binary blobs).
[04:02] <jbicha> infinity: ok...but wouldn't the package be stuck in -proposed?
[04:02] <infinity> jbicha: No.
[04:02] <infinity> jbicha: proposed migration ensures that things are built on the arches where they were previously.
[04:02] <infinity> jbicha: And since this was always FTBFS on arm/powerpc, that'll work fine.
[04:02] <jbicha> infinity: thanks, the proposed migration was the only reason I did that
[04:03] <infinity> jbicha: If you've been doing this sort of thing more elsewhere, can you please undo it?
[04:03] <infinity> jbicha: proposed-migration is the same as Debian testing in this regard.  Testing only cares about build regressions, if something's never built on an arch, it's fine if it continues to not do so.
[04:04] <infinity> (And, conversely, if it HAS built elsewhere before, it's a bug when it stops doing so, and we should generally try to fix it, not ignore it)
[04:45] <micahg> infinity: and livecd-rootfs changes you were planning to make?  if not, I'll go ahead an upload changes for Ubuntu Studio
[04:46] <micahg> *any
[05:00] <pitti> good morning
[05:02] <pitti> slangasek: no reports, but I just tried to check that, and update-manager crashes right away with "ImportError: No module named UpdateManager.UpdateManager"
[05:03]  * pitti reinstalls it, I think I've seen this before when attempting to sponsor a branch for mterry
[05:04] <pitti> ok, that worked
[05:05] <pitti> slangasek: so just calling "update-manager" here takes some 10 seconds, then shows me the updates
[05:05] <pitti> slangasek: (I did run apt-get update just before, though, so updating indexes was fast)
[05:06] <FourDollars> Who can help me to review https://code.launchpad.net/~fourdollars/software-properties/fix-1138121-a-typo-in-CountryInformation.py/+merge/151870 ?
[05:06] <FourDollars> It is just a litte typo.
[05:07] <FourDollars> s/litte/little/
[05:14] <micahg> infinity: nevermind, I'm uploading
[05:32] <jefimenko> does anyone here know how to run the equivalent of debuild using pbuilder-dist? "pbuilder-dist build" requires a .dsc file
[05:33] <lifeless> is there a pdebuild-dist ? There is a pdebuild
[05:34] <slangasek> pitti: interesting
[05:34] <jefimenko> yes, there is pdebuild
[05:34] <jefimenko> and pbuilder-dist
[05:35] <jefimenko> the man page for pbuilder-dist says that the `operation` argument can be any operation that pbuilder supports
[05:36] <jefimenko> one of those operations is debuild, but pbuilder-dist errors out when i try to use it
[06:55] <infinity> micahg: Checking bzr for pending changes would have worked, but I don't think anyone has any.
[06:55] <infinity> micahg: Oh, and you committed to bzr anyway.  So, yay.
[07:03] <pitti> yay for apt-get autoremove cleaning up old kernels
[09:50] <mitya57> doko: when was the last time you built those docs successfully?
[09:50] <mitya57> maybe it's related to https://bazaar.launchpad.net/~mitya57/ubuntu/raring/python-docutils/0.10-1ubuntu1/revision/32
[09:51] <doko> mitya57, see the publishing history
[09:53] <mitya57> yes, the previous version was built with old docutils
[09:53] <mitya57> let me look at the docs source
[09:56] <mitya57> looks like it fails to process lines like ".. _getting-started:"
[09:56] <testi> Will Applications compiled for Mir run natively without compatibility layer (protocol translation, additional context switches) on Wayland Compositors? Does that apply for the other direction too? By application I mean anything not deeply integrated with the system, especially games, because under no circumstances I want Mir to introduce any delay (context switch, protocol translation) only because some game developer has chosen Mir as ta
[09:57] <testi> Is Mir capable of reliable bypass offscreen on fullscreen? (also in order to reduce delays)?
[09:58] <Laney> ubuntu
[09:58] <Laney> err, #ubuntu-mir is where you'll get proper answers to mir questions
[09:58] <testi> okay, thanks
[10:03] <xnox> slangasek: pitti: i have been noticing significant cpu usage from update-manager with top when my system is in swapdeath / under heavy load.
[10:06] <Adri2000> it seems that pkgbinarymangler removes upstream changelog without removing the associated symlink if there is one (created by dh_installchangelogs -k). that leaves a broken symlink in the package. bug, right?
[10:06] <seb128> Adri2000, does the package depends on a binary that provides the symlink target?
[10:07] <Adri2000> seb128: no
[10:08] <Adri2000> it's all in the same package
[10:08] <seb128> k, dunno then
[10:20] <infinity> Adri2000: Sounds like a bug to me.
[10:20] <infinity> Adri2000: Assuming the behaviour actually matches what you described.
[10:40] <mitya57> doko: lp:~mitya57/ubuntu/raring/python-docutils/disable-references-patch disables the patch, and I've reported a bug
[10:41] <mitya57> https://sourceforge.net/tracker/?func=detail&aid=3607029&group_id=38414&atid=422030
[10:41] <doko> mitya57, ohh, I already had report the bug, see the email
[10:41] <mitya57> doko: commented there as well, please close it (I'm not able to do that)
[10:42] <mitya57> it's not a Sphinx issue
[10:42] <doko> ahh, ok
[10:43] <mitya57> btw it's a kind of issue that won't happen when britney will test-build all rbuilddepends before copying to -release
[13:17] <zyga> hey
[13:18] <zyga> I have a Lenovo G580 laptop, it just stopped booting current raring (it hangs on boot), one thing it does display is "mount: unable to allocate memory" for "/sys/firmware/efi/efivars"
[13:18]  * zyga hopes that's not laptop bricking on some EFI bug
[13:18] <hyperair> nah, if it bricked all you would see is a black screen
[13:19] <hyperair> with no text
[13:19] <hyperair> no boot logo
[13:19] <hyperair> nothign
[13:19] <zyga> yeah, it's not dead-dead
[13:19] <hyperair> then you have hope
[13:20] <hyperair> in any case, i think only samsung has a history of making chips that are brickable from supposedly valid commands
[13:20] <zyga> it seems to be a regression
[13:20] <hyperair> hmm i think there was an e1000e issue once as well
[13:20] <zyga> I just booted an earlier kernel
[13:20] <hyperair> ah
[13:20] <zyga> let me see if it really works
[13:20] <hyperair> there you go
[13:20] <zyga> yup
[13:20] <zyga> desktop
[13:21] <zyga> let's see the next kernel
[13:21] <zyga> so it _works_ on 3.8.0-5
[13:21] <hyperair> file a bug
[13:21] <hyperair> and head over to #ubuntu-kernel
[13:21] <zyga> yeah
[13:21] <zyga> checking next kernel
[13:32] <Hobbsee> So long, and thanks for all the fish, guys & girls!
[13:41] <slangasek> xnox: it's not swapdeath / heavy load for me, except for update-manager itself using the CPU
[13:45] <hyperair> Hobbsee: you make it sound like you're leaving the ubuntu project.
[13:45] <Hobbsee> hyperair: I am
[13:45] <Hobbsee> Still running Ubuntu on a few things though
[13:45] <hyperair> wat
[13:45] <hyperair> whyyyy
[13:49] <Hobbsee> hyperair: It was summed up pretty well in http://doctormo.org/2013/03/06/ubuntu-membership-2/
[13:51] <hyperair> hmm =\
[13:51] <hyperair> that's a pity
[13:51] <Hobbsee> Indeed
[13:54] <jcastro> Hobbsee: sorry you feel that way!
[13:58] <ScottK> So long Hobbsee.    What have you switched to?
[14:03]  * ScottK doesn't even know what "Technical Architect (Client)" means.
[14:05] <mlankhorst> presumably the client is a team
[14:06] <ScottK> No idea.
[14:06] <ScottK> There was a "Client" track for UDS, so I assume it's somehow related.
[14:08] <Hobbsee> ScottK: I haven't switched my work machine  & laptop to anything else yet.  We'll see, on that front.  As for the desktop, it's using windows for gaming
[14:08] <ScottK> Hobbsee: OK.  Maybe we'll see you in Debian then.
[14:08] <Hobbsee> ScottK: possibly.  You never know :)
[14:29] <davmor2> guys I did an install from this mornings cd I open the dash I have the cursor in the search bar turning I see the home lens and that's it
[14:50] <pitti> davmor2: dash search is quite broken right now, didrocks says it's being fixed
[14:51] <pitti> hm, your's sounds different, though
[14:51] <didrocks> davmor2: pitti: part of the batch of fix, the lenses are not recommended by default
[14:51] <davmor2> pitti: sorry I thought I was on the ubuntu-unity channel when I typed this I'm in there now looking through it
[14:52] <pitti> davmor2: so you hit the right channel after all :)
[14:52] <didrocks> so if you removed the lenses, yeah, you won't have them :)
[14:52] <didrocks> (fix is still building)
[14:53] <davmor2> didrocks: this is a fresh install
[14:53] <didrocks> davmor2: makes even more sense if you took today's daily :)
[14:53] <didrocks> yeah, lenses are not installed by default, I missed a build-dep when moving the lens recommendation in a perl script parsing a json file
[14:53] <davmor2> didrocks: Yeap it's an up-to-date iso
[14:54] <didrocks> and so the recommends: stenza is empty
[14:54] <davmor2> didrocks: this is what I see http://ubuntuone.com/4VY5XIUSXNWvpTzctl3hS9
[14:54] <didrocks> wait for next unity
[14:54] <didrocks> it's fixing it
[15:03] <micahg> infinity: I checked the bzr branch, I was looking for conservation of uploads :)
[15:04] <infinity> micahg: Ahh, the 738th law of thermodynamics.
[15:53] <jcastro> plenty of room for lightning talks
[15:53] <jcastro> don't make me start assigning people!
[15:57] <ev> my debian/control fu is rusty. Is there a way to specify a dependency equal to just the major version component?
[15:58] <pitti> ev: you can certainly do things like "firefox (>= 3)", it doesn't matter how much prefix you use
[15:58] <pitti> jcastro: one/two-minute LTs ok as well, I suppose?
[15:58] <ev> pitti: I thought that might be the case, but dpkg --compare-versions behaved differently so I wasn't certain
[15:59] <ev> pitti: thanks!
[15:59] <pitti> ev: orly?
[15:59] <pitti> people do that all the time with e. g. debhelper (>= 9)
[15:59] <ev> oh, does it fall over with strictly equals?
[15:59] <jcastro> pitti: sure, I'm mostly just interested in showing off cool things, so if it's less than 5 that's totally ok
[15:59] <ev> for example:
[16:00] <ev> dpkg --compare-versions 1.0.17 '=' '1.0'; echo $?
[16:00] <ev> 1
[16:00] <ev> that would make sense, but then how would I express 1.0.x series is fine, 2.0.x wont work
[16:01] <OdyX> conflicts >= 2~ ?
[16:01] <pitti> right, or depends <= should probably also work
[16:02] <slangasek> ev: you'd do it as depends: foo (>= 3), foo (<< 4)
[16:02] <ev> slangasek: ah, of course! Thanks muchly!
[16:06] <cjwatson> ev: Depending on what you're doing, the ${source:Upstream-Version} substvar may be helpful too (deb-substvar(5))
[16:06] <cjwatson> Sorry, deb-substvars(5)
[16:06] <cjwatson> Only if the dependency is on something else within your own source
[16:06] <ev> separate package (separately built library depending on the 1.0.x series of Cassandra)
[16:06] <ev> yeah
[16:06] <cjwatson> OK
[16:07] <ev> thanks though!
[16:07] <slangasek> :)
[16:15] <zul> mterry:  ping can we get python-json-patch MIRed as well please
[16:16] <mterry> zul, I didn't notice that MIR
[16:16] <zul> mterry: i though it subscribed ubuntu-mir
[16:16] <mterry> zul, doesn't look like it.  Looking now anyway.  But please sub them
[16:16] <zul> mterry:  just did
[16:21] <mterry> zul, I talked to the Debian maintainer of the json-pointer package, and he said we probably shouldn't be dropping the openstack-pkg-tools
[16:22] <mterry> zul, I opened a MIR for it already (it's super tiny, shouldn't be a problem)
[16:22] <mterry> zul, if we can promote that, we can go back to sync for json-pointer at least
[16:22] <zul> mterry:  i disagree there is really no reason for that build-depend
[16:23] <mterry> zul, it only provides some maintainer-oriented functionality now.  But he says that may change in future.  Plus, it forces us to keep a delta.  It's not worth it when we can just MIR it easily.  Is there a reason to actively pursue dropping it?
[16:25] <zul> mterry:  it doesnt add any value at all and not worth it
[16:26] <mterry> zul, "worth it"?  What is it costing us?
[16:26] <mterry> Debian packages do all sorts of things that we aren't directly interested in
[16:27] <zul> mterry:  its a superflous dependency and a bad idea imho
[16:30] <mterry> zul, I don't mind a superfluous dependency as long as it is tiny and build-time like this one.  I do mind deltas that don't serve us much purpose.  So can you expand on the "bad idea" comment?  What active harm is the build-dep doing?
[16:33] <zul> mterry:  its not doing any harm i just dont think its a good idea because the maintenance stuff that is intended for openstack-pkg-tools is not really used in the python-json-patch package or anywhere else
[16:34] <mterry> zul, I agree it's not actively helping.  But as long as it's not actively hurting, I'd rather avoid the delta
[16:35] <zul> mterry:  fine
[16:35] <mterry> zul, I already filed a MIR for it and assigned to didrocks
[16:35] <zul> mterry:  k
[16:35] <didrocks> yep
[17:45] <dobey> hrmm. is there a good overview of how autopkgtests work in practice? i have the spec document open, but it doesn't really say anything about how test runs get triggered
[17:47] <mitya57> dobey: http://developer.ubuntu.com/packaging/html/auto-pkg-test.html#executing-the-test
[17:49] <dobey> ah, thanks
[17:53] <dobey> hrmm
[17:54] <dobey> "…or [when] any of their reverse-dependencies change." <- this is for example the output of apt-cache rdepends $package? or if any of the dependencies listed in Depends: in tests/control change?
[17:54] <jtaylor> the ones in tests/control
[17:54] <jtaylor> but it doesn'T work
[17:54] <jtaylor> (in ubuntu adt jenkins)
[17:55] <dobey> oh; so tests only get run when the package is uploaded, at the moment?
[17:56] <jtaylor> it probably depends, some packages to rebuild some don't
[17:56] <jtaylor> (its a bug)
[17:58] <mitya57> jtaylor: by the way, any news about scipy tests failing?
[17:58] <jtaylor> mitya57: the adt tests?
[17:58] <jtaylor> the atlas one looks ugly
[17:58] <mitya57> jtaylor: yes, maybe disable it?
[17:59] <jtaylor> the other one is due to ubuntu compressing png's
[17:59] <jtaylor> I filed a bug upstream for that
[17:59] <jtaylor> still need to look at the atlas failure, that will be fun
[17:59] <mitya57> but why only on amd64?
[18:00] <mitya57> hm, pyxdg is also failing...
[18:00] <Laney> fixed that one
[18:00] <Laney> uploading in 2 mins
[18:00] <jtaylor> mitya57: which one is amd64 only?
[18:00] <jtaylor> atlas fails on i386, and that is not unusual for rounding issues
[18:01] <jtaylor> i386 is horrible concerning that
[18:01] <mitya57> jtaylor: my wrong, numpy was failing only on amd64, scipy fails on i386 as well
[18:02] <jtaylor> mitya57: numpy is fixed
[18:02] <dobey> pyxdg needs to get replaced (removed)
[18:02] <jtaylor> mitya57: it was just not rebuild due the bug I mentioned earlier
[18:02] <mitya57> dobey: ???
[18:02] <dobey> jtaylor: is there any way to say "only run the tests when the deps change, not when it uploads" ?
[18:02] <jtaylor> dobey: probably not, what would be the use case?
[18:02] <dobey> mitya57: pyxdg is unmaintained. apps need to move off of it, really
[18:03] <dobey> jtaylor: well, i don't really want to just run the same tests twice when i upload something (once in the normal source build, and then again in the autopkgtests). seems like a waste of time
[18:03] <mitya57> dobey: it's now well maintained by Thomas Kluyver — who is also upstream developer
[18:04] <Laney> I have fixed it
[18:04] <jtaylor> dobey: true, but you can do in adt tests what you can't do during the build
[18:05] <jtaylor> dobey: e.g. scipy and numpy, it tests blas, atlas and openblas
[18:05] <jtaylor> dobey: impossible during the build
[18:05] <dobey> jtaylor: what do you mean?
[18:05] <mitya57> Laney: pyxdg? thanks! Will you commit it to Debian or should I do that? :)
[18:05] <Laney> if you can, feel free
[18:06] <Laney> it's an upstream cherry-pick
[18:06] <dobey> jtaylor: i don't quite understand that
[18:06] <jtaylor> dobey: numpy and scipy can have their blas provider replaced underneath them, during the build I can't install new packages, in adt tests I can (via test dependencies)
[18:07] <Laney> mitya57: if you take the other patch too then we could sync; shouldn't be harmful on Debian but it's not entirely applicable there either
[18:07] <Laney> up to you
[18:07] <mitya57> Laney: I don't yet see the new upload, will look in a couple of minutes (and I can, yes)
[18:07] <Laney> it's not done yet, that's why ;-)
[18:07]  * Laney was test building
[18:08] <dobey> jtaylor: that's a special case though it sounds like. most code probably isn't like that? i mean, unless i can depend on packages from universe in the autopkgtests for a package in main?
[18:08] <cjwatson> You can
[18:08] <jtaylor> dobey: you can do that
[18:09] <jtaylor> dobey: you also test that the binary package is actually usable in adt tests
[18:09] <dobey> oh, then that might be nominally useful for me then
[18:09] <jtaylor> dobey: during the build you have everything installed as upstream intended and tests that, binary packages may make mistakes in splitting stuff up
[18:09] <Laney> mitya57: alright, there we go - perhaps wait and see if it passes in jenkins but feel free to upload at your leisure (or get tumbleweed to do it for you :P)
[18:09] <Laney> have to go out now - see you later
[18:09] <tumbleweed> what am I uploading?
[18:09] <jtaylor> dobey: e.g. gevent, their dbg package is broken, during the build you won't see that, but in adt tests you do (seen in pyzmq)
[18:09] <dobey> jtaylor: well, "works as intended" with ubuntuone is probably not all that testable in adt either though :)
[18:11] <dobey> most of the stuff we're already testing in the unit tests anyway, and not much more testing can really be done without actually talking to the server
[18:11] <jtaylor> another case is ipython which tests stuff only if a mongodb service is running, I can't do that during ab uild, but I can in adt
[18:11] <jtaylor> but I don'T because mongodb is broken in chroots ._.
[18:11] <mitya57> Laney: I'll look tomorrow then
[18:11] <dobey> but for some of the stuff where we use pyqt, we need a package that's in universe to run the tests, so we aren't running all the tests in the package build
[18:12] <mitya57> tumbleweed: Laney was suggesting to drop ubuntu pyxdg delta by committing it to DPMT
[18:12] <tumbleweed> ah
[18:13] <tumbleweed> mitya57: it's team maintained, that's a reasonable approach
[18:13] <dobey> is there any way to get autopkgtests to work for PPAs as well?
[18:28] <mitya57> dobey: https://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/view/head:/doc/USAGE.md#L54
[18:29] <dobey> mitya57: but there's no infrastructure already set up to do this automatically? i'd have to set up my own jenkins jobs somewhere doing that?
[18:30] <mitya57> dobey: that's a question to pitti or jibel
[18:32] <pitti> dobey: technically we can do it, it's just a resource issue
[18:32] <pitti> dobey: if you mail jibel and toss him a pointer to a PPA and some package names, he can set it up
[18:32] <pitti> dobey: we already do this for e. g. chrisccoulson's firefox PPA and seb128's gtk
[18:33] <chrisccoulson> we even get proper test results: https://jenkins.qa.ubuntu.com/job/raring-ppa-adt-ubuntu_mozilla_daily_ppa-firefox-trunk/69/#showFailuresLink :)
[18:34]  * chrisccoulson must fix the failures
[18:34] <jtaylor> :O
[18:34] <jtaylor> how do you get the test results into jenkins?
[18:34] <pitti> dobey: e. g. https://jenkins.qa.ubuntu.com/view/Raring/view/All/job/raring-ppa-adt-ubuntu_mozilla_daily_ppa-firefox-trunk/
[18:34] <dobey> pitti: it would be fine if i had to set it up on a separate jenkins as well (we already have jenkins set up for u1 stuff for testing on windows and landing branches and such, so not a big issue). just wanted to know what's what :)
[18:35] <dobey> chrisccoulson: jenkins gives you a stormy cloud
[18:36] <jtaylor> it would be nice when one could see the configurations of the jobs
[18:36] <chrisccoulson> dobey, ah, i wanted more than a stormy cloud and a 100MB text file though
[18:37] <dobey> heh
[18:37] <dobey> oh, that jenkins doesn't use sso
[19:04] <pitti> dobey: jenkins.q.u.c. is just a r/o mirror
[19:04] <pitti> dobey: the real one is behind a VPN in Lex, so you won't actually see execution nodes, login, etc.
[19:10] <dobey> ah right
[19:22] <lifeless> cr3: ping
[19:37] <dobey> still, it would be nice to be able to disable running the autopkgtests when their running would be the same as the tests run during the build, except for when any of the dependencies changed
[19:41] <cjwatson> my concern there would be that there would be no baseline for when they're rerun when deps change
[19:42] <cjwatson> it's quite possible for the autopkgtest setup files to be wrong even if the unit tests themselves pass
[19:48] <pitti> slangasek: do you have your systemd changes against 44-10 in some broken-out form like bzr commits, or do I just look at the debdiff?
[19:49] <dobey> i suppose that's true. i'm just looking to optimize out the bits where it would be unequivocally indifferent from running the tests in the builds, to avoid wasting resources
[19:50] <dobey> i guess it won't be too big an issue though
[19:53] <slangasek> pitti: umm I have them in a git tree here which I meant to push somewhere
[19:54] <slangasek> pitti: speaking of, what's the right way for me to submit my changes to systemd upstream for enabling a Debian backend on timedated?
[19:54] <pitti> slangasek: or just format-patch origin.. perhaps, then we can directly forward/apply them?
[19:55] <pitti> slangasek: that's a good question actually; back then I used the debian git, but that still has 44
[19:55] <pitti> I didn't find a git tree from which mbiebl built his version 195 packages
[19:55] <slangasek> pitti: I meant for forwarding to systemd upstream rather than Debian
[19:55] <pitti> oh
[19:55] <slangasek> well, the 195 packages also aren't published in Debian
[19:55] <pitti> slangasek: http://lists.freedesktop.org/mailman/listinfo/systemd-devel/
[19:56] <pitti> slangasek: most patches go there, and it's the fastest way to get them reviewed
[19:56] <pitti> slangasek: I'm on the list, so if someone acks patches I can push them, too
[19:56] <slangasek> pitti: great, thanks
[19:57] <pitti> slangasek: I guess Lennart is fine with me pushing Debianisms :)
[20:02] <pitti> good night everyone
[20:18] <ogra_> https://plus.google.com/hangouts/_/914b5784e52c5967784eae44e4b138a346b1ff90?authuser=0 post UDS beer hangout
[20:27] <chiluk> stgraber, in reference to http://pad.lv/1057358 .... sorry about that..I do have a question about it though.
[20:29] <mbiebl> pitti: http://people.debian.org/~biebl/systemd-198/
[20:29] <mbiebl> that's not a real git repo though, just some bits I'm currently experimenting with
[20:29] <mbiebl> which is sufficient to boot a systemd yet
[20:29] <chiluk> stgraber, the bazaar branch for precise available at lp:ubuntu/precise/isc-dhcp is stuck at 4.1.ESV-R4-0ubuntu5   Is there a newer place for the precise branch?
[20:30] <stgraber> chiluk: no, you need to pull the current source from LP outside of bzr branches
[20:30] <chiluk> I'd prefer not to use the patching system if I could instead just use a bazaar branch /
[20:30] <chiluk> stgraber where?
[20:30] <chiluk> I ended up using pull-lp-source for the latest debdiff I created.
[20:30] <stgraber> chiluk: pull-lp-source isc-dhcp precise-updates
[20:31] <stgraber> right, that's how you have to do it for SRU for isc-dhcp because the UDD branches are busted
[20:32] <chiluk> I'm still not sure where the logic is that blew away my patch...
[20:32] <chiluk> but moving the patch above the comment works...
[20:33] <chiluk> stgraber, anyhow sorry.. do I need to fill out another SRU in 1057358?
[20:34] <mdeslaur> chiluk: if happens at least twice to every person who touches the isc-dhcp package :P
[20:34] <mdeslaur> s/if/it/
[20:34] <chiluk> hah...
[20:35] <stgraber> chiluk: nope, we can use the same bug, just attach an updated patch to it
[20:35] <stgraber> mdeslaur: we finally fixed that with 12.10 though!!!
[20:35] <mdeslaur> stgraber: yes, thanks again :)
[20:35] <chiluk> I was going to just patch apparmor-profile.dhcpd , but I wanted to be fancy and use the darn patching system
[20:35] <stgraber> mdeslaur: though we also broke LDAP support in the process and didn't notice until a few weeks ago ;) I pushed an SRU last week that turns on LDAP support in the ldap packages
[20:35] <stgraber> mdeslaur: because the debian/rules magic dual-build stuff was completely broken and the ldap binary was overwritten by the standard binary
[20:35] <mdeslaur> stgraber: whoops :) although, meh, maybe it's an acceptable compromise :)
[20:36] <cr3> lifeless: pong, what's up?
[20:36] <chiluk> stgraber so you want a modified patch from 5.6 or a patch fixing 5.7?
[20:36] <stgraber> chiluk: from 5.6 would be easier to review
[20:36] <lifeless> cr3: subunit v2
[20:36] <lifeless> cr3: have you seen my blog posts ?
[20:36] <chiluk> alright.
[20:37] <cr3> lifeless: dude, what'a coincidence! I just got out of a meeting where I mentionned subunit and testmanager too!
[20:38] <cr3> lifeless: I haven't seen your blog posts, link? I'll forward to a few colleagues
[20:40] <lifeless> cr3: rbtcollins.wordpress.com
[20:41] <stgraber> chiluk: saw the new patch. Thanks, I'll try to review and bundle with other fixes when I have a sec.
[20:41] <chiluk> that's the fix against 5.7
[20:41] <cr3> lifeless: any estimate on when you expect v2 to be finalized?
[20:42] <chiluk> stgraber do you still want me to create a new debdiff against 5.6?
[20:43] <stgraber> chiluk: it's a simple enough patch that it doesn't really matter. 5.6 would be easier but 5.7 will just take me an extra minute or so
[20:43] <chiluk> stgraber thanks... I'm still new to how all the patching systems work in Ubuntu..
[20:44] <lifeless> cr3: soon I hope, the more feedback I get the better :)
[20:44] <lifeless> cr3: I'd love to be able to replace your custom protocol with v2 ;)
[20:46] <cr3> lifeless: I haven't touched checkbox in a while, zyga or roadmr should be made aware of this ^^^
[20:47] <lifeless> cr3: ah!
[20:48] <lifeless> cr3: well, care to point them at it, or mail me their contact details and I'll mail them a tl;dr summary?
[20:49] <cr3> lifeless: I was thinking of dropping them a quick email about it, I can cc you too
[20:49] <lifeless> please
[21:30] <zyga> lifeless: hey
[21:30] <lifeless> hi :)
[21:30] <zyga> lifeless: subunit you say? I read about your v2 work
[21:30] <lifeless> zyga: ah cool
[21:31] <lifeless> so yeah, I know checkbox has a reporting format, and I'd like to be sure that subunit v2 is at least an in-principle suitable candidate for you
[21:31] <zyga> lifeless: as for checkbox, we're not using it actively
[21:31] <zyga> lifeless: so we have a rewrite going on
[21:32] <zyga> lifeless: the core is mostly rewritten now
[21:32] <zyga> lifeless: we have a concept of exporters where all the test data can go to
[21:32] <zyga> lifeless: we have json, (now removed) yaml, rfc822 and custom certification xml outputs
[21:32] <zyga> lifeless: and a plain-text human readable output
[21:33] <zyga> lifeless: who would be a consumer for subunit exporter?
[21:33] <lifeless> zyga: your server ? Testrepository? Anything doing data mining?
[21:34] <zyga> we don't have a server, we only send data to certification rewrite that only eats the xml I've mentioned
[21:34] <zyga> I don't mind having that exporter but I don't know if it's applicable - the exporter is given a session state object that has all of the state, all the test that went by, all the output, all the user feedback, everything
[21:35] <zyga> then it has to produce some text to a stream
[21:35] <zyga> there's a sub-layer there that can select a subset of data
[21:35] <zyga> and we actually do that, also transforming from the objecet graph to something that can be easily json.dump()'ed
[21:35] <lifeless> well
[21:36] <zyga> which is also what most derivative exporters consume to be customizable
[21:36] <lifeless> so the idea of subunit is to avoid the buffering issues that e.g. xml has
[21:36] <lifeless> and support concurrent tests
[21:36] <zyga> we alredy buffer everything
[21:36] <zyga> we don't do any concurrent testing
[21:36]  * zyga sounds negative but I don't see how we could take advantage of that
[21:36] <lifeless> fair enough
[21:36] <zyga> we buffer and save to disk because jobs can crash machines (and do)
[21:37] <zyga> so we took a painful careful road to save stuff sanely
[21:37] <lifeless> right - thats what subunit is meant to tackle
[21:37] <zyga> so we have everything stored on disk anyway
[21:37] <lifeless> distributed lossy testing - just emit the events as they happen, direct onto the network.
[21:37] <zyga> lifeless: it would not store everything the way we need I suspect, our resume logic is not a serialization problem
[21:37] <lifeless> if the machine crashes you know it did because you only see the test start event not the finish
[21:37] <lifeless> ok
[21:38] <zyga> do you have docs docs on your v2 work?
[21:38] <zyga> (I only read the blog headline)
[21:38] <lifeless> I do, I will dig up in a bit, OTP just now.
[21:38] <zyga> k
[21:39] <zyga> lifeless: I'll look at them but frankly, it would probably require us to reachitect the core a little, to put subunit storage as the center of our state holiding
[21:39] <zyga> lifeless: and I don't think there's anything we gain, apart from a dependency and code sharing
[21:39] <zyga> lifeless: and correct me if I'm wrong but isn't subunit just equivalent to protocol buffers, json, yaml *records* being written somewhere?
[21:40] <lifeless> its the semantic rules that matter - the serialisation isn't interesting
[21:40] <lifeless> http://rbtcollins.wordpress.com/2013/02/14/time-to-revise-the-subunit-protocol/ is the first blog post
[21:41]  * zyga got a message from cr3 about subunit 2
[21:41] <zyga> lifeless: some parts of subunit seem like our io_log
[21:41] <lifeless> https://github.com/rbtcollins/testtools/blob/streamresult/doc/for-framework-folk.rst#extensions-to-testresult is framework author docs around the API you get
[21:41] <zyga> lifeless: which I fully agree we have a shit implementation of, but that's fine for now
[21:42] <zyga> lifeless: any chance for testtools.rtfd.org?
[21:42] <zyga> lifeless: works on kindle :) (and everything else)
[21:42] <zyga> ah
[21:42] <zyga> nice
[21:43] <zyga> reading
[21:43] <lifeless> http://bazaar.launchpad.net/~lifeless/subunit/streamresult/view/head:/README#L148 is the subunit *wire level* README
[21:43] <lifeless> parser/serialiser http://bazaar.launchpad.net/~lifeless/subunit/streamresult/view/head:/python/subunit/v2.py
[21:45] <zyga> lifeless: how are you using that?
[21:45] <bryce> hey, anyone know if there is an official preferred C++ lib for JSON parsing/writing for Qt/QML devel?
[21:45] <zyga> lifeless: I need to break for some real-life activities
[21:46] <zyga> lifeless: I'll look at that and ping you tomorrow
[21:46] <lifeless> zyga: ok, ping me whenever
[21:46] <zyga> lifeless: thanks
[21:46] <lifeless> Not sure what you mean by 'how are you using' - do you mean you want to see the CLI entry points for e.g. subunit.run or subunit-filter ?
[21:56] <RAOF> bryce: I'm somewhat surprised there's not one in Qt?
[22:02] <bryce> RAOF, there is qjson.  Would that be considered the official way to go?
[22:03] <bryce> there's a bunch of more general purpose options on C++, some of which seem pretty popular.  jansson, jsoncpp, rapidjson, et al.  Just wondering if we have a standard, or if I should just choose randomly.  :-)
[22:04] <RAOF> I'm not aware of a standard, but that's not terribly good evidence that there isn't one :)
[22:05] <bryce> hrm
[22:05] <dobey> RAOF, bryce: there's one in qt5, but it's a seprate lib with qt4. it's probably waht you want to use to do json in a c++ app using qt
[22:06] <dobey> i think a couple of the other people on online servers that are working on a qt/c++ thing are using it for the json parsing
[22:06] <bryce> alright, guess I'll play it by ear see what Qt does on its own with it
[23:18] <xnox> jdstrand: so slangasek passed a missed ping to me. Searching for consolekit it's nice to search for org.freedesktop.ConsoleKit as one needs to use this verbantim "well-known" name in the code.
[23:18] <xnox> regardless of which language is used to talk over dbus.
[23:19] <xnox> so this string is present in python / c / C++ / some config files etc.


[11:53] <utkarsh2102> hello! o/
[11:54] <utkarsh2102> could someone please re-trigger autopkgtest for pdepend with triger=phpunit&php-defaults; cf: https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=arm64&package=pdepend&trigger=php-defaults/80~exp1&trigger=phpunit/9.5.4-1&trigger=pdepend/2.9.1-1
[11:59] <slyon> utkarsh2102: done
[12:03] <utkarsh2102> sylon: thank you!
[12:04] <utkarsh2102> slyon: thank you! (apologies for the typo earlier)
[12:04] <slyon> o/
[12:06] <utkarsh2102> woot! passed now
[12:07] <utkarsh2102> for armhf also, please: https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=armhf&package=pdepend&trigger=php-defaults/80~exp1&trigger=phpunit/9.5.4-1&trigger=pdepend/2.9.1-1
[12:07] <utkarsh2102> and for ppc64el: https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=ppc64el&package=pdepend&trigger=php-defaults/80~exp1&trigger=phpunit/9.5.4-1&trigger=pdepend/2.9.1-1
[12:08] <slyon> nice! done and done
[12:08] <utkarsh2102> and s390x, finally: https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=s390x&package=pdepend&trigger=php-defaults/80~exp1&trigger=phpunit/9.5.4-1&trigger=pdepend/2.9.1-1
[12:08] <utkarsh2102> thank you, slyon! \o/
[12:08] <slyon> done!
[12:08] <utkarsh2102> lovely, thank you!
[12:09] <slyon> yw
[15:15] <paride> sil2100, hi!
[15:16] <paride> sil2100, python3-flake8 in focal-proposed is broken (uninstallable) and preventing packages build-depending on it from building
[15:17] <paride> it has been stuck in proposed for almost 300 days now
[15:17] <paride> related bug: https://bugs.launchpad.net/ubuntu/+source/python-flake8/+bug/1883175
[15:17] <ubot3> Launchpad bug 1883175 in python-flake8 (Ubuntu Focal) "Missing code linter support for python3.8 language features" [Low, Fix Committed]
[15:17] <paride> do you think it can be just pulled from focal-proposed at this point?
[15:23] <sil2100> paride: can you mark it as verification-failed-focal ?
[15:23] <sil2100> It will then be considered for removal and I can remove it
[15:23] <paride> sil2100, done
[18:57] <GunnarHj> Hi sarnold, Wondering if I can consider the apparmor part of bug #1928360 assigned to you. Also, do you think it is as easy as (almost) copying the fcitx 4 abstractions, or is there more into it?
[18:58] <ubot3> Bug 1928360 in Ubuntu Kylin "Switch to Fcitx 5 for Chinese" [Undecided, In Progress] https://launchpad.net/bugs/1928360
[19:01] <sarnold> GunnarHj: I don't know nearly enough about what's going on there to take ownership of it at this point :(
[19:04] <GunnarHj> sarnold: Then who does? I don't know enough about apparmor and snaps to play around on my own.
[19:06] <sarnold> GunnarHj: maybe it's time to engage the snappy team?
[19:07] <GunnarHj> sarnold: That may be an option, yes. It's often unclear to me who is responsible for what when it comes to these things. ;)
[19:08] <sarnold> GunnarHj: tell me about it :(
[19:09] <GunnarHj> haha
[19:09] <sarnold> GunnarHj: jamie would have been perfect for this, he was really good at most of these, and only fcitx would have been new to him, but alas he's found greener pastures
[19:10] <GunnarHj> sarnold: Right, I see he did most of the input method related apparmor work in the past.
[19:24] <GunnarHj> sarnold: Your mentioning of Jamie's absence makes me think about another loose input method related end. Thinking about bug #1890905. Is that something for the apparmor team?
[19:24] <ubot3> Bug 1890905 in snapd (Ubuntu) "Snaps cannot access IBus when $XDG_CACHE_HOME is set" [Medium, Confirmed] https://launchpad.net/bugs/1890905
[19:25] <sarnold> GunnarHj: no, that'll be snap
[19:29] <GunnarHj> sarnold: Are you sure? After all but #1423890 seems to very closely related.
[19:29] <GunnarHj> bug #1423890
[19:29] <ubot3> Bug 1423890 in apparmor (Ubuntu) "AppArmor support for the XDG Base Directory spec is incomplete" [Wishlist, New] https://launchpad.net/bugs/1423890
[20:34] <sarnold> GunnarHj: I don't think snap would just magically get ibus access or other xdg stuff correct if apparmor had a better XDG story; it probably would help with a clean implementation, but actually addressing 1890905 would require time investment from snap folks
[21:14] <GunnarHj> sarnold: Ok, thanks, I know too little to argue. Will try to call the snap devs' attention to these issues.
[21:15] <sarnold> GunnarHj: it's less 'argue' and more 'there's no way the apparmor team has time for this'..
[21:15] <GunnarHj> sarnold: I see. :(


[18:48] <vlt> Hello. How can I use the Salamander piano samples on Ubuntustudio? Is linuxsampler available on 14.10?
[18:49] <holstein> vlt: AFAIK, its not in the repos
[18:51] <holstein> vlt: should be able to find a PPA, or just build it according to the creators specs
[18:52] <holstein> http://wootangent.net/tag/linuxsampler/ is a friend that uses ubuntu and linux sampler
[18:52] <holstein> he's [lsd] in #opensourcemusicians
[18:53] <vlt> holstein: Thank you!
[18:54] <vlt> Wasn't there a decent studio distro also with linuxsampler? kxstudio maybe?
[18:55] <holstein> vlt: "decent" will always be a matter of opinion, and what is allowed to be included in the repos is not a reflection of quality in any way
[18:55] <holstein> vlt: ubuntu/ubuntustudio/linux is not prevening linuxsampler from running on it
[18:55] <holstein> vlt: i believe it was removed and not able to be included due to licensing..
[18:56] <holstein> vlt: if you would like it to be included, let the creators know that, and the community welcomes it
[18:56] <vlt> Aah ... ok!
[18:56] <holstein> vlt: otherwise, kxstudio ppa's are among the sources i reference that provide that tool
[21:11] <jamie_> hey I was wanting to switch over to ubuntu studio, I am currently using ubuntu 14.10 and have quite a bit of work saved on here and i am trying not to loose everything
[21:21] <holstein> jamie_: sure.. dont
[21:22] <holstein> jamie_: ubuntustudio *is* ubuntu
[21:22] <holstein> jamie_: just install what you want/need from the ubuntustudio software into your current installation. but, i also suggest you plan for *when* you lose that installation due to hardware failure, and backup properly
[21:22] <holstein> otherwise, you can use the ubuntustudio live iso to learn what you would like to be using from ubuntustuduio
[21:28] <jamie_> holstein: thanks. I know about the back up stuff... I work for mozilla
[21:29] <holstein> sure, and im just addressing the "i have a lot of work on there and im trying not to loose everything", since, you will, and it will have nothing to do with this issue
[21:29] <jamie_> and is the insatall and apt-get, the repository, and the graphics drives
[21:29] <jamie_> the same
[21:29] <holstein> jamie_: there is no "repository".. ubuntustudio *is* ubuntu
[21:30] <jamie_> okay thanks
[21:30] <jamie_> holstein: sorry for the annoyance... kinda multi tasking right now, sorry
[21:30] <holstein> jamie_: *all* the software is in the main repos for ubuntu.. so, you can open the package manager of your choice, and search "ubuntustudio".. synaptic is a nice GUI one
[21:31] <holstein> but, i suggest *not* doing that, since, that can change the desktop, and UI.. and you dont need to do that to use the applications
[21:31] <holstein> if you are not planning on doing audio production, and using JACK audio, i argue, you dont need most (like 90%) of what ubuntustudio provides
[21:31] <jamie_> holstein: I do
[21:31] <holstein> you would be more comfortable adding, for example, just audacity, etc
[21:32] <holstein> jamie_: sure, and even if you *are* interested in using JACK, you dont necessarily need to change your UI do do that
[21:32] <holstein> but, you are welcome to
[21:32] <holstein> i suggest, just try the live iso, and see what is there, and what you need
[21:32] <jamie_> i know i like the ui quite a bit, it seems more flowing
[21:32] <holstein> jamie_: its xfce/xubuntu basically
[21:32] <jamie_> yea... forgot i could have answered my own questions with virtual box
[21:33] <holstein> jamie_: thats a good idea, as well
[21:33] <holstein> just to see what is happening and what you want/need
[21:33] <jamie_> i just needed to make sure i can put firefox web developer edition for work
[21:33] <holstein> jamie_: its ubuntu.. nothing about ubuntu will prevent that
[21:35] <jamie_> that is what i was making sure.. i know that i have had problems with lubuntu in the past not having the right parts that i need, were removed to make it light weight and had to add the sources to the software manager
[21:35] <holstein> jamie_: sure, but with lubuntu, its the same.. the "parts" are all in the repos..
[21:35] <holstein> jamie_: you dont need to add the "sources" though.. the sources are the main ubuntu sources
[21:36] <holstein> jamie_: if the tools you need are not in the repos, then, they will not be in main ubuntu..
[21:36] <jamie_> and just on a whim.... lol you kinda just really down played ubuntu studio.... thought it was kinda funny.... arnt people here supposed to promote it
[21:36] <holstein> jamie_: i use it all the time
[21:36] <holstein> jamie_: what i want to address is, its not "magic".. and, if you have a running setup, you have no need to "change" or "break" it to use the tools here
[21:37] <holstein> if you are using ubuntu 14.10, and like it, and just want to use audio production, you dont need to change OS"s
[21:37] <jamie_> well thank you i need to go
[21:37] <holstein> if you want, you are welcome to, but its just not factually necessary.. and i think its a mis-step
[21:37] <holstein> it think, changing too much might be a way to cause an issue
[21:37] <holstein> uncessarily, as well
[21:37] <holstein> ubuntustudio is *great*, and free to try :)
[21:38] <holstein> but, you can add *all* of what we have in it to stock 14.10 or any of the other flavors
[21:38] <holstein> and, with no PPA's
[21:38] <holstein> the official sources contain *everything* that makes up the official flavors