[02:01] <smoser> nturner, maas provides the install environment with config for curtin.
[02:02] <smoser> the cloud-config-url on the cmdline is actually for the installer environment
[02:02] <smoser> the urls are slightly different beteween installer environment and installed environment
[02:02] <smoser> the installer environment's user-data is the installer
[02:02] <smoser> the installed environment is configured via config to curtin.
[02:02] <smoser> i think its done via dpkg set selections
[02:03] <smoser> nturner, i'd have to look around more, and what i'd do is https://gist.github.com/smoser/2610e9b78b8d7b54319675d9e3986a1b
[02:03] <smoser> do a deploy, jump in and poke around
[02:03] <smoser> likely the data you're after is in /curtin/config some where.
[06:33] <mup> Bug #1597625 opened: package maas-rack-controller (not installed) failed to install/upgrade: subprocess new pre-installation script returned error exit status 1 <amd64> <apport-package> <xenial> <maas (Ubuntu):New> <https://launchpad.net/bugs/1597625>
[11:12] <mgz> hey guys
[11:12] <mgz> where is the source for the user docs kept?
[11:13] <mgz> eg http://maas.ubuntu.com/docs2.0/install.html
[11:32] <mgz> lp:maas docs/ directory, for irc record
[12:49] <f1gjam> anyone in London got MaaS, Autopilot, Landscape and Openstack running?
[13:34] <geese> question:  Do you absolutely need IPMI/BMC for MaaS to operate?  Or can it gracefully degrade for "plain" systems?
[13:34] <geese> I've got 6 servers, and 2 of them have IPMI
[13:35] <geese> second question: can I provide netboot nbi for mac systems to launch and install linux?  a la: http://www.fink.org/netboot/netbooting.html
[13:35] <geese> I have about 8 2012 mac minis
[13:36] <geese> they're running ESXi now, but I want to build a lab openstack on them
[13:36] <geese> thanks!
[14:32] <mup> Bug #1597779 opened: Wily Deployements are failing in Maas <MAAS:New> <https://launchpad.net/bugs/1597779>
[14:35] <mup> Bug #1597779 changed: Wily Deployements are failing in Maas <MAAS:New> <https://launchpad.net/bugs/1597779>
[14:44] <mup> Bug #1597779 opened: Wily Deployements are failing in Maas <MAAS:New> <https://launchpad.net/bugs/1597779>
[14:44] <mup> Bug #1597787 opened: cannot create more than 4 partitions when disk is configured with dos DiskLabel <MAAS:New> <https://launchpad.net/bugs/1597787>
[14:53] <mup> Bug #1597787 changed: cannot create more than 4 partitions when disk is configured with dos DiskLabel <MAAS:New> <https://launchpad.net/bugs/1597787>
[15:02] <mup> Bug #1597787 opened: cannot create more than 4 partitions when disk is configured with dos DiskLabel <MAAS:New> <https://launchpad.net/bugs/1597787>
[15:26] <mup> Bug #1597779 changed: Wily Deployements are failing in Maas <cloud-init:New> <MAAS:Invalid> <https://launchpad.net/bugs/1597779>
[15:26] <mup> Bug #1597801 opened: cannot create node VLAN interfaces on centos <MAAS:New> <https://launchpad.net/bugs/1597801>
[17:57] <f1gjam> anyone in London got MaaS, Autopilot, Landscape and Openstack running?
[18:57] <f1gjam> mpontillo, kiko - I am about to quit my endeavour to get autopilot running. It just seems to buggy
[19:00] <mpontillo> f1gjam: sorry to hear that; if you can describe the issue I'll see if I can find someone to help
[19:00] <f1gjam> its landscape, it wont install now. I have completely started from scratch, because before landscape would just hang installing openstack at 80% or so
[19:01] <f1gjam> now doing openstack-install
[19:01] <f1gjam> it just crashes
[19:01] <f1gjam> the install just times out
[19:01] <f1gjam> the funny thing is i had it installed
[19:01] <mpontillo> f1gjam: anything in the logs?
[19:02] <f1gjam> only that it is timing out
[19:02] <f1gjam> http://paste.ubuntu.com/18188970/
[19:04] <roaksoax_> dpb1_: ^^
[19:09] <f1gjam> mpontillo, im gona try mirantis for a bit then come back to MaaS maybe after 2.0 comes out??
[19:09] <f1gjam> thanks for all your help, i do want to complete my doc, just need to get end to end working 100%
[19:11] <mpontillo> f1gjam: should be pretty soon. As for MAAS 2.0, I know the landscape team is now testing with it. Not sure what their timeline is. Thanks for trying MAAS and for all your feedback.
[19:12] <f1gjam> il be back in a week most likely
[19:12] <f1gjam> i was thinking of just going to eh office ;)
[19:13] <f1gjam> and saying hey anyone here got MaaS working :D
[19:13] <mpontillo> f1gjam: lol, hold up a sign
[19:13] <f1gjam> yeah
[19:13] <f1gjam> one man protest
[19:19] <dpb1_> hey f1gjam do you have a juju status from that attempt?
[19:19] <f1gjam> erm
[19:19] <f1gjam> i chan check
[19:20] <dpb1_> export JUJU_HOME=~/.cloud-install/juju
[19:20] <dpb1_> juju status
[19:21] <f1gjam> its doing something
[19:22] <f1gjam> just hanging
[19:24] <f1gjam> dpb1_, just haning
[19:24] <dpb1_> is the bootstrap node still 'deployed' in maas?
[19:39] <f1gjam> no
[19:39] <f1gjam> i released it
[19:39] <f1gjam> let me kick the install off again
[19:45] <mup> Bug #1597266 changed: MAAS - multiple DNS zones with the same duplicated zone name <cpec> <maas> <MAAS:New> <https://launchpad.net/bugs/1597266>
[19:48] <mup> Bug #1597266 opened: MAAS - multiple DNS zones with the same duplicated zone name <cpec> <maas> <MAAS:New> <https://launchpad.net/bugs/1597266>
[19:51] <mup> Bug #1597266 changed: MAAS - multiple DNS zones with the same duplicated zone name <cpec> <maas> <MAAS:New> <https://launchpad.net/bugs/1597266>
[20:01] <ahasenack> f1gjam: another good test is to just do a juju bootstrap on that maas, that is, configure a juju env that points at the maas server
[20:01] <ahasenack> f1gjam: and bypass landscape and cloud installer for now
[20:08] <pacavaca_> hey guys. I'll just repeat my yesterdays question, maybe there's someone around to answer it this time. How hard it is to "fork" MAAS, make few small changes to the REST API (and maybe in UI) and then build custom deb packages, maybe a private PPA (if such thing even exist)? My chnges are really small, but you probably will not want them in upstream. However, they're very important for the internal use
[20:08] <pacavaca_> case where I'm trying to apply MAAS..
[20:13] <f1gjam> ahasenack, yeha i was thining baout that, thats how the 2.0 install woudl be right?
[20:13] <f1gjam> whats the vallue of landscape im guessing
[20:14] <ahasenack> f1gjam: you can bypass the cloud-installer if all you want is landscape, it just saves you a few easy configuration steps in landscape
[20:14] <f1gjam> i want openstack isntalled
[20:14] <f1gjam> the one that is supported for up to 10 machines
[20:15] <ahasenack> f1gjam: I suggest to start with the plain juju + maas combination, see if you can bootstrap a node
[20:15] <ahasenack> and maybe even do a simple "juju deploy ubuntu", then access it ("juju ssh ubuntu/0")
[20:15] <f1gjam> i can defintely bootstrap a ndoe
[20:15] <ahasenack> because we need all that working to proceed
[20:15] <f1gjam> and i definitely had landscape installed
[20:15] <ahasenack> also see if the node can reach the internet
[20:15] <f1gjam> where it hung for me was
[20:15] <ahasenack> ok, that's good
[20:15] <f1gjam> during the openstack setup in landscape it got stuck
[20:15] <f1gjam> i still have those original logs
[20:16] <ahasenack> f1gjam: did you happen to click "cancel" and download logs, or file a bug?
[20:16] <f1gjam> i downloaded
[20:16] <f1gjam> didnt raise a bug as i didnt know what to raise a bug for
[20:17] <ahasenack> f1gjam: file a bug here: https://bugs.launchpad.net/landscape/+filebug
[20:17] <ahasenack> and attach the tarball you have
[20:17] <f1gjam> https://www.dropbox.com/s/w1ftoof4a58lvba/landscape-openstack-autopilot-logs-2016-06-29T00-03-09Z.tar.gz?dl=0
[20:17] <ahasenack> f1gjam: you can try openstack install again from scratch if you want, and if you hit the landscape timeout error again, please leave the environment up and we can check what happened
[20:18] <f1gjam> oik
[20:18] <f1gjam> im doing that now
[20:18] <f1gjam> its deploying landscape as we speak (via autopilot)
[20:18] <f1gjam> so another 5/10 mins max
[20:18] <ahasenack> hm, no, let's fix the terminology
[20:19] <ahasenack> autopilot is a landscape component, and is what deploys openstack
[20:19] <f1gjam> oh
[20:19] <ahasenack> landscape has autopilot and many other things
[20:20] <ahasenack> so you are deploying landscape via openstack-install, if I understood you
[20:20] <f1gjam> yes thats correct
[20:20] <f1gjam> that was failing
[20:20] <ahasenack> landscape being one of the options from within openstack-install
[20:20] <f1gjam> and now ....
[20:20] <f1gjam> i havent changed anything... lets see if it installs
[20:20] <f1gjam> as I did this before and it worked....
[20:20] <f1gjam> the only thing i did was release all servers and start again
[20:20] <ahasenack> in another terminal, can you export JUJU_HOME again and show me a "juju status --format=tabular"?
[20:20] <f1gjam> so if this works, there is a bug somewhere which causes it to randomly fail
[20:21] <f1gjam> http://paste.ubuntu.com/18193535/
[20:23] <f1gjam> https://bugs.launchpad.net/landscape/+bug/1597907
[20:23] <ahasenack> thx
[20:23] <ahasenack> f1gjam: can you check /var/log/syslog on the maas server, see if there are errors or messages about running out of dhcp leases?/
[20:24] <f1gjam> ahasenack, here is the doc which i started creating about the whole install... as you can see Landscape was installed. https://www.dropbox.com/s/fxs3voyjgtkrei4/Ubuntu_14.04_Install_Docuement.pdf?dl=0
[20:25] <dpb1_> pacavaca_: I'd suggest you just try it. :)
[20:25] <f1gjam> ahasenack, no errors
[20:25] <f1gjam> i have like over 50 IP address leases availble
[20:25] <f1gjam> only error
[20:25] <f1gjam> Jun 30 21:10:11 maas dhcpd: Can't create new lease file: Permission denied
[20:25] <ahasenack> f1gjam: how is your ip separation in the maas cluster interface? In terms of dynamic and static ranges
[20:26] <ahasenack> ok, that error is "normal"
[20:26] <f1gjam> <IP_ADDRESS> - Public
[20:26] <f1gjam> <IP_ADDRESS>/24 private
[20:26] <f1gjam> DHCP - 192.168.101-150 Dynamic
[20:26] <f1gjam> <IP_ADDRESS>-100 Static
[20:26] <f1gjam> brb
[20:26] <f1gjam> i need 10 mins
[20:32] <mpontillo> pacavaca_: I'm curious what your changes are; do you have a diff? if there is something missing from MAAS that is very important for someone to deploy it, I'd like to better understand what that is
[20:34] <mpontillo> pacavaca_: I've pushed MAAS builds to a personal PPA before, but I don't have instructions handy. I'll try to remember to ping you if that changes
[20:36] <mpontillo> pacavaca_: we have separate branches for packaging that you'd want to pull... this is the packaging branch for trunk; there are others used for various MAAS releases. https://code.launchpad.net/~maas-maintainers/maas/packaging
[20:39] <pacavaca_> mpontillo: So, basically we want to be able to release/acquire machines without re-imaging in between (most of the times). I found in code that it's pretty much enough to copy power_on action in API, rename it to, say boot_local, and before powering node on call set_netboot(False).
[20:40] <pacavaca_> mpontillo: I'm trying to run build locally, is it supposed to generate .deb packages at the end or they're somehow built on launchpad side? (I'm completely unfamiliar with launchpad and ubuntu hacking..)
[20:41] <mpontillo> pacavaca_: as I understand it (though packaging is not my forte) you upload the source and signed .dsc and launchpad builds the package for you
[20:41] <mpontillo> pacavaca_: I think the last time I did it, I followed this guide. http://askubuntu.com/questions/71510/how-do-i-create-a-ppa
[20:42] <mpontillo> pacavaca_: if you could post your code as a merge proposal, I'd like to get an understanding of the use case and if we could one day support something like that in MAAS
[20:43] <pacavaca_> mpontillo: thank you, will read through it. Sure, let me just first write the change :) The use case I can explain though. It's not exactly what MAAS is designed for, but in my opinion, maas fits there quite well.
[20:44] <mpontillo> pacavaca_: can you tell me more about why you need that type of release/acquire cycle? keep in mind that releasing a node has other side effects, like resetting the storage configuration
[20:48] <ahasenack> f1gjam: I'm reading your doc, I think you need a bigger dynamic range in dhcp
[20:48] <ahasenack> it's used by containers, and we deploy a lot of them
[20:49] <ahasenack> I would suggest 10-149 for dynamic, 150-250 for static
[20:49] <ahasenack> dynamic is also used when enlisting and commissioning nodes
[20:49] <pacavaca_> Basically, we have lot's of dev hardware available for different team to test their code. Right now the team is not so big and everything is managed manually (in chat, in google docs, everywhere). What I'm proposing is sort of a self-service portal, where each developer can come and claim any number of nodes with given capabilities. We also want those nodes to be imaged with our custom image (ubuntu 12.04
[20:49] <pacavaca_> + lots of packages pre-installed + our toolchain). The image is 3.7 Gb large and it's quite painful to install it every time node changes hands, though sometimes people screw up the OS and that's when we really want to re-image. Most of the time they're ok re-using the node after someone else. In fact, that's what everybody does right now and re-imaging is only done in emergency cases through clonezilla.
[20:49] <pacavaca_> In addition, I think if we would have a centralized pool of hw, we can easily re-purpose some dev nodes for other infra needs by installing pre-canned images there (e.g. we need one more LXD host - ok, take one node and flash LXD host image there).
[20:49] <pacavaca_> that's to mpontillo:
[20:49] <dpb1_> ahasenack: http://www.ubuntu.com/download/cloud/install-openstack-with-autopilot <- step 4 now lists the minimum amounts
[20:50] <ahasenack> thx dpb1_
[20:50] <ahasenack> f1gjam: ^
[20:51] <mpontillo> pacavaca_: ah, interesting - yeah, MAAS is really optimized for small images so that's understandable
[20:54] <mpontillo> pacavaca_: would it be sufficient to be able to simply change the owner of a node?
[20:54] <pacavaca_> mpontillo: I discovered MAAS couple month ago and "sold" to the team. Now I've already spent quite a lot of time trying to POC maas (and not only maas) solutions and none of them 100% finished. MAAS seems closest to the finish, but this small thing is really a show stopper. No one will use it if they need to wait 30 min+ before getting their nodes. So, that why I thought maybe it's just easier to add
[20:54] <mpontillo> pacavaca_: like, request ownership transfer from another user, or similar?
[20:54] <pacavaca_> missing functionality. It doesn't look too big of a change, but maybe I'm missing something.
[20:54] <pacavaca_> mpontillo: yeah, that would be good too
[20:54] <pacavaca_> maybe even easier than rebooting the node, etc
[20:55] <mpontillo> pacavaca_: right now I don't think MAAS allows you to see nodes someone else has acquired. but I wonder if the API could be used to update the owner
[20:56] <mpontillo> pacavaca_: I guess you would have to reboot it at least once (or kick cloud-init somehow) to grab the new SSH keys
[20:56] <pacavaca_> mpontillo: I haven't seen such an option, but I can re-check. SSH keys are easy in our case: we all use the same key :)
[20:59] <f1gjam> ahasenack, dpb1_ thanks for the info, ill adjust now. BTW the install failed, so i am guessing it is because the IP. Although the longs dont make that clear
[20:59] <f1gjam> do you want to see the logs?
[20:59] <ahasenack> f1gjam: the landscape install should work, it doesn't consume many ips
[20:59] <ahasenack> f1gjam: what does juju status --format=tabular have to say now?
[21:00] <f1gjam> http://paste.ubuntu.com/18195325/
[21:00] <mpontillo> pacavaca_: which version of MAAS are you using?
[21:00] <ahasenack> f1gjam: and juju debug-log, is it still printing out messages?
[21:01] <ahasenack> (you can abort with ctrl-c)
[21:01] <ahasenack> it's like tail -f <log>
[21:01] <f1gjam> yes its till printing messages
[21:01] <f1gjam> http://paste.ubuntu.com/18195389/
[21:02] <pacavaca_> mpontillo: 2.0b8 Just found "maas admin machine set-owner-data". This is probably what you're talking about. But I also realized, that people, who're done using the node should release it, otherwise how would others know which nodes they can acquire?
[21:02] <pacavaca_> and releasing will automatically power it off and then boot from pxe next time
[21:03] <ahasenack> f1gjam: hm, those are bad
[21:04] <ahasenack> f1gjam: can you "juju ssh 0 ps fauxw" and print the output?
[21:04] <ahasenack> paste, I mean
[21:04] <f1gjam> http://paste.ubuntu.com/18195527/
[21:05] <mpontillo> pacavaca_: set-owner-data allows you to add arbitrary key/value pairs to a node, to make notes about it and such
[21:08] <f1gjam> ahasenack, should i start from scratch
[21:08] <f1gjam> release all nodes
[21:08] <f1gjam> re-commission
[21:08] <ahasenack> f1gjam: yeah, and try something simple
[21:08] <ahasenack> f1gjam: juju bootstrap
[21:08] <ahasenack> f1gjam: then juju deploy ubuntu --to lxc:0
[21:08] <ahasenack> f1gjam: that will test bootstrap (which worked so far) and deploying a container on the bootstrap node
[21:09] <ahasenack> which is what we need working to begin with
[21:09] <f1gjam> but release the nodes first?
[21:09] <ahasenack> yes
[21:09] <ahasenack> you will have to configure juju to point at your maas server, have you done that before?
[21:09] <f1gjam> nope
[21:09] <ahasenack> and unset JUJU_HOME, that was just for openstack-install
[21:10] <ahasenack> f1gjam: https://jujucharms.com/docs/stable/config-maas
[21:10] <ahasenack> all you really need is an environments.yaml file with the maas env, those instructions will get you one with a ton of environments
[21:11] <f1gjam> ok node released
[21:11] <f1gjam> udpted dhcp
[21:12] <ahasenack> f1gjam: http://pastebin.ubuntu.com/18195888/ is a minimal file, put it in ~/.juju/environments.yaml
 is the ip of your maas server, and the oauth string you can get by logging in to maas and clicking on your name in the top right
