Re: F-14 updates hosed?
On Fri, 29 Oct 2010 11:26:15 +1100, Bojan wrote: Not sure if I'm imagining things, but it looks as if those have been hosed. For example: http://download.fedora.redhat.com/pub/fedora/linux/updates/14/x86_64/ Any ideas? During the entire F-14 Branched development period, the updates repo has been empty. Stable test updates have been pushed to the development/14 repo. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
On Thu, 28 Oct 2010, Jason L Tibbitts III wrote: JN == Joe Nall j...@nall.com writes: JN On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote: More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden capabilities are present on a binary? 'ls' doesn't mention anything. JN getcap Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages. I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it. Yup, rpm 4.7.0 was the first one to support file capabilities. It's use is tracked with rpmlib(FileCaps) dependency, making packages utilizing the feature uninstallable with any older rpm versions, and of course trying to build such packages on older versions will barf out with a errors. It should be possible to have EPEL define a macro that turns %caps(foo) into an %attr() with SUID bit set, but blindly enabling SUID bits might not be such a hot idea... - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building boo against mono-2.8 problem
On Thu, 28 Oct 2010 23:34:38 +0100, Paul F. Johnson wrote: Hi, Is it possible to build boo on koji without removing the old version or is there a way to just remove Boo.Lang.Extensions from the gac? Not sure how this is a problem. Boo.Lang.Extensions.dll is only shipped by the boo package, right? And rebuilding boo does *not* pull in the old version, so where's the conflict coming from? Boo itself. It looks like it tries to pull in Boo.Lang.Extensions from the gac if its there and build against that - but can't. I'm saying looks like as upstream aren't that forthcoming with information, just a workaround. Sure; I'm not surprised that the problem is with Boo itself, but how could it find Boo in the GAC if this is a pristine mock / Koji install? And if only local rebuilds are affected, I don't think we need to worry about it that much; that's what a build server is for. -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
On Thu, Oct 28, 2010 at 11:08:00PM +0100, Richard W.M. Jones wrote: On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote: On 10/28/2010 01:11 AM, Kevin Fenzi wrote: * #480 F15Feature - RemoveSETUID ( http://fedoraproject.org/wiki/Features/RemoveSETUID ) (nirik, 19:15:16) * AGREED: the feature is approved. (nirik, 19:26:46) This feature is now approved and I see bugs get filed. The documentation and guidelines are very incomplete. How does one figure out which file capabilities are needed by the programs I maintain that currently use setuid? Help, please. More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden capabilities are present on a binary? 'ls' doesn't mention anything. You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc. See also http://people.redhat.com/sgrubb/libcap-ng/index.html Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote: You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc. Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default partitioning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/28/2010 10:37 PM, Javier Prats wrote: Hello Stephen, On a default Fedora installation using encryption and LVM it partitioned a 50GB drive giving 44GB to the root partition and only 4GB to /home. In most environments saving things to the root partition is avoided and it seems there is more than enough room for applications. This is the first distribution I've seen do this, but it's also the first time using encryption on partitions. This is very well ignorance on my part, but is there a reason for that being the default partitioning scheme? What version of Fedora are we discussing? The most recent version I installed directly (Fedora 13) partitioned / with all of the available space* and did not create a separate /home partition at all (I had to perform a custom installation to accomplish this) * Well, it also added a SWAP partition. - -- 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/ iEYEARECAAYFAkzKpyUACgkQeiVVYja6o6PeUgCgshTZ++nlCEL+wi1dnvk1yVXW EjEAn3enjF4LoAeKRqDTBjO2Tr2QI8Va =9of9 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote: On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote: You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc. Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument. In theory there's nothing preventing this. Deciding on/defining a concise display of capabilities info that doesn't mess up the formatting of ps/ls/etc is even tricker than with SELinux -Z because of the length of capabilities to display. eg, pscap for dhclient which has just 5 capabilities is showing 'dac_override, net_bind_service, net_admin, net_raw, sys_admin' There are 32 possible capabilites, so you'll quickly exceed the width of terminals just listing capabilities, in this format. You could try and decide on shortened names to 5 characters each, but it isn't going to be so readable, nor very short for lots of caps Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
On Fri, Oct 29, 2010 at 4:48 PM, Daniel P. Berrange wrote: There are 32 possible capabilites, so you'll quickly exceed the width of terminals just listing capabilities, in this format. You could try and decide on shortened names to 5 characters each, but it isn't going to be so readable, nor very short for lots of caps w, r, x are not really that readable either. It is just short, familiar and memorable. once we get short notations with a option to list what it means in full, we can adopt to that. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
On Fri, Oct 29, 2010 at 04:55:44PM +0530, Rahul Sundaram wrote: On Fri, Oct 29, 2010 at 4:48 PM, Daniel P. Berrange wrote: There are 32 possible capabilites, so you'll quickly exceed the width of terminals just listing capabilities, in this format. You could try and decide on shortened names to 5 characters each, but it isn't going to be so readable, nor very short for lots of caps w, r, x are not really that readable either. It is just short, familiar and memorable. once we get short notations with a option to list what it means in full, we can adopt to that. You only have 3 letters to remember the name of and you encounter them on a daily basis, so its easily rememberable. Give every capability even a 5 letter long code and few will ever be able to remember what they mean. Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Space for public package git repositories
Tim Niemueller, Thu, 28 Oct 2010 00:33:07 -0400: git clone package-repo make changes in package repo commit push repo somewhere send pull request to package maintainer git format-patch(1)? Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Science is meaningless because it gives no answer to our question, the only question important to us: ``What shall we do and how shall we live?'' -- Lev Nikolaevich Tolstoy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/29/2010 07:18 AM, Daniel P. Berrange wrote: On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote: On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote: You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc. Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument. In theory there's nothing preventing this. Deciding on/defining a concise display of capabilities info that doesn't mess up the formatting of ps/ls/etc is even tricker than with SELinux -Z because of the length of capabilities to display. eg, pscap for dhclient which has just 5 capabilities is showing 'dac_override, net_bind_service, net_admin, net_raw, sys_admin' There are 32 possible capabilites, so you'll quickly exceed the width of terminals just listing capabilities, in this format. You could try and decide on shortened names to 5 characters each, but it isn't going to be so readable, nor very short for lots of caps Regards, Daniel BTW I believe we now have 32 capabilities, I believe there can now be upto 64 capabilities, although I think there are only a couple added to the second bitmask so far. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzKvB0ACgkQrlYvE4MpobOhmACfQu3x6cGE1BFvHE2XUpzJ8A96 6C0An22WAQG7Zym240DZ9mAD0nugVoUe =0uSf -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
On Fri, 2010-10-29 at 12:18 +0100, Daniel P. Berrange wrote: On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote: On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote: You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc. Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument. In theory there's nothing preventing this. Deciding on/defining a concise display of capabilities info that doesn't mess up the formatting of ps/ls/etc I don't think you need to display them, just display something that says this is more than it seems ... like ACLs. Something as simple as -rwcr-xr-x. instead of -rwsr-xr-x. for setuid. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/29/2010 08:32 AM, James Antill wrote: On Fri, 2010-10-29 at 12:18 +0100, Daniel P. Berrange wrote: On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote: On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote: You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc. Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument. In theory there's nothing preventing this. Deciding on/defining a concise display of capabilities info that doesn't mess up the formatting of ps/ls/etc I don't think you need to display them, just display something that says this is more than it seems ... like ACLs. Something as simple as -rwcr-xr-x. instead of -rwsr-xr-x. for setuid. Seems like a good idea for a bug report... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzKxBUACgkQrlYvE4MpobNg4QCgubTFjqe0OPT7kRNw2DRb/F5o rNsAoLRhCU5XS5HqzM+67fnga1nN+uFZ =cUD7 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/29/2010 08:32 AM, James Antill wrote: On Fri, 2010-10-29 at 12:18 +0100, Daniel P. Berrange wrote: On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote: On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote: You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc. Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument. In theory there's nothing preventing this. Deciding on/defining a concise display of capabilities info that doesn't mess up the formatting of ps/ls/etc I don't think you need to display them, just display something that says this is more than it seems ... like ACLs. Something as simple as -rwcr-xr-x. instead of -rwsr-xr-x. for setuid. https://bugzilla.redhat.com/show_bug.cgi?id=647786 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzKxOAACgkQrlYvE4MpobPaoQCeLMsgXUfmcuuIiFCiYpbykoq8 hnEAnA5sq0xi45/O4wtCJbTiTW3MOitQ =t6LP -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning openoffice.org-extendedPDF
I'm orphaning openoffice.org-extendedPDF. I'm not sure it is useful anymore. openoffice.org-extendedPDF has broken dependencies in the rawhide tree: On x86_64: openoffice.org-extendedPDF-1.4-10.fc14.x86_64 requires openoffice.org-core openoffice.org-extendedPDF-1.4-10.fc14.x86_64 requires openoffice.org-core On i386: openoffice.org-extendedPDF-1.4-10.fc14.i686 requires openoffice.org-core openoffice.org-extendedPDF-1.4-10.fc14.i686 requires openoffice.org-core Please resolve this as soon as possible. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning openoffice.org-extendedPDF
On Fri, 2010-10-29 at 08:25 -0600, Orion Poplawski wrote: I'm orphaning openoffice.org-extendedPDF. I'm not sure it is useful anymore. I don't know if its useful either :-), but nevertheless I've now rebuilt this against LibreOffice. That'll clear the oh my god broken deps mail for you anyway. C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote: Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument. FWIW, colorized ls seems to already recognize them. Setuid binaries are gray text on a red background, while binaries with capabilities set are black text on a red background. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
On Fri, Oct 29, 2010 at 12:41:07PM +0100, Daniel P. Berrange wrote: You only have 3 letters to remember the name of and you encounter them on a daily basis, so its easily rememberable. Give every capability even a 5 letter long code and few will ever be able to remember what they mean. Perhaps we can use obscure unicode glyphs. :) -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-14 updates hosed?
On Fri, Oct 29, 2010 at 11:26:15 +1100, Bojan Smojver bo...@rexursive.com wrote: Not sure if I'm imagining things, but it looks as if those have been hosed. For example: http://download.fedora.redhat.com/pub/fedora/linux/updates/14/x86_64/ Any ideas? There was some sort of glitch. 0-day updates should show up there soon. For some reason some recent ones did and then disappeared. Probably some switch over work related to changing from updates going into the base release to going into the updates repository needs to be worked out. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
Matthew Miller mat...@mattdm.org writes: On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote: Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument. FWIW, colorized ls seems to already recognize them. Setuid binaries are gray text on a red background, while binaries with capabilities set are black text on a red background. From coreutils/src/ls.c: /* Note has_capability() adds around 30% runtime to `ls --color` */ Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
On Fri, Oct 29, 2010 at 06:16:32PM +0200, Andreas Schwab wrote: From coreutils/src/ls.c: /* Note has_capability() adds around 30% runtime to `ls --color` */ Andreas. I think that's something we can live with. Colorizing is already significant overhead, and if performance is important, don't do it: /usr$ time ls --color=yes -R /dev/null real0m23.871s user0m1.315s sys 0m22.513s /usr$ time ls --color=no -R /dev/null real0m3.707s user0m0.636s sys 0m3.060s (Actually average of three runs, after discarding one.) -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Announcing 389 Directory Server 1.2.7 Alpha 3 for testing
The 389 team is pleased to announce the availability for testing of Alpha 3 of version 1.2.7. This release contains some new features as well as many bug fixes. On those platforms which have OpenLDAP built with Mozilla NSS crypto support (Fedora 14 and later), the packages are built with OpenLDAP instead of the Mozilla LDAP C SDK. WARNING: If you are upgrading from a previous 1.2.6 release candidate, you will need to run fixfiles to fix some SELinux AVCs, or directory server will not start. See bug https://bugzilla.redhat.com/show_bug.cgi?id=622882 To fix, run this: fixfiles -R 389-ds-base restore If you are upgrading from 1.2.5 or earlier, or a stable 1.2.6, there is no problem. WARNING: If you are upgrading from a 1.2.6 alpha or release candidate, you will need to manually fix your entryrdn index files. See http://port389.org/wiki/Subtree_Rename#warning:_upgrade_from_389_v1.2.6_.28a.3F.2C_rc1_.7E_rc6.29_to_v1.2.6_rc6_or_newer for more information. If you are upgrading from 1.2.5 or earlier, or a 1.2.6 stable release, there is no problem. The new packages and versions are: * 389-ds-base 1.2.7.a3 * 389-admin 1.1.12.a2 * 389-adminutil 1.1.13 * 389-dsgw 1.1.6 * perl-Mozilla-LDAP 1.5.3 (Fedora 14 and later) ***We need your help! Please help us test this software.*** It is an Alpha release, so it may have a few glitches, but it has been tested for regressions and for new feature bugs. The Fedora system requires that packages go into Testing until verified and pushed to Stable. The more testing we get, the faster we can release these packages to Stable. See the Release Notes for information about how to provide testing feedback (or just send an email to 389-us...@lists.fedoraproject.org). === Installation === yum install --enablerepo=[updates-testing|epel-testing] 389-ds setup-ds-admin.pl === Upgrade === yum upgrade --enablerepo=[updates-testing|epel-testing] 389-ds-base 389-admin 389-adminutil 389-dsgw perl-Mozilla-LDAP setup-ds-admin.pl -u === New features === * On Fedora 14 and later, the 389 packages are built with OpenLDAP instead of Mozilla LDAP * Account Policy - keep track of last login, automatically disable unused accounts * The replication changelog has been moved into the main server database environment * Member Of supports multiple membership attributes === Bugs Fixed === This release contains many bug fixes. The complete list of bugs fixed is found at the link below. Note that bugs marked as MODIFIED have been fixed but are still in testing. * Bug List for 389 1.2.7 https://bugzilla.redhat.com/showdependencytree.cgi?id=576869hide_resolved=1 * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
On Fri, 2010-10-29 at 12:31 -0400, Matthew Miller wrote: I think that's something we can live with. Colorizing is already significant overhead, and if performance is important, don't do it: I'm color-blind (I see colors but I don't distinguish them) quite strongly. In addition, I usually work on a reverse intensity terminal (light on dark), that makes ls colors anti-ergonomic. I already considered the introduction of a default shell alias to force coloring as particularly wicked. Thus: -1 for indications by colors. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
On Fri, Oct 29, 2010 at 07:00:54PM +0200, Patrick MONNERAT wrote: I'm color-blind (I see colors but I don't distinguish them) quite strongly. In addition, I usually work on a reverse intensity terminal (light on dark), that makes ls colors anti-ergonomic. I already considered the introduction of a default shell alias to force coloring as particularly wicked. Thus: -1 for indications by colors. It absolutely cannot be the only indication. I did not mean to suggest that. However, it is a very valuable indicator for those able to take advantage of it. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Release Engineering meeting summary for 2010-10-29
Minutes:http://meetbot.fedoraproject.org/fedora- meeting/2010-10-29/fedora-releng.2010-10-29-17.03.html 18:44 zodbot Minutes (text): http://meetbot.fedoraproject.org/fedora- meeting/2010-10-29/fedora-releng.2010-10-29-17.03.txt Log:http://meetbot.fedoraproject.org/fedora- meeting/2010-10-29/fedora-releng.2010-10-29-17.03.log.html Meeting summary --- * Roll Call (Oxf13, 17:03:38) * present are nirik dgilmore rdieter skvidal Oxf13 (Oxf13, 17:06:12) * Fedora 14 Release (Oxf13, 17:06:20) * notting also present (Oxf13, 17:07:14) * smooth from releng (Oxf13, 17:09:39) * only needed one RC, and it was delivered on time (Oxf13, 17:09:46) * almost ready to go, just need to create torrent configs (Oxf13, 17:09:54) * ACTION: Oxf13 to finish creating torrent configs and contact pre-seeders (Oxf13, 17:10:04) * poelcat is also present (Oxf13, 17:14:01) * Plan to unlock mirrors and torrents the evening before release (Oxf13, 17:14:14) * releng tasks would be complete for release morning. Release afternoon/evening will do mirrormanager redirect change. (Oxf13, 17:14:37) * Fedora Release Engineering Future (Oxf13, 17:18:45) * Oxf13 (Jesse Keating) to step down as Fedora Release Engineering lead for a years time to work on internal Red Hat source migration (Oxf13, 17:23:17) * dgilmore (Dennis Gilmore) to take over as Release Engineering Lead (Oxf13, 17:23:37) * Transition to happen in 1~ month's time after dgilmore returns from vacation (Oxf13, 17:23:56) * Oxf13 to remain available for contact and knowledge base throughout this time (Oxf13, 17:24:32) * ACTION: dgilmore to take over Fedora releng meetings, potentially arranging a new time (Oxf13, 17:32:31) * Oxf13 to continue working on fedpkg. (Oxf13, 17:36:22) * ACTION: nirik to be on point for updates for the next few weeks (Oxf13, 17:38:54) * Fedora 15 Schedule (Oxf13, 17:45:22) * LINK: https://fedorahosted.org/rel-eng/ticket/4233 (poelcat, 17:46:04) * LINK: https://fedorahosted.org/fesco/ticket/467 (nirik, 17:50:23) * AGREED: Move feature freeze and all later dates 2 weeks later to make way for FUDCon and Ubuntu release (Oxf13, 18:03:49) * AGREED: Release Engineering accepts amended F15 schedule (Oxf13, 18:05:29) * Package Signing (Oxf13, 18:07:40) * releng plans on reducing to one key to sign all rpms and automatically signing every official build that comes through koji with it. (Oxf13, 18:09:06) * Changes coming in package signing, desire to move to detached signatures, and no longer using gpg for the signatures (Oxf13, 18:10:01) * effort led by RHT security team (Oxf13, 18:11:03) * hopeful timeline is to be able to make x509 sigs by F15, but not necessarily include them (Oxf13, 18:27:27) * skvidal is planning to do a FUDCon session about this. (Oxf13, 18:30:25) * yum api break may be happening soon (Oxf13, 18:34:25) * Rawhide and deltas (Oxf13, 18:34:38) * xz had api change, which results in an odd deltarpm situation (Oxf13, 18:35:05) * delta generation currently broken in rawhide, will attempt to re-enable after inheritance fixes are done. (Oxf13, 18:39:13) * ACTION: Oxf13 to break inheritance between F15 and anything earlier, and force tag all currently inherited packages into dist-f15 (Oxf13, 18:39:35) * developers who want a new build to show up in rawhide will have to explicitly build for rawhide. (Oxf13, 18:39:48) * Open Floor (Oxf13, 18:41:54) Meeting ended at 18:44:16 UTC. Action Items * Oxf13 to finish creating torrent configs and contact pre-seeders * dgilmore to take over Fedora releng meetings, potentially arranging a new time * nirik to be on point for updates for the next few weeks * Oxf13 to break inheritance between F15 and anything earlier, and force tag all currently inherited packages into dist-f15 Action Items, by person --- * dgilmore * dgilmore to take over Fedora releng meetings, potentially arranging a new time * nirik * nirik to be on point for updates for the next few weeks * Oxf13 * Oxf13 to finish creating torrent configs and contact pre-seeders * Oxf13 to break inheritance between F15 and anything earlier, and force tag all currently inherited packages into dist-f15 * **UNASSIGNED** * (none) signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default partitioning
On Thu, 28 Oct 2010, Javier Prats wrote: Hello Stephen, On a default Fedora installation using encryption and LVM it partitioned a 50GB drive giving 44GB to the root partition and only 4GB to /home. In most environments saving things to the root partition is avoided and it seems there is more than enough room for applications. This is the first distribution I've seen do this, but it's also the first time using encryption on partitions. This is very well ignorance on my part, but is there a reason for that being the default partitioning scheme? Here is the bug regarding the installer creating a /home partition: https://bugzilla.redhat.com/show_bug.cgi?id=150670 And the commit: commit 1952a27de7bf47c4a8243662d6e606194eba002e Author: Chris Lumens clum...@redhat.com Date: Thu Oct 29 10:53:57 2009 -0400 Modify autopart requests to include a separate /home (#150670). This modifies the default partitioning as follows: (1) For VGs = 50 GB, we will continue to make swap and / as normal. (2) For VGs 50 GB, / will cap at 50 GB and /home will consume the rest. 50 GB is fairly arbitrary, and was based on the fact that an Everything install of Fedora right now is ~ 40 GB, plus some room for expansion. Very few users are likely to do an Everything install so this should provide plenty of space for upgrades and future growth. Additionally, this is only a default partitioning suggestion and can always be overridden by the user. We discussed how /home would be created during automatic partitioning and based on the feedback from many people, the above algorithm was determined. So, the odd 4GB /home in your case is most likely due to your disk being on the 50GB line. On Mon, 2010-10-25 at 07:02 -0400, Stephen Gallagher wrote: -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- -- David Cantrell dcantr...@redhat.com Red Hat / Honolulu, HI -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default partitioning
On 10/29/2010 14:37, David Cantrell wrote: (1) For VGs= 50 GB, we will continue to make swap and / as normal. (2) For VGs 50 GB, / will cap at 50 GB and /home will consume the rest. 50 GB is fairly arbitrary, and was based on the fact that an Everything install of Fedora right now is ~ 40 GB, plus some room for expansion. Very few users are likely to do an Everything install so this should provide plenty of space for upgrades and future growth. Additionally, this is only a default partitioning suggestion and can always be overridden by the user. We discussed how /home would be created during automatic partitioning and based on the feedback from many people, the above algorithm was determined. So, the odd 4GB /home in your case is most likely due to your disk being on the 50GB line. If you want to keep defaulting to a separate /home partition, how about doing so only when the disk is above a larger size such as 80 or 100 GB? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default partitioning
On 10/29/10 12:37 PM, David Cantrell wrote: We discussed how /home would be created during automatic partitioning and based on the feedback from many people, the above algorithm was determined. So, the odd 4GB /home in your case is most likely due to your disk being on the 50GB line. A small tweak which might make sense... For volumes that are over 100G in size, enact the 50g / + rest for /home setup. For anything smaller than 100G in size leave everything in / That should avoid having anything less than 50% of your disk space in /home. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default partitioning
On Fri, Oct 29, 2010 at 10:16 PM, Jesse Keating jkeat...@redhat.com wrote: A small tweak which might make sense... For volumes that are over 100G in size, enact the 50g / + rest for /home setup. For anything smaller than 100G in size leave everything in / That should avoid having anything less than 50% of your disk space in /home. Is it worth adding a warning when the available space is rather marginally small (in addition to the above suggestions)? i.e. Tell the user: The install will continue but the available space for user data and additional packages is limited - continue (yes/no)? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
On Fri, 2010-10-29 at 12:05 -0400, Matthew Miller wrote: On Fri, Oct 29, 2010 at 12:41:07PM +0100, Daniel P. Berrange wrote: You only have 3 letters to remember the name of and you encounter them on a daily basis, so its easily rememberable. Give every capability even a 5 letter long code and few will ever be able to remember what they mean. Perhaps we can use obscure unicode glyphs. :) you said 64 capabilities, right? that's not so many. Chinese and Japanese users are laughing, we can just use some basic Chinese characters. For our European users we can combine Roman, Greek and Cyrillic alphabets and require all our users to have decent liberal education. Anyone want to suggest something for Indian and African users? :) Americans, well, they're just a lost cause...perhaps the logos of popular sports teams? -- 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
[perl-Net-Patricia/f14/master] (10 commits) ...Merge branch 'master' into f14
Summary of changes: a632d5f... Initialize branch F-13 for perl-Net-Patricia (*) 8319cc5... Version bump to 1.17 (*) c869c9b... Refresh .spec file with cpanspec. (*) a19261d... Add changelog entries. (*) 51564e9... Update changelog. (*) 7d34f69... dist-git conversion (*) b5d8160... Merge remote branch 'origin/f13/master' (*) 89b4d88... Version bump to 1.18 per upstream. (*) 28ea21e... Merge remote branch 'origin/f13/master' into f14 61510be... Merge branch 'master' into f14 (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-Patricia/f14/master: 9/10] Merge remote branch 'origin/f13/master' into f14
commit 28ea21efabab262dfed9f9b291dee108c01a7eb9 Merge: e2cffdf 7d34f69 Author: Philip Prindeville phil...@fedoraproject.org Date: Wed Oct 27 00:35:32 2010 -0600 Merge remote branch 'origin/f13/master' into f14 --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-Patricia/f14/master: 10/10] Merge branch 'master' into f14
commit 61510be564199edd586e6113590a1e20fc7e411a Merge: 28ea21e 89b4d88 Author: Philip Prindeville phil...@fedoraproject.org Date: Wed Oct 27 00:37:16 2010 -0600 Merge branch 'master' into f14 .gitignore |1 + perl-Net-Patricia.spec |7 +-- sources|2 +- 3 files changed, 7 insertions(+), 3 deletions(-) --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-Patricia/f13/master] (11 commits) ...Version bump to 1.18 per upstream.
Summary of changes: 605f2d3... Update to stable release 1.16. (*) b885f18... - Mass rebuild with perl-5.12.0 (*) e932c0a... - Mass rebuild with perl-5.12.0 (*) c36edae... Version bump to 1.17 (*) a49c300... Refresh .spec file with cpanspec. (*) d553205... Add changelog entries. (*) b1eb5ae... Bump to what's on CPAN. (*) 4df3e50... Update changelog. (*) e2cffdf... dist-git conversion (*) b5d8160... Merge remote branch 'origin/f13/master' (*) 89b4d88... Version bump to 1.18 per upstream. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 596103] perl-Net-Patricia-1.18 is available
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=596103 --- Comment #2 from Fedora Update System upda...@fedoraproject.org 2010-10-29 02:24:18 EDT --- perl-Net-Patricia-1.18-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/perl-Net-Patricia-1.18-1.fc14 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 647783] New: perl-Mail-Box shouldn't force spamassassin to be installed
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Mail-Box shouldn't force spamassassin to be installed https://bugzilla.redhat.com/show_bug.cgi?id=647783 Summary: perl-Mail-Box shouldn't force spamassassin to be installed Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: low Component: perl-Mail-Box AssignedTo: tcall...@redhat.com ReportedBy: j...@kamens.brookline.ma.us QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com Classification: Fedora People who aren't planning on using spamassassin shouldn't be forced to install it just to be able to use the modules in perl-Mail-Box, most of which are totally independent of spamassassin. One fix would be to remove the dependency on Mail::SpamAssassin completely from the perl-Mail-Box RPM, in which case, people who try to use spamassassin functionality in perl-Mail-Box will simply get an error because of the missing module and know they need to install spamassassin. Another fix would be to split the perl modules in spamassassin into a separate RPM, e.g., spamassassin-perl, so they can be installed without the rest of spamassassin. -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 596103] perl-Net-Patricia-1.18 is available
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=596103 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2010-10-29 16:37:22 EDT --- perl-Net-Patricia-1.18-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Net-Patricia'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/perl-Net-Patricia-1.18-1.fc14 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 640505] Please branch for EPEL5
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=640505 Ruediger Landmann r.landm...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||DUPLICATE Last Closed||2010-10-29 19:55:07 --- Comment #2 from Ruediger Landmann r.landm...@redhat.com 2010-10-29 19:55:07 EDT --- *** This bug has been marked as a duplicate of bug 479223 *** -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: python-distutils-extra
On Fri, Oct 29, 2010 at 05:45:09PM -0400, Luke Macken wrote: Just a heads up to some new behavior that I noticed in F14. When python-distutils-extra is installed, it will cause pylint to be run against your project automatically when `python setup.py sdist` is called. It installs DistUtilsExtra.command.check on the distutils.commands check entry-point. This shouldn't be a problem in koji-land, since nothing currently pulls this in at build time. This turns out to be an annoyance for me, since it causes an infinite recursion error with one of my projects. Whether or not we want to patch this behavior out is still up for discussion. Is any of this submitted to distutils-extra upstream? -Toshio pgpdR32dFAlsv.pgp Description: PGP signature ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
