[00:08] <rcs_com2> LaserJock: I am now using RDP to remote desktop into my windows box from my Ubuntu laptop!  This is really cool.
[00:08] <rcs_com2> Next, I am going to convert to Ubuntu CE and then install Ed packages.
[00:23] <LaserJock> rcs_com2: fun
[00:23] <LaserJock> rcs_com2: are you using Ubuntu CE for the filtering?
[00:36] <rcs_com2> LaserJock: well, that was my intention, but I just realized that the project is temporarily on hold
[00:36] <rcs_com2> In addition, it looks like the last "convert" script was for the previous version of Ubuntu, so I think I have decided to skip that step.
[00:36] <rcs_com2> BTW, what do you use for ICQ in Ubuntu?
[00:43] <LaserJock> well, I don't personally use ICQ
[00:43] <LaserJock> but for general IM I use Pidgin
[00:43] <rcs_com2> If you don't use ICQ, how are you using this forum :)
[00:43] <rcs_com2> isn't it an ICQ forum?
[00:44] <rcs_com2> Pidgin runs on Linux too huh?  I guess I didn't think about that, thats what I use on Windows.
[00:46] <rcs_com2> HA, I was wrong.  I got my I* protocols mixed up. I really meant IRC :)
[00:50] <rcs_comp2> And I am now running pidgin too!  this is really great.
[00:50] <LaserJock> rcs_com2: ah, right now I'm using irssi (*the* terminal IRC client)
[00:50] <LaserJock> but I use xchat when I'm in a GUI mood
[00:50] <LaserJock> Pidgin is a Linux app
[00:51] <LaserJock> it's just portable so people have made Windows versions
[00:51] <rcs_comp2> edubuntu-addon-legacy is installing.  Its a lot of packages so it looks like it is going to take a while
[00:52] <LaserJock> yeah, gcompris is rather large
[00:52] <LaserJock> that's probably the biggest single package
[00:52] <LaserJock> but it's really great
[00:52] <LaserJock> I get hooked on it ;-)
[00:52] <rcs_comp2> what programs do you like best?
[00:52] <LaserJock> I like gcompris for fun
[00:52] <LaserJock> and Kalzium because I'm a chemist
[00:55] <rcs_comp2> What command would I use to examine what programs a certain package provides?
[00:56] <LaserJock> hmm, that's a good question
[00:56] <LaserJock> do you have the package downloaded?
[00:57] <LaserJock> are you looking for a package description or specifc paths to executables?
[00:58] <rcs_comp2> Well, I was wondering what edubuntu-addons-young provides
[00:59] <LaserJock> ok
[00:59] <LaserJock> if you do: apt-cache show edubuntu-addons-young
[00:59] <LaserJock> it will show you the list of dependencies
[01:00] <LaserJock> so it's atomix, gcompris, gpaint, tuxmath, tuxpaint, and tuxtype
[01:01] <rcs_comp2> doesn't dependency mean that the file listed needs to be installed first?
[01:02] <LaserJock> rcs_com2: yes
[01:02] <LaserJock> edubuntu-addons-young is just a "meta" package that pulls in the packages we want
[01:02] <LaserJock> so when we want to collect programs together that's what we do
[01:02] <rcs_comp2> Oh...I was forgetting that apt-get would pull in all dependencies.  It makes sense now.
[01:03] <rcs_comp2> In slackware the concept of a "meta" package doesn't exist because there is no automatic dependency resolution.
[01:03] <LaserJock> yeah
[01:03] <LaserJock> we see it as a "feature" ;-)
[01:03] <rcs_comp2> I think it is :)
[01:04] <LaserJock> all those edubuntu-* packages are metapackages
[01:04] <rcs_comp2> Slackware is great for servers IMO, but not for laptops or desktops.  I have done with Ubuntu on a three year old Dell laptop in a several hours what it would have taken me a few weeks to do in Slackware.
[01:04] <rcs_comp2> is there a way from the output to tell its just a meta package?
[01:05] <rcs_comp2> It even resized my Windows partition automatically so I could dual boot!
[01:05] <LaserJock> hmm,  not really
[01:05] <LaserJock> usually it doesn't really matter if somethings a metapackage or not
[01:06] <rcs_comp2> ok
[01:06] <LaserJock> you just find what you want and install it ;-)
[01:06] <LaserJock> we use metapackages also sometimes when we split a package up into different components
[01:06] <LaserJock> we then have a metapackage that'll install all the bits
[01:06] <rcs_comp2> Ok, that makes sense.Hey, thanks so much for all your help.  Don't hang around on my account if you have anything else to do.  I am just watching a movie with kids and playing with this new system.
[01:07] <rcs_comp2> Not that you have to leave or anything (obviously :)
[01:07] <rcs_comp2> )
[01:07] <LaserJock> heh
[01:07] <LaserJock> I'm just doing some data analysis before heading home
[01:07] <rcs_comp2> does that have to do with being a chemist?
[01:07] <LaserJock> yeah, trying to finish my PhD
[01:07] <rcs_comp2> wow.  Where do you go to school?
[01:08] <LaserJock> University of Nevada, Reno
[01:08] <rcs_comp2> I am pursing an MA in Biblical Counseling from Southern Seminary in Lousville, KY
[01:08] <LaserJock> rcs_com2: awesome!
[01:09] <LaserJock> my wife has a MA in Marriage and Family Therapy
[01:09] <rcs_comp2> LaserJock: I am going to be really!!! glad when I graduate next December (Lord willing).  Its really hard managing work and school and family.  I can't imagine doing a PhD.
[01:10] <LaserJock> yeah, I've been in college for the last 10 years straight
[01:10] <rcs_comp2> What does she do with it?  Does she counsel?
[01:10] <rcs_comp2> wow!
[01:10] <LaserJock> actually she's counseling at our church at the moment until we move
[01:10] <rcs_comp2> are you moving b/c you are finishing the PhD?
[01:10] <LaserJock> yeah
[01:10] <rcs_comp2> where you going?
[01:11] <LaserJock> wherever I can find a job :-)
[01:11] <LaserJock> don't know yet where though
[01:11] <rcs_comp2> I see :)  What will you do with a PhD in chemistry?  teach?
[01:11] <LaserJock> I'd like to
[01:11] <rcs_comp2> collage level?
[01:11] <LaserJock> yep
[01:12] <rcs_comp2> otherwise known as "college" :)
[01:16] <LaserJock> rcs_comp2: you know of Freed Hardman University?
[01:17] <LaserJock> I think it's in Ky or TN
[01:17] <rcs_comp2> nope
[01:18] <LaserJock> I think it's probably TN now that I think of it
[01:18] <LaserJock> anyway, a good friend of mine teaches there now
[01:18] <rcs_comp2> henderson, TN
[01:19] <rcs_comp2> LaserJock: are you interested in any other techie stuff?  Programming, other distros, etc.
[01:19] <LaserJock> sure
[01:19] <LaserJock> I do various things
[01:20] <LaserJock> I'm a Debian Maintainer, it's pretty useful as an Ubuntu developer
[01:20] <LaserJock> I also dabble with Fedora now and then
[01:20] <LaserJock> I work on a couple chemistry apps, C/C++ and Python
[01:21] <rcs_comp2> Do you have a particular area of emphasis with Debian?
[01:21] <LaserJock> chemistry :-)
[01:22] <rcs_comp2> Python huh?  I just decided that I needed to get involved with it.  I am a web developer and was very interested in the Django project.  However, I do a lot of stuff on IIS in windows and there is currently no way to run multiple instances of Django on an IIS server when running Python as an Isapi module, which is the only legitimate way of running it through IIS that I know of.
[01:23] <LaserJock> I've gone through the django tutorial but that's it
[01:25] <LaserJock> I tend to only really work with Linux
[01:26] <LaserJock> I run OS X as well at work
[01:26] <LaserJock> but I only really use Windows at tax time :-)
[01:28] <rcs_comp2> why at tax time?
[01:28] <LaserJock> I like TaxCut and it only works on Windows
[01:28] <rcs_comp2> I see.  No wine either huh?
[01:28] <LaserJock> I don't think so
[01:36] <rcs_comp2> LaserJock: Is the root user in Ubuntu different somehow?  I don't remember setting a password in the install for root, just for my normal user account.
[01:36] <LaserJock> ah, good question :-)
[01:36] <LaserJock> Ubuntu doesn't have a root user
[01:37] <rcs_comp2> nm "As you have noticed during the Ubuntu installation there was no question about the root password, as you might have been used to see during other Linux distribution installation process.Because of this your root accout is inactive."
[01:37] <LaserJock> our "philosophy" on that is that it's better to use sudo rather than create a root account
[01:38] <LaserJock> in terms of security and user-friendlyness
[01:39] <rcs_comp2> I guess I will learn to do that :)
[01:39] <rcs_comp2> Thanks so much for all your help, I am going to head out.
[01:39] <LaserJock> alright, it's about that time for me too
[01:39] <LaserJock> good luck with the Ubuntu box
[01:40] <LaserJock> if you need help feel free to ask
[01:40] <rcs_comp2> may the Lord bless you for you kindness to me this evening by providing a great job for you and your family.  Feel free to look me up later if you want to for some reason.  My business website is http://rcs-comp.com.  Thanks again.  Bye.
[08:47] <crazy_bus> since the edubuntu addon installer works on regular ubuntu.  Can it also work on regular kubuntu.  Or do you also have to download the normal ubuntu install cd
[09:02] <ogra> no, but you need network connection, there are gtk apps on the addon for which kubuntu doesnt bring the required libs
[09:03] <ogra> they will be pulled in from the archive
[09:03] <crazy_bus> ogra: how big of a download are we talking about?  Would it be better to get the ubuntu cd and use that as the archive
[09:04] <ogra> sorry, i neaver actually measured that, but i doubt its much
[09:15] <crazy_bus> so will it load some kind of guide to choose what to install in kubuntu.  Or is that feature meant to use gnome features
[09:40] <ogra> i should just pop up the kde equivalent to gnome-app-install and give you a list


