Bug#668556: ITP: dparser -- a scannerless GLR parser generator
Package: wnpp Severity: wishlist Owner: Markus Wanner * Package name: dparser Version : 1.26 Upstream Author : John Bradley Plevyak * URL : http://dparser.sourceforge.net/ * License : BSD Programming Lang: C and Python Description : a scannerless GLR parser generator DParser is a scannerless GLR parser generator based on the Tomita algorithm. It is self-hosted and very easy to use. Grammars are written in a natural style of EBNF and regular expressions and support both speculative and final actions. There's an archived RPF for dparser: #248589 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120412200052.27786.45336.report...@argodan.intranet.bluegap.ch
Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator
Dear Charles, On 04/14/2012 05:37 AM, Charles Plessy wrote: > I would like to suggest to explicit the "GLR", "RPF", and perhaps "EBNF" > acronyms in the long description. Thanks for your suggestions. GLR means "Generalized Left-to-right Rightmost deviation parser" or maybe "Generalized LR parser". EBNF is the Extended Backus–Naur Form. Acronyms like these - i.e. LL, LL(k), SLR, LALR - are pretty common when talking about parsers. RPF is actually a typo, I meant to point to the archived Request For Packaging (RFP) bug in Debian, see here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248589 That last sentence isn't meant to be part of the long description of the package. I wasn't sure how to make that clear. Regards Markus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f89392d.2060...@bluegap.ch
Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator
Hi, On 04/14/2012 11:22 AM, Jakub Wilk wrote: > Sure, they are also much more common than GLR. And if you are "just" > interested in parsing and not a computer scientists, there's a chance > you've never heard about any of them. Based on two votes for extending the acronyms, I propose to change the long description as follows: DParser is a scannerless, generalized left-to-right, rightmost deviation (GLR) parser generator based on the Tomita algorithm. It is self-hosted and very easy to use. Grammars are written in a natural style of extended Backus-Naur form (EBNF) and regular expressions and support both speculative and final actions. I'm not a native speaker, so please feel free to comment on spelling, grammar, comma or other errors. Regards Markus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f895c10.4050...@bluegap.ch
Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator
On 04/14/2012 01:12 PM, Adam Borowski wrote: > I can't really imagine someone writing a parser using such tools without > having heard these acronyms first, though. And I'd risk saying they are > actually more widely known than their expansions. Yeah, that's why I think the acronyms must be included in the long description as well. But it cannot hurt to provide the expansion. At best, it might even increase the number of people who actually know what the acronyms stand for (Although I - for example - am not sure I'm able to remember the GLR one...). ;-) Regards Markus Wanner -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f896a8d.3020...@bluegap.ch
Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator
Hi, On 04/14/2012 02:12 PM, Tollef Fog Heen wrote: > I've written parsers (using bison, though) and can't recall having heard > the term GLR parser before. Maybe I'm unique in that respect, but I > doubt it. Note that bison also supports building GLR parsers. That's a somewhat recent addition, IIRC. http://www.gnu.org/software/bison/manual/html_node/GLR-Parsers.html#GLR-Parsers Regard Markus Wanner -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f89746b.6020...@bluegap.ch
Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator
Dear Debian developers, On 04/15/2012 04:15 AM, Miles Bader wrote: > In my experience, "EBNF" and "LL"/"SLR"/"LALR" are widely known (they > are "classic compiler terms"), for the type of person who might be > interested in parser generators, but "GLR" isn't. Thank you all for your feedback on the long description. I've completed packaging now and sent out an RFS here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668966 Please go after sponsoring as eagerly as you discussed the long description. ;-) Regards Markus Wanner -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f8bb6ab.4000...@bluegap.ch
Re: Bug#701964: RFP: python-v8 -- python interface for the v8 javascript engine
Joost, On 03/01/2013 09:51 AM, Joost Yervante Damad wrote: >Package name: python-v8 > Version: 1.0-preview-r446 > Upstream Author: Xiaohai Lu > URL: http://code.google.com/p/pyv8/ > License: APL2.0 > Description: python interface for the v8 javascript engine I took a quick look. Using the plain setup.py distutils based build script, a build automatically checks out v8 and gpy (via svn). Both of these are packaged for Debian already. From a manageability and security standpoint, it's not feasible for python-v8 to "include" v8 (or gpy), but it should rely on libv8 as provided by Debian. That, however, doesn't seem feasible because pyv8 interfaces with v8::internal, a namespace that's not (or not completely) exposed by libv8 - for good reasons, as its name suggests. Thus, I'd currently argue that the upstream package isn't up to Debian standards. I considered, but decided against (trying to) package this piece of software. However, I'm a) not a DD and b) maybe others find a way to make libv8 work with python-v8. Regards Markus Wanner -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5133a41b.6080...@bluegap.ch
RFC: courier-webadmin
Hi, as the currently maintainer of courier [0], I'd like some advice from more experienced DDs. I'm currently considering to drop the binary package courier-webadmin from the packaged courier suite due to security concerns. This is a CGI binary allowing web based configuration of the Courier MTA. To modify the configuration and restart the server(s), it needs to be setuid root. Security measures in place: * the package warns about risks with setuid binaries and the user explicitly needs to enable the feature (it simply doesn't work if the user denies though - rendering the installation of the package pointless) * the setuid binary is a tiny (72 lines) C program that drops permissions and invokes a Perl script * the Perl script by default only serves requests that are either originating from the local host *or* which are SSL encrypted Concerns: * to save changes, the C wrapper does not drop permissions, but invokes the Perl script directly with root rights. * a reverse proxy happily forwards HTTP requests appearing as local to the CGI script, thus potentially circumventing this barrier. * the user normally used is the same that runs the MTA or IMAP server, i.e. user 'courier'. Meaning even in dropped privileges mode, the Perl script has all the rights the MTA or IMAP server have. * the password is stored and transported in plain text * the password gets stored in plain text in a cookie on the user's browser * lack of any audit traces of who changed what or when * upstream's INSTALL reads: "This is not Fort Knox, and webadmin is not going to be publicly accessible, so the only needed security is to keep everyone out except for authorized IP addresses." This is inspired by discussions with a disappointed user providing valuable feedback (in combination with somewhat less valuable feedback and in English sentences I have a hard time to understand) [2], [3]. If I'm going to drop this binary package, is a warning in NEWS enough (in courier-base, a dependency), or shall I better provide an empty shim package that actually removes the setuid binary (when upgraded)? I've clearly neglected this package for too long already and have requested an RFH as well [1]. And yes, this left some users unhappy and they are rightfully frustrated. Dropping support for courier-webadmin might not help that, either. And wastes all the effort of previous maintainers. However, I clearly don't feel comfortable maintaining *that* part of courier. Thoughs? Comments? Recommendations? Best Regards Markus [0]: https://tracker.debian.org/pkg/courier [1]: RFH: courier bug: https://bugs.debian.org/978755 [2]: https://salsa.debian.org/debian/courier/-/merge_requests/9 [3]: https://bugs.debian.org/341205
Re: PIE and static libraries
On 09/12/2016 01:47 AM, Bálint Réczey wrote: > I have opened a bug to encourage PIC for static libraries in Policy, too.: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837478 Thanks, cool. Is there any specific reason for not mentioning -fPIE in that request? That seems like a good middle-ground for static libraries. Reading up on the subject so far, I got the impression that most static libraries should be built with PIE, but not necessarily PIC (to allow building PIE(xecutable)s, but discourage creating shared libraries from those static ones.) To be honest, I didn't really check any use-case other than libsimgear-dev, which I'm concerned about. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Re: PIE and static libraries
On 09/12/2016 01:42 PM, Jakub Wilk wrote: > * Bálint Réczey , 2016-09-12, 13:21: >>> Reading up on the subject so far, I got the impression that most >>> static libraries should be built with PIE, but not necessarily PIC >>> (to allow building PIE(xecutable)s, but discourage creating shared >>> libraries from those static ones.) > > How does it discourage creating shlibs? AFAIUI it's impossible to build a PIC-enabled shared library from a PIE-enabled static one. That may be an intentional effect (from a packager's view). Granted, building a non-PIC shared library would still be possible from that static library, I guess, so this isn't bullet-proof. However, using a static library to build a shared one hopefully isn't a terribly frequent use case, anyways (in most cases you should better just use the original shared library). (This argument had nothing to do with shipping shared vs static libraries in Debian packages, nor the fact that we often have to compile things twice.) I guess my point mainly is that for static libraries, I currently see valid use cases for all of the three variants: no-nothing-enabled, PIE and PIC. Justification for the first case seems to vanish with time, while the policy currently mandates it (modulo discussion on this list). Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Re: Looking for new Debian maintainers for courier-mta packages
Hi, it's certainly a bit late, but I'd like to adopt the courier mta packages, as stated in the wnpp bugs. (Stumbled over this old mail only today.) On 12/06/2016 03:04 PM, Ondřej Surý wrote: > I have filled RFH (Request for Help) bug on courier package, but nobody > responded so far. Today I have changed that to RFA (Request for > Adoption) and I intend to properly orphan the packages before stretch > release and remove them from next Debian stable release. Well, unless > somebody comes up and makes a hard promise to take care of all Courier > MTA till Debian stretch (next stable) end-of-life and becomes > maintainers. Well, that's hard to promise, but I'll try to get courier ready for stretch, in the first place. If that effort isn't successful, it should better be dropped from stretch. > Please note that the bug list on src:courier is rather long: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=courier > (143 filled bugs) and it will need some time to comb through the list, > close the non-issues, fix the Debian related bugs and forward the > appropriate bugs to upstream. I would suggest it might be better this > would be a team effort. While I'm a long-time courier user and DD, I clearly don't qualify as a team. I'd certainly appreciate help and would instantly hand over maintenance to one. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
