What happened to OpenRC 0.9.6?
 

Am 27.11.2011 17:22, schrieb Nilesh Govindarajan:
> On Sun 27 Nov 2011 09:06:39 PM IST, Nikos Chantziaras wrote:
>> sys-apps/openrc-0.9.6 is just... gone? Not even masked, but
>> completely gone from portage.
>>
>> What happened to it?
>>
>
> 0.9.6? I updated my tree 24h before writing this reply. It's still not
> there. Only upto 0.9.4 & -9999 is masked.
>

From $PORTDIR/sys-apps/openrc/Changelog:
26 Nov 2011; William Hubbs <williamh@gentoo.org> -openrc-0.9.6.ebuild:
remove release that did not work with rc_parallel

Regards,
Florian Philipp

What happened to OpenRC 0.9.6?
 

Nilesh Govindarajan wrote:

On Sun 27 Nov 2011 09:06:39 PM IST, Nikos Chantziaras wrote:

sys-apps/openrc-0.9.6 is just... gone? Not even masked, but
completely gone from portage.

What happened to it?


0.9.6? I updated my tree 24h before writing this reply. It's still not
there. Only upto 0.9.4& -9999 is masked.



I got this in mine:

root@fireball / # equery list -p openrc
* Searching for openrc ...
[IP-] [ ] sys-apps/openrc-0.8.3-r1:0
[-P-] [ ~] sys-apps/openrc-0.9.2:0
[-P-] [ ~] sys-apps/openrc-0.9.3:0
[-P-] [ ~] sys-apps/openrc-0.9.3-r1:0
[-P-] [ ~] sys-apps/openrc-0.9.4:0
[-P-] [ ~] sys-apps/openrc-0.9.6:0
[-P-] [ -] sys-apps/openrc-9999:0
root@fireball / #

My last sync was:

Fri Nov 25 19:20:06 2011

If you need a ebuild or something, speak up soon while I still got it. :-)

Could it be that that version had a serious problem and puked on the
devs keyboard so he, or she, removed it before it messed up someone
else's keyboard? We got any female devs? :/


Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

What happened to OpenRC 0.9.6?
 

On 27/11/11 16.36, Nikos Chantziaras wrote:
> sys-apps/openrc-0.9.6 is just... gone? Not even masked, but completely
> gone from portage.
>
> What happened to it?

Last time I checked it was hardmasked. Now it's been confined into
oblivion, I hope.
It had a "little" problem in resolving the dependencies of a newly
introduced boot service that created a cycle and caused the boot process
to hang (almost) forever with rc_parallel=YES.

With 100% repeatability, mind you, which does raise same questions on
the amount of testing done before release. Yes, it's ~arch and
rc_parallel is explicitly marked "experimental", but it's not expected
to be completely and consistently broken, either.

If that sounds like I'm ranting, it's because I just spent about an hour
getting three machines affected by this problem back into working state.

If anyone still has it installed, it's time to sync and downgrade :)

andrea

What happened to OpenRC 0.9.6?
 

On Sun, 2011-11-27 at 20:28 +0100, Andrea Conti wrote:
> With 100% repeatability, mind you, which does raise same questions on
> the amount of testing done before release. Yes, it's ~arch and
> rc_parallel is explicitly marked "experimental", but it's not expected
> to be completely and consistently broken, either.
>
> If that sounds like I'm ranting, it's because I just spent about an
> hour
> getting three machines affected by this problem back into working
> state.
>
> If anyone still has it installed, it's time to sync and downgrade :)


Sorry to add more to the whining but...

Yes, you are in the testing tree. Yes, as a member of testing, *you*
expect things will occasionally break, and it is *your* job to test
things, break them, and report bugs.
>
And no, don't expect the devs to have tested something even they have
told you is "experimental" and might not always work. If you don't like
the unpredictability of testing, move to something more *stable* and
don't enable options that come with a caveat.
>

What happened to OpenRC 0.9.6?
 

On 11/28/2011 02:29 PM, Albert W. Hopkins wrote:

On Sun, 2011-11-27 at 20:28 +0100, Andrea Conti wrote:

With 100% repeatability, mind you, which does raise same questions on
the amount of testing done before release. Yes, it's ~arch and
rc_parallel is explicitly marked "experimental", but it's not expected
to be completely and consistently broken, either.

If that sounds like I'm ranting, it's because I just spent about an
hour
getting three machines affected by this problem back into working
state.

If anyone still has it installed, it's time to sync and downgrade :)


Sorry to add more to the whining but...

Yes, you are in the testing tree. Yes, as a member of testing, *you*
expect things will occasionally break, and it is *your* job to test
things, break them, and report bugs.


Generally true, but not when something is obviously broken. That means
not even its upstream dev bothered to test it.


~arch is for "we think this works, but please give it a go in case there
are problems". It's *not* for "we have no idea if this works because we
didn't even try it once".

What happened to OpenRC 0.9.6?
 

On Mon, 2011-11-28 at 18:15 +0200, Nikos Chantziaras wrote:
> Generally true, but not when something is obviously broken. That
> means
> not even its upstream dev bothered to test it.
>
> ~arch is for "we think this works, but please give it a go in case
> there
> are problems". It's *not* for "we have no idea if this works because
> we
> didn't even try it once".

You're experience is obviously different than mine. I've been using
Gentoo for many years and sometimes things in unstable don't even
compile... and it's obvious that the Gentoo developers didn't even
attempt to compile it. This is par for the course.

And you're talking about a feature that is already documented as
"probably won't work" and you're expecting them to test *that* given
that they don't even test things that are expected to work?!

Good luck with that.

What happened to OpenRC 0.9.6?
 

On Mon, 28 Nov 2011 11:31:44 -0500
"Albert W. Hopkins" <marduk@letterboxes.org> wrote:

> On Mon, 2011-11-28 at 18:15 +0200, Nikos Chantziaras wrote:
> > Generally true, but not when something is obviously broken. That
> > means
> > not even its upstream dev bothered to test it.
> >
> > ~arch is for "we think this works, but please give it a go in case
> > there
> > are problems". It's *not* for "we have no idea if this works
> > because we
> > didn't even try it once".
>
> You're experience is obviously different than mine. I've been using
> Gentoo for many years and sometimes things in unstable don't even
> compile... and it's obvious that the Gentoo developers didn't even
> attempt to compile it. This is par for the course.
>
> And you're talking about a feature that is already documented as
> "probably won't work" and you're expecting them to test *that* given
> that they don't even test things that are expected to work?!
>
> Good luck with that.

My experience is different to both of yours. I too have been using
Gentoo for many years and had good results with unstable. Hardly ever,
if even at all, have I run into packages that would not compile at


Build failures for me have always been some unusual configs on my end,
usually strange USE flags. But I don't use any of the more exotic
packages like those in sci- and games- so YMMV I guess.


--
Alan McKinnnon
alan.mckinnon@gmail.com

What happened to OpenRC 0.9.6?
 

Am 28.11.2011 17:15, schrieb Nikos Chantziaras:
> On 11/28/2011 02:29 PM, Albert W. Hopkins wrote:
>> On Sun, 2011-11-27 at 20:28 +0100, Andrea Conti wrote:
>>> With 100% repeatability, mind you, which does raise same questions on
>>> the amount of testing done before release. Yes, it's ~arch and
>>> rc_parallel is explicitly marked "experimental", but it's not expected
>>> to be completely and consistently broken, either.
>>>
>>> If that sounds like I'm ranting, it's because I just spent about an
>>> hour
>>> getting three machines affected by this problem back into working
>>> state.
>>>
>>> If anyone still has it installed, it's time to sync and downgrade :)
>>
>> Sorry to add more to the whining but...
>>
>> Yes, you are in the testing tree. Yes, as a member of testing, *you*
>> expect things will occasionally break, and it is *your* job to test
>> things, break them, and report bugs.
>
> Generally true, but not when something is obviously broken. That means
> not even its upstream dev bothered to test it.
>
> ~arch is for "we think this works, but please give it a go in case there
> are problems". It's *not* for "we have no idea if this works because we
> didn't even try it once".
>
>

Do you have any idea how much time you can spend with the kind of system
testing you propose? Most companies don't do what you expect from
part-time devs. You either have provide means to automate it or
outsource it with very cheap labor. Otherwise it will never be done
(talking from experience here).

