Notification - 2008-08-26 23:00 UTC
by Mike McGrath
There was an outage starting at 2008-08-26 23:00 UTC, which lasted
approximately 1 hour.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2008-08-26 23:00 UTC'
Affected Services:
Websites
Buildsystem
Database
Unaffected Services:
CVS / Source Control
DNS
Mail
Torrent
Ticket Link:
https://fedorahosted.org/fedora-infrastructure/ticket/784
Reason for Outage:
Cooling issues in our primary datacenter caused some ambient temperatures
to hit 39C/102F. After hitting a critical point many of our servers shut
themselves down. After the issue was corrected and things cooled down, we
powered up the servers without issue.
Contact Information:
Please join #fedora-admin in irc.freenode.net or respond to this email to
track the status of this outage.
15 years, 8 months
Re: moving libaio from /usr/lib to /lib -- any objections?
by rrankin@ihug.com.au
Jeff,
I added Denemo to rawhide on Monday (25/08) which uses libio. So this
may affect this new package.
Regards,
Roy Rankin
On Tue, 2008-08-26 at 09:42 -0400, Jeff Moyer wrote:
> Hi,
>
> Bug 459158 - multipath needs libaio in early userspace, can it be moved
> from /usr/lib to /lib?
>
> Does anyone see any problem with doing this? The library doesn't link
> with anything else.
15 years, 8 months
Re: compiler bug turning up in cmake package?
by Rex Dieter
John Fine wrote:
> Ulrich Drepper wrote:
>> It's most certainly not that simple. I haven't looked at the sources.
>> But the asm code does not really correspond to the code above. The
>> function above is most certainly inlined. The problem might very well
>> (and most likely is) in the use of this function. Look at the
>>
>> cmELF::GetRPath()
>>
>> function and where it directly or indirectly uses the Valid function.
>>
>>
> It is very simple and not a compiler bug, and you are correct that the
> error is in GetRPath.
>
> The code is
>
> if(this->Valid() &&
> this->Internal->GetFileType() == cmELF::FileTypeExecutable ||
> this->Internal->GetFileType() == cmELF::FileTypeSharedLibrary)
>
> Notice the lack of () around the || lines
So the simple(?) fix involves something like:
http://rdieter.fedorapeople.org/cmake-2.6.1-parens.patch
??
-- Rex
15 years, 8 months
cvs access denied (write permission)
by josef radinger
since several days i'm trying to update some spec-files via cvs and i
seem not to able to do that.
after some fiddling i found that i had to upload a new rsa-key (i tried
with dsa and got no meaningfull errormessage). i even managed to update
~fedora.cert + friends, but still no luck (the logmessage has only my
own comment for updateing):
[rpmbuild@cheese teg]$ cvs commit
cvs commit: Examining .
cvs commit: Examining F-7
cvs commit: Examining F-8
cvs commit: Examining F-9
cvs commit: Examining common
cvs commit: Examining devel
? devel/teg-0.11.2-15.fc10.src.rpm
? F-9/teg-0.11.2-16.fc9.src.rpm
cvs [server aborted]: "commit" requires write access to the repository
cvs commit: saving log message in /tmp/cvsmCWfVR
any ideas?
yours
josef
15 years, 8 months
Orphaning some packages
by Toshio Kuratomi
Hey guys,
I've orphaned qa-assistant which is a simple checklist application
written in pygtk. I'm also a negligent upstream for that so if you want
to pick it up, you'll probably want to do some upstream coding as well.
(I *think* the only thing that prevents it from building right now is
the configure script which I'd just convert to
paver/setuptools/distutils instead if I had the time). Let me know if
you want to pick this up and I'll get you access to the upstream source
(presently in svn on berlios.de)
I'm also maintaining the bzr version control system and would love for
other people who use it to take over maintainance of it or some of its
addon packages. Since I've been working on the TurboGears stack, I
haven't had time to package new software or help chase bugs in the
upstream code bases of a lot of the plugins. Comaintainers or packagers
of some of the addons would be greatly appreciated. These are packages
that are in the repository already:
bzr
bzrtools
bzr-gtk
Some of the many addons that aren't packaged::
bzr-bisect
bzr-stats
bzr-dbus
loggerhead
bzr-loom
Note that upstream bzr has expressed interest in merging some of these
into the bzr package if someone wants to do the work to implement a
smoke-screen test and submit the patch that merges it in. (bzr-bisect
comes to mind). This is something that I wanted to help out on but I
have lacked the time. An enthusiastic Fedora maintainer could help out
a lot with little things like that.
-Toshio
15 years, 8 months
Re: rpms/monodoc/devel import.log, NONE, 1.1 monodoc-2.0-makefile.patch, NONE, 1.1 .cvsignore, 1.9, 1.10 monodoc-patches.patch, 1.2, 1.3 monodoc.spec, 1.25, 1.26 sources, 1.9, 1.10
by Todd Zullinger
Paul F. Johnson wrote:
> Bump to 2.0 preview
> Alter license
[...]
> Index: monodoc.spec
> ===================================================================
> RCS file: /cvs/pkgs/rpms/monodoc/devel/monodoc.spec,v
> retrieving revision 1.25
> retrieving revision 1.26
> diff -u -r1.25 -r1.26
> --- monodoc.spec 11 Aug 2008 15:32:06 -0000 1.25
> +++ monodoc.spec 26 Aug 2008 15:03:13 -0000 1.26
> @@ -4,19 +4,19 @@
>
> Summary: The mono documentation system
> Name: monodoc
> -Version: 1.9
> -Release: 2%{?dist}
> -# No version specified. Most source files missing license attribution.
> -License: GPL+
> +Version: 2.0
> +Release: 1%{?dist}
> +License: GPL
Bzzzt. GPL is not a valid license. Your changes have undone the
change that Spot made to correct the licence tag (and the useful
comment directly above).
Please don't use cvs-import.sh without carefully ensuring that you are
not overwriting previous changes.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(When asked why he never drank water) "Fish fuck in it."
-- W.C. Fields
15 years, 8 months
compiler bug turning up in cmake package?
by Matthew Woehlke
I'm getting this SEGV trying to install kdelibs on my machine (koji
package 2.6.1-1.fc10.i386):
#0 cmELF::GetRPath (this=0xbf986708) at
/usr/src/debug/cmake-2.6.1/Source/cmELF.cxx:787
#1 0x080e9c07 in cmSystemTools::CheckRPath (file=@0xbf986800,
newRPath=@0xbf9867fc)
at /usr/src/debug/cmake-2.6.1/Source/cmSystemTools.cxx:2617
#2 0x08134378 in cmFileCommand::HandleRPathCheckCommand
(this=0x9ad3db8, args=@0xbf986874)
at /usr/src/debug/cmake-2.6.1/Source/cmFileCommand.cxx:1557
#3 0x0815dd6a in cmFileCommand::InitialPass (this=0x9ad3db8,
args=@0xbf986874)
at /usr/src/debug/cmake-2.6.1/Source/cmFileCommand.cxx:121
#4 0x081620cc in cmCommand::InvokeInitialPass (this=0x9ad3db8,
args=@0x9ad3fd4, status=@0xbf986918)
at /usr/src/debug/cmake-2.6.1/Source/cmCommand.h:68
#5 0x080c65a8 in cmMakefile::ExecuteCommand (this=0x9ac2730,
lff=@0x9ad3fc8, status=@0xbf986918)
at /usr/src/debug/cmake-2.6.1/Source/cmMakefile.cxx:399
#6 0x08150baa in cmIfFunctionBlocker::IsFunctionBlocked
(this=0x9ad1170, lff=@0x9ad7f98, mf=@0x9ac2730,
inStatus=@0xbf9869f8) at
/usr/src/debug/cmake-2.6.1/Source/cmIfCommand.cxx:116
#7 0x080b95dc in cmMakefile::IsFunctionBlocked (this=0x9ac2730,
lff=@0x9ad7f98, status=@0xbf9869f8)
at /usr/src/debug/cmake-2.6.1/Source/cmMakefile.cxx:2303
The relevant code is pretty boring:
785 bool cmELF::Valid() const
786 {
787 return this->Internal && this->Internal->GetFileType() !=
FileTypeInvalid;
788 }
...but the disassembly is unnerving:
0x819d4c0 <_ZN5cmELF8GetRPathEv>: push %ebp
0x819d4c1 <_ZN5cmELF8GetRPathEv+1>: mov %esp,%ebp
0x819d4c3 <_ZN5cmELF8GetRPathEv+3>: sub $0x8,%esp
0x819d4c6 <_ZN5cmELF8GetRPathEv+6>: mov 0x8(%ebp),%eax
0x819d4c9 <_ZN5cmELF8GetRPathEv+9>: mov (%eax),%edx
0x819d4cb <_ZN5cmELF8GetRPathEv+11>: test %edx,%edx
0x819d4cd <_ZN5cmELF8GetRPathEv+13>: je 0x819d510
<_ZN5cmELF8GetRPathEv+80>
0x819d4cf <_ZN5cmELF8GetRPathEv+15>: mov 0x10(%edx),%eax
0x819d4d2 <_ZN5cmELF8GetRPathEv+18>: test %eax,%eax
0x819d4d4 <_ZN5cmELF8GetRPathEv+20>: je 0x819d500
<_ZN5cmELF8GetRPathEv+64>
0x819d4d6 <_ZN5cmELF8GetRPathEv+22>: cmp $0x2,%eax
0x819d4d9 <_ZN5cmELF8GetRPathEv+25>: je 0x819d4e2
<_ZN5cmELF8GetRPathEv+34>
0x819d4db <_ZN5cmELF8GetRPathEv+27>: cmp $0x3,%eax
0x819d4de <_ZN5cmELF8GetRPathEv+30>: xchg %ax,%ax
0x819d4e0 <_ZN5cmELF8GetRPathEv+32>: jne 0x819d500
<_ZN5cmELF8GetRPathEv+64>
0x819d4e2 <_ZN5cmELF8GetRPathEv+34>: mov (%edx),%eax
0x819d4e4 <_ZN5cmELF8GetRPathEv+36>: movl $0xf,0x4(%esp)
0x819d4ec <_ZN5cmELF8GetRPathEv+44>: mov %edx,(%esp)
0x819d4ef <_ZN5cmELF8GetRPathEv+47>: call *0x14(%eax)
0x819d4f2 <_ZN5cmELF8GetRPathEv+50>: leave
0x819d4f3 <_ZN5cmELF8GetRPathEv+51>: nop
0x819d4f4 <_ZN5cmELF8GetRPathEv+52>: lea 0x0(%esi,%eiz,1),%esi
0x819d4f8 <_ZN5cmELF8GetRPathEv+56>: ret
0x819d4f9 <_ZN5cmELF8GetRPathEv+57>: lea 0x0(%esi,%eiz,1),%esi
0x819d500 <_ZN5cmELF8GetRPathEv+64>: xor %eax,%eax
0x819d502 <_ZN5cmELF8GetRPathEv+66>: leave
0x819d503 <_ZN5cmELF8GetRPathEv+67>: nop
0x819d504 <_ZN5cmELF8GetRPathEv+68>: lea 0x0(%esi,%eiz,1),%esi
0x819d508 <_ZN5cmELF8GetRPathEv+72>: ret
0x819d509 <_ZN5cmELF8GetRPathEv+73>: lea 0x0(%esi,%eiz,1),%esi
0x819d510 <_ZN5cmELF8GetRPathEv+80>: mov 0x10(%edx),%eax
0x819d513 <_ZN5cmELF8GetRPathEv+83>: nop
0x819d514 <_ZN5cmELF8GetRPathEv+84>: lea 0x0(%esi,%eiz,1),%esi
0x819d518 <_ZN5cmELF8GetRPathEv+88>: jmp 0x819d4db
<_ZN5cmELF8GetRPathEv+27>
Look particularly at the test at +11 and jump at +13, and then at lines
+80 and +15. If I read this right, it tests if "this->Internal" is NULL,
and then *dereferences it either way*. This is clearly not what the
source listing says (and is clearly wrong), so I wonder where this
generated code came from.
Hmm, actually, staring it it, trying to figure out how to hot-hack it so
the install will finish, it looks like the jump address is wrong (should
be going to +64, not +80). Or else, something funny is happening w.r.t.
"Internal"s vtable.
Note that "this" looks like:
(gdb) p *this
$3 = {Internal = 0x0, ErrorMessage = {static npos = 4294967295,
_M_dataplus = {<std::allocator<char>> =
{<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
fields>}, _M_p = 0xa0b402c "Error reading ELF identification."}}}
(edx is indeed 0x0, so that's definitely why it SEGV'd. And eax==this,
so I don't think I'm too far in the bushes guessing what went wrong.)
Note also that I first spotted this in 2.6.0-1.fc10.i386; my .rpm which
I kept around is timestamped 2008-05-06 (it also SEGV'd, but I upgraded
to 2.6.1 before digging into it, so I can't absolutely confirm the same
bug).
Because it looks like the generated code is bad, I'm inclined to blame
this first on the distro (Fedora) but I'm also CC'ing the cmake folk
(though I guess really I should be blaming either gcc, or come to think
of it, possibly gas), and also gcc-help as I figure they're most likely
to be able to make sense of the disassembly. Can anyone shed some light
on this?
I'll likely try to debug this further (please feel free to request
additional information), but for now it's a head's up of a bug in the
Fedora package.
(To the gcc folk: I know it's not a STC*, or even full code; sorry for
that, though in my experience compiler bugs like this disappear as soon
as the code is touched in the slightest manner, plus I don't have direct
access to the machine this was built on anyway. Hopefully I'll be able
to work with the Fedora people on that if it's needed. What I'm mainly
looking for from y'all is a second opinion if the assembly is clearly
whacked, or if there is an obvious flaw in my analysis.)
(*Simple Test Case)
--
Matthew
ENOWIT: .sig file for this machine not set up yet
15 years, 8 months