Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: package.mask
On Sat, 2008-06-21 at 10:43 +0400, Peter Volkov wrote: В Чтв, 19/06/2008 в 21:03 +, Michael Sterrett (mr_bones_) пишет: mr_bones_08/06/19 21:03:29 Modified: package.mask Log: mask =games-kids/gcompris-8.4.5 until http://bugs.gentoo.org/show_bug.cgi?id=225883 is fixed up. Revision ChangesPath 1.8740 profiles/package.mask Whenever you modify anything in profiles directory, please, fill in ChangeLog. ChangeLogs became useless if only part of developers fill them. Just to remind. There are per-arch ChangeLog, base profile ChangeLog, features ChangeLog and for other stuff ChangeLog: /usr/portage/profiles/base/ChangeLog /usr/portage/profiles/arch/sh/ChangeLog [snip other archs ChangeLog] /usr/portage/profiles/default-bsd/ChangeLog /usr/portage/profiles/embedded/ChangeLog /usr/portage/profiles/default-linux/arm/ChangeLog [snip other archs ChangeLog] /usr/portage/profiles/hardened/x86/ChangeLog /usr/portage/profiles/features/ChangeLog /usr/portage/profiles/ChangeLog Thus whenever you change anything in arch profile, or in base or features subdirectory use relevant ChangeLog. For other changes like local USE flags documentation, masking/unmasking/updating masks (not comments :)) use /usr/portage/profiles/ChangeLog. Perhaps install a script which automatically takes the CVS comment when some of these files is changed and adds this comment automatically to the ChangeLog? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)
On Sat, 2008-06-21 at 09:35 +0200, Tiziano Müller wrote: Donnie Berkholz wrote: On 14:52 Thu 05 Jun , Samuli Suominen wrote: # Samuli Suominen [EMAIL PROTECTED] (05 Jun 2008) # Masked for removal in ~30 days by treecleaners. # Replaced by USE libffi in sys-devel/gcc. Bug 163724. dev-libs/libffi dev-lang/squeak x11-libs/gtk-server The latest version of g-wrap (1.9.11) requires the external libffi released a month or two ago, because it looks for the pkgconfig file installed by that and not gcc: - libffi is no longer distributed with g-wrap, as it is available as a stand-alone package now (instead of being burried in the GCC sources). Thoughts? I'd vote for an external libffi as well since python currently has to use it's bundled version of it (statically linking against it). Using libffi provided by gcc (and linking dynamically) is no option yet since portage doesn't protect the user from destroying his system by re-emerging gcc without gcj or libffi USE flags (rev-dep check and USE-based deps would be needed). Isn't it always preferable to separate packages and break them down into peaces (in this case have an external libffi) instead of having big packages with lots of stuff (in this case GCC) ? Perhaps it's more work to maintain, but I as a user would prefer an external libffi. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)
On Thu, 2008-06-05 at 14:52 +0300, Samuli Suominen wrote: # Samuli Suominen [EMAIL PROTECTED] (05 Jun 2008) # Masked for removal in ~30 days by treecleaners. # Replaced by USE libffi in sys-devel/gcc. Bug 163724. dev-libs/libffi dev-lang/squeak x11-libs/gtk-server Squeak and gtk-server maintainers still have time to rescue their ebuild, just enough time has passed for handling this (one and half year) Are you sure that Squeak really depends on libffi? I just compiled it (squeak-3.9.7) fine without having libffi on my system and with disabled libffi USE-flag. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)
On Thu, 2008-06-05 at 19:54 +0100, David Leverton wrote: On Thursday 05 June 2008 19:21:24 Albert Zeyer wrote: Are you sure that Squeak really depends on libffi? I just compiled it (squeak-3.9.7) fine without having libffi on my system and with disabled libffi USE-flag. According to my reading of the code, it doesn't use libffi on x86-linux, ppc-linux and ppc-darwin, but does on all other platforms. In any case, it should be fine with the libffi in gcc, it's just a case of the maintainer finding time to update the ebuild. Is it possible to add this also to the ebuild, e.g. to only check for libffi if it is not one of these 3 architectures? I don't want to spam my system with libs I don't need. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] FRC: debtools herd creation
On Fri, 2008-05-16 at 11:19 -0500, Yuri Vasilevski wrote: Hello All, I will be adding some debian build tools to the tree, and would like to create the debtools herd to associate with the packages. I'll be adding things like debhelper, lintian and a little bit later things like apt, aptitude, cdebootstrap, debian-live and some more. Also there is debootstrap with [EMAIL PROTECTED] which I'd like to adopt. Any comments, sugestions and objections are more than welcome. Kindest regards, Yuri. Please also add fakechroot (bug #202144). Thanks, Albert -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] dedicated USE-flag is inconsequent and confusing
On Thu, 2008-05-15 at 15:42 +0200, Benedikt Morbach wrote: I think it should be made consistent or it should be turned into a local use flag. no-* or *-only flag don't make sense in my opinion, because you can get the same with: -gui instead of nogui (maybe -gtk/-qt4/-kde or something would be even better) -* server instead of server-only (sure, this can only be done for each single package, but it looks cleaner to me than -only) Benedikt Some packages also have the X USE-flag. Though this USE-flag is often used to enable linking against X; disabling doesn't mean to remove the GUI (it's often for games or libs like libsdl which have alternative gfx output like aalib, framebuffer, etc.). There is also already a guionly and a client-only USE-flag. But I don't think this is a good USE-flag for games because it's somehow confusing then if you want to have only the dedicated server and not the GUI. I also don't like no* USE-flags that much. But there are already a lot available. I thought they were introduced because it's most probable that you want to have the specific support and if not, you have to specify this explicitly. I think the server USE-flag is a good USE-flag to enable/disable the support of a dedicated server of a specific game. This USE-flag is intuitivly clear. The GUI would not depend on the server USE-flag. For the GUI, perhaps the USE-flag client would be good. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] dedicated USE-flag is inconsequent and confusing
Hi! Jan Kundrát said this topic belongs to the mailinglist. You can find the related bug-report here: http://bugs.gentoo.org/show_bug.cgi?id=221967 Content: From the name of the USE-flag, you could expect different things: 1. It stands for 'dedicated server', which would mean, that this USE-flag does enable support for a dedicated server. (That means also that you would expect, that you have in both cases the whole GUI; and with enabled USE-flag you get additionally the dedicated server.) 2. It stands for 'dedicated only', which means, all the GUI part is skipped. (That means you would expect, that you have in both cases the whole GUI and the dedicated server; and with enabled USE-flag you get only the dedicated server but not the GUI.) From the description, it seems, that there is even a third case where you have either only the GUI or only the dedicated server (something you would not except at all). After all my experiences with USE-flag, I would expect, that a USE-flag which does not contain the name no or only does only add a specific feauture but does not remove anything. Therefore I expected the first case when I saw this USE-flag for the first time and a lot of ebuilds also use it like this. Though the second case seems still also valid for me. The third case doesn't make sense at all for me. (Is there really any ebuild with this behaviour? If so, this should be fixed.) Anyway, the behaviour of the USE-flag should be consequent. The whole sense of USE-flags is to define the behaviour of ebuilds. And normally you define the USE-flags globally for your system. If there are USE-flags which behave different on each ebuild, they don't make sense. For example, on my desktop system, I want to have the first behaviour for all ebuilds (I want to have both the game itself and the dedicated server). I have enabled the dedicated USE-flag globaly and it works good for most games I use. Though, I always need to make some exceptions for some games which is annoying and should not be. On my server, I want to have the possibility to get only the dedicated server but not the GUI. For some own ebuilds, I introduced the USE-flag 'dedicated-only' for this. To fix the problem, there should be two different USE-flags. One should do the first behaviour (something like 'dedicated' or 'dedicated-server' or 'server') and another for the second (something like 'dedicated' or 'nogui' or 'dedicated-only' or 'server-only'). The important thing is to not have a USE-flag with different behaviours. So, what do you think? Greetings, Albert -- gentoo-dev@lists.gentoo.org mailing list
