Re: PostgreSQL 9 for F14?

2010-09-26 Thread Devrim GÜNDÜZ 
On Mon, 2010-09-20 at 17:32 +0200, Michał Piotrowski wrote:
> 
> PostgreSQL 9 was released
> http://www.postgresql.org/about/news.1235
> 
> Are there any chances to get this for F14? 

Here comes the upstream packager. :)

I have done major rewrite in 9.0 spec file, and it now supports parallel
installation like Debian/Ubuntu does:

http://svn.pgrpms.org/browser/rpm/redhat/9.0/postgresql/F-13/postgresql-9.0.spec

I'm not sure whether Tom will use this new layout or not in Fedora
packages, but I can definitely say that upstream RPM repo will
definitely support F-14 once it goes stable.

Feel free to use that repo:

http://yum.pgrpms.org

which will hopefully turn into yum.postgresql.org over the next month or
so. This repo has more PG related packages as compared to Fedora.

-HTH

-- 
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
PostgreSQL RPM Repository: http://yum.pgrpms.org
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

2010-09-26 Thread charles zeitler 
Do what thou wilt
shall  be the whole  of the Law.

On Sun, Sep 26, 2010 at 10:04 PM, Gerald Henriksen  wrote:
> On Sun, 26 Sep 2010 15:33:25 +0200, you wrote:
>
>>On Sun, Sep 26, 2010 at 3:21 PM, Gerald Henriksen  wrote:
>>> On Sun, 26 Sep 2010 13:41:38 +0200, you wrote:
>>>
On Sat, Sep 25, 2010 at 10:02 PM, Kevin Fenzi  wrote:
> On Sat, 25 Sep 2010 15:53:49 -0400
> Brandon Lozza  wrote:
>
> What does matter to Fedora is having an updates policy that is
> designed to minimize disruption to users during a release is pointless
> if a significant part of Fedora - KDE - is going to be allowed to
> ignore the updates policy and deliberately introduce visible to the
> user changes in the middle of a release.
> of the projects.
>

hey, some of us look forward to disruptive
changes. ( even in mid-release)

-- 
charles zeitler




Love is the law, love under will.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

2010-09-26 Thread Gerald Henriksen 
On Sun, 26 Sep 2010 15:33:25 +0200, you wrote:

>On Sun, Sep 26, 2010 at 3:21 PM, Gerald Henriksen  wrote:
>> On Sun, 26 Sep 2010 13:41:38 +0200, you wrote:
>>
>>>On Sat, Sep 25, 2010 at 10:02 PM, Kevin Fenzi  wrote:
 On Sat, 25 Sep 2010 15:53:49 -0400
 Brandon Lozza  wrote:

> It would be nice to list it somewhere as an exception, to avoid
> panics :)

 Well, I personally do not want to say:

 "Hey, anytime you like down the road, you get an exception to push a
 new major version. Have fun".
>>>
>>>Well, reading FESCo meeting, it was that we're allowed to do one major
>>>update to Fn due to the different release-cycles of Fedora and KDE.
>>>Bad enough that we need "exceptions" to do our expected work and be
>>>able to be the working official KDE part of Fedora.
>>
>> Perhaps then you should approach KDE and ask them why they are so
>> distribution unfriendly with their release schedule.
>
>Why should they align the releases more with Fedora? Because Fedora is
>the #1 KDE distro? Think about it. KDE isn't distribution unfriendly.
>Fedora lately becomes KDE unfriendly. *Please* stop to rant, all the
>ranting becomes old quickly.

Perhaps you should read the part of my message you deleted, I never
said they should align their release with Fedora.

What I said was that KDE specifically goes out of their way to make it
difficult for the distributions to get the latest KDE release to the
KDE users by using a schedule that does not fit with *any* of the big
three distributions.

If the KDE project is concerned about getting their releases out to
their users in a timely manner then they should time their releases to
suit a distribution - whether it be openSUSE, Ubuntu, Fedora, or any
other distribution that makes them happy.

What does matter to Fedora is having an updates policy that is
designed to minimize disruption to users during a release is pointless
if a significant part of Fedora - KDE - is going to be allowed to
ignore the updates policy and deliberately introduce visible to the
user changes in the middle of a release.

How can Fedora market itself to potential users as a stable choice,
but at the same time warn that if you use either KDE or any of its
included programs then you can expect changes?

It can't.

And we already have proof of this with the message from the user who
won't update when a new version of Fedora is released, but instead
will wait until after the disruptive KDE update to (in his own words)
"avoid having important programs change under my feet when I'm not
prepared".

The updates policy has to be consistent across all of the projects
that make up Fedora, both to allow a consistent message to the users
(both current and prospective) of Fedora as well as to be fair to all
of the projects.

Do I want Fedora to change to bring some sanity to updates and stop
disruptive changes mid-release?  Yes.  But if FESCO, the Board, etc.
feels that allowing KDE or any other project to make changes
mid-release is important then fine, but just be consistent with the
message and treat all of the projects equally.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

2010-09-26 Thread Björn Persson 
Rex Dieter wrote:
> The kde-sig asked FESCo to consider up to 1 KDE version upgrade per
> release, and this was generally well-received during the last FESCo
> meeting, so no reason to panic.

That's good to hear. Then I think my strategy for the future will be to mostly 
stay on the next to latest release, and upgrade to the latest some time after 
it has had its KDE upgrade. That way it seems like I'll be able to avoid 
having important programs change under my feet when I'm not prepared, and 
still continuously receive bugfixes.

