Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=785680
--- Comment #3 from Richard W.M. Jones rjo...@redhat.com 2012-02-01 08:33:49
EST ---
This still fails:
Camlp4: Uncaught
On Sat, 2012-01-28 at 00:03 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
As far as I'm aware, Canonical were reasonably good about proposing the
libindicator patches for upstream inclusion, but many upstream projects
- especially those that are part of GNOME - weren't exactly rushing
On 01/31/2012 11:30 PM, James Antill wrote:
On Tue, 2012-01-31 at 15:58 -0500, Bill Nottingham wrote:
James Antill (ja...@fedoraproject.org) said:
[root@nostromo ~]# mv /bin /cow
[root@nostromo ~]# /cow/ln -s /cow /bin
[root@nostromo ~]# rpm -qf /cow/bash
bash-4.2.20-1.fc16.x86_64
On 02/01/2012 01:32 PM, Panu Matilainen wrote:
To-be-installed files obviously have no on-disk fingerprints, so it
wont work for initial installation. So yes, those fake compatibility
provides are needed. Strictly speaking, compatibility provides would
be needed for ALL the moved files, not
Once upon a time, Emanuel Rietveld codehot...@gmail.com said:
On 02/01/2012 01:32 PM, Panu Matilainen wrote:
To-be-installed files obviously have no on-disk fingerprints, so it
wont work for initial installation. So yes, those fake compatibility
provides are needed. Strictly speaking,
On 02/01/2012 09:41 AM, Chris Adams wrote:
Once upon a time, Emanuel Rietveld codehot...@gmail.com said:
On 02/01/2012 01:32 PM, Panu Matilainen wrote:
To-be-installed files obviously have no on-disk fingerprints, so it
wont work for initial installation. So yes, those fake compatibility
On 02/01/2012 04:41 PM, Chris Adams wrote:
Once upon a time, Emanuel Rietveldcodehot...@gmail.com said:
On 02/01/2012 01:32 PM, Panu Matilainen wrote:
To-be-installed files obviously have no on-disk fingerprints, so it
wont work for initial installation. So yes, those fake compatibility
Once upon a time, Genes MailLists li...@sapience.com said:
Just asking - does a bind mount of /bin instead of a soft link help?
That doesn't affect RPM database and yum metadata issues.
--
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak
On Tue, Jan 31, 2012 at 1:22 PM, Sven Baus s.bau...@gmx.net wrote:
Hello everybody,
I'm trying to build a trident package
(https://bugzilla.redhat.com/show_bug.cgi?id=771480) , because it is
needed by my main review request for tv-browser
(https://bugzilla.redhat.com/show_bug.cgi?id=754246)
You'll also need to BR eclipse-swt and add %{_libdir}/java/swt.jar to
the classpath. Also, set jdk.home in build.properties to something
reasonable, say /usr/lib/jvm/java. Regards,
There's a macro for the Java home, %{java_home}, set to
/usr/lib/jvm/java by the way.
--
devel mailing list
commit ca2b7d13c0716228c6e03f416ad6eac5ef4bee85
Author: Paul Howarth p...@city-fan.org
Date: Wed Feb 1 16:11:46 2012 +
Spec clean-up
- Run Perl::Critic test in %check too
- BR: perl(Test::Perl::Critic)
- BR: perl(Carp) and perl(Symbol), which might be dual-lived
-
Panu Matilainen (pmati...@laiskiainen.org) said:
To-be-installed files obviously have no on-disk fingerprints, so it
wont work for initial installation. So yes, those fake compatibility
provides are needed. Strictly speaking, compatibility provides would
be needed for ALL the moved files, not
Jerry James wrote:
On Tue, Jan 31, 2012 at 12:42 PM, Tom Callaway tcall...@redhat.com
wrote:
No, because xulrunner needs it to rebuild. Why is libvpx breaking
package builds? Almost nothing should depend on it. The plan is for the
libvpx update to go out at the same time as the xulrunner
Bastien Nocera wrote:
GNOME never gave an opinion on the spec, we gave an opinion on the
library, which was really just a huge pile of bugs (I know, they patched
a bunch of the applications I maintain, and I get to receive a large
number of crashers because of it).
But I don't see any
Florian Müllner wrote:
I can not comment on the quality of the library, but GNOME did comment
on the spec[0] (or rather: several gnomers did) - there were a couple of
objections, none of which have been addressed in the spec as far as I
can tell.
The objections weren't addressed because they
On 02/01/2012 06:38 PM, Bill Nottingham wrote:
Panu Matilainen (pmati...@laiskiainen.org) said:
To-be-installed files obviously have no on-disk fingerprints, so it
wont work for initial installation. So yes, those fake compatibility
provides are needed. Strictly speaking, compatibility provides
On Wed, 2012-02-01 at 18:03 +0100, Kevin Kofler wrote:
Bastien Nocera wrote:
GNOME never gave an opinion on the spec, we gave an opinion on the
library, which was really just a huge pile of bugs (I know, they patched
a bunch of the applications I maintain, and I get to receive a large
Matthias Clasen wrote:
After the fruitless discussion on xdg-list, we decided that the spec was
not going to help us in implementing the desired user experience.
That's not up to you to decide. The spec is a cross-desktop spec already
implemented by KDE Plasma and Unity. Sometimes you have to
https://fedorahosted.org/389/attachment/ticket/55
https://fedorahosted.org/389/attachment/ticket/55/0001-Ticket-55-Limit-of-1024-characters-for-nsMatchingRul.patch
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
On Sat, 2012-01-28 at 00:03 +0100, Kevin Kofler wrote:
That's really GNOME's fault. :-( Canonical explicitly designed
libappindicator (which is the library applications are expected to use, it
uses libindicator behind the scenes; there's also libindicate which is for
communication apps to
On 01/31/2012 04:27 PM, Emmanuel Seyman wrote:
* Przemek Klosowski [31/01/2012 00:37] :
To solve that, I'd be nice if there was a way to roll over an EOL
version into an appropriate release of one of the
long-term-supported systems such as RHEL, Centos or Scientific
Linux.
This would be a
On Wed, Feb 01, 2012 at 13:20:58 -0500,
Przemek Klosowski przemek.klosow...@nist.gov wrote:
Precisely---but lack of the EOL path sometimes prevents use of
Fedora in the first place. Jon Vos said elsewhere in this discussion
that Fedora is not for long term if updates/security are an issue.
On mié, 2012-02-01 at 18:25 +0100, Kevin Kofler wrote:
The objections weren't addressed because they objected to the very point of
the spec, making it impossible to address them without defeating the purpose
of the spec.
One main design goal of the spec was that it should NOT be the app's
2012/2/1 Bruno Wolff III br...@wolff.to:
A lot of people need to step up and do the work. So far no one has been
able to successfully organize a group to do it. And given Fedora is more
likely
to attract people who want to run the latest and (hopefully) greatest stuff,
I would expect finding
A file has been added to the lookaside cache for perl-Net-STOMP-Client:
5b9a13ba8383ac33bcf3e16eeea6a44d Net-STOMP-Client-1.4.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
0001-fix-a-couple-of-minor-coverity-issues.patch
Description: application/mbox
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
Outage: buildsystem and pkgs - 2012-02-02 03:00 UTC
There will be an outage starting at 2012-02-02 03:00 UTC, which will
last approximately 1 hour.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2012-02-02 03:00
On 02/01/2012 01:56 PM, Rich Megginson wrote:
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
ack
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
https://fedorahosted.org/389/ticket/87
https://fedorahosted.org/389/attachment/ticket/87/0001-Ticket-87-Manpages-fixes.patch
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
On Wed, Feb 01, 2012 at 06:25:05PM +0100, Kevin Kofler wrote:
The objections weren't addressed because they objected to the very point of
the spec, making it impossible to address them without defeating the purpose
of the spec.
A spec that allows two conformant implementations to differ to
Neither package has built since F15, and while there's a new patchset
to apply, I don't quite have time to get it to work. Unless someone
wants to get them to build, or take ownership, I'll retire them
Friday, 2/3.
Thanks,
--
in your fear, seek only peace
in your fear, seek only love
-d.
* Przemek Klosowski [01/02/2012 19:58] :
I am just trying to explore if there's a way around that.
The answer is the same on this subject and the rolling release:
You need to get a group together, put together a set of specifications
that everybody agrees on and start working on making it
On 02/01/2012 04:28 PM, Rich Megginson wrote:
On 02/01/2012 02:16 PM, Mark Reynolds wrote:
Hi Everyone,
There is an issue with the PAM plugin, that when it performs a
successful bind we actually return error 1 to plugins_call_func(),
which essentially causes the abort of the all plugin
On mié, 2012-02-01 at 22:18 +0100, Kevin Kofler wrote:
So the argument that you're refusing to implement a cross-desktop protocol
in order to ban random applications from adding themselves to the panel is
bogus.
No, the argument for refusing to implement the protocol is that the spec
is bad.
(comaintainers bcc'd)
Each release, before branching, we block currently orphaned packages.
It's that time again for Fedora 17.
New this go-round is that we are also blocking packages that have
failed to build since before Fedora 15.
The following packages are currently orphaned, or fail to
On 02/01/2012 02:48 PM, Mark Reynolds wrote:
On 02/01/2012 04:28 PM, Rich Megginson wrote:
On 02/01/2012 02:16 PM, Mark Reynolds wrote:
Hi Everyone,
There is an issue with the PAM plugin, that when it performs a
successful bind we actually return error 1 to plugins_call_func(),
which
Matthew Garrett wrote:
A spec that allows two conformant implementations to differ to such a
degree that it's impossible for an application to work sensibly in both
implementations is a *bad* *spec*. The only argument anyone had against
that was Oh, nobody would implement the spec in that way,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/01/2012 12:49 PM, Kevin Kofler wrote:
Daniel J Walsh wrote:
Yes we have shipped a policy that requires the usrmove
functionality.
How many times do we have to tell you that you MUST build usrmove
stuff in the f17-usrmove build target, NOT
On Wed, Feb 1, 2012 at 14:16, Daniel J Walsh dwa...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
But as long as we live in the Rawhide/Non Rawhide world things are
going to be strange and mistakes are going to happen.
Why anyone is on Rawhide and not trying out usrmove
drago01 wrote:
On Wed, Feb 1, 2012 at 10:18 PM, Kevin Kofler kevin.kof...@chello.at
wrote:
Florian Müllner wrote:
I don't think anyone made an argument for letting apps decide how
exactly the icon will look (which is basically what XEmbed does, and
everyone agrees that it's crap), but
On Wed, 2012-02-01 at 18:45 +0100, Kevin Kofler wrote:
Kevin Fenzi wrote:
The only way is to revert the usrmove commit, then make your
change/build.
Actually, last I checked, it was possible to create a git branch off the
last commit before the stuff you don't want (i.e. the last commit
On 2012-02-01 14:49, Florian Müllner wrote:
Except that applications can set a 'resident' hint on notifications,
in
which case a representive icon is kept in the message tray, from
which
the notification can be recalled; together with the ability to
provide
actions on notifications, the
On 2012-02-01 15:16, Daniel J Walsh wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/01/2012 12:49 PM, Kevin Kofler wrote:
Daniel J Walsh wrote:
Yes we have shipped a policy that requires the usrmove
functionality.
How many times do we have to tell you that you MUST build usrmove
Florian Müllner wrote:
No, the argument for refusing to implement the protocol is that the spec
is bad. I was merely pointing out that *if* we used the protocol in the
top bar, it would have been as an implementation detail with no benefit
to applications (e.g. no way for applications to
I'll note here a nice Help wanted...
If you have access to RHEL6 (or I suppose any of the binary compatible
variants) and some time:
rel-eng is looking for some quick regression testing of the rpm change
in https://bugzilla.redhat.com/show_bug.cgi?id=761000 to make sure it
doesn't break in any
FESCo recently made an adjustment to the updates policy to no longer require
proventester karma for a critical path update to be deemed as stable.
Critical path updates will now require just one regular +1 karma vote during
the pre-beta phase and two regular +1 karma votes in other phases to be
Florian Müllner wrote:
No, but it would require that circle is drawn as circle and not a
square (or just discarded without notice). The NotifyIcon spec
explicitly allows either absurdity.
If your icon theme thinks a square is a good way to represent the concept of
a circle, that's an issue
Matthew Garrett wrote:
I'm on multiple spec bodies. If someone proposed an ammendment that
allowed two conforming implementations to be entirely incompatible, and
then argued that this was future proofing, they'd be laughed at.
The constraints actually relevant for compatibility are all
On Thu, Feb 02, 2012 at 01:51:55AM +0100, Kevin Kofler wrote:
Matthew Garrett wrote:
I'm on multiple spec bodies. If someone proposed an ammendment that
allowed two conforming implementations to be entirely incompatible, and
then argued that this was future proofing, they'd be laughed at.
A note for all: bind-9.9.0-0.7.rc2.fc17 , which was built for Rawhide
today, bumps the soname of at least /usr/lib64/libdns-export (from 92 to
93), but this API compatibility change wasn't announced. Best check if
any package you own that depends on bind is affected and needs a
rebuild.
It looks
Matthew Garrett wrote:
It can be completely unusable. There's no way to design an application
that will work with all valid implementations.
Sure there is. Just provide the data and let the implementation worry about
how it is displayed.
Yes, but it's not about visual uniformity. It's about
On Wed, 2012-02-01 at 17:19 -0800, Adam Williamson wrote:
A note for all: bind-9.9.0-0.7.rc2.fc17 , which was built for Rawhide
today, bumps the soname of at least /usr/lib64/libdns-export (from 92 to
93), but this API compatibility change wasn't announced. Best check if
any package you own
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/02/2012 01:19 AM, Luke Macken wrote:
FESCo recently made an adjustment to the updates policy to no
longer require proventester karma for a critical path update to be
deemed as stable.
Critical path updates will now require just one regular
On Thu, 2012-02-02 at 02:58 +0100, Michel Alexandre Salim wrote:
On 02/02/2012 01:19 AM, Luke Macken wrote:
FESCo recently made an adjustment to the updates policy to no
longer require proventester karma for a critical path update to be
deemed as stable.
Critical path updates will now
On Thu, Feb 02, 2012 at 02:21:01AM +0100, Kevin Kofler wrote:
If you think the version as written does not guarantee interoperability, why
don't YOU propose a version which you think does?
Because it is the job of people who are proposing a spec to answer the
objections of the people who
On 02/01/2012 05:00 PM, Adam Williamson wrote:
On 2012-02-01 11:39, Florian Müllner wrote:
Because the integrated experience means that there is a fixed set of
system items with a defined order. Extensions can be used to hack the
intended experience (which includes adding non-official icons in
On 02/01/2012 12:24 PM, Jerry James wrote:
Yes, the buildroots are both fine now. Thanks for fixing them. I was
just responding to spot's apparent surprise that an updated libvpx in
the buildroot should have broken package building for other people.
Indeed, I'm a little horrified at how deep
Adam Williamson wrote:
We'll keep it around, but I'll update the wiki pages to note that it's
kinda 'dormant' for now. I'm hoping that with Bodhi 2.0 we'll be able to
re-design the process and utilize proventesters in a better way.
How about just requiring 1 proventester +1 *or* 2 regular +1s
Matthew Garrett wrote:
Because it is the job of people who are proposing a spec to answer the
objections of the people who perform critical analysis of the spec
They did answer. You just didn't like their answer.
It's the GNOME developers who stopped replying. The KDE developers were
willing
On Wed, 01 Feb 2012 17:00:30 -0700
Adam Williamson awill...@redhat.com wrote:
I realize this isn't a very constructive mail, and the point has been
raised before, but I'm hoping at some point the sheer weight of
complaints will cause someone more creative than myself to actually
come up with
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=786085
--- Comment #4 from Iain Arnell iarn...@gmail.com 2012-02-01 05:41:09 EST ---
Those warnings seem to be innocuous.
But I have
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=786085
Petr Pisar ppi...@redhat.com changed:
What|Removed |Added
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=786085
--- Comment #5 from Petr Pisar ppi...@redhat.com 2012-02-01 07:44:35 EST ---
Created attachment 558816
--
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=786085
--- Comment #6 from Petr Pisar ppi...@redhat.com 2012-02-01 07:48:59 EST ---
Created attachment 558817
--
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=786085
--- Comment #7 from Petr Pisar ppi...@redhat.com 2012-02-01 07:52:52 EST ---
You are right, the warnings are just warnings.
commit 6038d16e5db6397aaebb8a7872547276f5efe10a
Author: Steve Traylen steve.tray...@cern.ch
Date: Wed Feb 1 22:06:31 2012 +0100
New upstream 1.4, rhbz#785732
Add BR Messaging::Message, Test::Pod and Test::Pod::Coverage to
execute new tests.
.gitignore |1 +
The unsigned tag 'perl-Net-STOMP-Client-1.4-1.fc17' was created.
Tagger: Steve Traylen steve.tray...@cern.ch
Date: Wed Feb 1 22:07:05 2012 +0100
New upstream 1.4, rhbz#785732
Add BR Messaging::Message, Test::Pod and Test::Pod::Coverage to
execute new tests.
Changes since the last
Summary of changes:
da525a7... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*)
6038d16... New upstream 1.4, rhbz#785732 Add BR Messaging::Message, Te (*)
(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
The unsigned tag 'perl-Net-STOMP-Client-1.4-1.fc16' was created.
Tagger: Steve Traylen steve.tray...@cern.ch
Date: Wed Feb 1 22:09:31 2012 +0100
New upstream 1.4, rhbz#785732
Add BR Messaging::Message, Test::Pod and Test::Pod::Coverage to
execute new tests.
Changes since the last
Summary of changes:
da525a7... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*)
6038d16... New upstream 1.4, rhbz#785732 Add BR Messaging::Message, Te (*)
1b69684... Merge branch 'master' into el6
(*) This commit already existed in another branch; no separate mail sent
--
The unsigned tag 'perl-Net-STOMP-Client-1.4-1.el6' was created.
Tagger: Steve Traylen steve.tray...@cern.ch
Date: Wed Feb 1 22:10:00 2012 +0100
New upstream 1.4, rhbz#785732
Add BR Messaging::Message, Test::Pod and Test::Pod::Coverage to
execute new tests.
Changes since the last tag
commit 1b6968491283a5d3357c093d6ef42edd8b69b811
Merge: 2872a90 6038d16
Author: Steve Traylen steve.tray...@cern.ch
Date: Wed Feb 1 22:09:52 2012 +0100
Merge branch 'master' into el6
.gitignore |1 +
perl-Net-STOMP-Client.spec | 14 +-
sources
Summary of changes:
da525a7... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*)
6038d16... New upstream 1.4, rhbz#785732 Add BR Messaging::Message, Te (*)
f3fb506... Merge branch 'master' into el5
(*) This commit already existed in another branch; no separate mail sent
--
commit f3fb5068ed1e017ef98aa345c2056bd895ce19fe
Merge: 444cc71 6038d16
Author: Steve Traylen steve.tray...@cern.ch
Date: Wed Feb 1 22:10:22 2012 +0100
Merge branch 'master' into el5
.gitignore |1 +
perl-Net-STOMP-Client.spec | 14 +-
sources
The unsigned tag 'perl-Net-STOMP-Client-1.4-1.el5' was created.
Tagger: Steve Traylen steve.tray...@cern.ch
Date: Wed Feb 1 22:10:29 2012 +0100
New upstream 1.4, rhbz#785732
Add BR Messaging::Message, Test::Pod and Test::Pod::Coverage to
execute new tests.
Changes since the last tag
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=785732
--- Comment #1 from Fedora Update System upda...@fedoraproject.org 2012-02-01
15:40:09 EST ---
perl-Net-STOMP-Client-1.4-1.fc16
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=785732
--- Comment #2 from Fedora Update System upda...@fedoraproject.org 2012-02-01
15:40:17 EST ---
perl-Net-STOMP-Client-1.4-1.el6
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=785732
--- Comment #3 from Fedora Update System upda...@fedoraproject.org 2012-02-01
16:00:36 EST ---
perl-Net-STOMP-Client-1.4-1.el5
https://fedorahosted.org/389/ticket/13
https://fedorahosted.org/389/attachment/ticket/13/0001-Ticket-13-slapd-process-exits-when-put-the-database-.patch
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
Hi Everyone,
There is an issue with the PAM plugin, that when it performs a
successful bind we actually return error 1 to plugins_call_func(), which
essentially causes the abort of the all plugin processing: the rest of
pre-op, the backend call, and all of post-op. PAM has completed the
On 02/01/2012 02:16 PM, Mark Reynolds wrote:
Hi Everyone,
There is an issue with the PAM plugin, that when it performs a
successful bind we actually return error 1 to plugins_call_func(),
which essentially causes the abort of the all plugin processing: the
rest of pre-op, the backend call,
https://fedorahosted.org/389/attachment/ticket/39
https://fedorahosted.org/389/attachment/ticket/39/0001-Ticket-39-Account-Policy-Plugin-does-not-work-for-si.patch
Thanks,
Mark
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
FESCo recently made an adjustment to the updates policy to no longer require
proventester karma for a critical path update to be deemed as stable.
Critical path updates will now require just one regular +1 karma vote during
the pre-beta phase and two regular +1 karma votes in other phases to be
83 matches
Mail list logo
