Re: [gentoo-dev] Asking for permission to update packages from LINGUAS to L10N

2016-08-10 Thread Ben de Groot
On 11 August 2016 at 04:22, NP-Hardass  wrote:
> Looks to me like we can't edit that eclass in place, so if we are to
> keep it, we should probably revbump it, update the -r1 to L10N, and add
> a deprecation warning to the old eclass to help maintainers migrate over.
>
> Any opinions?  I'd be happy work on the revbump for the eclass if we
> decide to go that route.  CC'ing yngwin since it is his eclass.

Feel free to revbump it and change it to whatever works for current needs.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] .gitignore

2015-08-14 Thread Ben de Groot
On 14 August 2015 at 14:02, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2015-08-13, o godz. 21:17:22
 Patrick McLean chutz...@gentoo.org napisał(a):
 We should have common editor artifacts and backup files in there, I
 generally use this in just about every repository I touch:

 *~
 .*.sw[po]
 .*.un~
 *#
 .#*

 This should cover vim and emacs, if there other editors that like to
 drop files around, we should consider adding those as well.0

 set directory=~/tmp,/var/tmp

 It's usually a bad idea to leave temporary files in cwd :P.

It is. But how many people actually bother to change the defaults?

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: Referencing bug reports in git

2015-08-13 Thread Ben de Groot
I vote for a simple

Bug: 333531

If it is going to be any longer than that, then you need to make sure
it is part of the commit message template magic. Because I'm surely
not the only one who is lazy and thus averse to typing anything longer
for the most common use case: Gentoo bugs.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] useflag policies

2015-08-05 Thread Ben de Groot
On 4 August 2015 at 22:56, Ian Stakenvicius a...@gentoo.org wrote:
 Are there any cases where things actually break if a package has both
 flags enabled? IE, is three a package with IUSE=qt4 qt5 that when
 both flags are enabled would build for qt5 only, and happens to be a
 dependency atom of something else that needs it to have qt4 support?
 That to me is the only case where a REQUIRED_USE needs to be set on a
 package.

I'm not aware we have such a package, but I may be overlooking
something. Either way, I think it is a dangerous road to go down that
way.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] useflag policies

2015-08-05 Thread Ben de Groot
On 5 August 2015 at 03:09, Davide Pesavento p...@gentoo.org wrote:
 On Mon, Aug 3, 2015 at 8:59 PM, Ben de Groot yng...@gentoo.org wrote:
 On 4 August 2015 at 04:20, Rich Freeman ri...@gentoo.org wrote:
 [...]
 Gentoo should be the best of both worlds.  We should give users the
 power to tweak things, but we shouldn't force them to play with config
 files all day long just to have a functional system.  If users want to
 care we let them care instead of telling them don't touch like most
 other distros, but if they don't care we still provide reasonable
 defaults.

 And that is exactly what we do. The kde profile enables qt4, the
 plasma profile enables qt5, the other profiles have no qt* useflags
 enabled. These are reasonable defaults.


 As tetromino pointed out, this is very far from the real current situation.

Indeed, I was wrong here. We will need another solution.

 Of course some users will proceed to enable both qt4 and qt5 globally
 in their make.conf, but I don't think it is unreasonable to expect
 them to then deal with adding exceptions to package.use for those
 packages where exactly-one-of is required.

 In my opinion, this is the way Gentoo has always worked, and we should
 simply recommend users to only set one of the qt* useflags as globally
 enabled, if they want to prevent such micro-management. Hiding the qt4
 option is in my opinion the wrong solution around people complaining
 after they have consciously enabled both flags.

 If this is not acceptable (or absolutely unusable as one dev put
 it), then we need a proper solution, which a) will not hide the qt4
 option, and b) will prevent triggering required_use blockage by
 choosing qt5 over qt4 in case both are enabled, while c) informing the
 user about this. This probably requires new eclass or even EAPI
 functionality.


 Please go ahead and design and implement such functionality (a sort of
 REQUIRED_USE defaults).

Something along the lines of PYTHON_TARGETS could work. But
personally, I'm happy with REQUIRED_USE.

 In the meantime, we will apply the policies
 written in the Qt project wiki page.

Except for the one that is wrong.

 In the meantime, we should stick with the policies adopted at the qt3
 to qt4 transition (explicit versioned useflags) and let the user deal
 with per-package management if they enable both flags.


 We didn't have REQUIRED_USE at the time of the qt3-qt4 transition, so
 this point is completely moot.

We had something worse. That didn't prevent us from using it tho.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] useflag policies

2015-08-03 Thread Ben de Groot
On 4 August 2015 at 04:20, Rich Freeman ri...@gentoo.org wrote:
 [...]
 Gentoo should be the best of both worlds.  We should give users the
 power to tweak things, but we shouldn't force them to play with config
 files all day long just to have a functional system.  If users want to
 care we let them care instead of telling them don't touch like most
 other distros, but if they don't care we still provide reasonable
 defaults.

And that is exactly what we do. The kde profile enables qt4, the
plasma profile enables qt5, the other profiles have no qt* useflags
enabled. These are reasonable defaults.

Of course some users will proceed to enable both qt4 and qt5 globally
in their make.conf, but I don't think it is unreasonable to expect
them to then deal with adding exceptions to package.use for those
packages where exactly-one-of is required.

In my opinion, this is the way Gentoo has always worked, and we should
simply recommend users to only set one of the qt* useflags as globally
enabled, if they want to prevent such micro-management. Hiding the qt4
option is in my opinion the wrong solution around people complaining
after they have consciously enabled both flags.

If this is not acceptable (or absolutely unusable as one dev put
it), then we need a proper solution, which a) will not hide the qt4
option, and b) will prevent triggering required_use blockage by
choosing qt5 over qt4 in case both are enabled, while c) informing the
user about this. This probably requires new eclass or even EAPI
functionality.

In the meantime, we should stick with the policies adopted at the qt3
to qt4 transition (explicit versioned useflags) and let the user deal
with per-package management if they enable both flags.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] useflag policies

2015-08-02 Thread Ben de Groot
On 3 August 2015 at 01:33, Andrew Savchenko birc...@gentoo.org wrote:
 On Mon, 3 Aug 2015 00:34:51 +0800 Ben de Groot wrote:
 [...]
 This policy will allow to USE both qt versions whichever is
 available preferring newer one. Quite reasonable approach.
 Alternatives (^^() and ??()) will require micromanagement (e.g.
 pagkage.use.conf) for dozens if not hundreds of packages for no
 good reason. If someone still needs to override such policy (e.g.
 to use qt4 when both are available), this can be done by
 per-package configuration.

 My idea is that packages should be fully controllable, but choises
 of default behaviour should be done so, that in most cases
 micromanagement will not be necessary.

 I like this qt policy and I'm not sure if it violates any current
 rule.

See https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies
under 1.4 and 1.5.

QA has spoken out pretty clearly against unversioned gtk or qt
useflags, and in favour of explicit versioned useflags. Dropping the
explicit qt4 useflag in these cases goes against (at least the spirit
of) this.

 [...]
 So I propose to add somewhere to devmanual/policies the following
 recommendation: If package supports several versions of the same
 technology (e.g. qt4 and qt5) and more than one is enabled by USE
 flags, ebuild should prefer the later one (in terms of technology
 generation)..

If we adopt this, we should make sure the users understand this
policy, because it hides certain details from the user.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] useflag policies

2015-08-02 Thread Ben de Groot
On 3 August 2015 at 09:37, Rich Freeman ri...@gentoo.org wrote:
 On Sun, Aug 2, 2015 at 9:03 PM, Patrick Lauer patr...@gentoo.org wrote:
 I find setting USE=qt4 -qt5 a lot more obvious than having USE=qt (why 
 not
 USE=X ?) which then does different things based on another useflag,
 sometimes. Maybe. It's horribly inconsistent and even might change result 
 over
 time, which is not very user-friendly.

 The problem is that this approach breaks down with scenarios which are
 likely to be commonplace.

 I want to use fooplayer and bargrapher which are two qt-based
 applications.  fooplayer only supports qt4, and bargrapher only
 supports qt5.  What USE flags should I set, without restorting to
 per-package flags?

These packages would not have useflags, as they only use one toolkit.

  Then I also install klunkybrowser which supports
 both qt4 and qt5 but not at the same time, so how should I manage my
 flags for that?

Set your global default in make.conf as either qt4 or qt5. If you want
to deviate from that for some package, you can set per package use
flags. Easy peasy. Clear and straightforward. Principle of least
surprise.

 The current qt policy just has each package support only one version
 using USE=qt

No, that is not at all the case. We have banned a simple qt useflag
since many years (which is also the QA policy). We have been using
versioned qt3, qt4, qt5 useflags.

 and while it denies user choice for klunkybrowser it is
 at least simple.  The alternative of qt means I don't care what
 version is also simple

Except many users do care. I don't see the benefit in changing the way
we used to do this.

 The approach qt4=qt4
 and qt5=qt5 seems simpler on the surface, but it means that users end
 up having to set tons of per-package configurations when they don't
 actually care which one they use, and it also doesn't necessarily hint
 to users which will give them the best experience on each package.

If they don't care, they can simply follow the defaults and not set
any qt4 or qt5 useflags in make.conf.

 Right now you can get away with just USE=qt4 -qt5 because we don't
 have many qt5-only packages in the tree

As I said before, this is of no consequence, as there would be no
mutually exclusive qt4 and qt5 useflags anyway for those packages.

The problem only appears with packages that force a choice between qt4
and qt5, and users that have enabled both useflags globally.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] useflag policies

2015-08-02 Thread Ben de Groot
On 3 August 2015 at 11:30, Rich Freeman ri...@gentoo.org wrote:
 On Sun, Aug 2, 2015 at 11:24 PM, Ben de Groot yng...@gentoo.org wrote:
 I want to use fooplayer and bargrapher which are two qt-based
 applications.  fooplayer only supports qt4, and bargrapher only
 supports qt5.  What USE flags should I set, without restorting to
 per-package flags?

 These packages would not have useflags, as they only use one toolkit.


 What if qt support is optional, and I do/don't want it enabled?

Users who don't care, simply follow the defaults as set by the package
maintainer or profile. Users who do care wouldn't mind adding a rule
to their package.use.

-- 
Cheers,

Ben | yngwin
Gentoo developer



[gentoo-dev] useflag policies

2015-08-02 Thread Ben de Groot
Recently some team members of the Qt project have adopted these ebuild
policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies

I have an issue with the policy adopted under Requires one of two Qt
versions. In my opinion, in the case where a package offers a choice
between qt4 or qt5, we should express this in explicit useflags and a
REQUIRED_USE=^^ ( qt4 qt5 ). This offers the user the clearest choice.

Other developers state that users are not interested in such implementation
details, or that forced choice through REQUIRED_USE is too much of a
hassle. This results in current ebuilds such as quassel to not make it
clear that qt4 is an option.

This goes against the principle of least surprise, as well as against QA
recommendations. I would like to hear specifically from QA about how we
should proceed, but comments from the wider developer community are also
welcome.

-- 
Cheers,

Ben | yngwin
Gentoo developer


Re: [gentoo-dev] Re: Reverted python3.4 defaults

2015-07-21 Thread Ben de Groot
On 20 July 2015 at 17:27, Jason Zaman perfin...@gentoo.org wrote:
 On Mon, Jul 20, 2015 at 10:39:25AM +0200, Dirkjan Ochtman wrote:
 On Mon, Jul 20, 2015 at 6:03 AM, Ben de Groot yng...@gentoo.org wrote:
  I would like to hear from the other team members, yes.

 I have sympathy towards those who are asking for only one Python in
 stages (as in, I would be fine with that), but I very much think we
 should not leave Python 3 out of generally installed systems by
 default. We need to move through the transition, and increasing the
 barriers to Python 3 adoption will only make that process slower.

 I also feel like a voting process for this is probably not a solution.

 I also very much dislike shipping only python2. Having only one python
 is admirable and I'm all for it but if we only ship one by default it
 should be python3.

That is a nice sentiment, but unpractical. We have a lot more packages
that require python2, while we only have 74 that require python3.

While it may be possible to ship with python3 only (I haven't looked
at what the packages in stage3 support), users will almost certainly
need to install python2 when they start installing more packages.

But if we ship with python2 only, then most users won't need python3.
Those who want it, can of course simply add it. Going with python2 as
default simply makes more sense.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: Reverted python3.4 defaults

2015-07-19 Thread Ben de Groot
On 20 July 2015 at 00:03, Mike Gilbert flop...@gentoo.org wrote:
 If there are no objections, I would like to enable python3.4 by
 default on Saturday, July 25. That means making the following change:

 profiles/base/make.defaults:
 PYTHON_TARGETS=python2_7 python3_4

I would like to note that we only have around 50 packages that require
python3, while the majority requires python2, and the remainder will
function with either. For this reason it seems to make more sense to
me to only set PYTHON_TARGETS=python2_7 as default, and leave adding
any python3_* targets to the user. This will also debloat our stage3
tarballs.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: Reverted python3.4 defaults

2015-07-19 Thread Ben de Groot
On 20 July 2015 at 02:31, Mike Gilbert flop...@gentoo.org wrote:
 On Sun, Jul 19, 2015 at 12:42 PM, Ben de Groot yng...@gentoo.org wrote:
 On 20 July 2015 at 00:03, Mike Gilbert flop...@gentoo.org wrote:
 If there are no objections, I would like to enable python3.4 by
 default on Saturday, July 25. That means making the following change:

 profiles/base/make.defaults:
 PYTHON_TARGETS=python2_7 python3_4

 I would like to note that we only have around 50 packages that require
 python3, while the majority requires python2, and the remainder will
 function with either. For this reason it seems to make more sense to
 me to only set PYTHON_TARGETS=python2_7 as default, and leave adding
 any python3_* targets to the user. This will also debloat our stage3
 tarballs.

 It looks like we have eliminated most (all?) of the unbounded
 dependencies on dev-lang/python from the gentoo repository, so this
 could actually work to satisfy the goal of smaller stages and only
 having one version of python installed.

 However, it feels like a step backward to me; I would rather treat
 python3 as the primary interpreter and python2 as the one necessary
 for the legacy baggage.

I understand the sentiment, and I wish it was possible. I'm not some
kind of Luddite. But too many useful packages (still) depend on
python2. A couple of months ago I tried switching to python3 (either
3.3 or 3.4) only, but I had a growing list of stuff I wanted that
ended up in my package.use/py2 file. Pretty soon I decided it was not
worth the trouble, and I switched back to python 2.7 only.

My tree grepping shows 1527 out of 2371 packages with python support
need py2 and don't work with py3. It is definitely too early to treat
python2 as legacy.

There are two packages I want to use that need python 3 (compton and
pybugz), but I decided I can live without them. And I think this is
true for many of our users. They could happily live with just python
2.7 as only default. If they do want py3 packages, it is easy enough
to add that to PYTHON_TARGETS in make.conf, or individual useflags in
package.use.

 I don't see any strong technical reason to switch from python2 +
 python3 to python2-only enabled. Some people don't like having two
 versions of python installed -- that's about the gist of it.

Indeed, there is no strong technical reason, except that some people
like to keep their systems more lean. But I think having a smaller
stage3 tarball is a more important reason. The python team has
historically left that up to the RelEng team, which has been averse to
handling that themselves.

 So, I'm personally not going to make that change without some kind of
 vote on it. I can arrange a vote within the python team if you like.

I would like to hear from the other team members, yes.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: Reverted python3.4 defaults

2015-07-19 Thread Ben de Groot
On 20 July 2015 at 01:01, Anthony G. Basile bluen...@gentoo.org wrote:
 On 7/19/15 12:42 PM, Ben de Groot wrote:

 On 20 July 2015 at 00:03, Mike Gilbert flop...@gentoo.org wrote:

 If there are no objections, I would like to enable python3.4 by
 default on Saturday, July 25. That means making the following change:

 profiles/base/make.defaults:
 PYTHON_TARGETS=python2_7 python3_4

 I would like to note that we only have around 50 packages that require
 python3, while the majority requires python2, and the remainder will
 function with either. For this reason it seems to make more sense to
 me to only set PYTHON_TARGETS=python2_7 as default, and leave adding
 any python3_* targets to the user. This will also debloat our stage3
 tarballs.

 What are those 50 packages, if you have the list handy?  Its not the number
 but their impact.