(I've been using Gnome since the KDE 4 chaos, but I still prefer Kate for 
programming, and Kmail is after all the least bad email program I've ever 
found, so those programs are quite important to me.)

Björn Persson


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 Beta corrupts user data

2010-09-26 Thread Sven Lankes 
On Sun, Sep 26, 2010 at 09:33:49PM +0200, Ralf Ertzinger wrote:

> Please forgive me for being confused, but isn't the default for Fedora
> to build with -O2?

The issue exists for code compiled with at least -O1 - so -O2 compiled
code is affected as well.

-- 
sven === jabber/xmpp: s...@lankes.net
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 Beta corrupts user data

2010-09-26 Thread Ralf Ertzinger 
Hi.

On Sun, 26 Sep 2010 10:40:22 -0700, John Reiser wrote

> Compiled code for minimum(), maximum(), etc. suffers from a compiler
> bug: https://bugzilla.redhat.com/show_bug.cgi?id=634757-O1
> wrong-code by cmove Unfortunately this bug can corrupt user data
> silently.

Please forgive me for being confused, but isn't the default for Fedora
to build with -O2?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 Beta corrupts user data

2010-09-26 Thread Kalev Lember 
On 09/26/2010 09:47 PM, Jan Kratochvil wrote:
> On Sun, 26 Sep 2010 20:41:04 +0200, Bruno Wolff III wrote:
>> On Sun, Sep 26, 2010 at 20:32:14 +0200, Jan 
>> Kratochvil  wrote:
>>> gcc-4.5.1-4.fc14: PASS
>>> gcc-4.5.1-3.fc14: FAIL
>>> gcc-4.5.1-2.fc14: There was no -2.
>>> gcc-4.5.1-1.fc14: PASS
>>
>> Does that mean the problem is restricted to packages built after
>> gcc-4.5.1-3.fc14 was built on September 7th?
>
> I do not have access to an easy query on Koji buildroots but if it is not
> obvious you can verify your build at least by:
> 

I made a crude script to figure out what packages might be affected. I'm
making the assumption that packages which don't have 'rtld(GNU_HASH)' in
rpm deps are not affected.

The script generates a list of packages which were built later than
gcc-4.5.1-3.fc14 and require 'rtld(GNU_HASH)'. The list is open ended as
the fixed -4 build doesn't appear to be in buildroots as I am typing this.

Caveats: packages which were built after gcc-4.5.1-3.fc14 and before it
got into buildroots are going to be listed as false positives; the
script will also miss packages which are not yet available in any
repositories.


# First affected GCC build
BUILD="http://kojipkgs.fedoraproject.org/packages/gcc/4.5.1/3.fc14/i686/cpp-4.5.1-3.fc14.i686.rpm";
# Get the time when it was built
BUILDTIME=$(rpm -qp $BUILD --qf '%{buildtime}')

# Query for packages which have been built later than the build above
repoquery --qf "%-50{sourcerpm} %{buildtime}" --disablerepo='*' 
--releasever=14 --enablerepo=fedora,updates-testing --whatrequires 
'rtld(GNU_HASH)' |
 awk "\$2 > $BUILDTIME" | sort | uniq | cut -f 1 -d ' ' | sed 
's/\.src\.rpm$//'


