Re: how do I tell what release yum upgrade will give me?

2013-07-30 Thread Frank Murphy 
distroverpkg=

*
Yum* obtains the value of $releasever from the distroverpkg= line in
the /etc/yum.conf"

,it goes to *release, if above line not present.


On 31 July 2013 03:48, T.C. Hollingsworth  wrote:

> On Mon, Jul 29, 2013 at 10:51 PM, Adam Williamson 
> wrote:
> > There isn't a particularly easy way, you just have to make sure
> > fedora-release-rawhide is installed and tweak the enabled repos, AFAIK.
> > I guess if you edited the .repo files directly they wouldn't get
> > overridden on updates? I haven't really played with it much, to be
> > honest, I just adjust as necessary for whatever I'm trying to do as I go
> > along.
>
> That won't work.  fedora-release just Obsoletes fedora-release-rawhide
> at the branch point [1] so fedora-rawhide.repo is removed completely.
>
> The only way to avoid it would be to prevent yum from honoring the
> obsoletes the first time you update after the branch, but that really
> isn't any easier than just reinstalling fedora-release-rawhide after
> the fact.
>
> -T.C.
>
> [1]
> http://pkgs.fedoraproject.org/cgit/fedora-release.git/commit/?h=f19&id=756e5e18042c4f820fb6059e640747a7a2b1e2a0
> --
> test mailing list
> test@lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test
>



-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of fedoraproject.org
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Resumed sessions are unstable if resuming after pm-hibernate with kernel-3.10.4-300.fc19.x86_64

2013-07-30 Thread Joachim Backes 

Hi all,

having some problem with hibernation in kernel-3.10.4-300.fc19.x86_64 
(from koji): After hibernating from a gnome3-session and then resuming, 
the resumed session is very unstable: repeatedly, the gnome3-session is 
killed/closed, so I have to relogin.


This only happens after hibernate/resume.

The only solution is to reboot completly.

Anybody sees this too?

Kind regards

Joachim Backes

--

Fedora release 19 (Schrödinger’s Cat)
Kernel-3.10.4-300.fc19.x86_64

Joachim Backes 
https://www-user.rhrk.uni-kl.de/~backes
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: how do I tell what release yum upgrade will give me?

2013-07-30 Thread T.C. Hollingsworth 
On Mon, Jul 29, 2013 at 10:51 PM, Adam Williamson  wrote:
> There isn't a particularly easy way, you just have to make sure
> fedora-release-rawhide is installed and tweak the enabled repos, AFAIK.
> I guess if you edited the .repo files directly they wouldn't get
> overridden on updates? I haven't really played with it much, to be
> honest, I just adjust as necessary for whatever I'm trying to do as I go
> along.

That won't work.  fedora-release just Obsoletes fedora-release-rawhide
at the branch point [1] so fedora-rawhide.repo is removed completely.

The only way to avoid it would be to prevent yum from honoring the
obsoletes the first time you update after the branch, but that really
isn't any easier than just reinstalling fedora-release-rawhide after
the fact.

-T.C.

[1] 
http://pkgs.fedoraproject.org/cgit/fedora-release.git/commit/?h=f19&id=756e5e18042c4f820fb6059e640747a7a2b1e2a0
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: how do I tell what release yum upgrade will give me?

2013-07-30 Thread Lars Seipel 
On Tue, Jul 30, 2013 at 02:16:35AM -0400, Felix Miata wrote:
> If by "tweaking" you mean manual manipulation of /etc/yum.repos.d/
> content, I'd need a howto. I don't do so well on my own messing with
> config files containing $ &/or ? in URLs.

Don't touch those. You don't need to mess with anything but the
"enabled=0|1" lines. Want Rawhide? Toggle "enabled" to 1 for the rawhide
repo in fedora-rawhide.repo. Set everything else to 0.

There's also yum-config-manager(1) …

Lars
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Draft bootloader selection test cases

2013-07-30 Thread Adam Williamson 
I drafted up a couple of test cases to verify this currently un-verified
criterion:

https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Bootloader_disk_selection

They are:

https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_anaconda_bootloader_target
https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_anaconda_no_bootloader

they're fairly straightforward, they simply test that the installer can
successfully deploy bootloader to a chosen disk, or not deploy one at
all, as the criterion requires. They would be added to the installation
verification matrix in the appropriate spots. Comments, suggestions,
questions etc? Thanks!
-- 
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: [Fedora QA] #397: Create test cases for release criteria that are currently missing them

2013-07-30 Thread Fedora QA 
#397: Create test cases for release criteria that are currently missing them
-+---
  Reporter:  adamwill|  Owner:
  Type:  task| Status:  new
  Priority:  major   |  Milestone:  Fedora 20
 Component:  Test cases  |Version:
