Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Sir Gallantmon (ニール・ゴンパ) wrote: Though, there are some instances where the prevailing opinion should be ignored, when there is no solid evidence to back it up, e.g. Mono and the like. Indeed, I also think defending freedom is important (and it was part of my campaign). But I've also been unhappy with FESCo's decisions in that domain, e.g.: * libvdpau was approved for Fedora. This is a library which: - only accelerates decoding patent-encumbered MPEG family video codecs. ALL software which uses that is in RPM Fusion, not Fedora, anyway. - has no actual Free Software implementations. It is ONLY implemented by proprietary drivers. So what does Fedora have to gain from this pseudo-Free library? * in at least 2 occasions, so-called Open Core [1] crippleware has been not only approved for Fedora (which makes sense, as IMHO we should accept everything under a Free license and with no patent issues as a Fedora package), but advertised as a Fedora Feature, which I consider to be completely counterproductive, as it gives free press coverage to such crippleware and sends a message to companies that releasing some crippled shareware version under a Free Software license is enough to get your product advertised as Free or Open Source all over the planet. My complaints about giving free advertising to such crippleware have been entirely ignored. [1] http://www.ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: broken desktop files
Hi Rudolf, a usual request: could you repost including the maintainer names? Thank you, Milos Jakubicek On 2.5.2010 23:30, Rudolf Kastl wrote: Hello, i did a desktop-file-validate on all .desktop files in the current rawhide distro (note rpmfusion too). here is the result of only the errors grepped from a complete check: http://fpaste.org/5p23/ kind regards, Rudolf Kastl p.s. if someone needs help fixing an entry ask away. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 3, 2010 at 1:04 AM, Kevin Kofler kevin.kof...@chello.at wrote: Sir Gallantmon (ニール・ゴンパ) wrote: Though, there are some instances where the prevailing opinion should be ignored, when there is no solid evidence to back it up, e.g. Mono and the like. Indeed, I also think defending freedom is important (and it was part of my campaign). But I've also been unhappy with FESCo's decisions in that domain, e.g.: * libvdpau was approved for Fedora. This is a library which: - only accelerates decoding patent-encumbered MPEG family video codecs. ALL software which uses that is in RPM Fusion, not Fedora, anyway. - has no actual Free Software implementations. It is ONLY implemented by proprietary drivers. So what does Fedora have to gain from this pseudo-Free library? * in at least 2 occasions, so-called Open Core [1] crippleware has been not only approved for Fedora (which makes sense, as IMHO we should accept everything under a Free license and with no patent issues as a Fedora package), but advertised as a Fedora Feature, which I consider to be completely counterproductive, as it gives free press coverage to such crippleware and sends a message to companies that releasing some crippled shareware version under a Free Software license is enough to get your product advertised as Free or Open Source all over the planet. My complaints about giving free advertising to such crippleware have been entirely ignored. [1] http://www.ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html Kevin Kofler Wait, I thought libvdpau had a VA-API backend? And I thought Fedora included a crippled version of mplayer in its repositories? Either way, it is true that VDPAU currently only works with MPEG formats, but nothing says that the library can't be modified to support other formats, does it? If I'm wrong, then shouldn't it be RPM Fusion? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gpsd update
On Fri, Apr 30, 2010 at 2:43 PM, Miroslav Lichvar mlich...@redhat.com wrote: I'd like to update the gpsd package to the latest version 2.94. If there will be no objections, probably sometimes next week. Unfortunately, there were non-trivial API changes since version 2.39 that break most of the dependent packages. The first version with the new API (2.90) was released more than a year ago, so I think the upstreams had enough time to make necessary changes and we shouldn't wait any longer. Packages that currently use libgps.so.18: qtgpsc-0:0.2.3-6.fc12 kdebase-workspace-0:4.4.2-5.fc14 vfrnav-0:0.4-1.fc13 gpsdrive-0:2.10-0.5.pre7.fc13 kdeedu-marble-libs-0:4.4.2-1.fc14 vifir-0:0.4-1.fc12 viking-0:0.9.9-1.fc12 You've missed both geoclue and tangogps off that list. geoclue dropped support for gpsd in F-13 and later so its not really an issue. What of the dependencies have an upstream with a port to the new version of gpsd. If none of them do I think its a little pointless updating just for the sake of it if all dependant packages break. It the majority of them do support the new api then its more worthwhile. I presume this would be just for F-14/rawhide. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Module-ScanDeps/devel perl-Module-ScanDeps.spec,1.26,1.27
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-Module-ScanDeps/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv860
Modified Files:
perl-Module-ScanDeps.spec
Log Message:
- Mass rebuild with perl-5.12.0
Index: perl-Module-ScanDeps.spec
===
RCS file: /cvs/pkgs/rpms/perl-Module-ScanDeps/devel/perl-Module-ScanDeps.spec,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -p -r1.26 -r1.27
--- perl-Module-ScanDeps.spec 7 Dec 2009 00:56:34 - 1.26
+++ perl-Module-ScanDeps.spec 3 May 2010 09:13:49 - 1.27
@@ -1,6 +1,6 @@
Name: perl-Module-ScanDeps
Version:0.95
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Recursively scan Perl code for dependencies
License:GPL+ or Artistic
Group: Development/Libraries
@@ -56,6 +56,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Mon May 03 2010 Marcela Maslanova mmasl...@redhat.com - 0.95-3
+- Mass rebuild with perl-5.12.0
+
* Mon Dec 7 2009 Stepan Kasal ska...@redhat.com - 0.95-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
Re: Super accurate timing?
On 2 May 2010 15:51, mike cloaked mike.cloa...@gmail.com wrote: I saw that there is an interesting ultra precise timing code being developed - to possibly supercede NTP: http://www.cubinlab.ee.unimelb.edu.au/tscclock/ http://queue.acm.org/detail.cfm?id=1773943 Is this code being developed for Fedora at all? If so would there be any interest from Fedora (or Redhat) users if it was available I wonder? Not from my POV but the source is there in your first link Mike so why not package it up? -- Christopher Brown -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gpsd update
On Mon, May 03, 2010 at 10:13:26AM +0100, Peter Robinson wrote: On Fri, Apr 30, 2010 at 2:43 PM, Miroslav Lichvar mlich...@redhat.com wrote: Packages that currently use libgps.so.18: qtgpsc-0:0.2.3-6.fc12 kdebase-workspace-0:4.4.2-5.fc14 vfrnav-0:0.4-1.fc13 gpsdrive-0:2.10-0.5.pre7.fc13 kdeedu-marble-libs-0:4.4.2-1.fc14 vifir-0:0.4-1.fc12 viking-0:0.9.9-1.fc12 You've missed both geoclue and tangogps off that list. geoclue dropped support for gpsd in F-13 and later so its not really an issue. geoclue doesn't seem to support the old API anymore. What of the dependencies have an upstream with a port to the new version of gpsd. If none of them do I think its a little pointless updating just for the sake of it if all dependant packages break. It the majority of them do support the new api then its more worthwhile. xtide is another package that supports only the new API, see https://bugzilla.redhat.com/show_bug.cgi?id=556642 I presume this would be just for F-14/rawhide. Yes. -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Moose/devel perl-Moose.spec,1.55,1.56
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-Moose/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv25474
Modified Files:
perl-Moose.spec
Log Message:
- Mass rebuild with perl-5.12.0
Index: perl-Moose.spec
===
RCS file: /cvs/pkgs/rpms/perl-Moose/devel/perl-Moose.spec,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -p -r1.55 -r1.56
--- perl-Moose.spec 30 Apr 2010 14:45:06 - 1.55
+++ perl-Moose.spec 3 May 2010 10:39:00 - 1.56
@@ -1,7 +1,7 @@
Name: perl-Moose
Summary:Complete modern object system for Perl 5
Version:1.01
-Release:1%{?dist}
+Release:2%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/Moose-%{version}.tar.gz
@@ -112,6 +112,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/Test::Moose*
%changelog
+* Mon May 03 2010 Marcela Maslanova mmasl...@redhat.com - 1.01-2
+- Mass rebuild with perl-5.12.0
+
* Fri Apr 30 2010 Marclea Mašláňová mmasl...@redhat.com 1.01-1
- update
--
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: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Monday 03 May 2010 02:20:51 Kevin Kofler wrote: Hi, You will have noticed by now that my FESCo term is about to expire, that the nomination period for FESCo just closed and that my name does not show up on the list of candidates. No, this is not an accident or negligence, the decision not to run for another term was intentional, for several reasons: * When I ran for election a year ago, one of my reasons for running, and also something I made part of my campaign, was that it shouldn't always be the same people who are sitting on FESCo. We have a much higher number of active contributors than FESCo seats, so it makes sense to see some turnover happening. So it would be very hypocritical from me to attempt to sit another year on FESCo myself, now that I'm myself a FESCo veteran. * I have never been a committee person and have always hated sitting on meetings. I have done it anyway for a year because I believed it to be important for the good of the project. But I'm really fed up of those meetings (I'm feeling burned out) and prefer focusing on more practical, less political areas of Fedora. The fact that I don't feel my presence in those meetings being of much if any use (more on that later) doesn't help either. * When looking back at what happened over the year I've been in office, I have a feeling that I have been able to acheive basically nothing: - The vast majority of votes were either unanimous or 8-1 against me. In both cases, my vote was entirely redundant. Even for more contested votes, my vote hardly ever mattered. - Any attempts to discuss those issues where everyone was against me went nowhere. In most cases, people rushed out a vote without even considering the real issue at hand and then shot down any discussion with we already voted, we want to move on. In those few cases where there actually was a discussion, my position was always dismissed as being ridiculous and not even worth considering, my arguments, no matter how strong, were entirely ignored. - Basically any proposal I filed was systematically shot down. Even things which should be obvious such as: . calling GNOME by its name rather than the generic Desktop or . eliminating the useless bureaucratic red tape of FESCo ratification for FPC guidelines which just wastes everyone's time and constitutes pure process inefficiency got only incomprehension. I have come to the conclusion that it is just plain impossible for a single person to change FESCo's ways and that therefore I am just wasting my time there. * I am very unhappy about FESCo's recent (and not so recent, which were what made me run in the first place) directions. The trend is steady towards bureaucracy and centralization: - Maintainers are continuously being distrusted. It all started with the provenpackager policy, where every single provenpackager has to be voted in by a FESCo majority vote, as opposed to letting any sponsor approve people as provenpackagers as originally planned, or just opening all our packages to everyone as was the case in the old Extras. From there, things pretty much degenerated and we're now at a point where FESCo no longer trusts maintainers to know when an update to the packages they maintain is stable, instead insisting on automatically-enforced bureaucracy which will never be as reliable and effective as a human. The fact that we trust our maintainers used to be one of the core values of the Fedora community. It has been replaced by control-freakiness and paranoia. - All the power in Fedora is being centralized into 2 major committees: the Board and FESCo. FESCo is responsible for a lot of things all taking up meeting time, leading to lengthy meetings and little time for discussion. Many of those things could be handled better in a more decentralized way. Power should be delegated to SIGs and technical committees wherever possible, FESCo should only handle issues where no reponsible subcommittee can be found or where there is disagreement among affected committees. In particular, I suggest that: . FPC guidelines should be passed directly by FPC, only concrete objections should get escalated to FESCo. . membership in packager-sponsors and provenpackager should be handled by the sponsors, with a process to be defined by them (my suggestion: provenpackager should take 1 sponsor to approve and no possibility to object or veto, sponsor should take 3 sponsors to approve and objections can be escalated to FESCo). . features should get approved by the responsible SIG or committee (e.g. FPC for RPM features, KDE SIG for KDE features etc.). The feature wrangler should decide on a SIG to hand the feature to for approval, or even accept features filed directly into approved by the responsible SIG, and FESCo would be responsible only where there is no clearly responsible SIG, or to arbitrate when a SIG is trying to make a
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
2010/5/3 Kevin Kofler kevin.kof...@chello.at: Hi, You will have noticed by now that my FESCo term is about to expire, that the nomination period for FESCo just closed and that my name does not show up on the list of candidates. No, this is not an accident or negligence, the decision not to run for another term was intentional, for several reasons: Hi Kevin, i really like your motivations for being part of the fesco, and voted and supported you even if i dont agree on many of your points. I have the impression many people feels the same frustration like me reading your open letter. However, in your message you could have proposed something that would change the way fesco works, instead of returning on those issues which have been discussed, and voted, following the rules. I mean something like giving each seater the ability to throw a veto once, or discuss and vote issues on separate meetings, or any other different idea you could think of after your experience at the fesco. -- Guido Grazioli guido.grazi...@gmail.com 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: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Hi Kevin, On 3 May 2010 01:20, Kevin Kofler kevin.kof...@chello.at wrote: You will have noticed by now that my FESCo term is about to expire, that the nomination period for FESCo just closed and that my name does not show up on the list of candidates. No, this is not an accident or negligence, the decision not to run for another term was intentional, for several reasons: snip I'm sorry to read this. Dissent is important and I for one believe that someone fighting for the causes you represented was important. As you have admitted, you are not a committee person so I hope you find greater satisfaction in your change of direction. Being an engineer will _always_ be more fun than being a bureaucrat. Regards -- Christopher Brown -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100503 changes
Compose started at Mon May 3 08:15:06 UTC 2010 Broken deps for i386 -- calibre-0.6.47-1.fc14.i686 requires libpodofo.so.0.6.99 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 ghc-cairo-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-cairo-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-cairo-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-cairo-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-cairo-prof-0.10.1.20100110-3.fc13.i686 requires ghc-prof = 0:6.12.1 ghc-gconf-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-gconf-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-gconf-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-gconf-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-gconf-prof-0.10.1.20100110-3.fc13.i686 requires ghc-prof = 0:6.12.1 ghc-gio-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-gio-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-gio-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-gio-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-gio-prof-0.10.1.20100110-3.fc13.i686 requires ghc-prof = 0:6.12.1 ghc-glade-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-glade-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-glade-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-glade-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-glade-prof-0.10.1.20100110-3.fc13.i686 requires ghc-prof = 0:6.12.1 ghc-glib-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-glib-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-glib-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-glib-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-glib-prof-0.10.1.20100110-3.fc13.i686 requires ghc-prof = 0:6.12.1 ghc-gstreamer-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-gstreamer-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-gstreamer-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-gstreamer-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-gstreamer-prof-0.10.1.20100110-3.fc13.i686 requires ghc-prof = 0:6.12.1 ghc-gtk-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-gtk-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-gtk-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-gtk-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-gtk-prof-0.10.1.20100110-3.fc13.i686 requires ghc-prof = 0:6.12.1 ghc-gtkglext-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-gtkglext-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-gtkglext-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-gtkglext-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-gtkglext-prof-0.10.1.20100110-3.fc13.i686 requires ghc-prof = 0:6.12.1 ghc-gtksourceview2-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-gtksourceview2-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-gtksourceview2-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-gtksourceview2-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-gtksourceview2-prof-0.10.1.20100110-3.fc13.i686 requires ghc-prof = 0:6.12.1 ghc-soegtk-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-soegtk-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-soegtk-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-soegtk-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-soegtk-prof-0.10.1.20100110-3.fc13.i686 requires ghc-prof = 0:6.12.1 ghc-svgcairo-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-svgcairo-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-svgcairo-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-svgcairo-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-svgcairo-prof-0.10.1.20100110-3.fc13.i686 requires ghc-prof = 0:6.12.1 ghc-vte-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-vte-devel-0.10.1.20100110-3.fc13.i686 requires ghc = 0:6.12.1 ghc-vte-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-vte-doc-0.10.1.20100110-3.fc13.i686 requires ghc-doc = 0:6.12.1 ghc-vte-prof-0.10.1.20100110-3.fc13.i686 requires ghc-prof =
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Therefore, I will stay in office until the end of my term, but I will not be available for reelection. I would like to thank the people who voted for me last year for their support and apologize to those who would have liked to vote for me this time for not giving them this opportunity. If you would like a KDE SIG person in FESCo, vote for Steven M. Parrish (and vote for Rex Dieter for the Board). But if you want to see the kind of change to FESCo I'd like to see, it'll take a faction of at least 5 people to make it happen. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I'm sorry to hear this as well. Fedora KDE has made great strides and is in my opinion the premiere KDE distro. Thanks for your work! -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Kevin, one way you might help for this election is add some questions to the question that you think are important for voters to know about the candidate. So far only Paul and I have added questions, and I really think the community needs to be more involved here. As a reminder it's at: https://fedoraproject.org/wiki/F14_elections_questionnaire -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Sun, May 02, 2010 at 07:02:23PM -0700, Henrique Junior wrote: Unfortunately, what I have seen over time is that Fedora is changing to something that worries me and that is getting less fun to contribute. I remember the time when I liked to say that fedora was the voice of the community. It's important for individual contributors to have fun, but it's also worth remembering that one person's fun can cause inconvenience to others.[1] We have rules about ABI breaks because we don't want one maintainer to be able to cause distruption that results in several other people having to spend time cleaning up after them. Maybe that's less fun for the library maintainer, but it means that others have less fun overall. The stable packages work is an extension of this. Even if we, as maintainers, have plenty of fun, that's pretty easily wiped out if even a small proportion of our users have to spend time fixing a system that a stable update has broken. And without users who enjoy using and talking about Fedora, the entire exercise is pointless. Fesco isn't introducing rules because it wants our developers to become rule-bound drones, but because it wants our developers to actually be able to see people using what those developers produce and interact with a community of people who *use* Fedora, not just people who develop it. Personally, I think it's reasonable to ask developers to do slightly more work if it means our users have to do significantly less. [1] And I appreciate that I made a mistake with hal-storage in this cycle that caused inconvenience for people maintaining other spins, so I'm not going to claim any kind of perfection in this area -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Great work on F13
Wow, Great work on Fedora 13. I just installed F13 on my R61 Lenovo. It has the familiar feel that I expect with fedora and the installer worked flawlessly and quickly, except it didn't automatically pick up another Linux OS, so I added that in manually to menu.lst Once I installed flash and then added the Fusion repo for multi media and I'm good. Currently the testing updates are causing some dependency issues, so I plan to sit tight and see if that improves. Otherwise, great work. Brilliant OS. And easy to use. Thanks! Carl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100503 changes
Compose started at Mon May 3 09:15:07 UTC 2010 Removed package paperbox Summary: Added Packages: 0 Removed Packages: 1 Modified Packages: 0 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Sir Gallantmon (ニール・ゴンパ) wrote: Wait, I thought libvdpau had a VA-API backend? AFAIK, no, there's only the opposite (a VDPAU backend for VA-API). And VA-API also has no implementation in Free drivers other than a proof of concept for the intel driver which: * only supports MPEG 2, no MPEG 4, * is not a true hardware implementation, but implemented as shaders, and thus subject to software patents, which makes it unshippable in Fedora. And I thought Fedora included a crippled version of mplayer in its repositories? We actually don't. Either way, it is true that VDPAU currently only works with MPEG formats, but nothing says that the library can't be modified to support other formats, does it? AFAIK, all of the primitives supported are operations which are used only in MPEG (most of them patented). Acceleration for Theora would have to be done with a completely different API, and probably exclusively based on shaders as no existing graphics card has a dedicated video unit with Theora support. So the best way to accelerate Theora is probably to ignore those APIs entirely and work directly with OpenGL shaders. Those APIs are focused on what GPU video units do in hardware and that's just MPEG. If I'm wrong, then shouldn't it be RPM Fusion? That's my point! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Kevin Kofler wrote: I do not wish to stand for such a committee anymore Kevin, thank you for your attempts and for raising attention on the difficulties you have faced. If some of the time you save by not doing meetings will be spent on additional excellent technical contributions of yours, Fedora will actually gain something. So, if your decision is both positive for you and positive for Fedora, there is nothing to be too sad about. Respectfully, -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Super accurate timing?
Christopher Brown wrote: On 2 May 2010 15:51, mike cloaked mike.cloa...@gmail.com wrote: I saw that there is an interesting ultra precise timing code being developed - to possibly supercede NTP: http://www.cubinlab.ee.unimelb.edu.au/tscclock/ http://queue.acm.org/detail.cfm?id=1773943 Is this code being developed for Fedora at all? If so would there be any interest from Fedora (or Redhat) users if it was available I wonder? Not from my POV but the source is there in your first link Mike so why not package it up? Is a kernel patch needed? -- Roberto Ragusamail at robertoragusa.it -- 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 Tom spot Callaway tcall...@redhat.com changed: What|Removed |Added CC||tcall...@redhat.com Blocks|182235(FE-Legal)| --- Comment #10 from Tom spot Callaway tcall...@redhat.com 2010-05-03 10:29:06 EDT --- For this package, this is the appropriate entry: # Some code was copied from Unix::Processors, which is LGPLv3 or Artistic 2.0 # The rest of the code is under the standard Perl license (GPL+ or Artistic) License: (GPL+ or Artistic) and (LGPLv3 or Artistic 2.0) Lifting FE-Legal. -- 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: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Matthew Garrett wrote: The stable packages work is an extension of this. Even if we, as maintainers, have plenty of fun, that's pretty easily wiped out if even a small proportion of our users have to spend time fixing a system that a stable update has broken. And without users who enjoy using and talking about Fedora, the entire exercise is pointless. Fesco isn't introducing rules because it wants our developers to become rule-bound drones, but because it wants our developers to actually be able to see people using what those developers produce and interact with a community of people who *use* Fedora, not just people who develop it. Personally, I think it's reasonable to ask developers to do slightly more work if it means our users have to do significantly less. You make it look as if I was out to break people's systems, when actually what I'm arguing for is: * allowing important bugfixes to bypass testing IN SOME CASES (i.e. if they aren't too risky/non-trivial), in order to get very needed bugfixes (e.g. regression fixes) out to our users faster and make them suffer LESS, * allowing trivial changes to bypass testing IN SOME CASES (i.e. if they are important/useful enough) because there's hardly any way they can break anything, in order to get ultra-low-risk improvements out to our users faster and make them suffer LESS, * allowing new upstream releases as updates IF AND ONLY IF THEY DON'T BREAK THINGS (with a very precise definition of break things I don't want to repeat again) and after sufficient regression testing and fixing, bringing both new features and bugfixes to our users without the breakage of an unstable distribution such as Rawhide and thus making them suffer LESS. Please stop attacking a strawman! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Super accurate timing?
On 3 May 2010 15:29, Roberto Ragusa m...@robertoragusa.it wrote: Christopher Brown wrote: On 2 May 2010 15:51, mike cloaked mike.cloa...@gmail.com wrote: I saw that there is an interesting ultra precise timing code being developed - to possibly supercede NTP: http://www.cubinlab.ee.unimelb.edu.au/tscclock/ http://queue.acm.org/detail.cfm?id=1773943 Is this code being developed for Fedora at all? If so would there be any interest from Fedora (or Redhat) users if it was available I wonder? Not from my POV but the source is there in your first link Mike so why not package it up? Is a kernel patch needed? Sort of. You can run the userland daemon using tsc or hpet clocksources (I think the latter is preferable) so probably the best route is to get the daemon packaged and then ask on the kernel list if they will carry the patch, though this would probably be rejected unless there was a very good reason. Maybe try and get it pushed in /staging upstream...? -- Christopher Brown -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 03, 2010 at 04:34:13PM +0200, Kevin Kofler wrote: You make it look as if I was out to break people's systems Actually, I didn't intend to say anything about you. My point was that any increased bureaucracy has not been generated with the intention to reduce the amount of fun that developers have. If developers /do/ feel that their ability to have fun in Fedora has been reduced, I hope that in the long run that that gets more than compensated for by more positive feedback from our users and fewer angry complaints when people's systems break. * allowing important bugfixes to bypass testing IN SOME CASES (i.e. if they aren't too risky/non-trivial), in order to get very needed bugfixes (e.g. regression fixes) out to our users faster and make them suffer LESS, If updates cause regressions in functionality then that indicates that our update testing process failed. The answer to that is to fix the update testing process, not bypass it. * allowing trivial changes to bypass testing IN SOME CASES (i.e. if they are important/useful enough) because there's hardly any way they can break anything, in order to get ultra-low-risk improvements out to our users faster and make them suffer LESS, There is no change too trivial to not require testing. The software industry is full of examples of obviously correct fixes causing hideous breakage. Most developers get to learn that the hard way at some point, but it's still preferable to put processes in place to protect users from accidents. * allowing new upstream releases as updates IF AND ONLY IF THEY DON'T BREAK THINGS (with a very precise definition of break things I don't want to repeat again) and after sufficient regression testing and fixing, bringing both new features and bugfixes to our users without the breakage of an unstable distribution such as Rawhide and thus making them suffer LESS. Regardless of your definition, there were several users who felt that the KDE 4.4 update broke things. That's a problem. It makes us look bad. We'd like to avoid those users being unhappy. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-MooseX-Params-Validate/devel perl-MooseX-Params-Validate.spec, 1.14, 1.15
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-MooseX-Params-Validate/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv19050
Modified Files:
perl-MooseX-Params-Validate.spec
Log Message:
- Mass rebuild with perl-5.12.0
Index: perl-MooseX-Params-Validate.spec
===
RCS file:
/cvs/pkgs/rpms/perl-MooseX-Params-Validate/devel/perl-MooseX-Params-Validate.spec,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -p -r1.14 -r1.15
--- perl-MooseX-Params-Validate.spec14 Mar 2010 19:07:51 - 1.14
+++ perl-MooseX-Params-Validate.spec3 May 2010 13:34:48 - 1.15
@@ -1,7 +1,7 @@
Name: perl-MooseX-Params-Validate
Summary:Extension of Params::Validate using Moose's types
Version:0.13
-Release:1%{?dist}
+Release:2%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/MooseX-Params-Validate-%{version}.tar.gz
@@ -65,6 +65,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Mon May 03 2010 Marcela Maslanova mmasl...@redhat.com - 0.13-2
+- Mass rebuild with perl-5.12.0
+
* Sun Mar 14 2010 Chris Weyl cw...@alumni.drew.edu 0.13-1
- update by Fedora::App::MaintainerTools 0.006
- PERL_INSTALL_ROOT = DESTDIR
--
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: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Matthew Garrett wrote: My point was that any increased bureaucracy has not been generated with the intention to reduce the amount of fun that developers have. Let me jump in just to say that I'm not a developer/packager, but it was my intention to become a contributor for Fedora. What scared me was just the huge level of bureaucracy. Submitting patches to the kernel 10 years ago was actually simpler than packaging a trivial rpm for Fedora is today. This is why I decided to not by a packager. I just try to help guys on the lists and open bugs (often ignored, I must add). Best regards. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, 2010-05-03 at 02:20 +0200, Kevin Kofler wrote: But if you want to see the kind of change to FESCo I'd like to see, it'll take a faction of at least 5 people to make it happen. Surely this is the point: if there are not sufficient candidates with a particular point of view, that's hardly FESCo's (or anyone else's) fault. I think it's a bit disingenuous to talk about prevailing opinion of the mailing list otherwise; to me a lot of the discussion looks an awful lot like a vocal minority, and some of these issues (e.g., confusing the name of the Desktop spin with others) have been pretty much done to death and certainly aren't obvious to me. Cheers Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
I'm sorry you are unhappy. I can only speak for myself here, but: - I don't distrust our maintainers. I very much value the work they do and without them we would have no Fedora. However, I also want to help them do the right thing for our users (who I also would like to see happy). I'm open to ideas on how to reduce 'red tape' for them, while increasing the standard of packages for our users. I know you have many such ideas, but I don't agree that we should not have testing or help our maintainers find problems before our users get the package. - I read this list every day, and am very mindful of feedback from developers. Any communication media is good, IMHO. My mailbox is also always open. I think many become discouraged with the mailing list these days because a few people reply to EVERY SINGLE POST with no new thoughts or information. Make a reasoned argument, wait and reply (at a high level) to feedback. Posting a reply to every post repeating yourself just makes less people able or interested in following the discussion. - I would like to hope that we can look beyond ourselves. We shouldn't be looking at My packages or My Desktop. We should all be working for a Fedora that we can be proud of our users using. We should be consistent about how much testing we do and when we update things so ALL our users will know whats going on. Can we Improve things? I absolutely think so, but change takes time, well reasoned argument, and people willing to do the work to make it happen. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, 2010-05-03 at 14:01 +0100, Matthew Garrett wrote: [1] And I appreciate that I made a mistake with hal-storage in this cycle that caused inconvenience for people maintaining other spins, so I'm not going to claim any kind of perfection in this area Which just adds reason to why we are doing necessary karma and automated testing, because humans make mistakes, no matter how much fun or not fun they are having. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Matthew Garrett wrote: If updates cause regressions in functionality then that indicates that our update testing process failed. The answer to that is to fix the update testing process, not bypass it. Your assumption there is that it is possible for a testing process to catch ALL regressions. I couldn't disagree more, and so far evidence has proven me right. For example, the critical path process, upon which the new update process is modeled, failed to catch the regressions in non-GNOME spins you caused by splitting out hal-storage-addon to a subpackage. NO amount of testing will EVER catch ALL regressions before they hit users. There will ALWAYS be a need for a way to fasttrack regression fixes! (And in fact a direct stable push is how we fixed the KDE spin.) There is no change too trivial to not require testing. The software industry is full of examples of obviously correct fixes causing hideous breakage. Most developers get to learn that the hard way at some point, but it's still preferable to put processes in place to protect users from accidents. While you do have a point in principle, in practice, our maintainers are quite good at judging the risk of their changes, and often the risk is so extremely low that it is far outweighed by the benefits of getting the change out ASAP. This is always a tradeoff. And 100% bugfreeness doesn't exist anyway, testing is NOT going to catch all issues either. There is a point at which the risk is so low that other real-world risks such as hardware failure are several orders of magnitude larger. So why bother worrying about such a low risk? Regardless of your definition, there were several users who felt that the KDE 4.4 update broke things. That's a problem. It makes us look bad. We'd like to avoid those users being unhappy. It is true that KDE 4.4 wasn't as smooth as we had hoped for some users. This is strange, because for most of us, things just worked! I'll note that KDE 4.4 got A LOT of testing, and all testing indicated that we are good to go. We would NOT have pushed this out if we hadn't been convinced that our update is regression-free. This is just yet another proof that testing will NEVER catch ALL issues. What happened was that: * the Akonadi migration seems to be fragile in some ways, and choke on various corner cases, often of unknown nature. This did not show up during testing. For most of the issues, KDE UserBase offers workarounds. * Akonadi needs manual configuration to work with NFS home directories. We were not aware of this when we pushed 4.4 out and none of our testers was using this configuration. This issue can be worked around by the user by following the instructions on KDE UserBase, which detail the required manual configuration. * we underestimated the annoyance factor of a warning Akonadi pops up if Nepomuk is not running. (This warning is mostly harmless at this time. It just means that some Akonadi functionality is disabled.) This has been remedied by a kde-settings update which enables Nepomuk by default. It shall however be noted that the Akonadi migration is a one-time event (well, there will be a second part in KDE 4.5, but once that's done too, the migration problem is solved), so I don't expect this kind of issues in future KDE upgrades. (In fact, we had NO similar complaints for our previous 4.1, 4.2 and 4.3 upgrades.) And IMHO most of the blame for the roughness of the Akonadi migration goes to upstream KDE. If we had been aware of the issues this is causing, we would have evaluated alternatives (e.g. staying on kdepim 4.3, or shipping the pre-Akonadi kdepim-enterprise4 branch). But all the feedback we got at the time of the decision pointed to the migration being trouble-free, and in fact I still believe that for the vast majority of our users, it was. You only hear from the handful people who ran into trouble. And we also need to weigh those against the people for whom KDE 4.4 fixed their issues. It has fixed thousands of bugs! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Jesse Keating wrote: On Mon, 2010-05-03 at 14:01 +0100, Matthew Garrett wrote: [1] And I appreciate that I made a mistake with hal-storage in this cycle that caused inconvenience for people maintaining other spins, so I'm not going to claim any kind of perfection in this area Which just adds reason to why we are doing necessary karma and automated testing, because humans make mistakes, no matter how much fun or not fun they are having. Except karma requirements (which were in force due to the critical path process) did NOT prevent this particular regression, nor would a 1 week minimum in testing requirement have prevented it (the update spent 8 days in testing). That process DOES NOT WORK. It just adds extra bureaucracy and delays the fix for the regression. (But thankfully, direct stable pushes are still possible for KDE packages, which allowed us to do one to fix this regression quickly.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 03, 2010 at 02:20:51AM +0200, Kevin Kofler wrote: [...] Kevin, I was rooting for you, and I particularly agree with you on the issues of trusting maintainers and devolving power down to packaging groups and SIGs. It was very disheartening also to see so many votes going N-to-1. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Alex Hudson wrote: I think it's a bit disingenuous to talk about prevailing opinion of the mailing list otherwise; to me a lot of the discussion looks an awful lot like a vocal minority I think it's quite cheap to write off the mailing list consensus as a vocal minority with no evidence for such a conclusion. and some of these issues (e.g., confusing the name of the Desktop spin with others) have been pretty much done to death and certainly aren't obvious to me. Why should we not call the GNOME spin, and the GNOME desktop in general, by its name? GNOME is just A desktop, it's NOT the desktop. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: popularity package context on fedora
On Sun, 2 May 2010 17:25:10 +0200 yersinia yersinia.spi...@gmail.com wrote: Would be interesting to have in Fedora something like this http://popcon.debian.org/ ? Look interesting from a QA point of view. It's been suggested many times before, but no one has really stepped forward to champion it. ;) There is an rpm version being worked on by an OpenSUSE person: http://gitorious.org/opensuse/popcorn Something would need to be packaged, tested, etc. Then the problem becomes what data to store, how to store it. It's going to be a vast amount of data, and we would need some server to store it, policies around when to drop entries, etc. Not that I think it's a bad idea, It just needs a group of determined people to work on and make it happen. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Once upon a time, Kevin Kofler kevin.kof...@chello.at said: Matthew Garrett wrote: snip Can we PLEASE not rehash all of this again? Thanks a lot Kevin; you showed a lot of class trying to stir up the same arguments that you stirred up before. Maybe the reason you lost votes is that a lot of people just don't agree with you; pouting about that won't help anything. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Kevin Fenzi wrote: - I don't distrust our maintainers. I very much value the work they do and without them we would have no Fedora. However, I also want to help them do the right thing for our users (who I also would like to see happy). I'm open to ideas on how to reduce 'red tape' for them, while increasing the standard of packages for our users. I know you have many such ideas, but I don't agree that we should not have testing or help our maintainers find problems before our users get the package. Helping our maintainers is one thing, FORCING them to work the way FESCo wants is another. And sadly, FESCo's update policy does the latter, NOT the former. Helping means ADVISING people, not REQUIRING them to follow some bureaucratic process. Update guidelines should be purely informative, not hardcoded in Bodhi as you, the other 8 FESCo members, decided (over my strong dissent). And again, it is simply NOT TRUE that I'm arguing that we should not have testing. I'm arguing that SOME updates should, at the maintainer's discretion, bypass testing because the urgency largely outweighs the risk (be it because the risk is extremely small, because the urgency is extremely high or both). The maintainer is in the best position to make such a call. I DO complain in the rare occasions where some update which breaks things is pushed directly to stable. But it means the maintainer screwed up and we need to teach the maintainer how to avoid such a mistake the next time, not to outright ban all direct stable pushes, many of which are legitimate. (In the cases I complained about, it was always quite obvious to me, and I believe to any sufficiently experienced maintainer, that the decision to push to stable was inappropriate, even without the hindsight.) But I ALSO complain when an urgent fix is NOT pushed to stable in a timely manner, sitting around in testing for no good reason. - I read this list every day, and am very mindful of feedback from developers. Any communication media is good, IMHO. My mailbox is also always open. I think many become discouraged with the mailing list these days because a few people reply to EVERY SINGLE POST with no new thoughts or information. Make a reasoned argument, wait and reply (at a high level) to feedback. Posting a reply to every post repeating yourself just makes less people able or interested in following the discussion. Then why did you not take such feedback into account when voting? Several people, including some very experienced high-profile packagers, objected to the new update policies. They have been ignored, by you and by the other 7 members. - I would like to hope that we can look beyond ourselves. We shouldn't be looking at My packages or My Desktop. We should all be working for a Fedora that we can be proud of our users using. We should be consistent about how much testing we do and when we update things so ALL our users will know whats going on. I'm sorry, but I don't agree with you at all about this kind of bureaucracy being the way to make our users happy. I strongly believe our maintainers are the ones who know best how to make their users happy, in particular, what to push to users of the stable updates and when. As for consistency: our users have explicitly asked for non-conservative, or even adventurous, updates, see Adam Williamson's poll, so I believe the way to make our users happy while being consistent is to consistently push new versions as updates unless there's a reason not to (and I already detailed possible reasons not to push an update on several occasions, so I won't do it again). But of course this should also be an indicative policy and ultimately the maintainer's decision, as they know best whether there's a reason not to push the update. We should just make it clear that the general policy is for new versions to be pushed unless there's a reason not to. Can we Improve things? I absolutely think so, but change takes time, well reasoned argument, and people willing to do the work to make it happen. True change mainly takes a change in attitude in FESCo. Otherwise all the change we'll get will be towards more and more bureaucracy. :-( The fact that a change requires implementation work is a strong hint that the change may be technobureaucratic. Most non-bureaucratic approaches require little to no work to implement. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 03, 2010 at 07:34:28PM +0200, Kevin Kofler wrote: Why should we not call the GNOME spin, and the GNOME desktop in general, by its name? GNOME is just A desktop, it's NOT the desktop. It's the desktop with the most development and integration work performed in the distribution, and hence it gets to be the default. This is, of course, unfair. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: Bug 586571 - DS Console shows escaped DNs
There were a few more problems with my previous patches. The console was not able to handle some cases where we using a DN value as the value in an RDN, in both the base console and in the ds-console packages. Also, I moved a lot of DN handling code from the ds-console package DSUtil into the base console package LDAPUtil, so that the base console could handle DN cases like these. Unfortunately, until the new base console is available everywhere, a user could find him/herself in a situation where they are managing a remote new DS on a machine that uses the old base console. So the DSUtil class will attempt to find and use the new methods from LDAPUtil if available, or fallback to the local implementation in DSUtil. https://bugzilla.redhat.com/show_bug.cgi?id=586571 https://bugzilla.redhat.com/attachment.cgi?id=411075action=diff https://bugzilla.redhat.com/attachment.cgi?id=411077action=diff https://bugzilla.redhat.com/attachment.cgi?id=411075action=edit https://bugzilla.redhat.com/attachment.cgi?id=411077action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 3, 2010 at 8:00 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Kevin Kofler kevin.kof...@chello.at said: Matthew Garrett wrote: snip Can we PLEASE not rehash all of this again? Generally agreed. Maybe the reason you lost votes is that a lot of people just don't agree with you Doesn't automatically mean they are right. And they aren't right if it comes to the Desktop. They just like it and don't want to change it. For whatever reason. pouting about that won't help anything. To not speak up as well not. Arguments are arguments, even the other side don't like them, doesn't make them smaller. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, 2010-05-03 at 19:34 +0200, Kevin Kofler wrote: Alex Hudson wrote: I think it's a bit disingenuous to talk about prevailing opinion of the mailing list otherwise; to me a lot of the discussion looks an awful lot like a vocal minority I think it's quite cheap to write off the mailing list consensus as a vocal minority with no evidence for such a conclusion. No, not really. Consensus of the list is not the same as consensus of the participants of a particular discussion - if anything, the evidence has to come the other way that a particular discussion does in any way reflect the balance of developer opinion. I'm not saying that opinions on the list are worthless; quite the contrary. I just don't think it constitutes evidence one way or another as to the balance of opinion of the members of the list. and some of these issues (e.g., confusing the name of the Desktop spin with others) have been pretty much done to death and certainly aren't obvious to me. Why should we not call the GNOME spin, and the GNOME desktop in general, by its name? This has been done to death, surely? For one, I don't think applications should get chosen for the Desktop spin for being GNOME: e.g., I wouldn't choose Epiphany over Firefox, even though it's more lightweight, better integrated, etc. Prioritizing non-GNOME applications doesn't seem right for something you would label GNOME spin. Cheers Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: popularity package context on fedora
It's been suggested many times before, but no one has really stepped forward to champion it. ;) There is an rpm version being worked on by an OpenSUSE person: http://gitorious.org/opensuse/popcorn Something would need to be packaged, tested, etc. Then the problem becomes what data to store, how to store it. It's going to be a vast amount of data, and we would need some server to store it, policies around when to drop entries, etc. Not that I think it's a bad idea, It just needs a group of determined people to work on and make it happen. ;) kevin i have looked at the source code (C server side / Python client side), it uses libtdb [1] as storage back-end (a plain text format) , i think that sqlite is better, and you can port it to other DBMS such as Postgres or MySQL [1] http://tdb.samba.org But how it can be integrated in Fedora, by writing yum plug-in ? -- Athmane Madjoudj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 3, 2010 at 8:08 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Mon, May 03, 2010 at 07:34:28PM +0200, Kevin Kofler wrote: Why should we not call the GNOME spin, and the GNOME desktop in general, by its name? GNOME is just A desktop, it's NOT the desktop. It's the desktop with the most development and integration work performed in the distribution, and hence it gets to be the default. This is, of course, unfair. No, it's not unfair. That are just facts. And it can and should stay as the default as long as the GNOME desktop gets the most development and integration. It's just about Desktop. It's the GNOME-Desktop, since there are more. If the GNOME guys like it or not, they are not alone ;) -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 libtool broken by gcc update
F-13 builds requiring libtool are now failing with DEBUG util.py:256: libtool-2.2.6-18.fc13.x86_64 from build has depsolving problems DEBUG util.py:256:-- Missing Dependency: gcc = 4.4.3 is needed by package libtool-2.2.6-18.fc13.x86_64 (build) DEBUG util.py:256: Error: Missing Dependency: gcc = 4.4.3 is needed by package libtool-2.2.6-18.fc13.x86_64 (build) DEBUG util.py:256: You could try using --skip-broken to work around the problem apparently as a result of the fact that gcc was updated to 4.4.4 over the weekend. Could we have a fix for this ASAP, please? And why weren't there loud bleats from broken-dependencies checking? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 3, 2010 at 3:07 AM, Alex Hudson fed...@alexhudson.com wrote: I think it's a bit disingenuous to talk about prevailing opinion of the mailing list otherwise; to me a lot of the discussion looks an awful lot like a vocal minority, Be careful about meeting subjective opinion with differing subjective opinion. How many individuals vote in the FESCO election? How man individuals chime in on heated devel-list threads? When the voting population is itself a minority of a larger community its difficult to know what minority opinion is big enough to be representative of general thought. it could be argued that the voting record is itself another vocal minority opinion. The general election format that FESCO uses does lend itself to exactly the sort of problems Kevin thinks he's seeing.. even in the brick and mortar world. There's no defined constituencies for any candidate..no topological separation of the voting demographic that helps you point to a specific member of the committee as your representative. It can lead to a sense of disconnectedness..even in the brick and mortar world...especially when there is a strong expectation of representative accountability. But I think your entirely correct about an organized slate of candidates being the correct path to take to address the expressed general concern. This is typically how changes in direction in brick and mortar general election scenarios are carried forward. An organized slate of candidates with a stated agenda. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 libtool broken by gcc update
On Mon, May 03, 2010 at 02:30:54PM -0400, Tom Lane wrote: F-13 builds requiring libtool are now failing with DEBUG util.py:256: libtool-2.2.6-18.fc13.x86_64 from build has depsolving problems DEBUG util.py:256:-- Missing Dependency: gcc = 4.4.3 is needed by package libtool-2.2.6-18.fc13.x86_64 (build) DEBUG util.py:256: Error: Missing Dependency: gcc = 4.4.3 is needed by package libtool-2.2.6-18.fc13.x86_64 (build) DEBUG util.py:256: You could try using --skip-broken to work around the problem apparently as a result of the fact that gcc was updated to 4.4.4 over the weekend. Could we have a fix for this ASAP, please? And why weren't there loud bleats from broken-dependencies checking? gcc-4.4.4-1.fc13 has just been tagged temporarily into dist-f13-override so that new libtool could be built. Likely you tried to built during that short window or NewRepo has been too slow after it has been untagged from dist-f13-override already. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 libtool broken by gcc update
Tom Lane wrote, at 05/04/2010 03:30 AM +9:00:
F-13 builds requiring libtool are now failing with
DEBUG util.py:256: libtool-2.2.6-18.fc13.x86_64 from build has depsolving
problems
DEBUG util.py:256:-- Missing Dependency: gcc = 4.4.3 is needed by
package libtool-2.2.6-18.fc13.x86_64 (build)
DEBUG util.py:256: Error: Missing Dependency: gcc = 4.4.3 is needed by
package libtool-2.2.6-18.fc13.x86_64 (build)
DEBUG util.py:256: You could try using --skip-broken to work around the
problem
apparently as a result of the fact that gcc was updated to 4.4.4 over
the weekend. Could we have a fix for this ASAP, please? And why
weren't there loud bleats from broken-dependencies checking?
regards, tom lane
$ TZ=UTC koji list-tag-history --build=gcc-4.4.4-1.fc13
Sat May 1 00:57:24 2010: Tagged gcc-4.4.4-1.fc13 with
dist-f13-updates-candidate [still active]
Mon May 3 15:58:06 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-override
Mon May 3 17:37:31 2010: Untagged gcc-4.4.4-1.fc13 from dist-f13-override
The dependency was broken only for this 2 hours (perhaps to rebuild libtool for
gcc 4.4.4).
Now:
$ koji latest-pkg dist-f13-build gcc libtool
Build Tag Built by
gcc-4.4.3-18.fc13 dist-f13 jakub
libtool-2.2.6-18.fc13 dist-f13 jakub
Once newrepo is created, dependency will be recovered again.
Regards,
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 3, 2010 at 10:00 AM, Chris Adams cmad...@hiwaay.net wrote: Thanks a lot Kevin; you showed a lot of class trying to stir up the same arguments that you stirred up before. Maybe the reason you lost votes is that a lot of people just don't agree with you; pouting about that won't help anything. There's no reason to paint this as a sour grapes issue. I'm pretty sure Kevin strongly believes that some decision-making is not in the best interest of the project... its not sour grapes to be persistent in that belief. It's difficult being cast into the role of loyal opposition (whether by choice or by calculation.) especially when you don't enjoy that role and being in that position burns you out. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 3, 2010 at 2:02 PM, Kevin Kofler kevin.kof...@chello.at wrote: Kevin Fenzi wrote: - I read this list every day, and am very mindful of feedback from developers. Any communication media is good, IMHO. My mailbox is also always open. I think many become discouraged with the mailing list these days because a few people reply to EVERY SINGLE POST with no new thoughts or information. Make a reasoned argument, wait and reply (at a high level) to feedback. Posting a reply to every post repeating yourself just makes less people able or interested in following the discussion. Then why did you not take such feedback into account when voting? Several people, including some very experienced high-profile packagers, objected to the new update policies. They have been ignored, by you and by the other 7 members. Whoosh. Kevin Kofler -- there was an interesting msg in that paragraph. Some of the points you make are valid, and worthy of discussion. Reasonable people may disagree on them, and you'll have to find a way to work within a community where people might disagree on some things with you. Without a particular need to repeat, restate and re-explain your points 100 times, with escalating hyperbole. You are good communicating, so (at least I, perhaps we) generally get what you mean, in your first post. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 libtool broken by gcc update
Jakub Jelinek ja...@redhat.com writes: gcc-4.4.4-1.fc13 has just been tagged temporarily into dist-f13-override so that new libtool could be built. Likely you tried to built during that short window or NewRepo has been too slow after it has been untagged from dist-f13-override already. I see. It seems like this indicates a rather fundamental shortcoming in the -override tagging mechanism. If random other builds that happen to be submitted at the wrong time will see the overridden packages, what happens to reproducibility? Can't we either fix it so that only the specific desired builds see the override, or just prevent unrelated builds from happening during the window? This is surely not going to be the last undesired failure if things stay like this. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Sun, May 2, 2010 at 6:20 PM, Kevin Kofler kevin.kof...@chello.at wrote: . - The prevailing opinion of the electorate of Fedora contributors keeps getting ignored. Feedback on the Fedora devel mailing list is never seen as in any way binding, it's often dismissed as noise or trolling. The predominant opinion in FESCo is you voted for us, now we get to do whatever we want, which is flawed in many ways: . It assumes there were true alternatives to vote for instead. This assumption does not look true to me. . It assumes the voters were aware of the positions of all the candidates. I'm fairly sure this was not the case. While I appreciate what has been done in an attempt to solve this issue (questionnaire, townhalls), this has proven by far insufficient to build an opinion on the candidates. I think there's a reason representative democracies normally work with parties/factions and I think something like that might help a lot, depending on what kind of factions would show up. . It assumes representative democracy is a well-working model in the first place, especially in its most hardcore form (now we get to do whatever we want). I believe elected representatives should really REPRESENT the people who voted them. I realize politicians aren't doing that, but are they really a good model to follow? As I have pointed out in both public and private emails to you 1) This is not a representative democracy. For one thing the voting method used does not promote the type of 'democracy' you are expecting. At best people are voted against by not getting points put to them.. not voted for. Range voting build out a 'statistical' average of what it considered the best candidate(s) versus anyone voting for or against someone/something. It like the Debian voting methods are meant to be 'more fair' and thus to remove the emotional baggage of 'voting for/against'. EG if you win a seat you were voted by a vast majority of people and have to represent not just your views but those that have no relation to yours. 2) This is not a federation or a representative democracy. It is at best a limited meritocracy and at worst a constitutional monarchy. You and many others keep thinking that some how by saying it is something over and over again it will somehow become that. It takes a lot more than thousands of repeated emails to change reality. It takes actual thought and hard work on coming up with what you want, and then compromising at some point. 3) Due to the fact that voting is not required for continual 'good-standing' membership in Fedora.. the vast majority of people do not vote. People voted in such 'democracies' are supposed to not only represent those that voted for them, but those who did not vote at all. At times the best anyone can do is just vote what they think best and hope that if they screw it up too badly they will get voted out next time. You and others want something different? Then start building a constitution, framework, government that you want, but realize that humans are a hard problem. They are mean, lazy, bigotted monsters that can also be noble, hardworking, humane angels sometimes at the same time. -- 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: popularity package context on fedora
On Mon, 2010-05-03 at 19:20 +0100, Athmane Madjoudj wrote: It's been suggested many times before, but no one has really stepped forward to champion it. ;) There is an rpm version being worked on by an OpenSUSE person: http://gitorious.org/opensuse/popcorn Something would need to be packaged, tested, etc. Then the problem becomes what data to store, how to store it. It's going to be a vast amount of data, and we would need some server to store it, policies around when to drop entries, etc. Not that I think it's a bad idea, It just needs a group of determined people to work on and make it happen. ;) i have looked at the source code (C server side / Python client side), it uses libtdb [1] as storage back-end (a plain text format) TDB is not plain text it's a key/value store, like BDB/etc. , i think that sqlite is better, and you can port it to other DBMS such as Postgres or MySQL [1] http://tdb.samba.org My guess is that sqlite would be nicer though, as I'd imagine you wouldn't want to store just key/values. But how it can be integrated in Fedora, by writing yum plug-in ? I can't think why you'd want a plugin, but you'd probably need to use the yum API ... at least so you could get data out of yumdb. The client side should be truly trivial though. Dumping the installed packages, which repos. they came from and the reason for their install ... is probably like 10 lines of yum code. If someone is doing this work, they'd probably do a bit more to get more info. ... but again, it would be trivial in comparison to the work needed on the server side (and to get people to install it etc.) -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: popularity package context on fedora
Am Montag, den 03.05.2010, 11:52 -0600 schrieb Kevin Fenzi: On Sun, 2 May 2010 17:25:10 +0200 yersinia yersinia.spi...@gmail.com wrote: Would be interesting to have in Fedora something like this http://popcon.debian.org/ ? Look interesting from a QA point of view. It's been suggested many times before, but no one has really stepped forward to champion it. ;) There is an rpm version being worked on by an OpenSUSE person: http://gitorious.org/opensuse/popcorn Something would need to be packaged, tested, etc. Then the problem becomes what data to store, how to store it. It's going to be a vast amount of data, and we would need some server to store it, policies around when to drop entries, etc. Not that I think it's a bad idea, It just needs a group of determined people to work on and make it happen. ;) Wouldn't it be easier to let MirrorManager do that? This way each mirror can save a counter per package and publish them statically on the server side. To get a total amount of the data, all counter files from all servers needs to be collected and that's it. Maybe a bit less data, than collecting anything like in smolt... Of course, this does not say 'how many computers out there have package X'. Maybe it fails and one needs to download a package twice and so on. But I think this would be a first great approximation. Comments? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: popularity package context on fedora
On Sun, May 2, 2010 at 7:25 AM, yersinia yersinia.spi...@gmail.com wrote: Look interesting from a QA point of view. How exactly is this interesting from a QA pov in Fedora? Smolt profiles I can understand being useful for QA because it gives us some ability to look for commonalities when troubleshooting hardware problems. I'm really not sure what installed packaging information gives up in terms of helping any QA process. Care to explain your thoughts on this? Debian uses popcon for a specific reason...to help in ordering the packages on their install media sets. I'm not sure we are interested in that sort of help...Debian releases are a vastly different timescale than ours. We aren't going to adapt the media contents based on popcon every 6 months.. I don't see us making a commitment to use the data in the same way Debian uses it..so I'm left scratching my head on how we will use it at all. Before I would be personally willing to commit time on seeing this implemented I would need to know what the perceived value is. I love datamining...but I'm not a big fan of collecting data without first having a stated reason for the collection of that information. If we are going to collect it I expect it to be used and I expect the initial use to be stated before we start collecting it. And more generally speaking. I'm not keen on collecting information unless there is a potential direct benefit for users who are providing the information. So the reason for collection needs to be sufficiently...user-focused...and not just because we want metrics. Collecting the information has to be used primarily to help us provide a better user experience or I'm going to get really pissy about it. Fair warning. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: popularity package context on fedora
On 2010-05-03 09:25:06 PM, Thomas Spura wrote: Wouldn't it be easier to let MirrorManager do that? This way each mirror can save a counter per package and publish them statically on the server side. To get a total amount of the data, all counter files from all servers needs to be collected and that's it. Maybe a bit less data, than collecting anything like in smolt... Of course, this does not say 'how many computers out there have package X'. Maybe it fails and one needs to download a package twice and so on. But I think this would be a first great approximation. I don't think yum requests packages specifically from mirrormanager. It gets a mirror URL from mirrormanager, then downloads everything else directly from the mirror that it gets back. Thanks, Ricky pgpcK9aBqeHiI.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Unable to get wlan0 to fire
Hi, Not sure on which package I need to bugzilla this under. I have a feeling it should be NetworkManager, but I'd like to check as it may be down to a PolicyKit failure (or even dbus). My laptop is not firing up the wireless network. When I try and bring it up from the command line I'm getting Error org.freedesktop.NetworkManagerSettings.InvalidConnection: ifcfg file '/etc/sysconfig/network-scripts/ifcfg-wlan0' unknown I've checked and the above file exists. Googling hasn't showed much in what is the cause other than suggesting both PolicyKit and NM being screwy. Using rawhide on the laptop, kernel-2.6.34-0.38rc5.git0, NM-0.8.0-10.git20100502, polkit-0.96-1. The laptop is using an intel chipset. Help! I need to file a bug on this unless there is a quick easy fix... TTFN Paul -- Biggles was quietly reading his favourite book when Algy burst through the door. Distracted for a moment, Biggles surveyed what had happened and turned a page. Algy old man he said, clearing his throat, use the handle next time... - Taken from Biggles combs his Hair 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: F-13 libtool broken by gcc update
Mamoru Tasaka mtas...@ioa.s.u-tokyo.ac.jp writes: $ TZ=UTC koji list-tag-history --build=gcc-4.4.4-1.fc13 Sat May 1 00:57:24 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-updates-candidate [still active] Mon May 3 15:58:06 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-override Mon May 3 17:37:31 2010: Untagged gcc-4.4.4-1.fc13 from dist-f13-override The dependency was broken only for this 2 hours (perhaps to rebuild libtool for gcc 4.4.4). ... Once newrepo is created, dependency will be recovered again. BTW, it's now two hours later and gcc 4.4.4 is still in the buildroot. There is no newrepo task running for F-13, and no evidence that one has been launched recently. Perhaps an untag event fails to force a repo rebuild? If so seems like a bug. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 libtool broken by gcc update
On Mon, May 03, 2010 at 03:35:44PM -0400, Tom Lane wrote: Mamoru Tasaka mtas...@ioa.s.u-tokyo.ac.jp writes: $ TZ=UTC koji list-tag-history --build=gcc-4.4.4-1.fc13 Sat May 1 00:57:24 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-updates-candidate [still active] Mon May 3 15:58:06 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-override Mon May 3 17:37:31 2010: Untagged gcc-4.4.4-1.fc13 from dist-f13-override The dependency was broken only for this 2 hours (perhaps to rebuild libtool for gcc 4.4.4). ... Once newrepo is created, dependency will be recovered again. BTW, it's now two hours later and gcc 4.4.4 is still in the buildroot. There is no newrepo task running for F-13, and no evidence that one has been launched recently. Perhaps an untag event fails to force a repo rebuild? If so seems like a bug. So what is http://koji.fedoraproject.org/koji/taskinfo?taskID=2158992 then? Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: popularity package context on fedora
On Mon, May 3, 2010 at 9:27 PM, Jeff Spaleta jspal...@gmail.com wrote: On Sun, May 2, 2010 at 7:25 AM, yersinia yersinia.spi...@gmail.com wrote: Look interesting from a QA point of view. How exactly is this interesting from a QA pov in Fedora? Smolt profiles I can understand being useful for QA because it gives us some ability to look for commonalities when troubleshooting hardware problems. I'm really not sure what installed packaging information gives up in terms of helping any QA process. Care to explain your thoughts on this? Sure, I can try. If one software is used many time from many user, directly or indirectly, and it have not such many problems (e.g bug open on bugzilla for example ), well this could guide to the decision of the goodness of the software and the need to delete it or not if the maintainer does not believe to support it yet. Conversely, if software is not used - directly or indirectly - this could facilitate the decision to remove it, in the event that this possibility emerge. In general it depends on what someone thing of what it is the QA of a distribution: finding bugs, automate the process of finding bugs is one thing. But not alone. But it s only a personal opinion. Regards -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: popularity package context on fedora
On Mon, May 3, 2010 at 12:03 PM, Thomas Janssen thom...@fedoraproject.org wrote: - Superb information for us packagers if and how much (of course not the correct value) users use the software i package It may or may not be superb information...but you haven't told me how collecting this information is helpful to the users of my packages. Nor have you told me exactly how we as a project would use this information. So what if you find out that all your packages are in 0.01% the long tail of lowest popularity..how does that help you as a maintainer? How would knowing it they were very popular than your thought help you as a maintainer? - Helps to decide if a package can be easily removed from Fedora (upstream dead, no users left, good bye is no problem) 1) Popcon says nothing about dead upstream 2) Having zero counts in popcon does not mean unused. You can not make effective project choices with regard to expiring packages on popcon data that is opt-in. We have way too many niche packages which will have zero popcon counts but are still in use by someone. And if you are proposing that we go further than Debian and have this as on by default? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 libtool broken by gcc update
Jakub Jelinek ja...@redhat.com writes: On Mon, May 03, 2010 at 03:35:44PM -0400, Tom Lane wrote: BTW, it's now two hours later and gcc 4.4.4 is still in the buildroot. There is no newrepo task running for F-13, and no evidence that one has been launched recently. Perhaps an untag event fails to force a repo rebuild? If so seems like a bug. So what is http://koji.fedoraproject.org/koji/taskinfo?taskID=2158992 then? Something that launched right about the same time I complained, evidently ;-) regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 libtool broken by gcc update
Jakub Jelinek wrote, at 05/04/2010 05:17 AM +9:00: On Mon, May 03, 2010 at 03:35:44PM -0400, Tom Lane wrote: Mamoru Tasakamtas...@ioa.s.u-tokyo.ac.jp writes: $ TZ=UTC koji list-tag-history --build=gcc-4.4.4-1.fc13 Sat May 1 00:57:24 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-updates-candidate [still active] Mon May 3 15:58:06 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-override Mon May 3 17:37:31 2010: Untagged gcc-4.4.4-1.fc13 from dist-f13-override The dependency was broken only for this 2 hours (perhaps to rebuild libtool for gcc 4.4.4). ... Once newrepo is created, dependency will be recovered again. BTW, it's now two hours later and gcc 4.4.4 is still in the buildroot. There is no newrepo task running for F-13, and no evidence that one has been launched recently. Perhaps an untag event fails to force a repo rebuild? If so seems like a bug. So what is http://koji.fedoraproject.org/koji/taskinfo?taskID=2158992 then? Jakub Well, it seems usually koji runs 3 newrepo tasks at the same time, but two of them were hanging for 9 hours (for dist-rawhide and dist-rawhide) so newrepo tasks were rolling very slowly (I noticed this because I submitted one chain-build for dist-rawhide but it failed because wait-repo failed). I requested to cancel hanging 2 newrepo tasks and they were cancelled. Now newrepo tasks seem to be going well and new F-13 build already appeared as Jakub said above. Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 libtool broken by gcc update
Mamoru Tasaka wrote, at 05/04/2010 05:31 AM +9:00: Well, it seems usually koji runs 3 newrepo tasks at the same time, but two of them were hanging for 9 hours (for dist-rawhide and dist-rawhide) small correction: for dist-rawhide and for dist-f14 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for tomorrow's FESCo meeting (2010-05-04)
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 19:00UTC (3pm EDT) in #fedora-meeting on irc.freenode.net. = Followups = #351 Create a policy for updates - status report on implementation = New Business = #371 Change package owner of ddclient (as subhodip is nonresponsive) #370 allow bundling libiberty = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: popularity package context on fedora
On Mon, May 3, 2010 at 12:19 PM, yersinia yersinia.spi...@gmail.com wrote: Sure, I can try. If one software is used many time from many user, directly or indirectly, and it have not such many problems (e.g bug open on bugzilla for example ), well this could guide to the decision of the goodness of the software and the need to delete it or not if the maintainer does not believe to support it yet. Are you speaking as a member of the QA team? This sounds very hypothetical..and not very specific. I'm really not sure that popcon is going to tell us anything about fitness of a package in a way that bugzilla does not alreadyespecially when popcon its not setup to provide enough details in its summary reports to distinguish individual versions of one against another...let alone whether they are testing versions or what not. I don't see how this data is useful at all compared to abrt and bugzilla in doing any sort of QA for anyone. Here's a little exercise . Go into debian's bug tracking system and compare the rank order popularity of a package in popcon with the rank ordering of number of bugs filed against that package in debian's ticketing system for all time. There is a popular theory that holds that all software is roughly equally buggy and that roughly speaking the number of people reporting problems scales with its popularity...not with its general fitness. To be useful for package QA we'd really have to tie it into bodhi to give detailed information about how many people are using a given testing updates compared to nominal usage to help maintainers feel confident that its seen enough testing even when there's been no karma added or subtracted. But such an integrated system would not look anything like popcon and a there would need to be a sit down discussion with bodhi developers on how to best integrate that sort of client side data. Conversely, if software is not used - directly or indirectly - this could facilitate the decision to remove it, in the event that this possibility emerge. Popcon is designed as an opt-in system. You cannot rely on it giving it accurate results on actual usage for the full breath of our repository. Nor the Debian repository for that matter. We carry a significant number of niche packages...packages that will not be seen by popcon-like data collection unless you get a significant proportion of the userbase running it and catch all possible usage scenarios. If you are proposing that the project employ a data driven package expiration policy.. then lets figure out what that policy needs to be and build data collection to meet its requirements...not build the data collection then build the policy that fits after the fact. I do not want to see data collected just because its possible to collect. I want there to be a specific reason and a firm commitment to using the data that we can communicate to our users. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, 2010-05-03 at 18:45 +0200, Kevin Kofler wrote: here will ALWAYS be a need for a way to fasttrack regression fixes! The proposals I've seen include a way to fasttrack. That is you get the required karma between the time the update was submitted to bodhi, and the time a bodhi admin starts the push. In such cases your update would go directly to stable. How is that not a fast track? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: popularity package context on fedora
On Mon, May 3, 2010 at 10:21 PM, Jeff Spaleta jspal...@gmail.com wrote: On Mon, May 3, 2010 at 12:03 PM, Thomas Janssen thom...@fedoraproject.org wrote: - Superb information for us packagers if and how much (of course not the correct value) users use the software i package It may or may not be superb information...but you haven't told me how collecting this information is helpful to the users of my packages. It's not intended to be helpful for the users, but for me as packager and upstream. Nor have you told me exactly how we as a project would use this information. We could use the information to find out, if an app that we think is the real deal, is really the real deal. I bet we would be surprised about the one or other application. Well maybe not :) So what if you find out that all your packages are in 0.01% the long tail of lowest popularity..how does that help you as a maintainer? How would knowing it they were very popular than your thought help you as a maintainer? That wouldn't effect my work as maintainer directly. Though the one or the other maintainer might be more careful with updates if he finds out that his software is used by a large portion of the community. Well, looks like i found at least one thing that it's helpful for our users. Oh, another thing helpful for our users: People who search for some software, not sure which one might be the best, could start with the most popular. I might have more ideas, it's almost midnight, nothing more to expect from me for today, sorry :) - Helps to decide if a package can be easily removed from Fedora (upstream dead, no users left, good bye is no problem) 1) Popcon says nothing about dead upstream 2) Having zero counts in popcon does not mean unused. 1) Right, i expect maintainers to find out if upstream is dead or not. I wasn't expecting popcorn to do it for me. 2) Right as well. Though if it's possible to have it implemented as said via mirrormanager (sorry i'm not part of infra so i can't tell if it's possible or not, or how to do it) it would at least indicate there are not much users. You can not make effective project choices with regard to expiring packages on popcon data that is opt-in. We have way too many niche packages which will have zero popcon counts but are still in use by someone. And if you are proposing that we go further than Debian and have this as on by default? Well, of course it wouldn't be only because of some popcon data, tough it would be better than nothing (our current situation). I mean mainly packages that are orphaned and nobody want's to pick them up due to nobody uses it. How would we decide today for such a package, we can't. Because we have no idea about how much users might be there. Good question about on or off by default. To make sense it should be on by default. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, 2010-05-03 at 18:51 +0200, Kevin Kofler wrote: Except karma requirements (which were in force due to the critical path process) did NOT prevent this particular regression, nor would a 1 week minimum in testing requirement have prevented it (the update spent 8 days in testing). That process DOES NOT WORK. It just adds extra bureaucracy and delays the fix for the regression. (But thankfully, direct stable pushes are still possible for KDE packages, which allowed us to do one to fix this regression quickly.) You are definitely missing the forest for the trees here. In the proposals I've seen, the was no mandate that an update spend a week in testing, provided it got enough karma before that. If the issue at hand is so egregious to need a push ASAP, then there should be plenty of people on hand to snag the update from koji and provide you the necessary karma nearly immediately. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 libtool broken by gcc update
On Mon, 2010-05-03 at 14:54 -0400, Tom Lane wrote: Jakub Jelinek ja...@redhat.com writes: gcc-4.4.4-1.fc13 has just been tagged temporarily into dist-f13-override so that new libtool could be built. Likely you tried to built during that short window or NewRepo has been too slow after it has been untagged from dist-f13-override already. I see. It seems like this indicates a rather fundamental shortcoming in the -override tagging mechanism. If random other builds that happen to be submitted at the wrong time will see the overridden packages, what happens to reproducibility? Can't we either fix it so that only the specific desired builds see the override, or just prevent unrelated builds from happening during the window? This is surely not going to be the last undesired failure if things stay like this. regards, tom lane I welcome suggestions. Your first suggestion would require entirely new buildroot tags produced for each -override. New buildroots have a significant cost in spin up, upwards to an hour or more for the first repo generation. Do you really want to introduce an hour+ delay in your build every time you need an override, not to mention the vastly increased load on our backend filesystem? The second suggestion would put significant blocks in our build windows, since we get override requests on a daily basis. If only one could be done at a time, and we had to wait until the build was finished before moving on, we'd have a serious backlog and almost never have a window for doing builds without any override tags in play. We take a measured risk with our current system, because that's the best balance we can strike right now. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: popularity package context on fedora
On Mon, May 3, 2010 at 1:06 PM, Thomas Janssen thom...@fedoraproject.org wrote: To make sense it should be on by default. Good luck with that. I strongly suggest that any usage which only makes sense with on by default is not a usage you can rely on as a strawman. The popularity application idea would be a compelling user benefit..but popcon as constructed really doesn't integrate well enough to give users useful popular application suggestions in a way that makes sense. We'd need something that integrates with PackageKit to relay suggestions. I suggest you read up on the now defunct mugshot idea that Red Hat/ Gnome developers implemented as a proof-of-concept of how to provide a popular suggestions idea. What mugshot did is directly comparable to what you want to do. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Jesse Keating wrote: The proposals I've seen include a way to fasttrack. That is you get the required karma between the time the update was submitted to bodhi, and the time a bodhi admin starts the push. In such cases your update would go directly to stable. How is that not a fast track? Because it requires getting karma. That's usually not fast at all, especially if you enforce that karma should not be given out without testing. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: popularity package context on fedora
Am Montag, den 03.05.2010, 23:30 +0200 schrieb Björn Persson: Thomas Janssen wrote: Good question about on or off by default. To make sense it should be on by default. NO! Popcon may have its uses, and I actually have it enabled on my Debian boxes, but it *must* be strictly opt-in. If it were on by default it would be spyware, and I do *not* want an operating system with spyware in it. Good point. +1 I don't think it's spyware, if it's enabled by default on the server side, do you? e.g. sourceforge does the same with their statistics counter (or any other web counter online). 'Phoning home' is indeed some kind of spyware... T -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, 2010-05-03 at 23:49 +0200, Kevin Kofler wrote: Jesse Keating wrote: The proposals I've seen include a way to fasttrack. That is you get the required karma between the time the update was submitted to bodhi, and the time a bodhi admin starts the push. In such cases your update would go directly to stable. How is that not a fast track? Because it requires getting karma. That's usually not fast at all, especially if you enforce that karma should not be given out without testing. Kevin Kofler Testing takes time, lets give up? Seriously? Pushes happen about once every 24 hours, do you really say it'll take longer than 24 hours to get a couple people to test the issue and confirm that your fix does indeed fix the issue, and doesn't seem to create any other immediately noticeable issues? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Stephen John Smoogen wrote: As I have pointed out in both public and private emails to you [snip] Why are you telling all this stuff to me? I'm ALREADY complaining about our processes being undemocratic. The points you make are very real. But I don't agree with you that the solution has to be some formal framework. If our representatives actually, well, REPRESENTED their electorate, things would work much better. Now of course none of the representatives knows who voted for them because the vote is anonymous, but as you explained, there are reasons to represent even those who did not vote for oneself, or at all, anyway. In some cases, the people to represent are even our users, e.g. they asked for adventurous updates, so why does the Board decide on a vision for conservative updates? Are people that set on their personal preference that they can't see that our users want something different? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: popularity package context on fedora
On Mon, 2010-05-03 at 13:32 -0800, Jeff Spaleta wrote: The popularity application idea would be a compelling user benefit..but popcon as constructed really doesn't integrate well enough to give users useful popular application suggestions in a way that makes sense. We'd need something that integrates with PackageKit to relay suggestions. I suggest you read up on the now defunct mugshot idea that Red Hat/ Gnome developers implemented as a proof-of-concept of how to provide a popular suggestions idea. What mugshot did is directly comparable to what you want to do. gnome-shell actually still collects app usage data in ~/.gnome2/shell (somewhat similar to what mugshot did), but it does nothing in particular with the data atm. And there is no popcon-esque framework to collect this data in a central place. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On 5/4/2010 12:57 AM, Jesse Keating wrote: Testing takes time, lets give up? Seriously? Pushes happen about once every 24 hours, do you really say it'll take longer than 24 hours to get a couple people to test the issue and confirm that your fix does indeed fix the issue, and doesn't seem to create any other immediately noticeable issues? At the risk of putting words into Kevin's mouth, I think that you just made his point. I'd be very surprised if Kevin couldn't get x number of people to say yes to a fix that he considered urgent. This might confirm that the fix had its expected consequence, but I think that he already knew that or he wouldn't be trying to push it to stable. It wouldn't say much for stability or edge cases, only a good regression suite would give confidence on that score. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, 2010-05-04 at 01:27 +0300, shmuel siegel wrote: At the risk of putting words into Kevin's mouth, I think that you just made his point. I'd be very surprised if Kevin couldn't get x number of people to say yes to a fix that he considered urgent. This might confirm that the fix had its expected consequence, but I think that he already knew that or he wouldn't be trying to push it to stable. It wouldn't say much for stability or edge cases, only a good regression suite would give confidence on that score. The point here is that Kevin isn't perfect. As such, he can make mistakes, just like all of us. By asking for a couple karma nods from different people, we increase the chance of catching some of those mistakes. Since the delay exists anyway, it doesn't seem to be that big of a deal to me to make sure a couple people test it and comment as such during that delay. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: popularity package context on fedora
Thomas Spura wrote: I don't think it's spyware, if it's enabled by default on the server side, do you? e.g. sourceforge does the same with their statistics counter (or any other web counter online). No, extracting download statistics from web server logs isn't spyware. Spyware is software that runs on a user's computer and, without the user's explicit permission, sends out data that otherwise wouldn't have left the user's computer. It can be considered unethical to publish or sell detailed information about individual users' activities even if no spyware was involved in gathering the information, but I don't think anyone thinks a download count is a problem. Björn Persson 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: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, 2010-05-04 at 00:01 +0200, Kevin Kofler wrote: In some cases, the people to represent are even our users, e.g. they asked for adventurous updates, so why does the Board decide on a vision for conservative updates? Are people that set on their personal preference that they can't see that our users want something different? Please stop banding about the forum poll as if it were some sort of scientific measure with meaningful results one could use as a basis for decision making. It was none of that. All it gave us was info we already had. Some users would like more adventurous stuff, while some users would not. We already had that information, the poll told us nothing new. You also seem to keep thinking that just because a decision was made that a person or some people disagree with, that their input was ignored. That is not the case. Data can be reviewed and used as part of a decision process, even if that decision ultimately does not agree with you. You are using inflammatory words to try and stir up the pot because boy, it sure does feel good to be angry about something! And boy, it sure does feel good to get other people to feel angry too, even if they have no idea what they're angry about, or whom they are angry at. So quit with the dramatics already. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 3, 2010 at 4:01 PM, Kevin Kofler kevin.kof...@chello.at wrote: Stephen John Smoogen wrote: As I have pointed out in both public and private emails to you [snip] Why are you telling all this stuff to me? I'm ALREADY complaining about our processes being undemocratic. The points you make are very real. But I don't agree with you that the solution has to be some formal framework. If our representatives actually, well, REPRESENTED their electorate, things would work much better. Now of course none of the representatives knows who voted for them because the vote is anonymous, but as you explained, there are reasons to represent even those who did not vote for oneself, or at all, anyway. I have been telling you because I had hoped you would listen and realize you were not just tilting at windmills but the wrong ones. However it is clear to me that I am not able to communicate with you or understand what you are trying to represent. After a year of posting, all I can make out is some sort of quest towards some sort of Anarchy/Anti-statist government in a place where it has little possibility of occurring. In some cases, the people to represent are even our users, e.g. they asked for adventurous updates, so why does the Board decide on a vision for conservative updates? Are people that set on their personal preference that they can't see that our users want something different? When less than 50% of the population votes, everyone can claim they represent the silent majority. And no, a set of emails to a mailing list does not make you non-silent. Hard work and continual effort is what counts in the long run. So in the end, elected members have to vote what they see best. If those views are not what the 'majority' believes to be right they will be voted out. -- 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: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
2010/5/4 Stephen John Smoogen smo...@gmail.com: On Mon, May 3, 2010 at 4:01 PM, Kevin Kofler kevin.kof...@chello.at wrote: Stephen John Smoogen wrote: As I have pointed out in both public and private emails to you [snip] Why are you telling all this stuff to me? I'm ALREADY complaining about our processes being undemocratic. The points you make are very real. But I don't agree with you that the solution has to be some formal framework. If our representatives actually, well, REPRESENTED their electorate, things would work much better. Now of course none of the representatives knows who voted for them because the vote is anonymous, but as you explained, there are reasons to represent even those who did not vote for oneself, or at all, anyway. I have been telling you because I had hoped you would listen and realize you were not just tilting at windmills but the wrong ones. However it is clear to me that I am not able to communicate with you or understand what you are trying to represent. After a year of posting, all I can make out is some sort of quest towards some sort of Anarchy/Anti-statist government in a place where it has little possibility of occurring. if someone opposes some enforced order it doesent make him necasserily and anarchist... and as long as people in general need someone to vote and decide for them, we are still in the social and educational stone age. kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
help needed for diffutils: bz #566482
hi, troubles with the i18n patch. http://bugzilla.redhat.com/show_bug.cgi?id=566482#c9 -thanks- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, May 04, 2010 at 00:01:24 +0200, Kevin Kofler kevin.kof...@chello.at wrote: Why are you telling all this stuff to me? I'm ALREADY complaining about our processes being undemocratic. The points you make are very real. But I don't agree with you that the solution has to be some formal framework. If our representatives actually, well, REPRESENTED their electorate, things would work much better. Now of course none of the representatives knows who voted for them because the vote is anonymous, but as you explained, there are reasons to represent even those who did not vote for oneself, or at all, anyway. I disagree, that that is the correct way to run a democratic republic. That is how most politicans work in the USA. They are more interested in getting elected than leading. They run polls continuously during election cycles so that they know what to tell voters. As a voter this sucks. You have no idea what such a person is going to do after getting elected, as they follow the whim of the polls. I'd much rather have a set of candidates say up front where they want to lead people and then decide which one gets to lead based on a vote. There are a few politicians who work this way in the USA, but not many. That's not to say a politician can't change their opinion based on new information, but cases where they do should be rare. I think people running for leadership positions for Fedora should actually lead and not just go along with the poll of the day. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Jesse Keating wrote: Please stop banding about the forum poll as if it were some sort of scientific measure with meaningful results one could use as a basis for decision making. It's the best data we have. It was none of that. All it gave us was info we already had. Some users would like more adventurous stuff, while some users would not. We already had that information, the poll told us nothing new. The poll told us an approximate proportion, which is so far from 50-50 (72.13%) that we clearly have a statistically significant majority, also considering the sample size N=183. If you want me to actually compute some p-values and do statistical tests, I can do that, but to me the numbers look obvious. Now you may try to argue that the sample is biased, but you have no actual evidence towards that. In the absence of better data, the data we have is what we should use as the basis for our decision, not your personal opinion nor some imaginary silent majority which never has been proven to exist. If you aren't happy with the data, start collecting some better one! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On 05/03/2010 10:30 PM, Jesse Keating wrote: The point here is that Kevin isn't perfect. As such, he can make mistakes, just like all of us. By asking for a couple karma nods from different people, we increase the chance of catching some of those mistakes. Since the delay exists anyway, it doesn't seem to be that big of a deal to me to make sure a couple people test it and comment as such during that delay. Agreed. For example we had a bug in one of the previous release were a relativity harmless fix in the maintainers eye ( which I do believe he tested locally before updating the package ) broke all non US keyboard layouts ( if I can recall correctly actually reset or set the keyboard layout setting to US or deleted the previous stored layout) luckily for us he did not act impatiently but pushed it to updates-testing were we were able to capture it before it hit mainstream. This could have proven disastrous but it did not thanx to this process. Now if maintainers wants to wield the power of pushing straight to update without having to have his update lay for few hours/day's in update-testing it is my firm opinion that he should be.. a) a upstream maintainer b) have flawless bugzilla interaction, c) have very active upstream interaction encase a) is false and d) upstream is ACTIVE. Encase of a mishap we need to be sure that the maintainer can act quickly ( from the first report in after he pushed that update ) if needed but before granting that access we seriously need to start tracking and visualize ( graph ) component action both in bugzilla and in bodhi to identify which maintainers and their components can be granted that access. You must all realize that the ratio of bureaucracy/process burden and quality of maintainers/packagers go hand in hand. The better the maintainers/packagers/components are less bureaucracy/process burden is needed. The worse it gets more bureaucracy/process burden is needed. If ye all feel that the bureaucracy/process burden is increasing that only means that the quality of maintainers and their components is going down.. ( we might be getting more components inn in less quality ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, 2010-05-04 at 01:58 +0200, Kevin Kofler wrote: Jesse Keating wrote: Please stop banding about the forum poll as if it were some sort of scientific measure with meaningful results one could use as a basis for decision making. It's the best data we have. Bad data is worse than no data. It was none of that. All it gave us was info we already had. Some users would like more adventurous stuff, while some users would not. We already had that information, the poll told us nothing new. The poll told us an approximate proportion, which is so far from 50-50 (72.13%) that we clearly have a statistically significant majority, also considering the sample size N=183. If you want me to actually compute some p-values and do statistical tests, I can do that, but to me the numbers look obvious. Now you may try to argue that the sample is biased, but you have no actual evidence towards that. Of course the sample is biased. It's a sample of people who frequent the forums, that's a self selecting group of people, by no means a worthwhile representation of the Fedora user base as a whole. In the absence of better data, the data we have is what we should use as the basis for our decision, not your personal opinion nor some imaginary silent majority which never has been proven to exist. If you aren't happy with the data, start collecting some better one! Kevin Kofler Proper scientific data collection is hard, really hard. To do it right would take a lot of time and engineering and even argument. I don't want to put in that time, nor do I think we could ever be able to truly have a good representation as we have no hard data on who all uses Fedora, and in which ways. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 3, 2010 at 10:01 PM, Jesse Keating wrote: On Tue, 2010-05-04 at 01:58 +0200, Kevin Kofler wrote: Jesse Keating wrote: The poll told us an approximate proportion, which is so far from 50-50 (72.13%) that we clearly have a statistically significant majority, also considering the sample size N=183. If you want me to actually compute some p-values and do statistical tests, I can do that, but to me the numbers look obvious. Now you may try to argue that the sample is biased, but you have no actual evidence towards that. Of course the sample is biased. It's a sample of people who frequent the forums, that's a self selecting group of people, by no means a worthwhile representation of the Fedora user base as a whole. Please stop talking about imaginary users who do not care to voice themselves. This is of zero use. The statistic talks. It doesn't only talk. It yells. Ignoring this test statistic in favor of the large pool of imaginary users, who supposedly think in the complete other direction, is not only non-scientific, stupid., but also self-conflicting. The imaginary users do not voice themselves. If you change the policy, do you really expect hundreds of thousands of imaginary users to become real, and start yelling at you? No, they will still remain imaginary. And perhaps, they will start thinking in the other direction and become imaginary evidence for certain people to ignore some further statistical data. This is nonsense. Sorry for my use of the word stupid, but this biasedness claim really falls in that category. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 3, 2010 at 5:58 PM, Kevin Kofler kevin.kof...@chello.at wrote: Jesse Keating wrote: Please stop banding about the forum poll as if it were some sort of scientific measure with meaningful results one could use as a basis for decision making. It's the best data we have. And the statisticians I know say that some data is usually much worse than no data at all. When we used to go about poll data in class, the professors used a training story like this: Get on a motorcycle. Drive 40 miles per hour. Spit in the direction you are going in. Do it multiple times just to be sure. From that data give the direction of the wind for the countryside. Unless the wind is very very strong and your methods of getting the data very stringent, the best your poll will tell you is that 'the wind' was towards your face. It doesn't matter if at rest the wind was to your back. The poll has the following problems: 1) self selected pool of subjects being polled (who voted versus who did not. were the people polled or did anyone who could poll themselves) 2) unknown controls on who was polled versus who wasn't. (how many times did someone vote multiple times, how strong can you confirm that) 3) how neutral were the questions and how many ways were the questions asked so that language biases were tested? Any one of those can invalidate the mathematical tests you say to run as they require random pools, controls on populations polled, and non-leading questions. People keep telling you this and you seem to keep ignoring it. At best what you can say is the following: 183 people who use the Fedora Forum expressed their opinions on X,Y,Z questions. 78% of those people voted for X and 22% voted for Y. Due to methodologies the level of uncertainty is not easily quantifiable making it unknown how it represents the general population. Further study and better testing methodologies are required. I would say the same thing if the votes had been the other way.. and people were harping that this proved that slow updates was what people wanted. -- 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: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Once upon a time, Orcan Ogetbil oget.fed...@gmail.com said: The statistic talks. It doesn't only talk. It yells. Ignoring this test statistic in favor of the large pool of imaginary users, who supposedly think in the complete other direction, is not only non-scientific, stupid., but also self-conflicting. You claim you have taken grad-level statistics, but you don't appear to understand how to select a sample. A self-selected sample on a web forum (with no basis to show that forum members are representative of the Fedora user base, much less that poll responders represent even the forum users) does not lead to valid statistical results. It doesn't matter how big the sample size is if the samples are not properly selected. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 3, 2010 at 10:26 PM, Chris Adams wrote: Once upon a time, Orcan Ogetbil said: The statistic talks. It doesn't only talk. It yells. Ignoring this test statistic in favor of the large pool of imaginary users, who supposedly think in the complete other direction, is not only non-scientific, stupid., but also self-conflicting. You claim you have taken grad-level statistics, but you don't appear to understand how to select a sample. A self-selected sample on a web forum (with no basis to show that forum members are representative of the Fedora user base, much less that poll responders represent even the forum users) does not lead to valid statistical results. It doesn't matter how big the sample size is if the samples are not properly selected. No, I exactly know how to select a sample. The forum based sample is the perfect sample. It is the users who talk. It is not the imaginary users, who you claim to exist. I do not care about your imaginary users. I do care about those who talk. Hence the statistic is significant. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, 2010-05-03 at 22:37 -0400, Orcan Ogetbil wrote: On Mon, May 3, 2010 at 10:26 PM, Chris Adams wrote: Once upon a time, Orcan Ogetbil said: The statistic talks. It doesn't only talk. It yells. Ignoring this test statistic in favor of the large pool of imaginary users, who supposedly think in the complete other direction, is not only non-scientific, stupid., but also self-conflicting. You claim you have taken grad-level statistics, but you don't appear to understand how to select a sample. A self-selected sample on a web forum (with no basis to show that forum members are representative of the Fedora user base, much less that poll responders represent even the forum users) does not lead to valid statistical results. It doesn't matter how big the sample size is if the samples are not properly selected. No, I exactly know how to select a sample. The forum based sample is the perfect sample. It is the users who talk. It is not the imaginary users, who you claim to exist. I do not care about your imaginary users. I do care about those who talk. Hence the statistic is significant. You aren't a very good statistician if you care. thats an implicit bias. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 3, 2010 at 10:45 PM, Dave Airlie wrote: On Mon, 2010-05-03 at 22:37 -0400, Orcan Ogetbil wrote: On Mon, May 3, 2010 at 10:26 PM, Chris Adams wrote: Once upon a time, Orcan Ogetbil said: The statistic talks. It doesn't only talk. It yells. Ignoring this test statistic in favor of the large pool of imaginary users, who supposedly think in the complete other direction, is not only non-scientific, stupid., but also self-conflicting. You claim you have taken grad-level statistics, but you don't appear to understand how to select a sample. A self-selected sample on a web forum (with no basis to show that forum members are representative of the Fedora user base, much less that poll responders represent even the forum users) does not lead to valid statistical results. It doesn't matter how big the sample size is if the samples are not properly selected. No, I exactly know how to select a sample. The forum based sample is the perfect sample. It is the users who talk. It is not the imaginary users, who you claim to exist. I do not care about your imaginary users. I do care about those who talk. Hence the statistic is significant. You aren't a very good statistician if you care. thats an implicit bias. ... which is far better than an imaginary bias. Orcan PS: No, I am not a statistician. But I know about the science of statistics to a good degree. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On 05/03/2010 11:12 PM, Jesse Keating wrote: On Mon, 2010-05-03 at 18:51 +0200, Kevin Kofler wrote: Except karma requirements (which were in force due to the critical path process) did NOT prevent this particular regression, nor would a 1 week minimum in testing requirement have prevented it (the update spent 8 days in testing). That process DOES NOT WORK. It just adds extra bureaucracy and delays the fix for the regression. (But thankfully, direct stable pushes are still possible for KDE packages, which allowed us to do one to fix this regression quickly.) You are definitely missing the forest for the trees here. So do you: The karma stuff will never work and if then only in corner-cases. In probably the overwhelming majority of cases, all karma does is adding to Fedora's bureaucracy, without being actually functional. In the proposals I've seen, the was no mandate that an update spend a week in testing, provided it got enough karma before that. If the issue at hand is so egregious to need a push ASAP, then there should be plenty of people on hand to snag the update from koji and provide you the necessary karma nearly immediately. You are presuming a bug * affects many people * is reproducable by many people * has user visible impacts * users are volunteering to provide feedback These presumptions are all wrong and do not apply. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, 2010-05-04 at 05:01 +0200, Ralf Corsepius wrote: You are presuming a bug * affects many people * is reproducable by many people * has user visible impacts * users are volunteering to provide feedback These presumptions are all wrong and do not apply. In many cases these do apply. I participate in cases such as this nearly every day, and it's working. We're testing fixes, rejecting bad ones, and getting the right builds into stable. The system is working, but as we all know, no system is perfect. However perfect is the enemy of good. We can't take the position of karma isn't the perfect solution to every update, therefor we should do away with testing all together. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, 2010-05-04 at 05:01 +0200, Ralf Corsepius wrote: On 05/03/2010 11:12 PM, Jesse Keating wrote: On Mon, 2010-05-03 at 18:51 +0200, Kevin Kofler wrote: Except karma requirements (which were in force due to the critical path process) did NOT prevent this particular regression, nor would a 1 week minimum in testing requirement have prevented it (the update spent 8 days in testing). That process DOES NOT WORK. It just adds extra bureaucracy and delays the fix for the regression. (But thankfully, direct stable pushes are still possible for KDE packages, which allowed us to do one to fix this regression quickly.) You are definitely missing the forest for the trees here. So do you: The karma stuff will never work and if then only in corner-cases. In probably the overwhelming majority of cases, all karma does is adding to Fedora's bureaucracy, without being actually functional. In the proposals I've seen, the was no mandate that an update spend a week in testing, provided it got enough karma before that. If the issue at hand is so egregious to need a push ASAP, then there should be plenty of people on hand to snag the update from koji and provide you the necessary karma nearly immediately. You are presuming a bug * affects many people * is reproducable by many people * has user visible impacts * users are volunteering to provide feedback So it its none of these why do you want to fast track it into stable? Leave it updates-testing for 2-3 weeks and pull it in then if nobody complains. If you can't find anyone the bug affects I don't see why its an urgent must-fix. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On 05/03/2010 10:01 PM, Jesse Keating wrote: Of course the sample is biased. It's a sample of people who frequent the forums, that's a self selecting group of people, by no means a worthwhile representation of the Fedora user base as a whole. FYI - Not true - I joined the forum for the sole purpose of voting in that poll - everyone I know who voted joined the forum for the same reason. The mailling list brought it to my attention. We all follow the mailing lists - as presumably does FESCO - so the sample is less biased than is being suggested. FESCO is not voted in by Aunt Tilly ... are they? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 3, 2010 at 9:13 PM, Mail Llists li...@sapience.com wrote: On 05/03/2010 10:01 PM, Jesse Keating wrote: Of course the sample is biased. It's a sample of people who frequent the forums, that's a self selecting group of people, by no means a worthwhile representation of the Fedora user base as a whole. FYI - Not true - I joined the forum for the sole purpose of voting in that poll - everyone I know who voted joined the forum for the same reason. The mailling list brought it to my attention. Actually what you did is considered the classic example of skewing the data by self-selection at this point it is no longer polling but 'voting'. It is the reason why many polls will say 'unscientific survey' when done this way... you can not apply standard tests and get answers that would be found scientifically valid. For a poll to be statistically valid, the population must be randomly polled. The population polled may be a 'self-selected' target (eg those who have registered to vote versus the general population) but it needs to be a semi-closed set. [EG polling surveys of registered voters after the deadline to register is considered to be more accurate than before so because the population will not suddenly grow afterwords.] Listen, I would have to say this no matter what the survey came out was. It was seriously flawed in ways that make using it worse than having no data at all. It also makes it harder to do a proper survey because of the emotional baggage that various people have attached for or against the first one. We all follow the mailing lists - as presumably does FESCO - so the sample is less biased than is being suggested. FESCO is not voted in by Aunt Tilly ... are they? They aren't voted in. The range voting method does not vote people in or out.. it determines who the majority of people are most likely to 'live' with. Basically it tries to remove the emotional political ends and find who the 'silent' majority want. How much it does that is dependant on other factors but that is what it (and the Debian voting system) aim for. In the end, being elected by a range vote is less of a mandate than an acceptance. -- 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: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 03, 2010 at 10:16:48PM -0400, Orcan Ogetbil wrote: On Mon, May 3, 2010 at 10:01 PM, Jesse Keating wrote: On Tue, 2010-05-04 at 01:58 +0200, Kevin Kofler wrote: Jesse Keating wrote: The poll told us an approximate proportion, which is so far from 50-50 (72.13%) that we clearly have a statistically significant majority, also considering the sample size N=183. If you want me to actually compute some p-values and do statistical tests, I can do that, but to me the numbers look obvious. Now you may try to argue that the sample is biased, but you have no actual evidence towards that. Of course the sample is biased. It's a sample of people who frequent the forums, that's a self selecting group of people, by no means a worthwhile representation of the Fedora user base as a whole. Please stop talking about imaginary users who do not care to voice themselves. This is of zero use. The statistic talks. It doesn't only talk. It yells. Ignoring this test statistic in favor of the large pool of imaginary users, who supposedly think in the complete other direction, is not only non-scientific, stupid., but also self-conflicting. The imaginary users do not voice themselves. If you change the policy, do you really expect hundreds of thousands of imaginary users to become real, and start yelling at you? No, they will still remain imaginary. I resent being called an imaginary user. Being imaginary would seriously screw with my weekend plans. Cheers, Peter And perhaps, they will start thinking in the other direction and become imaginary evidence for certain people to ignore some further statistical data. This is nonsense. Sorry for my use of the word stupid, but this biasedness claim really falls in that category. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I have no name, etc. after hibernate
Hi, On F12, as of about 1 month ago, user information started getting lost sometimes after resuming from hibernate. You can see this as follows: - With new terminals, the prompt user name is I have no name!. - With new SSH sessions, you get You don't exist, go away! - Su fails with su: user root does not exist - You can't login from new VTYs (just fails) - ls does not look up uids/gids /etc/passwd is 644, and usernames do exist there. LDAP auth is not used. Selinux is permissive. nscd is off. I do use fingerprint reader for auth but I doubt that's relevant. I couldn't find anything in bugzilla, and I have no idea which component to file this against. Any ideas? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I have no name, etc. after hibernate
On Tue, 2010-05-04 at 07:27 +0300, Pekka Savola wrote: On F12, as of about 1 month ago, user information started getting lost sometimes after resuming from hibernate. You can see this as follows: - With new terminals, the prompt user name is I have no name!. - With new SSH sessions, you get You don't exist, go away! - Su fails with su: user root does not exist - You can't login from new VTYs (just fails) - ls does not look up uids/gids /etc/passwd is 644, and usernames do exist there. LDAP auth is not used. Selinux is permissive. nscd is off. I do use fingerprint reader for auth but I doubt that's relevant. I couldn't find anything in bugzilla, and I have no idea which component to file this against. Any ideas? Run strace id and see if it is able to open and read /etc/nsswitch.conf and /etc/passwd. If so, it would be a glibc bug. If not, investigate why those files cannot be read. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Bernd Stramm said the following on 05/03/2010 07:13 PM Pacific Time: On Mon, 3 May 2010 22:04:11 -0400 Orcan Ogetbiloget.fed...@gmail.com wrote: On Mon, May 3, 2010 at 8:22 PM, Bernd Stramm wrote: On Tue, 04 May 2010 01:58:34 +0200 Kevin Kofler wrote: The poll told us an approximate proportion, which is so far from 50-50 (72.13%) that we clearly have a statistically significant majority, also considering the sample size N=183. I'm not sure what the poll was exactly, but a sample size of 183 people makes it utterly meaningless considering the population size. After all these years of academic studies, including graduate level Statistics courses, I disagree with your conclusion. Orcan I disagree with the disagreement. For one thing, the poll can only measure anything about the population that knows about it. That population is a very small percentage of the Fedora users. And there is no reason to assume that population is representative of Fedora users. Wow. It didn't take long :) http://poelcat.wordpress.com/2010/04/28/monty-python-does-the-fedora-development-list/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
