Build fails in koji, but not anywhere else ... how to debug?

[Tom Lane]

I've been pursuing, with increasing frustration, the seemingly simple
goal of getting mysql to rebuild in rawhide since the mass rebuild.
It failed in the mass rebuild (on the same source code which had worked
fine a few weeks before), and has failed multiple attempts since then,
for example
http://koji.fedoraproject.org/koji/getfile?taskID=1596536&name=build.log
http://koji.fedoraproject.org/koji/getfile?taskID=1606630&name=build.log
http://koji.fedoraproject.org/koji/getfile?taskID=1606834&name=build.log
The symptoms are not consistent, although there is some repetition;
for example the first and third runs above encountered the same failure.
It's usually the x86_64 build that dies, but I think that may just be
a reflection of the x86_64 builder being faster than the others.

What is frustrating me is that I can't reproduce the problem outside
koji where I might have a shot at debugging it.  It works fine in F-10,
F-11, rawhide, rawhide-via-mock, and everything else I've tried on my
own machines.  I've tried to try it on RHTS machines, but since neither
F-11 nor rawhide install successfully on those machines, that attempt
didn't get far either.  (And shouldn't somebody be paying closer
attention to that?)

I'm starting to wonder about corrupted ccache on the koji machines,
although unless they all share a common cache that theory doesn't seem
to hold much water.  I wonder if anyone else has a theory, or at least a
suggestion how to debug this problem?

