php-devel July 2009

php-devel@lists.fedoraproject.org

4 participants
8 discussions

Re: Naming Scheme php-pear-HTML_Javascript and php-pear-Auth_HTTP
by Remi Collet 19 Jul '09

19 Jul '09

Le 17/07/2009 16:59, Mamoru Tasaka a écrit : > Christopher Stone wrote, at 07/17/2009 02:22 PM +9:00: >> On Thu, Jul 16, 2009 at 9:26 PM, Mamoru >> Tasaka<mtasaka(a)ioa.s.u-tokyo.ac.jp> wrote: >>> Christopher Stone wrote, at 07/17/2009 11:59 AM +9:00: >>>> On Thu, Jul 16, 2009 at 1:35 AM, Mamoru >>>> Tasaka<mtasaka(a)ioa.s.u-tokyo.ac.jp> wrote: >>>>> You must explain why you want to force to change understore to hyphen, >>>>> even if installed files actually uses understore in its name. >>>> So trying to think back to when we originally created the PHP >>>> guidelines, specifically for php-pear, I think we had already >>>> discussed this issue. You may want to search the packaging list >>>> archives, I forget when we formulated the guidelines. Anyway, I think >>>> the logic behind it was that the perl packages converted the :: to - >>>> in their packages. So in order to be consistent with the perl packages >>>> we used the same convention in the php-pear packages. There might be >>>> some other technical reason why fedora converts upstream's :: to - for >>>> perl packages which I'm not aware of however. But IIRC, that was the >>>> logic behind the package naming. >>> >>> perl modules have some underscore naming like >>> perl-Convert-NLS_DATE_FORMAT. We have no reason we must apply perl >>> naming rule here and again there is no reason we should convert >>> underscore >>> to hyphen >>> which would just cause confusion. >>> >>> Please think in the way that we need less guidelines as much as >>> possible. >>> If you have some reason *specific to php-pear*, please explain, and such >>> reason must be written somewhere properly. >>> >>> Mamoru >>> >> >> Then I guess we should search the packaging list archives and see if >> we can find the reasoning when the guidelines were being formulated. >> It must have been discussed or else the entire packaging committee >> misunderstood the guidelines at the time. The majority of the >> packages are owned by Remi and myself. I don't know how much work it >> will be to rename all the packages. Hi, First, I think this discussion should go to fedora-php-devel (a public place), as I'd like to heard from others (tim please ?) > > So at least for now we cannot justify why underscore should be converted > to hyphen, right? I'm still not convinced.. but probably because I hate underscore... > For me it is strange that you or Remi don't remember > that (, however I guess there was actually no _real_ reason anyway). > > If we cannot find out what was discussed, we must withdraw the proposal > about converting underscore to hyphen and at least new packages must > use underscore if upstream's naming uses it. > (However I think remaing php-pear related packages on Fedora is preferable > and it is better that such renaming should be begun as early as possible) :( really a big work > > Regards, > Mamoru > Best regards.

4 3

For FPC : Change proposal to PHP Guidelines
by Remi Collet 18 Jul '09

18 Jul '09

Hi, We have some pending minor issues/questions with PHP packaging we should make clearer : 1/ use of /usr/share/php => 1 folder per library 2/ conditional in ABI check and in post/postun scriplet This conditions are present to maintain compatibility with older PHP version (5.1.6 on EL-5) and could be removed if package requires a recent version (> 5.2) 3/ ABI check With the update of PHP 5.3.0 in rawhide, I discover that a lot of C extensions doesn't use ABI check, Guidelines set is mandatory for PECL extension. Package could be installed, but extension couldn't be load, with the standard PHP error : Module compiled with module API=20060613 PHP compiled with module API=20090626 It seems clear it should be mandatory for all C extension. See bugs : cups https://bugzilla.redhat.com/show_bug.cgi?id=511106 ice https://bugzilla.redhat.com/show_bug.cgi?id=511068 graphviz https://bugzilla.redhat.com/show_bug.cgi?id=511092 uuid https://bugzilla.redhat.com/show_bug.cgi?id=511115 Please review my change proposal https://fedoraproject.org/wiki/PackagingDrafts/PHP Remi

2 2

Re: [php-maint] Bug#535770: PHP system timezone patch for 5.3?
by Joe Orton 17 Jul '09

17 Jul '09

