Bug#1053670: libreoffice-gtk3: Color changes in Libreoffice Draw stopped working with libreoffice-gtk3 installed
Hi, Am 11.10.23 um 17:53 schrieb Rene Engelhard: tag 1053670 + unreproducible tag 1053670 + moreinfo thanks Hi, Am 08.10.23 um 15:08 schrieb Kerstin Hoef-Emden: Probably an update of libreoffice and its components. Probably? The last update of "libreoffice and its components" was for 12.1 in July. Actually I didn't use Libreoffice Draw for months, so I don't know when this bug appeared. I used Libreoffce Writer and it behaved normally. If it appeared recently I'd guess some library update... Maybe in 12.2? I wanted to prepare a single picture for a presentation with Libreoffice Draw and realized that changes of text color stopped working. Works here. Both in my normal system and in a clean stable VM. Also filled areas of e.g. circles did not show the chosen color. Instead all fillings appeared white, colored text remained black. Dito. Also I realized that input becomes extremely slow, with libreoffice-gtk3 installed. The fan of my cpu speeds up and letters appear with a long delay while typing in. That suggests some graphics driver issue? Did something get updated with that? I've got a Radeon Lexa Pro RX550. Package firmware-amd-graphics 20210315-3 is installed. Driver in use is amdgpu. Best wishes, Kerstin * What exactly did you do (or not do) that was effective (or ineffective)? I purged libreoffice with "apt purge libreoffice*" from the system and reinstalled it. Thereafter the problem was gone, but the windows and menus had tiny hardly readable text and low contrast due to a gray background. Well, yes, that's how LO looks without Gtk3 integration. Regards, Rene
Bug#1053670: libreoffice-gtk3: Color changes in Libreoffice Draw stopped working with libreoffice-gtk3 installed
Package: libreoffice-gtk3 Version: 4:7.4.7-1 Severity: important Dear Maintainer, * What led up to the situation? Probably an update of libreoffice and its components. I wanted to prepare a single picture for a presentation with Libreoffice Draw and realized that changes of text color stopped working. Also filled areas of e.g. circles did not show the chosen color. Instead all fillings appeared white, colored text remained black. When scaling the circle or a text box, the color becomes visible, but after stopping the action, white filling or black text was shown again. These effects concern only the display on screen. In printouts the colors are present. In Libreoffice Writer changing the color of texts worked, but it also does not work in Libreoffice Impress. Also I realized that input becomes extremely slow, with libreoffice-gtk3 installed. The fan of my cpu speeds up and letters appear with a long delay while typing in. * What exactly did you do (or not do) that was effective (or ineffective)? I purged libreoffice with "apt purge libreoffice*" from the system and reinstalled it. Thereafter the problem was gone, but the windows and menus had tiny hardly readable text and low contrast due to a gray background. By internet search I found the proposal to install libreoffice-gtk3 to solve this problem. It resulted in readable menus with better contrast, i.e. it looked like the Libreoffice that I had purged from the system before, but the color problem returned. Deinstallation of libreoffice-gtk3 solved the problem, but now the surface of Libreoffice again is hardly readable. * What was the outcome of this action? * What outcome did you expect instead? For sure, that coloring of rectangle or circle areas works again as well as choosing a color for text different than black. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libreoffice-gtk3 depends on: ii libatk1.0-0 2.46.0-5 ii libc62.36-9+deb12u3 ii libcairo21.16.0-7 ii libepoxy01.5.10-1 ii libgcc-s112.2.0-14 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libgtk-3-0 3.24.38-2~deb12u1 ii libpango-1.0-0 1.50.12+ds-1 ii libreoffice-core 4:7.4.7-1 ii libstdc++6 12.2.0-14 ii libuno-cppu3 4:7.4.7-1 ii libuno-cppuhelpergcc3-3 4:7.4.7-1 ii libuno-sal3 4:7.4.7-1 ii libx11-6 2:1.8.4-2+deb12u2 ii uno-libs-private 4:7.4.7-1 Versions of packages libreoffice-gtk3 recommends: ii gstreamer1.0-gtk3 1.22.0-5+deb12u1 Versions of packages libreoffice-gtk3 suggests: pn libreofficekit-data -- no debconf information
Bug#1039983: cups: CMYK capable printer does not print in colour
Hi Brian, the lpadmin command did work. Regards, Kerstin Am 02.07.23 um 13:06 schrieb Brian Potkin: tags 1039983 upstream retitle 1039983 CMYK capable printer does not print in colour thanks On Fri 30 Jun 2023 at 17:56:08 +0200, Kerstin Hoef-Emden wrote: Package: cups Version: 2.4.2-3 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Upgrade from bullseye to bookworm * What exactly did you do (or not do) that was effective (or ineffective)? First of all, the printer drivers for my printer (Kyocera FS-C5250dn) were not anymore available in the printers list. The original Kyocera PPD files were still present in the file system. I chose them by browsing the file system. Although the printer was now identified as capable of doing CMYK and it was set to color in the cups browser interface. I also tried to change the setting in printer.conf a) by hand to printer-color-mode CMYK and I tried the command lpoptions -p Kyocera -o printer-colormode=CMYK. * What was the outcome of this action? It did not work, the printer still prints only Black & White and I am not able to change the setting in printer.conf. * What outcome did you expect instead? For sure I want my color printer to print color again. THank you for your report, Kerstin. Your issue sounds like the on at https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1971242 Does the lpadmin workaround do anything for you? Regards, Brian.
Bug#1039983: cups: Cannot change printer.conf to CMYK
Package: cups Version: 2.4.2-3 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Upgrade from bullseye to bookworm * What exactly did you do (or not do) that was effective (or ineffective)? First of all, the printer drivers for my printer (Kyocera FS-C5250dn) were not anymore available in the printers list. The original Kyocera PPD files were still present in the file system. I chose them by browsing the file system. Although the printer was now identified as capable of doing CMYK and it was set to color in the cups browser interface. I also tried to change the setting in printer.conf a) by hand to printer-color-mode CMYK and I tried the command lpoptions -p Kyocera -o printer-colormode=CMYK. * What was the outcome of this action? It did not work, the printer still prints only Black & White and I am not able to change the setting in printer.conf. * What outcome did you expect instead? For sure I want my color printer to print color again. *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups depends on: ii cups-client2.4.2-3 ii cups-common2.4.2-3 ii cups-core-drivers 2.4.2-3 ii cups-daemon2.4.2-3 ii cups-filters 1.28.17-3 ii cups-ppdc 2.4.2-3 ii cups-server-common 2.4.2-3 ii debconf [debconf-2.0] 1.5.82 ii ghostscript10.0.0~dfsg-11 ii libavahi-client3 0.8-10 ii libavahi-common3 0.8-10 ii libc6 2.36-9 ii libcups2 2.4.2-3 ii libgcc-s1 12.2.0-14 ii libstdc++6 12.2.0-14 ii libusb-1.0-0 2:1.0.26-1 ii poppler-utils 22.12.0-2+b1 ii procps 2:4.0.2-3 Versions of packages cups recommends: ii avahi-daemon 0.8-10 ii colord1.4.6-2.2 Versions of packages cups suggests: ii cups-bsd 2.4.2-3 pn cups-pdf pn foomatic-db-compressed-ppds | foomatic-db pn smbclient ii udev 252.6-1 -- debconf information: cupsys/raw-print: true cupsys/backend: lpd, socket, usb, snmp, dnssd Kyocera.ppd Description: application/vnd.cups-ppd # Printer configuration file for CUPS v2.4.2 # Written by cupsd # DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING NextPrinterId 2 PrinterId 1 UUID urn:uuid:80dbe96e-e1b1-33fd-69e1-dabf1d863644 Info Kyocera FS-C5250dn Location 192.168.1.6 MakeModel Kyocera FS-C5350DN (KPDL) DeviceURI socket://192.168.1.6 State Idle StateTime 1688140313 ConfigTime 1688140297 Type 8425564 Accepting Yes Shared Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 OpPolicy default ErrorPolicy retry-job Option print-color-mode monochrome Attribute marker-colors \#00,#FF00FF,#00,#00,none Attribute marker-levels 6,6,100,65,-1 Attribute marker-names TK-590C,TK-590M,TK-590Y,TK-590K,Waste Toner Box Attribute marker-types toner,toner,toner,toner,waste-toner Attribute marker-change-time 1688140313
Bug#1019054: [Pkg-phototools-devel] Bug#1019054: Bug#1019054: darktable: Darktable does not save Metadata in exported jpgs anymore, even author/copyright entries are gone!
Hi David, thank you very much. This did work! Best wishes, Kerstin Am 04.09.22 um 19:28 schrieb David Bremner: Kerstin Hoef-Emden writes: c) I opened the wheel and Voreinstellungen, went to the global settings of the meta data editor. It differed from the older darktable version in, that no percent symbols were visible (Metadaten-Editor_globale Einstallung.png). I can double-click on "Alle Rechte" and it offers a field to type something in. But apparently this is only to give a name ro a setting, rather than to change a setting. Those are the wrong settings. I agree it's a bit confusing, but click on the hamburger menu (≡) for the export, then choose preferences. On the left you will see a set of checkboxes, including metadata. Make sure the metadata one is selected (see attached). If that doesn't help, try deselecting "develop history". There was an old bug (which is supposed to be fixed) that caused metadata export to fail if the develop history stack got too big.
Bug#1019054: [Pkg-phototools-devel] Bug#1019054: darktable: Darktable does not save Metadata in exported jpgs anymore, even author/copyright entries are gone!
Hi David, Am 03.09.22 um 17:17 schrieb David Bremner: Kerstin Hoef-Emden writes: In oldstable, darktable saved all metadata upon export, even temperature of the camera body etc. I expect those data either not to be lost, so I can choose which ones to delete/maintain with help of exiftool or that the metadata editor offers the major spectrum of entries concerning camera settings including copyright. It would be helpful if you can confirm that the problem is still present in darktable 3.8.0-2~bpo11+1, available from bullseye-backports. I deinstalled darktable from bullseye and installed darktable from bullseye-backports (version 3.8.0-2~bpo11+1). a) I exported a jpg. Exif-data contained only information about rating and time (see attached Exif.png). b) I selected a photo, opened the metadata editor and told it to apply (Metadaten-Editor_lokale_Einstellung.png). After that I exported the jpg. Result was the same as in a). c) I opened the wheel and Voreinstellungen, went to the global settings of the meta data editor. It differed from the older darktable version in, that no percent symbols were visible (Metadaten-Editor_globale Einstallung.png). I can double-click on "Alle Rechte" and it offers a field to type something in. But apparently this is only to give a name ro a setting, rather than to change a setting. Currently I see no way how to activate inclusion of metadata into export of jpgs. Best wishes, Kerstin
Bug#1019054: darktable: Darktable does not save Metadata in exported jpgs anymore, even author/copyright entries are gone!
Package: darktable Version: 3.4.1-5 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Something must have changed in the global settings. * What exactly did you do (or not do) that was effective (or ineffective)? I tried to find the settings for saving all metadata, but was not successful. The metadata editor offers only entries for adding copyright, but the information is not saved in the jpgs. I also went to the wheel for global settings. It mentions only rights, but none of the other metadata, such as camera model, aperture and exposure time. Also it is not possible to change the available rights settings. * What was the outcome of this action? It was not succesful. The Exif-field still is completely empty except for "300 dpi". * What outcome did you expect instead? In oldstable, darktable saved all metadata upon export, even temperature of the camera body etc. I expect those data either not to be lost, so I can choose which ones to delete/maintain with help of exiftool or that the metadata editor offers the major spectrum of entries concerning camera settings including copyright. And for sure I expect this editor to work. Unlike the current situation. Actually, I have to load all exported jpgs into gimp to add a copyright/author entry. *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-17-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages darktable depends on: ii libc62.31-13+deb11u3 ii libcairo21.16.0-5 ii libcolord-gtk1 0.1.26-2 ii libcolord2 1.4.5-3 ii libcups2 2.3.3op2-3+deb11u2 ii libcurl3-gnutls 7.74.0-1.3+deb11u2 ii libexiv2-27 0.27.3-3+deb11u1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.8-1 ii libgomp1 10.2.1-6 ii libgphoto2-6 2.5.27-1 ii libgphoto2-port122.5.27-1 ii libgraphicsmagick-q16-3 1.4+really1.3.36+hg16481-2 ii libgtk-3-0 3.24.24-4+deb11u2 ii libilmbase25 2.5.4-1 ii libjpeg62-turbo 1:2.0.6-4 ii libjson-glib-1.0-0 1.6.2-1 ii liblcms2-2 2.12~rc1-2 ii liblensfun1 0.3.2-6 ii liblua5.3-0 5.3.3-1.1+b1 ii libopenexr25 2.5.4-2 ii libopenjp2-7 2.4.0-3 ii libosmgpsmap-1.0-1 1.2.0-1 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libpng16-16 1.6.37-3 ii libpugixml1v51.11.4-1 ii librsvg2-2 2.50.3+dfsg-1 ii libsecret-1-00.20.4-2 ii libsoup2.4-1 2.72.0-2 ii libsqlite3-0 3.34.1-3 ii libstdc++6 10.2.1-6 ii libtiff5 4.2.0-1+deb11u1 ii libwebp6 0.6.1-2.1 ii libx11-6 2:1.7.2-1 ii libxml2 2.9.10+dfsg-6.7+deb11u2 ii libxrandr2 2:1.5.1-1 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 darktable recommends no packages. darktable suggests no packages.
Bug#815176: staden: Gap4 contig editor does not show sequences
Hi to all, On Tue, 23 Feb 2016, Andreas Tille wrote: We are talking about different things when talking about "manual install". You can download the packages manually via wget http://ftp.de.debian.org/debian/pool/main/s/staden/staden_2.0.0+b10-3_amd64.deb http://ftp.de.debian.org/debian/pool/main/s/staden/staden-common_2.0.0+b10-3_all.deb Ok, that's much easier. any *may* *be* you might also need http://ftp.de.debian.org/debian/pool/main/s/staden-io-lib/libstaden-read11_1.14.7-1_amd64.deb Actually, also staden-common from unstable was required, but then install went through. All operations worked: Converting the files with pregap and opening of contig editor and of the trace files in gap4! Thanks a lot! You may install the backport ... Best wishes, Kerstin -- PD Dr. Kerstin Hoef-Emden Zülpicher Str. 47b Universität zu Köln 50674 Köln Biozentrum Köln (Cologne Biocenter) Germany Botanisches Institut http://www.uni-koeln.de/~aeb25/
Bug#815176: staden: Gap4 contig editor does not show sequences
Hi to all,
On Tue, 23 Feb 2016, Andreas Tille wrote:
Kerstin, you can either download the staden packages from unstable from
here:
https://packages.debian.org/source/unstable/staden
and install manually on your Jessie system
I had a look at the requirements in the README.build file. Manual
install is not straightforward. Itcl, itk and iwidgets are not available
for jessie. Also configure complains about a missing io_lib. I search
the packages and found staden-io-lib-utils, but could not find a
staden-io_lib.so or something to which I could point with a path.
Libstaden is something different is it? All other dependencies seem to
be sufficient.
or you add unstable to your
/etc/apt/sources.list. ATTENTION: You need to adapt
/etc/apt/preferences to make sure you will not bump your whole system
to unstable!
The most "dangerous" and possibly destabilizing actions I did, were
installations of backports. I usually don't dare to touch sid. Probably
the install will also result in the missing itcl etc. being installed?
Will it work, if I restrict it as such?
Package: staden
Pin: release n=sid
Pin-Priority: 900
Best wishes,
Kerstin
On Mon, Feb 22, 2016 at 05:42:38PM +, James Bonfield wrote:
On Mon, Feb 22, 2016 at 04:34:13PM +0100, Andreas Tille wrote:
if I understand you correctly you are suggesting a further change. Could
you please confirm that this patch
https://anonscm.debian.org/viewvc/debian-med/trunk/packages/staden/trunk/debian/patches/cope_with_modern_windowmanager.patch?view=markup
Yes that's it.
The other change was an improvement to resizing.
This is long and tedious so feel free to ignore, but if you're curious
then here are the details. Typically window managers treat windows as
one of two flavours:
1) The program set the size, so it's permitted to change it again
itself.
2) The user resized the window, so the application request to resize
it will be ignored.
Tk wm geometry command allows you to programatically change the size
of window or with the blank size (wm geometry . {} {}) it'll reset the
window to case 1 - governed by the program rather than the user.
This is all very ICKY and it gets worse. Gap4's contig editor is
"courageously" setting the Y dimension itself based on how many rows
of sequences it wants to display. The X dimension can be controlled
by the user, but as the user increases the size in X, more sequences
can become visible causing the Y dimension to be resized. In the past
this caused massive fights between various parts of tcl/tk and window
managers, sometimes triggering event loops with oscillating window
dimensions. The workaround for this was to have a 1 second delay
between resizing the window and asking the program to recompute the
size.
That in turn though broke all modern window managers. Basically if
you resized quickly and let go it'd just snap back - you had to
resize, hold and wait for 1 sec, and then release. Bizantine... Try
hard as I may I couldn't recreate the strange oscillations so this
change basically pushes it back to how it used to be with instant
recomputation. It seems to work much better in general, but still
isn't perfect.
Perfection isn't possible when you start with the premise of X being
user controlled and Y being program controlled! With Gap5 fortunately
we had an attack of sanity and chose a more traditional strategy.
James
PS. Kerstin if you're still reading this, if set -x doesn't work then
just editing the first #! line to be "#!/bin/sh -x" (without the
quotes) should do the same thing, or simpler still typing in
sh -x `which pregap4`
--
James Bonfield (j...@sanger.ac.uk) | Hora aderat briligi. Nunc et Slythia Tova
| Plurima gyrabant gymbolitare vabo;
A Staden Package developer: | Et Borogovorum mimzebant undique formae,
https://sf.net/projects/staden/ | Momiferique omnes exgrabure Rathi.
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
___
Debian-med-packaging mailing list
debian-med-packag...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
--
PD Dr. Kerstin Hoef-Emden Zülpicher Str. 47b
Universität zu Köln 50674 Köln
Biozentrum Köln (Cologne Biocenter) Germany
Botanisches Institut
http://www.uni-koeln.de/~aeb25/
Bug#815176: staden: Gap4 contig editor does not show sequences
Hi to all, On Mon, 22 Feb 2016, Andreas Tille wrote: Hmmm, lets hunt down this as well. Could you please write the output of apt-get policy staden You probably mean apt-cache policy staden? khe@euler:~$ apt-cache policy staden staden: Installiert: 2.0.0+b10-1.1 Installationskandidat: 2.0.0+b10-1.1 Versionstabelle: *** 2.0.0+b10-1.1 0 500 http://ftp.de.debian.org/debian/ jessie/main amd64 Packages 100 /var/lib/dpkg/status Actually I tried update and upgrade first, which did not include staden, then I deinstalled staden and reinstalled it. cat `which pregap4` Do you really want to see the whole script? Perhaps you try cp `which pregap4` ~/pregap4 edit ~/pregap4 and add set -x Did not work. as the second line in this script. For me this looks pretty sensible. Alternatively you could try explicitly calling /usr/lib/staden/bin/pregap4 What happens if you do this? Did not work (I am surprised - this is the path containing all modules). Best wishes, Kerstin -- PD Dr. Kerstin Hoef-Emden Zülpicher Str. 47b Universität zu Köln 50674 Köln Biozentrum Köln (Cologne Biocenter) Germany Botanisches Institut http://www.uni-koeln.de/~aeb25/
Bug#815176: staden: Gap4 contig editor does not show sequences
Hi to all, at what time intervals syncing takes place? I just tried pregap for the fix of the missing links and it did not yet work. I tested uncommenting the line in the tcl-script of the contig editor with a version downloaded from sourceforge and installed with stow and the fix worked (I use xfce4). Best wishes, Kerstin On Mon, 22 Feb 2016, Andreas Tille wrote: Hi James, thanks a lot for the quick help. On Mon, Feb 22, 2016 at 09:56:12AM +, James Bonfield wrote: Please try commenting out (#) the "wm resizable $w 1 0" line of the contig_editor procedure (approx line 111) in /usr/share/staden/tcl/gap/contig_editor.tcl. I've applied the suggested patch (which can be found in the packaging repository[1]). (It may not be /usr/share - Andreas, where does Debian by default install Gap4?) The patch will be applied to the source and later installed in the location you named above. This disables the attempt to inform the window manager that the X dimension is under user control and Y dimension under the program control. I don't know if this is sufficient as testing this requires checking every window manager out there and see which options they honour, but it cures the problem for me with xfwm4. Since I also can't really test we simply rely on Kerstin to check whether it solves her problem. Kerstin, you might like to wait for the next mirror sync until staden 2.0.0+b10-3 will be available. Please confirm whether both problems you reported are solved. Thanks for testing. James, if you are interested there are some more patches[2] in the packaging reporitory. Some of them might be of interest - at least the spelling.patch with some spelling fixes. Thanks again for your prompt help Andreas. [1] https://anonscm.debian.org/viewvc/debian-med/trunk/packages/staden/trunk/debian/patches/cope_with_modern_windowmanager.patch?revision=21446=markup [2] https://anonscm.debian.org/viewvc/debian-med/trunk/packages/staden/trunk/debian/patches/ -- PD Dr. Kerstin Hoef-Emden Zülpicher Str. 47b Universität zu Köln 50674 Köln Biozentrum Köln (Cologne Biocenter) Germany Botanisches Institut http://www.uni-koeln.de/~aeb25/
Bug#815176: staden: Gap4 contig editor does not show sequences
Hi Andreas, Am 20.02.2016 um 08:33 schrieb Andreas Tille: > Hi Kerstin, > > thanks agein for your bug report. I agree that this problem might be a > bit more tricky than the other bug. I have a slight suspicion that this > user oriented issue might be connected to a later Tcl/Tk version than > you might have used before. I checked it on my computer at home, which is a 64-bit machine: same problem. Best wishes, Kerstin > > On Fri, Feb 19, 2016 at 06:56:36PM +0100, Kerstin Hoef-Emden wrote: >> Package: staden >> Version: 2.0.0+b10-1.1 >> Severity: grave >> Justification: renders package unusable >> >> Dear Maintainer, >> >> >> I loaded pregap-converted *.exp sequences into gap4 to do an assembly. The >> assembly worked out, but I cannot open the contig editor for proofreading. >> More correctly described: It actually opens, but only the upper window bar >> is visible, neither sequences nor trace files are displayed. Since no >> information on this problem shows up in the log files of gap4, I have got no >> idea concerning the nature of the problem. Perhaps something connected to >> the graphical surface? >> >> Before upgrading to jessie, I had staden from the sourceforge site installed >> and it worked, but under jessie I have got the problem with both, the debian >> and with the sourceforge package. >> >> Kerstin >> >> >> >> -- System Information: >> Debian Release: 8.3 >> APT prefers stable-updates >> APT policy: (500, 'stable-updates'), (500, 'stable') >> Architecture: i386 (i686) >> >> Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) >> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) >> Shell: /bin/sh linked to /bin/dash >> Init: systemd (via /run/systemd/system) >> >> Versions of packages staden depends on: >> ii libc62.19-18+deb8u3 >> ii libcurl3 7.38.0-4+deb8u3 >> ii libfontconfig1 2.11.0-6.3 >> ii libfreetype6 2.5.2-3+deb8u1 >> ii libgcc1 1:4.9.2-10 >> ii liblzma5 5.1.1alpha+20120614-2+b3 >> ii libpng12-0 1.2.50-2+deb8u2 >> ii libstaden-read1 1.13.7-1 >> ii libstdc++6 4.9.2-10 >> ii libtcl8.68.6.2+dfsg-2 >> ii libtk8.6 8.6.2-1 >> ii libx11-6 2:1.6.2-3 >> ii libxext6 2:1.3.3-1 >> ii libxft2 2.3.2-1 >> ii libxss1 1:1.2.2-1 >> ii staden-common2.0.0+b10-1.1 >> ii staden-io-lib-utils 1.13.7-1 >> ii tklib0.6-1 >> ii zlib1g 1:1.2.8.dfsg-2+b1 >> >> staden recommends no packages. >> >> Versions of packages staden suggests: >> pn staden-doc >> >> -- no debconf information >> >> ___ >> Debian-med-packaging mailing list >> debian-med-packag...@lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging >> > signature.asc Description: OpenPGP digital signature
Bug#815176: staden: Gap4 contig editor does not show sequences
Package: staden Version: 2.0.0+b10-1.1 Severity: grave Justification: renders package unusable Dear Maintainer, I loaded pregap-converted *.exp sequences into gap4 to do an assembly. The assembly worked out, but I cannot open the contig editor for proofreading. More correctly described: It actually opens, but only the upper window bar is visible, neither sequences nor trace files are displayed. Since no information on this problem shows up in the log files of gap4, I have got no idea concerning the nature of the problem. Perhaps something connected to the graphical surface? Before upgrading to jessie, I had staden from the sourceforge site installed and it worked, but under jessie I have got the problem with both, the debian and with the sourceforge package. Kerstin -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages staden depends on: ii libc62.19-18+deb8u3 ii libcurl3 7.38.0-4+deb8u3 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-3+deb8u1 ii libgcc1 1:4.9.2-10 ii liblzma5 5.1.1alpha+20120614-2+b3 ii libpng12-0 1.2.50-2+deb8u2 ii libstaden-read1 1.13.7-1 ii libstdc++6 4.9.2-10 ii libtcl8.68.6.2+dfsg-2 ii libtk8.6 8.6.2-1 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxft2 2.3.2-1 ii libxss1 1:1.2.2-1 ii staden-common2.0.0+b10-1.1 ii staden-io-lib-utils 1.13.7-1 ii tklib0.6-1 ii zlib1g 1:1.2.8.dfsg-2+b1 staden recommends no packages. Versions of packages staden suggests: pn staden-doc -- no debconf information
Bug#815174: staden: Missing links in /usr/bin
Package: staden Version: 2.0.0+b10-1.1 Severity: grave Justification: renders package unusable Dear Maintainer, I tried to convert *.ab1 files to *.exp files with pregap4, which failed with an error message that eba could not be found. I copied an eba from the sourceforge download bay into /usr/bin and retried conversion of the ABI chromatograms. The error message concerning eba was gone, instead conversion failed because of a missing init_exp command. Thereafter I had a closer look into /usr/bin and realized that the staden parts were links to /usr/lib/staden/bin, but of the multiple files in the sourceforge package, only pregap, gap4, gap5, trev and spin had such a link. I thus, created the missing links by hand and conversion worked out. The files could be opened and assembled with gap4. Working furtheron with the files, however, is still hampered by another problem, which I suspect to be of a different kind, thus will be subject to a separate bug report. Kerstin -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages staden depends on: ii libc62.19-18+deb8u3 ii libcurl3 7.38.0-4+deb8u3 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-3+deb8u1 ii libgcc1 1:4.9.2-10 ii liblzma5 5.1.1alpha+20120614-2+b3 ii libpng12-0 1.2.50-2+deb8u2 ii libstaden-read1 1.13.7-1 ii libstdc++6 4.9.2-10 ii libtcl8.68.6.2+dfsg-2 ii libtk8.6 8.6.2-1 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxft2 2.3.2-1 ii libxss1 1:1.2.2-1 ii staden-common2.0.0+b10-1.1 ii staden-io-lib-utils 1.13.7-1 ii tklib0.6-1 ii zlib1g 1:1.2.8.dfsg-2+b1 staden recommends no packages. Versions of packages staden suggests: pn staden-doc -- no debconf information
Bug#731473: Wheezy: eth0 not working
Package: linux-image-3.2.0-4-amd64 Version: 3.2.51-1 I installed Wheezy on a new machine (Shuttle DS47) at first via netinst-CD, but access to the mirrors was not possible. Thus, Wheezy was installed with the standard set of DVDs, to be able to solve the problem from an working OS. Symptoms were as follows: It was not possible to ping from or to the machine, although dmesg said that eth0 was up and ready and although arp -a from another computer could identify MAC and IP address of the attached Shuttle. Two Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller are built in and the module r8169 was present. Only after downloading the proprietary driver from the sites of Realtek, transferring it via USB stick to the Shuttle and compiling it there made the ethernet work. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668991: evolution: Wrong date when opening a day in calendar
Package: evolution Version: 2.30.3-5 Severity: normal When opening a day in the calendar via double-click to enter an event, always one day earlier opens. I.e. I click to open Tuesday April 17, but Monday April 16 opens. This bug report was posted from a squeeze amd64-bit, but the problem also occurs on a machine with squeeze for 32bit intels. -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages evolution depends on: ii dbus 1.2.24-4+squeeze1 simple interprocess messaging syst ii debconf [debconf-2 1.5.36.1 Debian configuration management sy ii evolution-common 2.30.3-5 architecture independent files for ii evolution-data-ser 2.30.3-2 evolution database backend server ii gconf2 2.28.1-6 GNOME configuration database syste ii gnome-icon-theme 2.30.3-2 GNOME Desktop icon theme ii libart-2.0-2 2.3.21-1 Library of functions for 2D graphi ii libatk1.0-01.30.0-1 The ATK accessibility toolkit ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libcamel1.2-14 2.30.3-2 The Evolution MIME message handlin ii libcanberra-gtk0 0.24-1Gtk+ helper for playing widget eve ii libcanberra0 0.24-1a simple abstract interface for pl ii libdbus-1-31.2.24-4+squeeze1 simple interprocess messaging syst ii libdbus-glib-1-2 0.88-2.1 simple interprocess messaging syst ii libebackend1.2-0 2.30.3-2 Utility library for evolution data ii libebook1.2-9 2.30.3-2 Client library for evolution addre ii libecal1.2-7 2.30.3-2 Client library for evolution calen ii libedataserver1.2- 2.30.3-2 Utility library for evolution data ii libedataserverui1. 2.30.3-2 GUI utility library for evolution ii libegroupwise1.2-1 2.30.3-2 Client library for accessing group ii libenchant1c2a 1.6.0-1 a wrapper library for various spel ii libevolution 2.30.3-5 evolution libraries ii libfontconfig1 2.8.0-2.1 generic font configuration library ii libfreetype6 2.4.2-2.1+squeeze4FreeType 2 font engine, shared lib ii libgconf2-42.28.1-6 GNOME configuration database syste ii libgdata-google1.2 2.30.3-2 Client library for accessing Googl ii libgdata1.2-1 2.30.3-2 Client library for accessing Googl ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgnome-desktop-2 2.30.2-2 Utility library for loading .deskt ii libgnomecanvas2-0 2.30.1-1 A powerful object-oriented display ii libgtk2.0-02.20.1-2 The GTK+ graphical user interface ii libgtkhtml-editor0 3.30.3-1 HTML rendering/editing library - e ii libgtkhtml3.14-19 3.30.3-1 HTML rendering/editing library - r ii libgweather1 2.30.3-1 GWeather shared library ii libical0 0.44-3iCalendar library implementation i ii libice62:1.0.6-2 X11 Inter-Client Exchange library ii libnotify1 [libnot 0.5.0-2 sends desktop notifications to a n ii libnspr4-0d4.8.6-1 NetScape Portable Runtime Library ii libnss3-1d 3.12.8-1+squeeze4 Network Security Service libraries ii libpango1.0-0 1.28.3-1+squeeze2 Layout and rendering of internatio ii libsm6 2:1.1.1-1 X11 Session Management library ii libsoup2.4-1 2.30.2-1+squeeze1 an HTTP library implementation in ii libsqlite3-0 3.7.3-1 SQLite 3 shared library ii libstartup-notific 0.10-1library for program launch feedbac ii libunique-1.0-01.1.6-1.1 Library for writing single instanc ii libxml22.7.8.dfsg-2+squeeze3 GNOME XML library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages evolution recommends: ii bogofilter 1.2.2-2 a fast Bayesian spam filter (dummy ii evolution-plugins2.30.3-5standard plugins for Evolution ii evolution-webcal 2.28.1-1webcal: URL handler for GNOME and ii gnome-desktop-data 2.30.2-2Common files for GNOME desktop app ii yelp 2.30.1+webkit-1 Help browser for GNOME Versions of packages evolution suggests: pn bug-buddy none (no description available) pn
Bug#654890: openoffice.org-impress: Square root not properly displayed in presentation mode
Package: openoffice.org-impress Version: 1:3.2.1-11+squeeze4 Severity: important Mathematical formulas containing square roots are not displayed properly when switching openoffice.org-impress from edit to presentation mode. The foot of the square root moves to the middle of its horizontal bar. This bug was already present in openoffice.org under lenny. -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openoffice.org-impress depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libstdc++64.4.5-8The GNU Standard C++ Library v3 ii openoffice.or 1:3.2.1-11+squeeze4office productivity suite -- arch- ii openoffice.or 1:3.2.1-11+squeeze4office productivity suite -- drawi ii ure 1.6.1+OOo3.2.1-11+squeeze4 OpenOffice.org UNO runtime environ openoffice.org-impress recommends no packages. openoffice.org-impress suggests no packages. Versions of packages openoffice.org-core depends on: ii fontconfig2.8.0-2.1 generic font configuration library ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libcurl3-gnut 7.21.0-2 Multi-protocol file transfer libra ii libdb4.8 4.8.30-2 Berkeley v4.8 Database Libraries [ ii libexpat1 2.0.1-7XML parsing C library - runtime li ii libfreetype6 2.4.2-2.1+squeeze3 FreeType 2 font engine, shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgraphite3 1:2.3.1-0.2SILGraphite - a smart font rende ii libgstreamer- 0.10.30-1 GStreamer libraries from the base ii libgstreamer0 0.10.30-1 Core GStreamer libraries and eleme ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libhunspell-1 1.2.11-1 spell checker and morphological an ii libhyphen02.5-1 ALTLinux hyphenation library - sha ii libice6 2:1.0.6-2 X11 Inter-Client Exchange library ii libicu44 4.4.1-7International Components for Unico ii libjpeg62 6b1-1 The Independent JPEG Group's JPEG ii libmythes-1.2 2:1.2.1-1 simple thesaurus library ii libneon27-gnu 0.29.3-3 An HTTP and WebDAV client library ii libnspr4-0d 4.8.6-1NetScape Portable Runtime Library ii libnss3-1d3.12.8-1+squeeze4 Network Security Service libraries ii librdf0 1.0.10-3 Redland Resource Description Frame ii libsm62:1.1.1-1 X11 Session Management library ii libssl0.9.8 0.9.8o-4squeeze4 SSL shared libraries ii libstdc++64.4.5-8The GNU Standard C++ Library v3 ii libx11-6 2:1.3.3-4 X11 client-side library ii libxaw7 2:1.0.7-1 X11 Athena Widget library ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar ii libxinerama1 2:1.1-3X11 Xinerama extension library ii libxml2 2.7.8.dfsg-2+squeeze1 GNOME XML library ii libxrandr22:1.3.0-3 X11 RandR extension library ii libxrender1 1:0.9.6-1 X Rendering Extension client libra ii libxslt1.11.1.26-6 XSLT 1.0 processing library - runt ii libxt61:1.0.7-1 X11 toolkit intrinsics library ii openoffice.or 1:3.2.1-11+squeeze4office productivity suite -- arch- ii ttf-opensymbo 1:3.2.1-11+squeeze4OpenSymbol TrueType font ii ure 1.6.1+OOo3.2.1-11+squeeze4 OpenOffice.org UNO runtime environ ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages openoffice.org-draw depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libstdc++64.4.5-8The GNU Standard C++ Library v3 ii libwpd8c2a0.8.14-1 Library for handling WordPerfect d ii libwpg-0.1-1 0.1.3-1WordPerfect graphics import/conver ii openoffice.or 1:3.2.1-11+squeeze4office productivity suite -- arch- ii ure 1.6.1+OOo3.2.1-11+squeeze4 OpenOffice.org UNO runtime environ ii zlib1g1:1.2.3.4.dfsg-3 compression library -
Bug#514112: Openoffice 2.4 (lenny) crashes when opening template files from ooffice 2.0.4
Package: openoffice.org Version: 1:2.4.1-17 Severity: important From one day to the other, openoffice started crashing when I tried to open a spreadsheet.ots that has been set up under openoffice 2.0 from etch. It asks for a recovery of files, then upon opening crashes no matter whether I tell it to recover or not. All other spreadsheets that I tried to open thereafter, crashed, too. I have tried to solve the problem by renaming the .openoffice.org2 directory and by completely reinstalling the office suite together with the German menu package and the German help file. Current status is that I can open all other files, but it still crashes when trying to open the *.ots file from openoffice 2.0.4. The file itself is not damaged, since it still can be opened by openoffice 2.0.4 and causes openoffice 2.4 to crash when I copy it to the other computer with the lenny install. Apparently, ooffice2.4 cannot handle this file, which is simply an empty template with formulas to compute averages, standard deviations and min and max values for data that are supposed to be inserted in future. When I double-click the file to open it directly, the error message is: Durch einen unerwarteten Fehler ist OpenOffice.org abgestürzt. ... Die folgenden Dokumente werden wieder hergestellt: (= OpenOffice.org crashed due to an unexpected error. ... The following documents will be recovered.) However, the box below does not show any documents, but is empty. I am using kernel 2.6.26-1-686 and libc6-i686 2.7-18.
Bug#514112: Openoffice 2.4 (lenny) crashes when opening template files from ooffice 2.0.4
Hi, On Wed, 4 Feb 2009, Rene Engelhard wrote: I bet this is the same as #513743 / #513482. Can you confirm? (Run gdb /usr/lib/openoffice/program/soffice.bin, enter run, do stuff, enter bt when the crash happened) I had a look at the two bug reports and tested some things that have been reported to cause crashes. 513743 I chose a spreadsheet with several pages and switched sheets: ooffice did not crash. Opening *.ods files also does not crash ooffice (after I have reinstalled it, before that everything was messed up.) 513482 I saved the file containing several sheets to the Desktop as a template file (*.ots) and re-opened it: ooffice crashed (see attached screenshot - the lower part is not visible on the display, it simply allows for an OK. This is because lenny is installed on a Fujitsu-Siemens Amilo Pro Mini netbook with a 1024x600 display.) So I cannot confirm my bug is the same as reported in 513743, but it seems to be the same as reported in 513482. Best wishes, Kerstin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#450722: evince doesn't display gradient margins properly
Hi, On Fri, 9 Nov 2007, Josselin Mouette wrote: When opening PDFs with gradients as a background picture, evince doesn't display the margins properly. In a gradient with an axis from lower left to upper right corner, the upper left and lower right corners are empty and at the sides of the page a saw tooth-like margin is visible. This phenomenon was known to me from xpdf of sarge, but seemingly evince inherited it, whereas the problem is fixed now in etch's xpdf. It seems to me that this bug is fixed in evince 0.8.3 currently in unstable. Could you please confirm? Sorry, but I prefer not to test this. It is not a good idea to run unstable, if one permanently uses the computer for work. I don't want to sabotage my research. Only last Thursday, I switched to etch and that's why I stumble over bugs right now during my work. Best wishes, Kerstin -- Dr. Kerstin Hoef-Emden Gyrhofstr. 15 Universität zu Köln 50931 Köln Botanisches InstitutGermany http://www.uni-koeln.de/~aeb25/
