Bug#1058545: due to #1058653
block 1058545 by 1058653 tag 1058545 + patch thanks Hi, This is due to > dh_installdocs: error: Cannot find (any matches for) "doc/Esnacc.pdf" (tried in .) which is due to (cd /home/rene/esnacc-1.8.1/doc && unzip eSNACCManuals.zip && libreoffice --headless --convert-to pdf Esnacc.doc) Archive: eSNACCManuals.zip inflating: EsnaccOriginalMaterial.doc inflating: Esnacc.doc Warning: failed to launch javaldx - java may not function correctly Error: source file could not be loaded (the last message is it, the javaldx warning is harmless) failing. Which is due to a bug in libreoffice which is fixed by libreoffice (4:24.2.0-2) experimental; urgency=medium * debian/patches/sw-do-not-require-cui.diff: do not require cui in sw, from upstream (closes: #1058653) which is fixed but (well, it's followers) are held up by the time_t transition. (So this bug is not there anymore when building in sid) Workaround (as other packages did) is to build-deped on libreoffice-writer for now (instead of libreoffice-writer-nogui). Or just wait until said fix is in testing (whenever that may be) Regards, Rene
Bug#1066970: FTBFS: error: implicit declaration of function 'InitNibbleMem' [-Werror=implicit-function-declaration]
Source: esnacc Version: 1.8.1-3 Severity: serious Justification: FTBFS Tags: sid ftbfs User: lu...@debian.org Usertags: ftbfs-impfuncdef Hi, esnacc FTBFS: gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -I./asn1specs -I./asn1specs -I./c-lib/inc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/rene/esnacc-1.8.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O0 -Wall -Wextra -c -o c-examples/simple/sbuf-sbuf-ex.o `test -f 'c-examples/simple/sbuf-ex.c' || echo './'`c-examples/simple/sbuf-ex.c /bin/bash ./libtool --tag=CC --mode=link gcc -I./asn1specs -I./asn1specs -I./c-lib/inc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/rene/esnacc-1.8.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O0 -Wall -Wextra -Wl,-z,relro -o c-examples/simple/sbuf asn1specs/c_examples_simple_sbuf-p-rec.o c-examples/simple/sbuf-sbuf-ex.o c-lib/libcasn1.la -lm libtool: link: gcc -I./asn1specs -I./asn1specs -I./c-lib/inc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/rene/esnacc-1.8.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O0 -Wall -Wextra -Wl,-z -Wl,relro -o c-examples/simple/.libs/sbuf asn1specs/c_examples_simple_sbuf-p-rec.o c-examples/simple/sbuf-sbuf-ex.o c-lib/.libs/libcasn1.so -lm -pthread gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -I./c-lib/inc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/rene/esnacc-1.8.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O0 -Wall -Wextra -c -o c-examples/test-lib/testlib-test-lib.o `test -f 'c-examples/test-lib/test-lib.c' || echo './'`c-examples/test-lib/test-lib.c c-examples/test-lib/test-lib.c: In function 'main': c-examples/test-lib/test-lib.c:68:5: error: implicit declaration of function 'InitNibbleMem' [-Werror=implicit-function-declaration] 68 | InitNibbleMem (256, 256); | ^ [...] This is most likely caused by a change in dpkg 1.22.6, that enabled -Werror=implicit-function-declaration. For more information, see https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration Indeed a build with export DEB_BUILD_MAINT_OPTIONS=qa=-bug-implicit-func works. But better than disabling it would be to fix it of course ;) Regards, Rene
Re: Question regarding time_t transition
Hi, Am 12.03.24 um 15:17 schrieb Raphaël Halimi: Are we supposed to report bugs against packages ending up with "t64" and missing the "Provides: " for affected architectures like armhf ? That Provides: is there for archs where the transition *doesn't* make a difference. In Debian: Anything except armel/armhf. (ignoring ports where the 32bit archs are in the same boat as armel/armhf ttbomk) So the packages not having a Provides: on armel/armhf are correct. Or are they intentional and we should wait for the package to be tested/ready/whatever ? Intentional, yes. Regards, Rene
Bug#964262: FTBFS: needs updated build-depends; needs to build-depend on libreoffice-dev-gui
Source: openclipart Version: 1:0.18+dfsg-17 Severity: serious Dear Maintainer, Hi, as discussed back then in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952347 gengal was moved to libreoffice-dev-gui for the 7.x LO packages. These got uploaded to sid now [1]. Please build-depend on (the hopefully soon available) libreoffice-dev-gui. Regards, Rene [1] unfortunately thay are BD-Uninstallable anywhere due to the bsdmainutils mess (#)964242 but.: libreoffice build-depends on: - javahelper:amd64 (>= 0.37~) javahelper depends on: - bsdmainutils:amd64 bsdmainutils depends on missing: - bsdextrautils:amd64 (>= 2.35.2-7)
Re: Bug#952347: Processed: reassign 952347 to libreoffice-dev, affects 952347
Hi, On Sat, Mar 14, 2020 at 12:36:34PM +0100, Rene Engelhard wrote: > On Sat, Mar 14, 2020 at 12:20:00PM +0100, Andreas Beckmann wrote: > > Since you already have a gengal wrapper script, you could check for > > libreoffice-core being installed and error out with "please install > > libreoffice-core instead of libreoffice-core-nogui to use this tool" > > instead of failing with a weird missing symbol. > > Which wouldn't really help here as stuff will still "FTBFS" if they only used > -core-nogui, but yeah, one can add this nevertheless. https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/f16f367fcee34e6036053d85e68fc2f53a07732f Regards, Rene
Re: Processed: reassign 952347 to libreoffice-dev, affects 952347
Hi, On Sat, Mar 14, 2020 at 12:36:34PM +0100, Rene Engelhard wrote: > Thinking about this now actually, maybe it suffices to use a > --disable-gui version of gengal.bin for -dev here... Will try.. Hmm, no, won't work. We don't build the nogui variant everywhere (double build), so we'd get a problem still on arm* (except arm64), mips*. Regards, Rene
Re: Processed: reassign 952347 to libreoffice-dev, affects 952347
On Sat, Mar 14, 2020 at 12:20:00PM +0100, Andreas Beckmann wrote: > On 14/03/2020 09.51, Rene Engelhard wrote: > > Maybe split it out to a new libreoffice-dev-gui package or somesuch? (That > > would need NEW though, > > and thus will only be done with the 7.0 packages)? But a tiny package just > > for this tool... (that's why > > it was consumed in the -dev package.) > I'd go the libreoffice-gui-dev way, it will avoid this kind of confusion I had planned on -dev-gui. (To match to current -core vs. -core-nogui etc.) Strictly speaking gengal.bin is not a GUI tool anyway, it seems though it's just happens to be linked with GUI libs/glx functions. Thinking about this now actually, maybe it suffices to use a --disable-gui version of gengal.bin for -dev here... Will try.. But then we still would need it for ui-previewer... Though I am actually not sure this is used anywhere except for "core" LibreOffice development > in the future. Postponing to 7 (or any other reason to go through NEW) > is fine. OK, already done for the 7.0 packages: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952347#29 If the above hack will work, one might be able to revert that :-) > > Or Recommends: libreoffice-core, though that probably wouldn't be honoured > > by sbuild > Yep, Recommends is not sufficient. > > Since you already have a gengal wrapper script, you could check for > libreoffice-core being installed and error out with "please install > libreoffice-core instead of libreoffice-core-nogui to use this tool" > instead of failing with a weird missing symbol. Which wouldn't really help here as stuff will still "FTBFS" if they only used -core-nogui, but yeah, one can add this nevertheless. Regards, Rene
Re: Processed: reassign 952347 to libreoffice-dev, affects 952347
retitle 952347 /usr/lib/libreoffice/program/gengal.bin: symbol lookup error:
/usr/lib/libreoffice/program/gengal.bin: undefined symbol: _Z10getGlxPipev with
libreoffice-core-nogui installed
clone 952347 -1
reassign -1 src:openclipart
retitle -1 openclipart: please add a explicit build-dependency on
libreoffice-core
thanks
Hi,
On Fri, Mar 13, 2020 at 10:54:11PM +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
>
> > reassign 952347 libreoffice-dev 1:6.4.1~rc1-2
> Bug #952347 [src:openclipart] openclipart: FTBFS:
> /usr/lib/libreoffice/program/gengal.bin: symbol lookup error:
> /usr/lib/libreoffice/program/gengal.bin: undefined symbol: _Z10getGlxPipev
> Bug reassigned from package 'src:openclipart' to 'libreoffice-dev'.
> No longer marked as found in versions openclipart/1:0.18+dfsg-15.
> Ignoring request to alter fixed versions of bug #952347 to the same values
> previously set
> Bug #952347 [libreoffice-dev] openclipart: FTBFS:
> /usr/lib/libreoffice/program/gengal.bin: symbol lookup error:
> /usr/lib/libreoffice/program/gengal.bin: undefined symbol: _Z10getGlxPipev
> Marked as found in versions libreoffice/1:i6.4.1~rc1-2.
Glx is GUI stuff.
Indeed, in the bug the buildlog shows:
[...]
Get:229 http://127.0.0.1:/debian sid/main amd64
libreoffice-core-nogui amd64 1:6.4.1~rc1-2 [29.4 MB]
Get:230 http://127.0.0.1:/debian sid/main amd64
libreoffice-dev-common all 1:6.4.1~rc1-2 [1571 kB]
[...]
And -devs Depends: allow -core-nogui first:
Package: libreoffice-dev
Section: devel
Architecture: alpha amd64 arm64 armel armhf hppa i386 ia64 kfreebsd-amd64
kfreebsd-i386 m68k mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el
s390 s390x sparc sparc64
Depends: libreoffice-core-nogui (= ${binary:Version}) | libreoffice-core (=
${binary:Version}),
libreoffice-dev-common (= ${source:Version}),
${idlc-cpp-depends},
${misc:Depends},
${shlibs:Depends}
Recommends: g++, ${java-common-depends}, ${java-runtime-depends}
[...]
With -core installed, it just works:
root@frodo:/# dpkg -l libreoffice-core libreoffice-core-nogui
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==-=--=
ii libreoffice-core 1:6.4.2~rc2-1 amd64office productivity suite
-- arch-dependent files
un libreoffice-core-nogui(no description available)
root@frodo:/# /usr/lib/libreoffice/program/gengal.bin
Utility to generate LibreOffice gallery files
using: gengal --name --path [ --destdir ]
[ files ... ]
options:
--name defines the user visible name of the created or updated
theme.
--pathdefines directory where the gallery files are created
or updated.
--destdir defines a path prefix to be removed from the paths
stored in the gallery files. It is useful to create
RPM packages using the BuildRoot feature.
--relative-urlsflags that after removing the destdir, the URL
should be a path relative to the gallery folder in the install
primarily used for internal gallery generation at
compile time.
theme files.
files lists files to be added to the gallery. Absolute paths
are required.
root@frodo:/# apt -t experimental install libreoffice-core-nogui
Reading package lists... Done
Building dependency tree
Reading state information... Done
Recommended packages:
libpaper-utils
The following packages will be REMOVED:
libreoffice libreoffice-calc libreoffice-core
The following NEW packages will be installed:
libreoffice-core-nogui
0 upgraded, 1 newly installed, 3 to remove and 116 not upgraded.
Need to get 29.4 MB of archives.
After this operation, 38.2 MB disk space will be freed.
Do you want to continue? [Y/n]
Get:1 http://deb.debian.org/debian experimental/main amd64
libreoffice-core-nogui amd64 1:6.4.2~rc2-1 [29.4 MB]
Fetched 29.4 MB in 5s (5617 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
debconf: delaying package configuration, since apt-utils is not installed
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (2: No such
Bug#915060: link-grammar: autopkgtest relies on built binaries without matching dependencies
Source: link-grammar Version: 5.5.0-1 Severity: serious Hi, $ cat debian/tests/control Tests: unit-tests Depends: @, python3-distutils, build-essential, hunspell-en-us, locales-all, default-jdk [!hppa !hurd-i386 !m68k !sh4], Restrictions: build-needed So far so good. But that means that in the testing migration autopkgtests this breaks when there is a hunspell transition. See e.g. https://ci.debian.net/data/autopkgtest/testing/amd64/l/link-grammar/1399248/log.gz What seems to happen (correct me if I am wrong) is: 1. link-grammar gets built. Because the autopkgtest injects libhunspell 1.7 somehow into the build this one is built against libhunspell-1.7. 2. Now the test packages get installed in a clean environment. Because you just say "@" you get the dependencies from your own package (libhunspell-1.6) , not the built one (as should be, indeed) 3. The test now fails because it cannot open the libhunspell-1.7.so.0 because what was installed for 2. was just libhunspell-1.6. Maybe you want to add at least @builddeps@? But that would only hide the problem... Regards, Rene
Bug#862126: 1.14, obviously...
retitle 862135 src:zookeeper: FTBFS with cppunit 1.14
AM_PATH_CPPUNIT/cppunit-config removed)
retitle 862134 src:drumgizmo: FTBFS with cppunit 1.14
(AM_PATH_CPPUNIT/cppunit-config removed)
retitle 862133 src:gnuradio: FTBFS with cppunit 1.14 (no C++11 support,
required by cppunit)
retitle 862132 src:jags: FTBFS with cppunit 1.14 (cppunit-config removed,
errors ignored)
retitle 862131 src:rtorrent: FTBFS with cppunit 1.14
(AM_PATH_CPPUNIT/cppunit-config removed)
retitle 862130 src:mpd: FTBFS with cppunit 1.14 ("cannot use typeid with
-fno-rtti")
retitle 862129 src:libtorrent: FTBFS with cppunit 1.14
(AM_PATH_CPPUNIT/cppunit-config removed)
retitle 862128 src:ola: FTBFS with cppunit 1.14
retitle 862127 src:sipxtapi: FTBFS with cppunit 1.14
(AM_PATH_CPPUNIT/cppunit-config removed)
retitle 862126 src:zipios++: FTBFS with cppunit 1.14 (cppunit-config removed,
errors ignored)
retitle 862125 src:libfilezilla: FTBFS with cppunit 1.14 (cppunit-config
removed, errors ignored)
thanks
Regards,
Rene
Hi,
gah. I apparently shouldn't type stuff manually when tired
of course everywhere where I said 0.14 I mean 1.14 :)
Regards,
Rene
Bug#862126: src:zipios++: FTBFS with cppunit 0.14 (cppunit-config removed, errors ignored)
Package: src:zipios++
Version: 0.1.5.9+cvs.2007.04.28-6
Severity: normal
Dear Maintainer,
[ cppunit 0.14 is not in Debian yet, see #861718. Thus normal for now ]
On a rebuild test using ratt I noticed your package doesn't build with
cppunit 0.14:
[...]
dh build --with autotools-dev
dh_testdir
dh_update_autotools_config
dh_autotools-dev_updateconfig
dh_auto_configure
./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefi
x}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysco
nfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\${prefix}/lib/x
86_64-linux-gnu --libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintaine
r-mode --disable-dependency-tracking
[...]
checking for cppunit-config... no
checking for Cppunit - version >= 1.6.0... no
[...]
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating tests/Makefile
config.status: creating zipios++/Makefile
config.status: creating zipios++.spec
config.status: creating zipios++/zipios-config.h
config.status: executing depfiles commands
[...]
So here it doesn't find cppunit-config (cppunit-config was removed in
0.14.0) but still continues. Which then "of course" fails since there's
no -lcppunit on linking:
[...]
g++ -g -O2 -fdebug-prefix-map=/build/zipios++-Fhjwwq/zipios++-0.1.5.9+cvs.2007.0
4.28=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relr
o -o .libs/all_tests all_tests-all_tests.o all_tests-zipfiletest.o all_tests-zip
inputstreamtest.o all_tests-zipoutputstreamtest.o all_tests-commontest.o ../src
/.libs/libzipios.so -lz
all_tests-zipfiletest.o: In function `zipios::ZipFileTest::writeFileToZipOutputS
tream(zipios::ZipOutputStream&, std::__cxx11::basic_string const&)':
./tests/zipfiletest.cpp:82: undefined reference to `CppUnit::SourceLine::SourceL
ine(std::__cxx11::basic_string const&, int)'
./tests/zipfiletest.cpp:82: undefined reference to `CppUnit::Message::Message(st
d::__cxx11::basic_string co
nst&, std::__cxx11::basic_string const&)'
./tests/zipfiletest.cpp:82: undefined reference to `CppUnit::Asserter::fail(CppU
nit::Message const&, CppUnit::SourceLine const&)'
./tests/zipfiletest.cpp:82: undefined reference to `CppUnit::Message::~Message()
'
./tests/zipfiletest.cpp:82: undefined reference to `CppUnit::SourceLine::~Source
Line()'
[...]
collect2: error: ld returned 1 exit status
Makefile:323: recipe for target 'all_tests' failed
make[2]: *** [all_tests] Error 1
make[2]: Leaving directory '/build/zipios++-Fhjwwq/zipios++-0.1.5.9+cvs.2007.04.
28/tests'
Makefile:241: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/build/zipios++-Fhjwwq/zipios++-0.1.5.9+cvs.2007.04.
28'
dh_auto_build: make -j1 returned exit code 2
debian/rules:6: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
cppunit 0.14 removed cppunit-config.
You should use pkg-config for it now. (that one is available since
long.)
I put my package for testing to
https://people.debian.org/~rene/libreoffice/5.4/cppunit/
Regards,
Rene
Bug#818907: live-build: Fails to integrate a binary package whose name contains an uppercase character
Hi, I am not involved in live-build, but: On Mon, Mar 21, 2016 at 04:41:18PM +0100, Raphaël Hertzog wrote: > If you download a Nessus deb from here: > https://www.tenable.com/products/nessus/select-your-operating-system > > You get a Nessus-6.5.6-debian6_amd64.deb file for a "Nessus" package. > Note the uppercase N in the package name... (both in the filename and > in the .deb meta-data shown with dpkg -I) Which is broken. https://www.debian.org/doc/debian-policy/ch-binary.html#s3.1 points to https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Package which points to https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source which says "Package names (both source and binary, see Package, Section 5.6.7) must consist only of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). They must be at least two characters long and must start with an alphanumeric character." I don't think it is a bug if one can't handle a broken package. > Put that file in config/packages.chroot/ and try a live-build, you will > get an error like this: > [2016-03-19 19:50:13] lb chroot_install-packages install > P: Begin installing packages (install pass)... > Reading package lists... > Building dependency tree... > Reading state information... > E: Unable to locate package Nessus And isn't this apt/aptitude here, anyways? So it would be apt/aptitude "bug"? Regards, Rene
Bug#788970: abiword: please adapt for libwps 0.4
Source: abiword Version: 1:3.0.0-8 Severity: wishlist Tags: patch See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786713. libwps 0.4 was released in May and we should transition to that, especially because LibreOffice 5.0 strictly needs = 0.4 and won't work/build with earlier ones. As I mentioned in the first message to the above bug - thankfully the diff is trivial, as demonstrated by the official patch I mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786713.#15 which is http://pkgs.fedoraproject.org/cgit/abiword.git/commit/?id=1482cf1f893b6378f6c868a1f12b7bd366d6 Regards, Rene -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150616175233.gb3...@rene-engelhard.de
Bug#751577: docvert-libreoffice: outdated; new upstream release available
Package: docvert-libreoffice Version: 4.0+dfsg-1 Severity: wishtlist Hi, docvert is outdated in Debian. Debian contains a 4.0+dfsg-1 while looking on http://static.holloway.co.nz/docvert/news.html the have been releases: Docvert 6 2nd April 2014 Ported Docvert to Python 3! Docvert 5.2 2nd February 2014 Bugfixes. Docvert 5.1 16th August 2011 Improved list handling. Improved UI. Feature parity with Docvert 4.0 (for conversions) Docvert 5.0 28th March 2011 Ported Docvert to Python Security improvements Speed improvements Docvert 4.0 Beta 1 November 8th 2010 Here's the download page Improved support for EMF/WMF (requires PyODConverter with OOo Server) Replacing crappy homebrewed XML parser with SimpleXML. Should work identically, if you need the old behaviour then there's deprecated_xmlStringToArray() Minor bugfixes to PyODConverter. PLEASE NOTE: PyODConverter with OOo Server is strongly recommended, all other converters are now deprecated and may be removed in the future. Save yourself the hassle and move now. Note that there never was a 4.0 (but only a 4.0 beta1, so the Version string in Debian is wrong). Anyways, from what I see there the Security improvements and Ported Docvert to Python 3 fall into my mind. The latter one is the fix for #707340 which gets us nearer to the removal of the legacy python-uno... Regards, Rene -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140614133305.ga...@rene-engelhard.de
Bug#707340: fixed in docvert 6 upstream
block 707340 by 751577 thanks This bug (707340) was already (silently) tagged upstream by taffit some weeks ago (https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=14;bug=707340) but to make it clear: docvert 6.0 was released in April, which says: ### snip ### Docvert 6 2nd April 2014 Ported Docvert to Python 3! ### snip ### and additionally to that actually even mentions python3-uno in README.md: ### snip ### Requirements Python 3 libreoffice python3-uno python-lxml python-imaging pdf2svg librsvg2-2 Quickstart Guide sudo apt-get install libreoffice python3-uno python-lxml python3-imaging pdf2svg librsvg2-2 ### snip ### it explicitely talks about python3-uno. So docvert should be updated to 6.0.. David, (or anyone of QA) are you going to do that? Regards, Rene -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140614134555.ga6...@rene-engelhard.de
Bug#751577: docvert-libreoffice: outdated; new upstream release available
Hi, On Sat, Jun 14, 2014 at 03:33:05PM +0200, Rene Engelhard wrote: docvert is outdated in Debian. Debian contains a 4.0+dfsg-1 while looking on http://static.holloway.co.nz/docvert/news.html the have been releases: Docvert 6 2nd April 2014 Ported Docvert to Python 3! [...] Ported Docvert to Python 3 fall into my mind. The latter one is the fix for #707340 which gets us nearer to the removal of the legacy python-uno... I just updated 707340 with that info (was just silently tagged fixed-upstream in May). Either docvert should be updated to 6.0 - David, (or anyone of QA) are you going to do that? - or just simply be removed. Regards, Rene -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140614134922.ga8...@rene-engelhard.de
Bug#707340: retitle; package is back to python3-uno
retitle 707337 please support python3 (and python3-uno) retitle 707338 please support python3 (and python3-uno) retitle 707339 please support python3 (and python3-uno) retitle 707340 please support python3 (and python3-uno) retitle 707341 please support python3 (and python3-uno) retitle 707342 please support python3 (and python3-uno) retitle 707343 please support python3 (and python3-uno) thanks Hi, as python3 is now defaulting to 3.3 I was able to revert python3.3-uno back to python3-uno. Regards, Rene -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130715212532.ga8...@rene-engelhard.de
Re: Accepted sane-backends 1.0.23-1 (source amd64)
Hi, On Thu, Jul 04, 2013 at 05:34:08PM +, Markus Koschany wrote: * Build-Depend on libtiff5-dev. Thanks to Michael Terry for the patch. (Closes: #681079) You shouldn't apply something like that without verifying stuff.. People file such stuff even when the stuff isn't yet ready.. (see also Especially as the transition hasn't been started yet in any way (nothing on release.debian.org) This now breaks building of packages which build-depend on libsane-dev and other packages which still use libtiff4-dev (example: libreoffice): Dist-upgrade wants to remove libsane-dev and when I try it explicitely: (sid)root@frodo:/# apt-get -s install libsane-dev Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: hdf5-helpers libhdf5-dev libhdf5-serial-dev libvigraimpex4 Use 'apt-get autoremove' to remove them. The following extra packages will be installed: liblzma-dev libsane libsane-common libtiff5-dev libtiffxx5 libusb-1.0-0-dev Suggested packages: liblzma-doc hpoj Recommended packages: libsane-extras-dev The following packages will be REMOVED: libtiff4-dev libvigraimpex-dev The following NEW packages will be installed: liblzma-dev libtiff5-dev libtiffxx5 libusb-1.0-0-dev The following packages will be upgraded: libsane libsane-common libsane-dev 3 upgraded, 4 newly installed, 2 to remove and 0 not upgraded. Inst libsane-dev [1.0.22-7.4] (1.0.23-2 Debian:unstable [amd64]) [] Inst libsane [1.0.22-7.4] (1.0.23-2 Debian:unstable [amd64]) [] Inst libsane-common [1.0.22-7.4] (1.0.23-2 Debian:unstable [amd64]) [] Inst libtiffxx5 (4.0.3-1 Debian:unstable [amd64]) [] Inst liblzma-dev (5.1.1alpha+20120614-2 Debian:unstable [amd64]) [] Remv libvigraimpex-dev [1.9.0+dfsg-6] [] Remv libtiff4-dev [3.9.7-1] [] Inst libtiff5-dev (4.0.3-1 Debian:unstable [amd64]) [] Inst libusb-1.0-0-dev (2:1.0.15-1 Debian:unstable [amd64]) Conf libsane-common (1.0.23-2 Debian:unstable [amd64]) Conf libsane (1.0.23-2 Debian:unstable [amd64]) Conf libtiffxx5 (4.0.3-1 Debian:unstable [amd64]) Conf liblzma-dev (5.1.1alpha+20120614-2 Debian:unstable [amd64]) Conf libtiff5-dev (4.0.3-1 Debian:unstable [amd64]) Conf libusb-1.0-0-dev (2:1.0.15-1 Debian:unstable [amd64]) Conf libsane-dev (1.0.23-2 Debian:unstable [amd64] Please revert and wait for a *coodinated* transition here. Regards, Rene -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130706123622.gf13...@rene-engelhard.de
Re: Accepted sane-backends 1.0.23-1 (source amd64)
Hi, On Sat, Jul 06, 2013 at 02:36:22PM +0200, Rene Engelhard wrote: Please revert and wait for a *coodinated* transition here. Ah, well, it's maintained by QA anyway... Done myself. Regards, Rene -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130706131752.gg13...@rene-engelhard.de
Bug#715163: sane-backends: unsatisfiable build-depends on libusb-1.0.0-dev on kfreebsd-*
Package: sane-backends Version: 1.0.23-1 Severity: serious [ X-Debbugs-Cc to Markus, who introduced this. ] Hi, sane-backends (1.0.23-1) unstable; urgency=low [...] * Build-Depend on libusb-1.0-0-dev and enable libusb1.0 support in debian/rules. Thanks to Martin Pitt for the report and Whoopie for the patch. (Closes: #687137) -- Markus Koschany a...@gambaru.de Thu, 04 Jul 2013 17:41:47 +0200 Looking at control: Build-Depends: autotools-dev, chrpath, debhelper (= 9), gettext, libavahi-client-dev, libcam-dev [kfreebsd-any], libgphoto2-2-dev, libieee1284-3-dev [!hurd-i386], libjpeg-dev, libltdl3-dev, libtiff4-dev, libusb-1.0-0-dev [!hurd-i386], libv4l-dev [linux-any], pkg-config, po-debconf, texlive, texlive-latex-extra, xutils-dev This is broken. Because: $ rmadison libusb-1.0-0-dev libusb-1.0-0-dev | 2:1.0.8-2 | squeeze | amd64, armel, i386, ia64, mips, mipsel, powerpc, s390, sparc libusb-1.0-0-dev | 2:1.0.11-1 | wheezy | amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc libusb-1.0-0-dev | 2:1.0.15-1 | jessie | amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc libusb-1.0-0-dev | 2:1.0.15-1 | sid | amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc libusb-1.0-0-dev doesn't (and never did) exist on kfreebsd-*. Which now means that sane-backends will not be built there (it's BD-Uninstallable, see https://buildd.debian.org/status/package.php?p=sane-backends) Probably it should also be disabled for kfreebsd-* as for hurd? Or some alternative used... Regards, Rene -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130706134947.ga26...@rene-engelhard.de
Bug#681079: [r...@debian.org: Accepted sane-backends 1.0.23-3 (source amd64)]
Hi, The fix in 1.0.23-1 need to be reverted, which I just did. Reasoning: http://lists.debian.org/debian-release/2013/07/msg00126.html - Forwarded message from Rene Engelhard r...@debian.org - Date: Sat, 06 Jul 2013 13:33:53 + From: Rene Engelhard r...@debian.org To: debian-devel-chan...@lists.debian.org Subject: Accepted sane-backends 1.0.23-3 (source amd64) Reply-To: debian-de...@lists.debian.org Format: 1.8 Date: Sat, 06 Jul 2013 15:20:16 +0200 Source: sane-backends Binary: sane-utils libsane-common libsane libsane-dev libsane-dbg Architecture: source amd64 Version: 1.0.23-3 Distribution: unstable Urgency: low Maintainer: Debian QA Group packa...@qa.debian.org Changed-By: Rene Engelhard r...@debian.org Description: libsane- API library for scanners libsane-common - API library for scanners -- documentation and support files libsane-dbg - API development library for scanners [debug symbols] libsane-dev - API development library for scanners [development files] sane-utils - API library for scanners -- utilities Changes: sane-backends (1.0.23-3) unstable; urgency=low . * QA upload * revert move to libtiff5-dev Checksums-Sha1: 406c154c0d63c249f2e6d61bc3e1f9cda4cb5960 2227 sane-backends_1.0.23-3.dsc 53c58b8189db31ff70aedbeb3df7ca05239a2303 57135 sane-backends_1.0.23-3.debian.tar.gz 11e8da63990930f3216fe34bd476e81dedc0428d 199306 sane-utils_1.0.23-3_amd64.deb 39522f7286f8a50209f6948c6690a1e78bcef3e4 747310 libsane-common_1.0.23-3_amd64.deb 7086bf8af92fa76ec47bc8b548dff5a3943e394d 1989868 libsane_1.0.23-3_amd64.deb 4743d4ef55f64757d8820cf6709c6f78aff0efe4 2146250 libsane-dev_1.0.23-3_amd64.deb a317d670a7d55b7afcd72bf56340a430561a2587 6653638 libsane-dbg_1.0.23-3_amd64.deb Checksums-Sha256: 90085c282c68103878d80a5a967ebbd5315922ddd46e1a6c4ee6cda0ac6e878b 2227 sane-backends_1.0.23-3.dsc 0df7d11d5014f8d3b4e42b30988e757d5a3105767e099f774995f4fa78685aee 57135 sane-backends_1.0.23-3.debian.tar.gz f2edbaaf03ced154d46400c22db5c480df7a3954a6307c726c0c0bca48f49adf 199306 sane-utils_1.0.23-3_amd64.deb 22c8b35480eca4f669765413e28400f47aa1b5e7b0762f825d46621cb1bc818d 747310 libsane-common_1.0.23-3_amd64.deb 404fb2e4f08ed31f5e9d2b71c51e1e4547e1800a09f5c190c9feb9c9b75e5343 1989868 libsane_1.0.23-3_amd64.deb ecb69461563eccaebae15282cb7803dd477cfa66584bc97a7412f76c3b9f601f 2146250 libsane-dev_1.0.23-3_amd64.deb 5786597e36c3ad4b0e2cc24f7856905b9147924dcfc6081d2e39e4551e770632 6653638 libsane-dbg_1.0.23-3_amd64.deb Files: d1b2088383e7f005db470b7268b991d8 2227 graphics optional sane-backends_1.0.23-3.dsc 93ffe25c8592366c359d47dad383863a 57135 graphics optional sane-backends_1.0.23-3.debian.tar.gz 6987bd0bdd31fe795bce1dc8d6dec6b7 199306 graphics optional sane-utils_1.0.23-3_amd64.deb 6d239e2403bb638a74ede7b79ab02ee7 747310 libs optional libsane-common_1.0.23-3_amd64.deb acf019d930217b40af42c98db446e880 1989868 libs optional libsane_1.0.23-3_amd64.deb 66442a7de3a6568d7c9d3e131c895131 2146250 libdevel optional libsane-dev_1.0.23-3_amd64.deb 089e6a89e1701e7fb34ee3dd8fc8c7d1 6653638 debug extra libsane-dbg_1.0.23-3_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uvscb-0003zw...@franck.debian.org - End forwarded message - Regards, Rene -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130706135122.gh13...@rene-engelhard.de
Bug#707340: please support python3 (and python3.3-uno)
Package: docvert-libreoffice Version: 4.0-7 Severity: wishlist Tags: upstream Hi, LibreOffice 4.0 switched to python 3.3 as its (internal) python[1] and the LibreOffice 4.x packages in Debian thus build a pyUNO variant for that per default (python3.3-uno until python 3.3 - yes, really, = 3.3 is needed - is default at which time it will become python3-uno again). While I keep a python-uno for compatibility and smooth transition[2] building against python 2 will only be supported for a few releases upstream. But upstream does NOT ship python 2 support. If your upstream wants to support LibreOffice = 4.0.0 (s)he does need to adapt to python 3.3. Possibly even makng it work for both[2], but = 3.3 is a must. Please adapt (or make your upstream adapt, as said above they need to do it anyway) for python3. Regards, Rene [1] https://wiki.documentfoundation.org/ReleaseNotes/4.0#Python [2] And it's cumbersome, it needs various hacks like a nasty copy pyuno, patch it to have different lib names, create symlink farm and some tests even don't run with python2 anymore in 4.1.x [3] as did LibreOffice itself, all LibreOffice packages have a python3.3-uno | python3-uno (= 4.0) | python-uno depends -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages docvert-libreoffice depends on: ii adduser 3.113+nmu3 pn docvert none ii libreoffice-core1:4.1.0~alpha1~git20130424-1 ii libreoffice-writer 1:4.1.0~alpha1~git20130424-1 ii lsb-base4.1+Debian9 pn pdf2svg none ii procps 1:3.3.4-2 ii python 2.7.3-4 ii python-uno 1:4.1.0~alpha1~git20130424-1 docvert-libreoffice recommends no packages. docvert-libreoffice suggests no packages. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130509074947.ge12...@rene-engelhard.de
Re: LibreOffice 4.0 and your package using pyUNO and python(3)-uno
Hi again, On Sun, Feb 03, 2013 at 09:31:39PM +0100, Rene Engelhard wrote: A import uno in a python2 shell with python-uno still works; but I'd prefer - if you tested your package against the new python-uno to check whether more complex stuff works ;) - if you tested your package with python3(.3) and python3-uno and add this as an alternative to your depends/recommends/suggests if your program works - if you tested your package with python3(.3) and python3-uno and add this dependency/suggestion to a new python3-* package Test-debs are on http://people.debian.org/~rene/libreoffice/4.0.0. To avoid confusion, because I forgot to reword this part of the long ago composed mail before sending: Yes, I tested that the new python based wizards and the grammar checking (lightproof) work with both still. But you never know... And there probably *will* be neeed to port your package to support either python3 only or both.. Regards, Rene -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130204122444.gc12...@rene-engelhard.de
Re: LibreOffice 4.0 and your package using pyUNO and python(3)-uno
Hi, On Sun, Feb 03, 2013 at 09:31:39PM +0100, Rene Engelhard wrote: [...] Now - with LibreOffice 4.0 - python3 is the *default* python for LibreOffice so python3-uno is the preferred package in LibreOffices dependencies. That said, because of API stuff and string changes etc[1] it needs *= 3.3*. Oh, one more. (This poopped up somewhen on IRC): That means your upstream needs to adapt _anyway_ as when you want to work with the stuff offered by upstream at their site they need to support python3.3. And they do not have a python2 version. Regards, Rene -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130204163941.gd12...@rene-engelhard.de
LibreOffice 4.0 and your package using pyUNO and python(3)-uno
Hi, since some months I am also building a python3-uno for pyUNO python3-uno | 1:3.5.4+dfsg-4 | wheezy| amd64, armel, armhf, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc python3-uno | 1:3.5.4+dfsg-4 | sid | amd64, armel, armhf, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc python3-uno | 1:3.6.4-1 | experimental | amd64, armel, i386, kfreebsd-amd64, kfreebsd-i386, powerpc, s390, s390x in addition to the normal python-uno as a _nice-to-have, use if you need_ package to try stuff against. Now - with LibreOffice 4.0 - python3 is the *default* python for LibreOffice so python3-uno is the preferred package in LibreOffices dependencies. That said, because of API stuff and string changes etc[1] it needs *= 3.3*. I will keep a pyUNO build against 2.6 around for sometime - unfortunately, building a second flavour (here: 2) is not as easy anymore as in the previous (upto 3.6 - at least for the pyuno module) buildsystem; now with GNU make we need a crude hack and a symlink farm. A import uno in a python2 shell with python-uno still works; but I'd prefer - if you tested your package against the new python-uno to check whether more complex stuff works ;) - if you tested your package with python3(.3) and python3-uno and add this as an alternative to your depends/recommends/suggests if your program works - if you tested your package with python3(.3) and python3-uno and add this dependency/suggestion to a new python3-* package Test-debs are on http://people.debian.org/~rene/libreoffice/4.0.0. I think the most important thing is to ensure that python-uno (2.7) still works as intended, after that we slowly[2] can migrate to python3-compatible stuff. Regards, Rene [1] TTOBMK, and for the API I wasn't able to fix the build; maybe I oversaw something really obvious, though... [2] Not that slowly, upstream only wants to keep python2 support for a few releases only -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130203203139.ga12...@rene-engelhard.de
Bug#663747: FTBFS with LibreOffice 3.5: basis-link gone/uninstallable with LibreOffice 3.5
Package: openclipart
Version: 2.0-1
Severity: important
Tags: patch
Hi,
I already fixed this in 0.18+dfsg-13 in experimental[1], which is now void
with your 2.0-1 upload to unstable. (-13 will get removed because it's lower
than unstable and apt will prefer 2.0-1 anyway)
LibreOffice 3.5 dropped the we change basisX.Y with every minor version
madness and thus also dropped basis-link. Which leads to the jodconverter
build not being able to have the Java classes of LO acctually available.
Besides that, this package even will get uninstallable when LibreOffice 3.5
enters sid.
Filing this as important for now but this bug will become serious when
LibreOffice
3.5.x gets uploaded to sid (and this *will* happen before the wheezy freeze)
What I did from -12 to -13 is:
diff -u openclipart-0.18+dfsg/debian/rules openclipart-0.18+dfsg/debian/rules
--- openclipart-0.18+dfsg/debian/rules
+++ openclipart-0.18+dfsg/debian/rules
@@ -81,7 +81,7 @@
# Create OOo gallery files; we need to add the files in hunks
# because we othererwise may get too many arguments
- mkdir -p $(CURDIR)/build/usr/lib/libreoffice/$(shell readlink
/usr/lib/libreoffice/basis-link)/share/gallery
+ mkdir -p $(CURDIR)/build/usr/lib/libreoffice/share/gallery
for dir in `find build/usr/share/openclipart/png -mindepth 1 -maxdepth
1 -type d | LC_CTYPE=C sort` ; do \
gal_name=$${dir##*/}; \
gal_oooname=`echo $$gal_name | awk '{gsub(_,
);a=toupper(substr($$0,1,1));b=substr($$0,2);print a b}'` ; \
@@ -90,7 +90,7 @@
split -d -l 250 build/$$gal_name.filelist
build/$$gal_name.filelist- ; \
for file in build/$$gal_name.filelist-*; do \
echo Processing filelist $$file; \
- SAL_USE_VCLPLUGIN=svp
/usr/lib/libreoffice/basis-link/program/gengal --name $$gal_oooname --path
$(CURDIR)/build/usr/lib/libreoffice/`readlink
/usr/lib/libreoffice/basis-link`/share/gallery --destdir $(CURDIR)/build
--number-from 70 `cat $$file | xargs`; \
+ SAL_USE_VCLPLUGIN=svp
/usr/lib/libreoffice/program/gengal --name $$gal_oooname --path
$(CURDIR)/build/usr/lib/libreoffice/share/gallery --destdir $(CURDIR)/build
--number-from 70 `cat $$file | xargs`; \
done; \
done
@@ -111,9 +111,9 @@
$(CURDIR)/debian/openclipart-svg/usr/share/openclipart/svg/
# Install OOo files
- mkdir -p
$(CURDIR)/debian/openclipart-libreoffice/usr/lib/libreoffice/$(shell readlink
/usr/lib/libreoffice/basis-link)/share/gallery
- cp -af $(CURDIR)/build/usr/lib/libreoffice/$(shell readlink
/usr/lib/libreoffice/basis-link)/share/gallery/* \
-
$(CURDIR)/debian/openclipart-libreoffice/usr/lib/libreoffice/$(shell readlink
/usr/lib/libreoffice/basis-link)/share/gallery/
+ mkdir -p
$(CURDIR)/debian/openclipart-libreoffice/usr/lib/libreoffice/share/gallery
+ cp -af $(CURDIR)/build/usr/lib/libreoffice/share/gallery/* \
+
$(CURDIR)/debian/openclipart-libreoffice/usr/lib/libreoffice/share/gallery/
# Install Overrides file
install -p -o root -g root -m 644
$(CURDIR)/debian/openclipart-svg.overrides
$(CURDIR)/debian/openclipart-svg/usr/share/lintian/overrides/openclipart-svg
@@ -143,7 +143,7 @@
@@ -143,7 +143,7 @@
dh_installdeb
# dh_perl
dh_shlibdeps
- dh_gencontrol -- -V'basis-version=$(shell readlink
/usr/lib/libreoffice/basis-link | sed -e s/basis//)'
+ dh_gencontrol
dh_md5sums
dh_builddeb
diff -u openclipart-0.18+dfsg/debian/changelog
openclipart-0.18+dfsg/debian/changelog
--- openclipart-0.18+dfsg/debian/changelog
+++ openclipart-0.18+dfsg/debian/changelog
@@ -1,3 +1,11 @@
+openclipart (0.18+dfsg-13) experimental; urgency=low
+
+ * QA upload
+ * adapt for basisX.Y / basis-link removal in LibreOffice 3.5
+ * rebuild for LibreOffice = 3.5
+
+ -- Rene Engelhard r...@debian.org Mon, 13 Feb 2012 23:11:07 +
+
openclipart (0.18+dfsg-12) unstable; urgency=low
* QA upload
diff -u openclipart-0.18+dfsg/debian/control
openclipart-0.18+dfsg/debian/control
--- openclipart-0.18+dfsg/debian/control
+++ openclipart-0.18+dfsg/debian/control
@@ -45,7 +45,7 @@
Package: openclipart-libreoffice
Architecture: all
Depends: ${shlibs:Depends}, ${misc:Depends}, openclipart-png (=
${Source-Version})
-Conflicts: openclipart ( 0.10+dfsg-3), libreoffice-common (
1:${basis-version}), libreoffice-common (= 1:${basis-version}.99)
+Conflicts: openclipart ( 0.10+dfsg-3), libreoffice-common ( 1:3.5.0~beta~)
Recommends: libreoffice
Description: clip art for OpenOffice.org/LibreOffice gallery
The Open Clip Art Library is a collection of 100% license-free,
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores
Bug#589570: error: Unable to migrate to dependency based boot sequencing.
Hi, On Sun, Jul 18, 2010 at 08:44:44PM +0200, Helmut Grohne wrote: # dpkg-reconfigure sysv-rc ... error: Unable to migrate to dependency based boot sequencing. error: Problems detected: package timidity left obsolete init.d script behind ... # I bet you removed timidity and didn't purge it. This is expected behaviour because /etc/init.d/* are conffiles. How is this a bug in timidity? Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100720092927.ga32...@rene-engelhard.de
Bug#580883: Allow 14e4:4320, it works
severity 580883 wishlist thanks Hi, On Sat, May 08, 2010 at 03:41:00PM +0200, Jörg Sommer wrote: I've a Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) and it works fine with the fireware used by this package. I've downloaded and extracted it by hand. Ah, the old fun of reusing PCI IDs. 14e14:4320 can be BCM4320/2 (b43legacy driver!) and BCM4306/3 (b43).. See Homepage: And you should not block the installation of the package, if the suitable hardware is not present. If you user wishs to install this fireware he should get it. When it's unused and his device still doesn't work, it's the problem of the user, he selected the wrong package. Who then complain about b43 not working or even report a bug here because it deos not work - instead of against the kernel. (BTDT with when b43-fwcutter had the extract firmware? question) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100510234610.gu24...@rene-engelhard.de
Bug#570089: Processed: Re: Bug#377270: agg doesn't provide a shared library
Hi, On Tue, Feb 16, 2010 at 12:39:08PM +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: block 570089 with 377270 Bug #570089 [src:exactimage] exactimage: embedded copy of AGG Was not blocked by any bugs. Added blocking bug(s) of 570089: 377270 thanks Stopping processing here. I don't see why it's blocked here. You can also use libagg-dev and not use the embedded code copy without agg having a shared library. agg hot having a shared library results back from the time I maintained it - and it#s because of the fact that AFAIR agg didn't change SONAME even when the ABI changed - boom :-) The PIC argument isn't one either, that#s exactly why libagg_pic is there: $ dpkg -L libagg-dev | grep a$ /usr/lib/libaggplatformX11.a /usr/lib/libagg.a /usr/lib/libagg_pic.a ^ (same for the rest) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100216135207.ge14...@rene-engelhard.de
Re: Processed: Please fix your packages ;)
Hi, On Mon, Jan 25, 2010 at 08:58:27AM +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: # For the last 4 packages, please check bug #557604. # For the other packages, only a binNMU is necessary. # (except that real binNMUs are not supported on arch:all packages) And some of those packages have the - symlinks hardcoded in .links. At least many I did have. Did you check that? :) And don't forget we still have packages not updated for this afaik. Like icedove? Maybe also iceape. Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Processed: Please fix your packages ;)
Hi, On Mon, Jan 25, 2010 at 10:23:14AM +0100, Rene Engelhard wrote: On Mon, Jan 25, 2010 at 08:58:27AM +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: # For the last 4 packages, please check bug #557604. # For the other packages, only a binNMU is necessary. # (except that real binNMUs are not supported on arch:all packages) And some of those packages have the - symlinks hardcoded in .links. At least many I did have. Did you check that? :) And don't forget we still have packages not updated for this afaik. Like icedove? Maybe also iceape. Discussion on IRC showed that iceape will be fixed, as will icedove 3. Shouldn't you have filed the bug *after* you fixed them in any case so that those dicts won't stop working? (And eventually we should add a Breaks:?) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Processed: Please fix your packages ;)
Hi, On Mon, Jan 25, 2010 at 12:22:24PM +0100, Mike Hommey wrote: As said on IRC, they won't break, they will possibly shown as xx_XX instead of a nice label, if the remaining file is in the xx_XX (instead of xx-XX) I define that as break, admittedly only minor, though. There was a reason why this whole - symlink mess was introduced in the first place, if I agreed on having them listed as xx_YY I'd not have done that :-) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please fix your packages ;)
Hi, On Mon, Jan 25, 2010 at 06:45:11PM +0100, Kurt Roeckx wrote: On Mon, Jan 25, 2010 at 09:56:00AM +0100, Mike Hommey wrote: # For the last 4 packages, please check bug #557604. # For the other packages, only a binNMU is necessary. # (except that real binNMUs are not supported on arch:all packages) It's not at all clear to me what people are expected to do. As I understand it, the following things need to happen after to get this fixed: 1) Old mozilla (xx-YY) symlinks removed. We should only have xx_YY symlinks. Yes. 2) Some thing that will change the sorting of languages. I'm not sure how that is going to happen. (That's what the bug that was cloned was about.) I think that was a ice*-specific part What I think should not happen yet: 3) Remove the symlinks /usr/share/myspell/dicts. Or can we drop them now too? And does that mean dropping the xx-YY symlinks in there or not? I'd have liked to start removing those, but I fear the time to the freeze is too short to go and wait for maintainers not doing that and to do NMUS. And I'd have squeeze either have them or not on all packages for consistency :-) I understand that for some packages the only thing that needs to happen is just rebuilding it, but atleast the myspell-nl/dutch package is not in the list of the 4 last, and does require changes to not set up those symlinks. Yeah, that#s what I meant in my reply with I know some packages which have the stuff hardcoded. Actually most of the packages I did or fixed fall into that, as when dictionaries-common-dev didn't do what it s hould have done I didn't bother to debug that and just hardcoded it Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559419: DDPO: Invalid link to changes file for packages in NEW
reassign 559419 ftp.debian.org retitle 559419 http://ftp-master.debian.org/new.html: links to individual packages broken severity 559419 normal affects 559419 qa.debian.org thanks Hi, On Fri, Dec 04, 2009 at 09:41:00AM +0100, Micha Lenk wrote: if an upload sits in NEW for approval by the ftp masters, it version is shown below the version available in unstable, and linked to some file on ftp-master.debian.org. This link is broken. The fault is not in DDPO but NEW itself (after NEW got fixed after the archive restructuring, the code doing those pages is not yet fixed). Grüße/Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552124: qa.debian.org: bogusly warns about security issues when fixed
On Fri, Oct 23, 2009 at 04:35:39PM +0200, Rene Engelhard wrote: CVE-2009-2139 Heap-based buffer overflow in svtools/source/filter.vcl/wmf/enhwmf.cxx ... CVE-2009-2140 Multiple heap-based buffer overflows in ... CVE-2009-3239 Buffer overflow in the EMF parser implementation in OpenOffice.org ... fixed, but security-tracker buggy This is DSA-1880-1: # CVE-2009-2139 A vulnerability has been discovered in the parser of EMF files of OpenOffice/Go-oo 2.x and 3.x that can be triggered by a specially crafted document and lead to the execution of arbitrary commands the privileges of the user running OpenOffice.org/Go-oo. This vulnerability does not exist in the packages for oldstable, testing and unstable. The other two CVEs talk about the same issus but got missed/double-assigned.. Ccing security team, please fix the security tracker... Grüße/Regards, Rene -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552124: qa.debian.org: bogusly warns about security issues when fixed
Package: qa.debian.org Severity: important Hi, let's look at http://packages.qa.debian.org/o/openoffice.org.html. We see at the top: There are 5 open security issues, please fix them. Let's look what they are: CVE-2009-0200 Integer underflow in OpenOffice.org (OOo) before 3.1.1 and ... fixed in both etch-security and lenny-security (etch-backports is not relevant anymore) and just waits to be in a point release. Why is this listed as still needing to be fixed? CVE-2009-0201 Heap-based buffer overflow in OpenOffice.org (OOo) before 3.1.1 and ... fixed in both etch-security and lenny-security (etch-backports is not relevant anymore) and just waits to be in a point release. Why is this listed as still needing to be fixed? CVE-2009-2139 Heap-based buffer overflow in svtools/source/filter.vcl/wmf/enhwmf.cxx ... CVE-2009-2140 Multiple heap-based buffer overflows in ... CVE-2009-3239 Buffer overflow in the EMF parser implementation in OpenOffice.org ... fixed, but security-tracker buggy CVE-2009-3569 Stack-based buffer overflow in OpenOffice.org (OOo) allows remote ... CVE-2009-3570 Unspecified vulnerability in OpenOffice.org (OOo) has unspecified ... CVE-2009-3571 Unspecified vulnerability in OpenOffice.org (OOo) has unknown impact ... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551068. Nothing to fix there (yet). At least the first too should not be shown! Grüße/Regards, Rene -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551521: [UDD] please expose a list of RC-buggy and/or ANY-buggy packages
Hi, On Sun, Oct 18, 2009 at 10:57:26PM +0200, George Danchev wrote: packages with more than 10/100 open bugs (any kind of) That is a nonsensical measure. Big packages have many bugs. Many of them are upstream bugs. It doesn't make sense to use a hardcoded value like this. and eventually reports about packages with bugs tagged as 'request for help', 'more info' and 'wontfix'. True for the last ones. I disagree about wontfix, that will just prompt people to close them if they get a useless message about that. Grüße/Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: {My,Hun}spell dicts and OOo hyphenations/thesauri transition
Hi,
On Mon, Aug 03, 2009 at 12:35:47AM +0200, Rene Engelhard wrote:
The plan is as follows:
1) all hyphenation patterns (hyph_*.dic) will move to /usr/share/hyphen.
OOo can be configured with --with-external-hyph-dir to look there,
scribus can add a symlink there or add a configure thing, too
2) all thesauri (th_*.{idx,dat}) will move to /usr/share/mythes
OOo (only one using it) can be configured with --with-external-thes-dir
to look there
3) the hunspell dictionaries should move to /usr/share/hunspell.
OOo gets configured with --with-external-dict-dir. Hunspell itself
looks there anyway and the symlinks in the Mozillas get changed
To not have a transition involving OOo and the mozillas (and eventually
some transitions which they are in) and all dicts together we talked on
debconf how to best do it and came up with the following:
STEP 1 (now!)
--
All dictionary packages get changed for the new location but KEEP the old
one.
[...]
OK, as there was no objection we start with STEP 1 now. I already uploaded
my packages not using installdeb-myspell with that change.
(installdeb-myspell-using packges either need extra stuff or need to
wait until I fixed dictionaries-common-dev to install in the new location
with compat symlinks)
Bugs will come soon for the non-installdeb-myspell ones and the other
ones when dictionaries-common-dev is fixed.
Grüße/Regards,
Rene
--
.''`. René Engelhard -- Debian GNU/Linux Developer
: :' : http://www.debian.org | http://people.debian.org/~rene/
`. `' r...@debian.org | GnuPG-Key ID: D03E3E70
`- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70
signature.asc
Description: Digital signature
{My,Hun}spell dicts and OOo hyphenations/thesauri transition
Hi,
I want to get this mess fixed up as soon as possible:
(sid)r...@frodo:/usr/share/myspell/dicts$ ls
de-BE.aff de_DE.dic DicOOo.sxw en-US.dicth_de_DE_v2.idx
de-BE.dic de-DE.dic en_US.aff hyph_de_DE.dic th_en_US_v2.dat
de_DE.aff de-LU.aff en-US.aff hyph_en_US.dic th_en_US_v2.idx
de-DE.aff de-LU.dic en_US.dic th_de_DE_v2.dat
(sid)r...@frodo:/usr/share/myspell/dicts$
Since OpenOffice.org formerly only supported one directory for all its
spellchecking dictionaries and hyphenation patterns and thesauri we
all dumped them into /usr/share/myspell/dicts with a symlink from
ooo installdir/share/dict/ooo to there.
After the Mozillas started to use MySpell/Hunspell, too, they point
to the same directory...
Now, since OpenOffice.org is able to use more paths and the Mozillas
still only use one for the spellchecking ones (and the scribus'es might
use one for the hyphenation ones soon), it's probably a good idea to clean
this up right now.
The plan is as follows:
1) all hyphenation patterns (hyph_*.dic) will move to /usr/share/hyphen.
OOo can be configured with --with-external-hyph-dir to look there,
scribus can add a symlink there or add a configure thing, too
2) all thesauri (th_*.{idx,dat}) will move to /usr/share/mythes
OOo (only one using it) can be configured with --with-external-thes-dir
to look there
3) the hunspell dictionaries should move to /usr/share/hunspell.
OOo gets configured with --with-external-dict-dir. Hunspell itself
looks there anyway and the symlinks in the Mozillas get changed
To not have a transition involving OOo and the mozillas (and eventually
some transitions which they are in) and all dicts together we talked on
debconf how to best do it and came up with the following:
STEP 1 (now!)
--
All dictionary packages get changed for the new location but KEEP the old
one.
STEP 2 (before squeezes freeze)
--
all affected packages get changed to look in the new location/change
the symlink to the new location. Let them migrate to testing.
This would break partial upgrades when someone partially installed
the new OOo/Mozilla/... with old, non-yet-changed packages, but we decided
to ignore this possibility. Or, if STEP 1 was completed *in testing* we
can add appropriate Breaks:
STEP 3
--
Remove the /usr/share/myspell/dicts compatibility links. This also means
patching dictionaries-common (getting rid of info files, ...). This would
also remove compatibility of those packages with OOo 2.4, but I don't think
that's bad; we then have a stable release with OOo3 and new dicts anyway.
As that might be too late depending on when 1 and 2 get finished this also
can be done after squeeze...
Comments?
If approved, I'll start filing bugs for STEP 1 soon, and NMU after some time...
Regards,
Rene
--
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ifrench_1.4-23_amd64.changes ACCEPTED
Hi, Debian Installer wrote: Accepted: ifrench_1.4-23.diff.gz to pool/main/i/ifrench/ifrench_1.4-23.diff.gz ifrench_1.4-23.dsc to pool/main/i/ifrench/ifrench_1.4-23.dsc ifrench_1.4-23_amd64.deb to pool/main/i/ifrench/ifrench_1.4-23_amd64.deb myspell-fr_1.4-23_all.deb to pool/main/i/ifrench/myspell-fr_1.4-23_all.deb Override entries for your package: ifrench_1.4-23.dsc - source text ifrench_1.4-23_amd64.deb - extra text myspell-fr_1.4-23_all.deb - extra text As you did a upload anyway, you could have fixed #517785 yourself.. Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Remove ipw2200 and ieee80211?
Hi, Moritz Muehlenhoff wrote: ipw2200 and ieee80211 have been orphaned a few days ago. Since both are present in current 2.6 kernels (2.6.14 onwards) I'd recommend to remove them right away. See the buglogs. Already proposed this... Regards, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277687: developer.php: pending links not working
Package: qa.debian.org Severity: normal Hi, see http://qa.debian.org/developer.php?login=renecomaint=yes - openoffice.org has 15 (16) bugs tagged as pending but on neither link it actually shows them. you just get a empty buglist... Those bugs are shown normally on http://bugs.debian.org/src:openoffice.org. Regards, Rene -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8.1 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: QA Upload best practices, 2nd draft
Hi, Matthew Palmer wrote: * It's also important to ensure that the maintainer address is set correctly. The address has changed in the past, and some packages haven't had their maintainer address changed since it's orphaning (even after several QA uploads!), so ensure that the maintainer of the package is set to Debian QA Packages [EMAIL PROTECTED]. Shouldn't it be Debian QA Group [EMAIL PROTECTED]? $ grep-available -FMaintainer QA -sMaintainer | sort | uniq Maintainer: Debian QA Group [EMAIL PROTECTED] Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 signature.asc Description: Digital signature
Re: Packages with no users and not in testing yet
Andreas Tille wrote: On Tue, 1 Jun 2004, Petter Reinholdtsen wrote: mozilla-locale-ko mozilla-locale-zh-hk mozilla-thunderbird-locale-es I guess we should not dump these localisation packages ... At least the first two are horribly out of date... Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 signature.asc Description: Digital signature
Re: Your Debian packages
Hi, Pierre Machard wrote: Bugs w.r.t. CVS snapshot of a2ps will be fixed when I upload new package based on the old 4.13b. AbiWord bugs - Bug#231649 is not really abiword's bug (I've already uploaded new libwpd7 package a week ago and it doesn't enter the archive yet) and I have no idea why you uuh? And then you built abiword against it? Why did you not wait for it entering the archive? And doesn't that make i386 not in sync with the other archs (which built abiword without libwpd7). What is it for? Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 signature.asc Description: Digital signature
Bug#211228: developer.php: please supply repeatmerged=no
Package: qa.debian.org Version: unavailable; reported 2003-09-16 Severity: wishlist Hi, me again :) http://qa.debian.org/developer.php?login=rene; openoffice.org has dozens of merged bugs. I occassionally go over all bugs and do a mass severity-changing, reassigning, tagging etc. So what the current links show is repeatmerged=yes which is not ideal because I have more bugs than actually there I have to look at. What about doing the following:? developer.php shows the bug count as 1(2) when there are two bugs merged to one. What about linking the 1 to repeatmerged=no and 2 to repeatmerged=yes? The same with the colum All where currently is no repeatmerged specified anyhow so it is yes. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux frodo 2.4.21-rene #3 Mit Aug 6 17:21:44 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 signature.asc Description: Digital signature
Bug#208212: developer.php: please show binary package links sorted?
Hi, Igor Genibel wrote: * Raphael Goulais [EMAIL PROTECTED] [2003-09-02 10:39:51 +0200]: On Monday 01 September 2003 19:41, Rene Engelhard wrote: I know that display in the statusbar. The problem is not solved there because you still have to go through all of them and look into the statusbar It does not display in the statusbar. Igor added a title property, so it appears as a tooltip when your mouse is over the link. You don't have to aim at the link with an eye while looking at the bottom of the screen with the oh, haven't seen that... Maybe as I looked it wasn't updated yet. other. Sounds better, but yes, we still have to go through all of them :( Yes :/ Ok. I will implement this fonctionality soon. thanks. Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 pgpk4cMk46YfZ.pgp Description: PGP signature
Bug#208212: developer.php: please show binary package links sorted?
Hi, Igor Genibel wrote: Please make them somehow sorted (alphabetically probably, as the PTS seems doing). I did something in order to show these links less obfuscated. I have provided an title property to these links in order to be shown when you pass the mouse over them. Please test and tell me if this functionality is sufficient or if I must do the real sort. I know that display in the statusbar. The problem is not solved there because you still have to go through all of them and look into the statusbar Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 pgpdfdFOc3v2J.pgp Description: PGP signature
Bug#182031: Complement
reopen 182031 thanks Hi Igor, Igor Genibel wrote: Also I have fixed the bug complement you provides me (Architecture specific packages don't have to provide buildd link). I think what you have done was a little bit to enthusiastic :-) See http://qa.debian.org/developer.php?login=rene again, packages toshset and oooqs. toshset is i386-only and does not need a buildd link - right oooqs is i386 powerpc s390 and doesn't have a Buildd link, which is wrong since there are builds on the buildds... (http://buildd.debian.org/build.php?pkg=oooqs) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 pgpdti51GpugA.pgp Description: PGP signature
Re: Moving packages from Requested to Can't be packaged
Hi, Arnaud Vandyck wrote: / Bas Zoetekouw [EMAIL PROTECTED] wrote: | AFAIK, there is no automatic way of doing this. What about adding a | new tag, something like CBP (cannot be packaged), to the wnpp? Why not simply close the bug and give an explanation? Because - when it really cannot be packaged and if the bug is archived - someone comes again with an ITP for that and someone has to explain him (or he does find out himself) that it cannot be packaged. Waste of time, no? Regards, Rene -- .''`. Rene Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 pgpvPux8yAkAJ.pgp Description: PGP signature
Bug#182031: developer.php: link to buildd reports sometime wrong/not senseful in contrib/non-free
reopen 182031 thanks Hi Igor, Igor Genibel wrote: please look at http://qa.debian.org/developer.php?login=rene. openoffice.org-debian-files and openoffice.org-spellcheck-de are complete binary-independent (Arch: all) so they should have a - in the Buildd column. This isn't fixed.. Oh, and BTW: when we're at it. Could you remove the buildd link for package who have only one arch package (Architecture: foo) too because there is nothing auobuilt too (see toshset on the above link as an example) Regards, Rene -- .''`. Rene Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 pgpOQ2f1is9XJ.pgp Description: PGP signature
Bug#182031: developer.php: link to buildd reports sometime wrong/not senseful in contrib/non-free
Package: qa.debian.org Version: unavailable; reported 2003-02-22 Severity: normal Hi, please look at http://qa.debian.org/developer.php?login=rene. openoffice.org-debian-files and openoffice.org-spellcheck-de are complete binary-independent (Arch: all) so they should have a - in the Buildd column. Moreover, I just looked on something at http://qa.debian.org/developer.php?login=joeyh and saw that there is a Buildd entry on Joey's non-free dgen package. IIRC non-free isn't autobuild do that doesn't make any sense too... Regards, Rene -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux stan 2.4.18 #1 Son Nov 3 01:29:12 CET 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] -- .''`. Rene Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 pgpPtX3vvxrMW.pgp Description: PGP signature
Re: retitling ITP's [round 2]
Hi, [ CC'ing nidd and twerner ] Bas Zoetekouw wrote: 120553RFP: stlport -- STLPort compat library Hmm. [EMAIL PROTECTED]:~$ apt-cache search stlport libstlport4.5-common - STLport C++ class library libstlport4.5-dev - STLport C++ class library libstlport4.5-full - STLport development files libstlport4.5c102 - STLport C++ class library [EMAIL PROTECTED]:~$ [EMAIL PROTECTED]:~$ apt-cache showsrc stlport4.5 Package: stlport4.5 Binary: libstlport4.5-full, libstlport4.5-dev, libstlport4.5c102, libstlport4.5-common Version: 4.5.3-10 Priority: optional Section: libs Maintainer: Torsten Werner [EMAIL PROTECTED] [...] [EMAIL PROTECTED]:~$ I think this ITP/RFP is obsolete because a) slport4.5 is in Debian b) nidd said OOo needs 4.0, if you look the actual openoffice.org-bin 1.0.2-2, you'll see runs with libstlport4.5c102... Regards, Rene -- .''`. Rene Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 pgpECMhqdQhze.pgp Description: PGP signature
Re: old ITP's
Hi Mark, [ late answer, I know... ] Mark Howard wrote: When I was looking through the RFP list a while back, I noticed many of them were for packages that were not maintained upstream - sometimes they were still at the planning stage after a number of years; sometimes they had been abandoned (many napster clones); in other cases, upstream just seemed to be very amateurish with little sign of development (e.g. not using cvs; no mailing lists; seem to be only one developer; no I do not think all the points you are describing are _necessary_. I second that these things are good but in my opinion there's no must. I myself maintain a package (kover), which has not a mailing list and CVS seems only to be updated if there's a new version released which makes CVS quite senseless... documentation; latest 'news' on the site being from many months or years ago; poorly designed website). How do you define poorly designed website? A website has _not_ to use the newest crap to be functional and you can find there what you want to. In that case the kover Homepage (http://lisas.de/kover) is an example... Considering the 'news' aspect, you're right. That indicates that upstream development is slept or it died... Regards, Rene -- .''`.Rene Engelhard : :' :** Debian GNU/Linux Developer ** `. `' http://www.debian.org | http://people.debian.org/~rene/ `- [EMAIL PROTECTED] pgpyr4TI9Fbrd.pgp Description: PGP signature