[21:12] <ahasenack> it's a string with two :
[21:12] <ahasenack> like: text:text:text
[21:13] <ahasenack> f1gjam: then do juju env -l, to list (should show maas only), juju env (to confirm it's maas)
[21:13] <ahasenack> and then try "juju bootstrap", it should pick a node and start installing
[21:13] <ahasenack> f1gjam: what version of ubuntu are you on, btw? The machine where you ran cloud-installer, and where maas sits
[21:13] <ahasenack> trusty or xenial?
[21:14] <f1gjam> trusty
[21:14] <f1gjam> ok file created
[21:14] <f1gjam> ERROR the name of the environment must be specified
[21:16] <ahasenack> for bootstrap?
[21:17] <f1gjam> yes
[21:17] <ahasenack> did you unset JUJU_HOME?
[21:17] <f1gjam> no
[21:17] <f1gjam> let me do that
[21:17] <ahasenack> do that, or else it will be pointing at the other one created by openstack-install
[21:17] <ahasenack> the default is ~/.juju
[21:18] <f1gjam> done
[21:18] <ahasenack> so if you set JUJU_HOME to something else, that's where it will look
[21:18] <f1gjam> its doing something
[21:18] <ahasenack> ok, what does juju env -l show?
[21:18] <ahasenack> oh, or just go ahead :)
[21:18] <f1gjam> is this basically the CLI install
[21:18] <ahasenack> no
[21:18] <ahasenack> this is the underlying tech that the openstack-install and ladnscape/autopilot use
[21:19] <ahasenack> it's just easier to debug certain issues if we isolate them like this
[21:19] <f1gjam> i see
[21:19] <ahasenack> did it allocate a maas node?
[21:19] <f1gjam> everytime i hit a bug
[21:19] <f1gjam> i re-started from scratch
[21:19] <ahasenack> this will be stuck for a bit, some minutes
[21:19] <f1gjam> included maas rebuild
[21:19] <f1gjam> that way the doc is tested
[21:19] <ahasenack> but you can watch progress in the maas server
[21:20] <f1gjam> how can you watch
[21:20] <f1gjam> on maaS
[21:20] <ahasenack> go to the node listing
[21:20] <f1gjam> i just says deploying
[21:20] <ahasenack> right
[21:20] <ahasenack> so click on that
[21:20] <ahasenack> there is an event log or something down the page
[21:20] <f1gjam> ok
[21:20] <f1gjam> ok its going throught pxe cycle
[21:20] <f1gjam> 3 network cards
[21:21] <f1gjam> so takes a bit just to get past that
[21:21] <f1gjam> let me remote console on to the machine
[21:21] <ahasenack> I think if you click on "view history" you will get more details, and live refresh
[21:21] <mpontillo> pacavaca_: here's a hack that lets you change the owner. https://paste.ubuntu.com/18196246/
[21:21] <f1gjam> yeah i noticed that
[21:21] <f1gjam> i put in a feature
[21:21] <f1gjam> request
[21:21] <f1gjam> for console view in MaaS
[21:21] <f1gjam> :)
[21:21] <ahasenack> f1gjam: I have to go now, it's 6:21pm here
[21:21] <ahasenack> :)
[21:21] <f1gjam> where are you
[21:21] <mpontillo> pacavaca_: you would change it by doing something like "maas admin machine update 4y3hab owner=user2"
[21:22] <ahasenack> f1gjam: br
[21:22] <f1gjam> br?
[21:22] <ahasenack> f1gjam: yep, Brazil
[21:22] <f1gjam> oh wow
[21:22] <f1gjam> ok mate
[21:22] <f1gjam> thanks for your help
[21:22] <f1gjam> ill be here till around 1/2am UK time
[21:22] <ahasenack> f1gjam: after bootstrap, if that worked, to the "juju deploy ubuntu --to lxc:0"
[21:22] <f1gjam> ill keep positng
[21:22] <f1gjam> ok
[21:22] <f1gjam> but if that works
[21:22] <ahasenack> f1gjam: and after bootstrap is done, you can start doing "juju status --format=tabular" to check on things
[21:22] <f1gjam> ill start from scrath again
[21:22] <pacavaca_> mpontillo: thank you!
[21:23] <ahasenack> and juju ssh ubuntu/0, juju ssh 0, that kind of thing
[21:23] <ahasenack> f1gjam: interesting logs to look at are /var/log/juju/all-machines.log on the bootstrap node, and other logs in /var/log/juju
[21:23] <ahasenack> f1gjam: a good deploy will end with this ubuntu/0 service "started" in juju status and juju debug-log mostly silent
[21:23] <ahasenack> good luck, cya around
[21:24] <mpontillo> pacavaca_: let me know if that works for you, if so it might be an easy change for MAAS 2.1. will need to discuss with the team though
[21:24] <f1gjam> c ya
[21:32] <pacavaca_> mpontillo: I'll take a closer look once I have the buildout build passing locally. But as I said, I think nodes still will need to go through "Release" step, otherwise there's no way for people who want a node to know which nodes are free.
[21:34] <pacavaca_> However I have another idea in mind: what if release will not set netboot to True by default, but it will be done by "Deploy" instead, right before deployment. This way power-on will simply power the node on, which seems like a more intuitively expected thing for it to do.
[21:36] <mpontillo> pacavaca_: Hm. Or maybe a "null deployment" option, which would go through the motions but not actually touch the disks.
[21:38] <mpontillo> pacavaca_: you're right that this is a fairly specialized use case; we designed for MAAS having no idea what is currently on the disk of that node; MAAS assumes it could have been anything!
[21:38] <pacavaca_> pacavaca_: yeah, something like this. "null deployment" seems more like "just booting" :)
[21:38] <pacavaca_> mpontillo: Yeah, I understand that. But what maas does covers 90% of our use case, so that's why I'm trying to cover the other 10
[21:38] <mpontillo> pacavaca_: well, in addition you'd see the node change status to "Deployed" rather than just staying in Allocated
[21:40] <mpontillo> pacavaca_: in any case, patches to MAAS are welcome if you can generalize them enough. I think the "ownership transfer" idea is safest because then it's explicitly a user giving another user a node, and the original user knows exactly what was on it. when a node is released, as I said, MAAS's assumption is that we don't know what's on the disks and they need
[21:40] <mpontillo> to be reformatted
[21:41] <pacavaca_> mpontillo: actually, simply powering it on and then booting from disk (tried that yesterday by hacking code in python package directly), that changes state to Deploying. Then it times out though, but I suspect that's because it waits for something before cloud-init to happen and of course it never happens.
[21:41] <mpontillo> pacavaca_: your point about the user not knowing a node is free is a good one though. it's almost a "half deployed" state. except that when I get a test machine I normally want a clean slate =)
[21:41] <pacavaca_> mpontillo: yeah, sure. I'll first try to solve the specific use case and then, if I can generalize it, I'll submit a patch, no doubts
[21:42] <mpontillo> pacavaca_: great, thanks!
[21:45] <pacavaca_> mpontillo: What is the "recommisioning" concept exactly? Isn't it "ensuring that node is in a clean state faster than by re-imaging"?
[21:47] <mpontillo> pacavaca_: commissioning is when MAAS performs a network boot to inventory the host - CPU, RAM, disks, network cards, etc. recommissioning is just doing that again (in case something changed)
[21:48] <pacavaca_> mpontillo: ah, ok then. thanks
[23:09] <mup> Bug #1579073 changed: [ERROR] Failed to probe and enlist VMware nodes: 'vim.Folder' object has no attribute 'summary' <MAAS:New> <MAAS 1.9:New> <MAAS 2.0:New> <https://launchpad.net/bugs/1579073>
[23:19] <f1gjam> ahasenack, im starting from scratch


