[gentoo-dev] Monthly Gentoo Council Reminder for December
This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! 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. Keep in mind that every GLEP *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] packages.gentoo.org lives!
Robin H. Johnson wrote: My quote was from the first sentence of RFC1738, sec 3.3 (HTTP), para 4. Missed that, sorry. Redirecting clients to new URLs would give you perfect caching as well. That's why I say i'm willing to do redirection at the cache level. I do NOT want lots of users with old links to hit the actually web application if it's just going to redirect all of them to a page that is already in the cache. I thought you were doing caching/redirects on a service that sits before the real webapp . - The old parsing and variable usage code was the source of multiple bugs as well as the security issue that shuttered the site. Only because it passed the raw, unescaped values directly to shell, which is of course badly broken. Have a look at the recent discussion about HTML5 issues (http://www.crockford.com/html/), which also applies to web applications: HTML 5 is strict in the formulation of HTML entities. In the past, some browsers have been too forgiving of malformed entities, exposing users to security exploits. Browsers should not perform heroics to try to make bad content displayable. Such heroics result in security vulnerabilities. I can't follow this one -- how are broken browsers related to non-standard URLs? Why is an attempt to invent a competitive standard to XHTML related to URLs? Now that's something that sound reasonable. Why limit the period and don't provide it forever? Time limited to force everybody to move over, and to not have to support the redirections for the old version of the site forever, when they weren't advertised as permanent URLs. My question could be re-phrased as why don't keep those redirects, but you did the work, so you decide how to run it and I have no problems with that :). I did a quick hack up of some statistics, and I see that only 6.7% (5001 out of (69434+5001)) of the overall visitors were arriving at the old locations and not receiving the content they were originally interested in. Fine with me, thanks for your answers and all the work. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-mobilephone/gammu: ChangeLog gammu-1.15.0.ebuild
On 09:36 Sat 01 Dec , Alin Nastac (mrness) wrote:
1.1 app-mobilephone/gammu/gammu-1.15.0.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-mobilephone/gammu/gammu-1.15.0.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-mobilephone/gammu/gammu-1.15.0.ebuild?rev=1.1content-type=text/plain
my_use_with() {
local WITH_PREFIX
if [ -n ${2} ]; then
WITH_PREFIX=-DWITH_${2}
else
WITH_PREFIX=-DWITH_${1}
fi
if use $1 ; then
echo ${WITH_PREFIX}=ON
else
echo ${WITH_PREFIX}=OFF
fi
}
Seems like you're duplicating functionality of cmake-utils.eclass. Might
want to use that instead.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/rsync: ChangeLog rsync-2.6.9-r5.ebuild
On 17:56 Sat 01 Dec , Mike Frysinger (vapier) wrote: 1.1 net-misc/rsync/rsync-2.6.9-r5.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/rsync/rsync-2.6.9-r5.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/rsync/rsync-2.6.9-r5.ebuild?rev=1.1content-type=text/plain $(use_enable acl acl-support) \ $(use_enable acl xattr-support) \ We have a separate global xattr flag that could be used here. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/rsync: ChangeLog rsync-2.6.9-r5.ebuild
On 11:48 Sat 01 Dec , Donnie Berkholz wrote: On 17:56 Sat 01 Dec , Mike Frysinger (vapier) wrote: 1.1 net-misc/rsync/rsync-2.6.9-r5.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/rsync/rsync-2.6.9-r5.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/rsync/rsync-2.6.9-r5.ebuild?rev=1.1content-type=text/plain $(use_enable acl acl-support) \ $(use_enable acl xattr-support) \ We have a separate global xattr flag that could be used here. ... And I see that the 3.x ebuild already does so, but the 2.x ones don't. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Userinfo cleanups, and automatic generation
Hi everybody, Phreak and myself have been working on the data cleanups needed to get userinfo.xml generation fully automated from LDAP - we're very close now, just polishing data to that no old data gets used when we go live. I'm looking for verification/correctness of the following information (see the attached diff, and respond if you know the answer). dju - GPG key joem- GPG key, location jrinkovs- surname lordvan - location maedhros- GPG key markusle- roles, location mjc - join date taviso - GPG key wrobel - GPG key Also at that time, I'd like to find non-Gentoo addresses for all retired developers (needed for another upcoming project). -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 --- userinfo.xml.old.2 2007-12-01 21:16:00.0 + +++ userinfo.xml2007-12-01 21:16:30.0 + @@ -1753,7 +1753,7 @@ firstnameJulien/firstname familynameAllanos/familyname /realname -pgpkey0x1EC6C6C2/pgpkey +pgpkey0x3CA91F19/pgpkey email[EMAIL PROTECTED]/email email[EMAIL PROTECTED]/email joined15 June 2005/joined @@ -3182,11 +3182,11 @@ firstnameJoe/firstname familynameMcCann/familyname /realname -pgpkey0xBEE5CD74/pgpkey +pgpkey0x1B1E9741/pgpkey email[EMAIL PROTECTED]/email joined29 November 2004/joined rolesGnome/roles -location latitude=39.16 longitude=-86.529167Bloomington, Indiana/location +location longitude=-86.529167 latitude=39.16Illinois, USA/location /user user username=johnm realname fullname=John Mylchreest @@ -3259,9 +3259,9 @@ rolesppc64, releng/roles /user user username=jrinkovs -realname fullname=Joe Rinkovsky +realname fullname=Joe Rinkovski firstnameJoe/firstname - familynameRinkovsky/familyname + familynameRinkovski/familyname /realname pgpkey0x86E1E83A/pgpkey email[EMAIL PROTECTED]/email @@ -3917,7 +3917,7 @@ email[EMAIL PROTECTED]/email joined04 December 2002/joined rolesDVB, net-print and Python/roles -location longitude=-0.6934 latitude=52.3029Wellingborough, UK/location +location longitude=16 latitude=48.201Austria/location /user user username=lostlogic realname fullname=Brandon Low @@ -4029,7 +4029,7 @@ firstnameJonathan/firstname familynameCoome/familyname /realname -pgpkey0x848970C5/pgpkey +pgpkey0xA46E5974/pgpkey email[EMAIL PROTECTED]/email joined26 July 2005/joined rolesForums/roles @@ -4150,8 +4150,8 @@ pgpkey0x08FD678F/pgpkey email[EMAIL PROTECTED]/email joined31 October 2005/joined -rolesScientific Gentoo/roles -locationPittsburgh, PA/location +rolesScientific Computing/roles +locationChampaign, Illinois/location /user user username=martigen realname fullname=Ashton Mills @@ -4414,7 +4414,7 @@ /realname pgpkey/ email[EMAIL PROTECTED]/email -joined/ +joined?? January 2001/joined statusretired/status rolesKernel/roles locationFlorida, USA/location @@ -6414,7 +6414,7 @@ firstnameTavis/firstname familynameOrmandy/familyname /realname -pgpkey0x2690FD71/pgpkey +pgpkey0x05FF73D8/pgpkey email[EMAIL PROTECTED]/email joined/ rolesGentoo/Alpha, Security/roles @@ -7138,7 +7138,7 @@ firstnameGunnar/firstname familynameWrobel/familyname /realname -pgpkey0x970343BE/pgpkey +pgpkey0x809BEB4B/pgpkey email[EMAIL PROTECTED]/email email[EMAIL PROTECTED]/email joined27 December 2005/joined pgpMTKMqWJbca.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/freevo: ChangeLog freevo-1.7.4.ebuild freevo-1.6.1.ebuild freevo-1.5.4-r2.ebuild freevo-1.6.0.ebuild
On 21:04 Sat 01 Dec , Robert Buchholz (rbu) wrote: 1.1 media-tv/freevo/freevo-1.7.4.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/freevo/freevo-1.7.4.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/freevo/freevo-1.7.4.ebuild?rev=1.1content-type=text/plain use dvd ! (built_with_use media-libs/xine-lib directfb) \ ewarn media-libs/xine-lib was not built with directfb support ! (built_with_use media-video/mplayer directfb) \ ewarn media-video/mplayer was not built with directfb support if ! (built_with_use media-libs/libsdl directfb) ; then eerror media-libs/libsdl was not built with directdb support eerror Please re-emerge libsdl with the directfb use flag die directfb use flag specified but no support in libsdl and others fi fi There's no reason to use subshells for these checks, and more checks I cut. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for December
On Sat, Dec 01, 2007 at 05:45:02AM +, Mike Frysinger wrote: This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! 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. The new USE documentation discussion was mailed to the council by flameeyes after the first posts in gentoo-dev[1], but I'm not sure if it's really in the agenda so, please, consider it to be discussed. I would suggest this kind of question based on the different ideas shown by the developers comunity: - What is proper way to make changes to ebuild related information (metadata.dtd)? Do we need a GLEP? It only need to be discussed in -dev first? Gentoo-doc is who control metadata.dtd? And depends on the conclusion, please think if the current USE documentation specified in metadata.xml is consider as final. Thanks. P.D: This is not a post to discuss the new USE documentation (again), is just a request to the council to decide in this area where we (developers) have different points of view. [1] http://archives.gentoo.org/gentoo-dev/msg_149120.xml -- Jose Luis Rivero [EMAIL PROTECTED] Gentoo/Doc Gentoo/Alpha -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for December
Jose Luis Rivero wrote: I would suggest this kind of question based on the different ideas shown by the developers comunity: - What is proper way to make changes to ebuild related information (metadata.dtd)? Do we need a GLEP? It only need to be discussed in -dev first? Gentoo-doc is who control metadata.dtd? Eh? News to me. No, we in the GDP don't control it. In viewing the history [1], I see that neysx did make one commit to it, but that's because he's a go-to guy for xml/dtd stuff in general, not because this file is under the sole control of the GDP. We're not the ebuild developers/writers . . . you are. Granted, we do have commit access to that part of gentoo/xml/, but we're not the be-all and end-all for suggested changes to metadata.dtd. Something the council might want to keep in mind. [1] http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/dtd/metadata.dtd?rev=1.6view=log signature.asc Description: OpenPGP digital signature
