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

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-11-2012, 06:06 PM
Alexis Ballier
 
Default gentoo-x86 commit in profiles: ChangeLog profiles.desc

On Tue, 28 Aug 2012 00:23:11 +0000 (UTC)
"Mike Frysinger (vapier)" <vapier@gentoo.org> wrote:

> vapier 12/08/28 00:23:11
>
> Modified: ChangeLog profiles.desc
> Log:
> add new s390x profile #345421

[...]

> @@ -152,7 +153,7 @@
> x86 default/linux/x86/10.0/server
> stable
> # Gentoo/FreeBSD Profiles
> -amd64-fbsd default/bsd/fbsd/amd64/9.0 stable
> +amd64-fbsd default/bsd/fbsd/amd64/9.0 dev
> sparc-fbsd default/bsd/fbsd/sparc/8.2 exp
> x86-fbsd default/bsd/fbsd/x86/8.2 dev
> x86-fbsd default/bsd/fbsd/x86/9.0 dev

please be more careful, it is good practice to review the cvs diff output before hitting ci when committing to the profiles or eclass directories.

A.
 
Old 09-15-2012, 10:47 PM
Mike Frysinger
 
Default gentoo-x86 commit in profiles: ChangeLog profiles.desc

On Tuesday 11 September 2012 14:06:30 Alexis Ballier wrote:
> On Tue, 28 Aug 2012 00:23:11 +0000 (UTC) Mike Frysinger wrote:
> > vapier 12/08/28 00:23:11
> >
> > Modified: ChangeLog profiles.desc
> > Log:
> > add new s390x profile #345421
>
> [...]
>
> > @@ -152,7 +153,7 @@
> >
> > x86 default/linux/x86/10.0/server
> >
> > stable
> >
> > # Gentoo/FreeBSD Profiles
> >
> > -amd64-fbsd default/bsd/fbsd/amd64/9.0 stable
> > +amd64-fbsd default/bsd/fbsd/amd64/9.0 dev
> > sparc-fbsd default/bsd/fbsd/sparc/8.2 exp
> > x86-fbsd default/bsd/fbsd/x86/8.2 dev
> > x86-fbsd default/bsd/fbsd/x86/9.0 dev
>
> please be more careful, it is good practice to review the cvs diff output
> before hitting ci when committing to the profiles or eclass directories.

that was only partially an accident. amd64-fbsd has no business being in
stable since it has broken deps and has no stable keywords.
-mike
 
Old 09-16-2012, 03:01 PM
Alexis Ballier
 
Default gentoo-x86 commit in profiles: ChangeLog profiles.desc

On Sat, 15 Sep 2012 18:47:56 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Tuesday 11 September 2012 14:06:30 Alexis Ballier wrote:
> > On Tue, 28 Aug 2012 00:23:11 +0000 (UTC) Mike Frysinger wrote:
> > > vapier 12/08/28 00:23:11
> > >
> > > Modified: ChangeLog profiles.desc
> > > Log:
> > > add new s390x profile #345421
> >
> > [...]
> >
> > > @@ -152,7 +153,7 @@
> > >
> > > x86 default/linux/x86/10.0/server
> > >
> > > stable
> > >
> > > # Gentoo/FreeBSD Profiles
> > >
> > > -amd64-fbsd default/bsd/fbsd/amd64/9.0 stable
> > > +amd64-fbsd default/bsd/fbsd/amd64/9.0 dev
> > > sparc-fbsd default/bsd/fbsd/sparc/8.2 exp
> > > x86-fbsd default/bsd/fbsd/x86/8.2 dev
> > > x86-fbsd default/bsd/fbsd/x86/9.0 dev
> >
> > please be more careful, it is good practice to review the cvs diff
> > output before hitting ci when committing to the profiles or eclass
> > directories.
>
> that was only partially an accident. amd64-fbsd has no business
> being in stable since it has broken deps and has no stable keywords.

search the archives as for why its stable. profile not being stable
is the cause for broken deps, not the consequence...
also, where does your idea stable profile == stable keywords come
from ? if you want them to be the same, you need to invent something
that would make repoman checks fatals for broken deps rather than
displaying non fatal warnings that nobody ever reads because it needs
-d.

also, you are missing some bug # for the 'broken deps' part. packages
that have gained broken deps when the profile was marked 'dev', or that
you committed with your profile.desc locally modified, do not count and
are your fault actually...
 
Old 09-17-2012, 02:06 AM
Mike Frysinger
 
Default gentoo-x86 commit in profiles: ChangeLog profiles.desc

On Sunday 16 September 2012 11:01:00 Alexis Ballier wrote:
> also, you are missing some bug # for the 'broken deps' part. packages
> that have gained broken deps when the profile was marked 'dev', or that
> you committed with your profile.desc locally modified, do not count and
> are your fault actually...

wrong. if i'm version bumping a package and i see broken amd64-fbsd deps,
that is not my problem. sounds like i'll simply de-keyword it in the future
and let someone else pick up the pieces.

