Not sure if this is practical, it may be less work if the use of
Python and Ruby versions ( maybe others ) is reversed. Rather than
adding all the versions that the ebuild supports. What if it only
included versions it did not support?
Rational
When new versions are added. Ebuilds must be updated
On 09/04/2017 18:15, William L. Thomson Jr. wrote:
Not sure if this is practical, it may be less work if the use of
Python and Ruby versions ( maybe others ) is reversed. Rather than
adding all the versions that the ebuild supports. What if it only
included versions it did not support?
Rational
On 04/09/2017 06:15 PM, William L. Thomson Jr. wrote:
> Not sure if this is practical, it may be less work if the use of
> Python and Ruby versions ( maybe others ) is reversed. Rather than
> adding all the versions that the ebuild supports. What if it only
> included versions it did not support?
On 04/09/2017 12:15 PM, William L. Thomson Jr. wrote:
Not sure if this is practical, it may be less work if the use of
Python and Ruby versions ( maybe others ) is reversed. Rather than
adding all the versions that the ebuild supports. What if it only
included versions it did not support?
Even
On Sun, 9 Apr 2017 23:36:18 +0200
Francesco Riosa wrote:
> On 09/04/2017 18:15, William L. Thomson Jr. wrote:
> > Not sure if this is practical, it may be less work if the use of
> > Python and Ruby versions ( maybe others ) is reversed. Rather than
> > adding all the versions that the ebuild sup
On 09/04/2017 23:44, Kristian Fiskerstrand wrote:
On 04/09/2017 06:15 PM, William L. Thomson Jr. wrote:
Not sure if this is practical, it may be less work if the use of
Python and Ruby versions ( maybe others ) is reversed. Rather than
adding all the versions that the ebuild supports. What if
On Sun, 9 Apr 2017 17:52:44 -0400
Michael Orlitzky wrote:
> On 04/09/2017 12:15 PM, William L. Thomson Jr. wrote:
> > Not sure if this is practical, it may be less work if the use of
> > Python and Ruby versions ( maybe others ) is reversed. Rather than
> > adding all the versions that the ebuild
On 09/04/2017 23:52, Michael Orlitzky wrote:
On 04/09/2017 12:15 PM, William L. Thomson Jr. wrote:
Not sure if this is practical, it may be less work if the use of
Python and Ruby versions ( maybe others ) is reversed. Rather than
adding all the versions that the ebuild supports. What if it on
On 10/04/2017 00:20, Brian Dolbec wrote:
On Sun, 9 Apr 2017 23:36:18 +0200
Francesco Riosa wrote:
On 09/04/2017 18:15, William L. Thomson Jr. wrote:
Not sure if this is practical, it may be less work if the use of
Python and Ruby versions ( maybe others ) is reversed. Rather than
adding all
On Sun, 9 Apr 2017 12:15:56 -0400
"William L. Thomson Jr." wrote:
> Python 2.7 stuff aside. I am not sure how many Python and Ruby packages
> break with a newer release. In pythons case I think once they support
> Python 3.x, there is little chance if it breaking with further 3.x
> releases. Not
On Sun, 9 Apr 2017 23:44:50 +0200
Kristian Fiskerstrand wrote:
> On 04/09/2017 06:15 PM, William L. Thomson Jr. wrote:
> > Not sure if this is practical, it may be less work if the use of
> > Python and Ruby versions ( maybe others ) is reversed. Rather than
> > adding all the versions that the e
On Sun, 9 Apr 2017 15:20:02 -0700
Brian Dolbec wrote:
>
> This could be partially automated using buildbot. The easiest would
> be for pkgs containing working test suites. Those that pass could be
> auto-enabled with that python with ~arch keywords. I think if a
> stable pkg is to be added the
On 04/09/2017 07:15 PM, William L. Thomson Jr. wrote:
If the package failed, all that would need to be done kinda like now is
a given variable modified in the ebuild. Just marking what ever it did
not work with. As mentioned that could be done via my
ebuild-batcher[1], though same functionality
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2017-04-09 23:59 UTC.
Removals:
app-misc/ofl 20170404-16:43 mattst88 acf50dc1d27
dev-ruby/ruby-webkit-gtk 20170405-10:10 mgorny 9f79870f533
dev-ruby/ruby-webkit-gtk2
On 10/04/2017 01:59, Michael Orlitzky wrote:
On 04/09/2017 07:15 PM, William L. Thomson Jr. wrote:
If the package failed, all that would need to be done kinda like now is
a given variable modified in the ebuild. Just marking what ever it did
not work with. As mentioned that could be done via
On Sun, 9 Apr 2017 19:59:22 -0400
Michael Orlitzky wrote:
>
> How do you plan to test a thousand packages against the new version
> of python, and then revision/stabilize all of the broken ones
> immediately? Or is the plan to just break everyone's systems, and ask
> them to report bugs for the th
On Sun, 9 Apr 2017 12:15:56 -0400
"William L. Thomson Jr." wrote:
>
> The approach mentioned above, if the packages do not have issue. I
> could go ahead and switch to ruby24 and pyton 3.6 across the board.
> Which I cannot do now till a bunch of ebulids have their targets
> increased.
>
This
On Mon, 10 Apr 2017 13:38:58 +1200
Kent Fredric wrote:
>
> When you reverse this, you introduce a situation where adding a new
> version across the board creates a new skeleton-tree of support.
FYI, this is how it is when a new Java JDK comes out. When 1.5 came
out, if 1.4 code had issues compili
On Sun, 9 Apr 2017 22:04:13 -0400
"William L. Thomson Jr." wrote:
> This has never been the case with Java.
Its not a problem with C binaries either, because you have a discrete
compile time, and language level interop between compiled binary forms.
Meanwhile, you cannot build two parts of a gi
On Mon, 2017-04-10 at 00:04 +0100, James Le Cuirot wrote:
> People thought the sky would fall when 2.4 deprecated Fixnum
> and
> Bignum. It really didn't. It's still just a warning right now but I
> haven't seen that warning since it was dealt with in Rails.
>
This change broke the rspec test sui
Dnia 9 kwietnia 2017 18:15:56 CEST, "William L. Thomson Jr."
napisał(a):
>Not sure if this is practical, it may be less work if the use of
>Python and Ruby versions ( maybe others ) is reversed. Rather than
>adding all the versions that the ebuild supports. What if it only
>included versions it d
21 matches
Mail list logo
