**** BEGIN LOGGING AT Fri Apr 12 02:59:57 2019 Apr 12 04:55:41 New news from stackoverflow: Yocto: Remove Packages From core-image-base Apr 12 07:00:10 keith: that error isn't very helpful is it :/. Is the layer matching the branch you're using for everything else? Apr 12 08:16:34 keith: windows line endings or something... ? Apr 12 08:23:55 i tried adding a new splash into yocto. at first the compiler was complaning but after fixing it it compiled. now i cannot find the compiled binary on my sd card. do i have to specify that this file is included in rootfs somewhere Apr 12 08:26:21 New news from stackoverflow: Yocto Hello World C++ CMake Project is not able to compile a simple test program Apr 12 08:42:39 ok, i found the ipk file in my deploy folder. but the file is obviously not deployed. where do i specify what is installed? Apr 12 08:46:15 lastaid: add the package name to IMAGE_INSTALL of your image Apr 12 08:46:35 the entire one? Apr 12 08:46:44 psplash-pdix_0.1+git0+2015f7073e-r15_cortexa7t2hf-neon-vfpv4.ipk Apr 12 08:46:44 ? Apr 12 08:46:45 what "entier one" Apr 12 08:46:47 no. Apr 12 08:46:55 psplash-pdix Apr 12 08:46:59 probably, yes. Apr 12 08:47:25 and IMAGE_INSTALL is my layer.conf in this case? Apr 12 08:47:48 you can technically do it in local.conf for testing purposes. Apr 12 08:48:09 but the way better alternative is to create a specific image recipe that suits your needs. Apr 12 08:49:04 for a quick check, you can add CORE_IMAGE_EXTRA_INSTALL = "psplash-pdix" to your local.conf Apr 12 08:49:19 and the really next thing you should take care of is a custom image. Apr 12 08:50:59 thanks! Apr 12 08:51:36 but wait, i already have a layer Apr 12 08:51:57 will putting it in the layer.conf also work? Apr 12 08:52:24 it would work, but its an absolutely stupid way Apr 12 08:52:30 ok Apr 12 08:52:53 i still only have a very rudimentary understanding of yocto Apr 12 08:53:09 thats why i said, the next thing you shall do is a custom image. Apr 12 08:53:13 where would i put it properly? Apr 12 08:53:21 into a custom image. Apr 12 08:54:04 have a look at core-image-minimal-dev, for example. copy that over into your layer, name it whatever you want. Apr 12 08:54:11 ok Apr 12 08:54:25 then in there, do IMAGE_INSTALL_append = " psplash-pdix" Apr 12 08:54:47 then it is automagically built and pulled in when you build your image. Apr 12 08:54:49 thanks! Apr 12 09:01:47 i am not going to lie. i am building an embedded system with a raspberrypi. i moved to yocto because i had issues with the bootscreen and screen blank and because its the right direction in general. but this is a lot of effort for a boot screen Apr 12 09:01:55 yocto is really nice though Apr 12 09:02:17 its not the bootscreen that is causing your effort, its the learning curve. Apr 12 09:03:45 we know that yocto/Oe have a really steep learning curve, but its hard to avoid that for complex and extremely powerful tools Apr 12 09:15:01 RP: asked about some mirror/fetch/unpack problems yesterday, I guess I have exactly this problem: http://lists.openembedded.org/pipermail/bitbake-devel/2018-March/019029.html Apr 12 09:26:23 ernstp: you're using shallow tarballs? Apr 12 09:27:53 [log_check] Warn: update-alternatives: psplash has multiple providers with the same priority, i am getting this warning. i already increased the priority of the bbappend i added, without results Apr 12 09:27:58 any ideas? Apr 12 09:30:26 lastaid: its referring to the update-alternatives priority, no recipe priority Apr 12 09:30:47 lastaid: are you *appending* or have you actually *copied* the recipe? i mean, the package name psplash-pdix actually suggests that you added a second provider. Apr 12 09:36:47 i use bbappend ... Apr 12 09:37:02 and it creates psplash and psplash-pdix Apr 12 09:37:39 why does it create two things? Apr 12 09:37:40 scratch that .. it creates psplash-default and psplash-pdix Apr 12 09:38:00 then it creates a symlink to psplash Apr 12 09:38:21 because the meta-raspberry or oe package contains a default splash? Apr 12 09:38:35 i could probably just replace -pdix with -default in my bbappend? Apr 12 09:39:28 appends are meant to *modify* things, changing them to whatever you need. not exactly to *add* other conflicting versions Apr 12 09:58:29 RP: that's something you have to enable explicitly right? nope Apr 12 09:59:51 RP: I can see that I have both the git://git.yoctoproject.org/foo and https://git.yoctoproject.org/git/foo clones in downloads Apr 12 10:00:16 RP: but unpack then selects the wrong one and not the one from the MIRROR Apr 12 10:04:36 because of the extra .git. in the name Apr 12 10:12:06 ernstp: it does sound like a bug Apr 12 10:12:40 ernstp: there are supposed to be links created for mirrors but I suspect git has magic handling of ".git" in come cases :( Apr 12 10:13:11 RP: links in $DL_DIR/git2 ? Apr 12 10:14:14 ernstp: well, I'm thinking of the mirror tarballs in DL_DIR. not sure the other would create them :/ Apr 12 10:14:41 * RP suspects some weird git quirk with the .git suffix Apr 12 10:14:44 RP: I ran test_asyncio on 4.19 kernel, it passed. I ran it on 5.0 it failed. So it's almost certainly the same socket regression. Apr 12 10:15:08 kanavin: we should mention that upstream then Apr 12 10:15:28 RP: worse yet, I tried these tests on a host that has a 5.0.3 kernel, they seem to work okay :-( Apr 12 10:15:50 RP: it might be happeing only under qemu Apr 12 10:15:54 kanavin: good news is with our various fixes ptests look stable enough for release. That locale thing didn't seem to fix the failure though. I think ross said it was due to our "broken locale renaming" Apr 12 10:16:14 kanavin: ouch. That sounds nasty :( Apr 12 10:16:44 RP: that is odd, the locale fix did work for me Apr 12 10:17:02 kanavin: any special locale settings like changing the renaming? Apr 12 10:18:00 RP: I dont have any special settings, the test needs tr_TR.ISO8859 locale to be available, adding it to the dependencies satisfied that. Apr 12 10:19:01 kanavin: it is great to see the test passes going up and the failures being low :) Apr 12 10:19:25 and things giving consistent results Apr 12 10:19:55 RP: any plans to switch the defaults to have protocol=https ? would help us corporate drones :-) Apr 12 10:20:01 RP: yep Apr 12 10:20:39 ernstp: I want to make the mirrors work. Mandating https everywhere isn't going to work for all repos Apr 12 10:21:14 ernstp: all that would do is make more work, not all Apr 12 10:21:38 RP: sure, it just happens to be the most common problem I guess Apr 12 10:22:22 RP: so I think the summary of my problem is that the fetcher does stuff with mirrors, but the unpack step is not aware of that Apr 12 10:22:42 RP: and there are no links Apr 12 10:22:49 ernstp: that is how it looks. The reality is its calling the same code Apr 12 10:23:56 ernstp: there is no state shared between them do unpack isn't picking up the same thing fetch did though :/ Apr 12 10:25:28 RP: I'm also trying to come up with a (good?) short term workaround of course... Apr 12 10:26:43 New news from stackoverflow: bitbake failed with ExpansionError Apr 12 10:26:47 ernstp: I appreciate that. I have a lot of people wanting me to try and fix a lot of things and we have a release to get out :( Apr 12 10:29:43 i am inserting a usb stick but cannot find the device in /dev. is there anything i should be aware of? Apr 12 10:30:29 lastaid: behaviour depends on systemd or sysvinit and whether you have automounter installed as well as whether you have the right kernel usb drivers Apr 12 10:30:46 lastaid: are the kernel modules in your image? Apr 12 10:31:01 did dmesg show the device? Apr 12 10:31:16 dmesg really does not show anything after 12 seconds Apr 12 10:31:17 handon Apr 12 10:31:19 hangon Apr 12 10:32:02 i was being special, sda shows up Apr 12 10:32:19 but yeah, now i'll try to get it to automount Apr 12 10:32:57 RP: Ill check the latest master, maybe the fixup to the locale fix isnt somehow working Apr 12 10:33:46 kanavin: thanks Apr 12 10:34:04 * RP thinks we might be ready to build 2.7 Apr 12 10:34:13 assuming these autobuilder changes work out Apr 12 10:40:05 oh cool, 2.7 is that close, didn't realise Apr 12 10:40:32 moving from 2.4 to 2.5 now, that's why I'm running into problems :-) Apr 12 10:56:51 New news from stackoverflow: Able to publish data to IBM watson cloud through PC but unable to connect to cloud thorugh device (sierra wireless wp85 module - ARM arch) || Yocto: meta-debian errors for cl-som-imx7 Apr 12 11:14:42 RP: more details... git:// fails, then it tries the premirror from downloads.yoctoproject.org and downloads a git2_..tar.gz Apr 12 11:15:31 inside that git archive it says origin git://, so if it needs to update that archive in the future it will fail Apr 12 11:16:15 ernstp: that helps a lot! Apr 12 11:16:16 however if I clean my downloads, set PREMIRRORS="" and tries again, the MIRRORS system will work correctly, and setup a link in git2 Apr 12 11:16:44 ernstp: so we need to reset the origin Apr 12 11:16:56 RP: for example Apr 12 11:17:48 RP: should we write this down before you forget it? :-) since you're busy with 2.7 right now I mean... Apr 12 11:18:36 RP: https://bugzilla.yoctoproject.org/show_bug.cgi?id=9738 that you mentioned yesterday is not the right place... Apr 12 11:18:37 Bug 9738: enhancement, Medium, 2.99, richard.purdie, NEW , [PATCH] fetcher: allow git+: syntax Apr 12 11:19:43 ernstp: filing a specific bug for it would be great Apr 12 11:20:13 ernstp: creating a failing test case for bitbake-selftest would be even better! Apr 12 11:20:23 (then we have something to fix) Apr 12 11:22:51 RP: this thing? https://wiki.yoctoproject.org/wiki/Oe-selftest Apr 12 11:23:11 ernstp: no, the command "bitbake-selftest" Apr 12 11:23:21 ernstp: see bitbake/lib/bb/tests/fectch.py Apr 12 11:23:31 without the typos Apr 12 11:24:17 RP: no strong opinion either way, but if you need to rebuild 2.6 release, would it make sense to include the glibc fix (removal of those 2 rejected patches)? Apr 12 11:25:01 JaMa: if we start adding tons of changes we'll have to do another full QA round and a weeks wait Apr 12 11:25:20 JaMa: we could fix the systemtap issue, fix the ptest issue, add the glibc changes and so on Apr 12 11:25:29 JaMa: feel free to propose it Apr 12 11:25:32 ok, fair enough Apr 12 11:25:49 JaMa: I really don't want that boost upgrade in there Apr 12 11:26:08 the rest I can live with until 2.6.3 Apr 12 11:26:17 we've already removed them from SRC_URI in our layer (and we don't use exact point releases), so it's not an issue for us Apr 12 11:26:37 but when it was removed from master was consider serious issue I believe Apr 12 11:26:51 that's the only reason why I've mentioned it here Apr 12 11:27:03 JaMa: its serious but its also not hurting anything badly afaik apart from tracing Apr 12 11:27:32 true Apr 12 11:28:01 JaMa: QA is jammed up with 2.7 coming and 2.5 in there so I'm just trying to avoid a respin but sort boost :/ Apr 12 11:28:09 if the right answer is full respin, we will Apr 12 11:28:26 someone in LGE figured it out (maybe independently) about the same time as the report arrived on oe-core ML Apr 12 11:28:47 understood and thanks for boost Apr 12 11:31:08 Sadly Stephen isn't going to be around for a few weeks so it looks like I get to do the things he does too :( Apr 12 11:38:19 RP: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13278 Apr 12 11:38:20 Bug 13278: major, Undecided, ---, richard.purdie, NEW , If git protocol doesn't work, you get a tar.gz clone from PREMIRROR which has git protocol origin Apr 12 11:40:21 RP: I'm thinking that it's this check that causes my issue in a way... http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/__init__.py#n1011 Apr 12 11:41:32 ernstp: hmm, not sure I'd agree just at a glance Apr 12 11:43:07 RP: I have a git.yp.org.prelink-cross that doesn't work and a newly cloned git.yp.org.git.prelink-cross. In a fresh setup without PREMIRRORS I get a symlink from the short name to the longer name Apr 12 11:44:09 but here it's not replacing the old clone with a symlink... Apr 12 11:44:45 if os.path.exists() && os.path.islink ? Apr 12 11:44:55 sorry, and :-) Apr 12 11:45:18 ernstp: yes, that could explain it Apr 12 11:54:57 RP: rebuilt core-image-sato-sdk-ptest with master, the python locale test still passes Apr 12 12:12:53 RP: ok it wasn't exactly that perhaps, but similar things a few lines below... Apr 12 12:17:09 kanavin: ok,I guess we'll see what the next autobuilder run does :/ Apr 12 13:05:18 if i directly start into a qt application, how can i prevent the login to show up on terminal? Apr 12 13:05:47 i got the splash, then 2 seconds of login screen, then application. i want those two seconds of login screen gone Apr 12 13:05:57 2.7 rc1 is building Apr 12 13:06:17 halstead: sorry this will run into the maint window but I'd really prefer to have this done! Apr 12 13:13:52 lastaid: you could try disabling getty on tty1. If you're using systemd that would be something like "systemctl disable getty@tty1.service". Apr 12 13:20:30 i am using sysvinit ... Apr 12 13:20:45 which i am not accustomed to Apr 12 13:21:42 RP: built a small patch for https://bugzilla.yoctoproject.org/show_bug.cgi?id=13278 .... Apr 12 13:21:43 Bug 13278: major, Undecided, ---, richard.purdie, NEW , If git protocol doesn't work, you get a tar.gz clone from PREMIRROR which has git protocol origin Apr 12 13:23:13 lastaid: maybe grep for tty1 in /etc to see if you can find where it's configured? Apr 12 13:23:50 i'll take a look Apr 12 14:24:14 does anyone remember why libtool-cross doesn't inherit cross? I'm looking into weird issue with libtool-cross from sstate installing utilities from db recipe as libtool scripts instead of actuall binaries and the root cause seems to be in sstate.bbclass http://git.openembedded.org/openembedded-core/tree/meta/classes/sstate.bbclass?h=morty#n506 where it checks for bb.data.inherits_class('cross', d) before Apr 12 14:24:20 replacing FIXMESTAGINGDIR, I can probably work around this with EXTRA_STAGING_FIXMES but it's surprising if I'm the only one seeing it Apr 12 14:29:45 luckyli we're not using db utilities at all, only reason why I've noticed this was that it triggers QA error about /bin/bash dependency from the libtool linker scripts Apr 12 14:33:37 JaMa: cross is very gcc/binutils specific. I looked at this once and it didn't make sense for libtool to do it Apr 12 14:34:23 JaMa: libtool-cross is basically a dummy recipe to generate a cross libtool and install it, that is about all its useful for Apr 12 14:34:51 I have a do_deploy() that uses files from SRC_URI. Those files seem to get wiped by rm_work inbetween rebuilds I think. Is there a way I should mark those files, so that they get re-populated by setscene tasks, or something like that ? Apr 12 14:38:21 RP: should I sent fix for morty with EXTRA_STAGING_FIXMES? I think it doesn't happen with pyro and newer since RSS Apr 12 14:40:23 JaMa: realistically we can't really merge morty changes any more :( Apr 12 14:40:53 ok, fair enough Apr 12 14:41:38 JaMa: there is no harm in sending it, just not much we could do other than perhaps a stable/XXX branch in poky-contrib Apr 12 14:42:43 RP: OK, I'll send it, might be useful for other people using morty and olders (at least it will be archived in the ML) Apr 12 14:42:57 JaMa: sounds good Apr 12 14:43:16 * RP has pondered an LTS autobuilder Apr 12 14:43:50 Given I just temporarily had to take on the project programme management I can't see that happening any time soon :/ Apr 12 15:20:22 so strange it goes to: Apr 12 15:20:22 0: linux-raspberrypi-1_4.19.32+gitAUTOINC+d65a0f76d3-r0 do_fetch (pid 8472) 100% |###########################################################| Apr 12 15:20:22 and then says: Apr 12 15:20:22 WARNING: linux-raspberrypi-1_4.19.32+gitAUTOINC+d65a0f76d3-r0 do_fetch: Failed to fetch URL git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.19.y, attempting MIRRORS if available Apr 12 15:25:55 kergoth: it probably fetches, can't find the revision in that branch and then fetches more from mirrors Apr 12 15:26:02 keith: ^^^ Apr 12 15:26:05 sorry kergoth :) Apr 12 15:26:30 yeah, so how do i force my local.conf to use kernel 4.14? folks are saying it shouldnt use 4.19 anyways Apr 12 15:29:02 keith: understanding why its using 4.19 would help answer that question... Apr 12 15:29:16 https://github.com/agherzan/meta-raspberrypi/issues/410 Apr 12 15:29:39 its default right now, but theres multiple issues posted that ask for the default to be switched back to 4.14 Apr 12 15:30:14 so would like to use: https://github.com/raspberrypi/linux/tree/rpi-4.14.y since thats the suggestion in the issue Apr 12 15:30:43 https://github.com/raspberrypi/linux/issues/2931 Apr 12 15:30:47 here's another issue related to this Apr 12 15:30:54 keith: is there a 4.14 recipe in the tree? If so PREFERRED_VERSION_linux-raspberrypi = "4.14%" might do it Apr 12 15:31:09 * RP is just guessing Apr 12 15:31:28 sorry, i'm a yocto/oe newb :) thanks i'll try that! Apr 12 15:33:12 RP: looks like that is working: 1: linux-raspberrypi-1_4.14.98+gitAUTOINC+5d63a4595d-r0 do_fetch (pid 32306) | <=> | thanks again! Apr 12 17:28:38 I have a sp-paths.bbclass file with lots of vars like SPDIR="/opt/sp", SPDIR_BIN="${SPDIR}/bin" and so on. I'm working on rather using the stardard linux paths, so I need to define these paths. Can I use overrides to select which of these two sets I use? If so, how? Apr 12 17:30:02 SPDIR_BIN_usesystem="/usr/bin" I suppose. But how do I activate this override? Apr 12 17:33:45 sveinse: OVERRIDES .= ":usessystem" (or =. I can never remember which way around) Apr 12 17:35:34 RP: thanks Apr 12 17:43:14 RP: I assume the append syntax .= is wanted since it was written ":usesystem" rather than "usesystem:" where you'd need prepend, afaics Apr 12 17:44:14 I did erase all my sstate Apr 12 17:44:23 and now Im getting strange errors Apr 12 17:44:26 ld: cannot find -lgcc Apr 12 17:44:27 | collect2: error: ld returned 1 exit status Apr 12 17:44:35 glibc_2.26.bb:do_compile) failed Apr 12 17:44:48 found nothing meaningful on the internets Apr 12 17:45:30 Has anybody on here setup and used a signed fitImage with uboot for a fully secure boot? Asking here because the Poky channel seems dead... Apr 12 17:46:06 on the other hand if i do bitbake -c cleanall gcc Apr 12 17:46:21 and then bitbake gcc Apr 12 17:46:39 it tries to build glibc-2.26 first Apr 12 18:04:49 cant recall the exact sequences here, but this sounds about right Apr 12 18:20:36 Hey all - I've sort of ghetto-rigged my local poky instance to download and report all upstream versions it can find for all recipes to a little web service I have Apr 12 18:21:01 Of course, for packages that time out (lots of those in meta-oe it seems), that thing can take a long time with a few thousand recipes Apr 12 18:21:55 So I'd like to split up my list of recipes and query them in parallel. The problem, of course, is that the moment I fire up a second instance of my entrypoint script it blocks waiting to talk to the bitbake service Apr 12 18:22:07 cenobyte_: You might want to try the mailing list. People have definitely done signed boot in various forms Apr 12 18:22:15 I'm doing read-only access to bitbake Apr 12 18:22:43 Is there a way to get things like devtool to fire up their own personal bitbake service when they run? Apr 12 18:23:06 I'd really rather not split this thing up onto multiple docker nodes or the like Apr 12 18:23:20 Seems like a hairy answer to the problem Apr 12 18:23:22 Striking7: if they all have separate build directories, sure. Only one bitbake server per build directory Apr 12 18:24:11 Striking7: or since bitbake is an execution engine, have it run the queries in parallel fr you Apr 12 18:25:17 Striking7: our own upstream version checking code does also have other ways of doing parallelism if I remember rightly Apr 12 18:25:57 Striking7: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=411e2b7047b04edb9065f84d96cc7d14224c5032 Apr 12 18:26:17 Thanks RP - you always save my bacon: reading Apr 12 18:38:16 RP: have you looked into wic race issue with EXTRA_IMAGEDEPENDS, by any chance? Apr 12 19:28:28 New news from stackoverflow: Updating to the latest Yocto version sanity.bbclass issues Apr 12 19:29:28 denix, is that an open bug Apr 12 19:31:07 halstead: I am seeing that my builders are not able to connect to errors yp org Apr 12 19:31:30 halstead: ERROR: Could not contact server: https://errors.yoctoproject.org/ClientPost/JSON Apr 12 19:31:39 ERROR: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:847) Apr 12 19:31:58 khem, there was an issue eariler where the ssl cert renewed but the webserver was still serving the expired one. Apr 12 19:32:14 seems it has not gone well Apr 12 19:32:17 khem, It's been resolved for awhile now. Apr 12 19:32:36 this started to happen couple of weeks ago IIRC Apr 12 19:32:39 and is still happening Apr 12 19:32:44 on all my builders Apr 12 19:33:07 9am build today reported same Apr 12 19:33:30 khem, What distro is running on your builders? Apr 12 19:34:24 see http://jenkins.nas-admin.org/view/OE/job/oe_world_qemuarm/1069/console Apr 12 19:34:45 halstead: I have arch/ubuntu 14.04/ubuntu 18.04 Apr 12 19:34:50 in different locations Apr 12 19:34:56 all fail in same way Apr 12 19:37:42 khem, It's been fixed since just before 9am PDT. I'm looking for failures since. Apr 12 19:38:01 khem, But since it's been weeks it must be something else. Apr 12 19:43:41 khem, curl and wget from milla succeed without warning now. Could the webserver reload have resolved it? Apr 12 19:58:34 New news from stackoverflow: Yocto: Remove Packages From core-image-base [on hold] Apr 12 20:16:54 halstead: its failing on my desktop too which has been rebooted this morning Apr 12 20:17:45 khem, Can you point out where the code is that's failing? Point me at a good starting point? Apr 12 20:27:11 denix: not looked into it, no, sorry Apr 12 20:28:06 RP: do you want me to open a bugzilla defect to track it? Apr 12 20:28:23 halstead: probably report-error.bbclass Apr 12 20:32:04 denix: please Apr 12 20:48:27 halstead: OE builders are fixed Apr 12 20:48:37 lets me rebuild on others and see if they are fixed too Apr 12 20:49:17 khem, Excellent. Please let me know. Apr 12 21:27:15 denix: bug is good thanks. I added a quick note about a suspicion I had Apr 12 21:28:54 halstead: just realised we didn't get a release email generated :( Apr 12 21:29:01 at least not that I've found Apr 12 21:33:02 halstead: we're also missing build tarballs from the release directory. Perhaps we need to redo this... Apr 12 21:42:22 * RP notes a ton of nettle problems. Why is a sato image running nettle ptest anyway? :/ Apr 12 21:42:33 * RP thinks rc1 may be a no go Apr 12 21:48:41 https://autobuilder.yocto.io/pub/releases/yocto-2.7.rc1/testresults/testresult-report.txt for anyone interested Apr 12 21:54:46 http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/tree/images/qemux86/glibc/core-image-sato/installed-package-names.txt?h=poky/warrior/qemux86#n604 - shouldn't be there Apr 12 21:54:53 will revert that nettle change Apr 12 23:54:17 RP, I have the hashes for the missing tarballs and I can make them now. Should I go ahead? Apr 13 00:00:42 RP, Looks like the email didn't go out because of https://bugzilla.yoctoproject.org/show_bug.cgi?id=13281. Yeah? Apr 13 00:00:43 Bug 13281: minor, Undecided, ---, richard.purdie, NEW , build-perf-test cannot generate reports on new branches due to lack of comparison data Apr 13 00:18:17 * armpit thinks the nettle ptest has an rdepend on nettle-dev Apr 13 00:18:31 * armpit to get the missing lib Apr 13 00:40:45 RP, I've generated the missing tarballs and put them in place just in case. **** ENDING LOGGING AT Sat Apr 13 02:59:57 2019