Re: [gentoo-dev] jpeg-mmx is dead
On Mon, 2006-11-06 at 02:31 -0500, Mike Frysinger wrote: On Sunday 05 November 2006 22:42, Matthias Langer wrote: however, someone should adapt media-video/mjpegtools-1.8.0-r1 (see bug 154199) and someone should search for duplicates before filing bugs ups ... sorry - i should have looked after closed bugs too. this should not excuse the fault on my side, as i should have known better, but: a close in 48h-button in bugzilla would surely reduce the number of duplicates in a significant way. in fact, not looking after closed bugs before filing your own as a user, without cvs access to the tree, is always risky, as the fix may not yet be distributed to the rsync mirrors ... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Econf
Thanks, it work very well !D PIRYOn 11/2/06, Johannes Weiner [EMAIL PROTECTED] wrote:
On Mon, Oct 30, 2006 at 05:02:29PM -0500, Chris Gianelloni wrote: On Mon, 2006-10-30 at 22:44 +0100, KLessou wrote:
Hello, I have to make a Live ebuild (from a CVS repository). But econf don't find the configure script. !!! no configure script found .
The configure file is into ${WORKDIR}/package/, I have defined ${S} here, but no result. Set S globally (not in src_unpack) because ...1. src_compile() chdirs to $S
2. You change $S3. econf runs ./configureHannes -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee
Gentoo Foundation-- ~| klessou | ~
Re: [gentoo-dev] Re: Ignoring/overwriting IUSE from an eclass
On Sun, 05 Nov 2006 21:36:10 -0600 Ryan Hill [EMAIL PROTECTED] wrote: I'm sorry, but is anyone else sick and disgusted with Ciaran talking to people like this? This isn't called for and shouldn't be tolerated. No. Perhaps he could have been a bit more subtle, but it was entirely called for given the previous email in the thread. If people can't cope with being told that they're wrong, that's their problem. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Ignoring/overwriting IUSE from an eclass
Ryan Hill wrote: I'm sorry, but is anyone else sick and disgusted with Ciaran talking to people like this? This isn't called for and shouldn't be tolerated. After sleeping on it, I've decided my problem is personal, so i've just taken my own advice and set up a simple mail filter so I don't have to listen to this crap anymore. Unless, of course people respond, which is inevitable. But, I encourage anyone else tired of the bullshit to do the same, and maybe we can get the signal to noise ratio down to a reasonable level. Sorry for the noise. -- by design, by neglect [EMAIL PROTECTED]for a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] baselayout-1.13 going into ~ARCH soon
Hi List! This is a heads up to say that I'm going to be putting baselayout-1.13 into ~ARCH soon as all the exciting new features I wanted are in - FreeBSD and vserver support, buffered and wrapped einfo/ewarn/eerror output, rc-depend for lightning fast dependency sorting, no more critical services, no more net service specific code. So if you're concerned about any of the above features breaking your precious Gentoo, now is a very good time to test :) However, one issue is a concern. All baselayouts defined svcdir in /etc/conf.d/rc which defines where we hold the state information of the running services. This defaulted to /var/lib/init.d - which is bad as /var could be on a different partition. In 1.13, we've removed the variable from /etc/conf.d/rc and it's now forced to /lib/rcscripts/init.d which is safe as /lib is always on the same partition as /. The 1.13 ebuild will copy across existing state data, this is not the problem. However, downgrading back to 1.12 is a problem as services may have been stop, started etc in the middle. One solution is to ensure that we only hold one copy of the state data and move it to the new location. However, this does require altering the stable ebuild as well. Or we could just slap a very large warning on it. Ideas are welcome :) -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux/FreeBSD Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
So if you're concerned about any of the above features breaking your precious Gentoo, now is a very good time to test :) Mon Oct 2 22:24:05 2006 sys-apps/baselayout-1.13.0_alpha1-r1 ^^ Using 1.13* for over a month and no problems whatsover. -- Piotr Jaroszyński Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Ignoring/overwriting IUSE from an eclass
On Monday 30 October 2006 17:44, Piotr Jaroszyński wrote:
E_IUSE=${E_IUSE//X}
But that's a dirty portage-specific hack ;]
On Monday 30 October 2006 18:43, Ciaran McCreesh wrote:
Your solution is approximately on par with fixing a wobbly chair by
sawing off all four legs and then attaching what's left to a crocodile.
On Monday 06 November 2006 03:36, Ryan Hill wrote:
I'm sorry, but is anyone else sick and disgusted with Ciaran talking to
people like this? This isn't called for and shouldn't be tolerated.
Yes, I'm also sick of this negative level of civility. If I don't preempt it
now, I'll likely be told that I'm taking the above two quotes out of context
and that I'm just spreading FUD, but I don't believe the context really
changed from the outset.
Ciaran's analogies are always outrageous, condescending and greatly
accentuated. Specifically, his intention is never to help the person he is
replying to, but rather to show them that they are wrong. He believes that is
purely up to the person that he is replying to whether they learn from it or
not. There's a 100+ comment bug about this, though, which ended up with his
dismissal so discussing it further won't help any.
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
On Monday 06 November 2006 17:53, Roy Marples wrote: ... However, one issue is a concern. All baselayouts defined svcdir in /etc/conf.d/rc which defines where we hold the state information of the running services. This defaulted to /var/lib/init.d - which is bad as /var could be on a different partition. In 1.13, we've removed the variable from /etc/conf.d/rc and it's now forced to /lib/rcscripts/init.d which is safe as /lib is always on the same partition as /. The 1.13 ebuild will copy across existing state data, this is not the problem. However, downgrading back to 1.12 is a problem as services may have been stop, started etc in the middle. ... How is the case where the / partition always remains ro handled? Is rc-state information put into a tmpfs partition on that location, is the location configured differently for those? Bruno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Retirement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Portnoy wrote: I've been mostly inactive for a good while but hanging on mostly for sentimentality's sake, it's past time for that to stop. I mostly only maintain a small handful of ebuilds, I'm sure they can find proper homes quickly. None are maintenance-intensive. And of course, the only thing anyone is really concerned about; robbat2 has already laid claim to fortune-mod-gentoo-dev ;) Later. It's been fun, it's been real, but it hasn't been real fun. :) I'll be around #gentoo/#-dev. As I was gone for a week I didn't see this til this weekend, via seemant's blog. I was good and didn't reply til today to take that full week off. I'm sad to see you go Jon but know that you will continue to do great things so good luck in whatever you end up getting involved in -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFT24/SENan+PfizARAlwKAJsGIO7aKq5jmYGJp1G+WkidrBBcKACggzZV nc7glXTmCi8Bv5jkT7bbFpE= =/KWb -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
On Monday 06 November 2006 17:12, Bruno wrote: How is the case where the / partition always remains ro handled? Is rc-state information put into a tmpfs partition on that location, is the location configured differently for those? Good question! / is always ro at boot and the checkroot init script remounts it rw after checking it. As such, we mount /lib/rcscripts/init.d/ as tmpfs (or ramfs or similar). Yes, this means that the kernel must be configured with a ramdisk or similar OR /lib/rscripts/init.d is writeable. At the end of the rc process (ie end of boot runlevel) we tar up our state dir, unmount it and untar it back (taking good care with locking due to parallel starts and event driven services). Admittedly, an always ro / isn't handled right now, but I'll ensure it will be for the next release :) Thanks -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux/FreeBSD Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
On Monday 06 November 2006 17:33, Roy Marples wrote:
Admittedly, an always ro / isn't handled right now, but I'll ensure it will
be for the next release :)
We handle it with the attached patch, just comitted to our svn repo :)
Thanks
--
Roy Marples [EMAIL PROTECTED]
Gentoo/Linux/FreeBSD Developer (baselayout, networking)
Index: ChangeLog
===
--- ChangeLog (revision 2364)
+++ ChangeLog (working copy)
@@ -1,6 +1,11 @@
# ChangeLog for Gentoo System Intialization (rc) scripts
# Copyright 1999-2006 Gentoo Foundation; Distributed under the GPLv2
+ 06 Nov 2006; Roy Marples [EMAIL PROTECTED]:
+
+Ensure that we only move $svcdir from tmpfs to disk if $svclib is rw.
+Thanks to Bruno for the idea.
+
05 Nov 2006; Roy Marples [EMAIL PROTECTED]:
Don't create /proc on Linux as build scripts like to handle it now.
Index: sbin/rc
===
--- sbin/rc (revision 2364)
+++ sbin/rc (working copy)
@@ -442,7 +442,8 @@
rm -rf ${svcdir}/failed /dev/null
# If $svcdir is mounted in ram, save it back to disk and unmount
-if [[ $'\n'$(get_mounts) =~ $'\n'${svcdir}\ ]] ; then
+# but only if $svclib is writeable.
+if [[ $'\n'$(get_mounts) =~ $'\n'${svcdir}\ -w ${svclib} ]] ; then
# Function to show the timeout message
timeout=
do_timeout() {
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
Roy Marples wrote:
[snip that change the meaning of the message ;]
Ideas are welcome :)
need to jump net.lo in symlink tests fex as tested below:
for f in ${ROOT}etc/init.d/net.*; do
[[ ${f} == ${ROOT}etc/init.d/net.lo || -L ${f} ]] continue
echo
einfo WARNING: You have older net.* files in ${ROOT}etc/init.d/
[...]
there is a bug where to report gotchas ?
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Ignoring/overwriting IUSE from an eclass
On Wed, 8 Nov 2006 02:18:41 + Jason Stubbs [EMAIL PROTECTED] wrote: | Yes, I'm also sick of this negative level of civility. If I don't | preempt it now, I'll likely be told that I'm taking the above two | quotes out of context Which you are, since you removed a large part of my answer and then used it to claim that my answer was unhelpful. Hint: read all of what I wrote. | Ciaran's analogies are always outrageous, condescending and greatly | accentuated. And a lot of people find them a pleasant change from the usual lack of style and humour exhibited on this list. Effective technical writing does not have to be boring. | Specifically, his intention is never to help the person | he is replying to, but rather to show them that they are wrong. The person is irrelevant. What matters is whether someone looks at a proposed incorrect solution and uses it. | He believes that is purely up to the person that he is replying to | whether they learn from it or not. Well yes. What is this, nursery school? | discussing it further won't help any. But you still felt the need to try to throw in a cheap shot full of personal attacks. Right. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
On Monday 06 November 2006 17:51, Francesco Riosa wrote:
Roy Marples wrote:
[snip that change the meaning of the message ;]
Ideas are welcome :)
need to jump net.lo in symlink tests fex as tested below:
for f in ${ROOT}etc/init.d/net.*; do
[[ ${f} == ${ROOT}etc/init.d/net.lo || -L ${f} ]] continue
echo
einfo WARNING: You have older net.* files in ${ROOT}etc/init.d/
[...]
No I don't - net.lo is now a symlink itself to /lib/rcscripts/sh/net.sh
This solves the issue of users not etc-updating net.lo, and then getting loads
of errors. Which happens all to frequently.
there is a bug where to report gotchas ?
Nope. Just file a normal bug.
--
Roy Marples [EMAIL PROTECTED]
Gentoo/Linux/FreeBSD Developer (baselayout, networking)
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
On 06 Nov 2006 04:53 PM or thereabouts, Roy Marples wrote: This is a heads up to say that I'm going to be putting baselayout-1.13 into ~ARCH soon as all the exciting new features I wanted are in - FreeBSD and vserver support, buffered and wrapped einfo/ewarn/eerror output, rc-depend for lightning fast dependency sorting, no more critical services, no more net service specific code. Very nice! However, one issue is a concern. All baselayouts defined svcdir in /etc/conf.d/rc which defines where we hold the state information of the running services. This defaulted to /var/lib/init.d - which is bad as /var could be on a different partition. In 1.13, we've removed the variable from /etc/conf.d/rc and it's now forced to /lib/rcscripts/init.d which is safe as /lib is always on the same partition as /. From a filesystem usage point of view though, storing actively changing state data on /lib is ugly. The tmpfs /lib/rcscripts/init.d overlay solution for a ro / works, but as long as tmpfs magic is needed, can't it be written to /var after localmount? --Matthew [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for November
On Sat, 2006-11-04 at 15:45 -0800, Robin H. Johnson wrote: 3. The solution is for each enterprise to have their own tinderbox / build-machine. Tinderboxing is supported under catalyst, and I believe there is at least one other tinderbox implementation around. 4. (Assuming catalyst, as it's the only tinderbox I'm familiar with) The enterprise defines a specfile that describes each of their unique environments, and feeds these to tinderbox. Tinderbox generates sets of binpkgs for each environment, which the enterprise then deploys. Tinderbox (in catalyst) is designed more for testing. Using the stage4 catalyst target will save you a good amount of time, since it doesn't go through the unmerge/rsync/emerge cycle on each package. Just FYI. -- 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] New Developer: Alexander Færø y (eroyf)
Hi all. This announcement is slightly late but Alex never the less deserves a warm welcome for all the good work I'm sure he'll be doing in the future. Alex have a mysterious norwegian background but lives in Denmark (some people are a bit concerned about that fact as well..). Adding to his dubious background is the facts that he's a teenager and works for User Relations and the Alpha and Mips teams :) Please give Alex a warm welcome. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Sun, 2006-11-05 at 11:50 +0200, Alin Nastac wrote: Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. I have a problem with our current SPF record. I wanna see a +all in this record for 2 reasons: a) SPF is really worthless b) spamassassin have a SPF_NEUTRAL test, with a score bigger than 1 See http://thread.gmane.org/gmane.linux.gentoo.devel/43707/focus=43707 . This also falls under Infra. Have you tried asking them, instead? Perhaps filing a bug like all other infra requests? -- 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] Monthly Gentoo Council Reminder for November
On Sun, 2006-11-05 at 13:36 +0100, Jakub Moc wrote: Alin Nastac napsal(a): Mike Frysinger wrote: On Sunday 05 November 2006 05:39, Alin Nastac wrote: Mike Frysinger wrote: that's nice, but again, why arent these being directed to infra ? It could be considered as organization policy, so I assumed council had to be involved in this decision. it isnt ... so file a bug for infra done in bug 154120 . And WONTFIXed in 15 minutes. In that case, I'd like to resubmit it to the council... :/ So because you didn't like the answer from the people responsible for this, you'd rather go over their heads and try to bring this up to the council, so we can override their decisions? Not bloody likely. -- 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] Monthly Gentoo Council Reminder for November
Chris Gianelloni wrote: This also falls under Infra. Have you tried asking them, instead? Perhaps filing a bug like all other infra requests? Please see https://bugs.gentoo.org/show_bug.cgi?id=154120 . Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Mon, 06 Nov 2006 14:37:00 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: | So because you didn't like the answer from the people responsible for | this, you'd rather go over their heads and try to bring this up to the | council, so we can override their decisions? Not bloody likely. Isn't that part of why the Council is there? To make decisions on things where some people consider that those normally in charge of something are doing it incorrectly and refusing to fix things? Not saying that either side is right here... But there're a lot of objections to SPF out there, several people complaining and no justification from infra beyond we're using it anyway. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Mon, 2006-11-06 at 14:37 -0500, Chris Gianelloni wrote: So because you didn't like the answer from the people responsible for this, you'd rather go over their heads and try to bring this up to the council, so we can override their decisions? Not bloody likely. Let me post a little more productively. If you (Chris) had bothered to read the bug, you'd notice it goes like this: Alin: I have these issues for these reasons Andrea: I agree the thing isn't the best, and I think we're open to discussion. Kurt, will you weigh in? more back and forth between Alin and Andrea with Andrea maintaining that infra is a open to discussion Kurt: Nope, my opinion differs, I control things, I'm not talking about it. That's a summary, by the way, and I'm not quoting anyone, just paraphrasing closely. I don't care one way or the other about the issue, personally, but reading that bug is certainly a good way to get frustrated. Please stop being ridiculous, Council: if you're not going to actually listen to the people who voted for you without talking down to them, then, er, why exactly, did you run? -- Seemant Kulleen Developer, Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Chris Gianelloni napsal(a): And WONTFIXed in 15 minutes. In that case, I'd like to resubmit it to the council... :/ So because you didn't like the answer from the people responsible for this, you'd rather go over their heads and try to bring this up to the council, so we can override their decisions? Not bloody likely. No. Not because I didn't like the answer - because I haven't seen a *single* argument *in favour* of using the IMHO completely broken SPF thing. -- 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] Monthly Gentoo Council Reminder for November
Chris Gianelloni wrote: On Sun, 2006-11-05 at 13:36 +0100, Jakub Moc wrote: Alin Nastac napsal(a): Mike Frysinger wrote: On Sunday 05 November 2006 05:39, Alin Nastac wrote: Mike Frysinger wrote: that's nice, but again, why arent these being directed to infra ? It could be considered as organization policy, so I assumed council had to be involved in this decision. it isnt ... so file a bug for infra done in bug 154120 . And WONTFIXed in 15 minutes. In that case, I'd like to resubmit it to the council... :/ So because you didn't like the answer from the people responsible for this, you'd rather go over their heads and try to bring this up to the council, so we can override their decisions? Not bloody likely. I actually agree with Ciaran; it is your job to decide on stuff like this (or to rightly say the issue is stupid and write it off as such). Think US Supreme Court (we will hear your case and decide on it or we will say your case is frivolous). In either case a decision from you (the council) is required. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
Roy Marples wrote: On Monday 06 November 2006 18:27, Matthew Snelham wrote: In 1.13, we've removed the variable from /etc/conf.d/rc and it's now forced to /lib/rcscripts/init.d which is safe as /lib is always on the same partition as /. From a filesystem usage point of view though, storing actively changing state data on /lib is ugly. The tmpfs /lib/rcscripts/init.d overlay solution for a ro / works, but as long as tmpfs magic is needed, can't it be written to /var after localmount? It could be written to /var at the end of an rc. However, you then have to guarantee that /var is always available too and that may not always be the case as some people want to have /var net mounted or something equally silly :) /lib may be ugly, but it's also guaranteed which is what I'm more interested in. Thanks This screams vustomizable Just give us a variable we can set to move it; obviously there is no One True Location for everyone. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Monday 06 November 2006 16:59, Jakub Moc wrote: Chris Gianelloni napsal(a): And WONTFIXed in 15 minutes. In that case, I'd like to resubmit it to the council... :/ So because you didn't like the answer from the people responsible for this, you'd rather go over their heads and try to bring this up to the council, so we can override their decisions? Not bloody likely. No. Not because I didn't like the answer - because I haven't seen a *single* argument *in favour* of using the IMHO completely broken SPF thing. so what are you looking for ? us to regurgitate the entire SPF argument over again ? infra believes using SPF helps fight spam, you guys believe SPF does not ... how do you expect to come to a conclusion over such a technology ? -mike pgpHyOvxQXQ9D.pgp Description: PGP signature
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
On Monday 06 November 2006 22:06, Alec Warner wrote: Roy Marples wrote: On Monday 06 November 2006 18:27, Matthew Snelham wrote: In 1.13, we've removed the variable from /etc/conf.d/rc and it's now forced to /lib/rcscripts/init.d which is safe as /lib is always on the same partition as /. From a filesystem usage point of view though, storing actively changing state data on /lib is ugly. The tmpfs /lib/rcscripts/init.d overlay solution for a ro / works, but as long as tmpfs magic is needed, can't it be written to /var after localmount? It could be written to /var at the end of an rc. However, you then have to guarantee that /var is always available too and that may not always be the case as some people want to have /var net mounted or something equally silly :) /lib may be ugly, but it's also guaranteed which is what I'm more interested in. Thanks This screams vustomizable Just give us a variable we can set to move it; obviously there is no One True Location for everyone. If you want that level of flexability then simply symlink /lib/rcscripts to /var/rcscripts or where-ever you like. From my perspective, state data always has to be available and writeable, regardless of how simple or fancy the user has configured their layout. So this means I have access to /bin, /dev, /etc, /lib, /sbin as those directories have to exist on /. Why do we have to have everything configured by variables? -- Roy Marples [EMAIL PROTECTED] Gentoo Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Mike Frysinger napsal(a): No. Not because I didn't like the answer - because I haven't seen a *single* argument *in favour* of using the IMHO completely broken SPF thing. so what are you looking for ? us to regurgitate the entire SPF argument over again ? No. I expect you to _decide_ on the issue, considering that quite a couple of arguments were given against using it, and none was given in favour of using it. (Sorry, but I happen to disagree is not a valid or useful one). infra believes using SPF helps fight spam, you guys believe SPF does not ... how do you expect to come to a conclusion over such a technology ? -mike Infra didn't say anything useful, and no, they basically say that it's _not_ an antispam technology and that they'll continue to use it anyway, not subject to debate, the end... Kinda weird, hmmm? Last word on this, as it's getting really a frustrating experience. Quoting your own monthly email: snip If you have something you'd wish for us to chat about, maybe even vote on, let us know ! /snip Well folks, if you outright refuse to discuss/decide on stuff that people are asking you to discuss/decide on, then please drop the above from your email. I'll reconsider if it's worth wasting the bandwidth to vote for anyone next time. -- 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] Monthly Gentoo Council Reminder for November
On Monday 06 November 2006 18:03, Jakub Moc wrote: considering that quite a couple of arguments were given against using it which were a copy and paste of existing websites ... how about for the counterargument i copy and paste url's to pro-spf websites and then we'll have a proper exchange of ideas -mike pgpkpiX1PzCIK.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Monday 06 November 2006 21:35, Seemant Kulleen wrote: Please stop being ridiculous, Council: if you're not going to actually listen to the people who voted for you without talking down to them, then, er, why exactly, did you run? I have to agree with seemant here, we should probably accept the request even if some of the council already disagrees, that's why we vote on things... there's no loss in giving this a try, especially if there's no other thing on the agenda. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpZWu90v4AKW.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Monday 06 November 2006 17:09, Alin Nastac wrote: I re-stated my case in comment #14 most of your dislike for SPF centers around the idea you dont want to send mail via gentoo.org mail servers ... is this really a problem ? seems like it's pretty trivial to do so -mike pgpQQMpR29oZK.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Am Montag, 6. November 2006 20:37 schrieb Chris Gianelloni: On Sun, 2006-11-05 at 13:36 +0100, Jakub Moc wrote: Alin Nastac napsal(a): Mike Frysinger wrote: On Sunday 05 November 2006 05:39, Alin Nastac wrote: Mike Frysinger wrote: that's nice, but again, why arent these being directed to infra ? It could be considered as organization policy, so I assumed council had to be involved in this decision. it isnt ... so file a bug for infra done in bug 154120 . And WONTFIXed in 15 minutes. In that case, I'd like to resubmit it to the council... :/ So because you didn't like the answer from the people responsible for this, you'd rather go over their heads and try to bring this up to the council, so we can override their decisions? Not bloody likely. I disagree here. Let's put both items on the agenda. That finalizes the decission. In regard to 'Reply-To:'-munging: I'm going to vote to keep it as is, and i don't think that anybody would be able to convince me otherwise. In regard to SPF: If klieber (or any other infra member) can explain to me why SPF is a good thing(tm) to have for Gentoo Infrastructure, and convince me that it is the best way to go, i'll vote to keep it. Otherwise, i'm going to vote to remove it. Kurt: Please write up a short text to explain why you think this is necessary for Gentoo mailservers. Thanks in advance! Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Am Montag, 6. November 2006 20:37 schrieb Chris Gianelloni: On Sun, 2006-11-05 at 13:36 +0100, Jakub Moc wrote: it isnt ... so file a bug for infra done in bug 154120 . And WONTFIXed in 15 minutes. In that case, I'd like to resubmit it to the council... :/ So because you didn't like the answer from the people responsible for this, you'd rather go over their heads and try to bring this up to the council, so we can override their decisions? Not bloody likely. Uhm, i tend to disagree. I think we should evaluate the situation, and if _we_ think it is the best to override Infra's descision, we can and should do it. A completely different thing is, what our evaluation leads to. I for one would like to take both Reply-To:-Munging and SPF on our agenda. My current thoughts re these topics is as following: - Reply-To:-Munging: My vote: should stay as it currently is. Chris already pointed out how to modify the behaviour using procmail. - SPF: I currently don't understand what it is useful for in the current setup. I would appreciate if Kurt could write up a short text which explains why SPF is a good thing(TM) for Gentoo Infrastructure, so I can understand it :-) My vote would be: Remove, unless there is a real need for it. But this could change rather quickly once Kurt (or anybody else from Infra) has replied. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Mike Frysinger wrote: On Monday 06 November 2006 18:03, Jakub Moc wrote: considering that quite a couple of arguments were given against using it which were a copy and paste of existing websites ... how about for the counterargument i copy and paste url's to pro-spf websites and then we'll have a proper exchange of ideas -mike http://forum.spamcop.net/forums/lofiversion/index.php/t1963.html http://blog.ferris.com/2005/06/_microsofts_enf.html http://www.clickz.com/showPage.html?page=3388371 Here are some random links I found using spf rocks and google. Enjoy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Mon, Nov 06, 2006 at 05:20:49PM -0500, Mike Frysinger wrote: most of your dislike for SPF centers around the idea you dont want to send mail via gentoo.org mail servers ... is this really a problem ? seems like it's pretty trivial to do so While i couldn't care less about the whole SPF discussion i'd just like to point out sending mail via gentoo's email servers is listed as a last resort according to our docs rather than an alternative. http://www.gentoo.org/proj/en/infrastructure/dev-email.xml writes: Warning: Do not do this unless absolutely necessary. Please use your ISPs relay server whenever possible. If you need a relay-server desperately and have no other means of sending e-mails, you can use dev.gentoo.org as a relayserver. To do Using dev.gentoo.org as a mail relay server Perhaps that paragraph needs some rethinking if it affects SPF? cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgp2El20XRwjp.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Mon, Nov 06, 2006 at 05:20:26PM -0500, Mike Frysinger wrote: On Monday 06 November 2006 17:09, Alin Nastac wrote: I re-stated my case in comment #14 most of your dislike for SPF centers around the idea you dont want to send mail via gentoo.org mail servers ... is this really a problem ? seems like it's pretty trivial to do so Sending mail via gentoo.org mail servers is explicitly disallowed (not even just strongly discouraged) if the dev in question can use his/her ISP's server. http://www.gentoo.org/proj/en/infrastructure/dev-email.xml -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Mon, Nov 06, 2006 at 05:11:42PM -0500, Mike Frysinger wrote: On Monday 06 November 2006 18:03, Jakub Moc wrote: considering that quite a couple of arguments were given against using it which were a copy and paste of existing websites ... how about for the counterargument i copy and paste url's to pro-spf websites and then we'll have a proper exchange of ideas Why don't you do that? When some actual pro-SPF arguments are given, at least there's a real chance to either debunk or accept them. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
(sorry for the infra cc, just need to make sure this particular one gets through ... drop it in your replies people :P) On Monday 06 November 2006 17:38, Harald van Dijk wrote: Sending mail via gentoo.org mail servers is explicitly disallowed (not even just strongly discouraged) if the dev in question can use his/her ISP's server. http://www.gentoo.org/proj/en/infrastructure/dev-email.xml then *infra* needs to decide on a course here: - disable SPF - make sending gentoo.org mail via gentoo.org mail server friendly/recommended -mike pgpYEt1cQt9TQ.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Monday 06 November 2006 17:40, Harald van Dijk wrote: Why don't you do that? well, my reply was mostly dry sarcasm, but i hope we're all technically proficient enough to load up google.com and search for SPF ... even Alec could find three good links in no time and that dude cant even code his way out of a paper bag (or something) i'm not really pro or con SPF, just anti lamer -mike pgpqQvsBuLP9Q.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Alec Warner wrote: http://forum.spamcop.net/forums/lofiversion/index.php/t1963.html Anyone who thinks you can block all spam with a single technique, let alone at all, is not someone I want data from in the first place http://blog.ferris.com/2005/06/_microsofts_enf.html Opinion piece. http://www.clickz.com/showPage.html?page=3388371 fluff piece. I've seen two page BMW glossy ads with more technical info. Here are some random links I found using spf rocks and google. These links are short on detail and long on marketing. They aren't really answering why Gentoo uses what many consider to be a broken as designed technology. kashani -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Mike Frysinger wrote: On Monday 06 November 2006 17:09, Alin Nastac wrote: I re-stated my case in comment #14 most of your dislike for SPF centers around the idea you dont want to send mail via gentoo.org mail servers ... is this really a problem ? seems like it's pretty trivial to do so I admit I dislike SPF, but this isn't the issue. I don't ask Gentoo to join me in a crusade against SPF (I have better things to do with my life). The issue is we shouldn't have this TXT record for the g.o domain. While I could use smtp.g.o to send my email, others might be less lucky than me. Devs should have a choice whether they use Gentoo SMTP server or not, or at least this is opinion on the matter. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Mon, 6 Nov 2006 16:43:24 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: | infra believes using SPF helps fight spam Then infra are wrong. SPF was not designed to fight spam. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Monday 06 November 2006 20:06, Ciaran McCreesh wrote: On Mon, 6 Nov 2006 16:43:24 -0500 Mike Frysinger [EMAIL PROTECTED] | infra believes using SPF helps fight spam Then infra are wrong. SPF was not designed to fight spam. original design does not limit future possibilities ... i could make a lot of pointless blanket statements about what things were originally designed for thus future use is not possible -mike pgpMxIqBpXgz2.pgp Description: PGP signature
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
On 06 Nov 2006 09:57 PM or thereabouts, Roy Marples wrote: On Monday 06 November 2006 22:06, Alec Warner wrote: Roy Marples wrote: On Monday 06 November 2006 18:27, Matthew Snelham wrote: From a filesystem usage point of view though, storing actively changing state data on /lib is ugly. The tmpfs /lib/rcscripts/init.d overlay solution for a ro / works, but as long as tmpfs magic is needed, can't it be written to /var after localmount? It could be written to /var at the end of an rc. However, you then have to guarantee that /var is always available too and that may not always be the case as some people want to have /var net mounted or something equally silly :) /lib may be ugly, but it's also guaranteed which is what I'm more interested in. This screams vustomizable Just give us a variable we can set to move it; obviously there is no One True Location for everyone. If you want that level of flexability then simply symlink /lib/rcscripts to /var/rcscripts or where-ever you like. But then baselayout is still 'behaving badly' by sttempting to store dynamic state information in /lib. Something it has not done before, to the best of my knowledge (with the exception of /dev state tarballs, which are generally acceptable, since they don't change while the system is up). UNIX filesystem usage patterns are older than a good chunk of gentoo devs, so in the name of defaulting to expected behaviour, I think /lib should be avoided. From my perspective, state data always has to be available and writeable, regardless of how simple or fancy the user has configured their layout. So this means I have access to /bin, /dev, /etc, /lib, /sbin as those directories have to exist on /. /usr and /var have to be accessable for a working system... and if init fails before those are availible, the system is non-functional regardless. So a tmp storage location is needed for state data early in the boot process (before writeable filesystems can be assured), and can flip before the boot runlevel is completed. (I've built a number of clusters with NFS root fs, but I've never even heard of a disk backed root with an NFS /var. Can we say that's pathologically odd, and unsupported/unsupportable?) Why do we have to have everything configured by variables? Eh, I'm not sure I see the need for this to be a variable. I'd just like to see it well behaved. --Matthew [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
Matthew Snelham wrote: If you want that level of flexability then simply symlink /lib/rcscripts to /var/rcscripts or where-ever you like. But then baselayout is still 'behaving badly' by sttempting to store dynamic state information in /lib. Something it has not done before, to the best of my knowledge (with the exception of /dev state tarballs, which are generally acceptable, since they don't change while the system is up). UNIX filesystem usage patterns are older than a good chunk of gentoo devs, so in the name of defaulting to expected behaviour, I think /lib should be avoided. +1 This is a very good point, why are we breaking from accepted UNIX standards uselessly? Generally, a live system should never need to write to /lib, but a writable /var is pretty much standard. This new behavior breaks standards, if /var is on a separate filesystem, maybe we can use a subdir in /tmp for the init stuff until we get /var up, then move it over. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: baselayout-1.13 going into ~ARCH soon
In 1.13, we've removed the variable from /etc/conf.d/rc and it's now forced to /lib/rcscripts/init.d which is safe as /lib is always on the same partition as /. From a filesystem usage point of view though, storing actively changing state data on /lib is ugly. The tmpfs /lib/rcscripts/init.d overlay solution for a ro / works, but as long as tmpfs magic is needed, can't it be written to /var after localmount? After reading all the concerns and doubt and things, i ask myself: why not keep in a tmpfs? Well, it can be swapped out too, and it isn't too much data anyway, is it? The most disturbing thing to me, would be yet another entry when i watch the list mountpoints. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
On Monday 06 November 2006 21:42, Matthew Snelham wrote: But then baselayout is still 'behaving badly' by sttempting to store dynamic state information in /lib. it is and it isnt ... the dir is memory based so /lib could be read-only and that's fine -mike pgpTSguX5K8Nu.pgp Description: PGP signature
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
Patrick McLean wrote: Matthew Snelham wrote: If you want that level of flexability then simply symlink /lib/rcscripts to /var/rcscripts or where-ever you like. But then baselayout is still 'behaving badly' by sttempting to store dynamic state information in /lib. Something it has not done before, to the best of my knowledge (with the exception of /dev state tarballs, which are generally acceptable, since they don't change while the system is up). UNIX filesystem usage patterns are older than a good chunk of gentoo devs, so in the name of defaulting to expected behaviour, I think /lib should be avoided. +1 This is a very good point, why are we breaking from accepted UNIX standards uselessly? Generally, a live system should never need to write to /lib, but a writable /var is pretty much standard. This new behavior breaks standards, if /var is on a separate filesystem, maybe we can use a subdir in /tmp for the init stuff until we get /var up, then move it over. Agreed, this is a good point. Writing to /lib will also cause security complications for things like AIDE and other intrusion detection systems that look for writes to certain directories. If they see /lib changing quite often, it might confuse 'em and the sysadmin, who will get a rash of spurious alerts. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
On Tuesday 07 November 2006 04:06, Josh Saddler wrote: Agreed, this is a good point. Writing to /lib will also cause security complications for things like AIDE and other intrusion detection systems that look for writes to certain directories. If they see /lib changing quite often, it might confuse 'em and the sysadmin, who will get a rash of spurious alerts. H? It would only be updated when a service starts or stops or a user updates their config, which would imply a restart I suppose. The state data is generally only written to when starting up and shutting down - in the meantime it should be minimal. -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Quoting Lance Albertson [EMAIL PROTECTED]: Personally, after skimming through this thread, I'd say leave it as is and stick with Kurt's decision. Our developers clearly have nothing better to do than rant on about something as trivial as this. I ain't no dev, but how is this trivial? A typical scenario is: a gentoo-dev sends an e-mail to a mailing list (a non-gentoo mailing list) and that mail gets nuked by a greedy spam filter because the SPF rules exclude (oh well, do not specifically include) the server that forwards the mailing list message. Or could it be that my understanding of SPF is flawed (quite likely)? -- /\ Georgi Georgiev /\ Advertisements contain the only truths to /\ \/[EMAIL PROTECTED]\/ be relied on in a newspaper. -- Thomas \/ /\ http://www.gg3.net /\ Jefferson /\ This message was sent using IMP, the Internet Messaging Program. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
On Tuesday 07 November 2006 02:42, Matthew Snelham wrote: (I've built a number of clusters with NFS root fs, but I've never even heard of a disk backed root with an NFS /var. Can we say that's pathologically odd, and unsupported/unsupportable?) OK, I have /var mounted on an LVM. I need to run an fsck on it, so I unmount it and do the stuff I need to in single user mode. In baselayout-1.13 I can bring the entire system back up by going back to the default runlevel (although there is one error in checkfs I have to address). Now how can we do that if our state data no longer exists as /var is not available? Yes the user could remount it and it's back, but what happens if this is a laptop and the user plugs in their wifi card and they urgently need to get network running and there's a problem mounting /var? Why do we have to have everything configured by variables? Eh, I'm not sure I see the need for this to be a variable. I'd just like to see it well behaved. Well behaved as to the LFS or well behaved as in coping for as many scenarios as we can? I'm all for the later. If you want the former then you're welcome to suggest alternative fixes for this too :) -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
