**** BEGIN LOGGING AT Wed Aug 05 02:59:57 2020 **** BEGIN LOGGING AT Wed Aug 05 04:39:53 2020 Aug 05 08:24:28 halstead: in non-sysadmin terms, what happened to the servers if you don't mind? I'm always curious about what could (and did) go wrong :) Aug 05 08:45:34 qschulz: One of the two OS flash drives in the NAS went bad and caused booting/running issues (it had a redundant partner backup which should have let things work but didn't) Aug 05 08:46:07 qschulz: At least that is my understanding, I've not really talked to michael, he had enough to do without me asking questions! Aug 05 08:46:25 qschulz: systems are degraded but recovering Aug 05 08:51:23 RP: thx! Aug 05 08:56:42 RP: i couldn't resist putting that one out: https://twitter.com/TheYoctoJester/status/1290891843249504256 Aug 05 08:57:14 :) Aug 05 09:24:32 LetoThe2nd: we'd all love hardware redundancy Aug 05 09:28:06 qschulz, I don't fully understand why the system went down. On top of the 2 OS drives there was a third flash drive plugged in inside the chassis that was throwing nothing but errors. Once I found and removed it I was able to perform a standard recovery. Aug 05 10:03:29 halstead: You need http://pages.cs.wisc.edu/~ballard/bofh/bofhserver.pl Aug 05 10:14:20 paulbarker: "someone was calculating pi on the server" :'D **** BEGIN LOGGING AT Wed Aug 05 10:45:11 2020 Aug 05 15:26:36 anyone else getting a BrokenPipeErrror in the runqueue now? uncaught exception? i'm not doing anything special.. hmm Aug 05 15:27:08 errors trying to write to the worker pipe Aug 05 15:27:20 hmm, odd Aug 05 15:45:06 oh, nevermind, something was up with pseudo causing all my workers to fail, but it gave zero messages to that effect. had to wipe tmpdir **** BEGIN LOGGING AT Wed Aug 05 15:50:41 2020 Aug 05 17:15:04 ok complete brainfart, where is the code that checks that the SRCREV is in the branch specified Aug 05 17:15:19 I've read git.py twice now and can't see it Aug 05 17:15:23 *obviously* time to stop Aug 05 17:32:07 I have seen a few older posts asking about a do_package error in glibc-locale-2.31. I'm having the same error, with the error log here: Aug 05 17:32:28 https://textsaver.flap.tv/lists/3iwm Aug 05 17:33:12 I tried cleaning and running bitbake -c clean glibc-locale and then bitbake glibc-locale, but still getting the same error. I'm running the build in Jenkins with a docker ubuntu 18.04 agent. Aug 05 17:35:23 Better log format: https://pastebin.com/Ub723AfM Aug 05 17:41:39 rburton: line 374, raise bb.fetch2.FetchError("Unable to find revision %s in branch %s even from upstream" % (ud.revisions[name], ud.branches[name])) Aug 05 17:43:35 hale2bopp: it obviously doesn't like that docker filesystem Aug 05 18:05:22 The strange thing is, I can manually run a docker container based on the same image, and it runs successfully in there. Only when I run it via Jenkins do i get this error Aug 05 18:12:17 hale2bopp: If you're actually writing to the filesystem in the container, then it could be jenkins is using different filesystem for overlay. If you are bind mounting a filesystem for the output, then you'd need to make sure whatever is being bind mounted makes sense. Aug 05 18:28:06 hi, what is the best way to override the libusb version to build in my layer? Aug 05 18:28:17 the recipe can remain as is from meta, I just need to upgrade the version Aug 05 18:29:53 lpapp: reset its PV and srcuri checksums? Is that enough to make it build/work? Aug 05 18:30:23 yeah, it built when I changed that from meta, but I guess it would be nicer to have some sort .bbappend? Aug 05 18:32:21 Sometimes I think it would be nice if every bb file that includes a version had a .inc file with all the guts that don't change Aug 05 18:32:58 It makes it way easier to just create a new recipe in your layer with the proper version Aug 05 18:33:09 rewitt: don't let rburton see that :) Aug 05 18:33:20 oh, okay, copy/pasta ? Aug 05 18:33:47 rewitt: there are pros and cons, we try not to encourage multiple versions I guess Aug 05 18:34:09 rewitt: you can just include the original .bb btw Aug 05 18:34:27 if I copy the recipe into my layer with a new version in the file name, I guess the build system will pick up the recipe from my layer as opposed to that of meta's? Aug 05 18:34:42 RP: Yeah I'm not claiming that it's the best thing, just that it makes it easier sometimes :) Aug 05 18:34:51 lpapp: depends on your layer priorities but yes, most likely Aug 05 18:36:40 lpapp: You could make a libusb_newversion.bb(whatever newversion is), do what RP metioned which is include the libusb_oldversion.bb, and then change the SRC_URI etc. That's if you want the package version etc, to make sense. Aug 05 18:37:08 lpapp: You could also do a bbappend as you mentioned, but then you're going to have a package version that doesn't match the code that you built Aug 05 18:37:27 lpapp: Unless in your bbappend you change those things as well Aug 05 18:39:08 lpapp: If other people may look at the layer, I personally would lean toward the new bb file because it is obvious what it is without having to inspect the bbappend. But I could be wrong as to what the "best practice" would be Aug 05 18:50:06 thanks Aug 05 19:09:01 @rewitt: "If you're actually writing to the filesystem in the container, then it could be jenkins is using different filesystem for overlay. If you are bind mounting a filesystem for the output, then you'd need to make sure whatever is being bind mounted makes sense." Aug 05 19:09:41 Could you clarify a bit on how I would know whether I am writing to the filesystem in the container versus bind mounting a filesystem? Aug 05 19:25:02 is the latest commit on poky master 5e1bc3ef5a net-tools: fix upstream version check? Aug 05 19:25:33 somehow patchwork is complaining to my ltp patch, it applies fine on my local environment. **** BEGIN LOGGING AT Wed Aug 05 20:00:49 2020 Aug 05 20:58:12 There was a slight difference in the output of df -hT when I ran it in Jenkins and when I ran it directly in my docker container - does that suggest that Jenkins is using a different filesystem? **** BEGIN LOGGING AT Wed Aug 05 21:20:16 2020 Aug 05 21:56:10 khem: https://github.com/openembedded/openembedded-core/compare/master...kergoth:nativesdk-musl allows musl for nativesdk, https://github.com/kergoth/openembedded-core/compare/nativesdk-musl...kergoth:sdklibc makes it easier to enable/control. thoughts? Aug 05 21:57:00 hale2bopp: If you don't pass any arguments to docker to bind mount, then you are using the root filesystem inside of the container. If you need help beyond that, I recommend that you ask in the appropriate docker channels. And if you don't maintain the Jenkins server yourself, you'll need to talk to whoever has set up the configuration. There may be a more obvious answer, but I don't know it. Aug 05 22:06:24 rewitt Thanks! **** BEGIN LOGGING AT Thu Aug 06 00:07:44 2020 **** ENDING LOGGING AT Thu Aug 06 02:59:57 2020