[18:06] <weox> http://pastebin.ca/2199714 , hello , i done everything in this code , use setmaximum , setminimum and ... , but it can work on that dialog , it is bug with ATI (jvm has strange issue with my ATI card)?? or some thing i wrong done ? even setSize dosnt work


[03:37] <Nico_> Hello , I'm new
[08:07] <Kilos> o/
[08:08] <svij> hey Kilos
[08:09] <Kilos> hi svij
[08:09] <svij> how you doing?
[08:16] <wxl> svij: i've been a bit quiet but congrats and welcome to the lc
[08:16] <svij> wxl: thanks!
[08:16] <wxl> you should bug irc team to add you to:
[08:16] <wxl> !lococouncil
[08:17] <svij> I'll take care of that after my trip to UbuCon Summit… currently doing all the preparation before I fly tomorrow morning
[08:18] <wxl> oh man wish i could be there :(
[08:18] <svij> I got sick right in time yesterday/today :-/
[08:32] <pleia2> oh great, svij is bringing the ubuflu
[08:32] <pleia2> ;)
[08:32] <svij> sure!
[08:32] <svij> and you bring the headaches as it seems ;)
[08:33] <pleia2> haha, thankfully those aren't contagious ;)
[08:33] <wxl> ouch i think that was a burn pleia2 ;Þ
[08:33] <svij> :D
[08:34] <pleia2> wxl: you'll be missed
[08:35] <wxl> :'(
[08:35] <pleia2> next ubucon summit!
[08:35] <svij> or ubucon europe ;)
[08:35]  * wxl has to take his daughter to have a pin put in her wrist friday :''''''''{
[08:35] <wxl> ooh that'd be fun
[08:35] <wxl> i've never been
[08:36] <pleia2> eep, good luck with that
[08:36] <svij> noone has been to ubucon europe, because the first one is this year ;)
[08:36] <wxl> i'm sure it will be fine
[08:36] <wxl> no i mean i've never been to europe
[08:36] <svij> sure :D
[08:36]  * svij tried to be funny.
[08:37] <wxl> hehehehe
[08:37]  * wxl got it
[08:39] <svij> oh, I need an us-adapter Oo
[08:47] <nhaines> wxl: Europe is great, they mostly drive on the right side of the street.
[08:47] <nhaines> And Germany just puts all its meat dishes in gravies and sauces, so that's no problem either.
[08:47] <wxl> is that a feature or a bug? XD
[08:47] <pleia2> also, their default beers tend to be better than ours
[08:47] <nhaines> Yup, so you can nurse it forever and if it gets warm you don't even notice, unless it's that the flavor broadened.
[08:47] <wxl> that's saying a lot
[08:48] <nhaines> And if you don't agree, you just get a new one anyway, hehe.
[08:48] <nhaines> Problem solved!  \o/
[08:48] <wxl> i don't drink anymore but there was at least one american who could make a decent lager
[08:48] <wxl> heater allen
[08:48] <wxl> dopplebock is delicious too
[08:48] <pleia2> I am no fan of lagers, but there are some amazing microbreweries stateside now :)
[08:48] <pleia2> they aren't "default" beers though
[08:49]  * svij doesn't drink
[08:49] <nhaines> I was this close to getting a Schneider-Aventinus doppelbock today.  But I didn't.  :)
[08:49]  * rww looks at scrollback
[08:49] <wxl> he's austerely german about the whole process, of course adhereing to the Reinheitsgebot
[08:49] <pleia2> I had a beer yesterday with Simcoe hops \o/
[08:49] <rww> We replacing someone or just adding to !lococouncil?
[08:49] <wxl> rww: adding svij
[08:49] <nhaines> rww: ¿porque no los dos?
[08:50] <wxl> also lagers are terrible in the us
[08:50] <rww> k. I'll let ubottu know. Not sire what the sync delay is.
[08:50] <wxl> thx rww
[08:50] <wxl> but REAL lagers oohhhh droool
[08:50] <nhaines> M'query.
[08:51] <wxl> oh wow i've never had a schwarzbier
[08:51] <pleia2> it is not awaking time anymore
[08:51] <pleia2> good night
[08:51] <wxl> https://en.wikipedia.org/wiki/Schwarzbier
[08:51] <wxl> i'm almost there
[08:51] <nhaines> Schwarzbiers are nice.  Rauchbier was the interesting one.
[08:51] <nhaines> I need to drink one with a really heavy meat pizza some time.
[08:52] <wxl> mm
[08:52] <svij> if you all come to ubucon europe, I guess you're only trying out the beers^^
[08:52] <wxl> i really love saisons tho
[08:52] <wxl> that's easily my favorite
[08:52] <nhaines> I'm not a fan of saison but I love lambic beers.
[08:52] <wxl> svij: well, i'll be sniffing, but not partaking
[08:52] <nhaines> But I'm too cheap to buy them.


