[gentoo-dev] Introduction
Hey, Thanks to phreak`` for that great introduction and all his help over the last month or so, much appreciated, if you (or any gentoo dev) find yourself in switzerland, I'll gladly buy you a drink. As phreak`` mentioned I have a strong security interest and I will thusly be harassing Taviso for a long time to come! I'm looking forward to being a useful member of the community, hopefully I will see a lot of you at FOSDEM. Cheers -Rob -- /** * Robert Clark ** * Technical Student ALICE/DAQ * Software Engineer CERN PH/AID * Phone: (+41) (0)22 767 8338 ** * Gentoo Linux Developer * GPG : 0x2217D168 */ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Kevin F. Quinn napsal(a):
On Tue, 9 Jan 2007 23:23:55 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:
If a RESTRICT value is questionable, it shouldn't be supported or
used.
I agree; it'd be useful to know exactly what is failing the sandbox and
why, with the aim of fixing sandbox if it isn't quite up to the job.
+1; RESTRICT=sandbox shouldn't exist.
If you want to write an ebuild for some commercial broken stuff that
doesn't work w/ sandbox and stick it into some overlay, then stick
if has sandbox ${FEATURES} ; then
eerror This thing is FUBAR with sandbox
die If you really want to install it, disable sandbox manually
fi
into pkg_setup and be done with it; no need for RESTRICT=sandbox or
ACCEPT_RESTRICT. Users can decide whether they really wish to install
such app and disable sandbox temporarily if they think it's a good idea.
If you'd like to commit this to the official tree, then either fix it
properly or don't commit such stuff at all.
--
Best regards,
Jakub Moc
mailto:[EMAIL PROTECTED]
GPG signature:
http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E
... still no signature ;)
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-p2p/ww
# Raúl Porcel armin76 at gentoo.org (10 Jan 2007) # Upstream dead almost 2 years ago and doesn't compile with GCC 4.x. # Pending removal 10 Feb 2007, bug 152464 net-p2p/ww -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New developer: Marijn Schouten (hkBst)
It's my pleasure to introduce to you Marijn hkBst Schouten. He is joining us to take care of the packages related to the weird programming language called scheme. He hails from Zeist, near Utrecht in the Netherlands. This is how he describes himself: I'm working on my combined master thesis for physics and mathematics, which is about Yang-Mills instantons. I like to do varies forms of martial arts, currently down to 3 hours a week (from ~13) to speed up previously mentioned thesis. I like to read: mostly fantasy and science fiction and books on operating system( kernel)s, compilers and good books about/using computer languages I'm interested in. I also like to play Risk whenever I can get it and I love those little furry beasts called cats. So please give hkBst the usual warm welcome. Regards, Petteri PS. He is the owner of two MMIX T-shirts from DEK which he got for spotting some trivial bugs/typos. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Add LCD_DEVICES to USE_EXPAND
On Wed, 2007-01-10 at 01:15 +0100, Robert Buchholz wrote: If no one objects, I'd like to implement these changes. But there are some questions still open: * Who will add the entries to base/make.defaults? Can I do this? Not only *can* you, but you absolutely *must* do this if you're making the changes. The profiles aren't some black box that nobody can touch. The only thing anyone asks is that you know the ramifications of your actions. Asking here and getting sound advice should suffice for determining whether something is worth doing and the proper solution. *Not* adding these yourself means pawning work off on someone else, and possibly breaking (at least) your packages, and a violation of policy (the don't break the tree one). * Should the defaults and the USE_EXPAND entry be in base/ even though both programs do not are not keyworded for all arches? Yes. After all, they *may* be keyworded on any arch. It isn't like the hardware/software *can't* run on those arches. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wed, 2007-01-10 at 09:40 +0100, Jakub Moc wrote: into pkg_setup and be done with it; no need for RESTRICT=sandbox or ACCEPT_RESTRICT. Users can decide whether they really wish to install such app and disable sandbox temporarily if they think it's a good idea. Uhh... you missed RESTRICT=userpriv and the upcoming RESTRICT=unattended when calling for no ACCEPT_RESTRICT... If you'd like to commit this to the official tree, then either fix it properly or don't commit such stuff at all. That's very easy for someone to say when they're not the ones involved in the work. Placing artificial limitations such as this really is a bad idea. After all, we're all about empowering the user to make the choice, so let them make the choice. If users want the package, why should we stop them when it is technically feasible and not completely asinine? Besides, if I want to maintain some nasty application that doesn't work with sandbox, who are you (or anyone, for that matter) to tell me that I cannot? Hell, we could even *not* have sandbox/userpriv in the default ACCEPT_RESTRICT, since they have possible security implications. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wednesday 10 January 2007 03:40, Jakub Moc wrote: If you want to write an ebuild for some commercial broken stuff that doesn't work w/ sandbox and stick it into some overlay, then stick before you start anymore ignorant rants, why dont you look at what actually needs this app-editors/emacs dev-lang/gcl if you're categorizing those as commercial broken stuff you might want to look up the word commercial -mike pgp4ibICnkwHQ.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On 1/11/07, Chris Gianelloni [EMAIL PROTECTED] wrote: On Wed, 2007-01-10 at 09:40 +0100, Jakub Moc wrote: into pkg_setup and be done with it; no need for RESTRICT=sandbox or ACCEPT_RESTRICT. Users can decide whether they really wish to install such app and disable sandbox temporarily if they think it's a good idea. Uhh... you missed RESTRICT=userpriv and the upcoming RESTRICT=unattended when calling for no ACCEPT_RESTRICT... If you'd like to commit this to the official tree, then either fix it properly or don't commit such stuff at all. That's very easy for someone to say when they're not the ones involved in the work. Placing artificial limitations such as this really is a bad idea. After all, we're all about empowering the user to make the choice, so let them make the choice. If users want the package, why should we stop them when it is technically feasible and not completely asinine? Besides, if I want to maintain some nasty application that doesn't work with sandbox, who are you (or anyone, for that matter) to tell me that I cannot? Hell, we could even *not* have sandbox/userpriv in the default ACCEPT_RESTRICT, since they have possible security implications. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation I know at least one person who have an automated/cron-jobbed upgrade system, and I believe it would be useful as an extra application of ACCEPT_RESTRICT for them to auto-accept upgrades which can be done without breaking things without user interaction, and then occasionally have them doing a manual emerge run with ACCEPT_RESTRICT including the interactive requests to do the items which need their presence. My 2 cents. Kent, -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites for net-www/bk_edit
net-www/bk_edit has been dead upstream since the end of 2003 and does not build with GCC 4.x. We've only had one report of it failing to build, thus I am led to believe it will not be profoundly missed. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] deprecating /etc/make.profile
Hi all, As per bug 148388 [1] comment 1, I'd like to discuss the deprecation of /etc/make.profile and the use of a PORTAGE_PROFILE variable instead. Reason for this change aside from consistency with all other portage settings is the annoyance of re-adjusting the /etc/make.profile link before and after testing a profile change in an overlay/development repo. Before the change to portage is finally made, a few things will have to be done: * Adjust handbook * Adjust the eselect plugin * (Anything I'm missing?) If you don't like this idea, please speak up. [1] http://bugs.gentoo.org/show_bug.cgi?id=148388 -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Mike Frysinger napsal(a): On Wednesday 10 January 2007 03:40, Jakub Moc wrote: if you're categorizing those as commercial broken stuff you might want to look up the word commercial Huh? I was referring to this link [1] on Bug 161045 (which presumably started this whole debate) [1] http://marc.theaimsgroup.com/?l=gentoo-user-dem=115148403700916w=2 The gcl borkage is your job [2] and you might want to finally revert your broken commit: [2] http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lisp/gcl/gcl-2.6.7-r2.ebuild?r1=1.2r2=1.3 -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
maillog: 10/01/2007-15:34:52(+0100): Jakub Moc types Mike Frysinger napsal(a): On Wednesday 10 January 2007 03:40, Jakub Moc wrote: if you're categorizing those as commercial broken stuff you might want to look up the word commercial Huh? I was referring to this link [1] on Bug 161045 (which presumably started this whole debate) [1] http://marc.theaimsgroup.com/?l=gentoo-user-dem=115148403700916w=2 The gcl borkage is your job [2] and you might want to finally revert your broken commit: [2] http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lisp/gcl/gcl-2.6.7-r2.ebuild?r1=1.2r2=1.3 I looked at the diff and it replaces export SANDBOX_ON=0 with RESTRICT=sandbox. It seems that the problem is older than that revision. -- \Georgi Georgiev \ Chuck Norris cannot love, he can only not \ / [EMAIL PROTECTED]/ kill. / \ http://www.gg3.net/ \ \ pgpGeJ6Lwlw7D.pgp Description: PGP signature
Re: [gentoo-dev] deprecating /etc/make.profile
On Wednesday 10 January 2007 15:30, Simon Stelling wrote: Before the change to portage is finally made, a few things will have to be done: * Adjust handbook * Adjust the eselect plugin * (Anything I'm missing?) Am I right in thinking there would be a transition period when profile setting from make.conf would override make.profile link and small info would be displayed about future complete deprecation? If so I am fully with it. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Marijn Schouten (hkBst)
Welcome on board, Marijn, I'm looking forward to doing the gnucash bumps with you soon :) -- Seemant Kulleen Developer, Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] deprecating /etc/make.profile
Make a transition like locales.build and locales.gen, for instance. That would be handy. On 1/10/07, Piotr Jaroszyński [EMAIL PROTECTED] wrote: On Wednesday 10 January 2007 15:30, Simon Stelling wrote: Before the change to portage is finally made, a few things will have to be done: * Adjust handbook * Adjust the eselect plugin * (Anything I'm missing?) Am I right in thinking there would be a transition period when profile setting from make.conf would override make.profile link and small info would be displayed about future complete deprecation? If so I am fully with it. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list -- Ioannis Aslanidis deathwing00[at]gentoo.org 0xB9B11F4E -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wednesday 10 January 2007 09:34, Jakub Moc wrote: Huh? I was referring to this link [1] on Bug 161045 (which presumably started this whole debate) so you're replying to a non-gentoo-dev thread on a gentoo-dev thread when the threads arent even closely related ? how does that make sense ? this thread has nothing to do with commercial packages -mike pgpZo5imOU3MR.pgp Description: PGP signature
Re: [gentoo-dev] Add LCD_DEVICES to USE_EXPAND
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10.01.2007 at 13:56, Chris Gianelloni wrote: On Wed, 2007-01-10 at 01:15 +0100, Robert Buchholz wrote: * Who will add the entries to base/make.defaults? Can I do this? Not only *can* you, but you absolutely *must* do this if you're making the changes. The profiles aren't some black box that nobody can touch. The only thing anyone asks is that you know the ramifications of your actions. Asking here and getting sound advice should suffice for determining whether something is worth doing and the proper solution. *Not* adding these yourself means pawning work off on someone else, and possibly breaking (at least) your packages, and a violation of policy (the don't break the tree one). Just wanted to make sure I don't break an unknown to me or unwritten rule here :-) * Should the defaults and the USE_EXPAND entry be in base/ even though both programs do not are not keyworded for all arches? Yes. After all, they *may* be keyworded on any arch. It isn't like the hardware/software *can't* run on those arches. Good point. Regards, Robert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFpR51yZx3L/ph1soRAgWXAKDh52GHFPK1ue3zO19Zato5/E9ESACggmvU mo0Od4tmTpQ6vD3N7ER0X/g= =LG0s -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Georgi Georgiev napsal(a): The gcl borkage is your job [2] and you might want to finally revert your broken commit: [2] http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lisp/gcl/gcl-2.6.7-r2.ebuild?r1=1.2r2=1.3 I looked at the diff and it replaces export SANDBOX_ON=0 with RESTRICT=sandbox. It seems that the problem is older than that revision. No, the gcl problem didn't exist until vapier fixed the ebuild. I still fail to see why RESTRICT=sandbox is any better than the undocumented `export SANDBOX_ON=0` hack (which basically shouldn't be used anywhere in the tree anyway, ideally)... -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Mike Frysinger napsal(a): On Wednesday 10 January 2007 09:34, Jakub Moc wrote: Huh? I was referring to this link [1] on Bug 161045 (which presumably started this whole debate) so you're replying to a non-gentoo-dev thread on a gentoo-dev thread when the threads arent even closely related ? how does that make sense ? this thread has nothing to do with commercial packages No, it does not. And RESTRICT=sandbox is still completely unneeded, commercial packages or not... We don't need to introduce a special RESTRICT because of two borked packages in the tree and we should not introduce any more packages borked in a similar way into the tree. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Chris Gianelloni napsal(a): Uhh... you missed RESTRICT=userpriv and the upcoming RESTRICT=unattended when calling for no ACCEPT_RESTRICT... Don't see how's userpriv related here; also the original idea was to stick FEATURES=unattended (or non-interactive or whatever else) into portage, instead of inventing new variables to handle this, AFAICR. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] deprecating /etc/make.profile
Simon Stelling wrote: Hi all, As per bug 148388 [1] comment 1, I'd like to discuss the deprecation of /etc/make.profile and the use of a PORTAGE_PROFILE variable instead. Reason for this change aside from consistency with all other portage settings is the annoyance of re-adjusting the /etc/make.profile link before and after testing a profile change in an overlay/development repo. Before the change to portage is finally made, a few things will have to be done: * Adjust handbook * Adjust the eselect plugin * (Anything I'm missing?) If you don't like this idea, please speak up. [1] http://bugs.gentoo.org/show_bug.cgi?id=148388 This would require widespread documentation changes for the GDP, so we would absolutely require some close teamwork with the Portage guys if this happens. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wednesday 10 January 2007 13:03, Jakub Moc wrote: And RESTRICT=sandbox is still completely unneeded, commercial packages or not... We don't need to introduce a special RESTRICT because of two borked packages in the tree and we should not introduce any more packages borked in a similar way into the tree. for future reference, keep your replies on topic and stupid rants out this is what you should have said in the first place we need a real solution for emacs/gcl ... exporting SANDBOX_ON=0 is not the answer -mike pgpjwZ2fTBR3J.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Mike Frysinger napsal(a): this is what you should have said in the first place we need a real solution for emacs/gcl ... exporting SANDBOX_ON=0 is not the answer -mike Real solution, sure... RESTRICT=sandbox is not a solution, it's identical to the current hackish workaround, so I guess we can save portage folks the trouble... That was the whole point, thanks. :) BTW, usersandbox is not a valid RESTRICT either (see Bug 136445) -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wednesday 10 January 2007 13:45, Jakub Moc wrote: Real solution, sure... RESTRICT=sandbox is not a solution, it's identical to the current hackish workaround, so I guess we can save portage folks the trouble... except that RESTRICT is the documented method for disabling user FEATURES in ebuilds ... it works for pretty much every FEATURE except some -mike pgpWtrkvpyKqX.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Mike Frysinger napsal(a): On Wednesday 10 January 2007 13:45, Jakub Moc wrote: Real solution, sure... RESTRICT=sandbox is not a solution, it's identical to the current hackish workaround, so I guess we can save portage folks the trouble... except that RESTRICT is the documented method for disabling user FEATURES in ebuilds ... it works for pretty much every FEATURE except some -mike Well, honestly the point is that I'd rather leave the ways to disable sandbox in ebuilds pretty much undocumented, as opposed to making this easier.. :) -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New developer: Marijn Schouten (hkBst)
A fellow Dutchman, and he also likes cats! Gentoo keeps getting better all the time. :-) Welkom, Martijn! -- Hans de Graaff -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wednesday 10 January 2007 19:03, Jakub Moc wrote: Mike Frysinger napsal(a): On Wednesday 10 January 2007 09:34, Jakub Moc wrote: Huh? I was referring to this link [1] on Bug 161045 (which presumably started this whole debate) so you're replying to a non-gentoo-dev thread on a gentoo-dev thread when the threads arent even closely related ? how does that make sense ? this thread has nothing to do with commercial packages No, it does not. And RESTRICT=sandbox is still completely unneeded, commercial packages or not... We don't need to introduce a special RESTRICT because of two borked packages in the tree and we should not introduce any more packages borked in a similar way into the tree. I agree. The restrict should only be even considered when it is clear that the sandbox is indeed flawed by concept and cannot be fixed. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpWhO94WyagX.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wed, 10 Jan 2007 08:02:37 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: | Besides, if I want to maintain some nasty application that | doesn't work with sandbox, who are you (or anyone, for that matter) to | tell me that I cannot? Given how Portage relies upon sandbox to ensure that packages can be installed and uninstalled correctly, it probably suggests that you should be maintaining your nasty application using some other packaging system... -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wed, 2007-01-10 at 19:06 +0100, Jakub Moc wrote: Chris Gianelloni napsal(a): Uhh... you missed RESTRICT=userpriv and the upcoming RESTRICT=unattended when calling for no ACCEPT_RESTRICT... Don't see how's userpriv related here; also the original idea was to stick FEATURES=unattended (or non-interactive or whatever else) into portage, instead of inventing new variables to handle this, AFAICR. Wow. http://www.gentoo.org/proj/en/glep/glep-0052.html The name of the GLEP is even RESTRICT=unattended... not FEATURES=unattended... Now, let's try to make this as absolutely clear as possible. I am a user. I don't want any of my compiles executing with elevated privileges. I have FEATURES=userpriv. Package foo has RESTRICT=userpriv. I don't have ACCEPT_RESTRICT=userpriv. When I try to install package foo, it fails, because I don't want to allow RESTRICT=userpriv. Now, let's try the other. I am a user. I have games-fps/ut2004-data installed. The package has the new RESTRICT=unattended in the ebuild. I do not have ACCEPT_RESTRICT=unattended. I do an emerge --sync emerge -vuDN world... but there's a problem! There's a new revision of games-fps/ut2004-data that would require me to pull out my DVD in the middle of my emerge. Well, no problem. Instead of the current behavior, portage ignores the package/dies/whatever to let me know it cannot complete properly without my interaction. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wed, 2007-01-10 at 21:01 +0100, Paul de Vrieze wrote: On Wednesday 10 January 2007 19:03, Jakub Moc wrote: Mike Frysinger napsal(a): On Wednesday 10 January 2007 09:34, Jakub Moc wrote: Huh? I was referring to this link [1] on Bug 161045 (which presumably started this whole debate) so you're replying to a non-gentoo-dev thread on a gentoo-dev thread when the threads arent even closely related ? how does that make sense ? this thread has nothing to do with commercial packages No, it does not. And RESTRICT=sandbox is still completely unneeded, commercial packages or not... We don't need to introduce a special RESTRICT because of two borked packages in the tree and we should not introduce any more packages borked in a similar way into the tree. I agree. The restrict should only be even considered when it is clear that the sandbox is indeed flawed by concept and cannot be fixed. That's fine, but it still doesn't remove the usefulness of an ACCEPT_RESTRICT for some other variables. Think of it this way... a user *chose* to add a FEATURE. We have a package that doesn't work with that FEATURE. Currently, we tell the user they're wrong and do it our way, no matter what. There's no mechanism for the user to say Always do what I say. I'd rather not install the package if it doesn't work with $FEATURE. which could be solved with ACCEPT_RESTRICT. It gives the power back to the user, not the ebuild writer. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
[gentoo-dev] gentoo-sources-2.4 needs a maintainer (a real one)
Hi, A few weeks ago I posted that gentoo-sources-2.4 needs a maintainer. antarus stepped up but realised his fatal mistake and has now fled from the scene. If anyone is interested please step up, otherwise this will go through the usual mask/removal process. Recruiting a non-developer to take this is an option, provided the usual requirements are met. Maintaining a kernel is a big job, plus maintaining a 'dead' kernel tree like 2.4 is even worse and is not really that interesting. A maintainer needs to have interest and energy (which probably indicates a genuine requirement to run 2.4), I'm not interested in seeing this maintained-but-neglected. Please mention this in the next GWN. Thanks! Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites for media-libs/openquicktime
So the openquicktime package was up to now broken with GCC 3.4 and later, see bug #65453; as nobody seemed to actually give a damn about it, and there's libquicktime that works decently enough, I've masked it and will be remove it in 30 days. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpTdE70rHRdS.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Chris Gianelloni napsal(a): On Wed, 2007-01-10 at 19:06 +0100, Jakub Moc wrote: Don't see how's userpriv related here; also the original idea was to stick FEATURES=unattended (or non-interactive or whatever else) into portage, instead of inventing new variables to handle this, AFAICR. Wow. http://www.gentoo.org/proj/en/glep/glep-0052.html The name of the GLEP is even RESTRICT=unattended... not FEATURES=unattended... And how's that in contradiction? Why can't a user stick 'unattended' into FEATURES instead of having to care about yet another variable? Sticking RESTRICT=unattended into ebuild will make the ebuild unavailable to the user until he removes that from his FEATURES. What's the problem? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wed, 10 Jan 2007 16:43:52 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: | That's fine, but it still doesn't remove the usefulness of an | ACCEPT_RESTRICT for some other variables. For what other variables? We already established that it doesn't work for fetch, and that it's unsafe for sandbox. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] gentoo-sources-2.4 needs a maintainer (a real one)
On Wed, 2007-01-10 at 16:47 -0500, Daniel Drake wrote: Please mention this in the next GWN. I don't always read every post of every thread. In the future, send such requests to [EMAIL PROTECTED] to be sure I'll actually see it before making up the GWN. Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wed, 2007-01-10 at 23:02 +0100, Jakub Moc wrote: The name of the GLEP is even RESTRICT=unattended... not FEATURES=unattended... And how's that in contradiction? Why can't a user stick 'unattended' into FEATURES instead of having to care about yet another variable? Sticking RESTRICT=unattended into ebuild will make the ebuild unavailable to the user until he removes that from his FEATURES. What's the problem? OK. I'm done. I honestly can't even comprehend how you're not getting this, and I don't have the patience to continue discussing this without getting quite hostile. The only thing I can possibly gather from this is you're intentionally being fucking dense, so it's not worth my time. How is it that you can ignore half an email and only respond to something out of context and then still fuck *that* up? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Chris Gianelloni napsal(a): On Wed, 2007-01-10 at 23:02 +0100, Jakub Moc wrote: The name of the GLEP is even RESTRICT=unattended... not FEATURES=unattended... And how's that in contradiction? Why can't a user stick 'unattended' into FEATURES instead of having to care about yet another variable? Sticking RESTRICT=unattended into ebuild will make the ebuild unavailable to the user until he removes that from his FEATURES. What's the problem? OK. I'm done. I honestly can't even comprehend how you're not getting this, and I don't have the patience to continue discussing this without getting quite hostile. The only thing I can possibly gather from this is you're intentionally being fucking dense, so it's not worth my time. How is it that you can ignore half an email and only respond to something out of context and then still fuck *that* up? OK, dunno which of us is being dense; the whole point is that the damned ACCEPT_RESTRICT is completely redundant; hard to grok or what exactly? You already *don't* accept the restrict by sticking 'unattended' into FEATURES... WTH would you need to negate your FEATURES via another variable instead of simply altering the FEATURES (or not sticking such thing there in the first place?) -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] deprecating /etc/make.profile
On Wed, 2007-01-10 at 16:30 +0200, Simon Stelling wrote: Hi all, As per bug 148388 [1] comment 1, I'd like to discuss the deprecation of /etc/make.profile and the use of a PORTAGE_PROFILE variable instead. Reason for this change aside from consistency with all other portage settings is the annoyance of re-adjusting the /etc/make.profile link before and after testing a profile change in an overlay/development repo. PORTAGE_CONFIGROOT= kinda solves your problem. But I do admit it would be a lot easier dealing with a variable vs having to parse the symlink to figure out the profile. If this change does happen I'd suggest that we support make.profile symlinks as long as they exist unless the make.conf defines the variable. If variable exists it should override. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wednesday 10 January 2007 18:36, Jakub Moc wrote: OK, dunno which of us is being dense; the whole point is that the damned ACCEPT_RESTRICT is completely redundant; hard to grok or what exactly? You already *don't* accept the restrict by sticking 'unattended' into FEATURES... WTH would you need to negate your FEATURES via another variable instead of simply altering the FEATURES (or not sticking such thing there in the first place?) did you even read his e-mail ? the GLEP isnt just about sandbox or unattended ... i wont elaborate because i'll be copying pasting his e-mail -mike pgpxNgvP5LbPv.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Quoting Jakub Moc [EMAIL PROTECTED]: Georgi Georgiev napsal(a): I looked at the diff and it replaces export SANDBOX_ON=0 with RESTRICT=sandbox. It seems that the problem is older than that revision. No, the gcl problem didn't exist until vapier fixed the ebuild. I still fail to see why RESTRICT=sandbox is any better than the undocumented `export SANDBOX_ON=0` hack (which basically shouldn't be used anywhere in the tree anyway, ideally)... Alright, I don't know what the problem is in your opinion, but the way I see it is that the ebuild wants to touch stuff outside the sandbox and *that* is the problem. There were obviously two solutions, well, workarounds -- an undocumented variable and the RESTRICT. *Neither* one is better than the other. What vapier did was make the problem visible, which doesn't mean that he introduced it. Further, by adopting ACCEPT_RESTRICT, it would be possible to be able to say: ACCEPT_RESTRICT=-sandbox: Do not let any ebuild touch anything outside the sandbox. ACCEPT_RESTRICT=-userpriv: Do not let any ebuild run with elevated privileges. This message was sent using IMP, the Internet Messaging Program. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Thu, 11 Jan 2007 09:07:54 +0900 Georgi Georgiev [EMAIL PROTECTED] wrote: | Further, by adopting ACCEPT_RESTRICT, it would be possible to be able | to say: ACCEPT_RESTRICT=-sandbox: Do not let any ebuild touch | anything outside the sandbox. | ACCEPT_RESTRICT=-userpriv: Do not let any ebuild run with elevated | privileges. Which gains what, exactly? These are not things about which the end user should be concerned. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Mike Frysinger napsal(a): On Wednesday 10 January 2007 18:36, Jakub Moc wrote: OK, dunno which of us is being dense; the whole point is that the damned ACCEPT_RESTRICT is completely redundant; hard to grok or what exactly? You already *don't* accept the restrict by sticking 'unattended' into FEATURES... WTH would you need to negate your FEATURES via another variable instead of simply altering the FEATURES (or not sticking such thing there in the first place?) did you even read his e-mail ? the GLEP isnt just about sandbox or unattended ... i wont elaborate because i'll be copying pasting his e-mail -mike http://www.gentoo.org/proj/en/glep/glep-0052.html snip This GLEP proposes a new value for the RESTRICT metadata variable in ebuilds to indicate that an ebuild requires interaction by the user. ... Portage (and by extension other package managers) will support a new value for the RESTRICT metadata variable called unattended. /snip Maybe you are talking about a different GLEP, or I simply don't get this new variable mania... -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Quoting Ciaran McCreesh [EMAIL PROTECTED]: On Thu, 11 Jan 2007 09:07:54 +0900 Georgi Georgiev [EMAIL PROTECTED] wrote: | Further, by adopting ACCEPT_RESTRICT, it would be possible to be able | to say: ACCEPT_RESTRICT=-sandbox: Do not let any ebuild touch | anything outside the sandbox. | ACCEPT_RESTRICT=-userpriv: Do not let any ebuild run with elevated | privileges. Which gains what, exactly? These are not things about which the end user should be concerned. A user shouldn't be concerned if an ebuild wants to leave the sandbox when not supposed to? Anyway, I'll agree that this RESTRICT should simply be disallowed and that's about the only thing that bothered me. This message was sent using IMP, the Internet Messaging Program. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wednesday 10 January 2007 19:22, Jakub Moc wrote: Mike Frysinger napsal(a): On Wednesday 10 January 2007 18:36, Jakub Moc wrote: OK, dunno which of us is being dense; the whole point is that the damned ACCEPT_RESTRICT is completely redundant; hard to grok or what exactly? You already *don't* accept the restrict by sticking 'unattended' into FEATURES... WTH would you need to negate your FEATURES via another variable instead of simply altering the FEATURES (or not sticking such thing there in the first place?) did you even read his e-mail ? the GLEP isnt just about sandbox or unattended ... i wont elaborate because i'll be copying pasting his e-mail http://www.gentoo.org/proj/en/glep/glep-0052.html sorry, s/glep/thread/ as stated in original e-mail, unattended/sandbox are just some examples, not the only ones -mike pgp87y4AMUddP.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Thu, 11 Jan 2007 09:38:29 +0900 Georgi Georgiev [EMAIL PROTECTED] wrote: | Quoting Ciaran McCreesh [EMAIL PROTECTED]: | On Thu, 11 Jan 2007 09:07:54 +0900 Georgi Georgiev [EMAIL PROTECTED] | wrote: | | Further, by adopting ACCEPT_RESTRICT, it would be possible to be | | able to say: ACCEPT_RESTRICT=-sandbox: Do not let any ebuild touch | | anything outside the sandbox. | | ACCEPT_RESTRICT=-userpriv: Do not let any ebuild run with elevated | | privileges. | | Which gains what, exactly? These are not things about which the end | user should be concerned. | | A user shouldn't be concerned if an ebuild wants to leave the | sandbox when not supposed to? Correct. *Developers* should be concerned about whether their package installs and uninstalls correctly. If an ebuild is leaving the sandbox, it's doing so because it's necessary (at least at present -- this proposal will make it more like because the developer couldn't be bothered to fix something). Remember that packages can still do bad stuff to the filesystem even when sandbox is turned on. The point of sandbox is to be a safety feature, not a security measure. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wed, 10 Jan 2007 19:56:00 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: | as stated in original e-mail, unattended/sandbox are just some | examples, not the only ones So which RESTRICT values *should* the user legitimately have to care about? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wed, 10 Jan 2007 14:00:42 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Wednesday 10 January 2007 13:45, Jakub Moc wrote: Real solution, sure... RESTRICT=sandbox is not a solution, it's identical to the current hackish workaround, so I guess we can save portage folks the trouble... except that RESTRICT is the documented method for disabling user FEATURES in ebuilds ... it works for pretty much every FEATURE except some -mike Ok, before this myth gets stuck any more: FEATURES and RESTRICT are two independent entities. That *some* FEATURES have a matching RESTRICT value is more a coincidence that a design pattern. Also RESTRICT handles some things that have no matching entry in FEATURES (like the infamous RESTRICT=fetch for example) or have a different meaning than their matching FEATURES value (e.g. RESTRICT=mirror has nothing in common with FEATURES=mirror). Marius PS: this isn't an argument for or against the original proposal. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wed, 10 Jan 2007 19:06:09 +0100 Jakub Moc [EMAIL PROTECTED] wrote: Chris Gianelloni napsal(a): Uhh... you missed RESTRICT=userpriv and the upcoming RESTRICT=unattended when calling for no ACCEPT_RESTRICT... Don't see how's userpriv related here; also the original idea was to stick FEATURES=unattended (or non-interactive or whatever else) into portage, instead of inventing new variables to handle this, AFAICR. Actually so far there hasn't been any discussion about adding a way to mask packages with RESTRICT=unattended. The GLEP so far just mandates that those packages are highlighted in some way for the user. Just mentioning so people don't think that this idea is approved and implemented yet. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] deprecating /etc/make.profile
On Wed, 10 Jan 2007 16:30:00 +0200 Simon Stelling [EMAIL PROTECTED] wrote: Hi all, As per bug 148388 [1] comment 1, I'd like to discuss the deprecation of /etc/make.profile and the use of a PORTAGE_PROFILE variable instead. Reason for this change aside from consistency with all other portage settings is the annoyance of re-adjusting the /etc/make.profile link before and after testing a profile change in an overlay/development repo. Before the change to portage is finally made, a few things will have to be done: * Adjust handbook * Adjust the eselect plugin * (Anything I'm missing?) More tools that require an update: - euse and genpkgindex from gentoolkit - ufed - likely a bunch of other tools from app-portage (anything that doesn't use portage.config) - probably some other packages outside of app-portage (catalyst?) And I assume there is a non-trivial number of custom scripts out there using make.profile, but that's nothing we can do about. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] deprecating /etc/make.profile
On 1/11/07, Marius Mauch [EMAIL PROTECTED] wrote: And I assume there is a non-trivial number of custom scripts out there using make.profile, but that's nothing we can do about. You could give them all a grace period for which have to comply with the new standard by then end of it, and have ( during that grace period ) an automatic symlink generation based on that make.conf flag. And just to make sure, I doubt it would be too difficult to have an application that analyises packages as they install to check whether they reference make.profile or not, and flag a QA warning if they do. And packages that don't switch to the standard by the end of the grace period I guess we'll see on a last rites bulletin ;) - Kent -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] deprecating /etc/make.profile
On Thu, 2007-01-11 at 17:37 +1300, Kent Fredric wrote: On 1/11/07, Marius Mauch [EMAIL PROTECTED] wrote: And I assume there is a non-trivial number of custom scripts out there using make.profile, but that's nothing we can do about. You could give them all a grace period for which have to comply with the new standard by then end of it, and have ( during that grace period ) an automatic symlink generation based on that make.conf flag. And just to make sure, I doubt it would be too difficult to have an application that analyises packages as they install to check whether they reference make.profile or not, and flag a QA warning if they do. And packages that don't switch to the standard by the end of the grace period I guess we'll see on a last rites bulletin ;) Or we/gentoo could just support it and stop breaking the end user. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] deprecating /etc/make.profile
On 1/11/07, Ned Ludd [EMAIL PROTECTED] wrote: Or we/gentoo could just support it and stop breaking the end user. uh, the point was, what will happen to all those apps for users who switched to the -new- standard by using make.conf, who will therefore have no make.profile dir, so programs looking for that dir will fail. We have to provide some sort of compatibilty for people who use the new standard, or you will be seeing dozens of bug reports on all the numerous portage based programs which are still dependant on the old standard. I guess of course you could do a bulk hard masking of portage utilizing this feature untill all programs depending on this feature are fixed, but that would be not very nice to maintain I believe. -- gentoo-dev@gentoo.org mailing list