Hi Sean, sorry I didn't see your comments earlier. On Wed, Jul 15, 2009 at 01:14:46AM +0200, sean finney wrote: > in your comments you say: > > /* Parse an ISO-6709 date as used in zone.tab. Returns end of the > > s/date/coordinate/ ? :) Hah! I've fixed this in patch v7. > but more seriously: > > * in create_zone_index() it looks like > find_zone_info(system_zone_info...) is called but system_zone_info > isn't initialized until after create_zone_index has returned. This was fixed in v6. > * i'm not sure but it seems like there might be a few corresponding free()'s > missing from the mallocs/strdups. Yeah, everything here is malloc'ed but never free'd. We could set it up to be free'd in the date extension's global destructor, but, it would require modifying php_date.c which I am reluctant to do. I'm not sure it makes much difference; the memory will remain allocated for the lifetime of the process in any case, right? > * it looks like load_zone_table() is called unconditionally, even if > it's not needed (i.e. a scall to localtime() will trigger it) I think this is necessary, though I didn't realize that before v6, and didn't explain it at all in the v6 comments. I've added some better commentary now in v7 - the problem is that we need the fake tzdb->data array to be created once the tzdb is created, since timezone_identifiers_list() peeks directly into it. > * is parsing the comments really necessary? i don't see any php functions > that use them. They are exposed by the getLocation() interface - $ php -r '$m = new DateTimeZone("America/New_York"); \ print_r($m->getLocation());' Array ( [country_code] => US [latitude] => 40.71416 [longitude] => -73.99362 [comments] => Eastern Time ) but yes they do seem to be kind of useless, in general. > also, before i came to the conclusion that some kind of intermediate > hashtable was needed to do the mapping (at which point i gave up and > figured i'd wait to hear back from you :), i had done a slightly > simpler implementation of the parsing using a clean mmap'd buffer > and sscanf with "%ms" type formats which avoids a lot of the hard-coded > lengths etc[1]. if you're interested i can hack that code into the > load_zone_info (and parse_iso6709) to make a leaner/cleaner/more efficient > implementation. Does it end up being much simpler without relying on sscanf/%ms? I would rather this code is portable across older glibcs (e.g. so it works on older versions of RHEL). > also, FYI my posts to the fedora list are being automatically rejected > so if i say anything important that should be shared someone should > forward it along :) I've requested that you are whitelisted on the Fedora list. Thanks a lot for reviewing the patch, greatly appreciated! Regards, Joe

1 0

