**** BEGIN LOGGING AT Wed Aug 07 02:59:58 2013
Aug 07 05:27:32 <sgw1> otavio: finally got a build started with you fs-arm marked as master-next with MUT
Aug 07 06:14:16 <vicky> hi yocto. I m trying to add libhid package on meta.I added successfully and when trying to compile it taking libusb from /lib directory. So i m getting error as http://pastebin.com/JvkbDppj
Aug 07 06:16:51 <vicky> my bb file in  http://pastebin.com/SAzyPgmm
Aug 07 06:16:57 <vicky> any ideas guys/
Aug 07 06:50:25 <nerdboy> vicky: you might have better luck doing the autoreconf --cross thing
Aug 07 06:51:25 <nerdboy> let autotools/libtool redo the inputs to configure, then use oe_runconf
Aug 07 06:53:17 <nerdboy> look at the do_configure_prepend here  =>  https://github.com/sarnold/meta-raspberrypi/blob/master/recipes-support/giblib/giblib.inc
Aug 07 06:57:55 <nerdboy> you might need to pass PYTHON_LDFLAGS in EXTRA_OECONF if it can't find the right python-native in the sysroot
Aug 07 07:04:43 <vicky> thanks a lot nredboy. I will try it out
Aug 07 07:06:01 <nerdboy> if nothing else, you could patch out the python.m4 that it uses
Aug 07 07:13:31 <thesignal> hi, I've been trying to fix this for 2 days, but i can't find a solution: whenever i bake my own kernel (i called the recipe linux-faarm) the kernel gets deployed in a subdirectory of ../ipk/morgue instead of just ../ipk ,then when i want to bitbake my image, the kernel modules are not found, because they're in that wrong directory. also, when another kernel was build before and not bitbake -c clean'ed i get "NOTE: consider defining PREFERRED_PROVIDER_vi
Aug 07 07:14:15 <thesignal> has someone had the same problem and found a solution, or will i have to cleanup everything and place the files in the wrong directory to my /ipk directory?
Aug 07 08:01:03 <bluelightning> morning all
Aug 07 12:10:08 <exosyst> I've downloaded the latest poky dylan release and can't get a simple core-image-minimal to build - the cross compiler fails, as does openssl. I'm guessing these are known bugs? Are there fixes though?
Aug 07 12:10:23 <exosyst> Is it better to use master or another branch from git rather than the release tarball
Aug 07 12:10:24 <exosyst> ?
Aug 07 12:15:24 <Zagor> exosyst: what target are you building for? can you put up the build log on some paste site?
Aug 07 12:16:57 <exosyst> Zagor, I can make it work if I patch it with this http://patchwork.openembedded.org/patch/52387/ but I get the feeling that official releases should "Just Work" and that I'm doing something wrong?
Aug 07 12:18:25 <Zagor> that's certainly a sensible feeling. which is why I'm asking for more details :-)
Aug 07 12:19:57 <exosyst> pastebin.com/AcT2kyzp
Aug 07 12:20:02 <exosyst> Zagor, ^^
Aug 07 12:21:33 <exosyst> I patched the cross compiler one (there was a segfault building 4.7.2 with GCC 4.8) - I couldn't find out any errata on why it would be broken though - the fix was a bounds error in a function
Aug 07 12:22:09 <Zagor> what distro are you building on?
Aug 07 12:22:19 <exosyst> I've since checked out the git repo rather than the official tarball and switched to the unversioned dylan tag and that seems to work
Aug 07 12:22:23 <exosyst> I'm on F19
Aug 07 12:25:18 <Zagor> right, that would explain it
Aug 07 12:25:43 <exosyst> Zagor, oh? :-/
Aug 07 12:26:03 <Zagor> F19 was released after Dylan, and is thus not tested.
Aug 07 12:26:14 <Zagor> that's why you get the little notice from bitbake
Aug 07 12:26:27 <Zagor> grabbing from git is a better choice then
Aug 07 12:27:00 <exosyst> Zagor, OK - so dylan branch is newer than dylan-9.0.1 then?
Aug 07 12:27:18 <bluelightning> exosyst: yes
Aug 07 12:27:42 <bluelightning> the next stable release is very close though
Aug 07 12:28:30 <Crofton|work> I'm on F19 and haven't noticed any issues yet
Aug 07 12:28:35 <exosyst> right - now it kinda makes sense
Aug 07 12:29:27 <exosyst> Crofton, I'm doing a fairly vanilla core-image-minimal so wasn't expecting any issues. I already filed a bug for the toolchain installer script which got fixed in master (not sure if that got backported?) but the openssl thing does look like broken pod files :-/
Aug 07 12:31:47 <bluelightning> I will make sure to test on F19 before we do the next stable release
Aug 07 12:32:44 <exosyst> bluelightning, Is there anything I can do to help? We deliver training materials and try and stay with the latest and greatest so even just smoketesting for the project is beneficial to us too
Aug 07 12:34:25 <bluelightning> exosyst: what is in my paule/dylan-next branch in the poky-contrib repo is pretty much what should become the next release, so if you could test that that would be awesome
Aug 07 12:35:53 <exosyst> bluelightning, Where would I find poky-contrib? How are you handling bug reports on it? Do you have a MAT for the project?
Aug 07 12:36:03 <bluelightning> exosyst: a MAT?
Aug 07 12:36:27 <bluelightning> exosyst: https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/?h=paule/dylan-next
Aug 07 12:37:01 <exosyst> bluelightning, Minimum Acceptance Test. Checklist of things that have to be tested for distro compliance etc
Aug 07 12:37:43 <bluelightning> exosyst: we do have a list of QA checks this will have to go through before release; it may be hard to nail down but it's all recorded in testopia which is accessible from the yocto project bugzilla
Aug 07 12:38:25 <bluelightning> exosyst: mainly I just want to make sure issues like those with gcc and openssl on F19 are fixed
Aug 07 12:38:48 <bluelightning> (before we run through the "full pass" tests)
Aug 07 12:40:25 <exosyst> bluelightning, So i'd need to join testopia (is that just bugzilla.yoctoproject.org ) and just keep filing bugs?
Aug 07 12:40:44 <exosyst> I didn't recall a product ID for poky-contrib? How do you want issues filed?
Aug 07 12:41:43 <bluelightning> exosyst: it's kind of tricky with contrib branches like this; I guess the likelihood is this one will be merged though so it's probably not a big deal to file them as if they were in master
Aug 07 12:42:01 <bluelightning> or in the dylan branch in this case
Aug 07 12:42:53 <exosyst> bluelightning, I'll make a note to test your branch out - is there a request-for-test you send out or is it just "try and build it once a week?"
Aug 07 12:47:26 <bluelightning> exosyst: there's nothing formalised for community testing, no
Aug 07 13:00:54 <rburton> bluelightning: fwiw, i've asked beth if we can get stable branches autobuilt at least weekly for basic reproducability and host OS change testing
Aug 07 13:01:10 <bluelightning> rburton: that sounds like a good idea
Aug 07 13:01:37 <bluelightning> rburton: that reminds me, any chance of a danny merge soon? ;)
Aug 07 13:02:52 <rburton> good question
Aug 07 13:03:33 <rburton> not much in danny-next, but it all looks safe
Aug 07 13:03:40 <rburton> i'll re-review this afternoon and mail the list/rp
Aug 07 13:05:35 <bluelightning> rburton: thanks
Aug 07 13:14:09 <eren> I'm having problems with vesafb
Aug 07 13:14:29 <eren> it seems that I have wrong settings in kernel, and in the command line
Aug 07 13:14:41 <eren> does anyone have experience on that topic?
Aug 07 13:22:18 <exosyst> is systemd a default now?
Aug 07 13:23:07 <exosyst> eren, why not just bitbake linux -c menuconfig to see if it is wrong?
Aug 07 13:23:22 <eren> exosyst: I am looking, I have tried different options
Aug 07 13:23:28 <exosyst> once done, just bitbake linux -c deploy
Aug 07 13:23:29 <eren> apperently, I enabled both geode framebuffer and vesafb
Aug 07 13:23:39 <eren> vesafb is not needed in the board, as I read now
Aug 07 13:23:47 <eren> I will try different setting
Aug 07 13:23:55 <eren> exosyst: what does -c deploy task do?
Aug 07 13:24:13 <eren> I always use -c clean, -c menuconfig, .... , -c build
Aug 07 13:24:22 <exosyst> eren, deploy just the linux image rather than the whole image
Aug 07 13:24:34 <eren> ah I see
Aug 07 13:26:12 <bluelightning> exosyst: no, sysvinit is still the default
Aug 07 13:26:31 <bluelightning> exosyst: but systemd is now supported as an option in the core
Aug 07 13:27:26 <eren> bluelightning: btw, "live" image looks problematic
Aug 07 13:27:41 <eren> I will copy rootfs to the CF Card and install bootloader (say grub)
Aug 07 13:27:49 <eren> however, initramfs image is missing?
Aug 07 13:28:12 <bluelightning> eren: "live" does produce a separate initramfs image
Aug 07 13:28:32 <eren> but it has its own init script, which expects some other media mounted on /media dir
Aug 07 13:28:35 <eren> and it halts
Aug 07 13:28:36 <exosyst> bluelightning, So what do I need to do to get systemd? I thought it was a DISTRO_FEATURE?
Aug 07 13:28:44 <bluelightning> exosyst: it is
Aug 07 13:29:20 <bluelightning> exosyst: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#selecting-an-initialization-manager
Aug 07 13:29:24 <exosyst> bluelightning, ah cool, so DISTRO_FEATURES_append = "systemd" shoudl work
Aug 07 13:29:46 <bluelightning> exosyst: if there's a leading space in the value yes
Aug 07 13:30:03 <bluelightning> exosyst: (you haven't got one in what you just typed)
Aug 07 13:30:07 <exosyst> bluelightning, ah yeah - that's screwed me before
Aug 07 13:31:25 <eren> bluelightning: well, I have waiting for removable media" problem :)
Aug 07 13:31:49 <bluelightning> eren: I don't know much about that I'm afraid
Aug 07 13:32:00 <bluelightning> eren: I know we have some work to do with deployment that relates to this
Aug 07 13:32:21 <bluelightning> eren: but I do know for sure that live images work, I built and used one just the other day with master
Aug 07 13:32:22 <eren> ok, it's a common x86 pc, what deployment method would you suggest?
Aug 07 13:32:57 <eren> I just dd "hddimage" to flash, it boots, init script runs and I get "waiting for removable media"
Aug 07 13:33:14 <bluelightning> yes, that's what I did here too
Aug 07 13:36:23 <eren> I guess I will try ML
Aug 07 14:00:47 <rburton> eren: that normally means you've some messed up systemd/udev packages, i.e. udev from udev but libudev from systemd
Aug 07 14:01:06 <rburton> eren: or the initramfs is missing udev-extraconf (which contains the code that mounts the real rootfs)
Aug 07 14:01:27 <rburton> eren: not that switching distro features implies you wiping your build directory for reliability
Aug 07 14:01:33 <rburton> "note", even
Aug 07 14:01:42 <eren> rburton: oh, I just use dylan release, udev/systemd are default
Aug 07 14:01:48 <eren> I haven't touched them
Aug 07 14:02:03 <eren> what I do is to produve live image, and "dd" the hddimage directly onto CF Crad
Aug 07 14:02:08 <rburton> eren: sure, so that means "sysvinit" images use udev from udev, and systemd images use udev from systemd
Aug 07 14:02:09 <eren> which then ALIX board use to build
Aug 07 14:02:28 <rburton> eren: which have different versions, which causes problems if you change distro features but don't wipe the deploy.
Aug 07 14:02:45 <eren> ah
Aug 07 14:02:56 <eren> well, yes, I am working on a BSP for alix3d3
Aug 07 14:03:32 <eren> apprently, I haven't changed distro features
Aug 07 14:03:45 <eren> distro is poky
Aug 07 14:05:51 <eren> rburton: so, what should I try? udev-extraconf first?
Aug 07 14:07:42 <rburton> eren: yeah, verify that's in the initramfs
Aug 07 14:09:22 <eren> rburton: ok, I'm checking initramfs image
Aug 07 14:11:11 <eren> rburton: oh, I have udev-extraconf in initramfs
Aug 07 14:11:23 <eren> automount.rules, autonet.rules, etc
Aug 07 14:18:36 <Krz> hi guys, I'm using poky dylan-9.0.1 tag. The zlib version 1.2.7 is no longer available on zlib.org. Isn't there any other mirror?
Aug 07 14:19:45 <Krz> They must have removed 1.2.7 version from the website recently
Aug 07 14:22:44 <rburton> its on the yocto mirror, i thought it would look there by default
Aug 07 14:37:01 <bluelightning> Krz: what rburton said, if you have kept the default MIRRORS configuration it will be pulled from the yoctoproject.org mirrors
Aug 07 14:47:45 <Krz> I didn't change zlib recipe
Aug 07 14:48:10 <Krz> and there is only one mirror on the list: zlib.net
Aug 07 14:48:19 <Krz> or .org ...
Aug 07 14:48:27 <kergoth> MIRRORS isn't defined int he rcipe.
Aug 07 14:48:33 <kergoth> it's defined by the poky distro
Aug 07 14:49:15 <bluelightning> Krz: right, it's set in meta-yocto/conf/distro/poky.conf
Aug 07 14:49:32 <bluelightning> Krz: (by default at least)
Aug 07 14:50:43 <rburton> bluelightning: so why does mirrors.bbclass have the same lines but https?$://.*/.* as the regex?
Aug 07 14:50:49 <rburton> that $ looks very suspicious
Aug 07 14:51:05 <bluelightning> rburton: I'm not too sure
Aug 07 14:51:22 <kergoth> that $ looks fine. bitbake splits the url before matching the regexes
Aug 07 14:51:31 <kergoth> that $ ensures that only that scheme will match, not httpsfoobarbaz
Aug 07 14:51:41 <rburton> kergoth: so why do none of the others do that?
Aug 07 14:51:55 <kergoth> no idea
Aug 07 14:52:35 <rburton> in fact the mirrors in poky appears to just replicate lines in mirrors.bbclass, just without the $
Aug 07 14:52:56 <kergoth> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/classes/mirrors.bbclass is what we use at mentor. strips out the useless location-based mirrors, and uses a catchall scheme to avoid having to list them all
Aug 07 14:52:58 * kergoth shrugs
Aug 07 14:53:33 <rburton> yeah thats much better than ours ;)
Aug 07 14:55:33 <rburton> kergoth: you should totally send that in to oe-core
Aug 07 14:57:03 <rburton> kergoth: http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/recipes/gnome/gconf_3.2.6.bbappend <-- is that mentor value-add? ;)
Aug 07 14:57:45 <rburton> kergoth: ok, to be fair, you did send that one in ;)
Aug 07 15:00:00 <Krz> so when zlib 1.2.7 download fails it should pick one from yoctoproject.org? (because it didn't for me and i use unmodified poky.conf)
Aug 07 15:00:07 <rburton> Krz: yes
Aug 07 15:00:13 <rburton> Krz: pastebin the full log of it failing to download?
Aug 07 15:00:16 <rburton> maybe its failing the mirror too
Aug 07 15:00:51 <Krz> i don't have it anymore - just copied zlib127 tarball from other source to downloads/
Aug 07 15:01:02 <exosyst> eren, bluelightning_ so wait - systemd is default in dylan?
Aug 07 15:01:06 <exosyst> Now i'm confused
Aug 07 15:01:22 <Krz> I thought someone has seen it
Aug 07 15:01:42 <rburton> exosyst: no, sysvinit is default
Aug 07 15:01:44 <exosyst> I am getting some weird warnings about "The recipe systemd is trying to install files into a shared area when those files already exist" and then reams of them
Aug 07 15:02:05 <rburton> exosyst: did you enable systemd without wiping the sysroot?
Aug 07 15:02:09 <kergoth> rburton: heh, as always with such things, have to find breathing room to catch up on the submission backlog :)
Aug 07 15:02:37 <exosyst> rburton, wiping the sysroot? What shenanigans do i invoke to do that? bitbake -c clean?
Aug 07 15:02:44 <rburton> exosyst: "wipe-sysroot"
Aug 07 15:03:05 <rburton> exosyst: thats easier than blowing away the entire tmp/ when you change distro features
Aug 07 15:03:09 * dvhart learns a new task
Aug 07 15:03:12 <dvhart> thanks rburton
Aug 07 15:03:17 <rburton> dvhart: its a script
Aug 07 15:03:23 <rburton> dvhart: lots of rm's
Aug 07 15:03:33 <exosyst> rburton, thanks. That's pretty neat. So I can just bitbake -k core-image-minimal again and it *should* work?
Aug 07 15:03:34 <dvhart> ah, noted
Aug 07 15:03:38 <rburton> dvhart: the trick is deleting the right stamps
Aug 07 15:03:46 <rburton> exosyst: *should*
Aug 07 15:04:48 <exosyst> rburton, cool beans. Cheers!
Aug 07 15:06:07 <eren> ok, I still have "waiting for removable media" error
Aug 07 15:06:22 <eren> at least, I know have a decent framebuffer support (1024x768@60) yay!
Aug 07 15:06:33 <eren> the only thing is to bring the board at bootable stage
Aug 07 15:07:14 <rburton> eren: debugging that is a pita.  the initramfs is waiting for your rootfs to be automounted.
Aug 07 15:07:21 <rburton> luckily dvhart just turned up!
Aug 07 15:07:55 <dvhart> and is double booked on meetings, responses will be delayed ....
Aug 07 15:08:37 <rburton> dvhart: excuses
Aug 07 15:09:03 <rburton> dvhart: SEO forum is only half a booking at best ;)
Aug 07 15:09:25 * dvhart wonders what an SEO forum is
Aug 07 15:09:27 <dvhart> ;-)
Aug 07 15:09:27 <eren> ok, should I seek some solution in ML or wait here? :)
Aug 07 15:09:35 <dvhart> waiting on removable media....
Aug 07 15:09:40 <eren> dvhart: hahaha
Aug 07 15:10:05 <eren> ok, I will wait with "debugshell" option
Aug 07 15:10:35 <dvhart> that usually means the usb live config options aren't present
Aug 07 15:10:53 <dvhart> eren, which BSP and image?
Aug 07 15:11:38 <eren> dvhart: meta-alix3d3, that I am trying to bring up
Aug 07 15:11:42 <eren> dvhart: it is "live" image
Aug 07 15:12:10 <dvhart> which one? minimal,live,etc
Aug 07 15:12:38 <eren> dvhart: ah
Aug 07 15:12:42 <eren> it's core-image-minimal
Aug 07 15:13:01 <eren> https://github.com/eren/meta-alix3d3
Aug 07 15:13:04 <dvhart> which device ?
Aug 07 15:13:11 <dvhart> which device is your rootfs on?
Aug 07 15:13:34 <eren> dvhart: same device, I dd hddimage into CF Card
Aug 07 15:13:50 <dvhart> and that is what? /dev/sda?
Aug 07 15:14:09 <eren> ah, let me check
Aug 07 15:14:16 <dvhart> the live image looks for a specific set of devices
Aug 07 15:14:25 <dvhart> check the init script and be sure your device is in there
Aug 07 15:14:32 * dvhart has to run.... back later
Aug 07 15:17:50 <eren> oh well, I cannot seem to have kernel boot log
Aug 07 16:09:34 <mranostay> ok silly question what is difference in the recipes in recipes-support and recipes-extended?
Aug 07 16:10:52 <bluelightning> mranostay: see meta/recipes.txt
Aug 07 16:11:06 <bluelightning> mranostay: the divisions are somewhat arbitrary in some cases
Aug 07 16:20:51 <mranostay> bluelightning: so  reading that i can see some arbitrary calls being made :)
Aug 07 16:21:15 <rburton> mranostay: and the end of the day the recipes-* divisions are entirely arbitrary and have no meaning beyond some grouping for humans
Aug 07 16:42:35 <eren> well, I guess my kernel lacks CF Card slot (PCCARD) option so udev cannot detect and mount it
Aug 07 16:46:59 <kergoth> honestly i kind of preferred the flat model. now its often a guessing game figuring out where something is :)
Aug 07 16:49:06 <bluelightning> kergoth: kind of implies the categorisation isn't really helpful in some cases
Aug 07 16:49:13 <bluelightning> kergoth: we could look at reorganising
Aug 07 16:49:35 <fray> I find the categrorization very useful.. not as much for the name of the category, but because not everythign is all in one big directory..
Aug 07 16:49:46 <fray> I can go into recipes-devtools and find mostly development related items..
Aug 07 16:49:51 <fray> the graphics for all of the x11 and related.. etc
Aug 07 16:50:40 <kergoth> IMO taxonomies are only useful if you consider the use cases / how you access the infromation, and 90% of the time i'm looking for something knowing its name, but not necessarily even remembering waht categories exist, much less what one it's in
Aug 07 16:51:05 <kergoth> maybe i'm not the common case, but i dont go browsing around what recipes exist very often
Aug 07 16:51:11 <fray> I usually do ls -d recipes-*/<name>
Aug 07 16:51:14 <kergoth> (and the layer index exists to cover that)
Aug 07 16:51:41 <kergoth> so do i, or find, but it's adding overhead to what seems to me to be the most common thing for us to be doing
Aug 07 16:51:51 * kergoth shrugs
Aug 07 16:56:37 <rburton> kergoth: i like the fact that sh/emacs does globs when opening files, i.e meta/*/foo/*bb
Aug 07 17:00:26 <kergoth> note: useful vim tip, use 'n' instead of 'e' and you can open with globs too
Aug 07 17:00:31 <kergoth> :n */foo
Aug 07 17:31:23 <mr_science> the next time i hear someone rag on git because they used to have perforce, clearcase, or whatever, i'm converting their git repos to cvs...
Aug 07 17:32:51 <mr_science> just sayin'...
Aug 07 17:42:49 <bluelightning> mr_science: haha
Aug 07 18:16:05 <mr_science> it would be even funnier if i actually did it
Aug 07 18:16:36 <mr_science> rename thier repo something like old_junk and create a new cvs repo...
Aug 07 18:20:26 <mr_science> damn, i need a bigger font on this display...
Aug 07 18:21:03 <mr_science> loks great on the second head, but the first head is a 1080p laptop display
Aug 07 18:21:10 <mr_science> *looks even
Aug 07 18:21:39 <mr_science> couldn't tell he actually quit without squinting
Aug 07 19:19:54 <Garibaldi|work> Hi folks.  I've run into a problem with runqemu-extract-sdk.  Suppose that I have tmp/deploy/image/core-image-foo.gz.  If I do a 'tar -tvf <that_file>', I see for example "drwxr-xr-x 0/0               0 2013-08-07 18:16 ./etc/".  After extracting it, I see "drwx------ 27 user group 4.0K Aug  7 14:16 etc".  Notice that the permissions on the directory have changed
Aug 07 19:20:27 <Garibaldi|work> I need to preserve the directory's permissions
Aug 07 19:23:18 <mr_science> are you extracting with -p ?
Aug 07 19:23:27 <Garibaldi|work> I'm running rnuqemu-extract-sdk
Aug 07 19:23:36 <Garibaldi|work> err, 'runqemu-...'
Aug 07 19:23:54 <mr_science> can you see what the tar arguments are?
Aug 07 19:24:01 <Garibaldi|work> xjf
Aug 07 19:24:18 <Garibaldi|work> no p
Aug 07 19:24:21 <mr_science> needs p to presrve perms
Aug 07 19:25:00 <mr_science> i'd call that a bug...
Aug 07 19:25:25 <Garibaldi|work> jhhum
Aug 07 19:25:26 <kergoth> indeed
Aug 07 19:25:41 <Garibaldi|work> so I modified the script to include p, but I see the same behavior
Aug 07 19:26:10 <mr_science> -p should work no matter what user is running tar...
Aug 07 19:26:33 <kergoth> well, if he's not root, it wont be able to chown it to root, unless its sudo tar'ing
Aug 07 19:26:46 <mr_science> true
Aug 07 19:27:01 <seebs> I have used a machine with very strict restrictions on sudo commands.
Aug 07 19:27:05 <seebs> One of the commands permitted: tar.
Aug 07 19:27:11 <mr_science> or fakeroot/pseudo i suppose...
Aug 07 19:27:25 <Garibaldi|work> yeah, I didn't expect it to be root/root
Aug 07 19:27:34 <Garibaldi|work> but I did expect the same file permissions
Aug 07 19:27:54 * kergoth nods
Aug 07 19:28:05 <mr_science> i would this shouldn't need sudo
Aug 07 19:28:09 <seebs> What's your umask?
Aug 07 19:28:17 <kergoth> that is odd, unless it's not overwriting the existing files for some reason?
Aug 07 19:28:18 * kergoth shrugs
Aug 07 19:28:20 <Garibaldi|work> 0022
Aug 07 19:28:52 <seebs> I note that tar respects umask.
Aug 07 19:28:58 * mr_science is having whole-word dropouts today...
Aug 07 19:29:16 <seebs> Made an "x.tar" containing -rwxrwxrwx 1 seebs/seebs x.
Aug 07 19:29:25 <kergoth> ah, interesting.
Aug 07 19:29:29 <kergoth> good to know
Aug 07 19:29:29 <seebs> tar xf => -rwxr-xr-x (umask 022). tar xpf => -rwxrwxrwx
Aug 07 19:29:36 <seebs> Also, found a bug in tar
Aug 07 19:29:37 <kergoth> huh
Aug 07 19:29:42 <seebs> $ tar cf x.tar x
Aug 07 19:29:48 <seebs> .. oh wait
Aug 07 19:30:00 <Garibaldi|work> hum...
Aug 07 19:30:00 <seebs> nevermind. I found a typo, I'd spelled it "tr". Which is why it said "extra operand".
Aug 07 19:30:13 <Garibaldi|work> I think I might have found the issue
Aug 07 19:30:27 <seebs> kergoth: I might have a bunch of meta-sourcery patches coming up "soon".
Aug 07 19:30:49 <seebs> Specifically, enabling cross-canadian package creation, and a couple of related bits.
Aug 07 19:31:42 <Garibaldi|work> bah, I think I have two different versions of tar with different behaviors
Aug 07 19:32:04 <seebs> That's the lovely thing about standards. There's so many of them to choose from!
Aug 07 19:32:19 <Garibaldi|work> hehe
Aug 07 19:33:22 <Garibaldi|work> what's worse, both claim to be GNU tar 1.26
Aug 07 19:38:07 <mr_science> obviously i'm not the first to ask this one...
Aug 07 19:39:04 <mr_science> all you need in google is "cron re" and it completes it as "read-only filesystem" in a dozen different variants...
Aug 07 20:11:02 <mr_science> so bluelightning, i figured out my issue with start-stop-daemon yesterday...
Aug 07 20:18:35 <mr_science> turns out the guy who works on the binary in question had decided to make it background itself, then didn't remove the "&" from the initscript...
Aug 07 20:19:15 <mr_science> so my new initscript was still using start-stop-daemon --background
Aug 07 20:19:55 * mr_science grumbles about communication issues across one stupid cubicle divider...
Aug 07 20:22:59 <kergoth> heh
Aug 07 20:23:37 <mr_science> yeah, it's funny *now*
Aug 07 20:23:52 <mr_science> not so much yesterday afternoon...
Aug 07 20:25:12 <mr_science> there's actually better communication across countries/timezones on IRC...
Aug 07 20:29:52 <kergoth> sadly at work i'm pretty much the only one on y team that *lives* on irc
Aug 07 20:31:04 <mr_science> me too. other than a couple of contractors who are only here 3 times/week
Aug 07 20:42:54 <seebs> We have an internal IRC server, it works really well.
Aug 07 20:43:19 <kergoth> internal irc is indeed invaluable. virtual watercooler, among other things
Aug 07 20:43:45 <mr_science> i setup an internal xmpp server when i first got here
Aug 07 20:44:02 <mr_science> i was the only one using it so now i don't bother...
Aug 07 20:45:31 <otavio> kergoth: yes; irc indeed helps a lot
Aug 07 20:47:15 <mr_science> i only did xmpp because nobody else could spell irc...
Aug 07 20:53:51 <seebs> Asynchronous text medium = happy.
Aug 07 20:54:02 <seebs> Better, asynchronous-or-synchronous.
Aug 07 21:06:40 <bluelightning> mr_science: ok, good to hear at least that you figured out the problem
Aug 07 21:07:04 <mr_science> you mean good that it was my problem and not a bug...
Aug 07 21:07:14 <mr_science> ;-)
Aug 07 21:07:33 * mr_science always forgets the smilie...
Aug 07 21:07:55 <mr_science> and yes, it is/was
Aug 07 21:21:52 <mr_science> kergoth: i did see an "easy" way to do those permissions, but it's pretty much a side-effect
Aug 07 21:22:20 <mr_science> turns out you can abuse the volatiles config to do that for directories
Aug 07 21:31:10 <kergoth> mr_science: heh, downside to that is volatiles are handled differently between sysvinit and systemd, and of course that isn't really its purpose, as you say
Aug 07 21:31:13 * kergoth ponders
Aug 07 21:32:10 <mr_science> i'm not advocating using a side-effect that doesn't even qualify as an "undocumented feature"
Aug 07 21:32:27 <kergoth> heh :)
Aug 07 21:32:30 <mr_science> just pointing it out...
Aug 07 21:32:35 * kergoth nods
Aug 07 22:07:06 <bluelightning> mr_science: I don't mind bugs if they can be explained :)
Aug 07 22:09:18 <mr_science> yeah, i was thinking i like having bugs to fix...   just not so keen on the crazy ones...
**** ENDING LOGGING AT Thu Aug 08 02:59:59 2013