Summary: | dev-util/systemtap keyword request | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pacho Ramos <pacho> |
Component: | [OLD] Keywording and Stabilization | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | naota, nirbheek, sh+disabled, sparc, swegener |
Priority: | High | Keywords: | KEYWORDREQ |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 349627 |
Description
Pacho Ramos
![]() amd64 and x86 have already keyword for all version of this package systemtap never work for *-fbsd *** Bug 384647 has been marked as a duplicate of this bug. *** Looks like alpha@ was missed. Adding to CC. Added ~mips. Keyworded on alpha. Marked ~ppc/~ppc64 This package is now an optional dependency for MySQL 5.5. Can the lagging arches please keyword? Adding ~hppa. The HPPA kernel doesn't appear to implement KPROBES support. Also, someone appears to have masked this as a dev-db/mysql dependency. Nothing to do here. Looks like remaining arches are ok with use.masking of systemtap USE flag for glib Sorry for the delay. I've keyworded systemtap-2.0 for arm. Look at profiles/arch/arm, there are only two maskings of the keyword: package.use.mask:>=dev-db/mysql-5.5 systemtap tcmalloc package.use.mask:>=dev-db/mariadb-5.5 systemtap tcmalloc Can these now be removed? (Reopening the bug until we've cleaned this one up) ia64 done Commit message: Add ~s390 love -- it compiles http://sources.gentoo.org/dev-util/systemtap/systemtap-2.0.ebuild?r1=1.5&r2=1.6 Arch teams, ping! > Sorry for the delay. I've keyworded systemtap-2.0 for arm. Look at
> profiles/arch/arm, there are only two maskings of the keyword:
>
> package.use.mask:>=dev-db/mysql-5.5 systemtap tcmalloc
> package.use.mask:>=dev-db/mariadb-5.5 systemtap tcmalloc
>
> Can these now be removed?
I've removed the two entries, I guess it's okay as is.
What will sh and sparc do? If they will live with the use.mask, we can close this finally (In reply to Pacho Ramos from comment #16) > What will sh and sparc do? If they will live with the use.mask, we can close > this finally Closing then |