Re: Bug#419111: context: Fails to install: ctxfmtutil: line 12: kpsewhich: command not found
Dear release people, I think you know best how to contact buildd admins. Reversing the order of what Kurt Roeckx [EMAIL PROTECTED] wrote: http://buildd.debian.org/fetch.cgi?pkg=dfsbuildver=1.0.0arch=amd64stamp=1176485127file=log This one was probably attempted after the first one? No wonder. It's just that removal of texlive-nearlyeverything failed, and now dpkg thinks the files are still present, while they aren't. Now that the debhelper change has been reverted, we can't rebuild texlive with fixed tex-common. We need to upload a reverted tex-common, and then rebuild texlive. Until this has happened, buildds should be prevented to install texlive if that is possible, and the buildds need to be fixed. I think they will even fix themselves as soon as they once installed and then purged a working version. Thanks. The following is only interesting to the bug in Cc: It happened after I got those 2 buildd log: http://buildd.debian.org/fetch.cgi?pkg=frown;ver=0.6.1-6;arch=amd64;stamp=1176485011 This one doesn't show any bug except the removal ones, which are due to the debhelper change. And it shows a strange thing, namely that context is installed at all - I think we've got some dependencies wrong, but I don't see it. Hm, or it's a problem with the buildd log: the commandline in the buildd log installs only texlive packages, but actualy tetex-bin is installed, too. And that pulls in context. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Bug#419111: context: Fails to install: ctxfmtutil: line 12: kpsewhich: command not found
On Sat, Apr 14, 2007 at 08:56:28AM +0200, Frank Küster wrote: Dear release people, I think you know best how to contact buildd admins. Reversing the order of what Kurt Roeckx [EMAIL PROTECTED] wrote: http://buildd.debian.org/fetch.cgi?pkg=dfsbuildver=1.0.0arch=amd64stamp=1176485127file=log This one was probably attempted after the first one? No wonder. It's just that removal of texlive-nearlyeverything failed, and now dpkg thinks the files are still present, while they aren't. Yes, the 2 logs were after each other. Now that the debhelper change has been reverted, we can't rebuild texlive with fixed tex-common. We need to upload a reverted tex-common, and then rebuild texlive. Until this has happened, buildds should be prevented to install texlive if that is possible, and the buildds need to be fixed. I think they will even fix themselves as soon as they once installed and then purged a working version. What happens if we do install texlive other then it breaks on removal? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
fix for 418284 for etch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I have prepared a fix for the bug 418284 for etch. I think this fix
should be included since:
- - initial installations over pppoe might hit this bug
- - the fix is non-intusive and that trivial that would be a shame not
to have it
I have prepared a package for stable which is available at:
http://users.alioth.debian.org/~eddyp-guest/darcs/ppp-etch/
The diff relatively to the stable version is (broke by wrapping):
diff -ruN ../official/ppp-2.4.4rel/debian/changelog
ppp-2.4.4rel/debian/changelog
- --- ../official/ppp-2.4.4rel/debian/changelog 2007-04-10
11:03:01.0 +0300
+++ ppp-2.4.4rel/debian/changelog 2007-04-14
14:06:59.0 +0300
@@ -1,3 +1,10 @@
+ppp (2.4.4rel-8etch1) stable; urgency=low
+
+ * ppp-udeb: quote username and password in pap/chap secrets since
they
+might contain special characters (Closes: 418284)
+
+ -- Eddy Petrișor [EMAIL PROTECTED] Sat, 14 Apr 2007
14:05:44 +0300
+
ppp (2.4.4rel-8) unstable; urgency=high
* urgency high since fixes an RC bug
diff -ruN ../official/ppp-2.4.4rel/debian/ppp-udeb.postinst
ppp-2.4.4rel/debian/ppp-udeb.postinst
- --- ../official/ppp-2.4.4rel/debian/ppp-udeb.postinst 2007-04-10
11:03:01.0 +0300
+++ ppp-2.4.4rel/debian/ppp-udeb.postinst 2007-04-14
14:03:41.0 +0300
@@ -273,7 +273,7 @@
chmod 600 /etc/ppp/pap-secrets
cat EOF /etc/ppp/pap-secrets
#GENERATED-BY-DEBIAN-INSTALLER#
- -$USERNAME * $PASSWORD
+$USERNAME* $PASSWORD
EOF
cp /etc/ppp/pap-secrets /etc/ppp/chap-secrets
The package built fine on my machine and the same fix was tested on
an unstable machine (while the stable and unstable versions started
to diverge now with this fix).
Here is the debdiff output relative to the newly uploaded version in
unstable.
debdiff ppp_2.4.4rel-8etch1_amd64.changes
../ppp-eddyp-dev/ppp_2.4.4rel-9_amd64.changes
File lists identical (after any substitutions)
Control files of package ppp: lines which differ (wdiff format)
- ---
Version: [-2.4.4rel-8etch1-] {+2.4.4rel-9+}
Control files of package ppp-dev: lines which differ (wdiff format)
- ---
Version: [-2.4.4rel-8etch1-] {+2.4.4rel-9+}
Control files of package ppp-udeb: lines which differ (wdiff format)
-
Version: [-2.4.4rel-8etch1-] {+2.4.4rel-9+}
Installer-Menu-Item: [-17-] {+1700+}
The 17 - 1700 change is unstable specific.
One question, is stable ok as a distribution in this case?
- --
Regards,
EddyP
=
Imagination is more important than knowledge A.Einstein
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGIMvAY8Chqv3NRNoRAgsyAKDEji0MrWY/16WeP9YD5qB9/FwTRwCgkSOe
mGEis6XHZCSvBPgzRqZ0VXw=
=j8zb
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hints for packages with udebs
Frans Pop wrote: On Friday 13 April 2007 14:18, Frans Pop wrote: I could not check if those packages may be blocked from migrating for other reasons because p.qa.d.o is currently unreachable. Correction: it was a problem on my side; AFAICT all packages should be OK to migrate. All unblocked. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Upstream version freeze for Debian
On Fri, Apr 13, 2007 at 09:06:17AM +0200, Raphael Hertzog wrote: On Thu, 12 Apr 2007, Aurelien Jarno wrote: Basically it looks ok. What about the freeze period for the toolchain? I think we usually suffer for a too early freeze of the glibc (it has been frozen in July for Etch, even if it has been unblocked a lot of time after). In my opinion, it would be better to freeze the upstream version at that time and allow minor update until the main freeze. Agreed. Ubuntu uses this technic and it's called UVF for Upstream Version Freeze. Most regressions come from new upstream version and only a small percentage come from maintainer changes. I don't think the percentage is that small; packages with responsible upstreams who make careful stable releases seem to be compensated for by maintainers who happily introduce regressions of their own. ;) We avoided having an upstream version freeze for etch simply because the correlation between upstream version numbers and changes that didn't comply with the freeze guidelines was a weak one. I think it's fine to have this as a heuristic, but the version numbers really were not the major concern. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why was etch released as stable if it still has bugs?
[debian-release is not a discussion list; cc:ing to debian-project, please respect M-F-T (if mutt doesn't eat my setting again).] On Tue, Apr 10, 2007 at 05:22:46AM -0700, Seth Lang wrote: By definition I thought release-critical to mean that it was critical for these bugs to be fixed before the release can happen. If they are not release-critical why label them as such. I thought that it was part of debian's high standards (which make debian the distro of choice for many) to not release a stable distro if it had bugs that are considered as serious or grave. Or what is the REAL definition of release-critical? If the bugs are not critical for a stable distro to be released why label them as such (defeats the purpose). By default, any bug of severity: serious or higher is treated as release-critical. In various cases, exceptions are made. For the bugs of severity: serious or higher that were still present in etch at the time of release, a deliberate decision was made to release with those bugs because we were confident that etch was already of higher quality than sarge -- many of the RC bugs that were fixed for etch were actually present in sarge but never documented as such, and while it would be nice to have zero known security bugs at the time of a release, the supply of security bugs is being constantly replenished, so it doesn't make any sense to hold out for a perfect score. For the remaining non-security 5 RC bugs in etch at the time of release, holding out for bugfixes before etch r0 would have meant delaying the release for at least two weeks for the simplest of these, in a best-case scenario assuming everyone was available to finish the release at that point; and these bugs were variously unreproducible, of debatable severity, not regressions from sarge, or the appropriate fix is in doubt, such that fixing all 5 would more than likely require a full month or more before we would be ready to try for a release again. When all of these bugs are candidates for fixing in etch r1, it doesn't make sense to further delay the release when doing so means stable users would continue to use sarge, which we were confident we had already surpassed in quality. I'm only pointing out that it doesn't help with user confidence when a distro releases under the name stable when it admits to still having several release-critical bugs at the time. release-critical is, by definition, something that blocks the release. Since these bugs did not block the release, they were not release-critical; so what you're seeing is misleading statistics. But as you can see from: http://www.debian.org/Bugs/Developer#severities for a bug to be release critical means that the package is either critical, grave, or serious. Furthermore, the same document also states that a package maintainer can tag the package as etch-ignore Er, no, it doesn't say this, nor should it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org plans for the lenny cycle
On Fri, Apr 13, 2007 at 11:06:19AM +1000, Drew Parsons wrote: Marc 'HE' Brockschmidt enquired: The release team is currently working on a schedule for the lenny release cycle. For that, we want to gather some data from the bigger software packaging teams in Debian first. We would like to know which major upstream versions of X.org are expected to be released in the next 24 months and how much time you expect them to need to get stable enough for a Debian stable release. Our current, very rough plans would mean a release in 18 months, which would be in October 2008. We expect to shuffle this a bit around to fit everyone's needs, so please tell us if this date works for you. As I see it, there are three major developments going on in X.org at the moment. 1) active probing of video cards to allow a more dynamic setting and resetting of video modes used. This work is mostly complete already (available in experimental xserver-xorg-video-intel, soon to appear in unstable). To expand on Drew's excellent summary further, there is support in a development branch for the -ati driver for this as well, but it's not ready yet. I expect it to be ready in time for lenny. Nouveau, the replacement for -nv, which is in development will also have support for this, which covers all the major chipsets in use today. I wouldn't be surprised if we see several other drivers that are being actively maintained use this. As it is, this goal is flexible, and we'll ship the best support that's available when lenny is ready. For any chips that aren't ready, they can use the current architecture we already have in place. 2) Support for input-hotplug. As with the dynamic modesetting in 1), this allows for dynamic plugging in of X-related devices. Currently being developed on the master X.org branch, should be ready in X11R7.3 by June or July. It's not clear what's goin on with this. The implementation requires a daemon which talks to HAL via dbus and lets the X server know when a device changes. Currently, there's a prototype implementation in C written by Daniel Stone, which isn't really meant for production use. There's also an implementation in Python written by a Gentoo developer which is probably also not ready. Once we get 7.2 in to unstable, we'll have to make a more serious run at this. Even if it's not ready to turn on by default though, I plan to follow upstream and set the default mouse to /dev/input/mice, which will solve most problems and simplify things for our users. So either way, the release team shouldn't have to worry about things from this end. Expect to see more from us on it in the coming few months though. 3) More generally, making /etc/X11/xorg.conf completely redundant. I believe this will not be achieved under 2), but is a longer term goal. I'm actively working on this with upstream, albeit slowly. The infrastructure is in place to run without a xorg.conf completely, but it doesn't work properly when you have to change something. I'm in the process of making this work so that we can ship without a xorg.conf, or with a minimal one that only changes what the user needs. The exact shape of this by the end of the lenny cycle isn't really possible to predict (and it depends on the improved resolution stuff in item 1) but we can at least whittle away at this as the lenny cycle goes on so that we don't cause any disruptions to the release while making the improvements. As you can see, X.org's broad aims at the moment are to improve usability by enabling the Xserver to be configured automatically without user intervention. X.org is striving to keep to a relatively strict six month release cycle, I would imagine six months is sufficient time for us to stabilise X for the release of Lenny. So with a goal of Oct 2008 we would expect to include X11R7.4, which should have been released around Feb or Mar 2008. This would include the new input-hotplug features. One thing the XSF needs to do is actively build the packaging infrastructure for the input-hotplugging. I'm not sure exactly how long this will take, but I don't imagine that it will be too difficult. A long-standing bug which should be thought about is the GL licensing problem [1]. SGI kindly contributed code for GL support in X, but their licence is not DSFG. Upstream is not comfortable with the situation either and there have been intentions to approach colleagues at SGI to see about rationalising the licence, to the common X11 licence or otherwise. However these correspondences proceed at a glacial corporate rate - not high on corporate SGI's TODO list, you might say. We've conveniently been ignoring the problem for Debian stable, do we continue doing so, or are we capable of prodding SGI to accelerate the discussions? Or do we ditch OpenGL support from Debian... ? These are a real thorn in our sides. Another issue is the nvidia code obfuscation bug, which we can fix when we get nouveau in
Re: mutt/1.5.13-3 for etch r1?
At 1176460173 time_t, Christoph Berg wrote: I would like to upload the mutt version now in unstable (1.5.13-3) to etch. The only change [*] is a fix pulled from upstream that resolves a bug that prevents mutt from successfully re-logging into an imap connection that has timed out (e.g. while the user was editing a mail). The current version will just hang on attempting to reconnect, the fixed one still requires logging in again, but will succeed. Is that ok for a stable update? (If so, propagating the unstable version to p-u is ok.) Even if I think it should be fine, unfortunately, point release are about RC bugs. Not sure annoying bug would be considered as RC.. :-/ Cheers, -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
Request of binNMUs for the libpq4 - libpq5 transition
Hi Can someone please schedule binNMUs for the libpq4 to libpq5 transition once libpq5 (postgresql-8.2) is built everywhere? Cheers Luk signature.asc Description: OpenPGP digital signature
Re: fix for 418284 for etch
At 1176554433 time_t, Eddy Petrișor wrote: I have prepared a fix for the bug 418284 for etch. I think this fix should be included since: - initial installations over pppoe might hit this bug - the fix is non-intusive and that trivial that would be a shame not to have it So small, ok from my point of view. Cheers, -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
Re: Request of binNMUs for the libpq4 - libpq5 transition
On 2007-04-14 Luk Claes [EMAIL PROTECTED] wrote: Can someone please schedule binNMUs for the libpq4 to libpq5 transition once libpq5 (postgresql-8.2) is built everywhere? Hello, wouldn't it be better to wait until libpq5 is in testing? Otherwise a (newly found) rc-bug in libpq5's source would add more than a 100 packages out-of-sync in testing and sid. cu and- OTOH I'd expect testing migration to completely stop for at least a month, since the new glibc needs to be ready. ;-) -reas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request of binNMUs for the libpq4 - libpq5 transition
On Sat, Apr 14, 2007 at 05:06:18PM +0200, Andreas Metzler wrote: On 2007-04-14 Luk Claes [EMAIL PROTECTED] wrote: Can someone please schedule binNMUs for the libpq4 to libpq5 transition once libpq5 (postgresql-8.2) is built everywhere? Hello, wouldn't it be better to wait until libpq5 is in testing? Otherwise a (newly found) rc-bug in libpq5's source would add more than a 100 packages out-of-sync in testing and sid. This could work in this case since libpq4 is from the postgresql-8.1 source package and libpq5 from the postgresql-8.2 source package. This wouldn't work with if it was from the same source package. But I'm not sure if we really need to wait. I think postgresql-8.2 could be hinted into testing with an rc bug if it's really needed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
binNMUs request for ocamlnet
With the upload of ocamlnet 2.2.7 to unstable all ocaml libraries depending on it are now broken, I kindly ask the following binNMUs to fix that: cduce_0.4.1-1, rebuild against newer ocamlnet, 1, alpha amd64 hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libhttp-ocaml-dev_0.1.3-2, rebuild against newer ocamlnet, 1, alpha amd64 hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libldap-ocaml-dev_2.1.8-2, rebuild against newer ocamlnet, 1, alpha amd64 hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libpxp-ocaml-dev_1.1.96-8, rebuild against newer ocamlnet, 1, alpha amd64 hppa i386 ia64 m68k mips mipsel powerpc s390 sparc I haven't checked if the packages have previously been binNMUed, so 1 as the NMU number in the list above is a guess of mine (I do have checked source version and archs though). Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: binNMUs request for ocamlnet
Stefano Zacchiroli wrote: With the upload of ocamlnet 2.2.7 to unstable all ocaml libraries depending on it are now broken, I kindly ask the following binNMUs to fix that: cduce_0.4.1-1, rebuild against newer ocamlnet, 1, alpha amd64 hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libhttp-ocaml-dev_0.1.3-2, rebuild against newer ocamlnet, 1, alpha amd64 hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libldap-ocaml-dev_2.1.8-2, rebuild against newer ocamlnet, 1, alpha amd64 hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libpxp-ocaml-dev_1.1.96-8, rebuild against newer ocamlnet, 1, alpha amd64 hppa i386 ia64 m68k mips mipsel powerpc s390 sparc I haven't checked if the packages have previously been binNMUed, so 1 as the NMU number in the list above is a guess of mine (I do have checked source version and archs though). The 1 was a good guess as none of the versions have been binNMUed before. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
binNMU requests for libeb7 - libeb12 transition
Hi Can someone please schedule binNMUs for the following packages: ndtpd_3.1.5-6.3, rebuild against libeb12, 1, alpha amd64 arm hppa hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sparc libeb-ruby_2.3-1, rebuild against libeb12, 1, alpha amd64 arm hppa hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sparc Cheers Luk signature.asc Description: OpenPGP digital signature
Re: Mozilla plans for the lenny cycle
On Fri, Apr 13, 2007 at 08:51:52AM +0200, Mike Hommey wrote: Marc 'HE' Brockschmidt didn't write: The currently known upstream plans are the following: - Firefox 3.0 is expected around Q2 2007. - Xulrunner 1.9 should be expected at the same time. - Seamonkey 1.5 should be expected some time in 2007. - Thunderbird 3.0 is expected around Q1 2008. Firefox3.0 is expected in december 2007 ... more realistically in januar 2008 ... thats what I heard in one of the last firefox status meetings. for thunderbird 3.0 ... I would expect nothing. They are all expected to be buildable on top of xulrunner (except itself, obviously), which means we'll finally be able to have less pain for stable maintenance. Even if not, it is my personal lenny goal to make this happen. ack ... if there is something missing for this, we should definitly contribute upstream. They are probably happy to get help on this ... of course we have to begin in time ... e.g. submit patches at best before ffox beta 2 (read: end Q2/ start Q3 2007). As no other roadmap has been publicly depicted, I can't tell if by 18 months Firefox will be at version 4 or other, but it is likely that there won't be new major releases for Firefox after 3.0 before Lenny, effort probably going on the Mozilla 2.0 platform, which has a huge change plan, thus may take a while to come to completion. no comment and info on this from my side. - Alexander -- GPG messages preferred.| .''`. ** Debian GNU/Linux ** Alexander Sack | : :' : The universal [EMAIL PROTECTED]| `. `' Operating System http://www.asoftsite.org/ | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Request for give-backs for rtorrent
Hi Can someone please give back rtorrent_0.7.1-1 on alpha, mips, powerpc and sparc as libtorrent-dev = 0.11.1 was not yet available on these architectures when a first build was tried? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Request of binNMUs of nut
Hi Can someone schedule binNMUs for: nut_2.0.5-3, Rebuild against fixed libgd2 (shlibs was wrong), 1, alpha mips Current installed packages on alpha and mips are uninstallable... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please consider a binNMU on reprepro due to libarchive transition.
Regarding #418637. I've prepared a new release of deb-gview which Build-Depends on libarchive-dev. libarchive1 has been replaced by libarchive2 in unstable but I cannot find any ABI/API change as yet - I use deb-gview and reprepro regularly (I suspect others would use the two together as well) and when I recompiled deb-gview and reprepro against libarchive2, both compiled and functioned perfectly. I'm ready to make an upload of deb-gview and I'm wondering if a binNMU of reprepro is worthwhile to allow deb-gview, libarchive2 and reprepro to be installable together. It does seem to be working around the problem in libarchive, rather than fixing it, so I'm really asking whether a binNMU of reprepro is the best solution to #418637. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpjOQbWHTY6O.pgp Description: PGP signature
Re: Bug#419111: context: Fails to install: ctxfmtutil: line 12: kpsewhich: command not found
Kurt Roeckx [EMAIL PROTECTED] wrote: On Sat, Apr 14, 2007 at 08:56:28AM +0200, Frank Küster wrote: Now that the debhelper change has been reverted, we can't rebuild texlive with fixed tex-common. We need to upload a reverted tex-common, and then rebuild texlive. Until this has happened, buildds should be prevented to install texlive if that is possible, and the buildds need to be fixed. I think they will even fix themselves as soon as they once installed and then purged a working version. What happens if we do install texlive other then it breaks on removal? Nothing if the right packages will be installed. But as soon as it was attempted once, everytime it is tried the next time builds will fail because they think the postrm-failed texlive packages are still installed and do not try to install them again. That's what resulted in the context error in the second build log. If none of the buggy texlive packages are installed, the new ones will be automatically picked up when they are available. If they are installed, the least that needs to be done is to manually install and purge the new ones; I didn't check whether this is sufficient. I know we should, but I don't have any time this weekend, and Norbert probably not much, and we rather upload working packages as soon as possible. If the automatic cleanup (i.e. just installing the new ones) does not help, we need an other upload of tex-common to fix this. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Request of give-back of libglade-java_2.12.4-1+b1 on alpha and powerpc
Hi Can someone please give back libglade-java_2.12.4-1+b1 on alpha and powerpc? The missing build dependency libgnome-jni (= 2.12.3-1) is now available on alpha and powerpc. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
