FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 09-11-2010, 06:51 PM
justin
 
Default Closing bugs

Hi all,

is the following comment an adequate way to close bugs with
RESOLVED/INVALID? If so, I will change the way I handle bugs and use it too.

""
virtual/os-headers: 2.6.35 (sys-kernel/linux-headers)
ACCEPT_KEYWORDS="amd64"

you mix stable & unstable -> your problem
""

Cheers Justin
 
Old 09-11-2010, 07:00 PM
"Paweł Hajdan, Jr."
 
Default Closing bugs

On 9/11/10 11:51 AM, justin wrote:
> is the following comment an adequate way to close bugs with
> RESOLVED/INVALID? If so, I will change the way I handle bugs and use it too.
>
> ""
> virtual/os-headers: 2.6.35 (sys-kernel/linux-headers)
> ACCEPT_KEYWORDS="amd64"
>
> you mix stable & unstable -> your problem
> ""

I think that closing as INVALID is fine in that case, but would say
"please do not mix stable and unstable" instead of "your problem".

We should be polite when handling bugs.

Paweł
 
Old 09-11-2010, 07:04 PM
Petteri Rty
 
Default Closing bugs

On 09/11/2010 09:51 PM, justin wrote:
> Hi all,
>
> is the following comment an adequate way to close bugs with
> RESOLVED/INVALID? If so, I will change the way I handle bugs and use it too.
>
> ""
> virtual/os-headers: 2.6.35 (sys-kernel/linux-headers)
> ACCEPT_KEYWORDS="amd64"
>
> you mix stable & unstable -> your problem
> ""
>

Only if the problem will not eventually manifest itself with a pure
~arch or arch setup. Even then if it's easy to fix I would myself fix it
although we don't officially support it.

Regards,
Petteri
 
Old 09-11-2010, 07:04 PM
Ciaran McCreesh
 
Default Closing bugs

On Sat, 11 Sep 2010 20:51:56 +0200
justin <jlec@gentoo.org> wrote:
> is the following comment an adequate way to close bugs with
> RESOLVED/INVALID? If so, I will change the way I handle bugs and use
> it too.
>
> ""
> virtual/os-headers: 2.6.35 (sys-kernel/linux-headers)
> ACCEPT_KEYWORDS="amd64"
>
> you mix stable & unstable -> your problem

Would the problem also occur if the user used unstable, but hadn't
gotten around to updating every single package on their system all in
one go?

Or does the problem only occur if you mix keywords and ignore
dependencies?

--
Ciaran McCreesh
 
Old 09-11-2010, 07:09 PM
Maciej Mrozowski
 
Default Closing bugs

On Saturday 11 of September 2010 20:51:56 justin wrote:
> Hi all,
>
> is the following comment an adequate way to close bugs with
> RESOLVED/INVALID? If so, I will change the way I handle bugs and use it
> too.
>
> ""
> virtual/os-headers: 2.6.35 (sys-kernel/linux-headers)
> ACCEPT_KEYWORDS="amd64"
>
> you mix stable & unstable -> your problem
> ""

This is common misconception.

Let me quote myself from on of Diego's blogs, accusing me of not giving a crap
about quality wrt FEATURES=test.

Some people say that mixing testing and stable subtrees is ‘broken’ and not
supported.

It is because they apparently have no idea how package stabilization process
works.

‘tinderbox’ idea of full ~arch integration tests is broken by design!

Why? Gentoo is distribution with rolling updates and packages being stabilized
are hand picked from ~arch and integrated within existing stable environment
(along with possible dependencies).

Now the question arises – since Gentoo stable is our ultimate target release
(and not ~arch) - what is the point in testing how these packages interact
with full testing ~arch? The answer is NONE!

If any, following tests should be run:

- regression tests – ONLY within full stable arch, typical tinderbox of just
chroot would fit there well, it could prevent issues like Gentoo LiveCD
autobuilds failing since 8 April…

- integration tests – in similar way stabilization process is performed:
stable system as a base, picking packages or package sets for tests along with
their possible dependencies (best version visible, if not visible within
stable arch, then best visible within testing arch or some other algorithm,
usually just relying on ebuild dependencies) and testing whether it works so
that stabilization process is a formality.

Running ~arch as 'test' platform is in many cases counter productive.

--
regards
MM
 
Old 09-11-2010, 07:22 PM
Richard Freeman
 
Default Closing bugs

On 09/11/2010 03:04 PM, Ciaran McCreesh wrote:

Or does the problem only occur if you mix keywords and ignore
dependencies?



I think that if a package doesn't work in a mixed environment, that
points to a likely dependency problem. Sooner or later there is a good
chance it will bite somebody.


