Re: Who declares optional packages extra?
Richard B. Kreckel wrote: Hi, Also, I'm slightly worried about the 6 non-depending packages made uninstallable on arm, according to http://bjorn.haxx.se/debian/testing.pl?package=ginac. Is this just bogus or what? No, it's not bogus. It's a result of not having arm binary packages in unstable. The best solution would be to have ginac built on arm so that these 6 packages are installable on arm again (in unstable) and all can hopefuly transition smoothly to testing. The other solutions are to not have ginac transition to testing or to have the arm binary packages of the 6 packages removed (or being uninstallable) when ginac transitions to testing. 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: PGP signature signature.asc Description: OpenPGP digital signature
Re: Hint openssl to testing.
On Fri, Sep 29, 2006 at 08:02:16PM -0700, Steve Langasek wrote: On Sat, Sep 30, 2006 at 02:46:17AM +0200, Kurt Roeckx wrote: Could you please hint openssl to testing? It's frozen because it has udebs. Already done, will go in as soon as it's aged another day. I see a hint in aba's file which says: unblock openssl/0.9.8b-3 But it's about version 0.9.8c-2 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BinNMU request for openser 1.1.0-3 on arm
Steve Langasek [EMAIL PROTECTED] wrote: Hi, Scheduled, but a package that generates an empty binary in response to a gcc failure instead of aborting the build has a (lower-severity) sourceful bug. Please take care of this in the source package. Thanks for the binNMU. The build system has issues, this is a known problem and I think it's being worked on. I'll check that as soon as I'll have enough free time to do so. JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hint openssl to testing.
* Kurt Roeckx ([EMAIL PROTECTED]) [061002 08:38]: On Fri, Sep 29, 2006 at 08:02:16PM -0700, Steve Langasek wrote: On Sat, Sep 30, 2006 at 02:46:17AM +0200, Kurt Roeckx wrote: Could you please hint openssl to testing? It's frozen because it has udebs. Already done, will go in as soon as it's aged another day. I see a hint in aba's file which says: unblock openssl/0.9.8b-3 But it's about version 0.9.8c-2 I moved my finished-marker up. Thanks for noticing. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Who declares optional packages extra?
On Mon, Oct 02, 2006 at 08:04:27AM +0200, Luk Claes wrote: Also, I'm slightly worried about the 6 non-depending packages made uninstallable on arm, according to http://bjorn.haxx.se/debian/testing.pl?package=ginac. Is this just bogus or what? No, it's not bogus. It's a result of not having arm binary packages in unstable. The best solution would be to have ginac built on arm so that these 6 packages are installable on arm again (in unstable) and all can hopefuly transition smoothly to testing. The other solutions are to not have ginac transition to testing or to have the arm binary packages of the 6 packages removed (or being uninstallable) when ginac transitions to testing. Since ginac in testing does not have any RC bugs at present, and the version of ginac on arm for testing is up-to-date, it's not justifiable to increase arm's uninstallable count by forcing the new version of ginac in. That leaves getting ginac built on arm, requesting removal of the arm binaries that would be left uninstallable, or leaving things as they are until etch releases or unless a decision is made to drop arm from the release. Note that if someone shows that the version of ginac in testing also FTBFS on arm, that's an RC bug on those binary packages as well, so removing them (through propagation of ginac 1.3.5) would then be acceptable... -- 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: [Etch] Please allow docbook-xsl 1.71.0.dfsg.1-1 to propagate into Etch
Am Sonntag, den 01.10.2006, 04:50 -0700 schrieb Steve Langasek: On Sun, Oct 01, 2006 at 01:33:42PM +0200, Daniel Leidert wrote: I would like to ask for docbook-xsl 1.71.0.dfsg.1-1 in Etch. Where were you looking that you think it isn't there already? :) docbook-xsl | 1.71.0.dfsg.1-1 | testing | source, all docbook-xsl | 1.71.0.dfsg.1-1 | unstable | source, all Ok. The report, that docbook-xsl migrated to testing reached me today. So I was wrong thinking, it might be already frozen. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Would an ABI change of apt for DDTP support still be accepted?
On Mon, Oct 02, 2006 at 12:54:13AM +0200, Michael Vogt wrote: BTW, I count 18 binary packages that would need a rebuild for this. This is a decent-sized library transition in its own right. We may have to recompile the rdepends of libapt anyway because of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390189 (recent g++ upload 4.1.1ds1-14 has a g++ regression) sigh This version of g++-4.1 hasn't been accepted into etch yet, and there's been no request from Matthias that we do so. Letting it into etch as a freeze exception suggests that we might have *other* packages fail to build as a result of similar ABI regressions in other libraries. That doesn't sound like a good idea to me unless someone is offering to do a full regression-test of testing using g++ 4.1.1-15. Upstream gcc bugreport: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29289 From this report, there's nothing to suggest the reverse-deps need to be rebuilt, only that the lib needs to be rebuilt so that the reverse-deps don't FTBFS. Is there something I'm missing? Matthias is still waiting for a comment from upstream on this. It maybe enough to recompile apt with the current g++, but it maybe that the only save option is to change the soname and recompile a rdepends. If there really is reason to believe this requires an soname change, I think we should instead consider backing this patch out of g++-4.1 in unstable until after the etch release, as compiler-induced ABI changes are clearly *not* supposed to be happening during a toolchain freeze. There's no API changes from APT side so just binary NMUs are enough AFAIK. So what is this ABI change that doesn't involve API changes? There is a API change involved. But it is backwards compatible so a recompile will be good enough. To make use of the translated descriptions the applications needs to be changed though. Patches are available for aptitude, python-apt, synaptic, libapt-front (0.3). I hope this helps and I'm sorry for the bad timing with this request :/ FWIW, this didn't answer the question what is the ABI change? :) 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: Would an ABI change of apt for DDTP support still be accepted?
On Mon, 2006-10-02 at 11:54 +0200, Jens Seidel wrote: Consider how many people whould profit from it! I'm missing the following practical note a bit in this discussion: are there actually a significant number of translations to take the non-trivial venture of a very late apt update? I value the importance of the DDTP project, but the translating effort has only recently seriously started. Looking at the statistics[1], I see that the best language has yet only one third of descriptions translated in optional and extra, and steeply dropping to only a couple of percentpoints for those after that. Best translated are required/important/standard, but those descriptions will be the least relevant to Joe Average, since these packages are already installed for him. Concluding, we will not be able to claim that Debian has translated package descriptions, except for a very small number of languages. I think it's not worth the effort to risk delay or trouble for this; let's focus on other areas in etch now and make sure etch+1 has a really comprehensive set of translated descriptions. Thijs signature.asc Description: This is a digitally signed message part
intent to do a poppler transition
Hi, poppler 0.5.4 (f.d.o PDF rendering library) was declared stable by upstream and I would like to upload new version to unstable which changes SONAME from 0 to 1. No API changes were done between 0.4.x and 0.5.x so just rebuild with new libpoppler-dev should be enough. Also libpoppler.so moved to Libs.private:, so packages compiled against -qt,-glib binding should not directly depend on libpoppler after recompile (which is good thing :-). Affected packages (directly): texlive-base-bin tetex-bin poppler-utils libpopplerkit0 libpdfkit0 kdegraphics-kfile-plugins evince abiword-plugins Through libpoppler0c2-qt: kdegraphics-kfile-plugins Through libpoppler0c2-glib: evince Gnome Team will take care of evince, and I am Ccing maintainers of affected packages (although I think that binary NMU can fix that?). The reason for this is that poppler 0.4.x is very buggy and it will not be supported from upstream. Also number of affected packages in not very high. Ondrej. -- Ondřej Surý [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Would an ABI change of apt for DDTP support still be accepted?
On Mon, Oct 02, 2006 at 12:54:13AM +0200, Michael Vogt wrote: On Wed, Sep 27, 2006 at 11:42:35PM -0700, Steve Langasek wrote: On Thu, Sep 28, 2006 at 02:35:19AM -0300, Otavio Salvador wrote: On Wed, Sep 27, 2006 at 07:13:21PM +0200, Luk Claes wrote: Would you still accept an ABI change of apt to support description translations into etch? That's why I considered it so late for uploading to unstable. I didn't wanted to upload it without real-world testing because of the risk of having to break the ABI yet again to fix mistakes in the code. We may have to recompile the rdepends of libapt anyway because of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390189 (recent g++ upload 4.1.1ds1-14 has a g++ regression) Debian was always proud because of many software packages. Nevertheless it's a real drawback that package descriptions are only available in English. Many person with no English skills do not know the packages Debian provides and ignored these because of this. Once I installed a system with translated package descriptions for a friend I remember first time users of Debian browsing description just for fun, testing these packages, comparing with other systems, ... Without they never touched aptitude and complained about the usability. Consider how many people whould profit from it! Ten thousands, hundred thousands of users?! Please compare this with possible disadvantages and choose the proper solution! Once it enters testing I would also ask additional users from various lists (not only developers) to properly use and test it and would be willing to help these users to report possible problems. I'm sure many other people (translators and other) would do the same once you consider the changes for Etch. I now subscribed also to the APT bugs and will try my best ... Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Would an ABI change of apt for DDTP support still be accepted?
On Mon, Oct 02, 2006 at 01:17:18PM +0200, Thijs Kinkhorst wrote: On Mon, 2006-10-02 at 11:54 +0200, Jens Seidel wrote: Consider how many people whould profit from it! I'm missing the following practical note a bit in this discussion: are there actually a significant number of translations to take the non-trivial venture of a very late apt update? I value the importance of the DDTP project, but the translating effort has only recently seriously started. Looking at the statistics[1], I see See http://ddtp.debian.net/ for this link [1]. that the best language has yet only one third of descriptions translated in optional and extra, and steeply dropping to only a couple of percentpoints for those after that. Concluding, we will not be able to claim that Debian has translated package descriptions, except for a very small number of languages. I think it's not worth the effort to risk delay or trouble for this; let's focus on other areas in etch now and make sure etch+1 has a really comprehensive set of translated descriptions. Right. Nevertheless there are currently already at least 4 languages with (partly many more than) 1000 package descriptions. Also consider that the translation effort is independent of the Etch release (external database, no package upload are required, except of course for apt). Up to the release of Etch (for CD based installations) or even after it (network connection) users could profit from it. I can also guarantee that the effort will increase dramatically once we know that APT would support it. Currently the matra is: Let's ignore package descriptions as these will probably not be usable in Etch at all. Once users see a incomplete project they want to help, right!? Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: intent to do a poppler transition
Le lun 2 octobre 2006 14:26, Ondřej Surý a écrit : Hi, poppler 0.5.4 (f.d.o PDF rendering library) was declared stable by upstream and I would like to upload new version to unstable which changes SONAME from 0 to 1. No API changes were done between 0.4.x and 0.5.x so just rebuild with new libpoppler-dev should be enough. Also libpoppler.so moved to Libs.private:, so packages compiled against -qt,-glib binding should not directly depend on libpoppler after recompile (which is good thing :-). […] Through libpoppler0c2-qt: kdegraphics-kfile-plugins we will have a new dot release of kde soon, kde 3.5.5 that we'd like to push into etch, as it's (1) a minor fix-release (2) and that it address many of the kde current RC bugs. the 3.5.5 release is due to oct 10th, and I suppose the tarballs will be made available to us in the coming few days (probably end of the week). so we are ready to coordinate an upload here. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp8rlCsWR4JL.pgp Description: PGP signature
Re: intent to do a poppler transition
On Mon, 2006-10-02 at 15:52 +0200, Frank Küster wrote: The following packages have unmet dependencies: libpoppler1: Depends: poppler-data but it is not installable E: Broken packages # apt-cache policy poppler-data poppler-data: Installed: (none) Candidate: (none) Version table: Just uploaded to experimental: Changes: poppler (0.5.4-2) experimental; urgency=low . * [debian/control]: poppler-data is non-free, do not depend on it (Closes: #389753) Ondrej -- Ondřej Surý [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: intent to do a poppler transition
On Mon, 2006-10-02 at 15:56 +0200, Norbert Preining wrote: On Mon, 02 Okt 2006, Ond??ej Surý wrote: poppler 0.5.4 (f.d.o PDF rendering library) was declared stable by upstream and I would like to upload new version to unstable which changes SONAME from 0 to 1. No API changes were done between 0.4.x and 0.5.x so just rebuild with new libpoppler-dev should be enough. Also I remember a patch in the bts that should make tetex/texlive ready for poppler 0.5, the patch came from the ubuntu people which are shipping 0.5. (http://patches.ubuntu.com/t/texlive-bin/texlive-bin_2005.dfsg.1-1ubuntu2.patch) So is there really ONLY a recompile necessary ... Duck and hides. Sorry, I was not aware of it. Anyway, I was going to suggest compiling against experimental package before upload to unstable happens, so we would find that out. Whole problem is more complicated. No external package should every never use libpopplerX directly (well at least according to upstream). According to upstream, it was never meant to be used that way. External packages should use either -glib or -qt bindings which have stable API and ABI. Main reason why I didn't do upload of 0.5.x series to unstable was possible ABI unstability (see upstream comments and possible solutins at https://bugs.freedesktop.org/show_bug.cgi?id=7054 ) Ondrej. -- Ondřej Surý [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: intent to do a poppler transition
On Mon, 02 Okt 2006, Ond??ej Surý wrote: poppler 0.5.4 (f.d.o PDF rendering library) was declared stable by upstream and I would like to upload new version to unstable which changes SONAME from 0 to 1. No API changes were done between 0.4.x and 0.5.x so just rebuild with new libpoppler-dev should be enough. Also I remember a patch in the bts that should make tetex/texlive ready for poppler 0.5, the patch came from the ubuntu people which are shipping 0.5. (http://patches.ubuntu.com/t/texlive-bin/texlive-bin_2005.dfsg.1-1ubuntu2.patch) So is there really ONLY a recompile necessary ... Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Università di Siena Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- MARKET DEEPING (participial vb.) Stealing one piece of fruit from a street fruit-and- vegetable stall. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED]: Remove some architectures for vzctl]
Hi The response from the following bug #390637 was that I need to inform the release team and request the removal by them. If I update the architecture list to just list the three supported architectures, will that automatically be reflected on testing or do you still need to do manual intervention to remove them? In any case vzctl should never have been built for some architectures as there is no kernel syscal for those. Regards, // Ola - Forwarded message from Ola Lundqvist [EMAIL PROTECTED] - From: Ola Lundqvist [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Remove some architectures for vzctl Reply-To: [EMAIL PROTECTED] Envelope-to: [EMAIL PROTECTED] Package: ftp.debian.org Severity: normal Hi I'm writing this to request the removal of some built packages from unstable/testing. Remove vzctl for the following architectures: * s390 * powerpc * arm * sparc * mips * mipsel * alpha The reason for this removal is that they are not supported by vzctl as there is no syscall in the kernel. A check for this has been introduced in the latest version (which is good) and thus they fail now and not before. # 3.0.11-1 (s390) (latest build at Oct 1 17:39: maybe-failed) # 3.0.11-1 (amd64) (latest build at Oct 1 21:10: maybe-successful) # 3.0.11-1 (powerpc) (latest build at Oct 1 17:44: maybe-failed) # 3.0.11-1 (arm) (latest build at Oct 1 22:17: maybe-failed) # 3.0.11-1 (sparc) (latest build at Oct 2 00:31: maybe-failed) # 3.0.11-1 (ia64) (latest build at Oct 2 00:31: maybe-successful) # 3.0.11-1 (mips) (latest build at Oct 2 03:41: maybe-failed) # 3.0.11-1 (mipsel) (latest build at Oct 2 03:33: maybe-failed) # 3.0.11-1 (alpha) (latest build at Oct 2 05:10: maybe-failed) This bug is related to #390627. Best regards, // Ola - Forwarded message from Bastian Blank [EMAIL PROTECTED] - Envelope-to: [EMAIL PROTECTED] Delivery-date: Mon, 02 Oct 2006 11:00:47 +0200 Subject: Bug#390627: vzctl - FTBFS: error: #error no syscall for this arch Reply-To: Bastian Blank [EMAIL PROTECTED], [EMAIL PROTECTED] Resent-From: Bastian Blank [EMAIL PROTECTED] Resent-To: debian-bugs-dist@lists.debian.org Resent-CC: Ola Lundqvist [EMAIL PROTECTED] Resent-Date: Mon, 02 Oct 2006 09:03:24 + Resent-Message-ID: [EMAIL PROTECTED] X-Debian-PR-Message: report 390627 X-Debian-PR-Package: vzctl X-Debian-PR-Keywords: X-Debian-PR-Source: vzctl From: Bastian Blank [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 Resent-Sender: Debian BTS [EMAIL PROTECTED] Resent-Date: Mon, 02 Oct 2006 02:03:27 -0700 X-Spam-Score: 0.3 (/) X-Spamcheck-provider: Checked for spam by opalsys.net, [EMAIL PROTECTED] Package: vzctl Version: 3.0.11-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of vzctl_3.0.11-1 on debian-31 by sbuild/s390 85 [...] gcc -c -Wall -g2 -fPIC -I ../include lib/cpu.c -o lib/cpu.lo lib/cpu.c:57:2: error: #error no syscall for this arch lib/cpu.c: In function 'fairsched_vcpus': lib/cpu.c:85: error: '__NR_fairsched_vcpus' undeclared (first use in this function) lib/cpu.c:85: error: (Each undeclared identifier is reported only once lib/cpu.c:85: error: for each function it appears in.) make[2]: *** [lib/cpu.lo] Error 1 make[2]: Leaving directory `/build/buildd/vzctl-3.0.11/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/vzctl-3.0.11' make: *** [build-stamp] Error 2 ** Build finished at 20061001-1739 FAILED [dpkg-buildpackage died] - End forwarded message - -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- - End forwarded message - -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: intent to do a poppler transition
However, they are aware at least that other projects are interested in using poppler proper, and I think I told them we are already using it. We even talked about the possibility to provide a backend-free version with a clean API. AFAIR, the only reason for not providing it was that nobody had time to do it. I don't have an idea how this API should like, but I would be happy to join such project. (Better to help then deal with ABI breakages in libpoppler). It's completely inacceptable for pdftex to acquire a dependency on gtk or qt. It's just glib and not gtk, but I see your point. If using plain libpoppler turns out to be impossible, we'd rather switch back to using our embedded xpdf copy and have 10 security releases during each release cycle. I can always switch to debian SONAMEs if there is a need to, but simple library with clearly define API and no ABI breakages would be much better. Ondrej. -- Ondřej Surý [EMAIL PROTECTED] http://blog.rfc1925.org/ signature.asc Description: This is a digitally signed message part
Re: intent to do a poppler transition
Ondřej Surý [EMAIL PROTECTED] wrote: Gnome Team will take care of evince, and I am Ccing maintainers of affected packages (although I think that binary NMU can fix that?). Hm, while trying to check tetex-bin: # apt-get -t experimental install libpoppler1 libpoppler-dev Reading package lists... Done Building dependency tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libpoppler1: Depends: poppler-data but it is not installable E: Broken packages # apt-cache policy poppler-data poppler-data: Installed: (none) Candidate: (none) Version table: The reason for this is that poppler 0.4.x is very buggy and it will not be supported from upstream. Also number of affected packages in not very high. I generally support this move. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: intent to do a poppler transition
Ondřej Surý [EMAIL PROTECTED] wrote: Hi, poppler 0.5.4 (f.d.o PDF rendering library) was declared stable by upstream and I would like to upload new version to unstable which changes SONAME from 0 to 1. No API changes were done between 0.4.x and 0.5.x so just rebuild with new libpoppler-dev should be enough. This is not correct, see for example http://bugs.debian.org/356079 Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: intent to do a poppler transition
Ondřej Surý [EMAIL PROTECTED] wrote: Whole problem is more complicated. No external package should every never use libpopplerX directly (well at least according to upstream). According to upstream, it was never meant to be used that way. External packages should use either -glib or -qt bindings which have stable API and ABI. (I'd rather say have a well-defined API at all, which xpdf and hence libpoppler hasn't) However, they are aware at least that other projects are interested in using poppler proper, and I think I told them we are already using it. We even talked about the possibility to provide a backend-free version with a clean API. AFAIR, the only reason for not providing it was that nobody had time to do it. It's completely inacceptable for pdftex to acquire a dependency on gtk or qt. If using plain libpoppler turns out to be impossible, we'd rather switch back to using our embedded xpdf copy and have 10 security releases during each release cycle. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: intent to do a poppler transition
On 2006-10-02, Norbert Preining [EMAIL PROTECTED] wrote: On Mon, 02 Okt 2006, Ond??ej Surý wrote: poppler 0.5.4 (f.d.o PDF rendering library) was declared stable by upstream and I would like to upload new version to unstable which changes SONAME from 0 to 1. No API changes were done between 0.4.x and 0.5.x so just rebuild with new libpoppler-dev should be enough. Also I remember a patch in the bts that should make tetex/texlive ready for poppler 0.5, the patch came from the ubuntu people which are shipping 0.5. (http://patches.ubuntu.com/t/texlive-bin/texlive-bin_2005.dfsg.1-1ubuntu2.patch) *Sigh* Is this another embedded instance of the xpdf code? Please have it fixed before Etch, the Sarge situation has been a complete disaster. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: intent to do a poppler transition
Frank Küster wrote: It's completely inacceptable for pdftex to acquire a dependency on gtk or qt. If using plain libpoppler turns out to be impossible, we'd Nearly 1000 packages in sid depend on glib, it's not that it's a completely obscure lib causing major problems. Please elaborate why that is completely unacceptable. rather switch back to using our embedded xpdf copy and have 10 security releases during each release cycle. Great, just unload the work onto someone else! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please bin-NMU mn-fit on alpha, amd64, ia64
Hi release team, Could you please bin-NMU mn-fit on the three 64-bit architectures? Unfortunately, code of its build-dependencies in the cernlib and paw source packages is very old and not 64-bit clean; mn-fit must be linked against them statically on 64-bit arches in order to work. (The static linking is taken care of automatically by debian/rules and is already known to work.) I recently uploaded a new version of cernlib (2005.dfsg-5) with some minor 64-bit-related fixes. It would be nice to get mn-fit 5.13-4 rebuilt against that version on 64-bit arches, ASAP, so the bin-NMU'ed version can incorporate those fixes and go into etch. mn-fit is bin-NMU safe, to the best of my knowledge, so this should not cause any problems. Thanks in advance! best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
hypothetical bin-NMU versioning question
I have a hypothetical bin-NMU versioning question (this is asked only for my curiosity, so don't give it a high priority). Suppose that package X (version 1.0-1) is bin-NMU'ed on architectures A and B. At a later time it needs to be bin-NMU'ed on architectures B and C. Will the bin-NMUs be numbered incrementally independently on each arch, or grouped by round? That is, will the arch:any binary packages of X on arch C get version 1.0-1+b1 or 1.0-1+b2? (I'm pretty sure that arch A will end up with 1.0-1+b1 and arch B with 1.0-1+b2, but correct me if that's wrong.) And does this numbering depend upon whether the reasons for the first and second rounds of bin-NMUs are the same or different? Thanks and best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hypothetical bin-NMU versioning question
On 2006-10-02 Kevin B. McCarty [EMAIL PROTECTED] wrote: I have a hypothetical bin-NMU versioning question (this is asked only for my curiosity, so don't give it a high priority). Suppose that package X (version 1.0-1) is bin-NMU'ed on architectures A and B. At a later time it needs to be bin-NMU'ed on architectures B and C. Will the bin-NMUs be numbered incrementally independently on each arch, or grouped by round? That seems to be what happens, yes. See for example http://packages.debian.org/gsasl which was rebuilt after http://lists.debian.org/debian-release/2006/07/msg00270.html |--- | gsasl (amd64 and s390 +b1, all archs except s390 need a rebuild.) |--- It was at 0.2.12-1+b1: amd64 s390 0.2.12-1: alpha arm hppa i386 ia64 kfreebsd-i386 m68k mips mipsel powerpc sparc previously and is now 0.2.12-1+b2: amd64 0.2.12-1+b1: alpha arm hppa i386 ia64 kfreebsd-i386 m68k mips mipsel powerpc s390 sparc That is, will the arch:any binary packages of X on arch C get version 1.0-1+b1 or 1.0-1+b2? (I'm pretty sure that arch A will end up with 1.0-1+b1 and arch B with 1.0-1+b2, but correct me if that's wrong.) And does this numbering depend upon whether the reasons for the first and second rounds of bin-NMUs are the same or different? Afaict the numbering is simply increased for each upload. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BinNMU request for openser 1.1.0-3 on arm
Steve Langasek [EMAIL PROTECTED] wrote: Hi, Scheduled, but a package that generates an empty binary in response to a gcc failure instead of aborting the build has a (lower-severity) sourceful bug. Please take care of this in the source package. FYI: - the build system is fixed in SVN wrt this issue, will be in OpenSER 1.1.0-4 - #390694 has been filed against gcc-4.1 which fails to build part of the jabber module at -O2 (the binNMU rebuild failed too) JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#390637: Remove some architectures for vzctl
On Mon, 2006-10-02 at 21:32 +0200, Ola Lundqvist wrote: [...] One question. If I change the architecture list (remove or add). Do you need to manually do things in order for it to take effect (especially remove) or can I control it myself this way? Regards, // Ola Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#390637: Remove some architectures for vzctl
[G... let's see if we can send it with some content this time...] Hi, On Mon, 2006-10-02 at 21:32 +0200, Ola Lundqvist wrote: [...] One question. If I change the architecture list (remove or add). Do you need to manually do things in order for it to take effect (especially remove) or can I control it myself this way? Adding architectures isn't a problem. If you remove architectures then the binaries for those architectures will need removing from unstable by the ftp-team. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: intent to do a poppler transition
On 2006-10-02 08:26:08 -0400 Ondřej Surý [EMAIL PROTECTED] wrote: Affected packages (directly): libpopplerkit0 libpdfkit0 FYI, these two packages are also part of the (currently ongoing) GNUstep library transition. I'll check to see they will still compile with the new poppler (though I probably won't be able to get around to it until a couple of days). -- Hubert Chan - email Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Re: Would an ABI change of apt for DDTP support still be accepted?
On 10/2/06, Thijs Kinkhorst [EMAIL PROTECTED] wrote: I value the importance of the DDTP project, but the translating effort has only recently seriously started. Looking at the statistics[1], I see that the best language has yet only one third of descriptions translated in optional and extra, and steeply dropping to only a couple of percentpoints for those after that. Not sure which statistics you're looking at, perhaps these? [1] Sure, maybe the top language has only 33% of optional done, but several languages cover the entire base install. Additionally, the numbers are not fixed. As many (most?) descriptions are shared between etch and sid, even after etch is released the descriptions will keep getting updated and improved. Best translated are required/important/standard, but those descriptions will be the least relevant to Joe Average, since these packages are already installed for him. The goal should be making sure that most of the packages people have installed are translated, as well as the most popular packages. That is a much more acheivable goal, and I think that's attainable in the near future... I hope you're not suggesting we need to get all languages covering all of optional before you think it is worthwhile? As for whether it's enough to make it happen for etch, that's not my call. But the vast majority of descriptions for etch+1 will be usable for etch also, so the decision should *not* be based on whether the descriptions are ready now. Have a nice day, [1] http://svana.org/kleptog/temp/ddts-stats.html -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Would an ABI change of apt for DDTP support still be accepted?
On Mon, Oct 02, 2006 at 01:17:18PM +0200, Thijs Kinkhorst wrote: On Mon, 2006-10-02 at 11:54 +0200, Jens Seidel wrote: I value the importance of the DDTP project, but the translating effort has only recently seriously started. Looking at the statistics[1], I see The first DDTP translation effort started years ago (over 4, actually) and it was quite serious at the time for some languages. It was stalled due to gluck's compromise and recently restarted. that the best language has yet only one third of descriptions translated in optional and extra, and steeply dropping to only a couple of percentpoints for those after that. This is very much related to the fact that the language teams see no gain for translating the DDTP right now since end-users would not be able to see them, as there is no support in apt or its frontends. A change in apt to make those visible when users run 'apt-cache search|show' even if apt frontends (aptitude, synaptic) do not use them yet would certainly make translation teams shift their efforts over to the DDTP. Just my 2c. Javier signature.asc Description: Digital signature
Re: Would an ABI change of apt for DDTP support still be accepted?
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: On Mon, Oct 02, 2006 at 01:17:18PM +0200, Thijs Kinkhorst wrote: On Mon, 2006-10-02 at 11:54 +0200, Jens Seidel wrote: I value the importance of the DDTP project, but the translating effort has only recently seriously started. Looking at the statistics[1], I see The first DDTP translation effort started years ago (over 4, actually) and it was quite serious at the time for some languages. It was stalled due to gluck's compromise and recently restarted. And my first APT patch was release in 2003[1]. As anyone can notice, it's not new. 1. http://lists.debian.org/debian-devel-announce/2003/04/msg00015.html -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house.
Re: intent to do a poppler transition
On 2006-10-02 09:56:50 -0400 Norbert Preining [EMAIL PROTECTED] wrote: On Mon, 02 Okt 2006, Ond??ej Surý wrote: poppler 0.5.4 (f.d.o PDF rendering library) was declared stable by upstream and I would like to upload new version to unstable which changes SONAME from 0 to 1. No API changes were done between 0.4.x and 0.5.x so just rebuild with new libpoppler-dev should be enough. Also I remember a patch in the bts that should make tetex/texlive ready for poppler 0.5, the patch came from the ubuntu people which are shipping 0.5. (http://patches.ubuntu.com/t/texlive-bin/texlive-bin_2005.dfsg.1-1ubuntu2.patch) Hmm... If the API has changed, then shouldn't the -dev package name be bumped? -- Hubert Chan - email Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Re: hypothetical bin-NMU versioning question
Andreas Metzler wrote: On 2006-10-02 Kevin B. McCarty [EMAIL PROTECTED] wrote: I have a hypothetical bin-NMU versioning question (this is asked only for my curiosity, so don't give it a high priority). Suppose that package X (version 1.0-1) is bin-NMU'ed on architectures A and B. At a later time it needs to be bin-NMU'ed on architectures B and C. [snip] It was at 0.2.12-1+b1: amd64 s390 0.2.12-1: alpha arm hppa i386 ia64 kfreebsd-i386 m68k mips mipsel powerpc sparc previously and is now 0.2.12-1+b2: amd64 0.2.12-1+b1: alpha arm hppa i386 ia64 kfreebsd-i386 m68k mips mipsel powerpc s390 sparc Afaict the numbering is simply increased for each upload. Thanks for the clear and decisive answer! best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#390637: Remove some architectures for vzctl
Hi On Mon, Oct 02, 2006 at 06:19:07PM +0100, Adam D. Barratt wrote: Hi, On Mon, 2006-10-02 at 15:50 +0100, Adam D. Barratt wrote: Hi, On Monday, October 02, 2006 10:50 AM, Ola Lundqvist [EMAIL PROTECTED] wrote: I'm writing this to request the removal of some built packages from unstable/testing. You'll need to ask the Release Team ([EMAIL PROTECTED]) in order to get the packages removed from testing. *sigh* Suddenly realised that was a little imprecise. You'll need to ask the RMs to remove the packages from testing *if you want them removed before they would naturally fall out of testing*. (To expand slightly, I tend to interpret remove from unstable / testing as meaning remove from unstable and testing at the same time, on the basis that otherwise testing doesn't need to be mentioned because packages removed from unstable will automagically get removed from testing when there's nothing keeping them there. I possibly shouldn't assume that...) I see. Well if they fall out now or in a week or two do not matter to me. I have updated the architecture list so now it should only build on the interesting architectures. One question. If I change the architecture list (remove or add). Do you need to manually do things in order for it to take effect (especially remove) or can I control it myself this way? Regards, // Ola Regards, Adam -- --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering / [EMAIL PROTECTED] Annebergsslingan 37\ | [EMAIL PROTECTED] 654 65 KARLSTAD| | http://opalsys.net/ Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xen 3.0.3 for Etch
On Mon, Oct 02, 2006 at 06:26:27PM -0300, Otavio Salvador wrote: The kernels works to both, dom0 and domU. You use same kernel image. I think that the only difference is that the domU kernels do not require any sort of traditional hardware support (chipsets, NICs, etc), but it does not hurt anything if they are still in there. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Xen 3.0.3 for Etch
Roberto C. Sanchez [EMAIL PROTECTED] writes: On Mon, Oct 02, 2006 at 06:26:27PM -0300, Otavio Salvador wrote: The kernels works to both, dom0 and domU. You use same kernel image. I think that the only difference is that the domU kernels do not require any sort of traditional hardware support (chipsets, NICs, etc), but it does not hurt anything if they are still in there. There's the linux-modules package to make it work better ;-) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: intent to do a poppler transition
Dear Ondrej! Can you now tell us what the status is? It is a bit unclear for me? I can create new packages for texlive-bin with the changed patch, or leave it. Are the packages you want to upload to unstable already in experimental, or available in any other place? If yes I could at least try in my cowbuilder whether building works. Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Università di Siena Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- DALRYMPLE (n.) Dalarymples are the things you pay extra for on pieces of hand-made craftwork - the rough edges, the paint smudges and the holes in the glazing. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Remove some architectures for vzctl]
On Mon, Oct 02, 2006 at 04:51:44PM +0200, Ola Lundqvist wrote: The response from the following bug #390637 was that I need to inform the release team and request the removal by them. That response is incorrect. You're requesting binary removal, not source removal; binary removal is handled entirely by the ftp team, with no manual intervention from the release team. -- 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: Xen 3.0.3 for Etch
Jim Crilly [EMAIL PROTECTED] writes: On 10/01/06 05:08:51PM +0200, Bastian Blank wrote: Hi folks Upstream forked a 3.0.3 tree a week ago. I hope they will release it in the next two weeks. I think it will be a good idea to release this with Etch. This may be also a good target as RHEL5 will also release with Linux 2.6.18 (we use their xen patch for the kernel already) and Xen 3.0.3. My current plan is: - Upload 3.0.3-testing with version 3.0.3~rc1+hg$revision and abi 3.0.3-rc1. - Let it migrate to testing. - Update kernel to use this one as first option instead of only 3.0-unstable-1. - Remove xen-unstable from testing after anything else is migrated. Comments? Currently it looks like you're just shipping dom0 kernels, are there any plans to ship domU kernels too? The kernels works to both, dom0 and domU. You use same kernel image. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xen 3.0.3 for Etch
On 10/01/06 05:08:51PM +0200, Bastian Blank wrote: Hi folks Upstream forked a 3.0.3 tree a week ago. I hope they will release it in the next two weeks. I think it will be a good idea to release this with Etch. This may be also a good target as RHEL5 will also release with Linux 2.6.18 (we use their xen patch for the kernel already) and Xen 3.0.3. My current plan is: - Upload 3.0.3-testing with version 3.0.3~rc1+hg$revision and abi 3.0.3-rc1. - Let it migrate to testing. - Update kernel to use this one as first option instead of only 3.0-unstable-1. - Remove xen-unstable from testing after anything else is migrated. Comments? Currently it looks like you're just shipping dom0 kernels, are there any plans to ship domU kernels too? Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xen 3.0.3 for Etch
On 10/02/06 06:26:27PM -0300, Otavio Salvador wrote: The kernels works to both, dom0 and domU. You use same kernel image. Nice, I didn't know that was possible. Is that mentioned in the docs somewhere, although I admit I didn't look very hard. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
