RE: Proposed change to debian release system
My friend has a high volume mail server running spamassassin 2.31 Oops the spamassassin stopped working. Now I have 12,000 people angry with me. Take that to the bank. --luke > Scott Minns wrote: > I know this is no panacea, since in many cases, the maintainer cannot know > whether a package will perish at all (like when all spammers promptly give > up "advancing" their software, so a given version of spamassassin would > stay useful forever)... ;-) > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > >
install openwebmail interfere's with mysql-server install.
I recently encountered a potentail bug involving openwebmail and mysql-server. I wanted to know if anyone else could reproduce it. Result: Install openwebmail and modifyting DB_File as per directions in openwebmail and then installing mysql-server will prevent mysql-server from starting. Expected Result: Openwebmail should not interfere with mysql-server. Repro: Install openwebmail. Mody DB_File as per openwebmail directions. (see below) Install mysql-server. Start mysql-server. Mysql-server will not start, and does not give error. Remove change from DB_File. Remove mysql-server. Reinstall mysql-server. Mysql-server starts correctly. Package Information: Inst openwebmail (2.21-3 Debian:testing Inst mysql-server (4.0.16-2 Debian:testing) Openwebmail post install directions: /usr/share/doc/openwebmail/readme.txt I am assuming you need to add the listed line of code in DB_File.pm, if it does not exist. -- 2. it checks if the dbm system uses DB_File.pm by default and will suggest a necessary patch to DN_File.pm, you may see output like - Please modify /usr/libdata/perl/5.00503/mach/DB_File.pm by adding $arg[3] = 0666 unless defined $arg[3]; before the following text (about line 247) # make recno in Berkeley DB version 2 work like recno in version 1 --
Set up build environment.
I recently ported a testing package to stable. Did not have to make any changes to the package, just rebuilt it on a stable system. Here are the directions for setting up a stable build environment. Should be helpful to any who is starting off on setting up build environments. In the example I rebuild a testing perl program on a stable system, so I can install it on a stable system with perl 5.6.1 instead of 5.8.x. Please let me know if you find any gotcha's. I really appreciate any feedback. I want to help new developers get started. --Luke 1.20. setup debian for build root build mimedefang 2.38 example * debootstrap --verbose woody /root/woody-chroot http://repository/debian cp /etc/apt/sources.list /root/mimedefang-chroot/etc/apt/ mount -t proc /proc /root/woody-chroot/proc chroot /root/woody-chroot vi /etc/apt/sources.list, to include sources for stable only and a source for deb-src stable. need a testing deb-src for mimedefang. apt-get install build-essential devscripts lintian debhelper dh-make #normal vi annoys me apt-get install vim cd /usr/src/; mkdir mimedefang; cd mimedefang; apt-get install apt-get install libmilter-dev libunix-syslog-perl clamav apt-get source mimedefang dpkg-source -x mimedefang_2.38-2.dsc cd mimedefang-2.38 dpkg-buildpackage cd .. #Now I have a deb package called mimedefang_2.38-2_i386.deb If you exit the chroot and install the package via dpkg -i mimedefang #it wiill complain about dependencies but load the dependencies into the queue. #then apt-get install mimedefang #and it will download all of the dependencies. #dependencies installed #libdigest-sha1-perl libfreetype6 libio-stringy-perl libmailtools-perl libmime-base64-perl libmime-perl libnet-perl #libssl0.9.6 libtimedate-perl m4 sendmail tcl8.3 tk8.3 xfree86-common xlibs NOTE Their are not testing repositories listed repository so this cannot install any testing packages (Only testing src reposityr). Now you have installed mimedefang on a stable system, you need to manually add in the sendmail.mc change, and include support for the virus scanners you want to use. This works, I installed it and tested it. --Luke
RE: Proposed change to debian release system
Sorry, you are correct. I apologize for the error. > Lucas, not only did you horribly misquote my statement as coming from > Scott, but you also seem to not having read my mail thoroughly. Nowhere > did I suggest that installed packages stop working when "expired", did I? > Please re-read my suggestion.
Re: Bug#223772: general: no md5sums for many packages (e.g. bc)
> Re: Goswin von Brederlow in <[EMAIL PROTECTED]>
Why not set it so they are generated when a package is created?
Am I understanding correctly?
And then they could b gpg signed by the developer???
This adds one more check to the security of the system.
I used debsums just a few days to determine if a package was corrupt,
quite useful.
Is this something that would require maintainers to rebuild their
packages, or could the build machines do it?
--Luke
>
> They are not generated by apt/dpkg, so few people will actually build
> them. Since accidental corruption only occurs accidentally, it would be
> very convenient if the md5sums were already there if something crashes.
> Besides that, if the md5sums are in the package, you can check whether
> the installation went fine.
>
> I don't see where a text file with one line per file installed wastes
> more resources than {pick anything for a package you don't need, e.g.
> 95% of translated manpages, etc.}.
>
> Christoph
> Christoph Berg <[EMAIL PROTECTED]>, http://www.df7cb.de/
> Wohnheim D, 2405, Universität des Saarlandes, 0681/9657944
>
