Re: [gentoo-dev] Regarding my final year thesis
Thank you Jauhien Piatlicki, Ciaran McCreesh, Ian Stakenvicius, Jeroen Roovers for your detailed replies. After reading all the proivded information, I got confused about doing SAT or CP model. Currently i am in 5 th year of Applied Mathematics and i have 6 months of time to complete my work. > "The other huge multidimensional tree we have is the bug tracker > database. Several social science majors have already tried to do > something intelligible with the bug tracker data (and failed in my > opinion) so I am confident that someone who doesn't have that socially > oriented view of networks might be able to come up with more outrageous > and interesting viewpoints on how the bug tracker actually works and how > various bits of it interconnect, or doesn't work and don't connect, > respectively." -- Jeroen Roovers This idea seems bit interesting, about how the bug tracker works. In this i just need to confirm that how much mathematical aspect can be included. It's a good idea to work on. Harsh Bhatt On Friday, 7 November 2014 2:58 AM, Jeroen Roovers wrote: On Thu, 06 Nov 2014 14:25:46 +0100 Jauhien Piatlicki wrote: > Mathematics you said? That's nice. You can, for example, redesign our > portage's dependency solving algorithm More generally perhaps: do something interesting with the portage tree. If not as directly useful as fixing dependency, a look at how bits of the tree changed over time (particularly with regard to inter-dependencies between the bits) could be much more interesting than regarding any particular snapshot. The other huge multidimensional tree we have is the bug tracker database. Several social science majors have already tried to do something intelligible with the bug tracker data (and failed in my opinion) so I am confident that someone who doesn't have that socially oriented view of networks might be able to come up with more outrageous and interesting viewpoints on how the bug tracker actually works and how various bits of it interconnect, or doesn't work and don't connect, respectively. jer
Re: [gentoo-dev] Last rites media-fonts/oxygen-fonts
On Thu, 6 Nov 2014 22:49:38 + Ciaran McCreesh wrote: > Not if the new package has already been added you can't. Moving a > package on top of an existing package is very very bad. Also, the versions don't actually match so the content will probably have changed. Oh well. jer
Re: [gentoo-dev] RFC: future.eclass
> On Thu, 6 Nov 2014, Michał Górny wrote: > Please review the attached future.eclass. Long story short, the idea > is to provide some of the EAPI 6 feel to EAPI 5 ebuilds. I don't like this idea at all. We shouldn't anticipate EAPI 6 features in an eclass before the spec is final and has been approved by the council. If the purpose of this is testing the new feature, then this should be done in an overlay. Ulrich pgpoX1C7TxljG.pgp Description: PGP signature
Re: [gentoo-dev] Last rites media-fonts/oxygen-fonts
On Thu, 6 Nov 2014 23:47:20 +0100 Jeroen Roovers wrote: > On Thu, 06 Nov 2014 23:44:24 +0100 > Manuel Rüger wrote: > > It could have been introduced to the tree as a pkgmove, but it > > wasn't. The best solution for now is imho to lastrite it. > > You could still do the pkgmove right now, and not wait thirty days. :) Not if the new package has already been added you can't. Moving a package on top of an existing package is very very bad. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites media-fonts/oxygen-fonts
On Thu, 06 Nov 2014 23:44:24 +0100 Manuel Rüger wrote: > It could have been introduced to the tree as a pkgmove, but it wasn't. > The best solution for now is imho to lastrite it. You could still do the pkgmove right now, and not wait thirty days. :) jer
Re: [gentoo-dev] Last rites media-fonts/oxygen-fonts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06.11.2014 23:19, Jeroen Roovers wrote: > On Thu, 06 Nov 2014 22:03:26 +0100 Manuel Rüger > wrote: > >> # Manuel Rüger (6 Nov 2014) # Use >> kde-base/oxygen-fonts instead # Masked for removal in 30 days >> media-fonts/oxygen-fonts > > That one wasn't up for a pkgmove? > > > jer > It could have been introduced to the tree as a pkgmove, but it wasn't. The best solution for now is imho to lastrite it. Manuel -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJUW/nIXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNciz8P/j7y7KEWrZ3B30iSeIco3dHf vWReIbdt9/h8VBl1LH8q+rSvB/AckpuMZunoVBCCgBk58aK9gu3z1oRqs+vxbros +RwCyDATfDhZRwkCCeQ7xqPto1FC8Uca4xCJHLUBlSkRwvnZcg7ZH2EAlXAwcldI NP/nvKuDI3BGaQGp9YuorD0MbnvJzgrRX1CEqgQb82cN0zgBoIJ/dS1On9Yl1Qs/ 4yA+QoKnDaSFnmpI3AZoL39E3Ygvq1B5pJbZ4O1Docd/1MhESpar2VieUcb/F14g STrYtGvWIIttlNlwqobJXTMzxrRJVpF3x9zqFrVXFypjzH2uV0Ipb5/lAHFgSj1r dmsHwx/lbsu1NqCt/eFqIxVfb9CPmiCavLb2zdySTUx0t1F6pVJcG+9IvsVjBLcR DD437AAM6t4BpiFr9fcGc4XyjY84n8oNGL+8B1vYiilAzUAFC/7PjgEfK7yWF4RF TIYhw2Fquuz1GT9DLFlWeFGge36p/Cpm2n2JlWnf97yPn4dTmEqDaQCiAwRlcKJL TB2nZTjVIrDLOMV0I7AN4sxXhNze/ci8tlSKo6W93e/AXn6XXrCeXgbmDV/PfZfm KMAYsIN4XRLQlJQaPnckr2iPfBO9rFVMwXEYd/orBFdYbK+fasI9VDDAOth/lwNm DzEo19bRVc/Nbm3usWO2 =mkWh -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: future.eclass
On 11/06/2014 02:16 PM, Jeroen Roovers wrote: > On Thu, 06 Nov 2014 13:42:43 -0800 > Zac Medico wrote: > >> On 11/06/2014 01:32 PM, Jeroen Roovers wrote: >>> I'm not aware of any current definition of order in eclass >>> inheritance. >> >> Maybe PMS doesn't say anything about the order (yet). However, I'm >> fairly sure that all package managers process eclasses in the same >> order that they are passed as arguments to inherit. Otherwise, >> eclasses would not be able to properly override functions defined by >> eclasses earlier in the inherit chain. > > If the order is important, then the ebuild should call each phase or > utility function explicitly. Expecting the order of inheritance to > convey the same thing instead of making explicit calls might work from > the package manager's perspective, but the ebuild writer is lost in the > woods. With that in mind we might argue that a change in the order of > inheritance should never cause a different outcome. > >> In the context of future.eclass, eutils and multilib could simply >> check if the relevant functions were defined earlier, and die in that >> case. > > Would the bash internal `readonly -f' work for that? Maybe, but the error message would be cryptic. I was thinking something like this: declare -F get_libdir >/dev/null && \ die "multilib.eclass must be inherited before future.eclass" >>> We sure have issues with inheriting eclasses in a different order >>> giving different results now. Is this something that's in the works >>> for a future EAPI, then? >> >> No, but as said, I'm fairly sure that all package managers process >> eclasses in the same order that they are passed as arguments to >> inherit. > > Well, that's convenient but you should probably not start relying on > it now. I think it would be a fine assumption, and Ciaran has noted that PMS already specifies that inherit parameters are considered in order. > In that case we might want to discuss inheriting in > alphabetical order and numbering the eclasses cleverly, too. Or rename > this one to zfuture.eclass. I understand your intentions, but I don't think that's the right solution. I agree with Ciaran's assertion that "it would be much easier if people just stopped writing "clever" eclasses and didn't mix utility functions and phase functions within a single eclass". -- Thanks, Zac
Re: [gentoo-dev] RFC: future.eclass
On Thu, 06 Nov 2014 13:42:43 -0800 Zac Medico wrote: > Maybe PMS doesn't say anything about the order (yet). But it does. It says parameters are considered in order. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites media-fonts/oxygen-fonts
On Thu, 06 Nov 2014 22:03:26 +0100 Manuel Rüger wrote: > # Manuel Rüger (6 Nov 2014) > # Use kde-base/oxygen-fonts instead > # Masked for removal in 30 days > media-fonts/oxygen-fonts That one wasn't up for a pkgmove? jer
Re: [gentoo-dev] RFC: future.eclass
On Thu, 06 Nov 2014 13:42:43 -0800 Zac Medico wrote: > On 11/06/2014 01:32 PM, Jeroen Roovers wrote: > > I'm not aware of any current definition of order in eclass > > inheritance. > > Maybe PMS doesn't say anything about the order (yet). However, I'm > fairly sure that all package managers process eclasses in the same > order that they are passed as arguments to inherit. Otherwise, > eclasses would not be able to properly override functions defined by > eclasses earlier in the inherit chain. If the order is important, then the ebuild should call each phase or utility function explicitly. Expecting the order of inheritance to convey the same thing instead of making explicit calls might work from the package manager's perspective, but the ebuild writer is lost in the woods. With that in mind we might argue that a change in the order of inheritance should never cause a different outcome. > In the context of future.eclass, eutils and multilib could simply > check if the relevant functions were defined earlier, and die in that > case. Would the bash internal `readonly -f' work for that? > > We sure have issues with inheriting eclasses in a different order > > giving different results now. Is this something that's in the works > > for a future EAPI, then? > > No, but as said, I'm fairly sure that all package managers process > eclasses in the same order that they are passed as arguments to > inherit. Well, that's convenient but you should probably not start relying on it now. In that case we might want to discuss inheriting in alphabetical order and numbering the eclasses cleverly, too. Or rename this one to zfuture.eclass. jer
Re: [gentoo-dev] RFC: future.eclass
Am Donnerstag, 6. November 2014, 22:56:21 schrieb Rich Freeman: > > I think we are well-served by taking Ciaran's advice here. Utility > eclasses should just passively export functions. Anything that does > overrides should really be designed for special situations and not > widespread use where it would potentially conflict with other eclasses > that do the same. So, a KDE all-in-one eclass might not be bad. A > perl all-in-one eclass would be more troublesome, Bad example. :) We have ca 1800 packages in the portage tree inheriting perl- module.eclass and most of them do not declare any phases themselves but just inherit eclass phases. Which works fine and reduces most ebuilds to a bare minimum. But yes, in general the idea of separating utility eclasses and phase eclasses somehow is imho a good one. My personal suggestion would be for a future EAPI to only allow "export all phases, if necessary autogenerated dummies" or "export no phases". -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: future.eclass
On 11/06/2014 01:53 PM, Rich Freeman wrote: > On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny wrote: >> >> # This eclass contains backports of functions that were accepted >> # by the Council for the EAPI following the EAPI used by ebuild, >> # and can be implemented in pure shell script. > > I'm not sure that I like this sort of a moving-target definition. > When EAPI6 is out, do you intend to have the eclass die at some point > for any packages using EAPI5? We should be able to simply migrate consumers to the new EAPI, then deprecate future.eclass. > Or will they work indefinitely, and > then the eclass will behave differently depending on what EAPI is used > by the ebuild calling it? I can see issues either way (either we're > building a monster eclass that basically replicates half of PMS, or we > start running into migration issues and maybe even breakage of old > systems that aren't updated/etc). Old systems are not a problem, since installed packages always use serialized eclasses from /var/db/pkg/*/*/environment.bz2. The biggest problem would be out-of-tree ebuilds (overlays) that continue to use future.eclass after it's been deprecated. > If this were about testing EAPI features prior to implementation in a > limited and short-term scenario I could maybe see this being a > net-positive, but even then we have issues with the eclass changing > when users still have packages using it installed. No, as said, installed packages use serialized eclasses from /var/db/pkg/*/*/environment.bz2. > I get what you're trying to do, but I'm a little worried that it might > cause as many problems as it solves. Given that old systems aren't a problem, out-of-tree ebuilds are the main issue that I can think of. -- Thanks, Zac
Re: [gentoo-dev] RFC: future.eclass
On Thu, Nov 6, 2014 at 4:38 PM, Ciaran McCreesh
wrote:
> On Thu, 6 Nov 2014 22:32:17 +0100
> Jeroen Roovers wrote:
>> On Thu, 06 Nov 2014 12:40:33 -0800
>> Zac Medico wrote:
>> > On 11/06/2014 12:11 PM, Michał Górny wrote:
>> > > # multilib.eclass collisions
>> > > get_libdir() { future_get_libdir "${@}"; }
>> > > # eutils.eclass collisions
>> > > einstalldocs() { future_einstalldocs "${@}"; }
>> >
>> > This collision handling mechanism seems pretty reasonable.
>> > Alternatively, maybe it could die if the functions are already
>> > defined, and advise the developer that future should be inherited
>> > later than multilib and eutils.
>>
>> I'm not aware of any current definition of order in eclass
>> inheritance. We sure have issues with inheriting eclasses in a
>> different order giving different results now. Is this something
>> that's in the works for a future EAPI, then?
>
> An EAPI solution to this is hard to work out. It would be much easier if
> people just stopped writing "clever" eclasses and didn't mix utility
> functions and phase functions within a single eclass.
>
For anybody interested in this the topic came up in the council EAPI
discussions especially on June 17th, and in bug:
https://bugs.gentoo.org/show_bug.cgi?id=422533
I think we are well-served by taking Ciaran's advice here. Utility
eclasses should just passively export functions. Anything that does
overrides should really be designed for special situations and not
widespread use where it would potentially conflict with other eclasses
that do the same. So, a KDE all-in-one eclass might not be bad. A
perl all-in-one eclass would be more troublesome, especially if KDE
had any packages written in perl. Just to pick somewhat random and
perhaps not great examples.
--
Rich
Re: [gentoo-dev] RFC: future.eclass
On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny wrote: > > # This eclass contains backports of functions that were accepted > # by the Council for the EAPI following the EAPI used by ebuild, > # and can be implemented in pure shell script. I'm not sure that I like this sort of a moving-target definition. When EAPI6 is out, do you intend to have the eclass die at some point for any packages using EAPI5? Or will they work indefinitely, and then the eclass will behave differently depending on what EAPI is used by the ebuild calling it? I can see issues either way (either we're building a monster eclass that basically replicates half of PMS, or we start running into migration issues and maybe even breakage of old systems that aren't updated/etc). If this were about testing EAPI features prior to implementation in a limited and short-term scenario I could maybe see this being a net-positive, but even then we have issues with the eclass changing when users still have packages using it installed. I get what you're trying to do, but I'm a little worried that it might cause as many problems as it solves. --- Rich
Re: [gentoo-dev] RFC: future.eclass
On 11/06/2014 01:32 PM, Jeroen Roovers wrote:
> On Thu, 06 Nov 2014 12:40:33 -0800
> Zac Medico wrote:
>
>> On 11/06/2014 12:11 PM, Michał Górny wrote:
>>> # multilib.eclass collisions
>>> get_libdir() { future_get_libdir "${@}"; }
>>> # eutils.eclass collisions
>>> einstalldocs() { future_einstalldocs "${@}"; }
>>
>> This collision handling mechanism seems pretty reasonable.
>> Alternatively, maybe it could die if the functions are already
>> defined, and advise the developer that future should be inherited
>> later than multilib and eutils.
>
> I'm not aware of any current definition of order in eclass inheritance.
Maybe PMS doesn't say anything about the order (yet). However, I'm
fairly sure that all package managers process eclasses in the same order
that they are passed as arguments to inherit. Otherwise, eclasses would
not be able to properly override functions defined by eclasses earlier
in the inherit chain.
In the context of future.eclass, eutils and multilib could simply check
if the relevant functions were defined earlier, and die in that case.
> We sure have issues with inheriting eclasses in a different order giving
> different results now. Is this something that's in the works for a
> future EAPI, then?
No, but as said, I'm fairly sure that all package managers process
eclasses in the same order that they are passed as arguments to inherit.
--
Thanks,
Zac
Re: [gentoo-dev] RFC: future.eclass
On Thu, 6 Nov 2014 22:32:17 +0100
Jeroen Roovers wrote:
> On Thu, 06 Nov 2014 12:40:33 -0800
> Zac Medico wrote:
> > On 11/06/2014 12:11 PM, Michał Górny wrote:
> > > # multilib.eclass collisions
> > > get_libdir() { future_get_libdir "${@}"; }
> > > # eutils.eclass collisions
> > > einstalldocs() { future_einstalldocs "${@}"; }
> >
> > This collision handling mechanism seems pretty reasonable.
> > Alternatively, maybe it could die if the functions are already
> > defined, and advise the developer that future should be inherited
> > later than multilib and eutils.
>
> I'm not aware of any current definition of order in eclass
> inheritance. We sure have issues with inheriting eclasses in a
> different order giving different results now. Is this something
> that's in the works for a future EAPI, then?
An EAPI solution to this is hard to work out. It would be much easier if
people just stopped writing "clever" eclasses and didn't mix utility
functions and phase functions within a single eclass.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: future.eclass
On Thu, 06 Nov 2014 12:40:33 -0800
Zac Medico wrote:
> On 11/06/2014 12:11 PM, Michał Górny wrote:
> > # multilib.eclass collisions
> > get_libdir() { future_get_libdir "${@}"; }
> > # eutils.eclass collisions
> > einstalldocs() { future_einstalldocs "${@}"; }
>
> This collision handling mechanism seems pretty reasonable.
> Alternatively, maybe it could die if the functions are already
> defined, and advise the developer that future should be inherited
> later than multilib and eutils.
I'm not aware of any current definition of order in eclass inheritance.
We sure have issues with inheriting eclasses in a different order giving
different results now. Is this something that's in the works for a
future EAPI, then?
jer
Re: [gentoo-dev] Regarding my final year thesis
On Thu, 06 Nov 2014 14:25:46 +0100 Jauhien Piatlicki wrote: > Mathematics you said? That's nice. You can, for example, redesign our > portage's dependency solving algorithm More generally perhaps: do something interesting with the portage tree. If not as directly useful as fixing dependency, a look at how bits of the tree changed over time (particularly with regard to inter-dependencies between the bits) could be much more interesting than regarding any particular snapshot. The other huge multidimensional tree we have is the bug tracker database. Several social science majors have already tried to do something intelligible with the bug tracker data (and failed in my opinion) so I am confident that someone who doesn't have that socially oriented view of networks might be able to come up with more outrageous and interesting viewpoints on how the bug tracker actually works and how various bits of it interconnect, or doesn't work and don't connect, respectively. jer
Re: [gentoo-dev] RFC: future.eclass
On 11/06/2014 01:11 PM, Zac Medico wrote:
> On 11/06/2014 12:40 PM, Zac Medico wrote:
>> On 11/06/2014 12:11 PM, Michał Górny wrote:
>>> # multilib.eclass collisions
>>> get_libdir() { future_get_libdir "${@}"; }
>>> # eutils.eclass collisions
>>> einstalldocs() { future_einstalldocs "${@}"; }
>>
>> This collision handling mechanism seems pretty reasonable.
>> Alternatively, maybe it could die if the functions are already defined,
>> and advise the developer that future should be inherited later than
>> multilib and eutils.
>
> Now I realize that future.eclass has no way of knowing when mutilib or
> eutils are inherited later. So, I can't think of a better way to handle
> the collisions that what you already have.
Well, I suppose that multilib and eutils could check to see if future
was inherited earlier, and die in that case.
--
Thanks,
Zac
Re: [gentoo-dev] RFC: future.eclass
On 11/06/2014 12:40 PM, Zac Medico wrote:
> On 11/06/2014 12:11 PM, Michał Górny wrote:
>> # multilib.eclass collisions
>> get_libdir() { future_get_libdir "${@}"; }
>> # eutils.eclass collisions
>> einstalldocs() { future_einstalldocs "${@}"; }
>
> This collision handling mechanism seems pretty reasonable.
> Alternatively, maybe it could die if the functions are already defined,
> and advise the developer that future should be inherited later than
> multilib and eutils.
Now I realize that future.eclass has no way of knowing when mutilib or
eutils are inherited later. So, I can't think of a better way to handle
the collisions that what you already have.
--
Thanks,
Zac
[gentoo-dev] Last rites: dev-ruby/prawn:0, dev-ruby/prawn-{core,layout,security}
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Manuel Rüger (6 Nov 2014) # Unmaintained slot, move on to dev-ruby/prawn:1 # Masked for removal in 30 days dev-ruby/prawn:0 dev-ruby/prawn-security dev-ruby/prawn-layout dev-ruby/prawn-core -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJUW+KGXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNclNUP/A6ou3ARedcRy+KFCiAuswBK qCfXFAL5z9u0KZa1E+CQEZpI/CEO3GYDxIuZWChCggym9D5qw13HvM8t+pUWJMy0 +YqpOmqUkBdMUDGQ4Smu/sQD2BpY1m65xPnnwMEJgMnSkJ2XUpPhaGGm+Y5CaD9m zL5sBep3ZOmzeWxrgNuBgUIV0LZ0nyvE+d4elAwBYvfYHdugTzC4egNUzNXBW2n8 NAsz5P6Y2uhFGKlx6bDsg6IUkFpxwcWPyZF8MwSk2pw5oF6aqDsU84+3ZbmYpNua NfPjeBDwNZhV/6TDk8Ybhy3ZuGoHb4xSoW/dWe/RyEGobhTqRtEPyoJbMDv2OMVA G8BMacjZJ9+DSZAh+n9xKQynubT3XXQO1is/mt/Ta+J02ATzS8Rwp7FvWSSGbd6s 5L6mbVQ6T8XZ4mGvlrUBfc8M72E9GfiDRKmTklRsHqBiE4WNnkynxklzq5zLXZ9q BkrZVDiNT/CNtAT1zfqYQxMf1MG/bHBmms041F33LK/aAtzrEU/c9PhBERaGGI3S oawoUalnI35i8EnwD3GkI54fb9MO+9sZwiRD/aMhT/vrIgJ0da3Y7Hn6s/DWXq9m xIGPOA0/lz0dNpX9MK5kTyy17RM3shGYs6REvReePF0sNvU5olnDBr2YIPsgiIBd PBzS2ROb5dQAbnsSStGH =pH0t -END PGP SIGNATURE-
[gentoo-dev] Last rites media-fonts/oxygen-fonts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Manuel Rüger (6 Nov 2014) # Use kde-base/oxygen-fonts instead # Masked for removal in 30 days media-fonts/oxygen-fonts -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJUW+IeXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNc61cP/1FWtmr643gbri9fhDtnQqO0 2p3gB7PdIg36wThjYUZwx9lWovmOE45ZDMvK9ZWCaLkvmF3DmlM2eK3rwuZ3j0W9 00pEdMh4gjU6mVUZLkUloXvVxqDz7bim9U4bCZQo0lBnlVMHaaRtU+KjWvaFjCQe +KdlGamDyxdNBMQp+OhPgWQu9d7kwa8seGvWIKPJEoEPdOMS7bBfHTYTp8wCje8j aansMNAKsqlURSAus821deMTPd9QcywWN414VLpKeJuXl1rBueybrEt48RTQhOe+ wC8NuDno9Y9+fo7r2Zi1VSa1vkl2TiaBLZZlihSoP9M0XS6NLI/2Xn1tOonq/mqx 0VcatbRssRHWRTEi3qnFrOW7m49gtoZOh5ff375xV/uOOUgO59ZLu92OdczTzFgX oAAZLIVLVcfiJmIf8cGX4teB+58IC4qCmY+G8kZ1gS6ijsk4y37j1R+oA3We9V9A 3eJx0qixYaHO/M9giOY6ffHYLNAx04560tIlGC6yTZ2yVuwmDor3//ShAbha9utf pYYUZkGXtiJ4IcgqKbyI6i1uTqentqe1Gq7OOLFjBrSP9W8I405Ita1eseDWCQgx ZGP7TKXPSSMapaLuGhkUIDIavy0RikZ/lDHGNto3uKg1vF5LtAc8G3MFCsARhl6i 4TpH4B6FX93zO/cSDnXb =ZCIS -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: future.eclass
On 11/06/2014 12:11 PM, Michał Górny wrote:
> # multilib.eclass collisions
> get_libdir() { future_get_libdir "${@}"; }
> # eutils.eclass collisions
> einstalldocs() { future_einstalldocs "${@}"; }
This collision handling mechanism seems pretty reasonable.
Alternatively, maybe it could die if the functions are already defined,
and advise the developer that future should be inherited later than
multilib and eutils. Is there any reason not to inherit future after
multilib and eutils? I guess the reason would be some dependency on the
old implementations?
--
Thanks,
Zac
Re: [gentoo-dev] RFC: future.eclass
On Thu, 6 Nov 2014 21:11:03 +0100 Michał Górny wrote: > Please review the attached future.eclass. Long story short, the idea > is to provide some of the EAPI 6 feel to EAPI 5 ebuilds. Only if using future.eclass means any other developer automatically has permission to upgrade your ebuilds to a newer EAPI... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] RFC: future.eclass
Hi,
Please review the attached future.eclass. Long story short, the idea is
to provide some of the EAPI 6 feel to EAPI 5 ebuilds.
Quoting the beginning of the DESCRIPTION:
# This eclass contains backports of functions that were accepted
# by the Council for the EAPI following the EAPI used by ebuild,
# and can be implemented in pure shell script.
#
# The goals of the eclass are to:
# 1. provide wider testing of Portage implementations of the next EAPI
# functions,
# 2. allows developer to use some of the features of the next EAPI
# before it is approved production-ready and implemented in Portage
# for long enough,
# 3. improve EAPI migration time through allowing some of the ebuild
# updates earlier,
# 4. reduce the necessity of inheriting large, complex and frequently
# changing eclasses whenever possible.
and the feature list:
# Currently implemented EAPI 6 features for EAPI 5:
# 1. get_libdir() #463586, simpler than in multilib.eclass;
# 2. einstalldocs() #459862, does not use dohtml as eutils.eclass does;
# 3. eapply() #463768;
# 4. eapply_user() #475288;
# 5. new default src_prepare() & src_install() exported;
# 6. einstall() is banned #524112 [may be non-portable];
# 7. dohtml() is deprecated #520546 [may be non-portable].
--
Best regards,
Michał Górny
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: future.eclass
# @MAINTAINER:
# mgo...@gentoo.org
# @BLURB: backports of functions accepted for the next EAPI
# @DESCRIPTION:
# This eclass contains backports of functions that were accepted
# by the Council for the EAPI following the EAPI used by ebuild,
# and can be implemented in pure shell script.
#
# The goals of the eclass are to:
# 1. provide wider testing of Portage implementations of the next EAPI
# functions,
# 2. allows developer to use some of the features of the next EAPI
# before it is approved production-ready and implemented in Portage
# for long enough,
# 3. improve EAPI migration time through allowing some of the ebuild
# updates earlier,
# 4. reduce the necessity of inheriting large, complex and frequently
# changing eclasses whenever possible.
#
# Please note that the eclass is meant to support the newest EAPI only.
# At the time, this means that EAPI=5 ebuilds will get some EAPI=6
# features through it but EAPI=4 ebuilds are supposed to use EAPI=5
# directly.
#
# If a function declared in the next EAPI collides with eclass-defined
# function (e.g. get_libdir() in EAPI 6 and multilib.eclass),
# the future.eclass version is used whenever it is inherited later.
# Otherwise, the implementation can be accessed using 'future_' prefix.
# It is generally recommended to inherit future after those other
# eclasses, or not inherit those eclasses at all.
#
# Note to future maintainers: please don't add support for new EAPIs
# before the contents of a subsequent EAPI are approved by the Council
# and implemented in Portage.
#
# Currently implemented EAPI 6 features for EAPI 5:
# 1. get_libdir() #463586, simpler than in multilib.eclass;
# 2. einstalldocs() #459862, does not use dohtml as eutils.eclass does;
# 3. eapply() #463768;
# 4. eapply_user() #475288;
# 5. new default src_prepare() & src_install() exported;
# 6. einstall() is banned #524112 [may be non-portable];
# 7. dohtml() is deprecated #520546 [may be non-portable].
if [[ -z ${_FUTURE_ECLASS} ]]; then
case "${EAPI:-0}" in
5) ;;
*) die "EAPI ${EAPI:-0} is not supported by future.eclass.";;
esac
fi
# (run outside the guard for expectable behavior w/ indirect inherits)
# multilib.eclass collisions
get_libdir() { future_get_libdir "${@}"; }
# eutils.eclass collisions
einstalldocs() { future_einstalldocs "${@}"; }
EXPORT_FUNCTIONS src_prepare src_install
if [[ -z ${_FUTURE_ECLASS} ]]; then
# 1. NEW FUNCTIONS
# @FUNCTION: get_libdir
# @RETURN: the libdir for the selected ABI
# @DESCRIPTION:
# Return the proper libdir for the selected ABI, fallback to 'lib'.
#
# The implementation is based on the implementation used in econf PMS
# function. However, this one returns 'lib' whenever the econf
# implementation would not pass --libdir.
#
# Note: if multilib.eclass is inherited after future.eclass,
# the implementation can be accessed as future_get_libdir.
future_get_libdir() {
local libdir_var="LIBDIR_${ABI}"
local libdir="lib"
[[ -n ${ABI} && -n ${!libdir_var} ]] && libdir=${!libdir_var}
echo "${libdir}"
}
# @FUNCTION: einstalldocs
# @DESCRIPTION:
# Install documentation using DOCS and HTML_DOCS.
#
# If DOCS is declared and non-empty, all files and directories listed
# in it are installed. The files must exist, otherwise the function
# will fail.
#
# If DOCS is not declared, the files matching patterns given
# in the default EAPI implementation of src_install will be installed.
# If this is undesired, DOCS can be set to empty value to prevent any
# documentation from being installed.
#
# If HTML_DO
[gentoo-dev] glibc-2.20 heading to ~arch
remember: this requires >=linux-2.6.32 -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Regarding my final year thesis
On Thu, 06 Nov 2014 10:18:18 -0500 Ian Stakenvicius wrote: > ...well, if this is an undergrad project, he could start with the SAT > solver and then do what you recommend for his Masters' .. :) Naah, SAT is doomed. A (bad) vanilla CP model is doable, but in my experience of students doing these kinds of projects, SAT and IP look sufficiently "mathsy" to count as a maths project, but if you hand in a CP model to a mathematician they'll go "I don't understand, you just wrote down some stuff describing something. This isn't maths!"... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Regarding my final year thesis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/11/14 08:43 AM, Ciaran McCreesh wrote: > On Thu, 06 Nov 2014 14:25:46 +0100 Jauhien Piatlicki > wrote: >> Mathematics you said? That's nice. You can, for example, redesign >> our portage's dependency solving algorithm, as it is quite slow >> at the moment. ) I do not know what it does have inside right >> now, but using SAT solver can be a good idea (there is a >> successful example already: >> https://en.opensuse.org/openSUSE:Libzypp_satsolver) > > A SAT encoding for dependency resolution is a *terrible* idea, for > all kinds of reasons (some of which are Gentoo-specific, and some > of which are not). > > [ Snip! ] > > What you need is for someone who understands CP and SAT to write a > resolver using algorithms inspired by how CP and SAT solvers work, > but not just blindly copying them. Doing this well is at least a > full year Masters level project... > ...well, if this is an undergrad project, he could start with the SAT solver and then do what you recommend for his Masters' .. :) -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlRbkToACgkQ2ugaI38ACPBwYwEAtrXJFaVlf4WSv7eV8N+vX6T9 VFq56sh59LmeJ6+UMJcA/33trhsYdNAoRe6i/RWIIRQw8zyS37lIo6I9bLA7TEPg =7kZS -END PGP SIGNATURE-
Re: [gentoo-dev] Regarding my final year thesis
On Thu, 06 Nov 2014 14:25:46 +0100 Jauhien Piatlicki wrote: > Mathematics you said? That's nice. You can, for example, redesign our > portage's dependency solving algorithm, as it is quite slow at the > moment. ) I do not know what it does have inside right now, but using > SAT solver can be a good idea (there is a successful example already: > https://en.opensuse.org/openSUSE:Libzypp_satsolver) A SAT encoding for dependency resolution is a *terrible* idea, for all kinds of reasons (some of which are Gentoo-specific, and some of which are not). * The model would be full of implication constraints, which perform terribly under unit propagation. * You can't get decent human-readable explanations of failure out of SAT solvers. * You're not just trying to find a correct resolution. You're trying to find an optimal resolution, with respect to some very difficult criteria. For example, you don't want to install any extra unrelated packages. This is very hard to express in SAT if you're going for a model which preserves consistency. * Coming up with a legal ordering in SAT is a pain. It's worse if you're trying to fully solve circular dependencies: if you do, dependency resolution becomes harder than NP, so you'd at least need a QSAT solver, not SAT. * Coming up with a legal resolution isn't always the right thing to do. Often a legal resolution can be obtained by uninstalling a whole load of stuff or switching loads of USE flags off. But it's better to give a good error to the user than to come up with a legal but stupid resolution. In other words, you *don't* want a complete algorithm, you want a domain-aware incomplete algorithm. If you're going to go the toolkit route, you should be using a CP solver, not a SAT solver. But even then you'd be better off making some changes and not using plain old MAC, so you're back to writing the algorithms yourself. What you need is for someone who understands CP and SAT to write a resolver using algorithms inspired by how CP and SAT solvers work, but not just blindly copying them. Doing this well is at least a full year Masters level project... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Regarding my final year thesis
Hi, Mathematics you said? That's nice. You can, for example, redesign our portage's dependency solving algorithm, as it is quite slow at the moment. ) I do not know what it does have inside right now, but using SAT solver can be a good idea (there is a successful example already: https://en.opensuse.org/openSUSE:Libzypp_satsolver) -- Regards, Jauhien On 11/06/2014 01:49 PM, Harsh Bhatt wrote: > I an Applied Maths student, currently in my final year. In my last 6 months i > need to do a thesis something related to Mathematics as i am a Maths student. > I have been using gentoo for quite a long time so was thinking to do > something related to gentoo. Give me suggestion of what can be done. Anything > related to modeling, simulation or Discreet Mathematics would be a better > choice. > signature.asc Description: OpenPGP digital signature
[gentoo-dev] Regarding my final year thesis
I an Applied Maths student, currently in my final year. In my last 6 months i need to do a thesis something related to Mathematics as i am a Maths student. I have been using gentoo for quite a long time so was thinking to do something related to gentoo. Give me suggestion of what can be done. Anything related to modeling, simulation or Discreet Mathematics would be a better choice.
[gentoo-dev] help on lxqt
Hello there, Last night I decided to join the LXQT project. So I was checking our their their repo: git clone http://github.com/lxde/lxqt ~/src/lxqt Cretaed a build directory in there and ran cmake. It appeared that my version of liblxqt(0.8.0) was too old and I needed the current one from git. So I added the Gentoo Qt overlay and installed that version. However when running CMake I get: $ cmake .. -- The C compiler identification is GNU 4.8.2 -- The CXX compiler identification is GNU 4.8.2 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Error at compton-conf/CMakeLists.txt:11 (include): include could not find load file: LXQtTranslateTs CMake Error at compton-conf/CMakeLists.txt:12 (include): include could not find load file: LXQtTranslateDesktop -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - found -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - not found -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - not found -- Found Qt4: /usr/bin/qmake (found version "4.8.5") -- Building with Qt4.8.5 -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") -- checking for module 'libconfig' -- found libconfig, version 1.4.9 CMake Error at compton-conf/CMakeLists.txt:74 (lxqt_translate_ts): Unknown CMake command "lxqt_translate_ts". It seems like LXQtTranslateTs (which is supposed to be in git version of liblxqt) didn't get installed. To check if that was correct I ran "equery f liblxqt" which showed (among others): /usr/share/cmake/lxqt-qt5/modules/LXQtTranslate.cmake /usr/share/cmake/lxqt-qt5/modules/LXQtTranslateDesktop.cmake /usr/share/cmake/lxqt-qt5/modules/LXQtTranslateTs.cmake /usr/share/cmake/lxqt-qt5/modules/LXQtTranslationLoader.cmake Now I have no idea what to do and why this error persists. I also contacted the LXDE guys, but they said they have no idea as this might be Gentoo specific. Maybe I should also add that the newest version of lxqt only supports Qt5, which is why I unmasked it in /etc/portage/profiles/base/use.mask and added it to global USE flags. I hope somebody can help me with this. regards, Michael
Re: [gentoo-dev] Implicit system dependency
On 05/11/14 18:49, Mike Gilbert wrote: On Wed, Nov 5, 2014 at 12:30 PM, Luca Barbato wrote: On 05/11/14 02:16, Michael Orlitzky wrote: When I was taking my ebuild quizzes, I asked for someone to clarify the implicit system dependency that we have enshrined in the devmanual: https://bugs.gentoo.org/show_bug.cgi?id=485356 There is... some agreement, but also special cases and special-special cases that are folklore-only at this point. To me it seems like a fine thing to ask the council to sort out, so I'm asking here for discussion. Can we come up with an idiot-proof list (or FLOWCHART, even!) of what should and should not be excluded from *DEPEND? Assume a C runtime and a C compiler do exist. I would extend that to a C++ compiler and library as well. We are having yet another C++-moment (libstdc++ as usual) so it might change, please beware. lu
