Re: [gentoo-dev] Re: Remove "dev"-status of mips profiles
On Thu, Feb 11, 2010 at 10:12:44PM +0100, Christian Faulhammer wrote: > Hi, > > Jeremy Olexa : > > I would guess that it would be far easier to work in an overlay at > > this point. I would also guess that if there are ANY mips users out > > there that they would have to use some other ACCEPT_KEYWORDS value > > because the shape of ~mips is so...bad. > > Don't remove an architecture. Ask vapier what it means to reintroduce > it. Even if it rots, mark it as unmaintained and wait for someone to > pick-up. I question if this will hold true when gentoo-x86 goes git; at the very least folding an arch back into mainline should be a helluva lot easier. Anyone got any comments on similar attempts? ~harring pgpqbjLufTbxO.pgp Description: PGP signature
[gentoo-dev] Re: Remove "dev"-status of mips profiles
Hi, Jeremy Olexa : > I would guess that it would be far easier to work in an overlay at > this point. I would also guess that if there are ANY mips users out > there that they would have to use some other ACCEPT_KEYWORDS value > because the shape of ~mips is so...bad. Don't remove an architecture. Ask vapier what it means to reintroduce it. Even if it rots, mark it as unmaintained and wait for someone to pick-up. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Developer Handbook should document how/when to touch arch profiles' files
As set out in bug #304435 [1], we should declare some policy about changes to arch profiles in devmanual or in the Developer Handbook. Basically, I would want to have this apply to arch profile changes as well: [5] http://devmanual.gentoo.org/keywording/index.html says: = Keywording on Upgrades = [...] Sometimes you may need to remove a keyword because of new unresolved dependencies. If you do this, you *must* file a bug notifying the relevant arch teams. since it all to often happens that this isn't done, or is done after the fact. It would be even more helpful to get some language in there advising ebuild developers to coordinate this with the relevant arch teams in advance so that keywords need not be dropped at all, or that the package.mask entry can be minimised, or that damage can be limited in whichever way is technically achievable. The documentation about maintaining sub-profiles is thin already, so we might as well start documenting it more generally as well. Regards, jer [1] https://bugs.gentoo.org/show_bug.cgi?id=304435
Re: [gentoo-dev] Remove "dev"-status of mips profiles
On 02/11/2010 08:56 PM, Jeremy Olexa wrote: >>> Can we please move the mips profiles from "dev" to "exp" in >>> profiles/profiles.desc? >>> The ~150 mips development profiles increase the time for a >>> `repoman -d full` run in dev-perl/ from three to five minutes. That is >>> an increase of roughly 66 percent. >>> repoman further prints more than 2000 lines of output for two > keywording >>> problems. >> >> Quick pcheck visibility scan of the full tree, stats follow: >> >> mips profiles still enabled: >> * 116191 seperate dependency issues, 1 line per profile/dependency >> issue >> * roughly 2m39s run time >> >> mips profiles disabled (leaving mips-irix however) >> * 9550 seperate dependency issues, 1 line per profile/dependency issue >> * roughly 1m54s run time. [ .. ] > > [1]: > http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/profiles.desc?r1=1.151&r2=1.152 We could at least delete the server/desktop/developer profiles from the above list right away, not really required to have them for every machine type IMHO
Re: [gentoo-dev] Remove "dev"-status of mips profiles
On Thu, Feb 11, 2010 at 06:56:58PM +, Jeremy Olexa wrote: > > At the very least if it's going to be kept around, experimental or > > not, the number of profiles in use there *really* needs reduction- > > mips has roughly 117 profiles listed in profiles.desc out of 217- > > literally ~54% of all dev/stable/experimental profiles. Correction also- they've got 154 rather than 117, meaning 71% of all profiles for a scan. Not sure how I screwed that number up, but aparently I managed it. ~harring pgpJ6dBz0WF9a.pgp Description: PGP signature
Re: [gentoo-dev] Remove "dev"-status of mips profiles
On Thu, Feb 11, 2010 at 06:56:58PM +, Jeremy Olexa wrote: > I would guess that it would be far easier to work in an overlay at this > point. I would also guess that if there are ANY mips users out there that > they would have to use some other ACCEPT_KEYWORDS value because the shape > of ~mips is so...bad. Might want to wait till the cvs->git transition occurs, assuming it's in the next few months- primarily, preserve history, they can just fork the tree off and mainline can start pruning. Till then the profiles could pretty easily be disabled if folks wanted. ~harring pgp35n9LaxOK7.pgp Description: PGP signature
Re: [gentoo-dev] Remove "dev"-status of mips profiles
On Thu, 11 Feb 2010 10:41:41 -0800, Brian Harring wrote: > On Thu, Feb 11, 2010 at 04:54:38PM +0100, Torsten Veller wrote: >> Can we please move the mips profiles from "dev" to "exp" in >> profiles/profiles.desc? >> >> >> The ~150 mips development profiles increase the time for a >> `repoman -d full` run in dev-perl/ from three to five minutes. That is >> an increase of roughly 66 percent. >> repoman further prints more than 2000 lines of output for two keywording >> problems. > > Quick pcheck visibility scan of the full tree, stats follow: > > mips profiles still enabled: > * 116191 seperate dependency issues, 1 line per profile/dependency > issue > * roughly 2m39s run time > > mips profiles disabled (leaving mips-irix however) > * 9550 seperate dependency issues, 1 line per profile/dependency issue > * roughly 1m54s run time. > > So... mips accounts for about 30% of the pcheck runtime, and *92%* of > known visibility issues. As for the runtime difference between > pcheck/repoman, pcheck has some tricks internally to reduce the # of > profiles it has to scan down to just the unique USE/mask set- I'd > expect the mips impact to be far larger w/out that trick in place. > > At the very least if it's going to be kept around, experimental or > not, the number of profiles in use there *really* needs reduction- > mips has roughly 117 profiles listed in profiles.desc out of 217- > literally ~54% of all dev/stable/experimental profiles. I agree, I wasn't sure why so many profiles were added[1] for a dead team (for all intensive purposes). Seems quite silly to me to leave them as 'dev' status. If a member of the mips team would reply to this thread, that would be good. (and surprising to me :) I would guess that it would be far easier to work in an overlay at this point. I would also guess that if there are ANY mips users out there that they would have to use some other ACCEPT_KEYWORDS value because the shape of ~mips is so...bad. -Jeremy [1]: http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/profiles.desc?r1=1.151&r2=1.152 > > Either way, stats to chew on. > ~harring
Re: [gentoo-dev] Remove "dev"-status of mips profiles
On Thu, Feb 11, 2010 at 04:54:38PM +0100, Torsten Veller wrote: > Can we please move the mips profiles from "dev" to "exp" in > profiles/profiles.desc? > > > The ~150 mips development profiles increase the time for a > `repoman -d full` run in dev-perl/ from three to five minutes. That is > an increase of roughly 66 percent. > repoman further prints more than 2000 lines of output for two keywording > problems. Quick pcheck visibility scan of the full tree, stats follow: mips profiles still enabled: * 116191 seperate dependency issues, 1 line per profile/dependency issue * roughly 2m39s run time mips profiles disabled (leaving mips-irix however) * 9550 seperate dependency issues, 1 line per profile/dependency issue * roughly 1m54s run time. So... mips accounts for about 30% of the pcheck runtime, and *92%* of known visibility issues. As for the runtime difference between pcheck/repoman, pcheck has some tricks internally to reduce the # of profiles it has to scan down to just the unique USE/mask set- I'd expect the mips impact to be far larger w/out that trick in place. At the very least if it's going to be kept around, experimental or not, the number of profiles in use there *really* needs reduction- mips has roughly 117 profiles listed in profiles.desc out of 217- literally ~54% of all dev/stable/experimental profiles. Either way, stats to chew on. ~harring pgpSRzP1oftUl.pgp Description: PGP signature
[gentoo-dev] Re: Remove "dev"-status of mips profiles
Hi, Torsten Veller : > Can we please move the mips profiles from "dev" to "exp" in > profiles/profiles.desc? Agreement here. Maybe a restart on non-obsolete MIPS hardware (read Loongson instead of SGI) would be great. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Remove "dev"-status of mips profiles
Can we please move the mips profiles from "dev" to "exp" in profiles/profiles.desc? The ~150 mips development profiles increase the time for a `repoman -d full` run in dev-perl/ from three to five minutes. That is an increase of roughly 66 percent. repoman further prints more than 2000 lines of output for two keywording problems. I can't remember any serious mips keywording activity in the last years. I don't see why I should spend any more time on checking their profiles and filing bugs for an unactive team. Open KEYWORDREQ bugs: https://bugs.gentoo.org/buglist.cgi?quicksearch=kw%3AKEYWORDREQ+owner%2Ccc%3Amips%40gentoo.org
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-office/abiword-plugins: abiword-plugins-2.6.4.ebuild ChangeLog abiword-plugins-2.4.6.ebuild abiword-plugins-2.6.5.ebuild abiword-plugins-
On 02/11/2010 11:16 AM, Gilles Dartiguelongue wrote: > Le mercredi 10 février 2010 à 23:02 +, Samuli Suominen (ssuominen) a > écrit : >> ssuominen10/02/10 17:41:06 >> >> Modified: ChangeLog evince-2.24.2.ebuild >> evince-2.26.2.ebuild >> evince-2.28.1.ebuild evince-2.28.2.ebuild >> Log: >> Update poppler dependency for #304349 >> (Portage version: 2.2_rc62/cvs/Linux x86_64) >> >> ssuominen10/02/10 23:02:49 >> >> Modified: abiword-plugins-2.6.4.ebuild ChangeLog >> abiword-plugins-2.4.6.ebuild >> abiword-plugins-2.6.5.ebuild >> abiword-plugins-2.6.8.ebuild >> abiword-plugins-2.6.6.ebuild >> Log: >> Fix poppler depend. >> (Portage version: 2.2_rc62/cvs/Linux x86_64) > > For the nth time, could you please fill a tracker bug and let > maintainers do their job and/or ask before doing things yourself. > I opened the bug for you, so you have been informed (for your overlay). The change was trivial, and didn't change any functionality at all. The ebuild simply pulls in now what the virtual did before. Stop being over territorial, and let people do their job Thanks, Samuli
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-office/abiword-plugins: abiword-plugins-2.6.4.ebuild ChangeLog abiword-plugins-2.4.6.ebuild abiword-plugins-2.6.5.ebuild abiword-plugins-2.6.
Le mercredi 10 février 2010 à 23:02 +, Samuli Suominen (ssuominen) a écrit : > ssuominen10/02/10 17:41:06 > > Modified: ChangeLog evince-2.24.2.ebuild > evince-2.26.2.ebuild > evince-2.28.1.ebuild evince-2.28.2.ebuild > Log: > Update poppler dependency for #304349 > (Portage version: 2.2_rc62/cvs/Linux x86_64) > > ssuominen10/02/10 23:02:49 > > Modified: abiword-plugins-2.6.4.ebuild ChangeLog > abiword-plugins-2.4.6.ebuild > abiword-plugins-2.6.5.ebuild > abiword-plugins-2.6.8.ebuild > abiword-plugins-2.6.6.ebuild > Log: > Fix poppler depend. > (Portage version: 2.2_rc62/cvs/Linux x86_64) For the nth time, could you please fill a tracker bug and let maintainers do their job and/or ask before doing things yourself. -- Gilles Dartiguelongue Gentoo