Personally, I try to keep package dependencies correct. If a package in
unstable needs a library version in unstable, I depend on that version -
not on the library itself. Then we won't get burned in six months when
I forget all about this or am not around and things start going stable
in the wrong order.


Sure, if the issue is something really exotic maybe we should just say
"don't do that," but usually there is a better fix.


Personally I welcome these kinds of bugs, as they're the easiest way to
uncover non-obvious dependency issues that might otherwise make their
way into stable. Maybe we can't fix them all, but we ought not to just
dismiss them out of hand. I certainly wouldn't want to see the
bug-wranglers screening for them, for instance.


Rich
 
Old 09-12-2010, 02:51 AM
Ryan Hill
 
Default Closing bugs

On Sun, 12 Sep 2010 20:59:25 +1200
Alistair Bush <ali_bush@gentoo.org> wrote:


> There should be nothing stopping a user from running a mixed arch/~arch
> system. Those problems just point to our dependency information not being
> recorded correctly. It might be understandable that this info can be
> incredibly hard to get correct but that doesn't mean it isn't a valid bug.

It's invalid as soon as you bring system-set packages into the mix, which
falls outside of dependency correctness.

The trouble is knowing if this applies in the situation you're looking into.


--
fonts, gcc-porting, we hold our breath, we spin around the world
toolchain, wxwidgets you and me cling to the outside of the earth
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 
Old 09-12-2010, 03:29 AM
Mike Frysinger
 
Default Closing bugs

On Saturday, September 11, 2010 15:04:45 Ciaran McCreesh wrote:
> On Sat, 11 Sep 2010 20:51:56 +0200 justin wrote:
> > is the following comment an adequate way to close bugs with
> > RESOLVED/INVALID? If so, I will change the way I handle bugs and use
> > it too.
> >
> > ""
> > virtual/os-headers: 2.6.35 (sys-kernel/linux-headers)
> > ACCEPT_KEYWORDS="amd64"
> >
> > you mix stable & unstable -> your problem
>
> Would the problem also occur if the user used unstable, but hadn't
> gotten around to updating every single package on their system all in
> one go?

no
-mike
 
Old 09-12-2010, 04:17 AM
Mike Frysinger
 
Default Closing bugs

On Saturday, September 11, 2010 22:51:23 Ryan Hill wrote:
> On Sun, 12 Sep 2010 20:59:25 +1200 Alistair Bush wrote:
> > There should be nothing stopping a user from running a mixed arch/~arch
> > system. Those problems just point to our dependency information not
> > being recorded correctly. It might be understandable that this info
> > can be incredibly hard to get correct but that doesn't mean it isn't a
> > valid bug.
>
> It's invalid as soon as you bring system-set packages into the mix, which
> falls outside of dependency correctness.
>
> The trouble is knowing if this applies in the situation you're looking
> into.

indeed. for people who disagree, feel free to go through every single stable
package in the tree that breaks with glibc-2.12, or linux-headers-2.6.35, or
make-3.82, or xxx and add a blocker against the newer versions of these
packages. and then do it every time we get a new version.

or, let's keep our sanity and continue doing what we've been doing over the
years -- stabilize newer versions of packages that do work with the stable &
unstable versions of the packages they build against.

people who install unstable core system packages way before we're interested
in stabilizing and then file bugs that only apply to stable get INVALID->their
problem. especially when a simple bugzilla search would have told them that
their issue is already fixed in the unstable version of whatever package is
failing for them.
-mike
 
Old 09-12-2010, 08:59 AM
Alistair Bush
 
Default Closing bugs

> On 09/11/2010 03:04 PM, Ciaran McCreesh wrote:
> > Or does the problem only occur if you mix keywords and ignore
> > dependencies?
>
> I think that if a package doesn't work in a mixed environment, that
> points to a likely dependency problem. Sooner or later there is a good
> chance it will bite somebody.
>
> Personally, I try to keep package dependencies correct. If a package in
> unstable needs a library version in unstable, I depend on that version -
> not on the library itself. Then we won't get burned in six months when
> I forget all about this or am not around and things start going stable
> in the wrong order.
>
> Sure, if the issue is something really exotic maybe we should just say
> "don't do that," but usually there is a better fix.
>
> Personally I welcome these kinds of bugs, as they're the easiest way to
> uncover non-obvious dependency issues that might otherwise make their
> way into stable. Maybe we can't fix them all, but we ought not to just
> dismiss them out of hand. I certainly wouldn't want to see the
> bug-wranglers screening for them, for instance.
>
> Rich

++

There should be nothing stopping a user from running a mixed arch/~arch
system. Those problems just point to our dependency information not being
recorded correctly. It might be understandable that this info can be
incredibly hard to get correct but that doesn't mean it isn't a valid bug.

- Alistair
 

Thread Tools




All times are GMT. The time now is 03:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org