It's actually 74 packages at current, if my quick and dirty grepping is correct:

% qgrep -H PYTHON_COMPAT | grep -v python2 | grep -v 'python{2' | cut
-f1 -d : | cut -f 1,2 -d / | uniq
app-accessibility/accerciser
app-accessibility/orca
app-accessibility/speech-dispatcher
app-admin/cdist
app-arch/tardelta
app-arch/vimball
app-backup/backintime
app-editors/gedit
app-editors/gedit-plugins
app-editors/retext
app-emulation/lxc
app-i18n/ibus-cangjie
app-misc/media-player-info
app-portage/grs
app-text/nfoview
dev-libs/libgit2-glib
dev-libs/libixion
dev-python/aiohttp
dev-python/asyncio
dev-python/beautifulsoup
dev-python/cangjie
dev-python/cfgio
dev-python/dugong
dev-python/elasticsearch-py
dev-python/mypy
dev-python/pmw
dev-python/polygon
dev-python/pydns
dev-python/pyfltk
dev-python/pymtp
dev-python/python3-openid
dev-python/pythondialog
dev-python/pyx
dev-python/simpletal
dev-python/torment
dev-python/utmp
dev-util/cligh
dev-util/devhelp
dev-util/fatrace
dev-vcs/gitg
games-util/nml
gnome-base/gnome-shell
gnome-extra/gnome-builder
media-gfx/blender
media-gfx/eog-plugins
media-sound/gnome-music
media-sound/lyvi
media-sound/pithos
media-sound/rhythmbox
media-video/gaupol
media-video/pitivi
net-analyzer/pypacker
net-irc/znc
net-misc/gns3-converter
net-misc/gns3-gui
net-misc/gns3-server
net-misc/wget
net-news/canto-curses
net-news/canto-daemon
sci-electronics/pulseview
sci-electronics/sigrok-cli
sci-libs/libsigrokdecode
sys-apps/razercfg
sys-block/blocks
sys-fs/s3ql
sys-kernel/kergen
sys-process/systemd-cron
www-client/pybugz
www-client/qutebrowser
x11-apps/intel-gpu-tools
x11-misc/compton
x11-misc/dex
x11-misc/redshift
x11-misc/treeline

I have removed portage and python-exec as false positives from this
grep. Then there is net-misc/wget which only needs python if USE=test
is enabled. There may be a few more like that.

I don't see anything else that is immediately important.
-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Problems updating Qt from 4.8.6 to 4.8.7

2015-07-05 Thread Ben de Groot
On 6 July 2015 at 03:25, Sebastian Pipping sp...@gentoo.org wrote:
 On 05.07.2015 20:44, Alexandre Rostovtsev wrote:
 What I usually end up doing is listing my installed dev-qt/qt* ebuilds, and
 updating all of them together explicitly:

 emerge -1 qtcore:4 qtgui:4 qtsql:4 etc.

 That's what I tried but it doesn't seem to work with this update.

 Looking at the dependencies of qtgui

   dev-qt/qtgui-4.8.6-r4
 DEPEND
   ~dev-qt/qtcore-4.8.6

   dev-qt/qtgui-4.8.7
 DEPEND
   ~dev-qt/qtcore-4.8.7

 I really wonder if there is any update path from having

   dev-qt/qtcore-4.8.6-r2
   dev-qt/qtgui-4.8.6-r4

 installed before to

   dev-qt/qtcore-4.8.7
   dev-qt/qtgui-4.8.7

 after.  Right now, it looks like I have to use emerge -C .. to
 un-install them completely, temporary breaking Qt and installing 4.8.7
 fresh.  I'm still hoping for some way to not needing to do that.


 Alternatively, just try emerge --update --deep world - it probably should
 work if you have a consistent, complete and updateable world set.

 That's where I'm coming from.  It doesn't stop complaining because of Qt.

 Best,



 Sebastian



See also 
https://wiki.gentoo.org/wiki/Qt/FAQ#Why_do_I_get_blockers_when_trying_to_emerge_Qt.3F

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] RFC News item: FFmpeg default

2015-04-16 Thread Ben de Groot
On 11 April 2015 at 15:19, Ben de Groot yng...@gentoo.org wrote:

 And since this is now on the Council's agenda, we're waiting for their 
 decision.


Since the Council had no objections, this has now been committed.

Thanks for all the feedback.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] RFC News item: FFmpeg default

2015-04-11 Thread Ben de Groot
On 7 April 2015 at 15:00, Alexis Ballier aball...@gentoo.org wrote:
 On Tue, 7 Apr 2015 07:13:16 +0800
 Ben de Groot yng...@gentoo.org wrote:

   Please also note that some packages support only one of the two
   implementations. An attempt to install one of those packages may
  result in blockers requiring the user changes the global USE=libav
  state. The most notable example of such package is
  media-video/mplayer. -media-video/mpv may be used as a replacement
  for users who prefer libav. +media-video/mpv may be used as a
  replacement for users who prefer libav, +even though upstream mpv
  developers recommend using ffmpeg.
 
  This is off-topic, and strongly biased.

 The original statement may give the impression that mpv is to libav
 what mplayer is to ffmpeg. Many users were surprised to find out that
 mpv upstream actually recommends ffmpeg, and that some of mpv's
 features do not work with libav. If we are going to specifically
 recommend mpv, then it is something users need to be aware of.

 We could change it to: media-video/mpv works with both ffmpeg and
 libav, though some of its features require ffmpeg. Or something along
 those lines.


 I'd rather drop entirely that part about mplayer/mpv; I agree this is
 something users need to be aware of if we recommend mpv but with ffmpeg
 as default the mplayer hard requires ffmpeg is no longer an issue.
 Otherwise, we might as well note that gst-libav recommends... heh...
 libav, and as such all gst based players (totem, firefox, etc.)

 Alexis.


Good point. So let's drop The most notable example ... until the end
of the paragraph.

And since this is now on the Council's agenda, we're waiting for their decision.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] libressl status

2015-04-06 Thread Ben de Groot
On 7 April 2015 at 06:07, Jason A. Donenfeld zx...@gentoo.org wrote:
 Solution:

 Packages that will compile against either one get || (openssl libressl).
 Packages that require a specific one will just have that one listed. Openssl
 will block Libressl and vice versa.

This would result in a similar mess as we have been dealing with in
the ffmpeg / libav situation. Please don't do that. Make the choice
explicit, and don't rely on semi-automagic dependency resolution.
Also, explain clearly to users what the default implementation is and
why.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] RFC News item: FFmpeg default

2015-04-06 Thread Ben de Groot
On 6 April 2015 at 17:35, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2015-04-06, o godz. 14:10:12
 Ben de Groot yng...@gentoo.org napisał(a):

 On 30 March 2015 at 00:23, Michał Górny mgo...@gentoo.org wrote:
  Dnia 2015-03-30, o godz. 00:07:16
 
  Include example code.
 

 Updated version:

 Title: FFmpeg default
 Author: Ben de Groot yng...@gentoo.org
 Content-Type: text/plain
 Posted: 2015-04-07
 Revision: 1
 News-Item-Format: 1.0
 Display-If-Installed: media-video/ffmpeg
 Display-If-Installed: media-video/libav

 Since the choice between ffmpeg and libav has been made more
 explicit, there has been a lot of discussion about what the
 default implementation should be. It can be concluded that
 media-video/ffmpeg has wider support, and would be somewhat
 more convenient for most end-users.

 For this reason the default implementation has been switched
 back from media-video/libav to media-video/ffmpeg by removing
 the libav useflag from the base profile.

 'Switched back' is suggesting there was some 'unintentional' switch
 from ffmpeg to libav. Keep this free of politics, and just 'switched'.

No, it does not suggest that. It simply reflects the history of the
issue: once upon a time we had ffmpeg. Then libav was introduced and
at some point made the default implementation. Now we are switching
back to ffmpeg as default implementation. There is no politics in my
statement.

 If the libav useflag is already globally enabled or disabled
 in /etc/portage/make.conf, then no further action is required.

 Users who implicitly relied on libav being enabled in their
 profile, and who wish to continue using libav, should enable
 USE=libav in their /etc/portage/make.conf file.

  Also please prepare an update to the USE=libav news item to state
  updated default.

 Diff:

 --- 
 /var/portage/metadata/news/2015-02-01-use-libav/2015-02-01-use-libav.en.txt
 2015-02-04 05:31:20.0 +0800
 +++ /home/ben/tmp/2015-02-01-use-libav.en.txt   2015-04-06
 14:05:56.982039939 +0800
 @@ -2,7 +2,7 @@
  Author: Michał Górny mgo...@gentoo.org
  Content-Type: text/plain
  Posted: 2015-02-01
 -Revision: 1
 +Revision: 2
  News-Item-Format: 1.0
  Display-If-Installed: media-video/ffmpeg
  Display-If-Installed: media-video/libav
 @@ -20,17 +20,17 @@
  However, whenever appropriate additional USE=libav will be introduced to
  control the preference of one implementation over the other.

 -Users who currently use libav (the Gentoo default) do not have to
 -perform any action since USE=libav is enabled by default. It should be
 -noted that the users still need to enable USE=ffmpeg on packages with
 -optional libav support as well. Users who want to use ffmpeg instead
 -need to specify USE=-libav in make.conf explicitly.
 +Users who currently use libav need to enable USE=libav in
 +/etc/portage/make.conf. It should be noted that users still need to
 +enable USE=ffmpeg on packages with optional libav support as well.
 +Users who currently use ffmpeg need to take no action.

  Please also note that some packages support only one of the two
  implementations. An attempt to install one of those packages may result
  in blockers requiring the user changes the global USE=libav state.
  The most notable example of such package is media-video/mplayer.
 -media-video/mpv may be used as a replacement for users who prefer libav.
 +media-video/mpv may be used as a replacement for users who prefer libav,
 +even though upstream mpv developers recommend using ffmpeg.

 This is off-topic, and strongly biased.

The original statement may give the impression that mpv is to libav
what mplayer is to ffmpeg. Many users were surprised to find out that
mpv upstream actually recommends ffmpeg, and that some of mpv's
features do not work with libav. If we are going to specifically
recommend mpv, then it is something users need to be aware of.

We could change it to: media-video/mpv works with both ffmpeg and
libav, though some of its features require ffmpeg. Or something along
those lines.

  Please do not alter the state of 'libav' flag on a per-package basis
  (e.g. via package.use). The flag needs to be set globally to have

 FYI: since Council's meeting in one week, I have added this to
 the agenda. I'm really concerned about Gentoo's PR when users suffer
 due to developers ping-ponging implementations/defaults.

It's not so much ping-ponging as stumbling upon what is the best
solution for our users. Some years ago libav was made a soft default.
And if I recall correctly, that was done with very little discussion.
Recently this default was made harder by adding USE=libav to the base
profile. This resulted in quite a backlash from users.

Moreover, many upstreams of consuming packages actually prefer ffmpeg.
Add to that the upstream ffmpeg policy of merging in changes from
libav.

All in all, from an end-user point of view it makes more sense to have
ffmpeg as default. And when users were asked, they overwhelmingly
expressed support for changing

Re: [gentoo-dev] RFC News item: FFmpeg default

2015-04-06 Thread Ben de Groot
On 30 March 2015 at 00:23, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2015-03-30, o godz. 00:07:16

 Include example code.


Updated version:

Title: FFmpeg default
Author: Ben de Groot yng...@gentoo.org
Content-Type: text/plain
Posted: 2015-04-07
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: media-video/ffmpeg
Display-If-Installed: media-video/libav

Since the choice between ffmpeg and libav has been made more
explicit, there has been a lot of discussion about what the
default implementation should be. It can be concluded that
media-video/ffmpeg has wider support, and would be somewhat
more convenient for most end-users.

For this reason the default implementation has been switched
back from media-video/libav to media-video/ffmpeg by removing
the libav useflag from the base profile.

If the libav useflag is already globally enabled or disabled
in /etc/portage/make.conf, then no further action is required.

Users who implicitly relied on libav being enabled in their
profile, and who wish to continue using libav, should enable
USE=libav in their /etc/portage/make.conf file.

 Also please prepare an update to the USE=libav news item to state
 updated default.

Diff:

--- /var/portage/metadata/news/2015-02-01-use-libav/2015-02-01-use-libav.en.txt
2015-02-04 05:31:20.0 +0800
+++ /home/ben/tmp/2015-02-01-use-libav.en.txt   2015-04-06
14:05:56.982039939 +0800
@@ -2,7 +2,7 @@
 Author: Michał Górny mgo...@gentoo.org
 Content-Type: text/plain
 Posted: 2015-02-01
-Revision: 1
+Revision: 2
 News-Item-Format: 1.0
 Display-If-Installed: media-video/ffmpeg
 Display-If-Installed: media-video/libav
@@ -20,17 +20,17 @@
 However, whenever appropriate additional USE=libav will be introduced to
 control the preference of one implementation over the other.

-Users who currently use libav (the Gentoo default) do not have to
-perform any action since USE=libav is enabled by default. It should be
-noted that the users still need to enable USE=ffmpeg on packages with
-optional libav support as well. Users who want to use ffmpeg instead
-need to specify USE=-libav in make.conf explicitly.
+Users who currently use libav need to enable USE=libav in
+/etc/portage/make.conf. It should be noted that users still need to
+enable USE=ffmpeg on packages with optional libav support as well.
+Users who currently use ffmpeg need to take no action.

 Please also note that some packages support only one of the two
 implementations. An attempt to install one of those packages may result
 in blockers requiring the user changes the global USE=libav state.
 The most notable example of such package is media-video/mplayer.
-media-video/mpv may be used as a replacement for users who prefer libav.
+media-video/mpv may be used as a replacement for users who prefer libav,
+even though upstream mpv developers recommend using ffmpeg.

 Please do not alter the state of 'libav' flag on a per-package basis
 (e.g. via package.use). The flag needs to be set globally to have


-- 
Cheers,

Ben | yngwin
Gentoo developer



[gentoo-dev] RFC News item: FFmpeg default

2015-03-29 Thread Ben de Groot
Title: FFmpeg default
Author: Ben de Groot yng...@gentoo.org
Content-Type: text/plain
Posted: 2015-04-01
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: virtual/ffmpeg

Since the choice between ffmpeg and libav has been made more
explicit, there has been a lot of discussion about what the
default implementation should be. It can be concluded that
media-video/ffmpeg has wider support, and would be somewhat
more convenient for most end-users.

For this reason the default implementation has been switched
back from media-video/libav to media-video/ffmpeg by removing
the libav useflag from the base profile.

If the libav useflag is already globally enabled or disabled
in /etc/portage/make.conf, then no further action is required.

Users who implicitly relied on libav being enabled in their
profile, and who wish to continue using libav, should enable
this in their local /etc/portage configuration.


-- 
Cheers,

Ben | yngwin
Gentoo developer



[gentoo-dev] Last-rite x11-themes/gtk-engines-qtcurve

2015-03-28 Thread Ben de Groot
# Ben de Groot yng...@gentoo.org (29 Mar 2015)
# Merged with qtcurve-qt4 into x11-themes/qtcurve (with gtk useflag)
# Removal in 30 days. See also bug #544406.
x11-themes/gtk-engines-qtcurve

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] RFC: app-eselect category

2015-03-28 Thread Ben de Groot
On 29 March 2015 at 04:47, Ulrich Mueller u...@gentoo.org wrote:
 Now the number of eselect-* packages in the app-admin category has
 grown to 52. Should we create a new app-eselect category for them?

I think this is a good idea. So +1 from me.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] rfc: zsh completions -- optional or mandatory?

2015-03-27 Thread Ben de Groot
On 27 March 2015 at 00:51, William Hubbs willi...@gentoo.org wrote:
 The other method is shown by dev-vcs/hub at least, and maybe several
 other packages -- e.g. unconditionally installing the completions
 according to our small files installation practice and not reflecting
 the rdepend on app-shells/zsh.

This is standard practice already (e.g. for systemd unit files and
bash completion files), so this should be followed for zsh completion
files as well.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: multilib amd64 news item for review

2015-03-18 Thread Ben de Groot
On 18 March 2015 at 20:46, Duncan 1i5t5.dun...@cox.net wrote:
 Ben de Groot posted on Wed, 18 Mar 2015 15:40:02 +0800 as excerpted:

 On 17 March 2015 at 23:33, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2015-03-15, o godz. 15:11:47 Michał Górny mgo...@gentoo.org
 napisał(a):


 Here's -r1:
 [...]

 I think this is really great! Just one small nitpick:

 Note that after performing this step, 32-bit applications on user's
 system may become temporarily broken.

 Make that the user's system.

 What about...

 Note: 32-bit applications may be temporarily broken after this step.

 Concise and to the point. =:^)

Even better!

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] multilib amd64 news item for review

2015-03-18 Thread Ben de Groot
On 17 March 2015 at 23:33, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2015-03-15, o godz. 15:11:47
 Michał Górny mgo...@gentoo.org napisał(a):


 Here's -r1:
 [...]

I think this is really great! Just one small nitpick:

 Note that after performing this step, 32-bit applications on user's
 system may become temporarily broken.

Make that the user's system.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: media-video/mplayer2 media-video/smplayer2

2015-03-16 Thread Ben de Groot
On 16 March 2015 at 21:54, Юра Цимбалов yura.t...@gmail.com wrote:
 That would be great, but it depends on getting newer mpv stable, while
 (s)mplayer2 is dead and broken right now.

 https://bugs.gentoo.org/buglist.cgi?quicksearch=mplayer2list_id=2703540

 Why it's broken?

As stated in my original message: See bugs 452484, 485994, 512082, 519212.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: media-video/mplayer2 media-video/smplayer2

2015-03-16 Thread Ben de Groot
On 16 March 2015 at 19:17, Alexander Berntsen berna...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 16/03/15 11:09, Nikos Chantziaras wrote:
 On 16/03/15 11:58, Alexander Berntsen wrote:
 Does smplayer work with mpv?
 Version 14.9.0.6690 and up supports mpv.
 Then I would encourage that we stabilise this before removing (s)mplayer2.

That would be great, but it depends on getting newer mpv stable, while
(s)mplayer2 is dead and broken right now.

Anyway, it's probably a good idea to get that process started.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] multilib amd64 news item for review

2015-03-15 Thread Ben de Groot
On 15 March 2015 at 22:43, Ulrich Mueller u...@gentoo.org wrote:
 On Sun, 15 Mar 2015, Michał Górny wrote:

 Hello, everyone. Here's the first draft of news item for
 gx86-multilib. I tried to cover all the important aspects. Please
 review and let me know what you think.

 Title: True multilib support on amd64
 Author: Michał Górny mgo...@gentoo.org
 Content-Type: text/plain
 Posted: 2015-01-28
 Revision: 1
 News-Item-Format: 1.0
 Display-If-Keyword: amd64
 Display-If-Keyword: ~amd64

 Users of no-multilib profiles won't be affected, so maybe
 Display-If-Profile should be used (in addition, or instead of
 Display-If-Keyword)?

 Starting with 2015-03-29, we are enabling the true multilib support
 on amd64 and masking the old emul-linux-x86 package sets for removal.
 This change provides

 I'm not a native speaker, but shouldn't a future tense be used here?

English teacher here: no. The present continuous (are enabling) is a
normal way to express the future in English.
The only changes necessary here, as already noted, is changing 'with'
to 'on' before the date, and dropping 'the' before true.

It may be nice to specify *stable* amd64. I would also say that 'true'
is incorrect, as the emul packages were also truly multilib, just
implemented in a different way. Maybe 'eclass-based' is more specific
and less opinionated?

  our users with the opportunity to build 32-bit
 libraries from source with all the flexibility given by ebuilds, rather
 than relying on pre-packaged binary versions of them.
 [...]
 installed on their systems. This will aid the Package Manager
 in choosing the correct dependency resolution path. If using Portage,
 this can be done using the following command:

 $ emerge -C 'app-emulation/emul-linux-x86*'

 Note that after performing this step, 32-bit applications on your system

 So far you have used third person throughout, so avoid the your
 here.

I agree. Maybe 'that'?

-- 
Cheers,

Ben | yngwin
Gentoo developer



[gentoo-dev] Last rites: media-video/mplayer2 media-video/smplayer2

2015-03-15 Thread Ben de Groot
# Ben de Groot yng...@gentoo.org (15 Mar 2015)
# These projects have been abandoned upstream. Most mplayer2 devs have moved
# on to media-video/mpv, and users are suggested to do the same. We have
# media-video/baka-mplayer and media-video/smplayer available as Qt-based GUIs.
# See bugs 452484, 485994, 512082, 519212. Removal in 30 days.
media-video/mplayer2
media-video/smplayer2

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted

2015-03-14 Thread Ben de Groot
On 15 March 2015 at 06:34, Andreas K. Huettel dilfri...@gentoo.org wrote:
 imho,

 Questions:
 0. What names for the tree/repository.

 gentoo
 (it's also the repo_name)

Our repo is already named gentoo, so this makes the most sense.

But I wouldn't mind gentoo-main either. But then we should also
change the repo_name.

While we are at it, can we change the default location from
/usr/portage to something like /var/repos/${repo_name} then?

-- 
Cheers,

Ben | yngwin
Gentoo developer



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/base: package.use.mask

2015-03-14 Thread Ben de Groot
 mr_bones_15/03/09 18:15:22

   Modified: package.use.mask
   Log:
   hide the qt5 stuff for yabause for now

 [...]
 +# Michael Sterrett mr_bones_@g.o (09 Mar 2015)
 +# Mask qt5 support until qt5 is stable so as to not
 +# hold up making yabause stable.
 +games-emulation/yabause qt5

This is not necessary since qt5 is in base/use.stable.mask

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: Should there be a preference with qt4 and qt5 USE flags?

2015-03-09 Thread Ben de Groot
On 9 March 2015 at 04:17, Johannes Huber j...@gentoo.org wrote:
 Am Sonntag, 8. März 2015, 21:50:02 schrieb Nikos Chantziaras:
 On 08/03/15 21:35, Alexandre Rostovtsev wrote:
  On Sun, 2015-03-08 at 21:31 +0200, Nikos Chantziaras wrote:
  Some ebuilds in portage for Qt-based software support both Qt4 as well
  as Qt5. Some have +qt4 qt5 in IUSE, others have qt4 qt5.
 
  Is there a guideline for this somewhere? If a package needs Qt and thus
 
  lists:
  REQUIRED_USE=^^ ( qt4 qt5 )
 
  but otherwise doesn't prefer one version over the other and both are
  equally well supported, should qt4 still be enabled by default?

 As long qt5 is testing only qt4 makes sense.

This. For now, we need to prefer qt4, if there is a choice between qt4
and qt5. (Unless upstream has already abandoned the qt4 option, which
makes it less of a choice, I guess.) But please set useflags for both
options, so the choice is clear to the user.

As soon as qt5 goes stable, I think we should switch to qt5 as default
where possible.

And especially when we have an at-least-one-of or an either-or
required-use, we need to have one of the options set as default.
-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: Fonts project meeting and elections

2015-03-04 Thread Ben de Groot
On 1 March 2015 at 23:36, Guilherme Amadio ama...@gentoo.org wrote:
 On Sun, Mar 01, 2015 at 08:59:38PM +0800, Ben de Groot wrote:
 On 28 February 2015 at 19:52, Michael Orlitzky m...@gentoo.org wrote:
  On 02/28/2015 01:47 AM, Ben de Groot wrote:
 
  If we do the use expand, we should leave it up for users to set. I
  suggest we default to only otf, if there is a choice. Other formats
  should not be installed by default, unless it's the only option for
  that package.
 
 
  This is going to get confusing fast -- please consider just installing
  everything by default. If you default to only OTF, what happens when
  you install a foo-ttf package? Is it a no-op? What if there's a package
  that only ships WOFF files? A combination of TTF and WOFF?
 
  Most of the fonts are tiny and it's not worth the hassle to avoid a few
  kilobytes. It will also keep the eclass nice and clean. If you default
  to installing everything, then when a user goes out of his way to remove
  (say) WOFF, you can go ahead and just ignore WOFF files even if the
  result is something stupid like an empty package.
 
  (The webfonts might be useful for clients, by the way. If they're not
  installed locally, your browser downloads them on-demand and caches them
  for later use.)
 
 

 Actually, after thinking about it some more, and doing some more
 research, I think this approach is unnecessary. Unless someone can
 tell me otherwise, I don't think we have any software that can handle
 truetype fonts but not opentype fonts. Most if not all of these
 packages use media-libs/freetype, which displays both formats just
 fine. So when we have font packages that offer both ttf and otf, then
 we should just install the superior format, which is OpenType.

 For packages that only offer one format, we install that format.

 Webfonts are also not an issue, as they are simply repackaged OpenType
 fonts aimed at web delivery. But most web developers use third party
 CDNs for that, such as Google Fonts. For the very few people who want
 to serve WOFF fonts from their own websites, I'm sure they can locate
 them as necessary.

 And webfonts are not useful for clients. Users should simply install
 the otf (or ttf) format of those fonts locally, and they will be
 picked up instead of the webfonts.

 Summarized, I propose the following policy:

 1. If there is a choice of formats between otf and ttf, install only otf.
 2. Do not install webfonts.

 I agree with your policy, but I think it's still a good idea to offer a
 mechanism to install the other formats for those who need it, maybe via
 truetype and woff or webfont USE flags. LaTeX, for example, may not be
 able to use OpenType fonts, unless you use XeTeX, or other newer
 variant, and sometimes a package you may want to use is only available
 for plain LaTeX or PDFTeX (pst-solides3d and pstricks come to mind).

 We could have global USE flags for each popular font format, turn on the
 flag for OpenType by default, and let users choose extra formats they
 want. Another thing we might want to work on is on a way to convert
 fonts for use with legacy LaTeX software that can't use OpenType files.

Alexis, can you shed some light on this from the TeX side? What font
formats can be used by various TeX packages?

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: Fonts project meeting and elections

2015-03-01 Thread Ben de Groot
On 28 February 2015 at 19:52, Michael Orlitzky m...@gentoo.org wrote:
 On 02/28/2015 01:47 AM, Ben de Groot wrote:

 Since this is mostly used for web developers, I recommend to leave it
 off for desktop users, but possibly on for servers, for example.

 If we do the use expand, we should leave it up for users to set. I
 suggest we default to only otf, if there is a choice. Other formats
 should not be installed by default, unless it's the only option for
 that package.


 This is going to get confusing fast -- please consider just installing
 everything by default. If you default to only OTF, what happens when
 you install a foo-ttf package? Is it a no-op? What if there's a package
 that only ships WOFF files? A combination of TTF and WOFF?

 Most of the fonts are tiny and it's not worth the hassle to avoid a few
 kilobytes. It will also keep the eclass nice and clean. If you default
 to installing everything, then when a user goes out of his way to remove
 (say) WOFF, you can go ahead and just ignore WOFF files even if the
 result is something stupid like an empty package.

 (The webfonts might be useful for clients, by the way. If they're not
 installed locally, your browser downloads them on-demand and caches them
 for later use.)



Actually, after thinking about it some more, and doing some more
research, I think this approach is unnecessary. Unless someone can
tell me otherwise, I don't think we have any software that can handle
truetype fonts but not opentype fonts. Most if not all of these
packages use media-libs/freetype, which displays both formats just
fine. So when we have font packages that offer both ttf and otf, then
we should just install the superior format, which is OpenType.

For packages that only offer one format, we install that format.

Webfonts are also not an issue, as they are simply repackaged OpenType
fonts aimed at web delivery. But most web developers use third party
CDNs for that, such as Google Fonts. For the very few people who want
to serve WOFF fonts from their own websites, I'm sure they can locate
them as necessary.

And webfonts are not useful for clients. Users should simply install
the otf (or ttf) format of those fonts locally, and they will be
picked up instead of the webfonts.

Summarized, I propose the following policy:

1. If there is a choice of formats between otf and ttf, install only otf.
2. Do not install webfonts.

Your thoughts?
-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] [RFC] luajit global useflag

2015-03-01 Thread Ben de Groot
On 26 February 2015 at 22:44, Michał Górny mgo...@gentoo.org wrote:


 Ben de Groot yng...@gentoo.org napisał:

 % quse -D luajit
local:luajit:app-editors/gvim: Use dev-lang/luajit instead of
dev-lang/lua
local:luajit:app-editors/vim: Use dev-lang/luajit instead of
dev-lang/lua
local:luajit:app-editors/vim-qt: Use dev-lang/luajit instead of
dev-lang/lua
local:luajit:games-action/minetest: Use dev-lang/luajit instead of
dev-lang/lua
 local:luajit:games-engines/solarus: Use LuaJIT instead of default Lua.
 local:luajit:games-roguelike/stone-soup: Use dev-lang/luajit as
scripting backend instead of dev-lang/lua.
 local:luajit:media-sound/csound: Use the lua just-in-time compiler
dev-lang/luajit instead of dev-lang/lua
local:luajit:media-video/mpv: Use dev-lang/luajit instead of
dev-lang/lua
 local:luajit:www-client/luakit: Use the lua just-in-time compiler
dev-lang/luajit instead of dev-lang/lua, which should make luakit
faster.
 local:luajit:www-servers/nginx: Use dev-lang/luajit instead of
dev-lang/lua for lua support when building the lua http module.

I propose we make luajit a global useflag, using the description from
media-sound/csound:

Use the lua just-in-time compiler pkgdev-lang/luajit/pkg instead
of pkgdev-lang/lua/pkg

 How about we figure out how to handle multiple versions and interpreters 
 sanely instead? Not that I mind USE=luajit but I do mind the huge 
 conditionals with random USE flags like recently suggested for neovim.


That would be great going forward. But at this point it's a non-issue.
There is a choice between lua-5.1 and luajit. Other lua versions have
been masked since like forever. And I don't see that situation
changing anytime soon.

Or maybe one of the other lua package maintainers has plans?

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: Fonts project meeting and elections

2015-02-27 Thread Ben de Groot
On 28 February 2015 at 00:26, Guilherme Amadio ama...@gentoo.org wrote:
 On Fri, Feb 27, 2015 at 03:45:23PM +0800, Ben de Groot wrote:

 1. lu_zero, matsuu, pva: do you still want to be members of the Fonts
 project? Then add yourselves to the new project page:
 https://wiki.gentoo.org/wiki/Project:Fonts

 I'm listed, but why can I not edit the page? I'd like to be able to.

You need to contact a...@gentoo.org to give you developer status on the wiki.

 3. Handling of fonts with both truetype and opentype variants, as
 brought up in https://bugs.gentoo.org/406301#c8
 Since OpenType is an extension of TrueType, and superior for desktop
 and printing use, I propose that we prefer installing just OpenType.
 But this should be user configurable, so in those cases I propose we
 do:

 IUSE=+opentype
 if use opentype; then
 FONT_SUFFIX=otf
 else
 FONT_SUFFIX=ttf
 fi

 Both this and the use expand suggested by Luca seem good methods.
 I also suggest we prefer OpenType over TrueType whenever possible.

We need to get an addition to the eclass whipped up then, for use
expand handling.

 4. Project member should have a look at font bugs.
 https://bugs.gentoo.org/buglist.cgi?quicksearch=media-fonts has a lot
 of low hanging fruit: version bumps, dead homepages, etc. Also some
 good new packages.

 I've seen a few of those and suggested webpages for a couple of them.
 I can go fix some of these if nobody else does.

Please do.

 5. Some fonts have webfont variants (WOFF is the important one here).
 This may be useful for users doing web development. What are your
 thoughts on installing those (conditionally, toggled by useflag)?

 Since this is mostly used for web developers, I recommend to leave it
 off for desktop users, but possibly on for servers, for example.

If we do the use expand, we should leave it up for users to set. I
suggest we default to only otf, if there is a choice. Other formats
should not be installed by default, unless it's the only option for
that package.

 Anything else you want to discuss?


 I'd like to suggest that we do not name new font packages font-*, but
 simply by the name of the typeface, such as open-sans, source-pro, etc.

I totally agree. I would also like to prevent format suffixes, such as
in ttf-bitstream-vera. And I would also like just lowercase package
names.

