Bug#402664: rosegarden.desktop is installed twice
Package: rosegarden Version: 1:1.4.0-1 Severity: normal The rosegarden.desktop file is installed twice, thus it appears twice in the KDE menu. /usr/share/applnk/Applications should be deprecated as menu path. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Versions of packages rosegarden depends on: ii kdelibs4c2a4:3.5.5a.dfsg.1-5 core libraries and binaries for al ii khelpcenter4:3.5.5a.dfsg.1-2 help center for KDE ii libasound2 1.0.13-1 ALSA library ii libc6 2.3.6.ds1-8 GNU C Library: Shared libraries ii libfontconfig1 2.4.1-2 generic font configuration library ii libgcc11:4.1.1-19GCC support library ii libjack0.100.0-0 0.101.1-2 JACK Audio Connection Kit (librari ii liblircclient0 0.8.0-9 LIRC client library ii liblo0 0.23-2.1 Lightweight OSC library ii liblrdf0 0.4.0-1 a library to manipulate RDF files ii libqt3-mt 3:3.3.7-1 Qt GUI Library (Threaded runtime v ii libstdc++6 4.1.1-19 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-4 X11 client-side library ii libxft22.1.8.2-8 FreeType-based font drawing librar ii rosegarden-data1:1.4.0-1 music editor and MIDI/audio sequen Versions of packages rosegarden recommends: ii blop [ladspa-plugin] 0.2.8-3Bandlimited wavetable-based oscill ii cmt [ladspa-plugin] 1.15-3.1 Computer Music Toolkit (cmt) a col ii jackd 0.101.1-2 JACK Audio Connection Kit (server ii swh-plugins [ladspa-plugin] 0.4.14-1.1 Steve Harris's LADSPA plugins ii tap-plugins [ladspa-plugin] 0.7.0-2Tom's Audio Processing LADSPA plug -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401239: dosemu.desktop is not completely valid
Package: dosemu Version: 1.2.2-6 Severity: normal Tags: patch The dosemu.desktop file shipped with the Debian package is not completely valid. First, it has wrong categories, so it ends up in the lost+found menu of KDE. Then, it misses the Encoding key, and it contains an invalid key (MultipleArgs). The attached patch fixes all the issues above. -- Package-specific info: ## # This file is the system-wide dosemu.conf or the per-user ~/.dosemurc, # included by global.conf or dosemu.bin. # # ./doc/README.txt (chapter 2.) contains a description of the syntax # and the usage of dosemu.conf and .dosemurc. # # The commented-out values are defaults, here for documentation purposes # only. Options marked [priv] cannot be changed in ~/.dosemurc. # # (optional) access rights are defined in # # /etc/dosemu/dosemu.users or /etc/dosemu.users # ## # Notes for editing this file: # # In$_xxx = (n)n is a numerical or boolean value # = = # In$_zzz = "s"s is a string # # Please note that all options are commented out by default! # Remove the # in front of the $ to change an option. ## ## CPU settings: define the CPU features to DOSEMU. # CPU shown to DOS, valid values: "80[345]86" # or "emulated" for non-native CPU (386 in this case) Default: 80386 # $_cpu = "80486" # if possible use Pentium cycle counter. Default: off # $_rdtsc = (off) # CPU speed, used in conjunction with the TSC # Default 0 = calibrated by dosemu, else given (e.g.166.666) # $_cpuspeed = (0) # emulated FPU, (off) or (on), default = (on) # $_mathco = (on) # 0 = all CPU power to DOSEMU; default = 1 = nicest, then higher:more CPU power # $_hogthreshold = (1) ## ## Disk and file system settings # List of hdimages or boot directories under # ~/.dosemu, the system config directory (/etc/dosemu by default), or # syshdimagedir (/var/lib/dosemu by default) assigned in this order # such as "hdimage_c directory_d hdimage_e" # Absolute pathnames are also allowed. # If the name begins with '/dev/', then partion access is done instead of # virtual hdimage such as "/dev/hda1" or "/dev/hda1:ro" for readonly # Currently mounted devices and swap are refused. Hdimages and devices may # be mixed such as "hdimage_c /dev/hda1 /dev/hda3:ro" # Note: 'wholedisk' is _not_ supported. Default: "drives/*" $_hdimage = "freedos:ro hdimage_e" # if you want to boot from a virtual floppy: # file name of the floppy image under DOSEMU_LIB_DIR # e.g. "floppyimage" disables $_hdimage # "floppyimage +hd" does _not_ disable $_hdimage. Default: "" # $_vbootfloppy = "" # floppy drive types: "threeinch" or "fiveinch" or "atapi" or empty, # if non-existant. Optionally the device may be appended such as # "threeinch:/dev/fd0". Default: "threeinch" for A:, "" for B: # $_floppy_a = "threeinch" # $_floppy_b = "" # list of generic SCSI devices to make available for the builtin aspi driver # (format of an entry is 'device:type:mappedtarget' such as # "sg2:WORM sg3:Sequential-Access:6 sg4:CD-ROM" or # "sg2:4 sg3:1:6 sg4:5" (which are equal). Default: "" # $_aspi = "" # whether to lock the full file on lredired drives for file locking requests # or just one byte # $_full_file_locks = (off) # config.sys -> config.XXX; default="" or 3 char., # $_emusys = "" # system.ini -> system.XXX; default="" or 3 char., (for Windows 3.x) # $_emuini = "" ## ## Memory settings # conventional DOS memory size, in Kbyte, <= 768. Default = 640 # $_dosmem = (640) # XMS (extended memory) size in Kbyte; default: 8192. # $_xms = (8192) # EMS (expanded memory) size in Kbyte; default: 2048. # $_ems = (2048) # DOS segment where the EMS frame is put. Default = 0xe000. # $_ems_frame = (0xe000) # DPMI size in Kbyte; default: 0x5000 # $_dpmi = (0x5000) # preferred mapping driver, one of: auto, mapself, mapfile, mapshm # Default: ""="auto" # $_mapping= "" ## ## Debug settings # debug switches; same format as -D commandline option, default: ""="-a+cw". # (but without the -D in front), normally written to ~/.dosemu/boot.log # $_debug = "-a+cw" ## ## Dosemu-specific hacks # set this to some positive value (eg. Default: 10) # if you want to play Doom or Duke3D with sound. # $_cli_timeout = (10) # try setting this to some lower positive value (eg. 5; default: 50) # if you get problems with some DOS program # freezing after some time. # $_pic_watchdog = (50) # list of temporary hacks, see release notes in the file
Bug#401285: ri-li.desktop is not completely valid
Package: ri-li Version: 2.0.0-2 Severity: normal Tags: patch The Category key of the ri-li.desktop file is not valid. - the "Application" category does not exists (see http://standards.freedesktop.org/menu-spec/latest/apa.html) - it is a list, so it needs to ends with a semi-colon The attached patch fixes both the issues above. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-k7 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Versions of packages ri-li depends on: ii libc6 2.3.6.ds1-8 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-19 GCC support library ii libsdl-mixer1.2 1.2.6-1.1+b2 mixer library for Simple DirectMed ii libsdl1.2debian 1.2.11-7 Simple DirectMedia Layer ii libstdc++6 4.1.1-19 The GNU Standard C++ Library v3 ii ri-li-data 2.0.0-2 data files for Ri-li, a toy train ri-li recommends no packages. -- no debconf information --- ri-li.desktop.orig 2006-12-02 12:19:25.0 +0100 +++ ri-li.desktop 2006-12-02 12:18:28.0 +0100 @@ -8,4 +8,4 @@ Icon=ri-li Terminal=false Type=Application -Categories=Application;Game;ArcadeGame +Categories=Game;ArcadeGame;
Bug#420128: kpdf: Cannot open external files.
Hi, there's something I do not understand completely. If I open http://www.toulouse.fr/documents/urbanisme/plu/AUTRES_FICHIERS/Sommaire_PLU.pdf directly, then I'm able to jump to the files linked (eg 1, 2, 3A, 3B, etc). However, these links are in the form "../some_other_directory/target.pdf", so when opening the first PDF from the web, then the full URL is the (proper) base, and the linked files are properly found. While if you download all of them locally in the same folder, then there are troubles because the /path/where/you/downloaded/them/../some_other_directory/target.pdf points to a non existant file. Thus, I don't see any bad behaviour of KPDF. Doubts? Or something I missed? -- Pino Toscano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#733109: libgexiv2-dev: dependency changes: remove libexiv2-dev, add libglib2.0-dev
Package: libgexiv2-dev Severity: minor Hi, $ grep -rh include libgexiv2-dev/usr/include/* | sort -u #include #include #include #include #include #include #include #include #include so it seems the libexiv2-dev dependency should be removed (since the exiv2 headers are not included in the public gexiv2 ones), while libglib2.0-dev should be added Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734072: ocaml-doc: fix doc-base installation
Source: ocaml-doc
Version: 4.01-1
Severity: normal
Tags: patch
Hi,
due to the fact that the doc-base file is generated from a .in file,
dh_installdocs picks both the files, installing them with a wrong name:
/usr/share/doc-base/ocaml-doc-ocaml
/usr/share/doc-base/ocaml-doc-ocaml.in
Attached there is a small change to rules to exclude the .in files for
dh_installdocs; this also fixes the file name for doc-base, which now
is:
/usr/share/doc-base/ocaml-doc
Thanks,
--
Pino
--- a/debian/rules
+++ b/debian/rules
@@ -8,6 +8,9 @@
sed "s/@VERSION@/$(DOC_VERSION)/g" debian/$${file}.in > debian/$${file}; \
done
+override_dh_installdocs:
+ dh_installdocs -X.in
+
override_dh_compress:
dh_compress -X.pdf
Bug#605116: kde: lots of non-wallpaper pictures show up in kde background selector
Hi,
Alle sabato 27 novembre 2010, Yves-Alexis Perez ha scritto:
> On sam., 2010-11-27 at 17:47 +0100, Michael Biebl wrote:
> > On 27.11.2010 16:34, Yves-Alexis Perez wrote:
> > > On sam., 2010-11-27 at 16:01 +0100, Michael Biebl wrote:
> > >> In the KDE wallpaper selector, a lot of non-wallpaper files
> > >> started showing up with the update of desktop-base:
> > >> grub images, login splash images etc.
> > >>
> > >> Also, several images are shown with different resolutions.
> > >>
> > >> This clutters the wallpaper selector significantly.
> > >
> > > I have to admit I don't really care, this was requested by Pino
> > > Toscano (CC:ed) so it'd be easier to select wallpapers.
> >
> > It's not making it easier but harder.
>
> I won't argue on this, maybe Pino has a comment.
This is because of the mixup, I guess.
I did a simple patch (attached, tested) which, instead of adding
/u/s/images/desktop-base to the wallpaper paths, symlinks the
backgrounds in /u/s/wallpapers (and removes dir_wallpaper from
kdeglobals).
Note this still leaves the duplicates wallapers in case they are both in
SVG and PNG format, maybe Yves-Alexis has an idea for removing the
duplicates, preferring the SVGs.
> > It looks to me as if the right way to do this in KDE is to install
> > a desktop file in /usr/share/wallpapers/SpaceFun/metadata.desktop,
> > create a subfolder images/, and provide the images for the
> > different resolutions (which could be symlinks, I guess).
>
> That looks too complicated for me. I have no intent to spent time on
> the KDE part if no KDE people is interested either. If you think it
> useless, I'll just drop that on a future upload.
I thought about doing this as well, but I wanted to automate the
creation procedure for similar wallpaper structures, either for both the
naming and the size of the wallpaper files inside the wallpaper
packages. (Also, it would require metadata.desktop files with name/email
of the creator(s) and the license, but I guess this wouldn't be an
issue.)
--
Pino Toscano
Index: profiles/kde-profile/kdeglobals
===
--- profiles/kde-profile/kdeglobals (revision 211)
+++ profiles/kde-profile/kdeglobals (working copy)
@@ -1,3 +1,2 @@
[Directories]
dir_config=/usr/share/desktop-base/profiles/kde-profile/share/config/
-dir_wallpaper=/usr/share/images/desktop-base
Index: Makefile
===
--- Makefile(revision 211)
+++ Makefile(working copy)
@@ -24,6 +24,10 @@
mkdir -p $(DESTDIR)/usr/share/images/desktop-base
$(INSTALL) $(BACKGROUNDS) $(DESTDIR)/usr/share/images/desktop-base
cd $(DESTDIR)/usr/share/images/desktop-base && ln -s $(DEFAULT_BACKGROUND) default
+ mkdir -p $(DESTDIR)/usr/share/wallpapers
+ for wp in $(filter-out $(wildcard backgrounds/*grub*),$(BACKGROUNDS)) ; do \
+ ln -s /usr/share/images/desktop-base/`basename $${wp}` /usr/share/wallpapers/ ; \
+ done
# splash files
$(INSTALL) $(SPLASH) $(DESTDIR)/usr/share/images/desktop-base
# emblems
signature.asc
Description: This is a digitally signed message part.
Bug#736078: choqok: different orig tarball used
Source: choqok Version: 1.4-1 Severity: important Hi, it seems the orig tarball used for choqok is not the one released by the choqok developers: (a) -rw-r--r-- 1 pino users 814429 Sep 23 21:32 choqok_1.4.orig.tar.bz2 (b) -rw-r--r-- 1 pino users 1021228 Sep 1 05:18 choqok-1.4.tar.xz (a) is the one currently in Debian, while (b) is the one released upstream. The only difference so far is the lack of translations in (a), which is #686983; just using the real tarball is enough to have them shipped. It looks like you might have taken the version from the Git tag of the upstream repository; anyway, please make use of the upstream releases. Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#719227: transition: poppler 0.22
On 2014-01-20 10:25, Julien Cristau wrote: On Fri, Aug 9, 2013 at 15:45:19 +0200, Pino Toscano wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 679896 719224 712688 Hi, I would like to ask a slot for a Poppler 0.22.x transition. Currently there is Poppler 0.22.x in experimental already. Please note that there are still few issues that prevents it to be started, so I'm filing this at this time to have this transition considered by the release team. Is this only blocking on us now? If so please feel free to upload. Thanks, just done now. Regarding the binNMUs: - the priority of #690161 has just been raised to serious; OTOH it is not a blocker (as the source produces only an arch:all binary) - a fixed xpdf is in experimental, maybe Gilber will notice... the rest should be fine, so feel free to schedule binNMUs as you can and it is possible for the relevant sources. Thanks, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735246: okular: Okular features crippled by building with libpoppler 0.18.4
Hi, On 2014-01-14 00:22, Jan Binder wrote: okular is built with libpoppler 0.18.4, as verified with ldd. This makes saving annotations in PDFs impossible, even though it is implemented in this version of okular. There is a packaged version od lipoppler 0.22.5-3, where this would most probably work. Okular is built with whatever version of poppler is currently available in unstable at upload time. So far it means 0.18.x, while 0.22.x is in experimental (which does not matter regarding unstable). This makes this bug pointless, since okular doesn't get to decide which poppler to use; hence I'm closing it. Anyway, poppler 0.22.5 has been just uploaded to unstable, and as part of this packages using libpoppler-qt4, including okular, will be soon rebuilt against the library/ies with the new SONAME(s). Thanks for your report, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736425: poppler-glib: "incorrect password" error bypasses GError
forwarded 736425 https://bugs.freedesktop.org/show_bug.cgi?id=73269 tag 736425 + fixed-upstream thanks Hi, On 2014-01-23 16:07, Raphael Geissert wrote: When trying to open a password-encrypted pdf file with the glib interface but with the incorrect password, there's an error message printed to stderr: "Error: Incorrect password". Unconditionally, bypassing GError. Looking at SecurityHandler.cc I see that there are other cases for which error() is called, and assuming there's no race condition in the "trapping" of error() to GError, it would mean that there are several error conditions which entirely bypass GError. Or, most simply, poppler-glib does not install an error handler redirecting all the messages to the glib logging stuff. This is the upstream bug #736425, which is fixed with the upstream commit 92ea15642a6d3fe65d66d5c59fb6bed54e060e5d (in poppler >= 0.25.2). -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736537: plee-the-bear: please build again on any architecture
Source: plee-the-bear
Version: 0.6.0-2
Severity: wishlist
Tags: patch
Hi,
it seems that the build of plee-the-bear was restricted to some
architectures back in 2008, due to #490020.
After some years, there were updates in libclaw and in plee-the-bear
itself, so there could be the possibility that the (build) issues now
are gone/solved. I just tried to build plee-the-bear on a s390x
porterbox, and it build fine.
Can you please switch the architecture lists of the arch:any binaries
back to any? Attached there is a patch for it.
Thanks,
--
Pino
--- a/debian/control
+++ b/debian/control
@@ -22,7 +22,7 @@ Vcs-Svn: svn://anonscm.debian.org/pkg-ga
Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-games/packages/trunk/plee-the-bear/
Package: plee-the-bear
-Architecture: amd64 hppa i386 ia64 m68k mips mipsel mipsn32el mips64 mips64el sparc kfreebsd-i386 kfreebsd-amd64 armhf
+Architecture: any
Depends: ${shlibs:Depends}, plee-the-bear-data (= ${source:Version}),
${misc:Depends}
Description: 2D platform game
@@ -57,7 +57,7 @@ Description: data for Plee the Bear
This package includes the data files for the game.
Package: bear-factory
-Architecture: amd64 hppa i386 ia64 m68k mips mipsel mipsn32el mips64 mips64el sparc kfreebsd-i386 kfreebsd-amd64 armhf
+Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Editors for Plee the Bear
This package includes the level editor, animation editor and model editor of
Bug#736538: ruby-inotify: please build on Linux architectures only
Source: ruby-inotify
Version: 0.0.2-7
Severity: wishlist
Tags: patch
Hi,
ruby-inotify is a Ruby interface for the inotify system of Linux;
thus it is pointless to even trying to build it on non-Linux
architectures.
Could you please restrict its build on Linux architectures only?
Attached there is a patch for it.
Thanks,
--
Pino
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Homepage: http://dinhe.net/~aredridel/pr
XS-Ruby-Versions: all
Package: ruby-inotify
-Architecture: any
+Architecture: linux-any
XB-Ruby-Versions: ${ruby:Versions}
Depends: ${shlibs:Depends}, ${misc:Depends}, ruby | ruby-interpreter
Description: Ruby interface to Linux's inotify system
Bug#718264: luatex has unused build-deps on poppler libraries
Source: luatex Followup-For: Bug #718264 Hi, since a couple of days there's poppler 0.22.5 available in unstable, so luatex could switch back using an external poppler (and make the poppler-related build dependencies useful again). Note that having a note about the particular version requirements could help; also the too old version was due to the previous lack of maintainership (and then the freeze kicked in), which I'm trying to address. -- Pino -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732642: Split
clone 732642 -1 retitle 732642 gnustep-base: FTBFS on hurd-i386 retitle -1 gnustep-base: documentation fixes user debian-h...@lists.debian.org usertag -1 - hurd thanks Hi, since the Hurd build fix and the documentation fixes are separate issues, I'm splitting the documentation fixes from this bug (so leaving it just for the Hurd issue). The fixes for Hurd will be NMUed soon since its FTBFS, due to the removal of the old libffi5, is holding other GNUstep-related builds. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736998: poppler update made Evince display a blank page in a certain PDF
forwarded 736998 https://bugs.freedesktop.org/show_bug.cgi?id=70085 fixed 736998 poppler/0.24.5-1 tag 736998 + fixed-upstream thanks Hi, On 2014-01-29 08:35, Vlad Orlov wrote: Today's update in Jessie brought new libpoppler-glib8 and libpoppler37 instead of libpoppler19. A regression appeared in Evince. It can be reproduced by loading a certain PDF [1] and looking at the page 12. With the older poppler (0.18) that page is drawn normally, with the new one there's a blank page - the contents are not displayed. [1] http://dl.fullcirclemagazine.org/issue12_en.pdf Additional note: if you run Evince with that PDF as parameter from the terminal, a message appears: Internal Error: cairo context error: invalid matrix (not invertible)<0a> This sounds like upstream bug #70085, which has been fixed in poppler >= 0.24.3 with commit f4bfa940aa40a82a1080cdaf765da1d1615ccfb1. Will check further later. Thanks for your report, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737473: harfbuzz: please re-enable the test suite
Source: harfbuzz Version: 0.9.26-1 Severity: wishlist Tags: patch Hi, due to the double build in two build directories (build-main and build-udeb), dh_auto_test does nothing. It can be easily solved by manually invoking dh_auto_test for the two build directories, as done with other build steps. Patch attached for it. Thanks, -- Pino --- a/debian/rules +++ b/debian/rules @@ -18,6 +18,10 @@ dh_auto_build --builddir build-main dh_auto_build --builddir build-udeb +override_dh_auto_test: + dh_auto_test --builddir build-main + dh_auto_test --builddir build-udeb + override_dh_auto_install: dh_auto_install --builddir build-main
Bug#737473: closed by أحمد المحمودي (Ahmed El-Mahmoudy) (Bug#737473: fixed in harfbuzz 0.9.26-3)
On 2014-02-03 04:21, ow...@bugs.debian.org wrote: harfbuzz (0.9.26-3) unstable; urgency=low . * Re-enable the test suite. Since HarfBuzz has two builds, dh_auto_test needs to be overridden as with the other dh_auto_*. Thanks to Pino Toscano (Closes: #737473) Thanks for the fix, but it seems that there are failures on some architectures :/ Since I asked for tests to be run again, I debugged them and started reporting bugs (with patches): - check-static-inits.sh failures: https://bugs.freedesktop.org/show_bug.cgi?id=74490 it seems only a bug in the test - check-defs.sh & check-symbols.sh failures: https://bugs.freedesktop.org/show_bug.cgi?id=74491 it seems only a bug in the test - check-libstdc++.sh failures: this seems a problem in libgraphite on kFreeBSD and Hurd, where it links to libstdc++ while it does not on Linux; I did not send a fix for graphite yet In any case, it seems none of the test failures indicate some issue within harfbuzz itself, so you might want to either make the tests non-fatal (so they still are run at build time), or wait for the fixes to the above issues. Thanks for the patience, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738338: poppler: Patch for bootstrapping without Gtk+ or Qt
tag 738338 - patch thanks Hi, On 2014-02-09 12:37, Daniel Schepler wrote: As the subject says: the attached patch adds the possibility to do a bootstrapping build of poppler at a stage where Gtk+ and Qt are not yet available. While I am looking forward to a way to disable frontends in a clean way, your patch is for sure not acceptable to me: - I don't see DEB_BUILD_PROFILES documented anywhere in Policy, so I have no idea what it is supposed to be, and what tools are supposed to do with it (and neither you describe it, other than "pick this patch"...) - excluding packages (-Nfoo -Nbar ...) is quite ugly, feels like a bad hack than a well-designed solution I will eventually do the job myself when there is a *clean* and *documented* way to do this, so please no hacks in the meanwhile. Thanks anyway for your patch, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738353: graphite2: extra linking to libstdc++ on kFreeBSD and Hurd
Source: graphite2
Version: 1.2.4-1
Severity: normal
Tags: patch
Hi,
the build system of graphite2 avoids the linking of libgraphite2 to
libstdc++, but only on Linux. This causes the failure of one of the
harfbuzz tests (check-libstdc++.sh), which checks that libharfbuzz
(which links to libgraphite2) does not (directly or indirectly) pull
libstdc++.
Attached there is a patch that extends the checks in the build system
also to GNU/k*BSD platforms (k*.BSD) and Hurd (GNU).
Thanks,
--
Pino
--- a/gr2fonttest/CMakeLists.txt
+++ b/gr2fonttest/CMakeLists.txt
@@ -17,14 +17,14 @@ if (GRAPHITE2_ASAN)
set(GRAPHITE_LINK_FLAGS "-fsanitize=address")
endif (GRAPHITE2_ASAN)
-if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
+if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux" OR ${CMAKE_SYSTEM_NAME} MATCHES "k.*BSD" OR ${CMAKE_SYSTEM_NAME} STREQUAL "GNU")
# -lgcc LINKER_LANGUAGE C
add_definitions(-fno-rtti -fno-exceptions)
set_target_properties(gr2fonttest PROPERTIES LINK_FLAGS "-nodefaultlibs ${GRAPHITE_LINK_FLAGS}" LINKER_LANGUAGE C)
set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "")
# This script just fails
nolib_test(stdc++ $)
-endif (${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
+endif (${CMAKE_SYSTEM_NAME} STREQUAL "Linux" OR ${CMAKE_SYSTEM_NAME} MATCHES "k.*BSD" OR ${CMAKE_SYSTEM_NAME} STREQUAL "GNU")
# copy the DLL so that gr2fonttest can find it
add_custom_target(${PROJECT_NAME}_copy_dll ALL
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -110,7 +110,7 @@ else (${CMAKE_BUILD_TYPE} STREQUAL "Clan
set(GRAPHITE_LINK_FLAGS "")
endif (${CMAKE_BUILD_TYPE} STREQUAL "ClangASN")
-if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
+if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux" OR ${CMAKE_SYSTEM_NAME} MATCHES "k.*BSD" OR ${CMAKE_SYSTEM_NAME} STREQUAL "GNU")
set_target_properties(graphite2 PROPERTIES
COMPILE_FLAGS "-Wall -Wextra -Wno-unknown-pragmas -Wendif-labels -Wshadow -Wctor-dtor-privacy -Wnon-virtual-dtor -fno-rtti -fno-exceptions -fvisibility=hidden -fvisibility-inlines-hidden -fno-stack-protector"
LINK_FLAGS "-nodefaultlibs ${GRAPHITE_LINK_FLAGS}"
@@ -128,7 +128,7 @@ if (${CMAKE_SYSTEM_NAME} STREQUAL "Linu
endif (${CMAKE_CXX_COMPILER} MATCHES ".*mingw.*")
set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "")
CREATE_LIBTOOL_FILE(graphite2 "/lib${LIB_SUFFIX}")
-endif (${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
+endif (${CMAKE_SYSTEM_NAME} STREQUAL "Linux" OR ${CMAKE_SYSTEM_NAME} MATCHES "k.*BSD" OR ${CMAKE_SYSTEM_NAME} STREQUAL "GNU")
if (${CMAKE_SYSTEM_NAME} STREQUAL "Darwin")
set_target_properties(graphite2 PROPERTIES
--- a/tests/comparerenderer/CMakeLists.txt
+++ b/tests/comparerenderer/CMakeLists.txt
@@ -38,7 +38,7 @@ endif (${ICU_INCLUDE} STREQUAL "ICU_INCL
#set(HB1_LDFLAGS "-L${HB1_INCLUDE}/../../lib -lharfbuzz-1")
#endif (${HB1_INCLUDE})
-if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
+if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux" OR ${CMAKE_SYSTEM_NAME} MATCHES "k.*BSD" OR ${CMAKE_SYSTEM_NAME} STREQUAL "GNU")
find_package(Freetype)
find_package(PkgConfig)
@@ -63,7 +63,7 @@ if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux
set(GRAPHITE_LINK_FLAGS "-fsanitize=address")
endif (GRAPHITE2_ASAN)
-endif (${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
+endif (${CMAKE_SYSTEM_NAME} STREQUAL "Linux" OR ${CMAKE_SYSTEM_NAME} MATCHES "k.*BSD" OR ${CMAKE_SYSTEM_NAME} STREQUAL "GNU")
if (${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
find_path(GR_INCLUDE graphite/GrClient.h PATHS ENV SILGRAPHITE_HOME ${PROJECT_SOURCE_DIR}/../../../silgraphite-2.3.1 ${PROJECT_SOURCE_DIR}/../../../silgraphite-2.4.0 ${GRAPHITE_INSTALLED_PATH} ${PROJECT_SOURCE_DIR}/../../../graphite-trunk PATH_SUFFIXES engine/include include)
--- a/tests/examples/CMakeLists.txt
+++ b/tests/examples/CMakeLists.txt
@@ -26,12 +26,12 @@ macro(test_example TESTNAME SRCFILE)
set_tests_properties(${TESTNAME} PROPERTIES TIMEOUT 3)
endmacro(test_example)
-if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
+if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux" OR ${CMAKE_SYSTEM_NAME} MATCHES "k.*BSD" OR ${CMAKE_SYSTEM_NAME} STREQUAL "GNU")
find_package(Freetype)
if (${FREETYPE_FOUND})
include_directories(${FREETYPE_INCLUDE_DIRS})
endif (${FREETYPE_FOUND})
-endif (${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
+endif (${CMAKE_SYSTEM_NAME} STREQUAL "Linux" OR ${CMAKE_SYSTEM_NAME} MATCHES "k.*BSD" OR ${CMAKE_SYSTEM_NAME} STREQUAL "GNU")
macro(test_freetype TESTNAME SRCFILE)
if (${FREETYPE_FOUND})
--- a/tests/vm/CMakeLists.txt
+++ b/tests/vm/CMakeLists.txt
@@ -38,12 +38,12 @@ if (GRAPHITE2_ASAN)
set_target_properties(vm-test-call PROPERTIES LINK_FLAGS "-fsanitize=address")
endif (GRAPHITE2_ASAN)
-if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
+if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux" OR ${CMAKE_SYSTEM_NAME} MATCHES "k.*BSD" OR ${CMAKE_SYSTEM_NAME} STREQUAL "GNU")
add_definitions(-fno-rtti -fno-exceptions)
if ("${CMAKE_BUILD_TYPE}" STREQUAL "Release")
add_definitions(-DNDEBUG -fomi
Bug#738338: poppler: Patch for bootstrapping without Gtk+ or Qt
Hi, On 2014-02-09 19:42, Johannes Schauer wrote: Quoting Daniel Schepler (2014-02-09 19:13:01) On Sunday, February 09, 2014 03:42:50 PM Pino Toscano wrote: > While I am looking forward to a way to disable frontends in a clean way, your > patch is for sure not acceptable to me: > - I don't see DEB_BUILD_PROFILES documented anywhere in Policy, so I have no > idea what it is supposed to be, and what tools are supposed to do with it > (and neither you describe it, other than "pick this patch"...) This fairly recently made its way into dpkg, so it's not documented in policy yet. The dpkg man pages (dpkg-buildpackage's new -P flag in particular) and the blog at https://blog.mister-muffin.de/2014/02/06/botch-updates/ are currently the existing documentation. There is a bit more documentation. Here is the current spec of what we want to become policy: https://wiki.debian.org/BuildProfileSpec Sounds nice and dandy, but that is not Policy yet. The most important part of this (the new dependency syntax) entered dpkg 1.17.2 already but we can't upload packages with that syntax yet because full support for it needs to arrive in stable as Daniel already pointed out. > - excluding packages (-Nfoo -Nbar ...) is quite ugly, feels like a bad hack > than a well-designed solution Hi, Johannes. Maybe you could comment on this: is there any planned way to be able to specify something like Package: libpoppler-libqt4-4 Architecture: any Profiles: !profile.stage1 ... in debian/control and then have debhelper commands skip those packages when appropriate? It would also be nice to have dpkg-genchanges in-debian-control- but-not-built warnings not show up for such packages. Yes. As per the spec I linked to above, the Build-Profiles field in binary package stanzas in debian/control is supposed to inform the involved tools about which packages build or do not build when a certain build profile is enabled. We do not have a patch for debhelper and dpkg-genchanges for this yet. Wookey: is does such a patch already exist somewhere? Pino: src:poppler is one of the ~60 source packages which, if they were modified, would make all of Debian bootstrappable. [...] Yes, I perfectly know that. I knew that even way before Wookey did his talk at DebConf a couple of years ago about this (even mentioning poppler), and most probably even way before you did this research work. Please leave this bugreport open until this has been further documented and implemented in the respective tools. Please read the last paragraph in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738338#10 which Daniel did not quote when replying further. In short: I will *not* accept any such hack until: - there are clean solutions for dependencies and binary packages - *all* the tools in stable support whatever is the syntax for such stuff - the Debian Policy decribes everything (no out-of-Policy tricks) -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730112: poppler-utils: pdftotext unusable: Inconsistency detected by ld.so / Assertion failed
Hi, On 2013-12-16 01:47, Klaus Ethgen wrote: Am So den 24. Nov 2013 um 14:50 schrieb Vincent Lefevre: On 2013-11-23 18:52:29 -0500, Michael Gilbert wrote: > This seems to work now that fontconfig 2.11.0-2 has been uploaded. > This can probably be fixed with a depends fontconfig (>= 2.11.0-2). That's annoying because this means that there is no longer any workaround to get xpdf running. Well, there is. I did build new packages of libfontconfig with the patch from Michael Gilbert applied. This worked fine until this würgarround here that again breaks xpdf. [...] To emphasize it again, the version 0.18.4-10 did break xpdf even more than libfontconfig! Seriously: the current xpdf in Debian is totally broken, and it has been for years even before the recent changes in fontconfig and/or poppler; those just uncovered even more the nonsense the current xpdf is. The current xpdf in Debian is compiled with a totally fragile hack, that is picking the original Xpdf sources, patching them for the newer Poppler API and then "stripping away" the sources (with some cp and sed) that are "common" with Poppler (Poppler is a fork of Xpdf, too). This poses a number of issues: 1) symbols conflicts with Poppler (#658264), totally misdiagnosed and mishandled 2) the recent breakage (#727070), which may very well be another effect of the above issue 3) compatibility with just a precise stable serie of Poppler (now 0.18.x), with #679896 and #719224 currently asking for recent versions 4) just rebuilding Poppler, even with changes not even touching the main libpoppler library (like poppler/0.18.4-9 and -10) breaks xpdf, while I'm not aware of issues in any other poppler-using package (not even those using the private libpoppler directly) As you can see, its maintainer (Michael Gilbert) is doing next to nothing to fix them, other than rejecting patches, tagging bugs as "help" (because he says to have no time for xpdf), and trying to NMU nonsense patches in other sources (#728444, with the NMU delayed because of "emotional messages", not because of realizing the patch was totally broken... WTH). Currently xpdf is out of Jessie (the next release), and will be until the (2) above is fixed (at least), which may be even today or in years... Also, (3) can be (due to unattented patches nor even own porting work) another reason for xpdf nto keeping up with newer Poppler versions. All in all: my strong suggestion is to stop using xpdf, at least the version currently "shipped" in Debian unstable, until it is fixed (and kept in shape over time) by the current "maintainer" or by a new one. Luckly there are plenty of PDF viewers in Debian to choose from, with various UIs, dependencies, functionalities and so forth. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734352: libtext-bibtex-perl: FTBFS on hurd-i386
Source: libtext-bibtex-perl
Version: 0.66-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hi,
libtext-bibtex-perl fails to build on hurd-i386 [1].
The problem is in the test suite, which does not use $LD_LIBRARY_PATH
to locate the libbtparse.so.1 library in its output directory.
Attached there is a patch to use $LD_LIBRARY_PATH also on Hurd
($^O = 'gnu'), making the test suite pass successfully.
[1]
https://buildd.debian.org/status/fetch.php?pkg=libtext-bibtex-perl&arch=hurd-i386&ver=0.66-1&stamp=1377871517
Thanks,
--
Pino
--- a/inc/MyBuilder.pm
+++ b/inc/MyBuilder.pm
@@ -359,7 +359,7 @@ sub ACTION_test {
if ($^O =~ /darwin/i) {
$ENV{DYLD_LIBRARY_PATH} = catdir($self->blib, "usrlib");
}
-elsif ($^O =~ /(?:linux|bsd|sun|sol|dragonfly|hpux|irix)/i) {
+elsif ($^O =~ /(?:linux|bsd|sun|sol|dragonfly|hpux|irix|gnu)/i) {
$ENV{LD_LIBRARY_PATH} = catdir($self->blib, "usrlib");
}
elsif ($^O =~ /aix/i) {
Bug#735845: libbox2d-dev: please install the cmake configuration files
Package: libbox2d-dev Version: 2.3.0+ds-1 Severity: wishlist Tags: patch Hi, the new Box2D library installs configuration files for CMake, so that can find Box2D. Attached there is a patch to install them in libbox2d-dev, as they should be (together with other development files). Thanks, -- Pino --- a/debian/libbox2d-dev.install +++ b/debian/libbox2d-dev.install @@ -1,4 +1,5 @@ usr/include/* +usr/lib/*/Box2D/*.cmake usr/lib/*/libBox2D.a usr/lib/*/libBox2D.so usr/lib/*/pkgconfig
Bug#735885: RM: kdetoys -- ROM; replaced by split sources
Package: ftp.debian.org Severity: normal Hi, the monolithic kdetoys module has been split by upstream since KDE SC 4.11 in few smaller sources. The only loss package is kdetoys-dbg, but that is expected of course. Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735887: RM: kdeadmin -- ROM; replaced by split sources
Package: ftp.debian.org Severity: normal Hi, the monolithic kdeadmin module has been split by upstream since KDE SC 4.11 in few smaller sources. The only loss package is kdeadmin-dbg, but that is expected of course. Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735888: RM: kdenetwork -- ROM; replaced by split sources
Package: ftp.debian.org Severity: normal Hi, the monolithic kdenetwork module has been split by upstream since KDE SC 4.11 in few smaller sources. The only loss package is kdenetwork-dbg, but that is expected of course. Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735889: RM: kdesdk -- ROM; replaced by split sources
Package: ftp.debian.org Severity: normal Hi, the monolithic kdesdk module has been split by upstream since KDE SC 4.11 in few smaller sources. The only loss package is kdesdk-dbg, but that is expected of course. Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729064: poppler: CVE-2013-4473 CVE-2013-4474
Hi, sorry for the late reply, relocating can take your time. In data venerdì 8 novembre 2013 14:32:24, hai scritto: > Two security issues were found in the pdfseparate tool shipped by > poppler-utils: Luckly both of them are "minor" issues, that can be triggered just running pdfseparate. None of them affects oldstable, since pdfseparate does not exist in that old poppler. > CVE-2013-4473: buffer overflow > http://cgit.freedesktop.org/poppler/poppler/diff/utils/pdfseparate.cc? > id=b8682d868ddf7f741e93b This has been fixed upstream in 0.24.2. > CVE-2013-4474: format string issue > http://cgit.freedesktop.org/poppler/poppler/commit/?id=61f79b8447c3ac8 > ab5a26e79e0c28053ffdccf75 This has been fixed upstream in 0.24.3. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#729064: [Secure-testing-team] Bug#729064: poppler: CVE-2013-4473 CVE-2013-4474
Hi,
In data martedì 12 novembre 2013 23:47:21, hai scritto:
> On Fri, Nov 8, 2013 at 8:32 AM, Moritz Muehlenhoff wrote:
> > Two security issues were found in the pdfseparate tool shipped by
> > poppler-utils:
> Hi, I've uploaded an nmu fixing these two issue to delayed/5. Please
> see attached patch.
Unfortunately, one of your patches introduces the same issues it is
supposed to fix:
> +@@ -65,9 +66,37 @@
> + if (firstPage == 0)
> + firstPage = 1;
> + if (firstPage != lastPage && strstr(destFileName, "%d") == NULL) {
> +-error(-1, "'%s' must contain '%%d' if more than one page should be
> extracted", destFileName);
> ++error(-1, "'%s' must contain '%d' if more than one page should be
> extracted", destFileName);
> + return false;
error() in poppler < 0.19 takes a printf-like format, so changing from
%%d to %d will make printf expect an int, which is not passed as
argument (and thus a we run into a new format string issue).
For the same reason, also...
> ++ if (p != NULL) {
> ++error(-1, "'%s' can only contain one '%d' pattern", destFileName);
> ++free(auxDestFileName);
> ++return false;
> ++ }
... this error() contains the same issue.
Oh, and btw:
> +poppler (0.18.4-8+nmu1) unstable; urgency=high
The NMU version is wrong, since it is not a native package; it should
have been 0.18.4-8.1 instead, as also DevRef §5.11.2 says (but I see
you spread this wrong versioning when NMUing, so hardly something you
will change...)
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Bug#752269: texstudio: please enable parallel building
Source: texstudio
Version: 2.7.0+debian-2
Severity: wishlist
Tags: patch
Hi,
texstudio seems to build fine with multiple build jobs when building.
Thus, my suggestion is to enable the parallel build (with the
--parallel option of dh) to speed up the compilation when requested
(see also Policy §4.9.1).
Thanks,
--
Pino
--- a/debian/rules
+++ b/debian/rules
@@ -5,7 +5,7 @@ UPSTREAM_VERSION=$(shell dpkg-parsechang
| sed -rne 's,^Version: ([^-+]+).*,\1,p')
%:
- dh ${@}
+ dh ${@} --parallel
get-orig-source:
uscan --noconf --download --force-download --rename --destdir=. \
Bug#751525: transition: poppler 0.26
Hi, On 2014-06-24 10:52, Emilio Pozuelo Monfort wrote: On 14/06/14 12:11, Emilio Pozuelo Monfort wrote: On 13/06/14 20:41, Pino Toscano wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 751432 Hi, I would like to ask a slot for a Poppler 0.26.x transition. Currently there is Poppler 0.26.1 in experimental already. This transition impacts the existing poppler libraries in the following ways: - libpoppler44 → libpoppler46 - libpoppler-glib8 -- BC with 0.24 (with few new symbols) - libpoppler-qt4-4 -- BC with 0.24 (with one new symbol) - libpoppler-qt5-1 -- BC with 0.24 (with one new symbol) Below it is a list of sources which are touched by the transition, and their situation, sorted by solutions: Looks so good that I was going to ack it immediately, but unfortunately libreoffice clashes with the ongoing iceweasel transition, so let's wait until that finishes. libreoffice is about to transition, so please go ahead. I'll just wait until libreoffice migrates before scheduling its binNMU. Thanks for the ACK. Unfortunately I'm not that available for uploading, NMU gdcm and following the transition in the next 7 days. Please let me know whether there are blockers before July 3rd. Thanks, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732427: poppler-utils: 'pdftohtml -v' returns an exit code greater zero
Hi, this seems to be still an issue, even with development versions of Poppler. Would it be possible to report this upstream? https://bugs.freedesktop.org, product "poppler" and component "utils". Thanks for your report, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744257: attica: FTBFS on arm64 (symbols issue)
tag 744257 - patch thanks Hi, On 2014-04-12 02:46, Wookey wrote: Even with the updated kde-pkg-tools patch from https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=23;filename=pkg-kde-tools_0.15.13.arm64-subst-fix-2.patch;att=1;bug=744173 , this package doesn't build on arm64, because these two symbols are missing from the generated file: (optional=gccinternal)_ZN6Attica19DownloadDescription7PrivateD1Ev@Base 0.4.0 (optional=gccinternal)_ZN6Attica19DownloadDescription7PrivateD2Ev@Base 0.4.0 I don't know what that "(optional=gccinternal)" annotation means, although it saying 'optional' suggests to me that having it missing shouldn't fail the build, but it does. (optional=gccinternal) means a symbol is optional, so its lack won't cause a build failure. See also dpkg-gensymbols(1). It can be fixed with the attached patch to declare that these are not present on arm64. I don't know if this is the right fix, or if there is some other reason for these symbols being missing which we should look into? The patch is indeed wrong, and should not be applied. If you want more help on the issue, please do post a full build log. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744173: pkg-kde-tools: add arm64 support to SymbolsHelper
On 2014-04-11 04:45, Wookey wrote: Package: pkg-kde-tools Version: 0.15.13 Severity: important Tags: patch User: debian-...@lists.debian.org Usertag: arm64 SymbolsHelper needs to know about the new 64-bit architecture arm64 in order for any package that uses the (subst) Symbols file functionality to be buildable. This patch fixes that. Please follow my instructions in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656380#21 This will give us a better idea on the various type manglings on arm64. Thanks, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745714: missing multiarch paths on !linux
forwarded 745714 https://github.com/python-imaging/Pillow/pull/511
tag 745714 + upstream
thanks
On 2014-04-24 12:59, Christoph Egger wrote:
pillow currently does add multiarc paths on linux only. As a
result,
no decoders are built. The patch below should also add these on the
other debian architectures.
--- pillow-2.3.0.orig/setup.py
+++ pillow-2.3.0/setup.py
@@ -254,7 +254,8 @@ class pil_build_ext(build_ext):
except:
pass # homebrew not installed
-elif host_platform.startswith("linux"):
+elif host_platform.startswith("linux") or \
+ host_platform.startswith("gnu"): # Hurd / kFreeBSD
self.add_multiarch_paths()
elif host_platform.startswith("netbsd"):
This has been fixed upstream (by me) few months ago [1] (merged as
[2]),
and it is part of the new upstream release 2.4.0.
[1] https://github.com/python-imaging/Pillow/pull/511
[2]
https://github.com/python-imaging/Pillow/commit/cb309c9f59c6d4d9511112d0377b97c0b1a35a13
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740375: transition: poppler 0.24
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to ask a slot for a Poppler 0.24.x transition. I know a 0.22 transition has been done recently, but the future 0.26 will not be released at least for another month and it breaks few sources using the private libpoppler, so I would like to introduce 0.24 in Debian soon. Currently there is Poppler 0.24.x in experimental already. This transition impacts the existing poppler libraries in the following ways: - libpoppler37 → libpoppler44 Below it is a list of sources which are touched by the transition, and their situation, sorted by solutions: Sources that compile fine, and can be binNMU'ed: calligra cups-filters gambas3 gdal gdcm gnome-commander inkscape pdf2djvu pdftoipe popplerkit.framework texlive-bin Sources that currently FTBFS: * xpdf The version currently in unstable does not support Poppler 0.24, while the version in experimental does (#736443). * libreoffice LO 4.1 does not support Poppler 0.24 (needs an upstream commit [1]), while LO 4.2 (currently in experimental) does. Thus it is matter of either backporting that commit, or pushing LO 4.2 in unstable. Other cases: * derivations This source builds a libpoppler-based utility application which is only used during the build to generate other data, and no trace of that application are left in the resulting arch:all package. I grouped all the bugs mentioned above (even the solved ones) with the following usertag: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.24 A ben tracker for poppler would have: is_affected = .build-depends ~ "libpoppler-private-dev"; is_good = .depends ~ "libpoppler44"; is_bad = .depends ~ "libpoppler37"; [1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=828ebc542b980fce90e70459eb2d13e6eeecc355 Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740375: transition: poppler 0.24
On 2014-02-28 20:00, Rene Engelhard wrote: Hi, On Fri, Feb 28, 2014 at 07:44:28PM +0100, Pino Toscano wrote: * libreoffice LO 4.1 does not support Poppler 0.24 (needs an upstream commit [1]), sure? That mentioned commit *is* in 4.1.5 afaics? I know earlier versions of 4.1 didn't support 0.24, and I didn't check lately if it has been backported. Could you please check whether LO/sid builds fine with poppler 0.24? Thanks! -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740375: transition: poppler 0.24
On 2014-03-01 16:48, Rene Engelhard wrote: On Fri, Feb 28, 2014 at 08:39:15PM +0100, Rene Engelhard wrote: > Could you please check whether LO/sid builds fine with poppler 0.24? Will do. Builds and the sdext_pdfimport cppunit check passes. Thanks a lot! So, release-team, only xpdf would actually need a sourceful upload for this transition, and the other dozen sources could just need a binNMU. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740544: gnunet: FTBFS on !linux archs
Source: gnunet Version: 0.9.5a-3 Severity: important Tags: patch Hi, currently gnunet FTBFS on kfreebsd-*[1][2] and hurd-i386[3]. The problem is due to the gnunet-server.install.kfreebsd and gnunet-server.install.hurd files, which are outdated w.r.t. gnunet-server.install. Attached there is a patch which a) removes the useless leftovers of vpn, dns and gns stuff (which are useless as the related libraries are not built) b) generates gnunet-server.install.kfreebsd/.hurd dynamically based on gnunet-server.install, so they don't need to be shipped "statically" c) removes the now-dynamically-generated gnunet-server.install.kfreebsd/.hurd files Note I didn't test the result on either kFreeBSD or Hurd, so #702101 could still apply (and thus requiring more work). [1] https://buildd.debian.org/status/fetch.php?pkg=gnunet&arch=kfreebsd-i386&ver=0.9.5a-3&stamp=1393772529 [2] https://buildd.debian.org/status/fetch.php?pkg=gnunet&arch=kfreebsd-amd64&ver=0.9.5a-3&stamp=1393715732 [3] https://buildd.debian.org/status/fetch.php?pkg=gnunet&arch=hurd-i386&ver=0.9.5a-3&stamp=1393719014 Thanks, -- Pino --- a/debian/gnunet-server.install.hurd +++ /dev/null @@ -1,62 +0,0 @@ -etc/gnunet.conf -usr/bin/gnunet-arm -usr/bin/gnunet-ats -usr/bin/gnunet-config -usr/bin/gnunet-core -usr/bin/gnunet-fs -usr/bin/gnunet-gns* -usr/bin/gnunet-mesh -usr/bin/gnunet-namestore -usr/bin/gnunet-nat-server -usr/bin/gnunet-peerinfo -usr/bin/gnunet-resolver -usr/bin/gnunet-rsa -usr/bin/gnunet-testing -usr/bin/gnunet-testing-run-service -usr/bin/gnunet-transport -usr/bin/gnunet-transport-certificate-creation -usr/lib/*/gnunet/libexec/* -usr/lib/*/libgnunetarm.so.* -usr/lib/*/libgnunetats.so.* -usr/lib/*/libgnunetblock.so.* -usr/lib/*/libgnunetcore.so.* -usr/lib/*/libgnunetdatacache.so.* -usr/lib/*/libgnunetdht.so.* -usr/lib/*/libgnunetdnsstub.so.* -usr/lib/*/libgnunetfragmentation.so.* -usr/lib/*/libgnunethello.so.* -usr/lib/*/libgnunetlockmanager.so.0* -usr/lib/*/libgnunetmesh.so.* -usr/lib/*/libgnunetnamestore.so.* -usr/lib/*/libgnunetnat.so.* -usr/lib/*/libgnunetnse.so.* -usr/lib/*/libgnunetpeerinfo.so.* -usr/lib/*/libgnunetregex.so.* -usr/lib/*/libgnunetregexblock.so.* -usr/lib/*/libgnunetstream.so.* -usr/lib/*/libgnunettesting.so.* -usr/lib/*/libgnunettestbed.so.0* -usr/lib/*/libgnunettransport.so.* -usr/lib/*/libgnunettransporttesting.so.* -usr/lib/*/libgnunettun.so.* -usr/lib/*/gnunet/*.so -usr/share/gnunet/config.d -usr/share/gnunet/hellos/* -usr/share/gnunet/testing_hostkeys.ecc -usr/share/man/man1/gnunet-arm.1 -usr/share/man/man1/gnunet-ats.1 -usr/share/man/man1/gnunet-config.1 -usr/share/man/man1/gnunet-core.1 -usr/share/man/man1/gnunet-dns2gns.1 -usr/share/man/man1/gnunet-fs.1 -usr/share/man/man1/gnunet-gns.1 -usr/share/man/man1/gnunet-gns-fcfsd.1 -usr/share/man/man1/gnunet-gns-proxy.1 -usr/share/man/man1/gnunet-namestore.1 -usr/share/man/man1/gnunet-nat-server.1 -usr/share/man/man1/gnunet-peerinfo.1 -usr/share/man/man1/gnunet-rsa.1 -usr/share/man/man1/gnunet-transport.1 -usr/share/man/man1/gnunet-vpn.1 -usr/share/man/man5/gnunet.conf.5 -debian/man/* usr/share/man/man1/ --- a/debian/gnunet-server.install.kfreebsd +++ /dev/null @@ -1,62 +0,0 @@ -etc/gnunet.conf -usr/bin/gnunet-arm -usr/bin/gnunet-ats -usr/bin/gnunet-config -usr/bin/gnunet-core -usr/bin/gnunet-fs -usr/bin/gnunet-gns* -usr/bin/gnunet-mesh -usr/bin/gnunet-namestore -usr/bin/gnunet-nat-server -usr/bin/gnunet-peerinfo -usr/bin/gnunet-resolver -usr/bin/gnunet-rsa -usr/bin/gnunet-testing -usr/bin/gnunet-testing-run-service -usr/bin/gnunet-transport -usr/bin/gnunet-transport-certificate-creation -usr/lib/*/gnunet/libexec/* -usr/lib/*/libgnunetarm.so.* -usr/lib/*/libgnunetats.so.* -usr/lib/*/libgnunetblock.so.* -usr/lib/*/libgnunetcore.so.* -usr/lib/*/libgnunetdatacache.so.* -usr/lib/*/libgnunetdht.so.* -usr/lib/*/libgnunetdnsstub.so.* -usr/lib/*/libgnunetfragmentation.so.* -usr/lib/*/libgnunethello.so.* -usr/lib/*/libgnunetlockmanager.so.0* -usr/lib/*/libgnunetmesh.so.* -usr/lib/*/libgnunetnamestore.so.* -usr/lib/*/libgnunetnat.so.* -usr/lib/*/libgnunetnse.so.* -usr/lib/*/libgnunetpeerinfo.so.* -usr/lib/*/libgnunetregex.so.* -usr/lib/*/libgnunetregexblock.so.* -usr/lib/*/libgnunetstream.so.* -usr/lib/*/libgnunettesting.so.* -usr/lib/*/libgnunettestbed.so.0* -usr/lib/*/libgnunettransport.so.* -usr/lib/*/libgnunettransporttesting.so.* -usr/lib/*/libgnunettun.so.* -usr/lib/*/gnunet/*.so -usr/share/gnunet/config.d -usr/share/gnunet/hellos/* -usr/share/gnunet/testing_hostkeys.ecc -usr/share/man/man1/gnunet-arm.1 -usr/share/man/man1/gnunet-ats.1 -usr/share/man/man1/gnunet-config.1 -usr/share/man/man1/gnunet-core.1 -usr/share/man/man1/gnunet-dns2gns.1 -usr/share/man/man1/gnunet-fs.1 -usr/share/man/man1/gnunet-gns.1 -usr/share/man/man1/gnunet-gns-fcfsd.1 -usr/share/man/man1/gnunet-gns-proxy.1 -usr/share/man/man1/gnunet-namestore.1 -usr/share/man/man1/gnunet-nat-server.1 -usr/share/man/man1/gnunet-peerinfo.1 -usr/share/man/man1/gnunet-rsa.1 -usr/share/man/man1/gnunet-tra
Bug#739674: [PATCH] fix inet client connections
reassign 739674 src:libtirpc
tag 739674 + patch
thanks
Hi,
When trying to setup a inet connection, it happens the following:
- in libtirp, src/clnt_vc.c, clnt_vc_create gets called
- when trying to allocate vc_fd_locks, __rpc_dtbsize() is used as size
for that array of fd locks
- __rpc_dtbsize(), in src/rpc_generic.c, queries using rlimit the
maximum (rlim_max) number of file descriptors (RLIMIT_NOFILE):
- on Linux, the default is { rlim_cur = 1024, rlim_max = 4096 }
- on kFreeBSD, the default is { rlim_cur = 1024, rlim_max = 1024 }
- on Hurd, the default is { rlim_cur = 1024, rlim_max = RLIM_INFINITY
}
meaning that on Hurd the memory allocation fails (as
__rpc_dtbsize() * sizeof(int) overflows and is negative)
Attached there is a patch for libtiprc so __rpc_dtbsize falls back on
rlim_cur if rlim_max is unlimited.
The patch fixes the client connection using inet sockets; local unix
sockets are not working, for two reasons so far:
- getpeername on them gives EOPNOTSUPP
- SO_REUSEADDR is not implemented for them
Thanks,
--
Pino--- a/src/rpc_generic.c
+++ b/src/rpc_generic.c
@@ -108,12 +108,17 @@
{
static int tbsize;
struct rlimit rl;
+ rlim_t lim;
if (tbsize) {
return (tbsize);
}
if (getrlimit(RLIMIT_NOFILE, &rl) == 0) {
- return (tbsize = (int)rl.rlim_max);
+ lim = rl.rlim_max;
+ if (lim == RLIM_INFINITY) {
+ lim = rl.rlim_cur;
+ }
+ return (tbsize = (int)lim);
}
/*
* Something wrong. I'll try to save face by returning a
Bug#739674: [PATCH] fix inet client connections
On 2014-03-02 21:14, Petter Reinholdtsen wrote: [Pino Toscano] Attached there is a patch for libtiprc so __rpc_dtbsize falls back on rlim_cur if rlim_max is unlimited. I tried this patch on Hurd, and rpcinfo -p is still not working after I build libtirpc1_0.2.2-5.2_hurd-i386.deb and installed it. Am I testing the wrong thing? root@hurdtest:~# dpkg -i libtirpc1_0.2.2-5.2_hurd-i386.deb (Reading database ... 50646 files and directories currently installed.) Preparing to unpack libtirpc1_0.2.2-5.2_hurd-i386.deb ... Unpacking libtirpc1:hurd-i386 (0.2.2-5.2) over (0.2.2-5.1) ... Setting up libtirpc1:hurd-i386 (0.2.2-5.2) ... Processing triggers for man-db (2.6.6-1) ... Processing triggers for libc-bin (2.18-3) ... root@hurdtest:~# rpcinfo -p rpcinfo: can't contact portmapper: RPC: Remote system error - Operation not supported root@hurdtest:~# ps -ef|grep rpc root 694 1 - 0:00.04 /sbin/rpcbind -w root 2002 19709 p0 0:00.00 grep rpc root@hurdtest:~# /etc/init.d/rpcbind restart [ ok ] Stopping rpcbind daemon [ ok ] Starting rpcbind daemon root@hurdtest:~# ps -ef|grep rpc root 2031 1 - 0:00.01 /sbin/rpcbind -w root 2053 19709 p0 0:00.00 grep rpc root@hurdtest:~# rpcinfo -p rpcinfo: can't contact portmapper: RPC: Remote system error - Operation not supported root@hurdtest:~# I said earlier that unix sockets are not working yet, so you might try: # rpcinfo -p 127.0.0.1 (or whatever is the IP address of the service) -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740726: poppler: fails to build from source
Hi, On 2014-03-04 13:51, alex bodnaru wrote: Source: poppler Version: 0.22.5 Severity: important Dear pino, i'm building poppler with every upgrade in order to apply my rtl related patches. now it fails to build, claiming for a missing aclocal-1.13 and automake-1.13 the available versions are 1.9, 1.10, 1.11, 1.14, and 1.19. the source package should probably depend on the correct version, that would have probably prevented it's dissappearance. Please post the *full* build log. Also, make sure you are building in a clean way, and not from an already built source tree. Thanks, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740726: poppler: fails to build from source
Hi, On 2014-03-05 00:24, alex bodnaru wrote: i'm attaching my short build log. i have tried to build right after apt-get source. my patches do not refer to automake/aclocal/their version. i'm ready for any further test. What if you try to build *without* your patches, i.e. just the sources as you get them from the Debian archive? (Note a clean build is better.) -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740751: pdftoppm gets width and height backward for a "rotated" PDF
Hi,
On 2014-03-04 19:24, Josh Triplett wrote:
Package: poppler-utils
Version: 0.22.5-4
Severity: normal
$ pdftoppm -png -f 1 -l 1 -scale-to-x 800 -scale-to-y 600 test.pdf |
file -
/dev/stdin: PNG image data, 600 x 800, 8-bit/color RGB,
non-interlaced
$ pdftoppm -png -f 1 -l 1 -scale-to-x 600 -scale-to-y 800 test.pdf |
file -
/dev/stdin: PNG image data, 800 x 600, 8-bit/color RGB,
non-interlaced
$ pdfinfo test.pdf | grep '^Page '
Page size: 612 x 792 pts (letter)
Page rot: 90
This breaks the ability for a script to use
-scale-to-x $width -scale-to-y $height to generage a
${width}x${height}
image. A script should not need to check the PDF's rotation first
and
swap the dimensions.
Please provide a sample document showing the issue.
Also, could you please test with poppler-utils in experimental
(i.e. 0.24.x)?
Thanks,
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740754: pdftocairo: Completely incorrect output dimensions for rotated PDFs
Hi, On 2014-03-04 19:30, Josh Triplett wrote: Package: poppler-utils Version: 0.22.5-4 Severity: normal $ pdftocairo -png -f 1 -l 1 -scale-to-x 800 -scale-to-y 600 test.pdf test $ file test-01.png test-01.png: PNG image data, 1036 x 464, 8-bit/color RGB, non-interlaced $ pdftocairo -png -f 1 -l 1 -scale-to-x 600 -scale-to-y 800 test.pdf test $ file test-01.png test-01.png: PNG image data, 777 x 619, 8-bit/color RGB, non-interlaced $ pdfinfo test.pdf | grep '^Page ' Page size: 612 x 792 pts (letter) Page rot: 90 Please provide a sample document showing the issue. Also, could you please test with poppler-utils in experimental (i.e. 0.24.x)? Thanks, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740375: transition: poppler 0.24
Control: tag -1 pending On 2014-04-05 15:54, Julien Cristau wrote: On Fri, Feb 28, 2014 at 19:44:28 +0100, Pino Toscano wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to ask a slot for a Poppler 0.24.x transition. Feel free to upload to unstable. Thanks! Uploaded few hours ago, and now built everywhere. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743817: libpoppler-dev: Multi-arch -dev packages
severity 743817 wishlist thanks Hi, On 2014-04-06 21:13, Marc Glisse wrote: Package: libpoppler-dev Version: 0.24.5-3 Severity: normal Dear Maintainer, it is good that libpoppler44 is Multi-Arch: same (thanks), but it would be even better if the -dev packages were as well. libpoppler-dev has all its content in /usr/lib/$arch (except for changelog and copyright), so it seems really safe. The others should be as well, unless the includes or the gir file contain build-generated arch-specific data. What's the use case for marking libpoppler-dev as m-a: same? Alone it has no value in being so. Some dependencies may not be multiarch yet (qtbase5-dev) but I don't think it should prevent from marking libpoppler-qt5-dev (which would then become co-installable automatically when qtbase5-dev is updated), and it doesn't concern libpoppler-dev. - libqt4-dev (for libpoppler-qt4-dev) is not m-a: same safe - qtbase5-dev (for libpoppler-qt5-dev) is not m-a: same safe - libglib2.0-dev and the gir stuff (for libpoppler-glib-dev) are not m-a: same safe so it is pointless mark those -dev as m-a: same, for now. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698456:
On 2014-04-07 11:09, Mathieu Malaterre wrote: Control: severity -1 grave Control: found -1 0.18.4-6 This "found" contraddicts what the reporter says in message #15, so either you are trying with a different document or the reporter is not providing correct information. Moving to grave, since I cannot even read the PDF (PDF are generated by a bank application, which makes those PDF pretty much useless with evince). I think "grave" as severity for "I cannot read this particular PDF" is slightly overinflated. Please downgrade back to "important", thanks. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740375: transition: poppler 0.24
On 2014-04-06 18:57, Julien Cristau wrote: On Sat, Apr 5, 2014 at 23:16:25 +0200, Pino Toscano wrote: Uploaded few hours ago, and now built everywhere. Scheduled binnmus (except for gdal, want to get -5 in testing first). Thanks for the binNMUs (no problem delaying gdal's binNMUs). A small update regarding the situation so far: - gambas3 seems to be FTBFSing (what a surprise...) due to something related to pgsql; can be kicked out of testing, in case - gdcm cannot be built on s390x due to the ongoing (and un-ACKed...) mpich transition (#742821), so maybe that transition should be brought forward (luckly it affects mostly s390x and mips/mipsel) - gnome-commander FTBFSes on armel/armhf; the new upstream release 1.4.1 fixes that FTBFS, and also switches the libpoppler usage to poppler-glib (which would make it out of this transition); I contacted Alessio about it, and he should upload it within few days -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698456:
On 2014-04-07 18:00, Mathieu Malaterre wrote: Control: reassign -1 evince Control: found -1 3.4.0-3.1 Control: severity -1 important On Mon, Apr 7, 2014 at 5:37 PM, Pino Toscano wrote: On 2014-04-07 11:09, Mathieu Malaterre wrote: Control: severity -1 grave Control: found -1 0.18.4-6 This "found" contraddicts what the reporter says in message #15, so either you are trying with a different document or the reporter is not providing correct information. OP is not very clear either. Apparently the bug would be fixed with '0.18.4-6' on 'jessie'. Well, I don't care much about names, but about versions. What I can tell, is that the bug is present on default wheezy installation (x86_64). I saw the corruption of my PDF generated bank account (OP is using the same bank online service) Well, so far you have not provided enough information to even say that your problem is the one that was reported here in #698456. - can you reproduce the issue reported with the *provided* PDF document? - can you please run evince from command line, and paste as-is the output you get from it when opening your document? - can you please provide (if possible) a screenshot of evince opening your document? I do not believe the issue lie within the poppler code base since `pdftoppm` behave as expected. So the rendering issue should (must?) be within evince codebase. Thus re-assigning. Sigh, no. Evince renders documents using poppler-glib, which uses the cairo-based rendering backend of Poppler. So your reassign is wrong. (You can check yourself with other PDF viewers using poppler-glib, for example apvlv, epdfview, gpdftext.) Mathieu, I understand you care about solving the issue with your PDF document, being able to view it on your Wheezy installation. But please, provide *all* the information you can and let maintainers look into it, instead of just telling "my document does not work", changing the priority and randomly the product as well. Thanks, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745943: quickfix: FTBFS on hurd-i386: missing pthread usage
Source: quickfix
Version: 1.13.3+dfsg-8
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hi,
quickfix does not compile on GNU/Hurd [1].
The problem seems the same which appeared on kfreebsd-*, and that has
been solved in 1.13.3+dfsg-8 adding -pthread to the build flags.
Ideally a better solution would be using autoconf to detect the need
for cflags/ldlibs/etc for pthreads, but since the kfreebsd issue was
solved forcing -pthread in rules, I extended that for any non-Linux
architecture.
[1]
https://buildd.debian.org/status/fetch.php?pkg=quickfix&arch=hurd-i386&ver=1.13.3%2Bdfsg-8&stamp=1397464672
Thanks,
--
Pino
--- a/debian/rules
+++ b/debian/rules
@@ -16,6 +16,7 @@ include /usr/share/quilt/quilt.make
DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
+DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
CROSS= --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
else
@@ -33,10 +34,10 @@ CFLAGS += -O3 -msse3
CXXFLAGS += -O3 -msse3
endif
-# Fix FTBFS on kfreebsd-* builds, which require explicit pthread linkage
+# Fix FTBFS on !linux builds, which require explicit pthread linkage
# Using CFLAGS/CXXFLAGS feels like an ugly hack, but no amount of coaxing with
# DEB_LDFLAGS_MAINT_{PRE,AP}PEND seems to get the flag in the right position
-ifneq (,$(findstring kfreebsd,$(DEB_HOST_ARCH)))
+ifneq (linux,$(DEB_HOST_ARCH_OS))
CFLAGS += -pthread
CXXFLAGS += -pthread
endif
Bug#746540: bind9: FTBFS on hurd-i386
Source: bind9 Version: 1:9.9.5.dfsg-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, bind9 does not compile on Hurd since version 9.9.5 [1]. The problem is much like kFreeBSD's #741285, i.e. missing LDFLAGS when having ldopen. The attached patch extends the fix of #741285 to properly cover Hurd as well, whose GNU triplet is like "i686-unknown-gnu0.5". [1] https://buildd.debian.org/status/fetch.php?pkg=bind9&arch=hurd-i386&ver=1%3A9.9.5.dfsg-4&stamp=1398846530 Thanks, -- Pino --- a/configure.in +++ b/configure.in @@ -3568,7 +3568,7 @@ fi if test "$dlopen" = "yes"; then case $host in - *-linux*|*-gnu) + *-linux*|*-gnu*) SO_CFLAGS="-fPIC" if test "$have_dl" = "yes" then
Bug#748816: qtmultimedia-opensource-src: FTBFS on kfreebsd-*
severity 748816 important tag 748816 + pending thanks On 2014-05-21 03:05, Steven Chamberlain wrote: Package: qtmultimedia-opensource-src Version: 5.2.1-3 Severity: serious Note that qtmultimedia-opensource-src has never built on kfreebsd so far (or on any non-linux architecture, for what could matter). Thus this is not a regression, hence "serious" is wrong for it. The apparently missing file libfftreal.so.1 is in the same directory as the spectrum executable, but dpkg-shlibdeps does not seem to know to look for it there. For example in debian/qtmultimedia5-examples/usr/lib/x86_64-kfreebsd-gnu/qt5/examples/multimedia/spectrum: $ LD_LIBRARY_PATH=. ldd spectrum libfftreal.so.1 => ./libfftreal.so.1 (0x000801242000) $ file libfftreal.so.1 libfftreal.so.1: symbolic link to `libfftreal.so.1.0.0' $ file libfftreal.so.1.0.0 libfftreal.so.1.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, BuildID[sha1]=dbbcf445566c4944a39504c3c2720654d813a305, stripped This was just a missing rpath in that spectrum example to locate the fftreal library; patch committed in our packaging repository. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749221: colord: FTBFS on !linux archs
Source: colord Version: 1.2.0-1 Severity: serious Tags: patch Justification: fails to build from source Hi, colord 1.2.0-1 fails to build on non-Linux archs [1][2]. The issue is that udev is searched by default, and configure bails out if it is not found. Easy solution is to enable udev on Linux architectures, and forcing it off on non-Linux ones; patch attached for it. [1] https://buildd.debian.org/status/fetch.php?pkg=colord&arch=kfreebsd-amd64&ver=1.2.0-1&stamp=1400394452 [2] https://buildd.debian.org/status/fetch.php?pkg=colord&arch=kfreebsd-i386&ver=1.2.0-1&stamp=1400394114 Thanks, -- Pino --- a/debian/rules +++ b/debian/rules @@ -31,9 +31,9 @@ confflags = \ # --enable-libcolordcompat ifeq ($(DEB_HOST_ARCH_OS),linux) - confflags += --enable-sane --enable-gusb --enable-systemd-login + confflags += --enable-sane --enable-gusb --enable-systemd-login --enable-udev else - confflags += --disable-sane --disable-gusb --disable-systemd-login + confflags += --disable-sane --disable-gusb --disable-systemd-login --disable-udev endif override_dh_auto_configure:
Bug#749222: colord: FTBFS on hurd-i386
Source: colord Version: 1.2.0-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Control: block -1 by 749221 Hi, colord 1.2.0-1 cannot be built on hurd-i386 as it build depends on argyll, which is not available on this architecture at the moment. Since its usage is only to generate extra print profiles, attached there is a patch to disable them on hurd-i386. Note that this patch applies on top of #749221, as that bug applies also on hurd-i386 (being a non-Linux architecture). Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -24,7 +24,7 @@ Build-Depends: libsystemd-login-dev [linux-any], bash-completion, dh-systemd (>= 1.4), - argyll, + argyll [!hurd-any], Standards-Version: 3.9.5 XS-Testsuite: autopkgtest Section: graphics --- a/debian/rules +++ b/debian/rules @@ -22,8 +22,7 @@ confflags = \ --with-systemdsystemunitdir=/lib/systemd/system \ --with-udevrulesdir=/lib/udev/rules.d \ --enable-vala \ - --disable-silent-rules \ - --enable-print-profiles + --disable-silent-rules # Disabled; Needs Argyll >= 1.6 (not yet in Debian) to be useful # Installs plugin into global search path; we'll probably need to patch @@ -36,6 +35,12 @@ else confflags += --disable-sane --disable-gusb --disable-systemd-login --disable-udev endif +ifeq ($(DEB_HOST_ARCH_OS),hurd) + confflags += --disable-print-profiles +else + confflags += --enable-print-profiles +endif + override_dh_auto_configure: dh_auto_configure -- $(confflags)
Bug#749223: blender: FTBFS on hurd-i386
Source: blender Version: 2.70a-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, blender does not compile on GNU/Hurd [1]. The problem is the missing handling for malloc_usable_size in intern/guardedalloc/intern/mallocn_intern.h, much like as it was reported in #748322. Unfortunately, that bug has been fixed only for kFreeBSD... Attached there is a patch, which *replaces* the existing patch 0013-fix_FTBFS_on_kFreeBSD.patch, which fixes the build on any glibc-based OS. It has been build-tested on kFreeBSD and Hurd. [1] https://buildd.debian.org/status/fetch.php?pkg=blender&arch=hurd-i386&ver=2.70a-1&stamp=1400508629 Thanks, -- Pino --- a/intern/guardedalloc/intern/mallocn_intern.h +++ b/intern/guardedalloc/intern/mallocn_intern.h @@ -51,7 +51,7 @@ #undef HAVE_MALLOC_STATS -#if defined(__linux__) +#if defined(__linux__) || defined(__GLIBC__) # include # define HAVE_MALLOC_STATS #elif defined(__FreeBSD__)
Bug#740751: Sample rotated PDF for these bugs
Hi, sorry for the late reply. On 2014-03-09 03:07, Josh Triplett wrote: I've attached a sample PDF which triggers both of these bugs. I've also confirmed that the issue still exists with poppler-utils 0.24.5-2 from experimental. Since few days there is poppler 0.26.0 in experimental (and since yesterday 0.26.1), and it seems your problems still happen with it too? If so, could you please report the issues upstream? It's at https://bugs.freedesktop.org, "poppler" product. Thanks for your reports, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749286: xserver-xorg-input-synaptics: unbuildable on !linux archs
Source: xserver-xorg-input-synaptics Version: 1.8.0-1~exp1 Severity: serious Tags: patch Justification: fails to build from source (but built successfully in the past) Hi, xserver-xorg-input-synaptics 1.8.0-1~exp1 cannot be built on non-Linux archs because of the libevdev-dev B-D (which is Linux-specific). The attached patch limits the libevdev-dev B-D as linux-any, as it is used only for the eventcomm Linux backend. Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -9,7 +9,7 @@ Build-Depends: libx11-dev, libxext-dev, libxi-dev (>= 2:1.2.0), - libevdev-dev, + libevdev-dev [linux-any], x11proto-core-dev, xserver-xorg-dev (>= 2:1.12), pkg-config,
Bug#749290: g++-4.8: broken std::thread on Hurd
On 2014-05-26 02:31, Gabriele Giacone wrote:
$ wget
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1228201/+attachment/3831609/+files/thread.cpp
$ g++ thread.cpp -pthread -std=c++11 -o thread
$ ./thread
terminate called after throwing an instance of 'std::system_error'
what(): Enable multithreading to use std::thread: Operation not
permitted
Aborted
This happens because in gcc/src/libstdc++-v3/src/c++11/thread.cc,
thread::_M_start_thread throws EPERM if __gthread_active_p is false.
__gthread_active_p, implemented inline in bits/gthr-default.h, does
the following (simplified):
__gthrw2(__gthrw_(__pthread_key_create),
__pthread_key_create,
pthread_key_create)
# define GTHR_ACTIVE_PROXY __gthrw_(__pthread_key_create)
[...]
static inline int
__gthread_active_p (void)
{
static void *const __gthread_active_ptr
= __extension__ (void *) >HR_ACTIVE_PROXY;
return __gthread_active_ptr != 0;
}
so checks for the presence of __pthread_key_create to determine
whether threads are available, with a lengthy comment saying why that
symbol is checked when using the GNU C library.
Indeed, creating a simple extern "C" __pthread_key_create which just
calls pthread_key_create in the test case makes it run fine.
It looks like to me there are two solutions:
a) fix the GCC detection of threads on Hurd, so it uses only
pthread_key_create (or another internal symbol of Hurd's
libpthread)
b) fix pthread_key_create in Hurd's libpthread, changing it to
__pthread_key_create and declaring pthread_key_create as strong
alias, just like it is done in NPTL
IMHO most probably (b) is the most realistic and easy to do.
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749290: g++-4.8: broken std::thread on Hurd
On 2014-05-26 11:50, Matthias Klose wrote: see https://gcc.gnu.org/ml/gcc/2013-09/msg00196.html and follow-ups. Is this really specific for the Hurd? I cannot reproduce the "Operation not permitted" exception on updated - Debian/Linux testing installation - Debian/Linux unstable installation so I'm inclined to say this specific issue is Hurd-specific, yes. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749459: kdiff3: please enable parallel building
Source: kdiff3 Version: 0.9.97-3 Severity: wishlist Tags: patch Hi, kdiff3 seems to build fine with multiple build jobs when building. Thus, my suggestion is to enable the parallel build (enabling it in CDBS, and manually using its flags when invoking make) to speed up the compilation when requested (see also Policy §4.9.1). Thanks, -- Pino --- a/debian/rules +++ b/debian/rules @@ -10,6 +10,7 @@ # --- DEB_COMPRESS_EXCLUDE := ".docbook" +DEB_BUILD_PARALLEL = 1 include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/cmake.mk @@ -25,7 +26,7 @@ clean:: build/kdiff3-qt:: qmake-qt4 -nocache src-QT4/kdiff3.pro -o src-QT4/Makefile - make -C src-QT4 prefix=$(CURDIR)/debian/kdiff3-qt + make $(DEB_MAKE_PARALLEL) -C src-QT4 prefix=$(CURDIR)/debian/kdiff3-qt install/kdiff3:: # install man page
Bug#749460: kdiff3: please link in as-needed mode
Source: kdiff3 Version: 0.9.97-3 Severity: wishlist Tags: patch Hi, currently the KDE version of kdiff3 gets overlinked with libraries it does not actually use (e.g. libnepomuk, libQt3Support, etc). Thus, it should be safe to link in as-needed mode and avoid linking to unused libraries. Attached there is a patch for this, which enables the flag using dpkg-buildflags. Thanks, -- Pino --- a/debian/rules +++ b/debian/rules @@ -11,6 +11,8 @@ DEB_COMPRESS_EXCLUDE := ".docbook" +export DEB_LDFLAGS_MAINT_APPEND := -Wl,--as-needed + include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/cmake.mk # include /usr/share/cdbs/1/rules/simple-patchsys.mk
Bug#749508: segfault while trying to open an .ai file
tag 749508 + moreinfo thanks Hi, thanks for your report. On 2014-05-27 16:35, Yaroslav Halchenko wrote: $> wget -q http://www.onerussian.com/tmp/NITRC_IR.ai $> gdb --args inkscape NITRC_IR.ai GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1.1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/inkscape...(no debugging symbols found)...done. (gdb) r Starting program: /usr/bin/inkscape NITRC_IR.ai warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". inkscape: malloc.c:2368: sysmalloc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed. Program received signal SIGABRT, Aborted. 0x7fffef3a93a9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x7fffef3a93a9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7fffef3ac4c8 in __GI_abort () at abort.c:89 #2 0x7fffef3ebd0d in __malloc_assert (assertion=assertion@entry=0x7fffef4dac40 "(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)__builtin_offs"..., file=file@entry=0x7fffef4d66d1 "malloc.c", line=line@entry=2368, function=function@entry=0x7fffef4d6a58 <__func__.11276> "sysmalloc") at malloc.c:290 #3 0x7fffef3ee889 in sysmalloc (av=0x7fffef717620 , nb=416) at malloc.c:2365 #4 _int_malloc (av=0x7fffef717620 , bytes=408) at malloc.c:3743 #5 0x7fffef3efc80 in __GI___libc_malloc (bytes=408) at malloc.c:2858 #6 0x7fffefeb1e6d in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #7 0x704dc56d in PDFDoc::PDFDoc(GooString*, GooString*, GooString*, void*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.44 #8 0x7017130f in poppler_document_new_from_file () from /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8 #9 0x0079e224 in Inkscape::Extension::Internal::PdfImportDialog::PdfImportDialog(PDFDoc*, char const*) () #10 0x0079eb03 in Inkscape::Extension::Internal::PdfInput::open(Inkscape::Extension::Input*, char const*) () #11 0x0077ffda in Inkscape::Extension::open(Inkscape::Extension::Extension*, char const*) () #12 0x00635f50 in sp_file_open(Glib::ustring const&, Inkscape::Extension::Extension*, bool, bool) () #13 0x0062b703 in sp_main_gui(int, char const**) () #14 0x0060f1ff in main () Interesting, it seems that malloc is indirectly crashing, just for 408 bytes. I cannot reproduce it here, so if you still can, I'd suggest to a) make sure poppler-dbg is installed b) run valgrind on something "lighter", like poppler's pdftoppm (if you can reproduce the problem with it), or otherwise on inkscape On the other hand... -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental') ... your system is a testing installation, yet... ii libc6 2.18-4 ii multiarch-support 2.18-5 ... these two come from the same source (eglibc), yet a) their versions are not the same b) none of them is up-to-date wrt what's currently in testing (2.18-7) ii libstdc++6 4.8.2-1 This is not up-to-date either. Hence my suggestion is to make sure your system is *really* up-to-date first. Thanks, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749911: libcurses-perl: FTBFS on hurd-i386: outdated c-gnu.h
Source: libcurses-perl Version: 1.31-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, libcurses-perl 1.31-1 fails to compile on GNU/Hurd [1]. The problem is that the "hints" header c-gnu.h, provided by the Debian patch libcurses-perl_hurd1.debdiff, is not up-to-date w.r.t. the changes done upstream between 1.28 and 1.31 to the "hints" headers. Attached there is an updated version of the hurd patch, which allows libcurses-perl to build again. Would it be possible to forward it upstream, so this header will need less Debian-specific handling? [1] https://buildd.debian.org/status/fetch.php?pkg=libcurses-perl&arch=hurd-i386&ver=1.31-1&stamp=1401458475 Thanks, -- Pino From: Barry deFreese From: Pino Toscano Origin: vendor Bug-Debian: http://bugs.debian.org/533698 Subject: Fix build failure on Debian GNU/Hurd This fixes a FTBFS on Debian GNU/Hurd because it is missing a hints file. Last-Update: 2014-05-30 --- /dev/null +++ b/hints/c-gnu.h @@ -0,0 +1,27 @@ +/* Hint file for the GNU platform. + * + * If this configuration doesn't work, look at the file "c-none.h" + * for how to set the configuration options. + */ + +#include + +#ifdef C_PANELFUNCTION +#include +#endif + +#ifdef C_MENUFUNCTION +#include +#endif + +#ifdef C_FORMFUNCTION +#include +#endif + +#define C_LONGNAME +#define C_LONG0ARGS +#undef C_LONG2ARGS + +#define C_TOUCHLINE +#define C_TOUCH3ARGS +#undef C_TOUCH4ARGS
Bug#749911: libcurses-perl: FTBFS on hurd-i386: outdated c-gnu.h
Hi, On 2014-05-30 17:07, Axel Beckert wrote: Pino Toscano wrote: The problem is that the "hints" header c-gnu.h, provided by the Debian patch libcurses-perl_hurd1.debdiff, is not up-to-date w.r.t. the changes done upstream between 1.28 and 1.31 to the "hints" headers. Attached there is an updated version of the hurd patch, which allows libcurses-perl to build again. Would it be possible to forward it upstream, so this header will need less Debian-specific handling? Without having looked at it and just based on your description: Is there a chance that neither we nor upstream will have to ship that file and keep it uptodate, but that we build-depend on something on hurd-i386 only and we just have to "#include" that? Unless upstream changes the way those ncurses "hints" header work, I'd say working around it locally just makes things worse. For the rest, I guess it might be better to take a look at the actual files in the hints/ subdirectory. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749923: libcmocka-dev: please include the cmake config files
Package: libcmocka-dev Version: 0.4.1-1 Severity: wishlist Tags: patch Hi, since 0.4.1, cmocka installs configuration files for cmake, which currently are not installed in libcmocka-dev. The attached patch includes them as well. (PS: passing --list-missing or --fail-missing to dh_install helps spotting files installed by upstream but not placed in any binary.) Thanks, -- Pino --- a/debian/libcmocka-dev.install +++ b/debian/libcmocka-dev.install @@ -1,3 +1,4 @@ usr/include/cmocka.h +usr/lib/*/cmake/cmocka usr/lib/*/libcmocka.so usr/lib/*/pkgconfig
Bug#749968: claws-mail: please remove the extra libpoppler-dev build dependency
Source: claws-mail Version: 3.9.3-2 Severity: wishlist Tags: patch Hi, claws-mail build depends on libpoppler-glib-dev for the PDF viewer support, as it uses poppler-glib. Hence, the libpoppler-dev (which is pulled by libpoppler-glib-dev, but otherwise wouldn't be needed) build dependency is not used, so it could be removed. Patch attached for it. Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -15,7 +15,7 @@ Build-Depends: debhelper (>= 9), libcomp libwebkitgtk-dev, libgdata-dev (>= 0.6.4), libnotify-dev, libindicate-dev, libcanberra-gtk-dev, - libpoppler-dev, libpoppler-glib-dev (>= 0.4.2), + libpoppler-glib-dev (>= 0.4.2), libperl-dev (>= 5.8.0), perl (>= 5.8.0), libgpgme11-dev (>= 1.1.1), python-gtk2-dev (>= 2.10.3),
Bug#749971: texworks: please enable parallel building
Source: texworks Version: 0.5~svn1363-3 Severity: wishlist Tags: patch Hi, texworks seems to build fine with multiple build jobs when building. Thus, my suggestion is to enable the parallel build (reading the number of jobs from DEB_BUILD_OPTIONS, and adding it to the make invocation) to speed up the build when requested (see also Policy §4.9.1). Thanks, -- Pino --- a/debian/rules +++ b/debian/rules @@ -15,6 +15,10 @@ include /usr/share/dpkg/buildflags.mk CFLAGS+=$(CPPFLAGS) CXXFLAGS+=$(CPPFLAGS) +ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) +NJOBS := -j $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) +endif + .PHONY: build-arch build-indep build clean binary-indep binary-arch binary install configure @@ -38,7 +42,7 @@ build-arch: build-stamp # Build architecture-dependent files build-stamp: configure-stamp dh_testdir - cd build && $(MAKE) VERBOSE=1 + cd build && $(MAKE) $(NJOBS) VERBOSE=1 touch $@ clean:
Bug#749972: Drop the unused libgtk2.0-dev build dependency.
On 2014-05-31 11:28, Peter Pentchev wrote: As an added bonus, it will break one more circular build dependency except the QT 4 and 5 ones that I'll file the abovementioned separate bugs for. Please don't, there's #738338 already. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750004: libpoppler44: Some PDF Files are rendered wrong
fixed 750004 poppler/0.26.1-1 thanks Hi Manuel, On 2014-05-31 16:27, Manuel Gräber wrote: The Bug has already been reported at: https://bugs.freedesktop.org/show_bug.cgi?id=78389 It will be fixed in 0.26.1 (but not for 0.24) So it works when using poppler from experimental, right? It seems so to me, hence I'm marked this bug as fixed in that version but leaving it open; I'll evaluate whether backport this fix, or just try to get 0.26.x sooner. Thanks for your report, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749888: gnome-terminal: FTBFS on kfreebsd & hurd archs
tag 749888 + patch thanks Hi, On 2014-05-31 15:43, Robert Millan wrote: Which makes me wonder: Does gnome-terminal actually work without gnome-shell? It seems (just looking at the sources, I'm not a GNOME guy) gnome-shell is needed to integrate gnome-terminal as search provider for gnome-shell; OTOH the feature seems optional, and passing --disable-search-provider indeed disables it. Attached a first version of patch for it; the changes to control.in and rules should be fine, while most probably the .install files could need few tricks (since gnome-terminal-search-provider.ini is not installed). GNOME team: if you could help on this, that would be great. Thanks, -- Pino Toscano--- a/debian/control.in +++ b/debian/control.in @@ -26,7 +26,7 @@ Build-Depends: cdbs (>= 0.4.41), desktop-file-utils, appdata-tools, gsettings-desktop-schemas-dev (>= 0.1.0), - gnome-shell, + gnome-shell [linux-any], libnautilus-extension-dev Vcs-Svn: svn://anonscm.debian.org/pkg-gnome/desktop/unstable/gnome-terminal/ Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-terminal/ --- a/debian/rules +++ b/debian/rules @@ -9,10 +9,16 @@ include /usr/share/gnome-pkg-tools/1/rul include /usr/share/gnome-pkg-tools/1/rules/gnome-version.mk -include /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk +DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) + LDFLAGS += -Wl,-z,defs -Wl,-O1 -Wl,--as-needed DEB_CONFIGURE_EXTRA_FLAGS += --enable-distro-packaging +ifneq ($(DEB_HOST_ARCH_OS),linux) +DEB_CONFIGURE_EXTRA_FLAGS += --disable-search-provider +endif + build/gnome-terminal:: /usr/bin/docbook-to-man debian/gnome-terminal.sgml > debian/gnome-terminal.1 --- a/debian/gnome-terminal.install +++ b/debian/gnome-terminal.install @@ -5,6 +5,5 @@ usr/share/applications usr/share/dbus-1/services usr/share/glib-2.0/schemas usr/lib/nautilus/extensions-3.0/libterminal-nautilus.so -usr/share/gnome-shell/search-providers/gnome-terminal-search-provider.ini debian/gnome-terminal.wrapper /usr/bin --- /dev/null +++ b/debian/gnome-terminal.install.linux @@ -0,0 +1,10 @@ +usr/bin +usr/lib/gnome-terminal +usr/share/appdata +usr/share/applications +usr/share/dbus-1/services +usr/share/glib-2.0/schemas +usr/lib/nautilus/extensions-3.0/libterminal-nautilus.so +usr/share/gnome-shell/search-providers/gnome-terminal-search-provider.ini + +debian/gnome-terminal.wrapper /usr/bin
Bug#750064: eom: please use the default libjpeg
Source: eom Version: 1.8.0+dfsg1-2 Severity: normal Tags: patch Hi, currently eom build depends on libjpeg62-dev, which is not the default libjpeg used by basically all the rest of the Debian archive. eom seems to build fine with the default libjpeg (libjpeg v8 currently), so please make use of it. Patch attached. Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -23,7 +23,7 @@ Build-Depends: cdbs, libexif-dev, liblcms-dev, libexempi-dev, - libjpeg62-dev, + libjpeg-dev, libdbus-glib-1-dev, libxml2-dev, x11proto-core-dev,
Bug#750065: eom: enable the lcms support
Source: eom Version: 1.8.0+dfsg1-2 Severity: wishlist Tags: patch Hi, while looking at #750064, I noticed the lcms support is not enabled, even though there is the liblcms-dev build dependency. The reason is that eom actually wants lcms2, so switching that B-D to liblcms2-dev enables the lcms support. Patch attached for it (although I only build-tested it, I'm not actually a eom user). (Also, there is a plan to remove lcms1 from the archive before Jessie, see also https://lists.debian.org/debian-devel/2013/12/msg00570.html) Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -21,7 +21,7 @@ Build-Depends: cdbs, shared-mime-info, zlib1g-dev, libexif-dev, - liblcms-dev, + liblcms2-dev, libexempi-dev, libjpeg62-dev, libdbus-glib-1-dev,
Bug#750066: ecere-sdk: please use the default libjpeg
Source: ecere-sdk Version: 0.44.09.9-1 Severity: normal Tags: patch Hi, currently ecere-sdk build depends on libjpeg62-dev, which is not the default libjpeg used by basically all the rest of the Debian archive. ecere-sdk seems to build fine with the default libjpeg (libjpeg v8 currently), so please make use of it. Patch attached. Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -11,7 +11,7 @@ Build-Depends: debhelper (>= 9~), libgif-dev, libgl1-mesa-dev, libgl1-mesa-glx, - libjpeg62-dev, + libjpeg-dev, libncurses5-dev, libpng12-dev, libsqlite3-dev,
Bug#750068: ecere-sdk: Please Build-Depends on libpng-dev, change from libpng12-dev
Source: ecere-sdk Version: 0.44.09.9-1 Severity: important Tags: patch User: lib...@packages.debian.org Usertags: libpng15-transition Hi, currently ecere-sdk build depends on libpng12-dev, which means it will always build with libpng 1.2. The png maintainers plan [1] to switch to a newer libpng in the future, so it should be better to build depend on libpng-dev (which represents the default libpng version used in Debian). Patch attached for it. [1] https://bugs.debian.org/650601 Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -13,7 +13,7 @@ Build-Depends: debhelper (>= 9~), libgl1-mesa-glx, libjpeg62-dev, libncurses5-dev, - libpng12-dev, + libpng-dev, libsqlite3-dev, libx11-dev, libxext-dev,
Bug#750424: cups-pk-helper: FTBFS on hurd-i386
forwarded 750424 https://bugs.freedesktop.org/show_bug.cgi?id=59263 thanks Note this has been already reported upstream for quite some months. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750654: gimp: please enable parallel building
Source: gimp Version: 2.8.10-1 Severity: wishlist Tags: patch Hi, gimp seems to build fine with multiple build jobs when building. Thus, my suggestion is to enable the parallel build (enabling it in CDBS) to speed up the compilation when requested (see also Policy §4.9.1). Thanks, -- Pino --- a/debian/rules +++ b/debian/rules @@ -23,6 +23,7 @@ DEB_CONFIGURE_EXTRA_FLAGS := --disable-s --with-lcms=lcms2 \ --without-webkit DEB_BUILDDIR := $(DEB_SRCDIR)/builddir +DEB_BUILD_PARALLEL := 1 DEB_DH_SHLIBDEPS_ARGS_ALL := -Llibgimp2.0 -l$(CURDIR)/debian/libgimp2.0/usr/lib # exclude this since we manually add the Suggests in debian/control:
Bug#743596: gimp still built with lcms1
found 743596 tag 743596 + patch thanks Hi, adding the liblcms2-dev build dependency is not enough to have gimp build with it; libmng-dev has liblcms-dev as dependency, and configure checks for lcms1 first when no specific version is specified. Thus, the additional fix needed is to pass --with-lcms=lcms2 as configure argument; patch attached for it. Thanks, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751194: texmaker: please enable parallel building
Source: texmaker Version: 4.2-1 Severity: wishlist Tags: patch texmaker seems to build fine with multiple build jobs when building. Thus, my suggestion is to enable the parallel build (with the --parallel option of dh) to speed up the compilation when requested (see also Policy §4.9.1). Thanks, -- Pino --- a/debian/rules +++ b/debian/rules @@ -6,7 +6,7 @@ pkg=texmaker data=$(pkg)-data %: - dh $@ + dh $@ --parallel override_dh_auto_clean: [ ! -f Makefile ] || $(MAKE) distclean
Bug#751196: cups-filters: please enable parallel building
Source: cups-filters Version: 1.0.54-1 Severity: normal Tags: patch Hi, cups-filters seems to build fine with multiple build jobs when building. Thus, my suggestion is to enable the parallel build (with the --parallel option of dh) to speed up the compilation when requested (see also Policy §4.9.1). Thanks, -- Pino --- a/debian/rules +++ b/debian/rules @@ -5,7 +5,7 @@ derives_from_ubuntu := $(shell (dpkg-ven export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed %: - dh $@ --with autoreconf,systemd + dh $@ --parallel --with autoreconf,systemd override_dh_auto_configure: dh_auto_configure -- \
Bug#751217: gambas3: please enable parallel building
Source: gambas3 Version: 3.5.2-2 Severity: wishlist Tags: patch Hi, gambas3 seems to build fine with multiple build jobs when building. Thus, my suggestion is to enable the parallel build (reading the number of jobs from DEB_BUILD_OPTIONS, and adding it to the make invocation) to speed up the build when requested (see also Policy §4.9.1). Thanks, -- Pino --- a/debian/rules +++ b/debian/rules @@ -6,6 +6,10 @@ CFLAGS:=$(shell dpkg-buildflags --get CF CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS) LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS) +ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) +NJOBS := -j $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) +endif + configure: dh_autoreconf @@ -24,7 +28,7 @@ build-indep: build-stamp build-stamp: config.status dh_testdir - $(MAKE) prefix=$(CURDIR)/debian/tmp/usr + $(MAKE) $(NJOBS) prefix=$(CURDIR)/debian/tmp/usr touch build-stamp clean:
Bug#751335: gnome-main-menu: unbuildable on !linux archs
Source: gnome-main-menu Version: 1.8.0-1 Severity: important Tags: patch Hi, currently gnome-main-menu cannot be built on non-Linux architectures, because of few Linux-specific build dependencies. Since the features they enable are optional, those build dependencies can be safely restricted as linux-only. Patch attached for it. Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -19,10 +19,10 @@ Build-Depends: debhelper (>= 9), libxml2-dev, libcairo2-dev, libx11-dev, - network-manager-dev, - libnm-glib-dev, - libnm-util-dev, - libiw-dev, + network-manager-dev [linux-any], + libnm-glib-dev [linux-any], + libnm-util-dev [linux-any], + libiw-dev [linux-any], libmate-slab-dev, mate-common, libdconf-dev,
Bug#751432: gdcm: compatibility with poppler 0.26.x
Source: gdcm
Version: 2.4.2-1
Severity: normal
Tags: patch fixed-upstream
Control: forwarded -1 http://sourceforge.net/p/gdcm/bugs/312/
Hi,
gdcm 2.4.2-1 fails to build with Poppler 0.26.x (currently in
experimental).
The issue has been reported [1] and fixed upstream (for gdcm 2.4.3);
in the meanwhile, would it be possible to backport the two upstream
patches (which apply cleanly) for compatibility with Poppler 0.26.x?
[1] http://sourceforge.net/p/gdcm/bugs/312/
Thanks,
--
Pino
>From 096e5b84d9e241b6e5203904846454f7d7058e01 Mon Sep 17 00:00:00 2001
From: Pino Toscano
Date: Sun, 6 Apr 2014 06:20:43 +
Subject: [PATCH] cmake: proper handle the extra poppler CFLAGS
Make sure to join the extra CFLAGS with a space, otherwise they are
passed as list to set_source_files_properties; also make sure to quote
the string.
---
Applications/Cxx/CMakeLists.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Applications/Cxx/CMakeLists.txt b/Applications/Cxx/CMakeLists.txt
index 1c83bc3..714f5bc 100644
--- a/Applications/Cxx/CMakeLists.txt
+++ b/Applications/Cxx/CMakeLists.txt
@@ -79,12 +79,13 @@ if(GDCM_USE_SYSTEM_POPPLER)
list(APPEND libpoppler_flags -DLIBPOPPLER_PDFDOC_HAS_PDFVERSION)
endif()
if(libpoppler_flags)
+string(REPLACE ";" " " libpoppler_flags_string "${libpoppler_flags}")
set_source_files_properties(
${CMAKE_CURRENT_SOURCE_DIR}/gdcminfo.cxx
- PROPERTIES COMPILE_FLAGS ${libpoppler_flags})
+ PROPERTIES COMPILE_FLAGS "${libpoppler_flags_string}")
set_source_files_properties(
${CMAKE_CURRENT_SOURCE_DIR}/gdcmpdf.cxx
- PROPERTIES COMPILE_FLAGS ${libpoppler_flags})
+ PROPERTIES COMPILE_FLAGS "${libpoppler_flags_string}")
endif()
include_directories(${POPPLER_INCLUDE_DIRS})
set(GDCM_EXECUTABLE_NAME
--
2.0.0
>From 1da0cab121782f1a63a84a9bcc90da6c337dc2e3 Mon Sep 17 00:00:00 2001
From: Pino Toscano
Date: Sun, 6 Apr 2014 06:23:46 +
Subject: [PATCH] gdcminfo: support poppler 0.25.1
Check for the new API of StructTreeRoot, adapting the check for a
tagged PDF accordingly. Now Catalog::getStructTreeRoot() returns NULL
if StructTreeRoot is not a dictionary.
---
Applications/Cxx/CMakeLists.txt | 6 ++
Applications/Cxx/gdcminfo.cxx | 4
2 files changed, 10 insertions(+)
diff --git a/Applications/Cxx/CMakeLists.txt b/Applications/Cxx/CMakeLists.txt
index 714f5bc..9b4dd0e 100644
--- a/Applications/Cxx/CMakeLists.txt
+++ b/Applications/Cxx/CMakeLists.txt
@@ -78,6 +78,12 @@ if(GDCM_USE_SYSTEM_POPPLER)
if(LIBPOPPLER_PDFDOC_HAS_PDFVERSION)
list(APPEND libpoppler_flags -DLIBPOPPLER_PDFDOC_HAS_PDFVERSION)
endif()
+ CHECK_CXX_SOURCE_COMPILES(
+"\#include \n#include \nint main() { Catalog c(NULL); c.getStructTreeRoot()->getDoc(); return 0;}"
+LIBPOPPLER_CATALOG_HAS_STRUCTTREEROOT)
+ if(LIBPOPPLER_CATALOG_HAS_STRUCTTREEROOT)
+list(APPEND libpoppler_flags -DLIBPOPPLER_CATALOG_HAS_STRUCTTREEROOT)
+ endif()
if(libpoppler_flags)
string(REPLACE ";" " " libpoppler_flags_string "${libpoppler_flags}")
set_source_files_properties(
diff --git a/Applications/Cxx/gdcminfo.cxx b/Applications/Cxx/gdcminfo.cxx
index 6f52cd9..9288ea6 100644
--- a/Applications/Cxx/gdcminfo.cxx
+++ b/Applications/Cxx/gdcminfo.cxx
@@ -471,7 +471,11 @@ static int ProcessOneFile( std::string const & filename, gdcm::Defs const & defs
moddate = getInfoDate( info.getDict(), "ModDate" );
info.free();
}
+#ifdef LIBPOPPLER_CATALOG_HAS_STRUCTTREEROOT
+ const char *tagged = doc->getStructTreeRoot() ? "yes" : "no";
+#else
const char *tagged = doc->getStructTreeRoot()->isDict() ? "yes" : "no";
+#endif
int pages = doc->getNumPages();
const char *encrypted = doc->isEncrypted() ? "yes" : "no";
// printf("yes (print:%s copy:%s change:%s addNotes:%s)\n",
--
2.0.0
Bug#751525: transition: poppler 0.26
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 751432 Hi, I would like to ask a slot for a Poppler 0.26.x transition. Currently there is Poppler 0.26.1 in experimental already. This transition impacts the existing poppler libraries in the following ways: - libpoppler44 → libpoppler46 - libpoppler-glib8 -- BC with 0.24 (with few new symbols) - libpoppler-qt4-4 -- BC with 0.24 (with one new symbol) - libpoppler-qt5-1 -- BC with 0.24 (with one new symbol) Below it is a list of sources which are touched by the transition, and their situation, sorted by solutions: Sources that compile fine, and can be binNMU'ed: calligra cups-filters gambas3 gdal inkscape libreoffice pdf2djvu pdftoipe popplerkit.framework texlive-bin texworks (has a spurious dependency on libpoppler, handling it upstream and then to Debian) xpdf Sources that currently FTBFS: * gdcm Compatibility with Poppler 0.26.x fixed upstream, asked to backport the patches in #751432. Other cases: * derivations This source builds a libpoppler-based utility application which is only used during the build to generate other data, and no trace of that application are left in the resulting arch:all package. I grouped all the bugs mentioned above (even the solved ones) with the following usertag: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.26 A ben tracker for poppler would have: title = "poppler 0.26"; is_affected = .build-depends ~ "libpoppler-private-dev" | .source ~ /texworks/; is_good = .depends ~ "libpoppler46"; is_bad = .depends ~ "libpoppler44"; Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751533: pdfgrep: extra libpoppler-private-dev build dependency
Source: pdfgrep Version: 1.3.0-1 Severity: wishlist Tags: patch Hi, pdfgrep uses poppler-cpp, so the libpoppler-private-dev build dependency seems redundant; pdfgrep builds fine without it. Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -4,7 +4,6 @@ Priority: optional Maintainer: Christoph Egger Build-Depends: debhelper (>= 7.0.50~), automake, - libpoppler-private-dev, libpoppler-cpp-dev, pkg-config Standards-Version: 3.9.1
Bug#747577: blender: obsolete libtiff4 suggest
Package: blender Version: 2.69-4 Severity: minor Control: found -1 blender/2.70-1 Hi, blender suggests libtiff4, which is the old TIFF library. Furthermore, blender already links to libtiff, so suggesting to install manually the library is of no use. Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747716: Fwd: KDbg should be upgraded to latest version to work with latest GDB
reassign 747716 qttools5-dev-tools qttools-opensource-src/5.2.1-8 thanks On 2014-05-11 13:05, Shriramana Sharma wrote: Package: qttools-opensource-src Version: 5.2.1-8build1 I am using Kubuntu Trusty 64 bit. Since the relevant package is not modified downstream for Ubuntu, I am reporting this bug against Debian. Then please at least use a package and version number that exist in Debian... https://packages.debian.org/sid/qttools5-dev-tools shows that libqt5sql5-sqlite is only a "Recommends". However, without installing the latter, I am not able to run Qt 5 Assistant at all: $ assistant -qt=5 QSqlDatabase: QSQLITE driver not loaded QSqlDatabase: available drivers: Error reading collection file '/home/samjnaa/.local/share/QtProject/Assistant/qthelpcollection_5.2.1.qhc': Cannot load sqlite database driver!. Installing the libqt5sql5-sqlite package allows Qt 5 Assistant to load. Apparently this is a hard dependency which is mistakenly labeled as a Recommends. Please fix this. No, it has not been "mistakenly" marked as recommend: assistant is not the only tool on qttools5-dev-tools, and it is the only one requiring libqt5sql5-sqlite. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748379: xine-lib-1.2: FTBFS on hurd-i386: missing libva-dev build dependency
Source: xine-lib-1.2 Version: 1.2.4-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, since the upload of 1.2.4-1, xine-lib-1.2 cannot be built on hurd-i386. Because of missing libdrm, libva (and thus libva-dev) is not available on hurd-i386. Easy solution is to exclude the libva-dev build dependency on hurd. (P.S.: the "!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386" architecture restrictions in a couple of other build dependencies could be turned into "linux-any", which is simplier and more logic.) Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -6,7 +6,7 @@ Uploaders: Reinhard Tartler = 5.0.1), binutils (>= 2.12.90.0.9), pkg-config, dh-autoreconf, libavcodec-dev (>= 4:0.7~), libavformat-dev (>= 4:0.7~), libpostproc-dev (>= 4:0.7~), - libvdpau-dev, libva-dev, libvpx-dev, + libvdpau-dev, libva-dev [!hurd-any], libvpx-dev, libxcb-xv0-dev, libxcb-shm0-dev, libxcb-shape0-dev, libxinerama-dev, libxv-dev, libxvmc-dev, libxt-dev, libasound2-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386],
Bug#747716: closed by Lisandro Damián Nicanor Pérez Meyer (Not a bug)
On 2014-05-18 06:46, Shriramana Sharma wrote: Hello and thanks for your kind words while closing the bug. As you may have noticed I tried to elicit community opinion on debian-user, but there weren't many responses -- just two, one for and one against. So I guess it's going to be as it is. https://lists.debian.org/debian-user/2014/05/msg00783.html Quoting from your email: | I am posting this here since the developers seem to just disagree with | my point without providing any policy-based/logical reason. And many thanks for having completely disregarded anything Scott and me said in this bug. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747716: closed by Lisandro Damián Nicanor Pérez Meyer (Not a bug)
On 2014-05-18 08:44, Shriramana Sharma wrote: I haven't disregarded anything you/Scott said. I specifically mentioned in that thread that "developers say such-and-such". Didn't you notice that? I suppose I have the freedom to disagree with your opinion and try to elicit community opinion. That is what I did. Yes, I noticed you reported what we said. However, you also said that was we "just disagreed with yout point without providing any policy-based/logical reason". That pretty much dismisses the value of what we said, classifying it as illogic and based on personal whims. I voiced my opinion as a user, didn't get overmuch support for it from other users, and gave in to the developers' opinion then. I suppose that's a good democratic process. Going to users for opinion and presenting ours as "they said this, but it's based on nothing" is not exactly... a fair point of view. I understand you might have wanted (implicitly or explicitly) to get the user base to stand on your side, although I'd not call it as "good democratic process". Please don't be sarcastic when someone is just trying to improve the Debian packaging or documentation by submitting/voicing their opinion or trying to mobilize community opinion. Lisandro was nice enough to say "Even if we might disagree is good to have feedback from our users." I suppose you can be polite like that too. Note that I won't continue further in this, since I wanted to point out how your wording toward our opinion has not been exactly constructive. Sure, I overreacted with sarcasm, which you can understand a bit since reading the last past of your email on debian-user@ has not been exactly a good morning read. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742335: mesa: extra libegl1-mesa-drivers dependency & recommend on Hurd
Source: mesa
Version: 10.1.0-4
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hi,
thanks for the various egl/gles fixes (#729260, #741572, and the other
packaging commits) on Hurd!
The only left issue is that libegl1-mesa-dev depends on
libegl1-mesa-drivers, which is not built on Hurd (and libegl1-mesa
recommends it).
Attached there is a simple patch to remove such dependency and recommend
on hurd-any, which should make libegl1-mesa-dev finally installable.
Thanks,
--
Pino
--- a/debian/control
+++ b/debian/control
@@ -252,7 +252,7 @@ Architecture: any
Depends:
${shlibs:Depends},
${misc:Depends},
-Recommends: libegl1-mesa-drivers
+Recommends: libegl1-mesa-drivers [!hurd-any]
Provides: libegl1-x11
Conflicts: libegl1-x11
Replaces: libegl1-x11
@@ -287,7 +287,7 @@ Section: libdevel
Architecture: any
Depends:
libegl1-mesa (= ${binary:Version}),
- libegl1-mesa-drivers (= ${binary:Version}),
+ libegl1-mesa-drivers (= ${binary:Version}) [!hurd-any],
libdrm-dev (>= 2.4.52) [!hurd-any],
x11proto-dri2-dev (>= 2.6),
x11proto-gl-dev (>= 1.4.14),
Bug#669278: Processed: found 619244 in 44-8, found 677805 in sid/None, found 669278 in sid/None, found 646837 in sid/None ...
Alle domenica 20 gennaio 2013, Andreas Beckmann ha scritto: > On 2013-01-20 18:46, Pino Toscano wrote: > > Alle domenica 20 gennaio 2013, Debian Bug Tracking System ha scritto: > >> Marked as found in versions sid/None. > > > > sid/None??? What's this? > > A "magic version number" that is used by piuparts-analyze to classify > some of the packages affected by this bug and move the failing logs > away as "bugged" so that my attention goes to the important things. > > > Also, what's the use of adding versions of other sources to (what > > is now) a phonon bug? Would it be possible to not add them, since > > otherwise you would end up adding all the phonon-dependent sources > > (directly or indirectly, like most of the kde applications)? > > See http://bugs.debian.org/669278#154 To be honest the sid/None and the reply above sound like a slight abuse of the version of bugs: this bug is not *in* konversation/digikam/kopetec/etc, and adding their version to this bug does not sound appropriate. If piuparts needs markers in bugs, please make it use own usertags. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#648649: qdbm: please support nocheck in DEB_BUILD_OPTIONS
Package: qdbm Version: 1.8.78-1 Severity: wishlist Tags: patch Hi, could it be possible to support nocheck in DEB_BUILD_OPTIONS, as also recommended in §4.9.1 of Policy? Attached there is a patch for it (can be improved/changed/etc at will, of course). Thanks, -- Pino --- a/debian/rules +++ b/debian/rules @@ -33,6 +33,12 @@ CFLAGS += -O2 endif +ifneq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) + WITH_TESTS = +else + WITH_TESTS = y +endif + CONFIGURE_VARS = CFLAGS="$(CFLAGS)" CPPFLAGS="" CONFIGURE_SWITCHES = --host=$(DEB_HOST_GNU_TYPE) \ --build=$(DEB_BUILD_GNU_TYPE) \ @@ -64,23 +70,38 @@ autoconf mkdir with-gdbm && cp qdbm.* *ake* config* *.c *.h with-gdbm/ $(CONFIGURE_VARS) ./configure $(CONFIGURE_SWITCHES) --disable-gdbm - $(MAKE) && $(MAKE) check + $(MAKE) +ifneq "$(WITH_TESTS)" "" + $(MAKE) check +endif #cd with-gdbm && $(CONFIGURE_VARS) ./configure $(CONFIGURE_SWITCHES) #cd with-gdbm && $(MAKE) && $(MAKE) check cd cgi && $(CONFIGURE_VARS) ./configure $(CONFIGURE_SWITCHES) cd cgi && $(MAKE) cd plus && $(CONFIGURE_VARS) ./configure $(CONFIGURE_SWITCHES) - cd plus && $(MAKE) && $(MAKE) check + cd plus && $(MAKE) +ifneq "$(WITH_TESTS)" "" + cd plus && $(MAKE) check +endif cd perl && $(CONFIGURE_VARS) ./configure $(CONFIGURE_SWITCHES) - cd perl && $(MAKE) && $(MAKE) check + cd perl && $(MAKE) +ifneq "$(WITH_TESTS)" "" + cd perl && $(MAKE) check +endif touch build-stamp build-ruby-stamp: build-stamp cp -pR ruby ruby19 && \ cd ruby && $(CONFIGURE_VARS) ./configure $(CONFIGURE_SWITCHES) - export RUBY=/usr/bin/ruby1.8 && cd ruby && $(MAKE) && $(MAKE) check + export RUBY=/usr/bin/ruby1.8 && cd ruby && $(MAKE) +ifneq "$(WITH_TESTS)" "" + export RUBY=/usr/bin/ruby1.8 && cd ruby && $(MAKE) check +endif cd ruby19 && $(CONFIGURE_VARS) ./configure $(CONFIGURE_SWITCHES) - export RUBY=/usr/bin/ruby1.9.1 && cd ruby19 && $(MAKE) && $(MAKE) check + export RUBY=/usr/bin/ruby1.9.1 && cd ruby19 && $(MAKE) +ifneq "$(WITH_TESTS)" "" + export RUBY=/usr/bin/ruby1.9.1 && cd ruby19 && $(MAKE) check +endif touch build-ruby-stamp build-java-stamp: build-stamp
Bug#648663: qdbm: FTBFS on hurd-i386: failure on unimplemented msync()
Package: qdbm
Version: 1.8.78-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hi,
currently[1], qdbm fails to build on GNU/Hurd.
The problem is due to the fact that the msync() POSIX function is not
implemented on Hurd yet, thus returns -1 and sets ENOSYS as errno.
On the other hand, even without it qdbm seems to work fine on Hurd,
and the various tests succeed with the attached patch (which ignores
msync() failures when errno is ENOSYS).
I'm not sure whether the patch could be suitable for upstream though,
although it can work for the Debian packaging (and it won't need any
change when msync() is implemented).
[1]
https://buildd.debian.org/status/fetch.php?pkg=qdbm&arch=hurd-i386&ver=1.8.78-1&stamp=1321148107
Thanks,
--
Pino
--- a/depot.c
+++ b/depot.c
@@ -19,6 +19,8 @@
#include "depot.h"
#include "myconf.h"
+#include
+
#define DP_FILEMODE00644 /* permission of a creating file */
#define DP_MAGICNUMB "[DEPOT]\n\f" /* magic number on environments of big endian */
#define DP_MAGICNUML "[depot]\n\f" /* magic number on environments of little endian */
@@ -761,7 +763,7 @@
}
*((int *)(depot->map + DP_FSIZOFF)) = depot->fsiz;
*((int *)(depot->map + DP_RNUMOFF)) = depot->rnum;
- if(msync(depot->map, depot->msiz, MS_SYNC) == -1){
+ if(msync(depot->map, depot->msiz, MS_SYNC) == -1 && errno != ENOSYS){
dpecodeset(DP_EMAP, __FILE__, __LINE__);
depot->fatal = TRUE;
return FALSE;
@@ -1473,7 +1475,7 @@
}
*((int *)(depot->map + DP_FSIZOFF)) = depot->fsiz;
*((int *)(depot->map + DP_RNUMOFF)) = depot->rnum;
- if(msync(depot->map, depot->msiz, MS_SYNC) == -1){
+ if(msync(depot->map, depot->msiz, MS_SYNC) == -1 && errno != ENOSYS){
dpecodeset(DP_EMAP, __FILE__, __LINE__);
depot->fatal = TRUE;
return FALSE;
Bug#648987: syslog-ng: FTBFS on hurd-i386
Alle mercoledì 16 novembre 2011, Svante Signell ha scritto: > The attached patch fixes the FTBFS problems of syslog-ng on GNU/Hurd. > Since IOV_MAX is not defined on Hurd its usage is made conditional. > [...] > +#ifndef __GNU__ >if (flush_lines > IOV_MAX) > /* limit the flush_lines according to the current platform */ > flush_lines = IOV_MAX; > +#endif conditional yes, but on the IOV_MAX definition, not on a per-OS check. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#649192: webkit: FTBFS on hurd-i386
Source: webkit
Version: 1.6.1-5
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hi,
currently[1], webkit fails to build on GNU/Hurd.
The problem is due to the missing PTHREAD_KEYS_MAX definition (which is
optional in POSIX, though).
The attached patch does two things:
- Source/JavaScriptCore/wtf/Platform.h
defines WTF_OS_HURD in hopefully a suitable way for upstream;
it would be nice if you could send it upstream (so I don't need to
patch also the various webkit copies for it).
- Source/JavaScriptCore/wtf/ThreadIdentifierDataPthreads.cpp
adds a band-aid fix fix for the lack of PTHREAD_KEYS_MAX definition,
with a value which should not cause issues;
this part should not go upstream but stay locally in Debian for now,
as it will need either a better fix in webkit or a fix in
glibc/libpthread for Hurd.
[1]
https://buildd.debian.org/status/fetch.php?pkg=webkit&arch=hurd-i386&ver=1.6.1-5&stamp=1320390923
Thanks,
--
Pino
--- a/Source/JavaScriptCore/wtf/Platform.h
+++ b/Source/JavaScriptCore/wtf/Platform.h
@@ -352,6 +352,11 @@
#define WTF_OS_HAIKU 1
#endif
+/* OS(HURD) - GNU/Hurd */
+#ifdef __GNU__
+#define WTF_OS_HURD 1
+#endif
+
/* OS(LINUX) - Linux */
#ifdef __linux__
#define WTF_OS_LINUX 1
@@ -398,6 +403,7 @@
|| OS(DARWIN) \
|| OS(FREEBSD) \
|| OS(HAIKU)\
+|| OS(HURD) \
|| OS(LINUX)\
|| OS(NETBSD) \
|| OS(OPENBSD) \
--- a/Source/JavaScriptCore/wtf/ThreadIdentifierDataPthreads.cpp
+++ b/Source/JavaScriptCore/wtf/ThreadIdentifierDataPthreads.cpp
@@ -41,6 +41,9 @@
#define PTHREAD_KEYS_MAX 1024
#else
#include
+#if OS(HURD)
+#define PTHREAD_KEYS_MAX INT_MAX
+#endif
#endif
namespace WTF {
Bug#697011: unblock: filelight/4:4.8.4-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package filelight. The upload just improves/fixes the information in copyright. unblock filelight/4:4.8.4-2 Thanks, -- Pino diff -Nru filelight-4.8.4/debian/changelog filelight-4.8.4/debian/changelog --- filelight-4.8.4/debian/changelog 2012-06-20 00:18:44.0 +0200 +++ filelight-4.8.4/debian/changelog 2012-12-30 20:16:27.0 +0100 @@ -1,3 +1,10 @@ +filelight (4:4.8.4-2) unstable; urgency=low + + * Team upload. + * copyright: fix/improve information. + + -- Pino Toscano Sun, 30 Dec 2012 20:16:15 +0100 + filelight (4:4.8.4-1) unstable; urgency=low * Team upload. diff -Nru filelight-4.8.4/debian/copyright filelight-4.8.4/debian/copyright --- filelight-4.8.4/debian/copyright 2012-06-20 00:10:11.0 +0200 +++ filelight-4.8.4/debian/copyright 2012-12-30 19:33:28.0 +0100 @@ -10,12 +10,16 @@ Files: doc/* Copyright: 2003-2004, Max Howell 2008-2009 Martin Sandsmark -License: GFDL-NIV-1.2 +License: GFDL-NIV-1.2+ Files: debian/* Copyright: 2012, Eshat Cakar License: GPL-2+ +License: GPL-2+ + On Debian systems, the complete text of the GNU General Public License + version 2 can be found in `/usr/share/common-licenses/GPL-2'. + License: GPL-2+ or GPL-3+ with KDE e.V. exception This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as @@ -33,32 +37,15 @@ You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. . - On Debian systems, the full text of the GNU General Public - License version 2 can be found in the file + On Debian systems, the full text of the GNU General Public License + versions 2 and 3 can be found in `/usr/share/common-licenses/GPL-2' and `/usr/share/common-licenses/GPL-3'. -License: GFDL-NIV-1.2 - The purpose of this License is to make a manual, textbook, or other - functional and useful document "free" in the sense of freedom: to - assure everyone the effective freedom to copy and redistribute it, - with or without modifying it, either commercially or noncommercially. - Secondarily, this License preserves for the author and publisher a way - to get credit for their work, while not being considered responsible - for modifications made by others. - . - This License is a kind of "copyleft", which means that derivative - works of the document must themselves be free in the same sense. It - complements the GNU General Public License, which is a copyleft - license designed for free software. - . - We have designed this License in order to use it for manuals for free - software, because free software needs free documentation: a free - program should come with manuals providing the same freedoms that the - software does. But this License is not limited to software manuals; - it can be used for any textual work, regardless of subject matter or - whether it is published as a printed book. We recommend this License - principally for works whose purpose is instruction or reference. +License: GFDL-NIV-1.2+ + Permission is granted to copy, distribute and/or modify this document under + the terms of the GNU Free Documentation License, Version 1.2 or any later + version published by the Free Software Foundation; with no Invariant + Sections, no Front-Cover Texts, and no Back-Cover Texts. . - On Debian systems, the full text of the GNU General Public - License version 2 can be found in the file - `/usr/share/common-licenses/GFDL-1.2'. \ No newline at end of file + On Debian systems, the complete text of the GNU Free Documentation License + version 1.2 can be found in `/usr/share/common-licenses/GFDL-1.2'.
Bug#695160: unblock (pre-approval): akonadi/1.7.2-2
Alle lunedì 10 dicembre 2012, Julien Cristau ha scritto: > On Thu, Dec 6, 2012 at 16:22:55 +0100, Pino Toscano wrote: > > Alle mercoledì 5 dicembre 2012, Julien Cristau ha scritto: > > > On Tue, Dec 4, 2012 at 20:09:38 +0100, Pino Toscano wrote: > > > > Package: release.debian.org > > > > Severity: normal > > > > User: release.debian@packages.debian.org > > > > Usertags: unblock > > > > > > > > Hi, > > > > > > > > I would like to upload akonadi 1.7.2-2. > > > > The only change is a fix in the provided README.Debian, to > > > > actually match the configuration format. > > > > > > You don't really need pre-approval for trivial changes... > > > > OK, uploaded and built everywhere. > > Unblocked. For whatever reason it's stuck behind qt4-x11, though. It has not been actually unblocked... -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#697766: poppler feeds invalid UTF-8 to cairo
forwarded 697766 https://bugs.freedesktop.org/show_bug.cgi?id=53925 tag 697766 + fixed-upstream thanks Hi, thanks for your report. Alle mercoledì 9 gennaio 2013, Eric Marsden ha scritto: > Package: libpoppler28 > Version: 0.20.5-1 > > When attempting to print certain PDF files generated by luatex, > evince fails with multiple errors > >BAD status: input string not valid UTF-8 >Internal Error: cairo context error: input string not valid UTF-8 > > This is a known bug in poppler > > https://bugs.freedesktop.org/show_bug.cgi?id=53925 Thanks, added a reference to it to this bug. > It would be great to have poppler 0.22 available in Debian. This won't happen before (in order): a) Wheezy is released b) all the packages in Debian using the private libpoppler are fixed to compile with 0.20 (currently in experimental) c) there is a transition to introduce poppler 0.20 in unstable d) poppler 0.20 migrates to testing (possibly 0.22 or whatever is the latest stable serie will be pushed to experimental right after c) is done) It takes already some time to have packages compiling (and possibly working) with a new version of the private libpoppler, and with 0.22 there will be few more failures with it. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
