[11:50] <Guest69981> Why do people say that upgrading to Ubuntu 15 from Ubuntu 14.10 isn't recommended?
[11:52] <Na3iL> Guest69981, cause 15.04 is not LTS like people think
[11:53] <Guest69981> Sorry i'm new to Ubuntu ,
[11:53] <Na3iL> Wait! you mean downgrade not upgrade
[11:53] <Guest69981> upgrade
[11:54] <Guest69981> So will Ubuntu 15 be a LTS version?
[11:54] <Na3iL> Nope, 15.04 is not LTS anymore
[11:55] <Na3iL> So, it is not supportable from Canonical
[12:04] <Guest69981> Ok thanks alot ..


[13:45] <ancienttoilet> Good afternoon. First time every using cloud-init and I am really confused
[13:45] <ancienttoilet> I wold like to automate the deployment of Landscape with it, here is the yml file https://raw.githubusercontent.com/canonical/landscape-scripts/main/provisioning/cloud-init.yaml
[13:46] <ancienttoilet> however, I am not sure where to put or how to tell  cloud-init to deploy that yml file
[13:50] <minimal> you provide that as user-data when you create the VM
[13:51] <minimal> where are you deploying? to a specific cloud provider? to a local hypervisor-based VM?
[14:11] <ancienttoilet> hey minimal
[14:11] <ancienttoilet> I am trying to deploy it locally really
[14:11] <ancienttoilet> and using lxd
[14:12] <ancienttoilet> so I need to use lxd commands to deploy that yml file?
[14:12] <minimal> so then when you deploy the VM via LXD you use whatever mechanism the LXD tools have to specify user-data
[14:12] <ancienttoilet> I was expecting something like docker-compose . I was wrong :S
[14:13] <minimal> you must be running some cli tool to deploy the VM, right?
[14:13] <ancienttoilet> alright then, I will do the tutorial.
[14:13] <ancienttoilet> what do you mean?
[14:13] <ancienttoilet> the host is debian
[14:13] <minimal> how are you creating the VM in LXD?
[14:13] <ancienttoilet> lxd handles containers
[14:14] <minimal> yes and it also handles VMs, I assumed you were creating a VM not a containers
[14:14] <ancienttoilet> I thought I could feed the .yml file to cloud-init just as you do for docker-composer
[14:14] <minimal> how are you creating the container/VM with LXD?
[14:14] <ancienttoilet> minimal: I understand. Well I am kinda confused atm
[14:14] <ancienttoilet> I haven't yet.
[14:15] <minimal> LXD containers are nothing to do with docker
[14:15] <ancienttoilet> I literally started exploring this project
[14:15] <ancienttoilet> minimal: I know. I just though cloud-init usage of a yml file would be similar to docker-compose.
[14:15] <ancienttoilet> my mistake
[14:16] <minimal> you use a LXD tool to create a LXD container or LXD VM, that tool should provide a way to specify user-data at the same time
[14:17] <ancienttoilet> and the .yml config is the user-data right?
[14:17] <minimal> yes
[14:18] <ancienttoilet> alright, I guess I have some readings to do before I even go ahead with this
[14:18] <ancienttoilet> thank you for now :)
[14:40] <ancienttoilet> I guess I have the basics figured now
[14:40] <ancienttoilet> one more question
[14:41] <ancienttoilet> how can I pass the proxy settings to cloud-init? I have it in /etc/environment but it is not liking it by the looks of it
[14:42] <ancienttoilet> https://pastebin.com/XwD0dvN8
[16:04] <minimal> ancienttoilet: that is nothing to do with cloud-init - cloud-init runs inside the ubuntu cloud image which this error shows has not even been downloaded yet
[17:49] <blackboxsw> ancienttoilet: right, check out this tutorial for cloud-init on launching LXD with user-data https://cloudinit.readthedocs.io/en/latest/tutorial/lxd.html.
[17:51] <blackboxsw> and for proxy settings in cloud-init I don't think we've grown proper proxy config setup/automation given the state of this bug https://bugs.launchpad.net/cloud-init/+bug/1089405 (which has a workaround for you which may help)
[17:51] -ubottu:#cloud-init- Launchpad bug 1089405 in cloud-init "setting up system proxy via cloud-config might be nice" [Wishlist, Expired]
[17:55] <OutOfService> hi
[17:58] <OutOfService> so, i seems that there is a new way in order to deploy ubuntu, right? I'm used to use ipxe with http and simple config parameters for installing to my lab. Now I'm a little lost with cloud-init. Could please somebody help me to find some examples for installing ubuntu via (i)pxe and http, please? I don't know where top start.. there is no very much information at these days...
[18:09] <dbungert> OutOfService: I think this is more of an Ubuntu topic than a cloud-init one.  I suggest taking this to #ubuntu-server.  as a starting point, https://ubuntu.com/server/docs/install/autoinstall-quickstart has a bit about feeding autoinstall by way of cloud-init to the newer installers.
[18:09] <blackboxsw> OutOfService: seems like you are referring to Ubuntu autoinstall on live server/desktop images. https://ubuntu.com/server/docs/install/autoinstall  and https://ubuntu.com/server/docs/install/netboot-arm64 may be helpful. Cloud-init is used under the hood to allow for obtaining #cloud-config user-data during that boot process. The autoinstall:  key is largely ignored by cloud-init and passed through to the subiquity installer...
[18:09] <blackboxsw> https://cloudinit.readthedocs.io/en/latest/reference/faq.html#autoinstall-preruncmd-postruncmd.
[18:10] <blackboxsw> as dbungert mentioned, best to continue the installer conversation over in #ubuntu-server
[18:10] <blackboxsw> thx dbungert
[18:13] <OutOfService> thanks very much!!
[19:38] <blackboxsw> holmanb: I mentioned I'd look again at BSD images in clouds to see status/supportability from pycloudlib. As it stands, it looks like thefreebsdfoundation is a publisher of Azure images, but those images don't contain cloud-init by default. I think meena has mentioned https://bsd-cloud-image.org/ as typical base BSD image which can be converted and uploaded to clouds.
[19:39] <blackboxsw> azure's BSD publisher images:  are as follows:
[19:39] <blackboxsw> +FREEBSD_IMAGES = {
[19:39] <blackboxsw> +    "13.1": "thefreebsdfoundation:freebsd-13_2:13_2-release:13.1.0",
[19:39] <blackboxsw> +    "13.2": "thefreebsdfoundation:freebsd-13_2:13_2-release:13.2.0",
[19:39] <blackboxsw> +}
[19:39] <blackboxsw> ec2, on the otherhand seems to have an ec2 marketplace publisher "FreeBSD" which do contain cloud-init in images. I have a working example that I'd like to add to pycloudlib/examples
[19:39] <blackboxsw> https://aws.amazon.com/marketplace/seller-profile?id=92bb514d-02bc-49fd-9727-c474863f63da&ref=dtl_B0928XNW6D
[19:40] <blackboxsw> holmanb: and I've tested latest pycloudlib with your changes for custom username and we can directly provide known amis from ec2 BSD marketplace images and successfully interact w/ cloud-init there.
[19:43] <blackboxsw> strike that on ec2... it's running configinit too (like Azure images) https://www.daemonology.net/blog/2013-12-09-FreeBSD-EC2-configinit.html
[19:46] <blackboxsw> so I can put together a pycloudlib:examples/ec2.py  script that shows pkg install py39-cloud-init and rebooting into the test system.... but again it'd be injecting cloud-init after initial boot and rebooting into the 'clean' environment
[19:47] <blackboxsw> so, not ideal if we don't have official BSD images in ec2/azure with cloud-init already installed
[19:48] <falcojr> yeah, that feels excessive to me
[19:51] <blackboxsw> yeah, I think it's enough to say, pycloudlib supports unique AMIs from BSD when present and can interact with that VM using the desired custom username and related SSH pubkey/cert
[20:04] <meena> blackboxsw: who do we need to talk to fix that?
[20:05] <meena> actually, i probably know
[20:06] <meena> https://freshbsd.org/freebsd/src/branch/main?q=azure
[20:07] <meena> looks like lwhsu@ does azure stuff on behalf of the freebsd foundation
[20:11] <meena> https://github.com/freebsd/freebsd-src/blob/main/release/tools/azure.conf
[20:16] <blackboxsw> yeah that may help if there are Azure images from thefreebsdfoundation: containing configured/enabled cloud-init by default, pycloudlib testing should be a breeze.
[20:19] <blackboxsw> meena: with your recent merges of https://github.com/canonical/cloud-init/pull/4209/files and https://github.com/canonical/cloud-init/pull/4182 does that mean things are well placed for ds-identify to quickly reduce possible datasources detected on BSD prior to any cloud-init python code getting involved trying to DataSource*._get_data() now?
[20:19] -ubottu:#cloud-init- Pull 4209 in canonical/cloud-init "setup: fix generation of init templates" [Merged]
[20:19] -ubottu:#cloud-init- Pull 4182 in canonical/cloud-init "BSD: add dsidentify to early startup scripts" [Merged]
[20:20] <blackboxsw> as in, BSD cloud-images can contain a configured  cloud-init  which will filter it's datasource discovery based on the outputs of ds-identify in early boot.
[20:21] <blackboxsw> I mean this'll be cloud-init 23.3  as that functionality just landed now.
[20:26] <meena> blackboxsw: yes. it seems to work!
[20:26] <meena> I just say I'm surprised myself;)
[20:34] <blackboxsw> sweet!
[20:36] <blackboxsw> that'll be a huge performance boost as folks publish BSD images to various clouds to allow them to  avoid having to tailor the image to a specific `datasource_list: [ Ec2 ]` or OpenStack etc
[20:37] <meena> I've also made it easy for the service to be removed, in case someone prefers that
[20:42] <blackboxsw> good deal.
[20:44] <blackboxsw> meena: do you know offhand if typical BSD images prefer to **not** have sudo installed? just wondering from expectations of cloud-init and pycloudlib integration tests .pycloudlib tries to use sudo when non-root user is the default user on an instance
[20:44] <blackboxsw> and the BSD images I've seen in azure/ec2 don't have sudo installed by default
[20:44] <blackboxsw> it's something we'll have to be aware of if we want easy cloud image testing setup somewhere for BSD.
[20:45] <minimal> blackboxsw: some of the BSDs (OpenBSD for example) tend to use doas rather than sudo
[20:46] <meena> OpenBSD has a doas in Base, and for everyone else it's a contentious subject
[20:46] <minimal> I've been adapting my Alpine-specific patch to cloud-init to make it OS generic with the intention of submitting a PR for it soon (just need to write testcases)
[20:46] <minimal> my doas patch I mean
[20:47] <meena> I think the split is probably fifty 60% sudo, 25 su, rest doas
[20:47] <blackboxsw> TIL about doas thx.  so pycloudlib may need to grow a switch based on what utility to escalate permissions is available. specifically I'm thinking about things like our Instance.clean method https://github.com/canonical/pycloudlib/blob/main/pycloudlib/instance.py#L198-L212
[20:48] <meena> it would be cool if the choice was configurable, but as of yet, it's a runtime dependency, so it's a porter's opinion in that mix, too
[20:48] <blackboxsw> that'd be a blocker as many integration tests try to use "clean" before snapshotting images in clouds
[20:48] <blackboxsw> and then running through test cases for the base snapshotted image (with cloud-init upgraded to whatever we are testing)
[20:49] <blackboxsw> makes sense.
[20:49] <minimal> blackboxsw: I guess you'd have to run "which sudo", "which doas" etc or similar to decide which is available first
[20:50] <meena> seems easy enough
[20:50] <blackboxsw> yeah that's what I'm thinking too minimal.. though this particular ec2 marketplace image of BSD has neither sudo nor doas :)
[20:50] <blackboxsw> so I have to su ... .then pkg install X
[20:50] <meena> you'd probably not want both of those installed, and definitely not on a test system
[20:52] <blackboxsw> agreed. one or the other. sensible fallback when sudo doesn't exist... and a hard fail if neither sudo nor doas