BTW, the last time mysql started unexplainably failing its regression
tests in koji, it turned out to be because the build machines had been
switched to new RHEL-5 kernels that had a different page size on PPC
machines.  mysql is unduly sensitive to things like that :-(  So I'd
also be interested in information about any low-level changes that
might have been applied to the build machines a month or so ago.

regards, tom lane

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Lower Process Capabilities

[Steve Grubb]

On Friday 14 August 2009 06:05:06 pm Serge E. Hallyn wrote:
> Quoting Steve Grubb (sgr...@redhat.com):
> > On Sunday 26 July 2009 07:32:36 pm Steve Grubb wrote:
> > A sample srpm can be found here for anyone wanting to try it out before
> > alpha is unfrozen.
> >
> > http://people.redhat.com/sgrubb/files/filesystem-2.4.24-1.fc12.src.rpm
> >
> > Any feedback would be appreciated.
>
> downloading and looking at filesystem.spec in the above rpm, I don't
> see any special treatment for boot, root, or /lib  Is the right
> rpm at that link?

Should be. this morning I found that I forgot the /usr/lib[64] directories and
updated my local copy. I just updated the file I linked to above. 
rpm -qpl --verbose seems to show me that the changes are in place. I also
added tracker bugs to the project page so people can better tell what was
patched and how it might have been modified. In any event the patch attached to
bz is below. I only change the attributes and not the main code.

-Steve


--- filesystem.orig/filesystem.spec 2009-07-25 11:07:17.0 -0400
+++ filesystem/filesystem.spec  2009-08-14 13:09:19.0 -0400
@@ -79,15 +79,17 @@
 
 %files -f filelist
 %defattr(0755,root,root)
-%dir /
-/bin
-/boot
+%dir %attr(555,root,root) /
+%attr(555,root,root) /bin
+%attr(555,root,root) /boot
 /dev
 /etc
 /home
-/lib
+%attr(555,root,root) /lib
+%attr(555,root,root) /usr/lib
 %ifarch x86_64 ppc ppc64 sparc sparc64 s390 s390x
-/%{_lib}
+%attr(555,root,root) /%{_lib}
+%attr(555,root,root) /usr/%{_lib}
 %endif
 /media
 %dir /mnt
@@ -95,15 +97,16 @@
 %ghost %config(missingok) %verify(not size md5 mode user link rdev group 
mtime) /mnt/floppy
 %dir /opt
 %attr(555,root,root) /proc
-%attr(750,root,root) /root
-/sbin
+%attr(550,root,root) /root
+%attr(555,root,root) /sbin
 /selinux
 /srv
 /sys
 %attr(1777,root,root) /tmp
 %dir /usr
 /usr/[^s]*
-/usr/sbin
+%attr(555,root,root) /usr/sbin
+%attr(555,root,root) /usr/bin
 %dir /usr/share
 /usr/share/applications
 /usr/share/augeas

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Rebuilding mysql 5.1.30-1 fails under fc11

[Tom Lane]

Howard Wilkinson  writes:
>>> I am trying to regenerate the RPM packages for Mysql 5.1.30-1 as currently
>>> available for FC11. But the build fails a large number of the test cases. Is
>>> there a specific trick for getting this package to build properly?

> rpl.rpl_relay_space_innodb   [ pass ]913
> rpl.rpl_relayrotate  [ pass ]  16282
> rpl.rpl_slave_grp_exec   [ pass ]   3933
> timer 21378: expired after 18000 seconds
> Test suite timeout! Terminating...

After digging around, it seems that what you hit here is an arbitrary
upper limit that the mysql folks put on how long it should take the
regression tests to run.  In my experience the 5.1.x tests normally
take something close to 2 hours, on a reasonably current desktop machine
with nothing else going on.  I speculate that your machine was busy
running a lot of other builds concurrently, and it just plain took more
than 5 hours :-(.  The sum of the per-test times shown in your log is
about 221 minutes; after allowing for between-tests overhead, that seems
to match up reasonably well with the default 300-minute timeout.

I'm going to add a patch to increase the timeout to 12 hours, which
I hope will be enough for mass-rebuild scenarios like this one.
In the meantime, you'd probably find that it rebuilds okay if you do
it by itself.

regards, tom lane

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Lower Process Capabilities

[Serge E. Hallyn]

Quoting Steve Grubb (sgr...@redhat.com):
> On Sunday 26 July 2009 07:32:36 pm Steve Grubb wrote:
> > What can be done is that we program the application to drop some of the
> > capabilities so that its not all powerful. There's just one flaw in this
> > plan. The directory for /bin is 0755 root root. So, even if we drop all
> > capabilities, the root acct can still trojan a system.
> >
> > If we change the bin directory to 005, then root cannot write to that
> > directory unless it has the CAP_DAC_OVERRIDE capability. The idea with this
> > project is to not allow network facing or daemons have CAP_DAC_OVERRIDE,
> > but to only allow it from logins or su/sudo.
> 
> As discussed at the Fesco meeting last week, the lower process capabilities 
> project is going to reduce the scope of this part of the proposal. At this 
> point, we are going to tighten up perms on the directories in $PATH, 
> /lib[64], 
> /boot, and /root.
> 
> A sample srpm can be found here for anyone wanting to try it out before alpha 
> is unfrozen.
> 
> http://people.redhat.com/sgrubb/files/filesystem-2.4.24-1.fc12.src.rpm
> 
> Any feedback would be appreciated.

Hi Steve,

downloading and looking at filesystem.spec in the above rpm, I don't
see any special treatment for boot, root, or /lib  Is the right
rpm at that link?  If so, then I must be misunderstanding - can you
give me a diff or something to explain how it's supposed to work?

thanks,
-serge

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

2009-08-13 NetworkManager Test Day report

[Adam Williamson]

[forgot to cc to -devel-list]

We're going to try and be more organized about doing Test Day follow-ups
this cycle, so here goes!

Yesterday was the NetworkManager Test Day[1]. The Test Day was well
attended and very active; we thank the community members and Red Hat QA
team members who showed up, and the two DanWs (Williams and Winship) for
representing the development side. The full results matrix can be seen
on the Wiki page, but here's a report of all the bugs filed as a result
of the Test Day and their current status:

517243 NEW  - X nouveau livecd hangs on x86_64 machine
517228 NEW  - f12 rawhide networkmanager icon does not display
517253 NEW  - add new provider into Mobile broadband provider database
517294 NEW  - Connection established (got IP address) with wrong DNS 
configuration, and NetworkManager applet tray icon kept connecting status.
517270 NEW  - Warning when plugging in Nokia E71 via USB
517255 ASSIGNED  - network settings can't recognize ipv6 address
517229 ASSIGNED  - Network connection is stopped after service Networkmanager 
was stopped
517333 CLOSED RAWHIDE - NetworkManager stops already working network when 
starting
517242 CLOSED DUPLICATE - eth0 works fine but can't find it nor edit.
517267 CLOSED DUPLICATE - 2009-08-13 test day QA:Testcase_NetworkManager_assume 
failure
515797 CLOSED UPSTREAM - smoltSendProfile traceback

note that doesn't say whether they're in needinfo or not, it's not
straightforward to retrieve that information.

As this is the first time, I shall post for the group's amusement /
horror the command used to derive this list. It's run on a saved copy of
the Test Day page. Working out all the ways this could go wrong is left
as an exercise for the reader!

grep show_bug\.cgi\?id=[0-9][0-9][0-9][0-9][0-9][0-9] test_day_nm.html -o | 
sort -u | cut -d= -f 2 | tr '\n' ',' | xargs bugzilla query 
--outputformat="%{bug_id} %{bug_status} %{resolution} - %{short_desc}" -b

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 to require "i686", but which CPUs do not qualify?

[Adam Williamson]

On Fri, 2009-08-14 at 17:01 -0400, Tony Nelson wrote:
> On 09-08-14 09:20:04, Naheem Zaffar wrote:
> > Not Bill, but from my understanding, SSE2 was originally going to be
> > required and that question must have been presented and answered at
> > that point. Once the main page got updated after discussion, the 
> > original questions that no longer apply have not been removed.
> 
> Apparantly I'm not making myself clear.  That page specifically 
> excludes all AMD processors before the Geode LX, thus it excludes the 
> Athlon:
> 
> > * pre-AMD Geode processors

You're reading it wrong. That doesn't mean 'AMD processors before the
Geode', it means 'Geode processors before AMD bought out the Geode line
from NatSemi'.

Since someone's read it wrong, that's a good indication it should be
worded more clearly on the page :)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 to require "i686", but which CPUs do not qualify?

[Jesse Keating]

On Aug 14, 2009, at 14:01, Tony Nelson   
wrote:



On 09-08-14 09:20:04, Naheem Zaffar wrote:

Not Bill, but from my understanding, SSE2 was originally going to be
required and that question must have been presented and answered at
that point. Once the main page got updated after discussion, the
original questions that no longer apply have not been removed.


Apparantly I'm not making myself clear.  That page specifically
excludes all AMD processors before the Geode LX, thus it excludes the
Athlon:


* pre-AMD Geode processors


It may be that discussions have happened elsewhere, but the current
F12 Feature page does exclude the Athlon and similar processors.



Pretty sure this meant any geode before AMD picked them up, not any  
amd processor before the geode.


--
Jes 


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 to require "i686", but which CPUs do not qualify?

[drago01]

On Fri, Aug 14, 2009 at 11:01 PM, Tony
Nelson wrote:
> On 09-08-14 09:20:04, Naheem Zaffar wrote:
>> Not Bill, but from my understanding, SSE2 was originally going to be
>> required and that question must have been presented and answered at
>> that point. Once the main page got updated after discussion, the
>> original questions that no longer apply have not been removed.
>
> Apparantly I'm not making myself clear.  That page specifically
> excludes all AMD processors before the Geode LX, thus it excludes the
> Athlon:
>
>> * pre-AMD Geode processors
>
> It may be that discussions have happened elsewhere, but the current
> F12 Feature page does exclude the Athlon and similar processors.

The Athlon supports at least the same instructions as the Geode.
Athlon and PIII support where the main reasons why people where
against a sse2 requirement.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 to require "i686", but which CPUs do not qualify?

[Tony Nelson]

On 09-08-14 09:20:04, Naheem Zaffar wrote:
> Not Bill, but from my understanding, SSE2 was originally going to be
> required and that question must have been presented and answered at
> that point. Once the main page got updated after discussion, the 
> original questions that no longer apply have not been removed.

Apparantly I'm not making myself clear.  That page specifically 
excludes all AMD processors before the Geode LX, thus it excludes the 
Athlon:

> * pre-AMD Geode processors

It may be that discussions have happened elsewhere, but the current
F12 Feature page does exclude the Athlon and similar processors.


> 2009/8/14 Tony Nelson
> >
> >
> > That doesn't actually quite say about SSE2, but at
> > :
> >
> > > _Bill Nottingham_ Once a set has been decided on, this should be
> > > pretty trivial. With respect to the proposal, 'grep sse2 /proc/
> > > cpuinfo' should work.
> >
> > Bill?

-- 

TonyN.:'   
  '  


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: naive live USB question

[psmith]

On 13/08/09 17:06, Adam Williamson wrote:

On Thu, 2009-08-13 at 12:12 +0100, psmith wrote:

   

jeez when i brought up the idea of fedora using hybrid iso's a few
months back i was basically lambasted by most on this list, now all of
a sudden it's a new F12 feature? wtf???
 


Didn't you know? That's how Fedora works. First everyone tells you
you're insane, crazy, probably a drooling idiot, and there's ten reasons
your idea will never work and would eat babies if it did.

Then they implement it. :)

   
heh thanks adam, you just brought a big smile to my face :D just when i 
needed one too lol


