**** BEGIN LOGGING AT Wed Sep 18 02:59:57 2019 Sep 18 04:50:09 pkgadd: well I don't update since a year or so Sep 18 09:11:23 hello all Sep 18 09:12:37 how do you guys maintain dependency compatability? For example ubus depends on libubox. However the packages appear to be updated abitarily. Are packages (e.g. libubox in this example) always backwards compatiable? If not why don't you use so versioning for libraries? Sep 18 09:12:39 thanks Sep 18 09:35:21 Neighbor11111112: we introduced abi versioning in master to track incompatible libraries Sep 18 09:35:39 https://openwrt.org/docs/guide-developer/package-policies#shared_libraries Sep 18 09:36:06 thanks jow Sep 18 09:46:52 pkgadd: It looks there was more going on during the bump besides removing the upstreamed patch --> 1 out of 5 hunks FAILED -- rejects in file arch/arm/boot/dts/gemini-dlink-dir-685.dts Sep 18 09:48:26 jow, I think I understand the ABI versioning. However, I don't see how an executable states it depends on a specfic ABI version of a library. For example if A depends on libB1.0 and libB is bumped to 2.0. Then as I understand the documentation package A will be rebuilt to state in the package it is depdning on libB2.0. So you' have two A packages one the original that depends on liB-1.0 and the new one that depends Sep 18 09:48:26 on libB-2.0. However the latest one is invalid and it appears this system can't detect that Sep 18 09:48:29 is the correct? Sep 18 09:56:51 Neighbor11111112: when attempting to install a newer "A", opkg will attempt to install "libB2.0" which - if properly packaged, succeeds Sep 18 09:57:03 the reuslting system will have both libB1.0 and libB2.02 installed Sep 18 09:57:31 if libB1.0 and libB2.0 clash file-wise, installation/upgrading of A will not be possible Sep 18 10:00:10 jow, that makes sense. However, can you specify that package depends on a specific version of a library? E.g. can package A say it only depends on libB-1.0? Sep 18 10:00:34 yes, DEPENDS:=libB1.0 instead of DEPENDS:=libB Sep 18 10:00:41 ahh got it ok cool Sep 18 10:02:09 looking at ubus and libubox it appears the ubus maintainer assume that when libubox version is updated that it will be compatiable with ubus. Because ubus package does not depend on a specific version of libubox. Is that because core packages assume that libraries are backwards compatiable? Sep 18 10:03:22 source wise it does not depend on a specific version Sep 18 10:03:47 the resulting binary package will depend on the specific abi version ob libubus it was built against Sep 18 10:04:28 in my case: # opkg depends ubus | grep libubus Sep 18 10:04:29 libubus20170705 Sep 18 10:04:30 ahh I understand now why you're calling it ABI not soname. Your concern here is mismatching binary packages not source Sep 18 10:04:45 very cool, understood Sep 18 10:05:00 so I guess my final question is how do you track source-wise versioning dependencies? Sep 18 10:05:27 this was usually done on the packaging level by pulling the major version into the package name Sep 18 10:05:34 e.g. libevent vs. libevent2 Sep 18 10:06:00 so far there are no source version constraints in the buildroot for the build phase Sep 18 10:06:41 if there'll ever be a totally incompatible reimplementation of libubox, it'll likely be called libubox2 Sep 18 10:08:53 ok understood, thanks as always. I guess maintainers actively try avoid breaking backwards compatability Sep 18 10:09:06 yes, that what it boils down to Sep 18 10:09:15 very cool Sep 18 10:09:20 at least within base. The external pacakge feeds are more liberal in this regard Sep 18 10:09:42 but they too try to transition libraries in a coordinated manner Sep 18 10:21:42 pkgadd: and another one ;-) 1 out of 1 hunk FAILED -- rejects in file arch/arm/boot/dts/qcom-ipq4019.dtsi Sep 18 10:31:58 xback: you must be playing with a kernel bump Sep 18 10:32:17 ldir: How did you know? :-o Sep 18 10:32:46 ldir: how are you? it's been a while :-) Sep 18 10:33:43 because I've just been through the same sequence. Original patch doesn't apply 'cos the source text changed a bit, then we have a follow up patch (patch on a patch) that needs a refresh too. Sep 18 10:34:08 I've been in China for the last month doing $dayjob. Sep 18 10:35:06 Audio/system engineering on basketball world cup. Sep 18 10:37:50 it's good to be back in a place with real Internet and bank cards I can actually use. Sep 18 10:38:24 cool :) Sep 18 10:42:02 xback: you've got mail! Sep 18 10:43:58 ldir: just finished refresh here Sep 18 10:44:02 there is a larger delta Sep 18 10:44:22 4 files deleted here Sep 18 10:44:29 which are upstreamed Sep 18 10:44:46 I'm too tired/jetlagged to do anything sensible :-) Sep 18 10:52:47 ldir: bumps for master pushed to staging Sep 18 10:53:28 the 3 removed files for ipq4xx seem to correspond with the 3 commits in the stable commit list Sep 18 10:59:48 meantime the iptables bump has dropped one of my patches that hadn't made it into the 5.2 release...so it hasn't been dropped courtesy upstream. Sep 18 11:00:46 it'll work again when the bump to 5.3 happens. Sep 18 11:10:55 5.4 ? Sep 18 11:20:09 we have two identical files in OpenWrt repo: package/utils/otrx/src/otrx.c and tools/firmware-utils/src/otrx.c Sep 18 11:20:10 I wanted to make package/utils/otrx/Makefile also a host packages but is that possible to make *target* depend on a host package? Sep 18 11:30:44 xback: iproute2 5.3 Sep 18 11:33:16 or do all host packages get build by default? Sep 18 11:40:03 rmilecki: when I'm less jetlagged I'll ping you re fstools Sep 18 11:40:51 ldir: sure, thanks Sep 18 12:04:38 * gch981213 accidentally deleted his ssh key because he didn't name his files properly... Sep 18 12:07:20 xback: I'm not sure gemini should end up with GPIO_ACTIVE_LOW ?? Sep 18 12:29:36 ldir: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.19.73&id=bab0ff2d87db2b2c46c4158f28d37699e396c3c4 Sep 18 12:29:55 gch981213: backup? Sep 18 12:35:12 stintel: I deleted a ssh key dedicated to git.openwrt.org (with different passphrase so that I don't accidentally push stuff there) and I don't have any backup of it. Just asked jow to deploy it for me and I'll have a backup for it this time :) Sep 18 12:36:56 too bad, hope you learned your lesson ;) Sep 18 12:45:46 time to look for some token :p Sep 18 13:02:33 Good old times .. in DOS you had the "undelete" command :-) Sep 18 13:17:47 now we've more robust snapshots Sep 18 13:56:53 rmilecki: you should probably do it other way around if you need it for target, remove (or move the the otrx package to packages feed) and use otrx from firmware-utils Sep 18 14:09:39 ynezz: that way you still have to duplicate the code; the question is if there is a way to not have the sources twice in the tree by a single package for both host (image creation) and target (image verification during sysupgrade) Sep 18 14:13:59 rmilecki: you might get around it by having a package that is hidden defaults to y for targets that use it for sysupgrade (similar to u-boot), that also depends on its own host build to ensure it is built and present - a bit hackish though Sep 18 15:09:17 KanjiMonster: ah, missed that verification bit Sep 18 15:12:46 ynezz: also moving a package that is *required* by a target is a no-go Sep 18 15:12:56 ynezz: we keep such basic packages in the OpenWrt's repo Sep 18 15:14:08 KanjiMonster: actually i don't even need that default y thing if we follow your way Sep 18 15:14:17 KanjiMonster: i already have DEFAULT_PACKAGES += otrx Sep 18 15:14:35 KanjiMonster: so I can make otrx have "PKG_BUILD_DEPENDS := otrx/host" and that will work Sep 18 15:14:45 it just won't be an explicit dependency Sep 18 15:14:50 it will work though Sep 18 18:29:43 xback: sorry, I'm only building ath79, ipq806x and lantiq, so I don't really notice issues in other targets, while I hope to add ipq40xx to the mix, so far I don't have any devices for that. Sep 18 18:48:17 jow: https://lkml.kernel.org/r/1568820782-4679-1-git-send-email-aaron.komisar@tandemg.com is probably related **** ENDING LOGGING AT Thu Sep 19 03:01:42 2019