Re: [gentoo-dev] Re: How a proper server profile should look like
On 22 January 2013 10:36, Walter Dnes wrote: > I think we may have to admit that "one size does not fit all". There > are just too many individual scenarios. A truly minimal build should be > sufficient to boot to a text console, and have networking and portage to > be able to build further up the chain. It's not something "we may have to admit". It's been the Gentoo philosophy from the very start. That's why we have useflags and so on. Gentoo is based on choice and customization. The guiding idea for the base profile is that it should result in a lean but functional system, with defaults that the majority of users would need. Maybe we have erred on the side of inclusiveness in the past, and now is the time to move more towards minimalism, as we have a new set of 13.0 profiles being sculpted into shape. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Re: How a proper server profile should look like
On 22 January 2013 03:28, Rich Freeman wrote: > On Mon, Jan 21, 2013 at 12:51 PM, Dustin C. Hatch > wrote: >> The package defaults have gotten out of hand, in my opinion. I use >> default/linux/amd64/10.0 on all my machines and my /etc/portage/package.use >> directories have dozens of -flag entries for packages with ridiculous >> defaults, and almost none that come from the profile. I'm considering >> removing pkginternal from USE_ORDER. > > And this is the problem with having the default profile be really > minimal. It just moves the problem into per-package defaults that are > much more painful to override. No offense, but that's nonsense. You override it the exact same way. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
2013/1/21 Pacho Ramos : > This can be useful when, for example, doc contents are modified. You can > then rely on using REPLACING_VERSIONS in your ebuild to print messages > when people updates from versions using old docs > > Patch to review attached > Would'nt be better to just set some variable in the ebuild, rather than call function that touches empty file? Tom
[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
Sergey Popov posted on Tue, 22 Jan 2013 10:22:34 +0400 as excerpted: > 22.01.2013 08:23, Mike Gilbert wrote: >> I guess this change is ok, given that I can opt-out fairly easily. >> Zac's workaround for binary packages makes me feel better too. > > I am curious, can not this check be added to eclass? Or eclass does not > know about type of merged package? AFAIK, binpkgs are a PM-specific feature that isn't managed by PMS. As such, eclasses and ebuilds officially must remain binpkg agnostic, leaving all such handling to the PMs themselves. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
22.01.2013 08:23, Mike Gilbert wrote: > I guess this change is ok, given that I can opt-out fairly easily. Zac's > workaround for binary packages makes me feel better too. I am curious, can not this check be added to eclass? Or eclass does not know about type of merged package? -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: USE flags dri, cups, pppd
Hans de Graaff posted on Mon, 21 Jan 2013 08:46:59 +0100 as excerpted: > On Sun, 2013-01-20 at 18:03 +0100, Chí-Thanh Christopher Nguyễn wrote: > >> We can either set it in the base profile, then there is no need for >> IUSE="+dri". Or we can set it in every single ebuild that has the dri >> flag. I prefer the former because it reduces our maintenance burden. > > [I]t sounds like you want [...] use IUSE="+dri". This would also help > all the people starting out with "-*". ?? How would setting the default using IUSE="+dri" in the ebuilds help those starting out with -*? -* does just that, hard-setting all USE flags as disabled, unless they're specifically enabled later in the USE flag configuration. Thus, it's the same effect on default-enabled-flags, regardless of whether they're default-enabled in the profile or in the ebuilds. [TLDR folks can stop at that.] FWIW, based on this discussion I wondered just how much effect USE- defaults, both the profile and ebuild sort, were having here. Thus, I set -* myself, and have been working thru the changes one at a time. I've a couple packages yet to deal with ATM, but after I resolved enough of the required-use issues for emerge --pretend --newuse @world to even spit out a remerge list, I started with 40-some packages with --newuse changes. More or less what I expected... Most of the changes I've been able to resolve by either adding the flags to the use file sourced by my make.conf, or by deciding I didn't need the flag enabled anyway, and remerging the package without it. I've only added a few flags to package.use, as most of them were used by only the affected packages anyway, at least based on the packages I have installed. FWIW2, I'm /thinking/ about setting up my own profile entirely... or setting it up to cascade only from my custom-selected components, at least, keeping the profile-base for the global package-mask, and perhaps the amd64-no-multilib stuff. I already have zero packages in @system as I've negated all the entries that would otherwise be there, and I'm in the process of zeroing out my dependence on profile default-use... When I'm done with that, I'll take a look at the rest and see... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 01/21/2013 10:38 PM, Robin H. Johnson wrote: > CONFIG_CHECK has not been fatal for some years now, because there turned > out to be some cases where it cannot detect what the system really has > [1], or what is returned is wrong [2]. > > However, while this is has been superb in helping those corner-cases, > the fallout is that users frequently ignore the non-fatal warnings that > a configuration option is needed to run a binary later, and end up with > weird breakage. > > This patch introduces a new option, CONFIG_CHECK_FATAL, defaulting to > enabled, that explicitly causes a die if: > - CONFIG_CHECK cannot be performed successfully. > - Any CONFIG_CHECK options fail. > Technical issues aside, I'm conflicted on this. In general, I don't believe in protecting people from shooting themselves. However, I also know how easy it is to ignore elog messages. I guess this change is ok, given that I can opt-out fairly easily. Zac's workaround for binary packages makes me feel better too. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 01/21/2013 08:10 PM, Rick "Zero_Chaos" Farina wrote:
> On 01/21/2013 10:56 PM, Zac Medico wrote:
>> On 01/21/2013 07:45 PM, Mike Gilbert wrote:
>>> My suspicion is that portage's environment save/restore process will
>>> overwrite any setting I attempt to make on the destination host.
>
>> If necessary, you can use /etc/portage/bashrc to override
>> CONFIG_CHECK_FATAL for binary packages. Something like this would work:
>
>> [[ ${EMERGE_FROM} == binary ]] && CONFIG_CHECK_FATAL=0
>
>
> does this means I need to start adding "export CONFIG_CHECK_FATAL=0" to
> my catalystrc?
I guess so, if you don't want those fatal config checks to kill your
catalyst builds.
--
Thanks,
Zac
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/21/2013 10:56 PM, Zac Medico wrote:
> On 01/21/2013 07:45 PM, Mike Gilbert wrote:
>> My suspicion is that portage's environment save/restore process will
>> overwrite any setting I attempt to make on the destination host.
>
> If necessary, you can use /etc/portage/bashrc to override
> CONFIG_CHECK_FATAL for binary packages. Something like this would work:
>
> [[ ${EMERGE_FROM} == binary ]] && CONFIG_CHECK_FATAL=0
>
does this means I need to start adding "export CONFIG_CHECK_FATAL=0" to
my catalystrc?
- -Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJQ/hFJAAoJEKXdFCfdEflK53UP/3Ngz3yBmkPz6E7sBZhjnJiW
CVaRlXvXs3sSn9zWdAxxVn1Z2z3RP387eb7jEXOoUAyIezwVfBLZIfPXUK8KN8rD
LRSntTv3E1AUpE+N0GlxRGVlKYnDf3g+EAi0M6iEjtcVBxsCNiH+UcmwHvPFp/oN
R4n79qD3jWEMMnm708RqkwKKu+/F4wfpUQe66UhAwd4yFDkndl/lwrtwmgztMjtF
W6V6Z1ZkWg0r0rRTxhuAYwMcYFKunfSzNCnaD72z0d184fwxcSw2N697vAPCXiLp
MbjCENLME3+dk088YvjNoZCCcga+9omsIKDG/gkgTJib4Ibrc028Ut0G1Oyxrx+R
6LzES1GRshlx0W9N+b+CmChffWfaGENXx2sSM5W6yD6eJtxGPw736JxGMQcpSltz
G+z+tLwDbx1rvHDBeAWzSU0k+W6Yx/QJ4L5D1LNaA/S3pEXwU6aK2ipoRpiNrJfC
aRWyJx1KGLF+vhrN70SiFASJyotmQwoFipgHjm5QbBiHn8sK0cq3gf9wb3nLRNoD
Ym7u9plg85y/W1Gme09vqlptMzwymIrCmXQHuBeqwILJ+lsVQBa1rL/0fnMyDftX
GLT35hIWM7OVUufuiKB6xiOLH0h/P9w45wUZBiPzldphd5wYr3TMkZFv4C8Qgc1/
1/h2B65Lw5wfF5SEuVo7
=oVpV
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 01/21/2013 07:45 PM, Mike Gilbert wrote:
> My suspicion is that portage's environment save/restore process will
> overwrite any setting I attempt to make on the destination host.
If necessary, you can use /etc/portage/bashrc to override
CONFIG_CHECK_FATAL for binary packages. Something like this would work:
[[ ${EMERGE_FROM} == binary ]] && CONFIG_CHECK_FATAL=0
--
Thanks,
Zac
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 01/21/2013 10:38 PM, Robin H. Johnson wrote: > I'm raising this patch because of the recent spate of bugs with the > latest udev that now fails to boot your system if CONFIG_DEVTMPFS is > not available in your kernel. > > Bugs: 408947, 409393, 437320, 453074 > > CONFIG_CHECK has not been fatal for some years now, because there turned > out to be some cases where it cannot detect what the system really has > [1], or what is returned is wrong [2]. > > However, while this is has been superb in helping those corner-cases, > the fallout is that users frequently ignore the non-fatal warnings that > a configuration option is needed to run a binary later, and end up with > weird breakage. > > This patch introduces a new option, CONFIG_CHECK_FATAL, defaulting to > enabled, that explicitly causes a die if: > - CONFIG_CHECK cannot be performed successfully. > - Any CONFIG_CHECK options fail. > > For the aforementioned corner cases, those environments are used to > customizing their make.conf heavily, and they should add: > CONFIG_CHECK_FATAL=0 > > This patch does NOT change the handling of ~/tilde in CONFIG_CHECK > - options that are required at compile-time MUST NOT use ~/tilde. > - options that are only required at run-time MUST include the ~/tilde. > > Footnotes: > 1. If you are using a VM environment, where the kernel is provided >outside of your VM, and you don't have kernel sources, or >/proc/config.gz, you CANNOT detect what options the kernel is >configured with. > 2. Building stages for example. You may have /proc bind-mounted from the >host system, but it does not reflect the environment you are building >for. > How does this variable interact with binpkgs? For example, if I build a package on a system that does not have CONFIG_CHECK_FATAL=0, what happens if I try to install it on a system that does not have a usable kernel config? My suspicion is that portage's environment save/restore process will overwrite any setting I attempt to make on the destination host. signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
I'm raising this patch because of the recent spate of bugs with the
latest udev that now fails to boot your system if CONFIG_DEVTMPFS is
not available in your kernel.
Bugs: 408947, 409393, 437320, 453074
CONFIG_CHECK has not been fatal for some years now, because there turned
out to be some cases where it cannot detect what the system really has
[1], or what is returned is wrong [2].
However, while this is has been superb in helping those corner-cases,
the fallout is that users frequently ignore the non-fatal warnings that
a configuration option is needed to run a binary later, and end up with
weird breakage.
This patch introduces a new option, CONFIG_CHECK_FATAL, defaulting to
enabled, that explicitly causes a die if:
- CONFIG_CHECK cannot be performed successfully.
- Any CONFIG_CHECK options fail.
For the aforementioned corner cases, those environments are used to
customizing their make.conf heavily, and they should add:
CONFIG_CHECK_FATAL=0
This patch does NOT change the handling of ~/tilde in CONFIG_CHECK
- options that are required at compile-time MUST NOT use ~/tilde.
- options that are only required at run-time MUST include the ~/tilde.
Footnotes:
1. If you are using a VM environment, where the kernel is provided
outside of your VM, and you don't have kernel sources, or
/proc/config.gz, you CANNOT detect what options the kernel is
configured with.
2. Building stages for example. You may have /proc bind-mounted from the
host system, but it does not reflect the environment you are building
for.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Index: linux-info.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/linux-info.eclass,v
retrieving revision 1.95
diff -p -u -r1.95 linux-info.eclass
--- linux-info.eclass 16 Jan 2013 14:29:01 - 1.95
+++ linux-info.eclass 22 Jan 2013 03:23:59 -
@@ -57,6 +57,16 @@
# This is to allow usage of binary kernels, and minimal systems without kernel
# sources.
+# @ECLASS-VARIABLE: CONFIG_CHECK_FATAL
+# @DESCRIPTION:
+# Make failure of CONFIG_CHECK fatal.
+#
+# Enabled by default to save users.
+#
+# If you use a binary kernel, a minimal system without kernel sources, or any
+# system where checking config is no possible, you must disable this.
+[[ ${CONFIG_CHECK_FATAL+set} == set ]] || CONFIG_CHECK_FATAL=1
+
# @ECLASS-VARIABLE: ERROR_
# @DESCRIPTION:
# A string containing the error message to display when the check against CONFIG_CHECK
@@ -701,6 +711,8 @@ check_extra_config() {
fi
ewarn " - ${config#\~}${msg:+ - }${msg}"
done
+ [[ ${CONFIG_CHECK_FATAL} == 1 ]] && \
+die "Cannot check kernel config per CONFIG_CHECK_FATAL."
ewarn "You're on your own to make sure they are set if needed."
export LINUX_CONFIG_EXISTS_DONE="${old_LINUX_CONFIG_EXISTS_DONE}"
return 0
@@ -784,7 +796,7 @@ check_extra_config() {
fi
done
- if [[ ${hard_errors_count} > 0 ]]; then
+ if [[ ${hard_errors_count} > 0 ]] || [[ ${CONFIG_CHECK_FATAL} == 1 ]] && [[ ${soft_errors_count} > 0 ]]; then
eerror "Please check to make sure these options are set correctly."
eerror "Failure to do so may cause unexpected problems."
eerror "Once you have satisfied these options, please try merging"
signature.asc
Description: Digital signature
Re: [gentoo-dev] Re: How a proper server profile should look like
On Mon, Jan 21, 2013 at 02:28:47PM -0500, Rich Freeman wrote > On Mon, Jan 21, 2013 at 12:51 PM, Dustin C. Hatch > wrote: > > The package defaults have gotten out of hand, in my opinion. I use > > default/linux/amd64/10.0 on all my machines and my /etc/portage/package.use > > directories have dozens of -flag entries for packages with ridiculous > > defaults, and almost none that come from the profile. I'm considering > > removing pkginternal from USE_ORDER. > > And this is the problem with having the default profile be really > minimal. It just moves the problem into per-package defaults that are > much more painful to override. I don't think changing the profile is the solution. I doubt that dozens of maintainers will immediately unset unwanted default USE flags simply because the default profile is made more bloated. As I mentioned in a previous message, my personal experience is that it's actually less work to start with "-*", and add as required, rather than to use defaults and then hack and slash at the unwanted stuff. Mind you, as per my sig, I run ICEWM and leave the extra ram for useful applications. We may simply have to admit that we can't please everybody. I suggest a "minimal" profile instead. It would boot to a text console, and have networking and portage, allowing you to build further. -- Walter Dnes I don't run "desktop environments"; I run useful applications
[gentoo-dev] Re: USE flags dri, cups, pppd
On Sat, 19 Jan 2013 00:02:05 + Ciaran McCreesh wrote: > On Fri, 18 Jan 2013 23:58:22 + > "Aaron W. Swenson" wrote: > > ++ If the base profile is to become our server profile, it should not > > have graphics related USE flags enabled. > > ...but that's not how USE flags work. It doesn't matter if you enable > monkeys in the base profile, since the only people who are affected are > people who install monkey-related packages. It doesn't affect server > users. "Minimal" is irrelevant. I, for one, demand more monkey-related packages. -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
Re: [gentoo-dev] Re: How a proper server profile should look like
On Mon, Jan 21, 2013 at 11:51:54AM -0600, Dustin C. Hatch wrote > The package defaults have gotten out of hand, in my opinion. I use > default/linux/amd64/10.0 on all my machines and my > /etc/portage/package.use directories have dozens of -flag entries for > packages with ridiculous defaults, and almost none that come from the > profile. I'm considering removing pkginternal from USE_ORDER. Have you heard the old joke about how an elephant is actually a mouse designed by a committee? The same thing applies to distro bloat. Some people want feature A, others want feature B, and others want feature C. The final result is a distro with features A *AND* B *AND* C. I was originally drawn to Gentoo with the "Gentoo Ricer" atitude. But now it's the fine-grained control of USE flags that makes me stay with Gentoo. I think we may have to admit that "one size does not fit all". There are just too many individual scenarios. A truly minimal build should be sufficient to boot to a text console, and have networking and portage to be able to build further up the chain. -- Walter Dnes I don't run "desktop environments"; I run useful applications
[gentoo-dev] Lastrite: coldplug, hotplug, hotplug-base and ezusb2131 (2.4 kernel module)
# Samuli Suominen (22 Jan 2012) # Remove coldplug, hotplug and hotplug-base in 30 days wrt bug #145809 sys-apps/ezusb2131 sys-apps/hotplug sys-apps/hotplug-base sys-apps/coldplug
[gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
This can be useful when, for example, doc contents are modified. You can
then rely on using REPLACING_VERSIONS in your ebuild to print messages
when people updates from versions using old docs
Patch to review attached
--- readme.gentoo.eclass 2013-01-20 12:42:30.0 +0100
+++ /usr/portage/eclass/readme.gentoo.eclass 2013-01-21 22:06:46.0 +0100
@@ -66,6 +66,18 @@
fi
}
+# @FUNCTION: readme.gentoo_force_print_elog
+# @DESCRIPTION:
+# For elog message printing. This can be useful when, for example,
+# DOC_CONTENTS is modified. You can then rely on using REPLACING_VERSIONS
+# in your ebuild to print messages when people updates from versions
+# still providing old message.
+# Should be called before pkg_postinst phase.
+readme.gentoo_force_print_elog() {
+ debug-print-function ${FUNCNAME} "${@}"
+ touch "${T}"/README.gentoo.force_print_elog
+}
+
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with "${T}"/README.gentoo contents.
@@ -74,7 +86,7 @@
debug-print-function ${FUNCNAME} "${@}"
if [[ -f "${T}"/README.gentoo ]]; then
- if ! [[ "${REPLACING_VERSIONS}" ]]; then
+ if ! [[ "${REPLACING_VERSIONS}" ]] || [[ -f "${T}"/README.gentoo.force_print_elog ]]; then
eshopts_push
set -f
cat "${T}"/README.gentoo | while read -r ELINE; do elog "${ELINE}"; done
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: How a proper server profile should look like
On Mon, Jan 21, 2013 at 12:51 PM, Dustin C. Hatch wrote: > The package defaults have gotten out of hand, in my opinion. I use > default/linux/amd64/10.0 on all my machines and my /etc/portage/package.use > directories have dozens of -flag entries for packages with ridiculous > defaults, and almost none that come from the profile. I'm considering > removing pkginternal from USE_ORDER. And this is the problem with having the default profile be really minimal. It just moves the problem into per-package defaults that are much more painful to override. Rich
[gentoo-dev] Re: How a proper server profile should look like
On 1/21/2013 02:01, Ralph Sennhauser wrote: On Mon, 21 Jan 2013 13:27:18 +0800 Ben de Groot wrote: On 21 January 2013 12:16, Peter Stuge wrote: Panagiotis Christopoulos wrote: I don't build server machines every day, others do and it would be much appreciated if they could respond here. I build catalyst stage4s. Any default profiles are kindof pointless for me; I have USE=-* and the flags that I want. Anything else seems a bit too random. This is why I think we do need something like a truly minimal profile to start building from. Too many people are doing this. -* will still be required by those same people for EAPI 1 package defaults. Cleaning a profile won't change that. The package defaults have gotten out of hand, in my opinion. I use default/linux/amd64/10.0 on all my machines and my /etc/portage/package.use directories have dozens of -flag entries for packages with ridiculous defaults, and almost none that come from the profile. I'm considering removing pkginternal from USE_ORDER. -- ♫Dustin
Re: [gentoo-dev] January stabilization candidates
Dne So 12. ledna 2013 14:49:52, Paweł Hajdan, Jr. napsal(a): > Please review attached automatically generated stabilization candidates > for January. > > I don't want to annoy people with automatically filed bugs, and at the > same time I also received lots of positive feedback about the effort to > keep the stable tree more up-to-date. > > I think the best way to proceed is to listen to that feedback and > continue the effort, while also keeping an updated list of exclusions > for packagers/herds that are actively stabilized by maintainers. > > Paweł Hmm, nice idea but how about expanding metadata.xml with something like info for stabilisations so they can be automatically grabbed for it. Quite few software is just nice enough that it can go automatically for stable in 30 days, and someone could just go then and open new bugs (with assigned arches) based on it (of course it expects brain from the guy reporting it that he checks if there are no open bugs). Because mails to -dev are frankly annoying. :-) Tom signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
Dne St 16. ledna 2013 17:09:07, Alexis Ballier napsal(a): > On Wed, 16 Jan 2013 12:40:02 + (UTC) > > "Tomas Chvatal (scarabeus)" wrote: > > scarabeus13/01/16 12:40:02 > > > > Modified: ChangeLog > > Added:ffmpeg-9.ebuild > > Removed: ffmpeg-0.10.2-r1.ebuild > > Log: > > Add new virtual for 1.1/9 series. Masked. Also it has switched dep > > > > order as will be announced upon unmasking. > > ... and since we are committing silently without any real discussion I > will switch the dep order again and announce it much later without > leaving room for discussion :) Did you read the msg, announced later on, i am just preparing that shit because now I have time. Given that its masked and does not affect existing installs it can stay like this forever. Also if you read planet you would see I stated it on a blog yesterday, preparation of all moves take some time. Also it will be discussed on the dev in near future. I don't have too much of the time and sending mails to -dev takes some preparations if you don't want them turn into huge bikeshed. > > More seriously: Why ? Who decided this ? > Let's be realistic, both upstreams claim they're better than the other > in one way or another, and let's think like serious downstreams, not > like upstream playground. I do think like serious downstream. Thus tracking what major distros do. Given fedora switched and debian too we ough to do it at some point too. Also quite few upstreams are migrating and few staying so there is a tie. But we have to work on supporting both which currently you don't (see bellow). > > As a downstream, I can see plenty of reasons against, but none in favor > of this change: > - There are still a couple of non-trivial packages that need to be > fixed to work with libav while I don't know any that works with libav > but not ffmpeg. Nice from you that you didnt bother to check out if it works or not because I do it quite often, so does tinderbox from Diego. Every time i bump shit I have to compile it in two virtuals just to please both camps. Lets not forget how carefull you were when commiting to xbmc where you completely fucked stable ebuild without even letting anyone know [1]. >From my checking only package right now not building with stable libav is again XBMC (in testing only). If there is something more open bugs in bugize. > - All (but the one discovered in Nov. 2012) of the security issues > fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May 2012 > (!!) for ffmpeg according to the website... 8 months before... So what? Checking their importance yea we ride it straight to stable on Gentoo, but security relevance would not deem any maintenance update only to be done with next proposed maintenance one (eg when there is something important to fix) because most of them look . I can waste time to look the other way around and show you broken code in ffmpeg which happened after broken merge from libav but lets not turn this into a piss contest. Basically this having two libraries hurt everyone, but both forks are on par and we as gentoo will provide both while preffered default will be what major distros use. If you disagree with that and you don't want your lead to make that decision, which you and I both don't want. I don't want Luca being blamed that he is evil libav dev who does this just to make more share for his pet project. We can wait with dealing this for a bit and propose it for council meeting. We vote about lots and lots of stuff there and another thread about two ffmpeg implems on g-dev will do just fine, but it will be hell of a bikeshed :-) Tom [1] https://bugs.gentoo.org/show_bug.cgi?id=443006
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier wrote: > > To be honest, I don't know if there's other way to hide USE flags than > > using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split > > the flags per-arch, i.e. have: > > > > MULTILIB_AMD64="abi1 abi2 abi3" > > MULTILIB_PPC64="abi1 abi2 abi3" > > > > with appropriate USE_EXPAND_HIDDEN set by profiles. > > I don't like that at all. > I'd go for ABI= the union of all the MULTILIB_ABIS variables (if there > is no name collision) Well, there is one :). > we certainly want skype to depend on libitneeds[abi_x86], not 'amd64? > ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )' Yes, that seems reasonable. On the other hand, mips will most likely want some prefix with names like 'n32' and 'n64'. Well, I think I'll have to ping the arch teams to see what kinds of multilib they want. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)
On Sun, Jan 20, 2013 at 11:27 PM, Ben de Groot wrote: > On 21 January 2013 12:16, Peter Stuge wrote: > > Panagiotis Christopoulos wrote: > >> I don't build server machines every day, others do and it would be > >> much appreciated if they could respond here. > > > > I build catalyst stage4s. Any default profiles are kindof pointless > > for me; I have USE=-* and the flags that I want. > > > > Anything else seems a bit too random. > > This is why I think we do need something like a truly minimal profile > to start building from. Too many people are doing this. Remember that we can also modify USE_ORDER to specifically drop profile flags *or* package-default flags, but not necessarily both. Maybe this is something that should be brought "above the table" and documented. It's a lot harder to shoot yourself in the foot by just dropping profile flags, but keeping package defaults. Of course, that adds another factor to the USE=dri in profile versus package-default discussion, too. -Ben Kohler
[gentoo-dev] [PATCH autotools-multilib 2/2] Use (-)-dep in MULTILIB_USEDEP to make sure it works.
Due to use.force and magic like that, non-EAPI-5 deps would be assumed
to have USE=multilib otherwise.
---
eclass/autotools-multilib.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/autotools-multilib.eclass b/eclass/autotools-multilib.eclass
index b4af121..dbf2ad1 100644
--- a/eclass/autotools-multilib.eclass
+++ b/eclass/autotools-multilib.eclass
@@ -45,7 +45,7 @@ IUSE=multilib
# RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
# net-libs/libbar[ssl,${MULTILIB_USEDEP}]"
# @CODE
-MULTILIB_USEDEP=multilib?
+MULTILIB_USEDEP='multilib(-)?'
# @FUNCTION: autotools-multilib_foreach_abi
# @USAGE: argv...
--
1.8.1.1
[gentoo-dev] [PATCH autotools-multilib 1/2] Require EAPI=5 for working MULTILIB_USEDEPs.
Long story short, PMS, portage, havoc and that stuff.
There's currently one in-tree eclass consumer and I have bumped it
to EAPI=5 (from 4) already.
---
eclass/autotools-multilib.eclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/eclass/autotools-multilib.eclass b/eclass/autotools-multilib.eclass
index 024884d..b4af121 100644
--- a/eclass/autotools-multilib.eclass
+++ b/eclass/autotools-multilib.eclass
@@ -19,8 +19,9 @@
# enabled. Thus, it is impossible to use AUTOTOOLS_IN_SOURCE_BUILD with
# it.
+# EAPI=5 is required for meaningful MULTILIB_USEDEP.
case ${EAPI:-0} in
- 2|3|4) ;;
+ 5) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
--
1.8.1.1
Re: [gentoo-dev] USE flags dri, cups, pppd
On Mon, Jan 21, 2013 at 2:46 AM, Hans de Graaff wrote: > Setting the option in the profile tells me: "Here's this option you can > play with, and we think you might need it. Or not." > > Setting the option in the ebuild tells me: "You know, we are nice and > give you this option, but really you should keep this turned on. > Really." I'm not sure that either really has those connotations. They're both recommended defaults, and as with any recommended default changing it could vary in impact. I think that package defaults make sense from the standpoint of having flags that really do vary in usage between packages. Profile defaults are good for tweaking the overall characteristics of a system. The profile defaults do seem less and less relevant, because we only have 4 profiles. The kde/gnome/desktop profiles get a lot of care, and the default basically gets touched very little. If somebody really wants to make more minimal profiles that actually mean something, rather than just trying to tweak the default profile I think it would actually make more sense to make new profiles and actually turn them into something useful. Maybe have a hardened-server profile and accompanying stage3s that let you install a hardened server that "just works." Maybe have a Raspberry Pi profile. Things that are very specific, and therefore actually accomplish something. Obviously somebody needs to maintain them if they're going to create them, but at least they'd be useful to SOMEBODY. The problem with things like a "minimal default" profile are that everybody has a different idea of what it should be, and as a result the people who tend to want minimal just end up setting -* and tweaking everything anyway. That means that we're debating stuff and messing with existing systems and not really accomplishing anything of meaning for anybody. For one person minimal means that we replace half the GNU tools with busybox, and for another it just means disabling things like CUPS. I think that rather than tossing individual questions about individual flags to the list if some developers want to have a minimal profile they should form a project and create one. Maybe leave the default profile alone, unless there is some flag change that is just a no-brainer. I think the bottom line is that creating a minimal default profile that is actually useful for something and which accomplishes the goals of those envisioning it is going to be a lot harder than it might seem. Rich
Re: [gentoo-dev] call for testers: udev predictable network interface names
On Thu, Jan 17, 2013 at 9:51 AM, Ian Stakenvicius wrote: > On 16/01/13 09:55 PM, Rich Freeman wrote: >> SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="4-1:1.0", >> KERNEL=="ttyUSB*", SYMLINK="mythser/rca1" >> >> I'm not sure if rules are additive - if these symlinks would show >> up in addition to whatever other ones are created by other >> rules... >> > > I should look this up before making an authoritative response but I > believe that SYMLINK= would mean no, it's not additive. If you > changed that to SYMLINK+= then it would be additive. That worked. Looks like /dev/serial/by-path would accomplish what I ended up doing. The by-id directory only lists one of my two serial devices. I suspect this is because the devices are completely identical, aside from being plugged into two different ports. Rich
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Sun, 20 Jan 2013 23:33:39 +0100
Michał Górny wrote:
[...]
> > Do you plan to keep precise depends for packages?
> > like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32.
>
> Yes. ${MULTILIB_USEDEP} is for that (it currently evaluates
> to 'multilib?').
In that very precise case (gcc/glibc) I'd say no: it's probably saner
to leave the toolchain as it is, ie, able to build all supported abis.
It probably means an end to implicit system deps for the rest of the
system set though.
[...]
> > like on ABI=amd64 media-libs/glu[ABI=x32] could not be used by
> > any of ABI=amd64 users.
> >
> > In order to track such depends precisely you would need to add
> > ABI flags to each revdep recursively. It's quite invasive. Is it
> > worth the effort?
>
> A good point. I'd say that the default impl should be built then.
> But... how about making it a USE flag with use.force logic? That way,
> it would be explicitly visible, and if someone really wanted to
> disable it, he would be able to do it on his own responsibility.
+1
[...]
> > Looks like insane amount of metadata growth for each
> > plagued package.
>
> I don't think metadata is really important here. I believe that
> the amount of additional metadata introduced by the packages affected
> by multilib is not really one worth worrying.
>
+1 too
OTOH, if you don't have this metadata you cannot really distinguish
between packages needing multilib and those that do not care (I
wouldn't want to run texlive-latexextra src_* phases twice or three
times because I want multilib).
Alexis.
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Sun, 20 Jan 2013 20:11:31 +0100 Michał Górny wrote: > Hello, > > There is a fair interest in multilib and while still early, it would > be a good moment to decide on how USE flags to use for it. > > The current attempts are mostly using USE=multilib which is not really > expressive and poor. What I would go for is a clear variable > specifying which targets package is built for. > > > This raises the following questions: > > 1) do we want the default ABI to be switchable? I'd say no but I do not see any real problem with it. > 2) do we want irrelevant ABIs to be visible to emerge users? > > By 2) I mean: do we want the users to see stuff like: > > MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) > (-ppc64_abi2) (-ppc64_abi3) ..." > > or just the relevant part. just the relevant part, you'd probably need PM support here but showing it all doesn't hurt, it's just less convenient. > > To be honest, I don't know if there's other way to hide USE flags than > using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split > the flags per-arch, i.e. have: > > MULTILIB_AMD64="abi1 abi2 abi3" > MULTILIB_PPC64="abi1 abi2 abi3" > > with appropriate USE_EXPAND_HIDDEN set by profiles. I don't like that at all. I'd go for ABI= the union of all the MULTILIB_ABIS variables (if there is no name collision) we certainly want skype to depend on libitneeds[abi_x86], not 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )' Alexis.
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-01-20 23h59 UTC
On Mon, Jan 21, 2013 at 1:25 AM, Robin H. Johnson wrote: > The attached list notes all of the packages that were added or removed > from the tree, for the week ending 2013-01-20 23h59 UTC. How about sending those mails to gentoo-dev-announce only? Theo
Re: [gentoo-dev] Chromium system ffmpeg
On Sun, 20 Jan 2013 10:08:27 -0800 ""Paweł Hajdan, Jr."" wrote: > On 1/20/13 1:46 AM, Luca Barbato wrote: > > On 19/01/13 20:10, "Paweł Hajdan, Jr." wrote: > >> have a way to more simply exclude code that requires CODEC_ID_OPUS. > > > > Exclude in chrome or in libavcodec? > > > > The latter is a matter of adding --disable-decoder=opus and/or not > > --enable-libopus in the configure. > > Exclude in chrome, in case old ffmpeg/libav does not support it. yes in this case you need some #if VERSION < foo conditions (git blame & cie are your friends to obtain the version in which it appeared). it becomes messy when you realize minor/micro versions within ffmpeg and libav are not at all the same. vlc has some macro for this: http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/avcodec.h;h=8c8dd20ed3400527cab84265f4442bf06eb06f8d;hb=HEAD /* LIBAVCODEC_VERSION_CHECK checks for the right version of libav and FFmpeg 282 * a is the major version * b and c the minor and micro versions of libav * d and e the minor and micro versions of FFmpeg */ #define LIBAVCODEC_VERSION_CHECK( a, b, c, d, e ) \ (LIBAVCODEC_VERSION_MICRO < 100 && LIBAVCODEC_VERSION_INT >= AV_VERSION_INT( a, b, c ) ) || \ (LIBAVCODEC_VERSION_MICRO >= 100 && LIBAVCODEC_VERSION_INT >= AV_VERSION_INT( a, d, e ) ) _MICRO is >= 100 in ffmpeg so that you can distinguish between the two. Another option could be to check for the enum member at configure time. Alexis.
Re: [gentoo-dev] USE flag dri (reverted)
Am Sonntag, 20. Januar 2013, 18:16:32 schrieb Chí-Thanh Christopher Nguyễn: > Mike Frysinger schrieb: > > On Sunday 20 January 2013 10:54:55 Chí-Thanh Christopher Nguyễn wrote: > >> Yes, I mentioned this in another post already. We can use EAPI=1 IUSE > >> defaults instead. But this will not change any systems so I fail to > >> see the point behind this. This will only move clutter from profiles > >> into ebuilds. > > > > where it should have been in the first place. if it's a package-specific > > issue, then it belongs in the package. > > It is a common issue shared among all packages and package versions that > have this flag. So I think the profile is the correct place. > Following the discussion here, I've come to the conclusion that I made a bad call w/r to removing dri from default/linux after learning more about its effect. Summarizing, USE=dri * is the recommended default anytime * is needed in particular also in the embedded case (about as far from desktop as possible) Discussion here and on #g-dev presented two options, either * enabling dri in all relevant ebuilds as default-on, or * re-adding it to the profile. Chí-Thanh, who is the maintainer of the relevant packages, prefers a central setting. We've talked about this once more on IRC, I've reverted the profile commit and USE=dri is again enabled in default/linux/make.defaults. [We can still migrate to IUSE="+dri" in the ebuilds over time but that is a separate issue.] I am sorry for any inconvenience this has caused. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Fwd: [gentoo-commits] gentoo-x86 commit in mail-client/claws-mail-rssyl: ChangeLog claws-mail-rssyl-0.34.ebuild
Hello Christian, it looks like you accidentally choose the latest stable version 0.34 for removal instead of the older 0.33 [1]. I assume this happened in error and I revert the commit. (The 0.33 version downgrade does not build) This is reported as [2], too. Bye, Michael [1] https://bugs.gentoo.org/show_bug.cgi?id=448968 [2] https://bugs.gentoo.org/show_bug.cgi?id=453298 Original Message Subject: [gentoo-commits] gentoo-x86 commit in mail-client/claws-mail-rssyl: ChangeLog claws-mail-rssyl-0.34.ebuild Date: Sun, 20 Jan 2013 21:56:35 + (UTC) From: Christian Faulhammer (fauli) Reply-To: gentoo-dev@lists.gentoo.org, fa...@gentoo.org To: gentoo-comm...@lists.gentoo.org fauli 13/01/20 21:56:35 Modified: ChangeLog Removed: claws-mail-rssyl-0.34.ebuild Log: clean up (Portage version: 2.1.11.31/cvs/Linux i686, signed Manifest commit with key 2B859DE3) Revision ChangesPath 1.120mail-client/claws-mail-rssyl/ChangeLog file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/mail-client/claws-mail-rssyl/ChangeLog?rev=1.120&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/mail-client/claws-mail-rssyl/ChangeLog?rev=1.120&content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/mail-client/claws-mail-rssyl/ChangeLog?r1=1.119&r2=1.120 Index: ChangeLog === RCS file: /var/cvsroot/gentoo-x86/mail-client/claws-mail-rssyl/ChangeLog,v retrieving revision 1.119 retrieving revision 1.120 diff -u -r1.119 -r1.120 --- ChangeLog 20 Jan 2013 10:24:05 - 1.119 +++ ChangeLog 20 Jan 2013 21:56:35 - 1.120 @@ -1,6 +1,10 @@ # ChangeLog for mail-client/claws-mail-rssyl # Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2 -# $Header: /var/cvsroot/gentoo-x86/mail-client/claws-mail-rssyl/ChangeLog,v 1.119 2013/01/20 10:24:05 ago Exp $ +# $Header: /var/cvsroot/gentoo-x86/mail-client/claws-mail-rssyl/ChangeLog,v 1.120 2013/01/20 21:56:35 fauli Exp $ + + 20 Jan 2013; Christian Faulhammer + -claws-mail-rssyl-0.34.ebuild: + clean up 20 Jan 2013; Agostino Sarubbo claws-mail-rssyl-0.34.ebuild: Stable for alpha, wrt bug #448968 -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Getting the general dev opinion ("Meinungsbild") on some feature
Hi Andreas, Le dimanche 20 janvier 2013 à 16:20 +0100, Andreas K. Huettel a écrit : > So, a thread like "Should we enable useflag Z by default" would then include > "Please discuss here, vote on ..." with a link to the count page (updated via > cron every 1h). On login to ..., a message similar to the "open elections > message" could be displayed. > > Obviously the implementation does not exist, but this is conceptually simple > enough so it could be implemented within reasonable time. We (devs) participate in Gentoo in various ways and for very different reasons. And those ways and reasons may change over time. I, for one, no longer consider myself sufficiently informed about new PM/EAPI features, various profile changes, etc. Though I'll gladly update the few packages I maintain to whatever standard is expected, I'll leave the discussion(/trolling?) to other better-informed folks as I often have nothing of value to contribute in those areas. In fact, I believe this to be exactly the Council's role and we already have the necessary tools for that, including a yearly election. Council members already represent Gentoo devs when tougher decisions need to be made. So while I commend you for trying to collect everyone's opinion, I believe it should *not* be necessary for you (or anyone else) to organize elections or polls in order to implement new features or changes to Gentoo. Cheers, Rémi
