Re: [gentoo-dev] eselect init
On Fri, Jun 21, 2013 at 04:39:59AM +0200, Michał Górny wrote: > Dnia 2013-06-20, o godz. 15:56:09 > William Hubbs napisał(a): > > > On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote: > > > There is a new version of eselect-init in the systemd-love overlay to > > > play with. > > > The new version saw the following major changes: > > > > > > - the /sbin/init (aka the symlink that eselect-init handles) can be > > > changed to whatever one wants through make.conf [1] (this is a compile > > > time option, as documented in the eclass) > > > > Why do we need to mess with /sbin/init at all? > > Yes, we do because we don't want sysvinit randomly getting run > as fallback and messing with our systems. I don't understand what you are saying here. If eselect-init installs the wrapper as /sbin/einit, we don't have to touch /sbin/init at all, then, the only thing someone would have to do is to add an entry to their boot loader with init=/sbin/einit on the kcl to use it. > > I like the suggestion that came up here on the list a while back, have > > the eselect init module install its own symlink at, say, /sbin/einit. > > You would still have to have the user edit their boot loader > > configuration file one time if they want to use this, but this makes it > > completely opt-in. > > Plus hacking kernel sources to disable /sbin/init fallback. No, there is no reason we would have to hack anything in the kernel sources. William signature.asc Description: Digital signature
Re: [gentoo-dev] eselect init
Dnia 2013-06-20, o godz. 15:56:09 William Hubbs napisał(a): > On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote: > > There is a new version of eselect-init in the systemd-love overlay to play > > with. > > The new version saw the following major changes: > > > > - the /sbin/init (aka the symlink that eselect-init handles) can be > > changed to whatever one wants through make.conf [1] (this is a compile > > time option, as documented in the eclass) > > Why do we need to mess with /sbin/init at all? Yes, we do because we don't want sysvinit randomly getting run as fallback and messing with our systems. > I like the suggestion that came up here on the list a while back, have > the eselect init module install its own symlink at, say, /sbin/einit. > You would still have to have the user edit their boot loader > configuration file one time if they want to use this, but this makes it > completely opt-in. Plus hacking kernel sources to disable /sbin/init fallback. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote: > There is a new version of eselect-init in the systemd-love overlay to play > with. > The new version saw the following major changes: > > - the /sbin/init (aka the symlink that eselect-init handles) can be > changed to whatever one wants through make.conf [1] (this is a compile > time option, as documented in the eclass) Why do we need to mess with /sbin/init at all? I like the suggestion that came up here on the list a while back, have the eselect init module install its own symlink at, say, /sbin/einit. You would still have to have the user edit their boot loader configuration file one time if they want to use this, but this makes it completely opt-in. The other advantage of this is you don't have to mess with any init system ebuilds at all. > - the wrapper and its code paths are now documented in the > eselect-init eclass [2] [3] This eclass could go away entirely if you don't try to control /sbin/init. > If you intend to use switch between systemd to openrc (and vice > versa), make sure to install the rest of the packages in that overlay. > At the moment, if you want to switch, you also need to use > eselect-settingsd. However, I am planning to drop eselect-settingsd: > openrc-settingsd and systemd share the same settingsd dbus interface > while they call different executables, systemd initializes its dbus > services without relying on dbus activation, so the Exec= part of the > service descriptor file is currently set to /bin/false, this rings a > bell :D, because it is possible to replace /bin/false with a script > that starts the respective services when dbus activation is used > (which means that systemd hasn't booted the system). This would make > possible to remove the blocker dependency in openrc-settingsd and > systemd somehow. Keep up the good work; the more simple we can make the integration the better it will be. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: eselect init
On Thu, Jun 20, 2013 at 06:10:27PM +0100, Steven J. Long wrote: > Fabio Erculiani wrote: > > - only init is currently handled by eselect-init, which is now using a > > very small wrapper POSIX shell script to redirect the calls to the > > currently running init > > How does say, switching inittab format, work under this setup? I think this is a separate issue -- if busybox init's inittab is a different format than sysvinbb's inittab, it should also use a different file name, e.g. bb-inittab or something similar. bb could fall back to inittab, but I think it should look for something liike bb-inittab first. That way eselect init wouldn't have to worry about it at all. William signature.asc Description: Digital signature
Re: [gentoo-dev] Introduce global dmalloc USE flag?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/06/13 01:05 AM, Michał Górny wrote: > Dnia 2013-06-13, o godz. 09:35:54 "Dennis Lan (dlan)" > napisał(a): > >> also 4) app-admin/conserver 5) net-nds/ypbind 6) net-fs/samba 7) >> net-analyzer/scli 8) net-analyzer/traceproto 6) net-misc/siproxd >> >> use dmalloc but controlled under USE=debug > > Do those use USE=debug solely for dmalloc or does it imply other > stuff? Therefore: will it be possible to use USE=dmalloc in those > packages? > and to follow up, if we assume that USE="debug" does more than just build the package against the dmalloc lib (which is likely), is there any particular benefit to USE="debug -dmalloc" ? Or USE="dmalloc - -debug" ? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlHDSyEACgkQ2ugaI38ACPAHUwEAqFFDyarLSE8I/k8eKBUibmxu qZT2pnaaMj3nPEqrFxYBAIsIP8HAHR5mIaLBHKPiR6/oI/cxcu3h1XFodpbERO4t =T2KX -END PGP SIGNATURE-
[gentoo-dev] Re: eselect init
Fabio Erculiani wrote: > - only init is currently handled by eselect-init, which is now using a > very small wrapper POSIX shell script to redirect the calls to the > currently running init How does say, switching inittab format, work under this setup? -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] netsurf.eclass proposal
On 06/20/2013 05:03 PM, Mike Gilbert wrote: > On Thu, Jun 20, 2013 at 10:56 AM, hasufell wrote: >> On 06/20/2013 04:48 PM, Mike Gilbert wrote: >>> On Thu, Jun 20, 2013 at 10:31 AM, Michael Weber wrote: On 06/19/2013 06:23 PM, Mike Gilbert wrote: > I'm all for having fun, but I think the intent was to keep the > multilib-build eclass usage to a minimum. Sorry, I've missed that agreement, can you point me to it, please? >>> >>> Just something I picked up from various IRC conversations with mgorny >>> and pals. More precisely, I should say it was the eclass author's >>> intent, and it is a principle with which I personally agree. >>> >> >> The eclass authors opinion is not a policy. Policies must be discussed. >> > > I missed the part where anyone mentioned a policy... > I did... and by that I mean: let's discuss it! :D
Re: [gentoo-dev] netsurf.eclass proposal
On Thu, Jun 20, 2013 at 10:56 AM, hasufell wrote: > On 06/20/2013 04:48 PM, Mike Gilbert wrote: >> On Thu, Jun 20, 2013 at 10:31 AM, Michael Weber wrote: >>> On 06/19/2013 06:23 PM, Mike Gilbert wrote: I'm all for having fun, but I think the intent was to keep the multilib-build eclass usage to a minimum. >>> Sorry, I've missed that agreement, can you point me to it, please? >>> >> >> Just something I picked up from various IRC conversations with mgorny >> and pals. More precisely, I should say it was the eclass author's >> intent, and it is a principle with which I personally agree. >> > > The eclass authors opinion is not a policy. Policies must be discussed. > I missed the part where anyone mentioned a policy...
Re: [gentoo-dev] netsurf.eclass proposal
On 06/20/2013 04:48 PM, Mike Gilbert wrote: > On Thu, Jun 20, 2013 at 10:31 AM, Michael Weber wrote: >> On 06/19/2013 06:23 PM, Mike Gilbert wrote: >>> I'm all for having fun, but I think the intent was to keep the >>> multilib-build eclass usage to a minimum. >> Sorry, I've missed that agreement, can you point me to it, please? >> > > Just something I picked up from various IRC conversations with mgorny > and pals. More precisely, I should say it was the eclass author's > intent, and it is a principle with which I personally agree. > The eclass authors opinion is not a policy. Policies must be discussed.
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
Thanks for the offer, I appreciate it, but I have to decline this time. -- Fabio Erculiani
Re: [gentoo-dev] netsurf.eclass proposal
On Thu, Jun 20, 2013 at 10:31 AM, Michael Weber wrote: > On 06/19/2013 06:23 PM, Mike Gilbert wrote: >> I'm all for having fun, but I think the intent was to keep the >> multilib-build eclass usage to a minimum. > Sorry, I've missed that agreement, can you point me to it, please? > Just something I picked up from various IRC conversations with mgorny and pals. More precisely, I should say it was the eclass author's intent, and it is a principle with which I personally agree. > Turning abi_x86_32 on/off in a global scale is a decision to be made by > the user. With all consequences (initial compile time vs recompiles on > reconsiderations). It doesn't make that difference if turned off. > But if needed, it's just there. > It's a good point. As long as we are willing to support users who do not enable it globally, I guess it is fine.
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/2013 04:39 AM, Fabio Erculiani wrote: > The final outcome I would love to see is that everybody eventually > graduates from kindergarten :-) > And perhaps introduce a "culture-fit" score in the recruiting, > mentoring process. > Fabio, How about instead of quitting you run for student^H^H^H^H^H Gentoo council? I know why I'm running, and it's not because I think the status quo is acceptable. I nominate lxnay for council, on the basis that he must officially withdraw his retirement request first. Now accept so I can vote for you. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRwxOqAAoJEKXdFCfdEflKoCEP/0Ka8h8rxasTjMdyTWiMXUzg iAmKIWFODe9CjOSbzEkqOvtGkL/qlKIPqO9OINJHktPWp+Izd2dOTvTARwO6ngHn MIUA3uaxCkHbk78uQQAf7TJkP4WaaShXEtA3p5mh52i4mWhlPuvApzWv/Bfcnzl7 jtACqURZecu66TQS+S6Q1zozwq+EojjnCCb4HNS4A3ck8ZGGQ8Kn5YlbfWpWxcrS TQ87KM/wdcYZzdOpzN4LwA9DAakobMKVfGcHQPqXyONOY9mju/bYJ5/AJMwthxXx YWIhfcTMpS69juYTfDXhoJmh1nGhZE17eXFmcGXdxOeMpuGUKJekBWe6/qPbuJpy pAT0CgDLxWgT7MU1faxNiur4SYj5xxb6IDP+emUEiyWgThsmy7dK3GvC+s6z4AzY ElZSkbrpEU7q+dsTBrvWd7bhgZJprR7uJxGzBLtnjk/gMhVSk+EH8SGfbTAeHpTp i34Z57UaCIhjohGZgJBDAEoMO4oq9QLkCXfwZeSmsSZykeiEUn/lx8hsydwgzxNj 16u7XT7hlPxauMoYADjM5qxVG+34qaCOv90RiDM6YHXaN3s9Jn1AERLpQmoPbEHk qCMJyhBbf5rZhMrcpV5P0g5VPp9aRvGQjem0Q7vmJWLBxR7vRftf8lfxfP0mtWJ0 pJPBLv9FxlDLaXTamaQv =aEyq -END PGP SIGNATURE-
Re: [gentoo-dev] netsurf.eclass proposal
On 06/19/2013 06:23 PM, Mike Gilbert wrote: > I guess the follow-up question is this: > > Are there any consumers of these libraries which require the 32-bit > (x86) ABI to be installed? No ... t jet. And not that likely to arise, but I'm out of crystal balls ;-) . > I'm all for having fun, but I think the intent was to keep the > multilib-build eclass usage to a minimum. Sorry, I've missed that agreement, can you point me to it, please? > Otherwise, you'll end up installing libraries that will never be used. Same goes for all corner cases of emul-linux-members. Turning abi_x86_32 on/off in a global scale is a decision to be made by the user. With all consequences (initial compile time vs recompiles on reconsiderations). It doesn't make that difference if turned off. But if needed, it's just there. [Said that, I hope it doesn't propagate -abi_x86_32 down the dep tree.] [And I seriously doubt that any user has the patience to watch us migrate the tree on a per-request basis. Let's be honest then and abandon it. -- not my standpoint, under given circumstances of ready-to-use implementation.] Michael -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On Thu, Jun 20, 2013 at 9:32 AM, Michael Weber wrote: > > And it's not fair to pick on the candidates by putting them under > close watch (mentor ship, probation already in place) and let the > established ones walk away. Tend to agree, and I don't think it is as productive either. Set policies and enforce them, and the culture will gradually align to where we want it to go. Right now our culture probably turns away people who would be a good "cultural fit" because the reality is that they're really not a good fit because our current culture is lousy. If we fixed our culture, then people who want to flame away are likely to not bother applying because they see others like them being hounded by devrel. Policy enforcement isn't just corrective - it is preventative. When you set examples, others follow them beyond just the immediate target. Over time, properly-applied discipline is something that puts itself out of business. Rich
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 06/20/2013 08:32 AM, Michael Weber wrote: > [talking about recruiting] > > Please don't focus on new arrivals, we should all be under investigation. > > I don't know the distribution of dev-ship-duration, but (hopefully) > it's long enough to justify a look at the stock. > > And it's not fair to pick on the candidates by putting them under > close watch (mentor ship, probation already in place) and let the > established ones walk away. > > True, I'm just saying that we can help prevent this from happening if we screened our candidates a little better. We should keep going with policing our existing devs as well of course. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [talking about recruiting] Please don't focus on new arrivals, we should all be under investigation. I don't know the distribution of dev-ship-duration, but (hopefully) it's long enough to justify a look at the stock. And it's not fair to pick on the candidates by putting them under close watch (mentor ship, probation already in place) and let the established ones walk away. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlHDBGsACgkQknrdDGLu8JAIyAD6Apa6awYhImRLpDKwYG8Jled5 aCCm2tI6XF/yvdp+ZWcBAJGKvPVDWNePrLCLbzGRk3Q3sOIxI3yoSuHJdt9GR7Rc =MnYK -END PGP SIGNATURE-
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 20.6.2013 16.07, Matthew Thode wrote: > On 06/20/2013 07:49 AM, Petteri Räty wrote: >> On 20.6.2013 14.01, Matthew Thode wrote: >>> On 06/20/2013 03:39 AM, Fabio Erculiani wrote: The final outcome I would love to see is that everybody eventually graduates from kindergarten :-) And perhaps introduce a "culture-fit" score in the recruiting, mentoring process. >>> As an employee that works for a company that requires a culture fit >>> (very important to us). This helps a ton. >>> >> >> Sounds good in theory but how do you calculate that score? In companies >> there's much more interactions that allow to accumulate information for >> such things. >> >> Regards, >> Petteri >> > We do it during the interview process. I kinda think the best analog we > can do is to watch both before and during the probation period to see > how well they fit. > That's already part of the process. What we can improve is that I don't remember mentors reporting back on problems during the probation period. Maybe automate that in some way so the mentors get emails and should respond. Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 06/20/2013 08:11 AM, hasufell wrote: > On 06/20/2013 03:07 PM, Matthew Thode wrote: >> On 06/20/2013 07:49 AM, Petteri Räty wrote: >>> On 20.6.2013 14.01, Matthew Thode wrote: On 06/20/2013 03:39 AM, Fabio Erculiani wrote: > The final outcome I would love to see is that everybody > eventually graduates from kindergarten :-) And perhaps > introduce a "culture-fit" score in the recruiting, mentoring > process. > As an employee that works for a company that requires a culture fit (very important to us). This helps a ton. >>> >>> Sounds good in theory but how do you calculate that score? In >>> companies there's much more interactions that allow to accumulate >>> information for such things. >>> >>> Regards, Petteri >>> >> We do it during the interview process. I kinda think the best >> analog we can do is to watch both before and during the probation >> period to see how well they fit. > > > Maybe that period should be extended. Longer period -> more carful > thinking of your own actions -> becomes a habit. > That might be a good idea. I just wish that we could do some sort of culture fit before they get devship (should be a prerequisite). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/2013 03:07 PM, Matthew Thode wrote: > On 06/20/2013 07:49 AM, Petteri Räty wrote: >> On 20.6.2013 14.01, Matthew Thode wrote: >>> On 06/20/2013 03:39 AM, Fabio Erculiani wrote: The final outcome I would love to see is that everybody eventually graduates from kindergarten :-) And perhaps introduce a "culture-fit" score in the recruiting, mentoring process. >>> As an employee that works for a company that requires a culture >>> fit (very important to us). This helps a ton. >>> >> >> Sounds good in theory but how do you calculate that score? In >> companies there's much more interactions that allow to accumulate >> information for such things. >> >> Regards, Petteri >> > We do it during the interview process. I kinda think the best > analog we can do is to watch both before and during the probation > period to see how well they fit. > Maybe that period should be extended. Longer period -> more carful thinking of your own actions -> becomes a habit. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRwv+AAAoJEFpvPKfnPDWzCtMH/1K4jB/uWciUQaoQ1wT6DI1O DVPjyOyqYzK3IEpZZS4kBrVlL3Knumd41hSHhnnHAc82hcEOeJBAZedpXBuNjsj/ qH64v/nIAUR3rs7TSOOdy0cqSlOSOcU2tlZ4j3eW6Ddihks4mO8cZNnURTi/gzGn DWqrqJHNsefOEUR+GpA0NkaK7/ry/flbSvruQ2wqzwy9Zfgdw7W+NaM2G4FERxGL 0qkQJ+DEfB0wwIf1hz68GIw12ZcKz28qPwSYtNQjliGCyZFxGeZJeG15uUhTDqYW pNRU1BZIwEnoK9vUNfapVeB3EVkJ6PXJ3uXsjCZOBFB1ekS0b+4lDNdaarcBvNI= =7DA8 -END PGP SIGNATURE-
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 06/20/2013 07:49 AM, Petteri Räty wrote: > On 20.6.2013 14.01, Matthew Thode wrote: >> On 06/20/2013 03:39 AM, Fabio Erculiani wrote: >>> The final outcome I would love to see is that everybody eventually >>> graduates from kindergarten :-) >>> And perhaps introduce a "culture-fit" score in the recruiting, >>> mentoring process. >>> >> As an employee that works for a company that requires a culture fit >> (very important to us). This helps a ton. >> > > Sounds good in theory but how do you calculate that score? In companies > there's much more interactions that allow to accumulate information for > such things. > > Regards, > Petteri > We do it during the interview process. I kinda think the best analog we can do is to watch both before and during the probation period to see how well they fit. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 20.6.2013 14.01, Matthew Thode wrote: > On 06/20/2013 03:39 AM, Fabio Erculiani wrote: >> The final outcome I would love to see is that everybody eventually >> graduates from kindergarten :-) >> And perhaps introduce a "culture-fit" score in the recruiting, >> mentoring process. >> > As an employee that works for a company that requires a culture fit > (very important to us). This helps a ton. > Sounds good in theory but how do you calculate that score? In companies there's much more interactions that allow to accumulate information for such things. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 06/20/2013 03:39 AM, Fabio Erculiani wrote: > The final outcome I would love to see is that everybody eventually > graduates from kindergarten :-) > And perhaps introduce a "culture-fit" score in the recruiting, > mentoring process. > As an employee that works for a company that requires a culture fit (very important to us). This helps a ton. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Temporary DevRel actions for CoC violations
Roy Bamford posted on Thu, 20 Jun 2013 09:21:07 +0100 as excerpted: > On 06/19/13 18:35:49, Markos Chandras wrote: >> >> It is unfortunate to observe constant bullying, insults and trolling >> across our public media. Developers have been warned over and over that >> such behaviour is not acceptable and they should try to behave >> properly. However, people have ignored such warnings for a very long >> time. This ends today. >> > This has my support. > > I would like to see council voice their complete support publically too, > as thats one of the reasons proctors failed. ++ Also, I know there's sensitivity in providing real-case examples and contrived examples might not work too well, but... If possible, it'd be useful to have (say) 2-3 good examples of triggers. [TL;DR folks stop there.] At least once an action is finalized (whatever way) by full devrel or council, arguably an action-triggering public statement in some media deserves an equally public apology (if the original offender finds it appropriate) or rebuttal (if such rebuttal on behalf of gentoo is necessary due to lack of apology) by the same media. IIRC I've been called on to issue an apology once. I don't remember the details, but I do remember that I hadn't intended it to sound the way it did and I unconditionally apologized once someone pointed out how it read from a perspective other than my own. I've also called for a public apology a (small) handful of times, only once recently, from a user-poster not a dev, here. One other user replied to that backing me up but indicating that he thought a few devs might need such a call from time to time as well, while I've not seen anything besides that one post that I considered "beyond the pale" far enough to call for an apology on in /quite/ some time now, so evidently he's a bit more sensitive than I am at this point. Which means either that the potentially triggering instances aren't happening on this list, or that my sensitivity needs reset. I'm worried about the latter, and an example or two (anyone who believes they might have been out of line care to post a link/apology?) might help me with that reset, or clarify that the triggers haven't been happening here, but in IRC or on the blogs or whatever. Either would be useful. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] eselect init
There is a new version of eselect-init in the systemd-love overlay to play with. The new version saw the following major changes: - the /sbin/init (aka the symlink that eselect-init handles) can be changed to whatever one wants through make.conf [1] (this is a compile time option, as documented in the eclass) - only init is currently handled by eselect-init, which is now using a very small wrapper POSIX shell script to redirect the calls to the currently running init [2] - the wrapper and its code paths are now documented in the eselect-init eclass [2] [3] You need systemd and sysvinit from the same overlay for it to work. If you intend to use switch between systemd to openrc (and vice versa), make sure to install the rest of the packages in that overlay. At the moment, if you want to switch, you also need to use eselect-settingsd. However, I am planning to drop eselect-settingsd: openrc-settingsd and systemd share the same settingsd dbus interface while they call different executables, systemd initializes its dbus services without relying on dbus activation, so the Exec= part of the service descriptor file is currently set to /bin/false, this rings a bell :D, because it is possible to replace /bin/false with a script that starts the respective services when dbus activation is used (which means that systemd hasn't booted the system). This would make possible to remove the blocker dependency in openrc-settingsd and systemd somehow. [1] https://github.com/Sabayon/systemd-love/commit/ced29311348a81a2573b030b1316f1c3a0335c5b [2] https://github.com/Sabayon/systemd-love/commit/9eea3ff713c8fa0391e7b1bfa494d533dc21c0be [3] https://github.com/Sabayon/systemd-love/blob/master/eclass/eselect-init.eclass -- Fabio Erculiani
Re: [gentoo-dev] repoman commit unexpectedly drops FEATURES="sign" on error
Dnia 2013-06-19, o godz. 19:59:08 ""Paweł Hajdan, Jr."" napisał(a): > I was surprised by repoman just dropping FEATURES="sign" . I'm aware > that at that time it has to commit an updated Manifest to prevent > breakages, so if gpg fails it proceeds, but is there something it could > do to check gpg sanity before committing anything? I'm pretty sure this was discussed already, either here or on bugzie. Doing test signatures won't cover all failures. IMHO the best thing to do would be to drop CVS keywords and let repoman do normal commits instead of this two-step thing. But some of the devs really prefer to keep them, at least until we migrate to git and have better ways of e.g. checking the file version. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
The final outcome I would love to see is that everybody eventually graduates from kindergarten :-) And perhaps introduce a "culture-fit" score in the recruiting, mentoring process. -- Fabio Erculiani
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 20 June 2013 04:53, Diego Elio Pettenò wrote: > Does this mean the QA lead finally gets to suspend people who are patently > not suited for developing a stable distribution without asking devrel? > Because last time we got into the same judge, jury, and executioner > argument, which I guess was just sent for the gallows (pun intended). > > Mind, it's not like I disagree with at least one of the actions that you > took recently, but given your surge approach I would like to point out that > is not your task judging code quality, and yes that does make me > uncomfortable, that you want to pick up the full power at once, and not > collaborate with whom should have been involved in the process. > > > Diego Elio Pettenò — Flameeyes > flamee...@flameeyes.eu — http://blog.flameeyes.eu/ > > There is a high chance I drive this thread off-topic but: I believe the QA lead always had the power to suspend people if they break the tree but like I explained to my e-mail this is a temporary solution so it's not something we want in the long-term. Such actions need to be discussed internally. It's true that is not our task to judge code. But my understanding was that QA is not willing to pick up this task. We've seen numerous examples of bad commits or CCs of qa@g.o in bugs with several technical disagreements and not a single QA warning "you are doing it wrong". I could easily be wrong though as I can't track everything. My opinion is that you need to bring more people in QA so you can delegate the "technical" tasks to them. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 06/20/2013 05:53 AM, Diego Elio Pettenò wrote: > Does this mean the QA lead finally gets to suspend people who are > patently not suited for developing a stable distribution without > asking devrel? Because last time we got into the same judge, jury, > and executioner argument, which I guess was just sent for the gallows > (pun intended). I'm not against that, but I prefer setting some fast track involving at most 3 people and some procedure also for it. E.g. : you can ask for 6h suspension on direct request and by contacting a single devrel person to get an 1week suspension within 2 days. > Mind, it's not like I disagree with at least one of the actions that > you took recently, but given your surge approach I would like to > point out that is not your task judging code quality, and yes that > does make me uncomfortable, that you want to pick up the full power > at once, and not collaborate with whom should have been involved in > the process. As said, this whole thing is just an interim solution till fast-path procedures get deployed. lu
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 06/19/13 18:35:49, Markos Chandras wrote: > Hi, > > It is unfortunate to observe constant bullying, insults and trolling > across our public media. Developers have been warned over and over > that > such behaviour is not acceptable and they should try to behave > properly. However, people have ignored such warnings for a very long > time. This ends today. > [snip] > > -- > Regards, > Markos Chandras - Gentoo Linux Developer > http://dev.gentoo.org/~hwoarang > This has my support. I would like to see council voice their complete support publically too, as thats one of the reasons proctors failed. -- Regards, Roy Bamford (Neddyseagoon) an member of gentoo-ops forum-mods trustees
