[00:21] <PCLine__> Good evening everyone.
[00:31] <dzho> hiya PCLine__
[00:32] <PCLine__> hi dzho - how you doing tonight?
[00:41] <dzho> getting along ok, thanks. You?
[00:46] <PCLine__> I am great right now - Thinking I might make a Strawberry MilkShake for a snack.


[07:19] <ax> so i went through the tutorial about evolution contacts with ubuntu-one, but.. i don't actually see how they are connected to ubuntu-one
[07:20] <ax> it uses this 'couch-db' thing, and in the preferences i see a few settings that can be changed, desktop, system wide or remote.. but the tutorial doesn't say anything about it
[10:30] <huntz0r> Morning all, was wondering if someone could help me out.  My desktop couch database doesn't seem to be replicating between machines.  On my lucid vm I get an INFO message saying that there is "No o.u.c key. Maybe there's uo.c key?" And then straight after that an ERROR saying "Couldn't talk to 'https://one.ubuntu.com/api/account'. Got HTTP 400".  Any ideas?
[10:31] <huntz0r> (info grabed from .cache/desktop-couch/log/desktop-couch-replication.log)
[10:33] <rye> notes web ui is broken again :-/
[10:33] <rye> for those who have links in their notes
[10:33] <rye> filing-a-bug :-/
[11:02] <rye> no, it seems to be rye-specific, file-o-bug canceled for now, need more investigation
[18:21] <ax> so i just installed the ubunt update and now ubuntu-one isn't in my web folder of my applications menu
[23:02] <duanedesign> what is the default upload/download rate?


[04:16] <Puscher> hi all
[04:17] <Puscher> just wondering if anyone here knew the current status of edubuntu
[04:17] <Puscher> is it being maintained?
[06:10] <pleia2> Puscher: they did not have a 16.04 release, 14.04 is still supported, see https://lists.ubuntu.com/archives/ubuntu-devel/2016-March/039281.html
[11:08] <NikkyNick> Hi guys.
[11:08] <Na3iL> Hello NikkyNick
[11:08] <NikkyNick> I need your help.
[11:11] <NikkyNick> Tell me please, who know. What kind of Ubuntu support Realtek Wireless Driver rtl8723be?


[18:41] <anis> hey
[18:45] <anis> any way to activate tsx in haswell cpu without flashing the bios?
 Is there anyone who can tell me how to get the use of my keyboard’s right-hand keypad in 20.04?


