Re: [gentoo-dev] Asking for permission to update packages from LINGUAS to L10N
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
On 14 August 2015 at 14:02, Michał Górny wrote: > Dnia 2015-08-13, o godz. 21:17:22 > Patrick McLean 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
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
On 5 August 2015 at 03:09, Davide Pesavento wrote: > On Mon, Aug 3, 2015 at 8:59 PM, Ben de Groot wrote: >> On 4 August 2015 at 04:20, Rich Freeman 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
On 4 August 2015 at 22:56, Ian Stakenvicius 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
On 4 August 2015 at 04:20, Rich Freeman 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
On 3 August 2015 at 11:30, Rich Freeman wrote: > On Sun, Aug 2, 2015 at 11:24 PM, Ben de Groot 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
Re: [gentoo-dev] useflag policies
On 3 August 2015 at 01:33, Andrew Savchenko 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
On 3 August 2015 at 09:37, Rich Freeman wrote: > On Sun, Aug 2, 2015 at 9:03 PM, Patrick Lauer 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
[gentoo-dev] useflag policies
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
On 20 July 2015 at 17:27, Jason Zaman 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 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
On 20 July 2015 at 02:31, Mike Gilbert wrote: > On Sun, Jul 19, 2015 at 12:42 PM, Ben de Groot wrote: >> On 20 July 2015 at 00:03, Mike Gilbert 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
On 20 July 2015 at 01:01, Anthony G. Basile wrote:
> On 7/19/15 12:42 PM, Ben de Groot wrote:
>>
>> On 20 July 2015 at 00:03, Mike Gilbert 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] Re: Reverted python3.4 defaults
On 20 July 2015 at 00:03, Mike Gilbert 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] Problems updating Qt from 4.8.6 to 4.8.7
On 6 July 2015 at 03:25, Sebastian Pipping 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
On 11 April 2015 at 15:19, Ben de Groot 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
On 7 April 2015 at 15:00, Alexis Ballier wrote: > On Tue, 7 Apr 2015 07:13:16 +0800 > Ben de Groot 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
On 7 April 2015 at 06:07, Jason A. Donenfeld 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
On 6 April 2015 at 17:35, Michał Górny wrote: > Dnia 2015-04-06, o godz. 14:10:12 > Ben de Groot napisał(a): > >> On 30 March 2015 at 00:23, Michał Górny wrote: >> > Dnia 2015-03-30, o godz. 00:07:16 >> > >> > Include example code. >> > >> >> Updated version: >> >> Title: FFmpeg default >> Author: Ben de Groot >> 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 >> 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&#x
Re: [gentoo-dev] RFC News item: FFmpeg default
On 30 March 2015 at 00:23, Michał Górny wrote: > Dnia 2015-03-30, o godz. 00:07:16 > > Include example code. > Updated version: Title: FFmpeg default Author: Ben de Groot 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 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
Title: FFmpeg default Author: Ben de Groot 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
# Ben de Groot (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
On 29 March 2015 at 04:47, Ulrich Mueller 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?
On 27 March 2015 at 00:51, William Hubbs 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
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 wrote: >>> Dnia 2015-03-15, o godz. 15:11:47 Michał Górny >>> 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
On 17 March 2015 at 23:33, Michał Górny wrote: > Dnia 2015-03-15, o godz. 15:11:47 > Michał Górny 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
On 16 March 2015 at 21:54, Юра Цимбалов 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=mplayer2&list_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
On 16 March 2015 at 19:17, Alexander Berntsen 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
On 15 March 2015 at 22:43, Ulrich Mueller 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
>> 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
# Ben de Groot (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
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/base: package.use.mask
> mr_bones_15/03/09 18:15:22 > > Modified: package.use.mask > Log: > hide the qt5 stuff for yabause for now > > [...] > +# Michael Sterrett (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] Naming of repositories: gento-x86 edition, bike shedding wanted
On 15 March 2015 at 06:34, Andreas K. Huettel 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
Re: [gentoo-dev] Re: Should there be a preference with qt4 and qt5 USE flags?
On 9 March 2015 at 04:17, Johannes Huber 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
On 1 March 2015 at 23:36, Guilherme Amadio wrote: > On Sun, Mar 01, 2015 at 08:59:38PM +0800, Ben de Groot wrote: >> On 28 February 2015 at 19:52, Michael Orlitzky 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
On 28 February 2015 at 19:52, Michael Orlitzky 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
On 26 February 2015 at 22:44, Michał Górny wrote: > > > Ben de Groot 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 dev-lang/luajit instead >>of dev-lang/lua > > 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
On 28 February 2015 at 00:26, Guilherme Amadio 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. W
Re: [gentoo-dev] Re: Fonts project meeting and elections
On 27 February 2015 at 18:34, Peter Stuge 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
On 22 February 2015 at 03:43, 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. 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
[gentoo-dev] [RFC] luajit global useflag
% 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 dev-lang/luajit instead of dev-lang/lua -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] [PATCH] qmake-utils.eclass: add qt{4,5}_get_bindir helper functions
On 20 February 2015 at 04:06, Jeroen Roovers wrote: > On Wed, 18 Feb 2015 19:58:29 +0800 > Ben de Groot 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
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
On 23 February 2015 at 14:17, Vadim A. Misbakh-Soloviov 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] Fonts project meeting and elections
On 22 February 2015 at 23:27, Guilherme Amadio 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] Fonts project meeting and elections
On 22 February 2015 at 17:52, Alexis Ballier wrote: > Hi Ben, > > On Sun, 22 Feb 2015 03:43:33 +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. > [...] >> 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] Hello Everyone
On 22 February 2015 at 20:05, Tushar Rajput 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] [RFC] please review ebuilds for neovim and deps
On 23 February 2015 at 01:39, William Hubbs 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
[gentoo-dev] Fonts project meeting and elections
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
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
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
On 21 February 2015 at 16:18, Michał Górny 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 conne
[gentoo-dev] Last rites: media-fonts/culmus-ancient
# Ben de Groot (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
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
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
On 4 February 2015 at 17:26, Alexis Ballier wrote: > On Wed, 4 Feb 2015 10:12:12 +0100 > Ulrich Mueller 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
On 8 February 2015 at 18:38, Michał Górny 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
On 7 February 2015 at 23:06, hasufell 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
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On 7 February 2015 at 00:59, hasufell 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] ffmpeg vs libav choice of default
On 7 February 2015 at 07:03, Jason A. Donenfeld 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
Re: [gentoo-dev] Re: ffmpeg vs libav choice of default
On 7 February 2015 at 10:08, Mike Auty 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
On 6 February 2015 at 00:20, hasufell wrote: > Ben de Groot: >> On 4 February 2015 at 21:49, Chí-Thanh Christopher Nguyễn >> 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
On 4 February 2015 at 20:43, Mike Auty 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.16328&r2=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
On 4 February 2015 at 21:49, Chí-Thanh Christopher Nguyễn 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
On 4 February 2015 at 17:55, Michał Górny wrote: > Dnia 2015-02-04, o godz. 17:24:03 > Ben de Groot 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] ffmpeg vs libav choice of default
On 4 February 2015 at 17:21, Michał Górny wrote: > Dnia 2015-02-04, o godz. 10:12:12 > Ulrich Mueller 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] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 3 February 2015 at 00:00, Michael Orlitzky 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
On 28 December 2014 at 11:36, Robin H. Johnson 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
On 23 December 2014 at 00:11, Andreas K. Huettel 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
On 28 November 2014 at 20:20, Sergey Popov 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/*
On 8 November 2014 19:15, Jauhien Piatlicki 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/*
# Ben de Groot (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
On 27 September 2014 20:40, Ciaran McCreesh wrote: > On Sat, 27 Sep 2014 18:31:03 +0600 > Vladimir Romanov 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
On 13 August 2014 02:46, Michał Górny wrote: > Dnia 2014-08-11, o godz. 20:48:20 > William Hubbs 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
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
On 12 May 2014 03:28, Jauhien Piatlicki 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
On 10 May 2014 04:34, Markos Chandras wrote: > On 05/09/2014 09:32 PM, Tom Wijsman wrote: >> On Fri, 9 May 2014 16:15:58 -0400 >> Rich Freeman 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
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
On 2 April 2014 07:38, Patrick Lauer wrote: > On 04/01/2014 01:13 PM, Ben de Groot wrote: >> On 1 April 2014 06:16, Michał Górny 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
On 1 April 2014 21:58, Alexandre Rostovtsev wrote: > On Tue, 2014-04-01 at 13:13 +0800, Ben de Groot wrote: >> On 1 April 2014 06:16, Michał Górny 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
On 1 April 2014 06:16, Michał Górny 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)
On 12 February 2014 07:04, Samuli Suominen 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
On 15 November 2013 01:32, Rich Freeman wrote: > On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot 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 j
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 14 November 2013 23:12, Rich Freeman wrote: > On Thu, Nov 14, 2013 at 7:57 AM, Ben de Groot 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
On 14 November 2013 20:32, Rich Freeman wrote: > On Thu, Nov 14, 2013 at 7:21 AM, Ben de Groot wrote: >> On 14 November 2013 13:13, Michał Górny 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
On 14 November 2013 13:13, Michał Górny wrote:
> Dnia 2013-11-14, o godz. 07:49:55
> Patrick Lauer 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] Policy-level discussion for minimum versions on dependencies
On 8 November 2013 08:55, Rémi Cardona 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
On 3 November 2013 17:02, Alan McKinnon 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
On 14 October 2013 03:32, William Hubbs 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
On 23 September 2013 08:14, Ian Stakenvicius 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=M&O=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?
On 28 August 2013 16:00, Michał Górny 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
On 22 August 2013 18:01, Rich Freeman wrote: > On Thu, Aug 22, 2013 at 1:39 AM, Ben de Groot wrote: >> On 22 August 2013 01:19, Matt Turner wrote: >>> On Wed, Aug 21, 2013 at 8:50 AM, Markos Chandras >>> 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
On 22 August 2013 01:19, Matt Turner wrote: > On Wed, Aug 21, 2013 at 8:50 AM, Markos Chandras 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] Sets in the tree
On 21 August 2013 23:03, Sergey Popov 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
On 21 August 2013 19:04, Markos Chandras 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] rfc: stabilization policies
On 21 August 2013 04:12, Michael Orlitzky 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
On 21 August 2013 07:36, Gilles Dartiguelongue 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 > 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] gtk2/gtk3 use flags
On 17 August 2013 01:12, Michael Weber 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 > 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
On 13 August 2013 13:21, heroxbd 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
On 9 August 2013 21:57, Michał Górny wrote: > Dnia 2013-08-09, o godz. 13:45:25 > Tom Wijsman napisał(a): > >> On Fri, 09 Aug 2013 19:39:08 +0800 >> Patrick Lauer wrote: >> >> > On 08/09/2013 07:26 PM, Tom Wijsman wrote: >> > > On Fri, 09 Aug 2013 19:31:22 +0800 >> > > Patrick Lauer 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
On 7 August 2013 20:45, Michael Weber 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] newsitem: Kernel Team vanilla-sources policy
On 4 August 2013 09:56, Alex Xu 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
Re: [gentoo-dev] renaming gentoo-oldnet
On 4 August 2013 10:38, Brian Dolbec wrote: > On Sat, 2013-08-03 at 21:03 -0500, Doug Goldstein wrote: >> On Sat, Aug 3, 2013 at 7:30 PM, William Hubbs 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 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
