[gentoo-dev] New project: LeechCraft
I am announcing the LeechCraft project[1], to replace the old herd in preparation for the implementation of GLEP 67. 1: https://wiki.gentoo.org/wiki/Project:LeechCraft
Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub
11 авг. 2015 г. 17:33 пользователь Michał Górny mgo...@gentoo.org написал: Hello, everyone. Now that we're officially on git and can officially use pull requests to provide rapid community interaction, it'd be convenient to have a little better framework for pinging package maintainers. With the unofficial mirror/pull request project, I was either looking for project member GitHub accounts and pinging found project members by name, or talking to them directly on IRC. However, with the growth in number of pull requests this will become more and more inconvenient. Therefore, I think it's time to be able to mirror teams willing to work with GitHub community there for easier 'pings'. I have two ideas right now: 1. creating GitHub Gentoo project teams corresponding to willing Gentoo teams, 2. preparing lists of GitHub usernames on project wiki pages. Solution 1. is cleaner. In this case, we create GitHub teams under the Gentoo projects, and add appropriate Gentoo developers having GitHub accounts to the teams. Then, in PRs we can just ping the whole team like @Gentoo/Qt or like. Solution 2. avoids adding any GitHub teams. In this case, in team wiki page we collect team member usernames like @Pesa, @kensington, ... so we could copy-paste it to pull requests. We still require extra effort when 'assigning' PRs but at least I don't have to lookup the same people over and over again. With some Wiki people help, we could even implement updating GitHub teams automatically following Wiki member changes. Your thoughts? Hi Michał! Mirroring teams on GH is a great idea. I have a question though. Is it OK that highlight links from GH emails and GH pages (like '@gentoo/qt', etc) lead to GitHub's 404 page? -- Best regards, Michał Górny http://dev.gentoo.org/~mgorny/
Re: [gentoo-dev] Re: RFC: c++14 global USE flag
2015-05-03 1:30 GMT+03:00 Kent Fredric kentfred...@gmail.com: On 3 May 2015 at 10:18, Georg Rudoy 0xd34df...@gmail.com wrote: We have idn or gnutls or python etc USE flags after all, not support_international_names_in_blah or allow_secure_news_fetching_in_foo or build_scripting_support_for_baz. Or I just didn't get you here, sorry me in this case :) The difference is semantics. idn *is* saying Support for international names ( not in, but _for_ ) and python very often *is* saying Support for python ( not in, but _for_ ) That's for, not by. For support *by* python, an explicit python use-flag is not entirely necessary. Just like you presently don't have ( and we don't have ) a USE=c flag just to make sure you have a C compiler. What does it matter to a user that its in C++14 ? It doesn't. And end user is more concerned with what does this do for me. If for instance a specific user visible tool became magically available with USE=C++14, and that was the only tool that became visible as a result, that would, for example, be really silly. If a useflag doesn't tell me what it does for me, then what impetus is there for me to toggle it? For instance, Seamonkey doesn't have a USE=perl flag. Nor should it have one. It does however have a USE=crypt flag, which utilizes perl as part of its work. ( And its only a compile time dependency also ). But you seem to want USE=perl # turn on crypt features Which is inherently backwards. There is still places where that makes a degree of sense, but in cases like give new user facing features features an ambiguous C++ toggle is not going to be communicating intent in an appropriate manner. Well, I can see your point. But I don't see any reasonable alternative --- this functionality can't be generalized by any name, except c++14 --- that's only thing in common. Moreover, this is (I hope) a _temporal_ solution, until there's a gcc with needed level of support. And of course we can put a message about this flag in eclass and/or on LeechCraft site.
Re: [gentoo-dev] Re: RFC: c++14 global USE flag
2015-04-29 14:27 GMT+03:00 Anthony G. Basile bluen...@gentoo.org: On 04/28/15 17:52, Mike Gilbert wrote: On Tue, Apr 28, 2015 at 4:07 PM, Anthony G. Basile bluen...@gentoo.org wrote: On 04/26/15 23:21, Duncan wrote: Diego Elio Pettenò posted on Sun, 26 Apr 2015 17:41:04 +0100 as excerpted: On 25 April 2015 at 16:57, Duncan 1i5t5.dun...@cox.net wrote: Of course, one thing that could make the process faster would be if C++ based packages were marked some way. revdep-rebuild --soname 'libstdc\+\+.so.*' should do the trick. Stuff that does not link the library (statically linked or using libsupc++) should not really matter. Thanks. Obvious in hindsight. =:^) just saw this. This works unless you have two versions of gcc installed. The c++11 abi emitted by gcc-4.7 and 4.8 are different and since you link against the latest version (see the ordering of directories in /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf), building with the earlier gcc can cause breakage. We may not want to support such a situation but I'd like to. As I understand it, a given version of gcc links objects against its own version of libstdc++, but the latest version of libstdc++ is loaded by ld.so at runtime. Maybe that's what you meant, but I wanted to clarify that. And if I am wrong on that, please correct me. ^_^ Yes. So you could, for example, fix this by setting the correct rpath at link time so the correct library gets loaded at runtime. I fear this discussion is going in a slightly wrong direction. I'm not going to make any global Gentoo changes, I just need to add support for C++14 mode in a bunch of packages I maintain, and for that, I need to decide on a place to store USE descriptions. If I won't get good options, I'll just go and add this description to every of ~70 metadata's. Please consider the patch I'm going to apply to our eclass: https://bpaste.net/show/39ec6f4760f4 This is intended as an experimental feature, not as a globally supported configuration for every package in Gentoo. This is needed because already now LeechCraft has some functionality that is implemented in C++14 and won't be available otherwise. Please give your opinion on where to put this USE desc, that's all I want :) -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] RFC: c++14 global USE flag
Hello. My previous email was sent from the wrong address and it seems it did not make it into the list. Sending again from the right address... I'm introducing c++14 use flag to every package in app-leechcraft catherogy via leechcraft.eclass. I need to put USE description somewhere. I propose / ask for permission to do it in global use.desc. Putting this flag to every single metadata.xml feels just wrong --- there are 72 of them now. Proposed description: Build using C++ 14 standard Looking forward for comments.
Re: [gentoo-dev] RFC: c++14 global USE flag
2015-04-24 21:56 GMT+03:00 Ian Stakenvicius a...@gentoo.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/04/15 02:42 PM, Ciaran McCreesh wrote: On Fri, 24 Apr 2015 21:12:32 +0300 Maxim Koltsov maksbo...@gentoo.org wrote: Hello. My previous email was sent from the wrong address and it seems it did not make it into the list. Sending again from the right address... I'm introducing c++14 use flag to every package in app-leechcraft catherogy via leechcraft.eclass. I need to put USE description somewhere. I propose / ask for permission to do it in global use.desc. Putting this flag to every single metadata.xml feels just wrong --- there are 72 of them now. Proposed description: Build using C++ 14 standard Looking forward for comments. This isn't going to be sustainable... What's the long-term plan for dealing with this? Sounds like we need to go through the archives and revisit the conversations about how to integrate c++11 , again.. This is temporal, until gcc gets needed support and that version makes its way into ~. Then the flag won't be needed anymore, we'll just depend on new enough gcc and enable C++14 mode by default. I'm CCing LeechCraft author just in case. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlU6kfYACgkQ2ugaI38ACPCDuQEAhAv0boCkTU3RvT5d/fX3la7V 8so0wqnPtHKI4fSqEwgA+wXmVlB14ykbTQ1VnrRR5WrEPRjMbm9V1MSXAA6MnC43 =i/3U -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] qt5-build.eclass
2014-08-17 22:38 GMT+04:00 Davide Pesavento p...@gentoo.org: Hi guys, In preparation for moving Qt5 to gentoo-x86 (finally!), please review the attached eclass that is inherited by every Qt5 ebuild. If you want to get an idea about how the ebuild code looks like, see any ebuild in the dev-qt category of our overlay that inherits the eclass: https://git.overlays.gentoo.org/gitweb/?p=proj/qt.git;a=tree;f=dev-qt;hb=HEAD or on the github mirror (easier to navigate and nicer looking): https://github.com/gentoo/qt/tree/master/dev-qt For reference, the tracker bug is https://bugs.gentoo.org/show_bug.cgi?id=qt5 I will commit the eclass in about 7-10 days from now, unless major problems are found during the review. The actual Qt5 packages will follow soon thereafter, initially under package.mask. Thanks, Pesa For the record: I /think/ that an eclass for packages supporting both qt4 and qt5 (using multibuild.eclass) /might/ be useful. Looking forward to hearing Qt team opinion.
Re: [gentoo-dev] RFC: mysql-5.5 upgrade and mysql-5.1 mask news item
2014-08-14 23:58 GMT+04:00 Brian Evans grkni...@gentoo.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Title: MySQL 5.5 upgrade procedures Author: Brian Evans grkni...@gentoo.org Content-Type: text/plain Posted: 2014-08-14 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: dev-db/mysql-5.5 MySQL 5.5 is now stable across all arches. The upgrade process will be require you to rebuild everything linked to libmysqlclient.so.16 and libmysqlclient_r.so.16. This may be done for you by portage with 'emerge @preserved-rebuild'. A small number of libraries may not be automatically rebuilt against the new MySQL libraries using preserved-rebuild. If you have difficulties with packages not finding the new libraries, install app-portage/gentoolkit and run: # revdep-rebuild --library libmysqlclient.so.16 # revdep-rebuild --library libmysqlclient_r.so.16 Random question: why isn't it covered by subslots? The official upgrade documentation is available here: http://dev.mysql.com/doc/refman/5.5/en/upgrading.html Please be sure to review the upgrade document for any possible actions necessary before and after the upgrade. This includes running mysql_upgrade after the upgrade completion. Due to security flaws, MySQL 5.1 will be hard masked in 30 days after this news item is posted. It will remain in masked the tree for 3 months before removal. I guess you meant 'remain masked in the tree' or 'remain in the tree masked'. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJT7RTxAAoJEE4V4vFnx44dC/YH/3jiU/9kSfqaLoAkLXIcegFM b2us23rUXI0+Xws9otkq0kX4Zl+a/nrDmouB8+jh6OISbUt8/sif1JEvH+PO8xID o0jJEgqslhCN5qUMtvSOMz5Dxrx2OwREM4s/EsDWV4wprW8M9auA5ZOl1Fm/HVtJ eJwDVCE/fHyN8nYgNRxau/01dKdu35kfu4Q+KOfUaq9I55w2M+xb9SVkc6UZFB7R xqh1zQhXpCzZbjZDrIkuEU23olUiTFB2e4eH9P6H9IghhFWZ+fa8NjTwCrSiwKvq UOX+dodmklmCfgATVxAsxWEKPzyRomoeqHw9BdXZ2K6Xqm+wKux0ySmjen0eN3Q= =r3DL -END PGP SIGNATURE-
Re: [gentoo-dev] We should lastrite splashutils in it's current form and not allow it in tree before it's fixed.
2014-07-21 23:29 GMT+04:00 Maxim Kammerer m...@dee.su: On Mon, Jul 21, 2014 at 9:16 PM, Ian Stakenvicius a...@gentoo.org wrote: I'm not against dropping splashutils, but is there an alternative to creating or managing framebuffer-splash in the tree? fbsplash doesn't seem to be there (tho i don't know if that's the same upstream package or not) Fbsplash is a part of splashutils. There is also an fbcondecor kernel patch, apparently maintained by someone else now. Splashutils have an extremely complex structure of daemons, control programs, and interaction with the kernel via UVESAFB — I had to revisit this structure every time I had to change something wrt. splashutils integration. Not to claim that plymouth is the solution — last time I tried it (~ 2 years ago) it was practically unusable with OpenRC. It took control of the console in some weird and buggy way, etc. I guess you could integrate it into a specific system with specific video driver, but I gave up on plymouth as a generic solution. Maybe it works well with systemd, but from what I gathered the last time, it is (or used to be) explicitly disabled on unsupported video cards by the relevant distros. Well, at the moment plymouth works fine for me with OpenRC. I've installed plymouth-openrc-plugin and it's ok, despite being old and rather unmaintained. FYI, I use plymouth with dracut initramfs generator. And I also heard from maintainer (I'm proxy maintainer of plymouth) that it works with systemd too. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Re: The request to abolish games team policy
2014-07-08 16:10 GMT+04:00 Rich Freeman ri...@gentoo.org: On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny mgo...@gentoo.org wrote: The games team believes that they're binding. In fact, I recall one of the team members remarking explicitly that they're going to alter ebuilds that were committed without their approval. In fact, they did remove ebuilds from the tree in the past for this reason [1]. [1]: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/?hideattic=0 This was 3 weeks ago, so certainly relevant. Was this removal by mutual agreement (ie the games team and maksbotan ? Rich No, I was not notified beforehand (or failed to recieve such notification, it does not matter now). This was a proxied commit, I did a usual check of the ebuild and found no problems. I admit that the ebuild was not-so-compliant to games herd rules, though. Still, immediate removal without notification and/or discussion did annoy me. BTW, I fail to see the reason of move to games-engines, but that's another issue. -- Regards, Maxim.
[gentoo-dev] ImageMagick[opencl] sandbox access violations
Hello, Currently there are four open bugs (see comment 2 in bug 490457) about imagemagick tools causing access violations while trying to open GPU. There is working solution: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-themes/tango-icon-theme/tango-icon-theme-0.8.90.ebuild?r1=1.15r2=1.16 This must be applied to all affected ebuilds, so maybe we should move this code to some eclass (eutils?) so that ebuilds can just call the function instead of copying the code? Maxim.
Re: [gentoo-dev] [RFC] New category for LeechCraft
2013/3/6 Diego Elio Pettenò flamee...@flameeyes.eu On 06/03/2013 08:07, Maxim Koltsov wrote: 1) Do you agree with adding new category? Not really... are you going to add any more packages? It's very probable, yes. Also I think 60 packages is quite big number, as we have many categories with 20 or even less packages. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] New category for LeechCraft
2013/3/6 Diego Elio Pettenò flamee...@flameeyes.eu: On 06/03/2013 15:23, Rich Freeman wrote: Can't say I'm likely to be a leechcraft user, but the original proposal indicated they were up to 60 now, and had at least 10-20 more in the works. I don't think a category is unreasonable, and if at some point in time popularity wanes and it needs treecleaning it makes the whole task that much easier... I would have said no for 61 (as I would have expected them to wane, as you said) — for 100 I'm fine, if that's happening. So, what have we decided? I'm pretty sure it'll go up to 100 quite soon. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] New category for LeechCraft
2013/3/6 Diego Elio Pettenò flamee...@flameeyes.eu: On 06/03/2013 16:12, Maxim Koltsov wrote: So, what have we decided? I'm pretty sure it'll go up to 100 quite soon. Then go for it. I'd suggest just app-leechcraft Thanks. Do i have to do anything more that add it to profiles/categories and mkdir? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ -- Regards, Maxim.
[gentoo-dev] [RFC] New category for LeechCraft
Hi, Currently there are 61 leechcraft packages in tree scattered across several categories. We propose to move them to one new category to make maintaining easy as well as rsync --exclude'ing. So, two questions: 1) Do you agree with adding new category? 2) How should we call it: app-leechcraft, leechcraft-base or anything else? Thanks, Maxim.
[gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
Hi,
During prefix bootstrap i noticed that strip-flags removes -L and -I
flags from *FLAGS while these flags are essential for prefix
bootstrapping. Therefore i propose a fix for strip-flags function to
make it preserve prefix-related flags. I have attached a patch, please
review it. It works for me, but I'm unsure how it will work with
spaces in ${EPREFIX}
Thanks,
Maxim.
flag-o-matic.patch
Description: Binary data
Re: [gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
2012/6/17 Justin j...@gentoo.org:
On 17.06.2012 14:13, Maxim Koltsov wrote:
Hi,
During prefix bootstrap i noticed that strip-flags removes -L and -I
flags from *FLAGS while these flags are essential for prefix
bootstrapping. Therefore i propose a fix for strip-flags function to
Is this really necessary? I never experienced any problems which need
this when following the guides. I looks like a hack, because something
else is borked.
I've just hit binutils on OpenBSD not finding libdl.so installed in
$EPREFIX/usr/lib/ because of this.
Don't tell me that OpenBSD prefix is unsupported, i'm working on
getting it supported.
make it preserve prefix-related flags. I have attached a patch, please
review it. It works for me, but I'm unsure how it will work with
spaces in ${EPREFIX}
Why not use use prefix instead of checking for the variable?
I didn't know about prefix use flag. I attach the fixed patch.
flag-o-matic.patch
Description: Binary data
Re: [gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
2012/6/17 Richard Yao r...@gentoo.org: On 06/17/2012 09:23 AM, Maxim Koltsov wrote: Don't tell me that OpenBSD prefix is unsupported, i'm working on getting it supported. OpenBSD is listed on the platform matrix, but it has lacked a maintainer for quite some time: http://www.gentoo.org/proj/en/gentoo-alt/prefix/ I am happy to see that you are working on this. If you have questions about prefix, feel free to ping me in IRC. :) Gentoo/OpenBSD was listed in my gentooRoles since the beginning, but i had no time for it until this summer :) Thank's for you offer, i will ping you if needed.
Re: [gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
2012/6/17 Justin j...@gentoo.org:
On 17.06.2012 15:23, Maxim Koltsov wrote:
2012/6/17 Justin j...@gentoo.org:
On 17.06.2012 14:13, Maxim Koltsov wrote:
Hi,
During prefix bootstrap i noticed that strip-flags removes -L and -I
flags from *FLAGS while these flags are essential for prefix
bootstrapping. Therefore i propose a fix for strip-flags function to
Is this really necessary? I never experienced any problems which need
this when following the guides. I looks like a hack, because something
else is borked.
I've just hit binutils on OpenBSD not finding libdl.so installed in
$EPREFIX/usr/lib/ because of this.
Don't tell me that OpenBSD prefix is unsupported, i'm working on
getting it supported.
I am still not convinced. libdl.so is provided by glibc, at least on my
linux system. And glibc is one of the rare packages which needs to be
provided by the host system instead of being installed in the prefix.
Is there something different on BSD which makes libdl.so appear inside
the prefix?
At least on OpenBSD dlopen() is not in libdl.so, but in ld.so itself,
so I have to install dummy libdl.so to ${EPREFIX}/usr/lib.
I think we should use Fabian's solution from the bug, if it does not
cause any unwanted consequences.
Re: [gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
2012/6/17 Michał Górny mgo...@gentoo.org:
On Sun, 17 Jun 2012 19:03:22 +0400
Maxim Koltsov maksbo...@gentoo.org wrote:
2012/6/17 Justin j...@gentoo.org:
On 17.06.2012 15:23, Maxim Koltsov wrote:
2012/6/17 Justin j...@gentoo.org:
On 17.06.2012 14:13, Maxim Koltsov wrote:
Hi,
During prefix bootstrap i noticed that strip-flags removes -L
and -I flags from *FLAGS while these flags are essential for
prefix bootstrapping. Therefore i propose a fix for strip-flags
function to
Is this really necessary? I never experienced any problems which
need this when following the guides. I looks like a hack, because
something else is borked.
I've just hit binutils on OpenBSD not finding libdl.so installed in
$EPREFIX/usr/lib/ because of this.
Don't tell me that OpenBSD prefix is unsupported, i'm working on
getting it supported.
I am still not convinced. libdl.so is provided by glibc, at least
on my linux system. And glibc is one of the rare packages which
needs to be provided by the host system instead of being installed
in the prefix.
Is there something different on BSD which makes libdl.so appear
inside the prefix?
At least on OpenBSD dlopen() is not in libdl.so, but in ld.so itself,
so I have to install dummy libdl.so to ${EPREFIX}/usr/lib.
I think we should use Fabian's solution from the bug, if it does not
cause any unwanted consequences.
Shouldn't configure detect that no libdl is necessary?
Should, but eclass does the bad thing anyway.
--
Best regards,
Michał Górny
[gentoo-dev] RFC: remove ldap from desktop profiles use flags
Hi, I just installed fresh system on my pc, selected 'default/linux/x86/10.0/desktop' profile and noticed ldap among default USE flags. Why is that needed? I suppose there are more users w/o ldap auth on desktops than with it. So my proposal is to remove it from profiles/targets/desktop/make.defaults. Any objections?
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
2012/5/5 Alec Warner anta...@gentoo.org: On Sat, May 5, 2012 at 5:31 PM, Maxim Koltsov maksbo...@gentoo.org wrote: Hi, I just installed fresh system on my pc, selected 'default/linux/x86/10.0/desktop' profile and noticed ldap among default USE flags. Why is that needed? I suppose there are more users w/o ldap auth on desktops than with it. So my proposal is to remove it from profiles/targets/desktop/make.defaults. Any objections? So how are you going to avoid destroying machines that rely on it being on by default? Well, i just haven't thought about that. Maybe make news item or something of this kind. But now when i see this simple removal implies such consequences, i think i can just live with it, disabling manually :) -A
Re: [gentoo-dev] RFC: Adding ParaType Free Font License to tree
25 апреля 2012 г. 9:53 пользователь Ulrich Mueller u...@gentoo.org написал: On Tue, 24 Apr 2012, Maxim Koltsov wrote: We had Paratype fonts in tree for some time (media-fonts/paratype) with OFL license. Recently they added bold font variant to PTMono font with their own license [1], but OFL font tarball was left unchanged. We tried to reach upstream with this question, but as for now no answer was got. So the question is: can Paratype FreeFont license be added to tree as /usr/portage/licenses/paratype? I don't see any reason why it couldn't. It looks like a simplified version of the OFL license, so it could even be included in @MISC-FREE in profiles/license_groups. Ulrich So, just to clairfy. I create file 'paratype' in gentoo-x86/licenses, paste there text of license and then commit? and who adds it to license_groups? [1] http://www.paratype.com/public/pt_openlicense_eng.asp -- Regards, Maxim.
Re: [gentoo-dev] RFC: Adding ParaType Free Font License to tree
25 апреля 2012 г. 15:47 пользователь Ulrich Mueller u...@gentoo.org написал: On Wed, 25 Apr 2012, Maxim Koltsov wrote: So the question is: can Paratype FreeFont license be added to tree as /usr/portage/licenses/paratype? I don't see any reason why it couldn't. It looks like a simplified version of the OFL license, so it could even be included in @MISC-FREE in profiles/license_groups. So, just to clairfy. I create file 'paratype' in gentoo-x86/licenses, paste there text of license and then commit? Right. If it exists, you should preferably take the license or copying file from the package's tarball. (Make sure that it's utf-8 encoded.) and who adds it to license_groups? Please wait for a another few days if anybody will raise objections, then you can add it yourself. Ulrich Well, they updated their OFL version of fonts, so license is not needed now :) Anyway, thanks for help.
[gentoo-dev] RFC: Adding ParaType Free Font License to tree
Hi, We had Paratype fonts in tree for some time (media-fonts/paratype) with OFL license. Recently they added bold font variant to PTMono font with their own license [1], but OFL font tarball was left unchanged. We tried to reach upstream with this question, but as for now no answer was got. So the question is: can Paratype FreeFont license be added to tree as /usr/portage/licenses/paratype? [1] http://www.paratype.com/public/pt_openlicense_eng.asp
Re: [gentoo-dev] Packages up for grabs
dev-libs/libestr slepnoga (andreis.vingrad...@gmail.com) and I take this.
Re: [gentoo-dev] [RFC] virtual/polkit-agent virtual pkg
If user is emerging some polkit-requiring package on DE-less system, it will pull big bunch of KDE, GNOME, etc. pacakges, which is not desired. Also, nm-applet and others can be set up with localauthority files, without help of polkit agents. I don't think virtual will solve this case.
Re: [gentoo-dev] [RFC] office-ext.eclass
Hi Thomas,
Why EAPI=3 is not supported?
UNOPKG_BINARY=${EPREFIX}/usr/bin/unopkg
On my machine unopkg is at '/usr/lib64/libreoffice/program/unopkg'
(libreoffice-bin), so this can be a problem.
Re: [gentoo-dev] [RFC] office-ext.eclass
2011/8/29 Tomáš Chvátal scarab...@gentoo.org:
Dne 29.8.2011 09:20, Maxim Koltsov napsal(a):
Hi Thomas,
Why EAPI=3 is not supported?
I think we should always use the latest, and this is probably only way how
to force you lads to do so. Also it saves me from having to do needless ||
die :)
You have any reason why require eapi3?
No reason, i just like backaward compability :)
UNOPKG_BINARY=${EPREFIX}/usr/bin/unopkg
On my machine unopkg is at '/usr/lib64/libreoffice/program/unopkg'
(libreoffice-bin), so this can be a problem.
Hmpf, easier to do symlinks in the binpkg than to create optional logic in
the eclass, would you mind opening bug for that? (missing unopkg in bin)
Done, https://bugs.gentoo.org/show_bug.cgi?id=381009
Re: [gentoo-dev] [RFC] office-ext.eclass
2011/8/29 Tomáš Chvátal scarab...@gentoo.org: Dne 29.8.2011 10:24, Maxim Koltsov napsal(a): No reason, i just like backaward compability :) But this is not backcompat this will be completely new and the packages that will be added never were in main tree :-) Oh yes, you're right. I just feel some kind of sadness when old things pass away :) local ext=$1 How about extensions with spaces, if there are any? einfo Remember that if you replace your office implementation, Maybe @ooo-ext-rebuild set would be useful? And you use 'libreoffice' in comments and 'openoffice' in function and variable names. Why?
Re: [gentoo-dev] Re: RFC: leechcraft.eclass
2011/8/18 Michał Górny mgo...@gentoo.org:
On Thu, 18 Aug 2011 14:38:01 +0400
Maxim Koltsov maksbo...@gentoo.org wrote:
0|1) die EAPI not supported, bug ebuild mantainer ;;
*) die Unknown EAPI, Bug eclass maintainers. ;;
I think I already mentioned that. Keep consistent case, and in this
case lowercase 'bug' is correct'.
Sorry, i lost fixed version and forgot to correct this in new one :(
# @ECLASS-VARIABLE: LC_PCAT
# @DESCRIPTION:
# Set this to the category of the plugin, if any.
: ${LC_PCAT:=}
Please use verbose variable names, and prefix them with eclass
filename; e.g. LEECHCRAFT_PLUGIN_CATEGORY.
And I think @DEFAULT_UNSET may be of interest too.
done
if-elif-else-fi.
done
And I think you dropped gentoo-dev@ from recipients a few mails ago.
Yes, added it now.
--
Regards, Maxim.
leechcraft.eclass
Description: Binary data
Re: [gentoo-dev] Re: RFC: leechcraft.eclass
2011/8/18 Michał Górny mgo...@gentoo.org:
On Thu, 18 Aug 2011 19:30:29 +0400
Maxim Koltsov maksbo...@gentoo.org wrote:
if [ ${LEECHCRAFT_PACKAGE_CATEGORY+x} != x ]; then
CMAKE_USE_DIR=${S}/src/plugins/${LEECHCRAFT_PACKAGE_CATEGORY}/${PN#leechcraft-}
elif [ ${PN} != leechcraft-core ]; then
CMAKE_USE_DIR=${S}/src/plugins/${PN#leechcraft-}
[[ ]] is better here because it's a bash builtin. And you don't need
quotes there.
What should happen if LEECHCRAFT_PACKAGE_CATEGORY is set to ''?
Fixed, i think. In this version empty variable will be handled correctly.
--
Regards, Maxim.
leechcraft.eclass
Description: Binary data
[gentoo-dev] RFC: leechcraft.eclass
Hi devs, I'm about to add Leechcraft modular internet client to tree. It has 32 packages and uses it's own eclass. Please review it and allow me to commit it to the tree. Also i'd want to ask: is it woth to add new category (e.g. leechcraft-plugins) to simplify managing leechcraft ebuilds. And the last question: is it good to add versions for all ebuilds too?
[gentoo-dev] Re: RFC: leechcraft.eclass
Sorry, forgot the eclass. Attaching it here... P.S. Email of author: 0xd34df...@gmail.com leechcraft.eclass Description: Binary data
[gentoo-dev] Voting on adding Leechcraft to the tree
Hi devs, I got a request to add Leechcraft (http://leechcraft.org/) to the portage tree. Leechcraft is modular internet client with many plugins. Main problem with it is that it has very few (less than 5, i suppose) active maintainers, and is needed by very limited amount of users (mainly friends of project lead). So, i want to use gentoo-dev ML as tool to 1) advert Leechcraft to larger audience and 2) ask Gentoo developers and users: is it worth to be in tree? If there are 5 votes for Leechcraft and no unfixable complaints from other devs, i will start adding Leechcraft to tree. Here you can see existing ebuilds and other info: http://code.google.com/p/rion-overlay/source/browse/#hg%2Fnet-misc http://code.google.com/p/rion-overlay/source/browse/eclass/leechcraft.eclass Contacts of the project lead and supposed package maintaner in gentoo (with me as proxy): d34df...@jabber.ru (XMPP).
Re: [gentoo-dev] Virtual for tftp server
2011/5/2 Mike Frysinger vap...@gentoo.org: i dont think so. i cant see RDEPENDing on a random tftp server being terribly useful here, and it certainly isnt a requirement. elog it and be done. -mike Ok, please take a look at net-misc/ris-linux. It's used for network installing windows, therefore user will need tftp, samba and friends, so i added them to RDEPEND for convinience. Do you think we must ask user to install them by hand by elog message?
[gentoo-dev] Virtual for tftp server
Hi, Assuming we have a package, that want to have any tftp server on system, no matter which one exactly, what must we set in DEPEND? I think creating virtual for tftp server would be nice. Maxim
Re: [gentoo-dev] Virtual for tftp server
I'm going to add such a package to the tree tomorrow, http://bugs.gentoo.org/show_bug.cgi?id=365605. Can you write ebuild for this virtual, because i'm not familliar with new-style virtuals yet?
Re: [gentoo-dev] Virtual for tftp server
2011/5/2 Ciaran McCreesh ciaran.mccre...@googlemail.com: If it doesn't care about what the tftp server is, presumably that means that the package itself doesn't actually use the tftp server (and if it did call the tftp server, it would need to know the syntax for each individual package, so it wouldn't be a virtual). So why would it be a DEPEND? I meant RDEPEND, sorry. Since suggested dependencies don't exist yet, what's wrong with just elogging a message suggesting the user install a tftp server of their choice? I think this is uncomfortable for user.
Re: [gentoo-dev] Unmasking boost-1.46
Are you planning to move to modular boost? I mean, separate ebuild for boost-filesystem, boost-spirit, etc. Maxim.