However, "dev labor" is expensive since it is limited and better spent
on other issues. Automating tests for a reasonable subset of openrc's
parameter space is also a tricky issue. Therefore you have to resort to
cheap voluntarily provided "user labor" by means of ~arch.

And it worked, didn't it? You found a bug before it entered stable. Now
give yourself a pat on the shoulder for your accomplishment and go back
to stable if you value your time so high that you don't want to chase bugs.

Regards,
Florian Philipp

What happened to OpenRC 0.9.6?
 

On 2011-11-28, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> "Albert W. Hopkins" <marduk@letterboxes.org> wrote:
>> On Mon, 2011-11-28 at 18:15 +0200, Nikos Chantziaras wrote:
>>
>>> Generally true, but not when something is obviously broken. That
>>> means not even its upstream dev bothered to test it.
>>>
>>> ~arch is for "we think this works, but please give it a go in case
>>> there are problems". It's *not* for "we have no idea if this works
>>> because we didn't even try it once".
>>
>> You're experience is obviously different than mine. I've been using
>> Gentoo for many years and sometimes things in unstable don't even
>> compile... and it's obvious that the Gentoo developers didn't even
>> attempt to compile it.

I don't think that's fair. Perhaps nobody had compiled it using the
exact set of USE flags and the exast set of library versions and
configurations you were using, but I've never seen anything appear in
testing that was so broken it could be said that nobody had ever tried
to build it.

>> This is par for the course.
>>
>> And you're talking about a feature that is already documented as
>> "probably won't work" and you're expecting them to test *that* given
>> that they don't even test things that are expected to work?!
>>
>> Good luck with that.
>
> My experience is different to both of yours. I too have been using
> Gentoo for many years and had good results with unstable. Hardly ever,
> if even at all, have I run into packages that would not compile at
>
> Build failures for me have always been some unusual configs on my end,
> usually strange USE flags. But I don't use any of the more exotic
> packages like those in sci- and games- so YMMV I guess.

I've been running Gentoo for 5-6 years on multiple machines, and there
have been a couple occasions when a testing version of something
didn't build because it wasn't compatible with the testing version of
something else with a particular set of USE flags. Generally I would
just switch back to stable for the packages involved, since whatever
feature/fix that had prompted the switch to testing had long since
made it into the stable version. Other times, just waiting a day or
two and trying again would fix the problem.

--
Grant Edwards grant.b.edwards Yow! It's a hole all the
at way to downtown Burbank!
gmail.com

What happened to OpenRC 0.9.6?
 

On Mon, 2011-11-28 at 18:41 +0200, Alan McKinnon wrote:
> My experience is different to both of yours. I too have been using
> Gentoo for many years and had good results with unstable. Hardly ever,
> if even at all, have I run into packages that would not compile at
> Build failures for me have always been some unusual configs on my end,
> usually strange USE flags. But I don't use any of the more exotic
> packages like those in sci- and games- so YMMV I guess.

I'm not saying that unstable is somehow bad, I'm just saying it's
sometimes... unstable.

I dont' have any "exotic" packages or configs either, but I do from time
to time encounter such problems as

1. Patches not included
2. Patches not applying
3. build failures because a patch in a previous revision is no
longer applicable in the new revision
4. build failures caused by upstream issues
5. build failures due bad ebuilds
6. incomplete DEPENDS or RDEPENDS(this actually happens quite more
frequently than i'd like)
7. Broken functionality (upstream bugs)
8. A dependency of a package was bumped, and that package doesn't
build against the bump.

Granted, when I test, I test hard. I depclean with build time
dependencies removed, to make sure packages have the correct DEPENDS. I
do an "emerge -e world" about once per month. I have a build system
that builds virtual appliances from scratch that help me find bugs
(granted, most of these VMs are in the stable tree so they actually find
bugs in stable and the stage3 tarballs). I set USE flags manually
instead of using the defaults. So, while that may be considered an
"unusual config" it should work and it helps me find bugs before they
get into stable.

But my feeling is, if you use the testing branch and you *don't* find
bugs, then you aren't testing hard enough :P


-a