phil
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Another linux kernel NULL pointer vulnerability ( exploit here )

[Christoph Wickert]

Am Freitag, den 14.08.2009, 14:39 -0300 schrieb Itamar Reis Peixoto:
> Hello guy's
> 
> for the people who don't have updated the kernel.

I'm running kernel-2.6.29.6-217.2.3.fc11.x86_64 and this one is not
supposed to be fixed, however...

> http://grsecurity.net/%7Espender/wunderbar_emporium.tgz

... it doesn't work here. Although the author claims it's not stopped by
SELinux (he even mentions Dan by name), SELinux one more time saves the
world:

$ su -c 'setenforce 0'
$ LANG=C sh wunderbar_emporium.sh 
runcon: invalid context:
unconfined_u:unconfined_r:initrc_t:s0-s0:c0.c1023: Invalid argument
 [+] MAPPED ZERO PAGE!
 [+] Resolved selinux_enforcing to 0x81874374
 [+] Resolved selinux_enabled to 0x815a0a60
 [+] Resolved security_ops to 0x81871b20
 [+] Resolved default_security_ops to 0x815a0080
 [+] Resolved sel_read_enforce to 0x8118934c
 [+] Resolved audit_enabled to 0x8182e804
 [+] Resolved commit_creds to 0x810615c3
 [+] Resolved prepare_kernel_cred to 0x810614a4
 [+] got ring0!
 [+] detected 2.6 style 4k stacks
sh: mplayer: command not found
 [+] Disabled security of : nothing, what an insecure machine!
 [+] Got root!
sh-4.0# setenforce 1
sh-4.0# exit
exit
$ LANG=C sh wunderbar_emporium.sh 
runcon: invalid context:
unconfined_u:unconfined_r:initrc_t:s0-s0:c0.c1023: Invalid argument
UNABLE TO MAP ZERO PAGE!

The log entry:
> node=wicktop.localdomain type=AVC msg=audit(1250276339.135:27494):
> avc: denied { mmap_zero } for pid=16293 comm="exploit"
> scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> tclass=memprotect node=wicktop.localdomain type=SYSCALL
> msg=audit(1250276339.135:27494): arch=c03e syscall=9 success=yes
> exit=0 a0=0 a1=1000 a2=7 a3=32 items=0 ppid=16273 pid=16293 auid=500
> uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500
> fsgid=500 tty=pts4 ses=1 comm="exploit"
> exe="/home/chris/Downloads/wunderbar_emporium/exploit"
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) 

So I suggest to calm down and not believer everything you read.

Regards,
Christoph

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

FESCo meeting summary for 2009-08-14

[Jon Stanley]

Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2009-08-14/fedora-meeting.2009-08-14-17.01.html
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting/2009-08-14/fedora-meeting.2009-08-14-17.01.txt
Log:
http://meetbot.fedoraproject.org/fedora-meeting/2009-08-14/fedora-meeting.2009-08-14-17.01.log.html

--

17:01:23  #startmeeting FESCo meeting 2009/08/14
17:01:25  #chair dgilmore jwb notting nirik sharkcz jds2001
j-rod skvidal Kevin_Kofler
17:01:41 * nirik is here.
17:01:43  so notting and skvidal are unhere
17:02:04  Present.
17:02:44 * dgilmore is here
17:03:02 * j-rod here
17:03:27  cool
17:03:42  #topic apcuspd static linking
17:03:47  .fesco 235
17:04:16  Can't the libs go to /lib instead?
17:04:26  Static linking sounds like a bad solution to me.
17:04:44  please to be not the linking of static
17:04:46  how many are there?
17:04:47  But there clearly is a problem there, stuff in
/ must not require libs from /usr.
17:04:57  .bugzilla bug 346271
17:04:59  Bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=346271 low, low,
---, notting, ASSIGNED, halt initscript does not properly handle
apcupsd shutdowns
17:05:28  it's other packages /usr/lib/ libs that it's linked to...
17:05:45  snmp and sensors
17:05:53  Those need to be moved to /lib.
17:06:09  well my rootfs is typically like 1GB
17:06:10  Statically linking strikes me as the wrong
solution to a real problem.
17:06:19  i thought we had already agreed that we dont
support /usr of a seperate filesystem
17:06:39  so if we move everything in the world to /lib, then
I've got a problem.
17:07:01  dgilmore: yeah, I wonder how many people aside from
jds2001 do seperate /usr anymore.
17:07:23 * jds2001 doesnt think i'm unique :)
17:07:36  the guide suggests against it.
17:07:37  jds2001: but you are
17:07:39 
http://docs.fedoraproject.org/install-guide/f11/en-US/html/s2-diskpartrecommend-x86.html#sn-partitioning-advice
17:07:48 * jds2001 can point to several thousand systems at $DAYJOB
that have a separate /usr
17:07:49  "Do not place /usr on a separate partition"
17:08:08  jds2001: is that seperate /usr on local disk? or via net?
17:08:15  local disk
17:08:17  im pretty sure last release we said that /usr on a
seperate filesystem was not supported
17:08:38  then in this case I don't think it matters. This is
only a problem if we shut down net and can't use /usr/lib/
17:08:39  and they're RHEL/Solaris, but the point remains.
17:09:03  I think remote /usr isn't supported.
17:09:05  so this case is not 'seperate /usr' but 'seperate
/usr on network'
17:09:11  (unless I am reading this wrong)
17:09:29  pretty much how i read it too.
17:09:42  nirik: which is really not supported
17:10:01  humm... or is it... does it umount other fses before
it runs that?
17:11:17 * nirik re-reads the patch and halt script.
17:12:22  no, it's all non root mounts I think...
17:12:23  How much of the static libs gets linked in if
we do the static linking? If it doesn't actually save space, then it's
a no-brainer to -1 it and tell them to just move the stuff to /lib
instead if they want to support this usecase.
17:13:07  its a seperate /usr
17:13:18  yeah, I don't know how far it goes adding those 2
packages and their deps to /lib
17:13:26  One advantage of moving to /lib is that it
costs essentially nothing for those who don't have separate /usr
unlike static linking.
17:13:53  So for the vast majority of people, if the
problem is to be solved, moving to /lib is the best solution.
17:13:57  the answer here i believe is dont have a seperate /usr
17:14:49  it doesnt make sense like it used to anymore
17:14:55  Why can't we just move the libs to /lib? For
all those without a separate /usr, it won't change a thing.
17:15:13  Kevin_Kofler: where do we stop?
17:15:25  For those few folks with a separate /usr,
it'll solve their problem, and if their / is not big enough, they'll
just have to fix it.
17:15:50  dgilmore: Good question. Maybe we should drop
/usr entirely like HURD or make it an alias for / like MSYS? ;-)
17:15:51  if it's just 2 packages for this I'd be ok with
moving them to /lib... but if it pulls in a bunch of stuff we should
just say no.
17:16:21  in any case I don't think we should static link
unless there is a more compelling reason.
17:16:27  yeah, I'm wondering how much stuff it drags in
17:16:39  static linking is bad, mmmkkaayyy :)
17:16:42  Do not place /usr on a separate partition If /usr
is on a separate partition from /, the boot process becomes much more
complex, and in some situations (like installations on iSCSI drives),
might not work at all.
17:16:48  from the install guide
17:17:11  how does it become more complex?
17:17:24  the /usr gets mounted in rc.sysinit
17:17:28  Can we vote on not allowing the static linking
exception first of all?
17:17:33  I think we all agree on that part.
17:17:39  we likely have other things people consider
critical to propper functionality that live in /usr
17:17:42  sure, -1
17:17:58  -1 to the exce

