ssl-cert_1.0-10_i386.changes ACCEPTED
Accepted: ssl-cert_1.0-10.dsc to pool/main/s/ssl-cert/ssl-cert_1.0-10.dsc ssl-cert_1.0-10.tar.gz to pool/main/s/ssl-cert/ssl-cert_1.0-10.tar.gz ssl-cert_1.0-10_all.deb to pool/main/s/ssl-cert/ssl-cert_1.0-10_all.deb Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian.
Processing of ssl-cert_1.0-10_i386.changes
ssl-cert_1.0-10_i386.changes uploaded successfully to localhost along with the files: ssl-cert_1.0-10.dsc ssl-cert_1.0-10.tar.gz ssl-cert_1.0-10_all.deb Greetings, Your Debian queue daemon
Re: Bug#269757: apache-common: missing .info for mod_macro.so error during libapache-mod-php4 setup
Fabio Massimo Di Nitto wrote: Setting up libapache-mod-php4 (4.3.8-9) ... Error: mod_macro.so does not have a corresponding .info file. apache-common does not ship mod_macro.so or the info file. mod_macro is compiled in. Please check /usr/lib/apache/1.3/ for any mod_macro.so and move them somewhere. In any case that is a warning and not an error. It has been converted as such, a long time ago. Hi Fabio, I suspected this was a built-in module, whatever the jargon is. This workaround you've mentioned seems to have solved it; I checked after a restart and the module still seems to be listed in apache's list. Time to see now if anything breaks. :) I get the same error message when installing the latest apache 1.3.31-4 sarge package, *however* an error isn't reported by apache's setup. But as per above libapache-mod-php4 does, so setup doesn't complete. This is perhaps another bug related to php4 and i can't see why apache is at fault. In anycase the php4 maintainer reads the list. Perhaps. I guess now it's a case of trying to figure out who/what the heck installed the file in the first place? That raises a whole bunch of possibilities to me (though apache would be the prime -- though not the only -- suspect for me at this stage). Again, thanks for your answer. Cheers, Jonathan. -- Jonathan Ah Kit - Lower Hutt - New Zealand [EMAIL PROTECTED] - http://www.ah-kit.dropbear.id.au/ [EMAIL PROTECTED] - ICQ#9747234 - http://www.electric.gen.nz/ Away message: Looking for adhesive tape, not Alibrandi.
Re: Bug#269757: apache-common: missing .info for mod_macro.so error during libapache-mod-php4 setup
On Fri, 3 Sep 2004, Jonathan Ah Kit wrote: > I'm loathe to send in bug reports, but I've been asked to resubmit this as > apache-common or post to the debian-apache list (see #269738), and seeing > lists.debian.org says 'It is neither for submitting bug reports (please use > the BTS for that), nor for support requests', I'm resubmitting it. > > OK, here's the short of it: > > Setting up libapache-mod-php4 (4.3.8-9) ... > > Error: mod_macro.so does not have a corresponding .info file. apache-common does not ship mod_macro.so or the info file. mod_macro is compiled in. Please check /usr/lib/apache/1.3/ for any mod_macro.so and move them somewhere. In any case that is a warning and not an error. It has been converted as such, a long time ago. > I get the same error message when installing the latest apache 1.3.31-4 > sarge package, *however* an error isn't reported by apache's setup. But as > per above libapache-mod-php4 does, so setup doesn't complete. This is perhaps another bug related to php4 and i can't see why apache is at fault. In anycase the php4 maintainer reads the list. Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Bug#269757: apache-common: missing .info for mod_macro.so error during libapache-mod-php4 setup
Package: apache-common Version: 1.3.31-4 Severity: important Hi, I'm loathe to send in bug reports, but I've been asked to resubmit this as apache-common or post to the debian-apache list (see #269738), and seeing lists.debian.org says 'It is neither for submitting bug reports (please use the BTS for that), nor for support requests', I'm resubmitting it. OK, here's the short of it: > Setting up libapache-mod-php4 (4.3.8-9) ... > Error: mod_macro.so does not have a corresponding .info file. > The above errors might cause apache to not work properly or start > Please refer to the documentation on how to fix it or report it to > Debian Apache Maling List if in doubt > on how to proceed > dpkg: error processing libapache-mod-php4 (--configure): > subprocess post-installation script returned error exit status 20 [...] > Errors were encountered while processing: > libapache-mod-php4 [...] > E: Sub-process /usr/bin/dpkg returned an error code (1) I get the same error message when installing the latest apache 1.3.31-4 sarge package, *however* an error isn't reported by apache's setup. But as per above libapache-mod-php4 does, so setup doesn't complete. I see that as per the below posting to the debian-apache list someone's already posted about this 'problem', but with no reply. Like he says, is it possible I can just get or make up this .info file, or is it perhaps not a bug, or something else? > http://lists.debian.org/debian-apache/2004/08/msg00368.html Interestingly, despite the lack of a completed setup, my php4-based site http://greta.electric.gen.nz/gallery/ still runs for some reason. (Yes, I've restarted apache.) Like with my original bug report, if I've used the wrong forum, please advise. Cheers, Jonathan. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i586) Kernel: Linux 2.4.16-586tsc Locale: LANG=C, LC_CTYPE=C Versions of packages apache-common depends on: ii apache-utils1.3.31-4 Utility programs for webservers ii debconf 1.4.30 Debian configuration management sy ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libdb4.24.2.52-16Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii mime-support3.28-1 MIME files 'mime.types' & 'mailcap ii perl5.8.4-2 Larry Wall's Practical Extraction ii sed 4.1.2-1 The GNU sed stream editor ii ucf 1.07 Update Configuration File: preserv -- debconf information: * apache-common/confignotes: apache-common/old-logrotate-exists: apache-common/logs: apache-shared/debconf-modules: mod_userdir, mod_unique_id, mod_status, mod_setenvif, mod_rewrite, mod_negotiation, mod_mime_magic, mod_mime, mod_log_config, mod_headers, mod_expires, mod_dir, mod_cgi, mod_autoindex, mod_auth, mod_alias, mod_access, mod_php4 apache-shared/restart: false
RE: Bug#242543: More information
> Can you give us the patch directly since you have it working? I'm actually a little concerned that it might break something else! I've been working with a clean (non Debian) apache source, so it's really an upstream problem. What is their policy regarding regular bugs in 1.3? Are they still fixing them? It might be better to forward this to upstream - to somebody that knows mod_include better than me - and let them consider it. Carl GMG Regional Digital is part of the Guardian Media Group plc. CONFIDENTIALITY NOTICE. The information contained in this e-mail is intended only for [EMAIL PROTECTED], [EMAIL PROTECTED] It may contain privileged and confidential information that is exempt from disclosure by law and if you are not an intended recipient, you must not copy, distribute or take any action in reliance on it. If you have received this e-mail in error, you may notify us by telephone on 44 (0)161 832 7200. E-mail transmission cannot be guaranteed to be secure or error-free. The sender ([EMAIL PROTECTED]) therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
Bug#269377: apache: dselect-only upgrade
Package: apache Version: 1.3.31-4 Followup-For: Bug #269377 On two different "testing" boxes, both upgraded almost daily using only dselect, the last upgrade broke apache by removing the php4 module. When in dselect for upgrading, no changes to selected packages were made on either box, still somehow the php4 module was uninstalled. Manually installing the module fixed the problem (i.e., the config was fine). -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27nausicaa Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages apache depends on: ii apache-common 1.3.31-4 Support files for all Apache webse ii debconf 1.4.30.2 Debian configuration management sy ii dpkg1.10.23 Package maintenance system for Deb ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libdb4.24.2.52-17Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libmagic1 4.09-1 File type determination library us ii logrotate 3.7-2Log rotation utility ii mime-support3.28-1 MIME files 'mime.types' & 'mailcap ii perl5.8.4-2 Larry Wall's Practical Extraction -- debconf information: apache/server-name: localhost apache/document-root: /var/www apache/server-port: 80 * apache/enable-suexec: false apache/init: true apache/server-admin: [EMAIL PROTECTED]
is it true you two had sex last ngiht?
And seeming to whisper, "All is well!" Zenextend is an incredìble non-prescrìption herbàl formùla that has been shown to permanèntly ìncrease penìs sìze by an avèrage 1-2 ìnches in length and 1 ìnch in thickness! Your èrections will be ròck hard with ìncreased stamìna! Permànent gròwth, sàfe and effectìve rèsults. Bùy It Nòw http://jumbilo.com/9/4/index.php?ai=7411&com=35 Art from that Fund each just Supply provides, So by false Learning is good Sense defac'd. Loveliest of trees the cherry now Is hung with bloom along the bough A Fool might once himself alone expose, Now of my three score years and ten,twenty will not come again. Just as the moon rose over the bay, Not only bounded to peculiar Arts,
Re: Bug#242543: More information
On Fri, 3 Sep 2004, Carl Johnstone wrote: > > I've managed to track down why QUERY_STRING works and PATH_INFO doesn't. > > In src/modules/standard/mod_include.c around line 2181 mod_include fixes up > the QUERY_STRING. If I add similar code to fixup PATH_INFO ie: > > if (r->path_info) { >ap_table_setn(r->subprocess_env, "PATH_INFO", r->path_info); > } > > > Then it fixes my problem with PATH_INFO not being set correctly. > > I think what's happening is that mod_include is setting up the subrequest > using the values from the parent (main?) request. Then code has been > specifically added to correct the QUERY_STRING based on the subrequest, but > not the PATH_INFO. > > If I setup a mod_perl that looks up a URI and then runs the subrequest, it > behaves as I expect with the QUERY_STRING and PATH_INFO set according to the > subrequest. > > Carl Can you give us the patch directly since you have it working? Thanks Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.