Re: Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases
On 04/10/2012 09:04 AM, Adam Williamson wrote: > On Mon, 2012-04-09 at 22:15 -0500, Bruno Wolff III wrote: >> I think we want preupgrade to work for at least beta. I think just not >> blocking the composes, but requiring it to work for beta is better than >> waiting until final. > > That's the intent of option 2). Though to be honest, we're not terribly > good at following through on it. When we've had preupgrade / > livecd-tools 'blockers' before, we've sometimes not managed to get the > fix pushed stable by release date. I think it's a great idea to not block media composes for preupgrade issues. However, it is still a supported upgrade method and needs Beta testing. I would definitely not move preupgrade to only blocking final release; why else are we doing Beta releases if not to get testing? What I would do is treat preupgrade bugs at Go/No-Go meetings as release blockers, but at the same time not require install media respin for preupgrade fixes. This should allow more flexibility and faster turnover for validation. As long as there is a process to accept Anaconda builds to stable during the freeze without doing composes, I believe this should work. -- Kalev -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Fedora 17 Beta Release Candidate 3 (RC3) Available Now!
On Mon, 2012-04-09 at 18:57 -0700, Adam Williamson wrote: > On Mon, 2012-04-09 at 12:42 +0100, Piscium wrote: > > On 9 April 2012 07:21, Adam Williamson wrote: > > > > > Did you have actual window frames on the dialogs in question? Sometimes > > > this can happen when no WM that firstboot can actually work with is > > > present on the spin - you just get unmanaged windows. > > > > As far as I remember there were no frames, but I am not sure. > > > > I booted into my F17 test partition, ran firstboot as root, and the > > window frames were there and I could not reproduce the issue. > > > > I tried to have a more realistic firstboot experience by editing > > /etc/sysconfig/firstboot and removing the line RUN_FIRSTBOOT=NO, but > > that did not work, it still went into the login screen. It might have > > something to do with systemd. Its firstboot file has a line that says > > that type is one shot. Is there a way of tricking systemd into > > rerunning firstboot despite being one shot? Or maybe one shot does not > > mean what I think it means? > > One shot doesn't mean what you think it means. > > firstboot employs a belt-and-braces method of disabling itself - to get > it to fire again you have to turn it on twice. > =) /etc/sysconfig/firstboot is one place, you found that, but you missed > the other: you have to re-enable it as a service. So, in the Systemd > Age: > > systemctl enable firstboot.service > > that should do the trick. Gack. Actually it won't: systemctl enable firstboot-graphical.service Should be better. -- 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: Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases
On Mon, 2012-04-09 at 22:15 -0500, Bruno Wolff III wrote: > On Mon, Apr 09, 2012 at 19:13:31 -0700, >Adam Williamson wrote: > > > >So, I'm proposing one of two options: > > > >1) Simply bump preupgrade to the Final release criteria > > > >2) Keep preupgrade in the Beta criteria, but treat all preupgrade issues > >- even those that are in the anaconda package - the way we currently > >treat blocker issues in livecd-tools or the preupgrade package itself: > >consider them as not blocking image compose. Rather, we require the > >maintainer to push out an update before the release date. We could put > >issues in anaconda that only affect preupgrade into the same category. > > I think we want preupgrade to work for at least beta. I think just not > blocking the composes, but requiring it to work for beta is better than > waiting until final. That's the intent of option 2). Though to be honest, we're not terribly good at following through on it. When we've had preupgrade / livecd-tools 'blockers' before, we've sometimes not managed to get the fix pushed stable by release date. -- 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: Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases
On Mon, 2012-04-09 at 19:18 -0700, Dan Mashal wrote: > As I said in the meeting let's just deprecate it. Please, don't wildly derail the discussion. That's entirely outside the scope of QA and not at all the issue I want to talk about. You're proposing a major alteration of policy which would be very controversial. I'm proposing a fairly straightforward adjustment of policy to the existing compose process. They're very different things. If you want to propose deprecating preupgrade, then please do it separately... -- 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: [Test-Announce] Fedora 17 Beta Release Candidate 4 (RC4) Available Now!
Awesome! On Mon, Apr 9, 2012 at 10:54 PM, Andre Robatino wrote: > As per the Fedora 17 schedule [1], Fedora 17 Beta Release Candidate 4 > (RC4) is now available for testing. Content information, including > changes, can be found at https://fedorahosted.org/rel-eng/ticket/5141 . > Please see the following pages for download links (including delta ISOs) > and testing instructions. Normally dl.fedoraproject.org should provide > the fastest download, but download-ib01.fedoraproject.org is available > as a mirror (with an approximately 1 hour lag) in case of trouble. To > use it, just replace "dl" with "download-ib01" in the download URL. > > Installation: > > https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test > > Base: > > https://fedoraproject.org/wiki/Test_Results:Current_Base_Test > > Desktop: > > https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test > > Ideally, all Alpha and Beta priority test cases for Installation [2], > Base [3], and Desktop [4] should pass in order to meet the Beta Release > Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], > or on the test list [7]. > > Create Fedora 17 Beta release candidate (RC) - live and traditional > https://fedorahosted.org/rel-eng/ticket/5141 > > F17 Beta Blocker tracker bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752649 > > F17 Beta Nice-To-Have tracker bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752652 > > [1] > http://rbergero.fedorapeople.org/schedules/f-17/f-17-quality-tasks.html > [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing > [3] https://fedoraproject.org/wiki/QA:Base_validation_testing > [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing > [5] https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria > [6] irc://irc.freenode.net/fedora-qa > [7] https://admin.fedoraproject.org/mailman/listinfo/test > > > ___ > 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 > -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] Fedora 17 Beta Release Candidate 4 (RC4) Available Now!
As per the Fedora 17 schedule [1], Fedora 17 Beta Release Candidate 4 (RC4) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5141 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace "dl" with "download-ib01" in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha and Beta priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Beta Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. Create Fedora 17 Beta release candidate (RC) - live and traditional https://fedorahosted.org/rel-eng/ticket/5141 F17 Beta Blocker tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752649 F17 Beta Nice-To-Have tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752652 [1] http://rbergero.fedorapeople.org/schedules/f-17/f-17-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital 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: Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases
1) Yum should be intelligent enough to recognize this 2) yum-plugin-fastestmirror solves this problem. 3) I think we all upgraded from 14.4k modems a few years ago. Dan On Mon, Apr 9, 2012 at 8:35 PM, John Reiser wrote: > On 04/09/2012 07:18 PM, Dan Mashal wrote: > > As I said in the meeting let's just deprecate it [in favor of > yum+network]. > > The problems I have seen with using only yum+network to perform a distro > version upgrade are: > > 1. It's a poor idea to be running almost anything else on the box > at the same time as a distro version upgrade. It is quite likely > that an app will encounter difficulties because of mismatched versions > of the components on which it relies. [For instance, I've run across > situations where software-initiated reboot *hangs* after distro version > upgrade; I had to push the reset button.] Thus single user mode should > be considered a requirement for distro version upgrade via yum+network, > although often it happens to work in multi-user mode if the box > is "otherwise idle". > > 2. yum is stupidly slow about collecting the upgrade .rpms. > First there is downloading itself: yum downloading [of any kind] > is single threaded. Often this wastes 30% to 50% of available > bandwidth (at the server and/or in the pipe.) > A close-to-optimal strategy for typical cable modem ISP is: > 1. Sort the download list by size of file to be downloaded. > 2. Run two parallel threads. The first thread downloads > from large to small, the second from small to large. > Stop when the threads meet somewhere in the "middle". > [Debian has a two-thread download for "apt upgrade". It does not > use the optimal strategy, but it is still effective.] > > Second, yum does not download the remaining .rpm (whose .drpm > are not available) while it is reconstituting the other .rpm > from .drpm. The waste can be significant for the common case > when there are enough .drpm for some large .rpms (kernel, > libreoffice-*, etc.) > > 3. If distro version upgrade via yum+network fails (power failure, > network failure, configuration failure, operator error, ...), > then you have a big mess. > The .rpm are not saved, so re-downloading might be substantial. > If an expert is not available for hands-on analysis and repair, > then a fresh install might be the best choice to achieve > shortest down time. > > Thus effective downtime can be reduced substantially if preupgrade > manages to parallelize the collection of the anticipated .rpms > (download .drpm and .rpm, reconstitute .rpm from .drpm) > with normal multi-user operation of the machine under the old > distro version. > > -- > -- > test mailing list > test@lists.fedoraproject.org > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/test > -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any lxde or xfce spin nightly build available?
> RC4 hasn't been built yet.
> I believe you'll need to run liveinst --no-memcheck from the
> command line
> to install on a machine with 512 MiB, as the minimum memory
> size hasn't
> been updated, even though less memory will probably work
> now. (I did a
> test install to a machine with 512 MiB about a week agio and
> things worked
> OK.)
>
Dear sir,
Thank you for the tip :) I have successfully installed
nighlty build 0409 lxde on my machine
To share your profile:
http://www.smolts.org/client/show/pub_9d8ca8c7-0d17-4611-a6c0-100dd5f4a5c1
(public)
It was running Fedora 15 xfce. Now, I have another question, I want to add
FreeBSD entry to grub 2, but I don't know how. I have tried to follow some
guides but they are for Ubuntu and don't seem to work for Fedora.
The setup found Windows XP Home, and the reinstallation partition but missed
the FreeBSD part:
[root@acer-aspire-1 ~]# fdisk -l
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xd2107a38
Device Boot Start End Blocks Id System
/dev/sda1 6312594959 6297448+ 12 Compaq diagnostics
/dev/sda21259520096481279419430407 HPFS/NTFS/exFAT
/dev/sda3 *96481287 20133886452428789 a5 FreeBSD
/dev/sda4 201338880 312581807556214645 Extended
/dev/sda5 201340928 202364927 512000 83 Linux
/dev/sda6 202366976 31258009555106560 8e Linux LVM
Is there a nice template or way to add it so I can also boot FreeBSD?
Something like
menuentry "FreeBSD"
{
insmod ufs2
set root='(hd0,3)
chainloader +1
}
should do it, but where do I place this file and how to let grub 2 know about
FreeBSD?
Regards,
Antonio
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases
On 04/09/2012 07:18 PM, Dan Mashal wrote: > As I said in the meeting let's just deprecate it [in favor of yum+network]. The problems I have seen with using only yum+network to perform a distro version upgrade are: 1. It's a poor idea to be running almost anything else on the box at the same time as a distro version upgrade. It is quite likely that an app will encounter difficulties because of mismatched versions of the components on which it relies. [For instance, I've run across situations where software-initiated reboot *hangs* after distro version upgrade; I had to push the reset button.] Thus single user mode should be considered a requirement for distro version upgrade via yum+network, although often it happens to work in multi-user mode if the box is "otherwise idle". 2. yum is stupidly slow about collecting the upgrade .rpms. First there is downloading itself: yum downloading [of any kind] is single threaded. Often this wastes 30% to 50% of available bandwidth (at the server and/or in the pipe.) A close-to-optimal strategy for typical cable modem ISP is: 1. Sort the download list by size of file to be downloaded. 2. Run two parallel threads. The first thread downloads from large to small, the second from small to large. Stop when the threads meet somewhere in the "middle". [Debian has a two-thread download for "apt upgrade". It does not use the optimal strategy, but it is still effective.] Second, yum does not download the remaining .rpm (whose .drpm are not available) while it is reconstituting the other .rpm from .drpm. The waste can be significant for the common case when there are enough .drpm for some large .rpms (kernel, libreoffice-*, etc.) 3. If distro version upgrade via yum+network fails (power failure, network failure, configuration failure, operator error, ...), then you have a big mess. The .rpm are not saved, so re-downloading might be substantial. If an expert is not available for hands-on analysis and repair, then a fresh install might be the best choice to achieve shortest down time. Thus effective downtime can be reduced substantially if preupgrade manages to parallelize the collection of the anticipated .rpms (download .drpm and .rpm, reconstitute .rpm from .drpm) with normal multi-user operation of the machine under the old distro version. -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases
On Mon, Apr 09, 2012 at 19:13:31 -0700, Adam Williamson wrote: So, I'm proposing one of two options: 1) Simply bump preupgrade to the Final release criteria 2) Keep preupgrade in the Beta criteria, but treat all preupgrade issues - even those that are in the anaconda package - the way we currently treat blocker issues in livecd-tools or the preupgrade package itself: consider them as not blocking image compose. Rather, we require the maintainer to push out an update before the release date. We could put issues in anaconda that only affect preupgrade into the same category. I think we want preupgrade to work for at least beta. I think just not blocking the composes, but requiring it to work for beta is better than waiting until final. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases
On Mon, Apr 09, 2012 at 19:18:26 -0700, Dan Mashal wrote: As I said in the meeting let's just deprecate it. Upgrade methods as follows: 1) YUM Doing yum upgrades does not automatically handle special cases sometimes needed to upgrade bewteen releases. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Noveau wedge still alive
Happened again this afternoon. At least one proc in the background was still running. The on screen clock had stopped for several minutes. As before, mouse cursor moved but no response to keyboard or mouse clicks. -- Chuck Forsberg WA7KGX N2469R c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc "The High Reliability Software" 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
RE: Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases
As I said in the meeting let's just deprecate it. Upgrade methods as follows: 1) YUM 2) DVD It's just an extra thing to worry about and I know I'm gunna get flamed, however I say we just do away with it or have it perform very minimal tasks so yum can do the upgrade by itself. I remember upgrading from 11->12->13->14 by simply pointing to a new yum repo. So maybe instead of deprecating preupgrade, just gimp it to what it needs to do so yum can do the rest. I really believe that Yum can do this and preupgrade can be deprecated or perform less work while yum can play a bigger role (as it should). Feel free to flame/insult/tell me I'm wrong for whatever reason, just throwing it out there and trying to make life easier. Thanks, Dan -Original Message- From: test-boun...@lists.fedoraproject.org [mailto:test-boun...@lists.fedoraproject.org] On Behalf Of Adam Williamson Sent: Monday, April 09, 2012 7:14 PM To: test@lists.fedoraproject.org Subject: Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases Hey, folks. So, it occurred to me while testing the multiple preupgrade bugs we've hit this cycle that - as I understand the process - there's actually no reason we need to hold Alpha and Beta composes for preupgrade bugs. This is how preupgrade works: it pulls https://mirrors.fedoraproject.org/releases.txt , and that's the list of releases it shows you at the first step. It uses the locations defined in that file to retrieve everything - both the packages it downloads and feeds to anaconda, and the actual anaconda that it uses. releases.txt points out to our mirrors.fedoraproject.org mirror lists, and I'm reliably informed (by nirik) that, for pre-releases, the mirror list points to the development tree - that is, http://fedora.mirror.iweb.ca/development/17/x86_64/os/ , for example. It does not point to the frozen tree of the last 'official' pre-release (of which there is also one on the mirrors - it's at http://fedora.mirror.iweb.ca/releases/test/17-Alpha/ ). Since preupgrade for development releases uses the development tree, this means there's actually no relationship between preupgrade and the Alpha / Beta releases. If you run preupgrade from F16 to F17 right now, it doesn't use the anaconda from Alpha. It doesn't necessarily use whatever anaconda is in the latest Beta RC. What it uses is whatever anaconda was last pushed 'stable' via bodhi. Since we can push a new anaconda stable whenever we want, there's no reason I can see to hold Alpha or Beta composes for preupgrade issues. Putting the anaconda that 'fixes' a preupgrade problem into an Alpha or Beta release doesn't really achieve anything in and of itself. All we have to do is make sure the working anaconda is pushed 'stable' via Bodhi as quickly as possible, whenever the Alpha or Beta release point is. The situation for final releases is a bit different. For final releases, mirrorlist points to the 'frozen' release tree - for e.g. http://fedora.mirror.iweb.ca/releases/16/Fedora/x86_64/os/ . This tree is frozen in time at the state when the release went final. If we push an anaconda update stable for a final release, preupgrade to that final release does *not* use the new anaconda. So if right now we push an update to Fedora 16's anaconda stable, you won't get that anaconda when preupgrading from F15 to F16; you get the one from F16 release time. So for final release, we *do* need to make sure the anaconda in the frozen release package set is working for preupgrade. So, I'm proposing one of two options: 1) Simply bump preupgrade to the Final release criteria 2) Keep preupgrade in the Beta criteria, but treat all preupgrade issues - even those that are in the anaconda package - the way we currently treat blocker issues in livecd-tools or the preupgrade package itself: consider them as not blocking image compose. Rather, we require the maintainer to push out an update before the release date. We could put issues in anaconda that only affect preupgrade into the same category. We had a preliminary discussion about this at today's meeting, and agreed I'd make a formal proposal to the list - this is that proposal. Any concerns, questions, improvement suggestions or corrections are greatly welcomed! Please chip in your thoughts, and votes for 1), 2) or neither of the above. 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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17 vs. Pentium 4
On Mon, 9 Apr 2012, Adam Williamson wrote: On Sun, 2012-04-08 at 17:08 -0500, Michael Hennebry wrote: It's now been moe than a month sicne I started trying to install F16. Grrr. To be honest, I've mostly tuned out this thread because you seem to have become intent on doing it in a very complicated way, which some people have been trying to help you with out of the kindness of their hearts. Please don't take the grr as an indication that I am mad at you or blame you for something. Take it as an indication that seemingly interminal failure is frustrating. I'm pretty sure there must be a less strange and rarely-used way of doing it that would be usable in your situation... If you know what it is, I'm all eyes. I started by burning a minimal F16 install CD. It didn't work. So far anything involving F16 or F17 has crashed my system. -- Michael henne...@web.cs.ndsu.nodak.edu "On Monday, I'm gonna have to tell my kindergarten class, whom I teach not to run with scissors, that my fiance ran me through with a broadsword." -- Lily -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases
Hey, folks. So, it occurred to me while testing the multiple preupgrade bugs we've hit this cycle that - as I understand the process - there's actually no reason we need to hold Alpha and Beta composes for preupgrade bugs. This is how preupgrade works: it pulls https://mirrors.fedoraproject.org/releases.txt , and that's the list of releases it shows you at the first step. It uses the locations defined in that file to retrieve everything - both the packages it downloads and feeds to anaconda, and the actual anaconda that it uses. releases.txt points out to our mirrors.fedoraproject.org mirror lists, and I'm reliably informed (by nirik) that, for pre-releases, the mirror list points to the development tree - that is, http://fedora.mirror.iweb.ca/development/17/x86_64/os/ , for example. It does not point to the frozen tree of the last 'official' pre-release (of which there is also one on the mirrors - it's at http://fedora.mirror.iweb.ca/releases/test/17-Alpha/ ). Since preupgrade for development releases uses the development tree, this means there's actually no relationship between preupgrade and the Alpha / Beta releases. If you run preupgrade from F16 to F17 right now, it doesn't use the anaconda from Alpha. It doesn't necessarily use whatever anaconda is in the latest Beta RC. What it uses is whatever anaconda was last pushed 'stable' via bodhi. Since we can push a new anaconda stable whenever we want, there's no reason I can see to hold Alpha or Beta composes for preupgrade issues. Putting the anaconda that 'fixes' a preupgrade problem into an Alpha or Beta release doesn't really achieve anything in and of itself. All we have to do is make sure the working anaconda is pushed 'stable' via Bodhi as quickly as possible, whenever the Alpha or Beta release point is. The situation for final releases is a bit different. For final releases, mirrorlist points to the 'frozen' release tree - for e.g. http://fedora.mirror.iweb.ca/releases/16/Fedora/x86_64/os/ . This tree is frozen in time at the state when the release went final. If we push an anaconda update stable for a final release, preupgrade to that final release does *not* use the new anaconda. So if right now we push an update to Fedora 16's anaconda stable, you won't get that anaconda when preupgrading from F15 to F16; you get the one from F16 release time. So for final release, we *do* need to make sure the anaconda in the frozen release package set is working for preupgrade. So, I'm proposing one of two options: 1) Simply bump preupgrade to the Final release criteria 2) Keep preupgrade in the Beta criteria, but treat all preupgrade issues - even those that are in the anaconda package - the way we currently treat blocker issues in livecd-tools or the preupgrade package itself: consider them as not blocking image compose. Rather, we require the maintainer to push out an update before the release date. We could put issues in anaconda that only affect preupgrade into the same category. We had a preliminary discussion about this at today's meeting, and agreed I'd make a formal proposal to the list - this is that proposal. Any concerns, questions, improvement suggestions or corrections are greatly welcomed! Please chip in your thoughts, and votes for 1), 2) or neither of the above. 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: [Test-Announce] Fedora 17 Beta Release Candidate 3 (RC3) Available Now!
On Mon, 2012-04-09 at 12:42 +0100, Piscium wrote: > On 9 April 2012 07:21, Adam Williamson wrote: > > > Did you have actual window frames on the dialogs in question? Sometimes > > this can happen when no WM that firstboot can actually work with is > > present on the spin - you just get unmanaged windows. > > As far as I remember there were no frames, but I am not sure. > > I booted into my F17 test partition, ran firstboot as root, and the > window frames were there and I could not reproduce the issue. > > I tried to have a more realistic firstboot experience by editing > /etc/sysconfig/firstboot and removing the line RUN_FIRSTBOOT=NO, but > that did not work, it still went into the login screen. It might have > something to do with systemd. Its firstboot file has a line that says > that type is one shot. Is there a way of tricking systemd into > rerunning firstboot despite being one shot? Or maybe one shot does not > mean what I think it means? One shot doesn't mean what you think it means. firstboot employs a belt-and-braces method of disabling itself - to get it to fire again you have to turn it on twice. =) /etc/sysconfig/firstboot is one place, you found that, but you missed the other: you have to re-enable it as a service. So, in the Systemd Age: systemctl enable firstboot.service that should do the trick. -- 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: F17 vs. Pentium 4
On Sun, 2012-04-08 at 17:08 -0500, Michael Hennebry wrote: > It's now been moe than a month sicne I started trying to install F16. > Grrr. To be honest, I've mostly tuned out this thread because you seem to have become intent on doing it in a very complicated way, which some people have been trying to help you with out of the kindness of their hearts. I'm pretty sure there must be a less strange and rarely-used way of doing it that would be usable in your situation... -- 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: F17 vs. Pentium 4
On Mon, Apr 09, 2012 at 04:22:38PM -0500, Michael Hennebry wrote: > > My next trick should be to fix the need for enforcing=0. > Should triggering an automatic relabeling do that? One of reasons why it is needed. > Why does SELinux need fixing? > Do its rules reference sectors, absolute or relative? No. SELinux looks at labels on files. Your copy targets got labels according to their locations on a system where you were doing a copy (or do not have such labels at all if SELinux was not active at that time). Now you need labels relative to your new root before you can operate with 'enforcing=1'. In general if you are messing with files using anything else than your intended target, or if you were running even for a short moment with SELinux off, then to turn it on you have to fix labels. > I'll definitely need to fix /boot . > The best case scenario is that it gets really cluttered > when I start updating kernels on multiple OSs. With multiple installations on the same machine chainloading "private" bootloaders is likely the cleanest option even if grub2 will raise a hissy fit about putting it on a partition. Shrug! An "old grub" still can be used wherever possible. Michal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17 vs. Pentium 4
On 2012/04/09 16:22 (GMT-0500) Michael Hennebry composed: My next trick should be to fix the need for enforcing=0. Should triggering an automatic relabeling do that? Why does SELinux need fixing? Do its rules reference sectors, absolute or relative? I suggest a thread on a users list on this subject with a matching subject line. I never boot with SELinux enabled on purpose, and know little about SELinux except ways to avoid it. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17 vs. Pentium 4
On Mon, 9 Apr 2012, cornel panceac wrote: this may be of help, too. https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum Indeed it might. It looks hairier than preupgrade, but it avoids anaconda. That might avoid the land mine that causes crashes when I try to do an install. -- Michael henne...@web.cs.ndsu.nodak.edu "On Monday, I'm gonna have to tell my kindergarten class, whom I teach not to run with scissors, that my fiance ran me through with a broadsword." -- Lily -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17 vs. Pentium 4
On Mon, 9 Apr 2012, Felix Miata wrote: On 2012/04/08 17:08 (GMT-0500) Michael Hennebry composed: Felix Miata wrote: On 2012/04/06 15:24 (GMT-0500) Michael Hennebry composed: On Fri, 6 Apr 2012, Felix Miata wrote: How about "cloning" your F15, and upgrading that to F16 with latest fixes with Yum? I made a filesystem in a new partition and copied to it as follows: Booted to what? File copy can't be expected to work satisfactorily if source is running. Source wasn't running. I'm still running F14. F15 was installed primarily to establish that I could. from /media as root: cp -a sata400-3-slash/* sata-400-17 You have far more confidence in the competency of cp than I. Until last week, I'd never cloned a partition except by one of two ways: 1-DFSee (sector by sector); 2-MC, however it manages. Last time I tried MC I ran into trouble that probably was little different from what you just did, so last week I switched to doing file copies via rsync. I was under the impression that rsync was just a convenient version of cp. Is there something that rsync gets right that cp gets wrong? I've read cp vs. rsync theads. From those, rsync would have been much better if the copy had been interrupted for some reason. Fortunately it wasn't. I edited the target's fstab. LABEL=sata400-17/ext3defaults1 1 Here I made a big booboo. I'd forgotten I'd had a separate /var . The result was that the two shared a /var . the fstab& Grub menu post-cloning steps would almost surely result in damage to the F15 source, if not complete destruction, once is upgrade is begun. My first F15 install includes four partitions, one for / , one for /boot and two for swap. The copy uses the same /boot and swap partitions. Oops. See above. I suppose someone with a lot of experience could get away with sharing a /boot partition, but based upon your experiences of the past month I wouldn't expect that group to include you. I would have merged the content of the /boot partition into the /boot directory on the new /. Here are my grub stanzas: title Fedora 15 (2.6.42.12-1.fc15.i686.PAE) sdb17 root (hd1,1) kernel /vmlinuz-2.6.42.12-1.fc15.i686.PAE ro root=/dev/sdb17 initrd /initramfs-2.6.42.12-1.fc15.i686.PAE.img Leaving off some of those cmdline options could be a problem. I'm not familiar with all of them, and so would have included all I don't understand. Me too. I just edited poorly. title Fedora 15 (2.6.42.12-1.fc15.i686.PAE) sdb3 root (hd1,1) kernel /vmlinuz-2.6.42.12-1.fc15.i686.PAE ro root=UUID=ce978949-d044-4020-8001-02454648a64e rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet initrd /initramfs-2.6.42.12-1.fc15.i686.PAE.img I can boot sdb3. sdb17 fails. Here is what I did: Established that I could still boot my first F15, sdb3. Added the options mistakenly removed from kernel line in menu.lst . Made a filesystem in new partition, sdb18, for the new /var . Booted F15 under sdb17, yy. Tried and failed to login. Established that I could still login to my first F15. Tried for a gnome session under the new F15, still no go. Trying to login from a text console gave me permission errors, even for root. Added enforcing=0 to the kernel line. Booted and logged in to the new F15, yy. My next trick should be to fix the need for enforcing=0. Should triggering an automatic relabeling do that? Why does SELinux need fixing? Do its rules reference sectors, absolute or relative? Any ideas? 1-Do it again with rsync or a program designed specifically for cloning. 2-Merge /boot partition into the new /. 3-Either find out if any of those cmdline options can play a part in the problem and put back the ones you don't know you don't need, or add them all back except rhgb & quiet 4-Add option enforcing=0 to cmdline to ensure SELinux isn't in the way 5-Use the Grub on hd1,1 to start both, but for the clone include a hd1,16 configfile stanza until you get it booted, then install Grub on sdb17 and afterward chainload from hd1,1 to hd1,16, where updates will ultimately be applied to grub.conf only for the clone on account of new kernels. I'll definitely need to fix /boot . The best case scenario is that it gets really cluttered when I start updating kernels on multiple OSs. -- Michael henne...@web.cs.ndsu.nodak.edu "On Monday, I'm gonna have to tell my kindergarten class, whom I teach not to run with scissors, that my fiance ran me through with a broadsword." -- Lily -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: is the name ok
On Sun, 08 Apr 2012 23:27:31 -0700, AW (Adam) wrote: > Speaking entirely personally, I'm firmly in the 'ditch the stupid > release names, they serve no purpose' camp. Oh so true. ;) I favour the more liberal approach. If there are people (read: resources) who handle the entire release name process without obligation and treat it like fun-stuff, fine. However, it seems to me the process becomes more and more a waste of resources in general. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: is the name ok
On Fri, Apr 6, 2012 at 7:24 PM, george2 wrote: > There is no release criterion in the Testing/QA group for the release name. > Before millions see the latest great work from a multitude of contributors, > should this group pause to reflect if the release name is appropriate for > world wide release. I ask your attention that the name/ logo/ and parody > may offend many and may refuse to use it. I couldn't care less about users refusing to use a release because they feel offended by its codename, they can either grow up, see a doctor or just ignore it -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: size of F17 install DVD
> nonamedotc gmail.com> writes: > > > Could someone please tell me why the install DVD for F17 is smaller > > than > > that for earlier releases. The install DVD is 2.3 GB whereas the > > one for > > F16, for example, is 3.5 GB. Thanks. > > AFAIK no one has completely figured this out yet. I noticed that the > libreoffice-langpack-* packages are on the F16 DVD but not later, and > based on > the average size and number of these that seems to account for about > half of the > size difference. Here are links to package lists (sorted by size in > 1K-blocks) > for the i386 F16 and F17 Alpha TC1 DVDs (the size reduction happened > at Alpha > TC1). > > http://robatino.fedorapeople.org/sizes_Fedora-16-i386-DVD.txt > http://robatino.fedorapeople.org/sizes_Fedora-17-Alpha.TC1-i386-DVD.txt A bit of Python-fu computed following: List of added packages by size: http://fpaste.org/CM9U/ by name: http://fpaste.org/F2v7/ Total 40967 4kB blocks ~ 160 MB. List of removed packages by size: http://fpaste.org/rokW/ by name: http://fpaste.org/iYGp/ Total 322960 4kB blocks ~ 1261 MB. That more or less matches, doesn't it? Most space was saved by stripping translations (KDE, libreoffice), aspell and some fonts. I guess the translations will be downloaded during/after installation... or not? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: is the name ok
On 09/04/12 17:01, Andre Robatino wrote: People seem comfortable referring to "Windows 7". If it has a code name, I don't know it. Maybe it's just relative to other linux distros such as Ubuntu. If it was "Fedora 18.4", a name would be handy. But, personally a name should be kept internal to the planning of FedoraN+1. Personally, newbies email me for "The latest version" -- Regards, Frank "Jack of all, fubars" -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
is the name ok
Jon Stanley gmail.com> writes: > Well, Toshio raised an important point in the above-referenced thread > on advisory-board - just a version number makes Fedora feel cold and > distant to any new user or the press or anything like that. People seem comfortable referring to "Windows 7". If it has a code name, I don't know it. Maybe it's just relative to other linux distros such as Ubuntu. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] Fedora KDE Plasma Workspace Test Day - 2012-04-10
Hi, as Rezza wrote, this Tuesday is Fedora Test Day focused on KDE 4.8. KDE 4.8 Plasma Workspaces is an important desktop environment used by many Fedora users and is part of Fedora KDE spin. It's an excellent alternative to Gnome Shell desktop environment. Please help Fedora project test KDE 4.8 Plasma Workspaces in upcoming Fedora 17 release. Test Day wiki page: https://fedoraproject.org/wiki/Test_Day:2012-04-10_KDE_4.8 Join us at IRC #fedora-test-day on Freenode. Best Regards, Martin Holec Desktop QE, Red Hat Brno - Forwarded Message - From: "Jaroslav Reznik" To: k...@lists.fedoraproject.org Cc: "Martin Holec" Sent: Monday, April 9, 2012 2:04:22 PM Subject: Fedora KDE Plasma Workspace Test Day - 2012-04-10 Hi, there will be Fedora KDE Test Day tomorrow and I hope you will join us to help making our spin better ;-) Yep, we forgot about Easter holidays, but... The Test Day will be held the whole day, we try to cover most timezones (as our presence allows). https://fedoraproject.org/wiki/Test_Day:2012-04-10_KDE_4.8 See you at #fedora-test-day One note: if you're going to use rc3 in kvm, use qxl/spice combination as there's breakage using cirrus/vnc. Jaroslav -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ ___ 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: is the name ok
On 04/09/2012 10:23 PM, Jon Stanley wrote: > Well, Toshio raised an important point in the above-referenced thread > on advisory-board - just a version number makes Fedora feel cold and > distant to any new user or the press or anything like that. The > release name is also used by the design team in coming up with the > theme for the release. > > I'm personally in the "I don't care either way" camp :) I have been on the Fedora mailing lists for *years*. I can never recall someone saying "Hi, I'm new to Fedora and I am just installed $NAME." I can also never recall anyone using $NAME on the mailing lists in any form. Still you see people write FC15 instead of F15...but not $NAME. I feel $NAME is useless for users. -- Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century. -- Dame Edna Everage -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: is the name ok
On 04/09/2012 02:23 PM, Jon Stanley wrote: Well, Toshio raised an important point in the above-referenced thread on advisory-board - just a version number makes Fedora feel cold and distant to any new user or the press or anything like that. The release name is also used by the design team in coming up with the theme for the release. Well for the design team it probably would be best that we switched to a naming scenario similar to OS-X as in an theme based one. I'm personally in the "I don't care either way" camp:) I'm with let's ditch it altogether side. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: is the name ok
On Mon, Apr 9, 2012 at 2:35 AM, Larry Brower wrote: > As am I :) > > I don't see why just having a version number isn't enough. Well, Toshio raised an important point in the above-referenced thread on advisory-board - just a version number makes Fedora feel cold and distant to any new user or the press or anything like that. The release name is also used by the design team in coming up with the theme for the release. I'm personally in the "I don't care either way" camp :) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Fedora 17 Beta Release Candidate 3 (RC3) Available Now!
On 9 April 2012 07:21, Adam Williamson wrote: > Did you have actual window frames on the dialogs in question? Sometimes > this can happen when no WM that firstboot can actually work with is > present on the spin - you just get unmanaged windows. As far as I remember there were no frames, but I am not sure. I booted into my F17 test partition, ran firstboot as root, and the window frames were there and I could not reproduce the issue. I tried to have a more realistic firstboot experience by editing /etc/sysconfig/firstboot and removing the line RUN_FIRSTBOOT=NO, but that did not work, it still went into the login screen. It might have something to do with systemd. Its firstboot file has a line that says that type is one shot. Is there a way of tricking systemd into rerunning firstboot despite being one shot? Or maybe one shot does not mean what I think it means? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Weird F17 effect: New gdm-3.4.0.1 presents mysql server account on the login screen
On 03/31/2012 12:04 PM, drago01 wrote: > On Fri, Mar 30, 2012 at 11:10 PM, Ray Strode wrote: >> Hi, >> >>> on gdm? why not filtering out by defaul the famous non-human users, >>> like >>> mysql and postgresql? >> We could do that, but it's not a very scalable or upstream friendly answer >> (since different upstreams might have different account names for these >> users). > > The current situation isn't a user friendly answer though. So we > should do something about it. If the short term fix is a hardcoded > list so be it. Another short-term hack might be filtering out all users with UID < 500. This would make it possible to display human users that have UID between 500 and 1000 and at the same time, filter out statically assigned non-human users, e.g. mysql with UID 27. -- Kalev -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Weird F17 effect: New gdm-3.4.0.1 presents mysql server account on the login screen
On Mon, Apr 2, 2012 at 3:53 PM, Matthias Clasen wrote: > On Sat, 2012-03-31 at 12:26 -0500, Bruno Wolff III wrote: >> On Sat, Mar 31, 2012 at 18:40:46 +0200, >> Joachim Backes wrote: >> >On 03/31/2012 05:17 PM, Bruno Wolff III wrote: >> >> I found the code used. It is in the accountsservices package, not gdm as >> >> expected. >> >> >> >> There is a list of excluded users and any users with a shell that has >> >> a basename of false or "nologin" are also excepted. >> >> >> >> The list of excluded users is currently: >> >> bin, root, daemon, adm, lp, sync, shutdown, halt, mail, news, uucp, >> >> operator, >> >> nobody, nobody4, noaccess, postgres, pvm, rpm, nfsnobody, pcap >> > >> >Hi Bruno, >> > >> >thanks for your clarification. So my proposal: why not extend this hard >> >coded list by a second (dynamic) one administratable by the fedora admin? >> >> I think you can as there was code to add more logins to the list. I think >> it uses dconf keys to do it, which are a bit of a pain to set, especially >> for gdm instead of the current user. > > No, gdm doesn't currently do its own filtering on top, except for > excluding 'gdm' and uid 0. Discussion seem to have stalled ... what are we going to do about this? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17 vs. Pentium 4
this may be of help, too. https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
