On Sun, Jun 09, 2013 at 04:55:40PM -0400, Doug Ledford wrote:
> I would never encourage it in terms of suggesting people try to second
> guess the kernel's rules and limitations. However, you can use such a
> technique to weed out otherwise known to fail cases, at least in
> instances like this w
On Dom, 2013-06-09 at 13:02 +0300, Oron Peled wrote:
> Some progress...
>
>
>
> On Saturday 08 June 2013 10:47:21 Sérgio Basto wrote:
>
> > > I'm going , if no problem, begin F18 cycle
>
> > > build this 7 packages:
>
> > > dpkg
>
>
>
> This is what debhelper is waiting for
>
>
>
> >
On 06/09/2013 11:42 AM, Matthew Garrett wrote:
> On Sun, Jun 09, 2013 at 11:05:44AM -0400, Doug Ledford wrote:
>
>> And really, we've spent more time on this thread than it would take
>> Lennart to fix PA. Just a quick stat and check of uid before trying to
>> remove the stale files and this woul
On 06/09/2013 01:05 PM, Adam Williamson wrote:
> On Sun, 2013-06-09 at 16:44 +0200, Reindl Harald wrote:
>
>> where did you read this?
>
> Where Doug et al keep not responding to Lennart and Matthew's queries as
> to whether the correct fix is to the app or to the audit system, but
> keep repeati
On Sun, 2013-06-09 at 16:44 +0200, Reindl Harald wrote:
> where did you read this?
Where Doug et al keep not responding to Lennart and Matthew's queries as
to whether the correct fix is to the app or to the audit system, but
keep repeating that 'there's an audit error!'
> do yourself a favour an
On Sun, 2013-06-09 at 10:03 -0400, Steve Grubb wrote:
> Why would anyone write software that is incorrect enough the OS spits it back
> as EINVAL?
One example is the btrfs ioctl() for reflink:
https://bugzilla.gnome.org/show_bug.cgi?id=626497
--
devel mailing list
devel@lists.fedoraproject.
On Sun, Jun 09, 2013 at 11:05:44AM -0400, Doug Ledford wrote:
> And really, we've spent more time on this thread than it would take
> Lennart to fix PA. Just a quick stat and check of uid before trying to
> remove the stale files and this would all go away. Sure, your stat and
> remove could rac
On Sun, Jun 09, 2013 at 10:03:19AM -0400, Steve Grubb wrote:
> There isn't a mechanism to allow these to slip through. Over the years I have
> come to realize that the audit system can be a great resource for debugging
> user space. It was sitting through one of Dave Jones' why userspace sucks
On Sat, 08.06.13 11:35, Adam Williamson (awill...@redhat.com) wrote:
> On Sat, 2013-06-08 at 09:25 -0400, Steve Grubb wrote:
>
> > Its not quite like this. What I need is the OS to be well behaved under
> > normal
> > conditions so that when problems come along they are easily spotted. Fedora
On Fri, 07.06.13 22:33, Richard W.M. Jones (rjo...@redhat.com) wrote:
> On Fri, Jun 07, 2013 at 06:55:46PM +0200, Lennart Poettering wrote:
> > User "simo" creates /dev/shm/1000/ even though 1000 is the UID of user
> > "lennart". Lennart can never start PA again, ever. And can't do anything
> > ab
On Fri, 07.06.13 20:21, Miloslav Trmač (m...@volny.cz) wrote:
> AFAICS this can be solved by a ~100-line? patch to the pulseaudio
> ecosystem, or by doing much more work and coordicnation to design a
> different shm mechanism or a new shm namespace. I'm not planning to
> work on it so I suppose m
On Fri, 07.06.13 14:39, Bill Nottingham (nott...@redhat.com) wrote:
> Lennart Poettering (mzerq...@0pointer.de) said:
> > Yes, it is.
> >
> > POSIX shared memory doesn't define any useful scheme for automatic
> > removing of shared memory segments from /dev/shm after use. Hence, in
> > order to
On Fri, 07.06.13 15:35, Steve Grubb (sgr...@redhat.com) wrote:
> On Friday, June 07, 2013 07:29:56 PM Matthew Garrett wrote:
> > On Fri, Jun 07, 2013 at 02:02:14PM -0400, Simo Sorce wrote:
> > > The point is that we are simply throwing ideas off the wall as an aid in
> > > finding a way to solve t
On 06/09/2013 10:34 AM, Adam Williamson wrote:
> On Sun, 2013-06-09 at 10:03 -0400, Steve Grubb wrote:
>
>>> I don't think anyone wants these accesses to generate audit records. The
>>> question is whether the right way to fix that is to avoid those accesses
>>> in the first place or to provide a
On Fri, 07.06.13 14:02, Simo Sorce (s...@redhat.com) wrote:
> > Well, you know, this problem isn't new. Some SELinux AVCs can be set to
> > ignored for precisely reasons like this one, because it is common that
> > things like these happen: accesses which fail where that is
> > expected. You can c
On 06/09/2013 09:53 AM, Roberto Ragusa wrote:
> On 06/08/2013 04:13 PM, Doug Ledford wrote:
>>
>> Yes, but none of these results show the .12s time that your first
>> noatime test run showed in your original post. If you are now saying
>> that atime is faster than noatime by about .005 to .010s, t
On Sun, 2013-06-09 at 10:03 -0400, Steve Grubb wrote:
> > I don't think anyone wants these accesses to generate audit records. The
> > question is whether the right way to fix that is to avoid those accesses
> > in the first place or to provide a mechanism so that legitimate accesses
> > don't gen
On Sunday, June 09, 2013 05:56:42 AM Matthew Garrett wrote:
> On Sat, Jun 08, 2013 at 08:28:48PM -0400, Doug Ledford wrote:
> > On 06/08/2013 02:35 PM, Adam Williamson wrote:
> > > Well, you're defining something as 'bad behaviour' fairly arbitrarily -
> > > or at least controversially: not everyon
On 06/08/2013 04:13 PM, Doug Ledford wrote:
>
> Yes, but none of these results show the .12s time that your first
> noatime test run showed in your original post. If you are now saying
> that atime is faster than noatime by about .005 to .010s, then these
> results seem to show that. But your or
Compose started at Sun Jun 9 09:15:02 UTC 2013
Broken deps for x86_64
--
[deltacloud-core]
deltacloud-core-rhevm-1.1.3-1.fc19.noarch requires rubygem(rbovirt) >=
0:0.0.18
[dragonegg]
dragonegg-3.1-19.fc19.x86_64 requires gcc
Compose started at Sun Jun 9 08:15:02 UTC 2013
Broken deps for x86_64
--
[bind10]
bind10-1.0.0-3.fc20.i686 requires liblog4cplus-1.1.so.5
bind10-1.0.0-3.fc20.x86_64 requires liblog4cplus-1.1.so.5()(64bit)
bind10-dhcp-
21 matches
Mail list logo
