32bit vs 64bit - 32bit can't handle 2100 in strtotime?
Hi, I would like to note that I am aware of that 32 bit systems will not work after 2038. But does that mean that they can not do simple date conversion? 32-bit system string(19) "2011-06-27 09:17:10" int(1309159030) string(19) "2100-01-01 01:01:01" bool(false) 64-bit system string(19) "2011-06-27 09:18:28" int(1309159108) string(19) "2100-01-01 01:01:01" int(4102444861) -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 32bit vs 64bit - 32bit can't handle 2100 in strtotime?
2011/6/27 Michał Piotrowski : > Hi, > > I would like to note that I am aware of that 32 bit systems will not > work after 2038. But does that mean that they can not do simple date > conversion? Where is the difference ... overflowing the 32bit integer due to the current date being past 2038 or by setting it by hand? Just move on to the current century and install a 64bit os ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 716174] FTBFS perl-OpenFrame-3.05-13.fc15
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=716174 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-OpenFrame-3.05-16.fc16 -- 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: 32bit vs 64bit - 32bit can't handle 2100 in strtotime?
2011/6/27 drago01 : > 2011/6/27 Michał Piotrowski : >> Hi, >> >> I would like to note that I am aware of that 32 bit systems will not >> work after 2038. But does that mean that they can not do simple date >> conversion? > > Where is the difference ... overflowing the 32bit integer due to the > current date being past 2038 or by setting it by hand? > Just move on to the current century and install a 64bit os ;) I can't - it's project manager's test machine and it's 32-bit Intel T2300 :) If it were not 32-bit machine we certainly would not notice the occurrence of the problem :) > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 32bit vs 64bit - 32bit can't handle 2100 in strtotime?
Michał Piotrowski writes: > I would like to note that I am aware of that 32 bit systems will not > work after 2038. But does that mean that they can not do simple date > conversion? If they use the system time_t, then no. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Jeroen van Meeuwen
Am Freitag, den 17.06.2011, 14:37 +0200 schrieb Farkas Levente: > On 06/17/2011 02:01 PM, Vít Ondruch wrote: > > I'm following the procedure at: > > > > http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers > > > > Does anyone know how to contact Jeroen van Meeuwen? He is not answering > > e-mails at his listed address or the following Bugzilla reports: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=707934 > > https://bugzilla.redhat.com/show_bug.cgi?id=707937 > > > > There is also many other Jeroen's packages which would need some > > maintenance. > > there're dozen of reports about revisor too which is not working on any > current fedora and epel either. Correct me if I'm wrong, but there are workarounds described in the bug reports. The best way to move things forward is to submit patches. I'll ping Jeroen in the meantime, but we are both very busy with out dayjob. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 701000] perl-YAML-Tiny-1.50 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=701000 Petr Sabata changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com AssignedTo|st...@silug.org |psab...@redhat.com --- Comment #2 from Petr Sabata 2011-06-27 04:36:44 EDT --- 1.50 Thu 23 Jun 2011 - Major bug fix, all code that writes arbitrary data should upgrade. - Simple scalars with no whitespace but ending in a colon like ABC: were not being quoted, which results in the parser confusing it with a mapping key and crashing. 1.49 Tue 8 Mar 2011 - No functional changes. - Don't depend on the YAML modules in RELEASE_TESTING, as it can pollute the advisory META.yml. 1.48 Tue 1 Feb 2011 - Fix to the refaddr compatibility where Scalar::Util is installed but is older than 1.18. 1.47 Mon 31 Jan 2011 - No functional changes - Only depend on the YAML implementations when we are release testing -- 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: Unresponsive Package Maintainer - Jeroen van Meeuwen
On Mon, Jun 27, 2011 at 10:38:20AM +0200, Christoph Wickert wrote: > I'll ping Jeroen in the meantime, but we are both very busy with out > dayjob. In that case approving one or all of the three people who have requested commit access seems sensible. -- sven === jabber/xmpp: s...@lankes.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File YAML-Tiny-1.50.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-YAML-Tiny: 333727bed82ee70459bdc007a9a4fc2c YAML-Tiny-1.50.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-YAML-Tiny] 1.50 bump, cleanup, (build-time) dependencies corrected
commit 4fdff80790478ec314a7c8044d1b564df6f0373f
Author: Petr Sabata
Date: Mon Jun 27 10:49:13 2011 +0200
1.50 bump, cleanup, (build-time) dependencies corrected
.gitignore |1 +
perl-YAML-Tiny.spec | 31 ---
sources |2 +-
3 files changed, 18 insertions(+), 16 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d16e1fe..9f4b2fe 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
YAML-Tiny-1.40.tar.gz
/YAML-Tiny-1.44.tar.gz
/YAML-Tiny-1.46.tar.gz
+/YAML-Tiny-1.50.tar.gz
diff --git a/perl-YAML-Tiny.spec b/perl-YAML-Tiny.spec
index b4facf3..a93a2a1 100644
--- a/perl-YAML-Tiny.spec
+++ b/perl-YAML-Tiny.spec
@@ -1,20 +1,23 @@
Name: perl-YAML-Tiny
-Version:1.46
-Release:2%{?dist}
+Version:1.50
+Release:1%{?dist}
Summary:Read/Write YAML files with as little code as possible
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/YAML-Tiny/
Source0:
http://search.cpan.org/CPAN/authors/id/A/AD/ADAMK/YAML-Tiny-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
+BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Spec) >= 0.80
+BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Test::MinimumVersion)
BuildRequires: perl(Test::More) >= 0.47
BuildRequires: perl(Test::Pod)
BuildRequires: perl(YAML)
BuildRequires: perl(YAML::Syck)
+Requires: perl(Exporter)
+Requires: perl(Scalar::Util)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
%{?perl_default_filter}
@@ -32,28 +35,26 @@ memory overhead.
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
-
-%{_fixperms} $RPM_BUILD_ROOT/*
+make pure_install PERL_INSTALL_ROOT=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
+%{_fixperms} %{buildroot}/*
%check
make test AUTOMATED_TESTING=1
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
-%defattr(-,root,root,-)
%doc Changes LICENSE README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Mon Jun 27 2011 Petr Sabata - 1.50-1
+- 1.50 bump
+- Cleaning the spec file (I assume pre-EPEL6 compatibility is no longer
+ essential here)
+- Adding Exporter and Scalar::Util (optional but preferred) to BR/Rs
+
* Wed Feb 09 2011 Fedora Release Engineering
- 1.46-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
diff --git a/sources b/sources
index 0339826..9b6e5cb 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a8efc1e6e13a6fd1877b07a5211d0b8b YAML-Tiny-1.46.tar.gz
+333727bed82ee70459bdc007a9a4fc2c YAML-Tiny-1.50.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F15: ugly behavior of "df"
On Fri, Jun 24, 2011 at 12:15:52PM +0100, Pádraig Brady wrote: > > I did a find_bind_mount() function as part of: > > http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=ddf6fb86 Note, be careful with st_dev, because: * after mount --bind /mnt/A /mnt/A /mnt/A has the same devno as /mnt/A/B, but /mnt/A is a mountpoint * btrfs returns different st_dev for different subvolumes within the same filesystem and the numbers don't match with the maj:min numbers from /proc/self/mountinfo (in the file is used only devno for entire FS). https://bugzilla.redhat.com/show_bug.cgi?id=711881 > I've not got sandbox installed BTW. > Still need to look at this. I have the same problem... not sure why :-( Karel -- Karel Zak http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
On 24/06/11 20:49, Miloslav Trmač wrote: > On Fri, Jun 24, 2011 at 12:49 PM, Andrew Haley wrote: >> What I don't understand is why this feature requires a binary blob. >> Surely whatever northbridge code is required can be free software, >> Is this just security through obscurity? > > The purpose of the blob is to "measure" the system state; only the > blob (and hardware reset) is allowed to restart the "measuring" > process in the TPM. For this to work securely, the blob must be > signed by someone that the TPM itself trusts - otherwise an attacker > could replace the blob by something that lies about the system state. > > So, from a standpoint of hacking, it doesn't matter - users won't have > the practical freedom to modify the blob anyway because they can't > sign it. What we're saying, then, is that the TPM doesn't trust the owner of the computer, but its manufacturer. It's impossible for a user to decide who they trust. Surely, from a Fedora standpoint, this is a complete non-starter. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 32bit vs 64bit - 32bit can't handle 2100 in strtotime?
> I would like to note that I am aware of that 32 bit systems will not > work after 2038. But does that mean that they can not do simple date > conversion? Yes, if "simple date conversion" uses a 32-bit time_t and does not check-and-correct for 32-bit wrap-around. On a system which uses a 32-bit time_t, then some user code has problems with the calculations for a 30-year mortgage with an origination date of 2008 or later. One common workaround is to use a temporary origin of something like 1980-01-01T00:00 instead of 1969-01-01T00:00. Using 1980 allows the same code to work for any _existing_ 30-year mortgage as well as new ones. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110627 changes
Compose started at Mon Jun 27 08:15:38 UTC 2011 Broken deps for x86_64 -- 389-dsgw-1.1.6-3.fc16.x86_64 requires libadmsslutil.so.1()(64bit) 389-dsgw-1.1.6-3.fc16.x86_64 requires libadminutil.so.1()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) amanith-0.3-14.fc13.i686 requires libGLEW.so.1.5 amanith-0.3-14.fc13.x86_64 requires libGLEW.so.1.5()(64bit) audacious-plugin-xmp-3.3.0-7.fc16.x86_64 requires audacious(plugin-api) = 0:19 bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit) condor-deltacloud-gahp-7.7.0-0.4.fc16.x86_64 requires libdeltacloud.so.6(LIBDCLOUDAPI_0.0.0)(64bit) condor-deltacloud-gahp-7.7.0-0.4.fc16.x86_64 requires libdeltacloud.so.6(LIBDCLOUDAPI_2.0.0)(64bit) condor-deltacloud-gahp-7.7.0-0.4.fc16.x86_64 requires libdeltacloud.so.6(LIBDCLOUDAPI_1.0.0)(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper digikam-1.9.0-1.fc15.x86_64 requires libkdcraw.so.9()(64bit) digikam-1.9.0-1.fc15.x86_64 requires libmarblewidget.so.11()(64bit) digikam-1.9.0-1.fc15.x86_64 requires libkexiv2.so.9()(64bit) digikam-libs-1.9.0-1.fc15.i686 requires libkdcraw.so.9 digikam-libs-1.9.0-1.fc15.i686 requires libkexiv2.so.9 digikam-libs-1.9.0-1.fc15.i686 requires libmarblewidget.so.11 digikam-libs-1.9.0-1.fc15.x86_64 requires libkdcraw.so.9()(64bit) digikam-libs-1.9.0-1.fc15.x86_64 requires libkexiv2.so.9()(64bit) digikam-libs-1.9.0-1.fc15.x86_64 requires libmarblewidget.so.11()(64bit) 1:eclipse-cdt-8.0.0-1.fc16.x86_64 requires eclipse-rse >= 0:3.2.1 evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libebook-1.2.so.10()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libcamel-provider-1.2.so.25()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libcamel-1.2.so.25()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libgnome-desktop-3.so.0()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) gdb-heap-0.5-5.fc16.x86_64 requires glibc(x86-64) = 0:2.13.90 gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit) ghc-hinotify-0.3.1-9.fc16.i686 requires libHSarray-0.3.0.2-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSdirectory-1.1.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSghc-prim-0.2.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSold-time-1.0.0.6-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSold-locale-1.0.0.2-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSunix-2.4.2.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSfilepath-1.2.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSbase-4.3.1.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSinteger-gmp-0.2.0.3-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHScontainers-0.4.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSghc-prim-0.2.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSold-time-1.0.0.6-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSbase-4.3.1.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSinteger-gmp-0.2.0.3-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSold-locale-1.0.0.2-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSfilepath-1.2.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires ghc(base-4.3.1.0) = 0:c33a1741503ded8a0170884e8a2e4fa2 ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHScontainers-0.4.0.0-ghc7.0.2.so()(64bit)
Re: Unresponsive Package Maintainer - Jeroen van Meeuwen
Vít Ondruch wrote: > I'm following the procedure at: > > http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers > > Does anyone know how to contact Jeroen van Meeuwen? He is not answering > e-mails at his listed address or the following Bugzilla reports: > > https://bugzilla.redhat.com/show_bug.cgi?id=707934 > https://bugzilla.redhat.com/show_bug.cgi?id=707937 > > There is also many other Jeroen's packages which would need some > maintenance. > Boo. Kind regards, -- kanarip -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages that will be orphaned
Toshio, I wan to take fcitx. Fedora && Debian User, former Ubuntu User My Page: http://www.liangsuilong.info Fedora Project Contributor -- Packager && Ambassador https://fedoraproject.org/wiki/User:Liangsuilong On Sat, Jun 25, 2011 at 3:10 AM, Toshio Kuratomi wrote: > On Fri, Jun 24, 2011 at 04:19:51PM +0800, Robin 'cheese' Lee wrote: > > I can take kbibtex. > > > Done. > > -Toshio > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Jeroen van Meeuwen
Hi, Good to have you back! On 06/27/2011 01:53 PM, Jeroen van Meeuwen wrote: > Vít Ondruch wrote: >> I'm following the procedure at: >> >> http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers >> >> Does anyone know how to contact Jeroen van Meeuwen? He is not answering >> e-mails at his listed address or the following Bugzilla reports: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=707934 >> https://bugzilla.redhat.com/show_bug.cgi?id=707937 >> >> There is also many other Jeroen's packages which would need some >> maintenance. >> > > Boo. > Hmm, not really helpful, and I'm also not sure if this falls under "be excellent to each other" Perhaps you coulb so kind as to respond to the request others have made to become co-maintainers of your packages? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
On Mon, Jun 27, 2011 at 12:11 PM, Andrew Haley wrote: > On 24/06/11 20:49, Miloslav Trmač wrote: >> On Fri, Jun 24, 2011 at 12:49 PM, Andrew Haley wrote: >>> What I don't understand is why this feature requires a binary blob. >>> Surely whatever northbridge code is required can be free software, >>> Is this just security through obscurity? >> >> The purpose of the blob is to "measure" the system state; only the >> blob (and hardware reset) is allowed to restart the "measuring" >> process in the TPM. For this to work securely, the blob must be >> signed by someone that the TPM itself trusts - otherwise an attacker >> could replace the blob by something that lies about the system state. > What we're saying, then, is that the TPM doesn't trust the owner of > the computer, but its manufacturer. It's impossible for a user to > decide who they trust. First, the TPM (nor the CPU) really can't tell the difference between the owner of the computer and an author of a virus. It's all just software. Second, every owner of a computer has to completely trust the manufacturer of the computer anyway - there are way too many ways the manufacturer can break the security of the system, e.g. backdoors in the CPU or motherboard, or hidden configurations of https://secure.wikimedia.org/wikipedia/en/wiki/Intel_AMT . Placing trust in the manufacturer of the hardware puts the user in no worse position than they were before. And the user, of course, still has full control over whether to use the TPM or not, and what to use it for. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages that will be orphaned
Those packages are already orphaned. On Mon, Jun 27, 2011 at 8:01 PM, Liang Suilong wrote: > Toshio, I wan to take fcitx. > Fedora && Debian User, former Ubuntu User > My Page: http://www.liangsuilong.info > Fedora Project Contributor -- Packager && Ambassador > https://fedoraproject.org/wiki/User:Liangsuilong > > > On Sat, Jun 25, 2011 at 3:10 AM, Toshio Kuratomi wrote: >> >> On Fri, Jun 24, 2011 at 04:19:51PM +0800, Robin 'cheese' Lee wrote: >> > I can take kbibtex. >> > >> Done. >> >> -Toshio >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for a sponsor
On Sun, Jun 26, 2011 at 8:06 PM, Elder Marco wrote: > Hi all, > > I created a new review request ( yad program - > https://bugzilla.redhat.com/show_bug.cgi?id=683150) > > This is my first package. So, if possible, could someone sponsor me? > > Best Regards, > > -- > Elder Marco > parece que ja tem alguem revisando seu pacote, boa sorte. -- Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
On Mon, 2011-06-27 at 15:12 +0200, Miloslav Trmač wrote: > On Mon, Jun 27, 2011 at 12:11 PM, Andrew Haley wrote: > > On 24/06/11 20:49, Miloslav Trmač wrote: > >> On Fri, Jun 24, 2011 at 12:49 PM, Andrew Haley wrote: > >>> What I don't understand is why this feature requires a binary blob. > >>> Surely whatever northbridge code is required can be free software, > >>> Is this just security through obscurity? > >> > >> The purpose of the blob is to "measure" the system state; only the > >> blob (and hardware reset) is allowed to restart the "measuring" > >> process in the TPM. For this to work securely, the blob must be > >> signed by someone that the TPM itself trusts - otherwise an attacker > >> could replace the blob by something that lies about the system state. > > > What we're saying, then, is that the TPM doesn't trust the owner of > > the computer, but its manufacturer. It's impossible for a user to > > decide who they trust. > > First, the TPM (nor the CPU) really can't tell the difference between > the owner of the computer and an author of a virus. It's all just > software. > > Second, every owner of a computer has to completely trust the > manufacturer of the computer anyway - there are way too many ways the > manufacturer can break the security of the system, e.g. backdoors in > the CPU or motherboard, or hidden configurations of > https://secure.wikimedia.org/wikipedia/en/wiki/Intel_AMT . > > Placing trust in the manufacturer of the hardware puts the user in no > worse position than they were before. And the user, of course, still > has full control over whether to use the TPM or not, and what to use > it for. Trusting the manufacturer to not put bugs/backdoors is one thing. Having to depend on the manufacturer to sign your boot sequence is entirely different, doesn't scale and is generally not welcome. If the manufacturer allows you to put in the TPM your own set of keys then it's different as the user now has the power to do his own kernels and sign them with his own key and have it verify by the TPM. If the user trusts Fedora to do that he'd store a Fedora public key in the TPM, if he doesn't he'll just not use TPM or re-sign kernels on update on his own with his personal key. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-PerlIO-locale] Import
commit 3394a05a2aefe28fec9b1e2b847296375c4e7e22
Author: Petr Písař
Date: Mon Jun 27 16:11:50 2011 +0200
Import
.gitignore |1 +
perl-PerlIO-locale.spec | 58 +++
sources |1 +
3 files changed, 60 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..cc56e15 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/PerlIO-locale-0.07.tar.gz
diff --git a/perl-PerlIO-locale.spec b/perl-PerlIO-locale.spec
new file mode 100644
index 000..746a252
--- /dev/null
+++ b/perl-PerlIO-locale.spec
@@ -0,0 +1,58 @@
+Name: perl-PerlIO-locale
+Version:0.07
+Release:1%{?dist}
+Summary:PerlIO layer to use the encoding of the current locale
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/PerlIO-locale/
+Source0:
http://www.cpan.org/authors/id/R/RG/RGARCIA/PerlIO-locale-%{version}.tar.gz
+BuildRequires: perl(ExtUtils::MakeMaker)
+# Tests:
+BuildRequires: perl(PerlIO::encoding)
+BuildRequires: perl(POSIX)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(XSLoader)
+# Optional tests:
+BuildRequires: perl(Test::Pod) >= 1.14
+BuildRequires: perl(Test::Pod::Coverage) >= 1.04
+Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+This is mostly a per-file-handle version of the open pragma, when used under
+the form:
+
+use open ':locale';
+
+The encoding for the opened file will be set to the encoding corresponding to
+the locale currently in effect, if perl can guess it.
+
+
+%prep
+%setup -q -n PerlIO-locale-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"
+make %{?_smp_mflags}
+
+%install
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc ChangeLog README
+%{perl_vendorarch}/auto/*
+%{perl_vendorarch}/PerlIO*
+%{_mandir}/man3/*
+
+%changelog
+* Mon Jun 27 2011 Petr Pisar 0.07-1
+- Specfile autogenerated by cpanspec 1.78.
+- Remove BuildRoot and defattr
diff --git a/sources b/sources
index e69de29..3be0cd6 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+9b0d75d8907bbbe94486ead95cafa6a7 PerlIO-locale-0.07.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Security updates for Firefox 4 in F-15
> > For me the most important benefit is OS independent software, especially > web browser. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Debates like this expose a weakness in packaging philosophy. The current philosophy seems to be all packages are equal. An update to Open/Libre Office is handled the same as an update to the kernel or glibc. It seems like in mainstream Linux distros your options often are: 1) Wait 6 months for new software. 2) Download / build from source and deal with system integration issues. 3) Download unofficial package. The reality is that not all packages are equal, and some could/should be pushed faster than others. Firefox and Libreoffice are good examples of this. If parallel installs of Xulrunner are needed, in my opinion, so be it. Ultimately, packaging philosophy could hold back/prevent mainstream (i.e. non power user) Linux adoption. These users will ask themselves "I can get the latest version well integrated on release day using Windows or Mac, why not Linux?". Ubuntu is moving (once again in my opinion) in the correct direction with its combination of LTS (a stable base) and PPAs for more rapid updates of things like Firefox. The fact that they have LTS tagging also prevents the question of "How many versions to support?". The answer is clear: two, the current LTS and the latest 6 month release. Finally, with packaging cycles changing might it be time to revisit the decision to merge Fedora Core and Extras? Creating separate repos with different goals might be wise. I apologize for the long rant. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
On Mon, 27 Jun 2011 10:08:44 -0400 Simo Sorce wrote: > On Mon, 2011-06-27 at 15:12 +0200, Miloslav Trmač wrote: > > On Mon, Jun 27, 2011 at 12:11 PM, Andrew Haley > > wrote: > > > On 24/06/11 20:49, Miloslav Trmač wrote: > > >> On Fri, Jun 24, 2011 at 12:49 PM, Andrew Haley > > >> wrote: > > >>> What I don't understand is why this feature requires a binary > > >>> blob. Surely whatever northbridge code is required can be free > > >>> software, Is this just security through obscurity? > > >> > > >> The purpose of the blob is to "measure" the system state; only > > >> the blob (and hardware reset) is allowed to restart the > > >> "measuring" process in the TPM. For this to work securely, the > > >> blob must be signed by someone that the TPM itself trusts - > > >> otherwise an attacker could replace the blob by something that > > >> lies about the system state. > > > > > What we're saying, then, is that the TPM doesn't trust the owner > > > of the computer, but its manufacturer. It's impossible for a > > > user to decide who they trust. > > > > First, the TPM (nor the CPU) really can't tell the difference > > between the owner of the computer and an author of a virus. It's > > all just software. > > > > Second, every owner of a computer has to completely trust the > > manufacturer of the computer anyway - there are way too many ways > > the manufacturer can break the security of the system, e.g. > > backdoors in the CPU or motherboard, or hidden configurations of > > https://secure.wikimedia.org/wikipedia/en/wiki/Intel_AMT . > > > > Placing trust in the manufacturer of the hardware puts the user in > > no worse position than they were before. And the user, of course, > > still has full control over whether to use the TPM or not, and what > > to use it for. > > Trusting the manufacturer to not put bugs/backdoors is one thing. > Having to depend on the manufacturer to sign your boot sequence is > entirely different, doesn't scale and is generally not welcome. > > If the manufacturer allows you to put in the TPM your own set of keys > then it's different as the user now has the power to do his own > kernels and sign them with his own key and have it verify by the TPM. > > If the user trusts Fedora to do that he'd store a Fedora public key in > the TPM, if he doesn't he'll just not use TPM or re-sign kernels on > update on his own with his personal key. On the subject of trust, may I repeat that this is at present entirely undocumented. The feature page contains nothing whatsoever saying what this is, except for a link to a sourceforge project. The sourceforge project in turn contains nothing saying what the software does. Nothing. I have found something that looks related here http://www.intel.com/technology/security/downloads/315168.htm but is that it? How would anyone know? -- Bernd Stramm bernd.str...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
On Mon, Jun 27, 2011 at 4:08 PM, Simo Sorce wrote: > On Mon, 2011-06-27 at 15:12 +0200, Miloslav Trmač wrote: >> On Mon, Jun 27, 2011 at 12:11 PM, Andrew Haley wrote: >> > On 24/06/11 20:49, Miloslav Trmač wrote: >> >> The purpose of the blob is to "measure" the system state; only the >> >> blob (and hardware reset) is allowed to restart the "measuring" >> >> process in the TPM. For this to work securely, the blob must be >> >> signed by someone that the TPM itself trusts - otherwise an attacker >> >> could replace the blob by something that lies about the system state. > Trusting the manufacturer to not put bugs/backdoors is one thing. > Having to depend on the manufacturer to sign your boot sequence is > entirely different, doesn't scale and is generally not welcome. The hardware manufacturer _only_ signs the sinit blob. Any kernel/OS you use can be measured/"protected" by the TPM without any further involvement of the manufacturer. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 564798] FTBFS ocaml-camlimages-3.0.2-2.fc13
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=564798 Bug Zapper changed: What|Removed |Added Status|NEW |CLOSED Resolution||WONTFIX Flag|needinfo?(ftbfs@fedoraproje | |ct.org) | Last Closed||2011-06-27 10:57:30 --- Comment #11 from Bug Zapper 2011-06-27 10:57:30 EDT --- Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Trusted Boot in Fedora
On Mon, 2011-06-27 at 16:53 +0200, Miloslav Trmač wrote: > On Mon, Jun 27, 2011 at 4:08 PM, Simo Sorce wrote: > > On Mon, 2011-06-27 at 15:12 +0200, Miloslav Trmač wrote: > >> On Mon, Jun 27, 2011 at 12:11 PM, Andrew Haley wrote: > >> > On 24/06/11 20:49, Miloslav Trmač wrote: > >> >> The purpose of the blob is to "measure" the system state; only the > >> >> blob (and hardware reset) is allowed to restart the "measuring" > >> >> process in the TPM. For this to work securely, the blob must be > >> >> signed by someone that the TPM itself trusts - otherwise an attacker > >> >> could replace the blob by something that lies about the system state. > > > Trusting the manufacturer to not put bugs/backdoors is one thing. > > Having to depend on the manufacturer to sign your boot sequence is > > entirely different, doesn't scale and is generally not welcome. > > The hardware manufacturer _only_ signs the sinit blob. Any kernel/OS > you use can be measured/"protected" by the TPM without any further > involvement of the manufacturer. How does the sinit blob verify the kernel ? Can you add some documentation about that in the feature page request as others have asked please ? Thanks, Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
On Mon, Jun 27, 2011 at 5:14 PM, Simo Sorce wrote: > On Mon, 2011-06-27 at 16:53 +0200, Miloslav Trmač wrote: >> On Mon, Jun 27, 2011 at 4:08 PM, Simo Sorce wrote: >> The hardware manufacturer _only_ signs the sinit blob. Any kernel/OS >> you use can be measured/"protected" by the TPM without any further >> involvement of the manufacturer. > > How does the sinit blob verify the kernel ? It doesn't, really. My understanding is that it takes a hash of the contents of memory (and perhaps other state, I don't know) and submits this "measurement" to the TPM. The sinit blob doesn't contain any policy or configuration: it is only a mechanism for reducing the complete "system state" into a hash value. The hardware owner configures the TPM so that submitting specific "measurements" is required to use keys stored in the TPM. What those keys do is not specified by the TPM: for example, they may be used to allow access to an encrypted hard drive, or to sign the "remote attestation" data. > Can you add some documentation about that in the feature page request as > others have asked please ? I'm afraid I'm not the feature owner, only a semi-informed outsider. I'd love to see the feature page updated/expanded as well. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
2011/6/27 Miloslav Trmač : > The hardware owner configures the TPM so that submitting specific > "measurements" is required to use keys stored in the TPM. To avoid a misunderstanding, "hardware owner" is "the customer", not "hardware manufacturer". Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 32bit vs 64bit - 32bit can't handle 2100 in strtotime?
Once upon a time, Michał Piotrowski said: > I would like to note that I am aware of that 32 bit systems will not > work after 2038. But does that mean that they can not do simple date > conversion? Not if that "simple" date conversion uses the system time_t functions (which most of the common functions do). If you need to handle dates outside the range of 1970-2038, you'll need to use alternate functions that can handle the expected date range (and I don't know if such exist in PHP; you may have to code them yourself). Portable code should not assume system date routines can handle dates outside 1970-2038; you shouldn't depend on 64 bit systems having larger time_t (I don't think they all do). -- Chris Adams 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
[389-devel] Please review: Bug 697694 - rhds82 - incr update state stop_fatal_error "requires administrator action", with extop_result: 9
https://bugzilla.redhat.com/show_bug.cgi?id=697694 https://bugzilla.redhat.com/attachment.cgi?id=506109&action=diff https://bugzilla.redhat.com/attachment.cgi?id=506109&action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Plan for tomorrow's FESCo meeting (2011-6-27)
Stephen Gallagher (sgall...@redhat.com) said: > Following is the list of topics that will be discussed in the FESCo > > meeting tomorrow at 17:30UTC (1:30pm EDT) in #fedora-meeting on > irc.freenode.net. I thought the decision at last meeting was 1700 UTC/1pm EDT? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
longstanding pulseaudio bug. any workaround?
List, This bug https://bugzilla.redhat.com/show_bug.cgi?id=582798 has been around since F12. It was a minor annoyance than which has now turned into irritation. The fact that the sound menu is hidden deep inside in F15 doesn't help. Anyone know a workaround? Jitesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2011-06-16 x86_64
On Mon, Jun 27, 2011 at 08:03:17AM +0200, V?t Ondruch wrote: > Hi Matt, > > I just want to note that your script is not listing the package owners > correctly. There should be listed only people who have commit access, > but there are listed also people who just watch bugzilla and commits, > [1] for example. Unfortunately nobody of listed owners: > > rubygem-rack-1.1.0-2.fc14 (build/make) kanarip,mmorsi,stahnma,vondruch > > > can do something about it except kanarip. I originally had only the "package owner". I changed it to be "package owner and bugzilla cc: list" as, if you're signed up for cc: messages, you likely want to know, even if you can't commit a change to the package. (Some on cc: are provenpackagers). pkgdb does have a method for me to query only those with commit access, but I would prefer to leave it as-is, letting more people (those who have shown interest by signing up for bugzilla cc: list) get the notification rather than fewer (those who have commit rights), in hope of action being taken. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: longstanding pulseaudio bug. any workaround?
On Mon, 27.06.11 09:25, Jitesh Shah (jitesh.1...@gmail.com) wrote: > List, > This bug https://bugzilla.redhat.com/show_bug.cgi?id=582798 has been > around since F12. It was a minor annoyance than which has now turned > into irritation. The fact that the sound menu is hidden deep inside in > F15 doesn't help. > > Anyone know a workaround? Jack sensing is not really ready in the drivers yet. While many HDA drivers now support a jack sensing API via the Linux input subsystem PA does not make use of this and is unliekyl to anytime soon as most folks agree that misusing the input subsystem for jack sensing is a bad idea and a different solution should be sought. (Most likely based on the alsa control interface, see recent alsa-devel discussions about that). But that isn't upstream in neither ALSA nor PA. So, it might sound easy, but actually isn't. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: longstanding pulseaudio bug. any workaround?
..snip.. > Jack sensing is not really ready in the drivers yet. While many HDA > drivers now support a jack sensing API via the Linux input subsystem PA > does not make use of this and is unliekyl to anytime soon as most folks > agree that misusing the input subsystem for jack sensing is a bad idea > and a different solution should be sought. (Most likely based on the > alsa control interface, see recent alsa-devel discussions about > that). But that isn't upstream in neither ALSA nor PA. > > So, it might sound easy, but actually isn't. I see. Is there a way to alleviate the situation? eg. What is the commandline to manually switch between Plugged-in and plugged-out? (I can set it to some global shortcut key, so that I don't have to go reach the sound UI each time). Thanks, Jitesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2011-6-27)
On Mon, 2011-06-27 at 12:24 -0400, Bill Nottingham wrote: > Stephen Gallagher (sgall...@redhat.com) said: > > Following is the list of topics that will be discussed in the FESCo > > > > meeting tomorrow at 17:30UTC (1:30pm EDT) in #fedora-meeting on > > irc.freenode.net. > > I thought the decision at last meeting was 1700 UTC/1pm EDT? +1 -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: News from rebuild
- Original Message -
> From: "Paul Howarth"
> To: "Fedora perl development team"
> Sent: Friday, June 24, 2011 4:41:37 PM
> Subject: Re: News from rebuild
> On 06/24/2011 02:41 PM, Iain Arnell wrote:
> > 2011/6/24 Marcela Mašláňová:
> >>
> >> Another thing are filters. I suppose it isn't in Guidelines yet,
> >> but old
> >> filters doesn't work, because they do not have support in rpm. You
> >> can
> >> use something like this before prep section in your specfile.
> >> %{?perl_default_filter}
> >> %global __provides_exclude
> >> %{?__provides_exclude}|perl\\(XML::SAX::PurePerl\\)
> >> %global __requires_exclude
> >> %{?__requires_exclude}|perl\\(XML::SAX::PurePerl::DTDDecls\\)
> >
> > Marcela,
> >
> > since you're checking out all the specs as part of the rebuild, is
> > there any chance you could do a simple grep for old-style filtering
> > (i.e. __perl_provides, __perl_requires, filter_provides,
> > filter_requires) so that we have a list of all specs that need to be
> > fixed?
>
> Please bear in mind when fixing filters that some packagers may wish
> to
> keep their spec files EPEL-compatible; filters based on
> __perl_provides/__perl_requires can be retained harmlessly if filters
> based on __requires_exclude/__provides_exclude are added since rpm
> prior
> to 4.9 ignores that latter and rpm 4.9 onwards effectively ignores the
> former.
>
> Anyone that's stripped out buildroot definition/cleaning and/or
> defattr
> lines won't be concerned about EPEL compatibility though (at least not
> EPEL < 6).
>
> Paul.
> --
I'm sorry if I removed it from some packages, which you need. I fixed some
packages, which were using macro, which didn't work in last Fedora or two.
So, I thought no-one care about them much. You are right that these macros
are not the best thing because lost compatibility :-/
We might create some script for cpanspec to create/change missing parts
for different releases...
--
Marcela Mašláňová
BaseOS team Brno
--
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: longstanding pulseaudio bug. any workaround?
On Mon, 27.06.11 09:41, Jitesh Shah (jitesh.1...@gmail.com) wrote: > > ..snip.. > > > Jack sensing is not really ready in the drivers yet. While many HDA > > drivers now support a jack sensing API via the Linux input subsystem PA > > does not make use of this and is unliekyl to anytime soon as most folks > > agree that misusing the input subsystem for jack sensing is a bad idea > > and a different solution should be sought. (Most likely based on the > > alsa control interface, see recent alsa-devel discussions about > > that). But that isn't upstream in neither ALSA nor PA. > > > > So, it might sound easy, but actually isn't. > > I see. > > Is there a way to alleviate the situation? > eg. What is the commandline to manually switch between Plugged-in and > plugged-out? (I can set it to some global shortcut key, so that I > don't have to go reach the sound UI each time). Usually it's just a matter of switching profiles/ports by hand. You can do that in the sound capplet in gnome. If you want to do this on the command line you could do that on the ALSA level (i.e. find the right contro to switch with "alsamixer -c0", and then put together an "amixer -c0 ..." line doing the same.) Or you can do this on the PA level, simply use pacmd to execute the port/profile control command you want to execute. Use "pacmd help" for help. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [389-devel] Please review: add support for ldif files with changetype: add
ack On 06/27/2011 09:54 AM, Rich Megginson wrote: -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: writing Inf file shows SchemaFile = ARRAY(0xhexnum)
ack On 06/27/2011 09:55 AM, Rich Megginson wrote: -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Security updates for Firefox 4 in F-15
On 06/27/2011 07:52 PM, Mark Bidewell wrote > Debates like this expose a weakness in packaging philosophy. The > current philosophy seems to be all packages are equal. It really isn't http://fedoraproject.org/wiki/Critical_path_package http://fedoraproject.org/wiki/Updates_Policy Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2011-6-27)
=== #fedora-meeting: FESCO (2011-06-27) === Meeting started by sgallagh at 17:01:05 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-06-27/fesco.2011-06-27-17.01.log.html . Meeting summary --- * init process (sgallagh, 17:01:36) * AGREED: Cancel FESCo meeting on 2011-07-04 (sgallagh, 17:06:21) * #563 suggested policy: all daemons must set RELRO and PIE flags (sgallagh, 17:06:56) * ACTION: ajax to send out an email discussing %optflags vs. binutils (sgallagh, 17:11:03) * #608 F16Feature: Trusted Boot - http://fedoraproject.org/wiki/Features/Trusted_Boot (sgallagh, 17:11:51) * AGREED: Trusted Boot is declined as a Feature. Continued work on this will be negotiated by the tboot developers, not by FESCo. (sgallagh, 17:39:51) * #531 Orphaned package ownership claiming clarification (sgallagh, 17:40:47) * AGREED: Policy will change to ""If a package is in orphan state in pkgdb, feel free to take it and revivie it, no re-review needed. If it's depreciated, you must re-review and get admins to unblock it" (sgallagh, 17:49:42) * LINK: http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers looks like the page to update (at least one of) (nirik, 17:51:07) * #614 Proposed list of packages to drop due to FTBFS prior to F16 branching (sgallagh, 17:51:56) * AGREED: add this as a regular task for rel-eng every cycle at the same time as the orphan purge and drop packages that have failed to build since F(n)-2 (sgallagh, 18:03:27) * ACTION: nirik to ask mdomsch to write an SOP for FTBFS package removal, else work on it himself. (sgallagh, 18:08:14) * 615 Strategy for services that do not have systemd native unit files (sgallagh, 18:08:26) * AGREED: Option 3: We do as many upgrades as possible, and live with only partial success. (sgallagh, 18:48:53) * Next week's chair (sgallagh, 18:49:07) * ACTION: ajax will run the next FESCo meeting (sgallagh, 18:52:58) * Open Floor (sgallagh, 18:53:03) Meeting ended at 18:57:31 UTC. Action Items * ajax to send out an email discussing %optflags vs. binutils * nirik to ask mdomsch to write an SOP for FTBFS package removal, else work on it himself. * ajax will run the next FESCo meeting Action Items, by person --- * ajax * ajax to send out an email discussing %optflags vs. binutils * ajax will run the next FESCo meeting * nirik * nirik to ask mdomsch to write an SOP for FTBFS package removal, else work on it himself. * **UNASSIGNED** * (none) People Present (lines said) --- * sgallagh (113) * nirik (89) * pjones (56) * notting (35) * t8m (33) * Viking-Ice (28) * eparis (26) * ajax (18) * mmaslano (13) * abadger1999 (10) * zodbot (10) * cwickert (9) * simo (3) * mitr (1) * tatica (1) * llaumgui_zhukov (1) * mjg59 (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot 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: Security updates for Firefox 4 in F-15
On Mon, 2011-06-27 at 10:22 -0400, Mark Bidewell wrote: > I apologize for the long rant. Well...trying to think of a diplomatic way to put it, but I'd say the long rant is fine, but we've had the same discussion at least five times over the last couple of years and your post didn't seem to bring any new arguments, so I'm not sure we're going to reach any conclusions we didn't reach the last five times :) We _did_ come out with the personal repos - http://repos.fedorapeople.org/ - which can be used quite easily to do backports. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning a few packages
I have no use for these packages anymore, and didn't even really remember I owned them, until Ralf jumped in and fixed a ftbfs bug against isic filed all of 4 days ago without saying boo to me, other than suggesting in the bug that the AWOL maintainer dance be started after he'd already fixed the build. So thanks for the fix. And for the reminder that I still have ownership of some packages I just don't care about, I guess. I'll save the trouble of the whole AWOL stuff and just orphan it, along with three other packages: isic - ip stack integrity checker ip6sic ipv6 stack integrity checker ctrlproxy - an irc proxy rinputd - remote input daemon There's a ftbfs bug just filed against rinputd as well, looks like an easy fix, possibly even already fixed upstream, though it was only filed 4 days ago, so maybe not. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Jeroen van Meeuwen
Hans de Goede wrote: > Hi, > > Good to have you back! > I'm still busy elsewhere. I was pointed in the direction of this thread by someone else. Consider those ACL requests that I could find approved. -- Kind regards, -- kanarip -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Jeroen van Meeuwen
Sven Lankes wrote: > On Mon, Jun 27, 2011 at 10:38:20AM +0200, Christoph Wickert wrote: > > I'll ping Jeroen in the meantime, but we are both very busy with out > > dayjob. > > In that case approving one or all of the three people who have requested > commit access seems sensible. Which package is this? I do not recall a pending request for as many as three people at the same time. -- Kind regards, -- kanarip -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 717061] Change request (no review request ticket exists)
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=717061 Tom "spot" Callaway changed: What|Removed |Added Flag||fedora-cvs? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 717061] New: Change request (no review request ticket exists)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Change request (no review request ticket exists) https://bugzilla.redhat.com/show_bug.cgi?id=717061 Summary: Change request (no review request ticket exists) Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: perl-GDGraph3d AssignedTo: tcall...@redhat.com ReportedBy: tcall...@redhat.com QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, rc040...@freenet.de, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Package Change Request == Package Name: perl-GDGraph3d New Branches: el4 el5 el6 Owners: spot pghmcfc -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 717061] Change request (no review request ticket exists)
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=717061 --- Comment #1 from Jon Ciesla 2011-06-27 16:27:27 EDT --- Git done (by process-git-requests). -- 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
Does gnome-screensaver check the screen is locked before suspending or switching user?
When I suspend or switch user gnome-screensaver should kick in (and continue if successful). It seems* instead that gnome-screensaver kicks in on resume, or when I change back to the user. * I see a flash of the user's screen or (sometimes) the screenlock doesn't work at all. Anyone know? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Change to the orphan and deprecation policy
FESCo today approved a change to how orphan and deprecated packages are handled in Fedora. The prior policy was: - Packages that have been orphaned for more than three months require a re-review, regardless of whether or not they have been blocked. The new policy is: - Any package that is deprecated (i.e., blocked) requires a re-review before it can return to Fedora. Orphaned packages do not require a re-review. Note that orphaned packages will be deprecated once per release cycle. For more information, see: https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers Bill, on behalf of FESCo ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package drops due to FTBFS
On Thu, Jun 23, 2011 at 10:09:40AM -0500, Matt Domsch wrote: > Below are the of packages which have outstanding FTBFS bugs from > earlier Fedora releases. I've split them up by their 'dist' tag which > shows when they were last successfully built. > > I recommend and propose to FESCo that all non-building packages with > Fedora 12 and 13 dist tags be considered for dropping prior to > branching Fedora 16. At today's FESCo meeting, FESCo approved a policy to deprecate and block packages that FTBFS with dist tags of (N-2) and earlier, therefore .f12, .f13, and .f14 in prep for the f16 branch. At this point, there are no packages which FTBFS from that date which do not have a dist tag. https://fedoraproject.org/wiki/Deprecate_FTBFS_packages has been added to the Release Engineering Release SOP for comment and review enacting this. The packages below are the initial candidate list; packages which have new builds present in rawhide prior to branching f16 will no longer be considered candidates, so fix your packages sooner rather than later please... > Since Fedora 12: > > gnome-do-plugins-0.8.2-1.fc12 [u'599889 NEW'] (build/make) nushio,antiaircraft > guile-gnome-platform-2.16.1-4.fc12 [u'599864 NEW'] (build/make) laxathom > imgtarget-0.1.4-4.fc12 [u'599895 NEW'] (build/make) grof > kanatest-0.4.8-3.fc12 [u'631023 NEW'] (build/make) robmv > kdetv-0.8.9-13.fc12 [u'631359 NEW'] (build/make) subhodip > kpolynome-0.1.2-15.fc12 [u'599875 NEW'] (build/make) chitlesh > ktechlab-0.3.70-3.20090304svn.fc12 [u'631203 NEW'] (build/make) chitlesh > libctl-3.0.2-10.fc12 [u'599894 NEW'] > (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) > edhill,deji > libopensync-plugin-kdepim-0.22-6.fc12 [u'599881 NEW'] (build/make) awjb > multiget-1.2.0-7.fc12 [u'631052 NEW'] (build/make) guidoledermann,mtasaka > netgo-0.5-12.fc12 [u'631087 NEW'] (build/make) spot > notecase-1.6.1-6.fc12 [u'631448 NEW'] > (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) > bouska > photoprint-0.4.0-7.fc12 [u'599755 NEW'] (build/make) grof > pigment-0.3.17-3.fc12 [u'599828 NEW'] (build/make) thias > postgresql-pgpool-ha-1.1.0-8.fc12 [u'599834 NEW'] (build/make) devrim > qgo-1.5.4r2-3.fc12 [u'631091 NEW'] (build/make) orphan > qucs-0.0.15-4.fc12 [u'631404 NEW'] (build/make) tanguy > rubygem-cobbler-1.6.1-1.fc12 [u'599799 NEW'] > (unpackaged_files/python-egg-info?) jeckersb > starlab-4.4.3-7.fc12 [u'599988 ASSIGNED'] (build/make) lkundrak,mmahut > subtitlecomposer-0.5.3-3.fc12 [u'599833 NEW'] (build/make) tuxbrewr > xdx-2.4.1-3.fc12 [u'599818 NEW'] (build/make) bjensen,sindrepb > xsri-2.1.0-17.fc12 [u'599802 NEW'] (build/make) ssp > > > Since Fedora 13: > > automake15-1.5-29.fc13.1 [u'631216 NEW'] (build/make) karsten > automake16-1.6.3-18.fc13.1 [u'631215 NEW'] (build/make) karsten > db4o-7.4-2.fc13 [u'631066 NEW'] (build/make) pfj > fsvs-1.2.1-1.fc13 [u'631437 NEW'] (build/make) davidf,wolfy > gpar2-0.3-9.fc13 [u'631134 NEW'] (build/make) drago01 > gwave-2-18.20090213snap.fc13 [u'599862 NEW'] > (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) > chitlesh,tnorth > klibido-0.2.5-13.fc13 [u'631410 NEW'] (build/make) faucamp > linbox-1.1.7-0.2.svn3214.fc13 [u'631173 NEW'] (build/make) jjames > > > Since Fedora 14: > > agave-0.4.7-1.fc14 [u'631411 NEW'] (build/make) bonii > gnusim8085-1.3.6-1.fc14 [u'631067 NEW'] (build/make) sherry151,chitlesh > kazehakase-0.5.8-9.svn3873_trunk.fc14 [u'631305 NEW'] (build/make) mtasaka > link-grammar-4.6.7-3.fc14 [u'599978 NEW'] (build/make) uwog > rubygem-rcov-0.9.8-1.fc14 [u'631350 NEW'] (build/make) mmorsi > tilda-0.9.6-4.fc14 [u'631372 NEW'] (build/make) laxathom Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[dspam/el4] remove and obsolete dspam-web
commit e11cf862689bc37512dc0570bcb6030ab506aa46
Author: Nathanael D. Noblet
Date: Mon Jun 27 16:09:19 2011 -0600
remove and obsolete dspam-web
dspam.spec | 54 --
1 files changed, 12 insertions(+), 42 deletions(-)
---
diff --git a/dspam.spec b/dspam.spec
index d53207d..860fde6 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -9,7 +9,7 @@
Summary:A library and Mail Delivery Agent for Bayesian SPAM
filtering
Name: dspam
Version:3.9.0
-Release:8%{?dist}
+Release:9%{?dist}
License:GPLv2
Group: System Environment/Daemons
Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@ -50,6 +50,7 @@ other MTA that supports an external local delivery agent
(qmail, etc.)
%package libs
Summary:The DSPAM library core processing engines
Group: System Environment/Libraries
+Obsoletes: dspam-web
%description libs
The DSPAM core processing engine, also known as libdspam, provides all
@@ -116,14 +117,14 @@ This library can be used by developers to provide
'drop-in' spam
filtering for their mail client applications, other Anti-Spam tools, or
similar projects.
-%package web
-Summary:Web-based interface for DSPAM
-Group: System Environment/Daemons
-Requires: dspam = %{version}-%{release}
-Requires: webserver
+#%package web
+#Summary:Web-based interface for DSPAM
+#Group: System Environment/Daemons
+#Requires: dspam = %{version}-%{release}
+#Requires: webserver
-%description web
-Web-based interface for DSPAM's powerful Anti-Spam engine.
+#%description web
+#Web-based interface for DSPAM's powerful Anti-Spam engine.
%prep
@@ -170,13 +171,6 @@ make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"
%{__install} -d -p -m 755 $RPM_BUILD_ROOT%{_var}/run/dspam/
%{__install} -Dp -m 755 %{SOURCE5} $RPM_BUILD_ROOT%{_bindir}/dspam-front
-# webui
- %{__install} -d -p -m 755 $RPM_BUILD_ROOT%{_datadir}/dspam-web/templates/
-for foo in webui/cgi-bin/templates/??
-do
-[ -d "${foo}" ] && %{__install} -d p -m 755
$RPM_BUILD_ROOT%{_datadir}/dspam-web/templates/${foo##*\/}
-done
-
# remove .la and .a files
find $RPM_BUILD_ROOT -name *.la -exec rm {} \;
find $RPM_BUILD_ROOT -name *.a -exec rm {} \;
@@ -229,28 +223,6 @@ echo "Scanned and tagged as non-SPAM with DSPAM %{version}
by Your ISP.com"> $RP
#make sure CHANGELOG is in utf-8 format
iconv -f iso8859-1 -t utf-8 CHANGELOG > CHANGELOG.conv && mv -f CHANGELOG.conv
CHANGELOG
-# web
-%{__mkdir} -p $RPM_BUILD_ROOT%{_datadir}/%{name}-web/templates/
-%{__install} -p -m0755 webui/cgi-bin/templates/*.pl
$RPM_BUILD_ROOT%{_datadir}/%{name}-web/templates/
-%{__install} -p -m0644 webui/htdocs/*.{css,gif}
$RPM_BUILD_ROOT%{_datadir}/%{name}-web/
-%{__install} -p -m0644 webui/cgi-bin/templates/*.html
$RPM_BUILD_ROOT%{_datadir}/%{name}-web/templates/
-%{__install} -p -m0644 webui/cgi-bin/{admins,default.prefs,rgb.txt}
$RPM_BUILD_ROOT%{_datadir}/%{name}-web/
-
-# setup configure.pl to by default expect the url to be /dspam so css and
images load
-%{__sed} -i -r -e '/CONFIG.*WEB_ROOT/s,"","/dspam",' webui/cgi-bin/configure.pl
-%{__install} -Dp -m0755 webui/cgi-bin/{configure.pl,*.cgi}
$RPM_BUILD_ROOT%{_datadir}/%{name}-web/
-
-for foo in webui/cgi-bin/templates/??
-do
-if [ -d "${foo}" ]
-then
-%{__install} -Dp -m0644 ${foo}/*.html
$RPM_BUILD_ROOT%{_datadir}/%{name}-web/templates/${foo##*\/}
-[ -f ${foo}/*.pl ] && %{__install} -p -m0755 ${foo}/*.pl
$RPM_BUILD_ROOT%{_datadir}/%{name}-web/templates/${foo##*\/}
-fi
-done
-%{__mkdir} -p $RPM_BUILD_ROOT%{_sysconfdir}/httpd/conf.d
-%{__install} -p -m0644 %{SOURCE4} $RPM_BUILD_ROOT%{_sysconfdir}/httpd/conf.d/
-
%post
/sbin/chkconfig --add %{name}
if [ $1 -gt 1 ]; then
@@ -355,12 +327,10 @@ exit 0
%{_libdir}/pkgconfig/dspam.pc
%{_mandir}/man3/*
-%files web
-%defattr(-,root,root,-)
-%{_datadir}/dspam-web/
-%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
-
%changelog
+* Mon Jun 27 2011 Nathanael Noblet - 3.9.0-9
+- Remove and obsolete dspam-web
+
* Tue Jul 13 2010 Nathanael Noblet - 3.9.0-8
- Fix dspam data dir permissions to be writeable by mail (Reported by Jonas
Pasche)
--
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
Cairo with OpenGL backend
Just curious, did anyone try Cairo with OpenGL backend under Fedora (i.e. so that components that use Cairo, such as GTK+ etc. all use OpenGL for rendering)? If so, what was the experience like? -- Bojan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security updates for Firefox 4 in F-15
On 2011-06-26 12:33, Christoph Wickert wrote: > And I have no idea what part of our update policy should be violated by > this update. Please somebody enlighten me. This part: * Avoid changing the user experience if at all possible. Specifically, the update breaks a number of user-installed extensions because the extensions expect a certain version string. This is a functional regression regardless of whether or not the extension API changed. Please do not misconstrue this message as a value judgment. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2011-6-27)
> * #531 Orphaned package ownership claiming clarification (sgallagh, > 17:40:47) > * AGREED: Policy will change to ""If a package is in orphan state in > pkgdb, feel free to take it and revivie it, no re-review needed. If > it's depreciated, you must re-review and get admins to unblock it" > (sgallagh, 17:49:42) > * LINK: > > http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers > looks like the page to update (at least one of) (nirik, 17:51:07) Hopefully the word "deprecate" will be used in the policy language: http://linguisticszone.blogspot.com/2007/05/depreciate-or-deprecate.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Jeroen van Meeuwen
Dne 27.6.2011 14:44, Hans de Goede napsal(a): > Hi, > > Good to have you back! > > On 06/27/2011 01:53 PM, Jeroen van Meeuwen wrote: >> Vít Ondruch wrote: >>> I'm following the procedure at: >>> >>> http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers >>> >>> Does anyone know how to contact Jeroen van Meeuwen? He is not answering >>> e-mails at his listed address or the following Bugzilla reports: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=707934 >>> https://bugzilla.redhat.com/show_bug.cgi?id=707937 >>> >>> There is also many other Jeroen's packages which would need some >>> maintenance. >>> >> Boo. >> > Hmm, not really helpful, and I'm also not sure if this falls under > "be excellent to each other" > > Perhaps you coulb so kind as to respond to the request others have made to > become co-maintainers of your packages? > > Regards, > > Hans I have been already approved for several packages I requested, so thank you Jeroen. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