I think all font-* packages we have in the tree are X.org shipped
bitmap fonts. It's a useful indication for most users to ignore these.

 There is Source Serif, Source Sans, and Source Han Sans that are not
 packaged yet (see https://github.com/adobe-fonts for more info),

We do have media-fonts/source-pro, and I am planning on bumping that
package, as per bug #429780. I am hesitant to include the Han font
tho, since it is a 700+ MB download that may catch users unawares.

 as well
 as many other nice and well-known typefaces and icon fonts such as
 Aller, Amble, Casper, Clear Sans, Entypo, Font Awesome, Signika, Comic
 Neue, Fira, Nexa, Exo, Nobile, Open Sans, etc.

Some of those are on my to-do list already, but feel free to add others.

 There is also the really nice Input (http://input.fontbureau.com), but
 its license is only free for personal use, so we may need to talk to its
 designer to see if we can package it at all. I'm using it on my laptop,
 and it's a pleasure to read and very customizable.

The non-redistributable license is a problem. That's why I have chosen
not to include Envy R (which is somewhat popular for coding too).
Adding fonts with fetch restrictions seem counter-productive to me.
Users can simply download them for themselves and drop them in
~/.fonts/.

 Well, maybe opening a #gentoo-fonts on IRC will be a nice way to
 coordinate our efforts.

I don't think there will be that much to discuss on an ongoing basis
wrt fonts that it warrants a new channel. Let's keep it in
#gentoo-desktop for now, and see if we actually need a dedicated
channel.

 Also, this is definitely a minor thing, but all designers prefer the
 term typeface to font when referring to typefaces, so they'd probably be
 happy if media-fonts became media-type, or something similar. The
 distinction is that the set of fonts (regular, light, bold, condensed,
 etc) is what makes a typeface, which is the general style of all fonts
 in the set. Anyway, just food for thought.

I am aware of this, but the usage of fonts is so ingrained in the
popular mind, and it's a minor mistake at worst. I don't think it is
worth going thru the trouble of renaming the category (and fixing all
revdeps) for. We could use typeface in descriptions tho.

Finally, I would like to bring up fontconfig-ultimate [1] with a user
provided ebuild [2]  and some discussion on the forums [3]. There are
also many fixed fonts available, packaged for Arch Linux [4]. There
is some user demand for this, so I think we should package it. I
haven't yet taken the time to do so (too much other stuff going on).
What are your thoughts?

1: https://github.com/bohoomil

Re: [gentoo-dev] Re: Fonts project meeting and elections

2015-02-27 Thread Ben de Groot
On 27 February 2015 at 18:34, Peter Stuge pe...@stuge.se wrote:
 Ben de Groot wrote:
 I propose that we prefer installing just OpenType. But this should
 be user configurable, so in those cases I propose we do:

 IUSE=+opentype
 if use opentype; then
 FONT_SUFFIX=otf
 else
 FONT_SUFFIX=ttf
 fi

 So if I first USE=-opentype and later USE=opentype the filenames
 would change even though the fonts are actually the same. Do you
 know that no software packages will get horribly confused by that,
 and end up doing silly things such as listing each font twice?

So what are you suggesting?

-- 
Cheers,

Ben | yngwin
Gentoo developer



[gentoo-dev] Re: Fonts project meeting and elections

2015-02-26 Thread Ben de Groot
On 22 February 2015 at 03:43, Ben de Groot yng...@gentoo.org wrote:
 To anyone within Gentoo who is interested in fonts

 I would like to announce a meeting to be held in #gentoo-meetings on
 Freenode, on Friday February 27 at 06:00 UTC, unless another date
 and/or time will be suggested by people who want to attend.

Since nobody actually showed up, here is what I've decided and am proposing:

1. lu_zero, matsuu, pva: do you still want to be members of the Fonts
project? Then add yourselves to the new project page:
https://wiki.gentoo.org/wiki/Project:Fonts

2. Since aballier voted for me, and there were no other nominations,
we default to me becoming the lead.

3. Handling of fonts with both truetype and opentype variants, as
brought up in https://bugs.gentoo.org/406301#c8
Since OpenType is an extension of TrueType, and superior for desktop
and printing use, I propose that we prefer installing just OpenType.
But this should be user configurable, so in those cases I propose we
do:

IUSE=+opentype
if use opentype; then
FONT_SUFFIX=otf
else
FONT_SUFFIX=ttf
fi

4. Project member should have a look at font bugs.
https://bugs.gentoo.org/buglist.cgi?quicksearch=media-fonts has a lot
of low hanging fruit: version bumps, dead homepages, etc. Also some
good new packages.

5. Some fonts have webfont variants (WOFF is the important one here).
This may be useful for users doing web development. What are your
thoughts on installing those (conditionally, toggled by useflag)?

Anything else you want to discuss?

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] [PATCH] qmake-utils.eclass: add qt{4,5}_get_bindir helper functions

2015-02-25 Thread Ben de Groot
On 20 February 2015 at 04:06, Jeroen Roovers j...@gentoo.org wrote:
 On Wed, 18 Feb 2015 19:58:29 +0800
 Ben de Groot yng...@gentoo.org wrote:

 The attached patch proposes two helper functions to be added to
 qmake-utils.eclass. These functions echo the correct directory where
 qt binaries such as moc and lrelease are located. They can be used in
 ebuilds when such binaries need to be called directly. (Ebuilds should
 not rely on qtchooser for this.)

 Please review before I commit.

 Looks good (barring what Davide noted).

 Do you have a list of ebuilds that might benefit?

 I know net-analyzer/wireshark might, but it doesn't even use
 qmake-utils.eclass right now simply because it doesn't use qmake (but it
 does use moc and uic, so I wouldn't expect to find those functions in an
 eclass seemingly about qmake).


Committed, with improvements by Davide.

Based on a quick qgrep for lrelease/moc/uic, packages that would benefit are:

app-cdr/qpxtool
app-crypt/pinentry
app-editors/znotes
app-text/diffpdf
app-text/qpdfview
dev-util/universalindentgui
games-board/qgo
games-emulation/higan
games-kids/cubetest
games-util/higan-purify
media-sound/lastfmplayer
media-sound/musescore
media-video/smplayer
media-video/videocut
media-video/vlc
media-video/xvideoservicethief
net-analyzer/wireshark
net-im/psi
net-im/skype
net-p2p/transmission
sci-calculators/speedcrunch
sci-geosciences/gpsbabel
sci-geosciences/merkaartor
sci-visualization/qtiplot/
sys-boot/unetbootin

-- 
Cheers,

Ben | yngwin
Gentoo developer



[gentoo-dev] [RFC] luajit global useflag

2015-02-25 Thread Ben de Groot
 % quse -D luajit
 local:luajit:app-editors/gvim: Use dev-lang/luajit instead of dev-lang/lua
 local:luajit:app-editors/vim: Use dev-lang/luajit instead of dev-lang/lua
 local:luajit:app-editors/vim-qt: Use dev-lang/luajit instead of dev-lang/lua
 local:luajit:games-action/minetest: Use dev-lang/luajit instead of dev-lang/lua
 local:luajit:games-engines/solarus: Use LuaJIT instead of default Lua.
 local:luajit:games-roguelike/stone-soup: Use dev-lang/luajit as
scripting backend instead of dev-lang/lua.
 local:luajit:media-sound/csound: Use the lua just-in-time compiler
dev-lang/luajit instead of dev-lang/lua
 local:luajit:media-video/mpv: Use dev-lang/luajit instead of dev-lang/lua
 local:luajit:www-client/luakit: Use the lua just-in-time compiler
dev-lang/luajit instead of dev-lang/lua, which should make luakit
faster.
 local:luajit:www-servers/nginx: Use dev-lang/luajit instead of
dev-lang/lua for lua support when building the lua http module.

I propose we make luajit a global useflag, using the description from
media-sound/csound:

Use the lua just-in-time compiler pkgdev-lang/luajit/pkg instead
of pkgdev-lang/lua/pkg

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps

2015-02-23 Thread Ben de Groot
On 23 February 2015 at 14:17, Vadim A. Misbakh-Soloviov m...@mva.name wrote:
 I'd also say:

 neovim:

 CDEPEND=dev-lang/luajit
 ...
   dev-lua/LuaBitOp

 1) I'm not sure luajit:1 fits the dep
 2) LuaJIT:2 has it's own bit modules and is unneded LuaBitOp

Thanks! I don't know that much about lua, so this is very helpful.

 Unibilium:
 1.1.2 made a day ago. Bump, please ;)

Already on it.

 lua-MessagePack:
 RDEPEND==dev-lang/lua-5.1
 And what about LuaJIT? Huh?

Yeah, but I just followed what I found upstream.

 Also, I've it in lua overlay, called dev-lua/messagepack, though. Naming can
 be discussed.

I don't mind either way. But again, I just followed upstream.

 But main point is:

 RDEPEND=
!luajit? (
!lua53? (
|| (
=dev-lang/lua-5.1*
=dev-lang/lua-5.2*
)
)
lua53? ( =dev-lang/lua-5.3* )
)
luajit?  ( dev-lang/luajit:2 )

 ...
src_install() {
local lua=lua
use luajit  lua=luajit

insinto $($(tc-getPKG_CONFIG) --variable INSTALL_LMOD ${lua})
if use lua53; then
doins src5.3/MessagePack.lua
else
doins src/MessagePack.lua
fi
}

Thanks. But I think we can simplify that for now, since lua53 isn't
available (neither in the official tree or the lua overlay) and
=lua-5.2 is hardmasked.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps

2015-02-22 Thread Ben de Groot
On 23 February 2015 at 01:39, William Hubbs willi...@gentoo.org wrote:
 On Sat, Feb 21, 2015 at 09:18:08AM +0100, Michał Górny wrote:
 neovim:

  # Copyright 1999-2015 Gentoo Foundation
  # Distributed under the terms of the GNU General Public License v2
  # $Header: $
 
  EAPI=5
  inherit cmake-utils flag-o-matic
 
  DESCRIPTION=Vim's rebirth for the 21st century
  HOMEPAGE=https://github.com/neovim/neovim;
  if [[ ${PV} ==  ]]; then
  inherit git-r3
  EGIT_REPO_URI=git://github.com/neovim/neovim.git
  KEYWORDS=
  else
  inherit vcs-snapshot
  COMMIT=8efb3607a7f6cefce450953c7f8d5e3299347bae
  SRC_URI=https://github.com/${PN}/${PN}/tarball/${COMMIT} - 
  ${P}.tar.gz

 I don't think relying on stability of generated tarballs is a good
 idea. The same applies to almost all other ebuilds.

 If the tarball is based on an upstream tag, you should be fine, but this
 does not work for a commit hash like what is being used here.

 For more info on this, check out the man page for git archive. In
 particular, how it handles timestamps inside the tarball.

 In a nutshell, if you use git archive to create a tarball based on a
 commit hash, the time stamps of the files inside the tarball are
 different each time you create it, but this is not true if the tarball
 is based on an upstream tag.

 William

Thanks for the explanation! I'll roll tarballs then for our use until
upstream does tags or releases.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Fonts project meeting and elections

2015-02-22 Thread Ben de Groot
On 22 February 2015 at 23:27, Guilherme Amadio ama...@gentoo.org wrote:
 Hello,

 On Sun, Feb 22, 2015 at 03:43:33AM +0800, Ben de Groot wrote:
 To anyone within Gentoo who is interested in fonts

 I would like to announce a meeting to be held in #gentoo-meetings on
 Freenode, on Friday February 27 at 06:00 UTC, unless another date
 and/or time will be suggested by people who want to attend.

 There hasn't been much activity in the fonts area of Gentoo, and our
 lead seems to be MIA.

 The main points on the agenda:

 1. Who wants to be member of the Fonts project, and help out?
 2. Members to elect a new lead. I'm nominating myself.
 3. Make a plan for dealing with open bugs
 4. Open floor


  Yes, I would like to be part of the team. I was thinking about creating
  a Typography project, but if there is already a Fonts project, it will
  work just as well. I won't nominate myself as a lead, since I just
  became a Gentoo dev, but I do want to help. I will show up to the
  meeting.


Welcome to the team!

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Hello Everyone

2015-02-22 Thread Ben de Groot
On 22 February 2015 at 20:05, Tushar Rajput tushra...@gmail.com wrote:


  I am novice programmer and wants to contribute to gentoo.Can you give me
 some details?
 Thanks


We actually have a wiki page that does:
https://wiki.gentoo.org/wiki/Contributing_to_Gentoo

-- 
Cheers,

Ben | yngwin
Gentoo developer


Re: [gentoo-dev] Fonts project meeting and elections

2015-02-22 Thread Ben de Groot
On 22 February 2015 at 17:52, Alexis Ballier aball...@gentoo.org wrote:
 Hi Ben,

 On Sun, 22 Feb 2015 03:43:33 +0800
 Ben de Groot yng...@gentoo.org wrote:

 To anyone within Gentoo who is interested in fonts

 I would like to announce a meeting to be held in #gentoo-meetings on
 Freenode, on Friday February 27 at 06:00 UTC, unless another date
 and/or time will be suggested by people who want to attend.
 [...]
 The main points on the agenda:

 1. Who wants to be member of the Fonts project, and help out?
 2. Members to elect a new lead. I'm nominating myself.


 I've been on the alias and maintaining a few fonts (or rather,
 fonts/tex) packages for a while now, whatever that means.

 I won't be able to attend the meeting, but considering you've been the
 (only?) one doing most of the work on fonts side recently, count my
 vote  approval for you being the lead.


 Alexis.

Thanks and welcome to the team!

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps

2015-02-21 Thread Ben de Groot
On 21 February 2015 at 16:18, Michał Górny mgo...@gentoo.org wrote:
 Hi,

 Don't you think it sucks to review a few ebuilds in one e-mail? :)

No. :)

 neovim:

 # Copyright 1999-2015 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: $

 EAPI=5
 inherit cmake-utils flag-o-matic

 DESCRIPTION=Vim's rebirth for the 21st century
 HOMEPAGE=https://github.com/neovim/neovim;
 if [[ ${PV} ==  ]]; then
   inherit git-r3
   EGIT_REPO_URI=git://github.com/neovim/neovim.git
   KEYWORDS=
 else
   inherit vcs-snapshot
   COMMIT=8efb3607a7f6cefce450953c7f8d5e3299347bae
   SRC_URI=https://github.com/${PN}/${PN}/tarball/${COMMIT} - 
 ${P}.tar.gz

 I don't think relying on stability of generated tarballs is a good
 idea. The same applies to almost all other ebuilds.

Do we often run into trouble with that? I know it's not perfect, but
it should be temporary, until we get regular releases.

   KEYWORDS=~amd64 ~x86
 fi

 LICENSE=Apache-2.0 vim
 SLOT=0
 IUSE=perl python

 CDEPEND=dev-lang/luajit
   =dev-libs/libtermkey-0.17
   =dev-libs/unibilium-1.1.1
   =dev-libs/libuv-1.2.0
   =dev-libs/msgpack-0.6.0_pre20150220

 Accidentally found trailing whitespace here!

Not present in the actual ebuild.

   dev-lua/LuaBitOp
   dev-lua/lpeg
   dev-lua/lua-MessagePack
 DEPEND=${CDEPEND}
   virtual/libiconv
   virtual/libintl
 RDEPEND=${CDEPEND}
   perl? ( dev-lang/perl )
   python? ( dev-python/neovim-python-client )

 src_configure() {
   append-cflags -Wno-error
   append-cppflags -DNDEBUG -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
   local mycmakeargs=( -DCMAKE_BUILD_TYPE=Release )

 That looks like a very bad idea. Doesn't that disable all the Gentoo
 fancy overrides needed for sane CC/CXX etc.?

Any other way to do that then?

   cmake-utils_src_configure
 }

 And in the end it fails to build with some linker errors like:

 CMakeFiles/nvim.dir/tui/tui.c.o: In function `tui_set_scroll_region':
 tui.c:(.text+0xa2): undefined reference to `unibi_get_str'
 CMakeFiles/nvim.dir/tui/tui.c.o: In function `unibi_set_if_empty':
 tui.c:(.text+0x40c): undefined reference to `unibi_get_str'

 or for ncurses, if libtermkey was linked against ncurses. Long story
 short, it's linking to -ltermkey statically without providing
 -lunibilium before it... which (static linking) is a horrible thing
 to do anyway.

WFM, but yeah it's not ideal. I'll contact upstream about it.

 libtermkey:

 # Copyright 1999-2015 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: $

 EAPI=5
 inherit eutils multilib

 DESCRIPTION=Library for easy processing of keyboard entry from 
 terminal-based programs
 HOMEPAGE=http://www.leonerd.org.uk/code/libtermkey/;
 SRC_URI=http://www.leonerd.org.uk/code/${PN}/${P}.tar.gz;

 LICENSE=MIT
 SLOT=0
 KEYWORDS=~amd64 ~x86
 IUSE=demos

 RDEPEND=|| ( dev-libs/unibilium
   sys-libs/ncurses[unicode] )

 No, no, no, no, no and no. This dependency is meaningless, and broken.

 You're looking for either:

 # ignore ncurses since neovim will pull in unibilium anyway,
 # and then libtermkey will prefer it
 RDEPEND=dev-libs/unibilium:=

 or a USE flag to toggle the two. No auto-magic || () is doing.

