Re: F15 Feature - convert as many service init files as possible to the native SystemD services
2010/11/25 Tomas Mraz tm...@redhat.com: On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote: That's the point of the .path unit. i.e. you can list dirs to watch. If a user then drop a file into one of those dirs cron gets automatically started. Basically, in your .path unit you'd write something like this: [Path] PathExists=/etc/crontab DirectoryNotEmpty=/etc/cron.d DirectoryNotEmpty=/var/spool/cron And the moment where /etc/crontab starts to exist, or somebody drops a file into /etc/cron.d or /var/spool/cron crond would be automatically started. But what is the point of this? The /etc/crontab always exists and there always are some files in /etc/cron.d. Actually it's true, but in the near future all standard cron jobs might be runned by systemd http://0pointer.de/public/systemd-man/systemd.timer.html It's not 100 % cron replacement now, but who knows what the future holds :) Kind regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Tue, 23 Nov 2010 18:55:38 +0100, Kevin wrote: Mike Fedyk wrote: Install package from updates-testing, then +1 to karma after it works for you with your tests and normal workload. The average user won't even KNOW there's an update available in updates- testing before it's too late (i.e. all his/her data is gone, (s)he asks on forums or IRC what's up, and people point him/her to the testing update (which doesn't help because all the data is already corrupted/deleted!), at which point (s)he'll switch to Ubuntu or Window$ in disgust and swear to never use Fedora again). That can't be the full story. The distribution is based upon a long development period including several test releases. Are you trying to say that this data-eating-bug manages to slip through the cracks only for Fedora and not Ubuntu or Window$? I cannot believe that. This part of the thread is a lost cause already, if we want to go down that road while trying to fight for more freedom to decide on whether/when to push a stable update. :-/ Ubuntu contains plenty of packages with a large list of active bugs, which are not fixed with updates. Certainly not in a ASAP manner. No need to foist possibly broken software on everyone. That's exactly why bugs must be fixed ASAP! And a flood of rushed updates, which moves away farther from the originally tested final distribution, increases the risk that additional bugs must be fixed ASAP. That's going in circles. It's correct to pull up a fence and try to find more bugs prior to release of the dist *and* the updates. Returning to the topic, a new criterion for the updates acceptance could lower the hurdles for updates, which only patch the software (or the spec file) compared with the previous package release. That is, no attempts at hiding a version upgrade in a large scm-snapshot-patch, and no supposedly minor version bump which contains some fixes actually but also breaks something else (such as the infamous unexpected ABI/API breaks). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote: 2010/11/25 Tomas Mraz tm...@redhat.com: On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote: That's the point of the .path unit. i.e. you can list dirs to watch. If a user then drop a file into one of those dirs cron gets automatically started. Basically, in your .path unit you'd write something like this: [Path] PathExists=/etc/crontab DirectoryNotEmpty=/etc/cron.d DirectoryNotEmpty=/var/spool/cron And the moment where /etc/crontab starts to exist, or somebody drops a file into /etc/cron.d or /var/spool/cron crond would be automatically started. But what is the point of this? The /etc/crontab always exists and there always are some files in /etc/cron.d. Actually it's true, but in the near future all standard cron jobs might be runned by systemd http://0pointer.de/public/systemd-man/systemd.timer.html It's not 100 % cron replacement now, but who knows what the future holds :) I suppose the future holds systemd replacing the whole operating system. Resistance is futile. You will be assimilated. :) -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 update issue..
Michael Schwendt wrote: On Wed, 24 Nov 2010 13:25:15 -0700, Nathanael wrote: Hello, My aunt has F13 installed.. I got the following from her. Is this a known bug ?? I can't make heads or tails of the error message or what to tell her to do to resolve it. ERROR with rpm_check_debug vs depsolve: perl-libs = 4:5.10.1-112.fc13 is needed by perl-4:5.10.1-112.fc13.i686 perl-libs = 4:5.10.1-112.fc13 is needed by perl-4:5.10.1-112.fc13.i686 Please report this error at http://yum.baseurl.org/report Something worth reporting to bugzilla? This is multiarch breakage, which has been found and reported long ago, but won't be fixed. Nathanael, yes bugzilla, its fixable with a simple Obsoletes (which I'll commit to help with). -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 update issue..
On Thu, 25 Nov 2010 06:12:17 -0600, Rex wrote: On Wed, 24 Nov 2010 13:25:15 -0700, Nathanael wrote: Hello, My aunt has F13 installed.. I got the following from her. Is this a known bug ?? I can't make heads or tails of the error message or what to tell her to do to resolve it. ERROR with rpm_check_debug vs depsolve: perl-libs = 4:5.10.1-112.fc13 is needed by perl-4:5.10.1-112.fc13.i686 perl-libs = 4:5.10.1-112.fc13 is needed by perl-4:5.10.1-112.fc13.i686 Please report this error at http://yum.baseurl.org/report Something worth reporting to bugzilla? This is multiarch breakage, which has been found and reported long ago, but won't be fixed. Nathanael, yes bugzilla, its fixable with a simple Obsoletes (which I'll commit to help with). self-Obsoletes are a way to fix it, sure. It's one thing I tell packagers when they mail me in reply to broken deps reports. But when above I wrote it won't be fixed that refers to the result of the communication with Marcela Mašláňová about this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
04.11.2010 06:10, Orcan Ogetbil wrote: On Wed, Nov 3, 2010 at 10:59 PM, Adam Williamson wrote: On Wed, 2010-11-03 at 22:12 -0400, Orcan Ogetbil wrote: On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote: On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote: Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is. I disagree. I have seen many bugs fixed with the aid of abrt feedback. It beats the hell out of a bug report which says 'it crashed'. Does it compare to this number? (it takes a while to open) http://tinyurl.com/39yr832 Not hard to run the numbers. There've been 31,603 bugs reported to Bugzilla by abrt. There are 2,216 bugs reported by abrt that have been closed as CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE (which are the resolutions that usually imply 'it got fixed'). I think a tool that's resulted in 2,216 fixes for crasher bugs is pretty cool. :) I am pretty sure a subset of these closed bugs are mass-closing of bugs when a maintainer updates the software. Sometimes, when you forward the report upstream, they don't understand the output either, and say it may be fixed, just update and try. You update the software, put it to testing, and ask the user if it is fixed for him. The user doesn't respond as usual. Then you mark it as fixed without really knowing what's going on. Then you have such statistics. YAY! Orcan I think abrt is mostly useful tool, but it should be more interactive to our users. No, most problem from it (at my experience and by other answers there) because we got many reports dead at begining. Users encountered fill bug report, but if it is new user, it in 90% cases even do not answer on question how it may be reproduced. I assume it is main bad there. Can we add functionality track user bugreports and allow answer on requests (as minimum with 'needinfo' state) directly from abrt?? I think it may serious increase percentage of usefull bug reports from abrt. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On Thu, Nov 25, 2010 at 01:18:54AM -0500, Genes MailLists wrote: On 11/25/2010 01:13 AM, Genes MailLists wrote: http://oswatershed.org/ Hmm some interesting data there and some looks wrong to me: I see openssh at 5.5p1 not 5.0p1. but some like apache ours is lagging by quite a bit ... Did you email him to correct the openssh error? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libtool mismatch while building
Hello, How does one handle this error with libtool mismatches? I've run autoreconf, and aclocal autoconf automake, but it persists. (I don't know much about this stuff) [ankurgu...@070905042 xorg-input-wizardpen-0.8.0]$ make make all-recursive make[1]: Entering directory `/home/ankurGuest/rpmbuild/SOURCES/xorg-input-wizardpen-0.8.0' Making all in src make[2]: Entering directory `/home/ankurGuest/rpmbuild/SOURCES/xorg-input-wizardpen-0.8.0/src' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -fvisibility=hidden -I/usr/include/xorg -I/usr/include/pixman-1-I../src -MT wizardpen.lo -MD -MP -MF .deps/wizardpen.Tpo -c -o wizardpen.lo wizardpen.c libtool: Version mismatch error. This is libtool 2.2.6 Debian-2.2.6a-4, but the libtool: definition of this LT_INIT comes from libtool 2.2.6b. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 Debian-2.2.6a-4 libtool: and run autoconf again. make[2]: *** [wizardpen.lo] Error 63 make[2]: Leaving directory `/home/ankurGuest/rpmbuild/SOURCES/xorg-input-wizardpen-0.8.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ankurGuest/rpmbuild/SOURCES/xorg-input-wizardpen-0.8.0' make: *** [all] Error 2 Thanks, regards, Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libtool mismatch while building
Ankur Sinha sanjay.an...@gmail.com writes: Hello, How does one handle this error with libtool mismatches? I've run autoreconf, and aclocal autoconf automake, but it persists. (I don't know much about this stuff) Run autoreconf -fi. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Introducing wicked
Presenting wicked network configuration === This is the first public release of wicked, an experimental framework for network configuration. You may ask, don't we have enough of those already? Don't we have NetworkManager, connman, netcf, and a few more? The point I started from was the desire to unify what is usually provided through the traditional ifup script kudzu, with some of the more desktop oriented services provided by facilities like NetworkManager. I also wanted to move towards a more powerful set of functionality written in C, which is able to subsume functionality provided by ifconfig, ip(8), brctl, vconfig, ethtool, etc, and be able to drive these through an extensible XML representation of the network configuration. Kind of the Grand Unified Theory of network configuration :-) Right now, this implementation uses a daemon service and a command line utility. These two communicate securely via a local UNIX socket, allowing the server to validate the client's user id. The server offers a REST interface to various aspects of network configuration. The client application uses REST calls to retrieve interface configuration and status, or to reconfigure interfaces. The path space used by the API can be extended to cover other aspects of network configuration as well, such as reading, writing and restoring the resolv.conf file. After having hacked on this for a while, I want to release this to the community for feedback. If you're interested in finding out more, you will find a README and several manpages in the source code, which is available from http://gitorious.org/wicked Regards, Olaf Kirch o...@suse.de -- Neo didn't bring down the Matrix. SOA did. (soafacts.com) Olaf Kirch - Director Server (o...@novell.com) SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 update issue..
On 11/25/2010 02:15 PM, Michael Schwendt wrote: On Thu, 25 Nov 2010 06:12:17 -0600, Rex wrote: On Wed, 24 Nov 2010 13:25:15 -0700, Nathanael wrote: Hello, My aunt has F13 installed.. I got the following from her. Is this a known bug ?? I can't make heads or tails of the error message or what to tell her to do to resolve it. ERROR with rpm_check_debug vs depsolve: perl-libs = 4:5.10.1-112.fc13 is needed by perl-4:5.10.1-112.fc13.i686 perl-libs = 4:5.10.1-112.fc13 is needed by perl-4:5.10.1-112.fc13.i686 Please report this error at http://yum.baseurl.org/report Something worth reporting to bugzilla? This is multiarch breakage, which has been found and reported long ago, but won't be fixed. Nathanael, yes bugzilla, its fixable with a simple Obsoletes (which I'll commit to help with). self-Obsoletes are a way to fix it, sure. It's one thing I tell packagers when they mail me in reply to broken deps reports. But when above I wrote it won't be fixed that refers to the result of the communication with Marcela Mašláňová about this. Yes, we (Perl maintainers) already discussed this issue with you. But from our point view it was problem of wrong script, which create perl-libs for both architectures (i686 and x86_64). The easiest solution is to remove perl-libs-5.10.1-112.fc13.i686 from system, but I will test if obsolete would work. Imho yum could do solve it, so I'll create a RFE request for this issue. Regards, Marcela -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote: 2010/11/25 Tomas Mraz tm...@redhat.com: On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote: That's the point of the .path unit. i.e. you can list dirs to watch. If a user then drop a file into one of those dirs cron gets automatically started. Basically, in your .path unit you'd write something like this: [Path] PathExists=/etc/crontab DirectoryNotEmpty=/etc/cron.d DirectoryNotEmpty=/var/spool/cron And the moment where /etc/crontab starts to exist, or somebody drops a file into /etc/cron.d or /var/spool/cron crond would be automatically started. But what is the point of this? The /etc/crontab always exists and there always are some files in /etc/cron.d. Actually it's true, but in the near future all standard cron jobs might be runned by systemd http://0pointer.de/public/systemd-man/systemd.timer.html It's not 100 % cron replacement now, but who knows what the future holds :) To add some argument to my previous sarcasm. I do not think that it makes any sense to replicate cron functionality in systemd. Either you replicate half of it and then you still need to run crond for the rest or you replicate it completely. But in that case what is the saving over the separate daemon? I'm sorry but I do not think that crond is anything that optimized out by inclusion can improve performance of Linux desktop/server/whatever. I do not say that cronie code cannot be improved - it definitely can - but it does not make any sense to reimplement it from scratch. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
W dniu 25 listopada 2010 17:33 użytkownik Tomas Mraz tm...@redhat.com napisał: On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote: Actually it's true, but in the near future all standard cron jobs might be runned by systemd http://0pointer.de/public/systemd-man/systemd.timer.html It's not 100 % cron replacement now, but who knows what the future holds :) To add some argument to my previous sarcasm. I do not think that it makes any sense to replicate cron functionality in systemd. I do not know if it ever replace crond (I don't know Lennarts goals here), but having actual systemd.timer functionality in system daemon is IMHO very useful thing. Either you replicate half of it and then you still need to run crond for the rest or you replicate it completely. But in that case what is the saving over the separate daemon? I'm sorry but I do not think that crond is anything that optimized out by inclusion can improve performance of Linux desktop/server/whatever. I do not say that cronie code cannot be improved - it definitely can - but it does not make any sense to reimplement it from scratch. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Best regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libtool mismatch while building
On Thu, 2010-11-25 at 16:02 +0100, Andreas Schwab wrote: Ankur Sinha sanjay.an...@gmail.com writes: Hello, How does one handle this error with libtool mismatches? I've run autoreconf, and aclocal autoconf automake, but it persists. (I don't know much about this stuff) Run autoreconf -fi. Andreas. hello Andreas, Thanks for that. How would I do this in a spec? I've come across some mailing list threads that advise against usage of autotool commands in specs. Thanks, regards, Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libtool mismatch while building
On Thu, 2010-11-25 at 16:02 +0100, Andreas Schwab wrote: Ankur Sinha sanjay.an...@gmail.com writes: Hello, How does one handle this error with libtool mismatches? I've run autoreconf, and aclocal autoconf automake, but it persists. (I don't know much about this stuff) Run autoreconf -fi. Andreas. Hello, This is the error I receive while building the package (which was corrected by using autoreconf -fi). How should I change my spec[1] to work around the error please? Thanks, Ankur [1]http://ankursinha.fedorapeople.org/xorg-input-wizardpen/xorg-input-wizardpen.spec [ankurgu...@070905042 SPECS]$ rpmbuild -ba xorg-input-wizardpen.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.fevWVL + umask 022 + cd /home/ankurGuest/rpmbuild/BUILD + LANG=C + export LANG + unset DISPLAY + cd /home/ankurGuest/rpmbuild/BUILD + rm -rf xorg-input-wizardpen-0.8.0 + /bin/tar -xf - + /usr/bin/gzip -dc /home/ankurGuest/rpmbuild/SOURCES/xorg-input-wizardpen-0.8.0.tar.gz + STATUS=0 + '[' 0 -ne 0 ']' + cd xorg-input-wizardpen-0.8.0 + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.lVf0Aw + umask 022 + cd /home/ankurGuest/rpmbuild/BUILD + cd xorg-input-wizardpen-0.8.0 + LANG=C + export LANG + unset DISPLAY + CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables' + export CFLAGS + CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables' + export CXXFLAGS + FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -I/usr/lib/gfortran/modules' + export FFLAGS + ./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for style of include used by make... GNU checking for i686-pc-linux-gnu-gcc... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... none checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1966080 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking for /usr/bin/ld option to reload object files... -r checking for i686-pc-linux-gnu-objdump... no checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for i686-pc-linux-gnu-ar... no checking for ar... ar checking for i686-pc-linux-gnu-strip... no checking for strip... strip checking for i686-pc-linux-gnu-ranlib... no checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking
Re: libtool mismatch while building
Am 25.11.2010 18:16, schrieb Ankur Sinha: This is the error I receive while building the package (which was corrected by using autoreconf -fi). How should I change my spec[1] to work around the error please? libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 Debian-2.2.6a-4 Hi Ankur, it should be sufficient to run aclocal after calling autoreconf to fix the above issue. Martin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 update issue..
On Thu, 25 Nov 2010 17:31:18 +0100, Marcela wrote: On 11/25/2010 02:15 PM, Michael Schwendt wrote: On Thu, 25 Nov 2010 06:12:17 -0600, Rex wrote: On Wed, 24 Nov 2010 13:25:15 -0700, Nathanael wrote: Hello, My aunt has F13 installed.. I got the following from her. Is this a known bug ?? I can't make heads or tails of the error message or what to tell her to do to resolve it. ERROR with rpm_check_debug vs depsolve: perl-libs = 4:5.10.1-112.fc13 is needed by perl-4:5.10.1-112.fc13.i686 perl-libs = 4:5.10.1-112.fc13 is needed by perl-4:5.10.1-112.fc13.i686 Please report this error at http://yum.baseurl.org/report Something worth reporting to bugzilla? This is multiarch breakage, which has been found and reported long ago, but won't be fixed. Nathanael, yes bugzilla, its fixable with a simple Obsoletes (which I'll commit to help with). self-Obsoletes are a way to fix it, sure. It's one thing I tell packagers when they mail me in reply to broken deps reports. But when above I wrote it won't be fixed that refers to the result of the communication with Marcela Mašláňová about this. Yes, we (Perl maintainers) already discussed this issue with you. But from our point view it was problem of wrong script, which create perl-libs for both architectures (i686 and x86_64). The easiest solution is to remove perl-libs-5.10.1-112.fc13.i686 from system, but I will test if obsolete would work. Imho yum could do solve it, so I'll create a RFE request for this issue. It would be very helpful, if you really spent a minute to run repoquery --whatrequires libperl.so on an x86_64 machine. In short: There are other multiarch packages in the x86_64, which depend on the i686 Perl library. Hence you may be able to remove perl-libs.i686 from an x86_64 system, but not from the repo, since the multiarch compose tool (mash) adds it to the repo to satisfy dependencies. The original mistake is that perl.i686 no longer is dragged in, but still available in the Fedora 13 release repo (aka everything). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New gtk-vnc slower?n
Seems unlikely that it's gtk-vnc at fault here, but anyhow you should post the question the developer mailing list here: http://mail.gnome.org/mailman/listinfo/gtk-vnc-list Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Introducing wicked
On Thu, Nov 25, 2010 at 05:24:37PM +0100, Olaf Kirch wrote: You may ask, don't we have enough of those already? Don't we have NetworkManager, connman, netcf, and a few more? Indeed ... You don't explain how it's better than netcf. I notice a lot of hand-written C config file parsing in your code. netcf uses augeas which is a much sounder basis for making changes to config files. http://augeas.net/ https://fedorahosted.org/netcf/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Introducing wicked
On Thu, 25 Nov 2010 20:29:30 + Richard W.M. Jones rjo...@redhat.com wrote: On Thu, Nov 25, 2010 at 05:24:37PM +0100, Olaf Kirch wrote: You may ask, don't we have enough of those already? Don't we have NetworkManager, connman, netcf, and a few more? Indeed ... You don't explain how it's better than netcf. Or NM for that matter. There is nothing desktop-oriented about NM beyond the history when it was introduced to solve issues that originated on desktop. But its technical design is no different from what you are offering. Thus the case for replacement is not made. -- Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Introducing wicked
On 25/11/10 17:24, Olaf Kirch wrote: Presenting wicked network configuration === This is the first public release of wicked, an experimental framework for network configuration. You may ask, don't we have enough of those already? Don't we have NetworkManager, connman, netcf, and a few more? The point I started from was the desire to unify what is usually provided through the traditional ifup script kudzu, with some of the more desktop oriented services provided by facilities like NetworkManager. I also wanted to move towards a more powerful set of functionality written in C, which is able to subsume functionality provided by ifconfig, ip(8), brctl, vconfig, ethtool, etc, and be able to drive these through an extensible XML representation of the network configuration. XML? *cries* How about a nice simple file? ;) Kind of the Grand Unified Theory of network configuration :-) Right now, this implementation uses a daemon service and a command line utility. These two communicate securely via a local UNIX socket, allowing the server to validate the client's user id. The server offers a REST interface to various aspects of network configuration. The client application uses REST calls to retrieve interface configuration and status, or to reconfigure interfaces. The path space used by the API can be extended to cover other aspects of network configuration as well, such as reading, writing and restoring the resolv.conf file. After having hacked on this for a while, I want to release this to the community for feedback. If you're interested in finding out more, you will find a README and several manpages in the source code, which is available from http://gitorious.org/wicked Regards, Olaf Kircho...@suse.de -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
26.11.2010 00:43, Brendan Jones пишет: On 11/25/2010 11:38 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: I think abrt is mostly useful tool, but it should be more interactive to our users. No, most problem from it (at my experience and by other answers there) because we got many reports dead at begining. Users encountered fill bug report, but if it is new user, it in 90% cases even do not answer on question how it may be reproduced. I assume it is main bad there. Can we add functionality track user bugreports and allow answer on requests (as minimum with 'needinfo' state) directly from abrt?? I think it may serious increase percentage of usefull bug reports from abrt. I think I agree with what you are saying - would be nice for bugzappers to be able to filter out [abrt] bugs without debug symbols and steps to reproduce - has anyone done this? If not I could probably have a crack at it using the bugzilla commandline over the weekend. Main suggestion meantime was to continue dialog with user directly via abrt. It fill it via abrt and save credential. If I request something from user - abrt should show it information for user and provide possibility (at least) answer immediately. Furthermore, step to reproduce also is very important, and may be we should enforce users fill it? For example put it in separate required field and check it is not empty (or may be some minimal heuristic against fill it like '123', 'qwerty', 'qaz' like: longer than 10 symbols, contains at least 2 spaces). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Introducing wicked
On Thu, 2010-11-25 at 17:24 +0100, Olaf Kirch wrote: Presenting wicked network configuration === This is the first public release of wicked, an experimental framework for network configuration. You may ask, don't we have enough of those already? Don't we have NetworkManager, connman, netcf, and a few more? The point I started from was the desire to unify what is usually provided through the traditional ifup script kudzu, with some of the more desktop oriented services provided by facilities like NetworkManager. I also wanted to move towards a more powerful set of functionality written in C, which is able to subsume functionality provided by ifconfig, ip(8), brctl, vconfig, ethtool, etc, and be able to drive these through an extensible XML representation of the network configuration. Kind of the Grand Unified Theory of network configuration :-) Right now, this implementation uses a daemon service and a command line utility. These two communicate securely via a local UNIX socket, allowing the server to validate the client's user id. The server offers a REST interface to various aspects of network configuration. The client application uses REST calls to retrieve interface configuration and status, or to reconfigure interfaces. The path space used by the API can be extended to cover other aspects of network configuration as well, such as reading, writing and restoring the resolv.conf file. After having hacked on this for a while, I want to release this to the community for feedback. If you're interested in finding out more, you will find a README and several manpages in the source code, which is available from http://gitorious.org/wicked I'm going to be a little more positive with my comments for Olaf. The way I read his original post, is he is simply providing an alternative in addition to what we already have. I certainly didn't ready it as a replacement proposal. Good work Olaf. Keep up the good work. For future reference, we need to encourage these sorts of development projects. It's great for both Fedora and Linux. Regards -- Chris Jones PHOTO RESOLUTIONS - Photo - Graphic - Web ABN: 98 317 740 240 @: chrisjo...@comcen.com.au WWW: http://photoresolutions.freehostia.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File CGI-Application-Plugin-Authentication-0.19.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-CGI-Application-Plugin-Authentication: 778f9e3c5ec4ba7702cc932d37bf9230 CGI-Application-Plugin-Authentication-0.19.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Introducing wicked
On Thu, Nov 25, 2010 at 11:17:48PM +0100, nodata wrote: On 25/11/10 17:24, Olaf Kirch wrote: Presenting wicked network configuration === This is the first public release of wicked, an experimental framework for network configuration. You may ask, don't we have enough of those already? Don't we have NetworkManager, connman, netcf, and a few more? making a list of those is already an achievement :) The point I started from was the desire to unify what is usually provided through the traditional ifup script kudzu, with some of the more desktop oriented services provided by facilities like NetworkManager. I also wanted to move towards a more powerful set of functionality written in C, which is able to subsume functionality provided by ifconfig, ip(8), brctl, vconfig, ethtool, etc, and be able to drive these through an extensible XML representation of the network configuration. XML? *cries* How about a nice simple file? ;) seconded. Or JSON if something fancy is desperately needed. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 11/26/2010 08:24 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: Furthermore, step to reproduce also is very important, and may be we should enforce users fill it? For example put it in separate required field and check it is not empty (or may be some minimal heuristic against fill it like '123', 'qwerty', 'qaz' like: longer than 10 symbols, contains at least 2 spaces). (I know this thread has been done to death - but anyway) I'm sure there are maintainers who find the 'weightless' [abrt] bugs useful in certain scenarios (if only for gauging prevalence). There is a lot of clutter, I think it would be nice to filter these somehow via query in bugzilla. Insisting on debuginfo and comments will mean that the average joe will never use abrt, and I see that as a loss somehow (ha ha - that would reduce the clutter) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-CGI-Application-Plugin-Authentication] Update to 0.19
commit 0cba28c61702b6ad49b55ae931744fac1998711c
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Fri Nov 26 00:27:21 2010 +0100
Update to 0.19
.gitignore |1 +
perl-CGI-Application-Plugin-Authentication.spec |6 +-
sources |2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 296ed68..97e7444 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
CGI-Application-Plugin-Authentication-0.18.tar.gz
+/CGI-Application-Plugin-Authentication-0.19.tar.gz
diff --git a/perl-CGI-Application-Plugin-Authentication.spec
b/perl-CGI-Application-Plugin-Authentication.spec
index 5161b90..fb14c71 100644
--- a/perl-CGI-Application-Plugin-Authentication.spec
+++ b/perl-CGI-Application-Plugin-Authentication.spec
@@ -1,5 +1,5 @@
Name: perl-CGI-Application-Plugin-Authentication
-Version:0.18
+Version:0.19
Release:1%{?dist}
Summary:Authentication framework for CGI::Application
License:GPL+ or Artistic
@@ -25,6 +25,7 @@ BuildRequires: perl(Task::Weaken)
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::MockObject)
BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::NoWarnings)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Regression)
BuildRequires: perl(Test::Taint)
@@ -70,6 +71,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Nov 25 2010 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.19-1
+- Update to 0.19
+
* Wed Jul 19 2010 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.18-1
- Update to 0.18
- Add new BuidlRequires
diff --git a/sources b/sources
index d1f49ce..402f0b0 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-77ea474264927307a6aad1d6832af834
CGI-Application-Plugin-Authentication-0.18.tar.gz
+778f9e3c5ec4ba7702cc932d37bf9230
CGI-Application-Plugin-Authentication-0.19.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Thu, 25.11.10 08:39, Tomas Mraz (tm...@redhat.com) wrote: That's the point of the .path unit. i.e. you can list dirs to watch. If a user then drop a file into one of those dirs cron gets automatically started. Basically, in your .path unit you'd write something like this: [Path] PathExists=/etc/crontab DirectoryNotEmpty=/etc/cron.d DirectoryNotEmpty=/var/spool/cron And the moment where /etc/crontab starts to exist, or somebody drops a file into /etc/cron.d or /var/spool/cron crond would be automatically started. But what is the point of this? The /etc/crontab always exists and there always are some files in /etc/cron.d. The only contents of /etc/crontab and /etc/cron.d is the lines to handle /etc/cron.daily and friends. As mentioned we can easily run those as normal timer-triggerd units inside of systemd itself (and get all the features it offers you for free, nice introspection, logging, IO/CPU scheduling hooks, yadda yadda). So, if you remove that /etc/crontab is empty and hence could be removed. And /etc/cron.d is empty too. And there you go, we can support cron jobs just fine, but won't even start it on most machines, but the user won't se the difference in the behaviour. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Thu, 25.11.10 17:33, Tomas Mraz (tm...@redhat.com) wrote: Actually it's true, but in the near future all standard cron jobs might be runned by systemd http://0pointer.de/public/systemd-man/systemd.timer.html It's not 100 % cron replacement now, but who knows what the future holds :) To add some argument to my previous sarcasm. I do not think that it makes any sense to replicate cron functionality in systemd. Either you replicate half of it and then you still need to run crond for the rest or you replicate it completely. But in that case what is the saving over the separate daemon? I'm sorry but I do not think that crond is anything that optimized out by inclusion can improve performance of Linux desktop/server/whatever. I do not say that cronie code cannot be improved - it definitely can - but it does not make any sense to reimplement it from scratch. crond is not particularly complex. And providing similar functionality in systemd is relatively easy as the more complicated stuff cron does is actually spawning the processes, and systemd is vastly more powerful with that. i.e. you can set IO/CPU schedulers, get sane logging, get all the cgroups niftyness, you can pull in extra deps, yadda yadda. Also, what's particularly interesting is that you can combine various triggers if you do this in systemd: i.e. have one timer-based trigger, and one inotify trigger (i.e. .path unit), and they start the same job, and you don't end up with duplicates and need locking. And also, cron does a couple of really nasty things. For example it wakes up in regular intervals to check if a job is ready to run. It does so to deal with wallclock time changes/suspends. In systemd we are working on a different way to solve this, so that we can actually sleep as long as possible, and don't have to wake up in regular intervals. Also, this means we can have much more accurate time specifications, and we don't have to pay a price for it, due to this. This different design will even allow us to do amazing stuff that hasn't existed so far, for example, mark cron jobs so that they wake up the machine from suspend, and similar. To summarize this: the current logic of cron is not pretty. And it duplicates process spawning and babysitting which already exists in way too many daemons, and is actually the more interesting code. systemd unifies all that code, and the end result will be simpler, more powerful and less code, since we reuse what already exists anyway. The only thing we basically add to systemd is a parser for calendar events, and everything else already exists. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Fri, 26 Nov 2010 01:15:04 +0100, Lennart Poettering wrote: The only contents of /etc/crontab and /etc/cron.d is the lines to handle /etc/cron.daily and friends. As mentioned we can easily run On RHEL/CentOS (and it's likely only a matter of time before systemd fillers through to them) various programs install jobs into /etc/cron.d a quick look on one machine shows; mailman and sysstat related jobs as well as some others... those as normal timer-triggerd units inside of systemd itself (and get all the features it offers you for free, nice introspection, logging, IO/CPU scheduling hooks, yadda yadda). So, if you remove that /etc/crontab is empty and hence could be removed. And /etc/cron.d is empty too. And there you go, we can support cron Although I can't be the only one who puts various cron jobs under /etc/cron.d that get run at various times. Andrew -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
Although I can't be the only one who puts various cron jobs under /etc/cron.d that get run at various times. Andrew Almost every administrative cron here is in a cron.d crontab file .. we need control over exactly what time certain things happen. So please keep the functionality. If systemd is the expert spawner - then perhaps things like cron (or any reproductive daemon for that matter) could lean on a systemd for spawn service - but leave the other application specific parts to the local daemons to do for themselves. There is some merit in functional separation too ... g -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100: And also, cron does a couple of really nasty things. For example it wakes up in regular intervals to check if a job is ready to run. It does so to deal with wallclock time changes/suspends. In systemd we are working on a different way to solve this, so that we can actually sleep as long as possible, and don't have to wake up in regular intervals. Also, this means we can have much more accurate time specifications, and we don't have to pay a price for it, due to this. This different design will even allow us to do amazing stuff that hasn't existed so far, for example, mark cron jobs so that they wake up the machine from suspend, and similar. To summarize this: the current logic of cron is not pretty. And it duplicates process spawning and babysitting which already exists in way too many daemons, and is actually the more interesting code. systemd unifies all that code, and the end result will be simpler, more powerful and less code, since we reuse what already exists anyway. The only thing we basically add to systemd is a parser for calendar events, and everything else already exists. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100: On Thu, 25.11.10 17:33, Tomas Mraz (tm...@redhat.com) wrote: And also, cron does a couple of really nasty things. For example it wakes up in regular intervals to check if a job is ready to run. It does so to deal with wallclock time changes/suspends. In systemd we are working on a different way to solve this, so that we can actually sleep as long as possible, and don't have to wake up in regular intervals. Great. You can fix cron then, this does not mean it is necessary to integrate the two. To summarize this: the current logic of cron is not pretty. And it duplicates process spawning and babysitting which already exists in way too many daemons, I think you'll find the execution of processes is a comparatively small part of cron. And anyway, process spawning and babysitting will _always_ exist in many different daemons, unless you want to run the whole system within a single systemd process. It would be much much better for the ecosystem to extract these parts of systemd into a library (perhaps standalone, perhaps interacting with the system-wide systemd runtime) that can be used in any other process that needs to run a task in a separately tracked daemon group. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New gtk-vnc slower?
On Wed, 2010-11-24 at 22:05 -0700, Jerry James wrote: I have a collection of virtual machines that I use to test cross-platform compatibility of some code I'm developing. Today, the virtual machine I was working on kept getting slower and slower whenever a window refresh was needed. It got to the point that refreshing a terminal window was taking nearly half a second per line. My eyes could easily track the refresh going on. Moving a window was impossible, as I could see the entire window being redrawn, pixel by pixel, and it would just keep going long after I had released the mouse. Keys were repeating right and left, probably because of a sequence like KeyDown, refresh action that takes a really long time, KeyUp. I shut everything down, logged out, and even rebooted, to see if it was some weird behavior caused by a recent update that had only partly taken effect. When I started my VM back up, it was very snappy. But then, over time, it got a little slower and a little slower, until eventually I was back to watching refreshes happen line by line again. This never happened before today. I looked through the recent updates my machine has received. All I can see that might be relevant was an update to gtk-vnc-0.4.2-1.fc14.x86_64. The machine in question is a quad-core Intel with 8GB of RAM and an Nvidia video card of some kind. (Sorry, should have checked which one before leaving work.) The host is fine; it's just the virtual machines I open with virt-manager that are affected. I tried several, and they're all behaving like this today, which argues for the problem being on the host side. Is anybody else seeing this? Is there any other component besides gtk-vnc that I should examine as a possible source of the slowdown? VMs have been behaving like this for me in Rawhide at least for a while. Ever since I went from F14 to Rawhide. Not sure about F14. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 657015] perl-Sub-WrapPackages should not provide local override perl(lib)
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=657015 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2010-11-25 20:07:12 EST --- perl-Sub-WrapPackages-2.0-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Sub-WrapPackages'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/perl-Sub-WrapPackages-2.0-3.fc14 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 654301] False-positive related to XS code - please update to 0.11 or later
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=654301 --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2010-11-25 20:09:03 EST --- perl-Test-LeakTrace-0.13-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 654301] False-positive related to XS code - please update to 0.11 or later
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=654301 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2010-11-25 20:17:00 EST --- perl-Test-LeakTrace-0.13-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Fri, 26.11.10 02:07, Miloslav Trmač (m...@volny.cz) wrote: Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100: On Thu, 25.11.10 17:33, Tomas Mraz (tm...@redhat.com) wrote: And also, cron does a couple of really nasty things. For example it wakes up in regular intervals to check if a job is ready to run. It does so to deal with wallclock time changes/suspends. In systemd we are working on a different way to solve this, so that we can actually sleep as long as possible, and don't have to wake up in regular intervals. Great. You can fix cron then, this does not mean it is necessary to integrate the two. Well, I actually believe we should design an OS here, not just a set of independent tools. And that means I think closer integration is good and only has benefits. To summarize this: the current logic of cron is not pretty. And it duplicates process spawning and babysitting which already exists in way too many daemons, I think you'll find the execution of processes is a comparatively small part of cron. Well, and that's why it is also very limited. And anyway, process spawning and babysitting will _always_ exist in many different daemons, unless you want to run the whole system within a single systemd process. Sure, no doubt about that. But unifying this for system stuff is a good thing, not a bad thing. It would be much much better for the ecosystem to extract these parts of systemd into a library (perhaps standalone, perhaps interacting with the system-wide systemd runtime) that can be used in any other process that needs to run a task in a separately tracked daemon group. Mirek Well, I don't think that that technically makes any sense. Sorry. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Thu, 25.11.10 19:57, Genes MailLists (li...@sapience.com) wrote: Although I can't be the only one who puts various cron jobs under /etc/cron.d that get run at various times. Andrew Almost every administrative cron here is in a cron.d crontab file .. we need control over exactly what time certain things happen. So please keep the functionality. Hey, as I made explcitily clear I have no plans of taking away anything from you. No need to be defensive... If systemd is the expert spawner - then perhaps things like cron (or any reproductive daemon for that matter) could lean on a systemd for spawn service - but leave the other application specific parts to the local daemons to do for themselves. There is some merit in functional separation too ... Well, there isn't if the remaining bits simply do some minimal calendar calculations and do that in a way we shouldn't do things anymore, and hence needs to be fixed anyway. As mentioned: i have no plans to take crond away. Just change it to be started a little bit differently. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On 11/25/2010 09:08 PM, Lennart Poettering wrote: On Thu, 25.11.10 19:57, Genes MailLists (li...@sapience.com) wrote: keep the functionality. Hey, as I made explcitily clear I have no plans of taking away anything from you. No need to be defensive... Actually that was after I posted but ok :-) good! There is some merit in functional separation too ... Well, there isn't if the remaining bits simply do some minimal calendar calculations and do that in a way we shouldn't do things anymore, and hence needs to be fixed anyway. mmm maybe ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On 11/25/2010 09:19 PM, Genes MailLists wrote: On 11/25/2010 09:08 PM, Lennart Poettering wrote: On Thu, 25.11.10 19:57, Genes MailLists (li...@sapience.com) wrote: keep the functionality. Hey, as I made explcitily clear I have no plans of taking away anything from you. No need to be defensive... Also was not being defensive (or aggressive :-) - just politely asking ... thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
Lennart Poettering píše v Pá 26. 11. 2010 v 03:05 +0100: On Fri, 26.11.10 02:07, Miloslav Trmač (m...@volny.cz) wrote: Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100: On Thu, 25.11.10 17:33, Tomas Mraz (tm...@redhat.com) wrote: And also, cron does a couple of really nasty things. For example it wakes up in regular intervals to check if a job is ready to run. It does so to deal with wallclock time changes/suspends. In systemd we are working on a different way to solve this, so that we can actually sleep as long as possible, and don't have to wake up in regular intervals. Great. You can fix cron then, this does not mean it is necessary to integrate the two. Well, I actually believe we should design an OS here, not just a set of independent tools. And that means I think closer integration is good and only has benefits. At the very least, closer integration makes troubleshooting significantly more difficult. Each point where separate tools interact is a point where it is possible, and in UNIX often easy, to insert debugging instrumentation. If the system integrates everything into one process, the only remaining troubleshooting mechanisms are integrated logging (which is by definition unsatisfactory - if a problem was foreseen enough to be logged, it was probably also foreseen enough to be avoided), debugger (useless for non-programmers, useless for non-expert programmers that need to fix things in a hurry, practically useless with -O2) and systemtap (only a little better than a debugger, and not available for most programs). Design an OS means that the system _design_ should fit well together, nothing more. It would be much much better for the ecosystem to extract these parts of systemd into a library (perhaps standalone, perhaps interacting with the system-wide systemd runtime) that can be used in any other process that needs to run a task in a separately tracked daemon group. Mirek Well, I don't think that that technically makes any sense. Sorry. Care to elaborate? Look at sshd: it needs to start per-user sessions from a single daemon. Wouldn't it make sense to track these as cgroups recognized by systemd? Crond is _exactly_ the same thing. Any other remote access protocol (POSIX batch facilities, func, X server accepting remote clients, and anything else that isn't currently a part of the system and thus can't be rewritten as part of systemd) would benefit from this facility. AFAICS it would be clearly useful to be able to delegate the control of daemon group creation to other processes. Why doesn't it make sense? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
Once upon a time, Lennart Poettering mzerq...@0pointer.de said: Well, I actually believe we should design an OS here, not just a set of independent tools. And that means I think closer integration is good and only has benefits. But this is a Unix-like OS, where each tool does one (or few) things and does them well. systemd is not the OS, it is just one tool. Please don't try to subsume the entire OS into systemd. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On 11/25/2010 11:01 PM, Chris Adams wrote: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: Well, I actually believe we should design an OS here, not just a set of independent tools. And that means I think closer integration is good and only has benefits. But this is a Unix-like OS, where each tool does one (or few) things and does them well. systemd is not the OS, it is just one tool. Please don't try to subsume the entire OS into systemd. Lets get systemd working well and as close to dammit as bug free please .. before we start having it take over other parts of the OS ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On 11/26/2010 01:27 AM, Lennart Poettering wrote: On Thu, 25.11.10 17:33, Tomas Mraz (tm...@redhat.com) wrote: Actually it's true, but in the near future all standard cron jobs might be runned by systemd http://0pointer.de/public/systemd-man/systemd.timer.html It's not 100 % cron replacement now, but who knows what the future holds :) To add some argument to my previous sarcasm. I do not think that it makes any sense to replicate cron functionality in systemd. Either you replicate half of it and then you still need to run crond for the rest or you replicate it completely. But in that case what is the saving over the separate daemon? I'm sorry but I do not think that crond is anything that optimized out by inclusion can improve performance of Linux desktop/server/whatever. I do not say that cronie code cannot be improved - it definitely can - but it does not make any sense to reimplement it from scratch. crond is not particularly complex. And providing similar functionality in systemd is relatively easy as the more complicated stuff cron does is actually spawning the processes, and systemd is vastly more powerful with that. i.e. you can set IO/CPU schedulers, get sane logging, get all the cgroups niftyness, you can pull in extra deps, yadda yadda. Also, what's particularly interesting is that you can combine various triggers if you do this in systemd: i.e. have one timer-based trigger, and one inotify trigger (i.e. .path unit), and they start the same job, and you don't end up with duplicates and need locking. And also, cron does a couple of really nasty things. For example it wakes up in regular intervals to check if a job is ready to run. It does so to deal with wallclock time changes/suspends. In systemd we are working on a different way to solve this, so that we can actually sleep as long as possible, and don't have to wake up in regular intervals. Also, this means we can have much more accurate time specifications, and we don't have to pay a price for it, due to this. This different design will even allow us to do amazing stuff that hasn't existed so far, for example, mark cron jobs so that they wake up the machine from suspend, and similar. Cronie is using inotify, so it doesn't wake every minute as it used to. I'm just curious, how many programmes would stay in Fedora after you finish systemd ;-) /sarcasm. Marcela -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Fri, 2010-11-26 at 07:42 +0100, Marcela Mašláňová wrote: I'm just curious, how many programmes would stay in Fedora after you finish systemd ;-) /sarcasm. and do we run systemd in emacs, or emacs from systemd?! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 657153] Circular Dependency between perl-Readonly and perl-Readonly-XS
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=657153 Paul Howarth p...@city-fan.org changed: What|Removed |Added CC||p...@city-fan.org --- Comment #1 from Paul Howarth p...@city-fan.org 2010-11-25 04:18:52 EST --- Whilst it's true that the packages have runtime dependencies on each other (resulting in all users getting the performance benefits of the XS code), neither of them have build-time dependencies on each other so it should be possible to build each of them without requiring the other at build time. What error message are you getting when trying to build them? -- 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 657153] Circular Dependency between perl-Readonly and perl-Readonly-XS
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=657153 --- Comment #2 from Andrew McNaughton amcnaugh...@squiz.net 2010-11-25 05:05:16 EST --- (In reply to comment #1) Whilst it's true that the packages have runtime dependencies on each other (resulting in all users getting the performance benefits of the XS code), neither of them have build-time dependencies on each other so it should be possible to build each of them without requiring the other at build time. What error message are you getting when trying to build them? Errors like so: [r...@centos-5-64.build]:/home/build/rpms/RPMS/centos/5# rpm -i /home/build/rpms/RPMS/centos/5/x86_64/perl-Readonly-XS-1.04-7.1-squiz.x86_64.rpm error: Failed dependencies: perl(Readonly) = 1.02 is needed by perl-Readonly-XS-1.04-7.1.x86_64 [r...@centos-5-64.build]:/home/build/rpms/RPMS/centos/5# rpm -i /home/build/rpms/RPMS/centos/5/x86_64/perl-Readonly-1.03-6-squiz.noarch.rpm error: Failed dependencies: perl(Readonly::XS) is needed by perl-Readonly-1.03-6.noarch hmm. actually maybe that was just after building from spec file so, can build, but can't install. -- 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 657153] Circular Dependency between perl-Readonly and perl-Readonly-XS
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=657153 --- Comment #3 from Paul Howarth p...@city-fan.org 2010-11-25 05:33:56 EST --- You need to install them in the same rpm transaction, which is what would happen if you were using yum. # rpm -i \ perl-Readonly-XS-1.04-7.1-squiz.x86_64.rpm \ perl-Readonly-1.03-6-squiz.noarch.rpm Why aren't you installing these from EPEL using yum by the way? -- 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
