[20:44] <Elliria> Hey there. Is editing or updating of the https://lists.ubuntu.com page handled by the Ubuntu Doc team?


[17:20] <hwpplayer1> I signed the Canonical Agreement, will Canonical call me someday ?
[17:23] <meena> hwpplayer1: I've never had anyone call me since 2017? 2016?
[17:23] <hwpplayer1> understood meena Thanks
[17:27] <meena> hwpplayer1: are you kallioli / kadiron?
[17:28] <hwpplayer1> no I don't know what it is meena
[17:28] <meena> https://github.com/canonical/cloud-init/pull/2157 the person working on this pr
[17:28] -ubottu:#cloud-init- Pull 2157 in canonical/cloud-init "Added / fixed support for static routes on OpenBSD and FreeBSD" [Open]
[17:31] <hwpplayer1> No I am not kadiron :)
[17:31] <hwpplayer1> meena: ^
[17:37] <meena> aye
[18:01] <meena> what is this nonsense https://github.com/search?q=repo%3Acanonical%2Fcloud-init%20opensource.guide&type=code


[13:49] <Gargravarr> hey all, on Launchpad trying to log into the bug tracker, is there any reason my Ubuntu One account isn't being accepted and i'm being told to 'Go away' for being a 'Bad bot'?
[13:49] <Gargravarr> i've tried on latest Firefox with no plugins and default settings, on both Ubuntu and MacOS
[13:50] <Gargravarr> about to try Chrome, but i think our office IP may have been blacklisted
[13:52] <Gargravarr> okay, wrong, it works in Chrome
[14:00] <tomreyn> Gargravarr: i believe Gargravarr's issue was resolved in #ubuntu
[14:01] <Gargravarr> yes, i was about to say as such :)
[14:02] <Gargravarr> this is the issue i ran into: https://askubuntu.com/questions/650544/login-launchpad-net-tells-me-bad-bot-go-away-request-aborted
[14:02] <Gargravarr> and yes, when i said no plugins, i neglected to mention Lastpass
[14:03] <Gargravarr> can i point out, this seems a very silly way to detect bots as it breaks password managers


