Re: The new Update Acceptance Criteria are broken
On 11/23/2010 06:51 AM, Ralf Corsepius wrote: IMO, the real problem is not backports vs. upgrading to fix bugs, it's bugs not getting fixed in Fedora, for a variety of reasons. Therefore, I consider trying to apply any such simple policy to be impossible and naive. Agreeable logical conclusion. The underlying problem needs to get address and fixed first. I proposed this as a possible long term solution in one rough possible way a bit back on a different list to try to address the underlying issue but I did not receive any feedback on that proposal. 1. Improve the general standard of packagers ( need to at least have upstream bugzilla account and are part of or in good communication with the upstream community ) 2 Allow for a adjusting period when it's over revoke the rights from those that already have but do not full fill this requirements. Package goes up for grabs or gets dropped. 2. Allow all maintainers to touch every component in Fedora note that maintainer that brought the component to Fedora is still responsible for his components. 3. Gather what information from all those maintainers we have in the community what their code skill are and in which language and what skill level their expertise is. 4. Assemble a bug fixing task force ( can be per language ) to target component ( including testers if needed ). 5. Assign a component to the bug fixing task force and assign a time period they should spend looking at the bugs on that component and fixing them could be a day a week a month starting from critical path and onwards. 6. Assign interns ( students home hackers and what not ) to tag along the bug fixing task force and learn a few things.. Note that there could be several bug fixing task force working at the same time but in different programming language and based on what skill level they have as newbies could take the first rounds tackle the easy fixers push what they cant fix to the medium team which then goes through it if they cant handle it they push it on to the heavy hitters who will strike upon it with furious vengeance and squash that bug to a different dimension.. If and when something like above is ready then we can start small with procedure we know. create proven $language coders groups which maintainers sign up for Reverse the roles of testers and maintainers and host a bug squash day! QA decide which components needs addressing and contacts the relevant proven $language coders. Triagers run through the bugs list on the component the day(s) before and create a tracker bug with all the valid reports proven $language coders run through tracker bug list Testers stand ready on the sidelines during the code fiesta. Hopefully bunch of bugs get squashed and users live happily ever after or we find out this idea was great on paper but crap on field and we return back to the drawing board.. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File CPAN-Checksums-2.07.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-CPAN-Checksums: 586b4a829c5906ab4223616cab8595d9 CPAN-Checksums-2.07.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
[perl-CPAN-Checksums] New upstream release, v2.07
commit aef9502287e05b1bdb0bf988e34480c1f2dd5010
Author: Petr Sabata psab...@redhat.com
Date: Tue Nov 23 09:32:20 2010 +0100
New upstream release, v2.07
.gitignore |1 +
perl-CPAN-Checksums.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 23eb851..084f69b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
CPAN-Checksums-2.04.tar.gz
/CPAN-Checksums-2.05.tar.gz
/CPAN-Checksums-2.06.tar.gz
+/CPAN-Checksums-2.07.tar.gz
diff --git a/perl-CPAN-Checksums.spec b/perl-CPAN-Checksums.spec
index d10750f..4fa172b 100644
--- a/perl-CPAN-Checksums.spec
+++ b/perl-CPAN-Checksums.spec
@@ -1,6 +1,6 @@
Name: perl-CPAN-Checksums
-Version:2.06
-Release:3%{?dist}
+Version:2.07
+Release:1%{?dist}
Summary:Write a CHECKSUMS file for a directory as on CPAN
License:GPL+ or Artistic
Group: Development/Libraries
@@ -59,6 +59,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Nov 23 2010 Petr Sabata psab...@redhat.com - 2.07-1
+- New upstream release, v2.07
+
* Wed Oct 27 2010 Petr Pisar ppi...@redhat.com - 2.06-3
- 2.06 bump
diff --git a/sources b/sources
index a8a4f03..67f3b6d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6425bd8ee5bcac9fc50d84230f35928a CPAN-Checksums-2.06.tar.gz
+586b4a829c5906ab4223616cab8595d9 CPAN-Checksums-2.07.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: Fedora 15, new and exciting plans
On Sat, Nov 20, 2010 at 9:53 PM, Kevin Fenzi ke...@scrye.com wrote: On Sat, 20 Nov 2010 18:32:26 +0100 Michał Piotrowski mkkp...@gmail.com wrote: Hi, 2010/11/12 Kevin Fenzi ke...@scrye.com: Any other exciting work in progress that might land in F15 that people are actively working on? How about removing some old unix crud? (he said this and he saw that some people starts to gather firewood in the stack :)) Anyone uses gopher, uucp? I do use UUCP. ;) So do I. Its quite useful in particular circumstances. I'd have no problem with the uucp package making a user itself tho and dropping the user from base. I think it should be made by the package itself like all other users as per packaging guidelines. I'm also quite happy not to have it installed by default as I (and presumably pretty much everyone that would use it) would know how to yum install it and those that don't would likely get it via PackageKit-command-not-found Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Urgent: today's F14 catastrophe with openldap-servers update
While applying today's updates on a machine running a slapd server, the following error occurred: Stopping slapd: [ OK ] Checking configuration files for slapd: [FAILED] bdb(dc=linuxdev,dc=datasphere,dc=ch): Build signature doesn't match environment bdb_db_open: database dc=linuxdev,dc=datasphere,dc=ch cannot be opened, err -30971. Restore from backup! backend_startup_one (type=bdb, suffix=dc=linuxdev,dc=datasphere,dc=ch): bi_db_open failed! (-30971) slap_startup failed (test would succeed using the -u switch) stale lock files may be present in /var/lib/ldap[WARNING] /var/lib/ldap / / as a result, the ldap server is not running anymore, I cannot start it manually and I have no recent backup. I cannot even use slapcat (after update) on the current data. This is quite urgent since ldap data are heavily used by our applications. Please help ! Thanks Patrick -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
On Tue, 23 Nov 2010 11:11:13 +0100 Patrick MONNERAT wrote: While applying today's updates on a machine running a slapd server, the following error occurred: [...] Have you reported it as a bug against the openldap package? Have you tried yum downgrade to the previous version? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
On Tue, 2010-11-23 at 11:23 +0100, Michal Schmidt wrote: On Tue, 23 Nov 2010 11:11:13 +0100 Patrick MONNERAT wrote: While applying today's updates on a machine running a slapd server, the following error occurred: [...] Have you reported it as a bug against the openldap package? Not yet: I'm really busy trying to restore the production environment... Have you tried yum downgrade to the previous version? I've just done it: seems successful at first glance. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
usbip: how to build or find the driver
hi, I want share a usb key via IP and I have found this project: http://usbip.sourceforge.net/ Someone can help me to find the usbip_common_mod.ko, vhci-hcd.ko and usbip.ko module for fedora 14? Into Readme file of project, for build the driver i see this: For newer kernels ( =2.6.28 ), try linux-staging code! what is linux-staging code? where is the drivers? I'm not a kernel guru ... so ... please point me into right way In some other distro, like SuSe o AltLinux o mandr* there is a rpm package, bur for Fedora no. Thanks. -- Dario Lesca d.le...@solinos.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101123 changes
Compose started at Tue Nov 23 08:15:04 UTC 2010 Broken deps for x86_64 -- beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) bognor-regis-0.6.11-1.fc15.i686 requires libnotify.so.1 bognor-regis-0.6.11-1.fc15.x86_64 requires libnotify.so.1()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper digikam-1.5.0-1.fc15.x86_64 requires libkexiv2.so.8()(64bit) digikam-1.5.0-1.fc15.x86_64 requires libkipi.so.7()(64bit) digikam-1.5.0-1.fc15.x86_64 requires libmarblewidget.so.10()(64bit) digikam-1.5.0-1.fc15.x86_64 requires libkdcraw.so.8()(64bit) digikam-libs-1.5.0-1.fc15.i686 requires libkdcraw.so.8 digikam-libs-1.5.0-1.fc15.i686 requires libkipi.so.7 digikam-libs-1.5.0-1.fc15.i686 requires libkexiv2.so.8 digikam-libs-1.5.0-1.fc15.i686 requires libmarblewidget.so.10 digikam-libs-1.5.0-1.fc15.x86_64 requires libkexiv2.so.8()(64bit) digikam-libs-1.5.0-1.fc15.x86_64 requires libmarblewidget.so.10()(64bit) digikam-libs-1.5.0-1.fc15.x86_64 requires libkipi.so.7()(64bit) digikam-libs-1.5.0-1.fc15.x86_64 requires libkdcraw.so.8()(64bit) eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0 gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-gmail-notifier-0.10.1-1.fc14.x86_64 requires libnotify.so.1()(64bit) gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gshutdown-0.2-6.fc12.x86_64 requires libnotify.so.1()(64bit) gsql-0.2.1-4.fc12.i686 requires libnotify.so.1 gsql-0.2.1-4.fc12.x86_64 requires libnotify.so.1()(64bit) gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) ibus-fbterm-0.9.1-10.fc15.x86_64 requires libibus.so.2()(64bit) ibus-sunpinyin-2.0.2-2.fc15.x86_64 requires libibus.so.2()(64bit) intellij-idea-9.0.1.94.399-12.fc15.x86_64 requires commons-collections ircp-tray-0.7.4-1.fc14.x86_64 requires libnotify.so.1()(64bit) java-gnome-4.0.16-3.fc14.x86_64 requires libnotify.so.1()(64bit) kde-plasma-yawp-0.3.5-4.fc15.x86_64 requires libweather_ion.so.5()(64bit) 9:kdevelop-libs-4.1.0-2.fc15.i686 requires libkastencore.so.4 9:kdevelop-libs-4.1.0-2.fc15.i686 requires liboktetakastencore.so.4 9:kdevelop-libs-4.1.0-2.fc15.i686 requires liboktetakastengui.so.4 9:kdevelop-libs-4.1.0-2.fc15.i686 requires liboktetacore.so.4 9:kdevelop-libs-4.1.0-2.fc15.i686 requires liboktetakastencontrollers.so.4 9:kdevelop-libs-4.1.0-2.fc15.i686 requires liboktetagui.so.4 9:kdevelop-libs-4.1.0-2.fc15.i686 requires libkastencontrollers.so.4 9:kdevelop-libs-4.1.0-2.fc15.i686 requires libkastengui.so.4 9:kdevelop-libs-4.1.0-2.fc15.x86_64 requires liboktetakastencontrollers.so.4()(64bit) 9:kdevelop-libs-4.1.0-2.fc15.x86_64 requires libkastencore.so.4()(64bit) 9:kdevelop-libs-4.1.0-2.fc15.x86_64 requires liboktetakastencore.so.4()(64bit) 9:kdevelop-libs-4.1.0-2.fc15.x86_64 requires liboktetacore.so.4()(64bit) 9:kdevelop-libs-4.1.0-2.fc15.x86_64 requires liboktetakastengui.so.4()(64bit) 9:kdevelop-libs-4.1.0-2.fc15.x86_64 requires libkastengui.so.4()(64bit) 9:kdevelop-libs-4.1.0-2.fc15.x86_64 requires liboktetagui.so.4()(64bit) 9:kdevelop-libs-4.1.0-2.fc15.x86_64 requires libkastencontrollers.so.4()(64bit) kipi-plugins-1.5.0-3.fc15.x86_64 requires libkexiv2.so.8()(64bit) kipi-plugins-1.5.0-3.fc15.x86_64
Re: Urgent: today's F14 catastrophe with openldap-servers update
On 23/11/10 10:11, Patrick MONNERAT wrote: While applying today's updates on a machine running a slapd server, the following error occurred: Stopping slapd: [ OK ] Checking configuration files for slapd: [FAILED] bdb(dc=linuxdev,dc=datasphere,dc=ch): Build signature doesn't match environment bdb_db_open: database dc=linuxdev,dc=datasphere,dc=ch cannot be opened, err -30971. Restore from backup! backend_startup_one (type=bdb, suffix=dc=linuxdev,dc=datasphere,dc=ch): bi_db_open failed! (-30971) slap_startup failed (test would succeed using the -u switch) stale lock files may be present in /var/lib/ldap[WARNING] /var/lib/ldap / / as a result, the ldap server is not running anymore, I cannot start it manually and I have no recent backup. I cannot even use slapcat (after update) on the current data. This is quite urgent since ldap data are heavily used by our applications. Please help ! Just had the same thing happen to me. Worked around it by doing: # yum downgrade openldap openldap-servers openldap-clients # slapcat my.ldif # yum update openldap openldap-servers openldap-clients Remove contents of /var/lib/ldap except DB_CONFIG # slapadd my.ldif # chown ldap:ldap /var/lib/ldap/* # restorecon -rvF /var/lib/ldap # service slapd start It came back up OK. Looks like the new openldap is built against a different BerkeleyDB than the old one. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
On Tue, 23 Nov 2010, Paul Howarth wrote: On 23/11/10 10:11, Patrick MONNERAT wrote: While applying today's updates on a machine running a slapd server, the following error occurred: Stopping slapd: [ OK ] Checking configuration files for slapd: [FAILED] bdb(dc=linuxdev,dc=datasphere,dc=ch): Build signature doesn't match environment bdb_db_open: database dc=linuxdev,dc=datasphere,dc=ch cannot be opened, err -30971. Restore from backup! backend_startup_one (type=bdb, suffix=dc=linuxdev,dc=datasphere,dc=ch): bi_db_open failed! (-30971) slap_startup failed (test would succeed using the -u switch) stale lock files may be present in /var/lib/ldap[WARNING] /var/lib/ldap / / as a result, the ldap server is not running anymore, I cannot start it manually and I have no recent backup. I cannot even use slapcat (after update) on the current data. This is quite urgent since ldap data are heavily used by our applications. Please help ! Just had the same thing happen to me. Worked around it by doing: # yum downgrade openldap openldap-servers openldap-clients # slapcat my.ldif # yum update openldap openldap-servers openldap-clients Remove contents of /var/lib/ldap except DB_CONFIG # slapadd my.ldif # chown ldap:ldap /var/lib/ldap/* # restorecon -rvF /var/lib/ldap # service slapd start It came back up OK. Looks like the new openldap is built against a different BerkeleyDB than the old one. Yup, Berkeley DB is picky about its environment. It should be sufficient to to do 'rm -f /var/lib/ldap/__db.*; service slapd start' to recover from the upgrade. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
On Tue, 23 Nov 2010, Panu Matilainen wrote: On Tue, 23 Nov 2010, Paul Howarth wrote: On 23/11/10 10:11, Patrick MONNERAT wrote: While applying today's updates on a machine running a slapd server, the following error occurred: Stopping slapd: [ OK ] Checking configuration files for slapd: [FAILED] bdb(dc=linuxdev,dc=datasphere,dc=ch): Build signature doesn't match environment bdb_db_open: database dc=linuxdev,dc=datasphere,dc=ch cannot be opened, err -30971. Restore from backup! backend_startup_one (type=bdb, suffix=dc=linuxdev,dc=datasphere,dc=ch): bi_db_open failed! (-30971) slap_startup failed (test would succeed using the -u switch) stale lock files may be present in /var/lib/ldap[WARNING] /var/lib/ldap / / as a result, the ldap server is not running anymore, I cannot start it manually and I have no recent backup. I cannot even use slapcat (after update) on the current data. This is quite urgent since ldap data are heavily used by our applications. Please help ! Just had the same thing happen to me. Worked around it by doing: # yum downgrade openldap openldap-servers openldap-clients # slapcat my.ldif # yum update openldap openldap-servers openldap-clients Remove contents of /var/lib/ldap except DB_CONFIG # slapadd my.ldif # chown ldap:ldap /var/lib/ldap/* # restorecon -rvF /var/lib/ldap # service slapd start It came back up OK. Looks like the new openldap is built against a different BerkeleyDB than the old one. Yup, Berkeley DB is picky about its environment. It should be sufficient to to do 'rm -f /var/lib/ldap/__db.*; service slapd start' to recover from the upgrade. ...but just in case: I'm not at all familiar with openldap specifics. The openldap maintenance guide has the correct procedure for upgrades: http://www.openldap.org/doc/admin24/maintenance.html (which is basically the steps explained by Paul above) - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
mån 2010-11-22 klockan 18:51 +0100 skrev Björn Persson: Henrik Nordström wrote: * Slight adjustment of karma to provide choices Works for me, Problem still present and New problems seen * Works for me is a +1, and also adds the refereced bug as fixed by the update if not already in the list of fixed bugs. * Problem still present is a -1 if the bug is listed as fixed. Otherwise a +/-0. * Regression causing new problems is a -1, and requires a comment explaining the issue and explicit confirmation that the issue is not seen in earlier version. That should work for bugfix updates, but updates that don't fix bugs will never get any positive karma. You might argue that no update should be done if there are no bugs to fix, but what about bugfixes where the bugs have been reported upstream but not in Red Hat's Bugzilla? It was not meant to read that Works for me require a bug entry. Just that when you get to the update via a bug you get it filled in automatically and you have the option to reference a bug. I also think there should be separate choices for still works for me and fixes my problem. Fixes my problem would be what you called works for me, while still works for me would be for testers who had no problem before and don't see any regressions. Good idea. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 656317] New: libwx_gtk2u_stc-2.8.so: cannot open shared object file: No such file or directory
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: libwx_gtk2u_stc-2.8.so: cannot open shared object file: No such file or directory https://bugzilla.redhat.com/show_bug.cgi?id=656317 Summary: libwx_gtk2u_stc-2.8.so: cannot open shared object file: No such file or directory Product: Fedora Version: 14 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: low Component: perl-Padre AssignedTo: mmasl...@redhat.com ReportedBy: ppi...@redhat.com QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Target Release: --- When starting padre (perl-Padre package), I got graphical error message: libwx_gtk2u_stc-2.8.so: cannot open shared object file: No such file or directory with detail log: 02:37:21 PM: libwx_gtk2u_stc-2.8.so: cannot open shared object file: No such file or directory 02:37:21 PM: libwx_gtk2u_adv-2.8.so: cannot open shared object file: No such file or directory 02:37:21 PM: libwx_gtk2u_aui-2.8.so: cannot open shared object file: No such file or directory As a result padre cannot draw pictures and format text in some windows like in `About' window. This bug appears in F14 and F15 if wxGTK-devel is not installed. Despite the error message, the versioned library is opened according strace. In addition, padre segfaults in wxGTK in F14 if the error window get focus after dismissing splash screen. It seems like a bug in perl-Wx or wxGTK. We need to create minimal reproducer before reassigning to proper Bugzilla component. -- 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
The sale of Novell
Hi, As you may be aware, Novell recently sold itself/merged/whatever to another company with the transfer of 882 patents to MS. No idea what this will mean with the SCO legal case, but hey. My question regards Mono now. With the sale of Novell and MS gaining a pile of patents, will this affect the inclusion of Mono and the mono sub-packages into Fedora? I know the licence is OSS happy (else it wouldn't be allowed in), but will the sale change this (change of ownership, revokation of the licence etc)? TTFN Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The sale of Novell
On Tue, Nov 23, 2010 at 2:49 PM, Paul F. Johnson p...@all-the-johnsons.co.uk wrote: Hi, As you may be aware, Novell recently sold itself/merged/whatever to another company with the transfer of 882 patents to MS. No idea what this will mean with the SCO legal case, but hey. My question regards Mono now. With the sale of Novell and MS gaining a pile of patents, will this affect the inclusion of Mono and the mono sub-packages into Fedora? I know the licence is OSS happy (else it wouldn't be allowed in), but will the sale change this (change of ownership, revokation of the licence etc)? AFAIK the reason mono friends are allowed at all are that they are protected by the OIN, which didn't change. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
On Tue, 2010-11-23 at 14:55 +0100, Jan Vcelak wrote: Patric, thank you for reporting this. And sorry for the difficulties. You're welcome. And never mind for the difficulties: I understand your trouble and I wouldn't be in such a sh... myself ! I succeeded in restoring the LDAP usability by downgrading to 2.4.22-7, but I have to wait until after 16:00 UTC for the DB migration (after production use stops). Many thanks to all who helped. Cheers, Patrick -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide kernel image no longer readable
On Sat, 2010-11-20 at 22:45 -0500, Kyle McMartin wrote: On Sun, Nov 21, 2010 at 04:41:47AM +0100, Kevin Kofler wrote: Richard W.M. Jones wrote: The thing is, we really need to be able to boot a kernel in qemu as non-root, and carrying around a separately compiled or packaged kernel is in nobody's interest. I'm fairly sure this won't be the only application to break. We found it first because we are compiling and booting Rawhide in qemu virtually daily (so we tend to find any kernel or qemu problems very quickly -- it's the bain of my life). But I bet others will be needing to read those files. Also, I do think this smacks a bit of security through obscurity .. after all, the files that are being 'protected' here are being carried on a hundred or more mirror sites. It's the worst-kept secret :-) Uhm, indeed, making publicly available files non-readable is really useless. If it stops even one automated attack, then it's worth while. Is it going to stop an automated attach? If it's automated, it'll just get the uts name, then pull the files from some website, or probably come packed with the known addresses for various kernels (which of the ones I've seen in the wild for former exploits seems to be what is done - they don't read these files from the local filesystem). Not sure it's worth getting all TSA-y on this :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Appeal to finish the change in maintainer for the openjpeg package.
Someone with that right permissions need to change who maintains the openjpeg package in Fedora. Callum Lerwick has been AWOL for a long time now and has even said that he is not interested in long term maintenance of packages in a post over a year ago. https://www.redhat.com/archives/fedora-devel-list/2009-September/msg01223.html I have had a bug open since F12 regarding a crash of evinced caused by openjpeg. https://bugzilla.redhat.com/show_bug.cgi?id=579548 There was a Non-responsive openjpeg maintainer bug stared against the openjpeg package but it looks like some needed patches are not getting applied to openjpeg. https://bugzilla.redhat.com/show_bug.cgi?id=492218 - Adam Hough -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
On Tue, 2010-11-23 at 17:09 +0100, Jan Vcelak wrote: This is the problem: The database migration could take a really long time. I have testing data with 56 entries (nodes) - exporting (slapcat) is quite fast, but importing (slapadd) takes around 10 seconds. Imagine you have a large database. I would like to inform the user, that the database migration is in progress. Do you have some ideas? I would have thought this was exactly the kind of task that shouldn't happen during a stable release? Cheers Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: We can create a list of all scripts in wiki and maintainers of individual packages would indicate that they want to convert scripts themselves. How can I get information about all packages that provides init scripts? When I do rpm -qf /etc/init.d/* I get only information about already installed packages. Any magic switch to get informations about all packages from rpm database? Best regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usbip: how to build or find the driver
Il giorno mar, 23/11/2010 alle 15.55 +0100, Henrik Nordström ha scritto: Fedora do not normally include staging kernel drivers, but you can find them on rpmfusion. I have not looked into if the specific drivers you are looking for is there however. Regards Henrik Thanks Henrik, bui into rpmfusion the module witch I'm looking for there is not. I have found this howto: http://fedoraproject.org/wiki/Docs/CustomKernel#Building_Only_Kernel_Modules_.28Out_Of_Tree_Modules.29 And I have install the kernel source. Then I have extract the usbip folder (/tmp/usbip-module/linux-2.6.34/drivers/staging/usbip/) but I'm not able to build the usbip module, if I run : % cd /tmp/usbip-module/linux-2.6.34/drivers/staging/usbip/ % make -C /lib/modules/`uname -r`/build M=`pwd` modules noting is build Someone can show me how I can compile this module? Many thanks -- Dario Lesca d.le...@solinos.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Appeal to finish the change in maintainer for the openjpeg package.
AH == Adam Hough adam.ho...@gmail.com writes: AH Someone with that right permissions need to change who maintains the AH openjpeg package in Fedora. It has two comaintainers, so I don't really see what the issue is. I went ahead and gave those comaintainers approveacls permission on the Fedora branches so they can add other committers if they desire. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
MP == Michał Piotrowski mkkp...@gmail.com writes: MP How can I get information about all packages that provides init MP scripts? repoquery --whatprovides '/etc/init.d/*' - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
On Tue, 2010-11-23 at 17:09 +0100, Jan Vcelak wrote: Am I allowed to write some additional output in %pre/%post scriptlets? And shall I use stdout or stderr? I haven't found it in guidelines. I was always told no output allowed, which is sad. Sure, it might not be seen in all cases. What would be cool is if there were some way to indicate to RPM that progress was being made (some kind of incrementing counter, or whatever) that could be pushed up to higher level stuff, like PackageKit. I don't think there's anything today. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
2010/11/23 Michał Piotrowski mkkp...@gmail.com: W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: We can create a list of all scripts in wiki and maintainers of individual packages would indicate that they want to convert scripts themselves. How can I get information about all packages that provides init scripts? When I do rpm -qf /etc/init.d/* I get only information about already installed packages. Any magic switch to get informations about all packages from rpm database? no because only installed packages are part of the rpmdb. you could do yum install '/etc/init.d/*' then you have all the material to convert ;) kind regards, Rudolf Kastl Best regards, Michal -- 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: F15 Feature - convert as many service init files as possible to the native SystemD services
On Tue, 23 Nov 2010 17:18:44 +0100 Michał Piotrowski wrote:
How can I get information about all packages that provides init
scripts?
When I do
rpm -qf /etc/init.d/*
I get only information about already installed packages. Any magic
switch to get informations about all packages from rpm database?
repoquery -f /etc{,/rc.d}/init.d/\*
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On 11/22/10 11:32 PM, Till Maas wrote: On Mon, Nov 22, 2010 at 02:33:35PM -0800, Jesse Keating wrote: On 11/22/10 1:50 PM, Till Maas wrote: On Mon, Nov 22, 2010 at 12:02:49PM -0800, Jesse Keating wrote: On 11/22/2010 11:56 AM, Michael Cronenworth wrote: It was my understanding of reading the complaints that this is what they [complainers] desire - a reversal of what we require now (3 karma and/or proventester if critpath). Critpath requires +1 proven tester and +1 anybody. Total of +2. Non crit-path requires a minimum of +1 anybody or a 7 day timeout I do believe. I do not believe we require +3 anywhere. We /default/ the karma autopush level at +3/-3, but that's just a suggestion. Afaik there is currently no distinction between the requirement for non crit-path updates and the karma autopush level. Therefore by default non critpath updates require +3 karma, unless this has been changed since the beginning for the update criteria enforcement. I swear I've been able to set karma levels at 1 for non-critpath updates. But this means that the update is automatically pushed to stable, not that the update is approved and then pushed to stable when the maintainer requests it. Regards Till I'm sorry, I didn't realize that's what you were arguing about. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Tue, Nov 23, 2010 at 17:18:44 +0100, Michał Piotrowski mkkp...@gmail.com wrote: W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: We can create a list of all scripts in wiki and maintainers of individual packages would indicate that they want to convert scripts themselves. How can I get information about all packages that provides init scripts? When I do rpm -qf /etc/init.d/* I get only information about already installed packages. Any magic switch to get informations about all packages from rpm database? I believe rpm only knows about packages available locally. You either need to have the packages installed or a local mirror. (You can use urls to refer to remote packages with rpm, but that isn't likely to be workable.) If you have a local mirror you can use the p option and name the rpms. Otherwise yum is probably a better choice for this, since it can use meta data to get information. One of the yum utilities may be better than yum itself, but I am not sure offhand. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perlbrew/el6/master] (5 commits) ...Merge branch 'master' into el6
Summary of changes: 89ff2c1... initial import (*) 8d97dfc... - Mass rebuild with perl-5.12.0 (*) 528eadb... dist-git conversion (*) a8068ee... update to 0.13 (*) 59f0696... Merge branch 'master' into el6 (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perlbrew/el6/master: 5/5] Merge branch 'master' into el6
commit 59f06963e29f1e90761e07ee1a9925673091ab74 Merge: 37bf1d5 a8068ee Author: Iain Arnell iarn...@gmail.com Date: Tue Nov 23 17:26:06 2010 +0100 Merge branch 'master' into el6 .gitignore|1 + perlbrew.spec | 15 +++ sources |2 +- 3 files changed, 13 insertions(+), 5 deletions(-) --- -- 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: Urgent: today's F14 catastrophe with openldap-servers update
On 11/23/10 5:55 AM, Jan Vcelak wrote: Hi! Currently, the upgrade process in openldap looks like this: * during db4 package upgrade run db_upgrade (%triggerin and %triggerun) * if minor version of openldap changes (e.g. 2.3 - 2.4), export the database, delete it and import it back (which is recommended by maintanence guide, as Panu mentioned) We didn't wanted to do the export+import during each upgrade, as it takes quite a long time if you have large database. But it seems that current process doesn't work and that doing it every time will be the safest way. (Maybe we can ignore epoch changes.) Thanks for suggestions. I will fix it today and push an update. Patric, thank you for reporting this. And sorry for the difficulties. Why was this update made on F14 in the first place? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
Once upon a time, Jan Vcelak jvce...@redhat.com said: Am I allowed to write some additional output in %pre/%post scriptlets? And shall I use stdout or stderr? I haven't found it in guidelines. No, because there's no telling where it will go. This is the problem: The database migration could take a really long time. I have testing data with 56 entries (nodes) - exporting (slapcat) is quite fast, but importing (slapadd) takes around 10 seconds. This is usually a problem of improper (or missing) DB_CONFIG (the openldap-servers package should probably include one in /var/lib/ldap, not just a sample in a directory where nobody will look). Also, you can use the -q option to speed up slapadd (since you should have a consistent database already). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On 11/20/2010 11:46 PM, Michał Piotrowski wrote: Hi, I would like to help with scripts conversion. IMO the conversion action should be coordinated. Comments, thoughts? Kind regards, Michal I created this a while back so just take your pick from there fill it with a link to the new file when you are done and the corresponding bz report or package build https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability Thank you. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
2010/11/23 Jason L Tibbitts III ti...@math.uh.edu: MP == Michał Piotrowski mkkp...@gmail.com writes: MP How can I get information about all packages that provides init MP scripts? repoquery --whatprovides '/etc/init.d/*' It seems to me that too little packages was returned - J -- 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: F15 Feature - convert as many service init files as possible to the native SystemD services
2010/11/23 Jóhann B. Guðmundsson johan...@gmail.com: On 11/20/2010 11:46 PM, Michał Piotrowski wrote: Hi, I would like to help with scripts conversion. IMO the conversion action should be coordinated. Comments, thoughts? Kind regards, Michal I created this a while back so just take your pick from there fill it with a link to the new file when you are done and the corresponding bz report or package build This is exactly what I wanted :) https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability Thank you. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Best regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
On 11/23/2010 05:30 PM, Jesse Keating wrote: On 11/23/10 5:55 AM, Jan Vcelak wrote: Hi! Currently, the upgrade process in openldap looks like this: * during db4 package upgrade run db_upgrade (%triggerin and %triggerun) * if minor version of openldap changes (e.g. 2.3 - 2.4), export the database, delete it and import it back (which is recommended by maintanence guide, as Panu mentioned) We didn't wanted to do the export+import during each upgrade, as it takes quite a long time if you have large database. But it seems that current process doesn't work and that doing it every time will be the safest way. (Maybe we can ignore epoch changes.) Thanks for suggestions. I will fix it today and push an update. Patric, thank you for reporting this. And sorry for the difficulties. Why was this update made on F14 in the first place? IMO, this is the wrong question. The better questions would be - How could it happen, this package made it into updates, dispite all this QA bureaucracy is in place? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Bastien Nocera wrote: On Mon, 2010-11-15 at 15:44 +, Matthew Garrett wrote: On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with any luck). Not without a pile of X changes, which themselves are blocking on upstream kernel changes that I've submitted but which haven't been merged. For brightness? For GNOME at least, this is worked around in: http://git.gnome.org/browse/gnome-power-manager/tree/src/gpm-backlight- helper.c though a cleaner fix would certainly be appreciated. Huh? KDE trunk (4.6) already uses XRandR backlight setting in PowerDevil: http://websvn.kde.org/trunk/KDE/kdebase/workspace/powerdevil/daemon/backends/upower/xrandrbrightness.cpp?revision=1194096view=markup and it appears to work fine for those who have coded this. It might not to work for proprietary drivers, but that's those drivers' problem. KDE basically requires XRandR since at least 4.0. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
On Tue, 2010-11-23 at 18:21 +0100, Ralf Corsepius wrote: Why was this update made on F14 in the first place? IMO, this is the wrong question. The better questions would be - How could it happen, this package made it into updates, dispite all this QA bureaucracy is in place? Remember, critpath testing is intended to ensure that *critical path functionality* is not broken. The LDAP functionality that's critpath is _client_ functionality, not server functionality: if you run in an LDAP environment you need the openldap client functionality to log in. So it was the client functionality that was tested by those who approved the update, mostly: jhrozek - 2010-11-18 13:24:44 This update fixed both #652315 and #652304 for me. So far no regressions. (they're both client-side bugs) jlaska (proventesters) - 2010-11-18 21:16:59 I've tested the client in my existing SSSD setup. I've done some *basic* testing of slapd and related binaries to ensure they can survive basic execution I've said before that the critpath process does not ensure, nor does it aim to ensure, that nothing that goes through the critpath testing ever has problems, or regressions; what it aims to ensure is that the critical path functionality isn't broken. Of course, given the laws of Murphy and Sod, even this is not a guarantee, it's just what the process aims for. (You can look at this as ammo for the other side, too: the maintainer did a version bump that looked perfectly reasonable to him, as he explained at length...yet it turns out to have a significant problem. This is a good example of why, if you want a truly stable release process, you don't do even updates that look perfectly safe unless they're really needed, and you test the updates as far as is practical.) -- 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: Fedora 15, new and exciting plans
On Tue, 2010-11-23 at 18:23 +0100, Kevin Kofler wrote: Bastien Nocera wrote: On Mon, 2010-11-15 at 15:44 +, Matthew Garrett wrote: On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with any luck). Not without a pile of X changes, which themselves are blocking on upstream kernel changes that I've submitted but which haven't been merged. For brightness? For GNOME at least, this is worked around in: http://git.gnome.org/browse/gnome-power-manager/tree/src/gpm-backlight- helper.c though a cleaner fix would certainly be appreciated. Huh? KDE trunk (4.6) already uses XRandR backlight setting in PowerDevil: http://websvn.kde.org/trunk/KDE/kdebase/workspace/powerdevil/daemon/backends/upower/xrandrbrightness.cpp?revision=1194096view=markup and it appears to work fine for those who have coded this. It might not to work for proprietary drivers, but that's those drivers' problem. KDE basically requires XRandR since at least 4.0. this is a fairly new thing, AIUI: http://mjg59.livejournal.com/127103.html -- 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: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
Adam Williamson wrote: On Mon, 2010-11-22 at 10:21 +0100, Hans de Goede wrote: So taking for example the much much discussed KDE rebases. I think that doing a KDE rebase for Fedora #+1 is a no brainer, for Fedora # is fine as long as it is properly tested and for Fedora #-1 KDE should NOT be rebased. This also matches well with what the KDE people have been reporting, were they can get plenty of testing on Fedora # but all most none on Fedora #-1. I think that the few KDE users which remain on Fedora #-1, do so because they appreciate some stability, and thus should not get (a largely untested) KDE rebase. I hope I'm not putting words in KK's mouth again :), but I believe this is actually more or less what KDE team does; the current KDE update isn't a rebase as far as they see it, it's a minor point update. I think they may well not push KDE 4.6 to F13 when it comes out, but only to F14. (Yell at me again if I'm wrong, KK). It's not how we used to work (F9, F10, F11 got 2 KDE rebases each), nor how I think we SHOULD work (I think Fn-1 shouldn't be getting second-class support, what we did for F9-F11 was the right thing!), but how we ended up working for F12 (mainly because 4.5 took forever to test, so F12 was almost EOL when we declared it stable) and how we're probably going to work now (assuming they'll even let us do the one KDE rebase), due to all the anti-upgrade pressures. :-( Note that Fedora #-2 does not fit into this view for things at all, Fedora #-2 is meant to allow people to skip a Fedora release. But in practice I think this works out badly, because a relatively new Fedora release like Fedora 14 tends to still have some rough edges and get lots of updates/churn (and thus possible regressions, despite our best effords). This is not at a good point in its cycle to upgrade to for people who like it stable (and sticking with 1 release for an entire year to me sounds like liking it stable). That's a reasonable point indeed. Uh, you just explained yourself why it's not! (People don't like it stable, they're just too lazy to upgrade.) Where as the one which has already been out for 5-6 months (Fedora 13) has seen most rough edges polished away with updates, and the updates rate will have slowed. So maybe it is time we dropped the support duration for a release from 13 to 11 months, and make clear that people should not skip releases. That's one I didn't have on my list of ideas to look at; I'll add it :) It's a very bad idea, it'll lead to even more people running unsupported Fedora releases. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
2010/11/23 Michał Piotrowski mkkp...@gmail.com: W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: We can create a list of all scripts in wiki and maintainers of individual packages would indicate that they want to convert scripts themselves. I'll try to do it for Firebird package can you give me some hints and place I have to read before ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-17)
Till Maas wrote: It is totally annoying and time consuming to hit fixed bugs again, just because the update has not been pushed from testing to stable. I cannot really imagine that I am the only one experiencing this ever and ever again. E.g. just today when I wanted to debug f-e-k on the F14 test machine provided for package maintainers, ipython did not work at all, because it required an X server. The bug was already reported and fixed, but the update only in testing. +1! Bugfixes getting delayed for no good reason just sucks. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, Nov 22, 2010 at 01:29:45PM -0700, Kevin Fenzi wrote: Here's the latest list of ideas culled from this thread. Note: these are NOT my ideas, I am just gathering them up so fesco can discuss them. Feel free to add more concrete ideas, or let me know if I missed one you had posted. If folks could avoid me too or posts that contain no new information it would be easier for me to gather the actual ideas. ;) I've split things into General, Security, Critpath and non security/critpath to help organize them. Keep the ideas coming... Since people have been tossing around the general idea of testing being needed for a few maintainer/package combos where bad updates traditionally come from, here's a concrete proposal based on that: General: * Testing is only required for certain packages. Those packages are the packages where problems have occurred before so fesco or other maintainers affected by the changes deem it necessary to supplement the maintainer's testing with outside help. - Option: supplement this list with critpath packages where the maintainers desire extra testing. This means that we would no longer be dragging in dependencies immediately... only if updates by the dependency's maintaner to that package are breaking things. -Toshio pgpweNqg0ML4R.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On Tue, 2010-11-23 at 18:32 +0100, Kevin Kofler wrote: Note that Fedora #-2 does not fit into this view for things at all, Fedora #-2 is meant to allow people to skip a Fedora release. But in practice I think this works out badly, because a relatively new Fedora release like Fedora 14 tends to still have some rough edges and get lots of updates/churn (and thus possible regressions, despite our best effords). This is not at a good point in its cycle to upgrade to for people who like it stable (and sticking with 1 release for an entire year to me sounds like liking it stable). That's a reasonable point indeed. Uh, you just explained yourself why it's not! (People don't like it stable, they're just too lazy to upgrade.) What I thought was a good point is that our professed reason for the twelve month cycle is to allow users to 'skip a release', but that in practice this is tricky because it requires you to upgrade very early in the life of a new release, which historically speaking is not the most stable point. -- 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: F15 Feature - convert as many service init files as possible to the native SystemD services
W dniu 23 listopada 2010 18:35 użytkownik philippe makowski makowski.fed...@gmail.com napisał: 2010/11/23 Michał Piotrowski mkkp...@gmail.com: W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: We can create a list of all scripts in wiki and maintainers of individual packages would indicate that they want to convert scripts themselves. I'll try to do it for Firebird package can you give me some hints and place I have to read before ? This is a good start point http://0pointer.de/blog/projects/systemd-for-admins-3.html About services, sockets, targets etc http://0pointer.de/public/systemd-man/ You may want to read all systemd related things from http://0pointer.de/blog/ (if you don't know how it works, you should start from begining) Best regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Mike Fedyk wrote: So feel free to push directly to stable as often as you want, but once you introduce one regression, you have to satisfy 10 karma on every package you update. The second time, you have to satisfy 20 karma on every package you update and so on. At that point you can just ban the offender from Bodhi entirely, it'll have the same effect. :-/ Basically no update gets +10 karma out there in the real world! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Mozilla-LDAP] forgot to add -DUSE_SSL -DPRLDAP for the openldap case
commit 00a0544321e44ecc180451ab680e896bd6550231
Author: Rich Megginson rmegg...@redhat.com
Date: Tue Nov 23 10:47:50 2010 -0700
forgot to add -DUSE_SSL -DPRLDAP for the openldap case
Makefile.PL.rpm|2 +-
perl-Mozilla-LDAP.spec |5 -
2 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/Makefile.PL.rpm b/Makefile.PL.rpm
index afab05c..af64210 100644
--- a/Makefile.PL.rpm
+++ b/Makefile.PL.rpm
@@ -44,7 +44,7 @@ if (lc($ldappkgname) eq 'openldap') {
$libs = `pkg-config --libs nss`;
chomp($libs);
$libs = -lldap -llber $libs;
- $DEFINES = -DUSE_OPENLDAP;
+ $DEFINES = -DUSE_OPENLDAP -DUSE_SSL -DPRLDAP;
} else {
$cflags = `pkg-config --cflags $ldappkgname`;
chomp($cflags);
diff --git a/perl-Mozilla-LDAP.spec b/perl-Mozilla-LDAP.spec
index 18603ee..02e8630 100644
--- a/perl-Mozilla-LDAP.spec
+++ b/perl-Mozilla-LDAP.spec
@@ -1,7 +1,7 @@
Summary: LDAP Perl module that wraps the OpenLDAP C SDK
Name: perl-Mozilla-LDAP
Version: 1.5.3
-Release: 3%{?dist}
+Release: 4%{?dist}
License: GPLv2+ and LGPLv2+ and MPLv1.1
Group: Development/Libraries
URL: http://www.mozilla.org/directory/perldap.html
@@ -83,6 +83,9 @@ rm -rf $RPM_BUILD_ROOT
%doc CREDITS ChangeLog README MPL-1.1.txt
%changelog
+* Tue Nov 23 2010 Rich Megginson rmegg...@redhat.com - 1.5.3-4
+- forgot to add -DUSE_SSL -DPRLDAP
+
* Wed Sep 29 2010 jkeating - 1.5.3-3
- Rebuilt for gcc bug 634757
--
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
[perl-Mozilla-LDAP/f14/master] forgot to add -DUSE_SSL -DPRLDAP for the openldap case
Summary of changes: 00a0544... forgot to add -DUSE_SSL -DPRLDAP for the openldap case (*) (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Updates Criteria Summary/Brainstorming
Adam Williamson wrote: On Mon, 2010-11-22 at 16:01 +0100, Kevin Kofler wrote: Right, and the big point there should be that a bug which can corrupt mail folders should be fixed IMMEDIATELY, i.e. with a direct stable push! ANY testing requirement there is a failure. How about testing that it doesn't corrupt mail folders even worse? To the average user, more corrupt is a bit like more pregnant. The data is most likely a total loss even in the case which is technically less corrupt. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Michael Cronenworth wrote: So you'll double, triple, ultra swear that this[1] will never happen again? [1] http://lists.fedoraproject.org/pipermail/announce/2008-December/002572.html That wasn't a data corruption issue in the first place. It was a low-severity security fix, and the fix was very invasive and dangerous. The maintainer should have known this and NOT opted for a direct stable push in this case. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Mike Fedyk wrote: Install package from updates-testing, then +1 to karma after it works for you with your tests and normal workload. The average user won't even KNOW there's an update available in updates- testing before it's too late (i.e. all his/her data is gone, (s)he asks on forums or IRC what's up, and people point him/her to the testing update (which doesn't help because all the data is already corrupted/deleted!), at which point (s)he'll switch to Ubuntu or Window$ in disgust and swear to never use Fedora again). No need to foist possibly broken software on everyone. That's exactly why bugs must be fixed ASAP! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, Nov 22, 2010 at 10:39 PM, Tom Lane t...@redhat.com wrote: (And yeah, if we allow +1 autopush, we should definitely expect -1 is sufficient to unpush. Maybe bodhi should restrict the combination of those two settings, rather than either one alone?) Not as long people give -1 for random crap oh this does not fix a completely unrelated bug ... (where the update isn't any worse then the current build, but fixes issues for _others_). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Till Maas wrote: Afaik there is no need for a maintainer to set different acceptance thresholds for his updates. At least nobody ever explained to me why this would be helpful. * Upgrade paths! I DON'T want my foo-1.2.3-4.fc13 update to go out before my foo-1.2.3-4.fc14 update, even if it happens to get karma first. * Possibility to look at the feedback. E.g. if an update has -1, deletes all my e-mail, +1, can haz noo verzion? and +1, didn't test e-mail, everything else works, I'm NOT going to push the update! * Because people just make better decisions than software, period. In fact, IMHO automatic pushing is completely stupid, and the current process which heavily relies on it is just broken. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Tom Lane wrote: (And yeah, if we allow +1 autopush, we should definitely expect -1 is sufficient to unpush. Maybe bodhi should restrict the combination of those two settings, rather than either one alone?) Well, we've started to use +1/-999 for some KDE updates. :-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
On Tue, 23 Nov 2010, Ralf Corsepius wrote: On 11/23/2010 05:30 PM, Jesse Keating wrote: On 11/23/10 5:55 AM, Jan Vcelak wrote: Hi! Currently, the upgrade process in openldap looks like this: * during db4 package upgrade run db_upgrade (%triggerin and %triggerun) * if minor version of openldap changes (e.g. 2.3 - 2.4), export the database, delete it and import it back (which is recommended by maintanence guide, as Panu mentioned) We didn't wanted to do the export+import during each upgrade, as it takes quite a long time if you have large database. But it seems that current process doesn't work and that doing it every time will be the safest way. (Maybe we can ignore epoch changes.) Thanks for suggestions. I will fix it today and push an update. Patric, thank you for reporting this. And sorry for the difficulties. Why was this update made on F14 in the first place? IMO, this is the wrong question. The better questions would be - How could it happen, this package made it into updates, dispite all this QA bureaucracy is in place? Like Adam already pointed out, it appears that it was mostly the client parts that got tested. Bodhi makes no difference between simple packages vs those that have half a dozen different subpackages consisting of wildly different functionality (such as client and server parts) that need completely different testing methods. Requiring separate acks/karma/whatever for each sub-package would be a huge overkill in most cases but then there are cases like this... Another related thing is that Berkeley DB which openldap uses is notoriously picky about getting updated. I'm fairly certain openldap does not update their bundled BDB version to prevent issues like this on minor updates, and AFAICT (based on a quick lookaround at the changelogs etc) in this case it was this fix to comply with our own policies (no bundled libraries) that bit us when synced with rawhide version: * Fri Aug 27 2010 Jan Vcelak jvce...@redhat.com 2.4.23-1 - rebase to 2.4.23 - embeded db4 library removed - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Michael Cronenworth wrote: -Installs PackageKit plugin to give karma through the gnome-packagekit GUI. (Nothing exists yet, but I'm gonna get started on one soon) What about KPackageKit? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Tue, Nov 23, 2010 at 07:06:33PM +0100, Kevin Kofler wrote: Till Maas wrote: Afaik there is no need for a maintainer to set different acceptance thresholds for his updates. At least nobody ever explained to me why this would be helpful. * Upgrade paths! I DON'T want my foo-1.2.3-4.fc13 update to go out before my foo-1.2.3-4.fc14 update, even if it happens to get karma first. * Possibility to look at the feedback. E.g. if an update has -1, deletes all my e-mail, +1, can haz noo verzion? and +1, didn't test e-mail, everything else works, I'm NOT going to push the update! * Because people just make better decisions than software, period. In fact, IMHO automatic pushing is completely stupid, and the current process which heavily relies on it is just broken. I did not write about the automatic pushing threshold but only about the acceptance threshold. Regards Till pgpzKixEb0RTK.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Toshio Kuratomi wrote: We don't control RH bugzilla so changing bugzilla to be able to use fas to login would be problematic. The right solution would really be to have a separate Fedora Bugzilla tied in to Fedora infrastructure, with bug states which make sense for Fedora, not RHEL etc. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14: after last updates, getting Eclipse out of memory errors
On Mon, Nov 22, 2010 at 10:08 AM, Alexander Kurtakov akurt...@redhat.comwrote: On 10:05:21 am Sunday, November 21, 2010 Marius Andreiana wrote: Hi, After getting latest updates (glibc and eclise), I started getting reproducible Eclipse out of memory errors (happens during AppEngine deploys). Haven't done any other changes to my env besides yum update. Should I file a bug? Just edit /etc/eclipse.ini and set the --launcher.XXMaxPermSize and -Xmx384m to something meaningful for you. JVM can allocate more memory than a predefined value which can be controlled by startup parameters. This is what we do in eclipse.ini but we can not set this to something really big because people can use eclipse for things that even require less than the current settings. Alexander Kurtakov solved, thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: update for openldap available
On Tue, 2010-11-23 at 18:51 +0100, Jan Vcelak wrote: Just submitted to updates-testing. Please, test. 656257 - Upgrade from 2.4.22-7 to 2.4.23-3 breaks slapd 655899 - outdated list of overlays in slapd.conf 652822 - ldapsearch -Z hangs server if starttls fails Jan Many thanks Jan, it works. I have downloaded your new files from koji and installed them with rpm -F: perfect and the conversion was quite fast (I have a bit more than 3K records in the DB). Cheers, Patrick -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Adam Williamson wrote: On Tue, 2010-11-23 at 18:23 +0100, Kevin Kofler wrote: It might not to work for proprietary drivers, but that's those drivers' problem. KDE basically requires XRandR since at least 4.0. this is a fairly new thing, AIUI: http://mjg59.livejournal.com/127103.html I know it's a fairly recent XRandR feature. But it's also part of KDE's track record to always require the latest XRandR spec. :-) As long as the drivers actually in Fedora support that, I'm fine with it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Apache-DBI/el6/master] update to 1.09
commit 9ca9b1658ed1c65de7c6297a24e1a17132aec3e3
Author: remi fed...@famillecollet.com
Date: Tue Nov 23 20:02:27 2010 +0100
update to 1.09
.gitignore |3 ++-
perl-Apache-DBI.spec |5 -
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9b24c3e..c0c90d1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
-Apache-DBI-1.07.tar.gz
+Apache-DBI-1.08.tar.gz
+/Apache-DBI-1.09.tar.gz
diff --git a/perl-Apache-DBI.spec b/perl-Apache-DBI.spec
index 05bc3b4..0564368 100644
--- a/perl-Apache-DBI.spec
+++ b/perl-Apache-DBI.spec
@@ -1,7 +1,7 @@
%global perlname Apache-DBI
Name: perl-Apache-DBI
-Version: 1.08
+Version: 1.09
Release: 1%{?dist}
Summary: Persistent database connections with Apache/mod_perl
@@ -70,6 +70,9 @@ make test
%{perl_vendorlib}/Apache
%changelog
+* Tue Nov 23 2010 Remi Collet fed...@famillecollet.com 1.09-1
+- update to 1.09 (bugfix)
+
* Tue Feb 09 2010 Remi Collet fed...@famillecollet.com 1.08-1
- update to 1.08 (bugfix)
diff --git a/sources b/sources
index aa999db..a66a55a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-cb33b7ce268ef3a6fcbdc82d13d89b5c Apache-DBI-1.08.tar.gz
+3243a359906cfc62d548f327c9e3b8c7 Apache-DBI-1.09.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: Fedora 15, new and exciting plans
On Tue, Nov 23, 2010 at 06:23:10PM +0100, Kevin Kofler wrote: Huh? KDE trunk (4.6) already uses XRandR backlight setting in PowerDevil: http://websvn.kde.org/trunk/KDE/kdebase/workspace/powerdevil/daemon/backends/upower/xrandrbrightness.cpp?revision=1194096view=markup and it appears to work fine for those who have coded this. It might not to work for proprietary drivers, but that's those drivers' problem. KDE basically requires XRandR since at least 4.0. Well, that's unfortunate - XRandR backlight control is only implemented on -intel. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for tomorrow's FESCo meeting (2010-11-24)
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 18:30UTC (1:30pm EDT) in #fedora-meeting on irc.freenode.net. = Followups = #topic Updates policy #351 Create a policy for updates - status report on implementation https://fedorahosted.org/fesco/ticket/351 #382 Implementing Stable Release Vision https://fedorahosted.org/fesco/ticket/382 * Discuss ideas for adjusting policy * Need work on stats to see trends with new policy. * Need to investigate a 'new features' repo setup. * Need to look at education/enforcement = New business = #topic #503 Robotics Spin a Feature? https://fedorahosted.org/fesco/ticket/503 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Matthew Garrett wrote: On Tue, Nov 23, 2010 at 06:23:10PM +0100, Kevin Kofler wrote: Huh? KDE trunk (4.6) already uses XRandR backlight setting in PowerDevil: http://websvn.kde.org/trunk/KDE/kdebase/workspace/powerdevil/daemon/backends/upower/xrandrbrightness.cpp?revision=1194096view=markup and it appears to work fine for those who have coded this. It might not to work for proprietary drivers, but that's those drivers' problem. KDE basically requires XRandR since at least 4.0. Well, that's unfortunate - XRandR backlight control is only implemented on -intel. Well, what's unfortunate is that HAL got deprecated long before replacements for all its parts were ready. KDE already waited for quite some time before implementing the replacements for HAL and was heavily criticized for that out of some circles. And STILL, the replacement isn't ready? Surely copyingpasting HAL code into a helper which runs as root as gnome- power-manager does isn't a long-term-viable solution! How about next time the replacements get implemented BEFORE everyone scrambles to replace HAL and those who don't get yelled at for waiting until things actually work?! Is there a hope that radeon and nouveau get fixed to support XRandR backlight control by F15? (I don't give a darn about Catalyst/fglrx and nvidia.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
Heya! I hereby want to let everybody know that in the next days I will turn on /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance with the following accepted F15 feature: https://fedoraproject.org/wiki/Features/var-run-tmpfs My current tests indicate that we will not run into too much trouble with this and most things should continue to work just fine. However, of course I run only a small subset of packages of the fedora archive on my machine. So here's what might happen and which might need fixing over the next weeks in various packages: - Not all packages might be able to create their directory in /var/run on start-up. Since SUSE and Ubuntu have already been shipping systems with tmpfs on /var/run and /var/lock for quite a while I expect the number of packages that are incapable of doing this to be very small. If your software nonetheless fails witht this issue, then there are two options to fix this: a) patch the program in question, so that it is able to recreate the directories in /var/run, or b) ship a simple drop-in file for /etc/tmpfiles.d/ which recreates these directories on boot. (see below) - There might be permission problems, since the rpms might have set different perms on the subdirs of /var/run than the software itself might apply when starting up. In this case, a drop-in file in /etc/tmpfiles.d/ might help. (see below) - The SELinux policy might trigger AVCs and disallow creation of the dirs in question. In this case Dan will be of help of course, so make sure to file a bug. And I guess I don't need to mention this but temporarily falling back to permissive mode is a short-term workaround for this. - In some cases daemons might want to create more than one file/dir below /var/run which are supposed to be labelled differently. In this case the daemon can either be modified to fix its labels up itself, or a drop-in file in /etc/tmpfiles.d/ might help (see below). - Many .spec files currently own subdirs of /var/run. These need to be updated to %ghost those dirs only, so that the automatic removal of these files/dirs on boot doesnt cause rpm to complain. The list of packages which own such files/subdir you find on the aforementioned feature page. I will mass-file bugs against these packages later tonight, requesting the %ghosting of these entries. For more information on the %ghost directive in .spec files see this page: http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-FLIST-GHOST-DIRECTIVE Action items: a) Lennart will mass-file bugs regarding %ghost usage tonight b) Lennart will switch on /var/run and /var/lock on tmpfs either tomorrow or the day after tomorrow c) YOU need to edit your .spec file and place a %ghost where appropriate. c) YOU need to test if you package still works, and if necessary file AVC bugs, add an /etc/tmpfiles.d drop-in file to your program, or patch it so that it is able to recreate these directories beneath /var/run on its own. On /etc/tmpfiles.d: This is a new feature of systemd, but which is apparently very much liked by people outside of systemd, so this might actually find adoption even on systems which will not adopt systemd any time soon, since it actually is not specific at all to systemd. By dropping a simple configuration file in /etc/tmpfiles.d you can ensure that volatile files and directories are: a) created, deleted or emptied at boot b) their permissions/ownership fixed c) its directory contents cleaned up in regular intervals (a la tmpwatch) and d) it is properly relabeled at boot. As an example, here's how such a file might look like for the screen package (name it /etc/tmpfiles.d/screen.conf): snip d /var/run/screens 1777 root root 10d d /var/run/uscreens 0755 root root 10d12h /snip This encodes that two directories are created under the listed names, with automatic clean up after 10 days resp. 10 days and 12h. For more details consult the man page: http://0pointer.de/public/systemd-man/tmpfiles.d.html Thank you for your attention! Lennart -- Lennart Poettering - Red Hat, Inc. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On 11/23/10 12:16 PM, Toshio Kuratomi wrote: On Mon, Nov 22, 2010 at 11:39:02AM -0800, Jesse Keating wrote: On 11/22/2010 11:18 AM, Toshio Kuratomi wrote: They said that they install a Fedora for testing purposes when it first comes out and enjoy the rapid pace of bugfixes as they test the software in their environment. Then, the update pace slows down at about the same time their ready to push things out to the machines in their env. I think there's likely better ways that they could achieve this if we were optimizing for this, though. This sounds like install the newly Branched release (AKA Alpha), which has rapid updates, but should slow down once it goes GOLD, and then be slow and stable for the next 13 months after that. I'd say that people like this probably want to start installing Fedora at the point where no reversions of major Features are likely to occur. So they probably want to do their initial install at a point in the process after Alpha. I don't know where we match up though... the systemd reversion was a bit of a mess and I don't know how the process is supposed to work as opposed to how it did work this time around. -Toshio Alpha is post-feature freeze, so there shouldn't be reversions of features after that point, outside of special cases. systemd was a special case. If we as a project stuck better to our feature freeze and process, then installing from Alpha would be a more favorable target. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On 11/23/2010 03:48 PM, Lennart Poettering wrote: Heya! I hereby want to let everybody know that in the next days I will turn on /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance with the following accepted F15 feature: https://fedoraproject.org/wiki/Features/var-run-tmpfs Will the tmpfs mounts be available in the initramfs, or only on the running system? -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, 23 Nov 2010 21:48:30 +0100 Lennart Poettering mzerq...@0pointer.de wrote: - In some cases daemons might want to create more than one file/dir below /var/run which are supposed to be labelled differently. In this case the daemon can either be modified to fix its labels up itself, or a drop-in file in /etc/tmpfiles.d/ might help (see below). Given that the tmpfiles.d format doesn't mention SELinux contexts, I assume that the files/directories will be set up to have whatever their default context would be under the running policy, as restorecon would set it? Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, 23.11.10 21:19, Paul Howarth (p...@city-fan.org) wrote: On Tue, 23 Nov 2010 21:48:30 +0100 Lennart Poettering mzerq...@0pointer.de wrote: - In some cases daemons might want to create more than one file/dir below /var/run which are supposed to be labelled differently. In this case the daemon can either be modified to fix its labels up itself, or a drop-in file in /etc/tmpfiles.d/ might help (see below). Given that the tmpfiles.d format doesn't mention SELinux contexts, I assume that the files/directories will be set up to have whatever their default context would be under the running policy, as restorecon would set it? Yes, SELinux contexts are exclusively configured in the policy, we do not spread that around in other ocnfiguration files. The tmpfiles stuff includes an implicit restorecon, basically. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/23/2010 04:26 PM, Lennart Poettering wrote: On Tue, 23.11.10 21:19, Paul Howarth (p...@city-fan.org) wrote: On Tue, 23 Nov 2010 21:48:30 +0100 Lennart Poettering mzerq...@0pointer.de wrote: - In some cases daemons might want to create more than one file/dir below /var/run which are supposed to be labelled differently. In this case the daemon can either be modified to fix its labels up itself, or a drop-in file in /etc/tmpfiles.d/ might help (see below). Given that the tmpfiles.d format doesn't mention SELinux contexts, I assume that the files/directories will be set up to have whatever their default context would be under the running policy, as restorecon would set it? Yes, SELinux contexts are exclusively configured in the policy, we do not spread that around in other ocnfiguration files. The tmpfiles stuff includes an implicit restorecon, basically. Lennart And we do not want these labels leaking out into config files. Since there are multiple policies. For example. /var/run/BLAH might have different labels in MLS policy versus Targeted. And some of our partners ship their own policies. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzsNPYACgkQrlYvE4MpobNnawCfSGBUNfTq0ayy+RMdajBwDBuD YpgAn1gRJvhHdOmtXvbTh461p6M/rNd3 =4FmN -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On 11/23/2010 12:48 PM, Lennart Poettering wrote: Heya! I hereby want to let everybody know that in the next days I will turn on /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance with the following accepted F15 feature: https://fedoraproject.org/wiki/Features/var-run-tmpfs Is this actually an improvement? I know that dentries and inodes for regular filesystems can be discarded from RAM if they're not in use, is that the case for a tmpfs? How often are the files in /var/run and /var/lock accessed? Is the kernel likely to discard them? Files in /var/run tend to be 4 or 5 bytes in length, does that mean they each use an entire page of RAM or swap? There are vastly fewer swap pages than there are filesystem blocks, isn't this less efficient? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, Nov 23, 2010 at 10:32:00PM +0100, Lennart Poettering wrote: Also note that by now it's somewhat standard that code that needs to be run as part of early boot creates a subdir in /dev, such as /dev/.udev or /dev/.systemd. Not super-pretty, but I guess it's too late to complain about that. This is the first time I read about using a subdir in /dev. Is there some inter-distro agreement about this? The last discussion I had with someone from debian revealed that they use subdirs in /lib for stuff that should be in /var according to the FHS but might be needed before /var is mounted. Regards Till pgplL0HZgkAqX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, 23.11.10 22:44, Till Maas (opensou...@till.name) wrote: On Tue, Nov 23, 2010 at 10:32:00PM +0100, Lennart Poettering wrote: Also note that by now it's somewhat standard that code that needs to be run as part of early boot creates a subdir in /dev, such as /dev/.udev or /dev/.systemd. Not super-pretty, but I guess it's too late to complain about that. This is the first time I read about using a subdir in /dev. Is there some inter-distro agreement about this? The last discussion I had with someone from debian revealed that they use subdirs in /lib for stuff that should be in /var according to the FHS but might be needed before /var is mounted. Well it's not really inter-distro. It mostly inter-maintainers-of- packages-that-are-involved-with-early-boot. I know that at least some storage stuff also puts stuff there, as will most likely u-l-ng to place meta information about mounts. Yes, Debian has /lib/init/rw, and we shortly considered adopting that as suggested default in systemd, but we decided not to do that since more software was already using /dev/.foo/ than /lib/init/rw (which in fact is used only by debian specific scripts afaik at this point), and we didn't want to add yet another fs just for this purpose to the mix. I talked to some Debian guys about this and they have ben thinking about moving /lib/init/rw to /dev/.foobar/ too. I think everybody agrees that /dev/.foobar/ isn't particularly pretty. But given that /dev is some kind of tmpfs these days this should be fine. I don't think it is really necessary to make /dev/.foobar/ some kind of standard however. As the number of services involved with early boot and which need runtime files like this is very limited it should be sufficient to simply come to an agreement with the various maintainers involved, which is a small group. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, Nov 23, 2010 at 09:48:30PM +0100, Lennart Poettering wrote: I hereby want to let everybody know that in the next days I will turn on /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance with the following accepted F15 feature: ░ https://fedoraproject.org/wiki/Features/var-run-tmpfs The release notes section contains this: | /var/run and /var/lock are now mounted from tmpfs, and hence emptied on | reboot. Applications must ensure to recreate their own files/dirs on | startup, and cannot rely that doing this at package installtion will | suffice But this does not mention tmpfiles.d which you wrote can be used instead of creating files or dirs on startup. c) YOU need to edit your .spec file and place a %ghost where appropriate. c) YOU need to test if you package still works, and if necessary file AVC bugs, add an /etc/tmpfiles.d drop-in file to your program, or patch it so that it is able to recreate these directories beneath /var/run on its own. Imho there should be a packaging guideline to make it clear what needs to be done in which cases. E.g. when to %ghost files and when not. On /etc/tmpfiles.d: This is a new feature of systemd, but which is apparently very much liked by people outside of systemd, so this might actually find adoption even on systems which will not adopt systemd any time soon, since it actually is not specific at all to systemd. By dropping a simple configuration file in /etc/tmpfiles.d you can ensure that volatile files and directories are: a) created, deleted or emptied at boot b) their permissions/ownership fixed c) its directory contents cleaned up in regular intervals (a la tmpwatch) and d) it is properly relabeled at boot. As an example, here's how such a file might look like for the screen package (name it /etc/tmpfiles.d/screen.conf): snip d /var/run/screens 1777 root root 10d d /var/run/uscreens 0755 root root 10d12h /snip This encodes that two directories are created under the listed names, with automatic clean up after 10 days resp. 10 days and 12h. Removing /var/run/screens after 10 days sounds wrong. Even removing the sockets inside /var/run/screens sounds wrong. Is this just a bad example am I not understanding the age means. For more details consult the man page: http://0pointer.de/public/systemd-man/tmpfiles.d.html Here it says: | If a file or directory is older than the current time minus the age | field it is deleted. And when are the files and dirs created? Only when the system is booted? But then after installing an package that requires files to be created by tmpfiles.d the system needs to be rebooted before it can be used. Or will rpm call something that parses the appropriate tmpfiles.d file when the package is installed / updated? Regards Till pgp7lPygRktty.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please Review: (656515) Allow Name and Optional UID syntax for grouping attributes
https://bugzilla.redhat.com/show_bug.cgi?id=656515 https://bugzilla.redhat.com/attachment.cgi?id=462466action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Appeal to finish the change in maintainer for the openjpeg package.
On Tue, Nov 23, 2010 at 10:21 AM, Jason L Tibbitts III ti...@math.uh.eduwrote: AH == Adam Hough adam.ho...@gmail.com writes: AH Someone with that right permissions need to change who maintains the AH openjpeg package in Fedora. It has two comaintainers, so I don't really see what the issue is. I went ahead and gave those comaintainers approveacls permission on the Fedora branches so they can add other committers if they desire. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Thank you, I think that should help prevent this situation in the future for this package. The issue was that the patch that was applied in a special build of 1.3.9.1 that fixed the crash was never pushed out to the repositories. I had to complain on the mailing list in an admittedly horribly worded message complaining that the current maintainers had not pushed out a fix for the issue yet. I had though the issue was resolved until I got a Bug Zapper message saying that the bug was still open. I would suggest that one of the co-maintainers add Tom Lane as a committer since he is the person maintaining openjpeg in Redhat Enterprise. - Adam Hough -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, 23.11.10 13:41, Nicholas Miell (nmi...@gmail.com) wrote: On 11/23/2010 12:48 PM, Lennart Poettering wrote: Heya! I hereby want to let everybody know that in the next days I will turn on /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance with the following accepted F15 feature: https://fedoraproject.org/wiki/Features/var-run-tmpfs Is this actually an improvement? See the spec page. I think the fact that we get less disks accesses (just think noatime and stuff for the files dropped there) is more interesting than using the absolute minimal amount of memory. I know that dentries and inodes for regular filesystems can be discarded from RAM if they're not in use, is that the case for a tmpfs? How often are the files in /var/run and /var/lock accessed? Is the kernel likely to discard them? Note that under memory pressure tmpfs can be swapped out. Files in /var/run tend to be 4 or 5 bytes in length, does that mean they each use an entire page of RAM or swap? There are vastly fewer swap pages than there are filesystem blocks, isn't this less efficient? Yes, normal files will take up 4k if they contain data. But that's something that could be fixed and which would not only be useful for this usecase but the much heavier existing users of tmpfs such as udev. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, 23.11.10 23:02, Till Maas (opensou...@till.name) wrote: The release notes section contains this: | /var/run and /var/lock are now mounted from tmpfs, and hence emptied on | reboot. Applications must ensure to recreate their own files/dirs on | startup, and cannot rely that doing this at package installtion will | suffice But this does not mention tmpfiles.d which you wrote can be used instead of creating files or dirs on startup. Added a comment about this now. c) YOU need to edit your .spec file and place a %ghost where appropriate. c) YOU need to test if you package still works, and if necessary file AVC bugs, add an /etc/tmpfiles.d drop-in file to your program, or patch it so that it is able to recreate these directories beneath /var/run on its own. Imho there should be a packaging guideline to make it clear what needs to be done in which cases. E.g. when to %ghost files and when not. I guess extending the guidelines with a line or two about this is a good idea. snip d /var/run/screens 1777 root root 10d d /var/run/uscreens 0755 root root 10d12h /snip This encodes that two directories are created under the listed names, with automatic clean up after 10 days resp. 10 days and 12h. Removing /var/run/screens after 10 days sounds wrong. Even removing the sockets inside /var/run/screens sounds wrong. Is this just a bad example am I not understanding the age means. Sorry, it's not necessarily a great example. The aging stuff is mostly useful for things like /tmp itself. For more details consult the man page: http://0pointer.de/public/systemd-man/tmpfiles.d.html Here it says: | If a file or directory is older than the current time minus the age | field it is deleted. And when are the files and dirs created? Only when the system is booted? Yes. But then after installing an package that requires files to be created by tmpfiles.d the system needs to be rebooted before it can be used. Or will rpm call something that parses the appropriate tmpfiles.d file when the package is installed / updated? Hmm, it has been suggested that we should make it possible to create these dirs in the .spec files by invoking the systemd-tmpfiles tool directly from the scriptlets. I guess we should add a nice interface for that. In the meantime it should be sufficient to simply place th right mkdir -p -m ... in the scriptlet. Of course it would be desirable if we have a single place where the dirs to create are encoded. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On 11/23/2010 02:54 PM, Lennart Poettering wrote:
On Tue, 23.11.10 13:41, Nicholas Miell (nmi...@gmail.com) wrote:
On 11/23/2010 12:48 PM, Lennart Poettering wrote:
Heya!
I hereby want to let everybody know that in the next days I will turn on
/var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance
with the following accepted F15 feature:
https://fedoraproject.org/wiki/Features/var-run-tmpfs
Is this actually an improvement?
See the spec page.
The spec page says it'll be better, but is very vague as to why.
Basically, I'm looking for a Doing this will keep $X kilobytes
permanently pinned in RAM (in the form of dentry and inode structs) and
$Y bytes in RAM or swap (in the form of file data pages), of which $Z
bytes is wasted (due to the fixed page size) and this is {worth it, not
worth it} due to the $N millisecond improvement in boot times.
i.e. an acknowledgment that somebody thought about the trade-offs and
decided it is the right thing to do.
I think the fact that we get less disks accesses (just think noatime and
stuff for the files dropped there) is more interesting than using the
absolute minimal amount of memory.
They're already on a relatime mount, and don't bind mounts support
noatime now? (e.g. mount --bind /var/run /var/run; mount -o
remount,noatime /var/run)
I know that dentries and inodes for regular filesystems can be discarded
from RAM if they're not in use, is that the case for a tmpfs?
How often are the files in /var/run and /var/lock accessed? Is the
kernel likely to discard them?
Note that under memory pressure tmpfs can be swapped out.
The data pages can, but the inodes and dentries are permanently pinned
in unswappable kernel memory.
Files in /var/run tend to be 4 or 5 bytes in length, does that mean they
each use an entire page of RAM or swap? There are vastly fewer swap
pages than there are filesystem blocks, isn't this less efficient?
Yes, normal files will take up 4k if they contain data. But that's
something that could be fixed and which would not only be useful for
this usecase but the much heavier existing users of tmpfs such as udev.
That's a hypothetical future feature, which isn't exactly relevant to
the issue at hand. (And I think mmap() would make that really
complicated.) If anything, it's an argument that udev should be moved
off of a tmpfs, but that's another discussion entirely.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
On 10/5/10 3:27 PM, Jesse Keating wrote: As you might be aware, there was a period of roughly two weeks where a gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and Fedora 15. Items built with this could have undefined behavior, which could lead to data corruption. Unfortunately I'm told that it is impossible to look at a generated binary and detect whether or not the binary would be effected by this bug. The only reliable way to tell would be to re-create the build environment exactly, except replace GCC with one that will detect the error scenario and print something. As this is a significant amount of work, I decided instead to just rebuild the potential problem builds. I detected all the latest builds of packages that had gcc-4.5.1-3.fc14 in the buildroot, and then further narrowed it down to things which require rtld(GNU_HASH) to find the things that actually used gcc (since gcc gets thrown in every buildroot anyway). For Fedora 15 this was a simple task. Just find the packages where the latest build is bad, bump it and rebuild it. End of story. This work is already done (except that a few have failed, and I need to follow up on those). For Fedora 14 the matter is much more complicated. Builds are spread out across 3 main tags, dist-f14, dist-f14-updates-testing, and dist-f14-updates-candidate. dist-f14 is things that have made it through bodhi as stable. dist-f14-updates-testing is for things which are currently in updates-testing dist-f14-updates-candidate is for things which could potentially become an update should the maintainer decide. To handle the F14 scene I've come up with this strategy: * For things tagged in dist-f14 and no newer build elsewhere, do a bump, build and tag directly into dist-f14. While there is some risk of breakage, it is quite minimal and with discussion from QA we are willing to take that chance. This work is ongoing. * For things tagged in dist-f14-updates-testing, do a bump, build and then edit the bodhi ticket to add the new build, and re-push to updates-testing. This work will begin soon. * for things tagged in dist-f14-updates-candidate, do a bump and build. Then look for an open bodhi ticket for that package, adjusting as needed. If no bodhi ticket is found, do not create a new one, just leave the build as is. This work will begin soon. Using this strategy we should be able to replace potentially bad builds with corrected ones wherever they might have been published (barring the failed builds). This message is mostly a heads up as to what's happening. Now that F14 has shipped and other emergencies have been dealt with, I got back into this task. Unfortunately as time has gone on, there is now builds in dist-f14-updates to deal with as well as dist-f14, so I wanted to ping the list before I continue. I've identified a number of published builds that are still potentially broken in the F14 family, and have fixed builds for many of them. The real question is what to do with things in dist-f14 or dist-f14-updates that are potentially bad. What we did with the first round was to just tag the rebuilds on top of the previous build, if nothing else had changed. This was deemed safe enough to bypass updates-testing. That was pre-release though, we're not post-release, does this thought still stand? We could tag things directly into dist-f14-updates, bypassing bodhi or we could create new bodhi update requests for each item and either get karma or wait for the timeout. We're talking about 72 update requests that could be filed right now. There are also a few packages where a fixed build doesn't exist yet due to errors. Those need closer examination. Finally we have some builds that are in -testing that are potentially bad. I've replaced those with good builds and re-sent them back to -testing, the maintainer can choose to push them stable at will. Here is a list of the current known potentially bad builds and what action could be or has been taken: wireshark - Update pending wildmidi - my rebuild can be tagged usermode - my build can be tagged tigervnc - my build can be tagged tecnoballz - my build can be tagged tar - Update in testing syncevolution - update in testing spamass-milter - my build can be tagged shiboken - my build can be tagged rtpproxy - my build can be tagged raul - my build can be tagged python-storm - my build can be tagged python-crypto - my build can be tagged python - potential update in -candidate; pinged dmalcolm pycryptopp - my build can be tagged. pspp - my build can be tagged plee-the-bear - my build can be tagged perl-Text-Hunspell - my build can be tagged openchange - my build can be tagged nxtrc - my build can be tagged nasm - update in testing mutter-moblin - my build can be tagged (and tag into dist-f15) mutt - my build can be tagged moblin-panel-status - my build can be tagged moblin-panel-people - my build can be tagged
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
On Tue, Nov 23, 2010 at 03:45:26PM -0800, Jesse Keating wrote: gcc - update in -candidate, ping jakub Just remove gcc from your list. gcc is bootstrapped, so the installed gcc only builds first stage, everything else is built by (one of the) newly built compiler(s). So, gcc in f14 surely doesn't have that problem in it. I'll eventually do a f14 gcc errata, but only when I accumulate more fixes... Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On 11/23/2010 03:02 PM, Till Maas wrote: On Tue, Nov 23, 2010 at 09:48:30PM +0100, Lennart Poettering wrote: I hereby want to let everybody know that in the next days I will turn on /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance with the following accepted F15 feature: ░ https://fedoraproject.org/wiki/Features/var-run-tmpfs The release notes section contains this: | /var/run and /var/lock are now mounted from tmpfs, and hence emptied on | reboot. Applications must ensure to recreate their own files/dirs on | startup, and cannot rely that doing this at package installtion will | suffice But this does not mention tmpfiles.d which you wrote can be used instead of creating files or dirs on startup. c) YOU need to edit your .spec file and place a %ghost where appropriate. c) YOU need to test if you package still works, and if necessary file AVC bugs, add an /etc/tmpfiles.d drop-in file to your program, or patch it so that it is able to recreate these directories beneath /var/run on its own. Imho there should be a packaging guideline to make it clear what needs to be done in which cases. E.g. when to %ghost files and when not. I'm curious, one of my packages has /var/run/dspam in the specfile and /var/lock/subsystem/dspam used in the initscript... I added a %ghost for the second and now I'm wondering if I even need to.. Should I revert that change? and just %ghost /var/run/dspam ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-24)
On Tue, 2010-11-23 at 13:05 -0700, Kevin Fenzi wrote: Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 18:30UTC (1:30pm EDT) in #fedora-meeting on irc.freenode.net. I'm not going to be able to make this, I'll be on the road for Thanksgiving. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Tue, 23.11.10 18:44, Michał Piotrowski (mkkp...@gmail.com) wrote: W dniu 23 listopada 2010 18:35 użytkownik philippe makowski makowski.fed...@gmail.com napisał: 2010/11/23 Michał Piotrowski mkkp...@gmail.com: W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: We can create a list of all scripts in wiki and maintainers of individual packages would indicate that they want to convert scripts themselves. I'll try to do it for Firebird package can you give me some hints and place I have to read before ? This is a good start point http://0pointer.de/blog/projects/systemd-for-admins-3.html About services, sockets, targets etc http://0pointer.de/public/systemd-man/ You may want to read all systemd related things from http://0pointer.de/blog/ (if you don't know how it works, you should start from begining) Most important is actually the draft of the packaging guide for systemd: http://fedoraproject.org/wiki/Systemd_Packaging_Draft (see the lower part of it, ignore the top) Also, of particular interest is http://0pointer.de/public/systemd-man/daemon.html. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
On 11/23/2010 03:45 PM, Jesse Keating wrote: Here is a list of the current known potentially bad builds and what action could be or has been taken: Please alphabetize such a list, always! _PLEASE_? An alphabetized list is several times more effective at communication because advanced readers can process it more quickly by eye than a list that is in random order. Most mail user agent (MUA) software provides tools for string search, but using that often takes more time than a scan-and-PageDown. apcupsd - my build can be tagged apiextractor - my build can be tagged atanks - my build can be tagged avr-gcc - my build can be tagged awn-extras-applets - my build can be tagged bluefish - update in testing busybox - update in testing calf - my build can be tagged ccache - my build can be tagged celt - my build can be tagged chktex - my build can be tagged clutter-gtk - fixed build in updates clutter - my build can be tagged contacts - my build can be tagged dspam - my build can be tagged dssi - my build can be tagged elfutils - my build can be tagged flowcanvas - my build can be tagged folks - my build can be tagged frepple - my build can be tagged fuse-convmvfs - my build can be tagged gappa - my build can be tagged gcc - update in -candidate, ping jakub gedit-vala - my build can be tagged generatorrunner - my build can be tagged ghc-Boolean - my build can be tagged ghc-gio - no build ghc-pango - my build can be tagged ghc-terminfo - my build can be tagged ghostscript - update in candidate, ping owner glib-java - my build can be tagged gnustep-examples - my build can be tagged gretl - update in testing gridsite - my build can be tagged gstreamer-plugins-bad-free - my build can be tagged gtk+extra - my build can be tagged http-parser - my build can be tagged igraph - update in testing jack_capture - my build can be tagged jana - my build can be tagged koffice - my build can be tagged ldc - removed from updates-testing ledger - my build can be tagged lensfun - my build can be tagged libass - my build can be tagged libclaw - my build can be tagged libeio - my build can be tagged libglade-java - no build libgnome-java - no build libgtk-java - no build liblastfm - my build can be tagged libmutil - my build can be tagged libnfc - my build can be tagged libnxt - my build can be tagged libpst - my build can be tagged libselinux - update in testing libunicapgtk - my build can be tagged libvte-java - spots build can be tagged mailman - update in testing matahari - my build can be tagged meego-panel-datetime - update in testing midori - my build can be tagged minicom - my build can be tagged moblin-panel-applications - my build can be tagged moblin-panel-myzone - my build can be tagged moblin-panel-people - my build can be tagged moblin-panel-status - my build can be tagged mutter-moblin - my build can be tagged (and tag into dist-f15) mutt - my build can be tagged nasm - update in testing nxtrc - my build can be tagged openchange - my build can be tagged perl-Text-Hunspell - my build can be tagged plee-the-bear - my build can be tagged pspp - my build can be tagged pycryptopp - my build can be tagged. python-crypto - my build can be tagged python - potential update in -candidate; pinged dmalcolm python-storm - my build can be tagged raul - my build can be tagged R-ROC - my build can be tagged rtpproxy - my build can be tagged setuptool - my build can be tagged shiboken - my build can be tagged spamass-milter - my build can be tagged syncevolution - update in testing tar - Update in testing tecnoballz - my build can be tagged tigervnc - my build can be tagged usermode - my build can be tagged wildmidi - my rebuild can be tagged wireshark - Update pending -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote: Hi, I would like to help with scripts conversion. IMO the conversion action should be coordinated. Comments, thoughts? I would certainly welcome any work in this direction! I think it would make sense to use Johann's page in the wiki as the central place to keep track of this: https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability In another mail on this thread there was already a list of documentation posted. If you need real-life examples how this should look like, then consider having a look on a packge such as bluez (keep however in mind that this package predates the packaging daft, so if in doubt the draft is right and the package is wrong... ;-)). Also note that ideally services that currently are exclusively bus activated gain native systemd files as well, so that they for the first time can be controlled, supervised and introspected like any other service on the system. This adds the following packages to the list of packages to convert: abrt accountsservice ailurus avahi blueman bluez ConsoleKit cups-pk-helper dconf fprintd GConf2 gnome-applets gnome-lirc-properties gnome-settings-daemon gnome-system-monitor gypsy hal kdebase-runtime kdebase-workspace ModemManager NetworkManager PackageKit polkit rtkit sectool setroubleshoot system-config-firewall system-config-kdump system-config-samba system-config-services systemd udisks upower wpa_supplicant. (A number of these are already converted actually) If you have any questions regarding writing service files, refer to the linked documentation, especially the packaging draft: https://fedoraproject.org/wiki/Systemd_Packaging_Draft#Scriptlets (Note that this is still a draft, and not official, so take it with a pinch of salt!) Also, have a look into the already converted service files in /lib/systemd/system/*. Note however that service files for stuff involved in early boot and late shutdown are not suitable as an example, since they are very different than the service files of normal services, since early boot/late shutdown services have manually configured dependencies. You can easily recognize them by the DefaultDependencies=no setting. Don't be confused by those, just ignore them! Of course, the helpful folks on #systemd on freenode will be happy to answer any questions you might have, and especially I myself will be (mezcalero). However, for the next weeks I'll be backpacking through India and not be particularly responsive. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-24)
Adam Jackson (a...@redhat.com) said: On Tue, 2010-11-23 at 13:05 -0700, Kevin Fenzi wrote: Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 18:30UTC (1:30pm EDT) in #fedora-meeting on irc.freenode.net. I'm not going to be able to make this, I'll be on the road for Thanksgiving. I am highly unlikely to make it, for similar reasons. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
Michał Piotrowski (mkkp...@gmail.com) said: MP How can I get information about all packages that provides init MP scripts? repoquery --whatprovides '/etc/init.d/*' It seems to me that too little packages was returned Add '/etc/rc.d/init.d/*' too; while they both resolve to the same place, the filelist might have it in either. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, Nov 23, 2010 at 11:54:47PM +0100, Lennart Poettering wrote: I think the fact that we get less disks accesses (just think noatime and stuff for the files dropped there) is more interesting than using the absolute minimal amount of memory. Less disk access at startup, or in general somehow? Optimizing for startup performance over general performance does not seem so good. But this is really about elegance rather than resource usage, right? Currently, /var/run and /var/lock on my rawhide desktop system take up 364K. 385K on another rawhide system. (Blocksize of 4k.) I think we can spare that in this day and age if we get a reasonable benefit in return. Meanwhile, NetworkManager is doing absolutely nothing for me, and is taking up a USS of 65.3M. If we're gonna tilt at memory consumption windmills, how about we take a look at that one? (NetworkManager is awesome on my _laptop_, by the way. Wouldn't dream of living without 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
Re: Urgent: today's F14 catastrophe with openldap-servers update
Jan Vcelak jvce...@redhat.com wrote: This is the problem: The database migration could take a really long time. I have testing data with 56 entries (nodes) - exporting (slapcat) is quite fast, but importing (slapadd) takes around 10 seconds. Hmm. I've seen selinux-policy-targeted take longer than this on upgrades. SELinux is a little more obvious that it's doing something on upgrade (and after looking at the spec file[1], I'd not sure whether I'd have rather not known ;) ), but I don't think it'd be unheard of. --Ben [1]http://pkgs.fedoraproject.org/gitweb/?p=selinux-policy.git;a=blob;f=selinux-policy.spec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
On 11/23/2010 07:36 PM, Jan Vcelak wrote: On Tuesday 23 November 2010 19:13:09, Panu Matilainen wrote: Another related thing is that Berkeley DB which openldap uses is notoriously picky about getting updated. I'm fairly certain openldap does not update their bundled BDB version to prevent issues like this on minor updates, and AFAICT (based on a quick lookaround at the changelogs etc) in this case it was this fix to comply with our own policies (no bundled libraries) that bit us when synced with rawhide version: * Fri Aug 27 2010 Jan Vcelakjvce...@redhat.com 2.4.23-1 - rebase to 2.4.23 - embeded db4 library removed - Panu - You are right. My fault. :-( No, it's not your fault (Or at least only partially). A functional QA would catch such kind of breakages. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, 23 Nov 2010, Nicholas Miell wrote:
The spec page says it'll be better, but is very vague as to why.
Basically, I'm looking for a Doing this will keep $X kilobytes
permanently pinned in RAM (in the form of dentry and inode structs) and
$Y bytes in RAM or swap (in the form of file data pages), of which $Z
bytes is wasted (due to the fixed page size) and this is {worth it, not
worth it} due to the $N millisecond improvement in boot times.
i.e. an acknowledgment that somebody thought about the trade-offs and
decided it is the right thing to do.
Personally, I think its worth it just because a rebooted/crashed system starts
with a clean /var/run and /var/lock. Too often I've seen things not startup
based on a stale pid file.
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
On 11/23/10 5:04 PM, John Reiser wrote: Please alphabetize such a list, always! _PLEASE_? An alphabetized list is several times more effective at communication because advanced readers can process it more quickly by eye than a list that is in random order. Most mail user agent (MUA) software provides tools for string search, but using that often takes more time than a scan-and-PageDown. This wasn't a list of things maintainers needed to perform an action upon. If it were, I would have sorted it, by package owner. This was more of just a listing of the actions that /I/ would be doing, a list of the packages. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On Mon, Nov 22, 2010 at 12:39, Jesse Keating jkeat...@redhat.com wrote: On 11/22/2010 11:18 AM, Toshio Kuratomi wrote: They said that they install a Fedora for testing purposes when it first comes out and enjoy the rapid pace of bugfixes as they test the software in their environment. Then, the update pace slows down at about the same time their ready to push things out to the machines in their env. I think there's likely better ways that they could achieve this if we were optimizing for this, though. This sounds like install the newly Branched release (AKA Alpha), which has rapid updates, but should slow down once it goes GOLD, and then be slow and stable for the next 13 months after that. It sounds like it.. but psychologically is a completely different thing. Alpha/beta/rawhide all sound too scary and they won't go near it. However when they finally get on an RC or release they will go through the same steps that the alpha/beta/rawhide/ or -testers users had to do. Which then leads to a lot of stuff getting rolled in at the last minute. I just don't think Slow and Stable is ever going to work with Fedora. -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Passing ownership of mingetty
On Thu, 11 Nov 2010, Lennart Poettering wrote: That way most distros would only have to install one getty implementation, and can use it for both serial consoles and VCs. Yes please. Bonus points for anaconda configuring a working agetty login if the install console was serial. That is, run agetty using the same linespeed as the install and add the serial device to securetty. (last install I did, though it was rhel5, on a machine without VGA left me with no way to login to the system after install (kickstart didn't add a non-root user) Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
Hi, On 11/24/2010 12:45 AM, Jesse Keating wrote: On 10/5/10 3:27 PM, Jesse Keating wrote: snip Here is a list of the current known potentially bad builds and what action could be or has been taken: wildmidi - my rebuild can be tagged tecnoballz - my build can be tagged These 2 are mine and FWIW, I'm ok with directly tagging the rebuilds into updates Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File PPIx-EditorTools-0.11.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-PPIx-EditorTools: a56672022c0e382f168ccce08b2a3e26 PPIx-EditorTools-0.11.tar.gz -- 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-PPIx-EditorTools] New upstream release, v0.11
commit ea52ef008086f3dba7161044c44882ef8a0e725d
Author: Petr Sabata psab...@redhat.com
Date: Tue Nov 23 09:03:47 2010 +0100
New upstream release, v0.11
.gitignore |1 +
perl-PPIx-EditorTools.spec | 13 ++---
sources|2 +-
3 files changed, 12 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 2765e50..c81042f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
PPIx-EditorTools-0.09.tar.gz
/PPIx-EditorTools-0.10.tar.gz
+/PPIx-EditorTools-0.11.tar.gz
diff --git a/perl-PPIx-EditorTools.spec b/perl-PPIx-EditorTools.spec
index 60200b4..1b0f81e 100644
--- a/perl-PPIx-EditorTools.spec
+++ b/perl-PPIx-EditorTools.spec
@@ -1,5 +1,5 @@
Name: perl-PPIx-EditorTools
-Version:0.10
+Version:0.11
Release:1%{?dist}
Summary:Utility methods and base class for manipulating Perl via PPI
License:GPL+ or Artistic
@@ -9,13 +9,17 @@ Source0:
http://search.cpan.org/CPAN/authors/id/A/AZ/AZAWAWI/PPIx-EditorT
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(Class::XSAccessor) = 1.02
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.31
BuildRequires: perl(File::Spec)
BuildRequires: perl(PPI) = 1.203
# Tests only:
# Real version perl(Test::Differences) = 0.4801 clamped to 2 digits
BuildRequires: perl(Test::Differences) = 0.48
BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Most)
+BuildRequires: perl(Test::Warn)
+BuildRequires: perl(Test::Exception)
+BuildRequires: perl(Test::Deep)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(Class::XSAccessor) = 1.02
Requires: perl(File::Spec)
@@ -53,11 +57,14 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
-%doc Changes README TODO
+%doc Changes README LICENSE
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Tue Nov 23 2010 Petr Sabata psab...@redhat.com - 0.11-1
+- New upstream version, v0.11
+
* Mon Oct 04 2010 Petr Pisar ppi...@redhat.com - 0.10-1
- 0.10 bump
- Update Source URL
diff --git a/sources b/sources
index 7a61b61..115d218 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a48bf178d3ae63c2221bde55f264cbef PPIx-EditorTools-0.10.tar.gz
+a56672022c0e382f168ccce08b2a3e26 PPIx-EditorTools-0.11.tar.gz
--
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