[03:59] <Hypnotoad> knome: You can also request queuebot in the devel channel spitting out things related to your build or packageset, at least I think so anyway.
[06:05] <cub> Release day?
[06:08] <Noskcaj> cub, Almost release night over here
[06:08] <cub> we should use that internet time. :D
[06:38] <cub> great, so how do I know if it is Virtualbox on Mac that breaks JACK or if it's the latest release that's broken?
[06:45] <OvenWerks> jack worked fine for me... 32 and 64 bit
[06:46] <OvenWerks> da/coast
[06:46] <OvenWerks> da/coast
[06:56] <cub> yeah I saw you had tested already
[06:56] <cub> which per our standard seems to be enough, 2/2 and 1/1.
[06:58] <cub> this is weird though since I tested the i386 iso 3 days ago and had no issues starting JACK in live session. But now, on the same VM both amd64 and i386 live session, JACK crashes
[07:45] <cub> Ok, so after setting up new laptop the i386 iso runs JACK fine in live session. Virtualbox on Mac, no to reliable.
[07:45] <cub> on the other hand, my touchpad on the ubuntu laptop does not work in the live session.
[07:47] <cub> I only have crap HW available, maybe I should just lay off the testing ...
[08:56] <cub> hi smartboyhw
[08:56] <smartboyhw> cub, hello, can you test the i386 upgrades?
[08:56] <smartboyhw> We are only missing that...
[08:56] <cub> Nope
[08:57] <smartboyhw> Ouch
[08:57] <cub> I tried but it keeps crashing on my virtualbox and my eee pc won't get it to work
[08:57] <cub> but when I checked OvenWerks had done all tests already?
[08:57] <smartboyhw> http://iso.qa.ubuntu.com/qatracker/milestones/305/builds/55392/testcases
[08:57] <smartboyhw> Isn't done
[08:58] <cub> Aha perhaps I can run those.
[08:58] <smartboyhw> cub, yay!
[08:58] <cub> it's upgrade from 13.04? not 12.04.3?
[08:59] <smartboyhw> cub, upgrade from 13.04
[08:59] <smartboyhw> We don't support upgrading from 12.04.3 to 13.10 (it's too big change)
[09:00] <cub> strange, when I navigate through the iso.qa site I can't find that page you linked to
[09:00] <smartboyhw> Eh?
[09:00] <smartboyhw> cub, ISO QA Tracker -> "Saucy Final" -> "Upgrade Ubuntu Studio i386"
[09:00] <cub> aha Upgrade was filtered out with the other distros
[09:00] <smartboyhw> ;)
[09:03] <cub> Why is "Upgrade" considered a separate Product?
[09:03] <cub> doh..my 13.04 VM was 64 bit. Need to install 32 bit first
[09:03] <cub> I will most likely get the same issue with JACK as before, but I blame that on Virtualbox running under Mac OS X
[09:08] <smartboyhw> cub, well, JACK on Virtualbox is terrible but it does pronounce sound here :)
[09:08] <cub> It worked fine 3 days ago, but with the new iso today I got crashes on both 32 and 64 live sessions on the sam VM
[09:09] <cub> but I ran a usb live session on my eee pc and it worked fine. Though I had hw issues on that pc
[09:17] <smartboyhw> zequence, hmm, last time (13.04) I didn't do any release announcements, we only have the one you did....
[10:18] <cub> 13.04 installation, updating 320 packages. :P
[10:18] <cub> suppose I can go for lunch before I can do the 13.10 upgrade.
[10:38] <smartboyhw> cub, sure
[11:10] <zequence> smartboyhw: Just do what you always do. That text only needs to be copied directly to the website
[11:11] <smartboyhw> zequence, ACK, OK
[11:11] <zequence> I'll be doing an additional release announcement, just giving some cred to the people developing Ubuntu Studio, and talking a bit about what has been going on
[11:21] <knome> Hypnotoad, might be possible, but you probably want to see the discussion as well
[11:24] <smartboyhw> zequence, check out the announcement on the Ubuntu Studio website (draft)
[11:25] <smartboyhw> holstein, please be ready for updating channel topics today :)
[11:26] <zequence> smartboyhw: Looks good
[11:26] <smartboyhw> zequence, :)
[12:00] <cub> 1567 files to fetch. :P
[12:03] <smartboyhw> cub, ow
[12:18] <cub> the wifi dropped mid-upgrade....
[12:20] <smartboyhw> cub, ew
[12:20] <smartboyhw> Forget it then?
[12:33] <zequence> smartboyhw: Let's fix the download page before posting the release, ok?
[12:33] <smartboyhw> zequence, you want to change the download links NOW? Sure
[12:34] <zequence> smartboyhw: I'll wait until the official release announcement
[12:34] <smartboyhw> zequence, OK
[12:41] <cub> no it seems to be alright. Must have downloaded everything just in time.
[12:41] <cub> so the upgrade test is still ongoing.
[12:55] <smartboyhw> cub, yay
[12:55] <smartboyhw> zequence, I've updated the links on my side, just waitiing for the release
[12:58] <zequence> smartboyhw: What links?
[13:08] <smartboyhw> zequence, download links
[13:10] <zequence> smartboyhw: Yes, but where?
[13:10] <smartboyhw> zequence, well, at my computer-.-
[13:10] <smartboyhw> We are supposed to wait till release right?
[13:10] <zequence> smartboyhw: So, you put some links onto your computer?
[13:11] <zequence> Where did you change the links, is what I'm asking
[13:11] <smartboyhw> zequence, not-yet-saved  copy on the website (because it doesn't allow drafts)
[13:12] <zequence> Ah, ok. Well, you want to update the wikis then too?
[13:12] <zequence> I was going to do that, but it seems you are already doing it
[13:13] <smartboyhw> zequence, since you were going to do the wikis, you can do the wikis:)
[13:13] <zequence> smartboyhw: I was going to do the download page too
[13:13] <smartboyhw> zequence, oh, OK
[13:13] <smartboyhw> Will update the wiki later then
[13:14] <zequence> ok, good
[13:19] <cub> smartboyhw: upgrade test ok.
[13:19] <smartboyhw> cub, it's released anyhow:P
[13:19] <cub> bah
[13:19] <smartboyhw> (Looks like)
[13:20] <cub> seems all my testing for this release have been obsolete.
[13:20] <smartboyhw> cub, don't feel that sad
[13:21] <zequence> cub: The most common problem for me when doing upgrades is user settings
[13:21] <cub> hmm yeah I didn't any of those since the 13.04 installation was clean install
[13:21] <zequence> cub: things like background for the login window being corrupted. I think the more you change settings (and they are stored in the user home folder), the more likely there are to be problems
[13:22] <smartboyhw> zequence, my release announcement sent and published
[13:22] <cub> hard to write a test case for that?
[13:23] <zequence> cub: I think one just needs to map out all of the settings that can be changed and stored for XFCE
[13:23] <zequence> but,  it's a little outside of the scope of what we do here
[13:23] <zequence> so, not really what we should focus on
[13:24] <zequence> smartboyhw: Ok. Great
[13:26] <zequence> I'll post another release announcement later today - or it'll be more like just a letter to the public
[13:26] <smartboyhw> zequence, the wiki links that I can found is changed
[13:26] <zequence> smartboyhw: There are only two. wiki.ubuntu.com/UbuntuStudio and help.ubuntu.com/community/UbuntuStudio
[13:27] <smartboyhw> zequence, then all done
[13:27] <zequence> Great work everyone.
[13:28] <smartboyhw> zequence, cub OvenWerks great job:)
[13:28] <smartboyhw> Releases are earlier these days
[13:29] <smartboyhw> 13.04 and 13.10 are no later than 15:30 UTC
[13:29] <smartboyhw> Huh, only three flavours have announcements (LOL) https://lists.ubuntu.com/archives/ubuntu-announce/2013-October/000177.html
[13:31] <smartboyhw> astraljava, holstein please change topic in #ubuntustudio, we thank you for the work:)
[13:39] <smartboyhw> T cycle, here we come (where's the codename:P)
[13:45] <zequence> reposted in all our social channels
[13:46] <smartboyhw> zequence, yay
[14:12] <OvenWerks> for 14.04 I am thinking it may be worth while finding out what plugins are available for some of our main apps. (the scanning plugin for gimp may only be the tip of things)
[14:12] <OvenWerks> I think we should at least include most of such things in the extra SW installer.
[14:12] <smartboyhw> OvenWerks, write it in the blueprints. Great work of you in 13.10:)
[14:12] <OvenWerks> but we need to know what they are first.
[14:13] <zequence> OvenWerks: Currently, we don't have anyone working on any of the workflows
[14:13] <OvenWerks> I will maybe tonight (think 10 hrs down the road) But it is also something that will need discusion.
[14:14] <OvenWerks> I know.
[14:14]  * OvenWerks is off to work
[14:14] <zequence> We should find out about all the apps
[14:14] <zequence> Do a thorough research all around
[14:24] <cub> I was starting out to map workflows somewhat
[14:24] <cub> found a couple of pages that Scott set up I think
[14:24] <cub> but never got further than that so far.
[14:31] <cub> perhaps I should transfer my googledoc to the ubuntu wiki instead
[14:37] <cub> Hi ttoine, I think my mug have arrived. Will collect it form the Post office tonight. All in one piece I hope.
[14:41] <ttoine> ok
[14:41] <ttoine> tomorrow, I test ubuntu phone
[14:41] <ttoine> and I will try to use it as a java app server
[14:56] <zequence> cub: Scott scribbled a few things, yes, and some other folks
[14:57] <zequence> cub: But, those are not really relevant for researching apps so much, I mean, not so that you could base a lot of work on those pages
[14:58] <zequence> I find that Scott was focused on finding some way of simplifying the use of tools for users
[14:58] <zequence> But, IMO, he went the wrong way about it
[14:58] <zequence> What you need is application development for that to happen
[14:58] <zequence> And User Documentation, youtube videos, which show the user how to use existing tools
[14:59] <zequence> cub: Could I see what you have done so far?
[14:59] <cub> yeah but a list of the apps included with some information would be nice
[14:59] <cub> not much, I gathered some links you sent me and what I found on the wiki
[14:59] <cub> then I brainstormed a bit
[15:00] <cub> email incoming
[15:00] <zequence> cub: I think the first thing you should do is find a good way to list all application that are even faintly related to our workflows
[15:00] <zequence> then do some simple categorization on sub-workflows
[15:00] <zequence> Like, recording, mixing, mastering, etc.
[15:01] <zequence> It's easy to do on a workflow that you know well
[15:01] <zequence> If I were to do that for graphics, I'd need to learn all about graphics first, you know
[15:01] <zequence> We should consider some alternatives
[15:01] <cub> mhm
[15:02] <cub> I put a lot of stuff I'm planning to cehck out in trello
[15:02] <zequence> We could probably get all the major apps and tools to fit on the ISO
[15:02] <zequence> But, someone needs to find out, if it is possible, and for that, you need to have a comprehensive list of applications
[15:02] <cub> yeah
[15:03] <zequence> Anyway, the first thing to do is list the applications
[15:03] <zequence> All of them
[15:03] <zequence> Probably smartest to use some apt magic to find them
[15:05] <cub> gotta head home to the family. :) I might be around later on again.
[16:29] <holstein> updated topic :)
[19:20] <cub> zequence, how's the new job?


