[01:24] <mup> PR snapcraft#3580 closed: environment-setup-local: do not build rust <Created by xnox> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3580>
[02:14] <mup> PR snapcraft#3581 closed: packaging: load the correct libraries on riscv64 <Created by xnox> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3581>
[10:30] <mup> Bug #1944032 opened: uappexplorer-cli | No apps found <Snappy:New> <https://launchpad.net/bugs/1944032>
[10:33] <mup> Bug #1944032 changed: uappexplorer-cli | No apps found <Snappy:New> <https://launchpad.net/bugs/1944032>
[10:42] <mup> Bug #1944032 opened: uappexplorer-cli | No apps found <Snappy:New> <https://launchpad.net/bugs/1944032>
[22:55] <dust> tiled: This application failed to start because it could not find or load the Qt platform plugin "wayland-egl"


[01:10] <ButterflyOfFire> hi we would like to invite a bot to our chan
[01:10] <ButterflyOfFire> Can you help us please ?
[01:10] <ButterflyOfFire> Our irc chan is #ubuntu-dz
[01:13] <ButterflyOfFire> Thanks [NikO] ;) merci
[01:14] <[NikO]> >>> nalioth :)
[01:14] <ButterflyOfFire> ;)
[01:15] <nalioth> you're welcome
[01:15] <ButterflyOfFire> nalioth: thanks
[01:16] <ButterflyOfFire> Is the bot ubot3 logging the chan #ubuntu-dz since it is invited in ?
[01:18] <Myrtti> ButterflyOfFire: no, it's not a logbot
[01:18] <ButterflyOfFire> ok Myrtti
[01:18] <ButterflyOfFire> I'm trying to read on the Wiki ;)
[01:22] <ButterflyOfFire> So for the LoCoBot I've to contact<EMAIL_ADDRESS>?
[01:24] <[NikO]> ButterflyOfFire, or ping zed
[01:28] <ButterflyOfFire> :)
[01:28] <ButterflyOfFire> yes [NikO]
[01:43] <ButterflyOfFire> [NikO], or ping zed
[03:06] <ButterflyOfFire> Hi again, may I ask you for cloaking ?
[03:13] <mneptok> are you an Ubuntu member?
[03:14] <ButterflyOfFire> Yes I've an account on Lauchpad
[03:14] <ButterflyOfFire> Launchpad*
[03:14] <tritium> ButterflyOfFire: that's not quite the same thing.
[03:15] <ButterflyOfFire> ok
[03:17] <stdin> ButterflyOfFire: if you want an unaffiliated cloak, join #freenode and ask
[03:17] <ButterflyOfFire> thanks stdin
[03:17] <ButterflyOfFire> :)
[05:18] <stefanlsd> PriceChild: grouped my nick - https://edge.launchpad.net/~stefanlsd
[07:56] <elkbuntu> who was the russian representative here? they may want to talk to zloy about why goatse-style tricks are *really* inappropriate for #ubuntu channels.
[08:36] <Myrtti> they have been getting more obnoxious at #ubuntu of late
[08:36] <Myrtti> and I'm seeing them collecting a group at -women
[10:50] <bazhang> zloy has been removed for evading kline
[10:50] <Myrtti> he has been a troublesome guy, he and his friends
[10:51] <elkbuntu> at least they've left -women alone this time
[10:51] <bazhang> another to watch is vbooh and polatov
[18:01] <LjL> TheInfinity: i'm trying to find out who requested the bot on #kubuntu-de
[18:01] <TheInfinity> hello. one question. since some time we have a locobot in our channel (#kubuntu-de) although nobody reuested it (i asked most of our team). why is it there? :)
[18:01] <TheInfinity> LjL: ok thanks
[18:02] <LjL> TheInfinity: those bots are not managed by us, so it might take a while both to find out and to sort it out
[18:03] <TheInfinity> LjL: no problem, we just wondered as we have seen the bot today
[18:04] <[NikO]> TheInfinity, ask zed
[18:52] <LjL> TheInfinity, the bot was probably put there by mistake, it's not entirely clear. if you don't want it, you need to send an email to<EMAIL_ADDRESS>- if you also want the logs deleted, say so
[18:53] <TheInfinity> LjL: i cant't find the logs at irclogs.ubuntu.com. are they saved somewhere else?
[18:53] <LjL> TheInfinity: while you wait for a response, you can of course just kick it
[18:53] <LjL> !logs
[18:54] <TheInfinity> LjL: ok thanks for your help! i'll ask my team how to go on.
[20:13] <TheInfinity> LjL: should i ask you for deleting the logs or should i write it via mail?
[20:34] <nalioth> TheInfinity: logs can't be deleted  :(
[20:34] <nalioth> google, yahoo, and every other search engine has already indexed them
[20:35] <TheInfinity> yea but they will delete it some day?
[20:39] <nalioth> when the sun goes dormant
[20:46] <LjL> TheInfinity, you should ask via email, i cannot control those bots and logs in any way personally
[20:47] <TheInfinity> LjL: i'll do so. thanks :)
[21:46] <juliux> LjL: locobot was in #kubuntu-de allready in 2005/2006 but then they decide they don't want the locobot so they banned the bot with<EMAIL_ADDRESS>but now the bot is cloacked to he can rejoin the channel
[21:47] <LjL> juliux: well, that's clearly not the best way to out out from the service...
[21:47] <LjL> *rolls eyes*
[21:48] <juliux> LjL: http://logs.ubuntu-eu.org/free/2005/12/01/%23kubuntu-de.html there you can see that the bot was in 2005 allready there
[21:48] <Myrtti> I can't understand though why you don't want it there
[21:48] <Myrtti> but I'm just me
[21:49] <juliux> there the bot was kicked out http://logs.ubuntu-eu.org/free/2006/03/24/%23kubuntu-de.html
[21:50] <juliux> so it looks if the channel was never removed from the join list;)
[21:52] <LjL> i see
[21:52] <juliux> 13:23 -!- locobot_2<EMAIL_ADDRESS>has joined #kubuntu-de
[21:52] <juliux> that was at 2008-11-10
[21:53] <juliux> where the bot joined again
[21:53] <juliux> and today the bot was kicked out again
[21:55] <juliux> and i have to add that at the beging of locobot every loco channel was automaticly logge by locobot
[21:56]  * juliux knows that because the locobot was the issue why i get starting working with the ubuntu community;)
[21:57] <LjL> juliux: as in, you worked *for* locobot, or *against* it? :P
[21:57] <juliux> against
[21:57] <juliux> because the bot was not announcing the logigng
[21:57] <juliux> and all the joins and quits where als in the logs
[21:58] <LjL> ah, so it's you i have to "thank" also for ubuntulog now having the joins and parts anymore? >:
[22:01] <juliux> i only did that for locobot
[22:01] <juliux> but i write it in bash;) smurf rewrite it in perl
[22:02] <juliux> i don't like it if a bot publish logs with my joins and quits, because everybody then know when i stand up and when i go to bad
[22:02] <LjL> that can be easily reconstructed by looking at the times you talk at
[22:03] <juliux> not so easy
[22:03] <juliux> i tried it;9
[22:03] <juliux> but now i am using irssi so there is no join and no quit;9
[22:05] <LjL> juliux: well, it's only not easy because the locobots have no timestamps...
[22:06] <juliux> i know;)
[22:06] <juliux> you don't need timestamps or join and quits if you want to read the solution of a support issue
[22:06] <juliux> and for that we have locobot
[22:12] <Myrtti> um.
[22:13] <Myrtti> oh, nvm.
[22:20] <juliux> LjL: now the bot is banned and kicked again;9
[22:45] <TheInfinity> juliux: and now i write a mail to stop it at all :)


