Re: Release criterion proposal: upgrade methods
On Tue, 2012-09-25 at 23:01 -0400, Richard Ryniker wrote: > Maybe someone with more fortitude (intellectual honesty? discipline?) > than I will kill upgrade, and make the world a better place. Or at least > document that "upgrade" is offered only on a "good effort" basis, with no > guarantee or support. That's more or less my take on it, and why I'd like to use the word 'recommended' rather than 'supported'. I agree that it's very difficult to convincingly suggest that upgrades are in any reasonable definition 'supported'. (As a sidebar, it's worth noting that major version upgrades are unsupported for RHEL, and Microsoft rarely offers true 'upgrades' between Windows builds any more, and I think never recommended them for enterprise use: vastly better funded and more conservative operating system projects than Fedora nevertheless have the same problems. It all rather indicates to me that 'supporting' major version upgrades of operating systems is rather close to being an impossibility.) To bring this back to practicalities: I'd say this discussion represents a rather strong consensus that we don't see much value in *strengthening* the release criteria and validation testing as concerns upgrades. We are left with the option of preserving the existing status quo, wherein we effectively guarantee that precisely two fairly artificial cases will work, or of simply dropping the release criterion relating to upgrading and demoting the test cases to 'optional' status. I can kind of see arguments both ways; on the one hand, the burden of testing upgrades to the strictly limited extent we currently do is not a terribly harsh one, and it at least gives us some confidence that the basic upgrade mechanism is not irretrievably broken. On the other hand, the practical benefits of the testing are fairly marginal: that 'we know it's not completely impossible' is pretty much all we get out of it. Any more thoughts down that road? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
"Upgrade" installation is a bizarre beast, because the result is not well
defined. Yes, a newer set of packages is installed, but a new install
does that. The reason "upgrade" is so seductive is the notion all one's
configuration and personalization is carried into the upgraded system,
whereas a new installation loses that.
If the only personalization is creation of one userid, that's pretty easy
and separate /home makes it even easier. On the other hand, a system
with multiple users, complex firewall, e-mail, DHCP server, print, udev,
or other configurations (e.g. the whole /etc/alternatives structure) is
problematic. The old files preserved by an "upgrade" installation may
not mean what they used to mean... new data or different formats may be
needed, there may even be a new component that replaced what used to be
configured, and this new component uses completely different data.
Think "rpmnew" on steroids.
The sheer number of possibilities and possible effects makes "supported"
a lie (in the sense a user would like it to mean). The change to systemd
is a fine example, where a user would like "supported" to mean his
initscripts, upstart, or whatever is magically converted to systemd
formats that do exactly what used to be done. Hah!
In practical terms, upgrade installation "support" means:
You'll get something that resembles what you used to have, but is
different. If you do not notice any differences (except newer versions
of packages), you are extremely lucky. If something brakes, you can
either try to repair the pieces, or perform a new installation. You are
welcome to report bugs, but if these cannot be reproduced in a new
installation, it is likely they will be ignored ("not reproducible" or
"won't fix", or simply languish until end-of-life).
I remark that "upgrade installation is only supported from the prior
release" simply means "upgrade from F14 to F15; update; upgrade from
F15 to F16; update; upgrade from F16 to F17; update; ..." is the
"supported" path. Well, that will increase the proportion of new
installations; at least it is good in that respect.
Personally, I am as susceptible to the lure of "upgrade" as most, even
though I "know better." I have gotten away with upgrade installations,
even through more than one release, but always something eventually
breaks, and a new installation is the proper solution. I try now to put
more effort into good configuration records, and tools to help me
replicate configurations into new installations... and less into analysis
of what went awry in the last upgrade.
Intellectually, I understand "upgrade" is a snake in the grass, waiting
to bite. Realistically, I expect soon to again think "Why not try an
upgrade, and see if it works?" and take the (initially) easier road.
Maybe someone with more fortitude (intellectual honesty? discipline?)
than I will kill upgrade, and make the world a better place. Or at least
document that "upgrade" is offered only on a "good effort" basis, with no
guarantee or support.
Meanwhile, it is like that old, threadbare and torn shirt, overdue for
the dustbin, but "oh! so familiar and comfortable," that still hangs in
my closet and is my first choice when something better is not required.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On Tue, 2012-09-25 at 19:41 -0400, Matthew Miller wrote: > On Tue, Sep 25, 2012 at 11:24:58PM +, "Jóhann B. Guðmundsson" wrote: > > >It'd be kind of awesome if we also *knew* each release if three or four > > >releases back is likely to work, even if the answer is "no". > > Personally I think we should limit our "support" not go further back > > then the release we are about to eol so we would support F16 being > > upgrade to F18 but not F15 being upgraded to F18. > > We want to encourage people to get off those old releases without abandoning > Fedora. It's reasonable to say we can't *support* all those upgrade > scenarios, but we should generally be predisposed to having them working. > > If we chase all the users away, the whole excercise becomes rather > pointless. But I'd get to play so much more golf... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: The future of how to debug pages
On Tue, 2012-09-25 at 23:21 +, "Jóhann B. Guðmundsson" wrote: > > I still don't think you've actually demonstrated any causal linkage > > between these two things. Debugging instructions are debugging > > instructions. Bug reports are bug reports. They are separate things. I > > don't see how sourcing one of those things upstream inevitably means we > > should send the other one of them upstream. There is no obvious causal > > linkage there. > > If we send reporters upstream to read documents we can just as well send > them by the same method to upstream bugzilla's to file reports. I think we're hitting a point of diminishing returns, but I just don't agree. As another poster said, a list of debugging steps is essentially a static document. It really doesn't matter a whole deal where it lives. A bug report is not a static document at all. It's a single element in a complex process. A Fedora bug report is fundamentally a part of the Fedora development process. An upstream bug report is fundamentally a part of the upstream development process. Whether a bug should be filed up or downstream is an important question, and one to which different people have different answers, but it's fundamentally informed by the fact that a bug report is a single element of a much larger process. Anyone who wants to debug systemd can read the list of debugging instructions at fedoraproject.org or freedesktop.org with equal ease. It's just a basically-static page of text that tells them what to do. In a strict sense it is indeed just as 'easy' to tell them to report a bug in systemd at freedesktop.org as it is to tell them to file the bug at redhat.com, but doing so has far more consequences than telling them to read the debugging instructions at freedesktop.org. It makes their bug report a part of the upstream systemd development process, not the Fedora one. In some cases this may be appropriate. In others it may not. But the 'comparison' with the debugging instructions doesn't seem at all useful to me. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On Tue, Sep 25, 2012 at 11:24:58PM +, "Jóhann B. Guðmundsson" wrote: > >It'd be kind of awesome if we also *knew* each release if three or four > >releases back is likely to work, even if the answer is "no". > Personally I think we should limit our "support" not go further back > then the release we are about to eol so we would support F16 being > upgrade to F18 but not F15 being upgraded to F18. We want to encourage people to get off those old releases without abandoning Fedora. It's reasonable to say we can't *support* all those upgrade scenarios, but we should generally be predisposed to having them working. If we chase all the users away, the whole excercise becomes rather pointless. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On 09/25/2012 11:02 PM, Matthew Miller wrote: On Tue, Sep 25, 2012 at 12:59:40PM -0700, Adam Williamson wrote: Yeah. I have one system where I run rawhide, and I leap releases for everything else -- but, usually I accept that I'm going to reinstall. I don't think Fedora (or Red Hat) have *ever* promised that an upgrade from anything but the previous release will work. Richard pointed out that we actually do suggest (not promise, but...) this in the install guide. The example cited suggests it's fine to upgrade across like three releases. We probably ought to change that. It'd be kind of awesome if we also *knew* each release if three or four releases back is likely to work, even if the answer is "no". Personally I think we should limit our "support" not go further back then the release we are about to eol so we would support F16 being upgrade to F18 but not F15 being upgraded to F18. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: The future of how to debug pages
On 09/25/2012 10:59 PM, Adam Williamson wrote: On Tue, 2012-09-25 at 22:37 +, "Jóhann B. Guðmundsson" wrote: On 09/25/2012 07:54 PM, Adam Williamson wrote: I don't see that that follows logically at *all*. The two just seem like totally different things. Instructions for debugging a given component are going to be the same whether you're running Fedora, Ubuntu, SUSE or whatever: debugging systemd is debugging systemd. There may be cases where there are local variations, in which case it makes sense to have a local wiki page, but in cases where there aren't, it seems perfectly sensible if the instructions are provided upstream. I don't see any way in which that means bugs reports should always be upstream. Upstream is also upstream for all those distribution and your point being? Mine point is pretty obvious if we are going to be redirect reporters upstream in the first place why not then just go the whole way. I may be being dim, but it just isn't obvious to me at all. The internet is a set of linked documents. If there is a document somewhere on the internet which already specifies the correct steps to take to debug something, it seems to make sense just to point to that instead of rewriting the whole thing just because we want to have an orderly set of documents in our wiki. In fact a lot of maintainers withing the distribution would like us to do just that and while we dont have our own bugzilla instance where reporters wont be hitting "Your not authorized to view this bug" or other RHEL related bugzilla policies that nobody knows who are ( or those that do cant disclose it ). To me we should either try to keep everything locally within the QA community and withing the distribution by building our own knowledge base or we should simply do it the other way around. I still don't think you've actually demonstrated any causal linkage between these two things. Debugging instructions are debugging instructions. Bug reports are bug reports. They are separate things. I don't see how sourcing one of those things upstream inevitably means we should send the other one of them upstream. There is no obvious causal linkage there. If we send reporters upstream to read documents we can just as well send them by the same method to upstream bugzilla's to file reports. That's the linkage JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] Announcing 389 Directory Server version 1.2.11.15 Testing
The 389 Project team is pleased to announce the release of 389-ds-base-1.2.11.15 for Testing. This release fixes another issue with CLEANALLRUV, some schema and userpassword related fixes, and other fixes. The new packages and versions are: 389-ds-base 1.2.11.15 NOTE: 1.2.11 will not be available for Fedora 16 or earlier, nor for EL6 or earlier - 1.2.11 will only be available for Fedora 17 and later. We are trying to stabilize current, stable releases - upgrades to 1.2.11 will disrupt stability. Installation yum install 389-ds --enablerepo=updates-testing # or for EPEL yum install 389-ds --enablerepo=epel-testing setup-ds-admin.pl Upgrade yum upgrade 389-ds-base --enablerepo=updates-testing # or for EPEL yum upgrade 389-ds-base --enablerepo=epel-testing setup-ds-admin.pl -u How to Give Feedback The best way to provide feedback is via the Fedora Update system. Go to https://admin.fedoraproject.org/updates In the Search box in the upper right hand corner, type in the name of the package In the list, find the version and release you are using (if you're not sure, use rpm -qi on your system) and click on the release On the page for the update, scroll down to "Add a comment" and provide your input Or just send us an email to 389-us...@lists.fedoraproject.org Reporting Bugs If you find a bug, or would like to see a new feature, use the 389 Trac - https://fedorahosted.org/389 More Information * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On Tue, Sep 25, 2012 at 12:59:40PM -0700, Adam Williamson wrote: > > Yeah. I have one system where I run rawhide, and I leap releases for > > everything else -- but, usually I accept that I'm going to reinstall. I > > don't think Fedora (or Red Hat) have *ever* promised that an upgrade from > > anything but the previous release will work. > Richard pointed out that we actually do suggest (not promise, but...) > this in the install guide. The example cited suggests it's fine to > upgrade across like three releases. We probably ought to change that. It'd be kind of awesome if we also *knew* each release if three or four releases back is likely to work, even if the answer is "no". -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: The future of how to debug pages
On Tue, 2012-09-25 at 22:37 +, "Jóhann B. Guðmundsson" wrote: > On 09/25/2012 07:54 PM, Adam Williamson wrote: > > > I don't see that that follows logically at *all*. The two just seem like > > totally different things. Instructions for debugging a given component > > are going to be the same whether you're running Fedora, Ubuntu, SUSE or > > whatever: debugging systemd is debugging systemd. There may be cases > > where there are local variations, in which case it makes sense to have a > > local wiki page, but in cases where there aren't, it seems perfectly > > sensible if the instructions are provided upstream. I don't see any way > > in which that means bugs reports should always be upstream. > > Upstream is also upstream for all those distribution and your point > being? > > Mine point is pretty obvious if we are going to be redirect reporters > upstream in the first place why not then just go the whole way. I may be being dim, but it just isn't obvious to me at all. The internet is a set of linked documents. If there is a document somewhere on the internet which already specifies the correct steps to take to debug something, it seems to make sense just to point to that instead of rewriting the whole thing just because we want to have an orderly set of documents in our wiki. > In fact a lot of maintainers withing the distribution would like us to > do just that and while we dont have our own bugzilla instance where > reporters wont be hitting "Your not authorized to view this bug" or > other RHEL related bugzilla policies that nobody knows who are ( or > those that do cant disclose it ). > > To me we should either try to keep everything locally within the QA > community and withing the distribution by building our own knowledge > base or we should simply do it the other way around. I still don't think you've actually demonstrated any causal linkage between these two things. Debugging instructions are debugging instructions. Bug reports are bug reports. They are separate things. I don't see how sourcing one of those things upstream inevitably means we should send the other one of them upstream. There is no obvious causal linkage there. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: The future of how to debug pages
On 09/25/2012 07:54 PM, Adam Williamson wrote: I don't see that that follows logically at*all*. The two just seem like totally different things. Instructions for debugging a given component are going to be the same whether you're running Fedora, Ubuntu, SUSE or whatever: debugging systemd is debugging systemd. There may be cases where there are local variations, in which case it makes sense to have a local wiki page, but in cases where there aren't, it seems perfectly sensible if the instructions are provided upstream. I don't see any way in which that means bugs reports should always be upstream. Upstream is also upstream for all those distribution and your point being? Mine point is pretty obvious if we are going to be redirect reporters upstream in the first place why not then just go the whole way. In fact a lot of maintainers withing the distribution would like us to do just that and while we dont have our own bugzilla instance where reporters wont be hitting "Your not authorized to view this bug" or other RHEL related bugzilla policies that nobody knows who are ( or those that do cant disclose it ). To me we should either try to keep everything locally within the QA community and withing the distribution by building our own knowledge base or we should simply do it the other way around. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
2012-09-24 - Fedora QA Meeting - recap
As always, minutes and IRC transcript available on the wiki at https://fedoraproject.org/wiki/QA/Meetings/20120924 Next meeting is scheduled for 2012-10-01 at 1500 UTC in #fedora-meeting. If you have topics you think we should bring up at the meeting, please add them to the Wiki page at https://fedoraproject.org/wiki/QA/Meetings/20121001 . Thanks! TOPIC: Previous meeting follow-up === * "adamw to find out who's writing the release announcement and make sure it calls out the biggest Alpha bugs" - this was done successfully * "tflink to draft up a freeze entrance requirements proposal for the list and we can take the idea from there" - tflink still working on quantifying freeze readiness * "pschindl to kill 'uncategorized package groups' criterion" - this got done and reported on the list * "kparal to refine 'release-blocking package sets' criterion" - this is still going on but it looks like we're pretty close * "adamw to refine alpha partitioning criterion" - adam didn't get around to this yet, sorry TOPIC: Release criteria revision === * adamw will propose Beta partitioning criteria after discussion with anaconda team * tflink and adamw propose to replace the specific upgrade methods listed in the Beta upgrade criterion with the phrase "officially supported upgrade method(s)" * We agreed 'all kickstart delivery methods' criterion is possibly overstated, adamw will consider potential changes * tflink will ask other potentially interested parties to see if they think any of the Beta criteria need to be changed TOPIC: Naming of TCs/RCs === * We still don't have a proposed scheme that everyone loves, but we agree the goal is to come up with a TC/RC naming scheme as unlikely as possible to confuse people about what each build is TOPIC: Open Floor === * tflink will be announcing a new release of the blocker bug tracking app (also known as Skynet) shortly ACTION ITEMS === * adamw to refine alpha partitioning criterion * adamw to draft new partitioning criterion for Beta once we know what will be in anaconda * adamw to consider revisions to 'kickstart delivery method' criterion * tflink to ask other interested parties (anaconda team, fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [criteria update] Package set
On Tue, 2012-09-25 at 12:46 -0400, Kamil Paral wrote: > > Thanks. Current version: > > > > 'The installer must be able to install each of the release blocking > > desktops, as well as the minimal package set, with each supported > > installation method' > > The discussion died off, this is the latest proposal. If there are no more > proposed changes in wording or grammar, I'll make it official tomorrow. +1 for me. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On Tue, 2012-09-25 at 08:15 -0400, Matthew Miller wrote: > On Mon, Sep 24, 2012 at 04:06:23PM -0700, Adam Williamson wrote: > > You could certainly make the case, yeah. Given that our excuse for > > people who say 'you have to upgrade every six months' is to say 'no you > > don't, because we support releases for 12, you can just upgrade every > > second release!', so we kinda do tell people that. > > Yeah. I have one system where I run rawhide, and I leap releases for > everything else -- but, usually I accept that I'm going to reinstall. I > don't think Fedora (or Red Hat) have *ever* promised that an upgrade from > anything but the previous release will work. Richard pointed out that we actually do suggest (not promise, but...) this in the install guide. The example cited suggests it's fine to upgrade across like three releases. We probably ought to change that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: The future of how to debug pages
On Mon, 2012-09-24 at 20:31 +, "Jóhann B. Guðmundsson" wrote: > On 09/24/2012 08:25 PM, Kevin Fenzi wrote: > > On Mon, 24 Sep 2012 19:29:39 + > > "Jóhann B. Guðmundsson" wrote: > > > >> A while back I started the initiative and writing how to debug pages > >> for QA Community to use and was about to write another when I noticed > >> when there has been put a big fat banner referring to upstream wiki > >> page on it. > >> > >> So my question here should we continue with this initiative which was > >> aimed at better documentation in the project and to improve general > >> reporting or should we simply drop the effort? > >> > >> JBG > >> > >> 1. https://fedoraproject.org/wiki/How_to_debug_Systemd_problems > > I think if upstream projects want to provide information on this, that > > should be preferred. In cases where they don't for whatever reason, I > > think a page on our wiki is fine. > > > > The problem will end up being knowing where to go... perhaps we could > > make a single page on the wiki about debugging and point to the various > > upstream or local debugging pages? > > > The general idea was to increase activity within the QA community and > improve reporting at the same time without having them running around > the whole internet while doings so. > > If the community prefers to run to various upstreams for this info we > can just as well stop reporting to Red Hat's bugzilla and report > directly upstream instead. ( something I have been very much against in > the past for the very same reasons ) I don't see that that follows logically at *all*. The two just seem like totally different things. Instructions for debugging a given component are going to be the same whether you're running Fedora, Ubuntu, SUSE or whatever: debugging systemd is debugging systemd. There may be cases where there are local variations, in which case it makes sense to have a local wiki page, but in cases where there aren't, it seems perfectly sensible if the instructions are provided upstream. I don't see any way in which that means bugs reports should always be upstream. I honestly don't see any problem with a Fedora 'how to debug' page simply referring to the upstream instructions if such instructions exist. It doesn't seem like it's actually a practical problem to have to load a page that is not hosted on a Fedora server. It's what hyperlinks were invented for. I'm really not seeing the problem here. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] 2012-09-26 @ 16:00 UTC - F18 Beta Blocker Bug Review #1
# F18 Beta Blocker Review meeting #1 # Date: 2012-09-05 # Time: 16:00 UTC [1] (12:00 EDT, 09:00 PDT) # Location: #fedora-bugzappers on irc.freenode.net This is a little earlier than on the schedule, but we already have 30 proposed blockers to run through and waiting longer won't make them go away. We'll be running through the beta blockers and nice-to-haves. The current list of blocker bugs is available at: http://qa.fedoraproject.org/blockerbugs/current We'll be reviewing the bugs to determine ... 1. Whether they meet the Beta release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria For guidance on Blocker and Nice-to-have (NTH) bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_nth_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [criteria update] Package set
> Thanks. Current version: > > 'The installer must be able to install each of the release blocking > desktops, as well as the minimal package set, with each supported > installation method' The discussion died off, this is the latest proposal. If there are no more proposed changes in wording or grammar, I'll make it official tomorrow. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fedora 18 updates-testing report
The following Fedora 18 Security updates need testing: Age URL 6 https://admin.fedoraproject.org/updates/FEDORA-2012-14279/phpldapadmin-1.2.2-3.gitbbedf1.fc18 13 https://admin.fedoraproject.org/updates/FEDORA-2012-13785/mediawiki119-1.19.2-1.fc18 12 https://admin.fedoraproject.org/updates/FEDORA-2012-13871/libxslt-1.1.27-1.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2012-14664/openjpeg-1.5.0-5.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2012-14762/automake17-1.7.9-17.fc18 The following builds have been pushed to Fedora 18 updates-testing automake17-1.7.9-17.fc18 bdii-5.2.13-1.fc18 ceelog-0.1-1.fc18 ftp-0.17-60.fc18 libmatecomponentui-1.4.0-2.fc18 libsrtp-1.4.4-6.20101004cvs.fc18 libvirt-0.10.2-3.fc18 linux-firmware-20120925-0.1.git236367d.fc18 man-pages-ja-20120915-1.fc18 mate-window-manager-1.4.1-8.fc18 mcollective-2.2.0-1.fc18 mrpt-0.9.6-1.fc18 paps-0.6.8-22.fc18 pcl-1.6.0-2.fc18 php-pecl-memcache-3.0.7-3.fc18 python-django-horizon-2012.2-0.9.rc2.fc18 pytrainer-1.9.1-3.fc18 rng-tools-4-2.fc18 rusers-0.17-70.fc18 sssd-1.9.0-24.fc18 sudo-1.8.6p3-1.fc18 ypbind-1.36-6.fc18 ypserv-2.29-2.fc18 yum-langpacks-0.3.0-3.fc18 Details about builds: automake17-1.7.9-17.fc18 (FEDORA-2012-14762) A GNU tool for automatically creating Makefiles Update Information: CVE-2012-3386 fix ChangeLog: * Tue Sep 25 2012 Pavel Raiskup - 1.7.9-17 - fix for CVE-2012-3386 (#838661) References: [ 1 ] Bug #838661 - CVE-2012-3386 automake: locally exploitable "make distcheck" bug [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=838661 bdii-5.2.13-1.fc18 (FEDORA-2012-14764) The Berkeley Database Information Index (BDII) Update Information: ChangeLog: * Wed Aug 15 2012 Laurence Field - 5.2.13-1 - Included Fedora patches upstream. ceelog-0.1-1.fc18 (FEDORA-2012-14761) Tool for receiving, filtering and searching CEE/Lumberjack logs Update Information: Initial build/import of package for f18 References: [ 1 ] Bug #858613 - Review Request: ceelog - Tool for receiving, filtering and searching CEE/Lumberjack logs https://bugzilla.redhat.com/show_bug.cgi?id=858613 ftp-0.17-60.fc18 (FEDORA-2012-14752) The standard UNIX FTP (File Transfer Protocol) client Update Information: Plug some leaks; add listening timeout ChangeLog: * Tue Sep 25 2012 Jan Synáček - 0.17-60 - Plug leaks in "put", "send", "append" - Add listening timeout libmatecomponentui-1.4.0-2.fc18 (FEDORA-2012-14753) Libraries for MATE Desktop ui Update Information: clean up spec file libmatecomponentui for MATE Desktop ChangeLog: References: [ 1 ] Bug #851975 - Review Request: libmatecomponentui - Libraries for MATE Desktop ui components https://bugzilla.redhat.com/show_bug.cgi?id=851975 libsrtp-1.4.4-6.20101004cvs.fc18 (FEDORA-2012-14765) An implementation of the Secure Real-time Transport Protocol (SRTP) Update In
Re: Selinux in development releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/25/2012 11:11 AM, john.flor...@dart.biz wrote: >> From: "Jason L Tibbitts III" I'm something of an >> idiot when it comes to selinux; I used to know just enough to get a >> reasonable bug report out, but now I've even forgotten most of that. I >> do know, however, that turning off dontaudit rules can save your sanity, >> because _way_ too much stuff fails silently. Which is a horrible bug in >> itself but it seems to be by design. > > I concur. I suppose there's a good reason to not log some of these, but > I've nearly lost my sanity more than once with these squelched messages. > Life improved only once I realized my testing was missing 'setenforce 0' to > see if that had any effect. > > -- John Florian > > When this has happened please open a bug because we could be too liberal with our dontaudit rules. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBhysYACgkQrlYvE4MpobMoaQCfSDmP65PG1CYBMiyj+iScBlUh ftAAni6ssZZG54NMxsPdERbIwsI0O1eL =/Ufe -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
> From: john.flor...@dart.biz > I was going to suggest that this should be noted at http:// > fedoraproject.org/wiki/SELinux/Troubleshooting, but I see it already > is. Perhaps I should start reading all of my mail before responding to any of it. Anyway, I'm very happy to see the addition on that page. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
> From: "Jason L Tibbitts III" > I'm something of an idiot when it comes to selinux; I used to know just > enough to get a reasonable bug report out, but now I've even forgotten > most of that. I do know, however, that turning off dontaudit rules can > save your sanity, because _way_ too much stuff fails silently. Which is > a horrible bug in itself but it seems to be by design. I concur. I suppose there's a good reason to not log some of these, but I've nearly lost my sanity more than once with these squelched messages. Life improved only once I realized my testing was missing 'setenforce 0' to see if that had any effect. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
> From: "Jason L Tibbitts III" > > "JF" == John Florian writes: > > JF> I do wish there was some master switch to temporarily enable logging > JF> for them. > > You mean, besides the existing "disable dontaudit rules" switch? Just > run "semoduile -DB". It's pretty much mandatory to do that first when > debugging selinux problems. > No, that would be the one I'd want and was completely unaware of. ;-) I was going to suggest that this should be noted at http://fedoraproject.org/wiki/SELinux/Troubleshooting, but I see it already is. This just proves what I was saying about Dan's superhuman response times. He can somehow introduce just requested features prior to the present time! =) Regardless of how dumb I feel right now, thanks so much for pointing that out. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: test Digest, Vol 103, PoeIssue 1
On 25/09/12 02:07, fai...@gmail.com wrote: Sent from my BlackBerry® smartphone from Warid. your phone not that smart it seems :D -- Regards, Frank "Jack of all, fubars" -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Join Fedora X Test Week - Nouveau, Radeon, Intel (2012-09-25 - 2012-09-27)
On 9/24/12 8:15 PM, John Reiser wrote: If it is known that any Radeon card less than Radeon 9600 won't work satisfactorily in the default Gnome3 desktop, then Fedora should admit it up front, and raise the minimum stated requirements. I'm sure the docs team takes patches. But also: that's not a thing we would know without running the very test day you're claiming is of no value. a) You're calling out a test you ran once nearly two years ago. Pretty sure we've fixed at least one RV200 bug since then. Please give a specific reference. Here are all the CLOSED bugs with RV200. I don't see a single one that is RV200-specific that was fixed after October 2010. Only 680651 and 493328 were fixed; the rest are "WONT FIX". 680651 is not specific to RV200, and 493328 was more than two years ago. Why do you expect every issue with a GPU is reported in Fedora's bugzilla? Or in a bugzilla at all? Or that every affected GPU is mentioned, if the bug affects class of GPUs? Bugzilla is a collection of stories. There's no reason to believe it's exhaustive. c) I'm fairly sure zero of the tests you've shown to fail there _do_ matter. They all happen when you do a Render operation directly to a window, and nobody does that. Drawing straight to a window is unbelievably flickery, that's why everybody buffers things up to an offscreen pixmap and then blits across to the window (using core CopyArea, not Render). When I run the anaconda installer for Fedora 18 Alpha, then I see bad _graphics_. It's not clear where the problems lie, and this is Alpha. Nevertheless, I expected better _graphics_. I think you meant this in response to this next point: Why do you feel this is relevant? X bugs are X bugs. In which case: that's a fine expectation, and your rant about Gnome fallback mode has _nothing to do with it_. Also forget about any card+monitor which does not report EDID/DCC. "Forget about broken hardware"? Yeah, please do. That hardware meets Fedora's minimum stated requirements [The requirements mention nothing about graphics hardware.] Furthermore, the hardware is merely old, not necessarily "broken". Just because the hardware pre-dates the feature does not automatically make it "broken". If EDID+DDC is a requirement, then say so. EDID isn't a requirement. Some method for detection of the display is a prerequisite for plug and play working. We would prefer that be EDID; if your platform uses something else then we can attempt to accomodate that. But if there's no PNP support we'll try to stumble along, so no, EDID is not strictly required. Nonetheless, hardware that can't plug and play in 2012 is broken. For DDC support in particular there is no excuse, that spec (and the first OS it was a logo requirement for) is old enough to get a driver's license by now. Making a point of documenting it is sort of like insisting that the computer should be powered by electricity. - ajax -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: test Digest, Vol 103, PoeIssue 1
Sent from my BlackBerry® smartphone from Warid. -Original Message- From: test-requ...@lists.fedoraproject.org Sender: test-boun...@lists.fedoraproject.org Date: Tue, 25 Sep 2012 13:59:02 To: Reply-To: test@lists.fedoraproject.org Subject: test Digest, Vol 103, Issue 103 Send test mailing list submissions to test@lists.fedoraproject.org To subscribe or unsubscribe via the World Wide Web, visit https://admin.fedoraproject.org/mailman/listinfo/test or, via email, send a message with subject or body 'help' to test-requ...@lists.fedoraproject.org You can reach the person managing the list at test-ow...@lists.fedoraproject.org When replying, please edit your Subject line so it is more specific than "Re: Contents of test digest..." -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/25/2012 08:42 AM, Matthew Miller wrote: > On Tue, Sep 25, 2012 at 07:21:32AM -0500, Jason L Tibbitts III wrote: >> You mean, besides the existing "disable dontaudit rules" switch? Just >> run "semoduile -DB". It's pretty much mandatory to do that first when >> debugging selinux problems. > > Could this be added to > http://fedoraproject.org/wiki/SELinux/Troubleshooting? > > Seems like a lot of blog entries could be added to this page. Setting up Permissive Domains. Setting up unconfined domains. Disabling DontAudit rules. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBhuKEACgkQrlYvE4MpobOlcACfXoT8uhFE+BYA5ziORpPHIi1W TawAoMyyac8r/9S7vBnouCl0SjUVeYVU =LdQ0 -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/25/2012 08:42 AM, Matthew Miller wrote: > On Tue, Sep 25, 2012 at 07:21:32AM -0500, Jason L Tibbitts III wrote: >> You mean, besides the existing "disable dontaudit rules" switch? Just >> run "semoduile -DB". It's pretty much mandatory to do that first when >> debugging selinux problems. > > Could this be added to > http://fedoraproject.org/wiki/SELinux/Troubleshooting? > > Most of that info is ancient, but I did update it somewhat. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBhuAkACgkQrlYvE4MpobMzEQCfXcVDMa7vfoA0Zun31Th7LOOu b58An0el2e8+Lp1TV/nkyfFBxFKycsJE =nO7Z -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
> "MM" == Matthew Miller writes: MM> Of course. However, it might be better if someone who has better MM> understanding of exactly what that does and how to use it (e.g., MM> Jason) would do it, including adding a little bit of surrounding MM> text. I'm just aping one of Dan's old blog entries: http://danwalsh.livejournal.com/11673.html I'm something of an idiot when it comes to selinux; I used to know just enough to get a reasonable bug report out, but now I've even forgotten most of that. I do know, however, that turning off dontaudit rules can save your sanity, because _way_ too much stuff fails silently. Which is a horrible bug in itself but it seems to be by design. - J< -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
On Tue, Sep 25, 2012 at 12:55:19PM +, "Jóhann B. Guðmundsson" wrote: > >On Tue, Sep 25, 2012 at 07:21:32AM -0500, Jason L Tibbitts III wrote: > >>>You mean, besides the existing "disable dontaudit rules" switch? Just > >>>run "semoduile -DB". It's pretty much mandatory to do that first when > >>>debugging selinux problems. > >Could this be added to > >http://fedoraproject.org/wiki/SELinux/Troubleshooting? > It's an wiki just log in and add it. Of course. However, it might be better if someone who has better understanding of exactly what that does and how to use it (e.g., Jason) would do it, including adding a little bit of surrounding text. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
rawhide report: 20120925 changes
Compose started at Tue Sep 25 08:15:11 UTC 2012 Broken deps for x86_64 -- [almanah] almanah-0.8.0-7.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libecal-1.2.so.12()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libebook-1.2.so.13()(64bit) [clutter-gtk010] clutter-gtk010-0.11.4-6.fc17.i686 requires libcogl.so.9 clutter-gtk010-0.11.4-6.fc17.x86_64 requires libcogl.so.9()(64bit) [dogtag-pki] dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-util-javadoc >= 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-tools >= 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-tks >= 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-symkey >= 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-silent >= 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-setup >= 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-server >= 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-selinux >= 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-ocsp >= 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-kra >= 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-java-tools-javadoc >= 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-console >= 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-common-javadoc >= 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-ca >= 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-base >= 0:10.0.0 [ease] ease-0.4-18.fc17.i686 requires libcogl.so.9 ease-0.4-18.fc17.x86_64 requires libcogl.so.9()(64bit) [emacs-spice-mode] emacs-spice-mode-1.2.25-9.fc18.noarch requires gwave [evolution-exchange] evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-cal-1.2.so.17()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-book-1.2.so.14()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libecal-1.2.so.12()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebook-1.2.so.13()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebackend-1.2.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libcamel-1.2.so.36()(64bit) [fedora-ksplice] fedora-ksplice-0.5-10.fc18.x86_64 requires ksplice [flush] flush-0.9.10-7.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_signals-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) [freeipa] freeipa-server-3.0.0-0.8.fc19.x86_64 requires selinux-policy >= 0:3.11.1-21 freeipa-server-3.0.0-0.8.fc19.x86_64 requires pki-symkey >= 0:10.0.0-0.33.a1 freeipa-server-3.0.0-0.8.fc19.x86_64 requires pki-silent >= 0:10.0.0-0.33.a1 freeipa-server-3.0.0-0.8.fc19.x86_64 requires pki-setup >= 0:10.0.0-0.33.a1 freeipa-server-3.0.0-0.8.fc19.x86_64 requires pki-ca >= 0:10.0.0-0.33.a1 [gcc-python-plugin] gcc-python2-debug-plugin-0.9-4.fc19.x86_64 requires gcc = 0:4.7.1-7.fc19 gcc-python2-plugin-0.9-4.fc19.x86_64 requires gcc = 0:4.7.1-7.fc19 gcc-python3-debug-plugin-0.9-4.fc19.x86_64 requires gcc = 0:4.7.1-7.fc19 gcc-python3-plugin-0.9-4.fc19.x86_64 requires gcc = 0:4.7.1-7.fc19 [gcstar] gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::Table) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::HBox) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::Frame) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::EventBox) [gdb-heap] gdb-heap-0.5-9.fc18.x86_64 requires glibc(x86-64) = 0:2.15 [glom] glom-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) glom-libs-1.18.6-1.fc17.i686 requires libboost_python.so.1.48.0 glom-libs-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) [gnome-applets] 1:gnome-applets-3.5.1-1.fc18.x86_64 requires libgweather-3.so.0()(64bit) [gnome-pilot] gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserverui-3.0.so.1()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserver-1.2.so.16()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libecal-1.2.so.11()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libebook-1.2.so.13()(64bit) [gnome-shell-theme-selene] gnome-shell-theme-selene-3.4.0-
Re: Selinux in development releases
On 09/25/2012 12:42 PM, Matthew Miller wrote: On Tue, Sep 25, 2012 at 07:21:32AM -0500, Jason L Tibbitts III wrote: >You mean, besides the existing "disable dontaudit rules" switch? Just >run "semoduile -DB". It's pretty much mandatory to do that first when >debugging selinux problems. Could this be added to http://fedoraproject.org/wiki/SELinux/Troubleshooting? It's an wiki just log in and add it. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
On Tue, Sep 25, 2012 at 07:21:32AM -0500, Jason L Tibbitts III wrote: > You mean, besides the existing "disable dontaudit rules" switch? Just > run "semoduile -DB". It's pretty much mandatory to do that first when > debugging selinux problems. Could this be added to http://fedoraproject.org/wiki/SELinux/Troubleshooting? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
> "JF" == John Florian writes: JF> I do wish there was some master switch to temporarily enable logging JF> for them. You mean, besides the existing "disable dontaudit rules" switch? Just run "semoduile -DB". It's pretty much mandatory to do that first when debugging selinux problems. - J< -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
> From: "Jóhann B. Guðmundsson" > To: test@lists.fedoraproject.org > Date: 09/24/2012 16:25 > Subject: Re: Selinux in development releases > Sent by: test-boun...@lists.fedoraproject.org > > On 09/24/2012 08:16 PM, drago01 wrote: > > On Mon, Sep 24, 2012 at 10:13 PM, "Jóhann B. Guðmundsson" > > wrote: > >> I hereby propose that we default selinux to permissive mode up to final > >> which should just get rid of unneeded nuance during testing. > > -1 > > > > This would just mean we test something different then we actually > > ship. If there are selinux bugs they are supposed to be cough during > > testing and reported like any other bugs. > > With permissive mode we should still be able to catch all those errors > and report them without all the downside that comes with having it in > enforcing mode during our development releases... Not true from what I've witnessed. There are certain rules that indeed block some action, but do not get logged. I've encountered several over the years and was only able to detect these by toggling enforcing/permissive. I do wish there was some master switch to temporarily enable logging for them. I concur that Dan is superhuman in his response times. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On Mon, Sep 24, 2012 at 04:06:23PM -0700, Adam Williamson wrote: > You could certainly make the case, yeah. Given that our excuse for > people who say 'you have to upgrade every six months' is to say 'no you > don't, because we support releases for 12, you can just upgrade every > second release!', so we kinda do tell people that. Yeah. I have one system where I run rawhide, and I leap releases for everything else -- but, usually I accept that I'm going to reinstall. I don't think Fedora (or Red Hat) have *ever* promised that an upgrade from anything but the previous release will work. I'm very much in favor of changing that given what you say above, but I think maybe that in itself is a Feature. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
On 09/25/2012 02:10 AM, Daniel J Walsh wrote: Definitely not. Enforcing mode and Permissive mode are not equivalent. SELinux/Permission Denied can cause things to crash. I have been working since last week on SELinux/Systemd problems that happen in early boot, and would only be seen in enforcing mode. For some reason avc messages were not showup in early boot, so no one would have known about it. Interesting those errors not even caught by the journal? Dontaudit rules can cover up messages that cause applications bugs. I see We have been working with SELinux in enforcing mode for years now, why change now. We also have had several release without selinux running so we have two data points to measure with. The reason why I suggested this is to keep the entry level for reporters as low as possible so running selinux in permissive mode would have yielded the same result, we would have been able to still gather the necessary data without leaving the reporter with potentially unbootable system. I guess we could just create an wiki page that reporters could use on the side encase they need it. Ever since the introduction of systemd we have had more *severe* cases of selinux issues in the alpha phaze which seems to be mostly due to the systemd team not given the selinux team an heads up about some of the changes they have made or about to make. ( nothing that could not be solved with all the teams that make up CoreOS ( Kernel,Dracut,Systemd and arguably Selinux ) meeting and discussing what's going to happen next development cycle over a cold beer or good cognac ) Anyway given your input + -1 from drago01 ( whatever his or hers real name is ),Michael and Adams W. I think this proposal has been officially nack-ed ( Unless some others from the QA community have something more valuable to add to the discussion ) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
