**** BEGIN LOGGING AT Mon Nov 07 02:59:57 2011 Nov 07 08:44:09 good morning Nov 07 09:53:11 morning all Nov 07 11:23:29 gm Nov 07 14:18:18 Who is responsable by opkg in Yocto? Nov 07 14:35:14 RP__: sgw: any news about the dhcp fixed? Nov 07 14:35:19 fixes I meant Nov 07 14:44:59 otavio: they will be handled today Nov 07 15:15:29 sgw: good Nov 07 15:15:58 sgw: who is responsable for opkg? it seems it is broken Nov 07 15:17:26 Check the packages.yoctoproject.org, seems to be Dongxiao Nov 07 15:21:11 dongxiao: around? Nov 07 15:22:55 dongxiao: please take a look on the email thread I sent today about bad recommendations being broken ... Nov 07 15:23:20 dongxiao: i've been able to track it down to opkg install replacing the status file Nov 07 15:23:35 otavio: can you please file a bug summarizing that conversation, dongxiao is off as he is located in PRC Nov 07 15:23:52 sgw: i sent a mail to the ml about it already Nov 07 15:24:39 otavio: we need to be able to track some of these in bug reports also, to ensure the tracking that's the purpose of bugzilla. Nov 07 15:26:44 otavio: mailing lists are fine for discussion but when you isolate it to something specific, it needs to become bug so we can track it Nov 07 15:28:41 otavio: dongxiao is also the recipe maintainer, he may or may not have bandwidth to jump in a and look at problems within the software itself unrelated to the recipe itself :/ Nov 07 15:30:34 RP__: I fear this might be a regression of multilib changes Nov 07 15:30:53 RP__: as it probably changes the way opkg handles install Nov 07 15:31:26 RP__: JaMa confirmated this same problem to him Nov 07 15:31:50 otavio: Please file the bug and we'll see if we can get it looked into Nov 07 15:37:45 RP__: reported Nov 07 15:38:04 otavio: thanks Nov 07 15:38:53 RP__: http://bugzilla.pokylinux.org/show_bug.cgi?id=1758 Nov 07 15:41:08 RP__: there's a typo on Kernel's project description on bugzilla Nov 07 15:41:22 RP__: Yotco intead of Yocto Nov 07 15:53:45 otavio: fixed the typo Nov 07 16:08:08 RP__: thx Nov 07 16:11:28 fray: ping Nov 07 16:13:13 hey Nov 07 16:15:58 gm all Nov 07 16:16:34 fray: just looking into this issue that Anders posted on the mailing list (rpm+update-alternatives killing off busybox) Nov 07 16:17:05 fray: is it possible the maintenance script mappings aren't quite right? Nov 07 16:17:24 this guy has a suggested mapping and it's quite different from ours: http://code.google.com/p/fwtemplates/wiki/PackageHooks Nov 07 16:17:36 ya.. I was going to do that investigate that as well Nov 07 16:18:09 what part do you think is wrong? Nov 07 16:18:40 well, I don't know if it's wrong or not, but I can say our use of update-alternatives assumes that prerm/postrm happens before postinst Nov 07 16:18:59 ya, there is no guarenty of that in RPM Nov 07 16:19:18 it uses the dependencies to order the transaction scripts (all scripts in RPM are called transaction scripts) Nov 07 16:20:18 is there a way to solve the problem we have here without adding a check to every invocation of update-alternatives? Nov 07 16:20:30 I'd need to understand what exactly is going wrong.. Nov 07 16:21:34 I am sure we can map the behaviors properly into RPM.. but it might take a small bit of transforming Nov 07 16:23:06 it's fairly simple - use rpm -Uvh to upgrade a package, and (in OE terms) the postinst script gets called. This installs new alternatives. Then the OE prerm gets called, and at the moment for busybox the prerm script removes the alternatives; thus the system becomes broken Nov 07 16:24:13 busybox is just a catastrophic example of this issue but anything using update-alternatives is affected Nov 07 16:24:29 ok.. should be a simple fix.. Nov 07 16:24:57 the scriptlets in RPM are invoked with a single arg.. this argument indicates the number of packages that will remain after the transaction is complete.. Nov 07 16:25:24 in most cases RPM scripts have an if [ $1 -eq 0 ]; then ... do removal actions ... ; fi Nov 07 16:25:51 if it's ne 0 then the package is remaining and we only do whatever we need to when a package stays Nov 07 16:26:09 so the question is, can we simply wrap -all- postrm scripts with this? Nov 07 16:26:24 that makes postrm work only in an actual erase transaction and not upgrade transaction Nov 07 16:26:48 I'd say if that makes it match the behaviour when opkg is used then it should be fine Nov 07 16:26:59 I can test it now Nov 07 16:27:11 but are we actually mapping postrm in packages_rpm.bbclass? Nov 07 16:27:23 fray: yep Nov 07 16:27:28 postrm -> postun Nov 07 16:27:29 ok.. yes we are.. just verified that Nov 07 16:29:02 ya... have the recipe for a test.. if it works.. we might need to unconditionally add the if [ $1 -eq 0 ] ; ... wrapping... (but I'm not sure..) Nov 07 16:29:19 the key thing is that stops any actions from occuring in an upgrade.. which may not be what people want either Nov 07 16:29:50 doesn't dpkg have its own special logic for the scripts for upgrades? does opkg not support it? Nov 07 16:29:51 hmm Nov 07 16:30:18 an alternative (perhaps a bit sketchy) is to use the %pre and %post... merge the removal and upgrade actions as appropriate ordering.. and then continue to use the %postun for removal only? Nov 07 16:31:06 i.e. something like %post = postun ; post Nov 07 16:36:10 kergoth: I think opkg has now grown some logic for this Nov 07 16:36:16 kergoth: but we don't use that version yet :/ Nov 07 16:36:29 ah Nov 07 16:36:51 kergoth: btw, were you going to merge those bitbake patches or were you letting me do it? Nov 07 16:37:02 did the guy (who posted to the oe mailing list) ever start the opkg re-write work? Nov 07 16:37:28 fray: I think there are people slowly chipping away at it Nov 07 16:37:38 'k Nov 07 16:39:47 RP__: I'll go ahead and merge the main bits today if that's fine with you Nov 07 16:44:05 fray: ok, so with ipk in this situation, the prerm doesn't get called on upgrade Nov 07 16:44:25 so on the face of it your suggested fix should be OK, assuming no other tricky situations Nov 07 16:44:29 ok.. so the if [ ... ] bit will work Nov 07 16:44:43 RPM always calls all actions... Nov 07 16:45:06 kergoth: The bits I saw looked fine Nov 07 16:45:21 fray: right, since it kind of has a mechanism to detect what's actually occurring Nov 07 16:45:47 yup.. it should be easy to modify packages_rpm.bbclass to simply wrap it automagically Nov 07 16:45:57 I think postrm will need a similar guard Nov 07 16:46:09 ya.. sounds like it might.. Nov 07 16:46:17 "generally".. Nov 07 16:46:20 $1 == 0 removal Nov 07 16:46:23 $1 == 1 install Nov 07 16:46:35 we seem to use either for update-alternatives depending on which recipe you look at Nov 07 16:46:38 $1 > 1 either a "second" install -- or upgrade Nov 07 16:47:07 (RPM allows two versions of the same package to be installed at the same time as long as the files don't conflict.. this is used by Red Hat for their kernel installs.. personally I think it's a horribly way to do things) Nov 07 17:21:45 fray: so should I put together a patch to add the wrapper? Nov 07 17:22:08 yes please.. Nov 07 17:22:35 I'd like to review it.. also we should quickly audit any postrm scripts and make sure this is reasonable behavior based on current implementations.. Nov 07 17:22:49 (I don't have a copy of meta-oe locally.. but thats the one external source we need to verify IMHO) Nov 07 17:23:02 Koen -- if he's around -- should see if this works for Angstrom as well Nov 07 17:23:14 bluelightning: combo-layer is working fine :D thx Nov 07 17:23:35 otavio: glad to hear it :) no problem **** ENDING LOGGING AT Tue Nov 08 02:59:57 2011