do a repoman on the tree. there are multiple packages coming back right now
with broken amd64-fbsd deps.
-mike
 
Old 09-17-2012, 12:22 PM
Alexis Ballier
 
Default gentoo-x86 commit in profiles: ChangeLog profiles.desc

On Sun, 16 Sep 2012 22:06:19 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Sunday 16 September 2012 11:01:00 Alexis Ballier wrote:
> > also, you are missing some bug # for the 'broken deps' part.
> > packages that have gained broken deps when the profile was marked
> > 'dev', or that you committed with your profile.desc locally
> > modified, do not count and are your fault actually...
>
> wrong. if i'm version bumping a package and i see broken amd64-fbsd
> deps, that is not my problem. sounds like i'll simply de-keyword it
> in the future and let someone else pick up the pieces.

why do you want to treat amd64-fbsd different than other arches ?
just to make the work of those that want to maintain that arch a pain ?

you know, standard procedure is to drop keywords and file a bug when a
new dep comes in a new version. deps that are _already_ broken should
not happen because, heh, the profile is marked stable... in case this
happens there's nothing sane to do, better use repoman --force and file
an urgent bug to the arch team.

> do a repoman on the tree. there are multiple packages coming back
> right now with broken amd64-fbsd deps.

if people do not file bugs and think it's fine to commit packages with
broken deps, or silently dekeyword just because they can like you
suggested in the first paragraph, this will not change anytime soon.

and no thanks, i wont be doing repoman checks on the tree, i had been
doing this for x86-fbsd, spending hours fixing the mess i could, and had
to re-do it every couple of months because every other dev was
committing packages with broken deps.

now, would you please file bugs when you see such broken packages and
let the keywording level be sanitized ? thanks
 
Old 09-17-2012, 02:57 PM
Alexis Ballier
 
Default gentoo-x86 commit in profiles: ChangeLog profiles.desc

On Sun, 16 Sep 2012 22:06:19 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Sunday 16 September 2012 11:01:00 Alexis Ballier wrote:
> > also, you are missing some bug # for the 'broken deps' part.
> > packages that have gained broken deps when the profile was marked
> > 'dev', or that you committed with your profile.desc locally
> > modified, do not count and are your fault actually...
>
> wrong. if i'm version bumping a package and i see broken amd64-fbsd
> deps, that is not my problem. sounds like i'll simply de-keyword it
> in the future and let someone else pick up the pieces.
>
> do a repoman on the tree. there are multiple packages coming back
> right now with broken amd64-fbsd deps.

now that the repoman run has finished, lets analyze it:

dev-vcs/git/git-1.7.12-r2.ebuild:
~amd64-fbsd(default/bsd/fbsd/amd64/9.0) ['app-text/highlight']
x11-base/xorg-drivers/xorg-drivers-1.13.ebuild:
~amd64-fbsd(default/bsd/fbsd/amd64/9.0)
['x11-drivers/xf86-video-chips', 'x11-drivers/xf86-video-rendition',
'x11-drivers/xf86-video-tseng']

both added and unnoticed when the profile was marked as dev

net-misc/wget/wget-1.14.ebuild: ~amd64-fbsd(default/bsd/fbsd/amd64/9.0)
['sys-apps/util-linux']

bumped by you, earlier, probably when you made your local change.
util-_linux_ not being keyworded on fbsd is not what I would call a
broken dep. uuid functions are provided by either e2fsprogs-libs or the
libc on freebsd. maybe it would be a good idea to drop keywords and ask
for rekeywording to the arch team in that case ?
 
Old 09-19-2012, 05:38 AM
Mike Frysinger
 
Default gentoo-x86 commit in profiles: ChangeLog profiles.desc

On Monday 17 September 2012 08:22:50 Alexis Ballier wrote:
> On Sun, 16 Sep 2012 22:06:19 -0400 Mike Frysinger wrote:
> > On Sunday 16 September 2012 11:01:00 Alexis Ballier wrote:
> > > also, you are missing some bug # for the 'broken deps' part.
> > > packages that have gained broken deps when the profile was marked
> > > 'dev', or that you committed with your profile.desc locally
> > > modified, do not count and are your fault actually...
> >
> > wrong. if i'm version bumping a package and i see broken amd64-fbsd
> > deps, that is not my problem. sounds like i'll simply de-keyword it
> > in the future and let someone else pick up the pieces.
>
> why do you want to treat amd64-fbsd different than other arches ?

atm, i see amd64-fbsd as a toy arch that is impacting more negatively than it
is positively. i don't know of anyone using it for real work. it doesn't
have the large KEYWORDS deployment yet to not make it obnoxious for simple
things.

> just to make the work of those that want to maintain that arch a pain ?

this is why i've kept some arches which are not large in dev profiles -- so
that when a new dep does come up, other devs aren't blocked. i've also
communicated in the past that they should feel free to drop the keyword & file
a bug later so that they aren't hung up on work they're focusing on.