[00:58] <maslen> Hey, I'm a new maintainer for aircrack-ng, and want to try 'baking in' support for as many of the hardening features as possible.  Right now I'm working on squashing some bugs, but I was thinking about making an option for a 'hardened' build in the makefile and an apparmor profile. Are there any guides on best how to do that?
[01:01] <sarnold> maslen: the hardening-includes package includes a hardening-check tool that you could use to see if aircrack-ng is already hardened by the toolchain
[01:01] <sarnold> maslen: for an apparmor profile, you can use dh_apparmor to help install a profile; I think the mysql-5.6 source package includes an example, probably cups does as well
[01:02] <maslen> Is there any standard place to put it?
[01:02] <maslen> (or way to name it?)
[01:03] <sarnold> the apparmor profile should wind up in e.g. /etc/apparmor.d/usr.bin.aircrack-ng if you're confident that it will work for most users
[01:03] <maslen> got it. I wasn't sure if there was some other way to do it, that would take advantage of a custom installpath
[01:04] <maslen> just creating a directory called 'apparmor' should be sufficient?
[01:09] <sarnold> sorry, I've never added dh_apparmor to a package myself, I'm not sure what the details are
[01:23] <cjwatson> barry: Is it a bug that "from lazr.delegates import Passthrough" stopped working as of the Python 3 port you did, even under Python 2?  lazr.restful was using that, but apparently now has to use "from lazr.delegates._passthrough import Passthrough" (which seems wrong) or port to something else.  I'm wondering if it would make more sense to export that directly from lazr.delegates again.
[01:24] <cjwatson> barry: Noticed when finding that "pip install lazr.restful" (don't ask why, I'm multiple levels deep in yak-shaving) gives me a thing I can't import.
[01:25] <cjwatson> barry: Or is this internal machinery that lazr.restful has no business meddling in?
[01:40] <barry> cjwatson: gosh, i haven't looked at that in a long while.  looking at the usage.rst, i'm not sure that l.d.Passthrough was ever considered a public api, though i guess if lazr.restful was using it, that was maybe just an omission.  if it was a byproduct of the py3 port, i suppose we should say it's a bug
[01:42] <barry> cjwatson: ah
[01:42] <cjwatson> I don't really understand this layer well enough to have a strong opinion on which direction the fix should go in, I just know it's busted :)
[01:42] <cjwatson> (somewhere)
[01:42] <barry> cjwatson: so i think this was a byproduct of lazr.delegates._passthrough.Passthrough being imported by lazr/delegates/delegates.py and l/d/__init__.py doing a `from lazr.delegates._delegates import *`
[01:42] <barry> which did get lost in the py3 port
[01:43] <barry> so it probably worked accidentally
[01:43] <cjwatson> Yes.
[01:43] <barry> probably best to just explicitly import it in the __init__.py
[01:43] <cjwatson> That was my thought, if you think it's reasonable to effectively make it quasi-public again.
[01:44] <barry> i guess if l.restful uses it, we should restore its undocumented queasy, er, quasi nature.  can you file a bug?  i can probably turn this around and release + upload a new version tomorrow
[01:45] <barry> cjwatson: okay if it's just to unstable/wily? or do we need an sru to some earlier release?
[01:46] <infinity> barry: How far back was it broken like this?
[01:46] <cjwatson> barry: https://bugs.launchpad.net/lazr.delegates/+bug/1472456
[01:46]  * barry looks
[01:47] <infinity> If a public interface is going to disappear and reappear, I'd rather it reappear everywhere we support.
[01:47] <cjwatson> barry: I hadn't even looked at the packaged version, I was just going from pip
[01:47] <cjwatson> barry: lazr.restful isn't packaged so my care factor is limited in that regard
[01:47] <cjwatson> oh wait, it is
[01:48] <infinity> Of course it is.
[01:48] <cjwatson> So I don't personally care because LP deploys it in other ways, but the package is probably broken
[01:48] <infinity> And installed on many, many machines.
[01:48] <cjwatson> infinity: That's lazr.restfulclient.
[01:48] <cjwatson> lazr.restful is the server sied.
[01:48] <infinity> Oh.
[01:48] <cjwatson> *side
[01:48] <infinity> dpkg -l handily cut it off at just the right point to make me look silly. ;)
[01:48] <cjwatson> I'm rather surprised it's packaged, and probably nothing uses it, but ...
[01:48] <barry> probably broke in upstream version 2.0 (2013-01-10) which introduced the py3 port.  and the first debian version is 2.0.1 so it's probably been broken in debian/ubuntu forever
[01:48] <cjwatson> Indeed.
[01:49] <infinity> barry: Oh, if it was always "broken" in Debian/Ubuntu, then there's no regression.  You win!
[01:49] <barry> \o/
[01:49] <cjwatson> Well, just Ubuntu.  lazr.restful isn't in Debian at all.
[01:49] <barry> tbh, i don't really care about much of the lazr stuff, except lazr.smtptest
[01:49] <barry> oh, and lazr.config
[01:50] <infinity> Err, I'm super confused.
[01:50] <infinity> Is lazr.restful in the archive not the same thing?
[01:51] <infinity> Cause those versions don't align at all with what you said. :P
[01:51] <barry> infinity: above was for lazr.delegates
[01:51] <barry> lazr.restful is just a client of that
[01:51] <infinity> Oh.
[01:51] <infinity> I'm not awake enough to do things like read.
[01:51] <barry> where's sinzui when you need him?
[01:52] <infinity> barry: Though, you're still wrong about the "first Ubuntu version", then.
[01:52] <infinity>  lazr.delegates | 1.1.0-0ubuntu2 | precise/universe | source
[01:52] <infinity>  lazr.delegates | 1.2.0-0ubuntu3 | trusty/universe  | source
[01:52] <infinity>  lazr.delegates | 2.0.1-1        | utopic/universe  | source
[01:52] <infinity> Which implies this would have regressed in >= utopic.
[01:52] <barry> oh hahaha.  i was looking at the svn repo for the debian package
[01:53] <barry> infinity: do people still use utopic? <wink>
[01:53] <infinity> And given that restful is packages all the way back to precise, I assume it regressed in >= U.
[01:53] <infinity> Of course, if no one's noticed, that's also telling.
[01:53] <barry> indeed
[01:54] <barry> i think cjwatson is the only one using it
[01:54] <infinity> barry: Dunno, but U and V ship the same version, so SRU to U and I'll copy-with-binaries to V.
[01:54] <barry> should be easy enough
[01:55] <barry> anyway, eod
[04:26] <pitti> Good morning
[04:26] <pitti> teward: here now
[04:27] <pitti> slangasek: yes, I think we can handle that much more easily with the new code, now that I understand it
[04:27] <pitti> slangasek: right now we indeed require that all tests succeed in unstable (in britney terms, i. e. in -proposed)
[04:28] <pitti> slangasek: we would mostly need to set up a VM with apt pinning so that when it runs the multipath-tools induced tests with the non-proposed lava-dispatcher
[04:28] <pitti> and specify that "version constraint" in the AMQP request and re-run the test after it regressed in proposed
[04:29] <pitti> slangasek: still a lot of work, but at least possible
[05:45] <infinity> rbasak: Around yet?
[05:46] <infinity> pitti: Running test for both testing and unstable would complicate britney a fair bit.
[05:46] <infinity> pitti: Since, yes, if we're migrating only A, we don't care if B in unstable is failing, but if we're migrating both, we sure do.
[05:46] <pitti> right
[05:46] <infinity> pitti: And our test against tests comes before we know what will and won't migrate together.
[05:47] <pitti> infinity: it helps that we don't just "run test foo-1", we track that we test foo-1 *for* bar-2
[05:48] <infinity> pitti: Perhaps that's the solution (and has other nice side effects), which is that we should be testing autopkgtest state between the installibility/hint phase and the final SUCCESS/copy.
[05:48] <pitti> infinity: so if bar-2 is failing, but bar-1 succeeds, we cuold still promote foo-2 if that succeeds against bar-1, but we'd hold back bar-2
[05:48] <infinity> pitti: That has the nice side effect that a busted test wouldn't hide progress of a transition or a large block hint, like it does today.
[05:48] <pitti> infinity: oh, I thought it would already run that after the installable test
[05:49] <pitti> at least we don't even trigger tests any more if the package isn't even installable
[05:49] <infinity> pitti: autopkgtest happens in the update_exuses stage, which is before all the cool stuff in update_output happens.
[05:49] <pitti> ah, this one
[05:49] <infinity> pitti: There are two installable checks. :P
[05:49] <infinity> pitti: One for individual packages, one for migrated state.
[05:50] <infinity> pitti: So, *triggering* the tests when we do is right and shouldn't change, but *checking* state should probably actually happen very last, right before we'd pass/fail on promoting.
[05:50] <pitti> so we wouldn't even start running tests until a transition is completed
[05:50] <pitti> and only then learn about regressions -- not exactly ideal either
[05:50] <pitti> ah, I see
[05:50] <infinity> pitti: Nah, re-read.
[05:50] <infinity> Yeah. :)
[05:51] <infinity> We can still have the output on excuses for nice vivisibility and parsing, but not actually act on it there.
[05:51] <infinity> We'd act when we're about to commit a complete run, so we can see what's moving together, and use the right tuples.
[05:52] <infinity> foo_1 against bar_4, etc.
[05:52] <infinity> But this does mean running every test twice. :/
[05:52] <infinity> And a lot of failures on the "test against testing" test, when a transition is in play.
[05:52] <infinity> No ideal.
[05:52] <pitti> against testing? that's the bit I didn't get
[05:53] <pitti> I thought we'd continue to run everything against unstable
[05:53] <pitti> we'd re-trigger reverse depends as usual if you upload another piece of a transition
[05:53] <infinity> pitti: Well, no, we'd want to test everything twice, right?
[05:53] <pitti> do we?
[05:54] <infinity> pitti: Okay, well, look at Steve's complaint.  foo_2 and bar_2 both get uploaded.  bar_2 doesn't work right, but foo_2 works fine in the context of testing.
[05:54] <infinity> pitti: We can only know that if both are tested in isolation against testing, and then testing against full unstable.
[05:54] <infinity> s/testing/tested/
[05:54] <pitti> ah, for that
[05:54] <infinity> Err, where that belongs.
[05:55] <pitti> so that's unrelated to moving the evaluation of results until after the second install check stage
[05:55] <infinity> So, yeah.  It explodes the test matrix a bit, and makes britney's promotion decision a bit harder.
[05:55] <pitti> and it might cause a lot of failed tests due to uninstallablility if you can't install teh new source's binaries in isolation, but that'd be okay
[05:55] <infinity> pitti: Well, they relate because once we have both sets of results, the only place we can reliably use them is in the last britney stage.
[05:55] <infinity> pitti: Since I don't know which result I care about until I'm there.
[05:56] <infinity> ie: if I intend to promote one package, I care how it works with testing, while if I intend to promote 3 packages, I care how they work with each other.
[05:56] <infinity> (if they interdepend)
[06:00] <infinity> pitti: It makes the bold assumption that if an rdep failure is isolated to unstable, it's the rdep's fault, not the new dep.
[06:00] <infinity> pitti: Which is probably 99% true, but not always.
[06:00] <infinity> pitti: I dunno.  I think it's something we could do better, but I think human intervention is sort of working for now, and this sound painful to do perfectly.
[06:01] <pitti> well, in some cases it's part of a transition, and then it's fine to keep it in unstable
[06:01] <pitti> infinity: I read a lot of the current britney code recently; mostly the bits that directly interact with autopkgtest, I'm not yet familiar with the installability checks
[06:02] <pitti> infinity: anyway, I think I'll be more happy to think about this once we finish simplifying the autopkgtest stuff and moving it to the cloud
[06:02] <infinity> pitti: The installability checks are, actually, pretty simple, by necessity, since they're super duper quadratic and can't be complex. :P
[06:03] <infinity> pitti: Basically, attempt to promote source package, check if there are more or fewer uninstallable packages in testing as a result, if fewer win, if more, fail.  And then the autohinter that tries to match up things with deps on each other to batch attempt, and same check.
[06:03]  * pitti currently looks at a first excuses.html that contains both the old and the cloud test results, after a day of running 500 autopkgtests; looks fairly ok
[06:03] <pitti> I'm surprised that the machinery survived these 500 tests without much hiccup :)
[06:03]  * pitti pats scalingstack
[06:04] <infinity> Which region?
[06:05] <pitti> RegionOne
[06:05] <pitti> (lcy01)
[06:05] <pitti> I haven't tried lgw01 yet (uh, this is also called "RegionOne")
[06:09] <pitti> infinity: how do you usually handle britney merges? https://code.launchpad.net/~pitti/britney/britney2-ubuntu-amqp/+merge/264047 is a followup of the first amqp MP (Steve reviewed/merged that)
[06:10] <pitti> infinity: i. e. is it generally okay to push such followup merges myself, or better to do a four-eyes principle?
[06:10] <infinity> pitti: To be fair, until very recently, we've never really had merges to handle, so I dunno how we handle them. :P
[06:10] <infinity> pitti: Colin and I sort of just committed directly for most of our stuff.
[06:10] <pitti> oh? there were a fair bunch for the original adt-britney ones, then boottest, etc.
[06:11] <infinity> pitti: If you're willing to babysit the logs and make sure your stuff is happy, direct committing is fine.  If you're relying on the infra to fail gracefully and planning to commit and run, then please no.  And if you just want a review because you think it's a good idea (or because the change is largeish), a review would be good.
[06:11] <infinity> pitti: Yeah, true, there were for adt and boottest, Colin did all of those, and I assume it was all reviewed and merged by him, since the other parties wouldn't have had commit.
[06:12] <pitti> infinity: nah, I have a checkout of my branch on snakefruit to run britney there (partial copy of data/), no hit'n'run :)
[06:12] <pitti> infinity: so, my gut feeling is that the initial MP was good for four-eyes, I shoudl push these followup fixes directly, and do an MP again for the "get results from swift" bits
[06:12] <infinity> pitti: Sure.  I have no issues with direct commits if they come with commitment.
[06:13] <pitti> right now it's all a practical no-op as AMQP isn't yet enabled in the production checkout
[06:13] <pitti> infinity: of course; okay, thanks
[06:13] <infinity> pitti: Worst case scenario, you notice it explodes and you revert.  *shrug*
[06:13] <pitti> right
[06:13] <infinity> pitti: Thankfully, I've never met a britney failure mode where it screws everything up and then decides to promote everything.
[06:13] <pitti> infinity: or it promotes everythign in -proposed :)
[06:13] <pitti> hah
[06:13] <infinity> Oh, except when we open a new series and intentionally disable adt for a few days. :P
[06:13] <infinity> Hopefully with your new setup, we can fix that lag.
[06:14] <pitti> we now have an infinitely large cloud to do that!
[06:14] <pitti> *cough*
[06:14] <infinity> pitti: It's not the workers that were the lag, it was the setting up all the jenkins jobs, etc.
[06:14]  * pitti defines 10 == ∞
[06:14] <pitti> infinity: oh dear, I want that stuff to die
[06:14] <infinity> pitti: Hoping the new setup makes it more of an "add new release to a config file and watch it function" thing.
[06:15] <pitti> infinity: well, it's still some manual work as we don't have cloud images from day 1
[06:15] <infinity> Well, and "hack in temp cloud image".
[06:15] <pitti> right
[06:15] <pitti> but that's pretty much it
[06:15] <infinity> Sure, but a vivid cloud image with fixed sources.list is a wily cloud image. :)
[06:15] <infinity> (same story for buildd chroots)
[06:15] <infinity> Actually, buildd chroots are even easier, since lp-buildd writes sources.list at runtime, so it can literally be the same tarball.
[06:16] <pitti> yeah, except that this should get dist-upgraded every day to not explode the dist-upgrade/reboot time, but details
[06:16] <pitti> infinity: right, and I could provide that with a --setup-commands
[06:16] <infinity> pitti: Sure, sure.  Lots of maintenance and tweaking, my point is just series opening lag time.
[06:16] <infinity> If it's "fix a conffile and copy some cloud images", that's cake.
[06:16] <infinity> And yay.
[06:17] <pitti> so adding a 'change release in apt sources" setup command script would make this literally an "add new config file" process
[06:17] <pitti> (more and more inefficient over time, but working)
[06:17] <pitti> but that'll be the time when I'll sit down to create a new daily job to provide a current image :)
[06:17] <infinity> :)
[06:18] <infinity> Yeah, I'm waiting for *stack on all 6 arches, so I can move my chroot tarballs to some sort of cloud buildy thingee.
[06:18] <infinity> Y'know, I guess I could build them as livefses.
[06:18] <infinity> Hrm.  Why have I not been doing that?
[06:18] <infinity> Something to do later this week, I think.
[06:44] <dholbach> good morning
[06:45] <opiwahn> where would I have to place an initram-script if I want to have it executed as early as possible: http://snag.gy/KCkcM.jpg
[06:55] <pitti> opiwahn: init-top/asomething
[07:06] <opiwahn> pitti: thank you pitti . I will try it
[07:07] <opiwahn> pitti: and script inside there is executed before touching any harddisks?
[07:07] <pitti> opiwahn: yes
[07:08] <pitti> opiwahn: see "Subdirectories" in man initramfs-tools(8)
[07:09] <opiwahn> pitti: thank you very much :-)
[07:40] <jamespage> if there are any archive admins with a few spare minutes I'd appreciate a review of networking-odl in the wily NEW queue - thankyou!
[07:44] <infinity> jamespage: Is that a thing that has intent to also exist in Debian?
[07:45] <jamespage> infinity, yeah - the repo is created, but its not been testing in Debian yet
[07:45] <jamespage> infinity, I also have a python-os-brick in the queue - also in the NEW queue for experimental
[07:45] <jamespage> I just need to unblock our liberty milestone1 testing in wily
[07:45] <jamespage> as Debian is not targetting liberty just yet, we're leading on some of this stuff (doing more through experimental tho)
[07:45] <infinity> jamespage: Check.  The followup question would be if the maintainer in Debian is you, or if you're working with the planned maintainer to make sure the packaging is the same.
[07:46] <jamespage> infinity, it will be done under the pkg-openstack team - might be me...
[07:47] <infinity> jamespage: With a second followup of "wtf, no python3?" ... I thought all new openstack stuff was dual-stack.
[07:47] <jamespage> infinity, not core projects just yet - working towards that
[07:47] <jamespage> networking-odl is a split out vendor driver from neutron
[07:47] <jamespage> python-os-brick does have py3 support tho - I had to fix that up (submitted upstream)
[07:48] <opiwahn> pitti: about the init-script: do I have to write my script to this file "ORDER" ? http://pastebin.com/4pbZ4nGu
[07:49] <pitti> opiwahn: I've never heard about ORDER, shouldn't be necessary; might be something that initramfs-tools builds/uses internally
[07:50] <pitti> adding the script and "sudo update-initramfs -u" shoudl suffice
[07:50] <opiwahn> ok.. so I just put a (shell) script to folder init-top and update-initramfs -lk all should work?
[07:51] <opiwahn> pitti: my issue is that the script does not appear in the live-system.. when searching in /usr/share/initramfs-tools/scripts/   all the scripts are in there.. except mine
[07:51] <pitti> opiwahn: not sure what -l is (that doesn't exist), I suppose you want -u
[07:51] <jamespage> infinity, thankyou!
[07:52] <pitti> opiwahn: err, live system?
[07:52] <opiwahn> pitti: i use -k all
[07:52] <opiwahn> yes.. I am doing a remastering... and I want to add an early script to initrd.lz
[07:53] <pitti> opiwahn: ah, that might be where this ORDER things comes from? (no idea about remastering, sorry)
[07:53] <highvoltage> #Â# Â-#Â-/win 24
[07:54] <infinity> pitti: The ORDER files are generated by update-initramfs.
[07:54] <infinity> But yeah, if one was hacking the initrd manually instead of generating it properly, you'd need to hack those bits too.
[07:55] <opiwahn> this is how I generate it in my remaster-script: http://pastebin.com/LiNmSJJU
[07:55] <opiwahn> before that I unpack initrd.lz... put my script in there.. repack it..
[07:55] <infinity> opiwahn: Unpacking and repacking it isn't sane.
[07:56] <opiwahn> I used these lines to pack/unpack: http://pastebin.com/0cCsewNb
[07:56] <opiwahn> isnt that ok?
[07:56] <infinity> opiwahn: You want to put your script in /usr/share/initramfs-tools/scripts/init-top/ and the update-initramfs -u and use the result.
[07:57] <opiwahn> infinity: so you mean just putting while remastering the file in there, executing update-initramfs .... without modifying any initrd.lz ??
[07:57] <infinity> opiwahn: Use the tools available, instead of trying to hack around them. :)
[07:58] <opiwahn> so I can execute an init-script without hacking the initrd.lz ??
[07:59] <infinity> opiwahn: Your goal is to add a script to the initrd in init-top, yes?  So, put it in your chroot at chroot/usr/share/initamfs-tools/scripts/init-top/ and then "chroot chroot/ update-initramfs -u -k$(version)" and copy the result from chroot/boot/initrd-$(uname)
[08:00] <infinity> opiwahn: You *can* unpack and repack the initrd, but that means you need to know how initramfs-tools builds it, which is not knowledge worth having, really. :P
[08:01] <opiwahn> infinity: I really WANT to do the simple way :-)
[08:01] <infinity> opiwahn: Yes, the simple way is also the right way.
[08:01] <infinity> opiwahn: Two lines.  Copy your file, run update-initramfs.
[08:01] <infinity> No unpack, repack, understanding inner workings, etc.
[08:01] <opiwahn> infinity: is this "double chroot" right?   chroot chroot/ update-initramfs -u -k$(version)
[08:01] <pitti> all that in the chroot of the live image, I figure
[08:03] <infinity> opiwahn: Well, "chroot/" was the directory.  In your case "chroot ${WORK}/new/ update-initramfs -u -k 3.19.0-15-generic"
[08:03] <infinity> opiwahn: THe trick is that BEFORE that, you do "cp myscript ${WORK}/new/usr/share/initramfs-tools/scripts/init-top/"
[08:03] <infinity> And just those two lines (plus copying out the finished initrd) should get you what you want.
[08:04] <opiwahn> doing it at the moment and looking forward :-)
[08:04] <infinity> I'm assuming here that ${WORK}/new/ has you live filesystem in it. :P
[08:04] <infinity> s/you/your/
[08:05] <infinity> Hopefully writable.
[08:05] <opiwahn> the variable -k$(version) works on any kernel then ??
[08:06] <infinity> Err, no.
[08:06] <infinity> That was shorthand for "-k the-kernel-version-you-use"
[08:06] <opiwahn> ah ok
[08:06] <infinity> 3.19.0-15-generic", for instance.
[08:07] <opiwahn> good that I asked :-)
[08:07] <infinity> The kernel version on the livecd and installed in the chroot, of course.
[08:07] <infinity> Not the one you're running on your build system. ;)
[08:08] <mardy> pitti, pete-woods: I'm trying to use libqtdbus{test,mock} in my tests (successfully), but they fail when they are run as part of dpkg-buildpackage; do you know any tricks to run dbus-daemon as part of the package building process?
[08:08] <pitti> mardy: it's always better if your test starts/uses its own private dbus server
[08:08] <opiwahn> infinity: the remastering runs.. I tell about the result ;-)
[08:08] <pitti> mardy: you should never muck around with the "real" session or system bus
[08:08] <pete-woods> mardy: you shouldn't have to change anything. I've used libqtdbustest in all my packaging
[08:09] <pete-woods> pitti: libqtdbustest does exactly that (I wrote it)
[08:09] <pitti> mardy: and yes, you can use dbus-launch, but really, don't
[08:09] <pitti> pete-woods: ah, ok
[08:09] <pete-woods> pitti: and libqtdbusmock uses your dbusmock internally
[08:09] <mardy> pete-woods: wait, I'll post the output
[08:09] <pitti>  dbusmock also has a convenience API to start a "private" session bus (or system)
[08:09] <pitti> but that only works in python
[08:10] <pitti> for C/C++ you have to start the bus yourself, which I suppose is what pete-woods does in libqtdbusmock
[08:10] <infinity> It's never the starting that's a problem anyway, it's the 30 times people have reinvented the stopping wheel and failed.
[08:10] <pete-woods> mardy: I've likely point the finger at paths / resources are different on your dpkg build that in your local source build
[08:10] <pitti> infinity: ?
[08:10] <pitti> infinity: dbus-launch --exit-with-session ?
[08:10] <mardy> pete-woods: http://paste.ubuntu.com/11840275/
[08:10] <infinity> pitti: Oh, just whining about all the people who fail to stop processes they start in testsuites. :P
[08:10] <mardy> pete-woods: I tried both with and without xvfb, same errors
[08:11] <pitti> that does look like you have a bus, it's just your service doesn't seem to attach to it
[08:11] <pete-woods> infinity: if it makes you feel better, the test processes are managed by libqtdbustest and terminated when your test binary exits :)
[08:12] <pete-woods> even if you segfault
[08:12] <infinity> pete-woods: It makes me feel warm and fuzzy.
[08:12] <mardy> pete-woods: when I run the tests from the terminal, they work
[08:12] <infinity> So very fuzzy.
[08:12] <mardy> pete-woods: I even unset the DBUS_SESSION_ADDRESS variable, and they still run (on the console)
[08:12] <pete-woods> mardy: as they should
[08:13] <mardy> pete-woods, pitti: does dpkg-buildpackage run the tests in a chroot? maybe some directory (/var/lib/dbus/) is not available there?
[08:13] <infinity> mardy: dpkg-buildpackage doesn't, no.  Unless you're invoking it via something like sbuild.
[08:13] <mardy> (I found this, that's why I ask: https://bugzilla.redhat.com/show_bug.cgi?id=460574 )
[08:13] <pitti> mardy: no, it doesn't; you have to provide that yourself with sbuild/pbuilder/etc/
[08:13] <mardy> ok
[08:13] <pitti> mardy: err, /var/lib/dbus? that's the session bus
[08:14] <pitti> mardy: you aren't allowed to attach to that as user
[08:14] <pitti> mardy: I mean, that's teh *system* bus
[08:14] <infinity> mardy: dpkg-buildpackage does the following: "fakeroot debian/rules clean && debian/rules build && fakeroot debian/rules binary"
[08:14] <infinity> mardy: No magic.
[08:14] <mardy> pitti: ok, nevermind that then :-)
[08:14] <pitti> mardy: do you test a system or session service?
[08:14] <mardy> pitti: session
[08:14] <pete-woods> pitti: FYI, libqtdbus test starts a private system and session bus
[08:14] <pete-woods> and sets all the relevant environment variables
[08:15] <mardy> infinity: thanks; is there a command to run the tests only? that might be easier to debug
[08:15] <mardy> infinity: maybe "debian/rules test" or something like that?
[08:15] <infinity> mardy: Depends on how you're invoking them, I didn't write your debian/rules.
[08:15] <pete-woods> mardy: I would suggest adding some debugging to your test code, and perhaps paring it right back
[08:15] <pitti> mardy: I suggest you build it once, and then just do "make check"
[08:15] <pete-woods> so just start one test, that prints the bus address
[08:16] <pete-woods> something like that
[08:16] <pitti> mardy: or whatever your debian/rules does to run the tests
[08:16] <pete-woods> just to check it's not all gone crazy
[08:16] <mardy> infinity: %: dh $@ --with python3
[08:16] <pitti> mardy: then call fakeroot dh_auto_test
[08:16] <pete-woods> as I'm pretty confident about the libs - as mentioned before they are used in a number of projects for testing
[08:16]  * mardy tries
[08:17] <infinity> mardy: Without the fakeroot.
[08:18] <infinity> pitti: auto_test is part of the build sequence, not the binary sequence.
[08:18] <mardy> pitti, infinity: so, if I just run dh_auto_test, it works; if I run "fakeroot dh_auto_test", it fails with the same errors
[08:18] <pitti> jamespage, smoser: do you know how  cloud-init's userdata could set up apt sources, with referring to "apt_mirror:"? http://cloudinit.readthedocs.org/en/latest/topics/examples.html#add-apt-repositories doesn't really say
[08:19] <infinity> mardy: It shouldn't be run with fakeroot, generally.
[08:19] <pitti> I need to enable multiverse in the instance, but I don't see what's the preferred way of doing this other than hardcoding the mirror
[08:19] <infinity> mardy: Do you have a full build log instead of the short failure snippet?
[08:19] <pitti> mardy: so I suppose you are trying to talk to the real session bus
[08:19] <pitti> mardy: does it also fail with env -u DBUS_SESSION_BUS_ADDRESS dh_auto_test ?
[08:23] <mardy> pitti: with "env -u DBUS_SESSION_BUS_ADDRESS dh_auto_test" it works
[08:24] <pitti> ok, so I suppose there's a fakeroot *somewhere*?
[08:25] <infinity> mardy: At this point, I'm thinking the full source might be more helpful than people guessing.
[08:25] <mardy> infinity, pitti: the full build logs: http://paste.ubuntu.com/11840315/
[08:26] <mardy> pete-woods: I also added a line to print the session address, I cannot see anything wrong in it ^
[08:26] <mardy> infinity: let me push the latest commits...
[08:27] <infinity> Err, WTF?
[08:27] <infinity> Why is the whole build happening in the binary sequence?
[08:27] <infinity> mardy: Do you have a "build" rule in your rules file or something?
[08:28] <infinity> mardy: Seeing the source would be very helpful here. :P
[08:28] <infinity>  debian/rules build
[08:28] <infinity> make: 'build' is up to date.
[08:28] <infinity> That's why it's going downhill.
[08:28] <opiwahn> inifity: did not work, but I think I did not understand it right.. it now just copied my script to "scripts" in the chroot and did update-initramfs.... but thats not all, right?
[08:28] <mardy> infinity: lp:~mardy/online-accounts-api/service
[08:28] <infinity> opiwahn: And then copy out the new initrd from /boot in the chroot to wherever it should live on your remaster...
[08:29] <mardy> infinity: ah! I created a local directory called "build", could that confuse make?
[08:29]  * mardy tries removing that...
[08:29] <infinity> mardy: It could indeed. :P
[08:30] <infinity> mardy: If you need that directory, you could .PHONY build.
[08:30] <opiwahn> infinity: can I also copy initrd from the running live-system?
[08:30] <infinity> opiwahn: ...?
[08:30] <infinity> opiwahn: Once it's running seems a bit late, since you need it to boot.
[08:30] <opiwahn> infinity.. ahm ok.. I try it.. sorry for not-so-good-skills
[08:31] <opiwahn> infinity: so this line has to be added, right?
[08:31] <opiwahn> infinity: sudo mv ${WORK}/new/initrd.lz ${WORK}/ubuntu-livecd/casper/
[08:32] <mardy> infinity, pitti, pete-woods: so, indeed, having a directory called "build" in the source tree breaks everything :-) Now the tests run just fine :-)
[08:32] <infinity> opiwahn: I'm going to assume it's ${WORK}/new/boot/initrd-$(version) or something, but yes.
[08:32] <infinity> opiwahn: Look for it after you do the update-initramfs and see what it is.
[08:32] <mardy> infinity: thanks for spotting the issue! :-)
[08:32] <infinity> mardy: NP.
[08:33] <infinity> mardy: Welcome to make? :)
[08:33] <opiwahn> infinity: it isnt just called initrd.lz ?
[08:34] <infinity> opiwahn: No, update-initramfs generates it as /boot/initrd-$(uname -r) (look at /boot/ on your running system, if you use Ubuntu).
[08:34] <infinity> initrd.img-$(uname -r) even.
[08:35] <infinity> opiwahn: When we master CDs, we copy that out to "initrd.lz" on the ISO, so our CD bootloader can be stupid and not know about versions.
[08:36] <infinity> rbasak: Wake up.  I'm tired and want to yell at you about docker before I go to bed.
[08:41] <pete-woods> mardy: that's good to know :)
[08:45] <opiwahn> infinity: thank you infinity for so great background information.. would like to let u know that I am very very thankful
[08:53] <opiwahn> infinity: I located the initrd.img-3.19.0-15-generic in chroot/boot :-)        and I am doing WHAT with it?? :-)
[08:54] <opiwahn> infinity: because I will need initrd.lz not initrd.img-3.19.0-15-generic ?
[08:59] <opiwahn> I have build a initrd.img-$(version) in the chroot of my remastering process. where do I have to put this file so that it "overrides" initrd.lz from original ubuntu-cd ?
[08:59] <infinity> opiwahn: Yeah, just copy it to foo/bar/initrd.lz (where foo/bar is the path the original initrd.lz is in on the ISO layout).
[08:59] <infinity> ie: copy it over the thing you were previously unpacking and repackging.
[09:00] <ekarlso> Hi, is there a reason for network-manager-strongswan not supporting PSK
[09:00] <ekarlso> as in https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1457078
[09:00] <opiwahn> infinity: so e.g. to "casper" folder where I find the original initrd.lz ?  should I delete initrd.lz or is this system-immanent?
[09:01] <infinity> opiwahn: Copy it over initrd.lz
[09:01] <opiwahn> infinity: do you mean renaming and overriding initrd.lz, no?
[09:01] <infinity> opiwahn: As in "cp path/to/boot/initrd.img-3.19.0-15-generic path/to/casper/initrd.lz"
[09:02] <opiwahn> infinity: yes.. you meant that
[09:06] <infinity> rbasak: On second though, I'll sleep.  Please fix the golang-pty thing I rejected, and we'll talk docker itself when I wake up.
[09:07] <opiwahn> infinity: before you go to bed.. let me thank you again for such great help, patience..
[09:07] <rbasak> infinity: o/
[09:07] <rbasak> infinity: OK, looking
[09:08]  * rbasak looks at 47 new emails!
[09:08] <infinity> rbasak: Oh, sure, now you show up.
[09:09] <rbasak> :)
[09:09] <infinity> rbasak: Have 5 minutes for a quick mumble... In 5 minutes?
[09:09] <rbasak> infinity: sure
[09:09] <infinity> rbasak: Should be able to clear this all up and be happy by morning.
[09:09] <infinity> rbasak: Alright.  I'm going to grab the nightcap I was planning on putting myself to sleep with, then you can sing me a lullabye on mumble.
[09:11] <ekarlso> noone that knows why https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1457078 < isn't fixed ?
[09:11] <ekarlso> I can't use my VPN at all atm
[09:14]  * rbasak mumbles
[09:15] <rbasak> infinity: https://git.launchpad.net/~ubuntu-server/+git/docker-backport-tools/tree/all
[09:22] <ekarlso> noone in this chan that knows the nm stuff ?
[10:19] <pitti> rbasak: could I hand the apache2 merge back to you?
[10:34] <rbasak> pitti: I actually did it already. It's stuck in proposed.
[10:35] <rbasak> (I'll sort that out when I get a chance)
[10:35] <pitti> rbasak: ah great; I had a faint recall that we talked about this before
[10:35] <pitti>    * amd64: ltsp-cluster-control
[10:35] <rbasak> Yeah it's Ubuntu only and just needs its dependencies fixing
[10:36] <pitti> rbasak: ah, does the new version finally drop the apache2-mpm-* transitionals?
[10:36] <rbasak> Yes
[10:36] <pitti> ah ok, that sounds simple enough then
[10:46] <opiwahn> did this change from 14.04 to 15.04?  I customized an ubuntu-live-cd..  an entry in my "isolinux.cfg" boots with parameter "text" the text-only mode... remastering 15.04 this entry still boots gui... something changed here??
[10:48] <pitti> opiwahn: ah yes, our lightdm.service doesn't check for "text"
[10:48] <pitti> bug report appreciated
[10:48] <opiwahn> what can I do?
[10:48] <pitti> in /lib/systemd/system/lightdm.service, add ConditionKernelCommandLine=!text to the [Unit] section
[10:49] <opiwahn> ok. I'll try and give you feedback
[11:17] <pragomer> opiwahn: hello
[11:34] <opiwahn> pitti: I added this line to lightdm.service... after rebuild with boot-option "text" the system hangs on "rc-local.service"
[11:35] <opiwahn> pitti: this is my file: http://pastebin.com/C05ZEfnL
[11:38] <opiwahn> although I added ConditionKernelCommandLine=!text    to lightdm.service boot-option "text" does not work anymore
[11:43] <seb128> budgets for?
[11:46] <opiwahn> I added this line to lightdm.service... after rebuild with boot-option "text" the system hangs on "rc-local.service"    it says "A start job is running for Wait for ...en to Quit"
[11:51] <opiwahn> built a initramfs script that should block harddisks (blockdev --setro /dev/sd*).... but it says /dev/sd* not found.. is it possible that a this stage of boot /dev/sda etc.. are not yet ready??
[11:51] <pitti> opiwahn: please boot with systemd.debug-shell, then ctrl+alt+F9 when it hangs, and check systemctl status rc-local.service -- do you do anything funky in there?
[11:52] <pitti> opiwahn: yes, they very likely are not yet
[11:52] <pitti> not in init-top/
[11:53] <opiwahn> pitti: ah.. ok.. what would be the right place to put the script in to block these devices?
[11:53] <opiwahn> pitti: you mean if I edited rc-local.service? nope
[11:54] <opiwahn> pitti: where to put such a script? http://snag.gy/4WtQp.jpg
[11:55] <opiwahn> how do I boot with systemd.debug-shell ?
[12:00] <pitti> same place as "text"
[12:00] <pitti> i. e. kernel command line
[12:00] <opiwahn> ok I try
[12:00] <opiwahn> pitti: found out the right place would be local-premount :-)
[12:09] <mardy> pitti: sorry to bother you again :-) is there a way to get my unique connection name with dbus-python, or do I have to manually call "Hello"?
[12:16] <teward> pitti: got a question for you with regards to apport hooks, 'cause i'm a little lost.  Can apport hooks grab the output for a given command (not a log file!) for a package post installation failure, so when the bug is filed in 15.04 and up, we can get usable output and information rather than nothing useful from the existing apport handling for a package?
[12:16] <teward> (everyone says you're the person to poke on it)
[12:17] <mardy> pitti: actually, I cannot even call Hello myself: "dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Failed: Already handled an Hello message"
[12:30] <mardy> pitti: nevermind found it by using the source (bus.get_unique_name() -- looks like it's undocumented)
[12:36] <opiwahn> at what stage of initrd script: http://snag.gy/4WtQp.jpg   are devices /dev/sda e.g. ready to use ?
[12:59] <pitti> mardy: I don't know, I'm afraid; nothing in http://dbus.freedesktop.org/doc/dbus-python/api/ ?
[12:59] <pitti> mardy: ah, great!
[13:00] <pitti> teward: sure, hooks can run arbitrary stuff; there's even an apport.hookutils convenience wrapper for it
[13:00] <pitti> teward: apport.hookutils.command_output()
[13:09] <pstolowski> hi! i need to access an arm64 box to debug an issue with unit tests of unity-scopes-api, can somebody help me with getting an access?
[13:10] <cjwatson> pstolowski: you want #is, ask for access to the porter boxes
[13:11] <pstolowski> cjwatson, k, thanks!
[13:11] <cjwatson> (#is internal that is)
[13:11] <cjwatson> pstolowski: https://wiki.canonical.com/InformationInfrastructure/ISO/BuildInfrastructure/PorterBoxes
[13:11] <pstolowski> ack
[13:17] <smoser> pitti, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt
[13:17] <smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt#L107
[13:17] <pitti> smoser: ah, nice! thank you
[13:21] <teward> pitti: i'm horribly new to the apport hooks stuff, and embarrasingly so.  Do you have syntax documented anywhere for that, and potentially a general example of that in use currently somewhere?
[13:21] <teward> Next question is testing the apport hook, and that's the next question.  Final question is how do you include the apport hook inside of a package for inclusion in the repositories?
[13:21] <pitti> teward: "grep -r command_output /usr/share/apport/package-hooks/" has plenty of examples
[13:22] <teward> pitti: and the last part, about including in the packaging, I didn't find clear documentation on that, though I was hunting it last night when really tired
[13:22] <pitti> teward: or look at this for the API docs: python3 -c 'import apport.hookutils; help(apport.hookutils)'
[13:22] <teward> about when micahg poked me in -motu
[13:22] <pitti> teward: /usr/share/doc/apport/package-hooks.txt.gz is the first documentation you should read
[13:23] <teward> thanks, i'mma read all that.  sorry for picking your brain on this :/
[13:23] <pitti> teward: test> put it into /usr/share/apport/package-hooks/, and run "apport-bug yourbinarypackage"
[13:23] <pitti> teward: then you see the details of collected information in the window; just don't send it then
[13:24] <mdeslaur> The nss package has "libnss3-tools:native (>= 2:3.19-1-1~) <cross>" in Build-Depends, but the upload to Ubuntu fails with "invalid Build-Depends field; cannot be parsed by apt: Problem Parsing Dependency"
[13:24] <mdeslaur> I've never seen that format before, is that supported in Ubuntu?
[13:24] <pitti> teward: packaging> either use dh_apport (man dh_apport, in the dh-apport package), or just normal dh_install and put the file into the right place/name
[13:25] <pitti> mdeslaur: it's a realatively new debian thing called "build profiles"
[13:25] <pitti> mdeslaur: https://wiki.debian.org/BuildProfileSpec
[13:25] <mdeslaur> pitti: ah! thanks for the searchable term
[13:26] <pitti> mdeslaur: most probably Launchpad doesn't yet know about it
[13:26] <pitti> it's a kind of "make doko happier" feature :)
[13:27] <mdeslaur> oh, wow, I didn't know doko could be made happy :)
[13:27] <teward> pitti: thanks again.  and sorry for buggin you for documentation links and such.  At least I have a start point now, thanks!
[13:27] <pitti> teward: no worries, that's what IRC is for :)
[13:27] <pitti> teward: please let me know if you run into difficulties
[13:28] <teward> pitti: i likely will, python is NOT my forte
[13:29] <teward> i have a general understanding of it, enough to interpret semi-intelligible scripts and such, but ehh
[13:30] <pitti> teward: then I guess looking at the existing hooks and adapting them to your need is best
[13:30] <pitti> teward: most hooks should be simple, like collecting an extra log file or command output or two
[13:31] <teward> pitti: exactly, although the headache is that it's a post-installation failure - some have been ApacheAlreadyBindingTo80 issues, some have been failed configurations by the end users (i.e. something odd and nonstandard)
[13:31] <teward> and since systemd it's been even less diagnosable
[13:31] <teward> it used to spit errors out nicely.  now it just 'fails' with no usable error data in apt logs
[13:32] <teward> pitti: i assume in the documentation there's a selective-case for the hooks such that if it's a package install/postinstall/upgrade/postupgrade failure during apt, it will only trigger then?
[13:33] <teward> we don't need `journalctl -xe` or `systemctl status nginx.service` for other bugs yet...
[13:33] <teward> (and I assume that's documented as well)
[13:33] <teward> (so I should just start reading xD)
[13:46] <pitti> teward: the hook can look at report['ProblemType']
[13:46] <pitti> teward: that's "Crash", "Bug", or for your case "Package"
[13:47] <pitti> teward: the hook will always be called when you report something against that package, it can conditionally do/evaluate stuff based on ProblemType and the keys it has in the report object
[14:27] <barry> cjwatson: well, it looks like i must have released lazr.delegates 2.0.2 back in january and yet somehow managed to not check any of that into bzr or tag it.  can't find it on any machine.  must have been my evil twin, so now i'm going to unfutz that and try to get a 2.0.3 out in a bit
[14:27] <teward> pitti: right, i knew the hook would always get called, hence wanting to do some different things per problemtype
[14:27] <teward> pitti: thanks again
[14:27] <cjwatson> barry: Yikes.  OK ...
[14:28] <barry> cjwatson: at least i have the tarball and it wasn't much
[14:29] <teward> um... general question, but would an SRU to add in an apport hook for a package even be considered?  I only ask because with Vivid, we currently have a bunch of ambiguous bugs all for the same version all for failed-to-install, and nobody's providing additional info when we ask for it except maybe one guy on one bug.
[14:29] <teward> and adding an apport hook would solve that ambiguity problem.
[14:30] <teward> ('cause we can't diagnose bugs, even, in the current state of things)
[14:30] <teward> (for nginx)
[14:41] <barry> cjwatson: okay, 2.0.3 tagged and pushed.  if you want to give it a quick look/test i can wait a bit before spinning the release
[14:42] <barry> gonna make some tea
[14:50] <doko> jamespage, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778058 -std=gnu99 should help
[14:52] <cjwatson> barry: looks fine by eye, I expect you can just push that
[14:54] <barry> cjwatson: thanks. releasing
[15:09] <barry> cjwatson: done
[15:09] <cjwatson> thanks
[15:09] <cjwatson> will poke again at lazr.restful in a bit then :)
[15:29] <pitti> mvo: is there a python-apt'ish way of getting a list/iterator of all apt sources?
[15:29] <pitti> mvo: I mean the "deb[-src] ..." lines in sources.list and sources.list.d/
[15:30] <mvo> pitti: yes, some high level stuff even "pydoc aptsource"
[15:32] <pitti> mvo: oh, nice! So I create an aptsources.sourceslist.SourcesList() and then what?
[15:32] <pitti> mvo: oh, it's an iterator, nice!
[15:32] <mvo> pitti: there should be some example code and even some documentation
[15:33] <mvo> pitti: https://apt.alioth.debian.org/python-apt-doc/library/aptsources.sourceslist.html
[15:33] <mvo> pitti: https://apt.alioth.debian.org/python-apt-doc/library/aptsources.distro.html might also be interessting
[15:35] <pitti> mvo: perfekt, danke sehr!
[16:07] <doko> xnox, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+packages ftbfs on ppc64el and arm64 :-/
[16:07] <doko> no, everywhere
[16:08] <xnox> doko: boost1.55 is 98abi only, boost1.57+ is c++11 abi.
[16:08] <xnox> doko: you want 1.57 from experimental.
[16:09] <xnox> doko: boost1.55 fixed build failures, for reverse-deps, that compile with gcc5 & 98abi.
[16:10] <doko> xnox, still no 1.58?
[16:10] <xnox> not yet, no.
[16:10] <xnox> didn't have time to do it yet. I guess I should work on that and other build failures asap.
[16:10] <xnox> doko: did you poke icu futher to determine if it will require transition or not?
[16:10] <doko> xnox, feel free to upload to the ppa mentioned above
[16:11] <xnox> i hope it doesn't, but who knows.
[16:11] <doko> xnox, no, just rebuilt with GCC 5
[16:11] <doko> in the same ppa
[16:11] <xnox> doko: ok. let me check if I have upload rights there.
[16:11] <xnox> yes i do. good.
[16:27] <teward> pitti: what does one do if there's an AssertionError on the thing
[16:28] <teward> (for apport hooks)
[16:36] <teward> oop nevermind
[17:03] <ogra_> lol ... so debian goes back to ffmpeg ?
[17:03]  * ogra_ just saw the news, thats funny
[17:59] <hich-em> hey sabdfl
[18:04] <hich-em> Neo31,
[18:04] <hich-em> hak lehna
[18:05] <hich-em> Neo31,
[18:06] <smoser> anyone able to validate my vague memory that at one point apt was not checking the checksum of Translation-* files
[18:10] <TJ-> smoser: That sounds familiar; I was dealing with a lot of bugs like that due to captive portals a while ago
[18:12] <teward> did pitty leave until tomorrow?
[18:12] <teward> pitti*
[18:12]  * teward hates autocorrect
[18:16] <teward> so, i have one issue - I'm prompting the user in my apport hooks as to whether to include certain files.
[18:17] <teward> Problem is: Apport asks the same set of questions twice
[18:17] <teward> not sure whether it's my code or what
[18:55] <teward> other than pitti, is there anyone here who knows enough about apport hooks to try and diagnose the issue i'm seeing with my apport hook for a specific package?
[19:49] <teward> is there a way to determine whether upstart or systemd are actually in use on a given system?  (Some people use Upstart, some use SystemD, on their 15.04 systems...)
[19:49] <teward> like some file or some python that can be used as part of an apport hook
[19:50] <tarpman> teward: reportbug contains a snippet that tries to guess the active init system, I'd copy that
[19:53] <teward> so there's no easy way then
[19:53] <sarnold> teward: readlink /proc/1/exe might get you there
[19:53] <teward> sarnold: that worked for systemd on 15.04, didn't work 14.04
[19:53] <teward> with upstart
[19:53] <teward> i know one guy who has upstart on 15.04 instead, because they're odd but eh
[19:54] <sarnold> teward: oh? I didn't realize 14.04 could boot with systemd well enough to use..
[19:54] <teward> sarnold: it's a three pronged test
[19:54] <teward> sysvinit, systemd, or upstart
[19:54] <teward> sarnold: trying to make a 'global' apport hook :/
[19:55] <sarnold> ahh
[19:55] <teward> such that it can NOT run the systemd gathering commands if systemd isn't present
[19:55] <teward> (because it will blow up in our face if we try)
[19:57] <teward> what I need is pitti to be here but I missed em a while ago for a followup
[19:57] <teward> sarnold: is it safe to assume that for 15.04 and up it's likely Upstart handling things?
[19:57] <teward> s/upstart/systemd/
[19:57] <teward> god I am tired
[19:57] <sarnold> teward: it is the official; I think that makes sense.
[19:58] <teward> ok.
[19:58] <teward> because upstart and sysvinit, stderr is caught in the dpkg terminal log apparently
[19:58] <teward> but systemd, it holds it internal
[19:58] <teward> and just says "There is a problem"
[19:58] <teward> it's the nginx-bugs-not-having-sufficient-details problem that i'm finally attacking with the whole of my brain
[19:59] <sarnold> woo :)
[19:59] <teward> and thanks to pitti, i've got the bare minimum in apport hooks to diagnose the postinstallation scripts failed problem
[19:59] <teward> but me being the person i am, tryin to expand it - ask if the user wants to include the error.log, nginx.conf, and enabled site configs, which could contain sensitive info, with the report, for Crash and Bug type bugs
[20:00] <teward> those ones are easy
[20:00] <teward> but making the part to gather the stuff systemd doesn't put out to the logs is a systemd only thing, so i'll have to use that in the interim until pitti's back to spotcheck my code and give insights
[20:00] <teward> BEFORE putting in for SRU consideration for Vivid, and before uploading to Vivid
[20:00] <teward> s/Vivid/Wily/
[20:01] <teward> ehh, whatever, too tired
[20:02] <sarnold> don't forget to exclude ssl keys and passwords :)
[20:03] <teward> sarnold: mmm, well, i was considering that if those are included forcing the sensitivity to Private
[20:03] <teward> but then i realized, ehhhh, that'd be annoying to me
[20:03] <teward> so i may leave that out
[20:03] <teward> the key important log file is error.log though
[20:03] <teward> that has IP addrs
[20:04] <teward> sarnold: how much do you know about apport hooks?
[20:04] <teward> tarpman: ^ same q
[20:04] <sarnold> teward: nothing; I just see the collected data in launchpad
[20:05] <teward> 'cause I get an erroneus "Error: COmmand exited with stats 3" error with command_output
[20:05] <teward> i really need pitti here :/
[20:05] <tarpman> teward: no idea apport apport stuff, just your mention of init-detection caught my eye
[20:05] <teward> tarpman: yeah, that's something I'd love to incorporate into the apport hooks to NOT have systemd commands if upstart is present but eh
[20:06] <teward> i guess i'll stop by tomorrow morning and see if pitti is around
[20:06] <tarpman> teward: specifically, http://sources.debian.net/src/reportbug/6.6.3/reportbug/utils.py/#L1230
[20:06] <tarpman> pretty easy
[20:08] <teward> tarpman: how accurate is it in Debian?
[20:08] <teward> fairly accurate?
[20:10] <tarpman> teward: haven't heard of any false results. the systemd one is definitely the supported way of detecting systemd, at least
[20:10] <teward> mmm, indeed
[20:12] <teward> sarnold: i'm definitely glad though i know have a baseline for the 'ambiguous bugs' problem now, with these TWO LINES we get all the information we need for systemd and postinst fails
[20:13] <teward> baseline fix*
[21:57] <sarnold> teward: sweet :) there's certainlu enough 'postinst returns 1' errors..
[21:57] <sarnold> teward: knocking off the nginx errors would be a nice start :)
[22:28] <teward> sarnold: the start point there: get USABLE debug info
[22:28] <teward> 'cause currently it's horridly unuseful **** there now
[22:28] <teward> -server even agreed when i went on a minirant last night
[22:35] <mwhudson_> hm
[22:35] <mwhudson_> when i do
[22:35] <mwhudson_> sudo dpkg --add-architecture armhf
[22:35] <mwhudson_> on my laptop, apt-get update complains
[22:36] <mwhudson_> because the armhf stuff is on ports.ubuntu.com, not archive
[22:36] <teward> stupid question: why're you adding armhf arch?
[22:36] <mwhudson_> oh, i guess i need to put [arch=] in sources.list a bunch
[22:36] <mwhudson_> teward: hoping to be able to run stuff with qemu-arm-static
[22:37] <mwhudson_> maybe that's silly
[22:37] <mwhudson_> perhaps i should just make a chroot instead
[22:38] <teward> mwhudson_: eheheh... FWIW I have a pi coming in for when I need to run arm stuff.  And I have an sbuild enviro to local-build armhf stuff, although that sometimes asplodes just like the ppa builders do
[22:38] <mwhudson_> well i have a dragonboard too
[22:38] <mwhudson_> but sometimes i just have my laptop
[22:39] <mwhudson_> (which has arm64 installed on it, but the armhf chroot on there doesn't require qemu games)
[23:23] <teward> mmm, stupid question, how does one use dh_installapport / dh_apport in the package?  Is it automated or is there something i have to drop into the rules file?
[23:24] <teward> i'm a little confused on implementation/use of dh_apport is all
[23:24] <teward> (to work with the apport hooks for a given package)
[23:36] <infinity> teward: Manpages tend to explain these things.
[23:36] <teward> infinity: i didn't glean anything special from the manpage, but then again, i'm fairly tired having bashed my head against python all day
[23:36] <teward> and i am an idiot, it explains it perfectly
[23:36]  * teward facedesks


[03:37] <sbalneav> Evening all
[03:43] <ace_suares> hi sbalneav
[03:51] <sbalneav> Hey ace
[04:00] <ace_suares> wassup
[04:01] <sbalneav> Making a blog post.
[04:01] <sbalneav> It's been 9 or so months.
[04:01] <sbalneav> I'm about due :)
[04:04] <ace_suares> there's blogger and coders :-)
[04:06] <sbalneav> http://ltspthinclient.blogspot.com/
[04:06] <sbalneav> I code much more than I blog :)
[04:07] <ace_suares> yeah obviously
[04:07] <ace_suares> i wasted another 3 hrs playing a game
[04:07] <ace_suares> he he
[04:08] <sbalneav> Warzone?
[04:08] <ace_suares> yep
[04:08] <ace_suares> good post!
[04:08] <ace_suares> nicely written too
[04:09] <ace_suares> I just won so I am lookign around a bit and then sleep
[04:09] <sbalneav> Build machine gun bunkers to defend.  Research cannon tech until you get HPV's, build one command turret, and put the factories on auto-build of python hover HPV's.  PWN all enemies.
[04:09] <ace_suares> more or less accurate. I like vtols too ;-)
[04:10] <ace_suares> so you wasted a couple of hrs too uh...
[04:10] <ace_suares> man i had so much trouble with my machine for days
[04:10] <ace_suares> very strange i chnaged refresh rate on sytem monirot and everythign was fine again
[04:11] <ace_suares> unbelievable
[04:11] <sbalneav> I've been playing warzone 2100 since the game came out commercially.  I've been following the Gnu implemenation since day 1
[04:11] <sbalneav> I even contributed a couple of patches :)
[04:11] <ace_suares> ah we need to play online one day then :-)
[04:12] <sbalneav> Sure.  I'll probably get my *ss kicked since I've played the AI so long I know exactly how *little* I need to defend :)
[04:12] <ace_suares> r u going to linuxcon ?
[04:12] <sbalneav> Nah.  With the exception of BTS in late october, I'm conferenced out for the year.
[04:13] <ace_suares> oh i am still in the stage where I spread those red/gray rockets, then mortars around, just drag some trucks and then carpet bomb the enemy
[04:13] <sbalneav> FISL in Brazil, LinuxWorld in San Fran, and LTSP BTS in Maine.
[04:13] <ace_suares> I dislike the travel so you will see efforts from me to host any linux/ltsp/whatever con here in curacao :-)
[04:22] <ace_suares> hi dgroos
[04:22] <sbalneav> hello dgroos
[04:23] <ace_suares> sbalneav: damn, all the cookbook pages on the edubuntu wiki redirect to help.ubuntu.com !
[04:30] <ace_suares> ok i am off can't do much on the wiki now
[04:30] <ace_suares> see ya
[05:15] <dgroos> Hi ace_suares (ok, kinda post facto, I know :)
[05:16] <dgroos> and howdy, sbalneav.
[05:16] <sbalneav> _Userper_ pointed out a "potential" bug in Sabayon, but turns out it's not a bug
[05:17] <dgroos> I got iTALC fixed yesterday on the server and NX today--things are starting to look pretty...
[05:17] <dgroos> what was it?
[05:18] <dgroos> Now, if I can get my plone site upgraded and get CmapTools to work as localapp I'll be able to think about teaching!
[05:25] <sbalneav> dgroos: He disabled the command line, then wondered why he could still launch gnome-terminal
[05:26] <dgroos> sounds like a teacher ;)
[05:26] <sbalneav> but disabling the command line only stops the "command->run" interface from gnome.  If you want to disable the terminal, you have to remove it from the menus.
[05:26] <dgroos> (like me)
[05:26] <sbalneav> How's a kid supposed to *LEARN* anything if you don't give 'em the command lin?
[05:27] <dgroos> yea...
[05:28] <sbalneav> When I was in grade 10, I had my first "official" computer course.
[05:28] <sbalneav> I had build my own computer from a kit (a ZX-81) in grade 8.
[05:28] <sbalneav> I sat right in the front row, and all during the first class, I corrected the teacher on his syntax errors.
[05:29] <sbalneav> "Mr. Friesen, you need a NEXT N there. Mr. Friesen, you need a semicolon there." etc.
[05:29] <dgroos> Cool, and hopefully the teacher appreciated and took advantage of this young teacher!
[05:30] <sbalneav> After 2 more classes of this, he took me aside, asked me a couple of questions, and determined I knew more about BASIC programming than he did. :)
[05:30] <dgroos> and then did he put you to profitable use--ie profitable for your education and others?
[05:30] <sbalneav> He said "We have this new thing called a "glass tty" connected to something called "unix", maybe you'd like to play with that for the rest of the year"
[05:31] <sbalneav> This was in 1984
[05:31] <dgroos> cool :)
[05:31] <sbalneav> And the rest, as they say, is history.
[05:32] <dgroos> nice.  Ever contact Mr. F. and let him know what you do, that you program for education on your own time?
[05:33] <sbalneav> Personally, if it were me, I'd let the kids have the command line.  Those who don't figure it out can keep plinking away in the gui.  Those who manage to trash their home directory, or start poking around in /usr/sbin get to check out a copy of "Programming in Python" or "Shell scripting basics", and full marks for the year :)
[05:33] <sbalneav> I did, years ago.  He passed away about 10 years back.
[05:34] <sbalneav> At that point, I was still working for the University of Winnipeg.
[05:34] <dgroos> Down town...
[05:34] <sbalneav> I've taught classes, but never to grade school kids.  Only either uni students or adults.
[05:34] <dgroos> My daughters heading to U of M in 10 days :)
[05:35] <dgroos> will be a 'frosh'.
[05:35] <sbalneav> Which faculty?
[05:36] <dgroos> Well, she want to study Eastern European history, though not sure that answers your question?
[05:38] <sbalneav> Ah, so she'll probably spend a chunk of time in Fletcher Argue
[05:39] <sbalneav> I spent most of my uni years hanging out in windy hall in the basement of armes. :)
[05:40] <dgroos> Fletcher Argue?  sounds like someone who makes arrows would do in a disagreement ;)
[05:40] <dgroos> So you went to U of M?
[05:40] <sbalneav> Yup
[05:40] <sbalneav> 86-90
[05:40] <dgroos> She's very excited.
[05:40] <sbalneav> Yeah, University's a lot of fun.
[05:40] <sbalneav> Lots of new things to learn, people to meet.
[05:41] <dgroos> anyway, I'm sure I'll get a chance to buy you that beer I mentioned a while ago, though not this trip next weekend. :)
[05:42] <sbalneav> You live in winnipeg proper, or out of town?
[05:42] <sbalneav> I'm in South St. Vital.
[05:43] <sbalneav> Gimme a yell at work if you're ever passing by.  985-5249
[05:43] <dgroos> Well, actually i live in Minnesota,
[05:43] <sbalneav> Oh!
[05:43] <dgroos> and yes, I will!
[05:43] <sbalneav> U of M = University of Minnesota!
[05:43] <dgroos> (Minneapolis to be specific)
[05:44] <sbalneav> Thought you meant university of Manitoba :) lol
[05:44] <dgroos> No, U of M = University of Manitoba!
[05:44] <sbalneav> So she's coming to OUR u of M instead of yours?
[05:44] <dgroos> She's going to go to school in your country, not mine :)
[05:44] <sbalneav> Wow
[05:45] <dgroos> She's a bit adventurous :)
[05:45] <sbalneav> U of Man's got a degree program she wants that U of Min doesn't?
[05:45] <alkisg> Good morning
[05:46] <sbalneav> Mornig, alkisg
[05:46] <dgroos> Well, it's a long story, and kind of interesting--over that beer!
[05:46] <dgroos> Good evening/morning alkisg
[05:46] <sbalneav> Well, gimme a yell the NEXT time you're in town.
[05:46] <dgroos> For sure.
[05:47] <sbalneav> I've been down a couple of times to Minneapolis for a Linux and Education conference that was held there a couple of times.
[05:47] <sbalneav> And, my buddy Jeremy White of Codeweavers/wine fame's down there.
[05:47] <dgroos> 724-3595 give me a call :)
[05:48]  * sbalneav writes down
[05:48] <sbalneav> k got it.
[05:48] <dgroos> I went to college with Jeremy though I only knew him through his fame as being pretty good at (read amazing) at math.
[05:49] <sbalneav> He's a great guy.  And the work he's done with wine's fantastic
[05:49] <sbalneav> I buy a new copy of wine every year just to "kick in" :)
[05:49] <dgroos> cool.
[05:49]  * sbalneav yawns
[05:50] <sbalneav> Well, that's enough looking at the handbook tonight.
[05:50] <sbalneav> Time for me to hit the sack so I can do it all over again tomorrow :)
[05:50] <dgroos> Question!
[05:50] <sbalneav> Shoot
[05:50] <sbalneav> oh, btw
[05:50] <dgroos> If I disable some game for a level1 user, that just means that it won't be available through GNOME, but he/she can still navigate to the exe and launch it from there, right?
[05:50] <sbalneav> ltspthinclient.blogspot.com
[05:51] <dgroos> your blog?  I'll check it out.
[05:51] <sbalneav> Yeah, I don;t update very often. Like, 3 times a year is "a lot" for me :)
[05:51] <sbalneav> Hm
[05:52] <sbalneav> I think that can be locked down...
[05:52] <sbalneav> one sec
[05:52] <dgroos> ah, the dichotomy--do or write about doing...  I face that issue as well...
[05:52] <sbalneav> http://library.gnome.org/admin/deployment-guide/
[05:53] <dgroos> I'll check it out tomorrow!  I too need to get back to work--plone buildout config sheet.  thanks, and I'll put the blog on the list of reading material...
[05:56] <dgroos> Nice!  I look forward to reading other entries as well.  Glad to hear that you're committing to continued fun with Sabayon :)
[05:56] <dgroos> have a good eve, all.
[05:57] <alkisg> Hmmm I wonder what happened with that qt greeter... "... and got a Qt greeter fleshed out."
[05:59] <sbalneav> alkisg: I know Ryan52 in #ltsp did some work with it.
[05:59] <alkisg> Not upstream yet, is it?
[05:59] <sbalneav> These two guys showed up, "wrote it", then we never heard from them again.
[06:00] <alkisg> Heh.  Ping is a tool for diagnosing network issues on an TCP/IP network.
[11:39] <ace_suares> ubottu: so are you back from holiday /
[11:39]  * ace_suares smiles at ubottu
[11:39] <ace_suares> I like 'em dumb, and terminal...
[11:40] <ace_suares> ubottu: man, cool!
[11:40] <ace_suares> Well you should know something about man. Really, they're your only worthy opponent'
[11:41] <ace_suares> I met a brother of yours last night, he was defending his base with lancer bunkers and came at me with assault canons. But I got him cornered eventually.
[11:41] <ace_suares> ubottu: brother?
[11:41] <ace_suares> Well he says you should call him, and he'd love when you'd drop by with your wife ubotta.
[11:42] <ace_suares> Hey gotta go now, some work to do.
[11:42] <ace_suares> ubottu: bye!
[11:42] <ace_suares> Yeah but I do really have to go.
[13:43] <mhall119|work> wow, sometime reading the scroll buffer, isn't at all what you expect
[14:04] <highvolt1ge> mhall119|work: heh
[22:36] <highvoltage> goodnight edubuntuland!
[22:37] <alkisg> g'night highvoltage