abiword-2.8.6-2.fc14
acpid-2.0.5-3.fc14
ale-0.9.0.3-2.fc14.1
alleggl-0.4.3-7.fc14
allegro-4.2.3-3.fc14
amarok-2.3.2-3.fc14
anaconda-14.17.4-1.fc14
apcupsd-3.14.8-2.fc14
apiextractor-0.8.0-1.fc14
arm-gp2x-linux-binutils-2.16.1-9.fc14
atanks-4.7-1.fc14
audacious-2.4.0-3.fc14
audacious-plugins-2.4.0-2.fc14
authconfig-6.1.9-1.fc14
autotrace-0.31.1-24.fc14.1
avr-gcc-4.5.1-1.fc14
avr-gcc-4.5.1-2.fc14
awn-extras-applets-0.4.0-24.fc14
banshee-1.7.4-2.fc14
bespin-0.1-0.2.20100909svn1228.fc14
bibletime-2.7.3-1.fc14
bind-9.7.2-1.fc14
bind-dyndb-ldap-0.1.0-0.13.b.fc14
bluefish-2.0.2-1.fc14
bluez-4.71-4.fc14
bluez-4.71-5.fc14
bro-1.5.1-1.fc14
bti-028-1.fc14
busybox-1.15.1-8.fc14
bzip2-1.0.6-1.fc14
bzr-2.2.1-2.fc14
cabextract-1.3-1.fc14
cairo-1.10.0-1.fc14
cairo-java-1.0.8-1.fc14
calf-0.0.18.6-1.fc14
calibre-0.7.18-3.fc14.1
ccache-3.1-1.fc14
celt-0.8.1-1.fc14
chktex-1.6.4-7.fc14
clanbomber-1.05-13.fc14
clutter-1.2.14-1.fc14
clutter-gtk-0.10.8-1.fc14
ConsoleKit-0.4.2-2.fc14
contacts-0.12-2.fc14
coolkey-1.1.0-17.fc14
couchdb-glib-0.6.96-1.fc14
creox-0.2.2-0.5.rc2.fc14
cstream-2.7.6-4.fc14
cups-1.4.4-10.fc14
curl-7.21.0-5.fc14
cyphesis-0.5.24-1.fc14
dates-0.4.11-7.fc14
dbusmenu-qt-0.6.3-1.fc14
devhelp-2.31.91-2.fc14
dmapd-0.0.25-3.fc14.1
dnsperf-1.0.1.0-20.fc14
dovecot-2.0.3-1.fc14
doxygen-1.7.1-2.fc14
dracut-modules-olpc-0.5.3-1.fc14
drawtiming-0.7.1-1.1.fc14.1
dspam-3.9.0-9.fc14
duplicity-0.6.09-1.fc14
dx-4.4.4-16.fc14.1
ebook-tools-0.2.0-1.fc14
ecryptfs-utils-83-8.fc14
ElectricFence-2.2.2-29.fc14
elfutils-0.149-1.fc14
EmfEngine-0.8-2.fc14
empathy-2.31.90-2.fc14
empathy-2.31.92-1.fc14
enscript-1.6.5.2-3.fc14
entangle-0.2.0-1.fc14
erlang-R14B-0.1.fc14
eruby-1.0.5-14.fc14
evince-2.31.92-2.fc14
evolution-2.31.92-1.fc14
evolution-data-server-2.31.92-1.fc14
evolution-exchange-2.31.92-1.fc14
evolution-mapi-0.31.92-1.fc14
evolution-rspam-0.1.1-1.fc14
fbreader-0.12.10-2.fc14
flowcanvas-0.6.4-1.fc14
fltk-1.1.10-2.fc14
folks-0.1.16-1.fc14
fontik-0.6-1.20100901git8dd5b9fe7.fc14
font-manager-0.5.6-1.fc14
frepple-0.8.1-1.fc14
f-spot-0.7.2-2.fc14
fuse-convmvfs-0.2.6-1.fc14
galeon-2.0.7-33.fc14
gcc-4.5.1-4.fc14
gcin-1.5.5-3.fc14
gdb-7.2-6.fc14
gdb-7.2-7.fc14
gdl-0.9-3.fc14
gdm-2.31.90-7.fc14
gedit-vala-0.10.2-1.fc14
generatorrunner-0.6.1-1.fc14
gettext-0.18.1.1-4.fc14
ghc-Boolean-0.0.1-1.fc14
ghc-gio-0.11.1-2.fc14.1
ghc-gio-0.11.1-2.fc14
ghc-glib-0.11.2-2.fc14
ghc-pango-0.11.2-2.fc14
ghc-terminfo-0.3.1.3-1.fc14
ghc-text-0.8.1.0-1.fc14
ghc-xmonad-contrib-0.9.1-7.fc14
ghostscript-8.71-16.fc14
git-1.7.3-2.fc14
gle-4.2.2-5.fc14
glibc-2.12.90-11
glib-java-0.4.2-1.fc14
glibmm24-2.24.2-1.fc14
gnome-chemistry-utils-0.12.3-4.fc14
gnome-commander-1.2.8.8-2.fc14
gnome-dvb-daemon-0.1.21-1.fc14
gnome-keyring-2.31.92-1.fc14
gnome-panel-2.31.90-4.fc14
gnome-python2-desktop-2.31.1-7.fc14
gnome-python2-extras-2.25.3-23.fc14
gnome-web-photo-0.9-13.fc14
gnumeric-1.10.10-1.fc14
gnupg2-2.0.16-3.fc14
grep-2.7-1.fc14
gretl-1.9.1-6.fc14
gssdp-0.8.0-1.fc14
gstreamer-plugins-bad-free-0.10.20-3.fc14
gtk2hs-buildtools-0.11.2-1.fc14
gtk+extra-2.1.2-3.fc14
gtkhtml3-3.31.92-1.fc14
gtkmm24-2.21.7-2.fc14
gupnp-0.14.0-1.fc14
gupnp-av-0.6.0-1.fc14
gupnp-dlna-0.3.1-1.fc14
gupnp-tools-0.8.1-1.fc14
gvfs-1.6.3-3.fc14
hal-0.5.14-4.fc14
hal-0.5.14-5.fc14
highlight-3.1-2.fc14
http-parser-0.3-2.20100911git.fc14
hydrogen-0.9.4.2-1

Re: Fedora 14 Beta corrupts user data

2010-09-26 Thread Jan Kratochvil 
On Sun, 26 Sep 2010 20:41:04 +0200, Bruno Wolff III wrote:
> On Sun, Sep 26, 2010 at 20:32:14 +0200, Jan Kratochvil 
>  wrote:
> > gcc-4.5.1-4.fc14: PASS
> > gcc-4.5.1-3.fc14: FAIL
> > gcc-4.5.1-2.fc14: There was no -2.
> > gcc-4.5.1-1.fc14: PASS
> 
> Does that mean the problem is restricted to packages built after
> gcc-4.5.1-3.fc14 was built on September 7th?

I do not have access to an easy query on Koji buildroots but if it is not
obvious you can verify your build at least by:

-> gdb-7.2-6.fc14
https://koji.fedoraproject.org/koji/buildinfo?buildID=195900
-> Task
https://koji.fedoraproject.org/koji/taskinfo?taskID=2474915
-> x86_64
https://koji.fedoraproject.org/koji/taskinfo?taskID=2474924
-> Buildroot
https://koji.fedoraproject.org/koji/buildrootinfo?buildrootID=887145
-> Component RPMs
https://koji.fedoraproject.org/koji/rpmlist?buildrootID=887145&type=component
-> gcc-4.5.1-3.fc14.x86_64.rpm


Regards,
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 Beta corrupts user data

2010-09-26 Thread Bruno Wolff III 
On Sun, Sep 26, 2010 at 20:32:14 +0200,
  Jan Kratochvil  wrote:
> On Sun, 26 Sep 2010 19:58:05 +0200, Bruno Wolff III wrote:
> > On Sun, Sep 26, 2010 at 10:40:22 -0700, John Reiser  
> > wrote:
> > > Compiled code for minimum(), maximum(), etc. suffers from a compiler bug:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=634757-O1 wrong-code by 
> > > cmove
> [...]
> > Do you know when the gcc bug was introduced?
> 
> gcc-4.5.1-4.fc14: PASS
> gcc-4.5.1-3.fc14: FAIL
> gcc-4.5.1-2.fc14: There was no -2.
> gcc-4.5.1-1.fc14: PASS

Does that mean the problem is restricted to packages built after
gcc-4.5.1-3.fc14 was built on September 7th?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 Beta corrupts user data

2010-09-26 Thread Jan Kratochvil 
On Sun, 26 Sep 2010 19:58:05 +0200, Bruno Wolff III wrote:
> On Sun, Sep 26, 2010 at 10:40:22 -0700, John Reiser  
> wrote:
> > Compiled code for minimum(), maximum(), etc. suffers from a compiler bug:
> > https://bugzilla.redhat.com/show_bug.cgi?id=634757-O1 wrong-code by 
> > cmove
[...]
> Do you know when the gcc bug was introduced?

gcc-4.5.1-4.fc14: PASS
gcc-4.5.1-3.fc14: FAIL
gcc-4.5.1-2.fc14: There was no -2.
gcc-4.5.1-1.fc14: PASS


Regards,
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 Beta corrupts user data

2010-09-26 Thread Bruno Wolff III 
On Sun, Sep 26, 2010 at 10:40:22 -0700,
  John Reiser  wrote:
> Compiled code for minimum(), maximum(), etc. suffers from a compiler bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=634757-O1 wrong-code by cmove
> Unfortunately this bug can corrupt user data silently.
> 
> I have hit the bug three times myself (bz 635508, 637303, 637461)
> and consider myself lucky that the bad effects were evident and ignorable.
> 
> A fix is in testing, and a critical path update has been approved:
> https://admin.fedoraproject.org/updates/gcc-4.5.1-4.fc14
> IMNSHO this will require a mass rebuild of all architecture-specific
> .fc14 .rpm.
> 
> Meanwhile, do not use Fedora 14 Beta on data that you value (e-mail,
> documents, database, etc.)  It really is that dangerous.

That's interesting. I just saw an odd regression in the httpd server after
updating from F13 to F14. It affects deflate. The F13 httpd server appears
to be based on the same upstream version, so it seemed odd. I'm adding a
pointer to the gcc issue from my bug report.

Do you know when the gcc bug was introduced?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 14 Beta corrupts user data

2010-09-26 Thread John Reiser 
Compiled code for minimum(), maximum(), etc. suffers from a compiler bug:
https://bugzilla.redhat.com/show_bug.cgi?id=634757-O1 wrong-code by cmove
Unfortunately this bug can corrupt user data silently.

I have hit the bug three times myself (bz 635508, 637303, 637461)
and consider myself lucky that the bad effects were evident and ignorable.

A fix is in testing, and a critical path update has been approved:
https://admin.fedoraproject.org/updates/gcc-4.5.1-4.fc14
IMNSHO this will require a mass rebuild of all architecture-specific
.fc14 .rpm.

Meanwhile, do not use Fedora 14 Beta on data that you value (e-mail,
documents, database, etc.)  It really is that dangerous.

-- 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Nautilus still no go in rawhide

2010-09-26 Thread darrell pfeifer 
On Sun, Sep 26, 2010 at 09:30, Tom London  wrote:

