[gentoo-dev] Python without threads?
Upstream is talking about removing the ability to build python without threads support (non-double negative: future Python would require threads support). Is anyone here depending on building Python with -threads? Cheers, Dirkjan
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
On 05/08/2012 02:01 AM, Rich Freeman wrote: On Mon, May 7, 2012 at 7:17 PM, Walter Dnes waltd...@waltdnes.org wrote: There's a server profile which could be the answer. I've never seen that as being a terribly useful profile. Servers tend to be very minimal configurations. Maybe if we ever ripped sshd out of the default profile we might put it there, but beyond that what would you run on EVERY server? If I were to build a server I'd just stick with the default profile, and then add to it. Hi, read what Walter written till the very end ;) Problem is not what to *add* to the default profile, but rather that you have to *remove* tons of flags from it to have something compact. As he already mentioned usually USE=-* is the way to start. There were plans once among the cluster herd's members to write minimalistic profile for hpc server/node and ha cluster that would inherit from a barebone server profile. We just never got to it as demand wasn't that high. Maybe it's time to revisit the problem. Cheers, Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] add global useflag: webkit
On 05/07/2012 11:24 PM, Zac Medico wrote: On 05/07/2012 12:18 PM, Ulrich Mueller wrote: On Mon, 7 May 2012, Ciaran McCreesh wrote: I propose: REQUIRED_USE=== ( qt webkit ) But this just means that the ebuild has redundant USE flags, so one of them shouldn't be in IUSE, in the first place. It serves to convey meaning, such that a user who has disabled the qt USE flag will get a meaningful prompt if that flag is required for webkit support. This kind of information could be useful to some people, and it may be preferable to having a separate webkit-qt flag. ulm is right, it would still show up as an redudant USE flag as, the preferable result is that even KDE/Qt4 users get webkit-gtk installed if it's the rendering engine provided by the package. GTK+ is just graphical toolkit and not directly GNOME (like KDE users avoiding GNOME). By this same logic both USE=gtk qt4 are enabled in the desktop profile. I don't think we have any packages with *both* webkit-gtk and webkit-qt supports in tree (do we?).
[gentoo-dev] New category for (libre)office extensions: app-officeext
I've collected information and the extensions (should) work with any office variant, openoffice and libreoffice. To be more precise, they should work with anything that uses the so-called uno bridge. This is why I like the new category office-plugins best... and would like to implement that one. Is there any chance that there will be more than one or two office-* categories in future? If not, I think that we shouldn't introduce a new category prefix for this. The category should be named app-* instead. After some discussion with Ulrich on IRC, we settled on the name app-officeext, which we'll be able to fill with a couple of hundred (open|libre)office extensions then... :) I guess this is a compromise that we all can live with. So, I'll implement that tonight. Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
[gentoo-dev] amd64-fbsd profile marked 'stable'
Hi, I've just marked the profile 'default/bsd/fbsd/amd64/9.0' as 'stable' in profiles.desc. I've been careful not to keyword anything with broken deps, and its now forbidden. It is the first g/fbsd profile marked as such. Consequences for devs: broken deps are not allowed anymore; people are, like for standard arches, expected to drop keywords and fill a rekeywording bug. Rationale: - x86-fbsd has been a 'dev' profile for so long that the majority of the packages have broken deps, meaning moving it to a 'stable' profile is almost impossible. I do not want to repeat this error for amd64-fbsd - people usually do not run repoman -d, and as such, it is common to get (core or not) packages that are uninstallable on g/fbsd. This wont happen anymore and will make devs and users happier :=) cons: there's no stable amd64-fbsd keyword, i suppose that if we want some day to stabilize it, it'll be hard with a 'stable' profile, but we can temporarily switch it back to 'dev' while doing it, and without preventing broken deps it'll be almost impossible to do this anyway. Regards, A.
[gentoo-dev] The fate of sparc-fbsd: not supported anymore, keywords can be dropped at will.
Hi, Time has passed, nobody has been working on it in the past couple of years and I believe it is now time to make an official announce so that everyone knows: The sparc-fbsd arch is dead. People are free to drop the keywords at will. It has reached a state that it'll probably be simpler to start from scratch. The last development for this arch I can remember was when Monkeh gave me access to a sparc box where I had installed sparc-fbsd, some years ago. When the box died, we decided the pain was not worth the gain, and nothing I can remember has happened since then. Of course, this does not prevent anyone from resurrecting the port, but until further notice, people are free to drop ebuilds even if it is the last keyworded version for the sparc-fbsd arch. Regards, A.
Re: [gentoo-dev] amd64-fbsd profile marked 'stable'
On Tue, 8 May 2012, Alexis Ballier wrote: I've just marked the profile 'default/bsd/fbsd/amd64/9.0' as 'stable' in profiles.desc. I've been careful not to keyword anything with broken deps, and its now forbidden. It is the first g/fbsd profile marked as such. [...] cons: there's no stable amd64-fbsd keyword, i suppose that if we want some day to stabilize it, it'll be hard with a 'stable' profile, but we can temporarily switch it back to 'dev' while doing it, and without preventing broken deps it'll be almost impossible to do this anyway. This has as another consequence that we cannot extract the state of keywords from profiles.desc any more. So we need to find a different solution for bug 304133. Any ideas? Ulrich
Re: [gentoo-dev] amd64-fbsd profile marked 'stable'
On Tue, 8 May 2012 15:44:09 +0200 Ulrich Mueller u...@gentoo.org wrote: On Tue, 8 May 2012, Alexis Ballier wrote: I've just marked the profile 'default/bsd/fbsd/amd64/9.0' as 'stable' in profiles.desc. I've been careful not to keyword anything with broken deps, and its now forbidden. It is the first g/fbsd profile marked as such. [...] cons: there's no stable amd64-fbsd keyword, i suppose that if we want some day to stabilize it, it'll be hard with a 'stable' profile, but we can temporarily switch it back to 'dev' while doing it, and without preventing broken deps it'll be almost impossible to do this anyway. This has as another consequence that we cannot extract the state of keywords from profiles.desc any more. So we need to find a different solution for bug 304133. Any ideas? one of these maybe: 1) check if there's something starting with ~ in ACCEPT_KEYWORDS from make.default (probably slow); 2) generate that list from profile's make.default when building gentoolkit-dev 3) what are the usecases of ekeyword all ? noarch no deps packages ? in that case i dont really mind amd64-fbsd being included 4) make ekeyword all use the union of stable keywords of current package (probably saner as that wont bring in new stable keywords by mistake) 5) create a new profile state meaning 'no stable keyword but broken deps are errors' A.
Re: [gentoo-dev] New category for (libre)office extensions: office-ext?
On Sun, 6 May 2012 18:06:35 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: I've collected information and the extensions (should) work with any office variant, openoffice and libreoffice. To be more precise, they should work with anything that uses the so-called uno bridge. uno-plugins/* jer
Re: [gentoo-dev] New category for (libre)office extensions: app-officeext
Am Dienstag 08 Mai 2012, 12:30:04 schrieb Andreas K. Huettel: After some discussion with Ulrich on IRC, we settled on the name app-officeext, which we'll be able to fill with a couple of hundred (open|libre)office extensions then... :) I guess this is a compromise that we all can live with. So, I'll implement that tonight. And committed. There's already a first package in there, app-officeext/texmaths - a LaTeX replacement for the LO formula editor, generating embedded svg. Give it a try, it's really cool! -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: New category for (libre)office extensions: app-officeext
Andreas K. Huettel wrote: Am Dienstag 08 Mai 2012, 12:30:04 schrieb Andreas K. Huettel: After some discussion with Ulrich on IRC, we settled on the name app-officeext, which we'll be able to fill with a couple of hundred (open|libre)office extensions then... :) I guess this is a compromise that we all can live with. So, I'll implement that tonight. And committed. There's already a first package in there, app-officeext/texmaths - a LaTeX replacement for the LO formula editor, generating embedded svg. Give it a try, it's really cool! There's also app-office/ooextras since a long time. - Jörg