[00:45] <_John-Doe_> hello ubuntu community!
[00:46] <SpamapS> hello JOHN
[04:26] <stgraber> jjohansen: default
[04:45] <jjohansen> stgraber: okay thanks
[06:16] <axisys> is there a puppet recipe anyone know of that sets up pxe boot server ?
[11:04] <spm_Draget> Greetings. I am running u-server 10.4 LTS (lucid) on my own machine, and have access to a second machine running the same version. On this machine there is a packate installed 'mapserver-6.0.1' while on my serve rthe repos only show mapserver-5.6 avialable. I thought it was a backport - but how do I find this ou?
[11:04] <spm_Draget> I looked into /etc/apt/sources.list and the backport repos seem to be commented out on the other machine.
[11:05] <spm_Draget> Is there a way to find out why the other machine has mapserver-6.0.1 available and mine not?
[11:05] <spm_Draget> (Oh sorry, it is called 'cgi-mapserver')
[11:05] <shauno> spm_Draget: 'apt-cache policy cgi-mapserver' may render some clues
[11:06] <shauno> (I'm not sure if it needs to be still available via apt sources to show up, however)
[11:08] <spm_Draget> 500 http://ppa.launchpad.net/ubuntugis/ppa/ubuntu/ lucid/main Packages - is this the open communty repository? Hmm, I'll check sources.list agian, maybe I overlooked something
[11:10] <spm_Draget> Nope, sources.list are identical. Must admit that I am not too familar with any other means of installing 'additional' packges by anything else but adding something to my sources
[11:11] <shauno> any differences in /etc/apt/sources.list.d/ ?
[11:13] <shauno> I believe add-apt-repository will create individual *.list files under there, rather than editing your actual sources.list
[11:19] <spm_Draget> Thats it! Thank you. I will copy these over
[12:18] <ghatak> Hi, i am having little trouble with mdadm, i created an md device md0 at level 1 (mirror) by adding only one partition. That works fine, however when I reboot the system, it complains that array is degraded, and renames md0 to md127 and asks start array degraded (y/n). I am ok with starting array degraded, but why does it rename the array to md127?
[12:26] <dns53> no idea, but you should be using the uuid of the device and not the device name as the device can potentially move
[15:53] <thafreak> is there still a separate virt channel?
[16:29] <jparker> hey guys I need help, I need to figure out how to install a newer version of mysql on ubuntu 10.4 that isnt in the repository
[16:30] <Patrickdk> just install it :)
[16:30] <jparker> basically ubuntu 10.0.4 uses mysql 5.1.41 and I need to install mysql 5.1.61
[16:30] <jparker> yeah but unfortianltly I dont really know where to start
[16:30] <jparker> :(
[16:30] <qman__> in order of preference, backports, PPA, manual deb, compile from source
[16:31] <jparker> backports  would have newer versions?
[16:31] <qman__> that's what backports are
[16:31] <Patrickdk> if someone requested one, and someone built it
[16:31] <qman__> porting newer versions of software back into old releases
[16:32] <jparker> but this is to go to the newest verion
[16:32] <Patrickdk> personally I use my own rebuils of: http://www.percona.com/downloads/Percona-Server-5.1/
[16:32] <jparker> not going back to a older one
[16:32] <qman__> new software, old release
[16:33] <qman__> 10.04 is nearly two years old, and its supported/included software versions are also two years old
[16:33] <Patrickdk> you also loose security updates, when going with backports
[16:33] <jparker> gotcha
[16:34] <jparker> so its as simple as adding deb http://archive.ubuntu.com/ubuntu lucid-backports main restricted universe multiverse to my /etc/apt/sources.list ?
[16:34] <qman__> if that version of mysql was backported, yes
[16:34] <qman__> I don't know if it was or not, you'll have to search
[16:40] <jparker> doesnt look like I can find any mysql in backports
[17:21] <jparker> wow looking into this it seems pretty hard to do this
[17:22] <jparker> we are just trying to import a database, but there is a bug in mysql 5.1.41 which is the version in lucid
[17:23] <jparker> and apparently mysql 5.1.47 has the fix
[17:23] <jparker> but trying to find a way to upgrade it on our server proves to be hard :/
[17:31] <jparker> if anyone can help me figure this out that would be so great, I did look at back ports but couldnt find any thing new
[17:31] <stgraber> jjohansen: did you manage to reproduce the issue?
[17:58] <jparker> solved my problem by finding this! https://launchpad.net/~ubuntu-security-proposed/+archive/ppa
[17:59] <jparker> thanks for your guys help
[19:27] <delinquentme> hey all so I'm attempting to describe some server-related task that I'm after and I'm wondering if im using the correct terminology ... therefore does anyone happen to have a link to the general processes servers carryout?
[19:28] <delinquentme> im describing what im after as binary protocols ... and I think it would be perfectly equipped to handle it .. im not 100% sure though
[19:30] <qman__> not a clue what you're talking about, which probably means you have the wrong terminology
[19:31] <delinquentme> so maybe API calls
[19:32] <delinquentme> basically I've got a primary server ( rails deriv ) and then polling servers which drive microcontrollers ( hardware )
[19:32] <delinquentme> primary server will init calls to the polling servers and thus init stuff on the robotics
[19:32] <delinquentme> API calls would be correct no?
[19:33] <qman__> if you designed your protocol that way, sure
[19:33] <qman__> an API only exists inside the terms of the application though
[19:33] <qman__> e.g. GTK API, kernel API, ...
[23:01] <jjohansen> stgraber: I haven't got a chance yet but I did find an uninitialized value in one bind path, if you get a chance you might want to try this kernel people.canonical.com/~jj/linux-image-3.2.0-18-generic_3.2.0-18.29_amd64.deb


[00:08] <bdrung> kees, SpamapS, slangasek: Please fix the debian revision of upstart with the next upload (bug #693630)
[00:11] <kees> bdrung: ah, yeah, will do.
[02:12] <ohsix> anyone know offhand the apt-fu or aptitude meta query for listing packages installed manually
[04:53] <pitti> Good morning
[04:53] <cyphermox> pitti,  good evening ;)
[04:53] <pitti> mtaylor: not right now, but please feel free to open a bug an subscribe me, and we discuss it there; sounds interesting
[04:53] <pitti> cyphermox: I can't sleep any more :)
[04:54] <cyphermox> pitti, I haven't gone to sleep yet ;)
[04:54] <cyphermox> it
[04:54] <cyphermox> it's still wednesday here :)
[04:54] <broder> pitti (and kklimonda): re our python-gtk discussion from a bit ago, andersk pointed out to me earlier today that you can do "import sys; reload(sys); sys.setdefaultencoding('undefined')"  :)
[04:55] <pitti> broder: hah, nice hack
[04:55] <mtaylor> pitti: cool. I'm trying to find a _sensible_ way to integrate i18n into openstack stuff
[07:03] <pitti> kees: please don't ask for testing -proposed packages; if you upload to -proposed, they need to be reviewed/accepted by ~ubuntu-sru first
[07:04] <pitti> and our sru-accept.py script will then do the call for testing
[07:15] <kees> pitti: oh! eek, sorry about that
[07:15] <pitti> kees: no problem, I'm processing the queues now
[07:15] <pitti> so it's not too much time in between
[07:15] <pitti> but lucid-proposed had been locked for a while for 10.04.2 prep
[07:15] <kees> pitti: yeah, sorry, I went from doing security-proposed -> -proposed bugs to normal -proposed bugs and got carried away.
[07:16] <kees> right.
[07:16] <pitti> kees: no problem; just mentioning it for next time
[07:16] <pitti> thanks for the sponsoring!
[07:16] <kees> you bet! thanks for looking through the queues.
[07:16]  * kees heads to bed
[07:16] <pitti> sleep well!
[07:38] <didrocks> good morning
[08:03] <didrocks> @pilot in
[08:04] <dholbach> good morning
[08:06] <didrocks> hey dholbach
[08:13] <pitti> james_w: since I merged the blueprints API patch, the linaro WIs have skyrocketed (they apparently were miscounted before), and I now get a lot of cron spam for "[WARNING] milestone "4.4-2010.07-0" is unknown/invalid"
[08:14] <pitti> james_w: do you actually need the linaro configuration on people.c.c. these days? you guys have your own instance now, don't you?
[08:15] <dholbach> lu didrocks
[08:15]  * dholbach hugs didrocks
[08:16]  * didrocks hugs dholbach
[08:18] <hyperair> is there a cross platform way of printing out '\n' in sh?
[08:18] <hyperair> in dash, echo -n '\n' dumps a newline to screen
[08:18] <hyperair> in other shells, you need -e for it to dump a newline
[08:18] <hyperair> so dash requires '\\n' to print out a literal \n, but in other shells, that comes out as \\n
[08:18]  * hyperair facepalms
[08:19] <hyperair> like for example, busybox's ash
[08:21] <RAOF> hyperair: /usr/bin/printf
[08:21] <hyperair> RAOF: hmm interesting.
[08:22] <hyperair> RAOF: thanks for the idea!
[08:22]  * hyperair goes about patching haserl
[08:39] <nigelb> persia: hi, around/
[08:39] <nigelb> persia: would you be interested in giving a session at UDW about talking to upstreams and debian in particular?
[09:37] <didrocks> mvo: in case you didn't notice, you have two waiting grammar typo fix in apt: https://code.launchpad.net/~evfool/apt/fix641673/+merge/48689 and https://code.launchpad.net/~evfool/apt/fix418552/+merge/48695
[09:38] <mvo> thanks didrocks
[09:38] <mvo> I noticed, but forgot already
[09:38]  * mvo points to https://launchpad.net/~blatant-and-awkward
[09:39] <didrocks> mvo: heh :)
[09:39] <nigelb> mvo: lol, nice team ;)
[09:40] <nigelb> cdbs: ping
[09:40] <nigelb> cdbs: Want to talk about somethign packaging-ish at Ubuntu Developer Week? :)
[09:46] <csurbhi1> mvo, ping
[09:50] <mvo> hey csurbhi1
[09:51] <csurbhi1> hey mvo!
[09:51] <csurbhi1> i wanted to verify something
[09:51] <csurbhi1> bug 693630
[09:52] <csurbhi1> i have marked that invalid.. because upstart is not based on any debian package..
[09:52] <csurbhi1> but wanted to make sure that sounds right
[09:52] <cdbs> nigelb: back
[09:53] <cdbs> nigelb: no, my exams are starting from March 2nd
[09:53] <cdbs> so I will be really busy
[09:53] <cdbs> and can't pull an hour out of my routine
[09:53] <mvo> csurbhi1: well, yes and no :) its correct, but debian is using a -X schema as well. so there is the risk of having two identical versions (includiing debian revisions) but with different content
[09:53] <nigelb> cdbs: yeah, sorry.  daniel told me later that he already asked you.
[09:53] <mvo> csurbhi1: so there is some value in still doing the -0ubuntu1 dance (or asking debian to do -1debian1)
[09:54] <csurbhi1> ok
[09:54] <csurbhi1> but would we ever take the debian package ?
[09:54] <mvo> csurbhi1: given that for us the change is minimal and it avoids confusion I would be inclined to just use -0ubuntu1
[09:54] <csurbhi1> to cause the confusion?
[09:54] <csurbhi1> i mean would not Ubuntu's upstart be upstream for Debian now?
[09:55] <csurbhi1> so that we dont take full patches from debian
[09:55] <csurbhi1> no?
[09:56] <csurbhi1> like the problem of collision will occur only in case of a merge sync?
[09:56] <mvo> that is true, we will most likely not take debian package but do our own, still it feels wrong to have two versions with the same number (including distro revision) that hae different content. IMO either we or debian should adjust the version
[09:56] <csurbhi1> merge request?
[09:56] <csurbhi1> mvo, ack
[09:56] <mvo> anytime people compare version numbers
[09:56] <csurbhi1> thanks!
[09:57] <csurbhi1> ok, i will update the bug once again then :) and update it with your comments
[09:57] <mvo> yw, I think while technically its correct that we have -X for practical reasons we should adept
[09:57] <mvo> (or ask debian nicely to do that)
[09:58] <csurbhi1> one query
[09:58] <csurbhi1> i still have
[09:58] <csurbhi1> when we take debian's vanilla package
[09:58] <csurbhi1> and have no patch to add on top of it
[09:59] <csurbhi1> we do not have the -0ubuntuX scheme
[09:59] <csurbhi1> right?
[09:59] <mvo> csurbhi1: yeah, if we just sync it, we keep the version number from debian
[09:59] <csurbhi1> i mean if its not a merge request?
[09:59] <csurbhi1> ok
[09:59] <mvo> (as the source is the same)
[09:59] <csurbhi1> would debian be doing that with Ubuntu's upstart?
[10:00] <csurbhi1> owing to which the version numbers are the same?
[10:01] <mvo> csurbhi1: I think it would be a good idea if debian merges from ubuntu to have -1debian1 for example
[10:01] <mvo> csurbhi1: but I don#t think there is a policy for this yet
[10:01] <mvo> (in debina)
[10:02] <csurbhi1> just being a devils advocate here... but in the case the source is the same, Ubuntu can then have the same version number right :)
[10:02] <csurbhi1> but i get the gist of it..
[10:02] <csurbhi1> i will update the bug.. thanks for the enlightenment
[10:14] <janimo> what is the differnece between ubuntu.natty and platform.natty seeds?
[10:15]  * janimo wishes LP branches made use of the optional description field
[10:19] <mvo> csurbhi1: your welcome :) (sorry for the delay, was on the phone)
[10:19] <csurbhi1> mvo, np
[10:19] <cdbs> mvo: hi, do you intend to restrict the ability to review an app in s-c only for those who have installed it?
[10:20] <cdbs> (similar to the way iOS App Store and Android Market do)
[10:20] <mvo> cdbs: hello! iirc that is what the spec says, so yeah :)
[10:52] <bankix> Hi.
[10:56] <didrocks> session restart, brb
[10:59] <chrisccoulson> who's going to take care of gjs in the archive?
[11:00] <chrisccoulson> libmozjs is currently breaks ABI with every single point release....
[11:00] <chrisccoulson> s/breaks/breaking/
[11:00] <chrisccoulson> we dropped it for a reason
[11:05] <didrocks> chrisccoulson: bigon will
[11:06] <didrocks> chrisccoulson: I checked with him at fosdem and as he maintains it in debian and ubuntu, he'll follow the ABI breakage
[11:06] <didrocks> chrisccoulson: btw, the reason on the drop was just "unused by default", the ABI breakage should have been mentionned
[11:06] <chrisccoulson> right
[11:06] <chrisccoulson> but it's still unused isn't it?
[11:07] <didrocks> chrisccoulson: yeah, but people developping on ubuntu like the telepathy guys needs it for their dev
[11:07] <didrocks> I think it's not an isolated case
[11:39] <cjwatson> janimo: platform.natty => seeds common to all products; ubuntu.natty => seeds for Ubuntu desktop and server editions
[11:46] <janimo> cjwatson, thanks.
[11:46] <dholbach> who of you has started working on a small project that you want to introduce and get people interested in? we are going to have a "project lightning talks" in the last session of UDW: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions - feel free to sign up
[12:00] <blackmoon105> is possible to report a bug for "ubuntu-wine" ppa package? i can only report a bug for official wine version...
[12:00] <nigelb> PPA bugs aren't yet available
[12:00] <nigelb> you'll have to contact the author
[12:00] <blackmoon105> nigelb: ok, thank you!
[12:01] <nigelb> blackmoon105: :)
[12:13] <dholbach> fabbione, happy birthday! :)
[12:13] <fabbione> dholbach: thanks man :)
[12:26] <blackmoon105> hi, how can i be a official mantainer (not ppa) of a ubuntu package? so i can keep it update with the latest version..
[12:27] <dholbach> blackmoon105, get a new versioned sponsored into Ubuntu (https://wiki.ubuntu.com/SponsorshipProcess), after you've worked with a few sponsors, apply for upload rights (https://wiki.ubuntu.com/UbuntuDevelopers)
[12:32] <blackmoon105> dholbach: thanks, i read it
[12:46] <didrocks> @pilot out
[12:50] <dholbach> didrocks, great work!
[12:51] <didrocks> dholbach: thanks, hope that help the queue a little :)
[12:51] <dholbach> good job! :)
[13:22] <Daviey> JamesPage, Is mvel on your radar for a merge?  It's really out of date... we haven't merged since at least karmic by the looks of it; and it's a major version increase.
[13:23] <Daviey> JamesPage, I don't mind having a stab of it.
[13:24] <jfer> hi, i was wondering if there were plans to add MariaDB to the ubuntu repository?
[13:24] <Daviey> JamesPage,  hmm.. seems it was never sync'd - it was a ubuntu native package which is now in Debian
[13:26] <cdbs> mvo: ping
[13:27] <mvo> pong cdbs
[13:27] <Daviey> jfer, The logical step is for it to enter Debian and be sync'd across.. Inclusion in Debian is being tracked @ http://bugs.debian.org/565308
[13:27] <cdbs> mvo: hi, https://code.launchpad.net/~bilalakhtar/software-center/write-review-installed-only/+merge/49206 read the two comments, what do you say about this? should a bug be filed? on what? ayatana-design?
[13:27] <mvo> cdbs: I have a look now, many thanks
[13:28] <jfer> ok thanks Daviey
[13:29] <jfer> so it won't make it into natty then?
[13:29] <Daviey> jfer, hmm.. looking at the progress of that i would say it's possible but unlikely.
[13:32] <jfer> ok it seems that the conflict with MySQL is the main reason for the delay
[13:40] <JamesPage> Daviey: OK so we currently have two mvel packages - one in main (mvel) and one in universe (mvel2)
[13:41] <JamesPage> Daviey: mvel2 build-deps on Maven (not in main); we could potentially converge the packages but not without major MIR work for Maven-> main
[13:41] <james_w> pitti, yeah, let's delete the linaro config from your instance. We do indeed have our own instance.
[13:41] <Daviey> JamesPage, *sigh* :)
[13:41] <james_w> pitti, let me know if that isn't enough and I'll propose a patch to handle whatever is left.
[13:42] <pitti> james_w: thanks; I commented out the linaro teams from natty.cfg now
[13:42] <Daviey> JamesPage, Sounds like something to revist next cycle
[13:42] <JamesPage> Daviey: whats the requirement for it at this point in time?  I'm starting to see a number of packages in Debian switch from Ant to Maven which are already in main so its going to get worse....
[13:42] <pitti> james_w: there are still the separate linaro reports, of course (http://people.canonical.com/~platform/workitems/linaro-multimedia-wg/all.html etc.)
[13:43] <james_w> pitti, thanks
[13:43] <Daviey> JamesPage, i just noticed there versions were significantly different... it doesn't gain us anything i don't think having a newer thing... we need to maintain the version in Lucid regardless, so lets pin
[13:44] <JamesPage> Daviey: OK - I'm going to spec Maven -> Main for UDS-O so next cycle then (well maybe :-)
[13:45] <Daviey> JamesPage, I don't think users have complained that it's an old version, and with the major new version in universe already.. seems we are currently in a  good position
[13:45] <Daviey> JamesPage, You've been looking for more excuses to get Maven promoted to main, haven't you? :)
[13:45] <JamesPage> Daviey: TBH it just means that we are having to maintain a larger Ubuntu delta over debian than we should be for some areas of the Java library
[13:46] <JamesPage> Daviey: and yes I have :-)
[13:47] <Daviey> heh
[13:49] <mvo> thanks cdbs, branch looks fine
[13:51] <cdbs> mvo: Did you read the comment by Aaron?
[13:51] <cdbs> That ain't a bad idea
[13:53] <mvo> cdbs: true
[13:58] <cdbs> mvo: okay, if you find fit you may merge this branch for now, in the meantime, I will file a bug and look for mpt feedback
[13:59] <cdbs> bug about asking the user to review before uninstalling
[14:01] <mvo> cdbs: it appears the spec has it, its just a bit hidden
[14:01] <cdbs> mvo: it does?
[14:02] <mvo> """"This process begins when you activate the “Review…” button on an “Installed Software” item screen."""
[14:02] <mvo> https://wiki.ubuntu.com/SoftwareCenter/RatingsAndReviews
[14:03] <cdbs> mvo: I know that. I mean that the thing that the user should be prompted to review an app when uninstalling it, isn't in the spec
[14:03] <mvo> cdbs: aha, indeed
[14:03] <cdbs> mvo: just filed bug #716435
[14:04] <cdbs> mvo: so, that branch may be fit to go in now, I will work on this bug when the design spec is having that
[14:04] <cdbs> mvo: okay, I g2g now, bye!
[14:04]  * cdbs /aways
[14:47] <janimo> pitti, would jockey be a suitable component to handle some aspects of bootloader file updates on ARM? These are blobs which are packaged in Ubuntu, but need to be installed elsewhere not on /, such as copied to a vfat partition
[14:48] <janimo> pitti, there is a spec that deals with allowing users to update their bootlaoders easily and safely at least on the supported ARM images which keep their bootloaders on SD card's first partition
[14:49] <joaopinto> hello
[14:50] <Laney> there's a bot to do that ;-)
[14:51] <kenvandine> whoops
[14:51] <joaopinto> is it known that Natty's grub sets an unusable text mode with certain gfx cards/displays ?
[14:51] <kenvandine> @pilot in
[14:52] <soren> Is there a trick to get rid of the invisible window in the upper left corner that prevents me from clicking on things in unity? I thought that had been fixed, but I'm seeing it now.
[14:53] <cjwatson> joaopinto: https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032244.html
[14:53] <cjwatson> joaopinto: https://wiki.ubuntu.com/FoundationsTeam/Grub2BootFramebuffer/Whiteboard
[14:55] <soren> Uh... Weird. Turned out it was a crashed gvim. xkill took care of it.
[14:55] <joaopinto> cjwatson, the mail is not very clear in what related to the menu, it mentions transition, my issue is with the menu presentation, not with the transition itself
[14:56] <seb128> soren, usual workaround is to restart compiz or smspillaz said to hide and show the desktop can workaround it as well
[14:56] <cjwatson> joaopinto: the whiteboard has one entry on it which may be your problem
[14:56] <cjwatson> "Corrupted video in GRUB"
[14:56] <seb128> soren, i.e ctrl-alt-d twice
[14:56] <joaopinto> ok, checking
[14:57] <joaopinto> oh, ThinkPad, it's me :P
[14:57] <soren> seb128: Ah, cool.
[14:57] <soren> seb128: Thanks.
[14:58] <seb128> soren, yw, btw smspillaz is working on that bug and said it will probably be fixed by end of the day
[14:58] <seb128> let's see
[14:58] <soren> \o/
[15:00] <artfwo> seb128, don't you have a link to the bug by chance?
[15:01] <seb128> bug #709461
[15:02] <artfwo> thanks!
[15:06] <micahg> kenvandine: can you look at bug 713492, I believe there might be a symbols issue, so I wasn't comfortable sponsoring
[15:07] <kenvandine> micahg, sure
[15:08] <micahg> kenvandine: thanks
[15:13] <blackmoon-105> i've run "  apt-cache show freepops | grep ^Source: | sort -u | cut -d: -f2- " but it don' result nothing..
[15:14] <persia> blackmoon-105, That happens when the source name is the same as the binary name.
[15:14] <persia> You might find `apt-cache showsrc ...` useful
[15:14] <blackmoon-105> persia: thanks
[15:16] <blackmoon-105> persia: blank output also with 'showsrc'
[15:17] <persia> If you put it through the same pipes, that's expected.
[15:22] <blackmoon-105> persia: ok, i've found that i don't have the "Source:" entry.. and so greo don't find it..
[15:22] <blackmoon-105> *greo --> grep
[15:23] <persia> Right.  showsrc shows the source for Package, and lists binaries.  show shows the binary for Package, and sometimes lists source.
[15:27] <Riddell> cjwatson: I split kubuntu-mobile into a separate seed collection, can you remind me the right way to make changes to ubuntu-cdimage and its bzr archive?
[15:31] <cjwatson> Riddell: bzr co bzr+ssh://antimony/srv/cdimage.ubuntu.com/bzr/cdimage/  on your laptop, make changes there, commit - then let me know
[15:31] <blackmoon-105> persia: ok, thank you
[15:32] <cjwatson> blackmoon-105: you might also like to install dctrl-tools and learn to use grep-dctrl, if you're going to be doing lots of this
[15:33] <blackmoon-105> cjwatson: done, i do it
[15:33] <cjwatson> blackmoon-105: e.g.:  apt-cache showsrc freepops | grep-dctrl -nsSource:Package ''
[15:33] <cjwatson> (maybe sort -u in there too)
[15:34] <blackmoon-105> cjwatson: good, i've got the desired output
[15:48] <blackmoon-105> bzr log -l 1 lp:ubuntu/maverick/sysvinit | grep ^tags: | cut -d: -f2-  give me an "Permission denied (publickey)" eror, it's because i'm not the owner of repo?
[15:54] <nigelb> kirkland: ping?
[15:56] <kirkland> nigelb: pong
[15:56] <nigelb> kirkland: hey, want to talk about one of your projects at projects lightning talk for UDW?
[15:57] <nigelb> kirkland: We're trying to give 5 minutes per project to say what it does, how it can be used, and how you could use help :)
[15:58] <nigelb> kirkland: (I personally was thinking of bikeshed hearing about bikeshed and the kind of cool stuff it has)
[15:59] <kirkland> nigelb: sure
[15:59] <cjwatson> blackmoon-105: no, you should be able to 'bzr log' any public branch
[15:59] <kirkland> nigelb: i can talk about any of them
[15:59] <nigelb> kirkland: great! I'll put you down for a session :)
[15:59] <kirkland> nigelb: it's just 5 minutes, right?
[15:59] <cjwatson> blackmoon-105: follow the "one-time setup tasks" listed in https://help.launchpad.net/Code/QuickStart#Push%20a%20Bazaar%20branch%20to%20your%20project
[15:59] <nigelb> kirkland: yup 5 minutes
[15:59] <kirkland> nigelb: sure, you bet
[15:59] <cjwatson> (that goes on to talk about running 'bzr push' - I know you don't need to do that)
[15:59] <blackmoon-105> cjwatson: ok, now i check
[15:59] <kirkland> nigelb: i can introduce a handful of the most useful ones
[15:59] <nigelb> kirkland: awesome, that's great :)
[16:00] <kirkland> nigelb: what's the date?
[16:00] <kirkland> nigelb: and time?
[16:01] <nigelb> kirkland: friday 4th march at 20:00
[16:01] <kirkland> nigelb: hmm, okay
[16:01] <kirkland> nigelb: that might be tough
[16:02] <kirkland> nigelb: is that UTC?
[16:02] <nigelb> kirkland: yup UTC
[16:02] <kirkland> nigelb: okay, worst worst worst case, can I type up a script of what I would say, email it to you, and you paste it on my behalf, in case I can't make it?
[16:03] <nigelb> kirkland: worst case, yes, I can do that for you :)
[16:03] <kirkland> nigelb: thanks
[16:03] <nigelb> kirkland: thank you for joining the party :D
[16:03] <kirkland> nigelb: i'm going to be traveling that day, which is my only concern
[16:03] <kirkland> nigelb: but i'm happy to help :-)
[16:04] <nigelb> kirkland: :-)
[16:18] <kklimonda> hmm.. how to check what is sending out a lot of data?
[16:18] <kklimonda> who, u1
[16:20] <joaopinto> cjwatson, about the "Corrupted videon in GRUB" on thinkpads, is there some something I can do to to help, or you have enough triage already ?
[16:26] <ev> is there not an ICS or google calendar URL for the release schedule anymore?
[16:33] <micahg> kenvandine: so the warning of the lack of a symbols file wasn't relevant to the ccscript update?
[16:36] <kenvandine> micahg, i don't think so, but i am suggesting they add a symbols file in the future, currently no worse than before
[16:37] <micahg> kenvandine: ah, ok
[17:14] <Riddell> cjwatson: cdimage committed
[17:31] <barry> jam: very interesting.  y'know the udd page on working with a patch system?  well, i am hacking on numpy and i did not need the final quilt push/quilt pop this time.  in fact, it caused some recoverable problems.
[17:31] <jam> barry: so if you had *not* done the push/pop you would have been ok?
[17:31] <barry> jam: in this case, yes
[17:32] <barry> it was *definitely* needed the last time i hacked on a quilt3 package thoug, so really i have nfc ;)
[17:32] <jam> so *my* understanding of V3 quilt, is that the changes are supposed to be in the working tree (pushed?)
[17:32] <barry> jam: i think that's the effect of what i'm left with.  i'm about to push the branch so you can take a look
[17:32] <cjwatson> push/pop should just try to apply the patch and then back it out again.  it would catch corrupt-patch kinds of problems.
[17:32] <jam> versus pre v3 packaging, where the patches were supposed to only be in debian and not in the wt
[17:33] <jam> barry: were was the actual failure? in the upload?
[17:33] <cjwatson> one of the fundamental ideas of 3.0 (quilt) packaging is that when you do dpkg-source -x you should get the patches applied, rather than relying on debian/rules to do it for you
[17:33] <cjwatson> what you think the working tree representation should be depends on whether you think the wt should be basically equivalent to dpkg-source -x
[17:34] <cjwatson> my take is that it should be but apparently this isn't universal
[17:34] <barry> cjwatson, jam: when i do the quilt push, i get patch hunk failures.  presumably because it is trying to re-apply the patch to an already patched source tree.  which makes sense, but doesn't explain why i had to do it before
[17:35] <cjwatson> barry: so the patch really ought to be pushed but quilt just doesn't know it?  in that case, http://people.canonical.com/~cjwatson/dpkg-quilt-setup
[17:35] <cjwatson> barry: and see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204
[17:35] <jam> cjwatson: well, as I don't know anything about dpkg-source -x ... :)
[17:35] <cjwatson> jam: the one and only canonical way to unpack a Debian-format source package
[17:36] <jam> cjwatson: except all of the other things above it that may do something differently? as I've never run that command, but have run "apt-get source" many times
[17:36] <cjwatson> jam: apt-get source calls dpkg-source -x .
[17:36] <cjwatson> I don't know of any software in the archive that doesn't use dpkg-source -x to unpack source packages
[17:36] <cjwatson> and all that apt-get source does in addition is to deal with acquiring the source package
[17:37] <cjwatson> it doesn't do any extra tree mangling
[17:37] <jam> cjwatson: good to know
[17:37] <cjwatson> I suspect barry's problem is an instance of the general problem of .pc getting out of sync with the base of the patch stack; which is something udd could (theoretically ...) help with
[17:37] <barry> cjwatson: what i think is happening is this: the source includes the fix because that's where i hacked.  then the 'quilt import' does the right thing, and all you need is to bzr add the new debian/patches file and commit.
[17:37] <jam> barry: the other question, how do you *tell* quilt that the patch is already implied?
[17:37] <jam> is there something you should be running other than "import"?
[17:37] <cjwatson> jam: see above, dpkg-quilt-setup
[17:38] <cjwatson> but that's not official or anything
[17:38] <cjwatson> let me finish my disquisition on .pc and then it may be clear :-)
[17:38] <cjwatson> the files under .pc/PATCH, for each PATCH in the series, are copies of the clean state of each file that's part of PATCH before PATCH was applied
[17:38] <jam> cjwatson: so your script backs out all current patches, and then patches back from the beginning
[17:38] <jam> I'm pretty sure barry just wants to add one at the end
[17:38] <jam> with the current diff content
[17:39] <cjwatson> let me finish
[17:39] <cjwatson> please
[17:39] <cjwatson> it will be easier :)
[17:39] <jam> k
[17:39] <cjwatson> when you do something like an upstream merge, that conceptually changes the base state under the patches in your queue
[17:39] <barry> cjwatson: that's plausible.  if the package importer somehow messed up the .pc directory (which is under vcs), then it's possible the previous package i sworked on required that becuase it was out of sync, but numpy does not because it is in sync
[17:39] <cjwatson> I'm mangling terms a bit but hopefully YKWIM
[17:40] <cjwatson> .pc has to be kept in sync with the unpatched states of files or else quilt will get confused and all sorts of things will go disastrously wrong
[17:41] <cjwatson> dpkg-quilt-setup is a brute-force "assuming that all the patches are valid, get everything back in sync with a big hammer"
[17:41] <jam> cjwatson: there are 2 things at play, I think your problem is indeed a real one, but not what barry is hitting.
[17:41] <cjwatson> however it's mostly useful when you're checking out a tree that doesn't have .pc in it (because checking in .pc tends to produce large numbers of confusing diffs when you commit)
[17:41] <jam> barry's is "I just did some hacking, add the new changes to the quilt"
[17:42] <cjwatson> jam: if he's getting a 'quilt push' failure, it must mean that his series and the quilt state under .pc are out of sync
[17:42] <cjwatson> there's no other way for that to happen
[17:42] <jam> cjwatson: he just did an import, would that put it out of state?
[17:42] <jam> or is quilt supposed to see that the patch is already applied
[17:42] <jam> and just ignore the push?
[17:42] <cjwatson>        import [-p num] [-R] [-P patch] [-f] [-d {o|a|n}] patchfile ...
[17:42] <cjwatson>            Import external patches.  The patches will be inserted following the current top patch, and must be pushed after import to apply them.
[17:43] <jam> right, they are *already* applied
[17:43] <jam> he just used "bzr diff -rlast_state | quilt import"
[17:43] <cjwatson> oh yeesh
[17:43] <jam> he could then do "bzr revert -r last_start; quilt push"
[17:43] <cjwatson> redesign time :)
[17:43] <barry> jam: exactly right
[17:43] <cjwatson> I wouldn't do it that way
[17:44] <cjwatson> I'm trying to think of how I would do it
[17:44] <barry> cjwatson: here are the current instructions: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem
[17:44] <cjwatson> actually, frankly, I just do it all in quilt to start with and it is much easier, but I'm assuming that you have sort of ideological reasons not to do that
[17:45] <barry> cjwatson: hacking the source until you're happy and then diffing to an import is so tempting, convenient, and natural
[17:45] <cjwatson> you could hack the source inside a 'quilt shell'
[17:45]  * persia notes that the expected final state of the source package differs between Format: 1.0 packages using quilt, and Format: 3.0 (quilt) packages, which may affect the UDD documentation.
[17:46] <cjwatson> a cleaner approach might be to revert *first* and then import
[17:46] <cjwatson> then you will get a clean push
[17:46] <cjwatson> since import is intended for importing an external patch that isn't applied to your tree yet
[17:46] <cjwatson> if you follow that then you'll get minimal impedance mismatch
[17:47] <cjwatson> (I actually use fold instead of import since I find that model slightly less confusing, but whatever)
[17:47] <jam> cjwatson: what is fold?
[17:47] <jam> barry is trying to document the way to do some of this
[17:47] <jam> it would be good to update that part
[17:47] <barry> persia: ack.  i would be ecstatic if we could start with figuring out the right way to do quilt3 ;)
[17:47] <cjwatson> import creates a new patch and applies stuff in one go
[17:48] <cjwatson> fold applies stuff to the patch that's on the top of the stack
[17:48] <jam> cjwatson: so you would create a new patch on the stack, but empty
[17:48] <jam> then fold the current changes into it?
[17:48] <cjwatson> I personally find it less confusing to decompose those two operations, so I do 'quilt new name-of-patch.patch' and then 'quilt fold -p1 <external-patch'
[17:48] <cjwatson> then 'quilt refresh', and now my tree is in sync with the patch applied
[17:48] <cjwatson> and I can go fill in DEP-3 headers
[17:48] <barry> cjwatson: right.  last time i used fold though, it gave me unresolvable conflicts
[17:49] <cjwatson> that would be a "using it in the wrong context" problem :)
[17:49] <barry> :)
[17:49] <cjwatson> (I'm not at all arguing that this doesn't need some kind of wrapping up)
[17:49] <cjwatson> but fold if used correctly doesn't produce conflicts - I use it all the time
[17:49] <jam> cjwatson: I think some sort of "bzr export-to-quilt -rX..Y patch-name" is probably what we want
[17:49] <cjwatson> I agree
[17:50] <jam> but I have to actually understand quilt before I could write something like that
[17:50] <barry> jam: +1
[17:50] <jam> cjwatson: also, in my ideal udd scenario, the patches would all be in a loom that we can merge properly, and then we only export the loom to a quilt as a "and let debian see this too"
[17:51] <cjwatson> sure, with the proviso that the headers in patch files are actually useful and need to be editable
[17:51] <jam> so while I want tools to make it integrate nicely, I also don't want to spend a lot of time getting to where we want to be
[17:51] <jam> cjwatson: also something that I need either to be documented or internalized. What is in there, and what belongs in there?
[17:51] <cjwatson> http://dep.debian.net/deps/dep3/
[17:51] <cjwatson> it can reasonably be considered as "description of this thread in the loom"
[17:52] <persia> Some of that can probably be sensibly defaulted from the metainformation bzr already has.
[17:52] <cjwatson> not all of it
[17:52] <jam> persia: the problem is being a simple summary
[17:52] <jam> we could probably populate one by guessing
[17:52] <cjwatson> and TBH I think trying to do that would be a distraction
[17:52] <jam> but ultimately it is like debian/changelog
[17:52] <jam> people want to summarize what is 20-some odd commits into a simple statement
[17:52] <jam> and mutate that in the future as clarifications arise
[17:53] <cjwatson> right, exactly
[17:53] <barry> note that you do have the commit message
[17:53] <cjwatson> the commit message really isn't enough
[17:53] <cjwatson> have a look at openssh
[17:53] <jam> barry: the problem is that you have 20 commit messages
[17:53] <jam> and none are a summary
[17:53] <cjwatson> lots of those patches are long-lived
[17:53] <cjwatson> and go through multiple commits on merges, emendations, etc.
[17:53] <barry> yeah, i suppose so
[17:53] <jam> a final merge-commit *could* be a summary, but I'm not sure how you want to rollup that over time.
[17:53] <barry> export-to-quilt could take a -m
[17:54] <cjwatson> you don't want it to be something you just type in at export time
[17:54] <cjwatson> the summaries include things like justifications for why the patch is carried despite not being upstream
[17:54] <persia> Manual editing of the DEP-3 header isn't that bad, and it's not worth fussing about that yet.
[17:54] <jam> barry: the issue is "convert-loom-to-quilt" needs to track all the -m's you've supplied over time.
[17:54] <cjwatson> this is genuinely long-lived data
[17:55] <jam> persia: sure. but in a "we don't want to have debian/patches or .pc until we are finally done" determining where to put it is important
[17:55] <barry> persia: you're right.  my only issue is that it's another step that you have to remember, rather than the tools helping you remember ;)
[17:55] <jam> we don't want debian/patches because they are mostly redundant with the wt state
[17:55] <cjwatson> frex, http://patch-tracker.debian.org/patch/series/view/openssh/1:5.6p1-2/gssapi.patch
[17:55] <jam> except for stuff like dep3
[17:55] <persia> jam, You'll often start with debian/patches though.
[17:55] <jam> persia: ideally in a fully udd world (which is what this channel is about), we'd get away from them
[17:56] <jam> but yes, at some point that needs to be imported
[17:56] <jam> and at some point exported
[17:56] <cjwatson> wait, this channel is #ubuntu-devel, not #udd-devel :-)
[17:56] <jam> so the intermediate form needs to have a way to track it
[17:56] <jam> cjwatson: ah, I'm in the wrong one :)
[17:56] <jam> :)
[17:56] <persia> "this channel"?  I'm not sure about that.  In a fully-UDD world, we'd want a different implementation of Format 3.0 (bzr), and some source-format conversion tools.
[17:56] <cjwatson> this channel has to deal with interaction with Debian, and thus isn't going to get away from debian/patches/
[17:56] <barry> from __future__ import udd_dev as ubuntu_dev
[17:57] <jam> cjwatson: I just looked at the channel topic, is dapper still supported?
[17:57] <cjwatson> yes
[17:57] <cjwatson> it goes out of server support in June
[17:58] <jam> I was curious about that, and thought it had happened earlier. I guess that was desktop support
[17:58] <barry> well, the good news is that i think i have a decent workaround for bug 664276 if i can express it correctly ;)
[17:58] <cjwatson> desktop support ended in June 2009, yes
[17:59] <jam> barry:  now is that numb-pie or numpy like lumpy :)
[18:00] <barry> jam: depends on who you ask.  yooboontoo or ewboontoo?  lynn-uhx or lie-nux?  tomato or ... :)
[18:01] <jam> tomato
[18:01] <jam> sure
[18:01] <jam> I've always said numb-pie. I only just now saw it as lumpy
[18:02] <mok0> jam, I've always said "nubm-pie" but I will now start saying "numpi" :-)
[18:02] <barry> anyway, cjwatson, jam, persia thanks for the good discussion.  if you have insight into how you think this *should* work, please do post to the udd list.  i've mostly just documented what kindof-sortof-doesmostly-work
[18:03] <barry> i've always said numb-pie too, but in a kind of homer simpson "mmm! floor-pie" voice
[18:03] <jam> barry: with a little drool after it. sounds good
[18:03] <barry> :)
[18:04] <mok0> barry:  we should all start saying "numb-bee" in an Abu-kind of way ;-)
[18:05] <barry> mok0: :)
[18:06] <barry> cjwatson, persia: in dep3, should <Vendor> in Bug-<Vendor> be Launchpad or Ubuntu?
[18:06] <cjwatson> Ubuntu
[18:06] <barry> cjwatson: thanks
[18:06] <cjwatson> well, bugs.launchpad.net/ubuntu is Ubuntu
[18:06] <cjwatson> bugs.launchpad.net/<upstream> is probably just Bug:
[18:07] <barry> cjwatson: nod
[18:07] <persia> And as Launchpad develops greater support for more distributions, the answer gets more complex
[18:07] <ari-tczew> Bug: https://launchpad.net/bugs/XXXXXX
[18:07] <ari-tczew> shorter ;-)
[18:07] <persia> That's not actually helpful in this context, as it doesn't embed the string to use for Vendor
[18:07] <barry> ari-tczew: Bug-Ubuntu: though, right?
[18:07] <ari-tczew> barry: if launchpad is not bug tracker for upstream, right
[18:08] <cjwatson> ari-tczew: sure, I just meant what the canonical target for the redirection was
[18:08] <cjwatson> rather than the value of the field
[18:08] <jam> ari-tczew: http://pad.lv/XXXX even shorter
[18:09] <ari-tczew> jam: quite unnatural
[18:09] <persia> jam, Yes, but not as helpful, as it doesn't identify the source in a way easily understood by as many folk, meaning that it's trickier to integrate into other tools.
[18:09] <jam> persia: I wasn't saying you should put it into official history, just saying it is a nice shorthand to get to any lp bug
[18:10] <persia> Oh, sure.  I use http://deb.at/L#### myself, just because I find the variety of deb.at redirects helpful.
[18:10] <cjwatson> Riddell: deployed
[18:11] <barry> ari-tczew: right.  in this case, it's a purely ubuntu bug
[18:46] <kenvandine> @pilot out
[20:11] <chrisccoulson> does anyone know why all the armel builders are offline?
[20:12] <ogra> chrisccoulson, lamont i suppose
[20:13] <ogra> (he owns them)
[20:13] <chrisccoulson> thanks
[20:14] <lamont> chrisccoulson: the switch they're behind had some work done on it, and then I got back from lunch...
[20:15] <chrisccoulson> lamont, cool, thanks
[20:30] <mvo> cjwatson: btrfs alternate install works like a charm!
[20:30] <mvo> (just fyi)
[20:31] <cjwatson> mvo: yay
[23:22] <bankix> Good morning.
[23:22] <bankix> I need some help building my own kernel package for ubuntu.
[23:23] <bankix> I need a patch within my kernel and would build a new package with usual package name.
[23:24] <bankix> E.g. linux-image-2.6.32-28-ctbankix1
[23:24] <achiang> bankix: #ubuntu-kernel might be better for your question
[23:24] <bankix> Ah, good point, thanks.


