Bug#1072648: src:survival: fails to migrate to testing for too long: triggers autopkgtest issues in r-cran-popepi which needs an update
Am Mittwoch, 5. Juni 2024, 22:27:09 CEST schrieb Dirk Eddelbuettel: > On 5 June 2024 at 21:55, Paul Gevers wrote: > | Source: survival > | Version: 3.5-8-1 > | Severity: serious > | Control: close -1 3.6-4-1 > | Tags: sid trixie > | User: release.debian@packages.debian.org > | Usertags: out-of-sync > | > | Dear maintainer(s), > | > | The Release Team considers packages that are out-of-sync between testing > | and unstable for more than 30 days as having a Release Critical bug in > | testing [1]. Your package src:survival has been trying to migrate for 40 > | days [2]. Hence, I am filing this bug. The version in unstable triggers > | autopkgtest failure in r-cran-popepi. > | > | If a package is out of sync between unstable and testing for a longer > | period, this usually means that bugs in the package in testing cannot be > | fixed via unstable. Additionally, blocked packages can have impact on > | other packages, which makes preparing for the release more difficult. > | Finally, it often exposes issues with the package and/or > | its (reverse-)dependencies. We expect maintainers to fix issues that > | hamper the migration of their package in a timely manner. > | > | This bug will trigger auto-removal when appropriate. As with all new > | bugs, there will be at least 30 days before the package is auto-removed. > | > | I have immediately closed this bug with the version in unstable, so if > | that version or a later version migrates, this bug will no longer affect > | testing. I have also tagged this bug to only affect sid and trixie, so > | it doesn't affect (old-)stable. > | > | If you believe your package is unable to migrate to testing due to > | issues beyond your control, don't hesitate to contact the Release Team. > > It is beyond my control that package r-cran-popepi descides to run > autopkgtests that than hijack and blackmail this package of mine. > > Maybe the maintainers of r-cran-popepi should look at their package tracker > and eg attempt to update to a _current_ version? That's how things work at > CRAN. A look at the ChangeLog of popEpi confirms that that package just needs an update: News for version 0.4.12 Unit tests No changes in the package itself — fixed a unit test that used the output of survival::summmary.survfit which had improved slightly in 3.6-4. Should we reassign the bug to r-cran-popepi? Johannes > I am really tired of this here in Debian. If the package gets autoremoved, > so be it. The blame will rest with the so-called maintainer team for these > R package that are effectively taking down maintained packages of mine. > > Dirk > > | Paul > | > | [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html > | [2] https://qa.debian.org/excuses.php?package=survival > | > | x[DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature]
Bug#861333: r-base: R packages uploaded to Debian before 14 April 2017 that use .C or .Fortran fail to find objects
Nice. Amazing work. So buster should be covered then. Now (correct me if I am wrong) if we could adapt your scripts to create versioned Breaks: relationships with these packages, this would open the possibility to create backports for stretch-backports and jessie-backports- sloppy, taking advantage of the Debian infrastructure for builds on all architectures. Side note: Regarding backports on CRAN, I have chosen to create a separate repository for R >= 3.4.0, so people should be conscious about the issue for R package debs when they install it.
Bug#861333: r-base: R packages uploaded to Debian before 14 April 2017 that use .C or .Fortran fail to find objects
Am Montag, 1. Mai 2017, 14:53:49 schrieb Charles Plessy: ... > At this point I see 3 options: > > - For each rebuild, insert a "Breaks" relationship in r-base's control > file; This is the solution favoured by me as the maintainer of the backports on CRAN (I know, this is the Debian BTS, but nonetheless), as it would just cause rebuilds/reinstalls of the packages really affected, assuming that we manage to have a versioned Breaks relationship for those packages (e.g. r-cran-spatial <= xy). > - Increment r-api-3 to r-api-4 (or r-api-3.4, etc.) in order to not have to > maintain a long list of "Breaks" declarations. In that case, we have to > rebuild everything. Would be OK for me, but seems to cause a lot of work for r-cran-* and r-bioc* maintainers > - Just rebuild what has to be rebuilt, and do not support partial upgrades, > which is what has been done until now. In this case, I would create a new repository on CRAN (again, I know that this is not really Debians business), so people would consciously install R 3.4.0 and not be surprised by packages suddenly failing to find their objects. > Not supporting partial upgrades puts the maintainers of the r-cran and > r-bioc packages between the hammer and the anvil. I do not understand this sentence. > This said, I think that > we have made constant progresses over the years, so I do not feel shy > saying "not yet" to the Release team again if needed.
Bug#861333: r-base: R packages uploaded to Debian before 14 April 2017 that use .C or .Fortran fail to find objects
> | Packages compiled locally can simply be rebuilt using > | > | update.packages(lib.loc="/usr/local/lib/R/site-library", > | checkBuilt=TRUE) > | > | However the packages provided by Debian packages are installed in a > | directory only writable by privileged users. > > That's irrelevant. You also need to be "privileged" to install a .deb > package. Not quite irrelevant, as it was recommended on r-help to Göran, who first reported this for Debian, to just use update.packages(checkBuilt=TRUE) which tries to reinstall also the packages in /usr/lib/R/site-library, which should be left to the Debian package management.
Bug#804823: Severity and title
Package: kreversi Version: 4:4.13.1-1 Followup-For: Bug #804823 Control: severity -1 important Maybe other games are affected as well.
Bug#804823: kreversi: crashes on start
Package: kreversi
Version: 4:4.13.1-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
When I try to start kreversi on jessie, I get
file:///usr/share/kde4/apps/kreversi/qml/Table.qml:107:5: Type CanvasItem
unavailable
CanvasItem {
^
file:///usr/share/kde4/apps/kreversi/qml/CanvasItem.qml:25:1: module
"org.kde.games.core" is not installed
import org.kde.games.core 0.1 as KgCore
^
QObject::connect: Cannot connect (null)::cellClicked(int,int) to
KReversiView::onPlayerMove(int,int)
KCrash: Application 'kreversi' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
KCrash: Connect sock_file=/home/myuser/.kde/socket-myhost/kdeinit4__0
Kind regards,
Johannes
-- System Information:
Debian Release: 8.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (10, 'unstable'), (5,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages kreversi depends on:
ii kde-runtime 4:4.14.2-2
ii libc6 2.19-18+deb8u1
ii libkdecore5 4:4.14.2-5
ii libkdegames6abi14:4.14.2-1
ii libkdeui5 4:4.14.2-5
ii libqt4-declarative 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii libqt4-svg 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii libstdc++6 4.9.2-10
Versions of packages kreversi recommends:
ii khelpcenter4 4:4.14.2-2
kreversi suggests no packages.
-- no debconf information
Bug#804823: Only a dependency missing
I just discovered that it runs fine after installation of kde-games-core-declarative Cheers, Johannes
Bug#781266: r-base-core: Package fails to install when there is no group names staff on the system
Am Donnerstag, 26. März 2015, 12:48:37 schrieb Dirk Eddelbuettel: On 26 March 2015 at 18:03, Alexander Schlarb wrote: | Package: r-base-core | Version: 3.1.1-1+b2 | Severity: grave | Justification: renders package unusable | | When installing the package `r-base-core` (or anything that depends on it) | on a clean jessie install (not upgraded) then the depricated staff | group will not Uh-oh. When did 'staff' get deprecated? Do we have a list of still-supported groups? [Ok, went looking via a quick docker image for 'jessie'.] I'll change it to a group I create, something like rpkgs. | exist and the calls to `chown root:staff /usr/local/lib/R` and `chown | root:staff /usr/local/lib/R/site-library` will fail. This prevents the | package (and any dependant packages) from being configured correctly. The package is used to widely (eg by all r-cran-* packages) that I am a little surprised it has not come up earlier. For what it's worth, I do not recall having problems with my jessie pbuilder chroot (i386) and manually debootstrapped chroots (for amd64 and armel) that I used for the recent backport of R 3.1.3 to jessie. I think if I would have had to manually add the staff group I would remember... I suspect it is not really gone yet. I did not find anything in the draft release notes either, just some transition plan in #29007. Alexander, could we be educated further? Even if /usr/local were not to be owned by root:staff any more, does this mean the group will be gone in jessie? Johannes Dirk | -- System Information: | Debian Release: 8.0 | | APT prefers testing | APT policy: (500, 'testing') | | Architecture: amd64 (x86_64) | Foreign Architectures: i386 | | Kernel: Linux 4.0.0-999-lowlatency (SMP w/8 CPU cores; PREEMPT) | Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) | Shell: /bin/sh linked to /bin/dash | Init: systemd (via /run/systemd/system) | | Versions of packages r-base-core depends on: | ii libblas3 [libblas.so.3]1.2.20110419-10 | ii libbz2-1.0 1.0.6-7+b2 | ii libc6 2.19-15 | ii libcairo2 1.14.0-2.1 | ii libgfortran3 4.9.2-10 | ii libglib2.0-0 2.42.1-1 | ii libgomp1 4.9.2-10 | ii libice62:1.0.9-1+b1 | ii libjpeg62-turbo1:1.3.1-12 | ii liblapack3 [liblapack.so.3]3.5.0-4 | ii liblzma5 5.1.1alpha+20120614-2+b3 | ii libopenblas-base [liblapack.so.3] 0.2.12-1 | ii libpango-1.0-0 1.36.8-3 | ii libpangocairo-1.0-01.36.8-3 | ii libpaper-utils 1.1.24+nmu4 | ii libpcre3 2:8.35-3.3 | ii libpng12-0 1.2.50-2+b2 | ii libquadmath0 4.9.2-10 | ii libreadline6 6.3-8+b3 | ii libsm6 2:1.2.2-1+b1 | ii libtcl8.5 8.5.17-1 | ii libtiff5 4.0.3-12.2 | ii libtk8.5 8.5.17-1 | ii libx11-6 2:1.6.2-3 | ii libxext6 2:1.3.3-1 | ii libxss11:1.2.2-1 | ii libxt6 1:1.1.4-1+b1 | ii ucf3.0030 | ii unzip 6.0-16 | ii xdg-utils 1.1.0~rc1+git20111210-7.4 | ii zip3.0-8 | ii zlib1g 1:1.2.8.dfsg-2+b1 | | Versions of packages r-base-core recommends: | iu r-base-dev 3.1.1-1 | ii r-doc-html 3.1.1-1 | iu r-recommended 3.1.1-1 | | Versions of packages r-base-core suggests: | pn ess none | iu r-base-html 3.1.1-1 | pn r-doc-info | r-doc-pdf none | pn r-mathlib none | | -- no debconf information -- PD Dr. Johannes Ranke Kronacher Str. 8 79639 Grenzach-Wyhlen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#469128: gchempaint: crashes on startup
Package: gchempaint Version: 0.8.7-1 Severity: grave Justification: renders package unusable Hi Daniel, I just wanted to give the freshly updated gchempaint a try: [EMAIL PROTECTED]:~$ gchempaint (process:8241): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.14.6/gobject/gtype.c:2242: initialization assertion failed, use IA__g_type_init() prior to this function (process:8241): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed (process:8241): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed Segmentation fault Hope that the above is helpful to find the problem. Best, Johannes Ranke -- System Information: Debian Release: lenny/sid Architecture: amd64 (x86_64) Kernel: Linux 2.6.20-1-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages gchempaint depends on: ii gconf2 2.20.1-3 GNOME configuration database syste ii libart-2.0-2 2.3.20-1 Library of functions for 2D graphi ii libatk1.0-01.20.0-1 The ATK accessibility toolkit ii libbonobo2-0 2.21.90-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.21.90-1 The Bonobo UI library ii libc6 2.7-9 GNU C Library: Shared libraries ii libcairo2 1.4.14-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.5.0-2 generic font configuration library ii libfreetype6 2.3.5-1+b1FreeType 2 font engine, shared lib ii libgcc11:4.3.0~rc2-1 GCC support library ii libgconf2-42.20.1-3 GNOME configuration database syste ii libgcu00.8.6-1 GNOME chemistry utils (library) ii libgl1-mesa-glx [libgl 7.0.3~rc2-1 A free implementation of the OpenG ii libglade2-01:2.6.2-1 library to load .glade files at ru ii libglib2.0-0 2.14.6-1 The GLib library of C routines ii libglu1-mesa [libglu1] 7.0.3~rc2-1 The OpenGL utility library (GLU) ii libgnome2-02.20.1.1-1The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.20.1.1-1A powerful object-oriented display ii libgnomeprint2.2-0 2.18.4-1 The GNOME 2.2 print architecture - ii libgnomeprintui2.2-0 2.18.2-1 GNOME 2.2 print architecture User ii libgnomeui-0 2.20.1.1-1The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.20.1-2GNOME Virtual File System (runtime ii libgoffice-0-4 0.4.2-4 Document centric objects library - ii libgsf-1-114 1.14.7-2 Structured File Library - runtime ii libgtk2.0-02.12.8-1 The GTK+ graphical user interface ii libgtkglext1 1.2.0-1 OpenGL Extension to GTK+ (shared l ii libice62:1.0.4-1 X11 Inter-Client Exchange library ii libopenbabel2 2.1.1-2 Convert and manipulate chemical da ii liborbit2 1:2.14.10-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.18.4-1 Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-3PNG library - runtime ii libpopt0 1.10-3lib for parsing cmdline parameters ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libstdc++6 4.3.0~rc2-1 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-7 X11 client-side library ii libxml22.6.31.dfsg-1 GNOME XML library ii libxmu62:1.0.4-1 X11 miscellaneous utility library ii libxrender11:0.9.4-1 X Rendering Extension client libra ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii zlib1g 1:1.2.3.3.dfsg-11 compression library - runtime gchempaint recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465608: education-chemistry: fails to install: err 67: Custom distribution education does not exist
Package: education-chemistry Version: 0.824+svn40294 Severity: grave Justification: renders package unusable Setting up education-chemistry (0.824+svn40294) ... err 67: Custom distribution education does not exist dpkg: error processing education-chemistry (--configure): subprocess post-installation script returned error exit status 67 Errors were encountered while processing: education-chemistry E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: lenny/sid Architecture: amd64 (x86_64) Kernel: Linux 2.6.23-1-amd64 (SMP w/1 CPU core) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages education-chemistry depends on: ii education-tasks 0.824+svn40294 Debian Edu tasks for tasksel Versions of packages education-chemistry recommends: ii chemtool 1.6.10-1 Chemical structures drawing progra ii easychem 0.6-4 Draw high-quality molecules and 2D ii gchempaint0.8.6-12D chemical structures editor for ii gdis 0.89-2 molecular display ii ghemical 2.95-2 A GNOME molecular modelling enviro ii gperiodic 2.0.10-2 periodic table application ii kalzium 4:3.5.8-1 chemistry teaching tool for KDE ii pymol 1.0r2-1An OpenGL Molecular Graphics Syste ii viewmol 2.4.1-12 A graphical front end for computat ii xdrawchem 1.9.9-4+b1 Chemical structures and reactions -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456938: openoffice.org-java-common: fails to upgrade
Package: openoffice.org-java-common Version: 2.2.1-9~bpo40+1 Severity: grave Justification: renders package unusable On upgrade I get: Preparing to replace openoffice.org-java-common 2.2.1-9~bpo40+1 (using .../openoffice.org-java-common_1%3a2.3.1-2~bpo40+1_all.deb) ... Unpacking replacement openoffice.org-java-common ... dpkg: error processing /var/cache/apt/archives/openoffice.org-java-common_1%3a2.3.1-2~bpo40+1_all.deb (--unpack): trying to overwrite `/usr/lib/openoffice/program/classes/hsqldb.jar', which is also in package openoffice.org-base Errors were encountered while processing: /var/cache/apt/archives/openoffice.org-java-common_1%3a2.3.1-2~bpo40+1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-xen-amd64 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages openoffice.org-java-common depends on: ii bsh2.0b4-4 Java scripting environment (BeanSh ii libxalan2-java 2.7.0-1 XSL Transformations (XSLT) process ii libxerces2-java2.8.1-1 Validating XML parser for Java wit ii openoffice.org-common 1:2.3.1-2~bpo40+1 OpenOffice.org office suite archit openoffice.org-java-common recommends no packages. -- no debconf information -- Dr. Johannes Ranke [EMAIL PROTECTED] Key ID: F649AF90 UFT Bremen, Leobenerstr. 1 +49 421 218 63373 D-28359 Bremen http://www.uft.uni-bremen.de/chemie/ranke -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421705: r-cran-codetools: doesn't contain codetools library
Package: r-cran-codetools Version: 0.1-8-1 Severity: grave Justification: renders package unusable Hi Dirk, sorry to pollute your nice and clean BTS pages, but you obviously built the r-cran-codetools from the rcompgen source package, and therefore it only contains some files from rcompgen in /usr/share/doc/: # dpkg --contents /var/cache/apt/archives/r-cran-codetools_0.1-8-1_all.deb | cut -d . -f 2 / /usr/ /usr/share/ /usr/share/doc/ /usr/share/doc/r-cran-codetools/ /usr/share/doc/r-cran-codetools/copyright /usr/share/doc/r-cran-codetools/changelog /usr/share/doc/r-cran-codetools/TODO /usr/share/doc/r-cran-codetools/changelog /usr/lib/ /usr/lib/R/ /usr/lib/R/site-library/ Greets, Johannes -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.20-1-amd64 (SMP w/1 CPU core) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages r-cran-codetools depends on: ii r-base-core 2.5.0-1GNU R core of statistical computin r-cran-codetools recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421705: r-cran-codetools: doesn't contain codetools library
* Dirk Eddelbuettel [EMAIL PROTECTED] [070501 13:50]: Hi Johannes, On 1 May 2007 at 09:13, Johannes Ranke wrote: | Package: r-cran-codetools | Version: 0.1-8-1 | Severity: grave | Justification: renders package unusable | | | Hi Dirk, | | sorry to pollute your nice and clean BTS pages, but you obviously built | the r-cran-codetools from the rcompgen source package, and therefore I actually noticed that and made two more uploads (see http://packages.qa.debian.org/c/codetools.html -- which actually indicates that it got pulled) but I uploaded it with lower version numbers -- so the old package won, unfortunately. Oh, the version number was from rcompgen, too, I see. I'll clean that up, either with a new package r-cran-codetools or a fix via epochs. Good to hear that, I'll be glad to do the backports just starting out from your packages then as usual. Thanks for the heads up. You're welcome. It's a pleasure to work at the interface of R and Debian. Johannes Dirk | it only contains some files from rcompgen in /usr/share/doc/: | | # dpkg --contents /var/cache/apt/archives/r-cran-codetools_0.1-8-1_all.deb | cut -d . -f 2 | / | /usr/ | /usr/share/ | /usr/share/doc/ | /usr/share/doc/r-cran-codetools/ | /usr/share/doc/r-cran-codetools/copyright | /usr/share/doc/r-cran-codetools/changelog | /usr/share/doc/r-cran-codetools/TODO | /usr/share/doc/r-cran-codetools/changelog | /usr/lib/ | /usr/lib/R/ | /usr/lib/R/site-library/ | | Greets, | | Johannes | | -- System Information: | Debian Release: lenny/sid | APT prefers unstable | APT policy: (500, 'unstable'), (1, 'experimental') | Architecture: amd64 (x86_64) | | Kernel: Linux 2.6.20-1-amd64 (SMP w/1 CPU core) | Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) | Shell: /bin/sh linked to /bin/bash | | Versions of packages r-cran-codetools depends on: | ii r-base-core 2.5.0-1GNU R core of statistical computin | | r-cran-codetools recommends no packages. | | -- no debconf information | -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- Dr. Johannes Ranke [EMAIL PROTECTED] Key ID: F649AF90 UFT Bremen, Leobenerstr. 1 +49 421 218 63373 D-28359 Bremen http://www.uft.uni-bremen.de/chemie/ranke -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419987:
* Frank Küster [EMAIL PROTECTED] [070420 09:20]: Johannes Ranke [EMAIL PROTECTED] wrote: Couldn't texlive-base-bin conflict with xmltex? Of course not, since that would mean that xmltex isn't installable any more - there's no other TeX system in sid. Citing from the xmltex package: XMLTeX is a non-validating, namespace-aware XML parser written in TeX. It allows TeX to directly process XML files. Usually I process tex files with TeX, not XML files. So I figured I don't need xmltex. Did I miss something, like texlive converts every tex/latex file into XML and then uses xmltex?
Bug#419987:
* Frank Küster [EMAIL PROTECTED] [070420 10:30]: Johannes Ranke [EMAIL PROTECTED] wrote: * Frank Küster [EMAIL PROTECTED] [070420 09:20]: Johannes Ranke [EMAIL PROTECTED] wrote: Couldn't texlive-base-bin conflict with xmltex? Of course not, since that would mean that xmltex isn't installable any more - there's no other TeX system in sid. Citing from the xmltex package: XMLTeX is a non-validating, namespace-aware XML parser written in TeX. It allows TeX to directly process XML files. Usually I process tex files with TeX, not XML files. So I figured I don't need xmltex. Did I miss something, like texlive converts every tex/latex file into XML and then uses xmltex? No, why? What's the problem you are trying to address? See bug title. Was xmltex pulled in by some package which you installed? I don't remember this. Usually, people who don't want xmltex shouldn't install it, but for those who install it on purpose, it also needs a working TeX system underneath. The problem is, that if you have xmltex installed, an upgrade from tetex to texlive freezes the system. I think this is worth addressing quickly, since it is very annoying to have to restart the system. As I understood from Norberts comment, fixing xmltex might take a while. So, at present, it would be nice if tex-live-bin would conflict with xmltex, because it is impossible, as far as I can see, to have both on the system. Later, of course, this conflict should be removed. Johannes Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive) -- Dr. Johannes Ranke [EMAIL PROTECTED] Key ID: F649AF90 UFT Bremen, Leobenerstr. 1 +49 421 218 8971 D-28359 Bremen http://www.uft.uni-bremen.de/chemie/ranke
Bug#419987:
The problem is, that if you have xmltex installed, an upgrade from tetex to texlive freezes the system. I think this is worth addressing quickly, since it is very annoying to have to restart the system. As I understood from Norberts comment, fixing xmltex might take a while. No, he wrote about the number of changes, not the time it takes (Actually the work is already done by us, just the xmltex maintainer is inactive). OK. It wasn't clear to me that you were talking about an interim solution. Sorry, I should have made that clear. Thanks for all the great work on maintaining tex for Debian! Regards, Johannes Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive) -- Dr. Johannes Ranke [EMAIL PROTECTED] Key ID: F649AF90 UFT Bremen, Leobenerstr. 1 +49 421 218 8971 D-28359 Bremen http://www.uft.uni-bremen.de/chemie/ranke
Bug#419987:
retitle 419987 texlive-base-bin: =?iso-8859-15?q?configuration_runs_forever=2C_leaks_memory_until_system_d?= =?iso-8859-15?q?ies=0D=0Athanks?= Reply-To: Johannes Ranke [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] X-Mailer: reportbug 3.36 Date: Thu, 19 Apr 2007 23:16:58 +0200 Package: texlive-base-bin Version: 2007-5 Followup-For: Bug #419987 Just trying to change the bug title, so people using apt-listbugs get a clue. No idea if this works like that. Couldn't texlive-base-bin conflict with xmltex? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.20-1-amd64 (SMP w/1 CPU core) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages texlive-base-bin depends on: ii ed0.2-20 The classic unix line editor ii libc6 2.5-3 GNU C Library: Shared libraries ii libncurses5 5.5-5 Shared libraries for terminal hand ii libpng12-01.2.15~beta5-1 PNG library - runtime ii libpoppler0c2 0.4.5-5.1 PDF rendering library ii libx11-6 2:1.0.3-7 X11 client-side library ii libxaw7 1:1.0.3-3 X11 Athena Widget library ii libxmu6 1:1.0.3-1 X11 miscellaneous utility library ii libxpm4 1:3.5.6-2 X11 pixmap library ii libxt61:1.0.5-2 X11 toolkit intrinsics library ii mime-support 3.39-1 MIME files 'mime.types' 'mailcap ii perl 5.8.8-7Larry Wall's Practical Extraction ii texlive-common2007-4 TeX Live: Base component ii zlib1g1:1.2.3-13 compression library - runtime Versions of packages texlive-base-bin recommends: ii perl-tk 1:804.027-7 Perl module providing the Tk graph Versions of packages tex-common depends on: ii debconf 1.5.13 Debian configuration management sy ii ucf 2.0021 Update Configuration File: preserv Versions of packages texlive-base-bin is related to: pn tetex-basenone (no description available) ii tetex-bin 2007-4 TeX Live: teTeX transitional packa pn tetex-extra none (no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
