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: Only a dependency missing
I just discovered that it runs fine after installation of kde-games-core-declarative Cheers, Johannes
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#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 > | iu r-base-html 3.1.1-1 > | pn r-doc-info | r-doc-pdf > | pn r-mathlib > | > | -- 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
* 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#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#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:
* 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:
* 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:
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-base (no description available) ii tetex-bin 2007-4 TeX Live: teTeX transitional packa pn tetex-extra(no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