Another linux kernel NULL pointer vulnerability ( exploit here )

[Itamar Reis Peixoto]

Hello guy's

for the people who don't have updated the kernel.


http://grsecurity.net/%7Espender/wunderbar_emporium.tgz



-- 


Itamar Reis Peixoto

e-mail/msn: ita...@ispbrasil.com.br
sip: ita...@ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Printing test day coming up...

[Matthias Clasen]

On Fri, 2009-08-14 at 11:38 -0400, Matthias Clasen wrote:
> Another week, another Fit and Finish test day.
> This time around, we want to look at printing.
> 
> See
> http://www.fedoraproject.org/wiki/Test_Day:2009-08-18_Fit_and_Finish:Printing
> 
> Both Marek Kasik and Tim Waugh have kindly agreed to be around, so we'll
> have sufficient expertise for all of the printing stack.  
> 
> Drop in #fedora-fit-and-finish on Freenode on Tuesday, Aug 14, to join
> in the fun. 

...and of course, when I was talking about Aug 14, I meant Aug 18. 


Sorry, Matthias

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Fedora 12 Alpha Blocker Meeting Recap

[James Laska]

Meeting log available at
http://meetbot.fedoraproject.org/fedora-bugzappers/2009-08-14/fedora-bugzappers.2009-08-14-15.13.html

= Attendees =

jlaska, poelcat, rjune_wrk, stickster, jeff_hann

= https://bugzilla.redhat.com/show_bug.cgi?id=516941 =
State: MODIFIED

Anyone using the radeon driver is asked to help verify the fix against
kernel-2.6.31-0.145.2.1.rc5.git3.fc12.

= https://bugzilla.redhat.com/show_bug.cgi?id=517171 =
State: MODIFIED

Anaconda-12.15 did not arrive in last nights rawhide, so QA is unable to
verify the fix for this issue.  

= https://bugzilla.redhat.com/show_bug.cgi?id=517475 =
State: NEW

The group was not able to reach a conclusion.  Several people questioned
whether a downstream project should block the Alpha.  Another concern
reflected the number of Alpha testers impacted by the geode failure.

== UPDATES ==

SMOLT geode stats -
http://smolts.org/reports/view_devices?device=Geode&search=Submit+Query

