Re: Criterion revision proposal: KDE default applications
On Sun, 2013-12-15 at 17:47 +1300, Gavin Flower wrote: > I don't know... > > Possibly charge a lot of money, give out fancy certificates, and ensure > they have status and no real responsibilities! oh, I like it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On 15/12/13 17:41, Adam Williamson wrote: On Sat, 2013-12-14 at 22:27 -0500, Richard Ryniker wrote: Has Fedora QA discussed how much effort they should or can invest in organization and facilitation of others' test activities? Direct testing scales (approximately) linearly with number of people, but education, organization, and leadership has the potential to scale at greater multiples. |---| | Great opportunity! Become a Fedora test franchisee. We'll provide | | directions, training, and all the materials you need, so you too can | | participate in this fast-moving field. Gain experience, recruit | | others, become a Test Manager and train new Testers. With 10 or | | more Testers, select your own Test Managers (each of whom will direct | | at least five Testers) and advance to the Test Director level. With | | five Test Managers, become a Test Executive...| |---| It's a cute idea, but I'm firmly of the opinion that stuff like this just doesn't _work_ in a project like Fedora. It's a cliche that geeks and engineers aren't huge fans of 'bureaucracy' and 'management', and this is pure management - drawing up a nice little hierarchical org chart and giving people job titles. Does the Test Executive get a corner office and a nice chair? :) I kid, but you get the point. I don't know of a F/OSS project which has a strict pyramid structure and cutesy job titles like this, and that's for a reason: the whole "F/OSS is a meritocracy / F/OSS is a do-ocracy" thing has its own problem of bias and so on, but it is a _fairly_ accurate reflection of how F/OSS work actually happens in one respect: it's mostly the case that the work is done by the people who show up, and there usually isn't some kind of obvious hierarchy like you describe. I mean, we don't have Test Executives and Test Directors and Testers inside the QA group, so why would we expect it to work for other groups to do it? The general idea of trying to get other groups more involved in testing their own stuff is obviously a good one, but I don't think that's the right approach to achieve it :) I don't know... Possibly charge a lot of money, give out fancy certificates, and ensure they have status and no real responsibilities! Cheers, Gavin -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Sat, 2013-12-14 at 22:27 -0500, Richard Ryniker wrote: > Has Fedora QA discussed how much effort they should or can invest in > organization and facilitation of others' test activities? Direct > testing scales (approximately) linearly with number of people, but > education, organization, and leadership has the potential to scale at > greater multiples. > > |---| > | Great opportunity! Become a Fedora test franchisee. We'll provide | > | directions, training, and all the materials you need, so you too can | > | participate in this fast-moving field. Gain experience, recruit | > | others, become a Test Manager and train new Testers. With 10 or | > | more Testers, select your own Test Managers (each of whom will direct | > | at least five Testers) and advance to the Test Director level. With | > | five Test Managers, become a Test Executive...| > |---| It's a cute idea, but I'm firmly of the opinion that stuff like this just doesn't _work_ in a project like Fedora. It's a cliche that geeks and engineers aren't huge fans of 'bureaucracy' and 'management', and this is pure management - drawing up a nice little hierarchical org chart and giving people job titles. Does the Test Executive get a corner office and a nice chair? :) I kid, but you get the point. I don't know of a F/OSS project which has a strict pyramid structure and cutesy job titles like this, and that's for a reason: the whole "F/OSS is a meritocracy / F/OSS is a do-ocracy" thing has its own problem of bias and so on, but it is a _fairly_ accurate reflection of how F/OSS work actually happens in one respect: it's mostly the case that the work is done by the people who show up, and there usually isn't some kind of obvious hierarchy like you describe. I mean, we don't have Test Executives and Test Directors and Testers inside the QA group, so why would we expect it to work for other groups to do it? The general idea of trying to get other groups more involved in testing their own stuff is obviously a good one, but I don't think that's the right approach to achieve it :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
On 12/14/2013 06:20 PM, Kevin Fenzi wrote: Also, from re-reading the info in this thread, in addition to the xfce4-terminal bug, it sounds like perhaps recently all gnome based stuff isn't saving at all? (liferea, gnome-terminal, etc) I wonder if something changed recently in gtk3 session saving... will try and look into it. I am observing - some seem to be restored on the last active workspace (e.g. ghex, gedit, rhythmbox, totem) - some seem to be restored correctly (e.g. gnome-calculator) - gnome-terminals do not get restored. Other apps, which do not get restored: vlc, projectx. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fedora 20 updates-testing report
The following Fedora 20 Security updates need testing: Age URL 58 https://admin.fedoraproject.org/updates/FEDORA-2013-19198/quassel-0.9.1-1.fc20 50 https://admin.fedoraproject.org/updates/FEDORA-2013-19934/openstack-glance-2013.2-2.fc20 45 https://admin.fedoraproject.org/updates/FEDORA-2013-19507/openstack-keystone-2013.2-2.fc20 20 https://admin.fedoraproject.org/updates/FEDORA-2013-22042/varnish-3.0.4-2.fc20 18 https://admin.fedoraproject.org/updates/FEDORA-2013-22130/chicken-4.8.0.5-1.fc20 12 https://admin.fedoraproject.org/updates/FEDORA-2013-22575/subversion-1.8.5-2.fc20 10 https://admin.fedoraproject.org/updates/FEDORA-2013-22713/hdapsd-20090401.20131204git401ca60-1.fc20 9 https://admin.fedoraproject.org/updates/FEDORA-2013-22809/net-snmp-5.7.2-16.fc20 8 https://admin.fedoraproject.org/updates/FEDORA-2013-22832/ufraw-0.19.2-10.fc20 8 https://admin.fedoraproject.org/updates/FEDORA-2013-22854/dcraw-9.19-4.fc20 6 https://admin.fedoraproject.org/updates/FEDORA-2013-22983/munin-2.0.18-2.fc20 6 https://admin.fedoraproject.org/updates/FEDORA-2013-22968/munin-2.0.19-1.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2013-23034/rubygem-i18n-0.6.4-3.fc20 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23116/python-swiftclient-1.8.0-1.fc20 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23177/samba-4.1.3-2.fc20 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23197/ack-2.12-1.fc20 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23164/php-5.5.7-1.fc20 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23192/devscripts-2.13.5-2.fc20 2 https://admin.fedoraproject.org/updates/FEDORA-2013-23251/xen-4.3.1-6.fc20 2 https://admin.fedoraproject.org/updates/FEDORA-2013-23260/libgadu-1.12.0-0.2.rc1.fc20 2 https://admin.fedoraproject.org/updates/FEDORA-2013-23250/libreswan-3.7-1.fc20 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23339/openttd-1.3.3-1.fc20 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23361/v8-3.14.5.10-3.fc20 The following Fedora 20 Critical Path updates have yet to be approved: Age URL 69 https://admin.fedoraproject.org/updates/FEDORA-2013-18447/createrepo-0.9.9-23.fc20 32 https://admin.fedoraproject.org/updates/FEDORA-2013-21163/libproxy-0.4.11-8.fc20 13 https://admin.fedoraproject.org/updates/FEDORA-2013-22527/libbluray-0.4.0-2.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2013-23052/iso-codes-3.49-1.fc20 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23100/sqlite-3.8.2-1.fc20 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23111/python-setuptools-1.4.2-1.fc20 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23099/qtwebkit-2.3.3-2.fc20 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23168/colord-1.1.5-1.fc20 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23177/samba-4.1.3-2.fc20 2 https://admin.fedoraproject.org/updates/FEDORA-2013-23240/mash-0.6.02-1.fc20 2 https://admin.fedoraproject.org/updates/FEDORA-2013-23243/libfm-1.1.4-1.fc20 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23324/bluez-5.12-2.fc20 The following builds have been pushed to Fedora 20 updates-testing globus-gram-job-manager-slurm-1.2-2.fc20 inn-2.5.3-14.fc20 libburn-1.3.4-1.fc20 libisoburn-1.3.4-1.fc20 libisofs-1.3.4-1.fc20 libmemcached-1.0.16-2.fc20 mspdebug-0.22-1.fc20 nodejs-mbtiles-0.4.1-1.fc20 nodejs-tilejson-0.6.1-2.fc20 nodejs-xmlbuilder-1.1.2-1.fc20 perl-ExtUtils-CChecker-0.09-1.fc20 zukitwo-20131210-1.fc20 Details about builds: globus-gram-job-manager-slurm-1.2-2.fc20 (FEDORA-2013-23430) Globus Toolkit - SLURM Job Manager Support Update Information: New package from Globus Toolkit 5.2.5. References: [ 1 ] Bug #1028165 - Review Request: globus-gram-job-manager-slurm - Globus Toolkit - SLURM Job Manager Support https://bugzilla.redhat.com/show_bug.cgi?id=1028165 inn-2.5.3-14.fc20 (FEDORA-2013-23433) The InterNetNews system, an Usenet news server Update Information: Fix an issue with innd-nntpsend.service. ChangeLog: * Sat Dec 14 2013 Jochen Schmitt - 2.5.3-14 - Fix typo in innd-nntpsend.service (#1043126) References: [ 1 ] Bug #1043126 - Installation of INN cau
Fedora 18 updates-testing report
The following Fedora 18 Security updates need testing: Age URL 239 https://admin.fedoraproject.org/updates/FEDORA-2013-6117/eucalyptus-3.2.2-1.fc18 85 https://admin.fedoraproject.org/updates/FEDORA-2013-17195/spice-gtk-0.18-3.fc18 79 https://admin.fedoraproject.org/updates/FEDORA-2013-17635/wireshark-1.10.2-4.fc18 78 https://admin.fedoraproject.org/updates/FEDORA-2013-17853/davfs2-1.4.7-3.fc18 21 https://admin.fedoraproject.org/updates/FEDORA-2013-21875/389-ds-base-1.3.0.9-1.fc18 9 https://admin.fedoraproject.org/updates/FEDORA-2013-22771/gimp-2.8.10-4.fc18 7 https://admin.fedoraproject.org/updates/FEDORA-2013-22949/net-snmp-5.7.2-7.fc18 7 https://admin.fedoraproject.org/updates/FEDORA-2013-22929/dcraw-9.19-4.fc18 7 https://admin.fedoraproject.org/updates/FEDORA-2013-22899/ufraw-0.19.2-10.fc18 6 https://admin.fedoraproject.org/updates/FEDORA-2013-22986/munin-2.0.18-2.fc18 6 https://admin.fedoraproject.org/updates/FEDORA-2013-22993/munin-2.0.19-1.fc18 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23122/firefox-26.0-2.fc18,xulrunner-26.0-1.fc18 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23140/python-setuptools-0.6.49-1.fc18 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23068/rubygem-i18n-0.6.0-2.fc18 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23215/php-5.4.23-1.fc18 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23291/thunderbird-24.2.0-2.fc18 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23299/libreswan-3.7-1.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-23378/openttd-1.3.3-1.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-23401/v8-3.14.5.10-3.fc18 The following Fedora 18 Critical Path updates have yet to be approved: Age URL 308 https://admin.fedoraproject.org/updates/FEDORA-2013-2192/nautilus-3.6.3-5.fc18 13 https://admin.fedoraproject.org/updates/FEDORA-2013-22457/libbluray-0.4.0-2.fc18 7 https://admin.fedoraproject.org/updates/FEDORA-2013-22918/opus-1.1-1.fc18 7 https://admin.fedoraproject.org/updates/FEDORA-2013-22917/colord-1.0.5-1.fc18 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23122/firefox-26.0-2.fc18,xulrunner-26.0-1.fc18 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23140/python-setuptools-0.6.49-1.fc18 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23224/openssh-6.1p1-11.fc18 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23291/thunderbird-24.2.0-2.fc18 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23312/dracut-029-1.fc18.3 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23306/abrt-2.1.10-1.fc18,libreport-2.1.10-1.fc18,satyr-0.12-1.fc18 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23297/libfm-1.1.4-1.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-23381/cryptsetup-1.6.3-1.fc18 The following builds have been pushed to Fedora 18 updates-testing ReviewBoard-1.7.20-1.fc18 certmonger-0.69-1.fc18 cryptsetup-1.6.3-1.fc18 docky-2.2.0-1.fc18 fedora-review-0.5.1-1.fc18 globus-gram-audit-3.2-8.fc18 globus-gram-job-manager-13.53-2.fc18 globus-gram-job-manager-slurm-1.2-2.fc18 globus-scheduler-event-generator-4.7-7.fc18 libburn-1.3.4-1.fc18 libisoburn-1.3.4-1.fc18 libisofs-1.3.4-1.fc18 libuv-0.10.20-1.fc18 nodejs-0.10.23-1.fc18 opensmtpd-5.4.1p1-1.fc18 openttd-1.3.3-1.fc18 php-bartlett-PHP-CompatInfo-2.26.0-1.fc18 pyfits-3.1.3-1.fc18 python-djblets-0.7.27-1.fc18 python-elasticsearch-0.4.3-3.fc18 python-moksha-hub-1.2.2-1.fc18 rpmlint-1.5-6.fc18 rubygem-narray-0.6.0.8-9.fc18 v8-3.14.5.10-3.fc18 Details about builds: ReviewBoard-1.7.20-1.fc18 (FEDORA-2013-23383) Web-based code review tool Update Information: * Thu Dec 12 2013 Stephen Gallagher - 1.7.20-1 - New upstream bugfix release 1.7.20 - http://www.reviewboard.org/docs/releasenotes/reviewboard/1.7.20/ - Web API Changes: * When posting a review request and using submit-as, the given username will now be looked up in the auth backend (LDAP, Active Directory, etc.), instead of just the local database. - Bug Fixes: * Accessing file attachments without review UIs through the API no longer causes an HTTP 500 error. * Fields in the administration UI containing JSON will no longer cause errors during save. Furthermore, the JSON is now valid and properly editable. * Usernames with plus signs are now allowed. - Internal Changes * Rewrote the Mercurial support to use the command line tool. ChangeLog: * Thu Dec 12 2013 Stephen Gallagher - 1.7.20-1 - New upstream bugfix release 1.7.20 - http://www.reviewboard
Re: Criterion revision proposal: KDE default applications
On Sat, 14 Dec 2013, at 11:25:40 -0800 Adam Williamson wrote: One thing they've floated as an idea is to have a separate 'installation environment' you could boot into from the live images - so you could either boot into 'try it out' live mode, or 'install it' installer mode, but not run the installer from within the live mode. That is pretty much what I had in mind. There would be no "live installer". The Fedora stand-alone installation medium would be large enough to have a live system that offered "try" mode, "install" mode (full anaconda, with local repository), and maybe "rescue" mode. The same system image would be used: options built into each choice would direct which mode to execute. I think Ubuntu (or one of its variants) uses a scheme like this, but I do not know if it copies the live image or offers multiple installation variations. It is very crude, but I looked at how many models of USB flash drive Amazon sells directly and see: 512MB & Under 4 1GB39 2GB 176 4GB 378 8GB 518 16GBB 407 32GB & Up 465 Two thirds are models with 8GB or larger capacity. That does not mean this many flash drives sold have that capacity, but such capacity is readily available. There still are many machines that do not boot directly from USB, but that is a condition for which GRUB and friends are made. I cannot quantify how much a single installer for Fedora saves over two (live and multiple-environment). If one installer is adequate, it still may not be worth the disruption caused when the other is dropped. The single installer choice could be made either way. The alternative is only a live installer, which becomes the starting point for subsequent installation by yum of the desired environment(s). if you're interested in making [a limited resource Fedora] happen... I think one of my problems is too much hardware, not too little. Somehow, I seem to have acquired the notion a new release of Fedora justifies a new machine on which to run it. I don't really see a lot of evidence that many other groups test their stuff at all in any particularly organized way There are many reasons this is so. One may be a perception there is a QA group that will do this, therefore little need exists to do first what will be done again. This is not the most important factor, I believe, but a consequence is the more QA does, the more this attitude grows. You become a victim of your own success. Greater clarity about what QA will not test may help. I'll note two design choices in storage which make this problem exponentially harder... Yes. Test the untestable. I do not think those choices are caprice; they allow users, most of whom are no more than casually familiar with Fedora installation, to find a more comfortable path through the installation process, one that permits minimal rework (avoids the "Something is wrong - start over" event) as understanding grows and bad choices are improved. Fedora testers, who usually have an abundance of installation experience, likely do not appreciate the value to less experienced users of this flexibility that makes tests so difficult. for upgrading, we only test upgrading a very clean installation of the previous release Upgrade is a can of worms. Yes, I too am beguiled by how much easier upgrade is than a new installation, and have often chosen upgrade, but something (many somethings!) sooner or later bite. There are just too many initial conditions, and too many distinct ways appropriate for different users to handle these conditions, to make possible an accurate understanding of what results from an upgrade. In lucid moments, I know upgrade should be exorcised, but it just is *so* convenient. Has Fedora QA discussed how much effort they should or can invest in organization and facilitation of others' test activities? Direct testing scales (approximately) linearly with number of people, but education, organization, and leadership has the potential to scale at greater multiples. |---| | Great opportunity! Become a Fedora test franchisee. We'll provide | | directions, training, and all the materials you need, so you too can | | participate in this fast-moving field. Gain experience, recruit | | others, become a Test Manager and train new Testers. With 10 or | | more Testers, select your own Test Managers (each of whom will direct | | at least five Testers) and advance to the Test Director level. With | | five Test Managers, become a Test Executive...| |---| -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: UEFI install on MBR partition scheme, was: Failed attempt to fpaste UEFI failure data
On Dec 14, 2013, at 5:40 PM, Chuck Forsberg WA7KGX wrote: > Concerning Fedora's inability to boot from UEFI and install to > a fdisk configured disk: A relevant error message would have > been most useful. Like I said, I suggest you file an RFE against Rawhid for this message: DEBUG anaconda: info bar clicked: failed to find a suitable stage1 device ((,)) Failed to find a suitable stage1 device *is* the relevant error message, it's just that it's not sufficient plain language for the typical user to know what that means. So I'd be clear in the bug that the actual result is the above message. And the expected result is, "When EFI booted and installation destination is an MBR disk with partitions being retained, flag the user with a plain language explanation: Fedora only supports GPT partition scheme when installing from EFI booted computers." Or something like that, feel free to offer more clear, more concise plain language text that's easy to translate and isn't confusing. Also FYI recent versions of fdisk, I think just with Fedora 20, now has both MBR and GPT support. But it does default to creating MBR (DOS), which by the way Windows and OS X installers definitely will not let you install their systems to when UEFI booted either. UEFI booted systems require GPT in practice. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: UEFI install on MBR partition scheme, was: Failed attempt to fpaste UEFI failure data
On Sat, 2013-12-14 at 16:40 -0800, Chuck Forsberg WA7KGX wrote: > On 12/14/2013 03:22 PM, Chris Murphy wrote: > > On Dec 14, 2013, at 3:29 PM, Adam Williamson wrote: > >> It does not. So it sounds like Chuck's trying to do a UEFI install to an > >> msdos-labelled disk, and that's the problem. > > I think this could use an RFE on the error message to be more clear what > > the problem is. > > > >> Chuck, you can't do a UEFI > >> install to a disk with an msdos disk label (partition table). If you can > >> blow the entire disk away, then choose a partition layout that does so, > >> and anaconda should automatically reformat it to gpt for you. If there > >> is stuff on the disk you can't stand to lose, then you only have the > >> choice of doing a BIOS install of Fedora. > > Or convert from MBR to GPT using gdisk. > > > >> Chris, I'm trying to remember - we were discussing something like this > >> around the time of F19 release, and thinking of changing it. But I can't > >> recall if it was 'EFI system partition must be FAT32' or 'UEFI system > >> must be installed to a gpt-labelled disk' which was the assumption we > >> were questioning. Either way, I'm sure there was an assumption anaconda > >> was making in this area which we'd found not to be entirely true. > > I don't remember. But yes for system partitions it's FAT32, and for > > removable devices it's FAT12 or FAT16. The UEFI spec allows either GPT or > > MBR disks, and there's an EFI System Partition type code for both partition > > schemes. For MBR this is 0xEF and this code is missing from > > libparted/labels/dos.c, and blivet uses pyparted which hooks into > > libparted, I really don't think anaconda is going to use MBR disks on UEFI > > computers. > > > > Chris Murphy > I initialized a scratch disk with parted and was able to boot > netinst under UEFI and install Heisenbug. > > Concerning Fedora's inability to boot from UEFI and install to > a fdisk configured disk: A relevant error message would have > been most useful. > > And mow for the acid test - I plan on initializing a 4 TB disk with > parted and then install Win7 and Heisenbug on it. It's not really reducible to which utility you use. Both fdisk and parted can create ms-dos or gpt disk labels. If you want to pre-create a layout for a UEFI install, just make sure you use a gpt one. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: UEFI install on MBR partition scheme, was: Failed attempt to fpaste UEFI failure data
On 12/14/2013 03:22 PM, Chris Murphy wrote: On Dec 14, 2013, at 3:29 PM, Adam Williamson wrote: It does not. So it sounds like Chuck's trying to do a UEFI install to an msdos-labelled disk, and that's the problem. I think this could use an RFE on the error message to be more clear what the problem is. Chuck, you can't do a UEFI install to a disk with an msdos disk label (partition table). If you can blow the entire disk away, then choose a partition layout that does so, and anaconda should automatically reformat it to gpt for you. If there is stuff on the disk you can't stand to lose, then you only have the choice of doing a BIOS install of Fedora. Or convert from MBR to GPT using gdisk. Chris, I'm trying to remember - we were discussing something like this around the time of F19 release, and thinking of changing it. But I can't recall if it was 'EFI system partition must be FAT32' or 'UEFI system must be installed to a gpt-labelled disk' which was the assumption we were questioning. Either way, I'm sure there was an assumption anaconda was making in this area which we'd found not to be entirely true. I don't remember. But yes for system partitions it's FAT32, and for removable devices it's FAT12 or FAT16. The UEFI spec allows either GPT or MBR disks, and there's an EFI System Partition type code for both partition schemes. For MBR this is 0xEF and this code is missing from libparted/labels/dos.c, and blivet uses pyparted which hooks into libparted, I really don't think anaconda is going to use MBR disks on UEFI computers. Chris Murphy I initialized a scratch disk with parted and was able to boot netinst under UEFI and install Heisenbug. Concerning Fedora's inability to boot from UEFI and install to a fdisk configured disk: A relevant error message would have been most useful. And mow for the acid test - I plan on initializing a 4 TB disk with parted and then install Win7 and Heisenbug on it. -- Chuck Forsberg WA7KGX 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: Is yum groups broken in f20 ?
On Sat, 2013-12-14 at 14:26 -0800, Adam Williamson wrote: > On Wed, 2013-12-11 at 22:35 -0600, Michael Cronenworth wrote: > > On 12/08/2013 08:37 AM, Mateusz Marzantowicz wrote: > > > Curious, why it blew up right now, just before F20 is released. It > > > should have happened in alpha and not now. > > > > > > Workaround is to yum group mark remove for every group > > > on the list. What a waste of time. > > > > Whatever you do - do not run "yum group mark convert". Now one of my > > systems > > wants to install every Fedora package with "yum update". > > > > This affects all Fedoras with yum -120. Here's the parent bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=1014202 > > I've found some time to look into this today, and I do not believe those > two are the same bug. The error looks the same at a quick glance, but it > is not the same and it is not on the same codepath. (yum's code actually > contains about a dozen very similar warning messages produced by > different checks at different points). > > I believe I've identified probably the most common case of this bug > quite precisely. I forgot Piruthiviraj had filed #1039348 , so I filed a > new bug about it, with the details I was able to figure out: > > https://bugzilla.redhat.com/show_bug.cgi?id=1043202 > > I managed to identify the specific change to yum which made these > messages appear, and I think I know the attributes of the groups for > which it appears: non-environment groups that are listed as installed > in /var/lib/yum/groups/installed (also, possibly, through whatever other > mechanisms yum has for listing installed groups; like everyone else, I'm > having a lot of trouble grokking this yum-groups-as-objects thing), that > exist in comps, but have set to false. > > It at least appears the check that was added is being run in > circumstances where it wasn't expected to run. I don't know how many (if OK, I think I got as far as I can with this. I was wrong about some things, above - I was reading /var/lib/yum/groups/installed wrong. It's actually rather simpler than I thought. It's quite simple to reproduce, actually. From a clean F20 install, just try this: # yum group install books (group installed) # yum group install books Loaded plugins: langpacks, refresh-packagekit No packages in any requested group available to install or update # (that's correct) # yum install @books Loaded plugins: langpacks, refresh-packagekit Warning: group books does not exist. Nothing to do (the spurious error appears!) Unless I'm entirely misreading yum's source, even though "group install foo" and "install @foo" are meant to be synonyms, they're implemented in different functions in two different files - and the two aren't even copy/paste, they're implemented quite differently! The bug we're hitting is really just that the function which implements "yum install @foo" incorrectly reports "group foo does not exist" if group foo is *installed*, and that function is - for some reason - invoked when you run "yum update". I have no idea why yum thought it was a good idea to write two different functions in two different files to do the same thing, why the _at_groupinstall function is printing this error for groups that are installed but the installGroups function doesn't, or why the _at_groupinstall function gets called for all installed groups when you do 'yum update' (I suppose it's to install any extra packages for installed groups), I'll leave that to the experts. Anyone with stronger python foo than mine might be interested to take a look at /usr/lib/python2.7/site-packages/yum/__init__.py lines 4440-4477, which is where the buggy _at_groupinstall function that implements "yum install @foo" lives, and /usr/share/yum-cli/cli.py lines 1902-1965, where the not-buggy installGroups function that implements "yum group install foo" lives. I filed a new bug - https://bugzilla.redhat.com/show_bug.cgi?id=1043207 - for the "_at_groupinstall function's check is buggy" portion of the bug. I was keeping https://bugzilla.redhat.com/show_bug.cgi?id=1043202 for the "_at_groupinstall is called on yum update" part of the bug, but I think I'll close it now, as that's probably not wrong. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On 12/14/2013 12:38 PM, T.C. Hollingsworth wrote: On Fri, Dec 13, 2013 at 3:54 AM, Gene Czarcinski wrote: Indeed! There are environments/situations where there is no network connectivity (at least to the Internet) and never will be. It is this type of situations that will require a DVD. I run Fedora on a system that exists in on the side of a mountain in the remote part of the Arizona desert that is lucky to even have electricity and running water. No Internet, except tethering on my smartphone in an area that doesn't even have 3G coverage. (Internet access would sort of defeat the usual purpose of me venturing out there, anyway. That machine wouldn't even exist period if it were not used by others; I'd just take my laptop out there or maybe not even that. ;-) Trying to run a `yum update` out there would probably take longer than I usually spend there, and I'm not particularly worried about security updates, since the only way that system could possibly be more airgapped would be for it to exist on Mars. :-p Anyway, the DVD is _completely_ useless for this system. Pretty much every use case I have for this system requires packages from a certain third-party repository we all know and love, and even if Fedora contained all the packages I needed for it, they all certainly wouldn't on the DVD. Also, I really don't care about 95% of the packages on the DVD; I certainly don't need six different desktops. ;-) So instead when I refresh it from time to time, I just anaconda install onto a USB stick, yum install everything I want to it, then take it out there and dd it to the hard disk, manually making grub happy if necessary. This also allows me to configure it the way I want before I leave, so when I get out there it only takes me a few minutes to get it completely updated. I guess I could craft a kickstart and use livecd-creator instead, but that seems like more hassle than it's worth. Plus I keep that USB stick around so I have something that matches that system exactly at home, so if I ever decide I want to install some more stuff on it I can be sure I download all the RPMs necessary for a complete transaction. (Supposedly there's some offline download/install support in PackageKit for that usecase too, but it doesn't seem to be documented very well. The only reason I even know it exists is because hughsie asked on his blog if he could kill it. ;-) So if we really care about this usecase, we need to rebirth revisor or something similar so people can actually make images for their disconnected systems that have the stuff they want on them easily, instead of a grab bag of packages most of which they have no use for. For bonus points, maybe flesh out the offline update support so there's a sane way to update/install stuff on them afterward. Keeping the DVD around "because offline systems" is really just ignoring these users' actual needs. It would be nice if some development effort were put to making this actually better, but it's really an edge case that can already be handled by other, less elegant solutions like mine, so I really don't blame developers for not bothering with it. The only other use case we really have for the install DVD is for handing out at conferences, etc., and I think the multi-live DVD is a much better fit for that personally. Look at http://wiki.sugarlabs.org/go/Build_Your_Own_Remix_with_Fedora Make an installable live CD/DVD .iso with cutomizations Another situation is where I am installing into a qemu-kvm virtual system. Yes, there will be Internet connectivity. Yes, it is nice to have everything updated on install. But, running with just the DVD image is a lot faster (takes much less wall-clock time). Nowadays we have nice qcow2 images for that use case. Much better than the DVD IMHO, especially since a `yum update` is the first thing I'd do regardless... -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: UEFI install on MBR partition scheme, was: Failed attempt to fpaste UEFI failure data
On Dec 14, 2013, at 3:29 PM, Adam Williamson wrote: > > It does not. So it sounds like Chuck's trying to do a UEFI install to an > msdos-labelled disk, and that's the problem. I think this could use an RFE on the error message to be more clear what the problem is. > Chuck, you can't do a UEFI > install to a disk with an msdos disk label (partition table). If you can > blow the entire disk away, then choose a partition layout that does so, > and anaconda should automatically reformat it to gpt for you. If there > is stuff on the disk you can't stand to lose, then you only have the > choice of doing a BIOS install of Fedora. Or convert from MBR to GPT using gdisk. > > Chris, I'm trying to remember - we were discussing something like this > around the time of F19 release, and thinking of changing it. But I can't > recall if it was 'EFI system partition must be FAT32' or 'UEFI system > must be installed to a gpt-labelled disk' which was the assumption we > were questioning. Either way, I'm sure there was an assumption anaconda > was making in this area which we'd found not to be entirely true. I don't remember. But yes for system partitions it's FAT32, and for removable devices it's FAT12 or FAT16. The UEFI spec allows either GPT or MBR disks, and there's an EFI System Partition type code for both partition schemes. For MBR this is 0xEF and this code is missing from libparted/labels/dos.c, and blivet uses pyparted which hooks into libparted, I really don't think anaconda is going to use MBR disks on UEFI computers. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Is yum groups broken in f20 ?
On Sat, 2013-12-14 at 14:26 -0800, Adam Williamson wrote: > I managed to identify the specific change to yum which made these > messages appear, and I think I know the attributes of the groups for > which it appears: non-environment groups that are listed as installed > in /var/lib/yum/groups/installed (also, possibly, through whatever other > mechanisms yum has for listing installed groups; like everyone else, I'm > having a lot of trouble grokking this yum-groups-as-objects thing), that > exist in comps, but have set to false. > > It at least appears the check that was added is being run in > circumstances where it wasn't expected to run. I don't know how many (if > any) other bugs there are with the logic of the check itself and > the /var/lib/yum/groups/installed file and the groups-as-objects change > and whatever other goddamned changes are going on here. One further note - I'm not actually sure if the suggested 'yum group mark remove ' is actually a particularly good idea, here, because the groups in question really do exist and you may well 'have them installed' (for whatever value of 'having a group installed' we're using this week), they're just hidden. I don't know precisely what 'group mark remove' *does*, I need to keep reading the docs, but I don't think I'd advise it off-hand, especially since the messages, I _think_, are harmless (just annoying). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: UEFI install on MBR partition scheme, was: Failed attempt to fpaste UEFI failure data
On Sat, 2013-12-14 at 15:25 -0700, Chris Murphy wrote:
> On Dec 14, 2013, at 2:16 PM, Chuck Forsberg WA7KGX wrote:
>
> >
> > On 12/14/2013 12:57 PM, Adam Williamson wrote:
> >> On Sat, 2013-12-14 at 12:48 -0800, Chuck Forsberg WA7KGX wrote:
> >>> On 12/14/2013 09:12 AM, Adam Williamson wrote:
> On Sat, 2013-12-14 at 04:46 -0800, Chuck Forsberg WA7KGX wrote:
> > While in RC1.1 anaconda booted with UEFI I was able
> > to ftp the files in /tmp to my server. I then rebooted
> > my office machine to RC1.1 that had been installed
> > without UEFI. I tried fpaste again on these files and
> > fpaste failed again:
> >
> > -r--r--r-- 1 caf omen 149K Dec 14 04:32 syslog
> > -r--r--r-- 1 caf omen 24K Dec 14 04:32 storage.state
> > -r--r--r-- 1 caf omen 203K Dec 14 04:32 storage.log
> > -r--r--r-- 1 caf omen 112 Dec 14 04:32 sensitive-info.log
> > -r--r--r-- 1 caf omen 38K Dec 14 04:32 program.log
> > -r--r--r-- 1 caf omen 185K Dec 14 04:32 packaging.log
> > -r--r--r-- 1 caf omen 1.8K Dec 14 04:32 ifcfg.log
> > -r--r--r-- 1 caf omen 20K Dec 14 04:32 anaconda.log
> > -r--r--r-- 1 caf omen 351 Dec 14 04:32 anaconda-yum.conf
> > -r--r--r-- 1 caf omen 34K Dec 14 04:32 X.log
> > [caf@omen h]$ cat foo
> > [root@omen3 ~]# fpaste /o/tmp/h/*
> > WARNING: your paste size (812.2KiB) is very large and may be rejected by
> > the server. A pastebin is NOT a file hosting service!
> > Uploading (812.2KiB)...
> > Traceback (most recent call last):
> > File "/bin/fpaste", line 447, in
> > main()
> > File "/bin/fpaste", line 414, in main
> > [url, short_url] = paste(text, options)
> > File "/bin/fpaste", line 127, in paste
> > response = json.loads(f.read())
> > File "/usr/lib64/python2.7/json/__init__.py", line 338, in loads
> > return _default_decoder.decode(s)
> > File "/usr/lib64/python2.7/json/decoder.py", line 365, in decode
> > obj, end = self.raw_decode(s, idx=_w(s, 0).end())
> > File "/usr/lib64/python2.7/json/decoder.py", line 383, in raw_decode
> > raise ValueError("No JSON object could be decoded")
> > ValueError: No JSON object could be decoded
> >
> > It does appear fpaste is broken.
> Nope. It told you what was going on right at the top:
>
> "WARNING: your paste size (812.2KiB) is very large and may be rejected
> by the server. A pastebin is NOT a file hosting service!"
>
> It only takes up to 500KiB at a time. If you have somewhere to host the
> files from, there's no need to fpaste, just put them there for us to
> look at; otherwise, fpaste them one at a time.
> >>> I fpasted them one at a time just now.
> >> Then can you give us the URLs it gave you? We can't possibly find the
> >> stuff if you don't give us the URL...
> > Session output is attached.
>
> program.log failed to upload
>
> From anaconda.log
>
> • 04:30:44,507 DEBUG anaconda: Need disklabel: gpt have: msdos
>
>
> • 04:31:01,514 DEBUG anaconda: info bar clicked: failed to find a
> suitable stage1 device (( (AnacondaSpokeWindow at 0x37d9da0)>,))
>
> From storage.log
>
> • format = existing msdos disklabel
>
>
> I'm about to look through the blivet code now but does anyone know off
> hand if anaconda supports UEFI installs to MBR partition schemes? I
> think not, but I don't know for sure.
It does not. So it sounds like Chuck's trying to do a UEFI install to an
msdos-labelled disk, and that's the problem. Chuck, you can't do a UEFI
install to a disk with an msdos disk label (partition table). If you can
blow the entire disk away, then choose a partition layout that does so,
and anaconda should automatically reformat it to gpt for you. If there
is stuff on the disk you can't stand to lose, then you only have the
choice of doing a BIOS install of Fedora.
Chris, I'm trying to remember - we were discussing something like this
around the time of F19 release, and thinking of changing it. But I can't
recall if it was 'EFI system partition must be FAT32' or 'UEFI system
must be installed to a gpt-labelled disk' which was the assumption we
were questioning. Either way, I'm sure there was an assumption anaconda
was making in this area which we'd found not to be entirely true.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: Is yum groups broken in f20 ?
On Wed, 2013-12-11 at 22:35 -0600, Michael Cronenworth wrote: > On 12/08/2013 08:37 AM, Mateusz Marzantowicz wrote: > > Curious, why it blew up right now, just before F20 is released. It > > should have happened in alpha and not now. > > > > Workaround is to yum group mark remove for every group > > on the list. What a waste of time. > > Whatever you do - do not run "yum group mark convert". Now one of my systems > wants to install every Fedora package with "yum update". > > This affects all Fedoras with yum -120. Here's the parent bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1014202 I've found some time to look into this today, and I do not believe those two are the same bug. The error looks the same at a quick glance, but it is not the same and it is not on the same codepath. (yum's code actually contains about a dozen very similar warning messages produced by different checks at different points). I believe I've identified probably the most common case of this bug quite precisely. I forgot Piruthiviraj had filed #1039348 , so I filed a new bug about it, with the details I was able to figure out: https://bugzilla.redhat.com/show_bug.cgi?id=1043202 I managed to identify the specific change to yum which made these messages appear, and I think I know the attributes of the groups for which it appears: non-environment groups that are listed as installed in /var/lib/yum/groups/installed (also, possibly, through whatever other mechanisms yum has for listing installed groups; like everyone else, I'm having a lot of trouble grokking this yum-groups-as-objects thing), that exist in comps, but have set to false. It at least appears the check that was added is being run in circumstances where it wasn't expected to run. I don't know how many (if any) other bugs there are with the logic of the check itself and the /var/lib/yum/groups/installed file and the groups-as-objects change and whatever other goddamned changes are going on here. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: UEFI install on MBR partition scheme, was: Failed attempt to fpaste UEFI failure data
On Dec 14, 2013, at 2:16 PM, Chuck Forsberg WA7KGX wrote:
>
> On 12/14/2013 12:57 PM, Adam Williamson wrote:
>> On Sat, 2013-12-14 at 12:48 -0800, Chuck Forsberg WA7KGX wrote:
>>> On 12/14/2013 09:12 AM, Adam Williamson wrote:
On Sat, 2013-12-14 at 04:46 -0800, Chuck Forsberg WA7KGX wrote:
> While in RC1.1 anaconda booted with UEFI I was able
> to ftp the files in /tmp to my server. I then rebooted
> my office machine to RC1.1 that had been installed
> without UEFI. I tried fpaste again on these files and
> fpaste failed again:
>
> -r--r--r-- 1 caf omen 149K Dec 14 04:32 syslog
> -r--r--r-- 1 caf omen 24K Dec 14 04:32 storage.state
> -r--r--r-- 1 caf omen 203K Dec 14 04:32 storage.log
> -r--r--r-- 1 caf omen 112 Dec 14 04:32 sensitive-info.log
> -r--r--r-- 1 caf omen 38K Dec 14 04:32 program.log
> -r--r--r-- 1 caf omen 185K Dec 14 04:32 packaging.log
> -r--r--r-- 1 caf omen 1.8K Dec 14 04:32 ifcfg.log
> -r--r--r-- 1 caf omen 20K Dec 14 04:32 anaconda.log
> -r--r--r-- 1 caf omen 351 Dec 14 04:32 anaconda-yum.conf
> -r--r--r-- 1 caf omen 34K Dec 14 04:32 X.log
> [caf@omen h]$ cat foo
> [root@omen3 ~]# fpaste /o/tmp/h/*
> WARNING: your paste size (812.2KiB) is very large and may be rejected by
> the server. A pastebin is NOT a file hosting service!
> Uploading (812.2KiB)...
> Traceback (most recent call last):
> File "/bin/fpaste", line 447, in
> main()
> File "/bin/fpaste", line 414, in main
> [url, short_url] = paste(text, options)
> File "/bin/fpaste", line 127, in paste
> response = json.loads(f.read())
> File "/usr/lib64/python2.7/json/__init__.py", line 338, in loads
> return _default_decoder.decode(s)
> File "/usr/lib64/python2.7/json/decoder.py", line 365, in decode
> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
> File "/usr/lib64/python2.7/json/decoder.py", line 383, in raw_decode
> raise ValueError("No JSON object could be decoded")
> ValueError: No JSON object could be decoded
>
> It does appear fpaste is broken.
Nope. It told you what was going on right at the top:
"WARNING: your paste size (812.2KiB) is very large and may be rejected
by the server. A pastebin is NOT a file hosting service!"
It only takes up to 500KiB at a time. If you have somewhere to host the
files from, there's no need to fpaste, just put them there for us to
look at; otherwise, fpaste them one at a time.
>>> I fpasted them one at a time just now.
>> Then can you give us the URLs it gave you? We can't possibly find the
>> stuff if you don't give us the URL...
> Session output is attached.
program.log failed to upload
From anaconda.log
• 04:30:44,507 DEBUG anaconda: Need disklabel: gpt have: msdos
• 04:31:01,514 DEBUG anaconda: info bar clicked: failed to find a
suitable stage1 device ((,))
From storage.log
• format = existing msdos disklabel
I'm about to look through the blivet code now but does anyone know off hand if
anaconda supports UEFI installs to MBR partition schemes? I think not, but I
don't know for sure.
Chris Murphy
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 20 RC1 AMIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Sat, 14 Dec 2013 14:22:42 -0500 Matthew Miller escribió: > On Sat, Dec 14, 2013 at 02:50:50AM -0600, Dennis Gilmore wrote: > > > > > Hey Dennis, will the images going to mirrors be these or the > > > > > ones with the extra RC1.1 dot, like > > > > > "Fedora-x86_64-20-20131211.1-sda.qcow2"? > > > > The Images in RC1 and RC1.1 are exactly the same. the changes > > > > in the RC1.1 compose was just to respin the install tree making > > > > sure that none of the older libreoffice packages were in the > > > > tree. > > > Right, sorry, I wasn't clear. I know that part, but I'm wondering > > > what the actual filename going to the mirrors will be. This is > > > important for the web site and short links. > > We do not change file names when composed. what they are in the RC > > is what they will be when shipped. > > I see that the RC1 tree now alo contains > Fedora-x86_64-20-20131211.1-sda.qcow2 -- I am pretty sure that it was > previously Fedora-x86_64-20-20131211-sda.qcow2, without the .1. That > is what I was referring to. > the .1 is refering to the RC that it was. there is issues using just the date, it clashes with the nightly images for one. if we had done a rc2 there would have been a .2 at the end. going forward Im going to name the images as we do for ARM and livecds Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSrNmnAAoJEH7ltONmPFDRLc0P/RqkGeQ/svpoeTkDXIIfyegl L5lVbuQOB//Tviwq/3uGSt9vaR06EqniKpP9phSdwMxiXO5de0JQe/CAejiQvpsu Ko/ZwhMznDGCTar+okKs+FjtroC5ZYoHlU7afiAS/ZCo10QPYHsvsmnmccqKmvM9 ZYVUBha0fg++bWZzxXcblzh9kFzB/dny+s+dMpEVhi14kdcq9Fp26ncLmZ/4g1m8 vT/08vFLXA9hrUBDirDJXz3PNdLRZ6GWIoU8cSVdqPEu8bG6os00OxAtuCQyuvvs /TLjFLQBXmCWwZfebDEQDZu3PFTCBcnHWM3IcHizj3Eauwh9dsa1R8iVAR9hbbMv iFPHNRoLNxtiUkxNXVVBZJqaulOkyD5/eqBIdqhPMaDX5rIXWz84DMQPjL5FwDbT //n3tHWIe5Vpco8czaAJJXxFIcKbuEhnxWesIgdXuuXmVdya3ceJdoj6QzR64k+/ xj0xGYXYwxM61rZdxibY3P5a32IGgg8OKkmq+57s8chUNp5xpkq1giDGbQON/C9z 8SKO3Yhmo1ckpfezVy1Mw7sbJ79oiHqVVkMfJVxcX3vPDnZ0TNsn1u5Rsc9btRHf UF5dVGzDtusthxfzQjv2ToRru+8ebiF8oVp1BVCgSd8hobHuosOoxf0cNf7DaeKG IA/QRfSEZ4zACly/inpf =hXgD -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
On 12/14/2013 04:08 PM, Dan Mossor wrote: Although, as I'm writing this, I realized that when you said "restored", I'm not quite sure if you mean restored upon login, or restored upon restarting the application. Sorry if it was not clear earlier - I meant restored upon login - **not** restarting the application. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
On 12/14/2013 01:15 PM, nonamedotc wrote: > On 12/14/2013 11:20 AM, Kevin Fenzi wrote: >> Also, from re-reading the info in this thread, in addition to the >> xfce4-terminal bug, it sounds like perhaps recently all gnome based >> stuff isn't saving at all? >> >> (liferea, gnome-terminal, etc) >> >> I wonder if something changed recently in gtk3 session saving... will >> try and look into it. >> >> kevin >> >> > > One more observation - Thunderbird behavior is funny. It gets restored > correctly if it is **not** minimized to notification icons region (using > Firetray extension). > > * If thunderbird is "iconized" at the time of closing the session, it is > not restored. > > * If thunderbird is open or minimized to panel or simply inactive - it > is restored correctly. > > Thanks for looking in to this Kevin! Cheers. The Mozilla apps (Firefox, Thunderbird) save their own sessions. They should start up where you left off, unless you've customized either application. Although, as I'm writing this, I realized that when you said "restored", I'm not quite sure if you mean restored upon login, or restored upon restarting the application. -- Dan Mossor Systems Engineer at Large Fedora QA Team Volunteer FAS: dmossor IRC: danofsatx San Antonio, Texas, USA -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 up to F20 -- how?
On Sat, 14 Dec 2013 10:32:12 -0800, Adam Williamson wrote: > On Sat, 2013-12-14 at 18:28 +, Beartooth wrote: [] >> Yes, thanks again. After your post and Ed Greshko's, I did the >> first machine in question using his "fedup --net 20"; it worked fine. >> >> In a senior moment beyond most, I just did it again on the same >> machine (a Thinkpad T42). This time it got a list of non-extant groups >> like the ones that've been posted for yum. (I haven't checked whether >> they're identical to the list I got from yum directly, or to the one >> posted.) > > I think they do come from yum. It's on my todo list for today to try and > get to the bottom of what's going on with all these weird yum group > issues... In case it helps any, I'm now on the T42 again, after the second fedup, and it seems OK so far, if a bit slowed. Thanks again for your help! -- Beartooth Staffwright, Neo-Redneck Not Quite Clueless Power User Remember I have precious (very precious!) little idea where up is. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Failed attempt to fpaste UEFI failure data
On 12/14/2013 12:57 PM, Adam Williamson wrote:
On Sat, 2013-12-14 at 12:48 -0800, Chuck Forsberg WA7KGX wrote:
On 12/14/2013 09:12 AM, Adam Williamson wrote:
On Sat, 2013-12-14 at 04:46 -0800, Chuck Forsberg WA7KGX wrote:
While in RC1.1 anaconda booted with UEFI I was able
to ftp the files in /tmp to my server. I then rebooted
my office machine to RC1.1 that had been installed
without UEFI. I tried fpaste again on these files and
fpaste failed again:
-r--r--r-- 1 caf omen 149K Dec 14 04:32 syslog
-r--r--r-- 1 caf omen 24K Dec 14 04:32 storage.state
-r--r--r-- 1 caf omen 203K Dec 14 04:32 storage.log
-r--r--r-- 1 caf omen 112 Dec 14 04:32 sensitive-info.log
-r--r--r-- 1 caf omen 38K Dec 14 04:32 program.log
-r--r--r-- 1 caf omen 185K Dec 14 04:32 packaging.log
-r--r--r-- 1 caf omen 1.8K Dec 14 04:32 ifcfg.log
-r--r--r-- 1 caf omen 20K Dec 14 04:32 anaconda.log
-r--r--r-- 1 caf omen 351 Dec 14 04:32 anaconda-yum.conf
-r--r--r-- 1 caf omen 34K Dec 14 04:32 X.log
[caf@omen h]$ cat foo
[root@omen3 ~]# fpaste /o/tmp/h/*
WARNING: your paste size (812.2KiB) is very large and may be rejected by
the server. A pastebin is NOT a file hosting service!
Uploading (812.2KiB)...
Traceback (most recent call last):
File "/bin/fpaste", line 447, in
main()
File "/bin/fpaste", line 414, in main
[url, short_url] = paste(text, options)
File "/bin/fpaste", line 127, in paste
response = json.loads(f.read())
File "/usr/lib64/python2.7/json/__init__.py", line 338, in loads
return _default_decoder.decode(s)
File "/usr/lib64/python2.7/json/decoder.py", line 365, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib64/python2.7/json/decoder.py", line 383, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
It does appear fpaste is broken.
Nope. It told you what was going on right at the top:
"WARNING: your paste size (812.2KiB) is very large and may be rejected
by the server. A pastebin is NOT a file hosting service!"
It only takes up to 500KiB at a time. If you have somewhere to host the
files from, there's no need to fpaste, just put them there for us to
look at; otherwise, fpaste them one at a time.
I fpasted them one at a time just now.
Then can you give us the URLs it gave you? We can't possibly find the
stuff if you don't give us the URL...
Session output is attached.
--
Chuck Forsberg WA7KGX 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
[root@omen3 h]# ll
total 676
-r--r--r-- 1 caf omen 20084 Dec 14 04:32 anaconda.log
-r--r--r-- 1 caf omen351 Dec 14 04:32 anaconda-yum.conf
-r--r--r-- 1 caf omen 1816 Dec 14 04:32 ifcfg.log
-r--r--r-- 1 caf omen 188862 Dec 14 04:32 packaging.log
-r--r--r-- 1 caf omen 37895 Dec 14 04:32 program.log
-r--r--r-- 1 caf omen112 Dec 14 04:32 sensitive-info.log
-r--r--r-- 1 caf omen 206875 Dec 14 04:32 storage.log
-r--r--r-- 1 caf omen 24576 Dec 14 04:32 storage.state
-r--r--r-- 1 caf omen 152290 Dec 14 04:32 syslog
-r--r--r-- 1 caf omen 34557 Dec 14 04:32 X.log
[root@omen3 h]# for i in *
> do
> fpaste $i
> done
Uploading (23.7KiB)...
http://ur1.ca/g6vey -> http://paste.fedoraproject.org/61860/05564713
Uploading (0.5KiB)...
Traceback (most recent call last):
File "/bin/fpaste", line 447, in
main()
File "/bin/fpaste", line 414, in main
[url, short_url] = paste(text, options)
File "/bin/fpaste", line 128, in paste
id = [i[1]["id"] for i in response.iteritems()].pop()
KeyError: 'id'
Uploading (2.5KiB)...
http://ur1.ca/g6vf0 -> http://paste.fedoraproject.org/61861/38705564
Uploading (204.1KiB)...
http://ur1.ca/g6vf1 -> http://paste.fedoraproject.org/61862/87055650
Uploading (45.0KiB)...
Traceback (most recent call last):
File "/bin/fpaste", line 447, in
main()
File "/bin/fpaste", line 414, in main
[url, short_url] = paste(text, options)
File "/bin/fpaste", line 128, in paste
id = [i[1]["id"] for i in response.iteritems()].pop()
KeyError: 'id'
Uploading (0.2KiB)...
Traceback (most recent call last):
File "/bin/fpaste", line 447, in
main()
File "/bin/fpaste", line 414, in main
[url, short_url] = paste(text, options)
File "/bin/fpaste", line 128, in paste
id = [i[1]["id"] for i in response.iteritems()].pop()
KeyError: 'id'
Uploading (252.8KiB)...
http://ur1.ca/g6vf2 -> http://paste.fedoraproject.org/61863/87055653
WARNING: your paste looks a lot like binary data instead of text.
Send binary data anyway? [y/N]: y
Uploading (52.1KiB)...
http://ur1.ca/g6vf4 -> http://paste.fedoraproject.org/61864/13870556
Uploading (184.2KiB)...
http://ur1.ca/g6vf5 -> http://paste.fedoraproject.org/61865/05566713
U
Re: Failed attempt to fpaste UEFI failure data
On Sat, 2013-12-14 at 12:48 -0800, Chuck Forsberg WA7KGX wrote:
> On 12/14/2013 09:12 AM, Adam Williamson wrote:
> > On Sat, 2013-12-14 at 04:46 -0800, Chuck Forsberg WA7KGX wrote:
> >> While in RC1.1 anaconda booted with UEFI I was able
> >> to ftp the files in /tmp to my server. I then rebooted
> >> my office machine to RC1.1 that had been installed
> >> without UEFI. I tried fpaste again on these files and
> >> fpaste failed again:
> >>
> >> -r--r--r-- 1 caf omen 149K Dec 14 04:32 syslog
> >> -r--r--r-- 1 caf omen 24K Dec 14 04:32 storage.state
> >> -r--r--r-- 1 caf omen 203K Dec 14 04:32 storage.log
> >> -r--r--r-- 1 caf omen 112 Dec 14 04:32 sensitive-info.log
> >> -r--r--r-- 1 caf omen 38K Dec 14 04:32 program.log
> >> -r--r--r-- 1 caf omen 185K Dec 14 04:32 packaging.log
> >> -r--r--r-- 1 caf omen 1.8K Dec 14 04:32 ifcfg.log
> >> -r--r--r-- 1 caf omen 20K Dec 14 04:32 anaconda.log
> >> -r--r--r-- 1 caf omen 351 Dec 14 04:32 anaconda-yum.conf
> >> -r--r--r-- 1 caf omen 34K Dec 14 04:32 X.log
> >> [caf@omen h]$ cat foo
> >> [root@omen3 ~]# fpaste /o/tmp/h/*
> >> WARNING: your paste size (812.2KiB) is very large and may be rejected by
> >> the server. A pastebin is NOT a file hosting service!
> >> Uploading (812.2KiB)...
> >> Traceback (most recent call last):
> >> File "/bin/fpaste", line 447, in
> >> main()
> >> File "/bin/fpaste", line 414, in main
> >> [url, short_url] = paste(text, options)
> >> File "/bin/fpaste", line 127, in paste
> >> response = json.loads(f.read())
> >> File "/usr/lib64/python2.7/json/__init__.py", line 338, in loads
> >> return _default_decoder.decode(s)
> >> File "/usr/lib64/python2.7/json/decoder.py", line 365, in decode
> >> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
> >> File "/usr/lib64/python2.7/json/decoder.py", line 383, in raw_decode
> >> raise ValueError("No JSON object could be decoded")
> >> ValueError: No JSON object could be decoded
> >>
> >> It does appear fpaste is broken.
> > Nope. It told you what was going on right at the top:
> >
> > "WARNING: your paste size (812.2KiB) is very large and may be rejected
> > by the server. A pastebin is NOT a file hosting service!"
> >
> > It only takes up to 500KiB at a time. If you have somewhere to host the
> > files from, there's no need to fpaste, just put them there for us to
> > look at; otherwise, fpaste them one at a time.
> I fpasted them one at a time just now.
Then can you give us the URLs it gave you? We can't possibly find the
stuff if you don't give us the URL...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
On 12/14/2013 11:15 AM, nonamedotc wrote: On 12/14/2013 11:20 AM, Kevin Fenzi wrote: Also, from re-reading the info in this thread, in addition to the xfce4-terminal bug, it sounds like perhaps recently all gnome based stuff isn't saving at all? (liferea, gnome-terminal, etc) I wonder if something changed recently in gtk3 session saving... will try and look into it. kevin One more observation - Thunderbird behavior is funny. It gets restored correctly if it is **not** minimized to notification icons region (using Firetray extension). * If thunderbird is "iconized" at the time of closing the session, it is not restored. * If thunderbird is open or minimized to panel or simply inactive - it is restored correctly. Thanks for looking in to this Kevin! Cheers. Xfce stopped remembering sessions over a reboot some time ago. When it was remembering sessions it didn't remember correctly. Sessions were "restored" to the wrong workspace and the wrong state. Unless the apps can be restored correctly, I prefer to restart them myself. -- Chuck Forsberg WA7KGX 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: Failed attempt to fpaste UEFI failure data
On 12/14/2013 09:12 AM, Adam Williamson wrote:
On Sat, 2013-12-14 at 04:46 -0800, Chuck Forsberg WA7KGX wrote:
While in RC1.1 anaconda booted with UEFI I was able
to ftp the files in /tmp to my server. I then rebooted
my office machine to RC1.1 that had been installed
without UEFI. I tried fpaste again on these files and
fpaste failed again:
-r--r--r-- 1 caf omen 149K Dec 14 04:32 syslog
-r--r--r-- 1 caf omen 24K Dec 14 04:32 storage.state
-r--r--r-- 1 caf omen 203K Dec 14 04:32 storage.log
-r--r--r-- 1 caf omen 112 Dec 14 04:32 sensitive-info.log
-r--r--r-- 1 caf omen 38K Dec 14 04:32 program.log
-r--r--r-- 1 caf omen 185K Dec 14 04:32 packaging.log
-r--r--r-- 1 caf omen 1.8K Dec 14 04:32 ifcfg.log
-r--r--r-- 1 caf omen 20K Dec 14 04:32 anaconda.log
-r--r--r-- 1 caf omen 351 Dec 14 04:32 anaconda-yum.conf
-r--r--r-- 1 caf omen 34K Dec 14 04:32 X.log
[caf@omen h]$ cat foo
[root@omen3 ~]# fpaste /o/tmp/h/*
WARNING: your paste size (812.2KiB) is very large and may be rejected by
the server. A pastebin is NOT a file hosting service!
Uploading (812.2KiB)...
Traceback (most recent call last):
File "/bin/fpaste", line 447, in
main()
File "/bin/fpaste", line 414, in main
[url, short_url] = paste(text, options)
File "/bin/fpaste", line 127, in paste
response = json.loads(f.read())
File "/usr/lib64/python2.7/json/__init__.py", line 338, in loads
return _default_decoder.decode(s)
File "/usr/lib64/python2.7/json/decoder.py", line 365, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib64/python2.7/json/decoder.py", line 383, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
It does appear fpaste is broken.
Nope. It told you what was going on right at the top:
"WARNING: your paste size (812.2KiB) is very large and may be rejected
by the server. A pastebin is NOT a file hosting service!"
It only takes up to 500KiB at a time. If you have somewhere to host the
files from, there's no need to fpaste, just put them there for us to
look at; otherwise, fpaste them one at a time.
I fpasted them one at a time just now.
--
Chuck Forsberg WA7KGX 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: Criterion revision proposal: KDE default applications
On Fri, Dec 13, 2013 at 3:54 AM, Gene Czarcinski wrote: > Indeed! There are environments/situations where there is no network > connectivity (at least to the Internet) and never will be. It is this type > of situations that will require a DVD. I run Fedora on a system that exists in on the side of a mountain in the remote part of the Arizona desert that is lucky to even have electricity and running water. No Internet, except tethering on my smartphone in an area that doesn't even have 3G coverage. (Internet access would sort of defeat the usual purpose of me venturing out there, anyway. That machine wouldn't even exist period if it were not used by others; I'd just take my laptop out there or maybe not even that. ;-) Trying to run a `yum update` out there would probably take longer than I usually spend there, and I'm not particularly worried about security updates, since the only way that system could possibly be more airgapped would be for it to exist on Mars. :-p Anyway, the DVD is _completely_ useless for this system. Pretty much every use case I have for this system requires packages from a certain third-party repository we all know and love, and even if Fedora contained all the packages I needed for it, they all certainly wouldn't on the DVD. Also, I really don't care about 95% of the packages on the DVD; I certainly don't need six different desktops. ;-) So instead when I refresh it from time to time, I just anaconda install onto a USB stick, yum install everything I want to it, then take it out there and dd it to the hard disk, manually making grub happy if necessary. This also allows me to configure it the way I want before I leave, so when I get out there it only takes me a few minutes to get it completely updated. I guess I could craft a kickstart and use livecd-creator instead, but that seems like more hassle than it's worth. Plus I keep that USB stick around so I have something that matches that system exactly at home, so if I ever decide I want to install some more stuff on it I can be sure I download all the RPMs necessary for a complete transaction. (Supposedly there's some offline download/install support in PackageKit for that usecase too, but it doesn't seem to be documented very well. The only reason I even know it exists is because hughsie asked on his blog if he could kill it. ;-) So if we really care about this usecase, we need to rebirth revisor or something similar so people can actually make images for their disconnected systems that have the stuff they want on them easily, instead of a grab bag of packages most of which they have no use for. For bonus points, maybe flesh out the offline update support so there's a sane way to update/install stuff on them afterward. Keeping the DVD around "because offline systems" is really just ignoring these users' actual needs. It would be nice if some development effort were put to making this actually better, but it's really an edge case that can already be handled by other, less elegant solutions like mine, so I really don't blame developers for not bothering with it. The only other use case we really have for the install DVD is for handing out at conferences, etc., and I think the multi-live DVD is a much better fit for that personally. > Another situation is where I am installing into a qemu-kvm virtual system. > Yes, there will be Internet connectivity. Yes, it is nice to have > everything updated on install. But, running with just the DVD image is a > lot faster (takes much less wall-clock time). Nowadays we have nice qcow2 images for that use case. Much better than the DVD IMHO, especially since a `yum update` is the first thing I'd do regardless... -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Sat, 2013-12-14 at 13:47 -0500, Richard Ryniker wrote: > The defining characteristic of the Live images is that they run > without installation on a user's disks. Beyond that, they have the > capability to install a minimal Fedora system to a local disk. Once > the size limit for a live image is increased beyond the capacity of a > CD (or other common media), there seems no reason to limit the live > image size to 1 GB, or any arbitrary value. There's no reason to limit it to any arbitrary value, but none of the values we've used or discussed is arbitrary. 1GB is the size of a 1GB USB stick, 2GB is the size of a 2GB USB stick. 3GB for example would make no sense as no-one makes media in that size. Obvious 'sensible' target sizes are 650MB CD, 700MB CD, 1GB USB, 2GB USB, 4GB USB, 4GiB (because of FAT32 filesystem issues...), single-layer DVD, 8GB USB, dual-layer DVD, 16GB USB. > Rather than struggle to find what can be be discarded from a live > image in order to achieve a particular size, why not build the DVD > product as a live system, or expand the existing live recipe to > include more of the frequently used packages and not build the DVD? > The DVD installer program has much more flexibility, but this is due > to that arbitrary size limit, I expect: there just is not space for > the full Fedora installation program (plus local repository) in > today's live images. No, it isn't, really. The live installer can only install the package set you actually get when booting live, because all it does is dump itself to the hard disk; it doesn't actually contain or install any packages per se. So I don't see how we can do the DVD-as-live-image thing in any practical way; the point of the DVD is that you can install _different_ environments from it, but there's no way you can do that from a live image. It's also worth noting that the installer team doesn't like installing from a live environment. It involves rather a lot of messy hacks and can cause breakage; the major problem they have is they cannot possibly trust that the system is in a 'clean' state when the installer initializes, which they can control from the 'traditional' installer mode. One thing they've floated as an idea is to have a separate 'installation environment' you could boot into from the live images - so you could either boot into 'try it out' live mode, or 'install it' installer mode, but not run the installer from within the live mode. > A sizable group of users may have very limited hardware resources - > no network, only a CD drive. This group would be a reasonable target > for a "Limited Resources" spin that seeks to tailor Fedora to such an > environment. For example, these systems may have too little memory to > support anaconda (and many of the applications in Fedora's default > configuration). Maybe a new SIG for this target. (Perhaps it already > exists and I, with richer hardware resources, never looked for it.) I don't believe it does, no. It seems like an interesting idea, so if you're interested in making it happen, you could certainly go ahead and make a proposal to the relevant authorities... > Modifications to limit and > make more specific the actual test coverage can help Fedora users > better understand what they have, and reflect the reality of QA > resource limits. I think we've always had this as a goal, but we've just winded up drifting slightly over the last few releases to the point where we're really struggling to keep up with the workload. > To this end, it would be good to have better distinction between what > QA tests and what other groups - SIG, upstream, packager, spin > creator, architecture group, etc. - are responsible to test. QA test > criteria is one place to document this, at least the QA view of it. This is something viking-ice is talking about as well, and I certainly agree with you guys that there's some value to it. The only problem I have is that I don't really see a lot of evidence that many other groups test their stuff at all in any particularly organized way, though I may well be missing something. I'd have a lot of time for a vision where we place some responsibility on the desktop SIG for desktop testing, on the KDE SIG for KDE testing and so on, but like I keep saying for the specific proposal here, we have to make sure it actually *happens*. I'm not a fan of QA just throwing our hands up and unilaterally saying "okay, we're just going to test X and trust that someone else cares about making sure Y and Z work", at least not until we've made some good-faith effort to make things better in a collaborative way. At present it feels a lot like people only test things when we (QA) draw up the test plans and then go out and make a fairly strenuous effort to plead with others to test them. I mean, if we just fire a TC/RC and stick the desktop matrices up, it's only intermittently that I've seen desktop SIG folks show up and run through the validation testing. If I or someone
Re: Fedora 20 RC1 AMIs
On Sat, Dec 14, 2013 at 02:50:50AM -0600, Dennis Gilmore wrote: > > > > Hey Dennis, will the images going to mirrors be these or the ones > > > > with the extra RC1.1 dot, like > > > > "Fedora-x86_64-20-20131211.1-sda.qcow2"? > > > The Images in RC1 and RC1.1 are exactly the same. the changes in the > > > RC1.1 compose was just to respin the install tree making sure that > > > none of the older libreoffice packages were in the tree. > > Right, sorry, I wasn't clear. I know that part, but I'm wondering > > what the actual filename going to the mirrors will be. This is > > important for the web site and short links. > We do not change file names when composed. what they are in the RC is > what they will be when shipped. I see that the RC1 tree now alo contains Fedora-x86_64-20-20131211.1-sda.qcow2 -- I am pretty sure that it was previously Fedora-x86_64-20-20131211-sda.qcow2, without the .1. That is what I was referring to. -- Matthew Miller -- Fedora Project Architect -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
On 12/14/2013 11:20 AM, Kevin Fenzi wrote: Also, from re-reading the info in this thread, in addition to the xfce4-terminal bug, it sounds like perhaps recently all gnome based stuff isn't saving at all? (liferea, gnome-terminal, etc) I wonder if something changed recently in gtk3 session saving... will try and look into it. kevin One more observation - Thunderbird behavior is funny. It gets restored correctly if it is **not** minimized to notification icons region (using Firetray extension). * If thunderbird is "iconized" at the time of closing the session, it is not restored. * If thunderbird is open or minimized to panel or simply inactive - it is restored correctly. Thanks for looking in to this Kevin! Cheers. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
The defining characteristic of the Live images is that they run without installation on a user's disks. Beyond that, they have the capability to install a minimal Fedora system to a local disk. Once the size limit for a live image is increased beyond the capacity of a CD (or other common media), there seems no reason to limit the live image size to 1 GB, or any arbitrary value. Rather than struggle to find what can be be discarded from a live image in order to achieve a particular size, why not build the DVD product as a live system, or expand the existing live recipe to include more of the frequently used packages and not build the DVD? The DVD installer program has much more flexibility, but this is due to that arbitrary size limit, I expect: there just is not space for the full Fedora installation program (plus local repository) in today's live images. Others have stated the need for something like the DVD collection of packages. Without this, those who need something like it will have to build their own, obtain it from a third party, or look at another distribution. For this reason, to simplify the Fedora products to (1) network installation and (2) stand-alone installation, I submit the installation DVD could be built as a live image. I do not like the thought that many users might decide they have to copy an entire Fedora repository to a portable hard drive in order to install the Fedora system they want on a machine without a good Internet connection. A sizable group of users may have very limited hardware resources - no network, only a CD drive. This group would be a reasonable target for a "Limited Resources" spin that seeks to tailor Fedora to such an environment. For example, these systems may have too little memory to support anaconda (and many of the applications in Fedora's default configuration). Maybe a new SIG for this target. (Perhaps it already exists and I, with richer hardware resources, never looked for it.) In any case, Adam Williamson's articulate comment about the practical limits to what Quality Assurance can achieve with a six month release cycle and the available resources is very relevant. The release criteria, in part, seek to define what will be tested, but they read more like a prescription for what "should" be tested. Modifications to limit and make more specific the actual test coverage can help Fedora users better understand what they have, and reflect the reality of QA resource limits. To this end, it would be good to have better distinction between what QA tests and what other groups - SIG, upstream, packager, spin creator, architecture group, etc. - are responsible to test. QA test criteria is one place to document this, at least the QA view of it. Adam, your recent work on storage tests reads like a Unit Test Plan for anaconda: something that tries to exercise all the code paths of the program. Is this the proper function of Fedora QA? If it is, what is the proper fraction of the anaconda development budget to be allocated to Fedora QA for this purpose? I use this as an example to support your observation that QA clearly does not have resources to test all it might want to test, and clearer definition is required for what QA will test and what others have to test. Your storage test cases look like something anaconda developers should run before they let a new version loose. Throw away a package because it was not tested, failed a test, or missed a deadline is not a solution, however vexed one might be about what has not been done. It is natural that many changes will occur in Fedora's package roster. I counted 39,500 rpm files in the F20 repository. Lots of changes, for many reasons, are normal, but it is not sensible to expect all these parts to work properly. It is not even reasonable to expect the ten percent of these files on the DVD to all work properly. Fedora QA, as a group, should probably take a pragmatic approach and focus on "critical path" and installation issues that affect large groups of users, and refer more detailed tests to others. Do more, certainly, if resources permit. And try to influence others to be more aware and effective in their test activities. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 up to F20 -- how?
On Sat, 2013-12-14 at 18:28 +, Beartooth wrote: > > The only 'officially recommended' upgrade method from F18 onwards is > > fedup. The installer's upgrade mode does not exist any more. fedup is > > essentially just a fairly thin wrapper around a 'yum update' which is > > performed in a special systemd target. You can feed it packages from a > > repository or from a DVD ISO, but it basically does the same thing > > either way (you'll have more, and newer, packages available if you use > > the repo approach). > > Yes, thanks again. After your post and Ed Greshko's, I did the > first machine in question using his "fedup --net 20"; it worked fine. > > In a senior moment beyond most, I just did it again on the same > machine (a Thinkpad T42). This time it got a list of non-extant groups > like the ones that've been posted for yum. (I haven't checked whether > they're identical to the list I got from yum directly, or to the one > posted.) I think they do come from yum. It's on my todo list for today to try and get to the bottom of what's going on with all these weird yum group issues... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 up to F20 -- how?
On Wed, 04 Dec 2013 02:42:16 -0800, Adam Williamson wrote: > On Sun, 2013-12-01 at 19:44 +, Beartooth wrote: >> I have several machines running F18, which I would like to change >> to F20 by some sort of upgrade, rather than a fresh install. Can anyone >> yet guess whether upgrading from a DVD, or using fedup, or yum, or some >> other way is most likely to succeed with the least trouble? >> >> Among other possibilities, is an upgrade via DVD from F18 to F20 >> Beta, followed by yum updates at regular short intervals, any more or >> less promising that fedup? (I've had very mixed experience with that.) [] > You got various replies, but to clear up one point, you can't really > upgrade 'via DVD' from F18 to anything, at least not in the way I think > you're thinking about. Yes, I was still taking it for granted that I could run Anaconda from a DVD for any Fedora release, and get a choice of whether to upgrade or install afresh. And I thank you heartily for the correction! These changes often take some time to get to the likes of me, and I'd've fallen into a real mare's nest if I'd tried it. > The only 'officially recommended' upgrade method from F18 onwards is > fedup. The installer's upgrade mode does not exist any more. fedup is > essentially just a fairly thin wrapper around a 'yum update' which is > performed in a special systemd target. You can feed it packages from a > repository or from a DVD ISO, but it basically does the same thing > either way (you'll have more, and newer, packages available if you use > the repo approach). Yes, thanks again. After your post and Ed Greshko's, I did the first machine in question using his "fedup --net 20"; it worked fine. In a senior moment beyond most, I just did it again on the same machine (a Thinkpad T42). This time it got a list of non-extant groups like the ones that've been posted for yum. (I haven't checked whether they're identical to the list I got from yum directly, or to the one posted.) [snipperoo] > I don't know if there's any hard evidence as to whether it's better to > do an 'incremental upgrade' (18->19->20) or a direct one (18->20), to be > honest. I'm sure you can find anecdotal evidence for either. FWIW, I'd > usually go with the direct approach. Hang on! Here goes! -- Beartooth Staffwright, Neo-Redneck Not Quite Clueless Power User Remember I have precious (very precious!) little idea where up is. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Very rough storage validation matrix draft
On Sat, 2013-12-14 at 10:56 -0700, Chris Murphy wrote: > On Dec 14, 2013, at 12:48 AM, Adam Williamson wrote: > > > On Sat, 2013-12-14 at 00:06 -0700, Chris Murphy wrote: > >>> > >> In my opinion, every one of those tests requires a feature owner. If > >> no one volunteers, if a hand off isn't made, the functionality for the > >> feature represented by the sanity check shall be removed from the next > >> version of Fedora. > > > > Do you mean someone who is responsible for development of the feature, > > or testing it? > > Testing it. > > > Right now I'm simply trying to figure out a vaguely practical approach > > for testing what we can of the installer's storage functions. That's > > really all I'm shooting for. > > I understand that. I'm suggesting an approach that ties functionality > retention to community interest. If we can't recruit even temp "QA > people" to adopt a test case, then maybe the community doesn't really > value the functions indicated by those test cases. Personally I don't think that approach really works out; what are we going to do, have a big database of who 'owns' what test at any given time? You have to file paperwork to keep tests in the matrix? Who's going to own the process of tracking who owns which tests? I think tests with difficult requirements are something we have to deal with, but I don't think having 'feature owners' is the way to go, personally. > For example the iSCSI test case. It seemed pretty much no one in QA > really cared about that functionality, as they didn't depend on or use > it themselves. It was just a test case to them. So where are the > people who actually want that function to work? I was perfectly willing to test this one, actually, only it turns out my iSCSI target has some kind of weird issue that others don't. So I can't, practically, at the moment. I can see how your approach kind of feels like it makes sense if you think of every little attribute of the installer as a 'feature', but that itself doesn't quite work, for me. I mean, 'install into free space' isn't really a 'feature', or at least I don't see that it gets us anywhere to think of it as one. What does it mean to be the 'feature owner' for the 'install onto an empty disk' 'feature'? > Another example is LVM Thin P. I want to know where the feature's > owners have been this whole time, and how it is they didn't test RC1 > to see if their own feature, given prime real estate in the installer, > was working. On that basis alone I'd say LVM Thin P should be pulled > due to lack of community interest, including apparently lack of > interest by the feature's own owners. I'm honestly willing to cut them some slack here, given that RC1 existed for *one whole day* before Go/No-Go. One thing I should probably unpack explicitly here is that I'm worried that the way we've done releases the last few cycles is becoming the New Normal, especially for people who've mostly been involved with validation in the last few releases. I don't think it's a good thing at all that we've got 'accustomed' to spinning the RC we wind up releasing about 16 hours before we sign off on its release; we only really started doing that a lot around F18, and it is not at all the optimal way to do things. It is much better if we have the RC we're planning to ship built for, like, 3-4 days, to give us a chance to find issues in it that aren't immediately screamingly obvious from the validation matrices. Building the release image late on Wednesday then doing go/no-go on Thursday is absolutely not how we really _want_ to be doing things. People outside QA aren't reading the test@ list 24/7 ready to jump on a new RC, I don't think it's entirely realistic to expect every Change owner to catch the final RC in a 16-hour window and test their Change. thinp support as a feature is actually owned by dlehman - https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport - who I expect was taking a well-earned break during the very short window we were testing RC1. > > This is one possible approach, there are > > many others. I mean, prior to newUI, we placed a _much_ lower > emphasis > > on custom partitioning. > > Yes, well you know how I feel about manual partitioning. The test > cases are necessary to qualify the function works sufficiently well > for release. But to execute the test cases requires either people or > some magical automation. anaconda team is currently working on implementing CI into their development process, and may come to us for help with that later in the process (to help write test cases). I think that will help quite a lot; we could probably do much better 'sanity checking' with automated tests to stress obvious corner cases like setting things to invalid values, repeatedly changing values and so on. I would expect we would also be able to cover a lot of the cases in that matrix at least in non-UI form. I think there are always likely to be bugs in the UI stuff that only be
Re: Very rough storage validation matrix draft
On Dec 14, 2013, at 12:48 AM, Adam Williamson wrote: > On Sat, 2013-12-14 at 00:06 -0700, Chris Murphy wrote: >>> >> In my opinion, every one of those tests requires a feature owner. If >> no one volunteers, if a hand off isn't made, the functionality for the >> feature represented by the sanity check shall be removed from the next >> version of Fedora. > > Do you mean someone who is responsible for development of the feature, > or testing it? Testing it. > Right now I'm simply trying to figure out a vaguely practical approach > for testing what we can of the installer's storage functions. That's > really all I'm shooting for. I understand that. I'm suggesting an approach that ties functionality retention to community interest. If we can't recruit even temp "QA people" to adopt a test case, then maybe the community doesn't really value the functions indicated by those test cases. For example the iSCSI test case. It seemed pretty much no one in QA really cared about that functionality, as they didn't depend on or use it themselves. It was just a test case to them. So where are the people who actually want that function to work? Another example is LVM Thin P. I want to know where the feature's owners have been this whole time, and how it is they didn't test RC1 to see if their own feature, given prime real estate in the installer, was working. On that basis alone I'd say LVM Thin P should be pulled due to lack of community interest, including apparently lack of interest by the feature's own owners. > This is one possible approach, there are > many others. I mean, prior to newUI, we placed a _much_ lower emphasis > on custom partitioning. Yes, well you know how I feel about manual partitioning. The test cases are necessary to qualify the function works sufficiently well for release. But to execute the test cases requires either people or some magical automation. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
Also, from re-reading the info in this thread, in addition to the xfce4-terminal bug, it sounds like perhaps recently all gnome based stuff isn't saving at all? (liferea, gnome-terminal, etc) I wonder if something changed recently in gtk3 session saving... will try and look into it. kevin signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
On Sat, 14 Dec 2013 18:12:41 +0100 Ralf Corsepius wrote: > On 12/14/2013 06:14 AM, Ralf Corsepius wrote: > > On 12/13/2013 05:48 PM, Kevin Fenzi wrote: > >> On Fri, 13 Dec 2013 17:04:01 +0100 > >> Ralf Corsepius wrote: > > > > When re-loggin in, > > - sometimes, *all* "saved apps" appear on virtual "workspace 1", > > plastered on top of each other. > > Some more details after some experiments with newly created, local > accounts on f19 and f20: > > - instead of getting restored at their former positions, > xfce-terminals always pop up on random positions on "workspace 1" > > - gnome-terminals don't seem to be saved at all and do not get > restored. They vanish. > > - firefox and thunderbird do get restored correctly. > > From this, I conclude, xfce-terminal and gnome-terminal are both > broken in different ways. > > Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1043178 This is bug https://bugzilla.redhat.com/show_bug.cgi?id=1026599 It's sadly known upstream since the Terminal->xfce4-terminal rework. ;( Recently someone did bisect it and found the exact commit where it started breaking, so hopefully that means it might get fixed soon. kevin signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
On 12/14/2013 06:14 AM, Ralf Corsepius wrote: On 12/13/2013 05:48 PM, Kevin Fenzi wrote: On Fri, 13 Dec 2013 17:04:01 +0100 Ralf Corsepius wrote: When re-loggin in, - sometimes, *all* "saved apps" appear on virtual "workspace 1", plastered on top of each other. Some more details after some experiments with newly created, local accounts on f19 and f20: - instead of getting restored at their former positions, xfce-terminals always pop up on random positions on "workspace 1" - gnome-terminals don't seem to be saved at all and do not get restored. They vanish. - firefox and thunderbird do get restored correctly. From this, I conclude, xfce-terminal and gnome-terminal are both broken in different ways. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1043178 Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Failed attempt to fpaste UEFI failure data
On Sat, 2013-12-14 at 04:46 -0800, Chuck Forsberg WA7KGX wrote:
> While in RC1.1 anaconda booted with UEFI I was able
> to ftp the files in /tmp to my server. I then rebooted
> my office machine to RC1.1 that had been installed
> without UEFI. I tried fpaste again on these files and
> fpaste failed again:
>
> -r--r--r-- 1 caf omen 149K Dec 14 04:32 syslog
> -r--r--r-- 1 caf omen 24K Dec 14 04:32 storage.state
> -r--r--r-- 1 caf omen 203K Dec 14 04:32 storage.log
> -r--r--r-- 1 caf omen 112 Dec 14 04:32 sensitive-info.log
> -r--r--r-- 1 caf omen 38K Dec 14 04:32 program.log
> -r--r--r-- 1 caf omen 185K Dec 14 04:32 packaging.log
> -r--r--r-- 1 caf omen 1.8K Dec 14 04:32 ifcfg.log
> -r--r--r-- 1 caf omen 20K Dec 14 04:32 anaconda.log
> -r--r--r-- 1 caf omen 351 Dec 14 04:32 anaconda-yum.conf
> -r--r--r-- 1 caf omen 34K Dec 14 04:32 X.log
> [caf@omen h]$ cat foo
> [root@omen3 ~]# fpaste /o/tmp/h/*
> WARNING: your paste size (812.2KiB) is very large and may be rejected by
> the server. A pastebin is NOT a file hosting service!
> Uploading (812.2KiB)...
> Traceback (most recent call last):
>File "/bin/fpaste", line 447, in
> main()
>File "/bin/fpaste", line 414, in main
> [url, short_url] = paste(text, options)
>File "/bin/fpaste", line 127, in paste
> response = json.loads(f.read())
>File "/usr/lib64/python2.7/json/__init__.py", line 338, in loads
> return _default_decoder.decode(s)
>File "/usr/lib64/python2.7/json/decoder.py", line 365, in decode
> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
>File "/usr/lib64/python2.7/json/decoder.py", line 383, in raw_decode
> raise ValueError("No JSON object could be decoded")
> ValueError: No JSON object could be decoded
>
> It does appear fpaste is broken.
Nope. It told you what was going on right at the top:
"WARNING: your paste size (812.2KiB) is very large and may be rejected
by the server. A pastebin is NOT a file hosting service!"
It only takes up to 500KiB at a time. If you have somewhere to host the
files from, there's no need to fpaste, just put them there for us to
look at; otherwise, fpaste them one at a time.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 21 and 22 trackers created
On 12/13/2013 08:22 PM, Adam Williamson wrote: > Hey folks - just a quick note, I've created the F21 and F22 blocker/FE > tracker bugs and updated > https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers . The > F21 tracker bugs have the 'non-versioned' aliases (AlphaBlocker, > BetaBlocker etc etc) now, so you can propose F21 blocker/FEs easily. > > everyone ready to upgrade to Rawhide? :) > Yep! That's my Christmas present! The kids are getting tablets, momma's getting tickets to a show, and daddy's getting Rawhide. -- Dan Mossor Systems Engineer at Large Fedora QA Team Volunteer FAS: dmossor IRC: danofsatx San Antonio, Texas, USA -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Important note regarding /root permissions for those who installed Fedora 20 pre-releases
2013/12/13 Adam Williamson > Hi, folks. I wanted to draw the attention of anyone who used Fedora 20 > pre-release (Alpha, Beta, or TC/RC for Alpha, Beta or Final) to this > issue: > > > https://fedoraproject.org/wiki/Common_F20_bugs#.2Froot_permissions_incorrect_on_pre-release_installations > > Briefly, if you did use F20 pre-release - this includes yum or otherwise > upgrading to F20 at any time the older 'rootfiles' package was in the > F20 repos, that is any time prior to about 12-05 (testing) /12-11 > (stable) - permissions on the /root directory are likely to be 0755, > which is probably not what most sysadmins would expect. You may wish to > change them to 0550 or something similarly locked-down. > -- > Thank you. Indeed, it was 755. I have it installed since pre-Alpha. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Network Manager questions on F20RC1
Hi, my system has a built in ethernet interface wich is working perfectly fine on IPV4 and IPV6. I added a second interface via usb for wiresharking some stuff (this way I don't get my own traffic in the packet dumps). I don't want or need an IP-stack on this second interface. In network manager there is on top of the IPV4 and IPV6 config pages an on/off button. For IPV4 this buttons seems to have no effect at all. It's off-position is not even saved when applying or closing the dialog. For IPV6 something happens. All addresses except local link are deleted, no DNS and routing. But if link local still remains where is the difference between disabling IPV6 or enabling and choosing link local configuration only ? Did I missunderstand the gui and the on/off buttons have some other effect ? Or is it simply broken ? cu romal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Failed attempt to fpaste UEFI failure data
While in RC1.1 anaconda booted with UEFI I was able
to ftp the files in /tmp to my server. I then rebooted
my office machine to RC1.1 that had been installed
without UEFI. I tried fpaste again on these files and
fpaste failed again:
-r--r--r-- 1 caf omen 149K Dec 14 04:32 syslog
-r--r--r-- 1 caf omen 24K Dec 14 04:32 storage.state
-r--r--r-- 1 caf omen 203K Dec 14 04:32 storage.log
-r--r--r-- 1 caf omen 112 Dec 14 04:32 sensitive-info.log
-r--r--r-- 1 caf omen 38K Dec 14 04:32 program.log
-r--r--r-- 1 caf omen 185K Dec 14 04:32 packaging.log
-r--r--r-- 1 caf omen 1.8K Dec 14 04:32 ifcfg.log
-r--r--r-- 1 caf omen 20K Dec 14 04:32 anaconda.log
-r--r--r-- 1 caf omen 351 Dec 14 04:32 anaconda-yum.conf
-r--r--r-- 1 caf omen 34K Dec 14 04:32 X.log
[caf@omen h]$ cat foo
[root@omen3 ~]# fpaste /o/tmp/h/*
WARNING: your paste size (812.2KiB) is very large and may be rejected by
the server. A pastebin is NOT a file hosting service!
Uploading (812.2KiB)...
Traceback (most recent call last):
File "/bin/fpaste", line 447, in
main()
File "/bin/fpaste", line 414, in main
[url, short_url] = paste(text, options)
File "/bin/fpaste", line 127, in paste
response = json.loads(f.read())
File "/usr/lib64/python2.7/json/__init__.py", line 338, in loads
return _default_decoder.decode(s)
File "/usr/lib64/python2.7/json/decoder.py", line 365, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib64/python2.7/json/decoder.py", line 383, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
It does appear fpaste is broken.
--
Chuck Forsberg WA7KGX 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: Criterion revision proposal: KDE default applications
On lau 14.des 2013 00:54, Adam Williamson wrote: That requires will on the part of the desktop SIGs, though. QA is not going to be responsible for this. My position is either the desktop SIGs fix their stuff, or we will have to change the criteria as I proposed, because what other choice do we have? We will remove everything non core/base related out of our criteria and assist the communities surrounding those products to come up with criteria ( as well as test cases maybe ) specifically tailored for those products but that's where our ( QA communities ) involvement with the output from WG's ends period. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 20 RC1 AMIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Fri, 13 Dec 2013 23:13:01 -0500 Matthew Miller escribió: > On Fri, Dec 13, 2013 at 10:05:05PM -0600, Dennis Gilmore wrote: > > > > Note, these are the GA images. > > > Hey Dennis, will the images going to mirrors be these or the ones > > > with the extra RC1.1 dot, like > > > "Fedora-x86_64-20-20131211.1-sda.qcow2"? > > The Images in RC1 and RC1.1 are exactly the same. the changes in the > > RC1.1 compose was just to respin the install tree making sure that > > none of the older libreoffice packages were in the tree. > > Right, sorry, I wasn't clear. I know that part, but I'm wondering > what the actual filename going to the mirrors will be. This is > important for the web site and short links. We do not change file names when composed. what they are in the RC is what they will be when shipped. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSrBvwAAoJEH7ltONmPFDR1wgP/2zX6H9Tvp8WEuiHBo5n1rLp N8sJSJ5VrtR26tqtCEI5DHaujOHjGTwEPMP/QZqXTomm6gQVg6/cgcalL8d8PV+r /3Cx2epQxX28/ln4xVLI+3PdMXVErl01hEXVnXmAbuwdToUhi1jiDmbDVcpnAUv7 ibwqBn6V3nbk4ThCbfu1Wy2zRHR0qAFo689dsum/mlZPpU7ZelwqcQ7iOimpHvL7 ZwQ38rG1oLJZ0EfW7oe97w8pksn8mCOXdB+DIA17IEMlMWao4cxQ8SAXNsfyyx7l jwFuPHKAlb0kmDLaqqVljpzx+J7Zibe0aIImbXQ5cDFyiC1ZmRwR9ed2P0SzIscJ hIL9CPPi0I0nd+dxlIlTGbqu9sRddRVl3O6p4RVsizrrTJ9zF4Ft/MOWBrShlSsP RnrqiFGR29hP9d/XGA+N0WRFeFfLdrxknrVtIfzV6e8kYgHvdeWh/yRt4WmZDJ8V 5kc84uBBxL/CFZWBrhNbnZmEkoH8qEyrzXkVp6q+ePsGBWROHSX3Gt4eu8TNFsoS AZtXSfg8tSZnash6nCdTqcEuA0Avc6RA00SaUNHplQlpN8D42MyvCgNeWZNUyZta +IwOll7skZUIcPvxgnnHpqyhEfJLP+UeYX0+2QPx9/YnupAyiMQDDTOErZCrZdzs ClvuHNedf0dQLC2kVSHj =UzA+ -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
