[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

[Alexis Ballier]

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.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 983 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

[Alexis Ballier]

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...

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 631 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

[Alexis Ballier]

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

[Alexis Ballier]

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 ?

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 2163 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 680 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

[Alexis Ballier]

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.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

[Alexis Ballier]

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.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

[Alexis Ballier]

On Mon,  7 Jan 2013 00:02:33 +0000 (UTC)
"Mike Frysinger (vapier)" <vapier@gentoo.org> wrote:
[...]
> +  07 Jan 2013; Mike Frysinger <vapier@gentoo.org> profiles.desc:
> +  Mark s390 profiles stable.
> +
>    06 Jan 2013; Justin Bronder <jsbronder@gentoo.org> package.mask:
>    Remove net-nntp/sabnzbd mask, fix already released and updated in
> tree. 
[...]
> --- profiles.desc	3 Jan 2013 16:08:06 -0000	1.201
> +++ profiles.desc	7 Jan 2013 00:02:32 -0000	1.202
> @@ -122,10 +122,10 @@
>  ppc64
> default/linux/powerpc/ppc64/10.0/64bit-userland/server          dev 
>  # S390 Profiles
> -s390            default/linux/s390/10.0                         dev
> -s390            default/linux/s390/10.0/s390x                   dev
> -s390            default/linux/s390/10.0/server                  dev
> -s390            default/linux/s390/10.0/server/s390x            dev
> +s390            default/linux/s390/10.0
> stable +s390
> default/linux/s390/10.0/s390x                   stable
> +s390            default/linux/s390/10.0/server
> stable +s390
> default/linux/s390/10.0/server/s390x            stable # SH Profiles
>  sh              default/linux/sh/10.0                           dev
> 

please run 'repoman full | grep s390' on gentoo-x86 and fix the broken
deps, they are now errors and I just hit one:

 dependency.bad                16
   app-text/texlive-core/texlive-core-2011-r6.ebuild: DEPEND:
   s390(default/linux/s390/13.0) ['media-libs/silgraphite']


A.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

[Matt Turner]

On Tue, Feb 19, 2013 at 7:19 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Mon,  7 Jan 2013 00:02:33 +0000 (UTC)
> "Mike Frysinger (vapier)" <vapier@gentoo.org> wrote:
> [...]
>> +  07 Jan 2013; Mike Frysinger <vapier@gentoo.org> profiles.desc:
>> +  Mark s390 profiles stable.
>> +
>>    06 Jan 2013; Justin Bronder <jsbronder@gentoo.org> package.mask:
>>    Remove net-nntp/sabnzbd mask, fix already released and updated in
>> tree.
> [...]
>> --- profiles.desc     3 Jan 2013 16:08:06 -0000       1.201
>> +++ profiles.desc     7 Jan 2013 00:02:32 -0000       1.202
>> @@ -122,10 +122,10 @@
>>  ppc64
>> default/linux/powerpc/ppc64/10.0/64bit-userland/server          dev
>>  # S390 Profiles
>> -s390            default/linux/s390/10.0                         dev
>> -s390            default/linux/s390/10.0/s390x                   dev
>> -s390            default/linux/s390/10.0/server                  dev
>> -s390            default/linux/s390/10.0/server/s390x            dev
>> +s390            default/linux/s390/10.0
>> stable +s390
>> default/linux/s390/10.0/s390x                   stable
>> +s390            default/linux/s390/10.0/server
>> stable +s390
>> default/linux/s390/10.0/server/s390x            stable # SH Profiles
>>  sh              default/linux/sh/10.0                           dev
>>
>
> please run 'repoman full | grep s390' on gentoo-x86 and fix the broken
> deps, they are now errors and I just hit one:
>
>  dependency.bad                16
>    app-text/texlive-core/texlive-core-2011-r6.ebuild: DEPEND:
>    s390(default/linux/s390/13.0) ['media-libs/silgraphite']
>
>
> A.
>

Yep, me too with a Mesa revision bump.