[gentoo-dev] Re: News item: World file handling changes in Portage-2.2
Duncan wrote: every time I try to emerge -NuD system I think there's a good case for system and world without the set specifier working the way they always have. I for one am very aware if I type in @world (ie not system, useful for -e) vs world. I don't see any benefit to the user in jettisoning the existing metaphor. What do others think?
[gentoo-dev] Re: Last rites: =dev-lang/python-2.3* (Second try)
Ali Polatel yazmış: Now that the packages depending on 2.3 are masked, masking this one again for removal in 30 days. I've moved python-2.3 from gentoo-x86 to python junkyard overlay¹. ¹: http://overlays.gentoo.org/proj/python/browser/overlays/junkyard -- Regards, Ali Polatel pgpB3R7i4FEp1.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] What features should be included in EAPI 2?
Ciaran McCreesh wrote:
On Wed, 13 Aug 2008 01:18:33 -0700
Zac Medico [EMAIL PROTECTED] wrote:
* The old src_compile phase function is split into separate
src_configure and src_compile fuctions.
If you're doing new phases... Exheres has been using src_prepare, after
src_unpack, to avoid having lots of things of the form:
src_unpack() {
default
patch blah
eautoreconf
}
Besides saving one line of typing, what is the benefit of adding this new
phase?
[gentoo-dev] Re: News item: World file handling changes in Portage-2.2
Steve Long [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 19 Aug 2008 09:20:00 +0100: I think there's a good case for system and world without the set specifier working the way they always have. I for one am very aware if I type in @world (ie not system, useful for -e) vs world. I don't see any benefit to the user in jettisoning the existing metaphor. What do others think? That's an interesting idea. I don't personally care either way, as long as @world continues to /not/ include system/@system, but having world (without the @) continue to include system /would/ be useful for backward compatibility. I think it'd be much better in terms of ease of educating the vast majority of stable users, as the @ is new anyway, so it can have new behaviour without a problem, but having new behaviour for world does present a significant re-education/retraining issue. -- 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
[gentoo-dev] gnat-gpl-2008 has been SLOTted differently from -2008
Hi All. I have some information for those of you using Ada on this list (it appears there are quite a few, so, please drop those all two people using.. jokes ;)). I have found that the recently released -2008 version has some incompatible bugs with the -2007 version (NB: this is gnat-gpl, the ACT varian), which, in itself, is rather usial. However, this time these bugs directly affect one of the Ada libs in the tree - qtada, prohibitimg me from releasing a new version (the qtada-1.0.4 still requires precisely gnat-gpl-2007, hopefully qtada-1.1 will be less picky, but I haven't tested it yet). Considering also, that many of you might want to test the latest ADA-2005 features but may very well have some projects similarly sensitive to these bugs, I decided to SLOT gnat-gpl-2008 differently from the -2007 version (they were in the same SLOT, as they both use the same gcc backend version). Now, the -2008 version has SLOT=4.1-2008 while the -2007 one simply 4.1 (not that this precise value matters to anybody, its motsly internal portage affairs). I also issued revbumps, so that the updating happens automatically. Just check your /etc/ada/primary_compilers in case you want to update them.. I'll add the new version of qtada shortly. George
Re: [gentoo-dev] Gentoo Council Reminder for August 7
Mark Loeser wrote: I personally don't see why they should be allowed to stay part of our communication channels where they have caused problems bad enough to get them retired. With that being said, I think the same technical issues come into play here as with banning someone from Gentoo entirely. I agree on this. I'd limit this ban to channels where they have caused problems though (or channels which they've been taking part of), banning them on each and every #gentoo-* channel is just an unnecessary overhead imho. And for the given technical restrictions they'd be banned as suggested, when they are coming back using another IP or another nick the same rules would apply as for every other user - warning and ban if they're misbehaving. I am not sure how we would be able to enforce this across the board for forcefully retired developers. It's not really possible without some huge work overhead to fully ban someone - therefore given limitations as described above would apply. Everything else is not doable from my pov. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for August 7
Mark Loeser wrote: Lukasz Damentko [EMAIL PROTECTED] said: 1. I'd like to ask Council to discuss possible reactions to our [...] Due to their privacy policy I don't think we'll ever be able to get adequate explanations from Freenode staff when our devs are banned. I think that's a limitation which will also applies to other IRC networks, therefore we have to live with that limitation or run our own IRC network. I can't say that I prefer the latter one ... we're a quite good in running our distribution - but would we be also that good in running our own IRC network? I guess not ... 2. I want Council to consider moving their meetings somewhere where [...] If for some reason a developer was unable to attend a meeting due to being klined or the internet being FUBAR'd, I know that I have my IM details available in LDAP for that dev to be able to contact me, or they could send the entire council an email. I don't think setting up our own IRC server is worth the trouble for this small purpose. +1 on that 3. I want Council to consider creating and using irc.gentoo.org [...] I like this idea. again +1 on that spb rose some concerns in the meeting with regards to some users thinking that if they came onto irc.gentoo.org and joined #java that it would be a Gentoo java channel, but it doesn't seem like Freenode considers this to be much of a problem. For evidence of this: http://freenode.net/acknowledgements.shtml They thank projects for pointing their domains to them, so I believe that the network as a whole shouldn't have a problem with this. If someone thinks I'm misunderstanding what they mean on that page, please let me know. Given the fact that the concern spb raised in the meeting is a non-problem, at least until Freenode changes its policy in that aspect, i see no problem with pointing irc.g.o to irc.freenode.net. Plus irc.g.o. in some way points to Freenode servers already irc.gentoo.org canonical name = irc.osuosl.org. irc.osuosl.org is an A record for 140.211.166.3 and 140.211.166.4 which are both Freenode boxes. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for August 7
On Tue, Aug 19, 2008 at 9:16 AM, Tobias Scherbaum [EMAIL PROTECTED]wrote: Mark Loeser wrote: I personally don't see why they should be allowed to stay part of our communication channels where they have caused problems bad enough to get them retired. With that being said, I think the same technical issues come into play here as with banning someone from Gentoo entirely. I agree on this. I'd limit this ban to channels where they have caused problems though (or channels which they've been taking part of), banning them on each and every #gentoo-* channel is just an unnecessary overhead imho. And for the given technical restrictions they'd be banned as suggested, when they are coming back using another IP or another nick the same rules would apply as for every other user - warning and ban if they're misbehaving. I am not sure how we would be able to enforce this across the board for forcefully retired developers. It's not really possible without some huge work overhead to fully ban someone - therefore given limitations as described above would apply. Everything else is not doable from my pov. Tobias Although it isn't feasible in practice, such a policy would allow us to defenestrate forcefully retired developers that keep coming back to mailing lists or channels with the same attitude that got then kicked, without having to resort to long process and waste of our human resources. We wouldn't have to go through the same process over and over again: if somebody was retired and keeps doing the same things as when was a developer, then people in charge of channels or mailing lists might take instant action as they find it necessary. If they get a new attitude after retired, I'm sure that the people in charge will not take the extra work to ban them for nothing. My R$ 0.02. Pilla
Re: [gentoo-dev] Re: News item: World file handling changes in Portage-2.2
Duncan wrote: That's an interesting idea. I don't personally care either way, as long as @world continues to /not/ include system/@system, but having world (without the @) continue to include system /would/ be useful for backward compatibility. I think it'd be much better in terms of ease of educating the vast majority of stable users, as the @ is new anyway, so it can have new behaviour without a problem, but having new behaviour for world does present a significant re-education/retraining issue. The only drawback I see is that we would then have the following: @system == system ...but... @world != world This, I would think, could cause confusion too - and we'd have to live with and document this quirk. How about issuing a warning when portage starts if the user specifies world (with no @ sign) as the only specified target *and* @system is not in world_sets? It would warn that the world set no longer automatically includes system (i.e., @system) and also that it is better, from now on, to explicitly use the @ sign for all sets like world and system (since these two are special cases grandfathered in). -Joe
Re: [gentoo-dev] Re: [RFC] What features should be included in EAPI 2?
On Tue, Aug 19, 2008 at 12:12 PM, Steve Long
[EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
If you're doing new phases... Exheres has been using src_prepare, after
src_unpack, to avoid having lots of things of the form:
src_unpack() {
default
patch blah
eautoreconf
}
Besides saving one line of typing, what is the benefit of adding this new
phase?
Uh, count again. It's not just one line of typing saved.
The benefit is that it's a logically separate action, and will avoid
all the silliness of people repeatedly changing their minds about
which phase should do the eautoreconf calls and so on.
--
Ciaran McCreesh
[gentoo-dev] media-fonts/droid licensing: should fonts include Apache license in tarball?
Hello. There are droid fonts package in the tree. Author states that they are apache licensed [1] (supposedly similar to google's android sdk) but license itself is not included in the package (only .ttf files are there). Should we RESTRICT=mirror in such case or it's safe to drop such restriction? [1] http://damieng.com/blog/2007/11/14/droid-sans-mono-great-coding-font Thank you for any hints, -- Peter.
Re: [gentoo-dev] Re: [RFC] What features should be included in EAPI 2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: [...] The benefit is that it's a logically separate action, and will avoid all the silliness of people repeatedly changing their minds about which phase should do the eautoreconf calls and so on. a) Is this really an issue for maintainers? b) Does it really matter? c) So the flow will look like: ... src_unpack src_prepare src_configure src_compile ... To me this seems like an unnecessary overgeneralisation. The *only* potential benefit I see here is that at some point of time in the nebulous future, it might be possible to tell the PM to always skip src_prepare in order to give a system where everything is vanilla. This is not something I see as being useful to us. - -- Arun -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkirCm0ACgkQ+Vqt1inD4uyTvQCgjEPHRCJUFrIsoyk5EnYb/jNC Lu8An0KTbHP59UXa4UcShSC7VwLUgQpI =zwPv -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [RFC] What features should be included in EAPI 2?
On Tue, 19 Aug 2008 23:31:17 +0530 Arun Raghavan [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: The benefit is that it's a logically separate action, and will avoid all the silliness of people repeatedly changing their minds about which phase should do the eautoreconf calls and so on. a) Is this really an issue for maintainers? It's not a huge issue, any more than src_configure is. Equally, it's not expensive to implement. b) Does it really matter? In the grand scheme of things, no. In the grand scheme of things, you only *need* a single src_ function. From a maintainer convenience perspective, however, src_prepare is marginally more useful than having a split src_configure. c) So the flow will look like: ... src_unpack src_prepare src_configure src_compile ... To me this seems like an unnecessary overgeneralisation. It's a better mapping of the things ebuilds do than the current set of functions. The logic is this: lots of ebuilds end up duplicating src_unpack (or, in future EAPIs, calling 'default') and then adding things to do preparation work. Experience suggests that the most common reason for overriding src_unpack is to do preparation work, not to change how things are unpacked. (Number-wise... For Exherbo, where the split's already been made, custom src_prepare functions are three times more common than custom src_unpack functions. And that figure's significantly lower than what Gentoo would see, because with exheres-0 'default' functions you don't need to write a src_prepare if you're merely applying patches.) The *only* potential benefit I see here is that at some point of time in the nebulous future, it might be possible to tell the PM to always skip src_prepare in order to give a system where everything is vanilla. Such a system wouldn't be usable... Not all of Gentoo's patches are non-essential. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for August 7
On Tuesday 19 August 2008, Mark Loeser wrote: I am not sure how we would be able to enforce this across the board for forcefully retired developers. If we are talking policies, can someone please define the term 'forecefully retired'? What about people whom had been complained about to devrel, and who then resigned? Does it include people who are retired due to inactivity? What benifit does this proposal have over an enforcement of the CoC on retired developers? If they choose to stay part of our community, any misbehaviour can also be penalized using that document. If they choose to stay and contribute properly, why ban them? I'm happy about all bugs I get, even by the most evil compile persons. Robert signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Re: News item: World file handling changes in Portage-2.2
Joe Peterson wrote: Duncan wrote: That's an interesting idea. I don't personally care either way, as long as @world continues to /not/ include system/@system, but having world (without the @) continue to include system /would/ be useful for backward compatibility. I think it'd be much better in terms of ease of educating the vast majority of stable users, as the @ is new anyway, so it can have new behaviour without a problem, but having new behaviour for world does present a significant re-education/retraining issue. Yeah that was my thinking (only better expressed ;) The only drawback I see is that we would then have the following: @system == system ...but... @world != world This, I would think, could cause confusion too - and we'd have to live with and document this quirk. I don't see that as major from a user pov; as soon as you see @ you're in set territory, which is for finer-grained control. We already expect users to have the ability to read docs and the like, and this way we're not introducing any surprises; for the standard update procedure we're all used to, sets don't come into it. How about issuing a warning when portage starts if the user specifies world (with no @ sign) as the only specified target *and* @system is not in world_sets? It's starting to get tricky.. ;) It would warn that the world set no longer automatically includes system (i.e., @system) and also that it is better, from now on, to explicitly use the @ sign for all sets like world and system (since these two are special cases grandfathered in). .. and we still get the issue that future usage would mean needing: emerge @world @system # or should it be the other way round? ..when we used to have a simple 'emerge world'[1]. I don't see how that helps our users. iow the change feels like a loss, not an improvement (which the set code certainly is), when a little tweaking with the option parser would mean we had both uses. I see it as polishing the UI, nothing more. Maybe there's a case for dropping system as a special-case over time, and giving a deprecation warning. Personally I don't see the problem with simply continuing to support it, or even changing to mean system without any user-defined stuff/ as per-profile; option parsing is hardly the bottleneck ;) [1] Assuming user doesn't want @world always including @system, which makes sense to a power-user who would be interested in sets, as Duncan showed.
[gentoo-dev] Re: Re: [RFC] What features should be included in EAPI 2?
Ciaran McCreesh wrote: On Tue, 19 Aug 2008 23:31:17 +0530 Arun Raghavan [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: The benefit is that it's a logically separate action, and will avoid all the silliness of people repeatedly changing their minds about which phase should do the eautoreconf calls and so on. Er, that would be the new src_configure? a) Is this really an issue for maintainers? It's not a huge issue, any more than src_configure is. Equally, it's not expensive to implement. b) Does it really matter? In the grand scheme of things, no. In the grand scheme of things, you only *need* a single src_ function. From a maintainer convenience perspective, however, src_prepare is marginally more useful than having a split src_configure. How so? From a user point of view, and from a maintenance point of view, src_configure is very useful. c) So the flow will look like: ... src_unpack src_prepare src_configure src_compile ... To me this seems like an unnecessary overgeneralisation. It's a better mapping of the things ebuilds do than the current set of functions. The logic is this: lots of ebuilds end up duplicating src_unpack (or, in future EAPIs, calling 'default') and then adding things to do preparation work. Experience suggests that the most common reason for overriding src_unpack is to do preparation work, not to change how things are unpacked. Yeah I've always seen src_unpack as being more cogent to preparation of src files, than to actually untarring stuff. So what? Why make a new phase which every new dev has to know about, and we have to provide pre_ and post_ hooks for, when the existing phase covers the usage fine? (Number-wise... For Exherbo, where the split's already been made, custom src_prepare functions are three times more common than custom src_unpack functions. And that figure's significantly lower than what Gentoo would see, because with exheres-0 'default' functions you don't need to write a src_prepare if you're merely applying patches.) Well it's easy enough to auto-apply patches, given a declaration in the ebuild (since files for all versions are in the same dir.) It certainly doesn't need a new phase. The *only* potential benefit I see here is that at some point of time in the nebulous future, it might be possible to tell the PM to always skip src_prepare in order to give a system where everything is vanilla. Such a system wouldn't be usable... Not all of Gentoo's patches are non-essential. So the real, fully-defined, explicit benefit is..
Re: [gentoo-dev] Re: Re: [RFC] What features should be included in EAPI 2?
On Tue, 19 Aug 2008 21:27:03 +0100 Steve Long [EMAIL PROTECTED] wrote: On Tue, 19 Aug 2008 23:31:17 +0530 Arun Raghavan [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: The benefit is that it's a logically separate action, and will avoid all the silliness of people repeatedly changing their minds about which phase should do the eautoreconf calls and so on. Er, that would be the new src_configure? Oh really? In the grand scheme of things, no. In the grand scheme of things, you only *need* a single src_ function. From a maintainer convenience perspective, however, src_prepare is marginally more useful than having a split src_configure. How so? From a user point of view, and from a maintenance point of view, src_configure is very useful. Any reason you can provide for src_configure being useful can be used with slight modification for src_prepare. It's a better mapping of the things ebuilds do than the current set of functions. The logic is this: lots of ebuilds end up duplicating src_unpack (or, in future EAPIs, calling 'default') and then adding things to do preparation work. Experience suggests that the most common reason for overriding src_unpack is to do preparation work, not to change how things are unpacked. Yeah I've always seen src_unpack as being more cogent to preparation of src files, than to actually untarring stuff. Yes, the 'unpack' in the name really does go along with the phase being used to prepare things. So what? Why make a new phase which every new dev has to know about, and we have to provide pre_ and post_ hooks for, when the existing phase covers the usage fine? Make a phase for each common logically distinct operation. Which, with src_prepare being added, we almost have. (The one missing is a src_fetch_extra or somesuch, for use by the scm eclasses. But that wants special handling, and is probably best left to another EAPI...) (Number-wise... For Exherbo, where the split's already been made, custom src_prepare functions are three times more common than custom src_unpack functions. And that figure's significantly lower than what Gentoo would see, because with exheres-0 'default' functions you don't need to write a src_prepare if you're merely applying patches.) Well it's easy enough to auto-apply patches, given a declaration in the ebuild (since files for all versions are in the same dir.) It certainly doesn't need a new phase. Well, if you're proposing that Gentoo also adopts the more complicated default_* functions from exheres-0, you're more than welcome to write up a proposal... The *only* potential benefit I see here is that at some point of time in the nebulous future, it might be possible to tell the PM to always skip src_prepare in order to give a system where everything is vanilla. Such a system wouldn't be usable... Not all of Gentoo's patches are non-essential. So the real, fully-defined, explicit benefit is.. The same as the benefit of splitting src_compile into src_configure and src_compile, except that it'll be of use to a slightly larger proportion of ebuilds. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: News item: World file handling changes in Portage-2.2
Steve Long wrote: @system == system ...but... @world != world This, I would think, could cause confusion too - and we'd have to live with and document this quirk. I don't see that as major from a user pov; as soon as you see @ you're in set territory, which is for finer-grained control. We already expect users to have the ability to read docs and the like, and this way we're not introducing any surprises; for the standard update procedure we're all used to, sets don't come into it. Ah, OK. I have been considering that world is simply a grandfathered name for @world (and same for system). I.e. that world is also specifying the world set, but that only world and system are allowed to have the @ dropped to avoid breaking things for users. Isn't that the way the code treats it now? Or is world (no @) really not a set? How about issuing a warning when portage starts if the user specifies world (with no @ sign) as the only specified target *and* @system is not in world_sets? It's starting to get tricky.. ;) It just seems like that's the most common case (expecting world to include @system and @world), so if it doesn't, warn the user, and in the process migrate users to using @ (to avoid the warning). .. and we still get the issue that future usage would mean needing: emerge @world @system # or should it be the other way round? True, but as Duncan discovered, if you leave off the -1, @system gets put in world_sets anyway, and some might want that. Then @world includes both. ..when we used to have a simple 'emerge world'[1]. I don't see how that helps our users. iow the change feels like a loss, not an improvement (which the set code certainly is), when a little tweaking with the option parser would mean we had both uses. I see it as polishing the UI, nothing more. I know what you mean. And I'm not sure what makes most sense. It still seems potentially confusing for world and @world to mean different things. If the words were different, it would not seem that way. Maybe there's a case for dropping system as a special-case over time, and giving a deprecation warning. Yeah, I'd vote for that. -Joe
[gentoo-dev] Re: News item: World file handling changes in Portage-2.2
Joe Peterson [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 19 Aug 2008 15:45:11 -0600: Ah, OK. I have been considering that world is simply a grandfathered name for @world (and same for system). I.e. that world is also specifying the world set, but that only world and system are allowed to have the @ dropped to avoid breaking things for users. Isn't that the way the code treats it now? I believe that's the way it is now, yes. Thus what we're proposing would simply keep the legacy meaning for world (and system) as they are, while @world (and @system) would refer to the specific sets. Now that it has been suggested, I do believe that's the simplest way to handle it, since it would involve no change at all for the existing words. @system would of course be the same as system, but there'd be a slight difference between world and @world. I think that's still less confusing, however, because people who don't care about the new functionality wouldn't have to worry about it, while for those that do, world could be simply explained as a legacy special-case. Since the only people worried about the difference between world and @world would be by definition the folks learning the new functionality anyway, that single legacy corner-case, once documented, shouldn't be a big deal. People learning @world can be told not to worry about the world case anyway, and just remember that sets always get @, and they're @world view (hehe, punny!) will once again be consistent. But I'm not one of the portage devs implementing it, so I'm not the one making the rules how the implementation should work. Someone (or ones, plural, yes I know someones isn't a valid plural, but anyway) else gets to decide all that. =8^) -- 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