[11:35] <stl_> Hi all, does anyone know why cloud-init in Ubuntu 16 makes static network interface configuration instead of dhcp like in Ubuntu 14? Thanks
[12:48] <stl_> Hi all, does anyone know why cloud-init in Ubuntu 16 makes static network interface configuration instead of dhcp like in Ubuntu 14? Thanks
[12:49] <telling> I have both package_update and package_upgrade set to true in my cloud-config, now I expect it to update before it upgrades. But thats not the behaviour i'm seeing..Is this right?
[13:06] <smoser> stl_, in 16.04, it will render network configuration that came from the cloud provider
[13:06] <smoser> in 14.04, most likely you just got "dhcp on the first network device".
[13:07] <smoser> telling, package_upgrade implies package_update at least on ubuntu. can you share a config and where you're running this ?
[13:07] <smoser> also /var/log/cloud-init.log would be useful if you can paste that.
[13:08] <smoser> powersj, sorry, responding to your last night comment.
[13:08] <smoser> tox in my mind is somewhat broken for c-i due to lxd having c (and just the pain in building that way)
[13:09] <smoser> wrt simplestreams, we can i think fix that. i have to check.
[13:18] <stl_> @smoser yes, that's correct. I figure it out from interfaces.d/50-cloud-init.cfg that whole configuration is created. I would like to have it like in Ubuntu 14 -> dhcp on interfaces. I have tried to specify dhcp for network interfaces (version 1 and also version 2) http://cloudinit.readthedocs.io/en/latest/topics/network-config.html#network-configuration-sources
[13:19] <stl_> @smoser i have upstream ubuntu images. Running OpenStack Ocata in our company
[13:24] <stl_> smoser: and my main problem with cloud-init in Ubuntu 16 is that I have two interfaces (two diferent subnet) and I am getting two default routes configured ny cloud-init. With dhcp OS will install only one default route (that's correct)
[13:33] <smoser> well, its impossible to install 2 default routes.
[13:33] <smoser> so in 14.04, cloud-init woudl pick a interface via the hard coded name 'eth0'
[13:33] <smoser> actually, cloud-init didn't do that.
[13:33] <smoser> your image had to already be configured to do that. cloud-init didn't do any networking.
[13:34] <smoser> so cloud-init in 14.04 completely ignored any information  your provider gave it.
[13:34] <smoser> in 16.04, it listens to the provider's desired network configuration and tries to apply it.
[13:34] <smoser> it is able to do that on OpenStack with ConfigDrive
[13:35] <smoser> it will fall back to "dhcp on eth0" like behavior on OpenStack if there is no config drive.
[13:35] <smoser> so, lets try to identify the problem with the routes
[13:35] <smoser> then we can fix that and cloud-init will be working for you again (i think) in 16.04
[13:36] <smoser> that make sense ?
[13:36] <stl_> i will share ip r and 50-cloud-init.cfg in a few minutes.
[13:36] <smoser> can you pastebin /var/log/cloud-init.log ? pastebinit /var/log/cloud-init.log
[13:48] <stl_> smoser: cloud-init.log https://pastebin.com/yBx8Nq14  ;  ip r output after boot https://ibb.co/k0E7g5  ;  /etc/network/interfaces.d/50-cloud-init.cfg https://ibb.co/h2v2EQ  As you can see two defaults defined by cloud-init. Both networks are usual OpenStack virtual networks. First network advertise route <IP_ADDRESS>/24.  Thank you a lot!
[13:53] <smoser> stl_, you could have used 'pastebinit'
[13:53] <smoser> :)
[13:53] <smoser> literally type: pastebinit /var/log/cloud-init.log :)
[13:54] <stl_> if i flush interfaces and run dhclient, then i get https://pastebin.com/Gh9kPdLx which is what i would expect. I have tried following cloud configs, but without success https://pastebin.com/7zb3tb1B
[13:54] <stl_> ok :) i will type
[13:55] <stl_> cloud-init.log http://paste.ubuntu.com/25592505/ :) sorry i didnt know about pastebinit
[14:00] <smoser> its a very useful command. it can paste to other pastebins, but uses ubuntu by default. ubuntu is ad-free which is nice, but requires you to log in to get "raw" download (to avoid abuse)
[14:00] <smoser> anyway... after that advertisement for pastebinit, i'm reading your pastes :)
[14:01] <smoser> stl_, would you be able to get me the network_data.json file that is on the attached config drive ?
[14:01] <smoser> cloud-inti doesnt log it, just what it converted it to.
[14:02] <stl_> smoser: sure, could you please navigate me where it is stored?
[14:03] <smoser> stl_, wow. i actuall thought that kernel/ip would fail if you tried to write two default routes (as in 'route exists')
[14:03] <smoser> hm..
[14:03] <smoser> hm... so there is a disk attached.
[14:03] <smoser> run
[14:03] <smoser> mount /dev/disk/by-label/config-v2 /mnt
[14:03] <smoser> maybe..
[14:04] <rharper> smoser:  while it's not in json format, looking at the v1 is easy enough to see: http://paste.ubuntu.com/25592551/
[14:04] <smoser> rharper, yeah, but i wanted to get the real thing
[14:04] <rharper> there are two nics, each one has a cateway, both are set as "Default"
[14:04] <rharper> gateway
[14:04] <smoser> in case we did a bad job converting
[14:04] <rharper> that's fair
[14:05] <smoser> i really thought you coudl'nt do 'ip route add default' more than once
[14:05] <smoser> so https://ibb.co/k0E7g5 confused me :)
[14:05] <rharper> we render eni here, though
[14:05] <rharper> we have |: in those post-ups to deal with the artibrary order of the hook scripts
[14:06] <rharper> interesting
[14:06] <smoser> rharper, yeah, but his 'ip r' shows them
[14:06] <rharper> well, maybe ip let's you shoot your self in the foot
[14:06] <smoser> i didnt think the kernel would let you
[14:06] <smoser> ie, i thought 'route exists'
[14:06] <rharper> it's just a table
[14:07] <rharper> that's not the kernel, that's the tool saying that
[14:07] <smoser> i thought ip tried to add a route to table and got error
[14:07] <smoser> thus "kernel"
[14:07] <smoser> anyway.
[14:07] <smoser> stl_, we really need the original network_data.json
[14:08] <rharper> I think we can get it from the obj.pkl; lemme see on an openstack instance
[14:08] <smoser> and if it says that both of those nics should contain the "default" route, then .... we're doing as close to what we we were told to do, and we'll probably need to file a bug in openstack.
[14:08] <smoser> well, it shoudl be easily mountable too though. stl_ my 'mount' command above work ?
[14:08] <rharper> y
[14:09] <smoser> rharper, in your pasted config..
[14:09] <smoser> we could have make a hueristic decision there
[14:09] <smoser> as the first had a default route *and* a netmak'd route
[14:09] <stl_> smoser: here's paste http://paste.ubuntu.com/25592580/ it's from configdrive openstack/latest/network_data.json
[14:10] <smoser> oh wierd. but that .20
[14:10] <smoser> wierd
[14:10] <smoser> stl_, tyats what we needed. thanks
[14:10] <stl_> smoser: great! thank you
[14:12] <rharper> smoser: heh
[14:12] <rharper> we just copy in the routes provided
[14:13] <smoser> http://paste.ubuntu.com/25592599/
[14:13] <smoser> ^ is just prettier formated of stl's paste.
[14:13] <rharper> I'm not sure at conversion time we can make a choice;   I suspect the second network/nic need not have a gateway, but we don't know how the subnet in neutron was configured
[14:14] <smoser> yeah. it is buggy.
[14:14] <smoser> openstack is.
[14:15] <smoser> they tell us there are two networks and give a default route on both. there isnt really a way to pick.
[14:15] <smoser> hm..
[14:15] <smoser> stl_, do you have access to the hypervisor ?
[14:16] <stl_> smoser: yes I have
[14:16] <smoser> it'd be good for you to file a bug with 'ubuntu-bug nova-compute'
[14:16] <smoser> and then i can fill in some othoer info
[14:16] <smoser> you open it, and then i'll fill in the rest.
[14:16] <smoser> but basically they're giving us incomplete information
[14:17] <smoser> cloud-init is doing what they said to do :)
[14:17] <smoser> stl_, interstingly i think that if you ran dhclient on boht of those interfaces, you'd probably only get one route as default
[14:17] <smoser> and that would be random based on which got done first
[14:17] <stl_> actualy our hypervisors don't have access to Internet if 'ubuntu-bug nova-compute' is Ubuntu command
[14:18] <smoser> unless they have that path somehow fixed and one of the dhcp servers would *not* give you that default route
[14:18] <smoser> stl_, it is a command. it'd just collect some info on versions and things.
[14:18] <stl_> smoser: yes, if i run dhclient i will get default only from second interfaces (that's what i want)
[14:18] <smoser> "second"
[14:19] <smoser> as in "second that your run" ? or as in "always network1"
[14:20] <smoser> stl_, i'm kind of curious to see that. if you ran 'dhclient eth0' and 'dhclient eth1' and got the leases and the output of each. i'd be interested to see.
[14:21] <stl_> smoser: I was always runing just "sudo dhclient"
[14:21] <stl_> but i can try dhclient ens3 and then dhclient ens4
[14:21] <smoser> stl_, you have a launchpad id ?
[14:21] <smoser> i'll copy you on the bug.
[14:22] <smoser> stl_, if you wanted... dhclient -v
[14:22] <smoser> woudl be sufficient
[14:22] <smoser> the grab the /var/lib/dhcp/dhclient.leases file
[14:25] <stl_> smoser: https://ibb.co/bWHA15 got same default. Looks like if no route is advertised then default is installed.
[14:25] <stl_> smoser: I have launchpad account
[14:30] <smoser> stl_, i suspect that one of the two dhcp servers advertised a default route
[14:30] <smoser> could you
[14:30] <smoser>  dhclient -r
[14:30] <smoser> then
[14:31] <smoser> dhclient -v
[14:31] <smoser> and then get /var/lib/dhcp/dhclient.leases ?
[14:31] <stl_> sure
[14:34] <stl_> console, dhclient -r, dhclient -v https://ibb.co/mZYTok  here's dhclient.leases http://paste.ubuntu.com/25592685/
[14:40] <frickler> there is a bug against neutron that wants to allow not having a default route for networks: https://bugs.launchpad.net/neutron/+bug/1717560
[14:40] <rharper> interesting
[14:41] <frickler> stl_: not sure if I missed that in the scrollback, could you also pastebin the output of "openstack network/subnet show" for your (sub)networks?
[14:42] <stl_> frickler: will do
[14:42] <rharper> smoser: looking at the leases, only ens4 has 'routers' option;  and there is 'classless-static-routes' for both;  I'm not sure how those relate to  setting routes on the system, but I wouldn't expose those to become a default route
[14:42] <smoser> frickler, ! welcome . i was trying to think of who i knew that had some openstack networking chops
[14:42] <smoser> and he stepped right into the room!
[14:43]  * rharper is awed by the summoning powers of smoser
[14:43] <frickler> smoser: been lurking here for long :D
[14:44] <frickler> just took a view after seeing stl_'s question over in #openstack ;)
[14:44] <smoser> oh. ok. i'm opening a bug.
[14:44] <frickler> also about to leave for the weekend, but I hope I can take another look later
[14:44] <smoser> it does appear from his dhclient leases that the servers "know"
[14:45] <smoser> frickler, you leave work to early (and i'm not accepting any excuse that includes the word 'timezone')
[14:45] <smoser> :)
[14:46] <stl_> here's openstack network and subnet pastes http://paste.ubuntu.com/25592742/
[14:48] <stl_> smoser: if you need i can open bug on launchpad
[14:51] <smoser> https://bugs.launchpad.net/nova/+bug/1718954
[14:51] <stl_> thanks!
[14:56] <smoser> stl_, who are you there?
[14:56] <smoser> Lukas or Dr. Jens ?
[14:57] <stl_> smoser: Lukas :)
[14:57] <smoser> stl_, if you're looking for a hack / workaround
[14:57] <smoser> the easiest thing is probably to just delete the route
[14:58] <smoser> ip route delete ...
[14:58] <smoser> of the bad one
[14:59] <stl_> smoser: yes, that's something i have came up also. I was hoping that cloud-config will work (set interfaces to dhcp), but no success from my side.
[15:01] <smoser> stl_, well, you can't really affect networking confguration in user-data
[15:01] <smoser> its just kind of "too late"
[15:02] <stl_> :)
[15:04] <smoser> stl_, you could provide some script to run that would re-write it, so it'd be fixed on reboot
[15:04] <smoser> but you could just as well add a post ifup.d
[15:04] <smoser> that took out that default route
[15:08] <stl_> thanks for help and that bug report! Have a nice weekend.
[15:09] <kszarlej> hi guys. I have that configuration for NoCloud drive. It is used for my LibVirt KVM VMs. The mount (vdb) is not mounted. The device is available at /dev/sdb and in /etc/cloud/cloud.cfg the mounts module is listed in init modules. There is no error in logs. Any suggestions?
[15:09] <kszarlej> oh the configuration is here, forgot the link http://paste.ubuntu.com/25592915/
[15:12] <kszarlej> the /data directory actually doesnt exist when booting but I assume that cloud-init should create it? (Creating it using runcmd is pointless as it runs after the mounts module)
[15:44] <powersj> kszarlej: can you please look the two lcoud-init logs under: /var/log/cloud-init*
[15:44] <powersj> smoser: rharper: https://bugs.launchpad.net/cloud-init/+bug/1718959 looks like this guy ran into an odd unicode character. Is there a good suggestion to help him debug his user-config?
[15:46] <kszarlej> powersj: found that
[15:46] <kszarlej> http://paste.ubuntu.com/25593105/
[15:46] <kszarlej> in cloud-init.log
[15:47] <kszarlej> looks like the ci cant see the mount I have in config
[15:49] <kszarlej> btw I use centos and a daily build from cloud init devel repo (because the upstream from centos repos is broken :P)
[15:54] <kszarlej> rest of the stuff specified in meta-data was configured fine
[15:58] <powersj> kszarlej: was the daily build from: https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/
[16:00] <kszarlej> yes
[16:00] <kszarlej> the one that is in centos 7 repos
[16:00] <kszarlej> was unable to set the networking
[16:00] <kszarlej> been consulting that yesterday evening here :P
[16:01] <powersj> kszarlej: If you could, can you file a bug please.
[16:10] <blackboxsw> I can't wait for us to get 17.1 into xenial so we can have  "ubuntu file-bug cloud-init".
[16:11] <blackboxsw> it works currently on artful
[16:11] <blackboxsw> I mean ubunt-bug cloud-init
[16:11] <blackboxsw> I mean ubuntu-bug cloud-init
[16:11] <blackboxsw> third time's the charm
[16:13] <blackboxsw> I know that won't help us on centos, but it's a fun improvement for ubuntu
[16:14] <blackboxsw> kszarlej: you can run cloud-init collect-logs to collect a tarfile of logs that can be attached to the bug
[16:16] <blackboxsw> or even 'cloud-init collect-logs --include-userdata
[16:28] <smoser> blackboxsw, well, kszarlej is using trunk
[16:28] <smoser> so he can
[16:28] <blackboxsw> trunk centos  right?
[16:28] <smoser> trunk on centos
[16:28] <smoser> (copr build)
[16:28] <blackboxsw> he can "collect-logs --include-userdata" :)
[16:29] <smoser> right
[16:29] <smoser> ah. ubuntu-bug . i see . you were saying that wont work there.
[16:29] <smoser> which is treu
[16:29] <smoser> true even
[16:29] <blackboxsw> glad someone has has a case of typos this morning
[16:32] <smoser> kszarlej, is that you -> https://bugs.launchpad.net/cloud-init/+bug/1718959 ?
[16:33] <powersj> smoser: if you make a request of someone can you mark the bug incomplete?
[16:35] <dpb1> yes
[16:35] <dpb1> absolutely
[16:35] <kszarlej> smoser: no
[16:35] <kszarlej> I didnt create the bug yet
[16:35] <kszarlej> trying to make a workaround first
[16:35] <kszarlej> need to have that working today
[16:36] <dpb1> powersj: there is room for judgement if the request isn't material to the working on the bug, but normally, you don't want to action a bug with incomplete information.
[16:37] <powersj> dpb1: agreed: I just like to see new bugs that we respond to either moved to incomplete, invalid, or confirmed.
[16:37] <kszarlej> ok now I lost my mind
[16:38] <smoser> done
[16:38] <dpb1> powersj: yes, it's a sane policy that we should try to stick to.  (or wont fix)
[16:38] <kszarlej> http://paste.ubuntu.com/25593417/ and in log: 2017-09-22 16:32:00,901 - cc_runcmd.py[DEBUG]: Skipping module named runcmd, no 'runcmd' key in configuration
[16:44] <ajorg> gah. why haven't I prepared https://git.launchpad.net/~ajorgens/cloud-init/commit/?id=aaa626dd8aecc078210d3a48ff39faf3fd30cbdc for merging yet. It seemed pretty important when I wrote it!
[16:46] <blackboxsw> it's that "day job" thing... it just keeps getting in the way of good fun
[16:46] <ajorg> seriously
[16:54] <cesarjorge_> Hi
[16:56] <cesarjorge_> I need help with cloud-init in an OS image of Centos 7.4 that I build
[16:57] <ajorg> cesarjorge_: best to cut right to the chase and describe the problem you ran into
[16:58] <cesarjorge_> I need to create this image to working without extra changes in the cloud or not cloud environments:
[17:00] <cesarjorge_> I need that my image instantiate correctly if I launch it, for example, inside OpenStack, or, as a simple instance in local, I have virtualbox
[17:01] <cesarjorge_> Then, if I launch the image in OpenStack, works correctly. But if launch the image in virtualbox (as a simple instance), the cloud-init does:
[17:02] <cesarjorge_> Break my configured specific user with password, and takes many time to start
[17:03] <cesarjorge_> And does other things
[17:04] <cesarjorge_> Then, I need create a image that, if not launched in cloud, then do nothing and not interfere. If launch in a cloud, then execute as normal
[17:16] <cesarjorge_> How can I do it?
[17:17] <blackboxsw> ok schema suggestion for https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/331149 added robjo_away
[17:18] <ajorg> cesarjorge_: you've tried, and it doesn't work? Or you're assuming it won't work?
[17:20] <ajorg> IIRC for VirtualBox cloud-init will try to use the NoCloud data source: https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
[17:20] <smoser> cesarjorge_, ajorg is right. cloud-init goes looking for a "datasource". and if it doesnt find one can be kind of annoying. you can provide it one in virtualbox.
[17:22] <smoser> you can configure the datasource_list in the image to only consider OpenStack (or ConfigDrive) and NoCloud
[17:22] <smoser> then it wont end up polling for the ec2 metadata service
[17:22] <cesarjorge_> I have try, but dont work. Using datasources will work?
[17:22] <smoser> and will fallback to the None datasource faster.
[17:23] <smoser> well, "don't work" isnt much information.
[17:23] <smoser> NoCloud will work in virtualbox for sure.
[17:23] <smoser> https://asciinema.org/a/132013
[17:24] <smoser> theres a ubuntu cloud image demo of doing this in qemu-system-x86_64 but the same basic thing will work on virtualbox.
[17:24] <ajorg> "Break my configured specific user with password" you can probably configure it not to do, with a NoCloud source. "takes many time to start" sounds mysterious
[17:25] <ajorg> https://cloudinit.readthedocs.io/en/latest/topics/modules.html#users-and-groups
[17:25] <cesarjorge_> Then, I configure datasource_list: [ NoCloud ] ?
[17:25] <cesarjorge_> In file cloud.cfg?
[17:25] <ajorg> oh, you probably mean it take *much* time to start. That's fixed by limiting it to the data sources you know it might use, as smoser said.
[17:26] <smoser> well, if you want it to work on penstack you'll need to put either ConfigDrive or OpenStack in there.
[17:26] <smoser> (ajorg, i assume he's polling for the ec2 metadata service is what takes long)
[17:27] <ajorg> smoser: I thought that was fixed by checking the system uuid?
[17:27] <smoser> hm...... yeah.
[17:27] <ajorg> but if he's on CentOS he's got an older version, probably. CentOS and RHEL are not aligned for cloud-init last I checked.
[17:27] <smoser> you're right.
[17:28] <smoser> yeah
[17:28] <cesarjorge_> Version 0.7.9 for centos 7.4
[17:29] <ajorg> Oh, maybe they fixed that. They used to be on 0.7.5.
[17:30] <ajorg> I assume it checks for lots of other clouds though, and any of those takes time?
[17:31] <cesarjorge_> I just tried using a image with line datasource_list: [ OpenStack ]. Inside virtualbox works good. But inside OpenStack fail
[17:32] <cesarjorge_> Only if I boot the image without using no cloud task. Simply starting VM
[17:37] <cesarjorge_> Question: What tasks does the None datasource do?
[17:38] <cesarjorge_> This datasource is executed if no find any?
[17:41] <ajorg> https://cloudinit.readthedocs.io/en/latest/topics/datasources/fallback.html
[17:43] <smoser> none datasource doesnt do much. yes. basically generates ssh keys. will probably add the default user. and might lock its password (you could change that in config)
[17:45] <smoser> frickler, just for your later reference
[17:45] <smoser>  https://bugs.launchpad.net/nova/+bug/1718954
[17:46] <cesarjorge_> If I lock password, in config, then when I launch in openstack not work with ssh keys
[17:46] <smoser> ?
[17:47] <smoser> if you want a user that is already in the image and will always be accessible, just create one.  you can put ssh keys in it or not and set a password or not. cloud-init will not make any changes to that user.
[17:48] <smoser> name it 'superdude' or something.
[17:51] <cesarjorge_> If I launck in openstack, cloud-init modify the file /etc/ssh/sshd_config removing all passwordauthetication yes
[17:52] <cesarjorge_> For all users
[17:53] <cesarjorge_> If insert a specific line Match ssh user passwordauthentication no, then, does same thing, remove this line
[17:58] <smoser> i'm going to go through fix-commnitted bugs now and mark fix-released for all in 17.1
[17:59] <smoser> cesarjorge_, you can set that.
[17:59] <smoser> i am not aware of ssh user passwordauthentication. you're saying that  is a sshd_config setting that you can set per-user stuff ? i didnt know and tis quite possible that cloud-init gets confused by that.
[18:00] <smoser> you can tell cloud-init to either always enable password auth or not mess with it.
[18:00] <smoser> ssh_pwauth: <yes/no/unchanged>
[18:00] <cesarjorge_> In summary: I try to use same image for a cloud environment or isolate environment. In cloud environment I use cloud-init with ssh keys. In my isolate environment, i use one user with password, dont need the work for configurate extra things. Then, when the image works in cloud, dont work in isolate environment, and backwards
[18:04] <cesarjorge_> The result in isolate env when I do ssh: no authentication method available, because cloud-init change this passwordauthentication in sshd config
[18:05] <cesarjorge_> But, for openstack, I need this variable to do ssh public key for all users
[18:09] <cesarjorge_> I can configure virtualbox for use ssh public key, but complicate the configuration for users than only need work with an isolate VM, using passwords, without extra configuration
[18:15] <smoser> cesarjorge_, so you'd like for it to leave password authentication unchanged when running on a cloud
[18:15] <smoser> but turn it off when running local
[18:16] <smoser> er.. leave unchanged (off) when running on a cloud. but when run locally enable it.
[18:17] <smoser> you can kind of do this i think if you backed config for NoCloud into the image that had its own config there.
[18:17] <cesarjorge_> Passwordauthentication no, when cloud, passwordauthentication unchanged when no cloud
[18:17] <smoser> wait.
[18:17] <smoser> right
[18:17] <cesarjorge_> Or, better, not execute nothing nothing if no cloud
[18:17] <smoser> yeah. so you could do this by provding inside the image NoCloud config that would end up getting always found (in the event that it was not on a cloud)
[18:18] <cesarjorge_> Better write: not change nothing in the instance if no cloud
[18:19] <smoser> i think what you want is mostly how Ubuntu in 17.04 and later is set to work
[18:19] <smoser> if cloud-init finds its not in a cloud, it disables itself entirely.
[18:20] <smoser> so it should be acheivable with centos too. but i'm not sure how well the systemd-generator stuff is integrated tehre.
[18:21] <smoser> cesarjorge_, i'm sorry, i can't spend any more time on this now.  i think what you're after is either doable or not far off.
[18:21] <cesarjorge_> Workaround for centos? The RH/centos take a lot of tima in upgrade official versions
[18:22] <smoser> cesarjorge_, you definitely need newer cloud-init. from trunk-ish
[18:23] <smoser> we have copr builds
[18:23] <smoser>  https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/
[18:23] <smoser> those are of trunk
[18:25] <cesarjorge_> Thanks, I will try this trunk version. If you encounter a workaround for 0.7.9,, i would be grateful
[18:51] <robjo> blackboxsw: thanks
[18:52] <blackboxsw> np robjo
[18:52] <robjo> on the schema, I guess the basic question would be do we want to validate everything
[18:53] <robjo> that would imply  that yes we'd have to document everything at https://en.opensuse.org/openSUSE:Standards_RepoInfo
[18:53] <robjo> but that appears overkill to me
[18:53] <robjo> and of course total duplication
[18:55] <robjo> blackboxsw: ^^^^^
[18:55] <blackboxsw> robjo: yeah it also forces you into a high-maintenance world where cloud-init was out of date as format moves on
[18:56] <robjo> yes, thus it would be much nicer if the validation can somehow throw up it's hands and say "Ok, I know you need "baseurl" for everything else I don't care"
[18:57] <robjo> is that an option?
[18:57] <blackboxsw> as you saw with the config example, the permissive approach would be the following:                 'config': {
[18:57] <blackboxsw>                     'type': 'object',
[18:57] <blackboxsw>                     'description': 'Any supported zypo.conf key is written to /etc/zypp/zypp.conf'
[18:57] <blackboxsw>                 }
[18:57] <blackboxsw> yeah per the repos structure it could be the following if all you care about is baseurl
[18:57] <blackboxsw> one sec, will paste
[18:59] <robjo> And then the "id" is required becauase we cannot validate "any_random_name:" right?
[18:59] <blackboxsw> http://pastebin.ubuntu.com/25594124/
[18:59] <blackboxsw> yeah like this robjo
[19:00] <blackboxsw> yeah otherwise jsonschema can't describe the subschema under <any_random_name>: {...}
[19:01] <blackboxsw> I will take an action as I keep adding more schema though to see if there is a sensible way to describe that in jsonschema
[19:01] <blackboxsw> and if so, to send a patch and ping you... admitedly I'm still a newbie at jsonschema
[19:02] <robjo> Well we need multiple ids though such that a user can add as many repos as they want
[19:03] <robjo> so repos is really repos :{ [id, baseurl,....],[id baseurl,...],[id, baseurl,....]}
[19:04] <robjo> I am OK with calling it id, as this is an incompatible change we just need to nail it down and then leave it, whatever it is
[19:05] <robjo> So how do we express the list behavior?
[19:06] <blackboxsw> robjo: oops type in the schema.. one fixing the paste
[19:06] <blackboxsw> will account for that
[19:06] <robjo> and what does it look like in yaml?
[19:10] <ajorg> robjo: I'm missing some context (sorry for jumping in here). What are you working on?
[19:11] <robjo> Trying to figure out what the repo definition shoud look like, https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/331149
[19:13] <blackboxsw> http://paste.ubuntu.com/25594201/
[19:13] <blackboxsw> ok I'm looking over the following ^ as a potential it defines repos as a list w/ min items 1
[19:13] <blackboxsw> and declares that each item must have baseurl and id in it.
[19:13] <blackboxsw> other attributes are allowed
[19:15] <ajorg> robjo: interesting. I thought the spec was identical for zypp and for yum?
[19:15] <ajorg> just the file location was different?
[19:16] <robjo> blackboxsw: that works for the schema I don't think this can be expresed in yaml
[19:17] <robjo> ajorg: the repo description is different, and there is the desire to change things, i.e. th ecurrent implementation for RHEl is not what we want to do
[19:17] <ajorg> okay, cool
[19:18] <robjo> blackboxsw: That works for schema validation, but cannot be expressed in YAML, I think
[19:18] <ajorg> reminds me i have a patch that helps make sure yum config is correct, but it's currently buried in another patch, need to tease that out
[19:18] <blackboxsw> robjo: drawing up an example and testing w/ your branch
[19:20] <robjo> The point of the <arbitrary_name>: is to give yaml a separator and each is unique thus the result is a dict with {arbitrary_name1:{....], arbitrary_name2:{....}}
[19:21] <robjo> but if we say items: then there's no way to differentiate for the yaml parser and the result is undetermined
[19:22] <blackboxsw> robjo: like this? http://pastebin.ubuntu.com/25594260/
[19:23] <blackboxsw> can't your module validate 'id' on each object is unique?
[19:25] <blackboxsw> or this http://pastebin.ubuntu.com/25594275/
[19:25] <robjo> yaml bitches at that, looking at the error
[19:28] <blackboxsw> hmm here's on my side http://pastebin.ubuntu.com/25594296/
[19:29] <robjo> yes, without the {} I got it to work as well
[19:29] <blackboxsw> ahh checking the {} again to see if I can get that working
[19:30] <robjo> But that works, so I'll run with that
[19:32] <blackboxsw> robjo: yeah less characters than the other way
[19:32] <blackboxsw> here's the other http://pastebin.ubuntu.com/25594320/
[19:32] <blackboxsw> had to fix a bunch
[19:34] <robjo> Thanks, I like the - better I'll use that as example ;)
[19:34] <blackboxsw> I'm still trying to get the suggestion for your schema to work... I iterate w/ python3 -m 'cloudinit.cmd.main devel schema --doc' and ... devel schema -c <sample-cloud-config>
[19:40] <blackboxsw> and initial patch  for schema http://paste.ubuntu.com/25594361/
[19:41] <blackboxsw> robjo: ^
[19:41] <blackboxsw> you'll also need to git fetch; and get rebase origin master as we put in a docs fix related to schema yesterday
[19:41] <blackboxsw> that helps rendering
[19:42] <robjo> blackboxsw: great thanks, I'll get that included and hopefully will get the test written yet his afternoon, for another full review
[19:42] <blackboxsw> +1
[19:42] <robjo> next week is SUSECon I'll have little to no time....
[19:43] <blackboxsw> I'd imagine, we're heading for a sprint next week too so response times may be slow
[19:44] <smoser> blackboxsw, welll.. comments on https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/330115
[19:44] <smoser> robjo, i think my invitation to SUSECon got lost in the mail.
[19:45] <robjo> smoser: and Prague is such a nice place
[19:45] <smoser> yeah.
[19:47] <smoser> blackboxsw, i commented on your json file stuff
[19:48] <blackboxsw> thanks smoser will look at what we think should be done there
[20:01] <blackboxsw> smoser: good points, yeah I stopped work on this when we were trying to get 17.1 stuff in. Forgot that I didn't get back to work out the standardized top-level keys vs datasource blobs
[20:06] <blackboxsw> I had debated about iterating on standard/nornmalized metadata keys in instance-data.json on a followup branch. But, I guess we can implement low-hanging fruit in this branch. The problem with normalized/general keys is that we may have to have a ds.normalized_metadata  function that each datasource may have to implement to surface the common named keys if they don't already have it in meta/user-data
[20:09] <smoser> agreed
[20:19] <robjo> how do I run just one test? while I am working on the tests for zypper_add_repo I do not really want to run the whole test suite over and over again
[20:20] <robjo> and next question how do I populate the tmp location with a file that can be read by a test?
[20:25] <smoser> robjo, fastest thing is to use ./tools/tox-venv
[20:25] <smoser> $ ./tools/tox-venv py3 python3 -m nose tests/unittests/test_util.py
[20:25] <smoser> if you just want to run your tests and dont want to use tox-venv or it didnt work for you
[20:25] <smoser> $ tox -e py3 tests/unittests/test_util.py
[20:26] <smoser> tox-venv skips the "install" phase which is slow.
[20:26] <smoser> to populate a tmp location...
[20:26] <smoser> probably easiest is, if youre subclass of CiTestCase
[20:26] <smoser>  tmp = self.tmp_dir()
[20:27] <robjo> right now, i.e. in the pending MR it is: class TestConfig(helpers.FilesystemMockingTestCase):
[20:27] <smoser>  helpers.populate_dir(tmp, {'etc/passwd': content_for_that, 'usr/file1': more_stuff})
[20:28] <robjo> great, thanks
[20:28] <smoser> you want to do the populating before you patchUtils()
[20:28] <smoser> or it gets in the way
[20:29] <smoser> err... rather than patchUtils
[20:29] <smoser> probably patch.reRoot() is what youw ant
[20:29] <smoser> but do your pouplation of things *before* that
[20:46] <blackboxsw> meh all systemd dhcp lease parsing content/handlers are defined in internal header files.
[20:47] <blackboxsw> private dhcp options are parsed and added to internal lease objects
[20:47] <blackboxsw> but I don't yet see a path to expose that content
[20:49] <blackboxsw> FilesystemMockingTestCase subclasses from CiTestCase so self.tmp_dir() tmp_path are available there too
[20:51] <blackboxsw> hrm per systemd: sd_dhcp_client_get_lease might be what I want
[21:17] <robjo> smoser: is there already a utility function in the test infrastructure to confirm that warning messages get written or do I need to do that via @patch?
[21:25] <blackboxsw> smoser: rharper  :) http://pastebin.ubuntu.com/25594875/
[21:25] <blackboxsw> I think we can get to systemd custom dhcp options
[21:25] <blackboxsw> busctl FTW
[21:26] <blackboxsw> checking other instance types
[21:26] <rharper> blackboxsw: whoa
[21:27] <rharper> busctl needs a --json *so* bad
[21:27] <rharper> I've not looked at it yet, but there is python systemd module
[21:28] <rharper> maybe there's some easy access to the systemd dbus
[21:28] <blackboxsw> yeah it's nasty
[21:28] <blackboxsw> with custom types etc
[21:29] <rharper> oh, that's NetworkManager
[21:30] <rharper> org.freedesktop.systemd1
[21:59] <blackboxsw> yeah unfortunately /org/freedesktop/network1 gives us nothing of use. it describes the systemd network files used, but nothing as far as dhcp or network related config settings
[22:46] <smoser> blackboxsw, but that comes from networkmanager
[22:47] <smoser> not systemd
[22:47] <smoser> systemd-netwokrd
[22:47] <blackboxsw> yeah, looking at extending systemd-networkd to expose options
[22:47] <blackboxsw> yeah, looking at extending systemd-networkd to expose dhcp-options
[22:47] <blackboxsw> just like NetworkManager does. it's a bit of a lift.... and my C is rusty
[22:47] <smoser> horay for change for the sake of change!
[22:47] <blackboxsw> heh
[22:47] <smoser> we'd all be out of work otherwise.
[22:48] <smoser> what would i have accomplished from 14.04 to 16.04 if not for systemd.
[22:48] <smoser> nothing
[22:48] <blackboxsw> heh
[22:48] <blackboxsw> gotta stir up some dinner
[22:48] <blackboxsw> have  a good weekend folks
[22:54] <robjo> smoser: https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/331149 ready for another review.
[22:54] <robjo> Have a nice weekend everyone


