Re: Bug#302827: tetex-bin: fails to install on several architectures
Dear release team, since I must go on vacaction for several weeks, and I'm unsure whether there is enough (wo)manpower on debian-tetex-maint to resolve this bug, I recommend that you keep a close look at it. All my activities so far are recorded in the bug log. I have tried to contact the buildd admins only by mailing to rian murray whose address is at the bottom of the build logs - probably you know better than I how to get in contact with the right people. In my opinion, the first step to resolve this should be to check what exactly is messed up in the build environments of the failing hosts, clean it up, and verify whether this is the cause of the bug. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer pgptPpDMAMwmT.pgp Description: PGP signature
Re: Fwd: apt-get dist-upgrade will remove metapackages
Le Mercredi 6 Avril 2005 00:22, Frans Pop a crit: Is the release team aware of this issue? Will migration to testing of the new vim be blocked automatically until this is solved? the problem is known, and already addressed (see #303266) in fact, the bug is already closed in the current svn [1]. and I guess an upload with a high priority (that won't hurt for such a package after all) should solve the problem in less than 2 days. [1] http://lists.alioth.debian.org/pipermail/pkg-kde-commits/2005-April/000774.html -- O Pierre Habouzit O OOOhttp://www.madism.org pgpJNyZnQRndi.pgp Description: PGP signature
Re: proposed fix to allow security support for fai-kernels in sarge (#297811)
Hi Steve, On Tuesday 05 April 2005 16:54, Steve Langasek wrote: To reiterate our discussion on IRC, I don't think this addresses my concerns, which are that: - Nothing in the package (binary or source) uniquely identifies the kernel-source patchlevel used (including the added ABI name, since ABI name != patchlevel) I've changed the build dependencies to kernel-tree-2.6.8-15 and kernel-tree-2.4.27-8 now. - Nothing in the source or binary package names matches the kernel.*2\.(4\.27|6\.8) regexp that I've been using so far to identify the kernel packages requiring attention I have no knowledge of how important the latter is to the security team; As it seems, it's not really important at least to Joey. they may not be bothered by it as long as they're aware that this package exists which doesn't follow the usual naming convention. (which I presume that after this thread, at least one member of the security team *is* aware of this.) Hmmm... the only mail address for stable security support on http://www.debian.org/intro/organization is [EMAIL PROTECTED] - [EMAIL PROTECTED] didnt seem appropriate to me. Would that have been a better address ? regards, Holger pgphBOp1hkGMt.pgp Description: PGP signature
Re: proposed fix to allow security support for fai-kernels in sarge (#297811)
Hi Joey, On Tuesday 05 April 2005 18:26, Martin Schulze wrote: Howto handle security fixes for fai-kernels --- fai-kernels uses the kernel-source-2.4.27 and kernel-source-2.6.8 packages. If these packages get updated with a security fix, fai-kernels needs to be rebuild. As just said in the other mail, this is not true anymore, fai-kernels now build-depends on the latest kernel-tree packages. The kernel-image-debs which are included in the fai-kernel package contain the kernel abi version in the included packages name. If the abi version changes, those abi version number has to be incremented in fai kernels control file as well. Oh great, so we need to consider FAI as another architecture. Another arch because it's another kernel package to watch for ? (I would just like to understand that sentence :) Since there are only two base source packages left over (many thanks to the kernel team), this should be doable. Great. So, AFAIU, the proposed fixes for #297811 are accepted by the stable security team. regards, Holger pgpNMzInpxcIe.pgp Description: PGP signature
libpng planned changes for etch
Here is a summary of the important changes I'm planning for libpng in etch. * Removal of the entire libpng source package: libpng2, libpng2-dev, libpng10-0, libpng10-dev. All applications currently linking to libpng 1.0 will have to be rebuilt against libpng 1.2. As sarge's libpng packages include symbol versioning, it can be done smoothly. Some packages will temporarily depend indirectly on both versions, but they shouldn't be broken. * Removal of the libpng3 binary package, as only 2 packages in sarge still depend on this one. Maybe we can keep it, though, as some third-party binaries could require libpng.so.3. * Removal of the libpng3-dev binary package, adding a Provides: in libpng12-dev. I believe autobuilders can cope with such a change, as they are already dealing with packages build-depending on libpng-dev, which is a virtual package. * Removal of the private symbols that are exported in the library. This can break some applications directly using these private symbols. Which means: it shouldn't happen, but you never know how software authors can have stupid ideas. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposed fix to allow security support for fai-kernels in sarge (#297811)
Holger Levsen wrote: On Wednesday 06 April 2005 12:42, Martin Schulze wrote: Hmmm... the only mail address for stable security support on http://www.debian.org/intro/organization is [EMAIL PROTECTED] - [EMAIL PROTECTED] didnt seem appropriate to me. What's wrong with that address? The reason to have filed #297811 is to be able to do stable security support. So I choose the address for stable security support. debian-security-private@ seemed to me like a mail-address to address general security problems or security problems which should remain undisclosed until they are solved. Would that have been a better address ? Yes. Ok. So if debian-security-private@ is also responsible for stable security maybe it would be a good idea to add the address there. (As I also think it's not really perfect that only your personal mail address is listed for stable security support...) Huh? In which universe do you live? Not in one where the Debian Security Team is responsible for security updates in the stable Debian release apparently. (I guess you mixed Security Team with Release Manager for ``stable''.) ((Since at the moment, it's both me, it does not matter currently, but that doesn't have to be the case all the time...)) Regards, Joey -- GNU GPL: The source will be with you... always. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: woody-sarge upgrade removes perl (and a bunch of other stuff)
On Wed, Apr 06, 2005 at 04:09:08PM +0200, Wichert Akkerman wrote: I just looked at upgrading a server from woody to sarge and the result was, well, interesting. The output from apt-get -o Debug::pkgProblemResolver=true dist-upgrade starts off with: Investigating perl Package perl has broken dep on libterm-readline-perl-perl Considering libterm-readline-perl-perl 0 as a solution to perl 102 Removing perl rather than change libterm-readline-perl-perl Some first notes: - I can easily reproduce this in a woody chroot by installing the following packages: apache apache-common console-tools-libs cricket defoma gs gs-common gsfonts libapache-mod-auth-pam libapache-mod-ssl libchart-perl libdbd-mysql-perl libdbi-perl libdigest-md5-perl libgd-perl libhtml-format-perl libhtml-parser-perl libhtml-tagset-perl libhtml-tree-perl libmailtools-perl libmd5-perl libmime-base64-perl libnet-perl libnet-ph-perl libnet-snmp-perl libnet-snpp-perl libnet-telnet-perl librrds-perl libsnmp-session-perl libtime-hires-perl libtimedate-perl liburi-perl libwww-perl libxml-parser-perl mailman mysql-client perl perl-modules perl-suid php4 php4-mysql phpmyadmin psfontmgr python-bobodtml python-xmlrpc w3m-ssl imagemagick lesstif1 librrd0 ntp ntp-simple sqsh wenglish xlibs (so it doesn't have anything to do with the installed apache2 backport or other system specific problems ...) - It is a apt-get bug only, aptitude handles the same situation just fine. But both apt-get from woody and sarge bail out. - I have really _no_ idea how apt-get finds a dependency between perl and libterm-readline-perl-perl. All I can see is a suggests and apt shouldn't care about that at all... Can someone more firm with apt's interna offer a way to find that out? Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libpng planned changes for etch
Josselin Mouette [EMAIL PROTECTED] writes: * Removal of the libpng3 binary package, as only 2 packages in sarge still depend on this one. Maybe we can keep it, though, as some third-party binaries could require libpng.so.3. I get rather a longer list from apt-get rdepends; which two are you speaking of? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: woody-sarge upgrade removes perl (and a bunch of other stuff)
On Wednesday 06 April 2005 11:26 am, Frank Lichtenheld wrote: - It is a apt-get bug only, aptitude handles the same situation just fine. But both apt-get from woody and sarge bail out. That's really weird, because aptitude does nearly the same thing as apt-get when calculating upgrades. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | Microsoft, n: | | A company that makes pretty good mice. | \ Evil Overlord, Inc: http://www.eviloverlord.com --/ pgpQQZ9r2Psjf.pgp Description: PGP signature
Re: proposed fix to allow security support for fai-kernels in sarge (#297811)
Hi, btw, no need to cc: me, i'm subscribed to release, the bug and the package :-) On Tuesday 05 April 2005 16:54, Steve Langasek wrote: - Nothing in the package (binary or source) uniquely identifies the kernel-source patchlevel used (including the added ABI name, since ABI name != patchlevel) as we now have build depends on the kernel-tree packages including the patchlevel, the abi-name in the included debs (and therefore also touching the rules file on security updates) is not needed any more, right ? regards, Holger pgpMWdmF4GTiA.pgp Description: PGP signature
Re: woody-sarge upgrade removes perl (and a bunch of other stuff)
On Wed, 6 Apr 2005, Frank Lichtenheld wrote: - It is a apt-get bug only, aptitude handles the same situation just fine. But both apt-get from woody and sarge bail out. Is apt-get a supported upgrade route from Woody to Sarge? The release notes [1] recommend using aptitude instead. [1] http://www.debian.org/releases/testing/alpha/release-notes/ch-upgrading.en.html#s-upgrade-process --Andre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposed fix to allow security support for fai-kernels in sarge (#297811)
resent as I go the debian-security-private-address wrong, please follow reploy-to: Hi, btw, no need to cc: me, i'm subscribed to release, the bug and the package :-) On Tuesday 05 April 2005 16:54, Steve Langasek wrote: - Nothing in the package (binary or source) uniquely identifies the kernel-source patchlevel used (including the added ABI name, since ABI name != patchlevel) as we now have build depends on the kernel-tree packages including the patchlevel, the abi-name in the included debs (and therefore also touching the rules file on security updates) is not needed any more, right ? regards, Holger pgpxj4WRPe3oV.pgp Description: PGP signature
Re: woody-sarge upgrade removes perl (and a bunch of other stuff)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre Lehovich wrote: On Wed, 6 Apr 2005, Frank Lichtenheld wrote: - It is a apt-get bug only, aptitude handles the same situation just fine. But both apt-get from woody and sarge bail out. Is apt-get a supported upgrade route from Woody to Sarge? The release notes [1] recommend using aptitude instead. [1] http://www.debian.org/releases/testing/alpha/release-notes/ch-upgrading.en.html#s-upgrade-process The recommended route is not the only one. I (and probably a lot of users) expect apt-get dist-upgrade and even dselect or synaptic to work. Cheers Luk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCVBrh5UTeB5t8Mo0RAnraAKCXcunwf67kXocT1sXMrgsQsZXaRACgzn9I AyztUZICPzofSzt2iEw9vUk= =oLyt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: woody-sarge upgrade removes perl (and a bunch of other stuff)
On Wed, Apr 06, 2005 at 07:22:41PM +0200, Luk Claes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre Lehovich wrote: On Wed, 6 Apr 2005, Frank Lichtenheld wrote: - It is a apt-get bug only, aptitude handles the same situation just fine. But both apt-get from woody and sarge bail out. Is apt-get a supported upgrade route from Woody to Sarge? The release notes [1] recommend using aptitude instead. [1] http://www.debian.org/releases/testing/alpha/release-notes/ch-upgrading.en.html#s-upgrade-process The recommended route is not the only one. I (and probably a lot of users) expect apt-get dist-upgrade and even dselect or synaptic to work. This is not the only reason for preferring aptitude over apt-get for upgrades; there have been a number of upgrade issues that aptitude handles better than apt-get where it's not clear that this can be considered a bug in apt-get. In this case, OTOH, there seems to be a real bug in the handling of libterm-readline-perl-perl. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: proposed fix to allow security support for fai-kernels in sarge (#297811)
On Wed, Apr 06, 2005 at 07:18:06PM +0200, Holger Levsen wrote: On Tuesday 05 April 2005 16:54, Steve Langasek wrote: - Nothing in the package (binary or source) uniquely identifies the kernel-source patchlevel used (including the added ABI name, since ABI name != patchlevel) as we now have build depends on the kernel-tree packages including the patchlevel, the abi-name in the included debs (and therefore also touching the rules file on security updates) is not needed any more, right ? That's correct. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#302827: tetex-bin: fails to install on several architectures
reassign 302827 jadetex thanks On Wed, Apr 06, 2005 at 09:10:28AM +0200, Frank Küster wrote: since I must go on vacaction for several weeks, and I'm unsure whether there is enough (wo)manpower on debian-tetex-maint to resolve this bug, I recommend that you keep a close look at it. All my activities so far are recorded in the bug log. I have tried to contact the buildd admins only by mailing to rian murray whose address is at the bottom of the build logs - probably you know better than I how to get in contact with the right people. In my opinion, the first step to resolve this should be to check what exactly is messed up in the build environments of the failing hosts, clean it up, and verify whether this is the cause of the bug. Yeah, the architectures that failed to build pdns previously have all successfully built the subsequent version of it. I suspect this isn't a tetex-bin bug at all, so am downgrading it. One of the more suspicious lines in the log of the build failures is Error: `etex -ini -jobname=jadetex -progname=jadetex latex jadetex.ini' failed This happens during the setup of tetex-bin, *before* jadetex has been configured; so I think this is actually a bug, probably historic, in jadetex, which seems to have left config files around incorrectly on purge. Reassigning to jadetex accordingly for further investigation; hopefully this is a known bug in previous versions of jadetex that have since been fixed. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature