[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-02-08 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2015-02-08 23:59 UTC. Removals: dev-ml/obrowser 2015-02-02 11:37:14 aballier games-server/tetrix 2015-02-03 14:24:17 pacho app-emulation/wine-doors2015-02-03 14:25:10 pacho dev-libs/libgeier 2015-02-03 14:25:54 pacho dev-games/ggz-client-libs 2015-02-03 14:26:20 pacho dev-games/libggz2015-02-03 14:26:40 pacho games-board/ggz-gtk-client 2015-02-03 14:27:24 pacho games-board/ggz-gtk-games 2015-02-03 14:27:45 pacho games-board/ggz-sdl-games 2015-02-03 14:28:27 pacho games-board/ggz-txt-client 2015-02-03 14:28:35 pacho games-board/xfrisk 2015-02-03 14:29:24 pacho games-mud/mcl 2015-02-03 14:29:53 pacho media-gfx/photoprint2015-02-03 14:30:47 pacho media-gfx/rawstudio 2015-02-03 14:31:25 pacho app-office/imposter 2015-02-03 14:33:21 pacho dev-python/cl 2015-02-03 14:33:59 pacho sci-physics/camfr 2015-02-03 14:34:46 pacho net-analyzer/nagios-imagepack 2015-02-03 14:36:14 pacho dev-python/orm 2015-02-03 14:36:53 pacho dev-python/testoob 2015-02-03 14:36:53 pacho app-misc/fixdos 2015-02-03 14:37:41 pacho app-arch/mate-file-archiver 2015-02-03 14:40:31 pacho app-editors/mate-text-editor2015-02-03 14:40:54 pacho app-text/mate-document-viewer 2015-02-03 14:41:22 pacho app-text/mate-doc-utils 2015-02-03 14:41:50 pacho mate-base/libmatekeyring2015-02-03 14:42:10 pacho mate-base/mate-file-manager 2015-02-03 14:42:28 pacho mate-base/mate-keyring 2015-02-03 14:42:48 pacho mate-extra/mate-character-map 2015-02-03 14:43:07 pacho mate-extra/mate-file-manager-image-converter2015-02-03 14:44:02 pacho mate-extra/mate-file-manager-open-terminal 2015-02-03 14:44:02 pacho mate-extra/mate-file-manager-sendto 2015-02-03 14:44:02 pacho mate-extra/mate-file-manager-share 2015-02-03 14:44:02 pacho media-gfx/mate-image-viewer 2015-02-03 14:44:28 pacho net-wireless/mate-bluetooth 2015-02-03 14:44:50 pacho x11-libs/libmatewnck2015-02-03 14:45:41 pacho x11-misc/mate-menu-editor 2015-02-03 14:45:53 pacho x11-wm/mate-window-manager 2015-02-03 14:46:25 pacho net-zope/zope-fixers2015-02-03 14:46:57 pacho sys-apps/kmscon 2015-02-03 14:47:31 pacho app-office/teapot 2015-02-03 14:49:02 pacho net-irc/bitchx 2015-02-03 14:50:27 pacho sys-power/cpufrequtils 2015-02-03 14:51:49 pacho x11-plugins/gkrellm-cpufreq 2015-02-03 14:52:34 pacho media-sound/gnome-alsamixer 2015-02-03 14:53:11 pacho sys-devel/ac-archive2015-02-03 14:53:43 pacho net-misc/emirror2015-02-03 14:54:15 pacho net-wireless/wimax 2015-02-03 14:54:37 pacho net-wireless/wimax-tools2015-02-03 14:54:47 pacho rox-extra/clock 2015-02-03 14:57:01 pacho app-arch/rpm5 2015-02-03 14:57:27 pacho app-admin/gksu-polkit 2015-02-03 14:58:01 pacho sys-apps/uhinv 2015-02-03 14:58:33 pacho net-libs/pjsip 2015-02-03 14:59:02 pacho net-voip/sflphone 2015-02-03 15:00:20 pacho net-im/ekg 2015-02-03 15:01:29 pacho sys-firmware/iwl2000-ucode 2015-02-03 15:03:02 pacho sys-firmware/iwl2030-ucode 2015-02-03 15:03:02 pacho sys-firmware/iwl5000-ucode 2015-02-03 15:03:02 pacho sys-firmware/iwl5150-ucode 2015-02-03 15:03:02 pacho net-wireless/cinnamon-bluetooth 2015-02-03 15:03:23 pacho net-wireless/ussp-push 2015-02-03 15:03:52 pacho Additions: dev-pytho
Re: [gentoo-dev] Re: ffmpeg vs libav choice of default
On 08/02/15 17:13, Alexis Ballier wrote: What we need instead of such endless debate & happy bashing (been there, done that) is people doing the work. That's what will improve the distribution. I thought letting libav be the default would improve that; If nobody helps fixing the orphaned and near orphaned applications we distribute nothing good happens and sadly in the past months I had been busy with more rl tasks. unfortunately this is not the case today: libav ebuilds are good, tree-wide integration is not. I find it a bit sad and sarcastic that we're close to have ffmpeg-2.2 stable while libav-10 is not even unmasked: One big feature of the two versions is the h265/hevc decoder, and as I understood it, most of the work has been done on the libav side... libav-10 and libav-11 are the same api wise, sadly I had to wait for handbrake to provide a new release and I hadn't time to install and check all the near orphaned application that call direct the ffmpeg command. I had no problems with using libav-11 since it was released but I kept it masked while patching stuff. Sadly the time I can spend doing opensource stuff can be compressed from time to time and maybe is nicer develop interesting stuff such as useful API and features than write tons of s:CODEC_ID:AV_CODEC_ID: over countless packages. lu
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On Sun, Feb 8, 2015 at 12:38 PM, hasufell wrote: > > The council has (at least implicitly) stated that people may stop using > common eclasses that standardize stuff in gentoo if they don't like them > (that includes python, ruby, perl... eclasses as well, FYI). Maybe we should both step back a bit. The Council has said this, no more or less: - Motion: "Every developer is allowed to commit and maintain games ebuilds, without the need to ask for permission or review from the games team. The games team does not have authority to override maintainer decisions on packages they don't maintain." Accepted unanimously. Note: This should be understood as clarification of existing policy. - There is consensus amongst council members that specific policies (e.g., games group, /usr/games hierarchy, and games.eclass) should be settled by the QA team. - Motion: "The council encourages the games team to accept join requests and elect a lead. In the event they don't elect a lead within 6 weeks, we will consider the team as dysfunctional and thus disband it." Accepted with 6 yes votes and 1 abstention. - Motion: "The council appoints radhermit as the interim lead of games until the elections are held." Accepted with 4 yes votes and 3 abstentions. If you have any specific questions as to how this relates to other projects/eclasses/etc, I suggest that you bring them to the Council. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Rich Freeman: > On Sat, Feb 7, 2015 at 3:12 PM, hasufell wrote: >> >> You are making it sound like there is some huge work to be done. There >> isn't. And no one has to step up to change the current situation, except >> the council. > > > If you feel so strongly about it, then join the games team and get rid > of the eclass. Or, if you feel the council should run differently, > then by all means feel free to run for it. > The council has (at least implicitly) stated that people may stop using common eclasses that standardize stuff in gentoo if they don't like them (that includes python, ruby, perl... eclasses as well, FYI). Maybe I should start dropping python-r1 and multilib eclasses from my ebuilds and do my own thing that may or may not work with the current standards that are enforced through these eclasses? And now you are telling me that in order to fix that wrong sentiment, I have to join a team?? How is any of that related? > It seems to me that nobody really cares much about this issue besides > you, and if you don't care enough to do anything about it, why should > anybody else? > You are again mixing facts and topics that don't belong together and are repeatedly pointing to GLEP39 in order to not be responsible. This is not about "I like this or that eclass". This is about making DECISIONS and enforcing CONSISTENCY. That's your job in cooperation with the QA team and the relevant projects. Not mine.
Re: [gentoo-dev] Suggestion about how to tell ATs that a package can be stabilized on all arches at the same time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/08/2015 05:17 AM, Pacho Ramos wrote: > Hello > > Many times has raised the question about how we could handle those > packages (like icon packs, wallpapers...) that are not arch > dependent and, then, could be stabilized all at the same time by > the first arch team that is going to stabilize it. > > Some months ago it was suggested that this packages could have a > KEYWORD with a value like "~arch" for example that could indicate > this situation: > http://www.gossamer-threads.com/lists/gentoo/dev/283020 > > But it was shown that it would be difficult to make it work > properly at PM level. > > Then, I was wondering if we could handle this simply by having: - A > new keyword for bugzilla like "STABLEREQALL" to easily allow arch > teams to filter this kind of packages and handle them in this > "special way" - A new key for metadata.xml files to specify there > that the package can be handled in that way. > > What do you think about this? It wouldn't need any change at PM > level and, then, it should be easy to do. > > I would like to see packages with PHP scripts (only) be included with such a proposal. i.e. dev-php/PEAR-* . They are only text files which may only rely on dev-lang/php USE which are simple to detect with repoman failures. Brian -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJU15STXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NkMyRTQ0RUQ5MEUzMjc1OEU3RDU1QzBE MUY3ODFFRkY5RjRBM0I2AAoJENH3ge/59KO2wFEQAI2xAB27C8KhEpChVcteIy4g dKIn4dDJGhBxKPqs7Jz3I9A/G6dFmLd0lanPglXWzGND0N0MRtwEJpMuHMWRtuEB 6HQcBCX78OrTnE5Etiba/MZzaqvUs0mOdEBk8+Ay2UQcldEf1Z69FbJqC5CnGpEX Pj9Pwv2dD34GJxEhCVWslfjlec9tzs8jaV3iy/aS1BC75oektRkn7iVWzuPWneC8 /CihWDBUwsm7REexeZxcIaSzkTJjNdfK8728bPYshSKa/dtTzmgtyenOES4MZ39Y TWmVamR1m9AdCG7i8ZmSmtMXupMZswDfNn7lKjvlmHyGfK45eZKPtl6cFnRHNwTl nfm9ZUe8c+oILNbT279t3pyBTRZNlcMFeV7lFYTgGEkZjz0Zkz0K2nrlQ7jj9cNA jAxbdYvSJozyf2sPD5U+4JGQbUanY8XLkt5IC1akPYOI9wRIv3R9J4h3fO7bFZFj zsgmYj9LYe8ie9/7QDIruV14PhmJzOvxDMTdZKcal2IjaCTDT2tFQIr80UBy3aDN rxASDbi7/vL/gGrKmzwjbm1SM6Fgzt4gMLAQWlErmmiyUHnMYQ79qQlH/aDgGmSU jqdLYahx0KSsHrbgGMdFi6CMFy/0xvM6/X9nr/wZbvCgc3fqsy0JZh9w/xRGEsBt sPiU1Hr2E7Sd2TpDnhft =NiPF -END PGP SIGNATURE-
Re: [gentoo-dev] Re: ffmpeg vs libav choice of default
On Sun, 8 Feb 2015 12:19:18 + Ian Whyman wrote: > On 8 February 2015 at 03:20, Jason A. Donenfeld > wrote: > > The votes keep pouring in. Ffmpeg is the preference of Gentoo > > users, as well as the majority of Gentoo developers, and by a very > > relevant upstream author. > > I don't think a forum poll, or a poll of users for that matter is > great way to build a distribution, in fact it may be very worst way I > can think of. I wouldn't like to comment of the preferences of my > fellow developers, but I might suggest to put this to bed with a vote. A poll for which is default does make sense: if 90% of users were to use the non-default, there is no point of having such a default. Whether the forum is a good representing sample is another debate. What we need instead of such endless debate & happy bashing (been there, done that) is people doing the work. That's what will improve the distribution. I thought letting libav be the default would improve that; unfortunately this is not the case today: libav ebuilds are good, tree-wide integration is not. I find it a bit sad and sarcastic that we're close to have ffmpeg-2.2 stable while libav-10 is not even unmasked: One big feature of the two versions is the h265/hevc decoder, and as I understood it, most of the work has been done on the libav side... Alexis.
Re: [gentoo-dev] Re: ffmpeg vs libav choice of default
El dom, 08-02-2015 a las 12:19 +, Ian Whyman escribió: [...] > So long as libav is effectively dictating the API then by defaulting > to ffmpeg we are just delaying the inevitable breakage htting the > tree. I know there are people who think we shouldn't break unstable, > but I personally prefer a faster moving model with an amount of > breakage. > I have no problem with making that breakage land the "testing" tree... but having bugs like this in stable doesn't make me think libav is a good default (at least for now): https://bugs.gentoo.org/show_bug.cgi?id=474408 Regarding the "gstreamer preference", well, it's not exactly that: upstream supports either the internal libav lib, one concrete libav version and one concrete ffmpeg version per cycle. Once we patch it to support more libav/ffmpeg versions we are on our own (like it's the case now as, for example, you would need to run the development upstream version for libav-11, 1.4.x version for libav-10 and 1.2.x version for libav-9).
Re: [gentoo-dev] Re: Last rites: app-portage/portage-mod_jabber, media-sound/moodbar
On Mon, 09 Feb 2015 01:33:28 +1100 Michael Palimaka wrote: > On 09/02/15 00:27, Alan McKinnon wrote: > > I use this, it builds without errors and works well with Amarok. > > > > Please leave it in the tree for as long as it functions correctly. > > I'd like to keep this too. Okay, I hadn't expected that this even works, because its last release was ages ago. Michael: Do you want to add yourself as maintainer and unmask it? -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42
[gentoo-dev] Re: Last rites: app-portage/portage-mod_jabber, media-sound/moodbar
On 09/02/15 00:27, Alan McKinnon wrote: > On 08/02/2015 14:04, Hanno Böck wrote: > >> # Hanno Boeck (08 Feb 2150) >> # Dead upstream, will be removed in 30 days if nobody >> # complains. >> media-sound/moodbar > > I use this, it builds without errors and works well with Amarok. > > Please leave it in the tree for as long as it functions correctly. I'd like to keep this too.
Re: [gentoo-dev] Last rites: app-portage/portage-mod_jabber, media-sound/moodbar
On 08/02/2015 14:04, Hanno Böck wrote: > # Hanno Boeck (08 Feb 2150) > # Dead upstream, will be removed in 30 days if nobody > # complains. > media-sound/moodbar I use this, it builds without errors and works well with Amarok. Please leave it in the tree for as long as it functions correctly. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: ffmpeg vs libav choice of default
On 8 February 2015 at 03:20, Jason A. Donenfeld wrote: > The votes keep pouring in. Ffmpeg is the preference of Gentoo users, as well > as the majority of Gentoo developers, and by a very relevant upstream > author. I don't think a forum poll, or a poll of users for that matter is great way to build a distribution, in fact it may be very worst way I can think of. I wouldn't like to comment of the preferences of my fellow developers, but I might suggest to put this to bed with a vote. With regards to packages both Gstreamer and Handbrake upstreams prefer libav, though again I don't think that is great way to pick. So long as libav is effectively dictating the API then by defaulting to ffmpeg we are just delaying the inevitable breakage htting the tree. I know there are people who think we shouldn't break unstable, but I personally prefer a faster moving model with an amount of breakage. -- Ian Whyman www.gentoo.org
[gentoo-dev] Last rites: app-portage/portage-mod_jabber, media-sound/moodbar
# Hanno Boeck (08 Feb 2150) # Dead upstream, will be removed in 30 days if nobody # complains. app-portage/portage-mod_jabber # Hanno Boeck (08 Feb 2150) # Dead upstream, will be removed in 30 days if nobody # complains. media-sound/moodbar -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
07.02.2015 23:12, hasufell пишет: > In addition... there is no work that needs to be done that has not > already been done, other than banning an eclass or stating that it is > the way to go. How would you do that without breaking all user apps? Clearly - by slowly migrating away from it and do not use it in newer ebuilds. That's what is done here, so what do you complain on? > If the eclass is going to be banned, then there is a deprecation phase > with a news items for users and devs will just stop using it. If it is > the way to go, then nothing has to change (except disallowing ebuilds > that break consistency). > You are making it sound like there is some huge work to be done. There > isn't. And no one has to step up to change the current situation, except > the council. That's clearly up to eclass owner, which is games team. If you think that this is not huge work - deprecating eclass, moving all ebuilds from it and carring that no breakages will happen - then - step up and do this work, as was already suggested. "Talk is cheap, show me the code" (c) Linux Torvalds -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Git mirror news: travis-ci running repoman, git->cvs merge & revert tools
Hello, everyone. I would like to announce that our little rsync->git band-aid mirror [1] is doing fine and we're actively working towards improving Gentoo development experience. First of all, we have enabled tree-wide repoman scans using travis-ci [2]. Besides providing regularly updated repository state report, it can be used to scan Pull Requests for tree-wide damage :). Asides from the benefit to external contributors, Gentoo developers can use it to avoid having to run repoman locally. For example, if you are doing a big old version cleanup, do it in git and submit a Pull Request, and travis will figure out if you don't break any revdeps. Secondly, I have committed app-portage/lightweight-cvs-toolkit for your committing pleasure. It consists of three tools: a. lcvs-init -- that can be used to quickly create partial CVS checkout, having only pure categories checked out. The repository is set to use 'gentoo' as master, so you can easily commit into CVS while keeping the dependencies, eclasses and profiles synced to your regular rsync/git checkout (with working cache!). The idea is explained more thoroughly on the wiki [3] and in the script output. b. lcvs-merge-pr -- a convenient tool to merge github PR (or any git patch) into your CVS checkout. It 'cvs up -dP' directories as necessary, git-applies the patch omitting ChangeLogs and Manifests, calls cvs add/cvs rm as appropriate. All you have to do is update the ChangeLog and commit :). More about merging on the wiki [4]. c. lcvs-revert -- a convenient tool to revert commits. Pretty much the idea is: someone breaks something e.g. by removing ebuilds, and you want to revert that. Instead of playing all the fancy 'cvs add' magic, you just find the matching git commit and lcvs-revert it. Using logic similar to lcvs-merge-pr, it fetches the diff and reverse-applies it. Then you check if everything went fine, ChangeLog and commit :). More info on the wiki [5] as well. Thanks to all the people that helped me get this running, and have fun :). [1]:https://github.com/gentoo/gentoo-portage-rsync-mirror [2]:https://travis-ci.org/gentoo/gentoo-portage-rsync-mirror [3]:https://wiki.gentoo.org/wiki/Lightweight_CVS_Checkout [4]:https://wiki.gentoo.org/wiki/Project:Git_mirror/Merging_Pull_Requests [5]:https://wiki.gentoo.org/wiki/Project:Git_mirror/Reverting_Gentoo_commits -- Best regards, Michał Górny pgpKlWKnOcn7l.pgp Description: OpenPGP digital signature
[gentoo-dev] Suggestion about how to tell ATs that a package can be stabilized on all arches at the same time
Hello Many times has raised the question about how we could handle those packages (like icon packs, wallpapers...) that are not arch dependent and, then, could be stabilized all at the same time by the first arch team that is going to stabilize it. Some months ago it was suggested that this packages could have a KEYWORD with a value like "~arch" for example that could indicate this situation: http://www.gossamer-threads.com/lists/gentoo/dev/283020 But it was shown that it would be difficult to make it work properly at PM level. Then, I was wondering if we could handle this simply by having: - A new keyword for bugzilla like "STABLEREQALL" to easily allow arch teams to filter this kind of packages and handle them in this "special way" - A new key for metadata.xml files to specify there that the package can be handled in that way. What do you think about this? It wouldn't need any change at PM level and, then, it should be easy to do.