> On Sat, Sep 25, 2010 at 8:21 PM, darrell pfeifer 
> wrote:
> >
> >
> > On Sat, Sep 25, 2010 at 11:55, Owen Taylor  wrote:
> >>
> >> On Sat, 2010-09-25 at 14:04 -0400, Owen Taylor wrote:
> >>
> >> > > (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion
> >> > > `G_IS_OBJECT (object)' failed
> >> > > Segmentation fault (core dumped)
> >> >
> >> > There also seem to be problems with nautilus from GTK+ ABI changes - I
> >> > see various warnings along the lines of:
> >> >
> >> > (nautilus:27082): GLib-GObject-WARNING **: specified class size for
> type
> >> > `EvPropertiesView' is smaller than the parent type's `GtkVBox' class
> >> > size
> >> >
> >> > These indicate a definite need for rebuild, so I'll kick one off now,
> >> > and maybe things will be better after that finishes. It's certainly
> not
> >> > worth worrying about anything related to Nautilus until it's rebuild.
> >>
> >
> > The newer version still dies. It seemed to work for a while but segfaults
> > again. Also, sftp doesn't work any more.
> > Interestingly enough, it doesn't segfault under KDE.
> > darrell
> > --
>
> Does this sound like your segfaults:
> https://bugzilla.redhat.com/show_bug.cgi?id=636543
>
> I'm guessing that is some change in the gtk3 interface...
>
>
I haven't run a stack trace on mine, so I can't be sure.

Your guess might be accurate though. I also notice that chrome has been
segfaulting with annoying frequency which is strange because it has been
very stable for me.

darrell
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Nautilus still no go in rawhide

2010-09-26 Thread Tom London 
On Sat, Sep 25, 2010 at 8:21 PM, darrell pfeifer  wrote:
>
>
> On Sat, Sep 25, 2010 at 11:55, Owen Taylor  wrote:
>>
>> On Sat, 2010-09-25 at 14:04 -0400, Owen Taylor wrote:
>>
>> > > (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion
>> > > `G_IS_OBJECT (object)' failed
>> > > Segmentation fault (core dumped)
>> >
>> > There also seem to be problems with nautilus from GTK+ ABI changes - I
>> > see various warnings along the lines of:
>> >
>> > (nautilus:27082): GLib-GObject-WARNING **: specified class size for type
>> > `EvPropertiesView' is smaller than the parent type's `GtkVBox' class
>> > size
>> >
>> > These indicate a definite need for rebuild, so I'll kick one off now,
>> > and maybe things will be better after that finishes. It's certainly not
>> > worth worrying about anything related to Nautilus until it's rebuild.
>>
>
> The newer version still dies. It seemed to work for a while but segfaults
> again. Also, sftp doesn't work any more.
> Interestingly enough, it doesn't segfault under KDE.
> darrell
> --

Does this sound like your segfaults:
https://bugzilla.redhat.com/show_bug.cgi?id=636543

I'm guessing that is some change in the gtk3 interface...

tom
-- 
Tom London
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F-14 Branched report: 20100926 changes

2010-09-26 Thread Branched Report 
Compose started at Sun Sep 26 13:15:21 UTC 2010

Broken deps for x86_64
--
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libedata-book-1.2.so.2()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-1.2.so.17()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libgtkhtml-editor.so.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libebook-1.2.so.9()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-provider-1.2.so.17()(64bit)
evolution-sharp-0.21.1-9.fc14.x86_64 requires 
libcamel-1.2.so.19()(64bit)
frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10
frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
gnome-python2-evolution-2.31.1-5.fc14.x86_64 requires 
libcamel-1.2.so.19()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires 
libchamplain-gtk-0.4.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit)
intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples
libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10
libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit)
libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10
libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit)
libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10
libvte-java-0.12.1-15.fc12.x86_64 requires libgcj.so.10()(64bit)
matahari-0.0.5-1.fc14.x86_64 requires libqmf.so.1()(64bit)
mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires 
mingw32(libpng-3.dll)
ovirt-server-0.100-4.fc12.noarch requires qpidd
ovirt-server-0.100-4.fc12.noarch requires qpidc
php-pecl-imagick-3.0.0-7.fc14.x86_64 requires 
libMagickWand.so.3()(64bit)
php-pecl-imagick-3.0.0-7.fc14.x86_64 requires 
libMagickCore.so.3()(64bit)
plee-the-bear-0.4.1-5.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
plee-the-bear-0.4.1-5.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
plee-the-bear-0.4.1-5.fc14.x86_64 requires 
libboost_system-mt.so.1.41.0()(64bit)
qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires 
spacewalk-backend-libs >= 0:0.8.28
valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0
valide-0.6.1-0.22.20103003svn511.fc14.x86_64 requires 
libvala.so.0()(64bit)
viking-0.9.91-3.fc13.x86_64 requires libgps.so.18()(64bit)
wfut-1.1.0-8.fc12.x86_64 requires libgcj.so.10()(64bit)



Broken deps for i386
--
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
evolution-couchdb-0.4.92-1.fc14.i686 requires 
libcamel-provider-1.2.so.17
evolution-couchdb-0.4.92-1.fc14.i686 requires libebook-1.2.so.9
evolution-couchdb-0.4.92-1.fc14.i686 requires libgtkhtml-editor.so.0
evolution-couchdb-0.4.92-1.fc14.i686 requires libedata-book-1.2.so.2
evolution-couchdb-0.4.92-1.fc14.i686 requires libcamel-1.2.so.17
evolution-sharp-0.21.1-9.fc14.i686 requires libcamel-1.2.so.19
frysk-0.4-26.fc14.i386 requires libgcj.so.10
frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10
frysk-gnome-0.4-26.fc14.i386 requires libgcj.so.10
gnome-python2-evolution-2.31.1-5.fc14.i686 requires libcamel-1.2.so.19
gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-gtk-0.4.so.0
gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-0.4.so.0
intellij-idea-9.0.1.94.399-11.fc14.i686 requires jna-examples
libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10
libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10
libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10
matahari-0.0.5-1.fc14.i686 requires libqmf.so.1
mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires 
mingw32(libpng-3.dll)
ovirt-server-0.100-4.fc12.noarch requires qpidd
ovirt-server-0.100-4.fc12.noarch requires qpidc
php-pecl-imagick-3.0.0-7.fc14.i686 requires libMagickCore.so.3
php-pecl-imagick-3.0.0-7.fc14.i686 requires libMagickWand.so.3
plee-the-bear-0.4.1-5.fc14.i386 requires 
libboost_filesystem-mt.so.1.41.0
plee-the-bear-0.4.1-5.fc14.i386 requires libboost_system-mt.so.1.41.0
plee-the-bear-0.4.1-5.fc14.i386 requires libboost_thread-mt.so.1.41.0
qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18
spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires 
spacewalk-backend-libs >= 0:0.8.28
valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0

Re: Will make review for food (again).

2010-09-26 Thread Peter Robinson 
On Sun, Sep 26, 2010 at 12:00 PM, Peter Lemenkov  wrote:
> Hello All!
>
> I would like to exchange review requests - someone may pick up each of
> these three easy-to-review Erlang-related applications, and I will
> finish your stalled review request. One mine package for one yours -
> that's quite fair deal!
>
> Here is the list of my packages for trade:
>
> * https://bugzilla.redhat.com/632190 - erlang-amf - Erlang Action
> Message Format Library
> * https://bugzilla.redhat.com/632189 - erlang-misultin - Erlang
> library for building fast lightweight HTTP(S) servers
> * https://bugzilla.redhat.com/632186 - erlang-log4erl - A logger for
> erlang in the spirit of Log4J

