[00:37]  * Mega help
[01:24] <gpdev> Hi guys, can someone please confirm that irc nicks can be registered for this channel?
[02:32] <fnurl> lol @ RoyK
[02:32] <fnurl> no worries, for a second I got excited and thought somebody had answered my issue
[02:33] <fnurl> thin client printing on Pinet/LTSP/Chroot/CUPS
[02:41] <fnurl> lol @ RoyK, np, igot a bit excited thinking someone had answered my issue is all :p
[02:47] <lkthomas> folks, I am trying to reload udev rules without reboot,
[02:48] <lkthomas> udevadm control --reload-rules
[02:48] <lkthomas>  udevadm trigger --attr-match=subsystem=net
[02:48] <lkthomas> after execute, interface name still not changed
[05:58] <lordievader> Good morning.
[06:17] <adun153> Hi! I'm having problems getting a slightly older server to boot an Ubuntu 14.04.3 installer from a flash drive. This is a BIOS system. I am not encountering any problems when I try to boot it from my UEFI-based laptop. Is there an issue regarding the installer that I should know about?
[06:19] <lordievader> How was the live-usb made?
[06:21] <adun153> lordievader: Through Startup Disk creator on my laptop
[06:22] <adun153> that would be usb-creator-gtk or usb-creator-helper
[06:22] <lordievader> adun153: You could try and make a new one with unetbootin, rarely had success with the ubuntu startupdisk creator.
[06:22] <adun153> I see
[06:22] <adun153> yeah, just tried that right now.
[06:23] <adun153> Was about to reboot when I saw your reply
[06:23] <adun153> thanks
[10:10] <gnuoy> jamespage, I've got a ceph packaging question. The radosgw restart bug looks to be http://tracker.ceph.com/issues/11140 . This was fixed in v9 by the looks of it, so I think I need to cherry pick the fix back to 0.80.10 and create a pull request for that. In the mean time fix it via a packaging patch and create an SRU. Does that sound right?
[10:12] <jamespage> gnuoy, if that's only fixed in >= 9 you'll need to target fixes to 14.04, 15.04 and 15.10
[10:12] <gnuoy> ok, thanks
[10:13] <jamespage> gnuoy, this commit - https://github.com/ceph/ceph/commit/059674a686b4c6e5d19d5204dc41ab13d2954d0a ?
[10:13] <gnuoy> jamespage, yes
[10:15] <jamespage> gnuoy, ack - that's the right approach then
[10:16] <gnuoy> ta
[10:31] <rbasak> utlemmin`: I think open-vm-tools needs some attention. Judging from unconfirmed bug reports, it seems that it won't work against Linux 4.1 and a newer upstream is available?
[10:31] <rbasak> utlemmin`: please could you take a look?
[11:24] <jamespage> gnuoy, I'm about todo a point release for wily if you want me to include that patch?
[11:28] <jamespage> gnuoy, doing that anyway - I'll do the same for the vivid sru, if you'd like to prepare the trusty SRU that would be great
[11:30] <jamespage> gnuoy, hmm - which version of the init script do we get in Ubuntu?
[12:11] <gnuoy> jamespage, sorry, was lunching. We get src/init-radosgw in Ubuntu which is the same in 0.80.10 =< release < 9, unles I've misunderstood your question ?
[12:51] <teward> rbasak: i can say with relative certainty that's also a VMware problem as well, they still haven't fixed their tools for even the latest LTS kernel in Trusty, either.  (and I virtualize a lot of things0
[12:52] <teward> rbasak: but yes open-vm-tools probably needs attention anyways
[12:52] <teward> (it's vmhgfs stuff still doesn't work even under Trusty)
[12:53] <gnuoy> jamespage, ok, I think I've done all I can do for Trusty. I've greated a mp against  lp:ubuntu/trusty-proposed/ceph and the bug has the SRU info in it
[12:55] <gnuoy> jamespage, I have a pull request upstream for firefly ( https://github.com/ceph/ceph/pull/5831 ) but given 0.94.1 and 0.94.2 are not names releases I'm guessing there is no point doing one for them too?
[13:09] <jamespage> gnuoy, those are the hammer release
[13:10] <gnuoy> jamespage, so is the plan to pull vivid and wily to 0.94.3 then?
[13:10] <jamespage> gnuoy, yes
[13:11] <gnuoy> ok, I'll cherry pick the fix to hammer, thanks
[13:11] <jamespage> for wily I have the upload prepared but the commit you pointed to - I could not specifically see how that was going to help with the shutdown process?
[13:12] <gnuoy> jamespage, you can see  how it helps for wily or you can't see why it helps at all?
[13:12] <gnuoy> s/you can see/you can't see/
[13:13] <jamespage> gnuoy, whats the default for rgw_exit_timeout_secs
[13:13] <jamespage> ?
[13:13] <gnuoy> jamespage, 120
[13:13] <jamespage> gnuoy, ok - I see now
[13:13] <jamespage> fine - uploading to wily
[13:13] <gnuoy> kk
[13:27] <gnuoy> jamespage, hammer pull request done. Should I be looking for an Ubuntu sponsor for the trusty SRU? Not sure where I stand since you're doing vivid and wily
[13:28] <jamespage> gnuoy, I'll do it
[13:28] <gnuoy> thanks
[13:29] <jamespage> gnuoy, btw is perfectly acceptable to pull the patch directly from github
[13:32] <gnuoy> jamespage, do you mean rather than creating a quilt patch?
[13:34] <jamespage> gnuoy, yeah - I just dump the <commit>.patch content into a file in d/p and then add it to series
[13:34] <jamespage> normally works OK and you get the upstream commit message as well
[13:34] <jamespage> otherwise its tricky to trace the patch heritage without adding headers manually
[13:35] <gnuoy> ah, ok, good to know
[13:36] <RoyK> anyone that knows something like a 'locate' system (slocate/mlocate) that can use a central database?
[13:45] <jamespage> gnuoy, actually can you do that for your proposed trusty update? save me feeding back 'no traceablility' on the MP
[13:48] <gnuoy> ok, will do
[14:19] <gnuoy> jamespage, done
[15:00] <rbasak> smb: have you seen DPDK upstream's replies?
[15:01] <rbasak> smb: looks like upstream have removed CONFIG_RTE_LIBNAME now and it's hardcoded to dpdk
[15:01] <rbasak> smb: but I take it the question about the version is still missing?
[15:01] <rbasak> smb: or is that also now taking the version number from upstream?
[15:03] <jamespage> gnuoy, merged and uploaded you trusty fix - tweaked the changelog entry to match the same I did for vivid
[15:03] <jamespage> (and removed your crufty older patch :-))
[15:04] <jamespage> gnuoy, its stacked ontop of the zap disks fix right now - Ideally we want to push that through first, but your change includes that one so we should be ok
[15:05] <gnuoy> jamespage, ok, thanks for that. I guess quilt delete does not actually remove the patch but just stops applying it
[15:05] <jamespage> gnuoy, yes
[15:26] <jamespage> gnuoy, a good first start at triage - and thanks for emailing the team - helps all involved to learn
[15:58] <coetry> I have a fresh ubuntu server from digital ocean and am trying to install the lamp stack, but i'm running into a weird problem that i haven't before
[15:58] <coetry> Here is some output from my terminal
[15:58] <coetry> http://pastie.org/10403306#36-40
[16:09] <maxb> coetry: Looks like they system has been put in a seriously bizarre state, I'd throw it away, and start from a clean OS install
[16:10] <maxb> And second time around, be more careful about what you change in /etc/apt/, this looks like some unpleasane mixing of incompatible OS versions to me
[16:20] <coetry> ok, thank you
[17:10] <teward> postfix question.  If I have an SSL cert, say, for skyfall.domain.tld, does the 'myhostname' field for postfix have to match the FQDN on the cert?
[17:11] <quantic> teward: i don't know if it HAS to, but it should or some systems may whine about it.
[17:11] <quantic> teward: at least, I believe so. I'm not really a postfix guru.
[17:12] <teward> my assumption is it should so i'mma do that anyways
[17:12] <rbasak> Not knowing this side of Postfix, I imagine that if it works like anything else it'll use whatever certificate you give it to use, and what you really have is a TLS over SMTP question rather than a Postfix question as to whether other MTAs will accept it. It might be worth looking at the relevant RFCs.
[17:25] <teward> i think i've figured it out with postfix's docs
[17:25] <teward> but if I stop getting mail I know that I broke it xD
[17:40] <JanC> you could also just test it  :)
[17:53] <teward> JanC: True, but a notification is primed to go out in... oh, 7 minutes... anyways
[17:53] <teward> so :p
[18:00] <jelly> teward: I'd imagine myhostname was less relevant than PTR and A record of the submission or smtp service listener IP
[18:03] <teward> mmm
[18:12] <edgy> Hi, My web server (ubuntu 14.04 LTS) running as kvm machine frequently stopped working since some days ago. I cannot access the page. I try to ssh or ping but still but not response. However, I managed to login via console and can't see anything wrong
[18:20] <tanuki> edgy: What happens when you run ifconfig?
[18:20] <tanuki> If it works via the console but ssh and ping fail, that screams network failure
[18:20] <edgy> tanuki: I see my interfaces
[18:21] <tanuki> Are the ones that are supposed to be up up?
[18:21] <tanuki> Can you connect out?
[18:22] <edgy> tanuki: Umm! unfortunately, I didn't notice it and rebooted, but next time I would check whether it's UP
[18:22] <edgy> tanuki: good question i will try to ping out next time
[18:23] <edgy> anything else you need me to check?
[18:23] <edgy> tanuki: ^
[18:23] <edgy> and what can be the cause of such things?
[18:25] <tanuki> Not sure. Just running through standard troubleshooting steps.
[18:26] <edgy> tanuki: thanks a lot for your valuable hints, I will check this next time
[19:23] <AEL-H> I am trying to get some sound to play through the speakers attached to the computer running ubuntu server but I am having no luck, can someone please give me some guidance? (I am a linux newbie)
[19:27] <SCHAAP137> AEL-H, install alsa and alsa-tools, add your user account to the audio group, then reboot
[19:27] <SCHAAP137> afterwards use alsamixer to control volume levels
[20:25] <AEL-H> I rebooted my computer, now nothing is coming up on screen and my computer makes a beeping sound on startup
[20:45] <RoyK> AEL-H: what sort of beeping?
[20:45] <RoyK> AEL-H: usually the BIOS has a beep thing if hardware is failing - the sequence is somewhat like morse code - short or long beeps
[20:45] <AEL-H> RoyK: a long beep and then two short beeps -- which I think means there is a problem with the video adapter , but I don't understand how this would arise suddenly
[20:46] <RoyK> it's not linux' fault - it's hardware
[20:46] <AEL-H> Guess I'll open it up tomorrow:) thank you
[20:46] <RoyK> http://www.tomshardware.co.uk/forum/289971-30-ex58-ud3r-long-short-bios-beep-code
[20:47] <RoyK> unplug the video adapter and replug it
[20:47] <RoyK> that might work
[20:47] <AEL-H> I am just not sure why the problem would arise so suddenly? It worked fine until reboot then had a problem
[20:48] <RoyK> well, linux certainly has nothing to do with that
[20:48] <AEL-H> true:)
[20:48] <RoyK> BIOS happens long before Linux loads
[20:49] <RoyK> not sure why BIOS will morse you a D for that, though ;)
[20:50] <AEL-H> haha
[20:50] <RoyK> perhaps a bit easier than morsing --. .-. .- .--. .... .. -.-. ... / -.-. .- .-. -.. / -.. . ..-. . -.-. - .. ...- .
[20:50] <JanC> RoyK: D for Display?  ;)
[20:50] <RoyK> probably ;)
[20:51] <JanC> or maybe "graphics card" starts with a "D" in Chinese
[20:51] <JanC> it's different for many BIOS providers too
[20:52] <RoyK> not likely, even though chieftek has very good Engrish in their products
[20:55] <JanC> Chinese might have its own "morse code"-equivalent too
[20:55] <JanC> or maybe the signals are just chosen randomly
[20:56] <RoyK> .... --
[20:56] <JanC> or whatever the developer who programs a particular part of the BIOS likes
[20:56] <RoyK> that would be a good BIOS message
[20:57] <RoyK> .-- - ..-. ..--..