[06:35] <filipsohajek> Hello, can you please triage this bug, and assign priority to critical? https://bugs.launchpad.net/ubuntu/+source/poco/+bug/1361610 Thanks
[06:35] <ubot2`> Ubuntu bug 1361610 in poco "libPCRE3 8.31 regex matching is not working" [Undecided,Confirmed]
[19:06] <tarpman> would someone please mark bug 1362481 as triaged? thanks.
[19:07] <tarpman> actually, cancel that, I'll take it and call it in progress
[19:32] <hggdh> heh. Thanks :-)


[08:34] <JamesTait> Good morning all; happy Colour TV Day! :-D
[09:35] <mapreri> umh, I wanted to try mover to move my files out of u1, but I can't find a way to use it with the 2FA active. suggestion?
[09:36] <mapreri> (I don't want to disable 2FA)
[12:55] <beuno> mapreri, I don't follow, it seems to work fine for me with 2fa
[13:01] <mapreri> beuno: if I go to apps.mover.io and I try to add the U1 connector, mover asks me fr my credential and I (reluctant, I dislike give my credential away) insert my uSSO email and password mover tells me "Please double check your UbuntuOneConnector credentials and try again.". It does not ask for my one time password.
[13:09] <beuno> mapreri, it works well for me, are you sure the credentials are the right ones?
[13:11] <mapreri> beuno: yes, I am.


[10:02] <slickymaster> morning all
[11:11] <davmor2> Morning all
[12:39] <jibel> pitti, did you already try -hda fat:<directory> to share data between a qemu guest and the host? Do you know if there is any limitation?
[12:39] <jibel> (or -hdb, ...)
[12:39] <jibel> fat:rw:<dir> even
[13:02] <pitti> jibel: oh nice, I wasn't aware of that
[13:02] <pitti> jibel: you'd still need to inject some command to copy files from it, or bind-mount it, or run programs on it
[13:03] <pitti> jibel: but it's a simple (and much faster) way to copy up/down the tests and results
[13:04] <jibel> pitti, indeed, I was just wondering if it is well supported because it prints some weird warning on mount/umount


[02:19] <twb> I need a quick sanity check, please -- I have a server with linux-image-2.6.32-64-virtual installed, but uname -a is saying 2.6.32-64-server.
[02:19] <twb> Do -virtual builds normally report themselves as -server?
[02:24] <tarpman> twb: iirc, yes; and http://packages.ubuntu.com/lucid-updates/amd64/linux-image-2.6.32-65-virtual/filelist agrees
[02:24] <twb> OK, thanks
[02:25] <twb> (Didn't realize it would show up there, I was thinking it was only going into the local string in /boot/config-XXX.)
[03:57] <jetole> Hey! Is anyone in here pretty familiar with likewise open / PBIS open ?
[04:25] <Kane_> Hey, Just refered here. You guys think 14 is a good for a Avg website and website like uses no GUI etc. I think it has a 5 year support plan?
[07:22] <|\n> hey, guys! when ksplice was in beta i was testing it on my home server out of curiousity and it was amazing, now i have not-that-important production vds on kvm with 14.04 server, any hints on if its license free in this case or if it is even possible under kvm?
[07:34] <Sachiru> Does it have to be kSplice, or do you just want no-reboot updates?
[07:44] <|\n> Sachiru, the second is my end-goal, yeah! thank you for paying attention also =)
[07:44] <Sachiru> Hmm.
[07:45] <Sachiru> There are methods to achieve no-reboot updates, but they are non-trivial to apply (kExec, KernelCare, etc.)
[07:46] <|\n> Sachiru, any of them applied at least on non-critical places in production by chance?
[07:46] <Sachiru> Sure.
[07:46] <Sachiru> kExec is a standard Linux utility
[07:47] <|\n> Sachiru, thank you, gonna investigate those
[07:47] <Sachiru> Look into https://en.wikipedia.org/wiki/Kexec
[07:50] <Sachiru> Another is KernelCare, just as robust as kSplice, but less pricy
[07:53] <|\n> reading kexec unresolved issues part in canonical's manpages, seems fine so far
[08:14] <Sachiru> IMHO rebootless upgrades aren't really ideal. Want 99.999% uptime?  Consolidating everything onto one server is suicide, no matter how much you try to harden it, if it goes down (and it inevitably will) everything will go down with it.
[08:15] <|\n> how about backups? =)
[08:16] <Sachiru> A backup will not prevent service interruption.
[08:16] <Sachiru> Load-balancing and redundancy will.
[08:16] <|\n> it is not critical box
[08:16] <|\n> and you are totally right
[08:16] <Sachiru> Backups are there to recover from failure. Redundancy is there to *prevent* failure
[12:10] <Vladimir> Maybe wrong channel, but I wonder if there's a command to check what devices my packets go to first in my layer 2 network from ubuntu server machine?
[12:10] <rbasak> Vladimir: tcpdump?
[12:10] <Vladimir> oh okey
[12:10] <Vladimir> =)
[12:11] <rbasak> There's an option to show you MAC addresses.
[12:12] <Vladimir> arp -a?
[12:13] <Vladimir> arp -a seems to show the last mac address, I need the first hop mac adress
[12:14] <lordievader> Vladimir: traceroute?
[12:18] <Vladimir> lordievader: I tried it also
[12:18] <lordievader> That will at least report the routers in between source and destination.
[12:21] <Vladimir> lordievader: yeah but it'
[12:21] <rbasak> First hop mac address?
[12:21] <Vladimir> it's a Layer 2 network
[12:21] <rbasak> You mean a layer 2 hop there?
[12:21] <Vladimir> so no routers invovlved
[12:21] <rbasak> Or a layer 3 hop?
[12:21] <Vladimir> layer 2 hop
[12:21] <lordievader> Ah, right.
[12:22] <rbasak> I'm not sure that's possible. Switches hide that from you as part of the Ethernet protocol.
[12:22] <rbasak> You might be able to get something out of spanning tree protocol or something like that though.
[12:22] <rbasak> A server just isn't aware of what's on the first hop. Switches don't even have to have MAC addresses.
[12:23] <Vladimir> thing is, we have a wifi controller in the network, and want to know if the packets go through it or not since the server is on the WIFI for the moment
[12:23] <Vladimir> I better ask on another channel, no worries=)
[12:24] <rbasak> Get a switch with a mirror port (or a hub), put it "in the way" and use tcpdump on the mirror port.
[12:25] <rbasak> Or used managed switches and query them for their MAC address tables.
[12:28] <Vladimir> rbasak: thanks=)
[13:08] <halvors> Hi! I need to be able to login to my ubuntu-server using Active Directory login credentials. Is there a easy way to implement this?
[13:38] <Mississauga> any reason for NOT installing latest server version? empty hard disk?
[13:39] <Mississauga> is it safer to go with an older version, say 13.x ?
[13:39] <Pici> Mississauga: If you need to go with an older release, at least pick 12.04 LTS.
[13:42] <Mississauga> I rather go with 14.04 but I wondered if there are bugs
[13:44] <cfhowlett> Mississauga, 14.04 has reached release point .1      and I've heard few complaints in #ubuntu-server
[13:45] <lordievader> For me it has been very stable so far.
[13:49] <cemc> hi. I have ubuntu server 14.04 installed, with eth0 dhcp. I'm trying to set my own static DNS servers, disregarding the DHCP ones. I created /etc/resolv.conf file (not a symlink to resolvconf) but it still gets overwritten at reboot
[13:57] <RoyK> Mississauga: 12.04 is an LTS and is good. 14.04 is also an LTS and has been out for a while and is also good
[13:57] <RoyK> Mississauga: 13.04 and 13.10 are *not* LTS releases and shouldn't be used on servers (IMO)
[13:57] <RoyK> Mississauga: I'd use 14.04 if I were to install ubuntu on a new server
[13:58] <lordievader> 13.04 and 13.10 are EOL.
[13:59]  * RoyK knows
[13:59] <lordievader> Mississauga might not ;)
[13:59] <RoyK> anyway, I wouldn't use 14.10 on a server either, when it gets released
[14:01] <Mississauga> so I guess 14.04 ok for server
[14:03] <cfhowlett> Mississauga, 14.04.1 ??
[14:03] <RoyK> Mississauga: yes
[14:04] <Mississauga> whats that last  .1 ?
[14:04] <RoyK> Mississauga: patch level
[14:04] <RoyK> Mississauga: just use 14.04.1
[14:04] <cfhowlett> Mississauga, point release current version
[14:05] <Mississauga> I looking to buy a book on it to keep around,  anyone familiar with this book ?"Ubuntu 14.04 Lts Server: Administration and Reference"
[14:06] <Mississauga> by Richard Leland Petersen
[14:06] <cfhowlett> Mississauga, nope.  but I'd suggest "the official ubuntu server book"
[14:07] <Mississauga> so whats wrong with it?
[14:07] <hallyn> dannf: congrats :)
[14:11] <RoyK> Mississauga: he said he didn't know it, just suggested something else :P
[14:36] <dannf> hallyn: thanks! to you as well, belated :)
[17:11] <^^x^^> it's reeeeeally quite in here
[17:11] <arrrghhh> ^^x^^, it is quite quiet.
[17:15] <^^x^^> arrrghhh: were you under distress when creating that nickname? ;P
[17:16] <arrrghhh> potentially, t'was a while ago.  some sort of duress was taking place I'm sure.
[17:22] <^^x^^> :)
[17:27] <funman_> hey folks
[17:27] <funman_> is it easy to upgrade 13.04 to 14.04
[17:29] <arrrghhh> funman_, 13.04 is not LTS so you can't go directly to 14.04
[17:29] <funman_> hmm
[17:29] <funman_> my server provider offers 13.04
[17:29] <arrrghhh> you'd have to do 13.10 --> 14.04.  would be better to just do a clean install of 14.04 and stick to LTS releases
[17:29] <funman_> 14.04 is LTS?
[17:30] <arrrghhh> yes.  every 2 years - 12.04 is LTS, 14.04 is LTS
[17:30] <arrrghhh> so you can go from 12.04 -> 14.04
[17:30] <funman_> i asked them to install 14.04
[17:30] <funman_> lets see :D
[17:30] <arrrghhh> ya clean install would be better
[17:30] <funman_> if they agree
[17:30] <arrrghhh> then upgrade every 6 months or so... or just keep it on LTS releases
[17:30] <arrrghhh> I prefer LTS for my servers.
[17:31] <funman_> lol Take a picture of yourself holding a valid photo ID.
[17:32] <funman_> wtf
[17:32] <funman_> server provider responce
[17:33] <maxb_> It's perfectly valid to upgrade from 13.04 to 13.10 to 14.04. You just have to upgrade twice in succession
[17:33] <arrrghhh> I never said it was invalid... just cannot do it in one step, and a clean install would be preferred.
[17:34] <maxb> I don't think there's any reason to prefer a clean install
[17:34] <maxb> Unless there are other factors entirely separate to upgrading which make a clean install attractive
[17:35] <arrrghhh> ya, upgrades can fail.  clean installs have a better chance of working ;)
[17:35] <funman_> :P
[17:36] <maxb> A somewhat pessimistic viewpoint
[17:36] <arrrghhh> sure, but I can back it up with experience.
[17:36] <arrrghhh> IF a clean install is an option it is ALWAYS preffered IMHO.
[17:37] <arrrghhh> preferred, stupid language
[17:37] <arrrghhh> also, it would be quicker assuming he doesn't have a ton of crap in 13.04 already
[17:38] <lordievader> I'd say a clean install is a last resort. I've done many upgrades, haven't got a failed upgrade recently.
[17:38] <arrrghhh> used to happen all the time.  maybe it's gotten better, I haven't done an upgrade in a  while lol.
[17:39] <maxb> Indeed. There's little point making useless work for yourself, and rebuilding the systems installed on top of the base OS is useless work if you can easily avoid it
[17:39] <arrrghhh> I backup my config files, no big deal.
[17:40] <sarnold> upgrading through a release that has -also- hit EOL can make an upgrade really annoying
[17:40] <sarnold> especially if the mirrors have reclaimed the storage space and you're forced to use old-releases or whatever
[17:40] <maxb> Upgrades very rarely fail. Sometimes they run into issues requiring a little more manual intervention than would be preferred, but that's still usually less work than clean install. This isn't Windows, after all :-)
[17:40] <arrrghhh> well, there's that too ^^ if you're on a really old release
[17:41] <arrrghhh> maxb, and maybe on the server platform that is true.  all of my terrible upgrade experiences have occurred on the desktop platform.
[17:41] <sarnold> funman_: please ask the provider to take down the 13.04 and 13.10 options -- this chart may be useful in convincing them :)  https://wiki.ubuntu.com/Releases
[17:41] <arrrghhh> x1,000 ^^
[17:41] <funman_> lol
[17:41] <maxb> I had a desktop that I upgraded every six months for about four years, with very little problems.
[17:42] <arrrghhh> maxb, it got better after 10.04 I noticed.
[17:42] <arrrghhh> which, was 4 years ago :/  crap I'm getting old
[17:42] <maxb> I started with 6.06 :-)
[17:42] <arrrghhh> 7.04 haha
[17:43] <maxb> Though I do acknowledge other people in my office seem to have more problems than I do.
[17:43] <arrrghhh> ya maybe it was customized crap I was doing.  dunno, my parents machines I haven't had much issue upgrading.
[18:04] <^^x^^> time to work. Hasta luego
[19:21] <^^x^^> crap, when I run apache2ctl as normal user apache says it can't read a particular apache2.conf file but if I run the command as root everything is fine??
[19:21] <sarnold> ^^x^^: check ls -lad for every directory in the path and then the final file; make sure the unix permissions allow the user to read the file and traverse the directories, if that's the goal..
[19:22] <^^x^^> sarnold: yes, it's the goal. I wasn't sure I needed to provide permission across the whole path
[19:22] <^^x^^> but I want to know why apache2ctl gives back different errors when run by user/root ¿?
[19:23] <sarnold> ^^x^^: probably just 'x' directory access is sufficient
[19:23] <^^x^^> will try right now
[19:23] <^^x^^> thanks
[19:23] <^^x^^> have the second answer? ;P
[19:23] <sarnold> probably due to the first answer :) hehe
[19:24] <^^x^^> but i don't get it, apache is run by www-data weather I check stuff with apache2ctl as root or user, right?
[19:25] <sarnold> the change to www-data is after a significant amount of processing, including opening the listening ports (80 and 443 require the CAP_NET_BIND_SERVICE capability, so it starts as root)
[19:27] <^^x^^> uhm, but I have like 10 apache2 processes
[19:27] <^^x^^> 1 as root and the rest is www-data
[19:27] <^^x^^> which one is it?
[19:30] <sarnold> ^^x^^: I -think- the one process is left running as root in case you wish to add another listening socket and reload the configuration -- if it dropped root entirely, some 'simple' changes like that would require a full restart
[19:31] <^^x^^> that makes sense
[19:31] <^^x^^> I still don't understand the apache2ctl thing
[19:32] <sarnold> it runs with whatever privileges you have when you start it
[19:32] <^^x^^> apache2ctl runs with whatever I am at that moment??
[19:32] <sarnold> when you run it as you, it gets only your privileges, which may not allow it to read all the configuration files; but when you run it as root, it can bypass the permissions if needed to read the configuration files
[19:33] <^^x^^> but that's incredibly confusing, because when I run it as a normal user it complains about permission issues but it says "apache2: bla bla" at the beginning
[19:34] <^^x^^> so what that's saying to me is that it is apache2 who has permission issues, not apache2ctl, jesus
[19:34] <^^x^^> right?
[19:35] <sarnold> ^^x^^: probably the 'apache2: ' label is just letting you know which program is complaining.
[19:36] <^^x^^> which stresses my point
[19:36] <^^x^^> :\
[19:37] <^^x^^> http://i.imgur.com/BMfcR4H.png
[19:37] <^^x^^> that's confusing to me
[19:37] <sarnold> ^^x^^: I'm confused what point you're trying to make? :)
[19:37] <^^x^^> let's try with that screencap haha
[19:41] <^^x^^> sarnold: do you not get confused by the "apache2: " there?
[19:41] <^^x^^> it really seems like apache2 is not reading that file. If that's the case, it's the thing apache2ctl should report when run as root
[19:41] <sarnold> ^^x^^: no, it's just a helpful annotation about which program didn't like the input
[19:42] <sarnold> ^^x^^: how could apache2ctl report it when run as root? the permission check is bypassed when you run it as root
[19:42] <^^x^^> sarnold: because if it is apache2 who is having the problem, is going to have it anyways. I'm running apache2ctl as root, not apache2
[19:42] <^^x^^> see what I mean?
[19:43] <^^x^^> apache2ctl is the program I'm always running, I'm not doing anything to/with apache2
[19:43] <sarnold> ^^x^^: but the /etc/init.d/apache init script runs as root and starts apache as root
[19:43] <^^x^^> but I'm not doing anything with that
[19:44] <sarnold> ^^x^^: here, this might help :)  http://sources.debian.net/src/apache2/2.4.10-1/debian/apache2ctl/?hl=47#L47
[19:44] <sarnold> ^^x^^: apache2ctl is a simple little wrapper that runs /usr/sbin/apache2 to do a lot of the actual work
[19:45] <^^x^^> oh crap, I didn't know that
[19:45] <^^x^^> xD
[19:45] <sarnold> :D
[19:46] <^^x^^> so I should run apache2ctl as www-data to really see wtf is wrong? xD
[19:46] <^^x^^> because otherwise there's always user-bias
[19:47] <sarnold> ^^x^^: well, what problem are you trying to solve? :)
[19:47] <^^x^^> i want to find out if apache2 is reading all my *.conf files
[19:48] <^^x^^> check more than "find out"
[19:57] <m_tadeu> does anyone know the difference between "sudo service xxx start" ans "sudo start xxx"?
[20:47] <Guest48535> m_tadeu: service starts older sysv scripts, while starts is for upstart ones, i think
[20:48] <m_tadeu> Guest48535: thanx...I'll look into that
[20:57] <patdk-wk> heh? service starts EVERYTHING :)
[20:58] <patdk-wk> they did create man pages for this purpose :)
[20:58] <patdk-wk> service starts an sysv or upstart script
[20:58] <patdk-wk> start starts a sysv script
[20:59] <rurkowce> i was close enough :V
[20:59] <patdk-wk> by being 50% wrong? sure :)
[21:00] <patdk-wk> I had to switch to service to handle upstart
[21:35] <m_tadeu> patdk-wk: so the way to go is "service start", correct?
[21:35] <patdk-wk> service xxxxx start
[21:35] <m_tadeu> yes
[21:45] <m_tadeu> patdk-wk: thanx a bunch for the enlightnment
[23:38] <mikal> Hi
[23:38] <mikal> Is there a cloud archive for 14.04?