I can do those, can you do the following (also fairly straight forward) reviews.

https://bugzilla.redhat.com/show_bug.cgi?id=628524
festival-freebsoft-utils - A collection of utilities that enhance
Festival with some useful features

https://bugzilla.redhat.com/show_bug.cgi?id=629247 MeeGo Panel for
display of current social information  (rename request)

https://bugzilla.redhat.com/show_bug.cgi?id=630782 MeeGo Panel for
launching Applications  (rename request)

Cheers,
Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

2010-09-26 Thread Brandon Lozza 
On Sun, Sep 26, 2010 at 9:21 AM, Gerald Henriksen  wrote:
> On Sun, 26 Sep 2010 13:41:38 +0200, you wrote:
>
>>On Sat, Sep 25, 2010 at 10:02 PM, Kevin Fenzi  wrote:
>>> On Sat, 25 Sep 2010 15:53:49 -0400
>>> Brandon Lozza  wrote:
>>>
 It would be nice to list it somewhere as an exception, to avoid
 panics :)
>>>
>>> Well, I personally do not want to say:
>>>
>>> "Hey, anytime you like down the road, you get an exception to push a
>>> new major version. Have fun".
>>
>>Well, reading FESCo meeting, it was that we're allowed to do one major
>>update to Fn due to the different release-cycles of Fedora and KDE.
>>Bad enough that we need "exceptions" to do our expected work and be
>>able to be the working official KDE part of Fedora.
>
> Perhaps then you should approach KDE and ask them why they are so
> distribution unfriendly with their release schedule.
>
> As far as I can tell (based on the 4.5 release date, scheduled 4.6
> release date, and the general objections raised by the Fedora KDE
> people) KDE is following a 6 month schedule, but timed such as it
> falls in the middle of the releases of the major biannual
> distributions, and doesn't fit the 8-month schedule of openSUSE at
> all.
>
> If KDE really wants to get their latest and greatest into the hands of
> their users as soon as possible then they should be more distribution
> friendly.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

Currently openSUSE is regarded as the KDE distro of choice if you want
the latest and i've been trying to change that because Fedora usually
has the latest upstream release. The difference between the two is
that openSUSE maintains two "stable" repositories and one has to be
manually installed, the other is default. With openSUSE 11.3 KDE 4.5
sat in a factory repo and then got pushed to release just last week
afaik. However users manually need to install the 4.5 repo, and they
manually have to switch from factory to the 4.5 release repo. Once 4.5
is pushed to F13, Fedora will once again be the most superior KDE
distro. Users don't have to manually upgrade. That's a huge +1

What I mean by better? Well every 6-8 months I test out different
distributions and see if its worth switching to another one. Over the
past year i've tried Arch, openSUSE, Mandriva, Kubuntu, Slackware and
PC-BSD 8.1, Gentoo, Calculate, Sidux, and more. The thing I noticed
most about these is a lot of them released with old versions of KDE. A
lot of them never bothered to update their users to the latest.
openSUSE is the best alternative to Fedora, for the reasons listed
above and its creeping past us. They were one of the first distros to
carry GCC 4.5 besides Arch. They are doing a lot of things I
considered made Fedora better than the rest. Not shipping stale
software, the use of delta rpms, shipping the latest kernel, gcc,
xorg, kde. If we can't at least keep up we can't be the BEST KDE
distro. We can't even share the title.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

2010-09-26 Thread Thomas Janssen 
On Sun, Sep 26, 2010 at 3:21 PM, Gerald Henriksen  wrote:
> On Sun, 26 Sep 2010 13:41:38 +0200, you wrote:
>
>>On Sat, Sep 25, 2010 at 10:02 PM, Kevin Fenzi  wrote:
>>> On Sat, 25 Sep 2010 15:53:49 -0400
>>> Brandon Lozza  wrote:
>>>
 It would be nice to list it somewhere as an exception, to avoid
 panics :)
>>>
>>> Well, I personally do not want to say:
>>>
>>> "Hey, anytime you like down the road, you get an exception to push a
>>> new major version. Have fun".
>>
>>Well, reading FESCo meeting, it was that we're allowed to do one major
>>update to Fn due to the different release-cycles of Fedora and KDE.
>>Bad enough that we need "exceptions" to do our expected work and be
>>able to be the working official KDE part of Fedora.
>
> Perhaps then you should approach KDE and ask them why they are so
> distribution unfriendly with their release schedule.

Why should they align the releases more with Fedora? Because Fedora is
the #1 KDE distro? Think about it. KDE isn't distribution unfriendly.
Fedora lately becomes KDE unfriendly. *Please* stop to rant, all the
ranting becomes old quickly.

-- 
Best regards
Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

2010-09-26 Thread Gerald Henriksen 
On Sun, 26 Sep 2010 13:41:38 +0200, you wrote:

>On Sat, Sep 25, 2010 at 10:02 PM, Kevin Fenzi  wrote:
>> On Sat, 25 Sep 2010 15:53:49 -0400
>> Brandon Lozza  wrote:
>>
>>> It would be nice to list it somewhere as an exception, to avoid
>>> panics :)
>>
>> Well, I personally do not want to say:
>>
>> "Hey, anytime you like down the road, you get an exception to push a
>> new major version. Have fun".
>
>Well, reading FESCo meeting, it was that we're allowed to do one major
>update to Fn due to the different release-cycles of Fedora and KDE.
>Bad enough that we need "exceptions" to do our expected work and be
>able to be the working official KDE part of Fedora.

