On Wed, 2014-01-29 at 09:26 -0500, Matthew Miller wrote:
> On Tue, Jan 28, 2014 at 06:42:52PM -0800, Adam Williamson wrote:
> > Using the wiki as a TCMS is of course a gross hack, but it comes with a
> > surprising number of advantages - see
>
> Makes sense to me. I'm actually not opposed to using
On Tue, Jan 28, 2014 at 06:42:52PM -0800, Adam Williamson wrote:
> Using the wiki as a TCMS is of course a gross hack, but it comes with a
> surprising number of advantages - see
Makes sense to me. I'm actually not opposed to using the wiki in this way,
but I think it highlights the need for _some
On Tue, 2014-01-28 at 15:19 -0500, Matthew Miller wrote:
> On Tue, Jan 28, 2014 at 10:39:32AM +0800, Mathieu Bridon wrote:
> > > I could have sworn we already had something like this where bodhi would
> > > add a link to a wiki page for test plan on a package if that wiki page
> > > existed. I can'
On Tue, Jan 28, 2014 at 10:39:32AM +0800, Mathieu Bridon wrote:
> > I could have sworn we already had something like this where bodhi would
> > add a link to a wiki page for test plan on a package if that wiki page
> > existed. I can't seem to find it now, so perhaps it was just something
> > we ta
On Mon, 2014-01-27 at 19:24 -0800, Adam Williamson wrote:
> On Tue, 2014-01-28 at 10:39 +0800, Mathieu Bridon wrote:
> > On Mon, 2014-01-27 at 15:11 -0700, Kevin Fenzi wrote:
> > > On Mon, 27 Jan 2014 10:18:56 -0500
> > > Matthew Miller wrote:
> > >
> > > snip
> > >
> > > > * possibly ad
On Tue, 2014-01-28 at 10:39 +0800, Mathieu Bridon wrote:
> On Mon, 2014-01-27 at 15:11 -0700, Kevin Fenzi wrote:
> > On Mon, 27 Jan 2014 10:18:56 -0500
> > Matthew Miller wrote:
> >
> > snip
> >
> > > * possibly adding a "what should users test?" field to the update
> > > info.
> > >
>
On Mon, 2014-01-27 at 15:11 -0700, Kevin Fenzi wrote:
> On Mon, 27 Jan 2014 10:18:56 -0500
> Matthew Miller wrote:
>
> snip
>
> > * possibly adding a "what should users test?" field to the update
> > info.
> >
> > I know that there's a "notes" field in the update, but maybe it'd
> > h
On Mon, 27 Jan 2014 10:18:56 -0500
Matthew Miller wrote:
snip
> * possibly adding a "what should users test?" field to the update
> info.
>
> I know that there's a "notes" field in the update, but maybe it'd
> help to explicitly include testing instructions?
>
> Each package in the
On Fri, Jan 24, 2014 at 11:46:41PM +0100, Michael Schwendt wrote:
> Any ideas how to attract more testers?
> How to make the updates-testing repo more sexy?
* More automated smoke-tests, so that:
a) you know the most boring tests have been handled so you
can focus on more interesting apsects
Am 27.01.2014 02:11, schrieb Chris Murphy:
>> i only just warned about cases where a rollback would do harm and to *make
>> sure* that really no one would
>> do it without take care
>
> That was my *entire* point going back around 36 hours ago
and that is why i do not understand your turn around
On Jan 26, 2014, at 5:37 PM, Reindl Harald wrote:
>
>
> Am 27.01.2014 01:32, schrieb Chris Murphy:
>> On Jan 26, 2014, at 5:20 PM, Reindl Harald wrote:
>>> Am 27.01.2014 01:18, schrieb Chris Murphy:
You gave several examples of rollback-snapshot methods - same thing as you
suggeste
Am 27.01.2014 01:32, schrieb Chris Murphy:
> On Jan 26, 2014, at 5:20 PM, Reindl Harald wrote:
>> Am 27.01.2014 01:18, schrieb Chris Murphy:
>>> You gave several examples of rollback-snapshot methods - same thing as you
>>> suggested them. I never said you requested them
>>
>> oh my god - i gav
On Jan 26, 2014, at 5:20 PM, Reindl Harald wrote:
>
>
> Am 27.01.2014 01:18, schrieb Chris Murphy:
>> On Jan 26, 2014, at 4:55 PM, Reindl Harald wrote:
>>> Am 27.01.2014 00:51, schrieb Chris Murphy:
On Jan 26, 2014, at 4:29 PM, Reindl Harald wrote:
> do yourself and everybody
On Jan 26, 2014, at 5:10 PM, Reindl Harald wrote:
>
>
> Am 27.01.2014 01:07, schrieb Chris Murphy:
>
>> And then you propose a ridonkulous snapshot-rollback strategy that would for
>> certain cause major problems
>> if the rollback were actually done
>
> *the opposite is true because i WAR
Am 27.01.2014 01:18, schrieb Chris Murphy:
> On Jan 26, 2014, at 4:55 PM, Reindl Harald wrote:
>> Am 27.01.2014 00:51, schrieb Chris Murphy:
>>> On Jan 26, 2014, at 4:29 PM, Reindl Harald wrote:
>>>
do yourself and everybody a favour and
* don't claim others are rude while you ta
On Jan 26, 2014, at 4:55 PM, Reindl Harald wrote:
>
>
> Am 27.01.2014 00:51, schrieb Chris Murphy:
>> On Jan 26, 2014, at 4:29 PM, Reindl Harald wrote:
>>
>>> do yourself and everybody a favour and
>>>
>>> * don't claim others are rude while you talk like above and worser half of
>>> the t
ame argumentation as Simon and me to later fight against it
while now claim i came up with the idea of snapshots while
warning all the time and tried to explain Chris *why* i
warn
Original-Nachricht ----
Betreff: Re: Drawing lessons from fatal SELinux bug #1054350
Datum: Sat, 25 Jan 20
Am 27.01.2014 01:07, schrieb Chris Murphy:
> And then you propose a ridonkulous snapshot-rollback strategy that would for
> certain cause major problems
> if the rollback were actually done
*the opposite is true because i WARNED of doing snapshots*
signature.asc
Description: OpenPGP digita
On Jan 26, 2014, at 4:47 PM, Reindl Harald wrote:
>
> Am 27.01.2014 00:41, schrieb Chris Murphy:
>> Great, well I'll tell you what. I will just keep living dangerously, and
>> when I find a real world case of this, I'll file a bug. How about that?
>
> do that, your problem
>
>>> because nobo
I don't think this subthread is being particularly useful...
And the personal attacks are undesirable.
Please stop or at least take it to private email.
Thanks,
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.o
Am 27.01.2014 00:51, schrieb Chris Murphy:
> On Jan 26, 2014, at 4:29 PM, Reindl Harald wrote:
>
>> do yourself and everybody a favour and
>>
>> * don't claim others are rude while you talk like above and worser half of
>> the thread
>> * don't talk about things above your technical scope
>> *
On Jan 26, 2014, at 4:29 PM, Reindl Harald wrote:
> do yourself and everybody a favour and
>
> * don't claim others are rude while you talk like above and worser half of
> the thread
> * don't talk about things above your technical scope
> * discuss with software engineers while lacking basic
Am 27.01.2014 00:41, schrieb Chris Murphy:
> Great, well I'll tell you what. I will just keep living dangerously, and when
> I find a real world case of this, I'll file a bug. How about that?
do that, your problem
>> because nobody *can* know what exactly packages, versions are installed
>> in
On Jan 26, 2014, at 1:40 PM, Reindl Harald wrote:
>
>
> Am 26.01.2014 21:30, schrieb Chris Murphy:
>> On Jan 26, 2014, at 12:51 PM, Reindl Harald wrote:
>>> Am 26.01.2014 20:45, schrieb Chris Murphy:
> So ?
> It is only visible if you downgrade which a lot of software do not
> sup
Am 27.01.2014 00:26, schrieb Chris Murphy:
> On Jan 26, 2014, at 1:18 PM, Reindl Harald wrote:
>> Am 26.01.2014 21:13, schrieb Chris Murphy:
>>> On Jan 26, 2014, at 11:41 AM, Simo Sorce wrote:
>>>
I never said it won't work in absolute, it probably will work ok in many
cases, just to
On Jan 26, 2014, at 1:18 PM, Reindl Harald wrote:
>
>
> Am 26.01.2014 21:13, schrieb Chris Murphy:
>> On Jan 26, 2014, at 11:41 AM, Simo Sorce wrote:
>>
>>> I never said it won't work in absolute, it probably will work ok in many
>>> cases, just to cause incredible issues in others.
>>>
>>>
Am 26.01.2014 21:56, schrieb Chris Murphy:
> No you just have reading comprehension problem. The minor versions are
> compatible. The major versions aren't
one last question: what are firefox updates 25->26->27
minor, major, dunno?
more and more software has no minor/major splitting at all
sys
Am 26.01.2014 21:56, schrieb Chris Murphy:
> On Jan 26, 2014, at 1:07 PM, Reindl Harald wrote:
>>> Well, the mail servers regularly get updated by the company I pay for such
>>> things, and I've
>>> never noticed the change. It uses IMAP so I don't think the server even
>>> cares, its just a
On Jan 26, 2014, at 1:07 PM, Reindl Harald wrote:
> Am 26.01.2014 20:56, schrieb Chris Murphy:
>>> What about mail application change the format of the mail folders ?
>>
>> Good question because I experienced this recently. So the way Apple does
>> this on OS X with Mail,
>> there is no such
On Sun, 2014-01-26 at 12:45 -0700, Chris Murphy wrote:
> I still really have no idea what sorts of changes you're talking
> about.
I think you made it abundantly clear :-)
I am also sure what I wanted to convey to people that understand what I
am talking about is also clear. So I think the matter
Am 26.01.2014 21:30, schrieb Chris Murphy:
> On Jan 26, 2014, at 12:51 PM, Reindl Harald wrote:
>> Am 26.01.2014 20:45, schrieb Chris Murphy:
So ?
It is only visible if you downgrade which a lot of software do not
support and explicitly so
>>>
>>> The right way to do file format c
On Jan 26, 2014, at 12:51 PM, Reindl Harald wrote:
>
> Am 26.01.2014 20:45, schrieb Chris Murphy:
>>> So ?
>>> It is only visible if you downgrade which a lot of software do not
>>> support and explicitly so
>>
>> The right way to do file format changes is you design the new format.
>> And in
On Sun, 2014-01-26 at 13:13 -0700, Chris Murphy wrote:
> On Jan 26, 2014, at 11:41 AM, Simo Sorce wrote:
>
> > I never said it won't work in absolute, it probably will work ok in many
> > cases, just to cause incredible issues in others.
> >
> > It is a fine tool in the hands of an expert that k
Am 26.01.2014 21:13, schrieb Chris Murphy:
> On Jan 26, 2014, at 11:41 AM, Simo Sorce wrote:
>
>> I never said it won't work in absolute, it probably will work ok in many
>> cases, just to cause incredible issues in others.
>>
>> It is a fine tool in the hands of an expert that knows how to che
On Jan 26, 2014, at 11:41 AM, Simo Sorce wrote:
> I never said it won't work in absolute, it probably will work ok in many
> cases, just to cause incredible issues in others.
>
> It is a fine tool in the hands of an expert that knows how to check
> whether reverting to a snapshot is safe.
Why
Am 26.01.2014 20:56, schrieb Chris Murphy:
>> What about mail application change the format of the mail folders ?
>
> Good question because I experienced this recently. So the way Apple does this
> on OS X with Mail,
> there is no such thing as a mail format change during the life of a major OS
Am 26.01.2014 20:51, schrieb Reindl Harald:
> Am 26.01.2014 20:45, schrieb Chris Murphy:
>>> So ?
>>> It is only visible if you downgrade which a lot of software do not
>>> support and explicitly so
>>
>> The right way to do file format changes is you design the new format.
>> And in a minor vers
On Jan 26, 2014, at 11:38 AM, Simo Sorce wrote:
> On Sat, 2014-01-25 at 17:54 -0700, Chris Murphy wrote:
>> On Jan 25, 2014, at 4:12 PM, Adam Williamson wrote:
>>>
>>> * Do an offline update that includes Foo v2.0
>>> * Boot the updated system, run Foo, it migrates its configuration to
>>> som
On 01/25/2014 12:15 PM, Chris Murphy wrote:
> OK, so is the fact it's persistently available the problem? Because
> if I were to have a persistent backup of sysroot mounted, I've got
> the same attack vector available. By default for even an unprivileged
> user gnome-shell mounts with By default, g
Am 26.01.2014 20:45, schrieb Chris Murphy:
>> So ?
>> It is only visible if you downgrade which a lot of software do not
>> support and explicitly so
>
> The right way to do file format changes is you design the new format.
> And in a minor version update, the application gains the ability to
>
On Jan 26, 2014, at 11:35 AM, Simo Sorce wrote:
> On Sat, 2014-01-25 at 17:28 -0700, Chris Murphy wrote:
>> On Jan 25, 2014, at 12:55 PM, Simo Sorce wrote:
>>
>>> The reason is simple: lot's of software *changes* data as part of its
>>> normal functioning, including and often in rollback-incom
On Sat, 2014-01-25 at 15:04 -0500, Colin Walters wrote:
> Hi Simo,
>
> On Sat, 2014-01-25 at 14:55 -0500, Simo Sorce wrote:
>
> > The reason is simple: lot's of software *changes* data as part of its
> > normal functioning, including and often in rollback-incompatible ways.
>
> I wrote and maint
On Sat, 2014-01-25 at 17:54 -0700, Chris Murphy wrote:
> On Jan 25, 2014, at 4:12 PM, Adam Williamson wrote:
> >
> > * Do an offline update that includes Foo v2.0
> > * Boot the updated system, run Foo, it migrates its configuration to
> > some new scheme
> > * Realize there was something wrong w
On Sat, 2014-01-25 at 17:28 -0700, Chris Murphy wrote:
> On Jan 25, 2014, at 12:55 PM, Simo Sorce wrote:
>
> > The reason is simple: lot's of software *changes* data as part of its
> > normal functioning, including and often in rollback-incompatible ways.
> >
> > You cannot assume that upgrading
Reindl Harald wrote:
> i am not entirely sure how that is meant
>
> * disable the automatism to push to stable
> * forget the whole karma system at all
>
> in case of "disable the automatism to push to stable" i agree
Even just doing that would be an improvement, but I still think the whole
karm
Dominick Grift wrote:
> I did not mean to suggest that. I meant to suggest that SELinux would be
> able to contain the damage, referring to "fatal" in: "Drawing lessons
> from fatal SELinux bug"
And by what magic would it do that? SELinux cannot by its nature contain any
damage of the "the system
Chris Murphy wrote:
> I wouldn't ever expect this with a minor version or security update. I'd
> consider it a complete betrayal of software versioning to do this. In fact
> in certain instances of major version changes, downward compatibility of
> the file format is expected.
The compatibility is
Am 26.01.2014 01:54, schrieb Chris Murphy:
> On Jan 25, 2014, at 4:12 PM, Adam Williamson wrote:
>>
>> * Do an offline update that includes Foo v2.0
>> * Boot the updated system, run Foo, it migrates its configuration to
>> some new scheme
>> * Realize there was something wrong with the update,
On Jan 25, 2014, at 4:12 PM, Adam Williamson wrote:
>
> * Do an offline update that includes Foo v2.0
> * Boot the updated system, run Foo, it migrates its configuration to
> some new scheme
> * Realize there was something wrong with the update, roll it back
> * Run Foo again, find it doesn't wo
Am 26.01.2014 01:28, schrieb Chris Murphy:
>> It is basically impossible to find applications that handle the case
>> where you downgrade, in any more graceful way than punting and failing
>> to start in the *good* case. In the bad case they start and trash the
>> database.
>
> But important user d
On Jan 25, 2014, at 12:55 PM, Simo Sorce wrote:
> The reason is simple: lot's of software *changes* data as part of its
> normal functioning, including and often in rollback-incompatible ways.
>
> You cannot assume that upgrading a program that uses a database X from
> version A to B can still
On Jan 25, 2014, at 9:46 AM, Tomasz Torcz wrote:
> On Fri, Jan 24, 2014 at 03:10:04PM -0700, Chris Murphy wrote:
>>
>> Another possible case it's /etc/ where the either a package or the user could
>> make changes during the update. Btrfs allows per file snapshots with cp
>> --reflink so there m
On Jan 25, 2014, at 9:41 AM, Kevin Kofler wrote:
> Chris Murphy wrote:
>> If there is a directory that contains update and non-update related file
>> changes, that's a problem. If there's segmentation, then this can be done.
>>
>> Clearly /home needs to be separate (it's OK to take a snapshot b
On Sat, 2014-01-25 at 23:26 +0100, Tomasz Torcz wrote:
> On Sat, Jan 25, 2014 at 02:55:32PM -0500, Simo Sorce wrote:
> > On Sat, 2014-01-25 at 17:46 +0100, Tomasz Torcz wrote:
> > > >
> > > > If there is a directory that contains update and non-update related file
> > > > changes, that's a problem
Am 25.01.2014 23:26, schrieb Tomasz Torcz:
> On Sat, Jan 25, 2014 at 02:55:32PM -0500, Simo Sorce wrote:
>> The ONLY way to do that is if you do not care at all about user's data
>> and simply accept that a rollback will also remove user data.
>>
>> The reason is simple: lot's of software *change
On Sat, Jan 25, 2014 at 02:55:32PM -0500, Simo Sorce wrote:
> On Sat, 2014-01-25 at 17:46 +0100, Tomasz Torcz wrote:
> > >
> > > If there is a directory that contains update and non-update related file
> > > changes, that's a problem. If there's segmentation, then this can be
> > > done.
> >
>
On Sat, 25 Jan 2014 22:00:02 +0100, Kevin Kofler wrote:
> Right, but you were proposing to wait until it reaches a karma of +16.
Certainly not. That Yum update is only a good example where a high
karma threshold has been reached in less than a week, and even without
a vote from all available/acti
Am 25.01.2014 22:00, schrieb Kevin Kofler:
> But then the right solution is to disable karma automatism entirely, not to
> set it to some ridiculously high value.
>
> Those meaningless thresholds need to go away (and really, the whole concept
> of Bodhi karma and the policies that depend on it)
On Sat, 2014-01-25 at 21:51 +0100, Kevin Kofler wrote:
> Dominick Grift wrote:
> > No, that is a different discussion.
>
> Nonsense. That SELinux should be disabled is the whole point of this thread
> (I know, I have started it!), all the suggestions (in the various
> subthreads) of how to paper
Michael Schwendt wrote:
> If the update doesn't refer to any bugzilla tickets, what does that mean?
In that particular case, it means that we are updating all the KDE software
compilation and so there's a new release of KFloppy too, which most likely
doesn't even contain any actual changes from
Dominick Grift wrote:
> No, that is a different discussion.
Nonsense. That SELinux should be disabled is the whole point of this thread
(I know, I have started it!), all the suggestions (in the various
subthreads) of how to paper over the problem are off topic.
> Disabling SELinux does nothing
On Jan 24, 2014, at 9:40 PM, Josh Stone wrote:
> On 01/24/2014 05:27 PM, Chris Murphy wrote:
>> On Jan 24, 2014, at 4:16 PM, Josh Stone wrote:
>>> This concerns me especially in the case of security updates -- for
>>> example, a vulnerable setuid-root binary should be locked up tight!
>>
>> T
On Sat, 2014-01-25 at 14:32 -0500, Colin Walters wrote:
> On Sat, 2014-01-25 at 10:37 -0800, Josh Stone wrote:
>
> > Ok, sure, you can mount -o nosuid,noexec,nodev ... but this isn't the
> > default for btrfs subvolume paths AFAIK. It needs to be a conscious
> > decision in whatever snapshot desi
Hi Simo,
On Sat, 2014-01-25 at 14:55 -0500, Simo Sorce wrote:
> The reason is simple: lot's of software *changes* data as part of its
> normal functioning, including and often in rollback-incompatible ways.
I wrote and maintain a system that has been doing continuous deployment
of GNOME. It's b
On Sat, 2014-01-25 at 17:46 +0100, Tomasz Torcz wrote:
> On Fri, Jan 24, 2014 at 03:10:04PM -0700, Chris Murphy wrote:
> >
> > On Jan 24, 2014, at 11:19 AM, Kevin Fenzi wrote:
> >
> > > On Fri, 24 Jan 2014 09:41:13 -0800
> > > Adam Williamson wrote:
> > >
> > >> AIUI there is/was a long-term p
On Sat, 2014-01-25 at 10:37 -0800, Josh Stone wrote:
> Ok, sure, you can mount -o nosuid,noexec,nodev ... but this isn't the
> default for btrfs subvolume paths AFAIK. It needs to be a conscious
> decision in whatever snapshot design we choose.
This is definitely an issue with the OSTree design,
On Sat, 25 Jan 2014 19:17:14 +0100, Kevin Kofler wrote:
> > By the time the first testers noticed the scriptlet errors it was too
> > late, since stable updates cannot be withdrawn.
>
> That is also not a law of Physics. In the early days of Bodhi, one could
> actually unpush stuff from stable.
On Sat, 25 Jan 2014 19:29:12 +0100, Kevin Kofler wrote:
> > https://admin.fedoraproject.org/updates/FEDORA-2013-23627
> > Karma:17
> > Stable karma: 16 (!)
> >
> > It has reached the karma threshold 16 after ~5 days.
> > And those have not been all testers.
>
> That can work for yum,
On Sat, 2014-01-25 at 19:10 +0100, Kevin Kofler wrote:
> > Never the less, I think this issue could have been prevented even before
> > a package was spun.
>
> Yes, by disabling SELinux by default. :-)
>
No, that is a different discussion. Disabling SELinux does nothing to
solve this. If anythi
On 01/25/2014 06:03 AM, Bruno Wolff III wrote:
> On Fri, Jan 24, 2014 at 20:40:28 -0800,
>Josh Stone wrote:
>>
>> My point was not about what root can do. Suppose there's a vulnerable
>> 'sudo' binary that gives everyone a root shell. If that binary is
>> available on any executable path, ev
Michael Schwendt wrote:
> More lessons to learn:
>
> https://admin.fedoraproject.org/updates/FEDORA-2013-23627
> Karma: 17
> Stable karma: 16 (!)
>
> It has reached the karma threshold 16 after ~5 days.
> And those have not been all testers.
That can work for yum, but if I set the
Adam Williamson wrote:
> Yup, indeed. Of course, this is another area where we could improve the
> tooling: it doesn't seem like it'd be difficult for maintainers to be
> allowed to set a minimum timeframe before their update goes stable, but
> at present this isn't possible.
Why do we need to kee
Michael Schwendt wrote:
> By the time the first testers noticed the scriptlet errors it was too
> late, since stable updates cannot be withdrawn.
That is also not a law of Physics. In the early days of Bodhi, one could
actually unpush stuff from stable. Having stable updates become immutable is
Dominick Grift wrote:
> Sure, what i am saying is that this could have been prevented if the
> team just put a little more passion into it and also did some proof
> reading/coordination. The team knows whats going on. They know the
> issues and they can quickly and effortlessly identify issues like
Adam Williamson wrote:
> The 'comment' field exists to allow people to express all these things,
> but as it's just a completely free-form text field, it's intrinsically
> impossible to really base any programmatic stuff or even policy on it.
> In theory maintainers could submit updates without usi
Adam Williamson wrote:
> On Fri, 2014-01-24 at 13:36 +0100, Kevin Kofler wrote:
>> * If the package is already so screwed that it breaks the whole system,
>> it cannot realistically get any worse.
>
> Sure it can. It can wipe all your data, or mail it to the NSA...
That's why I said "realistical
Sergio Pascual wrote:
> The situation (a broken system that cannot be upgraded) could be
> mitigated a little bit by using yum + system snapshots. You can rollback
> to a previous sane system.
The big problem with that approach (other than the granularity issue already
pointed out) is disk space
Am 25.01.2014 17:46, schrieb Tomasz Torcz:
> Note that this situation is perfectly handled by Offline Updates.
> After reboot, there aren't collateral changes to filesystem, only
> upgrade-related
> ones. So if there's a need for revert, the previous state is clearly defined
says who?
UsrMove
On Fri, Jan 24, 2014 at 03:10:04PM -0700, Chris Murphy wrote:
>
> On Jan 24, 2014, at 11:19 AM, Kevin Fenzi wrote:
>
> > On Fri, 24 Jan 2014 09:41:13 -0800
> > Adam Williamson wrote:
> >
> >> AIUI there is/was a long-term plan to integrate this as core
> >> functionality using btrfs snapshots
Chris Murphy wrote:
> If there is a directory that contains update and non-update related file
> changes, that's a problem. If there's segmentation, then this can be done.
>
> Clearly /home needs to be separate (it's OK to take a snapshot but just
> don't use it by default in a rollback) or we los
On Sat, 2014-01-25 at 10:43 +, Richard W.M. Jones wrote:
> > I think that's being unnecessarily harsh on the testers. It's not at all
> > obvious to anyone that you ought to test update/install of another
> > package in order to validate an update to selinux-policy-targeted .
> > Hell, I don't
Ralf, Harald, you both actually mean the same thing, you're just
misunderstanding each other due to inexact wording!
Yes, distro-sync will not remove packages which are not in the default-
enabled repositories at all (in any version) (nor will it downgrade them,
obviously, because there is no ve
On Fri, Jan 24, 2014 at 20:40:28 -0800,
Josh Stone wrote:
My point was not about what root can do. Suppose there's a vulnerable
'sudo' binary that gives everyone a root shell. If that binary is
available on any executable path, even readonly, that's trouble.
That isn't true. File systems
On Fri, Jan 24, 2014 at 11:14:50AM -0800, Adam Williamson wrote:
> On Fri, 2014-01-24 at 19:26 +0100, Michael Schwendt wrote:
>
> > > * That update made it out to the stable updates! In other words, the
> > > draconian Update Policies that were enacted in a vain attempt to prevent
> > > such iss
On 01/24/2014 05:27 PM, Chris Murphy wrote:
> On Jan 24, 2014, at 4:16 PM, Josh Stone wrote:
>> This concerns me especially in the case of security updates -- for
>> example, a vulnerable setuid-root binary should be locked up tight!
>
> The organization question is valid. But sudo or root could
On 24 January 2014 20:13, drago01 wrote:
>> Am 24.01.2014 19:31, schrieb Reindl Harald:
>>and try the however named option, keep
>> in mind some people own only one machine and can't google for help
>
> I doubt that. Most people do have multiple ways to access the internet
> (multiple computers,
On Jan 24, 2014, at 4:16 PM, Josh Stone wrote:
> On 01/24/2014 01:38 PM, Chris Murphy wrote:
>> On Jan 24, 2014, at 2:58 AM, Sergio Pascual >> There is a plugin yum-plugin-fs-snapshot, but it requires better
>>> documentation and system integration.
>>
>> Well I'd go a step further and ask some
On Sat, 25 Jan 2014 00:21:13 +0100, Reindl Harald wrote:
> > More lessons to learn:
> >
> > https://admin.fedoraproject.org/updates/FEDORA-2013-23627
> > Karma:17
> > Stable karma: 16 (!)
> >
> > It has reached the karma threshold 16 after ~5 days.
> > And those have not been all tes
Am 24.01.2014 23:46, schrieb Michael Schwendt:
> On Fri, 24 Jan 2014 15:35:24 -0700, Stephen John Smoogen wrote:
>
>> Looking at the number of people who respond to the qa list at times.. I am
>> going to say there are probably 6-10 active testers during non-release
>> times. It comes and it goe
On Fri, 2014-01-24 at 15:35 -0700, Stephen John Smoogen wrote:
>
> Looking at the number of people who respond to the qa list at times..
> I am going to say there are probably 6-10 active testers during
> non-release times. It comes and it goes, but that is about the number
> who seem active at l
On Fri, 2014-01-24 at 22:36 +0100, Michael Schwendt wrote:
> Good point. Raises the question why an update that links so many bugzilla
> tickets can be marked stable automatically after a +3, which may be even
> about a single bz ticket.
Because that's how the maintainer configured it. (It is als
On Fri, 2014-01-24 at 22:36 +0100, Michael Schwendt wrote:
> That's why I think there's reason to be very careful and sometimes even
> prefer a +0 (with a comment) over a very early over-ambitious +1.
>
> And guess what happens in non-critpath updates after 7 days and _no_
> feedback. Packagers p
Am 24.01.2014 23:46, schrieb Michael Schwendt:
> On Fri, 24 Jan 2014 15:35:24 -0700, Stephen John Smoogen wrote:
>
>> Looking at the number of people who respond to the qa list at times.. I am
>> going to say there are probably 6-10 active testers during non-release
>> times. It comes and it goes
On 01/24/2014 01:38 PM, Chris Murphy wrote:
> On Jan 24, 2014, at 2:58 AM, Sergio Pascual > There is a plugin yum-plugin-fs-snapshot, but it requires better
>> documentation and system integration.
>
> Well I'd go a step further and ask some more basic questions how how
> many snapshots should be
On Fri, 24 Jan 2014 15:35:24 -0700, Stephen John Smoogen wrote:
> Looking at the number of people who respond to the qa list at times.. I am
> going to say there are probably 6-10 active testers during non-release
> times. It comes and it goes, but that is about the number who seem active
> at lea
On 24 January 2014 14:36, Michael Schwendt wrote:
> On Fri, 24 Jan 2014 12:39:55 -0800, Adam Williamson wrote:
>
> > > https://fedoraproject.org/wiki/Critical_path_package#Actions
> > >
> > > | Packages within the critical path are required to perform the
> > > | most fundamental actions on a s
On Jan 24, 2014, at 11:19 AM, Kevin Fenzi wrote:
> On Fri, 24 Jan 2014 09:41:13 -0800
> Adam Williamson wrote:
>
>> AIUI there is/was a long-term plan to integrate this as core
>> functionality using btrfs snapshots - in fact that was one of the
>> major attractions of the idea of switching to
On Fri, 2014-01-24 at 22:54 +0100, Michael Schwendt wrote:
> On Fri, 24 Jan 2014 22:17:20 +0100, Dominick Grift wrote:
>
> > >
> > > https://admin.fedoraproject.org/updates/FEDORA-2014-0806/selinux-policy-3.12.1-116.fc20
> > >
>
> > Because you would need to run RPM to notice it,
>
> Or Yum
On Fri, 24 Jan 2014 22:17:20 +0100, Dominick Grift wrote:
> >
> > https://admin.fedoraproject.org/updates/FEDORA-2014-0806/selinux-policy-3.12.1-116.fc20
> >
> Because you would need to run RPM to notice it,
Or Yum, DNF, Yumex, PackageKit, all tools on top of RPM would run into the
scriptle
On Jan 24, 2014, at 2:58 AM, Sergio Pascual wrote:
> 2014/1/24 Ralf Corsepius
>
> Certainly, downgrading installations which already upgraded to faulty
> packages would not work.
>
> Ralf
>
> The situation (a broken system that cannot be upgraded) could be mitigated a
> little bit by usin
1 - 100 of 151 matches
Mail list logo
