On Wed, 01 Feb 2012 17:00:30 -0700
Adam Williamson 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 a notification
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
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 +1
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 de
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" ico
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 pe
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
-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 reg
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
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 abou
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 l
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
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 spec
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 is
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 pu
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 an
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 p
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
s
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 exper
On Wed, 2012-02-01 at 17:00 -0700, 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
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
the
top bar), but it's nothing we want
On Wed, Feb 01, 2012 at 11:00:52PM +0100, Kevin Kofler wrote:
> 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 anyon
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
drago01 wrote:
> On Wed, Feb 1, 2012 at 10:18 PM, Kevin Kofler
> 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 rather to avo
commit bea7f42782c4cf86f9125e310d9f30822de4b25b
Author: Emmanuel Seyman
Date: Thu Feb 2 00:38:36 2012 +0100
Clean up spec file and add perl default filter
perl-Fedora-Bugzilla.spec | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
---
diff --git a/perl-Fedora-Bugzi
On Wed, Feb 1, 2012 at 14:16, Daniel J Walsh 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 is beyond
On mié, 2012-02-01 at 23:00 +0100, Kevin Kofler wrote:
> Are you going to require a spec on drawing circles to specify that the
> circumference of the circle must be between 355/113-2^-21 and 355/113
> times its diameter?
No, but it would require that "circle" is drawn as circle and not a
square
-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 targ
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
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 essenti
(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 buil
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 ba
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 proces
On Wed, Feb 1, 2012 at 10:18 PM, Kevin Kofler 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 rather to avoid the other extreme
>>
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 rather to avoid the other extreme
> of giving the shell complete power of what to display (and e
* 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 happ
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. bowie
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 t
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 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
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 UTC'
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
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
https://admin.fedoraproject.
2012/2/1 Bruno Wolff III :
> 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 lot of
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 ap
On Wed, Feb 01, 2012 at 13:20:58 -0500,
Przemek Klosowski 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.
> Period."
>
> I am j
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 mas
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
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
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
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 in f17(-candidate)???
This is already the third time somebody else cleans up your mess! (Rex
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
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 before the
usrmove commit in this case) and then build from
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 provide
Przemek Klosowski wrote:
> The downgrades would actually be better than having an unsupported
> system that doesn't get any updates ever. The assumption here is that
> the downgrades aren't introducing any security or fundamental
> functionality issues--hopefully, 'long term support' means that the
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 th
On Wed, Feb 1, 2012 at 9:46 AM, Rex Dieter wrote:
> Jerry James wrote:
>
>> On Tue, Jan 31, 2012 at 12:42 PM, Tom Callaway
>> 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
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 move
The lightweight tag 'perl-Package-Generator-0.103-8.fc17' was created pointing
to:
ca2b7d1... Spec clean-up
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/per
Jerry James wrote:
> On Tue, Jan 31, 2012 at 12:42 PM, Tom Callaway
> 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 update.
>
> So
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
commit ca2b7d13c0716228c6e03f416ad6eac5ef4bee85
Author: Paul Howarth
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
- Use DESTDIR rather
> 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
d
On Tue, Jan 31, 2012 at 1:22 PM, Sven Baus 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)
>
> I ran i
Once upon a time, Genes MailLists 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
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's eno
On 02/01/2012 04:41 PM, Chris Adams wrote:
Once upon a time, Emanuel Rietveld 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. Str
On 02/01/2012 09:41 AM, Chris Adams wrote:
> Once upon a time, Emanuel Rietveld 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
Once upon a time, Emanuel Rietveld 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, compatibility prov
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 j
On mié, 2012-02-01 at 12:01 +, 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 becaus
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
[root@nostrom
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 rus
Le Mar 31 janvier 2012 21:32, James Antill a écrit :
> Also, even if someone could fix rpm to work this out, making this work
> at the yum layer is _much_ harder ... because the repodata does not
> currently specify that /path/to/blah is a regular file or a symlink (and
> if it's a symlink, what
73 matches
Mail list logo