[20:03] <skryking> could someone point me in the right direction to request a USB_ID be added to sound/usb/format.c?
[20:10] <sarnold> skryking: if you want it in the upstream kernel, ./scripts/getmaintainer.pl sound/usb/format.c  is a good start. if you want it in an ubuntu kernel, 'ubuntu-bug linux' is a good start
[20:11] <skryking> sarnold: thank you


[00:02] <sarnold> engineer-pearl: the Digital Ocean guides are probably a better starting point, see e.g. https://www.digitalocean.com/community/tutorials/how-to-create-a-ssl-certificate-on-apache-for-ubuntu-14-04 or https://www.digitalocean.com/community/tutorials/how-to-create-a-self-signed-ssl-certificate-for-apache-in-ubuntu-16-04
[00:02] <sarnold> engineer-pearl: or https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-16-04
[00:02] <sarnold> etc
[00:03] <sarnold> they've got a lot of useful things :)
[00:08] <engineer-pearl> Ooop I thinnk that did it
[00:09] <engineer-pearl> Thank you, and since I've got you here, may I ask you a question (since I'm on a time crunch unfortunatly, I thought I had til the third, I have til tomorrow)
[00:10] <engineer-pearl> do I need to set the servername in the secure connection area or can I leave that be?
[00:10] <engineer-pearl> I'd do a proper test and find out but I have to wait for the ports.
[00:13] <sarnold> I don't know details of actual software, but I do know that SNI from clients means servers typically have to know their name, so they can hand out the proper certificate when clients request it
[00:34] <RoyK> engineer-pearl: let's encrypt just makes the day :)
[00:34] <engineer-pearl> ?
[00:34] <RoyK> well, it just works
[00:34] <RoyK> and configures apache for you during installation and all
[00:35] <RoyK> usually quite worry-free
[00:35] <engineer-pearl> I didn't realize that getting an ERROR MESSAGE (the ultimate goal, actually) would be this complicated
[00:38] <engineer-pearl> okay so is this "let's encrypt" a command line thing or a gui thing?
[00:38] <tarpman> engineer-pearl: https://letsencrypt.org/getting-started/
[00:39] <engineer-pearl> oh, just certificates. :/
[00:39] <engineer-pearl> not an accurate face.
[00:40] <sarnold> their 'standard client' does a bunch of configuration stuff too, no?
[00:40] <sarnold> hence the huge proliferation of other tools that do fewer things
[00:42] <engineer-pearl> @tarpman I think you found a "getting lost" page then...
[00:44] <engineer-pearl> I have the certificate ready. At this point I just need to get the port to listen, which will provide me with the information that my certificate is not signed by a trusted third party (my goal. I know that seems odd.)
[00:44] <fyrril> any reason on a fresh install, I get a black screen on a connected display.. but I can SSH into the server just fine?
[00:44] <ikonia> I'm struggling to see where this becomes an ubuntu problem ?
[00:45] <engineer-pearl> @ikonia I had a problem and had to guess where to go.
[00:45] <sarnold> fyrril: look around for something like a kernel comman dline parameter "nomodeset", I have a vague feeling that's helped (or hurt) other people...
[00:45] <ikonia> again - how is this anything to do with ubuntu ?
[00:46] <sarnold> ikonia: meh there's nothing wrong with asking how to configure apache to do tls..
[00:46] <sarnold> if you follow any old guide out ther eyou'll wind up re-writing half your apache config for no reason
[00:46] <ikonia> sarnold: I don't think there is any problem with asking how to conigured apache in ubuntu, but it seems to have gone beyond that now
[00:46] <fyrril> sarnold, you're referring to google correct?
[00:47] <sarnold> fyrril: or kernel Docuemtnation/ directory, I'm not sure where to suggest first, I've been lucky so far and not seen this :)
[00:48] <fyrril> just making sure you meant the internet before I spent 20 minutes looking through files in the CLI :D
[00:48] <sarnold> :)
[00:48] <fyrril> cheers
[00:50] <engineer-pearl> Okay, so here's something that's not unusual for me - I have a message saying something is already using 443, yet I can't identify anything that is using it, not with netstat, not with my browser, not at all
[00:51] <engineer-pearl> Netstat also doesn't show anything on 80, but I can connect to 80 on my browser.
[00:52] <ikonia> engineer-pearl: what netstat command are you using
[00:52] <ikonia> (maybe pastebin the output)
[00:55] <engineer-pearl> This is just "sudo netstat" http://paste.ubuntu.com/23488122/ cause "sudo netstat | grep 80" has no output
[00:55] <ikonia> ughh
[00:55] <ikonia> 80 won't show up anything
[00:55] <sarnold> netstat without arugments doesn't show listening sockets, just connected sockets
[00:56] <ikonia> try netstat -a | grep LIST for example
[00:56] <sarnold> try netstat -an
[00:56] <ikonia> I'd strongly suggest you read man pages on commands before blindly typing them, and before using them to evaluate situations
[00:56] <ikonia> (unless you know the flags to use)
[00:57] <tarpman> and keeping in mind that netstat on linux is different from netstat on e.g. windows or bsd
[00:57] <engineer-pearl> well it being different from windows would explain why itdidn't work even though I tookI it right off the internet (
[00:58] <ikonia> "took it right off the internet" ?
[00:58] <engineer-pearl> ((to be fair I've tried to use it before but))
[00:58] <tarpman> the internet is, as a rule, untrustworthy
[00:58] <ikonia> man netstat
[00:58] <tarpman> ^
[00:58] <ikonia> shows you all the flags and what it does
[00:58] <ikonia> rather than just typing in blind
[00:59] <engineer-pearl> I've tried to use that but I find the helps more helpful
[00:59] <ikonia> "the helps" ?
[00:59] <sarnold> ?
[00:59] <engineer-pearl> like help [command] or command --help
[01:00] <ikonia> but that gives you incomplete info
[01:00] <ikonia> as you can see with netstat
[01:00] <ikonia> it's a useful tool if you know how to use the command
[01:01] <engineer-pearl> "sudo netstat -pa | grep 80" and "sudo netstat -pal | grep 80" still don't show it???
[01:02] <ikonia> engineer-pearl: why are you doing "pa"
[01:02] <ikonia> you where given 2 examples
[01:02] <engineer-pearl> I tried those too
[01:02] <ikonia> and 80 won't show up if you're using service name mapping
[01:02] <ikonia> engineer-pearl: pastebin netstat -a | grep LIST
[01:02] <fyrril> sarnold, all squared thanks. GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" to ""
[01:02] <sarnold> fyrril: -that- fixed it?? odd.
[01:02] <sarnold> fyrril: thanks for reporting back :) it's always nice to know what works
[01:02] <fyrril> first thing I found said to add nomodeset to the quiet splash, but same problem.. second thing I found said to remove it all /shrug
[01:02] <fyrril> no sweat, it's a thankless job I'm sure.
[01:02] <sarnold> 'quiet splash' is a funny setting on a s erver anyway, hehe
[01:02]  * tarpman likes 'netstat -nltp'
[01:03] <tarpman> sarnold: not sure if it's still the case, but wasn't 'splash' necessary in the past to get plymouth activated?
[01:03] <engineer-pearl> http://paste.ubuntu.com/23488146/
[01:03] <sarnold> tarpman: yeah but why bother with that either? heh
[01:03] <tarpman> sarnold: message demultiplexing, of course :)
[01:04] <ikonia> engineer-pearl: grep git /etc/services
[01:05] <tarpman> sarnold: don't tell me you haven't read http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/ years ago ;)
[01:05] <sarnold> tarpman: never seen that :)
[01:07] <engineer-pearl> Here's just with "netstat -a | grep git" http://paste.ubuntu.com/23488154/
[01:07] <ikonia> engineer-pearl: what is the point in that ?
[01:07] <engineer-pearl> I can also grab ls /etc/services if that was what you were after
[01:07] <engineer-pearl> I don't know you asked for something weird
[01:07] <ikonia> I asked clearly for "grep git /etc/services"
[01:07] <sarnold> engineer-pearl: the point of ikonia's question was to find out what _number_ "ssh" means :)
[01:08] <ikonia> (what git actually meant if it was really the git service or if it was git omnibus installer updating /etc/services for git to have the web server running)
[01:08] <sarnold> engineer-pearl: maybe it means 80, in which case you find out wh you can't bind a web server :) maybe it means 443 which would explain why your web server couldn't offer https....
[01:08] <ikonia> there is a ton of docs about using the obnibus installer ONLY on a machine, nothing else
[01:09] <engineer-pearl> http://paste.ubuntu.com/23488162/
[01:09] <ikonia> so according to that, port 9418 should be open
[01:09] <ikonia> I bet it's not
[01:09] <engineer-pearl> Here's the thing though - I CAN access my server from my machine (ethernet only atm but that should get fixed tonight)
[01:10] <ikonia> get that fixed ?
[01:10] <engineer-pearl> oh wait I missed the second part sorry
[01:10] <ikonia> what's the problem with that, that sounds like a good thing
[01:10] <engineer-pearl> 9418?
[01:11] <engineer-pearl> I thought I was supposed to be binding it to 443?
[01:11] <ikonia> engineer-pearl: have you installed git via the omnibus installer
[01:12] <engineer-pearl> uhhhhhhhh I installed git a long time ago if it wasn't installed by default
[01:12] <sarnold> tarpman: thanks, that was fun reading
[01:12] <ikonia> why would it be installed by default ?
[01:12] <ikonia> no OS installs git by default
[01:12] <engineer-pearl> I don't remember! I've had the machine for a while
[01:12] <ikonia> define a while
[01:12] <ikonia> months, years, 10 years,
[01:12] <engineer-pearl> software? Somewhere between months and a couple of years
[01:13] <ikonia> what is your machines local IP address
[01:13] <engineer-pearl> .30
[01:13] <tarpman> sarnold: great, this has been my https://xkcd.com/1053/ moment for today :)
[01:13] <ikonia> engineer-pearl: .30 is not an IP address
[01:13] <ikonia> what is your machines local ip address
[01:14] <engineer-pearl> <IP_ADDRESS> I think is the one you are asking for
[01:14] <ikonia> is there more than 1 ?
[01:14] <ikonia> one even
[01:14] <sarnold> tarpman: haha, that's great. I've also not seen -that- one before today either. heh.
[01:14] <tarpman> !!
[01:14] <sarnold> tarpman: twice in one day :) not bad
[01:14] <engineer-pearl> There should only be one with that IP, but there are several devices on the network
[01:14] <tarpman> I can basically just go to bed now
[01:15] <ikonia> engineer-pearl: ??? do you understand basic networking ?
[01:15] <sarnold> tarpman: hehehe :D I endorse this idea!
[01:15] <ikonia> (please be honest)
[01:15] <engineer-pearl> "is there more than 1" leaves me to guess what you are asking for
[01:15] <ikonia> I'm asking if that devices has more than one IP address
[01:15] <ikonia> I'm asking if you understand network as you seem to think it's possible for more than one machine to have the same IP
[01:16] <ikonia> as you said "I think <IP_ADDRESS> is the one you want"
[01:16] <ikonia> suggesting there is more than one on that machine
[01:16] <engineer-pearl> more than one IP address maybe? whenever I type in IP addr I seem to get a lot more info than the tutorials suggest I should.
[01:16] <ikonia> do you understand basic networking ?
[01:16] <ikonia> again please be honest
[01:17] <engineer-pearl> I don't understand your question so probably not too well?
[01:18] <ikonia> what IP address is this host running git on the network with
[01:18] <engineer-pearl> nothing should be running git. It should be there but not anything else?
[01:19] <ikonia> what ???
[01:19] <ikonia> you've just shown me a box running git
[01:19] <ikonia> you said you installed it a long time ago
[01:19] <sarnold> for what it's worth this "what port is :git" and "what IP address is the service bound to" are the reasons why I use netstat's -n flag -- names get in the way, but you know where you stand with IP addresses and port numbers.
[01:19] <ikonia> I ask which box is running git and you say "nothing should be running git"
[01:19] <ikonia> sarnold: agreed
[01:19] <engineer-pearl> well here's the thing, I have only ever used git to connect out, never connect in
[01:19] <engineer-pearl> github hosts some good minetest mods
[01:20] <ikonia> engineer-pearl: ok - so you have not actually installed  agit service
[01:20] <ikonia> you've just installed the git client
[01:20] <ikonia> so what is the IP of the host you are having the problem with
[01:21] <engineer-pearl> I may have installed all of git trying to get the parts that I want but I don't really rember, hold on I think I have something holding the record
[01:21] <ikonia> it doesn't matter
[01:21] <engineer-pearl> okay
[01:21] <ikonia> just run "telnet $host_ip 80" from your work station
[01:21] <ikonia> what do you get back
[01:22] <engineer-pearl> does doing it from ssh provide expected behavior? I got an error
[01:22] <ikonia> what do you mean, doing it from ssh
[01:22] <engineer-pearl> Trying <IP_ADDRESS>...
[01:22] <engineer-pearl> telnet: Unable to connect to remote host: Invalid argument
[01:22] <engineer-pearl> well that looks like an IP address
[01:23] <ikonia> what is that IP ?
[01:23] <ikonia> it's not even valid
[01:23] <ikonia> and if you think that's a valid IP address, stop what you are doing now
[01:23] <engineer-pearl> That's the output of the command you sent me!
[01:23] <ikonia> no it's not
[01:23] <engineer-pearl> I know it wasn't alid
[01:23] <ikonia> you can't really think your hosts IP is 0.0.0
[01:23] <engineer-pearl> *valid
[01:23] <engineer-pearl> Just that it followed the form
[01:23] <ikonia> followed the form ?
[01:23] <ikonia> what are you talking about
[01:23] <ikonia> what was the EXACT command you typed
[01:23] <ikonia> and I do mean exact
[01:23] <engineer-pearl> number.numbur.number.number
[01:24] <engineer-pearl> yeah, I copied and pasted it.
[01:24] <ikonia> what was the EXACT command you typed
[01:24] <tarpman> engineer-pearl: you can't just make up random numbers and expect the result to be useful...
[01:24] <sarnold> did you replace $host_ip with the host's IP? or .. include the variable as-is? :)
[01:25] <tarpman> sarnold: great point -- 'telnet 80' does exactly that
[01:25] <engineer-pearl> you know like <IP_ADDRESS>,  <IP_ADDRESS>, <IP_ADDRESS>, all of them follow the same format. So did <IP_ADDRESS>, even if it was nothing.
[01:25] <ikonia> what was the EXACT command you typed
[01:25] <sarnold> $ telnet 80
[01:25] <sarnold> Trying <IP_ADDRESS>...
[01:25] <sarnold> W.T.F.
[01:25] <engineer-pearl> "telnet $host_ip 80"
[01:25] <ikonia> ok
[01:25] <tarpman> it's a standard - if obscure-  shorthand
[01:26] <ikonia> so I'm sad to say I think you are running before walking
[01:26] <sarnold> it's a -stupid- shorthand :)
[01:26] <ikonia> what you are trying to do is outside of your skill level at this time
[01:26] <tarpman> sarnold: telnet 127.1
[01:26] <tarpman> :)
[01:26] <ikonia> and I don't believe you are at a level where you can actually provide debugging
[01:26] <engineer-pearl> well the alternative is to try to find a safe site with an invalid certificate
[01:26] <sarnold> tarpman: #3
[01:26] <engineer-pearl> which uh... I doubht I'm going to find
[01:27] <sarnold> tarpman: seriously. I've been doing tcp/ip networking for >20 years and never seen this.
[01:27] <ikonia> engineer-pearl: what are you actually trying to achieve
[01:29] <engineer-pearl> You know the message you get when you go to a bad site and your browser alerts you that something is wrong?
[01:29] <engineer-pearl> and it even gives more information if you tell it to?
[01:29] <engineer-pearl> Well I have a presentation tomorrow on internet safety, and I figured that would be an EXELENT thing to use
[01:29] <engineer-pearl> Thing is, you have to actually get one.
[01:29] <engineer-pearl> Well I got a tip that if the certificate is self-signed, then you get that message. This means I could get it and explain it without attempting to navigate to a site that isn't okay
[01:29] <engineer-pearl> I've got the certificate ready
[01:29] <ikonia> engineer-pearl: do you understand the irony
[01:29] <ikonia> you don't really understand how this works but you're giving a presentation
[01:30] <engineer-pearl> well I don't need to explain the server side
[01:30] <engineer-pearl> I was just trying to simulate the user side
[01:30] <ikonia> https://badssl.com
[01:30] <ikonia> first hit on google
[01:30] <ikonia> shows all the examples of bad SSL configs
[01:30] <sarnold> heck if all you wanted was a self-signed certificate you could grab any old consumer router, they all fire up a server on <IP_ADDRESS> or <IP_ADDRESS> with a self-signed certificate ....
[01:31] <sarnold> ikonia: how come I can never remember this site when I want it?? I spent five minutes googling for it.
[01:31] <ikonia> sarnold: I always forget it too
[01:32] <sarnold> the closest I could find is https://revoked.grc.com/ which is .. half-way there. but not.
[01:34] <engineer-pearl> nooo that's not the one noooooo ah poop.
[01:34] <engineer-pearl> so that wasn't going to get me theone I'm after
[01:35] <sarnold> it's got a self-signed cert right here: https://self-signed.badssl.com/
[01:35] <ikonia> so you don't really even know what you're after
[01:35] <ikonia> I think this is now well outside the scope of this channel
[01:35] <engineer-pearl> yes but that wasn't the message I was after, I got a bad tip
[01:35] <ikonia> I think you are looking for an untrusted site
[01:35] <ikonia> that has been flagged in the common database as "untrusted"
[01:35] <ikonia> not an untrusted SSL
[01:36] <engineer-pearl> Oh. That would have been good info this morning, but that sounds exactly what I am looking for!
[01:37] <sarnold> aha; try searching for "adobe photoshop" or "microsoft office" and click the first thing that looks like a malware installation page that pretends to be a download page. That'll either exploit your browser or show you the dialog you want. :D
[02:18] <NOVAtechies> exit
[11:31] <ws2k3> nice ubuntu 12.04 mini install is still broken
[11:40] <ikonia> in what way broken ?
[11:51] <jonah> hi is anyone any good with samba? I can't connect anymore to my samba share with a desktop client. It previously worked but now the client just gives timeout on server... any help appreciated. I've tried with firewall off and the IP is in my hosts allow list in the smb.cnf but still not working...
[12:07] <ikonia> can you telnet to the port
[12:07] <ikonia> test the port is actually open and responding for you
[12:17] <DK2> ive a failed software raid1 with two disk where the first hdd is broken
[12:18] <DK2> but the system cant boot via the second disk
[12:18] <DK2> does a simple grub install on sdb solve the problem?
[12:33] <ikonia> define cannot boot
[12:33] <ikonia> has no grub - or has grub but won't boot
[14:01] <ddellav> zul coreycb working on heat b1
[14:02] <zul> pk
[14:18] <ddellav> zul coreycb neutron-fwaas and heat done: lp:~ddellav/ubuntu/+source/neutron-fwaas lp:~ddellav/ubuntu/+source/heat
[14:18] <ddellav> zul coreycb taking keystone b1
[14:21] <zul> ack
[14:22] <zul> ddellav: ill take nova when im done with this
[14:22] <ddellav> zul ack
[14:33] <jgrimm> caribou, is 1614052 still on your radar?
[14:34] <caribou> LP: #1614052
[14:34] <caribou> jgrimm: this is fixed in the latest sosreport as far as I remember
[14:34] <jgrimm> caribou, that's my read, justs needs SRUing
[14:34] <ddellav> zul coreycb neutron-lbaas and keystone done lp:~ddellav/ubuntu/+source/keystone lp:~ddellav/ubuntu/+source/neutron-lbaas
[14:35] <caribou> jgrimm: I'm working on pushing the latest sosreport as we speak but just found a last-minute bug while runningn autopkgtest
[14:35] <caribou> jgrimm: so I just pushed a fix upstream & hopefully will be able to SRU soon
[14:35] <caribou> jgrimm: I'll update the bug
[14:35] <ddellav> zul coreycb i'll take neutron-dynamic-routing
[14:35] <jgrimm> caribou, thanks! would be nice to get that one off the books
[14:41] <ddellav> zul whats the best practice for updating debian packages now that the repo's aren't on alioth?
[14:41] <zul> coreycb: ^^^
[14:41] <zul> ddellav: but https://github.com/coreycb/pkg-scripts
[14:42] <coreycb> ddellav, most of the openstack deps are now on ubuntu-server-dev.  if there's one missing let me know and I can create it.
[14:43] <ddellav> coreycb zul ok thanks
[14:43] <coreycb> ddellav, we still want to submit patches back to debian to minimize our delta though.  you can use submittodebian or you can submit patches using openstack gerritt.
[14:43] <ddellav> coreycb ok
[14:43] <jge> hey all good morning, anyone know why when I run something like 'find / -name file.name' i get a bunch of permission denied messages for a multitude of files when running as root in 16.04?
[14:43] <jge> fresh install
[14:43] <zul> coreycb: it doesnt help that there is no ocata branches yet
[14:46] <coreycb> zul, ddellav, right, i agree.  so maybe just use submittodebian until zigo has branches set up for ocata.
[15:03] <coreycb> ddellav, neutron-lbaas and neutron-fwaas pushed/uploaded
[15:05] <ddellav> coreycb ack
[15:27] <coreycb> ddellav, zul, i wonder if we can just drop keystone.conf.dist and setup-keystone-config.sh and just install the default generated keystone.conf
[15:28] <ddellav> coreycb the keystone.conf in the debian directory is the apache config fyi. The sample that gets installed is in etc/keystone.sample.conf
[15:28] <coreycb> ddellav, right, so debian/keystone.conf is different
[15:28] <ddellav> right
[15:29] <coreycb> ddellav, but the defaults that are generated by the above 2 files, are they neeed?
[15:29] <coreycb> needed
[15:29] <zul> coreycb: we should probbably rename it so we dont get confused
[15:30] <ddellav> coreycb i don't know if they are needed. I just took the directives from the sample config and put them in the dist. I imagine it makes it easier to handle config file format changes from upstream to insert the directive values on build
[15:36] <coreycb> ddellav, i think if the service starts with the default config then we don't need to modify it.
[15:37] <coreycb> ddellav, we can probably also drop debian/logging.conf and install etc/logging.conf.sample instead
[15:37] <coreycb> zul, yeah might make sense to rename that
[16:02] <jge> hey all, anyone know where the tomcat8.service file is on ubuntu 16.04 ? nothing inside of /etc/systemd/system/
[16:07] <Seveas> jge: there seems to be no such file (though I checked on 16.10 instead of 16.04)
[16:07] <Seveas> it has an oldfashioned initscript :)
[16:08] <andol> A more general answer: systemctl cat tomcat8.service
[16:10] <jge> Oh ok, I see the init script
[16:12] <jge> thanks guys
[16:16] <jge> Seveas and andol: how could I make it so a variable say, JAVA_OPT  inside an init script points to a file instead of putting it there
[16:41] <Seveas> jge: most initscripts source a file from /etc/default, where you can put such things
[16:41] <Seveas> disclaimer: I didn't check the tomcat initscript if it supports this :)
[16:51] <zul> coreycb: ping
[16:51] <zul> coreycb: so we dont have senlin/watcher in ci, maybe we should?
[16:51] <zul> coreycb: just to make sure this is buildable
[17:23] <coreycb> zul, they are just synced from debian
[17:23] <zul> coreycb: ok im just concerned that debian is behind again
[17:26] <coreycb> zul, in that regard yes, let's just focus on the core packages for b1 and sync anything from debian once it's available
[17:26] <zul> ok
[17:26] <zul> coreycb: my ocd was kickiing in but meh
[18:18] <zul> coreycb: i havent gotten to package installs yet ;)
[22:03] <coreycb> ddellav, forgot about keystone for a bit there.. it's pushed/uploaded.  i dropped those couple of files I mentioned earlier and installed logging.conf.sample.
[22:41] <docmur> I have a program I wrote, here is a sample: http://pastebin.com/rQYyCxVX which bootstraps 16.04.1 into a server and then runs an install script to get applications + kernel and then installs grub.  If I run the scripts myself, then chroot into the direct /mnt/destination and execute ./install.sh again, myself, and reboot, it works.  If I just run this program, when I reboot I get a kernel panaic
[22:41] <docmur> that it can't find init=, why would this program fail, yet when I run it manually it works :S
[22:43] <sarnold> docmur: yikes, does C# -really- let you pass multiple arguments to a program in one string like that?
[22:43] <docmur> yep
[22:44] <docmur> I'm assuming the problem has to be with chroot /mnt/destination bash install.sh
[22:48] <rattking> docmur: I do things in a very similar way.. but I call it like "chroot /mnt/target /path/to/script.sh"
[22:48] <rattking> script.sh is +x and has bash in the #!
[22:49] <docmur> so does mine, I'm going to remove bash and try it again
[22:49] <sarnold> is there a bash in your chroot?
[22:49] <sarnold> does it have all the libraries it needs to function in the chroot? devices?
[22:50] <rattking> or maybe you need more quoting like "/mnt/destination 'bash install.sh'"
[22:51] <docmur> I can see install.sh execute, it does what I need it to do, so it's running it
[22:52] <rattking> maybe you can make that #! bash -x and send the output to a log
[22:53] <docmur> good idea :)
[22:57] <rattking> I have to take off. good luck
[22:58] <docmur> kk thanks!