**** BEGIN LOGGING AT Mon Feb 17 02:59:57 2020 Feb 17 07:22:55 hey guys, quick question: I'm having trouble cloning the yocto repos. Is the git server down for maintenanceor is there any other reason? Feb 17 07:38:43 justCheckin: it's OK Feb 17 07:55:15 strange. now I get a connection timeout Feb 17 07:55:24 thank you! Feb 17 08:59:50 Greetings, having a bit of trouble with sem_timedwait() and was hoping anyone could help; Feb 17 09:01:36 pretty much, need sem_timedwait() to run on CLOCK_MONOTONIC instead of CLOCK_REALTIME, is anyone familiar with any patches that do this? Feb 17 09:02:13 hello, I am trying to set ssh connection between my host windows machine and my linux embedded board system ( which I build with yocto project ) . I installed the ssh in my image. I m following these steps Feb 17 09:02:26 https://docs.microsoft.com/en-us/cpp/linux/set-up-fips-compliant-secure-remote-linux-development?view=vs-2019#to-create-and-use-an-rsa-key-file Feb 17 09:02:31 It's fine if there is a sem_timedwait_monotonic function instead, but I need to be able to reset CLOCK_REALTIME without it affecting sem_timedwait Feb 17 09:02:49 but when I try to copy the public key to linux using this command Feb 17 09:03:02 scp %USERPROFILE%\.ssh\id_rsa.pub user@hostname: Feb 17 09:04:00 it tells me , ssh: could not resolve hostname sama5d27-som1-ek-sd: H\364te unknown Feb 17 09:04:30 Can you ping the host? Feb 17 09:04:35 user@hostname: is root@sama5d27-som1-ek-sd: Feb 17 09:04:51 ping sama5d27-som1-ek-sd Feb 17 09:05:40 it is fine with ping Feb 17 09:05:43 no problem Feb 17 09:09:51 Ok, then garbage characters at the end probably Feb 17 09:10:01 Try typing the line manually Feb 17 09:10:48 Oh, before that, try ssh user@hostname Feb 17 09:11:30 a lot of hosts does not allow remote root logins as well, could be that. Feb 17 09:12:42 ssh root@sama5d27-som1-ek-sd tells me that : Feb 17 09:12:45 ssh: Could not resolve hostname sama5d27-som1-ek-sd: Temporary failure in name resolution Feb 17 09:42:58 There you have the problem then Feb 17 09:43:01 It's a DNS issue Feb 17 09:43:14 Sorry for late reply, busy at work Feb 17 09:48:24 wertigon No problem. What's matter with the DNS, How can I fix it ? Feb 17 10:18:27 ok nevermind. we had an issue with our firewall. Thanks again for checking the status and bye bye Feb 17 10:24:17 BAm I the only one getting spammed by MSC? Feb 17 10:24:57 abelloni: hm? Feb 17 10:25:49 I'm getting an email from them for every patch I have in meta-freescale, oe-core and meta-qt5 Feb 17 10:26:41 didn't note anything, but i also don't have patches in there, methinks. Feb 17 10:31:26 abelloni, me too Feb 17 10:31:57 I tried to reply to postmaster but it rejects the mails Feb 17 10:33:59 anyone from MSI here? You're sending git commit notifications to outside e-mails and marked as confidential.. I got over 2000 today, please stop Feb 17 10:34:38 MSI? like, the HW vendor or what? Feb 17 10:34:53 postmaster@msi.com.tw Feb 17 10:35:00 hrhrhr Feb 17 10:37:23 * LetoThe2nd goes to check if they are a YP member.... Feb 17 10:37:31 it even includes colorful git diffs instead of regular plain text.. how knows how much bigger it is :) Feb 17 10:38:35 a German saying basically goes like "If I could only work with pros ONE TIME..." Feb 17 10:39:53 unfortunately in .tw they are at the end of the working day now Feb 17 10:45:31 do you know if there has been any progress on the procedure to remove busybox from the final image? Feb 17 11:07:20 * RP has stared at reproducibility and hashequiv for a few hours and already has a headache :( Feb 17 11:07:55 JaMa: I saw those for my meta-oe commits, I dread to think how many you/khem get Feb 17 11:08:07 Hello, I have a problem with IP adress of my embedded board which booting with Linux image build with yocto project . In fact, when I enter " ifconfig " command in the board terminal, it gives me localhost IP adress which is 127.0.0.1 and not the public IP adress Feb 17 11:08:22 How can I find the other IP adress please ? Feb 17 11:09:57 gaston4: if ifconfig doesn't give you another address, then the board doesn't have one. Feb 17 11:10:12 gaston4: having said that, usually one should prefer "ip a" these days. Feb 17 11:10:30 LetoThe2nd: `ip addr` even, more explicit :) Feb 17 11:10:41 qschulz: explicit++! Feb 17 11:10:44 gaston4: do you have another interface than lo on your defice? Feb 17 11:10:50 device* Feb 17 11:11:08 probably the board just doesn't bring the interface up, if its not told to do so. Feb 17 11:11:45 qschulz eth0 and inet Feb 17 11:12:07 qschulz I mean eth0 and lo Feb 17 11:12:20 is eth0 up? Feb 17 11:12:30 gaston4: which form of network management are you using? Feb 17 11:13:04 how can I verify if it's up or not ? Feb 17 11:13:16 qschulz ^^ Feb 17 11:13:19 ip a tells you. Feb 17 11:14:12 eth0: Feb 17 11:14:16 gaston4: also... have you run any dhcp client on your interface? Feb 17 11:14:22 udhcpc -i eth0 for example Feb 17 11:14:35 I mean that i read an interesting thread about removing busybox in ML and I was wondering if this topic has been discussed by the TSC Feb 17 11:15:29 mckoan: i remember the thread. it been a while, right? Feb 17 11:15:38 qschulz udhcpc: started, v1.27.2udhcpc: sending discoverudhcpc: sending discoverudhcpc: sending discover Feb 17 11:15:52 gaston4: FYI many things in embedded systems aren't as automatic as they are on desktop distros Feb 17 11:16:14 does this have any relation with SSH ? Feb 17 11:16:34 gaston4: define "this" Feb 17 11:16:37 LetoThe2nd: yes, Feb 19 Feb 17 11:17:11 qschulz the unfound IP adress Feb 17 11:17:33 gaston4: ssh doesn't work if you don't have an ip address. thats the relation. Feb 17 11:17:43 mckoan: 2019? Feb 17 11:17:58 because I can find that ssh is running on my board Feb 17 11:18:06 gaston4: where is your eth cable connected to? Feb 17 11:18:32 gaston4: most likely listening on 0.0.0.0, i don't think it matters Feb 17 11:19:21 Jack port Feb 17 11:19:26 of the embedded board Feb 17 11:19:35 gaston4: the other side of the ethernet cable I meant Feb 17 11:19:45 do you have a DHCP server on the network you're connected to? Feb 17 11:19:47 qschulz: have fun. Feb 17 11:21:14 LetoThe2nd: it can apparently be called jack or socket as well as Ethernet port :) Feb 17 11:22:59 "plug". Feb 17 11:23:05 "döngle" Feb 17 11:23:10 "thingie" Feb 17 11:26:56 LetoThe2nd: sigh, you scared them away Feb 17 11:27:00 :) Feb 17 11:27:37 LetoThe2nd: yes Feb 17 11:27:59 \m/ O \m/ Feb 17 11:39:55 mckoan: i have not noticed any follow-up activity so far. Feb 17 11:49:24 Hi, I want to create custom machine basing on raspberrypi4 so that I can put uboot paramets configuration in git not in local.conf Feb 17 11:50:04 How to change machine name and still inherit all the config of e.g. raspberrypi4-64. When I require this file it still fails at building kernel etc Feb 17 11:56:45 tolszak_: only the uboot parameters? why not .bbappend for recipes which use them instead of whole new machine config? Feb 17 11:57:22 or override them in your distro config with machine override Feb 17 12:08:20 JaMa: Seems like overriding rpi-config.bb is the safest option then Feb 17 12:08:22 thanks Feb 17 12:08:34 JaMa: I want image to be machine agnostic Feb 17 12:13:55 Hmm, I wish I could specify the proper clock with sem_timedwait... Feb 17 12:14:45 Or rather, I wish I could specify CLOCK_MONOTONIC or CLOCK_MONOTONIC_RAW with sem_timedwait Feb 17 12:14:57 Anyone know if the RT patches fix this in some fashion? Feb 17 12:19:53 tolszak_: you can't change the u-boot parameters from the image recipe anyway. You can do as JaMa suggested. If you want to do more changes wrt the machine, you will want to have your own layer with a new machine in there (conf/machine/mymachine.conf). This one will "require raspberrypi4-64.conf" and then you just need to override the variables from your file. That should do it. Feb 17 12:35:46 where does this "#yocto" come from lately on the ML? Feb 17 12:36:19 LetoThe2nd: hashtag everything #hastag #youngster #newbehavior Feb 17 12:36:38 #beer Feb 17 12:37:19 aahrhg, fix one repro issue and then the gstreamer one pops up again Feb 17 12:39:02 Hmmm... Feb 17 12:40:00 This is... Actually pretty bad, how the *bleep* can you even use sem_timedwait in any capacity with CLOCK_REALTIME? Feb 17 12:40:33 It's a DoS waiting to happen, all you need to do is set the system clock to now+a year and the entire system caves Feb 17 12:41:29 how do I set the directory where CMakeLists.txt is searched? I thought it's S, but I keep getting the same error Feb 17 12:41:34 Proof of concept: Feb 17 12:42:25 thread1() { sem_timedwait(&sem, 5000); } Feb 17 12:42:42 stuom1: it should be, AFAIK Feb 17 12:43:15 thread2() { sleep(3); set_system_clock(now - 300000); } Feb 17 12:43:38 thread1 wakeup time: 302000 ms from now Feb 17 12:43:39 :D Feb 17 12:43:48 wertigon: i understand the need to vent, but how shall we help if the api currently just is like that? Feb 17 12:44:24 Yeah, that's the thing - are you even supposed to use the sem_* API, like, at all? Feb 17 12:45:05 wertigon: what does man7 say about it? Feb 17 12:45:12 I can probably hack something userspacey together using sem_trywait or something like that Feb 17 12:46:30 i mean, its often problem domain specific - but in my daily life any form of RT requirement and a semaphore don't go together anyways. Feb 17 12:48:00 Yeah, in this case a sync protocol is used to constantly adjust the realtime clock Feb 17 12:48:06 PTP Feb 17 12:48:28 LetoThe2nd: thanks for confirmation. Now, the problem is that why is my S not changing whatever I put there...grepping from bitbake -e I can see it remains the default Feb 17 12:48:45 Which means we need to use the CLOCK_MONOTONIC Feb 17 12:48:53 Or CLOCK_MONOTONIC_RAW Feb 17 12:48:59 stuom1: you inherited cmake, and no other magic is invoked? Feb 17 12:49:09 yes Feb 17 12:49:17 stuom1: you'll be interested in checking what;s above ^S= in bitbake -e Feb 17 12:49:18 And this "feature" seems to have been known for at least 8 years, too Feb 17 12:49:58 stuom1: this will give you which line in which file your S is appended/prepended/set etc... Feb 17 12:51:08 qschulz: there is nothing above Feb 17 12:51:58 stuom1: there sure is Feb 17 12:53:24 bitbake -e | grep ^S= gives just one line output Feb 17 12:53:48 yes, because you grep for it Feb 17 12:54:01 pipe it into less/more/a file Feb 17 12:54:02 stuom1: don't grep, use less and read whats noted above that one line. Feb 17 12:54:06 qschulz: hi5 Feb 17 12:54:10 aa Feb 17 12:54:13 bb! Feb 17 12:54:23 LetoThe2nd: hi5 :) Feb 17 12:56:56 JaMa: When I bbappend rpi-config I got: "do_rootfs: The license listed GPLv2 was not in the licenses collected for recipe linux-raspberrypi" Feb 17 12:57:25 JaMa: and it fails on "No such file or directory: '*/tmp/deploy/licenses/rpi-config/recipeinfo'" Feb 17 12:57:34 tolszak_: what's your change? Feb 17 12:59:16 Currently it only contains: https://pastebin.pl/view/fc2a1a5f Feb 17 12:59:35 I tried to set different LICENSE with the same output Feb 17 12:59:50 qschulz: ^ Feb 17 13:02:00 Bah, humbug. I'll just do a trywait solution in user space instead :) Feb 17 13:02:07 qschulz: Sorry I'm still newbiew with yocto Feb 17 13:02:55 tolszak_: why do you change the license? what's the name of the file with the pasted content? Feb 17 13:03:03 tolszak_: Try LICENSE=GPLv3? Feb 17 13:03:10 Without = Feb 17 13:03:12 *? Feb 17 13:03:40 qschulz: from output it seems it is overwritten by externalsrc.bbclass, why is that? Feb 17 13:03:44 qschulz: I just tried to overcome error, when I set not license it is the same, the file is rpi-config_%.bbappend Feb 17 13:05:42 It failes on function license_deployed_manifest Feb 17 13:05:59 stuom1: because externalsrc replaces it :)? https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/externalsrc.bbclass?h=zeus Feb 17 13:06:06 set EXTERNALSRC instead Feb 17 13:07:33 I removed the rpi-cinfig_%.bbappend file and it is the same Feb 17 13:07:45 probably cached got corrupted Feb 17 13:07:56 I will rebuild everything from scratch just to double check Feb 17 13:08:35 tolszak_: don't forget the \ at the end of each line in RPI_EXTRA_CONFIG Feb 17 13:08:51 and don't change the license. Never :) Feb 17 13:09:49 qschulz: yes but why :) I've never before seen this problem, and I dont inherit externalsrc Feb 17 13:09:51 tolszak_: bitbake -c cleansstate rpi-config and rebuild your image, no need to remove everything Feb 17 13:10:31 tolszak_: maybe even bitbake -c clean rpi-config would be enough? Feb 17 13:10:48 stuom1: you might be inheriting a class which inherits externalsrc Feb 17 13:11:01 but from what you're saying, externalsrc is definitely inherited somewhere Feb 17 13:11:39 qschulz: cleansstate on image was not enough, I haven't tried do it explicitly on rpi-config Feb 17 13:12:07 qschulz: there is only cmake inherited Feb 17 13:12:22 qschulz: but I have all caches in separate dirs and sata 4 ssd so no I'm on 13% of image creation Feb 17 13:13:40 tolszak_: cleansstate needs a recipe. If you're doing it on the image recipe, you're cleaning only the sstate-cache of the image recipe, not all the recipes built to make the image. Feb 17 13:14:18 stuom1: Yocto apparently tells us the opposite. Send the content of your recipe if you can Feb 17 13:14:25 qschulz: good to know, seems like when I tried to change machine name I corrupted something Feb 17 13:14:59 qschulz: Everything works as exptected, I should have been do clean build before I go to you. I'm really sorry for taking your time Feb 17 13:15:30 tolszak_: throw money at qschulz! or beer! Feb 17 13:15:33 qschulz: I initially tried to make custom machine and put config there and inherit raspberrypi4-64.conf machine Feb 17 13:20:00 LetoThe2nd: I just found him on github :) Feb 17 13:21:19 tolszak_: :) Feb 17 13:26:18 qschulz: it's very barebones at the moment https://pastebin.com/fXHBGi3n Feb 17 13:33:16 do ww have any built-in magic for getting core dumps to a specific location, like an sd card? Feb 17 13:36:46 LetoThe2nd: we'd like magic ;-) Feb 17 13:36:57 RP: so nothing there yet? Feb 17 13:38:33 RP: Regarding the recent work on reproducible (great work!), is WIC covered as well? Feb 17 13:39:31 like2wise: I doubt that is tested by the current tests Feb 17 13:39:41 (sadly) Feb 17 13:42:29 RP: Also, can the community help to reproduce one specific commit on a variety of build environments? and assert we end up with the same string of bits in the resulting images? Feb 17 13:43:44 RP: I think currently mainly the time and paths indifferences are tested on your test setups? Feb 17 13:43:49 like2wise: certainly open to help. the autobuilder shares the milestone release artefacts so it could be an idea to compare against those? Feb 17 13:44:06 RP: yes, sounds like a good plan. Feb 17 13:44:17 like2wise: we test on different distro hosts which is the main cause of pain Feb 17 13:44:39 like2wise: they are all fairly minimal installs so larger installs may reveal more "fun" Feb 17 13:59:32 stuom1: have you used devtool with your recipe by any chance? Feb 17 13:59:51 qschulz: yes Feb 17 14:03:59 stuom1: there you go :) Feb 17 14:04:09 stuom1: devtool makes use of externalsrc Feb 17 14:04:26 stuom1: and until you do devtool reset the "devtool-ed" recipe will be used Feb 17 14:06:43 qschulz: ok, but i still dont understand what is wrong. I have used devtool with tens of recipes the same way. Bitbake it, get error, modify until works. Is it something specific to S that I cannot change that? Feb 17 14:06:43 stuom1: or let's say it this way, devtool creates bbappends for your recipes where externalsrc is inherited Feb 17 14:07:35 stuom1: but then you ran devtool reset when you finished your work, or didn't modify S Feb 17 14:09:34 qschulz: probably I didnt before edit S. Now I know that is the one variable I cannot change :P thanks for help! That bbappend seems to be the culprit Feb 17 14:09:52 stuom1: EXTERNALSRC path is hardcoded in the bbappend created by devtool Feb 17 14:10:07 when you're finished with devtool, always run devtool reset :) Feb 17 14:10:53 I don't know unfortunately how devtool creates those variables so can't say if there's something we could do better Feb 17 14:12:03 maybe we could use S from the original recipe and strip WORKDIR from it and append the workspace directory from devtool Feb 17 14:12:38 so that modifications to S in the original recipe are propagated when devtool is used Feb 17 14:19:46 Hello Guys, Feb 17 14:21:21 Jay Rajput here. I came across the Yocto Project via Community Mentorship Guidelines. I have applied to the project and wish to contribute to it. I was told we will have to undergo an assesment. Can anyone please guide me on the same? Thank you Feb 17 14:23:04 halstead: hi. fyi, https://git.yoctoproject.org/cgit.cgi/poky/ returns 500 Feb 17 14:24:37 and before that, the default branch (when ?h= is not passed in the URL) was some very old branch (something like 1.1). Will report accordingly once I can access the git repo again :) Feb 17 14:26:26 @qschulz poky is not the only repo down :) Feb 17 14:27:38 nayfe: has it been reported publicly/privately to halstead so he does not have to test each and every of them :) ? Feb 17 14:27:46 tlwoerner: ping... do you know about GSOC particularities? Feb 17 14:39:17 Is there a problem with the git repo?, I can't clone https://git.yoctoproject.org/git/poky Feb 17 14:39:52 ljep: yes Feb 17 14:41:33 out git repo is picky about its firends today, it seems. Feb 17 14:48:26 ljep: yes, there is :( Feb 17 14:48:36 ljep: clone using git:// which works Feb 17 14:58:00 Anyone seen the "Internal Server Errors" on https://git.yoctoproject.org/cgit/cgit.cgi/poky/ ? Feb 17 14:58:16 mirzak: yes. clone using git:// Feb 17 14:58:52 qschulz: Was this an intentional change, that is https will not be supported anymore? Feb 17 14:59:14 mirzak: bad karma on the wires. Feb 17 14:59:31 mirzak: AFAIK, no. sysadmin is not in this EU TZ so we have to wait :) Feb 17 14:59:35 halstead: is doing some voodoo dances, but to no success so far. Feb 17 15:00:53 Thanks for the quick update Feb 17 15:01:28 LetoThe2nd: When you were making that video series and building for BBB, did you have any connectivity issues with the meta-ti layer? My build machines can't seem to reach git.ti.com Feb 17 15:02:20 tgamblin_: pick a number. Feb 17 15:02:42 tgamblin_: bad karma is upon our repo servertoday. Feb 17 15:03:38 Ah, I was hoping the TI site was more fortunate :) Feb 17 15:20:49 can somebody help me to run qemu without runqemu wrapper? Feb 17 15:26:10 ruru4143_: we wrote runqemu so we didn't have to remember all the options! Feb 17 15:28:33 Hello, after building the linux image using yocto project, I have build now SDK. But I want to know the PATH of toolchain file of this SDK. Does anybody have an idea please ? Feb 17 15:29:10 You tell it where to put the sdk when you run its installer Feb 17 15:29:34 super: source the environemnt script that comes with it, it sets all the necessary things. Feb 17 15:30:26 Anyone got issues seeing the poky repo this afternoon? Feb 17 15:30:35 JoeR: everybody. Feb 17 15:30:54 Cool. As long as it's not just me :-) Feb 17 15:31:00 qschulz halstead > nop, meta-java still has https access down Feb 17 15:31:07 Shan't try and fix a problem that isn't mine! Feb 17 15:32:05 it's /opt/poky-atmel/2.5.3 Feb 17 15:33:02 but when I use this path in visual studio 2019 in order to compile my c++ program using this sdk it tells me that there is no toolchain file in this directory Feb 17 15:33:42 super: I guess you need to give the full path to g++ Feb 17 15:34:56 super: are we really talking about *visual studio*, not *visual studio code*? Feb 17 15:35:23 super: because if windows is involved, well then.. have fun, and get a pack of painkillers for your upcoming headaches. Feb 17 15:35:54 yes it's visual studio 2019 under windows Feb 17 15:36:21 and want to use the sdk to compile the c++ code Feb 17 15:36:35 with CMake project Feb 17 15:36:58 super: i'd rather try and construct a mingw toolchain. having said that, 2.5.3 is not exactly up to date either. Feb 17 15:37:23 super: and no idea if VS can actually use a toolchain that only work in the WSL subsystem. Feb 17 15:38:23 super: on the other hand, if you get it to work, post a tutorial on youtube and become famous real quick! Feb 17 15:38:44 Actually lol'd at that. Feb 17 15:38:56 i'm not kidding this time. Feb 17 15:39:02 hahaha you are making me so optimistic ;) Feb 17 15:39:44 You'd be better off spinning up a linux VM and doing it all in there. Feb 17 15:40:10 yeah, a vm and the vs remote extensions might be easier. maybe. Feb 17 15:40:25 if you get it that to work, post a tutorial on youtube and become famous real quick too! Feb 17 15:41:00 RP: oh. that makes sense... then i will figure it out myself Feb 17 15:41:25 That's making me laugh of myself now Feb 17 15:42:33 ruru4143_: I'd look at the command runqemu generates and then tweak as needed Feb 17 15:42:53 super: seriously. we're having enough hassles with the linux only workflow already, we're not exactly involved with windows at all. so there's really business to be had, if you care. yet, its also a fair share of work probably. so much of it that most just resort to getting their stuff done in linux. Feb 17 15:43:18 RP: the problem is that the runqemu script is broken, but i will handel this, i think Feb 17 15:43:44 ruru4143_: what is wrong with it? should it be fixed? Feb 17 15:44:23 RP: my bitbake broke (on manjaro), its my everyday laptop... so bitbake -e doesn't work Feb 17 15:44:27 LetoThe2nd I will make a try and we will see Feb 17 16:02:01 error: Cannot fetch poky from https://git.yoctoproject.org/git/poky Feb 17 16:03:18 dl9pf: yes. git:// should work Feb 17 16:03:22 yes, its a known issue Feb 17 16:03:27 its being worked on Feb 17 16:03:42 dl9pf, It should work at the moment. Lots of intermittent failures with http:// until we've solved the issue. Feb 17 16:04:27 halstead, maybe http has today off for Presidents day ; ) Feb 17 16:05:09 armpit, that is my current working theory. Feb 17 16:05:35 halstead: https cgit works again for poky for me and I can't reproduce the weird branch redirection I was talking about so please ignore :) Feb 17 16:06:40 qschulz, It will work off and on for the next bit. Still troubleshooting. Feb 17 16:14:57 Looking into TI chip support in yocto, and meta-ti and meta-arago-distro. Does everything depend on binary toolchains and SDKs and blobs, or do the yocto source code toolchains also work? Feb 17 16:24:53 fray: you might like https://git.openembedded.org/bitbake/commit/?h=master-next&id=b4de909da648ee8911d2731af4888da75f344b33 Feb 17 16:25:07 in fact this should give some nice memory usage wins for everyone Feb 17 16:28:22 RP: Awesome! I'm going to try that right now Feb 17 16:28:47 JPEW: I should warn I've not widely tested yet :) Feb 17 16:29:14 In related news, I love tracemalloc, its just what I needed/wanted to fix this kind of issue Feb 17 16:29:23 * RP needs to write up a HOWTO on that Feb 17 16:30:57 Err, poky git seems to be down? Feb 17 16:31:01 or just me? Feb 17 16:31:06 oh good, it's not just me then Feb 17 16:31:08 JPEW: use git:/// Feb 17 16:31:18 well, not good, but *shrug* Feb 17 16:31:24 halstead is working on it Feb 17 16:31:45 $ git remote -v: upstream git://git.yoctoproject.org/poky (fetch) Feb 17 16:32:35 fatal: remote error: access denied or repository not exported: /poky Feb 17 16:33:05 JPEW: ah, I thought it was just my push access :/ Feb 17 16:33:18 halstead: looks like git access is now down too :/ Feb 17 16:33:20 it worked now Feb 17 16:34:00 looks like nothing hosted on git.yoctoproject.org is currently accessible :/ Feb 17 16:34:01 "worked", branch references show up as [deleted] Feb 17 16:34:35 Its not right, repos have disappeared on the backend Feb 17 16:36:40 RP, I had to move the repos on disk. It should be back now. Feb 17 16:38:05 halstead: looks better thanks. Let me know if I should stop pushing at any point! :) Feb 17 16:39:02 RP, Okay. Pushes should have failed for about 5 minutes there. Feb 17 16:39:09 And back up again. Feb 17 16:39:21 halstead: no problem Feb 17 16:41:14 How come pixz has been removed from later versions of poky? Feb 17 16:42:39 sveinse: doesn't xz have threading support itsself now? Feb 17 16:42:47 sveinse: http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-extended?h=thud&id=0c705d112736c90f6a9051c435d430f6aeb4842a Feb 17 16:44:22 @halstead still getting some errors when cloning via cgit/https: Feb 17 16:44:36 remote: fatal: failed to read object db6ba9cc294eb2d0405c953bfca6bda7774c8431: Permission denied Feb 17 16:45:15 algorhythm: which repo is that? Feb 17 16:45:23 poky Feb 17 16:45:37 trying to start of a toaster-based build, and that's the first thing it tries to clone Feb 17 16:47:16 RP, qschulz: ok, thanks. Pity thou. I will probably need to make a pixz shim or reimport the recipe into own layers. Our product upgrade is dependent on pixz('s interface) and it must be available before and after upgrade. Feb 17 16:47:20 We are also experiencing issues with cloning poky over http. Feb 17 16:48:30 hpsy: http is unreliable at the moment. Working on a fix. git:// will work for now. Feb 17 16:48:32 sveinse: adding the recipe to your own layer should be fine. Going forward we don't need it though Feb 17 16:49:06 halstead: Ok, thanks. Feb 17 16:49:36 @halstead thanks, i'll retry the build later on in that case :) Feb 17 16:49:55 RP: yep. The trouble with that is that will be forgotten. The beauty of using "official" recipes, is that they are alive and maintained. (Well, that's almost always the case, but that's a diffent discussion) Feb 17 16:58:55 sveinse: well, we have to move forward, its obsolete and likely won't see fixes even upstream :/ Feb 17 17:00:18 xz doesn't seem to use all cores by default like pixz, so you'll need to add additional options to tar to use it. :( Feb 17 17:00:32 RP: oh, is pixz an obsoleted tool? Feb 17 17:01:14 sveinse: if support is in xz itself, why would it be needed? Feb 17 17:02:15 RP: because it has a different interface Feb 17 17:02:43 mcfrisk: source code toolchain works for the most part Feb 17 17:03:08 sveinse: that may be but I can't see someone maintaining pixz just for that Feb 17 17:03:58 It breaks compatibility. Perhaps backwards compatibility is perhaps not the foremost priority in Yocto? (Not intending the comment in a flippant way, but out of interest) Feb 17 17:04:34 sveinse: we have to follow the upstreams really, we can't afford not to change Feb 17 17:04:48 jep, understand Feb 17 17:05:45 sveinse: we had interfaces using pixz but we migrated everything Feb 17 17:07:17 RP: So much better! my 5 multiconfig parse took less than ~2GB of working memory instead of 20! Feb 17 17:08:32 JPEW: cool, thought it should help :) Feb 17 17:09:35 RP: yep, I see that when grepping the code. This is just /a/ tool, so there not reason to sulk over it. The unfortunates is that this hits straight home in the product upgrade logic. The change triggers extensive validation tests as I have to change /something/ -- which I of course don't have time for now. Oh well. Feb 17 17:10:08 sveinse: I feel for you with that :( Feb 17 17:17:55 RP: is there a similar story to pigz too? Or isn't that tool equal to gz as pixz is to xz? Feb 17 17:20:16 Grepping the layers and bitbake, it seems pigz is still a relevant tool Feb 17 17:27:22 sveinse: gzip doesn't have inbuilt threading? Feb 17 17:29:48 RP: all i know is that we migrated to pigz recently because it was way faster Feb 17 17:31:40 pigz is fine, its just pixz which was obsoleted Feb 17 17:32:13 These two are perhaps completely unrelated tools? Just sharing same naming scheme? Feb 17 17:34:05 correct Feb 17 19:31:52 hi. is anyone using devicemapper under systemd-udevd? i find that if i don't install lvm2-udevrules, devicemapper stuff hangs waiting for notifcations. this seems like a bug.. Feb 17 19:37:50 hi, I have one issue with do_rootfs which took ~50 minutes. I enabled buildstat to find out this info. IS there some possbility to debug it what is causing such slowdown? Feb 17 19:47:54 hello all. i need some advice. i am cross compiling and running a deep neural network on a target (qemux86-64). it is taking 3 minutes for a very small network. at the moment i am not using any framework(opencl, darknet) just opencv::dnn module(high level API to implement DNN). what can i do to increase processing speed of this? Feb 17 20:01:05 sorry i was logged out. if someone answered could someone some copy paste again:] Feb 17 20:53:46 rizi: You're better off asking in a forum related to opencv Feb 17 20:54:23 yeah okay thankyou Feb 17 21:06:36 halstead: could you give a nudge to https://git.yoctoproject.org/git/meta-ti Feb 17 21:06:49 Yep Feb 17 21:07:05 dl9pf: what do you mean? Feb 17 21:07:14 denix: error: Cannot fetch meta-ti from https://git.yoctoproject.org/git/meta-ti Feb 17 21:07:29 dl9pf: ah, repos are missing on git.yp.org, sure Feb 17 21:08:21 dl9pf, Should be good until the next push at least. Feb 17 21:08:42 halstead: tnx ! Feb 17 21:10:23 halstead: what's wrong with pushes? I have another one pending in few minutes... would I lose repo again? Feb 17 21:11:25 halstead: btw, that's not the latest... missing at least one push Feb 17 21:12:57 denix, Not totally sure yet. When new entries are added to refs/heads the cgit and the http backend have errors. git gc, packs everything and it works again until the next push. Feb 17 21:14:06 denix, I'm building out a new server and testing at each step to try to find the issue. Feb 17 21:14:38 halstead: ok, thanks, keep us posted Feb 17 21:30:16 halstead: I pushed one more change and it lost zeus branch and master is from daisy period... Feb 17 21:31:37 denix, Repaired, http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/ Feb 17 21:32:39 halstead: thanks! Feb 17 22:24:51 JPEW: hmm, new perl repro build failure :( Feb 17 22:29:35 RP: link? Feb 17 22:30:20 JPEW: https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200217-ctk683y7/packages/ Feb 17 22:30:40 JPEW: question is whether its from -next or an underlying bug Feb 17 22:32:39 RP: Maybe you would know - is there a more easy way to setup common timestamp for Yocto/OE builds for several machines? Feb 17 22:32:39 Now I do use Feb 17 22:32:39 export BB_ENV_EXTRAWHITE="${BB_ENV_EXTRAWHITE} FOO_TIMESTAMP" \ Feb 17 22:32:39 FOO_TIMESTAMP_VAL=$(date +"%Y%m%d%H%M%S"); \ Feb 17 22:32:39 FOO_TIMESTAMP=${FOO_TIMESTAMP_VAL} MACHINE=imx6 bitbake image-full Feb 17 22:33:16 denix, dl9pf I think http clones are good to go now. Thank you RP for pointing me in the right direction. Feb 17 22:33:23 RP: That one looks like one where the encode module is trying to use the host compiler to figure out if it should do `int foo[16] = { ... }` or `int foo[] = { ... }` Feb 17 22:33:28 And in that way I do have the same timestamp for several builds (and yes, I've tried ${DATETIME} but it changes as each bitbake invocation) Feb 17 22:33:29 I thought that was fixed Feb 17 22:34:30 RP: Hmm, thats a big diffoscope diff.... I thought it would break it up into multiple files Feb 17 22:38:29 JPEW: it is a huge diff, yes :/ Feb 17 22:38:55 lukma: other option would be to read the timestamp from some metadata file I guess Feb 17 22:39:07 halstead: glad we may have it fixed! :) Feb 17 22:39:59 RP: The problem is that after updating from rocko to zeus - I do see some errors regarding hash mismatches Feb 17 22:40:14 RP: For images which were build correctly Feb 17 22:40:44 lukma: it did get become a lot more careful about a few things iirc Feb 17 22:40:45 RP: I do guess that zeus added some extra checks support for caching the sstate/ Feb 17 22:41:04 lukma: we've found and fixed a few correctness bugs, yes Feb 17 22:41:50 RP: Ok, I will poke around Feb 17 23:14:10 JPEW: I wonder if we have some kind of data leakage from old builds or it really was fixed :/ Feb 17 23:14:24 JPEW: half tempted to wipe the hashequiv data Feb 17 23:14:31 * RP sleeps on it Feb 17 23:14:37 just do it Feb 17 23:14:57 armpit: what, sleep or wipe the data? Feb 17 23:15:39 both Feb 17 23:17:19 also I'd love it if someone wants to fix the webkitgtk float128 issue that seems to have appeared by enabling api-docs in qemux86-world-alt... Feb 17 23:18:05 * RP changes qemux86 world to 64 bit, that may even fix it Feb 18 01:07:26 New news from stackoverflow: Yocto Warrior Bitbake Recipe for PyTorch for NVIDIA Jetson Nano **** ENDING LOGGING AT Tue Feb 18 02:59:57 2020