Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Wed, Apr 10, 2013 at 8:15 AM, Mike Frysinger vap...@gentoo.org wrote: i plan on updating the latest glibc to add USE=suid. in pkg_preinst and ROOT==/, the ebuild will read /proc/mounts for a devpts line with gid=5. if it doesn't find one, i'll have it call `die`. What about chroot builds? I have /dev/pts bind-mounted from the (old) host filesystem into chroot, yet pt_chown has its suid bit happily disabled in deployed build since long time ago. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
[gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On Mon, Apr 08, 2013 at 12:30:08AM +1000, Michael Palimaka wrote: On 7/04/2013 16:53, Kacper Kowalik wrote: On 06.04.2013 20:08, Michał Górny wrote: As far as I'm aware, we don't really have much of a patch maintenance policy in Gentoo. There a few loose rules like «don't put awfully big files into FILESDIR» or the common sense «use unified diff», but no complete and clear policy. As soon as I saw this I thought of the same clean-patches doc as Kacper. 1-4 are basically about making patches work better in the automated ebuild framework, and I heartily agree (when it does not entail modifying 'upstream' or rather imported patches; shared with other distros in particular.) Your other post made a lot of sense (with the glob restriction.) 5. The patch name shall shortly summarize the changes done by it. 6. Patch files shall start with a brief description of what the patch does. Developers are encouraged to use git-style tags like 'Fixes:' to point to the relevant bug URIs. 7. Patch combining is discouraged. Developers shall prefer multiple patches following either the upstream commits or a logical commit sequence (if changes are not committed upstream). The above-listed policy will apply to the patches kept in the gx86 tree (in FILESDIRs) and patch archives created by Gentoo developers. They will not apply to the patch archives created upstream. Patches in FILESDIR are often those imported from and shared with other distros. there's at least one guideline written by the Ancient Ones that I know [1] It roughly follows the ideas that you've described. I think it'd be enough if people read it and used as a suggestion not a strict ruling. Imposing things like lexical order or git-style heading is a bit too much for me Do we really need rules for everything? Cheers, Kacper [1] http://dev.gentoo.org/~vapier/clean-patches We already have policy regarding patches[1], this just expands and formalises it a bit more. Trouble is it's got a lot less meat than vapier's doc. If you're expanding and formalising it's a good opportunity to add more relevant info, as well as the formalities that will make EAPI-6 patching cleaner. vapier's clean-patches document is an informative read, but I don't think devspace is a good method of disseminating of information that may not necessarily reflect the reality of the project. So why not just merge vapiers work into the devmanual, along with updated info to deal with newer git style tags? ATM the devmanual is woefully thin in comparison; it should be more prescriptive, along with the reasons, just like vapier wrote it the first time around (I actually link people to vapier's doc on IRC, but I'd never link them to the current devmanual as it has little tutorial content for a beginner, just some basic info mostly Gentoo-specific.) Sure, you can make the language a bit nicer, but really before you push policy there needs to be best practice info in place first (and that usually means content with wider development context, like the clean-patches doc.) Regards, steveL. -- #friendly-coders -- Where everybody knows your nick ;-)
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Friday 12 April 2013 02:50:20 Maxim Kammerer wrote: On Wed, Apr 10, 2013 at 8:15 AM, Mike Frysinger vap...@gentoo.org wrote: i plan on updating the latest glibc to add USE=suid. in pkg_preinst and ROOT==/, the ebuild will read /proc/mounts for a devpts line with gid=5. if it doesn't find one, i'll have it call `die`. What about chroot builds? I have /dev/pts bind-mounted from the (old) host filesystem into chroot, yet pt_chown has its suid bit happily disabled in deployed build since long time ago. i don't know what you mean. if the ebuild detects devpts being mounted and the mount is incorrect, it will die. if you don't have devpts mounted at all, then it assumes you know what you're doing. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Binary package dependencies for sub-slot-less EAPIs
Over on #gentoo-releng and in gentoo-catalyst@ we've been running into binary package dependency problems [1]. Before EAPI-5 and sub-slots, the version of dependency packages is not recorded in the binary package metadata (the Packages file). For example, a binary package for GCC built against mpc-0.8.2 will link to libmpc.so.2. If you install that package on a system that only has mpc-1.0.1 (and thus, libmpc.so.3), your cc1 will crash because libmpc.so.2 is missing. What we need is a way to track ABI sub-slot dependencies for all packages, even those that currently use EAPI-0. My initial idea was to store a fake EAPI-5-style sub-slot information in the binary package metadata, but further discussion on #gentoo-portage pointed me at the toolchain folks: 10:33 zmedico dol-sen: wouldn't it be easier to just migrate those pkgs to EAPI 5 + slot-operator? 10:34 * zmedico doesn't feel like doing extra work when EAPI 5 already does everything we need … 11:16 Tommy[D]_ Zero_Chaos: my suggestion: ask the toolchain guys about their preferred way (like updating existing eclass, using a new eclass, moving code into ebuilds) and when you got that, do the needed work, including an EAPI-5 version of toolchain ebuilds I looked in bugzilla for requests to update the toolchain EAPIs, but didn't find anything [2]. I don't want to bother people if the issue had already been hashed out, and searching on Gmane turned up the “[RFC] Drop EAPI=0 requirement for system packages.” thread from last October [3]. This early comment from Rich seemed to summarize the anti-EAPI-bump camp: On Wed, Oct 17, 2012 at 03:00:12PM -0400, Rich Freeman wrote: A policy that says all new ebuilds shall use EAPI foo might result in fewer new ebuilds. Sure, they'll have new and shiny fooness, but arguably I'd rather have more packages supported on older EAPIs then fewer packages supported on newer ones. Again, as I stated before, things that actually benefit the end users like slot dependencies are fine to mandate when it makes sense to do so. In other words, “Why force folks to do this if there is no benefit?”. This is understandable, but I think the broken binary packages [1] are enough of a visible benefit. The thread suggested filing bugs for bumping effected packages, but for this issue “effected packages” is “anything you might want to distribute as a binary package that uses something without EAPI-5 sub-slots” [4]. I'm happy to start filing bugs, but that doesn't strike me as the most productive way forward. If anyone can think of other solutions besides tweaking Portage or bumping a bunch of package EAPIs, I'd be happy to hear them ;). Otherwise I'd be happy to hear suggestions about moving forward on at least one of those fronts. Since I seem to be the most bothered by this issue, it's only fair that I help with the itch scratching. I just need a roadmap from the folks with commit access so I can start chipping away at whichever solution y'all think looks most appealing ;). Cheers, Trevor [1]: http://thread.gmane.org/gmane.linux.gentoo.catalyst/2137/focus=2237 [2]: https://bugs.gentoo.org/buglist.cgi?short_desc=EAPIresolution=---query_format=advancedbug_status=UNCONFIRMEDbug_status=CONFIRMEDbug_status=IN_PROGRESSbug_status=RESOLVEDbug_status=VERIFIEDshort_desc_type=allwordssubstrcomponent=Core%20systemcomponent=Developmentcomponent=Core%20systemcomponent=Developmentproduct=Gentoo%20Linux [3]: http://thread.gmane.org/gmane.linux.gentoo.devel/80705 [4]: Although on the catalyst side, only @system is really important. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Fri, Apr 12, 2013 at 7:22 PM, Mike Frysinger vap...@gentoo.org wrote: i don't know what you mean. if the ebuild detects devpts being mounted and the mount is incorrect, it will die. if you don't have devpts mounted at all, then it assumes you know what you're doing. What I am saying is that you make no distinction between build environment and deployment environment. Quite a few users build their Gentoo systems in a chroot. In that case, whole /dev, or its portions (including /dev/pts) can be bind-mounts from the host filesystem, and /dev/pts does not need to have the correct permissions. However, you *would* see such a bind-mount as a devpts mount in /proc/mounts. So why not print a warning — what's the point of dying in pkg_preinst? -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Binary package dependencies for sub-slot-less EAPIs
On Fri, Apr 12, 2013 at 12:25 PM, W. Trevor King wk...@tremily.us wrote: In other words, “Why force folks to do this if there is no benefit?”. This is understandable, but I think the broken binary packages [1] are enough of a visible benefit. I certainly agree. As I bump my own packages I'll certainly be looking for opportunities to use slot operator dependencies and will certainly bump to EAPI5 when I find them, and if somebody were to state that EAPI6 was going to make the lives of binary package users much better I'd be all for pushing to get everything onto EAPI6. My only concern was to let the actual benefits be the driver. Rich
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Fri, Apr 12, 2013 at 1:20 PM, Maxim Kammerer m...@dee.su wrote: On Fri, Apr 12, 2013 at 7:22 PM, Mike Frysinger vap...@gentoo.org wrote: i don't know what you mean. if the ebuild detects devpts being mounted and the mount is incorrect, it will die. if you don't have devpts mounted at all, then it assumes you know what you're doing. What I am saying is that you make no distinction between build environment and deployment environment. Quite a few users build their Gentoo systems in a chroot. In that case, whole /dev, or its portions (including /dev/pts) can be bind-mounts from the host filesystem, and /dev/pts does not need to have the correct permissions. However, you *would* see such a bind-mount as a devpts mount in /proc/mounts. So why not print a warning — what's the point of dying in pkg_preinst? Do you have a reason for not having /dev/pts mounted with gid=5 on the system hosting the chroot environment? Calling die is much more likely to save users systems than an ewarn.
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
MF == Mike Frysinger vap...@gentoo.org writes: It will impact everyone who has /dev/pts in fstab(5). MF don't do that. *I* didn't. I don't know /what/ added it, but something did. With noauto, just like the other reported case. It shouldn't matter how rare it is though. A general announcement won't hurt anyone. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Friday 12 April 2013 13:20:11 Maxim Kammerer wrote: On Fri, Apr 12, 2013 at 7:22 PM, Mike Frysinger vap...@gentoo.org wrote: i don't know what you mean. if the ebuild detects devpts being mounted and the mount is incorrect, it will die. if you don't have devpts mounted at all, then it assumes you know what you're doing. What I am saying is that you make no distinction between build environment and deployment environment. Quite a few users build their Gentoo systems in a chroot. In that case, whole /dev, or its portions (including /dev/pts) can be bind-mounts from the host filesystem, and /dev/pts does not need to have the correct permissions. However, you *would* see such a bind-mount as a devpts mount in /proc/mounts. So why not print a warning — what's the point of dying in pkg_preinst? unless you have a good reason for having the host devpts being mounted wrong, i'm not inclined to support this. every major distro that matters that i know of does it this way and has for a long time: Debian, Ubuntu, Fedora, Gentoo. if it encourages people to fix their host distro to also not suck, well that's just a bonus. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: glibc: pt_chown setuid going away by default
On Thursday 11 April 2013 22:19:40 Duncan wrote: Mike Frysinger posted on Thu, 11 Apr 2013 12:49:00 -0400 as excerpted: On Thursday 11 April 2013 11:43:59 James Cloos wrote: MF == Mike Frysinger vap...@gentoo.org writes: MF this should impact very few (if any) MF users, so i don't think a news item makes sense. It will impact everyone who has /dev/pts in fstab(5). don't do that. delete the line. I wonder if I added my devpts fstab entry (if as you say it wasn't an automated add) some time ago, when there was some security related hubbub over it, as significantly, my fstab entry has nosuid, noexec, while the default for it in /etc/init.d/devfs does not. My fstab devpts entry also has noauto, but that's likely simply due to it being an fstab entry... Regardless, that's at least two gentooers with installations dating from the early 00s that have reported having the (GID-less) entry in fstab now, so I strongly suspect it's going to affect more users, at least long- time users, than you thought. It may in fact affect the majority of users from that era... anyone who hasn't manually removed that entry from fstab over the years. You mention it wasn't in the old baselayout/openrc tarballs. What about the early stages? Perhaps that's where it came from? Anyone with 2004.x vintage stage tarballs around to check? stages get their files from baselayout/openrc. they don't generate them themselves. Robin found even older baselayout releases for me. baselayout-1.8.6.12 (released Nov 2011) and newer don't contain any mention of devpts. i don't know about 2004 releases, but i have stage tarballs i built in Oct 2005 using gcc-2.95 and they're exactly what i expect -- they match the baselayout install. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] rfc: toolchain-funcs: target-has-split-usr API?
What do people think of something like this? Obviously the equivalent
patch to prefix would need to include a test for
PREFIX_DISABLE_GEN_USR_LDSCRIPT:
Author: Gregory M. Turner gmturner...@ameritech.net
Date: Fri Apr 12 11:13:21 2013 -0700
eclass/toolchain-funcs: Add target-has-split-usr API
Move the platform-filtering code from gen_usr_ldscript into its own
API so that ebuilds can reliably test whether gen_usr_ldscript does
something or not in the currently applicable environment. See
in-source comments for more details.
Signed-off-by: Gregory M. Turner gmturner...@ameritech.net
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 9b94512..7600aaf 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -604,6 +604,36 @@ gcc-specs-nostrict() {
return $([[ ${directive/\{!fstrict-overflow:} != ${directive} ]])
}
+# @FUNCTION: target-has-split-usr
+# @DESCRIPTION:
+# This function returns 0 (true) if, for the currently
+# targeted platform, portage is presuming that a split-usr
+# configuration must be maintained. When target-has-split-usr
+# returns a nonzero (false) value, gen_usr_ldscript is a noop. This
+# may be handy in cases where an ebuild needs to decide, i.e., whether
+# it makes sense to move certain files from /usr/bin to /bin
+# in an ebuild. In the future, the assumption that critical
+# stuff ends up in /bin and /$(libdir) whereas noncritical
+# stuff ends up in /usr/bin and /usr/$(libdir) may be removed
+# from portage entirely, or relegated to a legacy-support role.
+# As of April 2013, discussion was ongoing in the Gentoo developer
+# community as to what exactly to change and how (see bug #417451).
+# By predicating ebuild code on target-has-split-usr, which exists solely
+# to maintain a split-usr layout, ebuilds can future-proof themselves
+# against changes to the precise criteria that determine whether or not
+# split-usr is in effect for a given target and configuration.
+target-has-split-usr() {
+tc-is-static-only return 1
+
+case ${CTARGET:-${CHOST}} in
+*-darwin*) return 0;;
+*linux*|*-freebsd*|*-openbsd*|*-netbsd*)
+use prefix return 1
+return 0
+;;
+*) return 1 ;;
+esac
+}
# @FUNCTION: gen_usr_ldscript
# @USAGE: [-a] list of libs to create linker scripts for
@@ -620,19 +650,10 @@ gcc-specs-nostrict() {
# the library (libfoo.so), as ldconfig should usually update it
# correctly to point to the latest version of the library present.
gen_usr_ldscript() {
+target-has-split-usr || return 0
local lib libdir=$(get_libdir) output_format= auto=false
suffix=$(get_libname)
[[ -z ${ED+set} ]] local ED=${D%/}${EPREFIX}/
-tc-is-static-only return
-
-# Eventually we'd like to get rid of this func completely #417451
-case ${CTARGET:-${CHOST}} in
-*-darwin*) ;;
-*linux*|*-freebsd*|*-openbsd*|*-netbsd*)
-use prefix return 0 ;;
-*) return 0 ;;
-esac
-
# Just make sure it exists
dodir /usr/${libdir}
--
gmt
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Friday 12 April 2013 15:41:55 James Cloos wrote: MF == Mike Frysinger vap...@gentoo.org writes: It will impact everyone who has /dev/pts in fstab(5). MF don't do that. *I* didn't. that you remember. i think it's more likely you copy pasted some line a long time ago than baselayout modified it for you. two people who have installs that are a decade old doesn't incline me to write a news entry. not when the ebuild itself contains a sanity check that triggers exactly as needed and includes an error message explaining things. we aren't talking about an upgrade here that will silently accidentally break your box on next boot (like udev friends), or will break running programs (like SONAME bumps, although that's a much less of a problem now that portage handles things automatically). -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?
Hello everyone Attached you will find the various changes I plan to apply to kernel-2.eclass after a week if there are no objections, feel free to take a look at them. A summary of the changes: - Added a warning after the variables that modifying other variables in the eclass is not supported, there is a chance that we will not fix resulting bugs. Fixes bug #421721. - Make use of readme.gentoo.eclass to make the user aware of the Gentoo Linux Kernel Upgrade Guide only the first time he emerges the package. Fixes bug #457598. - Clarify the default DESCRIPTION and make it not use versions, a directory with ebuilds that inherit this eclass may contain multiple versions and we also don't want to give the impression that a new directory needs to made if that's not the case. Fixes bug #445110. - Clarified which patch depths are used in the normal output and error output when applying patches. Fixes bug #436402. - Made sure .tmp_gas_check is created inside the temp folder, it accidentally created temp.tmp_gas_check instead. Fixes bug #336732. - Make UNIPATCH_DOCS work again, install _README document when using genpatches. Fixes bug #301478. Since these are quite a few changes, it doesn't hurt posting them here. I'll also summarize the past commits I made, for those who missed them: - Kernel sources and (gen)patches now use xz instead of bz2. Fixes bug #421721. - Added sys-devel/bc as a RDEPEND to kernel-2.eclass. Fixes bug #461848. - Use UID 0 instead of root to assign permissions to super user. Fixes bug #315807. The commit diffs can be obtained at http://sources.gentoo.org/ There is a guideline that reporting small changes to barely used eclasses here is not required, but that made some out-of-tree users unhappy; sorry for that, I'll try to get every eclass change reviewed in the future to avoid these issues. Small changes, like the above, I will try to combine together to avoid unnecessary mail and commit spam. That being said, since 3.8.7 has landed upstream we would like to hear about any issues we don't know about yet that would block stabilization; if we can, I plan to start stabilization in less than two weeks. Unless there are valid reasons for this to be done earlier/later. I'll add 3.2.43 and 3.8.7 to the tree in a moment, as it is late 3.0.73 and 3.4.40 will be for tomorrow... Have a nice day. :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D kernel-2.eclass.patches Description: Binary data signature.asc Description: PGP signature
Pass ${@} in phase functions Re: [gentoo-dev] [PATCH] Introduce cmake-multilib wrapper for cmake-utils.
Hi,
I'm not sure if it's a sane way to push make -j1 via
src_compile() {
cmake-multilib_src_compile -j1
}
but I detected a lack of functionality in the current
cmake-multilib.eclass. Both cmake-utils.eclass and multilib-build.eclass
have it, so it might be sound to continue with this behavior.
Comments, pls.
Michael
Index: cmake-multilib.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/cmake-multilib.eclass,v
retrieving revision 1.1
diff -u -B -r1.1 cmake-multilib.eclass
--- cmake-multilib.eclass 10 Feb 2013 11:44:55 - 1.1
+++ cmake-multilib.eclass 13 Apr 2013 00:58:17 -
@@ -33,24 +33,24 @@
EXPORT_FUNCTIONS src_configure src_compile src_test src_install
cmake-multilib_src_configure() {
- multilib_parallel_foreach_abi cmake-utils_src_configure
+ multilib_parallel_foreach_abi cmake-utils_src_configure ${@}
}
cmake-multilib_src_compile() {
- multilib_foreach_abi cmake-utils_src_compile
+ multilib_foreach_abi cmake-utils_src_compile ${@}
}
cmake-multilib_src_test() {
- multilib_foreach_abi cmake-utils_src_test
+ multilib_foreach_abi cmake-utils_src_test ${@}
}
cmake-multilib_src_install() {
cmake-multilib_secure_install() {
- cmake-utils_src_install
+ cmake-utils_src_install ${@}
# Make sure all headers are the same for each ABI.
multilib_check_headers
}
- multilib_foreach_abi cmake-multilib_secure_install
+ multilib_foreach_abi cmake-multilib_secure_install ${@}
}
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber x...@gentoo.org
