Call for F13 release slogan suggestions
Greetings Friends, We need a slogan for the F13 release. It will be chosen one week from now, on 3/2. A release slogan is a short call-to-action that fits the artwork theme from Design, found at https://fedoraproject.org/wiki/F13_release_slogan#Themes. (F12's slogan was "Unite.") If you are interested in suggesting ideas for the release slogan, please take a look at the Release Slogan SOP, and the criteria for selection, at https://fedoraproject.org/wiki/Release_slogan_SOP. The slogan must be: * short (1-3 words) * a call to action * positive It should reinforce that Fedora helps the user achieve something great. It should also reflect some of ideas and themes found in the release artwork, and, if possible, also touch upon the Four Foundations (http://https://fedoraproject.org/wiki/Foundations). Please put your slogan ideas here: https://fedoraproject.org/wiki/F13_release_slogan#New_slogan_ideas The deadline for submissions is Tuesday 3/2 at 20:00 UTC, which is our next Marketing meeting (https://fedoraproject.org/wiki/Marketing_meetings). We'll be discussing submissions there, and then the FPL, Mo Duffy, and the Marketing team lead will take that input and select the final slogan on 3/2, following the marketing meeting. Let me know if you have any questions, comments, or concerns -- and let the wiki table know if you have any ideas! Cheers, Robyn ___ 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
File MooseX-Types-DateTimeX-0.06.tar.gz uploaded to lookaside cache by mmaslano
A file has been added to the lookaside cache for perl-MooseX-Types-DateTimeX: d8142d7f7b08af18de6d302da8d7f7b9 MooseX-Types-DateTimeX-0.06.tar.gz -- 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
rpms/perl-MooseX-Types-DateTimeX/devel perl-MooseX-Types-DateTimeX.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-MooseX-Types-DateTimeX/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv13774
Modified Files:
.cvsignore sources
Added Files:
perl-MooseX-Types-DateTimeX.spec
Log Message:
* Mon Feb 22 2010 Marcela Mašláňová 0.06-2
- add missing BR, conflict with older version od MooseX
--- NEW FILE perl-MooseX-Types-DateTimeX.spec ---
Name: perl-MooseX-Types-DateTimeX
Version:0.06
Release:2%{?dist}
Summary:Extensions to MooseX::Types::DateTime::ButMaintained
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/MooseX-Types-DateTimeX/
Source0:
http://www.cpan.org/authors/id/E/EC/ECARROLL/MooseX-Types-DateTimeX-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(Moose)
BuildRequires: perl(MooseX::Types)
BuildRequires: perl(namespace::clean)
BuildRequires: perl(Time::Duration::Parse)
BuildRequires: perl(MooseX::Types::DateTime::ButMaintained)
BuildRequires: perl(DateTimeX::Easy)
BuildRequires: perl(Test::use::ok)
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::More)
BuildRequires: perl(ExtUtils::MakeMaker)
Requires: perl(MooseX) >= 0.41
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
Conflicts: perl(MooseX::Types::DateTime) < 0.05
%description
This module builds on MooseX::Types::DateTime to add additional custom
types and coercions. Since it builds on an existing type, all coercions and
constraints are inherited.
%prep
%setup -q -n MooseX-Types-DateTimeX-%{version}
%build
PERL5_CPANPLUS_IS_RUNNING=1 %{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Mon Feb 22 2010 Marcela Mašláňová 0.06-2
- add missing BR, conflict with older version od MooseX
* Fri Feb 19 2010 Marcela Mašláňová 0.06-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-MooseX-Types-DateTimeX/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 23 Feb 2010 17:09:08 - 1.1
+++ .cvsignore 24 Feb 2010 06:48:59 - 1.2
@@ -0,0 +1 @@
+MooseX-Types-DateTimeX-0.06.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-MooseX-Types-DateTimeX/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 23 Feb 2010 17:09:08 - 1.1
+++ sources 24 Feb 2010 06:49:00 - 1.2
@@ -0,0 +1 @@
+d8142d7f7b08af18de6d302da8d7f7b9 MooseX-Types-DateTimeX-0.06.tar.gz
--
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
Re: hdparm -B for netbooks
Matthew Garrett wrote on 23.02.2010 23:09: > On Tue, Feb 23, 2010 at 09:34:54PM +0100, Richard Zidlicky wrote: > >> it was my understanding that "hdparm -B" has nothing to do with the BIOS but >> changes >> the power management feature specific to the drive? > Either the drive set the initial value, or the BIOS did. We tend to > assume that there was some reason for that... And what does Windows do? I have the strange feeling it doesn't assume the same and instead simply sets something it thinks is sensible, which afaics results in Hardware manufactures not to care much what the initial value for the drive is or what the BIOS sets. If that's the case (I never checked and am not familiar with Windows enough to know) then wouldn't it be the most sensible thing to do something similar? CU knurd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for F13 release slogan suggestions
On Tue, 2010-02-23 at 22:06 -0700, Robyn Bergeron wrote: > * short (1-3 words) Well, some to avoid anyway... Lucky for You! Have More Fun! For Great Justice! ;) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdparm -B for netbooks
On Tue, Feb 23, 2010 at 09:10:03PM +0100, Richard Zidlicky wrote: > I have one of these netbooks that need "hdparm -B high_value" to avoid > unhealthy > frequent head parking. From some archived mails I had the impression that it > was > planned that gnome power manager and similar would take care of such issues - > which > does not appear to happen in my case. > > What is the state of this - is some package responsible for this or is it up > to > the user to do it manualy? You have to set it manually at bootup (add it to /etc/rc.local), but after suspend/hibernate the values are normally restored by pm-utils (eventually this might happen in the kernel). In the past some devices needed a manual override in /etc/pm-utils-hd-apm-restore.conf But this might not be needed anymore. Regards Till pgpJF0VZxLkKb.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intel GPU powersaving
Hello. Am Dienstag, den 23.02.2010, 22:13 + schrieb Matthew Garrett: > We tried some new Intel powersaving code in the F12 cycle, but it caused > a range of problems including screen flickering and crashes. I've > reworked this a little and it seems to work on a machine that had > problems in the past, so I'd like to try it again. If anyone with an > Intel GPU (except GMA500, 810, 815 and 830) would like to give the F13 > kernels at http://koji.fedoraproject.org/koji/taskinfo?taskID=2009928 a > go and let me know if they result in graphical glitches or hangs that > you don't otherwise have with F13, that would be a great help. I'm using an Iintel GMA 945 (Macbook 2.1), the above kernel does not behave different than 2.6.33-0.46. That means: - GDM works (again) - No flickering at boot - Logging in to GNOME blanks the screen, even a VT switch does not bring the backlight(?) back. (might this just be an gnome-power problem? related to ...) - ... adjusting brightness does not work. All in all the intel driver was quite unstable since 2.6.31-5. https://bugzilla.redhat.com/show_bug.cgi?id=558439 Greetings - fabian smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
switching from man to man-db
Hello, I'd like to switch from man (http://primates.ximian.com/~flucifredi/man/) to man-db project (http://man-db.nongnu.org/). man-db seems for me to be better choice then the original man. The reasons are: * the upstream very active in man-db, man upstream almost does not response and the last version was released in 2007 * because of the previous comment man-db have more features then man * man-db uses Berkeley db instead of text file for the index of man pages * Debian, Ubuntu, SuSE use man-db As the first step I want to add man-db to fedora cvs. Comments welcomed. Ivana -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: man-db vs. man
Hello, sorry for the late response, I'm the man package maintainer and I agree with the idea to switch from man to man-db. I just sent a mail to fedora list about it. Thanks. Ivana On 02/12/2010 05:53 PM, Till Maas wrote: > Hiyas, > according to the man-db[0] homepage all/most other major distributions > use a more actively developed manpage suite called man-db, while we only > ship this: > http://primates.ximian.com/~flucifredi/man/ > > In a package of mine, "man -l" is used to create a plaintext version of > the manpage, which seems to only work with man-db. Could this be a > Feature for F14 to use man-db instead of man or are there major reasons > not to do this? > > Btw. I cc'ed man-ow...@fpo. > > Regards > Till > > [0] http://man-db.nongnu.org/ > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:hdparm -B for netbooks
This is not a big problem, you can use pm-utils to solve this bug by throwing srcipts to /etc/pm/sleep.d and /etc/pm/power.d. 在2010-02-24?04:10:03，"Richard?Zidlicky"??写道： >Hi, > >I?have?one?of?these?netbooks?that?need?"hdparm?-B?high_value"?to?avoid?unhealthy >frequent?head?parking.?From?some?archived?mails?I?had?the?impression?that?it?was >planned?that?gnome?power?manager?and?similar?would?take?care?of?such?issues?-?which >does?not?appear?to?happen?in?my?case. > >What?is?the?state?of?this?-?is?some?package?responsible?for?this?or?is?it?up?to? >the?user?to?do?it?manualy? > >Richard >--? >devel?mailing?list >devel@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help for fixing Fedora rawhide FTBFS
On Mon, 15 Feb 2010, yersinia wrote: > On Mon, Feb 15, 2010 at 3:33 PM, Andreas Schwab wrote: > > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/x86_64/recode-3.6-28.fc12.src.rpm/result/build.log > > > > > > checking host system type... Invalid configuration > > > `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized > > > checking build system type... Invalid configuration > > > `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized > > > > The included config.sub is older than 10 years. Try running autoreconf. > > > > exists redhat-rpm-config in mock env ? > > rpmbuild -bc xxx.spec > ++ basename ./config/config.sub > + '[' -f /usr/lib/rpm/redhat/config.sub ']' > + /bin/rm -f ./config/config.sub > ++ basename ./config/config.sub > *+ /bin/cp -fv /usr/lib/rpm/redhat/config.sub ./config/config.sub* > `/usr/lib/rpm/redhat/config.sub' -> `./config/config.sub' So, you recommend to add the above lines (or something similar) to the spec file? I wanted to test the build process in mock, but I get Missing dependencies: -- mock -v -r fedora-devel-x86_64 rebuild recode-3.6-28.fc12.src.rpm ... 4:perl-5.10.1-110.fc13.i686 from fedora has depsolving problems --> Missing Dependency: perl(Module::Pluggable) is needed by package 4:perl-5.10.1-110.fc13.i686 (fedora) glibc-2.11.90-12.i686 from fedora has depsolving problems --> Missing Dependency: glibc-common = 2.11.90-12 is needed by package glibc-2.11.90-12.i686 (fedora) redhat-rpm-config-9.1.0-3.fc13.noarch from fedora has depsolving problems --> Missing Dependency: mktemp is needed by package redhat-rpm-config-9.1.0-3.fc13.noarch (fedora) 4:perl-5.10.1-110.fc13.i686 from fedora has depsolving problems --> Missing Dependency: perl(Pod::Simple) is needed by package 4:perl-5.10.1-110.fc13.i686 (fedora) redhat-rpm-config-9.1.0-3.fc13.noarch from fedora has depsolving problems --> Missing Dependency: /bin/bash is needed by package redhat-rpm-config-9.1.0-3.fc13.noarch (fedora) redhat-rpm-config-9.1.0-3.fc13.noarch from fedora has depsolving problems --> Missing Dependency: rpm >= 4.6.0 is needed by package redhat-rpm-config-9.1.0-3.fc13.noarch (fedora) 4:perl-5.10.1-110.fc13.i686 from fedora has depsolving problems --> Missing Dependency: perl(version) is needed by package 4:perl-5.10.1-110.fc13.i686 (fedora) basesystem-10.0-3.noarch from fedora has depsolving problems --> Missing Dependency: filesystem is needed by package basesystem-10.0-3.noarch (fedora) redhat-rpm-config-9.1.0-3.fc13.noarch from fedora has depsolving problems --> Missing Dependency: /bin/bash is needed by package redhat-rpm-config-9.1.0-3.fc13.noarch (fedora) redhat-rpm-config-9.1.0-3.fc13.noarch from fedora has depsolving problems --> Missing Dependency: /bin/sh is needed by package redhat-rpm-config-9.1.0-3.fc13.noarch (fedora) redhat-rpm-config-9.1.0-3.fc13.noarch from fedora has depsolving problems --> Missing Dependency: /bin/sh is needed by package redhat-rpm-config-9.1.0-3.fc13.noarch (fedora) Error: Missing Dependency: /bin/sh is needed by package redhat-rpm-config-9.1.0-3.fc13.noarch (fedora) Error: Missing Dependency: /bin/bash is needed by package redhat-rpm-config-9.1.0-3.fc13.noarch (fedora) Error: Missing Dependency: filesystem is needed by package basesystem-10.0-3.noarch (fedora) Error: Missing Dependency: glibc-common = 2.11.90-12 is needed by package glibc-2.11.90-12.i686 (fedora) Error: Missing Dependency: perl(Module::Pluggable) is needed by package 4:perl-5.10.1-110.fc13.i686 (fedora) Error: Missing Dependency: mktemp is needed by package redhat-rpm-config-9.1.0-3.fc13.noarch (fedora) Error: Missing Dependency: perl(version) is needed by package 4:perl-5.10.1-110.fc13.i686 (fedora) Error: Missing Dependency: rpm >= 4.6.0 is needed by package redhat-rpm-config-9.1.0-3.fc13.noarch (fedora) Error: Missing Dependency: perl(Pod::Simple) is needed by package 4:perl-5.10.1-110.fc13.i686 (fedora) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest The program package-cleanup is found in the yum-utils package. -- How can I fix this, test the build? Zoltan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100224 changes
Compose started at Wed Feb 24 08:15:05 UTC 2010 Broken deps for i386 -- blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28 doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5 edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 frepple-0.7.1-1.fc13.i686 requires libxerces-c.so.28 geglmm-0.1.0-3.fc13.i686 requires libgegl-0.0.so.0 generic-release-rawhide-14-0.1.noarch requires generic-release-14-0.1 2:gimp-2.6.8-3.fc13.i686 requires libgegl-0.0.so.0 gnome-python2-totem-2.29.1-4.fc13.i686 requires libtotem-plparser.so.12 gnucash-2.3.10-1.fc13.i686 requires libgoffice-0.8.so.7 koan-2.0.3.1-1.fc13.noarch requires mkinitrd kst-fits-1.8.0-6.fc14.i686 requires cfitsio = 0:3.24 libvirt-qpid-0.2.17-3.fc12.i686 requires qpidc >= 0:0.5.790661 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 matahari-0.0.4-7.fc13.i686 requires qpidc >= 0:0.5.819819 nip2-7.20.7-2.fc13.i686 requires libgoffice-0.8.so.7 ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc 1:perl-Catalyst-Manual-tests-5.8004-1.fc14.noarch requires perl-Catalyst-Manual = 0:5.8004-1.fc14 perl-MooseX-Types-DateTimeX-0.06-2.fc14.noarch requires perl(MooseX) >= 0:0.41 python-vcpx-0.9.35-7.fc12.noarch requires bazaar qmf-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-rdma-0.5.819819-4.fc13.i686 requires qpidc-client-rdma = 0:0.5.819819-4.fc13 qpidc-server-ssl-0.5.819819-4.fc13.i686 requires qpidc-client-ssl = 0:0.5.819819-4.fc13 solang-0.3-9.967a9627077cd2249093dbc552795d44dd82a729git.fc13.i686 requires libgegl-0.0.so.0 totem-youtube-2.29.4-3.fc13.i686 requires libgdata.so.6 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 -- blahtexml-0.6-5.fc12.x86_64 requires libxerces-c.so.28()(64bit) doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 doodle-0.6.7-5.fc12.x86_64 requires libextractor.so.1()(64bit) easystroke-0.5.2-1.fc13.x86_64 requires libboost_serialization-mt.so.5()(64bit) edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 edje-0.9.9.050-6.fc12.x86_64 requires libembryo.so.0()(64bit) frepple-0.7.1-1.fc13.i686 requires libxerces-c.so.28 frepple-0.7.1-1.fc13.x86_64 requires libxerces-c.so.28()(64bit) geglmm-0.1.0-3.fc13.i686 requires libgegl-0.0.so.0 geglmm-0.1.0-3.fc13.x86_64 requires libgegl-0.0.so.0()(64bit) generic-release-rawhide-14-0.1.noarch requires generic-release-14-0.1 2:gimp-2.6.8-3.fc13.x86_64 requires libgegl-0.0.so.0()(64bit) gnome-python2-totem-2.29.1-4.fc13.x86_64 requires libtotem-plparser.so.12()(64bit) gnucash-2.3.10-1.fc13.x86_64 requires libgoffice-0.8.so.7()(64bit) koan-2.0.3.1-1.fc13.noarch requires mkinitrd kst-fits-1.8.0-6.fc14.x86_64 requires cfitsio = 0:3.24 libvirt-qpid-0.2.17-3.fc12.x86_64 requires qpidc >= 0:0.5.790661 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) matahari-0.0.4-7.fc13.x86_64 requires qpidc >= 0:0.5.819819 nip2-7.20.7-2.fc13.x86_64 requires libgoffice-0.8.so.7()(64bit) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc 1:perl-Catalyst-Manual-tests-5.8004-1.fc14.noarch requires perl-Catalyst-Manual = 0:5.8004-1.fc14 perl-MooseX-Types-DateTimeX-0.06-2.fc14.noarch requires perl(MooseX) >= 0:0.41 python-vcpx-0.9.35-7.fc12.noarch requires bazaar qmf-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qmf-devel-0.5.819819-4.fc13.x86_64 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-devel-0.5.819819-4.fc13.x86_64 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-rdma-0.5.819819-4.fc13.x86_64 requires qpidc-client-rdma = 0:0.5.819819-4.fc13 qpidc-server-ssl-0.5.819819-4.fc13.x86_64 requires qpidc-client-ssl = 0:0.5.819819-4.fc13 solang-0.3-9.967a9627077cd2249093dbc552795d44dd82a729git.fc13.x86_64 requires libgegl-0.0.so.0()(64bit) totem-youtube-2.29.4-3.fc13.x86_64 requires libgdata.so.6()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package hivex Read and write Windows Registry binary hive files New package perl-M
Re: help for fixing Fedora rawhide FTBFS
Zoltan Kota writes: > So, you recommend to add the above lines (or something similar) to the > spec file? I'd recommend to update to recode-3.7-beta2. 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: hdparm -B for netbooks
Hi. On Tue, 23 Feb 2010 22:09:39 +, Matthew Garrett wrote: > Either the drive set the initial value, or the BIOS did. We tend to > assume that there was some reason for that... Well, the BIOS also sets the VGA resolution to 80x25. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdparm -B for netbooks
On Wed, 2010-02-24 at 16:17 +0100, Ralf Ertzinger wrote: > On Tue, 23 Feb 2010 22:09:39 +, Matthew Garrett wrote: > > Either the drive set the initial value, or the BIOS did. We tend to > > assume that there was some reason for that... > > Well, the BIOS also sets the VGA resolution to 80x25. ITYM 720x400. The reason for which is DOS compatibility, and we're not interested in being DOS compatible. Moreover, we go out and discover what resolutions _are_ possible, and filter them against the hardware's capabilities in terms of maximum pixel clock, memory bandwidth, and so forth. We have constraints, they are discoverable, and we know how to operate within them. Whereas for disks, we don't have the constraints that determined the initial choice of APM setting, so we're best off not messing with it in the general case. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F13 talking points have been chosen - help us add in details!
You may recall the Marketing team asking for help selecting the F13 talking points last week - thanks to a great many people who participated, we were able to wrap up the discussion today (which you can see at http://meetbot.fedoraproject.org/fedora-meeting-1/2010-02-23/fedora-meeting-1.2010-02-23-20.03.log.html) and are happy to announce that the F13 talking points have been chosen. Here they are! From https://fedoraproject.org/wiki/Fedora_13_Talking_Points: * 1 For desktop users and everyone o 1.1 Automatic print driver installation o 1.2 Automatic installation of language packs o 1.3 Redesigned user management interface o 1.4 Color management o 1.5 NetworkManager improvements include CLI o 1.6 Experimental 3D extended to free Nouveau driver * 2 For administrators o 2.1 BFO o 2.2 Authconfig UI redesign o 2.3 Pioneering NSF features o 2.4 Zarafa o 2.5 Experimenting with btrfs * 3 For developers o 3.1 SystemTap static probes o 3.2 Easier Python debugging o 3.3 Parallel-installable Python 3 o 3.4 NetBeans 6.8 first IDE to support entire Java 6 EE spec * 4 Spins o 4.1 Moblin Spin o 4.2 Sugar on a Stick Spin o 4.3 Design Studio Spin o 4.4 Security Spin Now: to finish fleshing them out, we need your help. We're aiming for a finished product like https://fedoraproject.org/wiki/Fedora_12_Talking_Points. See the links to feature pages, heavily hyperlinked descriptions, and catchy one-line summaries at the end? That's what we need for all the F13 talking points. If you know cool things about a talking point that should be mentioned, good resources on it to link to, or otherwise have something to chip in, please add it to the wiki page (https://fedoraproject.org/wiki/Fedora_13_Talking_Points); we'll be cleaning up the final display next week right before the Alpha goes out. Tally ho! --Mel on behalf of the Marketing team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdparm -B for netbooks
On Wed, Feb 24, 2010 at 09:53:39AM +0100, Till Maas wrote: > You have to set it manually at bootup (add it to /etc/rc.local), but > after suspend/hibernate the values are normally restored by pm-utils > (eventually this might happen in the kernel). In the past some devices > needed a manual override in /etc/pm-utils-hd-apm-restore.conf But this > might not be needed anymore. ok, this is a great step forward as I hated to add very similar but slightly different scripts to /etc/init.d and /etc/pm/ - and for each Linux distro needed several tries to actually figure out if it goes into /etc/acpi or into one of the pm dirs. Richard pgptLgLxidanC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdparm -B for netbooks
On Tue, Feb 23, 2010 at 10:09:39PM +, Matthew Garrett wrote: > On Tue, Feb 23, 2010 at 09:34:54PM +0100, Richard Zidlicky wrote: > > > it was my understanding that "hdparm -B" has nothing to do with the BIOS > > but changes > > the power management feature specific to the drive? > > Either the drive set the initial value, or the BIOS did. We tend to > assume that there was some reason for that... the reason is not always reasonable. Maybe the BIOS programmer assumed a specially tuned distribution which never materialised. Maybe some manufacturer wanted to impress with better runtimes on battery and did not care if the harddisk is broken after 2 years. Whatever the reason, many users think it is better to change the setting - is there any reason why the power manager should not make it really easy? I did read that various a few drives have a special interpretation of the numeric values but I do not see a problem if the sysadmin chooses the value and have never heard of any serious saftey problems. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdparm -B for netbooks
On Wed, Feb 24, 2010 at 05:07:44PM +0100, Richard Zidlicky wrote: > Whatever the reason, many users think it is better to change the setting - is > there > any reason why the power manager should not make it really easy? Yes - it's an option that's basically impossible to expose in a UI in a sensible way. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:hdparm -B for netbooks
This is not a big problem, you can use pm-utils to solve this bug by throwing srcipts to /etc/pm/sleep.d and /etc/pm/power.d. Anyone who cares high frequency of load/unload cycles on some hard disks can refering http://wiki.archlinux.org/index.php/Pm-utils to hack the pm-utils. 在2010-02-24 20:37:58，"Chen Lei" 写道： This is not a big problem, you can use pm-utils to solve this bug by throwing srcipts to /etc/pm/sleep.d and /etc/pm/power.d. 在2010-02-24?04:10:03，"Richard?Zidlicky"??写道： >Hi, > >I?have?one?of?these?netbooks?that?need?"hdparm?-B?high_value"?to?avoid?unhealthy >frequent?head?parking.?From?some?archived?mails?I?had?the?impression?that?it?was >planned?that?gnome?power?manager?and?similar?would?take?care?of?such?issues?-?which >does?not?appear?to?happen?in?my?case. > >What?is?the?state?of?this?-?is?some?package?responsible?for?this?or?is?it?up?to? >the?user?to?do?it?manualy? > >Richard >--? >devel?mailing?list >devel@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: fix memory leak in attr replace when replacement fails
>From 7be88811a1b26a4cac6cb0e25386c795f72dabef Mon Sep 17 00:00:00 2001
From: Rich Megginson
Date: Wed, 24 Feb 2010 09:48:36 -0700
Subject: [PATCH] fix memory leak in attr replace when replacement fails
if replacement of the attribute values fails (e.g. due to duplicate values)
the valstoreplace is not freed - the caller expects the valueset_replace
function to own the values passed in. The function will now free the values
if there was an error
In addition, valueset_replace should not free the old values in case
of error - it should leave the old values in the attribute
---
ldap/servers/slapd/valueset.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/ldap/servers/slapd/valueset.c b/ldap/servers/slapd/valueset.c
index a9cd37e..d6909ac 100644
--- a/ldap/servers/slapd/valueset.c
+++ b/ldap/servers/slapd/valueset.c
@@ -1345,10 +1345,6 @@ valueset_replace(Slapi_Attr *a, Slapi_ValueSet *vs, Slapi_Value **valstoreplace)
{
int rc = LDAP_SUCCESS;
int numberofvalstoreplace= valuearray_count(valstoreplace);
-if(!valuearray_isempty(vs->va))
-{
-slapi_valueset_done(vs);
-}
/* verify the given values are not duplicated.
if replacing with one value, no need to check. just replace it.
*/
@@ -1368,8 +1364,21 @@ valueset_replace(Slapi_Attr *a, Slapi_ValueSet *vs, Slapi_Value **valstoreplace)
if ( rc == LDAP_SUCCESS )
{
+/* values look good - replace the values in the attribute */
+if(!valuearray_isempty(vs->va))
+{
+/* remove old values */
+slapi_valueset_done(vs);
+}
+/* we now own valstoreplace */
vs->va = valstoreplace;
}
+else
+{
+/* caller expects us to own valstoreplace - since we cannot
+ use them, just delete them */
+valuearray_free(&valstoreplace);
+}
return rc;
}
--
1.5.5.6
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
[Bug 567931] virt-top exits sometimes when the window is resized
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=567931 Richard W.M. Jones changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||UPSTREAM --- Comment #6 from Richard W.M. Jones 2010-02-24 12:33:09 EST --- This change was pushed to upstream libvirt which fixes the bug: http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=f4a43df52b7c84bda61863250d20135f044893da -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: hdparm -B for netbooks
On Thu, Feb 25, 2010 at 01:10:10AM +0800, Chen Lei wrote: > This is not a big problem, you can use pm-utils to solve this bug by throwing > srcipts to /etc/pm/sleep.d and /etc/pm/power.d. > Anyone who cares high frequency of load/unload cycles on some hard disks can > refering > http://wiki.archlinux.org/index.php/Pm-utils to hack the pm-utils. The hook in sleep.d is not required in Fedora, because it should be already handled. I just wrote a mail to pm-utils devel mailinglist to decide whether the Fedora hook should be included in the upstream release. Regards Till pgplSqYXLGUW9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 567633] Cannot upload package to Redhat Satellite Server because of "RPM Requires"-Problem
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=567633 Chris Weyl changed: What|Removed |Added Status|NEW |CLOSED Resolution||NOTABUG --- Comment #5 from Chris Weyl 2010-02-24 12:46:43 EST --- Hey Patrick, Jan -- That's good to hear. Duplicate rpm dependency metadata is a prefectly legal situation for packages to be in, that we often find ourselves in packages with only auto-generated metadata. e.g., looking at the running kernel package on my machine, I see mutiple duplicate deps: [cw...@zeus perl-MooseX-Types-JSON]$ rpmquery --requires kernel-2.6.31.12-174.2.22.fc12.x86_64 rpmlib(VersionedDependencies) <= 3.0.3-1 fileutils module-init-tools initscripts >= 8.11.1-1 kernel-firmware >= 2.6.31.12-174.2.22.fc12 grubby >= 7.0.4-1 dracut >= 001-7 /sbin/new-kernel-pkg /sbin/new-kernel-pkg /bin/sh /bin/sh /bin/sh rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadIsXz) <= 5.2-1 S... Nothing against Spacewalk, but having duplicate requires/provides from any source in rpm metadata is perfectly legal, and perfectly expected. The situation you're describing in this ticket is not a perl-DBIx-Class bug at any level, but rather a problem being caused by an artificial limit of Spacewalk. That being said, I'd much prefer to have dependency metadata as trim as reasonably possible... But rpm does not give us the tools to easily do this, particularly when trying to work with both automatic (which can be incomplete) and manual (which tend to be more precise for Perl) data. If you can get the rpm team to give us easy access to the auto and manual dep streams from inside an rpm spec (either lua or rpm macro) so we can do this easily, I will forever be your friend :) This is NOTABUG of perl-DBIx-Class. -- 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 567630] Some packages have duplicate 'rpmlib(VersionedDependencies)' requires
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=567630 Chris Weyl changed: What|Removed |Added Status|NEW |CLOSED Resolution||NOTABUG --- Comment #7 from Chris Weyl 2010-02-24 12:47:49 EST --- Looks like most of the perl-* packages mentioned above are mine, so I'm going to go ahead and mark this as NOTABUG for all the reasons described in bug 567633. -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
pthreads linking in devel/F-13 issue
Does someone know why this is going wrong? -- Forwarded message -- Date: Wed, 24 Feb 2010 18:32:54 +0100 From: W.C.A. Wijngaards To: unbound-us...@unbound.net Subject: Re: [Unbound-users] unbound linking bug with pthreads -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Paul, Unbound uses http://www.nongnu.org/autoconf-archive/acx_pthread.html in acx_pthread.m4. It uses configure-style compilation tests to see what works, and tries -pthread (CFLAGS) and later -lpthread (LIBS). It does not try both at once. For me, I end up with -pthread in the CFLAGS. This is included on the commandline when linking. Perhaps -pthread is enough when linking, or does it have to be -lpthread ? If so, the configure test to link with - -pthread should be failing and perhaps a test added to the macro and submitted upstream. If the new system has pthread-config you can set both cflags and libs with that, no patch required. Best regards, Wouter On 02/24/2010 05:37 PM, Paul Wouters wrote: > > Hi, > > Fedora 13 will no longer implicitely link in certain libraries. For > a full description see: > > https://fedoraproject.org/wiki/UnderstandingDSOLinkChange > > This is happening with unbound and the pthreads library. So we need to > pass it a -lpthreads when we are compiling with --with-pthreads. > > I'm not a "configure" expert, so while I do see some tests in configure, > I don't understand where it remembers the additional -lpthread argument > which needs to be added to the Makefile's LIBS= > > Currently, on my Linux machine which ran with --with-phtreads, I see in > Makefile: > > LIBS=$(strip -lldns -levent -lrt -lcrypto) > > This is missing -lpthread > > Paul -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkuFYsYACgkQkDLqNwOhpPiKFwCeLJ3fwcO7Ye4Kp+bq/LuVIyn1 1B4AoILnaK2bP8SJ9PePI1Xw6Oa/5euf =yj7Q -END PGP SIGNATURE- ___ Unbound-users mailing list unbound-us...@unbound.net http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100224 changes
Compose started at Wed Feb 24 09:15:15 UTC 2010 Broken deps for i386 -- balsa-2.4.6-3.fc13.i686 requires libgmime-2.4.so.2 blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28 doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5 edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 frepple-0.7.1-1.fc13.i686 requires libxerces-c.so.28 fusecompress-2.6-3.fc12.i686 requires libboost_serialization-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_system-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_program_options-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_iostreams-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_filesystem-mt.so.5 gnome-python2-totem-2.29.1-4.fc13.i686 requires libtotem-plparser.so.12 koan-2.0.3.1-1.fc13.noarch requires mkinitrd kst-fits-1.8.0-5.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-5.fc12.i686 requires libnetcdf_c++.so.4 kst-netcdf-1.8.0-5.fc12.i686 requires libnetcdf.so.4 libvirt-qpid-0.2.17-3.fc12.i686 requires qpidc >= 0:0.5.790661 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 matahari-0.0.4-7.fc13.i686 requires qpidc >= 0:0.5.819819 ovaldi-5.5.25-2.fc13.i686 requires libxerces-c.so.28 ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc perl-Archive-RPM-0.05-1.fc13.noarch requires perl(MooseX::Types::DateTimeX) perl-Fedora-Bugzilla-0.13-2.fc13.noarch requires perl(MooseX::Types::DateTimeX) python-vcpx-0.9.35-7.fc12.noarch requires bazaar qmf-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-rdma-0.5.819819-4.fc13.i686 requires qpidc-client-rdma = 0:0.5.819819-4.fc13 qpidc-server-ssl-0.5.819819-4.fc13.i686 requires qpidc-client-ssl = 0:0.5.819819-4.fc13 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 -- balsa-2.4.6-3.fc13.x86_64 requires libgmime-2.4.so.2()(64bit) blahtexml-0.6-5.fc12.x86_64 requires libxerces-c.so.28()(64bit) doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 doodle-0.6.7-5.fc12.x86_64 requires libextractor.so.1()(64bit) easystroke-0.5.2-1.fc13.x86_64 requires libboost_serialization-mt.so.5()(64bit) edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 edje-0.9.9.050-6.fc12.x86_64 requires libembryo.so.0()(64bit) frepple-0.7.1-1.fc13.i686 requires libxerces-c.so.28 frepple-0.7.1-1.fc13.x86_64 requires libxerces-c.so.28()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_system-mt.so.5()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_program_options-mt.so.5()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_iostreams-mt.so.5()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_filesystem-mt.so.5()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_serialization-mt.so.5()(64bit) gnome-python2-totem-2.29.1-4.fc13.x86_64 requires libtotem-plparser.so.12()(64bit) koan-2.0.3.1-1.fc13.noarch requires mkinitrd kst-fits-1.8.0-5.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-5.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-5.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) libvirt-qpid-0.2.17-3.fc12.x86_64 requires qpidc >= 0:0.5.790661 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) matahari-0.0.4-7.fc13.x86_64 requires qpidc >= 0:0.5.819819 ovaldi-5.5.25-2.fc13.x86_64 requires libxerces-c.so.28()(64bit) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc perl-Archive-RPM-0.05-1.fc13.noarch requires perl(MooseX::Types::DateTimeX) perl-Fedora-Bugzilla-0.13-2.fc13.noarch requires perl(MooseX::Types::DateTimeX) python-vcpx-0.9.35-7.fc12.noarch requires bazaar qmf-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qmf-devel-0.5.819819-4.fc13.x86_64 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-devel-0.5.819819-4.fc13.x86_64 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-rdma-0.5.819819-4.fc13.x86_64 requires qpidc-client-rdma = 0:0.5.819819-4.fc13 qpidc-server-ssl-0.5.819819-4.fc13.x86_64 requires qpidc-cli
[Bug 567633] Cannot upload package to Redhat Satellite Server because of "RPM Requires"-Problem
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=567633 --- Comment #8 from Till Maas 2010-02-24 13:27:59 EST --- (In reply to comment #7) > Hmm, but does Spacewalk differentiate that? I am pretty sure, because otherwise every package with two kind of scriptlets would fail there. -- 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
Incompatible upgrade - Is this workaround ok? (mysql-mmm)
Hello all, I maintain Multi-Master Replication Manager for MySQL in both Fedora and EPEL. With changes from 2.0.11 -> 2.1.0 there was an incompatible change in that the daemon scripts were renamed: mmmd_agent -> mmm_agentd mmmd_mon -> mmm_mond Upgrades obviously break because the INIT scripts and configuration files reference the path to the files. Would a sufficient work-around be a symlink to the old path, or would that not be kosher for any reason? Thank you for your feedback. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Net-Patricia-1.16.tar.gz uploaded to lookaside cache by philipp
A file has been added to the lookaside cache for perl-Net-Patricia: 0b3d6bdc2426ababe0c95304fd58d6eb Net-Patricia-1.16.tar.gz -- 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
Re: Call for F13 release slogan suggestions
On 24 February 2010 08:52, Jon Masters wrote: > On Tue, 2010-02-23 at 22:06 -0700, Robyn Bergeron wrote: > >> * short (1-3 words) > > Well, some to avoid anyway... > > Lucky for You! > Have More Fun! > For Great Justice! > > ;) > What you say? -- Mat Booth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for F13 release slogan suggestions
How about... Prepare for launch Escape velocity Throttle up Go supernova Ignite -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Help needed: patching EMBOSS to use system pcre, expat and zlib
Hello, EMBOSS 6.2.0 bundles zlib, expat and pcre. In the previous version, I got help from a fellow packager to patch the pcre out, but that patch no longer works. Thus, I'd like to ask for help in solving this problem, which is unfortunately beyond my skills. Ideally, I'd gladly accept a co-maintainer for this bioinformatics suite. I have built the package with bundled libs for devel for the time being, so that potential helpers have access to the latest spec file. Regards, Julian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: switching from man to man-db
On Wed, 24 Feb 2010 13:34:00 +0100 Ivana Hutarova Varekova wrote: > Hello, > I'd like to switch from man > (http://primates.ximian.com/~flucifredi/man/) to man-db project > (http://man-db.nongnu.org/). > man-db seems for me to be better choice then the original man. The > reasons are: > * the upstream very active in man-db, man upstream almost does not > response and the last version was released in 2007 > * because of the previous comment man-db have more features then man > * man-db uses Berkeley db instead of text file for the index of man > pages > * Debian, Ubuntu, SuSE use man-db > As the first step I want to add man-db to fedora cvs. > Comments welcomed. I think this is a good idea. This would of course need to be a new package that would either not conflict with or simply obsolete/replace the existing man-db package, right? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for F13 release slogan suggestions
Hi, Okay, doesn't comply with the rules... I'm a PC and Fedora 13 is what I was *really* thinking ;-) TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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: hdparm -B for netbooks
On Wed, 2010-02-24 at 16:44 +, Matthew Garrett wrote: > On Wed, Feb 24, 2010 at 05:07:44PM +0100, Richard Zidlicky wrote: > > > Whatever the reason, many users think it is better to change the setting - > > is there > > any reason why the power manager should not make it really easy? > > Yes - it's an option that's basically impossible to expose in a UI in a > sensible way. Besides, 'expose every setting that some article on the internet claims makes everything faster/better/stabler/shinier' is not a sensible method for designing UIs. -- 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: Call for F13 release slogan suggestions
On Tue, 2010-02-23 at 22:06 -0700, Robyn Bergeron wrote: > > * short (1-3 words) > * a call to action > * positive > > So, "Houston, we have a problem." is not acceptable? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Call for F13 release slogan suggestions
On Wed, 24 Feb 2010, Jesse Keating wrote: > On Tue, 2010-02-23 at 22:06 -0700, Robyn Bergeron wrote: >> >> * short (1-3 words) >> * a call to action >> * positive >> >> > > So, "Houston, we have a problem." is not acceptable? > With absolutely no reference to any other linux distribution naming scheme - could the slogan be "To infinity and beyond!"? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for F13 release slogan suggestions
On Wed, Feb 24, 2010 at 10:22 PM, Seth Vidal wrote: > > > On Wed, 24 Feb 2010, Jesse Keating wrote: > >> On Tue, 2010-02-23 at 22:06 -0700, Robyn Bergeron wrote: >>> >>> * short (1-3 words) >>> * a call to action >>> * positive >>> >>> >> >> So, "Houston, we have a problem." is not acceptable? >> > > With absolutely no reference to any other linux distribution naming scheme > - could the slogan be "To infinity and beyond!"? -EMORETHANTHREEWORDS ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdparm -B for netbooks
On Wed, Feb 24, 2010 at 08:07:50AM +0100, Thorsten Leemhuis wrote: > And what does Windows do? I have the strange feeling it doesn't assume > the same and instead simply sets something it thinks is sensible, which > afaics results in Hardware manufactures not to care much what the > initial value for the drive is or what the BIOS sets. If that's the case > (I never checked and am not familiar with Windows enough to know) then > wouldn't it be the most sensible thing to do something similar? I've just checked again to confirm this. Windows (XP, at least) doesn't change the value, whatever the original value is. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 13 Alpha Go/No-Go Meeting RESCHEDULED: 2010-02-25 @ 19:00 UTC (14:00 EST)
IMPORTANT NOTE: we are rescheduling the Go/No-Go meeting for Fedora 13 Alpha. Previously scheduled for 2010-02-25 01:00 UTC, it is now scheduled for 2010-02-25 19:00 UTC (14:00 EST, 11:00 PST). This delay is to give sufficient time for the QA team to test the expected RC3 build. The original announcement, with the new time, is reproduced below for reference. Join us on irc.freenode.net #fedora-meeting for this important meeting. Thursday, February 25, 2010 @ 19:00 UTC (14:00 EST). "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 important meeting see: https://fedoraproject.org/wiki/Engineering_Readiness_Meetings -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ 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: hdparm -B for netbooks
Further, it loses the settings over suspend/resume. Can we stop blaming this on distributions now? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for F13 release slogan suggestions
> > > * short (1-3 words) Have about The dog's bollocks http://www.urbandictionary.com/define.php?term=Dog%27s%20Bollocks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for F13 release slogan suggestions
On 24/02/10 21:17, Jesse Keating wrote: > On Tue, 2010-02-23 at 22:06 -0700, Robyn Bergeron wrote: >> >> * short (1-3 words) >> * a call to action >> * positive >> >> > > So, "Houston, we have a problem." is not acceptable? > > Might not translate but "Lucky for Most" -- Regards, Frank Murphy UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: make sure programs are linked against the libraries they use
specifically, -lpthread - some programs have references to symbols in -lpthread but were not linking against them directly, but were finding the symbols resolved indirectly through another library. This cause the build to fail on Fedora 13 and other platforms with strict linkers. https://bugzilla.redhat.com/show_bug.cgi?id=564876 https://bugzilla.redhat.com/attachment.cgi?id=396176&action=diff https://bugzilla.redhat.com/attachment.cgi?id=396176&action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[Bug 568172] virt-top exits sometimes when the window is resized
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=568172 --- Comment #1 from Richard W.M. Jones 2010-02-24 17:41:11 EST --- I don't know if we're planning a rebase of libvirt which will get this fix for free. But if not, then we really do need this fix to be in RHEL 6, since it manifests as an annoying and obvious bug in virt-top. -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 568172] New: virt-top exits sometimes when the window is resized
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: virt-top exits sometimes when the window is resized
https://bugzilla.redhat.com/show_bug.cgi?id=568172
Summary: virt-top exits sometimes when the window is resized
Product: Red Hat Enterprise Linux 6
Version: 6.0
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: libvirt
AssignedTo: veill...@redhat.com
ReportedBy: rjo...@redhat.com
QAContact: virt-b...@redhat.com
CC: veill...@redhat.com, berra...@redhat.com,
rjo...@redhat.com, ita...@ispbrasil.com.br,
clala...@redhat.com, xen-ma...@redhat.com,
crobi...@redhat.com, fedora-virt-ma...@redhat.com,
fedora-ocaml-l...@redhat.com, jfor...@redhat.com
Depends on: 567931
Group: rhel_beta
Classification: Red Hat
Target Release: ---
Clone Of: 567931
+++ This bug was initially created as a clone of Bug #567931 +++
Description of problem:
virt-top exits sometimes (clean exit with code 1, not a segfault)
when the window is resized.
Version-Release number of selected component (if applicable):
virt-top-1.0.4-3.fc13.x86_64
Also observed with the Debian virt-top package.
How reproducible:
Sometimes.
Steps to Reproduce:
1. sudo virt-top -d 0.1 --debug /tmp/debug
2. Resize the window aggressively.
3.
Actual results:
Occasionally virt-top exits.
Expected results:
Should not exit.
Additional info:
Original report:
http://rwmj.wordpress.com/2010/02/23/virt-top-is-in-debian/#comment-1256
--- Additional comment from rjo...@redhat.com on 2010-02-24 06:45:55 EST ---
This bug is quite hard to reproduce anyway, but it seems like it
doesn't happen at all when virt-top is run under gdb. Possibly
gdb alters the way that signals are delivered.
--- Additional comment from rjo...@redhat.com on 2010-02-24 06:50:03 EST ---
I think this is actually a libvirt bug. The strace output
when it exits is:
18863 rt_sigaction(SIGTSTP, {0x3e77e192f0, [], SA_RESTORER|SA_RESTART,
0x3e75a337d0}, NULL, 8) = 0
18863 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
18863 poll([{fd=3, events=POLLOUT}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=3,
revents=POLLOUT}])
18863 sendto(3, "\0\0\0\34 \0\200\206\0\0\0\1\0\0\0003\0\0\0\0\0\0\0r\0\0\0\0",
28, 0, NULL, 0) = 28
18863 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=3,
revents=POLLIN}])
18863 recvfrom(3, "\0\0\1h", 4, 0, NULL, NULL) = 4
18863 recvfrom(3, "
\0\200\206\0\0\0\1\0\0\0\25\0\0\0\1\0\0\0q\0\0\0\0\0\0\0\21\0\0\0\21RHEL6200910210x32\0\0\0\0\0\0\vTmpBZ552994\0\0\0\0\21RHEL6201002033x64\0\0\0\0\0\0\nDebian5x64\0\0\0\0\0\fUbuntu910x64\0\0\0\16RHEL6Alpha3x64\0\0\0\0\0\rRHEL54Betax64\0\0\0\0\0\0\6F10x32\0\0\0\0\0\nCentOS5x32\0\0\0\0\0\rF13Rawhidex64\0\0\0\0\0\0\16TmpDebFirewall\0\0\0\0\0\rF12x64preview\0\0\0\0\0\0\nWin2003x32\0\0\0\0\0\7VSphere\0\0\0\0\vWindows7x32\0\0\0\0\vWindows7x64\0\0\0\0\vFreeBSD8x64\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
356, 0, NULL, NULL) = 356
18863 write(2, "libvir: Remote error : no call waiting for reply with serial
113\n", 65) = 65
18863 write(1, "\33[17;1H\33[2J\33[?47l\0338\r\33[?1l\33>", 27) = 27
18863 ioctl(1, SNDCTL_TMR_STOP or TCSETSW, {B9600 opost isig icanon echo ...})
= 0
18863 write(2, "libvirt: VIR_ERR_RPC: VIR_FROM_REMOTE: no call waiting for
reply with serial 113\n", 81) = 81
18863 exit_group(1) = ?
I wonder if this is a regression (see bug 484414).
My libvirt version is:
libvirt-0.7.5-3.fc13.x86_64
--- Additional comment from rjo...@redhat.com on 2010-02-24 06:52:40 EST ---
Also occurs with
libvirt-0.7.6-1.fc13.x86_64
The strace this time is roughly the same:
18952 recvfrom(3, "\0\0\1h", 4, 0, NULL, NULL) = 4
18952 recvfrom(3, "
\0\200\206\0\0\0\1\0\0\0\25\0\0\0\1\0\0\6O\0\0\0\0\0\0\0\21\0\0\0\21RHEL6200910210x32\0\0\0\0\0\0\vTmpBZ552994\0\0\0\0\21RHEL6201002033x64\0\0\0\0\0\0\nDebian5x64\0\0\0\0\0\fUbuntu910x64\0\0\0\16RHEL6Alpha3x64\0\0\0\0\0\rRHEL54Betax64\0\0\0\0\0\0\6F10x32\0\0\0\0\0\nCentOS5x32\0\0\0\0\0\rF13Rawhidex64\0\0\0\0\0\0\16TmpDebFirewall\0\0\0\0\0\rF12x64preview\0\0\0\0\0\0\nWin2003x32\0\0\0\0\0\7VSphere\0\0\0\0\vWindows7x32\0\0\0\0\vWindows7x64\0\0\0\0\vFreeBSD8x64\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
356, 0, NULL, NULL) = 356
18952 write(2, "libvir: Remote error : no call waiting for reply with serial
1615\n", 66) = 66
18952 write(1, "\33[26;1H\33[2J\33[?47l\0338\r\33[?1l\33>", 27) = 27
18952 ioctl(1, SNDCTL_TMR_STOP or TCSETSW, {B9600 opost isig icanon echo ...})
= 0
18952 write(2, "libvirt: VIR_ERR_RPC: VIR_FROM_REMOTE: no call waiting for
reply with serial 1615\n", 82) = 82
18952 exit_group(1) = ?
--- Additional comment from rjo...@re
[Bug 567931] virt-top exits sometimes when the window is resized
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=567931 Richard W.M. Jones changed: What|Removed |Added Blocks||568172 -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: pthreads linking in devel/F-13 issue
-pthread is indeed sufficient when it's really given to the linking $CC run.
> Does someone know why this is going wrong?
In unbound.spec I see:
%{__make} CFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE" QUIET=no %{?_smp_mflags}
This overrides the CFLAGS setting written into Makefile by configure.
You should never override CFLAGS in this way.
The place to set CFLAGS is in the configure line.
You use %configure, which uses CFLAGS="${CFLAGS:-%optflags}".
(%optflags is the same as $RPM_OPT_FLAGS.)
So what would work is:
%configure ... \
CFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE"
However, what I would really suggest is that you instead put -D_GNU_SOURCE
into CFLAGS in the source package itself. If you need that, it should not
be a Fedora-specific issue. e.g., early in configure.ac you can use:
CFLAGS="$CFLAGS -D_GNU_SOURCE"
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 Alpha Go/No-Go Meeting RESCHEDULED: 2010-02-25 @ 19:00 UTC (14:00 EST)
On Wed, Feb 24, 2010 at 01:57:02PM -0800, Adam Williamson wrote: > IMPORTANT NOTE: we are rescheduling the Go/No-Go meeting for Fedora 13 > For more details about this important meeting see: > https://fedoraproject.org/wiki/Engineering_Readiness_Meetings IMHO it would help a lot if there weren't always at least two names for every event or task. E.g. on http://poelstra.fedorapeople.org/schedules/f-13/f-13-all-tasks.html there are the "Alpha Go/No-Go Meeting (20:00 EST)" and the "Alpha Project Wide Release Readiness Meeting" Now also using "Engineering Readiness Meetings" is very easy to confuse with the other meeting, especially because both happen within about 24 hours or not. Regards Till pgp9LfyBMdoVU.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 568172] virt-top exits sometimes when the window is resized
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=568172 --- Comment #2 from RHEL Product and Program Management 2010-02-24 17:59:52 EST --- This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion. -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: pthreads linking in devel/F-13 issue
On Wed, 24 Feb 2010, Roland McGrath wrote:
Thanks for the reply.
> -pthread is indeed sufficient when it's really given to the linking $CC run.
>
>> Does someone know why this is going wrong?
>
> In unbound.spec I see:
>
> %{__make} CFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE" QUIET=no %{?_smp_mflags}
>
> This overrides the CFLAGS setting written into Makefile by configure.
Though CFLAGS is not the issue, LIBS= is.
> So what would work is:
>
> %configure ... \
> CFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE"
That fails with:
+ cd /builddir/build/BUILD
+ cd unbound-1.4.1
+ LANG=C
+ export LANG
+ unset DISPLAY
+ CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
-fasynchronous-unwind-tables'
+ export CFLAGS
+ CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
-fasynchronous-unwind-tables'
+ export CXXFLAGS
+ FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
-fasynchronous-unwind-tables -I/usr/lib/gfortran/modules'
+ export FFLAGS
+ ./configure --build=i386-redhat-linux-gnu --host=i386-redhat-linux-gnu
--program-prefix= --disable-dependency-tracking --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib
--mandir=/usr/share/man --infodir=/usr/share/info --with-ldns= --with-libevent
--with-pthreads --with-ssl --disable-rpath --enable-debug --disable-static
--with-conf-file=/etc/unbound/unbound.conf
--with-pidfile=/var/run/unbound/unbound.pid --enable-sha2 'CFLAGS=-O2 -g -pipe
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
-fasynchronous-unwind-tables -D_GNU_SOURCE QUIET=no'
checking for i386-redhat-linux-gnu-gcc... no
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: in `/builddir/build/BUILD/unbound-1.4.1':
configure: error: C compiler cannot create executables
See `config.log' for more details.
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pthreads linking in devel/F-13 issue
> Though CFLAGS is not the issue, LIBS= is. You are mistaken. Your configure check decides -pthread alone is sufficient (which it is), and that is all it sets. If your configure put -lpthread into LIBS, then you would not have a problem. The substitution of LIBS into the makefile is working fine. > > So what would work is: > > > > %configure ... \ > >CFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE" > > That fails with: [...] > + ./configure --build=i386-redhat-linux-gnu --host=i386-redhat-linux-gnu > --program-prefix= --disable-dependency-tracking --prefix=/usr > --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc > --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib > --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib > --mandir=/usr/share/man --infodir=/usr/share/info --with-ldns= > --with-libevent --with-pthreads --with-ssl --disable-rpath --enable-debug > --disable-static --with-conf-file=/etc/unbound/unbound.conf > --with-pidfile=/var/run/unbound/unbound.pid --enable-sha2 'CFLAGS=-O2 -g > -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom > -fasynchronous-unwind-tables -D_GNU_SOURCE QUIET=no' This indicates you wrote : %configure ... \ CFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE QUIET=no" QUIET=no belongs outside of quotes. It also does not serve any purpose there at all. Leave it on your make line as you had it before. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up! Broken deps in Upgrade from 12 to 13
Hi, On 02/21/2010 02:15 AM, Michael Schwendt wrote: >Upgrade from 12+updates to 13+updates+testing > == > Broken packages in fedora-updates-12-i386: > mono-moonlight-2.4.3.1-1.fc12.i686 requires mono-core = 0:2.4.3.1-1.fc12 > == > Broken packages in fedora-updates-12-x86_64: > mono-moonlight-2.4.3.1-1.fc12.x86_64 requires mono-core = > 0:2.4.3.1-1.fc12 Both problems should be fixed with https://admin.fedoraproject.org/updates/mono-2.6.1-2.fc13 Michael, where can I find the script you have used for generating the list of broken update paths? Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:Re: hdparm -B for netbooks
The NTFS and ext4 are differernt, though XP also doesn't change the value. 在2010-02-25?05:59:36，"Matthew?Garrett"??写道： >Further,?it?loses?the?settings?over?suspend/resume.?Can?we?stop?blaming? >this?on?distributions?now? > >--? >Matthew?Garrett?|?mj...@srcf.ucam.org >--? >devel?mailing?list >devel@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Incompatible upgrade - Is this workaround ok? (mysql-mmm)
On Wed, Feb 24, 2010 at 11:36 AM, BJ Dierkes wrote: > Hello all, > > I maintain Multi-Master Replication Manager for MySQL in both Fedora and > EPEL. With changes from 2.0.11 -> 2.1.0 there was an incompatible change in > that the daemon scripts were renamed: > > mmmd_agent -> mmm_agentd > mmmd_mon -> mmm_mond > I think this will need someone from Fedora packaging to comment versus EPEL (as that would have precedence.) My un-educated opinion is that there would not be a problem with symlinks if its for files. [Symlinks for directories I think causes RPM heartburn somewhere but thats a vague recollection.] > Upgrades obviously break because the INIT scripts and configuration files > reference the path to the files. Would a sufficient work-around be a symlink > to the old path, or would that not be kosher for any reason? > > Thank you for your feedback. > > --- > derks > > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:Incompatible upgrade - Is this workaround ok? (mysql-mmm)
It's not problem to update mysql-mmm to the latest version for F13 and devel soon. For F11 F12 and EPEL5, you need write Scriptlet in the pre and check the startlevel of mmmd_agent and mmmd_mon, then you can adapt the startlevel mmmd_agent based on mmm_agentd and mmmd_mon based on mmm_mond. There may be some more hack to do for configuration?files. I think symlink isn't a good idea. 在2010-02-25?02:36:31，"BJ?Dierkes"??写道： >Hello?all, > >I?maintain?Multi-Master?Replication?Manager?for?MySQL?in?both?Fedora?and?EPEL.??With?changes?from?2.0.11?->?2.1.0?there?was?an?incompatible?change?in?that?the?daemon?scripts?were?renamed: > >mmmd_agent?->?mmm_agentd >mmmd_mon?->?mmm_mond > > >Upgrades?obviously?break?because?the?INIT?scripts?and?configuration?files?reference?the?path?to?the?files.??Would?a?sufficient?work-around?be?a?symlink?to?the?old?path,?or?would?that?not?be?kosher?for?any?reason? > >Thank?you?for?your?feedback. > >--- >derks > > > >--? >devel?mailing?list >devel@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdparm -B for netbooks
Matthew Garrett wrote: > Yes - it's an option that's basically impossible to expose in a UI in a > sensible way. How so? "Spindown timeout", "Advanced power management timeout", and a slider with 256 entries (or 240 or whatever the number of non-weird ones is) looks quite sensible to me. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: switching from man to man-db
Kevin Fenzi wrote: > This would of course need to be a new package that would either not > conflict with or simply obsolete/replace the existing man-db package, > right? I'd say Obsoletes/Provides is the best solution. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:Help needed: patching EMBOSS to use system pcre, expat and zlib
Hi Julian, I think you should first confirm if the bundled zlib,?expat?and?pcre was heavily changed compared to the system-wide libs. If they are heavily changed, you maybe need use bundled version. otherwise it must be patched to avoid using bundled libs. 在2010-02-25?04:28:33，"Julian?Sikorski"??写道： >Hello, > >EMBOSS?6.2.0?bundles?zlib,?expat?and?pcre.?In?the?previous?version,?I >got?help?from?a?fellow?packager?to?patch?the?pcre?out,?but?that?patch?no >longer?works.?Thus,?I'd?like?to?ask?for?help?in?solving?this?problem, >which?is?unfortunately?beyond?my?skills. >Ideally,?I'd?gladly?accept?a?co-maintainer?for?this?bioinformatics?suite. >I?have?built?the?package?with?bundled?libs?for?devel?for?the?time?being, >so?that?potential?helpers?have?access?to?the?latest?spec?file. > >Regards, >Julian > >--? >devel?mailing?list >devel@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
scythia-0.9.3-5.fc14 (was: Re: rawhide report: 20100224 changes)
Rawhide Report wrote: > scythia-0.9.3-5.fc14 > > * Tue Feb 23 2010 Haïkel Guémar - 0.9.3-5 > - Rebuilt against Qt 4.6.2 Uh, was this really necessary? Qt 4.6.2 is normally backwards-compatible with 4.5.x. In addition, you queued updates for this for F11 and F12, but not F13. As F13 is frozen, it will NOT automatically pick up a build, you need to push it through Bodhi as well (and stuff pushed at this time will end up in the F13 release, not in updates). So you're breaking the upgrade path. Please also push this to F13 in Bodhi. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: scythia-0.9.3-5.fc14 (was: Re: rawhide report: 20100224 changes)
I wrote: > Uh, was this really necessary? Qt 4.6.2 is normally backwards-compatible > with 4.5.x. PS: Running application X built against Qt 4.5.x with Qt 4.6.x SHOULD work. Running application X built against Qt 4.6.x with Qt 4.5.x WILL NOT work (and this is why pushing apps built against a new Qt to stable BEFORE that Qt gets pushed to stable is a bad idea, but rebuilding appliations for the new Qt is normally NOT needed). This is known as one-way (backwards only) compatibility, and quite common. That said, some applications do need to be rebuilt due to backwards compatibility issues, or get more features when rebuilt against a newer Qt. But as you did not include a Bugzilla reference nor any other form of rationale, I can't figure out why you rebuilt this particular application. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: scythia-0.9.3-5.fc14
Le 25/02/2010 05:32, Kevin Kofler a écrit : > > PS: > Running application X built against Qt 4.5.x with Qt 4.6.x SHOULD work. > Running application X built against Qt 4.6.x with Qt 4.5.x WILL NOT work > (and this is why pushing apps built against a new Qt to stable BEFORE that > Qt gets pushed to stable is a bad idea, but rebuilding appliations for the > new Qt is normally NOT needed). > This is known as one-way (backwards only) compatibility, and quite common. > > That said, some applications do need to be rebuilt due to backwards > compatibility issues, or get more features when rebuilt against a newer Qt. > But as you did not include a Bugzilla reference nor any other form of > rationale, I can't figure out why you rebuilt this particular application. > > Kevin Kofler > I experienced few network hangs-up using Scythia/Qt 4.6.x, recompiling seemed to solve them. Since Qt 4.6.x wasn't in package collection yet, there was no ticket in RHBZ. Thanks for reporting about the F-13 build, that's an oversight. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: switching from man to man-db
On 02/25/2010 05:13 AM, Kevin Kofler wrote: > Kevin Fenzi wrote: > >> This would of course need to be a new package that would either not >> conflict with or simply obsolete/replace the existing man-db package, >> right? >> > I'd say Obsoletes/Provides is the best solution. > > Kevin Kofler > > Yes I agree, the idea is to add obsolete/provides. Man-db have the a lot of functionality which is the same with man, so theer are a lot of conflicts and if the package will replace man, the it has no sense to rename or remove conflicting files from man-db. Ivana Hutarova Varekova -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdparm -B for netbooks
Matthew Garrett wrote on 24.02.2010 22:59: > Further, it loses the settings over suspend/resume. Can we stop blaming > this on distributions now? Then why do a lot of drive load and unload frequently when running a linux-distribution but do not when running the operating system the Verndor pre-loaded? That's afaics what a lot of people seem to see. I had such a laptop myself (in fact I still have it, but I replaced the HDD with a SSD last fall) and had ten different models here in the lab months (maybe more than a year) ago that showed such a behavior... CU knurd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
