[gentoo-dev] Last rites: dev-lisp/emacs-cl
# Ulrich Müller (06 May 2013) # Fails to build with Emacs 24.3. # Masked for removal in 30 days, bug #466444. dev-lisp/emacs-cl pgpFlqXmCYkHC.pgp Description: PGP signature
[gentoo-dev] Last rites: media-fonts/adi-dsp-fonts
# Ulrich Müller (06 May 2013) # No license. Distfile not available upstream and not redistributable. # Masked for removal in 30 days, bug #452372. media-fonts/adi-dsp-fonts pgpzH6QsyDKo2.pgp Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-05-05 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-05-05 23h59 UTC. Removals: sys-process/crtools 2013-05-03 07:57:12 radhermit sci-chemistry/talos+2013-05-05 11:02:02 jlec www-servers/meteor 2013-05-05 12:17:36 tomwij Additions: app-leechcraft/lc-hotsensors2013-04-30 08:01:26 pinkbyte virtual/leechcraft-notifier 2013-04-30 08:24:39 pinkbyte dev-php/pecl-apcu 2013-04-30 10:08:33 olemarkus dev-ruby/rack-openid2013-04-30 13:47:20 graaff dev-ruby/simplecov-html 2013-04-30 13:52:04 graaff dev-ruby/simplecov 2013-04-30 13:52:42 graaff app-leechcraft/lc-gmailnotifier 2013-05-01 08:09:22 pinkbyte x11-themes/pidgin-penguins-smileys 2013-05-01 15:11:32 xarthisius dev-python/extras 2013-05-02 08:18:24 idella4 media-gfx/gnome-photos 2013-05-02 08:55:31 pacho app-leechcraft/lc-nacheku 2013-05-02 14:20:35 pinkbyte app-leechcraft/lc-kbswitch 2013-05-02 14:22:07 pinkbyte media-gfx/pycam 2013-05-02 20:25:39 slis dev-cpp/luabind 2013-05-02 21:56:13 hasufell games-rpg/valyriatear 2013-05-02 21:59:33 hasufell sys-process/criu2013-05-03 07:51:26 radhermit app-editors/moe 2013-05-03 17:10:03 pinkbyte dev-ruby/ruby-gdk3 2013-05-04 05:19:38 naota app-i18n/zinnia-tomoe 2013-05-04 05:22:49 naota dev-ruby/ruby-gtk3 2013-05-04 05:34:51 naota dev-ruby/ruby-cairo-gobject 2013-05-04 06:48:59 naota app-i18n/ibus-handwrite 2013-05-04 09:58:54 naota dev-ruby/ruby-gobject-introspection 2013-05-04 10:06:09 naota dev-python/bottleneck 2013-05-04 10:10:42 jlec dev-python/rarfile 2013-05-04 11:43:07 thev00d00 app-i18n/tegaki-zinnia-japanese 2013-05-04 12:49:38 naota dev-ruby/ruby-clutter 2013-05-04 12:52:14 naota dev-ruby/ruby-clutter-gtk 2013-05-04 13:08:53 naota media-libs/libxmi 2013-05-04 13:12:42 jlec dev-ruby/ruby-gtksourceview32013-05-04 15:03:08 naota dev-ruby/ruby-vte3 2013-05-04 16:45:00 naota dev-python/flask-restless 2013-05-04 22:51:10 rafaelmartins media-libs/libmkv 2013-05-05 17:20:34 tomwij media-video/handbrake 2013-05-05 17:33:51 tomwij -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: sys-process/crtools,removed,radhermit,2013-05-03 07:57:12 sci-chemistry/talos+,removed,jlec,2013-05-05 11:02:02 www-servers/meteor,removed,tomwij,2013-05-05 12:17:36 Added Packages: app-leechcraft/lc-hotsensors,added,pinkbyte,2013-04-30 08:01:26 virtual/leechcraft-notifier,added,pinkbyte,2013-04-30 08:24:39 dev-php/pecl-apcu,added,olemarkus,2013-04-30 10:08:33 dev-ruby/rack-openid,added,graaff,2013-04-30 13:47:20 dev-ruby/simplecov-html,added,graaff,2013-04-30 13:52:04 dev-ruby/simplecov,added,graaff,2013-04-30 13:52:42 app-leechcraft/lc-gmailnotifier,added,pinkbyte,2013-05-01 08:09:22 x11-themes/pidgin-penguins-smileys,added,xarthisius,2013-05-01 15:11:32 dev-python/extras,added,idella4,2013-05-02 08:18:24 media-gfx/gnome-photos,added,pacho,2013-05-02 08:55:31 app-leechcraft/lc-nacheku,added,pinkbyte,2013-05-02 14:20:35 app-leechcraft/lc-kbswitch,added,pinkbyte,2013-05-02 14:22:07 media-gfx/pycam,added,slis,2013-05-02 20:25:39 dev-cpp/luabind,added,hasufell,2013-05-02 21:56:13 games-rpg/valyriatear,added,hasufell,2013-05-02 21:59:33 sys-process/criu,added,radhermit,2013-05-03 07:51:26 app-editors/moe,added,pinkbyte,2013-05-03 17:10:03 dev-ruby/ruby-gdk3,added,naota,2013-05-04 05:19:38 app-i18n/zinnia-tomoe,added,naota,2013-05-04 05:22:49 dev-ruby/ruby-gtk3,added,naota,2013-05-04 05:34:51 dev-ruby/ruby-cairo-gobject,added,naota,2013-05-04 06:48:59 app-i18n/ibus-handwrite,added,naota,2013-05-04 09:58:54 dev-ruby/ruby-gobject-introspection,added,naota,2013-05-04 10:06:09 dev-python/bottleneck,added,jlec,2013-05-04 10:10:42 dev-python/rarfile,added,thev00d00,2013-05-04 11:43:07 app-i18n/tegaki-zinnia-japanese,added,naota,2013-05-04 12:49:38 dev-ruby/ruby-clutter,added,naota,2013-05-04 12:52:14 dev-ruby/ruby-clutter-gtk,added,naota,2013-05-04 13:08:53 media-libs/libxmi,added,jlec,2013-05-04 13:12:42 dev-ruby/ruby-gtksourceview3,added,naota,2013-05-04 15:03:08 dev-ruby/ruby-vte3,added,naota,2013-05-04 16:45:00 dev-python/flask-restless,added,rafaelmartins,2013-05-04 22:51:10 media-libs/libmkv,added,tomwij,2013-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/id3lib: metadata.xml ChangeLog id3lib-3.8.3-r9.ebuild
On 5/5/13 6:20 AM, Jeroen Roovers wrote: > On Sat, 04 May 2013 19:49:03 +0200 > "viv...@gmail.com" wrote: > >>> (Also, why do a revision bump and leave >>> the stable revision unfixed?) >>> >> but this: >> because automake-1.13 is _not_ stable an because there are enough >> changes to risk to break it? > > The fix changes a single line in a source file in a predictable way. I trust maintainer's judgement. We have Gentoo developers who are strongly opposed to making _any_ changes to stable ebuilds. I'm in fact leaning towards that group. And we also have developers who see no reasons not to change stable ebuilds in "trivial" ways (the question remains what is trivial and what is not, and how trivial changes can still break things). The way I see to resolve this - which I think is accurate description of what's happening - is to let maintainers handle the fixes in the way they think is best (after all, they are most knowledgeable about the package in question). Anyone else is free to file a stabilization request and do his own testing - in fact, I also support stable not being too far behind ~arch. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/id3lib: metadata.xml ChangeLog id3lib-3.8.3-r9.ebuild
On Sat, 04 May 2013 19:49:03 +0200 "viv...@gmail.com" wrote: > > (Also, why do a revision bump and leave > > the stable revision unfixed?) > > > but this: > because automake-1.13 is _not_ stable an because there are enough > changes to risk to break it? The fix changes a single line in a source file in a predictable way. jer
[gentoo-dev] Re: Making systemd more accessible to "normal" users
Rich Freeman posted on Sat, 04 May 2013 08:54:16 -0400 as excerpted: > On Sat, May 4, 2013 at 6:42 AM, Luca Barbato wrote: >> Hopefully we might have a gsoc student volunteering to make a >> runscript/lsb-script/systemd-unit compiler and a small abstraction so >> we write a single init.d script and generate what's needed. >> Probably we might even support pure-runit that way with minimal effort. >> > I'm skeptical that this will ever make sense - both init systems have > features that it would make sense for units/scripts to make use of in a > more tailored fashion. Same here. Sure, an automated conversion is possible and arguably might serve as a starting point, but you're losing the best of both initsystems in the process. > That said, if you really wanted to inter-convert, my gut feeling is that > it would be easier to go from a systemd unit to an init.d script, and > not the other way around. A systemd unit is more like a specification - > it describes the end result of what systemd should do. > An init.d script is an executable program You're a bit behind on openrc features, I think. =:^) It's actually quite possible for openrc/runscript "scripts" to be written in a "spec- style" format similar to systemd's unit files, just as it's possible for systemd to run "legacy" shell-style scripts with little or no modification, as some distros did with their initial conversion, according to what I've read. I think there's even some in-tree examples, tho I'm too lazy to go looking ATM and their package maintainers and/or williamh would be more familiar with them and could probably point them out off the top of their head without looking. > The reality is that systemd units are floating around all over the place > - when I installed it on a Gentoo box I ended up just Googling for > already-written units for daemons that lacked them in Gentoo and tweaked > them. That's what I have always figured I'd do, if I were to decide to convert here before all the packages I init here had in-tree unit-files. > Systemd units are much easier to write (typically) than init.d scripts > so this could be an area where end-users could contribute. See above. In theory it should be about even either way, since both systemd and openrc can do either scripted or spec-style "units". However, I expect systemd's "google resource" to be deeper in this regard, both with regard to the units themselves and to documentation about them, and the experience quotient probably favors systemd as well, so in practice you're almost certainly right, if only from the previous experience and googlable documentation and samples perspective. -- 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] Making systemd more accessible to "normal" users
On 05/04/2013 03:05 PM, Fabio Erculiani wrote: > Long story short, we should: > 1) give up with cross compiler support in genkernel, which has been > anyway in a broken state for ages. Nobody is using it anyway. > 2) make possible to optionally use udev in the initramfs (compiling > just for it is a pita and the trend here [dracut and others do this] > is to copy udevd from the system) > 3) default to udev? Uhm... sounds quite unpleasant and I'm really wondering why having udev as middle-man for storing userspace metadata. The netlink broadcast should be available to everybody for acting upon, using/extending it for such tasks isn't possible? lu
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On 05/04/2013 03:12 PM, Fabio Erculiani wrote: > I just forgot the tricky part. > If future lvm versions are going to use udev more extensively (for eg: > storing more critical metadata in it), the net result will be that > mdev won't work anymore. This is why I wrote that lvm is working "by > miracle for now". > mdev is not future proof wrt lvm support. Sounds dangerously bad, I guess the response by the interested parties (e.g. nas builders) will be moving lvm in bb or switch to dragonfly or freebsd. lu
