I am planning to push libnotify 0.7.0 into rawhide by the end of this
week; this is going to be a little painful, since there are some api
changes that will require minor adjustment of all users. And there's
quite a few of them (see below). I will hopefully be able to handle most
of the GNOME depen
[changing topic to split this out to it's own thread]
mån 2010-11-01 klockan 15:12 -0700 skrev Adam Williamson:
> > We also need some obvious ways where users in general can subscribe to
> > testing updates of stuff that they care about, to expand the userbase
> > that performs testing of updates
On Mon, Nov 1, 2010 at 10:32 PM, wrote:
> Fedora 14 Installation Guide have some mention about GRUB2
> but it is still not clear is anaconda capable to detect it.
> http://docs.fedoraproject.org/en-US/Fedora/14/html/Installation_Guide/s1-x86-bootloader.html
There is one reference to GRUB 2 to he
What can expect user that have system booting with GRUB2 and installing
Fedora? It is natural to expect that after Fedora installation will be
bootable both systems Fedora and other distro.
But if GRUB2 can not be detected there should be some kind of
warning about that. This is the reason why it
mån 2010-11-01 klockan 15:12 -0700 skrev Adam Williamson:
> This is a reasonable modification of the idea that an update should only
> require karma for one release (which would be nice if it were true but
> unfortunately isn't). In practice, though, there isn't much wiggle room
> for requiring 'l
On Mon, Nov 1, 2010 at 10:00 PM, wrote:
> There is nothing about GRUB2 in Installation Guide
I'm not sure why there would be an expectation that their would be.
Fedora doesn't use Grub2. There are many possible bootloaders that
could be on a system. Do we mention any of them by name anywhere?
We
On Mon, 2010-11-01 at 22:54 +0100, Henrik Nordström wrote:
> mån 2010-11-01 klockan 10:09 -0700 skrev Adam Williamson:
>
> > I disagree. The evidence you cite does not support this conclusion. We
> > implemented the policies for three releases. There are significant
> > problems with one release.
fre 2010-10-29 klockan 08:32 -0400 skrev James Antill:
> I don't think you need to display them, just display something that
> says "this is more than it seems" ... like ACLs. Something as simple as
> "-rwcr-xr-x." instead of "-rwsr-xr-x." for setuid.
I.e. kind of like what "ls --color" does?
R
Hi,
I was asked about problem with installing Fedora 13 on a machine
that is dual booting Windows 7 and another distro using GRUB2.
There is nothing about GRUB2 in Installation Guide
http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s1-x86-bootloader.html
"To add, remove, or c
mån 2010-11-01 klockan 10:09 -0700 skrev Adam Williamson:
> I disagree. The evidence you cite does not support this conclusion. We
> implemented the policies for three releases. There are significant
> problems with one release. This does not justify the conclusion that the
> policies should be en
Yeah, it looks like the capabilities thing has broken my buildsystem:
Error unpacking rpm package iputils-20101006-2.fc15.x86_64
error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file
failed - Operation not supported
Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x
On Mon, Nov 01, 2010 at 07:19:15PM +, Paul Howarth wrote:
> Any suggestions?
We've encountered some funny things about tmpfs before: It doesn't
support O_DIRECT at all, for example, necessitating workarounds in
libguestfs/qemu. Just speculating, but maybe it doesn't support
extended attribute
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=647783
Tom "spot" Callaway changed:
What|Removed |Added
---
On 11/1/2010 9:32, Jean-Francois Saucier wrote:
> I just put my package review template on my wiki space at :
> https://fedoraproject.org/wiki/User:Jfsaucier/Review_Template
[ ] SourceX is a working URL.
[ ] SourceX / PatchY prefixed with %{name}.
[ ] Final provides and requires are sane (rpm -
On Mon, 01 Nov 2010 11:04:09 -0400
Daniel J Walsh wrote:
> On 11/01/2010 09:44 AM, Paul Howarth wrote:
> > On 29/10/10 04:15, Jason L Tibbitts III wrote:
> >>> "JN" == Joe Nall writes:
> >>
> >> JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
> >>
> More to the point, I can e
On Mon, 01 Nov 2010 19:26:43 +0100
Kevin Kofler wrote:
> They also let several completely broken updates through and then
> delayed the FIXES for those updates, exactly as I had been warning
> about all the time.
Cite(s)?
>
> For example, my firstboot update which was required to make the Xfce
Adam Williamson wrote:
> I disagree. The evidence you cite does not support this conclusion. We
> implemented the policies for three releases. There are significant
> problems with one release. This does not justify the conclusion that the
> policies should be entirely repealed.
The evidence in TH
On Mon, Nov 1, 2010 at 9:12 AM, Jakub Jelinek wrote:
> -frecord-gcc-switches is unfortunately pretty much useless, see
> http://gcc.gnu.org/PR32998. Please don't add it, we want something actually
> usable, not this option.
Isn't it more useful in this state than not having the data at all? It
Adam Williamson wrote:
> The policies prevented us from shipping a number of completely broken
> updates, which is exactly what they were intended to do. I don't have a
> command handy to do a search for rejected proposed critpath updates for
> F14, but if you figure it out, you can see the precise
Adam Williamson wrote:
> On the other hand, other scenarios were also brought up, which have not
> come to pass - for instance, the same thing happening to Fedora 13 or
> Fedora 14.
Nonsense. We just do not have enough evidence yet to show such things
happening for F13 and F14. They CAN, and IMHO
Adam Williamson píše v Po 01. 11. 2010 v 10:55 -0700:
> On Mon, 2010-11-01 at 18:51 +0100, Miloslav Trmač wrote:
> > > Sorry, but characterizing it as a 'known problem' is misleading. It's
> > > easy to forecast failure, and you'll likely always be correct in *some*
> > > cases if you forecast eno
On Mon, 2010-11-01 at 18:51 +0100, Miloslav Trmač wrote:
> > Sorry, but characterizing it as a 'known problem' is misleading. It's
> > easy to forecast failure, and you'll likely always be correct in *some*
> > cases if you forecast enough failures. Only if you precisely forecast
> > only the fail
Adam Williamson píše v Po 01. 11. 2010 v 10:39 -0700:
> On Mon, 2010-11-01 at 18:29 +0100, Miloslav Trmač wrote:
> > > It's better to try things, with the proviso that
> > > you accept when they aren't working and withdraw or modify them.
> > It's even better not to dismiss known problems with the
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: perl-Term-ProgressBar is missing a dependency on perl-TermReadKey
https://bugzilla.redhat.com/show_bug.cgi?id=648598
Summary: perl-Term-ProgressBar is missing a
On Mon, 2010-11-01 at 18:29 +0100, Miloslav Trmač wrote:
> > On the other hand, other scenarios were also brought up, which have not
> > come to pass - for instance, the same thing happening to Fedora 13 or
> > Fedora 14. If we had simply accepted the predictions of doom and not
> > implemented th
Adam Williamson píše v Po 01. 11. 2010 v 10:08 -0700:
> > > We designed a policy,
> > > put it into effect, now we're observing how well it works and we can
> > > modify its implementation on the fly. It doesn't need to be done in an
> > > adversarial spirit.
> > Given that _this exact scenario_ w
On Mon, Nov 1, 2010 at 5:08 PM, Adam Williamson wrote:
> Saying 'oh dear, this might not work, we'd better not try' is rarely a
> good approach, IMHO. It's better to try things, with the proviso that
> you accept when they aren't working and withdraw or modify them.
I would agree with this, if th
On Mon, 2010-11-01 at 03:54 +0100, Kevin Kofler wrote:
> There's exactly one constructive thing to do, it's repealing this set of
> policies (Critical Path and Update Acceptance Criteria) in its entirety.
>
> An update should go stable when the maintainer says so, karma should be
> purely infor
On Mon, 2010-11-01 at 02:18 +0100, Miloslav Trmač wrote:
> > Kevin, could you *please* not word things like that? There's just no
> > need for it.
> >
> > I already wrote this to -test a couple of days ago:
> >
> > http://lists.fedoraproject.org/pipermail/test/2010-October/095135.html
> >
> > a
On Mon, 2010-11-01 at 15:58 +0100, Stanislav Ochotnicky wrote:
> > I plan to put up some scripts to automate part of the review process
> > as soon as I have the time to finish them.
Some time ago I put this together:
http://project.pingoured.fr/reviewHelper/
The idea here is of course not to do
>
> I plan to put up some scripts to automate part of the review process
> as soon as I have the time to finish them.
>
Great idea. I hacked a little script some time ago. It may be a little outdated
now, non optimally designed, but maybe something could be reused in your
project:
http://jskar
On Sun, 31 Oct 2010 10:16:41 -0400
"Clyde E. Kunkel" wrote:
> On 10/31/2010 03:18 AM, Michael Schwendt wrote:
> > Okay, feedback time.
> >
> > Lately, there have been several attempts at urging proventesters
> > (and not just testers in general) to give positive karma for aging
> > critpath updat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/01/2010 09:44 AM, Paul Howarth wrote:
> On 29/10/10 04:15, Jason L Tibbitts III wrote:
>>> "JN" == Joe Nall writes:
>>
>> JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
>>
More to the point, I can easily see the setuid bit
On 11/01/2010 03:32 PM, Jean-Francois Saucier wrote:
> Hi everyone,
>
> I just put my package review template on my wiki space at :
> https://fedoraproject.org/wiki/User:Jfsaucier/Review_Template
I created something similar specifically for Java reviews with Java SIG
members improving it bit by b
Hi everyone,
I just put my package review template on my wiki space at :
https://fedoraproject.org/wiki/User:Jfsaucier/Review_Template
My template is simply a collection based on other's already existing
template. What I did is I tried to put missing checks and sort them in
an order that should g
On Sun, 2010-10-31 at 15:07 -0400, Matt McCutchen wrote:
> On Wed, 2010-10-20 at 08:13 -0400, Daniel J Walsh wrote:
> > I have been trying to get system processes to stop using /tmp for years.
> >
> > http://danwalsh.livejournal.com/11467.html
> >
> > As some one who lives with polyinstatiated na
On 29/10/10 04:15, Jason L Tibbitts III wrote:
>> "JN" == Joe Nall writes:
>
> JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
>
>>> More to the point, I can easily see the setuid bit easily on a
>>> binary.
>>> How do I tell if these strange/hidden "capabilities" are
>>> present o
On Mon, Nov 01, 2010 at 09:04:12AM -0400, Tom "spot" Callaway wrote:
> On 10/30/2010 06:01 AM, Richard W.M. Jones wrote:
> > On Sat, Oct 30, 2010 at 02:24:02AM -0400, Jon Stanley wrote:
> >> I noticed on my Fedora 13 box that in the RPM macro %__global_cflags
> >> that -frecord-gcc-switches is miss
On Mon, Nov 1, 2010 at 9:04 AM, Tom "spot" Callaway wrote:
> On 10/30/2010 06:01 AM, Richard W.M. Jones wrote:
>> On Sat, Oct 30, 2010 at 02:24:02AM -0400, Jon Stanley wrote:
>>> I noticed on my Fedora 13 box that in the RPM macro %__global_cflags
>>> that -frecord-gcc-switches is missing, which i
On 10/30/2010 06:01 AM, Richard W.M. Jones wrote:
> On Sat, Oct 30, 2010 at 02:24:02AM -0400, Jon Stanley wrote:
>> I noticed on my Fedora 13 box that in the RPM macro %__global_cflags
>> that -frecord-gcc-switches is missing, which is a nifty compiler
>> feature that will record the flags passed t
On Tue, Oct 19, 2010 at 04:05:19PM +0100, Matthew Garrett wrote:
> On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote:
>
> > another benefit (not yet mentioned) is for filesystem encryption. I have /
> > and
> > /home encrypted and /usr not encrypted (for better performance of my la
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/31/2010 03:07 PM, Matt McCutchen wrote:
> On Wed, 2010-10-20 at 08:13 -0400, Daniel J Walsh wrote:
>> I have been trying to get system processes to stop using /tmp for years.
>>
>> http://danwalsh.livejournal.com/11467.html
>>
>> As some one who
Compose started at Mon Nov 1 08:15:05 UTC 2010
Broken deps for x86_64
--
1:anjuta-2.31.90.0-3.fc15.i686 requires libvala-0.10.so.0
1:anjuta-2.31.90.0-3.fc15.x86_64 requires libvala-0.10.so.0()(64bit)
apcupsd-3.14.8-3.
Does anybody know how to contact Chris Ricker (kaboom AT oobleck.net)?
https://bugzilla.redhat.com/show_bug.cgi?id=554334
https://bugzilla.redhat.com/show_bug.cgi?id=631825
and more
Jaroslav
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/deve
44 matches
Mail list logo
