[gentoo-dev] Re: Making systemd more accessible to "normal" users

2013-05-09 Thread Steven J. Long
Rich Freeman wrote:
> I think it really needs to be accommodated in the same way as openrc
> init.d scripts.  I'm not saying that maintainers should be required to
> create them if they're missing (they don't even have to do that for
> openrc init.d scripts).  However, if users or other devs contribute
> them and vouch that they work, then they should be included in
> packages.

++ absolutely.

And if you want to change init=, edit the file, from a script if you wish
to automate it, after checking that everything is in-place.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)



[gentoo-dev] Re: OpenRC supporting systemd units

2013-05-09 Thread Steven J. Long
Ambroz Bizjak wrote:
> Rich Freeman wrote:
> > Init.d scripts are programs - they could probably do just about anything.
> 
> They couldn't monitor a process and restart it when it crashes, as
> specified by the restart options in the unit file. That is, without
> significant modifications in the way OpenRC works, such as adding a
> monitoring process, or hacks such as launching a daemon that monitor
> that process specifically.

Actually a shell script can do that very easily, given a daemon that either
doesn't self-background, or can be given a switch to tell it not to "daemonize",
which reasonably modern services should support. See Q: 3.2 here:
  http://mywiki.wooledge.org/ProcessManagement (the linked "Wrapper Script" page
is interesting as well.)

That's assuming you don't want a simple respawn in inittab. Another common
loop is:

until somesrv -f "$blah"; do
e=$?
# stuff on abnormal termination, check situation etc
all_ok || exit # exits $?, or use $e or 1..
done
# svc terminated normally
:
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)



[gentoo-dev] Last rites: kde-misc/akonadi-google

2013-05-09 Thread Johannes Huber
+# Johannes Huber  (09 May 2013)
+# Masked for removal in 30 days. Package is obsolete.
+# Upstream replaced it with net-libs/libkgapi.
+kde-misc/akonadi-google
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Making systemd more accessible to "normal" users

2013-05-09 Thread Pacho Ramos
El jue, 09-05-2013 a las 18:44 +0200, Michał Górny escribió:
[...]
> A similar variant is implemented in app-portage/install-mask which maps
> names obtained from ${FILESDIR} to paths.
> 

Didn't know that utility :O, thanks! (maybe, at least, a blog entry
could have been added when you did this tool ;))




Re: [gentoo-dev] [PATCH] gnome2.eclass does not respect ECONF_SOURCE

2013-05-09 Thread Pacho Ramos
El mié, 08-05-2013 a las 20:59 -0400, Mike Frysinger escribió:
> On Wednesday 05 December 2012 18:02:51 Doug Goldstein wrote:
> > -   if grep -q "disable-scrollkeeper" configure; then
> > +   if grep -q "disable-scrollkeeper" ${ECONF_SOURCE:-.}/configure; then
> 
> ECONF_SOURCE should be quoted
> -mike

If it doesn't cause any problem (it shouldn't, I think), feel free to
commit adding the quotes. Thanks for noticing! (will CC gnome team to
keep them aware)




Re: [gentoo-dev] Making systemd more accessible to "normal" users

2013-05-09 Thread Rich Freeman
On Thu, May 9, 2013 at 12:44 PM, Michał Górny  wrote:
> We should probably consider extending the INSTALL_MASK a bit. A good
> idea would be to allow repositories to pre-define names
> for INSTALL_MASK (alike USE flags) and allow portage to control them
> over those names.

We'd need a corresponding way to unmask stuff as well, if we went that
route.  It would add value for stuff like the embedded profile, but I
wouldn't want to see it used in the base profiles.

Rich



Re: [gentoo-dev] Making systemd more accessible to "normal" users

2013-05-09 Thread Michał Górny
On Thu, 09 May 2013 05:56:42 -0400
"Anthony G. Basile"  wrote:

> On 05/08/2013 10:01 PM, Jeroen Roovers wrote:
> > On Wed, 8 May 2013 21:48:36 -0400
> > "Walter Dnes"  wrote:
> >
> >>Wouldn't the "systemd" USE flag be the appropriate one to key on?
> >> The description in /usr/portage/profiles/use.desc says...
> >>
> >> systemd - Enable use of systemd-specific libraries and features like
> >> socket activation or session tracking
> >>
> >> Surely, units files qualify as "systemd-specific features".
> >
> > https://bugs.gentoo.org/show_bug.cgi?id=198901
> 
> People keep saying disk space is not an issue but it is on embedded 
> systems.  Even 4k or one i-node.  So the choice to not install unit 
> files is important.  I'm sympathetic to the idea of reducing use flags 
> and I would really not like to see USE="openrc" or "systemd" everywhere. 
>   Without having tested, it does seem that INSTALL_MASK is sufficient. 
> I recommend going that route and documenting it.

We should probably consider extending the INSTALL_MASK a bit. A good
idea would be to allow repositories to pre-define names
for INSTALL_MASK (alike USE flags) and allow portage to control them
over those names.

