Re: [gentoo-dev] [PATCH v2 1/2] */*: Remove dependency on virtual/linuxtv-dvb-headers

[Matthias Schwarzott]

Hi!

These changes will be commited later today.

Regards
Matthias

[gentoo-dev] [PATCH v2 2/2] virtual/linuxtv-dvb-headers: Remove obsolete ebuild

[Matthias Schwarzott]

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

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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

[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


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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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]

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

[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
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)

[Matthias Schwarzott]

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/{...}

[Matthias Schwarzott]

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/{...}

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

Regards
Matthias

[gentoo-dev] Packages up for grabs

[Matthias Schwarzott]

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

[Matthias Schwarzott]

On 29.03.2015 23:29, Davide Pesavento wrote:
 On Sun, Mar 29, 2015 at 9:12 PM, Matthias Schwarzott z...@gentoo.org 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

[gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs

[Matthias Schwarzott]

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

Re: [gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs

[Matthias Schwarzott]

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] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/udev: udev-168-r2.ebuild ChangeLog udev-9999.ebuild

[Matthias Schwarzott]

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.575view=markup plain:
  http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/ChangeLog?re
  v=1.575content-type=text/plain diff :
  http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/ChangeLog?r1
  =1.574r2=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 z...@gentoo.org
  +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.37view=markup plain:
  http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-.eb
  uild?rev=1.37content-type=text/plain diff :
  http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-.eb
  uild?r1=1.36r2=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)

[Matthias Schwarzott]

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

[Matthias Schwarzott]

On Sonntag, 24. April 2011, Michał Górny wrote:
 On Sun, 24 Apr 2011 21:43:16 +0200
 
 Matthias Schwarzott z...@gentoo.org 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

[Matthias Schwarzott]

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] Re: rfc: libexec directory inconsistency

[Matthias Schwarzott]

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

[Matthias Schwarzott]

On Sonntag, 24. April 2011, Michał Górny wrote:
 On Sun, 24 Apr 2011 21:43:16 +0200
 
 Matthias Schwarzott z...@gentoo.org 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] About udev-145: new features / extras and kernel requirements

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

On Samstag, 10. Oktober 2009, Nirbheek Chauhan wrote:
 On Sat, Oct 10, 2009 at 6:42 PM, Alin Năstac mrn...@gentoo.org 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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

On Dienstag, 25. August 2009, Diego E. Pettenò wrote:
 # Diego E. Pettenò flamee...@gentoo.org (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

[Matthias Schwarzott]

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)

[Matthias Schwarzott]

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] Usage of econf with an additional || die

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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?

[Matthias Schwarzott]

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?

[Matthias Schwarzott]

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

[gentoo-dev] merging two packages - upgrade path?

[Matthias Schwarzott]

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] merging two packages - upgrade path?

[Matthias Schwarzott]

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

Re: [gentoo-dev] Re: RFC: qemu - add gcc-3.x dependency

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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.1view=markup plain:
  http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/lirc/lirc-0.8.2-
 r2.ebuild?rev=1.1content-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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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.1view=markup plain:
  http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-plugins/vdr-extrecm
 enu/vdr-extrecmenu-1.0.ebuild?rev=1.1content-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 vdr/timers.h

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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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)

[Matthias Schwarzott]

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)

[Matthias Schwarzott]

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] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK

[Matthias Schwarzott]

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] udev rules cleanup / merging rules files with other distros

[Matthias Schwarzott]

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

[gentoo-dev] [RFC] udev rules cleanup / merging rules files with other distros

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK

[Matthias Schwarzott]

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

[gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK

[Matthias Schwarzott]

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] baselayout-2 LVM

[Matthias Schwarzott]

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

Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK

[Matthias Schwarzott]

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] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK

[Matthias Schwarzott]

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] New Developer: Christian Hoffmann (hoffie)

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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)

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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?

[Matthias Schwarzott]

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/

[Matthias Schwarzott]

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/

[Matthias Schwarzott]

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

Re: [gentoo-dev] dont use `which` in ebuilds

[Matthias Schwarzott]

On Dienstag, 13. März 2007, Thomas de Grenier de Latour wrote:

 ./eclass/vdr-plugin.eclass:
if which md5sum /dev/null 21; then
^^ fixed

Matthias


-- 
Matthias Schwarzott (zzam)
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] dont use `which` in ebuilds

[Matthias Schwarzott]

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] New developer: Robert Buchholz (rbu)

[Matthias Schwarzott]

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.

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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-video/vlms and media-video/vls

[Matthias Schwarzott]

# 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

[gentoo-dev] Last rites: media-libs/libvideogfx and media-video/sampeg3

[Matthias Schwarzott]

# 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

Re: [gentoo-dev] media-tv/nxtvepg needs a maintainer

[Matthias Schwarzott]

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] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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 herd 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):

!DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd;
pkgmetadata
maintainer
email[EMAIL PROTECTED]/email
nameGentoo VDR Project/name
/maintainer

herdmedia-tv/herd
/pkgmetadata

Matthias

-- 
Matthias Schwarzott
Gentoo Developer
http://www.gentoo.org


pgprl0Gwn2pR4.pgp
Description: PGP signature

Re: [gentoo-dev] new herd: vdr - topic reanimated

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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)

[Matthias Schwarzott]

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)

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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

[Matthias Schwarzott]

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