Resolution:  |   Keywords:
Blocked By:  |   Blocking:
-+---

Comment (by adamwill):

 Draft test cases for bootloader disk selection:

  *
 
https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_anaconda_bootloader_target
  *
 
https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_anaconda_no_bootloader

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Draft terminal application test case

2013-07-30 Thread Adam Williamson 
Proposing a new draft release validation test case:

https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_desktop_terminal

this is a fairly simple test case that just checks that a terminal
application works in a desktop environment. It would be added to the
desktop matrix along with the browser test case, to cover the lack of a
test case to enforce the terminal part of the Alpha criterion "It must
be possible to run the default web browser and a terminal application
from all release-blocking desktop environments."

Comments, improvements, suggestions etc welcome as always! As this is
pretty straightforward I'm planning to put it into production pretty
soon if there's no negative feedback.
-- 
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: [Fedora QA] #397: Create test cases for release criteria that are currently missing them

2013-07-30 Thread Fedora QA 
#397: Create test cases for release criteria that are currently missing them
-+---
  Reporter:  adamwill|  Owner:
  Type:  task| Status:  new
  Priority:  major   |  Milestone:  Fedora 20
 Component:  Test cases  |Version:
Resolution:  |   Keywords:
Blocked By:  |   Blocking:
-+---

Comment (by adamwill):

 Draft of a terminal test case:
 https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_desktop_terminal

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #397: Create test cases for release criteria that are currently missing them

2013-07-30 Thread Fedora QA 
#397: Create test cases for release criteria that are currently missing them
-+---
  Reporter:  adamwill|  Owner:
  Type:  task| Status:  new
  Priority:  major   |  Milestone:  Fedora 20
 Component:  Test cases  |Version:
Resolution:  |   Keywords:
Blocked By:  |   Blocking:
-+---

Comment (by adamwill):

 I added the KDE package set test the other day -
 https://fedoraproject.org/wiki/QA:Testcase_Package_Sets_KDE_Package_Install
 .

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #398: Add Secure Boot test case

2013-07-30 Thread Fedora QA 
#398: Add Secure Boot test case
-+---
  Reporter:  adamwill|  Owner:
  Type:  task| Status:  new
  Priority:  major   |  Milestone:  Fedora 20
 Component:  Test cases  |Version:
Resolution:  |   Keywords:
Blocked By:  |   Blocking:
-+---

Comment (by adamwill):

 On second thought, a specific test case isn't really the way to go. This
 is more a case of running an existing set of test cases - the image boot
 and installed system boot test cases - in a specific environment - Secure
 Boot with a normal OEM configuration.

 We keep coming across more of these 'run test case X in configuration Y'
 cases, the 'simple table' style may be hitting its limitations in keeping
 track of them all. Have to think about this one...

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Template for marking test cases that are associated with release criteria

