Re: Full, current F18 tree to rsync?
On Thu, 25 Oct 2012 21:56:35 -0400 Cole Robinson crobi...@redhat.com wrote: Hi all, I regularly pull down the F18 tree from the rsync equivalent of: http://download.fedoraproject.org/pub/fedora/linux/development/18/x86_64/os/ note that download.fedoraproject.org is a redirect that gets you a mirror from mirrormanager. So, it will vary from run to run. Up until recently this was a full install tree, including the images/ subdir. This makes it easy to use the tree for PXE (like using cobbler import) or URL installs in virt-manager. Now, though, current trees only have Packages/ repodata/ and drpms/ subdirs. (occasionally accessing that URL dumps me at a mirror with a full install tree, but it was last synced on October 16 so obviously Is the change intentional? If so, why? And is there some place to still rsync a full install tree? It's been broken the last few days. See: https://fedorahosted.org/rel-eng/ticket/5377 The previous issue was fixed, but something further is going on now... kevin signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 at-spi* deps
On 25/10/12 22:49, Adam Jackson wrote: On Thu, 2012-10-25 at 22:21 +0100, Frank Murphy wrote: I agree, but I don't need it, Wheres the script to turn if off? Everone else has to figure that out themselves. accessibilty.conf has no on=0\false switch. If the F18 install I just did is any indication, the state it ships in is as off as it gets. - ajax So you agree, it's unneccessary. For me to need at-spi*. Point made. -- Regards, Frank Jack of all, fubars -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Installation Matrix Template - new Anaconda related changes
The list I'd come up with so far looks like this: 1. autopart empty disk 2. autopart existing empty space 3. autopart wipe entire disk 4. autopart alongside existing 5. autopart shrink 6. autopart multidisk so for 1) you feed it an entirely empty disk and let it autopart into it, with as little user input as possible. for 2) you feed it a disk with data but also enough empty space for an install and let it autopart (with the expectation it'll use the empty space and keep whatever was already on the disk accessible). for 3) you feed it a full disk and use 'guided partitioning' to delete all the existing partitions. for 4) you feed it a disk with two OS installs (or an OS install plus a data partition or something), wipe one of the OSes (or the data partition) with guided partitioning, and let it autopart into the empty space. 5) is a full disk with Fedora or Windows on it, shrink the existing OS partition and install into that space. 6) is feed it two empty disks and see what it does. There's more beyond that, but this was the basic approach I came up with. WDYT? -- Adam Williamson Cool, this seems to be more sensible, than warping the current testcases. Today, I'll try to review the rest of the testcases and send an email similar to the first one, so we can all have a look at it. Then (if it won't be done yet) I'll draft the new partitioning testcases, based on your description. J. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 Criterions/Testcases interconnection
Well I see your point, but it kind of cuts both ways - Josef clearly got confused by a few cases where we overload test cases to test several different things, so you can argue that it's actually more 'accessible' when we try to stick to 'one test case tests one thing'. But your approach would achieve what we need to achieve indeed. /me feels a bit ashamed :D I'm all for 'one test case tests one thing', even though I understand, that having several 'similar' testcases which differ in just few words is nonsense (as I got equally confused with the _almost the same_ criterions in alpha/beta). J. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 Criterions/Testcases interconnection
- Original Message - From: Kamil Paral kpa...@redhat.com No, this is a game of spot five differences :-) At least one versus all virtual consoles. This can be part of the same test case, marked as Alpha/Beta OK, I'll update the summary page/matrix accordingly. Also I'll try to highlight this at least one/all difference on the criteria page. J. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Fri, Oct 26, 2012 at 1:24 AM, Robyn Bergeron rberg...@redhat.com wrote: I am under the impression that we've been testing with/without LVM anyway, both scenarios? In any case, it doesn't seem as earthshaking as other developments - it's just making the default be what it's been for some time, and given that there exists documentation for the lvm enabled case and not much otherwise it seems like a reasonable thing to do. I would almost make the case that disabling LVM by default - were it a feature - would require a lot of that backup documentation and info that isn't really there Which documentation? FS directly on a partition has way more documentation then anything else ... it is what the rest of the world is using. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion proposal: security
On 10/25/2012 09:16 PM, Adam Williamson wrote: Sure, that's the reason for the potential distinction between bugs that _can_ be fixed with updates and those that_can't_. This discussion was prompted by a specific bug - https://bugzilla.redhat.com/show_bug.cgi?id=868519 - which can't be fixed with an update, because it's an issue in anaconda. Just like any bug in anaconda, we can't fix it with a post-release update. For the first we could fix this with an post-release update but as you know certain people did not want that even if there was sufficient man power that was willing to maintain and do that from the community ( fedora-unity ) it although I agree with vincent in c14 this is not a bug as I read it this is working as they intend it... C3... This is working as we intend it. C5... kickstart does not allow for expressing encrypted passphrases, and we have no plans to add that. From my pov they simply should not store the password line et all. The bottom line is we already have an policy with regards to security updates which worst case scenario would be pulled in with an post-release 0 day update and security updates they themselves can bring a plethora of brokenness with them just like any other bug. To give you an example install of an another security issue we have been knowingly shipping for years off the dvd install sshd is enabled by default exposing it to bruteforce attacks immediately out of the box ( how long to think it's going to take with an cloud and if the host is on edubandwith ) while having no means of notifying the end user when it's happening. We allow that! Anaconda developers can always make the case since the file is owned and readable by root that the end user has an bigger issue to deal with if someone can access it ( classic case of security theater )... So now you want to create/tighten a security criteria because of an political debate with the maintainers and this hits what are we supposed to do if upstream does not provide security fixes for a particular release as I mentioned before. In the end of the day in the release process we need to treat security bugs as NTH as in we pull them if a) we know about b) it does not break anything c) cant be fixed with an 0 day update instead of delaying the release indefinitely ( best effort approach )... Personally I dont think we should have security release criteria to complicated the release process and that Anaconda implementation debate should be address by FESCO after all they exist for that exact purpose and they are the once that approved the newUI feature even when it was no way ready ( and still is not ) so they just get to eat their own dog food. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On 10/26/2012 02:53 AM, Adam Williamson wrote: The general understanding among Storage People is that we're aiming to go to btrfs by default for F19. Finally. That's one of the arguments against changing the default_now_, for one release (or possibly two), only to change it again shortly. Where did they get that F19 will be default to BTRFS? Have they just decided that for FESCO and the project in whole? And last time I spoke with Josef he mentioned ( which admittedly was a while back ) that it probably would not be properly ready until F20 JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Fri, Oct 26, 2012 at 6:23 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 10/26/2012 02:53 AM, Adam Williamson wrote: The general understanding among Storage People is that we're aiming to go to btrfs by default for F19. Finally. That's one of the arguments against changing the default_now_, for one release (or possibly two), only to change it again shortly. Where did they get that F19 will be default to BTRFS? He said aiming. Have they just decided that for FESCO and the project in whole? Nothing has been decided. I would expect these Storage People to go through the Feature process like everyone else. Calm down. josh -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: More experiences with F18
On 10/25/12 23:42, Chuck Forsberg WA7KGX N2469R wrote: While waiting for a more functional Anaconda I have been running 64 bit F18 with yum updates. The Noveau driver still crashes. Fortunately Nvidia still installs. I am able to run SCO Openserver 5.0.7 under the virtual machine. Select i686, pcnet, and 4.4bsd. Audacity puts its data in the root segment by default. This eventually overflows the small root FS generated by Anaconda. Hmm, I wonder if they've made changes in upstream nouveau. I'm running rawhide and have not experienced any crashes of nouveau (although I have other issues with nouveau, just not crashing) and *can't* get the nvidia driver to install (either from rpmfusion or from nvidia directly; it doesn't build from the akmod, there is no kmod package for my kernel, and the nvidia .run file won't build (I've sent a request to nvidia for help after doing some debugging)). It appears that the nvidia builder script doesn't take into account include files that have been moved to uapi and/or generated/uapi (why must something that's working be messed with all of the time?). Kevin -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 at-spi* deps
Frank Murphy frankl...@gmail.com wrote on Fri, 26 Oct 2012 08:33:25 +0100: So you agree, it's unneccessary. For me to need at-spi*. Point made. I think the point was at-spi is part of GTK, but this part is not something it is reasonable to package separately, such as a language package or some esoteric locale. The default GTK configuration does not activate Assistive Technology features, therefore they do not intrude on a user like you. Indeed, you do not need at-spi. However, some other users can benefit from AT capabilities, and they are available to those users with appropriate GTK configuration. I am confident it is technically possible to create two GTK versions - one with AT and one without. This would make possible all of the usual additional complications and costs two versions of a large application can create, compared to a single version. Bad idea. It should also be possible to make at-spi a separately installed package, but I expect the GTK developers decided the cost of tests to determine whether at-spi was installed was significantly larger than the cost to include at-spi in the GTK core. Why, then, is at-spi a separate package at all? If it were quietly incorporated into other GTK packages, you might be more comfortable. I suggest the separate at-spi package makes it easier to enhance and test these Assistive Technologies, without a need to rebuild/replace the entire GTK system. If you want GTK, I think your only reasonable course is to accept AT (and not enable it - the default condition that most users prefer). If you really have no interest in GTK (and any of the applications that require it) - I think there are a good number of server or dedicated system instances that meet this condition - you can consider some minimal, focused Fedora installation optimized for your situation. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Full, current F18 tree to rsync?
Cole Robinson (crobi...@redhat.com) said: Up until recently this was a full install tree, including the images/ subdir. This makes it easy to use the tree for PXE (like using cobbler import) or URL installs in virt-manager. Now, though, current trees only have Packages/ repodata/ and drpms/ subdirs. (occasionally accessing that URL dumps me at a mirror with a full install tree, but it was last synced on October 16 so obviously Is the change intentional? If so, why? And is there some place to still rsync a full install tree? It's been broken the last few days. See: https://fedorahosted.org/rel-eng/ticket/5377 The previous issue was fixed, but something further is going on now... Thanks for the link. I only assumed it wasn't temp brokenness since rawhide trees similarly lack images/: http://mirror.steadfast.net/fedora/development/rawhide/x86_64/os/ Anyone know why that is? any recommendations if I want to try pxe booting/URL VM install of rawhide anaconda after F18 GA? It has been intentional that rawhide doesn't produce images, because (at least in the past), it wasn't even remotely expected to work, so it would generally cause a lot of bug reports where the response is 'yes, it's broken, we'll get to that later'. So image generation is turned off in rawhide. If people want it turned back on, we can do so; it's a script change. Obviosly doesn't mean they'll magically start working. Bill -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F18/Rawhide, kdm: wrong keyboard layout
Hi, I've been noticing this since at least September (but reboot really rarely, so I always forgot to mention the problem...). My keyboard layout of choice is swiss german, and the layout is such everywhere except at the kdm login screen. I've got vconsole.keymap=sg in the grub command line, KEYTABLE=sg MODEL=pc105 LAYOUT=ch VARIANT=de in /etc/sysconfig/keyboard, and an empty xorg.conf. AFAICT /etc/kde/kdm/* do not contain any layout related settings. I see this both on rawhide and F18 KDE, and I seem to remember that I also noticed it on F18 Alpha Gnome before I wrecked the virtual machine. Anyone else noticing this / any idea how to fix? Thanks, Sandro -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Full, current F18 tree to rsync?
On 10/26/2012 10:20 AM, Bill Nottingham wrote: Cole Robinson (crobi...@redhat.com) said: Up until recently this was a full install tree, including the images/ subdir. This makes it easy to use the tree for PXE (like using cobbler import) or URL installs in virt-manager. Now, though, current trees only have Packages/ repodata/ and drpms/ subdirs. (occasionally accessing that URL dumps me at a mirror with a full install tree, but it was last synced on October 16 so obviously Is the change intentional? If so, why? And is there some place to still rsync a full install tree? It's been broken the last few days. See: https://fedorahosted.org/rel-eng/ticket/5377 The previous issue was fixed, but something further is going on now... Thanks for the link. I only assumed it wasn't temp brokenness since rawhide trees similarly lack images/: http://mirror.steadfast.net/fedora/development/rawhide/x86_64/os/ Anyone know why that is? any recommendations if I want to try pxe booting/URL VM install of rawhide anaconda after F18 GA? It has been intentional that rawhide doesn't produce images, because (at least in the past), it wasn't even remotely expected to work, so it would generally cause a lot of bug reports where the response is 'yes, it's broken, we'll get to that later'. So image generation is turned off in rawhide. If people want it turned back on, we can do so; it's a script change. Obviosly doesn't mean they'll magically start working. Nah, given that it was turned off deliberately it sounds like it should stay that way. I was just curious. Thanks, Cole -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18/Rawhide, kdm: wrong keyboard layout
On Fri, 26 Oct 2012 16:34:54 +0200 Sandro Mani manisan...@gmail.com wrote: Hi, I've been noticing this since at least September (but reboot really rarely, so I always forgot to mention the problem...). My keyboard layout of choice is swiss german, and the layout is such everywhere except at the kdm login screen. I've got vconsole.keymap=sg in the grub command line, KEYTABLE=sg MODEL=pc105 LAYOUT=ch VARIANT=de in /etc/sysconfig/keyboard, and an empty xorg.conf. AFAICT /etc/kde/kdm/* do not contain any layout related settings. I see this both on rawhide and F18 KDE, and I seem to remember that I also noticed it on F18 Alpha Gnome before I wrecked the virtual machine. Anyone else noticing this / any idea how to fix? Seeing it alos on F18\Rawhide with Xfce, and LightDM or Lxdm No idea of permanent fix. -layout gb, Lightdm login -layout us. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 at-spi* deps
On 26/10/12 14:59, Richard Ryniker wrote: Frank Murphy frankl...@gmail.com wrote on Fri, 26 Oct 2012 08:33:25 +0100: So you agree, it's unneccessary. For me to need at-spi*. Point made. I think the point was at-spi is part of GTK, but this part is not something it is reasonable to package separately, It was packaged seperatly in F=17 such as a language package or some esoteric locale. Bleachbit takes care of that. The default GTK configuration does not activate Assistive Technology features, How to permamently disable with chattr +1, if required. I am confident it is technically possible to create two GTK versions - one with AT and one without. This would make possible all of the usual additional complications and costs two versions of a large application can create, compared to a single version. Bad idea. Can see the point there. It should also be possible to make at-spi a separately installed package, but I expect the GTK developers decided the cost of tests to determine whether at-spi was installed was significantly larger than the cost to include at-spi in the GTK core. It was in f17. Why, then, is at-spi a separate package at all? If it were quietly incorporated into other GTK packages, you might be more comfortable. I suggest the separate at-spi package makes it easier to enhance and test these Assistive Technologies, without a need to rebuild/replace the entire GTK system. If you want GTK, I think your only reasonable course is to accept AT (and not enable it - the default condition that most users prefer). No problem with it per say, except where end-user permanently disable it. If you really have no interest in GTK (and any of the applications that require it) - I think there are a good number of server or dedicated system instances that meet this condition - I'm not using Gnome, but with cross deps it sneaks in. you can consider some minimal, focused Fedora installation optimized for your situation. Hence the op. -- Regards, Frank Jack of all, fubars -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: More experiences with F18
On 10/26/2012 06:21 AM, Kevin Martin wrote: On 10/25/12 23:42, Chuck Forsberg WA7KGX N2469R wrote: While waiting for a more functional Anaconda I have been running 64 bit F18 with yum updates. The Noveau driver still crashes. Fortunately Nvidia still installs. I am able to run SCO Openserver 5.0.7 under the virtual machine. Select i686, pcnet, and 4.4bsd. Audacity puts its data in the root segment by default. This eventually overflows the small root FS generated by Anaconda. Hmm, I wonder if they've made changes in upstream nouveau. I'm running rawhide and have not experienced any crashes of nouveau (although I have other issues with nouveau, just not crashing) and *can't* get the nvidia driver to install (either from rpmfusion or from nvidia directly; it doesn't build from the akmod, there is no kmod package for my kernel, and the nvidia .run file won't build (I've sent a request to nvidia for help after doing some debugging)). It appears that the nvidia builder script doesn't take into account include files that have been moved to uapi and/or generated/uapi (why must something that's working be messed with all of the time?). Kevin I am using NVIDIA-Linux-x86_64-304.60.run 1. Change rhgb quiet to nomodeset in the active grub.cfg entry 2. Reboot 3. init 3 4. sh NV* As I keyboard this, I am running Xfce with composting on. Random screensavers are enabled. WSPR is running with one sound card and a real serial port. Lady Heather is running under Wine using a USB serial port to talk to a Trimble Thunderbolt. Ham Radio Deluxe's rotator control under Wine interrogates a rotator 1/sec using the other USB serial port. Audacity has been recording sound using the motherboard sound device for 21 hours. I have also been playing with SCO Openserver 5.0.7 under the virtual machine manager. Also have been using VNC, Firefox to talk to the world. The system has not crashed using the Nvidia driver. Knock on wood. -- 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: F18 at-spi* deps
On 26/10/12 16:31, Adam Jackson wrote: If the F18 install I just did is any indication, the state it ships in is as off as it gets. So you agree, it's unneccessary. What a dishonest thing to say. I'd appreciate it if you didn't put words in my mouth, thanks. - ajax Is it necessary for me or is it not? Better -- Regards, Frank Jack of all, fubars -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18/Rawhide, kdm: wrong keyboard layout
On Fri, 26 Oct 2012 15:14:12 + Jóhann B. Guðmundsson johan...@gmail.com wrote: Anyone else noticing this / any idea how to fix? Thanks, Sandro http://www.freedesktop.org/software/systemd/man/vconsole.conf.html Doesn't fix it for me. kemap=uk, can be both wrong and right. It does appear to be an X problem on my rawhide. With on runlevel 3 login: user password works fine. (keymap, UK) startx in Term | is now a , and other also switch (keymap, UK) It is only when setxkbmap -rules evdev -layout gb -model pc105 -variant extd is run, that | is once again |. On this physical keyboard | is above \, next to shift-L. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18/Rawhide, kdm: wrong keyboard layout
I haven't tried the vconsole thing yet (can't log out right now), but also in my case the problem _only_ appears at the login screen. Everywhere else, including on VTs, the layout is correct. On Fri, Oct 26, 2012 at 6:00 PM, Frank Murphy frankl...@gmail.com wrote: On Fri, 26 Oct 2012 15:14:12 + Jóhann B. Guðmundsson johan...@gmail.com wrote: Anyone else noticing this / any idea how to fix? Thanks, Sandro http://www.freedesktop.org/software/systemd/man/vconsole.conf.html Doesn't fix it for me. kemap=uk, can be both wrong and right. It does appear to be an X problem on my rawhide. With on runlevel 3 login: user password works fine. (keymap, UK) startx in Term | is now a , and other also switch (keymap, UK) It is only when setxkbmap -rules evdev -layout gb -model pc105 -variant extd is run, that | is once again |. On this physical keyboard | is above \, next to shift-L. -- 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: More experiences with F18
On 10/26/12 10:44, Chuck Forsberg WA7KGX N2469R wrote: On 10/26/2012 06:21 AM, Kevin Martin wrote: On 10/25/12 23:42, Chuck Forsberg WA7KGX N2469R wrote: While waiting for a more functional Anaconda I have been running 64 bit F18 with yum updates. The Noveau driver still crashes. Fortunately Nvidia still installs. I am able to run SCO Openserver 5.0.7 under the virtual machine. Select i686, pcnet, and 4.4bsd. Audacity puts its data in the root segment by default. This eventually overflows the small root FS generated by Anaconda. Hmm, I wonder if they've made changes in upstream nouveau. I'm running rawhide and have not experienced any crashes of nouveau (although I have other issues with nouveau, just not crashing) and *can't* get the nvidia driver to install (either from rpmfusion or from nvidia directly; it doesn't build from the akmod, there is no kmod package for my kernel, and the nvidia .run file won't build (I've sent a request to nvidia for help after doing some debugging)). It appears that the nvidia builder script doesn't take into account include files that have been moved to uapi and/or generated/uapi (why must something that's working be messed with all of the time?). Kevin I am using NVIDIA-Linux-x86_64-304.60.run 1. Change rhgb quiet to nomodeset in the active grub.cfg entry 2. Reboot 3. init 3 4. sh NV* As I keyboard this, I am running Xfce with composting on. Random screensavers are enabled. WSPR is running with one sound card and a real serial port. Lady Heather is running under Wine using a USB serial port to talk to a Trimble Thunderbolt. Ham Radio Deluxe's rotator control under Wine interrogates a rotator 1/sec using the other USB serial port. Audacity has been recording sound using the motherboard sound device for 21 hours. I have also been playing with SCO Openserver 5.0.7 under the virtual machine manager. Also have been using VNC, Firefox to talk to the world. The system has not crashed using the Nvidia driver. Knock on wood. Which kernel are you running? I can't get 304.60 to build on 3.7.0-0.rc2.git1.2.fc19.x86_64 (rawhide). It can't figure out the kernel version so it won't even try to build. Kevin -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: More experiences with F18
On 10/26/2012 09:22 AM, Kevin Martin wrote: On 10/26/12 10:44, Chuck Forsberg WA7KGX N2469R wrote: On 10/26/2012 06:21 AM, Kevin Martin wrote: On 10/25/12 23:42, Chuck Forsberg WA7KGX N2469R wrote: While waiting for a more functional Anaconda I have been running 64 bit F18 with yum updates. The Noveau driver still crashes. Fortunately Nvidia still installs. I am able to run SCO Openserver 5.0.7 under the virtual machine. Select i686, pcnet, and 4.4bsd. Audacity puts its data in the root segment by default. This eventually overflows the small root FS generated by Anaconda. Hmm, I wonder if they've made changes in upstream nouveau. I'm running rawhide and have not experienced any crashes of nouveau (although I have other issues with nouveau, just not crashing) and *can't* get the nvidia driver to install (either from rpmfusion or from nvidia directly; it doesn't build from the akmod, there is no kmod package for my kernel, and the nvidia .run file won't build (I've sent a request to nvidia for help after doing some debugging)). It appears that the nvidia builder script doesn't take into account include files that have been moved to uapi and/or generated/uapi (why must something that's working be messed with all of the time?). Kevin I am using NVIDIA-Linux-x86_64-304.60.run 1. Change rhgb quiet to nomodeset in the active grub.cfg entry 2. Reboot 3. init 3 4. sh NV* As I keyboard this, I am running Xfce with composting on. Random screensavers are enabled. WSPR is running with one sound card and a real serial port. Lady Heather is running under Wine using a USB serial port to talk to a Trimble Thunderbolt. Ham Radio Deluxe's rotator control under Wine interrogates a rotator 1/sec using the other USB serial port. Audacity has been recording sound using the motherboard sound device for 21 hours. I have also been playing with SCO Openserver 5.0.7 under the virtual machine manager. Also have been using VNC, Firefox to talk to the world. The system has not crashed using the Nvidia driver. Knock on wood. Which kernel are you running? I can't get 304.60 to build on 3.7.0-0.rc2.git1.2.fc19.x86_64 (rawhide). It can't figure out the kernel version so it won't even try to build. Kevin uname -a Linux omen3.omen.com 3.6.3-3.fc18.x86_64 #1 SMP Tue Oct 23 14:55:06 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux [caf@omen3 X11]$ ll N* -rw-r--r-- 1 root root 64146553 Oct 25 03:47 NVIDIA-Linux-x86_64-304.60.run Yum update is current. -- 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: More experiences with F18
On Fri, 26 Oct 2012 11:22:32 -0500 Kevin Martin ktm...@gmail.com wrote: Which kernel are you running? I can't get 304.60 to build on 3.7.0-0.rc2.git1.2.fc19.x86_64 (rawhide). It can't figure out the kernel version so it won't even try to build. Kevin Chuck is running F18, may be what's different. -- Regards, Frank -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: More experiences with F18
On 10/26/12 11:25, Chuck Forsberg WA7KGX N2469R wrote: On 10/26/2012 09:22 AM, Kevin Martin wrote: On 10/26/12 10:44, Chuck Forsberg WA7KGX N2469R wrote: On 10/26/2012 06:21 AM, Kevin Martin wrote: On 10/25/12 23:42, Chuck Forsberg WA7KGX N2469R wrote: While waiting for a more functional Anaconda I have been running 64 bit F18 with yum updates. The Noveau driver still crashes. Fortunately Nvidia still installs. I am able to run SCO Openserver 5.0.7 under the virtual machine. Select i686, pcnet, and 4.4bsd. Audacity puts its data in the root segment by default. This eventually overflows the small root FS generated by Anaconda. Hmm, I wonder if they've made changes in upstream nouveau. I'm running rawhide and have not experienced any crashes of nouveau (although I have other issues with nouveau, just not crashing) and *can't* get the nvidia driver to install (either from rpmfusion or from nvidia directly; it doesn't build from the akmod, there is no kmod package for my kernel, and the nvidia .run file won't build (I've sent a request to nvidia for help after doing some debugging)). It appears that the nvidia builder script doesn't take into account include files that have been moved to uapi and/or generated/uapi (why must something that's working be messed with all of the time?). Kevin I am using NVIDIA-Linux-x86_64-304.60.run 1. Change rhgb quiet to nomodeset in the active grub.cfg entry 2. Reboot 3. init 3 4. sh NV* As I keyboard this, I am running Xfce with composting on. Random screensavers are enabled. WSPR is running with one sound card and a real serial port. Lady Heather is running under Wine using a USB serial port to talk to a Trimble Thunderbolt. Ham Radio Deluxe's rotator control under Wine interrogates a rotator 1/sec using the other USB serial port. Audacity has been recording sound using the motherboard sound device for 21 hours. I have also been playing with SCO Openserver 5.0.7 under the virtual machine manager. Also have been using VNC, Firefox to talk to the world. The system has not crashed using the Nvidia driver. Knock on wood. Which kernel are you running? I can't get 304.60 to build on 3.7.0-0.rc2.git1.2.fc19.x86_64 (rawhide). It can't figure out the kernel version so it won't even try to build. Kevin uname -a Linux omen3.omen.com 3.6.3-3.fc18.x86_64 #1 SMP Tue Oct 23 14:55:06 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux [caf@omen3 X11]$ ll N* -rw-r--r-- 1 root root 64146553 Oct 25 03:47 NVIDIA-Linux-x86_64-304.60.run Yum update is current. I think between 3.6 and 3.7 there was a change of where some of the kernel source include files are held (from /usr/src/kernels/`uname -r`/include to /usr/src/kernels/`uname -r`/include/uapi and /usr/src/kernels/`uname -r`/include/generated/uapi) that is screwing up building of the nvidia drivers (for example, in 3.7, the version.h file found under include/linux is empty and has been moved to include//generated/uapi/linux but the nvidia-installer sript run by the .run script doesn't find that version (either at all or early enough to be able to use it). Kevin -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F18 Beta Smoke 12 Available
I've built a new smoke test image with: - btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18 - firstboot-18.4-1.fc18 - lorax-18.21-1.fc18.x86_64.rpm - pykickstart-1.99.21-1.fc18 - python-meh-0.18-1.fc18 http://dl.fedoraproject.org/pub/alt/qa/18/20121025_f18b-smoke12/ I've done a few quick installs with it and it seems to work for autopart gnome installs. Anyhow, more testing and appropriate karma for the included builds would be much appreciated. Happy testing, Tim signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 Beta Smoke 12 Available
On Fri, 2012-10-26 at 11:49 -0600, Tim Flink wrote: I've built a new smoke test image with: - btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18 - firstboot-18.4-1.fc18 Did you really use 18.4 or 18.5? We should be going with 18.5 I think. -- 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: F18 Beta Smoke 12 Available
On Fri, Oct 26, 2012 at 11:49 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2012-10-26 at 11:49 -0600, Tim Flink wrote: I've built a new smoke test image with: - btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18 - firstboot-18.4-1.fc18 Did you really use 18.4 or 18.5? We should be going with 18.5 I think. yeah 18.4-1 is obsolete 18.5-1 is in testing -- 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 -- Akshay vyas (http://www.gofedora.in) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion proposal: security
On Fri, 2012-10-26 at 09:35 +, Jóhann B. Guðmundsson wrote: On 10/25/2012 09:16 PM, Adam Williamson wrote: Sure, that's the reason for the potential distinction between bugs that _can_ be fixed with updates and those that_can't_. This discussion was prompted by a specific bug - https://bugzilla.redhat.com/show_bug.cgi?id=868519 - which can't be fixed with an update, because it's an issue in anaconda. Just like any bug in anaconda, we can't fix it with a post-release update. For the first we could fix this with an post-release update but as you know certain people did not want that even if there was sufficient man power that was willing to maintain and do that from the community ( fedora-unity ) You're derailing again. The fact is that we don't release official updates of the install images and therefore bugs in the install path cannot be fixed via updates. If this changes then obviously we could consider changes to the release criteria and validation process, but right now, it's a *fact*: we do not release installer updates, therefore we have to maintain the distinction between bugs that can be fixed with updates and bugs that cannot. Discussion of whether we _ought_ to release updated installer images is fine and good, but it should be separate from this. it although I agree with vincent in c14 this is not a bug as I read it this is working as they intend it... C3... This is working as we intend it. C5... kickstart does not allow for expressing encrypted passphrases, and we have no plans to add that. From my pov they simply should not store the password line et all. The bottom line is we already have an policy with regards to security updates which worst case scenario would be pulled in with an post-release 0 day update and security updates they themselves can bring a plethora of brokenness with them just like any other bug. I don't think it really needs reiterating, but again, it is inarguably the case that it is possible for there to be security issues we cannot fix with updates. All code is potentially vulnerable to security issues, we ship code that cannot be changed by our update process, ergo there is a possibility of security issues we cannot fix with updates. QED. Specific examples of this are just examples. To give you an example install of an another security issue we have been knowingly shipping for years off the dvd install sshd is enabled by default exposing it to bruteforce attacks immediately out of the box ( how long to think it's going to take with an cloud and if the host is on edubandwith ) while having no means of notifying the end user when it's happening. We allow that! Again I don't really see the relevance to this debate. That has been discussed before and it's been decided that it does not constitute a security bug in Fedora as it's an intentional configuration choice where we made the tradeoff between convenience and security in the direction of security. Whenever you're building something as complex as a distribution there will be occasions where you have to decide between convenience and security; when these are properly considered and the decision is made on the side of convenience, that does not constitute a security bug. Even if you want to reanimate the question of whether this particular decision is correct, it really doesn't impact on the question of whether we should consider security bugs as blocker bugs in some circumstances, so far as I can see. It's just yet another tangent. Anaconda developers can always make the case since the file is owned and readable by root that the end user has an bigger issue to deal with if someone can access it ( classic case of security theater )... So now you want to create/tighten a security criteria because of an political debate with the maintainers and this hits what are we supposed to do if upstream does not provide security fixes for a particular release as I mentioned before. No, I think you're misrepresenting things there. There is a debate about whether this is actually a 'bug' or not, which really just means it's another case of what I mentioned above: we're considering an issue and deciding the trade-off between security and convenience. I am not proposing this criterion with the intent that, if it's accepted, I will post to the bug 'HAHA we just added a security criterion therefore this is a blocker bug and you can't argue!'. That's not the idea at all. Whether we decide to take security bugs as release blockers or not does not answer the question of _whether this is considered a 'bug' or not at all'. That would still be up for debate. But, theoretically speaking, if we were to accept that this was a security bug, then under the proposed criteria it may count as a blocker bug. Without any criteria it definitely wouldn't. I was proposing the criterion not because I want to use it as a stick to beat anaconda with, but simply because I wanted
Re: F18 Beta Smoke 12 Available
On Fri, 26 Oct 2012 11:19:10 -0700 Adam Williamson awill...@redhat.com wrote: On Fri, 2012-10-26 at 11:49 -0600, Tim Flink wrote: I've built a new smoke test image with: - btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18 - firstboot-18.4-1.fc18 Did you really use 18.4 or 18.5? We should be going with 18.5 I think. Yes, I used 18.4. For some reason, I thought that it fixed a blocker/nth bug but going back, I can't figure out which bug. I should have just used 18.3 in stable. 18.5 doesn't fix anything that's beta blocker/nth (it does fix proposed blockers for final) and it's not in stable. Since we're in beta freeze, I didn't want to pull in anything from testing that isn't going to be pushed to stable before beta release. Tim signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion proposal: security
On 10/26/2012 07:14 PM, Adam Williamson wrote: I wanted to raise the question of whether it makes sense in general to hold our releases for some security bugs. Right now we have no capacity to do that. I dont think that should be for us to decide. When we encounter potential security issue in the development release cycle we should just forward those issue to the security team to determine if that's the case and let's assume it is then *they* would contact fesco which in turn decides if the release should be *delayed* or not until that security issue has been addressed. Given that these issue are few and far in between I dont think it warrants an specific criteria surrounding it but should rather be dealt on a case by case bases. The security community exists for this exact purpose so let's just let them handle that. They are expert in what they do... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion proposal: security
On Fri, 2012-10-26 at 19:33 +, Jóhann B. Guðmundsson wrote: On 10/26/2012 07:14 PM, Adam Williamson wrote: I wanted to raise the question of whether it makes sense in general to hold our releases for some security bugs. Right now we have no capacity to do that. I dont think that should be for us to decide. When we encounter potential security issue in the development release cycle we should just forward those issue to the security team to determine if that's the case and let's assume it is then *they* would contact fesco which in turn decides if the release should be *delayed* or not until that security issue has been addressed. Given that these issue are few and far in between I dont think it warrants an specific criteria surrounding it but should rather be dealt on a case by case bases. Oh, and in case this helps, I wasn't planning on adding a test case which says 'go test the entire distribution for security issues', or anything. The idea was just that this would be a criterion we would 'hold in reserve' to use when security issues were elevated to our attention. So really it just provides a mechanism for us to take a security issue that someone has raised that really seems to be a problem, and give it blocker status. I think with the feedback we've seen so far that we can say the original proposal was substantially too broad, so how about this as a revised proposal - for now, we just add a single Final release criterion which reads: The release must contain no known security issues of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation) ? How does that sound to everyone? It drops the issue entirely for Alpha and Beta, and means we only consider bad issues that cannot be fixed with an update for Final. -- 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: Criterion proposal: security
On 10/26/2012 07:44 PM, Adam Williamson wrote: The release must contain no known security issues of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation) ? How does that sound to everyone? It drops the issue entirely for Alpha and Beta, and means we only consider bad issues that cannot be fixed with an update for Final. -- Ack -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion proposal: security
On Fri, Oct 26, 2012 at 12:44:24 -0700, Adam Williamson awill...@redhat.com wrote: ? How does that sound to everyone? It drops the issue entirely for Alpha and Beta, and means we only consider bad issues that cannot be fixed with an update for Final. That sounds reasonable. For alpha and beta we could still warn people if appropriate using common bugs. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion proposal: security
On Fri, 2012-10-26 at 12:44 -0700, Adam Williamson wrote: I think with the feedback we've seen so far that we can say the original proposal was substantially too broad, so how about this as a revised proposal - for now, we just add a single Final release criterion which reads: The release must contain no known security issues of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation) ? How does that sound to everyone? It drops the issue entirely for Alpha and Beta, and means we only consider bad issues that cannot be fixed with an update for Final. Hmm, actually, let's change 'issues' to 'bugs' there, I think that makes it clearer that we're talking about things that have actually been accepted as bugs - it avoids any suggestion we'd be wading into the debate about what actually constitutes a security issue, as Johann was concerned about. So: The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation) with the understanding that QA would never use this to wade into something like the sshd question and declare that it was a Bug That Must Be Fixed. It applies only to things that are clearly agreed to be actual bugs. -- 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: F18 Beta Smoke 12 Available
On Fri, 2012-10-26 at 13:27 -0600, Tim Flink wrote: On Fri, 26 Oct 2012 11:19:10 -0700 Adam Williamson awill...@redhat.com wrote: On Fri, 2012-10-26 at 11:49 -0600, Tim Flink wrote: I've built a new smoke test image with: - btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18 - firstboot-18.4-1.fc18 Did you really use 18.4 or 18.5? We should be going with 18.5 I think. Yes, I used 18.4. For some reason, I thought that it fixed a blocker/nth bug but going back, I can't figure out which bug. I should have just used 18.3 in stable. No, 18.4 is right, it does include a fix we want: https://bugzilla.redhat.com/show_bug.cgi?id=856194 . 18.3 did not enforce the creation of an admin user in appropriate cases, it just changed the defaults. 18.4 actually forces you to create an admin user when the root account is locked. 18.5 doesn't fix anything that's beta blocker/nth (it does fix proposed blockers for final) and it's not in stable. Since we're in beta freeze, I didn't want to pull in anything from testing that isn't going to be pushed to stable before beta release. Kinda true, but it obsoleted 18.4 before the freeze went into place and 18.4 was never pushed stable, so it replaces 18.4 as the fix for https://bugzilla.redhat.com/show_bug.cgi?id=856194 , effectively. We could use releng privileges to push 18.4 stable and leave 18.5 out, I guess, if we really wanted to. -- 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: Criterion proposal: security
On Fri, 2012-10-26 at 19:33 +, Jóhann B. Guðmundsson wrote: On 10/26/2012 07:14 PM, Adam Williamson wrote: I wanted to raise the question of whether it makes sense in general to hold our releases for some security bugs. Right now we have no capacity to do that. I dont think that should be for us to decide. When we encounter potential security issue in the development release cycle we should just forward those issue to the security team to determine if that's the case and let's assume it is then *they* would contact fesco which in turn decides if the release should be *delayed* or not until that security issue has been addressed. Given that these issue are few and far in between I dont think it warrants an specific criteria surrounding it but should rather be dealt on a case by case bases. The security community exists for this exact purpose so let's just let them handle that. They are expert in what they do... Well, Vincent seemed to think it would be good to handle this as a matter of policy via the blocker process and not case-by-case by FESCo. I don't think it's quite like the feature process case where we say 'feature issues go to FESCo not through the blocker process', because the feature process is a Thing that Exists and is owned by FESCo. We don't _have_ a security bug process at present, really. At least so far as blocking releases is concerned. Anything introduced at this point would be an invention, whether it goes via FESCo or the release validation process. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] LVM autopart testing
Hey, folks. So the Big LVM Autopart Controversy has been kicked upstairs to FESCo: https://fedorahosted.org/fesco/ticket/964 If they say 'go with LVM', we'll have to do that. I have no idea what FESCo will decide, but we should cover our bets either way, I think, so it will do no harm to do some testing of the LVM autopart stuff over the weekend rather than wait till after FESCo makes up its mind. So, for those doing validation testing, if you could run a few test installs with LVM autopart and make sure everything's okay that'd be great. There's nowhere formal to report results - just yell on the list if you find a bug that doesn't affect ext4 autopart. I have a couple of updates.imgs available: http://adamwill.fedorapeople.org/updates-lvm.img against 18.19 (TC6) http://adamwill.fedorapeople.org/updates-lvm-1821.img against 18.21 (smoke12, possibly TC7) The first is for anaconda 18.19 - what's in TC6. The second is for anaconda 18.21 - what's in smoke12 and would possibly be in TC7. If more anaconda builds show up, I'll provide updates.img for them following the same name scheme. All you really have to do to test is use these updates.imgs and do a regular old autopart install. Two things should happen - the install shouldn't explode (unless you hit some unrelated bug, of course) and you should get LVs for your system partitions (not /boot) by default, just as you did with F17 and earlier. If you hit a problem, do test *without* the updates.img too before pulling the fire alarm, just in case it's not anything to do with the LVM change. You can also test autopart-within-custom-partitioning if you like. The button in custom part that says something like 'create partitions automatically'. It should also give you LVM-based partitioning with this patch. (It does for me, I checked). Thanks everyone! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ 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: [Test-Announce] LVM autopart testing
On Fri, 2012-10-26 at 14:06 -0700, Adam Williamson wrote: Hey, folks. So the Big LVM Autopart Controversy has been kicked upstairs to FESCo: https://fedorahosted.org/fesco/ticket/964 If they say 'go with LVM', we'll have to do that. I have no idea what FESCo will decide, but we should cover our bets either way, I think, so it will do no harm to do some testing of the LVM autopart stuff over the weekend rather than wait till after FESCo makes up its mind. So, for those doing validation testing, if you could run a few test installs with LVM autopart and make sure everything's okay that'd be great. There's nowhere formal to report results - just yell on the list if you find a bug that doesn't affect ext4 autopart. I have a couple of updates.imgs available: http://adamwill.fedorapeople.org/updates-lvm.img against 18.19 (TC6) http://adamwill.fedorapeople.org/updates-lvm-1821.img against 18.21 (smoke12, possibly TC7) The first is for anaconda 18.19 - what's in TC6. The second is for anaconda 18.21 - what's in smoke12 and would possibly be in TC7. If more anaconda builds show up, I'll provide updates.img for them following the same name scheme. All you really have to do to test is use these updates.imgs and do a regular old autopart install. Two things should happen - the install shouldn't explode (unless you hit some unrelated bug, of course) and you should get LVs for your system partitions (not /boot) by default, just as you did with F17 and earlier. If you hit a problem, do test *without* the updates.img too before pulling the fire alarm, just in case it's not anything to do with the LVM change. You can also test autopart-within-custom-partitioning if you like. The button in custom part that says something like 'create partitions automatically'. It should also give you LVM-based partitioning with this patch. (It does for me, I checked). Thanks everyone! Johann pointed out I forgot to include a link to the page with instructions on how to use updates images. For anyone who doesn't know, here it is: https://fedoraproject.org/wiki/Anaconda/Updates sorry for leaving this out! The short version is you just add 'updates=(URL)' to the boot parameters for the installer, so at the boot menu screen you hit 'Tab' to edit the boot parameters, add 'updates=http://adamwill.fedorapeople.org/updates-lvm.img' or 'updates=http://adamwill.fedorapeople.org/updates-lvm-1821.img' , and then hit enter and proceed with install as normal. You do need networking to be working 'out of the box' for this to work - so a wired DHCP connection, basically. -- 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: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Fri, 2012-10-26 at 10:23 +, Jóhann B. Guðmundsson wrote: On 10/26/2012 02:53 AM, Adam Williamson wrote: The general understanding among Storage People is that we're aiming to go to btrfs by default for F19. Finally. That's one of the arguments against changing the default_now_, for one release (or possibly two), only to change it again shortly. Where did they get that F19 will be default to BTRFS? Have they just decided that for FESCO and the project in whole? And last time I spoke with Josef he mentioned ( which admittedly was a while back ) that it probably would not be properly ready until F20 No-one's decided anything, it's just the latest goal they're aiming for. It'll go through the feature process as always. -- 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: F18/Rawhide, kdm: wrong keyboard layout
On Fri, 2012-10-26 at 18:16 +0200, Sandro Mani wrote: I haven't tried the vconsole thing yet (can't log out right now), but also in my case the problem _only_ appears at the login screen. Everywhere else, including on VTs, the layout is correct. It sounds like the console layout is correct and your desktop (KDE or whatever) also has the correct layout configured for your user, so I think what's missing is the systemwide X11 layout. Johann, where does that get set? -- 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: F18 Beta Smoke 12 Available
On 10/26/2012 07:49 PM, Tim Flink wrote: I've built a new smoke test image with: - btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18 - firstboot-18.4-1.fc18 - lorax-18.21-1.fc18.x86_64.rpm - pykickstart-1.99.21-1.fc18 - python-meh-0.18-1.fc18 http://dl.fedoraproject.org/pub/alt/qa/18/20121025_f18b-smoke12/ I've done a few quick installs with it and it seems to work for autopart gnome installs. Anyhow, more testing and appropriate karma for the included builds would be much appreciated. Selecting an installation source is somewhat difficult. Since it defaults to closest mirror it cannot work until the network is properly configured however once I did that it didn't try again to download the metadata. So I went in there, made sure that closest mirror is selected and clicked done. Nothing. So I went in again selected http and then closest mirror again followed by done. Nothing. Then I tried http = done and when I go back in closest mirror is set again. Finally I went all the way and set http with an actual (bogus) ip address and clicked done. Now I got an error (which was expected). After now going back in and selecting closest mirror again Anaconda finally could be convinced to try and download the meta data again which this time succeeded. Regards, Dennis -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 Beta Smoke 12 Available
On Sat, 2012-10-27 at 00:14 +0200, Dennis Jacobfeuerborn wrote: On 10/26/2012 07:49 PM, Tim Flink wrote: I've built a new smoke test image with: - btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18 - firstboot-18.4-1.fc18 - lorax-18.21-1.fc18.x86_64.rpm - pykickstart-1.99.21-1.fc18 - python-meh-0.18-1.fc18 http://dl.fedoraproject.org/pub/alt/qa/18/20121025_f18b-smoke12/ I've done a few quick installs with it and it seems to work for autopart gnome installs. Anyhow, more testing and appropriate karma for the included builds would be much appreciated. Selecting an installation source is somewhat difficult. Since it defaults to closest mirror it cannot work until the network is properly configured however once I did that it didn't try again to download the metadata. So I went in there, made sure that closest mirror is selected and clicked done. Nothing. So I went in again selected http and then closest mirror again followed by done. Nothing. Then I tried http = done and when I go back in closest mirror is set again. Finally I went all the way and set http with an actual (bogus) ip address and clicked done. Now I got an error (which was expected). After now going back in and selecting closest mirror again Anaconda finally could be convinced to try and download the meta data again which this time succeeded. Network configuration has been so fragile up till now I'm not sure we've actually done much testing on setups where the network actually *needs* configuring. So it sounds plausible that anaconda just isn't smart enough to notice when the network goes up and re-do the metadata stuff yet. Could you file a bug on this and nominate it as NTH (mark it as blocking F18Beta-accepted) , or if you don't have the power to do that, post the URL here so someone else can do it? 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: F18 Beta Smoke 12 Available
On 10/27/2012 12:14 AM, Dennis Jacobfeuerborn wrote: On 10/26/2012 07:49 PM, Tim Flink wrote: I've built a new smoke test image with: - btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18 - firstboot-18.4-1.fc18 - lorax-18.21-1.fc18.x86_64.rpm - pykickstart-1.99.21-1.fc18 - python-meh-0.18-1.fc18 http://dl.fedoraproject.org/pub/alt/qa/18/20121025_f18b-smoke12/ I've done a few quick installs with it and it seems to work for autopart gnome installs. Anyhow, more testing and appropriate karma for the included builds would be much appreciated. Selecting an installation source is somewhat difficult. Since it defaults to closest mirror it cannot work until the network is properly configured however once I did that it didn't try again to download the metadata. So I went in there, made sure that closest mirror is selected and clicked done. Nothing. So I went in again selected http and then closest mirror again followed by done. Nothing. Then I tried http = done and when I go back in closest mirror is set again. Finally I went all the way and set http with an actual (bogus) ip address and clicked done. Now I got an error (which was expected). After now going back in and selecting closest mirror again Anaconda finally could be convinced to try and download the meta data again which this time succeeded. After that Anaconda spends a while in the Preparing transaction from installation source it shows a fatal error Could not run transaction. In the following output i see an error that the package pcmciautils-018-3.fc18.x86_64 nees 719MB on the / filesystem. This is in a KVM guest with an autopartitioned 5G disk. 719MB seems quite excessive for the pcmciautils package? Regards, Dennis -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 Beta Smoke 12 Available
On 10/27/2012 12:22 AM, Adam Williamson wrote: On Sat, 2012-10-27 at 00:14 +0200, Dennis Jacobfeuerborn wrote: On 10/26/2012 07:49 PM, Tim Flink wrote: I've built a new smoke test image with: - btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18 - firstboot-18.4-1.fc18 - lorax-18.21-1.fc18.x86_64.rpm - pykickstart-1.99.21-1.fc18 - python-meh-0.18-1.fc18 http://dl.fedoraproject.org/pub/alt/qa/18/20121025_f18b-smoke12/ I've done a few quick installs with it and it seems to work for autopart gnome installs. Anyhow, more testing and appropriate karma for the included builds would be much appreciated. Selecting an installation source is somewhat difficult. Since it defaults to closest mirror it cannot work until the network is properly configured however once I did that it didn't try again to download the metadata. So I went in there, made sure that closest mirror is selected and clicked done. Nothing. So I went in again selected http and then closest mirror again followed by done. Nothing. Then I tried http = done and when I go back in closest mirror is set again. Finally I went all the way and set http with an actual (bogus) ip address and clicked done. Now I got an error (which was expected). After now going back in and selecting closest mirror again Anaconda finally could be convinced to try and download the meta data again which this time succeeded. Network configuration has been so fragile up till now I'm not sure we've actually done much testing on setups where the network actually *needs* configuring. So it sounds plausible that anaconda just isn't smart enough to notice when the network goes up and re-do the metadata stuff yet. Could you file a bug on this and nominate it as NTH (mark it as blocking F18Beta-accepted) , or if you don't have the power to do that, post the URL here so someone else can do it? Thanks! Filed and marked as blocking F18Beta-accepted: https://bugzilla.redhat.com/show_bug.cgi?id=870570 Regards, Dennis -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
HEADS UP several very old sysconfig files are being deprecated
Just a bit of heads up about the recent changes taking place in systemd ( 195 ) for F18+... The following sysconfig files are being deprecated /etc/sysconfig/clock, /etc/sysconfig/i18n,/etc/sysconfig/keyboard, /etc/sysconfig/network ( Hostname only ) These changes should be transparent ( they are migrated to systemd native files ) but various applications might still using the deprecated files so be on the look out and report any bug you come across. Ofcourse the fastest way to detect such breakage and to have it fixed, along with avoiding users confusion would be simply to delete those files... So here's the break down... * **/etc/sysconfig/clock has been replaced by /etc/localtime * The time zone is now configured by creating an appropriate /etc/localtime symlink to the relevant timezone. To list available timezone run the following command # timedatectl list-timezone To set timezone run the following command ( If you live in Iceland like I do ) # timedatectl set-timezone Atlantic/Reykjavik Systemd uses UTC for the hardware clock by default however I recommend people setup and use ntp To set the system clock directly run # set-time 2012-10-27 01:02:03 I highly recommend against setting the hardware clock to localtime but because I know some of you guys are dual booting with windows and to lazy to fix the registry here's how you set the hardware clock to use localtime instead.. # timedatectl set-local-rtc 1 To set configure the clock to use network time protocol start by configuring ntp then enable the service # systemctl enable ntpd.service And run # timedatectl set-ntp 1 And finally to see the current setting run # timedatectl status I think I have cover most uses case so see man timedatectl and man localtime to explore it further.. * **/etc/sysconfig/i18n has been replaced by /etc/locale.conf * LANG + All LC_* variables found in /etc/sysconfig/i18n as in LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= LC_MEASUREMENT= LC_IDENTIFICATION= belong in /etc/locale.conf The locale settings configured in here are system-wide and are inherited by every service or user, unless overridden or unset by individual programs or individual users. See man locale.conf for further details */etc/sysconfig/keyboard has been change to **/etc/vconsole.conf * The virtual console configuration is /etc/vconsole.conf /* *//*NOTE THAT THE VARIABLES BEING USED HAVE CHANGED*/ SYSFONT= becomes FONT= SYSFONTACM= becomes FONT_MAP= UNIMAP= becomes FONT_UNIMAP= KEYTABLE= becomes KEYMAP= Kernel keymap and fonts is the default being used if FONT= or KEYMAP= are not set or empty * **/etc/sysconfig/network ( hostname only ) to /etc/hostname * There are now three distinguished hostnames in use.. The pretty a.k.a the high level one as in my laptop The static hostname a.k.a kernel hostname at boot ( the one that got migrated usually fqdn of the host The transient hostname ( temporary network hostname like dhcp-foo ) To set the pretty one run # hostnamectl set-hostname name --pretty To set the static one run # hostnamectl set-hostname name --static To set the transient one run # hostnamectl set-hostname name --transient To set the same hostname for all three run # hostnamectl set-hostname fqdn To see the hostname settings run # hostnamectl status See man hostname and man hostnamectl for further details. I think that's about it for the most part so keep watching out for those bugs JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: HEADS UP several very old sysconfig files are being deprecated
On Oct 26, 2012 7:27 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Just a bit of heads up about the recent changes taking place in systemd ( 195 ) for F18+... (snip) https://admin.fedoraproject.org/mailman/listinfo/test Thanks for the writeup, Jóhann. There's a lot of good info here. Do you mind if I drop this into the F18 release notes, verbatim? It would really help, as we're getting close to freezing for translation. --pete -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: HEADS UP several very old sysconfig files are being deprecated
On 10/27/2012 01:43 AM, Pete Travis wrote: On Oct 26, 2012 7:27 PM, Jóhann B. Guðmundsson johan...@gmail.com mailto:johan...@gmail.com wrote: Just a bit of heads up about the recent changes taking place in systemd ( 195 ) for F18+... (snip) https://admin.fedoraproject.org/mailman/listinfo/test Thanks for the writeup, Jóhann. There's a lot of good info here. Do you mind if I drop this into the F18 release notes, verbatim? It would really help, as we're getting close to freezing for translation. Yeah sure clean up my English and put it in there I'm going to see if I cant wikify this and bunch of other additional useful information ( although not change in current behavior just add on bits ) that came with the 194 JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: HEADS UP several very old sysconfig files are being deprecated
On Sat, 2012-10-27 at 01:24 +, Jóhann B. Guðmundsson wrote: I highly recommend against setting the hardware clock to localtime but because I know some of you guys are dual booting with windows and to lazy to fix the registry here's how you set the hardware clock to use localtime instead.. # timedatectl set-local-rtc 1 This all looks good, especially keeping this. It isn't just coexistence with Windows that makes it a good idea to put local time into the CMOS clock. If you want to wake up a machine in the morning it is a lot simpler to do with local time in the clock, otherwise you either have it waking up an hour early half the year or manually twiddle twice a year. Complete shutdown saves even more electricity than suspend and is less error prone on the typical desktop. Which adds up if you have a lot of desktops. I only have a few dozen but every dollar that isn't wasted helps. 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: HEADS UP several very old sysconfig files are being deprecated
On Oct 26, 2012 8:01 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 10/27/2012 01:43 AM, Pete Travis wrote: On Oct 26, 2012 7:27 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Just a bit of heads up about the recent changes taking place in systemd ( 195 ) for F18+... (snip) https://admin.fedoraproject.org/mailman/listinfo/test Thanks for the writeup, Jóhann. There's a lot of good info here. Do you mind if I drop this into the F18 release notes, verbatim? It would really help, as we're getting close to freezing for translation. Yeah sure clean up my English and put it in there I'm going to see if I cant wikify this and bunch of other additional useful information ( although not change in current behavior just add on bits ) that came with the 194 JBG -- Thanks! Should I let it be for now, if you're revising further and putting it on the wiki somewhere? I'll be working on the release notes on and off over the weekend, so feel free to shout at me by email or as 'randomuser' on freenode and we will make sure it gets included. --pete -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