Since neovim upstream now moved completely from ncurses to unibilium,
I guess it makes sense to just do that here too.

 DEPEND=${RDEPEND}
   sys-devel/libtool

 Using system-wide libtool is horrendously broken. This is something for
 upstream to fix (like they should start using a sane build system)
 but if you really want to commit it like this, already open a bug alike
 https://bugs.gentoo.org/show_bug.cgi?id=515554.

I'll report upstream. Anything else we can do in the meantime?

 The same applies to unibilium.

   virtual/pkgconfig
   demos? ( dev-libs/glib:2 )

 src_prepare() {
   if ! use demos; then
   sed -e 's|all: $(LIBRARY) $(DEMOS)|all: $(LIBRARY)|' -i 
 Makefile || die

 sed -e '/^all:/s:$(DEMOS)::' ...

   fi
 }

 src_compile() {
   emake PREFIX=${EPREFIX}/usr all

 You need LIBDIR here too, otherwise the executable gets wrong rpath.

ok

 The same applies to unibilium. Also unibilium doesn't respect CC here.

 }

 src_install() {
   emake PREFIX=${EPREFIX}/usr LIBDIR=${EPREFIX}/usr/$(get_libdir) \
   DESTDIR=${D} install
   prune_libtool_files
 }

 neovim-python-client:

 # Copyright 1999-2015 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: $

 EAPI=5
 PYTHON_COMPAT=( python{2_7,3_3,3_4} pypy )
 inherit distutils-r1

 DESCRIPTION=Python client to connect to Neovim thru its msgpack-rpc API
 HOMEPAGE=https://github.com/neovim/python-client;
 SRC_URI=https://github.com/neovim/python-client/archive/0.0.28.tar.gz - 
 ${P}.tar.gz

 Hardcoded PV. And obviously github generated tarball :).

Oops! That was an oversight.


 LICENSE=Apache-2.0
 

[gentoo-dev] Fonts project meeting and elections

2015-02-21 Thread Ben de Groot
To anyone within Gentoo who is interested in fonts

I would like to announce a meeting to be held in #gentoo-meetings on
Freenode, on Friday February 27 at 06:00 UTC, unless another date
and/or time will be suggested by people who want to attend.

There hasn't been much activity in the fonts area of Gentoo, and our
lead seems to be MIA.

The main points on the agenda:

1. Who wants to be member of the Fonts project, and help out?
2. Members to elect a new lead. I'm nominating myself.
3. Make a plan for dealing with open bugs
4. Open floor

-- 
Cheers,

Ben | yngwin
Gentoo developer



[gentoo-dev] Fonts project meeting and elections

2015-02-21 Thread Ben de Groot
To anyone within Gentoo who is interested in fonts

I would like to announce a meeting to be held in #gentoo-meetings on
Freenode, on Friday February 27 at 06:00 UTC, unless another date
and/or time will be suggested by people who want to attend.

There hasn't been much activity in the fonts area of Gentoo, and our
lead seems to be MIA.

The main points on the agenda:

1. Who wants to be member of the Fonts project, and help out?
2. Members to elect a new lead. I'm nominating myself.
3. Make a plan for dealing with open bugs
4. Open floor

-- 
Cheers,

Ben | yngwin
Gentoo developer



[gentoo-dev] Last rites: media-fonts/culmus-ancient

2015-02-20 Thread Ben de Groot
# Ben de Groot yng...@gentoo.org (21 Feb 2015)
# Duplicates media-fonts/culmus[ancient] (bug #486814).
# Masked for removal in 30 days.
media-fonts/culmus-ancient

-- 
Cheers,

Ben | yngwin
Gentoo developer



[gentoo-dev] [RFC] please review ebuilds for neovim and deps

2015-02-20 Thread Ben de Groot
At the suggestion of radhermit, I'm putting my neovim  deps ebuilds
up here for review, before I commit them to the official tree. Do you
see any possible improvements?

Right now the neovim ebuild does not install any global default nvimrc
like we do with vim. We should probably consider doing so. Also, I'm
looking for the best way to let neovim use the vim plugins we install
in $VIMRUNTIME (such as gentoo-syntax).

The ebuilds are available in my personal dev overlay, and I'm
attaching them to this mail.
-- 
Cheers,

Ben | yngwin
Gentoo developer


neovim-0.0.0_pre20150220.ebuild
Description: Binary data


libtermkey-0.17.ebuild
Description: Binary data


msgpack-0.6.0_pre20150220.ebuild
Description: Binary data


unibilium-1.1.1.ebuild
Description: Binary data


lua-MessagePack-0.3.2.ebuild
Description: Binary data


neovim-python-client-0.0.28.ebuild
Description: Binary data


trollius-1.0.4.ebuild
Description: Binary data


[gentoo-dev] [PATCH] qmake-utils.eclass: add qt{4,5}_get_bindir helper functions

2015-02-18 Thread Ben de Groot
The attached patch proposes two helper functions to be added to
qmake-utils.eclass. These functions echo the correct directory where
qt binaries such as moc and lrelease are located. They can be used in
ebuilds when such binaries need to be called directly. (Ebuilds should
not rely on qtchooser for this.)

Please review before I commit.

-- 
Cheers,

Ben | yngwin
Gentoo developer
--- gentoo-x86/eclass/qmake-utils.eclass	2014-11-22 11:04:23.765870730 +0800
+++ overlay/qt/eclass/qmake-utils.eclass	2015-02-11 23:10:51.067484243 +0800
@@ -51,6 +51,25 @@
 	esac
 }

+# @FUNCTION qt4_get_bindir
+# @DESCRIPTION:
+# Get the correct location of Qt4's installed binaries.
+qt4_get_bindir() {
+	local qtbindir=${EPREFIX}/usr/$(get_libdir)/qt4/bin
+	if [[ -x ${qtbindir} ]]; then
+		echo ${qtbindir}
+	else
+		echo ${EPREFIX}/usr/bin
+	fi
+}
+
+# @FUNCTION qt5_get_bindir
+# @DESCRIPTION:
+# Get the correct location of Qt5's installed binaries.
+qt5_get_bindir() {
+	echo ${EPREFIX}/usr/$(get_libdir)/qt5/bin
+}
+
 # @VARIABLE: EQMAKE4_EXCLUDE
 # @DEFAULT_UNSET
 # @DESCRIPTION:
@@ -158,11 +177,7 @@

 	[[ -n ${EQMAKE4_EXCLUDE} ]]  eshopts_pop

-	# determine qmake binary location
-	local qmake_path=${EPREFIX}/usr/$(get_libdir)/qt4/bin/qmake
-	[[ ! -x ${qmake_path} ]]  qmake_path=${EPREFIX}/usr/bin/qmake
-
-	${qmake_path} \
+	$(qt4_get_bindir)/qmake \
 		-makefile \
 		QMAKE_AR=$(tc-getAR) cqs \
 		QMAKE_CC=$(tc-getCC) \
@@ -213,7 +228,7 @@

 	ebegin Running qmake

-	${EPREFIX}/usr/$(get_libdir)/qt5/bin/qmake \
+	$(qt5_get_bindir)/qmake \
 		-makefile \
 		QMAKE_AR=$(tc-getAR) cqs \
 		QMAKE_CC=$(tc-getCC) \


Re: [gentoo-dev] ffmpeg vs libav choice of default

2015-02-14 Thread Ben de Groot
On 4 February 2015 at 17:26, Alexis Ballier aball...@gentoo.org wrote:
 On Wed, 4 Feb 2015 10:12:12 +0100
 Ulrich Mueller u...@gentoo.org wrote:

 With the recent introduction of the libav USE flag, the Gentoo default
 for ffmpeg vs libav is more pronounced than it was before (with libav
 being listed first in || ( ) dependencies).

 In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982
 several users have expressed their preference for ffmpeg.

 So can someone please remind me what are the technical reasons why we
 prefer libav over ffmpeg?


 good luck !

 wait for other opinions, but I'd say: libav has a cleaner codebase and
 stricter development rules. (NB: some gentoo devs are member of the core
 libav dev team)


 IMHO, from a pure consumer POV where I want to play a random video and
 my programs using the libraries not to break, ffmpeg is much better
 (more codecs get in faster, API is preserved a bit longer), so I never
 understood nor agreed with that choice of default.

I think for our users the latter is more important.

After all the discussion we had here and on the forums,
I propose we change the default to ffmpeg.

Thoughts?
-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Git mirror news: travis-ci running repoman, git-cvs merge revert tools

2015-02-09 Thread Ben de Groot
On 8 February 2015 at 18:38, Michał Górny mgo...@gentoo.org wrote:
 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


Thank you! This looks really useful.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

2015-02-07 Thread Ben de Groot
On 7 February 2015 at 23:06, hasufell hasuf...@gentoo.org wrote:
 DEPEND=

 unzip is missing from DEPEND

 I thought portage auto-depends on this. But I can add || ( unzip zip )
 to be explicit.


 I don't know, but it's definitely not in @system. Afair we are only
 allowed to omit deps from that set.

OK, added.

 src_compile() {
   local my_arch
   use x86  my_arch=x86-32-old
   use cpu_flags_x86_sse  my_arch=x86-32
   use amd64  my_arch=x86-64
   use cpu_flags_x86_popcnt  my_arch=x86-64-modern
   use cpu_flags_x86_avx2  my_arch=x86-64-bmi2

   emake build ARCH=${my_arch} CXX=$(tc-getCXX) CXXFLAGS=${CXXFLAGS}

 This currently breaks all cpu flags, because it overwrites anything the
 Makefile does to CXXFLAGS, including -msse and -DIS_64BIT and even other
 flags that are not CPU specific (e.g. -DNDEBUG).

 Thanks for catching this! I guess we do need to patch the Makefile
 then, to *also* honour user-set CXXFLAGS and LDFLAGS. Or could we get
 away with just letting the Makefile do its thing?


 I've hit this bug myself in my overlay... I'll probably get up a pull
 request upstream today.

I think it's okay now. They do += so the user cxxflags and ldflags do
get honoured, but they end their own flags at the end of it. I've
added some more configuration options to the ebuild (optimize and
debug are important here).

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] ffmpeg vs libav choice of default

2015-02-06 Thread Ben de Groot
On 7 February 2015 at 07:03, Jason A. Donenfeld zx...@gentoo.org wrote:
 Welp, the votes clearly show ffmpeg is desired by users.

 Can we stop this nonsense and just do that? The people have spoken.

 Ffmpeg shall be default.

Except Gentoo is not a democracy.

It is still important data to take into consideration tho.

-- 
Cheers,

Ben | yngwin
Gentoo developer



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

2015-02-06 Thread Ben de Groot
On 7 February 2015 at 00:59, hasufell hasuf...@gentoo.org wrote:
 Ben de Groot (yngwin):
 yngwin  15/02/05 20:09:33

   Added:stockfish-6.ebuild metadata.xml Manifest ChangeLog
   Log:
   Initial commit (bug #318337)


First off: thank you for the review!


 EAPI=5
 inherit toolchain-funcs


 This breaks consistency. Now users cannot rely on games.eclass anymore.
 We should either abandon it completely or follow it consistently.

I thought we had abandoned it already?

Is there anything to be gained from using games.eclass here? It is a
chess engine that simply installs one file in /usr/bin/.


 DESCRIPTION=The strongest chess engine in the world

 This isn't very informative. I'd suggest
 DESCRIPTION=Free UCI chess engine derived from Glaurung 2.1

I just took the description from upstream's website. But you are
right, it could be more informative. Will fix.

 HOMEPAGE=http://stockfishchess.org/;

 Probably add the github link here too.

I will unify the live and release ebuilds.

 SRC_URI=https://stockfish.s3.amazonaws.com/${P}-src.zip;

 LICENSE=GPL-3
 SLOT=0
 KEYWORDS=~amd64 ~x86
 IUSE=cpu_flags_x86_avx2 cpu_flags_x86_popcnt cpu_flags_x86_sse

 DEPEND=

 unzip is missing from DEPEND

I thought portage auto-depends on this. But I can add || ( unzip zip )
to be explicit.

 RDEPEND=

 S=${WORKDIR}/${P}-src/src

 src_prepare() {
   sed -e 's:-strip $(BINDIR)/$(EXE)::' -i Makefile
 }


 missing || die... I'd also rather make this a patch, so it doesn't
 silently break on version bump

The die would not accomplish anything, unless the file wasn't there
anymore. I thought this was too simple for a patch, but see below.

 src_compile() {
   local my_arch
   use x86  my_arch=x86-32-old
   use cpu_flags_x86_sse  my_arch=x86-32
   use amd64  my_arch=x86-64
   use cpu_flags_x86_popcnt  my_arch=x86-64-modern
   use cpu_flags_x86_avx2  my_arch=x86-64-bmi2

   emake build ARCH=${my_arch} CXX=$(tc-getCXX) CXXFLAGS=${CXXFLAGS}

 This currently breaks all cpu flags, because it overwrites anything the
 Makefile does to CXXFLAGS, including -msse and -DIS_64BIT and even other
 flags that are not CPU specific (e.g. -DNDEBUG).

Thanks for catching this! I guess we do need to patch the Makefile
then, to *also* honour user-set CXXFLAGS and LDFLAGS. Or could we get
away with just letting the Makefile do its thing?

 Fixing this should definitely be done in a revbump.

Obviously. Will do.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: ffmpeg vs libav choice of default

2015-02-06 Thread Ben de Groot
On 7 February 2015 at 10:08, Mike Auty ike...@gentoo.org wrote:
 [...] I
 was concerned that a warning which had been in place in package.mask
 since September was removed by a different developer than the one who
 put it in place,

I discussed this beforehand with said developer on IRC.

 and that a package was unmasked (while a USE flag was
 masked) which then forced everyone who read the portage news article
 and swapped mplayer to mpv based on the article, to then be told they
 have to rebuild with ffmpeg after all, and potentially rebuild a lot
 of other packages because of that.

I was not aware of mpv upstream preference for ffmpeg when that news
item was written, or I would have brought up that issue. You are right
that the resulting situation is more confusing than it should be.
Maybe I should have insisted on a news item, even tho maksbotan didn't
think that was necessary.

Do you think a news item to explain this situation and giving explicit
instructions for users who wish to stay with libav would be useful?

 The mask of the USE flag even
 removed the possibility of building the newer mpv with libav

No. Users can unmask the useflag and build mpv with libav if they wish.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] ffmpeg vs libav choice of default

2015-02-06 Thread Ben de Groot
On 6 February 2015 at 00:20, hasufell hasuf...@gentoo.org wrote:
 Ben de Groot:
 On 4 February 2015 at 21:49, Chí-Thanh Christopher Nguyễn
 chith...@gentoo.org wrote:
 Ulrich Mueller schrieb:

 In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982
 several users have expressed their preference for ffmpeg.

 To help finding out what users actually think, I added a poll to the forum
 to ask them about their preference.
 https://forums.gentoo.org/viewtopic-t-1010096.html

 They seem pretty strongly in favour of changing the default back to ffmpeg:
 https://forums.gentoo.org/viewtopic-t-1010096-postdays-0-postorder-asc-vote-viewresult.html


 57% is not pretty strongly. It's a bit more than the half.


If we add up the votes to a simpler overview, we get at this point:

ffmpeg  66.4%
libav8.2%
don't care  24.0%
other1.4%

I think that's pretty clear.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] ffmpeg vs libav choice of default

2015-02-06 Thread Ben de Groot
On 4 February 2015 at 20:43, Mike Auty ike...@gentoo.org wrote:
 Whilst the default *is* still in place (and particularly after the
 recent news article detailing that users should be using libav), could
 we please keep commits like the following until *after* we've made an
 agreed upon decision please?

 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/package.mask?r1=1.16328r2=1.16329

 Anyone using mpv (because mplayer does not work with libav, and they
 were directed to use mpv by the news article) will now be hit by
 blockers attempting to reinstall ffmpeg.

 It's fine to have disagreements, but airing them in front of the users
 like this is not an ideal situation...

That would suggest political motives or something of the sort. But
that is far from the truth. Newer mpv versions were masked for many
months, for no apparently valid reason, except that the libav versions
on which it optionally (!) depended were masked.

Since we introduced the libav useflag, we have now a way to finally
make mpv-0.7* (using the upstream recommended ffmpeg as default)
visible to ~arch users, without the need to unmask it. Users who wish
to use libav with it, can do so by unmasking the useflag and the
relevant libav version. (While before they would have had to unmask
both mpv and libav. The resulting change is minor.)

Fewer users will now need to unmask mpv-0.7*. Besides, it is a
reminder that upstream recommends ffmpeg, which comes as a surprise to
many.

And as a result, we can unmask the newest version of smplayer, which
can now function as a GUI frontend for mpv as well.

I would say this is an overall improvement for our end-users. I don't
want to get into the politics of it, but just look at it from a
practical perspective.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] ffmpeg vs libav choice of default

