# Fedora Quality Assurance Meeting
# Date: 2012-04-09
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net
Greetings testers!
There's going to be a meeting. Probably. I may or not make it up in
time. Conduct yerselves according
I have an inconsequential F16 VM that uses btrfs. The VM went psycho for
unknown reasons and I had to force quit. Realizing btrfsck can't fix a problem,
I was curious if it would see any problems. So I loaded the F16.vdi as a 2nd
SATA disk in an F17 VM. I get the following results:
[root@f17v c
On Sun, 08 Apr 2012 22:50:21 +0200, Tom Lane wrote:
> A possible compromise that might allow software developers to live
> with the setting would be if the default excluded gdb
Counterargument in some that Bug was then the attacker can spawn GDB instead
of using PTRACE_ATTACH in that process itsel
* on the Tue, Apr 03, 2012 at 12:54:46PM -0500, Chris Adams was commenting:
| Once upon a time, Matthias Clasen said:
| > That really depends on what use cases we see for our live cds. In my
| > view, there's really only two:
| >
| > The primary use for a live cd is to install.
|
| That's the pr
On 04/09/2012 10:58 AM, Dave Young wrote:
> On 04/08/2012 10:54 PM, Nikola Pajkovsky wrote:
>
>> Dave Young writes:
>>
>>> Hi,
>>>
>>> When I testing kdump, the vmcore is successfully captured in
>>> /sysroot/var/crash which is the /var/crash in rootfs. But after reboot
>>> it disappeared.
>>>
>
On 04/08/2012 10:54 PM, Nikola Pajkovsky wrote:
> Dave Young writes:
>
>> Hi,
>>
>> When I testing kdump, the vmcore is successfully captured in
>> /sysroot/var/crash which is the /var/crash in rootfs. But after reboot
>> it disappeared.
>>
>> Any idea about this?
>
> do you have installed abrt
On Sun, Apr 8, 2012 at 10:50 PM, Tom Lane wrote:
> And, as I said, the alternative is that this gets turned off, by me
> and probably a very large fraction of other Fedora users. How is
> that "more secure"?
Perhaps people installing servers in high-risk situations could just
not turn it off. O
Mark Wielaard wrote:
> Is there still time to discuss and/or reconsider turning this on by
> default for F17?
+1, this broken misfeature really needs to be turned off by default. It also
breaks crash reporters such as DrKonqi (for DrKonqi, we work around this by
disabling the flag in kde-runtime
Björn Persson wrote:
> So what it boils down to is that you wish you didn't have to wait for the
> build to complete in Koji before you submit the update in Bodhi
Not really, because I have no idea whether it will build in the first place
before the build is complete (on any architecture)!
John Reiser writes:
> [...]
> According to this bugzilla Comment
>https://bugzilla.redhat.com/show_bug.cgi?id=786878#c27
> Fedora 17 Alpha turned on denyPtrace (as default) by mistake.
That's not how I read #c27. The flag was turned off during alpha by
mistake and that it would be on in the
John Reiser writes:
> gdb nicely gives the work-around for denyPtrace, but the work-around
> requires privileges to implement. So far the implementation history
> of the denyPtrace feature leads me to fear loss of Functionality and
> Usability for software developers.
Indeed. This "feature" isn
> I recently tested out f17 and saw I can no longer trace or debug
> applications by default. ...
> Is there still time to discuss and/or reconsider turning this on by
> default for F17?
According to this bugzilla Comment
https://bugzilla.redhat.com/show_bug.cgi?id=786878#c27
Fedora 17 Alpha
Mark Wielaard writes:
> Previously https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace
> implied that this feature could be turned on by an administrator,
> but recently it was changed to be on by default. Was that intended?
I certainly hope that's a mistake. If it's not, I will gladly joi
Hi,
I recently tested out f17 and saw I can no longer trace or debug
applications by default. While I appreciate why one might want
some applications to not ptrace any other application, it is a
bit of a sledge hammer to deny any and all program introspection.
Previously https://fedoraproject.org
Kevin Kofler wrote:
> The idea would be that you'd be able to file and queue the update in Bodhi
> as soon as the primary build completes, just as now, except that "primary"
> would now be the one, possibly fake, architecture. The updates could even
> get pushed right there, for the internal pri
Dave Young writes:
> Hi,
>
> When I testing kdump, the vmcore is successfully captured in
> /sysroot/var/crash which is the /var/crash in rootfs. But after reboot
> it disappeared.
>
> Any idea about this?
do you have installed abrt?
--
Nikola
--
devel mailing list
devel@lists.fedoraproject.o
On Sun, Apr 8, 2012 at 2:57 AM, Kevin Kofler wrote:
> Hi,
>
> let me suggest a new proposal for the primary architecture controversy:
> Let's have exactly one architecture handled as primary in Koji, picked with
> the ONLY aim of making builds as fast as possible.
Even though fast builds are nice
On Sun, Apr 08, 2012 at 02:34:25PM +0200, Kevin Kofler wrote:
> * Updates would be able to be filed as soon as the primary build completes
> (see below).
Question: What should be happen, if the build fails on a architecture
which was not built as fast as the festest build.
I have in mind that th
Miloslav Trmač wrote:
> How is this in practice different from
> a) the package maintainer looking at the build logs of the
> fastest-building architecture as soon as that architecture builds, and
> ignoring the rest? (The maintainer can do this right now.)
* The build might be faster if we find
Hi.
On Sat, 07 Apr 2012 22:35:01 -0300, Horst H. von Brand wrote
> Nobody will _run_ that, so no testing other that "it builds".
if I understand Kevin correctly nobody is supposed to run it.
It's just used as a fast-fail check for compilability (if that's
a word).
It's exactly the same informat
20 matches
Mail list logo