[04:03] <i-node> helo
[04:03] <i-node> hello*
[06:41] <twb> Does qemu-system-arm work *at all* on lucid?
[06:51] <twb> Hm, same behaviour on sid
[07:30] <twb> I give up, qemu-system-arm won't work for me on lucid, and the only non-lucid host I have, is a shitty little Atom netbook (where it works, but unbearably slowly)
[07:30] <twb> I will just reflash the TF101 again with ubuntu so that I have something to actually do compiles on
[17:36] <MMlosh> Grr..  the Oneiric kernel froze again..  (pandaboard with 2 DVB-T tuners atached)
[19:26] <Daviey> janimo: Hey!  Can you confirm the bump is correct on linux-ac100?
[19:26] <Daviey> New package: linux-ac100 (universe) [2.6.38-1.3 → 2.6.38-1000.1]
[19:26] <janimo> Daviey, yes
[19:26] <Daviey> janimo: What is the reasoning?
[19:26] <janimo> I am about to upload the linux-meta-ac100 so it is in universe by tomorrow
[19:27] <janimo> Daviey, I started with a new packaing using git
[19:27] <janimo> and followed a tutorial and existing ubuntu/linaro numbering convention
[19:27] <janimo> probably not needed in this case but I played it safe
[19:27] <Daviey> janimo: I don't follow?  Where does it state jump to 1000?
[19:27] <janimo> being my first time packaging a kernel by lots of trial and error eve
[19:28] <janimo> Daviey, it doe snot, the linaro template I started with uses 1000.0
[19:28] <janimo> and all linaro kernels use such large abi numbers afaik
[19:28] <janimo> omap 1200, landing team ones 1400 etc
[19:29] <Daviey> seems odd, but ok
[19:29] <Daviey> infinity: ^^
[19:30] <janimo> Daviey, tbh it seemed odd to me too, but if I were to question or dig into everything that seems odd to me in kernel packaging it would take me a lot more to get something ready
[19:31] <janimo> not one of the tutorials were 100% correct or covered the various cases, jcrigby's one is the closest and best yet
[19:32] <janimo> Daviey, at leats this package is now maintained in git and more or less in sync with how the kernel team and linaro manage their kernels
[19:32] <infinity> That works for me.
[19:32] <Daviey> janimo: heh, it's a black art that i don't understand either... The changelog generation blows me :)
[19:32] <janimo> I even plan to upload it to the kernel repos so it is not only on my disk
[19:33] <janimo> Daviey, I thought I understood everything about the changelog, when an innocent change in it (well version number addition _before_ the last one) tripped the ABI checker
[19:33] <infinity> Would it surprise you to know that most of the kernel team doesn't know how the packages are built either? ;)
[19:33] <infinity> A lot of that stuff is from BenC and I fiddling years ago.
[19:33] <janimo> at which point I deferred work to next morning being an unexpected error after I thought I had ironed out all issues and built the package a few times already
[19:33] <janimo> so I try to touch as little as possible
[19:33] <infinity> The fact that it's survived is a testament to opaque code that no one wants to touch.
[19:33] <Daviey> heh
[19:33] <janimo> and learn more as I upload new revisions
[19:34] <janimo> infinity, that would not surprise me in the least actually
[19:34] <infinity> janimo: To fully understand it, you have to first understand Ben Collins.  After rooming with him at many conferences, I don't recommend it.
[19:35] <janimo> and also it does not scale well
[19:35] <janimo> would need many many conferences or very large rooms
[19:35] <infinity> (That's not to say that I have anything against the guy, we're great friends, just warning that insanity may ensue)
[19:36] <Daviey> infinity: I think you might want to room with lag.
[19:36] <infinity> I don't need to corrupt any more Canonical employees, past, future, or present.
[19:37] <infinity> For the good of the company, I should probably always room alone. :P
[19:38] <Daviey> heh
[19:38] <janimo> infinity, how selfless, you are.
[19:38] <Daviey> infinity: I was more worried he'd corrupt you. :)
[19:38] <infinity> Seems unlikely.
[19:38] <infinity> But I'm always willing to be surprised.
[19:39] <infinity> jcrigby: LINARO: always build debug packages
[19:40] <infinity> jcrigby: ^-- From your recent uploads.  Don't we have that turned off for distro kernels (to avoid duplication of massive packages between -dbg and .ddeb)?
[19:40] <jcrigby> crap
[19:41] <jcrigby> that was a change for linaro ppa
[19:41] <infinity> I figured.
[19:41] <jcrigby> because we wanted the debug stuff
[19:41] <jcrigby> infinity, ok educate me
[19:41] <infinity> Because PPAs don't do ddebs, yes.  Longstanding feature request for that in LP. :P
[19:41] <jcrigby> so my fix didn't fix because it still goes to ddeb
[19:42] <jcrigby> it just always does it
[19:42] <infinity> Oh, in which case, these are fine for the primary archive. ;)
[19:42] <jcrigby> right
[19:42] <infinity> And you still need a better fix for your PPA, I guess.
[19:42] <jcrigby> so two wrongs make a right
[19:42] <jcrigby> yes, I need to not do the rename to ddeb
[19:42] <jcrigby> in ppa
[19:43] <jcrigby> so the debug stuff will just stick around like a normal deb
[19:43] <infinity> You can cheat and use archive_purpose to conditionally rename.
[19:43] <infinity> I'm a bit shocked the default templates don't do that.
[19:43] <jcrigby> you can tell me what the current stuff does
[19:44] <jcrigby> it looks in / for some file
[19:44] <jcrigby> let me look
[19:44] <infinity>  /CurrentlyBuilding
[19:44] <jcrigby> yes
[19:44] <jcrigby> and uses that to decide if it is a local developer build or an archive build
[19:45] <jcrigby> if that file exists it sets fullbuild or somesuch
[19:45] <infinity> Kay, but if you check the value of it, you can get more in-depth.
[19:45] <jcrigby> then later do_debug get set or not based on full_build
[19:46] <janimo> infinity, jcrigby a meta package should just need a changelog bump and debian/rules will DTRT on build?
[19:46] <infinity> janimo: Depends on the meta source.  But that's how most work.
[19:47] <janimo> ok, this is ogra's ac100 meta. Should work as it has no magic besides the debian/ dir in it
[19:47] <infinity> jcrigby: You can see in build logs that Purpose is actually set to a value in that file.
[19:47] <jcrigby> ok so packages are ok except for crappy short changelog
[19:47] <infinity> jcrigby: (Check the sbuild call for '--purpose='
[19:48] <infinity> jcrigby: For instance for primary archive, it's --purpose=PRIMARY
[19:48] <jcrigby> ahh
[19:48] <janimo> infinity, linux-meta-ac100 uploaded, fingers crossed, etc
[19:48] <infinity> jcrigby: For PPAs, it should be PPA, but double-check one of your build logs. :P
[19:48] <jcrigby> wow, I need to hang out with infinity for a week of intense training
[19:48] <jcrigby> ok, I'll do that
[19:48] <jcrigby> infinity, is this documented anywhere?
[19:48] <jcrigby> or just in package masters heads?
[19:48] <infinity> jcrigby: *mumbles something about the launchpad source code*
[19:49] <jcrigby> :)
[19:49] <infinity> jcrigby: I'd be willing to bet that about 5 people know how this works, and 2 don't work here anymore.
[19:54] <infinity> jcrigby / janimo : Kernels all accepted, after some very generous review.  May $diety have mercy on your souls if they all break. :P
[19:55]  * infinity really goes to find food this time.
[19:56] <janimo> infinity, thanks
[19:57] <infinity> jcrigby: Even for subarches like this where we're not building official images, it would be swell if, next cycle, you keep slightly more in sync.  Diffs that large a 2 weeks before RC are a bit scary.
[19:58] <infinity> s/a 2/2/
[19:59] <jcrigby> I agree
[20:00] <jcrigby> I need to make the ubuntu upload part of my normal workflow even though we (linaro) consume kernels from ppa
[20:04] <infinity> Certainly until we hit kernel freeze, anyway.
[20:04] <infinity> Then you need to get picky and potentially fork.
[20:29] <jcrigby> infinity, are you back from lunch
[20:29] <jcrigby> ?
[20:30] <infinity> jcrigby: I keep forgetting to start lunch.
[20:30] <infinity> jcrigby: 'sup?
[20:31] <jcrigby> so did I understand that I can look inside /currentlywhatever to figure out if I am ppa or normal or ...
[20:31] <infinity> jcrigby: Yup.
[20:32] <infinity> jcrigby: "Purpose: PPA" or "Purpose: PRIMARY" for PPA versus primary archive.  There are a few other possible values (PARTNER, etc), but those are probably the only two you care about.
[20:32] <infinity> jcrigby: And no /CurrentlyBuilding at all can generally be assumed to be "user machine, or non-LP buildd".
[20:32] <jcrigby> ok those two are all I need, thanks
[20:32] <jcrigby> right
[20:32] <jcrigby> thanks, I now need to go fix debug for ppa again
[20:33] <jcrigby> but conditionaly so i don't break primary
[20:33] <infinity> If and when we get around to merging the archive sbuild and the buildd sbuild, this might become more easily testable.
[20:33] <jcrigby> sure
[20:34] <infinity> And someone should probably hack up some CurrentlyBuilding support into pbuilder for similar "pretend I'm a buildd" testing reasons.
[20:34] <Daviey> infinity: I started doing that for sbuild
[20:34] <infinity> The upshot of that is that it would de-facto document it all.
[20:35] <infinity> Daviey: You're not the only one. :P
[20:35] <Daviey> infinity: CurrentlyBuilding support requires to know the component, which means it is network bound - or you have to delcare it at spawn, i guess?
[20:35] <infinity> Daviey: On the buildds, it's declared when you start the job.
[20:36] <infinity> Daviey: --component=foo --purpose=bar
[20:36] <Daviey> yeah, but launchpad is lucky enough to know the compoent.
[20:36] <Daviey> :)
[20:36]  * Daviey looks up what a compoent is
[20:36] <infinity> Daviey: That's more than enough to get people to be able to match the archive behaviour for reproducibility.
[20:37] <infinity> Daviey: I'd argue that if you don't know what component your source package is in, you probably shouldn't be uploading it. :P
[20:37] <Daviey> infinity: Incidently, i came acorss a package which built fine in pbuilder and sbuild, but failed on the buildd's.  Grabbing the LP chroot, and throwing it into pbuilder allowed me to debug it
[20:38] <Daviey> infinity: Well, my usecase was automated builds.. so thar! :)
[20:38] <infinity> Daviey: Yeah, for doing automated rebuilds or something, you could still cheat with the apt Sources.gz and grep-dctrl or some such.
[20:38] <infinity> Daviey: It wouldn't be up-to-the-minute accurate, but close enough.
[20:39] <infinity> But you'd want that sort of logic in a wrapper, not in pbuilder/sbuild themselves.
[20:39] <infinity> pbuilder and sbuild should just trust user input.
[20:39] <infinity> Not be clever.
[20:40] <Daviey> Oh aye.. that is what i was doing
[20:41] <Daviey> infinity: Incidently, i'd like to steal LP's Architecture: $target handling.. Need to see if/how that is exposed via API.
[20:42] <infinity> Hrm?
[20:43] <infinity> Not sure I know which Arch handling you're referring to.
[20:44] <infinity> You mean the part where it selects arch_indep for i386, and passes '-A' to sbuild?
[20:47] <infinity> If so, that's exposed via the API.  See is_nominated_arch_indep at https://api.launchpad.net/devel/ubuntu/oneiric/i386
[20:47] <infinity> Daviey: Was that what you were driving at? ---^
[20:49]  * infinity lunches for real this time.  Honest.
[20:59] <Daviey> infinity: Well that yes, but also processing of linux-any, and the others
[20:59] <Daviey> Although, not really an sbuild issue itself.
[21:00] <Daviey> for each package
[21:03] <infinity> Daviey: http://paste.ubuntu.com/463055/ <-- The patch that was applied to lp-buildd's sbuild to handle linux-any.
[21:03] <infinity> Though, I'd assume the distro sbuild does the right thing anyway.
[21:05] <Daviey> ah, nice


