Re: SELinux RPM scriplet issue annoucement
On Fri, 24 Jan 2014 22:36:02 -0800, Adam Williamson wrote: Note there's a GUI tool similar to easy karma called gooey karma, waiting for a package sponsor. We don't sponsor packages but packagers. ;) Actually, the review request has stalled, waiting for the reviewer (here also the sponsor because it's the packager's first package) to answer: https://bugzilla.redhat.com/1020839 And while some package submitters do attempt at contributing a few reviews, some don't, which makes the process more difficult if all they offer is a single package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
One note on that topic: I found myself giving karma to an update, while I tested different version (actually a completely different build). It would be good if giving karma would require to insert a hash or something generated from the package itself (rpm -q -qf something package), header or signature. Portal could check the hash and only accept karma for those users, who obviously installed the package. It could be optional as well. This could prevent mis-giving karma while testing different version of a package. The portal could instruct user to run specific one (short) command to get the hash and to put it in the form. This is just an idea. Question arises when the package consist of multiple subpackage (only to test the base one?) and also how much intrusive this would be for folks. -- Later, Lukas lzap Zapletal irc: lzap #theforeman -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
Am 24.01.2014 17:34, schrieb Lukas Zapletal: One note on that topic: I found myself giving karma to an update, while I tested different version (actually a completely different build). It would be good if giving karma would require to insert a hash or something generated from the package itself (rpm -q -qf something package), header or signature. Portal could check the hash and only accept karma for those users, who obviously installed the package. It could be optional as well. This could prevent mis-giving karma while testing different version of a package. The portal could instruct user to run specific one (short) command to get the hash and to put it in the form. This is just an idea. Question arises when the package consist of multiple subpackage (only to test the base one?) and also how much intrusive this would be for folks that could be easier solved by force anybody to use easy-karma instead the webinterface because that only asks for the current installed packages the only thing i wish is that fedora-easy-karma would support a param with a textfile containing the password because i hardly remember a 35 chars random password and so do it like below for CP from the terminal [root@srv-rhsoft:~]$ cat /scripts/easy-karma.sh #!/usr/bin/bash echo PASSWORT: ** fedora-easy-karma --fas-username=hreindl --default-comment=works for me signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
that could be easier solved by force anybody to use easy-karma instead the webinterface because that only asks for the current installed packages Oh, I did not know fedora-easy-karma. We should advertise with the update tickets on Bodhi perhaps. Actually this could improve things. -- Later, Lukas lzap Zapletal irc: lzap #theforeman -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
Lukas Zapletal l...@redhat.com wrote: that could be easier solved by force anybody to use easy-karma instead the webinterface because that only asks for the current installed packages Oh, I did not know fedora-easy-karma. We should advertise with the update tickets on Bodhi perhaps. Actually this could improve things. -- Later, Lukas lzap Zapletal irc: lzap #theforeman -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Note there's a GUI tool similar to easy karma called gooey karma, waiting for a package sponsor. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin DOT net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Tue, 2014-01-21 at 09:54 -0500, Matthias Clasen wrote: On Mon, 2014-01-20 at 23:18 -0800, Adam Williamson wrote: On Tue, 2014-01-21 at 01:01 -0600, Ian Pilcher wrote: On 01/20/2014 11:48 AM, Adam Williamson wrote: The bug currently under discussion was caused by a change that came in inadvertently, not intentionally, and was actually intended for Rawhide. I can't help wondering if there's an opportunity for process/workflow improvement right there. Well, I'd have to leave that to the SELinux folks to comment, but I would say it's only happened once since I came to Fedora that I remember, and everyone makes mistakes sometimes :/ Exactly. And because everybody makes mistakes, we have processes to catch and prevent those inevitable mistakes from going out. I think it would be great to make adjustments to the process / policy so that we get better at preventing this... In context, the question as I understood it was about the SELinux developers'/packagers' workflow, not the update workflow. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Tue, 21 Jan 2014 12:43:47 -0700 Luke Macken lmac...@redhat.com wrote: Unfortunately, bodhi has not had dedicated full-time development resources in a long time. Thankfully, I now have the cycles to put into new features, such as improving the feedback mechanisms. Many components of the Bodhi 2.0 vision are long-term, and rely on a plethora of other pieces to fall into place, such as python-fedora+fas-openid, koji+mash, taskotron, depcheck-mk-2, and so on. Other pieces of the puzzle can be implemented and deployed incrementally within the current tools now. My focus lately has been around the releng/infra side of the updates process, but for a feature that would make things 'immeasurably better' (even though I think it would actually be measurable :P), I'd be happy to shift gears to the QA/frontend side of things to help get it done sooner rather than later. As far as I can tell, you sent some ideas to a mailing list a few years ago about it, and then Mathieu started a prototype. I can't find any RFEs filed for it, so I'll create one and see what I can do about getting the existing prototype polished and integrated for testing. It would be absolutely lovely to get a bodhi-dev instance up on a cloud node running bodhi2 so we could see where we were and what needed to be worked on. Perhaps we could get interested folks together in irc sometime soon and discuss plans/status? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Wed, 2014-01-22 at 10:36 -0700, Kevin Fenzi wrote: On Tue, 21 Jan 2014 12:43:47 -0700 Luke Macken lmac...@redhat.com wrote: Unfortunately, bodhi has not had dedicated full-time development resources in a long time. Thankfully, I now have the cycles to put into new features, such as improving the feedback mechanisms. Many components of the Bodhi 2.0 vision are long-term, and rely on a plethora of other pieces to fall into place, such as python-fedora+fas-openid, koji+mash, taskotron, depcheck-mk-2, and so on. Other pieces of the puzzle can be implemented and deployed incrementally within the current tools now. My focus lately has been around the releng/infra side of the updates process, but for a feature that would make things 'immeasurably better' (even though I think it would actually be measurable :P), I'd be happy to shift gears to the QA/frontend side of things to help get it done sooner rather than later. As far as I can tell, you sent some ideas to a mailing list a few years ago about it, and then Mathieu started a prototype. I can't find any RFEs filed for it, so I'll create one and see what I can do about getting the existing prototype polished and integrated for testing. It would be absolutely lovely to get a bodhi-dev instance up on a cloud node running bodhi2 so we could see where we were and what needed to be worked on. Perhaps we could get interested folks together in irc sometime soon and discuss plans/status? I'd certainly be up for that. The thing I think would be most useful is just a lot more flexibility over the karma definition: ideally the back end should be extremely generic, a sort of set of possible conditions you can glue together any way you like, and we'd provide some common 'templates' for use in updates (and sensible defaults, of course). The Glorious Vision email still pretty much holds true, I believe, if you can still find it (yell if you can't, and I will). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Wed, Jan 22, 2014 at 8:55 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2014-01-22 at 10:36 -0700, Kevin Fenzi wrote: On Tue, 21 Jan 2014 12:43:47 -0700 Luke Macken lmac...@redhat.com wrote: Unfortunately, bodhi has not had dedicated full-time development resources in a long time. Thankfully, I now have the cycles to put into new features, such as improving the feedback mechanisms. Many components of the Bodhi 2.0 vision are long-term, and rely on a plethora of other pieces to fall into place, such as python-fedora+fas-openid, koji+mash, taskotron, depcheck-mk-2, and so on. Other pieces of the puzzle can be implemented and deployed incrementally within the current tools now. My focus lately has been around the releng/infra side of the updates process, but for a feature that would make things 'immeasurably better' (even though I think it would actually be measurable :P), I'd be happy to shift gears to the QA/frontend side of things to help get it done sooner rather than later. As far as I can tell, you sent some ideas to a mailing list a few years ago about it, and then Mathieu started a prototype. I can't find any RFEs filed for it, so I'll create one and see what I can do about getting the existing prototype polished and integrated for testing. It would be absolutely lovely to get a bodhi-dev instance up on a cloud node running bodhi2 so we could see where we were and what needed to be worked on. Perhaps we could get interested folks together in irc sometime soon and discuss plans/status? I'd certainly be up for that. The thing I think would be most useful is just a lot more flexibility over the karma definition: ideally the back end should be extremely generic, a sort of set of possible conditions you can glue together any way you like, and we'd provide some common 'templates' for use in updates (and sensible defaults, of course). The Glorious Vision email still pretty much holds true, I believe, if you can still find it (yell if you can't, and I will). While at it ... can it be less paranoid about who can edit updates please? It is overly restrictive for no real reason. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Wed, 2014-01-22 at 21:25 +0100, drago01 wrote: On Wed, Jan 22, 2014 at 8:55 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2014-01-22 at 10:36 -0700, Kevin Fenzi wrote: On Tue, 21 Jan 2014 12:43:47 -0700 Luke Macken lmac...@redhat.com wrote: Unfortunately, bodhi has not had dedicated full-time development resources in a long time. Thankfully, I now have the cycles to put into new features, such as improving the feedback mechanisms. Many components of the Bodhi 2.0 vision are long-term, and rely on a plethora of other pieces to fall into place, such as python-fedora+fas-openid, koji+mash, taskotron, depcheck-mk-2, and so on. Other pieces of the puzzle can be implemented and deployed incrementally within the current tools now. My focus lately has been around the releng/infra side of the updates process, but for a feature that would make things 'immeasurably better' (even though I think it would actually be measurable :P), I'd be happy to shift gears to the QA/frontend side of things to help get it done sooner rather than later. As far as I can tell, you sent some ideas to a mailing list a few years ago about it, and then Mathieu started a prototype. I can't find any RFEs filed for it, so I'll create one and see what I can do about getting the existing prototype polished and integrated for testing. It would be absolutely lovely to get a bodhi-dev instance up on a cloud node running bodhi2 so we could see where we were and what needed to be worked on. Perhaps we could get interested folks together in irc sometime soon and discuss plans/status? I'd certainly be up for that. The thing I think would be most useful is just a lot more flexibility over the karma definition: ideally the back end should be extremely generic, a sort of set of possible conditions you can glue together any way you like, and we'd provide some common 'templates' for use in updates (and sensible defaults, of course). The Glorious Vision email still pretty much holds true, I believe, if you can still find it (yell if you can't, and I will). While at it ... can it be less paranoid about who can edit updates please? It is overly restrictive for no real reason. Yeah, that's a real problem for teams working on multi-package updates, it seems. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Mon, 2014-01-20 at 23:18 -0800, Adam Williamson wrote: On Tue, 2014-01-21 at 01:01 -0600, Ian Pilcher wrote: On 01/20/2014 11:48 AM, Adam Williamson wrote: The bug currently under discussion was caused by a change that came in inadvertently, not intentionally, and was actually intended for Rawhide. I can't help wondering if there's an opportunity for process/workflow improvement right there. Well, I'd have to leave that to the SELinux folks to comment, but I would say it's only happened once since I came to Fedora that I remember, and everyone makes mistakes sometimes :/ Exactly. And because everybody makes mistakes, we have processes to catch and prevent those inevitable mistakes from going out. I think it would be great to make adjustments to the process / policy so that we get better at preventing this... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Mon, Jan 20, 2014 at 05:01:24PM -0800, Adam Williamson wrote: On Mon, 2014-01-20 at 17:00 -0800, Adam Williamson wrote: On Mon, 2014-01-20 at 15:35 -0500, Matthew Miller wrote: On Mon, Jan 20, 2014 at 09:48:28AM -0800, Adam Williamson wrote: I'd suggest this test should be a high priority for implementation once taskotron is operational, perhaps equal in importance to re-implementing the current AutoQA tests. *nod* Sounds good to me. what we have. I don't know how to quantify that point, though. All's I can do is reiterate that yes, this is a really significant pain point in our current processes, the proposed Bodhi 2.0 design would make things almost immeasurably better, and plead with anyone reading this who has the power to bump up the importance of / resources assigned to Bodhi 2.0's development to do so. So many things at top priority. :) I know Luke Macken is actually actively working it. I know he is. He's been actively working on it for the said three-four year period. Every FUDCon/Flock he tells me it's nearly done. ;) Not ragging Luke, but it rather seems like we need about six more of Unfortunately, bodhi has not had dedicated full-time development resources in a long time. Thankfully, I now have the cycles to put into new features, such as improving the feedback mechanisms. Many components of the Bodhi 2.0 vision are long-term, and rely on a plethora of other pieces to fall into place, such as python-fedora+fas-openid, koji+mash, taskotron, depcheck-mk-2, and so on. Other pieces of the puzzle can be implemented and deployed incrementally within the current tools now. My focus lately has been around the releng/infra side of the updates process, but for a feature that would make things 'immeasurably better' (even though I think it would actually be measurable :P), I'd be happy to shift gears to the QA/frontend side of things to help get it done sooner rather than later. As far as I can tell, you sent some ideas to a mailing list a few years ago about it, and then Mathieu started a prototype. I can't find any RFEs filed for it, so I'll create one and see what I can do about getting the existing prototype polished and integrated for testing. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Mon, 20 Jan 2014 01:53:42 -0500, Nathaniel McCallum wrote: Is it possible to build a one-time build of selinux-policy without scriptlets so that the update will succeed? Define what you mean with update will succeed. Simply replacing the bad package with a new package doesn't fix it. The selinux-policy-targeted scriptlets run some stuff to activate the changed policy. See: rpm -q --scripts selinux-policy-targeted Some of that would need to be run manually, at least. Also don't forget other updates in the same transaction. They won't install without problems as long as RPM scriptlets don't execute. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/2014 04:42 AM, Michael Schwendt wrote: I think we should have a much higher Karma for SELinux-policy to be released. 5 or maybe 10. The problem with selinux-policy is it gets karma fast, since each update fixes multiple bugs. And people just update it, see if it fixes their bug, then the tester updates the karma. As has been said, the update broke the next update. Which no one caught. Forcing it to wait a week would probably not be a bad idea. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLdO8AACgkQrlYvE4MpobMbagCgsdkkZA2mSPvku/mrUlS6aOZu fKQAoKmGHU0kJJZilPXWULTKL6ZyG7MC =Tmvz -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Mon, 2014-01-20 at 08:42 +0100, Michael Schwendt wrote: 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 partial update. Package selinux-policy updated to -117.fc20 but -targeted remaining at -116.fc20. I don't see this. I just updated today before reading this message (and I haven;t read the whole thread, sorry) and I got selinux-policy and targeted updated without any problem (I always run in enforcing mode). Did you update from -116.fc20 or an earlier one? Only if you come from -116.fc20, you would be affected, since -116.fc20 is the bad update. Ah I think I skipped 116, sorry for the noise. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Sat, 2014-01-18 at 15:06 -0700, Kevin Fenzi wrote: On Sat, 18 Jan 2014 15:47:38 -0500 Rahul Sundaram methe...@gmail.com 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 list and posted in the Fedora website prominently as well? I would think a detailed common bugs entry and then a short announcement pointing to that would be good. Would someone be able to write up the common bug entry? Adam? :) Many apologies for not helping out with this process, folks, and big thanks to others for picking up the slack (especially Rahul) - I was distracted by other shinies over the weekend, I'm afraid! I had this on my radar, but it looks like those involved did a great job, and I'd only have gotten in the way. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Sun, Jan 19, 2014 at 08:10:29PM +0100, Michael Schwendt wrote: A simple yum -y update ; reboot ; Oh, everything seems to work has not been enough this time. And it was an update with a screen full of ticket numbers for the included bug-fixes/changes. It could have broken something else, too. Once we have a better automation framework in place, we can have tests like: install selinux update, reboot, install (special) test package version 1, update to test package version 2. (In addition to a series of other things that should work with selinux enabled.) Btw, some other packages are in the same boat. Imagine a graphics driver update seems to work for three testers that are required for a +3 vote in the updates system, but fails badly for a hundred other users once it appears in the stable updates repo. That's a little harder, of course. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/2014 10:50 AM, Simo Sorce wrote: On Mon, 2014-01-20 at 08:42 +0100, Michael Schwendt wrote: 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 partial update. Package selinux-policy updated to -117.fc20 but -targeted remaining at -116.fc20. I don't see this. I just updated today before reading this message (and I haven;t read the whole thread, sorry) and I got selinux-policy and targeted updated without any problem (I always run in enforcing mode). Did you update from -116.fc20 or an earlier one? Only if you come from -116.fc20, you would be affected, since -116.fc20 is the bad update. Ah I think I skipped 116, sorry for the noise. Simo. Lucky man, hopefully a lot of users skipped it... -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLdXA4ACgkQrlYvE4MpobObvwCgrvA8ndAn5zBUpWA/LvO3fCUw qKUAoLHkon72qLTudvb/5LsHguzzt8Rg =8cRf -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Mon, 2014-01-20 at 12:17 -0500, Matthew Miller wrote: On Sun, Jan 19, 2014 at 08:10:29PM +0100, Michael Schwendt wrote: A simple yum -y update ; reboot ; Oh, everything seems to work has not been enough this time. And it was an update with a screen full of ticket numbers for the included bug-fixes/changes. It could have broken something else, too. Once we have a better automation framework in place, we can have tests like: install selinux update, reboot, install (special) test package version 1, update to test package version 2. (In addition to a series of other things that should work with selinux enabled.) Btw, some other packages are in the same boat. Imagine a graphics driver update seems to work for three testers that are required for a +3 vote in the updates system, but fails badly for a hundred other users once it appears in the stable updates repo. That's a little harder, of course. So I've read through this thread now. A few notes: 1) The precise nature of the failure here makes it a tricky issue to deal with. We actually already know that this kind of 'delayed action' bug is a tricky scenario to deal with, because we already have a whole pretty well-known *category* of similar bugs: scriptlet errors themselves. As Harald has pointed out, scriptlet errors are very messy bugs that our current testing process is very poor at catching. If anyone's not familiar with the scriptlet error category, see https://fedoraproject.org/wiki/Common_F20_bugs#preun-fail . So while the idea of an SELinux-specific 'update it, then update it again' test case seems to make superficial sense, it's not actually an SELinux-specific test. We should in fact be doing this for *all* updates, or at the least, all updates that include any scriptlets. However, it's not even that simple, because this is something that makes much more sense to test in an automated way than manually - even more so than many things. This specific bug was a bit easier to test than the scriptlet case, because you just had to update *any other* package after updating selinux-policy to see the bug, but it's clearly in the same category as the more difficult case, and we should come up with an approach that handles them all. What looks like the right approach has already been suggested in the FESCo ticket on this: an automated test that takes the update, bumps the spec one revision and tries to update. So if the update is foo-1.1-2, the test would build a foo-1.1-3 package with no other changes, and try updating from 1.1-2 to 1.1-3. Doing this manually is of course a PITA and it's really a _very_ clear candidate for automation. Such a test would, I believe, have caught the bug. As posted to FESCo, though, it's still the case that we're working on the automation framework at present and the tests come after that. We are aiming to have the framework operational for the F21 cycle, AIUI, and it may be plausible to implement this test during that cycle. As such a test has several very desirable attributes - i.e. it catches bugs which: 1) cause serious problems that are difficult to recover from 2) we are currently very bad at catching manually 3) would be difficult and onerous to reliably catch manually even with improved manual testing procedures I'd suggest this test should be a high priority for implementation once taskotron is operational, perhaps equal in importance to re-implementing the current AutoQA tests. (Harald is probably correct to note that another bug of precisely this type might result in 'innocent' updates being 'blamed' for being broken, but we'd at least have a clear indication that something was seriously boned, and could investigate/clean up manually - the proposed automated test wouldn't make anything worse than it currently is). 1b) Just in case anyone had forgotten, though, we do have the infrastructure for creating package-specific test cases that get integrated with Bodhi to an extent, even though I don't think that's the way to go in this particular case: see https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation . 2) I already suggested to the SELinux devs on test@ that perhaps selinux-policy updates should have a higher autokarma threshold, and they agreed this might be a good idea. It would also be possible for them to disable autopush for selinux-policy updates and handle pushing them manually, based on whatever policy they choose, though of course that's more work than using autopush. 3) Someone noted that big selinux-policy updates are 'scary'. I think to be fair to the SELinux devs it's worth noting they push big updates all the time, with a very high success record. This is the first time I can recall a bug anywhere near this serious happening with an SELinux update to a stable release. AIUI, they have a very sensible policy for stable release updates, which is that except in very exceptional cases, updates can only make the policy *more liberal*, they cannot make it
Re: SELinux RPM scriplet issue annoucement
On Sun, 2014-01-19 at 12:30 -0500, Scott Schmit wrote: 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. Don't know if that breaks any existing links. Thanks. I just sent out the announcement. Hopefully it makes sense. 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 point to anything on the page. Weird -- I loaded the page again and now it shows up, but I still have it in another tab the other way, so I know it wasn't just that I had missed it. Maybe there are multiple mirrors at play that aren't all in sync? I've found anchors on the Fedora wiki to be very unreliable in general, but never had time/inclination to look into it systematically. I just make sure the pages I write are set up correctly and figure that if the implementation is broken it ain't my problem. :P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Mon, Jan 20, 2014 at 09:48:28AM -0800, Adam Williamson wrote: I'd suggest this test should be a high priority for implementation once taskotron is operational, perhaps equal in importance to re-implementing the current AutoQA tests. *nod* Sounds good to me. what we have. I don't know how to quantify that point, though. All's I can do is reiterate that yes, this is a really significant pain point in our current processes, the proposed Bodhi 2.0 design would make things almost immeasurably better, and plead with anyone reading this who has the power to bump up the importance of / resources assigned to Bodhi 2.0's development to do so. So many things at top priority. :) I know Luke Macken is actually actively working it. Immeasurably better sounds pretty good, although it's a shame it isn't measurably better. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On 01/20/2014 06:48 PM, Adam Williamson wrote: On Mon, 2014-01-20 at 12:17 -0500, Matthew Miller wrote: On Sun, Jan 19, 2014 at 08:10:29PM +0100, Michael Schwendt wrote: A simple yum -y update ; reboot ; Oh, everything seems to work has not been enough this time. And it was an update with a screen full of ticket numbers for the included bug-fixes/changes. It could have broken something else, too. Once we have a better automation framework in place, we can have tests like: install selinux update, reboot, install (special) test package version 1, update to test package version 2. (In addition to a series of other things that should work with selinux enabled.) Btw, some other packages are in the same boat. Imagine a graphics driver update seems to work for three testers that are required for a +3 vote in the updates system, but fails badly for a hundred other users once it appears in the stable updates repo. That's a little harder, of course. So I've read through this thread now. A few notes: 1) The precise nature of the failure here makes it a tricky issue to deal with. We actually already know that this kind of 'delayed action' bug is a tricky scenario to deal with, because we already have a whole pretty well-known *category* of similar bugs: scriptlet errors themselves. As Harald has pointed out, scriptlet errors are very messy bugs that our current testing process is very poor at catching. If anyone's not familiar with the scriptlet error category, see https://fedoraproject.org/wiki/Common_F20_bugs#preun-fail . So while the idea of an SELinux-specific 'update it, then update it again' test case seems to make superficial sense, it's not actually an SELinux-specific test. We should in fact be doing this for *all* updates, or at the least, all updates that include any scriptlets. However, it's not even that simple, because this is something that makes much more sense to test in an automated way than manually - even more so than many things. This specific bug was a bit easier to test than the scriptlet case, because you just had to update *any other* package after updating selinux-policy to see the bug, but it's clearly in the same category as the more difficult case, and we should come up with an approach that handles them all. What looks like the right approach has already been suggested in the FESCo ticket on this: an automated test that takes the update, bumps the spec one revision and tries to update. So if the update is foo-1.1-2, the test would build a foo-1.1-3 package with no other changes, and try updating from 1.1-2 to 1.1-3. Doing this manually is of course a PITA and it's really a _very_ clear candidate for automation. Such a test would, I believe, have caught the bug. As posted to FESCo, though, it's still the case that we're working on the automation framework at present and the tests come after that. We are aiming to have the framework operational for the F21 cycle, AIUI, and it may be plausible to implement this test during that cycle. As such a test has several very desirable attributes - i.e. it catches bugs which: 1) cause serious problems that are difficult to recover from 2) we are currently very bad at catching manually 3) would be difficult and onerous to reliably catch manually even with improved manual testing procedures I'd suggest this test should be a high priority for implementation once taskotron is operational, perhaps equal in importance to re-implementing the current AutoQA tests. (Harald is probably correct to note that another bug of precisely this type might result in 'innocent' updates being 'blamed' for being broken, but we'd at least have a clear indication that something was seriously boned, and could investigate/clean up manually - the proposed automated test wouldn't make anything worse than it currently is). 1b) Just in case anyone had forgotten, though, we do have the infrastructure for creating package-specific test cases that get integrated with Bodhi to an extent, even though I don't think that's the way to go in this particular case: see https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation . 2) I already suggested to the SELinux devs on test@ that perhaps selinux-policy updates should have a higher autokarma threshold, and they agreed this might be a good idea. It would also be possible for them to disable autopush for selinux-policy updates and handle pushing them manually, based on whatever policy they choose, though of course that's more work than using autopush. 3) Someone noted that big selinux-policy updates are 'scary'. I think to be fair to the SELinux devs it's worth noting they push big updates all the time, with a very high success record. This is the first time I can recall a bug anywhere near this serious happening with an SELinux update to a stable release. AIUI, they have a very sensible policy for stable release updates, which is that except in very exceptional cases, updates can only make the policy *more
Re: SELinux RPM scriplet issue annoucement
On Mon, 2014-01-20 at 15:35 -0500, Matthew Miller wrote: On Mon, Jan 20, 2014 at 09:48:28AM -0800, Adam Williamson wrote: I'd suggest this test should be a high priority for implementation once taskotron is operational, perhaps equal in importance to re-implementing the current AutoQA tests. *nod* Sounds good to me. what we have. I don't know how to quantify that point, though. All's I can do is reiterate that yes, this is a really significant pain point in our current processes, the proposed Bodhi 2.0 design would make things almost immeasurably better, and plead with anyone reading this who has the power to bump up the importance of / resources assigned to Bodhi 2.0's development to do so. So many things at top priority. :) I know Luke Macken is actually actively working it. I know he is. He's been actively working on it for the said three-four year period. Every FUDCon/Flock he tells me it's nearly done. ;) Not ragging Luke, but it rather seems like we need about six more of him. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Mon, 2014-01-20 at 17:00 -0800, Adam Williamson wrote: On Mon, 2014-01-20 at 15:35 -0500, Matthew Miller wrote: On Mon, Jan 20, 2014 at 09:48:28AM -0800, Adam Williamson wrote: I'd suggest this test should be a high priority for implementation once taskotron is operational, perhaps equal in importance to re-implementing the current AutoQA tests. *nod* Sounds good to me. what we have. I don't know how to quantify that point, though. All's I can do is reiterate that yes, this is a really significant pain point in our current processes, the proposed Bodhi 2.0 design would make things almost immeasurably better, and plead with anyone reading this who has the power to bump up the importance of / resources assigned to Bodhi 2.0's development to do so. So many things at top priority. :) I know Luke Macken is actually actively working it. I know he is. He's been actively working on it for the said three-four year period. Every FUDCon/Flock he tells me it's nearly done. ;) Not ragging Luke, but it rather seems like we need about six more of him. Oh, and naturally, every FUDCon/Flock we tell him that Taskotron will be rolling out any week now ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On 01/20/2014 11:48 AM, Adam Williamson wrote: The bug currently under discussion was caused by a change that came in inadvertently, not intentionally, and was actually intended for Rawhide. I can't help wondering if there's an opportunity for process/workflow improvement right there. -- Ian Pilcher arequip...@gmail.com Sent from the cloud -- where it's already tomorrow -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Tue, 2014-01-21 at 01:01 -0600, Ian Pilcher wrote: On 01/20/2014 11:48 AM, Adam Williamson wrote: The bug currently under discussion was caused by a change that came in inadvertently, not intentionally, and was actually intended for Rawhide. I can't help wondering if there's an opportunity for process/workflow improvement right there. Well, I'd have to leave that to the SELinux folks to comment, but I would say it's only happened once since I came to Fedora that I remember, and everyone makes mistakes sometimes :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
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 sent out the announcement. Hopefully it makes sense. 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 point to anything on the page. smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Sun, 19 Jan 2014 12:23:42 -0500 Scott Schmit i.g...@comcast.net 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 point to anything on the page. Points to this: RPM scriptlets fail during updates Just clicked on it. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
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. Don't know if that breaks any existing links. Thanks. I just sent out the announcement. Hopefully it makes sense. 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 point to anything on the page. Weird -- I loaded the page again and now it shows up, but I still have it in another tab the other way, so I know it wasn't just that I had missed it. Maybe there are multiple mirrors at play that aren't all in sync? smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Sun, 19 Jan 2014 12:23:42 -0500 Scott Schmit i.g...@comcast.net 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't know if that breaks any existing links. Thanks. I just sent out the announcement. Hopefully it makes sense. 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 ^ Got it you have the wrong link, that is not the one posted in announce from announce https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriptlets_fail_during_updates ^^ ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Sat, Jan 18, 2014 at 9:47 PM, Rahul Sundaram methe...@gmail.com 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 list and posted in the Fedora website prominently as well? So it happened .. how do we prevent it in the future? How did it pass testing? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Sun, 2014-01-19 at 19:15 +0100, drago01 wrote: On Sat, Jan 18, 2014 at 9:47 PM, Rahul Sundaram methe...@gmail.com 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 list and posted in the Fedora website prominently as well? So it happened .. how do we prevent it in the future? How did it pass testing? Should we modify rpm so scriptlet failures aren't fatal? This is the second time in the last six months or so that I've seen scriptlet failures cause major update problems in Fedora, solely because they are fatal (see https://bugzilla.redhat.com/show_bug.cgi?id=989145). 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, then bumped the release for all updates in the last few pushes, and then rebuilt them. If some of the scriptlets were vitally important, they would get run with the new updates. Am I missing something? Is there any reason why scriptlet failures should be fatal? Jonathan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Sun, 19 Jan 2014 19:15:35 +0100 drago01 drag...@gmail.com 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/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
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 automatic push to stable two hours after it had entered updates-testing: https://admin.fedoraproject.org/updates/FEDORA-2014-0806/selinux-policy-3.12.1-116.fc20 It has not been offered long enough for more testers to give it a try. For example, here it had not been picked up by the nearby mirror yet when the karma threshold was reached. By the time it had arrived and the first scriptlet errors were noticed and required a closer look to find the culprit, the update had been pushed to stable already. 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 probably won't be sufficient, if testers aim at speed instead of safety. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Sun, Jan 19, 2014 at 7:34 PM, Michael Schwendt mschwe...@gmail.com 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 hours _before_ it entered the updates-testing repo. A third +1 vote and automatic push to stable two hours after it had entered updates-testing: https://admin.fedoraproject.org/updates/FEDORA-2014-0806/selinux-policy-3.12.1-116.fc20 It has not been offered long enough for more testers to give it a try. For example, here it had not been picked up by the nearby mirror yet when the karma threshold was reached. By the time it had arrived and the first scriptlet errors were noticed and required a closer look to find the culprit, the update had been pushed to stable already. OK. 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 probably won't be sufficient, if testers aim at speed instead of safety. Yeah that makes sense. (Automated tests that do test basic stuff would help as well). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
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 probably won't be sufficient, if testers aim at speed instead of safety. Sounds reasonable. Filed a ticket at https://fedorahosted.org/fesco/ticket/1223 Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Sun, 19 Jan 2014 19:15:35 +0100 drago01 drag...@gmail.com 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
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 activate the new selinux policy within the fixed package's %post scriptlet? Instead of updating to the package in permissive mode, you would need to run the scriptlet contents manually *and* still reinstall any package were the scriptlets failed. [...] 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 package collection that would remain installed but broken because of the scriptlets bug. You assume that users have only applied the few updates following the bad selinux policy update. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Sun, Jan 19, 2014 at 7:32 PM, Jonathan Dieter jdie...@lesbg.com wrote: On Sun, 2014-01-19 at 19:15 +0100, drago01 wrote: On Sat, Jan 18, 2014 at 9:47 PM, Rahul Sundaram methe...@gmail.com 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 list and posted in the Fedora website prominently as well? So it happened .. how do we prevent it in the future? How did it pass testing? Should we modify rpm so scriptlet failures aren't fatal? This is the second time in the last six months or so that I've seen scriptlet failures cause major update problems in Fedora, solely because they are fatal (see https://bugzilla.redhat.com/show_bug.cgi?id=989145). Well updates should be atomic so you either have the previous (working) start or the new working state and thing in between. Yes this requires a bit of work but isn't impossible (requires some infra at a lower level though). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
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 package collection that would remain installed but broken because of the scriptlets bug. You assume that users have only applied the few updates following the bad selinux policy update 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 of reports that other packages seems to be broken to get the picture that case seems to be unavoidable without force every packager of critical path updates to test them manually before they appear in updates-testing and on bodhi at all and to catch the specific case push the updates to testing after at least on their machine a independent update was applied without problems - unlikely to happen signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
Am 19.01.2014 20:00, schrieb drago01: On Sun, Jan 19, 2014 at 7:32 PM, Jonathan Dieter jdie...@lesbg.com wrote: On Sun, 2014-01-19 at 19:15 +0100, drago01 wrote: On Sat, Jan 18, 2014 at 9:47 PM, Rahul Sundaram methe...@gmail.com 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 list and posted in the Fedora website prominently as well? So it happened .. how do we prevent it in the future? How did it pass testing? Should we modify rpm so scriptlet failures aren't fatal? This is the second time in the last six months or so that I've seen scriptlet failures cause major update problems in Fedora, solely because they are fatal (see https://bugzilla.redhat.com/show_bug.cgi?id=989145). Well updates should be atomic so you either have the previous (working) start or the new working state and thing in between. Yes this requires a bit of work but isn't impossible (requires some infra at a lower level though) which would mean disallow scriptlets at all - but you hardly can do anything scriptlets are doing in a different way one problem is that many scriptlets are not that important or fail only on the second update still containing them after already applied - in that cases have them non-fatal would avoid dupes with no harm IMHO this problem is not solveable signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
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 *subsequent* attempts at updating to or installing *more* packages containing scriptlets - prior to giving +1 in the Fedora Updates System. A simple yum -y update ; reboot ; Oh, everything seems to work has not been enough this time. And it was an update with a screen full of ticket numbers for the included bug-fixes/changes. It could have broken something else, too. Btw, some other packages are in the same boat. Imagine a graphics driver update seems to work for three testers that are required for a +3 vote in the updates system, but fails badly for a hundred other users once it appears in the stable updates repo. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
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 of reports that other packages seems to be broken to get the picture True. However, it's not the Fedora product's users who do the testing, but brave testers with updates-testing enabled, who evaluate packages _before_ they get pushed into the stable updates repo. All the ordinary users, who thought that the nfs-utils update contained a bad scriptlet, assumed that such a bug has slipped through the Fedora testing process. What does that tell about quality of Fedora testing? ;) Other users have reported the same issue for initscripts and other packages. What these people have in common is that they have noticed the scriptlet errors and have opened a ticket in bugzilla. IMO, testers would have noticed it too, if the test update had been offered in the updates-testing repo for a longer time. It simply won't work well, if testing is a race for the fastest +1 votes. I wonder what a tester would have done when encountering a scriptlet error, if the bad selinux package had not been marked stable yet? Would it have led to a -1 on the wrong package? The nfs-utils update has been pushed to stable with +3 one day after the bad selinux policy. that case seems to be unavoidable without force every packager of critical path updates to test them manually before they appear in updates-testing and on bodhi at all and to catch the specific case push the updates to testing after at least on their machine a independent update was applied without problems - unlikely to happen Why that? Why the manual installation? There is no need to rush when voting in bodhi. Such a selinux policy update with many changes is _scary_. Come on, Fedora 20 has been released already after a long development/testing cycle. Why take the risk of breaking it with large updates that are rushed out? Where the released product is broken already since day zero, a few more days of testing the fixes don't hurt. One of the fundamental actions that critical path package updates must be able to complete is get updates. That means that after a full yum -y update to fetch a latest batch of Test Updates, the tester must attempt at triggering further system updates. A downgrade of some packages may be enough to test a subsequent manual yum update, at least. Alternatively, wait for the next updates/test-updates to appear in the repos, but what about automatic updates and update notifications?. Good, if Yum still works, at least. But that doesn't mean testers should neglect the graphical package tools and system update mechanisms many other users will depend on. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
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 out of 100 users you only need to look at the amount of reports that other packages seems to be broken to get the picture True. However, it's not the Fedora product's users who do the testing, but brave testers with updates-testing enabled, who evaluate packages _before_ they get pushed into the stable updates repo. All the ordinary users, who thought that the nfs-utils update contained a bad scriptlet, assumed that such a bug has slipped through the Fedora testing process. What does that tell about quality of Fedora testing? ;) i know, in a perfect world it does not happen Other users have reported the same issue for initscripts and other packages. What these people have in common is that they have noticed the scriptlet errors and have opened a ticket in bugzilla. IMO, testers would have noticed it too, if the test update had been offered in the updates-testing repo for a longer time. in that case - no testers also hardly had realized the responsible package said from one running updates-testing and often koji over years on my machines It simply won't work well, if testing is a race for the fastest +1 votes depends on the test matrix and package I wonder what a tester would have done when encountering a scriptlet error, if the bad selinux package had not been marked stable yet? Would it have led to a -1 on the wrong package? most likely The nfs-utils update has been pushed to stable with +3 one day after the bad selinux policy. which says not much most of my servers have selinux completly disabled so the selinux policy can be as broken as possible but that does not mean that i can't qualify a qt, kde, samba or whatever package which works as expected in my workloads that case seems to be unavoidable without force every packager of critical path updates to test them manually before they appear in updates-testing and on bodhi at all and to catch the specific case push the updates to testing after at least on their machine a independent update was applied without problems - unlikely to happen Why that? Why the manual installation? because i faced too much packages in updates-testing at all 3 days after build that hardly broken or not installable at all where i honestly ask has the packager ever instaleld it on one of his systems There is no need to rush when voting in bodhi. Such a selinux policy update with many changes is _scary_. Come on, Fedora 20 has been released already after a long development/testing cycle. Why take the risk of breaking it with large updates that are rushed out? Where the released product is broken already since day zero, a few more days of testing the fixes don't hurt. for that package yes on the other hand there are enough small bugs where it is even hard to realize what package / library is really responsible and library updates with a complete reboot and some hours qualify at least there is not more broken then before and in the best case it fixes issues for others or at least does not more harm then before One of the fundamental actions that critical path package updates must be able to complete is get updates. That means that after a full yum -y update to fetch a latest batch of Test Updates, the tester must attempt at triggering further system updates that is what i am doing always before give karma: * rebuild one of my self maintained packages * they all get MMDD in the %release automatically * run a yum update and verify YUM/RPM works but what about automatic updates and update notifications?. Good, if Yum still works, at least. But that doesn't mean testers should neglect the graphical package tools and system update mechanisms many other users will depend on expect that testers are using only yum for several reasons and many of them even uninstalled all that graphical package stuff if possible by cross-dependencies, that won't change in the future as long nobody takes away the CLI completly which drives away that users completly signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Jan 19, 2014 8:57 PM, Michael Schwendt mschwe...@gmail.com 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 the previous bad update that breaks scriptlets, how would you activate the new selinux policy within the fixed package's %post scriptlet? Instead of updating to the package in permissive mode, you would need to run the scriptlet contents manually *and* still reinstall any package were the scriptlets failed. I was focusing on the fact that scriptlet failures lead to duplicates in the rpm database, but, you're right, it's not the main problem. I still think there's a good case for making scriptlet errors non - fatal, but, in this situation, it would have had a minimal benefit. [...] 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 package collection that would remain installed but broken because of the scriptlets bug. You assume that users have only applied the few updates following the bad selinux policy update. ACK. I didn't think this part through properly. Jonathan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
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 -targeted remaining at -116.fc20. Fixing that with the instructions in the Wiki wouldn't work, # yum update selinux-policy Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit No packages marked for update since selinux-policy package is up-to-date. The enhanced fix that adds '\*' works also for this extra problem: setenforce 0 yum clean expire-cache yum update selinux-policy\* setenforce 1 [...] Here's the full reproducer: # yum update Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package selinux-policy.noarch 0:3.12.1-116.fc20 will be updated --- Package selinux-policy.noarch 0:3.12.1-117.fc20 will be an update --- Package selinux-policy-targeted.noarch 0:3.12.1-116.fc20 will be updated --- Package selinux-policy-targeted.noarch 0:3.12.1-117.fc20 will be an update -- Finished Dependency Resolution Dependencies Resolved == == Package Arch Version Repository Size == == Updating: selinux-policy noarch 3.12.1-117.fc20 updates 316 k selinux-policy-targeted noarch 3.12.1-117.fc20 updates 3.6 M Transaction Summary == == Upgrade 2 Packages Total download size: 3.9 M Is this ok [y/d/N]: y Downloading packages: updates/20/x86_64/prestodelta | 1.3 MB 00:02 (1/2): selinux-policy-3.12.1-117.fc20.noarch.rpm | 316 kB 00:04 (2/2): selinux-policy-targeted-3.12.1-117.fc20.noarch.rpm | 3.6 MB 00:04 Total 868 kB/s | 3.9 MB 00:04 Running transaction check Running transaction test Transaction test succeeded Running transaction Warning: RPMDB altered outside of yum. Updating : selinux-policy-3.12.1-117.fc20.noarch 1/4 warning: %post(selinux-policy-3.12.1-117.fc20.noarch) scriptlet failed, exit status 127 Non-fatal POSTIN scriptlet failure in rpm package selinux-policy-3.12.1-117.fc20.noarch warning: %triggerin(selinux-policy-3.12.1-117.fc20.noarch) scriptlet failed, exit status 127 Non-fatal unknown scriptlet failure in rpm package selinux-policy-3.12.1-117.fc20.noarch error: %pre(selinux-policy-targeted-3.12.1-117.fc20.noarch) scriptlet failed, exit status 127 Error in PREIN scriptlet in rpm package selinux-policy-targeted-3.12.1-117.fc20.noarch Cleanup : selinux-policy-3.12.1-116.fc20.noarch 3/4 error: selinux-policy-targeted-3.12.1-117.fc20.noarch: install failed error: selinux-policy-targeted-3.12.1-116.fc20.noarch: erase skipped warning: %postun(selinux-policy-3.12.1-116.fc20.noarch) scriptlet failed, exit status 127 Non-fatal POSTUN scriptlet failure in rpm package selinux-policy-3.12.1-116.fc20.noarch Verifying : selinux-policy-3.12.1-117.fc20.noarch 1/4 selinux-policy-targeted-3.12.1-116.fc20.noarch was supposed to be removed but is not! Verifying : selinux-policy-targeted-3.12.1-116.fc20.noarch 2/4 Verifying : selinux-policy-3.12.1-116.fc20.noarch 3/4 Verifying : selinux-policy-targeted-3.12.1-117.fc20.noarch 4/4 Updated: selinux-policy.noarch 0:3.12.1-117.fc20 Failed: selinux-policy-targeted.noarch 0:3.12.1-116.fc20 selinux-policy-targeted.noarch 0:3.12.1-117.fc20 Complete! # rpm -qa selinux-policy\* selinux-policy-targeted-3.12.1-116.fc20.noarch selinux-policy-3.12.1-117.fc20.noarch # yum update selinux-policy Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit No packages marked for update # yum update selinux-policy\* Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package selinux-policy-targeted.noarch 0:3.12.1-116.fc20 will be updated --- Package selinux-policy-targeted.noarch 0:3.12.1-117.fc20 will be an update -- Finished Dependency Resolution Dependencies Resolved Package Arch Version Repository Size Updating: selinux-policy-targeted noarch 3.12.1-117.fc20 updates 3.6 M Transaction Summary Upgrade 1 Package Total size: 3.6 M Is this ok [y/d/N]: y Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction Updating : selinux-policy-targeted-3.12.1-117.fc20.noarch 1/2 Cleanup:
Re: SELinux RPM scriplet issue annoucement
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 partial update. Package selinux-policy updated to -117.fc20 but -targeted remaining at -116.fc20. I don't see this. I just updated today before reading this message (and I haven;t read the whole thread, sorry) and I got selinux-policy and targeted updated without any problem (I always run in enforcing mode). Simo. Fixing that with the instructions in the Wiki wouldn't work, # yum update selinux-policy Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit No packages marked for update since selinux-policy package is up-to-date. The enhanced fix that adds '\*' works also for this extra problem: setenforce 0 yum clean expire-cache yum update selinux-policy\* setenforce 1 [...] [snip] -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
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.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
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 methe...@gmail.com 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 list and posted in the Fedora website prominently as well? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
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 partial update. Package selinux-policy updated to -117.fc20 but -targeted remaining at -116.fc20. I don't see this. I just updated today before reading this message (and I haven;t read the whole thread, sorry) and I got selinux-policy and targeted updated without any problem (I always run in enforcing mode). Did you update from -116.fc20 or an earlier one? Only if you come from -116.fc20, you would be affected, since -116.fc20 is the bad update. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
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 mandatory for testers of the selinux-policy-targeted packagers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
SELinux RPM scriplet issue annoucement
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 list and posted in the Fedora website prominently as well? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Sat, 18 Jan 2014 15:47:38 -0500 Rahul Sundaram methe...@gmail.com 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 list and posted in the Fedora website prominently as well? I would think a detailed common bugs entry and then a short announcement pointing to that would be good. Would someone be able to write up the common bug entry? Adam? :) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
Hi On Sat, Jan 18, 2014 at 5:06 PM, Kevin Fenzi wrote: I would think a detailed common bugs entry and then a short announcement pointing to that would be good. Would someone be able to write up the common bug entry? https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriplets_fail_during_updates Please review it. Do you want me to send the announcement as well? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Sat, 18 Jan 2014 17:39:07 -0500 Rahul Sundaram methe...@gmail.com wrote: Hi On Sat, Jan 18, 2014 at 5:06 PM, Kevin Fenzi wrote: I would think a detailed common bugs entry and then a short announcement pointing to that would be good. Would someone be able to write up the common bug entry? https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriplets_fail_during_updates Thanks. I made a few tweaks... Please review it. Do you want me to send the announcement as well? If you like. I started writing one up, but then I wasn't sure what we should tell affected users about cleanup. Any package where the scriptlets failed will need to be reinstalled, and the duplicate older package removed. Not sure how best to describe that process... ;( kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/18/2014 6:23 PM, Kevin Fenzi wrote: On Sat, 18 Jan 2014 17:39:07 -0500 Rahul Sundaram methe...@gmail.com wrote: Hi On Sat, Jan 18, 2014 at 5:06 PM, Kevin Fenzi wrote: I would think a detailed common bugs entry and then a short announcement pointing to that would be good. Would someone be able to write up the common bug entry? https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriplets_fail_during_updates Thanks. I made a few tweaks... Please review it. Do you want me to send the announcement as well? If you like. I started writing one up, but then I wasn't sure what we should tell affected users about cleanup. Any package where the scriptlets failed will need to be reinstalled, and the duplicate older package removed. Not sure how best to describe that process... ;( kevin What I did. This worked for me. I set Selinux to permissive I rebooted (don't know if needed) Yum clean all Yum update package-cleanup --dupes (to look for dupes) package-cleanup --cleandupes to remove the dupes - -- David -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS2xDLAAoJEI7mbDIOYu+oZOsQAIc48n+U0Kh7c7tp6dgE4jhc 1cMddHYhXjcjB551ejNHEX+2nOkv2+P3qFWM+l2I4QiZdWPtR++RIASCssc7vgIa KJ2o+UU37Rd1n3V20MYnWFrCeawhiwYDGm+cHM6huBC0Uizu2lDB2gvA0Lbt5Qb7 lJioPhP1YEUzNYqAMWMLQCtDIWWiBaBDLAf6veeJww18Hx4kdHVi2h2hQRXtfpOY xaxxyT3KGBpU19wKFFOP9jOedqu80akxm0wmjgOEPk8hFHO7SFOKnvx5VUML1MXh PkY1FmWF6NAN2XqmVfxrfYD9WlHY9C7gGYrcFsqeCY8tYq35kNAV04J2cj4PFcV2 EFw+QWP+YHuA4a5jHqoPmzrOVQ7JLtkYLkZ0DhaOruxXJ2OIfzwUL2uIxJRg6+xU kyIdZChfvEabzzjgJDx9hZjyOvScOK4E9QppkfXulc726y3QEdzv/FpTtwAIp6i0 lBVt+GYNFEipV38s78EECogoerUefpWRthAwWF0x1ZyVFpUB8cOOAE8+EfI2zZEx b/uaE8rGIbjHjunUf240CPM7GqzNngJYbRLKbR5xKzPddaZItmAloirHWR0S2Kcx 5vjfMYyDOnY/awDjJzjnwAplCAPrl5jdpIJDjgqWxLQ7YhMnAWtWOAESL9dSmy9n Yqy19BR3celAlhLOsOL5 =WYYt -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On 1-18-14 18:39:55 David wrote: What I did. This worked for me. I set Selinux to permissive I rebooted (don't know if needed) Not necessary. Yum clean all Yum update package-cleanup --dupes (to look for dupes) package-cleanup --cleandupes to remove the dupes This worked for me but I also added yum reinstall the newer package after the cleandupes of the older package. Don't know if it was necessary. -- Garry T. Williams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
Rahul Sundaram metherid at gmail.com writes: https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriplets_fail_during_updates Please review it. Do you want me to send the announcement as well? 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
Hi 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 sent out the announcement. Hopefully it makes sense. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
