[04:22] <knaccc> hey y'all, is it correct that I should not be editing 50-cloud-init.yaml to put in a custom nameserver list or search domains, and should instead create a /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg and then...? any help greatly appreciated
[04:26] <knaccc> i'm very confused that when i set up the custom DNS servers (<IP_ADDRESS> etc), "systemd-resolve --status" shows that it's recognizing that for "Link 2 (enp3s0f0)", but not for "Global". and i think therefore for some reason it's ignoring my DNS settings and search domain
[04:26] <knaccc> the server has 2 eth interfaces, and only one is configured,
[13:51] <Odd_Bloke> knaccc: cloud-init will regenerate /etc/netplan/50-cloud-init.yaml on each boot, so yes, you don't want to modify that.  If you're still having the issue, please pastebin all config you have in /etc/netplan and we can try to help out. :)
[15:32] <blackboxsw> rharper: lucasmoura Odd_Bloke falcojr this would be additional set of commits if we ran new-update-snapshot https://pastebin.ubuntu.com/p/qVMwsrKHKH/
[15:33] <Odd_Bloke> That LGTM, would definitely be nice to get that Chef change in.
[15:34] <rharper> blackboxsw: yeah, +1
[15:53] <blackboxsw> rharper: Odd_Bloke falcojr lucasmoura https://github.com/canonical/cloud-init/pull/411  upload of new-upstream-release for groovy and SRU afterward
[16:09] <Odd_Bloke> blackboxsw: Reviewing now.
[16:15] <blackboxsw> thanks Odd_Bloke focal right after it https://github.com/canonical/cloud-init/pull/412
[16:15] <blackboxsw> same changeset basically
[16:16] <blackboxsw> I have to change the eoan bionic and xenial a bit more
[16:16] <blackboxsw> aaand cloud-init status tim
[16:16] <blackboxsw> aaand cloud-init status time
[16:17] <blackboxsw> #endmeeting
[16:18] <Odd_Bloke> blackboxsw: Cool; one note: we have a lot of stale Build-Depends now: unittest2 isn't required, six isn't required, and we've stopped using pyflakes and pep8 directly (and my local build didn't fail due to the absence of flake8, so I don't think we need to replace it).
[16:18] <Odd_Bloke> (That build was on focal, I'm just bootstrapping a groovy build env now, to test the actual correct release.)
[16:21] <blackboxsw> #startmeeting cloud-init status meeting
[16:21] <meetingology> Meeting started Tue Jun  2 16:21:15 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:21] <meetingology> Available commands: action commands idea info link nick
[16:21] <blackboxsw> hi folks, time for another cloud-init upstream status meeting.
[16:22] <blackboxsw> we use this meeting to provide a venue for any cloud-init interested parties to keep up to date on current development, release-related info and expedite distributed development where possible.
[16:22] <blackboxsw> this meeting is a welcome place for interruptions, questions, requests and unrelated discussions at any point. so don't be shy :)
[16:23] <blackboxsw> #chair Odd_Bloke smoser rharper
[16:23] <meetingology> Current chairs: Odd_Bloke blackboxsw rharper smoser
[16:23] <blackboxsw> The topics we generally cover in this meeting are the following: Previous Actions, Recent Changes, In-progress Development, Community Charter, Office Hours (~30 mins).
[16:24] <blackboxsw> previous meeting minutes live here (and I just saw I forgot to publish last minutes so I pushed them now)
[16:24] <blackboxsw> #link https://cloud-init.github.io/
[16:24] <blackboxsw> #topic Previous Actions
[16:25] <blackboxsw> nothing actionable brought up in last meeting on 05/19
[16:26] <blackboxsw> Odd_Bloke: ahh we should fix devel with those pkg drops on next upload
[16:26] <blackboxsw> we did drop that for Xenial, Bionic Eoan and maybe focal too?
[16:26] <blackboxsw> so an oversight for groovy
[16:27] <blackboxsw> next topic
[16:27] <blackboxsw> #topic Recent Changes
[16:28] <blackboxsw> the following are commits landed in tip of master found via git log --since 05/19/2020 : https://paste.ubuntu.com/p/QFvgWhjXY9/
[16:28] <Odd_Bloke> blackboxsw: When you say "next upload" are you referring to the upload you're about to do, or the one after that?
[16:28] <blackboxsw> Odd_Bloke: if you'd like we can adjust the current upload so that devel, focal, bionic xenial eoan all drop those stale deps
[16:28] <blackboxsw> I think X, B E have all dropped them
[16:29] <blackboxsw> so maybe I re-do ubuntu/devel PR Odd_Bloke ?
[16:29] <blackboxsw> probably good/better/correct to keep all releases on the same footing.
[16:29] <Odd_Bloke> blackboxsw: I think it's worth doing, we've uploaded without fixing it a few times before, and we've remembered this time around.
[16:30] <blackboxsw> yeah sounds good Odd_Bloke I'll re-do that devel PR (and make sure focal drops it too)
[16:30] <blackboxsw> if needed
[16:30] <Odd_Bloke> And it should just be a case of pushing a new commit to your existing branch.
[16:30] <Odd_Bloke> Thanks!
[16:30] <blackboxsw> +1
[16:32] <blackboxsw> things of note in the recent commits landed.  https://github.com/canonical/cloud-init/pull/358  Mattew Ruffell  improved cc_grub_dpkg to be more dynamic in matching disks instead of a hardcoded device list
[16:33] <blackboxsw> thanks Matthew
[16:33] <blackboxsw> and chef_license support https://github.com/canonical/cloud-init/commit/0919bd46bbd1b12158c369569ec1298bb000dd8a
[16:34] <blackboxsw> thanks bipinbachhao  for the config extension there
[16:34] <blackboxsw> #topic  In-progress Development
[16:35] <blackboxsw> a couple of new notables in flight at the moment:
[16:38] <blackboxsw> - falcojr: introduction of feature-flags for cloud-init upstream to give us a toggle to retain original behavior of #include failures on stable downstream releases. https://github.com/canonical/cloud-init/pull/367  . Upstream cloud-init will fail loudly and raise an Exception if someone tries to #include a url which fails. this differs from original cloud-init behavior which was to try our best to get a system up
[16:38] <blackboxsw> and running, even amid not-critical failures
[16:39] <blackboxsw> per the above, if downstreams (distributiions) would like to retain a more permissive warn on #include user-data issues, a cloudinit/feature_overrides.py file would need to be introduced in the downstream
[16:40] <blackboxsw> - Also meena and Odd_Bloke and others have been working toward a refactor of cloudinit.net modules. Dan added a doc PR to capture this approach https://github.com/canonical/cloud-init/pull/391
[16:41] <blackboxsw> beyond that, there are a number of PRs up from lucas on json schema additions for cloudinit/config/cc_* modules to get better validation of #cloud-config user-data
[16:42] <blackboxsw> For ubuntu proper, we have started the StableReleaseUpdate process for cloud-init to publish master into ubuntu/xenial, bionic, eoan and focal releases
[16:43] <blackboxsw> some of these changes will add the opportunity to enable 'new' features on platforms like Azure
[16:43] <blackboxsw> and AWS
[16:43] <blackboxsw> Azure (xenial) will be dropping walinuxagent support
[16:44] <blackboxsw> AWS will now surface a datasource config option apply_full_imds_network_config boolean
[16:45] <blackboxsw> if set true in an Ec2(aws) image network configuration from cloud-init can come completely from IMDS for every connected NIC. That config will include all secondary IPv4/IPv6 addressses configured for the machine
[16:46] <blackboxsw> Upstream has  started the Ubuntu SRU process (which generally takes around 10-14 days). We plan to include every commit that has landed in tip of master as of commitish 5f7825e22241423322dbe628de1b00289cf34114
[16:46] <blackboxsw> the bug related to this SRU work is here
[16:46] <blackboxsw> #link https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018
[16:47] <blackboxsw> #topic Community Charter
[16:48] <blackboxsw> upstream has signed up to get as much of the json schema coverage as we  can for cloudinit/config/cc*py modules since invalid #cloud-config user-data formats tends to have one of the highest incidence of errors (because writing YAML is something humans shouldn't have to do :) )
[16:49] <blackboxsw> so we are chopping away at defining JSON schema for as many cloud config modules as possible . there are still plenty to choose from. Anyone can feel free to grab a JSON schema bug and help us with bettering cloud-init
[16:49] <blackboxsw> bugs are filed for each config module which needs schema definition:
[16:49] <blackboxsw> #link  https://bugs.launchpad.net/cloud-init/?field.tag=bitezise
[16:50] <blackboxsw> a big thanks to lucasmoura for starting to grab a number of these
[16:50] <blackboxsw> #topic Office Hours (next ~30 mins)
[16:50] <blackboxsw> This 'section' of the meeting is a time where a couple of upstream devs will be available in channel for any discussions, questions, bug work or PR reviews.
[16:51] <blackboxsw> In the absence of discussions/topics here we scrub the review queue.
[16:51] <blackboxsw> since we are mid-stream on Ubuntu SRU at the moment, I'll be addressing review comments on some of the functional 'upload' branches we've put together
[16:52] <blackboxsw> and, let's update the topic for next IRC meeting too while we are at it
[16:59] <blackboxsw> Odd_Bloke: just pushed ubuntu/devel dropping python3-six|unittest2|nose
[17:01] <blackboxsw> and just re-pushed ubuntu/focal to drop python3-six
[17:04] <blackboxsw> oops and missed you others. reworking
[17:12] <blackboxsw> ok re-pushed. focal and devel PRs in shape
[17:13] <blackboxsw> dropped the following build-deps: python3-six, python3-unittest2, python3-pep8, python3-nose, python3-pyflakes
[17:20] <Odd_Bloke> blackboxsw: +1 on the ubuntu/devel upload.
[17:21] <blackboxsw> whew, think we got all of the dropped deps between the two of us... thanks!
[17:21] <blackboxsw> Odd_Bloke: thanks focal looks good and sbuilds
[17:21] <blackboxsw> just finished eoan and building now to test
[17:23] <meena> what? me??
[17:24] <blackboxsw> well yes indeedy meena, just trying to keep you highlighted as participating in the cloud-init status meeting :) you've thankfully reviewed, pushed and prodded us to talk about cloudinit.net refactor and how best to address it I think :) credit due ;)
[17:26] <blackboxsw> community notice: upload to Ubuntu groovy of cloud-init master accepted [ubuntu/groovy-proposed] cloud-init 20.2-45-g5f7825e2-0ubuntu1 (Accepted)
[17:30] <Odd_Bloke> blackboxsw: One issue with https://github.com/canonical/cloud-init/pull/412
[17:31] <meena> blackboxsw: i'm just waiting for Odd_Bloke to provide the basic infrastructure so i can start moving code… without that, i have to bug other projects in my … 2 hours of free time per day.
[17:31] <meena> blackboxsw: yesterday, i tried to build an android app on my laptop and gave up after an hour.
[17:35] <blackboxsw> nice review again Odd_Bloke, will reflect that patch to each series. as every other ubuntu/* is missing enabling various cloud datasources beyond just Rbx
[17:54] <blackboxsw> Odd_Bloke: rharper so Xenial is interesting for datasource config via dpkg
[17:55] <blackboxsw> We are missing: Hetzner, IBMCloud, Oracle, and  RbxCloud
[17:55] <blackboxsw> one was an oversight on previous SRUs
[17:55] <blackboxsw> but Oracle and IBMCloud, I'm trying to recall if there is a reason we didn't want to surface either of those datasources as configurable on Xenial
[17:56] <blackboxsw> a little warning bell is going off in my head
[17:56] <blackboxsw> Hetzner I thought was 'ok'
[17:56] <blackboxsw> Oracle currently gets detected as OpenStack on Xenial.
[17:57] <rharper> IBMCloud and Oracle are sensitive
[17:57] <rharper> not sure about Hetzner or RbxCloud though
[17:57] <blackboxsw> upstream Oracle datasource is 'good', but I wasn't sure if there was extra baggage associated with *not* backporting that functionality
[17:57] <rharper> blackboxsw: I think you might want to check with CPC on those
[17:58] <meena> Hetzner is also detected as OpenStack on FreeBSD… but… only thru cloud-init itself, not thru ds-identify
[18:03] <meena> (i'm not sure how much of that is my fault having helped a lot with Hetzner and FreeBSD and ds-identify myself)
[18:03] <knaccc> Odd_Bloke thanks for your reply. I managed to fix things in the end, but kinda by cheating. Now my /etc/netplan/50-cloud-init.yaml only contains the IP addresses configuration, and I make the nameservers and search domain apply in the "Global" scope (as reported by systemd-resolve --status) by simply modifying the /etc/resolv.conf file. All configuration survives reboot just fine, and I am no longer
[18:03] <knaccc> scared that resolv.conf will be overwritten because I found a web page that said that "Note: The mode of operation of systemd-resolved is detected automatically, depending on whether /etc/resolv.conf is a symlink to the local stub DNS resolver file or contains server names." Although you said in your message that "cloud-init will regenerate /etc/netplan/50-cloud-init.yaml on each boot, so yes, you don't
[18:03] <knaccc> want to modify that", the OVH instructions directly contradict that and tell me to edit it to add all IP addresses to my interface (see Ubuntu 18.04 section here: https://docs.ovh.com/gb/en/vps/network-ipaliasing-vps/). I'm therefore very confused about why OVH seem to contradict the instructions that are in that config file, and confused as to what other location I should be editing/creating instead
[18:06] <ddstreet> knaccc why do you want to change resolved 'Global' section?
[18:08] <blackboxsw> heh meena not at fault :) . Just need to make sure we move cloud-platforms to a better way of detecting the right datasource when we can.
[18:08] <knaccc> ddstreet if I put the nameservers and search domain into the /etc/netplan/50-cloud-init.yaml file, it gets ignored completely (i.e. although those configurations show up in systemd-resolve --status against that specific "link", the "Global" nameservers and lack of any search domain in that Global section are taking precedence). Therefore I had to configure nameservers and search domain at the resolv.conf
[18:08] <knaccc> level so that it appeared in the Global section, and then suddenly everything worked for the first time
[18:08] <blackboxsw> I should tie off our cloud-init status meeting. Thanks folks for all who've attended
[18:08] <blackboxsw> #endmeeting
[18:08] <meetingology> Meeting ended Tue Jun  2 18:08:56 2020 UTC.
[18:08] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-06-02-16.21.moin.txt
[18:09] <knaccc> oh oops, sorry i didn't realise the meeting was still in progress when I interjected
[18:09] <blackboxsw> knaccc: the meeting is a welcome place for any and all discussions
[18:09] <blackboxsw> all good
[18:09] <blackboxsw> I was just supposed to end it about ~20 mins ago to capture logs
[18:10] <blackboxsw> we were in the "open discussion office hours"  part of the meeting
[18:10] <ddstreet> knaccc i don't know what your exact config is, but you don't need nameservers in the global section for dns to work
[18:11] <knaccc> ddstreet since the OVH config already specified a resolv.conf file, that seemed to be overriding my settings in the 50-cloud-init.yaml file. I should have thought to try deleting the resolv.conf file to see if that would stop the "Global" section for overriding the link settings
[18:13] <ddstreet> yeah with systemd-resolved you don't want to modify the /etc/resolv.conf file
[18:13] <knaccc> ddstreet do you disagree with the web page I found that says "Note: The mode of operation of systemd-resolved is detected automatically, depending on whether /etc/resolv.conf is a symlink to the local stub DNS resolver file or contains server names"?
[18:14] <knaccc> (that's a quote from here https://wiki.archlinux.org/index.php/Systemd-resolved )
[18:14] <ddstreet> knaccc no that's correct, but if you maintain your /etc/resolv.conf yourself, you need to 100% manage it
[18:14] <knaccc> ddstreet ah yes, that's the impression i got. since this is a dedicated server, and that resolv.conf configuration will probably never change, that should be OK, right?
[18:15] <knaccc> all resolv.conf contains is the cloudflare and google dns servers, and my search domain. so those will probably never change, ever
[18:15] <ddstreet> well that depends on what exactly you did, i.e. remove the symlink and create the file yourself, and remove the <IP_ADDRESS> from it
[18:15] <ddstreet> i.e. you want to bypass resolved entirely
[18:16] <ddstreet> when you do that, it doesn't matter what systemd-resolve --status says, because you aren't using it
[18:17] <knaccc> ah that makes sense. yes the resolv.conf file was already put there by OVH on a fresh install. so i'm guessing they did itthat way to make things easier for people who were used to just editing resolv.conf
[18:18] <knaccc> i'll try deleting resolv.conf and then seeing if 50-cloud-init.yaml nameservers and search domain suddenly get picked up
[18:18] <ddstreet> well you need to recreate the symlink to /run/systemd/resolve/stub-resolv.conf
[18:18] <ddstreet> and make sure something has told resolved about your actual nameservers, i.e. networkd in most cases
[18:19] <knaccc> ddstreet ah thanks, yes i see, i'm supposed to do: ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
[18:20] <knaccc> i'll try that, when i'll be reinstalling another server in a few hours
[18:20] <knaccc> although it seems like since i don't have some kind of liquid situation with frequently changing nameservers, maybe i should just stick to simplicity and just do things in resolv.conf
[18:20] <knaccc> ddstreet if i'm not supposed to be editing 50-cloud-init.yaml file, could you point me towards what I should be ediitng please?
[18:22] <knaccc> i wonder if OVH are using cloud-init in a kind of "one-shot" mode, where it's useful for them to just config a dedicated server the first time using cloud-init, but then i can then just edit the 50-cloud-init.yaml file myself from then on, because neither OVH nor any kind of system thing will ever overwrite 50-cloud-init.yaml
[18:27] <ddstreet> i didn't say you shouldn't edit that file
[18:28] <ddstreet> but in general, no you shouldn't, it's created from the cloud data
[18:28] <ddstreet> you should edit your instance config from the cloud provider's contorls
[18:34] <blackboxsw> so rharper/Odd_Bloke for this SRU, I'm thinking we hold on IBMCloud, Hetzner and Oracle datasource enablement and tackle that separately once we circle the wagons with regard to Xenial expected behavior
[18:35] <blackboxsw> I'm good with adding RbxCloud as that datasource was just recently added and detecting it falls at the end of the list for ds-identify
[18:37] <rharper> blackboxsw: that sounds good to me
[18:38] <blackboxsw> this is all for xenial and bionic, only adding RbxCloud, xenial and bionic will still lack Oracle and IBMCloud support. Xenial will also lack Hetzner
[18:44] <knaccc> ddstreet thanks for your advice. is cloud-init attempting to connect to OVH on every reboot to see if there are new settings available? as long as i'm confident that this dedicated server will never need an automatic network setting update or any other type of updates from OVH via cloud-init, do you see any problem with me just disabling cloud-init by doing "touch /etc/cloud/cloud-init.disabled"? is that
[18:44] <knaccc> the best way to disable it? it is a bit creepy to me that OVH could just use cloud-init to mess with my dedicated server unexpectedly
[18:57] <rharper> knaccc: cloud-init generally only operates on first boot; subsequent boots runs cloud-init to determine if it is on the same instance or if it has been captured and booted on a different platform; in which case it clears data and runs like first boot again
[18:58] <rharper> knaccc: I'm not sure which Datasource OVH uses ( I think OpenStack, but not 100%s) most datasources do not generate network config on *every* boot; some platforms do (Azure for example);  if you are only worried about network config changes, you can configure cloud-init to not bother configuring networking at all;
[18:58] <Odd_Bloke> blackboxsw: To be clear, the issue is not that we're missing DSes, it's that our two lists are inconsistent.
[18:58] <blackboxsw> Odd_Bloke: sorry I figured that out later. but we also have missing datasources on Bionic and Xenial
[18:59] <rharper> Odd_Bloke: do you think we miss these due to image builds for certain platforms which might include the DS automatically ?
[18:59] <lucasmoura> blackboxsw, I am trying to write one of our manual tests for the next SRU. I am starting with focal, but I just want to verify something. Is it right that the cloud-init package to be tested is not on focal-proposed yet ?
[18:59] <rharper> it seems like some of them would scream if cloud-init didn't work at all on certain releases
[19:00] <rharper> lucasmoura: yeah, it's not uploaded to the pocket release yet
[19:00] <lucasmoura> rharper, ack
[19:00] <rharper> lucasmoura: instead you can: add-apt-repository -y ppa:~cloud-init-dev/proposed
[19:00] <rharper> then apt update && apt install cloud-init
[19:01] <lucasmoura> Oh right, now I remember that we commented that issue on the daily. The lxc-proposed-snapshot use the pocket by default right ?
[19:01] <Odd_Bloke> rharper: blackboxsw: Given the uncertainty we have over it, and the lack of bug reports, I think we should proceed with the current set of DSes.
[19:01] <blackboxsw> Odd_Bloke: I've specifically added RbxCloud (because it's newly added to tip) to X, B, E and F
[19:01] <Odd_Bloke> That seems fine to me too. :)
[19:01] <blackboxsw> ok, the others let's leave untouched
[19:01] <knaccc> rharper yes OVH is openstack, but that's for their public cloud. I think they're just suddenly using cloud-init on their private dedicated servers too since it makes it easy for them. Just to clarify, are you saying that cloud-init is probably connecting to OVH on every reboot to ask OVH if any changes need to be made, and OVH is saying "no" each time? or is it my server that it is itself deciding not to
[19:01] <knaccc> contact OVH on subsequent boots?
[19:01] <blackboxsw> and RbxCloud is last detected datasource anyway, so no impact to other datasources unless nothing else matches
[19:02] <rharper> knaccc: no; I can't say what they're doing without seeing some logs;  If they are using it on dedicated servers; it may use "offline" datasources like NoCloud which reads from a file, or ConfigDrive which reads from an iso
[19:05] <rharper> knaccc: you can see which datasource was detected  looking at /run/cloud-init/cloud.cfg , would show something like  datasource_list: [ NoCloud, None ]
[19:07] <rharper> knaccc: on platforms where there is a remote datasource (Like Openstack);  cloud-init does not reconnect to the metadata service on subsequent boots by default;  in some datasources, the only way to determine an instance's unique id is to fetch the values from the platfroms metadata server; for those platfroms, cloud-init does fetch the metadata on each boot; if the instance-id matches, no further work is done.
[19:08] <Odd_Bloke> blackboxsw: +1 on focal.
[19:08] <blackboxsw> lucasmoura: here's what we typically push to a vm under test https://github.com/cloud-init/ubuntu-sru/blob/master/sru-templates/manual/ec2-sru#L35-L40
[19:08] <blackboxsw> which does the setup cloud-init/proposed  PPA
[19:09] <blackboxsw> falcojr: too ^   so it's a good guideline on what to test until we ping the ubuntu SRU team to our my current work in progress ubuntu/* branches uploaded
[19:09] <blackboxsw> thanks Odd_Bloke build-and-pushing ubuntu/focal then
[19:11] <blackboxsw> just eoan bionic and xenial to go if lucasmoura falcojr wanted to look at those too I've captured the same type of new-upstream-snapshot changesets for those that I just pushed into ubuntu/focal  (though I haven't updated the PR doc/context for the drop of debian/control build-deps and the cloud-init.templates RbxCloud addition
[19:11] <blackboxsw> eoan https://github.com/canonical/cloud-init/pull/409
[19:11] <blackboxsw> bionic https://github.com/canonical/cloud-init/pull/409
[19:12] <knaccc> rharper this is my /etc/cloud/cloud.cfg: https://pastebin.com/raw/YwTa8Cpb I think that since there are no datasources listed in that, that that means there are no updates being checked for on every reboot?
[19:12] <blackboxsw> xenial https://github.com/canonical/cloud-init/pull/406
[19:13] <blackboxsw> knaccc: you can /should also check /etc/cloud/cloud.cfg.d/90_dpkg.cfg
[19:13] <blackboxsw> that is typically where the cloud image creator defaults that datasource_list
[19:13] <lucasmoura> blackboxsw, thanks I will use this approach then
[19:13] <knaccc> blackboxsw that has just this line, and I don't know what it means: datasource_list: [ NoCloud, ConfigDrive, OpenNebula, DigitalOcean, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, SmartOS, Bigstep, Scaleway, AliYun, Ec2, CloudStack, Hetzner, IBMCloud, Oracle, Exoscale, RbxCloud, None ]
[19:14] <lucasmoura> And I can help with reviews, no problem. I will start with eoan
[19:15] <blackboxsw> knaccc: so that list means on initial boot, ds-itentify script will try to detect each of those datasources in that specific order. so if cloud-init hadn't already detected the datasource for your image, it'd try to go through that list to find which one matches your platform. sorry I may have muddied the water with your previous discussion, I was just responding to your latest comment
[19:16] <blackboxsw> I'm reading your backlog knaccc to respond more appropriately to your underlying concern (it was about whether cloud-init would try to redetect/reconfigure your instance across boots right ?)
[19:16] <knaccc> blackboxsw yes that's right
[19:17] <knaccc> blackboxsw i just want to make sure that now that OVH has used cloud-init once to auto-configure the freshly reinstalled private dedicated server, that cloud-init will never mess with my config again on reboot
[19:17] <lucasmoura> blackboxsw, I know we can easily extract that from the changelog, but on the steps to reproduce the package, it is missing the 2.header part
[19:18] <knaccc> blackboxsw in which case, do you agree that the best way to stop cloud-init from messing with my system is to just do "touch /etc/cloud/cloud-init.disabled"?
[19:18] <Odd_Bloke> I'm looking at eoan now.
[19:18] <blackboxsw> thanks Odd_Bloke, I'm uploading ubuntu/focal
[19:19] <Odd_Bloke> blackboxsw: Still working through the patches, but I've already posted a Q, FYI.
[19:19] <rharper> knaccc: no, you need to look at the /run/cloud-init/cloud.cfg ;  /etc/cloud/cloud.cfg is the default settings and it enables all of the supported datasource;  at boot time cloud-init uses a systemd generator to detect which platform (or which datasource) is configured, NoCloud looks for files in /var/lib/cloud/seed/nocloud-net/*  or a iso/filesystem label with 'cidata' for example and then if we find a datasource or platfrom, then we enable
[19:19] <rharper> cloud-init to run (otherwise we don't run at all)
[19:20] <rharper> knaccc: w.r.t disabling cloud-init, touching that file will disable cloud-init
[19:20] <knaccc> rharper aha, /run/cloud-init/cloud.cfg says just: datasource_list: [ ConfigDrive, None ]
[19:21] <blackboxsw> and knaccc cloud-init status --long will show you ultimately what cloud-init proper detected as the valid datasource.
[19:21] <blackboxsw> so I'd expect cloud-init status --long to show ConfigDrive in the output
[19:21] <knaccc> yes, that --long command only shows: DataSourceConfigDrive [net,ver=2][source=/dev/nvme0n1p4]
[19:22] <blackboxsw> ok so the configdrive path source in that case was from /dev/nvme0n1p4
[19:25] <knaccc> blackboxsw ok, now i'm really confused. my two SSD drives (as reported by parted) are /dev/nvme0n1 and /dev/nvme1n1, and i have no idea what /dev/nvme0n1p4 is
[19:26] <blackboxsw>  /dev/nvme0n1p4  is just partition 4 on  /dev/nvme0n1
[19:26] <blackboxsw> I think
[19:28] <knaccc> i guess it could be a temporary partition that existed for a while during machine setup
[19:28] <knaccc> and it gets wiped out when the disk is configured
[19:29] <knaccc> ok, i think i'm starting to get comfortable understanding this enough to just disable cloud-init now and not worry about the consequences, you've both been a great help in enabling me to get some kind of mental model of what cloud-init is doing and where, so thank you blackboxsw rharper
[19:30] <knaccc> i was terrified that cloud-init would suddenly overwrite things on reboot and brick the machine, but i'm feeling much better about how to handle this now
[19:31] <knaccc> (by brick the machine, i mean suddenly revert the network config or something else unexpectedly, and cause things to break)
[19:49] <rharper> knaccc: sure, glad we could help
[19:52] <Odd_Bloke> blackboxsw: Did you see my comments on eoan?
[19:52] <Odd_Bloke> Just realised I didn't ping you with them, now I'm done.
[19:53] <Odd_Bloke> Haha, I see in my inbox right now that you have. :p
[19:57] <powersj> FYI cloud-init + azure whitepaper: https://pages.ubuntu.com/rs/066-EOV-335/images/Cloud-init_on_Azure.pdf
[19:58] <powersj> ^ AnhVoMSFT thanks for your help on that
[20:03] <blackboxsw> wow excllent powersj and AnhVoMSFT !
[20:22] <blackboxsw> Odd_Bloke: ok, thanks I see the issue with the quilt patch renderer-do-not-prefer-netplan.patch
[20:23] <blackboxsw> lucasmoura: it'll be the same issue on bionic too. you can see Odd_Bloke's failure by running: quilt push -a; tox -e py3 tests/unittests/test_render_cloudcfg.py
[20:24] <blackboxsw> just so we know best approach for verifying future  upload checks. # apply all quilt patches and test the world  with quilt push -a; tox -p auto
[20:24] <lucasmoura> blackboxsw, okay
[20:24] <blackboxsw> sorry gents, I neeed about 20 mins to fix this on the 3 branches
[20:24] <blackboxsw> Xenial/bionic/eoan
[20:43] <Odd_Bloke> blackboxsw: I caught this by performing a build locally, should we include that as part of the process before you submit the PR?
[20:44] <blackboxsw> Odd_Bloke: you think new-upstream-snapshot should run sbuild?
[20:44] <blackboxsw> or is it PR review requirement
[20:48] <Odd_Bloke> I think the submitter (and soon-to-be uploader) should run it, I don't think that automation should Just Do It (because different people will have different package building setups).
[20:48] <blackboxsw> Odd_Bloke: agreed. I'll add a PR to ubuntu-sru to mention that pre-requisite prior to PR.
[20:49] <Odd_Bloke> Yeah, new-upstream-snapshot could just mention it in that block of commands it suggests running?
[20:50] <blackboxsw> yes that works
[21:36] <tgm4883> Trying to use cloudinit on a centos 7 image in vmware, feels like I'm close, but cloud init throws a warning that it's unable to get datra from the vmware source. When I use the vmware rpctool I can see and decode the base64 data so the VM at least knows about it.
[21:37] <tgm4883> But nothing that I've told it to do actually happens, any pointers on where to look next? The logs only tell me that the data isn't found, but I can see the data when I query it
[21:42] <rharper> tgm4883:   maybe test out a newer cloud-init version?  https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/  ;   vmware issues have been a challenge for the community to work with.
[21:43] <rharper> tgm4883: there's also some use of a non-upstream datasource from vmware,  https://github.com/vmware/cloud-init-vmware-guestinfo/blob/master/DataSourceVMwareGuestInfo.py   which we don't directly support; I've seen users attempt to use this version (it works for some and not for others)
[21:43] <tgm4883> Will do
[21:44] <tgm4883> yea that's the one I'm using
[21:45] <tgm4883> My *very limited* understanding of how this all works is that these datasources are essentially plugins for cloud-init correct? So maybe if I understood how the data gets from that plugin to cloud-init (or rather, if I could somehow run and debug the plugin directly) it might help
[21:46] <tgm4883> I do see cloud-init trying to use it, but just says that getting data from that class failed
[21:52] <rharper> tgm4883: you can rerun cloud-init manually if you can access the image;  typically we modify the image with a root password and ssh keys, etc when debugging;  once on a system, you can manually run 'cloud-init init --local' and 'cloud-init init'  (those are the first two stages which exercise the datasource);
[22:18] <blackboxsw> eoan finally fixed for tomorrow, or any late birds still around https://github.com/canonical/cloud-init/pull/409
[22:30] <tgm4883> rharper: thanks for the help. I didn't get a chance to try the new version of cloud-init yet, but I did notice that the datasource that is installed in vmware's RPM is older than the one installed via the install script, and the one in the install script at least returns data when running it by itself, so that gives me some more to test with
[23:33] <rharper> tgm4883: ah, ok
[23:34] <rharper> tgm4883: sure,  glad we can help


[10:13] <Garren> Can anyone help me with this?
[10:13] <Garren> E: The method driver /usr/lib/apt/methods/htp could not be found.
[10:13] <Garren> it happens when I do apt-get update
[05:08] <Tinku_> ubuntu is good distribution for notebook??
[05:09] <Tinku_> ??
[05:09] <crimsun> it's excellent on many notebooks, just as many distros are
[05:13] <Tinku_> i hear tha is problem for a internet camera....
[05:15] <crimsun> ..."internet camera"?
[05:15] <Tinku_> yeah
[05:15] <crimsun> I don't know what that is.
[05:16] <crimsun> Are you referring to a "Webcam"?
[05:16] <Tinku_> meaybe i lern english
[05:18] <Tinku_> yeah webcam srry for that


[00:20] <RoAkSoAx> hi all... Is there a way to list in what dependencies should a package depends (instead of just listing its current dependencies). Or, how can I know what dependencies does a library package needs?
[00:20] <RoAkSoAx> or how do I know what should a library link agaisnt?
[03:09] <ScottK> RoAkSoAx: What problem are you trying to solve?
[03:16] <ScottK> Ah, i see you solved it on another channel.
[03:32] <RoAkSoAx> ScottK: well it is not really solved actually...
[03:33] <ScottK> RoAkSoAx: OK.  What's the problem?
[03:34] <RoAkSoAx> ScottK: because of the new linker thingy pacemaker fails to build
[03:34] <ScottK> OK.  What's the error?
[03:34] <RoAkSoAx> ScottK: let me grab the log
[03:35] <RoAkSoAx> ScottK: this is the error: http://pastebin.ubuntu.com/532713/
[03:36] <RoAkSoAx> ScottK: complete build log: http://launchpadlibrarian.net/59133765/buildlog_ubuntu-natty-amd64.pacemaker_<IP_ADDRESS>%2Bhg15626-2ubuntu1_FAILEDTOBUILD.txt.gz
[03:36] <ScottK> The other's I've seen gave a more useful error.
[03:39] <RoAkSoAx> ScottK: and in maverick, it built but showed this warning: "dpkg-shlibdeps: warning: symbol sort_rsc_index used by debian/pacemaker/usr/lib/libpengine.so.3.0.0 found in none of the libraries."
[03:40] <ScottK> RoAkSoAx: So you need to figure out what packages provide those symbols.
[03:40] <ScottK> Right, that was unneeded indirect linking.
[03:40] <ScottK> (in theory anyway)
[03:41] <ScottK> RoAkSoAx: What I would do is put the binaries that it build depends on into http://qa.debian.org/cgi-bin/mole/seedsymbols and see which one provides the symbols in question.
[03:41] <ScottK> There's probably a more elegant way to do it.
[03:42] <ScottK> https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols is probably helpful, but is looking at the problem from the opposite direction.
[03:42] <RoAkSoAx> ScottK: yeah well, those symbels are provide by pacemaker itself (since the package is not yet split on a package per library)
[03:43] <ScottK> All the more reason it should be split then.
[03:44] <ScottK> You should just have to add them to the linker then.
[03:44] <RoAkSoAx> ScottK: yes I already have a diff with the split, but still experiencing the build failure, so this is why I was wondering if there was a way to see which library provided the symbols by looking to the library itself
[03:44] <ScottK> I'm sure there is.
[03:45] <ScottK> man ld to get started I believe.
[03:45] <RoAkSoAx> ScottK: i think i just found it with objdump -t
[03:45] <RoAkSoAx> i'll give it a try
[03:46] <ScottK> Yeah.
[03:46] <ScottK> That sounds right.
[03:47] <RoAkSoAx> ScottK: alright, thanks for the help. :) I'll let you know about the outcome
[03:48] <achiang> RoAkSoAx: sorry for the wild goose chase earlier
[03:50] <RoAkSoAx> achiang: It's fine :)! it had the same changes of working as of not working so it was worth to try
[03:53] <RoAkSoAx> achiang: ScottK ok this is sample output of objdump:<PHONE_NUMBER>000000      D  *UND*0000000000000000              resource_location
[03:55] <ScottK> Right, so that's not gonna be much help I guess.
[03:55] <ScottK> Sorry, it's a bit late and I'd have to do a bunch of research to be more help.
[03:56] <RoAkSoAx> ScottK: that's fine. :) I appreciate the help though. I'll ping you tomorrow to see if we can get this resolved :)
[03:58] <RoAkSoAx> achiang ScottK: btw.. could it be because of missing (non existant) .pc files?
[03:58] <ScottK> RoAkSoAx: ask me a Python question.  Then maybe I'll know.
[04:00] <RoAkSoAx> ScottK: will do when I have one :)
[04:00] <achiang> RoAkSoAx: i don't think it's because of missing .pc files; i still kinda think it's an optimizer problem
[04:01] <RoAkSoAx> achiang: yeah, I guess we'll need to find were to actually make that work :)
[04:25] <achiang> ScottK: here's a python question - why am I seeing this on maverick? http://pastebin.ubuntu.com/532774/
[04:25] <ScottK> Not sure.
[04:26] <achiang> ScottK: i was being a little facetious. but the question is real - that error seems to point to a python interpreter error, not anything a script could have done, right?
[04:29] <ScottK> Probably now, but it's not 100% clear from that if it's Python itself, usb-creator-gtk, or something in between them that's at fault.
[04:29] <ScottK> now/not
[04:29] <ebroder> achiang: Could also be an extension module if there are any in the mix
[04:31] <achiang> ebroder: hm, what would be an example of an extension module?
[04:32] <kunal> facing an issue while using debuild command
[04:32] <kunal>  dh_install -a
[04:32] <kunal> dh_install: libomxil-bellagio-dev missing files (usr/share/pkgconfig/*), aborting
[04:32] <kunal> make: *** [binary-arch] Error 2
[04:32] <kunal> dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2
[04:34] <ebroder> achiang: Err, a C module, instead of a pure-python module
[04:34] <achiang> ebroder: hm, ok. it seems possible... usb-creator calls out to dbus and calls syslinux and/or grub at times
[04:35] <ebroder> achiang: Yeah, dbus seems like an obvious culprit. syslinux and grub are done just by shelling out, so those shouldn't be at fault
[04:36]  * achiang is trying to create a CLI frontend to usb-creator, and is having some success, but keeps getting strange errors during the "installing bootloader" phase
[04:41] <ebroder> achiang: Have you tried turning on apport and looking at the backtraces it gets?
[04:41] <achiang> ebroder: hm. i've never thought about that... i must admit i don't really know what apport does.
[04:42] <achiang> ebroder: i've been reading the log file in ~/.cache/usb-creator.log
[04:42] <ebroder> Or you could just run your frontend under gdb or something :-P
[04:42] <achiang> and sprinkling print statements around...
[04:42] <achiang> ebroder: i guess what i'd need to do is run gdb /usr/bin/python
[04:42] <ebroder> Try gdb --args ./whatever --you-were running-before
[04:42] <achiang> and set args script bla bla bla
[04:43] <achiang> i've never tried running python under gdb before. it's worth a shot
[04:43] <ebroder> I guess I don't know if gdb can interpret shebangs. Wouldn't surprise me, but your way sounds better
[04:43] <ebroder> achiang: It's not very useful if your problems are in Python-land, but segfaults don't happen in Python-land
[04:44] <achiang> nod
[04:48] <achiang> ebroder: well, i think i have two problems, the first one being that usb-creator uses threads and i'm not tall enough to use threads.
[04:49] <ebroder> achiang: Hmm...in general I'm not either; the only thing I know to do with threads is "t a a bt"
[04:50] <achiang> i think it's time for bed. or rather, something not related to computers
[05:54] <siretart> fta: sorry? natty already ships an rc4 prelease. I should rather look into getting rc4 finally out
[08:04] <dholbach> good morning!
[08:16] <apachelogger> ScottK: for kde test building we probably can apply the stuff I once recommended for quicker building on kubuntu-devel (cowdancer, chroot with base deps etc.) + hook into the build process and prevent deb creation, since that is of little interest I suppose
[08:17]  * apachelogger hugs dholbach good morning
[08:18]  * dholbach hugs apacheloggerback
[09:07] <iulian> Morning dholbach!
[09:08] <dholbach> hi iulian
[09:50] <zyga> hi
[09:50] <zyga> I'm working on my own application + set of ubuntu packages
[09:50] <zyga> I currently work in a ppa
[09:50] <zyga> should I be using -ubuntu0 suffix?
[09:51] <zyga> someone just recommended that I should have -0ubuntu1~zyga
[09:56] <ulysses> Hello, could you look at http://revu.ubuntuwire.com/p/hupnp please?
[10:30] <apachelogger> zyga: hi. in particular you should be using something like -0ubuntu1~zyga1. that way, if the version at hand gets included into Ubuntu, the Ubuntu version will supersede installation of your PPA version
[10:30] <apachelogger> 1.0-0ubuntu1~foo1 < 1.0-0ubuntu1
[10:30] <zyga> apachelogger, thanks
[10:31] <apachelogger> zyga: you're very welcome :)
[10:31] <zyga> apachelogger, I did that but the build process complained the maintainer address is not @ubuntu.com
[10:31] <zyga> apachelogger, I used my @linaro.org address and changed 0ubuntu1 to 0linaro1
[10:31] <zyga> (actually I just noticed I used -linaro0, not -0linaro0)
[10:32] <zyga> apachelogger, does that seem valid?
[10:32] <apachelogger> no :)
[10:32] <apachelogger> dpkg --compare-versions 1-linaro0 lt 1-0ubuntu1; echo $?
[10:33] <apachelogger> returns 1, i.e. your version would not be lower than the ubuntu version
[10:33] <apachelogger> dpkg --compare-versions 1-linaro0 lt 1-0; echo $?
[10:33] <apachelogger> also not lower than a debian version
[10:33] <zyga> hmm
[10:34] <zyga> so I should stick to 0ubuntu1 and not worry about the email addres warning?
[10:34] <zyga> (or perhaps I could use my ubuntu address for that)
[10:34] <apachelogger> zyga: ignoring should be just fine
[10:34]  * sebner pets apachelogger
[10:35] <apachelogger> AFAIK the warning is only there so that ubuntu devs do not upload ubuntu specific packages without ubuntu maintainer (for which we have a policy)
[10:35]  * apachelogger hugs sebner
[10:35] <apachelogger> ulysses: that should be a version with ubuntu1 really
[10:36] <zyga> apachelogger, so my packages should have whatever-0ubuntu1~zyga1
[10:36] <zyga> apachelogger, and I should increase zyga2, zyga3 and so on, without touching the ubuntu part
[10:36] <zyga> apachelogger, correct
[10:36] <apachelogger> zyga: exactly
[10:37] <zyga> apachelogger, thanks
[11:00] <zyga> apachelogger, are you familiar with lauchpad build recipes?
[11:01] <zyga> apachelogger, I have a control file http://bazaar.launchpad.net/~linaro-infrastructure/linaro-python-json/packaging/annotate/head%3A/changelog and a recipe https://code.launchpad.net/~linaro-infrastructure/+recipe/linaro-python-json-daily-build
[11:01] <zyga> apachelogger, it seems that the version is not taken from the changelog but from the recipe script
[11:02] <apachelogger> ulysses: reviewed. is this your first package?
[11:02] <apachelogger> zyga: recipes add a new changelog entry
[11:03] <zyga> apachelogger, ah
[11:03] <zyga> apachelogger, so that explains it
[11:03] <apachelogger> changing 0+{revno} to 0+{revno}-0ubuntu1~zyga{revno:packaging} should do the tick
[11:04] <apachelogger> (I think)
[11:04] <zyga> let me try
[11:04] <zyga> apachelogger, is there any reference to the syntax and variables you can use there?
[11:05] <zyga> 0+, isn't that going to override the package version that I already have (?)
[11:05] <apachelogger> https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[11:05] <apachelogger> zyga: depends on the version you have ;)
[11:05] <zyga> apachelogger, 1.0.0~alpha
[11:05] <apachelogger> just use dpkg --compare-versions
[11:05] <zyga> ideally the PPA version should be that + the revno
[11:05] <apachelogger> zyga: 0<1
[11:05] <zyga> and be more recent
[11:06] <apachelogger> that 0+n has an effect as if the were n < 1 :)
[11:06] <zyga> so the PPA daily build version will always be smaller than non-daily version?
[11:07] <zyga> (if I ever dput that that is)
[11:07] <zyga> should it not be the other way around?
[11:07] <apachelogger> zyga: with the current recipe, yes
[11:07] <apachelogger> then you will need to change your recipe ;)
[11:07] <zyga> I'm asking about the principle, what it _should_ look like
[11:07] <ulysses> apachelogger: yes, I only made some rebuild previously
[11:09] <apachelogger> zyga: PPA should be 1.0.0~alpha1-0ubuntu1~zyga1  - a daily should be 1.0.0~alpha1+{revno}-0ubuntu1~zyga{revno:packaging}
[11:09] <apachelogger> ulysses: very good packaging for a first package I must say
[11:09] <ulysses> apachelogger: Riddell helped mi a lot
[11:09] <apachelogger> ah, cheating, I see ;)
[11:10] <zyga> apachelogger, can I use {debupstream} instead of 1.0.0~alpha1?
[11:10] <zyga> (assuming that's my upstream version
[11:10] <apachelogger> zyga: yes
[11:12] <dholbach> Laney, directhex, hyperair: did you get Richard Lee's mail? did anyone of you comment?
[11:12] <hyperair> what mail?
[11:13] <hyperair> i don't remember seeing any such mail though
[11:13] <hyperair> dholbach: where was it posted to?
[11:13] <dholbach> your ubuntu.com email address :)
[11:13] <hyperair> huh
[11:13] <hyperair> O_o
[11:13] <dholbach> shall I forward it to you again?
[11:14] <hyperair> yes please
[11:14] <dholbach> hang on
[11:14] <hyperair> what's the title?
[11:14] <dholbach> "(Basic) Mono packaging guide for Debian and Ubuntu"
[11:14] <hyperair> oh that!
[11:14] <hyperair> wasn't that some months back?
[11:14] <hyperair> i think someone might have replied.
[11:15] <dholbach> forwarded again
[11:15] <hyperair> lemme check
[11:15] <dholbach> 12 days ago :)
[11:15] <hyperair> dholbach: i guess time has been moving too fast over here >_>
[11:16] <dholbach> yeah, sounds like it ;-)
[11:19] <directhex> dholbach: just running through the instructions
[11:20] <dholbach> directhex, hyperair: I can't comment on these, so if you can help Richard to make this really useful everybody would be happy :)
[11:20] <ulysses> apachelogger: is this correct? Build-Depends: debhelper (>= 7.3.16), libqt4-dev (>= 4:4.7.0)
[11:21] <hyperair> hmm "Note that it tracks the *runtime* dependencies not the *build* dependencies" seems a bit vague.
[11:21] <hyperair> dholbach: are people supposed to have read anything before the guide?
[11:21] <dholbach> hyperair, I don't know
[11:22] <dholbach> hyperair, Richard talked to me about it since he wanted to document how he went about doing mono packaging (and he didn't find docs for it) and because I have no clue about mono packaging, I suggested to talk to you guys :)
[11:23] <hyperair> dholbach: i use http://pkg-mono.alioth.debian.org/cli-policy/ as my holy CLI packaging bible.
[11:23] <hyperair> but maybe it's a tad bit too wordy for a beginner's guide..
[11:24] <dholbach> I don't know if Richard knew about this
[11:24] <dholbach> it'd be really great if any of you could get in touch with him 0:-)
[11:26] <hyperair> dholbach: is he on irc?
[11:27] <hyperair> directhex: wasn't there another email... to pkg-cli-*-team list about a cli packaging guide?
[11:27] <directhex> hyperair: yes
[11:28] <hyperair> directhex: who was it who did that one?
[11:28] <directhex> hyperair: policy guide is very detailed, but not a great starting point for all. especially the md->autofoo stuff
[11:28] <hyperair> directhex: actually i'm clueless about the MD part.
[11:28] <hyperair> directhex: i've never actually used MD before, aside from starting it up and then closing it again
[11:29] <dholbach> hyperair, directhex, Laney: meet rhlee
[11:30] <dholbach> rhlee: meet hyperair, directhex and Laney :)
[11:30] <hyperair> aha.
[11:30] <dholbach> so hyperair mentioned http://pkg-mono.alioth.debian.org/cli-policy/ and something that was discussed on a pkg-cli mailing list
[11:31] <rhlee> hyperair + directhex + Laney: hiya guys
[11:31] <hyperair> i can't seem to find the email. hmm
[11:31] <hyperair> hiya rhlee
[11:31] <dholbach> I don't think I can contribute much to the discussion, but thought it'd be worthwhile bringing you in touch :)
[11:31] <hyperair> yeah thanks
[11:33] <hyperair> so anyway, rhlee, i was wondering whether people were supposed to have read something before reading this proposed document
[11:33] <directhex> replied
[11:33] <directhex> sorry, been busy
[11:33] <rhlee> directhex: np
[11:34]  * hyperair didn't recv anything though
[11:34] <rhlee> yes, the ubuntu packaging guide was a recommended prequisite for the guide
[11:34] <rhlee> https://wiki.ubuntu.com/PackagingGuide/Complete
[11:35] <hyperair> rhlee: so the readers would know the difference between runtime vs build deps then?
[11:35] <rhlee> i would assume so, or it that too much of an assumption?
[11:36] <zyga> when packaging python libraries can I somehow simplify the duplication of depends and build-depends
[11:36] <zyga> my package has virtually identical depends as build-depends
[11:36] <rhlee> hyperair + directhex + Laney: fyi the guide I provisionally published is here https://wiki.ubuntu.com/PackagingGuide/Mono
[11:37] <hyperair> rhlee: i'm not sure, i haven't actually touched the packaging guide for a long time. these days i refer to the debian policy manual if i need reference
[11:37] <directhex> zyga: i assume there's some pythony way of auto-tracking depends, like shlibs:depends
[11:38] <zyga> directhex, there is python:Depends
[11:38] <zyga> directhex, but it's not very helpful in my case, it does not pick up anything I have (I don't know how it works)
[11:38] <hyperair> rhlee: well apart from that i don't see anything wrong with the guide except for minor spelling issues.
[11:40] <directhex> hyperair: cli:depends is in there, which would lead to better packages than the occasional interloper in the archive
[11:40] <rhlee> hyperair: so I probably should elaborate more on the difference between runtime and build dependencies?
[11:41] <hyperair> rhlee: that's up to you. i figure the standard packaging guide should already mention it, right?
[11:41] <hyperair> if that's so then fine, otherwise you might want to, yeah.
[11:41] <hyperair> rhlee: also i've just corrected your spelling on the wiki page.
[11:42] <hyperair> and... are you that afraid of spam? =p
[11:42] <rhlee> yes, the standard packaging guide does mention it
[11:43] <rhlee> hyperair: thanks for the corrections
[11:43] <hyperair> alright, then i think it's fine to leave it be like that.
[11:43] <hyperair> =)
[11:43] <hyperair> thanks for doing the documentation
[11:44] <hyperair> like directhex mentioned, this should lead to cli packages of better quality in the archive.
[11:44] <rhlee> hyperair: np, re my email address: if it safe to leave it in properly?
[11:44] <rhlee> hyperair + directhex: thanks for your help
[11:44] <rhlee> directhex: got your email will go through it
[11:45] <hyperair> rhlee: it depends on how much you trust your spam filters, i guess.
[11:45] <hyperair> rhlee: i trust gmail's.
[11:46] <rhlee> hyperair: I'll probably leave as is then
[11:46] <hyperair> rhlee: and either way my email is all over the place, specifically wherever Maintainer: is displayed, or changelog entries.
[11:48] <rhlee> hyperair: i guess I can alway get canonical to change my email address if there is too much spam
[12:01] <zyga> apachelogger, thanks, you've helped me to build two packages :-)
[12:54] <zyga> I have a source tree with a script.py, how can I remove the extension when creating a debian package?
[14:49] <Rhonda> I would need to do a SRU to lucid for ejabberd because of bug #596676
[14:50] <Rhonda> I take it the version should be 2.1.2-2lucid1, what to put into the target of the upload? just lucid? lucid-updates?
[14:51] <Laney> lucid-proposed
[15:18] <geser> Rhonda: as version 2.1.2-2.1
[15:18] <Rhonda> geser: Why -2.1?
[15:19] <Rhonda> Wouldn't that hint it was pulled in unmodified from Debian?
[15:20] <Laney> adding ubuntu0.1 is common
[15:20] <Laney> but really it's only necessary to make sure there is an upgrade path
[15:21] <geser> Laney is right, it should be -2ubuntu0.1 (I should do more SRUs to remember it better :) )
[15:23] <Rhonda> Given that maverick has 2.1.5-3 I don't think there is a need for 0.1
[15:23] <Rhonda> erm, 2.1.5-2
[15:24] <geser> that's just the usual versioning scheme: add .1 (and ubuntu0 if needed)
[15:25] <geser> https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update%20the%20packaging describes the versioning scheme used for security updates but it also works for SRUs (and is linked from the SRU page)
[15:27] <Rhonda> Right. But adding ubuntu1 also fulfills the requirements of "be newer than the version being patched, but earlier than any version in the development branch" :)
[15:29] <geser> I just wanted to point you to the usual SRU versioning scheme, I don't know if the uploads gets rejected if you use one that also works but is different
[15:36] <Rhonda> hmm, a #redirect ion wiki.u.c/SRU would be helpful
[15:37] <Rhonda> oh, seems to be there
[15:38] <Rhonda> Actually I even had chosen to go with 2.1.2-2lucid1  :)
[15:38] <geser> else ask our bot (!sru) it knows many things :)
[15:39] <ebroder> Rhonda: 2.1.2-2lucid1 would be a lower version number than 2.1.2-2ubuntu1, which is what maverick would have had if there had been an Ubuntu-only change. That's why you add the 0ubuntu
[15:39] <ebroder> Err...wait. Never mind. That particular case would have been fine
[15:39] <ebroder> But that's the sort of thing you're watching for
[15:39] <Rhonda> ebroder: It being lower is the whole point of it. :)
[15:40] <ebroder> I think what I meant to say is that putting it in the same form means you don't have to think about whether it's higher or lower
[15:40] <Rhonda> erm, if there already would had been a -2ubuntu1 in lucid, of course I'd bump it to ubuntu2
[15:40]  * ebroder goes and gets coffee
[15:41] <Rhonda> But right, schemas are a good thing to reduce discussions like this. Thanks. ;)
[15:42]  * Rhonda . o O ( and editing another page, removing jaunty and adding maverick )
[15:45] <Rhonda> What will happen after release of zippy zebra?
[15:46] <jmarsden> Rhonda: We can start using letters from the Greek or Russian alphabet? :)
[15:46] <achiang> move to a different charset?
[15:47] <Rhonda> That will be 17.04, if I calculated right …
[15:49] <geser> Rhonda: perhaps we can use till then Unicode in version strings
[15:50] <Rhonda> You'll have to get that past manoj. Somehow I doubt that.
[15:50] <Rhonda> And I fear there are no animal names starting with unicode letters.
[15:52] <geser> or do it like ms excel: after Z comes AA :)
[15:52] <Rhonda> welsh names? :)
[15:52] <directhex> Rhonda: we could use 😸
[15:52] <directhex> that'd be an awesome release name
[15:52] <Rhonda> I only see <?>
[15:52] <directhex> geser: not just excel: also /dev/sd*
[15:52] <directhex> Rhonda: well, by 2017 your font will include that glyph
[15:53] <Rhonda> directhex: haha
[15:53] <directhex> Rhonda: important letters like GRINNING CAT FACE WITH SMILING EYES must be added to all fonts
[15:53] <Rhonda> directhex: Take this: "
[15:53] <Rhonda> Edvard Munch wouldU+1F631 at Unicode 6 t-shirtsEdvard Munch wouldU+1F631 at Unicode 6 t-shirts
[15:53] <Rhonda> bleah, stupid paste
[15:53] <Rhonda> directhex: http://www.zazzle.com/Lalobee
[15:54] <directhex> Rhonda: FACE SCREAMING IN FEAR ?
[15:54] <Rhonda> yep
[15:55] <Rhonda> Actually I really think I should order me my own shirt. :)
[15:55] <directhex> geser: yes device nodes go that high: Disk /dev/sdai: 23998.3 GB,<PHONE_NUMBER>2992 bytes
[15:55] <Rhonda> One of the most geeky ones, to be honest.
[16:01] <ari-tczew> if package has depends with [linux-any], it will works?
[16:03] <geser> should, I know I filed bugs about it and if I remember correctly they got fixed
[16:03] <ari-tczew> geser: but you mean Build-Depends or Depends?
[16:04] <geser> Build-Depends as this was a problem for the buildds
[16:04] <geser> Depends are handled by apt itself so should be less an issue
[16:04] <ari-tczew> geser: aha, ok
[16:06] <cjwatson> not to spoil the fun but I think Mark said we'd just cycle (though he might change / have changed his mind)
[16:06] <geser> and if I'm not mistaken [arch] isn't supported in Depends (but I have to check the Debian policy to be sure), but our fellow DDs might know it too
[16:07] <cjwatson> it is, fairly recently
[16:07] <cjwatson> provided the package is not Architecture: all
[16:07] <cjwatson> build-depends on [linux-any] were fixed - https://bugs.launchpad.net/launchpad-buildd/+bug/604981
[16:07] <cjwatson> I *think* it's basically OK now
[16:08] <cjwatson> https://bugs.launchpad.net/soyuz/+bug/669404 (Packages-arch-specific) is still open but not a major problem for most people
[16:10] <geser> the upload part for linux-any got also fixed (bug 605002)
[16:11] <cjwatson> indeed
[16:13] <ari-tczew> ok, I'm only asking
[16:13] <ari-tczew> BlackZ: ^^
[16:25] <kaushal> Hi
[16:25] <kaushal> https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/379329
[16:26] <kaushal> It says it has been fixed This bug was fixed in the package openssh - 1:5.2p1-1ubuntu1
[16:26] <kaushal> is this version available in hardy 8.04
[16:26] <kaushal> please suggest
[16:26] <ScottK> No.  It's not.
[16:27] <kaushal> oh i see
[16:27] <kaushal> so i need to add Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc
[16:27] <kaushal> in sshd_config and ssh_config
[16:27] <kaushal> ?
[16:28] <kaushal> and restart the sshd daemon
[16:28] <kaushal> as per that bug instruction
[16:28] <ScottK> I didn't read the bug, but if it gives a work around, you'll likely need it.
[16:29] <kaushal> ok
[19:18] <apachelogger> ulysses: about the build-dep change ... it is correct, and maybe not, if the code really only works with Qt >= 4.7 it is correct, if it is not the minimum requirement it is less correct (still good enough for me though :))
[19:18] <apachelogger> zyga: groovy :D
[19:26] <sebner> apachelogger: so, how did the test went?
[19:26] <sebner> *go
[19:34] <ricotz> sebner, hi
[19:38] <sebner> ricotz: hola
[19:38] <apachelogger> sebner: not terribly well
[19:39] <ricotz> sebner, could you help with a autotools problem?
[19:39]  * apachelogger is targetting ballmer peak right now -> free work hours from apachelogger this evening
[19:39] <sebner> apachelogger: don't worry, the next text surely comes :D
[19:39] <apachelogger> unfortunately :P
[19:40] <sebner> :D :D :D
[21:43] <ari-tczew> could someone ping me?
[21:43] <sebner> ari-tczew: ping
[21:43] <ari-tczew> sebner: could you again ping in next 10 seconds?
[21:44] <sebner> ari-tczew: ping
[21:44] <ari-tczew> sebner: I'm trying to reproduce bug in indicator-applet. I have to minimalize to tray.
[21:45] <ari-tczew> Rhonda: ping on chat, here :P
[21:45] <Rhonda> that's hilight, not ping
[21:48] <bdrung> ari-tczew: you could use two different irc apps and ping yourself in an self-created channel
[21:48] <sebner> Rhonda: ah!
[21:50] <ari-tczew> sebner, bdrung, Rhonda: That's right, my fault. I should say highlight. Sorry.
[21:52] <ari-tczew> Rhonda: could you then highlight me again? ;)
[21:52] <micahg> ari-tczew: you can have ubottu do it
[21:52] <Rhonda> I didn't hilight you before, and like bdrung noticed, you could actually do it for yourself with a second client, and using a test channel instead of in here.
[21:53] <bdrung> (that's what i do for debugging)
[21:53] <Rhonda> Actually when I have to test something with irssi which I maintain I fire up several instances and /join #randomfoo
[21:54] <ari-tczew> micahg: good point
[21:54] <ari-tczew> micahg: but I'm not sure whether he can hightlight me with delay :>
[21:55] <micahg> ari-tczew: which can be done in a PM as well, if you need a channel though, what the others have suggested is probably best
[21:55] <bdrung> ari-tczew: and you probably don't want your debugging stuff logged ;)
[21:56] <ari-tczew> bdrung: in this case I don't care
[21:56] <Rhonda> Actually we do :)
[21:56] <ari-tczew> don't be inflexible ...
[21:57] <ari-tczew> you can include this one to your report about my bad behavior!
[21:57] <micahg> ari-tczew: keep in mind there are 194 people in this channel that see all your tests
[21:58] <Rhonda> Actually such kind of responses to well-meant advices isn't really helping your case  :/
[21:59] <ari-tczew> Rhonda: very terrible. going back to my activities...
[22:03] <bdrung> ebroder: i included http://pastebin.ubuntu.com/532617/ and  it covers only 75% of the bugs. what should we do with merge requests?
[22:03] <ebroder> bdrung: for merge requests I'm assuming you just want to use when the request was created, no?
[22:03] <micahg> bdrung: separate section?  some sponsors aren't comfortable with them yet
[22:06] <ebroder> bdrung: The MPs that get listed on the queue currently are using the date the proposal was created, so that seems fine
[22:28] <bdrung> ebroder: MPs?
[22:28] <ebroder> merge proposals
[22:31] <bdrung> ebroder, micahg: please have a look at http://people.ubuntu.com/~bdrung/sponsoring/
[22:33] <micahg> bdrung: it's not grabbing the time for ubuntu-security-sponsors subscriptions
[22:34] <micahg> bdrung: also, can we sort by time in queue (not sure if ASC or DESC is more appropriate) with unknown going to the back of the queue?
[22:34] <bdrung> that's the current patch: http://pastebin.com/1Kfvyatn
[22:35] <micahg> bdrung: when I load the page, it's sorting by Date created ASC
[22:35] <bdrung> micahg: you can click on the column
[22:35] <ebroder> bdrung: Try changing line 56 of the diff to something like if activity.message in ["added subscriber Ubuntu Sponsors Team", "added subscriber Ubuntu Security Sponsors Team"]:
[22:35] <ebroder> or whatever they call themselves
[22:36] <micahg> bdrung: right, I know, but shouldn't the default reflect the more accurate order of time in queue vs date bug is created?
[22:37] <ScottK> It should be sortable the same ways an LP bug list is sortable.
[22:39] <ebroder> I'm having a hard time figuring out how to make an "unknown" value sort as being in the queue longer than anything else
[22:39] <micahg> ScottK: I think all the columns are sortable, my question was what the default view should be
[22:39] <ebroder> Maybe defaulting to 1970-0101?
[22:39] <ScottK> OK.
[22:39] <ari-tczew> geser: could you update also queue of task on Agenda?
[22:40] <ari-tczew> 2 requests have been added without number.
[22:40] <micahg> ebroder: well, maybe an s/-// and and then do a numeric comparison?
[22:42] <ebroder> micahg: sorttable.js can already deal with fields in a date format
[22:42] <micahg> ebroder: oh, cool
[22:42] <ebroder> but it guesses teh type of a column based on the first non-blank row
[22:43] <micahg> ebroder: can you hint as to the column type?
[22:43] <ebroder> Not that that matters, because a purely lexical sort would work, too
[22:43] <ebroder> micahg: Not that I see
[22:44] <geser> ari-tczew: done
[22:44] <bdrung> ebroder: no, the unknown items are at the wrong end
[22:44] <ebroder> micahg, bdrung: Oh wait, hmm...it looks like you can set a sorttable_customkey attribute on the <td> html tag
[22:44] <ebroder> So for unknown rows, do <td sorttable_customkey="0">unknown</td>
[22:44] <ebroder> Or thereabouts
[22:46] <bdrung> <td sorttable_customkey="0">unknown</td> doesn't seam to work
[22:46] <ebroder> I'm probably mis-reading the code
[22:46] <bdrung> now it doesn't sort it correctly
[22:48] <ebroder> oh - it's probably deciding that the column is numeric instead of dates
[22:48] <ebroder> What about sorttable_customkey="1970-01-01"?
[22:49] <ebroder> http://www.kryogenix.org/code/browser/sorttable/#customkeys is what I'm looking at, btw
[22:49] <bdrung> ebroder: yes, that works
[22:50] <bdrung> ebroder: but that's not valid xhtml
[22:51] <ebroder> bdrung: Yeah, that thought occurred to me. Not sure if there's a great answer for that
[22:51] <micahg> bdrung: what's not?
[22:51] <ebroder> micahg: Any of sorttable's custom attributes
[22:52] <micahg> ebroder: because of the underscore?
[22:52] <ebroder> micahg: Because XHTML specifies what attributes an element can have
[22:54] <micahg> here's the bug for that: http://www.kryogenix.org/bugs/sorttable/data-attributes.html
[22:55] <micahg> bdrung: use the XHTML transitional DTD?
[22:55] <bdrung> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
[22:57] <bdrung> micahg: IIRC xhtm 1.1 doesn't have a transitional dtd
[22:57] <micahg> no, I guess not
[22:57] <ebroder> Downgrade?
[22:57] <bdrung> why not fix it by getting the unknown ones from the list?
[22:58] <micahg> bdrung: I think they were added before there were logged
[22:58] <micahg> except for the security sponsors one
[22:58] <ebroder> micahg: Actually, my theory is that it relates to the ubuntu-{universe,main}-sponsors -> ubuntu-sponsors transitions
[22:59] <micahg> we could just unsub/resub and bump to front of queue?
[22:59] <ebroder> Look at the 4th from the bottom on https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/44609/+activity for instance
[22:59] <micahg> ebroder: yeah, that seems to be part of it
[22:59] <ebroder> It's a queue not a stack! :-P
[22:59] <ebroder> (At least in theory...)
[22:59] <micahg> ebroder: hence I said front and not top :)
[23:00] <micahg> depending on how you look at it
[23:00] <bdrung> ebroder: it's a queue with random access :P
[23:00] <micahg> or back I guess if you're going from the oldest (which I don't think most people do)
[23:01] <bdrung> sponsors bunch :)