> > do a repoman on the tree. there are multiple packages coming back
> > right now with broken amd64-fbsd deps.
>
> if people do not file bugs and think it's fine to commit packages with
> broken deps, or silently dekeyword just because they can like you
> suggested in the first paragraph, this will not change anytime soon.
>
> and no thanks, i wont be doing repoman checks on the tree, i had been
> doing this for x86-fbsd, spending hours fixing the mess i could, and had
> to re-do it every couple of months because every other dev was
> committing packages with broken deps.

except amd64-fbsd is no longer just a dev profile like x86-fbsd which means
those broken deps are messing people up. people who had nothing to do with
the breakage in the first place.
-mike
 
Old 09-19-2012, 05:40 AM
Mike Frysinger
 
Default gentoo-x86 commit in profiles: ChangeLog profiles.desc

On Monday 17 September 2012 10:57:50 Alexis Ballier wrote:
> net-misc/wget/wget-1.14.ebuild: ~amd64-fbsd(default/bsd/fbsd/amd64/9.0)
> ['sys-apps/util-linux']
>
> bumped by you, earlier, probably when you made your local change.
> util-_linux_

except it isn't linux specific. if you follow upstream, you'll see that people
are constantly making sure that it is possible to build it on non-linux
systems.

> uuid functions are provided by either e2fsprogs-libs or the
> libc on freebsd.

e2fsprogs-libs hasn't provided libuuid in a long time. that those are still
in the tree is part laziness. relying on it to provide libuuid isn't going to
work.
-mike
 
Old 09-19-2012, 12:07 PM
Alexis Ballier
 
Default gentoo-x86 commit in profiles: ChangeLog profiles.desc

On Wed, 19 Sep 2012 01:40:42 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Monday 17 September 2012 10:57:50 Alexis Ballier wrote:
> > net-misc/wget/wget-1.14.ebuild:
> > ~amd64-fbsd(default/bsd/fbsd/amd64/9.0) ['sys-apps/util-linux']
> >
> > bumped by you, earlier, probably when you made your local change.
> > util-_linux_
>
> except it isn't linux specific. if you follow upstream, you'll see
> that people are constantly making sure that it is possible to build
> it on non-linux systems.

well, I've never been able to build it.

>
> > uuid functions are provided by either e2fsprogs-libs or the
> > libc on freebsd.
>
> e2fsprogs-libs hasn't provided libuuid in a long time. that those
> are still in the tree is part laziness. relying on it to provide
> libuuid isn't going to work.

i know, the libc ones should be used. libuuid, whereever it comes from,
will always only be used during a transition period while the package is
getting fixed to use the libc ones.
 
Old 09-19-2012, 12:14 PM
Alexis Ballier
 
Default gentoo-x86 commit in profiles: ChangeLog profiles.desc

On Wed, 19 Sep 2012 01:38:51 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Monday 17 September 2012 08:22:50 Alexis Ballier wrote:
> > On Sun, 16 Sep 2012 22:06:19 -0400 Mike Frysinger wrote:
> > > On Sunday 16 September 2012 11:01:00 Alexis Ballier wrote:
> > > > also, you are missing some bug # for the 'broken deps' part.
> > > > packages that have gained broken deps when the profile was
> > > > marked 'dev', or that you committed with your profile.desc
> > > > locally modified, do not count and are your fault actually...
> > >
> > > wrong. if i'm version bumping a package and i see broken
> > > amd64-fbsd deps, that is not my problem. sounds like i'll simply
> > > de-keyword it in the future and let someone else pick up the
> > > pieces.
> >
> > why do you want to treat amd64-fbsd different than other arches ?
>
> atm, i see amd64-fbsd as a toy arch that is impacting more negatively
> than it is positively.

negatively ?

[...]
> > just to make the work of those that want to maintain that arch a
> > pain ?
>
> this is why i've kept some arches which are not large in dev profiles
> -- so that when a new dep does come up, other devs aren't blocked.
> i've also communicated in the past that they should feel free to drop
> the keyword & file a bug later so that they aren't hung up on work
> they're focusing on.

your choice, the same choice was made for x86-fbsd; however, after
years, i dont think that choice was wise and dont want to repeat the
mistakes.

>
> > > do a repoman on the tree. there are multiple packages coming back
> > > right now with broken amd64-fbsd deps.
> >
> > if people do not file bugs and think it's fine to commit packages
> > with broken deps, or silently dekeyword just because they can like
> > you suggested in the first paragraph, this will not change anytime
> > soon.
> >
> > and no thanks, i wont be doing repoman checks on the tree, i had
> > been doing this for x86-fbsd, spending hours fixing the mess i
> > could, and had to re-do it every couple of months because every
> > other dev was committing packages with broken deps.
>
> except amd64-fbsd is no longer just a dev profile like x86-fbsd which
> means those broken deps are messing people up. people who had
> nothing to do with the breakage in the first place.

you are missing the point here: amd64-fbsd has *never* been a dev
profile. nobody should *ever* have committed something with broken deps.
except because of the commit that started that thread.
 

Thread Tools




All times are GMT. The time now is 12:43 PM.

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