Core x86_64 rawhide rebuild in mock status 2007-02-26
by Matt Domsch
Core Rawhide-in-Mock Build Results for x86_64 Mon Feb 26 15:27:48 CST 2007
Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/
Total packages: 1156
Number failed to build: 57
Number expected to fail due to ExclusiveArch or ExcludeArch: 15
Leaving: 42
(there may be some duplicates if rawhide has 2 versions of a package)
Of those expected to have worked...
Without a bug filed: 42
----------------------------------
alacarte-0.11.3-2.fc7
automake16-1.6.3-9
boost-1.33.1-10.fc7
castor-0.9.5-1jpp.7
compat-gcc-32-3.2.3-61
compat-gcc-34-3.4.6-4
expect-5.43.0-8
g-wrap-1.9.6-7.1
gnome-media-2.17.91-1.fc7
gnome-sharp-2.16.0-1.fc6
gnucash-2.0.4-1.fc6
grub-0.97-13
icon-naming-utils-0.8.1-1.fc6
jgroups-2.2.9.2-3jpp.2
kasumi-2.0.1-1.1.fc6
kdnssd-avahi-0.1.3-0.1.20060713svn.fc6
libevent-1.2a-1
libgssapi-0.10-1
linux-atm-2.5.0-1.20050118cvs
memtest86+-1.70-1.fc7
mikmod-3.1.6-39.fc7
mysqlclient10-3.23.58-9.2.1
mysqlclient14-4.1.14-4.2.1
nfs-utils-lib-1.0.8-8.fc7
perl-5.8.8-12.fc7
ppc64-utils-0.11-1.fc7
prelink-0.3.10-1
readahead-1.3-6.fc6
scim-anthy-1.2.2-1.fc7
sgml-common-0.6.3-19
squirrelmail-1.4.8-4.fc6
struts-1.2.9-4jpp.2
syslinux-3.36-1.fc7
systemtap-0.5.10-1.fc7
tetex-3.0-36.fc7
tk-8.4.13-4.fc7
tomcat5-5.5.17-6jpp.2
valgrind-3.2.3-2
velocity-1.4-6jpp.1
w3m-0.5.1-15.fc6
xen-3.0.4-6.fc7
xferstats-2.16-14.1
With bugs filed: 0
----------------------------------
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
17 years, 2 months
Re: [Mandrakeot] ESR gives up on Fedora
by Avi Kivity
Simo Sorce wrote:
> On Mon, 2007-02-26 at 08:31 +0200, Avi Kivity wrote:
>
>> Simo Sorce wrote:
>>
>>> What if I have a revolutionary machine that can copy your bicycle
>>>
>> and
>>
>>> reproduce it perfectly?
>>> Would it be theft if I come and copy yours and than go away leaving
>>> yours intact?
>>>
>>>
>>>
>> It destroys my bicycle rental business, which is based on my unique
>> bicycle-for-fourteen design. Go clone your own bike and leave mine
>> alone.
>>
>
> I understand your reasoning, since the invention of the light bulb
> destroyed candle makers business I think we should go back and forbid
> the use of light bulbs, it hurt their business after all.
>
>
The light bulb makers used their own brains to invent something new,
without stealing the candlemaker's bright ideas. That's called
progress. The bicycle cloners invented nothing (except the cloning
machine; they could be rich unless someone cloned _that_), they took
someone else's painstaking research and painful field trials, and sell
it or use it as if it's their own, damaging those who invented the
bicycle. If you're a software developer, you can probably appreciate
the amount of effort that goes into producing software. That effort has
value. Allowing anyone to copy it reduces that value.
> This argument is soo trollish.
>
> The rest is reiteration of the same concept, which shows you didn't even
> put effort in understanding what I am talking about, so there is no
> point in arguing again. Thread Closed.
>
We can close a thread by agreeing to disagree, but hurling insults and
saying "Thread Closed" is not the way to do it. I didn't insult you,
and I did read what you've written quite carefully. Even if you think
there's no inherent value in a clonable entity, you'll find there is
much value in carrying out a conversation in an adult manner.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
17 years, 2 months
Detecting the need for additional kernel options?
by Michel Salim
Is Anaconda currently checking the machine configuration against a
compatibility database? On some AMD64 laptops (including my HP L2000),
the machine would lock up randomly (without any log message) if booted
without "noapic" (I added "nosmp" for good measure).
Perhaps a user-maintainable database; we can consider tying it in with
Smolt so that only users who own a particular model can submit
required kernel options for it (to verify ownership, give the user a
token that they must pass to Smolt, e.g. smoltSendProfile
--key=AF32EBD4008)
Speaking of Smolt, the CPUspeed reported does not seem that useful,
unless it interfaces with CPUspeed to first set the clockspeed to
minimum, take a measurement, then set it to maximum, measure, and then
restore the original setting? My 2GHz laptop was reported as a 1.6 ..
--
Michel Salim
http://hircus.wordpress.com/
17 years, 2 months
Broken version check in eclipse-emf?
by Rubin
Hi all,
Got this since yesterday night:
# yum update
(yadayada)
...
--> Processing Dependency: eclipse-platform < 1:3.2.2 for package:
eclipse-emf
--> Finished Dependency Resolution
Error: Missing Dependency: eclipse-platform < 1:3.2.2 is needed by
package eclipse-emf
# rpm -q eclipse-platform
eclipse-platform-3.2.1-23.fc6
# rpm -q eclipse-emf
eclipse-emf-2.2.1-9.fc6
Am I correct in assuming the eclipse-emf package is either
version_check_in_requires_line_broken or too old for the newer
eclipse-platform package?
Kind regards,
Rubin.
17 years, 2 months
PHP Webserver Cluster Tool
by markw@mohawksoft.com
I'm not looking to spam these discussions, but I am in need of some beta
testers and good old fashioned QA and feedback.
I have an GPL Free/OpenSource software project called MCache. Its primary
goal is to facilitate and augment web cluster session management,
primarily in PHP but can easily be used for Java.
My open source site is: http://www.mohawksoft.org.
A brief discussion is located here: http://www.mohawksoft.org/?q=node/36
The main documentation is located here: http://www.mohawksoft.org/?q=node/8
Any and all help in this project is appreciated.
17 years, 2 months
2. Questions??
by "Jóhann B. Guðmundsson"
Still noticed when I downloaded and installed FC6 of dvd
that the I586 Issue had not been fixed, Some how I my brain thought
that a new dvd would be released that would contain the correct kernel (
I686 or I386)
Unless there is some reason for it not to be addressed?
Thought that creating a new DVD Image would be better than letting all
FC6 newcomers
have to figure out of it on their own.
In the upcoming release of FC7, Core and Extras become one repository :)
Wouldnt it be splended if Maintainers of Freshrpms and Livna would join
hands and merge as well :)
Keep up the good work
Best Regards
Jóhann B.
--
Jóhann B. Guðmundsson. RHCE,CCSA
Unix Kerfistjóri.
Kerfistjórn.
Reiknistofnun Háskóla Íslands.
Tæknigarði, Dunhaga 5. Rafpóstur: johannbg(a)hi.is
107 Reykjavík. Sími: 525-4267
Ísland. Bréfasími: 552-8801
Johann B. Gudmundsson. RHCE,CCSA
Unix System Engineer.
IT Management.
Reiknistofnun University of Iceland.
Taeknigardi, Dunhaga 5. Email: johannbg(a)hi.is
IS-107 Reykjavik. Phone: +354-525-4267
Iceland. Fax: +354-552-8801
17 years, 2 months
A slight change to the freeze/release times
by Jesse Keating
In the past we've had a few different strategies for freezing and releasing
test and final releases of Fedora. At times we would freeze on a Monday, to
release the following Monday. This gave us roughly until Friday to have
a "golden tree" so that the mirrors could sync all weekend. However many
mirror admins hated Monday releases, so we adjusted a bit and started
targetting Tuesday's for release. This was accomplished by moving the freeze
day from Monday to Tuesday. However this shortened the amount of time we had
to get a tree ready and we would often lose the weekend for syncing by not
having a tree ready in time, and continually slipping until Thursday. Moving
the freeze to Thursday and targetting the next Thursday for the release is
not optimal either, as we still have two days of freeze where little work may
get done (the weekend).
I've taken a look at what motivates our freeze time.
A) Have enough time where the tree doesn't change from under us so that we can
stabilize things and target specific fixes
B) Have a tree ready for the mirrors at least 2 days before the release date
so that we can ensure many mirrors are fully synced
C) Minimize the amount of time where development is stifled.
Motivation C really got me thinking. How are the freezes stifling
development? In the past with previous build systems, Release Engineering
would completely lock a buildroot. During a freeze, nobody would be able to
build a package for the development collection, instead all builds were
redirected to a development-HEAD like collection and sit there. Rel-eng
would have to interactively "move" any of these builds back into the
development collection to be included in whatever release we were freezing
for (as well as rawhide for public testing). This was tedious and often
broken, especially when the freeze was lifted and trying to merge those
builds back in.
With the new buildsystem we're using, we can create new tags very cheaply, so
we've tried freezing a different way. The day/time of the freeze, Release
Engineering will create a new "freeze" tag and tag all the latest packages
from the development collection with this new tag. We would adjust the
rawhide compose so that it composed from this new tag. Developers could
continue to build things into the development collection without change,
rel-eng would tag specific builds we wanted in our release (and rawhide) with
the freeze tag. At the end of the freeze, the rawhide compose was again
pointed at the development collection and thus no builds were lost. This is
better for keeping development from being stifled, however there is still the
act of "turning off" rawhide.
Why do we turn off rawhide, or rather make it compose from the freeze tag?
Mostly it is so that the community at large are using the same package
versions we hope to have on the release. Now with pungi, it is also so that
folks "playing along at home" can do composes with the package set as well.
We used to keep rawhide "shut off" until the release day of the test release.
This was to hopefully catch any last minute bugs and possibly call off the
test release. However I think we need to re-think this a bit, since once we
release something to the mirrors it is extremely difficult to prevent that
from leaking out.
So, for a proposal, I propose that we keep the current freeze day of Tuesday.
This allows for the general weekend/Monday clean up and final rush for the
freeze. I propose that we move the anticipated release day to Wed/Thu,
leaving it somewhat vague. We'd like to hit Wed, but more often than not it
may be Thu. I just don't want to send a slip note every single time we miss
Wed. I also propose that we "turn on" rawhide once we release the tree to
the mirrors. This should be either Monday or Tuesday of the release week.
This keeps the time development is "stifled" short, while maximizing the
number of business days that we have to get the tree in shape in time for the
mirrors to sync, and adjusts the schedule to something a bit closer to
reality.
Thoughts?
--
Jesse Keating
Release Engineer: Fedora
17 years, 2 months
Re: [Mandrakeot] ESR gives up on Fedora
by Avi Kivity
Simo Sorce wrote:
> What if I have a revolutionary machine that can copy your bicycle and
> reproduce it perfectly?
> Would it be theft if I come and copy yours and than go away leaving
> yours intact?
>
>
It destroys my bicycle rental business, which is based on my unique
bicycle-for-fourteen design. Go clone your own bike and leave mine alone.
>> Not that I'm trying to support IP, just trying to express that your
>> analogy sounds wrong.
>>
>
> Analogies are always wrong, simply because we are not comparing apples
> to apples, a bicycle is a physical object, software is not.
>
> Persisting in trying to treat "Intellectual Property" like traditional
> forms of property on physical objects is just plain stupid. Unless it is
> done on purpose, to confuse people, in which case it is criminal imo, as
> it is a form of fraud.
>
One motivation in creating new ideas (and in writing software) is to be
able to be rewarded by it. If anyone can copy my software, my movie, my
song, my cookie recipe, or my bicycle design, I may just not do it, and
wait for you to come up with it instead.
Producing ideas, software, movies, songs, cookie recipes, and bicycle
design takes considerable effort, just like acquiring physical objects.
Ownership over an object means control, and so does ownership over ideas.
It's okay for you or your employer to place all the results of your
efforts in the public domain if you wish (and no, the GPL isn't public
domain) but that is the result of your own choice. Forcing others to do
so will cause others either stop stop producing ideas or to tie them
into physical objects so that one can't steal them ("appliances").
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
17 years, 2 months
rawhide report: 20070226 changes
by Build System
Updated Packages:
kernel-2.6.20-1.2947.fc7
------------------------
* Sun Feb 25 2007 David Woodhouse <dwmw2(a)redhat.com>
- Revert commit 8d610dd52dd1da696e199e4b4545f33a2a5de5c6 which moved
rootfs population (and free_initrd()) much later in the init sequence.
It seems to cause memory corruption.
* Sat Feb 24 2007 John W. Linville <linville(a)redhat.com>
- Back-out bcm43xx changes related to recent hardware spec changes
* Sat Feb 24 2007 David Woodhouse <dwmw2(a)redhat.com>
- Disable PlayStation 3 support temporarily; its drivers break on non-PS3
and it's not quite working fully yet anyway
Broken deps for ia64
----------------------------------------------------------
pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5
systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11
systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11
Broken deps for s390
----------------------------------------------------------
systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11
systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11
17 years, 2 months