Bug#733353: wdm: FTBFS: ld: cannot find -lungif
reassign 733353 libwings-dev retitle 733353 libwings-dev : get-wings-flags should not link deprecated libungif found 733353 wmaker/0.95.5-1 thanks 2013/12/28 David Suárez : > Source: wdm > Version: 1.28-16 > Severity: serious > Tags: jessie sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20131226 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Maybe you need to add the needed build depend. > > Relevant part (hopefully): >> gcc -Wl,-z,relro -Wl,--as-needed -L./bin -L/usr/lib -L/usr/lib >> src/TestLogin/TestLogin.o -lWINGs -lWUtil -lwraster -ltiff -lXpm -lpng >> -ljpeg -lungif -lXft -lXext -lXext -lX11 -lm -lWUtil -lfontconfig -lcrypt >> -lutil -lwdm -lSM -lICE -lXext -lX11 -lm -lXinerama -o bin/TestLogin >> /usr/bin/ld: cannot find -lungif >> collect2: error: ld returned 1 exit status Hi, David and Rodolfo, wdm does not explicitly link against ungif. Seems that recent 'get-wings-flags' from libwings-dev package (used by wdm) forces that link, WLIBS="-lWINGs -lWUtil -lwraster -ltiff -lXpm -lpng -ljpeg -lungif -lXft -lXext -lXext -lX11 -lm " Please use -lgif instead of -lungif (See http://bugs.debian.org/732272 for the details). Also some stuff there may already be added by normal X11 configure checks and in any case -lXext is repeated. Reassigning accordingly Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cahmxk7i1zcchovgxsmyki2govjbxgt17plwog0-1qbqkhd3...@mail.gmail.com
Re: Proposed new requirements for emacsen add-on packages
On Wed, Jan 22, 2014 at 12:39:27PM -0600, Rob Browning wrote: > Agustin Martin writes: > > > Did not test in depth, but I think the add-on state files state files > > could be recreated from /usr/lib/emacsen-common/packages/install in > > case emacsen-common is installed for the first time (i.e., not > > upgraded). Since emacs flavours depend on emacsen-common they should > > byte compile things when configured. > > I may be misunderstanding, but if not, I think the problem there is > simultaneous installs (which are our primary complication in general), > > i.e. most of the complexity we have comes from the fact that we're > operating outside dpkg's dependency system (to avoid add-on deps), and > so we have no ordering guarantees. > > That's why I added the state/package/installed infrastructure, but I'm > beginning to think that this approach may just be insufficient. The > original idea was that the state files would allow add-ons to signal > that they're "ready to go" with respect to emacsen-common install/remove > calls. > > For example, consider the case where no emacsen-related packages are > installed and someone runs this: > > apt-get install emacs24 add-on-1 > > Because there are no relevant dpkg deps, the packages' maintainer > scripts can fire in any relative order, and if emacs24's postinst fires > before add-on-1's, it can know to skip installing add-on-1 because > package/installed/add-on-1 doesn't exist. But emacs24 *will* create > flavor/installed/emacs24, so that when add-on-1's postinst fires, its > install script will be run for emacs24. Of course, something reasonable > should also happen if the order is reversed. > > However, to demonstrate why I'm beginning to think the current approach > may be unworkable, consider the case where no emacsen-related packages > are installed and someone runs this: > > apt-get install emacs24 add-on-depending-on-add-on-1 add-on-1 Hi, I may be wrong, but if add-on-depending-on-add-on-1 depends on add-on-1 dpkg should care of configuring add-on-1 first. However, there is no warranty about unpack ordering. > I begin to suspect that up to now, we may have just been fairly lucky, > and that the current approach is may just be broken for any number of > cases like this. And unfortunately, adding the emacsen-common > dependency won't help. > > Another reason why I keep wondering about the possibility of using > triggers is that even if we addressed some of the above issues, the > current approach will still probably result in redundant installs from > time to time. Even if you want to be conservative and expect to > reinstall an add-on whenever it's upgraded, or any flavor is upgraded, > consider the previous example, but assume that all of the packages are > already installed (just being upgraded): > > apt-get install emacs24 add-on-depending-on-add-on-1 add-on-1 > > Currently, the emacs24 postinst will install both of the add-ons, and > then each add-on will install itself, and add-on-depending-on-add-on-1 > will also reinstall add-on-1 again. With a triggers-based approach > you'd hope that we could coordinate better, and only run each install > once. Some add-ons do a check to avoid that, check that .elc for last byte-compiled file is present. If so, it is already done, otherwise byte-compile. But is way better if is emacsen-common who cares about that. > So, generally speaking, unless we come up with alternatives, I'm > beginning to wonder if triggers may be our best option, assuming we can > shoehorn all add-ons into accommodating the attendant restrictions > (whatever they end up being). I think you are right, they may be the best option, but some ellaboration is needed to properly evaluate that possibility, before going further into it. In a quick proposal, I'd think about emacs-install and emacs-package-install just touching action flags like $flavour___$package when run under dpkg control and not triggered and also enable the common emacsen-common trigger. If run from the command line or from dpkg-reconfigure (that is, not under dpkg control) they should do their usual current work and remove/update flags as needed in success. When the trigger is run, some script runs emacs-package-install as --triggered, old .elc files removed, byte-compilation done after flags and flag removed on success. I wrote some code to deal with aspell and ispell dictionaries automatic hash rebuild from dictionaries-common triggers that may be useful here (perl is also used). > I'm not sure if I already mentioned it here, but I'm not opposed to > triggers. Though if we made a change that substantial, we probably > *would*
Bug#606788: wdm: package fails to upgrade properly from lenny
tag 606788 + patch pending
thanks
On Sat, Dec 11, 2010 at 03:06:50PM -0800, Vagrant Cascadian wrote:
> this is due to a bug in the lenny version that's at least partially fixed in
> the version in squeeze:
>
> http://bugs.debian.org/582612
>
> from the above bug report:
>
> "This is caused by the insane way wdm handles refreshing of wm list, it
> directly modifies entry in wdm-config everytime wdm is started or stopped.
> ...
> This will not prevent prompting when upgrading from previous versions, but
> should leave this problem addressed for the future."
>
> so the squeeze version no longer has the bug that triggered the issue, but
> upgrades from older versions are going to suffer this issue.
Thanks for your comments.
As a matter of fact this is exactly the same problem than #582612.
When I prepared last wdm QA upload did not try to do a smooth upgrade since
I did not thought of a reasonable way at that time.
I have now thought of a possible approach for systems where changes were
never blessed by sysadmin in installation question (always decided to use
maintainer version). This will not affect config file if manually modified
by sysadmin.
Proposed wdm.preinst checks if the only change is display manager line and
then checks if change was not blessed by sysadmin, reverting automatic
changes if it was indeed not blessed and only automatically changed.
Proposed change is attached for comments before I prepare a new QA upload.
--
Agustin
>From 10b2dc3146dbff615de1f522063f0d8d0d7ffc20 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo
Date: Wed, 15 Dec 2010 12:54:56 +0100
Subject: [PATCH] debian/wdm.preinst: Smooth upgrades from lenny avoiding non-needed questions.
This should help in systems with no accepted changes.
wdm versions before 1.28-4 updated display manager list in ${wdmconfig}
conffile everytime wdm is installed, upgraded or run. That causes unneeded
queries during upgrade. This was fixed in 1.28-4. This file tries to smooth
upgrades from previous versions (1.28-2 and above). Checks if the only change
is display manager line and then checks if change was not blessed by sysadmin,
reverting automatic changes if so. See Debian bugs #582612 and #606788
---
debian/changelog |8
debian/wdm.preinst | 44
2 files changed, 52 insertions(+), 0 deletions(-)
create mode 100644 debian/wdm.preinst
diff --git a/debian/changelog b/debian/changelog
index 4b5f0bf..503e800 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+wdm (1.28-5) unstable; urgency=low
+
+ * QA upload.
+ * RC: Smooth upgrades from lenny avoiding non-needed questions
+ in systems with no accepted changes (Closes: #606788).
+
+ -- Agustin Martin Domingo Wed, 15 Dec 2010 12:35:20 +0100
+
wdm (1.28-4) unstable; urgency=low
* QA upload.
diff --git a/debian/wdm.preinst b/debian/wdm.preinst
new file mode 100644
index 000..1d98f38
--- /dev/null
+++ b/debian/wdm.preinst
@@ -0,0 +1,44 @@
+#!/bin/sh
+
+set -e
+
+# wdm versions before 1.28-4 updated display manager list in ${wdmconfig}
+# conffile everytime wdm is installed, upgraded or run. That causes unneeded
+# queries during upgrade. This was fixed in 1.28-4. This file tries to smooth
+# upgrades from previous versions (1.28-2 and above). Checks if the only change
+# is display manager line and then checks if change was not blessed by sysadmin,
+# reverting automatic changes if so. See Debian bugs #582612 and #606788
+
+# md5sums for pristine wdm-config with DisplayManager*wdmWm stripped
+# wdm_1.28-2 (as well as lenny wdm_1.28-3)
+pristine_stripped_md5="b903cf9c29cad13e3931ff30e6da7b96"
+# Intermediate wdm_1.28-3.5
+pristine_stripped_md5_alt="3ec0efa2089101552b0874ff63884292"
+
+# pristine wdm-config DisplayManager*wdmWm string
+pristine_string='! DisplayManager*wdmWm: twm:wmaker:afterstep'
+
+wdmconfig="/etc/X11/wdm/wdm-config"
+wdmconfig_tmp="${wdmconfig}.dpkg-tmp"
+
+# Do nothing if this is first installation
+if [ -f "$wdmconfig" ]; then
+wdmconfig_stripped_md5=$(grep -v 'DisplayManager\*wdmWm:' "${wdmconfig}" | md5sum | sed 's/ .*//')
+
+# First check if "$wdmconfig" matches old pristine files for everything but Displaymanager line.
+if [ "$wdmconfig_stripped_md5" = "$pristine_stripped_md5" ] ||
+ [ "$wdmconfig_stripped_md5" = "$pristine_stripped_md5_alt" ]; then
+ wdmconfig_dpkg_md5sum=$(dpkg-query -W -f='${Conffiles}' wdm | grep "$wdmconfig" | awk '{print $2}')
+ sed -e 's/.*DisplayManager\*wdmWm:.*/'"$pristine_string"'/' "$wdmconfig" > "${wdmconfig_tmp}"
+ wdmconfig_new_md5=$(md5sum "${wdmconfig_tmp}" | sed 's/ .*//')
+
+ # Check now if
Bug#463598: /var/run/utmp exists, but wdm still doesn't register the session
On Thu, May 27, 2010 at 07:37:37PM +0200, Agustin Martin wrote: > On Fri, May 21, 2010 at 09:36:47PM +0300, Yury Bulka wrote: > > > > Hello! Let me firstly thank you for your work on this package and for > > reading this:) > > So here's what the report is about: > > I've also noticed that wdm doesn't register the session it starts to utmp, > > but in my case /var/run/utmp exists on my system. > > It's strange, because the "sessreg" command is in its place in file > > /etc/X11/wdm/Xstartup: > > --- > > # Insert a utmp entry for the session > > if grep -q ^use-sessreg /etc/X11/wdm/wdm.options; then > > exec sessreg -a -l $DISPLAY -u /var/run/utmp -x /etc/X11/wdm/Xservers > > $USER > > # NOTREACHED > > fi > > --- > > and the option "use-sessreg" is enabled in /etc/X11/wdm/wdm.options. > > I tried to install xdm and it does register the session with almost > > identical "sessreg" command (the only difference is the -x parameter which > > is set to "/etc/X11/xdm/Xservers" there)... > > I replaced wdm Xstartup with xdm Xstartup and s/xdm/wdm/g. No luck, it still > does not register session. I have verified that $DISPLAY and $USER values > just before the sessreg call are correct and so that the sessreg line is > processed if use-sessreg is enabled. > > I am curious, did it register session at some time? > > In the box where wdm is installed last time /var/log/wdm.log was updated was > long time ago, on November 2005 for sid. I wonder what happened at that time. > I think about something related to xfree86 -> xorg transition (last xfree86 > log in this sid box is from September 2005). By the way, just noticed why "/var/log/wdm.log" was not updated. It was indeed the expected behavior. Somewhere around 1.27 (Seems to be 1.27-1, according to changelog, in reply to #242155), "wdm-config" was modified to have messages be sent to syslog as default, while previous default was "/var/log/wdm.log". And that happened in late 2004 amd hit me in 2005. I have checked my "/var/log/syslog" and it indeed contains wdm messages. If I modify "wdm-config" to not use syslog, messages are sent again to "/var/log/wdm.log". Adam, I am aware this bug is 3 years old and you no longer use wdm, but do you remember if when noticing the problem you checked "/var/log/wdm.log", or it was "/var/log/syslog"? Thanks for your feedback, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011022618.ga3...@agmartin.aq.upm.es
Bug#619279: myspell-hu: Remove unconditional call to soon to disappear 'update-openoffice-dicts'
Package: myspell-hu
Version: 0.99.4-2
Severity: normal
Patgs: patch
'update-openoffice-dicts' will soon be removed from dictionaries-common,
but 'myspell-hu' maintainer scripts unconditionally call it.
'update-openoffice-dicts' only remaining task was to remove ancient
Openoffice.org 2.4 "dictionary.lst" file. For squeeze, it still updated
"dictionary.lst" in the extremely unlikely possibility that Ooo 2.4 is
installed. That Ooo has now become more than ancient and its presence
really unlikely.
For that reason, 'update-openoffice-dicts' has been made a no-op and will
soon be removed.
Please remove unconditional call to 'update-openoffice-dicts' from
maintainer scripts, as proposed in attached patch.
Thanks in advance,
--
Agustin
reverted:
--- magyarispell-0.99.4/debian/myspell-hu.postinst
+++ magyarispell-0.99.4.orig/debian/myspell-hu.postinst
@@ -1,22 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-configure)
-update-openoffice-dicts
-;;
-
-abort-upgrade|abort-remove|abort-deconfigure)
-
-;;
-
-*)
-echo "postinst called with unknown argument \`$1'" >&2
-exit 1
-;;
-esac
-
-#DEBHELPER#
-
-exit 0
reverted:
--- magyarispell-0.99.4/debian/myspell-hu.postrm
+++ magyarispell-0.99.4.orig/debian/myspell-hu.postrm
@@ -1,20 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
- purge|remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
-if [ "$1" = "remove" ]; then
-update-openoffice-dicts
- fi
-;;
-
-*)
-echo "postrm called with unknown argument \`$1'" >&2
-exit 1
-
-esac
-
-#DEBHELPER#
-
-exit 0
diff -u magyarispell-0.99.4/debian/changelog magyarispell-0.99.4/debian/changelog
--- magyarispell-0.99.4/debian/changelog
+++ magyarispell-0.99.4/debian/changelog
@@ -1,3 +1,11 @@
+magyarispell (0.99.4-2.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * myspell-hu.post{inst,rm}: Remove, only unconditionally called
+useless and soon to not be shipped update-openoffice-dicts.
+
+ -- Agustin Martin Domingo Tue, 22 Mar 2011 17:41:07 +0100
+
magyarispell (0.99.4-2) unstable; urgency=low
* QA upload.
Bug#628603: synaptic does not start when wdm is the display manager
On Mon, May 30, 2011 at 08:57:27PM +0430, Eliad Bagherzadegan wrote: > Package: wdm > Version: 1.28-6 > Severity: important > > The title pretty much says it. Thanks for your info, but more details are really needed. I cannot reproduce that problem here in my i386 box when run from a xterm. Some questions, * Did you try with a different display manager? When you noticed the problem? Any other relevant change aroud that time? * Did you call synaptic from a xterm or from a pull-down menu? Does it fail when called both ways? * Is only synaptic which fails? * Which error did you see? Any relevant info under /var/log? Thanks for your feedback, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110531094815.ga18...@agmartin.aq.upm.es
Bug#629086: [myspell-fr]: Please remove call to soon to disappear 'update-openoffice-dicts'
Package: myspell-fr Version: 1.4-26 Severity: normal Hi, Your package still uses an entry in maintainer scripts that calls the soon to disappear update-openoffice-dicts script in a way that will fail once it is removed. If you use dictionaries-common-dev debhelper snippets, please rebuild your package against at least dictionaries-common-dev 1.10.5 and adjust Build-Depends accordingly. Otherwise just remove that part from maintainer scripts. Thanks in advance, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110603124806.ga3...@agmartin.aq.upm.es
Bug#605776: ifrench: throws lots of warning during preconfiguration
reassign 605776 dictionaries-common forcemerge 596277 605776 thanks On Fri, Dec 03, 2010 at 12:16:31PM +0100, Ralf Treinen wrote: > Package: ifrench > Version: 1.4-25 > Severity: normal > > Installing ifrench (with no ispell previously installed) results in the > following. In the debconf menu I had selected the french dictionary as > default dictionary. > > root@murdock:/home/rt# apt-get install ifrench > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following extra packages will be installed: > ispell > Suggested packages: > wfrench spell > The following NEW packages will be installed: > ifrench ispell > 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. > Need to get 0 B/563 kB of archives. > After this operation, 2,863 kB of additional disk space will be used. > Do you want to continue [Y/n]? > Preconfiguring packages ... > Use of uninitialized value $classprefix in concatenation (.) or string at > /usr/share/dictionaries-common/dc-debconf-default-value.pl line 119, > line 7. > Use of uninitialized value $classprefix in concatenation (.) or string at > /usr/share/dictionaries-common/dc-debconf-default-value.pl line 138, > line 7. This seems the same than #596277, fixed in dictionaries-common 1.5.14. merging both bug reports. -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110607132020.ga4...@agmartin.aq.upm.es
Bug#628603: synaptic does not start when wdm is the display manager
On Fri, Jun 17, 2011 at 11:02:55PM +0430, Eliad Bagherzadegan wrote: > On 05/31/2011 02:18 PM, Agustin Martin wrote: > > On Mon, May 30, 2011 at 08:57:27PM +0430, Eliad Bagherzadegan wrote: > >> Package: wdm > >> Version: 1.28-6 > >> Severity: important > >> > >> The title pretty much says it. > > > > Thanks for your info, but more details are really needed. > > > > I cannot reproduce that problem here in my i386 box when run from a xterm. > > Some questions, > > > > * Did you try with a different display manager? When you noticed the > > problem? > > Any other relevant change aroud that time? > > * Did you call synaptic from a xterm or from a pull-down menu? Does it fail > > when called both ways? > > * Is only synaptic which fails? > > * Which error did you see? Any relevant info under /var/log? > > > > Thanks for your feedback, > > > Sorry for the delay. I had upgraded some packages and did not have keyboard > and mouse on X. > > synaptic works perfectly with slim/openbox, from menu and from lxterminal. > Running wdm/openbox,I get this error message in lxterminal: > # synaptic > No protocol specified > > (synaptic:20554): Gtk-WARNING **: cannot open display: :0 > > > I've noticed that this only happens when an X application is going to be run > as root. For example I could run gedit as a user, but got the same error when > I tried o run it as root. Are you exporting XAUTHORITY from user account before becoming root? -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110620091948.ga3...@agmartin.aq.upm.es
Bug#557709: wdm: "Exit login" doesn't work
2009/11/23 Frank Küster : > Package: wdm > Version: 1.28-3.2 > Severity: normal > > Hi, > > when I choose "Exit login" (in the list that also contains shutdown > etc. and has login as default), the screen turns into pink bricks, but I > don't get to a console. Also pressing Alt+F1 or Ctrl-Alt+F1 doesn't > help. It also seems that blind typing doesn't work. > > Of course, switching to a console first and running /etc/init.d/wdm stop > works. Hi, Franck, Just uploaded a wdm QA and looked at some of the remaining bug reports. I am aware that this bug report is 2 years old, so you may no longer use wdm. Unless selected otherwise in wdm config file you need to authenticate as root for 'Exitlogin' to work under wdm. I tested yesterday in a squeeze box and worked as expected. Do you remember if you did it in the same way? If not, I guess after exitlogin failure you were hit by merged (and already fixed) #448647: wdm: Does not work a second time #472703: wdm: Sometimes I cannot login, Enter doesn't work leading to different login problems Please provide these details, if you remember them, Thanks in advance, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAHMXK7hWyC6r0B3nhi2W6LbZAi1Kp68db=-w2yzm+x49qzf...@mail.gmail.com
Bug#640788: ibritish: pidgin says: Illegal format hash table /usr/lib/ispell/british.hash
reassign 640788 libenchant1c2a retitle 640788 libenchant1c2a: Make enchant-ispell compatible with new ispell in sid tag 640788 +patch On Wed, Sep 07, 2011 at 08:54:53PM +1000, Russell Coker wrote: > Package: ibritish > Version: 3.3.02-5 > Severity: normal > > Illegal format hash table /usr/lib/ispell/british.hash - expected magic2 > 0x9602, got 0x0 > > When I run pidgin I get the above message. I don't know if it's pidgin or > ibritish at fault. Sorry if I filed the bug against the wrong one. > > The error message occurs repeatedly, it occurs on startup and also occurs when > opening a chat window. This seems to be caused by enchant ( pidgin -> libgtkspell0 -> libenchant1c2a ) not being updated for new ispell format, with no alternative spellchecker specified for that language. e.g., I reproduced this with ~/.enchant/enchant.ordering: en_GB:ispell $ echo "hola" | enchant -l -d british Illegal format hash table /usr/lib/ispell/british.hash - expected magic2 0x9602, got 0x0 hola Attached patch (with some changes borrowed from new ispell config.X) seems to work. Not sure if something else is needed. New package should also have a Breaks field in its control file against old ispell dictionaries, in a way similar to new ispell. In the meantime, if you have aspell-en installed you can try to add aspell as an alternative in enchant.ordering file to make enchant use aspell for that language if ispell fails, en_GB:ispell,aspell or comment that line, so enchant tries all possibilities in its default ordering. -- Agustin diff -Nru --exclude '*changelog' enchant-1.6.0/debian/patches/02-new-ispell-format.diff enchant-1.6.0/debian/patches/02-new-ispell-format.diff --- enchant-1.6.0/debian/patches/02-new-ispell-format.diff 1970-01-01 01:00:00.0 +0100 +++ enchant-1.6.0/debian/patches/02-new-ispell-format.diff 2011-09-07 18:34:01.0 +0200 @@ -0,0 +1,13 @@ +Index: enchant-1.6.0/src/ispell/ispell.h +=== +--- enchant-1.6.0.orig/src/ispell/ispell.h 2011-09-07 18:32:36.212371501 +0200 enchant-1.6.0/src/ispell/ispell.h 2011-09-07 18:33:55.152091750 +0200 +@@ -297,7 +297,7 @@ + ** character counts as two! + */ + #ifndef MAXSTRINGCHARS +-#define MAXSTRINGCHARS 128 ++#define MAXSTRINGCHARS 512 + #endif /* MAXSTRINGCHARS */ + + /* diff -Nru --exclude '*changelog' enchant-1.6.0/debian/patches/series enchant-1.6.0/debian/patches/series --- enchant-1.6.0/debian/patches/series 2011-08-18 21:09:33.0 +0200 +++ enchant-1.6.0/debian/patches/series 2011-09-07 18:34:30.0 +0200 @@ -1 +1,2 @@ debian-changes-1.6.0-3 +02-new-ispell-format.diff
Bug#640788: ibritish: pidgin says: Illegal format hash table /usr/lib/ispell/british.hash
On Wed, Sep 07, 2011 at 06:59:32PM +0200, Agustin Martin wrote: > On Wed, Sep 07, 2011 at 08:54:53PM +1000, Russell Coker wrote: > > Illegal format hash table /usr/lib/ispell/british.hash - expected magic2 > > 0x9602, got 0x0 > > > > When I run pidgin I get the above message. I don't know if it's pidgin or > > ibritish at fault. Sorry if I filed the bug against the wrong one. > > > > The error message occurs repeatedly, it occurs on startup and also occurs > > when > > opening a chat window. > > This seems to be caused by enchant ( pidgin -> libgtkspell0 -> libenchant1c2a > ) > not being updated for new ispell format, with no alternative spellchecker > specified for that language. e.g., I reproduced this with > > ~/.enchant/enchant.ordering: > en_GB:ispell > > $ echo "hola" | enchant -l -d british > Illegal format hash table /usr/lib/ispell/british.hash - expected magic2 > 0x9602, got 0x0 > hola > > Attached patch (with some changes borrowed from new ispell config.X) seems > to work. Not sure if something else is needed. New package should also have a > Breaks field in its control file against old ispell dictionaries, in a way > similar to new ispell. For the records, I committed this change to enchant collab-maint git repo, http://http://anonscm.debian.org/gitweb/?p=collab-maint/enchant.git;a=commit;h=515207f8e5285e79be21c77c30fd041247eb9086 enchant is currently orphaned. I may make at some time a QA upload including this change. Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111019100416.ga8...@agmartin.aq.upm.es
Bug#643107: enchant: FTBFS: dpkg-buildpackage: error: dpkg-source -b enchant-1.6.0 gave error exit status 2
tag 643107 +pending thanks On Mon, Sep 26, 2011 at 10:25:41PM +0200, Didier Raboud wrote: > Source: enchant > Version: 1.6.0-3 > Severity: important > Tags: wheezy sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20110923 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part: > > fakeroot debian/rules clean > > dh_testdir > > dh_testroot > > rm -f build-stamp > > # Add here commands to clean up after the build process. > > [ ! -f Makefile ] || /usr/bin/make distclean > > dh_clean > > dpkg-source -b enchant-1.6.0 > > dpkg-source: info: using source format `3.0 (quilt)' > > dpkg-source: info: building enchant using existing > > ./enchant_1.6.0.orig.tar.gz > > dpkg-source: info: local changes detected, the modified files are: > > enchant-1.6.0/config.guess > > enchant-1.6.0/config.sub > > dpkg-source: error: aborting due to unexpected upstream changes, see > > /tmp/enchant_1.6.0-3.diff.WV_GR7 > > dpkg-source: info: you can integrate the local changes with dpkg-source > > --commit > > dpkg-buildpackage: error: dpkg-source -b enchant-1.6.0 gave error exit > > status 2 > > > > Build finished at 20110924-0032 Just marking that I made a commit to enchant collab-maint git repo, taking care of this in one possible way, http://http://anonscm.debian.org/gitweb/?p=collab-maint/enchant.git;a=commit;h=9776604ebd64c4a4163916e5db7428e6430f3cc5 enchant is currently orphaned. I will probably make a QA upload including this change at some time. Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111019101054.ga9...@agmartin.aq.upm.es
Bug#219436: libenchant1: binaries should go into a separate package
tag 219436 +pending
tag 640788 +pending
thanks
On Thu, Nov 13, 2003 at 03:39:46PM +0100, Agustin Martin Domingo wrote:
> Gregor Hoffleit wrote.
>
> >Section 8.2 of the Debian policy says that run-time support packages
> >must not be put in a shared library package. Please consider moving
> >"enchant" and "enchant-lsmod" into another package ("enchange" or
> >"enchant-runtime").
>
> I think that files are not really runtime files, but intended to
> test the library version against which they were compiled, although
> enchant can have some not very frequent use standalone (Am I wrong,
> Masayuki?).
Since enchant program can be used standalone for some purposes I now think
differently. I have committed changes for this to enchant collab-maint git
repo
http://http://anonscm.debian.org/gitweb/?p=collab-maint/enchant.git;a=commit;h=a2576434231f5dc68bfa2ec639d2e069bd4f7e78
with programs moved to a new 'enchant' package.
I would like to play a bit more before sending a QA upload, but in the
meantime I am tagging this bug report as pending.
Regards,
--
Agustin
--
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111020094429.ga8...@agmartin.aq.upm.es
Bug#546418: libenchant1c2a: Command enchant, problems with
On Sun, Sep 13, 2009 at 11:47:05AM +0300, Tapio Lehtonen wrote: > Package: libenchant1c2a > Version: 1.4.2-3.3 > Severity: normal Hi, Tapio. Recently prepared a QA upload for enchant and am now looking at other bug reports for it, > Man page for enchant does not mention option -d (nor -h). > > $ enchant -h > Usage: enchant [options] -a|-d dict|-l|-L|-m|-v[v]| >-a lists alternatives. >-d dict uses dictionary . >-l lists misspellings. >-m is ignored. >-L displays line numbers. >-v displays program version. Not only that, -a does not list alternatives, but means pipe mode in the same was as for ispell > Furhermore enchant -d fi and -d fi_FI do not produce the same result. > Looks like -d fi works as expected, -d fi_FI makes strange results. > $ cat test-material-for-enchant-2.txt > Hallinnolliset tiedot > Tietoa tästä ohjeesta > This manual was created for Sarge's debian-installer, based on the > Woody > installation manual for boot-floppies, which was based on earlier > Debian > installation manuals, and on the Progeny distribution manual which was > released under GPL in 2003. Is this still true? > $ enchant -l -d fi < test-material-for-enchant-2.txt > $ enchant -l -d fi_FI < test-material-for-enchant-2.txt seems to work well here (Note that this is enchant 1.6.0, so this problem may have been fixed in the meantime) > According to enchant-lsmod, a different backend is used for fi_FI than > for fi. > $ enchant-lsmod -list-dicts > fi (voikko) > en (ispell) > en_PH (ispell) > en_US (ispell) > fi_FI (myspell) > tr (zemberek) This is also the result here, but voikko seems indeed used for both fi anf fi_FI, $ enchant-lsmod -lang fi fi (voikko) $ enchant-lsmod -lang fi_FI fi_FI (voikko) Will try to look deeper when I have time. > At least the man pages needs more material. Maybe the program works as > intended, but the docs should document the intentions. Agreed. There are already two patches for that man page and as mentioned above more changes are needed. Thanks for your feedback, Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111025112507.ga18...@agmartin.aq.upm.es
Bug#646555: [Pkg-geany-team] Bug#646555: geany-plugin-spellcheck: Spellcheck missing dependency
retitle 646555 libenchant1c2a: should depend on at least one dictionary. tag 646555 +pending thanks On Tue, Oct 25, 2011 at 01:24:39PM +0800, Chow Loong Jin wrote: > reassign 646555 enchant > kthxbye > > Hi Alex, > > Thanks for spotting this bug. Seeing as geany-plugin-spellcheck depends on > libenchant, and libenchant is meant to be an abstraction layer for several > spell > checker backends, the dependency should go there instead, so I'm reassigning > this bug to enchant instead. Hi both, I'd put the dependency on (myspell|aspell|ispell|hunspell)-dictionary. Committed that change to enchant collab-maint git repo. http://anonscm.debian.org/gitweb/?p=collab-maint/enchant.git;a=commit;h=df7f2c6e709abfca052024ef7f9a4d2974e62991 Note that enchant is orphaned. I will not upload inmediately, but would like to first prepare a new QA upload with some fixes in manpages. This change will go with it. Thanks for your help, Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111026104746.ga3...@agmartin.aq.upm.es
Bug#646555: enchant: Spellcheck missing dependency
On Thu, Oct 27, 2011 at 02:34:24AM +0800, Chow Loong Jin wrote: > On 26/10/2011 18:47, Agustin Martin wrote: > > I'd put the dependency on (myspell|aspell|ispell|hunspell)-dictionary. > > Committed that change to enchant collab-maint git repo. > > > > http://anonscm.debian.org/gitweb/?p=collab-maint/enchant.git;a=commit;h=df7f2c6e709abfca052024ef7f9a4d2974e62991 > > Thanks for the fix. > > > Note that enchant is orphaned. I will not upload inmediately, but would like > > to first prepare a new QA upload with some fixes in manpages. This change > > will go with it. > > Regarding that, it looks like Bastien ROUCARIES wants to adopt the package, as > mentioned on the O: bug[1]. Thanks for the pointer, cc'ing him. This ITA was not shown in the PTS because bug title was not renamed. Bastien, if you still want to adopt the package please set yourself as #580680 owner and retitle it to ITA: enchant -- a wrapper library for various spell checkers > It might be a good idea to check with him before uploading. Yes, I will contact Bastien before further commits. > Otherwise, if nobody else steps up to adopt this package, I can look into > adopting it myself, seeing as I'm maintainer of geany-plugins which uses it. Besides some recent commits and a QA upload, I enabled VCS notification for enchant collab-maint git repo through the PTS, if the cvs/vcs notification option has been selected during PTS package subscription. If you are already subscribed to enchant package through the PTS and have that option enabled, you should have received info about those commits. If subscribed but did not receive those messages and want to follow them, should (re-)subscribe making sure that cvs notification option is enabled. Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111027093133.ga2...@agmartin.aq.upm.es
Bug#647279: [enchant] typo "avalable" is the manual page of enchant-lsmod
2011/11/1 Filipus Klutiero :
> Package: enchant
> Version: 1.6.0-4
> Severity: minor
>
> The NAME section of enchant-lsmod's manpage contains:
>
>> enchant-lsmod - Show information about avalable spell-checking modules and
>> dictionaries.
>
> "avalable" is missing a "i" ("available").
Thanks for noticing this. Will take care in a couple of days. Bastien,
let me know if you prefer to care of this yourself.
Regards,
--
Agustin
--
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cahmxk7gx9eyxa9-x5nfefcrxnvuwpkfbpf1h5smkvasozes...@mail.gmail.com
Bug#647281: [enchant] incomplete/outdated manpage for enchant
2011/11/1 Filipus Klutiero : > Package: enchant > Version: 1.6.0-4 > Severity: normal > > enchant's manpage contains: > >> SYNOPSIS >> enchant [-a] [-l] [-L] [-v] > > However, calling enchant without arguments outputs: > >> Usage: enchant [options] -a|-d dict|-l|-L|-m|-v[v]| >> -a lists alternatives. >> -d dict uses dictionary . >> -l lists misspellings. >> -m is ignored. >> -L displays line numbers. >> -v displays program version. >> chealer@vinci:~/logs$ > > If you look at the output, you also notice it contains options not found in > the manpage, suggesting the manpage is also outdated. Thanks, This has been already reported as part of Debian #546418. Today I filed an upstream bug report and sent upstream a patch with proposed changes for this, also including a couple of other Debian changes, http://bugzilla.abisource.com/show_bug.cgi?id=13163 In the meantime, I will soon commit the part related to this bug report, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAHMXK7j0s2z1i+-T+_Mw=-c06c4r6f_yaouns4dxpmeqlsh...@mail.gmail.com
Bug#546418: libenchant1c2a: Command enchant, problems with
retitle 546418 enchant: Inconsistent behavior of enchant-lsmod -list-dicts and -lang options forwarded 546418 http://bugzilla.abisource.com/show_bug.cgi?id=13165 thanks On Tue, Oct 25, 2011 at 01:25:07PM +0200, Agustin Martin wrote: > On Sun, Sep 13, 2009 at 11:47:05AM +0300, Tapio Lehtonen wrote: > > Package: libenchant1c2a > > Version: 1.4.2-3.3 > > Severity: normal > > Man page for enchant does not mention option -d (nor -h). This should be improved/fixed with a QA upload just done. > > According to enchant-lsmod, a different backend is used for fi_FI than > > for fi. > > $ enchant-lsmod -list-dicts > > fi (voikko) > > en (ispell) > > en_PH (ispell) > > en_US (ispell) > > fi_FI (myspell) > > tr (zemberek) > > This is also the result here, but voikko seems indeed used for both fi anf > fi_FI, > > $ enchant-lsmod -lang fi > fi (voikko) > > $ enchant-lsmod -lang fi_FI > fi_FI (voikko) Seems that both options use a different way to parse available dictionaries. Filed upstream a bug report about this. http://bugzilla.abisource.com/show_bug.cgi?id=13165 Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2002114614.ga15...@agmartin.aq.upm.es
Bug#651819: "pkgconfig --libs enchant" specifies unnecessary libraries
On Mon, Dec 12, 2011 at 12:52:54PM +0100, Per Olofsson wrote: > Package: libenchant-dev > Version: 1.6.0-6 > Severity: minor > > When I build lyx, dpkg-shlibdeps complains about it unnecessarily > linking against libgmodule, libglib, and librt. > > It turns out that lyx depends on these libraries because it uses > enchant. Indeed: > > $ pkg-config --libs enchant > -pthread -lenchant -lgmodule-2.0 -lrt -lglib-2.0 Hi, Per Those libs seem to come from Requires: glib-2.0 gmodule-no-export-2.0 entry in upstream enchant.pc.in > It appears that enchant can be used without explicitly depending on > the extra libraries. Please consider moving them to Libs.private in > enchant.pc. I guess you mean that lyx can use enchant without explicitly depending on above libraries, enchant itself seems to heavily rely on glib-2.0. I am not familiar with pkg-config and friends. Should something like Requires.private help here? Or is better Libs.private as you suggest? PS: I am not enchant maintainer, just have it under my radar because I uploaded last QA. enchant itself is orphaned. Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111220121538.ga21...@agmartin.aq.upm.es
Bug#651819: "pkgconfig --libs enchant" specifies unnecessary libraries
tag 651819 +pending thanks On Tue, Dec 20, 2011 at 03:48:03PM +0100, Per Olofsson wrote: > 2011-12-20 13:15, Agustin Martin skrev: > > I am not familiar with pkg-config and friends. Should something like > > Requires.private help here? Or is better Libs.private as you suggest? > > Yes, Requires.private would help. Not Libs.private, of course, sorry. > > So, what I'm suggesting is to move glib and gmodule to a > Requires.private line. Hi Per, Hi Bastien Thanks for the clarification. I have prepared a quilt patch with that change and committed it to enchant collab-maint git repo git://anonscm.debian.org/collab-maint/enchant.git together with a lintian fix for an unrelated issue. I am cc'ing Bastien ROUCARIES, who has shown interest in the package in case he has some other changes ready to go or something else to add. If Bastien does not upload himself, I will prepare a new QA upload with these changes. If no further problems appear we shoud also file a bug report at upstream bug tracker. Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111220164556.ga11...@agmartin.aq.upm.es
Bug#655325: myspell-sl: Must not call update-openoffice-dicts from maintainer scripts
Package: myspell-sl Version: 1.0-3 Severity: important update-openoffice-dicts is no longer shipped by dictionaries-common. However, myspell-sl unconditionally calls it from maintainer scripts. I am preparing a QA upload for this, -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120110121558.ga23...@agmartin.aq.upm.es
Bug#591317: wdm breaks with wmalloc assertion error
On Mon, Aug 02, 2010 at 07:41:25AM +0200, Jurgen Defurne wrote: > Package: wdm > Version: 1.28-3 > Severity: normal > > > When starting wdm the normal way, the cross cursor from X changes to > an arrow, and then the startup process breaks off. > > I tested this then further in the following way. I started up a > separate X server, then did 'export DISPLAY=:0' in another terminal and > executed 'wdm -nodaemon'. After some time I get the following message > : > > wdm: /tmp/buildd/wmaker-0.92.0/WINGs/memory.c:83: wmalloc: Assertion `size > > 0' failed. Hi, Jurgen, I arranged a recent wdm QA upload I am also looking at some of the ancient wdm bug reports and found this one. Is this problem still happening? I cannot reproduce it here. Thanks for your feedback, Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120117113904.ga4...@agmartin.aq.upm.es
Bug#662545: wdm: Please Build-Depends on libpng-dev, change from libpng12-dev
owner 662545 ! thanks On Mon, Mar 05, 2012 at 03:05:53PM +0900, Nobuhiro Iwamatsu wrote: > Source: wdm > Version: 1.8-1.1 > Severity: important > User: lib...@packages.debian.org > Usertags: libpng15-transition > > Hi, > > Libpng maintainers plan transition of libpng[0]. > Version 1.2 is used for libpng of current debian, but will shifts > to version 1.5 in this transition. > Your package still does it depending on libpng12-dev. > We cannot shift in transition mentioned above. > Please change Build-Depends of the package from libpng12-dev to libpng-dev. > > Build-Depends: debhelper (>= 8.0.0) > > [0]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650601 Hi, I will care of this. I had some other pending changes to make wdm scripts mimic a bit more those of xdm, so QA care is easier. They still need some extra testing, but I expect to do this soon. Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120305175131.ga22...@agmartin.aq.upm.es
Bug#700422: wdm shouldn't use /dev/mem
control: forcemerge -1 700421 On Tue, Feb 12, 2013 at 03:32:54PM +0100, Borislav Petkov wrote: > Package: wdm > Version: 1.28-13 > Severity: normal > Tags: upstream patch > > Hi, > > this is my first reporting a bug against a debian package so I very well > might've missed something in the process. > > Here's the deal: wdm still uses /dev/mem in genauth.c to generate a tmp > key and it shouldn't. The kernel currently allows userspace to read < > 640K of /dev/mem for compatibility reasons with X. The modern way of > getting two random longs is /dev/urandom and I've a patch below which > converts wdm to do that. > > Patch is ontop of the master branch of > git://git.debian.org/collab-maint/wdm.git and fixes the issue. Hi, Borislav, Thanks for your contribution. Nice to see a way to get rid of the "program wdm tried to access /dev/mem ..." messages. wdm is currently orphaned and no maintainer is explicitly caring of it, neither in Debian nor upstream. Since I made some of the final QA non-maintainer uploads I will care of including your patch at some time. Note that this will not happen soon since Debian wheezy is currently in "frozen" state in preparation for release. Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130212181752.ga19...@agmartin.aq.upm.es
Bug#700422: wdm shouldn't use /dev/mem
control: tag -1 +pending
Hi, Borislav
On Tue, Feb 12, 2013 at 07:39:19PM +0100, Borislav Petkov wrote:
> Ok, thanks. I've tested it lightly here by building a debian package
> using debian/rules and applying the patch by hand (couldn't get it to
> apply the patch automatically with "debian/rules patch" because the
> patch target was missing there... yadda yadda) ...
In wdm, changes inside debian/ dir are done directly and changes involving
upstream sources (everything outside debian/) are done through quilt
patches. They are automatically applied by dpkg-build* scripts on package
build and can be {un,}applied on demand by quilt pop/push (some tweaks may
be needed first). I am attaching a patch with the commit that included your
changes in my personal git repo, part as a normal change and part as a new
quilt patch.
> ... long story short, ping me if there's an official package available
> so that I can test it too, before it enters the distro repos.
I have prepared a personal package and put it in my personal Debian repo
under http://people.debian.org/~agmartin/debian-store/misc. Changes file is
signed with my Debian gpg key, available from the Debian keyring.
That repo is reachable through apt line
deb http://people.debian.org/~agmartin/debian-store/misc/ ./
and is also signed with my debian gpg key. Note that there is other stuff
there (mostly personal backports for other packages).
I am currently testing that package in this box and seems to work well in
the normal use needed here, so I will soon commit my changes to the wdm
collab-maint git repo.
In the meantime I am tagging this bug as pending.
Thanks a lot for your feedback.
Regards,
--
Agustin
>From dfc7f1d4fcba1f02d2d4fe8506b4366ad697e078 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo
Date: Tue, 12 Feb 2013 18:33:14 +0100
Subject: [PATCH] 08_do_not_use_dev_mem.patch: Use /dev/urandom instead of
/dev/mem (#700422)
Patch by Borislav Petkov:
wdm still uses /dev/mem in genauth.c to generate a tmp key and it
shouldn't. The kernel currently allows userspace to read < 640K of
/dev/mem for compatibility reasons with X. The modern way of getting
two random longs is /dev/urandom and I've a patch below which
converts wdm to do that.
---
debian/man/wdm.1x |2 +-
debian/patches/08_do_not_use_dev_mem.patch | 108
debian/patches/series |1 +
3 files changed, 110 insertions(+), 1 deletion(-)
create mode 100644 debian/patches/08_do_not_use_dev_mem.patch
diff --git a/debian/man/wdm.1x b/debian/man/wdm.1x
index 5f468d5..968acf2 100644
--- a/debian/man/wdm.1x
+++ b/debian/man/wdm.1x
@@ -202,7 +202,7 @@ to pass on to the \fIXsetup\fP,
.IP \fBDisplayManager.randomFile\fP
A file to checksum to generate the seed of authorization keys.
This should be a file that changes frequently.
-The default is \fI/dev/mem\fP.
+The default is \fI/dev/urandom\fP.
.IP \fBDisplayManager.greeterLib\fP
On systems that support a dynamically-loadable greeter library, the
name of the library. The default is
diff --git a/debian/patches/08_do_not_use_dev_mem.patch b/debian/patches/08_do_not_use_dev_mem.patch
new file mode 100644
index 000..489bc54
--- /dev/null
+++ b/debian/patches/08_do_not_use_dev_mem.patch
@@ -0,0 +1,108 @@
+Author: Borislav Petkov
+Description: Use /dev/urandom instead of /dev/mem
+Bug-Debian: http://bugs.debian.org/700422
+
+Borislav Petkov:
+
+wdm still uses /dev/mem in genauth.c to generate a tmp key and it
+shouldn't. The kernel currently allows userspace to read < 640K of
+/dev/mem for compatibility reasons with X. The modern way of getting
+two random longs is /dev/urandom and I've a patch below which
+converts wdm to do that.
+
+Index: wdm/doc/wdm.man.in
+===
+--- wdm.orig/doc/wdm.man.in 2013-02-12 18:26:27.879201302 +0100
wdm/doc/wdm.man.in 2013-02-12 18:26:27.863202561 +0100
+@@ -202,7 +202,7 @@
+ .IP \fBDisplayManager.randomFile\fP
+ A file to checksum to generate the seed of authorization keys.
+ This should be a file that changes frequently.
+-The default is \fI/dev/mem\fP.
++The default is \fI/dev/urandom\fP.
+ .IP \fBDisplayManager.greeterLib\fP
+ On systems that support a dynamically-loadable greeter library, the
+ name of the library. The default is
+Index: wdm/src/wdm/genauth.c
+===
+--- wdm.orig/src/wdm/genauth.c 2013-02-12 18:26:27.879201302 +0100
wdm/src/wdm/genauth.c 2013-02-12 18:26:27.875201665 +0100
+@@ -71,37 +71,26 @@
+
+ #if !defined(ARC4_RANDOM) && !defined(DEV_RANDOM)
+ static int
+-sumFile (char *name, long sum[2])
++sumFile (char *name, long sum[], unsigned n)
+ {
+-longbuf[1024*2];
+ int cnt;
+ int fd;
+-int loops;
+-int reads;
+-int i;
+-int
Bug#700896: cinnamon doesn't show up in wdm's window/session manager list
On Mon, Feb 18, 2013 at 10:58:37PM +0100, Axel Beckert wrote: > Package: cinnamon,wdm > Version: cinnamon/1.6.7-2 > Version: wdm/1.28-13 > > Dear Cinnamon Maintainers, dear QA Team, > > I'm using wdm as display manager. While XFCE, LXDE and GNOME show up > in wdm's list of available window and session managers, Cinnamon > doesn't. > > This means that I cannot choose to run Cinnamon when using wdm as > display manager. I'd have expected that Cinnamon shows up in wdm's > list as all other installed window and session managers seem to do. > > It doesn't make a difference if I use wdm from Wheezy/Sid (1.28-13) or > from Experimental (1.28-14~exp1). > > I'm reporting this issue against cinnamon and wdm since I don't know > which of these packages are the source for this issue. And because > fixing this issue in one of the two packages should already suffice. Hi, Axel Seems that cinnamon does not register itself as an alternative for neither "x-window-manager" nor "x-session-manager". That is what wdm uses to know which alternatives are available. Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130219122056.ga6...@agmartin.aq.upm.es
Bug#707231: wdm: pam_selinux is not available on !linux
tag 707231 +pending thanks On Wed, May 08, 2013 at 01:56:41PM +0200, Laurent Bigonville wrote: > Package: wdm > Version: 1.28-12 > Severity: serious > > Hello, > > Since version 1.28-12, wdm is calling the pam_selinux pam module > (bug #664809). > > The problem is that pam_selinux is only available on linux > architectures. As you made the pam_selinux module "required" in the pam > configuration, this could prevent the user to login on !linux > architectures. > > You should change this to something like: > [success=ok ignore=ignore module_unknown=ignore default=bad] Thanks for the info. Since I made the change I will also take care of the new change. Unfortunately I cannot build nor sign today or tomorrow, but hope to do that before early next week. If I understand correctly something like attached diff should be enough. Regards, -- Agustin diff --git a/debian/wdm.pam b/debian/wdm.pam index a0ede74..d0be0d8 100644 --- a/debian/wdm.pam +++ b/debian/wdm.pam @@ -2,6 +2,7 @@ # - authrequiredpam_nologin.so authrequiredpam_env.so envfile=/etc/default/locale + @include common-auth # - @include common-account @@ -9,11 +10,16 @@ authrequiredpam_env.so envfile=/etc/default/locale # SELinux needs to be the first session rule. This ensures that any # lingering context has been cleared. Without out this it is possible # that a module could execute code in the wrong domain. -session requiredpam_selinux.so close +# pam_selinux is unavailable for !linux, use [...] instead of required. +session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close + session requiredpam_limits.so session requiredpam_loginuid.so + @include common-session + # SELinux needs to intervene at login time to ensure that the process # starts in the proper default security context. Only sessions which are # intended to run in the user's context should be run after this. -session requiredpam_selinux.so open +# pam_selinux is unavailable for !linux, use [...] instead of required. +session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
Bug#545834: ivtools: FTBFS: On 64 bit arches: error: cast from 'void*' to 'osboolean' loses precision
On Wed, Sep 09, 2009 at 04:51:39PM +0200, Kurt Roeckx wrote: > Source: ivtools > Version: 1.2.6-1 > Severity: serious > > Hi, > > There was an error while trying to autobuild your package: > > > Automatic build of ivtools_1.2.6-1 on excelsior by sbuild/amd64 98 > > Build started at 20090906-1809 > [...] > > > make[3]: Entering directory `/build/buildd/ivtools-1.2.6/src/Attribute' > > installing for LINUX in /build/buildd/ivtools-1.2.6/src/Attribute/LINUX > > make[4]: Entering directory > > `/build/buildd/ivtools-1.2.6/src/Attribute/LINUX' > > g++ -gdwarf-2 -O2 -fPIC -Dcplusplus_2_1 -Wno-deprecated > > -I/build/buildd/ivtools-1.2.6/src/Attribute/LINUX/.. > > -I/build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../.. > > -I/build/buildd/ivtools-1.2.6/src > > -I/build/buildd/ivtools-1.2.6/src/include > > -I/build/buildd/ivtools-1.2.6/src/include/ivstd -I/usr/include -c > > /build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../attrvalue.c > > /build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../attrvalue.c: In member > > function 'osboolean AttributeValue::boolean_val()': > > /build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../attrvalue.c:360: error: > > cast from 'void*' to 'osboolean' loses precision > > /build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../attrvalue.c: In member > > function 'unsigned int AttributeValue::uint_val()': > > /build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../attrvalue.c:519: error: > > cast from 'void*' to 'unsigned int' loses precision > > /build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../attrvalue.c: In member > > function 'int AttributeValue::int_val()': > > /build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../attrvalue.c:552: error: > > cast from 'void*' to 'int' loses precision > Note that a pointer does not fit in an integer on 64 bit arches. > A pointer is 64 bit, an integer 32 bit. This is bug #314666 revisited. Fix proposed there was mostly incorporated upstream, but not complete. The part not included by upstream was the change of int (and boolean, which seems mapped to int) to long in the above lines, so this problem reappears. I have been playing to build a lenny x86_64 backport (I still use idraw frequently). I successfully built the package with gcc 4.3 in a x86_64 lenny box with attached patch. Instead of changing int and boolean to long in offending lines I changed it to intptr_t (and unsigned int to uintptr_t), from stdint.h. Seems included by default, so no need of explicitly including that header. I expect it to also build properly in a x86_64 sid box, but cannot check now. Since stdint.h is provided by libc6 since some time ago I hope it is available in all currently released arches. Note that attached patch is only what I used to build the package, so is neither tagged as a NMU nor closes the bug. Not sure about the NMU policy for QA maintained packages, but if you want me to turn that into a real NMU just tell. Cheers, -- Agustin diff -u ivtools-1.2.6/debian/changelog ivtools-1.2.6/debian/changelog --- ivtools-1.2.6/debian/changelog +++ ivtools-1.2.6/debian/changelog @@ -1,3 +1,12 @@ +ivtools (1.2.6-0.1~amdlenny1) unstable; urgency=low + + * Personal lenny backport. + * 48_gcc40_errors.diff: New patch using (u)intptr_t when +passing from pointer to (unsigned) int. + * debian/rules: Remove empty -p parameter to dh_installdocs. + + -- Agustin Martin Domingo Sun, 27 Sep 2009 20:29:25 +0200 + ivtools (1.2.6-1) unstable; urgency=low * QA upload. diff -u ivtools-1.2.6/debian/rules ivtools-1.2.6/debian/rules --- ivtools-1.2.6/debian/rules +++ ivtools-1.2.6/debian/rules @@ -146,7 +146,7 @@ -rm -f $(CURDIR)/debian/libiv-unidraw1/usr/lib/libIV.so.* #Remove ivmkmf from ivtools-bin package. -rm -f $(CURDIR)/debian/ivtools-bin/usr/bin/ivmkmf - dh_installdocs -p + dh_installdocs # dh_installexamples -a dh_installmenu ivtools-bin dh_installman -p$(PKG_BIN) -Xsrc/man/man1/ivmkmf.1 diff -u ivtools-1.2.6/debian/patches/series ivtools-1.2.6/debian/patches/series --- ivtools-1.2.6/debian/patches/series +++ ivtools-1.2.6/debian/patches/series @@ -41,0 +42 @@ +48_gcc40_errors.diff only in patch2: unchanged: --- ivtools-1.2.6.orig/debian/patches/48_gcc40_errors.diff +++ ivtools-1.2.6/debian/patches/48_gcc40_errors.diff @@ -0,0 +1,31 @@ +Index: ivtools-1.2.6/src/Attribute/attrvalue.c +=== +--- ivtools-1.2.6.orig/src/Attribute/attrvalue.c 2008-02-12 19:38:19.0 +0100 ivtools-1.2.6/src/Attribute/attrvalue.c 2009-09-27 23:56:17.0 +0200 +@@ -357,7 +357,7 @@ + case AttributeValue::StringType: + return (boolean) int_val()!=-1; + case AttributeValue::Object
Bug#545834: ivtools: FTBFS: On 64 bit arches: error: cast from 'void*' to 'osboolean' loses precision
On Mon, Sep 28, 2009 at 12:25:56AM +0200, Agustin Martin wrote: > On Wed, Sep 09, 2009 at 04:51:39PM +0200, Kurt Roeckx wrote: > > Source: ivtools > > Version: 1.2.6-1 > > Severity: serious > > > make[3]: Entering directory `/build/buildd/ivtools-1.2.6/src/Attribute' > > > installing for LINUX in /build/buildd/ivtools-1.2.6/src/Attribute/LINUX > > > make[4]: Entering directory > > > `/build/buildd/ivtools-1.2.6/src/Attribute/LINUX' > > > g++ -gdwarf-2 -O2 -fPIC -Dcplusplus_2_1 -Wno-deprecated > > > -I/build/buildd/ivtools-1.2.6/src/Attribute/LINUX/.. > > > -I/build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../.. > > > -I/build/buildd/ivtools-1.2.6/src > > > -I/build/buildd/ivtools-1.2.6/src/include > > > -I/build/buildd/ivtools-1.2.6/src/include/ivstd -I/usr/include -c > > > /build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../attrvalue.c > > > /build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../attrvalue.c: In member > > > function 'osboolean AttributeValue::boolean_val()': > > > /build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../attrvalue.c:360: > > > error: cast from 'void*' to 'osboolean' loses precision > > > /build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../attrvalue.c: In member > > > function 'unsigned int AttributeValue::uint_val()': > > > /build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../attrvalue.c:519: > > > error: cast from 'void*' to 'unsigned int' loses precision > > > /build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../attrvalue.c: In member > > > function 'int AttributeValue::int_val()': > > > /build/buildd/ivtools-1.2.6/src/Attribute/LINUX/../attrvalue.c:552: > > > error: cast from 'void*' to 'int' loses precision > > > Note that a pointer does not fit in an integer on 64 bit arches. > > A pointer is 64 bit, an integer 32 bit. > > This is bug #314666 revisited. Fix proposed there was mostly incorporated > upstream, but not complete. The part not included by upstream was the > change of int (and boolean, which seems mapped to int) to long in the > above lines, so this problem reappears. > > I have been playing to build a lenny x86_64 backport (I still use idraw > frequently). I successfully built the package with gcc 4.3 in a x86_64 > lenny box with attached patch. Instead of changing int and boolean to > long in offending lines I changed it to intptr_t (and unsigned int to > uintptr_t), from stdint.h. Seems included by default, so no need of > explicitly including that header. > > I expect it to also build properly in a x86_64 sid box, but cannot check > now. Since stdint.h is provided by libc6 since some time ago I hope it > is available in all currently released arches. intptr_t and uintptr_t are c99 standard types to handle this kind of things. I think they should already be available in all Debian arches. > Note that attached patch is only what I used to build the package, so is > neither tagged as a NMU nor closes the bug. Not sure about the NMU policy > for QA maintained packages, but if you want me to turn that into a real > NMU just tell. Actually I have an NMU ready, in case you want me to upload. diff is attached. -- Agustin diff -wu ivtools-1.2.6/debian/changelog ivtools-1.2.6/debian/changelog --- ivtools-1.2.6/debian/changelog +++ ivtools-1.2.6/debian/changelog @@ -1,3 +1,14 @@ +ivtools (1.2.6-1+nmu1) unstable; urgency=low + + * Non-maintainer upload. + * 48_gcc40_int_pointer_errors.diff: New patch to fix some gcc40 errors. ++ A pointer does not fit in an integer on 64 bit arches. A pointer + is 64 bit, an integer 32 bit. Use (u)intptr_t instead of + (unsigned) int (Closes: #545834). + * debian/rules: Remove empty -p parameter to dh_installdocs. + + -- Agustin Martin Domingo Tue, 29 Sep 2009 13:02:03 +0200 + ivtools (1.2.6-1) unstable; urgency=low * QA upload. diff -wu ivtools-1.2.6/debian/rules ivtools-1.2.6/debian/rules --- ivtools-1.2.6/debian/rules +++ ivtools-1.2.6/debian/rules @@ -146,7 +146,7 @@ -rm -f $(CURDIR)/debian/libiv-unidraw1/usr/lib/libIV.so.* #Remove ivmkmf from ivtools-bin package. -rm -f $(CURDIR)/debian/ivtools-bin/usr/bin/ivmkmf - dh_installdocs -p + dh_installdocs # dh_installexamples -a dh_installmenu ivtools-bin dh_installman -p$(PKG_BIN) -Xsrc/man/man1/ivmkmf.1 diff -wu ivtools-1.2.6/debian/patches/series ivtools-1.2.6/debian/patches/series --- ivtools-1.2.6/debian/patches/series +++ ivtools-1.2.6/debian/patches/series @@ -41,0 +42 @@ +48_gcc40_int_pointer_errors.diff only in patch2: --- ivtools-1.2.6.orig/debian/patches/48_gcc40_int_pointer_errors.diff +++ ivtools-1.2.6/debi
Bug#545834: Yes Please! (Regarding ivtools 64-bit patch)
forwarded 545834 ivtools-de...@lists.sourceforge.net thanks On Wed, Oct 21, 2009 at 07:16:08PM +0100, Barak A. Pearlmutter wrote: > > Source: ivtools ... intptr_t and uintptr_t are c99 standard types > > ... I have an NMU ready ... > > Nice patch. I'm not QA but I am a DD. And an avid idraw/drawtool > user. And I vote YES! Yes, please NMU so I can have precious idraw > and drawtools on my amd64 box. Yes I say. Yes! Yes! Yes! Since nobody else added comments about the proposed changes, I will upload my NMU on Monday with no delay, unless there are objections before. In the meantime I resent the info to upstream devel list, now after explicit subscription (my previous message seems to have become lost in moderation). https://lists.sourceforge.net/lists/listinfo/ivtools-devel Cheers, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549407: ivtools 1.2.6-1 FTBFS on sparc
On Sat, Oct 03, 2009 at 09:17:52AM +0200, Andreas Barth wrote: > Package: ivtools > Version: 1.2.6-1 > Severity: serious > > Hi, > > this package FTBFS on sparc: > > make[2]: Entering directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6' > depending for LINUX in > /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src > make[3]: Entering directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src' > depending for LINUX in > /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common > make[4]: Entering directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common' > depending for LINUX in > /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX > make[5]: Entering directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX' > g++ -M -w -DMAKEDEPEND -Dcplusplus_2_1 -Wno-deprecated > -I/build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX/.. > -I/build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX/../.. > -I/build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src > -I/build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/include > -I/build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/include/ivstd > -I/usr/include -I/usr/local/include -UHAVE_ACE > /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX/../*.c > >Makefile.depend > g++: > /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX/../*.c: > No such file or directory > g++: no input files > make[5]: *** [depend] Error 1 > make[5]: Leaving directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX' > make[4]: *** [depend] Error 2 > make[3]: *** [depend] Error 2 > make[4]: Leaving directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common' > make[3]: Leaving directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src' > make[2]: *** [depend] Error 2 > make[2]: Leaving directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6' > > make subdirs > make[2]: Entering directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6' > making all for LINUX in > /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src > make[3]: Entering directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src' > making all for LINUX in > /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common > make[4]: Entering directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common' > making all for LINUX in > /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX > make[5]: Entering directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX' > make[5]: *** No rule to make target > `/build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX/../math.c', > needed by `math.o'. Stop. > make[5]: Leaving directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX' > make[4]: *** [all] Error 2 > make[4]: Leaving directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common' > make[3]: *** [all] Error 2 > make[3]: Leaving directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src' > make[2]: Leaving directory > `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6' Hi, debian-sparc people, This is a strange FTBFS. I uploaded a NMU fixing the 64bit build (#545834), but seems that this problem is not a temporary buildd problem but is still present. More funny, build previously worked for powerpc, but now a bug similar to this one appeared (nothing was touched in that area), so this particular FTBFS currently happens only in sparc and in powerpc. I am thinking about a race condition, but want to look more. I'd like to try building the package in smetana and see what happens, but libace-dev is missing from its sid dchroot. What is the procedure for asking libace-dev be installed in sid chroot at smetana.debian.org? Cheers, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549407: ivtools 1.2.6-1 FTBFS on sparc
On Tue, Oct 27, 2009 at 01:49:37PM +0100, Agustin Martin wrote:
> Hi, debian-sparc people,
>
> This is a strange FTBFS. I uploaded a NMU fixing the 64bit build (#545834),
> but
> seems that this problem is not a temporary buildd problem but is still
> present.
> More funny, build previously worked for powerpc, but now a bug similar to this
> one appeared (nothing was touched in that area), so this particular FTBFS
> currently happens only in sparc and in powerpc. I am thinking about a race
> condition, but want to look more.
>
> I'd like to try building the package in smetana and see what happens, but
> libace-dev is missing from its sid dchroot.
I finally could build this package sucessfully at smetana.debian.org. No
problems appeared with the sid dchroot, so this seems to be indeed a race
condition because lebrun seems to be a faster box than smetana.
I plan to upload a new NMU with minimal changes.
One is just calling the offending target (where things fail) with -j1. Seems
that the only way to really test this in a equivalent box is a new upload
(Yes, I hate this).
I also plan to fix lintian error
* E weak-library-dev-dependency
* ivtools-dev on libiv1 (>= ${binary:Version})
* ivtools-dev on libiv-unidraw1 (>= ${binary:Version})
Since I uploaded last NMU and changes are minimal, I will probably do this
with no delay and soon. I will however wait a couple of days for
suggestions/objections. Comments are of course welcome.
Regards,
--
Agustin
--
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549407: [buildd-tools-devel] Bug#549407: ivtools 1.2.6-1 FTBFS on sparc and powerpc
reassign 549407 buildd.debian.org,ivtools thanks 2009/11/6 Roger Leigh : > On Fri, Nov 06, 2009 at 04:20:31PM +0100, Agustin Martin wrote: >> >> I am looking at #549407 and noticed that both powerpc and sparc autobuilders >> seem to use two temporary dirs at the same time, > > I think those buildds may be missing the binNMU versioning fix > in commit 817aea8c, but I don't have access to check that. Thanks for the hint. May that be the origin for #549407? I have looked at all the ivtools logs and everything points to powerpc (praetorious) and sparc (lebrun) autobuilders having something different to all the other similar autobuilders where ivtools has been processed. Build *suceeds* in amd64 (sbuild/amd64 98 on nautilus), ia64 (sbuild/ia64 98 on caballero), mips (sbuild/mips 99.99 on ball), having what seems to be an old sbuild. Build *suceeds* in alpha (sbuild 0.58.2 (15 Jun 2009) on goetzs), armel (sbuild 0.58.2 (15 Jun 2009) on argento), mipsel ( sbuild 0.58.2 (15 Jun 2009) on rem), s390 (sbuild 0.58.2 (31 Jul 2009) on debian-31), having the new sbuild. Build *fails* in powerpc (sbuild 0.58.2 (15 Jun 2009) on praetorius), sparc (sbuild 0.58.2 (15 Jun 2009) on lebrun), all having the new sbuild. Is only in this last two autobuilders where I see two different temporaty directories being used simultaneously. buildd-ivtools_1.2.6-1+nmu2-1-2p04ki != buildd-ivtools_1.2.6-1+nmu2-powerpc-2p04ki buildd-ivtools_1.2.6-1+nmu2-1-6yM9Gd != buildd-ivtools_1.2.6-1+nmu2-sparc-6yM9G In all of alpha, armel, mipsel and s390 autobuilders, where build suceeds, no such behavior is found and a single temporary dir is used consistently during all the build. SInce there is something strange in powerpc and sparc autobuilders that may be related to #549407 I am reassigning this bug report to both buildd.debian.org and ivtools. If this is finally not related to the autobuilders, please reassign it back to ivtools alone. I have a new upload ready just to remove the -j1 stuff I added in previous upload. I was convinced at that time that this was a race condition where -j1 may help. Since this seems not true, better leave the package wihout the -j1, so changes are kept minimal and parallel processing can be attempted. I however will not upload this shortly. Will wait before for buildd admins comments. Thanks for your help, Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549407: [buildd-tools-devel] Bug#549407: ivtools 1.2.6-1 FTBFS on sparc and powerpc
On Mon, Nov 09, 2009 at 01:20:55PM +0100, Agustin Martin wrote: > reassign 549407 buildd.debian.org,ivtools > thanks > > 2009/11/6 Roger Leigh : > > On Fri, Nov 06, 2009 at 04:20:31PM +0100, Agustin Martin wrote: > >> > >> I am looking at #549407 and noticed that both powerpc and sparc > >> autobuilders > >> seem to use two temporary dirs at the same time, > > > > I think those buildds may be missing the binNMU versioning fix > > in commit 817aea8c, but I don't have access to check that. > > Thanks for the hint. May that be the origin for #549407? Answering myself. No, it is not. I have prepared an sbuild+schroot setup in a i386 box, using lenny schroot and bleeding edge sbuild (HEAD from sbuild git repo, 355a4dffe742445713ea089436da077fc7a40ae8). I can reproduce the problem with that sbuild version in the i386 box. However, I cannot reproduce it at all with pbuilder or with plain build in normal filesystem. ivtools uses imake to regenerate makefiles on each run. When the problem is reproduced, I noticed that the path set by imake is something (wrong) like .../buildd-ivtools_1.2.6-1+nmu2-1-2p04ki while the real path is something like .../buildd-ivtools_1.2.6-1+nmu2-powerpc-2p04ki I tried to look how that happens, or at least find a workaround, but was still unlucky. Why this does not happen in all autobuilders using new sbuild is puzzling me. More updates to this bug report. ivtools now builds in powerpc. It has now been queued to "voltaire" (using old sbuild) instead of "praetorius" (using the new one). The only arch where is not building is sparc, where "lebrun" has been used for all failed builds. > Build *suceeds* in amd64 (sbuild/amd64 98 on nautilus), ia64 > (sbuild/ia64 98 on caballero), > mips (sbuild/mips 99.99 on ball), having what seems to be an old sbuild. > > Build *suceeds* in alpha (sbuild 0.58.2 (15 Jun 2009) on goetzs), > armel (sbuild 0.58.2 (15 Jun > 2009) on argento), mipsel ( sbuild 0.58.2 (15 Jun 2009) on rem), s390 > (sbuild 0.58.2 (31 Jul 2009) > on debian-31), having the new sbuild. > > Build *fails* in powerpc (sbuild 0.58.2 (15 Jun 2009) on praetorius), > sparc (sbuild 0.58.2 (15 Jun > 2009) on lebrun), all having the new sbuild. I wonder what is different between buildds using new sbuild that makes this work in ones and fail in others. -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549407: [buildd-tools-devel] Bug#549407: ivtools 1.2.6-1 FTBFS on sparc and powerpc
2009/11/9 Agustin Martin : > Answering myself. No, it is not. I have prepared an sbuild+schroot setup in > a i386 box, using lenny schroot and bleeding edge sbuild (HEAD from sbuild > git repo, 355a4dffe742445713ea089436da077fc7a40ae8). > > I can reproduce the problem with that sbuild version in the i386 box. > However, I cannot reproduce it at all with pbuilder or with plain build in > normal filesystem. > > ivtools uses imake to regenerate makefiles on each run. When the problem is > reproduced, I noticed that the path set by imake is something (wrong) like > > .../buildd-ivtools_1.2.6-1+nmu2-1-2p04ki > > while the real path is something like > > .../buildd-ivtools_1.2.6-1+nmu2-powerpc-2p04ki Good news. I finally found the reason for this problem. An explanation was not that far. Quoting http://www.ivtools.org/ivtools/faq.html, --- * The absolute pathname used by the "make depend" pass is not the same as the ABSTOP pathname written to config/config.mk by the configure script. There is a vulnerability in the "make Makefiles" pass (the use of imake), where absolute pathnames that incorporate predefined C symbols get these symbols expanded to another value. For example, most PC-based uses of gcc have i386 defined to 1, so a path like /usr/src/i386/ivtools-1.0 gets expanded to /usr/src/1/ivtools-1.0. To check the set of pre-defined symbols, enter this command: touch test.c;gcc -dM -E test.c. You can either rename the affected directory in which ivtools resides, or you can add -U undefine arguments as necessary to the imake command line. See the definition of ImakeFlags in config/site.def.NETBSD for an example. --- As I understand it, this problem should also be present in other packages using imake. Not sure if many packages still use imake, but if so there is a problem with the temporary dir naming in sbuild. However, this problem seems a bit nonsensic, so if only few packages still use imake we can try working around this problem by making sure imake is invoked with -U`dpkg --print-architecture`. I hope this has no side effects. I am attaching a patch with the current changes in my box. I can successfully build ivtools with sbuild in this i386 box where I previously could not. It includes some other minor changes: - Revert the -j introduced in my last NMU. - Disable 015_Makefile_dontstrip.diff. Since imake rewrites Makefile, patches for it cannot be reverted later if built in the same dir. This is now done in configure through config.mk. Comments are more than welcome. If there are no objections I will set the final version number and upload at some time in the middle of next week. Cheers, -- Agustin diff -u ivtools-1.2.6/debian/changelog ivtools-1.2.6/debian/changelog --- ivtools-1.2.6/debian/changelog +++ ivtools-1.2.6/debian/changelog @@ -1,3 +1,16 @@ +ivtools (1.2.6-1+nmu2~a3) unstable; urgency=low + + * Non-maintainer upload. + * debian/rules: +- Reverting 1.2.6-1+nmu2 -j1 addition to keep package clean. +- Fix ARCH evaluation. +- Use generic $(MAKE) instead of make. +- Make sure imake is always called with -U$(ARCH) (Closes: #549407). + * 01_configure.diff: Handle disabling of early binary stripping. + * 015_Makefile_dontstrip.diff: Disable patch. + + -- Agustin Martin Domingo Sun, 06 Dec 2009 04:41:51 +0100 + ivtools (1.2.6-1+nmu2) unstable; urgency=low * Non-maintainer upload. diff -u ivtools-1.2.6/debian/rules ivtools-1.2.6/debian/rules --- ivtools-1.2.6/debian/rules +++ ivtools-1.2.6/debian/rules @@ -16,7 +16,7 @@ # so for alpha we just don't have ace, who uses it # anyhow ? -ARCH = $(dpkg --print-architecture) +ARCH = $(shell dpkg --print-architecture) ifeq "$(ARCH)" "alpha" ACE = @@ -24,6 +24,9 @@ # ACE = --with-ace=/usr/include --with-ace-libs=/usr/lib endif +# Make sure this symbol is disabled when imake is invoked. +MAKE += SPECIAL_IMAKEFLAGS="-U$(ARCH)" + build: build-stamp build-stamp: dh_testdir @@ -41,9 +44,9 @@ # Compile the packages - make Makefile ARCH=LINUX - make Makefiles ARCH=LINUX - make -j1 ARCH=LINUX + $(MAKE) Makefile ARCH=LINUX + $(MAKE) Makefiles ARCH=LINUX + $(MAKE) ARCH=LINUX # BUILD FINISHED # --- @@ -59,8 +62,8 @@ --mandir=$(CURDIR)/debian/tmp/usr/share/man cd src/scripts && \ - make ARCH=LINUX clean && \ - make ARCH=LINUX CONFIGDIRSPEC='-T template -I/usr/lib/ivtools/config -DCURDIR=\$(CURDIR)'\ + $(MAKE) ARCH=LINUX clean && \ + $(MAKE) ARCH=LINUX CONFIGDIRSPEC='-T template -I/usr/lib/ivtools/config -DCURDIR=\$(CURDIR)'\ MAKEMAKESPEC='ARCH=LINUX' touch build-stamp @@ -83,8 +86,8 @@ -rm config.cache -rm -rf static shared - [ ! -f Makefile ] || make ARCH=LINUX clean - [ ! -f src/scripts/Makefile ] || (
Bug#549407: [buildd-tools-devel] Bug#549407: ivtools 1.2.6-1 FTBFS on sparc and powerpc
2009/12/6 Agustin Martin :
>
> Good news. I finally found the reason for this problem. An explanation
> was not that far. Quoting http://www.ivtools.org/ivtools/faq.html,
>
> ---
> ... For example, most
> PC-based uses of gcc have i386 defined to 1, so a path like
> /usr/src/i386/ivtools-1.0 gets expanded to /usr/src/1/ivtools-1.0. ..
> ---
>
> As I understand it, this problem should also be present in other
> packages using imake. Not sure if many packages still use imake, but
> if so there is a problem with the temporary dir naming in sbuild.
In case this is ever needed, seems that is enough to change to a
lowbar one of the hyphen $(ARCH) boundaries in tempdir name, like in
-
--- Build.pm.orig 2009-11-20 19:48:42.0 +0100
+++ Build.pm2009-12-07 01:00:07.0 +0100
@@ -233,7 +233,7 @@
$self->set('Chroot Build Dir',
tempdir($self->get_conf('USERNAME') . '-' .
$self->get('Package_SVersion') . '-' .
- $self->get('Arch') . '-XX',
+ $self->get('Arch') . '_XX',
DIR => $session->get('Build Location')));
# TODO: Don't hack the build location in; add a means to customise
# the chroot directly.
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549407: [buildd-tools-devel] Bug#549407: ivtools 1.2.6-1 FTBFS on sparc and powerpc
clone 549407 -1 reassign -1 xutils-dev retitle -1 imake: Must not unconditionally mangle pre-defined symbols in paths. thanks On Tue, Dec 08, 2009 at 03:01:12PM +, Roger Leigh wrote: > Thanks for identifying the cause of the problem! > > So, to state the problem clearly: Imake is substituting the > $(ARCH) part of the path to something else. Such as 'i386' being > swapped for something else entirely, thus resulting in an > invalid path. Exactly. This is particularly obscure, since not all arch names have the associated symbol defined, e.g., I could not reproduce this with amd64, and there were no problems with other autobuilders using new sbuild, but there were with i386, sparc and powerpc. > This is, IMO, completely broken on the part of Imake. Agreed > I'm reluctant > to alter sbuild to accommodate such bad behaviour. For one thing, > it can substitute /any part/ of the path, so there's no guarantee it > won't randomly break on the XX random part or any other path > component for any given build. The "fix" just makes the arch > mismatch because underscore makes the two parts a single token, but > that is not to say it will /never/ match. I accept that it solves > the immediate issue, but it doesn't correct the fundamental > underlying defect in imake. > > What's worse is that the random path might actually be /valid/, in > which case it might scribble junk into, or delete files from, a > directory other than the build directory. Unlikely, but possible, > so a potential security problem on the buildd. Agreed also, but note that there is the same potential problem with the current setup. IIRC, few packages still use imake, so this is not at all a generalized problem. The only action I'd currently expect to be considered from the sbuild side is documenting this misbehavior. I agree that this is an imake misbehavior, so I am cloning this bug report and reassigning the clone to xutils-dev. I am keeping current RC severity, xutils-dev maintainers, please readjust at your will. > Is this possible to fix in ivtools using the -u option to undefine > things as suggested in the FAQ? Given the package-specific nature > of the problem, I feel this would be a more appropriate place for > a fix. Yes, that is the scheduled fix. Unfortunately, the buildd-tools mailing list stripped the patch, this is the relevant part, +# Make sure this symbol is disabled when imake is invoked. +MAKE += SPECIAL_IMAKEFLAGS="-U$(ARCH)" + and changed make->$(MAKE). In practice, this should only affect the Makefile and Makefiles targets. However, I did not check carefully if there is other indirect imake invocation, so doing things this way does not hurt. I expect to upload a fixed ivtools NMU today. Cheers, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560203: FTBFS: New failure with new gcc-4.4.
Package: ivtools Version: 1.2.6 Severity: serious Justification: Fails to Build From Source While preparing an upload to fix #549407 found a new FTBFS with new gcc 4.4, g++ -O2 -gdwarf-2 -O2 -fPIC -Dcplusplus_2_1 -Wno-deprecated -I/tmp/buildd/ivtools-1.2.6/src/IV-common/LINUX/.. - -I/tmp/buildd/ivtools-1.2.6/src/IV-common/LINUX/../.. - - -I/tmp/buildd/ivtools-1.2.6/src -I/tmp/buildd/ivtools-1.2.6/src/include - - - -I/tmp/buildd/ivtools-1.2.6/src/include/ivstd -I/usr/include -c - - - - /tmp/buildd/ivtools-1.2.6/src/IV-common/LINUX/../string.c /tmp/buildd/ivtools-1.2.6/src/IV-common/LINUX/../string.c: In member / function 'osString osString::before(const char*) const': /tmp/buildd/ivtools-1.2.6/src/IV-common/LINUX/../string.c:304: error: / invalid conversion from 'const char*' to 'char*' /tmp/buildd/ivtools-1.2.6/src/IV-common/LINUX/../string.c: In member / function 'osString osString::from(const char*) const': /tmp/buildd/ivtools-1.2.6/src/IV-common/LINUX/../string.c:316: error: / invalid conversion from 'const char*' to 'char*' Will check if is fixed in upstream 1.2.8 and try to backport a fix if so. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.31-1-686 (SMP w/1 CPU core) Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549407: [buildd-tools-devel] Bug#549407: ivtools 1.2.6-1 FTBFS on sparc and powerpc
On Wed, Dec 09, 2009 at 01:55:11PM +0100, Agustin Martin wrote: > I expect to upload a fixed ivtools NMU today. Uploaded. Took a bit longer because of a new RC bug with current sid gcc 4.4 and another problem with uintptr_t. Patch is attached. Unfortunately, seems that although it properly built in i386 pbuilder, at least in amd64 there are more gcc4.4 problems pending that did not show in i386. -- Agustin diff -u ivtools-1.2.6/debian/changelog ivtools-1.2.6/debian/changelog --- ivtools-1.2.6/debian/changelog +++ ivtools-1.2.6/debian/changelog @@ -1,3 +1,20 @@ +ivtools (1.2.6-1+nmu3) unstable; urgency=low + + * Non-maintainer upload. + * debian/rules: +- Reverting 1.2.6-1+nmu2 -j1 addition to keep package clean. +- Fix ARCH evaluation. +- Use generic $(MAKE) instead of make. +- Make sure imake is always called with -U$(ARCH) (Closes: #549407). + * 01_configure.diff: Handle disabling of early binary stripping. + * 015_Makefile_dontstrip.diff: Disable patch. + * 49_string.c_constchar.diff: New patch to deal with gcc 4.4 'invalid +conversion from 'const char*' to 'char*'' errors (Closes: #560203). + * 48_gcc40_int_pointer_errors.diff: Modified to use (unsigned intptr_t) +instead of (uintptr_t) to avoid out-of-context errors. + + -- Agustin Martin Domingo Wed, 09 Dec 2009 18:13:03 +0100 + ivtools (1.2.6-1+nmu2) unstable; urgency=low * Non-maintainer upload. diff -u ivtools-1.2.6/debian/rules ivtools-1.2.6/debian/rules --- ivtools-1.2.6/debian/rules +++ ivtools-1.2.6/debian/rules @@ -16,7 +16,7 @@ # so for alpha we just don't have ace, who uses it # anyhow ? -ARCH = $(dpkg --print-architecture) +ARCH = $(shell dpkg --print-architecture) ifeq "$(ARCH)" "alpha" ACE = @@ -24,6 +24,9 @@ # ACE = --with-ace=/usr/include --with-ace-libs=/usr/lib endif +# Make sure this symbol is disabled when imake is invoked. See #549407. +MAKE += SPECIAL_IMAKEFLAGS="-U$(ARCH)" + build: build-stamp build-stamp: dh_testdir @@ -41,9 +44,9 @@ # Compile the packages - make Makefile ARCH=LINUX - make Makefiles ARCH=LINUX - make -j1 ARCH=LINUX + $(MAKE) Makefile ARCH=LINUX + $(MAKE) Makefiles ARCH=LINUX + $(MAKE) ARCH=LINUX # BUILD FINISHED # --- @@ -59,8 +62,8 @@ --mandir=$(CURDIR)/debian/tmp/usr/share/man cd src/scripts && \ - make ARCH=LINUX clean && \ - make ARCH=LINUX CONFIGDIRSPEC='-T template -I/usr/lib/ivtools/config -DCURDIR=\$(CURDIR)'\ + $(MAKE) ARCH=LINUX clean && \ + $(MAKE) ARCH=LINUX CONFIGDIRSPEC='-T template -I/usr/lib/ivtools/config -DCURDIR=\$(CURDIR)'\ MAKEMAKESPEC='ARCH=LINUX' touch build-stamp @@ -83,8 +86,8 @@ -rm config.cache -rm -rf static shared - [ ! -f Makefile ] || make ARCH=LINUX clean - [ ! -f src/scripts/Makefile ] || (cd src/scripts;make clean) + [ ! -f Makefile ] || $(MAKE) ARCH=LINUX clean + [ ! -f src/scripts/Makefile ] || (cd src/scripts;$(MAKE) clean) # remove backups -rm -f `find . -name "*~"` @@ -102,10 +105,10 @@ dh_installdirs # Add here commands to install the package into debian/tmp. - make install ARCH=LINUX DESTDIR=$(CURDIR)/debian/tmp + $(MAKE) install ARCH=LINUX DESTDIR=$(CURDIR)/debian/tmp cp debian/template $(CURDIR)/debian/tmp/usr/lib/ivtools/config/ - [ ! -f src/glyphs/Makefile ] || (cd src/glyphs && make clean) + [ ! -f src/glyphs/Makefile ] || (cd src/glyphs && $(MAKE) clean) # don't include the scripts # ivtools installs the libACE link, we remove it ... hack diff -u ivtools-1.2.6/debian/patches/series ivtools-1.2.6/debian/patches/series --- ivtools-1.2.6/debian/patches/series +++ ivtools-1.2.6/debian/patches/series @@ -1,5 +1,4 @@ 01_configure.diff -015_Makefile_dontstrip.diff 02_rules_def.diff 025_params_def.diff 026_geomobjs_c.diff @@ -42,0 +42 @@ +49_string.c_constchar.diff diff -u ivtools-1.2.6/debian/patches/01_configure.diff ivtools-1.2.6/debian/patches/01_configure.diff --- ivtools-1.2.6/debian/patches/01_configure.diff +++ ivtools-1.2.6/debian/patches/01_configure.diff @@ -1,8 +1,15 @@ -Index: ivtools-1.2/configure +This patch modfies the configure scripts for different purposes: + +* Modify how config/config.mk is built: + - Make 'make CPU' more silent. + - Do not strip binaries during the build process. Will be done later +from debian/rules. + +Index: ivtools-1.2.6/configure === ivtools-1.2.orig/configure 2009-09-04 12:19:47.0 -0400 -+++ ivtools-1.2/configure 2009-09-04 12:20:02.0 -0400 -@@ -5129,8 +5129,8 @@ +--- ivtools-1.2.6.orig/configure 2009-11-30 12:08:21.0 +0100 ivtools-1.2.6/configure 2009-11-30 12:08:54.0 +0100 +@@ -5129,8 +5129,10 @@ echo XCONFIGDIR = $x_libraries/X11/config >config/config.mk
Bug#561089: ispell: segfaults on checking any file
On Mon, Dec 14, 2009 at 02:03:35PM +0100, Helmut Grohne wrote: > Package: ispell > Version: 3.1.20.0-7 > Severity: grave > Justification: renders package unusable > > When I try to spell check any file ispell simply segfaults. When I > invoke it without arguments it prints the help text. To find out whether > this was a recent regression I downgraded the package, but that did not > help. This indicates that the cause may be unrelated to ispell. I also > ran gdb on a core file from ispell, but the traceback did not reveal > anything useful. Running strace in ispell shows that it uses curses to > set up the terminal and then segfaults right after reading the file to > be checked. > > Is there anything else I can do to help diagnose this? That seems related to this ingerman installation error Unpacking ingerman (from .../ingerman_20091006-2_all.deb) ... Setting up ingerman (20091006-2) ... ispell-autobuildhash: Processing 'ngerman' dict Hash table overflowed by 1342 words Does this happen with other dictionaries? -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#572372: O: wdm -- WINGs Display Manager - an xdm replacement with a WindowMaker look
On Wed, Mar 03, 2010 at 08:28:47PM +0100, Jan Hauke Rahm wrote: > Package: wnpp > Severity: normal > > The current maintainer of wdm, Vlad Shakhov , > is not active anymore. Therefore, I orphan this package now. No, I do not intend to adopt this package, but have some changes ready for it. I was making some NMU for it lately and was playing a bit more after the last one. Last changes in my side include severity normal #571611 [wdm: Please provide a Xreset hook using a common framework] and fixing piuparts sid uninstallation error, http://piuparts.debian.org/sid/fail/wdm_1.28-3.4.log I also noticed that although tries to enable selinux when running configure, it is actually not set because does not build-depends on libselinux-dev. Changes also include making emacs and vi editing options closer and sanitizing indentation (postrm one was insane). Since nobody has yet intended to adopt the package, let me know if you think is OK to upload my changes along with changing maintainership to the QA team. For prospective maintainers, seems to be no news from upstream in some time, so anyone adopting this package should probably act as upstream. I have put all my changes in a git repo, so if anyone is interested in maintaining this package, it can be made available through collab-maint or through watever way is desired. Changes (excluding whitespace ones) are attached. Cheers, -- Agustin diff -wu wdm-1.28/debian/changelog wdm-1.28/debian/changelog --- wdm-1.28/debian/changelog +++ wdm-1.28/debian/changelog @@ -1,3 +1,16 @@ +wdm (1.28-3.5~2) unstable; urgency=low + + * debian/control: Really enable selinux in linux targets by +adding libselinux1-dev to Build-Depends for them. + * debian/config/Xreset: Use common Xreset framework if +available (Closes: #571611). + * Remove /etc/X11/default-display-manager if debconf question +db_get shared/default-x-display-manager no longer exists. Was +left behind in purge when no other X display managers were +installed. + + -- Agustin Martin Domingo Fri, 12 Mar 2010 14:27:51 +0100 + wdm (1.28-3.4) unstable; urgency=low * Non-maintainer upload. diff -wu wdm-1.28/debian/control wdm-1.28/debian/control --- wdm-1.28/debian/control +++ wdm-1.28/debian/control @@ -9,6 +9,7 @@ libpam0g-dev, libwings-dev, libwraster3-dev, zlib1g-dev, libxdmcp-dev, libxinerama-dev, libxkbfile-dev, libxmu-dev, libx11-dev, libxau-dev, libxt-dev, + libselinux1-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], x11proto-core-dev, libxft-dev, x11-xserver-utils Package: wdm diff -wu wdm-1.28/debian/wdm.prerm wdm-1.28/debian/wdm.prerm --- wdm-1.28/debian/wdm.prerm +++ wdm-1.28/debian/wdm.prerm @@ -196,0 +197,6 @@ + +# Local Variables: +# mode: shell-script +# sh-indentation: 2 +# sh-basic-offset: 2 +# End: diff -wu wdm-1.28/debian/wdm.postrm wdm-1.28/debian/wdm.postrm --- wdm-1.28/debian/wdm.postrm +++ wdm-1.28/debian/wdm.postrm @@ -7,6 +7,7 @@ log_file=/var/log/wdm-errors pid_file=/var/run/wdm.pid +DEFAULT_DISPLAY_MANAGER_FILE=/etc/X11/default-display-manager case "$1" in remove) @@ -18,6 +19,13 @@ if [ -e /usr/share/debconf/confmodule ]; then . /usr/share/debconf/confmodule db_purge + # Remove default display manager file if question not present + if ! db_get shared/default-x-display-manager; then + if [ -f $DEFAULT_DISPLAY_MANAGER_FILE ]; then + echo "wdm.postrm: Removing file $DEFAULT_DISPLAY_MANAGER_FILE" >&2 + rm -f $DEFAULT_DISPLAY_MANAGER_FILE + fi + fi fi rmdir /etc/X11/wdm > /dev/null 2>&1 || true rmdir /var/lib/wdm/authdir/authfiles || true @@ -41,0 +50,9 @@ + + +# vim:set ai et sts=2 sw=2 tw=0: + +# Local Variables: +# mode: shell-script +# sh-indentation: 2 +# sh-basic-offset: 2 +# End: diff -wu wdm-1.28/debian/config/Xreset wdm-1.28/debian/config/Xreset --- wdm-1.28/debian/config/Xreset +++ wdm-1.28/debian/config/Xreset @@ -4,6 +4,11 @@ # # This script is run as root after any X session ends. +# Use common X11 Xreset framework if available +if [ -x /etc/X11/Xreset ]; then + /etc/X11/Xreset +fi + # Remove the utmp entry for the session if grep -q ^use-sessreg /etc/X11/wdm/wdm.options; then sessreg -d -l $DISPLAY -u /var/run/utmp -x /etc/X11/wdm/Xservers $USER
Bug#582612: prompting due to modified conffiles which where not modified by the user
On Sat, May 22, 2010 at 10:44:25AM +0200, Holger Levsen wrote: > Package: wdm > Version: 1.28-3.5 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts piuparts.d.o > > Hi, > > during a test with piuparts I noticed your package failed the piuparts > upgrade > test because dpkg detected a conffile as being modified and then prompted the > user for an action. As there is no user input, this fails. But this is not > the real problem, the real problem is that this prompt shows up in the first > place, as there was nobody modifying this conffile at all, the package has > just been installed and upgraded... Hi, Holger This is caused by the insane way wdm handles refreshing of wm list, it directly modifies entry in wdm-config everytime wdm is started or stopped. I am attaching a first cut of a patch to care of this. Instead of directly modifying wdm-config itself, a new detached file is used to hold that info. That file is automatically regenerated on each wdm start/stop and loaded from wdm-config. Sysadmins can override automatic selection by setting that value again after that file is loaded, as pointed out in directions added to wdm-config. This will not prevent prompting when upgrading from previous versions, but should leave this problem addressed for the future. I will test a bit more, and if everything works as expected I will upload a fixed package. Since wdm is under QA team maintenance, one question, do I version it as a NMU or as a QA upload? (although I am not member of the QA team) Cheers, -- Agustin >From 7645f1ed7d107d3befa7540ce8b7a5c0f71a6bcd Mon Sep 17 00:00:00 2001 From: Agustin Martin Domingo Date: Tue, 25 May 2010 14:51:58 +0200 Subject: [PATCH] Move 'DisplayManager*wdmWm' automatic regeneration to a separate file. This is needed so wdm-config conffile is not modified on every wdm start/stop. We make wdm-config file load the other file (wdm.wmlist) containing autogenerated entry, and allow further override to sysadmins in case they want this value hardcoded. --- debian/changelog |8 ++ debian/config/wdm-config | 16 ++--- debian/update_wdm_wmlist | 55 +- debian/wdm.postrm|1 + 4 files changed, 51 insertions(+), 29 deletions(-) diff --git a/debian/changelog b/debian/changelog index aa4dd85..92a0b07 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +wdm (1.28-3.6) unstable; urgency=low + + * Move 'DisplayManager*wdmWm' automatic regeneration to a separate +file, so wdm-config conffile is not automatically changed +(Closes: #582612). + + -- Agustin Martin Domingo Tue, 25 May 2010 15:17:11 +0200 + wdm (1.28-3.5) unstable; urgency=low * Non-maintainer upload. diff --git a/debian/config/wdm-config b/debian/config/wdm-config index 987e4ef..06f3685 100644 --- a/debian/config/wdm-config +++ b/debian/config/wdm-config @@ -33,10 +33,6 @@ DisplayManager*wdmLogin:/usr/bin/wdmLogin DisplayManager*wdmBg: solid:Gray85 ! DisplayManager*wdmLogo: /usr/share/pixmaps/gnuLogo.xpm DisplayManager*wdmLogo: /usr/share/pixmaps/wdmDebianSwirl.xpm -! BEWARE: the wdmWm setting will be overwritten on every wdm (re)start -! and reload. Please see wdm.options(5) for info on disabling -! this behavior if you want to specify the list manually. -! DisplayManager*wdmWm: twm:wmaker:afterstep DisplayManager*wdmReboot: /sbin/reboot DisplayManager*wdmHalt: /sbin/halt DisplayManager*wdmVerify: true @@ -46,3 +42,15 @@ DisplayManager*wdmLoginConfig: /etc/X11/wdm/wdmlogin.conf DisplayManager*useSyslog: true DisplayManager*syslogFacility: LOG_AUTHPRIV DisplayManager*terminateServer: true + +! Load wm list from autogenerated file + +#include "wdm.wmlist" + +! BEWARE: the wdmWm setting in that file will be overwritten on every wdm +! (re)start and reload. If you want to hardcode your choice, do that +! in the line below, to be processed after previous automatic definition. + +! DisplayManager*wdmWm: twm:wmaker:afterstep + +! Please see wdm.options(5) for info on disabling automatic generation. diff --git a/debian/update_wdm_wmlist b/debian/update_wdm_wmlist index 3e795d6..90aa47d 100644 --- a/debian/update_wdm_wmlist +++ b/debian/update_wdm_wmlist @@ -1,52 +1,57 @@ #!/usr/bin/perl -w # -# update_wdm_wmlist, (c) 1998 Marcelo Magallón -# rewriten to use the x-window-manager alternative -# modified to also use the x-session-manager alternative by Arthur Korn -# Copyright 2000 Wichert Akkerman +# update_wdm_wmlist, # # This script will read the list of installed window managers from # the update-alternatives output for the x-window-manager alternative -# and update the DisplayManager*wdmWm resource in /etc/X11/wdm/wdm-config. +# and update the DisplayManager*wdmWm resource in $wdm_list_file (see below). #
Bug#582612: prompting due to modified conffiles which where not modified by the user
On Tue, May 25, 2010 at 03:20:35PM +0200, Agustin Martin wrote: > I am attaching a first cut of a patch to care of this. Instead of directly > modifying wdm-config itself, a new detached file is used to hold that info. > That file is automatically regenerated on each wdm start/stop and loaded > from wdm-config. Sysadmins can override automatic selection by setting that > value again after that file is loaded, as pointed out in directions added to > wdm-config. > > This will not prevent prompting when upgrading from previous versions, but > should leave this problem addressed for the future. Hi, Seems my tests are working properly, so I have prepared an upload. I finally prepared it it as a QA upload. Besides support for using new detached file, I have also improved copyright notices under debian/. They still referred to unversioned GPL when code was GPL2+. I'd like to upload fixed package around next Monday with 0-day delay, unless someone complains. Current patch is attached. Cheers, -- Agustin diff --git a/debian/changelog b/debian/changelog index aa4dd85..6a12c35 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +wdm (1.28-4) unstable; urgency=low + + * QA upload. + * Move 'DisplayManager*wdmWm' automatic regeneration to a separate +file, so wdm-config conffile is not automatically changed +(Closes: #582612). + * Clarify copyright notices. + + -- Agustin Martin Domingo Thu, 27 May 2010 13:30:21 +0200 + wdm (1.28-3.5) unstable; urgency=low * Non-maintainer upload. diff --git a/debian/config/wdm-config b/debian/config/wdm-config index 987e4ef..06c2f3d 100644 --- a/debian/config/wdm-config +++ b/debian/config/wdm-config @@ -33,10 +33,6 @@ DisplayManager*wdmLogin:/usr/bin/wdmLogin DisplayManager*wdmBg: solid:Gray85 ! DisplayManager*wdmLogo: /usr/share/pixmaps/gnuLogo.xpm DisplayManager*wdmLogo: /usr/share/pixmaps/wdmDebianSwirl.xpm -! BEWARE: the wdmWm setting will be overwritten on every wdm (re)start -! and reload. Please see wdm.options(5) for info on disabling -! this behavior if you want to specify the list manually. -! DisplayManager*wdmWm: twm:wmaker:afterstep DisplayManager*wdmReboot: /sbin/reboot DisplayManager*wdmHalt: /sbin/halt DisplayManager*wdmVerify: true @@ -46,3 +42,16 @@ DisplayManager*wdmLoginConfig: /etc/X11/wdm/wdmlogin.conf DisplayManager*useSyslog: true DisplayManager*syslogFacility: LOG_AUTHPRIV DisplayManager*terminateServer: true + +! Load wm list from file auto-generated by update_wdm_wmlist + +#include "wdm.wmlist" + +! BEWARE: the wdmWm setting in that file will be overwritten on every wdm +! (re)start and reload. If you want to hardcode your choice, uncomment the +! line below and set your choice, to be processed after previous automatic +! definition. + +! DisplayManager*wdmWm: twm:wmaker:afterstep + +! Please see wdm.options(5) for info on disabling automatic generation. diff --git a/debian/copyright b/debian/copyright index 342cf21..090dda5 100644 --- a/debian/copyright +++ b/debian/copyright @@ -2,21 +2,31 @@ This package is maintained by Noah Meyerhans It was previously maintained by Bas Zoetekouw . -It was originally debianized by Marcelo E. Magallon +It was originally debianized by Marcelo E. Magallon mmaga...@debian.org on Sat, 15 Aug 1998 19:55:35 -0600. It was downloaded from http://voins.program.ru/wdm/ -Upstream maintainer for wdm is vo...@voins.program.ru +Upstream maintainer for wdm is Alexey Voinov, vo...@voins.program.ru -Modifications for Debian Linux Copyright (C) 1998 Marcelo Magallon. + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. - wdm is distributed under the terms and conditions of the GPL, the text - of which can be found in /usr/share/common-licenses/GPL. wdm derived - from work by Tom Rothamel (external greeter for xdm, also under the - GPL) and xdm itself, which is copyright (C) 1988, 1989, 1990, 1991, - 1994 X Consortium. The relevant X Consortium's and XFree86's licenses - follows: + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + On Debian GNU/Linux systems, the complete text of the GNU General + Public License can be found in `/usr/share/common-licenses/GPL-2'. + +wdm is derived from work by Tom Rothamel (external greeter for xdm, also +under the GPL) and xdm itself, which is copyright (C) 1988, 1989, 1990, +1991, 1994 X Consortium. + + The relevant X Consortium's and XFree86's licenses follows: 1.
Bug#463598: /var/run/utmp exists, but wdm still doesn't register the session
On Fri, May 21, 2010 at 09:36:47PM +0300, Yury Bulka wrote: > > Hello! Let me firstly thank you for your work on this package and for reading > this:) > So here's what the report is about: > I've also noticed that wdm doesn't register the session it starts to utmp, > but in my case /var/run/utmp exists on my system. > It's strange, because the "sessreg" command is in its place in file > /etc/X11/wdm/Xstartup: > --- > # Insert a utmp entry for the session > if grep -q ^use-sessreg /etc/X11/wdm/wdm.options; then > exec sessreg -a -l $DISPLAY -u /var/run/utmp -x /etc/X11/wdm/Xservers $USER > # NOTREACHED > fi > --- > and the option "use-sessreg" is enabled in /etc/X11/wdm/wdm.options. > I tried to install xdm and it does register the session with almost identical > "sessreg" command (the only difference is the -x parameter which is set to > "/etc/X11/xdm/Xservers" there)... I replaced wdm Xstartup with xdm Xstartup and s/xdm/wdm/g. No luck, it still does not register session. I have verified that $DISPLAY and $USER values just before the sessreg call are correct and so that the sessreg line is processed if use-sessreg is enabled. I am curious, did it register session at some time? In the box where wdm is installed last time /var/log/wdm.log was updated was long time ago, on November 2005 for sid. I wonder what happened at that time. I think about something related to xfree86 -> xorg transition (last xfree86 log in this sid box is from September 2005). Thanks for your feedback, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527173737.ga3...@agmartin.aq.upm.es
Bug#109712: wdm: VNC localhost connection fails with pipe read error
On Wed, Aug 22, 2001 at 08:13:07PM -0700, kms...@ix.netcom.com wrote: > Package: wdm > Version: 1.20-11 > Severity: normal > > When attempting an XDMCP-mediated session via VNC to localhost, the > session fails, and the following error is recorded to daemon.log: > > daemon.log:Aug 22 18:33:07 navel wdm: wdm pipe read error with program > /usr/bin/X11/wdmLogin, wdm terminating Hi, I am looking at some ancient bug reports for this already orphaned package. I am aware that original bug report is 9 years old, so you may no longer be using wdm, but in case you still use it, there is something in above error message that also appeared in http://bugs.debian.org/488715 http://bugs.debian.org/547251 and that was fixed in wdm_1.28-3.5, so you may be interested in try again and see what happens. Thanks for your feedback. -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527180552.ga3...@agmartin.aq.upm.es
Bug#502404: wdm doesn't read ~/.xsession
On Mon, Apr 05, 2010 at 02:44:11PM +0200, Agustin Martin wrote: > On Thu, Feb 19, 2009 at 05:14:43PM +0100, Michelle Konzack wrote: > > Am 2009-02-19 16:44:28, schrieb Michael Jarosch: > > > O.k. - copied both of your files ( .xsession and .tdlocale ) into my > > > ~/-directory, logged out, killed X (because of the strange > > > wdm/ati-xserver behaviour), logged in with wdm and: > > > > > > No change. Wrong locale. Not german. > > > > OK, can you put the following lines > > > > echo "## env ###" > > env > > echo "## locale " > > locale > > echo "## locale -a #" > > locale -a > > echo "##" > > > > before the line > > > > exec $realstartup > > > > and look into the ~/.xsession-errors whats going on here? > > > > Does your locale "de_DE" exist? If not, it falls normaly back to > > /etc/default/locale but maybe there is something wron on your system and > > if falls back to "C". > > Reviewing more old wdm bug reports, count me also as a person that cannot > reproduce this problem. .xsession is used as expected here. > > What Michelle proposed is an interesting info. > > Also, you can verify that .xsession is tried by using from an xterm > > $ ps aux | grep \.xsession > > If this shows some lines using .xsession, it means that is detected and > used. Otherwise grepping for session will show things like > x-session-manager. Hi, Since neither Michelle nor myself could reproduce this problem I tagged it as 'unreproducible'. Please provide info suggested by Michelle and/or myself. If no further info is provided in some time, either by you or by others experiencing a similar problem, bug will be closed (of course, it can be re-opened in case problem persists). Cheers -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531122526.ga11...@agmartin.aq.upm.es
Bug#463598: wdm: sessreg invocation in Xstart up and Xreset doesn't work
On Fri, Feb 01, 2008 at 12:50:25PM -0500, Adam C. Emerson wrote: > Package: wdm > Version: 1.28-2.3 > Severity: normal > > > Due to the nonexistence of utmp on my newly installed system, the > -u /var/log/utmp option to sessreg causes it to not reg sesses. > Removing this option makes everything work perfectly. Looking at some bugs in this orphaned package. Not sure if is a typo, but is /var/run/utmp what is used, not /var/log/utmp. Anyway, seems that in systems with /var/run/utmp there is still no log. See followup to your bug report, http://bugs.debian.org/463598 I tried removing the '-u /var/run/utmp' part from Xstartup, but seems to still not register sessions. Are wdm sesions registered at your site with the change? I compared code in wdm and xdm Xstartups and they looked very similar, so I guess this problem originates somewhere else. In the box where wdm is installed last time /var/log/wdm.log was updated was long time ago, on November 2005 for sid. I wonder what happened at that time. I think about something related to xfree86 -> xorg transition (last xfree86 log in this sid box is from September 2005). Thanks for your feedback, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531134251.ga3...@agmartin.aq.upm.es
Bug#590617: wdm: Why one has to login to do HALT !! Please make LINUX SIMPLE and HUMAN !
severity 590617 wishlist tag 590617 +wontfix thanks On Wed, Jul 28, 2010 at 09:53:49AM +0200, Michelle Konzack wrote: > Am 2010-07-27 22:35:21, schrieb yellow: > > Package: wdm > > Version: 1.28-4 > > Severity: important > > > > Dear Sir, > > > > It is of no senses to make linux asking a login and password to halt it. > > Because it is not realy funny to have someone shutdown the computer > without permissions while you are running backgrond processes? > > Note: My Devel-Workstation is the fastest existing Quad-Phenom and > I do heavy dataprocessing, while I am not on my computer. > > However if you want to shutdown your Computer, configure system to allow > to shutdown the computer. > > > Please a fix asap ! > > WONTFIX! Really tagging wontfix, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100729100431.gb3...@agmartin.aq.upm.es
Re: Adopting dutch dicts + emacs21: ispell.el and dictionnary list
reassign 314622 aspell-nl close314622 1:0.1e-38 merge314622 329181 thanks On Thu, Jun 23, 2005 at 04:49:08PM +0200, Agustin Martin wrote: > On Thu, Jun 23, 2005 at 12:30:16PM +0200, Pascal A. Dupuis wrote: > > To get aspell-nl properly registred, I did the following: > > > > 1) extract the file idutch from package idutch, found under > >/var/lib/dictionaries-common/ispell > > 2) copied it as /var/lib/dictionnaries-common/aspell/aspell-nl > > 3) ran /usr/sbin/update-dictcommon-aspell > > > > So, what's missing: > > - the proper dictionnary definition aspell-nl > > - postinst and postrm scripts which update the aspell dict list > > > > Thanks for taking a look at this. > > You are right in the steps, but is better to add this in aspell-nl package > directly. dutch dicts are currently orphaned, > > http://bugs.debian.org/314839 > > I already mailed the two interested persons about patches I had nearly > ready for dutch dicts, one will deal only with registration and the other > will also deal with affix compression (available for aspell 0.60). This > second revealed some possible inconsistencies in the wordlist that might be > of interest upstream. I am cc'ing these two persons now. > > I will reassign this bugreport to aspell-nl as soon as it has a new > maintainer, I do not want to put noise on QA people in the meantime. If > nodoby finally takes the package I will take it temporarily until finds a > better (dutch speaking) home. The companion bug report [#329181: aspell-nl: fails to interface properly to emacs] has been closed by a QA upload, so I am reassigning this bug report to aspell-nl, closing it as of aspell-nl 1:0.1e-38 and merging it with #329181. Thanks for your feedback. [QA team, nothing else is required on your side] Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465540: post-installation script doesn't work in zsh
On Wed, Feb 13, 2008 at 03:51:28AM +0100, Matthias Berndt wrote: > Package: htdig > Version: 1:3.2.0b6-5 > Severity: normal > > Hi, > I just noticed that the post-installation script fails when /bin/sh points > to /usr/bin/zsh rather than /bin/bash. This should be fixed. FYI, please see similar bug reports http://bugs.debian.org/465537 [Debconf fails to initialise when /bin/sh is zsh] originally submitted against dhcp3-client and reassigned to debconf by Andrew Pollock and http://bugs.debian.org/465539 [Debconf fails to initialise when /bin/sh is zsh] originally submitted to dictionaries-common, reassigned to debconf and merged with #465537 by me Quoting Andrew on #465537 I've never heard of zsh being used as /bin/sh before, and I'm not sure if it's supported, but from my examination, it's something inside /usr/share/debconf/confmodule that is returning non-zero. Putting an echo statement immediately after the ". /usr/share/debconf/confmodule" never executes. Also note that this may well be the same as zsh bug: [#351031] DEBCONF_USE_CDEBCONF - errors with /bin/zsh as /bin/sh originally submitted against debconf and later reassigned to zsh. -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#820748: uniconvertor: ImportError: No module named sk1libs.utils.fs
On Mon, Apr 18, 2016 at 02:00:00AM +0300, Georgios Zarkadas wrote: > I encountered the same bug. > > The missing python modules are contained at the sk1 release tarball at > sourceforge.net (https://sourceforge.net/projects/sk1/). This project is > not yet part of the distribution, although there is an unofficial deb > package provided at the http://sk1project.org/ download page. > > Thus someone has to do the packaging of sk1, or the neccesary modules must > be copied to python-uniconvertor as a patch, or a request to upstream to > fix this issue has to be made. Hi, A while ago I was playing with this and thought that it was properly packaged and uploaded along with python-uniconvertor upgrade. Seems this was not the case. From: https://bugs.debian.org/699301 On Mon, 22 Jul 2013 18:11:57 +0200 Agustin Martin wrote: > The short story, I have been playing on building a 1.1.5 python-uniconvertor > package together with a new package python-sk1libs, the new dependency. > I did a minimal testing and resulting package seems to work, but this is my > first approach to python and everything I did needs extensive reviewing by > someone fluent with python, long story in above bug reports. > > I do not intend to adopt this package, so you may be interested in my > changes in > > http://anonscm.debian.org/gitweb/?p=users/agmartin/TMP/python-sk1libs.git;a=summary > http://anonscm.debian.org/gitweb/?p=users/agmartin/TMP/python-uniconvertor.git;a=summary > > Note that python-modules team seems to have SVN as preferred VCS (fix me if > this is no longer true) I am still not at all fluent with python so I do not intend to do the python-sk1libs packaging, but if someone is interested I hope it can help (even if only as an example of how things should not be done ;-)) Regards, -- Agustin
Bug#820748: uniconvertor: ImportError: No module named sk1libs.utils.fs
On Mon, Jan 30, 2017 at 11:43:24AM +0100, Mattia Rizzolo wrote: > On Mon, Apr 18, 2016 at 02:00:00AM +0300, Georgios Zarkadas wrote: > > The missing python modules are contained at the sk1 release tarball at > > sourceforge.net (https://sourceforge.net/projects/sk1/). This project is > > not yet part of the distribution, although there is an unofficial deb > > package provided at the http://sk1project.org/ download page. > > s/org/net/. > > Here is a more direct link. > https://sk1project.net/modules.php?name=Products&product=sk1libs&op=download > > > Thus someone has to do the packaging of sk1, or the neccesary modules must > > be copied to python-uniconvertor as a patch, or a request to upstream to > > fix this issue has to be made. > > copying as a patch it not really feasible, as it's not feasible to do it > at this time of the devel cycke.. > If I had noticed this bug when it was filed, I could have handled it. > I'm sorry. Hi, Mattia, Some years ago I was playing with python-uniconvertor and a possible python-sk1libs package, when looking at https://bugs.debian.org/699301. What I did is still available from https://anonscm.debian.org/git/users/agmartin/TMP/python-sk1libs.git https://anonscm.debian.org/git/users/agmartin/TMP/python-uniconvertor.git (links updated, those at #699301 no longer work). Since I am not fluent at all with python, I did not prepare a QA package for it and left things there in case someone with the required skills wanted to look at original sources and my hackish and not so hackish changes. I noticed python-uniconvertor upload, but since I was not using it, did not notice that something was not included with it. Anyway, here goes the info in case it is useful. Regards, -- Agustin
Bug#875574: systemd-shim: sdccard change events not detected under sysvinit
Package: systemd-shim Version: 10-3 Severity: normal Dear Maintainer, I have noticed yet another thing that works in systemd but not in sysvinit, so I guess it is systemd-shim issue. When using sysvinit, when I introduce an sdcard in the reader sdcard change event is not detected and no device is created by udev. It is recognised if sdcard is already present during boot or if partprobe is run after inserting sdcard. Trying to access the full device (e.g., trying to mount /dev/sde instead of /dev/sde1) fails as expected, but seems to also trigger detection for later usage. Since this works under systemd I guess there is a missing feature in systemd-shim. I am aware that systemd-shim is orphaned, so I am filing this bug report to at least have this issue documented. Regards, -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), LANGUAGE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages systemd-shim depends on: ii cgmanager 0.41-2 ii libc6 2.24-17 ii libglib2.0-0 2.54.0-1 systemd-shim recommends no packages. Versions of packages systemd-shim suggests: ii pm-utils 1.4.1-17 -- no debconf information -- Agustin
Bug#866472: Uniconvertor 2.0 upstream depends on python-pil and has some .debs
On Fri, Jun 21, 2019 at 07:24:15AM +0200, Xavi Drudis Ferran wrote:
>
> Hello. Maybe you know already (because the problem seems to be lack of
> maintainer). But there is a python-uniconvertor 2.0 that no longer depends on
> python-imaging but on python-pil (python2, I believe)
>
> https://sk1project.net/modules.php?name=Products&product=uniconvertor&op=download
Hi,
Even if that dependency is declared, python-uniconvertor in Debian does
not really depend on python-imaging, but on a copy of it embedded as
sk1libs.imaging in sk1libs, which is not in Debian.
The biggest problem is the lack of sk1libs, because there are some other
functions that are required by uniconvertor as soon as you try to go
beyond the usage message (See https://bugs.debian.org/820748).
I am not a python expert, but for the imaging part I would expect something
similar to attached patch to work. It changes dependency to python-pil and
tries to change calls to sk1libs.imaging stuff to the equivalent PIL calls.
Regards,
--
Agustin
>From eaac5ce28edcab4d022956f8a5eda171de521100 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo
Date: Thu, 27 Jun 2019 15:51:09 +0200
Subject: [PATCH] Depend on python-pil instead of (fake) python-imaging.
This package had a dependency on python-imaging but its real dependency
was on sk1project sk1libs.imaging, a python-imaging copy embedded in
sk1libs.
This patch tries to change sk1libs.imaging calls to PIL, so dependency
can be set to PIL.
---
debian/changelog | 8 +++
debian/control | 2 +-
debian/patches/05_sklibs.imaging2PIL.patch | 59 ++
debian/patches/series | 1 +
4 files changed, 69 insertions(+), 1 deletion(-)
create mode 100644 debian/patches/05_sklibs.imaging2PIL.patch
diff --git a/debian/changelog b/debian/changelog
index 594905a..15be5f8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+python-uniconvertor (1.1.5-5) unstable; urgency=medium
+
+ * QA upload.
+ * Depend on python-pil instead of python-imaging (Really was on
+sk2libs.imaging) (Closes: #866472).
+
+ -- Agustin Martin Domingo Thu, 27 Jun 2019 11:51:10 +0200
+
python-uniconvertor (1.1.5-4) unstable; urgency=medium
* QA upload.
diff --git a/debian/control b/debian/control
index c4e845c..f3703df 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Standards-Version: 3.9.8
Package: python-uniconvertor
Architecture: any
Depends:
- python-imaging,
+ python-pil,
python-reportlab,
${misc:Depends},
${python:Depends},
diff --git a/debian/patches/05_sklibs.imaging2PIL.patch b/debian/patches/05_sklibs.imaging2PIL.patch
new file mode 100644
index 000..9fa6921
--- /dev/null
+++ b/debian/patches/05_sklibs.imaging2PIL.patch
@@ -0,0 +1,59 @@
+Author: Agustin Martin Domingo
+Description: Try using python-pil instead of python-imaging copy embedded in sk1libs.
+
+
+diff --git a/src/app/Graphics/eps.py b/src/app/Graphics/eps.py
+index e587323..bbd4103 100755
+--- a/src/app/Graphics/eps.py
b/src/app/Graphics/eps.py
+@@ -21,7 +21,7 @@
+
+ import os, math
+
+-from sk1libs.imaging import Image
++from PIL import Image
+
+ from app.Lib import dscparser
+ from sk1libs import utils
+diff --git a/src/app/Graphics/graphics.py b/src/app/Graphics/graphics.py
+index 420f7d4..0f85051 100755
+--- a/src/app/Graphics/graphics.py
b/src/app/Graphics/graphics.py
+@@ -29,7 +29,7 @@ from types import TupleType
+ import operator, string
+ from math import atan2, hypot, pi, sin, cos
+
+-from sk1libs import imaging
++import PIL as imaging
+
+ #from app.X11 import X
+ from app.conf import const
+diff --git a/src/app/Graphics/image.py b/src/app/Graphics/image.py
+index bcb7c05..dbfb518 100755
+--- a/src/app/Graphics/image.py
b/src/app/Graphics/image.py
+@@ -24,8 +24,8 @@
+ import os, app
+ from types import StringType
+
+-from sk1libs.imaging import ImageChops
+-from sk1libs import imaging
++import PIL as imaging
++from imaging import ImageChops
+
+ from app import _, RegisterCommands, colormanager
+ #from app.UI.command import AddCmd
+diff --git a/src/app/scripts/export_raster.py b/src/app/scripts/export_raster.py
+index e548c6c..a92a51d 100755
+--- a/src/app/scripts/export_raster.py
b/src/app/scripts/export_raster.py
+@@ -37,7 +37,8 @@
+
+ import os, tempfile
+
+-from sk1libs import imaging.Image, imaging.ImageChops
++from PIL import Image as imaging.Image
++from PIL import ImageChops as imaging.ImageChops
+
+ import app.Scripting
+ from app import _, PostScriptDevice
diff --git a/debian/patches/series b/debian/patches/series
index bb5d10b..33e36f8 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
02_fake_fallback_font.patch
03_fontwarning.patch
+05_sklibs.imaging2PIL.patch
--
2.20.1
Bug#866472: Uniconvertor 2.0 upstream depends on python-pil and has some .debs
On Thu, Jun 27, 2019 at 04:07:53PM +0200, Agustin Martin wrote: > On Fri, Jun 21, 2019 at 07:24:15AM +0200, Xavi Drudis Ferran wrote: > > > > Hello. Maybe you know already (because the problem seems to be lack of > > maintainer). But there is a python-uniconvertor 2.0 that no longer depends > > on python-imaging but on python-pil (python2, I believe) > > > > https://sk1project.net/modules.php?name=Products&product=uniconvertor&op=download > > Hi, > > Even if that dependency is declared, python-uniconvertor in Debian does > not really depend on python-imaging, but on a copy of it embedded as > sk1libs.imaging in sk1libs, which is not in Debian. > > The biggest problem is the lack of sk1libs, because there are some other > functions that are required by uniconvertor as soon as you try to go > beyond the usage message (See https://bugs.debian.org/820748). By the way, some years ago I was playing with an old sk1libs version. Since I am not fluent with python I did not dare to prepare a real package for Debian, but made available what I did. It is still in https://salsa.debian.org/agmartin/python-sk1libs Some time ago it was cloned by someone from the Debian python team, https://salsa.debian.org/python-team/modules/python-sk1libs but did not see much work apart from some cosmetic commits. It no longer builds, but may be useful to someone working on it. Regards, -- Agustin
Bug#866472: Uniconvertor 2.0 upstream depends on python-pil and has some .debs
On Fri, Jul 05, 2019 at 10:50:08PM +0200, Xavi Drudis Ferran wrote: > Well, for what is worth here're the files for a package that builds > and install on buster for uniconvertor-2.0rc4. But I haven't > tested. Only did a sg to pdf conversion once. I may have done > lots of things wrong, of course. > > So far it does no seem to require sk1libs. Hi, Xavi, Thanks for your work. I was doing some work in parallel about how to build uniconvertor 2.0rc4 and learn something about packaging python stuff. I am attaching the current status of what I did. Note that I changed upstream version to 2.0~rc4 to keep proper version sorting in Debian. I only needed to use your reportlab patch. I am trying to guess if there is some license info about the color profiles. Will let you know. Regards, -- Agustin python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz Description: application/xz Format: 3.0 (quilt) Source: python-uniconvertor Binary: python-uniconvertor Architecture: any Version: 2.0~rc4-1~amd1 Maintainer: Debian QA Group Homepage: https://sk1project.net/modules.php?name=Products&product=uniconvertor Standards-Version: 4.3.0 Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.16.1.1), dh-python, python-dev, python-cairo-dev, libcairo2-dev, liblcms2-dev, libpango1.0-dev, libmagickwand-6.q16-dev Package-List: python-uniconvertor deb python optional arch=any Checksums-Sha1: 4ec122e9d066b339ab3aa4d745fb45505cf76ce8 1088298 python-uniconvertor_2.0~rc4.orig.tar.gz ede0259f13ddc37f4032770fc83682b6cacdb078 5976 python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz Checksums-Sha256: 98c32fa7255825cb5a395346f77bafa256d78a7b06093dbbb5f612e46371f045 1088298 python-uniconvertor_2.0~rc4.orig.tar.gz 50f5d7b21f472d374073bff6750f2a60c61a08aa7a35be0eb385e2634c5c804f 5976 python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz Files: 84efd5fa55ec8ebea0caaef4f3e0c5a3 1088298 python-uniconvertor_2.0~rc4.orig.tar.gz db098ede59dea3a284fc9239d3271cb6 5976 python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz
Bug#866472: copyright extract script
On Thu, Jul 11, 2019 at 04:02:13PM +0200, Xavi Drudis Ferran wrote: > > I attach the script. It prints some (c) info on the *_rc.py files. > You might need to change the uniconvertor directory in the script. > And you may not really find it too enlightening... Thanks a lot, I was already looking at the files generated under ~/.config/uc2/profiles/ where those strings can also be guessed. I will look more carefully, but at least one of the color profiles seems non free (the HP one). Regards, -- Agustin
Bug#866472: copyright extract script
On Thu, Jul 11, 2019 at 04:17:30PM +0200, Agustin Martin wrote: > On Thu, Jul 11, 2019 at 04:02:13PM +0200, Xavi Drudis Ferran wrote: > > > > I attach the script. It prints some (c) info on the *_rc.py files. > > You might need to change the uniconvertor directory in the script. > > And you may not really find it too enlightening... > > Thanks a lot, > > I was already looking at the files generated under > ~/.config/uc2/profiles/ where those strings can also be guessed. I will look > more carefully, but at least one of the color profiles seems non free (the > HP one). Hi again, Xavi I was looking at the color profiles. Here goes a summary of what I found: * cmyk_profile_rc.py -> built-in_CMYK.icm (Fogra27L.icc) Fogra27L CMYK Coated Press (C) Richard Hughes Public Domain * display_profile_rc.py -> built-in_Display.icm Contains this string: No copyright. Created with dispcalGUI 1.1.2.9 and Argyll CMS 1.4.0 -M P244W -A Acer Technologies Could get no more info about this profile * gray_profile_rc.py -> built-in_Grayscale.icm This is the same as /usr/share/color/icc/Gray.icc, shipped in icc-profiles-free package Copyright (C) 2005-2008 Kai-Uwe Behrmann License: zlib/libpng License * lab_profile_rc.py -> built-in_LAB.icm Seems similar (but not exact) to /usr/share/color/icc/LCMSXYZI.ICM, shipped in icc-profiles-free package Copyright (C) Marti Maria Saguer 1999 License: zlib/libpng License * srgb_profile_rc.py -> built-in_RGB.icm Copyright (c) 1998 Hewlett-Packard Company $ md5sum built-in_RGB.icm 1d3fda2edb4a89ab60a23c5f7c7d81dd built-in_RGB.icm If you look at https://bugs.debian.org/699301 this is exactly the same file that was reported as non-free. It is shipped as /usr/share/color/icc/sRGB.icm in non-free icc-profiles package. Some Debian packages are currently shipping free color profiles, at least icc-profiles-free colord-data libgs9-common I wonder if some profile in those packages could help. I have no idea about color profiles and such. Regards, -- Agustin
Bug#866472: Playing with a different approach for the color profiles
On Thu, Jul 11, 2019 at 06:26:49PM +0200, Xavi Drudis Ferran wrote: > > that was the intention of this code in my debian/rules (probably misplaced) > > python src/uc2/utils/rcc2py/rcc2py.py > /usr/share/color/icc/ghostscript/default_cmyk.icc > src/uc2/cms/cmyk_profile_rc.py > python src/uc2/utils/rcc2py/rcc2py.py /usr/share/color/icc/Gray.icc > src/uc2/cms/gray_profile_rc.py > python src/uc2/utils/rcc2py/rcc2py.py /usr/share/color/icc/sRGB.icc > src/uc2/cms/srgb_profile_rc.py > # python src/uc2/utils/rcc2py/rcc2py.py ? > src/uc2/cms/display_profile_rc.py > python src/uc2/utils/rcc2py/rcc2py.py > /usr/share/color/icc/ghostscript/lab.icc src/uc2/cms/lab_profile_rc.py Hi, Xavi, Missed how important were these lines, sorry. I finally had time to look again at this. I am beginning to think that keeping color profiles obfuscated and turning them available on first use is not the most convenient thing, so I played with other approach. I have been playing with using built-in_%s.icm under ~/.config/uc2/profiles if available, but global profiles otherwise. To make things simpler, I set symlinks with similar names from /usr/share/uniconvertor/profiles to some of the profiles in libgs9-common, and modified code to use them, so the *_profile_rc.py files could be removed from sources. I am not fluent with color profiles, and for simplicity I used everything from a single package, libgs9-common. Regarding display profile, people claim that it depends on monitor and graphics card, so I simply set it to the RGB profile. I am attaching a couple of files with current state of my experiments. I am also not fluent with python (that is why I did not adopt or sponsored this or any other python package), so my changes would definitely need review, if considered. A DEP5 copyright with file exclusion line is included, which should make easier to create a DFSG free tarball. Regards, -- Agustin Format: 3.0 (quilt) Source: python-uniconvertor Binary: python-uniconvertor Architecture: any Version: 2.0~rc4-1~amd1 Maintainer: Debian QA Group Homepage: https://sk1project.net/modules.php?name=Products&product=uniconvertor Standards-Version: 4.4.0 Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.16.1.1), dh-python, python-dev, python-cairo-dev, libcairo2-dev, liblcms2-dev, libpango1.0-dev, libmagickwand-6.q16-dev Package-List: python-uniconvertor deb python optional arch=any Checksums-Sha1: 4ec122e9d066b339ab3aa4d745fb45505cf76ce8 1088298 python-uniconvertor_2.0~rc4.orig.tar.gz fbb8eec9a014ebe1a7dd4009f27e7b8084a40d5b 7616 python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz Checksums-Sha256: 98c32fa7255825cb5a395346f77bafa256d78a7b06093dbbb5f612e46371f045 1088298 python-uniconvertor_2.0~rc4.orig.tar.gz a8460afa2cc4c56d10a032ef8f9699bcd8684e051f3a9df96d52dfebf907ab1b 7616 python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz Files: 84efd5fa55ec8ebea0caaef4f3e0c5a3 1088298 python-uniconvertor_2.0~rc4.orig.tar.gz 0f786da922842c0ffad7a953a685025d 7616 python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz Description: application/xz signature.asc Description: PGP signature
Re: Recent changes in dictionaries-common: dh_aspell and others
On Wed, Jun 18, 2014 at 05:49:52PM +0200, Agustin Martin wrote:
> Dear spellchecking dictionaries and wordlists maintainers,
>
> There were some recent changes in the system that may be interesting
> for your package, after initial work by Andreas Beckmann and Tobias
> Frost. Read below some reasons to consider upgrading your package to
> use some of the new features.
>
> * aspell-simple:
>
> This is new feature intended to make things easier for people
> maintaining aspell dictionaries created from pristine aspell
> sources (created with aspell "proc" utility, as are those fetched
> from aspell home page) that create nothing else than the aspell
> dictionary package.
>
> In these cases, debian/rules can be made as compact as
>
> # = 8< =
> #!/usr/bin/make -f
>
> %:
> dh $@ --with aspell-simple
>
> # this is not a GNU autoconf/automake build system
> override_dh_auto_configure:
> ./configure
> # = >8 =
>
> * substvars:
>
> Added support for ${wordlist:Depends}, ${ispell:Depends},
> ${aspell:Depends} and ${hunspell:Depends} substvars.
>
> * ispell/aspell autobuildhash symlinks:
>
> Build structure and autobuildhash scripts have been changed to allow
> those symlinks being no longer shipped with the package but created
> by the ispell or aspell autobuildhash script.
>
> A list of automatically created symlinks is put in a .remove list
> to make sure they are removed from postrm. Dangling symlinks are
> searched for and removed at the trigger run (this last may have been
> enough, but having .remove files does not harm).
>
> This way we no longer need to ship any dangling symlink with the
> dictionary package or wordlist.
Forgot to explicitly mention that this implies that packages relying on
this no longer available feature will no longer get it for new builds.
For this reason, *if and only if a new build is needed* they must have
their dictionaries-common dependency bumped to at least 1.23. substvars
use is highly recommended.
Don't panic, I went through the list of currently available dictionary
packages in sid, and all will work as they are now, no need to rebuild
just because of this notice.
This does not affect the binary:arch ispell or aspell dictionaries, unless
they are changed to use {a,i}spell-autobuidhash. Also, does not affect
packages that set the symlinks explicitly during their build process.
I am explicitly bcc'ing all packages that do not have an already updated
dependency, so maintainers are aware in case they need to upload a new
package using autobuildhash. Sorry if this message gets duplicated for
some of you.
> Most recent bug fixes and changes in the system came with
> dictionaries-common-dev 1.23.3, see changelog for the details. Consider
> build-depending on at least that version.
Regards,
--
Agustin
--
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141121172647.ga11...@agmartin.aq.upm.es
Please consider waiting for aspell fixing #772415 before uploading new aspell dictionaries
Hi, I am writing to warn aspell dict maintainers (aspell dict packages bcc'ed, sorry for the dups) about a problem we noticed in current jessie aspell. This problem is not RC, so a fixed aspell will not go into jessie, but will be uploaded after the release. In summary, if your aspell dictionary builds and installs directly from official aspell dict sources (directly or indirectly via debhelper dh_aspell sequence), please wait for aspell fixing #772415 before uploading new versions of the package. In this case, current aspell will lead to xx.dat file be installed under /usr/share/aspell instead of /usr/lib/aspell, and this will stop working in the future. Last time I checked I found no aspell dictionaries with xx.dat in /usr/share/aspell, but doublechecking is very much apreciated. If your aspell dictionary explicitly builds and installs all dict related stuff in /usr/lib/aspell, just keep doing things that way and to stay in the safe side please check that this happens after new builds. The long explanation follows, for those interested. One of the things that were added to aspell for semi-multiarch support was the possibility of real decouple of aspell's data-dir and dict-dir variables. Default data-dir was set to /usr/share/aspell and dict-dir to /usr/lib/ispell. Dictionaries already included all stuff under dict-dir (including xx.dat) and this worked with aspell-autobuildhash and is still the expected setup. At that time I did not notice that aspell dictionaries building directly from aspell sources will install all dat files (including xx.dat) under /usr/share/aspell. This will work with this change, but is not consistent with previous setup where all dict stuff is put at /usr/lib/ispell and will fail if change below is implemented. When #772415 (aspell expects en.dat in /usr/share/aspell but it is in /usr/lib/aspell) was reported I noticed that it was a matter of luck that aspell-autobuildhash was working well with that setup, it included a workaround for an ancient problem with aspell that helped the hash build process to find xx.dat under /usr/lib/aspell. But this will not work in the standard way of building hashes outside of aspell-autobuildhash, unless --local-data-dir is explicitly used (which should not be needed). We have been discussing in http://bugs.debian.org/772415 how to best deal with this, and tend to think that making data-dir and dict-dir point to the same /usr/lib/aspell dir is the best approach (while lib-dir still points to the multiarch dirs). We still need to do some extra tests here. Thanks a lot for your patience, Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150213121849.ga5...@agmartin.aq.upm.es
Re: Please consider waiting for aspell fixing #772415 before uploading new aspell dictionaries
On Fri, Feb 13, 2015 at 01:18:49PM +0100, Agustin Martin wrote: > Hi, > > I am writing to warn aspell dict maintainers (aspell dict packages bcc'ed, > sorry for the dups) about a problem we noticed in current jessie aspell. > This problem is not RC, so a fixed aspell will not go into jessie, but > will be uploaded after the release. > > In summary, if your aspell dictionary builds and installs directly from > official aspell dict sources (directly or indirectly via debhelper > dh_aspell sequence), please wait for aspell fixing #772415 before uploading > new versions of the package. Hi all, dict-common-dev subscribers and bcc'ed aspell dicts maintainers, aspell 0.60.7~20110707-3 with above fixes has already been uploaded to sid. Since it has been there for more than 40 days with no further problems I assume the problem is fixed and aspell dicts can be built against it without problems. Feel free to do that, jessie has been released. Thanks a lot for your patience, Best regards, -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150427174001.ga19...@agmartin.aq.upm.es
Bug#799855: myspell-sl: Typo in dependencies of myspell-sl transitional package: hunspell-th -> hunspell-sl
Subject: myspell-sl: Typo in dependencies of myspell-sl transitional package:
hunspell-th -> hunspell-sl
Package: myspell-sl
Version: 1:5.0.1+dfsg-3
Severity: normal
Tags: + patch
Hi, Mattia,
A typo slipped into dependencies of myspell-sl transitional package, pulling
hunspell-th instead of hunspell-sl, see attached patch.
Regards,
--
Agustin
diff --git a/debian/control.in b/debian/control.in
index a9add2c..40f8394 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -86,7 +86,7 @@ Package: myspell-sl
Priority: extra
Section: oldlibs
Architecture: all
-Depends: hunspell-th, ${misc:Depends}
+Depends: hunspell-sl, ${misc:Depends}
Description: Slovenian dictionary for hunspell - dummy transitional package
This is the Slovenian dictionary for use with the hunspell
spellchecker.
Bug#799855: myspell-sl: Typo in dependencies of myspell-sl transitional package: hunspell-th -> hunspell-sl
On Wed, Sep 23, 2015 at 12:04:53PM +0200, Agustin Martin wrote:
> Subject: myspell-sl: Typo in dependencies of myspell-sl transitional package:
> hunspell-th -> hunspell-sl
> Package: myspell-sl
> Version: 1:5.0.1+dfsg-3
> Severity: normal
> Tags: + patch
> Hi, Mattia,
>
> A typo slipped into dependencies of myspell-sl transitional package, pulling
> hunspell-th instead of hunspell-sl, see attached patch.
Hi,
Message from the BTS claimed to have sent bug acknowledgement to QA
Your message has been sent to the package maintainer(s):
Debian QA Group
owner of old myspell-sl. Re-sending the message, in case it did not reach
the libreoffice group. Bug is properly opened in libreoffice-dictionaries
page and patch is there, but I attach it again for the list benefit.
Regards,
--
Agustin
diff --git a/debian/control.in b/debian/control.in
index a9add2c..40f8394 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -86,7 +86,7 @@ Package: myspell-sl
Priority: extra
Section: oldlibs
Architecture: all
-Depends: hunspell-th, ${misc:Depends}
+Depends: hunspell-sl, ${misc:Depends}
Description: Slovenian dictionary for hunspell - dummy transitional package
This is the Slovenian dictionary for use with the hunspell
spellchecker.
Bug#799855: myspell-sl: Typo in dependencies of myspell-sl transitional package: hunspell-th -> hunspell-sl
On Wed, Sep 23, 2015 at 01:42:03PM +, Mattia Rizzolo wrote: > > Message from the BTS claimed to have sent bug acknowledgement to QA > > > > Your message has been sent to the package maintainer(s): > > Debian QA Group > > > > owner of old myspell-sl. Re-sending the message, in case it did not reach > > the libreoffice group. Bug is properly opened in libreoffice-dictionaries > > page and patch is there, but I attach it again for the list benefit. > > umh, oh. > also the page header on the bug is confused. > Package: myspell-sl; Maintainer for myspell-sl is Debian QA Group > ; Source for myspell-sl is > src:libreoffice-dictionaries. > > Anyway, it did reach me since I'm subscribed through the package > tracker. Fine, thanks BTW, filed #799870 against bugs.debian.org about this inconsistency. -- Agustin
