On Sat, 1 Sep 2012 16:23:01 +0900 Carsten Haitzler (The Rasterman) <[email protected]> wrote:
> On Sat, 1 Sep 2012 15:48:47 +1000 David Seikel <[email protected]> > said: > > > On Sat, 1 Sep 2012 12:54:00 +0900 Carsten Haitzler (The Rasterman) > > <[email protected]> wrote: > > > > > On Fri, 31 Aug 2012 22:23:25 +1000 David Seikel > > > <[email protected]> said: > > > > > > > On Fri, 31 Aug 2012 20:55:11 +0900 Carsten Haitzler (The > > > > Rasterman) <[email protected]> wrote: > > > > > > > > > On Fri, 31 Aug 2012 20:00:52 +1000 David Seikel > > > > > <[email protected]> said: > > > > > > > > > > > On Fri, 31 Aug 2012 18:42:32 +0900 Carsten Haitzler (The > > > > > > Rasterman) <[email protected]> wrote: > > > > > > > > > > > > > On Fri, 31 Aug 2012 19:31:20 +1000 David Seikel > > > > > > > <[email protected]> said: > > > > > > > > > > > > > > > On Fri, 31 Aug 2012 18:11:09 +0900 Carsten Haitzler (The > > > > > > > > Rasterman) <[email protected]> wrote: > > > > > > > > > > > > > > > > > On Fri, 31 Aug 2012 09:47:48 +0200 Vincent Torri > > > > > > > > > <[email protected]> said: > > > > > > > > > > > > > > > > > > > On Fri, Aug 31, 2012 at 9:33 AM, David Seikel > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > On Fri, 31 Aug 2012 16:00:24 +0900 Cedric BAIL > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > >> On Fri, Aug 31, 2012 at 3:44 PM, Vincent Torri > > > > > > > > > > >> <[email protected]> wrote: > > > > > > > > > > >> > On Fri, Aug 31, 2012 at 8:23 AM, David Seikel > > > > > > > > > > >> > <[email protected]> wrote: > > > > > > > > > > >> >> On Thu, 30 Aug 2012 23:45:13 +0200 Vincent > > > > > > > > > > >> >> Torri <[email protected]> wrote: > > > > > > > > > > >> >>> On Thu, Aug 30, 2012 at 7:42 PM, David Seikel > > > > > > > > > > >> >>> <[email protected]> wrote: > > > > > > > > > > >> >>> > Yay! First bug report from the released > > > > > > > > > > >> >>> > tarballs. Edited highlights - > > > > > > > > > > >> >>> > > > > > > > > > > > >> >>> > eina$ ./configure --disable-posix-threads > > > > > > > > > > >> >>> > > > > > > > > > > >> >>> funny because that option does not exist > > > > > > > > > > >> >>> anymore. Try ./configure --help > > > > > > > > > > >> >> > > > > > > > > > > >> >> > > > > > > > > > > >> >> ~/e17_svn/TEMP/eina-1.7.0$ ./configure --help > > > > > > > > > > >> > > > > > > > > > > >> >> It certainly does exist. This is in the > > > > > > > > > > >> >> released tarball - > > > > > > > > > > >> >> > > > > > > > > > > >> >> http://download.enlightenment.org/releases/eina-1.7.0.tar.bz2 > > > > > > > > > > >> > > > > > > > > > > > >> > then, there is something strange. As I did > > > > > > > > > > >> > remove that option, and before sending my > > > > > > > > > > >> > previous mail, i've checked that that option > > > > > > > > > > >> > is not available in my eina repo. > > > > > > > > > > >> > > > > > > > > > > >> I don't have it from svn either. > > > > > > > > > > > > > > > > > > > > > > So, something is wrong with the released tarball, > > > > > > > > > > > which is what I said in the beginning. > > > > > > > > > > > > > > > > > > > > indeed, problem is on raster's side : there are > > > > > > > > > > files that have been removed from svn, but raster > > > > > > > > > > still have them in his repo, it seems, and he > > > > > > > > > > packaged them > > > > > > > > > > > > > > > > > > i have the option here. if they were removed.... it > > > > > > > > > should have deleted my copies too... > > > > > > > > > > > > > > > > SVN is not so good at deleting stuff. Sometimes it's > > > > > > > > useful to just wipe it all and get a fresh copy from the > > > > > > > > repo. > > > > > > > > > > > > > > > > > hmm i guess we can just ignore this option then. > > > > > > > > > > > > > > > > Except that it's breaking the build of eet later, at > > > > > > > > least for me. The tarballs are broken and need to be > > > > > > > > fixed. Guess this was a BETA release after all. B-) > > > > > > > > > > > > > > > > I just went back to using the older release tarballs. > > > > > > > > > > > > > > they build perfectly for me. > > > > > > > > > > > > We already establish that you did not create the tarballs > > > > > > from a pristine environment, did you test build it in a > > > > > > dirty environment to? I build the entire embedded OS from > > > > > > scratch in qemu, from the released tarballs. Even the > > > > > > build tools are created pristinely. That's as pristine as > > > > > > you are gonna get. Except this time around, the tarballs > > > > > > are dirty. > > > > > > > > > > i did make distcheck - so yes. it passed distcheck. i build in > > > > > that env 5-10 times or more a day on 3-5 different machines. > > > > > > > > Well, the fact is that the released tarball is different from > > > > what was in SVN, as reported in this thread by at least three > > > > people. Looking at the contents of the tarball now it's obvious > > > > it has a bunch more m4 files than SVN. The tarball is also > > > > different from what's in the branch and tag versions in SVN. > > > > The tarball should be identical to the branched and tagged > > > > versions, minus the .svn cruft. > > > > > > > > "make distcheck" is different from "dowload tarballs into a > > > > clean environment and build them". Obviously "make distcheck" > > > > is also different from "clean checkout from the repo followed > > > > by make distcheck", and I think that's where things went wrong. > > > > > > > > Building from SVN in my usual environment works fine for me to, > > > > I did it a couple of times since I started this thread. > > > > Downloading those tarballs into a clean environment did not > > > > build. I build that clean environment from released tarballs > > > > as often as you build, and it works perfectly on the previous > > > > released tarballs. Fails badly on this release. Would not be > > > > so bad if it failed cleanly, but it fails badly. > > > > > > > > And by "clean and pristine environment" I mean it only has the > > > > dependencies and the build tools. > > > > > > > > In that pristine environment it fails to build, with or without > > > > the --disable-posix-threads option. If pthreads is a hard > > > > requirement now, then eina should properly detect that, and > > > > complain about it's lack. That's not happening. What actually > > > > happens is that eina claims to build properly, and then eet > > > > dies with a message that says the compiler you just used to > > > > compile eina with is broken. I looked into the log files and > > > > eet was testing the compiler with a test that needed pthread > > > > stuff in the eina library. That's not really a proper test if > > > > the compiler is working. So what happens is you get a crazy > > > > message that has nothing to do with the real problem. > > > > > > > > All those problems are likely due to the excess files, though > > > > there may be more wrong with the tarballs. > > > > > > do you know what make distcheck does? it generates a tarballs then > > > unpacks it THEN... it COMPILES the unpacked tarball contents. not > > > the svn tree. it passed that. it compiles here. > > > > Then you must have some dependency installed on your system that is > > not checked for properly that I do not have installed on my > > pristine system. Likely pthreads. That's the value of doing a test > > on a pristine system, and one that is cut down to be just enough to > > support EFL. > > > > > the RELEASED tarballs compiles. that's what discheck does - > > > ensures they compile. as opposed to dis which just makes the > > > tarball but doesn't test it. the question is why doesn't is > > > compile for YOU. why didn't you test the beta and alpha tarballs > > > and waited for release? the alpha and beta ones were produces the > > > exact same way with not a single complaint from anyone about > > > them. the beta tarballs have the same not-working > > > --disable-posix-threads thing. you claim the last release (and > > > that would have been beta) worked for you. why not this one? i'm > > > not doing anything until we know why exactly. > > > > By "last release" I meant the last stable tarball release, which for > > eina was 1.2.0, and the other EFL libraries on their various > > versions released at the same time. > > > > I've been busy with getting this embedded project delivered, not had > > time to test alpha and beta versions of 1.7.0. I was going to leave > > 1.7.0 for after delivery and test it for the next project, which is > > based in this current project. But there was an edje positioning > > bug on that previous stable release that is not in the SVN version > > I use on my work station. The client suddenly decided it was > > critical a few days ago, when he had seen that bug and not even > > mentioned it many times before. It's not really crucial, just > > makes it look a little better. And literally minutes after I told > > him that the bug will be solved in the next EFL release which I was > > expecting in the next few weeks, you released it. > > > > So it was worth trying it out quickly, just to prove it would > > actually solve the bug. Not actually compiling and failing with a > > mysterious message about the compiler being broken, which I did > > make some effort to try to track down, was a show stopper. So I've > > gone back to the previous stable release which includes eina 1.2.0 > > and the other EFL versions that was released at the same time. > > These and the released versions before that all worked fine. > > > > I've reported my findings here. Others have confirmed that some > > files that are not supposed to be there are there. These files are > > earlier in the m4 path and overriding files that are supposed to be > > there. That's why this 1.7.0 release is broken, you don't need me > > to poke at it further. I don't have time right now. The client > > sent me two SMS's while I slept, and one more plus a phone call > > while I was writing this email. I've not had breakfast or a shit > > yet, just woke up. > > > > So I'm sticking with the original plan, to deliver this embedded > > project based on released tarballs of eina 1.2.0 and friends, then > > leave testing 1.7.0 (or later if there's another release by then) > > for the next project. > > > > In summary, right now I don't have the time to care. You made this > > release, it's your job to have done things right in the first place, > > your job to have the time to care. I'll care about it later, when > > it's my job to care. Right now other things are higher priority > > for me and there's not enough hours in the day. So no point > > waiting for me, I've done all I can to help. I'll stick with the > > previous eina 1.2.0 release for delivering this current project. > > > > Would it kill you to do a fresh SVN checkout and turn that into a > > proper 1.7.1 release now? Coz 1.7.0 is broken, every one else in > > this thread agrees but you. It just happens to compile fine in > > most cases, but it's still broken in the pristine environment > > case. It's still broken full stop. Extra files that where deleted > > from SVN but stuck around on your system, that are earlier in the > > path than the proper files, and made it into the release coz you > > did not make sure your system is clean, that's BROKEN. That it > > just happens to work often is not important. It's broken and easy > > to fix. > > i'm not doing it at the drop of a hat because it takes HOURS to do. > you really dont know how much work is invovled. and yes - i have > pthread support. as already suggested - dont disable threads. dont > build without. we're using them more and more and it is not a path > tested by us here. would it kill you to have a simple dependency like > pthreads which has been a baseline common thing supported in all the > embedded projects i've worked on. This particular embedded project is for a device that has legal requirements imposed by the local government on this class of device. Sure, governments pass crazy laws all the time, but the client has to abide by those laws, and thus I have to design the project to also abide by those laws. The project has to pass government appointed review labs, so everything I can do to make life easier for that lab will be better for the project overall. We don't know which particular corners being cut will or will not pass the labs inspection. This is also why I rely on released source code packages for the open source parts we use. With minimal patches. The sort of thing that the lab will have an easier time dealing with. One of the legal requirements is that the software does not include anything that is not absolutely needed for the legal functioning of the device. As laws go, this one is relatively sane. So one of my priorities was to cut out anything that's not needed. That's why I was so happy that 1.7.0 looked like it no longer needed fontconfig in my case. That's sort of mild compared to needing pthreads though. This project does not need pthreads, and was quite happy working with earlier versions of EFL where I could disable that. Some developers think that threading is a really hard thing, and I have no idea if the lab tech we will get to inspect our device is one of those people. So I'd much rather not have to include threading support when it is not really needed for the legal functioning of the device. It's definitely something that may actually kill the project. It may be the straw that broke the camels back. So, given that there is a chance that adding threading support might kill the project, and that 1.7.0 as shipped included an option to disable threading, you can see why I'm fretting over the fact that it's a broken option. What you don't seem to understand raster is that given the nature of the breakage, OTHER things might be broken to. As shipped, it's using the wrong files to build with for everyone, causing at least one problem for me. There might be other problems for other people. I do understand how much work it is to release a large open source project that includes multiple libraries and dependencies, coz I do that myself on another project. If I screwed up so badly that this sort of thing happened, I'd just bite the bullet, apologize, and do it over. There's good reasons why when I do these sorts of things, I do it on pristine environments and other such clean room tactics. You gotta remember that the tools we use may not have been written by programmers as wonderfully talented as ourselves, so don't rely on them to work perfectly. In this case, you relied on SVN to do the right thing, and it did not. This is not the first time I have seen SVN make this exact same fuckup, so I don't trust it to not fuck up in exactly the way it did for you. As it is, from my point of view, 1.7.0 is broken and not usable on this project. It works fine on my desktop, I'm using it now, but it's not gonna work on this or the next embedded project without some upstream work. Had upstream taken a bit more care putting the 1.7.0 release out, this would not have happened. If you had taken more care, then instead of thinking that 1.7.0 is just plain broken, I would instead be seriously considering if including pthreads was a worthwhile price to pay for being able to drop fontconfig. Dropping fontconfig might allow me to drop some of it's dependencies as well, so it might have been worth it. If the overall system complexity is smaller, the lab tech might forgive that he has to wrap his brain around pthreads. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
