| 00:13.34 | *** join/#oe Jay7 (~jay@2.93.203.177) |
| 01:28.28 | *** join/#oe darkschneider (~gab@93-32-59-44.ip32.fastwebnet.it) |
| 01:44.54 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 03:40.09 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 04:05.56 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 04:48.01 | *** join/#oe Jackie (~quassel@106.120.101.38) |
| 04:57.39 | *** join/#oe rob_w__ (~rob@ppp-88-217-122-141.dynamic.mnet-online.de) |
| 06:07.20 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 06:11.32 | *** join/#oe AndersD (~anders@213-64-219-84-no126.business.telia.com) |
| 06:51.29 | *** join/#oe rob_w (~bob@93.104.205.194) |
| 06:51.29 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 06:54.28 | *** join/#oe zerus (~epetmab@77.105.235.174) |
| 07:03.09 | *** join/#oe contempt (contempt@unaffiliated/contempt) |
| 07:38.01 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 07:44.48 | *** join/#oe RP (~richard@5751f4a1.skybroadband.com) |
| 07:55.37 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-jjfpzkgpwbrdjada) |
| 08:05.38 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 08:09.49 | bluelightning | morning all |
| 08:18.54 | *** join/#oe ant_work (~ant__@host202-80-dynamic.180-80-r.retail.telecomitalia.it) |
| 08:25.58 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 08:33.55 | *** join/#oe maxin (~maxin@37-219-82-155.nat.bb.dnainternet.fi) |
| 08:34.21 | *** join/#oe jku (jku@nat/intel/x-hmprwayozmikfcev) |
| 08:37.13 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 08:38.00 | *** join/#oe blitz00 (stefans@unaffiliated/blitz00) |
| 08:43.08 | mckoan | good morning |
| 08:43.23 | t0mmy | morning |
| 08:43.35 | flo_lap | good morning |
| 08:44.40 | *** join/#oe vdehors (~vincent@LAubervilliers-656-1-235-184.w193-248.abo.wanadoo.fr) |
| 08:45.27 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 08:47.27 | *** join/#oe Alex_V (~xse@80.97.6.174) |
| 09:00.16 | *** join/#oe Tarnyko (~Administr@46.18.96.42) |
| 09:05.24 | *** join/#oe belen (~Adium@192.198.151.43) |
| 09:19.14 | *** join/#oe maxin (~maxin@37-219-82-155.nat.bb.dnainternet.fi) |
| 09:20.46 | *** join/#oe jonathanmaw (~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk) |
| 09:30.16 | *** join/#oe maxin (~maxin@2001:998:22:0:51ae:7f88:d1fa:cc77) |
| 09:35.38 | Jin^eLD | mornin |
| 09:55.00 | *** join/#oe RP (~richard@5751f4a1.skybroadband.com) |
| 09:56.13 | Jin^eLD | hmm, I'm being plagued by a problem in do_rootfs where exactly one and the same package produces an error "opkg_install_pkg: Package xyz md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'." |
| 09:56.17 | Jin^eLD | it's a multimachine build |
| 09:56.22 | Jin^eLD | and this package is an allarch one |
| 09:56.33 | Jin^eLD | when I -c cleanall stuff around and retry a couple of times it then works |
| 09:56.53 | Jin^eLD | so far I failed to find the source of the problem, the recipe itself looks not different from many others that I have, yet exactly this one is failing |
| 09:57.01 | Jin^eLD | and hints on how to debug this? |
| 09:58.11 | bluelightning | this keeps on coming up |
| 09:58.28 | bluelightning | I don't think anyone's come up with a reproducer for it though |
| 09:58.38 | bluelightning | the fact that it's an allarch recipe is suspicious though |
| 09:58.38 | Jin^eLD | aha, so its somewhat a known issue? |
| 09:58.52 | Jin^eLD | I get it pretty consistently |
| 09:58.53 | bluelightning | well, it's been reported by a few different people |
| 09:59.08 | Jin^eLD | so if you have ideas on what to look for I could try to debug |
| 09:59.50 | bluelightning | you'd first want to establish if the recipe is rebuilding when you change machines, if it is then use bitbake-diffsigs to compare between the two executions |
| 10:00.17 | Jin^eLD | well, in my case the recipe had no changes |
| 10:00.27 | Jin^eLD | and I have ab out 5 recipes that look exactly the same and they work just fine |
| 10:00.28 | *** join/#oe RP (~richard@5751f4a1.skybroadband.com) |
| 10:00.33 | Jin^eLD | its a recipe of some installation manuals |
| 10:01.03 | Jin^eLD | so it keeps failing from time to time while the recipe itself did not undergo any changes |
| 10:01.06 | *** join/#oe RP (~richard@5751f4a1.skybroadband.com) |
| 10:01.30 | Jin^eLD | which for me is weird in itself, I mean.. why would it complain about something that has not changed? |
| 10:01.57 | *** join/#oe RP (~richard@5751f4a1.skybroadband.com) |
| 10:02.12 | Jin^eLD | let me google up on the diffsigs thing |
| 10:04.47 | Jin^eLD | bluelightning: well, now I am in a state where doing my build would only run do_rootfs, everything else is through; if I cleanall the package in question it will probably work again |
| 10:04.49 | *** join/#oe tasslehoff (~Tasslehof@77.40.182.98) |
| 10:05.13 | Jin^eLD | what task name would I use for the diffsig thing? |
| 10:05.39 | *** join/#oe JaMa (~martin@ip-86-49-34-37.net.upcbroadband.cz) |
| 10:05.40 | bluelightning | Jin^eLD: you're sure that if you change machine you don't get any setscene tasks run? pipe through cat to make it more obvious |
| 10:06.06 | Jin^eLD | well I have a log of the whole build |
| 10:06.09 | Jin^eLD | so I can look stuff up |
| 10:06.12 | Jin^eLD | its a nightly-autobuilder |
| 10:06.54 | Jin^eLD | it builds every night, same distro, machine A, B |
| 10:06.58 | Jin^eLD | machine A failed tonight |
| 10:06.59 | bluelightning | ok |
| 10:10.14 | Jin^eLD | Running setscene task 1658 of 1758 ( |
| 10:10.21 | Jin^eLD | so it does run setscene for the failed package |
| 10:10.30 | Jin^eLD | and writes a new ipk |
| 10:10.38 | Jin^eLD | although there were no changes |
| 10:10.51 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 10:10.57 | Jin^eLD | the same happens with a number of other packages that also did not have any changes |
| 10:12.18 | Jin^eLD | what does setscene do btw? |
| 10:12.30 | bluelightning | it's restoring the output from sstate for the task |
| 10:12.46 | Jin^eLD | ah found it in the bitbake manual, will read up on it |
| 10:12.59 | Jin^eLD | but.. what now? we know its running setscene, I understand it was not supposed to do that? |
| 10:13.20 | Jin^eLD | or actually it was ok, from what I understand in the manual |
| 10:13.24 | Jin^eLD | it handles prebuilt artifacts |
| 10:13.37 | bluelightning | in this context it just means what's currently in the sysroot doesn't match with what the metadata says it should be, so it knows it needs to do something - if it successfully runs the setscene task that means it can restore it from sstate; if it hadn't been able to do that it would have rebuilt it instead |
| 10:13.43 | bluelightning | does this allarch recipe have any dependencies? |
| 10:15.12 | Jin^eLD | it only has an RDEPENDS on something in the rootfs but no DEPENDS |
| 10:15.16 | Jin^eLD | https://git.digitalstrom.org/dss-oe/dss-oe/blob/master/yocto/dS/meta-digitalstrom-devel/recipes-digitalstrom/dss11-help/dss11-installation-manual-tr-tr_0.9.bb |
| 10:15.19 | Jin^eLD | that's the reciep btw |
| 10:15.24 | Jin^eLD | really a simple one |
| 10:15.47 | Jin^eLD | and I have about 5 which are more or less the same for the other languages, but only this one fails consistently |
| 10:16.32 | Jin^eLD | now I notice I should fix the description :) but that's not the source of the error anyway |
| 10:17.23 | Jin^eLD | btw I can see that it does write ipk's for all the other manual recipes as well, which also have not changed |
| 10:19.48 | Jin^eLD | here's also a log with the grep for this package to see what it is going through https://pastebin.mozilla.org/8850409 |
| 10:20.33 | Jin^eLD | btw do we have a ticket for it? it may make sense to attach all the stuff there too |
| 10:27.22 | *** join/#oe jackmitchell (~Thunderbi@109.224.219.180) |
| 10:33.36 | *** join/#oe ldnunes (~ldnunes_@177.194.195.186) |
| 10:35.10 | Jin^eLD | bluelightning: could not find a ticket, I'll submit one and attach my logs |
| 10:36.22 | bluelightning | when you say ticket, where do you mean? |
| 10:36.45 | Jin^eLD | I mean an issue on bugzilla |
| 10:36.48 | Jin^eLD | sorry :) |
| 10:36.53 | bluelightning | whose though? |
| 10:37.08 | Jin^eLD | used to call it tickets (working with redmine a lot) |
| 10:37.35 | Jin^eLD | bluelightning: what do you mean "whose"? which component? |
| 10:38.25 | Jin^eLD | i was referring to bugzilla.yoctoproject.org |
| 10:38.31 | bluelightning | right, that was my question |
| 10:38.37 | Jin^eLD | bitbake? |
| 10:38.46 | Jin^eLD | well, we see that packages that had no changes get rebuilt, right? |
| 10:38.55 | Jin^eLD | which component is responsible for that? imho bitbake? |
| 10:39.05 | Jin^eLD | help me out here :) |
| 10:39.09 | bluelightning | it's a little more complicated than that |
| 10:39.17 | bluelightning | file it against OE-Core |
| 10:39.23 | Jin^eLD | hm ok |
| 10:39.34 | bluelightning | but the question will be have you run bitbake-diffsigs against the siginfo file for the tasks that get re-executed |
| 10:40.15 | Jin^eLD | I was asking what parameters do I give the diffsig thingie? it wants recipe (clear) and "taskname" - what do I use there? |
| 10:40.28 | Jin^eLD | aha.. "against the sigfinfo file.." |
| 10:40.29 | bluelightning | ok, so let's wind back a bit |
| 10:40.36 | Jin^eLD | ok.. |
| 10:40.53 | bluelightning | you want to find out which task is the first task that's re-running... that is where there is some difference that we want to compare |
| 10:41.10 | Jin^eLD | ok... |
| 10:42.17 | Jin^eLD | and I do that how exactly? |
| 10:42.19 | bluelightning | one way to do that - go into your build directory, bitbake -c cleansstate the recipe, build it, change to the other machine, cleansstate it again, then build it again piping through cat and noting the first task that re-runs |
| 10:42.34 | Jin^eLD | ok let me try that |
| 10:42.43 | bluelightning | actually hrm, that's not going to work |
| 10:42.49 | Jin^eLD | mhm |
| 10:43.05 | bluelightning | do both cleansstates first, so that means two machine changes in the process |
| 10:43.52 | bluelightning | so cleansstate the recipe, change machine, cleansstate again, then build it, then change machine, build it again and note the first task that executes |
| 10:47.16 | Jin^eLD | https://pastebin.mozilla.org/8850411 |
| 10:47.28 | Jin^eLD | so thats the log of the last step, "change machine, build it again" |
| 10:48.07 | Jin^eLD | do_populate_sysroot_setscene seems to be the first one? |
| 10:49.28 | bluelightning | do_package_write_ipk is the first real task |
| 10:49.50 | Jin^eLD | oh ok... but... why is it writing an ipk for an allarch package that was already built? |
| 10:50.11 | bluelightning | I don't know, that's what we're attempting to find out |
| 10:50.16 | Jin^eLD | indeed :) |
| 10:50.36 | bluelightning | FWIW I do wonder if it really makes sense for a package like this to have a dependency on lighttpd |
| 10:50.40 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 10:51.06 | Jin^eLD | bluelightning: its an RDEPENDS... and since it supplies an html page the idea was to make sure the webserver that's configured to serve it is also around... |
| 10:51.21 | Jin^eLD | but I could also drop it in this case because the webserver is anyway included elsewhere too |
| 10:51.24 | bluelightning | don't you have other means to ensure that's in the image? |
| 10:51.26 | bluelightning | right |
| 10:51.54 | Jin^eLD | but theoretically speaking there shouldn't be anything wrong with having the RDEPENDS there? |
| 10:52.12 | bluelightning | thinking about it that may be causing this; it may be triggering the allarch recipe to actually be architecture-specific |
| 10:52.22 | Jin^eLD | worst case its redundant but should not hurt, no? |
| 10:52.30 | Jin^eLD | aha hmm |
| 10:52.41 | bluelightning | take it out and see if it changes the behaviour |
| 10:52.44 | bluelightning | I suspect it will |
| 10:52.58 | Jin^eLD | ok so cleansstates again, take it out, rebuild? |
| 10:55.09 | Jin^eLD | ok lets see.. |
| 10:55.59 | Jin^eLD | thats the new log https://pastebin.mozilla.org/8850412 |
| 10:56.38 | Jin^eLD | indeed a lot shorter |
| 10:57.01 | Jin^eLD | the write_ipk is there but the qa is gone? |
| 10:57.19 | bluelightning | I think that's probably ok... since the sysroot will actually be different for the different machine (since the sysroot is per-machine), it's correct that it'd need to populate it for the second machine, but it's doing it entirely from sstate |
| 10:57.36 | bluelightning | no real tasks executed |
| 10:58.12 | bluelightning | so, I think we've fixed the underlying cause, but there are a couple of issues here |
| 10:58.45 | bluelightning | 1) you were sometimes getting an error from opkg triggered by this, that should never have happened |
| 10:59.15 | bluelightning | 2) it seems like there ought to be some kind of warning in this case; we've talked about it before though and I'm not sure there's clear agreement on how to handle that |
| 10:59.48 | Jin^eLD | is it actually OK that RDEPENDS triggers such a rebuild or is it a bug? |
| 11:00.22 | Jin^eLD | especially where neither the recipe itsself nor the one listed in RDEPENDS have changed, stayed the same for both machines |
| 11:03.36 | bluelightning | I'm not sure but I feel like either it shouldn't or there should be a warning that it has |
| 11:04.11 | bluelightning | you say that lighttpd hasn't changed, I think you'll find it has |
| 11:04.35 | bluelightning | what is the architecture of the two machines? |
| 11:05.17 | Jin^eLD | arm5 and imx6 |
| 11:05.28 | bluelightning | right, so not the same |
| 11:05.34 | Jin^eLD | yep, not the same |
| 11:05.40 | bluelightning | so lighttpd has been built differently for each one |
| 11:05.44 | bluelightning | that's the trigger |
| 11:05.44 | Jin^eLD | yes |
| 11:05.55 | Jin^eLD | but why is it a trigger for RDEPENDS? |
| 11:06.08 | Jin^eLD | isn't that only interesting for a runtime installation? |
| 11:07.37 | bluelightning | not sure, but I believe the behaviour is deliberate, whether it's correct or desirable in all situations is a different question |
| 11:08.51 | Jin^eLD | so what do you suggest now? I mean, sure, I can work around by removing the RDEPENDS and that's what I will do in the short term, and I guess I would not mind the rebuild if not the opkg error |
| 11:09.15 | Jin^eLD | but hearing that I'm not the first one who had these problems it'd be cool to find a more permanent solution |
| 11:09.33 | bluelightning | well the opkg issue definitely needs fixing |
| 11:09.43 | bluelightning | a solid reproducer would help a lot there |
| 11:10.25 | Jin^eLD | I think we just got rid of the solid reproducer :) |
| 11:10.31 | bluelightning | for the other one, we need to have a wider discussion, figure out the desired behaviour, and document it |
| 11:10.35 | Jin^eLD | but I can activate it again of course |
| 11:10.45 | bluelightning | naturally, you'd need to ;) |
| 11:11.17 | Jin^eLD | so should I file a bug or just drop a mail with our findings to the ml? |
| 11:11.44 | bluelightning | we need a bug for the opkg issue |
| 11:12.08 | Jin^eLD | ok so I'll try to summarize our findings there |
| 11:12.24 | bluelightning | well, let's not conflate the two things, I don't want them getting tangled up |
| 11:12.31 | bluelightning | even if they are related |
| 11:12.51 | bluelightning | file a bug for the opkg issue and start a thread on the mailing list for the other one, how does that sound? |
| 11:13.33 | bluelightning | brb |
| 11:13.57 | Jin^eLD | ok, deal |
| 11:14.03 | Jin^eLD | will do that right after lunch |
| 11:14.05 | Jin^eLD | brb |
| 11:30.22 | *** join/#oe RagBal (~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl) |
| 11:31.11 | *** join/#oe Rootert (~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl) |
| 11:33.36 | *** join/#oe belen (Adium@nat/intel/x-wlqregyybchckuig) |
| 11:39.51 | otavio | nerdboy: hello? |
| 11:42.06 | Jin^eLD | bluelightning: btw now that I removed the RDEPENDS on that package I simply started to get the opkg error eslewhere at a different place, I guess on something that RDEPENDS on python.. which is not in the image by default so removing the RDEPENDS there would not be that nice... |
| 12:06.11 | bluelightning | Jin^eLD: I guess we need to properly solve the opkg issue then |
| 12:07.11 | Jin^eLD | ok let me first enter the issues/post to the ml as we discussed and maybe if you have a little time we could have another look since it seems to be nicely reproducible on my setup? |
| 12:07.37 | Jin^eLD | unless you prefer to have another look before me submitting an issue :> |
| 12:08.31 | *** join/#oe tsramos (~tsramos@134.134.139.70) |
| 12:09.08 | bluelightning | Jin^eLD: I guess we can do, what's the new situation? |
| 12:11.31 | Jin^eLD | bluelightning: well, not really "new", its again an allarch recipe that RDEPENDS on some stuff |
| 12:11.49 | Jin^eLD | and produces the same md5sum mismatch error message with opkg upon do_rootfs |
| 12:12.09 | Jin^eLD | so the problem only shifted to another recipe after I removed the RDEPENDS in the previous one |
| 12:16.07 | bluelightning | well the only real workaround available is to make the recipe not allarch |
| 12:16.13 | bluelightning | at the moment anyway |
| 12:16.55 | Jin^eLD | switching from allarch to machine specific and back also poses issues at times |
| 12:17.23 | Jin^eLD | I'd rather look at the opkg problem while I can reproduce it, but I guess I need a bit of guidance since I am not that well familiar with the iternals |
| 12:18.15 | bluelightning | I'm guessing it's not machine-specific, but arch-specific in this case |
| 12:18.23 | bluelightning | but yes |
| 12:20.47 | Jin^eLD | I'm poking around in the workdir but not yet sure what to look for |
| 12:21.19 | Jin^eLD | probably I should compare the packages.gz md5sums with the actual package md5sum |
| 12:21.33 | Jin^eLD | usually this error happens (at least on live systems) when the package-index is out of date |
| 12:22.04 | bluelightning | maybe for some reason the package indexing code thinks the package was not updated when it actually was |
| 12:22.07 | *** join/#oe ant_work (~ant__@host202-80-dynamic.180-80-r.retail.telecomitalia.it) |
| 12:22.14 | bluelightning | and thus it doesn't update the md5sum |
| 12:22.19 | bluelightning | (a guess ...) |
| 12:22.27 | Jin^eLD | not a bad one actually, would make sense |
| 12:22.54 | Jin^eLD | could you point me to the code that does the indexing when the rootfs is done? |
| 12:23.58 | bluelightning | well it's before building the rootfs, not afterwards, but hang on |
| 12:24.39 | Jin^eLD | yes I did not express myself well enough, I meant "when the rootfs is being generated" |
| 12:24.50 | *** join/#oe tsramos (tsramos@nat/intel/x-laatausjjmbjzjgx) |
| 12:25.09 | Jin^eLD | packages.gz indeed has a different md5sum, not the one of the package, so index not up to date |
| 12:25.32 | bluelightning | Jin^eLD: see OpkgIndexer in meta/lib/oeqa/utils/qemurunner.py |
| 12:27.39 | Jin^eLD | OpkgIndexer? grep does not return anything on that in meta/lib/oeqa/utils/ |
| 12:28.05 | Jin^eLD | and I do not find anything opkg related in qemurunner.py ? |
| 12:28.08 | Jin^eLD | am I missing something? |
| 12:28.31 | bluelightning | ah sorry I pasted completely the wrong path |
| 12:28.37 | bluelightning | meta/lib/oe/package_manager.py: |
| 12:28.42 | Jin^eLD | :) |
| 12:32.02 | Jin^eLD | I do not see who calls that in do_rootfs |
| 12:32.34 | Jin^eLD | generate_index_files() is only called from package-index.bb |
| 12:32.43 | Jin^eLD | I do not yet see how that plays together with do_rootfs |
| 12:34.06 | Jin^eLD | I do not see it calling package-index either |
| 12:34.16 | Jin^eLD | but I guess I do not fully understand the whole process yet |
| 12:34.58 | Jin^eLD | do_rootfs() is a python function that calls create_manifest(d), create_rootfs(d) and create_image(d) |
| 12:35.21 | Jin^eLD | but none of those seems to be calling generate_index_files()? |
| 12:35.21 | bluelightning | Jin^eLD: there are calls to write_index() in meta/lib/oe/rootfs.py, that's on the package manager class, which calls through to the indexer |
| 12:35.43 | Jin^eLD | ok found it |
| 12:36.58 | Jin^eLD | I thought it would go via generate_index_files but write_index is called directly |
| 12:44.22 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 12:50.07 | Jin^eLD | bluelightning: to be honest I'm a bit lost there |
| 12:50.33 | Jin^eLD | does it create an index command for each file that needs to be indexed? |
| 12:51.23 | Jin^eLD | hm no, it indexes the whole directory |
| 12:51.26 | bluelightning | right |
| 12:51.34 | bluelightning | if there's a problem it's likely in opkg-make-index |
| 12:52.15 | Jin^eLD | it creates a list for each arch with a directory per arch, so its indexing directories, not single packages |
| 12:52.28 | Jin^eLD | now what I could check if it tries to index the allarch at all |
| 12:52.30 | Jin^eLD | or if it skips it |
| 12:53.14 | Jin^eLD | bb.note expects strings and print is not visible, is there a utility function to print python objects? |
| 12:53.21 | bluelightning | opkg-make-index comes from the opkg-utils recipe (its -native variant, in this instance) |
| 12:53.46 | bluelightning | just do: "%s" % obj |
| 12:53.47 | Jin^eLD | I first want to check if it attempts to update the index for the allarch directory at all |
| 12:53.56 | Jin^eLD | it tole me its not a string |
| 12:54.00 | Jin^eLD | *told |
| 12:54.03 | bluelightning | str() it then ;) |
| 12:54.05 | Jin^eLD | I wanted to print the list |
| 12:54.09 | Jin^eLD | ah, did not htink of it :) |
| 12:54.25 | bluelightning | that may not help though |
| 12:54.49 | bluelightning | you might need to actually poke into the attributes of the object and print those |
| 12:57.23 | Jin^eLD | allarch is there though |
| 12:57.25 | Jin^eLD | '/oe/dss-oe/poky-devel-build/build/sysroots/x86_64-linux/usr/bin/opkg-make-index -r /oe/dss-oe/poky-devel-build/build/deploy/ipk/all/Packages -p /oe/dss-oe/poky-devel-build/build/deploy/ipk/all/Packages -m /oe/dss-oe/poky-devel-build/build/deploy/ipk/all' |
| 12:57.57 | bluelightning | right, it's more likely that opkg-make-index itself is skipping the package |
| 12:58.38 | Jin^eLD | ok I'll focus on that one |
| 13:07.24 | *** join/#oe ensc|w (~ensc@fedora/ensc) |
| 13:09.59 | Jin^eLD | hmm somehow the printouts made in opkg-make-index do not make it to my console |
| 13:16.14 | Jin^eLD | worked around it, still debugging |
| 13:18.16 | Jin^eLD | and well, actually I can call it directly :) |
| 13:19.04 | *** join/#oe NileshKokane (uid116340@gateway/web/irccloud.com/x-ilnscfzxiadpnijv) |
| 13:19.08 | *** join/#oe Nilesh_ (uid116340@gateway/web/irccloud.com/x-hxfimbfrcdzjsbzv) |
| 13:24.58 | *** join/#oe AndersD (~anders@213-64-219-84-no126.business.telia.com) |
| 13:25.34 | *** join/#oe darkschneider (~gab@93-32-59-44.ip32.fastwebnet.it) |
| 13:34.24 | Jin^eLD | bluelightning: ok I think I have something |
| 13:34.25 | Jin^eLD | if filename in pkgsStamps and int(fnameStat.st_mtime) == pkgsStamps[filename]: |
| 13:34.48 | Jin^eLD | this is true for my package, so it does not get re-calculated |
| 13:34.51 | Jin^eLD | and keeps the old md5 |
| 13:35.05 | bluelightning | hmm, so why doesn't the mtime change? |
| 13:35.13 | Jin^eLD | if I skip this if then the packages index is correct, but then I force everything to get recalculated |
| 13:35.28 | bluelightning | or maybe the mtime actually gets updated in the dict before that code runs? |
| 13:35.37 | Jin^eLD | good question |
| 13:35.56 | Jin^eLD | hmmm |
| 13:35.59 | Jin^eLD | but now I ran it outside OE |
| 13:36.10 | Jin^eLD | because I otherwise had troubles seeing the error messages |
| 13:36.27 | Jin^eLD | however it kept the wrong index until I hacked out the if |
| 13:37.17 | Jin^eLD | ok let me re-reproduce it and then add some more debugigng to the pkgsStamps part |
| 13:37.47 | *** join/#oe ntl (~ntl@99-127-51-4.lightspeed.austtx.sbcglobal.net) |
| 13:47.37 | *** part/#oe Tarnyko (~Administr@46.18.96.42) |
| 13:47.49 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 13:49.07 | *** join/#oe ldnunes_ (~ldnunes_@177.100.174.62) |
| 13:52.26 | Jin^eLD | bluelightning: damn, now I "lost" it, it did build :( |
| 13:58.01 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 14:01.29 | *** join/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 14:01.30 | *** part/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 14:26.15 | *** join/#oe infobot (ibot@69-58-76-73.ut.vivintwireless.net) |
| 14:26.15 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel |
| 14:26.37 | Jin^eLD | bluelightning: I "lost" the reproducibility for now, I guess I will continued debugging when it fails next time, but at least I now know where to continue |
| 14:26.40 | Jin^eLD | thanks a lot for the help |
| 14:27.15 | Jin^eLD | I'll drop a mail regarding RDEPENDS that triggers a rebuild |
| 14:27.20 | Jin^eLD | not sure about the issue in bugzilla though |
| 14:30.39 | bluelightning | if you could file the bug anyway, cc alejandro castillo and note where you got to with the debugging |
| 14:31.15 | *** part/#oe belen (Adium@nat/intel/x-wlqregyybchckuig) |
| 14:31.24 | *** join/#oe belen (Adium@nat/intel/x-wlqregyybchckuig) |
| 14:31.41 | Jin^eLD | ok |
| 14:31.43 | Jin^eLD | vs oe-core? |
| 14:31.50 | Jin^eLD | or what part is the opkg-utils? |
| 14:32.05 | Jin^eLD | <PROTECTED> |
| 14:33.15 | Jin^eLD | yes, devtolls/toolchain |
| 14:33.16 | Jin^eLD | got it |
| 14:49.04 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 14:50.48 | *** join/#oe adelcast1 (~adelcast@130.164.62.82) |
| 14:52.32 | Jin^eLD | bluelightning: #8578 |
| 14:52.54 | *** join/#oe adelcast1 (~adelcast@130.164.62.82) |
| 14:57.05 | *** join/#oe tsramos_ (tsramos@nat/intel/x-crxvjrivpludozjk) |
| 14:59.36 | *** join/#oe berton (~fabio@201.22.227.56) |
| 14:59.44 | *** join/#oe belen (Adium@nat/intel/x-swbqkgxqailyvrua) |
| 15:02.49 | *** join/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 15:02.54 | *** part/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 15:20.21 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 15:33.25 | *** join/#oe Tarnyko (~Administr@ARennes-655-1-12-240.w109-218.abo.wanadoo.fr) |
| 15:35.00 | *** join/#oe tsramos (~tsramos@192.55.54.43) |
| 15:37.10 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 15:39.29 | *** join/#oe ant_work (~ant__@host202-80-dynamic.180-80-r.retail.telecomitalia.it) |
| 16:24.06 | *** join/#oe stephano (~stephano@74-92-165-193-Oregon.hfc.comcastbusiness.net) |
| 16:25.16 | *** join/#oe Nilesh_ (uid116340@gateway/web/irccloud.com/x-iagldapblbklnwpg) |
| 16:25.18 | *** join/#oe NileshKokane (uid116340@gateway/web/irccloud.com/x-wtowwxnyhjuzbujl) |
| 16:37.02 | *** join/#oe ldnunes_ (~ldnunes_@177.100.174.62) |
| 16:50.35 | *** join/#oe KNERD (~KNERD@netservisity.com) |
| 16:50.57 | *** join/#oe nerdboy (~sarnold@gatekeeper.gentoogeek.org) |
| 16:51.18 | *** join/#oe nerdboy (~sarnold@gentoo/developer/nerdboy) |
| 17:06.54 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 17:18.04 | mckoan|away | e |
| 17:39.49 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 17:42.06 | *** join/#oe kristoffer (~kristoffe@ua-83-227-162-207.cust.bredbandsbolaget.se) |
| 17:52.12 | nerdboy | buying a vowel? |
| 18:01.05 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 18:10.04 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 18:12.29 | *** join/#oe Crofton (~balister@207-114-172-147.static.twtelecom.net) |
| 18:28.12 | *** join/#oe stephano (~stephano@74-92-165-193-Oregon.hfc.comcastbusiness.net) |
| 19:03.28 | *** join/#oe mvader (~mvader@195-241-165-208.ip.open.net) |
| 19:05.22 | mvader | hi, anyone know how to find the machine name on the target? (runtime). I have a few applications that need to behave a bit different, depending on the machine they are running on, and wanted to simply add MACHINE To the default env, by modifying /etc/profile |
| 19:09.18 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 19:24.13 | *** join/#oe fischerm (~mfischer@207-114-172-147.static.twtelecom.net) |
| 19:26.48 | stephano | mvader: you can create a bbappend to the "base-files" recipe and in your bbappend use the ${MACHINE} variable in a case statement (or something similar). |
| 19:27.00 | fischerm | hi, I'm running into trouble with a patch that is supposed to create a file with executable permissions, that will be run as part of the boot process (zynq boot.bin generation, on top of mainline u-boot) |
| 19:27.13 | fischerm | http://pastebin.com/qrngjKcU |
| 19:27.35 | fischerm | I double checked the patch (create mode is 755) |
| 19:27.36 | *** join/#oe awozniak (~awozniak@71-93-61-178.static.snlo.ca.charter.com) |
| 19:27.48 | fischerm | am I doing something fundamentally wrong here? |
| 19:28.39 | mvader | stephano: thanks, I'll give that a try |
| 19:29.42 | Crofton | fischerm, you have a do*_append to run ./tools/zynq-boot-bin.py |
| 19:30.06 | Crofton | you could "python ./tools/zynq-boot-bin.py" |
| 19:30.11 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 19:30.15 | fischerm | Crofton: so the thing is, if the patches are in tree |
| 19:30.20 | fischerm | Crofton: it works as expected |
| 19:30.45 | fischerm | Crofton: if they're part of the SRC_URI ones they end up non executable |
| 19:31.34 | Crofton | oh crap, I forget zediii only hangs out in #yocto |
| 19:31.40 | Crofton | curses |
| 19:32.17 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 19:33.11 | *** join/#oe t0mmy (~tprrt@ram31-2-82-228-88-46.fbx.proxad.net) |
| 19:55.57 | *** join/#oe belen1 (Adium@nat/intel/x-mmnlckwgudpcdnoh) |
| 19:56.31 | *** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net) |
| 20:21.24 | *** join/#oe madisox (~madison@12.30.244.9) |
| 20:22.55 | *** part/#oe madisox (~madison@12.30.244.9) |
| 20:26.03 | *** join/#oe Meuuh (~cmassiot@lea.openheadend.tv) |
| 20:30.35 | *** join/#oe halstead_ (~halstead@drupal.org/user/301087/view) |
| 20:53.41 | *** join/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 20:53.44 | *** part/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 21:14.01 | *** join/#oe mvader (~mvader@195-241-165-208.ip.open.net) |
| 21:19.51 | *** join/#oe t0mmy (~tprrt@ram31-2-82-228-88-46.fbx.proxad.net) |
| 21:25.33 | *** join/#oe madisox1 (~madison@12.30.244.5) |
| 21:26.05 | *** part/#oe madisox1 (~madison@12.30.244.5) |
| 21:33.23 | *** join/#oe bluelightning (~paul@ip5f5ae69b.dynamic.kabel-deutschland.de) |
| 21:33.34 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 21:48.46 | *** join/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 21:48.49 | *** part/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 21:51.00 | *** join/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 21:51.02 | *** part/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 22:03.56 | Crofton | F me |
| 22:04.07 | Crofton | llvm changed from .gz to .xz |
| 22:04.17 | Crofton | making SRC-URI in include file hard |
| 22:08.52 | fischerm | :) |
| 22:48.56 | *** join/#oe joseppc (~Josep@sestofw01.enea.se) |