Perhaps then you should approach KDE and ask them why they are so
distribution unfriendly with their release schedule.

As far as I can tell (based on the 4.5 release date, scheduled 4.6
release date, and the general objections raised by the Fedora KDE
people) KDE is following a 6 month schedule, but timed such as it
falls in the middle of the releases of the major biannual
distributions, and doesn't fit the 8-month schedule of openSUSE at
all.

If KDE really wants to get their latest and greatest into the hands of
their users as soon as possible then they should be more distribution
friendly.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

2010-09-26 Thread Thomas Janssen 
On Sun, Sep 26, 2010 at 2:30 PM, Gerald Henriksen  wrote:
> On Sat, 25 Sep 2010 22:26:46 -0400, you wrote:
>
>>I can't tell people Fedora is the best if it's not carrying the latest
>>upstream KDE, its just not possible. I'm constantly recruiting new
>>users. I'm in regular contact with the team of people who run
>>Techrights.
>>
>>If a new release of KDE comes out, this is what happens currently
>>
>>1) Kubuntu adds a backports PPA. Stable users do not get the latest KDE.
>>2) openSUSE will have it in their KDE Factory Repo, and it will turn
>>into a release Repo later (not stable). Stable users do not get the
>>latest KDE.
>>3) Mandriva will have official packages on kde.org but they aren't
>>pushed as updates. Stable users do not get the latest KDE.
>>4) Fedora will have it entirely unofficially as a third party repo for
>>a few weeks, it will also be in the official repo in updates-testing
>>and then in updates. Stable users DO get the latest KDE.
>>
>>This makes Fedora BETTER than the rest.
>
> For your particular definition of better, which does not necessarily
> agree with anyone elses defintion of better.

Since it agrees at least with my definition of better, you might keep
rhetoric stuff like that.

>> If we delegate the latest KDE
>>to backports like everyone else, how does that make Fedora better? And
>>we do want to be better than everyone else if we want to compete with
>>Apple and Microsoft.
>
> How does shipping out possiblity disruptive changes mid-release help
> us compete with anyone else?  Or make us better than anyone else?

You obviously want to re-read what he wrote, except you really can't
see the part with the competition and better (not saying that i think
we compete with Apple or Microsoft). BTW, speaking of "possibility
disruptive changes", you don't want to send out any update then, since
it *can* be "possibility disruptive changes". Plus, you will find
enough non-KDE updates disruptive in the past (past as in before right
now).

Maybe it fits here best as well, please keep rhetoric stuff like that,
because he has some points.

-- 
Best regards
Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

2010-09-26 Thread Gerald Henriksen 
On Sat, 25 Sep 2010 22:26:46 -0400, you wrote:

>I can't tell people Fedora is the best if it's not carrying the latest
>upstream KDE, its just not possible. I'm constantly recruiting new
>users. I'm in regular contact with the team of people who run
>Techrights.
>
>If a new release of KDE comes out, this is what happens currently
>
>1) Kubuntu adds a backports PPA. Stable users do not get the latest KDE.
>2) openSUSE will have it in their KDE Factory Repo, and it will turn
>into a release Repo later (not stable). Stable users do not get the
>latest KDE.
>3) Mandriva will have official packages on kde.org but they aren't
>pushed as updates. Stable users do not get the latest KDE.
>4) Fedora will have it entirely unofficially as a third party repo for
>a few weeks, it will also be in the official repo in updates-testing
>and then in updates. Stable users DO get the latest KDE.
>
>This makes Fedora BETTER than the rest.

For your particular definition of better, which does not necessarily
agree with anyone elses defintion of better.

> If we delegate the latest KDE
>to backports like everyone else, how does that make Fedora better? And
>we do want to be better than everyone else if we want to compete with
>Apple and Microsoft.

How does shipping out possiblity disruptive changes mid-release help
us compete with anyone else?  Or make us better than anyone else?

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20100926 changes

2010-09-26 Thread Rawhide Report 
Compose started at Sun Sep 26 08:15:43 UTC 2010

