**** BEGIN LOGGING AT Wed Nov 14 03:00:00 2018 Nov 14 07:03:45 ok i need an elegent way to get past setting users permissions on a directory Nov 14 08:00:17 nevermind, fixed it Nov 14 08:32:59 good morning Nov 14 09:08:48 * RP notes more timeouts on the autobuilder Nov 14 09:09:03 There is something very wrong in the package feed sharing code :( Nov 14 09:10:17 * RP notes a race in the package manager repo code too :( Nov 14 09:19:02 New news from stackoverflow: Lock packages version with Yocto Nov 14 09:25:06 Hi there, I am trying to get python 3.7.x to build using the following patch: http://lists.openembedded.org/pipermail/openembedded-core/2018-November/275738.html . But I am ending up with an error during python3-dbus: tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/python3-dbus/1.2.6-r0/recipe-sysroot-native/usr/lib/libpython3.7m.so: file not recognized: File format not recognized Nov 14 09:27:41 It seems to me that there is a mixup between recipe-sysroot-native and recipe-sysroot. When building on official sumo I "-L/home/dev/medusa/build/yocto/build/tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/python3-dbus/1.2.6-r0/recipe-sysroot/usr/lib -lpython3.5m" is used. Note the "recipe-sysroot". Is anyone experiencing the same issue? Nov 14 09:37:07 hi, anyone here? Nov 14 09:37:29 nope. nobody is here. not even you yourself. its all an illusion! Nov 14 09:37:35 whoa Nov 14 09:37:36 * LetoThe2nd does the jedi handwave thing Nov 14 09:40:26 i am looking to get started writing layers/bb recipes. Is there an example how to customize a conf file in the image I create with bitbake? Nov 14 09:40:58 depends a bit on the specific conf file. Nov 14 09:43:09 As a starting point, I want to create my own layer and a recipe to provide my own /lib/systemd/network/10-eth0.network Nov 14 09:43:56 Well, iirc I can also provide an 99-override-eth0.network there Nov 14 09:46:19 ok, so it is a file that gets usually installed and that you want to modify. i *guess* it comes from the systemd recipe, unless you are using a specifc board support package that already incorporates it. Nov 14 09:46:30 which layers are in use so far, and whats the board? Nov 14 09:52:01 It's a board by PHYTEC. Their default setup has: meta, meta-poky, meta-networking, meta-python, meta-multimedia, meta-gstreamer1.0, meta-nodejs, meta-phytec, meta-qt5 and meta-yogurt (PHYTEC simple distribution layer) Nov 14 09:55:44 jmiehe_dup: then my first advice is to checj the meta-phytec and meta-yogurt layers if the file is actually provided by one of those. Nov 14 09:59:59 jmiehe_dup: systemd lets you override really nicely, so just write a new recipe that drops files in like you said Nov 14 10:00:51 Can I add that recipe to a new layer like I though? Nov 14 10:01:02 thought* Nov 14 10:02:48 yes Nov 14 10:04:34 Ultimately, I would like to include a node.js application into my new layer. As my dependencies have native bindings, I don't want to "npm install" doing recompiles on every fresh clone. How to avoid? Nov 14 10:05:01 @rburton nice Nov 14 10:05:25 surely you just need to write a recipe for each of the deps, so npm doesn't want to install anything else Nov 14 10:21:29 Hi Ross, I have a question relating Python 3.7: Were you have to successfully build python3-dbus using the patch http://lists.openembedded.org/pipermail/openembedded-core/2018-November/275727.html Nov 14 10:23:10 will tell you in a few minutes :) Nov 14 10:24:22 RP: master-next passes my buildhistory-diff test btw Nov 14 10:25:20 rburton: cool. I should look at merging some of the crazy patch baklog Nov 14 10:32:23 I am always ending up with python3-dbus: tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/python3-dbus/1.2.6-r0/recipe-sysroot-native/usr/lib/libpython3.7m.so: file not recognized: File format not recognized Nov 14 10:33:02 tristanram: with 3.7.1, yes Nov 14 10:33:18 what does file say about that object? Nov 14 10:33:33 maybe its using the native compiler, i'm building against x86 right now Nov 14 10:33:48 So with this patch http://lists.openembedded.org/pipermail/openembedded-core/2018-November/275738.html, yes? Nov 14 10:34:10 yes Nov 14 10:34:50 Before using this patch existed, I tried porting the 3.5.6 to 3.7.0 myself. But I always got stuck with above error. Nov 14 10:36:27 With 3.5.6 the python3-dbus do_configure lokks like "-L/home/dev/medusa/build/yocto/build/tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/python3-dbus/1.2.6-r0/recipe-sysroot/usr/lib -lpython3.5m" Nov 14 10:37:18 With the patch 3.7.1 from the ml, it looks like "L/home/dev/medusa-test/build/yocto/build/tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/python3-dbus/1.2.6-r0/recipe-sysroot-native/usr/lib -lpython3.7m" Nov 14 10:37:34 [OT] nice, I feel like I'm beginning to get it, thanks! [/OT] Nov 14 10:37:57 Somehow, the native python lib seems to be used by accident Nov 14 10:41:32 tristanram: yeah, the cross stuff in py is all hacked in and presumely it broke in the upgrade Nov 14 10:41:37 tristanram: can you reply on the list with that? Nov 14 10:44:41 rburton: I have not used mailing lists before but subscribed some days ago and ml is quite new to me. Sorry for this novice question: but how do I reply to an existing thread which was created before I was subscribed? Nov 14 10:44:57 tristanram: painfully Nov 14 10:45:15 i'll reply :) Nov 14 10:46:52 kergoth Thanks. If you're still around, could you possibly give me a hand with the bbappend thing? Nov 14 10:49:22 la_croix_: whats the exacty problem you have with the bbappend? Nov 14 10:49:53 LetoThe2nd Being, as you know, a moron, I'm not entirely sure where to start. Nov 14 10:50:55 rburton: thats what i suspected, thank you very much for your help. I would be very happy to update to python 3.7 without having to wait for "Warrior 2.7" Nov 14 10:52:19 la_croix_: oh thats simple. you just create a recipe in your layer that follows the same path and name as the recipe that you want to modify. just that its suffix is bbappend, instead of bb Nov 14 10:52:58 and in that file, you write down what you want. essentially, is will then overwrite the parts that you noted in the original recipe Nov 14 10:53:47 la_croix_: and no need to feel like a moron. i usually hand out a fair share of rtfms, but thats nothing to be taken personally. :-) Nov 14 10:55:02 ah see here, even a nice example in the fm: https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#using-bbappend-files Nov 14 10:55:11 LetoThe2nd Ok, but the file that I've found mentioning ssh is /poky/meta/recipes-core/packagegroups/packagegroup-core-ssh-openssh.bb and this doesn't mention any files (like an sshd_config) Nov 14 10:55:26 LetoThe2nd Thanks, I won't. Rtfm is usually pretty good advice, anyway ;) Nov 14 10:56:09 la_croix_: well if you look into the file you mentioned, its basically a dependency redirect to openssh itself. Nov 14 10:56:36 -> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/openssh/openssh_7.8p1+git.bb?h=master Nov 14 10:59:34 LetoThe2nd Ah, that looks promising. Thank you Nov 14 11:03:47 LetoThe2nd So presumably my new recipe would need a copy of the original sshd_config, with my changes? Nov 14 11:05:30 la_croix_: possibly. and *only* that, no need to copy over the whole shbang Nov 14 11:05:48 Ah, ok. Nov 14 11:06:58 Now, that will work for changing the ports, disabling password access, etc, but presumably to add my ssh key to .ssh/authorized_keys, I will need to edit the rootfs? Nov 14 11:08:45 no, you can modify the file at will in the recipe Nov 14 11:09:36 here's an example on how it can be done. http://git.yoctoproject.org/cgit/cgit.cgi/meta-web-kiosk/tree/recipes-common/ssh-keys/ssh-keys_0.1.bb?h=master Nov 14 11:10:02 Hmm. Ok. By the by, there is presumably nothing wrong with copying the entire original sshd_config, and having it replace the original? I'm not too keen on stubs of config files Nov 14 11:10:49 this is the seperate-recipe form which i personally would prefer anyways. so you might even be off with just disabling the debug-tweaks IMAGE_FEATURE (which causes the no-password-rootfs) and injecting such an ssh-keys recipe. i think there's no append needed at all. Nov 14 11:11:51 LetoThe2nd Understood, thank you Nov 14 11:12:06 have fun Nov 14 11:12:46 :) Nov 14 11:14:31 Morning folks Nov 14 11:14:44 do we know when the linux-yocto 4.19 branches are coming up? Nov 14 11:17:50 LetoThe2nd I think I've managed to add the new config to the do_install(), but I'm unclear on what "FILES_${PN}-server += "/home/${USER}/.ssh/authorized_keys" and thee line above it do. Do they just tell the build to consider these files to be associated with this package? Nov 14 11:19:18 la_croix_: that means that those files should go into the package. otherwise you would install them (to the staging area), but they wouldn't make the escond step from staging into the actual, deployed package Nov 14 11:20:04 LetoThe2nd Ok, so adding: FILES_${PN}-server += "/etc/ssh/sshd_config" Should be fine? Nov 14 11:20:30 tristanram: fwiw, worked for me against qemuarm64 Nov 14 11:21:16 la_croix_: i'd expect that this particular file is already in FILES, as it would never make it to the image otherwise. Nov 14 11:21:37 la_croix_: just build the recipe with bitbake -e, and search the output for the FILES variable Nov 14 11:22:03 LetoThe2nd Yes, it must be, so there's no need to redo it to make sure it contains *my* sshd_config, rather than the standard one? Nov 14 11:22:25 no Nov 14 11:23:02 if its in the variable already, then thats it. the variable gets applied in the packaging stage, log after all install things have been done. Nov 14 11:23:22 rburton: good to know; I am using armv7 here Nov 14 11:24:56 LetoThe2nd Perfect, thanks Nov 14 11:49:36 New news from stackoverflow: bitbake do_image dependency not cached Nov 14 13:11:19 My HW has no RTC when power is off. I notice that the system time is set to April 2018 on startup, which is far older than the image date. Is this a mechanism of Yocto/poky? If so, where in the codebase is this logic located? Nov 14 13:12:27 sveinse: usually it is the release date of the systemd version in use, or something similar Nov 14 13:12:37 (read: its no OE magic, but systemd's) Nov 14 13:13:03 LetoThe2nd: ok, thanks Nov 14 13:13:24 assuming that you are using systmd, of course. Nov 14 13:13:57 LetoThe2nd: I am, so this is a very plausible explaination Nov 14 13:27:05 If I want to disable debug-tweaks, can I just delete EXTRA_IMAGE_FEATURES, or do I need to set it as an empty string? Nov 14 13:33:27 la_croix_: i personally would set an empty string, but deleting will almost certainly work too Nov 14 13:34:24 LetoThe2nd Ok. I'm having a bit of a problem with this recipe. Half of it works (my public key is in authorized_keys), but it doesn't seem to be using my new sshd_config Nov 14 13:35:31 so you have a seperate ssh-keys recipe now? or are you appending openssh? Nov 14 13:37:18 I have a separate ssh-keys recipe now, exactly as you linked Nov 14 13:38:19 https://pastebin.com/vAazcTRS Nov 14 13:39:06 Authorized keys is working, as I can login with no password only if I have that key, but it doesn't seem to be using my sshd_config. I always change the port to a random one, but it is still listening for ssh on 22 Nov 14 13:39:09 ah! Nov 14 13:39:22 the FILES_${PN} hitng is recipe specific. Nov 14 13:40:29 Oh, so that will be adding it so ssh-keys-server? Nov 14 13:40:38 Which doesn't exist, presumably Nov 14 13:41:30 so this recipe only installs the key. plus, its rather pointless to split the recipe in -client and server. so this https://pastebin.com/mFt3jDm8 should work as the key-deployment recipe Nov 14 13:41:35 Can I just change it to FILES_${PN}? Nov 14 13:42:09 for modifying a file provided by openssh, you have to append to openssh Nov 14 13:42:19 Oh, ok. Nov 14 13:42:57 and the FILES_ from openssh applies to whatever you do in openssh, the FILES_ in your recipe applies to whatever you do in your reciope Nov 14 13:44:15 Ok, so I need a new recipe, with sshd_config in the files, and a bbappend file (rather than a bb file)? Nov 14 13:50:07 no the new recipe *is* the bbappend file Nov 14 13:50:40 if you look here http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/openssh/openssh_7.9p1+git.bb#n15 Nov 14 13:51:09 the original one already has the file. so just bbappend it to replace. Nov 14 13:55:41 Would this work? https://pastebin.com/DPZpuspF Nov 14 13:56:04 Named openssh_%.bbapend Nov 14 13:56:07 *append Nov 14 13:57:31 i think this is enough https://pastebin.com/22fuWrL9 Nov 14 13:57:38 named and pathed properly Nov 14 13:58:42 Does this constitute 'named and pathed correctly'? https://pastebin.com/t5eEEMJV Nov 14 13:59:45 sounds ok. go ahead and try ;-) Nov 14 14:00:10 :) Nov 14 14:21:23 LetoThe2nd That doesn't seem to have made any difference :/ Nov 14 14:22:15 hm Nov 14 14:23:13 It is still allowing root password access, and still on port 22 Nov 14 14:23:23 Not that I've any idea what yocto's default root password is... Nov 14 14:27:31 oh did you turn off debug-tweaks image feature? Nov 14 14:27:47 if that is on, it goes in and allows root with no password at rootfs time Nov 14 14:29:23 rburton Yes, I've removed it Nov 14 14:33:21 To disable password authentication I am using: "PasswordAuthentication no", "ChallengeResponseAuthentication no" and "UsePAM no" Nov 14 14:34:21 tristanram I'm only using PasswordAuthentication no, but that should be enough Nov 14 14:34:29 la_croix_: seems confusing, you added a user whhy not just add thheir key in the users recipe Nov 14 14:34:43 OutBackDingo I haven't added a user... This is for root Nov 14 14:35:01 la_croix_: ssh as root ? yikes Nov 14 14:35:28 OutBackDingo Indeed, it's not the production plan, I'm just trying to do things one step at a time, until I actually understand now yocto works :P Nov 14 14:36:51 la_croix_: not always: https://blog.tankywoo.com/linux/2013/09/14/ssh-passwordauthentication-vs-challengeresponseauthentication.html Nov 14 14:36:56 la_croix_: couuld also do a simple root-uuser recipe with USER="root" Nov 14 14:36:56 do_install() { install -d ${D}/home/${USER}/.ssh/ install -m 0755 ${S}/id_rsa.pub ${D}/home/${USER}/.ssh/authorized_keys} Nov 14 14:37:30 i guess i tend to avoid patching up the meta- repos Nov 14 14:37:48 tristanram I've always wondered what that was about... Looks like you're right. Thank you :) Nov 14 14:38:29 la_croix_: like rburton said patch hack test hack test :) Nov 14 14:39:01 la_croix_: this is my append for doing something similar as I think you are trying to do: https://github.com/tramseyer/meta-medusa-dist/blob/master/recipes-connectivity/openssh/openssh_%25.bbappend Nov 14 14:39:21 OutBackDingo I'm working on that, but currently I'm such a noob that it's more patch - hack - test - cry - beg for help Nov 14 14:39:53 la_croix_: your could also create a custom layer withh the ssh_%/bbapend itll still patch yy=up thhe sshh Nov 14 14:40:23 this way your not hacking up the meta- layers themselves and run into conflicts when updating Nov 14 14:40:56 OutBackDingo Oh, this is already in a new layer, and using bbappend Nov 14 14:41:08 la_croix_: ahh cool Nov 14 14:41:15 see yoour ahead of the game now :) Nov 14 14:41:42 OutBackDingo Haha, try to remember me like this, rather than as I am in twenty minutes when I ask 30 stupid questions ;) Nov 14 14:42:59 tristanram To clarify, your .bbappend actually modifies (with sed) the original sshd_config at build time, rather than overwriting it with a new config. Is that correct, and if so, why is that better? Nov 14 14:50:00 la_croix_: Yes, correct. Its not necessarily better but it takes the "original" sshd_config file and modifies it according to my needs. If the sshd_config will be extended upstream by new values I will get those for free. Nov 14 14:51:19 tristanram Good point... OK, sounds good :) Nov 14 14:53:06 la_croix_: Case 1: File to be modified is in some layer such as http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/openssh/openssh/sshd_config?h=sumo -> I will patch it via sed altough it may be a little brittle. Nov 14 14:54:49 la_croix_: Case 2: File to be modified is in a git repo where the SRC of the recipe comes from such as https://github.com/tramseyer/meta-medusa-dist/blob/master/recipes-connectivity/bluez5/bluez5/bluetooth.service.in.patch -> I will create a patch since git-patching is much more robust and verbose than sed stuff. Nov 14 14:55:28 tristanram Ok, fair enough Nov 14 14:56:18 I think I'll actually prevent root login, and create a user, though Nov 14 14:57:19 case 3) no ssh in prodcution devices :-) Nov 14 14:57:44 LetoThe2nd ... I actually hadn't thought of that, and that probably makes sense Nov 14 14:58:45 la_croix_: :-) Nov 14 14:59:00 How do I remove openssh from an image? ;) Nov 14 14:59:12 la_croix_: why remove it? do not add it in the first place. Nov 14 14:59:19 ls Nov 14 14:59:21 Oops Nov 14 15:00:22 LetoThe2nd I'm using a layer called 'meta' which already includes it Nov 14 15:00:37 i mean, i have totally no fear anybody exploits telnet, ssh, or anything like that on one of my products. it not only that they're not activated, "but there for...", i make totally sure that the binaries are absolutely never ever shipped. Nov 14 15:00:44 la_croix_: i am pretty sure that this is not true Nov 14 15:01:27 la_croix_: because meta is basically oe-core, and it certainly does not pull openssh into images by default. Nov 14 15:01:54 la_croix_: so its either the specific image you use, or something in your distro (which would be stupid, but hey, possible) Nov 14 15:02:26 LetoThe2nd Hmm... I have meta/recipes-connectivity/openssh with files and a .bb file Nov 14 15:03:10 la_croix_: just because a recipe is there, it does not end up in an image. this is like saying that everything available in the debian package repositories is always installed. (not true either) Nov 14 15:03:45 Oh, fair enough. In that case, where might I find the thing that is (currently) telling it to install it? Nov 14 15:03:49 la_croix_: so either something pulls it in through IMAGE_INSTALL or IMAGE_FEATURES Nov 14 15:03:58 Ok, I'll have a look Nov 14 15:04:07 la_croix_: again, bitbake -e your image target and search it Nov 14 15:08:18 There's nothing in image_install or image_features, and grepping the output of bitbake -e does not contain 'openssh' Nov 14 15:09:47 and did you grep for ssh? Nov 14 15:11:12 LetoThe2nd Yes, it turned up here: 'SSH_CLIENT': '5.66.10.68 58041 22', 'XDG_DATA_DIRS': '/usr/local/share:/usr/share:/var/lib/snapd/desktop', 'BUILDDIR': '/home/ubuntu/dev/poky/build', 'SSH_TTY': '/dev/pts/0', But I'm not sure that tells us why it is being included Nov 14 15:12:17 Aside from that it turns up at the very top, but that seems to relate to the machine on which the build is being performed, rather than the target image Nov 14 15:12:52 la_croix_: yeah that sounds about not right. Nov 14 15:14:30 la_croix_: do a bitbake -g of your image and pastebin the result, please. Nov 14 15:18:50 pastebinit can probably help: bitbake -g $YOURFUNNYIMAGE | pastebinit Nov 14 15:19:19 What is pastebinit? Nov 14 15:19:31 Oh, just googled it, genius Nov 14 15:19:50 Does it get around the 512kb limit? Nov 14 15:19:57 go and fine out. Nov 14 15:20:04 s/fine/find/ Nov 14 15:20:53 http://paste.ubuntu.com/p/2jgwM8sP4Z/ Nov 14 15:21:01 This is the closest I've seen to magic. Nov 14 15:21:49 ah dang. i meant, pastebin the file package-depends.dot Nov 14 15:21:57 sry. but again something learned :) Nov 14 15:23:57 LetoThe2nd Ah, http://paste.ubuntu.com/p/Hcfz2GmjgG/ Nov 14 15:25:04 you're building image-core-cmdline-full? Nov 14 15:25:26 erm, core-image-full-cmdline Nov 14 15:27:01 Yup... That's wrong, I assume? Nov 14 15:27:24 nothing wrong so far, i'm just looking at it Nov 14 15:30:28 Hi all, Is it possible to call a task from other task ( I dont want add a depends ) Nov 14 15:31:16 la_croix_: i am pretty certain that something, somewhere sets IMAGE_FEATURE ssh-server-openssh Nov 14 15:31:38 LetoThe2nd Presumably if I were building one of the smaller core-images it would not be included? Nov 14 15:31:40 la_croix_: thats what you have to find, as thats basically explicitly pulling in openssh. by default, core-image-full-cmdline would not do it. Nov 14 15:31:54 LetoThe2nd Ah... Nov 14 15:31:58 la_croix_: no, because if that is set, it get pulled into any image. Nov 14 15:32:24 I'll check the mender layers Nov 14 15:33:19 ack-grepping your working directory probably is enough Nov 14 15:35:47 LetoThe2nd http://paste.ubuntu.com/p/97Jp86VBwg/ is the result Nov 14 15:36:10 LetoThe2nd Does that mean the disabling ssh will break mender? Nov 14 15:36:43 la_croix_: i can't comment on any mender thing, as i've never used it. Nov 14 15:37:53 Ok, I'll find out if it's necessary Nov 14 15:41:41 In the meantime I'll figure out how to add a user Nov 14 15:44:42 Presumably that can be done in local.conf, with the EXTRA_USERS_PARAMS Nov 14 15:45:24 la_croix_: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb Nov 14 15:55:57 LetoThe2nd Thank you. What does those files (file1, file2...) do? Nov 14 15:57:34 la_croix_: those are literally just exmples to show how to set owner etc. on files that are being installed Nov 14 15:58:08 LetoThe2nd Ok... I'll try to figure this out. I thought adding a user might be easier :P Nov 14 15:58:52 la_croix_: *hint* think more if you actually need a user, and what for. what is it your device shall do, what processes run, under what user. Nov 14 15:59:32 la_croix_: in many cases you actually do not need an exmplicitly set up user either, but the implicitly exiting root and www (or comparable) are enough Nov 14 16:00:44 LetoThe2nd I can just run as root. All it does is read from a load of sensors (either wired or mqtt) and sends a port request Nov 14 16:00:55 la_croix_: in embedded devices, some thinking models are a bit different than on desktops :) Nov 14 16:00:55 s/port/post Nov 14 16:01:30 LetoThe2nd So you think I should just leave it as root Nov 14 16:01:32 ? Nov 14 16:02:11 no, you got that wrong. this does not mean "run as root". it means: "often a suitable user is already there, becasue you rely on something that brings it along. like lighttpd or apache" Nov 14 16:03:35 Well, my code itself has to run as something (a python script aggregating the data and making the POST) Nov 14 16:04:20 ok, then a user might be sensible to create, yes. Nov 14 16:05:38 I think I've worked out why the sshd_config changes didn't work... It seems to be using dropbear instead of openssh Nov 14 16:08:51 LetoThe2nd If this is anything to go by: https://pastebin.com/X9YbrrBj Nov 14 16:10:17 Actually no, it's not in the manifest Nov 14 16:12:59 you have to add it to IMAGE_INSTALL Nov 14 16:13:05 time to create your own image :) Nov 14 16:13:15 i gotta run now. worktime is voer! Nov 14 16:15:24 LetoThe2nd Ok, thanks for your help :) Nov 14 17:19:36 Could somebody give me a hand with adding a user? I'm using this recipe, and the build error is at the bottom: https://pastebin.com/pFLe1bVi It seems to be referring to files added by useradd, but they're not added in my recipe... Nov 14 17:24:19 Sorry, error is here: https://pastebin.com/iQec8JLD Nov 14 17:29:21 *https://pastebin.com/gUpa7uy1 Nov 14 18:37:58 /join #rpm Nov 14 18:39:16 Hi Nov 14 18:39:41 how to build jamvm 2.0 recipe with openjdk8 runtime library Nov 14 18:40:16 by default it selects GNU classpath but when I specify --with-java-runtime-library=openjdk8 in jamvm.inc Nov 14 18:40:23 there are many build errors Nov 14 18:41:12 anyone tried it, I am completely stuck Nov 14 18:54:02 anyone can please provide some pointers on jamvm recipe with openjdk8 for ARM Nov 14 19:52:24 rizwan_: you'll have more luck by mailing the list with the actual errors Nov 14 20:21:24 New news from stackoverflow: Yocto find the recipe or class that defines a task Nov 14 20:30:06 it looks like you can get dnf to work from here: https://wiki.yoctoproject.org/wiki/TipsAndTricks/EnablingAPackageFeed Nov 14 20:30:25 instead of a repo being on the network, could it be on a thumbdrive? Nov 14 20:30:31 "baseurl="file://thumb-drive/repo" ? or somesuch? Nov 14 20:57:18 hmm, getting bitbake tracebacks related to the recent changes to the s hallow logic. interesting. /me digs Nov 14 20:57:26 rburton: Are you still here? Nov 14 20:58:09 Exception: AttributeError: 'FetchData' object has no attribute 'fullshallow' Nov 14 21:34:28 ugh, fix that and get even more failures. this time git fails to lock config after unpacking the fetched git mirror tarball for pseudo-native, *warns* about the failure to clone, b ut then continues to do_unpack and fails due to a missing clonedir? Nov 14 21:34:36 how much did the latest fetch patch series break things, honestly Nov 14 21:35:03 (trying,a nd failing, to update from sumo to thud) Nov 14 21:46:55 kergoth: the gitsm one? Nov 14 21:52:16 there have been loads of changes. Nov 14 21:53:02 they seemed like a good thing to have in sumo but don't know how easy its going to be to backport Nov 14 21:53:13 kergoth: ah, that patch :/ Nov 14 21:53:54 kergoth: I try hard to keep things working and do good review but its tough :( Nov 14 21:54:01 not sure which ones are causing my issues, hitting a few errors. fetching is so hard to test. exercising every codepath and possible DL_DIR state is almost impossible Nov 14 21:54:36 kergoth: indeed. The tests are good but not that good, clearly :/ Nov 14 21:54:44 reminds me of a quote in my quotes file: "The file system is best viewed as a multi-threaded object over which you have no reliable synchronization capabilities" Nov 14 21:55:11 kergoth: I wonder what that makes NFS? :) Nov 14 22:26:51 JPEW: not really. email? Nov 14 22:28:07 rburton: I was just wondering if I should assign https://bugzilla.yoctoproject.org/show_bug.cgi?id=13020 to myself, I can wait until the bug triage call tomorrow if necessary Nov 14 22:28:08 Bug 13020: normal, Undecided, ---, apoorv.sangal, NEW , meta-mingw needs testing Nov 14 22:52:55 * armpit ahaahah spam from Stephen Nov 14 22:54:09 JPEW, we assign all bugs to zeddii **** ENDING LOGGING AT Thu Nov 15 03:00:00 2018