Re: [gentoo-dev] eclass for handling of file-based capabilities
On Sat, Mar 05, 2011 at 02:24:22PM +0100, Constanze Hausner wrote:
fcaps() {
debug-print-function ${FUNCNAME} $@
debug-print ${FUNCNAME}: Trying to set capabilities for ${4}
local uid_gid=$1
local perms=$2
export fallbackFileMode=$perms
local capset=$3
local path=$4
That export of fallbackFileMode looks pointless... clarify please.
Also, your arg count checking here means it's going to throw some
weird ass errors if people invoke it incorrectly. You likely want a
[ $# -ne 4 ] die wrong arg count
thrown in there..
if [ $# -eq 5 ]; then
local set_mode=$5
else
debug-print ${FUNCNAME}: no set-mode provided, setting it to
ep
#if there is no set_mode provided, it is set to true
local set_mode=1
fi
#set owner/group
debug-print ${FUNCNAME}: setting owner and group to ${uid_gid}
chown $uid_gid $path
if [ $? -ne 0 ]; then
eerror chown $uid_gid $path failed.
return 2
fi
#set file-mode including suid
debug-print ${FUNCNAME}: setting file-mode ${perms}, including suid
chmod $perms $path
Arbitrary/user-controlled path's always need to be quoted...
if [ $? -ne 0 ]; then
eerror chmod $perms $path failed.
return 3
fi
#if filecaps is not enabled all is done
use !filecaps return 0
#if libcap is not installed caps cannot be set
if [ ! -f /sbin/setcap ]; then
debug-print ${FUNCNAME}: libcap not installed, could not set
caps
return 4
fi
#Check for set mode
if [ $set_mode -eq 1 ]; then
debug-print ${FUNCNAME}: set-mode = ep
local sets==ep
else
debug-print ${FUNCNAME}: set-mode = ei
local sets==ei
fi
Shift this into the initial arg processing; eliminates the need for
set_mode and is simpler to follow.
#set the capability
debug-print ${FUNCNAME}: setting capabilities
lay off the debug-print's a bit...
setcap $capset$sets $path /dev/null
#check if the capabilitiy got set correctly
debug-print ${FUNCNAME}: checking capabilities
setcap -v $capset$sets $path /dev/null
local res=$?
#if caps could be set, remove suid-bit
if [ $res -eq 0 ]; then
debug-print ${FUNCNAME}: caps were set, removing suid-bit
chmod -s $path
else
debug-print ${FUNCNAME}: caps could not be set
ewarn setcap $capset $path failed.
ewarn Check your kernel and filesystem.
ewarn Fallback file-mode was set.
fi
return $res
}
I'd take a different approach here; this code basically assumes that
the PM knows of it- note the chmod -s. The use flag protection you
tried adding, without some profile hacks, is user modifiable- meaning
users can flip it on even if the PM doesn't support it.
Or consider that the code above is purely doing it's thing during the
install phase, specifically against whatever filesystem is used for
building- while capabilities might be able to be set there, it's
possible the final merge location won't support it. End result of
that is you'll get a setuid stripped binary merged to the
livefs lacking the caps- borkage. Or consider the inverse- the
buildroot can't do capabilities, but the livefs could. You get the
idea.
Instead, write the code so the PM has to export a marker in some
fashion to explicitly state yes, I can do capabilities- I'm
specifically suggestining checking for a callback function exposed to
the env.
If that function isn't there, then the PM can't do it- end of story.
If it is, the PM takes the args and will try to apply the
capabilities at the correct time- stripping setuid/setgid if it
succeeds.
Please go that route; and please do not stick portage into the
function name, something generic we can use for a later EAPI is
better.
Implementing it as I suggested has the nice side affect of not being
limited by PMS also, although it's an approach that still requires
planning for compatibility.
Thanks-
~brian
pgpsKYcI9z358.pgp
Description: PGP signature
[gentoo-dev] Bugzilla - New Default Status Workflow
Hey guys, in bugzilla-4.x they did change the Status Workflow[1]. snip This will convert the status of all bugs using the following system: NEW will become CONFIRMED ASSIGNED will become IN_PROGRESS REOPENED will become CONFIRMED (and the REOPENED status will be removed) CLOSED will become VERIFIED (and the CLOSED status will be removed) This change will be immediate. The history of each bug will also be changed so that it appears that these statuses were always in existence. Emails will not be sent for the change. /snip We're almost done with the preparation of bugzilla-4.x for bugs.gentoo.org. So, do we want the new workflow or do we want to keep the old? [1] http://www.bugzilla.org/releases/4.0/release-notes.html#v40_feat_workflow -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On 03/06/2011 02:22 PM, Christian Ruppert wrote: Hey guys, in bugzilla-4.x they did change the Status Workflow[1]. snip This will convert the status of all bugs using the following system: REOPENED will become CONFIRMED (and the REOPENED status will be removed) We would be loosing information here (at least you would need to go looking at bug history to find it). Would it be possible to have the new workflow + REOPENED? Would other statuses continue to exist like before? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On Sun, Mar 6, 2011 at 5:52 PM, Christian Ruppert id...@gentoo.org wrote: Hey guys, in bugzilla-4.x they did change the Status Workflow[1]. [snip] We're almost done with the preparation of bugzilla-4.x for bugs.gentoo.org. So, do we want the new workflow or do we want to keep the old? I'm not attached to the names we use for the various bug statuses. I would suggest that we follow the path that makes things easiest for future maintenance and upgrades. As for the removal of REOPENED, I guess that information will still be visible via the bug history button? It shouldn't be a problem then. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On Sun, Mar 06, 2011 at 01:22:09PM +0100, Christian Ruppert wrote: Hey guys, in bugzilla-4.x they did change the Status Workflow[1]. snip This will convert the status of all bugs using the following system: NEW will become CONFIRMED This seems mildly insane; sure you didn't mean UNCONFIRMED? ASSIGNED will become IN_PROGRESS REOPENED will become CONFIRMED (and the REOPENED status will be removed) Similarly weird. CLOSED will become VERIFIED (and the CLOSED status will be removed) VERIFIED != CLOSED; CLOSED means this issue should be fixed, VERIFIED means this issue is confirmed fixed by whatever qa/testing in use- specifically beyond the developer's testing. We're almost done with the preparation of bugzilla-4.x for bugs.gentoo.org. So, do we want the new workflow or do we want to keep the old? The new is more orientated towards bugzilla workflow's that have actual secondary validation of a change- developer fixes it, closes it, QA marks it verified, that sort of thing. That doesn't really fit our flow all that much, as such we really shouldn't be taking their defaults without tweaking it a bit. ~brian pgpI33WRme5hR.pgp Description: PGP signature
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On 03/06/2011 01:45 PM, Petteri Räty wrote: On 03/06/2011 02:22 PM, Christian Ruppert wrote: Hey guys, in bugzilla-4.x they did change the Status Workflow[1]. snip This will convert the status of all bugs using the following system: REOPENED will become CONFIRMED (and the REOPENED status will be removed) We would be loosing information here (at least you would need to go looking at bug history to find it). Would it be possible to have the new workflow + REOPENED? Would other statuses continue to exist like before? Regards, Petteri Yes. Yes. -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Bugzilla - New Default Status Workflow
Hi, Christian Ruppert id...@gentoo.org: We're almost done with the preparation of bugzilla-4.x for bugs.gentoo.org. So, do we want the new workflow or do we want to keep the old? New one, reopened is a bit pointless information on first glance. History tells enough. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: gtk 3 preparation work
Hi, Nirbheek Chauhan nirbh...@gentoo.org: Indeed, it is quite large, coming at ~1100 ebuilds. Hence, I've attached it instead of pasting it in-line. Unsurprisingly, some are gnome packages, and even a few maintained by me :p Claws Mail and plugins are fixed. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] gtk 3 preparation work
On 05/03/11 19:52, Nirbheek Chauhan wrote: On Tue, Mar 1, 2011 at 4:04 AM, Nirbheek Chauhan nirbh...@gentoo.org wrote: On Mon, Feb 28, 2011 at 8:28 AM, Donnie Berkholz dberkh...@gentoo.org wrote: On 11:13 Sun 27 Feb , Gilles Dartiguelongue wrote: a quick mail to announce that the gnome team, in order to prepare for gnome 3, started slotting a lot of gnome team managed packages. If you find yourself using such a package, please update your ebuilds to use slot notations or other EAPI compliant notation resulting in the same effect. This email would be much more useful if it included a list of affected packages, sorted by maintainer and/or herd. As requested, here is a (probably) complete list of packages which depend on x11-libs/gtk+ without a slot. The list was generated using the tinderbox rindex, so it may be slightly out of date. I've started maintaining an irregularly updated list for gtk+ (and a few other libraries): http://dev.gentoo.org/~nirbheek/gnome/3.0/slotting/ The script I use to generate these lists is: http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=blob;f=scripts/slot_rindex.py;hb=HEAD If you look at the lists in that directory, you'll be able to guess that there are other libraries which need the same treatment. The list of these libraries is, however, incomplete right now. We'll be sending a mail about that later, but folks can fix deps to use slots right now if they wish. Thanks to everyone who has fixed deps of their (and other folks') packages! all sci is fixed. Why do you have a rdeps list for vte. it is in slot 0. Will there be a different slot in future? justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] gtk 3 preparation work
On Sun, Mar 6, 2011 at 6:54 PM, justin j...@gentoo.org wrote: On 05/03/11 19:52, Nirbheek Chauhan wrote: I've started maintaining an irregularly updated list for gtk+ (and a few other libraries): http://dev.gentoo.org/~nirbheek/gnome/3.0/slotting/ all sci is fixed. Why do you have a rdeps list for vte. it is in slot 0. Will there be a different slot in future? Yeah, there's a new slot for GTK+-3 (currently 2.90, but that will probably change before the final release). The current vte won't change slot, however. We decided that slotting should be done on the basis of the pkg-config file name, and vte:0's pkgconfig file (and include dir) are at '0'. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On Sun, 6 Mar 2011, Christian Ruppert wrote: This will convert the status of all bugs using the following system: NEW will become CONFIRMED Weird. How can a newly added bug be CONFIRMED, unless someone has taken some action to confirm it? This change will be immediate. The history of each bug will also be changed so that it appears that these statuses were always in existence. So all bugs currently marked as NEW or REOPENED will change their status to CONFIRMED? That doesn't look right to me. Would that status change be visible in the bug's history? So, do we want the new workflow or do we want to keep the old? If the new workflow implies such status changes on existing bugs, then keep the old one please. Ulrich
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On Sun, Mar 6, 2011 at 7:09 PM, Ulrich Mueller u...@gentoo.org wrote: On Sun, 6 Mar 2011, Christian Ruppert wrote: This will convert the status of all bugs using the following system: NEW will become CONFIRMED Weird. How can a newly added bug be CONFIRMED, unless someone has taken some action to confirm it? This change will be immediate. The history of each bug will also be changed so that it appears that these statuses were always in existence. So all bugs currently marked as NEW or REOPENED will change their status to CONFIRMED? That doesn't look right to me. Would that status change be visible in the bug's history? So, do we want the new workflow or do we want to keep the old? If the new workflow implies such status changes on existing bugs, then keep the old one please. The link to the docs which idl0r gave says that it's optional to convert existing status changes. They gave a perl script to do the conversion. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Make sound a global USE flag?
On Wed, 23 Feb 2011, Ulrich Mueller wrote: On Tue, 22 Feb 2011, Rich Freeman wrote: Do we really need two different use flags for code-based sound support vs file-based sound inclusion? Maybe it's similar enough. So, unify both audio and sounds with the global sound flag? Bug 357661 now. Ulrich
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On 3/6/11 1:22 PM, Christian Ruppert wrote: We're almost done with the preparation of bugzilla-4.x for bugs.gentoo.org. So, do we want the new workflow or do we want to keep the old? I like the new workflow more, mostly because of simplicity. This is also closer to what code.google.com uses, and my experience with it was very positive. Before we start arguing for and against various details, let's ask one simple question - are we actually using all those CLOSED and VERIFIED statuses, and what does it change that a bug is REOPENED vs. NEW. Now one of the issues I can indeed understand is the CONFIRMED status vs. UNCONFIRMED. Still, I'm not sure whether we use UNCONFIRMED so much. Anyway, it should be possible to add UNCONFIRMED on top of the new workflow, right? Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] bugs.g.o - Bugzilla4 testing
Our bugstest setup is now public and can be found at [1] or [2]. If [1] doesn't work use [2] because the DNS changes I made may take some hours to reach everybody. Some notes: 1. SSL is enabled by default now, so it's forced. Unfortunately the option to force SSL *only* for logged in user is no longer available in Bugzilla-4.x. It has been added in early 3.x AFAIR and later replaced by forcing SSL at all or not. If *anybody* can't use SSL for any reason please yell so that we can decide if we leave it as it is (plain + encrypted) or not. *Bugmails are disabled*. All accounts (The DB is a few weeks old) from bugs.g.o should work on bugstest as well. If you're new, your account doesn't exist already and you're really interested in testing the new Bugzilla then please poke me either by mail or IRC (#gentoo-bugs, #gentoo-infra or #gentoo-dev). There are *no* attachments currently to speed up the conversions. All custom/Gentoo patches will be available *later* in a git repo[3]. So if you'd like to fix something or improve the theme you can contribute patches. Thanks to Alex Legler (a3li) for the Bugzilla theme. Also you need to decide which icon we should use. The current one[4] or this one[5]. The first one also looks good with other themes than the Gentoo theme. I'll try to migrate our current bugzilla-2.x as soon as possible to 4.x as everything should work and as I have more free time than usual right now. It is *possible* that we migrate even tomorrow. I know it's a bit fast but ... That should be all for the moment. [1] https://bugstest.gentoo.org [2] https://bugstest-web2.gentoo.org [3] http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-bugzilla.git;a=summary [4] https://bugstest-web2.gentoo.org/extensions/Gentoo/web/gentoo_org.png [5] https://bugstest-web2.gentoo.org/extensions/Gentoo/web/gentoo_org.2.png -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eclass for handling of file-based capabilities
On 17:44 Sat 05 Mar , Ciaran McCreesh wrote: On Sat, 5 Mar 2011 18:41:46 +0100 Constanze Hausner consta...@gentoo.org wrote: You're requiring special package manager behaviour if that flag is set? I'm requiring, that the package manager preserves the xattrs, when stripping the binary and when moving it from the sandbox to the live-fs. Currently we've got wording in PMS forbidding anything from relying upon xattrs being preserved correctly, since that's what Portage did when we wrote it. So if you're looking to change that, you'll need to EAPI control it. Yes, there would be the need for a new EAPI, if the caps should be set from src_install and therefore need to be preserved by the PMS. As long as there is no such garantee one could use the eclass to set the caps from pkg_postinst. I know it's really ugly, but it would be a start. Otherwise we will never be able to use caps. But it's not as simple as just requiring attributes to be preserved in future EAPIs, since: * some xattrs are fs specific * some xattrs (selinux?) can't be copied I said something different than I thought, sorry. I only thought of the caps and not other kinds of xattr, as I only require caps to be preserved. Caps do either work on a fs or they don't and they can be copied. * some filesystems don't support xattrs at all, and the package manager needs to support installing to them, even if the user is building on a filesystem that does support it That's true, additionaly even if the fs is able to support xattr, there are kernel options, which need to be set. I agree with you, that that's a huge problem. We need to have a good fallback mechanism. Zac metioned that we could have three modes for movefile: 1) no caps 2) tolerant mode, which does not fail if caps could not be copied 3) strict mode, which fails if caps can't be copied ferringb metioned some kind of marker with which one can indicate xattr support. While GSoC I was not able to come up with a good fallback mechanism. I'm going to give the new ideas some thought over the week and hopefully come up with something good :). * tar and xattrs is a massive problem, so how do binaries work? tar can be patched to support xattrs. If we want to use caps, we will have to apply those patches too. (iirc Fedora already uses such patches). I think it'd help if you provided a description of how all the above (plus the other issues that I've forgotten about) can be handled. I hope I cleared things up at least a bit :). Cheers, constanze
Re: [gentoo-dev] bugs.g.o - Bugzilla4 testing
On Sun, Mar 6, 2011 at 17:31, Christian Ruppert id...@gentoo.org wrote: Our bugstest setup is now public and can be found at [1] or [2]. If [1] doesn't work use [2] because the DNS changes I made may take some hours to reach everybody. This looks awesome, thanks so much for working on this!! One thing I noticed is that by default, search now also searches content, instead of just the titles. I rather liked the old behavior. Cheers, Dirkjan
Re: [gentoo-dev] bugs.g.o - Bugzilla4 testing
On 03/06/2011 05:37 PM, Dirkjan Ochtman wrote: On Sun, Mar 6, 2011 at 17:31, Christian Ruppert id...@gentoo.org wrote: Our bugstest setup is now public and can be found at [1] or [2]. If [1] doesn't work use [2] because the DNS changes I made may take some hours to reach everybody. This looks awesome, thanks so much for working on this!! One thing I noticed is that by default, search now also searches content, instead of just the titles. I rather liked the old behavior. Cheers, Dirkjan Do you mean the little search box in the toolbar or Simple/Advanced search? -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eclass for handling of file-based capabilities
On 03:01 Sun 06 Mar , Brian Harring wrote: [snip] Thanks for your feedback, your remarks were correct :). I updated the eclass appropriately. I'd take a different approach here; this code basically assumes that the PM knows of it- note the chmod -s. The use flag protection you tried adding, without some profile hacks, is user modifiable- meaning users can flip it on even if the PM doesn't support it. Or consider that the code above is purely doing it's thing during the install phase, specifically against whatever filesystem is used for building- while capabilities might be able to be set there, it's possible the final merge location won't support it. End result of that is you'll get a setuid stripped binary merged to the livefs lacking the caps- borkage. Or consider the inverse- the buildroot can't do capabilities, but the livefs could. You get the idea. Instead, write the code so the PM has to export a marker in some fashion to explicitly state yes, I can do capabilities- I'm specifically suggestining checking for a callback function exposed to the env. If that function isn't there, then the PM can't do it- end of story. If it is, the PM takes the args and will try to apply the capabilities at the correct time- stripping setuid/setgid if it succeeds. Please go that route; and please do not stick portage into the function name, something generic we can use for a later EAPI is better. Implementing it as I suggested has the nice side affect of not being limited by PMS also, although it's an approach that still requires planning for compatibility. I'm currently in search of a good fallback mechanism respectivly a good mechanism to deal with cap-setting in src_install. As I already said in my mail to ciaran, I'm going to give the new ideas some thought :). Cheers, constanze
Re: [gentoo-dev] bugs.g.o - Bugzilla4 testing
On Sun, Mar 6, 2011 at 17:44, Christian Ruppert id...@gentoo.org wrote: Do you mean the little search box in the toolbar or Simple/Advanced search? Both the search box in the toolbar and the search thing on the front page (with the Quick Search button). Cheers, Dirkjan
Re: [gentoo-dev] bugs.g.o - Bugzilla4 testing
On Sun, Mar 06, 2011 at 05:31:43PM +0100, Christian Ruppert wrote: Our bugstest setup is now public and can be found at [1] or [2]. If [1] doesn't work use [2] because the DNS changes I made may take some hours to reach everybody. Nice work :) Thanks for taking care of this. Some notes: 1. SSL is enabled by default now, so it's forced. Unfortunately the option to force SSL *only* for logged in user is no longer available in Bugzilla-4.x. It has been added in early 3.x AFAIR and later replaced by forcing SSL at all or not. If *anybody* can't use SSL for any reason please yell so that we can decide if we leave it as it is (plain + encrypted) or not. *Bugmails are disabled*. All accounts (The DB is a few weeks old) from bugs.g.o should work on bugstest as well. If you're new, your account doesn't exist already and you're really interested in testing the new Bugzilla then please poke me either by mail or IRC (#gentoo-bugs, #gentoo-infra or #gentoo-dev). There are *no* attachments currently to speed up the conversions. Can we have support for multiple attachments in a single upload? All custom/Gentoo patches will be available *later* in a git repo[3]. So if you'd like to fix something or improve the theme you can contribute patches. Great, I'd like to tweak the CSS a bit. Thanks to Alex Legler (a3li) for the Bugzilla theme. Also you need to decide which icon we should use. The current one[4] or this one[5]. The first one also looks good with other themes than the Gentoo theme. I like the second one a bit more, but both are fine. I've made a slightly better version of the one with the white background [0]. I'll try to migrate our current bugzilla-2.x as soon as possible to 4.x as everything should work and as I have more free time than usual right now. It is *possible* that we migrate even tomorrow. I know it's a bit fast but ... That should be all for the moment. Keep up the good work :) [0] http://www.linuxized.com/files/gentoo_org.png -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgpCl2VoUKiyV.pgp Description: PGP signature
Re: [gentoo-dev] bash-4.2 going into ~arch
On Mon, Feb 28, 2011 at 7:46 PM, Mike Frysinger wrote: ive just added bash-4.2_p5, and will ~arch that this week at some point bash-4.2_p7 is now in the tree as ~arch. BE AFRAID. -mike
[gentoo-dev] Bugzilla 4 migration
Dear community, our Bugzilla (bugs.gentoo.org) will be unavailable for the next hours. We're going to migrate our old Bugzilla to Bugzilla-4. We expect our update to finish within the next hours. Some notes: SSL is enabled by default now, so it's forced. Unfortunately the option to force SSL *only* for logged in user is no longer available in Bugzilla-4.x. It has been added in early 3.x AFAIR and later replaced by forcing SSL at all or not. If *anybody* can't use SSL for any reason please yell so that we can decide if we leave it as it is (plain + encrypted) or not. All custom/Gentoo patches will be available *later* in a git repo[1]. So if you'd like to fix something or improve the theme you can contribute patches. Thanks to Alex Legler (a3li) for the Bugzilla theme. [1] http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-bugzilla.git;a=summary -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eclass for handling of file-based capabilities
On Sun, Mar 06, 2011 at 05:34:29PM +0100, Constanze Hausner wrote: On 17:44 Sat 05 Mar , Ciaran McCreesh wrote: * tar and xattrs is a massive problem, so how do binaries work? tar can be patched to support xattrs. If we want to use caps, we will have to apply those patches too. (iirc Fedora already uses such patches). For binpkg, the approach I mentioned would remove the need to for tar to support xattrs- the same mechanism for the PM to tweak the perms would be usable. So no need for tar/bsdtar to restore xattrs- it's undesirable anyways since as I mentioned, if the cap couldn't be applied for whatever reason it would result in a chmod -s binary being installed. For src, I'd strongly be against restoration there. It just opens up way too many surprises- a simple example is a tarball carrying the immutable flag. Xattrs really should be specified by the ebuild (and applied by the PM) instead- far more controlled namely. ~harring pgpdNxOI7kzuG.pgp Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2011-03-06 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2011-03-06 23h59 UTC. Removals: net-misc/asterisk-chan_unistim 2011-02-28 22:20:38 chainsaw net-misc/asterisk-sounds2011-02-28 22:20:38 chainsaw net-misc/asterisk-sounds-de-pforzheim 2011-02-28 22:20:38 chainsaw net-misc/elianna-pack 2011-02-28 22:20:39 chainsaw net-misc/asterisk-app_icd 2011-02-28 22:35:29 chainsaw dev-php5/xdebug 2011-03-03 18:37:04 olemarkus dev-php5/ZendFramework 2011-03-03 21:00:20 olemarkus dev-php5/phptal 2011-03-05 09:41:24 olemarkus dev-php5/phing 2011-03-06 10:41:01 olemarkus dev-php5/agavi 2011-03-06 11:06:18 olemarkus app-editors/mousepad2011-03-06 12:34:11 ssuominen x11-themes/gion-icon-theme 2011-03-06 12:35:02 ssuominen app-office/qbankmanager 2011-03-06 12:38:17 ssuominen net-dialup/slmodem 2011-03-06 12:39:36 ssuominen net-p2p/lince 2011-03-06 12:40:02 ssuominen Additions: dev-ruby/stomp 2011-02-28 06:59:06 graaff media-gfx/photoprint2011-02-28 07:07:31 radhermit www-apps/collectd-web 2011-02-28 13:44:23 alexxy app-admin/mcollective 2011-03-01 02:18:33 ramereth app-emulation/winetricks2011-03-01 02:35:56 vapier x11-plugins/qled2011-03-01 17:26:53 hwoarang gnome-extra/zeitgeist 2011-03-02 01:52:53 signals dev-libs/libzeitgeist 2011-03-02 01:59:07 signals gnome-extra/zeitgeist-datahub 2011-03-02 02:00:54 signals gnome-extra/synapse 2011-03-02 02:03:10 signals www-apps/cgisysinfo 2011-03-02 02:04:25 rafaelmartins sci-libs/opencascade2011-03-03 01:08:20 dilfridge app-misc/wcd2011-03-03 14:22:17 jlec dev-php/xdebug 2011-03-03 18:17:09 olemarkus sci-libs/gpp4 2011-03-03 20:10:55 jlec sys-cluster/native-mpi 2011-03-03 20:44:59 alexxy dev-php/ZendFramework 2011-03-03 20:56:46 olemarkus dev-python/pivy 2011-03-03 23:05:53 dilfridge net-dialup/neocon 2011-03-04 05:04:10 radhermit dev-ml/kaputt 2011-03-04 13:00:32 aballier dev-python/pyzmq2011-03-04 17:27:48 djc dev-python/redis-py 2011-03-04 17:39:49 djc dev-php/phptal 2011-03-05 09:38:39 olemarkus kde-misc/colibri2011-03-05 15:48:24 dilfridge dev-libs/libcgroup 2011-03-05 17:35:52 nerdboy sci-libs/spooles2011-03-05 18:20:52 bicatali perl-core/Version-Requirements 2011-03-06 07:26:22 tove virtual/perl-Version-Requirements 2011-03-06 07:28:19 tove perl-core/CPAN-Meta 2011-03-06 07:30:37 tove virtual/perl-CPAN-Meta 2011-03-06 07:32:17 tove net-wireless/python-wifi2011-03-06 10:31:06 jlec dev-php/phing 2011-03-06 10:35:18 olemarkus dev-php/agavi 2011-03-06 11:04:39 olemarkus media-gfx/freecad 2011-03-06 15:24:20 dilfridge dev-python/pyasn1-modules 2011-03-06 19:11:49 arfrever sci-libs/armadillo 2011-03-06 19:23:25 bicatali -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-misc/asterisk-chan_unistim,removed,chainsaw,2011-02-28 22:20:38 net-misc/asterisk-sounds,removed,chainsaw,2011-02-28 22:20:38 net-misc/asterisk-sounds-de-pforzheim,removed,chainsaw,2011-02-28 22:20:38 net-misc/elianna-pack,removed,chainsaw,2011-02-28 22:20:39 net-misc/asterisk-app_icd,removed,chainsaw,2011-02-28 22:35:29 dev-php5/xdebug,removed,olemarkus,2011-03-03 18:37:04 dev-php5/ZendFramework,removed,olemarkus,2011-03-03 21:00:20 dev-php5/phptal,removed,olemarkus,2011-03-05 09:41:24 dev-php5/phing,removed,olemarkus,2011-03-06 10:41:01 dev-php5/agavi,removed,olemarkus,2011-03-06 11:06:18 app-editors/mousepad,removed,ssuominen,2011-03-06 12:34:11 x11-themes/gion-icon-theme,removed,ssuominen,2011-03-06 12:35:02 app-office/qbankmanager,removed,ssuominen,2011-03-06 12:38:17 net-dialup/slmodem,removed,ssuominen,2011-03-06 12:39:36 net-p2p/lince,removed,ssuominen,2011-03-06 12:40:02 Added Packages: dev-ruby/stomp,added,graaff,2011-02-28 06:59:06
Re: [gentoo-dev] Bugzilla 4 migration
On 03/07/2011 01:00 AM, Jan Kundrát wrote: On 03/06/11 23:55, Christian Ruppert wrote: our Bugzilla (bugs.gentoo.org) will be unavailable for the next hours. We're going to migrate our old Bugzilla to Bugzilla-4. We expect our update to finish within the next hours. (Private reply, as I don't feel like flaming you in public. Feel free to re-send to a public list, or quote, preferably as a whole.) Hi Christian, I wanted to ask if I missed the announcement of the migration. I tried to imagine a case which would force people to go ahead and perform such an action without informing the world about the downtime in advance, but failed to find one. So, did I miss the announcement, or was that a lapse on some guy's side, or is it something else which warranted a swift action? Anyway, I'm looking forward to a nice, upgraded bugzie. Hm, so before sending this mail, I checked my gentoo-dev archive, and the first e-mail about Bugzilla migration is roughly 12 hours old. That's very different from how Infra has handled any other migration in the past (apart from dealing with unexpected emergencies, of course). I realize I'm in the armchair position in this case, but this looks like a rather dangerous move. When you add the workflow change, I wouldn't stick with an announcement 12 hours in advance myself (I do sysadmin stuff as a day job). With kind regards, Jan Hey Jan, I know I didn't announce it properly. It was *my* fault but this is also a special case IMO. We decided to migrate just a few hours ago because robbat2 and me having enough time to do it now, finally. We're waiting since about 2007 for Bugzilla upgrades and it's now 2011 so I thought it's ok to do it now instead of waiting another few months (probably) or longer until we both have enough time again etc. We're not going to change the workflow, at least not now. We only do that if you guys decided about it. -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On 3/6/11 1:50 PM, Brian Harring wrote: NEW will become CONFIRMED This seems mildly insane; sure you didn't mean UNCONFIRMED? I don't understand that concern. There is UNCONFIRMED and NEW, now you'd get UNCONFIRMED and CONFIRMED. It seems to me it's just NEW with a different name, and UNCONFIRMED would still be there: http://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/ I'm in favor of the new workflow. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
