**** BEGIN LOGGING AT Tue Mar 21 03:00:02 2017 Mar 21 04:54:51 Hello all, I have a question that I spent 1 week to figure out how I can do .. Mar 21 04:55:53 My question is that one of my system is using systemd that collects log messages with systemd-journald Mar 21 04:56:34 So,, I want to see the log message from other PC through web-browser and I found 'systemd-journal-gatewayd.serivce' can do that. Mar 21 04:56:51 The problem is my system doesn't have systemd-journal-gatewayd.service Mar 21 04:57:20 In the source code for the system have all the source.. but I cannot enable it due to my stupid Mar 21 04:57:37 Can anyone help me? Mar 21 05:53:49 newb8: in a bbappend for systemd add PACKAGECONFIG_append = " microhttpd" Mar 21 06:38:23 is runqemu borked, or am i doing something wrong? Mar 21 06:38:27 Error: Unable to find tunctl binary in '/z/build-master/qemux86/build/tmp-glibc/work/i586-oe-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin', please bitbake qemu-helper-native Mar 21 06:38:59 bitbaking qemu-helper-native doesn't help Mar 21 06:40:49 I've not used master's run qemu in a few days maybe it recently broke? Mar 21 06:43:26 * fray notes a 72 core machine takes about 5 minutes to get through the BIOS/boot process.. :P Mar 21 06:44:33 ahh there we go Mar 21 06:49:16 tlwoerner: using rm_work? saw someone else have the same issue, where rm_work trashes the sysroot-native of the image, which means no tunctl or qemu binaries Mar 21 06:50:16 nrossi: yes! thanks :-) which is odd because I don't usually use rm_work... all the more reason not to Mar 21 07:05:12 nrossi: yep, that was it :-) Mar 21 07:21:27 frsc: be glad its not a 144 core box ;-) Mar 21 07:21:35 erm fray ^^^^^^ Mar 21 07:32:13 Is it possible to instruct the package step to ignore certain files in the destination evenm though they are not referenced in FILE_${PN} ? Mar 21 07:33:24 Currently all my .so or bin files not in FILES_${PN} result in an error and I would like to not include them in FILES and cannot delete them in the do_install step because of compiletime intra-packe dependencies... Mar 21 08:45:26 I'm currently in the process of trying to build a cross toolchain for windows (canadian cross, yocto installed in windows, target is arm, toolchain for windows). Mar 21 08:45:35 I already cloned meta-mingw into yocto/poky Mar 21 08:45:53 and then I tried setting SDKMACHINE to x86_64-mingw32 Mar 21 08:46:07 but the sanity-checker does not agree with that Mar 21 08:49:13 forgot to add it to bblayers, trying again :o Mar 21 09:37:38 hmm, i successfully built meta-toolchain with meta-mingw, copied it to windows and executed the environment setup.bat Mar 21 09:37:50 but now it's missing header files, hello world won't compile, because iostream is missing Mar 21 09:37:59 did I miss something when building the cross toolchain? Mar 21 09:39:01 yourfate: are you by chance calling the compiler directly instead of using ${CC} ? Mar 21 09:39:13 although I guess on windows it would be C% Mar 21 09:39:15 I use CC or rachter CPP Mar 21 09:39:19 which is set on windows Mar 21 09:39:44 right, ok, that's a good start Mar 21 09:40:06 hmm, I think I already have a CC somewhere in my path Mar 21 09:40:15 because if I start a new terminal it also works Mar 21 09:41:15 hmm Mar 21 09:41:37 aah, %CPP% is the right one Mar 21 09:41:46 how the error looks different, but it still doesn't find iosteream.h Mar 21 09:42:24 is meta-toolchain the correct bitbake target or should I build something different? Mar 21 09:43:39 hi everyone Mar 21 09:44:18 anyone facing problems with mtdtools? Mar 21 09:46:21 I have this trace since a few days : install: cannot stat 'tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/mtd-utils/1.5.2-r0/git//include/libubi.h': No such file or directory Mar 21 09:46:37 and obviously the build fails Mar 21 09:53:27 mythi_: what's the status of merging the latest meta-intel into intel-iot-refkit? Still blocked by a kernel bug? Mar 21 10:23:03 hello Mar 21 10:23:07 hi Mar 21 10:23:50 i can no longer get 'file' revision from github Mar 21 10:24:06 3c521817322 Mar 21 10:24:18 oops Mar 21 10:24:20 not that Mar 21 10:24:30 it's a known problem, now 'fixed' I believe Mar 21 10:24:31 3c0874be Mar 21 10:24:45 somebody rebased a release branch (: Mar 21 10:24:52 CTtpollard, a few minutes ago was not Mar 21 10:24:55 let me try again Mar 21 10:25:12 cornel: I mean fixed in openembedded, the upstream sha changed for the commit Mar 21 10:25:20 oh Mar 21 10:25:26 hm Mar 21 10:26:55 anybody knows why for example fedora 25 uses 'file' from darwinsys while OE uses 'file' from github? is this just fedora using older source delivery methods? Mar 21 10:27:38 CTtpollard, i assume OE fixed the SRC fro 5.28 (or latest version) Mar 21 10:27:54 CTtpollard, can you tell me how to update the commit id for 5.24 ? Mar 21 10:27:54 cornel: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=morty&id=555d77678507d313ba0e1a20ae868082b40046ed Mar 21 10:29:57 i mean, what was the method? how do i know which is the new commit id for 5.24? Mar 21 10:30:41 CTtpollard: update your poky to that commit, or cherry pick the fix Mar 21 10:30:47 or do the same manually Mar 21 10:32:28 * cornel tries to understand Mar 21 10:32:44 i am interested in the new commit id for 5.24 .... Mar 21 10:34:24 You'd have to find the sha yourself in the upstream, or wait for your release of poky (I presume you're using an old release, and this fix hasn't been applied to old branches) Mar 21 10:34:40 jethro, yes Mar 21 10:35:28 there is no fix for it in the jethro branch Mar 21 10:35:41 i've seen this, thank you Mar 21 10:39:08 the SRCREV in the recipe linked above is the commit id for file-5.28 in the upstream repo Mar 21 10:40:01 yes Mar 21 10:40:05 yes, i'm looking after 5.24 Mar 21 10:41:23 https://github.com/file/file/releases Mar 21 10:42:49 yes but, which is 5.24 ? Mar 21 10:43:06 jku: RPM-GPG-KEY-2.2+snapshot-20170318 - I suspect the date rolled over during the test Mar 21 10:43:17 marquiz: ^^^ Mar 21 10:43:21 rburton: ^^^ Mar 21 10:43:42 kanavin: ah Mar 21 10:43:49 joshuagl, i think i got it :) Mar 21 10:44:01 thank you very much Mar 21 10:45:05 rburton: let's define a DISTRO_VERSION_NODATE, as this is the second time the issue pops up Mar 21 10:47:13 hm Mar 21 10:49:51 or maybe not Mar 21 10:50:02 the reason it wasn't observed before is that we had no test for this :D Mar 21 10:52:11 pohly: good news: ovmf failed last night on a non-musl build, so i'm definitely grabbing your build patch :) Mar 21 10:52:41 rburton: I'm still puzzled why it now starts to fail. Mar 21 10:52:57 kanavin: why does it re-generate the distro version instead of looking to see what it's actually got to work with Mar 21 10:53:04 pohly: luck of the autobuilder draw? Mar 21 10:53:24 They are not the same host system? Mar 21 10:54:01 kanavin, jku: oh Mar 21 10:55:33 rburton: if signing-keys sstate was done before midnight, and image creation is happening after, then the DISTRO_VERSION will not match the sstate Mar 21 10:59:02 pohly: is your ovmf patch against master? doesn't apply cleanly here Mar 21 11:00:22 kanavin, rburton: should we just remove ${DISTRO_VERSION} from the filename(?) Mar 21 11:00:25 Pretty much, yes. Mar 21 11:00:47 lunch -> Mar 21 11:00:51 pohly: ah no problem, as it just deletes 0001-* i can do that bit by hand Mar 21 11:00:59 rburton: However, I had the same issue when moving the patch from poky to openembedded-core. "git am" failed, "patch -p1" worked. Mar 21 11:01:02 marquiz: that, or we could list the contents of the directory where the keys are, and pick the latest file with the appropriate filename Mar 21 11:01:06 pohly: weird Mar 21 11:01:10 Perhaps it's because the CR line endings again. Mar 21 11:01:15 hm yeah maybe Mar 21 11:01:20 marquiz: I'd say the latter is maybe nicer Mar 21 11:01:35 Please try "git am ...; patch -p1 ...; git am --continue". Mar 21 11:25:15 eh Mar 21 11:25:41 it seems that actually some files are gone between the old FILE%_24 and the new FILE5_24 Mar 21 11:25:51 for example two NASA files Mar 21 11:25:58 rinex-related Mar 21 11:26:03 but not only those Mar 21 11:34:22 does anyone have experience with meta-mingw and cross compiling (canadian cross)? I'm trying to build a windows toolchain to compile for my arm target Mar 21 11:35:09 I built meta-toolchain and extracted it in windows, it comes with an environment bat, and the compilers seem to be set correctly, but the C header files are missing, for exmampmle it doesn't find iostrea.h Mar 21 11:35:11 m Mar 21 11:38:03 yourfate: are you passing CPPFLAGS etc from the environment? Mar 21 11:38:33 (as per the documentation, you need to pass all the flags set in the environment) Mar 21 11:38:36 I'm using the %CPP% compiler varisable Mar 21 11:38:45 so, it passes a lot of stuff Mar 21 11:38:50 which is set from the settings .bat file Mar 21 11:38:51 that doesn't pass everything Mar 21 11:40:56 oh, so I need to find out what to pass. Is there a way to have that already set up, like cmake so I can set it up in visual studio? Mar 21 11:42:24 CPPFLAGS Mar 21 11:42:38 and yes, if you use a tool then it should respect those variables Mar 21 11:44:49 also, that sysroot that got built doesn't contain kernel sources / headers as far as I can tell Mar 21 13:19:54 yourfate: you can configure what gets added to it... Mar 21 13:22:16 RP, is meta-toolchain even what I want to be building? I want a toolchain that can be used from visual studio on windows to compile for the arm Mar 21 13:22:52 on linux I built the toolchain into the build dir with populate_sdk and meta-ide-support Mar 21 13:23:08 that worked nicely with eclipse, didn't have to set up anything manually, compilation worked Mar 21 13:24:30 yourfate: windows support isn't as well polished Mar 21 13:25:30 yourfate: I'd think that meta-toolchain is probably closest to what you want Mar 21 13:25:34 I see. how would I add stuff to the toolchain build? Mar 21 13:25:58 I imgaine somewhat close to the core_image_extra_install stuff Mar 21 13:27:37 ...if this was up to me I'd write the code in emacs and copile from command line, but the people tasked with actually working on it want visual studio... Mar 21 14:02:05 ~Hi! Can http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/android-tools/android-tools/.gitignore be the root cause of files in android-tools/ not being propagated in an extensible SDK? Mar 21 14:02:32 When running devtool in the eSDK environment I get warnings like "WARNING: /home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools-native SRC_URI entry remove-selinux-android.patch: file could not" Mar 21 14:03:18 for any patch file mentioned in meta-oe/recipes-devtools/android-tools/android-tools_5.1.1.r37.bb Mar 21 14:05:05 ...and the patch files are missing indeed Mar 21 14:15:20 gizero: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/android-tools/android-tools/remove-selinux-android.patch Mar 21 14:15:53 why is there a gitignore in there Mar 21 14:31:11 rburton: can you elaborate? I'm not getting the point... you link to one of the patches that end up being missing in the eSDK... Mar 21 14:45:14 rburton: what I see on the eSDK side is that poky_sdk/layers/meta-oe/recipes-devtools/android-tools/android-tools only includes *.mk (which are explicitly un-ignored in said .gitignore) files but no .patch at all Mar 21 15:39:27 hello guys Mar 21 15:40:08 I am trying to get package last commit hash using such command in a recipe: EXTRA_OEMAKE = "'CPPFLAGS=${CPPFLAGS} -DGITVERSION=\\\"$$(git describe --abbrev=7 --dirty --always --tags)\\\"'" Mar 21 15:40:15 but it doesn't work :) Mar 21 15:40:27 is there correct way to do this? Mar 21 16:31:44 Ox4: what is the output failure? Mar 21 16:31:55 Ox4: may be you aren't in the git repo dir Mar 21 16:51:08 RP: can I build an image with aarch64 kernel and 32bit userspace ? Mar 21 16:52:46 Marex: probably Mar 21 16:52:54 RP: any hints on how ? :) Mar 21 16:53:15 Marex: multilib would be the obvious one Mar 21 16:54:03 RP: probably Mar 21 16:55:39 RP: but then again, I don't really want multilib rootfs Mar 21 16:55:51 RP: I just want kernel compiled for aarch64 Mar 21 16:56:56 Marex: You have two options, you either use multilib or you hack the kernel config/compile options Mar 21 16:57:28 Marex: neither is a simple "just set an option" right now afaik Mar 21 16:57:36 well, multilib is more so Mar 21 17:00:43 RP: all righty, I'll dig into it, thanks :) Mar 21 17:01:19 RP: and btw , since we now have a patch in u-boot recipe for 2.3 release , I can as well backport the omap uart fix and be done with it :/ Mar 21 17:01:35 RP: no chance of upgrading uboot to 2017.03 anyway ... sigh Mar 21 17:01:50 * Marex was totally overloaded and didn't manage to test the patch Mar 21 17:08:17 Marex: I've seen this in a project recently, they add a depends on a aarch64 linaro toolchain recipe, then they overwrite things like ARCH, KERNEL_CC, KERNEL_LD, KERNEL_LD, CROSS_COMPILE, etc. in kernel recipe. Mar 21 17:27:43 After a gstreamer update this error start to show Mar 21 17:27:46 Missing or unbuildable dependency chain was: ['gstreamer1.0-plugins-bad', 'librsvg', 'gdk-pixbuf', 'virtual/libx11'] Mar 21 17:28:15 But I'm already have configured PACKAGECONFIG_remove_pn-gstreamer1.0-plugins-good = " gdk-pixbuf orc cairo " Mar 21 17:28:51 I'm using 1.7 version, this error don't allow to execute -c clean Mar 21 17:29:04 caiortp: gstreamer1.0-plugins-good != gstreamer1.0-plugins-bad ? Mar 21 17:29:04 PACKAGECONFIG_remove_pn-gstreamer1.0-plugins-bad = " gdk-pixbuf " Mar 21 17:29:36 caiortp: gdk-pixbuf is coming through librsvg ? Mar 21 17:30:07 RP, I configured the plugins-bad too to remove gdk-pixbuf Mar 21 17:30:27 RP, hm.. I don't know.. I will see Mar 21 17:30:32 caiortp: which doesn't help since -bad depends on librsvg ? Mar 21 17:30:51 and librsvg depends on gdk-pixbuf Mar 21 17:31:15 so you need to stop it depending on librsvg as well Mar 21 17:32:18 ok, I added the rsvg in the PACKAGE_remove Mar 21 17:33:19 I had a lot of problems with gstreamer 1.4.1 so I need to update to 1.8.3 Mar 21 17:34:47 it seems to have work Mar 21 17:34:50 tks RP Mar 21 17:37:30 mjourdan: I totally want to avoid external toolchain Mar 21 17:37:34 mjourdan: esp linaro one Mar 21 17:47:19 how to get sqlite3 for python3_3.4.3 in Jethro ? Mar 21 17:52:09 Hello! Mar 21 18:37:45 hmm, the fact that there's no readme int he bitbake repo anymore rather irks me Mar 21 18:38:01 at a minimum we should have contribution guidelines and a contact point there Mar 21 19:41:25 kergoth: agreed Mar 21 19:41:36 kergoth: not sure how/when that got lost... Mar 21 19:42:08 I'm guessing it was out of date, just odd to remove it entirely rather than updating / shrinking it :) Mar 21 19:42:10 * kergoth shrugs, no idea Mar 21 19:43:49 how to get sqlite3 for python3_3.4.3 in Jethro ? Mar 21 19:56:25 kergoth: not sure its ever had one... Mar 21 19:58:35 triacta_aa: isn't there a recipe for sqlite3 in jethro already? Mar 21 19:59:34 Hi. I have a recipe that inherits from cmake. I'd now like to add a systemd service at the recipe level. So, I added systemd to inherit. I seem unable, however, to "hook" into or after do_install to stage my systemd service. I've tried supplying my own do_install, adding do_install_append, and addtask after do_install before do_package, but Mar 21 19:59:34 all of these seem to be bypassed by a direct invocation of cmake_do_install. Any ideas? Thank you. Mar 21 20:00:04 RP: huh, yeah, you're right — that's really weird :) Mar 21 20:02:44 mtas: do_install is the task that actually gets called, cmake_do_install is simply the default implementation when you inherit cmake Mar 21 20:02:55 mtas: so I'm unsure as to what would be going on there Mar 21 20:03:11 do_install_append should work, pastebin might be useful to see what you're *actually* doing Mar 21 20:04:06 * mtas rburton: Mar 21 20:04:47 Hmm, I dislike that runfetchcmd() wraps the command failure in FetchError. loses context, can't wrap a call of it in a try/except and raise a more intelligent FetchError yourself, since the command output isn't carried in the exception Mar 21 20:05:14 we also need to start making use of chained exceptions at some point here Mar 21 20:05:16 raise foo from bar Mar 21 20:05:22 hmmm Mar 21 20:05:56 kergoth: i dislike almost everything about the fetcher Mar 21 20:06:03 heh, i hear that Mar 21 20:06:05 but i also know better than to say "lets write fetch3" Mar 21 20:06:06 :) Mar 21 20:06:08 getindeed Mar 21 20:06:10 s/get// Mar 21 20:06:37 https://www.irccloud.com/pastebin/3YwfY8mX/ Mar 21 20:06:52 I rather like the idea of having a standalone fetch tool that we run to do the work, but you'd have to retain the efficiency for revision checking at parse time, which could be troublesome Mar 21 20:07:16 kergoth: shared code in bitbake? Mar 21 20:08:20 mtas: for service_file_name in SYSTEMD_SERVICE_${PN}-systemd-auto; do <— what do you expect that to be doing? Mar 21 20:08:41 I think we need to start by better fleshing out the unit tests. we can't safely refactor worth a damn right now due to the risk. it's a lot better than it was before the tests were added, but still a lot of cases it doesn't cover Mar 21 20:08:58 hard to cover every possible state of DL_DIR, your mirrors, and the remotes Mar 21 20:09:56 hm i should give the dogs a stroll and finish building that bike Mar 21 20:10:11 rburton: What I was hoping to be doing is iterating through a list of service names and installing and sed-ing each. I was intending to debug that part after getting my hook to run in the first place... Mar 21 20:11:52 rburton: At the moment, I've seen no evidence that my hook is getting stitched into the bitbake machinery, hence my post to this channel. Mar 21 20:11:55 write a do_install_append, and just bbwarn HERE in it Mar 21 20:12:19 rburton: will do. Mar 21 20:12:49 i'd be surprised if bbwarn() did python-style expansion, it's just a shell function to echo a string to a pipe Mar 21 20:13:03 so your bbwarn() won't work anyway Mar 21 20:13:28 rburton: yes, I see that now... Mar 21 20:21:43 https://www.irccloud.com/pastebin/ccfNLh9O/ Mar 21 20:30:53 kergoth: I tried to at least have something with the current fetch tests. I agree its far from perfect though. All I can say about fetch2 is that I think it improved things over fetch(1) :/ Mar 21 20:31:19 I've also tried to keep conditionals out the code, having good well used paths where we can Mar 21 20:35:30 I just got a failure from file do_fetch, even after the fix we just did Mar 21 20:35:45 ERROR: file-native-5.30-r0 do_fetch: Fetcher failure: Unable to find revision 3050419355566d2a96c5be97fef0ffae097bbb96 in branch master even from upstream Mar 21 20:35:47 ERROR: file-native-5.30-r0 do_fetch: Fetcher failure for URL: 'git://github.com/file/file.git'. Unable to fetch URL from any source. Mar 21 20:35:56 any ideas? Mar 21 20:36:04 RP: a recipe has to tarballs in SRC_URI, which untar into parallel folders, I want the second one to go under first folder .. how to do that ? destsuffix= seems to only work with git based fetcher Mar 21 20:36:21 bluelightning: there are patches for this on ml Mar 21 20:36:34 I would suggest to look at pw Mar 21 20:39:51 khem: do you mean this one? https://patchwork.openembedded.org/patch/138200/ Mar 21 20:40:01 that's already in master Mar 21 20:40:09 rburton: FYI, when I went back to my original do_install_append function, it again had no effect on the generated do_install in run.do_install! I found that I had somehow placed an extra closing brace on the last line of my function, e.g. "} }". This didn't throw an error on parse, i.e. bitbake run to completion without grumble, Mar 21 20:40:09 but the content of my function was ignored. Mar 21 20:42:06 mtas: that sounds like something we should fix, would you mind filing a bug in bugzilla? Mar 21 20:43:58 khem: re the tarball unpack - try the subdir= parameter Mar 21 20:47:52 bluelightning: yes infact I found that via bitbake sources just minutes ago Mar 21 20:50:44 bluelightning: Hi. I will file a bug (after I create a minimalist repro) Mar 21 20:54:05 bluelightning: re devtool speed, my disk is too slow on rm operations and it seems devtool is doing some of those when setting up a package for development ? Mar 21 20:54:49 bluelightning: btw. I found a complex usecase where a recipe has custom do_patch, devtool does not work in this case Mar 21 20:55:00 khem: it does do some moving files around but shouldn't be doing that much unlinking - and in master it extracts its temp files under the workdir, so it shouldn't be across different disks Mar 21 20:55:20 khem: hmm, is that custom do_patch in a public recipe? Mar 21 20:55:32 bluelightning: if you want to try then apply this patch https://github.com/kraj/meta-openembedded/commit/793e5b76f72006054cef273d25b901c5c1cb5e85 on top of meta-oe/master Mar 21 20:55:37 bluelightning: yes public Mar 21 20:56:49 bluelightning: re. slowness, the meta layers were on another disk and build/ folder and devtool workspace folder were on different on Mar 21 20:56:51 e Mar 21 20:57:01 should that make difference ? Mar 21 20:57:17 it is doing too much parsing ? Mar 21 20:57:54 khem: not especially... there would be a cost to unpacking the source, but that would be during do_unpack Mar 21 20:58:15 khem: it's possible you are hitting some odd bug there though Mar 21 20:58:31 not sure how I would reproduce your configuration here Mar 21 21:02:56 bluelightning: two disks 1. checkout meta-layers, setup sstate and dl_dir also on this disk 2. setup builddir 3. Add all meta-oe layers 4. devtools modify -x Mar 21 21:03:15 the patching bug is simpler Mar 21 21:03:32 that you can try netcat-openbsd recipe to reproduce Mar 21 21:05:10 khem, your raspberry kernel is deeply tainted by linux-yocto tasks. I' still trying out which one is fixing do_menuconfig but I have guesses :) Mar 21 21:07:20 ...unfortunaly there ar changes to kernel.bbclass wrt initramfs to test so I never finish that menuconfig debug for non-yocto kernels Mar 21 21:56:42 RP: agreed, the fetcher has improved a lot, and the tests are extremely important. they caught a couple bugs in my shallow implementation :) Mar 21 22:51:53 kergoth: oe_selftest is cool Mar 21 23:09:36 turns out upstream restored the old file hashes (sigh) Mar 21 23:09:47 RP has just pushed a revert though that fixes it Mar 21 23:10:17 and reverts for the stable branches Mar 21 23:17:35 bluelightning: WHAT Mar 21 23:20:39 kanavin: https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/850/steps/Running%20oe-selftest/logs/stdio <— didn't cross days, still broke Mar 21 23:23:08 rburton: https://mx.gw.com/pipermail/file/2017/002262.html Mar 21 23:23:32 rburton: I have a tweaked -next running, mostly green, waiting on selftest Mar 21 23:23:45 rburton: will look at merging tomorrow if its happy Mar 21 23:24:18 cool Mar 21 23:24:33 godspeed, autobuilder Mar 21 23:24:35 * rburton goes Mar 21 23:59:29 heh Mar 22 00:30:33 we need to populate apr-1.4.8.tar.bz2 into download mirrors either at yp.org or oe.org its gone from apache who can help ? halfhalo Mar 22 00:30:48 halstead: ? Mar 22 00:32:02 khem I can help in a few minutes. Mar 22 00:50:27 ok Mar 22 00:51:53 halstead: nm its already on yp mirror Mar 22 00:52:28 khem, I just setup. Can you link to where you found it? Mar 22 00:52:41 I'll move it somewhere more permanent. Mar 22 00:53:20 yp 1.6 release :) Mar 22 00:53:27 I know its old but still using it Mar 22 00:56:29 didn't this happen like 2-3 mo ago with apache itself ? Mar 22 00:56:45 they moved a bunch of stuff to a "legacy" subdir or similar? Mar 22 00:57:31 I forget what the final solution was for that, but it was discussed here and on the lists IIRC. Mar 22 00:59:24 khem, Okay. Well let me know if I should copy it somewhere http://downloads.yoctoproject.org/mirror/ Mar 22 01:00:27 paulg: I don't recall either, but assuming the future location is known, an appropriate MIRRORS value should take care of that kind of old release archiving Mar 22 01:00:35 in the recipe, that is Mar 22 01:02:34 ok, google proved I wasn't hallucinating (this time) Mar 22 01:02:39 https://patchwork.openembedded.org/patch/135422/ **** ENDING LOGGING AT Wed Mar 22 03:00:01 2017