Re: Akonadi's unix sockets location
On Tue, Mar 16, 2010 at 12:43:16PM -0400, Daniel J Walsh wrote: > Ok if they are from the same login session and same UID it is reasonable > to expect them to share /tmp. Iirc, it would be more FHS compliant to use /var/tmp instead. Regards Till pgp70p2xBXwfN.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFE] Few additions to Bodhi
Am Samstag, den 20.03.2010, 07:20 +0100 schrieb Kevin Kofler: > Thomas Spura wrote: > > KPackageKit != Bodhi: > > > > When you use fedora-easy-karma or the updates site to provide testing > > feedback, it would be nice to have such a %changelog field, *expecially* > > if there are no updates notes shipped with the package. In this case it > > would be absolutely nessesary to have at least the changelog as notes > > there (if not getting the extra field). > > On https://admin.fedoraproject.org/updates/ , there's a Builds: field for > each update, click on one of the builds to get to its Koji build page which > also contains changelog info. Changelog info is per SRPM, not per update > group, so it can't really be done any faster, you need to select the SRPM > you want to view updates for. (You'll notice that for grouped updates, the > PackageKit frontends will display different changelogs depending on which > package from the group you're viewing the details for.) > > As for fedora-easy-karma, the script just needs to add the required Koji or > yum/repoquery queries, that doesn't have to be done on the server end at > all. That doesn't solve the lack of notes in bodhi. When bodhi greps them, they propagate anywhere else so there is no double work to do e.g. in fedora-easy-karma or some "?PackageKit" and so on and nobody needs to click throught koji (The builds field contains a search pattern, which means this would save some traffic in koji, too.). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Sat, 20.03.10 10:34, Till Maas (opensou...@till.name) wrote: > On Tue, Mar 16, 2010 at 12:43:16PM -0400, Daniel J Walsh wrote: > > > Ok if they are from the same login session and same UID it is reasonable > > to expect them to share /tmp. > > Iirc, it would be more FHS compliant to use /var/tmp instead. No. Unix sockets should definitely be cleaned up on reboot. Hence they belong in /tmp better than in /var/tmp. http://www.pathname.com/fhs/2.2/fhs-5.15.html Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Sat, Mar 20, 2010 at 11:34:58AM +0100, Lennart Poettering wrote: > On Sat, 20.03.10 10:34, Till Maas (opensou...@till.name) wrote: > > > On Tue, Mar 16, 2010 at 12:43:16PM -0400, Daniel J Walsh wrote: > > > > > Ok if they are from the same login session and same UID it is reasonable > > > to expect them to share /tmp. > > > > Iirc, it would be more FHS compliant to use /var/tmp instead. > > No. > > Unix sockets should definitely be cleaned up on reboot. Hence they > belong in /tmp better than in /var/tmp. Why do they need to be cleaned up on reboot? The problem with sharing files between applications using /tmp is this specification: http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES | Programs must not assume that any files or directories in /tmp are | preserved between invocations of the program. So in case there will be a file system for /tmp that automatically removes files once they are not open anymore, abusing /tmp for this will fail. Regards Till pgpI0hBm6QZcP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Sat, 20.03.10 12:42, Till Maas (opensou...@till.name) wrote: > > Unix sockets should definitely be cleaned up on reboot. Hence they > > belong in /tmp better than in /var/tmp. > > Why do they need to be cleaned up on reboot? After the program that listened on them exited they are useless and cannot be reused, they hence *must* be removed before another program can listen on them again. > The problem with sharing files between applications using /tmp is this > specification: > > http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES > | Programs must not assume that any files or directories in /tmp are > | preserved between invocations of the program. > > So in case there will be a file system for /tmp that automatically > removes files once they are not open anymore, abusing /tmp for this > will fail. Uh? First of all, such an fs does not exist. Secondly, as mentioned a unix socket is useless in the fs after the program that listened on it exited, hence automatically deleting the unix socket as soon as it exited would actually be a good idea. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100317 changes
On Sat, Mar 20, 2010 at 07:38:43AM +0100, Kevin Kofler wrote: > Till Maas wrote: > > These requirements render the karma automatism useless for all branches > > except F13, because the fedora-packager package in F12 was iirc pushed > > automatically after it received enough testing. If this implies, that > > that the package should also be pushed in F13, then this should happen > > automatically, too. Automatic default behaviour that leads to failure > > should not exist. > > Karma automatism is completely broken and useless, how's that news? If this is common knowledge, why does it still exist? > It's quite sad that the rest of FESCo wants to rely on such brokenness even > more in the future (with me being the only one who refused to vote for such > a broken plan which just smells of failure). Numeric karma should be > abolished entirely, not made a requirement for anything. IMHO numeric karma is better than nothing, but I agree that it can be improved a lot. Regards Till pgpxR21lOEpVu.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning xine-ui: maintainers / comaintainers needed
Hi, I find myself busy at $DAYJOB, so I don't have the time necessary to maintain xine-ui. I'm going to orphan the package (pkgdb didn't let me do it just a while ago), so I'm asking for maintainers and comaintainer candidates to request access to the relevant branches in pkgdb. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On 03/20/2010 07:48 AM, Lennart Poettering wrote: > Secondly, as mentioned a unix socket is useless in the fs after the > program that listened on it exited, You mean in the context of a 'shared secret'-named sockets, right? In general. a socket /tmp/socket can just sit there and be reused by whatever programs fancy to open it for reading and/or writing. Or have I misunderstood something in this discussion? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100320 changes
Compose started at Sat Mar 20 08:15:38 UTC 2010 Broken deps for i386 -- edje-0.9.93.063-1.fc14.i686 requires libembryo-ver-svn-05.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_job.so.0 emotion-0.1.0.042-5.fc12.i686 requires libevas.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_fb.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_x.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_txt.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_job.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_con.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedbus.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libevas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libehal.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_fb.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_x.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_ipc.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedje.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_file.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet_mime.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libedje.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 ewl-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet.so.0 ewl-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet_mime.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_evas.so.0 hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 inkscape-0.47-6.fc13.i686 requires libMagick++.so.2 inkscape-0.47-6.fc13.i686 requires libMagickCore.so.2 inkscape-view-0.47-6.fc13.i686 requires libMagick++.so.2 inkscape-view-0.47-6.fc13.i686 requires libMagickCore.so.2 murmur-1.1.8-15.fc12.i686 requires libIce.so.33 murmur-1.1.8-15.fc12.i686 requires libIceUtil.so.33 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas.so.2 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas_hg.so.2 paperbox-0.4.4-2.fc12.i686 requires libtrackerclient.so.0 php-pecl-imagick-2.2.2-4.fc12.i686 requires libMagickWand.so.2 php-pecl-imagick-2.2.2-4.fc12.i686 requires libMagickCore.so.2 pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0 python-docs-2.6.4-3.fc13.noarch requires python = 0:2.6.4 q-magick-7.11-6.fc12.i686 requires libMagickCore.so.2 rss-glx-0.9.1.p-2.fc13.i686 requires libMagickCore.so.2 rss-glx-0.9.1.p-2.fc13.i686 requires libMagickWand.so.2 rubygem-right_aws-1.10.0-3.fc14.noarch requir
Re: Akonadi's unix sockets location
On Sat, 20.03.10 10:37, Przemek Klosowski (przemek.klosow...@nist.gov) wrote: > > On 03/20/2010 07:48 AM, Lennart Poettering wrote: > > > Secondly, as mentioned a unix socket is useless in the fs after the > > program that listened on it exited, > > You mean in the context of a 'shared secret'-named sockets, right? > In general. a socket /tmp/socket can just sit there and be reused > by whatever programs fancy to open it for reading and/or writing. Or > have I misunderstood something in this discussion? No. Unix sockets cannot be reused. If the application that created the socket via calling bind() for the path closed the socket, the socket node is useless in the file system. Another bind() on it will return ADDRINUSE and a connect() on it will return ECONNREFUSED. Only after it was deleted it may be created anew with bind() and then be used again. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100320 changes
Compose started at Sat Mar 20 09:15:21 UTC 2010 Broken deps for i386 -- doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 -- doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 doodle-0.6.7-5.fc12.x86_64 requires libextractor.so.1()(64bit) hornsey-1.5.2-0.1.fc13.x86_64 requires libclutter-gst-0.10.so.0()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) pyclutter-gst-0.9.2-1.fc12.x86_64 requires libclutter-gst-0.10.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Moose/devel .cvsignore, 1.38, 1.39 auto.ini, 1.1, 1.2 perl-Moose.spec, 1.53, 1.54 sources, 1.38, 1.39
Author: cweyl
Update of /cvs/extras/rpms/perl-Moose/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv8166
Modified Files:
.cvsignore auto.ini perl-Moose.spec sources
Log Message:
* Fri Mar 12 2010 Chris Weyl 0.99-1
- update by Fedora::App::MaintainerTools 0.006
- updating to latest GA CPAN version (0.99)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-Moose/devel/.cvsignore,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -p -r1.38 -r1.39
--- .cvsignore 20 Feb 2010 03:26:50 - 1.38
+++ .cvsignore 20 Mar 2010 17:46:23 - 1.39
@@ -1 +1 @@
-Moose-0.98.tar.gz
+Moose-0.99.tar.gz
Index: auto.ini
===
RCS file: /cvs/extras/rpms/perl-Moose/devel/auto.ini,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- auto.ini13 Feb 2010 06:18:47 - 1.1
+++ auto.ini20 Mar 2010 17:46:23 - 1.2
@@ -1,3 +1,11 @@
+
+; This is probably an odd choice to try fully-managed mode out on, as we have
+; a subpackage to deal with, but... Why not :)
+
+[common]
+; Set to 0 to DISABLE all description/prep/build/etc management.
+is_fully_managed=1
+
[add_build_requires]
; optional test #1 (in no particular order)
; ** moved to author tests
@@ -29,3 +37,103 @@ perl(Test::Warn)=0
perl(Test::Output)=0
; optional test #10
perl(DateTime::Calendar::Mayan)=0
+
+[spec_description]
+content= = 0.02
+
%{?perl_default_filter}
%{?perl_default_subpackage_tests}
%description
Moose is an extension of the Perl 5 object system.
-Moose is built on top of Class::MOP, which is a metaclass system for
-Perl 5. This means that Moose not only makes building normal Perl 5
-objects better, but it also provides the power of metaclass programming.
-such things. Moose is different from other Perl 5 object systems because
-it is not a new system, but instead an extension of the existing one.
-
-While Moose is very much inspired by Perl 6, it is not itself Perl
-6. Instead, it is an OO system for Perl 5. I built Moose because I was
-tired or writing the same old boring Perl 5 OO code, and drooling over
-Perl 6 OO. So instead of switching to Ruby, I wrote Moose :)
+The main goal of Moose is to make Perl 5 Object Oriented programming easier,
+more consistent and less tedious. With Moose you can to think more about what
+you want to do and less about the mechanics of OOP.
+
+Additionally, Moose is built on top of Class::MOP, which is a metaclass system
+for Perl 5. This means that Moose not only makes building normal Perl 5
+objects better, but it provides the power of metaclass programming as well.
+Moose is different from other Perl 5 object systems because it is not a new
+system, but instead an extension of the existing one.
%package -n perl-Test-Moose
License:GPL+ or Artistic
@@ -76,28 +76,24 @@ very welcome.
%prep
%setup -q -n Moose-%{version}
-# tidy things up...
-find t/ -type f -exec perl -pi -e 's|^#!/usr/local/bin|#!/usr/bin|' {} +
-find . -name '*.orig' -exec rm -v {} +
-find . -type f -exec chmod -c -x {} +
-
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="%{optflags}"
make %{?_smp_mflags}
-
%install
rm -rf %{buildroot}
make pure_install DESTDIR=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} +
-find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
+find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
+
%clean
rm -rf %{buildroot}
@@ -116,6 +112,10 @@ rm -rf %{buildroot}
%{_mandir}/man3/Test::Moose*
%changelog
+* Fri Mar 12 2010 Chris Weyl 0.99-1
+- update by Fedora::App::MaintainerTools 0.006
+- updating to latest GA CPAN version (0.99)
+
* Sat Feb 20 2010 Chris Weyl 0.98-1
- update by Fedora::App::MaintainerTools 0.003
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Moose/devel/sources,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -p -r1.38 -r1.39
--- sources 20 Feb 2010
Re: comps submission error
Noriko Mizumoto píše v Čt 18. 03. 2010 v 11:55 +1000: > Hi, > > While submitting, the error of "Sorry, your file could not be sent > because of an error." has been encountered. The last submission is "The > component master of the comps project has been changed by raven 6 days, > 2 hours ago." This last entry would be some work for repo migration from > cvs to git. It seems no PO successful submission after this. I'm confirming that Transifex does not working last few days. I double checked my PO file (with --strict too). It seems like Transifex <=> GIT breakage. Sorry for cross-posting. I would like to submit last fine-tuned changes for my language. M.K. https://translate.fedoraproject.org/projects/p/comps/c/master/ -- Milan Keršláger http://www.pslib.cz/ke/ http://www.nti.tul.cz/wiki/Milan.Kerslager -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: main problems of fedora?
Am Mittwoch, den 17.03.2010, 19:32 +0100 schrieb Gergely Buday: > Hi there, Shalom & As-Salāmu `Alaykum > is there a list of known deficiencies of fedora - I mean those which > can be cured by developing new software, rather than fixing bugs? Or, > if such list does not exist, can you name a few missing item from > fedora? Think of relatively small would-be software, without a GUI. Can the missing of some CLI software being a main problem of fedora? Fedora has a lot of CLI-software. What software do you think is missing? The only CLI software I'm really missing is a well worked anaconda CLI and a slim gui install system without firstboot which requires metacity. Why should users of the KDE system install metacity and the half gnome desktop? Sorry, but this doesn't make sense to me. Every time I hear firstboot I want to do my first shutdown, because I'm sure that adding users and deal with smolt can be handled in the installer and the LICENSE should be definitly displayed BEFORE the user can install software! On my wishlist is an anaconda-text-installer (and a slim gui installer of course) on the top which is easy to use and gives you a lot functionality, like the BSD-Installer http://www.bsdinstaller.org > - Gergely -- Mit freundlichen Grüßen aus dem schönen Hainzell Simon Wesp http://www.fedoraproject.org/wiki/SimonWesp signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: main problems of fedora?
On 03/21/2010 04:47 AM, Simon Wesp wrote: > . Every time I hear > firstboot I want to do my first shutdown, because I'm sure that adding > users and deal with smolt can be handled in the installer and the > LICENSE should be definitly displayed BEFORE the user can install > software! > Firstboot is designed as separate program for good reasons. Think OEM setups for example and Fedora has no EULA so there is no need to display it at the start of the installation process. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