Broken deps for x86_64
--
ImageMagick-6.6.4.1-14.fc15.i686 requires libgs.so.8
ImageMagick-6.6.4.1-14.fc15.x86_64 requires libgs.so.8()(64bit)
almanah-0.7.3-3.fc14.x86_64 requires libedataserverui-1.2.so.10()(64bit)
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
claws-mail-plugins-geolocation-3.7.6-5.fc15.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 
0:1.3.0
clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) < 
0:1.3.0
clutter-gtkmm-0.9.5-1.fc14.i686 requires libclutter-gtk-0.10.so.0
clutter-gtkmm-0.9.5-1.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
clutter-gtkmm-devel-0.9.5-1.fc14.i686 requires 
pkgconfig(clutter-gtk-0.10) >= 0:0.10.2
clutter-gtkmm-devel-0.9.5-1.fc14.x86_64 requires 
pkgconfig(clutter-gtk-0.10) >= 0:0.10.2
emerillon-0.1.2-7.fc14.x86_64 requires librest-0.6.so.0()(64bit)
emerillon-0.1.2-7.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libedata-book-1.2.so.2()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-1.2.so.17()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libgtkhtml-editor.so.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libebook-1.2.so.9()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-provider-1.2.so.17()(64bit)
frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-devel-0.4-26.fc14.i386 requires libgtkjava-2.8.so
frysk-devel-0.4-26.fc14.i386 requires libglibjava-0.2.so
frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10
frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-devel-0.4-26.fc14.x86_64 requires libglibjava-0.2.so()(64bit)
frysk-devel-0.4-26.fc14.x86_64 requires libgtkjava-2.8.so()(64bit)
frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-gnome-0.4-26.fc14.x86_64 requires libglibjava-0.2.so()(64bit)
frysk-gnome-0.4-26.fc14.x86_64 requires libgtkjava-2.8.so()(64bit)
1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
gnome-python2-brasero-2.31.1-5.fc14.x86_64 requires 
libbrasero-media.so.1()(64bit)
gnome-python2-brasero-2.31.1-5.fc14.x86_64 requires 
libbrasero-burn.so.1()(64bit)
gnome-python2-totem-2.31.1-5.fc14.x86_64 requires 
libgnome-media-profiles.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires 
libchamplain-gtk-0.4.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit)
hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit)
intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples
libchamplain-gtk-0.6.1-4.fc14.i686 requires libclutter-gtk-0.10.so.0
libchamplain-gtk-0.6.1-4.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
libchamplain-gtk-devel-0.6.1-4.fc14.i686 requires 
pkgconfig(clutter-gtk-0.10)
libchamplain-gtk-devel-0.6.1-4.fc14.x86_64 requires 
pkgconfig(clutter-gtk-0.10)
1:libopensync-plugin-evolution2-0.22-6.fc14.x86_64 requires 
libedata-book-1.2.so.3()(64bit)
1:libopensync-plugin-evolution2-0.22-6.fc14.x86_64 requires 
libedata-cal-1.2.so.8()(64bit)
mail-notification-evolution-plugin-5.4-22.fc14.x86_64 requires 
libcamel-1.2.so.18()(64bit)
mail-notification-evolution-plugin-5.4-22.fc14.x86_64 requires 
libcamel-provider-1.2.so.18()(64bit)
meego-panel-devices-0.2.4-2.fc15.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
meego-panel-zones-0.2.0-0.1.fc15.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires 
mingw32(libpng-3.dll)
moblin-app-installer-0.4.0-0.9.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
moblin-panel-status-0.1.21-5.fc14.x86_64 requires 
libsocialweb-client.so.1()(64bit)
moblin-panel-status-0.1.21-5.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
ovirt-server-0.100-4.fc12.noarch requires qpidd
ovirt-server-0.100-4.fc12.noarch requires qpidc
pyclutter-gtk-0.10.0-2.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
spacewalk-certs-tools-1.1.1-2.1.fc15.noarch requires 
spacewalk-backend-libs >= 0:0.8.28
totem-2.90.5-5.fc15.i686 requires libpeasui-1.0.so.0
totem-2.90.5-5.fc15.x86_64 requires libpeasui-1.0.so.0()(64bit)
tracker-evolution-plugin-0.8.17-1.fc15.x86_64 requires 
libcamel-1.2.so.18()(64bit)

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

2010-09-26 Thread Thomas Janssen 
On Sat, Sep 25, 2010 at 10:02 PM, Kevin Fenzi  wrote:
> On Sat, 25 Sep 2010 15:53:49 -0400
> Brandon Lozza  wrote:
>
>> It would be nice to list it somewhere as an exception, to avoid
>> panics :)
>
> Well, I personally do not want to say:
>
> "Hey, anytime you like down the road, you get an exception to push a
> new major version. Have fun".

Well, reading FESCo meeting, it was that we're allowed to do one major
update to Fn due to the different release-cycles of Fedora and KDE.
Bad enough that we need "exceptions" to do our expected work and be
able to be the working official KDE part of Fedora.

> We still need to see what all is in the update, what the pros and cons
> are, etc.

Huh? And who of non-KDE FESCo members can decide what is pro or con in
a KDE update? Are we allowed to decide what is pro or con in a GNOME
update? Which would be the same here. No, the GNOME folks decide what
gets updated, as well as the XFCE or LXDE folks do, and that's as it
should be.

> I could add an example showing this however. :)
>
> Let me do that.

Now i'm curious.

-- 
Best regards
Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Will make review for food (again).

2010-09-26 Thread Peter Lemenkov 
Hello All!

I would like to exchange review requests - someone may pick up each of
these three easy-to-review Erlang-related applications, and I will
finish your stalled review request. One mine package for one yours -
that's quite fair deal!

Here is the list of my packages for trade:

* https://bugzilla.redhat.com/632190 - erlang-amf - Erlang Action
Message Format Library
* https://bugzilla.redhat.com/632189 - erlang-misultin - Erlang
library for building fast lightweight HTTP(S) servers
* https://bugzilla.redhat.com/632186 - erlang-log4erl - A logger for
erlang in the spirit of Log4J

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

kernel building instructions

2010-09-26 Thread Piscium 
This question is addressed at those with kernel building experience.

The Fedora wiki has instructions on building a custom kernel:
http://fedoraproject.org/wiki/Docs/CustomKernel

That's good, thanks.

Let's say that someone would like to build a kernel with different
configuration options. He or she has created a new .config file. The
relevant instructions are under the heading "Configure Kernel
Options". Instruction 6 says the following:

=
"Copy the config file to ~/rpmbuild/SOURCES/:
cp .config ~/rpmbuild/SOURCES/config-$arch"
=

The line above appears incorrect. This was recognized by another wiki
editor as can be seen in the following sentences:

=
"In actual fact, a Fedora 11 x86_64 machine would use the following
command, because the spec file has no config-x86_64 item, and so will
not process it. The only spec entry is for generic.
cp .config ~/rpmbuild/SOURCES/config-$arch-generic"
=

My question is this: what should be the name of the configuration file
for Intel 32 bits architecture?
config-x86 or
config-i386 or
config-i686 or
one of the above followed by "-generic"?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel