In a.m. I only find builds based on obsolete source code without ant public interest, seems to be some private amusement. We should not host that. Someone should talk with the contributor and find a solution.
what ? What do you mean "in a.m." ? Is there a link to the builds that are a problem ?
URL leads to the dev-builds. I have been testing for 6 weeks and only 1 time I found a build that was more current than the pre-releases and the releases. I can't see any relation of these binaries (with what source might they have been created?) to LibO further development, so I believe "dev-builds" is the wrong place.
@Rainer : Surely, these are the builds from master, i.e. the 350 branch, in which case there will be some features that are different ? Alex
http://dev-builds.libreoffice.org/daily/Voreppe_Win32_Tinderbox/ ? I see that one is a 3-4 branch build-bot, i.e. apparently working and uploading up-to-date 3-4 branch builds, e.g. http://dev-builds.libreoffice.org/daily/Voreppe_Win32_Tinderbox/libreoffice-3-4/2011-07-12_00.13.34/ http://dev-builds.libreoffice.org/daily/Provo_Windows_x86_Tinderbox/master/ appears to be a master/HEAD windows build-bot that uploaded a new build last night, so that one appears to be working http://tinderbox.libreoffice.org/MASTER/status.html lists the buildbots, it doesn't seem to list the individual owners of the buildsbots in case one of them has an unexpected failure
Hm may be my Subject line was too short and so causes misunderstanding? Of course I do not want to remove ALL builds, only the useless ones. The link shows a folder with 3.4.1RC1 based binaries (whatever that might mean), what additionally might cause some license problems (where is the source?). From time to time I install those Voreppe builds, my knowledge concerning recognizing fix integration from git is too poor to find out whether those builds are up to date. but when I try to update my WIN LibO 3.4.1 i get message "A more current version is installed on your PC".
They don't cause any license problems. The source for them is available in the git repo. So lets put that aside. Those 3-4 builds should be up-to-date builds from the 3-4 branch, i.e. they should now include the extra fixes that have been added for the future 3.4.2 in addition to the released 3.4.1 stuff. The real problem here might be the "A more current version is installed on your PC" stuff, i.e. that a to-be 3.4.2 daily is still reported as the same minor version as an installed 3.4.1. Or is it a development 3.5 that's already installed ? caolanm->tor: should/does a recent post 3.4.1 release 3-4 branch windows build considered itself a later version that 3.4.1 ?
I *think* that the installer currently will always overwrite files even if the version numbers that it perceives are the same. (Note that the concept of version number of a file is slightly vague, it is not always clear what bloody version number is meant, the one in the file's version resource block, or the one in the MSI database... and there might even be a third possibility that I don't recall now.) But certainly I am no MSI expert, and I say that especially after spending way too much time on it in the years gone, time that I could have spent on something sensible instead, like picking my nose or making sandcastles. Fridrich might know for sure.
(In reply to comment #6) > The real problem here might be the "A more current version is installed on your > PC" stuff, i.e. [...] 3.5 that's already installed ? No, the latest and only LibO I had installed was WIN 3.4.1 release.
So, "Can't upgrade released windows 3.4.1 to will-be 3.4.2 dailies built after 3.4.1" ?
(In reply to comment #6) > The source for them is available in the git repo. So lets put that aside. @Caolán: It would be great if you could some hints on <http://wiki.documentfoundation.org/Testing_Daily_Builds#How_to_find_the_source> so that that information will be integrated. Catchwords are sufficient. And yes, I can't upgrade 3.4.1 to whatever xxxxx_LibO_3.4.1rc1_Win_x86_helppack_en-US.exe might be. May be I will find the time to try to upgrade to that version tonight. If someone tells me some "easy to find" fixes that have been integrated after 3.4.1 I can try to find the result in that build (of coures I am able to install those versions although I get the "You have more current ..." message).
a) re finding the source, that's why we put in the build-id into the master builds to make it easy. Its hard in 3-4, we would have to manually grovel around searching by date to find the matching 3-4 ones, but it can be done in a pinch. b) The "helppack" is the help documentation, its split out into a separate per-language installer. c) If someone tells me some "easy to find" fixes that have been integrated after 3.4.1 I can try to find the result in that build. Petr (Mladek) does a weekly post on the development, and other, lists with a title of "development summary" which includes a 3-4 list of bugs-fixed/backported, e.g. here's a pre-canned search that should put the most recent one at the top http://nabble.documentfoundation.org/template/NamlServlet.jtp?macro=search_page&node=1639786&query=development+summary&sort=date i.e. bugfixes-libreoffice-3-4-week-2011-26.log on libreoffice-3-4: fixes for LO-3.4.2 bug fix release lets change the title to the "can't upgrade to daily" issue, which is the blocker for good testing I guess
So, I bet this fixes the problem for the next set of dailies http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?h=libreoffice-3-4&id=66b5a6f985281f31d0ba654e539c1df7ae283b7a i.e. bump from 3.4.1 to 3.4.2. Lets ask pmladek if we can bump from 3.4.2 to 3.4.3 in 3-4 right after a 3-4-2 tag is created, so that dailies upgrade path make sense.
Petr's list is too general for my test, but I found out that fix for "Bug 38457 - CRASH WHEN MOVING A FIELD IN DATAPILOT" has been pushed to 3.4 branch 2011-06-29, so that it should work in my Branch-Daily 2011-08-08, and indeed, the crash has gone. So the fix initiated here really is a considerable improvement for the usability of the dailies. I will watch the result with the next daily build. Remaining problems - The name containing "RC1" does not invitate to test that with release on the PC, any idea how that can be changed? Remaining questions: - the unique build identifier currently only is in the master, or where can I find it?
"Petr's list is too general for my test", well there were only 8 or so bugs listed in "bugfixes-libreoffice-3-4-week-2011-26.log" for example, so that looks like a good level of coverage for testing to me. But I guess that's an aside now for this issue, really shouldn't be carrying this conversation on in a specific bug about a specific topic :-) re: "the unique build identifier currently only is in the master, or where can I find it?". Only master, and it's in help->about. Too "risky" for 3-4.
Hmm, we need to solve this together with Fridrich who takes care of the Windows daily builds. In each case, it will not help to bump the version once after the branch is created. It would allow to upgrade from the last release to the next daily build. Though, it will not allow to update between dailies. We would need to bump also the build number in solenv/inc/minor.mk but we need to be carefull because the size of the number is limited (less or equal to 9999 or so) AFAIK, people wanted to be able to install daily builds in parallel with the regular build. This might be solved by using the so called "DEV" build on the tinderboxes. In this case, the version should not be important. => I think that we need to switch tinder boxes to produce DEV builds and increment the build number with every build. Hint: The incrementation could be done by the script libreoffice/build/bin/lo-set-version. We should move it to boostrap/bin for this purpose.
I think it is wrong to mix in a "build number" which by definition, almost, is specific to a particular machine where builds are done, with a source doee version number, which corresponds to a given set of source code. The whole idea of a "build id" in OOo was silly, as (in OOo) "build id" was actually a number 1:1 corresponding to source code releases (milestones), as far as I know. From each such "build id" somebody could then produce a set of actual builds, with increasing quality as he add necessary patches or fixed build glitches. But still, all these builds had the same "build id". If we start having an official "build number" in version control (or otherwise centrally managed), we are going back to the OOo idea. The only way a centrally managed "build number" makes sense is if *every single line* of build script is stored in version control, with a full version that then includes that build number. (This is how RPM package versioning is supposed to work, right?) Or whatever... Anyway, I still think what I say in comment #7 is how it is supposed to be currently...
I modify Status due to facts
FYI: I also get message "more current version on your PC) when I try to install latest Master build "libreoffice-3-4~2011-06-28_14.53.54_LibO_3.4.1rc1_Win_x86_install_en-US_de_fr"
just reading cold cases, is this tracker still relevant? I mean perhaps there's still the problem but with 3.5 or 3.6 versions. If not, I'd put "WONT FIX"
yeah, lets close this