Re: Proposed F19 Feature: systemd features
On 02/02/2013 07:33 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 07:06:12AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 07:03 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 02:08:00AM +, Jóhann B. Guðmundsson wrote: When I meet a maintainer in the project that stated to me I have to talk to my manager first before upgrading his component that rings alarm bells to me, That gives me the feel that they are maintaining their components as a part of their job not because they want to scratch an itch and want to! There is a third reason for maintaining a component: it is a dependency for another component the packager maintains. This is applicable for _all_ packagers, be they from Red Hat or the community. You either conveniently omitted this reason to make an argument or never thought of it, in which case I respectfully ask you to butt out of this thread because you do not know what you are talking about. Oh in my case it was an primary component no dependency that Red Hat maintainer could not update until he got approval but for the You generalized one specific case to _all components of all Red Hat maintainers_. When I rejected that generalization, you are counteracting by claiming that my argument does not apply for that one _specific_ case. Sorry, but that is a faulty reasoning. No i did not generalized one specific case to _all components of all Red Hat I know alot of Red Hat's employees that participate in the project by their own free will and at their own free time. I also know alot of Red Hat's employees that are working in the project that go on and above their duty doing so. And I also know yes granted an single individual that said he could not update his component in the project which he maintained without asking his boss before doing so which raises a whole bunch of questions but we have saying here in Icelandic Sjaldan er ein báran stök sake of your argument and concision let's lower my IQ to an rock ( which I do believe is 20 ) and say I dont have freaking flying idea what I'm talking about. Is this sarcasm or a personal attack? I am not quite sure... sarcasm if any would being guilty of being stupid that would be me would it not? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Sat, Feb 02, 2013 at 07:24:39AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 07:12 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 06:20:18AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 05:57 AM, Chris Adams wrote: If you can't handle that, then Fedora development might not be the right place for you. Get the fuck out before you get in my business. If you want to test me here I am deal with it because I wont back down not after the treatment he has given me! You have absolutely no idea what I have sacrificed for the project and if you want to head down that road son realize I dont bark I bite! Chris Adams care to explain to me what the fuck you have been doing all those years other than trying to play the tough boy? Let's put your contribution to the test! Congratulations! You have proved your merit once again. That personal attack was uncalled for. Was it? Yes, it was. He threaten me I responded. Really? AFAICS you have been the only one threatening in this thread (I dont bark I bite). The position and do correct me if I'm wrong for Adam did not exist before he got hired, and he was not even hired from the community. Ah, so your grievance is that Red Hat has hired Adam but not you. Care to share the link to his position at that time. Feel free to use the internet archive let's analyze what stood in it, I do not see how this could have any relevance to the matter. Prove me wrong and I shall be the first to admit my wrong doing, my mistake and apologize to all parties involved. Since Chris' sentence If you can't handle that, then Fedora development might not be the right place for you. can hardly be considered an attack (or a threat), I hereby claim that you are wrong and your harsh response to him was uncalled for. D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/02/2013 07:57 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 07:24:39AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 07:12 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 06:20:18AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 05:57 AM, Chris Adams wrote: If you can't handle that, then Fedora development might not be the right place for you. Get the fuck out before you get in my business. If you want to test me here I am deal with it because I wont back down not after the treatment he has given me! You have absolutely no idea what I have sacrificed for the project and if you want to head down that road son realize I dont bark I bite! Chris Adams care to explain to me what the fuck you have been doing all those years other than trying to play the tough boy? Let's put your contribution to the test! Congratulations! You have proved your merit once again. That personal attack was uncalled for. Was it? Yes, it was. He threaten me I responded. Really? AFAICS you have been the only one threatening in this thread (I dont bark I bite). Back me up to an wall I certainly will The position and do correct me if I'm wrong for Adam did not exist before he got hired, and he was not even hired from the community. Ah, so your grievance is that Red Hat has hired Adam but not you. God no losing James yes cry myself to a huge pillow every night Care to share the link to his position at that time. Feel free to use the internet archive let's analyze what stood in it, I do not see how this could have any relevance to the matter. Prove me wrong and I shall be the first to admit my wrong doing, my mistake and apologize to all parties involved. Since Chris' sentence If you can't handle that, then Fedora development might not be the right place for you. can hardly be considered an attack (or a threat), I hereby claim that you are wrong and your harsh response to him was uncalled for. I guess that's all in the hands of the beholder JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Sat, Feb 02, 2013 at 07:43:48AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 07:33 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 07:06:12AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 07:03 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 02:08:00AM +, Jóhann B. Guðmundsson wrote: When I meet a maintainer in the project that stated to me I have to talk to my manager first before upgrading his component that rings alarm bells to me, That gives me the feel that they are maintaining their components as a part of their job not because they want to scratch an itch and want to! There is a third reason for maintaining a component: it is a dependency for another component the packager maintains. This is applicable for _all_ packagers, be they from Red Hat or the community. You either conveniently omitted this reason to make an argument or never thought of it, in which case I respectfully ask you to butt out of this thread because you do not know what you are talking about. Oh in my case it was an primary component no dependency that Red Hat maintainer could not update until he got approval but for the You generalized one specific case to _all components of all Red Hat maintainers_. When I rejected that generalization, you are counteracting by claiming that my argument does not apply for that one _specific_ case. Sorry, but that is a faulty reasoning. No i did not generalized one specific case to _all components of all Red Hat Yes, you did. Or how else do you interpret That gives me the feel that they are maintaining their components as a part of their job not because they want to scratch an itch and want to! And I also know yes granted an single individual that said he could not update his component in the project which he maintained without asking his boss before doing so which raises a whole bunch of questions Sure. For example: Is he a new packager and does not realize that updating a component in Fedora does not involve the same process as in RHEL? or Is the update potentially dangerous and he wants to consult with someone more experienced? (We still do not know who the packager was and which component it was.) D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Sat, Feb 02, 2013 at 08:19:29AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 07:57 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 07:24:39AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 07:12 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 06:20:18AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 05:57 AM, Chris Adams wrote: If you can't handle that, then Fedora development might not be the right place for you. Get the fuck out before you get in my business. If you want to test me here I am deal with it because I wont back down not after the treatment he has given me! You have absolutely no idea what I have sacrificed for the project and if you want to head down that road son realize I dont bark I bite! Chris Adams care to explain to me what the fuck you have been doing all those years other than trying to play the tough boy? Let's put your contribution to the test! Congratulations! You have proved your merit once again. That personal attack was uncalled for. Was it? Yes, it was. He threaten me I responded. Really? AFAICS you have been the only one threatening in this thread (I dont bark I bite). Back me up to an wall I certainly will But he did not propose to do anything of that sort. So this is not an argument. Care to share the link to his position at that time. Feel free to use the internet archive let's analyze what stood in it, I do not see how this could have any relevance to the matter. Prove me wrong and I shall be the first to admit my wrong doing, my mistake and apologize to all parties involved. Since Chris' sentence If you can't handle that, then Fedora development might not be the right place for you. can hardly be considered an attack (or a threat), I hereby claim that you are wrong and your harsh response to him was uncalled for. I guess that's all in the hands of the beholder If you really see that sentence as a threat to you, in my opinion you should seek a psychiatrist. D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Le samedi 02 février 2013 à 06:29 +, Jóhann B. Guðmundsson a écrit : On 02/02/2013 02:39 AM, Reindl Harald wrote: Am 02.02.2013 03:08, schrieb Jóhann B. Guðmundsson: When I meet a maintainer in the project that stated to me I have to talk to my manager first before upgrading his component that rings alarm bells to me, That gives me the feel that they are maintaining their components as a part of their job not because they want to scratch an itch and want to! jesus christ be gladful that companies like red hat are paying people for development of free software and if someone get paied for a job soemtimes he has to speak with his managers It's not like RH gives other company's the alternative to sponsor the project now does it Depend on what you mean by sponsorship. If that's : paying someone to work on it, there is. See people from puppetlabs, for the easiest to find example If that's : paying for infrastructure, there is too. There is the mirrors, there is the servers, check the details with fedora-infrastructure, as I do not have the details right there. Now, there is some areas where this could be more open such as security and legal, but that's highly sensitive topics due to the confidential nature of some of the work ( ie, not so easy to open ). And unless someone volunteer to do anything first, we will not be able to open more ( and trust me, just opening is not enough, you have to fix the process as people try to integrate, or that's just useless ). Now, if you have a suggestion on who want to sponsor fedora and why they couldn't, I would gladly discuss and try to see what could be improved. I dont know about your parts but I grew up in environment where slavery is not accepted your definition of slavery is completly broken If an RH employee is maintainer is maintaining a component in the distribution and doing so because it's an part of his job but not because he want's to I call that slavery especially when he has to go to his manager to ask him if he is allowed to upgrade the component it to it's latest release. You can call it slavery as much as you want, that doesn't mean it is. Cf wikipedia : Slavery is a system under which people are treated as property to be bought and sold, and are forced to work. Slaves can be held against their will from the time of their capture, purchase or birth, and deprived of the right to leave, to refuse to work, or to demand compensation. Comparing someone asking for advice for whatever reason to slavery is insult to those that died and still die today in much more horrible conditions that sending a email to someone to see if that's ok. Yes first hand I have experienced an RH employee that has said I need to speak to my manager before he could upgrade the component he was maintaining to the latest release and to me that's pretty fucking alarming Maybe the employee was just too shy or just wanted to check with someone with more experience about the distro ( or someone with a broader view ). Or maybe the employee just didn't know he could do it, or the impact, not all people working on RH are experienced packagers. Without any specific, your example are just unusable to anything but speculation. We try to assume good faith in each others communication, and I hope you do as well. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/02/2013 08:31 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 07:43:48AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 07:33 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 07:06:12AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 07:03 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 02:08:00AM +, Jóhann B. Guðmundsson wrote: When I meet a maintainer in the project that stated to me I have to talk to my manager first before upgrading his component that rings alarm bells to me, That gives me the feel that they are maintaining their components as a part of their job not because they want to scratch an itch and want to! There is a third reason for maintaining a component: it is a dependency for another component the packager maintains. This is applicable for _all_ packagers, be they from Red Hat or the community. You either conveniently omitted this reason to make an argument or never thought of it, in which case I respectfully ask you to butt out of this thread because you do not know what you are talking about. Oh in my case it was an primary component no dependency that Red Hat maintainer could not update until he got approval but for the You generalized one specific case to _all components of all Red Hat maintainers_. When I rejected that generalization, you are counteracting by claiming that my argument does not apply for that one _specific_ case. Sorry, but that is a faulty reasoning. No i did not generalized one specific case to _all components of all Red Hat Yes, you did. Or how else do you interpret That gives me the feel that they are maintaining their components as a part of their job not because they want to scratch an itch and want to! That there exist individual that are maintaining components in Fedora not because they wan to but more because they have to as a part of their job. Something I had suspected for quite sometime for some time but in my case I was given the proof. And I also know yes granted an single individual that said he could not update his component in the project which he maintained without asking his boss before doing so which raises a whole bunch of questions Sure. For example: Is he a new packager and does not realize that updating a component in Fedora does not involve the same process as in RHEL? or Is the update potentially dangerous and he wants to consult with someone more experienced? (We still do not know who the packager was and which component it was.) I'm not going to reveal who that was. I am a lot of things but that guy I am not. What he told me in private mail is between me and him so keep fishing... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/02/2013 08:41 AM, Michael Scherer wrote: Le samedi 02 février 2013 à 06:29 +, Jóhann B. Guðmundsson a écrit : On 02/02/2013 02:39 AM, Reindl Harald wrote: Am 02.02.2013 03:08, schrieb Jóhann B. Guðmundsson: When I meet a maintainer in the project that stated to me I have to talk to my manager first before upgrading his component that rings alarm bells to me, That gives me the feel that they are maintaining their components as a part of their job not because they want to scratch an itch and want to! jesus christ be gladful that companies like red hat are paying people for development of free software and if someone get paied for a job soemtimes he has to speak with his managers It's not like RH gives other company's the alternative to sponsor the project now does it Depend on what you mean by sponsorship. If that's : paying someone to work on it, there is. See people from puppetlabs, for the easiest to find example If that's : paying for infrastructure, there is too. There is the mirrors, there is the servers, check the details with fedora-infrastructure, as I do not have the details right there. You even cant do that. Now, there is some areas where this could be more open such as security and legal, but that's highly sensitive topics due to the confidential nature of some of the work ( ie, not so easy to open ). And unless someone volunteer to do anything first, we will not be able to open more ( and trust me, just opening is not enough, you have to fix the process as people try to integrate, or that's just useless ). Now, if you have a suggestion on who want to sponsor fedora and why they couldn't, I would gladly discuss and try to see what could be improved. Trademark issues Fedora is trademarked and owned by FH I dont know about your parts but I grew up in environment where slavery is not accepted your definition of slavery is completly broken If an RH employee is maintainer is maintaining a component in the distribution and doing so because it's an part of his job but not because he want's to I call that slavery especially when he has to go to his manager to ask him if he is allowed to upgrade the component it to it's latest release. You can call it slavery as much as you want, that doesn't mean it is. Cf wikipedia : Slavery is a system under which people are treated as property to be bought and sold, and are forced to work. Slaves can be held against their will from the time of their capture, purchase or birth, and deprived of the right to leave, to refuse to work, or to demand compensation. Comparing someone asking for advice for whatever reason to slavery is insult to those that died and still die today in much more horrible conditions that sending a email to someone to see if that's ok. For that I apologies since I took slavery as forcing individual to do something he wanted not to do, Yes first hand I have experienced an RH employee that has said I need to speak to my manager before he could upgrade the component he was maintaining to the latest release and to me that's pretty fucking alarming Maybe the employee was just too shy or just wanted to check with someone with more experience about the distro ( or someone with a broader view ). Or maybe the employee just didn't know he could do it, or the impact, not all people working on RH are experienced packagers. Without any specific, your example are just unusable to anything but speculation. I cant reveal who it was without him being put in awkward situation We try to assume good faith in each others communication, and I hope you do as well. No based on experience it has turned quite the opposed path for me. I assume the worst in people and procedures that way I no longer get disappointed. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/02/2013 08:38 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 08:19:29AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 07:57 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 07:24:39AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 07:12 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 06:20:18AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 05:57 AM, Chris Adams wrote: If you can't handle that, then Fedora development might not be the right place for you. Get the fuck out before you get in my business. If you want to test me here I am deal with it because I wont back down not after the treatment he has given me! You have absolutely no idea what I have sacrificed for the project and if you want to head down that road son realize I dont bark I bite! Chris Adams care to explain to me what the fuck you have been doing all those years other than trying to play the tough boy? Let's put your contribution to the test! Congratulations! You have proved your merit once again. That personal attack was uncalled for. Was it? Yes, it was. He threaten me I responded. Really? AFAICS you have been the only one threatening in this thread (I dont bark I bite). Back me up to an wall I certainly will But he did not propose to do anything of that sort. So this is not an argument. Care to share the link to his position at that time. Feel free to use the internet archive let's analyze what stood in it, I do not see how this could have any relevance to the matter. Prove me wrong and I shall be the first to admit my wrong doing, my mistake and apologize to all parties involved. Since Chris' sentence If you can't handle that, then Fedora development might not be the right place for you. can hardly be considered an attack (or a threat), I hereby claim that you are wrong and your harsh response to him was uncalled for. I guess that's all in the hands of the beholder If you really see that sentence as a threat to you, in my opinion you should seek a psychiatrist. I guess the chances of me finding my sanity are as much as openoffice and libreoffice getting migrated so I guess from that point we are equally screwed ;) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Hi On Sat, Feb 2, 2013 at 1:32 AM, Jóhann B. Guðmundsson wrote: Then Rahul how about a wiki page about all the RH employees that are maintaining components in the distribution that have to vs those that want to. If you want to, go ahead. Noone is stopping you. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
This thread is over. I'd like to ask everyone to take a few minutes to re-read: http://fedoraproject.org/code-of-conduct and get some away time from the discussion and think about things and how to approach discussions more constructively. Thanks, kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/01/2013 04:21 AM, David Tardon wrote: On Thu, Jan 31, 2013 at 11:46:33PM +, Jóhann B. Guðmundsson wrote: And in the midst of me doing this research I have to have Bill Notting butting into my work ( and I know what that means ), trying to come up with his own list instead of simply asking me for the one I was looking at [¹] and consulting with me where I was with my findings and now he can just have at it and finish do it his own way., create those units and prep the necessary patches to the packages etc. since he's such an expert on the matter. If you stop behaving like a child, maybe people will start to take you seriously. And Bills behavior towards me has been so civilized through out the years. If he leaves me and my work alone and general stays away from me maybe I will... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Fri, 2013-02-01 at 08:44 +, Jóhann B. Guðmundsson wrote: On 02/01/2013 04:21 AM, David Tardon wrote: On Thu, Jan 31, 2013 at 11:46:33PM +, Jóhann B. Guðmundsson wrote: And in the midst of me doing this research I have to have Bill Notting butting into my work ( and I know what that means ), trying to come up with his own list instead of simply asking me for the one I was looking at [¹] and consulting with me where I was with my findings and now he can just have at it and finish do it his own way., create those units and prep the necessary patches to the packages etc. since he's such an expert on the matter. If you stop behaving like a child, maybe people will start to take you seriously. And Bills behavior towards me has been so civilized through out the years. If he leaves me and my work alone and general stays away from me maybe I will... Well, no, that's not going to happen. Fedora's a collaborative project. If you're making significant changes to core packages - which you would be, if you start porting things from crond to systemd timers - other people who work on the core system are going to take an interest. Like Bill. That's kind of how things work around here. You don't just get to stake off some territory and say MINE MINE MINE NO-ONE COMES IN HERE. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Hi On Fri, Feb 1, 2013 at 3:44 AM, Jóhann B. Guðmundsson And Bills behavior towards me has been so civilized through out the years. If he leaves me and my work alone and general stays away from me maybe I will... You are just proving David Tardon's point here. You have no monopoly on ideas. Just because you have a proposal doesn't mean everyone else who is interested has to stay out of it. Our method of doing things in Fedora is to actively sharing the space we work on. That is the civilized way to handle it. You seem to want total control over your chosen area of participation. We simply don't work that way. Bill Nottingham has a lot of relevant expertise in this area and his opinions are atleast as welcome as yours. You are free to disagree with him but you cannot take stake any ownership. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/01/2013 07:14 PM, Rahul Sundaram wrote: Hi On Fri, Feb 1, 2013 at 3:44 AM, Jóhann B. Guðmundsson And Bills behavior towards me has been so civilized through out the years. If he leaves me and my work alone and general stays away from me maybe I will... You are just proving David Tardon's point here. You have no monopoly on ideas. Just because you have a proposal doesn't mean everyone else who is interested has to stay out of it. Our method of doing things in Fedora is to actively sharing the space we work on. That is the civilized way to handle it. You seem to want total control over your chosen area of participation. We simply don't work that way. Bill Nottingham has a lot of relevant expertise in this area and his opinions are atleast as welcome as yours. You are free to disagree with him but you cannot take stake any ownership. I dont mind everyone else opinions and criticism or help staying in and out of my works and what not except Bill's after the treatment he has given me over the years. I personally would have preferred people waiting and giving me the chance to go through all the cron jobs and make my presentation and findings to fesco then afterwards discuss the merits of making the switch for the cron jobs of those 38 components that might warrant conversion. But since it matters so much to you have at it. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Fri, Feb 01, 2013 at 07:28:56PM +, Jóhann B. Guðmundsson wrote: I personally would have preferred people waiting and giving me the chance to go through all the cron jobs and make my presentation and findings to fesco then afterwards discuss the merits of making the switch for the cron jobs of those 38 components that might warrant conversion. I really don't understand how it hurts to have multiple people look at the information. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Hi On Fri, Feb 1, 2013 at 2:28 PM, Jóhann B. Guðmundsson wrote: I dont mind everyone else opinions and criticism or help staying in and out of my works and what not except Bill's after the treatment he has given me over the years. I have no idea what treatment you are talking about. State the problems specifically, resolve it or disagree and get over it. If you need help with that, talk to https://fedoraproject.org/wiki/Community_working_group Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/01/2013 05:16 PM, Adam Williamson wrote: On Fri, 2013-02-01 at 08:44 +, Jóhann B. Guðmundsson wrote: On 02/01/2013 04:21 AM, David Tardon wrote: On Thu, Jan 31, 2013 at 11:46:33PM +, Jóhann B. Guðmundsson wrote: And in the midst of me doing this research I have to have Bill Notting butting into my work ( and I know what that means ), trying to come up with his own list instead of simply asking me for the one I was looking at [¹] and consulting with me where I was with my findings and now he can just have at it and finish do it his own way., create those units and prep the necessary patches to the packages etc. since he's such an expert on the matter. If you stop behaving like a child, maybe people will start to take you seriously. And Bills behavior towards me has been so civilized through out the years. If he leaves me and my work alone and general stays away from me maybe I will... Well, no, that's not going to happen. Fedora's a collaborative project. If you're making significant changes to core packages - which you would be, if you start porting things from crond to systemd timers - other people who work on the core system are going to take an interest. Like Bill. That's kind of how things work around here. You don't just get to stake off some territory and say MINE MINE MINE NO-ONE COMES IN HERE. Oh and you where so collaborate Adam when you decided on your own deleting my tickets in the QA trac instance that A) exist because of me and B) I was using to keep track on my work within the QA community. It did not cross for a second for you to send me a line or ping me on irc and ask me if it was ok. Ńor did Stephen or Toshio when they filed an request that I was granted packaging privileges without them as much as asking me or giving me heads up before doing that! And you dare talking to me about mine mine when I want one man, one man out of thousand of contributors to leave me alone and stay out of my business! JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/01/2013 07:35 PM, Matthew Miller wrote: On Fri, Feb 01, 2013 at 07:28:56PM +, Jóhann B. Guðmundsson wrote: I personally would have preferred people waiting and giving me the chance to go through all the cron jobs and make my presentation and findings to fesco then afterwards discuss the merits of making the switch for the cron jobs of those 38 components that might warrant conversion. I really don't understand how it hurts to have multiple people look at the information. The plan was to gather that information and give people something to actually look at. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/01/2013 07:41 PM, Rahul Sundaram wrote: Hi On Fri, Feb 1, 2013 at 2:28 PM, Jóhann B. Guðmundsson wrote: I dont mind everyone else opinions and criticism or help staying in and out of my works and what not except Bill's after the treatment he has given me over the years. I have no idea what treatment you are talking about. State the problems specifically, resolve it or disagree and get over it. If you need help with that, talk to https://fedoraproject.org/wiki/Community_working_grou https://fedoraproject.org/wiki/Community_working_group I dont know if that group actually is active and on one of the group when it got formed it was proposed that Red Hat employees would get *special* treatment within the project and the CWG would speak with their *managers* so much for that... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Fri, Feb 1, 2013 at 1:38 PM, Jóhann B. Guðmundsson johan...@gmail.comwrote: On 02/01/2013 05:16 PM, Adam Williamson wrote: On Fri, 2013-02-01 at 08:44 +, Jóhann B. Guðmundsson wrote: On 02/01/2013 04:21 AM, David Tardon wrote: On Thu, Jan 31, 2013 at 11:46:33PM +, Jóhann B. Guðmundsson wrote: And in the midst of me doing this research I have to have Bill Notting butting into my work ( and I know what that means ), trying to come up with his own list instead of simply asking me for the one I was looking at [¹] and consulting with me where I was with my findings and now he can just have at it and finish do it his own way., create those units and prep the necessary patches to the packages etc. since he's such an expert on the matter. If you stop behaving like a child, maybe people will start to take you seriously. And Bills behavior towards me has been so civilized through out the years. If he leaves me and my work alone and general stays away from me maybe I will... Well, no, that's not going to happen. Fedora's a collaborative project. If you're making significant changes to core packages - which you would be, if you start porting things from crond to systemd timers - other people who work on the core system are going to take an interest. Like Bill. That's kind of how things work around here. You don't just get to stake off some territory and say MINE MINE MINE NO-ONE COMES IN HERE. Oh and you where so collaborate Adam when you decided on your own deleting my tickets in the QA trac instance that A) exist because of me and B) I was using to keep track on my work within the QA community. It did not cross for a second for you to send me a line or ping me on irc and ask me if it was ok. Ńor did Stephen or Toshio when they filed an request that I was granted packaging privileges without them as much as asking me or giving me heads up before doing that! And you dare talking to me about mine mine when I want one man, one man out of thousand of contributors to leave me alone and stay out of my business! I count at least 4, in this thread alone. I say this to my kids regularly: Your perception of their behaviour is not, by itself, always a good rationale for yours. Sometimes, in a community, when you work on other people's stuff, they might also want to work on it or have input into how it's done. That's just the way it is. Since no one person writes all the code or maintains all the packages, it's *all* other people's stuff. -J JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Fri, Feb 01, 2013 at 07:39:48PM +, Jóhann B. Guðmundsson wrote: I really don't understand how it hurts to have multiple people look at the information. The plan was to gather that information and give people something to actually look at. So... more information is good, right? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Hi On Fri, Feb 1, 2013 at 2:42 PM, Jóhann B. Guðmundsson wrote: I dont know if that group actually is active and on one of the group when it got formed it was proposed that Red Hat employees would get *special* treatment within the project and the CWG would speak with their *managers* so much for that... Again, your complaint here seems very vague. Please provide references. If there is a complaint about someone working in a company that itself is involved in the project, it is not unexpected it will get escalated to their manager to help resolve it. Since you are a volunteer, that will not be the case. How is this special treatment? What else did you expect? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/01/2013 08:04 PM, Rahul Sundaram wrote: Again, your complaint here seems very vague. Please provide references. If there is a complaint about someone working in a company that itself is involved in the project, it is not unexpected it will get escalated to their manager to help resolve it. Since you are a volunteer, that will not be the case. How is this special treatment? What else did you expect? You can go yourself through the community working log meetings to find my reference. I would expect RH employee ( and other corporation's employee ) sitting at the same table as their community brethren's and not having to worries about their job for their actions within the community. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Hi On Fri, Feb 1, 2013 at 3:23 PM, Jóhann B. Guðmundsson You can go yourself through the community working log meetings to find my reference. I would expect RH employee ( and other corporation's employee ) sitting at the same table as their community brethren's and not having to worries about their job for their actions within the community. If their work in the community is part of their job, then we cannot really separate the two. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Jóhann B. Guðmundsson (johan...@gmail.com) said: On 01/31/2013 03:51 PM, Bill Nottingham wrote: I would be tempted to say: Anything running at a core system level where a dependence on a separate cron daemon may be unwanted (or a bad idea) should be migrated, and nothing else for now until we have a clearer perspective on the future. Given that list that would be migration of: mcelog mdadm ovirt-node prelink (?) tmpwatch vdsm-* But I'm open to other ideas. Am I supposed to assume you are working migrating this? I was asked people to take a look at what the functionality can do, what it may mean to migrate, and what we want to offer to our users, in the short and in the long term. The thing about migrating SysV services is that we didn't have to at the start, and yet they'd still work, in systemd, without change. (For the most part). And admins could use the old tools adminms were used to in SysV land (/sbin/service, chkconfig, etc) with systemd, and they'd work and give them consistent output for both the native services, and the ones they hadn't got around to migrating yet. Here, while systemd has basically subsumed the functionality of cron (minus user jobs), it hasn't subsumed any of the infrastructure - there's no compat. In any case, to look at 'we have this functionality... now what': 1) migrate some cron jobs Then, system scheduled tasks are in two places. Admins can learn and cope, and have to go looking in multiple places and remember which tools to deal with which scheduled task type. It's not ideal. And if we do so, it's good to have some clear criteria to help admins decide where to find what they're looking for. You started working here - you suggested 'ones that come with daemons/services', I looked, and thought perhaps 'ones that live at a level below everything else, including the ones below daemons and services'. It's just different ideas as to where to draw the line. But it's still not a great interface to have users end up in - two infrastructures running in parallel. 2) migrate all This is cleaner, inasmuch as we can tell everyone hey, everything is over here now. But it's still a full break of interfaces and paradigms, and it easily devolves to #1 as soon as something doesn't get done, or new stuff is added. (After all, we can't remove support for cron-format jobs.) 3) introduce compatibility The cron and at interfaces aren't complex at all. It shouldn't be too hard to have a generator that reads crontab and cron.*, and the at queue, and creates the approprate timer files for systemd, in the same way that the fstab sysv generators run. We could even have new versions of the crontab and at commands that do the right thing. That's extra work that would need to be done, and we would have to actually be obsoleting cron here (can't have two things running the same jobs), so it's obviously not F19 material. We'd also need a mechanism for user jobs. But if this is where we want the system to end up, this is what we start working towards and writing code for. Once that lands, transitioning can actually be done much more smoothyl with less user disruption, and having different jobs in different formats doesn't hurt nearly as much. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Fri, Feb 1, 2013 at 10:36 PM, Bill Nottingham nott...@redhat.com wrote:
In any case, to look at 'we have this functionality... now what':
For the sake of completeness, the default is 0) Avoid all the
arguments and work, and continue using existing files.
Is there actually a noticeable benefit in migrating? We will help
Linux win neither on the desktop nor in the cloud by tinkering with
something admins are not supposed to touch :)
So far I can see:
A. Disk space usage in minimal systems has been mentioned: but cronie
is 200 kB, that's almost a waste of breath.
B. Cron's facility to submit jobs by unprivileged users to a daemon
running as root is a possible privilege escalation path; removing it
from the minimal (or even default) installation would remove a
possible risk (as long as we don't introduce an equivalent one as a
replacement.)
C. If we remove cron, is there anything left that needs the local MTA?
Removing the local MTA would be similar to removing cron, only more
so.
B. and C. would be somewhat interesting - if and only if we did the
next step of making cron/MTA optional and not installed by default.
Is that reasonable and feasible?
3) introduce compatibility
The cron and at interfaces aren't complex at all. It shouldn't be
too hard to have a generator that reads crontab and cron.*, and
the at queue, and creates the approprate timer files for systemd,
in the same way that the fstab sysv generators run. We could
even have new versions of the crontab and at commands that do the
right thing.
That's extra work that would need to be done, and we would
have to actually be obsoleting cron here (can't have two things
running the same jobs),
Technically it's not necessary to obsolete cron as a tool/daemon (and
reimplement all of the functionality); systemd could be handling
/etc/cron.{hourly,daily,monthly,weekly}, leaving the full syntax of
/etc/{ana,}crontab and per-user task lists edited via crontab(1)
(including root's, which is distinct from /etc/crontab) to cronie.
Unfortunately there is an ugly half-way case: /etc/cron.d.
I'd be very hesitant about moving per-user jobs to systemd - for
security reasons the mechanism to accept user's job submission really
needs to be distinct from PID 1, so structurally it can't end up that
different from simply including cronie into systemd; an independent
cronie reimplementation would just be asking for privilege
escalations, with zero user benefit.
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 1 February 2013 15:57, Miloslav Trmač m...@volny.cz wrote: On Fri, Feb 1, 2013 at 10:36 PM, Bill Nottingham nott...@redhat.com wrote: In any case, to look at 'we have this functionality... now what': For the sake of completeness, the default is 0) Avoid all the arguments and work, and continue using existing files. Is there actually a noticeable benefit in migrating? We will help Linux win neither on the desktop nor in the cloud by tinkering with something admins are not supposed to touch :) So far I can see: A. Disk space usage in minimal systems has been mentioned: but cronie is 200 kB, that's almost a waste of breath. B. Cron's facility to submit jobs by unprivileged users to a daemon running as root is a possible privilege escalation path; removing it from the minimal (or even default) installation would remove a possible risk (as long as we don't introduce an equivalent one as a replacement.) C. If we remove cron, is there anything left that needs the local MTA? Removing the local MTA would be similar to removing cron, only more so. I expect that in that case, systemd would expand until it became an MTA .. whether or not the main developers wanted it to :). Every program attempts to expand until it can send mail. Those programs which cannot so expand are replaced by ones which can. [misquoted from Zawinski] -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/01/2013 08:32 PM, Rahul Sundaram wrote: Hi On Fri, Feb 1, 2013 at 3:23 PM, Jóhann B. Guðmundsson You can go yourself through the community working log meetings to find my reference. I would expect RH employee ( and other corporation's employee ) sitting at the same table as their community brethren's and not having to worries about their job for their actions within the community. If their work in the community is part of their job, then we cannot really separate the two. I know few RH employees who would beg the differ, many of which go above and beyond their corporate duties but I'll remember your remarks. It's good to know there exist that corporate line... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/01/2013 11:14 PM, Stephen John Smoogen wrote: On 1 February 2013 15:57, Miloslav Trmač m...@volny.cz wrote: On Fri, Feb 1, 2013 at 10:36 PM, Bill Nottingham nott...@redhat.com wrote: In any case, to look at 'we have this functionality... now what': For the sake of completeness, the default is 0) Avoid all the arguments and work, and continue using existing files. Is there actually a noticeable benefit in migrating? We will help Linux win neither on the desktop nor in the cloud by tinkering with something admins are not supposed to touch :) So far I can see: A. Disk space usage in minimal systems has been mentioned: but cronie is 200 kB, that's almost a waste of breath. B. Cron's facility to submit jobs by unprivileged users to a daemon running as root is a possible privilege escalation path; removing it from the minimal (or even default) installation would remove a possible risk (as long as we don't introduce an equivalent one as a replacement.) C. If we remove cron, is there anything left that needs the local MTA? Removing the local MTA would be similar to removing cron, only more so. I expect that in that case, systemd would expand until it became an MTA .. whether or not the main developers wanted it to :). Every program attempts to expand until it can send mail. Those programs which cannot so expand are replaced by ones which can. [misquoted from Zawinski] When it does every current traditional monitoring system become obsolete but the resistance to venture into the inevitable exist upstream.. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Fri, 2013-02-01 at 19:38 +, Jóhann B. Guðmundsson wrote: On 02/01/2013 05:16 PM, Adam Williamson wrote: On Fri, 2013-02-01 at 08:44 +, Jóhann B. Guðmundsson wrote: On 02/01/2013 04:21 AM, David Tardon wrote: On Thu, Jan 31, 2013 at 11:46:33PM +, Jóhann B. Guðmundsson wrote: And in the midst of me doing this research I have to have Bill Notting butting into my work ( and I know what that means ), trying to come up with his own list instead of simply asking me for the one I was looking at [¹] and consulting with me where I was with my findings and now he can just have at it and finish do it his own way., create those units and prep the necessary patches to the packages etc. since he's such an expert on the matter. If you stop behaving like a child, maybe people will start to take you seriously. And Bills behavior towards me has been so civilized through out the years. If he leaves me and my work alone and general stays away from me maybe I will... Well, no, that's not going to happen. Fedora's a collaborative project. If you're making significant changes to core packages - which you would be, if you start porting things from crond to systemd timers - other people who work on the core system are going to take an interest. Like Bill. That's kind of how things work around here. You don't just get to stake off some territory and say MINE MINE MINE NO-ONE COMES IN HERE. Oh and you where so collaborate Adam when you decided on your own deleting my tickets in the QA trac instance that A) exist because of me and B) I was using to keep track on my work within the QA community. It did not cross for a second for you to send me a line or ping me on irc and ask me if it was ok. I didn't 'delete' anything. I *closed* some tickets that had seen no activity for two years and ten months, as part of a general effort to keep trac focused on current and active tasks. The tickets are still there and you could re-open them if you choose. This is roughly analogous to the EOL bugzilla closures we do with each release. When you contacted me about this I did not tell you to butt out and leave my area of expertise alone, we had a discussion about it. Collaboratively. And you dare talking to me about mine mine when I want one man, one man out of thousand of contributors to leave me alone and stay out of my business! There it is again: my business. I'm not sure how you consider this your business. This feature page: https://fedoraproject.org/wiki/Features/SystemdCalendarTimers lists Lennart as the feature owner. It does not list you anywhere. It does not in any way cover the question of how many, if any, cron jobs we should convert into systemd timer units: this is clearly beyond the feature's scope. There is no otherfeature that *does* cover that work, so far as I am aware. You are not the owner of the systemd package. You are not the owner of the cronie package. You are not the owner of any of the packages that would be candidates for conversion. So how exactly is the conversion to timer units your business? Your claim doesn't appear to be staked in any way anyone else can see. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/02/2013 01:16 AM, Adam Williamson wrote: On Fri, 2013-02-01 at 19:38 +, Jóhann B. Guðmundsson wrote: On 02/01/2013 05:16 PM, Adam Williamson wrote: On Fri, 2013-02-01 at 08:44 +, Jóhann B. Guðmundsson wrote: On 02/01/2013 04:21 AM, David Tardon wrote: On Thu, Jan 31, 2013 at 11:46:33PM +, Jóhann B. Guðmundsson wrote: And in the midst of me doing this research I have to have Bill Notting butting into my work ( and I know what that means ), trying to come up with his own list instead of simply asking me for the one I was looking at [¹] and consulting with me where I was with my findings and now he can just have at it and finish do it his own way., create those units and prep the necessary patches to the packages etc. since he's such an expert on the matter. If you stop behaving like a child, maybe people will start to take you seriously. And Bills behavior towards me has been so civilized through out the years. If he leaves me and my work alone and general stays away from me maybe I will... Well, no, that's not going to happen. Fedora's a collaborative project. If you're making significant changes to core packages - which you would be, if you start porting things from crond to systemd timers - other people who work on the core system are going to take an interest. Like Bill. That's kind of how things work around here. You don't just get to stake off some territory and say MINE MINE MINE NO-ONE COMES IN HERE. Oh and you where so collaborate Adam when you decided on your own deleting my tickets in the QA trac instance that A) exist because of me and B) I was using to keep track on my work within the QA community. It did not cross for a second for you to send me a line or ping me on irc and ask me if it was ok. I didn't 'delete' anything. I *closed* some tickets that had seen no activity for two years and ten months, as part of a general effort to keep trac focused on current and active tasks. The tickets are still there and you could re-open them if you choose. This is roughly analogous to the EOL bugzilla closures we do with each release. When you contacted me about this I did not tell you to butt out and leave my area of expertise alone, we had a discussion about it. Collaboratively. And you dare talking to me about mine mine when I want one man, one man out of thousand of contributors to leave me alone and stay out of my business! There it is again: my business. I'm not sure how you consider this your business. This feature page: https://fedoraproject.org/wiki/Features/SystemdCalendarTimers lists Lennart as the feature owner. It does not list you anywhere. It does not in any way cover the question of how many, if any, cron jobs we should convert into systemd timer units: this is clearly beyond the feature's scope. There is no otherfeature that *does* cover that work, so far as I am aware. You are not the owner of the systemd package. You are not the owner of the cronie package. You are not the owner of any of the packages that would be candidates for conversion. So how exactly is the conversion to timer units your business? Your claim doesn't appear to be staked in any way anyone else can see. Feeling happy in the Red Hat position they invented for you in QA. Feeling a big man now? Challenged accepted big man you have in your rein of error effectively killed 2 thriving process in the QA community. Do you really want to head down this road with me? Go ahead big man make my day! JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Sat, Feb 02, 2013 at 01:25:09 +, \Jóhann B. Guðmundsson\ johan...@gmail.com wrote: community. Do you really want to head down this road with me? Go ahead big man make my day! This is not appropriate behavior for a Fedora contributor. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Fri, Feb 01, 2013 at 04:36:20PM -0500, Bill Nottingham wrote: 3) introduce compatibility The cron and at interfaces aren't complex at all. It shouldn't be too hard to have a generator that reads crontab and cron.*, and the at queue, and creates the approprate timer files for systemd, in the same way that the fstab sysv generators run. We could even have new versions of the crontab and at commands that do the right thing. I heart this approach. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Hi On Fri, Feb 1, 2013 at 7:52 PM, Jóhann B. Guðmundsson johan...@gmail.comwrote: I know few RH employees who would beg the differ, many of which go above and beyond their corporate duties but I'll remember your remarks. It's good to know there exist that corporate line... You don't seem to have understood what I said. If a Red Hat employee has Fedora activities as part of their job, then it is not unexpected that feedback about those activities might reach their manager. They might very well have other interests in Fedora which aren't part of their Red Hat role and in that case, it is fine to ask people to direct feedback only to them as an individual. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/02/2013 01:57 AM, Rahul Sundaram wrote: Hi On Fri, Feb 1, 2013 at 7:52 PM, Jóhann B. Guðmundsson johan...@gmail.com mailto:johan...@gmail.com wrote: I know few RH employees who would beg the differ, many of which go above and beyond their corporate duties but I'll remember your remarks. It's good to know there exist that corporate line... You don't seem to have understood what I said. If a Red Hat employee has Fedora activities as part of their job, then it is not unexpected that feedback about those activities might reach their manager. They might very well have other interests in Fedora which aren't part of their Red Hat role and in that case, it is fine to ask people to direct feedback only to them as an individual. You cant have it both ways. Either RH employees are participating in the project by their own free will or not. I have personally meet both sides which has gotten me confused and conflicted. When I meet a maintainer in the project that stated to me I have to talk to my manager first before upgrading his component that rings alarm bells to me, That gives me the feel that they are maintaining their components as a part of their job not because they want to scratch an itch and want to! I dont know about your parts but I grew up in environment where slavery is not accepted. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Hi On Fri, Feb 1, 2013 at 9:08 PM, Jóhann B. Guðmundsson wrote: Either RH employees are participating in the project by their own free will or not. I have personally meet both sides which has gotten me confused and conflicted. Employees can have assigned duties as well as projects of their own interest. If you are confused about which one is what and have a need to know, feel free to ask them. When I meet a maintainer in the project that stated to me I have to talk to my manager first before upgrading his component that rings alarm bells to me, That gives me the feel that they are maintaining their components as a part of their job not because they want to scratch an itch and want to! Why is it cause for alarm that some people in Fedora are getting paid to do something within Fedora? I dont know about your parts but I grew up in environment where slavery is not accepted. This frequent I dont know about your parts sounds quite discriminatory and getting paid to do a job is pretty much the opposite of slavery. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Sat, 2013-02-02 at 01:25 +, Jóhann B. Guðmundsson wrote: Feeling happy in the Red Hat position they invented for you in QA. Feeling a big man now? Challenged accepted big man you have in your rein of error effectively killed 2 thriving process in the QA community. Do you really want to head down this road with me? Go ahead big man make my day! Well, no, not really. We're not having a fight, here. At least, I'm not trying to. I'm trying to discuss process. You appear to think this is a battle for domination, but that's not how it looks from where I'm sitting. I'm sorry if it came up that way, I'm not trying to slap you down or demean you, I think we've just fallen prey to a bit of process confusion here. So, can we back up a bit? I've just read back the whole way through the two threads, and it turns out to be a bit of a mess. I think the problem is different people have different perceptions of what's going on. So in the 01-16 FESCo meeting - right at the end, in open floor - there was a short conversation about cron job conversion: 18:56:15 Viking-Ice on an different subject does it make sense to migrate all those cron scripts to systemd timer units? 18:56:25 mmaslano what? 18:56:25 Viking-Ice all shipped cron scripts I mean 18:56:40 mitr Viking-Ice: what end-user benefit would all that work bring? 18:57:10 * nirik has no opinion on it without looking at it in more detail. 18:57:20 mmaslano Viking-Ice: as a maintainer, I don't plan to do it, because I don't see any user improvement 18:57:37 mmaslano is there any? 18:58:11 nirik lets discuss that proposal after it's had discussion on list or detailed proposal sent to us? 18:58:22 Viking-Ice mitr, fewer packages in install have not looked at it further it's just recent that systemd gained calender support 18:58:40 Viking-Ice for those timer units 18:59:31 Viking-Ice I'll compile a list of packages that ship cron jobs and look what benefits it might bring 18:59:42 mmaslano Viking-Ice: could you mention in your proposal what it brings to users? 18:59:44 mmaslano ok thanks This wasn't widely advertised at the time, it's not mentioned in the 01-16 meeting minutes (no #info or #action lines were given). So anyone who wasn't at the meeting probably never saw it. The discussion does not relate to the actual feature that was proposed - as we agree, that does not cover cron job migration. And so far as I can tell you never brought any kind of formal proposal to FESCo: there is nothing in the 01-23 or 01-30 logs on this topic, and you have not proposed a feature for it. There was then the thread Start of systemd timers after install/update of a package. You mentioned that you had looked into the migration possibilities and come to a list of 38 cron jobs in service related packages. There was a bit of follow-up discussion between you and Marcela; other principals in the current discussion weren't involved in the thread at this point (Bill posted to it early, but never *after* you mentioned your list of 38 packages). Then we come to this thread, which was related to a specific feature: https://fedoraproject.org/wiki/Features/SystemdCalendarTimers . The migration question was brought up early and quite vaguely by Marcela, not clearly in direct relation to the feature but more as a 'general concern'. You replied and clarified that the feature doesn't actually cover the cron job migration, and re-stated that you were working on a cron job migration proposal. Then we fast-forward a week or so, and Bill replied to Marcela and provided his own proposal for how to decide what cron jobs to migrate. Now at this point I can kinda see how to you it looked like Bill was 'butting in on' your work, as now I've gone and done the thread archaeology and dragged up three week old FESCo logs from the archives, I can see that this has been kind of an 'ongoing thing' for you. But it doesn't quite have that visibility for anyone else - the FESCo discussion wasn't in the minutes and there's no public draft proposal, and the references in the Start of systemd timers after install/update of a package thread are somewhat vague and it's not clear Bill even saw them. Bill was present for the open floor section of the 01-16 meeting (I just checked my personal logs, as the public ones don't show joins/parts), but he didn't say anything - he may not really have followed the conversation. So Bill may not actually have been fully aware this was something you were working on. This was where the thread started going seriously downhill - in response to three different people you stated more and more strongly that you were working on the cron job migration thing and Bill was 'butting in'. Again, I can see how it looked like that to you, but I think to the others it didn't - I'm guessing the others, like me, hadn't seen all the previous stuff. It looked more like Bill suggested a proposal and you were claiming more or less by fiat that this was your area and he should butt out,
Re: Proposed F19 Feature: systemd features
Once upon a time, Jóhann B. Guðmundsson johan...@gmail.com said: Feeling happy in the Red Hat position they invented for you in QA. Feeling a big man now? Challenged accepted big man you have in your rein of error effectively killed 2 thriving process in the QA community. Do you really want to head down this road with me? Go ahead big man make my day! Umm, what? I'll take a stab as a non-Red Hatter: you are WAY off base here. Please step away from the mailing list and take some time to cool off. You are making baseless attacks against people who I have seen provide significant value to the Fedora community (no matter their email address). _Nothing_ in Fedora is your private business. This is a community project, and all community members can have input. When someone gives input on proposals, you CANNOT say go away, this is not your business (especially when that is someone that has put significant hours into Fedora, whether paid by an employer to do so or not). If you can't handle that, then Fedora development might not be the right place for you. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/02/2013 02:28 AM, Adam Williamson wrote: On Sat, 2013-02-02 at 01:25 +, Jóhann B. Guðmundsson wrote: Feeling happy in the Red Hat position they invented for you in QA. Feeling a big man now? Challenged accepted big man you have in your rein of error effectively killed 2 thriving process in the QA community. Do you really want to head down this road with me? Go ahead big man make my day! Well, no, not really. We're not having a fight, here. At least, I'm not trying to. I'm trying to discuss process. You appear to think this is a battle for domination, but that's not how it looks from where I'm sitting. I'm sorry if it came up that way, I'm not trying to slap you down or demean you, I think we've just fallen prey to a bit of process confusion here. So, can we back up a bit? I've just read back the whole way through the two threads, and it turns out to be a bit of a mess. I think the problem is different people have different perceptions of what's going on. So in the 01-16 FESCo meeting - right at the end, in open floor - there was a short conversation about cron job conversion: 18:56:15 Viking-Ice on an different subject does it make sense to migrate all those cron scripts to systemd timer units? 18:56:25 mmaslano what? 18:56:25 Viking-Ice all shipped cron scripts I mean 18:56:40 mitr Viking-Ice: what end-user benefit would all that work bring? 18:57:10 * nirik has no opinion on it without looking at it in more detail. 18:57:20 mmaslano Viking-Ice: as a maintainer, I don't plan to do it, because I don't see any user improvement 18:57:37 mmaslano is there any? 18:58:11 nirik lets discuss that proposal after it's had discussion on list or detailed proposal sent to us? 18:58:22 Viking-Ice mitr, fewer packages in install have not looked at it further it's just recent that systemd gained calender support 18:58:40 Viking-Ice for those timer units 18:59:31 Viking-Ice I'll compile a list of packages that ship cron jobs and look what benefits it might bring 18:59:42 mmaslano Viking-Ice: could you mention in your proposal what it brings to users? 18:59:44 mmaslano ok thanks This wasn't widely advertised at the time, it's not mentioned in the 01-16 meeting minutes (no #info or #action lines were given). So anyone who wasn't at the meeting probably never saw it. The discussion does not relate to the actual feature that was proposed - as we agree, that does not cover cron job migration. And so far as I can tell you never brought any kind of formal proposal to FESCo: there is nothing in the 01-23 or 01-30 logs on this topic, and you have not proposed a feature for it. No because I was looking into it as I have been trying to state this whole time. There was then the thread Start of systemd timers after install/update of a package. You mentioned that you had looked into the migration possibilities and come to a list of 38 cron jobs in service related packages. Yes out of 99 There was a bit of follow-up discussion between you and Marcela; other principals in the current discussion weren't involved in the thread at this point (Bill posted to it early, but never *after* you mentioned your list of 38 packages). Bill showed up on the systemd channel looking for a glorified solution in the form of generators but mmaslano had already at that time shown her concerns about potential administrative conflicts as in half in cron job half in timer units... Then we come to this thread, which was related to a specific feature: https://fedoraproject.org/wiki/Features/SystemdCalendarTimers . The migration question was brought up early and quite vaguely by Marcela, not clearly in direct relation to the feature but more as a 'general concern'. You replied and clarified that the feature doesn't actually cover the cron job migration, and re-stated that you were working on a cron job migration proposal. Yes timer units have been there from more or less the start and they just gained calendar support which is totally irrelevant to my research. Tim wanted even to put in on our ( QA ) meeting logs that he showed concerned over this failing to understand that all that has happened is that you can specificy calendar days dates in timer units which he then retracted from the meeting logs once I had explained it to him that, that feature had nothing to do with anykind of migration. Then we fast-forward a week or so, and Bill replied to Marcela and provided his own proposal for how to decide what cron jobs to migrate. Now at this point I can kinda see how to you it looked like Bill was 'butting in on' your work, as now I've gone and done the thread archaeology and dragged up three week old FESCo logs from the archives, I can see that this has been kind of an 'ongoing thing' for you. But it doesn't quite have that visibility for anyone else - the FESCo discussion wasn't in the minutes and there's no public draft proposal, and the references in the Start of systemd timers after install/update of a package
Re: Proposed F19 Feature: systemd features
On 02/02/2013 05:57 AM, Chris Adams wrote: Once upon a time, Jóhann B. Guðmundsson johan...@gmail.com said: Feeling happy in the Red Hat position they invented for you in QA. Feeling a big man now? Challenged accepted big man you have in your rein of error effectively killed 2 thriving process in the QA community. Do you really want to head down this road with me? Go ahead big man make my day! Umm, what? I'll take a stab as a non-Red Hatter: you are WAY off base here. Please step away from the mailing list and take some time to cool off. You are making baseless attacks against people who I have seen provide significant value to the Fedora community (no matter their email address). Let's venture that road kid _Nothing_ in Fedora is your private business. This is a community project, and all community members can have input. When someone gives input on proposals, you CANNOT say go away, this is not your business (especially when that is someone that has put significant hours into Fedora, whether paid by an employer to do so or not). When an Red Hat employee that gets away with what ever he pleases within the community I say what dam I please. You might put him in some god like status I don't! Trust me when I say this people a little higher up the hierarchy has tried to convince me he's a good guy but my interaction with him tells a whole complexly different story... If you can't handle that, then Fedora development might not be the right place for you. Get the fuck out before you get in my business. If you want to test me here I am deal with it because I wont back down not after the treatment he has given me! You have absolutely no idea what I have sacrificed for the project and if you want to head down that road son realize I dont bark I bite! Chris Adams care to explain to me what the fuck you have been doing all those years other than trying to play the tough boy? Let's put your contribution to the test! JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/02/2013 02:39 AM, Reindl Harald wrote: Am 02.02.2013 03:08, schrieb Jóhann B. Guðmundsson: When I meet a maintainer in the project that stated to me I have to talk to my manager first before upgrading his component that rings alarm bells to me, That gives me the feel that they are maintaining their components as a part of their job not because they want to scratch an itch and want to! jesus christ be gladful that companies like red hat are paying people for development of free software and if someone get paied for a job soemtimes he has to speak with his managers It's not like RH gives other company's the alternative to sponsor the project now does it I dont know about your parts but I grew up in environment where slavery is not accepted your definition of slavery is completly broken If an RH employee is maintainer is maintaining a component in the distribution and doing so because it's an part of his job but not because he want's to I call that slavery especially when he has to go to his manager to ask him if he is allowed to upgrade the component it to it's latest release. Yes first hand I have experienced an RH employee that has said I need to speak to my manager before he could upgrade the component he was maintaining to the latest release and to me that's pretty fucking alarming JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/02/2013 02:28 AM, Rahul Sundaram wrote: Hi On Fri, Feb 1, 2013 at 9:08 PM, Jóhann B. Guðmundsson wrote: Either RH employees are participating in the project by their own free will or not. I have personally meet both sides which has gotten me confused and conflicted. Employees can have assigned duties as well as projects of their own interest. If you are confused about which one is what and have a need to know, feel free to ask them. When I meet a maintainer in the project that stated to me I have to talk to my manager first before upgrading his component that rings alarm bells to me, That gives me the feel that they are maintaining their components as a part of their job not because they want to scratch an itch and want to! Why is it cause for alarm that some people in Fedora are getting paid to do something within Fedora? I dont know about your parts but I grew up in environment where slavery is not accepted. This frequent I dont know about your parts sounds quite discriminatory and getting paid to do a job is pretty much the opposite of slavery. Rahul Then Rahul how about a wiki page about all the RH employees that are maintaining components in the distribution that have to vs those that want to. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Sat, Feb 02, 2013 at 02:08:00AM +, Jóhann B. Guðmundsson wrote: When I meet a maintainer in the project that stated to me I have to talk to my manager first before upgrading his component that rings alarm bells to me, That gives me the feel that they are maintaining their components as a part of their job not because they want to scratch an itch and want to! There is a third reason for maintaining a component: it is a dependency for another component the packager maintains. This is applicable for _all_ packagers, be they from Red Hat or the community. You either conveniently omitted this reason to make an argument or never thought of it, in which case I respectfully ask you to butt out of this thread because you do not know what you are talking about. D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/02/2013 07:03 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 02:08:00AM +, Jóhann B. Guðmundsson wrote: When I meet a maintainer in the project that stated to me I have to talk to my manager first before upgrading his component that rings alarm bells to me, That gives me the feel that they are maintaining their components as a part of their job not because they want to scratch an itch and want to! There is a third reason for maintaining a component: it is a dependency for another component the packager maintains. This is applicable for _all_ packagers, be they from Red Hat or the community. You either conveniently omitted this reason to make an argument or never thought of it, in which case I respectfully ask you to butt out of this thread because you do not know what you are talking about. Oh in my case it was an primary component no dependency that Red Hat maintainer could not update until he got approval but for the sake of your argument and concision let's lower my IQ to an rock ( which I do believe is 20 ) and say I dont have freaking flying idea what I'm talking about. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Sat, Feb 02, 2013 at 06:20:18AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 05:57 AM, Chris Adams wrote: If you can't handle that, then Fedora development might not be the right place for you. Get the fuck out before you get in my business. If you want to test me here I am deal with it because I wont back down not after the treatment he has given me! You have absolutely no idea what I have sacrificed for the project and if you want to head down that road son realize I dont bark I bite! Chris Adams care to explain to me what the fuck you have been doing all those years other than trying to play the tough boy? Let's put your contribution to the test! Congratulations! You have proved your merit once again. That personal attack was uncalled for. @list admins: Could we put this person on the moderation list, please? D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/02/2013 07:12 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 06:20:18AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 05:57 AM, Chris Adams wrote: If you can't handle that, then Fedora development might not be the right place for you. Get the fuck out before you get in my business. If you want to test me here I am deal with it because I wont back down not after the treatment he has given me! You have absolutely no idea what I have sacrificed for the project and if you want to head down that road son realize I dont bark I bite! Chris Adams care to explain to me what the fuck you have been doing all those years other than trying to play the tough boy? Let's put your contribution to the test! Congratulations! You have proved your merit once again. That personal attack was uncalled for. Was it? He threaten me I responded. The position and do correct me if I'm wrong for Adam did not exist before he got hired, and he was not even hired from the community. Care to share the link to his position at that time. Feel free to use the internet archive let's analyze what stood in it, Prove me wrong and I shall be the first to admit my wrong doing, my mistake and apologize to all parties involved. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Sat, Feb 02, 2013 at 07:06:12AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 07:03 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 02:08:00AM +, Jóhann B. Guðmundsson wrote: When I meet a maintainer in the project that stated to me I have to talk to my manager first before upgrading his component that rings alarm bells to me, That gives me the feel that they are maintaining their components as a part of their job not because they want to scratch an itch and want to! There is a third reason for maintaining a component: it is a dependency for another component the packager maintains. This is applicable for _all_ packagers, be they from Red Hat or the community. You either conveniently omitted this reason to make an argument or never thought of it, in which case I respectfully ask you to butt out of this thread because you do not know what you are talking about. Oh in my case it was an primary component no dependency that Red Hat maintainer could not update until he got approval but for the You generalized one specific case to _all components of all Red Hat maintainers_. When I rejected that generalization, you are counteracting by claiming that my argument does not apply for that one _specific_ case. Sorry, but that is a faulty reasoning. sake of your argument and concision let's lower my IQ to an rock ( which I do believe is 20 ) and say I dont have freaking flying idea what I'm talking about. Is this sarcasm or a personal attack? I am not quite sure... D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Sat, 2013-02-02 at 07:24 +, Jóhann B. Guðmundsson wrote: On 02/02/2013 07:12 AM, David Tardon wrote: On Sat, Feb 02, 2013 at 06:20:18AM +, Jóhann B. Guðmundsson wrote: On 02/02/2013 05:57 AM, Chris Adams wrote: If you can't handle that, then Fedora development might not be the right place for you. Get the fuck out before you get in my business. If you want to test me here I am deal with it because I wont back down not after the treatment he has given me! You have absolutely no idea what I have sacrificed for the project and if you want to head down that road son realize I dont bark I bite! Chris Adams care to explain to me what the fuck you have been doing all those years other than trying to play the tough boy? Let's put your contribution to the test! Congratulations! You have proved your merit once again. That personal attack was uncalled for. Was it? He threaten me I responded. The position and do correct me if I'm wrong for Adam did not exist before he got hired, and he was not even hired from the community. Care to share the link to his position at that time. Feel free to use the internet archive let's analyze what stood in it, Prove me wrong and I shall be the first to admit my wrong doing, my mistake and apologize to all parties involved. Um...Chris Adams and I are two different people. He doesn't work for RH. I haven't been involved in this strand of the thread at all. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Le Mer 30 janvier 2013 19:07, Bill Nottingham a écrit : it's wasteful in terms of builds and updates for users to be updating all of systemd just to add a new French keymap conversion, esp. since users want their keyboard to work the same in gui and the console, so putting the keymaps in systemd makes systemd a hard dep of the gui layer And I'm not sure the gui guys would agree -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Marcela Mašláňová (mmasl...@redhat.com) said: I would say that work even before. If I should say according to number of bugs, not many users were using specific SElinux contexts for cronjob tasks. No objection to this feature, it might be very powerful for some use-cases. I'm afraid of situation, when half of cronjobs will be converted and half stay as is. Poor admins. So, here's where policy could be helpful. What should and shouldn't migrate? Right now, it's used by: - systemd itself (obviously OK) - mrtg (optionally, not by default - in fact, this whole service is kind of a mess) - inn (eh) Current cron users are: afraid-dyndns amavisd-new apt arm4 atop autotrust awstats backup-manager bcfg2 cacti checkdns clamav-unofficial-sigs clamav-update clement cronie cronie-anacron cronie-noanacron crontabs crypto-utils cyrus-imapd dbmail denyhosts dmraid-events-logwatch dnf drupal6 drupal7 dspam dwatch epylog etckeeper exim exim-greylist fetch-crl freeipa-server ghc-compiler globus-gram-audit glpi glpi-mass-ocs-import hplip hylafax+ indefero leafnode libvirt-sandbox lightsquid limph-hostagent logcheck logrotate logwatch ltsp-server mailman man-db mcelog mdadm mldonkey-server mlocate moodle munin newscache nordugrid-arc-gridmap-utils nsd ocsinventory-agent olpc-update opendnssec openshift-origin-cartridge-cron-1.4 openshift-origin-msg-node-mcollective openvas-scanner ovirt-engine ovirt-node PackageKit-cron pam_shield polipo prelink queuegraph rancid rkhunter rpm-cron safekeep-server sagator-core sipwitch slrn-pull spamassassin squidGuard squirrelmail subscription-manager sysstat system-autodeath sysusage tmpwatch tripwire unbound-libs vdsm vdsm-reg vnstat webacula webalizer WebCalendar x509watch yum-cron zfs-fuse I would be tempted to say: Anything running at a core system level where a dependence on a separate cron daemon may be unwanted (or a bad idea) should be migrated, and nothing else for now until we have a clearer perspective on the future. Given that list that would be migration of: mcelog mdadm ovirt-node prelink (?) tmpwatch vdsm-* But I'm open to other ideas. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Colin Walters (walt...@verbum.org) said: On Tue, 2013-01-29 at 14:30 -0500, Bill Nottingham wrote: This is interesting, in that it's a feature that's occasionally requested by various users and administrators. However, this is rather limited in that only systemd stuff is using it now, and it's tied to the journal API. Actually, we're using it in GNOME too: http://git.gnome.org/browse/gnome-session/commit/?id=9ec4deede968ad55d18340109c5aa9f6416de13d Looking at this in the current implemenation... I understand that this doesn't work unless everything is documented. But... Jan 30 22:07:01 nostromo.devel.redhat.com systemd[1]: Starting Sendmail Mail Transport Client... -- Subject: Unit sm-client.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: -- http://www.freedesktop.org/wiki/Software/systemd/catalog/7d4958e842da4a758f6c1cdc7b36dcc5 -- -- Unit sm-client.service has begun starting up. ... this is a really verbose way of adding no additional information. Similar example here: Jan 31 09:22:15 nostromo.devel.redhat.com systemd-sleep[4298]: System resumed. -- Subject: System sleep state suspend left -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: -- http://www.freedesktop.org/wiki/Software/systemd/catalog/8811e6df2a8e40f58a94cea26f8ebf14 -- -- The system has now left the suspend sleep state. Jan 31 09:22:15 nostromo.devel.redhat.com systemd[1]: Time has been changed -- Subject: Time change -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: -- http://www.freedesktop.org/wiki/Software/systemd/catalog/c7a787079b354eaaa9e77b371893cd27 -- -- The system clock has been changed to REALTIME microseconds after January -- 1st, 1970. A substitution bug! (Unless it's really supposed to reference a meta-variable that isn't part of the message). Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 01/31/2013 03:51 PM, Bill Nottingham wrote: I would be tempted to say: Anything running at a core system level where a dependence on a separate cron daemon may be unwanted (or a bad idea) should be migrated, and nothing else for now until we have a clearer perspective on the future. Given that list that would be migration of: mcelog mdadm ovirt-node prelink (?) tmpwatch vdsm-* But I'm open to other ideas. Am I supposed to assume you are working migrating this? If so there is no point in me doing the same and be looking at this because I have an list that contains few more components that this that I'm looking at. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Thu, Jan 31, 2013 at 10:51:45 -0500, Bill Nottingham nott...@redhat.com wrote: I would be tempted to say: Anything running at a core system level where a dependence on a separate cron daemon may be unwanted (or a bad idea) should be migrated, and nothing else for now until we have a clearer perspective on the future. Given that list that would be migration of: mcelog mdadm ovirt-node prelink (?) tmpwatch vdsm-* But I'm open to other ideas. I think it will be easier to disable the jobs in systemd without the next update turning things on. This is useful if you have some package installed to look at it, but aren't actually running it. Editing the cron files to turn it off doesn't survive updates, but it should be possible to do an override in systemd that will survive package updates. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 01/31/2013 04:23 PM, Bruno Wolff III wrote: On Thu, Jan 31, 2013 at 10:51:45 -0500, Bill Nottingham nott...@redhat.com wrote: I would be tempted to say: Anything running at a core system level where a dependence on a separate cron daemon may be unwanted (or a bad idea) should be migrated, and nothing else for now until we have a clearer perspective on the future. Given that list that would be migration of: mcelog mdadm ovirt-node prelink (?) tmpwatch vdsm-* But I'm open to other ideas. I think it will be easier to disable the jobs in systemd without the next update turning things on. This is useful if you have some package installed to look at it, but aren't actually running it. Editing the cron files to turn it off doesn't survive updates, but it should be possible to do an override in systemd that will survive package updates. It already does. ( timer units in /etc/systemd/system directory ) in any case migrating the cron jobs are irrelevant to the feature Lennart mentioned. systemd has supported timer units for activating services based on time since its inception. However, it only could schedule services based on monotonic time events (i.e. every 5 minutes). With this feature in place systemd also supports calendar time events (i.e. every monday morning 6:00 am, or at midnight on every 1st, 2nd, 3rd of each month if that's saturday or sunday). I'm the one that has been looking into the benefit from which component and of which cron job it would be useful for migrating to systemd timer units and that's totally irrelevant to that feature as I mentioned to FESCO but given that Bill Notting seems to be butting into that effort and planning to do it i'll just leave that up to him. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Hi On Thu, Jan 31, 2013 at 11:27 AM, Jóhann B. Guðmundsson wrote: I'm the one that has been looking into the benefit from which component and of which cron job it would be useful for migrating to systemd timer units and that's totally irrelevant to that feature as I mentioned to FESCO but given that Bill Notting seems to be butting into that effort and planning to do it i'll just leave that up to him. Nobody is butting into anything. There can be more than one proposal. We get to discuss competing ideas and form consensus. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 01/31/2013 05:12 PM, Rahul Sundaram wrote: Hi On Thu, Jan 31, 2013 at 11:27 AM, Jóhann B. Guðmundsson wrote: I'm the one that has been looking into the benefit from which component and of which cron job it would be useful for migrating to systemd timer units and that's totally irrelevant to that feature as I mentioned to FESCO but given that Bill Notting seems to be butting into that effort and planning to do it i'll just leave that up to him. Nobody is butting into anything. There can be more than one proposal. We get to discuss competing ideas and form consensus. Have fun with your proposals and implementing them just dont mix the cron migration up with the timer units ( which has been there from the get go )... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Thu, 2013-01-31 at 17:32 +, Jóhann B. Guðmundsson wrote: On 01/31/2013 05:12 PM, Rahul Sundaram wrote: Hi On Thu, Jan 31, 2013 at 11:27 AM, Jóhann B. Guðmundsson wrote: I'm the one that has been looking into the benefit from which component and of which cron job it would be useful for migrating to systemd timer units and that's totally irrelevant to that feature as I mentioned to FESCO but given that Bill Notting seems to be butting into that effort and planning to do it i'll just leave that up to him. Nobody is butting into anything. There can be more than one proposal. We get to discuss competing ideas and form consensus. Have fun with your proposals and implementing them just dont mix the cron migration up with the timer units ( which has been there from the get go )... I agree we should keep them separate. The feature page talks solely about the feature itself being present: it's a publicity feature, a 'talk about this neat upstream feature!' feature. It does not in any way state that any existing services should or will be migrated from cron to systemd timers. If that were going to happen in any kind of wholesale manner, that should be a separate feature (and on that basis, we probably shouldn't do it for F19, as the feature deadline is now gone). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Thu, 2013-01-31 at 16:03 +0100, Nicolas Mailhot wrote: Le Mer 30 janvier 2013 19:07, Bill Nottingham a écrit : it's wasteful in terms of builds and updates for users to be updating all of systemd just to add a new French keymap conversion, esp. since users want their keyboard to work the same in gui and the console, so putting the keymaps in systemd makes systemd a hard dep of the gui layer And I'm not sure the gui guys would agree Bill was only citing an example, but for the record, it's looking like the keymap stuff should be a whole lot better in F19: https://bugzilla.redhat.com/show_bug.cgi?id=837292 Vitezslav Crhonek has come up with a way for us to derive kbd layouts from xkb layouts, so we should soon have a kbd package for Rawhide which will have all the same layouts we have for xkb. systemd won't then have to try and do clever-clever translation between xkb and kbd layout sets: we still have to decide exactly how systemd and anaconda and whatever else will handle the xkb/kbd divide, but in broad strokes, however it's handled exactly in technical terms, you'll just pick a keyboard layout in anaconda or gnome-control-center or KDE or whatever and that same layout with the same name will exist in both 'xkb' and 'kbd', so it should be trivial to use the same layout in both places. It would be kind of nice if we could make this a feature to make sure it gets hooked up sensibly all the way up the stack, but frankly even if we just replace the systemd 'translation table' with something simple that just maps the layout name from X to kbd, that would immediately be a big improvement on f18 already. if anyone's interested in making this a late feature, I could try and help vitezslav put together a feature page quickly. anyone with a dog in this fight should probably follow the bug, as that's where all the action's happening right now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Hi On Thu, Jan 31, 2013 at 12:32 PM, Jóhann B. Guðmundsson wrote: Have fun with your proposals and implementing them just dont mix the cron migration up with the timer units ( which has been there from the get go )... You seem confused. I don't have any proposals Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 01/31/2013 07:18 PM, Adam Williamson wrote: On Thu, 2013-01-31 at 17:32 +, Jóhann B. Guðmundsson wrote: On 01/31/2013 05:12 PM, Rahul Sundaram wrote: Hi On Thu, Jan 31, 2013 at 11:27 AM, Jóhann B. Guðmundsson wrote: I'm the one that has been looking into the benefit from which component and of which cron job it would be useful for migrating to systemd timer units and that's totally irrelevant to that feature as I mentioned to FESCO but given that Bill Notting seems to be butting into that effort and planning to do it i'll just leave that up to him. Nobody is butting into anything. There can be more than one proposal. We get to discuss competing ideas and form consensus. Have fun with your proposals and implementing them just dont mix the cron migration up with the timer units ( which has been there from the get go )... I agree we should keep them separate. The feature page talks solely about the feature itself being present: it's a publicity feature, a 'talk about this neat upstream feature!' feature. It does not in any way state that any existing services should or will be migrated from cron to systemd timers. If that were going to happen in any kind of wholesale manner, that should be a separate feature (and on that basis, we probably shouldn't do it for F19, as the feature deadline is now gone). Maintainers can just choose to do so today as an update to their component. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 01/31/2013 07:27 PM, Rahul Sundaram wrote: Hi On Thu, Jan 31, 2013 at 12:32 PM, Jóhann B. Guðmundsson wrote: Have fun with your proposals and implementing them just dont mix the cron migration up with the timer units ( which has been there from the get go )... You seem confused. I don't have any proposals Then stay out of this. I already told fesco I would be looking into it as I was doing. Somehow they got the impression that it meant migrating all the cron jobs which is not the case, which to me was obvious, to them apparently not so much. It *only* might make sense for cron jobs that are accommodated by services/daemons. There exist no infrastructure for users own cron jobs, no concepts of daily/weekly/monthly/.d/ where users can drop a file containing one liner, which makes timer units less attractive from users usability standpoint and systemd does not support having separated preset policy for different types of units. Timer units they should *always* ( or rather default to that with exceptions ) be enabled to get the exact cron like behavior. And in the midst of me doing this research I have to have Bill Notting butting into my work ( and I know what that means ), trying to come up with his own list instead of simply asking me for the one I was looking at [¹] and consulting with me where I was with my findings and now he can just have at it and finish do it his own way., create those units and prep the necessary patches to the packages etc. since he's such an expert on the matter. JBG 1. https://fedoraproject.org/wiki/User:Johannbg/Systemd/cron-migration -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Hi On Thu, Jan 31, 2013 at 6:46 PM, Jóhann B. Guðmundsson wrote: Then stay out of this. I don't think that is a reasonable request. This is a public mailing list after all. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 02/01/2013 12:31 AM, Rahul Sundaram wrote: Hi On Thu, Jan 31, 2013 at 6:46 PM, Jóhann B. Guðmundsson wrote: Then stay out of this. I don't think that is a reasonable request. This is a public mailing list after all. I'm not seeing asking you to stay out of this is an unreasonable request nor this being a public mailinglist has anything to do with that request after you stated you had no proposal. I guess I must still be confused... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Hi On Thu, Jan 31, 2013 at 7:53 PM, Jóhann B. Guðmundsson wrote: I'm not seeing asking you to stay out of this is an unreasonable request nor this being a public mailinglist has anything to do with that request after you stated you had no proposal. I guess I must still be confused... Yep. Development discussions include more than just proposals. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Thu, Jan 31, 2013 at 11:46:33PM +, Jóhann B. Guðmundsson wrote: And in the midst of me doing this research I have to have Bill Notting butting into my work ( and I know what that means ), trying to come up with his own list instead of simply asking me for the one I was looking at [¹] and consulting with me where I was with my findings and now he can just have at it and finish do it his own way., create those units and prep the necessary patches to the packages etc. since he's such an expert on the matter. If you stop behaving like a child, maybe people will start to take you seriously. D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 01/30/13 01:08, Kay Sievers wrote: On Tue, Jan 29, 2013 at 11:13 PM, Bill Nottingham nott...@redhat.com wrote: Kay Sievers (k...@vrfy.org) said: Realistically, it's new textual files, replacing old textual files, which are then compiled into a binary file. I'm not sure why there's the intermediate step of a second textual format, but there is. Because the original text file is a hack and a format specific to the PCI/USB IDs, and makes no sense at all for a generic hwdb. pci:v0010* ID_VENDOR_FROM_DATABASE=Allied Telesis, Inc It's not like that's that much more of a generic format. :) It is entirely generic. It can carry arbitrary numbers of freely named key/value pairs basically unlimited in their size. Is extensible, uses flexible and extensible string matches like modaliases for kernel modules. Nothing you would find in the PCI/USB IDs hack. So what do you criticize here? Still looks pointless. You convert the old-format into new-format, then compile new-format into the database. It's not obvious why you don't go straight from old-format to the database. hwdata package updates would directly show up in the database then, without having to touch systemd. cheers, Gerd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Wed, Jan 30, 2013 at 11:42 AM, Gerd Hoffmann kra...@redhat.com wrote: On 01/30/13 01:08, Kay Sievers wrote: On Tue, Jan 29, 2013 at 11:13 PM, Bill Nottingham nott...@redhat.com wrote: Kay Sievers (k...@vrfy.org) said: Realistically, it's new textual files, replacing old textual files, which are then compiled into a binary file. I'm not sure why there's the intermediate step of a second textual format, but there is. Because the original text file is a hack and a format specific to the PCI/USB IDs, and makes no sense at all for a generic hwdb. pci:v0010* ID_VENDOR_FROM_DATABASE=Allied Telesis, Inc It's not like that's that much more of a generic format. :) It is entirely generic. It can carry arbitrary numbers of freely named key/value pairs basically unlimited in their size. Is extensible, uses flexible and extensible string matches like modaliases for kernel modules. Nothing you would find in the PCI/USB IDs hack. So what do you criticize here? Still looks pointless. You convert the old-format into new-format, then compile new-format into the database. It's not obvious why you don't go straight from old-format to the database. hwdata package updates would directly show up in the database then, without having to touch systemd. It's as pointless as shipping a parser for a foreign and irrelevant format in the hwdb code. And it is as pointless as adding weird code and ./configure stuff again to udev to find these files in the place of the month, where some distro poeple decided again where to put it, and every distro in a different place, with different names or file types. And it is as pointless as inventing magic rules in the hwdb to overwrite the old files with possibly new data shipped in the new format. We don't want to pointlessly do any of that. Also, the textual strings are just one, and not the interesting part of the hwdb, and all should be uniform and not pull in some not convincing legacy formats, or weird rules how things are located and overwritten. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 01/30/13 11:55, Kay Sievers wrote: Hi, Still looks pointless. You convert the old-format into new-format, then compile new-format into the database. It's not obvious why you don't go straight from old-format to the database. hwdata package updates would directly show up in the database then, without having to touch systemd. It's as pointless as shipping a parser for a foreign and irrelevant format in the hwdb code. You need the parser anyway, for converting the old format into the new, don't you? And it is as pointless as adding weird code and ./configure stuff again to udev to find these files in the place of the month, where some distro poeple decided again where to put it, and every distro in a different place, with different names or file types. That is a bit nasty indeed. And it is as pointless as inventing magic rules in the hwdb to overwrite the old files with possibly new data shipped in the new format. You could use import $format $file syntax in the new format, then plumb a file with a single import line instead of the converted file into the directory. You get the same ordering then. cheers, Gerd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Wed, Jan 30, 2013 at 12:19 PM, Gerd Hoffmann kra...@redhat.com wrote: On 01/30/13 11:55, Kay Sievers wrote: Hi, Still looks pointless. You convert the old-format into new-format, then compile new-format into the database. It's not obvious why you don't go straight from old-format to the database. hwdata package updates would directly show up in the database then, without having to touch systemd. It's as pointless as shipping a parser for a foreign and irrelevant format in the hwdb code. You need the parser anyway, for converting the old format into the new, don't you? Right, but only in the build process, or the packaging. It's a dumb perl script. Doing it in shipped tools on the host has much higher requirements. :) And it is as pointless as adding weird code and ./configure stuff again to udev to find these files in the place of the month, where some distro poeple decided again where to put it, and every distro in a different place, with different names or file types. That is a bit nasty indeed. Yeah, it was a mess. Some even only shipped the .gz versions of it. And it is as pointless as inventing magic rules in the hwdb to overwrite the old files with possibly new data shipped in the new format. You could use import $format $file syntax in the new format, then plumb a file with a single import line instead of the converted file into the directory. You get the same ordering then. That could work, yeah. If we wanted to make it a swiss army knife, which brings-in a whole bunch of other problems, and people's creativity, which we intentionally wanted to leave out here. :) Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Wed, Jan 30, 2013 at 1:08 AM, Kay Sievers k...@vrfy.org wrote: And because a major part of the data the hwdb will carry in the future will be the equivalent of udev rules, and should not be shipped by a different package, because it it might carry specifics needed for a certain functionality, just like the udev rules do today. If we want to artificially declare the PCI+USB IDs different from the rest of the growing hwdb data, and split that into a different package and the rest not; Just because two sets of information have the same primary key does not necessarily mean they belong even in the same table, let alone the same database. udev rules and naming databases are rather different in purpose, development process, required testing, update frequency, impact of bugs. sure, we can do that when things have stabilized, but so far I'm not really sure if that will give is a significant advantage, considering that updates just can be installed along with the default data. Things are not stable now, so let's change them, and after they have stabilized, let's possibly revert the change? I can't quite see the rationale for doing things that way. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Kay Sievers (k...@vrfy.org) said: Either you're intending for the lifetime of your OS to be shipping systemd updates that update the base data set, I don't intend to ship update packages in the context of systemd, we can just update the data in the package like we add patches for other fixes, in case we need an update. In the end PCI+USB IDs are just pretty boring names for humans, not used in the system itself. What makes them so special? It really sounds more like cosmetic care, than a real technical need to update these more often than we will need to update systemd anyway. or you're intending to be shipping updated data sets in a separate package. We can just do that, but still could ship the default data in the main package. Would we be moving the other data to this model as well? I note that in F18 we ended up building systemd many many times just to update keymap conversions; it's wasteful in terms of builds and updates for users to be updating all of systemd just to add a new French keymap conversion, or to add a quirk just for some new laptop. The point is, we've done this in the past where we shipped the data with the tools, and we very quickly moved to shipping the data separate - it's cleaner, allows for just updating the data when necessary, and it forces people to keep their API ABI for accessing it stable. :) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Wed, 2013-01-30 at 13:07 -0500, Bill Nottingham wrote: Kay Sievers (k...@vrfy.org) said: Either you're intending for the lifetime of your OS to be shipping systemd updates that update the base data set, I don't intend to ship update packages in the context of systemd, we can just update the data in the package like we add patches for other fixes, in case we need an update. In the end PCI+USB IDs are just pretty boring names for humans, not used in the system itself. What makes them so special? It really sounds more like cosmetic care, than a real technical need to update these more often than we will need to update systemd anyway. or you're intending to be shipping updated data sets in a separate package. We can just do that, but still could ship the default data in the main package. Would we be moving the other data to this model as well? I note that in F18 we ended up building systemd many many times just to update keymap conversions; it's wasteful in terms of builds and updates for users to be updating all of systemd just to add a new French keymap conversion, or to add a quirk just for some new laptop. The point is, we've done this in the past where we shipped the data with the tools, and we very quickly moved to shipping the data separate - it's cleaner, allows for just updating the data when necessary, and it forces people to keep their API ABI for accessing it stable. :) +1 million - another data point - ca-certificates package - it was much cleaner to split it out of openssl. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Wed, 30 Jan 2013 19:18:40 +0100 Tomas Mraz tm...@redhat.com wrote: +1 million - another data point - ca-certificates package - it was much cleaner to split it out of openssl. +1 a lot from me too. Adding to churn of a core system component to simply update data files is bad. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Wed, Jan 30, 2013 at 07:18:40PM +0100, Tomas Mraz wrote: The point is, we've done this in the past where we shipped the data with the tools, and we very quickly moved to shipping the data separate - it's cleaner, allows for just updating the data when necessary, and it forces people to keep their API ABI for accessing it stable. :) +1 million - another data point - ca-certificates package - it was much cleaner to split it out of openssl. Ditto splitting of timezone data from glibc-common to tzdata. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Sun, Jan 27, 2013 at 2:54 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Features/SystemdHardwareDatabase = https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase Feature owner(s): Kay Sievers kay at redhat dot com The udevd service has a long history of managing kernel devices. Besides generating events when devices are discovered or removed it maintains a dynamic, stateless database of all available devices including meta data about them. With Fedora 19 we want to substantially enhance the metadata that udev keeps for each device, by augmenting it from a userspace database of non- essential information, that is indexed by device identification data such as PCI/USB vendor/product IDs. Some years ago all hardware data was moved out of various separate packages into the hwdata package (even if it meant moving it out of the original upstream source). The feature page doesn't even mention the hwdata package. AFAICS this 1) Duplicates the data. 1a) Will the two databases be kept in sync? How will that happen? 1b) What is the long-term goal? Will one of the two go away? If so, how and when? 2) Breaks the hwdata-vs-code separation that was created earlier. What were the reasons of the separation, and why are they no longer applicable now? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Miloslav Trmač (m...@volny.cz) said: Some years ago all hardware data was moved out of various separate packages into the hwdata package (even if it meant moving it out of the original upstream source). The feature page doesn't even mention the hwdata package. AFAICS this 1) Duplicates the data. 1a) Will the two databases be kept in sync? How will that happen? It pulls from upstream at build time, from reading the code. 2) Breaks the hwdata-vs-code separation that was created earlier. What were the reasons of the separation, and why are they no longer applicable now? It would be useful to be able to update this without updating systemd... is there any reason the perl generator for this can't be moved to hwdata itself and have *that* pull the upstream versions on build? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Jaroslav Reznik (jrez...@redhat.com) said: = Features/SystemdMessageCatalog = https://fedoraproject.org/wiki/Features/SystemdMessageCatalog Feature owner(s): Lennart Poettering lennart at poettering dot net Logging is essential for finding and tracking down system problems. Just finding and tracking them down however is seldom enough to actually get them fixed. With Journal Message Catalogs we want to link helpful meta information directly to many log messages applications generate, keyed off an ID identifying the type of message. This localized meta information can help the user to fix the problem, refer him to additional documentation, or even inform him where to get further help. This is interesting, in that it's a feature that's occasionally requested by various users and administrators. However, this is rather limited in that only systemd stuff is using it now, and it's tied to the journal API. Do we know 1) if anything else is going to start tagging messages in this way (the kernel, other programs, etc.) 2) if it's possible to set the MESSAGE_ID in some other structured way? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Tue, 29.01.13 20:07, Miloslav Trmač (m...@volny.cz) wrote: On Sun, Jan 27, 2013 at 2:54 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Features/SystemdHardwareDatabase = https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase Feature owner(s): Kay Sievers kay at redhat dot com The udevd service has a long history of managing kernel devices. Besides generating events when devices are discovered or removed it maintains a dynamic, stateless database of all available devices including meta data about them. With Fedora 19 we want to substantially enhance the metadata that udev keeps for each device, by augmenting it from a userspace database of non- essential information, that is indexed by device identification data such as PCI/USB vendor/product IDs. Some years ago all hardware data was moved out of various separate packages into the hwdata package (even if it meant moving it out of the original upstream source). The feature page doesn't even mention the hwdata package. AFAICS this 1) Duplicates the data. 1a) Will the two databases be kept in sync? How will that happen? The databases are kept in the systemd RPM in a generic source format (that is not the in the classic hwdb format) and are compiled into an indexed database at package installation. To update the various hardware databases one needs to rebuild the systemd RPM hence. Currently, the USB, PCI, OUI, IAB, ACPI, Bluetooth database are included. 1b) What is the long-term goal? Will one of the two go away? If so, how and when? Upstream lsusb has been updated to use libudev APIs to check the index database already. Something similar can be done by all other tools too. For devices that are discovered all matching database entries are attached to the respective udev devices anyway, and libudev also supports an API to lookup data for non-present hardware too. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Tue, 29.01.13 14:30, Bill Nottingham (nott...@redhat.com) wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Features/SystemdMessageCatalog = https://fedoraproject.org/wiki/Features/SystemdMessageCatalog Feature owner(s): Lennart Poettering lennart at poettering dot net Logging is essential for finding and tracking down system problems. Just finding and tracking them down however is seldom enough to actually get them fixed. With Journal Message Catalogs we want to link helpful meta information directly to many log messages applications generate, keyed off an ID identifying the type of message. This localized meta information can help the user to fix the problem, refer him to additional documentation, or even inform him where to get further help. This is interesting, in that it's a feature that's occasionally requested by various users and administrators. However, this is rather limited in that only systemd stuff is using it now, and it's tied to the journal API. Do we know 1) if anything else is going to start tagging messages in this way (the kernel, other programs, etc.) I know that at least gnome-session started to tag some of its messages with a message ID. This is a relatively new feature, we haven't really began to advertise that this is now available too much. In fact, posting this as Fedora feature is our first step to make this more broadly known, and maybe get more people to use this. 2) if it's possible to set the MESSAGE_ID in some other structured way? Well there is no other structured API in our basic stack I was aware of, so no, you have to use the journal API for this. That said, libvirt actually uses structured logging to the journal now, but does not use our API for that, since they had some special needs. The local protocol is currently not documented, but is considered stable (I really should document it in the wiki, too), so they just issue the log messages on their own. At the moment systemd itself already generates quite a few messages already that have MESSAGE_IDs attached and message catalog entries. However, this is is far from complete, and we should improve the catalog entries and add more message IDS. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Tue, 2013-01-29 at 14:30 -0500, Bill Nottingham wrote: This is interesting, in that it's a feature that's occasionally requested by various users and administrators. However, this is rather limited in that only systemd stuff is using it now, and it's tied to the journal API. Actually, we're using it in GNOME too: http://git.gnome.org/browse/gnome-session/commit/?id=9ec4deede968ad55d18340109c5aa9f6416de13d -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Tue, Jan 29, 2013 at 8:07 PM, Miloslav Trmač m...@volny.cz wrote: On Sun, Jan 27, 2013 at 2:54 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Features/SystemdHardwareDatabase = https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase Feature owner(s): Kay Sievers kay at redhat dot com The udevd service has a long history of managing kernel devices. Besides generating events when devices are discovered or removed it maintains a dynamic, stateless database of all available devices including meta data about them. With Fedora 19 we want to substantially enhance the metadata that udev keeps for each device, by augmenting it from a userspace database of non- essential information, that is indexed by device identification data such as PCI/USB vendor/product IDs. Some years ago all hardware data was moved out of various separate packages into the hwdata package (even if it meant moving it out of the original upstream source). The feature page doesn't even mention the hwdata package. AFAICS this The hwdb is drop-in directory based, which means: - additionally installed data overwrites shipped data - stuff with the same file name in /etc/ disables stuff in /usr/lib/ Users can just install update packages, or add their own files, which will not conflict with the default shipped data. 1) Duplicates the data. 1a) Will the two databases be kept in sync? How will that happen? No. In the long run the old textual files will no longer be used. It was a really bad idea from the start to parse several megabytes of ever-growing text files for every query submitted; it was showing up as CPU spikes in all sort of profiles. That model of implementing low-level operating system tools should just not be continued in the future. The systemd hwdb data can be queried almost for free. 1b) What is the long-term goal? Will one of the two go away? If so, how and when? Phase out hwdata, as soon as things have stabilized enough, the remaining users have been converted, and people get used to the new data source. 2) Breaks the hwdata-vs-code separation that was created earlier. What were the reasons of the separation, and why are they no longer applicable now? It's just not needed because of the /usr/lib/ etc/ and drop-in directory overwrite logic, that works for all other default vs. custom/update settings. It could go into another package when things have settled down, but there will be lots of other data in the same database shipped by systemd itself, like keymaps, power settings whitelists, which we cannot really and should not move out to a generic package. So all that theoretic code vs. data separation will not really mean much in the end, the hwdb will be much more than what hwdata was. It will take over quite a lot of what udev rules do today, and these should live in the main package. We will see, I think it's too early at the moment to introduce rather needless packaging complexities and dependencies for something that is still under development. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Kay Sievers (k...@vrfy.org) said: The hwdb is drop-in directory based, which means: - additionally installed data overwrites shipped data - stuff with the same file name in /etc/ disables stuff in /usr/lib/ Users can just install update packages, or add their own files, which will not conflict with the default shipped data. That's really not what we need, though - we have standing requests in That Other OS for regular updates of the hardware database as used by the tools, and having to spin systemd for this is way overkill. 1) Duplicates the data. 1a) Will the two databases be kept in sync? How will that happen? No. In the long run the old textual files will no longer be used. It was a really bad idea from the start to parse several megabytes of ever-growing text files for every query submitted; it was showing up as CPU spikes in all sort of profiles. That model of implementing low-level operating system tools should just not be continued in the future. The systemd hwdb data can be queried almost for free. Realistically, it's new textual files, replacing old textual files, which are then compiled into a binary file. I'm not sure why there's the intermediate step of a second textual format, but there is. 2) Breaks the hwdata-vs-code separation that was created earlier. What were the reasons of the separation, and why are they no longer applicable now? It's just not needed because of the /usr/lib/ etc/ and drop-in directory overwrite logic, that works for all other default vs. custom/update settings. That method implies the administrator wants to do the update without touching the code - what we have now is the *distributor* wants to do the update without touching the code. And for that case, packaging it seperately is simpler. It could go into another package when things have settled down, but there will be lots of other data in the same database shipped by systemd itself, like keymaps, power settings whitelists, which we cannot really and should not move out to a generic package. ... which, again, is not something you want to be updating the main systemd package all the time for. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Tue, Jan 29, 2013 at 9:06 PM, Bill Nottingham nott...@redhat.com wrote: Kay Sievers (k...@vrfy.org) said: The hwdb is drop-in directory based, which means: - additionally installed data overwrites shipped data - stuff with the same file name in /etc/ disables stuff in /usr/lib/ Users can just install update packages, or add their own files, which will not conflict with the default shipped data. That's really not what we need, though - we have standing requests in That Other OS for regular updates of the hardware database as used by the tools, and having to spin systemd for this is way overkill. Sure, create an RPM with non-conflicting files that are in /etc, or sort numerically *after* the default files. 1) Duplicates the data. 1a) Will the two databases be kept in sync? How will that happen? No. In the long run the old textual files will no longer be used. It was a really bad idea from the start to parse several megabytes of ever-growing text files for every query submitted; it was showing up as CPU spikes in all sort of profiles. That model of implementing low-level operating system tools should just not be continued in the future. The systemd hwdb data can be queried almost for free. Realistically, it's new textual files, replacing old textual files, which are then compiled into a binary file. I'm not sure why there's the intermediate step of a second textual format, but there is. Because the original text file is a hack and a format specific to the PCI/USB IDs, and makes no sense at all for a generic hwdb. 2) Breaks the hwdata-vs-code separation that was created earlier. What were the reasons of the separation, and why are they no longer applicable now? It's just not needed because of the /usr/lib/ etc/ and drop-in directory overwrite logic, that works for all other default vs. custom/update settings. That method implies the administrator wants to do the update without touching the code - what we have now is the *distributor* wants to do the update without touching the code. And for that case, packaging it seperately is simpler. Sure, there can be am any update packages as one wants, it will all work without any conflict with the original files. It could go into another package when things have settled down, but there will be lots of other data in the same database shipped by systemd itself, like keymaps, power settings whitelists, which we cannot really and should not move out to a generic package. ... which, again, is not something you want to be updating the main systemd package all the time for. Which, again, is not needed at all, as mentioned above. :) Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Kay Sievers (k...@vrfy.org) said: Realistically, it's new textual files, replacing old textual files, which are then compiled into a binary file. I'm not sure why there's the intermediate step of a second textual format, but there is. Because the original text file is a hack and a format specific to the PCI/USB IDs, and makes no sense at all for a generic hwdb. pci:v0010* ID_VENDOR_FROM_DATABASE=Allied Telesis, Inc It's not like that's that much more of a generic format. :) It could go into another package when things have settled down, but there will be lots of other data in the same database shipped by systemd itself, like keymaps, power settings whitelists, which we cannot really and should not move out to a generic package. ... which, again, is not something you want to be updating the main systemd package all the time for. Which, again, is not needed at all, as mentioned above. :) Is it strictly needed? No. Is it needlessly making the problem worse? Yes. Either you're intending for the lifetime of your OS to be shipping systemd updates that update the base data set, or you're intending to be shipping updated data sets in a separate package. Given systemd's churn rate, the first seems impractical, and if you're doing the second, why not split it out to begin with? (Much like the preset files.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Tue, Jan 29, 2013 at 11:13 PM, Bill Nottingham nott...@redhat.com wrote: Kay Sievers (k...@vrfy.org) said: Realistically, it's new textual files, replacing old textual files, which are then compiled into a binary file. I'm not sure why there's the intermediate step of a second textual format, but there is. Because the original text file is a hack and a format specific to the PCI/USB IDs, and makes no sense at all for a generic hwdb. pci:v0010* ID_VENDOR_FROM_DATABASE=Allied Telesis, Inc It's not like that's that much more of a generic format. :) It is entirely generic. It can carry arbitrary numbers of freely named key/value pairs basically unlimited in their size. Is extensible, uses flexible and extensible string matches like modaliases for kernel modules. Nothing you would find in the PCI/USB IDs hack. So what do you criticize here? It could go into another package when things have settled down, but there will be lots of other data in the same database shipped by systemd itself, like keymaps, power settings whitelists, which we cannot really and should not move out to a generic package. ... which, again, is not something you want to be updating the main systemd package all the time for. Which, again, is not needed at all, as mentioned above. :) Is it strictly needed? No. Is it needlessly making the problem worse? Yes. Worse? If we want an update package, it can drop the files in the same directory the default files are, and they will be used instead. Oh, and there are more copies of the PCI+USB IDs files in individual packages already, just run: find /usr -name pci.ids Maybe we should care about them first. :) Either you're intending for the lifetime of your OS to be shipping systemd updates that update the base data set, I don't intend to ship update packages in the context of systemd, we can just update the data in the package like we add patches for other fixes, in case we need an update. In the end PCI+USB IDs are just pretty boring names for humans, not used in the system itself. What makes them so special? It really sounds more like cosmetic care, than a real technical need to update these more often than we will need to update systemd anyway. or you're intending to be shipping updated data sets in a separate package. We can just do that, but still could ship the default data in the main package. Given systemd's churn rate, the first seems impractical, and if you're doing the second Hmm, check how often hwdata was updated, vs. systemd was updated :) http://pkgs.fedoraproject.org/cgit/hwdata.git/tree/hwdata.spec#n40 http://pkgs.fedoraproject.org/cgit/systemd.git/tree/systemd.spec#n730 why not split it out to begin with? (Much like the preset files.) Because preset files are for spins, and not generally useful static data. They should be provided by the people doing a spin, but all spins run on the same hardware. :) And because we are not there yet, with introducing rather fragile inter-package dependencies; things should have settled down before we do this. It's all still under development. And because a major part of the data the hwdb will carry in the future will be the equivalent of udev rules, and should not be shipped by a different package, because it it might carry specifics needed for a certain functionality, just like the udev rules do today. If we want to artificially declare the PCI+USB IDs different from the rest of the growing hwdb data, and split that into a different package and the rest not; sure, we can do that when things have stabilized, but so far I'm not really sure if that will give is a significant advantage, considering that updates just can be installed along with the default data. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 01/27/2013 04:36 PM, Michael Scherer wrote: Le dimanche 27 janvier 2013 à 09:49 -0500, Sam Varshavchik a écrit : Jaroslav Reznik writes: Announcing various systemd features in one announcement, see bellow: = Features/SystemdCalendarTimers = https://fedoraproject.org/wiki/Features/SystemdCalendarTimers Feature owner(s): Lennart Poettering lennart at poettering dot net systemd has supported timer units for activating services based on time since its inception. However, it only could schedule services based on monotonic time events (i.e. every 5 minutes). With this feature in place systemd also supports calendar time events (i.e. every monday morning 6:00 am, or at midnight on every 1st, 2nd, 3rd of each month if that's saturday or sunday). So, systemd wants to reinvent cron? That's not exactly the same. Since a timer can be activated by a unit, or triggered by a inactive unit, you could for example run a job only if a unit is running. You can also directly express stuff that cron do not do such as running X secondes after boot, even if this could be done in cron too ( like @reboot, sleep 40 stuff ). I guess also that since systemd support selinux ( https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl ), this permit to have a finer grained system for deciding who can or cannot disable a timer unit, with a selinux policy. On the other hand, cron just permit to edit the whole file, even if I guess you can work around this limitation with a clever system using /etc/cron.d/. I would say that work even before. If I should say according to number of bugs, not many users were using specific SElinux contexts for cronjob tasks. No objection to this feature, it might be very powerful for some use-cases. I'm afraid of situation, when half of cronjobs will be converted and half stay as is. Poor admins. Based on systemd's prior track record of various parts breaking randomly (namely the PrivateTmp fiasco), not really looking forward to this. You mean that PrivateTmp was not private at random, or that PrivateTmp activation broke software who relied on /tmp to be shared ? Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On 01/28/2013 02:56 PM, Marcela Mašláňová wrote: On 01/27/2013 04:36 PM, Michael Scherer wrote: Le dimanche 27 janvier 2013 à 09:49 -0500, Sam Varshavchik a écrit : Jaroslav Reznik writes: Announcing various systemd features in one announcement, see bellow: = Features/SystemdCalendarTimers = https://fedoraproject.org/wiki/Features/SystemdCalendarTimers Feature owner(s): Lennart Poettering lennart at poettering dot net systemd has supported timer units for activating services based on time since its inception. However, it only could schedule services based on monotonic time events (i.e. every 5 minutes). With this feature in place systemd also supports calendar time events (i.e. every monday morning 6:00 am, or at midnight on every 1st, 2nd, 3rd of each month if that's saturday or sunday). So, systemd wants to reinvent cron? That's not exactly the same. Since a timer can be activated by a unit, or triggered by a inactive unit, you could for example run a job only if a unit is running. You can also directly express stuff that cron do not do such as running X secondes after boot, even if this could be done in cron too ( like @reboot, sleep 40 stuff ). I guess also that since systemd support selinux ( https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl ), this permit to have a finer grained system for deciding who can or cannot disable a timer unit, with a selinux policy. On the other hand, cron just permit to edit the whole file, even if I guess you can work around this limitation with a clever system using /etc/cron.d/. I would say that work even before. If I should say according to number of bugs, not many users were using specific SElinux contexts for cronjob tasks. No objection to this feature, it might be very powerful for some use-cases. I'm afraid of situation, when half of cronjobs will be converted and half stay as is. Poor admins. It only makes sense to migrate the cron jobs that daemon/services bring in with them ( ca 38 out of 99 ) and I cant see how this is supposed to be poor sysadmins? It's simple if it's an daemon/service related it's being handled by systemd timers if not it's being handled by cron. The rest of those packages that bring in cron script should be fixed to require cron ( which is not the case now ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
How about crash/inconsistency recovery? That's either single user mode or multi user networked mode with blocks for anything to finish and nothing new starts and then setting up controlled environment which usually includes no cron interference. - Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: devel@lists.fedoraproject.org Sent: Monday, January 28, 2013 4:01:40 PM Subject: Re: Proposed F19 Feature: systemd features On 01/28/2013 02:56 PM, Marcela Mašláňová wrote: On 01/27/2013 04:36 PM, Michael Scherer wrote: Le dimanche 27 janvier 2013 à 09:49 -0500, Sam Varshavchik a écrit : Jaroslav Reznik writes: Announcing various systemd features in one announcement, see bellow: = Features/SystemdCalendarTimers = https://fedoraproject.org/wiki/Features/SystemdCalendarTimers Feature owner(s): Lennart Poettering lennart at poettering dot net systemd has supported timer units for activating services based on time since its inception. However, it only could schedule services based on monotonic time events (i.e. every 5 minutes). With this feature in place systemd also supports calendar time events (i.e. every monday morning 6:00 am, or at midnight on every 1st, 2nd, 3rd of each month if that's saturday or sunday). So, systemd wants to reinvent cron? That's not exactly the same. Since a timer can be activated by a unit, or triggered by a inactive unit, you could for example run a job only if a unit is running. You can also directly express stuff that cron do not do such as running X secondes after boot, even if this could be done in cron too ( like @reboot, sleep 40 stuff ). I guess also that since systemd support selinux ( https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl ), this permit to have a finer grained system for deciding who can or cannot disable a timer unit, with a selinux policy. On the other hand, cron just permit to edit the whole file, even if I guess you can work around this limitation with a clever system using / etc/cron.d / . I would say that work even before. If I should say according to number of bugs, not many users were using specific SElinux contexts for cronjob tasks. No objection to this feature, it might be very powerful for some use-cases. I'm afraid of situation, when half of cronjobs will be converted and half stay as is. Poor admins. It only makes sense to migrate the cron jobs that daemon/services bring in with them ( ca 38 out of 99 ) and I cant see how this is supposed to be poor sysadmins? It's simple if it's an daemon/service related it's being handled by systemd timers if not it's being handled by cron. The rest of those packages that bring in cron script should be fixed to require cron ( which is not the case now ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Jaroslav Reznik writes: Announcing various systemd features in one announcement, see bellow: = Features/SystemdCalendarTimers = https://fedoraproject.org/wiki/Features/SystemdCalendarTimers Feature owner(s): Lennart Poettering lennart at poettering dot net systemd has supported timer units for activating services based on time since its inception. However, it only could schedule services based on monotonic time events (i.e. every 5 minutes). With this feature in place systemd also supports calendar time events (i.e. every monday morning 6:00 am, or at midnight on every 1st, 2nd, 3rd of each month if that's saturday or sunday). So, systemd wants to reinvent cron? Based on systemd's prior track record of various parts breaking randomly (namely the PrivateTmp fiasco), not really looking forward to this. pgpj_XsprYnM9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Le dimanche 27 janvier 2013 à 09:49 -0500, Sam Varshavchik a écrit : Jaroslav Reznik writes: Announcing various systemd features in one announcement, see bellow: = Features/SystemdCalendarTimers = https://fedoraproject.org/wiki/Features/SystemdCalendarTimers Feature owner(s): Lennart Poettering lennart at poettering dot net systemd has supported timer units for activating services based on time since its inception. However, it only could schedule services based on monotonic time events (i.e. every 5 minutes). With this feature in place systemd also supports calendar time events (i.e. every monday morning 6:00 am, or at midnight on every 1st, 2nd, 3rd of each month if that's saturday or sunday). So, systemd wants to reinvent cron? That's not exactly the same. Since a timer can be activated by a unit, or triggered by a inactive unit, you could for example run a job only if a unit is running. You can also directly express stuff that cron do not do such as running X secondes after boot, even if this could be done in cron too ( like @reboot, sleep 40 stuff ). I guess also that since systemd support selinux ( https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl ), this permit to have a finer grained system for deciding who can or cannot disable a timer unit, with a selinux policy. On the other hand, cron just permit to edit the whole file, even if I guess you can work around this limitation with a clever system using /etc/cron.d/. Based on systemd's prior track record of various parts breaking randomly (namely the PrivateTmp fiasco), not really looking forward to this. You mean that PrivateTmp was not private at random, or that PrivateTmp activation broke software who relied on /tmp to be shared ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Sun, Jan 27, 2013 at 3:49 PM, Sam Varshavchik mr...@courier-mta.com wrote: Jaroslav Reznik writes: Announcing various systemd features in one announcement, see bellow: = Features/SystemdCalendarTimers = https://fedoraproject.org/wiki/Features/SystemdCalendarTimers Feature owner(s): Lennart Poettering lennart at poettering dot net systemd has supported timer units for activating services based on time since its inception. However, it only could schedule services based on monotonic time events (i.e. every 5 minutes). With this feature in place systemd also supports calendar time events (i.e. every monday morning 6:00 am, or at midnight on every 1st, 2nd, 3rd of each month if that's saturday or sunday). So, systemd wants to reinvent cron? Based on systemd's prior track record of various parts breaking randomly (namely the PrivateTmp fiasco), not really looking forward to this. cron is not going anywhere i.e you can still use cron. btw. from the feature page It doesn't affect anybody who doesn't use this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