2015-02-05 Thread Ben de Groot
On 4 February 2015 at 21:49, Chí-Thanh Christopher Nguyễn
chith...@gentoo.org wrote:
 Ulrich Mueller schrieb:

 In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982
 several users have expressed their preference for ffmpeg.

 To help finding out what users actually think, I added a poll to the forum
 to ask them about their preference.
 https://forums.gentoo.org/viewtopic-t-1010096.html

They seem pretty strongly in favour of changing the default back to ffmpeg:
https://forums.gentoo.org/viewtopic-t-1010096-postdays-0-postorder-asc-vote-viewresult.html

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] ffmpeg vs libav choice of default

2015-02-04 Thread Ben de Groot
On 4 February 2015 at 17:21, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2015-02-04, o godz. 10:12:12
 Ulrich Mueller u...@gentoo.org napisał(a):

 With the recent introduction of the libav USE flag, the Gentoo default
 for ffmpeg vs libav is more pronounced than it was before (with libav
 being listed first in || ( ) dependencies).

 In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982
 several users have expressed their preference for ffmpeg.

 So can someone please remind me what are the technical reasons why we
 prefer libav over ffmpeg?

From an upstream that I care about:
https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav

Based on that I would say we should switch back the default to ffmpeg.
-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] ffmpeg vs libav choice of default

2015-02-04 Thread Ben de Groot
On 4 February 2015 at 17:55, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2015-02-04, o godz. 17:24:03
 Ben de Groot yng...@gentoo.org napisał(a):

 From an upstream that I care about:
 https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav

 Based on that I would say we should switch back the default to ffmpeg.

 From what I heard, that upstream likes to change its opinion
 frequently, pretty much based on which upstream he is pissed at
 the moment. But it's just rumors.

Rumours have no place here. Let's focus on the technical arguments.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

2015-02-02 Thread Ben de Groot
On 3 February 2015 at 00:00, Michael Orlitzky m...@gentoo.org wrote:
 On 02/02/2015 10:50 AM, Michał Górny wrote:

 Maybe. Though it still will keep the confusion of !libav meaning ffmpeg.


 We could remove USE=libav from the tree, leaving only USE=ffmpeg. Then
 ffmpeg_impl_libav would switch the implementation if USE=ffmpeg is enabled.



 Maybe a little cleaner but still relies on the implicit thing. Not to
 mention the user is supposed to set either:

   FFMPEG_IMPL=libav

 or:

   FFMPEG_IMPL=

 which is nowhere close to sane :).


 With only one flag, why bother with the USE_EXPAND?



Actually, after reading this conversation, I don't think we need the
USE_EXPAND. The current solution with USE=ffmpeg libav works. It may
not be the cleanest, but the other solution proposed here doesn't add
that much.

Please restore the news item and unmask the revbumps, so we can get on
with business. :)

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] git.gentoo.org/git.overlays.gentoo.org upgrades, 2014/12/24 2014/12/26: gitolite upgrade done

