headers
Jon Stanley | 1 Feb 02:37
Picon

Re: New criterion for installation with minimal set of packages

On Tue, Jan 31, 2012 at 2:56 PM, Bill Nottingham <notting <at> redhat.com> wrote:

>> That's an implementation detail. It's not a capability-driven
>> description of which packages should actually be in the minimal package
>> set, as was discussed earlier in the thread.
>
> Merely stating that if you're linking to what the minimal set of packages
> will be, that's it.

But to Adam's point, who defines what is in @core and what it can do?
Could I decide tomorrow that the GNOME desktop is a core functionality
of the distro and commit it to comps and so it is (I seriously hope
someone would come shoot me if I *actually* did that :) )?

I guess this goes to the point that no one "owns" comps groups, but I
think someone should, and @core (and to a lesser extent @base) should
be "special" to have some defined set of functionality.

But I think this is getting *way* off topic for QA and should be a
fesco discussion :)
--

-- 
test mailing list
test <at> lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Permalink | Reply | 0 comments |
headers
Ralf Corsepius | 1 Feb 08:04
Picon
Favicon

Re: New testcase for installation without selinux

On 01/31/2012 09:00 PM, Adam Williamson wrote:
> On Tue, 2012-01-31 at 11:43 -0500, Chris Lumens wrote:
>>> "The installed system must run normally if the user chooses to install without SELinux"
>>>
>>> There is no test case for this now.
>>>
>>> I have one note on this. There is used noselinux option, but it doesn't work now. I filled bug [2] there is
another option with the same effect - selinux=0 and this one works fine, but Anaconda have noselinux in
documentation, so it should work and they're working on it.
>>
>> The option to install without selinux was added at a time when selinux
>> was a new, experimental feature in Fedora.  Now, it's an integral part
>> of the distribution.  It's time for this option to go away.

I disagree. Though SELinux isn't in the poor shape it once was, there 
are still situations, where users prefer or can not avoid to switch off 
SELinux.

> If we don't want to support that, the alternative is to ditch the
> release criterion. I'm okay with that.

I am not OK with that.

Ralf
--

-- 
test mailing list
test <at> lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Permalink | Reply | 1 comment |
headers
drago01 | 1 Feb 08:47
Picon

Re: Change of release level of Mediakit ISO Size test case

On Tue, Jan 31, 2012 at 7:29 PM, Adam Williamson <awilliam <at> redhat.com> wrote:
> On Tue, 2012-01-31 at 11:05 -0500, Petr Schindler wrote:
>
>> > We made this Beta not Alpha in the criteria on purpose, specifically
>> > because we don't think it's a significant enough problem if the lives
>> > are over-size at Alpha stage. It *may* be worth requiring at least
>> > the
>> > DVD to meet size requirements at Alpha size, although even if it's
>> > over,
>> > you can still test it in a VM or with a USB stick. I definitely think
>> > we
>> > shouldn't make the live sizes mandatory at Alpha.
>>
>> Here I don't know. I test in pre-alpha phase only on my VMs. When I
>> want to boot on bare metal, I use USB stick. But it's truth that
>> nothing new should be added after alpha. So the size of images should
>> be quite the same then or not? Still I think it could be in beta.
>
> When we talk about 'nothing being added' after Alpha we're really
> talking about major features. The package sets on the media can, and do,
> change. It doesn't happen so much lately, but it's been the case in the
> past that the Alpha live images were, say, 800MB, because no-one had yet
> trimmed the package set down to keep them under a CD in size. Then they
> did get properly trimmed down for Beta or Final. We don't want to block
> the Alpha if this happens.

Yes this has been discussed multiple times but ... do we really still
care about "omg it does not fit on a CD" ?
I mean it is 2012 ...
--

--
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frank Murphy | 1 Feb 11:33
Picon
Gravatar

Re: usrmove problem

On 31/01/12 17:26, Adam Williamson wrote:
>
> The initramfs is generated on-the-fly when the kernel is installed.

I presume initramfs gets the libc.so.6 from /usr/lib ?

On my post /usr box.
/usr/lib/libc.so.6 is a symlink itself to /usr/lib/libcc-2.15.so

Is it the double softlink that's breaking things.
/usr/bin/ > /usr/lib/libc.so.6 > /usr/lib/libcc-2.15.so

-- 
Regards,

Frank Murphy, friend of fedoraproject
UTF_8 Encoded
--

-- 
test mailing list
test <at> lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Permalink | Reply | 1 comment |
headers
Frank Murphy | 1 Feb 11:35
Picon
Gravatar

Re: usrmove problem

On 01/02/12 10:33, Frank Murphy wrote:

>
> Is it the double softlink that's breaking things.
> /usr/bin/ > /usr/lib/libc.so.6 > /usr/lib/libcc-2.15.so
>