[seanius@debian.org: Re: [php-maint] Bug#535770: PHP system timezone patch for 5.3?]
by Joe Orton 17 Jul '09

17 Jul '09

Forwarding since Sean's mail is not making it through. ----- Forwarded message from sean finney <seanius(a)debian.org> ----- From: sean finney <seanius(a)debian.org> To: PHP Packagers <pkg-php-maint(a)lists.alioth.debian.org>, 535770(a)bugs.debian.org, judas.iscariote(a)gmail.com, fedora-php-devel-list(a)redhat.com Date: Wed, 15 Jul 2009 01:14:46 +0200 Subject: Re: [php-maint] Bug#535770: PHP system timezone patch for 5.3? User-Agent: Mutt/1.5.20 (2009-06-14) hi joe, some quick notes/observations... in your comments you say: /* Parse an ISO-6709 date as used in zone.tab. Returns end of the s/date/coordinate/ ? :) but more seriously: * in create_zone_index() it looks like find_zone_info(system_zone_info...) is called but system_zone_info isn't initialized until after create_zone_index has returned. * i'm not sure but it seems like there might be a few corresponding free()'s missing from the mallocs/strdups. * it looks like load_zone_table() is called unconditionally, even if it's not needed (i.e. a scall to localtime() will trigger it) * is parsing the comments really necessary? i don't see any php functions that use them. also, before i came to the conclusion that some kind of intermediate hashtable was needed to do the mapping (at which point i gave up and figured i'd wait to hear back from you :), i had done a slightly simpler implementation of the parsing using a clean mmap'd buffer and sscanf with "%ms" type formats which avoids a lot of the hard-coded lengths etc[1]. if you're interested i can hack that code into the load_zone_info (and parse_iso6709) to make a leaner/cleaner/more efficient implementation. also, FYI my posts to the fedora list are being automatically rejected so if i say anything important that should be shared someone should forward it along :) sean [1] 'm' being the sooner-or-later POSIX.1 adoption of the non-standard 'a' GNU libc extension to automatically allocate the parsed strings, which in turn conflicted with the C99 'a' (float) format specifier, hence the new specifier. it requires glibc >= 2.7 btw. ----- End forwarded message -----

1 0

Re: Naming Scheme php-pear-HTML_Javascript and php-pear-Auth_HTTP
by Remi Collet 16 Jul '09

16 Jul '09

Le 16/07/2009 21:37, Christopher Stone a écrit : > On Thu, Jul 16, 2009 at 1:35 AM, Mamoru > Tasaka<mtasaka(a)ioa.s.u-tokyo.ac.jp> wrote: >> Remi Collet wrote, at 07/16/2009 05:23 PM +9:00: >>> I have just notice than php-pear-HTML_Javascript and php-pear-Auth_HTTP >>> have been approved. >>> >>> I think this package should be named php-pear-HTML-Javascript and >>> php-pear-Auth-HTTP, like all others pear extensions available in Fedora. >>> >> I strongly disagree with your proposition. >> We _must_ honor the naming upstream developer uses as much as possible, >> otherwise >> this will easily confuse people who will actually want to use these packages >> on Fedora. > > Well, one thing is clear. We need to be consistent. We should > identify which php-pear packages are renaming _ to - and which are > not. > >From http://rpms.famillecollet.com/rpmphp/rpm.php?type=pear php-pear-Auth-RADIUS (xulchris) php-pear-Auth-SASL (remi) php-pear-Cache-Lite (remi) php-pear-Console-Color (timj) php-pear-Console-Getargs (remi) php-pear-Console-ProgressBar (remi) php-pear-Console-Table (remi) php-pear-Crypt-Blowfish (xavierb) php-pear-Crypt-CHAP (xulchris) php-pear-Date-Holidays (xulchris) php-pear-Date-Holidays-USA (xulchris) php-pear-DB-DataObject (xulchris) php-pear-DB-DataObject-FormBuilder (xulchris) php-pear-DB-QueryTool (xulchris) php-pear-Event-Dispatcher (remi) php-pear-File-Find (remi) php-pear-File-Passwd (xulchris) php-pear-File-SMBPasswd (xulchris) php-pear-HTML-Common (xulchris) php-pear-HTML-QuickForm (xulchris) php-pear-HTML-QuickForm-advmultiselect (remi) php-pear-HTML-QuickForm-ElementGrid (xulchris) php-pear-HTML-Table (xulchris) php-pear-HTTP-Client (xulchris) php-pear-HTTP-Request (xulchris) php-pear-HTTP-Upload (xulchris) php-pear-Image-Canvas (xulchris) php-pear-Image-Color (xulchris) php-pear-Image-Graph (xulchris) php-pear-Image-GraphViz (xulchris) php-pear-Mail-Mime (remi) php-pear-Mail-mimeDecode (remi) php-pear-Math-Stats (xulchris) php-pear-MDB2-Driver-mysql (xulchris) php-pear-MDB2-Driver-mysqli (trasher) php-pear-MDB2-Driver-pgsql (trasher) php-pear-Net-Curl (xulchris) php-pear-Net-DIME (remi) php-pear-Net-DNS (moixs) php-pear-Net-FTP (remi) php-pear-Net-IPv4 (moixs) php-pear-Net-Ping (remi) php-pear-Net-POP3 (xulchris) php-pear-Net-Sieve (remi) php-pear-Net-SMTP (remi) php-pear-Net-Socket (remi) php-pear-Net-Traceroute (remi) php-pear-Net-URL (xulchris) php-pear-Net-URL-Mapper (xulchris) php-pear-Net-UserAgent-Detect (xulchris) php-pear-Numbers-Roman (xulchris) php-pear-Numbers-Words (xulchris) php-pear-Payment-Process (xulchris) php-pear-PEAR-Command-Packaging (timj) php-pear-PHP-CodeSniffer (icon) php-pear-PHP-Compat (remi) php-pear-PHP-CompatInfo (remi) php-pear-Services-Weather (remi) php-pear-Structures-DataGrid (xulchris) php-pear-Structures-DataGrid-DataSource-Array (xulchris) php-pear-Structures-DataGrid-DataSource-DataObject (xulchris) php-pear-Structures-DataGrid-DataSource-MDB2 (xulchris) php-pear-Structures-DataGrid-DataSource-RSS (xulchris) php-pear-Structures-DataGrid-Renderer-Pager (xulchris) php-pear-Structures-DataGrid-Renderer-Smarty (xulchris) php-pear-Text-Diff (xavierb) php-pear-Validate-Finance-CreditCard (xulchris) php-pear-Var-Dump (remi) php-pear-XML-Beautifier (xulchris) php-pear-XML-Parser (remi) php-pear-XML-RSS (xulchris) php-pear-XML-Serializer (xulchris) php-pear-XML-Util (xulchris) 73 packages php-pear-Auth_HTTP (topdog) php-pear-HTML_Javascript (topdog) 2 packages The first seems to be a "De facto" guidelines followed by all pear extensions packagers. Regards

1 0

Naming Scheme
by Christopher Stone 15 Jul '09

15 Jul '09

I've seen a couple php-pear packages come through the review pipes recently with underscores in their names like php-pear-HTML_Javascript[1] and php-pear-Auth_HTTP[2]. Shouldn't these have dashes instead of underscores in their names? I thought the naming guidelines suggested not using underscores? Have the rules changed? Regards, Chris [1] https://bugzilla.redhat.com/show_bug.cgi?id=508075 [2] https://bugzilla.redhat.com/show_bug.cgi?id=508082

2 1

Re: [php-maint] Bug#535770: PHP system timezone patch for 5.3?
by Joe Orton 15 Jul '09

15 Jul '09

Hi folks, I've attached "v5" of the system timezone patch, which is updated for 5.3.0. This contains the changes to parse zone.tab which I proposed in my previous mail, and should fix the crash reported in the Debian bug 535770. It seems to work fine though I have not tested it exhaustively. Further review and testing would be very welcome! Regards, Joe

1 1

[jorton@redhat.com: Re: [php-maint] Bug#535770: PHP system timezone patch for 5.3?]
by Joe Orton 14 Jul '09

14 Jul '09

Looks like I failed to CC that as intended, copying for the archives. ----- Forwarded message from Joe Orton <jorton(a)redhat.com> ----- From: Joe Orton <jorton(a)redhat.com> To: sean finney <seanius(a)debian.org> Cc: PHP Packagers <pkg-php-maint(a)lists.alioth.debian.org>, 535770(a)bugs.debian.org, judas.iscariote(a)gmail.com Date: Tue, 7 Jul 2009 10:10:06 +0100 Subject: Re: [php-maint] Bug#535770: PHP system timezone patch for 5.3? User-Agent: Mutt/1.5.18 (2008-05-17) Hi Sean - adding the Fedora PHP devel list to CC. Thanks for getting in touch. For Fedora folks, Sean has referenced this Debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535770 Quoting in full: On Tue, Jul 07, 2009 at 12:05:31AM +0200, sean finney wrote: > ...and hi again :) > > On Mon, Jul 06, 2009 at 10:51:40PM +0200, sean finney wrote: > > specifically timezone_identifiers_list() was extended to include country > > codes as a filter for the returned values and it doesn't look like this > > is covered by the patch and results in a segfault. > > looking a bit more at the specifics, it doesn't seem so desirable to have > to mmap and read every file to get all the country codes. here's some > options i see: > > - read all the files anyway. performance will be dismal but it's hopefully > a corner case except for someone running a public world clock app or > something :) > > - fall back to the internal timezonedb for listing country names. it would > be a bit ugly and there's maybe a possibility that timezone names might > get out of sync. > > - pre-cache the tzdata at install time (and make use of triggers to > catch updates to the tzdata files). nice performance but adds extra > complexity/dependencies outside of the engine. > > - use zone.tab for country code -> tzdata mapping? it seems to have the > info we'd want all in one file (assuming it's correct and consistant), > and we'd only have to read it in the specific cases that it was needed. > > - disable the api extension. not desirable. > > i guess zone.tab seems a nice easy and boring fix for this, what do you think? It looks like they are (as threatened) shipping a mutated version of the zoneinfo data in 5.3. Changes: 1) first four bytes are "PHP1" not "TZif" 2) in the "reserved" 16 bytes which follow, they have: ONE BYTE: "BC" flag TWO BYTES: country code ... those are being used by the code you mention above 3) after the end of the data, they have: TWO BYTES: latitude and longtitude ONE BYTE: length N (N) BYTES: "comment" Whereas we have the 64-bit TZif2 block at the end of the TZif data. I think that's everything that's different. The "BC" flag seems to be an indication that the zone name is a deprecated form, and it's the case that BC is 0 if and only if the country code is '??', otherwise BC is 1; with 'UTC' as a special-case (BC=1, code is '??'). I believe it is also the case that, other than UTC, there is a one-to-one mapping between zones *not* listed in zone.tab, and zones which PHP designates with country code '??' (and hence BC=0). zone.tab also has the lat/long data, and the country codes, so, yup, parsing that at startup seems to be the way to go. I'll have a crack at a patch later today hopefully. Regards, Joe ----- End forwarded message -----

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

php-devel July 2009