2014-12-28 Thread Ben de Groot
On 28 December 2014 at 11:36, Robin H. Johnson robb...@gentoo.org wrote:
 We are now running gitolite-gentoo-3.6.2.1, a huge jump from our prior
 2.3.3.

 File a bug if you see anything weird, and ping me in IRC (#gentoo-dev)
 if you think it's urgent.

There still is no web interface for browsing the repositories. What
are the plans for returning that service?

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

2014-12-24 Thread Ben de Groot
On 23 December 2014 at 00:11, Andreas K. Huettel dilfri...@gentoo.org wrote:
 +1 for an archive overlay

I set up the graveyard overlay for such purposes, a couple of years ago.
But it hasn't taken off: https://github.com/gentoo/graveyard

Feel free to resurrect it. (pun intended)

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Make 'vaapi' USE flag global

2014-11-30 Thread Ben de Groot
On 28 November 2014 at 20:20, Sergey Popov pinkb...@gentoo.org wrote:
 Packages that uses 'vaapi' local USE-flag:

 media-libs/avidemux-core
 media-libs/xine-lib
 media-tv/mythtv
 media-tv/xbmc
 media-video/avidemux
 media-video/ffmpeg
 media-video/hwdecode-demos
 media-video/libav.
 media-video/mpv
 media-video/vlc
 virtual/ffmpeg
 www-plugins/gnash

 Descriptions for that flag are pretty the same and we already have
 'vdpau' USE flag, which is for someway similar technology.

 So, how about making this flag global too?

Do it!

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Last rites: razorqt-base/*

2014-11-08 Thread Ben de Groot
On 8 November 2014 19:15, Jauhien Piatlicki jauh...@gentoo.org wrote:
 Hi Ben,

 Have you read comments on Qt overlay commit? Have you check reverse 
 dependencies of packages you are masking? razorqt-base/libqtxdg is used by 
 LXQt. So, please, unmask it. I will move it into lxqt-base category. But 
 until this, please, do not touch it. And, please, make sure you are reading 
 metadata.xml and checking revdeps of packages you are touching.

I mistakenly assumed you had a newer version of all packages in the
lxqt-base category. Nothing outside of the razorqt-base category
should logically have depended on a package in there. Anyway, I have
since fixed this issue with a package move to dev-libs/libqtxdg. I
have adjusted the depend lines in relevant lxqt ebuilds.

-- 
Cheers,

Ben | yngwin
Gentoo developer



[gentoo-dev] Last rites: razorqt-base/*

2014-11-07 Thread Ben de Groot
# Ben de Groot yng...@gentoo.org (7 Nov 2014)
# Unmaintained, no longer supported, and starting to throw compilation
# errors (bug #513906, bug #528372). Masked for removal in 30 days.
# Update to lxqt-base/* packages.
razorqt-base/libqtxdg
razorqt-base/razorqt-appswitcher
razorqt-base/razorqt-autosuspend
razorqt-base/razorqt-config
razorqt-base/razorqt-data
razorqt-base/razorqt-desktop
razorqt-base/razorqt-kbshortcuts
razorqt-base/razorqt-libs
razorqt-base/razorqt-lightdm-greeter
razorqt-base/razorqt-meta
razorqt-base/razorqt-notifications
razorqt-base/razorqt-openssh-askpass
razorqt-base/razorqt-panel
razorqt-base/razorqt-policykit
razorqt-base/razorqt-power
razorqt-base/razorqt-runner
razorqt-base/razorqt-session

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Add bc back to the stage3

2014-09-27 Thread Ben de Groot
On 27 September 2014 20:40, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 On Sat, 27 Sep 2014 18:31:03 +0600
 Vladimir Romanov bluebo...@gmail.com wrote:
 Em. I don't agree. I prefer Emacs and don't like Vim. But if i must
 choose between Vim and Nano, i prefer Nano

 But vi is POSIX.

vi is available through busybox already

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings

2014-08-18 Thread Ben de Groot
On 13 August 2014 02:46, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2014-08-11, o godz. 20:48:20
 William Hubbs willi...@gentoo.org napisał(a):
  got a minor (but chatty) QA warning:
  DESCRIPTION ends with a '.' character

 Why is this a QA warning in the first place?

 Because it is a common mistake, and having the warning in-place should
 help people avoid repeating it.

This is correct.

 I don't recall a policy mandating that descriptions can't end with '.'. I
 asked our QA lead about it and was told that he didn't recall that we
 have an official policy about it either. Also, the devmanual never
 mentions any such requirement.

 I don't know if and where it is documented but that's what I was taught
 when I started contributing to Gentoo, and it pretty much follows
 the common sense. DESCRIPTION is supposed to be short and descriptive.
 So you do an elliptical sentence (if I got the right translation),
 and that doesn't end with a dot.

Again, this is what I was taught as well. It may have been an
undocumented rule, but it has been around for as long as I can
remember. It also makes linguistic sense, and as an English teacher it
always irks me when I see this mistake.

 If you have any fair reason to not follow this, please speak of it.
 Otherwise, this is pure bikeshed and waste of time. This thread already
 took much more time than fixing your packages if repoman complained
 about them.

Amen!

 If someone can point me to something I'm missing, let me know.
 Otherwise, I think the warning should be removed.

 Even if there were no written-down policy, why would it be removed?
 What is the benefit of removing the check that resulted in many fixes
 already? Do you want to revert the removals afterwards? Or do you want
 to introduce new packages which use '.' there?

I completely support this argument. The warning is correct and should
remain in place.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Supporting both Qt4 and Qt5 builds

2014-08-11 Thread Ben de Groot
On 10 August 2014 18:51, Georg Rudoy 0xd34df...@gmail.com wrote:
 Hi,

 I'm thinking of converting a few ebuilds (x11-libs/qwt,
 dev-libs/kqoauth, net-libs/qxmpp among them) to support building with
 both Qt4 and Qt5.

 Should this better be done by adding the corresponding useflags (qt4
 and qt5 respectively) or by slotting?

 What's your opinion on this?


The Qt team has always recommended the useflag method for packages
that support more than one major version of Qt. This is also what we
implement ourselves. So for consistency's sake, please stick with the
useflags.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] New category lxqt-base

2014-05-12 Thread Ben de Groot
On 12 May 2014 03:28, Jauhien Piatlicki jauh...@gentoo.org wrote:
 Hi all,

 LXQt 0.7.0 has been released [1].

 As it is project different from LXDE

That is debatable. LXQt is released by the merged LXDE and Razor-Qt
upstreams. One could say there are simply two expressions of LXDE now:
one in GTK+ and one in Qt.

 and will be supported in parallel
 with it, it seems like a good idea add a new category lxqt-base.

Personally I don't see a need for this. All the Qt-specific packages
are named accordingly, and should not confuse anyone installing
anything from the lxde-base category. I would like to see that latter
category re-used for this.

But I know the maintainers of LXDE herd do not support this view, and
since at this point I don't have the time to maintain LXQt, I will
leave the decision up to you guys.

 compton-conf
 libqtxdg
 qt-gtk-engine
 libfm
 libsysstat
 obconf-qt
 pcmanfm-qt

I think these packages could be placed in the relevant x11-*
categories, as they are perfectly usable in other environments as
well, tho for ease of maintenance you could stick them with the LXQt
packages.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-09 Thread Ben de Groot
On 10 May 2014 04:34, Markos Chandras hwoar...@gentoo.org wrote:
 On 05/09/2014 09:32 PM, Tom Wijsman wrote:
 On Fri, 9 May 2014 16:15:58 -0400
 Rich Freeman ri...@gentoo.org wrote:

 I think fixing upstream is a no-brainer.

 It indeed is, this is the goal; you can force them in multiple ways,
 some of which can be found on the Lua bug and previous discussion(s).

 The controversy only exists when upstream refuses to cooperate (which
 seems to be the case when we're one of six distros patching it).  If
 there are other situations where we supply our own files please speak
 up.

 Not that I know of; the refusal to cooperate is what this is all about,
 see my last response to hwoarang before this mail for a short summary.
 Though, I think that the Lua maintainers can explain all the details...

 When the only issue is maintainer laziness I could see fixing that in
 a different way...

 It has always been an issue; we could always use more manpower, ...

 https://wiki.gentoo.org/wiki/Contributing_to_Gentoo


 Well to me it feels that gentoo specific .pc files is a similar problem
 to any other patch that affects upstream code in order to make the
 package compatible with gentoo. Some people may consider downstream pc
 files more dangerous because reverse deps are affected. But really, if
 there is no other alternative, we shouldn't be treating this as a
 special case. We patch upstream packages all the time after all

Exactly. I don't understand why this is an issue at all. Obviously,
if upstream does not ship a .pc file or ships a broken one, we try
to work with upstream to get it fixed on their end. If they are
uncooperative, we fix it on our end.

-- 
Cheers,

Ben | yngwin
Gentoo developer



[gentoo-dev] Packages up for grabs / looking for new primary maintainers

2014-04-20 Thread Ben de Groot
As my time is limited, and certain issues also drain my motivation, I
am stepping down as primary maintainer for the following packages.
They are also assigned to a herd, but since these are relatively high
maintenance they need a dedicated maintainer. (And fonts herd has been
basically inactive for the last couple of years...)

app-text/calibre
media-libs/fontconfig
media-libs/freetype
www-apps/nikola
x11-libs/cairo

I would also like to completely hand over maintenance of the following
low-maintenance packages:

app-admin/pydf
app-arch/lrzip
app-arch/xar

Feel free to remove me as maintainer for these last three packages, if
anyone is willing to take over.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Stable masks on multilib packages

2014-04-02 Thread Ben de Groot
On 1 April 2014 21:58, Alexandre Rostovtsev tetrom...@gentoo.org wrote:
 On Tue, 2014-04-01 at 13:13 +0800, Ben de Groot wrote:
 On 1 April 2014 06:16, Michał Górny mgo...@gentoo.org wrote:
  Hello, all.
 
  The late multilib ppc issues made me re-check our stable masks on
  abi_x86_* flags and, honestly, I'm not sure if we're doing things
  the right way.
 
  That said, I have an alternate idea inspired by the ppc breakage.
 
  Your thoughts?

 In my opinion your multilib approach introduces an unnecessary degree
 of complexity, which --as has been shown here again-- is prone to
 breakage.

 It would be best for our beloved distro to revert all the multilib
 changes, and try a different approach, or leave this prone-to-breakage
 implementation to an overlay for the few people who would actually
 benefit from it.

 Speaking as a wine maintainer, the emul-linux-x86-* approach has many
 times been proven to be an embarrassing failure and the main source of
 pain and frustration for wine users. The sooner emul-linux-x86-* can be
 removed from the tree, the better for Gentoo.

I would like to see an honest cost-benefit analysis of the
emul-linux-x86 approach compared to the multilib eclass approach.
Because in my experience the latter introduces more breakage and
higher maintenance costs.

 I am aware of only two solutions to the emul-linux-x86-* problems :
 multilib-portage and multilib-build.eclass. The first requires everybody
 to switch to a new package manager. The second allows us to keep using
 portage, but requires library maintainers to add some simple boilerplate
 to their ebuilds for multilib support.

 Do you have yet another alternative in mind?

In my mind the emul-linux-x86 approach is more acceptable. I don't
have experience with multilib-portage, as I don't have a use case for
it. Another option, which seems to me to be more reasonable and which
has greatly lower maintenance costs, is using a chroot.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Stable masks on multilib packages

2014-04-02 Thread Ben de Groot
On 2 April 2014 07:38, Patrick Lauer patr...@gentoo.org wrote:
 On 04/01/2014 01:13 PM, Ben de Groot wrote:
 On 1 April 2014 06:16, Michał Górny mgo...@gentoo.org wrote:
 Hello, all.

 The late multilib ppc issues made me re-check our stable masks on
 abi_x86_* flags and, honestly, I'm not sure if we're doing things
 the right way.

 That said, I have an alternate idea inspired by the ppc breakage.

 Your thoughts?

 In my opinion your multilib approach introduces an unnecessary degree
 of complexity, which --as has been shown here again-- is prone to
 breakage.

 And it removes any chance of writing ebuilds - I seriously have no idea
 how to fix those things now. They are multibuilds, not ebuilds.

This is part of the complexity I mentioned. I significantly raises
maintenance costs, and I'm not convinced of the benefit.


 It would be best for our beloved distro to revert all the multilib
 changes, and try a different approach, or leave this prone-to-breakage
 implementation to an overlay for the few people who would actually
 benefit from it.

 As a temporary stage they are kinda okish, maybe ... but ...

 the whole transition strategy has been very very silly and should have
 been staged in an overlay. I'd even build-test them and file bugs - just
 don't do this salami tactic of one breakage a day.


I'm strongly considering reverting these changes in the packages I
maintain. I'm tired of having to deal time and again with multilib
breakage.

Either that, or someone else can take over primary maintainership.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Stable masks on multilib packages

2014-03-31 Thread Ben de Groot
On 1 April 2014 06:16, Michał Górny mgo...@gentoo.org wrote:
 Hello, all.

 The late multilib ppc issues made me re-check our stable masks on
 abi_x86_* flags and, honestly, I'm not sure if we're doing things
 the right way.

 That said, I have an alternate idea inspired by the ppc breakage.

 Your thoughts?

In my opinion your multilib approach introduces an unnecessary degree
of complexity, which --as has been shown here again-- is prone to
breakage.

It would be best for our beloved distro to revert all the multilib
changes, and try a different approach, or leave this prone-to-breakage
implementation to an overlay for the few people who would actually
benefit from it.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

2014-02-18 Thread Ben de Groot
On 12 February 2014 07:04, Samuli Suominen ssuomi...@gentoo.org wrote:
[...]

 It's sad that people don't follow common sense (which happens to be the
 GNOME highlights)
 and that everything must be turned into a policy of somesort so people
 get it.

[...]

 Just make the gnome gtk3 policy the guideline if you must. It's just
 documenting common sense.


It seems that only the Gnome team regards this as common sense.
Others, such as the Qt team and QA regard the versioned useflag
solution as more sensible.

I think we can conclude that there is no perfect solution, and we
simply have different preferences.

That said, I'm not sure we absolutely need a policy. Though I would
agree it would be more elegant if we can solve this matter, to make it
easier to grasp by our users. In that case the QA proposal makes sense
to me.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Ben de Groot
On 14 November 2013 13:13, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2013-11-14, o godz. 07:49:55
 Patrick Lauer patr...@gentoo.org napisał(a):

 On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:

  It's also worth pointing out that the whole reason why abi_x86_32 is
  {package.,}use.stable.masked is because trying to manage the partial
  transisition between emul-* and multilib-build dependencies

 ^^

 Why is there a partial random transition with no roadmap, no coordination?

 https://wiki.gentoo.org/wiki/Multilib_porting_status

 That's the closest thing to a roadmap.

Closest thing, yeah. But it doesn't really solve the problem. It's
basically a one-man show, but affecting a large part of the tree,
going ahead like a steam roller that can't be stopped, never mind the
road kill.

 Well, discussing it properly would also maybe have been a good idea, but
 since this is now getting unilaterally hammered in it's mostly about
 damage limitation now ...

 And how is it possible to discuss anything properly in Gentoo?

That's because we have no proper leadership. We're an anarchistic
collection of people working at cross-purposes at the best of times.
There is no direction, and very little accountability.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Ben de Groot
On 14 November 2013 20:32, Rich Freeman ri...@gentoo.org wrote:
 On Thu, Nov 14, 2013 at 7:21 AM, Ben de Groot yng...@gentoo.org wrote:
 On 14 November 2013 13:13, Michał Górny mgo...@gentoo.org wrote:

 And how is it possible to discuss anything properly in Gentoo?

 That's because we have no proper leadership. We're an anarchistic
 collection of people working at cross-purposes at the best of times.
 There is no direction, and very little accountability.

 This seems to be an arrangement that everybody likes except when
 somebody else does something differently than they would prefer...

Seems, maybe. I for one do not like it at all, and I do bring that up
from time to time. Others agree with me to various degrees. The
problem is that it's so damn hard to change anything structurally in
Gentoo.

 We have a Council, and any issue can always be escalated there.

As it is always happy to point out, Council doesn't see itself as
leadership, just as a supreme court of appeal, when everything else
seems to have failed. It likes to get involved as little as possible.

 We
 also have Comrel, which is a better starting point for cases
 concerning individuals vs policies.

This also displays little real leadership. It concerns itself with
conflict resolution, with various degrees of success. (I still have a
bad taste in my mouth from my past dealings with that institution.)

 However, so far I haven't really seen any real indications of what the
 concern is here.  32-bit software on amd64 has always been a kludge,
 and if anything the latest multilib eclass seems to be less of a
 kludge.

I vehemently disagree. The emul-* packages may be a hack, but they
work and cover the use cases we need. The new multilib eclass approach
is much more intrusive in many packages, introduces new levels of
complexity in ebuilds, with resulting new bugs and new behaviour that
confuses users, and adding maintenance costs. It does this for very
little gain. The great majority of our users doesn't need this
functionality.

The costs are higher than the benefits, in my opinion. Where are the
use cases for this high-cost solution that is being pushed upon us?

  Apparently some argue that there is a better solution being
 worked on, and that's great to hear.  What exactly is the problem?  If
 the eclass were breaking things that weren't already broken and having
 a real impact on ordinary systems I'd consider that a concern.

If you'd care to look at the history of bugs due to multilib eclass
introduction in various packages, that's what you'd find.

 The problem with having top-down leadership in a volunteer-based
 organization is that it tends to drive away anybody who doesn't agree
 with the leader.  If a supreme leader said mgorny has the right
 solution to multilib - everybody is going to work to implement it
 that would probably cause more harm than good.  Everybody wants a
 supreme leader until the leader backs something they oppose.

But what's the alternative? Having a few dozen self-appointed leaders
doing whatever they want, and often taking things in opposing
directions. It's not top-down leadership, but rule of the strongest.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Ben de Groot
On 14 November 2013 23:12, Rich Freeman ri...@gentoo.org wrote:
 On Thu, Nov 14, 2013 at 7:57 AM, Ben de Groot yng...@gentoo.org wrote:
  I said
 As it is always happy to point out, Council doesn't see itself as
 leadership, just as a supreme court of appeal, when everything else
 seems to have failed. It likes to get involved as little as possible.

 The last time I talked to Council she said that she doesn't like it
 when you anthropomorphize her.

 Certainly I stated in my manifesto that I believe that Council members
 SHOULD be leaders, and should not limit their leadership of the distro
 to casting votes.  That's why we're chatting on a list, and I'm not
 sitting back waiting for you to put this issue on a Council agenda.

That is nice of you, but many of your fellow councilmen (historically,
as well as currently) do not hold similar views, as was made painfully
clear to me a few years ago.

 We
 also have Comrel, which is a better starting point for cases
 concerning individuals vs policies.

 This also displays little real leadership. It concerns itself with
 conflict resolution, with various degrees of success. (I still have a
 bad taste in my mouth from my past dealings with that institution.)

 Well, that is the role of Comrel.  I don't expect it to decide whether
 developers can touch each other's ebuilds to add systemd units to
 them, etc.  However, if the Council establishes a policy then Comrel
 should certainly take issue with devs that ignore that policy.  Comrel
 certainly can show leadership when it comes to how it operates,
 facilitating better relations in the community in general, etc.


 The costs are higher than the benefits, in my opinion. Where are the
 use cases for this high-cost solution that is being pushed upon us?

 Where are the costs for this high-cost solution that you purport the
 existence of?  Just what about this solution is difficult to maintain?
  I keep hearing that it is painful, but I haven't seen specific
 examples of HOW it is painful.

See how much effort is expended on this, and how many maintainers are
being involved:
https://bugs.gentoo.org/buglist.cgi?quicksearch=ALL+multilib

I was particularly hit by this as maintainer of freetype, see bugs
455070 and 459352 for some of the mess that could have been avoided.

 The problem with having top-down leadership in a volunteer-based
 organization is that it tends to drive away anybody who doesn't agree
 with the leader.  If a supreme leader said mgorny has the right
 solution to multilib - everybody is going to work to implement it
 that would probably cause more harm than good.  Everybody wants a
 supreme leader until the leader backs something they oppose.

 But what's the alternative? Having a few dozen self-appointed leaders
 doing whatever they want, and often taking things in opposing
 directions. It's not top-down leadership, but rule of the strongest.

 When you have officially-appointed leaders they usually tend to be the
 same people who would otherwise be the self-appointed leaders.  They
 just have more power to kick everybody out who disagrees with them.
 It is still the rule of the strongest.  How did Linus become the
 leader of Linux?  He wrote it...

At least there is one person in charge who sets a clear direction, and
is accountable.

 I used to get philosophical about things like this, but I think the
 model Gentoo has is actually not a bad one.

I guess we'll have to agree to disagree on this one then.

 In the end, stuff only
 gets done if people write code.  Your power in any FOSS project really
 comes down to your ability to write code or convince others to write
 code on your behalf.

No, it's more about your ability to commit and get away with it.

 We can argue about what piece of software is
 conceptually the best, but implemented software will almost always win
 over the unimplemented competitor, unless the merits of the competitor
 are such that people will flock behind it and actually implement it.

 Rich


-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Ben de Groot
On 15 November 2013 01:32, Rich Freeman ri...@gentoo.org wrote:
 On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot yng...@gentoo.org wrote:
 I was particularly hit by this as maintainer of freetype, see bugs
 455070 and 459352 for some of the mess that could have been avoided.

 Looks like 455070 was the source of problems there (the other is just
 a tracker with the aftermath).  The package had no maintainer at the
 time, only a herd (per cvs).  There was a request in the bug for
 whether it was suitable to deploy to production.  Somebody associated
 with the herd gave a thumbs-up, apparently (I can only say that based
 on your comment - I have no idea how that was communicated).  Then
 something went wrong.  Since it caused problems, it was masked.  Those
 who run ~arch should be thanked for saving the stable users from
 potential breakage!

 I'm not sure what should have been done differently.  If the package
 maintainer (in this case a herd) says that something is good to go,
 why would anybody assume that it wasn't?  You suggested testing in an
 overlay 20 days earlier, but you weren't in any particularly
 privileged position at the time (you were presumably just another
 maintainer of the herd).

I don't really want to bring up this episode again, but it is a
telling example, which you asked for.

As can be seen from the ChangeLog, I was the primary maintainer. As a
member of the herd I didn't feel it necessary to assert any kind of
privilege any other way. I had already said no, or at least wait
but that was circumvented by asking another herd member who hadn't
touched the package in years. It would have been nice were I asked for
my okay before making any changes.

And as can be seen, the mess I feared for indeed took place. This
could have been prevented, in my opinion, had this seen more extensive
testing in an overlay.

And this is exactly why I am now more weary for the next package about
to be mangled: cairo (bug 488672).

I am even tempted to undo the multilib changes to freetype, since it
is still causing trouble (just search for freetype bugs and see how
often multilib pops up).

 I'm not pointing fingers here.  This was apparently a
 miscommunication, and part of the cause was a failure to document that
 there was a primary maintainer of the package (something which was
 subsequently corrected).  Michał did offer to just maintain the status
 quo on that package instead of migrating it, and apparently he thought
 he had the all-clear to migrate it anyway.

 Michał did add the multilib project as a co-maintainer, taking
 responsibility for dealing with the multilib-related issues long-term.
  In my mind this is the sort of things projects should do.

Indeed, but more communication with the current actual maintainers of
the package in question should also be part of that.

 I'm sure there were other issues, but issues will happen when projects
 make changes.  That's just the way things roll around here.  If Michał
 just committed a change to a package without conferring with the
 maintainer at all or giving significant notice, I'd feel differently.
 I think we just need to learn and move forward, and from the looks of
 things we have.  Gentoo always has been a fairly disruptive distro,
 though it has settled down of late.  I don't think we're erring on the
 side of breaking systems too often right now, though I'm always for
 preventing that as long as it doesn't require ossification.

 (Just a note - this is all based on what I could piece together from
 cvs and bugzilla.  I'm sure those who were personally involved could
 contribute more detail. I'm not sure it is necessary that do so, but
 I'll gladly defer to those with firsthand knowledge.)

 In the end, stuff only
 gets done if people write code.  Your power in any FOSS project really
 comes down to your ability to write code or convince others to write
 code on your behalf.

 No, it's more about your ability to commit and get away with it.

 So, I'm 100% for what Donnie said and in general I tend to lean
 towards saying thanks, but no thanks when a heavy contributor is
 driving everybody nuts.  However, the reality is that those who commit
 more also tend to be allowed to get away with committing more.  That's
 just human nature - we all like our free toys and we're reluctant to
 take too much objection when we're slapped around a little by the guy
 who is giving us the free toys.  There needs to be a balance, and from
 the sound of things Markos is looking to step in and adjust the
 balance if it gets out of line.  Honestly, I just wish everybody would
 do what they can to make his job easier, and I say that without
 pointing my fingers in any direction.  I think we have a really great
 thing going here...

 Rich


Markos has shown initiative and good ideas, so I'm looking forward to
positive changes.

I am also cautiously optimistic about a renewed QA team, which could
be involved more in this kind of issues.

As I see it now

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

2013-11-08 Thread Ben de Groot
On 8 November 2013 08:55, Rémi Cardona r...@gentoo.org wrote:
 Le jeudi 07 novembre 2013 à 10:44 +0100, Alexis Ballier a écrit :
 in short: if a package requires version X then the ebuild should require
 version X; it can be forgotten but it's a bug.

 That _is_ our policy.

Since this thread was deemed necessary, apparently it's not.
Or at least not clearly stated.

 Ebuilds should - at the very least - mirror what
 upstream's build script requires.

And they do. Strictly spoken, we do not support ebuilds / versions
that are not (or no longer) in the tree. If the user chooses to use
ebuilds / versions we don't support, they are on their own.

That said, we can do it as a courtesy to users, when it is brought
to our attention. But it's more of an enhancement than a bug,
in my opinion.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

2013-11-03 Thread Ben de Groot
On 3 November 2013 17:02, Alan McKinnon alan.mckin...@gmail.com wrote:
 On 03/11/2013 01:45, yac wrote:

 Afaik there is no official way to update gentoo, is there?

 It's always been emerge -avuND world


 I personally got used to -uaNDv and I don't even know what exactly is
 the difference and it's implications between that and just -uD

 the difference is -N, it's in man emerge


We really should change this recommendation to --changed-use instead of -N.
But we also need a short option for that.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

2013-10-14 Thread Ben de Groot
On 14 October 2013 03:32, William Hubbs willi...@gentoo.org wrote:
 All,

 from what I'm seeing, we should look into converting /etc/mtab to a
 symlink to /proc/self/mounts [1].

 Are there any remaining concerns about doing this?

 If not, it seems like it would be pretty easy to make baselayout create
 this symlink in the stages (I'm willing to do this work), but what about
 on systems that are already installed? Should we send out a news item
 and have everyone convert their /etc/mtab manually or find a way to
 automate that?

 William

 [1] http://bugs.gentoo.org/show_bug.cgi?id=477498

I don't see a compelling case being made for why we should make this
change apart from all the other distros are doing it, and quite a
few reasons why we shouldn't. I'm open to being convinced, so please
tell me why this is good for Gentoo users.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: sys-kernel/tuxonice-sources up for grabs

2013-09-22 Thread Ben de Groot
On 23 September 2013 08:14, Ian Stakenvicius a...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 21/09/13 08:21 PM, Rick Zero_Chaos Farina wrote:
 On 09/21/2013 08:44 AM, Pacho Ramos wrote:
 El sáb, 21-09-2013 a las 14:42 +0200, Pacho Ramos escribió:
 I don't have time for it for a long time (since I switched to
 official suspend time ago and moved back to gentoo-sources
 then), updated patches are periodically generated and put at:
 http://tuxonice.nigelcunningham.com.au/downloads/all/?C=MO=D

 Feel free to get it if you want

 It goes with tuxonice-userui



 Is any of this really needed anymore?  I suspend/hibernate/resume
 with gentoo-sources and hardened-sources Does it really make
 sense to hold on to tuxonice still?

 -Zero


 Admittedly I haven't looked into this, but I believe tuxonice-sources
 is still required if you wish to use a hibernation file rather than a
 swap partition.  There are numerous other features to, iirc, that
 users may want that the kernel just doesn't offer.



Tux-on-ice patches are also included in pf-sources, so those who want
it can get it that way. Then we may not need to maintain separate
tuxonice-sources.


-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?

2013-08-28 Thread Ben de Groot
On 28 August 2013 16:00, Michał Górny mgo...@gentoo.org wrote:
 Hello, all.

 I think I'm finally ready to put all the breaking awesomeness that was
 waiting for the git eclasses. However, I'm wondering what's the best
 way of proceeding with it.

 We've just lately finished the git-git-2 eclass migration. The old
 eclass is no longer used and is marked for removal in a few days.
[...]
 However, I would like to do a few breaking changes to simplify
 the eclass and its maintenance:
[...]
 But it's not all removing. There are also a few things I would like to
 change/add:
[...]

 How should I proceed? Assuming that git-2.eclass is used by live
 ebuilds only, and those ebuilds can be subject to random breakage,
 I could supposedly just start changing API of the eclass.

 On the other hand, I could also go for beautiful git-r1.eclass,
 and cleanly switch the packages.

 Then, I could go for something involving the two -- create a new
 git-r1.eclass that has API fully stripped, and start deprecating
 features from git-2.eclass. We would be able to switch to git-r1 to
 test offending packages safely, then do a big switch of remaining
 packages and make the two eclasses temporarily equivalent.

 What are your thoughts?

You are planning to do more than trivial changes, so you should make a
new eclass (-version). Ebuilds rely on eclass functionality to be
stable, so please don't introduce unnecessary breakage.

This is another indication that we really need a better mechanism for
eclass versioning. But that would deserve it's own separate thread.

As for naming, I recommend you do a +1 to avoid confusion, so
git-3.eclass, or git-r3.eclass. Again, here it would be good to agree
on a convention for everyone to follow.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Moving more arches to dev profiles

2013-08-22 Thread Ben de Groot
On 22 August 2013 18:01, Rich Freeman ri...@gentoo.org wrote:
 On Thu, Aug 22, 2013 at 1:39 AM, Ben de Groot yng...@gentoo.org wrote:
 On 22 August 2013 01:19, Matt Turner matts...@gentoo.org wrote:
 On Wed, Aug 21, 2013 at 8:50 AM, Markos Chandras hwoar...@gentoo.org 
 wrote:
 Is there an alternative? afaik a profile can be either stable,dev or
 exp. I can't see how we can implement something between
 stable and dev. And what would that represent? It may or may not be
 stable? If this is the case, then I believe ~arch is more preferred.

 I haven't read much into it, but Fedora has a concept of Secondary
 Architectures. I think it would make sense if we could keep stable
 keywords for them, but not prevent maintainers from needing to wait on
 them to stabilize other packages.

 I don't see how that would work. You can't remove older versions
 unless a newer one is stabilized, or you'd break the tree.

 Sort-of.  You'd break it in that users would have to accept ~arch to
 keep that package, or remove it.  It is really no different than
 dropping stable keywords which forces them to do the same thing,
 except that you're doing it one package at a time.

 You could impose a time limit to respond to the STABLEREQ prior to
 removal (30-60 days or something).

The problem is with reverse dependencies. We had this a while ago with
Qt libraries, and I ended up needing to mask a whole list of packages
on two slacker arches. That's more trouble than it's worth for me.

In my opinion we should only bother with stabilization on the most
widely used arches: amd64, x86, and arm.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Moving more arches to dev profiles

2013-08-21 Thread Ben de Groot
On 21 August 2013 19:04, Markos Chandras hwoar...@gentoo.org wrote:
 Hi,

 It's time of year again to consider moving a few arches to dev-only status.

 I propose the following arches to lose their stable keywords

 - s390
 - sh
 - ia64
 - alpha
 - m68k
 - sparc


++

And consider adding ppc and ppc64 to that list.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Sets in the tree

2013-08-21 Thread Ben de Groot
On 21 August 2013 23:03, Sergey Popov pinkb...@gentoo.org wrote:
 15.08.2013 12:12, Pacho Ramos пишет:
 El mié, 14-08-2013 a las 15:17 +0100, Ciaran McCreesh escribió:

 Ah, looks like I was too optimistic and we are (again) with the usual
 blocking (and blocker) issues -_- (PMS refusing to include something
 because of lack of documentation :S)



 And they are right at this point. How you can include something into
 standard, that is not documented? Documentation of how to use sets(for
 users) is not enough in this case, IMHO.

 --
 Best regards, Sergey Popov
 Gentoo developer
 Gentoo Desktop-effects project lead
 Gentoo Qt project lead
 Gentoo Proxy maintainers project lead


So let's get a proper spec and documentation! Because sets can be
very useful, as I'm sure everyone will agree.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Moving more arches to dev profiles

2013-08-21 Thread Ben de Groot
On 22 August 2013 01:19, Matt Turner matts...@gentoo.org wrote:
 On Wed, Aug 21, 2013 at 8:50 AM, Markos Chandras hwoar...@gentoo.org wrote:
 Is there an alternative? afaik a profile can be either stable,dev or
 exp. I can't see how we can implement something between
 stable and dev. And what would that represent? It may or may not be
 stable? If this is the case, then I believe ~arch is more preferred.

 I haven't read much into it, but Fedora has a concept of Secondary
 Architectures. I think it would make sense if we could keep stable
 keywords for them, but not prevent maintainers from needing to wait on
 them to stabilize other packages.

I don't see how that would work. You can't remove older versions
unless a newer one is stabilized, or you'd break the tree.

One option I see is to limit the amount of packages with stable
keywords to a select list, e.g. @system and closely related packages,
and refuse stable keywords for GUI toolkits and their desktop reverse
dependencies and the like.

Ago is doing a fantastic job, but it would be good to lower his
work-load and reduce the bus factor problem.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] gtk2/gtk3 use flags

2013-08-20 Thread Ben de Groot
On 21 August 2013 07:36, Gilles Dartiguelongue e...@gentoo.org wrote:
 Le mardi 20 août 2013 à 17:31 +0400, Sergey Popov a écrit :
 16.08.2013 21:15, hasufell пишет:
  https://bugs.gentoo.org/show_bug.cgi?id=420493
 
  gtk2 and gtk3 useflags are discouraged and should only be used in
  special cases
 
  file a bug for those if there is not one already

 What's about maintainer wish to support both of toolkits? I have dropped
 GTK2 support in gtkdiskfree[1], but it seems that proxied maintainer
 will quit if i keep things that way :-/

 The upstream maintainer is free to support both toolkits if he wishes to
 do so, but we strongly recommend to only select one slot for
 applications in gentoo tree, the one which works best for the
 application.

 --
 Gilles Dartiguelongue e...@gentoo.org
 Gentoo

When upstream supports both, and the maintainer wishes to do so as
well, I would strongly recommend to support both, so that end-users
can make their own choices. Some may wish to use the applications in a
light-weight gtk2-only environment such as LXDE. As long as gtk+:2 is
supported in the tree, I don't see why we should artificially restrict
such choices for our users.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] rfc: stabilization policies

2013-08-20 Thread Ben de Groot
On 21 August 2013 04:12, Michael Orlitzky mich...@orlitzky.com wrote:
 [snip]
 Ok, this one is ridiculous. The stable version of Rails is 2.3.18, and
 3.0 was released almost exactly three years ago. Every time rails-3.x
 gets bumped, I have to manually update the entire list above. I need
 to do it on an x86 server as well, so I get to do it twice; I can't
 even copy/paste the list.

Yes you can. Just leave out the actual keyword. It will assume ~arch.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] gtk2/gtk3 use flags

2013-08-16 Thread Ben de Groot
On 17 August 2013 01:12, Michael Weber x...@gentoo.org wrote:
 Hello,

 gtk is a global use flag [1], gtk2 and gtk3 are used in metadata.xml [2].

 Is there a consensus how to use these flags if an app provides gtk2
 and gtk3 gui in parallel or exclusive?

 Michael

 [1] /usr/portage/profiles/use.desc
 gtk - Add support for x11-libs/gtk+ (The GIMP Toolkit)


 [2] egrep gtk(2|3) /usr/portage/profiles/use.local.desc
 app-admin/gtkdiskfree:gtk3 - Use GTK+3 instead of 2
 app-editors/emacs:gtk3 - Link against version 3 of the GIMP Toolkit
 instead of version 2 (x11-libs/gtk+)
 app-editors/emacs-vcs:gtk3 - Link against version 3 of the GIMP
 Toolkit instead of version 2 (x11-libs/gtk+)
 app-i18n/fcitx:gtk3 - Install GTK3 IM module
 app-i18n/fcitx-configtool:gtk3 - Use GTK+3 instead of 2
 app-i18n/ibus:gtk3 - Enable support for gtk+3
 app-i18n/ibus-anthy:deprecated - Install deprecated pygtk2 library
 app-i18n/ibus-unikey:gtk3 - Enable support for gtk+3
 app-i18n/imsettings:gtk3 - Enable support for x11-libs/gtk+:3
 app-i18n/scim:gtk3 - Enable support for x11-libs/gtk+:3
 app-i18n/uim:gtk3 - Enable support for x11-libs/gtk+:3
 app-office/libreoffice:gtk3 - Enable highly experimental gtk3 frontend
 dev-java/icedtea-web:gtk2 - Use x11-libs/gtk+:2 instead of x11-libs/gtk+:3
 dev-java/icedtea-web:gtk3 - Use x11-libs/gtk+:3 (default)
 dev-python/matplotlib:gtk3 - Use x11-libs/gtk+:3 instead of
 x11-libs/gtk+:2
 lxde-base/lxdm:gtk3 - Use GTK+3 instead of 2
 mail-client/claws-mail:gtk3 - Build support for GTK+3
 media-libs/libcanberra:gtk3 - Enables building of gtk+3 helper
 library, gtk+3 runtime sound effects and the canberra-gtk-play
 utility. To enable the gtk+3 sound effects add canberra-gtk-module to
 the colon separated list of modules in the GTK_MODULES environment
 variable.
 media-plugins/audacious-plugins:gtk3 - Link against version 3 of the
 GIMP Toolkit instead of version 2 (x11-libs/gtk+)
 media-sound/audacious:gtk3 - Link against version 3 of the GIMP
 Toolkit instead of version 2 (x11-libs/gtk+)
 media-sound/jalv:gtk2 - Adds support for GTK+2 in addition to GTK+3
 controlled by the gtk useflag.
 media-sound/mp3splt-gtk:gtk3 - Link against x11-libs/gtk+:3 instead of
 x11-libs/gtk+:2
 net-analyzer/wireshark:gtk2 - Build the wireshark executable with a
 GTK+ UI version 2.
 net-analyzer/wireshark:gtk3 - Build the wireshark executable with a
 GTK+ UI version 3.
 net-dns/avahi:gtk3 - Build the avahi-ui-gtk3 library, and use gtk3 for
 the avahi utilities under USE=utils
 net-libs/gtk-vnc:gtk3 - Build the gtk3 gtk-vnc library and other gtk3
 assets
 net-misc/spice-gtk:gtk3 - Link against x11-libs/gtk+:3 instead of
 x11-libs/gtk+:2
 net-p2p/eiskaltdcpp:gtk3 - Use x11-libs/gtk+:3 instead of x11-libs/gtk+:2
 www-client/dwb:gtk3 - Link against x11-libs/gtk+:3 instead of
 x11-libs/gtk+:2
 www-client/uget:gtk3 - Use x11-libs/gtk+:3 instead of x11-libs/gtk+:2
 www-client/uzbl:gtk3 - Use x11-libs/gtk+:3 instead of x11-libs/gtk+:2
 x11-themes/light-themes:gtk3 - Support GTK 3.x, too
 x11-wm/fvwm:gtk2-perl - Enable GTK2 Perl bindings
 --
 Michael Weber
 Gentoo Developer
 web: https://xmw.de/
 mailto: Michael Weber x...@gentoo.org


As mentioned on IRC, there's this:

https://wiki.gentoo.org/wiki/Gnome_Team_Policies#gtk3

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge

2013-08-13 Thread Ben de Groot
On 13 August 2013 13:21, heroxbd hero...@gentoo.org wrote:
 Dear Fellows,

 I would like to kick out a sub-project of Gentoo targeting smartphone
 and tablets. It would be nice to find out a solution based on Gentoo for
 desktop/smartphone hybrid *before* Canonical's release.

I would be interested in such a project.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

2013-08-09 Thread Ben de Groot
On 9 August 2013 21:57, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2013-08-09, o godz. 13:45:25
 Tom Wijsman tom...@gentoo.org napisał(a):

 On Fri, 09 Aug 2013 19:39:08 +0800
 Patrick Lauer patr...@gentoo.org wrote:

  On 08/09/2013 07:26 PM, Tom Wijsman wrote:
   On Fri, 09 Aug 2013 19:31:22 +0800
   Patrick Lauer patr...@gentoo.org wrote:
  
   You just removed the upgrade path for users.
  
   The upgrade path is to install systemd or to implement openrc
   support.
  
  Invalid upgrade path.
 
  The upgrade path is to install Fedora is about as reasonable, and
  also not acceptable.

 Your upgrade path is no longer an upgrade; the other ones are, and as
 said before, running Gentoo has no implication that OpenRC must be ran.

 I can think of at least a few examples where 'upgrade path' actually
 involved replacing one package with another and yet nobody complains
 about that.

 This one is *so special* just because we have a few folks which really
 have nothing useful to do and instead spit their systemd hatred on
 gentoo-dev@ and expect others to join their stupid vendetta.

Please keep your insults off this list. You may want to deny them, but
there are valid reasons why people oppose systemd. It doesn't help to
keep so aggressively pushing it.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

2013-08-08 Thread Ben de Groot
On 7 August 2013 20:45, Michael Weber x...@gentoo.org wrote:
 Greetings,

 Gnome Herd decided to target stablilization of 3.8 [1] which requires
 systemd.

 What are the reasons to stable 3.8 and not 3.6, a version w/o this
 restriction, enabling all non systemd users to profit from this
 eye-candy as well.

 I raise the freedom of choice card here. And deliberately choosing an
 uncooperative version doesn't shine a good light.

People are free to use a saner desktop environment...

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] renaming gentoo-oldnet

2013-08-04 Thread Ben de Groot
On 4 August 2013 10:38, Brian Dolbec dol...@gentoo.org wrote:
 On Sat, 2013-08-03 at 21:03 -0500, Doug Goldstein wrote:
 On Sat, Aug 3, 2013 at 7:30 PM, William Hubbs willi...@gentoo.org wrote:
  On Sun, Aug 04, 2013 at 01:49:46AM +0300, Alon Bar-Lev wrote:
  On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs willi...@gentoo.org wrote:

  OK... so gentoo-networking? or just come up with own name? 
  best-networking?
 

 You and I have had this talk more times than I can remember at this
 point. Using the name oldnet sucks and was one of the worst choices
 possible. Looking through our IRC chats, I had also suggested
 gentoo-networking.


 How about gen-net?  It's nice, short and the name is more flexible if
 the pkg is picked up by other distros (something bantied about during
 previous discussions).

++

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy

2013-08-04 Thread Ben de Groot
On 4 August 2013 09:56, Alex Xu alex_y...@yahoo.ca wrote:
 Minor grammar/typographical errata:

 On 04/08/13 12:53 AM, Mike Pagano wrote:
 The Gentoo Kernel Team will no longer be providing stable vanilla-sources
 kernels. All currently stabilized vanilla-sources versions will be dropped
 to ~arch. The Arch teams, via normal requests of the Kernel Team, will
 continue to stabilize gentoo-sources kernels upon request. This decision is
 based on the facts that upstream is now releasing approximately 1-2 vanilla-
 try not to wrap vanilla-sources on the hyphen if possible
 sources kernels a week. Arch teams, understandable, are unable to keep up 
 with
 s/understandable/understandably/
 this rate of release.  As most vanilla releases contain security fixes, the
 user who only runs stable vanilla-sources will consistently be behind and
 potentially at risk.  For the latest upstream non Gentoo patched vanilla
 s/non Gentoo patched/non-Gentoo-patched/ or upstream kernel unpatched
 by Gentoo
 kernel, we recommend user add 'sys-kernel/vanilla-sources' to their
 s/user add/adding/;s/their/the/ or similar; recommend user add is not
 grammatically correct

Make that: we recommend the user to add 'sys-kernel/vanilla-sources' to
their package.accept_keywords file.

(Note: their is perfectly correct usage as a gender-neutral reference to a
singular person.)

Alternatively: we recommend users to add 

 package.accept_keywords file.  Gentoo-sources will continue to be a tested 
 and
 s/Gentoo-sources/gentoo-sources/
 supported version for Gentoo users.

 s/\.  /. /g

 (or vice versa)



-- 
Cheers,

Ben | yngwin
Gentoo developer



  1   2   3   4   5   >