**** BEGIN LOGGING AT Tue Oct 13 02:59:59 2015
Oct 13 03:25:06 <namra> greetings
Oct 13 03:25:39 <namra> is it possible to change a machine configuration value via a .bbappend file?
Oct 13 03:26:03 <namra> don't like to fiddle around in the mate/conf/machine configs
Oct 13 03:27:16 <namra> or do i need to create a custom machine image?
Oct 13 07:05:47 <bluelightning> morning all
Oct 13 07:32:02 <mckoan> good morning bluelightning, all
Oct 13 07:32:11 <bluelightning> morning mckoan
Oct 13 08:04:56 <parrot> good morning all :-)
Oct 13 08:09:41 <bluelightning> morning parrot
Oct 13 09:37:18 <lpapp> good morning
Oct 13 09:40:58 <lzm> the opkg in my board knows about a qt4-x11-free_4.8.6_r0.1 from earlier installations, but i want to install a _r0.0 that i just built. "opkg install qt4-x11-free" always tries to get the r0.1 version, even though it doesnt exist in my repository. what can i do to force it to install r0.0?
Oct 13 09:49:25 <fredcadete> I've never used opkg, only ipkg
Oct 13 09:49:50 <fredcadete> but when I did what you are describing, I told the tool to install the *.ipk file directly
Oct 13 09:50:07 <fredcadete> then I still have the package repo to go back to the previous state if I want to
Oct 13 09:50:46 <fredcadete> and of course, you may have to use the force
Oct 13 09:53:37 <lpapp> fredcadete: opkg is the package manager's name and ipk is the extension :)
Oct 13 09:54:02 <lzm> the package depends on other packages, if i try to install the r0.0.ipk directly it still tries to fetch r0.1 dependencies, which dont exist
Oct 13 09:55:01 <fredcadete> lpapp: yeah, that's the case for yocto :) in the somewhat old system I used, the tool was called ipkg
Oct 13 09:55:16 <lpapp> interesting
Oct 13 09:55:32 <rburton> correct, ipkg was forked to opkg
Oct 13 09:56:36 <fredcadete> lzm: that's messed up
Oct 13 09:57:11 <rburton> lzm: force remove qt4-x11-free, update, install
Oct 13 09:57:28 <lzm> i have no qt packages installed anymore, removed them all
Oct 13 09:57:47 <lpapp> I should read upon this fork
Oct 13 09:58:56 <rburton> ipkg was dead, opkg was forked to fix it
Oct 13 09:59:23 <rburton> the o stands for openmoko
Oct 13 10:00:08 <lpapp> i stands for?
Oct 13 10:00:20 <lpapp> Itsy
Oct 13 10:01:09 <fredcadete> lzm: the dependencies of your package need to be satisfied in some way. Do you want it to take r0.0 or r0.1 for those dependencies? What is your package repo providing?
Oct 13 10:01:29 <lpapp> they claim open package management in here: https://en.wikipedia.org/wiki/Opkg
Oct 13 10:02:37 <lzm> fredcadete: my package repo provides r0.0 for all qt libraries, i want to install 0.0
Oct 13 10:02:56 <lpapp> is there a way to look for installed packages like this with opkg? opkg-root list-installed foo\|bar
Oct 13 10:03:04 <lpapp> I would like to look for two patterns in one go.
Oct 13 10:03:20 <lpapp> I could probably work it around with grep 'foo\|bar' should there be no solution to this.
Oct 13 10:04:11 <fredcadete> lzm: did you rebuild your package index? Is your qt4-x11-free package specifying a minimum version for its dependencies?
Oct 13 10:05:26 <rburton> lpapp: meh, we forked it for openmoko, and everything openmoko was o-prefixed
Oct 13 10:07:34 <lzm> fredcadete: i did rebuild it, it does not specify a minimum version
Oct 13 10:08:41 <fredcadete> lzm: I fold :\
Oct 13 10:09:27 <lzm> yeah, i think my options are to either reflash the board, or recompile qt4 and bump the version to 0.1
Oct 13 10:09:56 <JaMa> rburton: I've noticed that you merged my force ARM mode change to master, what about the other 3 changes like this which were sent earlier (couple months ago)?
Oct 13 10:09:59 <JaMa> pick a238e64 gdb: force arm mode
Oct 13 10:10:01 <JaMa> pick d5cee6a icu: force arm mode
Oct 13 10:10:04 <JaMa> pick 4a74e96 guile, mailx, gcc, opensp, gstreamer1.0-libav, libunwind: disable thumb where it fails for qemuarm
Oct 13 10:10:11 <rburton> hm
Oct 13 10:10:41 <rburton> JaMa: i'll see if i can find them, but i do think fixing valgrind will fix some of those too
Oct 13 10:10:46 <JaMa> will you merge them if I update the actuall error log with link to errors?
Oct 13 10:10:52 <lzm> is there a way to build new qt4 packages without recompiling it all? it takes hours for me
Oct 13 10:11:10 <rburton> JaMa: that would be appreicated anyway :)
Oct 13 10:11:55 <JaMa> rburton: all 3 are linked from https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717
Oct 13 10:11:58 <lpapp> lzm: qt 4... hmm, why not 5?
Oct 13 10:11:59 <yocti> Bug 7717: normal, Medium, 2.1, denis, NEW , build issues with Thumb-1, when building for qemuarm (armv5te)
Oct 13 10:12:10 <JaMa> DateJuly 15, 2014, 6:30 p.m.
Oct 13 10:12:15 <JaMa> couple months ago :)
Oct 13 10:12:28 <rburton> we should probably add a thumb build to the autobuilder?
Oct 13 10:12:44 <rburton> how does one turn it on?
Oct 13 10:13:03 <JaMa> yes, that's what I've suggested in http://patchwork.openembedded.org/patch/75817/
Oct 13 10:13:15 <lzm> lpapp: qt5 is not a drop in replacement for 4
Oct 13 10:13:29 <JaMa> rburton: see last 3 lines in http://logs.nslu2-linux.org/buildlogs/oe/world/log.world.20151008_105254.log/world_fixes.inc
Oct 13 10:13:43 <rburton> thanks
Oct 13 10:14:15 <lpapp> lzm: that is correct
Oct 13 10:14:43 <lzm> so the reason is legacy apps :)
Oct 13 10:16:25 <lpapp> yeah, it is a shame, isn't it
Oct 13 10:57:44 <simonl> Any suggestions for how to deal with slightly different boards? I think the MACHINE infrastructure seems a bit heavy handed for what basically amounts to a different device tree and a configuration file.
Oct 13 10:58:38 <simonl> Specify multiple device tree files and make separate image recipes for different boards?
Oct 13 11:02:36 <LetoThe2nd> depends how the devicetree files have to be used
Oct 13 11:02:53 <LetoThe2nd> if they're not included in the image for example, no need to make seperate images :)
Oct 13 11:41:07 <simonl> LetoThe2nd: They're not, but the config files would be.
Oct 13 11:41:45 <LetoThe2nd> simonl: well if you need different images, there's no way around creating different images. and then MACHINE is the correct way to do it.
Oct 13 11:41:56 <simonl> One thing I worry about a little is how the device tree could be updated. So far we don't think we need to, but we have that part of the flash writable just in case. I'd need to figure out which device tree to write during updates
Oct 13 11:42:37 <LetoThe2nd> it all depends on your update process.
Oct 13 11:43:11 <simonl> LetoThe2nd: Ok. Reading the manual, it seems that would include entirely separate build directories, package feeds, etc. I was hoping to just get one additional machine specific feed. Is that possible?
Oct 13 11:43:23 <simonl> that=the MACHINE approach
Oct 13 11:44:12 <LetoThe2nd> um, you should be able to MACHINE=xyz bitbake whatever-image to reuse the whole structure, basically.
Oct 13 11:45:12 <LetoThe2nd> and if the rest of the arch and all is identical, you can always have a look at how angstrom handles it, basically
Oct 13 11:45:34 <simonl> LetoThe2nd: Ok. I guess I'm not quite comfortable with what can be changed config-wise yet. But that sounds like what I want, assuming it works ^^
Oct 13 11:45:52 <simonl> let me look up the angstrom bit
Oct 13 11:45:54 <LetoThe2nd> as always, verify that it really does what you want
Oct 13 11:47:06 <LetoThe2nd> theoretically you could even set MACHINE to an invalid or null value in local.conf to force passing in a specifc one through the command line. at least I assume that.
Oct 13 11:47:08 <simonl> LetoThe2nd: Got it!
Oct 13 11:47:45 <simonl> ah, that'd be good if we go that route
Oct 13 11:49:00 <LetoThe2nd> but again, it really depends a lot on your build process and requirements.
Oct 13 11:54:36 <simonl> LetoThe2nd: I'll have to think it through after reading a bit, I guess. Thanks a ton for the pointers!
Oct 13 11:54:43 <LetoThe2nd> have fun!
Oct 13 11:54:59 <simonl> will do!
Oct 13 12:01:58 <simonl> A second, not quite related question about writing recipes: Can I find out in a post-inst script if it is the first boot or not?
Oct 13 12:05:54 <bluelightning> simonl: you can find out if it's running at image construction time or not, but I don't believe there's a distinction between first boot and subsequent package installation
Oct 13 12:06:01 <bluelightning> maybe you meant the former?
Oct 13 12:06:27 <bluelightning> if so, $D is only set when building the image
Oct 13 12:07:15 <simonl> bluelightning: I actually think I need the former. We have a patched systemd bbclass, where we disable the systemctl restart ... line since it is incompatible with our update strategy
Oct 13 12:07:46 <simonl> problem is, for packages that need to run the script on the machine, the service is not started on first boot because of that
Oct 13 12:08:30 <simonl> bluelightning: err, I think I actually need to distriguish between first boot/update
Oct 13 12:08:44 <bluelightning> I don't know of a means to do that
Oct 13 12:09:27 <simonl> bluelightning: ok. Thanks anyway, I think for specific cases we can work around it, but it would be nice to fix it generally.
Oct 13 13:14:49 <raykinsella78> how do I do complete rebuild of sysroot, have changed init systems and I don't want to do an rm -rf tmp
Oct 13 13:15:45 <bluelightning> raykinsella78: rm -rf tmp is really what you want - anything already built that hasn't changed will be restored from the sstate-cache
Oct 13 13:18:34 <raykinsella78> ok ... haven't setup sstate yet ... can I copy it out of tmp before the rm and set the variable?
Oct 13 13:23:44 <bluelightning> raykinsella78: there's no need to set up sstate, it's on automatically
Oct 13 13:23:57 <bluelightning> raykinsella78: you'll see there is an sstate-cache directory there already
Oct 13 13:24:36 <rburton> if you put it in tmp, then move the directory out and change the variable in local.conf
Oct 13 13:25:38 <raykinsella78> ok dokey ... thanks folks
Oct 13 13:37:24 <raykinsella78> WTF
Oct 13 13:37:25 <raykinsella78> conf/distro/include/iot-devkit.inc:SSTATE_DIR ?= "${TOPDIR}/../devkit-cache/sstate-cache"
Oct 13 13:37:38 <raykinsella78> A layer is setting my SSTATE_DIR
Oct 13 13:56:27 <qknight> ERROR: qt3d-tools not found in the base feeds (raspberrypi arm1176jzfshf-vfp armv6hf-vfp armv5ehf-vfp armv5hf-vfp noarch any all).
Oct 13 13:57:16 <qknight> this is what i get with meta-qt5 and if i add http://patches.openembedded.org/patch/52957/ <- ALLOW_EMPTY_${PN} = "1" it goes away for qt3d but then, as in the error message, i get it for qt3d-tools
Oct 13 14:21:01 <bboozzoo> raykinsella78: I suggest using site.conf for setting SSTATE_DIR (and probably other settings like DL_DIR and so on)
Oct 13 14:22:12 <bboozzoo> and ?= is just a default, your local settings should override it
Oct 13 14:32:21 <bluelightning> bboozzoo: not if he has used ?= to set it in his local.conf
Oct 13 14:33:32 <bboozzoo> bluelightning: IIRC he said that it's set by ?= in distro conf, will that have a lower priority than local.conf/site.conf?
Oct 13 14:37:06 <bluelightning> depends on where that inc file is included
Oct 13 14:40:29 <bboozzoo> bluelightning: do you know where I could find some information on the order in which assignments are done? I tried to look that up once in bitbake manual but came up empty, so I just keep on checking -e just if there's something particularly bothering me
Oct 13 14:42:06 <bluelightning> bboozzoo: bitbake -e | less is the best way to find that out
Oct 13 14:42:16 <bluelightning> shows full history for every variable
Oct 13 14:43:49 <Ox4b> hello everyon
Oct 13 14:43:58 <t0mmy> "?=" to assign the value, if it is not already assigned, maybe you should be used "=" in your distro.conf. You can  also use bitbake -e <recipe>|tee .... to check variables assignment.
Oct 13 14:45:46 <Ox4> http://dpaste.com/3YZH1B5 could somebody help me with this one?
Oct 13 14:45:57 <bboozzoo> bluelightning: so far it looks like auto.conf outranks all, then comes the site.conf, local.conf, followed by distro config and machine config, does that sound reasonable?
Oct 13 14:47:04 <bluelightning> bboozzoo: "outranks" isn't how I would put it; if you consider setting a variable with = then the last one wins, not the first...
Oct 13 14:48:27 <t0mmy> 0x4: check all variables named FILES_${PN} of your recipes
Oct 13 14:49:31 <Ox4> t0mmy: http://dpaste.com/03CSR95 here is the recipe
Oct 13 14:51:38 <t0mmy> I think, you can start to add FILES_${PN}-dbg for files in the folder .debug
Oct 13 14:52:59 <Ox4> t0mmy: and append .debug/<filename> to this variable?
Oct 13 14:53:13 <Ox4> t0mmy: what about found library in wrong location?
Oct 13 14:56:55 <challinan> anyone know of a modern version of parted (or better alternative) that actually works for automating partition tasks?
Oct 13 14:56:59 <Ox4> t0mmy: http://dpaste.com/1F70Q6H omg
Oct 13 14:58:26 <Ox4> t0mmy: I've just appended this one: http://dpaste.com/2EH26B3
Oct 13 15:00:54 <bboozzoo> bluelightning: found the order in which the files are included in meta/conf/bitbake.conf :) so basically if a variable is assigned by =, then ?= is a noop, similarly for ?= and ??=
Oct 13 15:01:20 <bluelightning> yes
Oct 13 15:04:06 <Ox4> guys, could somebody help me: http://dpaste.com/2G0ZMD3 ?
Oct 13 15:09:24 <bboozzoo> Ox4: /usr/powerbeacon/lib/.debug/libConfigManager.so.1.0.0 these should go to FILES_${PN}-dbg
Oct 13 15:11:14 <bluelightning> the symlink .so needs to go to ${PN}-dev
Oct 13 15:11:36 <bboozzoo> Ox4: also /usr/powerbeacon/lib/libConfigManager.so.1.0.0 is not an expected location for libraries, if you really have to put everythin under /usr/powerbeacon prefix, you'll need to adjust PATH and /etc/ld.so.conf most probably
Oct 13 15:11:49 <Ox4> bboozzoo: but then I am receving such log: http://dpaste.com/2S2XSS8
Oct 13 15:12:36 <bluelightning> Ox4: use += not =
Oct 13 15:12:53 <Ox4> bboozzoo: where shoud I set PATH?
Oct 13 15:13:11 <Ox4> bluelightning: thanks
Oct 13 15:16:40 <bboozzoo> Ox4: you can set a system wide PATH for shells in /etc/profile, but that's for the shell *only*
Oct 13 15:17:42 <Ox4> bboozzoo: do you mean on my host?
Oct 13 15:18:18 <Ox4> well, now I have this one: http://dpaste.com/2AVJFXH
Oct 13 15:18:33 <bboozzoo> Ox4: no, I meant your target's rootfs
Oct 13 15:19:24 <Ox4> bboozzoo: ah, I set it in rcS script
Oct 13 15:21:23 <Ox4> bluelightning: could you please tell me more about .so symlink?
Oct 13 15:22:04 <bluelightning> Ox4: I assume /usr/powerbeacon/lib/libConfigManager.so is a symlink
Oct 13 15:22:13 <bluelightning> Ox4: that is only there for development purposes
Oct 13 15:22:24 <bluelightning> Ox4: hence it should go into the -dev package
Oct 13 15:24:11 <Ox4> bluelightning: yes
Oct 13 15:24:14 <Ox4> lrwxrwxrwx 1 vadimi vadimi       25 Oct 12 13:14 libConfigManager.so.1 -> libConfigManager.so.1.0.0
Oct 13 15:24:14 <Ox4> lrwxrwxrwx 1 vadimi vadimi       25 Oct 12 13:14 libConfigManager.so.1.0 -> libConfigManager.so.1.0.0
Oct 13 15:25:09 <bluelightning> Ox4: those are the versioned symlinks, that's not what I was talking about
Oct 13 15:26:19 <bluelightning> libConfigManager.so
Oct 13 15:28:19 <Ox4> bluelightning: yes, it helped. Thank you
Oct 13 15:28:24 <Ox4> what about warning?
Oct 13 15:28:36 <Ox4> can I remove it somehow?
Oct 13 15:29:43 <bluelightning> Ox4: which one?
Oct 13 15:32:14 <Ox4> bluelightning: http://dpaste.com/0RFPZ70
Oct 13 15:33:26 <bluelightning> Ox4: I guess INSANE_SKIP_${PN} += "libdir"
Oct 13 15:34:26 <Ox4> hm
Oct 13 15:34:31 <Ox4> ok, I will try
Oct 13 15:40:27 <Ox4> bluelightning: it didn't help
Oct 13 15:40:53 <Ox4> bluelightning: http://dpaste.com/0X7QJMF
Oct 13 15:41:21 <bluelightning> Ox4: add also INSANE_SKIP_${PN}-dbg += "libdir"
Oct 13 15:45:01 <Ox4> bluelightning: thanks
Oct 13 15:45:43 <Ox4> bluelightning: if I remove debug package I also have to remove FILES_{PN}-{dbg,dev} from the recipe, right?
Oct 13 15:46:40 <bluelightning> Ox4: when you say "remove debug package" what do you mean?
Oct 13 15:47:07 <Ox4> bluelightning: I mean when I remove debug-tweaks from local.conf
Oct 13 15:47:46 <bluelightning> well, no, because debug-tweaks has no bearing on whether debug symbols are split and stripped from binaries
Oct 13 15:49:08 <kergoth> does anyone recall the history behind the duplication between OECORE_TARGET_SYSROOT and SDKTARGETSYSROOT in the sdk env scripts?
Oct 13 15:59:46 <raykinsella78> ERROR: Function failed: Fetcher failure for URL: 'http://kernel.org/pub/software/utils/pciutils/pciutils-3.2.1.tar.bz2'. Unable to fetch URL from any source.
Oct 13 15:59:49 <raykinsella78> hum ..
Oct 13 16:00:20 <raykinsella78> strange its on kernel.org
Oct 13 16:01:23 <raykinsella78> autoredirect to https causing it.
Oct 13 16:03:46 <kergoth> bluelightning: damn, i think devtool-extract fails if given a provide like virtual/kernel, have you tried that? I wonder if it needs https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/lib/recipetool/kernel.py#L55-L62 -- probably we need something similar for a lot of the recipetool and devtool commands, actually, most seem to expect PN specifically
Oct 13 16:03:48 <kergoth> hmm
Oct 13 16:04:02 <kergoth> i think there's value in being able to: devtool extract virtual/kernel src/kernel
Oct 13 16:04:06 <kergoth> for example
Oct 13 16:04:11 * kergoth ponders
Oct 13 16:04:44 <bluelightning> hmm yes I had considered that earlier and never got much further than that...
Oct 13 16:04:55 <bluelightning> it blows up somewhat...
Oct 13 16:06:59 <kergoth> I'll open a yocto enhancement bug about it
Oct 13 16:17:00 <otavio> RP: can you include the image.py patch in master-next for test please?
Oct 13 16:38:14 <kergoth> Does anyone know if it's possible to disable the linux-yocto scripts branch validation process?
Oct 13 16:39:26 <kergoth> ah, maybe i could just noexec the task..
Oct 13 16:40:18 <kergoth> ah, no, that's what does the checkout, that won't do
Oct 13 16:40:33 <kergoth> it's not the branch validation i want to bypass, it's the checking of the dependent branches
Oct 13 16:40:41 <kergoth> hmm
Oct 13 16:40:56 <Crofton|work> zeddii, ?
Oct 13 16:40:59 <armpit> what about KCONF_BSP_AUDIT_LEVEL = "0"
Oct 13 16:42:36 <armpit> that fix a QA message for a machine when its not in the meta branch
Oct 13 16:44:58 <zeddii> -ENOCONTEXT or -ETHEDAYAFTERTHANKSGIVING
Oct 13 16:46:20 <armpit> _append_EH
Oct 13 16:47:51 <raykinsella78> folks where can I find an example reciepe for a kernel module?
Oct 13 16:53:50 <raykinsella78> poky/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb ... :-)
Oct 13 17:00:21 <raykinsella78> signing off
Oct 13 17:10:18 <Ox4> kergoth: can I use ${EXTERNAL_TOOLCHAIN} which is set in my local.conf and pointed to sourcery toolchain in EXTRA_OEMAKE variable?
Oct 13 17:22:37 <kergoth> you *could*, but that's really really not a good idea
Oct 13 17:22:38 <kergoth> why would you?
Oct 13 17:23:57 <Ox4> I have very ubly Makefile
Oct 13 17:24:09 <kergoth> that doesn't really make sense.
Oct 13 17:24:23 <kergoth> anything from EXTERNAL_TOOLCHAIN, e.g. libs, headers, etc are already pulled out of there and put into the oe/yocto sysroots
Oct 13 17:24:27 <Ox4> kergoth: http://dpaste.com/2WXR17R
Oct 13 17:24:28 <kergoth> there's no reason to point to it directly
Oct 13 17:24:53 <Ox4> kergoth: so I just need to use ${CC}?
Oct 13 17:25:11 <kergoth> wow, that's a lot of terrible hardcoded madness. the toolchain handles its own search paths, there's zero reason to specify those explicitly
Oct 13 17:25:18 <Ox4> yes :-(
Oct 13 17:25:32 <kergoth> I'd say just drop all the -L/-I which reference TOOLCHAIN_DIR, patch it out
Oct 13 17:25:42 <kergoth> it's all pointless
Oct 13 17:26:02 <kergoth> -isystem too, none of it's needed
Oct 13 17:26:04 <Ox4> kergoth: what is the best point? Just to edit this Makefile with sed?
Oct 13 17:26:19 <Ox4> ok
Oct 13 17:26:45 <kergoth> The only reason I could see for them to be doing that is if they pass a custom --sysroot= and that sysroot doesn't include teh files that in the toolchain itself
Oct 13 17:26:50 <kergoth> even in that case, they're doing it badly
Oct 13 17:27:32 <kergoth> and obviously we don't do that, so. i'd drop into a devshell, quilt new no_toolchain_dir.patch; quilt edit Makefile; # make your changes, then quilt refresh, copy that patch out to the appropriate place in a layer and add to SRC_URI
Oct 13 17:28:05 <Ox4> ok, thank you
Oct 13 17:29:05 <Ox4> kergoth: what about KERNEL_DIR?
Oct 13 17:29:23 <Ox4> kergoth: just pass it through the EXTRA_OEMAKE?
Oct 13 17:30:01 <kergoth> yep, that'd be best
Oct 13 17:30:41 <Ox4> so I have to delete everything from that Makefile :D
Oct 13 17:30:58 <bluelightning> won't -E override a bunch of this anyway ?
Oct 13 17:31:17 <bluelightning> sorry, -e
Oct 13 17:32:14 <Ox4> http://dpaste.com/0SDQV9N
Oct 13 17:32:24 <Ox4> mcpu error
Oct 13 20:27:21 <kergoth> damn, a patch failed to apply in the linux-yocto build when using a shallow repo
Oct 13 20:27:23 * kergoth digs
Oct 13 22:43:00 <kergoth> Hmm, I wonder if I should rework how the shallow git tarball repositories are constructed somewhat
Oct 13 23:12:49 <nerdboy> anybody got a link for oe vs debian arm comparison?
Oct 13 23:13:04 * nerdboy notes google is less than helpful today...
Oct 13 23:14:16 <nerdboy> hmm, found something on intel.com...
Oct 13 23:16:07 <nerdboy> nope, just somebody complaining
Oct 13 23:41:03 <khem> nerdboy: what are you looking for specifically ?
Oct 14 00:02:11 <nerdboy> a quickie point/counterpoint sort of thing
Oct 14 00:02:43 <nerdboy> developing for a small arm no fpu with debian vs oe
Oct 14 00:03:17 * nerdboy needs to convince someone they need to look at reqs not just do it "because"
Oct 14 00:18:26 <nerdboy> found something on slideshare
Oct 14 00:18:35 * nerdboy looking...
Oct 14 00:41:40 <nerdboy> ross's slides from way back apparently
Oct 14 00:42:21 <nerdboy> nice but the notes are cut off instead of wrapped in the pdf...  :/
**** ENDING LOGGING AT Wed Oct 14 02:59:59 2015