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
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 the
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 mat...@fedoraproject.org wrote:
snip
* possibly
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 talked
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't seem to
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
On Mon, 27 Jan 2014 10:18:56 -0500
Matthew Miller mat...@fedoraproject.org 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
On Mon, 2014-01-27 at 15:11 -0700, Kevin Fenzi wrote:
On Mon, 27 Jan 2014 10:18:56 -0500
Matthew Miller mat...@fedoraproject.org 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
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 mat...@fedoraproject.org wrote:
snip
* possibly adding a what should users test? field to the update
info.
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
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 is
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
karma
On Sat, 2014-01-25 at 17:28 -0700, Chris Murphy wrote:
On Jan 25, 2014, at 12:55 PM, Simo Sorce s...@redhat.com 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
On Sat, 2014-01-25 at 17:54 -0700, Chris Murphy wrote:
On Jan 25, 2014, at 4:12 PM, Adam Williamson awill...@redhat.com 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
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 maintain a
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
On Jan 26, 2014, at 11:41 AM, Simo Sorce s...@redhat.com 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
Am 26.01.2014 21:13, schrieb Chris Murphy:
On Jan 26, 2014, at 11:41 AM, Simo Sorce s...@redhat.com 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
On Sun, 2014-01-26 at 13:13 -0700, Chris Murphy wrote:
On Jan 26, 2014, at 11:41 AM, Simo Sorce s...@redhat.com 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
On Jan 26, 2014, at 12:51 PM, Reindl Harald h.rei...@thelounge.net 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.
Am 26.01.2014 21:30, schrieb Chris Murphy:
On Jan 26, 2014, at 12:51 PM, Reindl Harald h.rei...@thelounge.net 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
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
On Jan 26, 2014, at 1:07 PM, Reindl Harald h.rei...@thelounge.net 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
Am 26.01.2014 21:56, schrieb Chris Murphy:
On Jan 26, 2014, at 1:07 PM, Reindl Harald h.rei...@thelounge.net 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,
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
On Jan 26, 2014, at 1:18 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 26.01.2014 21:13, schrieb Chris Murphy:
On Jan 26, 2014, at 11:41 AM, Simo Sorce s...@redhat.com wrote:
I never said it won't work in absolute, it probably will work ok in many
cases, just to cause incredible
Am 27.01.2014 00:26, schrieb Chris Murphy:
On Jan 26, 2014, at 1:18 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 26.01.2014 21:13, schrieb Chris Murphy:
On Jan 26, 2014, at 11:41 AM, Simo Sorce s...@redhat.com wrote:
I never said it won't work in absolute, it probably will work ok in
On Jan 26, 2014, at 1:40 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 26.01.2014 21:30, schrieb Chris Murphy:
On Jan 26, 2014, at 12:51 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 26.01.2014 20:45, schrieb Chris Murphy:
So ?
It is only visible if you downgrade which a lot
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 which
On Jan 26, 2014, at 4:29 PM, Reindl Harald h.rei...@thelounge.net 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
Am 27.01.2014 00:51, schrieb Chris Murphy:
On Jan 26, 2014, at 4:29 PM, Reindl Harald h.rei...@thelounge.net 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
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
On Jan 26, 2014, at 4:47 PM, Reindl Harald h.rei...@thelounge.net 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
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 digital
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 2014 16:42:13 -0700
Von
On Jan 26, 2014, at 4:55 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 27.01.2014 00:51, schrieb Chris Murphy:
On Jan 26, 2014, at 4:29 PM, Reindl Harald h.rei...@thelounge.net wrote:
do yourself and everybody a favour and
* don't claim others are rude while you talk like above
Am 27.01.2014 01:18, schrieb Chris Murphy:
On Jan 26, 2014, at 4:55 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 27.01.2014 00:51, schrieb Chris Murphy:
On Jan 26, 2014, at 4:29 PM, Reindl Harald h.rei...@thelounge.net wrote:
do yourself and everybody a favour and
* don't claim
On Jan 26, 2014, at 5:10 PM, Reindl Harald h.rei...@thelounge.net 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
On Jan 26, 2014, at 5:20 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 27.01.2014 01:18, schrieb Chris Murphy:
On Jan 26, 2014, at 4:55 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 27.01.2014 00:51, schrieb Chris Murphy:
On Jan 26, 2014, at 4:29 PM, Reindl Harald
Am 27.01.2014 01:32, schrieb Chris Murphy:
On Jan 26, 2014, at 5:20 PM, Reindl Harald h.rei...@thelounge.net 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
On Jan 26, 2014, at 5:37 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 27.01.2014 01:32, schrieb Chris Murphy:
On Jan 26, 2014, at 5:20 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 27.01.2014 01:18, schrieb Chris Murphy:
You gave several examples of rollback-snapshot methods -
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 180
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 issues from
On Fri, Jan 24, 2014 at 20:40:28 -0800,
Josh Stone jist...@redhat.com 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
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
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 do
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 lose
On Fri, Jan 24, 2014 at 03:10:04PM -0700, Chris Murphy wrote:
On Jan 24, 2014, at 11:19 AM, Kevin Fenzi ke...@scrye.com wrote:
On Fri, 24 Jan 2014 09:41:13 -0800
Adam Williamson awill...@redhat.com wrote:
AIUI there is/was a long-term plan to integrate this as core
functionality
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 was
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.
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 realistically.
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 using
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
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
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 keep
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 stable
On 01/25/2014 06:03 AM, Bruno Wolff III wrote:
On Fri, Jan 24, 2014 at 20:40:28 -0800,
Josh Stone jist...@redhat.com 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
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 anything, to
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, but if I set
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, 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 ke...@scrye.com wrote:
On Fri, 24 Jan 2014 09:41:13 -0800
Adam Williamson awill...@redhat.com wrote:
AIUI there
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 design we
On Jan 24, 2014, at 9:40 PM, Josh Stone jist...@redhat.com wrote:
On 01/24/2014 05:27 PM, Chris Murphy wrote:
On Jan 24, 2014, at 4:16 PM, Josh Stone jist...@redhat.com wrote:
This concerns me especially in the case of security updates -- for
example, a vulnerable setuid-root binary should
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
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
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 over
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)
i
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
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.
Note that
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 *changes* data
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. If there's
On Jan 25, 2014, at 9:41 AM, Kevin Kofler kevin.kof...@chello.at 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
On Jan 25, 2014, at 9:46 AM, Tomasz Torcz to...@pipebreaker.pl 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
On Jan 25, 2014, at 12:55 PM, Simo Sorce s...@redhat.com 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
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 data
On Jan 25, 2014, at 4:12 PM, Adam Williamson awill...@redhat.com 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
Am 26.01.2014 01:54, schrieb Chris Murphy:
On Jan 25, 2014, at 4:12 PM, Adam Williamson awill...@redhat.com 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
2014/1/24 Ralf Corsepius rc040...@freenet.de
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 using yum + system snapshots. You can rollback to a
On Fri, Jan 24, 2014 at 12:55 AM, Kevin Kofler kevin.kof...@chello.at wrote:
So, what happened:
* We are enabling SELinux enabled (enforcing) by default, a tool designed to
prevent anything it does not like from happening. (Reread this carefully:
The ONLY thing that tool is designed to do at
Adam Williamson wrote:
Even if we can do it on the mirrors, we have no way to 'recall' a
package from systems where it's already been installed (of course in the
current case that wouldn't have worked anyway, but we're discussing the
generic case here).
Crazy idea of the day: Maybe our update
Adam Williamson wrote:
TBH this has always been the one of Kevin's Big Book Of Update Policy
Complaints I find the most baffling. If we know you managed to screw up
your update once, why exactly would we just trust you to get it right
the *second* time without any testing?
* If the package is
drago01 wrote:
The feature is called security. By your logic everyone should be
root,
For home user machines, that wouldn't necessarily be a bad thing (but it
would mean fixing the software that special-cases the root user improperly
for no good reason).
Alternatively, the kernel could be
Am 24.01.2014 13:56, schrieb Kevin Kofler:
Alternatively, the kernel could be patched to give admin users (either
defined as members of the wheel group as now, or by some additional
property that would be set for the same users by default) some strategic
capabilities such as dac_override.
On Fri, 2014-01-24 at 14:40 +0100, Reindl Harald wrote:
Am 24.01.2014 13:56, schrieb Kevin Kofler:
Alternatively, the kernel could be patched to give admin users (either
defined as members of the wheel group as now, or by some additional
property that would be set for the same users by
On 01/24/2014 01:39 PM, Kevin Kofler wrote:
Adam Williamson wrote:
Even if we can do it on the mirrors, we have no way to 'recall' a
package from systems where it's already been installed (of course in the
current case that wouldn't have worked anyway, but we're discussing the
generic case
Am 24.01.2014 15:55, schrieb Ralf Corsepius:
On 01/24/2014 01:39 PM, Kevin Kofler wrote:
Adam Williamson wrote:
Even if we can do it on the mirrors, we have no way to 'recall' a
package from systems where it's already been installed (of course in the
current case that wouldn't have worked
On 01/24/2014 04:06 PM, Reindl Harald wrote:
Am 24.01.2014 15:55, schrieb Ralf Corsepius:
On 01/24/2014 01:39 PM, Kevin Kofler wrote:
Adam Williamson wrote:
Even if we can do it on the mirrors, we have no way to 'recall' a
package from systems where it's already been installed (of course in
Am 24.01.2014 16:40, schrieb Ralf Corsepius:
On 01/24/2014 04:06 PM, Reindl Harald wrote:
a) This would blow away all installed packages, which aren't available in
permanently enabled repos
that is not true, try it out
Been there many times
no, you did not and you did also not in your
On 01/24/2014 04:57 PM, Reindl Harald wrote:
Am 24.01.2014 16:40, schrieb Ralf Corsepius:
On 01/24/2014 04:06 PM, Reindl Harald wrote:
a) This would blow away all installed packages, which aren't available in
permanently enabled repos
that is not true, try it out
Been there many times
lessons from fatal SELinux bug #1054350
Datum: Fri, 24 Jan 2014 16:06:21 +0100
Von: Reindl Harald h.rei...@thelounge.net
An: devel@lists.fedoraproject.org
Am 24.01.2014 15:55, schrieb Ralf Corsepius:
On 01/24/2014 01:39 PM, Kevin Kofler wrote:
Adam Williamson wrote:
Even if we can do
On Fri, 2014-01-24 at 10:58 +0100, Sergio Pascual wrote:
2014/1/24 Ralf Corsepius rc040...@freenet.de
Certainly, downgrading installations which already upgraded to
faulty packages would not work.
Ralf
The situation (a broken system
On Fri, 2014-01-24 at 13:36 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
TBH this has always been the one of Kevin's Big Book Of Update Policy
Complaints I find the most baffling. If we know you managed to screw up
your update once, why exactly would we just trust you to get it right
Am Freitag, den 24.01.2014, 00:55 +0100 schrieb Kevin Kofler:
it is time to analyze the fallout from the following catastrophic
Fedora 20
regression:
https://bugzilla.redhat.com/show_bug.cgi?id=1054350
rpm scriptlets are exiting with status 127
Hey,
can't we add a default boot entry which
On Fri, Jan 24, 2014 at 7:12 PM, Fabian Deutsch fabian.deut...@gmx.de wrote:
Am Freitag, den 24.01.2014, 00:55 +0100 schrieb Kevin Kofler:
it is time to analyze the fallout from the following catastrophic
Fedora 20
regression:
https://bugzilla.redhat.com/show_bug.cgi?id=1054350
rpm
On Fri, 24 Jan 2014 09:41:13 -0800
Adam Williamson awill...@redhat.com 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 btrfs-by-default in the
first place. I
On Fri, 24 Jan 2014 00:55:23 +0100, Kevin Kofler wrote:
it is time to analyze the fallout from the following catastrophic Fedora 20
regression:
https://bugzilla.redhat.com/show_bug.cgi?id=1054350
rpm scriptlets are exiting with status 127
* We are losing users to Ubuntu because of this
Am 24.01.2014 19:18, schrieb drago01:
On Fri, Jan 24, 2014 at 7:12 PM, Fabian Deutsch fabian.deut...@gmx.de wrote:
Am Freitag, den 24.01.2014, 00:55 +0100 schrieb Kevin Kofler:
it is time to analyze the fallout from the following catastrophic
Fedora 20
regression:
Am 24.01.2014 19:31, schrieb Reindl Harald:
Am 24.01.2014 19:18, schrieb drago01:
On Fri, Jan 24, 2014 at 7:12 PM, Fabian Deutsch fabian.deut...@gmx.de
wrote:
Am Freitag, den 24.01.2014, 00:55 +0100 schrieb Kevin Kofler:
it is time to analyze the fallout from the following catastrophic
Am Freitag, den 24.01.2014, 19:18 +0100 schrieb drago01:
On Fri, Jan 24, 2014 at 7:12 PM, Fabian Deutsch fabian.deut...@gmx.de wrote:
Am Freitag, den 24.01.2014, 00:55 +0100 schrieb Kevin Kofler:
it is time to analyze the fallout from the following catastrophic
Fedora 20
regression:
On Fri, Jan 24, 2014 at 1:37 PM, Fabian Deutsch fabian.deut...@gmx.de wrote:
How would that help? If a user knows enough about the issue to try it
he/she could just switch to permissive mode.
I mean, don't we have a general save boot / emergency boot entry -
we could add enforcing=0 there.
I
1 - 100 of 142 matches
Mail list logo
