Re: Reasons for hall monitoring
On Thu, May 06, 2010 at 07:53:52PM -0400, Orcan Ogetbil wrote: > On Thu, May 6, 2010 at 6:26 PM, Karel Zak wrote: > > On Thu, May 06, 2010 at 05:46:21PM -0400, Brian Pepple wrote: > >> On Thu, 2010-05-06 at 23:22 +0200, Matěj Cepl wrote: > >> > Dne 6.5.2010 12:28, Karel Zak napsal(a): > >> > >> Thank you for pointing out yet another undemocratic policy passed by > >> > >> one of > >> > > > >> > > +1 The Hall Monitor Policy is cancer. > >> > > >> > +1000 it feels to me like in a bad old Communism when the open debate > >> > was allowed only when it didn't touch the leading role of the Communist > >> > Party. I really don't think anybody in this thread said anything so > >> > sacrilegious that the thread should be terminated. > >> > >> Normally, I'd be against it killing a thread, but the thread that > >> started this discussion had already been done awhile back and this new > >> thread added *nothing* new to the discussion. Frankly, it was more > > > > This all is your subjective opinion. There is not objective and > > unbiased way how evaluate any discussion, it's unmeasurable. > > I don't agree. There are logical ways to measure this. e.g. > > N people participate in a thread. > -> (N/2)+1 of them complains to the moderator > -> the thread gets closed. Why people in (N/2)+1 group read the thread? Masochism? Why do you think that the thread is interesting only for people who participate in the thread? We have many passive readers. I think old good "Don't feed trolls!" is better than arbitrary attempt to implement censorship. Karel -- Karel Zak http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 yum in kvm or vmware guests
On ۱۰/۰۵/۰۶ 11:47, Seth Vidal wrote: > > > On Thu, 6 May 2010, Hedayat Vatnakhah wrote: > >> Hi, >> >> Warren Togami wrote on پنجشنبه ۰۶ مه ۱۰، >> ۰۲:۱۰:۴۸:On ۱۰/۰۵/۰۶ 02:10, Warren Togami >> wrote: >> >> (10/12): samba-3.5.2-60.fc13.x86_64.rpm (71%) 73% >> [- ] 0.0 B/s | 3.7 MB >> 3340883129410265958989882401668816722716705737932:48 ETA >> >> Anyone else seeing this kind of behavior with F-13 yum within kvm or >> vmware guests? It seems to happen consistently here in the middle of >> downloading multiple packages where I need to kill yum and try again. >> >> >> It is nothing new if you've tried using yum in a poor internet >> connection. I've seen it regularly in Fedora >> 12 and IIRC Fedora 11. >> > > Hedayat, > take the python-urlgrabber pkg from rawhide 0 3.9.1-6.fc14 and give > it a whirl. OK, I'll do it ASAP and let you know the results (I'll probably unable to do so until Sunday, but then I'll try it). Thanks, Hedayat > > -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-User-Identity/devel perl-User-Identity.spec,1.7,1.8
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-User-Identity/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv2913
Modified Files:
perl-User-Identity.spec
Log Message:
- Mass rebuild with perl-5.12.0
Index: perl-User-Identity.spec
===
RCS file: /cvs/pkgs/rpms/perl-User-Identity/devel/perl-User-Identity.spec,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- perl-User-Identity.spec 7 Dec 2009 08:38:35 - 1.7
+++ perl-User-Identity.spec 7 May 2010 09:00:44 - 1.8
@@ -1,6 +1,6 @@
Name: perl-User-Identity
Version:0.92
-Release:6%{?dist}
+Release:7%{?dist}
Summary:Maintains info about a physical person
Group: Development/Libraries
License:GPL+ or Artistic
@@ -43,6 +43,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Fri May 07 2010 Marcela Maslanova - 0.92-7
+- Mass rebuild with perl-5.12.0
+
* Mon Dec 7 2009 Stepan Kasal - 0.92-6
- rebuild against perl 5.10.1
--
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
File Devel-Cover-0.66.tar.gz uploaded to lookaside cache by mmaslano
A file has been added to the lookaside cache for perl-Devel-Cover: db1a982fc82454c4f5a2d8edcc857cf3 Devel-Cover-0.66.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
Could someone, please, clarify situation with *-javadoc
Hello All! Sometimes *-javadoc sub-packages explicitly requires main package, and sometimes - not. I'm not a java-expert, so I don't know which is correct. Could someone, please, clarify this? -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 13 RC #1 testing open
Fedora 13 Final RC1 is now becoming available [1]. Please refer to the following pages for download links and testing instructions. At present, i386 DVD, split CD and netinst images are available: x86-64 images and live images will be available in due course. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha, Beta, and Final priority test cases for installation [2] and desktop [3] should pass in order to meet the Final Release Criteria [4]. Help is available on #fedora-qa on irc.freenode.net [5], or on the test list [6]. [1] http://poelstra.fedorapeople.org/schedules/f-13/f-13-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [4] https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria [5] irc://irc.freenode.net/fedora-qa [6] https://admin.fedoraproject.org/mailman/listinfo/test -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-WWW-Myspace/devel perl-WWW-Myspace.spec,1.18,1.19
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-WWW-Myspace/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv14584
Modified Files:
perl-WWW-Myspace.spec
Log Message:
- Mass rebuild with perl-5.12.0
Index: perl-WWW-Myspace.spec
===
RCS file: /cvs/pkgs/rpms/perl-WWW-Myspace/devel/perl-WWW-Myspace.spec,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -p -r1.18 -r1.19
--- perl-WWW-Myspace.spec 7 Dec 2009 07:17:15 - 1.18
+++ perl-WWW-Myspace.spec 7 May 2010 10:37:07 - 1.19
@@ -12,7 +12,7 @@
Name: perl-WWW-Myspace
Version: 0.60
-Release: 5%{?dist}
+Release: 6%{?dist}
Summary: Access your myspace.com profile in Perl!
Group:Development/Libraries
@@ -96,6 +96,9 @@ rm -rf %{buildroot}
%changelog
+* Fri May 07 2010 Marcela Maslanova - 0.60-6
+- Mass rebuild with perl-5.12.0
+
* Mon Dec 7 2009 Stepan Kasal - 0.60-5
- rebuild against perl 5.10.1
--
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: GConf error
On Thu, 2010-05-06 at 20:44 +0200, Pierre-Yves wrote:
> Hi,
>
> Being the maintainer of Guake I have received a number of bug gconf
> related [1]. Their common pattern is that they only appear the first
> time guake is installed and run (and then again not always).
>
> If the user restart X/the computer, the bug does not appear at all.
>
> I am therefore quite unsure of what to do with these bugs. I asked
> upstream who also is not sure. It is like if the gconf schema was not
> correctly install while I install it via:
>
> %post
> export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
> gconftool-2 --makefile-install-rule \
> %{_sysconfdir}/gconf/schemas/%{name}.schemas > /dev/null || :
> (cf [2] and [3] for build log)
>
> Why am I doing wrong ?
> Is this gconf issue ?
>
Would it be allowed to try to restart gconfd ?
It seems that the debian package is doing so.
Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100507 changes
Compose started at Fri May 7 05:31:05 UTC 2010 New package banshee-community-extensions Collection of extensions for the media player Banshee New package byobu Light-weight, configurable window manager built upon GNU screen New package jffi An optimized Java interface to libffi New package jgrapht A free Java graph library that provides mathematical graph objs and algorithms New package libsysactivity Library for retrieving statistics of the system`s activity New package perl-CGI-Compile Compile .cgi scripts to a code reference like ModPerl::Registry New package perl-Sys-CPU Getting CPU information Updated Packages: anjuta-2.30.0.0-2.fc13 -- * Thu Apr 29 2010 Debarshi Ray - 1:2.30.0.0-2 - The Python templates in /usr/share/anjuta/project/python can not be byte-compiled. Try not to abort the build on byte-compilation errors. - Updated the icon cache and scrollkeeper scriptlet snippets according to Fedora packaging guidelines. * Thu Apr 29 2010 Debarshi Ray - 1:2.30.0.0-1 - Version bump to 2.30.0.0. * Completion for ., -> and :: in C/C++. * PackageKit integration. * Support for a simple 'Directory' project. * Support for Javascript. * Support for Vala symbols in the symbol-db. * Fixed shortcut grabbing. (GNOME Bugzilla #567689) * Loading file from command line should not put starter page in front of file. (GNOME Bugzilla #582726) * Send special keys to the terminal. (GNOME Bugzilla #559925) * Smaller icons in plugin list. (GNOME Bugzilla #550715) * Build (basic Autotools) plugin: + Underline warnings/errors using user-selected message colors. (GNOME Bugzilla #567029) + Missing call to fclose. (GNOME Bugzilla #599532) + Allow project path to contain space. (GNOME Bugzilla #604954) + Do not crash when trying to compile a file without an open project. (GNOME Bugzilla #612959) * Debug manager plugin: + Easier addition of watches. (GNOME Bugzilla #596009) + Single-step highlighting works only for the first opened project. (GNOME Bugzilla #605060) * File manager: + Saving a file duplicates its entry. (GNOME Bugzilla #605050) * GDB plugin: + Can not attach to a process to debug it. (GNOME Bugzilla #606069) * GtkSourceView editor plugin: + Parenthesis in strings confuse auto-indentation. (GNOME Bugzilla #586457) + Tooltip evaluation does not respect mouse position. (GNOME Bugzilla * Language support (C, C++, Java) plugin: + Do not auto-complete inside string or comment. (GNOME Bugzilla #566982) + Better expression parsing. (GNOME Bugzilla #608499) * Message view plugin: + Do not print garbage for messages in bold font. (GNOME Bugzilla #566194) * Project manager plugin: + Allow Python source to be added to a project. (GNOME Bugzilla #559876) + Fixed 'add project target'. (GNOME Bugzilla #565191) + Do not create random directories when importing. (GNOME Bugzilla #607415) * http://download.gnome.org/sources/anjuta/2.29/anjuta-2.29.92.0.news * http://download.gnome.org/sources/anjuta/2.29/anjuta-2.29.90.0.news * http://download.gnome.org/sources/anjuta/2.29/anjuta-2.29.6.0.news * http://download.gnome.org/sources/anjuta/2.29/anjuta-2.29.5.0.news - Added 'BuildRequires: dbus-glib-devel vala-devel'. - Dropped patch to fix build failures due to missing libxml cflags/libs. (GNOME Bugzilla #567029) - Force verbose build output with '--disable-silent-rules'. * Tue Feb 16 2010 Debarshi Ray - 1:2.28.2.0-1 - Version bump to 2.28.2.0. * Class generator plugin: + C++ keywords should not be translated. (GNOME Bugzilla #606801) * Git plugin: + Fixed failure while importing. (GNOME Bugzilla #601567) * Symbol-db plugin: + Editing some text while searching should not lead to an inconsistent state. (GNOME Bugzilla #566209) * http://download.gnome.org/sources/anjuta/2.28/anjuta-2.28.2.0.news authconfig-6.1.4-1.fc13 --- * Tue May 04 2010 Tomas Mraz - 6.1.4-1 - set the new icon also for the windows (#583330) - updated translations - disable non-smartcard PAM stacks if require smart card for authentication - remove pam_pkcs11 from the password PAM stack - set smartcard action also in gconf - properly set the options for pam_pkcs11 - do not write pam_password option to nslcd.conf (#585953) banshee-1.6.0-1.fc13 * Wed Mar 31 2010 Christian Krause - 1.6.0-1 - Update to 1.6.0 release * Fri Mar 12 2010 Christian Krause - 1.5.5-1 - Update to 1.5.5 release * Sun Feb 28 2010 Christian Krause - 1.5.4-1 - Update to 1.5.4 release - Remove upstreamed patch (Spanish translation update) * Thu Feb 18 2010 Karsten Hopp -2.1 - disable ipod support on s390(x), enable boo support * Thu Feb 04 2010 Christian Krause - 1.5.3-2 - Update Spanish translation beagle-0.3.9-18.fc13 * Thu Apr 01 2010 Christian Krause - 0.3.9-18 - Rebuilt ag
rawhide report: 20100507 changes
Compose started at Fri May 7 08:15:04 UTC 2010 Broken deps for i386 -- almanah-0.7.2-1.fc13.i686 requires libedataserver-1.2.so.11 almanah-0.7.2-1.fc13.i686 requires libedataserverui-1.2.so.8 anjal-0.3.2-2.fc14.i686 requires libedataserver-1.2.so.11 anjal-0.3.2-2.fc14.i686 requires libcamel-1.2.so.14 anjal-0.3.2-2.fc14.i686 requires libcamel-provider-1.2.so.14 anjal-0.3.2-2.fc14.i686 requires libedataserverui-1.2.so.8 clutter-gtkmm-0.9.4-3.fc12.i686 requires libcluttermm-0.9.so.3 clutter-gtkmm-devel-0.9.4-3.fc12.i686 requires pkgconfig(cluttermm-0.9) dates-0.4.11-3.fc14.i686 requires libedataserver-1.2.so.11 dcbd-0.9.19-3.fc14.i686 requires libconfig.so.8 empathy-2.30.1-2.fc14.i686 requires libedataserver-1.2.so.11 evolution-couchdb-0.3.2-2.fc13.i686 requires libcamel-provider-1.2.so.14 evolution-couchdb-0.3.2-2.fc13.i686 requires libcamel-1.2.so.14 evolution-couchdb-0.3.2-2.fc13.i686 requires libedataserver-1.2.so.11 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 evolution-sharp-0.21.1-5.fc13.i686 requires libedataserver-1.2.so.11 glabels-2.2.7-1.fc14.i686 requires libedataserver-1.2.so.11 gnome-launch-box-0.4-17.fc13.i686 requires libedataserver-1.2.so.11 gnome-panel-2.30.0-1.fc14.i686 requires libedataserverui-1.2.so.8 gnome-panel-2.30.0-1.fc14.i686 requires libedataserver-1.2.so.11 gnome-phone-manager-0.65-5.fc12.i686 requires libedataserver-1.2.so.11 gnome-phone-manager-telepathy-0.65-5.fc12.i686 requires libedataserver-1.2.so.11 gpsdrive-2.10-0.5.pre7.fc13.i686 requires libgps.so.18 kdebase-workspace-4.4.3-1.fc14.i686 requires libgps.so.18 kdeedu-marble-libs-4.4.3-1.fc14.i686 requires libgps.so.18 1:libopensync-plugin-evolution2-0.22-3.fc13.i686 requires libedataserver-1.2.so.11 lldpad-0.9.32-1.fc14.i686 requires libconfig.so.8 mumble-1.2.2-6.fc14.i686 requires libprotobuf.so.4 murmur-1.2.2-6.fc14.i686 requires libprotobuf.so.4 nautilus-sendto-2.28.4-1.fc14.i686 requires libedataserver-1.2.so.11 pygsl-0.9.5-1.fc14.i686 requires gsl = 0:1.13 pygsl-devel-0.9.5-1.fc14.i686 requires gsl-devel = 0:1.13 qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 rubygem-right_aws-1.10.0-3.fc14.noarch requires rubygem(right-http_connection) >= 0:1.2.4 tracker-search-tool-0.8.4-1.fc14.i686 requires libedataserver-1.2.so.11 tracker-search-tool-0.8.4-1.fc14.i686 requires libcamel-1.2.so.14 tracker-search-tool-0.8.4-1.fc14.i686 requires libcamel-provider-1.2.so.14 vfrnav-0.4-1.fc13.i686 requires libgps.so.18 vifir-0.4-2.fc14.i686 requires libgps.so.18 viking-0.9.9-1.fc12.i686 requires libgps.so.18 xapian-bindings-python-1.0.18-1.fc14.i686 requires libxapian.so.15 xapian-bindings-ruby-1.0.18-1.fc14.i686 requires libxapian.so.15 Broken deps for x86_64 -- almanah-0.7.2-1.fc13.x86_64 requires libedataserverui-1.2.so.8()(64bit) almanah-0.7.2-1.fc13.x86_64 requires libedataserver-1.2.so.11()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libcamel-provider-1.2.so.14()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libedataserverui-1.2.so.8()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libcamel-1.2.so.14()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) clutter-gtkmm-0.9.4-3.fc12.i686 requires libcluttermm-0.9.so.3 clutter-gtkmm-0.9.4-3.fc12.x86_64 requires libcluttermm-0.9.so.3()(64bit) clutter-gtkmm-devel-0.9.4-3.fc12.i686 requires pkgconfig(cluttermm-0.9) clutter-gtkmm-devel-0.9.4-3.fc12.x86_64 requires pkgconfig(cluttermm-0.9) dates-0.4.11-3.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) dcbd-0.9.19-3.fc14.x86_64 requires libconfig.so.8()(64bit) empathy-2.30.1-2.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) evolution-couchdb-0.3.2-2.fc13.x86_64 requires libcamel-provider-1.2.so.14()(64bit) evolution-couchdb-0.3.2-2.fc13.x86_64 requires libcouchdb-glib-1.0.so.1()(64bit) evolution-couchdb-0.3.2-2.fc13.x86_64 requires libcamel-1.2.so.14()(64bit) evolution-couchdb-0.3.2-2.fc13.x86_64 requires libedataserver-1.2.so.11()(64bit) evolution-sharp-0.21.1-5.fc13.x86_64 requires libedataserver-1.2.so.11()(64bit) glabels-2.2.7-1.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) gnome-launch-box-0.4-17.fc13.x86_64 requires libedataserver-1.2.so.11()(64bit) gnome-panel-2.30.0-1.fc14.x86_64 requires libedataserverui-1.2.so.8()(64bit) gnome-panel-2.30.0-1.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) gnome-phone-manager-0.65-5.fc12.x86_6
rpms/perl-XML-Filter-XInclude/devel perl-XML-Filter-XInclude.spec, 1.5, 1.6
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-XML-Filter-XInclude/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv25241
Modified Files:
perl-XML-Filter-XInclude.spec
Log Message:
- Mass rebuild with perl-5.12.0
Index: perl-XML-Filter-XInclude.spec
===
RCS file:
/cvs/pkgs/rpms/perl-XML-Filter-XInclude/devel/perl-XML-Filter-XInclude.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- perl-XML-Filter-XInclude.spec 7 Dec 2009 06:00:27 - 1.5
+++ perl-XML-Filter-XInclude.spec 7 May 2010 12:00:29 - 1.6
@@ -1,6 +1,6 @@
Name: perl-XML-Filter-XInclude
Version:1.0
-Release:5%{?dist}
+Release:6%{?dist}
Summary:XInclude as a SAX Filter
License:GPL+ or Artistic
Group: Development/Libraries
@@ -46,6 +46,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Fri May 07 2010 Marcela Maslanova - 1.0-6
+- Mass rebuild with perl-5.12.0
+
* Mon Dec 7 2009 Stepan Kasal - 1.0-5
- rebuild against perl 5.10.1
--
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: Reasons for hall monitoring
Dne 7.5.2010 01:01, Rudolf Kastl napsal(a): > one of the questions raised in the meeting posted by mcepl was... "why > dont those people leave if they are unhappy". simple... they put alot > sweat blood and tears into a project, and they have friends... with > the development crowd and with the community in general. they are > obviously feeling as a part of it with just a different pov and an own > opinion. that isnt bad at all ... but healthy... "diversity is > healthy" to a project. I didn't to continue in this thread, but here I have to defend myself. I don't remember I would say anything like that, but it looks to me like taken out of the context at least and expressing exactly opposite position I think I held. Although I don't agree with many of them in a lot of places, I strongly support Kevin's, Ralf's and others position that the current development is very harmful to the development of Fedora and I would love them to stay and defend this still nice project we all work on. Actually, http://skvidal.wordpress.com/2010/05/07/dissidents/ made me so angry that I am just not able to write any response to it ... whatever I would write would be too much personal half-libelous attack, so I will rather write nothing. Matěj -- According to the Franciscan priest Richard Rohr, spirituality is not for people who are trying to avoid hell; it is for people who have been through hell. In many ways, spirituality is about what we do with our pain. And the truth is, if we don't transform it, we will transmit it. -- Al Gustafson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File DateTime-Format-Flexible-0.15.tar.gz uploaded to lookaside cache by mmaslano
A file has been added to the lookaside cache for perl-DateTime-Format-Flexible: 4869f7f1fbef588d5c778e0b345e3742 DateTime-Format-Flexible-0.15.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: Reasons for hall monitoring
Burying the underlying issue yet again under the carpet or "Hall monitoring" it wont resolve it neither will a shouting contest between people do. People will need leave all emotion behind and look neutrally at each other point of view and listen to each other constructive criticism to gradually build up and achieve a compromised solution between themselves and all parties involved. Everyone knows the underlying issue that dissatisfies so many of the community ( otherwise Kevin would never been elected to FESCo ) and to resolve that issue the board needs to step back and look at the project in whole, it's members, where it is and where it wants it to be and coming up with a clear cut vision of what the project is going to achieve and who they are trying to attract while achieving that goal. As long as the project vision remains clouded and is sending out mixed signals the underlying issue will never be resolved and will leave contributors stuck in a Groundhog day unable to move on either within this project or to another one and the same issue will continue to re-surface release cycle after release cycle gradually increasing the disruption and the rift in the community. JBG <>-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-XML-Simple-DTDReader/devel perl-XML-Simple-DTDReader.spec, 1.3, 1.4
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-XML-Simple-DTDReader/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv6034
Modified Files:
perl-XML-Simple-DTDReader.spec
Log Message:
- Mass rebuild with perl-5.12.0
Index: perl-XML-Simple-DTDReader.spec
===
RCS file:
/cvs/pkgs/rpms/perl-XML-Simple-DTDReader/devel/perl-XML-Simple-DTDReader.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- perl-XML-Simple-DTDReader.spec 7 Dec 2009 04:51:18 - 1.3
+++ perl-XML-Simple-DTDReader.spec 7 May 2010 13:29:00 - 1.4
@@ -1,6 +1,6 @@
Name: perl-XML-Simple-DTDReader
Version:0.04
-Release:5%{?dist}
+Release:6%{?dist}
Summary:Simple XML file reading based on their DTDs
License:GPL+ or Artistic
Group: Development/Libraries
@@ -48,6 +48,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri May 07 2010 Marcela Maslanova - 0.04-6
+- Mass rebuild with perl-5.12.0
+
* Mon Dec 7 2009 Stepan Kasal - 0.04-5
- rebuild against perl 5.10.1
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-DateTime-Format-Natural/devel perl-DateTime-Format-Natural.spec, 1.18, 1.19
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-DateTime-Format-Natural/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv6372
Modified Files:
perl-DateTime-Format-Natural.spec
Log Message:
* Fri Apr 30 2010 Marcela Maslanova - 0.86-2
- Mass rebuild with perl-5.12.0
Index: perl-DateTime-Format-Natural.spec
===
RCS file:
/cvs/pkgs/rpms/perl-DateTime-Format-Natural/devel/perl-DateTime-Format-Natural.spec,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -p -r1.18 -r1.19
--- perl-DateTime-Format-Natural.spec 30 Apr 2010 13:58:36 - 1.18
+++ perl-DateTime-Format-Natural.spec 7 May 2010 13:30:56 - 1.19
@@ -9,6 +9,7 @@ Source0:http://www.cpan.org/auth
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(boolean)
+BuildRequires: perl(Class::ISA)
BuildRequires: perl(Date::Calc)
BuildRequires: perl(DateTime)
BuildRequires: perl(List::MoreUtils)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-DateTime-Format-Oracle/devel perl-DateTime-Format-Oracle.spec, 1.8, 1.9
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-DateTime-Format-Oracle/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv6616
Modified Files:
perl-DateTime-Format-Oracle.spec
Log Message:
* Fri Apr 30 2010 Marcela Maslanova - 0.05-5
- Mass rebuild with perl-5.12.0
Index: perl-DateTime-Format-Oracle.spec
===
RCS file:
/cvs/pkgs/rpms/perl-DateTime-Format-Oracle/devel/perl-DateTime-Format-Oracle.spec,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -p -r1.8 -r1.9
--- perl-DateTime-Format-Oracle.spec30 Apr 2010 13:59:16 - 1.8
+++ perl-DateTime-Format-Oracle.spec7 May 2010 13:33:21 - 1.9
@@ -10,6 +10,7 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+BuildRequires: perl(Class::ISA)
BuildRequires: perl(Convert::NLS_DATE_FORMAT)
BuildRequires: perl(DateTime)
BuildRequires: perl(DateTime::Format::Builder)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-DateTime-Format-Pg/devel perl-DateTime-Format-Pg.spec, 1.8, 1.9
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-DateTime-Format-Pg/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv6955
Modified Files:
perl-DateTime-Format-Pg.spec
Log Message:
* Fri Apr 30 2010 Marcela Maslanova - 0.16004-3
- Mass rebuild with perl-5.12.0
Index: perl-DateTime-Format-Pg.spec
===
RCS file:
/cvs/pkgs/rpms/perl-DateTime-Format-Pg/devel/perl-DateTime-Format-Pg.spec,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -p -r1.8 -r1.9
--- perl-DateTime-Format-Pg.spec30 Apr 2010 13:59:55 - 1.8
+++ perl-DateTime-Format-Pg.spec7 May 2010 13:35:12 - 1.9
@@ -10,6 +10,7 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+BuildRequires: perl(Class::ISA)
BuildRequires: perl(DateTime) >= 0.10
BuildRequires: perl(DateTime::Format::Builder) >= 0.72
BuildRequires: perl(DateTime::TimeZone)>= 0.05
--
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: GConf error
On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves wrote: > > Would it be allowed to try to restart gconfd ? It would make sense to SIGHUP gconfd after new schemas are installed, yes. Note though we should really only be doing this once at the end of a transaction when installation is complete. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-XML-Stream/devel perl-XML-Stream.spec,1.10,1.11
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-XML-Stream/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv7413
Modified Files:
perl-XML-Stream.spec
Log Message:
- Mass rebuild with perl-5.12.0
Index: perl-XML-Stream.spec
===
RCS file: /cvs/pkgs/rpms/perl-XML-Stream/devel/perl-XML-Stream.spec,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -p -r1.10 -r1.11
--- perl-XML-Stream.spec7 Dec 2009 04:36:49 - 1.10
+++ perl-XML-Stream.spec7 May 2010 13:39:42 - 1.11
@@ -1,6 +1,6 @@
Name: perl-XML-Stream
Version:1.22
-Release:12%{?dist}
+Release:13%{?dist}
Summary:XML::Stream - streaming XML library
Group: Development/Libraries
@@ -83,6 +83,9 @@ rm -rf %{buildroot}
%changelog
+* Fri May 07 2010 Marcela Maslanova - 1.22-13
+- Mass rebuild with perl-5.12.0
+
* Mon Dec 7 2009 Stepan Kasal - 1.22-12
- rebuild against perl 5.10.1
--
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
cpio: File name too long?
A recently built sbcl-1.0.38 won't install: error: unpacking of archive failed on file /usr/share/doc/sbcl-1.0.38/sbcl/Method- sb_002dbsd_002dsockets_003asocket_002dmake_002dstream-_0028_0028socket- socket_0029-_0026key-input-output-_0028element_002dtype-_0027character_0029- _0028buffering-full_0029-_0028external_002dformat-default_0029-timeout- auto_002dclose_0029.html;4be416e1: cpio: open failed - File name too long Seems this file grew in length a bit since the last build. Any suggested fixes? (other than whacking whatever created the crazy overly long filename)? -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File DateTime-Format-Strptime-1.2000.tar.gz uploaded to lookaside cache by mmaslano
A file has been added to the lookaside cache for perl-DateTime-Format-Strptime: 8e0218294f983629cf781990ed61f3ba DateTime-Format-Strptime-1.2000.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-DateTime-Format-Strptime/devel .cvsignore, 1.5, 1.6 perl-DateTime-Format-Strptime.spec, 1.12, 1.13 sources, 1.5, 1.6
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-DateTime-Format-Strptime/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv7971
Modified Files:
.cvsignore perl-DateTime-Format-Strptime.spec sources
Log Message:
* Fri Apr 30 2010 Marcela Maslanova - 1.1000-2
- Mass rebuild with perl-5.12.0
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-DateTime-Format-Strptime/devel/.cvsignore,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- .cvsignore 16 Feb 2010 08:13:56 - 1.5
+++ .cvsignore 7 May 2010 13:43:31 - 1.6
@@ -1 +1 @@
-DateTime-Format-Strptime-1.1000.tgz
+DateTime-Format-Strptime-1.2000.tar.gz
Index: perl-DateTime-Format-Strptime.spec
===
RCS file:
/cvs/pkgs/rpms/perl-DateTime-Format-Strptime/devel/perl-DateTime-Format-Strptime.spec,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -p -r1.12 -r1.13
--- perl-DateTime-Format-Strptime.spec 30 Apr 2010 14:01:25 - 1.12
+++ perl-DateTime-Format-Strptime.spec 7 May 2010 13:43:31 - 1.13
@@ -1,11 +1,11 @@
Name: perl-DateTime-Format-Strptime
-Version:1.1000
-Release:2%{?dist}
+Version:1.2000
+Release:1%{?dist}
Summary:Parse and format strp and strf time patterns
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/DateTime-Format-Strptime/
-Source0:
http://www.cpan.org/authors/id/R/RI/RICKM/DateTime-Format-Strptime-%{version}.tgz
+Source0:
http://www.cpan.org/authors/id/R/RI/RICKM/DateTime-Format-Strptime-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(DateTime) >= 0.44
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-DateTime-Format-Strptime/devel/sources,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- sources 16 Feb 2010 08:13:56 - 1.5
+++ sources 7 May 2010 13:43:31 - 1.6
@@ -1 +1 @@
-bf7f6b219e34411aa3f5d0de56fda393 DateTime-Format-Strptime-1.1000.tgz
+8e0218294f983629cf781990ed61f3ba DateTime-Format-Strptime-1.2000.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
File DateTimeX-Easy-0.088.tar.gz uploaded to lookaside cache by mmaslano
A file has been added to the lookaside cache for perl-DateTimeX-Easy: 62b3fde502e99d00b2a4001b3b299719 DateTimeX-Easy-0.088.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-DateTimeX-Easy/devel .cvsignore, 1.3, 1.4 perl-DateTimeX-Easy.spec, 1.7, 1.8 sources, 1.3, 1.4
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-DateTimeX-Easy/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv8800
Modified Files:
.cvsignore perl-DateTimeX-Easy.spec sources
Log Message:
* Fri Apr 30 2010 Marcela Maslanova - 0.087-5
- Mass rebuild with perl-5.12.0
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-DateTimeX-Easy/devel/.cvsignore,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- .cvsignore 19 May 2009 02:45:44 - 1.3
+++ .cvsignore 7 May 2010 13:47:48 - 1.4
@@ -1 +1 @@
-DateTimeX-Easy-0.087.tar.gz
+DateTimeX-Easy-0.088.tar.gz
Index: perl-DateTimeX-Easy.spec
===
RCS file: /cvs/pkgs/rpms/perl-DateTimeX-Easy/devel/perl-DateTimeX-Easy.spec,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- perl-DateTimeX-Easy.spec30 Apr 2010 14:04:27 - 1.7
+++ perl-DateTimeX-Easy.spec7 May 2010 13:47:48 - 1.8
@@ -1,6 +1,6 @@
Name: perl-DateTimeX-Easy
-Version:0.087
-Release:5%{?dist}
+Version:0.088
+Release:1%{?dist}
# see lib/DateTimeX/Easy.pm
License:GPL+ or Artistic
Group: Development/Libraries
@@ -11,6 +11,7 @@ BuildRoot: %{_tmppath}/%{name}-%{versio
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
BuildArch: noarch
+BuildRequires: perl(Class::ISAA)
BuildRequires: perl(ExtUtils::MakeMaker) >= 6.42
BuildRequires: perl(DateTime)
BuildRequires: perl(DateTime::Format::DateParse)
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-DateTimeX-Easy/devel/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 19 May 2009 02:45:44 - 1.3
+++ sources 7 May 2010 13:47:48 - 1.4
@@ -1 +1 @@
-231ff4345ff5f7a3092bfdc19c374d51 DateTimeX-Easy-0.087.tar.gz
+62b3fde502e99d00b2a4001b3b299719 DateTimeX-Easy-0.088.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-DateTime-Format-Mail/devel perl-DateTime-Format-Mail.spec, 1.11, 1.12
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-DateTime-Format-Mail/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv5820
Modified Files:
perl-DateTime-Format-Mail.spec
Log Message:
* Fri Apr 30 2010 Marcela Maslanova - 0.3001-7
- Mass rebuild with perl-5.12.0
Index: perl-DateTime-Format-Mail.spec
===
RCS file:
/cvs/pkgs/rpms/perl-DateTime-Format-Mail/devel/perl-DateTime-Format-Mail.spec,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -p -r1.11 -r1.12
--- perl-DateTime-Format-Mail.spec 30 Apr 2010 13:57:16 - 1.11
+++ perl-DateTime-Format-Mail.spec 7 May 2010 13:25:43 - 1.12
@@ -10,7 +10,7 @@ Source0: http://search.cpan.org/CPAN/aut
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
-BuildRequires: perl
+BuildRequires: perl(Class::ISA)
BuildRequires: perl(Module::Build), perl(DateTime)
BuildRequires: perl(Params::Validate) >= 0.67, perl(Test::More) >= 0.47
BuildRequires: perl(File::Find::Rule)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-XML-SAX-Writer/devel perl-XML-SAX-Writer.spec,1.7,1.8
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-XML-SAX-Writer/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv3745
Modified Files:
perl-XML-SAX-Writer.spec
Log Message:
- Mass rebuild with perl-5.12.0
Index: perl-XML-SAX-Writer.spec
===
RCS file: /cvs/pkgs/rpms/perl-XML-SAX-Writer/devel/perl-XML-SAX-Writer.spec,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- perl-XML-SAX-Writer.spec7 Dec 2009 05:00:15 - 1.7
+++ perl-XML-SAX-Writer.spec7 May 2010 13:17:16 - 1.8
@@ -1,6 +1,6 @@
Name: perl-XML-SAX-Writer
Version:0.50
-Release:8%{?dist}
+Release:9%{?dist}
Summary:SAX2 Writer
License:GPL+ or Artistic
Group: Development/Libraries
@@ -54,6 +54,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Fri May 07 2010 Marcela Maslanova - 0.50-9
+- Mass rebuild with perl-5.12.0
+
* Mon Dec 7 2009 Stepan Kasal - 0.50-8
- rebuild against perl 5.10.1
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-DateTime-Format-SQLite/devel perl-DateTime-Format-SQLite.spec, 1.6, 1.7
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-DateTime-Format-SQLite/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv9484
Modified Files:
perl-DateTime-Format-SQLite.spec
Log Message:
* Fri Apr 30 2010 Marcela Maslanova - 0.11-2
- Mass rebuild with perl-5.12.0
Index: perl-DateTime-Format-SQLite.spec
===
RCS file:
/cvs/pkgs/rpms/perl-DateTime-Format-SQLite/devel/perl-DateTime-Format-SQLite.spec,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -p -r1.6 -r1.7
--- perl-DateTime-Format-SQLite.spec30 Apr 2010 14:00:44 - 1.6
+++ perl-DateTime-Format-SQLite.spec7 May 2010 13:50:50 - 1.7
@@ -10,6 +10,7 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+BuildRequires: perl(Class::ISA)
BuildRequires: perl(DateTime) >= 0.1
BuildRequires: perl(DateTime::Format::Builder) >= 0.6
BuildRequires: perl(ExtUtils::MakeMaker)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-XML-TokeParser/devel perl-XML-TokeParser.spec,1.3,1.4
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-XML-TokeParser/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv9753
Modified Files:
perl-XML-TokeParser.spec
Log Message:
- Mass rebuild with perl-5.12.0
Index: perl-XML-TokeParser.spec
===
RCS file: /cvs/pkgs/rpms/perl-XML-TokeParser/devel/perl-XML-TokeParser.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- perl-XML-TokeParser.spec7 Dec 2009 04:27:52 - 1.3
+++ perl-XML-TokeParser.spec7 May 2010 13:51:41 - 1.4
@@ -1,6 +1,6 @@
Name: perl-XML-TokeParser
Version:0.05
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Simplified interface to XML::Parser
License:GPL+ or Artistic
Group: Development/Libraries
@@ -50,6 +50,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri May 07 2010 Marcela Maslanova - 0.05-4
+- Mass rebuild with perl-5.12.0
+
* Mon Dec 7 2009 Stepan Kasal - 0.05-3
- rebuild against perl 5.10.1
--
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: Reasons for hall monitoring
On 05/06/2010 07:28 PM, Jeff Spaleta wrote: > On Thu, May 6, 2010 at 3:01 PM, Rudolf Kastl wrote: > >> one of the questions raised in the meeting posted by mcepl was... "why >> dont those people leave if they are unhappy". simple... they put alot >> sweat blood and tears into a project, and they have friends... with >> the development crowd and with the community in general. they are >> obviously feeling as a part of it with just a different pov and an own >> opinion. that isnt bad at all ... but healthy... "diversity is >> healthy" to a project. >> > > Constructive... additive ...diversity in opinion is healthy. But > there is a line at which debate can turn unhealthy and destructive... > when repetitive discussion becomes shrill in its desire to be > informative...becomes over reaching in its need to be persuasive. > Unfortunately what we have seen lately is a somewhat self propogating > cycle that we repeat when issues are multi-faceted. > > People who have taken their shot at making a persuasive argument to > change the minds of a particular audience can feel like they are being > ignored when their arguments end up not being persuasive. Ratcheting > up the heat( and number of capitalized words) in the next opportunity > to restate their arguments brings more attention from others who have > not noticed previous rounds in the discussion but in fact make the > original audience more likely to tune out what is being said. And the > cycle repeats spiralling downward towards a CapsLock doomsday as the > participants become more entrenched in their points of view and less > forgiving of other people's. Personal foibles and slights both real > and imagined pile up into a palatable physiological barrier and people > just end up talking at each other. > > Totally off-topic, but I think "Spiralling Downward Towards a CapsLock Doomsday" would be a fantastic band name. -J > For the sake of everyone's sanity we have to find a way out of this > cycle. Letting these sorts of fires burn out on their own doesn't > seem like the best way to manage our communication commons. And yes > I'm throwing stones while standing in my own glass house, I can be > sucked into bad behavior as easily as anyone else and being told I'm > beating a dead horse is the appropriate thing to do. > > > -jef"It's seldom going to end well when one of the most active > participants in any thread proclaims at the start that they are burned > out on the issues. It's difficult to see how one can simultaneously be > burned-out as well as a constructive voice on the issues. Passion can > fight against effectiveness"spaleta > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Fri, 7 May 2010, Jon Ciesla wrote: >> >> > Totally off-topic, but I think "Spiralling Downward Towards a CapsLock > Doomsday" would be a fantastic band name. > Or possibly a Cory Doctrow book. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On 05/07/2010 08:56 AM, Seth Vidal wrote: > > On Fri, 7 May 2010, Jon Ciesla wrote: > >>> >>> >> Totally off-topic, but I think "Spiralling Downward Towards a CapsLock >> Doomsday" would be a fantastic band name. >> >> > Or possibly a Cory Doctrow book. > > -sv > > That totally skipped my mind. That would be much better. I'd totally read that book, because I can imagine where he'd take the concept. CCing same. :) -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
2010/5/7 "Jóhann B. Guðmundsson" : > Burying the underlying issue yet again under the carpet or "Hall monitoring" > it wont resolve it neither will a shouting contest between people do. People > will need leave all emotion behind and look neutrally at each other point of > view and listen to each other constructive criticism to gradually build up > and achieve a compromised solution between themselves and all parties > involved. > > Everyone knows the underlying issue that dissatisfies so many of the > community ( otherwise Kevin would never been elected to FESCo ) and to > resolve that issue the board needs to step back and look at the project in > whole, it's members, where it is and where it wants it to be and coming up > with a clear cut vision of what the project is going to achieve and who they > are trying to attract while achieving that goal. > > As long as the project vision remains clouded and is sending out mixed > signals the underlying issue will never be resolved and will leave > contributors stuck in a Groundhog day unable to move on either within this > project or to another one and the same issue will continue to re-surface > release cycle after release cycle gradually increasing the disruption and > the rift in the community. It's quite easy. First of all there's obviously the need for a poll what our users really want. Since a lot people think our users want another openSUSE/Ubuntu, why not find out what they really want in the first place. Make a scientific poll. I have to say scientific since the last thread showed that the ones who want to change Fedora completely away from what it is, don't believe a non-scientific poll. Speaking of the handful of people who want another openSUSE/Ubuntu. Have they ever thought about how many downloads Fedora has? That Fedora is since a long time with "adventurous" updates? That Fedora grows from users *not* satisfied with exactly the system where they want it to be? I can say that because i'm one of them. If my former distro would have been that close to the edge (getting the latest and greatest KDE in released versions) like Fedora is (was that time) i wouldn't have changed to Fedora. The blue color and a fancy hat is no reason at all. The best thing that happened lately, was the plan to test updates better to prevent bad breakage. Of course it wont catch any bug. But it is obviously needed. And i don't say it's because of some bad dissidents break it (really a horribly blog post Seth), but it's because of we're all just humans and stuff happens. So if we can find at least the real show stopper before they get out as updates, we're close to perfect. So FAB, if you want to do something, do it right. Check out why our users use Fedora. For sure not because they search for another distro already on the market. And if this is no democracy, then don't speak of visions, don't confuse our contributors, then speak as expected from you. I hope one or the other might get something positiv out of this post. People who laugh about it, i'm glad that i at least made your day. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On 05/07/2010 08:48 AM, Matěj Cepl wrote: > Although I don't agree with many of them in a > lot of places, I strongly support Kevin's, Ralf's and others position > that the current development is very harmful to the development of > Fedora and I would love them to stay and defend this still nice project > we all work on. Here's the rub, though: Kevin argues for aggressive development and empowering the package maintainers to push out changes, even if it resulted in temporary regressions. Ralf, on the other hand, reminds us about the need for quality control, process and stability. They can't both be right---but the entire project is better off for them voicing their opinions. There's a lot of research in social psychology suggesting that large groups engaged in transparent and open discussion make better decisions, statistically speaking, so a broad discussion exploring the entire spectrum of opinions is exactly what we need. We just can't let it become personal and acrimonious. This is an obligation for everyone to take the 'extreme' voices at face value: assume good faith, which, by the way, is a great life principle in most circumstances. It is also an obligation on those who take an unpopular view: voice it to the best of your ability but don't take it personally if your argument doesn't take the day. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-YAML-Parser-Syck/devel perl-YAML-Parser-Syck.spec, 1.11, 1.12
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-YAML-Parser-Syck/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv20116
Modified Files:
perl-YAML-Parser-Syck.spec
Log Message:
- Mass rebuild with perl-5.12.0
Index: perl-YAML-Parser-Syck.spec
===
RCS file:
/cvs/pkgs/rpms/perl-YAML-Parser-Syck/devel/perl-YAML-Parser-Syck.spec,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -p -r1.11 -r1.12
--- perl-YAML-Parser-Syck.spec 7 Dec 2009 03:31:41 - 1.11
+++ perl-YAML-Parser-Syck.spec 7 May 2010 14:58:54 - 1.12
@@ -1,6 +1,6 @@
Name: perl-YAML-Parser-Syck
Version:0.01
-Release:14%{?dist}
+Release:15%{?dist}
Summary:Perl Wrapper for the YAML Parser Extension: libsyck
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri May 07 2010 Marcela Maslanova - 0.01-15
+- Mass rebuild with perl-5.12.0
+
* Mon Dec 7 2009 Stepan Kasal - 0.01-14
- rebuild against perl 5.10.1
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-YAML-Syck/devel perl-YAML-Syck.spec,1.20,1.21
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-YAML-Syck/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv20687
Modified Files:
perl-YAML-Syck.spec
Log Message:
- Mass rebuild with perl-5.12.0
Index: perl-YAML-Syck.spec
===
RCS file: /cvs/pkgs/rpms/perl-YAML-Syck/devel/perl-YAML-Syck.spec,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -p -r1.20 -r1.21
--- perl-YAML-Syck.spec 7 Dec 2009 03:25:43 - 1.20
+++ perl-YAML-Syck.spec 7 May 2010 15:04:24 - 1.21
@@ -1,6 +1,6 @@
Name: perl-YAML-Syck
Version:1.07
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Fast, lightweight YAML loader and dumper
License:BSD and MIT
Group: Development/Libraries
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri May 07 2010 Marcela Maslanova - 1.07-4
+- Mass rebuild with perl-5.12.0
+
* Mon Dec 7 2009 Stepan Kasal - 1.07-3
- rebuild against perl 5.10.1
--
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: cpio: File name too long?
On Fri, 2010-05-07 at 08:42 -0500, Rex Dieter wrote: > A recently built sbcl-1.0.38 won't install: > > error: unpacking of archive failed on file > /usr/share/doc/sbcl-1.0.38/sbcl/Method- > sb_002dbsd_002dsockets_003asocket_002dmake_002dstream-_0028_0028socket- > socket_0029-_0026key-input-output-_0028element_002dtype-_0027character_0029- > _0028buffering-full_0029-_0028external_002dformat-default_0029-timeout- > auto_002dclose_0029.html;4be416e1: cpio: open failed - File name too long > > Seems this file grew in length a bit since the last build. Any suggested > fixes? (other than whacking whatever created the crazy overly long > filename)? I see. The original filename was 249 characters (so it was possible to create the file in the first place for addition to the RPM), but after addition of the temporary suffix, it exceeds NAME_MAX at 258 characters. cpio could be changed to snip some characters in this case like gzip does. However, I agree that the process that created that file ought to be whacked. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Test-Script/devel perl-Test-Script.spec,1.10,1.11
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-Test-Script/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv21241
Modified Files:
perl-Test-Script.spec
Log Message:
* Fri May 07 2010 Marcela Maslanova - 1.07-2
- Mass rebuild with perl-5.12.0
Index: perl-Test-Script.spec
===
RCS file: /cvs/pkgs/rpms/perl-Test-Script/devel/perl-Test-Script.spec,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -p -r1.10 -r1.11
--- perl-Test-Script.spec 6 May 2010 22:53:21 - 1.10
+++ perl-Test-Script.spec 7 May 2010 15:10:30 - 1.11
@@ -44,6 +44,8 @@ find $RPM_BUILD_ROOT -depth -type d -exe
%{_fixperms} $RPM_BUILD_ROOT/*
%check
+# remove until fix of Perl::MinimalVersion and version.pm
+rm -rf t/99_pmv.t
make test AUTOMATED_TESTING=1 RELEASE_TESTING=1
%clean
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-YAML-Tiny/devel perl-YAML-Tiny.spec,1.15,1.16
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-YAML-Tiny/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv21328
Modified Files:
perl-YAML-Tiny.spec
Log Message:
- Mass rebuild with perl-5.12.0
Index: perl-YAML-Tiny.spec
===
RCS file: /cvs/pkgs/rpms/perl-YAML-Tiny/devel/perl-YAML-Tiny.spec,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -p -r1.15 -r1.16
--- perl-YAML-Tiny.spec 7 Dec 2009 03:21:33 - 1.15
+++ perl-YAML-Tiny.spec 7 May 2010 15:10:55 - 1.16
@@ -1,6 +1,6 @@
Name: perl-YAML-Tiny
Version:1.40
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Read/Write YAML files with as little code as possible
License:GPL+ or Artistic
Group: Development/Libraries
@@ -54,6 +54,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri May 07 2010 Marcela Maslanova - 1.40-3
+- Mass rebuild with perl-5.12.0
+
* Mon Dec 7 2009 Stepan Kasal - 1.40-2
- rebuild against perl 5.10.1
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Test-Strict/devel perl-Test-Strict.spec,1.7,1.8
Author: mmaslano Update of /cvs/pkgs/rpms/perl-Test-Strict/devel In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv21779 Modified Files: perl-Test-Strict.spec Log Message: * Fri May 07 2010 Marcela Maslanova - 0.13-5 - Mass rebuild with perl-5.12.0 Index: perl-Test-Strict.spec === RCS file: /cvs/pkgs/rpms/perl-Test-Strict/devel/perl-Test-Strict.spec,v retrieving revision 1.7 retrieving revision 1.8 diff -u -p -r1.7 -r1.8 --- perl-Test-Strict.spec 6 May 2010 23:13:56 - 1.7 +++ perl-Test-Strict.spec 7 May 2010 15:13:45 - 1.8 @@ -20,6 +20,7 @@ BuildRequires: perl(FindBin) >= 0.01 BuildRequires: perl(Test::Builder) >= 0.01 BuildRequires: perl(Test::Simple) >= 0.47 BuildRequires: perl(Test::More) +BuildRequires: perl(Test::Pod) %description "Test::Strict" lets you check the syntax, presence of "use strict;" and -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Test-Class/devel perl-Test-Class.spec,1.10,1.11
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-Test-Class/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv22539
Modified Files:
perl-Test-Class.spec
Log Message:
* Thu May 06 2010 Marcela Maslanova - 0.33-3
- Mass rebuild with perl-5.12.0
Index: perl-Test-Class.spec
===
RCS file: /cvs/pkgs/rpms/perl-Test-Class/devel/perl-Test-Class.spec,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -p -r1.10 -r1.11
--- perl-Test-Class.spec6 May 2010 19:32:45 - 1.10
+++ perl-Test-Class.spec7 May 2010 15:19:32 - 1.11
@@ -8,6 +8,7 @@ URL:http://search.cpan.org/d
Source0:
http://www.cpan.org/authors/id/A/AD/ADAMK/Test-Class-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
+BuildRequires: perl(Class::ISA)
BuildRequires: perl(Contextual::Return)
BuildRequires: perl(Devel::Symdump) >= 2.03
BuildRequires: perl(Module::Build)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Template-Provider-Encoding/devel perl-Template-Provider-Encoding.spec, 1.6, 1.7
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-Template-Provider-Encoding/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv22836
Modified Files:
perl-Template-Provider-Encoding.spec
Log Message:
* Thu May 06 2010 Marcela Maslanova - 0.10-6
- Mass rebuild with perl-5.12.0
Index: perl-Template-Provider-Encoding.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Template-Provider-Encoding/devel/perl-Template-Provider-Encoding.spec,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -p -r1.6 -r1.7
--- perl-Template-Provider-Encoding.spec6 May 2010 17:56:44 -
1.6
+++ perl-Template-Provider-Encoding.spec7 May 2010 15:21:38 -
1.7
@@ -10,6 +10,7 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+BuildRequires: perl(Class::ISA)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Encode)>= 1.00
BuildRequires: perl(Template) >= 2.1
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Test-ClassAPI/devel perl-Test-ClassAPI.spec,1.17,1.18
Author: mmaslano Update of /cvs/pkgs/rpms/perl-Test-ClassAPI/devel In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv23254 Modified Files: perl-Test-ClassAPI.spec Log Message: * Thu May 06 2010 Marcela Maslanova - 1.06-4 - Mass rebuild with perl-5.12.0 Index: perl-Test-ClassAPI.spec === RCS file: /cvs/pkgs/rpms/perl-Test-ClassAPI/devel/perl-Test-ClassAPI.spec,v retrieving revision 1.17 retrieving revision 1.18 diff -u -p -r1.17 -r1.18 --- perl-Test-ClassAPI.spec 6 May 2010 19:37:07 - 1.17 +++ perl-Test-ClassAPI.spec 7 May 2010 15:24:03 - 1.18 @@ -51,6 +51,8 @@ find $RPM_BUILD_ROOT -type d -depth -exe chmod -R u+w $RPM_BUILD_ROOT/* %clean +# remove until fix of Perl::MinimalVersion and version.pm +rm -rf t/99_pmv.t rm -rf $RPM_BUILD_ROOT %check -- 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: Reasons for hall monitoring
On Fri, 2010-05-07 at 10:56 -0400, Przemek Klosowski wrote: > On 05/07/2010 08:48 AM, Matěj Cepl wrote: > > Although I don't agree with many of them in a > > lot of places, I strongly support Kevin's, Ralf's and others position > > that the current development is very harmful to the development of > > Fedora and I would love them to stay and defend this still nice project > > we all work on. > > Here's the rub, though: Kevin argues for aggressive development and > empowering the package maintainers to push out changes, even if it > resulted in temporary regressions. Ralf, on the other hand, reminds us > about the need for quality control, process and stability. They can't > both be right---but the entire project is better off for them voicing > their opinions. (Note to non-native English speakers, and native speakers for that matter: I'm using "you" in the second person plural here. I am not addressing Przemek, or anyone else, specifically.) Be very very careful with that last bit. Voicing your opinion is a right you have. But it's not the case that the project is always better off if you do so. There are poisonous ideas, and poisonous behaviours, and yours might be one of them. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, May 07, 2010 at 09:38:45AM -0400, Colin Walters wrote: > On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves wrote: > > > > Would it be allowed to try to restart gconfd ? > > It would make sense to SIGHUP gconfd after new schemas are installed, > yes. Note though we should really only be doing this once at the end > of a transaction when installation is complete. > My understanding was that with current Fedoras, gconf doesn't need this but I could be misremembering, missing a corner case, or just wrong :-) What are the cases that we need to still send a sighup to gconf? (or is this a workaround for an undiagnosed bug in the guake gconf schema?) We can't do this only once at the end of a transaction but if I'm remembering a different discussion, doing it multiple times at the end of the rpm transaction should be almost as good (since gconf will wait for a few moments from getting the first SIGHUP to see if it will get any other ones.) Is that correct? -Toshio pgpMfzXzRSJcL.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Some more Python 3: (was Re: rawhide report: 20100507 changes)
On Fri, 2010-05-07 at 12:25 +, Rawhide Report wrote: Three more python 3 subpackages in today's "rawhide" heading for F14 - I've gone ahead and added these to the wiki here: https://fedoraproject.org/wiki/Features/Python3F13#Python_3_already_in_Fedora Are we missing anything? [snip] > libsemanage-2.0.45-4.fc14 > - > * Tue Apr 27 2010 David Malcolm - 2.0.45-4 > - add python3 subpackage [snip] > python-beaker-1.5.3-2.fc14 > -- > * Thu May 06 2010 Luke Macken - 1.5.3-2 > - Add a python3 subpackage > > > python-mako-0.3.2-2.fc14 > > * Tue May 04 2010 David Malcolm - 0.3.2-2 > - add python3 subpackage [snip] ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: GConf error
On Fri, May 7, 2010 at 12:05 PM, Toshio Kuratomi wrote: > On Fri, May 07, 2010 at 09:38:45AM -0400, Colin Walters wrote: >> On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves wrote: >> > >> > Would it be allowed to try to restart gconfd ? >> >> It would make sense to SIGHUP gconfd after new schemas are installed, >> yes. Note though we should really only be doing this once at the end >> of a transaction when installation is complete. >> > My understanding was that with current Fedoras, gconf doesn't need this but > I could be misremembering, missing a corner case, or just wrong :-) [walt...@pocket gconf (master)]$ git grep inotify [walt...@pocket gconf (master)]$ git grep g_file_monitor [walt...@pocket gconf (master)]$ So... > We can't do this only once at the end of a transaction but if I'm > remembering a different discussion, doing it multiple times at the end > of the rpm transaction should be almost as good (since gconf will wait for > a few moments from getting the first SIGHUP to see if it will get any other > ones.) Is that correct? It has a 30 second timer currently for "periodic cleanup", and SIGHUP just sets a flag that that function reads. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, 2010-05-07 at 09:38 -0400, Colin Walters wrote: > On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves wrote: > > > > Would it be allowed to try to restart gconfd ? > > It would make sense to SIGHUP gconfd after new schemas are installed, > yes. Note though we should really only be doing this once at the end > of a transaction when installation is complete. Thanks for your help, I will update the spec to do this. Would you have any advice/example on what would be the best way to do it ? Do you think it should be done on %postun as well ? Pirre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
new qt-webkit-devel
In anticipation of nokia's plans to ship a separate qtwebkit, we've split this out into separate packaging in rawhide's qt-4.7.0-0.10 (and newer) qt-webkit qt-webkit-devel So, if you have a package that needs this at build time, you will now need to use (preferably): BuildRequires: qt4-webkit-devel or BuildRequires: qt-webkit-devel To ease migration, I also added similar Provides: to qt-4.6.2-18+ builds for previous releases, which will be issued as updates at earliest prudence. -- Rex ___ 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: Could someone, please, clarify situation with *-javadoc
> "PL" == Peter Lemenkov writes: PL> Sometimes *-javadoc sub-packages explicitly requires main PL> package, and sometimes - not. I'm not a java-expert, so I don't know PL> which is correct. Java guidelines have come up recently on the packaging list. The templates in the Java packaging guidelines all show the javadoc package with a dependency on the main package. Otherwise, this is not addressed in the guidelines. I would follow the templates, although I will try to get this addressed with the next guideline revision. - J< -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, May 07, 2010 at 12:15:20PM -0400, Colin Walters wrote: > On Fri, May 7, 2010 at 12:05 PM, Toshio Kuratomi wrote: > > On Fri, May 07, 2010 at 09:38:45AM -0400, Colin Walters wrote: > >> On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves wrote: > >> > > >> > Would it be allowed to try to restart gconfd ? > >> > >> It would make sense to SIGHUP gconfd after new schemas are installed, > >> yes. Note though we should really only be doing this once at the end > >> of a transaction when installation is complete. > >> > > My understanding was that with current Fedoras, gconf doesn't need this but > > I could be misremembering, missing a corner case, or just wrong :-) > > [walt...@pocket gconf (master)]$ git grep inotify > [walt...@pocket gconf (master)]$ git grep g_file_monitor > [walt...@pocket gconf (master)]$ > > So... > It's in gconftool.c: Running makefile-install-schema and makefile-uninstall-schema eventually calls do_sync() which was supposed to reread the schemas. That's currently calling gconf_engine_suggest_sync() in gconf.c and I'm not sure whether there's some logic in there that could cause it not to suggest syncing in our current setup. Here's our bug where it was implemented but the code has changed since then: https://bugzilla.redhat.com/show_bug.cgi?id=173869 Possibly a regression? > > We can't do this only once at the end of a transaction but if I'm > > remembering a different discussion, doing it multiple times at the end > > of the rpm transaction should be almost as good (since gconf will wait for > > a few moments from getting the first SIGHUP to see if it will get any other > > ones.) Is that correct? > > It has a 30 second timer currently for "periodic cleanup", and SIGHUP > just sets a flag that that function reads. So changing policy back to doing a killall -HUP in %posttrans should work. It would be nice to know what Fedora versions are affected by this and whether it will someday be fixed before updating the Guidelines, though. -Toshio pgpttwMxOIzVA.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, May 07, 2010 at 06:59:29PM +0200, Pierre-Yves wrote: > On Fri, 2010-05-07 at 09:38 -0400, Colin Walters wrote: > > On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves wrote: > > > > > > Would it be allowed to try to restart gconfd ? > > > > It would make sense to SIGHUP gconfd after new schemas are installed, > > yes. Note though we should really only be doing this once at the end > > of a transaction when installation is complete. > > Thanks for your help, I will update the spec to do this. > Would you have any advice/example on what would be the best way to do > it ? > Do you think it should be done on %postun as well ? > > Something like this: %posttrans killall -HUP gconfd-2 > /dev/null || : You might want to switch to using the macros documented here at the same time:: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GConf I don't know which version of Fedora those went into GConf though. (Since this might be a regression in gconf2, you might need to still add the %posttrans scriptlet wth the new scriptlets. If Colin knows that this is %a bug that won't be fixed in some versions of Fedora I'll add the killall %to the appropriate point in the Guidelines.) -Toshio pgpLh9pVqz22z.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 585336] Review Request: perl-Sys-CPU - Getting CPU information
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=585336 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Sys-CPU-0.51-2.fc12 Resolution||ERRATA -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 585336] Review Request: perl-Sys-CPU - Getting CPU information
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=585336 --- Comment #17 from Fedora Update System 2010-05-07 13:26:17 EDT --- perl-Sys-CPU-0.51-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: GConf error
On Fri, May 7, 2010 at 1:17 PM, Toshio Kuratomi wrote: > > Running makefile-install-schema and makefile-uninstall-schema eventually > calls do_sync() which was supposed to reread the schemas. That's currently > calling gconf_engine_suggest_sync() in gconf.c and I'm not sure whether > there's some logic in there that could cause it not to suggest syncing in > our current setup. I don't understand how this could ever work - GConf IPC happens in terms of ORBit which is per-uid, so a bare --makefile-install-rule might contact the GConf engine for uid 0 and ask it to reload, but that's it. It would have to jump through hoops to contact the GConf running as uid 500 or whatever, and I don't see those hoops being jumped. Oh but...I see, it's a Fedora patch not in the upstream GConf code to run killall. My bad looking at upstream gconf git. Sigh... > So changing policy back to doing a killall -HUP in %posttrans should work. > It would be nice to know what Fedora versions are affected by this and > whether it will someday be fixed before updating the Guidelines, though. So though this still leaves a window of up to 30 seconds where after installing an application the schema will be invalid. Which seems very likely what people are hitting. I think ideally we'd have the RPM system detect a schema was installed and do an immediate reload once post transaction, and nuke the 30 second timeout from gconf. That still leaves though the problem of the massive copy&paste scriptlets; we could remove the killall from --makefile-install-rule which would help. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Could someone, please, clarify situation with *-javadoc
Hi, > Sometimes *-javadoc sub-packages explicitly requires main package, and > sometimes - not. I'm not a java-expert, so I don't know which is > correct. I don't think it really matters. In some cases, sure, it would be nice to ensure that the package is around if someone is looking at the API documentation. Other times someone may only want to peruse the APIs without installing the implementation. Others will have different opinions so let's hear 'em. Andrew -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
2010/5/7 Matěj Cepl : > Dne 7.5.2010 01:01, Rudolf Kastl napsal(a): >> one of the questions raised in the meeting posted by mcepl was... "why >> dont those people leave if they are unhappy". simple... they put alot >> sweat blood and tears into a project, and they have friends... with >> the development crowd and with the community in general. they are >> obviously feeling as a part of it with just a different pov and an own >> opinion. that isnt bad at all ... but healthy... "diversity is >> healthy" to a project. > > I didn't to continue in this thread, but here I have to defend myself. I > don't remember I would say anything like that, but it looks to me like > taken out of the context at least and expressing exactly opposite > position I think I held. Although I don't agree with many of them in a > lot of places, I strongly support Kevin's, Ralf's and others position > that the current development is very harmful to the development of > Fedora and I would love them to stay and defend this still nice project > we all work on. i didnt mean you said that. i was referring to the meeting log you posted. sorry for the confusion. kind regards, Rudolf Kastl > > Actually, http://skvidal.wordpress.com/2010/05/07/dissidents/ made me so > angry that I am just not able to write any response to it ... whatever I > would write would be too much personal half-libelous attack, so I will > rather write nothing. > > Matěj > > -- > According to the Franciscan priest Richard Rohr, spirituality is > not for people who are trying to avoid hell; it is for people > who have been through hell. In many ways, spirituality is about > what we do with our pain. And the truth is, if we don't > transform it, we will transmit it. > -- Al Gustafson > > -- > 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: Some more Python 3: (was Re: rawhide report: 20100507 changes)
On Fri, May 7, 2010 at 9:05 AM, David Malcolm wrote: > On Fri, 2010-05-07 at 12:25 +, Rawhide Report wrote: > > Three more python 3 subpackages in today's "rawhide" heading for F14 - > I've gone ahead and added these to the wiki here: > > https://fedoraproject.org/wiki/Features/Python3F13#Python_3_already_in_Fedora > > Are we missing anything? > > Crud, this probably means I need to either finish my pure-python MySQL driver, or work on making MySQLdb run with python3. :-) If you want to update the upstream status for MySQLdb, we simply haven't started porting it. -- ky...@kylev.com Some people have a way with words, while others... erm... thingy. ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Could someone, please, clarify situation with *-javadoc
On Friday 07 May 2010, Andrew Overholt wrote: > Hi, > > > Sometimes *-javadoc sub-packages explicitly requires main package, and > > sometimes - not. I'm not a java-expert, so I don't know which is > > correct. > > I don't think it really matters. In some cases, sure, it would be nice > to ensure that the package is around if someone is looking at the API > documentation. Other times someone may only want to peruse the APIs > without installing the implementation. > > Others will have different opinions so let's hear 'em. I'm strongly against adding such dependencies if the javadocs don't actually for some reason _really_ require the main package. I don't think I've seen a case where such a dependency would really exist. - Common sense and common packaging practices: don't add dependencies that aren't really requirements for a package. - It's convenient to be able to install lots of *-javadoc packages (nicely crosslinked even in many cases) and configure a web server to serve them, browse them and/or configure IDEs to access API docs from there. Main package deps would pull in lots of cruft that isn't needed by a server with this role. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Could someone, please, clarify situation with *-javadoc
On Fri, 2010-05-07 at 13:41 -0400, Andrew Overholt wrote: > > Sometimes *-javadoc sub-packages explicitly requires main package, and > > sometimes - not. I'm not a java-expert, so I don't know which is > > correct. > > I don't think it really matters. In some cases, sure, it would be nice > to ensure that the package is around if someone is looking at the API > documentation. Other times someone may only want to peruse the APIs > without installing the implementation. > > Others will have different opinions so let's hear 'em. This is where a "suggests" like Debian might be appropriate. (Does Debian do that for their javadocs?) -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Thu, 2010-05-06 at 17:46 -0400, Brian Pepple wrote: > Normally, I'd be against it killing a thread, but the thread that > started this discussion had already been done awhile back and this new > thread added *nothing* new to the discussion. Frankly, it was more > deserving to be on Slashdot more than the fedora-devel list. The Hall > Monitors were totally justified in killing this one imo, and frankly if > folks want more repetitive flame-bait threads like that I've got zero > interest in staying subscribed to it. I'm not actually particularly interested in whether this is true or not. What worries me is that it was always my understanding, and I think the understanding of others, that the hall monitoring policy does not grant hall monitors the power to shut down threads they judge to be repetitive. My understanding is it should only grant them the power to shut down threads which violate the 'be excellent to each other' motto - i.e., it's about the civility of the discussion, not the subject matter. Whether shutting down repetitive threads is a good idea and they _should_ have that power is a separate question; even if you think they should, it's surely not appropriate for them to exercise that power before it's actually been duly granted. (if you go to the policy to check this, you may be surprised to notice it's suddenly sprouted the following section: "In addition to non-excellent individual behavior, there can be occasions where a mailing list thread gets "out of hand", and is no longer productive. While simply being a long thread is not a problem, threads with a limited number of people, repeating their same stances over and over again with no forward progress, are also not beneficial, and detract from healthy discussion. * Hall monitors are allowed to send 'thread closure' posts to threads that, after 50 or more messages, do not appear to be making any forward progress. When this is done the subject line of the message will be prefixed with [HALL-MONITORED] and a link to this wiki page is included in the message. This is intended to spur thread participants to re-focus their discussion in productive manners, ideally in new and smaller topic-specific threads." This seems to have been added 'for review' yesterday, which to me is a rather odd approach for a policy which is already in practical use, however much the top of the page claims it to be a 'draft'. Proposed changes for review should happen elsewhere, not in the 'production copy' of the policy. But never mind. For the purposes of this email, please refer to the policy as it existed when the thread was monitored, before the above addition.) -- 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: Reasons for hall monitoring
On 05/07/2010 03:05 PM, Adam Williamson wrote: > On Thu, 2010-05-06 at 17:46 -0400, Brian Pepple wrote: > >> Normally, I'd be against it killing a thread, but the thread that >> started this discussion had already been done awhile back and this new >> thread added *nothing* new to the discussion. Frankly, it was more >> deserving to be on Slashdot more than the fedora-devel list. The Hall >> Monitors were totally justified in killing this one imo, and frankly if >> folks want more repetitive flame-bait threads like that I've got zero >> interest in staying subscribed to it. > > I'm not actually particularly interested in whether this is true or not. > What worries me is that it was always my understanding, and I think the > understanding of others, that the hall monitoring policy does not grant > hall monitors the power to shut down threads they judge to be > repetitive. My understanding is it should only grant them the power to > shut down threads which violate the 'be excellent to each other' motto - > i.e., it's about the civility of the discussion, not the subject matter. The problem with this distinction is that in some cases the very act of bringing something up again *isn't* civil. That being said, I think the Hall Monitor concept is pretty awful. -- Peter What we need is either less corruption, or more chances to participate in it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Could someone, please, clarify situation with *-javadoc
(changing lists) fre 2010-05-07 klockan 13:41 -0400 skrev Andrew Overholt: > Hi, > > > Sometimes *-javadoc sub-packages explicitly requires main package, and > > sometimes - not. I'm not a java-expert, so I don't know which is > > correct. > > I don't think it really matters. In some cases, sure, it would be nice > to ensure that the package is around if someone is looking at the API > documentation. Other times someone may only want to peruse the APIs > without installing the implementation. Agreed. Those deps are now removed from the examples in https://fedoraproject.org/wiki/User:Abo/JavaPackagingDraftUpdate which I previously submitted as a proposed guideline update. (I hope I submitted it the right way...) Somehow I managed to not notice the java-devel list until recently so I think this is the first time I've mentioned the draft here. Please read and comment on it! The number of changes are growing... I should move it out of the User:Abo namespace so it doesn't look like a personal page. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
usb_modeswitch 1.1.2 in Fedora 11
You appear to be the maintainer of usb_modeswitch. For the purpose of making GSM connectivity work on the OLPC XO-1, I've backported usb_modeswitch and usb_modeswitch-data to Fedora 11. It's been tested in the field and it fixes some Huawei models that were previously unusable. Would you mind if I pushed this update before the Fedora 11 repositories freeze? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Fri, 2010-05-07 at 20:05 +0100, Adam Williamson wrote: > (if you go to the policy to check this, you may be surprised to notice > it's suddenly sprouted the following section: > > "In addition to non-excellent individual behavior, there can be > occasions where a mailing list thread gets "out of hand", and is no > longer productive. [...] This would appear to be the action from the recent board meeting: https://meetbot.fedoraproject.org/fedora-board-meeting/2010-05-06/fedora_board.2010-05-06-16.00.log.html > This seems to have been added 'for review' yesterday, which to me is a > rather odd approach for a policy which is already in practical use, > however much the top of the page claims it to be a 'draft'. Proposed > changes for review should happen elsewhere, not in the 'production copy' > of the policy. FWIW, I agree. > What worries me is that it was always my understanding, and I think the > understanding of others, that the hall monitoring policy does not grant > hall monitors the power to shut down threads they judge to be > repetitive. My understanding is it should only grant them the power to > shut down threads which violate the 'be excellent to each other' motto - > i.e., it's about the civility of the discussion, not the subject matter. > > Whether shutting down repetitive threads is a good idea and they > _should_ have that power is a separate question; even if you think they > should, it's surely not appropriate for them to exercise that power > before it's actually been duly granted. The board meeting log suggests that they intended the policy to have the broader goal of keeping the discussion "constructive". I'm not sure to what degree the policy can be considered something to follow by letter, independently of its intent. (BTW, John Poelstra made two more revisions to the policy 20 minutes ago.) -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, May 07, 2010 at 01:37:20PM -0400, Colin Walters wrote: > On Fri, May 7, 2010 at 1:17 PM, Toshio Kuratomi wrote: > > > > Running makefile-install-schema and makefile-uninstall-schema eventually > > calls do_sync() which was supposed to reread the schemas. That's currently > > calling gconf_engine_suggest_sync() in gconf.c and I'm not sure whether > > there's some logic in there that could cause it not to suggest syncing in > > our current setup. > > I don't understand how this could ever work - GConf IPC happens in > terms of ORBit which is per-uid, so a bare --makefile-install-rule > might contact the GConf engine for uid 0 and ask it to reload, but > that's it. It would have to jump through hoops to contact the GConf > running as uid 500 or whatever, and I don't see those hoops being > jumped. > > Oh but...I see, it's a Fedora patch not in the upstream GConf code to > run killall. My bad looking at upstream gconf git. Sigh... > Ah I guess that's also why I thought the code had changed. Thought that was something we'd pushed upstream and subsequent changes had removed parts of it. > > So changing policy back to doing a killall -HUP in %posttrans should work. > > It would be nice to know what Fedora versions are affected by this and > > whether it will someday be fixed before updating the Guidelines, though. > > So though this still leaves a window of up to 30 seconds where after > installing an application the schema will be invalid. Which seems > very likely what people are hitting. > Interesting -- so to test this we'd need: 1) Update package with new schema 2) Hopefully the package is the only thing being updated, otherwise, we could pass the timeout if no other schema-installing packages are also installed in the transaction. 3) Immediately try to invoke the program. The program then reads the old gconf schema and bails out or something. However, this would seem to mean that if the user just stops the program and restarts it after 30 seconds it should pick up the new schema. > I think ideally we'd have the RPM system detect a schema was installed > and do an immediate reload once post transaction, and nuke the 30 > second timeout from gconf. That still leaves though the problem of > the massive copy&paste scriptlets; we could remove the killall from > --makefile-install-rule which would help. > The current scriptlets are pretty short... perhaps even too short :-( I had to look at the draft page for the gconf update to remember what they're doing behind the scenes. I remember panu and ffesti were exploring ideas in the area of autodetecting types of files that were installed and running scripts based on that but I don't know what they've found. -Toshio pgpS4qprgMAwK.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
Matt McCutchen said the following on 05/07/2010 01:41 PM Pacific Time: > On Fri, 2010-05-07 at 20:05 +0100, Adam Williamson wrote: >> (if you go to the policy to check this, you may be surprised to notice >> it's suddenly sprouted the following section: >> >> "In addition to non-excellent individual behavior, there can be >> occasions where a mailing list thread gets "out of hand", and is no >> longer productive. [...] > > This would appear to be the action from the recent board meeting: > > https://meetbot.fedoraproject.org/fedora-board-meeting/2010-05-06/fedora_board.2010-05-06-16.00.log.html > >> This seems to have been added 'for review' yesterday, which to me is a >> rather odd approach for a policy which is already in practical use, >> however much the top of the page claims it to be a 'draft'. Proposed >> changes for review should happen elsewhere, not in the 'production copy' >> of the policy. > > FWIW, I agree. > >> What worries me is that it was always my understanding, and I think the >> understanding of others, that the hall monitoring policy does not grant >> hall monitors the power to shut down threads they judge to be >> repetitive. My understanding is it should only grant them the power to >> shut down threads which violate the 'be excellent to each other' motto - >> i.e., it's about the civility of the discussion, not the subject matter. >> >> Whether shutting down repetitive threads is a good idea and they >> _should_ have that power is a separate question; even if you think they >> should, it's surely not appropriate for them to exercise that power >> before it's actually been duly granted. > > The board meeting log suggests that they intended the policy to have the > broader goal of keeping the discussion "constructive". I'm not sure to > what degree the policy can be considered something to follow by letter, > independently of its intent. > > (BTW, John Poelstra made two more revisions to the policy 20 minutes > ago.) > Correct. He was following up on an action item he took from the meeting which was to draft up some clear objectives for having the policy in the first place :) John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, 2010-05-07 at 17:25 -0400, Toshio Kuratomi wrote: > I remember panu and ffesti were exploring ideas in the area of autodetecting > types of files that were installed and running scripts based on that but > I don't know what they've found. Link? This is an idea I have been meaning to push as a "feature" for a while, but I hadn't gotten around to it. I would be glad to join an existing effort. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Wed, 2010-05-05 at 07:37 +0200, Rudolf Kastl wrote: > well there are a few potential solution to this: > > 1) try to get rid of this policy > 2) use different lists/forums to continue the discussion. > > you pick which one is worth to go ahead with. this is not a democracy, > and it has been stated often enough by all people involved, not even > an indirect one. Right. Someone in the community should set up a suitable list or forum, identical in charter but with weaker restrictions on "unconstructive" discussion. It could even be called Mail Fission. Volunteers? I could do it if no one else wants to. Or does such a venue already exist? We'll see how many people join. If very many people do, the board may be persuaded to change the policy; if not, that would suggest that the current policy is acceptable to the community at large. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Socket-GetAddrInfo/devel perl-Socket-GetAddrInfo.spec, 1.5, 1.6
Author: kwizart
Update of /cvs/pkgs/rpms/perl-Socket-GetAddrInfo/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv23675
Modified Files:
perl-Socket-GetAddrInfo.spec
Log Message:
Fix for perl(ExtUtils::CChecker)
Index: perl-Socket-GetAddrInfo.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Socket-GetAddrInfo/devel/perl-Socket-GetAddrInfo.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- perl-Socket-GetAddrInfo.spec7 May 2010 21:37:17 - 1.5
+++ perl-Socket-GetAddrInfo.spec7 May 2010 21:59:57 - 1.6
@@ -1,6 +1,6 @@
Name: perl-Socket-GetAddrInfo
Version:0.15
-Release:3%{?dist}
+Release:4%{?dist}
Summary:RFC 2553's "getaddrinfo" and "getnameinfo" functions
Group: Development/Libraries
@@ -10,6 +10,7 @@ Source0:http://search.cpan.org/C
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(ExtUtils::CBuilder)
+BuildRequires: perl(ExtUtils::CChecker)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Module::Build::Compat)
BuildRequires: perl(Test::More)
@@ -60,8 +61,8 @@ rm -rf $RPM_BUILD_ROOT
%changelog
-* Fri May 07 2010 Nicolas Chauvet - 0.15-3
-- Rebuilt with perl(ExtUtils::CBuilder)
+* Fri May 07 2010 Nicolas Chauvet - 0.15-4
+- Rebuilt with perl(ExtUtils::CChecker)
* Thu May 06 2010 Marcela Maslanova - 0.15-2
- Mass rebuild with perl-5.12.0
--
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: GConf error
On Fri, 2010-05-07 at 13:24 -0400, Toshio Kuratomi wrote: > > Something like this: > > %posttrans > killall -HUP gconfd-2 > /dev/null || : > > > You might want to switch to using the macros documented here at the > same > time:: > https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GConf I have updated devel and F-13 to use the macro and only added the % posttrans for F-12 and F-11. Thanks for the help, Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Could someone, please, clarify situation with *-javadoc
2010/5/7 Alexander Boström :
> fre 2010-05-07 klockan 13:41 -0400 skrev Andrew Overholt:
>>> Sometimes *-javadoc sub-packages explicitly requires main package, and
>>> sometimes - not. I'm not a java-expert, so I don't know which is
>>> correct.
>>
>> I don't think it really matters. In some cases, sure, it would be nice
>> to ensure that the package is around if someone is looking at the API
>> documentation. Other times someone may only want to peruse the APIs
>> without installing the implementation.
>
> Agreed. Those deps are now removed from the examples in
> https://fedoraproject.org/wiki/User:Abo/JavaPackagingDraftUpdate which I
> previously submitted as a proposed guideline update. (I hope I submitted
> it the right way...)
I think there are use cases for which you want to install javadocs without
installing the bytecode; besides that, the Requires: tag is to make explicit
some runtime dependency, not a simple relation like this one.
Someone would disagree with me; however i think any decision is taken on
that topic would be turned in a MUST (depend or not depend) for the sake
of coherency.
> Somehow I managed to not notice the java-devel list until recently so I
> think this is the first time I've mentioned the draft here. Please read
> and comment on it! The number of changes are growing...
Some notes:
1- BuildRequires and Requires
At a minimum, Java packages MUST:
BuildRequires: java-devel [>= specific_version]
BuildRequires: jpackage-utils
Requires: java >= specific_version
Requires: jpackage-utils
This code snippet is telling me that specifying ">= specific_version"
in BuildRequires: java-devel is optional, while it is mandatory in
Requires: java
I have no objections to that, but the ant and maven templates below
must be updated consistently with that.
2- JavaDoc installation
"The name of the subdirectory SHOULD be either %{name}
or %{name}-%{version} with a symlink %{name} pointing to it."
I would turn that in a "MUST be either " one or the other: different directory
naming should be a rare exception and SHOULD doesnt seem strong enough.
3- maven template
You could drop the dependency on the main package for the manual too.
Anyway, the line should be:
Requires: %{name} = %{version}-%{release}
not
Requires: %{name}-%{version}-%{release}
I also would write a more general %add_to_maven_depmap macro call, from:
%add_to_maven_depmap org.apache.maven %{name} %{version} JPP %{name}
to:
%add_to_maven_depmap [groupId] [artifactId] %{version}
JPP[/optional_subDir] [jarName]
Finally, in the %files section:
%{_datadir}/maven2/poms/*
or
%{mavenpomdir}/*
Hope that helps
guido
--
Guido Grazioli
Via Parri 11 48011 - Alfonsine (RA)
Mobile: +39 347 1017202 (10-18)
Key FP = 7040 F398 0DED A737 7337 DAE1 12DC A698 5E81 2278
Linked in: http://www.linkedin.com/in/guidograzioli
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
s/redhat/system in package names
hi, Long time ago, all *redhat* packages were renamed to "system*". But three of them are still alive: redhat-lsb, redhat-menus and redhat-rpm-config Should they switch to "system-" ? -thanks- -- «Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra; que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor, que no sienta mi derecho y dé pecho a mi valor.» -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 13 RC #2 testing open
Fedora 13 Final RC2 is now becoming available. Please refer to the following pages for download links and testing instructions. We have a mostly complete set of images, with DVD and split CD for both arches, and Desktop and KDE live images. The changes from RC1 are minor: just an updated plymouth package to address https://bugzilla.redhat.com/show_bug.cgi?id=585128 , and an updated deja-dup package as we discovered it had been stuck in updates-testing for a while and the package on RC1 was rather old and suffering from a few bugs. Aside from that, it should behave exactly as RC1, but of course we would like to fill out the matrices to be confident. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha, Beta, and Final priority test cases for installation [2] and desktop [3] should pass in order to meet the Final Release Criteria [4]. Help is available on #fedora-qa on irc.freenode.net [5], or on the test list [6]. [1] http://poelstra.fedorapeople.org/schedules/f-13/f-13-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [4] https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria [5] irc://irc.freenode.net/fedora-qa [6] https://admin.fedoraproject.org/mailman/listinfo/test -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
Dne 7.5.2010 16:56, Przemek Klosowski napsal(a): > Here's the rub, though: Kevin argues for aggressive development and > empowering the package maintainers to push out changes, even if it > resulted in temporary regressions. Ralf, on the other hand, reminds us > about the need for quality control, process and stability. They can't > both be right---but the entire project is better off for them voicing > their opinions. Well, I would argue that both can be right (although I believe Ralf would strongly disagree with me on this point). The point in Kevin's triades which I am afraid was utterly rejected (or ignored) is that the most important relationship in whole Fedora land is the relationship between package maintainer and users of the package she maintains. When I came to Fedora from the Debian-world (around FC6 release) I was absolutely in awe how better experience was maintaining packages in Fedora than in Debian. It seemed like the combination of best of being completely independent and maintaining your own repository (what would be now called PPA; I haven't heard the term then yet) and having support and community of fellow maintainers all in one package. It was refreshing to see how problems were just solved on the spot without need to apply for permission and a lot of bureaucracy. The result was incredibly rapid development (I remember I was using as an advertisement slogan “Fedora? Next release of your distribution today!”). This vision in my opinion requires freedom for packagers of individual packages to have quite wide allowance in setting their own policies concerning updates and bug fixing. If Kevin prefers to have packages on all distros synchronized and (maybe, I don't know, I don't use KDE) broken much more often than Gnome-folks, it is in my opinion mostly between KDE team and KDE users. Also, if they don't think they can manage much more than pushing all non-packaging bugs upstream, I am not the one who would preach to them they should do better (especially without providing manpower to do so). OTOH, if Ralph doesn't won't to push almost any bug upstream and he wants to make sure that all Fedora bugs are fixed asap, great for his users, they will certainly love him, but I am not sure it should be fixed as a rule for everybody. This kind of "shared PPA" vision doesn't exclude some kind of stricter requirements on critical-path packages ... if glibc or kernel is broken, than basically everybody is affected and these components should be fixed fast to allow others to work. But I would think that this critical path should be really short ... glibc, kernel, udev & co. and it should end somewhere at xorg-x11-* packages, but not much more. Certainly the critical packages shouldn't cover by far “all what normal user needs for his work” (including OpenOffice.org and Firefox), “whatever is on LiveCD”, or “in the end everything” (all three ideas I have actually heard). Of course, this kind of development process doesn’t produce distro stable enough I could put it on my company’s server (or my mom’s notebook), but it could be an ideal distro for developers or contributors of any kind (with reference to http://smoogespace.blogspot.com/2010/05/at-least-they-had-burning-cloud-to.html by contributor I mean anybody who provides any bits to the distro ... packagers, artists, translators, tech writers, QA folks, yes, even admins; I would say that somebody just handing the DVD to a friend is doing good job in promoting the distro, but he isn't contributor in my meaning of the word). It seems to me that the current fashion is going sharply against this vision of "shared PPA". There is more and more policies, permissions, preliminary testing, etc. Suddenly packaging for Fedora is less and less fun and more and more chore, which I don't want to dwell in. I have left most of packaging last year (for various personal and non-personal reasons) but I don't feel much urge to return to packaging anymore. Or in other words, if I need some package, I can package it myself, but I tend to keep all packages in my personal repository, and not bother with all permissions, reviews, guildelines, policies (which is not to say that there are no guidelines which could be helpful). I don't need that much bandwidth and storage for my personal needs any (which is the key resource current establishment controls). I wonder how many packagers (or former packagers) feels the same. More and more I was writing this email, more and more I tend to agree with somebody today, who wrote that they key problem of the Fedora community is unclear vision about its purpose. I agree completely. I believe, that in the root of many of our problems lies in our unwillingness to say that we are not end-user-oriented distribution, but the contributors-oriented one. There are many who pretends that it is possible to be both CentOS (or Ubuntu) and Fedora-as-we-knew-it at the same time, at tha
Re: s/redhat/system in package names
On Sat, May 8, 2010 at 9:10 AM, Xose Vazquez Perez wrote: > hi, > > Long time ago, all *redhat* packages were renamed to "system*". > But three of them are still alive: redhat-lsb, redhat-menus and > redhat-rpm-config > > Should they switch to "system-" ? > > -thanks- > > -- > «Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra; > que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie > impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor, > que no sienta mi derecho y dé pecho a mi valor.» > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Although I am not familiar with what you've mentioned, is there a point for the change? I'm curious, -- Chris Jones Photographic Imaging Professional and Graphic Designer ABN: 98 317 740 240 Photo Resolutions Web: http://photoresolutions.freehostia.com Email: -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Fri, May 7, 2010 at 5:41 PM, Matěj Cepl wrote: > Dne 7.5.2010 16:56, Przemek Klosowski napsal(a): >> Here's the rub, though: Kevin argues for aggressive development and >> empowering the package maintainers to push out changes, even if it >> resulted in temporary regressions. Ralf, on the other hand, reminds us >> about the need for quality control, process and stability. They can't >> both be right---but the entire project is better off for them voicing >> their opinions. > > Well, I would argue that both can be right (although I believe Ralf > would strongly disagree with me on this point). The point in Kevin's > triades which I am afraid was utterly rejected (or ignored) is that the > most important relationship in whole Fedora land is the relationship > between package maintainer and users of the package she maintains. > > When I came to Fedora from the Debian-world (around FC6 release) I was > absolutely in awe how better experience was maintaining packages in > Fedora than in Debian. It seemed like the combination of best of being > completely independent and maintaining your own repository (what would > be now called PPA; I haven't heard the term then yet) and having support > and community of fellow maintainers all in one package. It was > refreshing to see how problems were just solved on the spot without need > to apply for permission and a lot of bureaucracy. The result was > incredibly rapid development (I remember I was using as an advertisement > slogan "Fedora? Next release of your distribution today!"). It is a blessing and it is a curse. Why do more developers show up at conferences these days running Ubuntu or Debian systems.. many who used to run Fedora or RHL? My very non-scientific survey has been that it isn't that Ubuntu is cooler, etc.. but it is just much more stable. Things don't break mid-release, they aren't spending all their time updating to whatever is in Fedora and finding yet again its broken. And when things are broken, people seem nicer. Now does this happen a lot, probably not.. but for most developers it just has to happen one or two times at the worst time and they will go find something both new and stable for them. Yes they aren't getting the latest stuff anymore.. but on the other hand they don't have to worry that the 3 KDE apps they use didn't completely change over a weekend (or vice versa the 2 gnome apps they depend on for something didn't break because ibus got added as a dependency and didn't work for some reason.) > This vision in my opinion requires freedom for packagers of individual > packages to have quite wide allowance in setting their own policies > concerning updates and bug fixing. If Kevin prefers to have packages on > all distros synchronized and (maybe, I don't know, I don't use KDE) > broken much more often than Gnome-folks, it is in my opinion mostly > between KDE team and KDE users. Also, if they don't think they can > manage much more than pushing all non-packaging bugs upstream, I am not > the one who would preach to them they should do better (especially > without providing manpower to do so). OTOH, if Ralph doesn't won't to > push almost any bug upstream and he wants to make sure that all Fedora > bugs are fixed asap, great for his users, they will certainly love him, > but I am not sure it should be fixed as a rule for everybody. > The vision works as long as the set of packages and packagers is small. It is very much the "Tragedy of the Commons" where at a certain point I don't have a strong enough social link to think or worry about what effect my package might have on something 30 packages away from me. The fact that its broken and 4 users left doesn't really affect me unless it turns out that it is Linus and he says something like "Sorry about missing 2.6.36-rc1.. but for some reason Xmonkey. started writing 0's to all my files last night and my backups too... Didn't know I even had it installed.." Sure it got pulled in because it gives libslapmonkey and now vim pulls it in so you can have an animated monkey if you type :monkeybrainz [or some such thing.] But in cases where it isn't Linus people just don't know. At a certain size there are too many packages and too few packagers who meet the level of people back when Fedora Extras was the big thing, and you had to deal with getting critiqued directly by Ralph and similar others. -- Stephen J Smoogen. "The core skill of innovators is error recovery, not failure avoidance." Randy Nelson, President of Pixar University. "We have a strategic plan. It's called doing things."" -- Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
2010/5/8 Matěj Cepl : > Of course, this kind of development process doesn’t produce distro > stable enough I could put it on my company’s server (or my mom’s > notebook), but it could be an ideal distro for developers or > contributors of any kind I am a developer and i want my workstation more stable than my mother laptop (and yes we both use Fedora). Indeed my home deploy server has F-11, my daily eclipse workstation has F-12, and i have rawhide in a kvm to do package maintenance. I dont want to be thrown daily updates on the first two, but i think 8-9 month is a good enough compromise for an upgrade; so i',m pretty comfortable with Fedora release cycle. Even if you don't develop for work, lets say you are contributing to some oss project, i don't think working on an "adventurous" environment is a good idea; do you want to be stopped for bugs in libraries your code base depends on? So, such an environment turns useful for distro developers, but a distro for distro developers sounds so silly to me. On the other hand, i have my living room htpc with fedora and update-candidates turned on (and atrpms-bleeding to be precise). So i get all those updates daily, hoping some of the (very minor in comparison to those i *could* have on my work pc) issues go away. I have choice; and no, i'm not configuring all like that because fesco told me. I understand and respect any different opinion, but please don't imply i don't exists, because i think i am a pretty standard figure in end-user realm. Cheers -- Guido Grazioli Via Parri 11 48011 - Alfonsine (RA) Mobile: +39 347 1017202 (10-18) Key FP = 7040 F398 0DED A737 7337 DAE1 12DC A698 5E81 2278 Linked in: http://www.linkedin.com/in/guidograzioli -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
Matěj Cepl said the following on 05/07/2010 04:41 PM Pacific Time: > More and more I was writing this email, more and more I tend to agree > with somebody today, who wrote that they key problem of the Fedora > community is unclear vision about its purpose. I agree completely. I > believe, that in the root of many of our problems lies in our > unwillingness to say that we are not end-user-oriented distribution, but > the contributors-oriented one. > It is not a binary situation. https://fedoraproject.org/wiki/User_base -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On 05/08/2010 02:40 AM, John Poelstra wrote: > Matěj Cepl said the following on 05/07/2010 04:41 PM Pacific Time: > >> More and more I was writing this email, more and more I tend to agree >> with somebody today, who wrote that they key problem of the Fedora >> community is unclear vision about its purpose. I agree completely. I >> believe, that in the root of many of our problems lies in our >> unwillingness to say that we are not end-user-oriented distribution, but >> the contributors-oriented one. >> That somebody being *me* and no you fail to understand the underlying issue Matěj we can be both be an end-user-oriented distribution and the contributors-oriented one but as long as one "vision" governs the project that will never happen. Projects and their contributions are not being treated equally within the project and that truly is the underlying issue and that's OK as long as contributors are told that that is what they are signing up for which by the way they have not been nor currently is being done. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Fri, 2010-05-07 at 20:05 +0100, Adam Williamson wrote: > What worries me is that it was always my understanding, and I think the > understanding of others, that the hall monitoring policy does not grant > hall monitors the power to shut down threads they judge to be > repetitive. My understanding is it should only grant them the power to > shut down threads which violate the 'be excellent to each other' motto - > i.e., it's about the civility of the discussion, not the subject matter. The thread was repetitive from a thread that had been shut down because it had degenerated way past "be excellent to each other", and seemingly was restarted explicitly to incite more flames, misinformation and hatred. The only thing I found objectionable was that it was allowed to last _so_ _long_ before being killed. Hopefully, in the future, if a thread is hall monitored the people who were the main reason it got out of control won't be allowed to wait a few weeks, change the subject and start it back up. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On 05/08/2010 01:41 AM, Matěj Cepl wrote: > Dne 7.5.2010 16:56, Przemek Klosowski napsal(a): > It seemed like the combination of best of being > completely independent and maintaining your own repository (what would > be now called PPA; I haven't heard the term then yet) and having support > and community of fellow maintainers all in one package. It was > refreshing to see how problems were just solved on the spot without need > to apply for permission and a lot of bureaucracy. The result was > incredibly rapid development (I remember I was using as an advertisement > slogan “Fedora? Next release of your distribution today!”). :) Agreed, this aspect to a wide extend has gone lost in Fedora. > This vision in my opinion requires freedom for packagers of individual > packages to have quite wide allowance in setting their own policies > concerning updates and bug fixing. If Kevin prefers to have packages on > all distros synchronized and (maybe, I don't know, I don't use KDE) > broken much more often than Gnome-folks, it is in my opinion mostly > between KDE team and KDE users. Also, if they don't think they can > manage much more than pushing all non-packaging bugs upstream, I am not > the one who would preach to them they should do better (especially > without providing manpower to do so). OTOH, if Ralph doesn't won't to > push almost any bug upstream and he wants to make sure that all Fedora > bugs are fixed asap, great for his users, they will certainly love him, > but I am not sure it should be fixed as a rule for everybody. Well, my view is a bit different: I consider it to be a Fedora's package's maintainer's primary task and duty to keep his package "working and functional" in *Fedora*. To be able to achieve this he is required to bring along a certain amount of technical skills/qualifications. Wrt. this, I am observing deficiencies in Fedora. I feel, there are packagers who consider packaging to be a mechanical task, but who don't actually understand what they are doing. Part of this "task and duty" is the Fedora maintainer to go after bugs/malfunctions/defects etc." and process them in "adequate time" such that these "bugs/malfunctions etc" do not furtheron affect Fedora users. How and what to do in detail to achieve this can vary in wide ranges in individual cases. This can be him to investigate an issue and to provide fixes himself, this can be him asking upstream, this can be him arranging a contact between reporter and upstream. The only thing that matters is to keep the impact of such issues low as possible to the Fedora users - In an ideal world, this would be to fix the bug ASAP. In real world, processing such issues often works entirely different. It may easily comprise to release major package upgrades midst of a distro's life-cycle, even ABI/APi breaking ones, occasionally to backport selected fixes, or ... not to upgrade or in extreme cases, to remove or downgrade packages. In short: Being religous about any of these details doesn't help anyone. Neither "let users report bugs upstream" nor "no backports" nor "no ABI/API breaking upgrades" nor "strictly follow upstream releases" will work everywhere on all occasions. Or yet differently: The user and his experience with the packages a packager maintains should be in the focus of a packager's works. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
Dne 8.5.2010 07:33, James Antill napsal(a): > The thread was repetitive from a thread that had been shut down because > it had degenerated way past "be excellent to each other", and seemingly > was restarted explicitly to incite more flames, misinformation and > hatred. What if, somebody is not happy about a discussion degraded into personal attacks, but feels that the issue at hand was never resolved properly. So he sits down and writes as plainly as he can (BTW, notice that Kevin is not native English speaker, not trying to imply it is the case here, just that we should cut each other some slack ... there are many people with ESL in the Fedora project). He feels personally hurt by the previous actions, so he writes in quite personal tone. And he is immediately shut down, because we have already settled this issue (well, we haven't, the discussion was just shut down, but it is convenient to pretend we did). How is that being excellent to each other? Matěj -- He can compress the most words into the smallest idea of any man I know. -- Abraham Lincoln -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
