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.
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.
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. An
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.opensu
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 goo
-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
>> a
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 k
remember: this requires >=linux-2.6.32
-mike
signature.asc
Description: Digital signature
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 eb
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 n
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
-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
ZW5wZ3AuZmlm
-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
iQJ8BA
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 r
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 "${@}"; }
>>
>
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 l
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 mechani
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(
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_einsta
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 defini
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_libd
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 no
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
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 proc
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
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
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). How
-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 on
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
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 no
> 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
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
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.
>
33 matches
Mail list logo
