I have created a set of pre-release source tarballs for Trinity 3.5.12. They are currently publishing to the mirror, and should be available within 48 hours from this link:
http://ppa2.quickbuild.pearsoncomputing.net/redirect.php?file=releases/3.5.1...
If no issues are found in the next four days, there is a very good chance these files will become the final release.
Please keep this information on this list for now; I am releasing the files early for testing purposes only, not for general consumption.
Thanks!
Tim
http://ppa2.quickbuild.pearsoncomputing.net/redirect.php?file=releases/3.5.1...
If no issues are found in the next four days, there is a very good chance these files will become the final release.
Redirect results in 404 error as of early afternoon. Probably not yet updated.
I see a few more additions in the SVN tree. At some point we need to declare a complete freeze except for fatal issues. Takes me 8 hours to build the core packages and a half dozen non-core. With each SVN change I have to rebuild to verify no build errors. I only have a dual core, not a cluster. :)
http://ppa2.quickbuild.pearsoncomputing.net/redirect.php?file=releases/3.5.1...
If no issues are found in the next four days, there is a very good chance these files will become the final release.
Redirect results in 404 error as of early afternoon. Probably not yet updated.
I see a few more additions in the SVN tree. At some point we need to declare a complete freeze except for fatal issues. Takes me 8 hours to build the core packages and a half dozen non-core. With each SVN change I have to rebuild to verify no build errors. I only have a dual core, not a cluster. :)
Out of curiosity, who here (if anyone) is not subscribed to the trinity-announce list? That is where announcements such as feature freeze, artwork freeze, pre-release freeze, etc. are posted.
As of 1:00PM CDT on September 27, 2010 a hard freeze is in effect in SVN. Only crash fixes will be accepted at this point, provided that the patch is relatively simple.
Tim
Out of curiosity, who here (if anyone) is not subscribed to the trinity-announce list? That is where announcements such as feature freeze, artwork freeze, pre-release freeze, etc. are posted.
I'm not. I'll join.
As of 1:00PM CDT on September 27, 2010 a hard freeze is in effect in SVN. Only crash fixes will be accepted at this point, provided that the patch is relatively simple.
Good!
http://ppa2.quickbuild.pearsoncomputing.net/redirect.php?file=releases/3.5.1...
Early evening here and get redirected to:
http://mirror.its.uidaho.edu/pub/trinity/releases/3.5.12/downloads.html
with a 404 page:
Not Found
The requested URL /pub/trinity/releases/3.5.12/downloads.html was not found on this server.
Even with a slow connection I would expect to see something there by now or at least a blank page, but not a 404.
http://ppa2.quickbuild.pearsoncomputing.net/redirect.php?file=releases/3.5.1...
Is this link working? I still receive a redirct to http://mirror.its.uidaho.edu/pub/trinity/releases/3.5.12/downloads.html and 404 error.
http://ppa2.quickbuild.pearsoncomputing.net/redirect.php?file=releases/3.5.1...
Is this link working? I still receive a redirct to http://mirror.its.uidaho.edu/pub/trinity/releases/3.5.12/downloads.html and 404 error.
The mirror is taking forever to sync up this time around. Probably because the transfer so far is > 6GB over my 0.5MB/s uplink.
Tim
The mirror is taking forever to sync up this time around. Probably because the transfer so far is > 6GB over my 0.5MB/s uplink.
Looks like the link is working. I realize this is a test point but some thoughts:
What is the monolithic tarball?
Perhaps file sizes should accompany each link to help people gauge download times?
Could there be a single download link for the traditional core kde packages?:
tqtinterface arts kdeaccessibility: kdeaddons kdeadmin kdeartwork kdebase kdebindings kdeedu kdegames kdegraphics kdelibs kdemultimedia kdenetwork kdepim kdesdk kdetoys kdeutils kdevelop kdewebdev
The mirror is taking forever to sync up this time around. Probably because the transfer so far is > 6GB over my 0.5MB/s uplink.
Looks like the link is working. I realize this is a test point but some thoughts:
What is the monolithic tarball?
Perhaps file sizes should accompany each link to help people gauge download times?
Could there be a single download link for the traditional core kde packages?:
tqtinterface arts kdeaccessibility: kdeaddons kdeadmin kdeartwork kdebase kdebindings kdeedu kdegames kdegraphics kdelibs kdemultimedia kdenetwork kdepim kdesdk kdetoys kdeutils kdevelop kdewebdev
Good suggestions! This is why the test tarballs (which I can now say for certain are NOT final) were published early, to get feedback from distribution packagers. ;-)
The monolithic tarball is the entire source tree provided in the original SVN archive structure. The complete tarball is a collection of all the smaller module tarballs in one file for easy downloading.
I suppose the traditional packages mentioned above could be provided in one more tarball. Of course, that means that everything else should go in another tarball, which brings up the question of whether or not the "complete" file should be retained as-is or split into two separate files, "core" and "extra".
Thoughts?
Tim
Good suggestions! This is why the test tarballs (which I can now say for certain are NOT final) were published early, to get feedback from distribution packagers. ;-)
Yes, I saw the recent security updates. I cleaned house here and downloaded the entire SVN tree after those updates. Everything compiled.
The monolithic tarball is the entire source tree provided in the original SVN archive structure.
Perhaps the link should read:
Complete core and non-core packages SVN source tree
The complete tarball is a collection of all the smaller module tarballs in one file for easy downloading.
Perhaps the link should read:
Complete non-core packages SVN source tree
I suppose the traditional packages mentioned above could be provided in one more tarball. Of course, that means that everything else should go in another tarball, which brings up the question of whether or not the "complete" file should be retained as-is or split into two separate files, "core" and "extra".
Variety provides end-users more choices. Many people do not have high-speed connections.
1. Provide one link to each individual package source tarball, just as you have right now.
2. Provide one link to one tar.bz2 file containing all traditional core package sources, which includes arts but also now includes tqtinterface.
3. Provide one link to one tar.bz2 for all non-core source tarballs.
4. Provide one link to the entire SVN source tree.
5. Provide one link to the SVN tree of the traditional core packages.
6. Provide one link to the SVN tree of all non-core packages.
I'm unsure about the latter three. As I discovered in my early efforts with this project, there is no way to sync a local SVN tree after downloading the tree as a tarball or ISO image. I had to delete that directory and then use svnadmin and svn co to sync my local tree. I wonder whether those SVN tree tarballs provide value or waste bandwidth?
Another note. I wonder about users' responses when they select a link at your web site and are redirected to some place at the University of Idaho. I think the link at your site should contain an informational message that the sources are stored at that location and the SVN tree is stored at your web site. Then people would know and won't wonder whether they were hijacked.
Hello,
I like those split packages. We (in Gentoo) are already splitting it into smaller pieces, so we welcome it. (until now, we had to unpack smaller apps from bigger tarballs, which was slow)
Of course, if it's not a problem, traditional packages should be also available (as long as it's clear they duplicate/are duplicated by the split packages and users won't download both)
Regards Ladislav Laska S pozdravem Ladislav Laska --- xmpp/jabber: ladislav.laska@jabber.cz
On Wed, Sep 29, 2010 at 11:14 PM, Darrell Anderson humanreadable@yahoo.com wrote:
Good suggestions! This is why the test tarballs (which I can now say for certain are NOT final) were published early, to get feedback from distribution packagers. ;-)
Yes, I saw the recent security updates. I cleaned house here and downloaded the entire SVN tree after those updates. Everything compiled.
The monolithic tarball is the entire source tree provided in the original SVN archive structure.
Perhaps the link should read:
Complete core and non-core packages SVN source tree
The complete tarball is a collection of all the smaller module tarballs in one file for easy downloading.
Perhaps the link should read:
Complete non-core packages SVN source tree
I suppose the traditional packages mentioned above could be provided in one more tarball. Of course, that means that everything else should go in another tarball, which brings up the question of whether or not the "complete" file should be retained as-is or split into two separate files, "core" and "extra".
Variety provides end-users more choices. Many people do not have high-speed connections.
Provide one link to each individual package source tarball, just as you have right now.
Provide one link to one tar.bz2 file containing all traditional core package sources, which includes arts but also now includes tqtinterface.
Provide one link to one tar.bz2 for all non-core source tarballs.
Provide one link to the entire SVN source tree.
Provide one link to the SVN tree of the traditional core packages.
Provide one link to the SVN tree of all non-core packages.
I'm unsure about the latter three. As I discovered in my early efforts with this project, there is no way to sync a local SVN tree after downloading the tree as a tarball or ISO image. I had to delete that directory and then use svnadmin and svn co to sync my local tree. I wonder whether those SVN tree tarballs provide value or waste bandwidth?
Another note. I wonder about users' responses when they select a link at your web site and are redirected to some place at the University of Idaho. I think the link at your site should contain an informational message that the sources are stored at that location and the SVN tree is stored at your web site. Then people would know and won't wonder whether they were hijacked.
Good suggestions! This is why the test tarballs (which I can now say for certain are NOT final) were published early, to get feedback from distribution packagers. ;-)
Yes, I saw the recent security updates. I cleaned house here and downloaded the entire SVN tree after those updates. Everything compiled.
The monolithic tarball is the entire source tree provided in the original SVN archive structure.
Perhaps the link should read:
Complete core and non-core packages SVN source tree
The complete tarball is a collection of all the smaller module tarballs in one file for easy downloading.
Perhaps the link should read:
Complete non-core packages SVN source tree
I suppose the traditional packages mentioned above could be provided in one more tarball. Of course, that means that everything else should go in another tarball, which brings up the question of whether or not the "complete" file should be retained as-is or split into two separate files, "core" and "extra".
Variety provides end-users more choices. Many people do not have high-speed connections.
- Provide one link to each individual package source tarball, just as you
have right now.
- Provide one link to one tar.bz2 file containing all traditional core
package sources, which includes arts but also now includes tqtinterface.
Provide one link to one tar.bz2 for all non-core source tarballs.
Provide one link to the entire SVN source tree.
Provide one link to the SVN tree of the traditional core packages.
Provide one link to the SVN tree of all non-core packages.
I'm unsure about the latter three. As I discovered in my early efforts with this project, there is no way to sync a local SVN tree after downloading the tree as a tarball or ISO image. I had to delete that directory and then use svnadmin and svn co to sync my local tree. I wonder whether those SVN tree tarballs provide value or waste bandwidth?
Another note. I wonder about users' responses when they select a link at your web site and are redirected to some place at the University of Idaho. I think the link at your site should contain an informational message that the sources are stored at that location and the SVN tree is stored at your web site. Then people would know and won't wonder whether they were hijacked.
Done.
The source files now published are the final 3.5.12 versions. Binary builds are catching up as I write this, and I have already filed the first bug targeted for 3.5.13 ;-).
Official release is in around 24 hours (late in the day on October 1, 2010), and will occur on schedule provided that no mirror sync glitches occur between now and then.
I don't know how you want Slackware to be mentioned in the release notes. Would it work to direct people to your site for the installation instructions, and then you can redirect them back to my site/the mirror for any downloads that might be needed? That would allow a few more days for you to finish building the packages based on the finalized sources.
Tim
Good suggestions! This is why the test tarballs (which I can now say for certain are NOT final) were published early, to get feedback from distribution packagers. ;-)
Yes, I saw the recent security updates. I cleaned house here and downloaded the entire SVN tree after those updates. Everything compiled.
The monolithic tarball is the entire source tree provided in the original SVN archive structure.
Perhaps the link should read:
Complete core and non-core packages SVN source tree
The complete tarball is a collection of all the smaller module tarballs in one file for easy downloading.
Perhaps the link should read:
Complete non-core packages SVN source tree
I suppose the traditional packages mentioned above could be provided in one more tarball. Of course, that means that everything else should go in another tarball, which brings up the question of whether or not the "complete" file should be retained as-is or split into two separate files, "core" and "extra".
Variety provides end-users more choices. Many people do not have high-speed connections.
- Provide one link to each individual package source tarball, just as
you have right now.
- Provide one link to one tar.bz2 file containing all traditional core
package sources, which includes arts but also now includes tqtinterface.
Provide one link to one tar.bz2 for all non-core source tarballs.
Provide one link to the entire SVN source tree.
Provide one link to the SVN tree of the traditional core packages.
Provide one link to the SVN tree of all non-core packages.
I'm unsure about the latter three. As I discovered in my early efforts with this project, there is no way to sync a local SVN tree after downloading the tree as a tarball or ISO image. I had to delete that directory and then use svnadmin and svn co to sync my local tree. I wonder whether those SVN tree tarballs provide value or waste bandwidth?
Another note. I wonder about users' responses when they select a link at your web site and are redirected to some place at the University of Idaho. I think the link at your site should contain an informational message that the sources are stored at that location and the SVN tree is stored at your web site. Then people would know and won't wonder whether they were hijacked.
Done.
The source files now published are the final 3.5.12 versions. Binary builds are catching up as I write this, and I have already filed the first bug targeted for 3.5.13 ;-).
Official release is in around 24 hours (late in the day on October 1, 2010), and will occur on schedule provided that no mirror sync glitches occur between now and then.
I don't know how you want Slackware to be mentioned in the release notes. Would it work to direct people to your site for the installation instructions, and then you can redirect them back to my site/the mirror for any downloads that might be needed? That would allow a few more days for you to finish building the packages based on the finalized sources.
Tim
You might want to hold off on firing off the build processes; I think I just sent a false alarm. No one here has tried logging in with a new test user; I just tried it and got two Trash icons.
This behavior was caused by one file that snuck through in kdebase. The commit will go out shortly, after I have ensured correct behavior. For now the release is still scheduled for late October 1, however the mirror sync schedule may force a miss on that deadline.
Sorry for the confusion!
Tim
Hmm. I did not get the memo.
My test run a day ago with test 3.5.12 tarballs went okay. I did not try to build all files but just a few.
Today I tried and the build scripts kept failing.
First thing I finally discover is the file compression is tar.gz and not tar.bz2. When did that change?
Second, the non-core packages all have "3.5.12" in the source tarball file name. Previously those packages used a local version.
arts: 1.5.10 koffice: 1.6.3 k3b: 1.0.5 etc.
Now all of them are 3.5.12.
Third, when the non-core tarballs unpack, they are in a subdirectory rather than just under the package name. For example, both tqtinterface and arts unpack to a parent directory named dependencies. Koffice, knemo, k3b, etc all unpack to a parent directory named applications. Yes, that matches SVN, but the tarballs don't need to match SVN. Downstream builders will not be expecting that. They will expect the unpacked tarball to be in its own directory of the same name.
My build process is broken.
Darrell
Hmm. I did not get the memo.
My test run a day ago with test 3.5.12 tarballs went okay. I did not try to build all files but just a few.
Today I tried and the build scripts kept failing.
First thing I finally discover is the file compression is tar.gz and not tar.bz2. When did that change?
It didn't; they were always tar.gz when I created them. bzip would take overnight to run; as it is gzip takes many hours. To me, the difference in compressed file size was not great enough to justify the performance hit from bzip.
Second, the non-core packages all have "3.5.12" in the source tarball file name. Previously those packages used a local version.
arts: 1.5.10 koffice: 1.6.3 k3b: 1.0.5 etc.
Now all of them are 3.5.12.
That is normal and will stay that way for all future releases, unless there is a good reason for not doing things this way.
Third, when the non-core tarballs unpack, they are in a subdirectory rather than just under the package name. For example, both tqtinterface and arts unpack to a parent directory named dependencies. Koffice, knemo, k3b, etc all unpack to a parent directory named applications. Yes, that matches SVN, but the tarballs don't need to match SVN. Downstream builders will not be expecting that. They will expect the unpacked tarball to be in its own directory of the same name.
This issue I can definitely fix.
Tim
First thing I finally discover is the file compression
is tar.gz and not
tar.bz2. When did that change?
It didn't; they were always tar.gz when I created them. bzip would take overnight to run; as it is gzip takes many hours. To me, the difference in compressed file size was not great enough to justify the performance hit from bzip.
My scripts were written for tar.bz2 and use wget to fetch tarballs if none are found locally. The other day I downloaded files. The script would have failed if the files were tar.gz. Something strange here.
Second, the non-core packages all have "3.5.12" in the
source tarball file
name. Previously those packages used a local version.
arts: 1.5.10 koffice: 1.6.3 k3b: 1.0.5 etc.
Now all of them are 3.5.12.
That is normal and will stay that way for all future releases, unless there is a good reason for not doing things this way.
Then I have to rewrite my scripts. This problem never arose while building from SVN. Thus, I never anticipated that change and is an example of why we need time to test downloading and building tarballs.
Third, when the non-core tarballs unpack, they are in
a subdirectory
rather than just under the package name. For example,
both tqtinterface
and arts unpack to a parent directory named
dependencies. Koffice, knemo,
k3b, etc all unpack to a parent directory named
applications. Yes, that
matches SVN, but the tarballs don't need to match SVN.
Downstream builders
will not be expecting that. They will expect the
unpacked tarball to be in
its own directory of the same name.
This issue I can definitely fix.
Thanks.
I can't blink my eyes and this stuff magically compiles. :) Compiling is an overnight process for me --- and that is if nothing breaks. I have yet to read about any physicist who has a working theory for bypassing time. :)
As we have seen many times, your process does not break because you remain with the Debian build process and inherited sources from Debian. Also, you have your way of doing things ("works for me!") and that works well for you, but needs to be tested if others are going to help support Trinity on non-Debian systems. Breakage takes time to fix with the other operating systems.
I presume you want to keep the October 1 release date, but I can't commit to any Ubuntu like schedule of "release --- ready or not". I prefer a "release when ready" schedule. I doubt waiting a few days is going to hurt anybody?
Done.
The source files now published are the final 3.5.12 versions. Binary builds are catching up as I write this, and I have already filed the first bug targeted for 3.5.13 ;-).
Official release is in around 24 hours (late in the day on October 1, 2010), and will occur on schedule provided that no mirror sync glitches occur between now and then.
I don't know how you want Slackware to be mentioned in the release notes. Would it work to direct people to your site for the installation instructions, and then you can redirect them back to my site/the mirror for any downloads that might be needed? That would allow a few more days for you to finish building the packages based on the finalized sources.
Is there a reason for the suddenly announced October 1 release date? Anything wrong with October 4 or 5?
I need to test building with the the official 3.5.12 tarballs. As the previous test batch files were not official I have not yet ran a full build of the links. Looks like another all-nighter for the computer.
Barring any unforeseen problems, I'll update my web page with the latest news and the current build scripts.
As agreed, I will post the final 3.5.12 Slackware 12.2 binary packages to someplace at my web site and notify you privately of the link. You then can download them to your site.
For your web site, I was thinking you could add a link just after the Ubuntu Maverick link. That link would be like the others and say "Installation instructions."
When people select that link they would find a link to my web site for build instructions. For people wanting only to download the binary packages, they probably should find both a link to the packages for manual downloading and and a URL for those who use the package manager.
Your site, you decide.
That time I warned several weeks ago about having little time is here. Thus, I'm hoping the dust settles between now and the weekend and we are done with 3.5.12 and I am done with 12.2 support. I am unlikely to get around to testing anything seriously again for a few months.
Done.
The source files now published are the final 3.5.12 versions. Binary builds are catching up as I write this, and I have already filed the first bug targeted for 3.5.13 ;-).
Official release is in around 24 hours (late in the day on October 1, 2010), and will occur on schedule provided that no mirror sync glitches occur between now and then.
I don't know how you want Slackware to be mentioned in the release notes. Would it work to direct people to your site for the installation instructions, and then you can redirect them back to my site/the mirror for any downloads that might be needed? That would allow a few more days for you to finish building the packages based on the finalized sources.
Is there a reason for the suddenly announced October 1 release date? Anything wrong with October 4 or 5?
It wasn't suddenly announced; for the past few weeks there has been a counter on the main page slowly ticking down to October 1st. Also, I believe I sent several notices on the announce list with the days remaining until release.
However, in hindsight, I should have sent an announcement clearly detailing the release deadlines. I will do that for 3.5.13.
I need to test building with the the official 3.5.12 tarballs. As the previous test batch files were not official I have not yet ran a full build of the links. Looks like another all-nighter for the computer.
Barring any unforeseen problems, I'll update my web page with the latest news and the current build scripts.
As agreed, I will post the final 3.5.12 Slackware 12.2 binary packages to someplace at my web site and notify you privately of the link. You then can download them to your site.
For your web site, I was thinking you could add a link just after the Ubuntu Maverick link. That link would be like the others and say "Installation instructions."
Sure; works for me.
When people select that link they would find a link to my web site for build instructions. For people wanting only to download the binary packages, they probably should find both a link to the packages for manual downloading and and a URL for those who use the package manager.
Your site, you decide.
That time I warned several weeks ago about having little time is here. Thus, I'm hoping the dust settles between now and the weekend and we are done with 3.5.12 and I am done with 12.2 support. I am unlikely to get around to testing anything seriously again for a few months.
OK! I am done with 3.5.12 as of now; the final tarballs (with the Trash fix included) will be syncing to the mirror overnight tonight. Late tomorrow I will update all the links on the website and send out the release announcement.
Can you send me the URL to the public page you would like the Slackware information link to point to?
Thanks!
Tim
Is there a reason for the suddenly announced October 1
release date?
Anything wrong with October 4 or 5?
It wasn't suddenly announced; for the past few weeks there has been a counter on the main page slowly ticking down to October 1st. Also, I believe I sent several notices on the announce list with the days remaining until release.
I signed up on the announcment list several days ago. Possibly then I missed those announcements. However, I see no counter. Only the words "Countdown to Trinity 3.5.12."
Is there a reason for the suddenly announced October 1
release date?
Anything wrong with October 4 or 5?
It wasn't suddenly announced; for the past few weeks there has been a counter on the main page slowly ticking down to October 1st. Also, I believe I sent several notices on the announce list with the days remaining until release.
I signed up on the announcment list several days ago. Possibly then I missed those announcements.
That's the reason--the announcements were sent a while ago.
However, I see no counter. Only the words "Countdown to Trinity 3.5.12."
I didn't think about those who don't have JavaScript enabled when I wrote that counter. I have now put a static countdown in noscript tags to resolve the problem.
I have also pushed release back until October 03, 2010. This is twofold; 1. Primarily, to allow the source mirror to sync up, as the uplink is being extra slow today 2. Secondarily, to allow you to get the Slackware builds ready without being overly rushed
In the future the Trinity team will need to decide on a release type and schedule. Fixed release dates are good from an end-user and consumer (i.e. various distributions) standpoint, and my opinion is that such dates should be able to be met provided sufficient organization/scheduling is provided in the future. However, if a good case is made for floating dates I would be willing to change it. Thoughts from other members on the list? ;-)
Thanks!
Tim
However, I see no counter. Only the words "Countdown to Trinity 3.5.12."
I didn't think about those who don't have JavaScript enabled when I wrote that counter. I have now put a static countdown in noscript tags to resolve the problem.
Good news!
Only now I cannot see anything in the left frame. All I see is this error message:
Not Found
The requested URL /trinity/links_main.html was not found on this server. Apache/2.2.14 (Ubuntu) Server at thor.starlink.edu Port 80
I have also pushed release back until October 03, 2010. This is twofold;
- Primarily, to allow the source mirror to sync up, as the
uplink is being extra slow today 2. Secondarily, to allow you to get the Slackware builds ready without being overly rushed
Good! My days are numbered!
In the future the Trinity team will need to decide on a release type and schedule. Fixed release dates are good from an end-user and consumer (i.e. various distributions) standpoint, and my opinion is that such dates should be able to be met provided sufficient organization/scheduling is provided in the future. However, if a good case is made for floating dates I would be willing to change it. Thoughts from other members on the list? ;-)
I am only advocating that release dates should be approximate and not rigidly followed. Setting a goal such as October 1 is fine, but if the actual release is October 3 or 4, then nobody loses. When things break they need to be repaired or the release gets bad reviews. I have lost count how many times I have seen that happen and the next day or even hours after release a patch is needed.
I also realize you are for the first time creating links and tarballs for non-Debian users. New territory that requires testing. More than likely these problems won't occur next release.
With that in mind, since your system produces nightly binaries, possibly consider posting nightly tarball snapshots too. That will provide a way to continually test the tarball links in real-time. Building from SVN would produce the same result, but tarballs provide an easy way to keep testing the tarball process. Also, many people like to build snapshot releases from tarballs and not SVN. Just a thought.
With that said, I am reporting a new FTBFS bug in kdelibs. I'll start a new thread.
-
Darrell Anderson -
Ladislav Laska -
Timothy Pearson