**** BEGIN LOGGING AT Wed Jul 23 03:00:01 2014 Jul 23 07:50:00 JaMa: Martin, around? Jul 23 07:57:54 y Jul 23 07:58:52 gm Jul 23 08:00:29 regarding test-dependencies and klibc-utils, the story is that back then I have lazily split the recipes to have distinct packages Jul 23 08:00:47 gm Jul 23 08:00:49 BUT only klcc_cross has a distinct do_compile Jul 23 08:00:59 and so it has a dependency on klibc Jul 23 08:01:13 for the utils, klibc is built as well but not packaged Jul 23 08:01:19 so it is implicit Jul 23 08:01:41 gm woglinde Jul 23 08:03:12 JaMa: in practice klibc-utils does not depend on klibc at buildtime Jul 23 08:03:32 because it is self-providing it Jul 23 08:03:43 JaMa: how bad is that ;) ? Jul 23 08:05:37 reading before coffee? _terrible_ :) Jul 23 08:11:27 got a moka for 4 earlier ;) Jul 23 08:14:24 now 2 solutions, add the DEPENDS = "klibc" at the end of the klibc-utils and silence the warning Jul 23 08:14:39 or as second option Jul 23 08:14:55 +DEPENDS_pn-klibc = "linux-libc-headers perl-native" Jul 23 08:15:04 +DEPENDS = "klibc" Jul 23 08:15:09 in the klibc.inc Jul 23 08:15:24 which is inherited by all Jul 23 08:15:36 *included even Jul 23 08:16:26 seems a bit a big gun... Jul 23 08:20:41 ant_work: the first looks reasonable Jul 23 08:21:30 yea Jul 23 08:22:01 ant_work: I'm more worried about possible difference between klibc built by klibc-utils and klibc installed on target from separate klibc recipe Jul 23 08:22:56 It would be nice to add patch in klibc-utils to use staged klibc from sysroot instead of building own copy and then forgetting about it Jul 23 08:24:44 the version remains hardcoded iirc Jul 23 08:25:20 the binaries need that specific libklibc Jul 23 08:25:57 so no risk until there is a single recipe Jul 23 08:26:05 but yes, it is suboptimal Jul 23 08:26:19 I'll see if I come to something better Jul 23 08:29:46 hello all, is it possible to have a more complete busybox solution (I mean not the tiny one) ? Jul 23 08:32:28 kbouhara, you can provide your own busybox-defconfig via a .bbappend Jul 23 08:43:46 morning all Jul 23 08:45:32 kroon: ah ok missed that Jul 23 08:45:39 kroon: thanks Jul 23 08:46:24 ant_work: wrt ERROR: Recipe linux-yocto-tiny-kexecboot is trying to change PV from '3.10.43+gitAUTOINC+199943142f_aa677a2d02' to '3.14.5+gitAUTOINC+602be954ac_96930820e0'. This will cause do_package_write_* failures since the incorrect data will be used and they will be unable to find the right workdir. Jul 23 08:46:45 ant_work: I think that linux-yocto-tiny-kexecboot is creating some package which happens to be created also by normal linux-yocto Jul 23 08:47:10 IIRC we should get different error message saying that this package is already provided by something else Jul 23 08:52:25 bluelightning, morning Jul 23 08:52:36 hi JaMa, kroon Jul 23 08:53:07 hi all Jul 23 09:26:42 JaMa: that recipe does PACKAGE = "" Jul 23 09:26:53 and most tasks are noexec Jul 23 09:27:05 I guess we need to set noexec for package_qa Jul 23 09:27:17 (wich is a new task) Jul 23 09:56:55 JaMa: what seems utterly bad is that it mixes 3.10 and 3.14 Jul 23 10:07:09 hi. what's the git branch for bitbake used for daisy, 1.22? Jul 23 10:11:41 ndec: yes Jul 23 10:11:51 ok. thx Jul 23 10:11:53 ndec: FYI, this is the canonical reference for such things: https://wiki.yoctoproject.org/wiki/Releases Jul 23 10:12:16 (I've made sure the OE wiki also has links in the appropriate places to this as well) Jul 23 10:13:27 oh. nice page... i knew it didn't exist before... so i didn't search for it today ;_) Jul 23 10:13:48 or maybe it was there before... and i didn't know about it.. Jul 23 10:16:49 it's been around for a while, although only for just over a year Jul 23 10:17:01 it's grown a bit hairy for my liking, but it is kept up-to-date Jul 23 11:43:30 https://bugzilla.yoctoproject.org/show_bug.cgi?id=5423 Jul 23 11:43:39 Looks like that one can be put to "RESOLVED" ? Jul 23 12:10:15 the change i sent in was rejected Jul 23 12:10:45 Hello all, Im still working with dora and I wonder if I want to test a build with daisy, if it's best to get new build directory ? does it make sense to change the build directory if want to save my old dora build ? Jul 23 12:10:49 (i think) Jul 23 12:11:23 kroon: you're right! closed. Jul 23 12:11:29 yay another bug off my list. Jul 23 12:46:04 nobody is aware of any opkg chages or breakages lately? Jul 23 12:46:21 I cant seem to do basic things anymore Jul 23 12:46:26 opkg update Jul 23 12:46:31 opkg upgrade foo Jul 23 12:46:46 then it complains the package is not found... Jul 23 12:46:52 but I checked it is there Jul 23 12:46:57 and I did run bitbake package-index Jul 23 12:47:09 I've done this a million times Jul 23 12:47:32 manually accessing it with a browser shows no premission issues Jul 23 12:48:17 it should work Jul 23 12:50:15 running opkg with -V4 yields funny version numbers that look like-> pkg_hash_fetch_best_installation_candidate: storer 1.0+ac12+22471 impedo_duo Jul 23 12:50:29 the +ac12+ Jul 23 12:50:31 what is that? Jul 23 12:52:49 actually its not +ac12+, it's just the 12+ part that comes from strange places Jul 23 12:53:36 that 12+ is somehow inside the SRCPV Jul 23 12:54:25 pompomjuice: what is SRCPV set to in the recipe? Jul 23 12:55:40 checking... Jul 23 12:56:21 it is not set Jul 23 12:56:23 but Jul 23 12:58:07 the SRCPV originates from a custom VC accurev.py that was added to __init__.py by the guys who came before me Jul 23 12:58:22 oh, well in that case... Jul 23 12:58:25 meaning if SRCPV changed recently then I will have to redo that patch Jul 23 12:58:45 has there been changes to the system? Jul 23 12:58:53 imn on 1.6 Jul 23 12:59:04 not that I know of, but I don't necessarily track every single change Jul 23 12:59:08 aah ok Jul 23 12:59:16 let me double check what is going on here Jul 23 12:59:22 but what I see is the following: Jul 23 12:59:50 storer-databases_1.0+ac12+22471-r20.0_impedo_duo.ipk Jul 23 13:00:04 sorry not that one Jul 23 13:00:21 storer_1.0+ac12+22471-r20.0_impedo_duo.ipk Jul 23 13:00:29 that file exists inside IPK folder Jul 23 13:01:06 packages contain -> Version: 1.0+ac12+22471-r20.0 Jul 23 13:01:14 but on the device I get this: Jul 23 13:01:30 Installing storer (1.0+ac30+22456-r19.0) to root... Jul 23 13:01:35 note the R19 Jul 23 13:01:54 opkg update somehow does not realize the recipy went from r19 to r20 Jul 23 13:02:03 it couldn't Jul 23 13:02:04 but it did pick up the SRCPV change Jul 23 13:02:15 the version number is considered by opkg as a whole Jul 23 13:02:41 1.0+ac12+22471-r20.0 sorts lower than 1.0+ac30+22456-r19.0 Jul 23 13:02:46 so opkg upgrade wont upgrade on PR changes? Jul 23 13:03:05 aah I see Jul 23 13:03:05 it will, but in this case PV also changed (massively) Jul 23 13:03:09 I see Jul 23 13:03:29 PV beats PR since it goes first in the package version string Jul 23 13:03:43 but 22471-r20 is bigger than 22456-r19 ? Jul 23 13:04:02 you missed the +ac30 / +ac12 bit Jul 23 13:04:09 where does that 12+ come from Jul 23 13:04:24 something puts a 12+ infront of my SRCPV Jul 23 13:04:33 there are 2 candidates Jul 23 13:04:49 kg_hash_fetch_best_installation_candidate: Candidate: storer 1.0+ac12+22471. Jul 23 13:04:50 pkg_hash_fetch_best_installation_candidate: Candidate: storer 1.0+ac30+22456. Jul 23 13:04:53 12 Jul 23 13:04:55 then 30 Jul 23 13:05:01 I have no idea where these numbers come from Jul 23 13:05:11 is it new? Jul 23 13:05:22 I dont see them on all packages either? Jul 23 13:05:25 depends on what your custom code does, but with the git fetcher we have an incrementing number based on whether it's the same as the last hash or not Jul 23 13:05:38 the mechanism is not new, no Jul 23 13:05:45 aah Jul 23 13:05:46 ok Jul 23 13:05:48 sounds a lot like this accrev fetcher tries to do the same, bug is broken Jul 23 13:05:49 I will investigate Jul 23 13:06:00 rburton: my thoughts exactly Jul 23 13:06:09 must be the accurev fetcher Jul 23 13:06:13 its been working Jul 23 13:06:20 only lately I see now its not working anymore Jul 23 13:06:35 lately meaning last 2 months Jul 23 13:07:02 let me investigate further.. Jul 23 13:07:30 I was hoping for a quick: "yes the SRCPV thing change recheck your patches" type answer Jul 23 13:09:04 aah I see now Jul 23 13:09:16 normally that 12+ contains the phrase AUTOINC Jul 23 13:10:53 ok just cleaning and rebuild it went back to AUTOINC Jul 23 13:10:57 bizarre Jul 23 13:15:21 opkg simply wont update now Jul 23 13:18:42 ok new developments Jul 23 13:19:15 ./var/lib/opkg/lists/ contain duplicate package index files Jul 23 13:19:27 one has a oe- prefix Jul 23 13:19:39 and that one contains the old package Jul 23 13:20:54 ok once I delete the file oe-impedo_duo it starts to work again Jul 23 13:21:06 and opkg update does not return the oe-impedo_duo file Jul 23 13:21:27 anyone have an idea where this oe- prefix package list files come from? Jul 23 13:22:06 opkg update only returns the file without the prefix, i.e impedo_duo Jul 23 13:29:46 pompomjuice maybee from do_rootfs? Jul 23 13:29:56 at image creationtime? Jul 23 13:31:06 must be Jul 23 13:31:13 I just have strange situiations now Jul 23 13:31:33 I deleted all package[.gz] files everywhere Jul 23 13:31:42 both the package repo Jul 23 13:31:46 and the device Jul 23 13:32:01 and it clings on to this old version of that package Jul 23 13:32:13 even though the package does not exist on disk with that version number anymore Jul 23 13:33:04 keeps on telling me I must do opkg update Jul 23 13:33:14 even though everything checks out Jul 23 13:34:38 wait a minute Jul 23 13:34:50 I think I know what is going on here Jul 23 13:35:21 that recipy does this ----> PACKAGES += "${PN}-databases" Jul 23 13:35:32 and that package is still stuck on the old version Jul 23 13:35:54 and no deps are set Jul 23 13:35:59 let me fix this Jul 23 13:36:58 I think it is a bug in the system Jul 23 13:37:40 you can trigger it by manually rebuilding the mother recipy/package when doing it manually via $bitbake foo; bitbake package-index Jul 23 13:39:34 then it jams somehow Jul 23 13:42:54 ok so I think I know how to tigger this bug Jul 23 13:43:41 1.) write recipy that produces two packages via the PACKAGES += "${PN}-databases" etc levers.... Jul 23 13:43:49 2.) Bake the image with both packages Jul 23 13:44:16 3.) manually do bitbake foo followed by bitbake package-index Jul 23 13:44:30 4.) on the device do a opkg update Jul 23 13:44:42 5.) then opkg upgrade foo Jul 23 13:44:46 watch how it fails Jul 23 13:51:27 make sure the bitbake foo stage is accompanied by a SRCPV bump or it wont fail Jul 23 14:04:45 also... after removing the package storer it still has an status entry with the old version in /var/lib/opkg/status Jul 23 14:04:47 opkg is broken Jul 23 14:05:16 yay Jul 23 14:05:25 after deleting the old status it works Jul 23 14:21:20 pompomjuice: the version somehow went backwards, that's not expected to work Jul 23 14:21:58 no Jul 23 14:22:00 Basically Jul 23 14:22:04 I have a recipy Jul 23 14:22:12 that produces two packages Jul 23 14:22:17 if you meddle with the one it fails Jul 23 14:22:23 you have to uninstall both Jul 23 14:22:30 and then install the new versions Jul 23 14:22:43 if you do just the one it jams because it's mate is still stuck Jul 23 14:23:16 opkg's dependency mechanism does not function when one recipy produces more than one package Jul 23 14:23:48 it depends entirely on how you set up the dependency relationships within the recipe... Jul 23 14:23:54 indeed Jul 23 14:24:01 so I tried making it depend on itself Jul 23 14:24:02 does not work Jul 23 14:24:13 not in the traditional way anyway meaning adding a DEPENDS = " Jul 23 14:24:25 DEPENDS ="${PN}-databases" Jul 23 14:24:28 that does not work Jul 23 14:24:43 maybe if you could forward declare that package it might work Jul 23 14:25:19 DEPENDS is a build-time dependency Jul 23 14:25:35 we are talking about runtime dependencies here i.e. RDEPENDS Jul 23 14:38:56 let me try the RDEPENDS Jul 23 19:42:03 Does anyone know how to use a .bbappend file for a .inc file? The .inc file is required in the recipe's .bb file, but I need to adjust the .inc, not the .bb. **** ENDING LOGGING AT Thu Jul 24 03:00:02 2014