27 Sep
2010
27 Sep
'10
9:30 a.m.
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.…
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
27 Sep
27 Sep
10:54 a.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
http://ppa2.quickbuild.pearsoncomputing.net/redirect.php?file=releases/3.5.…
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. :)
10:58 a.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
http://ppa2.quickbuild.pearsoncomputing.net/redirect.php?file=releases/3.5.…
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. :)
11:18 a.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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!
4:41 p.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
http://ppa2.quickbuild.pearsoncomputing.net/redirect.php?file=releases/3.5.…
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.
28 Sep
28 Sep
9:20 a.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
http://ppa2.quickbuild.pearsoncomputing.net/redirect.php?file=releases/3.5.…
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.
12:26 p.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
http://ppa2.quickbuild.pearsoncomputing.net/redirect.php?file=releases/3.5.…
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
29 Sep
29 Sep
10:45 a.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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
11:13 a.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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
2:14 p.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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.
30 Sep
30 Sep
4:24 a.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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(a)jabber.cz
On Wed, Sep 29, 2010 at 11:14 PM, Darrell Anderson
<humanreadable(a)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.
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.
2:16 p.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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.
3:03 p.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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.
6:35 p.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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.
7:51 p.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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."
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
8:06 p.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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
10:09 p.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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
1 Oct
1 Oct
7:26 a.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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.
7:28 a.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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.
9:29 a.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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, 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
12:39 p.m.
New subject: [trinity-devel] Trinity 3.5.12 pre-release source tarballs
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
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.
4978
days inactive
4982
days old
20 comments
3 participants
participants (3)
-
Darrell Anderson -
Ladislav Laska -
Timothy Pearson