**** BEGIN LOGGING AT Sun Oct 15 03:00:01 2017
Oct 15 03:00:38 <set_> Or...
Oct 15 03:00:42 <eupeptic> set_: That's possible.  However, I had an older version of Debian booting from the same SD card a couple of days ago, and I got one of the Angstrom test images to boot from it yesterday.
Oct 15 03:01:12 <set_> You can try the easy way. I have done this before with etcher and just pluggin' in the SD Card.
Oct 15 03:02:11 <set_> Let me read more about what you typed. Please hold.
Oct 15 03:02:35 <eupeptic> set_: I can try Etcher, but I don't think that Debian 8.4 tarball I used contains a ready-to-go image; that's why the script is there.  Holding.  :)
Oct 15 03:03:11 <set_> Oh.
Oct 15 03:03:42 <set_> Hey, did you try to use 7-zip to compress the file and then use etcher to write the file to the SD Card?
Oct 15 03:04:17 <set_> eupeptic: If not, I will find another way. I have this book.
Oct 15 03:05:20 <eupeptic> set_: I uncompressed the debian-8.4-lxqt-4gb-armhf-2016-05-13.tar.xz file with xz.  When I do that, though, I don't get anything that looks like an SD card image.
Oct 15 03:05:39 <set_> Oh and if anyone is listening, I am having a complication on installing debootstrap. Any ideas?
Oct 15 03:05:59 <set_> Oh. Let me keep reading this book on it.
Oct 15 03:06:02 <set_> Please hold.
Oct 15 03:06:06 <eupeptic> set_: I *do* get a collection of files and a script called "setup_sdcard.sh".  That script partitions the SD card and copies files from the package to the SD card in hopefully the right places.
Oct 15 03:09:14 <set_> Where did you get your .img file from?
Oct 15 03:09:53 <set_> sorry. Tarball file. Where did you get this file?
Oct 15 03:10:12 <eupeptic> set_: I got it from https://debian.beagleboard.org/images/ . All the way at the bottom of the list.
Oct 15 03:10:48 <set_> Oh.
Oct 15 03:11:03 <set_> Dang. Let me check it quickly.
Oct 15 03:11:19 <eupeptic> OK.
Oct 15 03:11:31 <set_> Hey, can you try their site instead?
Oct 15 03:11:58 <set_> bbb.io or https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Checking_The_Debian_Image_Version
Oct 15 03:14:32 <set_> ...
Oct 15 03:14:36 * eupeptic checks
Oct 15 03:14:52 <set_> I am on the wiki.debian.org/ArmHardFloatTodo page online.
Oct 15 03:14:54 <set_> ...
Oct 15 03:15:04 <eupeptic> ID.txt is BeagleBoard.org Debian Image 2016-05-13
Oct 15 03:15:07 <eupeptic> (checked from PC)
Oct 15 03:15:08 <eupeptic> BUT!
Oct 15 03:15:22 <set_> I am looking for issues pertaining to debootstrap.
Oct 15 03:15:23 <set_> ...
Oct 15 03:15:31 <eupeptic> I forgot that the script *also* forgets to populate the FAT partition sometimes (ID.txt, MLO, u-boot.img).  Trying that now.
Oct 15 03:15:35 <set_> I am trying to install it.
Oct 15 03:15:36 <set_> ...
Oct 15 03:15:51 <set_> Okay. You seem better at this than me.
Oct 15 03:16:12 <set_> eupeptic: Do you cross-compile at all?
Oct 15 03:16:34 <eupeptic> set_: I have before, but I haven't done it for this particular attempt
Oct 15 03:17:54 <set_> Okay. I was wondering b/c I am currently cross-compiling from a amd64 to armhf device (BBB)!
Oct 15 03:17:57 <eupeptic> set_: okay, I populated the FAT partition myself, but it still hangs after "Loading Ramdisk."
Oct 15 03:18:15 <set_> Sounds oddly difficult to figure out.
Oct 15 03:18:26 <set_> Are you connected via 5v or by USB?
Oct 15 03:18:57 <eupeptic> Power to the Beagleboard is via a regulated +5 V DC power supply to the +5 V coaxial plug on the Beagleboard.
Oct 15 03:19:19 <set_> Oh.
Oct 15 03:19:46 <set_> Okay...I am out of ideas. I need to read more on this subject from this book. Linux has answers!
Oct 15 03:20:32 <set_> Hey...
Oct 15 03:20:33 <set_> ...
Oct 15 03:20:52 <set_> Did you ever get a fresh image from https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Checking_The_Debian_Image_Version?
Oct 15 03:21:29 <eupeptic> not yet!
Oct 15 03:21:38 <eupeptic> but I haven't found that page before, and it seems to have actual images
Oct 15 03:21:42 <eupeptic> I will pick one and download it
Oct 15 03:22:20 <set_> Oh.
Oct 15 03:22:21 <set_> Sorry.
Oct 15 03:22:46 <set_> I guess we are not two-peas-in-a-pod. I accept images, still.
Oct 15 03:23:07 <eupeptic> They don't seem to have an image that matches my hardware
Oct 15 03:23:16 <eupeptic> I have an original Beagleboard, rev C3
Oct 15 03:23:36 <eupeptic> those images are for Beaglebone, Beagleboard-X15, and Beagleboard xM
Oct 15 03:23:48 <set_> Oh.
Oct 15 03:24:20 <set_> Sorry. I do not know anything about that speific board. Actually, nope. Not at all. My mistake. I am very sorry.
Oct 15 03:24:34 <set_> Be patient.
Oct 15 03:24:41 <set_> Someone may show up.
Oct 15 03:24:56 <eupeptic> It's OK.  Thanks.  :)  I'll stay around.
Oct 15 03:25:41 <set_> Cool...see you later.
Oct 15 03:41:07 <set_> Forget about debootstrap. I finally got it.
Oct 15 03:41:47 <eupeptic> Good!
Oct 15 03:46:16 <set_> Hey eupeptic: are you still having issues?
Oct 15 03:49:10 <set_> Hey...can I move on, i.e. even if I cannot install module-init-tools for the BBB in cross-compilation?
Oct 15 03:50:00 <eupeptic> Depends on if the next step needs someting from module-init-tools
Oct 15 03:50:13 <eupeptic> You can try it... probably the worst that will happen is that the next step will fail
Oct 15 03:50:32 <set_> You are right. The bbb probably needs it but it is not available, i.e. neither is ar.
Oct 15 03:50:33 <set_> Yep.
Oct 15 03:55:16 <set_> I am retrying.
Oct 15 04:01:28 <set_> From what I can tell, this is one of the most needed pieces of this compilation.
Oct 15 04:30:16 <set_> ...
Oct 15 04:30:40 <set_> Do you think that kldutils could take the place of module-init-tools?
Oct 15 04:38:42 <eupeptic> I don't know.
Oct 15 04:47:12 <set_> I do not know either. I tried it anyway. The system could not find it.
Oct 15 04:47:13 <set_> Boo!
Oct 15 10:32:03 <oppo> hi i want to know which dts file (..ie am57xx-beagle-x15.dts or am57xx-evm.dts) is present in the beagleboard-x15 board
Oct 15 12:55:09 <set_> Hello!
Oct 15 12:56:30 <set_> GenTooMan: I found that Bosch stuff and some APIs online for controlling the BMP180 w/ the BBG.
Oct 15 12:58:29 <set_> ...
Oct 15 12:59:13 <set_> I am currently trying to cross-compile sid onto the BBB from a VMware Debian Distro...
Oct 15 12:59:15 <set_> ...
Oct 15 13:00:14 <set_> I came across some issues so far. module-init-tools are not covered in the Distro yet. Boo!
Oct 15 13:20:29 <Humpelstilzchen> uhm what?
Oct 15 13:20:32 <set_> eupeptic: use wget <BBB .xz file> and then unxz <BBB .xz file> and then use sudo dd if = bone-debian-7.7-lxde-4gb-armhf-2014-11-11-4gb.img \ of =/ dev/ sdb bs = 8M
Oct 15 13:20:34 <set_> ...
Oct 15 13:20:43 <set_> eupeptic: Does this help?
Oct 15 13:21:09 <Humpelstilzchen> module-init-tools? Which decade is this?
Oct 15 13:21:28 <set_> What is the updated version?
Oct 15 13:22:54 <Humpelstilzchen> set_: see https://packages.debian.org/search?keywords=module-init-tools
Oct 15 13:23:00 <Humpelstilzchen> so most of us do use kmod
Oct 15 13:23:08 <set_> kmod. Thank you.
Oct 15 13:23:14 <set_> I read about that but I was not sure.
Oct 15 13:23:20 <set_> ...
Oct 15 13:23:26 <set_> I am following along in a book.
Oct 15 13:23:38 <set_> <<<< first attempt!
Oct 15 13:24:37 <set_> Humpelstilzchen: Thank you. I am off to read on kmod.
Oct 15 13:26:26 <set_> You rule. I just found that it replaces the older, outdated module-init-tools.
Oct 15 13:43:23 <set_> Humpelstilzchen: It is working. The older package was holding me back.
Oct 15 14:26:52 <GenTooMan> welcome to the world of open stuff where yesterdays tools get replaced by yesterdays toys :D
Oct 15 14:48:57 <ganesh> hi
Oct 15 14:50:27 <set_> Salutations, ganesh.
Oct 15 14:50:33 <set_> Cross-compilation?
Oct 15 16:35:27 <mrigendra> Hi all
Oct 15 16:35:46 <mrigendra> I am facing a problem in associating i2c driver with i2c device.
Oct 15 16:36:01 <mrigendra> can anyone help?
Oct 15 16:59:08 <zmatt> mrigendra: declaring the right "compatible" property in DT should do the trick
Oct 15 16:59:25 <zmatt> or, for testing, you should be able to manually bind a driver to the device via sysfs
Oct 15 17:18:27 <mrigendra> I tried this
Oct 15 17:18:58 <mrigendra> echo adxl345_i2c 0x53 > /sys/bus/i2c/devices/i2c-2/new_device
Oct 15 17:20:28 <mrigendra> and there is an entry in /devices/platform/ocp/4819c000.i2c/i2c-2/2-0053
Oct 15 17:20:35 <mrigendra> here if I do cat name
Oct 15 17:20:58 <mrigendra> I can see adxl345_i2c
Oct 15 17:21:13 <mrigendra> so now the driver should be able to associate, isn't it?
Oct 15 17:24:45 <mrigendra> I am not doing device tree stuff right now
Oct 15 17:25:11 <mrigendra> I just need a way for my driver and device to get connected, based on that I can understand more.
Oct 15 17:27:30 <zmatt> that sounds like the driver did in fact associate
Oct 15 17:28:09 <mrigendra> why i suspect it didn't is because I have put a print in probe function.
Oct 15 17:28:15 <mrigendra> that print was not in dmesg
Oct 15 17:29:09 <mrigendra> after echo command
Oct 15 17:29:12 <zmatt> is there a symlink named 'driver' in i2c-2/2-0053
Oct 15 17:29:14 <mrigendra> dmesg have this print only.
Oct 15 17:29:15 <mrigendra> i2c i2c-2: new_device: Instantiated device adxl345_i2c at 0x53
Oct 15 17:29:25 <zmatt> ohhh
Oct 15 17:29:37 <zmatt> is maybe that first argument its name, not its driver?
Oct 15 17:29:47 * zmatt has never used new_device
Oct 15 17:30:07 <mrigendra> no driver folder is not there
Oct 15 17:31:00 <mrigendra> modalias, name, power, subsystem,uevent are there
Oct 15 17:31:24 <zmatt> either that first argument to new_device isn't used to indicate the driver, or "adxl345_i2c" isn't what the driver matches on
Oct 15 17:32:11 <zmatt> locate your driver in /sys/bus/i2c/drivers
Oct 15 17:32:48 <zmatt> echo 2-0053 >/sys/bus/i2c/drivers/$DRIVER/bind
Oct 15 17:32:56 <zmatt> (where $DRIVER is the name of the driver)
Oct 15 17:33:20 <mrigendra> yes that is there
Oct 15 17:35:41 <mrigendra> no such device
Oct 15 17:35:44 <mrigendra> I tried this too
Oct 15 17:35:46 <mrigendra> echo /sys/devices/platform/ocp/4819c000.i2c/i2c-2/2-0053 >/sys/bus/i2c/drivers/adxl345_i2c/bind
Oct 15 17:36:00 <zmatt> nono, not a path, just '2-0053'
Oct 15 17:36:10 <mrigendra> yes I tried that first.
Oct 15 17:36:15 <mrigendra> what is bind here?
Oct 15 17:36:15 <zmatt> nothing in kernel log?
Oct 15 17:36:27 <zmatt> manually attaches the driver to a device
Oct 15 17:37:17 <mrigendra> no print from probe function.
Oct 15 17:39:19 <zmatt> hmm, apparently the first argument to new_device should actually select the driver
Oct 15 17:39:42 <mrigendra> https://unix.stackexchange.com/questions/318062/binding-an-i2c-device-driver
Oct 15 17:39:50 <mrigendra> this might be my problem too.
Oct 15 17:40:27 <zmatt> have a link to the driver source code?
Oct 15 17:40:35 <mrigendra> yes.
Oct 15 17:40:37 <mrigendra> I can give.
Oct 15 17:41:49 <mrigendra> https://pastebin.com/raw/9JeEzYgW
Oct 15 17:41:53 <mrigendra> this is core driver.
Oct 15 17:42:47 <mrigendra> https://pastebin.com/raw/GugA5djM
Oct 15 17:43:21 <mrigendra> this is the i2c driver for device.
Oct 15 17:44:51 <zmatt> the id this driver declares is "adxl345", not "adxl345_i2c"
Oct 15 17:49:20 <mrigendra> name	= "adxl345_i2c",
Oct 15 17:50:20 <mrigendra> tch tch that is driver name, device name should be adxl345 maybe
Oct 15 17:50:56 <zmatt> so, the reason those are separate is because a single driver can support multiple ids (e.g. minor variations of a device)
Oct 15 17:51:59 <mrigendra> yes I got that, I will delete adxl345_i2c device and try with adxl345
Oct 15 17:52:34 <zmatt> you know that the proper way to do this is through Device Tree right?
Oct 15 17:52:52 <mrigendra> it worked right away.
Oct 15 17:53:07 <mrigendra> I know in bits and pieces but haven't tried that.
Oct 15 17:53:08 <zmatt> yay :)
Oct 15 17:53:29 <mrigendra> that was a basic driver and device glitch that I made.
Oct 15 17:53:32 <mrigendra> thanks a ton.
Oct 15 17:53:58 <zmatt> well in this case binding it at runtime works too I guess.  fortunately it seems this driver doesn't require any platform data, since then you would definitely need to do this through DT
Oct 15 17:54:37 <mrigendra> I just took a leap from old board file way to do it this way.
Oct 15 17:54:51 <mrigendra> now the bigger problem I need to face to make it work through device tree.
Oct 15 17:55:53 <zmatt> https://github.com/mvduin/overlay-utils/blob/master/i2c1-mcp7940x.dtsi   an example of how to declare an i2c device in DT
Oct 15 17:56:33 <zmatt> and my overlay-utils project has a makefile that can build an overlay .dtbo from this :)
Oct 15 17:57:41 <zmatt> note that "compatible" is yet another identifier... look for "of_match" in the driver
Oct 15 17:57:52 <zmatt> so, it would be "adi,adxl345" in this case
Oct 15 17:58:44 <mrigendra> thanks a lot. Yes that name only I looked in driver file and realized my mistake.
Oct 15 17:59:07 <mrigendra> I will try with your overlay file for next experiment, I need to document all of this.
Oct 15 17:59:13 <mrigendra> for future.
Oct 15 18:01:03 <zmatt> it can definitely be confusing as hell with all these subtly different identifiers for one thing
Oct 15 18:02:15 <mrigendra> yes it is, thats why I was doing this manual thing first.
Oct 15 18:02:34 <mrigendra> Now suppose I have an overlay file for my device.
Oct 15 18:02:58 <mrigendra> I just need to compile it and then put it in firmware and then export it.
Oct 15 18:03:07 <mrigendra> I think in this way it works.
Oct 15 18:03:49 <zmatt> if you want to use the snippet I've shown, you should use the makefile from that project to build the .dtbo
Oct 15 18:05:52 <zmatt> the actual syntax for overlays isn't the same as for normal device tree fragment.  imho this is annoying as hell, which is why I made a perl script that converts the syntax to what dtc wants
Oct 15 18:07:39 <zmatt> you can of course also insert (or #include) the fragment into a customized main device tree source file, but I think that customizing your main DT is generally considered to be a bit more intimidating than using an overlay :)
Oct 15 18:12:33 <mrigendra> yes thats why I couldn't make up my mind till now as what to do further.
Oct 15 18:12:51 <mrigendra> what is more industry specific or standard specific way to do this.
Oct 15 18:13:33 <mrigendra> only advantage I see in this is that even learning this is annoying, but it will be there for long.
Oct 15 18:13:52 <mrigendra> so I am trying to see as many ways to do this as I can.
Oct 15 18:14:02 <zmatt> I personally don't use overlays at all
Oct 15 18:14:13 <mrigendra> you already have figured out a way, and I am going to learn from that.
Oct 15 18:16:58 <mrigendra> thanks for the help.
Oct 15 18:17:14 <zmatt> well, it doesn't really matter *how* it ends up in the kernel's DT, at long as it does :)   overlays are runtime patches to the kernel's DT representation, thus allowing DT to be modified after boot
Oct 15 18:18:09 <zmatt> the beaglebone has traditionally used it to apply the necessary DT changes for auto-detected CAPEs
Oct 15 18:20:26 <zmatt> it's obviously safer than modifying your main DT (which is loaded by u-boot and handed over to the kernel when it's executed), since making a mistake in the main DT can render the system unbootable (although if you were smart enough to keep a copy of the original dtb around it's not hard to recover from this via u-boot)
Oct 15 18:22:18 <zmatt> on the other hand, overlays are sometimes buggy (not all parts of the kernel appreciate runtime changes to DT), they a fair number of limitations, and their diagnostics suck
Oct 15 18:22:59 <zmatt> oh, and they use horrible syntax, but that problem is remedied by my overlay-utils project ;)
Oct 15 18:23:10 <zmatt> and... you left, probably a while back already
Oct 15 18:23:13 <zmatt> -.-
Oct 15 18:23:52 <zmatt> well, another monologue for the irclogs... may future mankind benefit from it somehow
Oct 15 18:34:47 <GenTooMan> I always log this channel you never know when something is answered I don't know I need yet.
Oct 15 18:50:22 <cyberguy> hi all, i've change the /etc/network/interface file to static ip, but it always get assiged by DHCP after reboot
Oct 15 18:50:39 <cyberguy> is there any service or something that i'm missing that is automatically turns the DHCP back on?
Oct 15 18:50:50 <cyberguy> i'm using BeagleBone Black
Oct 15 19:17:09 <zmatt> that file is probably not even being used
Oct 15 19:18:14 <zmatt> connman is the network manager installed on beaglebones by default, so you should do your network config there (or replace it by a different network manager of your choice)
Oct 15 19:27:48 <cyberugy> hi all, i'm using BBB , and i can't set static IP address , i've seen the issue here : https://ubuntuforums.org/showthread.php?t=2288300 , can anyone came up with a better solution than suggestion there? (i don't want to disable the USB)
Oct 15 19:52:27 <cyberugy> okay, i got it, it is releated to connman
Oct 15 19:52:28 <cyberugy> crap
Oct 15 20:28:15 <zmatt> cyberugy: 21:18 < zmatt> connman is the network manager installed on beaglebones by default, so you should do your network config there (or replace it by a different network manager of your choice)
Oct 15 20:51:51 <set_> Hello!
Oct 15 20:52:30 <set_> This cross-comp stuff is complicated for some reason. I cannot get Eclipse on the Debian distro with C++ development.
Oct 15 20:53:50 <set_> Well, I have Eclipse (circa 1901) but I need to update the release.
Oct 15 20:54:00 <set_> Debian is beating me again.
Oct 15 20:55:29 <set_> Does anyone know how to mess with Eclipse and Java for cross-comp on a amd to armhf?
Oct 15 20:55:50 <set_> BBB!
Oct 15 21:18:50 <set_> Only older models work w/ Debian, ECLIPSE!
Oct 15 21:21:16 <set_> ...
Oct 15 21:21:59 <set_> W/out starting from SCRATCH in Ubuntu, how can I transfer my Debian info. into Ubuntu on VMware? Send rations!
Oct 15 21:22:40 <set_> <<<< off to VMware dot com. Boo!
Oct 15 21:57:25 <GenTooMan> No
Oct 15 21:58:03 <GenTooMan> you need to read the ARM information about eclipse so you can understand how it integrates as a cross compiler.
Oct 15 21:58:22 <GenTooMan> ARM inc controls the GCC port to put it simply.
Oct 15 22:00:56 <GenTooMan> It does work it's just not as straight forward as compiling natively on the machine.
Oct 15 22:03:19 <set_> Oh.
Oct 15 22:03:35 <set_> I am actually following out of an outdated book.
Oct 15 22:09:27 <set_> i also found that Java is not supposed, well JRE, work w/ Debian or at least they do not have that Distro listed on their site.
Oct 15 22:17:55 <set_> Okay...off to ARM's site on eclipse.
Oct 15 22:27:27 <set_> GenTooMan: I have not made it to the C++ compiler on Eclipse just yet. I have to reinvent the docs. on this text to suit Ubuntu's need. I am starting from scratch w/ Ubuntu.
Oct 15 22:27:38 <set_> ...
Oct 15 22:27:45 <set_> I am almost to where I was before
Oct 15 23:42:16 <set_> Okay...I am still at it and falling apart. In writing new mirrors in Ubuntu under /etc/apt/sources.list, what should this "dog-gone" mirror be for this cross-compilation? This question is killing me. Boo!
Oct 15 23:52:28 <set_> ...
Oct 15 23:53:01 <set_> I went for us.archive.ubuntu.com/ubuntu and hated every second. Boy!
Oct 16 00:14:29 <set_> Forget it. It was us.ports.ubuntu.com/ubuntu-ports.
Oct 16 00:14:34 <set_> ...
Oct 16 00:22:10 <set_> Cross-compilation is harder than once thought. Geaux BBB!
Oct 16 00:29:53 <set_> I am almost to the point where "I have no name!"
Oct 16 00:29:56 <set_> ...
Oct 16 00:58:36 <set_> Does anyone know of the keyring issue on Ubuntu w/ cross-compilation? I am asking because the Debian keyring is debian-archive-keyring but on Ubuntu, the obvious, does not work.
Oct 16 00:58:37 <set_> ...
Oct 16 00:58:40 <set_> Any ideas?
Oct 16 01:04:56 <GenTooMan> Use debian instead of Ubuntu. To be blunt.
Oct 16 01:06:54 <GenTooMan> Also there is considerable documentation on running Eclipse for cross compilation. However it is likely better to do so from the command line (cross compilation). Here is some useful hints https://eewiki.net/display/linuxonarm
Oct 16 01:08:12 <set_> Okay.
Oct 16 01:08:39 <GenTooMan> The include the BBB under there listings pander board (yes mischievously spelled) all the beagle boards.
Oct 16 01:09:01 <set_> Okay.
Oct 16 01:15:32 <set_> GenTooMan: I will try what you stated after I eat my keyboard. No offense. I just want to keep trying rewriting this book w/ notes and updated info. No offense. In all fairness, I will try what you have described but only after I totally give up.
Oct 16 01:15:34 <set_> ...
Oct 16 01:15:40 <set_> Sorry for the long sentence.
Oct 16 01:19:08 <GenTooMan> Well Fyodor Dostoyevsky you are not, but I digress, you can do cross compilation in Eclipse however it's not as simple as you might think. Actually it requires more work than doing so from the command line.
Oct 16 01:21:51 <set_> Thank you. I have found that you are right, so far. I have had some issues but I am working through them (as we speak).
Oct 16 01:22:55 <set_> ...I typed so far just in case I catch you in the knowlege dept. Ha! Just playin'.
Oct 16 01:24:52 <GenTooMan> Unless you are programming an application with FreeRTOS (IE no linux) it's not worth it. Eclipse is better for an RTOS then an OS when it comes to ARM developement. I do know that much :D
Oct 16 01:25:16 <set_> Oh.
Oct 16 01:32:54 <GenTooMan> If you want to use Linux based developement things get more convoluted. You might wish to do native developement on the BBB instead of cross compilation.
Oct 16 01:33:25 <set_> Hold...I found the keyring. I was confused. I did find it.
Oct 16 01:33:46 <GenTooMan> "the key ring to undo the all!
Oct 16 01:33:54 <set_> Yes!
Oct 16 01:39:38 <set_> Tested and tested again. I will configure it and stay up to date (most likely).
Oct 16 02:25:33 <set_> Well GenTooMan: I will try your way.
**** ENDING LOGGING AT Mon Oct 16 03:00:01 2017