Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
On 5/7/16 4:25 PM, Michał Górny wrote:
> On Sat, 7 May 2016 21:19:31 + (UTC)
> "Joerg Bornkessel" wrote:
>
>> commit: 66afcab271f65b97330e610040ad3acc1b812a03
>> Author: Joerg Bornkessel gentoo org>
>> AuthorDate: Sat May 7 21:18:48 2016 +
>> Commit: Joerg Bornkessel gentoo org>
>> CommitDate: Sat May 7 21:18:48 2016 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2
>>
>> fixed einstall vs. emake install for eapi=6
>>
>> eclass/vdr-plugin-2.eclass | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass
>> index ae09a34..65f1409 100644
>> --- a/eclass/vdr-plugin-2.eclass
>> +++ b/eclass/vdr-plugin-2.eclass
>> @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() {
>> local SOFILE_STRING=$(grep SOFILE Makefile)
>> if [[ -n ${SOFILE_STRING} ]]; then
>> BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install
>> }}
>> -einstall ${BUILD_PARAMS} \
>> +if [[ ${EAPI} == 6 ]]; then
>> +emake install ${BUILD_PARAMS} \
>> +else
>> +einstall ${BUILD_PARAMS} \
>> +fi
>> ${BUILD_TARGETS} \
>> TMPDIR="${T}" \
>> DESTDIR="${D}" \
>>
>
> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?
>
Michal,
How about trying a different tone?
--
Doug Goldstein
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: dev-libs/matrixssl
On 3/19/16 1:39 AM, Aaron Bauman wrote: > # Aaron Bauman (19 Mar 2016) > # Multiple unpatched security vulnerabilities > # per bug #523040. Masked for removal in 30 days. > dev-libs/matrixssl > bug #532040 -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/5] app-emulation/xen-tools: Make use of new python_gen_impl_dep function
On 12/23/15 10:44 AM, Michał Górny wrote:
> ---
> app-emulation/xen-tools/xen-tools-4.2.5-r10.ebuild | 2 +-
> app-emulation/xen-tools/xen-tools-4.2.5-r11.ebuild | 2 +-
> app-emulation/xen-tools/xen-tools-4.5.2-r2.ebuild | 4 ++--
> app-emulation/xen-tools/xen-tools-4.5.2-r3.ebuild | 4 ++--
> app-emulation/xen-tools/xen-tools-4.6.0-r4.ebuild | 2 +-
> app-emulation/xen-tools/xen-tools-4.6.0-r5.ebuild | 2 +-
> 6 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/app-emulation/xen-tools/xen-tools-4.2.5-r10.ebuild
> b/app-emulation/xen-tools/xen-tools-4.2.5-r10.ebuild
> index 67e3d1c..d29aab3 100644
> --- a/app-emulation/xen-tools/xen-tools-4.2.5-r10.ebuild
> +++ b/app-emulation/xen-tools/xen-tools-4.2.5-r10.ebuild
> @@ -68,7 +68,7 @@ DEPEND="dev-libs/lzo:2
> api? ( dev-libs/libxml2
> net-misc/curl )
> ${PYTHON_DEPS}
> - pygrub? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/ncurses} )
> + pygrub? ( $(python_gen_impl_dep ncurses) )
> sys-devel/bin86
> sys-devel/dev86
> dev-lang/perl
> diff --git a/app-emulation/xen-tools/xen-tools-4.2.5-r11.ebuild
> b/app-emulation/xen-tools/xen-tools-4.2.5-r11.ebuild
> index ae93f4d..392be10 100644
> --- a/app-emulation/xen-tools/xen-tools-4.2.5-r11.ebuild
> +++ b/app-emulation/xen-tools/xen-tools-4.2.5-r11.ebuild
> @@ -68,7 +68,7 @@ DEPEND="dev-libs/lzo:2
> api? ( dev-libs/libxml2
> net-misc/curl )
> ${PYTHON_DEPS}
> - pygrub? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/ncurses} )
> + pygrub? ( $(python_gen_impl_dep ncurses) )
> sys-devel/bin86
> sys-devel/dev86
> dev-lang/perl
> diff --git a/app-emulation/xen-tools/xen-tools-4.5.2-r2.ebuild
> b/app-emulation/xen-tools/xen-tools-4.5.2-r2.ebuild
> index 8af652c..ba2f756 100644
> --- a/app-emulation/xen-tools/xen-tools-4.5.2-r2.ebuild
> +++ b/app-emulation/xen-tools/xen-tools-4.5.2-r2.ebuild
> @@ -87,8 +87,8 @@ DEPEND="${COMMON_DEPEND}
> ${PYTHON_DEPS}
> api? ( dev-libs/libxml2
> net-misc/curl )
> - pygrub? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/ncurses} )
> - ovmf? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/sqlite} )
> + pygrub? ( $(python_gen_impl_dep ncurses) )
> + ovmf? ( $(python_gen_impl_dep sqlite) )
> !amd64? ( >=sys-apps/dtc-1.4.0 )
> amd64? ( sys-devel/bin86
> system-seabios? ( sys-firmware/seabios )
> diff --git a/app-emulation/xen-tools/xen-tools-4.5.2-r3.ebuild
> b/app-emulation/xen-tools/xen-tools-4.5.2-r3.ebuild
> index 59e9056..a147169 100644
> --- a/app-emulation/xen-tools/xen-tools-4.5.2-r3.ebuild
> +++ b/app-emulation/xen-tools/xen-tools-4.5.2-r3.ebuild
> @@ -90,8 +90,8 @@ DEPEND="${COMMON_DEPEND}
> ${PYTHON_DEPS}
> api? ( dev-libs/libxml2
> net-misc/curl )
> - pygrub? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/ncurses} )
> - ovmf? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/sqlite} )
> + pygrub? ( $(python_gen_impl_dep ncurses) )
> + ovmf? ( $(python_gen_impl_dep sqlite) )
> !amd64? ( >=sys-apps/dtc-1.4.0 )
> amd64? ( sys-devel/bin86
> system-seabios? ( sys-firmware/seabios )
> diff --git a/app-emulation/xen-tools/xen-tools-4.6.0-r4.ebuild
> b/app-emulation/xen-tools/xen-tools-4.6.0-r4.ebuild
> index 57d618e..e9f84c0 100644
> --- a/app-emulation/xen-tools/xen-tools-4.6.0-r4.ebuild
> +++ b/app-emulation/xen-tools/xen-tools-4.6.0-r4.ebuild
> @@ -87,7 +87,7 @@ DEPEND="${COMMON_DEPEND}
> ${PYTHON_DEPS}
> api? ( dev-libs/libxml2
> net-misc/curl )
> - ovmf? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/sqlite} )
> + ovmf? ( $(python_gen_impl_dep sqlite) )
> !amd64? ( >=sys-apps/dtc-1.4.0 )
> amd64? ( sys-devel/bin86
> system-seabios? ( sys-firmware/seabios )
> diff --git a/app-emulation/xen-tools/xen-tools-4.6.0-r5.ebuild
> b/app-emulation/xen-tools/xen-tools-4.6.0-r5.ebuild
> index 104fac9..ceb1402 100644
> --- a/app-emulation/xen-tools/xen-tools-4.6.0-r5.ebuild
> +++ b/app-emulation/xen-tools/xen-tools-4.6.0-r5.ebuild
> @@ -90,7 +90,7 @@ DEPEND="${COMMON_DEPEND}
> ${PYTHON_DEPS}
> api? ( dev-libs/libxml2
> net-misc/curl )
> - ovmf? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/sqlite} )
> + ovmf? ( $(python_gen_impl_dep sqlite) )
> !amd64? ( >=sys-apps/dtc-1.4.0 )
> amd64? ( sys-devel/bin86
> system-seabios? ( sys-firmware/seabios )
>
Acked-by: Doug Goldstein
I actually made ncurses always required in recent versions to try and
avoid this hack. I'm glad there's a nicer way to officially do this.
--
Doug Goldstein
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Use GLEP27!
On 12/14/15 3:22 AM, Michał Górny wrote: > > > Dnia 13 grudnia 2015 21:41:02 CET, "Robin H. Johnson" > napisał(a): >>On Sun, Dec 13, 2015 at 09:03:51PM +0300, Alexey Shvetsov wrote: >>> Hi all! >>> >>> We trying to use ldap for users @work, many of our workstations >>running >>> binary gentoo based distro called Calculate linux. However if we >>wanna >>> have wide use of ldap there is a need for determenistic system group >>> gids names and user uids. >>> >>> Many ebuilds in tree uses enewgroup and enewuser with -1 (aka next >>> available parameter)[1]. However it will be much better to set distro >> >>> wide deterministic uid and gid for system service name. So for >>example >>> ldap users may have determenistic groups like video, audio, plugdev, >>> etc.. >>GLEP27 was approved for this, however it is barely used. >> >>Convert the rest of the tree to use it, and then you'll be done, aside >>from the existing mess on user systems. > > As far as I can see, this GLEP predates EAPI and does not meet modern > standards. It needs to be updated or killed with fire. > > For a start, relation to EAPI needs to be defined. This will likely > require both profiles and ebuilds to use the new EAPI. > > Also, the contents of 'backwards compatibility' section are > unacceptable. But that's probably going to be covered by EAPI. > > The spec itself is hard to follow, though the idea seems simple. It > makes me wonder if we aren't missing something important there. > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. Don't kill it. The best way forward would be to update it. -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Use GLEP27!
On 12/14/15 12:06 AM, Robin H. Johnson wrote: > On Mon, Dec 14, 2015 at 07:49:42AM +0300, Alexey Shvetsov wrote: >> Hi! >> >> Ok. Since there is GLEP27 we should make it reality. To do so i think we >> should >> 1. Have some list of system uid/gid (on wiki for example). Also we need >> to agree on uid/gid numbers for services > This database was already started, prior to GLEP27. > In CVS, you want gentoo-src/eid_database/ > >> 2. Add uid/gid from list to existing ebuilds > >> 3. Make a repoman (or may be eclass) check, that will no allow to commit >> ebuilds with enewuser enewgroup calls with undefined uids > I think in the original discussion, there were concerns that there were > cases where this was going to be valid. I think this check needs to come > later, after we rule those out. It should however start to warn about > them ASAP. > >> 4. Make some script or howto to migrate to determenistic uids/gids from > Much of the work was implemented for GSOC2006, "Creandus" by > developer pioto. > > Cardoe did more work on it later on. > I'll try to find what I did but at one point I had the database of uid/gid updated to include everything in the tree. I had some patches for enewuser/enewgroup to not allow them to do anything unless the ids were in the database. Sadly, its been a long long time. But I still would love to see this happen. There just wasn't much interest from everyone in making this happen. -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCHES] multilib-build & multilib-minimal EAPI 6 patchset
On 12/6/15 12:57 PM, Michał Górny wrote: > Hi, everyone. > > Here's a patchset for review. Changes: > > 1. eclass-generated variables are read-only, > 2. missing error checks (||die) added, > 3. 'unset -f' used to wipe local and temporary functions from the env, > 4. deprecated function QA warnings turned into bans for EAPI 6, > 5. eutils inherit fixes/updates. > > Please review. I've tested it on a set of randomly selected packages. > > Its worth noting that you should probably be utilizing --cover-letter to git format-patch to generate this. -- Doug Goldstein signature.asc Description: OpenPGP digital signature
[gentoo-dev] news item: libvirt-1.2.19 init script upgrades
The following is the proposed news item to inform OpenRC users of a change to the init script setup for libvirt 1.2.19 and newer. -- Doug Goldstein Title: libvirt-1.2.19 init script changes Author: Doug Goldstein Content-Type: text/plain Posted: 2015-09-09 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-emulation/kvm-kmod
# Doug Goldstein (25 Aug 2015) # Masked for removal in 30 days. Users should use the modules available # via the kernel as upstream has deprecated these packages. app-emulation/kvm-kmod -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] git commit / push signing error
On Mon, Aug 10, 2015 at 3:36 AM, Chí-Thanh Christopher Nguyễn wrote: > Doug Goldstein schrieb: >> gpg: cancelled by user >> gpg: skipped "0xA2BC03DC87ED1BD4": Operation cancelled >> gpg: signing failed: Operation cancelled >> error: gpg failed to sign the data > > There was an IRC discussion yesterday about this. Probably your pinentry > tries to talk to a GUI and fails. Try: > > unset DISPLAY > export GPG_TTY=$(tty) > > to make it fall back to curses, or use "eselect pinentry" to select curses as > default. > > Interestingly, git requires GPG_TTY if eselect-pinentry is set to gtk-2 or > qt4, but repoman doesn't. > > > Best regards, > Chí-Thanh Christopher Nguyễn > > $ eselect pinentry show Current pinentry binary implementation: pinentry-curses $ eselect pinentry list Available pinentry binary implementations: [1] pinentry-curses * Its the only version I've got on this machine. The box is headless and I ssh into and I use keychain to manage my SSH and GPG agent. -- Doug Goldstein
Re: [gentoo-dev] git commit / push signing error
On Sun, Aug 9, 2015 at 9:00 PM, Kent Fredric wrote: > On 10 August 2015 at 13:40, Doug Goldstein wrote: >> $ git push --signed origin master >> >> You need a passphrase to unlock the secret key for >> user: "Doug Goldstein " >> 4096-bit RSA key, ID 0xA2BC03DC87ED1BD4, created 2015-04-24 >> (subkey on main key ID 0x6C4E620431C9980D) >> >> gpg: cancelled by user >> gpg: skipped "0xA2BC03DC87ED1BD4": Operation cancelled >> gpg: signing failed: Operation cancelled >> error: gpg failed to sign the data >> fatal: failed to sign the push certificate >> fatal: The remote end hung up unexpectedly > > > Your GPG is not working correctly. > > eg: echo hello | gpg -a --sign # also fails > > export GPG_TTY=$(tty) > > try again. ( The GPG-Agent associates with the tty it was spawned in > by default, and that tty might have evaporated ) > > > -- > Kent > > KENTNL - https://metacpan.org/author/KENTNL > This was it. Thanks. I use keychain and ssh into the box so I would expect keychain would handle things for me correctly. -- Doug Goldstein
[gentoo-dev] git commit / push signing error
Hoping someone has the answer for me because I'm at a loss. I'm not canceling the operating or hitting any key after . $ git push --signed origin master You need a passphrase to unlock the secret key for user: "Doug Goldstein " 4096-bit RSA key, ID 0xA2BC03DC87ED1BD4, created 2015-04-24 (subkey on main key ID 0x6C4E620431C9980D) gpg: cancelled by user gpg: skipped "0xA2BC03DC87ED1BD4": Operation cancelled gpg: signing failed: Operation cancelled error: gpg failed to sign the data fatal: failed to sign the push certificate fatal: The remote end hung up unexpectedly -- Doug Goldstein
Re: [gentoo-dev] some multilib-minimal enhancements [0/6]: de-headerization
On Wed, Dec 11, 2013 at 3:18 PM, Greg Turner wrote: > sorry for attaching these rather than in-lining but google insists on > 78-wrapping plain-text e-mail. If HTML mail would be a better > solution for people I'd be happy to re-send (unless maybe a single > person requests it and a chorus of objections are raised :P). > > This series is available also in bug #493214. Use git send-email, works perfectly fine with gmail. Attachments are worthless and mostly considered spam. -- Doug Goldstein
Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC
On Wed, Dec 11, 2013 at 6:37 PM, Patrick Lauer wrote: > On 12/12/2013 04:41 AM, William Hubbs wrote: >> All, >> >> We got a request from Debian to rename the "rc" binary of OpenRC due to >> a naming conflict they have. They have a port of the at&t plan 9 shell, >> which has a binary named "rc" as well[1]. >> >> My thought is to rename our "rc" to "openrc", since that would be >> unique. > > Make it build-time configurable. Keep default at "rc". Let Debian and > others rename it as they want/need. > >> I know at least one thing that will break is everyone's inittab, so >> should I sed their inittab in our live ebuild or expect them to fix it >> and give a warning? > > It's change to change things, it doesn't fix any bugs we have. > > So don't break things for fun, please ... Honestly, with Linux systems a symlink won't matter. Just rename the binary to "openrc" so that we are closer with Debian. It would be nice if in the future docs and blogs and other things could share the same info. For Gentoo just symlink rc -> openrc and call it a day. There's also no reason to remove the symlink in the next release like others have said. Keep the thing around for as long as is possible. Cause if you drop it, you're liable to break someone upgrading an old system and they have a higher chance to miss an important ewarn and you know how much I hate breaking upgrades. -- Doug Goldstein
Re: [gentoo-dev] rfc: status of OpenRC's public API
On Sat, Sep 14, 2013 at 11:35 AM, William Hubbs wrote: > On Sat, Sep 14, 2013 at 12:47:04AM -0400, Alexandre Rostovtsev wrote: >> On Fri, 2013-09-13 at 22:48 -0500, William Hubbs wrote: >> > On Fri, Sep 13, 2013 at 09:04:06PM -0400, Alexandre Rostovtsev wrote: >> > > app-admin/openrc-settingsd uses various functions (rc_sys(), >> > > rc_runlevel_get(), rc_service_exists(), rc_service_in_runlevel(), >> > > rc_service_resolve(), rc_service_mark() etc.) from rc.h >> > >> > Will this still be needed once gnome 3.8 is stable everywhere? >> >> It will not be needed for gnome. Possibly another desktop environment >> might have a use for it. > > Running " grep -r 'app-admin/openrc-settingsd' ." in a current > gentoo-x86 tree shows the following output: > > ./app-admin/openrc-settingsd/openrc-settingsd-1.0.1.ebuild:# $Header: > /var/cvsroot/gentoo-x86/app-admin/openrc-settingsd/openrc-settingsd-1.0.1.ebuild,v > 1.8 2013/02/02 22:20:11 ago Exp $ > ./app-admin/openrc-settingsd/ChangeLog:# ChangeLog for > app-admin/openrc-settingsd > ./app-admin/openrc-settingsd/ChangeLog:# $Header: > /var/cvsroot/gentoo-x86/app-admin/openrc-settingsd/ChangeLog,v 1.10 > 2013/02/02 22:20:11 ago Exp $ > ./app-admin/openrc-settingsd/CVS/Repository:gentoo-x86/app-admin/openrc-settingsd > ./gnome-base/gnome-control-center/gnome-control-center-3.8.3.ebuild:|| ( > ( app-admin/openrc-settingsd sys-auth/consolekit ) >=sys-apps/systemd-31 ) > ./gnome-base/gnome-control-center/gnome-control-center-3.8.4.1-r1.ebuild: > || ( ( app-admin/openrc-settingsd sys-auth/consolekit ) > >=sys-apps/systemd-31 ) > ./gnome-base/gnome-control-center/gnome-control-center-3.8.4.1.ebuild: || ( > ( app-admin/openrc-settingsd sys-auth/consolekit ) >=sys-apps/systemd-31 ) > ./gnome-base/gnome-control-center/gnome-control-center-3.6.3-r1.ebuild: > app-admin/openrc-settingsd > ./gnome-extra/cinnamon/cinnamon-1.8.8.1.ebuild: > app-admin/openrc-settingsd > ./gnome-extra/cinnamon/cinnamon-1.6.7-r2.ebuild: > app-admin/openrc-settingsd > > It looks like this is gnome specific to me. > > I would be concerned about another desktop environment linking to these > libraries because that seems to be the same type of vertical integration > gnome is doing with systemd. > linking to these libraries because that seems to be the same type of > vertical integration gnome is doing with systemd. > > William > Cinnamon is not requiring systemd, so removing openrc-settingd will break that environment. -- Doug Goldstein
Re: [gentoo-dev] rfc: stabilization policies
On Tue, Aug 20, 2013 at 7:42 PM, Rich Freeman wrote: > On Tue, Aug 20, 2013 at 5:03 PM, Andreas K. Huettel > wrote: > > > > Stable implies "not so often changing". If you really need newer > packages on a > > system that has to be rock-solid, then keyword what you need and nothing > else. > > ++ > > 30 days is too long? How can something new be stable? Stable doesn't > mean "I don't think this is broken." Stable means "lots of others > have already been using this and so far there aren't many reports of > breakage." > Stable also means this is less broken than current stable. In the past I've gotten push back from arch teams on all sorts of items I consider to be unrelated to the stabilization request. Yes it'd be great if the world was black and white and 30 days was a magical cut off but many times its not. If current stable is causing a crash or some bad user case, I'll ask for a quick stabilization of a revbump that contains a small scope patch that a user can confirm it fixes the issue. > > According to distrowatch RHEL is at 2.6.32. I'm sure it has a > bazillion backports, but that is what I'd call stable. Running stable > means starting to use the stuff everybody else is about ready to stop > using. When an upstream releases a new stable release, that means > that it is just now ready for testing, and chances are they'll have > another stable release before their previous release really is stable. > Apples and oranges. Its 2.6.32 for the kabi, which they maintain and support. They have plenty of things that landed in 3.7 in RHEL 6.4. They have a solid QA procedure to vet their kernels and they're not afraid to turn the crank on small targeted fixes and pushing those out to resolve issues as the release matures. > > If you need the release two days after it comes out, you're not really > looking for a stable release. > > At work we typically buy stuff about a year after it comes out, and by > the time we're done doing integration and testing it is probably two > years old and we've gotten 27 patches in the meantime. That's stable. > Correlation is not causation. Just because software or hardware sat of the shelf for a year doesn't mean its any more or less stable when it was originally shipped. If a vendor has a high level of QA with multi-layed test processes that product will probably more stable out the door than a vendor with no QA that kicked the product out the door and let their early adopters find the bugs over the past year. I say probably because again the world isn't black and white. Your use case with both products could be exposing a corner case that no user before you and no QA engineer before you had tried and both products will go boom. > > Gentoo is one of the few distros that really lets you mix and match, > so run stable on the stuff you don't care about, and if the purpose of > the box is to serve apps on Rails then by all means use ~arch on Ruby. > You can do that and not worry about whether it is going to be broken > by the latest glibc or coreutils or whatever. > > Rich > > Its also precisely that mix and match that might cause instability due to people not testing things. Case in point QEMU 1.6.0 just came out and it went through a number of release candidates but no one ever saw that it depends only on Python 2.4 but actually needs Python 2.6. That's kind of like Gentoo, a package says it depends on libfoo 1.0 or higher and the dev that tested stable baz 0.8 confirmed it worked with libfoo 1.0, but baz 0.9 in ~arch still depends on libfoo 1.0 but really needs libfoo 1.1 and libfoo 1.1 is ~arch as well. So the developer running ~arch believed that baz 0.9 works fine since he has ~arch libfoo. My point is what Gentoo calls "stable" is just something that usually 2 or more people have compiled and installed vs ~arch which 1 or more people have compiled and installed. -- Doug Goldstein
Re: [gentoo-dev] Re: [gentoo-user] OpenRc-0.12 is coming soon
On Fri, Aug 16, 2013 at 10:30 PM, Dale wrote: > Doug Goldstein wrote: > > > > sys-apps/etckeeper is what you want. Works great. It even has portage > > integration. Though I'd recommend going with the ~arch version instead > > of stable for that portion. > > > > -- > > Doug Goldstein > > I think this is something dispatch-conf does too. I use that but still > make a backup myself, just in case. Generally, a successful reboot is a > good sign that the configs are working. > > Going to look into this but the home page doesn't really show me much, yet. > > > You'll want USE=cron enabled so that you get the benefits of etckeeper taking a note of someone or something changing a config and not committing it. Additionally without USE=cron, when you emerge the next package etckeeper will think that the most recent package you emerged changed a file that it didn't if you manually changed a file. Once that's done just do: # etckeeper init -d /etc # bzcat /usr/share/doc/etckeeper-1.7/examples/bashrc.bz2 >> /etc/portage/bashrc And you're set. -- Doug Goldstein
Re: [gentoo-dev] Re: [gentoo-user] OpenRc-0.12 is coming soon
On Fri, Aug 16, 2013 at 11:46 AM, Rich Freeman wrote: > On Fri, Aug 16, 2013 at 12:14 PM, Ian Stakenvicius wrote: > > For everyone's information -- The conf.d/net removal on upgrade is a > > packaging issue, which could not have been tested prior to > > openrc-0.12.ebuild hitting the tree. There are details in > > https://bugs.gentoo.org/show_bug.cgi?id=481336 if anyone's interested > > in why it's happening. > > > > I've fixed the 0.12.ebuild in the tree now. It's a hack but it seems > > to be the best possible solution. > > Thanks for the update. From the other report it seems unlikely that > calling for volunteers would have turned up much. > > That's just the nature of ~arch - if you get an openrc update you're > among the first. Gentoo users should know what they're doing > regardless, and ~arch users doubly-so. > > Also, it really isn't Gentoo-specific, but putting /etc in a git repo > is a really good practice, and I'm wondering if it should go in the > handbook as a result. > > Rich > > sys-apps/etckeeper is what you want. Works great. It even has portage integration. Though I'd recommend going with the ~arch version instead of stable for that portion. -- Doug Goldstein
Re: [gentoo-dev] renaming gentoo-oldnet
On Sat, Aug 3, 2013 at 7:30 PM, William Hubbs wrote: > On Sun, Aug 04, 2013 at 01:49:46AM +0300, Alon Bar-Lev wrote: >> On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs wrote: >> > Actually the plan is to generalize it so that it works with other init >> > systems. Right now it is very tightly integrated with OpenRc, but there >> > is interest in changing that, so adding openrc to the name would be >> > misleading eventually. >> >> OK... so gentoo-networking? or just come up with own name? best-networking? > > I don't know about "best-networking". ;-) One reason we are splitting it > out also is so it can have its own development/release cycle; the > oldnet stuff is responsible for about 1/3 of the bugs against OpenRc > right now, and it is very difficult to test because of all of the > possibilities. You and I have had this talk more times than I can remember at this point. Using the name "oldnet" sucks and was one of the worst choices possible. Looking through our IRC chats, I had also suggested gentoo-networking. Its really a shame because this dependency based networking is really one of the real strengths of Gentoo and its really just being given the cold shoulder. Our dependency based init system was one of the reasons many people used Gentoo back in the day (besides the zomg its source its faster use -O6 crowd). In our discussions I've suggested trimming back the support in the networking scripts from all the various options (they support 4 DHCP clients for example) and slowly push these scripts to be installed by the package and maintained by the package maintainer (e.g. the pump script can be managed by the net-misc/pump maintainer and so on and so forth). Give them a name (systemd did by calling these snippets unit files) like OpenRC net snippets (Don't let me come up with names, I'm not good at that part, just ask my co-workers) and maintain an "API" for them. > >> However, I do not understand how you can port it without changing the >> notations... or lowering features... example: rc_net_*_provide, >> rc_net_*_need, or the rc_config, rc_use, rc_net_*_provide="!net" >> etc... >> >> Do you think systemd users can understand that /etc/conf.d/net is >> actually a shell script? I hope this is not going to be eliminated, as >> I use it a lot. > > Robin is going to do most of it I think; I'm not exactly sure what he > has in mind. > > William > If we lose that flexibility and configurability then just give up on OpenRC right now cause its dead because all interesting features are gone and it'll just become an inferior init system that needs to be replaced. -- Doug Goldstein
Re: [gentoo-dev] [PATCH] gnome2.eclass does not respect ECONF_SOURCE
On Thu, May 23, 2013 at 2:31 PM, Mike Frysinger wrote:
> On Thursday 09 May 2013 12:59:11 Pacho Ramos wrote:
> > El mié, 08-05-2013 a las 20:59 -0400, Mike Frysinger escribió:
> > > On Wednesday 05 December 2012 18:02:51 Doug Goldstein wrote:
> > > > - if grep -q "disable-scrollkeeper" configure; then
> > > > + if grep -q "disable-scrollkeeper" ${ECONF_SOURCE:-.}/configure;
> then
> > >
> > > ECONF_SOURCE should be quoted
> > > -mike
> >
> > If it doesn't cause any problem (it shouldn't, I think), feel free to
> > commit adding the quotes. Thanks for noticing! (will CC gnome team to
> > keep them aware)
>
> Index: gnome2.eclass
> ===
> RCS file: /var/cvsroot/gentoo-x86/eclass/gnome2.eclass,v
> retrieving revision 1.120
> diff -u -p -r1.120 gnome2.eclass
> --- gnome2.eclass 16 Jan 2013 23:01:02 - 1.120
> +++ gnome2.eclass 23 May 2013 19:31:00 -
> @@ -122,7 +122,7 @@ gnome2_src_configure() {
> # Remember to drop 'doc' USE flag from your package if it was only
> used to
> # rebuild docs.
> # Preserve old behavior for older EAPI.
> - if grep -q "enable-gtk-doc" ${ECONF_SOURCE:-.}/configure ; then
> + if grep -q "enable-gtk-doc" "${ECONF_SOURCE:-.}"/configure ; then
> if has ${EAPI:-0} 0 1 2 3 4 && in_iuse doc ; then
> G2CONF="$(use_enable doc gtk-doc) ${G2CONF}"
> else
> @@ -132,29 +132,29 @@ gnome2_src_configure() {
>
> # Pass --disable-maintainer-mode when needed
> if grep -q "^[[:space:]]*AM_MAINTAINER_MODE(\[enable\])" \
> - ${ECONF_SOURCE:-.}/configure.*; then
> + "${ECONF_SOURCE:-.}"/configure.*; then
> G2CONF="--disable-maintainer-mode ${G2CONF}"
> fi
>
> # Pass --disable-scrollkeeper when possible
> - if grep -q "disable-scrollkeeper" ${ECONF_SOURCE:-.}/configure;
> then
> + if grep -q "disable-scrollkeeper" "${ECONF_SOURCE:-.}"/configure;
> then
> G2CONF="--disable-scrollkeeper ${G2CONF}"
> fi
>
> # Pass --disable-silent-rules when possible (not needed for
> eapi5), bug
> #429308
> if has ${EAPI:-0} 0 1 2 3 4; then
> - if grep -q "disable-silent-rules"
> ${ECONF_SOURCE:-.}/configure; then
> + if grep -q "disable-silent-rules"
> "${ECONF_SOURCE:-.}"/configure; then
> G2CONF="--disable-silent-rules ${G2CONF}"
> fi
> fi
>
> # Pass --disable-schemas-install when possible
> - if grep -q "disable-schemas-install" ${ECONF_SOURCE:-.}/configure;
> then
> + if grep -q "disable-schemas-install"
> "${ECONF_SOURCE:-.}"/configure; then
> G2CONF="--disable-schemas-install ${G2CONF}"
> fi
>
> # Pass --disable-schemas-compile when possible
> - if grep -q "disable-schemas-compile" ${ECONF_SOURCE:-.}/configure;
> then
> + if grep -q "disable-schemas-compile"
> "${ECONF_SOURCE:-.}"/configure; then
> G2CONF="--disable-schemas-compile ${G2CONF}"
> fi
>
> -mike
>
I guess I forgot to commit that to the tree when I posted it a few days
ago/week, w/e. Yeah commit that. My original commit was wrong.
--
Doug Goldstein
Re: [gentoo-dev] sys-apps/texinfo vs @system
On Sun, Mar 31, 2013 at 12:59 AM, Mike Frysinger wrote: > the new texinfo-5.x series has rewritten makeinfo in perl. the main `info` > program is still in pure C. > > when it comes to packages installing .info pages, it's largely limited to the > GNU projects as the format has never really caught on. many of those projects > also install man pages. > > personally, i've never found info pages usable. for most utils, the man pages > or the --help output is sufficient, and for people doing heavy development, > the > online html manuals are significantly more useful. agreed. > > when it was pure C, i could live with it as it's only <1MiB and no real deps > to speak of. now it's more like 3MiB, and pulls in 3 semi-uncommon additional > perl packages (not to mention perl itself). > > it's in @system for two reasons: it provides `info` and `makeinfo`. the > former is for reading info pages (i.e. RDEPEND) while the latter is used for > generating info pages (i.e. DEPEND) when the tarball didn't ship with them > pregenerated (they usually do). > > one option would be to make the makeinfo stuff into a USE flag so all the perl > junk isn't pulled in by default. only the packages that actually generate > info pages can DEPEND on that. > > it'd be simpler if we just dropped it altogether from @system. if people want > `info`, they can `emerge` it themselves. if packages want `makeinfo`, they > can DEPEND on it -- few fall into this category (<100 by a rough survey of > random Gentoo installs). > > obviously my preference is for the latter. > -mike I agree with the later as well. -- Doug Goldstein
[gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers
One of the reasons people volunteer in open source projects is to scratch their personal itch. When that itch develops into a festering, gangrenous limb it becomes time to amputate it. That is what I am doing with my involvement in x11-drivers/nvidia-drivers. As a result someone will need to work with spock and rej to figure out what aspects they are able to maintain and then maintain the components they aren't able to. For example, different hardware has different series of drivers to support it. -- Doug Goldstein
Re: [gentoo-dev] Building against /usr/src/linux and linux-info.eclass
On Thu, Feb 21, 2013 at 12:42 PM, Anthony G. Basile wrote: > Hi everyone, > > This issue has come up in a few bugs so I want to bounce it off the > community. When building packages that need a configured kernel source > tree, many ebuilds inherit linux-info to find configuration info about the > kernel. However, there is the running kernel with its configuration > (/proc/config.gz if it exists), there is the kernel source tree > (/usr/src/linux if it exists and is configured) and both of these can be of > a different version than linux-headers. Since building modules consumes > headers from /usr/include/linux, but uses code from /usr/src/linux and then > these modules are expected to insmod against the running kernel, all of > which can be mismatched, we have a lot of room for breakage. Eg. bug > #458014. > > Any ideas about how to deal cleanly with situations like that? > > -- > Anthony G. Basile, Ph. D. > Chair of Information Technology > D'Youville College > Buffalo, NY 14201 > (716) 829-8197 > Kernel modules never use /usr/include/linux. That's the uapi headers, which are now broken out in 3.7 and newer. Kernel modules always use /usr/src/linux. There have been a number of issues with the differences between the user space bits and the kernel space bits wrt to netfilter post 3.0, so its not surprising that a userspace component is trying to use /usr/include/linux to frame up a structure to pass into kernel space via netlink and running into an issue. This is one of the reasons behind kapi/uapi to make it clear you shouldn't play with or touch this field/structure/value from user space. -- Doug Goldstein
Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
On Fri, Feb 8, 2013 at 11:53 AM, Samuli Suominen wrote: > Any objections if I slap a generic package.mask on every firmware package > installing to wrong directory? > Half of them install to /$(get_libdir)/firmware as opposed to correct > /lib/firmware. > Most of them are maintainer-needed@ and very old. > > Then intrested parties get to fix what they want and unmask? > > - Samuli > Whatever is correct and sticks should have a pkgmove added so that users don't have long lasting issues. -- Doug Goldstein
Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree
On Fri, Jan 25, 2013 at 5:51 PM, Mike Frysinger wrote: > i've taken Constanze' work and rewritten it a bit to be easier to use (imo) as > most settings are now defaults > -mike > Good deal. Good idea on using USE=filecaps instead of USE=caps due to the requirements. Once this hits the tree I'll likely start using it for app-emulation/qemu. -- Doug Goldstein
Re: [gentoo-dev] Separately buildable binary blobs
On Sun, Jan 20, 2013 at 10:45 PM, Peter Stuge wrote: > Doug Goldstein wrote: >> sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios, >> sys-firmware/vgabios > .. >> So basically, how important is it to keep supporting these separately >> buildable blobs knowing that it might slow the release of QEMU within >> our own tree. > > Each of those sys-firmware/ packages have quite significant use cases > well outside of QEMU. Aware of that, but no one added them to the tree prior to me adding them to the tree for QEMU. Since then I haven't had a single user report a bug or contact me in any way about using it outside of QEMU. The one exception is myself with ipxe as I use that at work to provide something similar to boot.fedoraproject.org but on a much grander scale. > > Note also that in particular SeaBIOS but possibly the others too are > really recommended to build with a separate, known-good, toolchain - > even if you're building for the same platform that you run on. Aware of that as well, you'll notice we have always defaulted to using pre-built binaries of the releases by Kevin O'Connor the upstream maintainer and for any bugs reported with QEMU if someone built their own BIOS I always tell them they need to try with the upstream blob. The point of my original post was we go through the effort to ALLOW users to build their own binary blobs but is it really necessary as part of our culture? If this was Debian the answer would obviously be yes. -- Doug Goldstein
Re: [gentoo-dev] Lastrites: app-misc/secure-delete, app-misc/ccal, www-apache/mod_vhs, app-portage/epm, www-apps/online-bookmarks, sys-apps/i2c
On Thu, Jan 17, 2013 at 1:21 PM, Pacho Ramos wrote: > # Pacho Ramos > # Dead since 2003, doesn't work with journaling filesystems. > # Also collides with dev-util/smem (#288721). Removal in a month. > app-misc/secure-delete > FWIW, we also have app-misc/scrub in the tree which likely does similar things. http://code.google.com/p/diskscrub/ -- Doug Goldstein
[gentoo-dev] Separately buildable binary blobs
How important are separately buildable binary blobs? Rather than speak in terms of app/foo and app/bar, I'll just come out and say its app-emulation/qemu. Due to the nature of the package it relies on firmware blobs to emulate certain aspects of the system (e.g. BIOS). I've been working on making each of the binary blobs buildable and adding them to the tree e.g. sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios, sys-firmware/vgabios. Unfortunately QEMU upstream keeps their own repos of the various components and for each release builds their own and commits it within their repo. They ship with these pre-built blobs and that is what they install by default. The result is from the true package upstreams there often is not a release that works with QEMU. For example, QEMU 1.3.0 requires a git revision of SeaBIOS. So basically, how important is it to keep supporting these separately buildable blobs knowing that it might slow the release of QEMU within our own tree. -- Doug Goldstein
Re: [gentoo-dev] removing the server profiles...
On Wed, Jan 16, 2013 at 8:16 AM, Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 16/01/13 08:32 AM, Panagiotis Christopoulos wrote: >> On 00:36 Wed 16 Jan , Andreas K. Huettel wrote: >>> several people have pointed out to me that the 10.0 -> 13.0 >>> transition would be a good moment to finally remove the (also in >>> my opinion rather useless) server profiles. >>> >> >> The server profiles are not useless, if we can maintain them, and >> if they actually are, nowadays, they shouldn't be. >> >> -1, unless other profile options being offered are "minimal" enough >> for the job and enabling certain things that someone may need in a >> server. >> > > Just to summarize the last massive thread on this: > > 1 - they aren't maintained; they haven't changed for years I think you're confusing updates with maintenance. They work fine as is therefore no need for updates. > > 2 - the only difference between server profiles and the base profile > is USE="+snmp" and maybe one other flag USE="-perl -python snmp truetype xml" > > 3 - there isn't any general consensus on what makes a server, as such > there isn't any consensus on how to make server profiles more useful. Just make the base profile as minimal as possible and people will be happy. > > ... i think that's about it? > > PS: +1 from me. > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.19 (GNU/Linux) > > iF4EAREIAAYFAlD2tjQACgkQ2ugaI38ACPDGbwEAr4WGmtio2d+uWTkroEGCbu4U > 53GdR5R3A4Fti8UXzj8A/iM805vMnkojNTNGw8b5XYVXPbYrZ9TJ4GPp0onE8AK8 > =6Lja > -END PGP SIGNATURE- > -- Doug Goldstein
Re: [gentoo-dev] app-emulation/qemu-user mask
On Mon, Jan 14, 2013 at 11:01 AM, Doug Goldstein wrote: > On Mon, Jan 14, 2013 at 1:47 AM, Alexey Shvetsov wrote: >> В письме от 14 января 2013 00:38:06 пользователь Doug Goldstein написал: >>> On Sun, Jan 13, 2013 at 1:45 PM, Alexey Shvetsov wrote: >>> > Hi! >>> > >>> > For cross-chroots its needed to have static qemu-$arch user translators. >>> > May be you can introduce user-static use flag for them? Also it will be >>> > cool to have init script for kvm >>> >>> USE=static is available for app-emulation/qemu. I'll get a chroot for >>> arm setup soon and test everything to make sure its working well. >> >> It doesnt allow to build dynamik qemu-system* and static user targets > > That can be fixed. File a bug. > To follow this up. I've successfully installed and am using an arm chroot on my amd64 box using app-emulation/qemu-1.2.2 not using USE=static. But it required a little bit of effort (using ldd or readelf to bring in the necessary libraries) so I'll introduce USE=static-user and USE=static-softmmu, both of which will be enabled by USE=static. -- Doug Goldstein
Re: [gentoo-dev] app-emulation/qemu-user mask
On Mon, Jan 14, 2013 at 1:47 AM, Alexey Shvetsov wrote: > В письме от 14 января 2013 00:38:06 пользователь Doug Goldstein написал: >> On Sun, Jan 13, 2013 at 1:45 PM, Alexey Shvetsov wrote: >> > Hi! >> > >> > For cross-chroots its needed to have static qemu-$arch user translators. >> > May be you can introduce user-static use flag for them? Also it will be >> > cool to have init script for kvm >> >> USE=static is available for app-emulation/qemu. I'll get a chroot for >> arm setup soon and test everything to make sure its working well. > > It doesnt allow to build dynamik qemu-system* and static user targets That can be fixed. File a bug. > >> >> With regards to the KVM init script, I'm uninterested in maintaining >> it and it doesn't belong in the package as it is. There's a number of >> submitted init scripts that are attempting to create "init scripts" >> but really they're re-inventing libvirt and ganeti, but instead >> poorly. Ones I know about are: >> >> https://bugs.gentoo.org/show_bug.cgi?id=321517 >> https://bugs.gentoo.org/show_bug.cgi?id=406043 > > Ghm.. Its some kind of overkill to install libvirt or gannety just for 1-2 vms > -- Doug Goldstein
Re: [gentoo-dev] app-emulation/qemu-user mask
On Sun, Jan 13, 2013 at 1:45 PM, Alexey Shvetsov wrote: > Hi! > > For cross-chroots its needed to have static qemu-$arch user translators. May > be you can introduce user-static use flag for them? Also it will be cool to > have init script for kvm > USE=static is available for app-emulation/qemu. I'll get a chroot for arm setup soon and test everything to make sure its working well. With regards to the KVM init script, I'm uninterested in maintaining it and it doesn't belong in the package as it is. There's a number of submitted init scripts that are attempting to create "init scripts" but really they're re-inventing libvirt and ganeti, but instead poorly. Ones I know about are: https://bugs.gentoo.org/show_bug.cgi?id=321517 https://bugs.gentoo.org/show_bug.cgi?id=406043 -- Doug Goldstein
[gentoo-dev] Handy pybugz wrappers
Anyone have handy pybugz wrappers for bumping ebuilds and fixing bugs? I'm so used to the environment at work where a post-commit hook parses specifically formatted commit messages to take several actions on commits. I figure before I hack on any I'd ask if someone has some that could be shared with the community. Really just looking to combine steps like echangelog and repoman commit with pybugz. -- Doug Goldstein
[gentoo-dev] app-emulation/qemu-user mask
Just wanted to give everyone a heads up. app-emulation/qemu provides all the functionality of app-emulation/qemu-user without all the outstanding security bugs and issues the package has. For users using a cross chroot, I encourage you to look at QEMU_USER_TARGETS. I presently use an arm chroot with app-emulation/qemu. Should there truly be a missing feature, open a bug and I'll fix it. The only item I'm aware of that app-emulation/qemu does not have is the binfmt initscript. But I plan on adding that to the unstable version shortly. If there are no objections for 30 days, I'll send a treecleaner notice in 30 days and remove it 30 days after that (60 days from now). -- Doug Goldstein
Re: [gentoo-dev] DNSSEC (w/ DLV) live on *.dev.gentoo.org
On Sun, Jan 6, 2013 at 7:31 PM, Robin H. Johnson wrote: > Just a heads up, > > DNSSEC is now live on *.dev.gentoo.org hosts. So for those that had to look up some or all of what Robin mentioned, I'll summarize below. > > There is a DLV anchor registered at dlv.isc.org, so all public DNSSEC > lookups within the domain should work fine. DLV allows you to break out of the traditional each parent needs to be signed and has an aside database that can confirm a specific node. Very useful when the TLD didn't support signing or if a DNS provider you use doesn't support DNSSEC. Stands for DNSSEC Lookaside Validation. > > Here's visualisation on my two test cases: > http://dnsviz.net/d/dev.gentoo.org/dnssec/ > http://dnsviz.net/d/mv78100.arm.dev.gentoo.org/dnssec/ > > If there are no problems reported in a week or two, I'm going to enable > this for the rest of our DNS zones, as well as registering the DS > records with the TLD. Basically getting rid of the need for the DLV and having the whole chain signed from the root down to each domain. > Thereafter, I'd also like to deploy DANE and SSH > fingerprints in DNS, and remove our reliance any elements of the CA > chain. SSH supports a specific record called SSHFP which stores the hosts key for validation. To against it when it enabled you should be able to do something like: $ ssh dev.gentoo.org -o VerifyHostKeyDNS=yes DANE is DNS-based Authentication of Named Entities. Looks like its a working group to add more public keys into DNS and get applications or protocols to support it. > > I haven't implemented NSEC3 by way of a conscious choice. I don't see > the need for any private information in our DNS records - simply > obscuring them isn't really security. NSEC3 is related to exposing the entities in your whole DNS record. With DNSSEC you end up getting the whole zone to verify that its signed. This has the side effect if you had www.mycompany.com but you also had secret.mycompany.com, with DNSSEC your hostname secret would be reveled as existing. NSEC3 attempts to mitigate this. For more info on everything see: http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions > > -- > Robin Hugh Johnson > Gentoo Linux: Developer, Trustee & Infrastructure Lead > E-Mail : robb...@gentoo.org > GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 > Excellent job getting us DNSSEC support btw! -- Doug Goldstein
Re: [gentoo-dev] glibc-2.17: nscd is optional
On Mon, Dec 31, 2012 at 11:13 PM, Maxim Kammerer wrote: > On Tue, Jan 1, 2013 at 2:10 AM, Alec Warner wrote: >> flatfile lookups are 2-4ms with hot cache. How much faster is the db >> option? > > I guess it depends on the implementation and how close is the system's > operational situation to an ideal one (whether swap started thrashing, > etc.). A DB is the proper solution that can be improved if necessary > (e.g., keeping often-used parts in RAM). Filesystem where it resides > can be offered hardware with lower seek time or better cache. But I > agree that it is easy to rationalize bad solutions. I don't like > waiting on an "ls -l" in addition to the system not being responsive > due to some other reason, though. But maybe I am expecting too much, > with even PolKit delegating each query to a full-blown Javascript > library nowadays. > You realize that files are cached in RAM right? There's a page cache and pages are ejected when the system needs that RAM for something else and they're ejected in an LRU fashion. More than likely those pages are always in cache. I say pages very liberally here because most of the files we're dealing with are less than 4096 bytes (yep, I'm making that assumption) so its really 1 page per file. The result is that the request for the data (assuming mmap here) is handled by just doing a bounds/range check and converting the virtual address to the physical address the data is wired in. The time required to parse the average GNOME single user desktop machine (I've got 44 users and 69 groups on that box) is likely smaller than the overhead of a DB. -- Doug Goldstein
Re: [gentoo-dev] Time based retirements
On Fri, Dec 21, 2012 at 7:05 PM, Markos Chandras wrote: > > Finally, I am very proud with the work we are doing, especially Pacho > who has been doing most of the work lately. We have managed to "free" > many many packages and this was one of the reasons I formed the > proxy-maintainers project, so that non-dev contributors could step up > and take care of all these packages that inactive devs left > unattended. > I see "free" as "dump a lot of orthogonally related packages on to the herd that is listed but really the other herd members aren't interested in those packages. So over time we go from a herd that had decent number of semi-active developers that handled a large swath of the packages to only a handful of active devs who are only interested in a select few packages with no support for all those other packages. Because the result was you could prod the semi-active guys about the packages they maintained and they would fix something or they'd give you feedback on something you might do to test it. Once they're retired, the magical list of person X has knowledge of Y goes away (metadata.xml). If you're curious if I'm speaking about a specific herd, I am. It's media-tv. IMHO, if you're really after finding others to take care of packages that appear abandoned then you should contact the inactive people to see if there's any packages they'd be ok with giving up to the proxy-maintainers project or to another developer, but don't retire them. The reason I say ask them about packages is that they might appear to be inactive because they really are only maintaining one or two packages that infrequently get any activity, but when they package gets activity they jump on it and fix it right away. I know that was the case for me when I was busy with RL things for a while. But there were a number of packages my employer paid me to maintain and I did. All the other packages that had my name on them I just didn't have the time. If the goal here really is to ensure well maintained packages then retiring people is akin to treating a screw like a nail and banging it in with a hammer, wrong tool... wrong job. For some packages you may find another developer right away with interest to fix it, or a proxy maintainer but in some cases you might have just kicked the only person who had any inclination to fix the package. Some packages have 50 users and 49 of them are Gentoo developers or would step up and become Gentoo developers to fix the package should it become unmaintained and that's great. But some packages have 200 users and 1 person willing to be the developer to maintain it. You retire that person and you might have well just told those 200 people to pick a different distro because inevitably their package will be treecleaned. If you need a concrete example of a package, that would be MythTV. I've been hoping for the day that someone becomes a Gentoo developer with the goal of maintaining MythTV for nearly a decade but it hasn't happened. If I stop touching it, it languishes and I get e-mails and bugs, etc. I tell everyone they are more than welcome to maintain it and 99% of the time nothing comes of it, and 1% of the time someone does 1 bump for me and nothing more again. Regarding my use of the words "brain dead", notice I never said "Markos is brain dead". What I said was the policy of retiring people when what you really want is an active maintainer of packages is brain dead. Now I understand that you're involved with the enforcement of that policy and therefore identify with it, but I would have to encourage you to separate yourself from a policy. I unfortunately feel after reading all the comments in this whole thread that my original statement is still true. Well that felt like a Duncan e-mail so its time to wrap it up. -- Doug Goldstein
[gentoo-dev] Time based retirements
I'm curious who had the brain dead idea to retire Gentoo developers that are still interested in the distro, that maintain low activity packages for herds that are stretched way too thin, and are still contributing to the distro in many ways other than direct CVS commits (e.g. overlays, user support, providing hardware to other devs, etc). I could MAYBE understand it if they're consuming some valuable resource that we need to free up by retiring them. But instead they get a nasty-gram about their impending retirement and decide if that's how they are to be treated that they can be retired. When they finally want to contribute again they have the lovely uphill of our dreadfully painful recruitment process. I'm really just trying to understand the sense in this. -- Doug Goldstein
[gentoo-dev] Lastrites: app-emulation/qemulator
# Doug Goldstein (07 Dec 2012) # Masked for removal in 30 days. (07 Jan 2012) # Upstream says the project is dead and is being replaced app-emulation/qemulator -- Doug Goldstein
[gentoo-dev] [PATCH] gnome2.eclass does not respect ECONF_SOURCE
The gnome2.eclass checks the configure script for certain items and
adjusts the arguments to econf based on those checks. Unfortunately
when checking the configure script it did not respect ECONF_SOURCE.
---
gnome2.eclass | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/gnome2.eclass b/gnome2.eclass
index 3f7b2da..1f3e005 100644
--- a/gnome2.eclass
+++ b/gnome2.eclass
@@ -129,7 +129,7 @@ gnome2_src_configure() {
# Remember to drop 'doc' USE flag from your package if it was only used
to
# rebuild docs.
# Preserve old behavior for older EAPI.
- if grep -q "enable-gtk-doc" configure ; then
+ if grep -q "enable-gtk-doc" ${ECONF_SOURCE:-.}/configure ; then
if has ${EAPI-0} 0 1 2 3 4 && has doc ${IUSE} ; then
G2CONF="${G2CONF} $(use_enable doc gtk-doc)"
else
@@ -138,24 +138,25 @@ gnome2_src_configure() {
fi
# Pass --disable-maintainer-mode when needed
- if grep -q "^[[:space:]]*AM_MAINTAINER_MODE(\[enable\])" configure.*;
then
+ if grep -q "^[[:space:]]*AM_MAINTAINER_MODE(\[enable\])" \
+ ${ECONF_SOURCE:-.}/configure.*; then
G2CONF="${G2CONF} --disable-maintainer-mode"
fi
# Pass --disable-scrollkeeper when possible
- if grep -q "disable-scrollkeeper" configure; then
+ if grep -q "disable-scrollkeeper" ${ECONF_SOURCE:-.}/configure; then
G2CONF="${G2CONF} --disable-scrollkeeper"
fi
# Pass --disable-silent-rules when possible (not needed for eapi5), bug
#429308
if has ${EAPI:-0} 0 1 2 3 4; then
- if grep -q "disable-silent-rules" configure; then
+ if grep -q "disable-silent-rules" ${ECONF_SOURCE:-.}/configure;
then
G2CONF="${G2CONF} --disable-silent-rules"
fi
fi
# Pass --disable-schemas-install when possible
- if grep -q "disable-schemas-install" configure; then
+ if grep -q "disable-schemas-install" ${ECONF_SOURCE:-.}/configure; then
G2CONF="${G2CONF} --disable-schemas-install"
fi
--
1.8.0
[gentoo-dev] Lastrite: app-emulation/kqemu
# Doug Goldstein (21 Nov 2012) # Masked for removal. Lots of bugs opened. Upstream # says don't use it. No Gentoo maintainer # activity for some time. qemu no longer supports it. # Removal date: 21 Dec 2012 app-emulation/kqemu -- Doug Goldstein
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:59 PM, Diego Elio Pettenò wrote: > On 17/11/2012 21:52, Joshua Kinard wrote: >> It's human nature to wake up one day and exclaim, "I will develop X!", and >> then go off and do so without any formal planning or even a rough idea of >> how to start. Sometimes it works, and sometimes it doesn't. Sometimes, you >> just roll dice. That's what keeps life interesting. > > Agreed. Heck I've worked for how long on Gentoo/FreeBSD? And did I have > a plan for most of that? Not really. > > But I didn't go around saying that I was "not following the waterfall" > or "developing AGILE". I was just doing shit that sounded cool and > looked nice. Did I expect much out of it? Not really. > > At the end we did get something, in particular we got OpenRC out of it, > which has served us very well for quite a while, and we never planned > for it before that. But it was just luck, and I wouldn't brag about it. Diego I'm going to have to call you out here. You've so far in this thread claimed you were the reason behind the "eudev" project and now claim you're behind OpenRC. Sounds like bragging to me. > > That's why I'm not saying "please shut down the project", just "please > keep ryao away from the keyboard". > > -- > Diego Elio Pettenò — Flameeyes > flamee...@flameeyes.eu — http://blog.flameeyes.eu/ > -- Doug Goldstein
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
y? What, specifically, is wrong with the existing systemd solution > that you have a problem with? Specifics please, otherwise they can't be > fixed. > >> We have decided to try doing things ourselves to see if we can do >> better. We think we can. > > That's wonderful, seriously. But why is this suddenly an official > Gentoo project? When did that happen, and why? Why not just do a > "normal" project and if it matures and is good enough, then add it to > the distro like all other packages are added. > > My main point here is the fact that this is now being seen as an act by > Gentoo, the distro / foundation. And that happened in private, without > any anouncement. Which is not good on many levels. > >> > Have you studied the problem area for booting, process monitoring, >> > system isolation, device creation and notification, persistant naming, >> > multiple users with multiple displays, and the like, and found that >> > Linux is lacking in this area? If so, I would love to learn more, as I >> > want Linux, and Gentoo, to succeed. Without knowing the problems you >> > are having, there's no way anyone will ever change. >> >> We already have OpenRC, which has been found to work well on both Gentoo >> Linux and Gentoo FreeBSD. The integration of udev into systemd has >> caused problems for existing OpenRC systems with people being told that >> it is okay to break configurations that users had been told to use over >> well over a decade. Many of us consider that to be unacceptable. > > Part of the goal of systemd is to unify all Linux distros startup logic, > and configuration logic, to make things unified to help a whole lot of > things happen better and faster in the end. It is a move to save > effort, and, is succeeding quite well. If Gentoo does not wish to > participate in this effort, then those of us who are participating in > it, and are Gentoo developers, should be told this so that we can decide > what we wish to do. > > OpenRC is great, and has worked well for 10+ years. But seriously, it > is creaky in places, and doesn't do much at all compared to what systemd > offers. If Gentoo wants to ignore systemd, it does so at its own peril. > > Oh, and systemd has nothing to do with the /usr issue, don't ever get > that confused. A separate /usr broke a long time ago, systemd just now > shows you how broken your system really was, and you didn't notice it :) > >> Anyway, results are what are important. If you are interested in what we >> are doing, then I suggest coming back in a month to see what we have >> produced. > > Why a month? Where did that deadline come from? > > And again, the main question that has never been answered yet, "What are > you trying to do here?" > > thanks, > > greg k-h > Greg, While I agree you have some valid points here, I do think you're being a bit discouraging towards this. Honestly if they want to go off and work on this project because it gets them excited about open source then that's a good thing and they should be allowed to do that (the whole Gentoo Foundation thing and copyright business aside) as a stand alone project. What stake do you have in this to really hurl a bunch of questions at them about their problems with existing solutions and goals? I'd honestly just drop it and let them do what developers are suppose to do and produce some code. Maybe the project goes no where, maybe it comes up with some interesting ideas that can be merged in with other projects, or maybe it becomes something that stands on its own. My feeling is if people want to code, let them code. Let them do what they want to do and enjoy themselves, even if you think their idea sucks. -- Doug Goldstein
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: nvidia-driver.eclass
On Sun, Nov 18, 2012 at 12:18 AM, Samuli Suominen wrote: > On 18/11/12 07:47, Doug Goldstein (cardoe) wrote: >> >> cardoe 12/11/18 05:47:02 >> >>Modified: nvidia-driver.eclass >>Log: >>Update to support a new legacy series >> >> Revision ChangesPath >> 1.16 eclass/nvidia-driver.eclass >> >> file : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/nvidia-driver.eclass?rev=1.16&view=markup >> plain: >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/nvidia-driver.eclass?rev=1.16&content-type=text/plain >> diff : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/nvidia-driver.eclass?r1=1.15&r2=1.16 >> >> Index: nvidia-driver.eclass >> === >> RCS file: /var/cvsroot/gentoo-x86/eclass/nvidia-driver.eclass,v >> retrieving revision 1.15 >> retrieving revision 1.16 >> diff -u -r1.15 -r1.16 >> --- nvidia-driver.eclass22 Aug 2011 04:46:32 - 1.15 >> +++ nvidia-driver.eclass18 Nov 2012 05:47:02 - 1.16 >> @@ -1,6 +1,6 @@ >> # Copyright 1999-2011 Gentoo Foundation >> # Distributed under the terms of the GNU General Public License v2 >> -# $Header: /var/cvsroot/gentoo-x86/eclass/nvidia-driver.eclass,v 1.15 >> 2011/08/22 04:46:32 vapier Exp $ >> +# $Header: /var/cvsroot/gentoo-x86/eclass/nvidia-driver.eclass,v 1.16 >> 2012/11/18 05:47:02 cardoe Exp $ >> >> # @ECLASS: nvidia-driver.eclass >> # @MAINTAINER: >> @@ -30,9 +30,21 @@ >> 031b 031c 0320 0321 0322 0323 0324 0325 0326 0327 0328 032a 032b 032c >> 032d \ >> 0330 0331 0332 0333 0334 0338 033f 0341 0342 0343 0344 0347 0348 034c >> 034e" >> >> +drv_304x="0040 0041 0042 0043 0044 0045 0046 0047 0048 004e 0090 0091 >> 0092 \ >> +0093 0095 0098 0099 009d 00c0 00c1 00c2 00c3 00c8 00c9 00cc 00cd 00ce >> 00f1 \ >> +00f2 00f3 00f4 00f5 00f6 00f8 00f9 0140 0141 0142 0143 0144 0145 0146 >> 0147 \ >> +0148 0149 014a 014c 014d 014e 014f 0160 0161 0162 0163 0164 0165 0166 >> 0167 \ >> +0168 0169 016a 01d0 01d1 01d2 01d3 01d6 01d7 01d8 01da 01db 01dc 01dd >> 01de \ >> +01de 01df 0211 0212 0215 0218 0221 0222 0240 0241 0242 0244 0245 0247 >> 0290 \ >> +0291 0292 0293 0294 0295 0297 0298 0299 029a 029b 029c 029d 029e 029f >> 02e0 \ >> +02e1 02e2 02e3 02e4 038b 0390 0391 0392 0393 0394 0395 0397 0398 0399 >> 039c \ >> +039e 03d0 03d1 03d2 03d5 03d6 0531 0533 053a 053b 053e 07e0 07e1 07e2 >> 07e3 \ >> +07e5" >> + >> mask_96xx=">=x11-drivers/nvidia-drivers-97.0.0" >> mask_71xx=">=x11-drivers/nvidia-drivers-72.0.0" >> mask_173x=">=x11-drivers/nvidia-drivers-177.0.0" >> +mask_173x=">=x11-drivers/nvidia-drivers-305.0.0" > > > I don't know the eclass, but shouldn't this say mask_304x here ? > >> >> # @FUNCTION: nvidia-driver-get-card >> # @DESCRIPTION: >> @@ -71,6 +83,13 @@ >> return 0; >> fi >> done >> + >> + for drv in $drv_304x; do >> + if [ "x$card" = "x$drv" ]; then >> + echo "$mask_304x"; >> + return 0; >> + fi >> + done >> done >> >> echo ""; >> >> >> >> > Thank you for finding the flaw in my mail filter rule to delete these e-mails when they hit gentoo-dev, where I'm directly addressed. In the future if you want these e-mails to go through you'll have to e-mail me directly without CCing the list or sending it to the list. Just doing my part to help clean up pointless e-mails to -dev one mail filter at a time. That said, you are actually correct. -- Doug Goldstein
Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On Tue, Oct 30, 2012 at 2:17 PM, Fabian Groffen wrote: > On 30-10-2012 19:08:39 +, Samuli Suominen wrote: >> Added: udev.eclass >> Log: >> New eclass to determine udevdir from udev.pc pkg-config file as requested >> by many people, without ML review due to unproductive feedback > > Uhm... > Please, stop doing this! > > > -- Stop the bike shedding. Provide real constructive improvements. I'm not copying and pasting the same hunk of code in a bunch of ebuilds. -- Doug Goldstein
Re: [gentoo-dev] About DESCRIPTION in ebuilds needing to end with a dot "."
On Fri, Oct 19, 2012 at 2:01 PM, Pacho Ramos wrote: > Hello > > At least in spanish, it's mandatory to end phrases with a dot ".", would > you agree with trying to enforce this trivial change with a repoman > warning? > > Thanks for your opinions > I don't really see the advantage or upside. English requires sentences end in a dot as well. -- Doug Goldstein
[gentoo-dev] app-emulation/qemu & app-emulation/qemu-kvm folding into one package
Hey all, Just an announcement that app-emulation/qemu-kvm will be pkgmove'd to app-emulation/qemu at some point this week. The app-emulation/qemu ebuilds will effectively die and be replaced by the app-emulation/qemu-kvm ebuilds. I've brought this up before and there was a bunch of rabble about "keep our pristine qemu ebuilds!!!". The fact of the matter is that the app-emulation/qemu just isn't getting the same maintenance care that app-emulation/qemu-kvm is. I've really only got the bandwidth to handle one at a time. Additionally this will bring us inline with a few other distros use of qemu as they're really building their binaries from qemu-kvm. For those that want pure qemu builds, I recommend creating an overlay and replacing the URL. The ebuilds will otherwise aim to be 100% compatible. -- Doug Goldstein
Re: [gentoo-dev] News item 1: changes to stages (make.conf and make.profile)
On Sun, Sep 9, 2012 at 3:13 PM, Jorge Manuel B. S. Vicetto wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This news item was committed. > So the news item was a bit ambiguous on if I wanted to make the change myself to the new locations when I could actually make the change. Current portage supports it? Or is their a new version coming which I would need? -- Doug Goldstein
Re: [gentoo-dev] remove system set?
On Thu, Aug 16, 2012 at 7:05 AM, Rich Freeman wrote: > On Wed, Aug 15, 2012 at 10:04 AM, Fabian Groffen wrote: >> >> From that angle, if you wouldd remove the system set, would you add its >> contents to the Portage ebuild? Portage itself doesn't need a compiler >> or might not need gawk, but whatever it runs (ebuilds) often need so. > > Nope - I'd add them to every ebuild, and only where needed. That's > the whole point. > >> >> Adding libc, a compiler, linker, shell, etc. to almost any every ebuild >> looks pretty much useless to me. Adding deps for all regular tools an >> ebuild uses (bash, sed, awk, cut, wc, ...) seems like error-prone and >> pretty much useless to me as well. So, there is the system set which >> just is the central place where those packages are recorded. > > It is only useful for situations where people want to do something > unusual. Some would argue that this is the only situation where > Gentoo is useful. If I wanted a system just like everybody else's I > guess I'd run Ubuntu, if not Windows or OSX. > > In any case, I do agree that getting there is associated with pain. I > just like to think that getting there "someday" would be nice. I know > that a systematic effort exists in mathematics to try to reduce all of > math to a minimum set of axioms and have everything else be formally > derived. I consider that a thing of beauty, even if I don't care to > read the two volumes necessary to get to 1+1=2. > > Rich > The other point of the system set is to get rid of the chicken and egg problem. For example, virtually every package in the system set ships as a tar, including tar itself. All the compression utilities ship as tars, which need to be installed to build tar (think -z, -j, -J). You need a standard C library to run virtually everything including tar, which you need to extract your standard C sources. The list goes on. -- Doug Goldstein
Re: [gentoo-dev] Kernel calls gcc directly: fine?
On Sun, Aug 12, 2012 at 9:19 AM, Agostino Sarubbo wrote: > If you try to launch make V=1 from the kernel source directory you will see: > > gcc -Wp,-MD,scripts/mod/.empty.o.d -nostdinc -isystem /usr/lib/gcc/x86_64- > pc-linux-gnu/4.5.3/include -I/usr/src/linux-3.3.8-gentoo/arch/x86/include - > Iarch/x86/include/generated -Iinclude -include /usr/src/linux-3.3.8- > gentoo/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes > -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function- > declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 - > march=core2 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate- > outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 - > DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -pipe -Wno-sign-compare -fno- > asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe- > larger-than=2048 -fno-stack-protector -fomit-frame-pointer -Wdeclaration- > after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack - > DCC_HAVE_ASM_GOTO-D"KBUILD_STR(s)=#s" - > D"KBUILD_BASENAME=KBUILD_STR(empty)" -D"KBUILD_MODNAME=KBUILD_STR(empty)" -c > -o scripts/mod/empty.o scripts/mod/empty.c > > > So it calls gcc directly. > > I see we don't like gcc called directly from the tracker[1], but this is for > packages/ebuild. Should this bug block that tracker or it is invalid? > > > [1]: https://bugs.gentoo.org/show_bug.cgi?id=cc-directly > Its invalid. Kbuild has its own documented way to do cross compiles and replace out the compiler (granted only gcc works for building the official Linux tree, there has been efforts to use clang and icc but those are not mainlined). -- Doug Goldstein
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/udev: udev-187-r1.ebuild udev-9999.ebuild ChangeLog
On Sat, Aug 4, 2012 at 2:31 AM, Samuli Suominen wrote:
> If you don't use double [[ then ${ROOT} will need "" quoting
>
Don't do top post code reviews. Snip out the context and do code
reviews inline so that your feedback is meaningful. Top posting and
leaving the entire commit with CVS metadata and all is just wasteful
and silly.
--
Doug Goldstein
Re: [gentoo-dev] force verbose build log as per PMS policy?
On Fri, Aug 3, 2012 at 6:18 PM, hasufell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/01/2012 06:07 PM, Michał Górny wrote: >> On Wed, 01 Aug 2012 13:13:43 +0200 hasufell >> wrote: >> >>> We already had a discussion about cmake-utils.eclass and forcing >>> verbose build log for that which was approved: >>> http://archives.gentoo.org/gentoo-dev/msg_ce7d33748936663e84a5463fbf7f4d39.xml >>> >>> >>> > Also we have bug https://bugs.gentoo.org/show_bug.cgi?id=384193 and >>> https://bugs.gentoo.org/show_bug.cgi?id=379497 >>> >>> I opened a tracker >>> https://bugs.gentoo.org/show_bug.cgi?id=429308 >>> >>> Some devs seem unsure about that or want to have a council vote >>> on that https://bugs.gentoo.org/show_bug.cgi?id=429332 >> >> PMS doesn't have such a thing as a 'policy'. Gentoo can have one, >> and I believe that should be discussed per Gentoo policy. >> > > So that would simply mean we add that information to the devmanual? > > Should I open a bug with a devmanual patch then? FFS, do not spam base-system yet again with stuff that's in the process of being discussed still. Additionally, this is something that should be fixed on the EAPI/eclass level and NOT per package. Putting EXTRA_ECONF="--disable-silent-rules" in EVERY package is epically moronic. Make econf automatically use --disable-silent-rules. -- Doug Goldstein
Re: [gentoo-dev] Problem with texlive-basic-2012 in portage
On Mon, Jul 30, 2012 at 9:00 PM, easior wrote: > Hi, all! > > I am a TeX user with TeX Live installed by Gentoo portage. Recently, I found > that the TeX Live version have been updated to 2012 and I want to refresh my > Gentoo system. Unfortunately, the package, texlive-basic-2012, couldn't be > properly compiled. Viewed from the build.log, it maybe caused by the package > zlib. The version of zlib did not match to texlive-basic since texlive-basic > needs the zlib library with version 1.2.5.1, but the zlib in my gentoo is > updated to version 1.2.7. On the other hand, the ebuild of zlib-1.2.5 have > been removed by the Gentoo protage and the downgrading of zlib is not a good > solution for zlib-1.2.7 is pulled by many packages. > $ revdep-rebuild $ emerge -1 lua Should do the trick. -- Doug Goldstein
Re: [gentoo-dev] news item: changes to stages (make.conf and make.profile)
On Mon, Jul 23, 2012 at 7:07 PM, Jorge Manuel B. S. Vicetto wrote: > Starting with catalyst 2.0.10, make.conf and make.profile will be > moved from /etc to /etc/postfix. Releng build boxes will be updated to s/postfix/portage/ -- Doug Goldstein
[gentoo-dev] ROMs category suggestion
I've got a few ROMs to add to the tree and some which are already in the tree if people have a suggestion where they should live. Short list: ipxe openbios seabios sgabios vgabios -- Doug Goldstein
Re: [gentoo-dev] multiple package moves into one
On Mon, Jul 16, 2012 at 8:49 AM, Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 15/07/12 06:16 PM, Zac Medico wrote: >> On 07/15/2012 03:08 PM, Doug Goldstein wrote: >>> Is it valid to do something like: >>> >>> move media-plugins/mytharchive media-plugins/mythplugins move >>> media-plugins/mythbrowser media-plugins/mythplugins move >>> media-plugins/mythgallery media-plugins/mythplugins move >>> media-plugins/mythgame media-plugins/mythplugins move >>> media-plugins/mythmovies media-plugins/mythplugins move >>> media-plugins/mythnews media-plugins/mythplugins move >>> media-plugins/mythweather media-plugins/mythplugins >> >> No, that's not really how it's intended to be used. You'll probably >> have to put blockers in media-plugins/mythplugins to block all the >> old packages that install the same files. > > Theoretically (i've done a quick test on this and it seems true) a > single-"!" blocker is enough that one package will on upgrade replace > all these others without user intervention being required (assuming > these packages aren't in @world, of course), and it won't cause file > collisions. > > Unrelatedly curious, why the package merge? Trying to make MythTV maintenance easier on myself since I couldn't find a maintainer. Upstream changed to SVN a long while back and with that changed moved all the plugins into one bundle called mythplugins. They've now switched to git and with that change I decided to modernize a little bit. mythtv.git a few top level directories, each of which is packaged as its own tarball which makes backporting patches extra fun. The mythplugins tarball (mythtv.git/mythplugins) contains additional plugins that are found in different git repos. They're still unique snowflakes with their git usage. -- Doug Goldstein
Re: [gentoo-dev] multiple package moves into one
On Sun, Jul 15, 2012 at 5:14 PM, Ciaran McCreesh wrote: > On Sun, 15 Jul 2012 17:08:45 -0500 > Doug Goldstein wrote: >> Is it valid to do something like: >> >> move media-plugins/mytharchive media-plugins/mythplugins >> move media-plugins/mythbrowser media-plugins/mythplugins >> move media-plugins/mythgallery media-plugins/mythplugins >> move media-plugins/mythgame media-plugins/mythplugins >> move media-plugins/mythmovies media-plugins/mythplugins >> move media-plugins/mythnews media-plugins/mythplugins >> move media-plugins/mythweather media-plugins/mythplugins > > Nope. > Dang. Didn't think so but I figured I'd ask. Thanks for the quick reply. -- Doug Goldstein
[gentoo-dev] multiple package moves into one
Is it valid to do something like: move media-plugins/mytharchive media-plugins/mythplugins move media-plugins/mythbrowser media-plugins/mythplugins move media-plugins/mythgallery media-plugins/mythplugins move media-plugins/mythgame media-plugins/mythplugins move media-plugins/mythmovies media-plugins/mythplugins move media-plugins/mythnews media-plugins/mythplugins move media-plugins/mythweather media-plugins/mythplugins Thanks. -- Doug Goldstein
Re: [gentoo-dev] sys-auth/nss-ldapd is looking for a maintainer
On Sat, Jul 14, 2012 at 6:25 PM, Matthew Thode wrote: > On 07/14/2012 02:49 PM, Doug Goldstein wrote: >> sys-auth/nss-ldapd is looking for a maintainer. This is the >> "preferred" NSS LDAP by RHEL6. I just haven't been using it and >> haven't been keeping up with releases. I'm only aware of two bugs: >> >> https://bugs.gentoo.org/show_bug.cgi?id=287727 >> https://bugs.gentoo.org/show_bug.cgi?id=234555 >> >> One is asking for a bump and one is asking for some USE flag fixes. >> > I'll take it, starting with the bump and hopefully getting upstream to > accept a --enabled/disable for kerberos. > Thanks a bunch Matt. -- Doug Goldstein
[gentoo-dev] sys-auth/nss-ldapd is looking for a maintainer
sys-auth/nss-ldapd is looking for a maintainer. This is the "preferred" NSS LDAP by RHEL6. I just haven't been using it and haven't been keeping up with releases. I'm only aware of two bugs: https://bugs.gentoo.org/show_bug.cgi?id=287727 https://bugs.gentoo.org/show_bug.cgi?id=234555 One is asking for a bump and one is asking for some USE flag fixes. -- Doug Goldstein
Re: [gentoo-dev] grub:2 keywords
On Tue, Jul 3, 2012 at 9:20 AM, Jeroen Roovers wrote: > On Mon, 2 Jul 2012 15:02:28 -0400 > Mike Gilbert wrote: > >> That is exactly what Doug (cardoe) proposed, and he is working on the >> docs for that. >> > > Ah yes, it's been a long-winded thread. :) > > > jer > I got a little busier this past weekend than I had intended (loving that leap second bug) but here's the first draft: http://dev.gentoo.org/~cardoe/docs/grub2-migration.xml It will be integrated into the official Gentoo doc set once I get a nod from the docs guys. -- Doug Goldstein
Re: [gentoo-dev] grub:2 keywords
On Sun, Jun 24, 2012 at 11:15 PM, Mike Gilbert wrote: > An official release of grub-2.00 should be coming pretty soon. I would > like to keyword this for ~amd64 and ~x86 shortly after it hits the tree. > I don't do much work on base system packages, so I would like some > advice on how to make this as smooth as possible. > > My main concern is that many people probably have sys-boot/grub in > @world. If grub:2 is made visible, portage will install it, and will > remove grub-0.97 on the next depclean. This could be a little confusing, > but should not cause any immediate damage since the copy of grub-0.97 > installed in the MBR and /boot would remain intact. > > Is this worthy of a news item? Or I just blog about it? > > Anything else I need to think about here? > > Note: The Gentoo Documentation Project has indicated that they do not > want to add anything to the handbook until we are somewhat close to > stabilizing grub:2. That's at least a couple months away. > Mike, Since Grub Legacy and Grub 2 are slotted, Portage won't remove the older version. Even if it removes the older one, everything necessary is installed into /boot and the MBR already. The best route forward would be to instruct people to use grub2-install (but whatever the flag is to prevent MBR installation). Have people generate their grub.cfg with grub2-mkconfig and then put a chain loader into the Grub Legacy configs so that they can test Grub 2 and then once they test it tell them to install Grub 2 into the MBR and remove Grub Legacy. I'll gladly work with you on this. IMHO, it might be a good plan to unmask and ~arch one of the release candidates with an aim to get Grub 2.0.0 fully released with docs. -- Doug Goldstein
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sat, Jun 23, 2012 at 9:45 AM, Gilles Dartiguelongue wrote: > Le samedi 23 juin 2012 à 14:40 +0100, Ciaran McCreesh a écrit : >> >> I'd like to know why using USE flags until a nicer solution is >> available >> is sufficiently terrible that it warrants a hackaround. > > remember qt3/qt4, gtk/gtk2. We want to avoid repeating these "mistakes" > hence the guidelines already exposed back when we introduced gtk3 to the > tree. > > As you may have noticed, this is still the solution applied for things > hard to split or slot like gtk-vnc or avahi but we didn't see the need > to have such USE flags when the library was so easily slottable. > It's funny you bring up qt3/qt4 and gtk/gtk2 since I'm only of the few developers that worked on resolving both of those as they came and went. Right now the resources we've got available to us from a Package Manager stand point. Being a Gentoo dev for so long has allowed me to see how our distro has evolved so let me give you a short walk down memory lane, when gtk/gtk2 & qt3/qt4 occurred we had the following: - Portage 1.x (gtk/gtk2) / Portage 2.0.x (qt3/qt4) - No EAPI - No way to add features quickly to the Package Manager and the spec for it. During gtk/gtk2, the rule was you had to wait until a feature was available in the STABLE version of Portage, 4 releases back before you could use a new feature. For everyone's knowledge, we did 4 releases a year then. We knew our solution to gtk/gtk2 sucked and we hated it but there was absolutely nothing we could do about it. It was a bitter battle of band aids and hacks that we couldn't wait to get rid of. We even attempted to throw gtk1 out of the tree entirely (ah the XMMS flamewar) to get rid of the hacks. You couldn't even modify eclasses since they weren't stored with the install, which lead to the -rX revisioning of eclasses. On top of all this, Portage 1.x SUCKED to modify or hack at. The only solution with that codebase was to nuke it from orbit, which we finally did with Portage 2.0.x. During qt3/qt4, the rule was you had to wait until the feature you were trying to use was in a STABLE Portage for 6 months. We didn't have a lot of options available but we worked with the current Portage maintainer at the time to get some of the resolver improved and fixed and get those updates pushed out to the tree as quickly as possible. Once the updates were available the hacks went away and life was better. Now fast forward to 2011/2012, we were obviously aware that the gtk2/gtk3 change would cause some problems. Heck people encountered it when they tried to add ebuilds to the tree. The right path forward was to speak to Zac, Brian and the rest of the PMS guys and see what the best solution was. If it was implementing some new features then we could have done that and gotten and EAPI approved quickly and had it available before we even saw the first gtk3 ebuild unmasked. But alas, that wasn't the case and here we are today. So here's what I suggest, let's stop bickering and revisit the "hacks" you did to make things work. Speak to Zac, Brian and the rest of the PMS guys and get what you need implemented as a feature and get that feature into the very next EAPI bump. Fix the tree to use that EAPI and get rid of the hacks. You'll thank yourselves in the long run since things will be easier to maintain and you can focus on what you enjoy doing. -- Doug Goldstein
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sat, Jun 23, 2012 at 1:26 PM, Michał Górny wrote: > On Sat, 23 Jun 2012 14:40:50 +0100 > Ciaran McCreesh wrote: > >> On Sat, 23 Jun 2012 15:33:47 +0200 >> Gilles Dartiguelongue wrote: >> > Well the problem is simple, we need to ship webkit with gtk2 and >> > gtk3 support. This is needed because gentoo has gtk2 based >> > desktop/apps and because we want to ship gnome3 for example. >> > >> > Cool thing is that webkit supports being built with each toolkit >> > without conflicting with the build from the other toolkit hence we >> > ended up using SLOTS. >> >> You could just have gtk2 and gtk3 use flags in the ebuild, use >> REQUIRED_USE to ensure that at least one is enabled, and build things >> twice in the ebuild if necessary. > > Ah, so because a few paludis users may be building an additional > variant of webkit-gtk unnecessarily, we should force all Gentoo users > to randomly rebuild 1-2 variants depending on how soon they're going to > get the USE correctly. > Let's all agree that the current solution is less than ideal and could use improvement. I have several Gentoo & Portage only desktops and I find myself annoyed with webkit-gtk and its revisions and rebuilds. -- Doug Goldstein
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sat, Jun 23, 2012 at 1:31 PM, hasufell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/11/2012 07:08 PM, Ciaran McCreesh wrote: >> No, your goal is to provide a distribution. Gentoo has repeatedly >> shot itself in the foot, leg, groin etc by favouring short-term >> hacks over a well thought out, validated, self-enforcing design. >> Right now nearly all of the package manager work is on paying off >> previously incurred technical debt, and in the mean time you're >> busy adding to it. >> > > Please take your exherbo trolling somewhere else. > > Our goal is not to provide a distribution, because gentoo sees itself > as a metadistribution. > > Please familiarize yourself with: > http://www.gentoo.org/main/en/about.xml Let's keep the discussions on this mailing list technical and not personal. Thanks. -- Doug Goldstein
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, Jun 21, 2012 at 2:42 AM, Michał Górny wrote: > On Thu, 21 Jun 2012 08:30:24 +0100 > Ciaran McCreesh wrote: > >> On Thu, 21 Jun 2012 09:29:49 +0200 >> Michał Górny wrote: >> > On Wed, 20 Jun 2012 18:24:33 +0100 >> > Ciaran McCreesh wrote: >> > > On Wed, 20 Jun 2012 19:11:33 +0200 >> > > hasufell wrote: >> > > > On 06/20/2012 07:07 PM, Michał Górny wrote: >> > > > > Please read the rationale. Again. The whole thing. Three >> > > > > times. >> > > > >> > > > Please read my suggestions. Again. The whole thing. Three times. >> > > >> > > Can we all agree to just stop this and just restrict the arguing >> > > to being between SDEPEND and DEPENDENCIES? Cheers. >> > >> > You just volunteered to write portage patches. Cheers. >> >> Both were already implemented in Paludis, if you're looking for a >> reference implementation to try it out. There are also examples of >> use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I >> can give you a small patch to turn SDEPEND on for an EAPI if you like >> (it's just a one line addition to the EAPI definition file). > > Wait, did I just write to exherbo ml? No, don't think so. 'Implemented > in Paludis' doesn't work here. We're discussing Gentoo features, > and official package manager in Gentoo is portage. If you don't believe > me, check out the docs. > > -- > Best regards, > Michał Górny I would recommend the two of you step away from this thread and discussion for a day or two and come back to it with a fresh look at the suggestions and the code that's available and then we can move on getting this into an EAPI from there. -- Doug Goldstein
Re: [gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev
On Thu, Jun 21, 2012 at 9:12 PM, Sylvain Alain wrote: > Amen to that too, but can you post the actual comments that he said ? > > > > 2012/6/21 Homer Parker >> >> On Thu, 2012-06-21 at 23:01 +0200, Michał Górny wrote: >> > Just a short note as it seems some confusion arises lately: >> > >> > Ciaran McCreesh is not a Gentoo dev and his words don't represent >> > the position of Gentoo development team. >> > >> >> >> Amen. >> >> -- >> Homer Parker > > > > > -- > Salut > alp > Sylvain > Guys, Let's act like adults here. Just because someone disagrees with you doesn't mean they have something personally against you so there's no reason to take it to that level. This thread should end right now in the interest of civil discussion. -- Doug Goldstein
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Tue, Jun 19, 2012 at 10:27 PM, Samuli Suominen wrote: > On 06/20/2012 06:19 AM, Mike Frysinger wrote: >> >> On Tuesday 19 June 2012 22:46:26 Samuli Suominen wrote: >>> >>> On 06/15/2012 06:10 PM, Mike Frysinger wrote: >>>> >>>> On Friday 15 June 2012 03:44:14 Samuli Suominen wrote: >>>>> >>>>> On 06/13/2012 06:02 AM, Mike Frysinger wrote: >>>>>> >>>>>> i've noticed a growing trend where people put setup of variables into >>>>>> pkg_setup that only matter to src_* funcs presumably so they don't >>>>>> have >>>>>> to call the respective src_* func from an inherited eclass. >>>>>> unfortunately this adds pointless overhead to binpkgs. can we please >>>>>> move away from this practice ? >>>>> >>>>> >>>>> Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables, >>>>> DOCS for src_install, PATCHES for src_prepare >>>> >>>> >>>> these are static variables, so defining them in a func is pointless >>> >>> >>> "sort of" not necessarily, 'has $useflag && PATCHES+=( )' has been used >>> before, not sure if it's used in tree right now or not >> >> >> as we've always said, USE conditional patches are to be highly discouraged > > > I agree BUT there are cases where it's OK to use conditional patching: > > For example, libfoo-0.1.1 is broken and is fixed in git for master which > will be in next release. The fix doesn't apply to 0.1.1 cleanly without > heavy modifications. > Then you would take the easiest possible route to get 0.1.1 working again, > with the comfort of knowing it's properly fixed for the next version. > > -Samuli > I assume you mean libfoo-0.1.1 is broken when USE=bar is enabled and you get a patch for that conditional case when USE=bar is enabled. Either way, the better solution is to mask it and have people use libfoo-0.1.0 -- Doug Goldstein
Re: [gentoo-dev] epatch_user usage
On Mon, Apr 23, 2012 at 11:10 PM, Mike Frysinger wrote: > On Monday 23 April 2012 23:45:36 Doug Goldstein wrote: >> So I've just had one reservation when using epatch_user for allowing >> users to apply patches. And that's figuring out when to run >> eautoreconf. I don't necessarily want to run it unconditionally but >> sometimes users have patches which touch autoconf files but my >> existing patch set doesn't so I'm not calling eautoreconf. Does anyone >> have a suggested way to handle this? > > just always call it when the user applies patches. i don't see a big deal. > epatch_user && eautoreconf > -mike That works. I was wondering if you guys did anything more crafty but this is fine. Thanks all for the input. -- Doug Goldstein
[gentoo-dev] epatch_user usage
So I've just had one reservation when using epatch_user for allowing users to apply patches. And that's figuring out when to run eautoreconf. I don't necessarily want to run it unconditionally but sometimes users have patches which touch autoconf files but my existing patch set doesn't so I'm not calling eautoreconf. Does anyone have a suggested way to handle this? Thanks. -- Doug Goldstein
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
On Fri, Feb 24, 2012 at 6:31 PM, Richard Yao wrote: >> Am I the only paranoid person who moves them rather than unlinking >> them? Oh, if only btrfs were stable... > > Is this a reference to snapshots? You can use ZFS for those. The > kernel modules are only available in the form of ebuilds right > now, but they your data should be safe unless you go out of your way > to break things (e.g. putting the ZIL/SLOG on a tmpfs). Alternatively, > there is XFS, which I believe also supports snapshots. > FWIW, I'll second the ZFS > btrfs suggestion. I understand people want to go btrfs cause its the Linux way but in real world usage, its performance is abysmal We've had over a dozen developers switch to btrfs in my group on their various environments (OpenSUSE, Fedora, own rolled distros) and they've all gone back to their previous filesystem of choice. Simplest test I can suggest to btrfs users to attempt is the following: dd if=/dev/zero of=/mnt/btrfs/file bs=4k count=100 oflag=direct dd if=/dev/zero of=/mnt/ext4/file bs=4k count=100 oflag=direct It will emulate the similar operation to an fdatasync(). -- Doug Goldstein
[gentoo-dev] Unstabling a package
Any specific procedure to unstable a package? Specifically MythTV. While there's a lot of user interest in the package, there's just not enough dev help with the package to really keep it up to snuff to what could be considered stable. Its woefully behind and I'd just be happier to drop the current stable and bump everything as unstable. -- Doug Goldstein
[gentoo-dev] How to handle x86/amd64 only packages on other arches
I need to be able to have ppc/arm/etc users install a package that can only be built on x86/amd64. The packages in question are sys-apps/seabios and sys-apps/vgabios. The point is that a PPC machine that's using qemu-system-x86_64 still needs to use seabios and vgabios. I was planning on building the package on my own hardware and posting up sys-apps/seabios-bin and sys-apps/vgabios-bin unless of course someone has a better suggestion. I know the list tends to devolve into the theory of foo/bar and foo/baz but I'd like to keep this concrete to those two packages. -- Doug Goldstein
Re: [gentoo-dev] enew{user,group}: killing off [extra] argument
On Sun, Nov 6, 2011 at 4:54 PM, Mike Frysinger wrote: > On Sunday 06 November 2011 13:33:48 Petteri Räty wrote: >> On 03.11.2011 17:30, Mike Frysinger wrote: >> > http://sources.gentoo.org/eclass/user.eclass?r1=1.8&r2=1.9 >> >> Less than a day is quite a short time for people to comment. Also it >> would be better to include the diff in the original email. > > 4 days later and still no one cares > -mike > I care Mike... I care... that the code is now cleaner and more maintainable. Thank you for doing this improvement. -- Doug Goldstein
Re: [gentoo-dev] nvidia-settings needs a maintainer (or something)
On Mon, May 9, 2011 at 12:47 PM, Samuli Suominen wrote: > should have announced this before, but nvidia-settings needs an active > maintainer or it should be merged back to the nvidia-drivers > > the bugs idle on maintainer-needed@ now, you can find them easily by > search keyword of "nvidia-settings" > > Jer has been doing some work on the matter, so might want to discuss > with him before just "taking over" > > - Samuli > > I'll take it over as I've wanted to do to keep the two packages in sync. -- Doug Goldstein
[gentoo-dev] Re: Last rites: x11-drivers/nvidia-drivers-71.86.x
On Tue, Jul 13, 2010 at 12:16 AM, Doug Goldstein wrote: > Last rites: x11-drivers/nvidia-drivers-71.86.x > > The Video ABI in these drivers is no longer supported by any version > of x11-base/xorg-server that Gentoo has in the tree. Gentoo has not > had a version that supported this video ABI in the tree for some time > now. As a result, this version will leave the tree in approximately 30 > days. > > -- > Doug Goldstein > Its the end of August folks, these versions have been removed. -- Doug Goldstein
Re: [gentoo-dev] Re: Last rites: eclass/php5_1.eclass
On Sat, Jul 17, 2010 at 6:28 PM, Ryan Hill wrote: > On Sat, 17 Jul 2010 22:23:03 +0200 > Matti Bickel wrote: > >> On 07/17/2010 09:58 PM, Matti Bickel wrote: >> > since there's no dev-lang/php-5.1* version in the tree anymore, this >> > eclass is useless. It will be removed on 17th August 2010. >> >> I've just been told by scarabeus that eclass removal is a two years >> minimum process. So it'll be removed 17th August 2012 and marked #...@dead >> (deprived of functionality) in the next days. > > /me shakes his fist once again at the inanity of this policy. > > Just remove it! If the council can not be bothered to help developers develop but instead hinder developers from developing, then they are no longer relevant and should be treated as such. Other course of action could always be that they should all be kicked out and replaced with a suitable organization to ensure Gentoo's technical and developmental success. -- Doug Goldstein
[gentoo-dev] Last rites: x11-drivers/nvidia-drivers-71.86.x
Last rites: x11-drivers/nvidia-drivers-71.86.x The Video ABI in these drivers is no longer supported by any version of x11-base/xorg-server that Gentoo has in the tree. Gentoo has not had a version that supported this video ABI in the tree for some time now. As a result, this version will leave the tree in approximately 30 days. -- Doug Goldstein
Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others
On Mon, Jul 12, 2010 at 3:54 AM, Petteri Räty wrote: > On 07/12/2010 12:56 AM, Doug Goldstein wrote: > >> I remember very clearly as you and I were both council members at the >> time. My point is that this discussion does not need to even happen >> and the council shouldn't even remotely be involved here. >> > > I assumed the best way to change policy would be to ask council to rule > on it. Of course we could just see if we can get a consensus fast > without council. There is no change of policy and there is no reason for the council to be involved. He can change the eclass how he needs and that's the end of the story. The council does not need to be involved at every potential crossroad. The council only needs to be involved when a potential technical issue arises. No technical issue, proceed ahead. No need for the council to road block. e.g. if its not in the "rule" book you can do it. This is vastly different then your interpretation of the council's mandiate, Petteri, which is "if its not in the rule book go ask permission". Hence my point of saying let developers develop instead of telling them they need to ask permission and wait 4 weeks while it gets on an agenda list everytime they want to commit to the tree or blow their nose or boot up their computer. -- Doug Goldstein
Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others
On Sun, Jul 11, 2010 at 11:37 AM, Jorge Manuel B. S. Vicetto wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Doug. > > On 11-07-2010 16:03, Doug Goldstein wrote: >> On Sun, Jul 11, 2010 at 7:49 AM, Petteri Räty wrote: >>> On 07/11/2010 08:02 AM, Doug Goldstein wrote: >>> >>>> If I really need to go to the council with every change, considering >>>> it must be debated on the ML for at least X number of days prior to >>>> going to the council, I'd more likely just remove MythTV from the tree >>>> and maintain it in an overlay. I don't invest a lot of time in the >>>> MythTV ebuilds, but they work for a large majority of people. And when >>>> a new version comes out it requires some retooling and it just works >>>> for everyone. >>>> >>> >>> When someone proposes this I'll let you know. What's under discussion is >>> allowing removals to the public API of eclasses by following a >>> documented process (that doesn't involve council approval). >>> >>>> So basically, you guys decide.. am I pulling them out of the tree or >>>> am I leaving them in? >>>> >>> >>> If you decided to drop maintenance of MythTV in main tree, wouldn't it >>> be a better service to users to try and find a new maintainer (who would >>> possibly merge stuff from your overlay)? >>> >>> Regards, >>> Petteri >>> >>> >> >> Simply put, the council's purpose is not to say "oh we have to stop >> development and have a 4 week debate about everything minor". The >> council's purpose is to help decide between different technical >> solutions and encourage people to move forward on one unified path. >> The council's purpose is not to HINDER development as your responses >> clearly suggest you would like to hinder eclass development but >> instead to promote positive development. > > There seems to be some misunderstanding going on as we (Gentoo) haven't > approved (in prior councils terms or in the current one which hopes to > have its first meeting in the coming week or the following) any rules > about eclass changes having to be discussed or approved by the council. > >> Someone along the years the council lost its way and has felt that it >> needs to stick its fingers into places that it really doesn't belong. >> Its really become like the upper management at a large company that >> slows its developers down, instead of helping make them more >> efficient. > > About the issue in discussion, Petteri was recalling that contrary to > what anyone new to Gentoo might conclude from the current discussion, > the issue of eclass deprecation has been subject to at least 2 separate > discussions in the past 2 or 3 years and that in the last round there > was a proposal for setting minimal deprecation time frames. > > - -- > Regards, > > Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org > Gentoo- forums / Userrel / Devrel / KDE / Elections Jorge, I remember very clearly as you and I were both council members at the time. My point is that this discussion does not need to even happen and the council shouldn't even remotely be involved here. Let developers develop. -- Doug Goldstein
Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others
On Sun, Jul 11, 2010 at 7:49 AM, Petteri Räty wrote: > On 07/11/2010 08:02 AM, Doug Goldstein wrote: > >> If I really need to go to the council with every change, considering >> it must be debated on the ML for at least X number of days prior to >> going to the council, I'd more likely just remove MythTV from the tree >> and maintain it in an overlay. I don't invest a lot of time in the >> MythTV ebuilds, but they work for a large majority of people. And when >> a new version comes out it requires some retooling and it just works >> for everyone. >> > > When someone proposes this I'll let you know. What's under discussion is > allowing removals to the public API of eclasses by following a > documented process (that doesn't involve council approval). > >> So basically, you guys decide.. am I pulling them out of the tree or >> am I leaving them in? >> > > If you decided to drop maintenance of MythTV in main tree, wouldn't it > be a better service to users to try and find a new maintainer (who would > possibly merge stuff from your overlay)? > > Regards, > Petteri > > Simply put, the council's purpose is not to say "oh we have to stop development and have a 4 week debate about everything minor". The council's purpose is to help decide between different technical solutions and encourage people to move forward on one unified path. The council's purpose is not to HINDER development as your responses clearly suggest you would like to hinder eclass development but instead to promote positive development. Someone along the years the council lost its way and has felt that it needs to stick its fingers into places that it really doesn't belong. Its really become like the upper management at a large company that slows its developers down, instead of helping make them more efficient. -- Doug Goldstein
Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others
On Sat, Jul 10, 2010 at 10:02 PM, Ryan Hill wrote:
> On Sat, 10 Jul 2010 01:34:37 -0700
> Brian Harring wrote:
>
>> On Sat, Jul 10, 2010 at 09:30:42AM +0300, Petteri RRRty wrote:
>> > The standing policy is still not to remove any public functionality from
>> > eclasses. If we decide to start removing functionality the council
>> > should set common rules for it.
>>
>> Just adding a note on this one- the original technical reason for
>> this policy (portage inability to run from just the saved env dump)
>> is no longer an issue.
>>
>> If people want to allow eclasses to have fluid APIs (specifically
>> removal of functionality), that's a discussion that needs to start on
>> the dev level.
>>
>> Anyone got strong opinions on this one?
>
> I don't believe there ever was such a policy, except for pkg_{pre,post}rm
> because of the mentioned technical limitations (which were fixed in portage
> 2-3 years ago now). If there is such a policy then I've violated it on
> several occasions :). In fact, isn't the generally accepted method of
> deprecating an eclass to remove all functionality and replace it with a
> message in global scope and a "# @DEAD" tag?
>
> I don't see the advantage of keeping unmaintained broken code no one should
> use around in eclasses. You can argue that removing eclass functionality can
> potentially break ebuilds in overlays, but if you follow that line of
> reasoning then really we should never remove any package from the tree
> because it may be a dependency of something, somewhere.
>
> So I'd like to see a policy that treats public functions in eclasses the same
> as the last rites policies for package removal: minimum 30 day deprecation
> period, mail to dev-announce, etc.
>
>
> --
> fonts, gcc-porting, and it's all by design
> toolchain, wxwidgets to keep us from losing our minds
> @ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
>
To be honest, the MythTV eclasses have been an ever evolving set of
eclasses for ages now. Ever since it was declared that its now safe to
remove eclasses from the tree since Portage saves eclasses and its
env, therefore it wouldn't cause a problem.
If I really need to go to the council with every change, considering
it must be debated on the ML for at least X number of days prior to
going to the council, I'd more likely just remove MythTV from the tree
and maintain it in an overlay. I don't invest a lot of time in the
MythTV ebuilds, but they work for a large majority of people. And when
a new version comes out it requires some retooling and it just works
for everyone.
So basically, you guys decide.. am I pulling them out of the tree or
am I leaving them in?
--
Doug Goldstein
Re: [gentoo-dev] RFC: removal of virtual/php from depend.php
On Fri, Jul 9, 2010 at 5:09 PM, Matti Bickel wrote: > So we're replacing virtual/php with dev-lang/php in depend.php. > Question is: do we need depend.php-r1 for this? Did I miss some > important point about the change? > Matt, No you don't. You should be free to make the change. -- Doug Goldstein
Re: [gentoo-dev] The future of sys-apps/openrc in Gentoo
On Mon, Jul 5, 2010 at 11:13 AM, Enrico Weigelt wrote: > * Nirbheek Chauhan schrieb: > >> What you are saying makes sense for desktop users since they will >> likely already have consolekit/policykit/nm-applet installed, and >> hence using NetworkManager for all network management makes sense. > > Actually, I've got several Gentoo-based desktop systems, none of > them uses any these packages. > >> From what I can see, we have three options: >> (a) Make our existing openrc network code + openrc configuration files >> work with systemd, and move to systemd by default >> (b) Make systemd work with openrc+NM configuration files[1], make NM >> work w/o PK/CK[2], add command line tools to NM, and move to systemd >> by default. >> (c) Support systemd as an alternative init system for use by desktop users. > > (d) Fix systemd to get rid of dependencies to dbus, etc. > > (e) Get our network scripts compatible with netcf [1], which is the way of the future for letting applications modify the network configuration of the system. [1] https://fedorahosted.org/netcf/ -- Doug Goldstein
Re: [gentoo-dev] when to use a function and an implementation use flag.
On Sat, Mar 27, 2010 at 9:44 AM, Petteri Räty wrote: > On 03/24/2010 08:30 PM, Peter Hjalmarsson wrote: > >> For qemu-kvm the problem is that there is only one implementation (i.e. >> gnutls), and if I want to have ssl support I have to enable gnutls for >> this package. > > In this case the ebuild should have only ssl use flag. > >> When I wrote a bug about this I got a rather short reply from maintainer >> about pointing me to the policy about this. > > Where did he point you to? I didn't point him anywhere. I merely asked him for a policy on this. Because senseless changes in USE flags will require my 9 VM servers will need to be tweaked around for a pointless USE flag change and I don't need administrative burden for the sake of administrative burden. > >> So I have a question: >> Is there no policy about this? > > The policy is that USE="ssl" controls whether to enable ssl support in > general. Then the specific use flags like gnutls and openssl control > what implementation to use if the package supports multiple. Again, this policy is stated but no one can point me to anything. The closest thing to a "policy" is you sending a follow up e-mail to the dev list to make this a policy. -- Doug Goldstein
Re: [gentoo-dev] RFC: changing ssl use flag descriptions and unify behavior
On Sat, Mar 27, 2010 at 9:54 AM, Petteri Räty wrote: > See this thread for background: > http://archives.gentoo.org/gentoo-dev/msg_0673a33fe75961e510872fd2c1044ced.xml > > I think we should go through all the ssl use flag using packages and > unify the use flag descriptions and behavior to the following standing > policy (handed down probably): > > 1) packages always have the general ssl use flag to control whether to > enable ssl at all > 2) If the package supports multiple backends then there's use flags for > gnutls, openssl or nss. EAPI 2 use defaults will be used to > communicate upstream defaults if any. If they are all turned of > select the default (ssl being on). > > No objections and I will open a tracker a week from now and let's see > who joins up to go through packages and open bugs. > > Regards, > Petteri > > I seriously hate changing USE flags for the sake of changing use flags. This provides a moderate amount of annoyance for anyone that maintains more then one Gentoo box because they need to then tinker with their /etc/make.conf and /etc/portage/package.use to get everything right again. And oh no what if the one box is on ~arch and one isn't and what if one is x86 and one isn't. Its just such a configuration nightmare. So unless there's any real benefit, I'm against this. Also two little side points... USE defaults happened in EAPI 1. And the method by which you're asking people to select would be nice if we had some method for saying USE X and Y are subset of USE A. -- Doug Goldstein
[gentoo-dev] Re: Pending mask of Qt3 and MythTV
On Sun, Feb 21, 2010 at 11:25 PM, Ben de Groot wrote: > Hi, > > As the Gentoo Qt team has announced six months ago, Qt3 is about to be > masked now (see bug 283429). We sent another mail with a timeline at > the end of December. Most of the issues surrounding the mask and > removal of Qt3 have been solved. But we see ourselves confronted with > one remaining issue: MythTV. Its current stable version uses Qt3, but > there is a Qt4 version in testing. In all this time the MythTV > maintainers have not taken any action. Incorrect. You came to me a few months ago and I told you I would not and will not have time to mess with the package at all. I think I've made that clear in past mailing list posts, discussions we've had, and on bugzilla. Many people have spoken up about the situation and time and time again I've said "please, take over the package. It needs to be stabilized and a new unstable bump needs to happen." You took one of those times to create a ticket saying you'd stabilize it, then deferred to me and the arch teams. My response was the arch teams haven't stabilized MythTV in years because none of them have a setup to test it, so please stabilize it. I'm running it on a stable machine. I do not have my Gentoo commit machine up and running right now. I've only got my MythTV machines running x86 and amd64 with MythTV running ~arch for a while now. So I ask you once again, PLEASE just mark it stable. SOMEONE. And quit accusing anyone of inaction. As far as the news item goes, as I've said before. Its completely unnecessary since MythTV will handle notifying you properly if you need to do anything to your database. I can count more than a dozen people on Gentoo that have successfully done the conversion without issue. The problem stems from people either not reading the instructions when MythTV tells them they need to take action and read the update guide. Or people stupidly reading the upgrade guide, thinking "oh I'll upgrade my DB early" and upgrading their DB and then running their old version. A news item will probably do more harm than good and will result in a lot of partial corruptions, which we already have one person on the bug you guys made for the news item already doing. -- Doug Goldstein
Re: [gentoo-dev] Last rites: media-tv/linuxtv-dvb-firmware
On Mon, Feb 8, 2010 at 1:15 PM, Daniel Pielmeier wrote: > # Daniel Pielmeier (08 Feb 2010) > # Masked for removal on 10 Mar 2010. > # Manifest failures due to upstream source changes without version bump. > # SRC_URI changes all the time. Firmware extraction fails. Overly complex > # ebuild for just installing one or two files. > # Will be replaced by updating the vdr-guide with information on how to obtain > # and install the firmware. > media-tv/linuxtv-dvb-firmware > > -- > Daniel Pielmeier > > > Ignore this. Its not being removed. -- Doug Goldstein
[gentoo-dev] x11-libs/cairo USE defaults change
I figured I'd let everyone know that this weekend sometime I plan on changing the cairo ebuilds to have IUSE="+svg". It seems like a lot of default installs of various things out of the box actually rely on cairo to have SVG support and users are presented with an ugly error message out of the box all the time. Any objections, speak up now. -- Doug Goldstein
Re: [gentoo-dev] Upstream tags in metadata.xml (GLEP 46)
On Thu, Feb 4, 2010 at 7:05 PM, Mike Frysinger wrote: > On Thursday 04 February 2010 16:37:01 Tiziano Müller wrote: >> While some people already discovered the upstream metadata tags, there >> are only 8 ebuilds using them so far. Mostly I am to blame for that, >> since I forgot to send out a proper announcement. While all the required >> information can be found in the Developer Handbook [1], here is a short >> summary: > > anyone who feels like doing this kind of work should feel free to add any > tags to base-system/toolchain/games packages ... no need for > bugzilla and such. > -mike > Ditto on base-system/mythtv/app-emulation -- Doug Goldstein
Re: [gentoo-dev] GLEP59 - Manifest2 hashes
On Sun, Jan 31, 2010 at 3:57 AM, Robin H. Johnson wrote: > > The SHA512 algorithm is available in Python 2.5, which has been a > dependency of Portage since approximately Python 2.1.6.13. I hate to nitpick, but I believe you meant Portage in that line. However, great work on this GLEP, you've put forth some good solid research into it. I do hope that we don't intend on settling on SHA512 as the end all solution as well. We should retain a method for bumping the hashing algorithm used when the SHA-3 family becomes available. -- Doug Goldstein
Re: [gentoo-dev] g15 and freevo up for grabs
On Mon, Jan 18, 2010 at 10:56 AM, Robert Buchholz wrote: > Hello, > > I want to drop maintenance for some of the packages that I have acquired > over the years. Some of them are still co-maintained, some are now > unmaintained. > > === Freevo === > > Freevo is split up in different Python components. They are all > maintained by a herd, but a dedicated maintainer is needed. > > media-tv/freevo # media-tv herd > Should be worth noting that no one from media-tv herd actually uses freevo or has an interest in it. You've got 2 MythTV guys and 2 vdr guys in the herd and that's it. Unless someone steps up this package should be marked maintainer-needed. -- Doug Goldstein
Re: [gentoo-dev] net-fs/netatalk is facing removal
On Fri, Jan 8, 2010 at 2:38 PM, Samuli Suominen wrote: > since noone seems to care about this package, and it's blocking glibc > stabilization it will be removed from tree wrt bug 300218 > > last chance > > thanks, Samuli > > Its been saved. -- Doug Goldstein
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: use.local.desc
On Thu, Dec 31, 2009 at 4:13 PM, Samuli Suominen wrote: > On 01/01/2010 12:07 AM, Robin H. Johnson (robbat2) wrote: >> +app-accessibility/flite:alsa - use alsa for audio output. >> +app-accessibility/flite:oss - Use Open Sound System for audio output. > > Why? USE alsa and oss are global flags. > > Real question is why not? local USE flags provide more details than the very generic global description and as such are considered a good thing. That is one of the purposes I had in mind originally when I wrote GLEP 56 [1]. [1] http://www.gentoo.org/proj/en/glep/glep-0056.html -- Doug Goldstein
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 1:15 PM, Jeroen Roovers wrote: > On Mon, 28 Dec 2009 10:10:48 +0100 (CET) > lx...@gentoo.org wrote: > >> let's discuss concerns here (actually I don't see any and I am >> willing to fix all the ebuilds and close all my bugs if you ack). > > If they are genuine bugs, then there isn't anything to discuss. > >> List of Gentoo bugs: > > Tracker bug is #298759[1] > > > Regards, > jer > > > [1] https://bugs.gentoo.org/show_bug.cgi?id=298759 > > > Then there was no need to waste everyone's time with a backhanded comment about the X11 herd. And we can all get on with our lives. -- Doug Goldstein
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 3:10 AM, wrote: > In the aim of improving binpkgs status, I filed a bunch of bugs against all > the libX* available in tree that contain wrong RDEPEND bits pointing to > x11-proto/* stuff. > To x11, just don't get angry (eheh), let's discuss concerns here (actually I > don't see any and I am willing to fix all the ebuilds and close all my bugs > if you ack). Why not provide some actual meat and potatoes here instead of a useless e-mail with bug numbers and some stupid attempt at humor at the expense of the x11 herd?
Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date
of people, who can and are > willing to work on > portage code is limited, so which other way do you have to improve it as > requested? > > And yes, it is frustrating to see 3 council sessions and months going by and > still no offer to > support, no discussion, no patches and no decision is made. I can see now, > why such project did die > before and why people dont want to do such things, which can actually improve > the experience with > Gentoo and can give our userbase more options and choice. > >> >> I will stop now because I'm at a bus stop near Mount Fuji and I need >> to go. I hope the other council members, especially the more >> technically competent ones than me, will get back to you on this and >> offer help and advice. As soon as I have a better internet connection >> I will contact you about this. > > Feel free to do so. > > P.S.: I dont want to affront you or anyone else personally, but the way, how > it currently goes. I > know from IRC, forums and mails, that there are people around, who would like > to see > multilib-features in portage. But with such frustrating none-actions like > this, noone should wonder > why such things are not implemented, also there are people, who would like to > see it and even > people, who would help doing it and creating code for it. That does not > actually speak for Gentoo, > more against it (and it is not the only point, where Gentoo could improve, > but does not, but that > could be part of another big mail). > > > -- > Thomas Sachau > > Gentoo Linux Developer > > People are honestly just waiting for this to hit the tree at this point. Inaction by the council is a serious failure of the council. The Portage team doesn't want to start integrating code that the council will force them to remove in the future. Being a former council member myself I can easily say, get off your ass and do something. -- Doug Goldstein
[gentoo-dev] app-emulation/kvm moves to app-emulation/qemu-kvm
Hey all, app-emulation/kvm has moved to app-emulation/qemu-kvm to align ourselves better with the development goals of upstream. If anyone wants to maintain this package (and app-emulation/kvm-kmod) please feel free to step up and join because I honestly will not have much time to maintain it. -- Doug Goldstein
Re: [gentoo-dev] GLEP 27 Bump
On Sun, Nov 15, 2009 at 7:35 PM, Robin H. Johnson wrote: > On Sun, Nov 15, 2009 at 09:25:45AM +0200, Petteri Räty wrote: >> Doug Goldstein wrote: >> > GLEP 27 [1] seems pretty stagnant and I'm planning on giving it a bit >> > of a refresh and actually implementing it. Now before I do this I'm >> > not in love with the format in tree but I haven't decided on a format >> > exactly in my head. So that being said, I'm sending this out looking >> > for some opinions or ideas for my new GLEP. One of the obvious things >> > I'll cover is all the ambiguity of the GLEP with regard to the data >> > inside each of the files. >> > >> > [1] http://www.gentoo.org/proj/en/glep/glep-0027.html >> One idea worth considering is making users just ebuilds with a >> supporting eclass. > While I'm hugely in favour of having consistent UID/GIDs with no > conflicts over all Gentoo machines, I feel one of the reasons that the > GLEP failed was that users required by ebuilds changed over ebuild > versions, and the GLEP didn't seem to handle that well. > > Cases I've seen in the tree: > - username change (slocate -> locate) > - homedir change > - shell change > Which would seem to mean that Petteri's suggestion would work better since that would allow us to version/upgrade user/group data. -- Doug Goldstein
[gentoo-dev] GLEP 27 Bump
GLEP 27 [1] seems pretty stagnant and I'm planning on giving it a bit of a refresh and actually implementing it. Now before I do this I'm not in love with the format in tree but I haven't decided on a format exactly in my head. So that being said, I'm sending this out looking for some opinions or ideas for my new GLEP. One of the obvious things I'll cover is all the ambiguity of the GLEP with regard to the data inside each of the files. [1] http://www.gentoo.org/proj/en/glep/glep-0027.html -- Doug Goldstein
[gentoo-dev] global USE flag description change: css
The css USE flag currently says: Enables ripping of encrypted DVDs But that really doesn't describe the usage correctly. It enables the ability to READ encrypted DVDs. I'm going to make the change if no one objects. -- Doug Goldstein