A similar variant is implemented in app-portage/install-mask which maps
names obtained from ${FILESDIR} to paths.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC: cartesian product extension to keyword system

2013-05-09 Thread Alexey Shvetsov
В письме от 29 апреля 2013 15:43:03 пользователь Jeroen Roovers написал:
> On Mon, 29 Apr 2013 16:14:51 +0900
> 
> heroxbd  wrote:
> > KEYWORDS="~hppa-hpux ~m68k-mint ~ppc-aix ~x64-solaris ~x86-interix["]
> > 
> > KEYWORDS_ARCH="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64
> > ~s390 ~sh ~sparc ~x86"
> 
> Regardless of your chance of success in making the extra complexity
> manageable, I think moving the tradition KEYWORDS value to
> KEYWORDS_ARCH, and reusing KEYWORDS for something else , would
> needlessly increase the work required to "migrate" the portage tree.
> 
> Why not leave KEYWORDS what it is right now, and expand/change its
> meaning using alternate variables so that you can (indefinitely)
> maintain backward compatibility?

Its not necessary. We simply may not define KEYWORDS but only define KEYWORDS_* 
vars. So old package managers versions will treat that as we have empty 
keywords

> 
> 
>  jer
-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] OpenRC supporting systemd units

2013-05-09 Thread Peter Stuge
Michael Mol wrote:
> obviously you have an interesting position as a dev in a distribution,
> and you might make your change there, but that certainly shouldn't be
> your default course of action.

+1 and not just for unit files.


//Peter


pgpQGx9XaD1PC.pgp
Description: PGP signature


Re: [gentoo-dev] Making systemd more accessible to "normal" users

2013-05-09 Thread Rich Freeman
On Wed, May 8, 2013 at 10:18 PM, Walter Dnes  wrote:
> On Wed, May 08, 2013 at 10:31:21PM +0530, Arun Raghavan wrote
>
>> The overhead of the files' presence is trivial, and most users won't
>> care. Those who do care have a trivial line to add in make.conf, and
>> that is for the small number of people who share your vitriol for the
>> systemd project.
>
>   Then howsabout a "units" ebuild that installs all available units
> files for systemd users?  "The overhead of the files' presence is
> trivial, and most systemd users won't care".

Read the rest of the thread and the archives.  Both suggestions have
been discussed and they're not practical.  Your first suggestion was
specifically rejected by the council.  Your second one was suggested
only yesterday in this very same thread.

>
>   The thread title says it all... normal Gentoo users don't use systemd.

There is no such thing as a "normal Gentoo user."  About the closest
you'll come is a hypothetical Gentoo user who doesn't touch
/etc/portage.  I suspect that the time will be approaching soon that
there will be more development/testing targeting systemd than OpenRC
on Gentoo.  I'm sure the default will remain as-is for a long-time.
For how many years was the typical developer running OpenRC while the
typical user was running baselayout 1?

The goal is to make systemd a first class citizen in Gentoo, nothing
more.  Developers will not be required to run it, or test on it, just
as they aren't required to run or test on OpenRC or FreeBSD (two other
first-class citizens in Gentoo).

If you don't want unit files installed, just use INSTALL_MASK as
endorsed by the Council.  Ditto for docs, or init.d files, or
whatever.

Rich



Re: [gentoo-dev] Making systemd more accessible to "normal" users

2013-05-09 Thread Anthony G. Basile

On 05/08/2013 10:01 PM, Jeroen Roovers wrote:

On Wed, 8 May 2013 21:48:36 -0400
"Walter Dnes"  wrote:


   Wouldn't the "systemd" USE flag be the appropriate one to key on?
The description in /usr/portage/profiles/use.desc says...

systemd - Enable use of systemd-specific libraries and features like
socket activation or session tracking

Surely, units files qualify as "systemd-specific features".


https://bugs.gentoo.org/show_bug.cgi?id=198901


  jer



People keep saying disk space is not an issue but it is on embedded 
systems.  Even 4k or one i-node.  So the choice to not install unit 
files is important.  I'm sympathetic to the idea of reducing use flags 
and I would really not like to see USE="openrc" or "systemd" everywhere. 
 Without having tested, it does seem that INSTALL_MASK is sufficient. 
I recommend going that route and documenting it.


--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197



Re: [gentoo-dev] extending metadata.xml to support CPE information

2013-05-09 Thread Sven Vermeulen
On Wed, May 08, 2013 at 09:06:00PM -0400, Mike Frysinger wrote:
> On Wednesday 08 May 2013 21:01:19 Mike Frysinger wrote:
> > On Tuesday 07 May 2013 23:59:18 Mike Frysinger wrote:
> > > we've already got a database for maintaining this sort of thing on a per-
> > > package basis: metadata.xml.  so let's extend the DTD to cover this.  the
> > > existing remote-id field looks like a pretty good fit, so the proposal is
> > > simple: add a new "cpe" type.
> > 
> > committed:
> 
> or not.  someone on cc want to commit that change for me ? :)
> 
> just add "cpe" between "cpan-module" and "cran" in the remote-id field.

Done

Wkr,
Sven Vermeulen