[13:54] <robjo> smoser: ping
[13:55] <smoser> hey
[13:55] <smoser> robjo,
[13:56] <robjo> smoser: Any thoughts on the e-mail I sent to the list yesterday? Have done some more digging and it appears to me that
[13:56] <robjo> init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
[13:56] <robjo> i.e. stage # should be guarded such that it does not run during the -local phase
[13:57] <smoser> well, the specific error you point to is fixed i believe
[13:57] <smoser> er... hold on
[13:58] <smoser> https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/305882
[13:58] <smoser> i belive is the one
[14:03] <robjo> smoser: I can try this, but it still appears to be opposing the definition of the intent, cloud-init-local is set to run prior to network-pre, thus there is no guarantee that the device is up
[14:03] <robjo> in this case why do we even try to read the device state? Should we no simply forgoe this whole network stuff in -local?
[14:03] <smoser> ah
[14:04] <smoser> robjo, right.
[14:04] <smoser> sorry, i really, really need to write a description of all of this and what is supposed to happen.
[14:04] <smoser> so local should run before networking comes up
[14:04] <smoser> before the OS would bring up networking
[14:04] <smoser> as it is going to configure it.
[14:04] <smoser> it doesn't bring it up because the OS should on boot
[14:04] <smoser> as it would normally in non-cloud-init boots.
[14:05] <smoser> just as if cloud-init-local had run before boot and wrote the files
[14:05] <smoser> thats the goal
[14:05] <robjo> that at least is my interpretation based on what's in the unit file. thus stage#6 should be guarded and should not execute the network call at all if in local mode
[14:07] <robjo> Oh, I think the light just came on and I see the chicken and egg problem
[14:07] <robjo> in -local we want to write the config for the network interface, but in order to write the config we check if the device is actually online, thus we read the carrier file
[14:08] <robjo> but that is not OK at this point
[14:09] <robjo> so one option may be to write out configurations for every device we find whether the device is connected or not
[14:09] <robjo> then let the network client figure it out from there
[14:10] <robjo> the other option may be to delay the configuration as proposed in my e-mail
[14:11] <robjo> btw, I did test the delayed config approach and that worked for me
[14:32] <smoser> robjo, sorry.
[14:32] <smoser> was distracted reading. sorry.
[14:33] <smoser> why is it not ok to read the carrier ?
[14:33] <smoser> because it's not been set 'up' i guess ?
[14:33] <robjo> as the trace shows it may not be there, so we get EINVAL from the kernel
[14:33] <smoser> sure... so in that case we decide "don't know"
[14:34] <smoser> and assume it available i think
[14:34] <smoser> delaing configuration until existing configuration as found in the system (ie, readying /etc/sysconfig)
[14:34] <robjo> following the way I currently understand the logic that would imply that we will not write the config, so why bother to begin with?
[14:34] <smoser> would mean that that network config might come up
[14:34] <smoser> which might be wrong
[14:34] <smoser> and or detrimental
[14:34] <smoser> ie, if i launch 2 isntances from same captured node
[14:34] <smoser> then they'd both bring up networking as the old ip address
[14:36] <robjo> the wheels are turning, just a moment...
[14:38] <robjo> So, at this point the configuration can only come from a config drive or the config file, as there is no network cannot pull any data from a server, correct?
[14:39] <robjo> That also implies that we can simply write the configuration we get from the source, i.e. the config drive
[14:39] <robjo> there is really no need to check the carrier flag or other status of the device.
[14:39] <smoser> robjo, sort of.
[14:40] <robjo> If we simply write the configuration we promise that the instance will not come up with a duplicate IP
[14:40] <smoser> right.
[14:40] <smoser> (or if it does, not our problem)
[14:40] <smoser> the thing where it kind of matters is "fallback"
[14:40] <smoser> basically, if cloud-init does not find anything at this point
[14:40] <robjo> then once the config is written by -local and the network stack comes up it will sort out the interfaces that are actually in use
[14:40] <smoser> it generates a config that equates to old behavior "dhcp on eth0"
[14:40] <smoser> and writes that.
[14:41] <smoser> but it tries to be a bit smarter, and not dhcp on a device that is not connected
[14:42] <robjo> but the network client will figure that out, so if cloud-init always writes "dhcp" on "eth0" but eth0 is not there then dhcp-client, or in our case wicked will just drop that interface
[14:43] <robjo> now of course we can argue whether it is better to generate the EINVAL error form the kernel or let the network client figure out that the interface isn't really there ;)
[14:43] <robjo> I am not certain there is a good answer to that question
[14:43] <robjo> Other than, if we try to be to clever we create problems ;)
[14:44] <smoser> well, if the thing isn't connected, then its pointless to try to dhcp on it.
[14:45] <smoser> but if we just go on , as i think the branch i pointed at does.... then we end up with "dhcp on eth0" and eth0 not being connected, but not much else we can really do.
[14:45] <smoser> in the future, what we will be doing is like the digital ocean datasource does now.
[14:45] <smoser> the cloud-init local will actually be part of every datasource...
[14:45] <smoser> and the datasources will check to see if they are on their platform.
[14:46] <smoser> if they are, then they'll configure networking manually enough to get to the network metadata service
[14:46] <smoser> and find the real network data
[14:46] <smoser> and then write that.
[14:46] <smoser> and tear down their temporary stuff
[14:46] <smoser> that make sense ? its what makes us able to get networking information from a source that lives on the network
[14:48] <robjo> yes, makes sense
[14:48] <robjo> backporting the patch to 0.7.8 for my package.....
[14:49] <robjo> unless 0.7.9 is right around the corner ;)
[14:58] <smoser> well, lets get that merged.
[14:58] <smoser> does it work for you, robjo ?
[14:58] <robjo> smoser: still backporting I probably need an hour before I can test, have a meeting in a couple of minutes
[15:00] <smoser> robjo, ok. it did seem to fix things for others.
[15:01] <robjo> I'll let you know as soon as possible
[15:09] <hkominos> morning everyone. I would like to ask quick question if you dont mind. I am using a small openstack installation and i am passing cloud-init to configure the VM. I am using the cloud images from ubuntu for now. In those image
[15:11] <hkominos> morning everyone. I would like to ask quick question if you dont mind. I am using a small openstack installation and i am passing cloud-init to configure the VM. I am using the cloud images from ubuntu for now. In those images the default user is Ubuntu. I dont want that created so I make a new one. However the default key which is passed from openstack never reaches the user[0] name created. Is that default behaviour?]
[15:28] <smoser> hkominos, what is "default key" ?
[15:29] <smoser> oh. i see. the ssh key.
[15:29] <hkominos> I mean a key-pair created from the openstack UI
[15:30] <hkominos> http://paste.openstack.org/show/585344/
[15:31] <hkominos> this is the relevant cloud-init snipet
[15:42] <robjo> smoser: works for me with the patch applied
[15:50] <smoser> hkominos, i thin if you just set 'default: true' on one of those entries you'll get what you want
[15:54] <smoser> shoot. no that doesnt seem to work even though it should
[15:56] <hkominos> that is a good idea. +I think that the -default attribute would create a user named ubuntu thought. Not the one that i want to create. (i think)
[15:58] <smoser> well i think it was intended to update the exiting 'default'
[15:58] <smoser> just launching an lxc container, i get the user created
[15:58] <smoser> and no ubunt user
[15:59] <hkominos> you mean withou the -default user.
[15:59] <smoser> http://paste.ubuntu.com/23308735/
[15:59] <smoser> right
[15:59] <smoser> all i get is /home/smoser
[16:01] <hkominos> http://paste.ubuntu.com/23308739/
[16:01] <hkominos> so this would create 2 users.
[16:02] <hkominos> That is the only use of "default" tag that i know of.
[18:03] <prometheanfire> going to have to finish the cloud-init gentoo networkv2 stuff to get v6-only networking working I think
[18:19] <jgrimm> smoser, powersj:  wrt cloud-init integration testing... magicalChicken has some time to help with that, interested?
[18:26] <smoser> sure.
[18:29] <jgrimm> smoser, cool  i really want to get that off the ground, but wasn't sure if either of you'd started into it at all
[18:29] <smoser> no. other than what i'd written there.
[18:31] <jgrimm> smoser, what's ETA for next cloud-init release?
[18:31] <smoser> i hadnt targetted one.
[18:32] <jgrimm> ok, we probably should for the SRU waiting in the wings?
[20:36] <harlowja> prometheanfire are u the main gentoo person?
[20:36] <harlowja> prometheanfire  if so, got any time to look at https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+ref/kill-brpm
[20:36] <harlowja> just preferring to use a single spec file...
[20:37] <harlowja> makes things a little bit simpler...
[20:38] <harlowja> though i  can say i didn't merge in the packages/suse/cloud-init.spec.in stuff; so there might be a tiny bit of work
[20:45] <prometheanfire> harlowja: I suppose so
[20:46] <prometheanfire> harlowja: do you have a diff?
[20:46] <harlowja> ya, let me get one
[20:46] <prometheanfire> the files modified doesn't look like I'd care
[20:46] <prometheanfire> I treat it like a python package
[20:47] <prometheanfire> a somewhat special one (due to having to run a script iirc)
[20:47] <prometheanfire> https://github.com/gentoo/gentoo/blob/master/app-emulation/cloud-init/cloud-init-0.7.8-r1.ebuild#L66-L86
[20:48] <prometheanfire> that's how I install
[20:48] <prometheanfire> someone should look at https://code.launchpad.net/~prometheanfire/cloud-init/+git/cloud-init/+merge/307969 too :P
[21:08] <harlowja> prometheanfire so the part that might bother u is that i dropped the suse spec file, lol
[21:08] <prometheanfire> harlowja: I'm not suse :P
[21:08] <harlowja> oh
[21:08] <harlowja> nm then
[21:08] <harlowja> lol
[21:09] <prometheanfire> hwoarang might
[21:09] <harlowja> kk