After discussing with Jkeating, the proposed rpm patch is limited to
geode and does not appear to affect other platforms (see
http://www.redhat.com/archives/fedora-devel-list/2009-June/msg01641.html).  
Jkeating felt the bug was worth addressing to unblock OLPC/XO testers using the 
Alpha.  Jlaska expressed concern why this patch hadn't been applied yet, but 
indicated the issue was a 'nice to have' for the alpha.

= Action items =

[jlaska] - follow-up in bug#517 with additional information

= Open discussion =

== Verifying MODIFIED bugs ==

poelcat asked what the recommended practice was for monitoring what bugs
need testing.  Jlaska indicated he was asking QA folks to keep an eye on
MODIFIED bugs on the blocker list.  Additionally, there is a
NEEDSRETESTING keyword available.

== Rawhide install test run ==

Jlaska provided results from a test run initiated by lili and rhe last
night against rawhide.  This provides a more recent snapshot of
installer status with anaconda-12.14 (see
https://fedoraproject.org/wiki/QA:Fedora_12_Alpha_TCRegression_Install_Test_Results).
  No new alpha blockers have been escalated from this testing.

Thanks,
James


signature.asc
Description: This is a digitally signed message part
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[ANNOUNCEMENT] dracut-0.9

[Harald Hoyer]

dracut-0.9
==
- let plymouth attach to the terminal (nice text output now)
- new kernel command line parameter "rdinfo" show dracut output, even when
  "quiet" is specified
- rd_LUKS_UUID is now handled correctly
- dracut-gencmdline: rd_LUKS_UUID and rd_MD_UUID is now correctly generated
- now generates initrd-generic with around 15MB
- smaller bugfixes

dracut-0.8
==
- iSCSI with username and password
- support for live images (dmsquashed live images)
- iscsi_firmware fixes
- smaller images
- bugfixes

dracut-0.7
==
- dracut: strip binaries in initramfs

   --strip
  strip binaries in the initramfs (default)

   --nostrip
  do not strip binaries in the initramfs
- dracut-catimages

Usage: ./dracut-catimages [OPTION]...  
[...]
Creates initial ramdisk image by concatenating several images from the
command
line and /boot/dracut/

  -f, --force   Overwrite existing initramfs file.
  -i, --imagedirDirectory with additional images to add
(default: /boot/dracut/)
  -o, --overlaydir  Overlay directory, which contains files that
will be used to create an additional image
  --nooverlay   Do not use the overlay directory
  --noimagedir  Do not use the additional image directory
  -h, --helpThis message
  --debug   Output debug information of the build process
  -v, --verbose Verbose output during the build process

- s390 dasd support

dracut-0.6
==
- dracut: add --kernel-only and --no-kernel arguments

   --kernel-only
  only install kernel drivers and firmware files

   --no-kernel
  do not install kernel drivers and firmware files

All kernel module related install commands moved from "install"
to "installkernel".

For "--kernel-only" all installkernel scripts of the specified
modules are used, regardless of any checks, so that all modules
which might be needed by any dracut generic image are in.

The basic idea is to create two images. One image with the kernel
modules and one without. So if the kernel changes, you only have
to replace one image.

Grub and the kernel can handle multiple images, so grub entry can
look like this:

title Fedora (2.6.29.5-191.fc11.i586)
root (hd0,0)
kernel /vmlinuz-2.6.29.5-191.fc11.i586 ro rhgb quiet
initrd /initrd-20090722.img 
/initrd-kernel-2.6.29.5-191.fc11.i586.img /initrd-config.img


initrd-20090722.img
  the image provided by the initrd rpm
  one old backup version is kept like with the kernel

initrd-kernel-2.6.29.5-191.fc11.i586.img
  the image provided by the kernel rpm

initrd-config.img
  optional image with local configuration files

- dracut: add --kmoddir directory, where to look for kernel modules

   -k, --kmoddir [DIR]
  specify the directory, where to look for kernel modules


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Printing test day coming up...

[Matthias Clasen]

Another week, another Fit and Finish test day.
This time around, we want to look at printing.

See
http://www.fedoraproject.org/wiki/Test_Day:2009-08-18_Fit_and_Finish:Printing

Both Marek Kasik and Tim Waugh have kindly agreed to be around, so we'll
have sufficient expertise for all of the printing stack.  

Drop in #fedora-fit-and-finish on Freenode on Tuesday, Aug 14, to join
in the fun. 


Matthias 

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 to require "i686", but which CPUs do not qualify?

[Nalin Dahyabhai]

On Fri, Aug 14, 2009 at 10:38:58AM +0100, Andrew Haley wrote:
> Kevin Kofler wrote:
> > We need to provide "architectural defaults" for plain i686, even crappy 
> > ones, they just need to work at all.
> 
> I think there's a valid case for making an exception to this: when a
> package is an accelerated version of a particular library.  That is,
> when the basic functionality of a library is available in a i686
> Fedora package, but a special SSEx version of the library makes use of
> faster instructions.

The run-time linker on i386 can already pick up an SSE2-specific build
of a shared library if it's available -- the i386 gmp package makes use
of this.  Of course, both builds have to provide the same interfaces for
that to work, and I'm not sufficiently familiar with this set of
libraries to know if they do.

If they do, and if the libc maintainers think it's worth doing, this
support could be extended to cover SSE- and SSE3-specific versions.  We
could then package these optimized versions of the library with the
fallback works-everywhere version and let ld.so sort out the details at
runtime.

That's quite a few "if"s, and I'm not one of the people who'd have to
actually do the work, so I'll shut up now.

HTH,

Nalin

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 to require "i686", but which CPUs do not qualify?

[Deji Akingunola]

On Fri, Aug 14, 2009 at 10:04 AM, Joachim wrote:
>> I think there's a valid case for making an exception to this: when a
>> package is an accelerated version of a particular library.  That is,
>> when the basic functionality of a library is available in a i686
>> Fedora package, but a special SSEx version of the library makes use of
>> faster instructions.
>>
>> Andrew.
>
> Right now, there exist a number of packages which explicitly pull in
> atlas instead of the also available generic packages blas/lapack which
> do not exhibit these severe restrictions.
> Earlier versions of the Fedora atlas package actually supported a
> wider range of processors including even such offering 3dnow! and also
> plain x86. The current behaviour (code depending on lapack aborts
> because of illegal instructions) is a regression which has been
> introduced by the packager.
>
Correction: The current behaviour was not introduced by the packager,
it is because of changes in the upstream's design of the package;
unless of course you mean we should be stuck with the old version.
The only way to produce atlas binary for architectures not provided
for in the upstream tarball, is to bootstrap it on that particular
arch. Unfortunately none of Fedora build infrastructure is based on
PII or less.

Deji

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: An error while using livecd-creator

[Jeremy Katz]

On Tuesday, August 11 2009, Kushal Das said:
> I am using livecd-creator on a F-11 box. I have 27GB free on my / partition.
> The error I am getting is given below:
[snip]
> Error creating Live CD : Unable to install: [('installing package
> bug-buddy-1:2.26.0-2.fc11.i586 needs 684KB on the
> /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
[snip]
> Any pointer on how to fix this ?

As the message says, there's not enough space in the root fs of the
livecd (/var/tmp/imgcreate-X/install_root) to install the packages.

If you were overriding the size of the / partition, be sure you have the
latest pykickstart package installed as there was a bug there that broke
the overriding

Jeremy

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Lower Process Capabilities

[David Malcolm]

On Thu, 2009-08-13 at 21:27 -0400, Steve Grubb wrote:
> On Thursday 13 August 2009 05:53:37 pm John Poelstra wrote:
> > Can you update the feature page to reflect the reduced scope of the
> > feature and its completion percentage?  All I see since FESCo met was
> > the change to the detailed description related to the permissions.
> 
> That *is* the reduction in scope - other than what I have time to actually 
> work on. If I can fix dhcp, that is a major win. That is the item that stands 
> out as the biggest problem when running netcap.

Steve: With my paranoid/QA hat on, I think the "How to Test" section
needs some more items.   It covers testing that each specific change
being made works as expected, but it doesn't also cover testing that
there weren't unexpected side effects.

I added some questions to this end to the discussion page:
https://fedoraproject.org/wiki/Talk:Features/LowerProcessCapabilities


Hope this is helpful
Dave


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

New, improved FESCo trac instance

[Jon Stanley]

As one of the features implemented out of a complaint that the FESCo
wiki information was outdated since our move to a Trac-based workflow,
there are now templates for various types of tickets in the FESCo trac
instance at https://fedorahosted.org/fesco.

If you attempt to file a ticket, a template will appear.  If you
change the type of ticket, it will ask if you wish to reload the
template for that ticket type.  Click OK. and you have a relevant
template to fill out.  Delete the explanatory text in the template,
and fill in the requested information.

This will enhance the ability for FESCo to provide prompt resolution to issues.

Thanks for your cooperation!
-Jon

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 to require "i686", but which CPUs do not qualify?

[Joachim]

> I think there's a valid case for making an exception to this: when a
> package is an accelerated version of a particular library.  That is,
> when the basic functionality of a library is available in a i686
> Fedora package, but a special SSEx version of the library makes use of
> faster instructions.
>
> Andrew.

Right now, there exist a number of packages which explicitly pull in
atlas instead of the also available generic packages blas/lapack which
do not exhibit these severe restrictions.
Earlier versions of the Fedora atlas package actually supported a
wider range of processors including even such offering 3dnow! and also
plain x86. The current behaviour (code depending on lapack aborts
because of illegal instructions) is a regression which has been
introduced by the packager.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Lower Process Capabilities

[Jon Stanley]

On Mon, Aug 3, 2009 at 12:38 PM, Till Maas wrote:

> $ sudo -i
> sudo: /etc/sudoers is mode 00, should be 0440
> sudo: no valid sudoers sources found, quitting

This is sudo checking the permissions of it's own sudoers file.  Since
they aren't what it expects, it bails.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 to require "i686", but which CPUs do not qualify?

[Naheem Zaffar]

Not Bill, but from my understanding, SSE2 was originally going to be
required and that question must have been presented and answered at that
point. Once the main page got updated after discussion, the original
questions that no longer apply have not been removed.

2009/8/14 Tony Nelson
>
>
> That doesn't actually quite say about SSE2, but at
> :
>
> > _Bill Nottingham_ Once a set has been decided on, this should be
> > pretty trivial. With respect to the proposal, 'grep sse2 /proc/
> > cpuinfo' should work.
>
> Bill?
>
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 to require "i686", but which CPUs do not qualify?

[Tony Nelson]

I'm late replying -- had trouble with my mail server -- so I'm moving 
all my replies to Bill Nottingham's post, as I think he can fix the 
wiki pages most authoritatively to not say that Athlons will not work,
if that is indeed the proper thing to do, given that so many packages 
depend on packages that are only built for SSE2.




If necessary, I can install Rawhide and see if it boots, and then edit 
the above wiki page and the Alpha release notes, but I'd prefer if 
someone who already uses an Athlon-core processor on Rawhide did it.


On 09-08-13 10:34:58, Peter Robinson wrote:
> Tony Nelson wrote:
 ...
> > Is there a simple way for ordinary users to know if their CPU is
> > expected to work on F12 (as an "i686" according to GCC)?  Is there 
> > a tool to run that doesn't require downloading F12?
> 
> https://fedoraproject.org/wiki/Features/F12X86Support
> 
> Its outlined in the link above. An athlon should be fine. Basically 
> if its i586 + cmov it should work. You can tell if you have cmov by
> looking at /proc/cpuinfo.

According to that link, an Athlon is specifically excluded.  According 
to the Talk:Features/F12X86Support link 
, SSE2 is 
required.


> Originally it wasn't planned to support them but there was enough
> discussion to change peoples minds :-)

If that has changed, then those wiki pages need updating, as well as 
the Release Notes and release announcements.  Thanks.


On 09-08-13 10:35:29, Jon Ciesla wrote:
> Quoting Bill Nottingham:
> 
> Given the loud feedback, I've updated the proposal at:
>   https://fedoraproject.org/wiki/Features/F12X86Support
> 
> The revised proposal:
> 
> - Build all packages for i686 (this requires cmov)
> - Optimize for Atom
> 
> Why?
 ...

That doesn't actually quite say about SSE2, but at 
:

> _Bill Nottingham_ Once a set has been decided on, this should be 
> pretty trivial. With respect to the proposal, 'grep sse2 /proc/
> cpuinfo' should work.

Bill?

-- 

TonyN.:'   
  '  

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Package groups vs "metapackages"

[Dennis Gregorovic]

On Thu, 2009-08-13 at 14:38 -0700, Adam Williamson wrote:
> On Thu, 2009-08-13 at 12:53 -0700, Bryan O'Sullivan wrote:
> > I've been working recently on bringing Fedora up to snuff as a
> > platform to build Haskell software on:
> > 
> > https://fedoraproject.org/wiki/SIGs/Haskell#Haskell_Platform_support
> > 
> > In my ideal world, it would be possible to install all of the
> > necessities for decent Haskell development via a single short command
> > line. I can see two ways to do this:
> >   * Create a "haskell-devel" (or something) package that simply
> > depends on all of the Haskell Platform's component packages.
> > This would have the nice property of being versioned, just as
> > the Haskell Platform itself is.
> >   * Create a "Haskell Development" group in comps. This is unknown
> > territory to me: I don't know if it's a good idea, how it
> > would work, how I'd edit it to add new dependencies when the
> > Haskell Platform gets updates, or ... well, anything.
> > What's the collective wisdom about the best approach for doing this?
> 
> I wondered about this too when I joined, and several people told me
> metapackages are generally discouraged in favour of package groups. I
> don't know the rationale behind that decision, but that's what I was
> told.

I prefer comps groups.  Here are the benefits of each approach as I see
it:

Comps Groups
  * visible through anaconda
  * configurable between products
  * allows for mandatory/default/optional/conditional packages
  * "cleaner" - i.e. comps groups were meant for this purpose
whereas metapackages are more of a kludge

Metapackages
  * allow for versioned package listings

Cheers
-- Dennis

p.s. If you decide to create a metapackage, don't name it *-devel.
Packages with those names are assumed to contain development libraries
and are automatically marked as multilib.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Updates lacking descriptions

[Seth Vidal]

On Fri, 14 Aug 2009, Rahul Sundaram wrote:


On 08/14/2009 09:11 AM, Ralf Corsepius wrote:


I strongly think Fedora would be better without Rahul and Kevin, two
persons I have learned to be doing a good job on certain subjects, but
to be a miscast on certain jobs and failure of the system in Fedora.


Of course, noone can hold a opinion that is different from yours and
still acknowledged to be even reasonable.

Yes and all the private flames (not that the public behaviour is any
better) you have been sending for years have been quite an inspiration.
I doubt anyone can change your behaviour but I do agree that continuing
to tolerate it is a failure of the system in Fedora. No more from me on
this topic.



This thread is now closed.
-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Updates lacking descriptions

[Seth Vidal]

On Fri, 14 Aug 2009, Chris Adams wrote:


Once upon a time, Ralf Corsepius  said:

On 08/13/2009 06:55 PM, Josh Boyer wrote:

Two wrongs does not make a right.  Everyone needs to stop the back and
forth
on this now.

And censorship doesn't make it better.


Asking people to try to be polite or to take a break when discussions
get heated is not censorship.


I strongly think Fedora would be better without ...


That is far over the line for acceptable behavior.


This thread is now closed.

-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Updates lacking descriptions

[Seth Vidal]

On Fri, 14 Aug 2009, Thomas Janssen wrote:


2009/8/14 Ralf Corsepius :

On 08/14/2009 07:32 AM, Jesse Keating wrote:

On Fri, 2009-08-14 at 05:41 +0200, Ralf Corsepius wrote:

I strongly think Fedora would be better without Rahul and Kevin, two
persons I have learned to be doing a good job on certain subjects, but
to be a miscast on certain jobs and failure of the system in Fedora.


I strongly feel that Fedora would be better without this negative
attitude, and the appearance that this kind of attitude is tolerated.



First of all I do not consider my answers to be rude, but to be "open". OK,
I might not always be using the correct wording (I am not a native English
speaker) and phrases people from the US might consider "appropriate phrases"
(German is a much direct language than US-English) - My appologies for that.


Erm.. I'm German as well, and what you wrote in this thread (and other
stuff you wrote on this list) *is* rude. Do not try to excuse your
behavior with "you're German". You do a lot of discredit to the other
Germans on this list with it.



this thread is now closed.

-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Updates lacking descriptions

[Seth Vidal]

On Thu, 13 Aug 2009, Jesse Keating wrote:


On Fri, 2009-08-14 at 05:41 +0200, Ralf Corsepius wrote:


I strongly think Fedora would be better without Rahul and Kevin, two
persons I have learned to be doing a good job on certain subjects, but
to be a miscast on certain jobs and failure of the system in Fedora.


I strongly feel that Fedora would be better without this negative
attitude, and the appearance that this kind of attitude is tolerated.
It's not.  Your continued poisonous and rude attitude on these lists
have gone unchecked for far too long.  Please keep it in check, or spend
some time somewhere else.


This thread is now closed.
-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Updates lacking descriptions

[Seth Vidal]

On Fri, 14 Aug 2009, Ralf Corsepius wrote:


forth
on this now.

And censorship doesn't make it better.

I strongly think Fedora would be better without Rahul and Kevin, two persons 
I have learned to be doing a good job on certain subjects, but to be a 
miscast on certain jobs and failure of the system in Fedora.




This thread is now closed.

-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

rawhide report: 20090814 changes

[Rawhide Report]

Compose started at Fri Aug 14 06:15:05 UTC 2009

Updated Packages:

cups-1.4-0.rc1.15.fc12
--
* Tue Aug 11 2009 Tim Waugh  1:1.4-0.rc1.15
- Avoid empty BrowseLocalProtocols setting (bug #516460, STR #3287).

* Mon Aug 10 2009 Tim Waugh  1:1.4-0.rc1.14
- Fixed ppds.dat handling of drv files (bug #515027, STR #3279).
- Fixed udev rules file to avoid DEVTYPE warning messages.
- Fixed cupsGetNamedDest() so it does not fall back to the default
  printer when a destination has been named (bug #516439, STR #3285).
- Fixed MIME type rules for image/jpeg and image/x-bitmap
  (bug #516438, STR #3284).
- Clear out cache files on upgrade.
- Require acl.

* Thu Aug 06 2009 Tim Waugh  1:1.4-0.rc1.13
- Ship udev rules to allow libusb to access printer devices.
- Fixed duplex test pages (bug #514898, STR #3277).


libvirt-0.7.0-4.fc12

* Thu Aug 13 2009 Daniel P. Berrange  - 0.7.0-4
- Rewrite policykit support (rhbz #499970)
- Log and ignore NUMA topology problems (rhbz #506590)


virt-manager-0.8.0-2.fc12
-
* Thu Aug 13 2009 Daniel P. Berrange  - 0.8.0-2.fc12
- Remove obsolete dep on policykit agent


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 3
Broken deps for i386
--
389-ds-1.1.3-4.fc12.noarch requires 389-ds-admin
R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs
asterisk-fax-1.6.1-0.24.rc1.fc12.i686 requires libspandsp.so.1
bigboard-0.6.4-12.fc12.i686 requires mugshot >= 0:1.1.90-1
clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0
clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2
clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0
clutter-cairomm-devel-0.7.4-2.fc11.i586 requires 
pkgconfig(cluttermm-0.8)
clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8)
clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0
clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0
clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires 
pkgconfig(clutter-gtk-0.9)
cluttermm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0
cluttermm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-0.9)
dap-hdf4_handler-3.7.9-2.fc11.i586 requires libdap.so.9
dap-hdf4_handler-3.7.9-2.fc11.i586 requires libdapserver.so.6
entertainer-0.4.2-5.fc12.noarch requires pyclutter-cairo
octave-forge-20080831-10.fc12.i686 requires octave(api) = 0:api-v32
perl-DBIx-Class-Schema-Loader-0.04006-4.fc12.noarch requires 
perl(DBIX::Class)
php-layers-menu-3.2.0-0.2.rc.fc12.noarch requires 
php-pear(HTML_Template_PHPLIB)
plplot-octave-5.9.4-1.fc12.i586 requires octave(api) = 0:api-v32
ppl-yap-0.10.2-5.fc12.i686 requires libYap.so
python-repoze-what-quickstart-1.0-2.fc12.noarch requires 
python-repoze-who-plugins-sql
qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8
rubygem-main-2.8.4-3.fc12.noarch requires rubygem(fattr) >= 0:1.0.3
sems-1.1.1-2.fc12.i586 requires libspandsp.so.1
sems-g722-1.1.1-2.fc12.i586 requires libspandsp.so.1
sems-gsm-1.1.1-2.fc12.i586 requires libspandsp.so.1
sems-speex-1.1.1-2.fc12.i586 requires libspandsp.so.1
serpentine-0.9-5.fc12.noarch requires gnome-python2-nautilus-cd-burner
showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so
sugar-pippy-34-2.fc12.i686 requires libstdc++.so.6(CXXABI_1.3)(64bit)
sugar-pippy-34-2.fc12.i686 requires libc.so.6()(64bit)
sugar-pippy-34-2.fc12.i686 requires libgcc_s.so.1(GCC_3.0)(64bit)
sugar-pippy-34-2.fc12.i686 requires libm.so.6()(64bit)
sugar-pippy-34-2.fc12.i686 requires libm.so.6(GLIBC_2.2.5)(64bit)
sugar-pippy-34-2.fc12.i686 requires libstdc++.so.6()(64bit)
sugar-pippy-34-2.fc12.i686 requires libc.so.6(GLIBC_2.2.5)(64bit)
sugar-pippy-34-2.fc12.i686 requires libstdc++.so.6(GLIBCXX_3.4)(64bit)
sugar-pippy-34-2.fc12.i686 requires libgcc_s.so.1()(64bit)
thunderbird-lightning-1.0-0.8.20090513hg.fc12.i686 requires thunderbird 
< 0:3.0-3.6.b4



Broken deps for x86_64
--
389-ds-1.1.3-4.fc12.noarch requires 389-ds-admin
R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs
asterisk-fax-1.6.1-0.24.rc1.fc12.x86_64 requires 
libspandsp.so.1()(64bit)
bigboard-0.6.4-12.fc12.x86_64 requires mugshot >= 0:1.1.90-1
clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0
clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2
clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0
clutter-cairomm-0.7.4-2.fc11.x86_64 requires 
libclutter-cairo-0.8.so.0()(64bit)
clutter-cairomm-0.7.4-2.fc11.x86_64 requires 
lib

Re: Error while installing firefox from source build "cpio: MD5 sum mismatch"

[Harshavardhana]

Hi all,

 I have been trying to build firefox 3.0.13 on Fedora-10, i was
successfull in building it but during installation i end up with following
md5sum mismatch. This is happening continously with even fresh builds and i
don't have firefox installed also.


RegardsPreparing...
### [100%]
   1:firefox###
[100%]
error: unpacking of archive failed on file
/usr/lib64/firefox-3.0.13/firefox;4a854232: cpio: MD5 sum mismatch

Has any one seen this error? is there a way out?

I have also tried enabling the following parameters in my  rpm macros file.
But still after that a fresh build fails.

%_source_filedigest_algorithm   1
%_binary_filedigest_algorithm   1

Can any one give me few more pointers to debug this problem?. Thanks

Regards

--
Harshavardhana
Gluster - http://www.gluster.com
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Updates lacking descriptions

[Thomas Janssen]

2009/8/14 Ralf Corsepius :
> On 08/14/2009 07:32 AM, Jesse Keating wrote:
>> On Fri, 2009-08-14 at 05:41 +0200, Ralf Corsepius wrote:
>>> I strongly think Fedora would be better without Rahul and Kevin, two
>>> persons I have learned to be doing a good job on certain subjects, but
>>> to be a miscast on certain jobs and failure of the system in Fedora.
>>
>> I strongly feel that Fedora would be better without this negative
>> attitude, and the appearance that this kind of attitude is tolerated.

> First of all I do not consider my answers to be rude, but to be "open". OK,
> I might not always be using the correct wording (I am not a native English
> speaker) and phrases people from the US might consider "appropriate phrases"
> (German is a much direct language than US-English) - My appologies for that.

Erm.. I'm German as well, and what you wrote in this thread (and other
stuff you wrote on this list) *is* rude. Do not try to excuse your
behavior with "you're German". You do a lot of discredit to the other
Germans on this list with it.

-- 
LG Thomas

Dubium sapientiae initium

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 to require "i686", but which CPUs do not qualify?

[Andrew Haley]

Kevin Kofler wrote:
> Joachim wrote:
>> I do not understand then, that there exist i686 packages which have
>> higher requirements.
> 
> Those packages need to be fixed.
> 
> I know there are some audio production packages which are building with SSE 
> enabled (and required, those packages don't do runtime detection), IIRC in 
> both Fedora and RPM Fusion, in blatant violation of the guidelines, and the 
> packager(s) refuse(s) to fix this (they even do it intentionally for new 
> packages, despite my objections in the reviews). If I'm not mistaken, most 
> of the offenders are owned by oget (Orcan Ogetbil), but if I were you, I'd 
> check all the audio production packages.
> 
>> Look at the ATLAS library for which I had filed a bug because only
>> SSE/SSE2/SSE3 variants are provided
> 
> This one needs to get fixed too, of course.
> 
> I've looked at how Debian is handling this, but they're stuck at an old 
> version (3.6.0), maybe exactly because of this issue. :-(
> 
> We need to provide "architectural defaults" for plain i686, even crappy 
> ones, they just need to work at all.

I think there's a valid case for making an exception to this: when a
package is an accelerated version of a particular library.  That is,
when the basic functionality of a library is available in a i686
Fedora package, but a special SSEx version of the library makes use of
faster instructions.

Andrew.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)

[Peter Robinson]

On Thu, Jun 18, 2009 at 4:22 PM, Bill Nottingham wrote:
> Martin Langhoff (martin.langh...@gmail.com) said:
>> To note: it _is_ reported as a 586, so at least ancillary work in
>> yum/anaconda/rpm will be needed so that installing F12 on these
>> "supported but not quite 686 CPUs" is possible, avoiding the hackery
>> of installing it on a true 686 and then transferring the image to the
>> XO.
>
> diff --git a/rpmrc.in b/rpmrc.in
> index 4a6cca9..d62ddaf 100644
> --- a/rpmrc.in
> +++ b/rpmrc.in
> @@ -281,7 +281,7 @@ arch_compat: alphaev5: alpha
>  arch_compat: alpha: axp noarch
>
>  arch_compat: athlon: i686
> -arch_compat: geode: i586
> +arch_compat: geode: i686
>  arch_compat: pentium4: pentium3
>  arch_compat: pentium3: i686
>  arch_compat: i686: i586
>
> That should do the trick. :)

I've just been testing this with my Fit-PC geode box and it hasn't
made it into rawhide and hence doesn't work. I've filed a bug [1] and
added it to the alpha blocker as its a pretty large miss for the x86
recompile feature.

Peter

[1] https://bugzilla.redhat.com/show_bug.cgi?id=517475

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Cannot rely on /dev being present in %post scripts?

[Mike A. Harris]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

David Woodhouse wrote:
> According to bug #517013, %post scripts should not assume that /dev is
> available -- so we can't do anything that requires the existence of 
> /dev/null, /dev/urandom, etc.
> 
> Is this a known and expected packaging rule, or is it a bug in the way
> that the user is attempting to install the packages?

It's been pretty common since forever for various scriptlets to redirect
output of stderr/stdout to /dev/null, so I think it'd be a bit of an
ugly mess if there was a mandatory packaging rule you couldn't use at
least /dev/null

I hope post scripts wont have to test for /dev/null and create a device
node for it if it isn't present, before redirecting to it.  ;o)



- --
Mike A. Harris
http://mharris.ca  |  https://twitter.com/mikeaharris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFKhSxZ4RNf2rTIeUARAjPWAJ962g89WlN4q+rn92c+IR2rzft/9gCgoFHy
dOV7pNYrcGQPgIWIuvfenkU=
=nV29
-END PGP SIGNATURE-

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list