Bug#1060323: libosp-dev: missing dependency on libosp5
I took the second approach suggested by Gregor, of changing the install order. Massive rewrite of d/rules to happen at a later date. :-) -- Neil Roeth
Bug#984931: git-el,elpa-magit: fails to install: /usr/lib/emacsen-common/packages/install/git emacs failed at /usr/lib/emacsen-common/lib.pl line 19, line 7.
On Thu, 11 Mar 2021 15:17:39 -0400 David Bremner wrote: > David Bremner writes: > > > > > As far as I can see, the problem is that the setup for elpa-magit and > > git-el both call "emacs", but that does not exist until the > > update-alternatives is called. So there seems to be a race condition > > here where emacs-gtk (or whatever is providing /usr/bin/emacs) needs to > > run its postinst before any add-on package wanting to do byte > > compilation. > > > > Somewhat to my surprise I could duplicate this failure with > > > > $ sudo schroot -r -c test apt install git-el elpa-magit > > > > where test is an up to date sid chroot. > > Another thing I noticed is that git-el does not depend on emacsen-common > > per [1] (5), I think it should. I don't know if this has any practical > impact. > > d > I maintain the psgml add-on package and worked through a similar issue in this release cycle. According to the Emacs policy (5A and 5C), this package should not only add a dependency on "emacsen-common" but also remove the dependency on "emacs". That would have the positive practical impact of not trying to byte compile the files until Emacs was completely installed, according to (5B). For psgml, I added the dependency on "emacsen-common" and changed the dependency on "emacs25" to a recommendation of "emacs". Neil
Bug#976547: Bug#976535: Bug#976495: also happens on amd64, should be worked around by 1.8.20-5 but the real fix will come with 1.8.20-6
Attached is a minimal Docbook SGML file and a script which invokes the commands required to make a PDF using pdfjadetex. Thanks for looking into this. test.sh Description: application/shellscript Some Title Here STH Neil Roeth 2020 Neil Roeth Introduction This is a test. This is only a test. Now, back to our regularly scheduled program.
Bug#933319: psgml: depends on old emacs packages
On 08/02/2019 06:47 AM, Gianfranco Costamagna wrote: > control: tags -1 pending > > uploaded in deferred/10 > > G. Thanks!
Bug#854430: The last version provides the bugfix
On 02/09/2017 01:02 PM, Georges Khaznadar wrote: > Fritzing version 0.9.3b+dfsg-4 provides a workaround for this bug: it > invokes the command 'fritzing' after a working directory change. > > Please be sure to call the command 'Fritzing' in order to launch it > safely (this command name did not change, and the .desktop file taken in > account in the applications menu behaves as expected). More info: I had invoked Fritzing from the menu, as /usr/bin/Fritzing and as /usr/bin/fritzing and encountered missing file errors in all cases which resulted in almost no parts being loaded. Just now, I completely removed the fritzing, fritzing-data and fritzing-parts packages, deleted the /usr/share/fritzing directory, then reinstalled all three and the error went away. It looks like there is some error in the upgrade process from prior packages to the new ones. -- Neil Roeth
Bug#854430: fritzing: Fritzing fails to find core parts
Package: fritzing Version: 0.9.3b+dfsg-4 Severity: grave Similar to 847655, while displaying a screen that says, "loading bin 'Core Parts'", Fritzing displays another screen that says, "Cannot read file screw_terminal_2_3.5mm.fzp: No such file or directory.". That file exists in /usr/share/fritzing/parts/core/. After clicking OK on that screen, Fritzing displays a screen titled "Unable to find the following 143 parts:". I randomly selected several and all were in /usr/share/fritzing/parts/core. After continuing from there, almost no parts are displayed. Directly calling /usr/bin/fritzing instead of the wrapper /usr/bin/Fritzing generates an error that it cannot find the file /usr/share/fritzing/parts/core/bins/core.fzb. That file is actually in /usr/share/fritzing/parts/bins/core.fzb. Again, continuing results in almost no parts displayed. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fritzing depends on: ii fritzing-data 0.9.3b+dfsg-4 ii libc6 2.24-9 ii libgcc1 1:6.3.0-6 ii libgit2-240.24.5-1 ii libgl1-mesa-glx [libgl1] 13.0.4-1 ii libqt5concurrent5 5.7.1+dfsg-3+b1 ii libqt5core5a 5.7.1+dfsg-3+b1 ii libqt5gui55.7.1+dfsg-3+b1 ii libqt5network55.7.1+dfsg-3+b1 ii libqt5printsupport5 5.7.1+dfsg-3+b1 ii libqt5serialport5 5.7.1~20161021-2 ii libqt5sql55.7.1+dfsg-3+b1 ii libqt5sql5-sqlite 5.7.1+dfsg-3+b1 ii libqt5svg55.7.1~20161021-2 ii libqt5widgets55.7.1+dfsg-3+b1 ii libqt5xml55.7.1+dfsg-3+b1 ii libstdc++66.3.0-6 ii zlib1g1:1.2.8.dfsg-5 fritzing recommends no packages. Versions of packages fritzing suggests: ii fritzing-parts 0.9.3b-1 -- no debconf information -- Neil Roeth
Bug#800291: jade: Please migrate a supported debhelper compat level
Thanks, Tobias. I have finished filing bugs against all packages with reverse dependencies on jade and sp. All are blockers on the tracking bugs. I will follow up and/or NMU as necessary. On 10/16/2016 05:26 AM, Tobias Frost wrote: > Hi Neil, > > sorry for the late reply... Been busy recenently. > > Am Sonntag, den 25.09.2016, 12:32 -0400 schrieb Neil Roeth: >> Hi, Tobi, >> >> The removal of jade, sp and openjade1.3 is coming >> along. Openjade1.3 >> is done, it was actually removed from testing but there were no more >> dependencies on it. I was focusing recently on the sp binary >> package, >> and most of those dependencies have been switched to opensp. Jade is >> next. >> >> There are tracking bugs already, 811310 and 811312. > ok > >> Aboot and iputils have bugs with patches open to change sp to opensp. >> >> Can you explain the output below? I guess "dak rm jade" means remove >> jade, while the -n means not to actually do it (no act). What does >> -R >> mean? Does the command apply to the jade source package or the >> binary >> package? I'm guessing source since sp appears in the list and it is >> a >> binary package built from the jade source package. > The command checks what would happen if you remove jade from the > archives, a convenient way to check reverse dependencies you have on > jade. > >> Thanks. >> >> On 09/25/2016 07:04 AM, Tobias Frost wrote: >>> Hi Neil, >>> >>> how is the removal going? >>> I was wondering if there should be a dedicated bug to track the >>> status >>> of the progess? What do you think? >>> >>> >>> A "dak rm -Rn jade" yields to: >>> >>> >>> # Broken Depends: >>> xmldiff: xmldiff-xmlrev >>> >>> # Broken Build-Depends: >>> aboot: sp >>> alex: jade >>> datapacker: jade >>> dejagnu: jade >>> gnome-packagekit: sp >>> gstreamer1.0: jade (>= 1.2.1) >>> iputils: sp >>> kannel: jade >>> libetpan: jade >>> lprng-doc: jade >>> mozart: sp >>> pyepl: jade >>> scons-doc: jade >>> >>> >>> -- >>> tobi >>> >>> On Thu, 29 Oct 2015 21:00:50 -0400 Neil Roeth >>> wrote: >>>> I intend to remove this package from Debian rather than update >>> it. The >>>> Debian packages openjade/opensp can be used instead. I will file >>>> bugs >>>> against any packages that depend on jade and give them some time >>>> to >>> be >>>> updated before I file the actual removal bug for jade. >>>> >>>> -- >>>> Neil Roeth >>>> >>>> >>>> >> >> >> -- Neil Roeth
Bug#800291: jade: Please migrate a supported debhelper compat level
Hi, Tobi, The removal of jade, sp and openjade1.3 is coming along. Openjade1.3 is done, it was actually removed from testing but there were no more dependencies on it. I was focusing recently on the sp binary package, and most of those dependencies have been switched to opensp. Jade is next. There are tracking bugs already, 811310 and 811312. Aboot and iputils have bugs with patches open to change sp to opensp. Can you explain the output below? I guess "dak rm jade" means remove jade, while the -n means not to actually do it (no act). What does -R mean? Does the command apply to the jade source package or the binary package? I'm guessing source since sp appears in the list and it is a binary package built from the jade source package. Thanks. On 09/25/2016 07:04 AM, Tobias Frost wrote: > Hi Neil, > > how is the removal going? > I was wondering if there should be a dedicated bug to track the status > of the progess? What do you think? > > > A "dak rm -Rn jade" yields to: > > > # Broken Depends: > xmldiff: xmldiff-xmlrev > > # Broken Build-Depends: > aboot: sp > alex: jade > datapacker: jade > dejagnu: jade > gnome-packagekit: sp > gstreamer1.0: jade (>= 1.2.1) > iputils: sp > kannel: jade > libetpan: jade > lprng-doc: jade > mozart: sp > pyepl: jade > scons-doc: jade > > > -- > tobi > > On Thu, 29 Oct 2015 21:00:50 -0400 Neil Roeth wrote: >> I intend to remove this package from Debian rather than update > it. The >> Debian packages openjade/opensp can be used instead. I will file bugs >> against any packages that depend on jade and give them some time to > be >> updated before I file the actual removal bug for jade. >> >> -- >> Neil Roeth >> >> >> -- Neil Roeth
Bug#835065: jade: Package rebuilt from source is broken
On 08/21/2016 07:34 PM, Daniel Schepler wrote: > Source: jade > Version: 1.2.1-49 > Severity: serious > > For example, if I rebuild jade locally, then try to build > dictionaries-common using the rebuilt jade, it gives an error: > > jade -t sgml -V nochunks -d policy/html.dsl \ > /usr/share/sgml/declaration/xml.decl policy/dsdt-policy.xml > > policy/dsdt-policy.html > jade:/usr/share/sgml/declaration/xml.decl:31:27:W: characters in the > document character set with numbers exceeding 65535 not supported > Segmentation fault > Makefile:129: recipe for target 'policy/dsdt-policy.html' failed > make[1]: *** [policy/dsdt-policy.html] Error 139 > make[1]: Leaving directory '/build/dictionaries-common-1.27.0' > debian/rules:27: recipe for target 'build-stamp' failed > make: *** [build-stamp] Error 2 > dpkg-buildpackage: error: debian/rules build gave error exit status 2 I am working on removing the jade package from Debian. I'll file a bug against dictionaries-common to replace jade with openjade. Thanks. -- Neil Roeth
Bug#832932: gtk-doc: build dependencies unsatisfiable on current sid (build-conflicts with openjade)
On 07/30/2016 06:08 AM, Emilio Pozuelo Monfort wrote: > On 30/07/16 01:22, Neil Roeth wrote: >> Thanks, I'll take a look at gtk-doc to see what can be done to transition it >> to >> openjade. > Looks like jade is no longer used. We can probably just drop the jade build > dependency and the openjade b-d-conflicts. > > Cheers, > Emilio That's what it looks like to me as well. I was able to build it in pdebuild with no errors after removing jade and docbook-dsssl from the build-dependencies and also removing the build-conflicts. I also could not find a call to jade anywhere in the code, so I think jade and docbook-dsssl can also be dropped from the binary package depends. -- Neil Roeth
Bug#832932: gtk-doc: build dependencies unsatisfiable on current sid (build-conflicts with openjade)
Thanks, I'll take a look at gtk-doc to see what can be done to transition it to openjade. On 07/29/2016 02:02 PM, Niko Tyni wrote: > Package: gtk-doc > Version: 1.25-2 > Severity: serious > X-Debbugs-Cc: docbook-ds...@packages.debian.org, Neil Roeth > > The build dependencies of the gtk-doc package are currently unsatisfiable > on sid/amd64: > > # apt-get build-dep gtk-doc > Reading package lists... Done > Reading package lists... Done > Building dependency tree > Reading state information... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: >builddeps:gtk-doc : Depends: docbook-dsssl but it is not going to be > installed > E: Unable to correct problems, you have held broken packages. > > This doesn't seem to be transient but rather due to a recent change > in docbook-dsssl_1.79-9.1 which made it depend unconditionally on > openjade. This is a problem for gtk-doc because it Build-Depends on > docbook-dsssl but Build-Conflicts on openjade. > > Cc'ing the docbook-dsssl maintainer, and Neil Roeth who did the NMU. -- Neil Roeth
Bug#822293: password-gorilla: Cannot save new passwords
Package: password-gorilla
Version: 1.5.3.7-1
Severity: grave
I have recently been unable to save new entries in Password Gorilla. I
get an error about not being able to run ifconfig. This occurs because
Password Gorilla uses the Tcl package uuid which way deep inside calls
ifconfig (full stack below). On my Debian unstable system, the ifconfig
program is located in /sbin which is not in my PATH as a non-root user.
There are some workarounds:
* Add /sbin to your PATH (not a great idea)
* Create a symbolic link from /sbin/ifconfig to a directory in your PATH.
* Create a shell script in your PATH called ifconfig that does something
similar, like call "ip a" or "hostname -I". I don't really know what the
Tcl uuid package requires from ifconfig, so it is difficult to say what
is an appropriate substitute, but this worked for me.
Possible solutions:
* Change Password Gorilla to use some other method for generating UUIDs.
* Change the Tcl uuid package not to use ifconfig.
I set the severity to grave because this prevents saving password
entries which is the core function of Password Gorilla.
Error message stack:
couldn't execute "ifconfig": no such file or directory
couldn't execute "ifconfig": no such file or directory
while executing
"exec ifconfig"
(procedure "dump" line 2)
invoked from within
"dump"
(procedure "::nettool::mac_list" line 3)
invoked from within
"::nettool::mac_list"
(procedure "::nettool::hwid_list" line 3)
invoked from within
"::nettool::hwid_list"
(procedure "generate_tcl_machinfo" line 36)
invoked from within
"generate_tcl_machinfo"
(procedure "generate_tcl" line 7)
invoked from within
"generate_tcl"
(procedure "generate" line 6)
invoked from within
"generate"
(procedure "uuid::uuid" line 7)
invoked from within
"uuid::uuid generate"
(procedure "PopulateRecord" line 20)
invoked from within
"PopulateRecord [ set newrn [ $::gorilla::db createRecord ] ] "
(procedure "Ok" line 30)
invoked from within
"Ok"
(in namespace inscope "::gorilla::LoginDialog::0" script line 1)
invoked from within
"namespace inscope ::gorilla::LoginDialog::0 Ok"
invoked from within
".nmLoginDialog0.bf.top.ok invoke "
invoked from within
".nmLoginDialog0.bf.top.ok instate !disabled { .nmLoginDialog0.bf.top.ok
invoke } "
invoked from within
".nmLoginDialog0.bf.top.ok instate pressed { .nmLoginDialog0.bf.top.ok
state !pressed; .nmLoginDialog0.bf.top.ok instate !disabled {
.nmLoginDialog0.bf..."
(command bound to event)
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages password-gorilla depends on:
ii itcl3 3.4.3-1
ii tcl8.5 8.5.19-2
ii tcllib 1.18-dfsg-2
ii tk8.5 8.5.19-1
ii tklib 0.6-3
password-gorilla recommends no packages.
password-gorilla suggests no packages.
-- no debconf information
--
Neil Roeth
Bug#816585: opensp: FTBFS: ! LaTeX Error: File `ulem.sty' not found.
Thanks. It needs an explicit build dependency on texlive-generic-recommended that wasn't necessary before. -- Neil Roeth
Bug#683938: aplus-fsf-el: missing copyright file
On 08/05/2012 05:29 PM, Andreas Beckmann wrote: Disabling dh_installdocs as can be seen in https://lists.debian.org/debian-release/2012/08/msg00204.html is not a good idea. Also the description should be updated to state that this is an empty dummy package because xemacs is buggy and currently not available. Andreas Description changed and dh_installdocs restored. -- Neil Roeth
Bug#668039: closed by Guido Günther (Re: Bug#668039: iceowl: Upgrade to latest sid makes all calendar data unavailable)
I hadn't seen that, thanks. However, I consider it an iceowl issue rather than an iceowl-extension issue since a user may want to switch to some other stand alone calendar program rather than to iceowl-extension. In that case, he would need to export the iceowl calendars to a standard format so that it could be imported to the other program. On 04/10/2012 07:55 AM, Olivier Berger wrote: Hi. On Tue, Apr 10, 2012 at 06:58:37AM -0400, Neil Roeth wrote: Thanks, I didn't realize standalone iceowl had been removed from Debian. I successfully switched to iceowl-extension. In order to do that, I had to install iceowl and the older version of calendar-timezones, export the calendars, then install iceowl-extension and the newer version of calendar-timezones and import the calendars. This is not something I would think a typical user would be capable of doing. I expect some users will be surprised when they upgrade to the next Debian release and they have no way to retrieve any of their iceowl calendar data. It would be nice if there were some way to alert them to export their calendars before calendar-timezones is upgraded and makes iceowl unusable. Maybe a transitional iceowl package with a pre-conf step that just gives them the choice to either quit so they can export their calendars, or continue? You may also see #655703 which deals with that very same issue. Hope this helps. Best regards, -- Neil Roeth -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668039: closed by Guido Günther (Re: Bug#668039: iceowl: Upgrade to latest sid makes all calendar data unavailable)
Thanks, I didn't realize standalone iceowl had been removed from Debian. I successfully switched to iceowl-extension. In order to do that, I had to install iceowl and the older version of calendar-timezones, export the calendars, then install iceowl-extension and the newer version of calendar-timezones and import the calendars. This is not something I would think a typical user would be capable of doing. I expect some users will be surprised when they upgrade to the next Debian release and they have no way to retrieve any of their iceowl calendar data. It would be nice if there were some way to alert them to export their calendars before calendar-timezones is upgraded and makes iceowl unusable. Maybe a transitional iceowl package with a pre-conf step that just gives them the choice to either quit so they can export their calendars, or continue? On 04/09/2012 10:11 AM, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the iceowl package: #668039: iceowl: Upgrade to latest sid makes all calendar data unavailable It has been closed by Guido Günther. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Guido Günther by replying to this email. -- Neil Roeth -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668039: iceowl: Upgrade to latest sid makes all calendar data unavailable
Package: iceowl Version: 1.0~b2-7 Severity: grave I upgraded to the latest sid packages today and when I restarted iceowl afterward, none of my calendar data was displayed. When I started it from a terminal window, I got this output: -- Error: No timezones found! Please install calendar-timezones.xpi. Error: No timezones found! Please install calendar-timezones.xpi. Error: No timezones found! Please install calendar-timezones.xpi. Error: No timezones found! Please install calendar-timezones.xpi. Error: No timezones found! Please install calendar-timezones.xpi. Error: Can't create calendar for 03fe941b-e505-4376-a0fd-aa0b799db359 (storage, moz-storage-calendar://): [Exception... "'' when calling method: [calICalendar::id]" nsresult: "0x804a0008 ()" location: "JS frame :: file:///usr/lib/iceowl/modules/calUtils.jsm -> file:///usr/lib/iceowl/calendar-js/calCalendarManager.js :: cmgr_assureCache :: line 793" data: no] Error: No timezones found! Please install calendar-timezones.xpi. Error: Can't create calendar for af5e2f5a-476a-455c-bad0-e2289ba82da0 (storage, moz-storage-calendar://): [Exception... "'' when calling method: [calICalendar::id]" nsresult: "0x804a0008 ()" location: "JS frame :: file:///usr/lib/iceowl/modules/calUtils.jsm -> file:///usr/lib/iceowl/calendar-js/calCalendarManager.js :: cmgr_assureCache :: line 793" data: no] Error: No timezones found! Please install calendar-timezones.xpi. Error: Can't create calendar for cd1ed02c-66af-4f8f-99b3-e0e87f76f6a1 (storage, moz-storage-calendar://): [Exception... "'' when calling method: [calICalendar::id]" nsresult: "0x804a0008 ()" location: "JS frame :: file:///usr/lib/iceowl/modules/calUtils.jsm -> file:///usr/lib/iceowl/calendar-js/calCalendarManager.js :: cmgr_assureCache :: line 793" data: no] Error: No timezones found! Please install calendar-timezones.xpi. Error: No timezones found! Please install calendar-timezones.xpi. -- It appeared to be having trouble getting timezones, but the calendar-timezones package is installed, as shown below. I attempted to set the timezone in Iceowl Preferences, but it displayed an empty list of timezones. I attempted to remove and install iceowl and calendar-timezones, and got this message about iceowl: -- Reading package lists... Done Building dependency tree Reading state information... Done Package iceowl is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'iceowl' has no installation candidate -- I reinstalled iceowl from the deb file on my system and reinstalled the latest calendar-timezones, but the problem remained - I still could not see my calendar data. I again removed the two packages iceowl and calendar-timezones, then installed iceowl and an older version of calendar-timezones (8.0-2+b1 for amd64) and that restored my calendar data as well as made a list of timezones available in the Preferences. So, it seems the newer version of calendar-timezones breaks iceowl's timezone handling. Let me know if you need more information. Thanks. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages iceowl depends on: ii calendar-timezones 10.0.3-3 ii libasound2 1.0.25-2 ii libatk1.0-0 2.4.0-2 ii libc6 2.13-27 ii libcairo2 1.12.0-2 ii libdbus-1-3 1.5.12-1 ii libdbus-glib-1-20.98-1 ii libfontconfig1 2.8.0-3.1 ii libfreetype62.4.9-1 ii libgcc1 1:4.7.0-2 ii libgconf2-4 3.2.3-4 ii libgdk-pixbuf2.0-0 2.26.0-2 ii libglib2.0-02.32.0-3 ii libgnomevfs2-0 1:2.24.4-1 ii libgtk2.0-0 2.24.10-1 ii libjpeg88d-1 ii libnotify4 0.7.5-1 ii libnspr4-0d 4.9-1 ii libnss3-1d 3.13.3-1 ii libpango1.0-0 1.30.0-1 ii libsqlite3-03.7.11-2 ii libstdc++6 4.7.0-2 ii libx11-62:1.4.4-4 ii libxrender1 1:0.9.6-2 ii libxt6 1:1.1.1-2 ii zlib1g 1:1.2.6.dfsg-2 Versions of packages iceowl recommends: ii calendar-google-provider 10.0.3-3 iceowl suggests no packages. -- no debconf information -- Neil Roeth -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662091: sends SGML parsers to an sgml.dcl that isn't there
On 03/04/2012 04:42 PM, Samuel Bronson wrote: (Anyway, since it seems to be a problem in that package, I've reassigned it accordingly, and closed the clone of this bug for opensp.) OK, thanks. -- Neil Roeth -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662091: sp: nsgmls can't find sgml.dcl
Sorry, my mistake on sgml-data. So far, I am unable to reproduce this. The same command works fine on my system, and if I use strace to verify which files it is opening, sgml.dcl is not among them. nsgmls and onsgmls effectively have a builtin SGML declaration, so it doesn't surprise me that it succeeds without an external one. The question is, why does executing the command on your system require that external file? Can you run the command under strace and post the output? I.e., $ strace -f -e open nsgmls -s /usr/share/doc/sp/index.htm Regarding version control, Jade upstream has been dead for years and OpenJade development is also basically dormant. I haven't bothered putting my Debian changes out anywhere public since nothing much has been changing. Thanks. -- Neil Roeth -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662091: sp: nsgmls can't find sgml.dcl
Is the package sgml-data installed? On 03/03/2012 07:49 PM, Samuel Bronson wrote: Package: sp Version: 1.3.4-1.2.1-47.1 Severity: serious Dear Maintainer, It looks like nsgmls can't find sgml.dcl anymore: , | % nsgmls -s /usr/share/doc/sp/index.htm 2>&1 | head | nsgmls:E: cannot find "sgml.dcl"; tried "/usr/share/sgml/xhtml/sgml.dcl", "/usr/local/share/sgml/sgml.dcl", "/usr/share/sgml/sgml.dcl" | nsgmls:(invalid location):E: invalid default SGML declaration | nsgmls:/usr/share/doc/sp/index.htm:1:52:E: cannot find "IETF/HTML-2_0-Strict.dtd"; tried "/usr/share/sgml/xhtml/IETF/HTML-2_0-Strict.dtd", "/usr/local/share/sgml/IETF/HTML-2_0-Strict.dtd", "/usr/share/sgml/IETF/HTML-2_0-Strict.dtd" | nsgmls:/usr/share/doc/sp/index.htm:1:52:E: DTD did not contain element declaration for document type name | nsgmls:/usr/share/doc/sp/index.htm:2:5:E: element "HTML" undefined | nsgmls:/usr/share/doc/sp/index.htm:3:5:E: element "HEAD" undefined | nsgmls:/usr/share/doc/sp/index.htm:4:6:E: element "TITLE" undefined | nsgmls:/usr/share/doc/sp/index.htm:6:5:E: element "BODY" undefined | nsgmls:/usr/share/doc/sp/index.htm:7:3:E: element "H1" undefined | nsgmls:/usr/share/doc/sp/index.htm:8:3:E: element "H3" undefined ` -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-1-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages sp depends on: ii libc6 2.13-26 ii libgcc1 1:4.6.2-12 ii libsp1c21.3.4-1.2.1-47.1 ii libstdc++6 4.6.2-12 sp recommends no packages. Versions of packages sp suggests: ii doc-base 0.10.3 ii sgml-data 2.0.6 -- no debconf information -- debsums errors found: dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 11247 package 'jhcore': missing architecture dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 39968 package 'lambdamoo': missing architecture -- Neil Roeth -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#625102: aplus-fsf: diff for NMU version 4.22.1-4.1
That's fine. Thanks. On 12/08/2011 09:48 AM, gregor herrmann wrote: tags 625102 + pending thanks Dear maintainer, I've prepared an NMU for aplus-fsf (versioned as 4.22.1-4.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. -- Neil Roeth -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650610: openjade1.3: FTBFS: No rule to make target `/usr/lib/libosp.la', needed by `openjade'.
Thanks, I'll have a look. On 12/01/2011 02:28 AM, Daniel Schepler wrote: Source: openjade1.3 Version: 1.3.2-11 Severity: serious From my pbuilder build log: ... /usr/bin/perl ./../instmac.pl MifFOTBuilder_inst.m4>MifFOTBuilder_inst.cxx chmod -w MifFOTBuilder_inst.cxx /usr/bin/perl -w ./../msggen.pl -l jstyleModule MifMessages.msg Legacy library getopts.pl will be removed from the Perl core distribution in the next major release. Please install the separate libperl4-corelibs-perl package. It is being used at ./../msggen.pl, line 21. g++ -g -pipe -fpermissive -O2 -I. -I./../include -I/usr/include/OpenSP -I/usr/include/OpenSP/.. -I./../grove -I./../spgrove -I./../style -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" - DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"openjade\" -DVERSION=\"1.3.2\" -DSP_DEFINE_TEMPLATES=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 - DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_ST_BLKSIZE=1 -DSIZEOF_SIZE_T=8 - DSIZEOF_UNSIGNED_INT=4 -DSP_HAVE_LOCALE=1 -DSP_HAVE_WCHAR=1 -DSP_HAVE_GETTEXT=1 -DSP_HAVE_BOOL=1 -DSP_ANSI_CLASS_INST=1 -DSP_HAVE_SOCKET=1 -DJADE_MIF=1 -DJADE_HTML=1 -DSP_MULTI_BYTE=1 - DHAVE_DLFCN_H=1 -DDEFAULT_SCHEME_BUILTINS=\"/usr/share/sgml/openjade1.3/builtins.dsl\" -c MifFOTBuilder.cxx make[3]: *** No rule to make target `/usr/lib/libosp.la', needed by `openjade'. Stop. make[3]: Leaving directory `/tmp/buildd/openjade1.3-1.3.2/jade' make[2]: *** [jade] Error 2 make[2]: Leaving directory `/tmp/buildd/openjade1.3-1.3.2' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/buildd/openjade1.3-1.3.2' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 The cause appears to be that linking against /usr/lib/libosp.la gets hard-coded into jade/Makefile.lt. -- Neil Roeth -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#625355: Bug#638441: opensp: openjade1.3 causes FTBFS on hurd-i386
Thanks for the report. I will look into it the next time I prepare a new version of opensp. On 08/19/2011 06:32 AM, Svante Signell wrote: Package: opensp Version: 1.5.2-9 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, Currently opensp does not compile on GNU/Hurd. The problem is due to the dependency order of openjade versions. With openjade (1.4devel1-20) opensp builds fine while with openjade1.3 (1.3.2-11) it does not. The tiny patch inlined below fixes this issue. --- debian/control.orig 2011-08-19 12:19:41.0 +0200 +++ debian/control 2011-08-19 12:20:38.0 +0200 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Neil Roeth Standards-Version: 3.9.2.0 -Build-Depends: debhelper (>> 7.0.0), dh-buildinfo, xmlto, poppler-utils, openjade1.3 | openjade, jadetex, docbook-dsssl +Build-Depends: debhelper (>> 7.0.0), dh-buildinfo, xmlto, poppler-utils, openjade | openjade1.3, jadetex, docbook-dsssl Package: opensp Architecture: any Thanks, Svante -- Neil Roeth -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#624872: openjade: diff for NMU version 1.4devel1-19.1
That's fine, thanks. I'll merge the changes into the next regular release. On 07/01/2011 01:45 PM, Luk Claes wrote: tags 624872 + pending thanks Dear maintainer, I've prepared an NMU for openjade (versioned as 1.4devel1-19.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#625102: aplus-fsf: patch for the issue
On 06/25/2011 04:34 PM, Andreas Moog wrote: Package: aplus-fsf Version: 4.22.1-4 Followup-For: Bug #625102 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 *** /tmp/tmp1ExG17 In Ubuntu, the attached patch was applied to achieve the following: * src/main/Makefile.am/in: Fix order of arguments to allow building with --as-needed. * src/MSGUI/Makefile.am/in: Include X11 libs when linking * src/MSTypes/MSTypeData.H: Add to headers (LP: #766003) Thanks for considering the patch. Thank you for doing this work. -- Neil Roeth -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#624872: openjade FTBFS with GCC 4.6
Thanks for the report and the work around. At Mon, 02 May 2011 13:36:03 +0200, Matthias Klose wrote: > > Package: openjade > Version: 1.4devel1-19 > Severity: serious > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu oneiric ubuntu-patch > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-4.6 > > the workaround is to build with -fpermissive, although not a proper fix. > http://launchpadlibrarian.net/70913934/openjade_1.4devel1-19build1_1.4devel1-19ubuntu1.diff.gz > -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#624871: jade FTBFS with GCC 4.6
Thanks for the report and the work around. At Mon, 02 May 2011 13:35:37 +0200, Matthias Klose wrote: > > Package: jade > Version: 1.2.1-47 > Severity: serious > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu oneiric ubuntu-patch > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-4.6 > > the workaround is to build with -fpermissive, although not a proper fix. > http://launchpadlibrarian.net/70913863/jade_1.2.1-47build3_1.2.1-47ubuntu1.diff.gz > -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560446: aplus-fsf: FTBFS: MSFloat.C:123: error: invalid conversion from 'const char*' to 'char*'
I wanted to let you know that I am working on this, but I'm running into a strange issue that's holding me up. I reproduced the bug, fixed the C++, rebuilt on my machine and it works fine. However, I then attempted to build the final packages to be uploaded in a pbuilder chroot and the resulting executable segvs during the test suite. Up to date sid in both cases, compared build logs and nothing apparently differs, etc. I'm trying to figure that out now. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560446: aplus-fsf: FTBFS: MSFloat.C:123: error: invalid conversion from 'const char*' to 'char*'
At Fri, 11 Dec 2009 08:52:06 +0100, Lucas Nussbaum wrote: > > Source: aplus-fsf > Version: 4.22.1-3 > Severity: serious > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20091210 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. Thanks, I will take a look. Are you saying that it succeeded on other architectures but FTB only on amd64, or that amd64 was the only architecture that was tried? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531286: unowned files after purge (policy 6.8)
Thanks for the report; I'll fix it. On May 31, Holger Levsen (hol...@layer-acht.org) wrote: > Package: jade > Version: 1.2.1-47 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts piuparts.d.o > > Hi, > > during a test with piuparts I noticed your package left unowned files on the > system after purge, which is a violation of policy 6.8: > > http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails > > From the attached log (scroll to the bottom...): > > 0m32.1s ERROR: FAIL: Package purging left files on system: > /etc/sgml not owned > > > regards, > Holger -- Neil Roeth -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#476049: openjade1.3: FTBFS: /bin/sh: -O2: command not found
On Apr 14, Lucas Nussbaum ([EMAIL PROTECTED]) wrote: > During a rebuild of all packages in sid, your package failed to build on > i386. Thanks, I will take a look. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430287: Bug#430283: ldbl128 transition for alpha, powerpc, sparc, s390
On Jun 23, Matthias Klose ([EMAIL PROTECTED]) wrote: > Package: libostyle-dev > Severity: serious > User: [EMAIL PROTECTED] > Usertags: goal-ldbl128 > > Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html > > With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' > data type did change from a 64bit representation to a 128bit > representation on alpha, powerpc, sparc, s390. To allow > partial upgrades of packages, we will need to rename all > packages holding libraries with the long double data type in > their API. Both libc and libstdc++ do not need to be renamed, > because they support both representations. We rename the library > packages on all architectures to avoid name mismatches between > architectures (you can avoid the renaming by supporting both > datatype representations in the library as done in glibc and > libstdc++, but unless a library is prepared for that, it does not > seem to be worth the effort). > > It is suggested to rename a package libfoo1 to libfoo1ldbl; > please wait with the renaming if the package depends on > another library package which needs renaming. > > This package has been indentified as one with header files in > /usr/include matching 'long *double'. Please close this bug report > if it is a false positive, or rename the package accordingly. I'm kind of confused about this. Two bugs were filed against my packages, both lib*-dev packages, i.e., development libraries. The only reverse depends on them are also lib*-dev packages. If there is an incompatible change in them, can't dependencies just be versioned so that all dependencies are on libraries built with glibc-2.5 and gcc-4.1.2 or above? This doesn't seem to be any different than introducing a new version of a shared library and the corresponding development package - the shared library changes version so packages can be partially upgraded, but the corresponding development packages don't. BTW, the only reference to long double is in config.h for each library, i.e.: $ egrep -i 'long.*double' /usr/include/Open*/* /usr/include/OpenJade/config.h:/* Define if you have the 'long double' type. */ /usr/include/OpenJade/config.h:#define HAVE_LONG_DOUBLE 1 /usr/include/OpenSP/config.h:/* Define if you have the 'long double' type. */ /usr/include/OpenSP/config.h:#define HAVE_LONG_DOUBLE 1 Please let me know what you think. Thanks. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423818: opensp: FTBFS: install: cannot stat `./releasenotes.ps': No such file or directory
On May 14, Michael Ablassmeier ([EMAIL PROTECTED]) wrote: > Package: opensp > Severity: serious > Version: 1.5.2-3 > Justification: policy violation > > hi, > > Lucas has rebuild the archive on i386 and your package Failed to Build > from Source with the following error: > > test -z "/usr/share/doc/OpenSP" || mkdir -p -- > "/build/user/opensp-1.5.2/debian/tmp/usr/share/doc/OpenSP" > install -o root -g root -m 644 -p 'releasenotes.html' > '/build/user/opensp-1.5.2/debian/tmp/usr/share/doc/OpenSP/releasenotes.html' > install -o root -g root -m 644 -p 'releasenotes.pdf' > '/build/user/opensp-1.5.2/debian/tmp/usr/share/doc/OpenSP/releasenotes.pdf' > install -o root -g root -m 644 -p './releasenotes.ps' > '/build/user/opensp-1.5.2/debian/tmp/usr/share/doc/OpenSP/releasenotes.ps' > install: cannot stat `./releasenotes.ps': No such file or directory > make[5]: *** [install-pkgdocDATA] Error 1 > > the full log can be found here: > > > http://people.debian.org/~lucas/logs/2007/05/13/opensp_1.5.2-3_sid32.buildlog > > bye, > - michael I'm having trouble reproducing this. If you look in the log at the part just prior to the errors you provided, you'll see that it executes: /usr/bin/pdf2ps releasenotes.pdf releasenotes.ps which is supposed to convert the PDF file releasenotes.pdf into the Postscript file releasenotes.ps. However, in the log you provided, rather than putting the Postscript in a file, it is getting dumped to stdout or stderr, i.e., it appears in the log. So, the later step where it tries to install releasenotes.ps fails because that files was not created. When I build this package on an up to date sid system, that does not occur, it creates releasenotes.ps just fine. I tried building it three ways: "debian/rules install", dpkg-buildpackage and pdebuild, and all built fine. How exactly was this built, i.e., what utility/commands did Lucas use? -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423818: opensp: FTBFS: install: cannot stat `./releasenotes.ps': No such file or directory
On May 14, Michael Ablassmeier ([EMAIL PROTECTED]) wrote: > Package: opensp > Severity: serious > Version: 1.5.2-3 > Justification: policy violation > > hi, > > Lucas has rebuild the archive on i386 and your package Failed to Build > from Source with the following error: > > test -z "/usr/share/doc/OpenSP" || mkdir -p -- > "/build/user/opensp-1.5.2/debian/tmp/usr/share/doc/OpenSP" > install -o root -g root -m 644 -p 'releasenotes.html' > '/build/user/opensp-1.5.2/debian/tmp/usr/share/doc/OpenSP/releasenotes.html' > install -o root -g root -m 644 -p 'releasenotes.pdf' > '/build/user/opensp-1.5.2/debian/tmp/usr/share/doc/OpenSP/releasenotes.pdf' > install -o root -g root -m 644 -p './releasenotes.ps' > '/build/user/opensp-1.5.2/debian/tmp/usr/share/doc/OpenSP/releasenotes.ps' > install: cannot stat `./releasenotes.ps': No such file or directory > make[5]: *** [install-pkgdocDATA] Error 1 > > the full log can be found here: > > > http://people.debian.org/~lucas/logs/2007/05/13/opensp_1.5.2-3_sid32.buildlog > > bye, > - michael Thanks, I'll find out what broke. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398832: xfonts-kapl: postrm purge fails: fc-cache: command not found
On Nov 15, Lucas Nussbaum ([EMAIL PROTECTED]) wrote: > Package: xfonts-kapl > Version: 4.20.2-4 > Severity: serious > Usertags: grid5000 > > Hi, > > During a piuparts run over all the packages in etch, I ran into a > problem with your package: > Removing xfonts-kapl ... > Purging configuration files for xfonts-kapl ... > /var/lib/dpkg/info/xfonts-kapl.postrm: line 12: fc-cache: command not > found > dpkg: error processing xfonts-kapl (--purge): >subprocess post-removal script returned error exit status 127 > > The full log is available from > http://ox.blop.info/bazaar/buildlogs/20061115/ Thanks. It appears from a quick glance that the package should execute this command in a prerm instead of a postrm script. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383772: openjade: FTBFS: cmp error, License is not GPL-2
On Aug 19, Julien Danjou ([EMAIL PROTECTED]) wrote: > Package: openjade > Version: 1.4devel1-16 > Severity: serious > > Hello, > > There was a problem while autobuilding your package: > > > Automatic build of openjade_1.4devel1-16 on avidan by sbuild/i386 0.49 > > Build started at 20060819-1338 > > ** > ... > > make[1]: Leaving directory `/build/buildd/openjade-1.4devel1' > > touch install-stamp > > cmp -s COPYING /usr/share/common-licenses/GPL-2 || \ > >(echo "License is not GPL-2" && false) > > License is not GPL-2 > > make: *** [debian/copyright] Error 1 > > ** > > Build finished at 20060819-1350 > > FAILED [dpkg-buildpackage died] > > -- > > Kinda funny. Thanks. I'll fix it soon. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376222: dovecot-common: dovecot dies immediately
>From the strace output I just sent, it appears that the child process is failing to find the function epoll_create(), which a quick Google shows is a function introduced in Linux kernel 2.5.44. I suppose it's relevant that I am running a 2.4 kernel. :-) -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376222: dovecot-common: dovecot dies immediately
On Jul 2, Fabio Tranchitella ([EMAIL PROTECTED]) wrote:
> On sab, 01 lug 2006, Neil Roeth wrote:
>
> Content-Description: message body text
> > strace output is attached.
>
> Hi Neil,
> could you please run again strace with the "-f" switch, in order to trace
> the child process too?
Sure, attached.
execve("/usr/sbin/dovecot", ["/usr/sbin/dovecot"], [/* 26 vars */]) = 0
uname({sys="Linux", node="ml330", ...}) = 0
brk(0) = 0x8067ffc
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40017000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=34292, ...}) = 0
mmap2(NULL, 34292, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220T\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1177116, ...}) = 0
mmap2(NULL, 1186964, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x40021000
mmap2(0x40139000, 32768, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x117) = 0x40139000
mmap2(0x40141000, 7316, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40141000
close(3)= 0
mprotect(0x40139000, 20480, PROT_READ) = 0
munmap(0x40018000, 34292) = 0
time(NULL) = 1151842963
brk(0) = 0x8067ffc
brk(0x8088ffc) = 0x8088ffc
brk(0x8089000) = 0x8089000
uname({sys="Linux", node="ml330", ...}) = 0
getpid()= 18815
geteuid32() = 0
open("/etc/dovecot/dovecot.conf", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=39348, ...}) = 0
pread64(3, "## Dovecot configuration file\n\n#"..., 2048, 0) = 2048
pread64(3, "fix). This however\n# means that "..., 1992, 2048) = 1992
pread64(3, "bout permissions. Note that\n# ev"..., 2001, 4040) = 2001
pread64(3, "m number of users\n# logging in a"..., 1988, 6041) = 1988
pread64(3, "is simply done by having a\n# nam"..., 2000, 8029) = 2000
pread64(3, "ped = yes.\n#mail_read_mmaped = n"..., 1979, 10029) = 1979
pread64(3, "retty high.\n#mail_process_size ="..., 1986, 12008) = 1986
pread64(3, "them.\n#\n# Usually you should jus"..., 2030, 13994) = 2030
pread64(3, "e.\n# If you care about performan"..., 1971, 16024) = 1971
pread64(3, "irty_syncs = no\n\n# Delay writing"..., 2036, 17995) = 2036
pread64(3, "ary for\n # clients to request i"..., 1978, 20031) = 1978
pread64(3, " it doesn\'t move files\n # from "..., 1996, 22009) = 1996
pread64(3, " plugins. mail_plugins is a spac"..., 2012, 24005) = 2012
pread64(3, "Note that bsdauth, PAM and vpopm"..., 2046, 26017) = 2046
pread64(3, "rator character here. The format"..., 2005, 28063) = 2005
pread64(3, "the destination user to be looke"..., 2020, 30068) = 2020
pread64(3, "ervice (ie. IMAP, POP3) must mat"..., 2019, 32088) = 2019
pread64(3, " static settings generated from "..., 2045, 34107) = 2045
pread64(3, "ssible to export the authenticat"..., 2037, 36152) = 2037
pread64(3, "n. Multiple backends are support"..., 2033, 38189) = 1159
pread64(3, "", 874, 39348) = 0
close(3)= 0
socket(PF_FILE, SOCK_STREAM, 0) = 3
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT
(No such file or directory)
close(3)= 0
socket(PF_FILE, SOCK_STREAM, 0) = 3
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT
(No such file or directory)
close(3)= 0
open("/etc/nsswitch.conf", O_RDONLY)= 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40018000
read(3, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 465
read(3, "", 4096) = 0
close(3)= 0
munmap(0x40018000, 4096)
Bug#376222: dovecot-common: dovecot dies immediately
) = -1 EEXIST (File exists)
lstat64("/var/run/dovecot/login", {st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
open("/var/run/dovecot/login", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
close(3)= 0
lstat64("/var/run/dovecot/login", {st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
open("/var/run/dovecot/login", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 3 entries */, 4096)= 88
lstat64("/var/run/dovecot/login/ssl-parameters.dat", {st_mode=S_IFREG|0644,
st_size=230, ...}) = 0
getdents64(3, /* 0 entries */, 4096)= 0
close(3)= 0
access("/usr/lib/dovecot/pop3-login", X_OK) = 0
open("/etc/passwd", O_RDONLY) = 3
fcntl64(3, F_GETFD) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
_llseek(3, 0, [0], SEEK_CUR)= 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=1639, ...}) = 0
mmap2(NULL, 1639, PROT_READ, MAP_SHARED, 3, 0) = 0x40018000
_llseek(3, 1639, [1639], SEEK_SET) = 0
munmap(0x40018000, 1639)= 0
close(3)= 0
access("/usr/lib/dovecot/dovecot-auth", X_OK) = 0
open("/dev/null", O_RDONLY|O_LARGEFILE) = 3
fcntl64(3, F_GETFD) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
dup(3) = 4
fcntl64(4, F_GETFD) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(5, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
bind(5, {sa_family=AF_INET, sin_port=htons(143),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
getsockname(5, {sa_family=AF_INET, sin_port=htons(143),
sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
listen(5, 8)= 0
fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fcntl64(5, F_GETFD) = 0
fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6
setsockopt(6, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(6, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
bind(6, {sa_family=AF_INET, sin_port=htons(993),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
getsockname(6, {sa_family=AF_INET, sin_port=htons(993),
sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
listen(6, 8)= 0
fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fcntl64(6, F_GETFD) = 0
fcntl64(6, F_SETFD, FD_CLOEXEC) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7
setsockopt(7, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(7, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
bind(7, {sa_family=AF_INET, sin_port=htons(110),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
getsockname(7, {sa_family=AF_INET, sin_port=htons(110),
sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
listen(7, 8)= 0
fcntl64(7, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(7, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fcntl64(7, F_GETFD) = 0
fcntl64(7, F_SETFD, FD_CLOEXEC) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 8
setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(8, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
bind(8, {sa_family=AF_INET, sin_port=htons(995),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
getsockname(8, {sa_family=AF_INET, sin_port=htons(995),
sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
listen(8, 8)= 0
fcntl64(8, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(8, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fcntl64(8, F_GETFD) = 0
fcntl64(8, F_SETFD, FD_CLOEXEC) = 0
dup2(4, 0) = 0
dup2(4, 1) = 1
dup2(4, 2) = 2
fork() = 10845
--- SIGCHLD (Child exited) @ 0 (0) ---
exit_group(0) = ?
Process 10844 detached
[EMAIL PROTECTED]:/etc/init.d#
--
Neil Roeth
Bug#376222: dovecot-common: dovecot dies immediately
On Jun 30, Jaldhar H. Vyas ([EMAIL PROTECTED]) wrote: > On Fri, 30 Jun 2006, Neil Roeth wrote: > > > > > Thanks for the quick response. > > > > I see this in /tmp/dovecot.log, which is what I had log_path set to in > > dovecot.conf for a while: > > > > dovecot: 2006-06-28 23:02:29 Error: IMAP([EMAIL PROTECTED]): utimes() > > failed with mbox file /var/mail/virtual_mailboxes/athenamontes > > sori.org/neil/inbox: Operation not permitted > > > > but I think that is unrelated, I got the same message the day before in > > /var/log/mail/mail.warn, when everything was working fine. > > > > In /var/log/syslog, I had just this: > > > > Jun 28 20:56:56 ml330 dovecot: Killed with signal 15 > > > > which corresponds to the old version being killed as the new version was > > being > > installed. > > > > > > can you run an strace on /usr/sbin/dovecot and tell me the results? > Are you sure there is nothing else listening on TCP port 143? I'll do the strace and get back to you. I did do "telnet localhost 143" originally and got back a connection refused error (from telnet, not dovecot) so I believe nothing else was listening on port 143. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376222: dovecot-common: dovecot dies immediately
On Jun 30, Jaldhar H. Vyas ([EMAIL PROTECTED]) wrote: > On Fri, 30 Jun 2006, Neil Roeth wrote: > > > Package: dovecot-common > > Version: 1.0.rc1-1 > > Severity: grave > > File: /usr/sbin/dovecot > > > > I upgraded from 1.0beta9-1 to 1.0rc1-1, and was immediately unable to > > contact > > the IMAP server. I tried starting it by hand, both by executing > > "/etc/init.d/dovecot start" as well as by running start-stop-daemon by > > hand, > > with no luck. I checked if /usr/sbin/dovecot was running, and it was not. > > I > > synced up my dovecot.conf with the one from the package as much as possible > > without changing what I needed, and that didn't help (it took a while, too, > > since that file appears to have undergone a gratuitous reshuffling of the > > contents). I also attempted to change the config file to turn on various > > bits > > of logging, but that did not help, it did not get that far. I found that > > no > > matter what, /usr/sbin/dovecot just does not run at all. Downgrading back > > to > > 1.0beta9-1 resolved the problem. > > > > What if anything do the logs say? Thanks for the quick response. I see this in /tmp/dovecot.log, which is what I had log_path set to in dovecot.conf for a while: dovecot: 2006-06-28 23:02:29 Error: IMAP([EMAIL PROTECTED]): utimes() failed with mbox file /var/mail/virtual_mailboxes/athenamontes sori.org/neil/inbox: Operation not permitted but I think that is unrelated, I got the same message the day before in /var/log/mail/mail.warn, when everything was working fine. In /var/log/syslog, I had just this: Jun 28 20:56:56 ml330 dovecot: Killed with signal 15 which corresponds to the old version being killed as the new version was being installed. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376222: dovecot-common: dovecot dies immediately
Package: dovecot-common Version: 1.0.rc1-1 Severity: grave File: /usr/sbin/dovecot I upgraded from 1.0beta9-1 to 1.0rc1-1, and was immediately unable to contact the IMAP server. I tried starting it by hand, both by executing "/etc/init.d/dovecot start" as well as by running start-stop-daemon by hand, with no luck. I checked if /usr/sbin/dovecot was running, and it was not. I synced up my dovecot.conf with the one from the package as much as possible without changing what I needed, and that didn't help (it took a while, too, since that file appears to have undergone a gratuitous reshuffling of the contents). I also attempted to change the config file to turn on various bits of logging, but that did not help, it did not get that far. I found that no matter what, /usr/sbin/dovecot just does not run at all. Downgrading back to 1.0beta9-1 resolved the problem. Let me know if there is anything else you'd like me to try. Thanks. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.19 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- no debconf information -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366512: ted: Fails to display file
On May 9, Steve Langasek ([EMAIL PROTECTED]) wrote: > On Tue, May 09, 2006 at 09:29:20PM -0400, Neil Roeth wrote: > > On May 9, Chris Waters ([EMAIL PROTECTED]) wrote: > > > Hmm, it seems to be complaining that it can't find anything to use as > > > a Helvetica font for that document. What happens if you do: > > > > > > xlsfont | grep -i helvetica > > > Thanks for looking into this. Here's the requested output: > > > -adobe-helvetica-bold-o-normal--0-0-100-100-p-0-iso10646-1 > > -adobe-helvetica-bold-o-normal--0-0-100-100-p-0-iso10646-1 > > -adobe-helvetica-bold-o-normal--0-0-100-100-p-0-iso8859-1 > > -adobe-helvetica-bold-o-normal--0-0-100-100-p-0-iso8859-1 > > > > > The major font-related thing I did recently was switching to the new X11R7 > > scheme where all fonts are in /usr/share/fonts/X11 rather than > > /usr/X11R6/lib/X11/fonts. > > Is there any chance that bug #365403 is relevant to this case? It does sound possible. I will do the symlinking or install the updated package and see if that cures the problem (later today, no time at the moment). -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366512: ted: Fails to display file
m-o-normal--25-180-100-100-p-130-iso10646-1 -adobe-helvetica-medium-o-normal--25-180-100-100-p-130-iso8859-1 -adobe-helvetica-medium-o-normal--25-180-100-100-p-130-iso8859-1 -adobe-helvetica-medium-o-normal--34-240-100-100-p-176-iso10646-1 -adobe-helvetica-medium-o-normal--34-240-100-100-p-176-iso10646-1 -adobe-helvetica-medium-o-normal--34-240-100-100-p-176-iso8859-1 -adobe-helvetica-medium-o-normal--34-240-100-100-p-176-iso8859-1 -adobe-helvetica-medium-o-normal--8-80-75-75-p-47-iso10646-1 -adobe-helvetica-medium-o-normal--8-80-75-75-p-47-iso10646-1 -adobe-helvetica-medium-o-normal--8-80-75-75-p-47-iso8859-1 -adobe-helvetica-medium-o-normal--8-80-75-75-p-47-iso8859-1 -adobe-helvetica-medium-r-normal--0-0-100-100-p-0-iso10646-1 -adobe-helvetica-medium-r-normal--0-0-100-100-p-0-iso10646-1 -adobe-helvetica-medium-r-normal--0-0-100-100-p-0-iso8859-1 -adobe-helvetica-medium-r-normal--0-0-100-100-p-0-iso8859-1 -adobe-helvetica-medium-r-normal--0-0-75-75-p-0-iso10646-1 -adobe-helvetica-medium-r-normal--0-0-75-75-p-0-iso10646-1 -adobe-helvetica-medium-r-normal--0-0-75-75-p-0-iso8859-1 -adobe-helvetica-medium-r-normal--0-0-75-75-p-0-iso8859-1 -adobe-helvetica-medium-r-normal--10-100-75-75-p-56-iso10646-1 -adobe-helvetica-medium-r-normal--10-100-75-75-p-56-iso10646-1 -adobe-helvetica-medium-r-normal--10-100-75-75-p-56-iso8859-1 -adobe-helvetica-medium-r-normal--10-100-75-75-p-56-iso8859-1 -adobe-helvetica-medium-r-normal--11-80-100-100-p-56-iso10646-1 -adobe-helvetica-medium-r-normal--11-80-100-100-p-56-iso10646-1 -adobe-helvetica-medium-r-normal--11-80-100-100-p-56-iso8859-1 -adobe-helvetica-medium-r-normal--11-80-100-100-p-56-iso8859-1 -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso10646-1 -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso10646-1 -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1 -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1 -adobe-helvetica-medium-r-normal--14-100-100-100-p-76-iso10646-1 -adobe-helvetica-medium-r-normal--14-100-100-100-p-76-iso10646-1 -adobe-helvetica-medium-r-normal--14-100-100-100-p-76-iso8859-1 -adobe-helvetica-medium-r-normal--14-100-100-100-p-76-iso8859-1 -adobe-helvetica-medium-r-normal--14-140-75-75-p-77-iso10646-1 -adobe-helvetica-medium-r-normal--14-140-75-75-p-77-iso10646-1 -adobe-helvetica-medium-r-normal--14-140-75-75-p-77-iso8859-1 -adobe-helvetica-medium-r-normal--14-140-75-75-p-77-iso8859-1 -adobe-helvetica-medium-r-normal--17-120-100-100-p-88-iso10646-1 -adobe-helvetica-medium-r-normal--17-120-100-100-p-88-iso10646-1 -adobe-helvetica-medium-r-normal--17-120-100-100-p-88-iso8859-1 -adobe-helvetica-medium-r-normal--17-120-100-100-p-88-iso8859-1 -adobe-helvetica-medium-r-normal--18-180-75-75-p-98-iso10646-1 -adobe-helvetica-medium-r-normal--18-180-75-75-p-98-iso10646-1 -adobe-helvetica-medium-r-normal--18-180-75-75-p-98-iso8859-1 -adobe-helvetica-medium-r-normal--18-180-75-75-p-98-iso8859-1 -adobe-helvetica-medium-r-normal--20-140-100-100-p-100-iso10646-1 -adobe-helvetica-medium-r-normal--20-140-100-100-p-100-iso10646-1 -adobe-helvetica-medium-r-normal--20-140-100-100-p-100-iso8859-1 -adobe-helvetica-medium-r-normal--20-140-100-100-p-100-iso8859-1 -adobe-helvetica-medium-r-normal--24-240-75-75-p-130-iso10646-1 -adobe-helvetica-medium-r-normal--24-240-75-75-p-130-iso10646-1 -adobe-helvetica-medium-r-normal--24-240-75-75-p-130-iso8859-1 -adobe-helvetica-medium-r-normal--24-240-75-75-p-130-iso8859-1 -adobe-helvetica-medium-r-normal--25-180-100-100-p-130-iso10646-1 -adobe-helvetica-medium-r-normal--25-180-100-100-p-130-iso10646-1 -adobe-helvetica-medium-r-normal--25-180-100-100-p-130-iso8859-1 -adobe-helvetica-medium-r-normal--25-180-100-100-p-130-iso8859-1 -adobe-helvetica-medium-r-normal--34-240-100-100-p-176-iso10646-1 -adobe-helvetica-medium-r-normal--34-240-100-100-p-176-iso10646-1 -adobe-helvetica-medium-r-normal--34-240-100-100-p-176-iso8859-1 -adobe-helvetica-medium-r-normal--34-240-100-100-p-176-iso8859-1 -adobe-helvetica-medium-r-normal--8-80-75-75-p-46-iso10646-1 -adobe-helvetica-medium-r-normal--8-80-75-75-p-46-iso10646-1 -adobe-helvetica-medium-r-normal--8-80-75-75-p-46-iso8859-1 -adobe-helvetica-medium-r-normal--8-80-75-75-p-46-iso8859-1 I grepped for helvetica in the various fonts.alias files, and found it in none. I noticed that the "variable" font was a helvetica font, so I created an xfonts.alias file in the /etc/X11/fonts/X11R7/misc directory that had an entry with the work "variable" substituted by "Helvetica" (and "helvetica"), ran update-fonts-alias and update-fonts-dir, but that did nothing. I made a copy of TedDocument-en_US.rtf and changed all the font definitions to variable, and tried opening that - still no luck. The major font-related thing I did recently was switching to the new X11R7 scheme where all fonts are in /usr/share/fonts/X11 rather than /usr/X11R6/lib/X11/fonts. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366512: ted: Fails to display file
Package: ted Version: 2.17-1 Severity: grave Starting Ted like so: $ ted /usr/share/ted/Ted/TedDocument-en_US.rtf makes the initial screen pop up, but the file that I am trying to edit does not. Since I cannot even see the document I am trying to edit, much less edit it, I consider that unuseable. The following messages appear in the xterm from which I started Ted: appFont.c(812) aff->affFontFamilyName="Helvetica" afe->afeXfontFamilies=0x0 appFont.c(813) encoding=8 PS_Encodings[encoding].fcX11Registry="iso8859" appFont.c(814) encoding=8 PS_Encodings[encoding].fcX11Encoding="15" appFont.c() psf->affFontFamilyName="Helvetica" dsf->apfFontEncoding=8 appFont.c(1167) 1=1 tedLayout.c(995) attributeNumber=0 sfl->sflAttributeToScreen[attributeNumber]=-1 tedLayout.c(1022) part=0 textAttr=0 tedLayout.c(852) 1=1 docLayoutParagraphs.c( 82) 1=1 docLayoutParagraphs.c(142) 1=1 docLayoutParagraphs.c(494) 1=1 docLayout.c(825) 1=1 docLayout.c(805) 1=1 docLayout.c(805) 1=1 docLayoutExternalItem.c(219) 1=1 docLayout.c(716) 1=1 docLayout.c(797) 1=1 docLayout.c(932) 1=1 tedLayout.c(1071) 1=1 tedPage.c(332) 1=1 tedDocument.c(571) 1=1 appDocument.c(579) ed->edFilename="/usr/share/ted/Ted/TedDocument-en_US.rtf" appDocument.c(752) filename="/usr/share/ted/Ted/TedDocument-en_US.rtf" I get the same behavior and the same messages in the xterm when I try to open a file from the File/Open menu item on the initial screen. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.19 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages ted depends on: ii lesstif2 1:0.94.4-1.1+b2 OSF/Motif 2.1 implementation relea ii libc62.3.6-7 GNU C Library: Shared libraries ii libice6 1:1.0.0-3 X11 Inter-Client Exchange library ii libjpeg626b-12 The Independent JPEG Group's JPEG ii libpng12-0 1.2.8rel-5.1PNG library - runtime ii libsm6 1:1.0.0-4 X11 Session Management library ii libtiff4 3.8.2-1 Tag Image File Format (TIFF) libra ii libx11-6 2:1.0.0-6 X11 client-side library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxp6 1:1.0.0-1 X Printing Extension (Xprint) clie ii libxpm4 1:3.5.4.2-3 X11 pixmap library ii libxt6 1:1.0.0-4 X11 toolkit intrinsics library ii ted-common 2.17-1 common files used by ted and ted-g ii xlibs6.9.0.dfsg.1-6 X Window System client libraries m ii zlib1g 1:1.2.3-11 compression library - runtime ted recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361864: segfaults in OpenSP::ParsedSystemId::unparse
On Apr 10, Filipus Klutiero ([EMAIL PROTECTED]) wrote: > Package: openjade1.3 > Version: 1.3.2-9 > Severity: grave > Justification: renders package unusable > > Both openjade1.3 and openjade segfault when called with the example > usage in "Using OpenJade" from the documentation index. The first > openjade command I tried segfaulted, and I didn't find any command that > didn't segfault. > This problem reproduces apparently everytime on 3 Etch boxes on the 3 I > tested: > > $ openjade1.3 /usr/share/doc/openjade/demo.sgm > Erreur de segmentation The documentation assumes that the OpenSP executable was built with either /usr/share/doc/openjade or . on the default search path, and neither is in the Debian build. The command works if you either copy demo.dsl to /usr/share/sgml or /usr/local/share/sgml, or if you explicitly specify it on the command line, e.g., openjade -d /usr/share/doc/openjade/demo.dsl /usr/share/doc/openjade/demo.sgm I'll fix the documentation in the upstream source so this is clear, and change this bug to minor. Since the program should not segfault in any case, I am going to reassign this bug to opensp and make it a normal severity bug there. Thanks for the report. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#170795: fixed in opensp 1.5.2-1
On Feb 11, Steinar H. Gunderson ([EMAIL PROTECTED]) wrote: > On Sat, Feb 11, 2006 at 09:11:36AM -0500, Neil Roeth wrote: > > (2) Explicitly specify it on the command line, e.g., > > > > onsgmls -s /usr/share/xml/declaration/xml.dcl foo.xml > > That's odd, I do: > > my $cmd = "/usr/bin/onsgmls -s -n -c > /usr/share/w3c-markup-validator/catalog/xml.soc -wxml <$sp_in 2>$sp_err"; > > and it's failing consistently. Why is that odd? There is no SGML declaration specified on your command line, you are specifying the catalog xml.soc rather than relying on the default catalog, so onsgmls will look for DTDDECL entries in xml.soc or any catalogs referenced within that. This is similar to what I did while debugging this: I created a small catalog that had just the entries needed to reproduce the problem, and called onsgmls like this: ./onsgmls -s -c ./catalog < test.html on the test.html attached to the bug report. > Apart from that, I think I understand the issues at least partially now; > thanks :-) You're welcome, glad to help. I learned all this since picking up maintenance of the package, it's been an educating experience for me. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#170795: fixed in opensp 1.5.2-1
On Feb 10, Steinar H. Gunderson ([EMAIL PROTECTED]) wrote: > On Fri, Feb 10, 2006 at 07:44:23AM -0500, Neil Roeth wrote: > > Correct on both counts: it would be just "pushing it ahead", and I am > > reluctant at this time to turn off DTDDECL in stable, because that is > > removing > > behavior, though the longer the package remains in unstable with DTDDECL > > handling turned off and no complaints, the less reluctant I will be to make > > the corresponding change in stable. > > What does the DTDDECL thing _do_, BTW? I don't think I've gotten to that part > yet :-) An SGML declaration defines the syntax of SGML used in the document, down to what characters are allowed, capacities, case sensitivity, etc. This is how the rules for XML and HTML are specified. It basically specifies the syntax of elements, while the DTD specifies the structure of the document in terms of elements. There are three ways to determine the SGML decaration to use: (1) Use the default implied SGML declaration built into OpenSP. (2) Explicitly specify it on the command line, e.g., onsgmls -s /usr/share/xml/declaration/xml.dcl foo.xml (3) Use one implied by the DTD of the document and a DTDDECL entry in the SGML catalog. This entry means that if using the specified DTD, use the corresponding SGML declaration. The test document in this case does use a DTD that has a DTDDECL catalog entry in the catalog, so it is trying to use that SGML declaration to parse the document. One difference between this way of finding an SGML declaration and the other two is that the document has to be parsed once to some extent in order to find its DTD and then that DTD has to be used to find any corresponding DTDDECL entries. Conceptually, you could do a first pass over the document to find the DTD, find any DTDDECL entries, read the corresponding SGML declaration, then make a second pass over the document with the new SGML declaration. I think it is this multipass requirement of DTDDECL handling that is causing this bug. > But will a workaround for this be to simply use a temporary file instead of > reading from a pipe? I guess I can do that, I don't need the validation in > production code... Yes, that will work. A temporary file has no problem being reread. You could also pipe the SGML declaration before the document, e.g. cat /usr/share/sgml/html/dtd/4.01/HTML4.decl test8k.html | onsgmls -s I think an explicit SGML declaration passed to OpenSP tells it to skip looking for one any other way. If you know what SGML declaration to use, that's fine; the trick is that it depends on the DTD of the document, and figuring out the SGML declaration that corresponds to the DTD of the document is the whole point of the DTDDECL handling that is causing this bug! HTH -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350797: openjade: Fails on entity definitions in xml-iso-entities-*
On Feb 1, Frans Pop ([EMAIL PROTECTED]) wrote: > severity 350797 minor > thanks > > Thanks for your quick reaction. > > On Wednesday 01 February 2006 04:26, you wrote: > > The problem is that in order to resolve a long standing performance > > problem, I turned off DTDDECL handling in the the libosp5 package on > > which openjade depends. What this means is that you need to explicitly > > specify the XML declaration before the document: > > > > /usr/bin/openjade -t tex -b utf-8 -o build.tmp/install.en.tex \ > >-d > > /home/fjp/projects/manual-build/manual/build/stylesheets/style-print.dsl \ > >-V tex-backend declaration/xml.dcl build.tmp/install.en.profiled.xml > > ^^^ > > This works for me. Great. > > This is a reversion back to an older (pre-Sarge) form of the command. > > I think this is a small price to pay for the huge performance gain (a > > factor of 10-20), but let me know if it is not an option for you; if > > so, I'll consider reinstating the behavior as it was in Sarge. > > Please consider documenting this change in NEWS.Debian with your next upload. > Leaving the report open for that. Good idea, will do. > The performance gain is indeed impressive. Here are some results for the > Installation Guide: > > $ time ./buildone.sh i386 en pdf > Info: creating temporary profiled .xml file... > Info: creating temporary .tex file... > Info: creating temporary .dvi file... > Info: creating .pdf file... > > real0m45.286s > user0m43.041s > sys 0m2.427s > > > > $ time ./buildone.sh i386 en pdf > Info: creating temporary profiled .xml file... > Info: creating temporary .tex file... > Info: creating temporary .dvi file... > Info: creating .pdf file... > > real0m24.491s > user0m24.252s > sys 0m0.451s That's only a factor of two, not 10-20 that I've seen; I'm glad you think that is "impressive"! :-) -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350797: openjade: Fails on entity definitions in xml-iso-entities-*
The problem is that in order to resolve a long standing performance problem, I turned off DTDDECL handling in the the libosp5 package on which openjade depends. What this means is that you need to explicitly specify the XML declaration before the document: /usr/bin/openjade -t tex -b utf-8 -o build.tmp/install.en.tex \ -d /home/fjp/projects/manual-build/manual/build/stylesheets/style-print.dsl \ -V tex-backend declaration/xml.dcl build.tmp/install.en.profiled.xml ^^^ This is a reversion back to an older (pre-Sarge) form of the command. I think this is a small price to pay for the huge performance gain (a factor of 10-20), but let me know if it is not an option for you; if so, I'll consider reinstating the behavior as it was in Sarge. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#170795: fixed in opensp 1.5.2-1
On Jan 17, Steinar H. Gunderson ([EMAIL PROTECTED]) wrote: > On Sun, Jan 08, 2006 at 12:46:37PM -0500, Neil Roeth wrote: > > Thanks for digging into this and finding that the bug still exists if > > --disable-dtddecl is dropped. I'll also keep looking into it and see what I > > can find. > > Any progress on this? No. Unfortunately, my time is limited, so it might take a while. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#170795: fixed in opensp 1.5.2-1
On Jan 8, Steinar H. Gunderson ([EMAIL PROTECTED]) wrote: > On Sat, Jan 07, 2006 at 11:05:59PM +0100, Steinar H. Gunderson wrote: > > I have no idea what the resolution would be, but this should IMHO be fixed > > in > > stable; onsgmls is rather broken as long as it can't read properly from a > > line-buffered pipe. :-) > > I've debugged this a bit, even though I have a hard time grokking opensp's > insanely complex input layer (stdio or iostreams was obviously too standard). > > The bug seems to manifest itself if and only if a tag spans two read() > buffers, like this imaginary strace fragment: > > read(0, "(data here)", 4096) = 4096 > read(0, "(more data)", 4096) = 512 > > This explains the different behaviour with regard to stdin redirection, pipes > etc. -- opensp simply uses different block sizes in those cases (4kB vs. 8kB > vs. 32kB, AFAICS). > > You're right in that 1.5.2 fixes the problem, but it might be by accident -- > if I compile it on sarge it works, but if I drop --disable-dtddecl the bug is > back again. > > FWIW, I've run it through valgrind, but can't find any errors. Thanks for digging into this and finding that the bug still exists if --disable-dtddecl is dropped. I'll also keep looking into it and see what I can find. As for the "insanely complex input layer" and "standard" - this code was probably written a decade ago, so my guess is that what is standard now might not even have existed in most C++ compilers back then. :-) -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346185: jade: FTBFS with new make
On Jan 6, Daniel Schepler ([EMAIL PROTECTED]) wrote:
> Package: jade
> Severity: serious
> Version: 1.2.1-45
> Tags: patch
>
> Because of changes in recent versions of make for Posix compliance,
> the jade package now fails to build with:
>
> ...
> echo "libsp1c2:Version=libsp1c2 (= 1.3.4-1.2.1-45)" \
> >> debian/libsp1-dev.substvars
> sed -e 's|%{default-catalogs}|/etc/sgml/catalog|; \
>
> s|%{default-sgml-path}|/usr/local/share/sgml:/usr/share/sgml|; \
> s|%{sgmldir}|/usr/share/sgml|;' \
> debian/README.Debian.in > debian/README.Debian
> sed: -e expression #1, char 143: unterminated address regex
> make: *** [binary-arch] Error 1
>
> I've attached a patch which fixes this failure for me.
Thanks, I'll fix it soon.
--
Neil Roeth
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346151: openjade1.3: fails to build with make >= 3.80+3.81.b3-1
On Jan 5, Colin Watson ([EMAIL PROTECTED]) wrote:
> Package: openjade1.3
> Version: 1.3.2-8
> Severity: serious
>
> The multi-line sed expression in openjade1.3's debian/rules fails with
> make >= 3.80+3.81.b3-1, because of the backward-incompatible change in
> backslash-newline processing made in that version for POSIX
> compatibility:
>
> sed -e 's|%{default-catalogs}|/etc/sgml/catalog|; \
>
> s|%{default-sgml-path}|/usr/local/share/sgml:/usr/share/sgml|; \
> s|%{sgmldir}|/usr/share/sgml|;' \
> debian/README.Debian.in > debian/README.Debian
> sed: -e expression #1, char 143: unterminated address regex
> make: *** [binary-arch] Error 1
>
> The attached patch fixes this by using multiple sed -e arguments.
>
> (It's also worth noting that you have %{sgmldir} in the sed expression,
> but debian/README.Debian.in uses %{sgml-dir}.)
>
> Cheers,
>
> --
> Colin Watson [EMAIL PROTECTED]
> diff -u openjade1.3-1.3.2/debian/rules openjade1.3-1.3.2/debian/rules
> --- openjade1.3-1.3.2/debian/rules
> +++ openjade1.3-1.3.2/debian/rules
> @@ -108,9 +108,9 @@
> cat COPYING debian/copyright.Debian > debian/copyright
>
> #substitution in README.Debian
> -sed -e 's|%{default-catalogs}|$(default-catalogs)|; \
> -s|%{default-sgml-path}|$(default-sgml-path)|; \
> -s|%{sgmldir}|$(sgmldir)|;' \
> +sed -e 's|%{default-catalogs}|$(default-catalogs)|;'\
> +-e 's|%{default-sgml-path}|$(default-sgml-path)|;' \
> +-e 's|%{sgmldir}|$(sgmldir)|;' \
> debian/README.Debian.in > debian/README.Debian
>
> ##
Thanks, I'll take care of these.
--
Neil Roeth
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#321543: ICE
While trying to rebuild the openjade package against the new opensp package, I got an internal compiler error. I am in the process of submitting a bug report for that and investigating if I can make some changes in the code to work around that error. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#321543: openjade: uninstallable due to missing libosp4
On Aug 6, Chris Hanson ([EMAIL PROTECTED]) wrote: > Package: openjade > Version: 1.4devel1-13 > Severity: grave > Tags: sid > > Please recompile to update dependency. I'm working on it, thanks. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318361: Upload?
On Aug 5, Frank Lichtenheld ([EMAIL PROTECTED]) wrote: > Hi. > > On July, 15th you acknowledged this bug and the patch. Is there any > problem that makes it unfeasable to upload a new package with this > patch? No problem, just lack of time and the fact that since my other packages are more widely used, I was concentrating on them. I'll try to get it done this weekend. Thanks for the reminder. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#321084: jade FTBFS on hppa
On Aug 3, Matthias Klose ([EMAIL PROTECTED]) wrote: > Package: jade > Version: 1.2.1-44 > Severity: serious > > see the buildd logs. > > looks like it builds ok with g++-3.4 on hppa. Thanks, I was just preparing a new version with the fix for your last bug (320445). I'll make it use g++-3.4 on hppa. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318361: FTBFS: Declarations without types
On Jul 14, Matt Kraai ([EMAIL PROTECTED]) wrote: > Package: aplus-fsf > Version: 4.18.8-11 > Severity: serious > Tags: patch > > aplus-fsf fails to build because some declarations do not have types: > > > The attached patch fixes this problem by declaring the types before > they are used. > Thanks for finding this and for the patch. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310763: jade problem with gnupg-doc (#310763)
On Jun 1, Roger Leigh ([EMAIL PROTECTED]) wrote: > I'm not the maintainer of the package (it's maintained by James > Troup), so this is to let him know of your offer, which I'm sure will > be well appreciated! > > > Many thanks for all your work, > Roger You're welcome, glad to help. James, the ball is in your court - I'm willing to work on improving the package post-Sarge. Just let me know. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298163: FTBFS in experimental
On Mar 12, Neil Roeth ([EMAIL PROTECTED]) wrote:
> On Mar 12, Frank Lichtenheld ([EMAIL PROTECTED]) wrote:
> > On Sat, Mar 05, 2005 at 09:39:44AM +0100, Andreas Barth wrote:
> > > docbook2pdf local-fontconfig-user.sgml
> > > Using catalogs: /etc/sgml/catalog
> > > Using stylesheet: /usr/share/docbook-utils/docbook-utils.dsl#print
> > > Working on:
> /build/buildd/fontconfig-2.3.0/doc/local-fontconfig-user.sgml
> > >
> openjade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/print/dbrfntry.dsl:83:3:E:
> flow objects at the root must be all of class scroll or all of class
> page-sequence or simple-page-sequence
> > > /usr/share/docbook-utils/backends/pdf: line 9: 3698 Illegal
> instruction $SGML_JADE -t tex -o ${SGML_FILE_NAME}.tex $SGML_ARGUMENTS
> >
> > Some further investigation on this:
> >
> > fontconfig builds fine if jade is installed but not if only openjade is
> > installed. So the real error here seems to be the openjade error, not
> > the segv in docbook-utils that is caused by it.
> >
> > Since I don't know that much about the docbook SGML toolchain, I'm
> > unsure how to proceed: should fontconfig build-depend on jade? Or
> > is this a bug in openjade? Or really in docbook-utils?
> >
> > Gruesse,
> > --
> > Frank Lichtenheld <[EMAIL PROTECTED]>
> > www: http://www.djpig.de/
>
> The openjade error message is saying that there is a problem in the
> stylesheet
> dbrfntry.dsl, part of the docbook-dsssl package. I suppose since the error
> occurs for openjade and not jade that it could actually be an error in
> openjade. I maintain jade, openjade and openjade1.3. I can look into
> whether
> this is an openjade error if someone will tell me how to reproduce it - will
> the error occur if I just get the current source of fontconfig from unstable
> and attempt to build the package?
>
> I CC'ed the docbook-dsssl package on this. It's maintained by Peter
> Eisentraut. Peter, can you take a look at the stylesheets and see if
> there is a problem in dbrfntry.dsl?
I was able to reproduce this using just openjade and the docbook-dsssl
stylesheets, so the problem is not in docbook-utils or its customized versions
of the docbook stylesheets. I was also able to generate without error the
HTML version of the file, which uses the DocBook html stylesheet rather than
the DocBook print stylesheet, so the problem is specific to the print
stylesheet. I'm not a DSSSL expert, but I was able to modify the print
stylesheet so that it did not produce an error. I think this is a
docbook-dsssl problem.
--
Neil Roeth
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298163: FTBFS in experimental
On Mar 12, Frank Lichtenheld ([EMAIL PROTECTED]) wrote:
> On Sat, Mar 05, 2005 at 09:39:44AM +0100, Andreas Barth wrote:
> > docbook2pdf local-fontconfig-user.sgml
> > Using catalogs: /etc/sgml/catalog
> > Using stylesheet: /usr/share/docbook-utils/docbook-utils.dsl#print
> > Working on: /build/buildd/fontconfig-2.3.0/doc/local-fontconfig-user.sgml
> > openjade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/print/dbrfntry.dsl:83:3:E:
> > flow objects at the root must be all of class scroll or all of class
> > page-sequence or simple-page-sequence
> > /usr/share/docbook-utils/backends/pdf: line 9: 3698 Illegal instruction
> > $SGML_JADE -t tex -o ${SGML_FILE_NAME}.tex $SGML_ARGUMENTS
>
> Some further investigation on this:
>
> fontconfig builds fine if jade is installed but not if only openjade is
> installed. So the real error here seems to be the openjade error, not
> the segv in docbook-utils that is caused by it.
>
> Since I don't know that much about the docbook SGML toolchain, I'm
> unsure how to proceed: should fontconfig build-depend on jade? Or
> is this a bug in openjade? Or really in docbook-utils?
>
> Gruesse,
> --
> Frank Lichtenheld <[EMAIL PROTECTED]>
> www: http://www.djpig.de/
The openjade error message is saying that there is a problem in the stylesheet
dbrfntry.dsl, part of the docbook-dsssl package. I suppose since the error
occurs for openjade and not jade that it could actually be an error in
openjade. I maintain jade, openjade and openjade1.3. I can look into whether
this is an openjade error if someone will tell me how to reproduce it - will
the error occur if I just get the current source of fontconfig from unstable
and attempt to build the package?
I CC'ed the docbook-dsssl package on this. It's maintained by Peter
Eisentraut. Peter, can you take a look at the stylesheets and see if
there is a problem in dbrfntry.dsl?
--
Neil Roeth
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
