[01:56] <smoser> blackboxsw: sorry. kind of confused by Odd_Bloke comments there.
[01:57] <smoser> oh. i see. you fixed.
[02:08] <bugbuilder> Hi everyone! I'll be very glad if someone could give me an advise, about a weird issue that I having with a cloud-init and a packer template. When I boot the image the first time, using terraform provider openstack and libvirt for local, sometime the cloud-init doesnt start. I check the systemd and said tha the cloud-init is disable but this services was enabled in the image creation.
[02:09] <bugbuilder> This happends randomly. Sometime the same temple provision the VM without problems.
[02:09] <bugbuilder> *template
[02:09] <smoser> bugbuilder: its probably related to ds-identify.
[02:09] <smoser> but you should file a bug and attach cloud-init collect-logs output
[02:10] <smoser> ideally inboth "good" and "bad" cases.
[02:10] <bugbuilder> yep I checked them and in the case when the cloud.init service is disable I dont have any log.
[02:11] <bugbuilder> I'm thinking to put the datasource for openstack to see if the identifier could fix it
[02:11] <smoser> run cloud-init collect-logs
[02:11] <smoser> anad attach the output
[02:11] <bugbuilder> k
[02:11] <smoser> it gets mroe than /var/log/cloud-init.log
[02:13] <bugbuilder> I looking on them.. Let me read them first and I coming back in a bit thank yoy smoser
[02:13] <smoser> sure.then jsut file a bug. attach and you can ping me with a link here.
[02:18] <bugbuilder> I red dmesh and journal without luck.
[02:18] <bugbuilder> *read
[02:18] <bugbuilder> but I found a problem about the DS as you said
[02:19] <bugbuilder> di_report:
[02:19] <bugbuilder>   datasource_list: [  ]
[02:19] <bugbuilder>   # reporting not found result. notfound=disabled.
[02:20] <bugbuilder> Do you think if I create thee datsource for openstack this problem could be disapper?
[02:21] <smoser> iits possible that if you put 'datasource_list: [OpenStack, None]' into /etc/cloud/some.cfg that it will fix the issue.
[02:21] <bugbuilder> also which would be for local develoment
[02:21] <smoser> but you can potentially fix the issue for other people "the right way" (tm)
[02:21] <smoser> er... help fix the issue
[02:21] <smoser> by filing a bug
[02:21] <bugbuilder> sure, how I could do that.
[02:22] <smoser> by filing a bug with that info ;)
[02:22] <bugbuilder> lol
[02:22] <bugbuilder> yeah sure but I dindt know where
[02:22] <smoser> is it ubuntu ?
[02:22] <bugbuilder> Suse
[02:22] <smoser> https://bugs.launchpad.net/cloud-init/+filebug
[02:24] <bugbuilder> let me try the fix, I'll come with news and then I'll fill the report
[02:24]  * smoser has to go afk
[02:24] <smoser> night night
[03:29] <blackboxsw> thanks smoser. yeah I had force pushed the changes. I need to stop doing that so the PR more easily represents the fixes.
[03:39] <smoser> i think force-push to a pr is fine
[07:28] <mkrai_> Hi I am trying to boot a baremetal server in OpenStack with two network, the provisioning is succesful but the node is not reachable. I saw that the instance folder in /var/lib/cloud was not created.
[07:29] <mkrai_> When i try to boot the same server with only network, provisioning is succesful and the node is reachable too. cloud-init does the network configuration properly.
[07:29] <mkrai_> Can someone please help me identify the problem with cloud-init or how to debug this issue?
[07:33] <mkrai_> It seems that the DataSourceConfigDrive is not known to cloud init
[08:02] <mkrai_> smoser, Hi
[08:02] <mkrai_> blackboxsw, portdirect Odd_Bloke rharper Hi, Can you please help?
[08:56] <tribaal> mkrai: most people on this chan are in US timezones. If you can prepare the following it would help them be efficient when they wake up:
[08:56] <tribaal> mkrai: run "cloud-init collect-logs" and upload the result of that command somewhere (this collects the logs as the name implies)
[08:57] <mkrai> tribaal, Ok thanks I will do it now
[09:04] <mkrai> tribaal, I get error when i run this command "IOError: [Errno 2] No such file or directory: '/var/log/cloud-init-output.log'"
[09:04] <mkrai> I have /var/log/cloud-init.log
[09:14] <tribaal> that is interesting - perhaps cloud init is not actually run at boot for some reason
[09:38] <mkrai> tribaal, http://paste.openstack.org/show/787707/
[09:42] <tribaal> looks like it works fine as far as I can tell
[09:43] <tribaal> I'm afraid you'll have to wait for somebody more knowledgeable than myself to come online
[09:43] <mkrai_> tribaal, np thanks for the help though :)
[09:44] <mkrai_> blackboxsw, portdirect Odd_Bloke rharper smoser Here are the logs http://paste.openstack.org/show/787707/
[14:25] <smoser> mkrai__: i think you're hitting
[14:25] <smoser>  https://bugs.launchpad.net/cloud-init/+bug/1801364
[14:26] <smoser> so i would suggest trying https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/
[14:30] <meena> Goneri: your branch is again out of synch?
[14:31] <meena> you gotta rebase against tip
[14:32] <Goneri> I'm rebasing it
[14:32] <Goneri> thanks meena for the notice
[14:43] <Goneri> For the record. I've tested the branch against FreeBSD-10, 11, and 12 yesterday on OpenStack. And it works just fine. I'm in the process to upload all the qcow2, if anyone wants to give them a try.
[14:44] <Goneri> it would be great if the branch could be merged. It has been here for a while, and it resolved several long standing problems.
[14:59] <Goneri> the PR is here, https://github.com/canonical/cloud-init/pull/61
[15:32] <meena> i have tested this on hetzner, and i'm quite  happy with what it does, that is: exactly what it promises to do: it configures the network and renames the device. IPv4 only so far, but it's a start
[15:39] <wolfiepresley> Hello everyone, I have a few questions about a thing I am trying to do but due to my lack of knowledge I am struggling quite a bit. If you have 5-10 minutes it would help a lot maybe. Thank you
[15:42] <smoser> wolfiepresley: well, try to write your question
[15:42] <smoser> and if someone can answer,t hey will
[15:43] <wolfiepresley> Sure :)
[15:46] <wolfiepresley> Been using Amazon Linux inside an AWS Workspaces.
[15:46] <wolfiepresley> create a bundle and assign that bundle to a new workspace.
[15:47] <wolfiepresley> But the whole idea is that the user should not be prompted to enter the password when he executes the command. So I had the idea to edit /etc/sudoers but when the image/workspace is being created it cleans it.
[15:48] <wolfiepresley> Wanted to add something like --  testuser ALL=NOPASSWD: /sbin/openvpn
[15:49] <smoser> well, i dont knwo what is doing cleaning. but that is not somethign that cloud-init control.
[15:49] <smoser> cloud-init's general goal is to not require cleaning
[15:49] <smoser> you can absolutely use user-data to make cloud-init re-add the rules you want.
[15:50] <wolfiepresley> I was thinking if  I can edit the cloud.cfg or cloud.cfg.d add a new file here where at the boot it adds that line to sudoers.d
[15:50] <smoser> or add systemd jobs that did it, or some other way.
[15:51] <smoser>  /var/lib/cloud/per-instance/your-script.sh
[15:51] <smoser> chmod 755 that and it should get run once per instance.
[15:51] <smoser> but if your cleaner deletes it, then there is nothing i can do.
[15:51] <smoser> basically... you can't fight a cleaner that applies its own arbitrary rules.
[15:52] <smoser> it could just as well decide to delete things in /etc/cloud/
[15:53] <wolfiepresley> Here is some info from AWS Workspaces custom bundle documentation
[15:53] <wolfiepresley> https://docs.aws.amazon.com/workspaces/latest/adminguide/create-custom-bundle.html
[15:54] <wolfiepresley> Seems contents from /var/lib/cloud are removed :(
[15:54] <smoser> :q
[15:54] <smoser> well, file a bug. they should not delete /var/lib/cloud/
[15:55] <wolfiepresley> Thing is this happens only when you create the image, if for e.g you have a workspace already built on top of that image/bundle it will not remove its contents.
[15:55] <smoser> all the files in that list have valid reasons to keep them.
[15:56] <smoser> sure.
[15:56] <smoser>  /var/log/amazon/ssm
[15:57] <smoser> funny my initials show up there.
[15:57] <wolfiepresley> :D
[15:57] <smoser> anyway... you can absolutely work around their custom bundle stuff. and do whatever you want.
[15:57] <smoser> but they can later decide to update their custom bundler and screw you
[15:58] <smoser> but i do consider it a bug to delete
[15:58] <smoser> /var/lib/cloud
[15:58] <smoser> because
[15:58] <smoser> a.) cloud-init should manage that correctly
[15:58] <smoser>  (and does)
[15:59] <smoser> b.) there are interfaces with behaviors based on files in that path... so it shoudlnt get cleaned as that breaks cloud-init's promised interfaces.
[16:10] <wolfiepresley> I am not experienced with this at all.. actually I started working on this last week and i've been reading through a lot of stuff but it's a whole mess in my head as you may have realised already. Appreciate you taking the time to write this.
[16:11] <wolfiepresley> To be honest i thought if I edit the /etc/cloud/cloud.cfg
[16:11] <wolfiepresley> openvpn without the password.
[16:15] <Odd_Bloke> Looks like Travis is broken in master ATM because of tag issues.  I'm looking into it.
[16:18] <Odd_Bloke> OK, I think I've addressed it.
[16:19] <Odd_Bloke> I believe the 19.4 tag was pointing at a commit in the proposed branch, which changed when it was squashed.
[16:19] <Odd_Bloke> And the tag needs to be signed, AFAICT, for read-version to be happy with it, so that took a couple of iterations too.
[16:20] <powersj> Odd_Bloke, good to know - is that something we should doc?
[16:40] <chillysurfer> why would cloud-init.service have only an After directive on systemd-networkd-wait-online.service? shouldn't that be a requirement?
[16:41] <smoser> well, systemd-networkd-wait-online.service is obnoxious
[16:42] <smoser> what cloud-init wants to wait for is "all configured networking to be up".
[16:42] <chillysurfer> smoser: but we have no hard requirement for an online network then right?
[16:42] <smoser> but what systemd-networkd-wait-online.service provides is
[16:42] <smoser>  "you have network connectivity".
[16:42] <chillysurfer> otherwise what is the mechanism that says "dont do cloud-init things until we are connected"
[16:42] <chillysurfer> ?
[16:42] <smoser> the difference is that if you intentionally have no network connectivity, or you have no network devices
[16:43] <smoser> then you will not be online, but that is sufficient for cloud-init. it does not have a requirement that there be network.
[16:43] <chillysurfer> smoser: ok so this is basically by design then, not to have a hard requirement on network connectivity?
[16:43] <chillysurfer> ok
[16:43] <chillysurfer> that answers my question
[16:43] <chillysurfer> is it a weird thing and un-cloud-init-like to make that a requirement?
[16:44] <chillysurfer> i don't see _why_ that would be a bad thing to modify, but curious on second opinions
[16:44] <smoser> the use case that I think is completely valid is
[16:44] <smoser>  - take ubuntu cloud image
[16:44] <smoser>  - add a data disk
[16:44] <smoser>  - add a NoCloud datasource
[16:45] <smoser>  - userdata says to do a bunch of stuff (compile maybe) and put output on datadisk
[16:45] <smoser> no network needed, nor desired.
[16:45] <chillysurfer> yeah makes sense
[16:45] <smoser> if you change that to be "you  must have network connectivity", then it doesnt work.
[16:45] <chillysurfer> because at the moment, for instance, cloud-init does *not* require systemd-networkd.service to be up and running
[16:46] <smoser> i really thikn that what cloud-init wants is what systemd-networkd-wait-online.service should provide
[16:46] <chillysurfer> and i think i have a use-case where we absolutely need networking to be up and running before running cloud-init
[16:46] <smoser> what does "online" even mean?  (AOL sound-bite has played ? )
[16:46] <chillysurfer> smoser: able to make network requests..? i think
[16:47] <smoser> on one network interface ? on all of them ?
[16:47] <smoser> ipv4 ipv6 ?
[16:47] <smoser> its not really straight forward
[16:47] <chillysurfer> right i see where you're going with that
[16:47] <chillysurfer> basically i'm working on an issue right now where systemd-networkd.service isn't up and running, and therefore we're not able to contact the cloud fabric. that's an issue (i don't know when that wouldn't be an issue for azure at least..?)
[16:47] <smoser> i am remembering things kind of fuzzy....
[16:48] <smoser> but what cloud-init *wants* is "All configured network interfaces are up."
[16:48] <chillysurfer> smoser: where do you see that *wants* directive?
[16:49] <smoser> oh. thats more of a goal.
[16:49] <smoser> not a reall 'Wants'
[16:49] <chillysurfer> but cloud-init will continue even if network interfaces aren't up, correct?
[16:50] <smoser> you mean if they failed ?
[16:50] <chillysurfer> no not even a failure. just never started
[16:51] <chillysurfer> for instance, cloud-init will continue on it's way even if systemd-networkd.service isn't started
[16:51] <smoser> cloud-init.service should not run until networking is up.
[16:51] <chillysurfer> smoser: i don't see a directive in cloud-init.service that enforces that?
[16:51] <smoser> well,. in ubuntu, cloud-init gets that to happen via netplan apply
[16:51] <smoser> at the local time frame i think
[16:51] <smoser> this is kind of fuzzy, and probasbly isnt perfect
[16:52] <smoser> and i think that is why we have After=systemd-networkd-wait-online.service
[16:52] <chillysurfer> smoser: what runs netplan apply?
[16:52] <chillysurfer> smoser: yeah but After isn't a requirement, only timing
[16:54] <smoser> cloudinit/net/netplan.py: will call netplan generate
[16:54] <Orion]> hi I have a question about cloud-init
[16:54] <smoser> sorry... i have to go. i think i've probably not been terribly helpful
[16:55] <chillysurfer> smoser: you've definitely been very helpful! thanks for the assistance
[16:55] <Orion]> I am using a VPS from a cloud provider on debian 10, and I found that the network configuration by default is /etc/network/interfaces.d/50-cloud-init.cfg
[16:56] <Orion]> cloud init confuses me, I want to set up my networking to support multiple ips
[16:56] <Orion]> is it correct to think cloud init is not relevant to me, and I can remove it's configuration file and create my own
[17:18] <meena> Odd_Bloke: i approved, but that still does nothing in github's eyes: https://github.com/canonical/cloud-init/pull/120 also, your branch needs a rebase
[17:24] <blackboxsw> meena: that UI shows a nice grey ✅
[17:24] <blackboxsw> thanks for the review there. I've updated the PR and waiting on CI to land
[17:25] <wolfiepresley> If I try to edit the cloud.cfg file and add under section -- users -- the following
[17:26] <wolfiepresley>   - name: myuser
[17:26] <wolfiepresley> system: false
[17:28] <wolfiepresley> if some of those field are empty do they still need to be present?
[17:28] <Odd_Bloke> powersj: Yes, we should either doc the tagging requirement and/or adjust tooling.
[17:28] <meena> blackboxsw: it does, now at your review has landed
[17:29] <Odd_Bloke> chillysurfer: AIUI, the only effect that A declaring a Requires on B has is that if A is included in boot, then B will be included as well.
[17:30] <Odd_Bloke> If systemd-networkd-wait-online.service is relevant to cloud-init, then something else should already "Requires" it, so it's included in boot.
[17:30] <Odd_Bloke> If nothing else in boot Requires systemd-networkd-wait-online.service then that _probably_ means that networkd isn't in use on the system, so cloud-init "Requires"ing it would be incorrect.
[17:31] <Odd_Bloke> The Wants=systemd-networkd-wait-online.service is effectively saying "if systemd-networkd-wait-online.service is included in boot, then cloud-init should run after it", which I believe is correct.
[17:32] <chillysurfer> Odd_Bloke: right exactly, but there is no Wants directive, it's `After=systemd-networkd-wait-online.service`
[17:32] <chillysurfer> i would think adding in Wants=systemd-networkd-wait-online.service would be a possible fix to ensuring network is up and running for cloud-init
[17:33] <Odd_Bloke> chillysurfer: Are you seeing that systemd-networkd-wait-online.service isn't running during boot?
[17:33] <chillysurfer> Odd_Bloke: correct
[17:33] <chillysurfer> Odd_Bloke: and i think making it a requirement might alleviate this issue
[17:34] <chillysurfer> like adding it as a Wants
[17:34] <Odd_Bloke> OK, right.
[17:34] <Odd_Bloke> I'm surprised that it isn't already included.
[17:34] <Odd_Bloke> chillysurfer: What release are you looking at?
[17:35] <chillysurfer> 19.2-36-g059d049c-0ubuntu2~18.04.1
[17:35] <chillysurfer> but smoser did bring up a good point. there are cases where a network requirement is a bad thing
[17:35] <blackboxsw> Orion]: depending on the cloud platform, cloud-init does support configuring multiple ip addresses and/or  multiple nics. It all depends on the metadata datasource used. Orion] if you are adding more nics on a platform that doesn't support configuring multiple IPs you could add additional nic configuration in /etc/network/interfaces.d/50-your-additional.cfg  or you can either describe your own network config in
[17:35] <blackboxsw> entirty to cloud-init (and cloud-init will write it out) or you can disable cloud-init network configuration in general by adding a network: {config:disabled} in a file somewhere in /etc/cloud/cloud.cfg.d/*.cfg per https://cloudinit.readthedocs.io/en/latest/topics/network-config.html
[17:37] <blackboxsw> https://github.com/canonical/cloud-init/pull/120 landed thx meena
[17:37] <chillysurfer> Odd_Bloke: i guess i could just add that Wants directive when i think it's necessary
[17:37] <chillysurfer> maybe not a bad idea
[17:39] <Odd_Bloke> chillysurfer: Can you pastebin `systemctl status systemd-networkd-wait-online`, please?  I'm seeing it run in a lxd container locally, so I'm confused as to why it isn't running.
[17:40] <blackboxsw> minor branch to validate CLA signing and fail CI with a message about reading hacking doc if the PR author hasn't already signed the CLA.
[17:40] <blackboxsw> https://github.com/canonical/cloud-init/pull/124
[17:41] <chillysurfer> Odd_Bloke: i'll save the pastebin as it's easy to describe. it runs sometimes but takes a reboot for it to run
[17:41] <chillysurfer> Odd_Bloke: here's what i'm seeing.... 1) first boot, cloud-init tries to provision with no networking as systemd-networkd is not running 2) something reboots the machine 3) networking comes up, but provisioning is already completed with errors
[17:42] <chillysurfer> Odd_Bloke: so during the 1 phase above, networking just isn't up, including systemd-networkd-wait-online. and it's causing issues
[17:42] <Odd_Bloke> systemd-networkd not running sounds like something is very broken, TBH.  I'm not sure that's a cloud-init issue.
[17:42] <chillysurfer> Odd_Bloke: my thoughts to remedy this include making cloud-init have a hard requirement
[17:42] <chillysurfer> Odd_Bloke: no doubt, i completely agree with you. this was simply a workaround to tell cloud-init that it shouldn't run if systemd-networkd.service isn't running
[17:42] <chillysurfer> it's a workaround for a much larger issue, i agree
[17:44] <Odd_Bloke> chillysurfer: I guess what I'm confused about is how you've ended up with a system with this behaviour.  Because I assume this isn't an issue in the default behaviour of bionic on Azure?
[17:44] <chillysurfer> Odd_Bloke: correct. custom image
[17:51] <rharper> chillysurfer: at generator time, we can't know if systemd-networkd is present; and it won't be running;  cloud-init local runs *before* networking on purpose;  I don't understand the exact scenario;  why is there no networking (missing nics?, not connected?) and how would cloud-init know that there isn't any networking available?
[17:53] <chillysurfer> rharper: why is there no networking? great question. that's the root of the problem, i wanted to add a unit directive as a workaround to the problem in the interim
[17:53] <ananke> I was wondering if any of you seed cloud-init configs with packer. the goal is to customize existing AMIs and automate their build process. I can't seem to find much in terms of examples of such workflow
[17:54] <chillysurfer> rharper: for some reason, networking isn't up for the 2-3 minutes on first boot so provisioning has issues. and then _something_ reboots the vm (don't know what). and then when it comes back up, networking works but provisioning is already complete (with issues)
[17:58] <rharper> chillysurfer: having a journal would be helpful
[17:59] <rharper> chillysurfer: do you want cloud-init to run
[17:59] <rharper> and without knowing why networking isn't available, it's not easy to drop-in some logic to check for such a state and have cloud-init skip running this boot
[17:59] <chillysurfer> rharper: totally understand. i've combed through it pretty thoroughly. nothing that really jumps out as to why networking doesn't come up for some time
[18:00] <rharper> chillysurfer: I'm happy to look at the journal if you can share
[18:00] <chillysurfer> rharper: yep totally understand
[18:00] <chillysurfer> rharper: i'll have to check with a few people before i could share it, thanks for the offer!
[18:00] <rharper> sure, understood
[18:00] <chillysurfer> rharper: thanks for your willingness to help! super appreciated
[18:00] <rharper> https://github.com/coreos/docs/issues/519
[18:01] <rharper> chillysurfer: I suggest adding this to the image; it dumps way more debugging for networkd
[18:01] <chillysurfer> rharper: oh wow that's super helpful actually
[18:01] <chillysurfer> thank you
[18:21] <blackboxsw> rharper: https://github.com/canonical/cloud-init/pull/123 for ubuntu/devel so I can upload to focal today if possible
[18:21] <blackboxsw> the 19.4 release
[18:22] <blackboxsw> also Travis validation of CLA is passing CI in https://github.com/canonical/cloud-init/pull/124/files
[18:36] <blackboxsw> thanks for the review on ubuntu/devel smoser. True on adding RbxCloud to templates
[18:47] <blackboxsw> done
[19:17] <Odd_Bloke> blackboxsw: https://github.com/canonical/cloud-init/pull/124 reviewed
[19:19] <Odd_Bloke> 28 contributors from 29 domains?
[19:33] <Odd_Bloke> powersj: rharper: blackboxsw: https://github.com/canonical/cloud-init/pull/125 is the first workflow automation piece; it will auto-close PRs after 21 days of inactivity (it first marks a PR as stale after 14 days).
[19:34] <blackboxsw> nice!
[19:34] <blackboxsw> addressed 124
[20:03] <Odd_Bloke> powersj: blackboxsw: meena: I've responded to the comment that you either made or reacted on: https://github.com/canonical/cloud-init/pull/125#issuecomment-567190235
[20:11] <meena> Odd_Bloke: okay, fair.
[20:11] <blackboxsw> Odd_Bloke: responded with an inline question/comment. I'm +1 regardless of your stance
[20:12] <Odd_Bloke> blackboxsw: Yes, I think we do, let me update.
[20:13] <meena> rharper: would you like to take a look at this again? https://github.com/canonical/cloud-init/pull/53
[20:17] <Odd_Bloke> blackboxsw: Updated.
[20:17] <meena> blackboxsw / Odd_Bloke: would you like to take a look at this…
[20:17] <meena> https://github.com/canonical/cloud-init/pull/69
[20:18] <blackboxsw> approved Odd_Bloke
[20:18] <blackboxsw> looking meena
[20:36]  * blackboxsw will run through openstack once on that changeset meena, I'm +1 otherwise, but I don't think it'll actually trigger due to our current code structure in DatasourceOpenStack
[20:36] <blackboxsw> it could possibly in Hetzner.
[20:37] <meena> blackboxsw: it does; that's how i test Goneri's changeset :P
[20:37] <blackboxsw> hrm, then I'll have to get through that live test to to re-educate myself about how that'd work across reboots (without cloud-init clean)
[20:39] <blackboxsw> community notice: Upload to Ubuntu Focal (20.04) of cloud-init 19.4 complete  [ubuntu/focal-proposed] cloud-init 19.4-1-g8c96cbc1-0ubuntu1 (Accepted)
[21:09] <Odd_Bloke> powersj: This PR brought to you by having to read the cc_ssh docs repeatedly over the past few days: https://github.com/canonical/cloud-init/pull/126 :p
[21:09] <powersj> hahahaha!
[21:10] <powersj> Odd_Bloke, was this from a grep on 'ssh'?
[21:21] <Odd_Bloke> powersj: `ait -s '[^-_/.a-zA-Z]ssh[^-/_a-zA-Z]' cloudinit doc/rtd`
[21:21] <Odd_Bloke> (Where `ait` is `ag --ignore tests`.)
[21:38] <meena> i keep forgetting that hetzner is overriding my system_info/distro
[21:44] <Odd_Bloke> meena: Have you attempted to escalate that with them?
[21:49] <Goneri> I've rebuilt my FreeBSD images, they go from 10 to 12: e.g: https://virt-lightning.org/images/freebsd-11/disk.qcow2
[21:54] <Odd_Bloke> https://www.youtube.com/watch?v=KOO5S4vxi0o
[21:56] <Goneri> Odd_Bloke, you made me reconsider a lot of things in my life.
[22:00] <meena> Odd_Bloke: nah, i have considered overriding vendor-data, however ;)
[22:01] <meena> for one: FreeBSD doesn't need a rng seed; cuz it's got an implementation that doesn't suck
[22:01] <meena> (sorry Linux folk)
[22:01] <meena> However, i don't know how to do that!
[22:01]  * meena blames powersj
[22:02] <powersj> lol
[22:04] <meena> https://bugs.launchpad.net/cloud-init/+bug/1837530 not sure if my reading comprehension is enough to get anything out of this bug report
[22:04] <powersj> the merging doc needs to be updated, but I'll be honestly I don't understand it all enough to do the updates
[22:05] <powersj> generally user data always wins versus vendor data is about all I can somewhat intelligently say
[22:05] <meena> so, given my vendor-data: https://bugs.launchpad.net/cloud-init/+bug/1855170 maybe it's enough that I say: system_info: distro: freebsd ; and be done with it
[22:10] <Odd_Bloke> meena: That's certainly worth a try.
[22:10] <Odd_Bloke> If it doesn't work, then disabling all vendor data should do it.
[22:11] <meena> Odd_Bloke: that's not documented EITHER!
[22:27] <meena> oh my gosh, it's like a dream
[22:30] <meena> runcmd: section seems to have been ignored tho :(
[22:33] <Odd_Bloke> meena: `alias man=grep -R` <-- fixed the docs problem
[22:35] <meena> Odd_Bloke: lookit, my personal wisdom is, read the source, but STILL.
[22:35] <meena> so, almost midnight, time to give up.
[22:35] <meena> Goneri: found a "bug"
[22:36] <meena> Goneri: https://gist.github.com/8fb0a17238b4264cfa8a37093017c7d1 can you find it too? ;)
[22:37] <meena> so, bed time.
[22:41] <meena> I've commented on https://github.com/canonical/cloud-init/pull/61 with my experience report ;)
[22:41] <meena> next up, finding out why runcmd doesn't work…
[22:41] <meena> or, sleep???
[22:44] <meena> anyway, i'm now paying hetzner double the money for the privilege of developing cloud-init
[22:44] <meena> (almost 6€)
[22:59] <meena> whoa, y'all have useful reviews comments! (it's much easier to give those useful reviews when you know the codebase better i guess;)
[23:38] <Goneri> meena, I suspect the ifconfig_vtnet0 line to come from the ephemeral dhcp call
[23:38] <Goneri> meena, could you send me the cloud metadata?


[00:25] <Trevinho> robru: hey, do you have any clue why this is back: https://requests.ci-train.ubuntu.com/#/ticket/1419?
[00:25] <Trevinho> I think britney thinking that unity is not building in s390x, where it never got built ever
[00:25] <Trevinho> but, in xenial this thing was ignored
[00:27] <robru> Trevinho: i guess the hints need to be updated. Poke pitti about that, for now just tell qa to override it and put it in the queue anyway
[00:28] <Trevinho> robru: do you know who is in charge right now?
[00:35] <robru> Trevinho: for qa? I usually see ToyKeeper at this time, not sure officially though
[00:36] <robru> Trevinho: i think of you ping "ubuntu-qa" it gets them all
[00:36] <Trevinho> robru: ok, as we don't generally need the QA ACK, so I just need someone who can push the "publish" button.
[00:36] <robru> Trevinho: oh right, sorry.
[00:36] <ToyKeeper> If it needs QA but the automated signoff can't pass for bogus reasons, I can get it into the QA queue.  But it sounds like that's irrelevant?
[00:37] <robru> Trevinho: you should be able to publish yourself if there's no packaging changes
[00:37] <robru> ToyKeeper: sorry, yakkety only landing
[00:37] <Trevinho> let me check
[00:38] <Trevinho> well there are some pkg changes
[00:39] <Trevinho> eh, no... not allowed
[00:39] <Trevinho> I need some ubuntu dev
[00:51] <robru> Trevinho: sorry, i can't do it. My go-to guys are EOD by now. Try looking at ubuntu-core-dev for timezone appropriate people, or wait a few hours for sil2100 to wake up
[00:51] <Trevinho> robru: yeah, no worries... We can wait till tomorrow morning
[06:26] <Saviq> Mirv, hey, any idea why mir 0.22 would still be unavailable in yakkety-proposed https://launchpad.net/ubuntu/+source/mir/ ?
[06:33] <Saviq> abeato, for whatever reason mir 0.22 isn't published in proposed yet
[06:33] <Saviq> ↑↑
[06:33] <abeato> Saviq, noted, thanks
[06:34] <abeato> Mirv, we need that to build aethercast too see error ^^
[06:34] <abeato> (that = mir 0.22)
[06:44] <Saviq> ah Mirv is away, forgot, we'll need to wait for sil2100
[07:05] <Mirv>  Saviq hmm
[07:05] <Mirv> Saviq: I'm away?
[07:06] <Saviq> Mirv, aren't you? :D
[07:06] <Mirv> Saviq: no, why would I be? :D I will be in two weeks though
[07:06] <Saviq> Mirv, yeah I saw that in the calendar and didn't pay attention to dates ;)
[07:07] <Mirv> Saviq: isn't that " 0.22.1+16.04.20160516.2-0ubuntu2 " "proposed (main)" what you asked?
[07:07] <Saviq> Mirv, sure, except:
[07:07] <Saviq> # apt-cache policy libmirclient9
[07:07] <Saviq> libmirclient9:
[07:07] <Saviq>   Installed: (none)
[07:07] <Saviq>   Candidate: 0.21.0+16.04.20160330-0ubuntu3
[07:07] <Saviq>   Version table:
[07:07] <Saviq>      0.21.0+16.04.20160330-0ubuntu3 500
[07:07] <Saviq>         500 http://archive.ubuntu.com/ubuntu yakkety/main amd64 Packages
[07:07] <Saviq> and yes I have proposed enabled
[07:08] <Mirv> Saviq: but, regardless, it's not in release pocket, and it's not "really" in proposed pocket either since it has new binaries that are in https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0&queue_text=mir
[07:08] <Mirv> Saviq: so yes it's in proposed but it's not in proposed
[07:08] <Mirv> (source is, binaries aren't)
[07:08] <Saviq> Mirv, right, that sounds about right
[07:08] <Mirv> Saviq: abeato: so you need to ping your friendliest member of https://launchpad.net/~ubuntu-archive/+members
[07:09]  * Saviq → #ubuntu-devel
[07:10]  * abeato follows
[07:11] <Saviq> this is going to be nasty, mir will need an archive admin for basically every release...
[07:13] <Mirv> Saviq: incorrect actually
[07:14] <Mirv> Saviq: or it will, but by trainguard. I mean, train bypasses binary new queue
[07:14] <Saviq> ah
[07:14] <Saviq> right
[07:14] <Mirv> so it's manual requirement that the publisher needs to consults archive admin, and it has always been so
[07:15] <Mirv> which is boring regardless of which way archive admins need to be troubled with it
[07:15] <Mirv> but needs to be done as long as mir continues to break its stuff instead of being stable ;)
[07:15] <Mirv> 1.0!
[07:56] <Saviq> gaaah how long's it gonna take mir to get published in proposd after being binNEWed?
[07:57]  * Saviq got tricked into trio-ifying silo 58 ;(
[07:57] <Saviq> it'll be fine, they said
[07:57] <Saviq> it's best like that, they said
[08:01] <Saviq> bollocks
[08:52] <Saviq> abeato, you can rebuild, mir got published
[08:53] <abeato> Saviq, already did, thanks :)
[08:53] <abeato> seems to be building just fine
[10:20] <Saviq> rvr, jibel, https://requests.ci-train.ubuntu.com/#/ticket/1381 is good to go... again..., any chance of putting it back on the top of the queue?
[10:20] <rvr> Saviq: Sure
[10:40] <Ads20000> Uh, I don't really know how CI Train works, but it's failed to build unity8 for the Stable Phone Overlay PPA which is a bit of a problem since I use that (though I haven't loaded unity8 successfully yet anyway). I'm guessing someone's on it (but it's not in known issues)?
[10:44] <Saviq> Ads20000, why do you say that? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=unity8&field.status_filter=published&field.series_filter=
[10:44] <Saviq> it's only "failed" for architectures we don't support (yet) because of missing dependencies
[10:44]  * ogra_ wonders what he means by "since i use that" ...
[10:45] <Saviq> I suppose the overlay
[10:45] <ogra_> there are thousands of phones out there using it too :) ... (but definitely not as deb packages)
[10:45] <Ads20000> Sorry, I meant that I use the PPA on my desktop, but I haven't actually used Unity 8 yet because I couldn't log into it (though I also couldn't report a bug on it because 1 package wasn't installing (can't remember what it was))
[10:45] <ogra_> urgh
[10:46] <ogra_> dont do that
[10:46] <Ads20000> Don't do what, run the PPA? Didn't help that OMG Ubuntu recommended it, maybe I could ask him to edit the article?
[10:46] <ogra_> many of these packages are solely designed for working in image based upgrades ...
[10:47] <Ads20000> I'm confused, they're DEBs right? For using on a standard APT system?
[10:47] <ogra_> there wont be config transitions etc ... and there will be things they expect tht you dont have on a PC ... just use xenial or yakkety and the unity8 from the archive
[10:48] <Ads20000> If I may ask, what's the PPA actually for then?
[10:48] <ogra_> Ads20000, they are debs designed to be used in context of image based updates
[10:48] <ogra_> images and their deltas are built from them
[10:48]  * Mirv haz Meizu Pro 5
[10:48] <ogra_> they are usually not installed directly unless someone develops on a specific package
[10:48]  * Mirv loves it, it's awesome, really
[10:49]  * ogra_ throws envious looks at Mirv  ... mine is on the truck ... still waiting
[10:49] <Ads20000> Hmm, ogra_ could you get someone to edit the PPA description then to tell normal users not to add it? :P
[10:49] <Mirv> I moved my /home/phablet over from Bq already too
[10:49] <Mirv> camera and hotspot didn't work at first but then I noticed my first visit to System Settings hadn't told me that there's a system upgrade. both worked after that.
[10:49] <Ads20000> But OK, I suppose that makes sense, cheers, will ppa-purge now :)
[10:50] <ogra_> Ads20000, i dont know who owns it ... perhaps sil2100 can
[10:50] <Mirv> also, default was 2G network, but now I've 4G and currently ~20Mbit/s :)
[10:50] <ogra_> crazy talk !
[10:52] <Ads20000> Also, ogra_, I'm guessing the unity8 package in Xenial/Yakkety will be more out-of-date but you're saying that's OK? I can still file bugs against it?
[10:52] <ogra_> xenial -> a little since it must be SRUed ... yakkety is on the same version as the PPA usually
[10:52] <ogra_> everything landing lands in all thee
[10:53] <Saviq> ... since yesterday ...
[10:53] <ogra_> heh, yeah
[10:53] <Saviq> so this is why overlay was really needed on xenial even to get the latest and greatest
[10:53] <Saviq> but yeah, starting today yakkety should be on par
[10:55] <Ads20000> OK cool sounds good :)
[10:55] <Ads20000> Thanks for the help :)
[10:55] <ogra_> np :)
[10:56] <jin_> jibel: ping
[10:56] <jin_> jibel: Hello, there is a request from Telegram: https://requests.ci-train.ubuntu.com/#/ticket/1441
[10:57] <jin_> jibel: need your approval on pushing this into the dashboard you have :)
[10:58] <sil2100> What's up?
[10:59] <ogra_> sil2100, Ads20000 asked if you can change the overlay PPA description to tell people oit is not for general use
[10:59] <jin_> davmor2: hey buddy
[10:59] <ogra_> he enabled it on the PC to test unity8
[10:59] <jin_> davmor2: need your team's support on this version:
[10:59] <jin_> https://drive.google.com/open?id=1y8XmPqIv-0rkp8bTXYT5Lo_8jhrdF2X2mcsymTENnjY
[11:00] <jin_> davmor2: oh sorry, this one is the correct one:
[11:00] <jin_> https://requests.ci-train.ubuntu.com/#/ticket/1441
[11:00] <jin_> davmor2: the ticket #1441 for Telegram
[11:00] <jin_> :)
[11:00] <davmor2> jin_: hey dude nice okay I'll keep an eye out for it.
[11:01] <sil2100> Ads20000, ogra_: ok, let me change the description, but I thought the name itself was obvious enough ;) It's the Stable PHONE Overlay, not desktop ;)
[11:01] <jin_> davmor2: awesome!
[11:01] <ogra_> haha, yeah
[11:03] <Ads20000> sil2100: I think the problem was that it seemed like one could use the PPA for getting the stable phone packages onto the desktop and it's implied that the existence of the PPA means that Xenial/Yakkety package aren't up-do-date enough
[11:03] <Ads20000> but a description change would fix that impression :)
[11:20] <rvr> abeato: Hi
[11:21] <rvr> abeato: Would it be possible to merge silos 29 and 5?
[11:21] <abeato> rvr, not really, one of them is not a dual(trio) landing
[11:21] <rvr> Ah, I see
[11:25] <Ads20000> Oh, Saviq, I've only just realised what you were saying. I can't install unity8 from the PPA because it depends on unity8-common which depends on unity-scopes-impl-12 which isn't in the PPA or in Yakkety
[11:26] <Saviq> Ads20000, oh you're using yakkety?
[11:28] <Ads20000> Yes, is that an issue?
[11:28] <Ads20000> (Saviq)
[11:28] <Saviq> Ads20000, no, there's just no yakkety packages in the overlay PPA at all, there's a big queue of packages in proposed that will make yakkety work for you again
[11:29] <Saviq> Ads20000, unity-plugin-scopes provides unity-scopes-impl-12 (it's virtual) - https://launchpad.net/ubuntu/+source/unity-scopes-shell
[11:29] <Saviq> Ads20000, we're in a bit of a transition period right now, you'd either need to enable proposed on your machine or wait a day or two for us to resolve all this
[11:30] <Ads20000> Saviq I have yakkety-proposed enabled
[11:31] <Saviq> Ads20000, as you can see it's waiting to build https://launchpad.net/ubuntu/+source/unity-scopes-shell/0.5.7+16.04.20160505-0ubuntu2
[11:32] <Saviq> Ads20000, so as said, we're in a bit of a transition - we're working on it - give it a day please :)
[11:33] <Ads20000> Saviq, OK that's fine, I don't understand as much as I thought about how this all works! ogra_ suggested that it's best just to use the packages in the Yakkety repo though, would you agree? :)
[11:33] <rvr> kdub: Hi. We need more info about silo 69. Can you include the changelog in the description? This is a good example: https://requests.ci-train.ubuntu.com/#/ticket/1420
[11:34] <kdub> rvr, sure
[11:34] <Saviq> Ads20000, yes, but just give us a day as we complete the transition :)
[11:36] <Ads20000> OK cool, cheers :)
[11:36] <kdub> rvr, done
[11:36] <rvr> kdub: Great, thanks
[11:37] <sil2100> No-change rebuilds for the win :|
[11:37] <sil2100> Saviq: do you know if pstolowski or anyone else is on the yakkety unity-scopes-api failure?
[11:38] <Saviq> sil2100, just pung them
[11:38] <sil2100> Saviq: big thanks!
[11:53] <rvr> bzoltan: ping
[11:54] <bzoltan> rvr:  hello there, what can I do for you?
[11:54] <rvr> bzoltan: I'm checking https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1582339
[11:54] <bzoltan> rvr:  and?
[11:54] <rvr> bzoltan: Not a big issue. But cannot reproduce in stable or rc-proposed
[11:54] <rvr> I see that the section is correctly colored
[11:55] <bzoltan> rvr:  because that bug was introduced by our staging branch
[11:55] <rvr> Ah
[11:55] <rvr> So never hit the images ?
[11:56] <t1mp> rvr: no, only in our staging
[11:56] <rvr> t1mp: Cool. Mistery solved :)
[11:57] <bzoltan> rvr: as t1mp said... we introduced a regression :) but we have fixed it before it could land.
[11:58] <rvr> bzoltan: Understood
[12:05] <kdub> rvr, with silo 69, i had to rebuild a package (not a content change, but still had to rebuild) not sure if that card has to go back to square zero or not :/
[12:05] <rvr> kdub: No problem, I will remove the new card
[12:05] <rvr> Everytime a silo is rebuilt, a new card appears
[12:06] <rvr> The prioritization in trello is manual
[12:06] <kdub> rvr, thanks
[12:24] <ChrisTownsend> trainguards: Hi!  Are britney runs known to be taking a very loooong time right now?  I did a rebuild yesteday due to the triple landings and the britney run is still going: https://requests.ci-train.ubuntu.com/#/ticket/1425
[12:28] <kdub> ChrisTownsend, I noted that they were taking longer than normal yesterday as well
[12:29] <ChrisTownsend> kdub: Ok, good to know I'm not the only one.  But my run has been going on for almost 14 hours or so.
[12:29] <Mirv> ChrisTownsend: I'm not 100% sure. there has been a huge queue for yakkety http://autopkgtest.ubuntu.com/running.shtml but I don't see yours there, plus the ppc64el libertine at https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-031/excuses.html seems suspicious too. our only option if somethings gets truly stuck is to ping pitti on #ubuntu-devel
[12:29] <kdub> ChrisTownsend, yeah, it took most of the day to sign off on my silo
[12:30] <ChrisTownsend> Mirv: Ok, I'll follow up w/ pitti.  Thanks
[12:30] <ChrisTownsend> kdub: ok
[12:43] <Mirv> sil2100: jibel: I upgraded my turbo to rc-proposed, now SIM unlock does not prompt when booting the phone, I need to select it from menu. sounds familiar, and under which such a bug should be filed?
[12:50] <jibel> Mirv, you mean there is no SIM unlock prompt or it doesn't show up when you press the unlock SIM button in the indicator
[12:50] <jibel> ?
[12:50] <jibel> there is a bug for both IIRC
[12:51] <jibel> davmor2, ^ do you know?
[12:51] <pstolowski> sil2100, hey, since apparently we should do triple landings now, can enable & build for yakety in silo 47 without starting from scratch?
[12:52] <davmor2> Mirv: there is a bug for it I think don't know if it is specific to turbo let me have a dig
[12:55] <davmor2> Mirv: meh I can't put my hand on it right now I'll dig it out later
[12:57] <Mirv> jibel: there's no SIM unlock prompt during bootup, but there is if I press the button from indicator
[12:57] <Mirv> davmor2: ok, that's a regression from the OTA-10.2 my turbo booted with before upgrading
[12:58] <jibel> Mirv, I'm pretty sure I saw a bug report but cannot find it
[12:59] <davmor2> jibel: yeah there is but I can't find it either, I'm not sure if it is device specific so filed there or against ofono/system-settings/network indicator
[13:01] <Saviq> sil2100, can you please recycle the regression here https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-058/excuses.html thanks
[13:01] <rvr> tsdgeos: ping
[13:02] <Saviq> mterry, oh you're here now, too, can you recycle ↑ please
[13:02]  * mterry dusts off his recycling fingers
[13:03] <mterry> done
[13:03] <tsdgeos> rvr: hi
[13:04] <rvr> tsdgeos: Hi
[13:04] <rvr> tsdgeos: I'm testing #1421293
[13:05] <rvr> tsdgeos: Can you tell me whether this is right? https://trello-attachments.s3.amazonaws.com/53fc6641728df958a48bfbe1/573c2103599129a715a9863d/322d159220c9ee3f8f9f0d87eb507142/screenshot20160520_140023336.png
[13:06] <rvr> tsdgeos: Well, that's an screenshot with arale
[13:06] <tsdgeos> rvr: not sure what i'm looking at :D
[13:06] <rvr> tsdgeos: I'm trying to understand what you did :D https://launchpadlibrarian.net/197431959/icon.png
[13:07] <tsdgeos> rvr: it's with 25px and 50px as grid unity
[13:07] <tsdgeos> -y
[13:07] <tsdgeos> but i am not sure the bug was actually fixed
[13:07] <tsdgeos> ltinkl: ping
[13:08] <tsdgeos> ltinkl: do you remember the branch https://code.launchpad.net/~lukas-kde/ubuntu-ui-toolkit/staging-fix-icon-svg-image-loading ? it was marked as fixing https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1421293 but i remember some discussion about it not really fixing the bug?
[13:11] <ltinkl> tsdgeos, it should be fixed
[13:11] <ltinkl> tsdgeos, I used your testcase
[13:11] <Mirv> jibel: davmor2: sil2100: I couldn't find a bug, so I filed bug #1584049 (not sure to which package it would suite best)
[13:14] <davmor2> Mirv: I thought this was going to be your stable phone so why take it off stable????
[13:15] <tsdgeos> rvr: ltinkl: ok let me try to remember what this was about :D
[13:15] <Mirv> davmor2: because I have strong belief that OTA-11 is near ready :) I already changed the channel back to stable to stay on this particular image until OTA-11 is ready
[13:15] <Mirv> davmor2: and because OTA-10 had the Mir performance bug(s)
[13:15] <davmor2> Mirv: so you lied then ;)
[13:15] <rvr> tsdgeos: lol, ok
[13:16] <Mirv> davmor2: if I said something about staying on stable channel yes I lied :) too tempting...
[13:17] <davmor2> Mirv: you didn't say stable channel you said this is my new stable phone so I can use krillin for testing :D
[13:19]  * ogra_ finds it funny that the "gold" actually doesnt look so "gold" ... it is more somewhere between champagne and copper i think
[13:20] <Mirv> ogra_: indeed, which is a good thing. bzoltan and zsombi didn't order it since they tought it's too gold, but it's actually quite mute and mostly gray with some tints as you mentioned
[13:20] <ogra_> yeah
[13:23] <tsdgeos> rvr: yeah the bug is not fixed
[13:24] <rvr> tsdgeos: :-(
[13:24] <tsdgeos> rvr: the bug is basically that the first image looks "correct" at any GRID_UNIT_PX value
[13:24] <tsdgeos> while the second does not
[13:24] <tsdgeos> you need to add extra code (i.e. the third) for it to look correct
[13:25] <Mirv> davmor2: I will use the krillin to test any offered fix for that bug :)
[13:25] <Mirv> my turbo is back to ro mode after editing the channel.ini back to stable
[13:26] <tsdgeos> rvr: this is with different GRID_UNIT_PX for me http://i.imgur.com/EBb8PEU.png
[13:26] <davmor2> Mirv: why edit channel.ini all you had to do was system-image-cli --switch <channel_url>
[13:26] <rvr> tsdgeos: So fixed, it should like the third window, right?
[13:27] <tsdgeos> rvr: the second image should look like the third in all GRID_UNIT_PX
[13:27] <tsdgeos> and not only in the right one
[13:27] <rvr> tsdgeos: Ack
[13:28] <tsdgeos> t1mp: i edited the bug, hope it's easier to understand now
[13:29] <rvr> bzoltan: So, bug #1421293 is not fixed
[13:31] <jhodapp> sil2100, ping
[13:32] <Mirv> davmor2: I didn't remember that one and this one also easy, one line change, back to ro mode, check for updates in system settings
[13:38] <dobey> go go gadget mir already
[13:39] <Saviq> sil2100, jibel, https://requests.ci-train.ubuntu.com/#/ticket/1442 - this can probably skip QA and will unblock some things in yakkety
[13:42] <dobey> Saviq: how will that unblock things?
[13:42] <Saviq> dobey, there's things waiting to build in proposed because of it FTBFSing
[13:42] <Saviq> https://launchpad.net/ubuntu/+source/unity-scopes-api/1.0.5+16.04.20160413.1-0ubuntu2
[13:45] <dobey> the big thing still seems to be mir
[13:45] <Saviq> seb128, since I excluded you earlier today, can I ask you to ♻ https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-058/excuses.html
[13:45] <Saviq> dobey, mir's in proposed already
[13:46] <dobey> Saviq: yes, but lots of things seem to be uninstallable
[13:47] <seb128> Saviq, done
[13:47] <Saviq> seb128, thanks
[13:47] <Saviq> dobey, yeah, and part of everything being uninstallable was unity-scopes-api not building
[13:47] <Saviq> now it will so we'll just get one small step further
[13:48] <bzoltan> t1mp: or better here
[13:48] <t1mp> ah, right
[13:48] <bzoltan> t1mp:  yes rvr I mean
[13:50] <t1mp> rvr, tsdgeos: is https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1421293 not fixed?
[13:50] <t1mp> I reviewed a branch with a test case that fixed it, let me see
[13:50] <t1mp> well the two attached branches are the same, just different merge target
[13:51] <tsdgeos> t1mp: i think you may have not understood what the bug was about
[13:51] <t1mp> it adds a test case in tst_icons that passes, and visual inspection showed the correct results too
[13:51] <tsdgeos> since the bug is not against svg
[13:51] <tsdgeos> and the branches where for svg improvements
[13:51] <tsdgeos> as far as i remember
[13:52] <t1mp> hmm, right, the branch name mentions svg
[13:52] <t1mp> but the test case is for png, and I checked that
[13:52] <t1mp> I didn't think of svg
[13:52] <t1mp> hmm
[13:52] <ChrisTownsend> ubuntu-qa: Hi!  Could we keep the current place on the queue for https://requests.ci-train.ubuntu.com/#/ticket/1425 since I had to rebuild for the triple landing?
[13:52] <t1mp> from the bug report: "For the SVG the width grows as the units.gu grow, but for the JPEG it does not and one has to manually add code to maitain the aspect ratio."
[13:53] <tsdgeos> t1mp: see the updated description
[13:53] <t1mp> so, the test verifies that the aspect ration is maintained, right?
[13:53] <tsdgeos> yes, i'm not complaining about sVG doing the right thing
[13:53] <tsdgeos> i'm complaining JPEG/PNG doesn't
[13:53] <tsdgeos> t1mp: which test?
[13:53] <t1mp> see l. 227 on https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk-fix-icon-svg-image-loading/+merge/286585
[13:54] <t1mp> and the test function directly under it
[13:54] <davmor2> ChrisTownsend: yeah don't worry we are just deleting new tickets if they are dupes
[13:54] <ChrisTownsend> davmor2: Ok, cool, thanks
[13:54] <Mirv> ogra_: can you play back videos you take with camera? for me it says it can't and also all thumbnails are just placeholder image (both videos I took with Bq and new ones)
[13:55] <ogra_> havent tried
[13:55] <tsdgeos> t1mp: that test is broken, needs to be testing for different grid units too
[13:55] <tsdgeos> incidentally on the default gu value on the desktop it works
[13:55] <tsdgeos> i've no idea why
[13:57] <Mirv> it might be this  .cache/gstreamer-1.0/registry.arm.bin problem I read somewhere about
[13:58] <t1mp> tsdgeos: http://i.imgur.com/EBb8PEU.png indeed looks wrong
[13:58] <ogra_> Mirv, works fine
[13:58] <jibel> ChrisTownsend, sure
[13:58] <t1mp> tsdgeos: okay, so then the bug is not fixed
[13:58] <bzoltan> rvr: did I miss something?
[13:58] <tsdgeos> t1mp: yeah :/
[13:58] <t1mp> ltinkl: will you take the bug again?
[13:58] <rvr> bzoltan: tsdgeos confirms that the bug is not fixed
[13:58] <Mirv> ogra_: ok, good. I think it's something they've struggled with after OTA-10
[13:59] <t1mp> bzoltan: it appears that the bug was only fixed for the specific GU setting that was used for testing..
[13:59] <bzoltan> rvr:  would you please not fail the silo yet?
[13:59] <tsdgeos> rvr: yeah failing the silo for that makes no sense
[13:59] <rvr> bzoltan: I tested everything else and is good
[13:59] <t1mp> rvr, bzoltan: that bug is only low priority, we thought it was nice that is was fixed as a side-effect of other fixes, but I don't think we need to fail a silo for that. Just remove the bug
[13:59] <ogra_> Mirv, well, i'm on 10.2
[13:59] <jibel> Saviq, +1 to skip QA
[13:59] <tsdgeos> rvr: i mean the branch was not fixing that really, was fixing something else and i guess my bad description of the bug made people think it was actually fixed
[13:59] <bzoltan> rvr: let's keep the bug open and pass the silo
[14:00] <jibel> Saviq, (for silo 39)
[14:00] <Saviq> yup
[14:01] <rvr> tsdgeos: But if the test is wrong, and the code doesn't fix the problem...
[14:01] <rvr> Remove the branch
[14:01] <bzoltan> rvr: it is not a branch
[14:01] <tsdgeos> rvr: the code does fix the problem
[14:01] <tsdgeos> just not *this* problem
[14:01] <tsdgeos> it fixes the problem it wanted to fix
[14:01] <rvr> Hmm
[14:01] <t1mp> rvr: the branch fixed another, critical, bug. But it did not fix this low-priority bug that we thought it also fixed as a side-effect
[14:02] <rvr> I see
[14:02] <rvr> Ok, then remove the bug from the list and I'll aprove it
[14:02] <bzoltan> rvr:  and regardless of anything... the silo does not bring regression and it does fix OTA bugs... + the issue in hand does fix one case... multiply MRs can fix the same bug.
[14:03] <bzoltan> rvr: but that MR does fix one case of that bug... the way to handle it is to reopen the bug. Would not be the first case that the same bug is fixed multply time.
[14:04] <bzoltan> rvr: tsdgeos: t1mp: There is no "Fixes partially LP: #123456" syntax ... so fixing a corner case requires the same syntax in the changelogs
[14:04] <bzoltan> good job ubot5
[14:04] <rvr> lol
[14:05] <davmor2> Mirv: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1583944
[14:05] <t1mp> bzoltan: it does not properly fix this bug, so we can remove that line from the changelog and keep the bug open
[14:05] <oSoMoN> rvr, all merge requests approved for https://trello.com/c/b1JNG7NQ/3239-1387-ubuntu-landing-053-webbrowser-app-osomon
[14:05] <rvr> oSoMoN: Thanks
[14:05] <rvr> bzoltan: Approved
[14:05] <bzoltan> rvr: thanks
[14:06] <t1mp> ltinkl: do you want to take another shot at fixing that bug?
[14:06] <bzoltan> t1mp: let's let the CI machine now mark that bug and reopen... I do not remove changelog entry from the changelog without removing the code what it refers to
[14:07] <t1mp> okay
[14:07] <bzoltan> t1mp: pushing a new rev of the landing branch would hold back like 24 hours
[14:07] <ltinkl> t1mp, not really, if I don't have to :p
[14:07] <t1mp> ltinkl: who decides whether you have to? ;)
[14:07] <t1mp> ok, I'll keep it as unassigned for now then.
[14:12] <rvr> ChrisTownsend: Hi!
[14:12] <ChrisTownsend> rvr: Hey!
[14:13] <rvr> ChrisTownsend: Can you add the changelog to the libertine silo description? Like this one: https://requests.ci-train.ubuntu.com/#/ticket/1420
[14:13] <ChrisTownsend> rvr: Sure!  Is that something I should every time from now on?
[14:14] <rvr> ChrisTownsend: Yes, please. It is easier for us.
[14:14] <ChrisTownsend> rvr: Sure, no problem.
[14:17] <ChrisTownsend> rvr: Ok, updated the ticket.
[14:17] <ChrisTownsend> rvr: Let me know if that is what you are looking for.
[14:18] <rvr> ChrisTownsend: Yeah, that's fine. Thanks!
[14:18] <ChrisTownsend> rvr: Ok, cool
[15:18] <oSoMoN> sil2100, Mirv: can one of you guys please publish silo 53 on my behalf? it’s got packaging changes (which were approved by kenvandine)
[15:25] <sil2100> oSoMoN: looking!
[15:27] <sil2100> oSoMoN: done!
[15:29] <oSoMoN> sil2100, thanks!
[15:33] <oSoMoN> davmor2, I see that you moved the trello card for silo 53 to under testing, you can skip that and move it to passed, as it was validated by jibel earlier this morning and it is currently being published
[15:33] <jibel> davmor2, it's done
[15:34] <davmor2> jibel: shocking ;)
[15:36] <davmor2> oSoMoN: I did stumble across something fun in that silo, on frieza if you open system-indicator select desktop mode, then open the browser if you highlight one of the link scroll up and down the page it then triggers the mouse over dialogue at the bottom of the page with the url link in it :)
[15:38] <oSoMoN> davmor2, isn’t that the expected behaviour? if the mouse cursor is over a hyperlink, its target URL will be displayed in the overlay
[15:39] <davmor2> oSoMoN: there is no mouse cursor long press on a link and then hit cancel, then scroll up and down, ie long press the shop link, cancel that dialogue, then scroll up and down and you get the mouse hover dialogue
[15:41] <oSoMoN> davmor2, ah, got it! I guess this is still considered as a mouseover event by the web engine
[15:41] <oSoMoN> even though there is no actual cursor visible on screen
[15:42] <davmor2> oSoMoN: that's my assumption but it only happen after the scroll which was the thing that threw me :)
[15:42] <oSoMoN> davmor2, not sure that would qualify as a bug, more like a "weird behaviour", but feel free to file a bug against webbrowser-app anyway
[15:43] <davmor2> oSoMoN: I have no issue with it just a fun thing you'll note at no time did I say bug just weird :)
[16:00] <oSoMoN> davmor2, fair enough :)
[16:37] <Mirv> ogra_: jibel: davmor2: I managed to fix my video thumbnailing problem by removing the registry in .cache/gstreamer-1.0/ a couple of times (and then removing unity-thumbnailer "failures" database to get thumbnails back), but I wouldn't say the problem, discussed on some mailing list (search your mail for gstreamer registry), would be completely fixed for OTA-10 -> OTA-11 upgraders and might cause seriou
[16:37] <Mirv> s trouble for at least turbo users (since it seems it affects the fastest device the most)
[16:38] <Mirv> davmor2: s/my video thumbnailing problem/my video thumbnailing and playback of any video problem/
[16:39] <ogra_> thumbnails behave fine here
[16:44] <Mirv> ogra_: it might be because of my data transfer from Bq, hopefully no-one will encounter it then in normal situation anymore. although you also haven't upgraded to rc-proposed.
[16:45] <ogra_> yeah, i usually hand-copy my data to not carry over unwanted dot-dirs and caches
[16:45] <ogra_> a lot more initial effort, but i can be sure my device is clean
[16:46] <Mirv> maybe popey's buds should be updated to --exclude .cache/gstreamer-1.0 :) (well, really, without smiley too)
[16:49] <Mirv> davmor2: bug #1583944 seems not related to my bug #1584049 since the unlocking from indicator works fine, while it does not according to the bug linked from the former
[16:51] <davmor2> hmmm Mirv so I have sim pin unlock on mine at least on initial boot let me try a reboot
[16:52] <Mirv> I have now booted the rc-proposed several times and it always goes to the phone unlock screen without showing SIM unlock screen. but there's that 1580908 filed indeed that my bug was made duplicate of now.
[17:24] <bzoltan> Mirv:  would you help me to publish and merge the silo19 please?
[17:25] <bzoltan> Mirv:  I am sure you can do it on your huuuuuge screened Pro5 ...
[17:26] <Mirv> bzoltan: well if you ask _that_ nicely :) yes it's huge!
[17:26] <bzoltan> Mirv: i wonder how to get my dirty hand on one of them
[17:27] <Mirv> bzoltan: I do manual triple landing as discussed on mailing lists earlier today
[17:27] <bzoltan> Mirv:  OK
[17:29] <robru> Mirv: i forgot to mention, you must force merge after manual triple, it won't auto merge because it will expect xenial package in xenial archive, not overlay.
[17:29] <Mirv> robru: oh, ok, thanks!
[17:30] <Mirv> bzoltan: so done as you can see vivid+xenial https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?batch=75&memo=300&start=300 and yakkety (building) at bottom of https://lists.canonical.com/archives/yakkety-changes/2016-May/thread.html
[17:31] <bzoltan> Mirv:  thank you!
[17:32] <Mirv> davmor2: I'll keep your hilights on another channel untouched so I remember them on another day :)
[17:32] <davmor2> hahahaha
[18:26] <dobey> anyone know anything about http://pastebin.ubuntu.com/16530018/ in yakkety?
[19:20] <dobey> mcfly?
[19:24] <robru> dobey: no idea
[19:29] <dobey> hmm, i wish the excuses page would show 'Queued' instead of 'Test In Progress' for tests that are queued but not yet running
[19:33] <robru> dobey: file a bug against britney
[20:15] <dobey> haha
[20:15] <dobey> well i guess one 'good' thing about the yakkety migration fiasco is now all the autopkgtests are flagged as 'always failed'
[20:30] <Saviq> ;)


[12:02] <TJ-> Any ideas why (iwlwifi) would fail to locate its firmware during boot, but does after a "modprobe -r  && modprobe" later? I confirmed one of the firmware files it asks for is in the initrd in case it was an early-boot issue.


[11:16] -queuebot:#ubuntu-ci-eng- juliank, https://bileto.ubuntu.com/#/ticket/4950 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[11:59] -queuebot:#ubuntu-ci-eng- juliank, https://bileto.ubuntu.com/#/ticket/4950 Preparing packages


[00:03] <mup> PR snapd#9326 closed: tests: fix for basic20 test running on external backend and rpi <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9326>
[01:59] <mup> PR snapd#9362 closed: tests: skip nested images pre-configuration by default <Run nested> <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9362>
[06:20] <mup> PR snapd#9360 closed: tests: make gadget-reseal more robust <Run nested> <Simple 😃> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9360>
[06:35] <mborzecki> morning
[06:37] <mvo> good morning mborzecki
[06:37] <mborzecki> mvo: hey
[06:38] <mborzecki> mvo: so are we out of the woods yet?
[06:39] <mvo> mborzecki: yeah, I think it's time for a (small) bottle of champagne
[06:39] <mvo> mborzecki: resealing+pcr4 just landed
[06:40] <mvo> mborzecki: so we should be good
[06:40] <mup> PR snapd#9277 closed: secboot: add boot manager profile to pcr protection profile <Run nested> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9277>
[06:40] <mup> PR snapd#9356 closed: sysconfig,o/devicestate: mv DisableNoCloud to DisableAfterLocalDatasourcesRun <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9356>
[06:40] <mvo> mborzecki: I guess the next step is to test gadget udpate with the pc branch 20/beta/edition3 for real
[06:40] <mvo> mborzecki: and if that works it's really time to celebrate
[06:41] <mvo> mborzecki: I will branch 2.47 now
[06:41] <mborzecki> yay
[06:41] <mvo> mborzecki: afaict all is merged and the only missing pr needs a samuele review first
[06:41] <mborzecki> mvo: i'll work on the fix for updating structures without partitions on an encrypted device
[06:42] <mvo> mborzecki: sounds great, thanks for this
[07:01] <pstolowski> morning
[07:02] <mvo> good morning pstolowski
[07:02] <mvo> pstolowski: do we happen to have a forum topic for disk-space awareness that I could link to?
[07:02] <pstolowski> mvo: i don't think so
[07:03] <pstolowski> mvo: i could publish the notes i sent to degville
[07:04] <mvo> pstolowski: not urgent if degville publishes them I can link to that
[07:04] <mvo> pstolowski: mostly wondering because I'm working on 2.47 release notes
[07:05] <degville> mvo / pstolowski: the disk awareness doc is here: https://forum.snapcraft.io/t/disk-space-awareness/20007
[07:07] <pstolowski> degville: nice, thank you!
[07:07] <degville> np!
[07:07] <pstolowski> degville: there is a mistake there re snapd version (it says 2.37+ )
[07:08] <degville> pstolowski: ah, thanks. I'll fix it now.
[07:08] <mvo> degville: \o/ thank you! I updated the snapd roadmap page now
[07:10] <zyga> good morning :)
[07:10] <zyga> I patched all the profiles last night and ran a test before EODing
[07:10] <zyga> I see that lxd and gdbserver failed, let me look at those
[07:12] <zyga> let's debug those
[07:12] <zyga> mvo: is 2.47 ready now?
[07:13] <zyga> I saw ian and samuele fight some issues last night
[07:13] <mvo> good morning zyga
[07:13] <mvo> zyga: yeah, I'm on 2.47~pre1 right now
[07:13] <zyga> I slept for 5 hours but I'm okay surprisingly
[07:13] <zyga> cool, fingers crossed no more surprises
[07:15] <mup> PR snapd#9361 closed: tests/lib/cl_check.py: use python3 compatible code <Simple 😃> <Skip spread> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9361>
[07:27] <zyga> ah missing snap-gdbserver-shim
[07:27] <zyga> fixed
[07:27] <zyga> let's look at lxd now
[07:35] <mborzecki> zyga: can you take a loot at https://github.com/snapcore/snapd/pull/9364 ? you like them python bits ;)
[07:35] <mup> PR #9364: tests/lib/cla_check: default to Python 3, tweaks, formatting <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9364>
[07:35] <zyga> sure
[07:35] <zyga> looking
[07:35] <mborzecki> zyga: fwiw, do you remember what distro is used for the workers/
[07:35] <mup> PR snapd#9364 opened: tests/lib/cla_check: default to Python 3, tweaks, formatting <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9364>
[07:36] <zyga> re-formatted with black I presume
[07:36] <mborzecki> zyga: yeah, the trademark () style it uses
[07:36] <zyga> +1
[07:37] <mborzecki> zyga: are you in power to install python3-launchpadlib in the containers used to run the cla workflow?
[07:37] <zyga> on mine, yes
[07:37] <zyga> one moment
[07:39] <mborzecki> zyga: who manages the other workers? that workflow runs on self-hosted (whatver that means)
[07:39] <zyga> mborzecki: claudio
[07:39] <zyga> installing now
[07:39] <mborzecki> zyga: cool, i'll ping him
[07:40] <zyga> mborzecki: self hosted are workers which are managed buy us, not github
[07:40] <mborzecki> zyga: right, i though that maybe is runs/manages some of those for us
[07:40] <zyga> that's two nodes from me and one from claudio
[07:40] <zyga> it's self-managed
[07:40] <zyga> it will be ready in a few minutes
[07:41] <mborzecki> zyga: cool, thank you
[07:55] <zyga> mborzecki: done, all workers under my control are ready
[07:56] <mborzecki> zyga: thanks
[07:56] <zyga> mborzecki: as for self-hosted workers
[07:56] <zyga> mborzecki: we could tweak actions to run cla checks on a pi easily
[07:56] <zyga> mborzecki: no need for spread or root access
[07:56] <zyga> mborzecki: just a small container with python and git
[07:57] <zyga> mborzecki: so that's entirely viable
[07:58] <zyga> nothing is running now
[07:58] <zyga> rebooting for kernel update
[07:59] <zyga> workers will be back in a minute or two
[08:00] <zyga> ok, fixed the profile bit affecting lxd
[08:00] <zyga> it's quite curious
[08:00] <zyga> MS_BIND really matters for MS_REMOUNT
[08:00] <zyga> testing again
[08:00] <zyga> all of main should pass now
[08:00] <zyga> I'll do core next and then add the feature flag I need for safety
[08:01] <zyga> and that should be it :)
[08:01] <zyga> mvo: I'll start working on enabling raa today as we talked
[08:09] <mborzecki> hm built a uc20 image and it gets stuck in the efi shell
[08:09] <mborzecki> pretty sure i'm using the same ovmf that worked the last time
[08:14] <zyga> Removing snapd (2.45.1ubuntu0.2) ...
[08:14] <zyga> Failed to execute operation: Connection timed out
[08:14] <zyga> inside containers
[08:15] <mup> PR snapd#9365 opened: release: 2.47~pre1 <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9365>
[08:18] <zyga> \o/
[08:24] <zyga> lxd passed
[08:24] <zyga> regression and core are in progress
[08:47] <zyga> afk, lucy needs me
[08:47] <zyga> both core and regression passed
[08:47] <zyga> just the feature to restore old behavior in case we need it
[08:48] <zyga> but that's after wife is back in a moment
[08:48] <zyga> o/
[08:48] <pedronis> mvo: I made a comment in https://github.com/snapcore/snapd/pull/9293
[08:48] <mup> PR #9293: snap: auto-import will not try to auto-create users on managed devices <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9293>
[08:48] <mvo> pedronis: \o/
[08:48] <mvo> pedronis: sounds sensible
[08:49] <pedronis> mvo: sorry, it's a bit more work, but maybe put us in a better spot
[08:49] <mvo> pedronis: yeah, totally agreed, I like this
[09:07] <mborzecki> duh, console-conf drops a backtrace when i try to configure the device
[09:08] <zyga-mbp> mborzecki physical or vm?
[09:08] <mborzecki> or snapd isn't quite up yet https://paste.ubuntu.com/p/3RZY7vmC4m/
[09:08] <mborzecki> vm
[09:09] <zyga-mbp> well, console conf should handle that error
[09:09] <zyga-mbp> and probably just retry
[09:09] <zyga-mbp> maybe we just got restarted
[09:34] <mvo> mborzecki: please file a bug and we need to put it onto the foundations radar
[09:35] <mborzecki> mvo: investigating still a bit, maybe it's snapd that's tarting slow
[09:36] <mborzecki> mvo: and seriously takes a bit of work to get a debug shell on the system :/
[09:36] <mborzecki> mvo: but i guess you already know the pain :)
[09:36] <mvo> mborzecki: yes, but it's okay to just file a bug
[09:37] <mborzecki> uhh, mark boot successful fails, `cannot identify kernel snap with bootloader grub: cannot read dangling symlink kernel.efi`
[09:37] <mvo> mborzecki: and not dive too deep, if it's really a matter of retrying. but sorry, in a meeting so only 20% of my brain is available
[09:38] <mvo> mborzecki: this is not the issue that ian identified the other day that snap-bootstrap older versions eat modeenv keys?
[09:38] <mborzecki> yeah, omg, need to repack the kernel
[09:38] <mborzecki> ehh
[09:39] <mborzecki> i suppose i have what i wanted now anyway
[09:40] <mborzecki> mvo: a random thought, it'd be great to have at least a debug version of the snapd snap which has `systemd.debug-shell=1 dangerous` baked in
[09:43] <mvo> mborzecki: yeah, I was wondering something similar - and snapd.debug=1 too :)
[09:44] <mvo> mborzecki: maybe we should have this as part of the +testkeys or a similar new build-tag?
[09:48] <zyga> re :)
[10:36] <zyga> I've updated mount-ns test to cope with the new tmpfs
[11:22] <zyga> now added the feature flag
[11:22] <zyga> now for some tests
[11:28] <zyga> brb
[11:55] <zyga> re
[12:08] <ijohnson> mborzecki: imho the proper way to set systemd.debug-shell=1 dangerous for tests is to make gadget specified kernel cmdlines work, then when we already repack the gadget we can set the extra cmdlines from there
[12:09] <mborzecki> ijohnson: well, i'm using https://github.com/snapcore/snapd/commit/a1ec67e26bc5fde9ef645bcc8d6e127345cee344 for now ;)
[12:09] <mborzecki> ijohnson: but yeah, i'd prefer the gadget way
[12:19] <mborzecki> login.ubuntu.com is down?
[12:19] <mborzecki> cannot create users in a UC20 vm
[12:20] <zyga> WFM
[12:22] <mborzecki> ehh, dropped too many modules when repacking the kernel
[12:26] <mup> PR snapd#9366 opened:  gadget: resolve device mapper devices for fallback device lookup <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9366>
[12:27] <pedronis> zyga: any news on google:ubuntu-16.04-64:tests/main/lxd:snapd_cgroup_neither ?
[12:27] <zyga> pedronis: oh? is that broken?
[12:27] <zyga> I ran it today several times
[12:28] <pedronis> it failed here: https://github.com/snapcore/snapd/pull/9270/checks?check_run_id=1123940072
[12:28] <mup> PR #9270: wrappers, systemd: allow empty root dir and conditionally do not pass --root to systemctl <Run nested> <Services ⚙> <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9270>
[12:28] <zyga> let me look
[12:29] <zyga> ah, wait, is that the issue we discussed recently
[12:29] <zyga> I remember now,
[12:29] <cmatsuoka> zyga: I had multiple errors in that test yesterday
[12:29] <zyga> it's weird, I did see the failure messages but in my case the test ultimately passed (it was slow though)
[12:30] <zyga> I'll check with stgraber about it and re-check with -shell-after, to see if it really passed for me
[12:39] <pstolowski> pedronis: there is no api to append to zip in Go... but gess what, there is an old juju package from rogpeppe to do this.. https://godoc.org/github.com/juju/zip#Reader.Append
[12:39] <pedronis> pstolowski: mmh
[12:39] <pstolowski> pedronis: it's a fork of stdlib though ...
[12:39] <pstolowski> and old
[12:40] <pedronis> pstolowski: we need to chat again
[12:40] <pstolowski> for context: https://groups.google.com/g/golang-dev/c/ZSubqlF2G4k?pli=1
[12:40] <pstolowski> and https://github.com/golang/go/issues/15626
[12:40] <pstolowski> it got nowwhere in stdlib of go
[12:46] <pedronis> pstolowski: I also I was confused about something
[12:46] <pedronis> pstolowski: anyway let's chat again
[12:46] <pstolowski> pedronis: ok, now/later?
[12:47] <pedronis> pstolowski: as you prefer, but not a lot of time before standup
[12:47] <pstolowski> pedronis: ok, after then
[13:01] <mup> PR snapd#9364 closed: tests/lib/cla_check: default to Python 3, tweaks, formatting <Simple 😃> <Skip spread> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9364>
[14:01] <mborzecki> hmm, maybe we still need to improve error handling in nested prepare: https://paste.ubuntu.com/p/FBBRKSKBGH/
[14:01] <ijohnson> huh
[14:01] <ijohnson> if the snap command is available why would it be connection refused talking to the socket
[14:02] <ijohnson> I guess sudo snap wait system seed.loaded in the nested_retry_until_success with a much shorter timeout on that
[14:06] <mborzecki> ijohnson: could it be that this ran after the socket was created by system, but before snapd.service started listening (or the service started)?
[14:07] <ijohnson> mborzecki: but I thought that was the whole point of socket activation
[14:08] <ijohnson> is that the stuff sent on the socket gets queued and "saved" so that when snapd is ready and starts listening using systemd's fd we just get what was sent before snapd finished starting
[14:10] <mup> Bug #1887153 changed: Installing network-manager drops the network <Snappy:Invalid> <snappy-hwe-snaps:New> <https://launchpad.net/bugs/1887153>
[14:13] <mup> Bug #1887153 opened: Installing network-manager drops the network <Snappy:Invalid> <snappy-hwe-snaps:New> <https://launchpad.net/bugs/1887153>
[14:19] <mup> Bug #1887153 changed: Installing network-manager drops the network <Snappy:Invalid> <snappy-hwe-snaps:New> <https://launchpad.net/bugs/1887153>
[14:51]  * cachio lunch
[15:27] <mup> PR snapd#9365 closed: release: 2.47~pre1 <Simple 😃> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9365>
[15:47] <mup> PR snapd#9367 opened: tests: misc nested changes <Run nested> <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9367>
[15:47] <ijohnson> hmm does anybody remember the version of snapd we supported parallel installs of classic snaps?
[15:51] <ijohnson> degville: when you have time could you review my update to https://forum.snapcraft.io/t/parallel-installs/7679 mentioning classic parallel snap support in 2.43+ ?
[15:52] <ijohnson> hopefully I didn't botch it too badly :-)
[15:53] <degville> ijohnson: yes, of course! Looks great - thanks for updating it.
[15:53] <ijohnson> thanks
[16:00] <zyga> woot, new test passes
[16:21] <zyga> a few more variants to cover everything
[16:21] <zyga> I'll go make tea
[16:21] <zyga> I like days like this
[16:21] <zyga> quiet focus
[16:43] <cachio> mvo, 2.47 is comming today, right?
[16:54] <zyga> -debug time
[17:22] <ijohnson> cachio: could you look at my 9364 again, it seems my change to the debug: section for each suite didn't take when the nested tests failed, so I force pushed a different change which should work now I think
[17:23] <cachio> ijohnson|lunch, sure
[17:23] <ijohnson|lunch> thanks
[17:24] <cachio> ijohnson|lunch, it is already merged
[17:24] <ijohnson|lunch> cachio: sorry I meant 9367
[17:24] <cachio> ijohnson|lunch, hehe, ok
[17:49] <mvo> cachio: it's already in beta - at least the snapd snap
[17:50] <mvo> cachio: systemd is yet again hold in the review queue
[17:50] <cachio> mvo, ok, I'll start with snapd, thnanks
[17:51] <mvo> cachio: great, thank you
[17:51]  * zyga starts to prepare commits
[18:57] <zyga> ok, one more case fixed
[18:57] <zyga> this test acts as extra documentation
[19:11] <zyga> still some failures on some systems
[19:17] <zyga> centos/fedora/amazon
[19:18] <zyga> and core
[19:18] <zyga> let's dig at the classic set first
[19:18] <mup> PR snapcraft#3289 opened: build providers: fix issues running on Windows <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3289>
[19:19] <zyga> but hey 29 / 40 passed :)
[19:27] <cmatsuoka> ijohnson: did you try to build and install an edge system recently?
[19:27] <ijohnson> cmatsuoka: yes, many
[19:27] <ijohnson> cmatsuoka: let me read your mind
[19:27] <ijohnson> cmatsuoka: it's broken isn't it?
[19:27] <ijohnson> :-)
[19:27] <cmatsuoka> ijohnson: hum, I just tried it and it failed to install
[19:27] <cmatsuoka> ah ok
[19:28] <ijohnson> the issue is that we need a kernel snap respin
[19:28] <ijohnson> ubuntu-core-initramfs was updated with new snap-bootstrap
[19:28] <ijohnson> but the kernel snap has not been rebuilt yet
[19:28] <cmatsuoka> ah I see
[19:28] <ijohnson> so edge is currently broken
[19:28] <cmatsuoka> ah I thought it was published already
[19:28] <cmatsuoka> ok
[19:29] <ijohnson> not yet
[19:30]  * zyga takes the dog out
[19:31] <cmatsuoka> my idea was to build a edge image with maciek's gadget update snapd branch and try it with the edition3 gadget
[19:31] <cmatsuoka> and see if it reseals correctly
[19:32] <ijohnson> yeah you'll need to repack the initramfs with the new version of ubuntu-core-initramfs
[19:33] <cmatsuoka> do we have any estimate on when the kernel snap will be ready?
[19:33] <ijohnson> no idea
[19:43] <zyga> okay
[19:44] <zyga> back and looking at the debug prompt
[19:48] <zyga> huh
[19:48] <zyga> looks like real byg
[19:50] <zyga> printf debug time
[20:06] <zyga> mmm
[20:22] <cachio> ijohnson, cmatsuoka I found something really insteresting about the issue on kvm
[20:22] <cachio> if I use the host system = debian 9
[20:23] <cachio> no reboots
[20:23] <cmatsuoka> oh
[20:23] <cmatsuoka> that's interesting
[20:23] <cachio> the only diff is that on debian 9 I coundt make tpm work
[20:23] <zyga> ok, interesting
[20:23] <zyga> debugging
[20:23] <cachio> I need to take a look to that
[20:23] <zyga> but looks like forced host tools
[20:24] <zyga> but why, maybe some silly bug
[20:24] <cachio> but tmp does not affect on the reboots
[20:24] <zyga> anyway, thank for integration tests
[20:24] <zyga> I'll know on the next cycle
[20:24] <cachio> I tested ubuntu without tmp and ti reboots
[20:25] <cachio> so perhaps a solution for us is to replace ubuntu focal by debian 9
[20:25] <zyga> cachio: debian 9 has really old qemu
[20:25] <zyga> perhaps it doesn't do something fancy enough
[20:25] <cachio> zyga, I am gonna try usign the same qemu on focal
[20:25] <zyga> or doesn't interact with recent security mitigations
[20:26] <cachio> zyga, both things could be the problem
[20:27] <ijohnson> cachio: but if you can't make tpm work with debian then it seems not useful since we need tpm
[20:27] <cachio> zyga, I'll try with debian sid
[20:27] <cachio> ijohnson, that qemu does not support tpm emulation
[20:27] <ijohnson> cachio: right but my point is that we need nested vm's with tpm to test uc20
[20:28] <cachio> ijohnson, yes yes agre
[20:28] <ijohnson> and afaik the reboots only happen with tpm
[20:28] <cachio> ijohnson, no
[20:28] <ijohnson> but yes anyways very interesting point about using debian 9
[20:28] <cachio> ijohnson, reboots happen when we use ovmf
[20:28] <cachio> independently if we use tpm
[20:29] <cachio> I tried removing tpm and the reboots still happen
[20:29] <ijohnson> cachio: ah I see
[20:29] <cachio> ijohnson, I'll try now with debian sid
[20:30] <cachio> it should support tpm by software
[20:30] <cachio> if sid fails the problem is in qemu/kvm version used
[20:32] <ijohnson> Yeah good find nonetheless
[20:32] <cmatsuoka> sid has qemu 5.1 I believe
[20:34] <mup> PR snapcraft#3290 opened: build providers: unified provider refactoring for provider setup <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3290>
[20:34] <cachio> I am creating a new image to support virtualization on sid
[20:34] <cachio> let see
[20:39] <zyga> ah
[20:39] <zyga> what is /etc/sysconfig/snapd:SNAP_REEXEC=0
[20:39]  * zyga looks
[20:41] <zyga> ah
[20:41] <zyga> packaging/fedora/snapd.spec:echo
[20:41] <zyga> why?
[20:42] <zyga> at least that explains it
[20:43] <zyga> the test needs adjusting
[20:58] <zyga> if this passes the next error is on core
[20:59] <zyga> I'll keep pushing, open the PR and go to sleep
[20:59] <zyga> but I may be a bit tired tomorrow
[21:04] <mup> PR snapcraft#3289 closed: build providers: fix issues running on Windows <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3289>
[21:04] <zyga> fedora passed
[21:04] <zyga> ok, core
[21:08] <zyga> need to stretch back
[21:08] <zyga> brb
[21:16] <zyga> back with water,
[21:16] <zyga> core is rebooting
[21:16] <zyga> I'll know soon
[21:20] <zyga> ah
[21:20] <zyga> hh
[21:20] <zyga> ok, weird
[21:20] <zyga> let's check
[21:20] <zyga> I think the test has a mistake
[21:25] <cachio> ijohnson, cmatsuoka, zyga fails on debian sid
[21:25] <cachio> it reboots
[21:25] <zyga> mmm
[21:25] <cachio> so the qemu version
[21:26] <cachio> I need to find a version with supports tpm and no reboots
[21:26] <cmatsuoka> is it using kvm or just software qemu?
[21:26] <cachio> kvm
[21:27] <cmatsuoka> if using kvm it should depend on the kernel too
[21:27] <cachio> cmatsuoka, in tha tpast I tried with a very old kernel
[21:27] <cachio> and it rebooted
[21:28] <cachio> an old kernel which supported kvm
[21:28] <cachio> I think I should find a version of qemu which works
[21:30] <zyga> I think we should ask some qemu people
[21:33] <cmatsuoka> our case is very specific even for qemu people (nested with ovmf)
[21:34] <cmatsuoka> the last time I asked some kvm engineers they said they never worked with that specific scenario :|
[21:53] <cachio> cmatsuoka,just ran in xenial and no reboots
[21:53] <cachio> qemu 2.5
[21:54] <cmatsuoka> hum
[21:54] <cmatsuoka> and does it work with tpm?
[21:54] <cachio> no
[21:55] <cachio> now I'' try to find which version works with tpm
[21:55] <cachio> I nee dto go now
[21:55] <cachio> I'll continue after I am back
[21:55] <cachio> need to buy some stuff
[21:57] <zyga> figured it out
[21:57] <zyga> and documented
[21:57] <zyga> man so many sharp edges
[21:58] <zyga> restarting another run
[21:58] <zyga> all systems now
[22:11] <zyga> ok
[22:11] <zyga> I bail
[22:11] <zyga> tomorrow
[22:11] <zyga> see you all


  This is *SO* exciting!  You are part of HISTORY!" ;-)
[15:50] <yano> "just think you don't have to dist-upgrade for another 2 years!"
[15:57] <jrgifford> thafreak: and why weren't you on the s3 mirrors? :)
[15:57] <thafreak> these were throw away VM's in a computer lab...
[15:58] <canthus13> thafreak: Shoulda given them a 64k leased line to work with. :)
[15:58] <jrgifford> and why didn't you set up a caching proxy? :p
[15:58] <thafreak> jrgifford: didn't think about it being release day until everyone was complaining, and then I didn't think to change mirrors
[15:59] <jrgifford> thafreak: fair enough
[15:59] <thafreak> meh, the final was a disaster anyway
[15:59] <thafreak> i tried to make large portions of it easy with scripts, so that we could do more things as part of the final
[16:00] <thafreak> but that just added complexity when things didn't work right
[16:02] <thafreak> all in all, i'm not at all happy with how this course turned out


[00:06] <travisgonzales23> hey anybody here?
[16:20] <bkerensa> slangasek: Do you know why if I run "gpg -d F1384F1F.signed-by.SOMEID.asc  | gpg --import
[16:20] <bkerensa> " it fails saying I need a passphrase but does not prompt me for such
[16:21] <slangasek> no
[16:21] <slangasek> do you have gpg set up to use a key agent, or not?
[16:21] <bkerensa> I have no idea ^
[16:22] <bkerensa> Im assuming not
[16:22] <slangasek> if you didn't set it up to, then you don't
[17:43] <bkerensa> good morning zenlinux
[17:57] <bkerensa> good morning nathwill
[17:58] <nathwill> morning bkerensa, how goes?
[17:58] <bkerensa> tired
[17:58] <bkerensa> >.<
[17:58] <bkerensa> really wanna run and get starbucks but I got fedex and ups coming so yeah >.<
[18:18] <nathwill> blkperl, so no one expressed a preference for either the 16th or the 23rd. what works best for y'all?
[18:27] <bkerensa> kees: http://seattle.toorcon.org/ do you go?
[18:28] <kees> bkerensa: defcon is enough for me. :)
[18:28] <kees> I've heard it's really good though
[18:29] <bkerensa> yeah
[18:29] <bkerensa> DefCon is to far south :P and too expensive
[18:30] <sbeattie> too vegas in august
[18:30] <bkerensa> :D
[18:37] <tgm4883> whats wrong with vegas in august?
[18:39] <bkerensa> hah
[18:40] <nathwill> that isn't wrong with vegas every other part of the year?
[18:43] <bkerensa> nathwill: well all summer in vegas imho is not fun... Have you ever been in the dessert with a hangover? its horrible :P
[18:43] <bkerensa> its on level with being in Oakland with a hangover
[18:44] <nathwill> anywhere with a hangover is horrible...
[18:44] <sbeattie> nathwill: vegas in august double-downs on the misery that is vegas, at least to this sometimes-mistaken-for-a-canuckistani.
[18:44] <bkerensa> ;p
[18:44] <nathwill> at least it's not reno ... vegas does have that going for it.
[18:46] <bkerensa> Reno atleast is surrounded by mountains capped with snow and rivers
[18:46] <bkerensa> :D
[18:53] <MarkDude> OMG Fedora is STILL fighting over Beefy Miracle name
[18:53] <MarkDude> its incredible
[18:54] <bkerensa> you guys need a dictator
[18:58] <MarkDude> We may have some
[18:58]  * MarkDude will fight them
[18:59] <MarkDude> At least when Mark S says sumthin' its over done and no time is wasted
[18:59] <MarkDude> Its a cartoon hotdog
[19:00] <bkerensa> MarkDude: Did you come to the closing party at UDS? I cannot remember
[19:00] <bkerensa> >.<
[19:00] <bkerensa> that night was foggy
[19:02] <MarkDude> Yes
[19:02] <MarkDude> I took pics of you
[19:02] <nathwill> so why would people still be fighting? i don't understand
[19:02] <MarkDude> You got foggy after that South American booze we found
[19:02] <nathwill> it's a vote. people voted. it's done
[19:02] <MarkDude> Good question nathwill
[19:02] <bkerensa> MarkDude: oh thats right... I remember dancing with uhh Bethany :)
[19:03] <bkerensa> MarkDude: So after the party I was all the way out on International and the East 20's
[19:03]  * MarkDude was tryoing to explain that he has spent time on far stupider pissing contests than names
[19:03] <MarkDude> Yes sketchyville
[19:03] <bkerensa> Heh
[19:03] <MarkDude> Good for findi9ng both crack AND crakhoes
[19:03] <bkerensa> yeah all the stores had bullet proof vault windows
[19:03] <bkerensa> :D
[19:07] <MarkDude> Damn, this whole naming thing is going to take some time. This sucks - we are losing all sorts of man hours due to this
[19:08] <sbeattie> new name: "Bikeshed Miracle"
[19:08] <bkerensa> :D
[19:08] <bkerensa> "Beefy Mess"
[19:08] <nathwill> lol @ sbeattie
[19:10] <MarkDude> lol
[19:10] <MarkDude> that was my 1st response
[19:10]  * MarkDude said please look at relevant site bikeshed.org
[19:10] <MarkDude> And I vote fot eh shed to be painted Blue, with hotdogs on it
[19:29] <MarkDude> Wow, I just got kickbanned for talking about naming process in Fedora-social
[19:29] <MarkDude> By evilbob
[19:29] <MarkDude> That is AWESOME
[19:29] <nathwill> evilbob did something evil?
[19:30]  * MarkDude had folks asking about him at UDS
[19:30] <MarkDude> :D
[19:30] <MarkDude> Yes
[19:30]  * MarkDude thinks he got mad when I asked if he had pets
[19:30] <MarkDude> And are they known as EvilCat, EvilDog, etc
[19:30] <nathwill> aha
[19:31] <nathwill> yes, evilnathwill would've kickbanned you as well ;)
[19:31] <MarkDude> And then we got into the freakin cartoon hotdog talks
[19:31] <MarkDude> Well I got kicked after saying Im sorry
[19:31] <MarkDude> It should be talked about on this thread
[19:31] <MarkDude> There is no CoC. We have be excellent to each other
[19:32] <nathwill> interesting.
[19:48] <MarkDude> This may take a long long time to sort out
[19:48]  * MarkDude has made very clear he has a *scorched earth * policy on this
[19:48] <MarkDude> And anyone that votes to limit naming
[19:48] <MarkDude> Will have an albatross around their neck
[19:49] <nathwill> well. naming does have limitations, but they should be only legal considerations having to do with trademark/copyright
[19:50] <nathwill> there should not be any politicking involved in restricting the decisions once an established community-driven process has reached consensus
[19:53] <MarkDude> Agreed
[19:53] <nathwill> cool link from reddit: http://www.youtube.com/watch?v=sKOk4Y4inVY
[19:54] <MarkDude> I wish the Ambassaodr list was public, this will get epic
[19:57] <blkperl> nathwill: 16th then
[19:58] <nathwill> blkperl, ok, cool. will you let me know when we have officially got a room reserved?
[19:59] <blkperl> nathwill: got it
[19:59] <blkperl> nathwill: i mean on it
[19:59] <blkperl> nathwill: what was the time frame?
[20:00] <nathwill> blkperl, you mean the hours?
[20:00] <blkperl> nathwill: yeah
[20:00] <nathwill> slangasek, kees, how long do these normally run for?
[20:00] <nathwill> i'd think 6 hours would be good... maybe noon-6, but let's get confirmation
[20:01] <slangasek> I'm not sure what normal is
[20:01] <bkerensa> >.< http://portland.craigslist.org/clk/sys/3021787761.html
[20:01] <slangasek> in Europe, they do them as all-weekend things, with people coming in on train and crashing on couches or at the venue overnight :)
[20:02] <nathwill> blkperl, don't suppose psu eng building has bunkbeds? ;)
[20:02] <blkperl> nathwill: nope
[20:02] <nathwill> lol
[20:02] <bkerensa> slangasek: imho having a all day event at the very least seems best so we can get much done
[20:03] <slangasek> yeah
[20:03] <nathwill> ok then... would a 10-> ~8 be a good timeframe?
[20:03] <slangasek> that seems good to me
[20:05] <nathwill> blkperl, think we could get 10-8?
[20:06] <MarkDude> You folks know that if you do a release party picnic for Ubuntu, we can put it on geeknic.org?
[20:06] <MarkDude> If there is food, its a geeknic
[20:06] <bkerensa> nathwill: question is how much space will we have? Then next phase is food/drink :) geeks dont work without some sort of snacks and beverages
[20:07] <blkperl> nathwill: ok
[20:07] <bkerensa> MarkDude: me and nathwill have discussed already.... later this summer likely
[20:09] <MarkDude> Well depending on plan for event, you may be able to promote next event there
[20:22] <nathwill> well, i think room for ~20 would be plenty right?
[20:22] <nathwill> bkerensa, what was attendance at the last event?
[20:23] <bkerensa> uhh
[20:23] <bkerensa> 20-25-30? idk exact number
[20:24] <nathwill> ok.
[20:24] <nathwill> blkperl, think a room with capacity for 30 is doable?
[20:24] <nathwill> i know people tend to float in and out throughout
[20:24] <blkperl> nathwill: i think it can hold 80ish
[20:25] <blkperl> nathwill: theres multiple rooms too
[20:25] <nathwill> :D
[20:25] <nathwill> excellent :)
[20:25] <bkerensa> Im not agin us using that PSU ya her
[20:57] <nathwill> lol
[20:57] <nathwill> yay whiskey and dishwashing
[21:11] <bkerensa> sounds like a horrible idea ^


[09:19] <Laney> isn't there a way to get an archive to publish for a series without having to put a package there?
[09:20] <Laney> or maybe I'm misremembering
[09:20] <Laney> tried markSuiteDirty() but I'm not sure that'll do it
[09:21] <cjwatson> That's what it's meant to do
[09:21] <Laney> oho
[09:21] <cjwatson> There's a mark-suite-dirty in lp:ubuntu-archive-tools for convenience
[09:22] <Laney> ok, then I just need to wait for it to publish
[09:22] <Laney> I lost confidence that this would work for empty suites, seems I shouldn't have


[04:57] <klrguy> i am getting " The import java.util.Scanner cannot be resolved" . how can i resolve this?
[07:16] <nthykier> slytherin: About the removal of servlet2.4 - eclipse depends on it, so I would appreciate if it was allowed to stay
[07:16] <nthykier> slytherin: but I am definitely pro the removal of servlet2.3
[07:20] <nthykier> ttx: hey - About the removal of servlet2.4 - eclipse depends on it, so I would appreciate if it was allowed to stay, but I am definitely pro the removal of servlet2.3. (I also mentioned it to slytherin just before you joined)
[07:21] <ttx> nthykier: ok, ideally we would just follow Debian here
[07:23] <nthykier> ttx: then we should probably sell the idea to Debian :P
[07:23] <slytherin> nthykier: Ok. But I will make it so that other rdeps of servlet2.4 start using servlet2.5
[07:23] <nthykier> slytherin: That would be great
[07:24] <slytherin> In any case. The first thing on my TODO list for this week is getting JSTL packaged.
[07:24] <nthykier> I wish I could do the same for eclipse, but sadly it needs both 2.4 and 2.5 at the same time
[07:40] <slytherin> nthykier: ttx: Does either of you know how can I configure the directory in which jetty will put compiled JSP. I found some references of such a configuration parameter but did not find any actual example.
[07:41] <ttx> slytherin: hmmm... no.
[10:33] <slytherin> ttx: Is OpenJDK currently in a state to supersede Sun Java? Any idea who requested the removal of Sun Java?
[10:34] <ttx> slytherin: I think it was the security team
[10:35] <slytherin> The removal reason didn't state security reasons.
[10:35] <slytherin> It just said 'Superseded by OpenJDK'.
[10:35] <slytherin> ttx: ^
[10:36] <ttx> I don't really know the status of this...
[10:36] <ttx> Maybe it's part of https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-dropping-sun-java6
[10:39] <slytherin> So many items on the list are TODO. :-(


[21:25] <Bassoon28607>  Hi .. anyone got time to help a newbie with a Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)


[02:55] <Ubugtu> New bug: #2066 in libxfont (main) "Unable to load any usable fontset" [Undecided,Unconfirmed]  https://launchpad.net/bugs/2066
[02:55] <Ubugtu> New bug: #52163 in libxfont (main) "Scalable bitmap font names reported but not usable after failed XSetFontPath() call" [Undecided,Unconfirmed]  https://launchpad.net/bugs/52163
[04:20] <Ubugtu> New bug: #36314 in xserver-xorg-video-ati (main) "direct rendering missing on ATI Radeon XPRESS 200M " [Medium,Confirmed]  https://launchpad.net/bugs/36314
[06:50] <Ubugtu> New bug: #43154 in xserver-xorg-video-via "computer freezes with some applications using 3D" [Medium,Confirmed]  https://launchpad.net/bugs/43154
[07:30] <Ubugtu> New bug: #47508 in acpi-support (main) "Suspend and Hibernate are broken on an IBM Thinkpad R50e (dup-of: 40621)" [Medium,Needs info]  https://launchpad.net/bugs/47508
[07:55] <Ubugtu> New bug: #84938 in xorg (main) "dependancy on xfonts-scalable unnecessary" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84938
[10:30] <Ubugtu> New bug: #77928 in xserver-xorg-input-keyboard (main) "xorg handling of "special" keys inconsistant" [Undecided,Unconfirmed]  https://launchpad.net/bugs/77928
[10:41] <Ubugtu> New bug: #70886 in xserver-xorg-input-keyboard (main) "Dead keys for diacritics not complete" [Undecided,Unconfirmed]  https://launchpad.net/bugs/70886
[10:54] <Ubugtu> New bug: #84969 in linux-restricted-modules-2.6.17 (restricted) "aticonfig --enable-monitor fails" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84969
[12:02] <Ubugtu> New bug: #83726 in xorg (main) "[feisty-herd3]  X Display in Power-Saving mode on Startup, LiveCD even" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83726