2013-07-30 Thread Adam Williamson 
On Thu, 2013-07-25 at 15:18 -0700, Adam Williamson wrote:
> I slapped together a quick template for adding a 'note' to a test case
> that it enforces one of the release criteria.
> https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_anaconda_user_creation
>  gives an example of how to use it:
> 
> {{Template:Associated_release_criterion|releasecriterion=Fedora_{{FedoraVersionNumber|next}}_Alpha_Release_Criteria#Expected_installed_system_boot_behavior}}

As discussed later in the thread, I've revised the template to make
invocation rather simpler. Now you just do this:

{{Template:Associated_release_criterion|Alpha|expected-installed-system-boot-behavior}}

or similar. i.e. just pass the milestone and a criterion name as the two
variables to the template. All the magic for turning them into a current
link is now in the template.

Note that in the criteria pages, each criterion has an explicit anchor
tag and also an auto-generated link from the table of contents, so both:

https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Expected_installed_system_boot_behavior
 (auto-generated)

and:

https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#expected-installed-system-boot-behavior
 (anchor)

are valid. You can use either format for the template - in the end it's
just spitting out a hyperlink with the # in it. But I'd recommend using
the anchor names, as my intent was that those should be the 'permanent'
names of each criterion - even if we change the visible paragraph titles
we should keep the anchor names the same so they're reliable.

I've gone back and adjusted all the existing test case pages to use the
new form of the template. Thanks folks!
-- 
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: [Fedora QA] #393: Revise release criteria for ARM as primary arch

2013-07-30 Thread Fedora QA 
#393: Revise release criteria for ARM as primary arch
---+---
  Reporter:  adamwill  |  Owner:  adamwill
  Type:  task  | Status:  new
  Priority:  major |  Milestone:  Fedora 20
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+---

Comment (by adamwill):

 ARM folks, I think Johann's questions from comment #2 are pretty germane
 here. Is there a definite plan for what the expected 'deliverables' for
 ARM for F20 are? Is it like F19: two images for the two slight arch
 variations, to be deployed by imaging followed by initial-setup? Or is
 there more? Is the network install method for ARM to be considered
 'supported' or not?

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Proposed test cases: initial-setup and anaconda user creation

2013-07-30 Thread Adam Williamson 
On Thu, 2013-07-25 at 14:26 -0700, Adam Williamson wrote:
> Hi, folks. So now we revised the release criteria for initial-setup and
> anaconda user creation instead of firstboot, we need to do the same for
> test cases.
> 
> I'm proposing a couple of new test cases to replace
> https://fedoraproject.org/wiki/QA:Testcase_base_firstboot :
> 
> https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_base_initial_setup
> https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_anaconda_user_creation
> 
> One is a generic test for 'initial setup' type utilities, the other
> covers user creation in the installer. I'm envisaging that we can put
> them in the Base validation matrix with GNOME, KDE and Minimal columns
> to cover the three release-blocking installation types. That should
> cover all the possible paths through install and 'first boot' on our
> three release-blocking package sets. Note that, as written, the first
> test case can actually apply to ARM: 'deploying' ARM via a non-installer
> image would comply with the 'setup' and 'how to test' steps as they are
> described, and the test case would imply that user creation must work
> during first boot of a non-installer deployed ARM system, which I
> believe is desired.
> 
> There would also need to be minor changes to
> https://fedoraproject.org/wiki/QA:Testcase_base_startup to go with this
> change, which should be pretty obvious.
> 
> Anyone have comments/criticisms/questions/suggestions on the test cases
> themselves or this plan? Thanks!

Any feedback on this before I put it into 'production'? Thanks folks!
-- 
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

Fedora 17 updates-testing report

2013-07-30 Thread updates 
The following Fedora 17 Security updates need testing:
 Age  URL
 389  
https://admin.fedoraproject.org/updates/FEDORA-2012-10269/revelation-0.4.14-1.fc17
 202  
https://admin.fedoraproject.org/updates/FEDORA-2013-0455/fedora-business-cards-1-0.1.beta1.fc17
 129  
https://admin.fedoraproject.org/updates/FEDORA-2013-4234/stunnel-4.55-1.fc17
 124  
https://admin.fedoraproject.org/updates/FEDORA-2013-4501/libxslt-1.1.28-1.fc17
 121  
https://admin.fedoraproject.org/updates/FEDORA-2013-4581/libuser-0.57.6-2.fc17
  54  
https://admin.fedoraproject.org/updates/FEDORA-2013-10121/subversion-1.7.10-1.fc17
  44  
https://admin.fedoraproject.org/updates/FEDORA-2013-10940/tomcat6-6.0.37-1.fc17
   7  
https://admin.fedoraproject.org/updates/FEDORA-2013-13381/ghc-xmonad-contrib-0.10-7.1.fc17,bluetile-0.6-12.fc17
   6  
https://admin.fedoraproject.org/updates/FEDORA-2013-13473/openttd-1.3.0-2.fc17,pyicu-1.2-3.fc17,fontmatrix-0.9.99-4.r1218.fc17,icu-4.8.1.1-7.fc17,libreoffice-3.5.7.2-14.fc17
   5  
https://admin.fedoraproject.org/updates/FEDORA-2013-13459/squid-3.2.13-1.fc17
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-13610/perl-Proc-ProcessTable-0.48-1.fc17
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-13647/gksu-polkit-0.0.3-8.gitf8ce834c.fc17
   3  
https://admin.fedoraproject.org/updates/FEDORA-2013-13715/libgcrypt-1.5.3-1.fc17
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-13839/bind-9.9.3-4.P2.fc17


The following Fedora 17 Critical Path updates have yet to be approved:
 Age URL
 149  
https://admin.fedoraproject.org/updates/FEDORA-2013-3304/libvpx-1.2.0-1.fc17
  13  
https://admin.fedoraproject.org/updates/FEDORA-2013-13129/livecd-tools-17.18-1.fc17
  13  
https://admin.fedoraproject.org/updates/FEDORA-2013-13082/selinux-policy-3.10.0-171.fc17
  12  
https://admin.fedoraproject.org/updates/FEDORA-2013-13149/qtwebkit-2.3.2-1.fc17
   3  
https://admin.fedoraproject.org/updates/FEDORA-2013-13715/libgcrypt-1.5.3-1.fc17


The following builds have been pushed to Fedora 17 updates-testing

bind-9.9.3-4.P2.fc17
mate-file-manager-sendto-1.6.0-2.fc17
mate-image-viewer-1.6.1-1.fc17
mozilla-https-everywhere-3.3.1-1.fc17

Details about builds:



 bind-9.9.3-4.P2.fc17 (FEDORA-2013-13839)
 The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server

Update Information:

- update to 9.9.3-P2 (fix for CVE-2013-4854)
- update RRL patch to 9.9.3-P2-rl.13207.22

ChangeLog:

* Sun Jul 28 2013 Tomas Hozza  32:9.9.3-4.P2
- update to 9.9.3-P2 (fix for CVE-2013-4854)
- update RRL patch to 9.9.3-P2-rl.13207.22

References:

  [ 1 ] Bug #988999 - CVE-2013-4854 bind: named crash with an assertion failure 
on parsing malformed rdata
https://bugzilla.redhat.com/show_bug.cgi?id=988999




 mate-file-manager-sendto-1.6.0-2.fc17 (FEDORA-2013-13869)
 MATE file manager send to

Update Information:

some spec file improvements

ChangeLog:

* Sun Jul 28 2013 Wolfgang Ulbrich  - 1.6.0-2
- own directories
- clean BRs
- remove gsettings convert file
- sort file section
- improve find language
* Sat Apr 13 2013 Dan Mashal  - 1.6.0-1
- Update to latest 1.6.0 stable release.
* Thu Feb 14 2013 Fedora Release Engineering  
- 1.5.0-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild




 mate-image-viewer-1.6.1-1.fc17 (FEDORA-2013-13907)
 Eye of MATE image viewer

Update Information:

Various bugfixes, latest upstream release

ChangeLog:

* Mon Jul 29 2013 Dan Mashal  - 1.6.1-1
- Update to latest 1.6.1 stable release.




 mozilla-https-everywhere-3.3.1-1.fc17 (FEDORA-2013-13908)
 HTTPS/HSTS enforcement extension for Mozilla Firefox and SeaMonkey

Update Information:

3.3.1
- [Wikimedia] removed mixedcontent

3.3
- This major release fixed the following mixed content blocker (MCB) 
 -- re

Re: Template for marking test cases that are associated with release criteria

2013-07-30 Thread Adam Williamson 
On Tue, 2013-07-30 at 08:29 -0400, Kamil Paral wrote:
> > I slapped together a quick template for adding a 'note' to a test case
> > that it enforces one of the release criteria.
> > https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_anaconda_user_creation
> > gives an example of how to use it:
> > 
> > {{Template:Associated_release_criterion|releasecriterion=Fedora_{{FedoraVersionNumber|next}}_Alpha_Release_Criteria#Expected_installed_system_boot_behavior}}
> 
> Maybe I'd put the note at the bottom of the test case, instead of the top?

Eh, I dunno if it makes much of a difference, and I'd have to go edit a
hundred pages to change it now :)

> And maybe it doesn't have to be highlighted, but it can be a standard
> section (a header and a text)?

> We will likely have this present in many test cases and the current
> appearance seems too... shouting. It's not an especially important
> information (unlike, for example, an information which bugs currently
> affect test case verification). It's a useful information and a
> standard part of every relevant test case, so maybe it should look
> like a standard text part?
> 
> Example:
> https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_anaconda_user_creation2
> (there is an extra vertical space due to Test_case template, can be
> fixed)

I don't really like that, no. To me, using an admon template isn't
'shouting', it's just cueing the reader in that what they're about to
read is some kind of notice about the rest of the content. If we just
make it a paragraph it looks like it's actually part of the test case in
some way, which it isn't, exactly.

> > 
> > Basically you just take the part after /wiki/ from the release
> > criterion's URL and plug that in as the 'releasecriterion' variable
> for
> > the template, but because the release criteria pages are versioned,
> you
> > have to replace the 'Fedora_20' bit with
> 'Fedora_{{FedoraVersionNumber|
> > next}}' . We could have the release criteria pages unversioned, but
> it's
> > actually quite useful to be able to 'go back in time' and look at
> what
> > our release requirements were for a given previous release.
> 
> What about using an unversioned page for Branched (with an existing
> FNN redirect) and once Fedora is released, just copy the contents into
> FNN page for historic purposes? It would simplify some things (links
> in our guides etc), and complicate others (links in bugzilla could go
> outdated).

Yeah, I thought of that, personally I didn't really love the
trade-off...I think this is more something we might solve by moving the
criteria into the webapp or something.

> Or maybe the other way around, redirect
> https://fedoraproject.org/wiki/Fedora_Alpha_Release_Criteria to
> https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria ? And
> use these unversioned links at least in the "associated criteria"
> template?
> 
> Unfortunately templates can't be used in redirects, so we would have
> to update these 3 redirects (Alpha, Beta, Final) every 6 months
> manually. So, maybe your solution (template in a template) is the best
> solution after all...

May well be (there's nothing wrong with it, templates are _built_ to be
nested). But one thing I did realize is I could make the template
invocation much less silly: I can just rejig it so to use the template
you just do:

{{Template:Associated_release_criterion|Alpha|
Expected_installed_system_boot_behavior}} (for example) - I think that's
probably going to be easier to read and remember. I'll try and do that
today (unfortunately it involves editing a hundred pages...:>)
-- 
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: Template for marking test cases that are associated with release criteria

2013-07-30 Thread Kamil Paral 
> I slapped together a quick template for adding a 'note' to a test case
> that it enforces one of the release criteria.
> https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_anaconda_user_creation
> gives an example of how to use it:
> 
> {{Template:Associated_release_criterion|releasecriterion=Fedora_{{FedoraVersionNumber|next}}_Alpha_Release_Criteria#Expected_installed_system_boot_behavior}}

Maybe I'd put the note at the bottom of the test case, instead of the top?

And maybe it doesn't have to be highlighted, but it can be a standard section 
(a header and a text)?

We will likely have this present in many test cases and the current appearance 
seems too... shouting. It's not an especially important information (unlike, 
for example, an information which bugs currently affect test case 
verification). It's a useful information and a standard part of every relevant 
test case, so maybe it should look like a standard text part?

Example:
https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_anaconda_user_creation2
(there is an extra vertical space due to Test_case template, can be fixed)

> 
> Basically you just take the part after /wiki/ from the release
> criterion's URL and plug that in as the 'releasecriterion' variable for
> the template, but because the release criteria pages are versioned, you
> have to replace the 'Fedora_20' bit with 'Fedora_{{FedoraVersionNumber|
> next}}' . We could have the release criteria pages unversioned, but it's
> actually quite useful to be able to 'go back in time' and look at what
> our release requirements were for a given previous release.

