**** BEGIN LOGGING AT Tue Jul 30 02:59:58 2013 Jul 30 07:54:31 Hi, is there any way to set PREFERRED_VERSION_udev in image's .bb file or the only way is to use local.conf (or some other .conf)? Jul 30 07:57:46 morning all Jul 30 07:58:03 dzoe: no, it has to be at the configuration level Jul 30 07:58:30 bluelightning: and for example at meta layer configuration level? Jul 30 07:58:50 dzoe: it would typically be in your custom distro configuration Jul 30 08:00:06 <_frank_> morning, bluelightning~ In yocto, many places used "d" variable, like "packages = d.getVar('PACKAGES', True)". Jul 30 08:00:31 <_frank_> Then, where is "d" defined ? and when is it cleared ? Jul 30 08:00:31 _frank_: indeed Jul 30 08:01:48 _frank_: it's normally passed into most python functions, either implicitly (for python xyz() { }) or explicitly (def funcname(arg1, arg2, d): ...) Jul 30 08:02:12 _frank_: you can find the class declaration for it in bitbake/lib/bb/data_smart.py Jul 30 08:03:30 <_frank_> bluelightning: yeah, thanks for help ! Jul 30 08:10:15 Ah, so basically I just add distro policy in meta-mylayer/conf/distro - that's easy. Jul 30 08:10:20 bluelightning: thank you Jul 30 08:48:28 <_frank_> What does PACKAGE_INSTALL_ATTEMPTONLY mean ? attemptonly ?? Jul 30 09:26:59 hi all Jul 30 09:27:25 today, I guess I will test the first hambedded linux image in ALIX board. I hope I will succeed in getting KISS modem working :) Jul 30 09:34:42 _frank_: it's a mechanism for attempting to install recipes that are not hard requirements where installing them might not always be possible (due to unsatisfied dependencies or conflicts) Jul 30 09:34:49 er, s/recipes/packages/ Jul 30 09:42:04 <_frank_> bluelightning: Then, RRECOMMENDS_{PN} will be interpreted to this kind attempting packages ? Jul 30 09:42:43 _frank_: no, that is handled separately by the package manager Jul 30 09:43:03 _frank_: although in past versions for RPM I think recommends might have gone into there Jul 30 09:44:57 <_frank_> bluelightning: I wonder what will result in PACKAGE_INSTALL_ATTEMPTONLY ? Jul 30 09:45:16 good morning Jul 30 09:45:24 <_frank_> As we know, IMAGE_INSTALL + "xxx" will go to PACKAGE_INSTALL Jul 30 09:46:04 _frank_: "git grep PACKAGE_INSTALL_ATTEMPTONLY" is your friend ;) Jul 30 09:51:14 <_frank_> bluelightning: Thanks! Jul 30 13:27:47 hi bluelightning: you can close this one: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4439 Jul 30 13:27:48 Bug 4439: normal, Medium, 1.5, kergoth, ACCEPTED , devshell fails to open a new tmux session Jul 30 13:28:52 panda84kde: will do Jul 30 13:29:12 bluelightning: thanks for fixing it! :) Jul 30 13:29:26 panda84kde: thank the patch submitter, I just tried it out :) Jul 30 13:30:43 right... Jul 30 13:46:39 ah, I need to try that as well Jul 30 13:46:47 I applied the workaround before Jul 30 13:46:48 let's see :) Jul 30 13:50:04 bluelightning: there is another workaround for it, have you looked at it? Jul 30 13:50:31 cml1.bbclass Jul 30 13:50:48 I am wondering why it was not committed Jul 30 14:02:50 eren: I have, but that changes the behaviour for all terminals; this is a tmux-specific problem and should be fixed by the patch I've pointed to Jul 30 14:03:04 oh ok Jul 30 14:03:13 I guess we can close the bug after 2 confirmation Jul 30 14:03:16 eren: did the patch I pointed to work for you? Jul 30 14:03:21 bluelightning: yes Jul 30 14:03:25 great :) Jul 30 14:03:41 I guess we will see it included in the next release cycle? Jul 30 14:04:23 yes, I'll add it to paule/dylan-next now for testing Jul 30 14:04:29 okkie Jul 30 14:04:35 (poky-contrib branch that is) Jul 30 14:05:03 bluelightning: is there a problem with git.yoctoproject.org btw? Jul 30 14:06:00 it's really slow for me Jul 30 14:06:52 eren: hmm yes it does seem a bit slow for me too Jul 30 14:07:01 http://dpaste.com/1323160/ Jul 30 14:07:13 it seems that the bottleneck is level3 Jul 30 14:07:26 at least for me Jul 30 14:09:15 yeah, definitely there is a problem with level3 Jul 30 14:09:17 eren: the 100% loss items are a bit of a concern... Jul 30 14:10:12 bluelightning: yeah, the output is from Turkey, our ISP's behind-the-wall filtering/spying device I guess :) Jul 30 14:10:31 I've tried from UK, linode: http://dpaste.com/1323165/ Jul 30 14:11:13 eren: that's OK, in recent months we've discovered (to not much surprise) that most countries have pretty intensive "spying" programmes :) Jul 30 14:11:36 yeah :) Jul 30 14:12:38 halstead: are you aware of any current problems affecting access to git.yoctoproject.org? Jul 30 14:14:47 bluelightning: it seems that it is throttling the bw Jul 30 14:15:32 I get linux-yocto around 400 - 500 KB/s Jul 30 14:15:45 from UK / Linode Jul 30 14:17:27 s/get/clone/ Jul 30 14:27:51 http://pastebin.com/EgU1s9Vt -> this is another regression in dylan? Jul 30 14:27:58 I did not get such error messages with denzil. Jul 30 14:29:16 lpapp: no aware of any fetcher checksum changes, but i'm not paying attention there. if you name your tarballs you need to use the names in the checksums, like the lines it gave you. Jul 30 14:29:39 the meta/recipes-kernel/... does not do that though. Jul 30 14:31:02 linux-yocto uses git so that isn't checksumed Jul 30 14:32:08 I see. OK, this was not a problem with denzil though. Jul 30 14:32:30 maybe denzil didn't mandate the name, dunno. Jul 30 14:33:28 sorry? Jul 30 14:33:41 maybe denzil fell back to the non-named checksum Jul 30 14:33:44 you mean, it did not mandate the presence of the checksum? Jul 30 14:33:58 if you had a tarball you'd need a checksum Jul 30 14:34:30 as I said, it was not a problem for denzil. Jul 30 14:34:41 so it is likely a new "intrusive action". Jul 30 14:34:50 well, it's more correct this way Jul 30 14:35:08 anyway, easy to fix and naming the checksums is more expressive/accurate when you have multiple files Jul 30 14:35:13 (if you don't, no need to name them generally) Jul 30 14:36:12 well, you usually have patches for the kernel in a bsp layer ... Jul 30 14:37:00 seems the error does not go away if I manually insert those two lines into the kernel recipe. Jul 30 14:37:00 true Jul 30 14:37:11 then something Very Odd is happening, pastebin? Jul 30 14:37:41 the same error? Jul 30 14:38:59 perhaps I should delete the tarball before retry Jul 30 14:39:25 no Jul 30 14:39:31 pastebin the recipe please Jul 30 14:40:04 actually, deleting the tarball helped. Jul 30 14:40:15 i can't see any reason for that Jul 30 14:40:36 but i'm not going to argue it! :) Jul 30 14:42:22 weird, it came up again, just much later. Jul 30 14:42:37 it was probably downloading the tarball Jul 30 14:42:42 it will do many things in parallel Jul 30 14:42:47 pastebin the latest error and your recipe Jul 30 14:43:40 (with a dep chain of a->b->c, whilst a is still building bitbake will extract and patch b and c) Jul 30 14:43:43 http://pastebin.com/N9Z0pAh3 Jul 30 14:43:53 no, it was not. Jul 30 14:44:03 according to bitbake, that went fine ("fetch"). Jul 30 14:44:07 and it was doing some other jobs. Jul 30 14:45:34 can you pastebin the recipe too? Jul 30 14:45:39 hmm, so kernel.md5sum != tarball.md5sum Jul 30 14:45:41 sorry, no. Jul 30 14:45:50 correct Jul 30 14:46:02 your SRC_URI has name=kernel Jul 30 14:46:07 I do not think it should be this complicated. Jul 30 14:46:21 so you need a checksum called kernel.md5sum Jul 30 14:46:21 it does not matter whether it is the kernel or something else. Jul 30 14:46:31 this is generic bitbake checksumming Jul 30 14:46:32 the checksum should be standardized how it is expressed in bitbake. Jul 30 14:46:37 it is Jul 30 14:46:41 might be generic, but whether it is good. Jul 30 14:46:45 that is questionable. Jul 30 14:46:48 here is the example at hand. Jul 30 14:46:49 SRC_URI[optional-name.md5sum] Jul 30 14:47:25 you may have multiple tarballs, so you need a way to identify them Jul 30 14:47:29 the naming is entirely up to you Jul 30 14:47:29 too much flexibility for no apparent gain. Jul 30 14:48:04 most people will not change the order, so that could be the common denominator. Jul 30 14:48:53 1: gcc-cross-4.7.2-r20 do_compile (pid 10855) Jul 30 14:48:55 ??? Jul 30 14:49:00 why is it building that? Jul 30 14:49:09 I explicitly have an external toolchain! Jul 30 14:49:53 didn't you have that problem earlier? some dependency the external toolchain wasn't providing, iirc. Jul 30 14:50:10 no, I did not. Jul 30 14:50:29 "bitbake -g -u depexp" should let you see what is pulling it in Jul 30 14:50:32 then you can work out why Jul 30 14:52:54 WARNING: linux-foo: No generic license file exists for: GPL in any provider Jul 30 14:53:04 that seems to be a new change with dylan as well... Jul 30 14:53:55 not sure I understand the warning. Jul 30 14:54:07 you need to version "GPL" Jul 30 14:54:43 ie "GPLv2" Jul 30 14:55:32 there wasn't a "GPL" in denzil either from what I can tell Jul 30 14:57:10 not sure what that means. Jul 30 14:58:21 using License="GPL" in denzil was likely to produce a warning, from what i can see Jul 30 14:58:37 the kernel is v2, so you need to say GPLv2 Jul 30 14:59:09 very important as i'm sure you're aware, you don't want to accidently use any GPLv3 code if that concerns you Jul 30 15:00:13 YPTM: Scott Rifenbark is on the call Jul 30 15:00:31 http://pastebin.com/FkAz7uik -> yet another dylan warning/error? Jul 30 15:01:16 YPTM: Welcome to the tech team meeting, please let me know who's on the bridge. Thanks! Jul 30 15:01:16 YPTM: Tom Z on Jul 30 15:01:26 YPTM: Paul Eggleton joined Jul 30 15:01:46 YPTM: jzhang's on the call Jul 30 15:01:53 YPTM: I'm here Jul 30 15:01:56 YPTM: Darren is on Jul 30 15:02:07 lpapp: does the stock busybox build? might be your recipe using internal functions that got removed. Jul 30 15:02:10 YPTM: Song, Sean is here. Jul 30 15:02:32 * darknighte waves Jul 30 15:02:46 YPTM: ross here Jul 30 15:02:54 YPTM: Nitin is on the bridge Jul 30 15:03:08 YPTM: Dial-in number: 1.972.995.7777 / Participant passcode: 42001078 Jul 30 15:03:14 YPTM: Saul is on Jul 30 15:03:40 YPTM: Any opens? Jul 30 15:03:42 YPTM: LaurentiuP joined Jul 30 15:04:06 YPTM: Michael here. Jul 30 15:04:41 YPTM: Song_Liu: a reminder: there is a OE project IRC discussion in the next hour. Jul 30 15:04:50 oh Jul 30 15:04:55 * eren connecting Jul 30 15:05:46 YPTM: Cristian is present Jul 30 15:06:03 YPTM: Bruce Ashfield in on. Jul 30 15:06:50 YPTM: Eren is present Jul 30 15:06:50 bluelightning, Is git.yp.org still slow for you? Jul 30 15:06:53 YPTM: Matthew Weigel just joined Jul 30 15:07:01 YPTM: Beth joined Jul 30 15:07:16 halstead: a little bit, but eren was having some more serious difficulties Jul 30 15:08:43 halstead: yeah, I cloned linux-yocto at the rate of ~400 KB/s Jul 30 15:09:13 I cloned, no problem for me but I'm wondering why it was that slow Jul 30 15:10:10 eren, We have been near our bandwidth cap (60mbps) recently. http://is.gd/aSumhe Jul 30 15:11:09 halstead: oh, assuming that that's a bw problem then? Jul 30 15:11:18 halstead: whoa, what was that spike? :) Jul 30 15:12:37 rburton, The large spike going over the cap at 20:00 is a backup to a network peer. That's why it can go so high. Jul 30 15:12:56 ah Jul 30 15:13:17 rburton, That transit really should be excluded from the graph but it isn't. Jul 30 15:13:24 i need me some of that capacity here Jul 30 15:13:52 That would be nice. :) Jul 30 15:14:05 halstead: do you use munin for network graph? Jul 30 15:14:13 sorry for off-topic question :) Jul 30 15:16:02 any link for "making of?" Jul 30 15:16:34 eren, No. Just using our ISP's graphs right now. Jul 30 15:16:49 halstead: okkie, thanks. Jul 30 15:17:02 is Beth around? Jul 30 15:17:18 AlexG: beth is pidge Jul 30 15:17:26 dvhart: woot on getting so much into the maintainer trees. Jul 30 15:17:41 sgw_: tnx Jul 30 15:17:44 eren, Link to "making of" https://www.youtube.com/watch?v=Qbr9QYFmzrU&feature=player_embedded Jul 30 15:19:36 halstead: thanks Jul 30 15:20:13 halstead: vacation!?! who authorized that? Jul 30 15:20:19 +1 Jul 30 15:21:07 darknighte, Some crazy LF person. Jul 30 15:22:30 halstead: Hope you have a great time and manage to forget about work (for the most part) for a while. Jul 30 15:24:00 darknighte, Thanks. I'll go out on southern Oregon whitewater for a bit and then see a play or three in Ashland OR. Should be fun. Jul 30 15:24:14 github.com/eren/meta-hamradio Jul 30 15:24:16 Sounds fun. Jul 30 15:24:23 halstead: I am jealous about whitewater! Jul 30 15:25:09 halstead: sgw_: I have never gone on whitewater. Jul 30 15:25:30 halstead: aren't there different levels? Jul 30 15:25:56 eren: I need to get my station back up soon :) Then I can start testing! Jul 30 15:26:22 pidge: oh okkie! :) Jul 30 15:26:30 thanks Jul 30 15:26:48 eren: antenna mast collapsed Jul 30 15:27:27 it sounds like pidge likes to brutalize her keyboard… Jul 30 15:27:34 pidge: oh :/ sad. Jul 30 15:27:46 pidge: only aprs support is there, btw. Jul 30 15:27:52 darknighte, Each series of rapids is rated 1-6. I've done up to 4. (http://en.wikipedia.org/wiki/Rafting#Grades_of_white_water) Jul 30 15:28:05 I'm also working on ALIX 3D3 support, so it will be a little complicated :) Jul 30 15:28:22 I will see if it boots and try to interface it with KISS modem Jul 30 15:28:41 eren: I had grig support working a while back. Jul 30 15:29:00 YPTM: thank you all for joining the meeting, have nice day or evening! Jul 30 15:29:05 darknighte: my keyboard is loud Jul 30 15:29:12 brb Jul 30 15:29:33 halstead: so, going for a grade 6? Jul 30 15:29:35 khem, did you disappear the 2.18 eglibc tarball, do we need to recreate that on the downloads.yp.org? Jul 30 15:29:50 halstead: I like the description on wikipedia... Jul 30 15:30:03 damn. i was hoping to use this native systemd-tmpfiles to prepopulate tmpfiles.d, but it can't e built on rhel5/centos5, which is where we still do most of our builds Jul 30 15:30:07 * kergoth grumbles Jul 30 15:30:20 halstead: "Skill level: successful completion of a Class 6 rapid without serious injury or death is widely considered to be a matter of great luck or extreme skill and is considered by some as a suicidal venture" Jul 30 15:30:27 darknighte, I'll probably stick with the easy ones as I'm a bit rusty. Jul 30 15:31:06 halstead: the rouge? on your own or with a guide? Jul 30 15:31:42 halstead: that sounds prudent to me. it sounds like great fun no matter what class. Jul 30 15:33:37 hehe, these boards are literally "cooked" (minnowboard) Jul 30 15:34:50 sgw_, With a guide company. Probably a half day on the upper klamath and a full day on the rogue. Jul 30 15:37:05 halstead: nice, we did a family trip a couple of years ago on the rogue, was blast, I actually kayaked a bunch of it (but not the bigger stuff) Jul 30 15:39:05 darknighte, thanks :) Jul 30 15:39:27 sgw_, When I was 19 I did a five day trip on the rogue with a paddle boat, an oar boat for gear, and two IKs. It was a good trip with a lot of downtime. Jul 30 15:48:53 bluelightning: do you have the external-sourcery patch in your dylan queue? Jul 30 15:49:06 sgw_: I can add it definitely Jul 30 15:49:40 bluelightning: do you want me to leave bug 4908 open for dylan now, probably should take that, I will mark you owner also. Jul 30 15:49:40 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4908 normal, Medium+, 1.5 M3, saul.wold, IN PROGRESS REVIEW , External toolchain does not work with poky dylan Jul 30 15:50:20 sgw_: yes let's keep it open until the patch is merged in dylan Jul 30 15:51:58 kergoth: ^ Jul 30 16:04:08 rburton: I have the busybox version from danny Jul 30 16:04:12 which is not working with dylan apparently ... Jul 30 16:04:24 this change broke it from RP: http://bpaste.net/show/118688/ Jul 30 16:04:38 lpapp: why are you using danny's busybox with dylan? Jul 30 16:05:28 rburton: because dylan's busybox does not work. Jul 30 16:05:38 also, we have custom patches Jul 30 16:06:18 it does work, what's your specific problem? i recommend applying your patches in a bbappend instead of taking a recipe from another version and amending that. Jul 30 16:06:22 is there a way for sending patches to the mailing list without subscriving and moderation? Jul 30 16:06:28 it is getting tedious. Jul 30 16:06:38 you can subscribe and turn off mail delivery Jul 30 16:06:44 then you don't get moderated but you don't get list mail Jul 30 16:06:54 rburton: no no Jul 30 16:07:03 rburton: our busybox is quite different. Jul 30 16:07:08 with changes, very unlikely for upstreaming. Jul 30 16:07:17 and they are intrusive. Jul 30 16:07:23 .bbappend will not help you there. Jul 30 16:07:50 fine, so fork the one native to your release Jul 30 16:08:15 rburton: that leaves me stale in a few years. Jul 30 16:08:24 on many mailing lists, then... i.e. not a preferred option. Jul 30 16:08:32 rburton: it was already forked back then. Jul 30 16:08:54 so, can anyone explian RP's change? Jul 30 16:09:06 I do not quite get it from the commit message. Jul 30 16:09:12 nor that, what I am supposed to do afterwards ... Jul 30 16:10:54 so basically, Yocto does not provide API guarantee. Jul 30 16:11:04 source code interface can break at any moment. Jul 30 16:11:57 so basically forking is an unpleasure experience then ... Jul 30 16:12:04 because the Yocto API is inherently unstable. Jul 30 16:12:09 no guarantees. Jul 30 16:13:57 lpapp: that commit make the file deps handling be threaded, and it shouldn't have broken your recipe Jul 30 16:14:27 rburton: process_deps is not available anymore after that commit ... Jul 30 16:14:33 as you can see it was moved around ... Jul 30 16:15:10 sounds like a bugzilla entry for documenting the no api compatibility promise. Jul 30 16:15:47 NameError: global name 'process_deps' is not defined Jul 30 16:15:51 lpapp: i still recommend forking the busybox recipe in the version of your distro, instead of attempting to use one from an older release Jul 30 16:15:52 after that particular change ... Jul 30 16:16:09 rburton: you are not real. Jul 30 16:16:16 rburton: causing extra work for us is not wished. Jul 30 16:16:29 rebase all the stuff, test all the utils thoroughly, etc. Jul 30 16:16:37 lpapp: if you pastebin the recipe i may be able to help you solve your parsing problems Jul 30 16:16:51 rburton: recipe was already pasted. Jul 30 16:16:53 or if you just have patches, use a bbappend. Jul 30 16:16:58 but it upstream danny, really. Jul 30 16:17:01 lpapp: sorry i'm also in meetings and trying to do work, must have missed it Jul 30 16:17:20 as I said before, .bbappend is a complete no go Jul 30 16:17:26 please read back why I claimed that. Jul 30 16:17:57 i did, and i don't understand Jul 30 16:18:11 read harder. :) Jul 30 16:18:28 also, after the mailing list incident about fixing a serious regression, I do not wish to do any upgrade to busybox Jul 30 16:18:36 it is fully broken, and should not be used for my project Jul 30 16:19:12 you will have more work in the end with the support than accepting, but I was trying to be clear about it. Jul 30 16:19:33 I have to maintain old stuff, you need to support more. Jul 30 16:19:43 it is a lost/lost for everyone involved except a very few people, if any! Jul 30 16:23:26 https://bugzilla.yoctoproject.org/show_bug.cgi?id=4958 Jul 30 16:23:26 Bug 4958: normal, Undecided, ---, scott.m.rifenbark, NEW , No documentation about source compatibility Jul 30 16:24:35 lpapp: help harder... Jul 30 16:24:55 bluelightning: ? Jul 30 16:25:11 you want rburton to help you, so help him to do so by explaining yourself clearly Jul 30 16:25:23 please Jul 30 16:25:49 bluelightning: what to explain, please? Jul 30 16:26:01 there are more specific questions than "I do not understand". Jul 30 16:27:32 lpapp: please explain why a bbappend won't work for you because that is the mechanism we recommend for adding a few patches/supplying a different config to a recipe such as busybox Jul 30 16:27:45 I already did Jul 30 16:28:14 besides, no, you have actually suggested a *fork* for patches that will not be upstreamed. Jul 30 16:28:37 nothing about bbappends mandates sending patches upstream Jul 30 16:29:00 and even .bbappend would not fly really, as it does not solve the main problem at hand: avoid the additional rebase and relevant works because someone thought it is good to break source compatibility. Jul 30 16:29:14 that's exactly what a bbappend is designed to solve Jul 30 16:29:36 not really, no. Jul 30 16:29:46 it needs *manual* work to rebase changes, a lot, like this discussion. Jul 30 16:30:30 * lpapp wonders why he needs to fight for trivial things, like so many others fork packages out there, and now being pointed as evil Jul 30 16:30:50 it is the same as the defense of the almost non-existing rfkill users. Jul 30 16:30:59 I am bored with fighting for trivial stuff. Jul 30 16:31:02 we're not stopping you fork, but it's your problem when the fork needs rebasing Jul 30 16:31:41 which is what bbappend is designed to do, you can change sources/add patches/add functions and not care when the "real" recipe is updated Jul 30 16:31:45 the fork does not need any rebasing. Jul 30 16:31:53 that is the whole point of the fork. Jul 30 16:32:01 the upstream source version can be retained easily. Jul 30 16:33:06 I am coming here for help, not to get more work on my shoulder. Jul 30 16:33:36 RP: you broke the stuff, any clue what to change in the fork? Jul 30 16:33:45 lpapp: this is a rare instance where a recipe was broken because it called internal functions in package.bbclass, this is not a common case Jul 30 16:34:08 lpapp: the community is happy to offer advice, but remember we all have work to do. You need to do work too. :-) Jul 30 16:34:16 lpapp: if you prefer not to use a bbappend and rebase your patches each release, I'd suggest to resolve this particular issue, just use the current inc file Jul 30 16:34:23 davest: ? Jul 30 16:34:32 I have been doing simple yocto stuff for two weeks soon Jul 30 16:34:35 to get something basic done? Jul 30 16:34:38 in full time Jul 30 16:34:50 with an already well-innovated system into Yocto. Jul 30 16:35:14 bluelightning: that might bring new dependencies in, not present in other places... Jul 30 16:35:20 bluelightning: which can launch an avalanche. Jul 30 16:35:42 lpapp: what would you like us to do, then? Jul 30 16:35:46 I would rather wait for an expert feedback, basically RP who broke it. Jul 30 16:36:05 RP is on holiday, you may be waiting some time Jul 30 16:36:14 lpapp: perhaps you might be better served by someone like Wind River or Mentor who you can get paid support from. Jul 30 16:36:19 and no one else knows why he broke it? Jul 30 16:36:25 like reviewers who approved? Jul 30 16:36:40 davest: oh, yeah, that is so cheap Jul 30 16:36:47 but if you pay, well, why not? :) Jul 30 16:36:48 lpapp: at the time he made the change, FYI, the inc file no longer had a reference to the function Jul 30 16:37:00 lpapp: I observe a definite fatigue factor on the community's part Jul 30 16:37:07 bluelightning: yes, I checked. Jul 30 16:37:16 bluelightning: but that does not mean, he did not break the API Jul 30 16:37:47 lpapp: you're assuming it was stable API to begin with. i'm not sure where that was documented. Jul 30 16:37:54 davest: well, if Yocto is fatigue, that might be right. :) Jul 30 16:38:02 davest: we are all here to improve it to be less tiring. Jul 30 16:38:06 i.e. proper errors, etc Jul 30 16:38:07 lpapp: so the change was good, as busybox was fixed before the change was made. Jul 30 16:38:30 rburton: as I wrote just a few lines above, it broke the API for other people. Jul 30 16:38:42 rburton: yes, of course, I assumed Yocto provides stable stuff Jul 30 16:38:46 pardon me. Jul 30 16:38:52 see my bugreport for action points. Jul 30 16:40:43 is the busybox.inc supposed to work with older busybox releases as is? Jul 30 16:41:26 it's not designed to be generic for all time, no Jul 30 16:41:33 :'( Jul 30 16:41:57 but if you've a compatible busybox its a big fragment you can include and then tweak from your .bb Jul 30 16:42:15 so basically if you are coming from one older release (~6 month), you might be screwed. Jul 30 16:42:59 there's a spectrum of ways to change a package Jul 30 16:43:22 fork the .bb / use a common .inc / use a bbappend Jul 30 16:43:23 sounds like a call for a public discussion Jul 30 16:43:31 to actually deprecate stuff maximum, but not break. Jul 30 16:43:44 deprecate implies remove Jul 30 16:43:51 lpapp: I think what you are suggesting would be impossible to validate Jul 30 16:44:06 rburton: in the future. So? Jul 30 16:44:27 davest: no idea what you are saying. Jul 30 16:44:48 "is the busybox.inc supposed to work with older busybox releases as is?" Jul 30 16:44:55 That would be impossible to validate Jul 30 16:45:03 sure, it would be possible. Jul 30 16:45:14 Not with bounded resources of an open source project Jul 30 16:45:17 go back a few releases, but at least two (~1 year) Jul 30 16:45:25 remember, you are not paying money for this work Jul 30 16:45:32 davest: it really has nothing to do with that. Jul 30 16:45:35 it could be all automated, really. Jul 30 16:45:41 it is a machine work, not human. Jul 30 16:45:46 Again, takes work to do that Jul 30 16:45:48 for every supported board? Jul 30 16:46:02 do you want to volunteer to do it? Jul 30 16:46:27 Jefro: of course no, just the supported toolchains etc ... which are still undocumented... Jul 30 16:46:32 see my bugreport for details. Jul 30 16:47:44 let us see who approved that break. Jul 30 16:49:28 so, it could be that one release (~6 months) back is verified against the change with the supported combinations, and then the information could also be used for writing the porting guide. Jul 30 16:49:53 if something breaks, at least a porting guide could help. Jul 30 16:50:37 the release notes have an upgrading section, but sadly humans are involved so stuff gets missed Jul 30 16:51:10 rburton: how would you know something breaks if you do not have CI? Jul 30 16:51:15 you would have much less power to know. Jul 30 16:51:40 so, I think the first step ahead could be testing one version back with CI Jul 30 16:51:50 and that could also give some continuity between releases. Jul 30 16:52:01 so one person coming from 2 or 3 versions back can still follow the progress. Jul 30 16:52:24 note, even if I decided to upgrade to the latest busybox, dylan would still be broken Jul 30 16:52:30 as my change was rejected Jul 30 16:52:38 so I do not even bother to get twice more work. Jul 30 16:52:57 lpapp: believe this does go beyond what we're able to do, unless you feel inspired to volunteer. Jul 30 16:53:05 lpapp: as I said, you can always work with an OSV Jul 30 16:53:40 well, it is not my problem, only. Jul 30 16:53:45 it is also your, and your users' problem. Jul 30 16:54:13 it would be a generic quality and documentation gate. Jul 30 16:54:16 lpapp: we try to be responsive if there is a strong demand Jul 30 16:54:40 lpapp: but remember, it's still free software Jul 30 16:55:30 I think the issue is that lpapp is trying to do things outside of what we normally test for. We can only build & test for a finite number of combinations of things, so we try to meet as many combinations as we can. I can also see his point, that there are things that "should" work - while we welcome contributions to help get those things working, there is only so much one team can do. Jul 30 16:55:38 it is not possible to search on patchwork for an sha? o_O Jul 30 16:56:00 Jefro: no no Jul 30 16:56:06 not correct? Jul 30 16:56:15 Jefro: it would be equivalently broken for any supported combination with one release back. Jul 30 16:56:28 regardless toolchain, machine, distro, whatsoever. Jul 30 16:56:42 a python function got moved around. It is platform agnostic stuff. Jul 30 16:57:07 Jefro: I do not think you will give CI access for me. Jul 30 16:57:14 so inherently, I cannot help. Jul 30 16:57:33 lpapp: if you are suggesting we validate one version back for all recipes to make sure they still function, that is not sensible Jul 30 16:57:45 lpapp: excuse me Jul 30 16:57:51 lpapp: I meant to say Jul 30 16:58:07 lpapp: creating a working operating system is a tricky thing Jul 30 16:58:22 lpapp: you need to get everything just right to make it work Jul 30 16:58:30 lpapp: it's not easy, believe me Jul 30 16:58:49 davest: easy or not, it would make a lot of sense IMO... ;-) Jul 30 16:59:08 lpapp: and YP is so flexible and the universe of possible combinations so large Jul 30 16:59:23 lpapp: I just don't see how an open source community project could do better Jul 30 16:59:28 well, you will not give access for me to the CI, will you Jul 30 16:59:35 lpapp: but we really do try to do better, all the time Jul 30 17:00:33 if you do not, you cannot say, I should help because I am physically unable. :) Jul 30 17:00:50 lpapp: well, anything is possible Jul 30 17:01:03 yeah, right ... :) Jul 30 17:01:03 lpapp: honestly though, I would want to meet with you first Jul 30 17:01:50 https://bugzilla.yoctoproject.org/show_bug.cgi?id=4958 -> anyway, this can be a starting step, and probably not hard to resolve. Jul 30 17:01:50 Bug 4958: normal, Undecided, ---, scott.m.rifenbark, NEW , No documentation about source compatibility Jul 30 17:01:55