[02:22] <mup> PR snapd#3556 opened: Support snap license field (SPDX expression) <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/3556>
[04:19] <mup> Bug #1563358 changed: snappy can only handle one bootloader (if grub is installed, uboot is completely ignored) <Snappy:Expired> <https://launchpad.net/bugs/1563358>
[04:28] <mup> PR snapcraft#1386 closed: tests: workaround issue that causes failures to download core <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1386>
[05:22] <mup> PR snapd#3557 opened: systemd: add snapd.core-fixup.service unit <Created by mvo5> <https://github.com/snapcore/snapd/pull/3557>
[06:56] <zyga> oh linode why do you hate me
[06:56] <zyga> and qemu, why do you need all the network to run tests :/
[06:57] <mvo> hey zyga, good morning
[06:57] <mvo> zyga: could you please push your branch that backports the internaltool use for 2.26?
[06:58] <zyga> yes
[06:58] <zyga> pushed
[06:58] <zyga> there are three commits
[06:58] <zyga> one is the squash of your branch
[06:58] <zyga> and there are two more that are small backports to make things work
[06:59] <zyga> backport/2.26/fix-internal-tool-path
[06:59] <zyga> I didn't manage to run tests yesterday
[06:59] <zyga> my network at home is super unreliable
[06:59] <zyga> and capping makes things fail all the time
[06:59] <zyga> if you have better connectivity please pull and run locally
[06:59] <zyga> I think one test failure was genuine, it is just measuring a stale reexec message
[07:00] <zyga> mvo: please ack, I'm not even sure IRC works (I always see lag: $LOTS) in irssi
[07:03] <mvo> zyga: ack
[07:03] <mvo> zyga: great, I can run tests here
[07:03] <zyga> thanks!
[07:05] <mvo> zyga: do I need detect-re-exec as well?
[07:05]  * mvo needs to take a short break, doorbell
[07:05] <zyga> mvo: which branch is that?
[07:10] <zyga> mvo: as for https://github.com/snapcore/snapd/pull/3557/files -- how about naming those as fixup-1-ownership-change.after so that we can just have a namespace for the files
[07:10] <mup> PR snapd#3557: systemd: add snapd.core-fixup.service unit <Created by mvo5> <https://github.com/snapcore/snapd/pull/3557>
[07:36] <mvo> zyga: I like the idea, however its out already so kind of difficult to change now
[07:37] <mvo> zyga: nevermind about https://github.com/zyga/snapd/tree/backport/2.26/detect-re-exec - I think we merged this already
[07:43] <zyga> mvo: +1 to keep as-is
[07:46] <mvo> zyga: ta
[07:59] <zyga> brb
[08:41] <pstolowski> hey guys, any improvement on linode side, or no change?
[08:42] <zyga> pstolowski: I tried an hour ago, all failed
[08:42] <pstolowski> zyga, ack, thanks
[08:45] <mvo> zyga: I pushed a fix for the failing test, I think we are good now
[08:47] <mup> PR snapd#3558 opened: cmd: backport fix for internal tool path <Created by mvo5> <https://github.com/snapcore/snapd/pull/3558>
[08:51] <zyga> mvo: thank you! let's see
[08:52] <zyga> mvo: which test was failingt?
[08:52] <mvo> zyga: I run the tests now against the full 2.26
[08:52] <mvo> zyga: it was re-exec and the string of the log messgae that it did not restart has changed
[08:53] <zyga> ah, great
[08:53] <zyga> mvo: ok, so that's all good for 2.26
[08:57] <mvo> zyga: yeah, I run tests locally right now and if things are good will release
[08:57] <zyga> sounds good, thank you!
[08:59] <mvo> zyga: yes
[09:14] <pstolowski> oh noes, 3 pages of PRs.. 56
[09:15] <mvo> pstolowski: well, linode broken
[09:21] <mvo> zyga: hrm, hrm, for some reason I cannot push to your branch zyga:backport/2.26/fix-internal-tool-path
[09:23] <pstolowski> yeah i know
[09:24] <mup> PR snapd#3559 opened: Backport/2.26/fix internal tool path <Created by mvo5> <https://github.com/snapcore/snapd/pull/3559>
[09:29] <zyga> mvo: why two PRS?
[09:29] <mup> PR snapd#3558 closed: cmd: backport fix for internal tool path <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3558>
[09:30] <mvo> zyga: couldn't push to your branch, I used my own now
[09:30] <zyga> mvo: ah, odd
[10:01]  * Chipaca suddenly finds himself recompiling ncurses, and takes a step back
[10:05] <pstolowski> Chipaca, I'll start to get worried when you fork ncurses
[10:05]  * Chipaca puts away his cutlery
[10:07] <pstolowski> just don't curse and you'll be fine
[10:08] <Chipaca> ncurses on debian has been waiting for a soname change to add support for mouse wheel events for 12 years now
[10:08] <Chipaca> I wonder if at any point it becomes "enough's enough"
[10:19] <pstolowski> Chipaca, is it important for us?
[10:19] <Chipaca> pstolowski: no :-)
[10:19] <Chipaca> that's why i stopped
[10:19] <pstolowski> :)
[10:28] <Chipaca> pstolowski: also, dangit, the 2*len(args)+4 was correct before i split -ojson -nn into -o json -n n
[10:29] <Chipaca> needs to be +6 now :-(
[10:29] <Chipaca> i shall fix it, and add a comment, at some point before landing this
[10:42] <zyga> re :-(
[11:11]  * zyga break
[11:18] <mvo> pstolowski, Chipaca: I just got a 504 from the store - we do not retry those currently, should we? if so, I can prepare a PR
[11:21] <pstolowski> mvo, are you sure? looking at retry.go we do retry everything >= 500
[11:22] <pstolowski> perhaps we exhausted all retries?
[11:24] <zyga> re
[11:25] <zyga> this is a very unproductive and annoying day :/
[11:25] <mvo> pstolowski: aha, maybe thisis just in the 2.26 branch (which I'm testing right now)
[11:25] <pstolowski> mvo, ah, could be, the >= 500 condition was introduced recently. before that we only retried select codes
[11:26] <pstolowski> zyga, don't tell me. I feel stupid still fighting json issue :}
[11:27] <pstolowski> maybe I need to take a step back and look at ncurses too ;)
[11:27] <zyga> pstolowski: I'm fighting weather and network while making no progress on apparmor profile load
[11:28] <zyga> fgimenez: any luck in that home test?
[11:32] <Chipaca> pstolowski: step away from ncurses tho
[11:32] <zyga> mvo: anything I can help with to have a change of focus?
[11:34] <pstolowski> Chipaca, ah, ok, I misunderstood then
[11:35] <mvo> zyga: not right now, running the tests, then I push a new release
[11:35] <zyga> ok
[11:38] <mvo> sorry
[11:38] <mvo> zyga: I guess the work for base-snaps on core (in snap-confine) is already done, right? that might be a nice project
[11:39] <niemeyer> Good morning
[11:40] <niemeyer> News from Linode:
[11:41] <niemeyer> Actually, I won't quote him directly as he was using language for a private conversation
[11:41] <niemeyer> But the point is, apparently their backend corrupted one of our images
[11:42] <niemeyer> Restore underway.. we can try it in a moment
[11:42] <zyga> niemeyer: do you know which one?
[11:42] <pstolowski> hey niemeyer!
[11:43] <pstolowski> great they found out finally
[11:43] <niemeyer> zyga: At least ubuntu-16.04-64 I suppose, which is the one presenting issues all the time
[11:43] <niemeyer> pstolowski: Fingers crossed for now
[11:43] <niemeyer> I don't know what I'll do when this one guy leaves Linode :)
[11:43] <zyga> hehe, I was about to say, murhpy picked the "best" image to corrupt
[11:50] <mvo> niemeyer: \o/
[11:51] <fgimenez> zyga: nope, i've kept retrying but no trace of it, i start from the stable image, sudo snap refresh, reboot and then run the tests, last week the same actions led to the error after about 15 runs, now i can't reproduce it
[11:51] <fgimenez> hey niemeyer, great!
[11:51] <zyga> fgimenez: ok, thank you!
[11:55] <niemeyer> Looks promising: https://travis-ci.org/snapcore/snapd/builds/250270516
[11:59]  * mvo crosses fingers
[12:00] <niemeyer> Still going strong
[12:28] <mup> PR snapcraft#1391 closed: tests: reduce the amount of test code in test_meta <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1391>
[12:31] <mup> PR snapcraft#1389 closed: Use newer distro module with no tuple <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1389>
[12:40] <Chipaca> niemeyer: mvo: i'm skipping the standup today -- i need to go to the boys' school
[12:41] <Chipaca> the only thing different on my front is that i had some fun snapping things and then realising the bugs i was seeing was because of a bug in the distro itself, not in the snap :-)
[12:55] <mup> PR snapd#3560 opened: cmd/snap-repair: implement most logic to get the next repair to run/retry in a brand sequence <Created by pedronis> <https://github.com/snapcore/snapd/pull/3560>
[13:08]  * zyga has network issues, trying to reconnect
[13:09] <zyga> mvo: can you see my messages now?
[13:09] <zyga> ok, back
[13:29] <fgimenez> mvo: i have the beta images already built, just to confirm release/2.26 is up to date for running the tests from it, correct?
[13:35] <zyga> pedronis: can you repeat what you said on the call?
[13:36] <pedronis> zyga: do we know if there was a self-built snapd involved?
[13:36] <pedronis> I know he had a very old one on his path at some point by mistake
[13:37] <pedronis> anyway not sure snapd itself would affect this unless it was a full deb
[13:37] <pedronis> and not just the daemon
[13:37] <zyga> pedronis: good question, I'll ask the reporter
[13:38] <mvo> fgimenez: almost, one sec
[13:38] <mvo> fgimenez: now it is up-to-date
[13:38] <fgimenez> mvo: cool thx!
[13:39] <niemeyer> Chipaca: Thanks for the note
[13:39] <niemeyer> Our Linode pool is clean and seems to be churning at an appropriate pace now
[13:43] <fgimenez> mvo: i see 2.26.8 in snap version's output, that is fine right? iirc we omited the last digit in previous releases
[13:45] <mvo> fgimenez: the output is correct, we skipped 2.26.7 because it was ready before the core-fixup script came up
[13:48] <fgimenez> mvo: ok thanks, but did we always include the 3 digits in the version? we have a 2.24.1 entry in the changelog but the current stable shows 2.24 in snap version
[13:50] <pstolowski> niemeyer, did you mean this topic https://forum.snapcraft.io/t/how-to-snap-get-root-document/522 ?
[13:50] <niemeyer> pstolowski: yes, that looks like the one
[13:50] <fgimenez> mvo: i'm in validation mode now, pls forgive my pickiness :)
[13:53] <mvo> fgimenez: we included the digests before, at least in theory, I need to figure out why changelog/core disagree
[13:53] <mvo> fgimenez: it might be that 2.24.1 was never uploaded as a core snap becasue it contained something that was only relevant on classic (adt fix or something)
[13:53] <fgimenez> mvo: ok great, don't spend too much time on it, just curious
[13:53] <niemeyer> pstolowski: I've added another note there as well on a closely related need
[13:54] <niemeyer> pstolowski: and tagged it for you
[13:54] <pstolowski> niemeyer, cool, thanks
[13:54] <niemeyer> pstolowski: Thanks for looking into this
[13:55] <pstolowski> niemeyer, btw did you get the calendar invitiaion for interfaces stuff?
[13:57] <niemeyer> Yep, looks good, thanks
[14:12] <coreycb> hi all, what's the next step for getting auto-aliases setup?  i have a security ack on the request: https://forum.snapcraft.io/t/auto-aliases-for-openstack-base-snaps/1146
[14:25] <niemeyer> coreycb: It's just waiting for a second +1 I think.. will look
[14:25] <coreycb> niemeyer: ok thanks!
[14:28]  * zyga dinner
[14:39] <mup> PR snapd#3539 closed: tests: fix timeout issue for test refresh core with hanging … <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3539>
[14:42] <jdstrand> coreycb: I'll circle back around in a bit. there is a voting process. I'll gide it
[14:42] <jdstrand> guide*
[14:42] <coreycb> jdstrand: ok thanks
[14:42] <flexiondotorg> icey A while back you mentioned that you a cholcombe were working on a rustup snap. Any progress on that?
[14:43] <zyga> jdstrand: o/
[14:45] <icey> No time flexiondotorg
[14:45] <flexiondotorg> OK :-(
[14:54] <mvo> fgimenez: I just double checked, 2.24.1 was a autopkgtest fix so not relevant for core
[14:56] <fgimenez> mvo: great thanks a lot, btw i just had an error on amd64 in the refresh from stable scenario http://paste.ubuntu.com/25025482/ i have the session open in case you want to have a look
[14:57] <fgimenez> mvo: core went from 1441 (this comes from the stable image) -> 2312 (after the first refresh, still stable) -> 2329 (beta)
[14:57] <mvo> fgimenez: yes, would love to have a look, do you have a ssh session for me?
[14:58] <mvo> fgimenez: if so, please /msg or tg
[14:58] <mvo> fgimenez: looks like snap list --all is affected
[14:58] <fgimenez> mvo: sure 1sec, fwiw the same scenario just finished successfully on i386
[14:58] <mvo> fgimenez: the mount unit for 1441 would be interessting
[14:59] <mvo> fgimenez: I suspect the snap is there but for some reason it is not mounted
[14:59] <fgimenez> mvo: indeed, it shows up in /var/lib/snapd/snaps
[15:06] <kyrofa> niemeyer, any chance you have some time available today to discuss the two snapcraft items from the sprint agenda?
[15:07] <niemeyer> kyrofa: Yeah, feel free to pick any open slot in the agenda
[15:09] <kyrofa> niemeyer, agenda = your calendar? :P
[15:10] <ogra_> heh
[15:11] <cholcombe> flexiondotorg: no i haven't made progress on that
[15:11] <flexiondotorg> cholcombe Thanks for the feedback.
[15:15] <niemeyer> kyrofa: Sorry, yeah
[15:27] <pstolowski> bah, got the json numbers working
[15:28] <pstolowski> now, i have so many changes in the tree... need to find out which ones are irrelevant to these fixes ;)
[15:28] <mup> PR snapd#3561 opened: tests: store /etc/systemd/system/snap-*core*.mount in snapd-state.tar.gz <Created by mvo5> <https://github.com/snapcore/snapd/pull/3561>
[15:28] <mvo> fgimenez: this is the PR we just talked about -^
[15:29] <fgimenez> mvo: great, thanks!
[15:32] <Chipaca> is ubuntu-16.04-32:tests/main/create-key being a problem, or have i been unlucky?
[15:49] <mup> PR snapd#3512 closed: cmd: avoid using current symlink in InternalToolPath <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3512>
[15:50] <mup> PR snapd#3559 closed:  cmd: backport fix for internal tool path #3558  <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3559>
[15:51] <mvo> if someone could review 3557 that would be great
[15:51] <mvo> zyga: maybe -^
[15:51] <mvo> then we can restart edge builds today
[15:52] <zyga> mvo: looking
[15:53] <Chipaca> mvo: 3557, or 8?
[15:53] <mvo> Chipaca: the systemd unit fix thing, 3557 I think
[15:54] <mvo> Chipaca: 3558 already got cherry picked when tests were still unhappy
[15:54] <Chipaca> ok
[15:56] <zyga> mvo: done
[15:57] <Chipaca> all the lgtms!
[15:57] <Chipaca> :-)
[16:05] <mup> PR snapd#3557 closed: systemd: add snapd.core-fixup.service unit <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3557>
[16:07] <mup> PR snapd#3562 opened: systemd: add explicit sync to snapd.core-fixup.sh <Created by mvo5> <https://github.com/snapcore/snapd/pull/3562>
[16:17] <mup> PR snapd#3563 opened: release: merge release/2.26 branch back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/3563>
[16:22] <mup> PR snapd#3546 closed: tests: fix for rng-tools service not restarting <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3546>
[16:23] <mup> PR snapd#3541 closed: snapd: fix for snapctl get panic on null config values <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3541>
[16:25] <mvo> cachio_afk: if you could address the feedback in 3409, that would be appreciated, then this branch can go in
[16:53] <pstolowski> mvo, shall I propose a cherry-picked PR 3451 for 2.26?
[16:53] <mup> PR snapd#3510 closed: tests: shellcheck improvements for nightly upgrade and regressions tests <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3510>
[16:55] <mvo> pstolowski: 3451 is dir abstractions - is this the one you have in mind?
[16:56] <pstolowski> mvo, sorry, 3541
[16:57] <mvo> pstolowski: unfortunately too late, 2.26.8 is out, so unless this is critical it will go into 2.27
[16:58] <pstolowski> mvo, i see. i don't think it's critical
[17:43] <coreycb> jdstrand: any chance you can publish this for me? https://dashboard.snapcraft.io/dev/snaps/6421/rev/78/   it looks to be blocked by a previous upload that used  kernel-module-control, but has since been dropped.
[17:44] <jdstrand> coreycb: sure thing (fyi, was off yesterday and monday so queue is a little behind (though it was caught up on friday)
[17:44] <jdstrand> )
[17:44] <coreycb> jdstrand: thanks, and no problem at all
[18:09] <jdstrand> coreycb: oh, that's done now. the newer ones are approved but you need to release them. did you want me to release the latest (r78) to edge for you?
[18:11] <coreycb> jdstrand: i've just released that. thanks!
[18:15] <jdstrand> cool np
[19:02] <mup> PR snapd#3538 closed: tests: create ramdisk if it's not present <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3538>
[19:03] <mup> PR snapd#3508 closed: tests: shellcheck improvements for tests/lib scripts <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3508>
[19:04] <mup> PR snapd#3492 closed: cmd/snap: `--last` for abort and watch, and aliases (search→find, change→tasks) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3492>
[19:08] <mup> PR snapd#3534 closed: tests: shellcheck improvements for tests/main tasks - first set of tests <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3534>
[19:10] <mvo> zyga: #3518 needs a test update, the failure look real
[19:29]  * zyga nods
[19:34] <mup> PR snapd#3518 closed: cmd/snap-confine: various small fixes and tweaks to seccomp support code <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3518>
[20:22] <mup> PR snapd#3518 opened: cmd/snap-confine: various small fixes and tweaks to seccomp support code <Created by zyga> <https://github.com/snapcore/snapd/pull/3518>
[20:23] <zyga> jdstrand: can you please have a 2nd look at ^
[20:38] <jdstrand> zyga: ack
[21:07] <zyga> jdstrand: thank you
[21:14] <jdstrand> zyga: yw
[23:09] <mup> PR snapd#3550 closed: update firewall-control to allow {arp,ip,ip6}tables to control bridged vlan/ppoe-tagged traffic <Created by coreycb> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3550>
[23:56] <mup> PR snapcraft#1392 opened: catkin plugin: extract rosdep into new package <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1392>


[07:08] <grendal-prime> dude...what is the irc client?
[07:08] <grendal-prime> i need this...
[07:11] <philipballew> grendal-prime, what do you need help with?
[07:40] <dholbach> good morning
[09:01] <dholbach> sorry, having problems with google hangout
[09:01] <dholbach> one second
[09:03] <dholbach> seems it's working now
[09:09] <Rcart> good morning o/
[09:10] <dholbach> hey Rcart
[09:30] <Rcart> see you in next hangout, 3:30 am here o/