Re: RPM version goes backward in Rawhide
On 2011-08-19 20:41, Kevin Kofler wrote: Updates can be pulled out of updates-testing at any moment, which makes a lot of sense, but which means that users with updates-testing enabled will end up with the EVR going backwards, something that's not even allowed in Rawhide. Enabling updates-testing by default means forcing EVR downgrades on users of Branched by default, making the policy banning them in Rawhide totally pointless. The problem is that basically nobody is testing the actual release package set, considering that it's much less straightforward to opt out of updates- testing than to opt in, and that probably only few people are doing it (and those who do bother to explicitly opt out of updates-testing are the ones who just need early access to the releases for whatever reason, e.g. because they need a newer version of some package, and don't actually want to do any testing whatsoever, just to seamlessly move on to the release when it's out officially). FESCo discussed both of these issues before the release of the Fedora 15 Alpha at its meetings on 16 Feb 2011 and 2 Mar 2011. The current recommendation [1] is to run ``yum distro-sync'' after upgrading from pre-releases to the final release. [1] https://fedoraproject.org/wiki/Upgrading_from_pre-release_to_final#After_updating_to_final.2C_why_does_yum_complain_about_mismatched_package_versions_even_though_my_rawhide_repo_is_disabled.3F -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing default setting of bash's hash table?
On 08/20/2011 12:09 AM, Maciej Małecki wrote: Not worth it, one can always use which to verify if command is gone or is bash is going mad. +1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On Fri, Aug 19, 2011 at 10:49:23PM -0700, Steve Jenkins wrote: On Fri, Aug 19, 2011 at 9:17 PM, Rahul Sundaram methe...@gmail.com wrote: On 08/19/2011 06:02 AM, Steve Jenkins wrote: Hi - the purpose of this email is to introduce myself as a prospective new package maintainer for Fedora. My recently filed review request is here: https://bugzilla.redhat.com/show_bug.cgi?id=731898 Hello Steve Jenkins, welcome to Fedora. Just in case, you haven't already seen it, refer to https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group Thanks, Rahul. Yes, thank you for that link. I had read it, as well as any of the other new packager guidelines I could find. I've Did you already perform reviews as mentioned here: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Reviewing_packages Doing this and mentioning it in the review ticket usually helps to find a sponsor. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing default setting of bash's hash table?
On Fri, Aug 19, 2011 at 01:24:37PM +0200, Roman Rakus wrote: I have a question, if it is worth to enable this option by default? It will not confuse some people, but can increase disk searching. Comments welcome. How can it increase disk searching in case the program is still there? It needs to be fetched from the disk anyhow when it is run. Or am I missing something here? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing default setting of bash's hash table?
2011/8/20 Till Maas opensou...@till.name: How can it increase disk searching in case the program is still there? It needs to be fetched from the disk anyhow when it is run. Or am I missing something here? It's just one stat with every command execution. If you're curious how it looks internally, findcmd.c:71 and findcmd.c:327. Function which gets executed is file_status, defined in findcmd.c:84. -- Greetings, Maciej Małecki -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora-medical comps patch
On Sat, Aug 20, 2011 at 11:28:38AM +0530, Ankur Sinha wrote: Hello, You may have noticed a lot of packaging activity on the fedora-medical front[1]. There are still quite a few packages in the review queue. Some have been approved, and we'd like to get started with the comps group. I've created a patch (attached). Please review it :) If all's okay, I shall commit it by Sunday night (tomorrow night). [1] https://fedorahosted.org/fedora-medical/ [2] https://fedorahosted.org/fedora-medical/report/6 I'm not saying it's right or wrong, but shouldn't the comps group be called just Medical or Medical Applications instead of Fedora Medical? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Seamonkey status
Hi Seamonkey hasn't been updated in a long time. Someone recently mentioned it in identi.ca and filed a bug report to update it. I was looking into it and the spec doesn't seem to be following the packaging guidelines. Source tarball seems to have created locally and doesn't point to a URL. No instructions on regenerating it. Has interesting things like %define _unpackaged_files_terminate_build 0 and %define _use_internal_dependency_generator 0. Patches don't have comments in the spec etc.Anyone know the current status? Rahul . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seamonkey status
Dne 20.8.2011 12:09, Rahul Sundaram napsal(a): Seamonkey hasn't been updated in a long time. Someone recently mentioned it in identi.ca and filed a bug report to update it. I was looking into it and the spec doesn't seem to be following the packaging guidelines. Source tarball seems to have created locally and doesn't point to a URL. No instructions on regenerating it. Has interesting things like %define _unpackaged_files_terminate_build 0 and %define _use_internal_dependency_generator 0. Patches don't have comments in the spec etc.Anyone know the current status? 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? Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Those to whom evil is done \\ Do evil in return. -- W. H. Auden, September 1, 1939 http://www.poets.org/viewmedia.php/prmMID/15545 smime.p7s Description: Elektronický podpis S/MIME -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seamonkey status
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 Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Sat, 2011-08-20 at 00:13 +0200, Reindl Harald wrote: if you can give a warning you can also stop the socket this is what the user expects and if your software-design is not able to act logically it is broken Stopping the service but leaving the possibility for later socket activation is a valid use case. Warning about that because it also could be a mistake is a nice service and sufficient. service restart htt you can type TAb the whole day and will get no auto-completion Of course not. This is wrong syntax. systemctl restart htttab should do what you're trying to accomplish. If you insist on using the service wrapper script, the appropriate syntax would be: service htttab restart It does fine in both cases. yes it is a improvent to get htis after the boot but if you restart a server you nromally watch the boot and have no reason to login as long you see nothing red - this was broken by the usability-pifall how systemd boots I'm pretty certain that failures are colored red. Are you sure you got your facts right? Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110820 changes
Compose started at Sat Aug 20 08:15:14 UTC 2011 Broken deps for x86_64 -- FlightGear-2.0.0-6.fc16.x86_64 requires libosgViewer.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgUtil.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgText.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgSim.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgParticle.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgGA.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgFX.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgDB.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libOpenThreads.so.11()(64bit) SimGear-2.0.0-6.fc16.i686 requires libosgParticle.so.74 SimGear-2.0.0-6.fc16.i686 requires libosgDB.so.74 SimGear-2.0.0-6.fc16.i686 requires libosg.so.74 SimGear-2.0.0-6.fc16.i686 requires libOpenThreads.so.11 SimGear-2.0.0-6.fc16.x86_64 requires libosgParticle.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libosgDB.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libOpenThreads.so.11()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libecal-1.2.so.9()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libebook-1.2.so.11()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(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) bluetile-0.5.3-11.fc16.x86_64 requires ghc(xmonad-contrib-0.9.2) = 0:d669bbdb9b9f7adb145fcb61825dec73 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 libse.so.5()(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 librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(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 libse.so.5()(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 librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(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 libedataserver-1.2.so.14()(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 libcamel-1.2.so.23()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave empathy-3.1.5-1.fc17.x86_64 requires libgcr-3.so.1()(64bit) empathy-3.1.5-1.fc17.x86_64 requires libgck.so.0()(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 libgraph.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.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 libgraph.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(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 libboost_signals-mt.so.1.46.1()(64bit) fgrun-1.5.2-8.fc16.x86_64 requires libosgViewer.so.74()(64bit) fgrun-1.5.2-8.fc16.x86_64 requires
fedora 15 didn.t detected my Wifi card.
Hello, I have installed fedora 15 on my portable hardisk. Recently i had updated my fedora kernel to 2.6.40 nd now it is working fine but it didn't detected my wifi card(Intel Centrino Advanced-N 6230 ). Need some help. Plz. Regards Navdeep Singh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora 15 didn.t detected my Wifi card.
2011/8/20 Navdeep Singh Sidhu navdeepsingh.sidh...@gmail.com Hello, I have installed fedora 15 on my portable hardisk. Recently i had updated my fedora kernel to 2.6.40 nd now it is working fine but it didn't detected my wifi card(Intel Centrino Advanced-N 6230 ). Need some help. Plz. Regards Navdeep Singh You may want to ask on fedora-users list, this one is for development purposes. When asking there, provide more details on your setup. Also: http://www.intellinuxwireless.org/ -- Greetings, Maciej Małecki -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Friday, August 19, 2011 10:50:01 PM Kevin Kofler wrote: Tim Waugh wrote: Oh, I just noticed this: https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa tion Since Fedora currently doesn't want any services to do on-demand loading, all socket activated services must autostart. What the heck?! We're disabling systemd's main feature there, aren't we? Wasn't the main design concept behind systemd the observation that everything can be parallelized most effectively by on-demand activation? Why is bootup speed so important that init now has become network aware? Process 1 gets special protection from the kernel. You cannot kill it. If there is any mistake in its code, then you have an unkillable all powerful process that might do rogue things. It almost sounds like this is reinventing Xinetd - except its not as feature rich as xinetd. We had a lot of problems with xinetd over the years. For example, if it listens for a connection that the service must accept and then the service fails before it can call accept, xinetd will spin in a tight loop because the the listen socket is readable and the service is not calling accept. Then lets look at the accept option. If systemd accepts a connection and passes it to a child process, do you now support tcp_wrappers so that you deny the connection before starting the child? That would mean any flaw in tcp_wrappers now is part of process 1 which has special protection from the kernel. How do you limit the number of children? Xinetd grew all these features because of security problems. Xinetd had many bugs because of these features. I personally think systemd's configure should have an --enable-networking. I think this should be turned off. A network aware init could be internet worm material since you cannot kill process 1. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing default setting of bash's hash table?
Roman Rakus wrote: Maybe the subject is a bit misleading, I will clarify it. Bash is using hash table to remember locations of executed commands. Whenever you try to run a command bash looks in hash table. When the command is found in table then bash will you full path name as it is in the table. However there is a problem when the command moved (or is deleted). Bash by default is not checking if the command is really on the location. But there is bash option that will force bash to check if the command really exists. Man page says: checkhash If set, bash checks that a command found in the hash ta‐ ble exists before trying to execute it. If a hashed command no longer exists, a normal path search is per‐ formed. I have a question, if it is worth to enable this option by default? It will not confuse some people, but can increase disk searching. Comments welcome. It will only help if the first match in the search path is removed, it will still not do the right thing if a new match is prepended to the search path. IMHO, this whole hashing should not be done in interactive shells at all. The bottleneck is going to be the user running the commands anyway. I can see how it speeds up scripts, but it's just confusing and useless in interactive operation. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemd in F15 orphaned?
WHY do F16 and F17 get permanently updated and nobody cares about the beta-release called F15 GA any longer? F15 is SEVEN versions behind! sometimes it seems nobody cares about GA-Releases to have arguments updating to the next as soon as possible where all will be better and the things which are worse are better in the release after the release PLEASE fix bugs in GA-Releases instead working permanently only in rawhide! systemd-33-2.fc16 systemd-33-1.fc16 systemd-32-1.fc17 systemd-32-1.fc16 systemd-31-2.fc16 systemd-31-1.fc16 systemd-30-1.fc16 systemd-26-8.fc15 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd in F15 orphaned?
Hi, 2011/8/20 Reindl Harald h.rei...@thelounge.net: WHY do F16 and F17 get permanently updated and nobody cares about the beta-release called F15 GA any longer? It's maintained - serious bugs are fixed. F15 is SEVEN versions behind! sometimes it seems nobody cares about GA-Releases to have arguments updating to the next as soon as possible where all will be better and the things which are worse are better in the release after the release PLEASE fix bugs in GA-Releases instead working permanently only in rawhide! systemd-33-2.fc16 systemd-33-1.fc16 systemd-32-1.fc17 systemd-32-1.fc16 systemd-31-2.fc16 systemd-31-1.fc16 systemd-30-1.fc16 systemd-26-8.fc15 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Anaconda memory requirements
Hi, We are working on a remix(considering a spin) of Fedora that could be used in schools[1], The problem is, most of these schools in India use donated computers and have very less memory (256 Mb - 512 Mb). According to this blog post https://anonbadger.wordpress.com/2011/02/25/need-more-memory/ and this email thread https://lists.fedoraproject.org/pipermail/devel/2011-February/149110.html i understand that some one is working on reducing the memory footprint of anaconda. Will it be ready for F16? How much memory will anaconda require to install Fedora 16? I'd love to see reduced memory requirements for anaconda in F16. [1] https://lists.fedoraproject.org/pipermail/devel/2011-February/149110.html -- Arun S.A.G http://zer0c00l.in/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Am 20.08.2011 04:50, schrieb Kevin Kofler: Tim Waugh wrote: Oh, I just noticed this: https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activation Since Fedora currently doesn't want any services to do on-demand loading, all socket activated services must autostart. What the heck?! We're disabling systemd's main feature there, aren't we? Wasn't the main design concept behind systemd the observation that everything can be parallelized most effectively by on-demand activation? Kevin Kofler Mhh - See also here https://bugzilla.redhat.com/show_bug.cgi?id=714426 The mysqld problems would be solved by socket-activation whoever dcided that socket-activation is not wanted should recognize that he ha sno technical qualification to decide anything and si forcong maintainers to play around with wait-tricks for services like mysqld - IDIOTIC again: systemd in F15 has not a single benfit for anybody, is making only troubles which are MAYBE solved in F16 or F17 or even F18 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Am 20.08.2011 14:09, schrieb Lars Seipel: On Sat, 2011-08-20 at 00:13 +0200, Reindl Harald wrote: if you can give a warning you can also stop the socket this is what the user expects and if your software-design is not able to act logically it is broken Stopping the service but leaving the possibility for later socket activation is a valid use case. Warning about that because it also could be a mistake is a nice service and sufficient. it is NOT a valid usecase because the service is restarted a moment later service restart htt you can type TAb the whole day and will get no auto-completion Of course not. This is wrong syntax. systemctl restart htttab should do what you're trying to accomplish. If you insist on using the service wrapper script, the appropriate syntax would be: service htttab restart It does fine in both cases. this was a typo and IT DOES NOT and if you look on the systemd-mailing list you will find a patch for this but damned why does F15 get no updates for systemd over months? this is reasonable for software which is stable and bugfree, but systemd is not and targeting bugfixes/optimizing for F16/F17 is unacceptable it does if the service is NOT running which is useless for restart [root@srv-rhsoft:~]$ systemctl restart htt^C [root@srv-rhsoft:~]$ systemctl stop httpd.service [root@srv-rhsoft:~]$ systemctl restart httpd.service yes it is a improvent to get htis after the boot but if you restart a server you nromally watch the boot and have no reason to login as long you see nothing red - this was broken by the usability-pifall how systemd boots I'm pretty certain that failures are colored red. Are you sure you got your facts right? Lars they are NOT i am sure because my self-written pulsed.service will fail the first 10 times compare a F14 boot WITHOUT quiet and a F15 boot and after that you will not tell me that the whole output is not degraded since systemd started take over the world [root@srv-rhsoft:~]$ cat /lib/systemd/system/pulsed.service [Unit] Description=Pulseaudio Daemon After=syslog.target local-fs.target rtkit-daemon.service udev.service dbus.service prefdm.service [Service] Type=forking ExecStart=-/usr/bin/pulseaudio --daemonize=true --system=true --log-level=0 --log-target=stderr --disallow-module-loading --disallow-exit --exit-idle-time=0 --disable-shm --no-cpu-limit=false --use-pid-file=false Restart=always RestartSec=30 TimeoutSec=15 Nice=-10 [Install] WantedBy=multi-user.target another thing where lennart is responsible that he believes to know what is good for users and will not probide a systemwide pulsed, where here he could show that systemd brings any benefit to the users by packaging pulseaudio-systemwide.rpm and fix both (systemd and pulseaudio) as long they are not working perfectly together as system-instance again: there are users running music from their machine the whole day without login or even with login as another user, but this usecase does not bother Lennart signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Sat, 20.08.11 04:50, Kevin Kofler (kevin.kof...@chello.at) wrote: Tim Waugh wrote: Oh, I just noticed this: https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activation Since Fedora currently doesn't want any services to do on-demand loading, all socket activated services must autostart. What the heck?! We're disabling systemd's main feature there, aren't we? Wasn't the main design concept behind systemd the observation that everything can be parallelized most effectively by on-demand activation? While it is of course disappointing if we do not use lazy socket activation of CUPS in Fedora the ability to do lazy socket activation is only one of the many benefits of socket activation. I'd claim the most interesting advantage of socket activation is that it drastically improves parallelization and simplifies the execution ordering logic at boot-up. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd in F15 orphaned?
On Sat, 20.08.11 16:25, Reindl Harald (h.rei...@thelounge.net) wrote: WHY do F16 and F17 get permanently updated and nobody cares about the beta-release called F15 GA any longer? F15 is SEVEN versions behind! Like most packages in Fedora systemd in released distributions is only updated when bugs need to be fixed. Feature additions are only done in the development version of Fedora. 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 Sat, 20.08.11 09:41, Steve Grubb (sgr...@redhat.com) wrote: On Friday, August 19, 2011 10:50:01 PM Kevin Kofler wrote: Tim Waugh wrote: Oh, I just noticed this: https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa tion Since Fedora currently doesn't want any services to do on-demand loading, all socket activated services must autostart. What the heck?! We're disabling systemd's main feature there, aren't we? Wasn't the main design concept behind systemd the observation that everything can be parallelized most effectively by on-demand activation? Why is bootup speed so important that init now has become network aware? Process 1 gets special protection from the kernel. You cannot kill it. If there is any mistake in its code, then you have an unkillable all powerful process that might do rogue things. It almost sounds like this is reinventing Xinetd - except its not as feature rich as xinetd. systemd never reads a single packet from any of the network sockets it listens on on behalf of services. It just passes these sockets off to the services as soon as traffic is seen on them (i.e. when POLLIN is triggered we pass off the socket, we don't call read() on it.) We had a lot of problems with xinetd over the years. For example, if it listens for a connection that the service must accept and then the service fails before it can call accept, xinetd will spin in a tight loop because the the listen socket is readable and the service is not calling accept. systemd (much like sysvinit) rate limits service start-up. If a service respawns too often we will refuse starting it again for a while. Then lets look at the accept option. If systemd accepts a connection and passes it to a child process, do you now support tcp_wrappers so that you deny the connection before starting the child? We do tcpwrap checks for incoming connections. I do wonder though whether it might be time to deprecate tcpwrap distribution-wide. I am pretty sure firewalls are the better approach, more widely supported, more widely understood and more widely used. That would mean any flaw in tcp_wrappers now is part of process 1 which has special protection from the kernel. We are very careful with what we execute in PID 1. For example we make sure not to do any NSS lookups or use other code that might pull in arbitrary libraries into PID 1. And following this logic I carefully made sure that tcpwrap checks are not done in PID 1, but in the forked off process shortly before we execute the process binary. And anyway, I wouldn't overestimate the risk here. tcpwrap does not read from the socket, it just executes syscalls like getsockname() and getpeername() and suchlike, but does not parse potentially dangerous network traffic. How do you limit the number of children? There's an option for that: MaxConnections=. It defaults to 64. I personally think systemd's configure should have an --enable-networking. I think this should be turned off. A network aware init could be internet worm material since you cannot kill process 1. Please read up on socket activation before making such broad comments. http://0pointer.de/blog/projects/systemd.html Read the part about Parallelizing Socket Services. It explains why socket actviation is interesting, and why systemd's focus is (much unlike inetd) on AF_UNIX sockets here, not AF_INET sockets. And why the parallelization enables us to do is what matters, and not so much the lazy loading. And again, systemd never reads from the sockets it listens on on behalf of services. It just waits for POLLIN and then passes them off. In fact, the way most modern socket activatable services are written systemd doesn't even call accept() ever, but passes the listening socket off (instead of the connection socket). In this common case tcpwrap isn't invoked by systemd code either. systemd has no network parsing code. And even NSS code (which might potentially parse network packets) is always done out-of-process, never from PID 1. 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 08/20/2011 08:09 AM, Lars Seipel wrote: On Sat, 2011-08-20 at 00:13 +0200, Reindl Harald wrote: if you can give a warning you can also stop the socket this is what the user expects and if your software-design is not able to act logically it is broken Stopping the service but leaving the possibility for later socket activation is a valid use case. Warning about that because it also could be a mistake is a nice service and sufficient. How can you say that? I stopped the serivce! I don't expect it to magically start backup!!! You are just plain wrong. Any system should be about doing things with the least surprise to the user! service restart htt you can type TAb the whole day and will get no auto-completion Of course not. This is wrong syntax. systemctl restart htttab should do what you're trying to accomplish. If you insist on using the service wrapper script, the appropriate syntax would be: service htttab restart It does fine in both cases. yes it is a improvent to get htis after the boot but if you restart a server you nromally watch the boot and have no reason to login as long you see nothing red - this was broken by the usability-pifall how systemd boots I'm pretty certain that failures are colored red. Are you sure you got your facts right? Lars -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda memory requirements
... 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. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd in F15 orphaned?
Am 20.08.2011 19:58, schrieb Lennart Poettering: On Sat, 20.08.11 16:25, Reindl Harald (h.rei...@thelounge.net) wrote: WHY do F16 and F17 get permanently updated and nobody cares about the beta-release called F15 GA any longer? F15 is SEVEN versions behind! Like most packages in Fedora systemd in released distributions is only updated when bugs need to be fixed. Feature additions are only done in the development version of Fedora. the problem is that wat you call as intedned, a bug and users call the same is mostly a different thing, so if it was decided to include systemd in a way too few state in systemd it should be mandatory that it will be optimized in the same rlease and not a year later signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd in F15 orphaned?
2011/8/20 Reindl Harald h.rei...@thelounge.net: Am 20.08.2011 19:58, schrieb Lennart Poettering: On Sat, 20.08.11 16:25, Reindl Harald (h.rei...@thelounge.net) wrote: WHY do F16 and F17 get permanently updated and nobody cares about the beta-release called F15 GA any longer? F15 is SEVEN versions behind! Like most packages in Fedora systemd in released distributions is only updated when bugs need to be fixed. Feature additions are only done in the development version of Fedora. the problem is that wat you call as intedned, a bug and users call the same is mostly a different thing, so if it was decided to include systemd in a way too few state in systemd it should be mandatory that it will be optimized in the same rlease and not a year later If you want a new features just build it or use F16 branch. Most F15 users don't want to deal with new systemd bugs in stable system. -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Saturday, August 20, 2011 02:17:04 PM Lennart Poettering wrote: On Sat, 20.08.11 09:41, Steve Grubb (sgr...@redhat.com) wrote: On Friday, August 19, 2011 10:50:01 PM Kevin Kofler wrote: Tim Waugh wrote: Oh, I just noticed this: https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_ac tiva tion Since Fedora currently doesn't want any services to do on-demand loading, all socket activated services must autostart. What the heck?! We're disabling systemd's main feature there, aren't we? Wasn't the main design concept behind systemd the observation that everything can be parallelized most effectively by on-demand activation? Why is bootup speed so important that init now has become network aware? Process 1 gets special protection from the kernel. You cannot kill it. If there is any mistake in its code, then you have an unkillable all powerful process that might do rogue things. It almost sounds like this is reinventing Xinetd - except its not as feature rich as xinetd. systemd never reads a single packet from any of the network sockets it listens on on behalf of services. It just passes these sockets off to the services as soon as traffic is seen on them (i.e. when POLLIN is triggered we pass off the socket, we don't call read() on it.) And therein lies one of the big problems that xinetd has. If its listening and passes the descriptor to a child to accept and the child crashes or aborts before accepting the socket, the whole mess spins in a circle where the listen descriptor is readable, but nothing is accepting the connection. But still, why is speed so important that xinetd capabilities are the answer? Why not leave init not network aware and let xinetd do the on demand startup? This has the advantage of being able to kill xinetd whereas init cannot be killed. Then lets look at the accept option. If systemd accepts a connection and passes it to a child process, do you now support tcp_wrappers so that you deny the connection before starting the child? We do tcpwrap checks for incoming connections. I do wonder though whether it might be time to deprecate tcpwrap distribution-wide. I am pretty sure firewalls are the better approach, more widely supported, more widely understood and more widely used. Do you remember the hole in netfilter a while back? CVE-2001-1572 CVE-2006-4572 Its happened before and it will happen again. I'm sure this list is not complete. Then some tools that help setup the firewall might accidentally leave you open: CVE-2003-0080 Belt and suspenders! Must have both. That would mean any flaw in tcp_wrappers now is part of process 1 which has special protection from the kernel. We are very careful with what we execute in PID 1. For example we make sure not to do any NSS lookups or use other code that might pull in arbitrary libraries into PID 1. And following this logic I carefully made sure that tcpwrap checks are not done in PID 1, but in the forked off process shortly before we execute the process binary. And anyway, I wouldn't overestimate the risk here. tcpwrap does not read from the socket, it just executes syscalls like getsockname() and getpeername() and suchlike, but does not parse potentially dangerous network traffic. I wrote lots of patches for tcp_wrappers, mostly to give it ipv6 capabilities. But there were bugs fixed. For example, it provides many functions with names that are in glibc. Which means you might get tcp_wrapper's implementation rather than glibc's. My version was called socket_wrappers and it fixed a whole lot of the problems in tcp_wrapper. So, even if you fork with the intention of not using its code in process 1, you might accidentally be using it. readelf -s /lib64/libwrap.so.0.7.6 | grep FUNC | grep -v UND Looks like someone has been doing some cleanining up, but maybe not that way on other distros. But anyways, tcp_wrapper does reverse DNS lookups to compare the forward and reverse paths in case anyone has tampered with the remote DNS to make it look like the incoming connection is legit. So, may it does not read much off the socket, its does a recvfrom peek, but it does talk with remote DNS servers to make a decision. Not all DNS servers are legit and can be malicious. One incoming packet can cause a cascade of outgoing DNS querries. I personally think systemd's configure should have an --enable-networking. I think this should be turned off. A network aware init could be internet worm material since you cannot kill process 1. Please read up on socket activation before making such broad comments. I feel very comfortable in saying that if you increase the attack surface of an unkillable and all powerful process, someone will notice this and find the hole one day and it might not even be in your code. You may do everything perfect and there is one hole in a library that is the undoing of the
Re: Anaconda memory requirements
On Sat, 20 Aug 2011 20:31:55 +0200, John Reiser wrote: Anaconda requires 768MB, and more (=1GB) if there is no swap partition. [...] Use the installer that is available on a Live spin, instead of using anaconda. This reduces the memory requirements by 128MB: Fedora-15-i686-Live-Desktop.iso Fedora requires 640 MB of memory to install, but you only have 256 MB on this machine. And even creating swap space in advance does not help - but a fix is underway: Fedora 15 Live refuses to install to disk on 256MB RAM, but installs fine with 2 simple workarounds https://bugzilla.redhat.com/show_bug.cgi?id=708966 Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Anaconda memory requirements
Would it be possible to create a custom image that just does a minimal (possibly text-based) install? This might reduce memory requirements even more, and extra packages could be added later - the DVD could be used as a repo if bandwidth is an issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda memory requirements
On Sat, 20 Aug 2011 11:31:55 -0700 John Reiser jrei...@bitwagon.com wrote: How much memory will anaconda require to install Fedora 16? Anaconda requires 768MB, and more (=1GB) if there is no swap partition. It is not just Anaconda. F15 GA kernel would not even uncompress initramfs on anything below 1GB. On VM hosts, I modify the VMs with virsh to have 1GB, then scale them down after installation. This is getting difficult to manage, I have to say. My almost brand new Red Hat corporate T400 only has 2GB, and I have a stack of almost good enough boxes. In the past we always felt free to push obsolete hardware over to BSD. Remember NPTL? CMOV? But now I have a feeling that we may be outstripping the speed of improvement in common hardware. Or maybe I need a better computer. I'm wondering what everyone's feeling is about it. I saw a tweet (by Mairin, I think) the 12GB is a life-changing experience. Well, if that's our new standard platform, then sure, no sense to optimize for 1GB. -- Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Hey all, my name is Jaroslav I live in Slovakia (central europe) and I am the upstream author of ipwatchd - daemon that detects IP conflicts in Linux. I maintain ipwatchd packages in Debian and I've received few request from Fedora users that they would like to see it packaged as RPM. So here I am :) willing to create the package and maintain it thereafter. Project website: http://ipwatchd.sourceforge.net/ Package review request: https://bugzilla.redhat.com/show_bug.cgi?id=726989 Thanks for any feedback -- Kind Regards / S pozdravom Jaroslav Imrich http://www.jimrich.sk jaroslav.imr...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda memory requirements
Use the installer that is available on a Live spin, instead of using anaconda. Arun, lets use live installer. Anaconda won't help in schools. Live, anyway, has its advantages and kids/teachers can check it out before installation. -- Aditya Patawari http://blog.adityapatawari.com/ India -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda memory requirements
On 08/21/2011 10:51 AM, Aditya Patawari wrote: Use the installer that is available on a Live spin, instead of using anaconda. Arun, lets use live installer. Anaconda won't help in schools. Live, anyway, has its advantages and kids/teachers can check it out before installation. Live installer is part of Anaconda as well Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Pod-Wordlist-hanekomu/f14] Initial import (perl-Pod-Wordlist-hanekomu-1.110090-3)
Summary of changes: 4cde408... Initial import (perl-Pod-Wordlist-hanekomu-1.110090-3) (*) (*) 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-Test-Mojibake/f14] Initial import (perl-Test-Mojibake-0.3-2)
Summary of changes: 43d4f14... Initial import (perl-Test-Mojibake-0.3-2) (*) (*) 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-Test-Mojibake] Created tag perl-Test-Mojibake-0.3-2.fc14
The lightweight tag 'perl-Test-Mojibake-0.3-2.fc14' was created pointing to: 43d4f14... Initial import (perl-Test-Mojibake-0.3-2) -- 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-Test-Mojibake] Created tag perl-Test-Mojibake-0.3-2.fc15
The lightweight tag 'perl-Test-Mojibake-0.3-2.fc15' was created pointing to: 43d4f14... Initial import (perl-Test-Mojibake-0.3-2) -- 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-Pod-Wordlist-hanekomu] Created tag perl-Pod-Wordlist-hanekomu-1.110090-3.fc14
The lightweight tag 'perl-Pod-Wordlist-hanekomu-1.110090-3.fc14' was created pointing to: 4cde408... Initial import (perl-Pod-Wordlist-hanekomu-1.110090-3) -- 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-Test-Mojibake/f15] Initial import (perl-Test-Mojibake-0.3-2)
Summary of changes: 43d4f14... Initial import (perl-Test-Mojibake-0.3-2) (*) (*) 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
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-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