[08:06] <guiverc_t> plan 3, cano 7, pres 1, blog 7(+1), audv 1  ... but not fri.evening in most of world so likely will be more
[08:29] <tsimonq2> guiverc_t: Thanks, good work as always :)
[23:15] <guiverc_t> summary email sent; fyi:  blogo stuff on 16.10EOL I'd like to move to general; due topic [EOL] - agree?
[23:23] <guiverc_t> moved: following #473
[23:25] <guiverc_t> (but note #473 was post-eol; we're still pre-EOL)


[02:25] <KageSenshi> ejat, dude u got my mail ?
[02:26] <KageSenshi> anyway .. ubuntu-my .. theres opportunity for a desk booth at HiTB KL 2012 .. if you guys interested, ping me ..
[06:35] <ejat> KageSenshi: email direct to me or group ? btw thanks ..
[06:36] <KageSenshi> ejat, ur ubuntu.com.my address
[06:36] <KageSenshi> i mean , ubuntu.com
[06:39] <ejat> ok .. got it
[06:39] <ejat> btw .. is it on october?
[06:42] <KageSenshi> yep october
[07:49] <fairuz> helo rakan2
[20:59]  * ejat pang penreturns


[08:16] <lissyx> bandali, do you know where to escalate https://bugs.launchpad.net/snapd/+bug/2048104 ?
[08:16] -ubottu:#ubuntu-desktop- Launchpad bug 2048104 in snapd "Cant install firefox update - Mount snap 'firefox' (3600) (cannot find required base 'core22')" [Undecided, New]
[08:16] <lissyx> either we need more logging or the issue on snap store cannot be identified client-side
[08:16] <lissyx> but we still have issues
[10:07] <KGB-X> mutter Daniel van Vugt 453857 * commented merge request !116 * https://deb.li/3GKNA
[11:43] <lissyx> seb128, hello, happy new year :)
[11:44] <lissyx> seb128, do you know who to ping for https://bugs.launchpad.net/snapd/+bug/2048104 ?
[11:44] -ubottu:#ubuntu-desktop- Launchpad bug 2048104 in snapd "Cant install firefox update - Mount snap 'firefox' (3600) (cannot find required base 'core22')" [Undecided, New]
[12:51] <seb128> lissyx, hey, happy new year!
[12:57] <seb128> lissyx, maybe try to post about it on the snapcraft forum?
[12:57] <seb128> I can try to nag on an internal channel but no guarantee
[12:59] <lissyx> there's already this bug, I'm not sure how forum would help
[13:03] <seb128> lissyx, the forum feels more active than the bug tracker to me
[13:42] <bandali> hey lissyx, happy new year! indeed, i echo seb128's sentiments about trying asking on the forums, i don't have any other clues
[13:43] <lissyx> I would have anticipated that problem on the store get more visibility than a forum :(
[13:49] <lissyx> also the forum makes it painful
[13:49] <lissyx> I can't put more than two links ...
[13:50] <bandali> i'm sorry about the situation & the pain points :-(
[13:50] <bandali> i'd have offered to help post your text on your behalf, but i don't think i have special perms/levels on the snapcraft forums
[13:51] <lissyx> https://forum.snapcraft.io/t/intermittent-failure-to-snap-refresh-becauses-of-store-issue/38431
[13:51] <lissyx> I had to remove one link :(
[13:55] <bandali> lissyx, thanks. if you can send the link here, i can try adding it as a reply to your post?
[13:56] <bandali> ah i see you did that yourself :-) nvm
[14:01] <KGB-X> mutter Marco Trevisan 453944 * commented merge request !116 * https://deb.li/3H4j
[14:04] <KGB-X> mutter Marco Trevisan 453945 * commented merge request !116 * https://deb.li/h0jl
[14:42] <lissyx> bandali, seb128, tests succeeded; https://treeherder.mozilla.org/jobs?repo=try&revision=12076c6fdc3f8a61754f34cbe86c6f0e3eb586c6
[17:49] <KGB-X> gnome-online-accounts signed tags 7d8d453 Jeremy Bicha upstream/3.49.0 * Upstream version 3.49.0 * https://deb.li/oKHh
[17:49] <KGB-X> gnome-online-accounts upstream/latest be61eae Jeremy Bicha * pushed 67 commits (first 5 follow) * https://deb.li/3bKxR
[17:49] <KGB-X> gnome-online-accounts upstream/latest 66fcffa Yuri Chornoivan po/uk.po * Update Ukrainian translation * https://deb.li/3g4ND
[17:49] <KGB-X> gnome-online-accounts upstream/latest b33de3a Quentin PAGÈS po/oc.po * Update Occitan translation * https://deb.li/ixLEz
[17:50] <KGB-X> gnome-online-accounts upstream/latest 0fae428 Felipe Borges (5 files in 3 dirs) * build: Depend on gcr4 * https://deb.li/4N91
[17:50] <KGB-X> gnome-online-accounts upstream/latest a0f315c Milan Crha src/goaidentity/goaidentityutils.c * goaidentityutils: Correct unused result warning from g_string_free() * https://deb.li/3WKWN
[17:50] <KGB-X> gnome-online-accounts upstream/latest 909686f Emmanuele Bassi (5 files in 3 dirs) * Merge branch 'depend-on-gcr4' into 'master' * https://deb.li/e4XV
[17:50] <KGB-X> gnome-online-accounts pristine-tar 17e05bc Jeremy Bícha gnome-online-accounts_3.49.0.orig.tar.xz.delta gnome-online-accounts_3.49.0.orig.tar.xz.id * pristine-tar data for gnome-online-accounts_3.49.0.orig.tar.xz * https://deb.li/3ALdg
[19:09] <bandali> awesome! i think we may be experiencing some potentially related weirdness on the launchpad builds tho :-(
[20:53] <KGB-X> gnome-control-center signed tags 1648911 Jeremy Bicha upstream/46_alpha * Upstream version 46~alpha * https://deb.li/jz4I
[20:54] <KGB-X> gnome-control-center pristine-tar 07c45ac Jeremy Bícha gnome-control-center_46~alpha.orig.tar.xz.delta gnome-control-center_46~alpha.orig.tar.xz.id * pristine-tar data for gnome-control-center_46~alpha.orig.tar.xz * https://deb.li/3DnzA
[20:54] <KGB-X> gnome-control-center upstream/latest acbd899 Jeremy Bicha * pushed 410 commits (first 5 follow) * https://deb.li/BADe
[20:54] <KGB-X> gnome-control-center upstream/latest 03f7a6c Hari Rana shell/cc-application.c * about: Set copyright holder * https://deb.li/302s0
[20:54] <KGB-X> gnome-control-center upstream/latest abe6aa3 Automeris naranja panels/privacy/ cc-location-page.c cc-location-page.ui * location-page: Implement the new privacy notice * https://deb.li/dQjz
[20:54] <KGB-X> gnome-control-center upstream/latest e3eb30f Automeris naranja panels/privacy/cc-location-page.ui * location-page: Rename master switch title to "Automatic Device Location" * https://deb.li/31bvs
[20:54] <KGB-X> gnome-control-center upstream/latest ad30771 Hari Rana panels/notifications/cc-app-notifications-dialog.ui * app-notifications: Add width-request * https://deb.li/3prRv
[20:55] <KGB-X> gnome-control-center upstream/latest 1d1f95b Sabri Ünal shell/appdata/ meson.build org.gnome.Settings.appdata.xml.in * appdata: Improve appdata for AppStream 1.0 * https://deb.li/iQBnn