that should be
/lib >  > /usr/lib/libc.so.6 > /usr/lib/libcc-2.15.so

-- 
Regards,

Frank Murphy, friend of fedoraproject
UTF_8 Encoded
--

-- 
test mailing list
test <at> lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Permalink | Reply | 0 comments |
headers
Petr Schindler | 1 Feb 11:40
Picon
Favicon

Re: New criterion for Checksum

On Tue, 2012-01-31 at 10:23 -0800, Adam Williamson wrote:
> On Tue, 2012-01-31 at 07:48 -0500, Petr Schindler wrote:
> 
> > OK, so test case should stay in alpha and new criterion should be in
> > alpha too. I propose to drop the part about embedded checksum (that
> > would be only additional check) and new criterion should be:
> > 
> > "A correct checksum must be published for each official release
> > image."
> > 
> > The second possibility is to have two criteria, first in alpha and
> > second in beta. In beta, there would be included embedded checksum.
> > 
> > I think that first option is better.
> 
> Well, I think we probably want to ensure the embedded checksum is
> correct at final - it would look silly to ship a release where the
> built-in media check always fails, after all. So I think we may want to
> have that second criterion at least for final.

You are right. So beside this alpha criterion I propose new final
criterion:

"If there is embedded checksum on ISO media, it must be correct."

Test case [1] should be mark as Alpha/Final release level.

[1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums

> BTW, Petr, can you set your mail client to wrap at 72 characters, as is
(Continue reading)

Permalink | Reply | 7 comments |
headers
Frank Murphy | 1 Feb 11:45
Picon
Gravatar

Re: New criterion for Checksum

On 01/02/12 10:40, Petr Schindler wrote:

> You are right. So beside this alpha criterion I propose new final
> criterion:
>
> "If there is embedded checksum on ISO media, it must be correct."
>

Not  trying to hijack.
But, is there a reason md5 is still being used?

-- 
Regards,

Frank Murphy, friend of fedoraproject
UTF_8 Encoded
--

-- 
test mailing list
test <at> lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Permalink | Reply | 4 comments |
headers
Andre Robatino | 1 Feb 17:11
Favicon

New criterion for Checksum

Frank Murphy <frankly3d <at> gmail.com> writes:

> > "If there is embedded checksum on ISO media, it must be correct."
> >
> 
> Not  trying to hijack.
> But, is there a reason md5 is still being used?

A built-in checksum is only useful for checking for natural corruption, not a
deliberate fake (since in that case it's easy to change the checksum to the
correct one for the fake). Even md5 is more than enough for this purpose.

--

-- 
test mailing list
test <at> lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Permalink | Reply | 3 comments |
headers
Frank Murphy | 1 Feb 17:14
Picon
Gravatar

Re: New criterion for Checksum

On 01/02/12 16:11, Andre Robatino wrote:

>
> A built-in checksum is only useful for checking for natural corruption, not a
> deliberate fake (since in that case it's easy to change the checksum to the
> correct one for the fake). Even md5 is more than enough for this purpose.
>

So it's not error proof,
it can fail and still have a perfect disk, correct.

-- 
Regards,

Frank Murphy, friend of fedoraproject
UTF_8 Encoded
--

-- 
test mailing list
test <at> lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Permalink | Reply | 2 comments |
headers
Andre Robatino | 1 Feb 17:33
Favicon

New criterion for Checksum

Frank Murphy <frankly3d <at> gmail.com> writes:

> > A built-in checksum is only useful for checking for natural corruption, not a
> > deliberate fake (since in that case it's easy to change the checksum to the
> > correct one for the fake). Even md5 is more than enough for this purpose.
> >
> 
> So it's not error proof,
> it can fail and still have a perfect disk, correct.

Yes, there can be a bug that causes the mediacheck to fail even though the disc
is good (this actually happened recently during development). Conversely, it can
pass even if the disc is fake. Personally, I always do the external check, for
example Fedora-16-x86_64-DVD.iso is 3757047808 bytes, so after burning I check
it by running

dd if=/dev/dvd bs=2048 count=1834496 conv=notrunc,noerror | sha256sum

(since 3757047808/2048=1834496) and comparing the sha256sum to the checksum
file. This has the slight advantage that it checks the entire image, while the
built-in check leaves out the small part containing the md5 itself. It's also
the kind of check you'd want to do if someone you didn't know or trust handed
you a "Fedora" disc, since in that case the disc can't be trusted to check
itself (if you burn it yourself from an ISO that you verified has the right
sha256sum, that's not an issue).

--

-- 
test mailing list
test <at> lists.fedoraproject.org
To unsubscribe:
(Continue reading)

Permalink | Reply | 1 comment |

Gmane