Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-10-25 23h59 UTC
On Mon, Oct 26, 2009 at 5:45 AM, Robin H. Johnson robb...@gentoo.org wrote: The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-10-25 23h59 UTC. Removals: [snip] x11-themes/gtk-engines-kde4 2009-10-19 16:48:05 ssuominen [snip] Additions: x11-themes/gtk-engines-kde4 2009-10-19 16:26:02 ssuominen This is interesting. It's certainly not a category change; and the removal is after the addition; but the directories are still around[1]. Samuli, are you in the process of re-committing it or did you miss the empty directories? 1. http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-themes/gtk-engines-kde4/ -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
Maciej Mrozowski wrote: Hi there! Resulting from discussion during last Gentoo KDE team meeting taking place 22 Oct 2009 at #gentoo-meetings (summary fill be available soon), having Gentoo GNOME team representative, it's been decided to go ahead with splitting desktop profile to DE-specific subprofiles, to avoid bloat and provide desktop specific separation which should result in desktop subprofiles being actually practical. It's been proposed to: - keep 'desktop' profile but strip it from any desktop specific features and settings, making it default recommended choice for anyone using non-KDE and non-GNOME desktop environment, yet avoiding USE flags bloat. Any other DE is free to join and create own DE-specific subprofile if needed. - create 'KDE' (or 'kde') and 'GNOME' (or 'gnome') subprofiles within 'desktop' profile and move any desktop specific things there. This should in theory allow us to not add 'recommended' IUSE defaults to desktop specific packages, but keep those settings in profile - making profile effectively 'out of the box' solution for those who need it. If you have any comments, suggestions, important notices regarding this change, please keep discussion in gentoo-desktop mailing list. Thanks As a user and someone who provides support on IRC regularly, I think extra profiles in this manner is unnecessary complexity. At a guestimate there's going to be less than 10 USE flags difference between the profiles. (New) users already find it confusing what the differences between profiles are (the number of users I've seen using a developer profile because they do some programming, for example*) and frankly I think having these extra profiles will make some users think you can only have one of kde or gnome. Why are we talking about out of the box with a distro that doesn't even come with a pre-compile kernel? Or X installed? Gentoo isn't an out of the box distro. If disabling use flags is considered too confusing for users, maybe the entire system needs to be revised. * Why is the developer profile even shown on eselect profile? Wouldn't it be better to keep unsupported profiles off this list. Surely Gentoo devs can cope with setting their profile manually in favor of a little sanity preservation for the rest of us?
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
AllenJB wrote: * Why is the developer profile even shown on eselect profile? Wouldn't it be better to keep unsupported profiles off this list. Surely Gentoo devs can cope with setting their profile manually in favor of a little sanity preservation for the rest of us? It's not only for Gentoo developers, but for /Software/ developers in general. IMHO.
Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay
On Thursday 22 October 2009 11:26:58 Thomas Sachau wrote: Mike Frysinger schrieb: On Sunday 18 October 2009 14:46:07 Thomas Sachau wrote: Mike Frysinger schrieb: how do you control whether the multilib headers are needed ? it'll probably make sense in general, but there are def some packages where this will only get in the way (the toolchain ones). What do you mean here? If the diff between ABIs makes sense to install seperate versions? some packages (like glibc and linux-headers) already handle the multilib situation. forcing the unnecessary Gentoo layer into the stack can easily break things. For glibc, it is avoided since it has the multilib useflag. If this is enabled, it indicates for me that the package does handle everything for itself, so multilib-portage does handle it as if it would be a normal package without multi-ABI request. Since linux-headers do also some special multilib handling, could you also add a multilib useflag for them? Currently i have an exception for them in my code to prevent problems for other packages. the linux-headers package doesnt have any multilib handling in them. the linux kernel itself takes care of installing proper headers for all ABIs (since they differ very little). it isnt possible to enable/disable this behavior afaik, so USE=multilib in the package makes no sense. perhaps cram all of these into a hidden USE expanded variable EABI ... but this is kind of a bad poor hack in face of creating a new dedicated variable to declare/control multilib settings. I assume that ever package not having a multilib useflag does not any multilib-specific action. To check, if the header files differ per ABI, i save them for both ABIs, then diff them and create ABI-specific header files with a wrapper for all header files, that differ. The rest is just installed as usual. that should obviously work in general how do you differentiate between packages where multi ABIs make no sense ? for example, most packages that dont install any libraries but just binaries. let's use the simple package app-text/tree. I dont differentiate. Currently i build for every ABI, if lib32 useflag is set and multilib useflag is not set. The idea behind it is to allow the installation of additional 32bit binaries, if requested. that's is an immense waste of time. if we ran all the source phases for a single ABI in one go, it should be easy to dynamically detect when a multilib multipass is necessary (by looking at library paths in $D). and for the odd package out, create a hook of some sort (EMULTIABI=true) to force behavior. i dont think there is any inherit reliance on running the multilib pass on each src step every time (other than that was easiest to implement) ? For packages with header files, i need to run all phases for both ABIs to check, if the header files are ABI specific. So it would require a check for installed libs and installed header files. And its more work since it requires both changes to the ebuild and emerge command. my point is to skip multilib phases for a package that only installs executables. i dont think you need any changes to ebuilds to support this. if you run all src steps and then check for include files/libs in the $D dir, you know at that point whether you need to re-run the src steps for all ABIs. if it's a binary package, we know the ABI of it ahead of time. so if the package declared the binary ABI that it uses, then portage could handle the rest (making sure the deps are resolved against the ABI that it requires). we dont want to rewrite every binary ebuild to include an explicit [foo] ABI flag on each of its deps. This would require additional vars for multilib handling, which would require inclusion in EAPI-3 or in a future EAPI, if the current process with EAPIs is continued. With the current implementation, i try to stay EAPI-independent, so the changes can be implemented without having to wait for aproval of another EAPI. this is an edge case that the rest of the implementation doesnt really need to rely on. in other words, we spec/prototype the right solution for this part for future EAPIs. now that i think about it more, i dont think explicit USE deps on these packages is really EAPI compliant either. for example, you cant change quake4-bin's depends from like x11-libs/libXext to x11-libs/libXext[x86] because that package doesnt have x86 in IUSE, nor does it make sense to add it. an EAPI change would be required anyways to handle funky source packages like wine where normally it's a 32bit binary, but it can be built as a 64bit binary via USE flags ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: multilib and the compatibility to singlelib
On Wednesday 21 October 2009 07:34:18 Michael Haubenwallner wrote:
Mike Frysinger wrote:
On Tuesday 20 October 2009 09:06:29 Michael Haubenwallner wrote:
As I'm building the toolchain myself too, I configure it with the
32bit host triplet on each platform, usually disabling multilib.
this doesnt make any sense to me
What exactly doesn't make sense to you:
it doesnt make sense to build your own toolchain when the default native one
Gentoo provides includes all multilib support already.
but i guess when you're commercially developing a binary-only package, people
tend to not have such freedoms as the binary-only mentality infects all
layers.
Isn't the intention of multilib to have a new (64bit) system
be compatible with the corresponding old (32bit) system?
your description of compatible is pretty vague. ignoring /lib -
/lib64 symlink (which shouldnt matter to any binaries), i'm not aware of
any differences off the top of my head.
Well, compatible here means to me that when I do
$ configure --{build,host}=i686-pc-linux-gnu
assuming you simply forgot the forcing of -m32 here, or you have a fully named
i686-pc-linux-gnu-... toolchain
on x86-linux, I'd like to expect this working on x86_64-linux too, as the
_64 can be seen as an extension[1] to x86 I just do not want to use.
It turns out that it is the /lib resolving to 64bit thing only that
causes me headaches here, which actually is distro-specific.
i'm not against changing things to fall in line with what other distros have
settled on (guess that's the risk you take when you're one of the first
distros to do multilib), i just want this kind of decision to be fully
informed / thought out before making it. it's not something i'd label
trivial.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
Samuli Suominen wrote: AllenJB wrote: * Why is the developer profile even shown on eselect profile? Wouldn't it be better to keep unsupported profiles off this list. Surely Gentoo devs can cope with setting their profile manually in favor of a little sanity preservation for the rest of us? It's not only for Gentoo developers, but for /Software/ developers in general. IMHO. General software developers should have the following features enabled? - test (all test suites) - stricter (horribly strict portage handling) - digest (ignore package digests) - cvs (not even documented in man make.conf) - sign (gpg key signing for cvs manifest commits) As well as the infamous I_KNOW_WHAT_I_AM_DOING=yes Certainly test, stricter and digest are all known to me to cause issues for anyone who doesn't understand what they do and why. AllenJB
Re: [gentoo-dev] Re: New ebuild metadata to mark how robust the package is?
This is awesome! It really like the idea, but (there is always but, right?) it doesn't work. I have googled for it for a while and haven't found any reference how to do it exactly. I have created mentioned file and run emerge, but I've got $ sudo emerge -av @critical !!! '@critical' is not a valid package atom. !!! Please check ebuild(5) for full details And I have no idea why. Also, I'm using portage 2.1.7.1. I guess this is new feature in 2.2? Regards Ladislav Laska S pozdravem Ladislav Laska --- xmpp/jabber: ladislav.la...@jabber.cz On Wed, Oct 21, 2009 at 5:30 PM, William Hubbs willi...@gentoo.org wrote: Afaik, you can already do this. Make a file in /etc/portage/sets/critical, or whatever you want to call it, and in there list the packages you are concerned about. Then you can do: emerge -NDup @critical to see the packages in that set that need to be upgraded or you can use @critical in any other place you could use a set. William On Wed, Oct 21, 2009 at 03:21:34PM +, Ladislav Laska wrote: Of course, by safe I meant unsafe or needs-additional-care or whatever,... My bad. Regards Ladislav Laska S pozdravem Ladislav Laska --- xmpp/jabber: ladislav.la...@jabber.cz On Wed, Oct 21, 2009 at 12:45 PM, Ladislav Laska ladislav.la...@gmail.com wrote: Hi, One can see some similarity to a thread around week or two old (about critical packages). I would imagine, that a simple and straightforward solution would be to make a new set of packages. Since we already have world and system sets, it wouldn't hurt to have a third, safe list which would be configurable by user. What I mean is: I consider ssh, postfix two very important packages (ssh is pretty stable, but hey, what if...) and I would most certainly not want to trigger emerge world and not notice postfix. So: I would add ssh and postfix to the safe set and do emerge -avu @safe, have a coffee and looked whether it's ok (mail are flowing, can login, etc. etc.) and then do emerge -avuD world and sleep well. I think this would be good solution for all of you? Regards Ladislav Laska S pozdravem Ladislav Laska --- xmpp/jabber: ladislav.la...@jabber.cz On Sun, Oct 18, 2009 at 2:10 AM, Duncan 1i5t5.dun...@cox.net wrote: Patrick Lauer posted on Sat, 17 Oct 2009 09:53:39 +0200 as excerpted: On Saturday 17 October 2009 01:29:00 Daniel Bradshaw wrote: Some packages, like findutils, are pretty robust and generally just get on with working. Other packages, like apache and ssh, need are more fragile and need plenty of configuration. That's almost completely user-side configuration outside the influence of portage. emerge findutils and emerge apache works the same ... Packages from the second group want emerging on their own, or in small groups, the better to keep an eye out for notices about things that might break, to update configs, and to check that they're running happily. That's a very individual thing :) Sometimes apache is a critical service, sometimes apache is just there as a fallback if/when the lighttpd+php+... stack breaks. FWIW, there's a portage helper package, IDR the name as I have my own system for this but it looks like it might be helpful here, that allows users to pick and choose their updates. ??One could run it multiple times, updating (what the user considers) the critical stuff on its own, and updating everything else in a big bunch. That seems like the answer here; it already exists; and it's in the tree (unless it has been removed recently, I don't know as IDR the name). Take a look thru app-portage and see what you find. -- Duncan - List replies preferred. ?? No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. ??Richard Stallman -- William Hubbs gentoo accessibility team lead willi...@gentoo.org
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Saturday 24 October 2009, Maciej Mrozowski wrote: Resulting from discussion during last Gentoo KDE team meeting taking place 22 Oct 2009 at #gentoo-meetings (summary fill be available soon), having Gentoo GNOME team representative, it's been decided to go ahead with splitting desktop profile to DE-specific subprofiles, to avoid bloat and provide desktop specific separation which should result in desktop subprofiles being actually practical. (From your email) I fail to see the advantage as other commenters have pointed out. What problem is there that cannot be solved using dependencies and kde/gnome use flags? This decision just seems to increase the split between KDE and Gnome and that does not reflect user's realities: They use both. Gnome desktop + kmail, k3b, yakuake or KDE with evince, etc. Why add one more decision to make where the result is unclear (and honestly, profile documentation is almost zero)? Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Mon, 26 Oct 2009 13:11:38 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: AllenJB wrote: * Why is the developer profile even shown on eselect profile? Wouldn't it be better to keep unsupported profiles off this list. Surely Gentoo devs can cope with setting their profile manually in favor of a little sanity preservation for the rest of us? It's not only for Gentoo developers, but for /Software/ developers in general. IMHO. Uhh . . . no, it's not. A long time ago I talked with the folks who created the profile, and that's why I put the following into our profile documentation. This is seen in all handbooks: note The cdeveloper/c subprofile is specifically for Gentoo Linux development tasks. It is enot/e meant to help set up general development environments. /note . . . so no, it's not for general software development; it's to help out the hundreds of developers and users who are performing Gentoo development activities. Developing Gentoo is not like writing some random piece of software. This profile is for our special requirements, nothing else. signature.asc Description: PGP signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-10-25 23h59 UTC
Nirbheek Chauhan wrote: On Mon, Oct 26, 2009 at 5:45 AM, Robin H. Johnson robb...@gentoo.org wrote: The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-10-25 23h59 UTC. Removals: [snip] x11-themes/gtk-engines-kde4 2009-10-19 16:48:05 ssuominen [snip] Additions: x11-themes/gtk-engines-kde4 2009-10-19 16:26:02 ssuominen This is interesting. It's certainly not a category change; and the removal is after the addition; but the directories are still around[1]. Samuli, are you in the process of re-committing it or did you miss the empty directories? 1. http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-themes/gtk-engines-kde4/ It was a very bad decision to add this package so I've removed it like few mins after adding. ssuomi...@unique ~/gentoo-x86/x11-themes $ cvs up ssuomi...@unique ~/gentoo-x86/x11-themes $ ls -l *kde4* ls: cannot access *kde4*: No such file or directory ssuomi...@unique ~/gentoo-x86/x11-themes $ As shown above, there's no empty directory here.
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
Having recently installed gentoo, I can see hwo it could get confusing with DE specific profiles. Especially as a number of users that are new to linux might very well have no idea what DE they're going to use. And the same can be said for users who decided to run ubuntu to try linux and then decide to go further. having to choose a profile, gives less time for the wavering user, if you ask me. Particularly because a number might well believe that having a DE specific profile would restrict them to use such profiles. Instead I'd say it's a better idea to give a suggestion of useflags in the handbook for the different choices of DE's. And also I don't thin it's relevant to talk about gentoo in relation to an out-of-box experience. To me it seems to be counterproductive, being that by creating an out-of-box experience would, intially at least, make choices on the users behalf, which is against gentoo's philosophy as I understand it. The way I understand Gentoo, is it is a distro to allow freedom of choice, whether it being a choice of having a graphical interface or a choice of which graphical interface. And to aim for an out-of-box experience, is counteracting that freedom, or rather, only allowing a choice of removing it after the decision has already been made for you. I don't think the developer profile should be removed however. There could very well be users installing gentoo, with the purpose of getting involved with developing gentoo. So the profile should be there, and it is well enough documented as being geared towards developing gentoo, and not developing in general. (New) users already find it confusing what the differences between profiles are (the number of users I've seen using a developer profile because they do some programming, for example*) and frankly I think having these extra profiles will make some users think you can only have one of kde or gnome. Why are we talking about out of the box with a distro that doesn't even come with a pre-compile kernel? Or X installed? Gentoo isn't an out of the box distro. If disabling use flags is considered too confusing for users, maybe the entire system needs to be revised. * Why is the developer profile even shown on eselect profile? Wouldn't it be better to keep unsupported profiles off this list. Surely Gentoo devs can cope with setting their profile manually in favor of a little sanity preservation for the rest of us?
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Mon, Oct 26, 2009 at 21:42, Zeerak Waseem zeera...@gmail.com wrote: having to choose a profile, gives less time for the wavering user Why all the fuss? No-one said we're removing the plain desktop profile, we're simply adding *more* options. If you want generic DE options pre-enabled, choose the desktop profile. If you *know* you only need KDE as your DE, choose KDE, If you *know* you only need GNOME as your DE, choose GNOME, If you need both or can't decide, either choose Desktop and add the USE flags yourself or use both profiles together. Beats enabling default USE flags without asking you :) -- Alex || wired Gentoo Dev www.linuxized.com
Re: [gentoo-dev] Lastrite: KDE3 applications with bugs and KDE4 replacements.
Am Sonntag 25 Oktober 2009 schrieb Samuli Suominen: # Samuli Suominen ssuomi...@gentoo.org (25 Oct 2009) # Replaced by: # # =media-gfx/digikam-0.10 # kde-base/gwenview # =media-gfx/kphotoalbum-4 # =media-plugins/kipi-plugins-0.6 # # Masked for removal in 30 days. media-libs/libkdcraw =media-gfx/digikam-0.9* =media-gfx/kphotoalbum-3* media-gfx/gwenview =media-plugins/kipi-plugins-0.1* media-libs/libkipi media-libs/libkexiv2 gwenview from kde4 is no replacement for the single app gwenview. It's a completely different (I assume 99% rewritten) app and they don't have much in common beside that both are for image viewing. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:ha...@hboeck.de http://schokokeks.org - professional webhosting signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] make install without die (gentoo-x86 commit in app-arch/hardlink, app-arch/duff )
On 2009-10-23 09:28, Torsten Veller wrote: An imprecise search (/make .*install$/) revealed another 200 packages: http://dev.gentoo.org/~tove/files/makeinstallwithoutdie.txt Fixed app-admin/tenshi. -- Heath Caldwell - hncaldw...@gentoo.org pgpClKv2i8vwN.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
Le 24/10/2009 15:42, Maciej Mrozowski a écrit : If you have any comments, suggestions, important notices regarding this change, please keep discussion in gentoo-desktop mailing list. IMHO, we shouldn't even have desktop/server subprofiles to begin with. I've always considered Gentoo to be an opt-in distro where after a successful install, you end up with a bash prompt and a _means_ of installing new packages. Finding out what USE flags mean and do is part of the Gentoo experience. If we were doing spin-off distros like Ubuntu and Fedora do, then subprofiles would be fine, but we're not. So with my X hat on, I won't be adding any X subprofile. And with my (former?) Gnome hat on, I vote against any gnome subprofile. Cheers, Rémi
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
Alex Alexander wrote: On Mon, Oct 26, 2009 at 21:42, Zeerak Waseem zeera...@gmail.com wrote: having to choose a profile, gives less time for the wavering user Why all the fuss? No-one said we're removing the plain desktop profile, we're simply adding *more* options. If you want generic DE options pre-enabled, choose the desktop profile. If you *know* you only need KDE as your DE, choose KDE, If you *know* you only need GNOME as your DE, choose GNOME, If you need both or can't decide, either choose Desktop and add the USE flags yourself or use both profiles together. Beats enabling default USE flags without asking you :) +1. This is adding options not taking away. I like this idea since you can still do it the old way with no problems at all. Plus this will make my USE line shorter. It has to help a little at least. Dale :-) :-)
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Monday 26 of October 2009 21:06:04 Rémi Cardona wrote: IMHO, we shouldn't even have desktop/server subprofiles to begin with. I've always considered Gentoo to be an opt-in distro where after a successful install, you end up with a bash prompt and a _means_ of installing new packages. Finding out what USE flags mean and do is part of the Gentoo experience. If we were doing spin-off distros like Ubuntu and Fedora do, then subprofiles would be fine, but we're not. So with my X hat on, I won't be adding any X subprofile. And with my (former?) Gnome hat on, I vote against any gnome subprofile. I most cases I agree with you. To be more specific - desktop profile should be annihilated because it's a joke. It's impractical and bloated. Splitting it to kde and gnome is just nicer way of annihilating it. However, considering amount of confused users on IRC and forums, especially after KDE4 stabilization and Qt4 default USE flags change, and considering no automatic USE flags management provided by portage (for example via -- interactive mode) - there's no way to make it easier to use. Making something easier to use does not necessarily need to mean less flexible. It we're to provide mostly learning experience and not practical solutions, why not rename Gentoo to Eduentoo :) And I fail to see *any* point in forcing users to learn Gentoo internals (sic! like USE flags). What else? Ebuild syntax so that they're able to get to know what particular global USE flag is responsible for, when someone forgot (or decided not to) describe it in metadata.xml even when semantics is different? Maybe I sound too harsh here, but that's because I'm not ideologist - I'm practical man. -- regards MM signature.asc Description: This is a digitally signed message part.
[gentoo-dev] qemu/kvm image with prepared multilib setup for testing
Hi, for those, who are lazy or not able to setup a system with multilib-portage, i created a qemu/kvm image, which is basicly a default amd64 autobuild tarball with added multilib-portage and default enabled 32bit libs for almost all packages. You can find the image at your local mirror in the experimental/amd64/qemu dir. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
Maciej Mrozowski reave...@gmail.com writes:
And I fail to see *any* point in forcing users to learn Gentoo internals
(sic!
like USE flags). What else? Ebuild syntax so that they're able to get to know
what particular global USE flag is responsible for, when someone forgot (or
decided not to) describe it in metadata.xml even when semantics is different?
Maybe I sound too harsh here, but that's because I'm not ideologist - I'm
practical man.
If the point of the distribution is – like some other distros – to have
a high-functioning, high-polish, well-integrated system and desktop with
a minimal amount of end-user knowledge, then, yes, the goal should be
for end-users to not need to know about such things.
But profiles, make.conf, USE flags (especially!), elog, c. … these
things are not internals, but instead the interface the package
manager presents to its user. They are the language the user is
expected to speak in to interact with her system. The trade off for
doing this is more and finer-grained control over the system, and the
reason people choose Gentoo. Even ebuilds themselves are (usually)
sufficiently non-magical that I think they could qualify in some
circumstances, though that quickly starts to get into eclasses, PM
behavior and real internals.
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}
pgpiBiYJOz5SX.pgp
Description: PGP signature
[gentoo-dev] Re: [RFC] Splitting desktop profile to KDE and GNOME
Maciej Mrozowski posted on Mon, 26 Oct 2009 21:40:17 +0100 as excerpted: And I fail to see *any* point in forcing users to learn Gentoo internals (sic! like USE flags). What else? Ebuild syntax so that they're able to get to know what particular global USE flag is responsible for, when someone forgot (or decided not to) describe it in metadata.xml even when semantics is different? Maybe I sound too harsh here, but that's because I'm not ideologist - I'm practical man. Actually, yes. Gentoo has never been a hand-holding distribution. We try to provide documentation and reasonable defaults for any apps the user chooses to install, and let the user configure what they will. For some time I've wondered about all those profiles. IMO, for pure/ normal USE flag issues, we don't need profiles. Profiles are for things such as setting the arch, masking stuff that won't run on that arch, doing the necessary to make multilib work as appropriate, setting up a basic system set of packages, etc. After that, it's upto[1] the user. USE flags are documented in the handbook, and a major defining part of what makes Gentoo, Gentoo. If they can't even manage to learn USE flag basics, honestly, they'd be better off with a different distribution, probably something that does a bit more hand-holding, like Ubuntu, because they're going thru a whole lot of additional hassle compiling stuff, etc, for very little payoff in practical terms, because they simply aren't using Gentoo as it was designed to be used. So IMO, few if any USE flags should be set in the profiles. That is, or should be, upto the user to decide. In general, if a USE flag is not set in a user's make.conf, it shouldn't be on, with few exceptions definitely not at the system level, and with some exceptions, not at the individual ebuild/pkg level either. --- [1] Upto: Yeah, I know, but Wictionary already defines it as a common misspelling, so make it even more common and eventually it'll no longer be a misspelling but considered normal and correct usage, just as into is no longer a misspelling but normal and correct usage. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] gdata-build eclass proposal
On Mon, Oct 26, 2009 at 12:06:09AM -0400, Kyle Cavin wrote: snip # @ECLASS: gdata-build.eclass # @BLURB: Eclass for gdata API ebuilds. # @DESCRIPTION: # This eclass contains various functions that are used when building gdata APIs. EAPI=2 EAPI can be tested for in eclasses, but eclasses should not set it. --- William Hubbs gentoo accessibility team lead willi...@gentoo.org pgp7l3t128Hwk.pgp Description: PGP signature
[gentoo-dev] Re: New ebuild metadata to mark how robust the package is?
Ladislav Laska posted on Mon, 26 Oct 2009 13:55:51 +0100 as excerpted: I have created mentioned file and run emerge, but I've got $ sudo emerge -av @critical !!! '@critical' is not a valid package atom. !!! Please check ebuild(5) for full details And I have no idea why. Also, I'm using portage 2.1.7.1. I guess this is new feature in 2.2? Yes. Sets were left for 2.2, as the implementation wasn't quite ready for 2.1 stability. (As I understand it, there's multiple set implementations, and before sets become available as in-tree kde install options, for instance, they needed some reconciliation and possible PMS/ EAPI approval.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: [RFC] Splitting desktop profile to KDE and GNOME
Duncan wrote: Actually, yes. Gentoo has never been a hand-holding distribution. We try to provide documentation and reasonable defaults for any apps the user chooses to install, and let the user configure what they will. Gentoo is about choice. Well, except for the choice to not have to choose... I don't see why having some nice polished sets of use flags is a bad thing. Personally, I find it a pain when I've emerged half of my system only to find out I left out some critical use flag (my use flags take up several lines now). Sure, leave users a choice, but there is no harm in giving them some pointers. Gentoo should be fully usable in a USE= state, but that doesn't mean that we need to make users start out from this point.
Re: [gentoo-dev] Re: [RFC] Splitting desktop profile to KDE and GNOME
Le 26/10/2009 22:58, Richard Freeman a écrit : Gentoo is about choice. No it isn't. Gentoo is about empowering users, giving them the ability and tools to _change_ the distro to _their_ needs. Gentoo does _not_ cater to all the possible needs. This is somewhat off-topic, but it irks me every time I see/hear it, so there. Cheers, Rémi
Re: [gentoo-dev] Re: [RFC] Splitting desktop profile to KDE and GNOME
When it all comes down, I just fail to see how the handbook doesn't provide the pointers. I've always been about getting my system up and running, and then learn whatever needs learning, this means that whilst I didn't have more than a basic knowledge and understanding of useflags when installing, that knowledge has grown due to necessity of using gentoo to it's full potential. I think setting up useflags should be left to the user. A system can be recompiled should the need arise. The reason I chose gentoo as my distribution was that, it seemed to me that it gives you a basic knowledge of the system and then encourages to gain and apply further knowledge according to need. But again, the handbook gives all the necessary pointers, albeit there can occur conflicts that are outside of the range of the handbook, but that's why the forums and the irc channels are there :-) On Mon, 26 Oct 2009 22:58:57 +0100, Richard Freeman ri...@gentoo.org wrote: I don't see why having some nice polished sets of use flags is a bad thing. Personally, I find it a pain when I've emerged half of my system only to find out I left out some critical use flag (my use flags take up several lines now). Sure, leave users a choice, but there is no harm in giving them some pointers. Gentoo should be fully usable in a USE= state, but that doesn't mean that we need to make users start out from this point. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Monday 26 October 2009 21:06:04 Rémi Cardona wrote: Le 24/10/2009 15:42, Maciej Mrozowski a écrit : If you have any comments, suggestions, important notices regarding this change, please keep discussion in gentoo-desktop mailing list. IMHO, we shouldn't even have desktop/server subprofiles to begin with. I've always considered Gentoo to be an opt-in distro where after a successful install, you end up with a bash prompt and a _means_ of installing new packages. Finding out what USE flags mean and do is part of the Gentoo experience. If we were doing spin-off distros like Ubuntu and Fedora do, then subprofiles would be fine, but we're not. So hmm, let me make few hypothetical statements. You see package foo-libs/baz has USE=pic that is not set by default in profile. It's well documented in metadata.xml which says disable optimized assembly code that is not PIC friendly. So as an ordinary user you set it in your make.conf because it may be helpful. Then you want to install another package with USE=pic but you note this useflag for this package means Force shared libraries to be built as PIC (this is slower). Of course you don't want your programs run slower, do you? So you disable useflag in make.conf or package.use. This situation may lead user to reinstall half of his system, because some packages with USE=- pic force foo-libs/baz[-pic] and foo-libs/bar[-pic] too. You end up with nothing after some time spent on reading metadata.xml, recompilling foo, bar, baz... just because you were forced to have a choice. IMO profiles are very good solution for every user. Especially for those that don't know what every use flag means and they (profiles) should have at least base useflags set. And if base, why not most of useful? They are only option. User can alwasy disable it (eg. -kde if he wants gnome, -gnome if he wants kde or - both if he uses openbox). My $0,02. -- Cheers Dawid Węgliński
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
But instead of just giving the user the answer, wouldn't it be more appropriate, as far as understanding useflags and their uses goes, to give users lists of useflags and what they do. Ie a list of base use flags for say, kde, and also what basic useflags to disable, and a suggestion to read the descriptions of the useflags to add what's necessary. As the handbook currently does. I think with the documentation, one should have enough information to assess what useflags are desired for one's system. And then I'd suggest looking at the packages and the need for various use flags individually, if you want to. But the documentation provides basic useflags for running your system. But again, this is just my take on it :-) On Tue, 27 Oct 2009 01:08:30 +0100, Dawid Węgliński c...@gentoo.org wrote: On Monday 26 October 2009 21:06:04 Rémi Cardona wrote: Le 24/10/2009 15:42, Maciej Mrozowski a écrit : If you have any comments, suggestions, important notices regarding this change, please keep discussion in gentoo-desktop mailing list. IMHO, we shouldn't even have desktop/server subprofiles to begin with. I've always considered Gentoo to be an opt-in distro where after a successful install, you end up with a bash prompt and a _means_ of installing new packages. Finding out what USE flags mean and do is part of the Gentoo experience. If we were doing spin-off distros like Ubuntu and Fedora do, then subprofiles would be fine, but we're not. So hmm, let me make few hypothetical statements. You see package foo-libs/baz has USE=pic that is not set by default in profile. It's well documented in metadata.xml which says disable optimized assembly code that is not PIC friendly. So as an ordinary user you set it in your make.conf because it may be helpful. Then you want to install another package with USE=pic but you note this useflag for this package means Force shared libraries to be built as PIC (this is slower). Of course you don't want your programs run slower, do you? So you disable useflag in make.conf or package.use. This situation may lead user to reinstall half of his system, because some packages with USE=- pic force foo-libs/baz[-pic] and foo-libs/bar[-pic] too. You end up with nothing after some time spent on reading metadata.xml, recompilling foo, bar, baz... just because you were forced to have a choice. IMO profiles are very good solution for every user. Especially for those that don't know what every use flag means and they (profiles) should have at least base useflags set. And if base, why not most of useful? They are only option. User can alwasy disable it (eg. -kde if he wants gnome, -gnome if he wants kde or - both if he uses openbox). My $0,02.
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Mon, 26 Oct 2009 21:52:04 +0200, Alex Alexander wi...@gentoo.org wrote: On Mon, Oct 26, 2009 at 21:42, Zeerak Waseem zeera...@gmail.com wrote: having to choose a profile, gives less time for the wavering user Why all the fuss? No-one said we're removing the plain desktop profile, we're simply adding *more* options. If you want generic DE options pre-enabled, choose the desktop profile. If you *know* you only need KDE as your DE, choose KDE, If you *know* you only need GNOME as your DE, choose GNOME, If you need both or can't decide, either choose Desktop and add the USE flags yourself or use both profiles together. Beats enabling default USE flags without asking you :) My personal definition of bloat: to add complexity for no real gain on features. Adding a profile just because it's a cool way to do the same thing that *one* single USE flag can do is a nonsense *to me*. I am already hearing all the new (and old) users asking what the damn difference between the flag and the profile is. It's a cool way to create extra traffic and confusion for absolutely no benefit. But hey, maybe it's just that my old brain can't cope with the coolness :) -- Jesús Guerrero
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Tuesday 27 October 2009 00:26:38 Zeerak Waseem wrote:
But instead of just giving the user the answer, wouldn't it be more
appropriate, as far as understanding useflags and their uses goes, to give
users lists of useflags and what they do. Ie a list of base use flags for
say, kde, and also what basic useflags to disable, and a suggestion to
read the descriptions of the useflags to add what's necessary. As the
handbook currently does. I think with the documentation, one should have
enough information to assess what useflags are desired for one's system.
And then I'd suggest looking at the packages and the need for various use
flags individually, if you want to. But the documentation provides basic
useflags for running your system.
But again, this is just my take on it :-)
No. Handbook doesn't provide information on every useflag. For this you have
use{.local.,.}desc in PORTDIR/profiles/. And again, if you missread my previous
post - there's no way to standarize *every* useflag and tell user flag foo
does
bar. It's developer who should decide on behalf of user what's the best
configuration. And user has always choice to disable some useflags and create
his own configuration for his requirements.
--
Cheers
Dawid Węgliński
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Tuesday 27 October 2009 01:34:55 Dawid Węgliński wrote:
On Tuesday 27 October 2009 00:26:38 Zeerak Waseem wrote:
But instead of just giving the user the answer, wouldn't it be more
appropriate, as far as understanding useflags and their uses goes, to
give users lists of useflags and what they do. Ie a list of base use
flags for say, kde, and also what basic useflags to disable, and a
suggestion to read the descriptions of the useflags to add what's
necessary. As the handbook currently does. I think with the
documentation, one should have enough information to assess what useflags
are desired for one's system. And then I'd suggest looking at the
packages and the need for various use flags individually, if you want to.
But the documentation provides basic useflags for running your system.
But again, this is just my take on it :-)
No. Handbook doesn't provide information on every useflag. For this you
have use{.local.,.}desc in PORTDIR/profiles/. And again, if you missread
my previous post - there's no way to standarize *every* useflag and tell
user flag foo does bar. It's developer who should decide on behalf of
user what's the best configuration. And user has always choice to disable
some useflags and create his own configuration for his requirements.
s...@best configurat...@best minimal configuration@
--
Cheers
Dawid Węgliński
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Sunday 25 October 2009 03:41:10 Jesús Guerrero wrote: I fail to see how this is simpler and/or more versatile than simply using USE=kde gnome, USE=-kde gnome, USE=-gnome kde or USE=-gnome -kde. What exactly are we going to gain by adding yet another level of complexity where two simple USE flags suffice? you've missed some like USE=eds. i hate that damn thing, but it really only makes sense in a GNOME environment. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-dev-announce] Unused ebuild built_with_use cleanup
Petteri == Petteri Räty betelge...@gentoo.org writes: Petteri Their maintainers should be active and switch their ebuilds to Petteri EAPI 2. If they don't have an active maintainer, then do we Petteri want to keep live ebuilds for them around? What possible benefit could be had from dropping ebuilds for no other reason than their EAPI? (Incidently, since I mentioned it as the one I remembered from the first post, I see that git- is EAPI 2 even though it does use built_with_use.) Any mass removal should be as conservative as possible in the list of things removed, just like anything which declares something unlawful should be interpreted narrowly. Your initial post indicated that you only wanted to drop ebuilds which were unlikely to be in use by users. Given the fact that most (all?) live ebuilds are masked, any automated tests for the likelyhood that an ebuild is in active use will, by definition, have false negatives when dealing with live ebuilds. (Where false negative means unlikely to be in use even though it, in fact, is in use.) And even if you did not intend to limit your removals as much as you indicated, it is still wrong to remove anything which the userbase actively uses. These are not ebuilds which are broken, just ones which, while functional, remain imperfect. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
[gentoo-dev] Re: Automated Package Removal and Addition Tracker, for the week ending 2009-10-25 23h59 UTC
Samuli Suominen wrote: Nirbheek Chauhan wrote: On Mon, Oct 26, 2009 at 5:45 AM, Robin H. Johnson robb...@gentoo.org wrote: The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-10-25 23h59 UTC. Removals: [snip] x11-themes/gtk-engines-kde4 2009-10-19 16:48:05 ssuominen [snip] Additions: x11-themes/gtk-engines-kde4 2009-10-19 16:26:02 ssuominen This is interesting. It's certainly not a category change; and the removal is after the addition; but the directories are still around[1]. Samuli, are you in the process of re-committing it or did you miss the empty directories? 1. http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-themes/gtk-engines-kde4/ It was a very bad decision to add this package so I've removed it like few mins after adding. ssuomi...@unique ~/gentoo-x86/x11-themes $ cvs up ssuomi...@unique ~/gentoo-x86/x11-themes $ ls -l *kde4* ls: cannot access *kde4*: No such file or directory ssuomi...@unique ~/gentoo-x86/x11-themes $ As shown above, there's no empty directory here. Actually, due to the way CVS works, there is an empty directory there, and will *always* be a directory there. I believe that in order to actually remove the directory, you have to have shell access to the cvs server itself. Most users end up setting up cvs to prune empty directories when checking out because of this exact problem. -- Jonathan
Re: [gentoo-portage-dev] REVDEP-REBUILD and emerge default options
I am very much against allowing EMERGE_DEFAULT_OPTS in revdep-rebuild since I went through hell trying to support it when it was first added as a feature to portage and I really don't want to go through that again. Paul, there's good option to filter _only_ safe options from EMERGE_DEFAULT_OPTS and pass them to emerge. If you don't like to maintain it alone, I will help you. Just forward all tickets connected to EMERGE_DEFAULT_OPTS to me. Deal? -- Best regards, Spinal
Re: [gentoo-portage-dev] REVDEP-REBUILD and emerge default options
On Mon, 2009-10-26 at 20:04 +0200, Arthur D. wrote: I am very much against allowing EMERGE_DEFAULT_OPTS in revdep-rebuild since I went through hell trying to support it when it was first added as a feature to portage and I really don't want to go through that again. Paul, there's good option to filter _only_ safe options from EMERGE_DEFAULT_OPTS and pass them to emerge. If you don't like to maintain it alone, I will help you. Just forward all tickets connected to EMERGE_DEFAULT_OPTS to me. Deal? The biggest issue is determining that EMERGE_DEFAULT_OPTS is the problem. Anyhow, I'm looking at it to see what can be done. Regards, Paul
