Bug#1009196: [Dev-luatex] Bug#1009196: texlive-binaries: Reproducible content of .fmt files
On 4/11/2022 4:34 PM, Roland Clobus wrote: The texlive-binaries in Debian contain an embedded copy of Lua 5.3. The Lua 5.4 version of luai_makeseed is more complex, see [2]. I'll write a feature request for Lua later, that is out-of-scope for this scenario. fyi: it is unlikely that luatex will move to 5.4 because it might break exisiting code and/or introduce incompatibilties (so we assume 5.3 for now) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -
Bug#1009196: [Dev-luatex] Bug#1009196: texlive-binaries: Reproducible content of .fmt files
On 4/11/2022 6:56 AM, Norbert Preining wrote: Hi Luigi, hi all luatex devs, here at Debian we got a bug report about reproducability of luatex format dumps. It contains a patch to make the hyphenation exception list sorted. (I attach the patch) Could you please take a look whether this is still relevant for the latest release of luatex. it actually defeats one of the security properties of lua (which was explicitly introduced at some point: make sure that hashes have random order each run so that it's harder to retrieve sensitive data from mem) that said, it means that as soon as something gets stored in the format otherwise (than exceptions) one can face the same issue (although one can work around that by sorting etc) if you want reproducibility for some testing, mess with this instead: #if !defined(luai_makeseed) #include #define luai_makeseed() cast(unsigned int, time(NULL)) #endif anyway, formats with embedded lua data (serialized or bytecode is never guaranteed the same unless one does soem effort) fwiw: the easiest solution is to not store patterns and exceptions in the format and just load them runtime which is just as fast (in retrospect not a good idea to store it but it was needed for some plain compatibility testing) Hans (who in the past has been bitten by this 'random feature' when we made the switch to 5.3, or maybe it was even 5.2; it used to be 'random per binary' and became 'random per run' but we decided to stick with official lua) - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -
Bug#525315: connect/disconnect loops with ifupdown and wpa_supplicant in roaming mode
Package: ifupdown
Version: 0.8.35+b1
Followup-For: Bug #525315
Hey,
I'm pretty sure this should be filed as a bug to wpasupplicant.
In my case (same phenomena on display as OP reported), increasing the
hysteresis timeout to 10 seconds was enough to stop the cycling reliably.
For the record that would be 10 seconds (instead of 4) in
wpa_hysteresis_check() in /etc/wpa_supplicant/functions.sh (a
pro-forma patch is attached).
The actual question here is: how do I debug this cycle properly?
--- a/wpa_supplicant/functions.sh
+++ b/wpa_supplicant/functions.sh
@@ -847,9 +847,10 @@ wpa_hysteresis_check () {
local TIME
local TIMESTAMP
local TIMEWAIT
+ local TIMEDELTA=10
TIME=$(date +%s)
- # current time minus 4 second event buffer
- TIMEWAIT=$(($TIME-4))
+ # current time minus TIMEDELTA second event buffer
+ TIMEWAIT=$((TIME-TIMEDELTA))
# get time of last event
TIMESTAMP=$(cat $WPA_CLI_TIMESTAMP)
# compare values, allowing new action to be processed
Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions
* Matthias Klose | 2020-02-03 22:29:21 [+0100]: [CCing Alan Modra, H.J. Lu, Nick Clifton & Arnaldo] Ok, I tried to check what happens: - Alan Modra modified the bfd_section_* macros (see commit fd3619828e94a) upstream (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=summary) Or in other words: this patch removed/renamed the macros silently. This was back in September last Year. No __attribute__ deprecation warning or other information was given a priori to react. - This went mainline and was now taken by Debian Bullseye the last couple of days. RedHat and other distributions will probably run in the same problems, once they upgrade binutils. - Linux perf and other applications build on these functionality are now doomed. >binutils doesn't have any comitment to a stable ABI/API for libopcodes and >libbfd. Sure? They exposed bfd_get_section_flags and friends in bfd.h - it was not hidden somewhere in private header files nor was it guarded by any other measure. Correct me if I am wrong! And: the functions/macros where used in the wild! They where helpful and serviceable to the broader audience - which is (sorry: "was" :-) great! The following patch fixed the problem for me to build Linux perf again: --- /usr/include/bfd.h 2020-02-04 15:24:36.746534674 + +++ /usr/include/bfd.new.h 2020-02-04 15:24:39.486542126 + @@ -1243,6 +1243,11 @@ return (sec->flags & SEC_IS_COMMON) != 0; } +#define bfd_get_section_flags(bfd, ptr) ((void) bfd, (ptr)->flags) +#define bfd_get_section_userdata(bfd, ptr) ((void) bfd, (ptr)->userdata) +#define bfd_get_section_vma(bfd, ptr) ((void) bfd, (ptr)->vma) +#define bfd_get_section_size(ptr) ((ptr)->size) + Note: for binutils ./bfd/bfd-in.h should be adjusted - sure. Hagen Paul Pfeifer >> It seems other people (kernel folks, Stephen) have the identical error as >> well: https://lkml.org/lkml/2020/1/30/1005 >> Stephen: or is the bug fixed somewhere else? Do you have an workaround?a > >I don't have a work-around. If you rely on binutils internals, you really >should >adjust to binutils upstream.
Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions
CCed: Stephen Rothwell * Matthias Klose | 2020-02-03 21:10:14 [+0100]: Hey Matthias >please can you reassign that to the appropriate package? both libopcodes and >libbfd have non-public interfaces. If you use those, please adopt to these. I don't get it: `apt-file search /usr/include/bfd.h` results in binutils-dev: /usr/include/bfd.h On an slightly older bullseye the shipped version of bfd.h building perf works like a charm. I don't get it why the currently shipped version of bfd.h by binutils-dev/bullseye should be fine? bfd.h looks broken now because they break API compatibility by silently removing previously defined public functions. libbfd-dev is an meta-package and provided by binutils-dev. I don't get the correlation to the bug. It seems other people (kernel folks, Stephen) have the identical error as well: https://lkml.org/lkml/2020/1/30/1005 Stephen: or is the bug fixed somewhere else? Do you have an workaround?a Thank you Matthias for the quick response! Hagen
Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions
Package: binutils-dev Version: 2.33.90.20200122-2 Severity: important Dear Maintainer, linux perf build fails with current version of binutils-dev: Steps to produce: $ cd /path/to/linux/tools/perf $ make Everything worked with the previous(?) version of binutils-dev: 2.33.1-6. Relevant output: CC util/srccode.o util/srcline.c: In function ‘find_address_in_section’: util/srcline.c:200:7: error: implicit declaration of function ‘bfd_get_section_flags’; did you mean ‘bfd_set_section_flags’? [-Werror=implicit-function-declaration] 200 | if ((bfd_get_section_flags(abfd, section) & SEC_ALLOC) == 0) | ^ | bfd_set_section_flags util/srcline.c:200:7: error: nested extern declaration of ‘bfd_get_section_flags’ [-Werror=nested-externs] util/srcline.c:204:8: error: implicit declaration of function ‘bfd_get_section_vma’; did you mean ‘bfd_set_section_vma’? [-Werror=implicit-function-declaration] 204 | vma = bfd_get_section_vma(abfd, section); |^~~ |bfd_set_section_vma util/srcline.c:204:8: error: nested extern declaration of ‘bfd_get_section_vma’ [-Werror=nested-externs] util/srcline.c:205:9: error: implicit declaration of function ‘bfd_get_section_size’; did you mean ‘bfd_set_section_size’? [-Werror=implicit-function-declaration] 205 | size = bfd_get_section_size(section); | ^~~~ | bfd_set_section_size util/srcline.c:205:9: error: nested extern declaration of ‘bfd_get_section_size’ [-Werror=nested-externs] And as expected: bfd_get_section_flags() is now missing in /usr/include/bfd.h which leads to this error. Hagen -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.utf8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to de_DE.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages binutils-dev depends on: ii binutils 2.33.90.20200122-2 ii libbinutils2.33.90.20200122-2 ii libctf-nobfd0 2.33.90.20200122-2 ii libctf02.33.90.20200122-2 binutils-dev recommends no packages. binutils-dev suggests no packages. -- no debconf information
Bug#875788: (no subject)
Package: installation-reports Boot method: Date: Machine: AMD Ryzen 5 1400, 8gb DDR4, 5x 1TB, GeForce GTX 770 2GB, 1250w net aggregat. Processor: AMD Ryzen 5 1400 Memory: 8gb DDR Partitions: Output of lspci -knn (or lspci -nn): Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card: [E] Configure network: [E] Detect CD: [E] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system: [O] Clock/timezone setup: [O] User/password setup: [O] Install tasks: [O] Install boot loader: [O] Overall install: [E] Comments/Problems: I cannot install additional packages from those three blu-ray discs and the physical button to eject any of disc does not work but only in boot, I have disabled the network at the mainboard because I don't using that after an finished absolute agreement with doctor and psychology, I cannot compiling source-code but only install them, I have problem to read any SD-card in locked mode, there are two login at Ctrl+F1 and Ctrl F2; while I logged in the Ctrl+F2 are in use while Ctrl+F1 showing login screen, thus I only having four left for console text mode but not five as I usually am using and for a few years ago the GUI was at Ctrl+F7 but moved to Ctrl+F1, and I have problem to using the command adduser, addgroup, and problem to leave folders in home folder read and Write Access after I have copied at least one file from external medium. Now that's was all problems I have discovered until yet. Hilsen Øyvind Hagen.
Bug#851464: prosody: Please suggest/recommend python-bcrypt (provides bcrypt auth backend)
Package: prosody Version: 0.9.11-1 Severity: wishlist Dear Maintainer, bcrypt is one of the hash algorithms looked upon more favourably. Prosody supports it, yet the package makes no mention of it. Could we recommend/suggest it? Also: kudos for your on-the-button packaging! Yours, Hagen
Bug#851183: fenics: Misses important 'mshr' module
Dear Johannes, > No, not really - none of the demo programs in DOLFIN uses mshr. Got me there. The project I'm contributing to (micromagnetics software) switched to it and the only two examples I've found of any interest were using it. I /might/ have extrapolated a bit. ;) > mshr is already packaged for Debian[...] Again: thanks for your work! > mshr needs a patched version of CGAL. Ouf. Anything I can do or is it simply a matter of just waiting for the maintainers? -Hagen
Bug#851183: fenics: Misses important 'mshr' module
Package: fenics Version: 2016.2.0.1 Severity: important Hello, Fenics/Dolfin contains the core module 'mshr' which deals in meshes. All current examples seem to be employing 'mshr', eg. https://fenicsproject.org/qa/9414/fenics-mesh-generation-mark-inner-region The Fenics project page mentions that simply installing Fenics should bring 'mshr' along, so maybe/hopefully this is a simple matter to resolve. (Knowing Fenics, it most probably isn't.) Many thanks for packaging the newest Fenics versions in any case! If I can help in any capacity, shoot. Regards, Hagen
Bug#793740: kwrite: spell checking does not work at all
Hey, Alright, running kwrite with:: LANGUAGE=en LANG=en kwrite works (with spotty highlighting for auto-check, but yeah). My locale says:: LANG=en_GB.utf8 LANGUAGE=en_GB:en however. I installed everything (on a clean slate Debian testing machine) by saying:: aptitude install kwrite sonnet-plugins aspell-en hunspell-en-gb \ kde-cli-tools libqt5xcbqpa5 Note, I'm not running a KDE environment, hence the 'libqt5xcbqpa5' package. I'm simply using kwrite in XFCE (not even that's entirely true, as I'm reporting this bug for somebody else :). The kde-cli-tools report failure, too:: $ kcmshell5 spellchecking Could not find module 'spellchecking'. See kcmshell5 --list for the full list of modules. Nevertheless, I did a complete purge and reinstall cycle, even went so far as to install 'plasma-framework' (I have no stomach to try task-kde-desktop). However, none of the above changed. Hypothesis: hunspell is never asked. Supporting: Removing aspell-en yields the same behaviour as before, this time with No language dictionaries for the language: "en" in the terminal. Also: > [copious strace output] > > As you can see, it finds (and then loads) all the plugins. Yes. Yes, it does. My point was, however, that a '/usr//usr/' path anywhere can't be healthy. But it can possibly safely be ignored, I wouldn't know. Thanks!
Bug#793740: kwrite: spell checking does not work at all
Hi,
> Do you have sonnet-plugins installed?
Yes. I also tried to provide different backends (aspell, hunspell,
myspell) exclusively and all together. No dice.
Note again, that after starting kwrite with eg.
strace -s 512 kwrite |& grep 'sonnet'
I'm still seeing the line
stat("/usr//usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/sonnet", 0x7fff8cff2920)
= -1 ENOENT (No such file or directory)
immediately after selecting 'Tools > Spelling > Spelling ...'.
Thanks for looking into it!
-Hagen
Bug#793740: kwrite: spell checking does not work at all
Package: kwrite
Followup-For: Bug #793740
Hi,
Discovering that the bug is happily alive, I tinkered a bit with with
strace. One of the lines that appears after activating the
spell-checker reads::
stat("/usr//usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/sonnet", 0x7ffe5537a0b0)
= -1 ENOENT (No such file or directory)
Note the '/usr//usr/' part. I haven't looked at the source. /2¢
-Hagen
Bug#767864: units should recommend python-unidecode
Hi, Both these fixes will be in the first upload after Jessie releases. Grand, thanks! -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767864: units should recommend python-unidecode
Package: units Version: 2.11-1 Followup-For: Bug #767864 Hello, Thanks for maintaining units! Love it. I have two suggestions, 1) Simply a refinement of Mike's proposal: Depend on or suggest python-unidecode instead of python:all, it's compatible with Python 2 and 3, so this does the trick just as well. 2) Change units_cur a bit to avoid warnings from unidecode when trying to decode simple ASCII strings. With that, I can run units_cur every week or so as a cronjob without reading unidecode's RuntimeWarning over and over again. Here's the patch (unified diff): --- /usr/bin/units_cur 2014-04-09 07:35:56.0 +0200 +++ units_cur 2015-03-24 11:56:15.584269473 +0100 @@ -50,8 +50,8 @@ for i in xrange(len(names)): if names[i] == 'anguilla(ecd)': names[i] = 'eastcaribbeandollar' - ascii = unidecode(names[i]) - if names[i] != ascii: + if type(names[i]) != str: +ascii = unidecode(names[i]) if not foundunicode: foundunicode = True outstr += '# Unicode Currency Names\n\n!utf8\n' -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#377548: usbmount: Fails mounting some parts in a n-in-1 device
Hello, https://github.com/hfuchs/usbmount/tree/hfuchs.377548 This version has a bug, though: [...] The problem is that $mountpoint is now set within a subshell[.] Fixed. Using command groups now instead of that blasted subshell. Updated on Github. (Shell scripting is never fun.) Do not deride my evening's entertainment! ;) Thanks, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676554: usbmount: no write permission on hotplugged usb devices: PLEASE CLOSE
Package: usbmount Followup-For: Bug #676554 Hi, Please close the bug report. There's nothing to do here. The problem seems specific to the original poster's configuration (and might, of course, be caused by what Edward described!). Don't keep idle bug reports around, please close. Thanks! -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759530: libc-bin: ldconfig breaks a system
Package: libc-bin
Version: 2.19-11
Followup-For: Bug #759530
Hello!
Something similar happened to me (after upgrade to 2.19-11). If this
report wasn't on top of libc-bin and absolutely recent, I would not have
said a word: read on!
Foundation-laying: the scenario. All packages that call ldconfig in their
install scripts started sputtering like this one:
Setting up golang (2:1.3.2-1) ...
Processing triggers for libc-bin (2.19-11) ...
Segmentation fault
/sbin/ldconfig.real: Path `/lib/x86_64-linux-gnu' given more than once
/sbin/ldconfig.real: Path `/usr/lib/x86_64-linux-gnu' given more than once
/usr/lib/x86_64-linux-gnu/libfakeroot:
libfakeroot-0.so - libfakeroot-tcp.so
/usr/local/lib:
/lib/x86_64-linux-gnu:
libthread_db.so.1 - libthread_db-1.0.so
[...]
libglib-2.0.so.0 - libglib-2.0.so.0.4200.0
/usr/lib/x86_64-linux-gnu:
Segmentation fault
dpkg: error processing package libc-bin (--configure):
subprocess installed post-installation script returned error exit status 139
Errors were encountered while processing:
libc-bin
Hu? ldconfig dies like this (strace):
[natural-looking output]
stat(/usr/lib/x86_64-linux-gnu/libQtScript.so.4, {st_mode=S_IFREG|0644,
st_size=2692504, ...}) = 0
stat(/usr/lib/x86_64-linux-gnu/libjasper.so.1, unfinished ...
+++ killed by SIGSEGV +++
Segmentation fault
Oh?
# file /usr/lib/x86_64-linux-gnu/libjasper.so.1
Segmentation fault
Drastic measures (wtf?):
# ls !$
ls /usr/lib/x86_64-linux-gnu/libjasper.so.1
Segmentation fault
# rm /usr/lib/x86_64-linux-gnu/libjasper.so.1
Segmentation fault
# unlink !$
unlink /usr/lib/x86_64-linux-gnu/libjasper.so.1
# ls /usr/lib/x86_64-linux-gnu/libjasper.so.1
ls: cannot access /usr/lib/x86_64-linux-gnu/libjasper.so.1: No such file or
directory
Done (reinstall libjasper1).
Now, ordinarily, I'd say: severe FS corruption, something or other.
But, with this report on top, perhaps there's something deeper going on.
No idea.
Note: I now have no way of returning to the broken state.
I doubt anyone can profit from this, but I had to throw it in (as I
already mentioned).
Such is my tale of woe.
Regards,
Hagen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#377548: usbmount: Fails mounting some parts in a n-in-1 device
Package: usbmount Followup-For: Bug #377548 Hi! Frédéric's reply to this bugreport warmed my heart and I was inspired to do what I promised Rogério a couple of years ago: solve all of usbmount's problems. ;) While Frédéric's approach is outstandingly creative, I think we can address #377548 and #403209 simply by switching to another locking approach. I replaced all calls to utilities from 'lockfile-progs' by one to flock(1), thereby gaining: 1) Even less dependencies (and LOC); flock comes from the essential package 'util-linux'. 2) A snappy locking implementation that doesn't wait in increments of 5, 10, 15, ... seconds like lockfile-* does. (WTF!) I tested with a pen drive that has 20 partitions, different file systems and I consistently mount all of 'em under 4 seconds. I have a bugfix-branch of upstream, https://github.com/hfuchs/usbmount/tree/hfuchs.377548 which contains only the necessary changes (almost: I also handle the /var/run - /run transition because it's the same code region). (Don't forget: There's another one for #658028!) -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#377548: usbmount: Fails mounting some parts in a n-in-1 device
Hi there! [flock(1)] I feel silly for not having been aware of that simple command. :) Well, its handling is a bit weird (take a look at the 'third form' description in the man page), but it does the job amiably. Also: I spent a ludicrous amount of time trying to make usbmount lockless. -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676554: usbmount: no write permission on hotplugged usb devices (CLOSE)
Package: usbmount Followup-For: Bug #676554 Hi, As nobody yelled during the last month, I strongly suggest we close this bug report. If in future anything similar occurs, there's nothing stopping anybody from filing a new bug or requesting to reopen this one. Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666059: clusterssh: cssh does not deal well with compound commands
Package: clusterssh Followup-For: Bug #666059 Hello, Please close this report - clusterssh does not exhibit the bug any more. I wrote the following over two years ago, but for some reason it never reached the server (probably missing pseudo-header): Upstream fixed the problem in question (employing the exact same method I proposed :). See https://github.com/duncs/clusterssh/commit/cb3aa92febd16c8af901066dffd9f428c8ef255a Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658028: usbmount: Udev should not wait for mounting
Package: usbmount Followup-For: Bug #658028 This is indeed a very valid concern (not that I have been affected personally). Quite a few scripts in /lib/udev/rules.d seem to be doing things that might take a while or even hang. I'm surprised, honestly. In any case, I imagine usbmount's udev compliance could be trivially ensured: make 'usbmount' a wrapper that calls, say, usbmount.real proper with all the banalities, insecurities, hopes and despair that comes with it. I created a branch of the alioth upstream sources that implements precisely this change, https://github.com/hfuchs/usbmount/tree/hfuchs.658028 and also renames usbmount.rules - 90-usbmount.rules because it seemed proper (all of the other rule scripts start with some ordering number, only usbmount stood out :). How about it? -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676554: usbmount: no write permission on hotplugged usb devices
Package: usbmount Followup-For: Bug #676554 Hello, All my hotplugged usb devices are owned by root and only writable by the superuser. This can't possibly be the way this is supposed to work. It's not. Rather, I'd suggest that somewhere along the line something got misconfigured. Do reply if you're still affected by/interested in this, josh! Otherwise I suggest we close this report in, say 30 days. I'll be back, eh? Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/18/2014 1:35 PM, Fabian Greffrath wrote: Am Donnerstag, den 17.07.2014, 20:57 -0400 schrieb James Cloos: A patch has at least been proposed for poppler to treat glyph names like /f_i as equivilent to names like /fi, at least for the f-ligs found in the standard pdf font encodings for the base14 fonts. I am still convinced (and as far as I understand it seems that at least Karl Berry agrees in that regard) that the most portable solution would be to include duplicates of the two fl/f_l and fi/f_i glyphs that are part of the MacRoman character set in the fonts - in addition to and independent of the fixes in poppler. of course that will then fail again when someone drops in another times replacement that doesn't have the /ff if dropping in otf files for type 1 ones is considered a valid solution, then poppler should do more checking anyway for the few f related ligatures (which makes me wonder why the otf file is used as drop-in) (apart from potential issues in one-to-one slot-to-name mapping resolvers in other programs that now can get confused when ff overloads f_f) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/7/2014 10:08 AM, Fabian Greffrath wrote: Isn't Times one of the fonts that are by definition of the PDF standard explicitely not required to get embedded? Those 7+bit times of a default minimal set of 15 fonts (these were embedded in printers which at some point made sense due to bandwidth et etc) are behind us. Of course most printers will still have these fonts because they are part of old standards. Not embedding a font has no benefits and for archival pdf (a/x) fonts have to be embedded. (Nowadays a mediocre picture taken by some gadget takes more space than a font in a document.) In fact, if I get a pdf file with no fonts embedded and it doesn't show up ok, I'd not even bother figuring out why and simple discard the pdf. Now, adding ff as well as f_f to a font mapping to the same glyph might work ok for applications that look for ff but it might as well confuse applications that like to see f_f (think of a one-to-one mapping: which one wins ff - some slot or f_f - slot ?). So, i guess some testing is needed as fixing one and breaking another set of applications doesn't help. So, all applications that want to support the old stuff and new stuff need to support (ff, f_f) = slot mapping. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/2/2014 4:32 PM, Boguslaw Jackowski wrote: Hans: I think even the type1 texgyre isn't by definition metric compatible. Metric compatibility was one of the major targets of the TeX Gyre project. Sure, definitely for the type1s, but also that for opentype we would not be strict (one never knows what follow up we will have). Visually there are of course differences (accent placement etc) so one can expect visual differences when doing trickery that depends on exact visual properties (like putting multiple accents on top of things) in which case probably even the type1 drop in could be a problem. (I'm talking tex now where open type fonts don't have the type1/tfm relates limitations in w/h/d). In practice a document that doesn't embed and expects e.g. times is not typeset that clever so problems are unlikely to show up. (Users who don't embed shouldn't complain about quality of rendering anyway.) Hans ps. A way bigger nightmare can be lucida as there are many incompatible variants of that one and then there are also cross platform viewing issues. But I assume these are normally embedded, but even then bad things can happen, e.g. with included images in documents that have no embedded fonts too. But afaik we left that time behind us. - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/1/2014 1:40 PM, Fabian Greffrath wrote: Am Dienstag, den 01.07.2014, 08:08 +0900 schrieb Norbert Preining: or adding another fake glyph fi/f_i, Yes, please. This sounds like the best compromise: It retains backward and forward compatibility, should be trivial to implement and should be safe for future changes that poppler (or any other rendering framework) introduce. I have no clue what this will solve. Say that the original input stream has this: effe = e f i e and the feature processor turns that into glyph representing e glyph representing fi glyph representing e which in the pdf stream can become 121 with 1 pointing glyph representing e and 2 representing fi. The pdf file has then this mapping with fi being named f_i and not fi (why should it) and also carries a tounicode which maps the 1 to unicode e and 2 to unicodes f followed by i. The reference to ff never ends up in the subsetted file. Just fix poppler, because it it has this problem with f_i it definitely has more such problems. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/1/2014 6:12 PM, Ralf Stubner wrote: On Tue, Jul 1, 2014 at 2:13 PM, Hans Hagen pra...@wxs.nl wrote: The pdf file has then this mapping with fi being named f_i and not fi (why should it) and also carries a tounicode which maps the 1 to unicode e and 2 to unicodes f followed by i. The reference to ff never ends up in the subsetted file. I suspect that the pdf was created using glyph names and metrics for Times, where fi and not f_i is used, but the font was not embedded. On viewing the pdf, the font used instead of Times was the OpenType version of TeX Gyre Termes, which has no glyph named fi. In this case it should help to supply copies of the ligature glyphs using old style names (fi and fl only). Isn't it better then to install the standard ps set on the operating system and make sure these are not remapped? The texgyre opentype fonts are not supposed to be drop ins for those standard (15 or so) ps fonts. I think even the type1 texgyre isn't by definition metric compatible. It might be interesting to see how other viewers/operating systems behave (e.g. do mupdf based viewers have the same side effect?) I think that for that embedding the times and so is kind of mandate nowadays. Those big cjk fonts are often extern but these have well defined vectors. Personally I'd not spend a second on a user complaint that concerns a not-embedded font. (Btw, a bigger issue is actually that only a few viewers do 'copy' well i.e. deal with tounicode vectors.) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 6/30/2014 1:15 PM, Boguslaw Jackowski wrote: Norbert: here at Debian recently a problem surfaced with respect to the OpenType TeX Gyre fonts. The problem is that the ligatures are named f_i etc while display engines like poppler, as well as the orginal PostScript fonts, use fi etc. In Debian and Ubuntu, currently the TeX Gyre fonts provide the *standard* postscript fonts, due to be considered generally better. But that means, that at the current moment of one uses the TeX Gyre fonts as a replacement for the PS fonts, the ligatures will not be rendered at all. [...] Related bug reports are: * Debian BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742767 * FreeDesktop: https://bugs.freedesktop.org/show_bug.cgi?id=73291 Dear Colleagues, we are more than happy that the TeX Gyre collection of fonts has been have been chosen as a default font set in Debian distribution. And we are sorry that we haven't predicted the problem of the discrepancy between the new and old ligatures name. Our idea was to provide partially new fonts. More precisely, we have assumed that the fonts in the Type 1 format should be as compatible as possible with the Adobe original fonts. In particular, we tried to preserve (with some exceptions, due to obvious Adobe's bugs) the original font metric and, moreover, we used the old-style names for ligatures. The fonts in the OTF format, however, we considered new ones (note, e.g., that they have Unicode tables and that they are equipped with the OTF typografic features, both absent from the original Adobe fonts) and, therefore, following Adobe's recommendations for the glyph naming in new fonts (see the mentioned by Karl documentation http://sourceforge.net/adobe/aglfn/wiki/AGL%20Specification and also Adam Twardoch's John Hudson's comments -- http://typophile.com/node/18452 and http://typophile.com/node/0 , respectively), we assigned the new-style ligature names. Indeed, so it's f_i etc and using fi for that and foo_bar_whatever for other ligatures makes no sense ... tounicode logic depends on conventions like the _ as ligature separator. In the TeX Gyre Math fonts we also have used the new-style ligature names. Two questions: 1. What about using Type 1 fonts for compatibility purposes? It seems to us taht it could be the simplest patch, provided the font rendering engines are able to handle conveniently obsolete Type 1 fonts. 2. Does it make really sense to make a step backward and revert to the old-style names in the OTF TeX Gyre fonts (including TeX Gyre Math)? It is feasible, but we are rather reluctant to introduce such a change, as it is likely to cause fuss among TeX Gyre users. It makes no sense ... if poppler does something with glyphnames (and i'm not sure why it would) it should deal with it properly and recognize u, uni, index, numbers, _, . ... as classifiers and separators. Dealing with inconsistencies in unicode and fonts is already a pain and adding more confusion makes no sense. btw, If I grep my afm files for f_f and f_l I get lots of hits on linotype fonts like palatino-nova, aldus-nova, palatinosans* so there are type one fonts out there that use _ too. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/1/2014 1:05 AM, Norbert Preining wrote: On Mon, 30 Jun 2014, Hans Hagen wrote: btw, If I grep my afm files for f_f and f_l I get lots of hits on linotype fonts like palatino-nova, aldus-nova, palatinosans* so there are type one fonts out there that use _ too. Interestingly I cannot trigger the bug with xelatex and Palatino Sans, for example. If I understand right, the bug has to do with viewing (rendering) a glyph in a pdf file. In pdf the page stream has numbers pointing to a (normally) subset index which in turn maps onto the font slots (can be any order). Normally no glyph name is involved in that. Those names might kick in when copying is involved and no tounicode mapping is present in the pdf. As you mention in a previous mail, it's a bug in poppler (or maybe some library it uses) that somehow used glyph names. I agree that there is no need to change the font (and I cannot predict what other issues might show up by duplicating glyph names; for instance turning f + i into an fi glyph .. it would still map onto the one associated with f_i). Using the unicode ligature sis a bad idea anyway as all these ligs in unicode make not much sense and is just there to suit bad old times. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750785: Slowness with context and xetex
On 6/8/2014 9:26 AM, Norbert Preining wrote:
Hi Hans, hi Taco,
(please keep the Debian bug report in Cc)
We got a report here at Debian that context when run over xetex
is extremely slow, which I can confirm.
It is interesting that when I drop the original TeX Live (not Debian)
xetex into our /usr/bin, then it is getting fast again.
On the other hand, I don't see any slow down when running
xelatex on a similar document. The test document is a simple
\starttext
lots of lorem ipsum in paragraphs
\stoptext
If I change this to a simple latex document {article} it is also
very fast.
So that points at something that context is telling xetex to do/load
that exhibits a bug, but I have *NO* idea where the bug might
come from.
Can you see if (in the background) the xetex font database gets
regenerated? I remember that long ago on windows we had a problem with
xetex, where it could not determine that it had already generated the
database. This can happen when a font is asked for 'by name' which isn't
on the system so that some kind of 'not found, let's regenerate the
database' action happens (which is out of context control).
The difference between TL original and Debian is that we use
shared libraries. For pure text processing the fault should be
in harfbuzz, right? We are having 0.9.28.
Do you have any other ideas how to track such a bug? Do you have
any guess what could it be that context tells xetex?
Thanks a lot
Norbert
PREINING, Norbert http://www.preining.info
JAIST, Japan TeX Live Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
--
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| www.pragma-pod.nl
-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743378: workstation.d/kernel: trivial fix for reworded Caching mode page messages
Package: logcheck-database
Version: 1.3.16
Severity: normal
Tags: patch
Hello,
Attached you'll find a trivial patch that enables
'ignore.d.workstation/kernel' to capture the recently reworded message
No Caching mode page present (nowadays its present - found).
Thanks,
Hagen
diff --git a/logcheck/ignore.d.workstation/kernel b/logcheck/ignore.d.workstation/kernel
index 53cd1dc..2bc9f80 100644
--- a/logcheck/ignore.d.workstation/kernel
+++ b/logcheck/ignore.d.workstation/kernel
@@ -61,7 +61,7 @@
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? sd [:[:digit:]]+: \[sd[a-z]\] [[:digit:]]+-byte physical blocks$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? sd [:[:digit:]]+: \[sd[a-z]\] Write Protect is (off|on)$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? sd [:[:digit:]]+: \[sd[a-z]\] Mode Sense: [[:xdigit:]]+ [[:xdigit:]]+ [[:xdigit:]]+ [[:xdigit:]]+$
-^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? sd [:[:digit:]]+: \[sd[a-z]\] No Caching mode page present$
+^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? sd [:[:digit:]]+: \[sd[a-z]\] No Caching mode page (present|found)$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? sd [:[:digit:]]+: \[sd[a-z]\] Assuming drive cache: write through$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? sd [:[:digit:]]+: \[sd[a-z]\] Spinning up disk\.\.\.\.ready$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? [[:space:]]*sd[a-z]:( sd[a-z][[:digit:]]+)*$
Bug#717245: cups-daemon: Bonjour record changed format from printer@host.domain to printer@host in 1.6
Hello, For posteriority and vanity's sake: I did indeed write a script for the transition period from long to short Bonjour names as advertised by CUPS[0]. It turned out surprisingly effective and stable, so I decided to keep the script around instead of just throwing it away. Perhaps somebody finds it a useful starting point for the same or a similar problem. The thing's called Bonjour Aliases and was in productive use for the last three months at the aforementioned research institute. I put the code up on Github: https://github.com/hfuchs/bonjour_aliases The thing is written in Python and needs one additional module called pybonjour[1] which is not (yet) in the Debian repository. This excellently documented library is essentially doing the heavy lifting. I provide a fleshed-out README and a run-script for use with 'daemontools' or 'runit'. So, for me, the problem is solved and this bugreport may be closed. Thanks! -Hagen [0] Now don't you go round changing it back again! :) [1] https://code.google.com/p/pybonjour/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728985: wget: Terrible performance with gnutls
Package: wget Version: 1.13.4-3 Severity: important Dear Maintainer, I'm using the munin http_loadtime plugin which in turn uses wget to measure the loadtime of websites. While this plugin ususally shows results well below one second, on updated Debian systems the performance drops considerably. It seems to be realted to the switch from openssl to gnutls. Quick: wget -p --no-cache --delete-after http://www.scc.kit.edu/ Slow: wget -p --no-cache --delete-after http://www.scc.kit.edu/ Quick: wget -p --no-cache --ca-certificate=/etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem --no-check-certificate --ca-directory=/tmp/empty --delete-after https://www.scc.kit.edu/ Even worse, options like --no-check-certificat (bad, I know) or --ca-certificate=/etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem do not speed up the process, but --ca-directory=/tmp/empty does. It seems like gnutls is initialized for every request and upon initialisation parses all certificates contained in /etc/ssl/certs I file this as bug against wget, since --ca-certificate and --no-check-certificate do not seem to have any effect, so I guess initialisation of gnutls is defective. -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages wget depends on: ii dpkg 1.16.12 ii libc6 2.13-38 ii libgcrypt111.5.0-5+deb7u1 ii libgnutls262.12.20-7 ii libgpg-error0 1.10-3.1 ii libidn11 1.25-2 ii zlib1g 1:1.2.7.dfsg-13 wget recommends no packages. wget suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722332: libcommon-sense-perl: common::sense runs into trouble with Perl 5.18, eg. no say().
First of all: Nice response time! I'm always in awe of Debian maintainers'
work ethic.
In response to your last comment,
I've committed the changes for the first point; reviews welcome!
I'm not sure how I can review those changes? I `dpkg -i`'d the unstable
version of libcommon-sense-perl, but it's the same thing as before.
What am I missing?
Meanwhile, here's the results of a little investigation of my own:
Executive summary.
This is probably a case for upstream: they'll have to adapt their use of
the '$^H' variable.
Longer version.
The common::sense module's really short, so I tried poking in the source
a bit. Turns out, there's quite a bit of eye-candy; among those the use
of the magic variable '$^H'. `perldoc perlvar` says:
$^H WARNING: This variable is strictly for internal use only.
Its availability, behavior, and contents are subject to change
without notice.
So ... the gods went ahead and changed it, hu? My best guess for
where to look is feature.pm and the difference between 5.14 and 5.18:
https://metacpan.org/source/DAPM/perl-5.14.4/lib/feature.pm
https://metacpan.org/source/RJBS/perl-5.18.1/lib/feature.pm
Rabbit hole! Turns out, in 5.18, $^H is now initialized(?) with
$hint_mask= 0x1c00;
[...]
sub __common {
[...]
$^H |= $hint_mask;
And, of course, a few more manglings happen. Now, simply saying
sed -i 's|0x820f00|0x1c00|' /usr/lib/perl5/common/sense.pm
does the trick:
$ perl -Mcommon::sense -e 'say $common::sense::VERSION; say $^V; say Hi!;'
3.72
v5.18.1
Hi!
(Mind, this naïve substitution is all kinds of wrong -- this is a bitmask with
definitive meaning and will quite probably still not work for all other
use cases of common::sense (utf8, switch, ...) or even introduce more
subtle errors!)
In conclusion, I hope to have established a case for upstream to become
involved.
Regards,
Hagen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722332: libcommon-sense-perl: common::sense runs into trouble with Perl 5.18, eg. no say().
[package tracking system and git repository] I see, thanks! Wondering if we should clone it with lowered severity for a more elegant fix. Comments? Executive Sum.: Upstream is cleared of any wrongdoing, common::sense needs to be built for every Perl version anew. Longer: I've been delving into common::sense's source and realized that the magic number (0x820f00 in the old version's case) is actually set correctly according to Perl version in the build script, sense.pm.PL . So, if common::sense is being built with Perl 5.18 it will work with 5.18 but not with 5.14 and perhaps not even with 5.20 (due to the fast-changing Perl 'feature' facility evinced by the ephemeral nature of $^H). So the line sed -i 's|0x820f00|0x1c00|' /usr/lib/perl5/common/sense.pm simply worked, because it reset the 5.14 $^H to a version that's at least length-wise compatible with 5.18's. Does that make any ... No, no cheap pun today. That's a bit of a bummer for the package's progression through unstable-testing-stable, though, isn't it? Or is that only a problem in my mind? Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722332: libcommon-sense-perl: common::sense runs into trouble with Perl 5.18, eg. no say().
Hi! Sorry for not mentioning this in my first reply. More embarrassing hand-holding? :) Alright, as you guys have this thing covered on all angles, I'll just say this: Awesome work! (I need new vocabulary.) I'm actually looking forward to my next bug report. Sadly enough, I really do. Yours, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722332: libcommon-sense-perl: common::sense runs into trouble with Perl 5.18, eg. no say().
Package: libcommon-sense-perl Version: 3.72-1 Severity: grave Justification: renders package unusable Dear maintainer, I just noticed that, upon upgrading to Perl 5.18.1-3 (Debian testing), common::sense stopped having some: $ perl -Mcommon::sense -e 'say hi;' syntax error at -e line 1, near say hi Execution of -e aborted due to compilation errors. On another machine with Perl 5.14 still installed and the same version of libcommon-sense-perl (3.72-1) it's still the same friendly response: $ perl -Mcommon::sense -e 'say hi;' hi So, *something* happened upon upgrading, although I'm currently at a loss (of time, mainly) to specify what exactly. Surely I messed something up and everything's working fine for everybody else? Thank you! Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693604: [Pkg-utopia-maintainers] Bug#693604: avahi-daemon takes 100% CPU right after boot and at every restart of CUPS
Hello again, That's me back-tracking. Otmar was absolutely right: The load excursions started again (after three months, quite suddenly); reliably, usually at least twice a day with a production print server on Debian Wheezy. Again, Till Kamppeter's patch referenced earlier fixed it (as it did for Otmar). I have *no* idea what causes this. Other print servers -- configured in precisely the same way, seeing about the same usage -- are fine. Please consider the patch for adoption. Thanks, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717245: cups-daemon: Bonjour record changed format from printer@host.domain to printer@host in 1.6
Hello again, Thanks for the effort, appreciate it! I have now pretty much exhausted my options by playing with Avahi's settings (and CUPSens, for all I know). For example, I set browse-domain=domain.local in Avahi's config and got at least my Ubuntu test client to go along with that. Not Macs, of course, they aren't quite as forgiving. My options reduce to: 1. Make a clone of every CUPS 1.5 machine and keep it running alongside the updated machines for as long as the domain-nodomain transition lasts; or 2. Write a small script that takes every nodomain record and creates a replica with only the 'Service Name' field changed to the old form. #2 seems promising and something I'd look forward to do (wield that old 800 pound chainsaw again). I will call the project 'Avahi Aliases' -- it will be an instant classic. :) Input/concerns welcome (for example, I have as yet no idea on how to get/inject Bonjour packets out of/into Avahi)! -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717245: cups-daemon: Bonjour record changed format from printer@host.domain to printer@host in 1.6
Hi Brian, Thanks for the quick reply! The only way I can get the second type of record permanently is by putting it in /etc/hostname, which I believe is read by avahi-daemon. Ah, well now we're going into interesting territory. My /etc/hostname actually says 'cups4dhcp'[0]. I have set CUPS' ServerName to 'cups.pks.mpg.de' and assume this was the name used for the Bonjour record. Is there a way to debug the communication between avahi-daemon and cupsd that doesn't involve an actual debugger? I found avahi-daemon's '--debug' switch to be not that verbose. Is your Debian testing a new install or an upgrade from Wheezy? My servers are all on 'testing' as in 'eternal testing'. :) That probably means the answer is upgrade from Wheezy. I'll keep digging around... -Hagen [0] It's not quite easy to explain, but I'll try: I have *4* CUPS servers that serve different physical subnets (eg. LAN and WLAN). I chose the odd CUPS ServerName-setting in order to ensure that MacOS clients always see the same Bonjour name, instead of 'printer @ cups4dhcp.pks.mpg.de' when connected via cable and 'printer @ cups4wlan.pks.mpg.de' when in the WLAN. MacOS assumes they're different printers, so unhappiness quickly ensues. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717245: cups-daemon: Bonjour record changed format from printer@host.domain to printer@host in 1.6
Package: cups-daemon Version: 1.6.2-10 Severity: important Hello! I am using CUPS in Debian testing to provide access to a pool of 30+ printers to all sorts of OSes (research institute). Switching from CUPS 1.5.3 to 1.6.2, I noticed that it registers its Bonjour records differently with Avahi: `avahi-browse -a` now shows + eth0 IPv4 ps22 @ cups Internet Printer local instead of + eth0 IPv4 ps22 @ cups.pks.mpg.deInternet Printer local This change, unfortunately, breaks printing to these printers from all MacOS systems. A work-around would be to remove all Bonjour-printers from the clients' systems and re-add them again. Considering our user base and the nerves of our IT support team, I'd much prefer to keep the old record format. So, is this change intentional? If so, is there a way to revert to the old format with CUPS 1.6? (I have been playing with 'ServerName', 'ServerAlias' settings in cupsd.conf -- to no avail. I also tried changing the 'host-name' parameter in Avahi -- dito.) Thanks! Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693604: [Pkg-utopia-maintainers] Bug#693604: avahi-daemon takes 100% CPU right after boot and at every restart of CUPS
Hello, About two weeks ago I replaced all my locally modified packages with those in testing (which are currently the same version as in stable: 0.6.31-2). In that period approx. 4000 print jobs have gone over our four print servers and none of them showed any signs of the aforementioned load excursion. Previously, not a day went by without going on a hunt for rogue Avahi daemons. So, I guess either Avahi's been patched silently or some other condition remedies (masks?) the problem. In any case, from my point of view, it would make sense to reduce the severity or even close the bug report now. Thanks! -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693604: avahi-daemon takes 100% CPU right after boot and at every restart of CUPS
Package: avahi-daemon Followup-For: Bug #693604 Hello, I can confirm that applying the patch mentioned above[0] directly on the Debian avahi-sources stopped these occurrences. To be clear: Avahi /never/ recovers from these load excursions and stays at ~100% until killed. In our environment of 39 print queues (about 30 physical printers) this had become rather a serious headache with multiple daily occurrences. I wrote a rather desperate script that would minutely check for Avahi's well-being. After applying the patch about two weeks ago, it (the script) recorded not one instance of permanent overload. More tidbits: I have/had two servers exhibiting this behaviour (from a total of four). They multicast into different subnets. One is a x86_64 KVM machine, the other a i686 OpenVZ container. Also, the behaviour occurs in heavily MacOS-infes...frequented subnets. Thanks! -Hagen [0] Direct link: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1059286/+attachment/3387784/+files/avahi_0.6.31-1ubuntu1_0.6.31-1ubuntu2.debdiff -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670911: Database disk image is malformed
Package: darktable Version: 0.9.3-2 $ darktable sqlite3 error: /build/darktable-0aGDAQ/darktable-0.9.3/src/control/control.c:158, function dt_control_sanitize_database(): database disk image is malformed sqlite3 error: /build/darktable-0aGDAQ/darktable-0.9.3/src/control/control.c:159, function dt_control_sanitize_database(): no such table: temp_history sqlite3 error: /build/darktable-0aGDAQ/darktable-0.9.3/src/views/view.c:472, function dt_view_image_expose(): database disk image is malformed sqlite3 error: /build/darktable-0aGDAQ/darktable-0.9.3/src/views/view.c:472, function dt_view_image_expose(): database disk image is malformed sqlite3 error: /build/darktable-0aGDAQ/darktable-0.9.3/src/views/view.c:472, function dt_view_image_expose(): database disk image is malformed sqlite3 error: /build/darktable-0aGDAQ/darktable-0.9.3/src/views/view.c:472, function dt_view_image_expose(): database disk image is malformed sqlite3 error: /build/darktable-0aGDAQ/darktable-0.9.3/src/views/view.c:472, function dt_view_image_expose(): database disk image is malformed sqlite3 error: /build/darktable-0aGDAQ/darktable-0.9.3/src/views/view.c:472, function dt_view_image_expose(): database disk image is malformed sqlite3 error: /build/darktable-0aGDAQ/darktable-0.9.3/src/views/view.c:472, function dt_view_image_expose(): database disk image is malformed The result is clear: I didn't see any images previously added to the database. Are there any incompatible changes in the disk format to darktable previously? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669388: wicd-daemon: Fix for CVE-2012-2095 invalidates all templates that use 'ca_cert', 'password' and other fields.
Package: wicd-daemon
Version: 1.7.2.1-1
Severity: grave
Tags: upstream
Justification: renders package unusable
Hi there,
[tl;dr. wicd 1.7.2 (upstream development revision 751) introduces
a fatal bug that invalidates many connection templates.]
I just upgraded my wicd installation (to Wheezy's 1.7.2) and witnessed
my wireless connection fail. wicd's log file contains entries that read
2012/04/19 13:10:22 :: Trying to set invalid property (or property not
permitted): ca_cert.
2012/04/19 13:10:22 :: Trying to set invalid property (or property not
permitted): password.
2012/04/19 13:10:22 :: Trying to set invalid property (or property not
permitted): identity.
Those settings will accordingly not be reflected in
/etc/wicd/wireless-settings.conf or /var/lib/wicd/configurations/*.
I (quickly :) realized that the changes introduced in reaction to
CVE-2012-2095 where to blame. So, without further ado, I'll point you
the appropriate patch:
http://bazaar.launchpad.net/~wicd-devel/wicd/experimental/revision/751/wicd/wicd-daemon.py
The properties that `self._validProperties` introduces are *nowhere
near* a complete representation of supported wpa_supplicant fields
(which it quite probably should!). Just to be sure, I consulted
wpa_supplicant.conf(5) and found all of the invalid properties above
used in examples.
Finally, I applied the patch below to
/usr/share/wicd/daemon/wicd-daemon.py and could 'appily browse again
(thus the bug report :).
I suggest you get this to upstream's attentation as quickly as possible
as quite a few of wicd's own templates are now invalid. Hence the
elevated priority (I *do* hope, I'm not wrong on this ... ).
Thanks!
Regards,
Hagen Fuchs
Trivial proof-of-concept patch (diff -wu wicd-daemon.py*):
--- wicd-daemon.py 2012-04-19 15:35:52.023010442 +0200
+++ wicd-daemon.py.hfuchs 2012-04-19 15:55:04.830971520 +0200
@@ -1087,9 +1087,10 @@
Sets property to value in network specified.
# We don't write script settings here.
if prop.strip() not in self._validProperties:
-print Trying to set invalid property (or property not \
- permitted): + prop.strip() + .
-return False
+print I'll allow that - for now! :)
+#print Trying to set invalid property (or property not \
+# permitted): + prop.strip() + .
+#return False
self.LastScan[netid][prop] = misc.to_unicode(misc.Noneify(value))
@dbus.service.method('org.wicd.daemon.wireless')
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669388: wicd-daemon: Fix for CVE-2012-2095 invalidates all templates that use 'ca_cert', 'password' and other fields.
Hello David, Unfortunately, I'm the only upstream developer, so I can't really test every possible scenario. Well, you're doing one hell of a job. wicd is my prime architectural role models for UI server-client architecture. One of those keep in mind for the big thing projects. I'm really sorry for having introduced such a nasty bug. It's your software, do as you like. ;) I hope I'll be able to release 1.7.2.2 later tonight, when I'll be back home from work. Marvellous! I'll stop heaping kudos now and wait till rev 759 hits the repo (or should it already have done so?). Yours, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669388: wicd-daemon: Fix for CVE-2012-2095 invalidates all templates that use 'ca_cert', 'password' and other fields.
Hi, I already uploaded it a while ago, so if it doesn't tonight, it surely will be tomorrow :) I was actually looking forward to digging around in the code a bit tonight, but you were simply too fast - I didn't realize that you not only fixed the thing but also packaged it by now. Impressive response time. Got to be nimble on my feet next time. Thanks again, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666059: clusterssh: cssh does not deal well with compound commands
Package: clusterssh
Version: 4.00_11
Severity: normal
Tags: upstream
Hello,
I am in the unenviable position to report a bug on behalf of a
colleague, whom I explained the behaviour described below to. He
subsequently lost interest and my almost-finished, rather lucidly
written script that reproduced the critical cssh-features lingered sadly
on my drive ever since. No more! Here we go:
ClusterSSH does not deal well with compound commands as handed to the
'-a' flag, eg.
cssh [remote_server] -a cd /; ls; sleep 10
The directory listed will be the local working directory, /not/ the
remote root directory.
I elaborated on this in a separate Perl script, available on Github[0]
and attached. The comment section does a good job (I'm a bit
self-aggrandising today, am I not?) explaining, but heavily references
the (very small) code section of the script. For this reason, I am not
including the description here and instead would like to refer you to
the script.
In addition the script offers a naïve solution!
Sorry for the wild circumstancial mess.
Yours,
Hagen
[0] https://github.com/hfuchs/misc/blob/master/cssh_action_test.pl
#!/usr/bin/perl
# 2011-11-04, Created by Hagen Fuchs hagen.fu...@physik.tu-dresden.de
#
# Purpose: ClusterSSH does not deal well with compound commands as
# handed to the '-a' flag, eg.
#
# cssh [remote_server] -a cd /; ls; sleep 10
#
# The directory listed will be the local working directory, /not/ the
# remote root directory. This file is a working example that exhibits
# the precise same behaviour. Almost all of the code here has been
# pasted and shortened to its essence from App/ClusterSSH.pm (in
# /usr/share/perl5 on my system). That makes it slightly longer than
# strictly necessary but code here can now easily be matched with code
# in the ClusterSSH module.
#
# Looking at the eval()ed and exec()ed strings below, one can easily see
# how appropriate quoting will break the expression in $helper_script.
# Eg. trying to protect the inner expression with single quotes,
#
# cssh [remote_server] -a 'cd /; ls; sleep 10'
#
# or
#
# perl cluster_test.pl [remote_server] -a 'cd /; ls; sleep 20'
#
# will spectacularly fail. On the other hand, an expression like
#
# perl cluster_test.pl [remote_server] -a \\\cd /; ls; sleep 20\\\
#
# works as it transports both backslashes and quotes safely through
# two layers of string interpolation (first Perl's, then the shell's).
# This translates straightforward into
#
# cssh [cluster] -a \\\cd /; ls; sleep 10\\\
#
#
# Proposed Solution:
# --
# Naïvely, I'd say substitute $config{command} in $helper_script with
# the unwieldy construct
#
# \\\$config{command}\\\
#
# and be done with it. But deep down I'd know: this whole part needs
# more thought and less brittle quoting magic.
use common::sense; # Where else, if not here? ;)
use Pod::Usage;
use Getopt::Long qw(:config no_ignore_case bundling no_auto_abbrev);
my @options_spec = ( 'action|a=s' );
my %options;
my %config;
pod2usage( -verbose = 1 )
if ( !GetOptions( \%options, @options_spec ) );
$config{command} = $options{action} if ( $options{action} );
my @servers = @ARGV;
my $helper_script = HERE;
my \$command = ssh $servers[0];
\$command .= \\\$config{command}\\\ || sleep 5;
exec(\$command);
HERE
#eval $helper_script || die ($@);
my $exec = xterm -e \$^X\ \-e\ '$helper_script';
# hfuchs| Diagnostics (not in ClusterSSH).
say Helper Script:;
say $helper_script;
say Exec Line:;
say $exec;
exec($exec) == 0 or die $!;
Bug#377548: Fails mounting some parts in a n-in-1 device
Hello again, I was pondering a lock-less solution and your patches seem to provide a good upgrade path towards that. Unfortunately: $ git clone git://git.katzien.de/usbmount.git Cloning into usbmount... git.katzien.de[0: 82.165.99.49]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) Thanks for the quick response! Yours, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#377548: Fails mounting some parts in a n-in-1 device
Package: usbmount Severity: normal Hello, I tested Jan's patch with a flash drive that has 12 partitions on it. The original position of the locking code just at the beginning of the add handler will usually only be able to mount 3 to 4 partitions on my machine before lockfile-create will give up. Jan has proposed a more logical position right before usbmount actually deals with the outside world - putting the locking code there (as a whole or as a function call) will consistently yield the expected usbmount behaviour: mounting of all 12 partitions. This solution doesn't scale very well either, though, because we're using `lockfile-create --retry 3` which waits in fixed time intervals between retries (+5sec on every retry, ie 15sec after the third try), thus increasing the likelihood of deadlocks. In my 12-partition-scenario, the last partitions get sometimes mounted in the third (and last) retry cycle of lockfile-create (after ~30 sec). In any case, we should adopt Jan's patch, thereby closing this bug for n-in-1 devices where n 10. Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#403209: locking - necessary to avoid long wait for multi-device card reader
Package: usbmount Severity: normal Hello, I just now perused the changelog and saw the message for version 0.0.17.1: revert patch from #403209 (seems to introduce race conditions) Seems, I should familiarize myself with the code /and/ its history, before going off and analysing code from my chair when its already been proven not to work. Sorry for that. Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#403209: locking - necessary to avoid long wait for multi-device card reader
Package: usbmount Severity: normal Hello Richard, Rogério, Won't per-device locking eventually produce race conditions? Specifically, I'm looking at the code that allocates a mount point: # Search an available mountpoint. for v in $MOUNTPOINTS; do if [ -d $v ] ! grep -q ^[^ ][^ ]* *$v /proc/mounts; then mountpoint=$v log debug mountpoint $mountpoint is available for $DEVNAME break fi So if you don't do global locks and plug in a few different, /active/ devices, you'll probably overmount. ;) So I think we'll have to find another way to speed usbmount up a little. Best Regards, Hagen Fuchs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#377548: Fails mounting some parts in a n-in-1 device
Package: usbmount Severity: normal Hello Jan, I have just looked at #403209 and the patch proposed there seems to me to lead straight into race conditions upon finding a free mount point (see there for further reference). The problem you described sounds almost as if you had the #403209-patch applied, but I assume there's a different problem at work. I will try to find and reactivate an old USB-IDE and partition it heavily in order to try and reproduce your report. Your patch, by the way, looks good to me! usbmount only needs to lock right before search a free mount point and putting logically related code in a separate function is almost always a good idea. So, yeah, I think we should use that. Best Regards, Hagen Fuchs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630541: wrong permission in mount
Package: usbmount Severity: normal Hello barabba, I'm trying to squish a few bugs in usbmount and this one is currently the only one listed with a severity level of important. Unfortunately, I cannot quite grasp the problem(s) you're describing. The following list tries to summarize what I think you might experience and suggestions/questions that I have. 1. usbmount r/w access only possible as root, permissions are wrong Have you tried specifying a custom fstype string for vfat in the configuration file? 2. The mount point is not correct usbmount currently uses generic mount points, eg. /media/usb0 up to /media/usb7. There is another bug for usbmount, a wishlist item, that addresses this[0]. 3. usbmount has udisk problems I don't understand. What were you trying to do? Please elaborate on those points, if at all possible. If you're not sure whether those problems persist or you don't care anymore, please tell us regardless. Many thanks! Best Regards, Hagen Fuchs [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321694 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632112: openthesaurus-de-text: does not trivially work with ding
Package: openthesaurus-de-text Version: 20110119-3 Severity: important Hello, The description of the openthesaurus package specifically mentions its usability with the dictionary program ding. As I was unable to actually achieve this (without major hackage such as reformatting the entire openthesaurus.txt file), I would like to request a short description of the process in the README.Debian file. Best Regards, Hagen Fuchs -- System Information: Debian Release: 6.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i586) Kernel: Linux 2.6.32-5-486 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632116: ding: not possible to add generic search
Package: ding Version: 1.7-1 Severity: normal Hi there, I ran into considerable difficulties trying to make good on the promise of the package openthesaurus-de-text that it would work with ding. The format of their file is bla;foo;bar so that I cannot simply use ding's dictionary mode (using the semicolon as separator). Therefore, I tried to add a generic search (via Search Preferences) which invariably always requites my efforts with an error message reading can't read smeth(grepcmd): no such element in array An example setup would be Name: test Search command: dict Language: English The same message appears when specifying my executable scripts with full (and valid) path names as Search command. The documentation - both on- and in-line - seems rather silent on this topic. An obvious fix for this /special/ case would be to convert the thesaurus file into the two-term format that the dictionary module of ding expects. But the problem described here is more general. In case I really didn't lengthily show off my incompetence just now, I would be happy to assist in hunting this down. Best Regards, Hagen -- System Information: Debian Release: 6.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i586) Kernel: Linux 2.6.32-5-486 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#491456: It works without X server in headless mode
I run into the same issue and subsequently found this blog and went through every single suggestion provided so far but was not able to resolve it. Though, I finally figured it out and share it here in case someone else gets the same trouble. In my case, I only wanted to use unoconv on my headless (no X Server) Ubuntu 11.04 (natty) chroot. It took me many many hours. Therefore the sequence of steps outlined below does not reflect what I have gone through but it shows the relevant bits. #Installed unoconv $sudo apt-get install unoconv #Run unoconv $unoconv -f pdf mytext.txt javaldx: Could not find a Java Runtime Environment! Please ensure that a JVM and the package libreoffice-java-common is installed. If it is already installed then try removing ~/.libreoffice/3/user/config/javasettings_Linux_*.xml Error: Unable to connect or start own listener. Aborting. #I followed the suggestion and installed libreoffice-java-common and openjdk-6-jre-headless. #Run unoconv $unoconv -f pdf mytext.txt unoconv: UnoException during conversion: URL seems to be an unsupported one. The provided document cannot be converted to the desired format. #Then I came across this debian bug 491456 discussion and followed the suggestion to install #libreoffice-writer libreoffice-calc libreoffice-impress #Run unoconv $unoconv -f pdf mytext.txt Error: Unable to connect or start own listener. Aborting. #Then I learned that (mentioned above in this thread) that the LibreOffice process (soffice) needs to be running. $ soffice Failed to open display #I didn't worry about this much and run the unoconv command again $unoconv -f pdf mytext.txt Error: Unable to connect or start own listener. Aborting. #Eventually I figured out that the soffice process needs to be started with the -headless and -nofirststartwizard parameters. http://code.google.com/p/openmeetings/wiki/OpenOfficeConverter Note: Make sure that you kill any previously started soffice processes. To check this, run ps -l | grep soffice. $/usr/lib/libreoffice/program/soffice -headless -nofirststartwizard -accept=socket,host=localhost,port=8100;urp;StarOffice.Service #Run unoconv $unoconv -f pdf mytext.txt Now, it worked. It successfully converted mytext.txt to mytext.pdf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629176: virtualbox-ose-dkms: Warning about perf_counter_paranoid during boot
Package: virtualbox-ose-dkms Version: 3.2.10-dfsg-1 Severity: important During boot I get the following warning: vboxdrv: Warning: 2.6.31+ kernel detected. Most likely the hardware performance vboxdrv: counter framework which can generate NMIs is active. You have to prevent vboxdrv: the usage of hardware performance counters by vboxdrv: echo 2 /proc/sys/kernel/perf_counter_paranoid According to http://vbox.innotek.de/pipermail/vbox-dev/2010-June/002860.html and http://www.familytidings.com/blog/?p=599 this can lead to host reboots. -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages virtualbox-ose-dkms depends on: ii dkms 2.1.1.2-5 Dynamic Kernel Module Support Fram virtualbox-ose-dkms recommends no packages. virtualbox-ose-dkms suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622626: lxc: Re: LXC Debian template architecture bug
Package: lxc Version: 0.7.2-1 Severity: normal Hi there, Same behaviour here. Though my hardware's different (Transmeta Crusoe), I found that lxc-debian works happily with the patch appended. This patch is just a readily applicable (and slightly more [Ba]shistic) version of Benjamin's suggestion (I'd written this report before spotting his - I'd probably have shut up otherwise :). Best Regards, Hagen Fuchs --- lxc-debian 2011-05-16 10:19:09.0 +0200 +++ lxc-debian.fixed2011-05-16 10:19:03.0 +0200 @@ -151,7 +151,7 @@ arch=amd64 fi - if [ $arch == i686 ]; then + if [ $arch == i686 -o $arch == i586 ]; then arch=i386 fi
Bug#625845: apt: Cron job doesn't correctly handle removal by archive size.
Package: apt Version: 0.8.14.1 Severity: normal I recently discovered the /etc/cron.daily/apt script and wanted to use it to download upgradeable packages and then immediately afterwards delete them. Point is: There's a caching daemon (apt-cacher-ng) in between that will keep requested packages around but cannot by itsself determine and download upgradeable packages. So, as suggested in the cron job, I created the file /etc/apt/apt.conf.d/02periodic with the following contents: APT::Periodic::MinAge 0; APT::Periodic::Verbose 2; APT::Periodic::MaxSize 1; APT::Periodic::Update-Package-Lists 1; APT::Periodic::Download-Upgradeable-Packages 1; The MinAge=0 setting should allow the clean-by-size-routine to indiscriminately kill newly downloaded packages, or so I thought. Well, it doesn't, as this whole clean-by-size subtree will be deactivated if MinAge==0. This is easily fixed by moving this check a bit deeper as can be seen in the small and trivial patch I attached (apt.remove_by_size.diff). I don't think it'll break any of the more customary use cases (such as actually keeping downloaded packages around for later installation :). There are also a few comments marked TODO in this diff - those contain suggestions for later improvements (or silly remarks, I'm often not sure). Thanks, Hagen diff --git a/cron.daily/apt b/cron.daily/apt index 75986f5..efce46f 100755 --- a/cron.daily/apt +++ b/cron.daily/apt @@ -170,6 +170,7 @@ check_size_constraints() # check size if [ ! $MaxSize -eq 0 ]; then # maxSize is in MB + # TODO Well, no... 1024 - binary prefixes (MiB, KiB,... :). MaxSize=$(($MaxSize*1024)) #get current time @@ -187,7 +188,7 @@ check_size_constraints() fi # check for MinAge of the file - if [ $MinAge -ne 0 ]; then + # hfuchs| Moved age check deeper below - doesn't make sense here. # check both ctime and mtime mtime=$(stat -c %Y $file) ctime=$(stat -c %Z $file) @@ -196,14 +197,19 @@ check_size_constraints() else delta=$(($now-$ctime)) fi - if [ $delta -le $MinAge ]; then + # hfuchs| Moved MinAge != 0 check here. + if [ $delta -le $MinAge -a $MinAge -ne 0 ]; then debug_echo skip remove by archive size: $file, delta=$delta $MinAgeSec + # TODO Why break here? Just because of one file that's too fresh? break else # delete oldest file + # TODO btw: I read somewhere at the top of this file that + # the biggest files are deleted first? I can't see it + # happening. Don't relly care, either. ;) + # TODO Indentation is a bit of a mess down here. debug_echo remove by archive size: $file, delta=$delta = $MinAgeSec (sec), size=$size = $MaxSize rm -f $file - fi fi done fi
Bug#621903: dvd-slideshow: Preflight check should be stricter
Package: dvd-slideshow Version: 0.8.2-0.1ubuntu2 Severity: wishlist The preflight check detects many problems, but far from all. Simple spelling errors and typoes like kenbruns or Kenburns instead of kenburns or 50%% instead of 50% are not detected during preflight check. Maybe during preflight check, the script could simply run through its normal schedule simply with all real action disabled (by some $preflightcheck flag) and thus guarantee that *all* missing file, bad syntax, and bad parameter conditions are detected before the actual rendering starts. -- System Information: Debian Release: squeeze/sid APT prefers lucid-updates APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-28-generic (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dvd-slideshow depends on: ii dvdauthor0.6.14-3ubuntu4 create DVD-Video file system ii ffmpeg 4:0.5.1-1ubuntu1multimedia player, server and enco ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4 Fonts for the Ghostscript interpre ii imagemagick 7:6.5.7.8-1ubuntu1.1image manipulation programs ii libavcodec-e 4:0.5.1-1ubuntu1+medibuntu1 ffmpeg codec library ii mjpegtools 1:1.9.0-0.5ubuntu3 MJPEG video capture/editting/playb ii netpbm 2:10.0-12.1ubuntu1 Graphics conversion tools between ii sox 14.3.0-1.1build1Swiss army knife of sound processi Versions of packages dvd-slideshow recommends: ii jhead 1:2.88-2 manipulate the non-image part of E ii lame 3.98.2+debian-0ubuntu3 An MP3 encoding library (frontend) ii twolame 0.3.12-1 MPEG Audio Layer 2 encoder (comman dvd-slideshow suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621904: dvd-slideshow: duration audio should use only *remaining* sound length
Package: dvd-slideshow Version: 0.8.2-0.1ubuntu2 Severity: normal Setting the duration of an image or effect to audio should render that image/effect until the end of the latest audio, not as long as the latest audio. Example: /some-audio-of-20-seconds.mp3 /first-image.jpg:7 /second-image.jpg:7 /third-image.jpg:audio will show the third image for 20 seconds (hence with 14 seconds of silence). It would be more logical for the audio keyword to translate to a duration of 20-7-7 = 6 seonds here, so that the imgae ends at the same time as the audio (which I assume is the intended purpose of the audio keyword). -- System Information: Debian Release: squeeze/sid APT prefers lucid-updates APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-28-generic (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dvd-slideshow depends on: ii dvdauthor0.6.14-3ubuntu4 create DVD-Video file system ii ffmpeg 4:0.5.1-1ubuntu1multimedia player, server and enco ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4 Fonts for the Ghostscript interpre ii imagemagick 7:6.5.7.8-1ubuntu1.1image manipulation programs ii libavcodec-e 4:0.5.1-1ubuntu1+medibuntu1 ffmpeg codec library ii mjpegtools 1:1.9.0-0.5ubuntu3 MJPEG video capture/editting/playb ii netpbm 2:10.0-12.1ubuntu1 Graphics conversion tools between ii sox 14.3.0-1.1build1Swiss army knife of sound processi Versions of packages dvd-slideshow recommends: ii jhead 1:2.88-2 manipulate the non-image part of E ii lame 3.98.2+debian-0ubuntu3 An MP3 encoding library (frontend) ii twolame 0.3.12-1 MPEG Audio Layer 2 encoder (comman dvd-slideshow suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621905: dvd-slideshow: Unusual hostname may cause erroneous SMP detection
Package: dvd-slideshow Version: 0.8.2-0.1ubuntu2 Severity: normal Line 574 of /usr/bin/dvd-slideshow if [ -z `uname -a | grep -i smp` ] ; then uses uname -a to test for presence of SMP. Since uname -a also contains the hostname, a single processor machine with a hostname containing the letter sequence smp will erroneously be assumed to be a multiprocessor machine. I suggest using uname -v instead (or to check /proc/cpuinfo) -- System Information: Debian Release: squeeze/sid APT prefers lucid-updates APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-28-generic (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dvd-slideshow depends on: ii dvdauthor0.6.14-3ubuntu4 create DVD-Video file system ii ffmpeg 4:0.5.1-1ubuntu1multimedia player, server and enco ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4 Fonts for the Ghostscript interpre ii imagemagick 7:6.5.7.8-1ubuntu1.1image manipulation programs ii libavcodec-e 4:0.5.1-1ubuntu1+medibuntu1 ffmpeg codec library ii mjpegtools 1:1.9.0-0.5ubuntu3 MJPEG video capture/editting/playb ii netpbm 2:10.0-12.1ubuntu1 Graphics conversion tools between ii sox 14.3.0-1.1build1Swiss army knife of sound processi Versions of packages dvd-slideshow recommends: ii jhead 1:2.88-2 manipulate the non-image part of E ii lame 3.98.2+debian-0ubuntu3 An MP3 encoding library (frontend) ii twolame 0.3.12-1 MPEG Audio Layer 2 encoder (comman dvd-slideshow suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#147839: Short README file describing how to create a password DB for pam_userdb.so
Package: libpam-modules Severity: normal Hello, I would just like to add that the last part in this README concerning the implicit addition of the '.db' extension in the pam_userdb module hit me quite hard this week. Could pam_userdb(8) perhaps add an appropriate line? The 'db' entry under OPTIONS looks to me like the prime candidate: db=/path/database Use the /path/database database for performing lookup. There is no default; the module will return PAM_IGNORE if no database is provided. Please note that the extension '.db' will be appended implicitly. Thanks! Best Regards, Hagen Fuchs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608843: iwatch: Trouble with utf8 characters in filenames (+ 2 possible fixes)
Hi, I realise that both versions posted earlier (1: downgrade system()-string; 2: use Encode, use open) break character representation in e-mail notifications. So the royal way would probably be to properly decode()/encode() everywhere. Or am I going completely astray here? Regards, HF -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608843: iwatch: Trouble with utf8 characters in filenames (+ 2 possible fixes)
Package: iwatch
Version: 0.2.2
Severity: normal
Hi,
iwatch had - for as long as I dare to remember - a somewhat strained
relationship with UTF-8 characters. Exempli gratia:
First shell:
iwatch -v -c 'ls %f' -e create .
Second shell:
touch mö
Output (first shell):
Watch .
[ 3/Jan/2011 23:24:35] IN_CREATE ./mö
[ 3/Jan/2011 23:24:35] * Command: ls ./mö
ls: cannot access ./mö: No such file or directory
I decided not to work around this behaviour any longer and try to get
iwatch to correctly pass on UTF-8 chars. And down Perl's
UTF-8/utf8/PerlIO hole I went... I have two very small patches
(+2 lines each, appended) that seem to produce what I like to think
could be correct behaviour. I tested variant 1 (see
iwatch.variant1.diff) and have it in (very limited) production use.
I would be happy to discuss the patches if anybody's interested - I
still haven't quite grasped what I actually did.
Best Regards,
Hagen Fuchs
-- System Information:
Debian Release: 5.0.7
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to en_GB.utf8)
Shell: /bin/sh linked to /bin/bash
--- iwatch 2011-01-03 22:29:06.0 +0100
+++ iwatch.variant1 2011-01-03 22:33:32.0 +0100
@@ -416,6 +416,8 @@
$command =~ /^(.+)$/;
return if(!defined($1));
my $securecommand = $1;
+# Force byte-string semantics [why does that work?].
+utf8::downgrade($securecommand) if (utf8::is_utf8($securecommand));
system($securecommand);
}
if(defined($Message) $Path-{'alert'}) {
--- iwatch 2011-01-03 22:29:06.0 +0100
+++ iwatch.variant2 2011-01-03 22:32:23.0 +0100
@@ -19,6 +19,9 @@
use XML::SimpleObject::LibXML;
use POSIX;
use Sys::Syslog;
+# Force UTF-8 interpretation of strings and IO.
+use encoding 'utf-8';
+use open qw|:utf8 :std|;
my $PROGRAM = iWatch;
my $VERSION = 0.2.2;
Bug#593520: cil: Dependency missing: libfile-homedir-perl.
Package: cil Version: 0.07.00-1 Severity: important The upstream version of cil has the dependency on libfile-homedir-perl in 'debian-lenny/control'. But, even tough the debian source-archive (acquired with `apt-get source cil`) contains the dependency specification, the actual package does not list it: http://packages.debian.org/sid/cil Am I missing something trivial here? I suspect so. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570542: gitosis: Does not initialise as advertised - needs Python module peak
Package: gitosis Version: 0.2+20090917-2 Severity: important Following the setup procedures in /usr/share/doc/gitosis/README.Debian, I issued (as root): sudo -H -u gitosis gitosis-init gitosis_rsa.pub The resulting Python traceback essentially says: ImportError: No module named peak The same thing after aptitude install python-peak.util works fine. So, I suggest making the package 'python-peak.util' a mandatory requirement. Thanks, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#441595: [Dev-luatex] (fwd) Bug#441595: not all libraries are customized, there is room for improvement
Norbert Preining wrote: Dear Taco, one of the lua Gurus here at Debian checked the embedded libs and found that most of the included libs are very similar to upstream, and he offered to push the few changes in your code to upstream. What do you say? (See attached email, including the diffs between current upstream of the lua libs and code in texlua). TeX has alwaye been independent of external libraries, although for pdftex it's possible to keep some libs external. Although the 'teams' assume statics, its' up to the distributers to decide on external libs; kpse has been an example for a long time already but that one lives alongside tex. For luatex it's somewhat different. Take for instance a moving target like lpeg. Macro packages depend on the functionality as defined when the luatex version came around. If some (maybe more recent) library is used it might break things. And it might even be that at some point when we have luatex version 1.0, we freeze on libraries (apart from bug fixes of course). The same might happen with lua itself. If lua 6 comes around we might add an extra lua engine but keep 5 around as well. Loading libraries in luatex can become a nightmare esp when we thing of mixes with luarocks and other distributions. As lua is meant for embedding, the libs we use are also kind of internal. Of course, pushing changes/patches upstream is great. This is a tricky issue. In principle luatex, once stable, should run decades as-is. An independent entity. On th eother hand, progress is also a nice thing. I can imagine a scenario where we have a static luatex as usual, but when distributers want to go dynamic they should use the (in terms of api) same libs as static. None of us is looking forward to getting bug reports like luatex+macropackage reports an lpeg error which only happens with non statics bins. Also, i wonder, if luatex demands some specific lib version, how does this translate to installation? Currently i can just drop a static luatex bin in my tex bin path but what if a bunch of extra libs (maybe already present but potentially conflicting) are used? Ok, we can control things with the cpath variable, but that also adds another variable to the game. Anyhow, this needs quite a bit of thinking. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#441595: [Dev-luatex] (fwd) Bug#441595: not all libraries are customized, there is room for improvement
Martin Schröder wrote: 2009/12/19 Hans Hagen pra...@wxs.nl: what does that mean in practice for your tex live installer? that it has to fetch (and compile) extra libs? Debian: Dynamic libs. TeXlive: Mostly static binaries. yes but how does it check if the libs are functionally the same? Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#441595: [Dev-luatex] (fwd) Bug#441595: not all libraries are customized, there is room for improvement
Hi Norbert No, only that as long as the libraries in texlua are the same as upstream I can reuse the the packages in Debian. what does that mean in practice for your tex live installer? that it has to fetch (and compile) extra libs? Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#441595: [Dev-luatex] (fwd) Bug#441595: not all libraries are customized, there is room for improvement
Martin Schröder wrote: 2009/12/19 Hans Hagen pra...@wxs.nl: yes but how does it check if the libs are functionally the same? APIs are versioned and checked by the loader. http://en.wikipedia.org/wiki/Dynamic_library#Dynamic_linking It works. Mostly. sure, but i wonder what this means for the texlive updater ... will it also ship upgraded (or ancient) library versions then? Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556600: getaddrinfo() fails with system error
, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110) = -1
ENOENT (No such file or directory)
close(3)= 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110) = -1
ENOENT (No such file or directory)
close(3)= 0
open(/etc/host.conf, O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0644, st_size=9, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f37ec418000
read(3, multi on\n, 4096) = 9
read(3, , 4096) = 0
close(3)= 0
munmap(0x7f37ec418000, 4096)= 0
getpid()= 27836
open(/etc/resolv.conf, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=24, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f37ec418000
read(3, nameserver 94.75.228.29\n, 4096) = 24
read(3, , 4096) = 0
close(3)= 0
munmap(0x7f37ec418000, 4096)= 0
uname({sys=Linux, node=perrin, ...}) = 0
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=82373, ...}) = 0
mmap(NULL, 82373, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f37ec404000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/libnss_nis.so.2, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0
\0\0\0\0\0\0..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=43552, ...}) = 0
mmap(NULL, 2139320, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f37eba96000
mprotect(0x7f37ebaa, 2093056, PROT_NONE) = 0
mmap(0x7f37ebc9f000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x9000) = 0x7f37ebc9f000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/libnsl.so.1, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\...@\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=89064, ...}) = 0
mmap(NULL, 2194128, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f37eb87e000
mprotect(0x7f37eb893000, 2093056, PROT_NONE) = 0
mmap(0x7f37eba92000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x7f37eba92000
mmap(0x7f37eba94000, 6864, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f37eba94000
close(3)= 0
mprotect(0x7f37eba92000, 4096, PROT_READ) = 0
mprotect(0x7f37ebc9f000, 4096, PROT_READ) = 0
munmap(0x7f37ec404000, 82373) = 0
uname({sys=Linux, node=perrin, ...}) = 0
write(2, error in getaddrinfo: -11 / Syst..., 41error in
getaddrinfo: -11 / System error
) = 41
write(2, system error: 0 / Success\n, 26system error: 0 / Success
) = 26
exit_group(1)
===
Thanks for your time and interest,
Hagen.
--
Hagen Möbius
Lychener Str. 81, 10437 Berlin, Germany
Home: +49 30 4450091
Cell: +49 179 5853897
Mail: hagen.moeb...@googlemail.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556600: getaddrinfo() fails with system error
Hi back. That did it. Thanks a bunch! Now the problem is certainly resolved but why is the error reporting so wrong (EAI_SYSTEM points to errno which does not contain any error information) and why is the fallback not working? Is that related to the [NOTFOUND=return] directive? Anyway, thanks for your input, Hagen. /etc/nsswitch === # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc-reference' and `info' packages installed, try: # `info libc Name Service Switch' for information about this file. passwd: nis compat group: nis compat shadow: nis compat hosts: nis files mdns4_minimal [NOTFOUND=return] dns mdns4 networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis === Hm, I don't have a NIS configuration here ... only thinking alound. The strace shows that the System error comes from the nis NSS library. This is the first one called to resolv hosts type records. Removing nis here would probably solve your problem. -- Hagen Möbius Lychener Str. 81, 10437 Berlin, Germany Home: +49 30 4450091 Cell: +49 179 5853897 Mail: hagen.moeb...@googlemail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556600: getaddrinfo() fails with system error
Package: libc6
Version: 2.10.1-7
Programs which use getaddrinfo() to resolve addresses fail most of the
time. I tried to get to the bottom of the error and came up with the
following little program, that exhibits the error.
test.c
===
#include errno.h
#include stdio.h
#include netdb.h
#include string.h
int main(void)
{
struct addrinfo * result;
int error;
error = getaddrinfo(ftp.de.debian.org, http, NULL, result);
if(error != 0)
{
fprintf(stderr, error in getaddrinfo: %d / %s\n, error,
gai_strerror(error));
if(error == EAI_SYSTEM)
{
fprintf(stderr, system error: %d / %s\n, errno,
strerror(errno));
}
return 1;
}
freeaddrinfo(result);
return 0;
}
===
The output is as follows, which seems wrong in itself to me.
===
error in getaddrinfo: -11 / System error
system error: 0 / Success
===
Now the thing is, when I replace the service string http with NULL,
it works perfectly. But ftp.de.debian.org:http for instance is what
aptitude wants to query and it fails which makes my system
un-upgradable at the moment.
Thanks for your time,
Hagen.
--
Hagen Möbius
Lychener Str. 81, 10437 Berlin, Germany
Home: +49 30 4450091
Cell: +49 179 5853897
Mail: hagen.moeb...@googlemail.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555738: Could mod_wsgi be added to the nginx package?
Package: nginx Version: 0.6.32-3+lenny3 Severity: wishlist Hi I would ask for the nginx to be patched and compiled with mod_wsgi from http://hg.mperillo.ath.cx/nginx/mod_wsgi/ Would that be possible? -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages nginx depends on: ii libc6 2.7-18GNU C Library: Shared libraries ii libpcre3 7.6-2.1 Perl 5 Compatible Regular Expressi ii libssl0.9.80.9.8g-15+lenny5 SSL shared libraries ii python2.5 2.5.2-15 An interactive high-level object-o ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime nginx recommends no packages. nginx suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#369662: fortunes: typo in Brandeis quote: fortune -m 'mean of zeal'
There seems to be a duplication as well: cd /usr/share/games/fortunes $ grep encroachment * cookie:The greatest dangers to liberty lurk in insidious encroachment by mean of zeal, cookie.u8:The greatest dangers to liberty lurk in insidious encroachment by mean of zeal, politics:The greatest dangers to liberty lurk in insidious encroachment by men politics.u8:The greatest dangers to liberty lurk in insidious encroachment by men So, `politics` contains the right, `cookie` the wrong quote. Who would've guessed? fortunes 1:1.99.1-3.1 Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529870: linux-image-2.6.26-2-686: I can confirm the bug also exists in 2.6.26-2-686
Package: linux-image-2.6.26-2-686 Followup-For: Bug #529870 After upgrade to 2.6.26-2-686 the kernel panics when selinux is enabled -- Package-specific info: -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-2-686 depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii initramfs-tools [linux-initra 0.92o tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.26-2-686 recommends: ii libc6-i6862.7-18 GNU C Library: Shared libraries [i Versions of packages linux-image-2.6.26-2-686 suggests: ii grub 0.97-47lenny2 GRand Unified Bootloader (Legacy v pn linux-doc-2.6.26 none(no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516762: Acknowledgement (madwifi-source: I get a lot of wifi0: ath_fatal_tasklet: Hardware error; resetting)
Debian == Debian Bug Tracking System ow...@bugs.debian.org writes: Hi. It seems it is a known problem with some atheros cards and madwifi in AP mode (http://madwifi-project.org/wiki/StuckBeacon) Yesterday I did the: iwpriv ath0 bgscan 0 iwpriv ath0 protmode 0 iwpriv ath0 rssi11a 11 iwpriv ath0 rssi11b 11 iwpriv ath0 rssi11g 11 iwpriv ath0 bintval 500 sysctl -w dev.wifi0.diversity=0 sysctl -w dev.wifi0.txantenna=1 sysctl -w dev.wifi0.rxantenna=1 (the last three I already used because I am only using one antenna) And I haven't seen this problem since(that is actually using madwifi trunk, but I got the same errors as the version in lenny and they disappeared using the iwpriv commands) The bug can be closed I guess Regards Hasse H. Johansen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516762: madwifi-source: I get a lot of wifi0: ath_fatal_tasklet: Hardware error; resetting
Package: madwifi-source Version: 1:0.9.4+r3772.20080716-1 Severity: important Hi After upgrading to lenny and building the madwifi module with module-assistant I see a lot of these in my kernel.log wifi0: ath_fatal_tasklet: Hardware error; resetting And my wifi has also become unstable. This has worked for years before upgrading to lenny so I don't believe i've got a hardware problem. The card is place in a Soekris net 4801 machine and exact hardware model from lspci is: Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01) And I don't believe the ath5k in lenny can work as accesspoint? -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i586) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages madwifi-source depends on: ii bzip2 1.0.5-1high-quality block-sorting file co ii debhelper 7.0.15 helper programs for debian/rules ii module-assistant 0.10.11.0 tool to make module package creati madwifi-source recommends no packages. Versions of packages madwifi-source suggests: pn kernel-pac none(no description available) ii madwifi-to 1:0.9.4+r3685.20080531+dfsg-1 tools for the Multiband Atheros Dr -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516653: nagios3-common: Preremoval script: syntax error
Package: nagios3-common Version: 3.0.6-3 Severity: normal Trying to purge nagios3 from my system, I encountered this message: Removing nagios3-common ... /var/lib/dpkg/info/nagios3-common.prerm: line 23: syntax error near unexpected token `fi' dpkg: error processing nagios3-common (--remove): subprocess pre-removal script returned error exit status 2 Simple enough, the line in question (in 'nagios3-common.prerm') is syntactically wrong. I attached a unified diff fixing the problem. -- System Information: Debian Release: 5.0 Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) Shell: /bin/sh linked to /bin/bash --- nagios3-common.prerm.old2009-02-22 23:22:24.0 +0100 +++ nagios3-common.prerm2009-02-22 21:32:57.0 +0100 @@ -4,7 +4,7 @@ apacheconf=/etc/nagios3/apache2.conf -if [ -f $apacheconf ] +if [ -f $apacheconf ]; then case $1 in remove) # find the configured servers
Bug#508644: general: installing mdadm pulls in citadel-server as depedency
Eugene == Eugene V Lyubimkin jackyf.de...@gmail.com writes: Eugene Hasse Hagen Johansen wrote: I think it would be better to ask which package to use for a virtual if it is installed interactively. In my case actually didn't want exim4 neither citadel - not for a mailserver. In most cases I think ssmtp or nullmailer is more appropiate, but that is another discussion :-) Eugene Actually, apt-get is more often used as non-interactive Eugene package manager, so I would not add interactive asker to Eugene it. Aptitude, however, has all chances and opportunities to Eugene implement it. Yes, but even though when using apt-get you are asked debconf questions for various packages? If just a sane(and by sane I mean use the debian default in this situation exim4) default is used when used non-interactively I can only see that it will help. For mail-transfer-agent it depends very much of the kind of system you would end up with, which of the packages which provides mail-transfer-agent you would use But I am perfectly fine that it works as it works now. I just didn't think it was fine when mdadm pulled in citadel-server :-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508644: general: installing mdadm pulls in citadel-server as depedency
Package: general Severity: important Hi Looking around for why citadel-server was pulled in instead of exim4 (which I believe is still the default MTA in debian). I saw the bug #474999 I just would let you know that maybe it is a more general problem as mdadm is also pulling citadel-server in as a dependency I still believe it should have been exim4? -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508644: general: installing mdadm pulls in citadel-server as depedency
Daniel == Daniel Baumann dan...@debian.org writes: Daniel Hasse Hagen Johansen wrote: I just would let you know that maybe it is a more general problem as mdadm is also pulling citadel-server in as a dependency Daniel this really sucks (in this case only if you have recommends Daniel enabled, though). someone should check all depends and Daniel recommends in debian to not declare unconditional relations Daniel to mail-transfer-agent. Yes. Actually like the virtual packages work right now it probably ok to just take one of the packages satisfying the mail-transfer-agent. But right now I don't quite understand how apt-get/aptitude would pick the mail-transfer-agent to use? is it first hit of a package with Provides mail-transfer-agent? in some package cache or something? Maybe apt-get/aptitude could just asks the user when they find that multiple packages Provides the dependency? I know that would not work non-interactively, but that could be solved with maybe having some file a standard place telling apt-get/aptitude which are the official debian standard package for a Virtual package and install that? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508644: general: installing mdadm pulls in citadel-server as depedency
Daniel == Daniel Baumann dan...@debian.org writes: Maybe apt-get/aptitude could just asks the user when they find that multiple packages Provides the dependency? Daniel package maintainers should just fix their packages... I know that would not work non-interactively, but that could be solved with maybe having some file a standard place telling apt-get/aptitude which are the official debian standard package for a Virtual package and install that? Daniel ...by using 'exim4 | mail-transport-agent' instead of Daniel 'mail-transport-agent'. Ok. I understand that Daniel iirc some time ago, someone wanted to add another layer Daniel (default-mail-transport-agent) so that all packages would be Daniel factually defaulting to install the same package to fulfil Daniel the mail-transport-agent relation when being installed first Daniel time, but that got somehow lost. I think it would be better to ask which package to use for a virtual if it is installed interactively. In my case actually didn't want exim4 neither citadel - not for a mailserver. In most cases I think ssmtp or nullmailer is more appropiate, but that is another discussion :-) Thanks for taking the time explaining to me how it works. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497928: rsnapshot uses the lchown perl module
You just made my day. I'm halfway into the new one already? Nevermind, you made that, too. Thanks, Hagen signature.asc Description: Digital signature
Bug#501738: iwatch: Wrong email address in XML file
Package: iwatch Version: 0.2.1-2 Severity: minor In /etc/iwatch/iwatch.xml the guard email entry is [EMAIL PROTECTED] This should probably be [EMAIL PROTECTED] For reference, the whole entry (I'm too tired to diff properly, it's trivial anyway): config guard email=[EMAIL PROTECTED] name=IWatch/ watchlist -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501520: flashcards: fails with Package geometry Error; even on the example page
Package: texlive-latex-extra Version: 2007.dfsg.4-1 Severity: normal The 'flashcards' package, residing in /usr/share/texmf-texlive/tex/latex/flashcards/, does not properly built the example flash card document 'samplecards.tex' http://www.tug.org/texlive/Contents/live/texmf-dist/doc/latex/flashcards/samplecards.tex and fails with ! Package geometry Error: You must set \paperwidth properly. This seems to be a known problem and has already been described: http://www.feferraz.net/en/flashcards.html (see section 'Problems'). A diff is also provided. I already tried the unstable version; same result. Thanks, Hagen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499465: rsnapshot: Does not get executed by anacron as its cron-file resides in cron.d
Package: rsnapshot Version: 1.2.9-1 Severity: important As the cron-file for rsnapshot is in cron.d/, systems which rely on anacron for execution of cron-jobs may not be doing backups as expected! Anacron does *not* execute jobs in cron.d/. I suggest splitting the rsnapshot cron-files into cron.daily/, cron.weekly/ and cron.monthly/ files. And yes, I think it is a PITA to repeat oneself like that, but for the sake of Desktop users that rely on anacron (and rsnapshot!), it seems to be the right thing to do. Thanks, Hagen -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497928: rsnapshot: The lchown Perl-module is not available in Debian-ized form
Package: rsnapshot Version: 1.2.9-1 Severity: normal rsnapshot produces warnings like this WARNING: Could not lchown() symlink when the Perl Lchwon.pm-module is not installed. It is, however, not possible to install this package in a clean, Debian-ized way, as this module (file) is nowhere to be found in Debian's official repos. The rsnapshot downloads-page http://www.rsnapshot.org/downloads.html gives another page http://permalink.gmane.org/gmane.comp.sysutils.backup.rsnapshot.general/1565 which allegedly provides a way to get sarge-packages. However, one of the hosts that have to be added to the 'sources.list' is not available. The only option left, which I would like to circumvent, is to run Perl to fetch it from CPAN. Thanks, Hagen -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496450: ncmpc: Jumping to song dir from search (F5) not possible
After a substantial amount of hacking, I think I have actually succeded in implementing this function. I would not consider my changes to be hacks, although I had my quarrels with the design (which I find quite pleasing now). Anyway, my patch makes it possible to press 'g' (goto) on an search results entry in order to browse the corresponding mpd-directory (in which the song is listed). I dont't know if this is a desireable feature, so either * close the ticket, as I'm satisfied or * notify upstream (or should I do that? - I'm not sure what the protocol suggests ;) So long, Hagen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496450: ncmpc: Jumping to song dir from search (F5) not possible
I'm not sure I did understand you correctly. What do you mean by entering some album? Do you mean something like add the corresponding album to the playlist? That would be a consequence of the feature I'm interested in: Enter the browse-screen (3) from one of the entries of the search-screen (5) by hitting a particular key (eg. 'g' for 'goto'). I've played around with the code, but due to the very C-ish structure, I was unable to find a way to tell the browse-screen to open up in a certain directory, without major intrusion. Regards, HF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496450: ncmpc: Jumping to song dir from search (F5) not possible
Package: ncmpc Version: 0.11.1+svn-r3965-2 Severity: wishlist It would be very logical to implement a way to enter the album that corresponds to one of the resulting entries in a search list; á la: I'd really like to hear that album where 'foo' sang 'bar'! Thanks, HF -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495219: freetalk: Hangs on start-up, works fine after pressing CTRL-C once.
can you please tell me, which aspell dictionary you are using? may be if it is too big, freetalk is not handling it.. Sorry, I tried different word-lists (wngerman was the one with 300.000+ entries) - english, british and even cleared the wordlist once: Loading dictionary [/usr/share/dict/words]... [0] words Also, I tried de-installing aspell and installing the most recent version - the problem persists: An indefinitely long hang on start-up. Thanks, Hagen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495219: freetalk: Hangs on start-up, works fine after pressing CTRL-C once.
Package: freetalk Version: 0.5-2 Severity: normal After invoking freetalk 0.5, I need to press CTRL-C after waiting one moment: $ freetalk [ 1 sec ] CTRL-C Loading dictionary [/usr/share/dict/words]... [320577] words and normal operation begins. This even happens, when I remove my '.freetalk'-folder: $ mv .freetalk/ freesomething $ freetalk Welcome to freetalk! Running for the first time? Performing some one-time initializations ... [ waiting ... ] CTRL-C Loading dictionary [/usr/share/dict/words]... [320577] words and everything goes smoothly from here. -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495219: freetalk: Hangs on start-up, works fine after pressing CTRL-C once.
Hi, Try latest version from Lenny or even more latest version from Sid. I have never seen such issues before with freetalk. Already tried that - sorry to say: same outcome. I can wait infinitely long (so it seems) after invoking freetalk. Then I Ctrl-C and all is well. Is there some way to get debug-output from freetalk - without wading into Guile-waters, preferably? Or perhaps one of the libraries (readline?) blocks? What is it supposed to be doing at the stage before this one: Loading dictionary [/usr/share/dict/words]... - Library versions (aptitude output): --\ guile-1.6 i A 1.6.8-6 --\ guile-1.6-libs i A 1.6.8-6 --\ libc6 (= 2.3.5-1) i A 2.7-13 --\ libglib2.0-0 (= 2.8.5) i A 2.16.4-2 --\ libloudmouth1-0 (= 1.0.1) i A 1.4.0-1 --\ libncurses5 (= 5.4-5) i A 5.6+20080713-1 --\ libreadline5 (= 5.1) p A 5.2-3 - So long, Hagen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#269336: the better satisfaction she has.
If you are searching for reliable chemists. You wont find better range of goods than our site. We have everything to help to get rid of ilnesses.Even if you need fast delivery at your door you can always trust us. Obtain the most experienced help as fast as a mouse click. levelwisdom.com 20 Jul 2008 13:26:47 sinima fire -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448700: [Dev-luatex] luatex loading old hyphenation patterns
Norbert Preining wrote: Hi Taco, hi all, I am trying to activate the latex based fromats of luatex in the Debian packages, but stumbled over problematic hyphenation patterns. Currently, luatex dies on tex/generic/ukrhyph/ukrhypmp.tex as shipped with TL2007, it contains Ukrainian hyphenation patterns in LCY (cp866nav) encoding. I guess that one cannot do anything here but wait for TL2008 with the new utf8 patterns to hit Debian. Right? indeed, only utf8 Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
