Re: gimp
On 08/23/2011 11:34 PM, Itamar Reis Peixoto wrote: On Tue, Aug 23, 2011 at 5:24 PM, Richard Shaw wrote: On Tue, Aug 23, 2011 at 11:50 AM, Genes MailLists wrote: Are there any plans to bring gimp 2.7.x - 2.8 into F16 ? Is there a specific reason to? The home page states that the whole 2.7.x series should be considered unstable. is this a good reason ? http://tech.slashdot.org/story/11/08/23/1355225/The-GIMP-Now-Has-a-Working-Single-Window-Mode No, that single window mode is not such a good reason, the feature is... cute but not excessively useful, the real reason is the 2.8 release is long overdue (expected since last December) and quite a few features were added: more gegl integration, better usability, linked layers etc. And we the people using it for real work still remember the times when Fedora used to be a bleeding edge distro and had such GIMP updated... happy old times... Hopefully Luya will update his unofficial build: http://repos.fedorapeople.org/repos/luya/gimp/ -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to ignore LD_LIBRARY_PATH
On 08/23/2011 11:44 AM, Orion Poplawski wrote: See https://bugzilla.redhat.com/show_bug.cgi?id=719785 for the motivation The environment module system allows users to modify their environment in a predictable way, including setting LD_LIBRARY_PATH. However, this makes it possible to break the modulecmd binary by putting an incompatible TCL (or other) library earlier in the path. It would be great if modulecmd were made impervious to such things, but I don't know the best or acceptable method to do this. I'm guessing using rpaths would be the easiest. Thoughts/suggestions? IMNSHO disabling LD_LIBRARY_PATH is a bad thing. A user may need it for some reason that you don't anticipate. If someone uses LD_LIBRARY_PATH, it is up to them to make sure that they don't force incompatible libraries to be loaded. If they report bugs against Fedora packages (including the environment module system) due to library incompatibilities when using LD_LIBRARY_PATH, I think the correct response is to tell them not to do that, and that it is not a bug in the package. Generally the correct thing to do if an application is incompatible with the system-supplied Tcl is to rebuild that application. Granted, that's not possible with closed-source software like the Xilinx ISE referenced in that bug. However, I don't see it as a job of Fedora to fix problems in proprietary software. As it happens, I actually use Xilinx ISE myself, and while I hadn't tried it with the environment module system, if I did do that and had trouble with it, and you told me that it wasn't supported, I would simply use it without the environment module system. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bug in fuse-s3fs
If you open a bug on fuse-s3fs with the problem you encountered, I'll gladly fix it. ok, https://bugzilla.redhat.com/show_bug.cgi?id=732939 I've tried the google code s3fs as well, and not had any luck in fixing it up. I think thats probably a dead end. I've tried the rpm in the review request and it worked as charm I'd installed ntp and activated ntpd I've also needed to install fuse (in order to use it in /etc/fstab) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On 24 August 2011 01:35, JB jb.1234a...@gmail.com wrote: ...do not expect them to accept your sick world domination drive ...and this is why some upstream developers have unsubscribed from fedora-devel list. Ever wonder why people like David Zeuthen unsubscribed? People like you. I'm also --- --- this close to unsubscribing also. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Tue, Aug 23, 2011 at 06:11:45PM -0400, Tom Lane wrote: Another way of saying this is: people are used to being able to check if a service is up without thereby changing its state. Consider for example somebody who has a nagios alert set to check database server availability every few seconds. If that probe results in Yes, but I think this kind of monitoring appeared because SysV initscript is not reliable in determining service status. Even status command sometimes checkes only existence of PID file, not the real status. In world with systemd, monitoring can just ask systemd if service is running. Systemd will provide reliable answer, and if service is not running, will provide information for how long it is stopped and what was the reason for failure. -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seamonkey status
On 08/22/2011 03:01 AM, Kai Engert wrote: On 20.08.2011 13:59, Rahul Sundaram wrote: On 08/20/2011 03:57 PM, Matěj Cepl wrote: Putting Firefox maintainers on CC to have a definite word on this, but I suspect that Seamonkey is generally completely in the arms of community. I guess if anybody wants to take it over formally in pkgdb he would be welcome. Chris and Kai, am I right? I dont know what community means in this context. Everything is in the hands of the community in Fedora but the question is who is maintaining it? Apparently, noone is keeping it updated. If so, orphan it properly I worked on it during the weekend. Thanks. Can you fix the spec to follow the packaging guidelines? Add comments when there is a necessity to deviate Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bug in fuse-s3fs
On Wed, Aug 24, 2011 at 11:36:55AM +0300, Muayyad AlSadi wrote: If you open a bug on fuse-s3fs with the problem you encountered, I'll gladly fix it. ok, https://bugzilla.redhat.com/show_bug.cgi?id=732939 Thanks, I'll take care of it today. Neil I've tried the google code s3fs as well, and not had any luck in fixing it up. I think thats probably a dead end. I've tried the rpm in the review request and it worked as charm I'd installed ntp and activated ntpd I've also needed to install fuse (in order to use it in /etc/fstab) -- 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: Seamonkey status
On 24.08.2011 12:04, Rahul Sundaram wrote: On 08/22/2011 03:01 AM, Kai Engert wrote: On 20.08.2011 13:59, Rahul Sundaram wrote: On 08/20/2011 03:57 PM, Matěj Cepl wrote: Putting Firefox maintainers on CC to have a definite word on this, but I suspect that Seamonkey is generally completely in the arms of community. I guess if anybody wants to take it over formally in pkgdb he would be welcome. Chris and Kai, am I right? I dont know what community means in this context. Everything is in the hands of the community in Fedora but the question is who is maintaining it? Apparently, noone is keeping it updated. If so, orphan it properly I worked on it during the weekend. Thanks. Can you fix the spec to follow the packaging guidelines? Add comments when there is a necessity to deviate I would appreciate contributions, reviews, specific proposals. Thanks Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
Nicu Buculei wrote: And we the people using it for real work still remember the times when Fedora used to be a bleeding edge distro and had such GIMP updated... +1 The new update strategy (because it IS new, contrary to what some lazy maintainers who always refused to follow the old policy out of sheer laziness are claiming) just makes no sense, is the exact opposite of what more than ⅔ of our users are asking for (see the FedoraForum poll on the subject, made prior to the change) and is destroying what used to be a major selling point for Fedora. It is also utterly ridiculous and pointless if you consider the fact that the Firefox maintainers are allowed to push major (first digit! Not minor like 2.6 to 2.8) version increments as security updates… (Ironically, Firefox used to be one of those odd packages NOT doing feature upgrades when the rest of the distro was getting them. They seem to have fun always doing the exact opposite of Fedora policy.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Richard Hughes hughsient at gmail.com writes: On 24 August 2011 01:35, JB jb.1234abcd at gmail.com wrote: ...do not expect them to accept your sick world domination drive ...and this is why some upstream developers have unsubscribed from fedora-devel list. Ever wonder why people like David Zeuthen unsubscribed? People like you. I'm also --- --- this close to unsubscribing also. Richard. Richard, before you do it, read his post again and his insinuations about conspiracies and other staff ! If this is his state of mind about the project quality and people on this list who try to help him and themselves, then I propose that he unsubscribes from this list as well. Do you know how many people disappeared from Fedora orbit entirely or stopped with F14 release due to his systemd project alone ? Do you remember world's reaction on www.osnews.com to his world domination plans with regard to systemd and GNOME project ? This guy is a loose cannon, with an outsized ego, but lacking UNIX understanding and design skills. There is a video on Youtube (I can not find the link right now, it is on www.osnews.com article in comments section) from a German Linux sysadmin presentation in Munich, in 2009 I believe - with Lennart present in the audience and constantly interrupting the presenter and putting him down. Read the comments there by people who watched it ! Lennart, if you read this post go back to that video recording and experience it again. After that come back here and apologize for your attitude ! You do not deserve to be treated so well by us ! It is an embarrassment to watch this list's threads regarding systemd, its deficiencies, havoc it has caused, and these sysadmin software dev people trying to straighten things up, and his refusal to do it (or even consider it). JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, Aug 24, 2011 at 12:18:57PM +, JB wrote: Richard Hughes hughsient at gmail.com writes: On 24 August 2011 01:35, JB jb.1234abcd at gmail.com wrote: ...do not expect them to accept your sick world domination drive ...and this is why some upstream developers have unsubscribed from fedora-devel list. Ever wonder why people like David Zeuthen unsubscribed? People like you. I'm also --- --- this close to unsubscribing also. Richard. Richard, before you do it, read his post again and his insinuations about conspiracies and other staff ! [...snip...] This thread really is starting to sound like personal vendetta and not worthwhile discussion of technical details. Seriously, cut it out. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
JB jb.1234abcd at gmail.com writes: ... There is a video on Youtube (I can not find the link right now, it is on www.osnews.com article in comments section) from a German Linux sysadmin presentation in Munich, in 2009 I believe - with Lennart present in the audience and constantly interrupting the presenter and putting him down. Read the comments there by people who watched it ! Lennart, if you read this post go back to that video recording and experience it again. After that come back here and apologize for your attitude ! You do not deserve to be treated so well by us ! ... Here it is. http://www.osnews.com/comments/24926 I really couldn't just let this occasion pass by Lennie on Thu 7th Jul 2011 22:12 UTC OK, this is a presentation by someone who manages many Linux-desktops and is used to how things used to be in the Unix/Linux world. Good or bad, things have changed in the last few years in most Linux distributions. The presenter is trying to explain what is has become more complicated or isn't even possible anymore with the new setup. 'luckily' Lennart Poettering was in the audience to 'help' explain why : http://www.youtube.com/watch?v=_ERAXJj142o The presentation is funny and sad at the same time. It shows you what he is like and what he thinks. Lennart Poettering has vision of what thinks need to be improved for Linux on the desktop (possible server too). But he seems to always want to do big changes and not every idea always actually reaches it's full potential. His intensions are obviously good, but maybe he doesn't work well with others as he doesn't let others choose what they want. Like with systemd, where he has basically said: the Linux API is the new Posix I've got a feeling Lennart Poettering will never be loved in the Linux community because of it. Especially not by the BSD-community ;-) Edited 2011-07-07 22:17 UTC Enjoy it ! JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/08/11 14:18, JB wrote: This guy is a loose cannon, with an outsized ego, but lacking UNIX understanding and design skills. Ok, it's getting clear, both of you won't become best friends. Assuming, all arguments were written to this list, please stop affronts on him. This has nothing to do with systemd's quality, however do you rate it. Thanks - -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOVPMeAAoJEOnz8qQwcaIWorQH/0WXPyHcXI7Kra9bQ1qGio6g DyVd7RIen+ue/7GYwnqPGbVLMWq43QOh6YBCuxO3h6s8xIxULRqsp1GTmJXzysgD zV4nZXYqkQxrkCeV1brv/8rG9FV1y4djxL6avMRM/VlvZkjF3U918XbfSEq/NRXW Gk1bvFbKR1KCmt06heDwEMHjf6cevah6VsWZBQbDgMt1sNof3nfJkDupd2FS93vm qGnnP7ScyUQA1dAbojhgrD6eWv8qsCSDf1Kg2WLDv5G7/KPVwBgndaWDTHjXgvn1 ugZxNNcstj4O8Mu8kS8MPCp5fO8q5iZK98RT5PGIuGf621QZtTM7pWAVnCaePBI= =d85W -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote: Simo Sorce s...@redhat.com writes: ... If instead the socket is listening but not really accepting and processing requests, then yes, you can have a deadlock. So socket activation is not transparent by any means and needs to be handled very carefully in terms of circular dependencies as they may actually introduce deadlocks that weren't there before. Yeah. Another way in which socket activation is not transparent is that code might try to determine whether the service is running by seeing whether a connection attempt succeeds. In such a case, having the service autostart is absolutely *not* the desired outcome. Both mysql and postgresql suffer from this problem --- there's no other way for mysqladmin ping to work, for example. This issue is currently preventing both of those databases from being packaged as socket-activated services. I could try to get the upstreams to think about inventing non-connection-based protocols for testing database server status, but I doubt that either one will be receptive. I fail to see any reason why you would want to socket-activate a database. Either you need the database, so it should start asap, or don't. Using socket-activation as a hammer to throw around as a way to make implicit dependencies between services is just wrong imho. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/23/2011 10:58 PM, Kevin Kofler wrote: Steve Grubb wrote: I think it was mentioned before that systemd is consuming a lot of memory. The amount quoted was actually ridiculously small considering both today's memory sizes and the fact that systemd is a singleton process. Plus, it can be reduced even further (by something like 90%!) by disabling SELinux. It's your security stuff which is consuming a lot of memory. Kevin Kofler Well not wanting to get into this war, this is a little bit of the chicken and the egg. The reason systemd has SELinux memory usage is because it wants to take on the functions that used to be done by other processes, like udev labeling of /dev. Impersonating processes requires SELinux labeling, while listening on sockets. Creating of content on tmpfs /run requires SELinux Labeling. So saying systemd has grown because of SELinux is stretching the truth a little. With that said, I like some of the features that systemd is bringing to the table, from a security point of view. Setting up CGroups properly. Always starting services with a clean environment, IE the parent of a service is init rather then some random admin that happened to restart it. SELinux has tons of AVC's over the years caused by an admin sitting in a random directory like /home/dwalsh or /root and starting a service. Lots of bugs have had to be fixed by services using the environment of the admin. Allowing us to potentially eliminate all services from ever talking to a tty. I have railed over the years about random root running daemons using /tmp, and I think systemd using namespacing to change a services view of /tmp is a good idea. I think using namespacing to eliminate the network is also a good idea, especially when combined with SELinux. One think we need to code up is some additional knowledge into systemd to say which Types can manage which services. For example we want to say NetworkManager_t can start/stop ntpd but not start/stop the apache server. Similarly we want to have a confined admin type webadm_t that can only start and stop the apache service. In Fedora 14/15 we do this by labeling the initrc script. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5U9vwACgkQrlYvE4MpobOuzgCgnyx3tceuOGuu5xpZNmMVzjaW m28An1tXwchUnjdBASir+QwXijPa2eam =w/w6 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote: On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote: Simo Sorce s...@redhat.com writes: ... If instead the socket is listening but not really accepting and processing requests, then yes, you can have a deadlock. So socket activation is not transparent by any means and needs to be handled very carefully in terms of circular dependencies as they may actually introduce deadlocks that weren't there before. Yeah. Another way in which socket activation is not transparent is that code might try to determine whether the service is running by seeing whether a connection attempt succeeds. In such a case, having the service autostart is absolutely *not* the desired outcome. Both mysql Why not? If the service is enabled but the daemon not currently running, is it so terrible for a connection test to cause the daemon to start? Remember, in systemd logic 'service enabled with socket activation, daemon not currently running' is effectively an 'on' state, not an 'off' state. If you wanted the database to be 'off' you should have the service disabled, and in that case, the ping test wouldn't cause the daemon to start. It generally is a bad idea to automatically restart a database based on a random connection. There many reasons why you may have stopped the db (or it may have stopped itself) and requires inspection before attempting a new restart. Having to battle with socket activation while in a critical situation is not a good idea. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-NOCpulse-Gritch
perl-NOCpulse-Gritch has broken dependencies in the rawhide tree: On x86_64: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-SOAP-Lite
perl-SOAP-Lite has broken dependencies in the rawhide tree: On x86_64: perl-SOAP-Lite-0.714-1.fc17.noarch requires perl(SOAP::Transport::TCP) On i386: perl-SOAP-Lite-0.714-1.fc17.noarch requires perl(SOAP::Transport::TCP) Please resolve this as soon as possible. -- 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: Default services enabled
On Wed, 2011-08-24 at 09:05 -0400, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/23/2011 10:58 PM, Kevin Kofler wrote: Steve Grubb wrote: I think it was mentioned before that systemd is consuming a lot of memory. The amount quoted was actually ridiculously small considering both today's memory sizes and the fact that systemd is a singleton process. Plus, it can be reduced even further (by something like 90%!) by disabling SELinux. It's your security stuff which is consuming a lot of memory. Kevin Kofler Well not wanting to get into this war, this is a little bit of the chicken and the egg. The reason systemd has SELinux memory usage is because it wants to take on the functions that used to be done by other processes, like udev labeling of /dev. Impersonating processes requires SELinux labeling, while listening on sockets. Creating of content on tmpfs /run requires SELinux Labeling. So saying systemd has grown because of SELinux is stretching the truth a little. I think you can say it is a plain lie, it's neither fault. Systemd took over some functions done by other processes so the memory is used by systemd and not by these other processes. It is a shift in which process uses what. It is true this memory is then carried around by systemd forever, but that's not a big deal. It saves a lot of time on process activation for changes that need to happen on the fly and when not used the kernel is perfectly capable of swapping out whatever is not needed. Yay for memory overcommitting kernels! And before people wonder if I am one of 4/5 try to shot systemd down, I am not. I think it has very good features, and just need to round some rough edges in order to make it easier to transition. And I say this even though systemd is giving my group a headache because there is a strong disconnect between the way it works and the way we start services in a sysv environment. With that said, I like some of the features that systemd is bringing to the table, from a security point of view. /me too! Setting up CGroups properly. Always starting services with a clean environment, IE the parent of a service is init rather then some random admin that happened to restart it. This is a truly good feature, the amount of pain people go through with SELinux because old init files carried the admin user context around instead of setting up the proper context is gone. Even people that knew what was going on were tricked regularly by this insanity, and it was all due to a very poor init system. SELinux has tons of AVC's over the years caused by an admin sitting in a random directory like /home/dwalsh or /root and starting a service. Lots of bugs have had to be fixed by services using the environment of the admin. Don't forget mismatching labels on files due to this and then the service fails to start at boot because at that point it is started with the right SELinux label and it is prevented access to its own files (just like it happens with some daemons when they are started as roo by mistake and then they refuse to work if you start them with their own users because their files are owned by root and not r/w by the unprivileged daemon user). Allowing us to potentially eliminate all services from ever talking to a tty. Another really goos thing! I have railed over the years about random root running daemons using /tmp, and I think systemd using namespacing to change a services view of /tmp is a good idea. I think using namespacing to eliminate the network is also a good idea, especially when combined with SELinux. Yes, we still need some change for stuff that unfortunately relies on /tmp like kerberos credentials caches. I hope we'll be able to move them under SSSD control soom so that will be one less problem on the road to make private, per-user, /tmp dirs. One think we need to code up is some additional knowledge into systemd to say which Types can manage which services. For example we want to say NetworkManager_t can start/stop ntpd but not start/stop the apache server. Similarly we want to have a confined admin type webadm_t that can only start and stop the apache service. In Fedora 14/15 we do this by labeling the initrc script. Excellent! Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On Wed, 24 Aug 2011 13:41:41 +0200, you wrote: Nicu Buculei wrote: And we the people using it for real work still remember the times when Fedora used to be a bleeding edge distro and had such GIMP updated... +1 The new update strategy (because it IS new, contrary to what some lazy maintainers who always refused to follow the old policy out of sheer laziness are claiming) just makes no sense, is the exact opposite of what more than ? of our users are asking for (see the FedoraForum poll on the subject, made prior to the change) and is destroying what used to be a major selling point for Fedora. In addition to the warning that Gimp 2.7.* is considered unstable and not to be used in production (aka in a distribution), it comes with a warning that they are cleaning up the API's and thus 3rd party plugins and scripts can be broken. So you are saying Fedora should go against the wishes of the Gimp developers, as well as endure the significant risk that plugins/scripts that users rely on may not work? It is also utterly ridiculous and pointless if you consider the fact that the Firefox maintainers are allowed to push major (first digit! Not minor like 2.6 to 2.8) version increments as security updates (Ironically, Firefox used to be one of those odd packages NOT doing feature upgrades when the rest of the distro was getting them. They seem to have fun always doing the exact opposite of Fedora policy.) It's not the Firefox maintainers, it is Mozilla who have decided that release numbers are irrelevant and that the bug fix release for Firefox 5 is Firefox 6. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help to build gimp-2.7.3
Luya Tshimbalanga wrote, at 08/24/2011 09:45 AM +9:00: Attempting to build rpm version of gimp 2.7.3 ended with failure from http://koji.fedoraproject.org/koji/taskinfo?taskID=3297263 For some reasons, I am puzzled about gimp-remote not built with this version while it did with 2.7.2. Can anyone check and suggest fix on the spec. Regards, Luya http://developer.gimp.org/NEWS says Changes in GIMP 2.7.3 = Source and build system: - Remove gimp-remote for good, it has been disabled for years Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote: On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote: Why not? If the service is enabled but the daemon not currently running, is it so terrible for a connection test to cause the daemon to start? Remember, in systemd logic 'service enabled with socket activation, daemon not currently running' is effectively an 'on' state, not an 'off' state. If you wanted the database to be 'off' you should have the service disabled, and in that case, the ping test wouldn't cause the daemon to start. It generally is a bad idea to automatically restart a database based on a random connection. There many reasons why you may have stopped the db (or it may have stopped itself) and requires inspection before attempting a new restart. Having to battle with socket activation while in a critical situation is not a good idea. You'd have the same problem with any init system that supports automatic service restarting. You can easily disable the service via systemctl. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
It could be built to be installed in parallel with 2.6 - which would allow those who want to test/play with it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On Wed, Aug 24, 2011 at 9:33 AM, Genes MailLists li...@sapience.com wrote: It could be built to be installed in parallel with 2.6 - which would allow those who want to test/play with it. The other option is for someone to build packages and host them on fedorapeople.org as a personal repository. I certainly wouldn't mind trying 2.7+ but I would like the ability to easily revert if I run into problems. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Am 24.08.2011 15:04, schrieb Simo Sorce: I fail to see any reason why you would want to socket-activate a database. Either you need the database, so it should start asap, or don't because systemd as shipped with F15 CAN NOT make sure that if it means i have started mysql mysqld is ready for connections and fire up on mysqld depending services independent what you try to define in Before/After and most of this services will fail or fail randomly depending on luck how fast mysqld was and at which time they was started since we have no longer a defined starting-order and it makes me simply TIRED explain this thousand times on this mailing-list and you guys do not try to understand nor rearding multiple linked bugreports https://bugzilla.redhat.com/show_bug.cgi?id=714426 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled - there is no problem with mysqld
Am 23.08.2011 23:28, schrieb Tom Lane: Yeah. Another way in which socket activation is not transparent is that code might try to determine whether the service is running by seeing whether a connection attempt succeeds. well if you have enabled the service and a listening socket it is the definition of RUNNING In such a case, having the service autostart is absolutely *not* the desired outcome. why not? if you have it enabled you expect that it is there Both mysql and postgresql suffer from this problem you see a problem where no problem is there's no other way for mysqladmin ping to work, for example and where is the problem? this is expected do you not undertsand the fact that if i ENABLE mysqld i expect that it is listening and if anything checks if mysql is available it has to get YES at answer if mysqld is enabled from the begin of the boot process This issue is currently preventing both of those databases from being packaged as socket-activated services. nothing is preventing anything because you see a problem where no problem exists and with your view you make problems on machines where a lot of services are depending on mysql i tried to explain this thousands of times and getting tired of your non-understanding that mysqld has to accept connections as soon as possible and if oyu do not want mysqld started so do NOT enable mysqld I could try to get the upstreams to think about inventing non-connection-based protocols for testing database server status, but I doubt that either one will be receptive they will reject you because you are the only person seeing a problem and not because there is one signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
FYI, I have placed JB on moderation on this list. I'll be happy to let through posts that are not personal attacks. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote: On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote: On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote: Why not? If the service is enabled but the daemon not currently running, is it so terrible for a connection test to cause the daemon to start? Remember, in systemd logic 'service enabled with socket activation, daemon not currently running' is effectively an 'on' state, not an 'off' state. If you wanted the database to be 'off' you should have the service disabled, and in that case, the ping test wouldn't cause the daemon to start. It generally is a bad idea to automatically restart a database based on a random connection. There many reasons why you may have stopped the db (or it may have stopped itself) and requires inspection before attempting a new restart. Having to battle with socket activation while in a critical situation is not a good idea. You'd have the same problem with any init system that supports automatic service restarting. You can easily disable the service via systemctl. You can do that if you are doing a planned outage. But not for unplanned ones. I am not saying automatic restarts should never be employed, only that not all software should be automatically restarted. I think databases shouldn't in most cases. But that's just my opinion on the specific case. That doesn't mean socket-activation shouldn't be employed in other cases. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Hi, On 08/24/2011 04:56 PM, Simo Sorce wrote: On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote: On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote: On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote: Why not? If the service is enabled but the daemon not currently running, is it so terrible for a connection test to cause the daemon to start? Remember, in systemd logic 'service enabled with socket activation, daemon not currently running' is effectively an 'on' state, not an 'off' state. If you wanted the database to be 'off' you should have the service disabled, and in that case, the ping test wouldn't cause the daemon to start. It generally is a bad idea to automatically restart a database based on a random connection. There many reasons why you may have stopped the db (or it may have stopped itself) and requires inspection before attempting a new restart. Having to battle with socket activation while in a critical situation is not a good idea. You'd have the same problem with any init system that supports automatic service restarting. You can easily disable the service via systemctl. You can do that if you are doing a planned outage. But not for unplanned ones. I am not saying automatic restarts should never be employed, only that not all software should be automatically restarted. I think databases shouldn't in most cases. But that's just my opinion on the specific case. That doesn't mean socket-activation shouldn't be employed in other cases. So maybe we need a socket-activate-once attribute for .service files, which makes systemd do the socket activation only once, hmm thinking of it, doesn't it do that already in the form of handing the listening fd over? So if a service is set to not auto restart the service I would expect the order would be: 1) systemd starts 2) systemd creates listening socket 3) connection comes in 4) systemd starts foodb, hands overlistening socket 5) foodb crashes 6) db is dead, no one listening to socket. Right? I guess that unless auto-restart is set for the service, systemd won't re-create the listening socket and start listening itself again on step 6. If it does I'm sure that the systemd authors are very reasonable people and we can tell them that socket activation should not imply auto-restart on daemon crash / exit (unless explicitly requested). Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Simo Sorce s...@redhat.com writes: On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote: On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote: It generally is a bad idea to automatically restart a database based on a random connection. There many reasons why you may have stopped the db (or it may have stopped itself) and requires inspection before attempting a new restart. Having to battle with socket activation while in a critical situation is not a good idea. You'd have the same problem with any init system that supports automatic service restarting. You can easily disable the service via systemctl. You can do that if you are doing a planned outage. But not for unplanned ones. I am not saying automatic restarts should never be employed, only that not all software should be automatically restarted. I think databases shouldn't in most cases. But that's just my opinion on the specific case. That doesn't mean socket-activation shouldn't be employed in other cases. FWIW, I do think that there may be use-cases for socket activation of a database. I'd like to support the option ... the problem is to do so without breaking existing, expected behaviors. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote: Simo Sorce s...@redhat.com writes: On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote: On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote: It generally is a bad idea to automatically restart a database based on a random connection. There many reasons why you may have stopped the db (or it may have stopped itself) and requires inspection before attempting a new restart. Having to battle with socket activation while in a critical situation is not a good idea. You'd have the same problem with any init system that supports automatic service restarting. You can easily disable the service via systemctl. You can do that if you are doing a planned outage. But not for unplanned ones. I am not saying automatic restarts should never be employed, only that not all software should be automatically restarted. I think databases shouldn't in most cases. But that's just my opinion on the specific case. That doesn't mean socket-activation shouldn't be employed in other cases. FWIW, I do think that there may be use-cases for socket activation of a database. I'd like to support the option ... the problem is to do so without breaking existing, expected behaviors. I am not sure you can, the only would be to have systemd have some way to get callbacks from service to know when they are actually ready to serve. This would make After more meaningful. Still wouldn't solve the problem of a probe ending up causing a database start, I don't think there is a way to do that if you allow socket-activation. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning techtalk-pse
I am orphaning the techtalk-pse package because the Gtk2::MozEmbed perl module will no longer be maintained in Fedora because gtkmozembed support has been removed from xulrunner. If upstream (or anybody) has the time to work on techtalk-pse and get it working with something like Gtk2::WebKit, I'm glad to pick up package maintenance again. (I would, but my perl skills go as far as running programs.) -- Ian Weller i...@ianweller.org _ \//_ All Hail the Beefy Miracle! /_/ beefymiracle.org \ \ pgpn00zspQTYU.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda memory requirements
On Sat, Aug 20, 2011 at 11:31:55AM -0700, John Reiser wrote: ... I understand that some one is working on reducing the memory footprint of anaconda. Will it be ready for F16? The treebuilder branch of lorax, where such a project is being developed, is not complete today. How much memory will anaconda require to install Fedora 16? Anaconda requires 768MB, and more (=1GB) if there is no swap partition. I'd love to see reduced memory requirements for anaconda in F16. Use the installer that is available on a Live spin, instead of using anaconda. Being live (running from media without install) might have other advantages in the stated environment: try-before-install (without modifying the harddrive), etc. FYI - The installer on live *is* Anaconda. The primary difference is that it doesn't use yum to install the system, it copies the live image to the target and resizes it. This avoids several large memory hits that happen during package install. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpzlQCcaWMrL.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-16 Branched report: 20110824 changes
Compose started at Wed Aug 24 13:15:20 UTC 2011 Broken deps for x86_64 -- 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpagent.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpmibs.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmp.so.25()(64bit) OpenImageIO-0.10.1-2.fc15.i686 requires libboost_program_options-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_thread-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_python-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_system-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libGLEW.so.1.5 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_regex-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_filesystem-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_regex-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_filesystem-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_program_options-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_system-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libGLEW.so.1.5()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_python-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_thread-mt.so.1.46.0()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) 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 gnome-python2-applet 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 emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit) evolution-mapi-3.1.3-1.fc16.i686 requires libcamel-1.2.so.27 evolution-mapi-3.1.3-1.fc16.i686 requires libcamel-provider-1.2.so.27 evolution-mapi-3.1.3-1.fc16.x86_64 requires libcamel-provider-1.2.so.27()(64bit) evolution-mapi-3.1.3-1.fc16.x86_64 requires libcamel-1.2.so.27()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(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 libgraph.so.4()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(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
Re: gimp
On 08/24/2011 05:11 PM, Kevin Kofler wrote: It is also utterly ridiculous and pointless if you consider the fact that the Firefox maintainers are allowed to push major (first digit! Not minor like 2.6 to 2.8) version increments as security updates… (Ironically, Firefox used to be one of those odd packages NOT doing feature upgrades when the rest of the distro was getting them. They seem to have fun always doing the exact opposite of Fedora policy.) I am sure you know better. Mozilla changed their release scheme. Blaming Fedora Firefox maintainers for that is just silly. Claiming this is being done for fun is insulting. Stop doing that. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On Wed, Aug 24, 2011 at 9:36 AM, Richard Shaw hobbes1...@gmail.com wrote: On Wed, Aug 24, 2011 at 9:33 AM, Genes MailLists li...@sapience.com wrote: It could be built to be installed in parallel with 2.6 - which would allow those who want to test/play with it. The other option is for someone to build packages and host them on fedorapeople.org as a personal repository. I certainly wouldn't mind trying 2.7+ but I would like the ability to easily revert if I run into problems. You mean something like this? http://repos.fedorapeople.org/repos/luya/gimp/ -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seamonkey status
On 08/24/2011 05:05 PM, Kai Engert wrote: I would appreciate contributions, reviews, specific proposals. I did note some of the prominent ones in my first mail https://lists.fedoraproject.org/pipermail/devel/2011-August/155758.html https://fedoraproject.org/wiki/Packaging:SourceURL https://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, 2011-08-24 at 09:06 -0400, Simo Sorce wrote: If the service is enabled but the daemon not currently running, is it so terrible for a connection test to cause the daemon to start? Remember, in systemd logic 'service enabled with socket activation, daemon not currently running' is effectively an 'on' state, not an 'off' state. If you wanted the database to be 'off' you should have the service disabled, and in that case, the ping test wouldn't cause the daemon to start. It generally is a bad idea to automatically restart a database based on a random connection. There many reasons why you may have stopped the db (or it may have stopped itself) and requires inspection before attempting a new restart. Having to battle with socket activation while in a critical situation is not a good idea. Sure, and I agree with you that socket activation may not be a great idea for a constantly-used database. I should've made it clearer that I was engaging with the generic argument - 'socket activation makes it tough to check the state of services by pinging them' - not the specific example - 'socket activation makes it tough to check the state of MySQL by pinging it'. As far as I was concerned, MySQL was just an arbitrary example chosen by the OP. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote: Simo Sorce s...@redhat.com writes: On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote: On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote: It generally is a bad idea to automatically restart a database based on a random connection. There many reasons why you may have stopped the db (or it may have stopped itself) and requires inspection before attempting a new restart. Having to battle with socket activation while in a critical situation is not a good idea. You'd have the same problem with any init system that supports automatic service restarting. You can easily disable the service via systemctl. You can do that if you are doing a planned outage. But not for unplanned ones. I am not saying automatic restarts should never be employed, only that not all software should be automatically restarted. I think databases shouldn't in most cases. But that's just my opinion on the specific case. That doesn't mean socket-activation shouldn't be employed in other cases. FWIW, I do think that there may be use-cases for socket activation of a database. I'd like to support the option ... the problem is to do so without breaking existing, expected behaviors. It was noted up-thread that systemd can tell you whether the underlying daemon is running or not, though I guess that doesn't tell you whether it's entirely in a functional state. You could do a two-stage thing: check with systemd whether the daemon is running, and ping it if so? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Aug 24, 2011, at 10:05 AM, Adam Williamson wrote: On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote: Simo Sorce s...@redhat.com writes: On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote: On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote: It generally is a bad idea to automatically restart a database based on a random connection. There many reasons why you may have stopped the db (or it may have stopped itself) and requires inspection before attempting a new restart. Having to battle with socket activation while in a critical situation is not a good idea. You'd have the same problem with any init system that supports automatic service restarting. You can easily disable the service via systemctl. You can do that if you are doing a planned outage. But not for unplanned ones. I am not saying automatic restarts should never be employed, only that not all software should be automatically restarted. I think databases shouldn't in most cases. But that's just my opinion on the specific case. That doesn't mean socket-activation shouldn't be employed in other cases. FWIW, I do think that there may be use-cases for socket activation of a database. I'd like to support the option ... the problem is to do so without breaking existing, expected behaviors. It was noted up-thread that systemd can tell you whether the underlying daemon is running or not, though I guess that doesn't tell you whether it's entirely in a functional state. You could do a two-stage thing: check with systemd whether the daemon is running, and ping it if so? Some of the argument here is that it is difficult to do this from a remote host. You'd have to engage in remote execution of software, e.g. using nagios nrpe to remotely (from the nagios system) execute commands on the database system to call systemd to check the status of the db. This is a shift from previous environments where you could just poke at the network socket from the nagios system and parse the reply. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to ignore LD_LIBRARY_PATH
On Tue, Aug 23, 2011 at 11:44, Orion Poplawski or...@cora.nwra.com wrote: See https://bugzilla.redhat.com/show_bug.cgi?id=719785 for the motivation The environment module system allows users to modify their environment in a predictable way, including setting LD_LIBRARY_PATH. However, this makes it possible to break the modulecmd binary by putting an incompatible TCL (or other) library earlier in the path. It would be great if modulecmd were made impervious to such things, but I don't know the best or acceptable method to do this. I'm guessing using rpaths would be the easiest. Thoughts/suggestions? To be honest, I think this falls under: User shoots self in foot. I have run into this a lot and done it quite a few times myself... but in the end it usually meant finding out I had old software I no longer needed while not breaking software I still needed to have work. Is this a security issue? -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On 20:17:14 Wednesday 24 August 2011 Adam Williamson wrote: On Wed, 2011-08-24 at 09:06 -0400, Simo Sorce wrote: If the service is enabled but the daemon not currently running, is it so terrible for a connection test to cause the daemon to start? Remember, in systemd logic 'service enabled with socket activation, daemon not currently running' is effectively an 'on' state, not an 'off' state. If you wanted the database to be 'off' you should have the service disabled, and in that case, the ping test wouldn't cause the daemon to start. It generally is a bad idea to automatically restart a database based on a random connection. There many reasons why you may have stopped the db (or it may have stopped itself) and requires inspection before attempting a new restart. Having to battle with socket activation while in a critical situation is not a good idea. Sure, and I agree with you that socket activation may not be a great idea for a constantly-used database. I should've made it clearer that I was engaging with the generic argument - 'socket activation makes it tough to check the state of services by pinging them' - not the specific example - 'socket activation makes it tough to check the state of MySQL by pinging it'. As far as I was concerned, MySQL was just an arbitrary example chosen by the OP. I want to add one more POV - not every database is constantly-used. Example usage is Amarok using mysql database and I really want mysql to not be started until I start Amarok. Not that this is very common usage scenario but still I know at least one guy using Amarok with mysql :). Alexander Kurtakov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, Aug 24, 2011 at 9:22 AM, Alexander Kurtakov akurt...@redhat.comwrote: I want to add one more POV - not every database is constantly-used. Example usage is Amarok using mysql database and I really want mysql to not be started until I start Amarok. Not that this is very common usage scenario but still I know at least one guy using Amarok with mysql :). You are using a system-wide network exposed mysql for Amarok? Is this mysql serving information to multiple clients or multiple users? If its system-wide and only being used by one application by one user, why is it being run system-wide? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled - there is no problem with mysqld
On Wed, 24.08.11 10:45, Tom Lane (t...@redhat.com) wrote: Reindl Harald h.rei...@thelounge.net writes: Am 23.08.2011 23:28, schrieb Tom Lane: there's no other way for mysqladmin ping to work, for example and where is the problem? I'm not planning on repeating myself either, but: a database *monitoring* tool, as opposed to a vanilla client, needs to know whether the database is in fact up. Autostarting the DB in response to a monitoring probe is the wrong behavior for that. Are you sure it is? The thing is that when using socket activation it is merely an implementation detail when a service is actually really started. If you get a response you get a response and that's what you probably want to monitor. Whether the backing service has been running all the time or was just started due to your request shouldn't really matter -- unless of course you actually really want to monitor the service itself and not just whether it responds. But in that case it's probably a good idea to ask systemd for the service's status, since it will provide you with a lot of interesting data, including timestamps and so on. So, my claim would be that if you want to monitor whether a service responds then the backing implementation of it should be asbtract to you and it doesn't matter whether a service is started, or already running for that. And if you want to monitor the service itself then it's a good idea to make use of the monitoring data systemd keeps and hence you probably should talk to systemd directly in your monitoring tool. I think it's really important to know what you actually want to monitor, and then figure out how to do it best. I do not really care whether you believe that that's a problem or not; it is in my eyes, and as the responsible engineer, I'm not going to produce a broken database package. I do believe socket activation is interesting for SQL servers, but lazy activation of SQL servers makes little sense. One should not conflate socket activation with lazy socket activation. The latter is only interesting for a select few of services which are very seldom used like CUPS or sshd which are usually only access less than 1/h. Socket activation brings a lot of advantages, lazy activation is only one small one. More interesting are the paralellization or the fact that we can get rid of explicitly configured dependencies and suchlike. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Tue, Aug 23, 2011 at 06:14:34PM +0200, Lennart Poettering wrote: systemctl list-unit-files is what you are looking for. It's simpler even than chkconfig --list. When I run systemctl list-unit-files, I get a Unknown operation list-unit-files error. Did you mean systemctl list-units? -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please Review: (732541) Ignore error 32 when adding automember config
https://bugzilla.redhat.com/show_bug.cgi?id=732541 https://bugzilla.redhat.com/attachment.cgi?id=519679action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Default services enabled
On Wed, Aug 24, 2011 at 9:31 AM, Jef Spaleta jspal...@gmail.com wrote: On Wed, Aug 24, 2011 at 9:22 AM, Alexander Kurtakov akurt...@redhat.comwrote: I want to add one more POV - not every database is constantly-used. Example usage is Amarok using mysql database and I really want mysql to not be started until I start Amarok. Not that this is very common usage scenario but still I know at least one guy using Amarok with mysql :). You are using a system-wide network exposed mysql for Amarok? Is this mysql serving information to multiple clients or multiple users? If its system-wide and only being used by one application by one user, why is it being run system-wide? And to belabor the point a bit more. We really need to have distinct discussions about what a system service default is and what its okay for local admins are encourage/discourage/allowed to do. If you need to run a private instance of mysql on non-standard network ports to serve a local Amarok application in an on-demand fashion. Then you can do that as a local admin. In fact working with the mysql packager you might be able to use systemd's support for multiple instances to make it easier to set that up without it interfering with the system default mysql. However, does it make since to write the default init for the system-wide mysql with this usage case in mind? I'm not sure. It could very well be that for right now the system wide mysql default init needs to refrain from socket activation as mysql is primarily aimed at a server workload and not an on-demand workload. Any service that primarily services remote systems instead of local applications will probably want to start up fully at boot and not on demand later. I guess that's sort of the sane boundary for me with regard to socket activiation. If a service wants to see the outside world via tcp sockets...probably should not be on-demand by default. If its unix socket only..it can probably be a socket activated service. There will be of course things that break that simple rule..but as I guide I think it will work as a starting point for service packagers. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, 24.08.11 10:56, Simo Sorce (s...@redhat.com) wrote: a random connection. There many reasons why you may have stopped the db (or it may have stopped itself) and requires inspection before attempting a new restart. Having to battle with socket activation while in a critical situation is not a good idea. You'd have the same problem with any init system that supports automatic service restarting. You can easily disable the service via systemctl. You can do that if you are doing a planned outage. But not for unplanned ones. I am not saying automatic restarts should never be employed, only that not all software should be automatically restarted. I think databases shouldn't in most cases. But that's just my opinion on the specific case. That doesn't mean socket-activation shouldn't be employed in other cases. Restart= defaults to off by default, since only selected services should be restarted automatically. What currently is missing is that if a service fails we can (optionally) automatically propagate this to the triggering .socket, .path, .timer units. That's what you are asking for right? Because in that case we would shut down a listening socket as soon as the backing service fails. This has been on the TODO list for a while I just need to get around implementing this. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, 24.08.11 11:40, Andrew McNabb (amcn...@mcnabbs.org) wrote: On Tue, Aug 23, 2011 at 06:14:34PM +0200, Lennart Poettering wrote: systemctl list-unit-files is what you are looking for. It's simpler even than chkconfig --list. When I run systemctl list-unit-files, I get a Unknown operation list-unit-files error. Did you mean systemctl list-units? As mentioned in the mail list-unit-files is only availablein F16. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, 24.08.11 10:05, Adam Williamson (awill...@redhat.com) wrote: FWIW, I do think that there may be use-cases for socket activation of a database. I'd like to support the option ... the problem is to do so without breaking existing, expected behaviors. It was noted up-thread that systemd can tell you whether the underlying daemon is running or not, though I guess that doesn't tell you whether it's entirely in a functional state. You could do a two-stage thing: check with systemd whether the daemon is running, and ping it if so? systemd will put services only in running state if they are fully up and told systemd so. They'll be in starting until that time. All we need for this is that services either use Type=forking and double fork+exit in parent, or use Type=notify and sd_notify(READY=1) as soon as they are fully up. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On Wed, Aug 24, 2011 at 11:48 AM, Jeffrey Ollie j...@ocjtech.us wrote: On Wed, Aug 24, 2011 at 9:36 AM, Richard Shaw hobbes1...@gmail.com wrote: The other option is for someone to build packages and host them on fedorapeople.org as a personal repository. I certainly wouldn't mind trying 2.7+ but I would like the ability to easily revert if I run into problems. You mean something like this? http://repos.fedorapeople.org/repos/luya/gimp/ Yup! It's at 2.7.2, but I'm downloading the SRPM to updated it to 2.7.3... Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, 24.08.11 20:22, Alexander Kurtakov (akurt...@redhat.com) wrote: On 20:17:14 Wednesday 24 August 2011 Adam Williamson wrote: On Wed, 2011-08-24 at 09:06 -0400, Simo Sorce wrote: If the service is enabled but the daemon not currently running, is it so terrible for a connection test to cause the daemon to start? Remember, in systemd logic 'service enabled with socket activation, daemon not currently running' is effectively an 'on' state, not an 'off' state. If you wanted the database to be 'off' you should have the service disabled, and in that case, the ping test wouldn't cause the daemon to start. It generally is a bad idea to automatically restart a database based on a random connection. There many reasons why you may have stopped the db (or it may have stopped itself) and requires inspection before attempting a new restart. Having to battle with socket activation while in a critical situation is not a good idea. Sure, and I agree with you that socket activation may not be a great idea for a constantly-used database. I should've made it clearer that I was engaging with the generic argument - 'socket activation makes it tough to check the state of services by pinging them' - not the specific example - 'socket activation makes it tough to check the state of MySQL by pinging it'. As far as I was concerned, MySQL was just an arbitrary example chosen by the OP. I want to add one more POV - not every database is constantly-used. Example usage is Amarok using mysql database and I really want mysql to not be started until I start Amarok. Not that this is very common usage scenario but still I know at least one guy using Amarok with mysql :). Please, don't conflate general socket activation with lazy socket activation. The former is the generic technology that provides us with a lot of advantages like robustness, parallelization, simplicity because deps don't need to be configured explicitly anymore. The latter is something that is useful for very few selected services, like CUPS and sshd which are used very seldom (i.e. less often than 1/h in 90% of the cases). Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, 24.08.11 10:10, Jesse Keating (jkeat...@j2solutions.net) wrote: FWIW, I do think that there may be use-cases for socket activation of a database. I'd like to support the option ... the problem is to do so without breaking existing, expected behaviors. It was noted up-thread that systemd can tell you whether the underlying daemon is running or not, though I guess that doesn't tell you whether it's entirely in a functional state. You could do a two-stage thing: check with systemd whether the daemon is running, and ping it if so? Some of the argument here is that it is difficult to do this from a remote host. You'd have to engage in remote execution of software, e.g. using nagios nrpe to remotely (from the nagios system) execute commands on the database system to call systemd to check the status of the db. systemctl actually knows the -H switch to access remote systems (via ssh), but this needs a patch to dbus to actually work which I still haven't found time to ultimately clean up for proper inclusion. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, 2011-08-24 at 19:44 +0200, Lennart Poettering wrote: On Wed, 24.08.11 10:56, Simo Sorce (s...@redhat.com) wrote: a random connection. There many reasons why you may have stopped the db (or it may have stopped itself) and requires inspection before attempting a new restart. Having to battle with socket activation while in a critical situation is not a good idea. You'd have the same problem with any init system that supports automatic service restarting. You can easily disable the service via systemctl. You can do that if you are doing a planned outage. But not for unplanned ones. I am not saying automatic restarts should never be employed, only that not all software should be automatically restarted. I think databases shouldn't in most cases. But that's just my opinion on the specific case. That doesn't mean socket-activation shouldn't be employed in other cases. Restart= defaults to off by default, since only selected services should be restarted automatically. What currently is missing is that if a service fails we can (optionally) automatically propagate this to the triggering .socket, .path, .timer units. That's what you are asking for right? Because in that case we would shut down a listening socket as soon as the backing service fails. This has been on the TODO list for a while I just need to get around implementing this. Yes, I think this would neatly solve many issues. Thanks, Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, 2011-08-24 at 20:19 +0200, Lennart Poettering wrote: On Wed, 24.08.11 10:10, Jesse Keating (jkeat...@j2solutions.net) wrote: FWIW, I do think that there may be use-cases for socket activation of a database. I'd like to support the option ... the problem is to do so without breaking existing, expected behaviors. It was noted up-thread that systemd can tell you whether the underlying daemon is running or not, though I guess that doesn't tell you whether it's entirely in a functional state. You could do a two-stage thing: check with systemd whether the daemon is running, and ping it if so? Some of the argument here is that it is difficult to do this from a remote host. You'd have to engage in remote execution of software, e.g. using nagios nrpe to remotely (from the nagios system) execute commands on the database system to call systemd to check the status of the db. systemctl actually knows the -H switch to access remote systems (via ssh), but this needs a patch to dbus to actually work which I still haven't found time to ultimately clean up for proper inclusion. Monitoring system generally do not have (nor should have) ssh access to other servers. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, 2011-08-24 at 19:59 +0200, Lennart Poettering wrote: On Wed, 24.08.11 10:05, Adam Williamson (awill...@redhat.com) wrote: FWIW, I do think that there may be use-cases for socket activation of a database. I'd like to support the option ... the problem is to do so without breaking existing, expected behaviors. It was noted up-thread that systemd can tell you whether the underlying daemon is running or not, though I guess that doesn't tell you whether it's entirely in a functional state. You could do a two-stage thing: check with systemd whether the daemon is running, and ping it if so? systemd will put services only in running state if they are fully up and told systemd so. They'll be in starting until that time. All we need for this is that services either use Type=forking and double fork+exit in parent, or use Type=notify and sd_notify(READY=1) as soon as they are fully up. Sure, but it would be possibly for mysql to be 'fully up' under systemd's definition (i.e. the mysqld process has successfully executed and is running happily) while not actually being properly configured to serve external requests, right? Bad mysql config, firewall in the way, whatever...point is that systemd can't really know for sure that the underlying process is 100% working, only that it's _running_. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Aug 24, 2011, at 11:19 AM, Lennart Poettering wrote: On Wed, 24.08.11 10:10, Jesse Keating (jkeat...@j2solutions.net) wrote: FWIW, I do think that there may be use-cases for socket activation of a database. I'd like to support the option ... the problem is to do so without breaking existing, expected behaviors. It was noted up-thread that systemd can tell you whether the underlying daemon is running or not, though I guess that doesn't tell you whether it's entirely in a functional state. You could do a two-stage thing: check with systemd whether the daemon is running, and ping it if so? Some of the argument here is that it is difficult to do this from a remote host. You'd have to engage in remote execution of software, e.g. using nagios nrpe to remotely (from the nagios system) execute commands on the database system to call systemd to check the status of the db. systemctl actually knows the -H switch to access remote systems (via ssh), but this needs a patch to dbus to actually work which I still haven't found time to ultimately clean up for proper inclusion. Lennart That would require your nagios (or other monitoring) system to be running systemd, which may not be the case for quite a while :) - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[SOLVED] Re: Jmol, Java and netscape.javascript
On Tue, 23 Aug 2011 14:25:16 -0400
Omair Majid oma...@redhat.com wrote:
On 08/23/2011 04:44 AM, Jussi Lehtola wrote:
$ ant -lib %{_datadir}/icedtea-web/plugin.jar doc main
doesn't work, it still fails in the same error.
There are two things that were causing problems. The spec file was
setting classpath to a directory, not a jar. Also, the build.xml file
was instructing ant to discard the classpath specified on the command
line.
The build.xml statement was indeed the culprit. Thanks for your help!
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: Bug 733103 - large targetattr list with syntax errors cause server to crash or hang
https://bugzilla.redhat.com/show_bug.cgi?id=733103 https://bugzilla.redhat.com/attachment.cgi?id=519695action=diff https://bugzilla.redhat.com/attachment.cgi?id=519695action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Orphaning dnsmasq
On 08/22/2011 06:35 PM, Paul Wouters wrote: If it could also not grab port 0.0.0.0:53 in the future, that would be great. I'd like to work with whichever libvirt developer takes this package on. Are you talking about dnsmasq or the way that libvirt uses dnsmasq? The interfaces on which dnsmasq listens are configurable with the 'interface' and 'listen-address' parameters in /etc/dnsmasq.conf. When libvirt starts dnsmasq, it tells it to ignore the configuration file and passes all of the parameters on the command line. If you want dnsmasq to not listen on 0.0.0.0:53 when it's started by libvirt, you'll have to take that up with the libvirt developers. -- Ian Pilcher arequip...@gmail.com If you're going to shift my paradigm ... at least buy me dinner first. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help to build gimp-2.7.3
Quoting TASAKA Mamoru mtas...@fedoraproject.org: http://developer.gimp.org/NEWS says Changes in GIMP 2.7.3 = Source and build system: - Remove gimp-remote for good, it has been disabled for years Regards, Mamoru Thanks, Mamoru. Luya -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On 08/24/2011 12:24 PM, Ian Pilcher wrote: When libvirt starts dnsmasq, it tells it to ignore the configuration file and passes all of the parameters on the command line. If you want dnsmasq to not listen on 0.0.0.0:53 when it's started by libvirt, you'll have to take that up with the libvirt developers. At least for a NAT network, it does bind tightly, e.g. I see: --bind-interfaces --except-interface lo --listen-address 192.168.122.1 Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Jesse Keating (jkeat...@j2solutions.net) said: Some of the argument here is that it is difficult to do this from a remote host. You'd have to engage in remote execution of software, e.g. using nagios nrpe to remotely (from the nagios system) execute commands on the database system to call systemd to check the status of the db. This is a shift from previous environments where you could just poke at the network socket from the nagios system and parse the reply. Sure, but there's nothing that says you *have* to set up your internet-facing services as socket-activated. (In fact, quite the opposite.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to ignore LD_LIBRARY_PATH
On 08/23/2011 12:47 PM, Thomas Moschny wrote:
2011/8/23 Orion Poplawskior...@cora.nwra.com:
See https://bugzilla.redhat.com/show_bug.cgi?id=719785 for the motivation
The environment module system allows users to modify their environment in a
predictable way, including setting LD_LIBRARY_PATH. However, this makes it
possible to break the modulecmd binary by putting an incompatible TCL (or
other) library earlier in the path. It would be great if modulecmd were made
impervious to such things, but I don't know the best or acceptable method to
do this. I'm guessing using rpaths would be the easiest.
Thoughts/suggestions?
Would something like this work?
module ()
{
eval `/lib64/ld-linux-x86-64.so.2 --library-path ''
/usr/bin/modulecmd bash $*`
}
(on a 64bit system; on a 32bit system it would need to use
/lib/ld-linux.so.2).
- Thomas
Hmm, I like this idea. I think it would protect the default system, but still
allow for end users to override it for some reason. It might even be
acceptable upstream.
I'm CC'ing the packaging list to get their thoughts.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wednesday, August 24, 2011 11:52:23 AM Jesse Keating wrote: That would require your nagios (or other monitoring) system to be running systemd, which may not be the case for quite a while :) Why? When used to access remote machines systemctl shouldn't require running systemd locally. Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Aug 24, 2011, at 1:33 PM, Lars Seipel wrote: On Wednesday, August 24, 2011 11:52:23 AM Jesse Keating wrote: That would require your nagios (or other monitoring) system to be running systemd, which may not be the case for quite a while :) Why? When used to access remote machines systemctl shouldn't require running systemd locally. Lars Sorry, I conflated the two. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Aug 24, 2011, at 12:49 PM, Bill Nottingham wrote: Jesse Keating (jkeat...@j2solutions.net) said: Some of the argument here is that it is difficult to do this from a remote host. You'd have to engage in remote execution of software, e.g. using nagios nrpe to remotely (from the nagios system) execute commands on the database system to call systemd to check the status of the db. This is a shift from previous environments where you could just poke at the network socket from the nagios system and parse the reply. Sure, but there's nothing that says you *have* to set up your internet-facing services as socket-activated. (In fact, quite the opposite.) Bill oh of course not. I was just trying to shed light on where some of the argument was coming from. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Problems with bodhi buildroot overrides
I'm been having nothing but grief with bodhi buildroot overrides. Latest:
$ bodhi --my-overrides
1 Buildroot Overrides submitted by orion
[ plplot-5.9.8-2.fc16 ]
* Notes: Need to rebuild plplot users for soname bump
* Submitter: orion
* Submitted: 2011-08-19 04:01:18
* Expiration: 2011-08-26 00:00:00
But http://koji.fedoraproject.org/koji/taskinfo?taskID=3299827 built with
plplot-5.9.7.
$ koji latest-pkg f16-build plplot
Build Tag Built by
plplot-5.9.7-7.fc15 dist-f15 orion
Known issue? Inheritance problems?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
Gerald Henriksen wrote: In addition to the warning that Gimp 2.7.* is considered unstable and not to be used in production (aka in a distribution), That's why my point is that F16 should ship with 2.6 and get upgraded to 2.8 once it is stable. it comes with a warning that they are cleaning up the API's and thus 3rd party plugins and scripts can be broken. That might be a problem though… But then again those Firefox security updates are also breaking 3rd-party extensions. It's not the Firefox maintainers, it is Mozilla who have decided that release numbers are irrelevant and that the bug fix release for Firefox 5 is Firefox 6. If Firefox were following the update policy, they'd backport the security fixes, not push the new versions. And it's not just release NUMBERS which are irrelevant for upstream, it's the whole concept of release cycles and stable branches. They'll just throw together feature upgrades and security fixes the way they feel like. Now I don't really have anything against this (see also the next paragraph), but you have to understand that the change is definitely not only about numbers, the numbering changed for a reason. The new versions really CAN contain new major version material. (But they don't necessarily do, Mozilla is just always incrementing the same integer no matter what they actually changed.) Now, don't get me wrong, I think pushing the Firefox upgrades is actually a GOOD thing, but I think this should be the general rule in Fedora and not an exception for Firefox alone! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On 08/25/2011 04:56 AM, Kevin Kofler wrote: If Firefox were following the update policy, they'd backport the security fixes, not push the new versions. That is just not true https://fedoraproject.org/wiki/Updates_Policy#Security_fixes If upstream does not provide security fixes for a particular release, and if backporting the fix would be impractical, then a package may be rebased onto a version that upstream supports. The definition of practicality is left to the judgement of FESCO and the packager. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Tasque orphaned
Tasque has upstream bugs, and there has been no new release for over a year. Some of the bugs may be fixable with patches, but one of its dependencies, evolution-sharp has been deprecated in Fedora 16. Consequently, I am orphaning this package. -David Kaylor -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemd not in critpath
Neither bodhi nor mash appears to consider systemd to be in the critical path. Why is this? Is that the way we want it to be? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File indirect-0.24.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-indirect: 5ce3afe4e3b8f98477820e56d0f207d6 indirect-0.24.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-indirect] initial import (rhbz#730069)
commit 46eec3c0672b7a7f70a63e919af3c9319133ca13
Author: Iain Arnell iarn...@gmail.com
Date: Wed Aug 24 09:10:42 2011 +0200
initial import (rhbz#730069)
.gitignore |1 +
perl-indirect.spec | 54
sources|1 +
3 files changed, 56 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..c92c18a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/indirect-0.24.tar.gz
diff --git a/perl-indirect.spec b/perl-indirect.spec
new file mode 100644
index 000..304b603
--- /dev/null
+++ b/perl-indirect.spec
@@ -0,0 +1,54 @@
+Name: perl-indirect
+Version:0.24
+Release:1%{?dist}
+Summary:Lexically warn about using the indirect object syntax
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/indirect/
+Source0:
http://search.cpan.org/CPAN/authors/id/V/VP/VPIT/indirect-%{version}.tar.gz
+BuildRequires: perl = 0:5.008001
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::Kwalitee)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(Test::Portability::Files)
+BuildRequires: perl(XSLoader)
+Requires: perl(XSLoader)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+When enabled (or disabled as some may prefer to say, since you actually
+turn it on by calling no indirect), this pragma warns about indirect object
+syntax constructs that may have slipped into your code.
+
+%prep
+%setup -q -n indirect-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f {} \;
+find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
+
+%{_fixperms} %{buildroot}/*
+
+%check
+make test
+
+%files
+%doc Changes README
+%{perl_vendorarch}/auto/*
+%{perl_vendorarch}/indirect*
+%{_mandir}/man3/*
+
+%changelog
+* Thu Aug 11 2011 Iain Arnell iarn...@gmail.com 0.24-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..1ce82ed 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+5ce3afe4e3b8f98477820e56d0f207d6 indirect-0.24.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-indirect] remove unnecessary explicit BR on perl
commit eab63d9d740bb291b8db479dbc3e49687f08ba16
Author: Iain Arnell iarn...@gmail.com
Date: Wed Aug 24 09:11:09 2011 +0200
remove unnecessary explicit BR on perl
perl-indirect.spec |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
---
diff --git a/perl-indirect.spec b/perl-indirect.spec
index 304b603..278d911 100644
--- a/perl-indirect.spec
+++ b/perl-indirect.spec
@@ -1,12 +1,11 @@
Name: perl-indirect
Version:0.24
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Lexically warn about using the indirect object syntax
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/indirect/
Source0:
http://search.cpan.org/CPAN/authors/id/V/VP/VPIT/indirect-%{version}.tar.gz
-BuildRequires: perl = 0:5.008001
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::Kwalitee)
BuildRequires: perl(Test::More)
@@ -50,5 +49,8 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Aug 24 2011 Iain Arnell iarn...@gmail.com 0.24-2
+- remove unnecessary explicit BR on perl
+
* Thu Aug 11 2011 Iain Arnell iarn...@gmail.com 0.24-1
- Specfile autogenerated by cpanspec 1.78.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-indirect/f16] (2 commits) ...remove unnecessary explicit BR on perl
Summary of changes: 46eec3c... initial import (rhbz#730069) (*) eab63d9... remove unnecessary explicit BR on perl (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-indirect/f15] (2 commits) ...remove unnecessary explicit BR on perl
Summary of changes: 46eec3c... initial import (rhbz#730069) (*) eab63d9... remove unnecessary explicit BR on perl (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-indirect/f14] (2 commits) ...remove unnecessary explicit BR on perl
Summary of changes: 46eec3c... initial import (rhbz#730069) (*) eab63d9... remove unnecessary explicit BR on perl (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 732963] perl-Dancer-1.3072 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=732963 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|mmasl...@redhat.com |psab...@redhat.com -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Dancer-1.3072.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Dancer: 7ecf0bf6b28ba5ed0e7a6f82919394b1 Dancer-1.3072.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Dancer] 1.3072 bump
commit a8d89c027631656c755038c4442add3b7520a7f5
Author: Petr Sabata con...@redhat.com
Date: Wed Aug 24 12:59:00 2011 +0200
1.3072 bump
.gitignore |1 +
perl-Dancer.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9e75479..e734b49 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Dancer-1.3040.tar.gz
/Dancer-1.3071.tar.gz
+/Dancer-1.3072.tar.gz
diff --git a/perl-Dancer.spec b/perl-Dancer.spec
index 2307737..1a80335 100644
--- a/perl-Dancer.spec
+++ b/perl-Dancer.spec
@@ -1,5 +1,5 @@
Name: perl-Dancer
-Version:1.3071
+Version:1.3072
Release:1%{?dist}
Summary:Lightweight yet powerful web application framework
License:GPL+ or Artistic
@@ -88,6 +88,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Aug 24 2011 Petr Sabata con...@redhat.com - 1.3072-1
+- 1.3072 bump
+
* Wed Aug 10 2011 Marcela Mašláňová mmasl...@redhat.com 1.3071-1
- update
- add filter for RPM 4.8
diff --git a/sources b/sources
index 6e73a45..d128e88 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9fbe54f6d43c95c7d4aea4f765075bdb Dancer-1.3071.tar.gz
+7ecf0bf6b28ba5ed0e7a6f82919394b1 Dancer-1.3072.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 732963] perl-Dancer-1.3072 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=732963 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Dancer-1.3072-1.fc17 Resolution||RAWHIDE Last Closed||2011-08-24 07:07:46 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 715559] perl-Mojolicious-1.89 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=715559 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Mojolicious-1.87 is|perl-Mojolicious-1.89 is |available |available --- Comment #21 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2011-08-24 06:39:53 EDT --- Latest upstream release: 1.89 Current version in Fedora Rawhide: 1.65 URL: http://search.cpan.org/dist/Mojolicious/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 732963] New: perl-Dancer-1.3072 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Dancer-1.3072 is available https://bugzilla.redhat.com/show_bug.cgi?id=732963 Summary: perl-Dancer-1.3072 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Dancer AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: j...@di.uminho.pt, fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, psab...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 1.3072 Current version in Fedora Rawhide: 1.3071 URL: http://search.cpan.org/dist/Dancer/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-16 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-NOCpulse-Gritch
perl-NOCpulse-Gritch has broken dependencies in the F-16 tree: On x86_64: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-SOAP-Transport-TCP] Disable the local perl_bootstrap macro
commit 207cd26c138a8ffb94adecb5f942a1bc07747c54
Author: Petr Sabata con...@redhat.com
Date: Wed Aug 24 18:14:39 2011 +0200
Disable the local perl_bootstrap macro
perl-SOAP-Transport-TCP.spec |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-SOAP-Transport-TCP.spec b/perl-SOAP-Transport-TCP.spec
index 85f2ec5..1054712 100644
--- a/perl-SOAP-Transport-TCP.spec
+++ b/perl-SOAP-Transport-TCP.spec
@@ -1,9 +1,9 @@
# For initial import only; will be removed later
-%global perl_bootstrap 1
+#global perl_bootstrap 1
Name: perl-SOAP-Transport-TCP
Version:0.715
-Release:2%{?dist}
+Release:3%{?dist}
Summary:TCP Transport Support for SOAP::Lite
License:GPL+ or Artistic
Group: Development/Libraries
@@ -57,6 +57,9 @@ find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Wed Aug 24 2011 Petr Sabata con...@redhat.com - 0.715-3
+- Disable perl_bootstrap macro
+
* Wed Aug 24 2011 Petr Sabata con...@redhat.com - 0.715-2
- Correcting various defects for the review
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
