Re: [gentoo-dev] [PATCH v2 1/2] */*: Remove dependency on virtual/linuxtv-dvb-headers
Hi! These changes will be commited later today. Regards Matthias
[gentoo-dev] [PATCH v2 2/2] virtual/linuxtv-dvb-headers: Remove obsolete ebuild
Closes: https://bugs.gentoo.org/924398 Signed-off-by: Matthias Schwarzott --- .../linuxtv-dvb-headers-5.8.ebuild | 11 --- virtual/linuxtv-dvb-headers/metadata.xml | 12 2 files changed, 23 deletions(-) delete mode 100644 virtual/linuxtv-dvb-headers/linuxtv-dvb-headers-5.8.ebuild delete mode 100644 virtual/linuxtv-dvb-headers/metadata.xml diff --git a/virtual/linuxtv-dvb-headers/linuxtv-dvb-headers-5.8.ebuild b/virtual/linuxtv-dvb-headers/linuxtv-dvb-headers-5.8.ebuild deleted file mode 100644 index a8bcb0283499.. --- a/virtual/linuxtv-dvb-headers/linuxtv-dvb-headers-5.8.ebuild +++ /dev/null @@ -1,11 +0,0 @@ -# Copyright 1999-2022 Gentoo Authors -# Distributed under the terms of the GNU General Public License v2 - -EAPI=7 - -DESCRIPTION="Virtual Package installing the Header files for DVB" - -SLOT="0" -KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~loong ~m68k ~mips ppc ppc64 ~riscv ~s390 sparc x86 ~amd64-linux ~x86-linux" - -RDEPEND=">=sys-kernel/linux-headers-3.7" diff --git a/virtual/linuxtv-dvb-headers/metadata.xml b/virtual/linuxtv-dvb-headers/metadata.xml deleted file mode 100644 index 241b5e6e7446.. --- a/virtual/linuxtv-dvb-headers/metadata.xml +++ /dev/null @@ -1,12 +0,0 @@ - -https://www.gentoo.org/dtd/metadata.dtd";> - - - - This package contains the header files for the DVB drivers - from linuxtv.org needed to compile any application - accessing the DVB-hardware to record/watch tv or - use internet over satellite connection. - - - -- 2.44.0
[gentoo-dev] [PATCH v2 1/2] */*: Remove dependency on virtual/linuxtv-dvb-headers
virtual/linuxtv-dvb-headers has been important in the past when linux-headers was not yet up-to-date. Now it just pulls in sys-kernel/linux-headers. Even that could be dropped as it is part of @system. But this might not be valid everywhere. Bug: https://bugs.gentoo.org/924398 Signed-off-by: Matthias Schwarzott --- eclass/vdr-plugin-2.eclass | 4 ++-- media-tv/dvbstream/dvbstream-0.7_pre20080516-r1.ebuild | 5 ++--- media-tv/dvbtune/dvbtune-0.5-r1.ebuild | 4 ++-- .../linuxtv-dvb-apps-1.1.1.20140321-r2.ebuild| 4 ++-- media-tv/tvheadend/tvheadend-4.2.8-r2.ebuild | 4 ++-- media-tv/tvheadend/tvheadend-.ebuild | 3 +-- media-tv/w_scan/w_scan-20170107.ebuild | 4 ++-- media-video/dvbsnoop/dvbsnoop-1.4.50-r2.ebuild | 4 ++-- media-video/dvbsnoop/dvbsnoop-1.4.50-r3.ebuild | 2 +- media-video/mplayer/mplayer-1.5_p20230215.ebuild | 4 ++-- media-video/mplayer/mplayer-1.5_p20230618.ebuild | 4 ++-- media-video/mplayer/mplayer-1.5_p20231206.ebuild | 4 ++-- media-video/mplayer/mplayer-.ebuild | 4 ++-- media-video/mpv/mpv-0.37.0-r1.ebuild | 2 +- media-video/mpv/mpv-0.37.0.ebuild| 4 ++-- media-video/mpv/mpv-.ebuild | 2 +- media-video/vdr/vdr-2.2.0-r7.ebuild | 4 ++-- media-video/vdr/vdr-2.6.4.ebuild | 4 ++-- media-video/vdr/vdr-2.6.6.ebuild | 2 +- 19 files changed, 33 insertions(+), 35 deletions(-) Changes in v2: - only depend on linux-headers without version - Adapted to updated vdr and mpv versions - Removed another empty KEYWORDS="" to please pkgcheck diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass index f53e2c23f4f8..8f56511032c8 100644 --- a/eclass/vdr-plugin-2.eclass +++ b/eclass/vdr-plugin-2.eclass @@ -1,4 +1,4 @@ -# Copyright 1999-2023 Gentoo Authors +# Copyright 1999-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 # @ECLASS: vdr-plugin-2.eclass @@ -83,7 +83,7 @@ S="${WORKDIR}/${VDRPLUGIN}-${PV}" # depend on headers for DVB-driver and vdr-scripts BDEPEND="virtual/pkgconfig" DEPEND="media-tv/gentoo-vdr-scripts - virtual/linuxtv-dvb-headers" + sys-kernel/linux-headers" RDEPEND="media-tv/gentoo-vdr-scripts app-eselect/eselect-vdr" diff --git a/media-tv/dvbstream/dvbstream-0.7_pre20080516-r1.ebuild b/media-tv/dvbstream/dvbstream-0.7_pre20080516-r1.ebuild index f8e76f402c4a..9dfe663f071a 100644 --- a/media-tv/dvbstream/dvbstream-0.7_pre20080516-r1.ebuild +++ b/media-tv/dvbstream/dvbstream-0.7_pre20080516-r1.ebuild @@ -1,4 +1,4 @@ -# Copyright 1999-2018 Gentoo Foundation +# Copyright 1999-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=6 @@ -13,10 +13,9 @@ SRC_URI="mirror://gentoo/${MY_P}.tar.bz2" LICENSE="GPL-2" SLOT="0" KEYWORDS="amd64 x86" -IUSE="" RDEPEND="dev-lang/perl" -DEPEND="virtual/linuxtv-dvb-headers" +DEPEND="sys-kernel/linux-headers" S="${WORKDIR}/${PN}" diff --git a/media-tv/dvbtune/dvbtune-0.5-r1.ebuild b/media-tv/dvbtune/dvbtune-0.5-r1.ebuild index e4cb2c114c24..1d2b4cece0ae 100644 --- a/media-tv/dvbtune/dvbtune-0.5-r1.ebuild +++ b/media-tv/dvbtune/dvbtune-0.5-r1.ebuild @@ -1,4 +1,4 @@ -# Copyright 1999-2021 Gentoo Authors +# Copyright 1999-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=8 @@ -16,7 +16,7 @@ IUSE="xml" RDEPEND="xml? ( dev-libs/libxml2 )" DEPEND="${RDEPEND} - virtual/linuxtv-dvb-headers" + sys-kernel/linux-headers" PATCHES=( "${FILESDIR}"/${PF}-gentoo.diff diff --git a/media-tv/linuxtv-dvb-apps/linuxtv-dvb-apps-1.1.1.20140321-r2.ebuild b/media-tv/linuxtv-dvb-apps/linuxtv-dvb-apps-1.1.1.20140321-r2.ebuild index 2b5377d5ba58..8fe3e2af5236 100644 --- a/media-tv/linuxtv-dvb-apps/linuxtv-dvb-apps-1.1.1.20140321-r2.ebuild +++ b/media-tv/linuxtv-dvb-apps/linuxtv-dvb-apps-1.1.1.20140321-r2.ebuild @@ -1,4 +1,4 @@ -# Copyright 1999-2023 Gentoo Authors +# Copyright 1999-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=7 @@ -26,7 +26,7 @@ RDEPEND=" " DEPEND="${RDEPEND} dev-lang/perl - virtual/linuxtv-dvb-headers + sys-kernel/linux-headers dev-libs/libusb-compat " RDEPEND+=" diff --git a/media-tv/tvheadend/tvheadend-4.2.8-r2.ebuild b/media-tv/tvheadend/tvheadend-4.2.8-r2.ebuild index 138048f41d63..11b918469163 100644 --- a/media-tv/tvheadend/tvheadend-4.2.8-r2.ebuild +++ b/media-tv
Re: [gentoo-dev] [PATCH 1/2] */*: Replace dependency to virtual/linuxtv-dvb-headers by sys-kernel/linux-headers
Am 25.02.24 um 18:54 schrieb Ionen Wolkens: On Tue, Feb 13, 2024 at 09:19:46AM +0100, Matthias Schwarzott wrote: virtual/linuxtv-dvb-headers has been important in the past when linux-headers was not yet up-to-date. Now it just pulls in >=sys-kernel/linux-headers-3.7. Even that could be dropped as it is part of @system. Bug: https://bugs.gentoo.org/924398 Signed-off-by: Matthias Schwarzott diff --git a/media-video/mpv/mpv-0.37.0-r1.ebuild b/media-video/mpv/mpv-0.37.0-r1.ebuild index 731cc45c2106..9ce839af5283 100644 --- a/media-video/mpv/mpv-0.37.0-r1.ebuild +++ b/media-video/mpv/mpv-0.37.0-r1.ebuild @@ -116,7 +116,7 @@ RDEPEND=" DEPEND=" ${COMMON_DEPEND} X? ( x11-base/xorg-proto ) - dvb? ( virtual/linuxtv-dvb-headers ) + dvb? ( >=sys-kernel/linux-headers-3.7 ) Had missed this mail (sorry), not that I have much to say about it. I'd argue that there's no need to clutter ebuilds with the >=3.7 bit at this point, <3.7 is long gone (dropped 9 years ago, and its addition predates the tree's git migration). Think should keep the dependency itself though, it's not part of @system on *all* profiles (virtual/os-headers has conditions esp. with some prefixes). Similar deal to depending on glibc when packages are prebuilt and cannot be used with musl so pkgcheck can warn if masks are missing. I also wondered if I could drop the dependency completely. Then decided for the simplest possible solution. I will update it to only depend on linux-headers. Regards Matthias
Re: [gentoo-dev] [PATCH 1/2] */*: Replace dependency to virtual/linuxtv-dvb-headers by sys-kernel/linux-headers
Am 25.02.24 um 18:11 schrieb Martin Dummer: Am 25.02.24 um 11:10 schrieb Matthias Schwarzott: Am 13.02.24 um 09:19 schrieb Matthias Schwarzott: virtual/linuxtv-dvb-headers has been important in the past when linux-headers was not yet up-to-date. Now it just pulls in >=sys-kernel/linux-headers-3.7. Even that could be dropped as it is part of @system. Bug: https://bugs.gentoo.org/924398 Hi, +1 from me... but please take note that media-video/vdr has been upgraded in the meantime: [I] media-video/vdr Available versions: 2.2.0-r7 2.6.4 (~)2.6.6 so you must rework your patch a little bit. This part has magically been solved by git rebase. (I do not understand how it did it). Matthias
Re: [gentoo-dev] [PATCH 1/2] */*: Replace dependency to virtual/linuxtv-dvb-headers by sys-kernel/linux-headers
Am 13.02.24 um 09:19 schrieb Matthias Schwarzott: virtual/linuxtv-dvb-headers has been important in the past when linux-headers was not yet up-to-date. Now it just pulls in >=sys-kernel/linux-headers-3.7. Even that could be dropped as it is part of @system. Bug: https://bugs.gentoo.org/924398 As there is no feedback (neither negative nor positive), I will commit this series later today. Regards Matthias
[gentoo-dev] [PATCH v2] games-engines/stratagus: Unbreak USE=debug case
Avoid renaming stratagus executable if compiled with USE=debug. It would end up as /usr/bin/stratagus-dbg instead of /usr/bin/stratagus. Signed-off-by: Matthias Schwarzott --- games-engines/stratagus/stratagus-3.3.2.ebuild | 1 + 1 file changed, 1 insertion(+) diff --git a/games-engines/stratagus/stratagus-3.3.2.ebuild b/games-engines/stratagus/stratagus-3.3.2.ebuild index 1828b8874857..f7735c5f5216 100644 --- a/games-engines/stratagus/stratagus-3.3.2.ebuild +++ b/games-engines/stratagus/stratagus-3.3.2.ebuild @@ -57,6 +57,7 @@ PATCHES=( src_prepare() { sed -i -e 's:-Werror::' CMakeLists.txt || die + sed -i -e '/set_target_properties(stratagus PROPERTIES OUTPUT_NAME.*)/d' CMakeLists.txt || die cmake_src_prepare } -- 2.43.1
[gentoo-dev] [PATCH] games-engines/stratagus: Unbreak USE=debug case
Avoid renaming stratagus executable if compiled with USE=debug. It would end up as /usr/bin/stratatgus-dbg instead of /usr/bin/stratatgus. Signed-off-by: Matthias Schwarzott --- games-engines/stratagus/stratagus-3.3.2.ebuild | 1 + 1 file changed, 1 insertion(+) diff --git a/games-engines/stratagus/stratagus-3.3.2.ebuild b/games-engines/stratagus/stratagus-3.3.2.ebuild index 1828b8874857..6e068b63a521 100644 --- a/games-engines/stratagus/stratagus-3.3.2.ebuild +++ b/games-engines/stratagus/stratagus-3.3.2.ebuild @@ -57,6 +57,7 @@ PATCHES=( src_prepare() { sed -i -e 's:-Werror::' CMakeLists.txt || die + sed -i -e '/set_target_properties(stratagus .*)/d' CMakeLists.txt || die cmake_src_prepare } -- 2.43.1
[gentoo-dev] [PATCH] games-strategy/wargus: Fix running it with games-engines/stratagus[debug]
When stratagus is compiled with USE=debug, its executable is called /usr/bin/stratatgus-dbg. Signed-off-by: Matthias Schwarzott --- games-strategy/wargus/wargus-3.3.2.ebuild | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/games-strategy/wargus/wargus-3.3.2.ebuild b/games-strategy/wargus/wargus-3.3.2.ebuild index fff6023fa177..3295b2911d48 100644 --- a/games-strategy/wargus/wargus-3.3.2.ebuild +++ b/games-strategy/wargus/wargus-3.3.2.ebuild @@ -1,4 +1,4 @@ -# Copyright 1999-2022 Gentoo Authors +# Copyright 1999-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=8 @@ -46,10 +46,12 @@ pkg_pretend() { } src_configure() { + local suffix= + has_version games-engines/stratagus[debug] && suffix=-dbg local mycmakeargs=( -DGAMEDIR="${EPREFIX}/usr/bin" -DBINDIR="${EPREFIX}/usr/bin" - -DSTRATAGUS="${EPREFIX}/usr/bin/stratagus" + -DSTRATAGUS="${EPREFIX}/usr/bin/stratagus${suffix}" -DSHAREDIR="${EPREFIX}/usr/share/stratagus/wargus" -DICONDIR=/usr/share/icons/hicolor/64x64/apps -DWITH_STORMLIB=$(usex bne) -- 2.43.1
[gentoo-dev] [PATCH 2/2] virtual/linuxtv-dvb-headers: Remove obsolete ebuild
Closes: https://bugs.gentoo.org/924398 Signed-off-by: Matthias Schwarzott --- .../linuxtv-dvb-headers-5.8.ebuild | 11 --- virtual/linuxtv-dvb-headers/metadata.xml | 12 2 files changed, 23 deletions(-) delete mode 100644 virtual/linuxtv-dvb-headers/linuxtv-dvb-headers-5.8.ebuild delete mode 100644 virtual/linuxtv-dvb-headers/metadata.xml diff --git a/virtual/linuxtv-dvb-headers/linuxtv-dvb-headers-5.8.ebuild b/virtual/linuxtv-dvb-headers/linuxtv-dvb-headers-5.8.ebuild deleted file mode 100644 index a8bcb0283499.. --- a/virtual/linuxtv-dvb-headers/linuxtv-dvb-headers-5.8.ebuild +++ /dev/null @@ -1,11 +0,0 @@ -# Copyright 1999-2022 Gentoo Authors -# Distributed under the terms of the GNU General Public License v2 - -EAPI=7 - -DESCRIPTION="Virtual Package installing the Header files for DVB" - -SLOT="0" -KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~loong ~m68k ~mips ppc ppc64 ~riscv ~s390 sparc x86 ~amd64-linux ~x86-linux" - -RDEPEND=">=sys-kernel/linux-headers-3.7" diff --git a/virtual/linuxtv-dvb-headers/metadata.xml b/virtual/linuxtv-dvb-headers/metadata.xml deleted file mode 100644 index 241b5e6e7446.. --- a/virtual/linuxtv-dvb-headers/metadata.xml +++ /dev/null @@ -1,12 +0,0 @@ - -https://www.gentoo.org/dtd/metadata.dtd";> - - - - This package contains the header files for the DVB drivers - from linuxtv.org needed to compile any application - accessing the DVB-hardware to record/watch tv or - use internet over satellite connection. - - - -- 2.43.1
[gentoo-dev] [PATCH 1/2] */*: Replace dependency to virtual/linuxtv-dvb-headers by sys-kernel/linux-headers
virtual/linuxtv-dvb-headers has been important in the past when linux-headers was not yet up-to-date. Now it just pulls in >=sys-kernel/linux-headers-3.7. Even that could be dropped as it is part of @system. Bug: https://bugs.gentoo.org/924398 Signed-off-by: Matthias Schwarzott --- eclass/vdr-plugin-2.eclass | 4 ++-- media-tv/dvbstream/dvbstream-0.7_pre20080516-r1.ebuild | 5 ++--- media-tv/dvbtune/dvbtune-0.5-r1.ebuild | 4 ++-- .../linuxtv-dvb-apps-1.1.1.20140321-r2.ebuild| 4 ++-- media-tv/tvheadend/tvheadend-4.2.8-r2.ebuild | 4 ++-- media-tv/tvheadend/tvheadend-.ebuild | 2 +- media-tv/w_scan/w_scan-20170107.ebuild | 4 ++-- media-video/dvbsnoop/dvbsnoop-1.4.50-r2.ebuild | 4 ++-- media-video/dvbsnoop/dvbsnoop-1.4.50-r3.ebuild | 2 +- media-video/mplayer/mplayer-1.5_p20230215.ebuild | 4 ++-- media-video/mplayer/mplayer-1.5_p20230618.ebuild | 4 ++-- media-video/mplayer/mplayer-1.5_p20231206.ebuild | 4 ++-- media-video/mplayer/mplayer-.ebuild | 4 ++-- media-video/mpv/mpv-0.36.0-r1.ebuild | 4 ++-- media-video/mpv/mpv-0.37.0-r1.ebuild | 2 +- media-video/mpv/mpv-0.37.0.ebuild| 4 ++-- media-video/mpv/mpv-.ebuild | 2 +- media-video/vdr/vdr-2.2.0-r7.ebuild | 4 ++-- media-video/vdr/vdr-2.6.3.ebuild | 4 ++-- media-video/vdr/vdr-2.6.4.ebuild | 4 ++-- 20 files changed, 36 insertions(+), 37 deletions(-) diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass index f53e2c23f4f8..cf07058f6177 100644 --- a/eclass/vdr-plugin-2.eclass +++ b/eclass/vdr-plugin-2.eclass @@ -1,4 +1,4 @@ -# Copyright 1999-2023 Gentoo Authors +# Copyright 1999-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 # @ECLASS: vdr-plugin-2.eclass @@ -83,7 +83,7 @@ S="${WORKDIR}/${VDRPLUGIN}-${PV}" # depend on headers for DVB-driver and vdr-scripts BDEPEND="virtual/pkgconfig" DEPEND="media-tv/gentoo-vdr-scripts - virtual/linuxtv-dvb-headers" + >=sys-kernel/linux-headers-3.7" RDEPEND="media-tv/gentoo-vdr-scripts app-eselect/eselect-vdr" diff --git a/media-tv/dvbstream/dvbstream-0.7_pre20080516-r1.ebuild b/media-tv/dvbstream/dvbstream-0.7_pre20080516-r1.ebuild index f8e76f402c4a..cb605b78912f 100644 --- a/media-tv/dvbstream/dvbstream-0.7_pre20080516-r1.ebuild +++ b/media-tv/dvbstream/dvbstream-0.7_pre20080516-r1.ebuild @@ -1,4 +1,4 @@ -# Copyright 1999-2018 Gentoo Foundation +# Copyright 1999-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=6 @@ -13,10 +13,9 @@ SRC_URI="mirror://gentoo/${MY_P}.tar.bz2" LICENSE="GPL-2" SLOT="0" KEYWORDS="amd64 x86" -IUSE="" RDEPEND="dev-lang/perl" -DEPEND="virtual/linuxtv-dvb-headers" +DEPEND=">=sys-kernel/linux-headers-3.7" S="${WORKDIR}/${PN}" diff --git a/media-tv/dvbtune/dvbtune-0.5-r1.ebuild b/media-tv/dvbtune/dvbtune-0.5-r1.ebuild index e4cb2c114c24..f7917665451a 100644 --- a/media-tv/dvbtune/dvbtune-0.5-r1.ebuild +++ b/media-tv/dvbtune/dvbtune-0.5-r1.ebuild @@ -1,4 +1,4 @@ -# Copyright 1999-2021 Gentoo Authors +# Copyright 1999-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=8 @@ -16,7 +16,7 @@ IUSE="xml" RDEPEND="xml? ( dev-libs/libxml2 )" DEPEND="${RDEPEND} - virtual/linuxtv-dvb-headers" + >=sys-kernel/linux-headers-3.7" PATCHES=( "${FILESDIR}"/${PF}-gentoo.diff diff --git a/media-tv/linuxtv-dvb-apps/linuxtv-dvb-apps-1.1.1.20140321-r2.ebuild b/media-tv/linuxtv-dvb-apps/linuxtv-dvb-apps-1.1.1.20140321-r2.ebuild index 2b5377d5ba58..f46f64bd78e9 100644 --- a/media-tv/linuxtv-dvb-apps/linuxtv-dvb-apps-1.1.1.20140321-r2.ebuild +++ b/media-tv/linuxtv-dvb-apps/linuxtv-dvb-apps-1.1.1.20140321-r2.ebuild @@ -1,4 +1,4 @@ -# Copyright 1999-2023 Gentoo Authors +# Copyright 1999-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=7 @@ -26,7 +26,7 @@ RDEPEND=" " DEPEND="${RDEPEND} dev-lang/perl - virtual/linuxtv-dvb-headers + >=sys-kernel/linux-headers-3.7 dev-libs/libusb-compat " RDEPEND+=" diff --git a/media-tv/tvheadend/tvheadend-4.2.8-r2.ebuild b/media-tv/tvheadend/tvheadend-4.2.8-r2.ebuild index 138048f41d63..e1d4ec07444e 100644 --- a/media-tv/tvheadend/tvheadend-4.2.8-r2.ebuild +++ b/media-tv/tvheadend/tvheadend-4.2.8-r2.ebuild @@ -1,4 +1,4 @@ -# Copyright 1999-2023 Gentoo Autho
Re: [gentoo-dev] Last rites: 12 more packages (broken, obsolete deps)
Am 05.06.2017 um 20:13 schrieb Michał Górny: > > # Michał Górny (05 Jun 2017) > # (on behalf of Treecleaner project) > # Unmaintained in Gentoo. The current Gentoo version no longer builds. > # Removal in 30 days. Bug #602820. > media-plugins/vdr-xineliboutput > I like to take this package. It is one of a very small number of pure software output possibilities of vdr needed for development. There is an new upstream version available that builds. Regards Matthias
Re: [gentoo-dev] [gentoo-dev-announce] Last rites: dev-util/{...}
Am 11.06.2016 um 21:41 schrieb Matthias Schwarzott: > Am 05.06.2016 um 21:04 schrieb Robin H. Johnson: >> On Sun, Jun 05, 2016 at 01:47:48PM +0200, Patrice Clement wrote: >>> dev-util/cdecl >>> dev-util/dwarves >>> dev-util/intel2gas >>> dev-util/lsuio >>> dev-util/mock >>> dev-util/par >>> dev-util/tinlink >>> dev-util/usb-robot >> I've used the above subset of these, so I'll review the upstreams to see >> if they just moved or what. >> > > I also would like to have dev-util/dwarves be kept. I use the pahole > tool from time to time. > As I checked it, the git repository has new commits from this year. > I took dev-util/dwarves now and updated it to a snapshot containing the latest changes from upstream. Now it works with recent compiler output again. Regards Matthias
Re: [gentoo-dev] [gentoo-dev-announce] Last rites: dev-util/{...}
Am 05.06.2016 um 21:04 schrieb Robin H. Johnson: > On Sun, Jun 05, 2016 at 01:47:48PM +0200, Patrice Clement wrote: >> dev-util/cdecl >> dev-util/dwarves >> dev-util/intel2gas >> dev-util/lsuio >> dev-util/mock >> dev-util/par >> dev-util/tinlink >> dev-util/usb-robot > I've used the above subset of these, so I'll review the upstreams to see > if they just moved or what. > I also would like to have dev-util/dwarves be kept. I use the pahole tool from time to time. As I checked it, the git repository has new commits from this year. Regards Matthias
[gentoo-dev] Packages up for grabs
Hi! Feel free to take over one of these packages if interested: * sys-apps/input-utils * dev-java/skinlf Regards Matthias
Re: [gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs
On 29.03.2015 23:29, Davide Pesavento wrote: > On Sun, Mar 29, 2015 at 9:12 PM, Matthias Schwarzott wrote: >> On 29.03.2015 20:58, Matthias Schwarzott wrote: >>> Hi there! >>> >>> I updated my ~amd64 system recently to new hardware (Intel Core i3-4160). >>> Since then valgrind did no longer work for 32bit programs because >>> "-march=native" did choose instructions that valgrind does not support >>> in 32bit mode (even ld.so was unusable). >>> >>> After some research I put this into make.conf and now it works: >>> CFLAGS_x86="${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" >>> CXXFLAGS_x86="${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" >>> >>> Is this the best solution to the problem? >>> If yes, the valgrind ebuild could suggest something like this. >>> Either always show it or check cpu-flags first (is this maintainable?). >>> >> I should add, that it seems to break for exactly one package: mariadb >> > > Not only mariadb, there are other known breakages... see > https://bugs.gentoo.org/show_bug.cgi?id=541616#c5 > > According to mgorny (Cc'ed): > "You are not supposed to touch CFLAGS_x86, ever. That's some magic > stuff that's used in profiles & multilib.eclass." > I created this bug to track the issue: https://bugs.gentoo.org/show_bug.cgi?id=545052 Regards Matthias
Re: [gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs
On 29.03.2015 20:58, Matthias Schwarzott wrote: > Hi there! > > I updated my ~amd64 system recently to new hardware (Intel Core i3-4160). > Since then valgrind did no longer work for 32bit programs because > "-march=native" did choose instructions that valgrind does not support > in 32bit mode (even ld.so was unusable). > > After some research I put this into make.conf and now it works: > CFLAGS_x86="${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" > CXXFLAGS_x86="${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" > > Is this the best solution to the problem? > If yes, the valgrind ebuild could suggest something like this. > Either always show it or check cpu-flags first (is this maintainable?). > I should add, that it seems to break for exactly one package: mariadb # file /usr/lib32/libmysqlclient.so.18.0.0 /usr/lib32/libmysqlclient.so.18.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped After commenting the flags again: # file /usr/lib32/libmysqlclient.so.18.0.0 /usr/lib32/libmysqlclient.so.18.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped Regards Matthias
[gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs
Hi there! I updated my ~amd64 system recently to new hardware (Intel Core i3-4160). Since then valgrind did no longer work for 32bit programs because "-march=native" did choose instructions that valgrind does not support in 32bit mode (even ld.so was unusable). After some research I put this into make.conf and now it works: CFLAGS_x86="${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" CXXFLAGS_x86="${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" Is this the best solution to the problem? If yes, the valgrind ebuild could suggest something like this. Either always show it or check cpu-flags first (is this maintainable?). Regards Matthias
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/udev: udev-168-r2.ebuild ChangeLog udev-9999.ebuild
On Saturday 14 May 2011, you wrote: > On 05/14/2011 05:00 PM, Matthias Schwarzott (zzam) wrote: > > zzam11/05/14 14:00:34 > > > > Modified: ChangeLog udev-.ebuild > > Added:udev-168-r2.ebuild > > Log: > > Remove /run is not existing message, Bug #365679. Fix uinput rule to > > match what newer kernels does, Bug #321677. Only run modprobe unix > > when unix sockets are not yet available, Bug #363549. > > > > (Portage version: 2.1.9.49/cvs/Linux x86_64) > > > > Revision ChangesPath > > 1.575sys-fs/udev/ChangeLog > > > > file : > > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/ChangeLog?re > > v=1.575&view=markup plain: > > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/ChangeLog?re > > v=1.575&content-type=text/plain diff : > > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/ChangeLog?r1 > > =1.574&r2=1.575 > > > > Index: ChangeLog > > === > > RCS file: /var/cvsroot/gentoo-x86/sys-fs/udev/ChangeLog,v > > retrieving revision 1.574 > > retrieving revision 1.575 > > diff -u -r1.574 -r1.575 > > --- ChangeLog 30 Apr 2011 20:07:08 - 1.574 > > +++ ChangeLog 14 May 2011 14:00:34 - 1.575 > > @@ -1,6 +1,14 @@ > > > > # ChangeLog for sys-fs/udev > > # Copyright 1999-2011 Gentoo Foundation; Distributed under the GPL v2 > > > > -# $Header: /var/cvsroot/gentoo-x86/sys-fs/udev/ChangeLog,v 1.574 > > 2011/04/30 20:07:08 zzam Exp $ +# $Header: > > /var/cvsroot/gentoo-x86/sys-fs/udev/ChangeLog,v 1.575 2011/05/14 > > 14:00:34 zzam Exp $ + > > +*udev-168-r2 (14 May 2011) > > + > > + 14 May 2011; Matthias Schwarzott > > +udev-168-r2.ebuild, + udev-.ebuild: > > + Remove /run is not existing message, Bug #365679. Fix uinput rule to > > match + what newer kernels does, Bug #321677. Only run modprobe unix > > when unix + sockets are not yet available, Bug #363549. > > > > *udev-168-r1 (30 Apr 2011) > > > > 1.37 sys-fs/udev/udev-.ebuild > > > > file : > > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-.eb > > uild?rev=1.37&view=markup plain: > > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-.eb > > uild?rev=1.37&content-type=text/plain diff : > > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-.eb > > uild?r1=1.36&r2=1.37 > > > > Index: udev-.ebuild > > === > > RCS file: /var/cvsroot/gentoo-x86/sys-fs/udev/udev-.ebuild,v > > retrieving revision 1.36 > > retrieving revision 1.37 > > diff -u -r1.36 -r1.37 > > --- udev-.ebuild30 Apr 2011 13:15:40 - 1.36 > > +++ udev-.ebuild14 May 2011 14:00:34 - 1.37 > > @@ -1,13 +1,13 @@ > > > > # Copyright 1999-2011 Gentoo Foundation > > # Distributed under the terms of the GNU General Public License v2 > > > > -# $Header: /var/cvsroot/gentoo-x86/sys-fs/udev/udev-.ebuild,v 1.36 > > 2011/04/30 13:15:40 zzam Exp $ +# $Header: > > /var/cvsroot/gentoo-x86/sys-fs/udev/udev-.ebuild,v 1.37 2011/05/14 > > 14:00:34 zzam Exp $ > > > > EAPI="1" > > > > inherit eutils flag-o-matic multilib toolchain-funcs linux-info > > autotools > > > > #PATCHSET=${P}-gentoo-patchset-v1 > > > > -scriptversion=164-v2 > > +scriptversion=v3 > > > > scriptname=${PN}-gentoo-scripts-${scriptversion} > > > > if [[ ${PV} == "" ]]; then > > > > @@ -197,7 +197,7 @@ > > > > src_install() { > > > > emake -C "${WORKDIR}/${scriptname}" \ > > > > - DESTDIR="${D}" \ > > + DESTDIR="${D}" LIBDIR="$(get_libdir)" \ > > Does this mean it's /$(get_libdir)/udev again instead of /lib/udev? > Ditto for 168-r2. No, it does mean that the scripts package itself is updated, so it installs the udev stuff into /lib/udev and the baselayout-1 addon into /$(get_libdir)/rcscripts/addons. I think I should clone the git tree of these scripts somewhere. Best is git.overlays.gentoo.org, correct? What about the udev-git tree plus gentoo patches? Should that also be published there? Matthias
[gentoo-dev] Re: udev installs now to /lib/udev (was: rfc: libexec directory inconsistency)
On Sonntag, 24. April 2011, Matthias Schwarzott wrote: > Getting that discussion back on top. > > On Samstag, 22. Januar 2011, Diego Elio Pettenò wrote: > > Il giorno sab, 22/01/2011 alle 11.02 -0600, William Hubbs ha scritto: > > > Is there a reason for this? If not, would it break things if we start > > > using /libexec as well as /usr/libexec? > > > > More or less and yes, it would create one more root directory that has > > no real usage to be there anyway... > > > > > I noticed that for dhcpcd and openrc we force their LIBEXECDIR to be > > > $(get_libdir)/foo, which puts things in different directories > > > depending on whether the system is multilib or not. > > > > Which is wrong, it should be /lib/foo instead, not $(get_libdir), to > > follow what udev and other software in Linux has been using for a very > > long time now. > > Sounds like we should fix udev ebuild and some ebuilds installing udev > rules to not use /$(get_libdir)/udev, but plain /lib/udev. > > I used that in believe that /lib is identical or links to /$(get_libdir) > and multilib-strict requires it, but it seems to be intelligent enough to > only deny 64-bit libs to go to /lib. > > So proper udev should use /lib/udev, correct? > sys-fs/udev-168 does now install to /lib/udev unconditionally. Regards Matthias
Re: [gentoo-dev] Re: rfc: libexec directory inconsistency
On Sonntag, 24. April 2011, Michał Górny wrote: > On Sun, 24 Apr 2011 21:43:16 +0200 > > Matthias Schwarzott wrote: > > Sounds like we should fix udev ebuild and some ebuilds installing > > udev rules to not use /$(get_libdir)/udev, but plain /lib/udev. > > > > I used that in believe that /lib is identical or links > > to /$(get_libdir) and multilib-strict requires it, but it seems to be > > intelligent enough to only deny 64-bit libs to go to /lib. > > > > So proper udev should use /lib/udev, correct? > > Do you really think it'd be fine for some systems to possibly > have /lib64 and /lib with random different contents? Regarding /lib64/udev vs. /lib/udev: I think it is fine for some time. Having some rules only in /lib64/udev when udevd looks info /lib/udev will make only these things break that depend on the extra rules. The main question is: How many systems are affected by this /lib64 is not the same as /lib ? Matthias
Re: [gentoo-dev] Re: rfc: libexec directory inconsistency
On Sonntag, 24. April 2011, Michał Górny wrote: > On Sun, 24 Apr 2011 21:43:16 +0200 > > Matthias Schwarzott wrote: > > Sounds like we should fix udev ebuild and some ebuilds installing > > udev rules to not use /$(get_libdir)/udev, but plain /lib/udev. > > > > I used that in believe that /lib is identical or links > > to /$(get_libdir) and multilib-strict requires it, but it seems to be > > intelligent enough to only deny 64-bit libs to go to /lib. > > > > So proper udev should use /lib/udev, correct? > > Do you really think it'd be fine for some systems to possibly > have /lib64 and /lib with random different contents? Well I was always under the impression that /lib64 and /lib did point to the same directory. Is the case where /lib is no symlink to /lib64 so frequent? Matthias
Re: [gentoo-dev] Re: rfc: libexec directory inconsistency
On Sonntag, 24. April 2011, Samuli Suominen wrote: > On 04/24/2011 10:43 PM, Matthias Schwarzott wrote: > > Getting that discussion back on top. > > > >> Which is wrong, it should be /lib/foo instead, not $(get_libdir), to > >> follow what udev and other software in Linux has been using for a very > >> long time now. > > > > Sounds like we should fix udev ebuild and some ebuilds installing udev > > rules to not use /$(get_libdir)/udev, but plain /lib/udev. > > Right, doesn't make sense to have both 32bit and 64bit ELF's for udev, > so we should stick with /lib/udev. > > > I used that in believe that /lib is identical or links to /$(get_libdir) > > and multilib-strict requires it, but it seems to be intelligent enough > > to only deny 64-bit libs to go to /lib. > > > > So proper udev should use /lib/udev, correct? > > Correct. > > > > The udev situation is really a mess tree-wide, we have ebuilds > installing into 3 different directories now: > > /etc/udev (where user puts his local rules) > /$(get_libdir)/udev(as explained above) > /lib/udev (the correct one) > > Check the Portage to see the sad status of inconsistency: > > $ grep -r 'etc.*udev' */*/*.ebuild > $ grep -r 'get_libdir.*udev' */*/*.ebuild And this does not even catch the cases where Makefiles (eventuelly together with configure-parameters) install to any of these three locations. By the way, the bug that led me to think about the install location is this Bug #363549 Matthias
Re: [gentoo-dev] Re: rfc: libexec directory inconsistency
Getting that discussion back on top. On Samstag, 22. Januar 2011, Diego Elio Pettenò wrote: > Il giorno sab, 22/01/2011 alle 11.02 -0600, William Hubbs ha scritto: > > Is there a reason for this? If not, would it break things if we start > > using /libexec as well as /usr/libexec? > > More or less and yes, it would create one more root directory that has > no real usage to be there anyway... > > > I noticed that for dhcpcd and openrc we force their LIBEXECDIR to be > > $(get_libdir)/foo, which puts things in different directories > > depending on whether the system is multilib or not. > > Which is wrong, it should be /lib/foo instead, not $(get_libdir), to > follow what udev and other software in Linux has been using for a very > long time now. Sounds like we should fix udev ebuild and some ebuilds installing udev rules to not use /$(get_libdir)/udev, but plain /lib/udev. I used that in believe that /lib is identical or links to /$(get_libdir) and multilib-strict requires it, but it seems to be intelligent enough to only deny 64-bit libs to go to /lib. So proper udev should use /lib/udev, correct? Matthias
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
On Montag, 9. November 2009, Mart Raudsepp wrote: > On Sun, 2009-08-30 at 16:11 +0200, Matthias Schwarzott wrote: > > Hi there! > > A late hello, > > > Second point: udev-145 bundles a lot of new extras, but they can only be > > enabled/disabled all or nothing. > > > > These extras are: > > * udev-acl: Apply consolekit permissions to devices for users (audio, > > video, joysticks, scanner, cameras, ...) > > * usb-db: Provide udev-rules with device names of pci and usb devices > > * hid2hci: Special utility to fix resume of some hid devices > > * keymap: Auto-configure model specific keys found on many laptops > > ("brightness up", "next song", "www browser", or "suspend") > > * modem-modeswitch: Switch modems that provide virtual cd-drive with > > drivers to modem mode > > I think the thread hasn't seen an answer to the question of when these > are actually used or useful, as asked in another subthread as well. > > > * gudev: glib/gobject support for libudev > > Would it be possible to have this in a separate package? Of course then > with a temporary compatibility PDEPEND on it with udev[extras] until > packages needing gudev migrate over. The question is: DO we really need to split udev that upstream bundled into one tarball? > And what of the above listed other things besides core udev does gudev > require or potentially use? To be answered by someone else, I do not need these yet. Matthias
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
On Mittwoch, 14. Oktober 2009, sch...@subverted.org wrote: > > Oh, you mean the docs that only cover the "old" configuration mechanism > and are only installed with USE=oldnet? How silly to think that changes > that are likely to take testers' machines offline should be documented, > if nothing else with, say, 'ewarn "USE=-oldnet changes the network > configuration syntax, check it before rebooting"'. I wasn't bitten > (because I am more cautious than that), but I WAS annoyed that a package > was sent out to be tested with zero instructions on the drastic changes > it made. So this is my last mail to this topic. At least /etc/conf.d/network does contain documentation. Or is a requirement of documentation that it is not inside config files? First: Default enabled use-flags may be enabled for a reason. One should think before overriding it. Another thing: There was no message that one should switch to new scripts NOW. Old scripts will still be supported some time. I also keep using the old ones for now. As openrc-0.5.1 did work in the tests for me and some other people and no breakage was expected I did commit it. If you got a bug you should report it on bugzilla. And no, package.mask does not help, as then the bug would show later when unmasking. The openrc ebuild does print a warning if old net.* init-scripts are enabled in some runlevels. See this code: if ! use oldnet; then local f= links=$(find "${ROOT}"/etc/runlevels/ -name "net.*") if [[ "${links}" != "" ]] ; then ewarn "You have disabled installation of old-style network scripts" ewarn "but they are still enabled in some runlevels:" for f in $links; do ewarn "\t$f" done ewarn "You should migrate the settings" ewarn "from /etc/conf.d/net to /etc/conf.d/network" ewarn "and clean runlevels from /etc/init.d/net.* and" ewarn "instead add /etc/init.d/network" fi fi So if you disabled "oldnet" you definitely got the message above. Yes, there is no big fat warning that stuff may break, but you still can roll back to the config you had before. But, as new network script is installed regardless of oldnet setting, the warning must be printed always to be useful. Did you have a look at demerge. That is a software that makes a snapshot of which packages are installed with exact use-flag config and can rollback to that snapshot. The use-flag "oldnet" itself is described like this: Install the old type of network init-scripts with a symlink net.IFACE for each interface Matthias
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
On Dienstag, 13. Oktober 2009, Markos Chandras wrote: > > I agree with Nirbheek. You should always provide an updated documentation ( > and a news item if necessary ) when you release a new major update of such > core packages. I would like to see new openrc masked until the > documentation is ready with full details about the transition to the new > network init script. > If you don't provide such documentation in time, you will fail to make > users switch to new init script in the near future, since everybody will > forget about this and will use the 'oldnet' use flag anyway. > The sooner you will explain them how to migrate, the better > results/feedback/updated systems you will get > You are right. If I want everybody to switch to new net init script. But do I want that? I still use the old one, as I think it is more powerful. The old scripts will not be dropped in medium future if it does not break stuff. By the way I am no official maintainer of openrc, still caring about it and fixing stuff if it annoys me or I have too much of free time. About the new scripts in general: Do we consider them already good enough and stable enough to recommend (non power-)users to transition? Regards Matthias
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
On Samstag, 10. Oktober 2009, Nirbheek Chauhan wrote: > On Sat, Oct 10, 2009 at 6:42 PM, Alin Năstac wrote: > > On 10/9/09 7:57 PM, Matthias Schwarzott wrote: > >> * does new scripts already can do all that was possible with net.* ? > > > > No. PPP is not compatible with the new scripts. > > Major regression. It never pays to drop surprises on people like this. > I *strongly* suggest masking openrc-0.5.1 until the documentation is > updated and a news file is sent. Why do you suggest masking it immediately? Emerging it without changing any use-flags, has oldnet enabled by default, so user gets exactly the same net init-scripts as with openrc-0.4 before, so where is the regression that needs to be masked? One can still use the same stuff and nobody is forced to transition to the new network script. Regards Matthias
[gentoo-dev] openrc-0.5.1 arrived in the tree
Hi there! As some of you have waited long for this to happen, sys-apps/openrc-0.5.1 is there. It has a default enabled (eapi-1) useflag oldnet to install the old-style network scripts called net.*. Regardless of this use-flag, the new init-script /etc/init.d/network is always installed. For transition to new-style network script there is something todo I think. Unordered list of todos: * hotplug? at least udev does explicitly call in net.* scripts * New systems should get old or new scripts? * does new scripts already can do all that was possible with net.* ? So far I hope the update does not break any system. In case this happens nevertheless open a bug as usual. Regards Matthias
[gentoo-dev] About udev-145: new features / extras and kernel requirements
Hi there! The new udev-145 and newer have some new kernel requirements. How should the ebuild verify they are met? Some possible ways: 1. Check config under /usr/src/linux 2. Check /proc/config.gz 3. Print message for user in pkg_postinst Second point: udev-145 bundles a lot of new extras, but they can only be enabled/disabled all or nothing. These extras are: * udev-acl: Apply consolekit permissions to devices for users (audio, video, joysticks, scanner, cameras, ...) * usb-db: Provide udev-rules with device names of pci and usb devices * hid2hci: Special utility to fix resume of some hid devices * keymap: Auto-configure model specific keys found on many laptops ("brightness up", "next song", "www browser", or "suspend") * modem-modeswitch: Switch modems that provide virtual cd-drive with drivers to modem mode * gudev: glib/gobject support for libudev This makes udev depend on these libs: libacl, libglib2, libusb, usbutils, pciutils, gperf Up to now I have just added use-flag "extras" to control these. But I suppose that udev-acl and maybe gudev is a hard requirement for newer hal or devicekit versions. And upstream thinks these should be enabled by default. Are any of these extras considered harmful? Regards Matthias
Re: [gentoo-dev] QA last rites for media-tv/linuxtv-dvb-firmware
On Dienstag, 25. August 2009, Diego E. Pettenò wrote: > # Diego E. Pettenò (25 Aug 2009) > # on behalf of QA team > # > # Fails to fetch since June 2007 (bug #181908), that's over > # two years ago. > # > # Removal on 2009-10-24 > media-tv/linuxtv-dvb-firmware Only some of the many possible firmwares fail to fetch. Daniel Pielmeier (billie) has a reworked ebuild almost ready to be commited. Regards Matthias
Re: [gentoo-dev] [rfc] repo_name/layman-global.txt overlay name mismatches
On Sonntag, 12. Juli 2009, Sebastian Pipping wrote: > "vdr-xine-overlay", # vdr-xine Fixed to be vdr-xine. Zzam
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Samstag, 28. Februar 2009, Peter Volkov wrote: > В Втр, 24/02/2009 в 16:14 +0200, Serkan Kaba пишет: > > lucene-contrib eclass in java-experimental [1] sets EAPI to 1 to use > > slot deps. And I think that's a valid usage. > > > > 1: > > http://overlays.gentoo.org/proj/java/browser/java-experimental/eclass/luc > >ene-contrib.eclass > > It's better (the only way...) to die in case an ebuild sets lower EAPI, > like kde4-functions.eclass does: > > case ${EAPI} in > 2) : ;; > *) die "No way! EAPI older than 2 is not supported." ;; > esac I still dislike die in global scope, why not do it like autotools.eclass? It does: DEPEND="INCORRECT-WANT_AUTOCONF-SETTING-IN-EBUILD" Regards Matthias
Re: [gentoo-dev] Detecting Baselayout2/openrc - no-symlink profiles leading to breakage
On Sonntag, 18. Januar 2009, Robin H. Johnson wrote: > I'm raising this as an extension of bug 253076, but also because I see > the potential for danger. > > To date, for an init script that has baselayout2-specific behavior, we > have had some variant of [ -e /lib/librc.so ] in the init script. > > On a multilib profile with no symlinks and a 64-bit userspace, the .so > file would be installed in /lib64/librc.so, and the check would > mistakenly have the wrong result. > > There's one fix that has started to turn up already, but I'm not sure if > it's going to be safe always: [ -f /etc/init.d/sysfs ] > This happens to work as openrc installs that init script. > I changed udev to only check for /etc/init.d/sysfs. See Bug #252493. The only place where librc checking is kept is only run on older openrc-versions which are no longer available via ebuild. I hope this will make udev work on any system regardless of how /lib and stuff is linked. (For further analysis perhaps someone on a multilib profile can check where udev still has /lib/xxx hardcoded instead of /lib64/xxx or similar). Should I nevertheless add such a blocker to udev or will that make update unnecessary complicated? RDEPEND="!
Re: [gentoo-dev] Usage of econf with an additional || die
On Dienstag, 30. September 2008, Thomas Sachau wrote: > > From my knowledge and experience with sunrise: > > some functions that dont need "|| die": > epatch, econf, eqmake3, eqmake4 > > some functions that need "|| die": > emake, do* > > Afaik die wont work in a subshell independent of how it is called, so the > die from econf wont work, but also the "emake || die" one would also not > work. Well there might be some cases when die does not work fine, I am not sure. But it IS designed to work in subshells. Looking into /usr/lib/portage/bin/isolated-functions.sh: die basically calls kill -s SIGTERM ${EBUILD_MASTER_PID} and sigterm is catched in /usr/lib/portage/bin/ebuild.sh # subshell die support EBUILD_MASTER_PID=$$ trap 'exit 1' SIGTERM and btw. econf is also implemented as a function in ebuild.sh so it even is executed inside the "main" ebuild bash process - no subshell here. Regards Matthias
Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins
On Mittwoch, 6. August 2008, Robin H. Johnson wrote: > Getting the bot out there > - > If you would like to have the new bot in your #gentoo-* channel, would > each channel founder/leader please respond to this thread, stating the > channel name, and that they are the contact for any problems/troubles. > channel: #gentoo-vdr contacts: zzam, hd_brummy
Re: [gentoo-dev] Re: Removing .la files...
On Donnerstag, 19. Juni 2008, Jeroen Roovers wrote: > On Thu, 19 Jun 2008 11:20:10 +0100 > > David Leverton <[EMAIL PROTECTED]> wrote: > > What's to stop an application from loading a "normal" library using > > libtool's dlopen wrapper (perhaps so it can fail gracefully if the > > library is missing, for example)? > > That's a pretty basic definition of a plugin. :) > > > JeR As example loading libm.so via dlopen. So I still would not name libm a plugin. Regards Matthias -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Packages broken by phase ordering change
On Freitag, 13. Juni 2008, Santiago M. Mola wrote: > Hi all, > > As discussed in bug #222721, portage has changed the execution order > of phases. It seems the change was introduced in portage-2.1.5 and it > makes that, when upgrading a package, pkg_postinst is run after the > old version has been removed. This breaks packages which use > has_version in pkg_postinst to detect upgrades/downgrades. It can also > break packages in more subtle ways. > So someone that has access permissions here: Please do fix the devmanual http://devmanual.gentoo.org/ebuild-writing/functions/pkg_postinst/index.html It now states: Common pkg_postinst Tasks The most common use for pkg_postinst is to display post-install informational messages or warnings. Note that has_version will operate on the version that was installed, which can be useful for selective upgrade messages. Regards Matthias -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] merging two packages - upgrade path?
On Montag, 9. Juni 2008, Enrico Weigelt wrote: > * Matthias Schwarzott <[EMAIL PROTECTED]> schrieb: > > Hi, > > > This post is about how to create a nice upgrade path when merging two > > packages. > > The packages I care about are > > media-plugins/vdr-streamdev-{client,server}, that we wanted to merge into > > one media-plugins/vdr-streamdev package. > > please, please, don't do at it all. > > Server vs. clients things should really be separated, and if there's > shared code between them (eg. proto headers), it should belong to > another package. We've already got enough blowed-up, fat packages. > > Same with the -client / -server useflags: they're just a work around > for certain upstream's crap design - if they really understood the > concept named "client-server-model", we'd have clean lines and wouldn't > need this at all. > > Actually, I didn't check whether the upstream did this mixup or just > you, so I won't accuse you for that ;P. If it's the upstream's fault, > please try to stop them. > > Yes, I know Gentoo's policy is to stay as near to upstream as > possible, but there should be a limit. Upstream quality can range > widely, from excellent to crap. Please try to keep the overall > quality as high as possible and leave out the crap. > Well, upstream is just one file/package: vdr-streamdev-0.3.4.tgz All other distros (that I know of) still have only one package for vdr-streamdev. Only gentoo has split this into the client and server parts. But we want to revert this now, because splitting leads to more maintainance effort as both ebuilds are almost the same. Regards Matthias -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] merging two packages - upgrade path?
On Donnerstag, 5. Juni 2008, Rémi Cardona wrote: > Matthias Schwarzott a écrit : > > With #1 user will get no message, as neither the user nor the package > > manager know of the merged package that should be emerged. > > I would do #1 because it's easier to do and it's the Gentoo Way (tm). > > Consider writing an upgrade guide and post it on Planet Gentoo and maybe > on the forums. If it's really important, you might want to get it > published in the official Gentoo News or the GMN. > > If users don't read _any_ of those, then it's not your fault :) > Well, I dont guess so much users will read it there. So my newest idea for this is: package.mask the split ebuilds and write a nice mask-message once the new ebuild is marked stable. Matthias -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] merging two packages - upgrade path?
On Donnerstag, 5. Juni 2008, Ulrich Mueller wrote: > >>>>> On Thu, 5 Jun 2008, Matthias Schwarzott wrote: > > > > This post is about how to create a nice upgrade path when merging two > > packages. > > The packages I care about are > > media-plugins/vdr-streamdev-{client,server}, that we wanted to merge into > > one media-plugins/vdr-streamdev package. > > > > > > So there seem to be different options: > > > > 1. Just create the new packages and do blocks between split and merged > > versions. > > > > [...] > > > > 2. Same as 1, but create dummy ebuilds vdr-streamdev-client-100 and > > vdr-streamdev-server-100: > > > > pkg_setup() { > > eerror "Please unmerge vdr-streamdev-server and emerge vdr-streamdev" > > die > > } > > With #1 the user will get a message about the blockers immediately. > With #2 his emerge (maybe of many packages) will needlessly die when > it reaches your package. > With #1 user will get no message, as neither the user nor the package manager know of the merged package that should be emerged. Maybe #2 but without call to die could be used. But that will make the plugin go away until user reacts on the instructions. > > 3. Let the dummy ebuilds RDEPEND/PDEPEND on the merged version. > > As you said yourself, #3 will result in cruft leftover on the user's > system. > > > #1 is the default used in the tree. > > With good reason, IMHO. This is a package manager issue which > shouldn't be "solved" by creating strange dummy ebuilds. > Matthias -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] merging two packages - upgrade path?
Hi there! This post is about how to create a nice upgrade path when merging two packages. The packages I care about are media-plugins/vdr-streamdev-{client,server}, that we wanted to merge into one media-plugins/vdr-streamdev package. So there seem to be different options: 1. Just create the new packages and do blocks between split and merged versions. vdr-streamdev-client: DEPEND="!media-plugins/vdr-streamdev" vdr-streamdev-server: DEPEND="!media-plugins/vdr-streamdev" vdr-streamdev: DEPEND="!media-plugins/vdr-streamdev-client !media-plugins/vdr-streamdev-server" 2. Same as 1, but create dummy ebuilds vdr-streamdev-client-100 and vdr-streamdev-server-100: vdr-streamdev-server-100: pkg_setup() { eerror "Please unmerge vdr-streamdev-server and emerge vdr-streamdev" die } 3. Let the dummy ebuilds RDEPEND/PDEPEND on the merged version. I think #1 is the default used in the tree. So is there already some better way to do it? #3 offers the easiest upgrade path but keeps useless dummy ebuilds on the system. Regards Matthias -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: qemu -> add gcc-3.x dependency
On Samstag, 10. Mai 2008, Steve Long wrote: > Matthias Schwarzott wrote: > > Code may look like this: > > > > # get last one of sorted list > > for t in $(ls -1 /usr/bin/gcc-3*|sort); do > > use teh globs, luke ;) > for t in /usr/bin/gcc-3*; do # will already do this, sorting according to > LC_COLLATE order (set to C or POSIX [same thing] for ebuild.) There's no > need to step through every one either: > t=(/usr/bin/gcc-3*); [EMAIL PROTECTED]: -1}; unset t # get rid of array > storage > (using same var for both, eg [EMAIL PROTECTED]: -1} only sets the first cell; > the > rest of the array is still live. var is a synonym for var[0] in BASH.) > > set -- * > t=${@: -1} # works here as well but dunno if that applies to all sh (the -1 > expansion, not the set.) In any event not needed in BASH since arrays make > our life so much easier ;) > Well, you want it compact, without loops. Here is it: set -- /usr/bin/gcc-3* Get first entry: CC="$1" Get last entry: eval CC="\${$#}" Regards Matthias -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: qemu -> add gcc-3.x dependency
On Montag, 5. Mai 2008, Peter Volkov wrote: > В Вск, 04/05/2008 в 21:48 +0200, Enrico Weigelt пишет: > > I'm just installing qemu, which requires gcc-3.x for building. > > The current breaks are very ugly, IMHO. > > > > So I'm proposing to add the old gcc-3.x as depedency to qemu, > > at least as long as it doesn't build w/ newer gcc. > > > > What do you think about this ? > > How do you suppose to change gcc version portage uses on-the-fly? > Please, answer trough bugzilla where most bug reports/feature requests > should normally go. I suggest something like this: Get correct path of gcc-3 executable, then supply this with $CC to make. Code may look like this: # get last one of sorted list for t in $(ls -1 /usr/bin/gcc-3*|sort); do p=$t done einfo "Using $p for compiling." emake CC=$p Matthias -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
On Mittwoch, 13. Februar 2008, Petteri Räty wrote: > Fabian Groffen kirjoitti: > > On 13-02-2008 08:50:19 +0100, Rémi Cardona wrote: > >> Petteri Räty a écrit : > >>> What do you think about adding support to base.eclass for running > >>> eautoreconf? > >> > >> In most of the ebuilds where we need to run eautoreconf, we usually > >> apply patches. I can't remember of an ebuild where we just run > >> eautoreconf on its own. > > > > +1 > > If you need to run eautoreconf without adding patches, it may be worth > > adding a comment explaining why. > > base.eclass supports the PATCHES variable which is why I use it in the > first place > How can I use PATCHESwithout quoting issues? default is this (when not using relative pathes): PATCHES="${FILESDIR}/p1.diff ${FILESDIR}/p2.diff" Regards Matthias -- Matthias Schwarzott (zzam) -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-plugins/vdr-radio: ChangeLog vdr-radio-0.2.4.ebuild
On Dienstag, 9. Oktober 2007, Donnie Berkholz wrote: > fowners solved by diropts -m755 -ovdr -gvdr keepdir /var/cache/vdr-radio Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/lirc: ChangeLog lirc-0.8.2-r2.ebuild
On Freitag, 12. Oktober 2007, Donnie Berkholz wrote: > On 19:35 Thu 11 Oct , Matthias Schwarzott (zzam) wrote: > > 1.1 app-misc/lirc/lirc-0.8.2-r2.ebuild > > > > file : > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/lirc/lirc-0.8.2- > >r2.ebuild?rev=1.1&view=markup plain: > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/lirc/lirc-0.8.2- > >r2.ebuild?rev=1.1&content-type=text/plain > > > > add_device() { > > ((lirc_device_count++)) > > [skip lots of code] > > > lirc_driver_count=0 > > "driver" != "device" > > Might be useful to initialize it in add_device() if it's unset, so code > being this far apart won't get out of sync. fixed > > > make DESTDIR="${D}" install || die "make install failed" > > If emake doesn't work, please add a comment to that effect. > changed it to emake for ~arch ebuild. Dont want to try that on stable without knowing well. > > newinitd ${FILESDIR}/lircd lircd > > newinitd ${FILESDIR}/lircmd lircmd > > newconfd ${FILESDIR}/lircd.conf lircd > > > > insinto /etc/modules.d/ > > newins ${FILESDIR}/modulesd.lirc lirc > > > > newinitd ${FILESDIR}/irexec-initd irexec > > newconfd ${FILESDIR}/irexec-confd irexec > > Quoting. fixed Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Unmasking udev-115-r5
On Freitag, 21. September 2007, Matthias Schwarzott wrote: > Hi there! > > If nobody objects, I will unmask udev-115-r5 (or later if needed) today or > tomorrow. There are some rules that got removed between udev-115-r1 and > newer version. If you miss anything please contact us. Either these need to > be added back, or installed by other relevant packages. > > One package I know that needs this is aoetools (Bug #193315). > > Please, if you use or maintain any unusual hardware/driver, please test if > there are no regressions in udev-115-r5. > > One still open regression is this: As we no longer use a wrapper around > modprobe blacklisting will not work in all cases, until module-init-tools > is patched (Bug #192201). > Patched version of module-init-tools done, thanks to Mike Frysinger. So finally this version got unmasked. Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-plugins/vdr-extrecmenu: ChangeLog vdr-extrecmenu-1.0.ebuild
On Montag, 8. Oktober 2007, Donnie Berkholz wrote: > On 20:23 Sun 07 Oct , Joerg Bornkessel (hd_brummy) wrote: > > 1.1 > > media-plugins/vdr-extrecmenu/vdr-extrecmenu-1.0.ebuild > > > > file : > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-plugins/vdr-extrecm > >enu/vdr-extrecmenu-1.0.ebuild?rev=1.1&view=markup plain: > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-plugins/vdr-extrecm > >enu/vdr-extrecmenu-1.0.ebuild?rev=1.1&content-type=text/plain > > > > src_unpack() { > > vdr-plugin_src_unpack > > > > if grep -q fskProtection /usr/include/vdr/timers.h; then > > sed -i "s:#WITHPINPLUGIN:WITHPINPLUGIN:" Makefile > > This doesn't respect ROOT != / and it's also dependent on the build > system. > I guess ROOT-safeness here is irrelevant, as for vdr / vdr-plugin.eclass there is yet no good solution to use the headers from ${ROOT}/usr/include/vdr for compiling. How can this be converted to respect ROOT ? Most times the sources just do #include And this normally will find headers located under /usr/include. Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/udev: ChangeLog udev-115-r6.ebuild
On Montag, 24. September 2007, Donnie Berkholz wrote: > On 19:59 Mon 24 Sep , Matthias Schwarzott (zzam) wrote: > > zzam07/09/24 19:59:38 > > > > This ebuild has really inconsistent use of tests, quotes in tests, and > command substitutions. Being more consistent will increase readability > and decrease bugs due to differences between styles. For tests, pick a > style [[ ]] or [ ] and stick with it. The [[ ]] one is pretty nice > because it generally doesn't require quotes, so the code looks a lot > cleaner. For command substitions, prefer $() over ``. > > > newins ${FILESDIR}/blacklist-110 blacklist > > doins ${FILESDIR}/pnp-aliases > > Quotes here. > > > emake \ > > EXTRAS="${extras}" \ > > libudevdir=${udev_helper_dir} \ > > CROSS_COMPILE=${mycross} \ > > OPTFLAGS="" \ > > ${myconf} || die > > > > emake \ > > DESTDIR="${D}" \ > > libudevdir=${udev_helper_dir} \ > > EXTRAS="${extras}" \ > > ${myconf} \ > > install || die > > Could use some die messages here. > > Thanks, > Donnie fixed, thanks Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Unmasking udev-115-r5
Hi there! If nobody objects, I will unmask udev-115-r5 (or later if needed) today or tomorrow. There are some rules that got removed between udev-115-r1 and newer version. If you miss anything please contact us. Either these need to be added back, or installed by other relevant packages. One package I know that needs this is aoetools (Bug #193315). Please, if you use or maintain any unusual hardware/driver, please test if there are no regressions in udev-115-r5. One still open regression is this: As we no longer use a wrapper around modprobe blacklisting will not work in all cases, until module-init-tools is patched (Bug #192201). Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Please test udev-115-r2 (was: udev rules cleanup / merging rules files with other distros)
On Donnerstag, 6. September 2007, Matthias Schwarzott wrote: > On Dienstag, 4. September 2007, Matthias Schwarzott wrote: Hi there! > That is already available as udev-115-r1 ebuild. > > I now tried to get a small ruleset to apply additional to upstream ones to > get a sane status. > > This is now available as (masked) ebuild udev-115-r2. > The files can also be browsed here: http://dev.gentoo.org/~zzam/udev/ > > I know not all rules have been copied from old rules. But are all really > needed? > Please test this ebuild and give feedback about wrong pathes/permissions > for devices. > I now did some more updates to udev-115-r2. This time it is about subdirs. I removed /dev/fb/ as it does not play well together with symlink /dev/fb -> /dev/fb0 (that upstream rules create now). Same applies for /dev/lirc/ that we should also remove that from the lirc rule. Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Please test udev-115-r2 (was: udev rules cleanup / merging rules files with other distros)
On Dienstag, 4. September 2007, Matthias Schwarzott wrote: Hi there! > > So here we are: > In udev git-gtree suse and redhat rules are already merged. > But they use a different permission / group system than we have, they have > less groups and assign some desktop permissions via pam_console. > > I also got all of our rules files (except 50-udev.rules) merged with what > the other distros use (already in git). That is already available as udev-115-r1 ebuild. I now tried to get a small ruleset to apply additional to upstream ones to get a sane status. This is now available as (masked) ebuild udev-115-r2. The files can also be browsed here: http://dev.gentoo.org/~zzam/udev/ I know not all rules have been copied from old rules. But are all really needed? Please test this ebuild and give feedback about wrong pathes/permissions for devices. Greetings Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] udev rules cleanup / merging rules files with other distros
On Mittwoch, 5. September 2007, Rémi Cardona wrote: > Maybe some of those groups could be merged (cdrom, cdrw) or dropped > (tape maybe?) > I guess this is ok, as for normal burning cdrom for now does grant all permissions. Only questionable thing is: Isn't a user with write permission to cdroms able to modify firmware ... ? > Having usb devices as root:root 644 is going to be a PITA if we don't > have something like a sane pam_console (one that doesn't change all /dev > nodes whenever someone logs in over ssh, like the one we used to have > did) or like ConsoleKit. I am not planning to delete group usb. I just want to discuss this permission stuff and not decide alone. For usb we sure keep GROUP=usb, MODE=664. And for additionall packages maybe changed group, but still MODE=664. Unlike most packages changing usb-permissions that now install MODE=660. I should create a bug about this. (Incomplete) list of affected packages: media-libs/libgphoto2: GROUP="plugdev", MODE="660" media-gfx/iscan: GROUP="scanner", MODE="660" media-gfx/sane-backends: GROUP="scanner", MODE="660" What about plugdev - should that name be changed? Why is it used there? I remember it came from hal or similar. Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Dienstag, 4. September 2007, Matthias Schwarzott wrote: > On Samstag, 1. September 2007, Matthias Schwarzott wrote: > > On Samstag, 1. September 2007, Daniel Drake wrote: > > > I like the idea of adding this to CONFIG_PROTECT_MASK. > > Ok seems we should do this! Next udev ebuild will add rules directory to > CONFIG_PROTECT_MASK. > > I also tested now what happens to rule changes that get installed in the > same turn as the MASK is added. etc-update and dispatch-conf both handle > this case fine. udev-115-r1 has been commited. It now adds rules directory to CONFIG_PROTECT_MASK. -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Samstag, 1. September 2007, Matthias Schwarzott wrote: > On Samstag, 1. September 2007, Daniel Drake wrote: > > I like the idea of adding this to CONFIG_PROTECT_MASK. > > Ok seems we should do this! Next udev ebuild will add rules directory to CONFIG_PROTECT_MASK. I also tested now what happens to rule changes that get installed in the same turn as the MASK is added. etc-update and dispatch-conf both handle this case fine. Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [RFC] udev rules cleanup / merging rules files with other distros
Hi there! As you all know up to now we have our very own rules file 50-udev.rules This is good for getting our specials - but bad from maintainance view. So here we are: In udev git-gtree suse and redhat rules are already merged. But they use a different permission / group system than we have, they have less groups and assign some desktop permissions via pam_console. I also got all of our rules files (except 50-udev.rules) merged with what the other distros use (already in git). Slackware has already started merging the rules with this "upstream" common rules, and they also are more near to our approach by using groups for audio/tape/cdrom/... But I have not yet seen their rules yet. So for now we are on our own. So before doing to much work we should get a sane concept. And for that concept we need: * A (maybe formal) definition what each group should be used for * what devices it contains (if not obvious) * if permissions should be read/read-write for the group * and nothing/read for world. The question arises as we use MODE=660 for most groups but upstream does 640 most of the time. This are the groups. 1. audio All alsa and oss devices. Rules are not contained in upstream rules - they will in future be installed by media-libs/alsa-lib And upstream split of file for also also does not contain this group but sure it should keep MODE=660 / group audio (Or should we still support oss without having alsa installed) 2. cdrom Used for all cdrom/cdwriter devices and for scsi also the associated sg device. MODE=660 Upstream has no such group - member of disk for them. 3. cdrw Only used for pktcdvd with MODE=660 Should this be merged into group cdrom? 4. disk Contains every device with SUBSYSTEM==block, with MODE=660 the raw-devices (still needed?) + some devices needed for ata-over-ethernet (with modes 220 or 440) Upstream uses MODE=640 (Like old unix group for backup usage). 5. floppy The fd* devices, MODE=660 Upstream uses MODE=640 6. lp Used for all *lp* and parport devices with MODE=660 Upstream uses it same way. 7. tape Contains all tape devices with MODE=660. Upstream has no such group - member of disk group. 8. tty Same usage as upstream (maybe only very slight changes) 9. usb Devices for libusb (/dev/bus/usb/...) with MODE=664. + legousbtower device Upstream has no such group but has libusb stuff root:root with MODE=644 If default world permission is reading then every package changing permissions here (like gphoto, iscan, sane) should also keep world-read I think! 10. uucp serial devices, isdn and more for dialout usage MODE=660 Upstream uses it same way. 11. video A lot of misc stuff: dri/card*, nvidia, 3dfx, framebuffer, ieee1394, v4l, dvb with MODE=660 Upstream has no such group - they keep group at root and grant access via pam. Groups we do not use yet: 12. kmem Upstream uses it for /dev/mem /dev/kmem /dev/port with MODE=640 Should be ok to use - we have group=root, MODE=640 for now Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Samstag, 1. September 2007, Daniel Drake wrote: > I like the idea of adding this to CONFIG_PROTECT_MASK. > > Matthias Schwarzott wrote: > > Only problem I see: What to do with people having custom modifications > > inside the default rules-files? > > I can't think of any cases where the user would have to do this (they > can make custom modifications in their own files). > > Could we modify the rules files installed by udev to include a comment > at the top warning that a default portage configuration will overwrite > any changes that the user makes? > I have newer testing files locally, but as far as I remember udev-115 should contain this header on almost all rule files already. # do not edit this file, it will be overwritten on update Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Freitag, 31. August 2007, Tobias Klausmann wrote: > Hi! > > On Fri, 31 Aug 2007, Mike Frysinger wrote: > > On Friday 31 August 2007, Marius Mauch wrote: > >> Petteri Räty <[EMAIL PROTECTED]> wrote: > >>> Matthias Schwarzott kirjoitti: > >>>> On Freitag, 31. August 2007, Matthias Schwarzott wrote: > >>>>> What do you think about adding /etc/udev/rules.d/ to > >>>>> CONFIG_PROTECT_MASK. This will no longer bother the user with > >>>>> updating these files. Thus it will reduce the number of bugs > >>>>> triggered by forgotten config-file updates. > >>>>> > >>>>> If user needs home-brewn rules he is requested to add own files, > >>>>> and not use the already existing ones. > >>>> > >>>> Only problem I see: What to do with people having custom > >>>> modifications inside the default rules-files? > >>> > >>> Can they add /etc/udev/rules.d back to CONFIG_PROTECT in make.conf? > >> > >> No, that wouldn't work. However they could add '-/etc/udev/rules.d' to > >> CONFIG_PROTECT_MASK or add individual files to CONFIG_PROTECT. > > > > either solution sucks > > > > the question is, should people be modifying the default rules ? is there > > something in the default rules file that they cant accomplish in a sep > > rules file ? if so, then the dir cant be masked ... > > I find the persisten-net-generator.rules particularly annoying > (for various reasons including, but not limited to system images > and system cloning). > > So I have an empty file of that name and happily nuke whatever > comes along with udev updates. I could of course unmask that > file if it were to be masked in the future. > > Still, this reeks of layers upon layers of customization to me. > I'd prefer a more elegant solution - although know of none. The > classic approach would be a USE flag to toggle installation of > the shipped udev files - which wouldn't work for me, as I only > have gripes about *one* of them. > > There probably simply isn't a simple, elegant solution that is a) > not wrong and b) works for just about everybody. > If your only regard is disabling persistent-net stuff you also can archive this without need to modify any files. 1. For almost all decisions udev does it is possible to overwrite them later, or assign a value with := instead of = before. 2. In special case of persistent-net: 75-persistent-net.rules does only catch a devices if no name is set at that point, that means it can by bypassed simply be doing this in some rule-file before: SUBSYSTEM=="net", NAME="%k" We have already thought about adding a config option to disable persistent-net, but we have not yet find a nice (from developer and user view) solution. 3. If there are annoyances in udev-rules, please inform us about this. We might have some kind of hardware, but there are lots of different possible configurations we have no idea of, so please bug us (best with solution ;) ). Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Freitag, 31. August 2007, Matthias Schwarzott wrote: > Hi there! > > What do you think about adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK. > This will no longer bother the user with updating these files. > Thus it will reduce the number of bugs triggered by forgotten config-file > updates. > > If user needs home-brewn rules he is requested to add own files, and not > use the already existing ones. > Only problem I see: What to do with people having custom modifications inside the default rules-files? Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 & LVM
On Freitag, 31. August 2007, Ed W wrote: > > You will basically need to remerge sys-fs/lvm2 and sys-fs/device-mapper > > and > > Darn, sorry for the noise > > Didn't think to check the masked packages - however, there it is clear > as day in the changelog... > Well, this is not true, because neither device-mapper not lvm2 are listed in package.mask. Checking the ebuilds: device-mapper: 30 Apr 2007; Daniel Drake <[EMAIL PROTECTED]> +files/device-mapper.rc, +device-mapper-1.02.18-r1.ebuild: Add baselayout-2 init script The latest stable version of device-mapper is 1.02.19-r1 and this contains the init-script. lvm2: 09 May 2007; Doug Goldstein <[EMAIL PROTECTED]> +files/lvm.rc, lvm2-2.02.17.ebuild: added baselayout-2 compatible init script from bug #175983 For lvm2 this was added without increasing the ebuild revision, but later there were some updates of lvm2, so all users of ~arch that are up to date should have this. Maybe baselayout2 could get some blockers against too old versions of device-mapper/lvm2. Greetings Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
Hi there! What do you think about adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK. This will no longer bother the user with updating these files. Thus it will reduce the number of bugs triggered by forgotten config-file updates. If user needs home-brewn rules he is requested to add own files, and not use the already existing ones. Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New Developer: Christian Hoffmann (hoffie)
On Sonntag, 19. August 2007, Christian Heim wrote: > It's my pleasure to introduce to you Christian Hoffmann (also known as > hoffie on IRC), our latest addition joining the PHP herd. > > Christian is joining us from Bamberg (which is about 60km north of Welcome onbord Christian! +1 for german conspiracy. Lets found a franconian sub-conspiracy ;) Greets from Erlangen Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Mittwoch, 20. Juni 2007, Olivier Crête wrote: > > I will claim that almost any file in /etc is potentially sensitive (even > if it does not contain passwords, if may contain other informations > interesting to a cracker). And even if we did what you propose, we'd run > the risk of missing some and giving the user a false sense of security. > > Maybe we should document somewhere that the only way to make bin pkg > that are safe for public distribution is to do emerge -b or -B .. And > that pkgs built with quickpkg may contain sensitive information. If there is smart conf-file updating inside pkg_preinst(), I think even emerge -b could be unsafe. Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New developer: Thomas Scharl (think4urs11)
On Samstag, 14. April 2007, Christian Heim wrote: > It's my pleasure to introduce to you Thomas Scharl (also known as > think4urs11), our latest addition joining the forum moderators. > > Thomas is joining us from Nürnberg (or Nuremberg), Germany, where he's > currently working for an unnamed Networking/Security company. > > Please welcome Thomas as a new, fellow developer among us ! > Welcome Thomas! Wow, new gentoo members in less than 100km distance. I'm from Erlangen :) Zzam -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] base packages up for grabs
On Sonntag, 8. April 2007, Mike Frysinger wrote: > sys-power/nvram-wakeup VDR-Team can look at it. Matthias -- Matthias Schwarzott (zzam) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /lib/rcscripts or /$(get_libdir)/rcscripts?
On Dienstag, 27. März 2007, Georgi Georgiev wrote: > I just realized that there not only doesn't seem to be any consensus > about what the location of /lib/rcscripts should be (as witnessed by > the location where the following packages install > > lib64/rcscripts sys-apps/baselayout-1.13.0_alpha12 > lib64/rcscripts sys-apps/gawk-3.1.5-r3 > lib64/rcscripts sys-fs/mdadm-2.6.1 > lib/rcscriptssys-fs/device-mapper-1.02.12 > lib/rcscriptssys-fs/lvm2-2.02.17 > lib/rcscriptssys-fs/udev-107 > Same problem with udev-helper programs: Should they be in /lib/udev or in /$(get_libdir)/udev Matthias -- Matthias Schwarzott (zzam) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] removal of /etc/dev.d - cleanup of /etc/udev/rules.d/
On Donnerstag, 15. März 2007, Matthias Schwarzott wrote: > Hi fellows! > > 1. I am going to remove the legacy call of /etc/dev.d from our default > udev-rules. > > # always run /etc/dev.d/ stuff for now. > #RUN+="udev_run_devd $env{SUBSYSTEM}" > > If I get no votes against, this will happen on 2007/03/20. > As there were no objections, I unmasked it today. Matthias -- Matthias Schwarzott (zzam) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] removal of /etc/dev.d - cleanup of /etc/udev/rules.d/
On Donnerstag, 15. März 2007, Matthias Schwarzott wrote: > Hi fellows! > > > 2. I think we should get udev rules directory (/etc/udev/rules.d/) a bit > more cleaned up. > > At the moment a lot of packages install their files prefixed with 99. > I does not like that, and in the future that should perhaps be moved to > some numbers below 95, as I hope to get 95-udev-late.rules to be the last > one called. > This is a (possibly incomplete) list of ebuilds installing udev-rules: app-crypt/ccid-1.2.0.ebuild: 60-pcscd_ccid.rules app-crypt/ccid-1.2.1.ebuild: 60-pcscd_ccid.rules app-misc/lirc-0.8.1: 10-lirc.rules app-misc/lirc-0.8.0-r5: 10-lirc.rules app-misc/lirc-0.8.0-r8: 10-lirc.rules app-misc/usbirboy-0.2.1-r1: 55-usbirboy.rules sys-power/nut-2.0.5: 70-nut-usbups.rules sys-power/nut-2.0.5-r1: 70-nut-usbups.rules sys-power/nut-2.0.4: 70-nut-usbups.rules sys-power/nut-2.0.4-r1: 70-nut-usbups.rules sys-power/nut-2.0.3: 70-nut-usbups.rules sys-power/nut-2.0.3-r1: 70-nut-usbups.rules media-gfx/iscan-2.2.0-r1: 75-iscan.rules media-gfx/iscan-2.4.0: 75-iscan.rules media-gfx/iscan-2.4.0-r1: 99-iscan.rules media-gfx/sane-backends-1.0.18-r2: 99-libsane.rules media-libs/libgphoto2-2.3.1-r3: 99-libgphoto2.rules media-libs/libgphoto2-2.3.1-r2: 99-libgphoto2.rules media-libs/libgphoto2-2.2.1-r1: 99-libgphoto2.rules media-libs/libgphoto2-2.3.1-r4: 99-libgphoto2.rules media-libs/svgalib-1.9.25: 30-svgalib.rules media-libs/svgalib-1.9.24: 30-svgalib.rules media-libs/libmtp-0.1.3: 65-mtp.rules media-libs/libmtp-0.0.21: 65-mtp.rules sys-apps/pcfclock-0.44-r3: 55-pcfclock.rules sys-apps/pcfclock-0.44-r2: 55-pcfclock.rules sys-auth/bioapi-1.2.2: 51-bioapi.rules app-emulation/virtualbox-modules-1.3.6-r1: 60-virtualbox.rules app-emulation/virtualbox-modules-1.3.8: 60-virtualbox.rules app-emulation/virtualbox-: 60-virtualbox.rules app-emulation/kqemu-1.3.0_pre9: 48-qemu.rules app-emulation/kqemu-0.7.2: 48-qemu.rules app-emulation/kqemu-1.3.0_pre5: 48-qemu.rules app-emulation/kqemu-1.3.0_pre11: 48-qemu.rules app-emulation/kqemu-1.3.0_pre7: 48-qemu.rules net-misc/zaptel-1.2.11-r1: 10-zaptel.rules net-misc/zaptel-1.0.10-r2: 10-zaptel.rules net-misc/zaptel-1.2.9.1-r1: 10-zaptel.rules net-misc/zaptel-1.2.12-r1: 10-zaptel.rules net-misc/zaptel-1.2.12: 10-zaptel.rules dev-libs/legousbtower-0.5.4: 20-lego.rules dev-libs/openct-0.6.11-r1: 70-openct.rules dev-libs/linux-fusion-3.2-r1: 60-fusion.rules net-wireless/bluez-utils-2.24: 70-bluetooth.rules net-wireless/bluez-utils-2.25-r1: 70-bluetooth.rules sys-fs/cowloop-2.15-r1: 70-cow.rules sys-fs/cowloop-3.0-r2: 70-cow.rules sys-fs/multipath-tools-0.4.7-r1: 40-multipath.rules media-sound/alsa-firmware-1.0.14_rc3: 52-usx2yaudio.rules media-sound/alsa-firmware-1.0.14_rc2-r1: 52-usx2yaudio.rules media-video/em8300-modules-0.15.3: 15-em8300.rules media-video/em8300-modules-0.16.0-r1: 15-em8300.rules app-antivirus/clamav-0.88.7-r2: 60-dazuko.rules app-antivirus/clamav-0.88.7-r1: 60-dazuko.rules net-dialup/misdn-1.0.4: 53-misdn.rules net-dialup/slmodem-2.9.11_pre20061021-r2: 55-slmodem.rules net-dialup/ltmodem-8.31_alpha10-r3: 55-ltmodem.rules media-tv/wis-go7007-0.9.8: wis-ezusb.rules If you maintain such a package can you please check if the rules use no syntax-elements being deprecated, and going to be removed in future udev-versions, like BUS: replaced by SUBSYSTEM/SUBSYSTEMS SYSFS: replaced by ATTR/ATTRS or others. These packages even checks for /dev/.udev existence to install rules files: I think that they should unconditionally install that file. sys-apps/pcfclock-0.44-r3 sys-apps/pcfclock-0.44-r2 Matthias -- Matthias Schwarzott (zzam) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [RFC] removal of /etc/dev.d - cleanup of /etc/udev/rules.d/
Hi fellows! 1. I am going to remove the legacy call of /etc/dev.d from our default udev-rules. # always run /etc/dev.d/ stuff for now. #RUN+="udev_run_devd $env{SUBSYSTEM}" If I get no votes against, this will happen on 2007/03/20. Only ebuilds still installing stuff there are (found via grep): sys-apps/hal-0.5.7.1-r3 sys-apps/hal-0.5.7-r3 sys-auth/pam_console-0.99.7.0.2.7 2. I think we should get udev rules directory (/etc/udev/rules.d/) a bit more cleaned up. At the moment a lot of packages install their files prefixed with 99. I does not like that, and in the future that should perhaps be moved to some numbers below 95, as I hope to get 95-udev-late.rules to be the last one called. Then it is more easy to debug rules, if we can get the complete event environment from the debug rules there. Perhaps we should create some convention, like installing all additional rule files prefixed with 80- or similar. Matthias -- Matthias Schwarzott (zzam) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] dont use `which` in ebuilds
On Dienstag, 13. März 2007, Ned Ludd wrote: > On Mon, 2007-03-12 at 19:15 -0400, Mike Frysinger wrote: > > On Monday 12 March 2007, Mike Frysinger wrote: > > > instead, since we require bash for our ebuilds, use the builtin `type > > > -p` > > > > err i botched that ;) > > > > `type -p` is almost a complete drop in replacement for which ... it does > > not work on bash builtins however, so people should use `type -P` to > > force the PATH search > > > > in other words, `type -p echo` would return "" while `type -P echo` would > > return "/bin/echo" > > -mike > > Quick search shows the following ebuilds are abusing this behavior. > The scripts installed by these ebuilds also use which: sys-kernel/module-rebuild: media-tv/vdrplugin-rebuild: (fixed) R_PORTAGEQ="`which portageq 2>/dev/null`" Matthias -- Matthias Schwarzott (zzam) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] dont use `which` in ebuilds
On Dienstag, 13. März 2007, Thomas de Grenier de Latour wrote: > ./eclass/vdr-plugin.eclass: >if which md5sum >/dev/null 2>&1; then ^^ fixed Matthias -- Matthias Schwarzott (zzam) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Robert Buchholz (rbu)
On Wednesday 27 December 2006 20:38, Petteri Räty wrote: > He hails from Berlin, Germany. Welcome to the German Conspiracy ;) Matthias -- Matthias Schwarzott (zzam) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for adding berlios to thirdpartymirrors.
On Monday 18 December 2006 23:00, David Shakaryan wrote: > Excerpt from the official site: > "BerliOS Developer is a free service to Open Source developers offering > easy access to the best in CVS/SVN, mailing lists, bug tracking, message > boards/forums, task management, site hosting, permanent file archival, > full backups, and total web-based administration." > > > The proposed mirror name is 'berlios' and the three mirrors are: > - http://download.berlios.de > - http://download2.berlios.de > - ftp://ftp.berlios.de/pub > Something along the lines of mirror://berlios/${PN}/${P}.tar.bz2 can be > used in SRC_URI. > > I'm sure all of you understand that not much work would be necessary for > the the transition as it can occur over time, for example when package > maintainers modify an ebuild. So, what do you folks think? Hm, I think this should be fine. I only have one point against this: Has the issue of different files for every download be solved? Thread listed here: http://thread.gmane.org/gmane.linux.gentoo.devel/36077 Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] unconditionally depending on sys-apps/hotplug
Hi fellow devs! One thing that annoys me since some time are packages pulling in sys-apps/hotplug unconditionally. How should the dependencies on hotplug/hotplug-base and udev be managed: Some problems with current tree: The problem with hotplug is, that it breaks in combination with udev-103 in several ways. One known to me is firmware-loading. Bug https://bugs.gentoo.org/show_bug.cgi?id=147006 Some ebuilds depending on hotplug (incomplete list): DEPEND="sys-apps/hotplug" net-wireless/ipw2200-firmware net-wireless/acx-firmware net-wireless/atmel-firmware media-libs/libgphoto2 sys-apps/hal DEPEND="|| ( sys-fs/udev sys-apps/hotplug )" ./app-emulation/xen-tools DEPEND="|| ( >=sys-fs/udev-103 sys-apps/hotplug )" ./media-tv/wis-go7007 DEPEND="|| ( >=sys-fs/udev-096 >=sys-apps/hotplug-20040923 )" net-wireless/zd1211-firmware DEPEND="udev? ( >=sys-fs/udev-068 ) !udev? ( >=sys-apps/hotplug-20040920 )" sys-apps/pcmciautils Some more problems (minor ones, but even more confusing to users): It installs files not used but confusing users like /etc/hotplug/blacklist. Bug: http://bugs.gentoo.org/show_bug.cgi?id=130766 It creates empty /usr/lib/hotplug/firmware that is no longer used (now: /lib/firmware) Bug: http://bugs.gentoo.org/show_bug.cgi?id=124427 Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites: media-libs/libvideogfx and media-video/sampeg3
# Matthias Schwarzott <[EMAIL PROTECTED]> (29 Nov 2006) # Pending removal Dec 29 2006 # libvideogfx not compiling since years (Bug #69389) # sampeg3 being only package depending on it, no releases # since years, homepage dead (Bug #120563) media-libs/libvideogfx media-video/sampeg3 pgpMUHe9mr29j.pgp Description: PGP signature
[gentoo-dev] Last rites: media-video/vlms and media-video/vls
# Matthias Schwarzott <[EMAIL PROTECTED]> (29 Nov 2006) # Pending removal Dec 29 2006 # No longer supported from upstream. # Are all replaced by the app vlc. media-video/vlms media-video/vls -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org pgpPe2UO26loy.pgp Description: PGP signature
Re: [gentoo-dev] media-tv/nxtvepg needs a maintainer
On Thursday 23 November 2006 19:59, Patrick Kursawe wrote: > Hi all, > > as the subject says: media-tv/nxtvepg needs a maintainer. > > You need > 1) a bttv-style analog TV card (Hauppauge, for example) and of course > 2) some analog tv input for it. > > I have 1) and am lacking 2) since I moved a while ago. As you can see in > bug #153341 it could really need a bit more love than I can currently give > it. > With some patches it can also work with DVB. But I neither have the correct patch nor the time to take just another package. Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org pgpczWtHowggD.pgp Description: PGP signature
Re: [gentoo-dev] Make FEATURES=test the default
On Saturday 05 August 2006 11:33, Kevin F. Quinn wrote: > > IMO devs should be working with "collision-protect sandbox strict > stricter test userpriv" but let's not get too excited ;) Why not discussing what should be default for developers and then having FEATURES=developer activating these flags, but being overwritable when needed. like FEATURES="developer -test" Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org pgpCCNHgYZT7o.pgp Description: PGP signature
Re: [gentoo-dev] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...
On Wednesday 12 July 2006 15:16, Danny van Dyk wrote: > Hi all, > > thanks to djm's efforts i was just able to scan the whole tree using > qualudis. For a start, i'll attach a list of QA violations on missing > entries in IUSE. As this is a minor change to the ebuilds, I'll go on > and fix all the listed ebuilds myself. > > There are 505 ebuilds which are missing use flags in IUSE that they use > in other places. > While reading your list I have seen pcmcia often. e.g. on my ebuild v4l-dvb-hg not supporting pcmcia as conditional. A bit digging showed that linux-mod.eclass contains this code: --cut-- IUSE="" # don't put pcmcia here, rather in the ebuilds that actually support pcmcia SLOT="0" DESCRIPTION="Based on the $ECLASS eclass" RDEPEND="kernel_linux? ( virtual/modutils pcmcia? ( virtual/pcmcia ) )" --cut-- I don't know if pcmcia should then be added to every ebuild including linux-mod.eclass. Please solve this before adding pcmcia on every kernel-module-ebuild. Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org pgpdqMJ1OoKWx.pgp Description: PGP signature
Re: [gentoo-dev] new herd: vdr - topic reanimated
On Monday 10 July 2006 10:08, Jakub Moc wrote: > Robin H. Johnson wrote: > > On Mon, Jul 10, 2006 at 04:36:55AM +0200, Diego 'Flameeyes' Petten?? wrote: > >> On Monday 10 July 2006 02:25, Luca Barbato wrote: > >>> c is simpler. I like it. > >> > >> Yes, of course if _all wranglers_ respected metadata, instead of > >> stopping to tag and assigning to that even when a particular > >> maintainer is listed. > > > > Actually, this isn't that simple at the moment. There are packages that > > directly list me as the maintainer, but I want bugs for them assigned to > > the herd by default - so that the other folk in the herd can find them > > quickly. > > > > Perhaps this could be alleviated with an explicit assign-to field in > > package metadata? At the same time, it should have an explicit cc-to > > field, for cases where the maintainer is not in the herd. > > Well, that reminds me - just stick [EMAIL PROTECTED] (or whatever else) to > maintainer field then and put it first, enough of a hint for me :) Should we then use this metadata-file (maintainer before herd tag): http://www.gentoo.org/dtd/metadata.dtd";> [EMAIL PROTECTED] Gentoo VDR Project media-tv Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org pgprl0Gwn2pR4.pgp Description: PGP signature
Re: [gentoo-dev] new herd: vdr - Comprehension
On Sunday 09 July 2006 19:17, Matthias Schwarzott wrote: We will use the alternative c) - as lu_zero and flameeyes suggested. > c) Using media-tv as herd and [EMAIL PROTECTED] (project's mail-address) as > maintainer. Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org pgpgfOuSENanO.pgp Description: PGP signature
Re: [gentoo-dev] new herd: vdr - topic reanimated
Hi! As the situation now has changed I would like to discuss this one more. Since one week we (hd_brummy and me) have changed our Gentoo VDR Project (http://www.gentoo.org/proj/en/desktop/video/vdr/index.xml) to an official subproject of desktop/video. Now the situation is as follows: Most packages have historically either a) one of us or b) both as a maintainer and the herd media-tv as fallback. c) The newest ebuilds have herd media-tv and [EMAIL PROTECTED] (projects mail-address) as maintainer. We now think that this should be unified. Our ideal would be having the concept of a sub-herd. The best realizable alternatives we can think of are: c) herd media-tv and [EMAIL PROTECTED] (projects mail-address) as maintainer. d) create an own herd vdr. What do you think of that? Zzam -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org pgpA9Hp26uXpb.pgp Description: PGP signature
Re: [gentoo-dev] Re: Addition of a USE_EXPAND-Variable LIRC_DRIVERS and general cleanup of app-misc/lirc
On Sunday 04 June 2006 05:11, Ryan Hill wrote: > Matthias Schwarzott wrote: > > The --with-driver part will be moved to LIRC_DRIVERS. The name need not > > to be LIRC_DRIVERS, tell me if you have a better name for it > > (LIRC_RECEIVERS is another possibility). > > LIRC_DEVICE? most of the USE_EXPAND stuff seems to be named for the device > rather than the driver. eg. ALSA_CARDS, VIDEO_CARDS, INPUT_DEVICES. > > I think these ones are suitable: LIRC_RECEIVERS LIRC_DEVICES I vote for LIRC_DEVICES if there are no more good suggestions. Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Addition of a USE_EXPAND-Variable LIRC_DRIVERS and general cleanup of app-misc/lirc
Hi! If nobody objects I will add LIRC_DRIVERS to USE_EXAPAND tomorrow (sunday 2006/06/04). This will replace as much as possible from the up to now used dirty hack LIRC_OPTS="--with-driver=serial --with-trasmitter --with-irq=4" in make.conf. The --with-driver part will be moved to LIRC_DRIVERS. The name need not to be LIRC_DRIVERS, tell me if you have a better name for it (LIRC_RECEIVERS is another possibility). The other (binary flag) settings will be moved to normal use-flags (--with-transmitter --without-soft-carrier). The only problematic things that will perhaps stay in LIRC_OPTS are things like --with-port=378. But I think most of these settings can also be changed at module-load-time. Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org -- gentoo-dev@gentoo.org mailing list
Re: mercurial.eclass (was: [gentoo-dev] New darcs.eclass)
On Wednesday 24 May 2006 03:30, Aron Griffis wrote: > Matthias, > > Matthias Schwarzott wrote: [Sun May 21 2006, 05:40:53AM EDT] > > > * The eclass copies the downloaded sources to ${S} rather than to > > ${WORKDIR}/${HG_MODULE_NAME}. > > * the unpack-function keeps the current working directory > > in /usr/portage/distfiles/hg-src/${HG_MODULE}. > > Could you try the version from my (new and shiny) overlay? > > http://n01se.net/agriffis/overlay/ > > I think this solves both problems. I didn't create a variable > HG_MODULE_NAME because with mercurial the name of the module is always > the last component of the URL. > > I don't think for your purposes it matters, but you can rename the > local clone by calling mercurial_fetch directly, for example: > > mercurial_fetch http://n01se.net/agriffis/overlay overlay_agriffis > I checked the version from your overlay, and it works like before and also solves the mentioned problems. Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org -- gentoo-dev@gentoo.org mailing list
Re: mercurial.eclass (was: [gentoo-dev] New darcs.eclass)
On Saturday 20 May 2006 15:23, Aron Griffis wrote: > Henrik Brix Andersen wrote: [Sat May 20 2006, 04:50:22AM EDT] > > > On Fri, May 19, 2006 at 10:36:42PM -0400, Aron Griffis wrote: > > > Along these lines, I added my mercurial.eclass to the tree. I use it > > > personally for a couple projects, and figured it might help prevent > > > other people from needing to re-invent the wheel. > > > > Errr... you added a new eclass without posting it to this mailing > > list for review first? > > I've never posted an eclass here for review, and I don't think I've > ever announced one before either, so let's call this progress. ;-) > > If you'd like to review it, I'd appreciate the input. > I am in the process of creating the ebuild v4l-dvb-hg to compile the sources for the development-dvb-driver. I have a few annotations for mercurial.eclass: * The eclass copies the downloaded sources to ${S} rather than to ${WORKDIR}/${HG_MODULE_NAME}. So I have to use S=${WORKDIR}/xyz to unpack it there and have S set to a subdirectory of the hg-sources. * the unpack-function keeps the current working directory in /usr/portage/distfiles/hg-src/${HG_MODULE}. That creates problems when applying patches. Could the eclass switch to ${WORKDIR} after unpacking. Now I use this part of code S=${WORKDIR}/v4l-dvb/v4l src_unpack() { S=${WORKDIR}/v4l-dvb mercurial_src_unpack cd ${WORKDIR} epatch ... } Regards Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] new herd: vdr
Hi! I propose the creation of a new herd - "vdr". It will combine the program media-video/vdr, its plugins (87 plugins now in portage under media-plugins), some programs and some supplementary ebuilds (scripts ...). Most of the ebuilds are at the moment member of media-tv herd. At the beginning hd_brummy and I are going to care about this herd. If there are other developers out there who want to help, please let us know. VDR is an app for watching and recording digital television (dvb/atsc). It can be extended with plugins to not only support dvb input and hardware mpeg2 output. vdr supports hardware-wakeup for recording timers, remotes with lirc, OSD, teletext/subtitles, EPG (electronic program guide) with various different views, burning dvds from recordings, some OSD games, viewing divx files, listening mp3s ... There are addons to scan for advertisments after a recording http://www.linuxtv.org/vdrwiki/index.php/Main_Page Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Addition of DVB_CARDS to USE_EXPAND
On Monday 28 November 2005 22:37, Chris Gianelloni wrote: > On Mon, 2005-11-28 at 21:53 +0100, Matthias Schwarzott wrote: > > Hi! > > > > If nobody objects I will add DVB_CARDS to USE_EXAPAND on next saturday > > (2005/12/03). > > > > This will be used to decide which firmware-file to download and install > > within the to be created media-tv/linuxtv-dvb-firmware ebuild. > > What will the ebuild do if DVB_CARDS is not set? > > Please make it download/install them all. No problem making the default installing all. (That means around ~60Mb download for the whole packet which makes it a bit uncomfortable for users. Installed are just the ~2Mb of firmware files. Most firmware files are contained in driver-files which are around 10mb per driver/firmware file (extracted firmware file is only some kb) but must not be extracted and mirrored cause of license. Before being sure I have to check the licenses inside these driver archives. Up to now I have not found a license file inside every archive.) Zzam -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Addition of DVB_CARDS to USE_EXPAND
Hi! If nobody objects I will add DVB_CARDS to USE_EXAPAND on next saturday (2005/12/03). This will be used to decide which firmware-file to download and install within the to be created media-tv/linuxtv-dvb-firmware ebuild. Zzam -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Proposal: new category media-vdr
Hi Gentoo developers! vdr and its environment has been quite productive and produced more than 130 plugins for vdr. Not all of them are suitable for inclusion into the portage tree but nevertheless I would propose the creation of the category media-vdr for vdr, its plugins and other related packages. For those not knowing what vdr is: vdr (=video disk recorder) is a program to turn a normal pc into an advanced television set-top-box with hard disc recording, timeshifting, etc. Homepage: http://www.cadsoft.de/vdr/ Wiki: http://www.linuxtv.org/vdrwiki/index.php/Main_Page Greetings Matthias Schwarzott -- gentoo-dev@gentoo.org mailing list