[03:35] <smoser> blackboxsw: i dont know what that error checkign signature is.
[03:35] <smoser> maybe you dont have trusted your own key?
[03:35] <smoser> i do not set BIN_NMU_TIMESTAMP
[03:35] <smoser> I think this is the only things i have"
[03:36] <smoser> http://paste.ubuntu.com/p/gYKS7skDGd/
[13:33] <blackboxsw> Yeah I hadn't earlier verified my key in launchpad. I have since pushed and verified.
[15:40] <blackboxsw> smoser: forgot to ask about the lintian error that I saw which complained about debian/cloud-init.templates not having po translation files
[15:40] <blackboxsw> E: cloud-init source: untranslatable-debconf-templates cloud-init.templates: 6
[15:40] <blackboxsw> 16:13 E: cloud-init source: not-using-po-debconf
[15:40] <blackboxsw> do we care?
[15:41] <blackboxsw> enough to ignore the lint on that template file? or setup the pot files instead
[15:41] <smoser> oh yeah... ENOCARE :)
[15:41] <blackboxsw> excellent
[15:41] <smoser> i'd like to get rid of it, but...
[15:41] <smoser> not a big deal.
[15:42] <smoser> we could and arguably should add potential translations for that i guess.
[15:50] <blackboxsw> Soy increíble en la traducción
[15:50] <smoser> my keyboard doesn't have one of those funny i or o keys
[15:50] <blackboxsw> just a couple of curls away against google.translate
[15:51] <smoser> :)
[16:20] <blackboxsw> smoser: or rharper if there is a chance today for the azure branch landing, then I can easily re-upload cloud-init :) https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/352660
[16:20] <blackboxsw> shameless self-interest on that branch :)
[16:25] <smoser> blackboxsw: i had asked about 'remove_ubuntu_network_config_scripts' in _get_data()
[16:25] <smoser> and suggested in .activate
[16:32] <blackboxsw> Smoser I responded I thought that activate was too late as we are generating network config in init local timeframe and we would collide with the cloud image's seeded netplan file
[16:36] <blackboxsw> So we need something to clean out the /etc/netplan/90-azure-hotplu.yaml before we kick netplan
[16:36] <smoser> oh. ok. yeah, that is why we should talk on the MP :)
[16:36] <smoser> rahter htan me asking out of band
[16:36] <smoser> :)
[16:36] <blackboxsw> Yeah... and me deleting the original merger proposal broke that :/
[16:37] <blackboxsw> ... bad solution to a stale  visual diff with merge conflict markers 《《
[16:58] <smoser> blackboxsw: respondoned
[20:04] <blackboxsw> rharper  one of smoser's comments on my branch which adds the ds-identify detect_Azure logic to DataSourceAzure._is_platform_viable was that the following test is not really valid  has_fs_with_label "rd_rdfe_*" && return ${DS_FOUND}
[20:05] <blackboxsw> I just validated that adding data diskss on azure instances resulted in the following partitions and labels
[20:05] <blackboxsw> sudo python3 -c 'from cloudinit.util import blkid; print(["%s:%s" % (k, v.get("LABEL", "")) for k,v in blkid().items()])'
[20:05] <blackboxsw> ['/dev/sda1:cloudimg-rootfs', '/dev/sda15:UEFI', '/dev/sdb1:', '/dev/sdc1:', '/dev/sda14:']
[20:05] <blackboxsw> ubuntu@SRU-worked:~$
[20:06] <blackboxsw> so most disks have empty labels.  /me wonders about the initial dvd/cdrom that shows up on azure during first boot... maybe it had that label
[20:06] <blackboxsw> my question was...
[20:06] <blackboxsw> if we thinkg the re_rdfe_* prefix is not valid for DataSourceAzure._is_platform_viable, should I also drop it from ds-id
[20:06] <blackboxsw> if we are thinking the re_rdfe_* prefix is not valid for DataSourceAzure._is_platform_viable, should I also drop it from ds-id
[20:07] <blackboxsw> the thing that stinks about irccloud is that if my browser is sucking wind, it timesout on keyboard character input
[20:08] <rharper> blackboxsw: that's prolly a question for the MS folks w.r.t  cdrom
[20:08] <rharper> blackboxsw: can you confirm if /dev/sr[0,1] has anything in it ?
[20:09] <rharper> I don't think we can yet drop it until we know that it's invalid;  we usually have a collection of information that jointly confirms which platform we're on
[20:15] <smoser> blackboxsw: so the dvd/cdrom definitely used to start with 're_rdfe_'
[20:17] <smoser> its possibly obsolete now.
[20:17] <smoser> and i recall bein told that it might be.
[20:18] <smoser> but as in the 'dscheck_Azure' function "header", you can see that is where it came from
[20:21] <rharper> blackboxsw: AFAICT the check is still valid; we don't know of another cloud where there are (iso) filesystems with such labels;  they may not be in used in your instance
[20:21] <rharper> but it's possible in other azure deployments (AZ, or private)
[20:21] <rharper> it may still be used
[20:21] <rharper> blackboxsw: what was smoser objecting to w.r.t the label check being invalid ?
[20:21] <smoser> well, butthat only ever gets considered if azure asset tag is not present.
[20:21] <rharper> a fallback
[20:21] <rharper> sure
[20:21] <smoser> and we really should have azure asset tag present everywhere.
[20:21] <rharper> yes
[20:22] <rharper> that makes sense
[20:52] <blackboxsw> So smoser should I drop that filesystem prefix check from ds-id or leave our fallback in both places
[20:55] <smoser> and if not... well, i think its completely unrelated to your changes.
[20:56] <smoser> so if you want you can do that in a separate MP and we can just take that in first.
[20:57] <blackboxsw> woot! +1 . let's do that as I'm itching to get an upload in
[20:57] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/352921
[20:57] <smoser> thats my no-unit test oracle ds
[20:57] <blackboxsw> nice smoser will play with it
[20:58] <blackboxsw> smoser: I'll pull out the prefix check from the python is_viable_platform
[20:58] <blackboxsw> then we only have it in one place to remove
[20:59] <blackboxsw> I won't touch ds-id logic until we confirm otherwise
[21:05] <blackboxsw> ok pushed my branch. it can sit until monday as it's EOW for you gents