On Sat, 1 Sep 2012 18:07:16 +1000 David Seikel <[email protected]> wrote:
> 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. Or to put it another may, EFL 1.7.0 released tarballs "works", mostly, but it works entirely by accident, not by design. That's not a good solid base on which to release E17. Finally, after all these years, E17 is getting released, but the released libraries it's built on are broken and only work by accident. That's not gonna go down well, people will laugh at us even more than they do now. Yes, SVN works fine, but it's not SVN that you built the tarballs on, it's SVN plus some left over cruft that happened to stick around on your system. That cruft is gonna bite is in the arse, and not just me. Coz that cruft overrides the proper files that ARE designed to be the way it should work. God only knows what other errors slipped in with that cruft, or what other cruft also slipped in. -- 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