[14:57] <smoser> harlowja, thoughts:
[14:57] <smoser> https://code.launchpad.net/~vlastimil-holer/cloud-init/net-reconfigure/+merge/186352
[17:09] <pedroalvarez_> Hi, I have configured cloud-init in a linux image, but when I boot the image, the systemd services crash. When I start them manually it works. What could it be?
[17:12] <smoser> pedroalvarez_, i'm not sure. i've never used systemd.
[17:12] <smoser> what is 'crash' ?
[17:12] <smoser> logs ?
[17:17] <pedroalvarez_> smoser: http://paste.ubuntu.com/6124789/
[17:17] <harlowja> ya, maybe logs, i haven't used systemd either myself (yet)
[17:19] <smoser> well it sure thinks it failed to create the user
[17:19] <pedroalvarez_> If I do: `systemctl start cloud-init` it works.
[17:19] <pedroalvarez_> And if I reboot the image, sometimes it starts.
[17:20] <pedroalvarez_> I want cloud-init to execute commands at boot time, through the "customization-script" of OpenStack
[17:21] <harlowja> ya, thats fine
[17:21] <harlowja> pretty normal use-case
[17:21] <pedroalvarez_> And, correct me if I am wrong, the services running are essential
[17:21] <harlowja> likely :)
[17:21] <harlowja> *likely u are right
[17:22] <harlowja> pedroalvarez_ is this systemd via fedora
[17:22] <harlowja> or systemd via some other distro?
[17:23] <pedroalvarez_> customized core linux
[17:23] <pedroalvarez_> baserock
[17:26] <pedroalvarez_> I have located the systemd files on /etc/systemd/system
[17:26] <pedroalvarez_> And I made a symlink in /lib/systemd/system/multi.user.bla.wants
[17:27] <pedroalvarez_> Also in /lib/systemd/system/
[17:27] <harlowja> hmmm, eck, defintly outside of my area of expertise :(
[17:28] <pedroalvarez_> smoser: Does the install script try to copy them?
[17:28] <pedroalvarez_> harlowja: no worries :) tvm
[17:29] <harlowja> pedroalvarez_ can u just use the init.d versions instead of the sytemd ones?
[17:29] <harlowja> that might work better, idk
[17:29] <pedroalvarez_> harlowja: I'll try init.d version then :) thanks
[17:29] <harlowja> those work on RHEL6 and such
[17:30] <harlowja> and i know the upstart ones work
[17:30] <harlowja> since smoser  uses them
[17:30] <harlowja> the systemd ones i think work with fedora, but i don't know if smoser or me have to much experience with them
[17:32] <smoser> yeah, i have no idea on systemd.
[17:32] <smoser> harlowja, did you see above?
[17:32] <harlowja> smoser that review looks ok, an interesting approach with the 'pretend'
[17:32] <smoser> why is it 'pretend' ?
[17:32] <smoser> what was that for. i didn't understand.
[17:32] <harlowja> def _write_network(self, settings, pretend=False)
[17:33] <smoser> right. what is that doing ?
[17:33] <smoser> other than for testing. why would i want that.
[17:33] <harlowja> ah, k, got your question
[17:33] <harlowja> digging deeper, incase i missed why its being used, ha
[17:34] <harlowja> i think its for
[17:34] <harlowja> dev_names = self._write_network(settings, pretend=True)
[17:34] <harlowja> self._bring_down_interfaces(dev_names)
[17:34] <harlowja> which is like a way to figure out the device names to bring down
[17:35] <harlowja> although i would think its a little convoluted :-P
[17:35] <harlowja> just have a 'list_interfaces' function and bring those down, ha
[17:35] <harlowja> so from my understanding, whats happening
[17:36] <harlowja> is that its pretending to write out the network interfaces, the result of this gives u the device names, and then the code is ifdown those
[17:36] <harlowja> and then it writes out in non-pretend mode
[17:36] <smoser> so the reason for this being is https://bugs.launchpad.net/cloud-init/+bug/1225922
[17:37] <smoser> in short, if the system is booting, eth0 might have already been 'ifup'ed. and then we write a new /etc/network/interfaces file.
[17:37] <harlowja> gotcha
[17:37] <smoser> (ifup'ed successfully or non-successfully)
[17:37] <smoser> we need to bring it down and then back up.
[17:37] <smoser> and ideally we dont run 'ifdown -a'
[17:37] <harlowja> so the pretend thing is really just a way to list the interfaces by using the same code that writes out the interfaces (which returns a list of device names)
[17:37] <smoser> and 'ifup -a'
[17:37] <smoser> (although that i a hacky solution)
[17:38] <smoser> ah.
[17:38] <harlowja> pretend make sense now?
[17:38] <harlowja> thats my interpreation
[17:38] <smoser> but where does he call with 'pretend'?
[17:39] <smoser> ah. i see.
[17:39] <harlowja> 19	+ if bring_up:
[17:39] <harlowja> 20	+ dev_names = self._write_network(settings, pretend=True)
[17:39] <harlowja> 21	+ self._bring_down_interfaces(dev_names)
[17:39] <harlowja> it is a little convoluted i guess, haha
[17:40] <harlowja> a function like 'list_interfaces(settings)'
[17:40] <harlowja> that returns the device names
[17:40] <harlowja> probably would be clearer to understand
[17:40] <smoser> yeah.
[17:40] <smoser> parse the existing
[17:40] <smoser> parse the new
[17:41] <harlowja> ya, since all that write_network does is parse settings and write out a file
[17:41] <harlowja> *or files
[17:42] <harlowja> want me to comment on that review
[17:42] <harlowja> or u got it under control boss
[17:47] <pedroalvarez_> Ok, after see that cloud-init service tries to create an "ubuntu" user, and then another service tries to use "apt", I think it thinks I'm running ubuntu
[17:51] <harlowja> :)
[17:51] <harlowja> haha
[17:51] <pedroalvarez_> hahahahaha
[17:51] <harlowja> ya, so u need to edit the cloud.cfg for that
[17:52] <pedroalvarez_> harlowja: good news then?
[17:52] <harlowja> yup
[17:52] <harlowja> # System and/or distro specific settings
[17:52] <harlowja> # (not accessible to handlers/transforms)
[17:52] <harlowja> system_info:
[17:52] <harlowja>  # This will affect which distro class gets used
[17:52] <harlowja>  distro: rhel
[17:52] <harlowja> something like that
[17:52] <harlowja> you are probably using the default ('ubuntu')
[17:52] <harlowja> and the other part is what modules u have left active by default in cloud.cfg
[17:53] <harlowja> some of them are more ubuntu speicfic
[17:53] <harlowja> *aka ones starting with 'apt' and such
[17:53] <harlowja> all smoser  fault, ha
[17:54] <pedroalvarez_> The other problem of initialization is just because cloud-init needs ssh services running, and cloudinit doesn't wait I think.
[17:54] <smoser> harlowja, i'd appreciately comement.
[17:54] <smoser> pedroalvarez_, the user is configurable.
[17:55] <pedroalvarez_> smoser: that's cool
[18:11] <pedroalvarez_> I think I found all my problems on this file! :)
[18:12] <harlowja> :)
[18:12] <pedroalvarez_> I'm going home happy today
[18:12] <pedroalvarez_> I owe you a couple of beers
[18:13] <harlowja> ha
[18:13] <harlowja> np
[18:13] <harlowja> cloud.cfg is the magic file
[18:24] <smoser> cloud.cfg is the magic.
[18:24] <harlowja> all the magic