What about using an unversioned page for Branched (with an existing FNN 
redirect) and once Fedora is released, just copy the contents into FNN page for 
historic purposes? It would simplify some things (links in our guides etc), and 
complicate others (links in bugzilla could go outdated).

Or maybe the other way around, redirect 
https://fedoraproject.org/wiki/Fedora_Alpha_Release_Criteria to 
https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria ? And use these 
unversioned links at least in the "associated criteria" template?

Unfortunately templates can't be used in redirects, so we would have to update 
these 3 redirects (Alpha, Beta, Final) every 6 months manually. So, maybe your 
solution (template in a template) is the best solution after all...

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: cups

2013-07-30 Thread Tim Waugh 
On Mon, 2013-07-29 at 09:20 -0700, richard.vicker...@gmail.com wrote: 
> I thought CUPS was developed by the open source community; I was just
> setting up the printer and impressed that the program called up the
> commands itself, and thought one of us was responsible for making it
> so easy, even if at a lesser extent. 

There is no single "open source community" really.  CUPS is developed as
open source, and Apple does most of the core development.

If you're thinking about automatic printer driver installation, or
automatic queue set-up when a USB printer is connected, or the slick
Printers page in the GNOME System Settings tool... those features were
largely developed by Red Hat. :-)

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: how do I tell what release yum upgrade will give me?

2013-07-30 Thread Frank Murphy 
http://docs.fedoraproject.org/en-US/Fedora/14/html/Deployment_Guide/sec-Using_Yum_Variables.html


On 30 July 2013 07:59, Adam Williamson  wrote:

> On Tue, 2013-07-30 at 02:16 -0400, Felix Miata wrote:
> > On 2013-07-29 22:51 (GMT-0700) Adam Williamson composed:
> >
> > >> how do those who want to keep a system on Rawhide instead of
> > >> switching to branch after each branch occurs do it?
> >
> > > There isn't a particularly easy way, you just have to make sure
> > > fedora-release-rawhide is installed and tweak the enabled repos, AFAIK.
> > > I guess if you edited the .repo files directly they wouldn't get
> > > overridden on updates?
> >
> > If by "tweaking" you mean manual manipulation of /etc/yum.repos.d/
> content,
> > I'd need a howto. I don't do so well on my own messing with config files
> > containing $ &/or ? in URLs.
>
> No, I actually use the GUI (!!!) for that. I've no idea what it does,
> but it works.
> --
> 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




-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of fedoraproject.org
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test