[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Mon, 7 Jan 2013 00:02:33 + (UTC) Mike Frysinger (vapier) vap...@gentoo.org wrote: [...] + 07 Jan 2013; Mike Frysinger vap...@gentoo.org profiles.desc: + Mark s390 profiles stable. + 06 Jan 2013; Justin Bronder jsbron...@gentoo.org package.mask: Remove net-nntp/sabnzbd mask, fix already released and updated in tree. [...] --- profiles.desc 3 Jan 2013 16:08:06 - 1.201 +++ profiles.desc 7 Jan 2013 00:02:32 - 1.202 @@ -122,10 +122,10 @@ ppc64 default/linux/powerpc/ppc64/10.0/64bit-userland/server dev # S390 Profiles -s390default/linux/s390/10.0 dev -s390default/linux/s390/10.0/s390x dev -s390default/linux/s390/10.0/server dev -s390default/linux/s390/10.0/server/s390xdev +s390default/linux/s390/10.0 stable +s390 default/linux/s390/10.0/s390x stable +s390default/linux/s390/10.0/server stable +s390 default/linux/s390/10.0/server/s390xstable # 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.bad16 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
On Tue, Feb 19, 2013 at 7:19 AM, Alexis Ballier aball...@gentoo.org wrote: On Mon, 7 Jan 2013 00:02:33 + (UTC) Mike Frysinger (vapier) vap...@gentoo.org wrote: [...] + 07 Jan 2013; Mike Frysinger vap...@gentoo.org profiles.desc: + Mark s390 profiles stable. + 06 Jan 2013; Justin Bronder jsbron...@gentoo.org package.mask: Remove net-nntp/sabnzbd mask, fix already released and updated in tree. [...] --- profiles.desc 3 Jan 2013 16:08:06 - 1.201 +++ profiles.desc 7 Jan 2013 00:02:32 - 1.202 @@ -122,10 +122,10 @@ ppc64 default/linux/powerpc/ppc64/10.0/64bit-userland/server dev # S390 Profiles -s390default/linux/s390/10.0 dev -s390default/linux/s390/10.0/s390x dev -s390default/linux/s390/10.0/server dev -s390default/linux/s390/10.0/server/s390xdev +s390default/linux/s390/10.0 stable +s390 default/linux/s390/10.0/s390x stable +s390default/linux/s390/10.0/server stable +s390 default/linux/s390/10.0/server/s390xstable # 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.bad16 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.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Wed, 19 Sep 2012 01:40:42 -0400 Mike Frysinger vap...@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
On Wed, 19 Sep 2012 01:38:51 -0400 Mike Frysinger vap...@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.
Re: [gentoo-dev] Re: [gentoo-commits] 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Sun, 16 Sep 2012 22:06:19 -0400 Mike Frysinger vap...@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
On Sun, 16 Sep 2012 22:06:19 -0400 Mike Frysinger vap...@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
On Sat, 15 Sep 2012 18:47:56 -0400 Mike Frysinger vap...@gentoo.org wrote: On Tuesday 11 September 2012 14:06:30 Alexis Ballier wrote: On Tue, 28 Aug 2012 00:23:11 + (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-fbsddefault/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
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 signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] 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 + (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 signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Tue, 28 Aug 2012 00:23:11 + (UTC) Mike Frysinger (vapier) vap...@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-fbsddefault/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.
