**** BEGIN LOGGING AT Tue Jul 28 02:59:58 2015
Jul 28 04:28:31 <CyanoticAxolotl> trying to run a QEMU session but it panics, dunno what's wrong http://i.imgur.com/nbMKgsR.png
Jul 28 04:29:45 <CyanoticAxolotl> if you're wondering i'm running arch linux, all the bitbake stuff ran successful, and i'm doing x86-64 Intel Ivy Bridge to x86-64 QEMU session.
Jul 28 04:52:40 <CyanoticAxolotl> ah i see
Jul 28 04:52:44 <CyanoticAxolotl> hm
Jul 28 05:02:52 <CyanoticAxolotl> fixed it i think
Jul 28 05:02:56 <CyanoticAxolotl> yep
Jul 28 05:03:01 <CyanoticAxolotl> i fixed it
Jul 28 06:14:10 <miandonmenmian__> where does opkg list get the list from ?
Jul 28 06:26:12 <neverpanic> miandonmenmian__: /var/lib/opkg/status
Jul 28 06:27:02 <neverpanic> or rather /var/lib/opkg, status probably only for opkg list-installed
Jul 28 07:05:02 <miandonmenmian__> thanks!
Jul 28 07:45:09 <bachp> Is anybody using Qt4.8 in combination with CMake? It seems that when I do "inherit cmake qt4e" cmake is picking up the Qt libraries from the native sysroots. Befor I spend to much time searching the root cause I wanted to ask if somebody has any hints on this.
Jul 28 08:05:37 <mckoan> good morning
Jul 28 08:21:54 <bachp> morning
Jul 28 08:26:26 <bluelightning> morning all
Jul 28 10:26:11 <Ox4> good day everyone
Jul 28 10:26:26 <Ox4> where does yocto store fetched souce code?
Jul 28 10:26:45 <Ox4> I just performed bitbake -c fetch package and don't see it anywhere
Jul 28 10:28:11 <bluelightning> Ox4: whereever DL_DIR is set to (by default, build/downloads)
Jul 28 10:41:58 <Ox4> bluelightning: as I see here build/tmp/work/cortexa8-vfp-neon-poky-linux-gnueabi/powerbeacon-app/1.0-r0/git yocto uses previouse commit and not that commit where actually HEAD points to
Jul 28 10:42:53 <bluelightning> Ox4: what is your SRCREV set to ?
Jul 28 10:45:05 <Ox4> bluelightning: oh, it points to wrong branch. Thank you
Jul 28 10:45:37 <bluelightning> Ox4: branch= in SRC_URI should specify the branch; if you want to track HEAD of the branch, you need to set SRCREV = "${AUTOREV}"
Jul 28 10:46:00 <bluelightning> otherwise SRCREV should be set to a fixed revision
Jul 28 10:49:08 <Ox4> bluelightning: currently I have branch=develop_test and SRCREV = "develop"
Jul 28 10:49:15 <Ox4> that was mistake
Jul 28 10:49:42 <Ox4> I think I have to set SRCREV to ${AUTOREV} to avoid such mistakes
Jul 28 10:50:01 <bluelightning> if you want it to always check and fetch the latest HEAD on that branch, yes
Jul 28 10:50:57 <Ox4> thank you
Jul 28 10:51:31 <Ox4> bluelightning: btw, which is more correct way to cleanup build? Currently I am using bitbake -c cleanall package
Jul 28 10:52:13 <bluelightning> -c cleanall will delete all files including the ones fetched during do_fetch
Jul 28 10:52:21 <bluelightning> -c cleansstate will delete the work files and the sstate cache
Jul 28 10:52:27 <bluelightning> -c clean will just delete the work files
Jul 28 10:53:03 <bluelightning> (well, all will delete the work files and remove items staged to the sysroot)
Jul 28 10:53:15 <bluelightning> all of those options, I mean
Jul 28 10:56:45 <miandonmenmian__> is dbus the standard inter process communication method for yocto ?
Jul 28 10:57:18 <bluelightning> miandonmenmian__: we don't really have a standard specific to the Yocto Project
Jul 28 10:57:35 <bluelightning> dbus is available, as are many other options
Jul 28 10:57:59 <miandonmenmian__> where should i look for notifications on yocto for network ?
Jul 28 11:03:19 <Ox4> bluelightning: so if I want yocto re-fetch sources I have to use cleanall, right?
Jul 28 11:04:09 <bluelightning> Ox4: with SRCREV = "${AUTOREV}" no, it'll happen automatically
Jul 28 11:04:54 <bluelightning> Ox4: also fetching will happen if you edit the recipe and change SRC_URI, SRCREV or other variables that influence do_fetch, or if you modify any local files referenced by SRC_URI
Jul 28 11:05:43 <Ox4> bluelightning: so I don't have to perform clean at all?
Jul 28 11:06:19 <bluelightning> Ox4: in most cases you shouldn't have to no
Jul 28 11:07:01 <Ox4> understood, thank you
Jul 28 11:10:29 <Ox4> one more question
Jul 28 11:10:44 <Ox4> how can I modify init scripts for the future image?
Jul 28 11:10:50 <Ox4> just patch them?
Jul 28 11:26:46 <bluelightning> Ox4: it depends on where they come from - ultimately you need to use a bbappend for the recipe which packaged the initscript; if it is included in SRC_URI in the original recipe, you'll probably need to include your modified version of the file; otherwise if it came with the upstream source you'll need to patch it yes
Jul 28 11:54:14 <Ox4> hm
Jul 28 11:55:18 <Ox4> I've enable debugging symbols and tools-dbg and receiving the following: http://dpaste.com/2EX203B
Jul 28 11:56:12 <Ox4> can I just append gdb without server to IMAGE_INSTALL?
Jul 28 12:10:59 <bluelightning> Ox4: did you set DISTRO_FEATURES somewhere ?
Jul 28 12:15:09 <Ox4> bluelightning: nope
Jul 28 12:16:20 <Ox4> just set DISTRO_FEATURES_remove
Jul 28 12:16:56 <bluelightning> Ox4: oh, this is another meta-sourcery related issue no doubt
Jul 28 12:17:27 <Ox4> bluelightning: http://dpaste.com/2XBHYK4
Jul 28 12:17:30 <Ox4> hm
Jul 28 12:23:31 <Ox4> kergoth: hey, how can I build gdb and packages with debugging symbols using meta-sourcery?
Jul 28 13:19:16 <paulg_> anyone know what these are all about before I investigate myself?
Jul 28 13:19:18 <paulg_> WARNING: lib32-qt-mobility-x11: invalid PACKAGECONFIG: bluez5                                                                                                            | ETA:  00:00:11
Jul 28 13:20:09 <paulg_> seeing this one too ; just pulled everything 2m ago.
Jul 28 13:20:11 <paulg_> WARNING: Unable to get checksum for lib32-python-numpy SRC_URI entry _numpyconfig.h: file could not be found
Jul 28 13:54:42 <jeratz> writing a do_compile() in a recipe does replace a makefile right?
Jul 28 14:18:43 <bluelightning> paulg_: the latter one is probably because there's no _numpyconfig.h for the architecture you're building for
Jul 28 14:19:53 <paulg_> bluelightning, odd, since I'm buidling generic x86-64
Jul 28 14:21:08 <bluelightning> paulg_: that is indeed odd, because meta/recipes-devtools/python/python-numpy/x86-64/_numpyconfig.h exists
Jul 28 14:21:55 <bluelightning> I'm a bit confused about the _numpyconfig.h vs numpyconfig.h in that recipe
Jul 28 14:22:21 <bluelightning> oh wait, maybe this is to do with override ordering
Jul 28 14:22:24 <bluelightning> RP: ^
Jul 28 14:24:04 <bluelightning> there's definitely something strange going on there
Jul 28 14:28:44 <rburton> bluelightning: you touched it last! it's yours now!
Jul 28 14:28:55 <paulg_> bluelightning, RP - let me know if you need me to look sth up  in the build.
Jul 28 14:30:56 <bluelightning> rburton: ah, you see I am careful not to send a patch ;)
Jul 28 14:31:15 <rburton> bluelightning: 	for numpy looking counts as touching
Jul 28 14:31:26 <rburton> strange but true
Jul 28 14:31:26 <bluelightning> rburton: you wish ;)
Jul 28 14:35:05 <LocutusOfBorg1> hi folks, I'm getting the "tar corrupted octal value in tar header" error when flashing on an i.MX28
Jul 28 14:35:20 <LocutusOfBorg1> the strange fact is that the tarball is generated with ubuntu 14.04
Jul 28 14:35:35 <LocutusOfBorg1> the same repository with ubuntu 12.04 and 15.04 seems to be working
Jul 28 14:36:01 <LocutusOfBorg1> I took the tarball, extracted with tar xvf, recreated with tar cvf on my ubuntu 15.04 system and it works correctly
Jul 28 14:36:54 <bluelightning> LocutusOfBorg1: when you say "the" error, are you implying you've seen this mentioned before?
Jul 28 14:37:10 <LocutusOfBorg1> nope :)
Jul 28 14:37:53 <LocutusOfBorg1> anyway I suspected that the "tar" command was buggy on 14.04 and not on 12.04 and 15.04, so I downgraded it on the 14.04, taking the 12.04 version
Jul 28 14:37:59 <LocutusOfBorg1> I did a full rebuild
Jul 28 14:38:03 <LocutusOfBorg1> and nothing is solved
Jul 28 15:03:56 <paulg_> LocutusOfBorg1, it sounds like a bug in the tar on the flash deployment end of things, be it a busybox one, or ...
Jul 28 15:05:00 <paulg_> the fact that you can unbundle it and rebundle it and then it works makes me think the tar in the flashing end of things has some kind of fencepost bug that the happenstance layout of the 1st tarball triggers.
Jul 28 15:05:05 <LocutusOfBorg1> yes, seems that busybox is somewhere unable to open it
Jul 28 15:05:11 <LocutusOfBorg1> and I agree
Jul 28 15:05:24 <LocutusOfBorg1> the problem is: how is the tarball generated in yocto? with tar, right?
Jul 28 15:05:33 <LocutusOfBorg1> so, why downgrading tar didn't work?
Jul 28 15:05:42 <paulg_> do the two tarballs (working and non working) match in size?
Jul 28 15:06:22 <LocutusOfBorg1> -rw-rw-r--  1 locutus locutus 73809920 lug 28 15:52 asd.tar
Jul 28 15:06:40 <LocutusOfBorg1> -rw-r--r--  1 locutus locutus 73809920 lug 28 16:59 imx28-fallback.tar
Jul 28 15:06:42 <LocutusOfBorg1> yes
Jul 28 15:06:53 <LocutusOfBorg1> seems just some bit at the begin of the file
Jul 28 15:10:11 <paulg_> hexdump -C  each of them into a file and diff -u the two files ; see where tehy diverge.   Chances are once they diverge, they'll never reconnect, so ignore the bottom 99% of the diff.
Jul 28 15:12:12 <LocutusOfBorg1> the problem is that they diverge a lot, specially because my user is "locutus" and the other is "root"
Jul 28 15:12:16 <LocutusOfBorg1> I don't know why it is root
Jul 28 15:19:11 <bluelightning> LocutusOfBorg1: it'll be root because normally within the build system it will be assembled under pseudo
Jul 28 15:20:46 <paulg_> would be interesting to rebundle as root and see if the tar is still valid or not.
Jul 28 15:27:08 <aurelihein> Hello, I am trying to debug a buggy plugin of gstreamer, I am building an image with EXTRA_IMAGE_FEATURES += "debug-tweaks tools-debug " IMAGE_FEATURES += "dev-pkgs eclipse-debug" IMAGE_INSTALL += "kernel-dev" but I keep getting (no debugging symbols found) under almost all my library
Jul 28 15:27:13 <aurelihein> Thank you very much for your support
Jul 28 15:28:37 <LocutusOfBorg1> bluelightning, why on my build machine I see my uid and not root? do you use any fakeroot?
Jul 28 15:28:59 <bluelightning> LocutusOfBorg1: pseudo is effectively fakeroot++(+)
Jul 28 15:34:05 <bluelightning> fundamentally it's the same thing though, it tells programs running under it that they are running as root without them actually having any elevated privileges
Jul 28 15:40:30 <Ox4> kergoth: ping
Jul 28 15:56:00 <kergoth> Ox4: pong
Jul 28 15:56:47 <Ox4> kergoth: could you please tell me how to build gdb and packages with debugging symbols by meta-sourcery?
Jul 28 16:01:43 <kergoth> not sure what you mean by that. in oe/yocto recipes are always built withd ebugging symbols enabled, the packages get split out into -dbg, and you add those package sto an image with IMAGE_FEATURES += "dbg-pkgs". this is fully documented in the yocto manuals, and works fine with meta-sourcery and without, i build images like that regularly
Jul 28 16:02:12 <Ox4> kergoth: just a second
Jul 28 16:02:47 <kergoth> from local.conf, obviously that'd be EXTRA_IMAGE_FEATURES rather than IMAGE_FEATURES
Jul 28 16:02:54 <Ox4> kergoth: I set EXTRA_IMAGE_FEATURES = "debug-tweaks dbg-pkgs tools-debug"
Jul 28 16:03:24 <kergoth> and?
Jul 28 16:03:39 <Ox4> and receive the following error: http://dpaste.com/1JTX830
Jul 28 16:04:27 <Ox4> kergoth: also http://dpaste.com/0DXSV2S
Jul 28 16:06:14 <kergoth> the gdb thing isn't at all surprsiing, i explained why a couple days ago
Jul 28 16:06:25 <kergoth> you could deal with that via PREFERRED_PROVIDER_gdbserver = "gdb" in local.conf
Jul 28 16:06:35 <kergoth> i should document that in the layer readme
Jul 28 16:06:47 <kergoth> the glibc-mtrace issue, i have a local patch ready to push once I verify the fix, hold on a few
Jul 28 16:07:06 <Ox4> ok
Jul 28 16:07:16 <kergoth> unless you really need mtrace, you could add gdb to CORE_IMAGE_EXTRA_INSTALL and remove tools-debug from EXTRA_IMAGE_FEATURES as a temporary measure
Jul 28 16:09:26 <Ox4> ParseError: ParseError at /home/int/dev/leantegra/yocto/poky-4.5.1/build/conf/local.conf:146: unparsed line: 'PREFERRED_PROVIDER_gdbserver = "gdb'
Jul 28 16:09:35 <Ox4> ohmy
Jul 28 16:09:37 <Ox4> "'
Jul 28 16:10:03 <Ox4> sorry
Jul 28 16:11:27 <kergoth> fix your syntax error :)
Jul 28 16:14:46 <Ox4> http://dpaste.com/33RJXVZ
Jul 28 16:14:51 <Ox4> yes, I fixed it
Jul 28 16:19:08 <kergoth> did you clean after changing the provider? bitbake -c clean gdbserver-external
Jul 28 16:23:08 <Ox4> kergoth: actually I removed tmp dir :)
Jul 28 16:23:12 <Ox4> will see
Jul 28 16:23:34 <kergoth> With the preference set, gdbserver-external shouldn't be built at all, so that should resolve that piece of it
Jul 28 16:26:38 <ericbutters> hey! anyone used to meta-mono (or mono in generell) pls take a look at: http://lists.ximian.com/pipermail/mono-devel-list/2015-July/043142.html -- i really need help here. using mono_git.bb breaks mono on the target for me
Jul 28 16:29:18 <Ox4> kergoth: shoud I append gdbserver-external to IMAGE_INSTALL?
Jul 28 16:29:41 <kergoth> no, that will cause breakage, guaranteed. i thought you wanted gdb?
Jul 28 16:29:48 <kergoth> gdb includes gdbserver, gdbserver does not include gdb
Jul 28 16:29:53 <kergoth> the latter is a subset of the former
Jul 28 16:31:06 <Ox4> kergoth: currently I have gdb in IMAGE_INSTALL in image.bb and added PREFERRED_PROVIDER_gdbserver = "gdb to local.conf file
Jul 28 16:31:43 <kergoth> good
Jul 28 16:37:28 <kergoth> Ox4: the mtrace issue is fixed in current meta-sourcery master by https://github.com/MentorEmbedded/meta-sourcery/pull/85
Jul 28 16:41:30 <LocutusOfBorg1> bluelightning, the problem actually might be that I'm not in sudoers, while the other user (creating the bad tarball) might be in it
Jul 28 16:41:34 <LocutusOfBorg1> I guess he can become sudo
Jul 28 16:41:46 <LocutusOfBorg1> so maybe fakeroot or pseudo is giving him root privileges?
Jul 28 16:42:23 <bluelightning> LocutusOfBorg1: pseudo does not interact with sudo or real root in any way
Jul 28 16:43:07 <bluelightning> it doesn't need to, it's not providing or utilising any additional permissions or capabilities
Jul 28 17:15:44 <DS__> Hi, I want to create a recipe for a package in python's package index, however that package doesn't include a license file. Is there any way to specify this in the recipe? Currently I'm getting errors because the recipe does not specify the license
Jul 28 17:17:47 <kergoth> you'll need to find out what license it's under. that should be documented in the pypi metadata
Jul 28 17:17:50 <kergoth> set LICENSE appropriately
Jul 28 17:18:08 <kergoth> then patch in or otherwise provide the license text, unless you can get upstream to do it, which would be better
Jul 28 17:19:08 <DS__> kergoth: it's MIT, however they don't include the license with the source anywhere. I guess I'll have to patch it
Jul 28 17:19:11 <DS__> Thanks for the help
Jul 28 17:20:21 <DS__> I just saw that the latest released version doesn't include the file, however it's in the latest development branch, so it'll be fine in the future
Jul 28 17:21:16 <kergoth> ah, nice
Jul 28 17:21:55 <bluelightning> DS__: is there not even a comment at the top of one of the source files?
Jul 28 17:23:19 <DS__> bluelightning: just checked all files. Nothing there
Jul 28 17:23:28 <bluelightning> that's a shame
Jul 28 17:23:32 <DS__> They only say it's MIT license, but the license text is not included
Jul 28 19:55:05 <kergoth> RP: do we have a way to examine bitbake's knowledge of dependencies of a specific configuration variable? could we have bitabke set a flag like vardeps with its own view of the final deps between scanning and manual, or have a separate tool for it?
Jul 28 19:55:15 <kergoth> hmm, maybe i should add that to my old barely-maintained bb script
Jul 28 20:18:20 <RP> kergoth: I think I'd lean to a separate tool just because the storage overhead of that may be problematic
Jul 28 20:18:44 <RP> kergoth: we might be able to poke through to siggen which does have that info
Jul 28 20:19:01 <RP> kergoth: in fact you could perhaps teach emit_var to do that
Jul 28 20:19:05 <kergoth> yeah, thats what i was thinking, on-demand siggen query for the specified variables
Jul 28 20:19:06 <skfax> I want to reference a local source folder with SRC_URI for a package; i.e. fetch all the files from the specified directory. It doesn't seem possible with the standard fetchers; is there a clean workaround to this?
Jul 28 20:19:40 <RP> kergoth: trouble is you have that data for bitbake -e <target> but not -e -b <recipe>
Jul 28 20:19:43 <kergoth> skfax: you can use file:// with an absolute path to the source tree, or better yet use externalsrc
Jul 28 20:20:04 <kergoth> hmmm
Jul 28 20:21:12 <skfax> kergoth: Is it possible to point to a directory and not individual files using the file fetcher?
Jul 28 20:23:20 <fray> --- a/meta/classes/cross-canadian.bbclass
Jul 28 20:23:20 <fray> +++ b/meta/classes/cross-canadian.bbclass
Jul 28 20:23:20 <fray> @@ -30,7 +30,7 @@ python () {
Jul 28 20:23:27 <fray> -    for variant in ["", "spe", "x32", "eabi"]:
Jul 28 20:23:27 <fray> +    for variant in ["", "spe", "x32", "eabi", "n32"]:
Jul 28 20:23:52 <fray> oops.. sorry
Jul 28 20:24:13 <skfax> kergoth: Checking out externalsrc now; it seems to be what I'm looking for
Jul 28 20:24:42 <kergoth> skfax: yes, file: can point at a directory, but as you say, externalsrc is superior
Jul 28 20:24:59 <kergoth> devtool may be of use to you for quickly redirecting an existing recipe to a local source tree rather than upstream
Jul 28 20:25:09 <kergoth> see `devtool modify -x` for that case
Jul 28 20:27:47 <skfax> kergoth: How is the file fetcher lacking? It seems neater in that the source code path is then kept within the recipe
Jul 28 20:28:26 <kergoth> depends on your purpose, but hardcoding a local path in a recipe that may end up not local seems problematic. also it copies the entire source tree from its external location into WORKDIR rather than using it where it is
Jul 28 20:28:35 <kergoth> again, depends on your goals
Jul 28 20:28:55 <kergoth> if the sources will live next to the recipe in the layer or so, that's exactly what file:// is for
Jul 28 20:29:11 <skfax> kergoth: Ok, that is not an issue with this project as the codebase is small and the sources have fixed locations
Jul 28 20:29:18 * kergoth nods
Jul 28 20:29:22 <kergoth> that seems fine then
Jul 28 20:29:25 <skfax> thank you for your help :)
Jul 28 20:29:51 <kergoth> np
Jul 28 20:34:47 <skfax> Arg.. haha. It's getting late
Jul 28 20:35:51 <skfax> Was going to reflash u-boot from within u-boot using an environment variable script. The host IP was misconfigured so the TFTP command was stalling. I Ctrl+Ced but that just skipped the command and erased the existing bootloader.
Jul 28 20:37:58 <paulg> ouch
Jul 28 20:38:18 <paulg> if you haven't reset yet, all is not lost
Jul 28 20:38:28 <skfax> Yeah I just waited out the erase + programming garbage
Jul 28 20:38:50 <skfax> Since u-boot is still running I could just reprogram with an actual bootloader =)
Jul 28 20:38:58 <skfax> (I've done the same mistake before without realizing that)
Jul 28 20:39:41 <paulg> you can also leave a backup copy in some unused flash in case networking doesn't come up with the new image.
Jul 28 20:39:53 <skfax> That's not a bad idea
Jul 28 20:40:13 <paulg> I've even gone to the trouble to download an image to a networking-failed target over kermit protocol in the past, 'cause I hate hooking up an ICE.
Jul 28 20:40:29 <skfax> haha
Jul 28 20:40:45 <skfax> Yeah I've got a JTAG programmer, it's just more hassle hooking up cabling etc..
Jul 28 20:40:52 <paulg> don't get into doing that stuff to much anymore.  Not missing it either.   :-/
Jul 28 20:41:22 <paulg> s/to/too
Jul 28 20:41:26 <skfax> I just really enjoy having made scripts for u-boot. Used to do tons of manual typing to erase / copy / program memory areas etc. Waste of time
Jul 28 20:56:57 <kergoth> did anyone ever add comma escaping to PACKAGECONFIG?
Jul 28 21:08:48 <grummund> fallen at the first hurdle ;( ... help o/
Jul 28 21:09:12 * grummund following the developer screencast tutorial
Jul 28 21:09:37 <grummund> it says download and unpack poky-edison-6.0.tar.bz
Jul 28 21:10:43 <grummund> instead i did: git clone git://..../poky
Jul 28 21:11:14 <grummund> where is the oe-init-build-end script ?
Jul 28 21:14:15 <grummund> never mind... git checkout -b fido origin/fido
Jul 28 21:28:06 <domidimi> Hi, does someone have an idea what happens in the RunQueueExecuteScenequeue.__init__ in bitbake's runqueue.py?
Jul 28 21:31:33 <kergoth> I think most of that is taking the normal task dependencies and making the setscene tasks run in that order relative to one another, then checking to see which of them need to be run
Jul 28 21:36:38 <domidimi> kergoth: when I look at the execute method: it is possible to skip some tasks if their sq_revdeps are all in the covered list and the check_dependency function returns True?
Jul 28 21:36:55 <domidimi> but what is actually in the sq_revdeps?
Jul 28 21:38:07 <domidimi> squashed reverese dependecies. Can someone give me an example?
Jul 28 22:13:24 <skfax> Anyone here with meta-ros experience? Getting a "Project XXX tried to find library YYY" error when attempting to set up a package A depending on another library package B
Jul 28 22:13:46 <skfax> (Working when compiling the same packages using ROS on host)
Jul 28 23:41:23 <freeordie> hello i am trying to install a yocto image to an SSD as outlined here: https://wiki.yoctoproject.org/wiki/How_do_I
Jul 28 23:41:35 <freeordie> however the grub-install step fails
Jul 28 23:43:25 <freeordie> grub-install --recheck --root-directory=/mnt/target /dev/sde fails
Jul 28 23:43:44 <freeordie> actually i am experiencing the same issue as this person: https://communities.intel.com/thread/77694?start=0&tstart=0
Jul 28 23:44:05 <freeordie> any ideas?  or is there an alternative to formatting/partitioning/installing that i don't know about
Jul 28 23:44:34 <freeordie> i want to have /data partitions to save certain data and use the rest of the SSD.  there's a lot of available space
Jul 29 00:15:22 <freeordie> any pointers?  am i missing looking at the right documentation?
Jul 29 00:51:16 <freeordie> hello?
**** ENDING LOGGING AT Wed Jul 29 02:59:58 2015