Re: [gentoo-dev] extending metadata.xml to support CPE information
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
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/08/2013 10:01 PM, Jeroen Roovers wrote: On Wed, 8 May 2013 21:48:36 -0400 Walter Dnes waltd...@waltdnes.org 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] Making systemd more accessible to normal users
On Wed, May 8, 2013 at 10:18 PM, Walter Dnes waltd...@waltdnes.org 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] OpenRC supporting systemd units
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] RFC: cartesian product extension to keyword system
В письме от 29 апреля 2013 15:43:03 пользователь Jeroen Roovers написал: On Mon, 29 Apr 2013 16:14:51 +0900 heroxbd hero...@gentoo.org 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] Making systemd more accessible to normal users
On Thu, May 9, 2013 at 12:44 PM, Michał Górny mgo...@gentoo.org 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] [PATCH] gnome2.eclass does not respect ECONF_SOURCE
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
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 ;))
[gentoo-dev] Last rites: kde-misc/akonadi-google
+# Johannes Huber j...@gentoo.org (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.
[gentoo-dev] Re: OpenRC supporting systemd units
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] Re: Making systemd more accessible to normal users
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 ;-)
