The following Fedora 16 Security updates need testing:
Age URL
8
https://admin.fedoraproject.org/updates/FEDORA-2012-14363/phpldapadmin-1.2.2-3.gitbbedf1.fc16
8 https://admin.fedoraproject.org/updates/FEDORA-2012-14322/pcp-3.6.8-1.fc16
80
https://admin.fedoraproject.org/updates/FEDOR
The following Fedora 17 Security updates need testing:
Age URL
8
https://admin.fedoraproject.org/updates/FEDORA-2012-14344/phpldapadmin-1.2.2-3.gitbbedf1.fc17
83
https://admin.fedoraproject.org/updates/FEDORA-2012-10269/revelation-0.4.14-1.fc17
8 https://admin.fedoraproject.org/updat
I think this is a vast improvement over the previous images as expected.
I tested the DVD iso on a virtual machine and here are some observations.
1. The image is automatically recognized as local repo and it works fine.
2. Package selection screen actually allows selection of packages (to
the
=
#fedora-qa: f18-beta-blocker-review-1
=
Minutes:
http://meetbot.fedoraproject.org/fedora-qa/2012-09-26/f18-beta-blocker-review-1.2012-09-26-16.03.html
Minutes (text):
http://meetbot.fedoraproject.org/fedora-qa/2012-09-26/f
On Wed, Sep 26, 2012 at 20:05:13 +0100,
"Richard W.M. Jones" wrote:
On Wed, Sep 26, 2012 at 12:54:40PM +, Fedora Rawhide Report wrote:
[libguestfs]
1:libguestfs-1.19.44-2.fc19.i686 requires selinux-policy >= 0:3.11.1-23
1:libguestfs-1.19.44-2.fc19.x86_64 requires selinux-p
On Tue, Sep 25, 2012 at 08:20:48PM -0700, Adam Williamson wrote:
> 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
#81: Add i18n release criteria
--+---
Reporter: jlaska | Owner:
Type: enhancement | Status: reopened
Priority: major| Milestone: Fedora 14
Component: Wiki |Version:
Resolution: | Ke
On Wed, 2012-09-26 at 08:46 -0700, Adam Williamson wrote:
> On Wed, 2012-09-26 at 08:50 -0600, Tim Flink wrote:
> > On Wed, 26 Sep 2012 16:47:16 +0200
> > drago01 wrote:
> >
> > > > Would we OK with shipping beta with only yum upgrades working? While
> > > > it's not currently a 'recommended' met
> Reviving this discussion from August to make a decision on what we're
> going to do about the mediacheck release criterion
>
> The current criterion reads:
>
> If there is an embedded checksum on any release medium, it must be
> correct.
>
> The last proposed criterion update was:
>
> > "If t
On Wed, 2012-09-26 at 09:26 -0600, Stephen John Smoogen wrote:
> A user can upgrade your XP -> Vista, XP -> 7?, 7->8 etc and it will
> mostly work.
Well there's that, and also...I don't recall the details and I may be
wrong, but I thought I'd read that the 'upgrade' to 7 from anything but
Vista
On Wed, 2012-09-26 at 08:50 -0600, Tim Flink wrote:
> On Wed, 26 Sep 2012 16:47:16 +0200
> drago01 wrote:
>
> > > Would we OK with shipping beta with only yum upgrades working? While
> > > it's not currently a 'recommended' method for upgrades right now as
> > > far as I know, that could certainl
On Wed, 2012-09-26 at 08:41 -0600, Tim Flink wrote:
> Would we OK with shipping beta with only yum upgrades working? While
> it's not currently a 'recommended' method for upgrades right now as far
> as I know, that could certainly change.
If we started considering it a recommended method, then su
On 26 September 2012 01:10, drago01 wrote:
> On Wed, Sep 26, 2012 at 5:20 AM, Adam Williamson wrote:
>> 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
On Wed, Sep 26, 2012 at 4:50 PM, Tim Flink wrote:
> On Wed, 26 Sep 2012 16:47:16 +0200
> drago01 wrote:
>
>> > Would we OK with shipping beta with only yum upgrades working? While
>> > it's not currently a 'recommended' method for upgrades right now as
>> > far as I know, that could certainly cha
On 09/26/2012 02:47 PM, drago01 wrote:
No that way the upgrade method used by most users (which is even new
code this time) will get even less testing.
Yum upgrades ( even thou officially unsupported ) is the preferred
method to upgrade Fedora in this country so I guess it's depends on
where
On 09/26/2012 02:41 PM, Tim Flink wrote:
Would we OK with shipping beta with only yum upgrades working? While
it's not currently a 'recommended' method for upgrades right now as far
as I know, that could certainly change.
Ack
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
htt
On Wed, 26 Sep 2012 16:47:16 +0200
drago01 wrote:
> > Would we OK with shipping beta with only yum upgrades working? While
> > it's not currently a 'recommended' method for upgrades right now as
> > far as I know, that could certainly change.
>
> No that way the upgrade method used by most users
Reviving this discussion from August to make a decision on what we're
going to do about the mediacheck release criterion
The current criterion reads:
If there is an embedded checksum on any release medium, it must be
correct.
The last proposed criterion update was:
> "If there is an embedded ch
On Wed, Sep 26, 2012 at 4:41 PM, Tim Flink wrote:
> On Mon, 24 Sep 2012 10:32:01 -0600
> Tim Flink wrote:
>
>> As currently written, the upgrade criterion in the Fedora 18 beta
>> release requirements [1] reads:
>>
>> The installer must be able to successfully complete an upgrade
>> installation
On 09/26/2012 10:37 AM, Kamil Paral wrote:
> I personally split maintainers in the distribution into three
> categories.
>
> 1. Packager
>
> 2, Maintainer
>
> 3. Upstream maintainer
Is this an argument for an additional Fedora package class? At present,
it seems there are two well-defined types:
On Mon, 24 Sep 2012 10:32:01 -0600
Tim Flink wrote:
> As currently written, the upgrade criterion in the Fedora 18 beta
> release requirements [1] reads:
>
> The installer must be able to successfully complete an upgrade
> installation from a clean, fully updated default installation (from
> any
On 09/26/2012 10:45 AM, Karel Volný wrote:
Dne St 26. září 2012 10:37:54, Jan Pazdziora napsal(a):
>(they have accounts in the upstream bug tracking systems).
just a note, this is very valid point
Indeed but will never come to be unless it will be made mandatory for
packagers , pack of the r
On 09/26/2012 10:37 AM, Kamil Paral wrote:
I personally split maintainers in the distribution into three
categories.
1. Packager
2, Maintainer
3. Upstream maintainer
Nice categorization.
We differ in the view of Packagers. You consider them harmful, I consider them desired. I am
missing *lo
Dne St 26. září 2012 10:37:54, Jan Pazdziora napsal(a):
> (they have accounts in the upstream bug tracking systems).
just a note, this is very valid point
I've given up reporting many problems just because of the initial
barrier - to find the upstream way of handling bugs (not every
project has i
On 09/26/2012 10:28 AM, Kamil Paral wrote:
I completely missed my point. I was suggesting middle ground - lots of packages
and clear bug reporting guidelines configurable for each of them. That can help
us avoid stale NEW bugs.
That is something you need to fix on packagers/maintainers level
> I personally split maintainers in the distribution into three
> categories.
>
> 1. Packager
>
> 2, Maintainer
>
> 3. Upstream maintainer
Nice categorization.
We differ in the view of Packagers. You consider them harmful, I consider them
desired. I am missing *lots* of packages in Fedora whe
> I'd rather have limited set of packages that are well supported with
> bugzillas acted upon than load of packages where bugzillas are all
> NEW
> or UPSTREAM.
I completely missed my point. I was suggesting middle ground - lots of packages
and clear bug reporting guidelines configurable for each
On 09/26/2012 10:08 AM, Jan Pazdziora wrote:
On Wed, Sep 26, 2012 at 05:25:06AM -0400, Kamil Paral wrote:
In my opinion this should be a maintainer choice. Ideally there would be a support for this choice in
Bugzilla. When reporting a new bug against component X, "bug reporting guidelines" woul
On 09/26/2012 07:50 AM, Matej Cepl wrote:
On 26/09/12 01:21, "Jóhann B. Guðmundsson" wrote:
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.
Yes, I think it could be preferred way for some bugs and some
co
On Wed, Sep 26, 2012 at 05:25:06AM -0400, Kamil Paral wrote:
> In my opinion this should be a maintainer choice. Ideally there would be a
> support for this choice in Bugzilla. When reporting a new bug against
> component X, "bug reporting guidelines" would be displayed (Launchpad already
> supp
On 09/26/2012 08:37 AM, Jan Pazdziora wrote:
The Fedora maintainers are supposed to bring the upstream to the
distribution and maintain it there. The Fedora users are supposed
to use the distribution, not compile the upstream themselves. It's
the Fedora maintainer that should do the communication
On 09/26/2012 09:25 AM, Kamil Paral wrote:
In my opinion this should be a maintainer choice.
That will only lead to confusion for members of the QA community.
Either we direct all QA community members upstream *always* or we keep
them locally *always*
JBG
--
test mailing list
test@lists.fed
> > What would you prefer? Upstream balancing five bug reports in five
> > downstream bug trackers (plus his own) and wasting ton of time just
> > coordinating and communicating with them, or five bug reporters
> > (and
> > their package maintainers, if required) working with the upstream
> > in
>
The following Fedora 16 Security updates need testing:
Age URL
7
https://admin.fedoraproject.org/updates/FEDORA-2012-14363/phpldapadmin-1.2.2-3.gitbbedf1.fc16
7
https://admin.fedoraproject.org/updates/FEDORA-2012-14295/moodle-2.1.8-1.fc16
7 https://admin.fedoraproject.org/updates/FE
On 09/26/2012 08:31 AM, Kamil Paral wrote:
What is the intended use case of test-announce@?
Marketing
JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
> > > '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 g
On Wed, Sep 26, 2012 at 09:50:06AM +0200, Matej Cepl wrote:
> On 26/09/12 01:21, "Jóhann B. Guðmundsson" wrote:
> >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.
>
> Yes, I think it could be preferred way
I wonder, are all test-announce@ subscribers happy to see these announcements,
or is posting to test@ list good enough?
I am not sure why new versions of a specific package goes to test-announce@,
but new versions of other packages are not announced there.
What is the intended use case of test-
On 26/09/12 01:21, "Jóhann B. Guðmundsson" wrote:
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.
Yes, I think it could be preferred way for some bugs and some components
(i.e., I would suggest much more a
On Wed, Sep 26, 2012 at 5:20 AM, Adam Williamson wrote:
> 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
40 matches
Mail list logo
