Re: systemd: Is it wrong?
On 07/11/2011 02:22 AM, Steve Dickson wrote: > > On 07/10/2011 07:06 PM, Lennart Poettering wrote: >> On Sun, 10.07.11 13:32, Steve Dickson (ste...@redhat.com) wrote: >> >>> Hey, >>> >>> On 07/10/2011 11:32 AM, Matthew Garrett wrote: Improvement means change, and change will inevitably upset some people who would prefer to do things in exactly the same way that they always have done. >>> I will have to slightly disagree. If improvement does indeed come with >>> the change, then I believe the change will warmly embraced by 99% of >>> the community. But if the change introduces confusion, deteriorates >>> "easy-of-use" and possibly introduces regressions (as systemd just >>> might possibly do, esp in the early stages), then that change will not >>> be strongly embraced. >> I am sorry, but I cannot help myself: >> >> The "easy-of-use" of the current NFS stack is indeed legendary. > :-) You are right... NFS is legendary... It is one of the oldest > technology today but also one of the most used technology today. > > But you also make my point... For some one to come along (with absolutely > no NFS understand whatsoever) and simply disregard all of that history > of how and how not to start things up and simply say the know how > to do it better... is just a bit... well... ;-) > > steved. I think that any change that leaves a major subsystem not working is simply not ready for prime time. If systemd is to become the default, we need to convince the upstream NFS team to modify their configuration (and keep in mind that this is a pain since systemd has not become the default in all distros, so this is effectively a fork). It is pointless to argue style and design. Rather, let's work this as you would with anything else. Let's see proposed, tested and working patches from the change proponents that allows NFS to work fully. Those patches will have to be acceptable to the upstream of the NFS world which means Steve and others have to buy in here or they simply won't fly Thanks! Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Sun, 10 Jul 2011 20:49:56 -0400 Steve Dickson wrote: > Ok.. Now understand where my confusion is... Currently when one > want to start the nfs server they type 'service nfs start' which > calls a number of binaries and ultimately a system daemon. We could achieve something similar with systemd by providing a target unit 'nfs.target'. The unit would pull the daemons using requirement dependencies. > Now if they enable want secure nfs, they edit a file in /etc/systconf > and simply type 'service nfs restart' which again runs a number > of binaries and start a couple of system daemons. This could be another target 'nfs-secure.target'. It would pull 'nfs.target' + more daemons. The users would start and enable these target units instead of the units of the individual daemons. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
Lennart Poettering 0pointer.de> writes: > ... I would like to verify the systemd's parallelism (or should we say concurrency in case of systemd ?) claim. Any parallelization possible to achieve thru configuration of service files ? What it would look like ? Let me take a shot at 2 examples of service files below. Are they correct setup-wise ? Will both examples be executed sequentially only ? 1. main-service-1.service: [Unit] Description=Main service 1 Requires= ... sub-service-1.service sub-service-2.service After= ... sub-service-1.service sub-service-2.service ... [Service] Type=forking<-- any other type too ? ExecStartPre= ExecStartPre= ExecStart= ExecStart= /usr/sbin/some-service ExecStartPost= ExecStartPost= ... sub-service-1.service: [Unit] Description=Sub service 1 ... [Service] ... sub-service-2.service: [Unit] Description=Sub service 2 ... [Service] ... 2. main-service-2.service: [Unit] Description=Main service 2 After= ... ... [Service] Type=forking<-- any other type too ? ExecStartPre= sub-service-1.service ExecStartPre= sub-service-2.service ExecStart= ExecStart= /usr/sbin/some-service ExecStartPost= ExecStartPost= ... sub-service-1.service: [Unit] Description=Sub service 1 ... [Service] ... sub-service-2.service: [Unit] Description=Sub service 2 ... [Service] ... What if sysadmin wants to execute them in parallel because she knows they can be executed this way (no conflict and no races) ? How, if by definition, systemd executes them sequentially only ? Can they be grouped and execution-parallelized in the whole service file, or at least in subgroups Pre-, regular, and Post- ? The /etc/init.d/nfs under current SysV init system can start the main service and include calling sub-services (each of whom is a separate service as well). Yes, they are executed sequentially. Can that be done under systemd as well ? Are the examples given above good for that ? If yes, they would be examples of a sequential execution as under SysV init ? So, where would be the promised parallelism in there, in the way the main and sub services are executed ? Can you give us a working example of a services setup (or something else) in systemd where execution-parallelism would be present or at least theoretically exploitable ? JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/11/2011 02:40 AM, Steve Dickson wrote: > I truly truly truly hope so... but at the end of the day... I > simply can't allow a new, untested (in a business environment) > package destabilize a technology that is used by a large number > of our community... The longer it takes to get a native systemd unit files out there the more "untested" they will become. The faster they will be out there the more experience/exposer they will receive. No rocket science behind that logic some would even go so far as calling that common knowledge so if you are truly worried about that, convert those legacy sysv init file and put the native systemd unit file out there, the sooner the better.. I think it's time that we hear from you explaining to us how systemd has brought doom and chaos to the nfs world, how it has destabilize nfs and left the *major subsystem* not working and it's citizens running for their lives, committing mass suicide on the side walks and the cities being overrun by zombies and the nfs world going down in flames... What do you say? How about explaining that to us so we can catch and fix bugs ( if any ) in timely manner on either side ;) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Sun, Jul 10, 2011 at 11:51 PM, Steve Clark wrote: > On 07/10/2011 05:35 PM, Matthew Garrett wrote: > > On Sun, Jul 10, 2011 at 03:56:25PM -0500, Chris Adams wrote: > > Once upon a time, Matthew Garrett said: > > The suggestion isn't that having the options is wrong > > Well, that's what you said before (conveniently snipped from your > reply). You compared CLI args/env vars to the BKL as something to be > eliminated; specifically, you said (and I quoted): > > In this case there are sound > technical arguments against configuration by command line argument or > environment variable > > You have still failed to enumerate even one of the "sound technical > arguments". > > "Configuration by", not overriding configuration. It's a mistake to have > > Says you. It has seemed to work OK for the last 25+ years. Yet another "it has been done for $years so it must be right" kind of argument ... Do you configure your webbrowser by passing command line arguments and/or editing its source code? Do you configure your word process by passing command line arguments and/or editing its source code? Do you configure $app by passing command line arguments and/or editing its source code? No and you wouldn't want to change to such a scheme simply because it hasn't been like that for "25+ years". The same thing applies to system daemons only because it has been done like this does not make it right ... and really asking the user to edit the source code (yes shell scripts are source code not configuration files) is just wrong.It is kind of odd seeing people arguing in favor of that ... with the only reason "it has been like that for $years". Yes people got used to that simply because there where no alternative (people adding new scripts simply followed the lead of existing ones). But now we have a chance to clean up this mess so we should do that and not try to stick to the past forever. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/11/2011 08:42 AM, Michal Schmidt wrote: > On Sun, 10 Jul 2011 20:49:56 -0400 Steve Dickson wrote: >> Ok.. Now understand where my confusion is... Currently when one >> want to start the nfs server they type 'service nfs start' which >> calls a number of binaries and ultimately a system daemon. > We could achieve something similar with systemd by providing a target > unit 'nfs.target'. The unit would pull the daemons using requirement > dependencies. > >> Now if they enable want secure nfs, they edit a file in /etc/systconf >> and simply type 'service nfs restart' which again runs a number >> of binaries and start a couple of system daemons. > This could be another target 'nfs-secure.target'. It would pull > 'nfs.target' + more daemons. > > The users would start and enable these target units instead of > the units of the individual daemons. I was thinking along the same line... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, 11 Jul 2011 08:44:16 + (UTC) JB wrote: > Let me take a shot at 2 examples of service files below. > Are they correct setup-wise ? > Will both examples be executed sequentially only ? > > 1. > > main-service-1.service: > [Unit] > Description=Main service 1 > Requires= ... sub-service-1.service sub-service-2.service > After= ... sub-service-1.service sub-service-2.service > ... > [Service] > Type=forking<-- any other type too ? > ExecStartPre= > ExecStartPre= > ExecStart= > ExecStart= /usr/sbin/some-service Nitpick: You can have only one ExecStart= in a forking unit. Only oneshot units can have more. > ExecStartPost= > ExecStartPost= > ... > > sub-service-1.service: > [Unit] > Description=Sub service 1 > ... > [Service] > ... > > sub-service-2.service: > [Unit] > Description=Sub service 2 > ... > [Service] > ... First, sub-service-1.service and sub-service-2.service will be started in parallel. When they're running, main-service-1.service will be started by processing its ExecStart* commands sequentially. > 2. > > main-service-2.service: > [Unit] > Description=Main service 2 > After= ... > ... > [Service] > Type=forking<-- any other type too ? > ExecStartPre= sub-service-1.service > ExecStartPre= sub-service-2.service This is incorrect. ExecStartPre= expects a command to run, not a unit name. > What if sysadmin wants to execute them in parallel because she knows > they can be executed this way (no conflict and no races) ? > How, if by definition, systemd executes them sequentially only ? > Can they be grouped and execution-parallelized in the whole service > file, or at least in subgroups Pre-, regular, and Post- ? Parallelism in systemd happens between multiple units, but never between ExecStart* commands of one unit. Requesting parallelism within one unit seems like over-engineering to me. You can always split your unit to smaller ones if you want parallelism. > Can you give us a working example of a services setup (or something > else) in systemd where execution-parallelism would be present or at > least theoretically exploitable ? Take a look at 'systemd-analyze plot' where you can clearly see services starting in parallel. This Lennart's blog post has an example: http://0pointer.de/blog/projects/blame-game.html Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
Am 11.07.2011 02:49, schrieb Steve Dickson: > My point it this. You are changing the meaning of 'service'. People > expect a service to be just that as service. When one starts a > service all the needed daemons are started and all the configuration > is done once the service is started. > > Unless I'm misunderstanding, for an admin to the same thing as above > the will have to type of string of commands enabling all the needed > daemons... People are not expecting or even what to know which daemon > is need to start up each service... oops.. a service is not longer > as service its a daemon... hmm... let use subsystem... see my point? the same problem with the logic "if there is a svcname.socket" you have to do "systemctl stop svcname.socket svcname.service" or systemd wil fire up it again if you do only "systemctl stop svcname" https://bugzilla.redhat.com/show_bug.cgi?id=714525 nobody would expect this and even if someone knows about this is nothing which makes usabilitöy better lennart please think about such inputs and try to implement logic that your tool does what admins normally expect according to my bugreport (yes the topic was wrong because unexpected bahvior) "systemctl stop mysqld.service" should implicitly always stop an according "svcname.socket" as long we do not restart - STOP means STOP and not restart :-) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong? -> wrong order
Am 11.07.2011 04:51, schrieb Matthew Garrett: >> I truly truly truly hope so... but at the end of the day... I >> simply can't allow a new, untested (in a business environment) >> package destabilize a technology that is used by a large number >> of our community... > > If it's impossible to make NFS work sensibly with systemd then obviously > we'd revert it. But I don't believe that that's the case, and nothing > you've said in this thread has changed my mind there. It's clearly > possible to get NFS working. The question is whether it's possible to do > so in a way that matches your expectations of how users want NFS to > behave, and that's not an issue that results in any destabalisation my main critic on systemd shipped als default with F15 is that widely used services like NFS are not converted to systemd BEFORE systemd replaced upstart the acceptance and bugfree-state could have been MUCH better if all services would be converted before the switch because in this case probably some improvements would have been done on systemd side what happended was: * systemd is pushed * most services are not converted * many services have open questions how to go forward with systemd * what do if some services CAN NOT be converted fully? this is simply bad on every point of view and point 4 would be a reason to improve systemd as it is intended to replace SysV/LSB-services and "in systemd world" is not a good argument if things are not working properly signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
Michal Schmidt redhat.com> writes: > ... > > 1. > > > > main-service-1.service: > > [Unit] > > Description=Main service 1 > > Requires= ... sub-service-1.service sub-service-2.service > > After= ... sub-service-1.service sub-service-2.service > > ... > > [Service] > > Type=forking<-- any other type too ? > > ExecStartPre= > > ExecStartPre= > > ExecStart= > > ExecStart= /usr/sbin/some-service > > Nitpick: You can have only one ExecStart= in a forking unit. Only > oneshot units can have more. > > > ExecStartPost= > > ExecStartPost= > > ... > > > sub-service-1.service: > > [Unit] > > Description=Sub service 1 > > ... > > [Service] > > ... > > > > sub-service-2.service: > > [Unit] > > Description=Sub service 2 > > ... > > [Service] > > ... > > First, sub-service-1.service and sub-service-2.service will be started > in parallel. When they're running, main-service-1.service will be > started by processing its ExecStart* commands sequentially. > ... OK. Q: The sub-service-1.service and sub-service-2.service will be run as stand- alone processes (of whatever kind they are: daemon, master/slave, multithreaded), with no back references or dependecies of any kind (parent-child like, shared resources, etc) to main-service-1.service ? > > 2. > > > > main-service-2.service: > > [Unit] > > Description=Main service 2 > > After= ... > > ... > > [Service] > > Type=forking<-- any other type too ? > > ExecStartPre= sub-service-1.service > > ExecStartPre= sub-service-2.service > > This is incorrect. ExecStartPre= expects a command to run, not a unit > name. > OK. Yes, I goofed here ... I meant some executable ... Let me repeat example 2: 2. main-service-2.service: [Unit] Description=Main service 2 After= ... ... [Service] Type=forking<-- any other type too ? ExecStartPre= exec /etc/init.d/sub-service-1 ExecStartPre= exec /etc/init.d/sub-service-2 ExecStart= /usr/sbin/some-service ExecStartPost= ExecStartPost= ... Would the above be correct setup-wise ? Are there any restrictions on those Pre (and Post) commands ? > > What if sysadmin wants to execute them in parallel because she knows > > they can be executed this way (no conflict and no races) ? > > How, if by definition, systemd executes them sequentially only ? > > Can they be grouped and execution-parallelized in the whole service > > file, or at least in subgroups Pre-, regular, and Post- ? > > Parallelism in systemd happens between multiple units, but never between > ExecStart* commands of one unit. > Requesting parallelism within one unit seems like over-engineering to > me. You can always split your unit to smaller ones if you want > parallelism. But this is what Steve, I believe, wants to do with nfs (to have a bunch of services started from the main one, as under current SysV init system, so his users are not confused by the startup of all these individual service files). > ... > > Can you give us a working example of a services setup (or something > > else) in systemd where execution-parallelism would be present or at > > least theoretically exploitable ? > > Take a look at 'systemd-analyze plot' where you can clearly see > services starting in parallel. Well, I wish I could (I am on F15) ... $ systemd-analyze plot http://www.w3.org/2000/svg"; xmlns:xlink="http://www.w3.org/1999/xlink"; width="1793pt" height="2290pt" viewBox="0 0 1793 2290" version="1.1"> $ $ systemd-analyze plot |less Traceback (most recent call last): File "/usr/bin/systemd-analyze", line 221, in surface.finish() IOError: [Errno 32] Broken pipe $ > This Lennart's blog post has an example: > http://0pointer.de/blog/projects/blame-game.html > > Michal Thanks. JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong? -> wrong order
2011/7/11 Reindl Harald > my main critic on systemd shipped als default with F15 is that > widely used services like NFS are not converted to systemd > BEFORE systemd replaced upstart > Given that Fedora only used upstart with existing SysV scripts, upstart should not have been included in the first place according to that argument. Yet you want to stick with an init system which does not have a single native service, because some services are used through systemd's SysV compatibility? Sorry, but that's hardly a credible position, it just makes you look biased against systemd. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, Jul 11, 2011 at 08:55:40AM +0200, Andreas Schwab wrote: > Matthew Garrett writes: > > > These scripts don't sanitise input beforehand. What happens if I'm > > logged in as root, change IFS and then do /etc/init.d/nfs restart? > > Nothing, because the shell always sets IFS to the default on startup. Yes, that does turn out to be a spectacularly poor example. Sorry! -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Inline-Files-0.67.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Inline-Files: 938c737763522461bcb810cd9bd2a592 Inline-Files-0.67.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Inline-Files] 0.67 bump
commit 45366feac4e30822dcf2729135c6cf51c504a335
Author: Petr Sabata
Date: Mon Jul 11 13:47:35 2011 +0200
0.67 bump
.gitignore |1 +
perl-Inline-Files.spec |7 ++-
sources|2 +-
3 files changed, 8 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 99c8e3a..c54f53b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
Inline-Files-0.63.tar.gz
/Inline-Files-0.64.tar.gz
/Inline-Files-0.65.tar.gz
+/Inline-Files-0.67.tar.gz
diff --git a/perl-Inline-Files.spec b/perl-Inline-Files.spec
index 6f9a6ef..ed6baff 100644
--- a/perl-Inline-Files.spec
+++ b/perl-Inline-Files.spec
@@ -1,5 +1,5 @@
Name: perl-Inline-Files
-Version:0.65
+Version:0.67
Release:1%{?dist}
Summary:Allows for multiple inline files in a single perl file
Group: Development/Libraries
@@ -10,8 +10,10 @@ BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
# Tests only:
BuildRequires: perl(Cwd)
+BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Filter::Util::Call)
BuildRequires: perl(Test)
+Requires: perl(Data::Dumper)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
%description
@@ -43,6 +45,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Mon Jul 11 2011 Petr Sabata - 0.67-1
+- 0.67 bump
+
* Mon Jun 20 2011 Petr Pisar - 0.65-1
- 0.65 bump
- Remove defattr
diff --git a/sources b/sources
index 333c3bb..0cd5dbd 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-acfa698148411c3f6bf4db87466863a3 Inline-Files-0.65.tar.gz
+938c737763522461bcb810cd9bd2a592 Inline-Files-0.67.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: systemd: Is it wrong?
On 07/11/2011 01:08 PM, JB wrote: > Michal Schmidt redhat.com> writes: >> First, sub-service-1.service and sub-service-2.service will be started >> in parallel. When they're running, main-service-1.service will be >> started by processing its ExecStart* commands sequentially. >> ... > > OK. > Q: The sub-service-1.service and sub-service-2.service will be run as stand- > alone processes (of whatever kind they are: daemon, master/slave, > multithreaded), Yes. > with no back references or dependecies of any kind > (parent-child like, shared resources, etc) to main-service-1.service ? There is no parent-child relationship between services. The parent of all services is systemd (PID 1). Services do not spawn other services directly. Only systemd spawns services. About "dependencies of any kind": In the example there are requirement and ordering dependencies between main-service-1.service and the sub-services (that's what Requires= and After= directives specify). systemd maintains the graph of these dependencies in its data structures. > 2. > main-service-2.service: > [Unit] > Description=Main service 2 > After= ... > ... > [Service] > Type=forking<-- any other type too ? > ExecStartPre= exec /etc/init.d/sub-service-1 > ExecStartPre= exec /etc/init.d/sub-service-2 > ExecStart= /usr/sbin/some-service > ExecStartPost= > ExecStartPost= > ... > > Would the above be correct setup-wise ? Synchronous starting of other services may lead to deadlocks in some cases (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=690177). But even if you avoid the deadlock, this unit file is still horrible. Using systemd's dependency mechanisms (Requires, Wants, After, ...) is definitely cleaner. > Are there any restrictions on those Pre (and Post) commands ? One limitation was already mentioned somewhere in this thread - these commands must not fork off daemons. >> Parallelism in systemd happens between multiple units, but never between >> ExecStart* commands of one unit. >> Requesting parallelism within one unit seems like over-engineering to >> me. You can always split your unit to smaller ones if you want >> parallelism. > > But this is what Steve, I believe, wants to do with nfs (to have a bunch of > services started from the main one, as under current SysV init system, so his > users are not confused by the startup of all these individual service files). I proposed a way to do this cleanly using systemd targets elsewhere in this discussion. >> Take a look at 'systemd-analyze plot' where you can clearly see >> services starting in parallel. > > Well, I wish I could (I am on F15) ... > > $ systemd-analyze plot > [...] Store it to an SVG file and then view it. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110711 changes
Compose started at Mon Jul 11 08:15:32 UTC 2011 Broken deps for x86_64 -- 389-ds-base-1.2.9-0.2.a2.fc16.x86_64 requires libnetsnmp.so.25()(64bit) 389-ds-base-1.2.9-0.2.a2.fc16.x86_64 requires libnetsnmpmibs.so.25()(64bit) 389-ds-base-1.2.9-0.2.a2.fc16.x86_64 requires libnetsnmpagent.so.25()(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 libcamel-1.2.so.26()(64bit) 1:anerley-0.2.14-7.fc16.i686 requires libcamel-1.2.so.26 1:anerley-0.2.14-7.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) 1:anjuta-3.1.2-1.fc16.i686 requires libvala-0.12.so.0 1:anjuta-3.1.2-1.fc16.x86_64 requires libvala-0.12.so.0()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) cpqarrayd-2.3-15.fc15.x86_64 requires libnetsnmp.so.25()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper eclipse-birt-3.7.0-2.fc16.noarch requires eclipse-gef >= 0:3.7.0 eclipse-birt-3.7.0-2.fc16.noarch requires eclipse-emf >= 0:2.7.0 eclipse-birt-3.7.0-2.fc16.noarch requires eclipse-dtp >= 0:1.9.0 ekiga-3.3.0-10.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) evolution-couchdb-0.5.90-2.fc16.x86_64 requires libcamel-provider-1.2.so.26()(64bit) evolution-couchdb-0.5.90-2.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libebook-1.2.so.10()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libcamel-provider-1.2.so.25()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libcamel-1.2.so.25()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libgnome-desktop-3.so.0()(64bit) evolution-sharp-0.21.1-14.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) foghorn-0.1.2-4.fc16.x86_64 requires libnetsnmpmibs.so.25()(64bit) foghorn-0.1.2-4.fc16.x86_64 requires libnetsnmp.so.25()(64bit) foghorn-0.1.2-4.fc16.x86_64 requires libnetsnmpagent.so.25()(64bit) gdb-heap-0.5-5.fc16.x86_64 requires glibc(x86-64) = 0:2.13.90 gedit-valencia-0.3.0-6.20110701git808152718e3ab.fc16.x86_64 requires libvala-0.12.so.0()(64bit) ghc-hinotify-0.3.1-9.fc16.i686 requires libHSarray-0.3.0.2-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSdirectory-1.1.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSghc-prim-0.2.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSold-time-1.0.0.6-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSold-locale-1.0.0.2-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSunix-2.4.2.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSfilepath-1.2.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSbase-4.3.1.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSinteger-gmp-0.2.0.3-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHScontainers-0.4.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSghc-prim-0.2.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSold-time-1.0.0.6-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSbase-4.3.1.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSinteger-gmp-0.2.0.3-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSold-locale-1.0.0.2-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 req
Re: systemd: Is it wrong?
On 07/11/2011 10:46 AM, Reindl Harald wrote: > the same problem with the logic "if there is a svcname.socket" > you have to do "systemctl stop svcname.socket svcname.service" > or systemd wil fire up it again if you do only > "systemctl stop svcname" > > https://bugzilla.redhat.com/show_bug.cgi?id=714525 > > nobody would expect this and even if someone knows about > this is nothing which makes usabilitöy better > > lennart please think about such inputs and try to implement > logic that your tool does what admins normally expect > > according to my bugreport (yes the topic was wrong because > unexpected bahvior) "systemctl stop mysqld.service" should > implicitly always stop an according "svcname.socket" as long > we do not restart - STOP means STOP and not restart :-) 'systemctl stop ...' means: stop the currently running instance. Nothing more. It says nothing about what should or should not happen in the future. Socket activation is a future event. Usind 'BindTo=' it may be possible to stop the socket when the service is stopped. I have not tried it. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
Once upon a time, drago01 said: > Do you configure your webbrowser by passing command line arguments > and/or editing its source code? As a matter of fact, I do use command line arguments to my web browser. I have several different Firefox profiles set up (regular use, web dev, clean for testing, etc.), so I modify the normal icon to add "-no-remote -P regular". I then start the others as needed from a command line (changing "regular" to "dev" or "clean"). Anyway, comparing GUI applications to system daemons is not a valid comparison. GUI apps are generally designed to be started with a click, not a command line. System daemons are generally designed to be started from a script (since that's the way they've been started since day 1). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
Michal Schmidt redhat.com> writes: > ... > > 2. > > main-service-2.service: > > [Unit] > > Description=Main service 2 > > After= ... > > ... > > [Service] > > Type=forking<-- any other type too ? > > ExecStartPre= exec /etc/init.d/sub-service-1 > > ExecStartPre= exec /etc/init.d/sub-service-2 > > ExecStart= /usr/sbin/some-service > > ExecStartPost= > > ExecStartPost= > > ... > > Are there any restrictions on those Pre (and Post) commands ? > > One limitation was already mentioned somewhere in this thread - these > commands must not fork off daemons. This is interesting. Or perhaps I read too much into your above statement ? We know already that ExecStartPre must contain a command to be executed. > > ExecStartPre= exec /etc/init.d/sub-service-1 Note the 'exec' command, which means "Replace the shell with the given command." with immediate return. How does systemd know what's in the "/etc/init.d/sub-service-1" process, to be able to figure out if any daemon is to be forked off ? > ... > >> Parallelism in systemd happens between multiple units, but never between > >> ExecStart* commands of one unit. > >> Requesting parallelism within one unit seems like over-engineering to > >> me. You can always split your unit to smaller ones if you want > >> parallelism. > > > > But this is what Steve, I believe, wants to do with nfs (to have a bunch of > > services started from the main one, as under current SysV init system, so > > his users are not confused by the startup of all these individual service > > files). > > I proposed a way to do this cleanly using systemd targets elsewhere in > this discussion. Or my example 1 would serve him too ? > ... JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File threads-tbb-0.04.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-threads-tbb: a40f2b1fe5e0d463acdf6256fb184165 threads-tbb-0.04.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: systemd: Is it wrong?
On 07/11/2011 02:56 PM, JB wrote: >>> ExecStartPre= exec /etc/init.d/sub-service-1 > Note the 'exec' command, which means "Replace the shell with the given > command." with immediate return. > How does systemd know what's in the "/etc/init.d/sub-service-1" process, to be > able to figure out if any daemon is to be forked off ? Of course it does not know that beforehand. It just hates it when it happens. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Sun, 10.07.11 20:49, Steve Dickson (ste...@redhat.com) wrote: > >> So basically what you are saying is a service can never consist of > >> more than one system daemon. > > > > Well, it can, but we encourage you not to do this. > > > > The word "service" is mostly used synonymously with "daemon" in the > > systemd context, and we prefer if people write one service file for each > > daemon, as this is the easiest to understand for admins and users and > > makes sure supervision/monitoring works properly. > > Ok.. Now understand where my confusion is... Currently when one > want to start the nfs server they type 'service nfs start' which > calls a number of binaries and ultimately a system daemon. > > Now if they enable want secure nfs, they edit a file in /etc/systconf > and simply type 'service nfs restart' which again runs a number > of binaries and start a couple of system daemons. > > My point it this. You are changing the meaning of 'service'. People > expect a service to be just that as service. When one starts a > service all the needed daemons are started and all the configuration > is done once the service is started. I think most people actually expected that one service file would start one service. > Unless I'm misunderstanding, for an admin to the same thing as above > the will have to type of string of commands enabling all the needed > daemons... People are not expecting or even what to know which daemon > is need to start up each service... oops.. a service is not longer > as service its a daemon... hmm... let use subsystem... see my point? No I don't. Note that you can have dependencies between services: you can say that when service A is started service B must be started too and finished before A. These are *runtime* dependencies. You can also say that when A is enabled B should be enabled too. These are *install time* dependencies. The former are suppoirted via Wants= and Requires= in the [Unit] section, then latter in via Also= in the [Install] section of unit files. > >> Maybe a better way to says is ExecStartPre= should not be used for > >> daemon process? > > > > Well, technically, not only daemon processes do this, but that's > > nitpicking, so let's not discuss this part further. > Right.. Not only daemon processes spawn off processes that fork and stay in > the > background. How are we suppose to know if he flux capacitor command will or > will leave a process background? Hopefully the folks writing a unit file know the software they are writing it for. It is our intention after all to get these unit files shipped upstream, i.e. they are written by the upstream developers. > > Simplify things, have as many levels of disabling as necessary but as > > few as possible, and unify that across the different services. This is > > what we want to ensure by getting people to use "systemctl enable" > > instead of having service-specific sysconfig files for > > disabling/enabling services. > > Hang on... you say that 'systemctl enable' will also configure a daemon > like the sysconfig files do? Could you please give me an example of this > this? No, this is about enabling/disabling daemons. systemctl enable/disable is not about configuring arbitrary parameters to daemons. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong? -> wrong order
On Mon, 11.07.11 10:57, Reindl Harald (h.rei...@thelounge.net) wrote: > Am 11.07.2011 04:51, schrieb Matthew Garrett: > > >> I truly truly truly hope so... but at the end of the day... I > >> simply can't allow a new, untested (in a business environment) > >> package destabilize a technology that is used by a large number > >> of our community... > > > > If it's impossible to make NFS work sensibly with systemd then obviously > > we'd revert it. But I don't believe that that's the case, and nothing > > you've said in this thread has changed my mind there. It's clearly > > possible to get NFS working. The question is whether it's possible to do > > so in a way that matches your expectations of how users want NFS to > > behave, and that's not an issue that results in any destabalisation > > my main critic on systemd shipped als default with F15 is that > widely used services like NFS are not converted to systemd > BEFORE systemd replaced upstart It's a bit of a chicken of egg problem. I actually sent patches which cleaned up part of the NFS stuff to Steve (for example, socket activation patches for rpcbind), but he declined to apply them. With those patches at least some of the complexity would go away, as rpcbind would simply be available, and started as soon as it is needed, copying what MacOS has been doing in the area of NFS for a while. If systemd isn't in, people won't wake up, it's that easy. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks))
CC'ing devel -- Wiadomość przekazana dalej -- Od: Michał Piotrowski Data: 9 lipca 2011 10:59 Temat: Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks)) Do: Michal Hlavinka W dniu 9 lipca 2011 10:29 użytkownik Michał Piotrowski napisał: > Hi, > > W dniu 8 lipca 2011 20:08 użytkownik Michal Hlavinka > napisał: >> Hi, >> >> please check if this package changes anything for you: >> >> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3187528/ > > unfortunately there is no difference I'm attaching valgrind output. I checked your patch and it removes correctly all uses of memcpy so it seems that memcpy only covered the root of the problem. > >> >> thanks >> >> On Friday 08 of July 2011 18:32:55 you wrote: >>> W dniu 8 lipca 2011 18:21 użytkownik Michał Piotrowski >>> >>> napisał: >>> > Hi, >>> > >>> > 2011/7/8 Andreas Schwab : >>> >> Use valgrind. >>> > >>> > I attach valgrind output. >>> > >>> > ==1312== 1 errors in context 1 of 116: >>> > ==1312== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, >>> > 76) ==1312== at 0x4C283B6: memcpy@@GLIBC_2.14 >>> > (mc_replace_strmem.c:653) ==1312== by 0x401835: ??? (in >>> > /sbin/mount.ecryptfs) >>> > ==1312== by 0x5E3039C: (below main) (in /lib64/libc-2.14.so) >>> >>> I installed ecryptfs-utils-debuginfo package and now it's more readable >>> >>> ==1815== 1 errors in context 1 of 116: >>> ==1815== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, 76) >>> ==1815== at 0x4C283B6: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:653) >>> ==1815== by 0x401835: main (string3.h:52) >>> >>> > Could this be related to >>> > - Fix static linking with checking x86/x86-64 memcpy (BZ#12653) >>> > or is it an eCryptfs problem? >>> > >>> >> 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 >>> > >>> > -- >>> > Best regards, >>> > Michal >>> > >>> > http://eventhorizon.pl/ >> > > > > -- > Best regards, > Michal > > http://eventhorizon.pl/ > valgrind.bad2.txt.bz2 Description: BZip2 compressed data -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Sun, 10.07.11 23:14, Steve Dickson (ste...@redhat.com) wrote: > On 07/10/2011 10:58 PM, Garry T. Williams wrote: > > On Sunday, July 10, 2011 22:40:51 Steve Dickson wrote: > >> So did that "elaborate process of acceptance" include the Fedora > >> community or maybe the Linux community or possibly the Business > >> community. > > > > You seem to be very late to the party. > Good call.. Unfortunately I live in multiple worlds > and yes I have most definitely came to this party > late... So are we out of beer? 8-) You have been invited to the party a couple of times btw. For example I sent you those rpcbind patches which you declined to merge. You have been made aware of these changes in advance, and I did some of the conversion work for you even. You cannot really claim that this all was too fast and nobody told you. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, 2011-07-11 at 01:21 +0200, Lennart Poettering wrote: > Our documentation is really good and relatively comprehensive (as > many people will happily acknowledge I am sure). I'm acknowledging that. However that's also perhaps its weak point: the systemd documentation is too comprehensive (is that even possible? :) I had no idea where to find what I was looking for at first, so I had to read it entirely. It took me an afternoon (good thing my work involves understanding systemd), but now that I did, I have enough understanding of how it vaguely works to know that if I'm searching for "foo", it will be in page "bar". If you could just add a simple search engine on those man pages, I'm sure lots of people would be really happy. :) -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, Jul 11, 2011 at 3:58 PM, Lennart Poettering wrote: > On Sun, 10.07.11 20:49, Steve Dickson (ste...@redhat.com) wrote: >> > The word "service" is mostly used synonymously with "daemon" in the >> > systemd context, and we prefer if people write one service file for each >> > daemon, as this is the easiest to understand for admins and users and >> > makes sure supervision/monitoring works properly. >> >> Ok.. Now understand where my confusion is... Currently when one >> want to start the nfs server they type 'service nfs start' which >> calls a number of binaries and ultimately a system daemon. >> >> Now if they enable want secure nfs, they edit a file in /etc/systconf >> and simply type 'service nfs restart' which again runs a number >> of binaries and start a couple of system daemons. >> >> My point it this. You are changing the meaning of 'service'. People >> expect a service to be just that as service. When one starts a >> service all the needed daemons are started and all the configuration >> is done once the service is started. > > I think most people actually expected that one service file would start > one service. I think most "people" do not equate "service" with a process; "service" is a _service_ being provided - it may be atd with one process (service is "makes at(1) work"), httpd with 10 similar children (service is "answers on port 80"), mailman with 5 or so different interoperating processes (service is "runs mailing lists"). At least as long as the "service" works, nobody really cares about the processes. If you will, "service" is "a product that could be bought and installed". Just follow the use cases: - Install, configure and start mailman - Set up mailman so that it starts at boot - A huge security hole has been reported in mailman, take mailman down immediately - My mailing lists don't work, what's the status of mailman? Is mailman running? Did mailman report an error? In every single one of these use cases the sysadmin wants to treat "mailman" as a single unit, not as five different units (I bet most mailman sysadmins couldn't even list names of the processes). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, 11.07.11 16:32, Miloslav Trmač (m...@volny.cz) wrote: > > On Mon, Jul 11, 2011 at 3:58 PM, Lennart Poettering > wrote: > > On Sun, 10.07.11 20:49, Steve Dickson (ste...@redhat.com) wrote: > >> > The word "service" is mostly used synonymously with "daemon" in the > >> > systemd context, and we prefer if people write one service file for each > >> > daemon, as this is the easiest to understand for admins and users and > >> > makes sure supervision/monitoring works properly. > >> > >> Ok.. Now understand where my confusion is... Currently when one > >> want to start the nfs server they type 'service nfs start' which > >> calls a number of binaries and ultimately a system daemon. > >> > >> Now if they enable want secure nfs, they edit a file in /etc/systconf > >> and simply type 'service nfs restart' which again runs a number > >> of binaries and start a couple of system daemons. > >> > >> My point it this. You are changing the meaning of 'service'. People > >> expect a service to be just that as service. When one starts a > >> service all the needed daemons are started and all the configuration > >> is done once the service is started. > > > > I think most people actually expected that one service file would start > > one service. > > I think most "people" do not equate "service" with a process; Neither does systemd. A service/daemon can consist of multiple processes. Examples for this are Apache (main + worker processes + cgi scripts), Avahi (main + chroot helper process), udev (main + worker processes + callouts), and a lot of other stuff. In systemd "daemon" is synonymous to "service". And a daemon/service can consist of multiple processes, but one of those is the main one, which defines the runtime (and traditionally is the one whose PID was stored in the PID file). If that one exits/crashes we consider the service down, and optionally will restart it. Steve otoh wants one service to consist of multiple daemons, each of which can consist of multiple processes. I find that unnecessarily complex and this is not implemented in system, and have pointed out a number of times why. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for today's FESCo meeting (2011-7-11)
(Apologies for short notice, for some reason I wasn't thinking about Fedora on the weekend.) Following is the list of topics that will be discussed in the FESCo meeting today at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #NNN Title of ticket .fesco NNN #topic #563 suggested policy: all daemons must set RELRO and PIE flags .fesco 563 #topic #614 Proposed list of packages to drop due to FTBFS prior to F16 branching .fesco 614 #topic #615 Strategy for services that do not have systemd native unit files .fesco 615 #topic #531 Orphaned package ownership claiming clarification .fesco 531 = New business = #topic #608 F16Feature: Trusted Boot - http://fedoraproject.org/wiki/Features/Trusted_Boot .fesco 608 #618 F16Feature: pacemaker-cloud - https://fedoraproject.org/wiki/Features/pacemaker-cloud .fesco 618 #619 F16 Feature: Matahari -- https://fedoraproject.org/wiki/Features/Matahari .fesco 619 #620 F16Feature: Virtual Machine Lock Manager - https://fedoraproject.org/wiki/Features/VirtLockManager .fesco 620 #621 F16 Feature: GNOME 3.2 - https://fedoraproject.org/wiki/Features/Gnome3.2 .fesco 621 #622 F16Feature: KDE Plasma Workspaces 4.7 - https://fedoraproject.org/wiki/Features/KDE47 .fesco 622 #623 F16Feature: KDE Plasma Desktop by default - https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default .fesco 623 #624 F16Feature: Virt Networking Enhancements - https://fedoraproject.org/wiki/Features/VirtNetworkingEnhancements .fesco 624 #625 F16Feature: USB Network Redirection - https://fedoraproject.org/wiki/Features/UsbNetworkRedirection .fesco 625 #626 F16Feature: firewalld as default Fedora firewall solution - https://fedoraproject.org/wiki/Features/firewalld-default .fesco 626 #627 F16 Feature: network zones -- https://fedoraproject.org/wiki/Features/network-zones .fesco 627 #628 F16Feature: VirtSandbox -- https://fedoraproject.org/wiki/Features/VirtSandbox .fesco 628 #629 F16Feature: Virt-manager Guest Inspection - https://fedoraproject.org/wiki/Features/Virt-manager_Guest_Inspection .fesco 629 #630 F16Feature: SELinux File Name Transition - https://fedoraproject.org/wiki/Features/SELinuxFileNameTransition .fesco 630 #631 F16Feature: TigerVNC 1.1 - http://fedoraproject.org/wiki/Features/TigerVNC1.1 .fesco 631 #632 F16Feature: Grub2 - https://fedoraproject.org/wiki/Features/Grub2 .fesco 632 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Deprecating portreserve
The BMC thing sounds a bit more special-purpose than portreserve, and presumably could be done in its own package that could perhaps be installed as needed depending on the hardware. So is the next step to deprecate portreserve? What actually needs to be done for that to happen? Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks))
W dniu 8 lipca 2011 18:21 użytkownik Michał Piotrowski napisał: > Hi, > > 2011/7/8 Andreas Schwab: >> Use valgrind. > > I attach valgrind output. > > ==1312== 1 errors in context 1 of 116: > ==1312== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, > 76) ==1312==at 0x4C283B6: memcpy@@GLIBC_2.14 > (mc_replace_strmem.c:653) ==1312==by 0x401835: ??? (in > /sbin/mount.ecryptfs) > ==1312==by 0x5E3039C: (below main) (in /lib64/libc-2.14.so) I installed ecryptfs-utils-debuginfo package and now it's more readable ==1815== 1 errors in context 1 of 116: ==1815== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, 76) ==1815==at 0x4C283B6: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:653) ==1815==by 0x401835: main (string3.h:52) > Could this be related to > - Fix static linking with checking x86/x86-64 memcpy (BZ#12653) > or is it an eCryptfs problem? >> W dniu 8 lipca 2011 20:08 użytkownik Michal Hlavinka >> napisał: >>> Hi, >>> >>> please check if this package changes anything for you: >>> >>> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3187528/ >> >> unfortunately there is no difference > > I'm attaching valgrind output. I checked your patch and it removes > correctly all uses of memcpy so it seems that memcpy only covered the > root of the problem. ok, complain about memcpy in ecryptfs-utils is gone. I've checked all of them and I think I've fixed those which needed it. I was not able to reproduce original problem nor valgrind complaint, so please test if following package produces memcpy complain in valgrind output or not: http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/ Anyway, I don't think there is any problem in ecryptfs-utils, because it's just mount helper. It's not running when files are being encrypted/decrypted and you said it works fine when you use ecryptfs directly (without samba). We've fixed memcpy bug in ecryptfs which is definitely a good think, but problem is elsewhere. If you want, you can test following build of samba which has all occurrences of memcpy replaced by memmove. I don't dare to guess if it changes anything, but give it a try if you want: http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190918/ Could you describe your environment in more details so we can try to reproduce it? For example what ecryptfs options you use (including fstab line if you have any), samba configuration etc... Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks))
Hi, W dniu 11 lipca 2011 17:09 użytkownik Michal Hlavinka napisał: > ok, complain about memcpy in ecryptfs-utils is gone. I've checked all of > them and I think I've fixed those which needed it. I was not able to > reproduce original problem nor valgrind complaint, so please test if > following package produces memcpy complain in valgrind output or not: > > http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/ Your mtab handling patch fixed both issues - mount warning and data corruption :) Huge thanks! > > Anyway, I don't think there is any problem in ecryptfs-utils, because it's > just mount helper. It's not running when files are being encrypted/decrypted > and you said it works fine when you use ecryptfs directly (without samba). > We've fixed memcpy bug in ecryptfs which is definitely a good think, but > problem is elsewhere. > > If you want, you can test following build of samba which has all occurrences > of memcpy replaced by memmove. I don't dare to guess if it changes anything, > but give it a try if you want: > > http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190918/ > > Could you describe your environment in more details so we can try to > reproduce it? For example what ecryptfs options you use (including fstab > line if you have any), samba configuration etc... I do not think that it had any significance - it seems to me that these options are pretty standard mount -t ecryptfs /home/$SHARE/ /home/$SHARE/ -o key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_fnek_sig=some_value It's a little strange that you could not reproduce that mount warning. > > Michal > > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Deprecating portreserve
On 07/11/2011 03:08 PM, Tim Waugh wrote: > The BMC thing sounds a bit more special-purpose than portreserve, and > presumably could be done in its own package that could perhaps be > installed as needed depending on the hardware. > > So is the next step to deprecate portreserve? What actually needs to be > done for that to happen? > I guess figure out what requires portreserve and ping those ? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks))
On 07/11/2011 05:40 PM, Michał Piotrowski wrote: > Hi, > > W dniu 11 lipca 2011 17:09 użytkownik Michal Hlavinka > napisał: >> ok, complain about memcpy in ecryptfs-utils is gone. I've checked all of >> them and I think I've fixed those which needed it. I was not able to >> reproduce original problem nor valgrind complaint, so please test if >> following package produces memcpy complain in valgrind output or not: >> >> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/ > > Your mtab handling patch fixed both issues - mount warning and data > corruption :) Huge thanks! I can't imagine *how* it could affect this, so I'd advice to monitor it carefully if it is fixed for real. Btw, there is not only mtab patch, but 2x memcpy -> memmove too, just not all of them as in previous test package (which did not help). >> Could you describe your environment in more details so we can try to >> reproduce it? For example what ecryptfs options you use (including fstab >> line if you have any), samba configuration etc... > > I do not think that it had any significance - it seems to me that > these options are pretty standard > mount -t ecryptfs /home/$SHARE/ /home/$SHARE/ -o > key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_fnek_sig=some_value > > It's a little strange that you could not reproduce that mount warning. AFAIK that memcpy warning from valgrind gets triggered only if you use "correct" -o ... option -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 462254] Review Request: perl-Catalyst-Plugin-Session-Store-FastMmap - FastMmap session storage backend
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=462254 Iain Arnell changed: What|Removed |Added Flag|fedora-cvs+ |fedora-cvs? --- Comment #12 from Iain Arnell 2011-07-11 11:54:36 EDT --- Package Change Request == Package Name: perl-Catalyst-Plugin-Session-Store-FastMmap New Branches: el6 Owners: iarnell -- 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: systemd: Is it wrong? -> wrong order
On 07/11/2011 10:03 AM, Lennart Poettering wrote: > On Mon, 11.07.11 10:57, Reindl Harald (h.rei...@thelounge.net) wrote: > >> Am 11.07.2011 04:51, schrieb Matthew Garrett: >> I truly truly truly hope so... but at the end of the day... I simply can't allow a new, untested (in a business environment) package destabilize a technology that is used by a large number of our community... >>> >>> If it's impossible to make NFS work sensibly with systemd then obviously >>> we'd revert it. But I don't believe that that's the case, and nothing >>> you've said in this thread has changed my mind there. It's clearly >>> possible to get NFS working. The question is whether it's possible to do >>> so in a way that matches your expectations of how users want NFS to >>> behave, and that's not an issue that results in any destabalisation >> >> my main critic on systemd shipped als default with F15 is that >> widely used services like NFS are not converted to systemd >> BEFORE systemd replaced upstart > > It's a bit of a chicken of egg problem. > > I actually sent patches which cleaned up part of the NFS stuff to Steve > (for example, socket activation patches for rpcbind), but he declined to > apply them. No. The community rejected them because * They were to evasive which made the code unmaintainable esp WRT to security fixes. * You rejected the idea of put the code in a standalone library. * They were too Fedora specific * Code stability was also a concern Here is the thread: http://marc.info/?t=12795066321&r=1&w=2 steved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 462254] Review Request: perl-Catalyst-Plugin-Session-Store-FastMmap - FastMmap session storage backend
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=462254 --- Comment #13 from Jon Ciesla 2011-07-11 12:01:17 EDT --- Git done (by process-git-requests). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks))
W dniu 11 lipca 2011 17:57 użytkownik Michal Hlavinka napisał: > On 07/11/2011 05:40 PM, Michał Piotrowski wrote: >> >> Hi, >> >> W dniu 11 lipca 2011 17:09 użytkownik Michal Hlavinka >> napisał: >>> >>> ok, complain about memcpy in ecryptfs-utils is gone. I've checked all of >>> them and I think I've fixed those which needed it. I was not able to >>> reproduce original problem nor valgrind complaint, so please test if >>> following package produces memcpy complain in valgrind output or not: >>> >>> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/ >> >> Your mtab handling patch fixed both issues - mount warning and data >> corruption :) Huge thanks! > > I can't imagine *how* it could affect this, so I'd advice to monitor it > carefully if it is fixed for real. Ok, so I will do. Before each time I mounted ecryptfs I get this "Error mounting eCryptfs: [-5] Input/output error" error. Now it's gone - I tried a few times. > Btw, there is not only mtab patch, but 2x > memcpy -> memmove too, just not all of them as in previous test package > (which did not help). > >>> Could you describe your environment in more details so we can try to >>> reproduce it? For example what ecryptfs options you use (including fstab >>> line if you have any), samba configuration etc... >> >> I do not think that it had any significance - it seems to me that >> these options are pretty standard >> mount -t ecryptfs /home/$SHARE/ /home/$SHARE/ -o >> >> key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_fnek_sig=some_value >> >> It's a little strange that you could not reproduce that mount warning. > > AFAIK that memcpy warning from valgrind gets triggered only if you use > "correct" -o ... option > > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/11/2011 10:44 AM, Lennart Poettering wrote: > On Mon, 11.07.11 16:32, Miloslav Trmač (m...@volny.cz) wrote: > Steve otoh wants one service to consist of multiple daemons, each of > which can consist of multiple processes. I find that unnecessarily > complex and this is not implemented in system, and have pointed out a > number of times why. Too complexed for your code, not system admins. That's exactly what they want. One command that starts multiple process/daemons of a particular service. It as simple as that. steved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong? -> wrong order
On Mon, 11.07.11 12:02, Steve Dickson (ste...@redhat.com) wrote: > > > > On 07/11/2011 10:03 AM, Lennart Poettering wrote: > > On Mon, 11.07.11 10:57, Reindl Harald (h.rei...@thelounge.net) wrote: > > > >> Am 11.07.2011 04:51, schrieb Matthew Garrett: > >> > I truly truly truly hope so... but at the end of the day... I > simply can't allow a new, untested (in a business environment) > package destabilize a technology that is used by a large number > of our community... > >>> > >>> If it's impossible to make NFS work sensibly with systemd then obviously > >>> we'd revert it. But I don't believe that that's the case, and nothing > >>> you've said in this thread has changed my mind there. It's clearly > >>> possible to get NFS working. The question is whether it's possible to do > >>> so in a way that matches your expectations of how users want NFS to > >>> behave, and that's not an issue that results in any destabalisation > >> > >> my main critic on systemd shipped als default with F15 is that > >> widely used services like NFS are not converted to systemd > >> BEFORE systemd replaced upstart > > > > It's a bit of a chicken of egg problem. > > > > I actually sent patches which cleaned up part of the NFS stuff to Steve > > (for example, socket activation patches for rpcbind), but he declined to > > apply them. > No. The community rejected them because Nope, you did. In a personal mail on Wed 11 Aug 2010. But really, this is a pointless game... >* They were to evasive which made the code unmaintainable esp > WRT to security fixes. Uh? It's an addition of 30 lines of very simple code. In fact if it had been merged it probably would have been the simplest code in all of the NFS stack. >* They were too Fedora specific systemd is not a fedora-only project. It is available in a number of other distributions, in a number of them default, and will be the default in opensuse too, in the next release. >* Code stability was also a concern Really, for 30 lines of code? And where have these been expressed? I take it if I update the patch and repost it this would not change your minds and would be rejected again? A pity, Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, 11.07.11 12:15, Steve Dickson (ste...@redhat.com) wrote: > On 07/11/2011 10:44 AM, Lennart Poettering wrote: > > On Mon, 11.07.11 16:32, Miloslav Trmač (m...@volny.cz) wrote: > > Steve otoh wants one service to consist of multiple daemons, each of > > which can consist of multiple processes. I find that unnecessarily > > complex and this is not implemented in system, and have pointed out a > > number of times why. > > Too complexed for your code, not system admins. That's exactly what > they want. You have as little idea of what "exactly" sys admins want as I do. Or maybe I have a tiny bit of more of an idea, because I actually get all the feedback, and I go to all the conferences, and I know what's going on and I don't live under a rock. > One command that starts multiple process/daemons of a particular service. > It as simple as that. I guess we have to agree to disagree on this. A lost chance for NFS, Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, Jul 11, 2011 at 12:15:25PM -0400, Steve Dickson wrote: > > > On 07/11/2011 10:44 AM, Lennart Poettering wrote: > > On Mon, 11.07.11 16:32, Miloslav Trmač (m...@volny.cz) wrote: > > Steve otoh wants one service to consist of multiple daemons, each of > > which can consist of multiple processes. I find that unnecessarily > > complex and this is not implemented in system, and have pointed out a > > number of times why. > Too complexed for your code, not system admins. That's exactly what they want. > > One command that starts multiple process/daemons of a particular service. > It as simple as that. Wasn't it suggested that that could be obtained by having one service per daemon plus another generic NFS service that depends on the appropriate other services? What you want appears to be achievable in the systemd way of doing things, just not by putting all of the daemons in a single service file. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, Jul 11, 2011 at 12:18 PM, Lennart Poettering wrote: > I guess we have to agree to disagree on this. There are enough replied to this thread that I think it's time for me to step in here, and ask the thread to please focus on the technical details of how to make NFS work well under systemd. It seems to me that right now, you're both just talking past each other to defend why your think your point of view is the "one" correct point of view in the universe. In my (possibly naive?) view, we're spending too much time trying to tear people down rather than build up the technological answers to the problem at hand. -- Jared Smith Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/11/2011 05:03 AM, "Jóhann B. Guðmundsson" wrote: > On 07/11/2011 02:40 AM, Steve Dickson wrote: >> I truly truly truly hope so... but at the end of the day... I >> simply can't allow a new, untested (in a business environment) >> package destabilize a technology that is used by a large number >> of our community... > > The longer it takes to get a native systemd unit files out there the > more "untested" they will become. True... > > The faster they will be out there the more experience/exposer they will > receive. Acknowledged. > > No rocket science behind that logic some would even go so far as calling > that common knowledge so if you are truly worried about that, convert > those legacy sysv init file and put the native systemd unit file out > there, the sooner the better.. Yes I am very concern systemd will effect how NFS started, shutdown, managed, and configured... Because at the end of the day, when all hell breaks lose, your name will not those bz and your reputation will on the line... > > I think it's time that we hear from you explaining to us how systemd has > brought doom and chaos to the nfs world, how it has destabilize nfs and > left the *major subsystem* not working and it's citizens running for > their lives, committing mass suicide on the side walks and the cities > being overrun by zombies and the nfs world going down in flames... > > What do you say? My concerns are will documented the bz: https://bugzilla.redhat.com/show_bug.cgi?id=699040 But in a nut shell: * There is no way to conditionally start and stop services/daemons using a configuration variable. * There is no way to conditionally start and stop services within as service. * The variables read out of the EnvironmentFile are *always* character strings which means set LOCKD_TCPPORT=234 is no longer possible. Losing that ability to set variable to integer values seem to like a giant step backwards. * Being able to set a number of different config variables that will automatically build a valid command line to a given daemon. Granted, these issues will not effect the stability of the actual daemon code, but they will destroy the "easy-of-use" factor. My admins have to tweak one file and start (or restart) the service and BOOM everything just works... Its a two step process that has mature in time that has become fairly seamless and straightforward. This is what I'm concern that systemd will destroy. steved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, 11.07.11 12:55, Steve Dickson (ste...@redhat.com) wrote: > > > > On 07/11/2011 05:03 AM, "Jóhann B. Guðmundsson" wrote: > > On 07/11/2011 02:40 AM, Steve Dickson wrote: > >> I truly truly truly hope so... but at the end of the day... I > >> simply can't allow a new, untested (in a business environment) > >> package destabilize a technology that is used by a large number > >> of our community... > > > > The longer it takes to get a native systemd unit files out there the > > more "untested" they will become. > True... > > > > The faster they will be out there the more experience/exposer they will > > receive. > Acknowledged. > > > > > No rocket science behind that logic some would even go so far as calling > > that common knowledge so if you are truly worried about that, convert > > those legacy sysv init file and put the native systemd unit file out > > there, the sooner the better.. > Yes I am very concern systemd will effect how NFS started, shutdown, > managed, and configured... Because at the end of the day, when all > hell breaks lose, your name will not those bz and your reputation > will on the line... > > > > > I think it's time that we hear from you explaining to us how systemd has > > brought doom and chaos to the nfs world, how it has destabilize nfs and > > left the *major subsystem* not working and it's citizens running for > > their lives, committing mass suicide on the side walks and the cities > > being overrun by zombies and the nfs world going down in flames... > > > > What do you say? > My concerns are will documented the bz: > https://bugzilla.redhat.com/show_bug.cgi?id=699040 > > But in a nut shell: >* There is no way to conditionally start and stop services/daemons > using a configuration variable. True, and on purpose. >* There is no way to conditionally start and stop services > within as service. Not true. Services can start other services, by queuing a job for that via a D-Bus call (or via systemctl, a wrapper for that). However, I'd avoid doing this. >* The variables read out of the EnvironmentFile are *always* > character strings which means set LOCKD_TCPPORT=234 is > no longer possible. Losing that ability to set variable to > integer values seem to like a giant step backwards. Hmm? Shell only understands strings, too. What precisely are you asking for? >* Being able to set a number of different config variables > that will automatically build a valid command line to a > given daemon. You can do that. Subsituation of env vars is (on purpose) very simple in systemd. If you need a programming language to spawn your service, then use one: shell. > Granted, these issues will not effect the stability of the actual > daemon code, but they will destroy the "easy-of-use" factor. We disagree on that. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Buildroot broken? (iproute)
I can't build for Rawhide today. Here's an example: http://koji.fedoraproject.org/koji/getfile?taskID=3191106&name=root.log Here's an excerpt: DEBUG backend.py:739: ['/usr/bin/yum', '--installroot', '/var/lib/mock/dist-f16-build-1097005-168601/root/', 'groupinstall', 'srpm-build'] DEBUG util.py:284: Executing command: ['/usr/bin/yum', '--installroot', '/var/lib/mock/dist-f16-build-1097005-168601/root/', 'groupinstall', 'srpm-build'] DEBUG util.py:250: Ignored option -c (probably due to merging -yc != -y -c) DEBUG util.py:250: Error: Package: iproute-2.6.39-1.fc16.x86_64 (build) DEBUG util.py:250: Requires: libxtables.so.5()(64bit) DEBUG util.py:250: You could try using --skip-broken to work around the problem DEBUG util.py:250: You could try running: rpm -Va --nofiles --nodigest DEBUG util.py:323: Child returncode was: 1 -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks))
On 07/11/2011 06:05 PM, Michał Piotrowski wrote: > W dniu 11 lipca 2011 17:57 użytkownik Michal Hlavinka > napisał: >> On 07/11/2011 05:40 PM, Michał Piotrowski wrote: >>> >>> Hi, >>> >>> W dniu 11 lipca 2011 17:09 użytkownik Michal Hlavinka >>> napisał: ok, complain about memcpy in ecryptfs-utils is gone. I've checked all of them and I think I've fixed those which needed it. I was not able to reproduce original problem nor valgrind complaint, so please test if following package produces memcpy complain in valgrind output or not: http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/ >>> >>> Your mtab handling patch fixed both issues - mount warning and data >>> corruption :) Huge thanks! >> >> I can't imagine *how* it could affect this, so I'd advice to monitor it >> carefully if it is fixed for real. > > Ok, so I will do. Before each time I mounted ecryptfs I get this > "Error mounting eCryptfs: [-5] Input/output error" error. Now it's > gone - I tried a few times. yes, this is related to mtab patch, but it mounted it anyway. I was able to reproduce this warning. It should not affect smb+ecryptfs data corruption in any way. Btw, did you test if this version works in valgrind or not? (the "Source and destination overlap in memcpy" warning). btw, we should move this conversation off list if it's related only to ecryptfs. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
AutoQA Downtime Starting 2011-07-11 20:00 UTC
AutoQA will be affected by the infrastructure changes announced last week [1]. During the outage, AutoQA tests will not be run and feedback will not be posted to Bodhi. At this point, we are expecting the outage to last at least a day while the systems are re-racked and we reconfigure AutoQA for these changes. We will update this thread as we get closer to bringing things back online. If you have any AutoQA specific questions about the outage, please contact us on the AutoQA devel list [2]. [1] http://lists.fedoraproject.org/pipermail/devel/2011-July/153947.html [2] autoqa-de...@lists.fedorahosted.org signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/10/2011 05:35 PM, Matthew Garrett wrote: > On Sun, Jul 10, 2011 at 03:56:25PM -0500, Chris Adams wrote: >> This is a small, light-weight daemon, and doesn't need a configuration >> file parser. This is a valid way that Unix daemons have run for >> decades, and you are saying that should be removed. I guess every small >> daemon now needs to include its own config file parser, replacing the >> already-existing getopt() call? How is this "better"? > > Nobody's said it should be removed. Lennart's said that it sucks, and I > agree. But all of this would still be better with a simple config parser > that's shared between any daemons that want it. Some programs get their arguments through commandline and getopt(). Others, presumably with more complex configuration needs, use config files with ad-hoc syntax. Each individual one is easy enough to deal with, but together, they result in a divergent mess. This comes in play when people tried to write sysadmin tools dealing with all those formats---it was a nightmare (I remember trying and bein frustraded by one that 'almost worked' in the late 90s, written by a French/Candadian dude---sorry, can't recall the name at the moment). I for one welcome the new standard configuration format---yes, you have to adapt, but it unifies the configuration and configuration tools across the entire system. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong? -> wrong order
On 07/11/2011 12:15 PM, Lennart Poettering wrote: > On Mon, 11.07.11 12:02, Steve Dickson (ste...@redhat.com) wrote: > >> >> >> >> On 07/11/2011 10:03 AM, Lennart Poettering wrote: >>> On Mon, 11.07.11 10:57, Reindl Harald (h.rei...@thelounge.net) wrote: >>> Am 11.07.2011 04:51, schrieb Matthew Garrett: >> I truly truly truly hope so... but at the end of the day... I >> simply can't allow a new, untested (in a business environment) >> package destabilize a technology that is used by a large number >> of our community... > > If it's impossible to make NFS work sensibly with systemd then obviously > we'd revert it. But I don't believe that that's the case, and nothing > you've said in this thread has changed my mind there. It's clearly > possible to get NFS working. The question is whether it's possible to do > so in a way that matches your expectations of how users want NFS to > behave, and that's not an issue that results in any destabalisation my main critic on systemd shipped als default with F15 is that widely used services like NFS are not converted to systemd BEFORE systemd replaced upstart >>> >>> It's a bit of a chicken of egg problem. >>> >>> I actually sent patches which cleaned up part of the NFS stuff to Steve >>> (for example, socket activation patches for rpcbind), but he declined to >>> apply them. >> No. The community rejected them because > > Nope, you did. In a personal mail on Wed 11 Aug 2010. > > But really, this is a pointless game... > >>* They were to evasive which made the code unmaintainable esp >> WRT to security fixes. > > Uh? It's an addition of 30 lines of very simple code. In fact if it had > been merged it probably would have been the simplest code in all of the > NFS stack. > >>* They were too Fedora specific > > systemd is not a fedora-only project. It is available in a number of > other distributions, in a number of them default, and will be the > default in opensuse too, in the next release. Good to know... I'll talk their NFS maintainer to see how they are handling the systemd conversation... What other distro are planing to use it? > >>* Code stability was also a concern > > Really, for 30 lines of code? And where have these been expressed? > > I take it if I update the patch and repost it this would not change your > minds and would be rejected again? The main problem, in which you chose to ignore in this reply, is: >>* You rejected the idea of put the code in a standalone library. If you put your code in a standalone library making it much more manageable went it comes to configuration issues, go a head and resubmit it... You'll have a much better chance of acceptance... steved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/11/2011 01:11 PM, Lennart Poettering wrote: > On Mon, 11.07.11 12:55, Steve Dickson (ste...@redhat.com) wrote: > >> >> >> >> On 07/11/2011 05:03 AM, "Jóhann B. Guðmundsson" wrote: >>> On 07/11/2011 02:40 AM, Steve Dickson wrote: I truly truly truly hope so... but at the end of the day... I simply can't allow a new, untested (in a business environment) package destabilize a technology that is used by a large number of our community... >>> >>> The longer it takes to get a native systemd unit files out there the >>> more "untested" they will become. >> True... >>> >>> The faster they will be out there the more experience/exposer they will >>> receive. >> Acknowledged. >> >>> >>> No rocket science behind that logic some would even go so far as calling >>> that common knowledge so if you are truly worried about that, convert >>> those legacy sysv init file and put the native systemd unit file out >>> there, the sooner the better.. >> Yes I am very concern systemd will effect how NFS started, shutdown, >> managed, and configured... Because at the end of the day, when all >> hell breaks lose, your name will not those bz and your reputation >> will on the line... >> >>> >>> I think it's time that we hear from you explaining to us how systemd has >>> brought doom and chaos to the nfs world, how it has destabilize nfs and >>> left the *major subsystem* not working and it's citizens running for >>> their lives, committing mass suicide on the side walks and the cities >>> being overrun by zombies and the nfs world going down in flames... >>> >>> What do you say? >> My concerns are will documented the bz: >> https://bugzilla.redhat.com/show_bug.cgi?id=699040 >> >> But in a nut shell: >>* There is no way to conditionally start and stop services/daemons >> using a configuration variable. > > True, and on purpose. What would it take to change this? > >>* There is no way to conditionally start and stop services >> within as service. > > Not true. Services can start other services, by queuing a job for that > via a D-Bus call (or via systemctl, a wrapper for that). However, I'd > avoid doing this. hmm Not sure nfs-utils wants to get tied into the D-Bus world... > >>* The variables read out of the EnvironmentFile are *always* >> character strings which means set LOCKD_TCPPORT=234 is >> no longer possible. Losing that ability to set variable to >> integer values seem to like a giant step backwards. > > Hmm? Shell only understands strings, too. What precisely are you asking for? in /etc/sysconfig/nfsservices set LOCKD_TCPPORT=234 In nfsservice.service EnvironmentFile=-/etc/sysconfig/nfsservices ExecStartPre=/sbin/sysctl -w $LOCKD_TCPPORT to work. > >>* Being able to set a number of different config variables >> that will automatically build a valid command line to a >> given daemon. > > You can do that. Subsituation of env vars is (on purpose) very simple in > systemd. If you need a programming language to spawn your service, then > use one: shell. ok... I will look into that... steved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Catalyst-Plugin-I18N/el6] revert to 0.09
commit 46671f5678ee46e826de9762884d57518e84d92d
Author: Iain Arnell
Date: Mon Jul 11 18:20:25 2011 +0200
revert to 0.09
EL-6 only has Locale::Maketext::Simple 0.18.
.gitignore |1 +
perl-Catalyst-Plugin-I18N.spec | 30 +-
sources|2 +-
3 files changed, 7 insertions(+), 26 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 856d017..f59fa67 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Catalyst-Plugin-I18N-0.10.tar.gz
+/Catalyst-Plugin-I18N-0.09.tar.gz
diff --git a/perl-Catalyst-Plugin-I18N.spec b/perl-Catalyst-Plugin-I18N.spec
index a522f66..53566f6 100644
--- a/perl-Catalyst-Plugin-I18N.spec
+++ b/perl-Catalyst-Plugin-I18N.spec
@@ -1,18 +1,18 @@
Name: perl-Catalyst-Plugin-I18N
-Version:0.10
-Release:3%{?dist}
+Version:0.09
+Release:2%{?dist}
Summary:I18N for Catalyst
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Catalyst-Plugin-I18N/
-Source0:
http://search.cpan.org/CPAN/authors/id/B/BO/BOBTFISH/Catalyst-Plugin-I18N-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/M/MR/MRAMBERG/Catalyst-Plugin-I18N-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(Catalyst::Runtime)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Locale::Maketext::Lexicon)
-BuildRequires: perl(Locale::Maketext::Simple) >= 0.19
-BuildRequires: perl(MRO::Compat) >= 0.10
+BuildRequires: perl(Locale::Maketext::Simple)
+BuildRequires: perl(MRO::Compat)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
@@ -56,26 +56,6 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
-* Tue Feb 08 2011 Fedora Release Engineering
- 0.10-3
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
-
-* Wed Dec 15 2010 Marcela Maslanova - 0.10-2
-- 661697 rebuild for fixing problems with vendorach/lib
-
-* Fri Jun 18 2010 Iain Arnell 0.10-1
-- update to latest upstream
-- use perl_default_filter and DESTDIR
-- update buildrequires
-
-* Fri Apr 30 2010 Marcela Maslanova - 0.09-5
-- Mass rebuild with perl-5.12.0
-
-* Mon Dec 7 2009 Stepan Kasal - 0.09-4
-- rebuild against perl 5.10.1
-
-* Sat Jul 25 2009 Fedora Release Engineering
- 0.09-3
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
-
* Sun May 24 2009 Iain Arnell 0.09-2
- add missing requires perl(Locale::Maketext::Lexicon)
diff --git a/sources b/sources
index 8b3fc1c..e72731a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d0b42885072d49dcd0f5def7eb14d42b Catalyst-Plugin-I18N-0.10.tar.gz
+6f0c0e5e165a3f605bd66dd4db2ba5d7 Catalyst-Plugin-I18N-0.09.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
File Bucardo-4.4.6.tar.gz.asc uploaded to lookaside cache by itamarjp
A file has been added to the lookaside cache for bucardo: cdfddfb7e13bc4fc197fe709b7271bd0 Bucardo-4.4.6.tar.gz.asc -- 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
File Bucardo-4.4.6.tar.gz uploaded to lookaside cache by itamarjp
A file has been added to the lookaside cache for bucardo: e74b526e9eb3ef7de936e720c4b2f222 Bucardo-4.4.6.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
[bucardo] new version 4.4.6
commit 2a1c3f83b07a767804dc538d5fddab16a0ccabe4
Author: Itamar Reis Peixoto
Date: Mon Jul 11 14:00:47 2011 -0300
new version 4.4.6
bucardo.spec | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
---
diff --git a/bucardo.spec b/bucardo.spec
index 80668d6..6d6d7c5 100644
--- a/bucardo.spec
+++ b/bucardo.spec
@@ -1,6 +1,6 @@
%define realname Bucardo
Name: bucardo
-Version:4.4.5
+Version:4.4.6
Release:1%{?dist}
Summary:Postgres replication system for both multi-master and
multi-slave operations
@@ -10,7 +10,9 @@ URL:http://bucardo.org/
Source0:http://bucardo.org/downloads/Bucardo-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Source1: master-master-replication-example.txt
+Source1: Bucardo-%{version}.tar.gz.asc
+Source2: master-master-replication-example.txt
+
BuildArch: noarch
@@ -69,7 +71,7 @@ rm -f $RPM_BUILD_ROOT/%{_bindir}/bucardo_ctl
install -Dp -m 755 bucardo_ctl $RPM_BUILD_ROOT/%{_sbindir}/bucardo_ctl
mkdir -p $RPM_BUILD_ROOT/%{_localstatedir}/run/bucardo
-install -Dp -m 644 %{SOURCE1} .
+install -Dp -m 644 %{SOURCE2} .
@@ -92,6 +94,9 @@ rm -rf $RPM_BUILD_ROOT
%dir %{_localstatedir}/run/bucardo
%changelog
+* Mon Jul 11 2011 Itamar Reis Peixoto - 4.4.6-1
+- new version 4.4.6
+
* Sun Jun 19 2011 Itamar Reis Peixoto - 4.4.5-1
- New version 4.4.5 fix truncate 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
[bucardo] - new version
commit c63156bf2e1fb8f3f2fda4b3e90bb99858c517cb Author: Itamar Reis Peixoto Date: Mon Jul 11 13:59:30 2011 -0300 - new version .gitignore |2 ++ sources|4 ++-- 2 files changed, 4 insertions(+), 2 deletions(-) --- diff --git a/.gitignore b/.gitignore index 9a1fbce..24f52e9 100644 --- a/.gitignore +++ b/.gitignore @@ -3,3 +3,5 @@ Bucardo-4.4.0.tar.gz /Bucardo-4.4.4.tar.gz /Bucardo-4.4.5.tar.gz /Bucardo-4.4.5.tar.gz.asc +/Bucardo-4.4.6.tar.gz +/Bucardo-4.4.6.tar.gz.asc diff --git a/sources b/sources index 36c4a90..b76c8b4 100644 --- a/sources +++ b/sources @@ -1,2 +1,2 @@ -90a013c5e4c5efa608aea9cf57fc49bd Bucardo-4.4.5.tar.gz -c55e4af589ece423d958059270575c6b Bucardo-4.4.5.tar.gz.asc +e74b526e9eb3ef7de936e720c4b2f222 Bucardo-4.4.6.tar.gz +cdfddfb7e13bc4fc197fe709b7271bd0 Bucardo-4.4.6.tar.gz.asc -- 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: systemd: Is it wrong?
On 07/11/2011 04:42 AM, Michal Schmidt wrote: > On Sun, 10 Jul 2011 20:49:56 -0400 Steve Dickson wrote: >> Ok.. Now understand where my confusion is... Currently when one >> want to start the nfs server they type 'service nfs start' which >> calls a number of binaries and ultimately a system daemon. > > We could achieve something similar with systemd by providing a target > unit 'nfs.target'. The unit would pull the daemons using requirement > dependencies. > >> Now if they enable want secure nfs, they edit a file in /etc/systconf >> and simply type 'service nfs restart' which again runs a number >> of binaries and start a couple of system daemons. > > This could be another target 'nfs-secure.target'. It would pull > 'nfs.target' + more daemons. > > The users would start and enable these target units instead of > the units of the individual daemons. This definitely sounds promising... When you have some code to play around please let me know... I'm more than willing to help out.. steved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
mån 2011-07-11 klockan 12:55 -0400 skrev Steve Dickson: > * The variables read out of the EnvironmentFile are *always* > character strings which means set LOCKD_TCPPORT=234 is > no longer possible. Losing that ability to set variable to > integer values seem to like a giant step backwards. The default value is "" (empty string) so you need to handle that case. (The SysV script has an if clause for exactly this purpose.) It looks like you can have multiple EnvironmentFile (or just use Environment=), which allows you to have one file with the default values and one config file where they can be overridden. Or you can modify the unit file to handle the empty variable in some other way. Say, by branching out into a shell script which only calls sysctl if the variable is set. Or by creating a special command which does about the same. Or by moving it into rpc.statd. /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
2011/7/11 Steve Dickson
> > Hmm? Shell only understands strings, too. What precisely are you asking
> for?
> in /etc/sysconfig/nfsservices
> set LOCKD_TCPPORT=234
>
> In nfsservice.service
>
> EnvironmentFile=-/etc/sysconfig/nfsservices
> ExecStartPre=/sbin/sysctl -w $LOCKD_TCPPORT
>
> to work.
>
That is supposed to work. However, if /etc/sysconfig/nfsservices reads:
#set LOCKD_TCPPORT=234
the variable evaluates to the empty string, not 0, so the sysctl invocation
fails. I don't think unit files support advanced bash syntax like
${LOCKD_TCPPORT:-0} ...
Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks))
W dniu 11 lipca 2011 18:28 użytkownik Michal Hlavinka napisał: > On 07/11/2011 06:05 PM, Michał Piotrowski wrote: >> >> W dniu 11 lipca 2011 17:57 użytkownik Michal Hlavinka >> napisał: >>> >>> On 07/11/2011 05:40 PM, Michał Piotrowski wrote: Hi, W dniu 11 lipca 2011 17:09 użytkownik Michal Hlavinka napisał: > > ok, complain about memcpy in ecryptfs-utils is gone. I've checked all > of > them and I think I've fixed those which needed it. I was not able to > reproduce original problem nor valgrind complaint, so please test if > following package produces memcpy complain in valgrind output or not: > > http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/ Your mtab handling patch fixed both issues - mount warning and data corruption :) Huge thanks! >>> >>> I can't imagine *how* it could affect this, so I'd advice to monitor it >>> carefully if it is fixed for real. >> >> Ok, so I will do. Before each time I mounted ecryptfs I get this >> "Error mounting eCryptfs: [-5] Input/output error" error. Now it's >> gone - I tried a few times. > > yes, this is related to mtab patch, but it mounted it anyway. I was able to > reproduce this warning. It should not affect smb+ecryptfs data corruption in > any way. I uploaded another large file (> 1 GB) and unfortunately data corruption problem still exist - I do not know why it worked previously. > Btw, did you test if this version works in valgrind or not? (the > "Source and destination overlap in memcpy" warning). Yes, I tested this version, but log isn't generated - so I suppose there are no problems that can be found by valgrind. > > btw, we should move this conversation off list if it's related only to > ecryptfs. > > Michal > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/11/2011 01:40 PM, Florian Müllner wrote:
> 2011/7/11 Steve Dickson mailto:ste...@redhat.com>>
>
> > Hmm? Shell only understands strings, too. What precisely are you asking
> for?
> in /etc/sysconfig/nfsservices
> set LOCKD_TCPPORT=234
>
> In nfsservice.service
>
> EnvironmentFile=-/etc/sysconfig/nfsservices
> ExecStartPre=/sbin/sysctl -w $LOCKD_TCPPORT
>
> to work.
>
>
> That is supposed to work. However, if /etc/sysconfig/nfsservices reads:
> #set LOCKD_TCPPORT=234
No, I go head and set it to zero... So I know its defined...
>
> the variable evaluates to the empty string, not 0, so the sysctl invocation
> fails. I don't think unit files support advanced bash syntax like
> ${LOCKD_TCPPORT:-0} ...
that would be nice... But defining it to zero is no biggie...
steved.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages
On Wed, Jul 06, 2011 at 02:43:43PM -0400, Casey Dahlin wrote: > On Wed, Jul 06, 2011 at 11:23:06AM -0700, Jesse Keating wrote: > > I no longer have a need/care for these packages, they are up for grabs: > > > > contacts > > inotail > > I'll take inotail. > > --CJD Someone pointed out that this functionality is now available in tailf, so I don't think this package is necessary at all. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong? -> wrong order
On Mon, 11.07.11 13:20, Steve Dickson (ste...@redhat.com) wrote: > > systemd is not a fedora-only project. It is available in a number of > > other distributions, in a number of them default, and will be the > > default in opensuse too, in the next release. > > Good to know... I'll talk their NFS maintainer to see how > they are handling the systemd conversation... What other > distro are planing to use it? I lost track of this a bit, but MeeGo already switched, and Mandriva did too afair. OpenSUSE will switch in the coming release. Gentoo, Debian, Arch have it in the disro, but not default. Or to turn this around: of the big ones only Ubuntu currently has no official plans, but I am confident this will change too eventually (hopefully as soon as their next LTS release is out). > >>* You rejected the idea of put the code in a standalone library. > > If you put your code in a standalone library making it much more > manageable went it comes to configuration issues, go a head > and resubmit it... You'll have a much better chance of acceptance... Well, this has been requested before, and we'll eventuall provide that, but at the moment we ask prople to embed this code. To make that unproblematic it is really trivial code (just parses two env vars basically), and portable, and liberally licensed. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
[Resending this got bounced ] On 07/11/2011 12:18 PM, Lennart Poettering wrote: > On Mon, 11.07.11 12:15, Steve Dickson (ste...@redhat.com) wrote: > >> On 07/11/2011 10:44 AM, Lennart Poettering wrote: >>> On Mon, 11.07.11 16:32, Miloslav Trmač (m...@volny.cz) wrote: >>> Steve otoh wants one service to consist of multiple daemons, each of >>> which can consist of multiple processes. I find that unnecessarily >>> complex and this is not implemented in system, and have pointed out a >>> number of times why. >> >> Too complexed for your code, not system admins. That's exactly what >> they want. > > You have as little idea of what "exactly" sys admins want as I > do. > > Or maybe I have a tiny bit of more of an idea, because I actually get > all the feedback, and I go to all the conferences, and I know what's > going on and I don't live under a rock. This just rocks my world that you have the audacity to say something like this... You have no idea of where I've been, what I've done and for how long... You really need to roll back your attitude 100% because it makes working with so difficult when you throw out blanket statements like that... So please lets keep this on a respectful and professional plane... steved. P.S. I don't go to many conferences but I have been to many customer sites, over the years... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, 11.07.11 13:29, Steve Dickson (ste...@redhat.com) wrote: > >> But in a nut shell: > >>* There is no way to conditionally start and stop services/daemons > >> using a configuration variable. > > > > True, and on purpose. > > What would it take to change this? We want to simplify things and hence want to explicitly avoid having additional places where services are enabled/disabled. So, it is really against a design principle of ours that we support additional ways to disable services in systemd itself. So this is unlikely to ever happen. Sorry. > >>* There is no way to conditionally start and stop services > >> within as service. > > > > Not true. Services can start other services, by queuing a job for that > > via a D-Bus call (or via systemctl, a wrapper for that). However, I'd > > avoid doing this. > > hmm Not sure nfs-utils wants to get tied into the D-Bus world... *sigh* > >>* The variables read out of the EnvironmentFile are *always* > >> character strings which means set LOCKD_TCPPORT=234 is > >> no longer possible. Losing that ability to set variable to > >> integer values seem to like a giant step backwards. > > > > Hmm? Shell only understands strings, too. What precisely are you asking for? > in /etc/sysconfig/nfsservices > set LOCKD_TCPPORT=234 > > In nfsservice.service > > EnvironmentFile=-/etc/sysconfig/nfsservices > ExecStartPre=/sbin/sysctl -w $LOCKD_TCPPORT > > to work. This will work. And I completely fail to see what this has to do with integer values? Can you elaborate? And what do you claim the shell does differently then we do? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, 11.07.11 13:43, Steve Dickson (ste...@redhat.com) wrote:
> > the variable evaluates to the empty string, not 0, so the sysctl
> invocation fails. I don't think unit files support advanced bash
> syntax like ${LOCKD_TCPPORT:-0} ...
>
> that would be nice... But defining it to zero is no biggie...
You can use Environment= in unit files to set defaults, which are then
overriden by EnvironmentFile=.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/11/2011 01:54 PM, Lennart Poettering wrote: > On Mon, 11.07.11 13:29, Steve Dickson (ste...@redhat.com) wrote: * The variables read out of the EnvironmentFile are *always* character strings which means set LOCKD_TCPPORT=234 is no longer possible. Losing that ability to set variable to integer values seem to like a giant step backwards. >>> >>> Hmm? Shell only understands strings, too. What precisely are you asking for? >> in /etc/sysconfig/nfsservices >> set LOCKD_TCPPORT=234 >> >> In nfsservice.service >> >> EnvironmentFile=-/etc/sysconfig/nfsservices >> ExecStartPre=/sbin/sysctl -w $LOCKD_TCPPORT >> >> to work. > > This will work. And I completely fail to see what this has to do with > integer values? Can you elaborate? If I'm interpreting commitments: https://bugzilla.redhat.com/show_bug.cgi?id=699040#c43 and https://bugzilla.redhat.com/show_bug.cgi?id=699040#c44 Correctly, the only way to make this work is to make LOCKD_TCPPORT then entire string "fs.nfs.nlm_udpport=12345" instead of just 12345 steved -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
orphaning xmms-modplug
I'm orphaning xmms-modplug. Free to anyone to take. Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/11/2011 12:18 PM, Lennart Poettering wrote: > On Mon, 11.07.11 12:15, Steve Dickson (ste...@redhat.com) wrote: > >> On 07/11/2011 10:44 AM, Lennart Poettering wrote: >>> On Mon, 11.07.11 16:32, Miloslav Trmač (m...@volny.cz) wrote: >>> Steve otoh wants one service to consist of multiple daemons, each of >>> which can consist of multiple processes. I find that unnecessarily >>> complex and this is not implemented in system, and have pointed out a >>> number of times why. >> >> Too complexed for your code, not system admins. That's exactly what >> they want. > > You have as little idea of what "exactly" sys admins want as I > do. > > Or maybe I have a tiny bit of more of an idea, because I actually get > all the feedback, and I go to all the conferences, and I know what's > going on and I don't live under a rock. This just rocks my world that you have the audacity to say something like this... You have no idea of where I've been, what I've done and for how long... You really need to roll back your attitude 100% because it makes working with so difficult when you throw out blanket statements like that... So please lets keep this on a respectful and professional plane... steved. P.S. I don't go to many conferences but I have been to many customer sites, over the years... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/11/2011 06:02 PM, Steve Dickson wrote:
>
> On 07/11/2011 01:54 PM, Lennart Poettering wrote:
>> On Mon, 11.07.11 13:29, Steve Dickson (ste...@redhat.com) wrote:
> * The variables read out of the EnvironmentFile are *always*
> character strings which means set LOCKD_TCPPORT=234 is
> no longer possible. Losing that ability to set variable to
> integer values seem to like a giant step backwards.
Hmm? Shell only understands strings, too. What precisely are you asking
for?
>>> in /etc/sysconfig/nfsservices
>>> set LOCKD_TCPPORT=234
>>>
>>> In nfsservice.service
>>>
>>> EnvironmentFile=-/etc/sysconfig/nfsservices
>>> ExecStartPre=/sbin/sysctl -w $LOCKD_TCPPORT
>>>
>>> to work.
>> This will work. And I completely fail to see what this has to do with
>> integer values? Can you elaborate?
> If I'm interpreting commitments:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=699040#c43
> and
> https://bugzilla.redhat.com/show_bug.cgi?id=699040#c44
>
> Correctly, the only way to make this work is to make LOCKD_TCPPORT
> then entire string "fs.nfs.nlm_udpport=12345" instead of just 12345
I was conducting a series of test and I just confirmed that this works
as well ;)
ExecStartPre=/sbin/sysctl -w fs.nfs.nlm_tcpport=${LOCKD_UDPPORT}
fs.nfs.nlm_tcpport=${LOCKD_TCPPORT}
Which btw is documented also in the manpage ;) which I should have read
as well as you..
"On top of that basic environment variable substitution is supported,
where ${FOO} is replaced by the string value of the environment variable
of the same name. Also $FOO may appear as separate word on the command
line in which case the variable is replaced by its value split at
whitespaces. Note that the first
argument (i.e. the binry to execute) may not be a variable, and must
be a literal and absolute path name.
So let's get this one packaged and rolling. )
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, 11.07.11 14:02, Steve Dickson (ste...@redhat.com) wrote:
>
>
>
> On 07/11/2011 01:54 PM, Lennart Poettering wrote:
> > On Mon, 11.07.11 13:29, Steve Dickson (ste...@redhat.com) wrote:
> * The variables read out of the EnvironmentFile are *always*
> character strings which means set LOCKD_TCPPORT=234 is
> no longer possible. Losing that ability to set variable to
> integer values seem to like a giant step backwards.
> >>>
> >>> Hmm? Shell only understands strings, too. What precisely are you asking
> >>> for?
> >> in /etc/sysconfig/nfsservices
> >> set LOCKD_TCPPORT=234
> >>
> >> In nfsservice.service
> >>
> >> EnvironmentFile=-/etc/sysconfig/nfsservices
> >> ExecStartPre=/sbin/sysctl -w $LOCKD_TCPPORT
> >>
> >> to work.
> >
> > This will work. And I completely fail to see what this has to do with
> > integer values? Can you elaborate?
> If I'm interpreting commitments:
>
>https://bugzilla.redhat.com/show_bug.cgi?id=699040#c43
> and
>https://bugzilla.redhat.com/show_bug.cgi?id=699040#c44
>
> Correctly, the only way to make this work is to make LOCKD_TCPPORT
> then entire string "fs.nfs.nlm_udpport=12345" instead of just 12345
Use "/sbin/sysctl -w fs.nfs.nlm_tcpport=${LOCKD_TCPPORT}" instead of
"/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT".
This is all documented. See systemd.service(5), under ExecStart=.
$FOO needs to appear as separate word, and the variable value will be split up
at whitespace.
${FOO} can appear as part of a word, and the variable value will not be
split up at whitespace.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/11/2011 02:40 PM, Lennart Poettering wrote:
> On Mon, 11.07.11 14:02, Steve Dickson (ste...@redhat.com) wrote:
>
>>
>>
>>
>> On 07/11/2011 01:54 PM, Lennart Poettering wrote:
>>> On Mon, 11.07.11 13:29, Steve Dickson (ste...@redhat.com) wrote:
>>* The variables read out of the EnvironmentFile are *always*
>> character strings which means set LOCKD_TCPPORT=234 is
>> no longer possible. Losing that ability to set variable to
>> integer values seem to like a giant step backwards.
>
> Hmm? Shell only understands strings, too. What precisely are you asking
> for?
in /etc/sysconfig/nfsservices
set LOCKD_TCPPORT=234
In nfsservice.service
EnvironmentFile=-/etc/sysconfig/nfsservices
ExecStartPre=/sbin/sysctl -w $LOCKD_TCPPORT
to work.
>>>
>>> This will work. And I completely fail to see what this has to do with
>>> integer values? Can you elaborate?
>> If I'm interpreting commitments:
>>
>>https://bugzilla.redhat.com/show_bug.cgi?id=699040#c43
>> and
>>https://bugzilla.redhat.com/show_bug.cgi?id=699040#c44
>>
>> Correctly, the only way to make this work is to make LOCKD_TCPPORT
>> then entire string "fs.nfs.nlm_udpport=12345" instead of just 12345
>
> Use "/sbin/sysctl -w fs.nfs.nlm_tcpport=${LOCKD_TCPPORT}" instead of
> "/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT".
>
> This is all documented. See systemd.service(5), under ExecStart=.
Thanks for point this out... I did look for how to set these variables
but I obviously I missed it... thank you for point this and taking the
time to test it..
steved.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for today's FESCo meeting (2011-7-11)
=== #fedora-meeting: FESCO (2011-07-11) === Meeting started by ajax at 17:00:55 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-07-11/fesco.2011-07-11-17.00.log.html . Meeting summary --- * #563 suggested policy: all daemons must set RELRO and PIE flags (ajax, 17:03:53) * AGREED: revisit PIE criteria next week (ajax, 17:26:25) * #614 Proposed list of packages to drop due to FTBFS prior to F16 (ajax, 17:26:38) * AGREED: package removal list as given is implicitly agreed to, based on last fesco's policy decision (ajax, 17:31:00) * LINK: http://fedoraproject.org/wiki/Deprecate_FTBFS_packages (gholms, 17:31:04) * #615 Strategy for services that do not have systemd native unit files (ajax, 17:31:59) * #531 Orphaned package ownership claiming clarification (ajax, 17:34:27) * LINK: https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd (Viking-Ice, 17:37:29) * systemd conversion status (round two) (ajax, 17:38:03) * ACTION: ajax to send email to devel@ reminding people of blocker-ness of not converting systemd services (ajax, 17:49:03) * #608 F16Feature: Trusted Boot - http://fedoraproject.org/wiki/Features/Trusted_Boot (ajax, 17:50:51) * AGREED: feature discussion is deferred until grubby integration happens (ajax, 17:58:04) * ACTION: ajax to email feature owner to remind (ajax, 17:58:15) * #618 F16Feature: pacemaker-cloud - https://fedoraproject.org/wiki/Features/pacemaker-cloud (ajax, 18:00:14) * AGREED: pacemaker-cloud feature is approved (ajax, 18:01:16) * #619 F16 Feature: Matahari -- https://fedoraproject.org/wiki/Features/Matahari (ajax, 18:01:37) * AGREED: matahari feature is approved (ajax, 18:03:25) * #620 F16Feature: Virtual Machine Lock Manager - https://fedoraproject.org/wiki/Features/VirtLockManager (ajax, 18:03:46) * AGREED: virtual machine lock manager feature is approved (ajax, 18:17:51) * #621 F16 Feature: GNOME 3.2 - https://fedoraproject.org/wiki/Features/Gnome3.2 (ajax, 18:18:00) * AGREED: gnome 3.2 feature is approved (ajax, 18:18:50) * #622 F16Feature: KDE Plasma Workspaces 4.7 - https://fedoraproject.org/wiki/Features/KDE47 (ajax, 18:18:56) * AGREED: KDE 4.7 feature is approved (ajax, 18:19:44) * #624 F16Feature: Virt Networking Enhancements - https://fedoraproject.org/wiki/Features/VirtNetworkingEnhancements (ajax, 18:20:04) * AGREED: virt networking enhancements feature is approved (ajax, 18:21:47) * #625 F16Feature: USB Network Redirection - https://fedoraproject.org/wiki/Features/UsbNetworkRedirection (ajax, 18:22:04) * AGREED: USB network redirection feature is approved (with release notes, please) (ajax, 18:26:22) * #626 F16Feature: firewalld as default Fedora firewall solution - https://fedoraproject.org/wiki/Features/firewalld-default (ajax, 18:26:37) * AGREED: firewalld feature is approved (ajax, 18:33:46) * #627 F16 Feature: network zones -- https://fedoraproject.org/wiki/Features/network-zones (ajax, 18:33:59) * AGREED: network zones feature is approved (ajax, 18:35:42) * #628 F16Feature: VirtSandbox -- https://fedoraproject.org/wiki/Features/VirtSandbox (ajax, 18:35:55) * AGREED: virt sandbox feature is approved (ajax, 18:38:06) * #629 F16Feature: Virt-manager Guest Inspection - https://fedoraproject.org/wiki/Features/Virt-manager_Guest_Inspection (ajax, 18:38:22) * AGREED: virt-manager guest inspection feature is approved (ajax, 18:41:18) * #630 F16Feature: SELinux File Name Transition - https://fedoraproject.org/wiki/Features/SELinuxFileNameTransition (ajax, 18:41:32) * AGREED: selinux file name transition feature is not approved (ajax, 18:48:16) * #631 F16Feature: TigerVNC 1.1 - http://fedoraproject.org/wiki/Features/TigerVNC1.1 (ajax, 18:48:36) * AGREED: tigervnc 1.1 feature is approved (ajax, 18:49:32) * #632 F16Feature: Grub2 - https://fedoraproject.org/wiki/Features/Grub2 (ajax, 18:49:36) * AGREED: grub2 feature is approved (ajax, 18:50:53) * #623 F16Feature: KDE Plasma Desktop by default - https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default (ajax, 18:51:17) * AGREED: kde-by-default feature is rejected (ajax, 18:52:55) * open floor (ajax, 18:53:28) * ACTION: mjg59 to chair next week (ajax, 18:55:04) Meeting ended at 18:57:22 UTC. Action Items * ajax to send email to devel@ reminding people of blocker-ness of not converting systemd services * ajax to email feature owner to remind * mjg59 to chair next week Action Items, by person --- * ajax * ajax to send email to devel@ reminding people of blocker-ness of not converting systemd services * ajax to email feature owner to remind * mjg59 * mjg59 to chair next we
Re: Plan for today's FESCo meeting (2011-7-11)
On 07/11/2011 07:10 PM, Adam Jackson wrote: > * #531 Orphaned package ownership claiming clarification (ajax, > 17:34:27) > * LINK: > https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd > (Viking-Ice, 17:37:29) Uhum my link belongs to item #615 not Item #531 ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 15 moving task (thread) off CPU
Hi, I'm trying to move kernel threads off CPUs, but can't seem to do so in F15. The kernel call used is sched_setaffinity, and it fails with message "Invalid argument". Example threads include "cpuset" and "khelper", among others. Yes, I have checked that these threads are not bounded to specific CPUs. Any idea why? Are there any new restrictions w.r.t. moving kthreads in F15? There were no problems in Redhat 6 or earlier. Thank you. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 16 Schedule Reminders - Feature Submission and Feature Freeze.
A few friendly reminders: * The Feature Submission deadline for Fedora 16 is *tomorrow*, July 12. The current process for submitting a feature for Fedora 16 can be seen here: http://fedoraproject.org/wiki/Features/Policy * Feature Freeze comes quickly after the Feature Submission deadline, on July 26. Please note that at this point, Features should be *substantially complete and in a testable state.* For more information on the Feature Freeze policy, please read: http://fedoraproject.org/wiki/ReleaseEngineering/FeatureFreezePolicy And finally for those of you interested in seeing how the Feature List is shaping up for Fedora 16, it is up to date with the latest and greatest approvals from today's FESCo meeting. http://fedoraproject.org/wiki/FeatureList This is where I'm going to put on my Gentle Reminder Hat, and give everyone a chance to go into their individual feature pages and update their percentage complete, and update their "Last Updated" date, which I will apply to the main FeatureList page. Your efforts here are appreciated, and help a number of groups understand how close you are to completion, or conversely, if you are at risk of not making deadlines. If percentages don't start getting updated, and "last-updated" dates aren't getting touched, I'll be reaching out to folks individually, but I would prefer to see that people take the initiative and keep those things up. Otherwise I have to get out the not-so-Gentle-Reminder-Hat, and frankly, I don't look very good in that one. Communication is the key here. If you believe you are *at risk* of not making the Feature Freeze, please update your feature page accordingly. The rest of the schedule, as always, can be seen here: https://fedoraproject.org/wiki/Releases/16/Schedule Thanks! -Robyn ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lack of space on /
On Sat, 2011-07-09 at 11:30 +0100, Richard W.M. Jones wrote: > On Fri, Jul 08, 2011 at 09:47:13AM +0100, Paul F. Johnson wrote: > > Hi, > > > > Something strange has happened on my system. At the start of last > > week, / was reporting that I had about 8Gb free. It now reports that / > > is completely full. > > > > chkrootkit is reporting nothing untoward. > > > > I have noticed that putting things in the wastebasket and then saying > > empty hasn't been doing so recently, but that shouldn't account for 8Gb! > > > > Any ideas? > > This is the wrong list to be asking this question. Nevertheless, > a quick shout out to the amazing power of KDE Filelight ... > > http://kde-apps.org/content/show.php/filelight?content=99561 > > Rich. GNOME equivalent is Baobab. I think it's actually a core bit of GNOME these days... [adamw@adam Downloads]$ rpm -qf `which baobab` gnome-utils-3.1.2-1.fc16.x86_64 [adamw@adam Downloads]$ -- 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
Re: Lack of space on /
2011/7/11 Adam Williamson : > On Sat, 2011-07-09 at 11:30 +0100, Richard W.M. Jones wrote: >> On Fri, Jul 08, 2011 at 09:47:13AM +0100, Paul F. Johnson wrote: >> > Hi, >> > >> > Something strange has happened on my system. At the start of last >> > week, / was reporting that I had about 8Gb free. It now reports that / >> > is completely full. >> > >> > chkrootkit is reporting nothing untoward. >> > >> > I have noticed that putting things in the wastebasket and then saying >> > empty hasn't been doing so recently, but that shouldn't account for 8Gb! >> > >> > Any ideas? >> >> This is the wrong list to be asking this question. Nevertheless, >> a quick shout out to the amazing power of KDE Filelight ... >> >> http://kde-apps.org/content/show.php/filelight?content=99561 >> >> Rich. > > GNOME equivalent is Baobab. I think it's actually a core bit of GNOME > these days... > > [adamw@adam Downloads]$ rpm -qf `which baobab` > gnome-utils-3.1.2-1.fc16.x86_64 I am using Linux every day, but for a long time I did not use X. Some people just needs shell magic :) > [adamw@adam Downloads]$ > -- > 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 > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Garbled display and touchpad configuration
On Sun, 2011-07-10 at 12:28 -0400, ceco wrote: > Ok folks I know everyone is busy but it's time to actually sit down > and write a driver for the ATI Radeon card used in a lot of laptops. There are several hundred - probably thousand, by now - different graphics adapters with the string 'ATI Radeon' in their name. Many of them are supported by the 'radeon' driver. It would help quite a lot in your bug report if you could be rather more specific about the hardware and the problem. Please see https://fedoraproject.org/wiki/How_to_debug_Xorg_problems . Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Firefox channels (Nightly, Aurora and Beta) in F16
Hello everyone! As it is my first mail to this list, let me briefly introduce myself: I am Maciej Małecki, software developer based in Poznań, Poland. I've been using Fedora since F11 (and I love it). The point is: is there a chance to have Mozilla Aurora, Beta and Nightly in F16 repositories? I think it would make life easier for quite many people. Now installation process is to download .tar.gz from Mozilla, unpack to /usr/lib64/firefox-7 (for Aurora) and create a .desktop file in /usr/share/applications. Mozilla guys discussed it here: https://bugzilla.mozilla.org/show_bug.cgi?id=600317, however most of the links are outdated/404. -- Greetings, Maciej Małecki -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, 2011-07-11 at 18:18 +0200, Lennart Poettering wrote: > > One command that starts multiple process/daemons of a particular service. > > It as simple as that. > > I guess we have to agree to disagree on this. A lost chance for NFS, Well, two people have already pointed out it's perfectly possible to achieve this even for the multiple service case by using a target. -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Garbled display and touchpad configuration
I just uploaded the files, should I still do a bug report even though there are other reports on the same issue -- ceco -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, 2011-07-11 at 13:34 -0400, Steve Dickson wrote: > > On 07/11/2011 04:42 AM, Michal Schmidt wrote: > > On Sun, 10 Jul 2011 20:49:56 -0400 Steve Dickson wrote: > >> Ok.. Now understand where my confusion is... Currently when one > >> want to start the nfs server they type 'service nfs start' which > >> calls a number of binaries and ultimately a system daemon. > > > > We could achieve something similar with systemd by providing a target > > unit 'nfs.target'. The unit would pull the daemons using requirement > > dependencies. > > > >> Now if they enable want secure nfs, they edit a file in /etc/systconf > >> and simply type 'service nfs restart' which again runs a number > >> of binaries and start a couple of system daemons. > > > > This could be another target 'nfs-secure.target'. It would pull > > 'nfs.target' + more daemons. > > > > The users would start and enable these target units instead of > > the units of the individual daemons. > This definitely sounds promising... When you have some code to > play around please let me know... I'm more than willing to help > out.. There's no 'code' involved, really, targets are a feature of systemd and you create them much like services. Take a look at /lib/systemd/system/graphical.target and /lib/systemd/system/graphical.target.wants , for instance. All you need is a definition for the target and the .wants subdirectory containing symlinks to the services included in (in systemd terminology, 'wanted by') the target. So if, in converting NFS to systemd, we wound up with five services which all need to be run to start up NFS completely: /lib/systemd/system/nfs-1.service /lib/systemd/system/nfs-2.service /lib/systemd/system/nfs-3.service /lib/systemd/system/nfs-4.service /lib/systemd/system/nfs-5.service you'd just have a /lib/systemd/system/nfs.target with the normal boring boilerplate: [Unit] Description=NFS Requires=network.target and a /lib/systemd/system/nfs.target.wants/ directory containing symlinks to: /lib/systemd/system/nfs-1.service /lib/systemd/system/nfs-2.service /lib/systemd/system/nfs-3.service /lib/systemd/system/nfs-4.service /lib/systemd/system/nfs-5.service and Bob would be your uncle. More or less. I just did all that on the back of an envelope and it's probably wrong somewhere. But you get the idea. -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Garbled display and touchpad configuration
On Mon, 2011-07-11 at 20:17 -0400, ceco wrote: > I just uploaded the files, should I still do a bug report even though there > are other reports on the same issue Add a comment and attach your data to one of the reports. -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Garbled display and touchpad configuration
Thank you I will do just that --Original Message-- From: Adam Williamson To: Cecil Funderburk Cc: devel@lists.fedoraproject.org Subject: Re: Garbled display and touchpad configuration Sent: Jul 11, 2011 8:36 PM On Mon, 2011-07-11 at 20:17 -0400, ceco wrote: > I just uploaded the files, should I still do a bug report even though there > are other reports on the same issue Add a comment and attach your data to one of the reports. -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net Have a great day!! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Mon, 11.07.11 17:16, Adam Williamson (awill...@redhat.com) wrote: > > On Mon, 2011-07-11 at 18:18 +0200, Lennart Poettering wrote: > > > > One command that starts multiple process/daemons of a particular service. > > > It as simple as that. > > > > I guess we have to agree to disagree on this. A lost chance for NFS, > > Well, two people have already pointed out it's perfectly possible to > achieve this even for the multiple service case by using a target. You don't really need targets for this really. A target is a nice abstraction that can be used to mean a lot of different things based on configuration. But I think in the NFS case this isn't even necessary. So what I am proposing is this. Split up the daemons, so that you have one unit file per daemon. Have the main NFS daemon unit file pull in all other required NFS deaemons via BindTo and backwards too to ensure that they ara always started/stopped together. The optional additional daemons hook in via nfs.service.wants/ links, via the usual [Install] in them section and "systemctl enable". Note that you can hook services into any other unit via .wants/ links (including .service units!), not just into .target units. Nothing stops you from placing "WantedBy=nfs.service" in a unit file, in fact I encourage you to. Or in other words: using a target is not the solution, but simply using the relatively powerful set of dependencies you can express in systemd unit files. Here's an example. let's say we have three nfs related services. The main daemon is in nfs.service, an auxiliary service always needed by it is nfs-mount.service, and a third service nfs-quota.service is optional. Then write this: In nfs.service: [Unit] Description=Main NFS Service BindTo=nfs-mount.service [Service] ExecStart=... [Install] WantedBy=multi-user.target In nfs-mount.service: In nfs-quota.service: [Unit] Description=Optional quota service for NFS BindTo=nfs.service [Service] ExecStart=... [Install] WantedBy=nfs.service Then if you run "systemctl enable nfs.service" the first two services will be started at next boot. If either one of them goes down the other one will too. If you on top of that run "systemctl enable nfs-quota.service", then this one will be started at boot too. If it goes down the other ones don't care, but if you start nfs.service all three will be started. Which is a pretty good behaviour. Of course, these service names are all made up, but I believe the actual existing NFS services are not unlike these three examples. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
JB gmail.com> writes: > > Michal Schmidt redhat.com> writes: > > > ... > > > 2. > > > main-service-2.service: > > > [Unit] > > > Description=Main service 2 > > > After= ... > > > ... > > > [Service] > > > Type=forking<-- any other type too ? > > > ExecStartPre= exec /etc/init.d/sub-service-1 > > > ExecStartPre= exec /etc/init.d/sub-service-2 > > > ExecStart= /usr/sbin/some-service > > > ExecStartPost= > > > ExecStartPost= > > > ... > > > Are there any restrictions on those Pre (and Post) commands ? > > > > One limitation was already mentioned somewhere in this thread - these > > commands must not fork off daemons. > > This is interesting. Or perhaps I read too much into your above statement ? > We know already that ExecStartPre must contain a command to be executed. > > > ExecStartPre= exec /etc/init.d/sub-service-1 > Note the 'exec' command, which means "Replace the shell with the given > command." with immediate return. > How does systemd know what's in the "/etc/init.d/sub-service-1" process, to be > able to figure out if any daemon is to be forked off ? > > > ... > > >> Parallelism in systemd happens between multiple units, but never between > > >> ExecStart* commands of one unit. > > >> Requesting parallelism within one unit seems like over-engineering to > > >> me. You can always split your unit to smaller ones if you want > > >> parallelism. > > > ... Regarding your statement on Parallelism. Let's consider these two ExecStartPre with 'exec': Is that still considered sequential execution, or parallel execution and a violation of the previous principle ? Actually, this question has a general ramification, as it applies to any of Pre, regular, and Post sequential execution principle within unit file. What is the meaning and purpose of "serial execution" within systemd ? - mechanical submit for execution, wait for return code, iterate - or more involved submit for execution, wait for command (job) completion, presumably to avoid ... parallelism and its potential side effects like any conflicts, races, etc; with return code, iterate JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
