On Jan 15, 2014 10:19 PM, "Michael Schwendt" wrote:
>
> > Anyone being familiar with "sunpinyin" please help with this
"re-review":
> > https://bugzilla.redhat.com/1043504
Well, the assignee is one of the Chinese packagers, still active in chinese
list.
I will see what I can do.
--
devel mailin
On Sun, Jan 19, 2014 at 4:55 AM, Juan Manuel Borges Caño
wrote:
> The packages built okay without the optional kernel module (to know,
> linux-fusion is the one), if that turns to be obligatory, again, i'd take
> alsa packaging as a cool example :)
ALSA kernel modules are included in the upstream
Hi,
On Sun, Jan 19, 2014 at 10:16 AM, Ville Skyttä wrote:
> On Sun, Jan 19, 2014 at 4:55 AM, Juan Manuel Borges Caño
> wrote:
> > The packages built okay without the optional kernel module (to know,
> > linux-fusion is the one), if that turns to be obligatory, again, i'd take
> > alsa packaging
On Sat, Jan 18, 2014 at 11:47:37PM -0500, Rahul Sundaram wrote:
> On Sat, Jan 18, 2014 at 8:20 PM, Andre Robatino wrote:
> > I replaced the typo scriplet -> scriptlet in several places in that page,
> > including the anchor link. Don't know if that breaks any existing links.
>
> Thanks. I just se
On Sun, 19 Jan 2014 12:23:42 -0500
Scott Schmit wrote:
> The text of the announcement made sense, but the link doesn't point to
> anything -- https://fedoraproject.org/wiki/Common_F20_bugs exists, but
> https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriplets_fail_during_updates
> doesn't poi
On Sun, Jan 19, 2014 at 12:23:42PM -0500, Scott Schmit wrote:
> On Sat, Jan 18, 2014 at 11:47:37PM -0500, Rahul Sundaram wrote:
> > On Sat, Jan 18, 2014 at 8:20 PM, Andre Robatino wrote:
> > > I replaced the typo scriplet -> scriptlet in several places in that page,
> > > including the anchor link.
On Sun, 19 Jan 2014 12:23:42 -0500
Scott Schmit wrote:
> On Sat, Jan 18, 2014 at 11:47:37PM -0500, Rahul Sundaram wrote:
> > On Sat, Jan 18, 2014 at 8:20 PM, Andre Robatino wrote:
> > > I replaced the typo scriplet -> scriptlet in several places in
> > > that page, including the anchor link. Don'
On Sat, Jan 18, 2014 at 9:47 PM, Rahul Sundaram wrote:
> Hi
>
> Since updates don't automatically fix the issue created by
> https://bugzilla.redhat.com/show_bug.cgi?id=1054350 and users are required
> to run a set of steps as a workaround, shouldn't this be announced via the
> fedora announce li
On Sun, 2014-01-19 at 19:15 +0100, drago01 wrote:
> On Sat, Jan 18, 2014 at 9:47 PM, Rahul Sundaram wrote:
> > Hi
> >
> > Since updates don't automatically fix the issue created by
> > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 and users are required
> > to run a set of steps as a workaro
On Sun, 19 Jan 2014 19:15:35 +0100
drago01 wrote:
> So it happened .. how do we prevent it in the future? How did it pass
> testing?
I don't think it got manually tested.
___
Regards,
Frank
www.frankly3d.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
On Sun, 19 Jan 2014 19:15:35 +0100, drago01 wrote:
> So it happened .. how do we prevent it in the future? How did it pass testing?
A first +1 vote 22 hours _before_ it entered the updates-testing repo.
A second +1 vote eight hours _before_ it entered the updates-testing repo.
A third +1 vote and
On Sun, Jan 19, 2014 at 7:34 PM, Michael Schwendt wrote:
> On Sun, 19 Jan 2014 19:15:35 +0100, drago01 wrote:
>
>> So it happened .. how do we prevent it in the future? How did it pass
>> testing?
>
> A first +1 vote 22 hours _before_ it entered the updates-testing repo.
> A second +1 vote eight
Hi
On Sun, Jan 19, 2014 at 1:34 PM, Michael Schwendt wrote:
> How to prevent it from happening in the future? The update criteria for
> the so-called critical path packages could be made more strict. A minimum
> time for updates to stay in the updates-testing repo. A higher karma
> threshold pr
On Sun, 19 Jan 2014 19:15:35 +0100
drago01 wrote:
> So it happened .. how do we prevent it in the future? How did it pass
> testing?
Would a gui yumex\PK have burped at the update?
Would the two testers have seen the script errors.
___
Regards,
Frank
www.frankly3d.com
--
devel mailing list
d
On Sun, 19 Jan 2014 20:32:26 +0200, Jonathan Dieter wrote:
> If scriptlet failures weren't fatal, we wouldn't have the problem we
> have now with duplicate packages. We could have just pushed the selinux
> update,
After installing the previous bad update that breaks scriptlets, how would
you act
On Sun, Jan 19, 2014 at 7:32 PM, Jonathan Dieter wrote:
> On Sun, 2014-01-19 at 19:15 +0100, drago01 wrote:
>> On Sat, Jan 18, 2014 at 9:47 PM, Rahul Sundaram wrote:
>> > Hi
>> >
>> > Since updates don't automatically fix the issue created by
>> > https://bugzilla.redhat.com/show_bug.cgi?id=10543
Am 19.01.2014 19:57, schrieb Michael Schwendt:
>> [...] then bumped the release for all updates in the last few pushes,
>> and then rebuilt them.
>
> How do you know which packages a user has tried to install/update _after_
> updating to the bad policy package? It could be any package within the
Am 19.01.2014 20:00, schrieb drago01:
> On Sun, Jan 19, 2014 at 7:32 PM, Jonathan Dieter wrote:
>> On Sun, 2014-01-19 at 19:15 +0100, drago01 wrote:
>>> On Sat, Jan 18, 2014 at 9:47 PM, Rahul Sundaram wrote:
Hi
Since updates don't automatically fix the issue created by
https
On Sun, 19 Jan 2014 18:48:57 +, Frank Murphy wrote:
> Would a gui yumex\PK have burped at the update?
Yes, because selinux-policy* is a low-level package not specific to Yum.
The policy affects RPM and everything on top of it.
> Would the two testers have seen the script errors.
Only during
On Sun, 19 Jan 2014 20:03:14 +0100, Reindl Harald wrote:
> this case is *very* special because you also need to realize *what*
> update before breaks the scriptlets and that it break all scriptlets
>
> zero chance to figure that out for 99 out of 100 users
>
> you only need to look at the amount
Am 19.01.2014 20:48, schrieb Michael Schwendt:
> On Sun, 19 Jan 2014 20:03:14 +0100, Reindl Harald wrote:
>
>> this case is *very* special because you also need to realize *what*
>> update before breaks the scriptlets and that it break all scriptlets
>>
>> zero chance to figure that out for 99 o
On Jan 19, 2014 8:57 PM, "Michael Schwendt" wrote:
>
> On Sun, 19 Jan 2014 20:32:26 +0200, Jonathan Dieter wrote:
>
> > If scriptlet failures weren't fatal, we wouldn't have the problem we
> > have now with duplicate packages. We could have just pushed the selinux
> > update,
>
> After installing
Anyone not aware of the problem and the fix, who applies the -117.fc20
selinux-policy update in _enforcing_ mode (since it has entered stable
updates meanwhile) believing it to be a normal update, will face another
failure and a partial update. Package selinux-policy updated
to -117.fc20 but -targe
On Mon, 2014-01-20 at 00:14 +0100, Michael Schwendt wrote:
> Anyone not aware of the problem and the fix, who applies the -117.fc20
> selinux-policy update in _enforcing_ mode (since it has entered stable
> updates meanwhile) believing it to be a normal update, will face another
> failure and a par
IMO a SOP need to be documented or linked to selinux-policy package update also.
BTW not all people run enforcing mode in daily time, so sometimes
problems may not be found easily.
Thanks.
--
--
Yours sincerely,
Christopher Meng
Noob here.
http://cicku.me
--
devel mailing list
devel@lists.f
Is it possible to build a one-time build of selinux-policy without
scriptlets so that the update will succeed?
On Sat, Jan 18, 2014 at 3:47 PM, Rahul Sundaram wrote:
> Hi
>
> Since updates don't automatically fix the issue created by
> https://bugzilla.redhat.com/show_bug.cgi?id=1054350 and use
Yeah, the packages as i built them, as i said, do not build the OPTIONAL
KERNEL MODULES, everything works anyway. Thanks, Ville Slytta, for the
insight in kernel module packaging in case at some point needs
consideration, again, NOT NOW as Ilyes Gouta repeats (and 1.7 is current).
If SDL2 IS DROPP
On Sun, 19 Jan 2014 23:02:24 -0500, Simo Sorce wrote:
> > Anyone not aware of the problem and the fix, who applies the -117.fc20
> > selinux-policy update in _enforcing_ mode (since it has entered stable
> > updates meanwhile) believing it to be a normal update, will face another
> > failure and a
On Mon, 20 Jan 2014 12:20:38 +0800, Christopher Meng wrote:
> IMO a SOP need to be documented or linked to selinux-policy package update
> also.
>
> BTW not all people run enforcing mode in daily time, so sometimes
> problems may not be found easily.
Running SELinux in enforcing mode is mandato
29 matches
Mail list logo
