Re: Default partitioning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/23/2010 06:39 PM, Javier Prats wrote: Hello all, I was wondering if this is the correct place to discuss the default partitioning scheme after installation. If not, could someone please direct me to the correct place? It's as good a place as any. What is your concern? - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzFY8AACgkQeiVVYja6o6McJwCgkw9uJFtBJN0nDkNH41l+DPVu 3SwAoIpJopi6oV6omFRUu50ObdFPO6Gb =IaGL -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
Paul Wouters p...@xelerance.com writes: On Fri, 8 Oct 2010, Nathanael D. Noblet wrote: On 10/07/2010 10:58 PM, Paul Wouters wrote: One usage of yubikey I would like very much is as storage for the AES encryption key for disk encryption. I'd prefer the disk crypto key to not be on the disk at all, protected by just a passphrase. It would be nice to have it on a yubikey instead. I just ordered a yubikey for this express purpose, we have a product under development that has an encrypted partition that gets decrypted by a key on a USB thumbdrive - not the best... When I saw these I immediately thought I should see about getting them used to unlock encrypted partitions!... I'll keep you informed. Note that yubikeys are not (yet) usable for this. You cannot request the AES key from it (AFAIK), only an OTP. And the OTP can also not be used to unlock an AES key on the harddisk because it is different for each activation. The YubiKey with firmware 2.2 (latest) supports an challenge-response HMAC-SHA1 mode that probably can be used for this. You feed a pass phrase to the YubiKey, and it responds with a static string generated from the pass phrase using HMAC-SHA1. It will be the same output every time if the input is the same. The output would then be used as the encryption key. Of course, you still need to trust the software on your machine to not leak the HMAC-SHA1 output.. If anyone is trying something like this, I'm interested to hear about progress. Encrypting disks assisted with an external device is something I'd like to see. /Simon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
Maxim Burgerhout ma...@wzzrd.com writes: Hi, I am the maintainer for ykpers and libyubikey for Fedora. It's great to see Fedora starting to use these nifty devices! If there is anything I can do to help out and make the use of Yubikey's in the Fedora project into a success, just holler. Hi -- I likewise want to congratulate you on adding support for this to the Fedora infrastructure (and thanks Maxim for packaging work). I work for Yubico and if there are any questions or issues with the YubiKey that you can encounter, please let me know and can accelerate an answer. I have re-read this thread, and from what I can tell, you got all current questions resolved, but if I missed something, please let me know. /Simon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101025 changes
Compose started at Mon Oct 25 08:15:05 UTC 2010 Broken deps for x86_64 -- PyKDE4-4.5.2-5.fc15.x86_64 requires PyQt4 = 0:4.8n ScientificPython-2.8-11.fc14.x86_64 requires libmpi.so.0()(64bit) ScientificPython-2.8-11.fc14.x86_64 requires libopen-rte.so.0()(64bit) ScientificPython-2.8-11.fc14.x86_64 requires libopen-pal.so.0()(64bit) 1:anjuta-2.31.90.0-3.fc15.i686 requires libvala-0.10.so.0 1:anjuta-2.31.90.0-3.fc15.x86_64 requires libvala-0.10.so.0()(64bit) avahi-sharp-0.6.28-1.fc15.x86_64 requires mono(Mono.Posix) = 0:1.0.5000.0 avahi-sharp-0.6.28-1.fc15.x86_64 requires mono(System) = 0:1.0.5000.0 avahi-sharp-0.6.28-1.fc15.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 avahi-ui-sharp-0.6.28-1.fc15.x86_64 requires mono(Mono.Posix) = 0:1.0.5000.0 avahi-ui-sharp-0.6.28-1.fc15.x86_64 requires mono(System) = 0:1.0.5000.0 avahi-ui-sharp-0.6.28-1.fc15.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 avahi-ui-sharp-0.6.28-1.fc15.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 banshee-1.8.0-8.fc15.i686 requires mono(atk-sharp) = 0:2.12.0.0 banshee-1.8.0-8.fc15.i686 requires mono(gconf-sharp) = 0:2.24.0.0 banshee-1.8.0-8.fc15.i686 requires mono(gtk-sharp) = 0:2.12.0.0 banshee-1.8.0-8.fc15.i686 requires mono(Mono.Addins) = 0:0.5.0.0 banshee-1.8.0-8.fc15.i686 requires mono(Mono.Addins.Gui) = 0:0.5.0.0 banshee-1.8.0-8.fc15.i686 requires mono(pango-sharp) = 0:2.12.0.0 banshee-1.8.0-8.fc15.i686 requires mono(gdk-sharp) = 0:2.12.0.0 banshee-1.8.0-8.fc15.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 banshee-1.8.0-8.fc15.x86_64 requires mono(atk-sharp) = 0:2.12.0.0 banshee-1.8.0-8.fc15.x86_64 requires mono(gconf-sharp) = 0:2.24.0.0 banshee-1.8.0-8.fc15.x86_64 requires mono(Mono.Addins) = 0:0.5.0.0 banshee-1.8.0-8.fc15.x86_64 requires mono(Mono.Addins.Gui) = 0:0.5.0.0 banshee-1.8.0-8.fc15.x86_64 requires mono(pango-sharp) = 0:2.12.0.0 banshee-1.8.0-8.fc15.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 banshee-community-extensions-1.8.0-2.fc15.x86_64 requires mono(pango-sharp) = 0:2.12.0.0 banshee-community-extensions-1.8.0-2.fc15.x86_64 requires mono(gconf-sharp) = 0:2.24.0.0 banshee-community-extensions-1.8.0-2.fc15.x86_64 requires mono(System) = 0:1.0.5000.0 banshee-community-extensions-1.8.0-2.fc15.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 banshee-community-extensions-1.8.0-2.fc15.x86_64 requires mono(Mono.Addins) = 0:0.5.0.0 banshee-community-extensions-1.8.0-2.fc15.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 banshee-community-extensions-1.8.0-2.fc15.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 bareftp-0.3.2-1.fc14.x86_64 requires mono(gconf-sharp) = 0:2.24.0.0 bareftp-0.3.2-1.fc14.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 bareftp-0.3.2-1.fc14.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 bareftp-0.3.2-1.fc14.x86_64 requires mono(gnome-vfs-sharp) = 0:2.24.0.0 bareftp-0.3.2-1.fc14.x86_64 requires mono(gnome-sharp) = 0:2.24.0.0 beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) beagle-evolution-0.3.9-19.fc14.x86_64 requires mono(gconf-sharp) = 0:2.24.0.0 beagle-gnome-0.3.9-19.fc14.x86_64 requires mono(gconf-sharp) = 0:2.24.0.0 beagle-gnome-0.3.9-19.fc14.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 beagle-gnome-0.3.9-19.fc14.x86_64 requires mono(glade-sharp) = 0:2.12.0.0 beagle-gnome-0.3.9-19.fc14.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 beagle-gnome-0.3.9-19.fc14.x86_64 requires mono(gnome-vfs-sharp) = 0:2.24.0.0 beagle-gnome-0.3.9-19.fc14.x86_64 requires mono(pango-sharp) = 0:2.12.0.0 beagle-gnome-0.3.9-19.fc14.x86_64 requires mono(gnome-sharp) = 0:2.24.0.0 chronojump-0.8.14-1.fc12.x86_64 requires mono(glade-sharp) = 0:2.12.0.0 chronojump-0.8.14-1.fc12.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 chronojump-0.8.14-1.fc12.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 chronojump-0.8.14-1.fc12.x86_64 requires mono(pango-sharp) = 0:2.12.0.0 clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) 0:1.3.0 db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dbus-sharp-0.63-14.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 dh-make-0.55-2.fc15.noarch requires debhelper eclipse-checkstyle-5.1.0-1.fc14.noarch requires checkstyle = 0:5.1 empathy-2.91.0-2.fc15.x86_64 requires libfolks-telepathy.so.0()(64bit) empathy-2.91.0-2.fc15.x86_64 requires libfolks.so.0()(64bit)
Re: F-14 Branched report: 20101024 changes
On 10/24/2010 01:25 PM, Garrett Holmstrom wrote: qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) rakudo-0.0.2010.08_2.7.0-1.fc14.x86_64 requires libparrot.so.2.7.0()(64bit) Any chance these are going to be fixed before release? I looked at qtgpsc, but that's unlikely to be fixed sanely unless: A) gpsd is regressed to an older version and all other dependencies are hacked up to use it. B) qtgpsc is updated to the current branch, which requires gpsd to be updated to SVN and all other dependencies are hacked up to use it. I actually got pretty far down B (on my local system) before realizing it was too intrusive and too late in the cycle to make those changes. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F15 Feature - online Ex4 defragmentatnion (Re: e4defrag support?)
Hi, 2010/10/6 Eric Sandeen sand...@redhat.com: OK gang, it's in e2fsprogs-1.41.12-6.fc15 you have to invoke it with -test options to make it go ;) Word of warning, it's not had a lot of attention, and the whole design could change in the future, but it's something to play with :) -Eric Would it make sense to propose online ext4 defragmentation as a Fedora 15 feature? Rationale - more people would point their attention to this feature - more people would test it. Contingency Plan: None. Just delete feature from features page :) I'm not sure how it is in other distros, but it's probably not very popular feature. Any suggestions? Kind regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libpoppler soname bump in rawhide
Hi, I plan to rebase poppler in rawhide to poppler-0.15.1. There are some API changes and 1 soname bump of libpoppler.so.8 to libpoppler.so.9. API changes mostly involve addition of new functions (see below). You can test it against your package with this scratch-build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2552287 I'll ask release engineers for chain-build at the beginning of the next week. Regards Marek Changes: cpp/poppler-document.h: - new public functions in class document: get_pdf_id(), load_from_raw_data() Dict.h: - new public function in class Dict: getXRef() - new private member in class Dict: GBool sorted Form.h: - new public functions in class FormWidget: getPartialName(), getMappingName(), getFullyQualifiedName() - new protected members in class FormWidget: GooString *partialName, GooString *mappingName, GooString *fullyQualifiedName Gfx.h: - API change of private functions in class Gfx: gouraudFillTriangle() and fillPatch() - new private function in class Gfx: gouraudFillTriangle() GfxState.h: - new public functions in class GfxGouraudTriangleShading: isParameterized(), getParameterDomainMin(), getParameterDomainMax(), getTriangle(), getParameterizedColor() - new struct in struct GfxPatch struct ColorValue - type change change in struct GfxPatch: GfxColor color[2][2] - ColorValue color[2][2] - new public functions in class GfxPatchMeshShading: isParameterized(), getParameterDomainMin(), getParameterDomainMax(), getParameterizedColor() - new public functions in class GfxSubpath: setX(), setY() - new sub class ReusablePathIterator in class GfxState class ReusablePathIterator - new public function in class GfxState: getReusablePath() glib/poppler-document.h: - new public functions in glib/poppler-document.h: poppler_document_get_id(), poppler_document_get_pdf_version_string(), poppler_document_get_pdf_version(), poppler_document_get_title(), poppler_document_get_author(), poppler_document_get_subject(), poppler_document_get_keywords(), poppler_document_get_creator(), poppler_document_get_producer(), poppler_document_get_creation_date(), poppler_document_get_modification_date(), poppler_document_is_linearized(), poppler_document_get_page_layout(), poppler_document_get_page_mode(), poppler_document_get_permissions(), poppler_document_get_metadata() glib/poppler-enums.h: - new public function in glib/poppler-enums.h: poppler_print_flags_get_type () - new macro in glib/poppler-enums.h: POPPLER_TYPE_PRINT_FLAGS () glib/poppler-form-field.h: - new public functions in glib/poppler-form-field.h: poppler_form_field_get_partial_name(), poppler_form_field_get_mapping_name(), poppler_form_field_get_name glib/poppler.h: - new enum in glib/poppler.h: PopplerPrintFlags glib/poppler-page.h: - new public functions in glib/poppler-page.h: poppler_page_render_for_printing_with_options (), poppler_page_get_selected_region () PDFDoc.h: - new public function in class PDFDoc: getID() PSOutputDev.h: - private member removed from class PSOutputDev: int savedRender qt4/poppler-qt4.h: - new public function in class Document: getPdfId() - new public function in class PSConverter: void setPageConvertedCallback(void (* callback)(int page, void *payload), void *payload); SplashOutputDev.h: - new public function in class SplashOutputDev: updateRender() - private member removed from class SplashOutputDev: int savedRender ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
Hello: Jesse Keating wrote, at 10/06/2010 07:27 AM +9:00: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As you might be aware, there was a period of roughly two weeks where a gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and Fedora 15. Items built with this could have undefined behavior, which could lead to data corruption. Unfortunately I'm told that it is impossible to look at a generated binary and detect whether or not the binary would be effected by this bug. The only reliable way to tell would be to re-create the build environment exactly, except replace GCC with one that will detect the error scenario and print something. As this is a significant amount of work, I decided instead to just rebuild the potential problem builds. Would you update the current status of this issue? For example I checked the current status of ruby-gnome2 (because I was going to upgrade ruby-gnome2 on F-14) and - still the latest ruby-gnome2 on F-14 is ruby-gnome2-0.90.2-1.fc14 - this one uses the problematic gcc - while it seemed that ruby-gnome2 was rebuilt against newer gcc (with EVR: ruby-gnome2-0.90.2-1.fc14.1), this new ruby-gnome2 was never pushed into dist-f14 or submitted on bodhi. So are there any list file which suggests what packages still need repush (after rebuild or update) for this gcc issue? Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - online Ex4 defragmentatnion (Re: e4defrag support?)
Michał Piotrowski wrote: Hi, 2010/10/6 Eric Sandeen sand...@redhat.com: OK gang, it's in e2fsprogs-1.41.12-6.fc15 you have to invoke it with -test options to make it go ;) Word of warning, it's not had a lot of attention, and the whole design could change in the future, but it's something to play with :) -Eric Would it make sense to propose online ext4 defragmentation as a Fedora 15 feature? At this time, I don't think I'll be able to commit to that work. I'd usually sign up a feature for Fedora when it is reaching completion upstream, rather than using Fedora as a driver for upstream priorities... This might change but I'm not going to commit to it today, sorry. -Eric Rationale - more people would point their attention to this feature - more people would test it. Contingency Plan: None. Just delete feature from features page :) I'm not sure how it is in other distros, but it's probably not very popular feature. Any suggestions? Kind regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20101025 changes
Compose started at Mon Oct 25 13:15:08 UTC 2010 Broken deps for x86_64 -- qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) rakudo-0.0.2010.08_2.7.0-1.fc14.x86_64 requires libparrot.so.2.7.0()(64bit) Broken deps for i386 -- qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 rakudo-0.0.2010.08_2.7.0-1.fc14.i686 requires libparrot.so.2.7.0 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - online Ex4 defragmentatnion (Re: e4defrag support?)
W dniu 25 października 2010 17:19 użytkownik Eric Sandeen sand...@redhat.com napisał: Michał Piotrowski wrote: Hi, 2010/10/6 Eric Sandeen sand...@redhat.com: OK gang, it's in e2fsprogs-1.41.12-6.fc15 you have to invoke it with -test options to make it go ;) Word of warning, it's not had a lot of attention, and the whole design could change in the future, but it's something to play with :) -Eric Would it make sense to propose online ext4 defragmentation as a Fedora 15 feature? At this time, I don't think I'll be able to commit to that work. I'd usually sign up a feature for Fedora when it is reaching completion upstream, rather than using Fedora as a driver for upstream priorities... This might change but I'm not going to commit to it today, sorry. I did not mean burdening your in bug reports with the annotation please fix this bug before F15 :) All bug reports should be sent to NEC's e4defrag developers. It seems to me that they are the most appropriate people to fix e4defrag bugs (of course if they still want to maintain this project - it is hard to deduce anything from git log - only five commits after merge - one from author). -Eric Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
xz-5.0.0 in rawhide + soname bump
Hi! xz-5.0.0 is now released and soname is now bumped to 5.0.0 in rawhide. The most important changes are: * The compression settings associated with the preset levels -0 ... -9 have been changed. --extreme was changed a little too. It is now less likely to make compression worse, but with some files the new --extreme may compress slightly worse than the old --extreme. * The major soname has been bumped to 5.0.0. liblzma API and ABI are now stable, so the need to recompile programs linking against liblzma shouldn't arise soon. For more news and differences between xz-4.999.9beta and 5.0.0 please read the NEWS file in the main package documentation. The change of compression level presets may cause deltarpm to print md5 mismatch of result when rebuilding drpms and downloading full rpms. This message will stop occuring as soon as the original package will be built with the new xz-5.0.0. Cheers, Jindrich -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ Kdo víno má a nepije, kdo hrozny má a nejí je, kdo ženu má a nelíbá, kdo zábavě se vyhýbá, na toho vemte bič a hůl, to není člověk, to je vůl. --- Jan Werich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 557485] Extra provides need trimming
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=557485 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-SOAP-Lite-0.710.07-3.e ||l5 Resolution||ERRATA Last Closed||2010-10-25 12:38:29 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 557485] Extra provides need trimming
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=557485 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2010-10-25 12:38:23 EDT --- perl-SOAP-Lite-0.710.07-3.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Fedora 14 FINAL Go/No-Go Meeting Tuesday, October 26, 2010 @ 21:00 UTC
Join us on irc.freenode.net #fedora-meeting for this important meeting. Tuesday October 26, 2010 @ 21:00 UTC (17:00 EDT/14:00 PDT) Before each public release Development, QA, and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the: Go/No-Go Meeting. Verifying that the Release criteria are met is the responsibility of the QA Team. For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime keep an eye on the Fedora 14 Final Blocker list and help us finish filling out the test result matrices. https://bugzilla.redhat.com/showdependencytree.cgi?id=F14Blockerhide_resolved=1 http://fedoraproject.org/wiki/Category:Fedora_14_Final_RC_Test_Results John ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i686/x86_64 dual install media
On Sun, 2010-10-24 at 10:45 -0400, Mark Bidewell wrote: Sorry if this has been discussed, but has there every been discussion of a dual 32/64-bit install media? I realize that the default package selection would be reduced but with a high speed connection it shouldn't be too big of an issue. Having a single ISO for both my 64-bit desktop and 32-bit laptop would be quite nice. It wouldn't make sense to make everyone download the default package set twice, when only a relatively small amount of people actually need to, and the extra work involved in downloading and burning two separate ISOs is so tiny. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-14 Branched report: 20101024 changes
On Sun, 2010-10-24 at 12:25 -0500, Garrett Holmstrom wrote: On 10/24/2010 10:17, Branched Report wrote: Broken deps for x86_64 -- qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) rakudo-0.0.2010.08_2.7.0-1.fc14.x86_64 requires libparrot.so.2.7.0()(64bit) Any chance these are going to be fixed before release? It's very unlikely. Any change now requires us to slip the release; RC1 is looking good in validation testing and may well wind up being shipped as the final release (have we *ever* shipped RC1 before? Is this some sort of record? :) Two dependency issues in the entire package set is way, way fewer than we've shipped with before, IIRC. We made much more of an effort to clear them up for this release than we did previously. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Auto Mounting in Fedora F14 TC6
On Sun, 2010-10-24 at 19:31 -0700, Kevin Higgins wrote: I can not tell you exactly which day but approximately Oct 18th auto mount for data DVD's worked and now it does not . Did a clean install to test again. with same result. Blank DVD's auto mount Movies and data DVD's do not auto mount. nor can I manually mount. the drive shows up in nautilus but when ever movie or data dvd is placed in drive it disappears. Checked all settings in File Management Preferences / Media and all is correct, even installed gconf and checked all settings again; and all is correct as far as I can see; just will not auto mount any more. I am not sure if this would be considered a blocker or not, but shall see what everybody else thinks. https://fedoraproject.org/wiki/Test_Results:Fedora_14_Final_RC1_Desktop has 'pass' results on the auto-mount test on three different desktops from three different testers, so apparently not everyone is seeing this. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xz-5.0.0 in rawhide + soname bump
On Mon, 25 Oct 2010 18:35:54 +0200 Jindrich Novy jn...@redhat.com wrote: Hi! xz-5.0.0 is now released and soname is now bumped to 5.0.0 in rawhide. The most important changes are: * The compression settings associated with the preset levels -0 ... -9 have been changed. --extreme was changed a little too. It is now less likely to make compression worse, but with some files the new --extreme may compress slightly worse than the old --extreme. * The major soname has been bumped to 5.0.0. liblzma API and ABI are now stable, so the need to recompile programs linking against liblzma shouldn't arise soon. This has broken the Rawhide buildroot: DEBUG backend.py:656: /usr/bin/yum --installroot /var/lib/mock/dist-f15-build-911517-134161/root/ groupinstall build DEBUG util.py:294: Executing command: /usr/bin/yum --installroot /var/lib/mock/dist-f15-build-911517-134161/root/ groupinstall build DEBUG util.py:260: Error: Package: rpm-libs-4.8.1-5.fc15.x86_64 (build) DEBUG util.py:260: Requires: liblzma.so.0()(64bit) DEBUG util.py:260: Error: Package: elfutils-libs-0.149-2.fc15.x86_64 (build) DEBUG util.py:260: Requires: liblzma.so.0()(64bit) DEBUG util.py:260: Error: Package: rpm-4.8.1-5.fc15.x86_64 (build) DEBUG util.py:260: Requires: liblzma.so.0()(64bit) DEBUG util.py:260: Error: Package: rpm-build-4.8.1-5.fc15.x86_64 (build) DEBUG util.py:260: Requires: liblzma.so.0()(64bit) Given that the ABI hasn't actually changed since the previous build, a short term fix could be to build a mini liblzma.so.0 that just links to liblzma.so.5, along the same lines as the mini libcurl built for the last soname bump of that library (Mon Aug 11 2008, curl 7.18.2-4). The current build needs untagging anyway. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xz-5.0.0 in rawhide + soname bump
On Mon, 25 Oct 2010 19:56:27 +0100 Paul Howarth p...@city-fan.org wrote: On Mon, 25 Oct 2010 18:35:54 +0200 Jindrich Novy jn...@redhat.com wrote: Hi! xz-5.0.0 is now released and soname is now bumped to 5.0.0 in rawhide. The most important changes are: * The compression settings associated with the preset levels -0 ... -9 have been changed. --extreme was changed a little too. It is now less likely to make compression worse, but with some files the new --extreme may compress slightly worse than the old --extreme. * The major soname has been bumped to 5.0.0. liblzma API and ABI are now stable, so the need to recompile programs linking against liblzma shouldn't arise soon. This has broken the Rawhide buildroot: DEBUG backend.py:656: /usr/bin/yum --installroot /var/lib/mock/dist-f15-build-911517-134161/root/ groupinstall build DEBUG util.py:294: Executing command: /usr/bin/yum --installroot /var/lib/mock/dist-f15-build-911517-134161/root/ groupinstall build DEBUG util.py:260: Error: Package: rpm-libs-4.8.1-5.fc15.x86_64 (build) DEBUG util.py:260: Requires: liblzma.so.0()(64bit) DEBUG util.py:260: Error: Package: elfutils-libs-0.149-2.fc15.x86_64 (build) DEBUG util.py:260: Requires: liblzma.so.0()(64bit) DEBUG util.py:260: Error: Package: rpm-4.8.1-5.fc15.x86_64 (build) DEBUG util.py:260: Requires: liblzma.so.0()(64bit) DEBUG util.py:260: Error: Package: rpm-build-4.8.1-5.fc15.x86_64 (build) DEBUG util.py:260: Requires: liblzma.so.0()(64bit) Given that the ABI hasn't actually changed since the previous build, a short term fix could be to build a mini liblzma.so.0 that just links to liblzma.so.5, along the same lines as the mini libcurl built for the last soname bump of that library (Mon Aug 11 2008, curl 7.18.2-4). The current build needs untagging anyway. I've untagged it and mailed Jindrich. Updating a rpm dep is not easy. You will need to rebuild rpm static, or make a compat package, or some other trick. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
policycoreutils needs cairo.
I did a minimal install yesterday, and was surprised to find that cairo, and a bunch of X libs were still installed. The dependancy chain that pulled them in looks like this.. policycoreutils - dbus-glib - gobject-introspection - fontconfig - cairo Could any part of that chain have its dependancies relaxed ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i686/x86_64 dual install media
On 25.10.2010 20:49, Adam Williamson wrote: On Sun, 2010-10-24 at 10:45 -0400, Mark Bidewell wrote: Sorry if this has been discussed, but has there every been discussion of a dual 32/64-bit install media? I realize that the default package selection would be reduced but with a high speed connection it shouldn't be too big of an issue. Having a single ISO for both my 64-bit desktop and 32-bit laptop would be quite nice. It wouldn't make sense to make everyone download the default package set twice, when only a relatively small amount of people actually need to, and the extra work involved in downloading and burning two separate ISOs is so tiny. But a combo x86-32/x86-64 install media OTOH would be very interesting for magazines that want to ship Fedora on a enclosed DVD, as that's cheaper than two and makes way more readers happy than a x86-32 only DVD. Ohh, and a combo install media might be interesting as hand out for fairs and conferences, too. Just my 2¢. CU knurd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i686/x86_64 dual install media
Thorsten Leemhuis wrote: But a combo x86-32/x86-64 install media OTOH would be very interesting for magazines that want to ship Fedora on a enclosed DVD, as that's cheaper than two and makes way more readers happy than a x86-32 only DVD. Ohh, and a combo install media might be interesting as hand out for fairs and conferences, too. What I would like to see is a regular net install CD (not b.f.o) that is capable of installing either x86_64 or i686. I'm not sure if it's worth the work, though... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xz-5.0.0 in rawhide + soname bump
On Mon, 25 Oct 2010 12:59:22 -0600 Kevin Fenzi ke...@scrye.com wrote: On Mon, 25 Oct 2010 19:56:27 +0100 Paul Howarth p...@city-fan.org wrote: On Mon, 25 Oct 2010 18:35:54 +0200 Jindrich Novy jn...@redhat.com wrote: Hi! xz-5.0.0 is now released and soname is now bumped to 5.0.0 in rawhide. The most important changes are: * The compression settings associated with the preset levels -0 ... -9 have been changed. --extreme was changed a little too. It is now less likely to make compression worse, but with some files the new --extreme may compress slightly worse than the old --extreme. * The major soname has been bumped to 5.0.0. liblzma API and ABI are now stable, so the need to recompile programs linking against liblzma shouldn't arise soon. This has broken the Rawhide buildroot: DEBUG backend.py:656: /usr/bin/yum --installroot /var/lib/mock/dist-f15-build-911517-134161/root/ groupinstall build DEBUG util.py:294: Executing command: /usr/bin/yum --installroot /var/lib/mock/dist-f15-build-911517-134161/root/ groupinstall build DEBUG util.py:260: Error: Package: rpm-libs-4.8.1-5.fc15.x86_64 (build) DEBUG util.py:260: Requires: liblzma.so.0()(64bit) DEBUG util.py:260: Error: Package: elfutils-libs-0.149-2.fc15.x86_64 (build) DEBUG util.py:260: Requires: liblzma.so.0()(64bit) DEBUG util.py:260: Error: Package: rpm-4.8.1-5.fc15.x86_64 (build) DEBUG util.py:260: Requires: liblzma.so.0()(64bit) DEBUG util.py:260: Error: Package: rpm-build-4.8.1-5.fc15.x86_64 (build) DEBUG util.py:260: Requires: liblzma.so.0()(64bit) Given that the ABI hasn't actually changed since the previous build, a short term fix could be to build a mini liblzma.so.0 that just links to liblzma.so.5, along the same lines as the mini libcurl built for the last soname bump of that library (Mon Aug 11 2008, curl 7.18.2-4). The current build needs untagging anyway. I've untagged it and mailed Jindrich. Updating a rpm dep is not easy. You will need to rebuild rpm static, or make a compat package, or some other trick. ;) The mini-library hack does the trick by proving both sonames (effectively the new one and the compat one) in the same package. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: policycoreutils needs cairo.
On Mon, Oct 25, 2010 at 3:33 PM, Dave Jones da...@redhat.com wrote: I did a minimal install yesterday, and was surprised to find that cairo, and a bunch of X libs were still installed. The dependancy chain that pulled them in looks like this.. policycoreutils - dbus-glib - gobject-introspection - fontconfig - cairo This is fixed in F15 in multiple ways (restorecond is split out of policycoreutils, and dbus-glib no longer deps on gobject-introspection, and g-i no longer depends on cairo) Could any part of that chain have its dependancies relaxed ? Unfortunately we didn't notice this dependency until pretty late in F14...I'm not sure what can be done reasonably at this point, since all of these packages are critical path. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: policycoreutils needs cairo.
On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters walt...@verbum.org wrote:
Unfortunately we didn't notice this dependency until pretty late in
F14...I'm not sure what can be done reasonably at this point, since
all of these packages are critical path.
Though I will say that if this was determined to be a blocker, here's
a really safe minimal fix:
From ebec17c813c860964af9e1d313c3ec97171aeacb Mon Sep 17 00:00:00 2001
From: Colin Walters walt...@verbum.org
Date: Mon, 25 Oct 2010 17:45:05 -0400
Subject: [PATCH] - Move test libraries into -devel; they pull in a cairo dependency,
which is unnecessary.
---
gobject-introspection.spec | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/gobject-introspection.spec b/gobject-introspection.spec
index 2ec89d5..8e59067 100644
--- a/gobject-introspection.spec
+++ b/gobject-introspection.spec
@@ -3,7 +3,7 @@
Name: gobject-introspection
Version:0.9.3
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary:Introspection system for GObject-based libraries
Group: Development/Libraries
@@ -73,13 +73,15 @@ find $RPM_BUILD_ROOT -type f -name *.a -exec rm -f {} ';'
%defattr(-,root,root,-)
%doc COPYING
-%{_libdir}/lib*.so.*
+%{_libdir}/libgirepository-1.0.so.*
%dir %{_libdir}/girepository-1.0
%{_libdir}/girepository-1.0/*.typelib
%files devel
%defattr(-,root,root)
%{_libdir}/lib*.so
+%{_libdir}/libgirepository-everything-1.0.so.*
+%{_libdir}/libgirepository-gimarshallingtests-1.0.so.*
%dir %{_libdir}/gobject-introspection
%{_libdir}/gobject-introspection/*
%{_libdir}/pkgconfig/*
@@ -94,6 +96,10 @@ find $RPM_BUILD_ROOT -type f -name *.a -exec rm -f {} ';'
#%{_datadir}/gtk-doc/html/gi/*
%changelog
+* Mon Oct 25 2010 Colin Walters walt...@verbum.org - 0.9.3-2
+- Move test libraries into -devel; they pull in a cairo dependency,
+ which is unnecessary.
+
* Tue Aug 3 2010 Matthias Clasen mcla...@redhat.com - 0.9.3-1
- Update to 0.9.3
--
1.7.3.1
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: policycoreutils needs cairo.
Colin Walters (walt...@verbum.org) said: On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters walt...@verbum.org wrote: Unfortunately we didn't notice this dependency until pretty late in F14...I'm not sure what can be done reasonably at this point, since all of these packages are critical path. Though I will say that if this was determined to be a blocker, here's a really safe minimal fix: AFAIK, there's nothing on the release criteria which make this a blocker. You can submit an update whenever for it, of course. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Mounting an encrypted volume presents the volume to all users on a machine
Hi, I'm concerned about the default behaviour of mounting encrypted volumes. The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume. What I am concerned about is that the volume is mounted for _every_ user on the system to see. I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085 I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box. Thoughts? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 10/25/2010 04:28 PM, nodata wrote: Hi, I'm concerned about the default behaviour of mounting encrypted volumes. The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume. What I am concerned about is that the volume is mounted for _every_ user on the system to see. I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085 I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box. Wouldn't they be restricted based on the contents of the encrypted volume? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 26/10/10 00:31, Nathanael D. Noblet wrote: On 10/25/2010 04:28 PM, nodata wrote: Hi, I'm concerned about the default behaviour of mounting encrypted volumes. The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume. What I am concerned about is that the volume is mounted for _every_ user on the system to see. I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085 I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box. Wouldn't they be restricted based on the contents of the encrypted volume? What do you mean? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 26/10/10 00:31, Nathanael D. Noblet wrote: On 10/25/2010 04:28 PM, nodata wrote: Hi, I'm concerned about the default behaviour of mounting encrypted volumes. The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume. What I am concerned about is that the volume is mounted for _every_ user on the system to see. I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085 I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box. Wouldn't they be restricted based on the contents of the encrypted volume? Yes. Once the volume is mounted it will be treated with normal UNIX permissions. So you would have to create a sub-directory on the volume where the permissions were strict and create files under that. My point is that if the disk is encrypted, and the user knows the passphrase to access files on the device, then it doesn't make sense to let everyone else see what's on the device as well: it only make sense to decrypt the device to the user who knows the passphrase. There's an argument that other people will want to see what's on the device too. That's fine: the user can opt-in to that. But secure by default should be what we're aiming at. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/25/10 8:09 AM, Mamoru Tasaka wrote: Hello: Jesse Keating wrote, at 10/06/2010 07:27 AM +9:00: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As you might be aware, there was a period of roughly two weeks where a gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and Fedora 15. Items built with this could have undefined behavior, which could lead to data corruption. Unfortunately I'm told that it is impossible to look at a generated binary and detect whether or not the binary would be effected by this bug. The only reliable way to tell would be to re-create the build environment exactly, except replace GCC with one that will detect the error scenario and print something. As this is a significant amount of work, I decided instead to just rebuild the potential problem builds. Would you update the current status of this issue? For example I checked the current status of ruby-gnome2 (because I was going to upgrade ruby-gnome2 on F-14) and - still the latest ruby-gnome2 on F-14 is ruby-gnome2-0.90.2-1.fc14 - this one uses the problematic gcc - while it seemed that ruby-gnome2 was rebuilt against newer gcc (with EVR: ruby-gnome2-0.90.2-1.fc14.1), this new ruby-gnome2 was never pushed into dist-f14 or submitted on bodhi. So are there any list file which suggests what packages still need repush (after rebuild or update) for this gcc issue? Regards, Mamoru Current status is that almost all the builds are done and in the proper location. There are a few stragglers, and you may have identified one. The effort was put on hold as we get Fedora 14 ready for release. Anything in F14 GA that could be effected will see a post-release update. As for ruby-gnome2, the build you have in updates-testing, if it goes stable, will suffice. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzGB7kACgkQ4v2HLvE71NXX/gCfasPcIg7JV9OchitCGWVMpRl7 dnwAoKZ1oUR/GUDotEgdo87EA7uwRHKU =V1qH -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 10/25/2010 04:40 PM, nodata wrote: Wouldn't they be restricted based on the contents of the encrypted volume? Yes. Once the volume is mounted it will be treated with normal UNIX permissions. So you would have to create a sub-directory on the volume where the permissions were strict and create files under that. My point is that if the disk is encrypted, and the user knows the passphrase to access files on the device, then it doesn't make sense to let everyone else see what's on the device as well: it only make sense to decrypt the device to the user who knows the passphrase. There's an argument that other people will want to see what's on the device too. That's fine: the user can opt-in to that. But secure by default should be what we're aiming at. I encrypt /home... So for my use case it doesn't make much sense. I guess I can see the case where you have some random storage that is encrypted, however I'm not sure how common this is, and file permissions keeps them at bay once mounted anyway. I guess if they could get root, once you decrypt they have access, but if they have root... you've got other problems. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: policycoreutils needs cairo.
On Mon, 2010-10-25 at 17:55 -0400, Bill Nottingham wrote: Colin Walters (walt...@verbum.org) said: On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters walt...@verbum.org wrote: Unfortunately we didn't notice this dependency until pretty late in F14...I'm not sure what can be done reasonably at this point, since all of these packages are critical path. Though I will say that if this was determined to be a blocker, here's a really safe minimal fix: AFAIK, there's nothing on the release criteria which make this a blocker. You can submit an update whenever for it, of course. It's worth pointing out that we're not religious about the criteria: we want to have criteria to cover each blocker issue, but that doesn't mean that no issue can ever be a blocker unless it meets the existing criteria. When we come across an issue that is widely agreed ought to be a blocker, but doesn't meet the existing criteria, we write a new criterion. :) Having said that, I don't think this seems serious enough to be a blocker, though obviously we'd like the minimal install to be as minimal as possible. Does it cause major problems for any spins? I doubt it, I expect most of them will have cairo for one reason or another anyway. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: policycoreutils needs cairo.
On Mon, Oct 25, 2010 at 11:52 PM, Adam Williamson awill...@redhat.com wrote: On Mon, 2010-10-25 at 17:55 -0400, Bill Nottingham wrote: Colin Walters (walt...@verbum.org) said: On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters walt...@verbum.org wrote: Unfortunately we didn't notice this dependency until pretty late in F14...I'm not sure what can be done reasonably at this point, since all of these packages are critical path. Though I will say that if this was determined to be a blocker, here's a really safe minimal fix: AFAIK, there's nothing on the release criteria which make this a blocker. You can submit an update whenever for it, of course. It's worth pointing out that we're not religious about the criteria: we want to have criteria to cover each blocker issue, but that doesn't mean that no issue can ever be a blocker unless it meets the existing criteria. When we come across an issue that is widely agreed ought to be a blocker, but doesn't meet the existing criteria, we write a new criterion. :) Having said that, I don't think this seems serious enough to be a blocker, though obviously we'd like the minimal install to be as minimal as possible. Does it cause major problems for any spins? I doubt it, I expect most of them will have cairo for one reason or another anyway. I wouldn't expect it to affect the usual spins on s.fp.o, but the image for EC2 might be as I would expect that to be aimed at Just Enough OS but then I'm not sure how stripped down they've tried to make it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: policycoreutils needs cairo.
Peter Robinson wrote: On Mon, Oct 25, 2010 at 11:52 PM, Adam Williamson awill...@redhat.com wrote: On Mon, 2010-10-25 at 17:55 -0400, Bill Nottingham wrote: Colin Walters (walt...@verbum.org) said: On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters walt...@verbum.org wrote: Unfortunately we didn't notice this dependency until pretty late in F14...I'm not sure what can be done reasonably at this point, since all of these packages are critical path. Though I will say that if this was determined to be a blocker, here's a really safe minimal fix: AFAIK, there's nothing on the release criteria which make this a blocker. You can submit an update whenever for it, of course. It's worth pointing out that we're not religious about the criteria: we want to have criteria to cover each blocker issue, but that doesn't mean that no issue can ever be a blocker unless it meets the existing criteria. When we come across an issue that is widely agreed ought to be a blocker, but doesn't meet the existing criteria, we write a new criterion. :) Having said that, I don't think this seems serious enough to be a blocker, though obviously we'd like the minimal install to be as minimal as possible. Does it cause major problems for any spins? I doubt it, I expect most of them will have cairo for one reason or another anyway. I wouldn't expect it to affect the usual spins on s.fp.o, but the image for EC2 might be as I would expect that to be aimed at Just Enough OS but then I'm not sure how stripped down they've tried to make it. While we (the Cloud SIG) are shooting for a very minimal EC2 image, last I heard we still planned to ship it with SELinux. But if that isn't the case then I'm pretty sure this will impact the size of the images we need to upload. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: policycoreutils needs cairo.
On Mon, Oct 25, 2010 at 15:52:38 -0700, Adam Williamson awill...@redhat.com wrote: Having said that, I don't think this seems serious enough to be a blocker, though obviously we'd like the minimal install to be as minimal as possible. Does it cause major problems for any spins? I doubt it, I expect most of them will have cairo for one reason or another anyway. At this point the spins ar all smaller than their target size. I expect that Desktop would have pulled this stuff in, in any case. So it wouldn't have saved us from the scramble to get it under size. For custom spins built from the release, an update should be sufficient. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, Oct 26, 2010 at 00:40:41 +0200, nodata l...@nodata.co.uk wrote: My point is that if the disk is encrypted, and the user knows the passphrase to access files on the device, then it doesn't make sense to let everyone else see what's on the device as well: it only make sense to decrypt the device to the user who knows the passphrase. The files aren't decrypted to people (at least not yet, but expect a law requiring people to replace their eyes with ones that respect DRM sometime in the future). Once the OS can access the files, you are relying on the OS' security. There's an argument that other people will want to see what's on the device too. That's fine: the user can opt-in to that. But secure by default should be what we're aiming at. When you mount the file you can attach selinux context to all of the files or set the uid and group ownership to allow the OS to restrict access to the files excepting a compromised system or the use doing something boenheaded. (selinux can make the latter hard to do). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
nodata wrote: Hi, I'm concerned about the default behaviour of mounting encrypted volumes. The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume. What I am concerned about is that the volume is mounted for _every_ user on the system to see. I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085 I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box. Thoughts? If you want something closer to per-file encryption, try out ecryptfs. http://ecryptfs.sourceforge.net/ecryptfs-faq.html#compare -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADS UP: KDE/Qt update intentions in Fedora 13 (RFC)
On Sun, 24 Oct 2010 21:24:30 +0300 Kalev Lember ka...@smartlink.ee wrote: On 10/20/2010 03:02 PM, Jaroslav Reznik wrote: The question is (we agreed on KDE SIG meeting yesterday) - should we update Qt to 4.7 too or build KDE stack with current 4.6 series? As there are a few Qt packages outside of KDE SIG/Qt maintainers scope, we'd like to hear any objections against update - bugs we can fix etc. Qt 4.7 is quite well tested, thanks to work on Fedora 14 (Qt 4.7 is already included) and a lot of users are actually using this combination in Fedora 13. KDE is pretty much self contained, whereas a Qt upgrade affects a much larger number of packages. I don't think updating Qt to a new major version in a stable Fedora release is a good idea; it just causes too much churn. ...snip... I agree with Kalev here. Qt upgrade in a stable release is to be avoided unless there's some severe bug or security issue that can't be backported. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADS UP: KDE/Qt update intentions in Fedora 13 (RFC)
2010/10/25 Kevin Fenzi ke...@scrye.com On Sun, 24 Oct 2010 21:24:30 +0300 Kalev Lember ka...@smartlink.ee wrote: On 10/20/2010 03:02 PM, Jaroslav Reznik wrote: The question is (we agreed on KDE SIG meeting yesterday) - should we update Qt to 4.7 too or build KDE stack with current 4.6 series? As there are a few Qt packages outside of KDE SIG/Qt maintainers scope, we'd like to hear any objections against update - bugs we can fix etc. Qt 4.7 is quite well tested, thanks to work on Fedora 14 (Qt 4.7 is already included) and a lot of users are actually using this combination in Fedora 13. KDE is pretty much self contained, whereas a Qt upgrade affects a much larger number of packages. I don't think updating Qt to a new major version in a stable Fedora release is a good idea; it just causes too much churn. ...snip... I agree with Kalev here. Qt upgrade in a stable release is to be avoided unless there's some severe bug or security issue that can't be backported. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I have KDE 4.5.2 in my Fedora 13 wich as far as I understand uses the last version of Qt, the computer is working Flawlessly :D -- -Manuel Escudero- Linux User #509052 @GWave: jmlev...@googlewave.com @Blogger: http://www.blogxenode.tk/ (Xenode Systems Blog) PGP/GnuPG: DAE3 82E9 D68E 7AE4 ED31 1F8F 4AF4 D00C 50E7 ABC6 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, 2010-10-26 at 00:28 +0200, nodata wrote: Hi, I'm concerned about the default behaviour of mounting encrypted volumes. The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume. What I am concerned about is that the volume is mounted for _every_ user on the system to see. I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085 I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box. Thoughts? I'd think you mixed the concept of volume encryption and permission. Once you supply the pass for the encrypted volume, it means that you grant the right to OS to mount this volume. Then the OS is in charge of permission settings. OS doesn't care about if it is encrypted or not, it only knows some volume wants to be mounted and it sets permission as the default schema. Qiang -- Qiang Li HuBei Polytechnic Institute No. 17 YuQuan Road XiaoGan HuBei 432100 China E-mail: liqi...@hbvtc.edu.cn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 14 FINAL Go/No-Go Meeting Tuesday, October 26, 2010 @ 21:00 UTC
Join us on irc.freenode.net #fedora-meeting for this important meeting. Tuesday October 26, 2010 @ 21:00 UTC (17:00 EDT/14:00 PDT) Before each public release Development, QA, and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the: Go/No-Go Meeting. Verifying that the Release criteria are met is the responsibility of the QA Team. For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime keep an eye on the Fedora 14 Final Blocker list and help us finish filling out the test result matrices. https://bugzilla.redhat.com/showdependencytree.cgi?id=F14Blockerhide_resolved=1 http://fedoraproject.org/wiki/Category:Fedora_14_Final_RC_Test_Results John ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
