Bug#1017739: emacs-lucid cannot start after upgrade
On Mon Aug 22, 2022 at 14:53:57 -0700, Russ Allbery wrote: > Control: severity -1 important > > Adam Lackorzynski writes: > > > I had the same issue. Turned out my personal .emacs.d/eln-cache > > directory and its folders belonged to root: > > > $ ls -la $HOME/.emacs.d/eln-cache > > total 16 > > drwxr-xr-x 4 root root 4096 Aug 21 19:32 . > > drwx-- 4 adam users 4096 Aug 19 19:43 .. > > drwxr-xr-x 2 root root 4096 Aug 21 19:32 28.1-20961986 > > drwxr-xr-x 2 root root 4096 Aug 19 19:43 28.1-aa5da5cc > > > chown'ing it to me fixed it. > > Oh, good catch! The same thing was true of mine. > > I think the dates were when I upgraded Emacs. Let me take a guess: are > you also old-school and use su from a regular user account when installing > new packages? HOME gets overridden by su, but LOGNAME and USER do not, > and I suspect something in Emacs is deciding where to write files based on > USER, and the installation process of emacs-lucid creates the eln-cache > directory for some reason. Indeed, yes. I'd follow the lines here that a Debian package should ensure that content generated for global use (which I assume the package positinst is generating) shall be in a location accessible for everyone. > I'm downgrading the severity of this bug because I suspect the average > user using sudo may not run into it (although the maintainer should feel > free to raise the severity again if they disagree). If I'm right, the > best place to solve the problem may be in the Debian maintainer scripts, > overwriting USER (and possibly LOGNAME, not sure if it matters) to some > safe value like root while performing the installation. This may also be > necessary to do when installing Emacs add-on packges; I'm not sure. > > I've removed the directory with the wrong ownership and upgraded again > with USER and LOGNAME set to root, and now everything works fine. (Well, > my laptop gets extremely hot the first time I start the new Emacs, but I > assume that's expected for the new compilation system.) > > -- > Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> Adam
Bug#1017739: emacs-lucid cannot start after upgrade
On Fri Aug 19, 2022 at 11:42:30 -0700, Russ Allbery wrote: > Package: emacs-lucid > Version: 1:28.1+1-1 > Severity: grave > X-Debbugs-Cc: r...@debian.org > > The 28.1 version of emacs-lucid fails on startup with a cryptic error > message: > > % emacs > Cannot find suitable directory for output in ‘comp-native-load-path’. I had the same issue. Turned out my personal .emacs.d/eln-cache directory and its folders belonged to root: $ ls -la $HOME/.emacs.d/eln-cache total 16 drwxr-xr-x 4 root root 4096 Aug 21 19:32 . drwx-- 4 adam users 4096 Aug 19 19:43 .. drwxr-xr-x 2 root root 4096 Aug 21 19:32 28.1-20961986 drwxr-xr-x 2 root root 4096 Aug 19 19:43 28.1-aa5da5cc chown'ing it to me fixed it. Thanks, Adam
Bug#1003930: qemu: Please include multiboot_dma.bin
Source: qemu
Version: 1:6.2+dfsg-1
Severity: normal
Hi,
QEMU 6.2 ships with a new multiboot blob, please include it as it is used by
default when launching a multiboot-capable guest:
Could not open option rom 'multiboot_dma.bin': No such file or directory
--- optionrom.mak.old 2022-01-17 23:08:52.891445869 +0100
+++ optionrom.mak 2022-01-17 23:09:49.055305128 +0100
@@ -6,7 +6,8 @@
-I${SRC_PATH}/include
VPATH = ${SRC_PATH}/pc-bios/optionrom
-BINS = kvmvapic.bin linuxboot.bin linuxboot_dma.bin multiboot.bin pvh.bin
+BINS = kvmvapic.bin linuxboot.bin linuxboot_dma.bin \
+ multiboot.bin multiboot_dma.bin pvh.bin
all: ${BINS}
%.o: %.S
Thanks, Adam
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.15.0-2-amd64 (SMP w/96 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#989735: minicom: stack smashing when searching in history buffer
On Mon Jun 14, 2021 at 10:19:13 +0100, Mike Crowe wrote: > Hi Adam, > > On Monday 14 June 2021 at 09:16:51 +0200, Adam Lackorzynski wrote: > > Ok, thanks. Meantime I changed all of this static memory handling to be > > more dynamic, also addressing this case I believe. The 'magic' constant > > is gone, so hopefully any of those cases. > > Thanks for the extremely quick fixes. The current state of master > (b7727586547b4a24939bef4176b8a0d5ad91d62d) seems to work perfectly for me. > > Since this didn't turn out to be a regression, is it safe to assume that > there's little chance of the fix ending up in Bullseye? Let's see. I've put all on the v2.8.x branch, being corruption fixes. Maybe it still works out if an upload is being done timely. ;) Adam
Bug#989735: minicom: stack smashing when searching in history buffer
Hi Mike, On Mon Jun 14, 2021 at 08:12:18 +0100, Mike Crowe wrote: > On Sunday 13 June 2021 at 21:22:32 +0200, Adam Lackorzynski wrote: > > thanks again. I wonder why it did not reproduce for me earlier. > > Could you try attached patch and report back? > > Hi Adam, > > Thanks for the patch. It did seem better. However, when I do a > case-insensitive search I now get: Ok, thanks. Meantime I changed all of this static memory handling to be more dynamic, also addressing this case I believe. The 'magic' constant is gone, so hopefully any of those cases. Adam
Bug#989735: minicom: stack smashing when searching in history buffer
Hi Mike,
thanks again. I wonder why it did not reproduce for me earlier.
Could you try attached patch and report back?
Thanks, Adam
On Sun Jun 13, 2021 at 17:16:36 +0100, Mike Crowe wrote:
> Hi Adam,
>
> Thanks for the speedy response.
>
> On Sunday 13 June 2021 at 17:25:20 +0200, Adam Lackorzynski wrote:
> > Hi,
> >
> > thanks for the report. The issue has always been there and had to do
> > with the width of minicom's window (over 256 columns). I have addressed
> > this.
>
> Aha. I switched font at a similar time to upgrading to Bullseye and hadn't
> realised that this meant that my window was no so wide!
>
> > Martin, I have pushed this on the 2.8.x branch (8deebed). Please
> > pick both changes there for the next upload.
>
> I tried compiling master (f118eb9efe89672e5c2a75b34960813db493b2ed) with
> your fix and -fsanitize=address. It looks like the original problem no
> longer occurs, but now when I follow the original steps I get:
>
> =
> ==56567==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x557fff340c20 at pc 0x557fff2f550b bp 0x7ffe7d9321e0 sp 0x7ffe7d9321d8
> READ of size 4 at 0x557fff340c20 thread T0
> #0 0x557fff2f550a in mc_wdrawelm_var ../../src/window.c:1059
> #1 0x557fff2d45dc in find_next ../../src/minicom.c:338
> #2 0x557fff2d04c1 in scrollback ../../src/minicom.c:540
> #3 0x557fff2d04c1 in main ../../src/minicom.c:1707
> #4 0x7f88fb12cd09 in __libc_start_main ../csu/libc-start.c:308
> #5 0x557fff2d3059 in _start
> (/overflow/mac/nobackup/git/minicom/build/src/minicom+0x25059)
>
> 0x557fff340c20 is located 32 bytes to the left of global variable
> 'iconv_enabled' defined in '../../src/minicom.c:937:12' (0x557fff340c40) of
> size 4
> 0x557fff340c20 is located 0 bytes to the right of global variable
> 'outofrange' defined in '../../src/minicom.c:177:14' (0x557fff340420) of size
> 2048
> SUMMARY: AddressSanitizer: global-buffer-overflow ../../src/window.c:1059 in
> mc_wdrawelm_var
> Shadow bytes around the buggy address:
> 0x0ab07fe60130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0ab07fe60140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0ab07fe60150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0ab07fe60160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0ab07fe60170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0ab07fe60180: 00 00 00 00[f9]f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
> 0x0ab07fe60190: 00 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
> 0x0ab07fe601a0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
> 0x0ab07fe601b0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
> 0x0ab07fe601c0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
> 0x0ab07fe601d0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
> Shadow byte legend (one shadow byte represents 8 application bytes):
> Addressable: 00
> Partially addressable: 01 02 03 04 05 06 07
> Heap left redzone: fa
> Freed heap region: fd
> Stack left redzone: f1
> Stack mid redzone: f2
> Stack right redzone: f3
> Stack after return: f5
> Stack use after scope: f8
> Global redzone: f9
> Global init order: f6
> Poisoned by user:f7
> Container overflow: fc
> Array cookie:ac
> Intra object redzone:bb
> ASan internal: fe
> Left alloca redzone: ca
> Right alloca redzone:cb
> Shadow gap: cc
> ==56567==ABORTING
>
> I hope this is meaningful to you. If not, I'll see if I can work out
> anything more.
>
> Thanks.
>
> Mike.
Adam
--
Adam a...@os.inf.tu-dresden.de
Lackorzynski http://os.inf.tu-dresden.de/~adam/
From b6043854f1e762801347ed4bf4d368b49ad99217 Mon Sep 17 00:00:00 2001
From: Adam Lackorzynski
Date: Sun, 13 Jun 2021 21:10:59 +0200
Subject: [PATCH] Make mc_getline immune to MAXCOLS
---
src/minicom.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/src/minicom.c b/src/minicom.c
index 2719f8c..06dd7be 100644
--- a/src/minicom.c
+++ b/src/minicom.c
@@ -174,7 +174,6 @@ static void shjump(int sig)
static ELM *mc_getline(WIN *w, int no)
{
int i;
- static ELM outofrange[MAXCOLS] = {{0,0,0}};
if (no < us->histlines) {
/* Get a line from the history buffer. */
@@ -189,13 +188,20 @@ static ELM *mc_getline(WIN *w, int no)
/* Get a line from the "us" window. */
no -= us->histlines;
if (no >= w->ys) {
-if (outofrange[0].value == 0) {
- for (i = 0; i < MAXCOLS; i++) {
-outofrange[i].value = ' ';
-outofran
Bug#989735: minicom: stack smashing when searching in history buffer
Hi, thanks for the report. The issue has always been there and had to do with the width of minicom's window (over 256 columns). I have addressed this. Martin, I have pushed this on the 2.8.x branch (8deebed). Please pick both changes there for the next upload. Thanks, Adam On Fri Jun 11, 2021 at 15:29:55 +0100, Mike Crowe wrote: > Package: minicom > Version: 2.8-1 > Severity: important > > Steps to reproduce: > > 1. Start Minicom connected to a serial port with MINICOM="-m -c on -8" > (although I was also able to reproduce the problem with MINICOM="" if the > keystrokes below are changed appropriately.) > > 2. Cause whatever is connected to emit more than a screenful of text. >(Without this, Minicom won't let you enter history mode.) > > 3. Press Alt-B to enter history mode. Press / to search, type something >short that doesn't exist in the history and press Enter. > > Expected result: > > Minicom searches for the specified text in the buffer as it always did > successfully in the Buster version of Minicom. > > Actual result: > > *** stack smashing detected ***: terminated > > and Minicom exits. > > I tried compiling Minicom from the Debian package source with CC="gcc > -fsanitize=address" and got: > > = > ==3332560==ERROR: AddressSanitizer: stack-buffer-overflow on address > 0x7ffc81d544e0 at pc 0x556347a102d8 bp 0x7ffc81d54080 sp 0x7ffc81d54078 > WRITE of size 4 at 0x7ffc81d544e0 thread T0 > #0 0x556347a102d7 in mc_wdrawelm_var ../../src/window.c:1055 > #1 0x5563479efb65 in find_next ../../src/minicom.c:336 > #2 0x5563479ec687 in scrollback ../../src/minicom.c:533 > #3 0x5563479ec687 in main ../../src/minicom.c:1646 > #4 0x7f0b62d83d09 in __libc_start_main ../csu/libc-start.c:308 > #5 0x5563479ee6c9 in _start > (/overflow/mac/Debian/minicom-2.8/build/src/minicom+0x236c9) > > Address 0x7ffc81d544e0 is located in stack of thread T0 at offset 1056 in > frame > #0 0x5563479efa0f in find_next ../../src/minicom.c:309 > > This frame has 1 object(s): > [32, 1056) 'tmp_line' (line 312) <== Memory access at offset 1056 > overflows this variable > HINT: this may be a false positive if your program uses some custom stack > unwind mechanism, swapcontext or vfork > (longjmp and C++ exceptions *are* supported) > SUMMARY: AddressSanitizer: stack-buffer-overflow ../../src/window.c:1055 in > mc_wdrawelm_var > Shadow bytes around the buggy address: > 0x1000103a2840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x1000103a2850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x1000103a2860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x1000103a2870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x1000103a2880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > =>0x1000103a2890: 00 00 00 00 00 00 00 00 00 00 00 00[f3]f3 f3 f3 > 0x1000103a28a0: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 > 0x1000103a28b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x1000103a28c0: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 > 0x1000103a28d0: 00 f2 00 00 00 f2 f2 f2 00 00 f2 f2 f8 f8 f8 f2 > 0x1000103a28e0: f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2 f2 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user:f7 > Container overflow: fc > Array cookie:ac > Intra object redzone:bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone:cb > Shadow gap: cc > ==3332560==ABORTING > > find_next has: > wchar_t tmp_line[MAXCOLS]; > > According to gdb inside mc_wdrawelm_var: > > (gdb) p w->x1 > $5 = 0 > (gdb) p w->x2 > $6 = 263 > > (other useful stuff like "c" was optimised out.) > > If I add: > > if (c >= MAXCOLS) > abort(); > > inside the loop in mc_wdrawelm_var then the process aborts as would be > expected rather than the sanitizer complaining. > > -- System Information: > Debian Release: 11.0 > APT prefers testing-security > APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, > 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.10.0-6-amd64 (SMP w/32 CPU threads) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB:en > Shell: /bin/sh linked to /bin/bash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages minicom depends on: > ii libc6 2.31-12 > ii libtinfo6 6.2+20201114-2 > > Versions of packages minicom recommends: > ii
Bug#979422: Sv: Bug#979422: Acknowledgement (minicom does not consider port busy if lockfile isn't readable (existence isn't enough))
Hi Björn, On Fri Jan 29, 2021 at 09:35:45 +, Björn Wiberg wrote: > Hello Adam! > > Thank you for your reply! > > On Sun, 24 Jan 2021 20:44:23 +0100 Adam Lackorzynski > wrote: > > I improved the handling in minicom upstream to consider this case. > > Thanks a lot! > > > Still, minicom creates the lockfile such that it is readable by > > everyone. In your case, has the lockfile been created by minicom or > > someone else? > > The lockfile was created by another software (socat). > > It (socat) appears to have problems both with the format (reported separately > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979445), and, as noted, > with the permissions (reported separately in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979506). Ah, this explains it then. Thanks for letting us know! Adam
Bug#979422: Proposed step-by-step logic
Hi, I improved the handling in minicom upstream to consider this case. Still, minicom creates the lockfile such that it is readable by everyone. In your case, has the lockfile been created by minicom or someone else? Adam
Bug#869753: minicom: -R UTF-8 passed in environment variable ignored
Hi, On Wed Jul 26, 2017 at 08:24:48 +0200, Heinrich Schuchardt wrote: > calling > minicom -R UTF8 > displays utf-8 characters in the accessed utf-8 system correctly. > > Environment variable > export MINICOM="-R UTF8" > does not have this effect. Utf-8 characters are output as two (or more) > characters. > > Plese, support -R in the environment variable as is already the case for -c. I think I've identified and fixed the issue (in upstream). Martin, would you like to pick d3e201383e46? Adam
Bug#821936: [i18n] minicom does not live well with multicol characters
Hi Mingye, sorry it took so long but I changed the internal handling of those strings and it should work better now. Could you give me your updated translation file so I could try it? Or you can try yourself. However, the change is still in minicom's hg repository. Get it with hg clone https://alioth.debian.org/anonscm/hg/minicom/ Thanks, Adam On Tue Apr 26, 2016 at 20:45:09 -0400, Mingye Wang (Arthur2e5) wrote: > On 4/26/2016 18:23, Adam Lackorzynski wrote: > > Hi, > > > > thanks for letting me know of those issues! > Thanks for responding to my report :) > > It seems that you have CC'ed your message to Debian BTS submission > instead of Debbugs#822490. Assuming that's done by mistake, I am quoting > all your message and CC'ing it back to the bug so your reply will be > visible on the bug info page for others. > > > > > On Wed Apr 20, 2016 at 12:04:37 -0400, Mingye Wang (Arthur2e5) wrote: > >> Package: minicom > >> Version: 2.7-1 > >> > >> // omitted > >> > >> wcswidth(wchar_t *) may be a better solution, but you may want to add > >> some comments to ask translations not to use tabs (which screws up > >> things in the current implementation too.) Unprintable chars (including > >> ctrl chars like tab and newline) in wcswidth will cause it to return -1. > > > > Probably a wrapper for wcswidth() will do here that counts unprintable > > characters as 1 char/column (and just ignoring the speciality of TAB). > wcswidth(wchar_t*, size_t) is essentially finding the sum of the return > values of wcwidth(wchar_t) for all the wchars in the range (, and > returning -1 when wcwidth gives -1). Hence you will actually end up > doing a wcwidth(wchar_t) wrapper. > > > > >> // omitted > >> > >> The windows x/y knowledge is also crippled here. For single-char width > >> info, use wcwidth(wchar_t). Like wcswidth, it returns -1 for unprintable > >> chars. > > > > Yes, needs to be fixed. > > > >> Note that emoji suport in glibc wcwidth() comes with Unicode 7.0 support > >> in glibc, which is in glibc 2.22. Some extra even newer emojis require > >> Unicode 8.0 (glibc 2.23). > > > > Ok, good to know, thanks. > > > > Adam > > > > -- > Regards, > > Arthur2e5
Bug#821936: [i18n] minicom does not live well with multicol characters
Hi,
thanks for letting me know of those issues!
On Wed Apr 20, 2016 at 12:04:37 -0400, Mingye Wang (Arthur2e5) wrote:
> Package: minicom
> Version: 2.7-1
>
> A few months ago I was doing some minicom zh_CN l10n on
> TranslationProject.org. Since the work is has been assigned to someone
> else, I was not able to submit the done files. Interestingly, the
> coordinator of the zh_CN language actually presented me with an extra
> reason why they are not accepting strings (even if someone else has done
> that years ago) -- translating minicom makes the UI a mess [1].
> [1]: https://groups.google.com/d/topic/i18n-zh/X-FCRHzWuYc/discussion
>
> multi-column scripts like CJK and emoji takes up multiple terminal
> columns for each character. (For the two specifically, well, two cols.)
> However, these segments in minicom appears to be ignoring all such
> characters:
>
> config.c:
> > static void dologopt(void)
> > {
> > /* ... */
> > while(1) {
> > mc_wlocate(w, mbslen(question) + 5, 5);
>
> This mc_wlocate call assumes that mbslen(str) is the colomn width of
> str. However, due to the reasons mentions above, CJK strings like "要修
> 改哪个选项？" will end up giving a cursor stuck in the middle.
>
> wcswidth(wchar_t *) may be a better solution, but you may want to add
> some comments to ask translations not to use tabs (which screws up
> things in the current implementation too.) Unprintable chars (including
> ctrl chars like tab and newline) in wcswidth will cause it to return -1.
Probably a wrapper for wcswidth() will do here that counts unprintable
characters as 1 char/column (and just ignoring the speciality of TAB).
> window.c:
> > void mc_wputc(WIN *win, wchar_t c)
> > {
> > /* ... */
> > if (win->cury == win->sy2 - win->y1 + 1)
>
> The windows x/y knowledge is also crippled here. For single-char width
> info, use wcwidth(wchar_t). Like wcswidth, it returns -1 for unprintable
> chars.
Yes, needs to be fixed.
> Note that emoji suport in glibc wcwidth() comes with Unicode 7.0 support
> in glibc, which is in glibc 2.22. Some extra even newer emojis require
> Unicode 8.0 (glibc 2.23).
Ok, good to know, thanks.
Adam
Bug#477810: minicom and utf8 does weired things
Hi, On Mon Apr 11, 2016 at 23:11:24 +0200, Luca Corbatto wrote: > I can confirm that minicom (still) has problems with utf-8. > I opened minicom in the gnome-terminal. > > I implemented a small console program on an ATMega1284p that simply sends > the exact same > bytes it recieves back. I am using a TTL2USB-UART adaptor. Whenever I try to > send any character > multibyte character it shows up weiredly. For any n-long character it shows > n-1 times the > character � followed by the actual character. E. g. I send the character ' > ' and this shows up: "���". > However, when I start minicom in hex-mode (using -H) the character '' shows > up as "f0 9f 98 ad" > which is the correct utf-8 value of that character. This and the fact that > this setup works perfectly > fine with dterm, brings me to the conclusion that minicom has some problem > with outputting utf-8 > characters. I think you need to add the option "-R utf8" to minicom so that minicom knows that the remote side is sending using UTF8. Without it doing a simple character pass-through (both sides on utf8) seems to have some glitches, which you're seeing. Adam
Bug#707564: minicom: please show config or device name in status bar
On Thu May 09, 2013 at 15:03:26 +0200, Sascha Silbe wrote: I'm often using multiple minicom instances to work on multiple serial ports (connected both to different devices and to different ports of the same device) in parallel. Currently, it's hard to distinguish these instances as they all look exactly the same. It would be quite useful if minicom could display the name of the config or serial device in use in the status bar. Screen real estate is usually not an issue for me, but on systems where it is, the minicom version could be dropped. If showing the name of the serial device, it may need to be shortened (especially when using /dev/serial/by-path/...). When showing the config name, that's unlikely to be a problem (though not impossible). Starting minicom with -T will show the device name instead of the online time. I guess that's what you're looking for. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707564: minicom: please show config or device name in status bar
On Thu May 09, 2013 at 16:04:39 +0200, Sascha Silbe wrote: Adam Lackorzynski a...@os.inf.tu-dresden.de writes: Starting minicom with -T will show the device name instead of the online time. I guess that's what you're looking for. Thanks for the hint; I wouldn't have expected the option to have this effect, based on the description in the manual page (Disable the display of the online time in the status bar.). Perhaps a better phrasing would be Show device name instead of online status in the status bar. or Replace online status in status bar with device name.? I've fixed that. The option does almost what I need. Except that in the case I tested, it cut off the most interesting part of the device name: the last digit that indicates what port I'm on. The devices are named /dev/serial/by-name/ll8p1 through /dev/serial/by-name/ll8p8. minicom shows serial_by-name_ll8p for all of them. The terminal is 185 characters wide, so there's no reason for minicom to cut off the device name. And if there would be, it should probably be stripping off the head, not the tail, as in most cases the port number comes last (ttyUSBn, ttySn, serial/by-path/pci*usb*usb-id-portn, ...). Indeed, and I've changed that now with the hope the handling is better now. Also, is there a way to enable this through configuration, rather than setting up the environment (MINICOM)? No. Further I think the whole statusline must be done via some printf-line config, so this would be something to put into config. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594449: proftpd-basic: Unable to reload (signal HUP) - The process is killed
Hi, I was seeing the same issue on wheezy systems (x86 32 and 64 bit). proftpd process segfaults on SIGHUP. After tracing this a bit the segfault happens when processing restart events of the quotatab module. Thus disabling quota modules in the config makes reload/SIGHUP work again for me. HTH, Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698407: minicom: Cannot handle long device names
On Thu Jan 17, 2013 at 23:56:39 -0500, Mattthew Gabeler-Lee wrote: Package: minicom Version: 2.6.1-2 Severity: normal Apparently the maximum length of a device name for minicom is 80 chars. This does not play well at all with the udev symlinks in /dev/serial/by-id, which are very handy when you are working in an environment with multiple (esp USB) serial ports. Thanks for the report. I've 'fixed' that upstream. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697624: minicom: can't use /dev/serial/by-path/*usb* device names
Hi, On Mon Jan 07, 2013 at 19:23:14 +, Sascha Silbe wrote: Package: minicom Version: 2.6.1-1 Severity: normal Dear Maintainer, 123456789012345678901234567890123456789012345678901234567890123456789012 minicom cuts off the name of the serial device file at the first colon, so by-path persistent serial device names can't be used; at least not for USB serial adapters. I'm using several el-cheapo USB serial adapters that have no serial number on the same host, so the only way to distinguish them reliably is to identify them by the physical port of the USB hub they're plugged into, which is exactly what the /dev/serial/by-path/*usb* symlinks do. To reproduce: 1. Plug in a USB serial adapter 2. Check /dev/serial/by-path for the device name, e.g. /dev/serial/by-path/platform-orion-ehci.0-usb-0:1.1:1.0-port0 3. Create a new minicom configuration file: minicom -s P1 4. In Serial port setup, enter the device name from 2. in A - Serial Device. 5. Choose Exit (not Exit from Minicom) 6. The following error message will appear: minicom: cannot open /dev/serial/by-path/platform-orion-ehci.0-usb-0: No such file or directory As you can see, minicom cuts off the device name after the first colon. Shortening the path (for testing purposes) or adding a backslash for to escape the colon shows the same result. minicom(1) mentions space, comma and semicolon as special characters in the device name, but not colon. Thanks for the report. I have fixed this in upstream with the following patch. This changes old behaviour but I favor support for this kind of paths more than the old feature of path delimiters. --- a/src/util.cFri Dec 21 22:16:13 2012 +0100 +++ b/src/util.cWed Jan 09 23:14:03 2013 +0100 @@ -175,7 +175,7 @@ } /* - * Get next port from a space-, comma-, colon-, or semi-colon-separated + * Get next port from a space-, comma-, or semi-colon-separated * list (we're easy :-)) in a PARS_VAL_LEN length string. * * Returns NULL pointer on end-of-list. @@ -197,10 +197,10 @@ strncpy(loc_port_list, port_list, PARS_VAL_LEN); loc_port_list[PARS_VAL_LEN - 1] = 0; ep = loc_port_list[strlen(loc_port_list)]; -sp = strtok(loc_port_list, :;, ); +sp = strtok(loc_port_list, ;, ); } else if (*sp != 0) -sp = strtok(sp, :;, ); +sp = strtok(sp, ;, ); else sp = NULL; Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696504: varnish: Fails to start properly with 077 umask
Package: varnish Version: 3.0.2-2 Severity: normal Hi, starting varnish with umask set to 077 fails: $ /usr/sbin/varnishd -P /var/run/varnishd.pid -F -a :80 -T localhost:6082 ... child (2484) Started Pushing vcls failed: dlopen(./vcl.B6xCZlYB.so): ./vcl.B6xCZlYB.so: cannot open shared object file: Permission denied Stopping Child Child (2484) said Child starts Child (2484) said SMF.s0 mmap'ed 375809638400 bytes of 375809638400 Child (2484) said Child dies Child (2484) died status=1 Child cleanup complete Here varnish is started but does not listen to port 80. Same seems to happen when starting via init-script. Starting goes ok but it does not listen on port 80. With umask=022 it works. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660575: minicom sends `--' key as ascii BS, contrary to debian policy
Hi, On Sun Feb 19, 2012 at 15:31:20 -0800, Basil Nutmeg wrote: Minicom sends ASCII BS for the `--' key by default. This means that this key does not delete the character to the left of the cursor when minicom is connected to a policy-conforming remote system. What would be an example of such a remote system? Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659351: minicom: Minicom stops receiving in -R utf-8 mode
Hi, On Fri Feb 10, 2012 at 13:01:20 +, Mike Crowe wrote: Package: minicom Version: 2.4-3 Severity: normal LANG=en_GB.utf8 Minicom parameters -m -c on -8 -R utf-8 If minicom receives an invalid UTF-8 sequence from the serial port it doesn't display any more of the characters that have been sent. For example (borrowing from bug 413934) if the byte sequence f8 e2 82 ac c2 a3 0a is received then no further serial output is displayed. Steps to reproduce: Connect via serial to another Linux box and enter something like this at the shell: printf \xf8\xe2\x82\xac\xc2\xa3\nFoo bar baz; ls -lR / Notice that no more output is seen. Exiting from minicom and relaunching is required to see further serial input. Thanks for the test case, confirmed and fixed upstream, and included in new version 2.6.1. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639967: wmnet: Fix when values in /proc/net/dev are getting big
Package: wmnet
Version: 1.05-17
Severity: normal
Tags: patch
Hi,
this patch fixes wmnet to continue displaying when the numbers in
/proc/net/dev increase over 32bits.
diff -ur x/wmnet-1.05/drivers.c wmnet-1.05/drivers.c
--- x/wmnet-1.05/drivers.c 2011-09-01 09:24:15.526102621 +0200
+++ wmnet-1.05/drivers.c2011-09-01 09:24:02.585877953 +0200
@@ -60,8 +60,8 @@
extern char buffer[256];
extern char *in_rule_string, *out_rule_string, *device;
-extern unsigned long totalbytes_in, totalbytes_out, lastbytes_in,
lastbytes_out;
-extern unsigned long totalpackets_in, totalpackets_out, lastpackets_in,
lastpackets_out;
+extern unsigned long long totalbytes_in, totalbytes_out, lastbytes_in,
lastbytes_out;
+extern unsigned long long totalpackets_in, totalpackets_out, lastpackets_in,
lastpackets_out;
extern unsigned int diffpackets_in, diffpackets_out, diffbytes_in,
diffbytes_out;
extern unsigned int out_rule, in_rule; /* number of rule in /proc/net/ip_acct
to use */
extern Bool current_tx, current_rx, rx, tx;
@@ -197,7 +197,7 @@
flag |= ACCOUNT_IN_FOUND;
while(buffer[offset++] != ' ');
offset += 18;
- totalpackets_in = strtoul(buffer[offset],
ptr, 10);
+ totalpackets_in = strtoull(buffer[offset],
ptr, 10);
if (totalpackets_in == lastpackets_in) break;
totalbytes_in = strtoul(ptr, NULL, 10);
diffpackets_in += totalpackets_in -
lastpackets_in;
@@ -211,7 +211,7 @@
flag |= ACCOUNT_OUT_FOUND;
while(buffer[offset++] != ' ');
offset += 18;
- totalpackets_out = strtoul(buffer[offset],
ptr, 10);
+ totalpackets_out = strtoull(buffer[offset],
ptr, 10);
if (totalpackets_out == lastpackets_out) break;
totalbytes_out = strtoul(ptr, NULL, 10);
diffpackets_out += totalpackets_out -
lastpackets_out;
@@ -371,9 +371,9 @@
packets_in_str = bytes_in_str;
NEXTFIELD(packets_in_str);
- totalpackets_in = strtoul(packets_in_str, NULL, 10);
+ totalpackets_in = strtoull(packets_in_str, NULL, 10);
if (totalpackets_in != lastpackets_in) {
- totalbytes_in = strtoul(bytes_in_str, NULL, 10);
+ totalbytes_in = strtoull(bytes_in_str, NULL,
10);
diffpackets_in += totalpackets_in -
lastpackets_in;
diffbytes_in += totalbytes_in - lastbytes_in;
lastpackets_in = totalpackets_in;
@@ -391,9 +391,9 @@
packets_out_str = bytes_out_str;
NEXTFIELD(packets_out_str);
- totalpackets_out = strtoul(packets_out_str, NULL, 10);
+ totalpackets_out = strtoull(packets_out_str, NULL, 10);
if (totalpackets_out != lastpackets_out) {
- totalbytes_out = strtoul(bytes_out_str, NULL,
10);
+ totalbytes_out = strtoull(bytes_out_str, NULL,
10);
diffpackets_out += totalpackets_out -
lastpackets_out;
diffbytes_out += totalbytes_out - lastbytes_out;
lastpackets_out = totalpackets_out;
diff -ur x/wmnet-1.05/wmnet.h wmnet-1.05/wmnet.h
--- x/wmnet-1.05/wmnet.h2011-09-01 09:24:15.526102621 +0200
+++ wmnet-1.05/wmnet.h 2011-09-01 09:16:38.810068098 +0200
@@ -76,8 +76,8 @@
/* I know statically declared buffers are against GNU coding standards, so sue
me */
char buffer[256], *click_command = NULL, *label = NULL;
struct timeval timenow, timelast;
-unsigned long totalbytes_in, totalbytes_out, lastbytes_in, lastbytes_out;
-unsigned long totalpackets_in, totalpackets_out, lastpackets_in,
lastpackets_out;
+unsigned long long totalbytes_in, totalbytes_out, lastbytes_in, lastbytes_out;
+unsigned long long totalpackets_in, totalpackets_out, lastpackets_in,
lastpackets_out;
unsigned int diffpackets_in, diffpackets_out, diffbytes_in, diffbytes_out;
unsigned int delayTime = 25000, displayDelay = 55000, maxRate = 6000;
unsigned int out_rule = 2, in_rule = 1, graphbox_height = 44; /* number of
rule in /proc/net/ip_acct to use */
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Versions of packages wmnet depends on:
ii libc6
Bug#626379: libc6: Static binaries fail with __getpagesize: Assertion `_rtld_global_ro._dl_pagesize != 0'
Package: libc6
Version: 2.13-2
Severity: normal
Tags: sid
Hi,
static binaries that trigger loading of shared objects (libnss) fail
with the following assertion.
/tmp cat a.c
#include pty.h
#include stdlib.h
int main()
{
int a, b;
openpty(a, b, 0, 0, 0);
return (int)malloc(123);
}
/tmp gcc -static a.c -lutil
/tmp ./a.out
a.out: ../sysdeps/unix/sysv/linux/getpagesize.c:32: __getpagesize: Assertion
`_rtld_global_ro._dl_pagesize != 0' failed.
/tmp
Other example:
/tmp cat b.c
#include pwd.h
int main()
{
getpwnam(root);
return 0;
}
/tmp gcc -static b.c
/tmp/ccZB6Ooy.o: In function `main':
b.c:(.text+0x11): warning: Using 'getpwnam' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking
/tmp ./a.out
a.out: ../sysdeps/unix/sysv/linux/getpagesize.c:32: __getpagesize: Assertion
`_rtld_global_ro._dl_pagesize != 0' failed.
/tmp
Thanks,
Adam
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.38.2 (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/bash
Versions of packages libc6 depends on:
ii libc-bin 2.13-2 Embedded GNU C Library: Binaries
ii libgcc1 1:4.6.0-7 GCC support library
Versions of packages libc6 recommends:
ii libc6-i6862.13-2 Embedded GNU C Library: Shared lib
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.39 Debian configuration management sy
ii glibc-doc 2.13-2 Embedded GNU C Library: Documentat
ii locales 2.13-2 Embedded GNU C Library: National L
-- 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#621741: minicom: ~ (tilde) gets expanded to users home in dial commands
On Fri Apr 08, 2011 at 15:35:41 +0200, Florian Lohoff wrote: Hi, when entering a single ~ in the Modem and Dialing commands e.g. Init String or Reset String the ~ gets expanded to the users homedir on pressing return. For obvious reasons this is broken as the ~ is the delay character and no shell globbing should happen. Right and thanks for reporting. Fixed upstream. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620622: minicom removes its own lockfile
On Sat Apr 02, 2011 at 21:32:34 -0700, Eugene Stemple wrote: When minicom is invoked for a RS-232 serial port, ttyS0, it creates a lockfile /var/lock/LCK..ttyS0 as expected. However, when a file transfer is initiated that lockfile is removed! For example, when an ASCII upload is started an ascii-xfr task is started and for the duration of that text file transfer there is no lockfile at all for the ttyS0 device. When the file transfer is complete the lockfile returns (owned by minicom). I think this is happening with the [x|y|z]modem file transfers also. If the device at the receiving end of the serial path sends back any character during the file transmission it is (apparently) redirected to mgetty (listening by default for a serial device to connect on that tty device) and mgetty then establishes a lockfile for the serial port. When the ASCII file transmission completes, an error message is displayed, cannot create lockfile and control returns to minicom (after pressing any key, as prompted). minicom can't create a lockfile for the tty device because mgetty now has it! The lockfile, and ownership, of the serial port remains with mgetty. mgetty then issues a login message to the remote terminal and attempts to get a user/password authentication. Any characters returned from the remote terminal are randomly(?) directed to either mgetty or minicom - probably a race since both programs think they own the serial port. The straightforward recovery is to exit minicom; then, from the remote terminal either login and logout (to put mgetty back to sleep) or wait for the login timeout to cycle. Then, if desired, restart minicom. It seems like minicom should retain its lockfile when it spawns a file transfer since the transfer programs don't create their own. Some do, some not. I think kermit is among those that require to have an own lock file. I'm unsure how to solve this, even if lockfiles is removed/not removed depending on the program started by minicom. A race will be there when minicom removes it until the launched program is up. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613785: debian-user-german: removal of FAQ footer
Package: lists.debian.org Severity: normal Hi, debian-user-german has a footer in every list mail that refers to http://www.de.debian.org/debian-user-german-FAQ/. As it is not available anymore and has been outdated anyway, please remove this FAQ footer. Thanks, Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610511: minicom string/word size limit to 89 characters
tags 610511 fixed-upstream thanks On Wed Jan 19, 2011 at 11:27:42 +0100, Roland Stigge wrote: Package: minicom Version: 2.4-4 Severity: normal Hi, there seems to be a limit on (quoted) words to send in scripts: sth. like: send set xxx x in a script leads to: script test.minicom: syntax error in line 1 (word contains ESC or quote) in minicom. See also src/script.c:163:getword(). (I know that a partial workaround is to use (non-quoted) multiple words with the send command.) Thanks for the report. Fixed upstream. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610512: minicom: scripts never exit
tags 610512 fixed-upstream thanks On Wed Jan 19, 2011 at 11:17:53 +0100, Roland Stigge wrote: Package: minicom Version: 2.4-4 Severity: normal Hi, when a minicom script is run and exits, one still needs to press Ctrl-C. See also https://bugs.launchpad.net/ubuntu/+source/minicom/+bug/585911 and the respective PTS-accessible Ubuntu patch which is supposed to fix the bug. The patch is merged upstream. For me, the problem is gone after applying the patch. But please note that after running the script (and script exit), script ... is still present in the status line. I do not see this behaviour with current upstream version. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590900: minicom: setting localecho in config file doesn't work
Hi, On Fri Jul 30, 2010 at 01:52:39 +0200, Peter De Wachter wrote: I've tried configuring minicom to start with local echo enabled (pu localecho Yes in the config file), but this doesn't work. Minicom's upper layer recognizes this setting, but it isn't passed on to the vt100 layer. The attached patch contains a fix. I think this is already fixed in the upstream repo. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578001: minicom lock file incorrect format
On Thu Apr 15, 2010 at 23:47:07 +0100, David Wilson Clarke wrote: When starting 'minicom' contents of lock file is not to Filesystem Hierarchy Standard. FHS 2.3 states: Thanks, I've changed it accordingly (in upstream repo). Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550604: korganizer: Segfaults when creating calendar entry
On Sun Oct 11, 2009 at 16:27:52 +0200, Adam Lackorzynski wrote: korganizer always crashes for me when I create a new calender entry by double-clicking e.g. in the week view, add a title and klicking 'Apply'. The crash-report reads as follows: Application: KOrganizer (korganizer), signal: Segmentation fault [Current thread is 1 (Thread 0xb4e22700 (LWP 16565))] Thread 2 (Thread 0xb2de3b90 (LWP 16735)): [KCrash Handler] #6 strlen () at ../sysdeps/i386/i486/strlen.S:40 #7 0xb6823645 in *__GI___strdup (s=0x274e Address 0x274e out of bounds) at strdup.c:42 #8 0xb608a87e in icalmemory_strdup () from /usr/lib/libical.so.0 For some reason I had libical0 version 4:2.2.1-1 installed which does not seem to exist anymore. I've 'downgraded' to the other implementation with version 0.44-1 and now it works. Might this be a dependency issue? Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552892: minicom: FTBFS: minicom.c:170: error: conflicting types for 'getline'
On Wed Oct 28, 2009 at 11:34:21 +0100, Lucas Nussbaum wrote: During a rebuild of all packages in sid, your package failed to build on amd64. In eglibc = 2.9, getline was only defined if _GNU_SOURCE was defined. In eglibc 2.10, getline is always defined (since it became a standard in POSIX2008). The problem is that your package already has a function named getline(), which now conflicts with glibc's. You need to rename your function to something else. Relevant part: /usr/include/stdio.h:651: error: previous declaration of 'getline' was here make[3]: *** [minicom.o] Error 1 FWIW, upstream has already renamed those to mc_getline. Backports or release 2.4 finally? The latter is probably better... Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550604: korganizer: Segfaults when creating calendar entry
Package: korganizer Version: 4:4.3.2-1 Severity: important Hi, korganizer always crashes for me when I create a new calender entry by double-clicking e.g. in the week view, add a title and klicking 'Apply'. The crash-report reads as follows: Application: KOrganizer (korganizer), signal: Segmentation fault [Current thread is 1 (Thread 0xb4e22700 (LWP 16565))] Thread 2 (Thread 0xb2de3b90 (LWP 16735)): [KCrash Handler] #6 strlen () at ../sysdeps/i386/i486/strlen.S:40 #7 0xb6823645 in *__GI___strdup (s=0x274e Address 0x274e out of bounds) at strdup.c:42 #8 0xb608a87e in icalmemory_strdup () from /usr/lib/libical.so.0 #9 0xb60988cc in icalvalue_set_text () from /usr/lib/libical.so.0 #10 0xb6098857 in icalvalue_new_text () from /usr/lib/libical.so.0 #11 0xb6090aec in icalproperty_set_transp () from /usr/lib/libical.so.0 #12 0xb6090a90 in icalproperty_new_transp () from /usr/lib/libical.so.0 #13 0xb7c28d8a in ?? () from /usr/lib/libkcal.so.4 #14 0xb7c2ae3c in ?? () from /usr/lib/libkcal.so.4 #15 0xb7be2698 in ?? () from /usr/lib/libkcal.so.4 #16 0xb7c1cbb0 in ?? () from /usr/lib/libkcal.so.4 #17 0xb7c196ec in KCal::ICalFormat::toString(KCal::Incidence*) () from /usr/lib/libkcal.so.4 #18 0xb24b4f1f in ?? () from /usr/lib/kde4/akonadi_serializer_kcal.so #19 0xb2ea83dd in ?? () from /usr/lib/libakonadi-kde.so.4 #20 0xb2ea8487 in ?? () from /usr/lib/libakonadi-kde.so.4 #21 0xb2e9b9e8 in Akonadi::ItemCreateJob::doStart() () from /usr/lib/libakonadi-kde.so.4 #22 0xb2eb6812 in ?? () from /usr/lib/libakonadi-kde.so.4 #23 0xb2eb6dfe in Akonadi::Job::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libakonadi-kde.so.4 #24 0xb2ee971a in Akonadi::TransactionSequence::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libakonadi-kde.so.4 #25 0xb7517303 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQtCore.so.4 #26 0xb7517f42 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #27 0xb751d007 in ?? () from /usr/lib/libQtCore.so.4 #28 0xb751d12c in ?? () from /usr/lib/libQtCore.so.4 #29 0xb751239f in QObject::event(QEvent*) () from /usr/lib/libQtCore.so.4 #30 0xb6b41a94 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #31 0xb6b49bee in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #32 0xb7ea70dd in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #33 0xb75021eb in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4 #34 0xb7530e21 in ?? () from /usr/lib/libQtCore.so.4 #35 0xb752d317 in ?? () from /usr/lib/libQtCore.so.4 #36 0xb55e0e98 in g_main_dispatch (context=0x8649b48) at /build/buildd-glib2.0_2.22.2-2-i386-R8GTDn/glib2.0-2.22.2/glib/gmain.c:1960 #37 IA__g_main_context_dispatch (context=0x8649b48) at /build/buildd-glib2.0_2.22.2-2-i386-R8GTDn/glib2.0-2.22.2/glib/gmain.c:2513 #38 0xb55e4623 in g_main_context_iterate (context=0x8649b48, block=1, dispatch=1, self=0x8678170) at /build/buildd-glib2.0_2.22.2-2-i386-R8GTDn/glib2.0-2.22.2/glib/gmain.c:2591 #39 0xb55e47a8 in IA__g_main_context_iteration (context=0x8649b48, may_block=1) at /build/buildd-glib2.0_2.22.2-2-i386-R8GTDn/glib2.0-2.22.2/glib/gmain.c:2654 #40 0xb752d041 in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /usr/lib/libQtCore.so.4 #41 0xb750083a in QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /usr/lib/libQtCore.so.4 #42 0xb7500c82 in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from /usr/lib/libQtCore.so.4 #43 0xb76ceb4e in KJob::exec() () from /usr/lib/libkdecore.so.5 #44 0xb2f57146 in ?? () from /usr/lib/kde4/kcal_akonadi.so #45 0xb74115e2 in ?? () from /usr/lib/libQtCore.so.4 #46 0xb55924b5 in start_thread (arg=0xb2de3b90) at pthread_create.c:300 #47 0xb688ea5e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 1 (Thread 0xb4e22700 (LWP 16565)): #0 0xe424 in __kernel_vsyscall () #1 0xb5595f65 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122 #2 0xb689d85d in __pthread_cond_wait (cond=0x84b3e20, mutex=0x84b3e08) at forward.c:139 #3 0xb74125c2 in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4 #4 0xb2f46ef1 in ?? () from /usr/lib/kde4/kcal_akonadi.so #5 0xb2f412b3 in ?? () from /usr/lib/kde4/kcal_akonadi.so #6 0xb7c526db in KCal::ResourceCalendar::save(KCal::Incidence*) () from /usr/lib/libkcal.so.4 #7 0xb7c62c61 in KCal::CalendarResources::save(KCal::CalendarResources::Ticket*, KCal::Incidence*) () from /usr/lib/libkcal.so.4 #8 0xb7c6532d in KCal::CalendarResources::endChange(KCal::Incidence*) () from /usr/lib/libkcal.so.4 #9 0xb7c69f17 in KCal::CalendarResources::addIncidence(KCal::Incidence*) () from /usr/lib/libkcal.so.4 #10 0xb7a3fe4f in IncidenceChanger::addIncidence(KCal::Incidence*, QWidget*) () from
Bug#477308: minicom crashes when running a script after a log file had been enabled
Hi, On Tue Apr 22, 2008 at 12:29:49 +0200, Lothar Wassmann wrote: If a script is being run after logging has been enabled and subsequently disabled minicom crashes. I.e: - Enable logging to a file - Disable logging - Start any minicom script = crash I can confirm this for the etch version but cannot trigger it on sid nor latest CVS. So this seems fixed. Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477071: hpoj: Missing dependency to 'killall'
Package: hpoj Version: 0.91-13.2 Severity: normal Hi, the ptal-init script uses 'killall' which is in package psmisc but is not listed in the dependencies of hpoj. A missing killall makes 'ptal-init setup' fail in a strange way when trying to detect USB devices. Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466961: minicom: In the options menu: can not set a number of the history lines bigger that 3 digits
On Fri Feb 22, 2008 at 14:14:45 +0900, Rene Pavlik wrote: The implicit history buffer size is 2000 lines. This cannot be changed in the menu to a bigger value than 999, since I can type 3 digits only. Thanks, fixed in repo. Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460485: minicom: [I18N] translated string is truncated in the menu
On Sun Jan 13, 2008 at 06:46:57 +0300, Yuri Kozlov wrote: char some_string[32]; but it is too small for utf8 translated Russian text (and not only Russian, I think) Could it be to increase up to 64 or allocated dynamically? I increased the string in the upstream repo. Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460497: minicom: [i18n] missing localisation for ADDLINEFEED and LOCALECHO
On Sun Jan 13, 2008 at 11:07:24 +0300, Yuri Kozlov wrote: Patch: --- src/config.c2007-05-12 13:12:24.0 +0400 +++ /home/yuray/tmp/minicom-2.3~rc1/src/config.c2008-01-13 08:15:31.0 +0300 @@ -847,8 +844,8 @@ mc_wprintf(w, %s %s\n, macros_enabled, _(P_MACENAB)); mc_wprintf(w, %s %s\n, character_conversion, P_CONVF); - mc_wprintf(w, %s %s\n, add_linefeed, P_ADDLINEFEED); - mc_wprintf(w, %s %s\n, local_echo, P_LOCALECHO); + mc_wprintf(w, %s %s\n, add_linefeed, _(P_ADDLINEFEED)); + mc_wprintf(w, %s %s\n, local_echo, _(P_LOCALECHO)); mc_wredraw(w, 1); @@ -1115,12 +1112,12 @@ break; case 'P': psets(P_ADDLINEFEED, yesno(P_ADDLINEFEED[0] == 'N')); -mc_wlocate(w, strlen (add_linefeed) + 1, 16); +mc_wlocate(w, mbslen (add_linefeed) + 1, 16); mc_wprintf(w, %s, _(P_ADDLINEFEED)); break; case 'Q': psets(P_LOCALECHO, yesno(P_LOCALECHO[0] == 'N')); -mc_wlocate(w, strlen (local_echo) + 1, 17); +mc_wlocate(w, mbslen (local_echo) + 1, 17); mc_wprintf(w, %s, _(P_LOCALECHO)); break; } Committed, thanks. Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450943: minicom: FTBFS on GNU/kFreeBSD
On Mon Nov 12, 2007 at 15:41:36 +0100, Petr Salinger wrote: the current version fails to build on GNU/kFreeBSD. It is due to usage of non-posix TCGETS. Please use portable tcgetattr() instead. It would also be nice if you can ask upstream to include this changes. Thanks, committed upstream. Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423017: internal_utf8_loop_single: Assertion
merge 413934 423017 thanks On Wed May 09, 2007 at 15:23:29 +0200, David Weinehall wrote: Package: minicom Version: 2.2-5 Severity: normal Minicom crashed on me today, with the following error message: minicom: ../iconv/loop.c:425: internal_utf8_loop_single: Assertion `inptr - bytebuf (state-__count 7)' failed. Thanks for the report. This one is known but doesn't seem easily fixable. Ideas? Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419538: minicom: SEGV with deep directory
Hi Yasushi, On Fri Apr 20, 2007 at 20:46:30 +0900, Yasushi SHOJI wrote: The reason was simple. We played with variable work_dir when we draw the screen and left along. Then, in the next iteration, realloc() was upset because we gave the changed wrong address as the first argument. Thanks for your analysis and the patch. I've applied it the upstream CVS repository. this is very good example why we should reduce global variables to play with. very nasty code. Indeed. The file dialog is also quite ugly and probably needs to be redone from scratch. Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413934: minicom crashes if LANG=de_DE.UTF-8 is set - with LANG=POSIX it works fine
On Sun Apr 15, 2007 at 08:10:07 +0200, Martin Godisch wrote:
On Sat, Mar 10, 2007 at 17:41:19 +0100, Adam Lackorzynski wrote:
If minicom is started with LANG=de_DE.UTF-8 and serial port is set
wrong (wrong Bps/Par/Bits), it crashes with the following error
message:
xminicom: ../iconv/loop.c:425: internal_utf8_loop_single:
Zusicherung »inptr - bytebuf (state-__count 7)« nicht erfüllt.
It's hard for me to do anything about this since this is an assertion
from inside glibc. To start, I probably need to reproduce this...
Does a strace log help? The bug can be reproduced by pointing minicom to
a fifo (with empty scriptprog, minit, mreset) and putting Mike Crowe's
crash.cap into it.
The backtrace does not really help. I'm not sure what to do as this
looks like a glibc issue. On the other side there's #115566.
Reassign/reopen?
This little patch makes minicom crash instantly when started, when using
LANG=en_GB.UTF-8 (or another utf8 locale).
Unfortunately creating a little test program which triggers this
assertion does not seem so easy.
This issue also puts the question whether it is good to display (serial)
input with the local locale or rather use C? Or something
configurable? A work around for this could also be to set the locale to
C when outputting input data.
Any opinions?
Index: main.c
===
RCS file: /cvsroot/minicom/minicom/src/main.c,v
retrieving revision 1.16
diff -u -r1.16 main.c
--- main.c 31 Oct 2005 12:13:51 - 1.16
+++ main.c 15 Apr 2007 10:11:06 -
@@ -681,8 +681,21 @@
/* Update the timer. */
timer_update();
-/* Check for I/O or timer. */
-x = check_io(portfd_connected, 0, 1000, buf, blen);
+{
+ static int foo = 0;
+ if (!foo) {
+ x = 1;
+ buf[0] = 248;
+ buf[1] = 226;
+ buf[2] = 130;
+ buf[3] = 172;
+ buf[4] = 194;
+ buf[5] = 163;
+ blen = 6;
+ foo = 1;
+ } else
+x = check_io(portfd_connected, 0, 1000, buf, blen);
+}
/* Send data from the modem to the screen. */
if ((x 1) == 1) {
Adam
--
Adam [EMAIL PROTECTED]
Lackorzynski http://os.inf.tu-dresden.de/~adam/
Bug#416060: minicom: wrong way to scan a directory and list files
Hallo, On Sat Mar 24, 2007 at 15:28:17 +0100, Ludovic Rousseau wrote: When I ask to upload a file a dialog listing the files is displayed. Some files are missing from the listing. I found the bug. minicom assumes that '.' and '..' files are the first and second answers from readdir(). This is not correct for every filesystem but generaly is. I guess ext3 has some optimisations and then reorder the entries. Thanks for the patch, I fixed it in the upstream CVS. Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412561: minicom can't read .dialdir created on amd64
On Mon Feb 26, 2007 at 23:35:02 +0100, Adam Lackorzynski wrote: On Mon Feb 26, 2007 at 11:41:34 -0800, Alan Ianson wrote: Package: minicom Version: 2.2-5 Severity: minor Minicom on amd64 can't read a .dialdir created by minicom on i386 or vice-versa. Some 32 - 64 bit thing? Yes, confirmed. Alignment issue in some structures. Will see how a fix could look like. I've now implemented a new version of the dialdir format that should be 32/64 as well as endian safe. Minicom will still read the old format and convert the new one which then should work. HTH, Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413934: minicom crashes if LANG=de_DE.UTF-8 is set - with LANG=POSIX it works fine
On Thu Mar 08, 2007 at 14:04:09 +0100, Markus Meier wrote: Am Donnerstag, 8. März 2007 10:33 schrieb Adam Lackorzynski: On Thu Mar 08, 2007 at 00:14:07 +0100, Markus Meier wrote: If minicom is started with LANG=de_DE.UTF-8 and serial port is set wrong (wrong Bps/Par/Bits), it crashes with the following error message: xminicom: ../iconv/loop.c:425: internal_utf8_loop_single: Zusicherung »inptr - bytebuf (state-__count 7)« nicht erfüllt. Can you give me a concrete example of the wrong configuration? I can't trigger this assertion (on ia32). I booted pfsense (Firewall derivated from FreeBSD) and tried to watch the boot process via serial console. pfsense wants me to set the serial port to 9600 8N1, but I firstly forgot this and kept the old setting, which was 38400 8N1. I think the resultant garbage on the terminal raised the foregoing error. I also did some further investigation and tried this on x86 and x86-64, but the error appears on both computers. It's hard for me to do anything about this since this is an assertion from inside glibc. To start, I probably need to reproduce this... I also found the following typing error: When I leave minicom with strg a + x it says Modem zurüksetzen but here a 'c' is missing, as it has to be labeled to Modem zurücksetzen. Thanks, this one is fixed in upstream. Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/
Bug#413934: minicom crashes if LANG=de_DE.UTF-8 is set - with LANG=POSIX it works fine
Hi, On Thu Mar 08, 2007 at 00:14:07 +0100, Markus Meier wrote: If minicom is started with LANG=de_DE.UTF-8 and serial port is set wrong (wrong Bps/Par/Bits), it crashes with the following error message: xminicom: ../iconv/loop.c:425: internal_utf8_loop_single: Zusicherung »inptr - bytebuf (state-__count 7)« nicht erfüllt. Can you give me a concrete example of the wrong configuration? I can't trigger this assertion (on ia32). Thanks, Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/
Bug#413131: powerpc-utils: nvsetenv fails to read/write nvram
Package: powerpc-utils
Severity: important
Tags: patch
Hi,
on recent kernels like 2.6.19 nvsetenv does work anymore:
$ nvsetenv
Error reading /dev/nvram: No such file or directory
This is caused by the fact that nvsetenv tries to read from /dev/nvram
with a single read call whereas Linux only supplies 4k and the data to
be read is over 4k. The same applies for writing. The following patch
fixes nvsetenv for me so that I can set options again.
--- powerpc-utils-1.1.3/nwnvsetenv.c2007-03-02 15:34:30.531458670 +0100
+++ powerpc-utils-1.1.3-al/nwnvsetenv.c 2007-03-02 15:54:04.320050019 +0100
@@ -75,7 +75,7 @@
/* seek NVRAM until common (OF) part
return the lenght of the part in case of sucess,
0 otherwise.
- chrph is set to the value of the coommon blocek eventually found
+ chrph is set to the value of the common block eventually found
*nvstart is set to the seekpoint where common block starts.
*/
@@ -102,12 +102,18 @@
static char* nvload( int nvfd , int nvsize)
{
char* nvbuf = malloc(nvsize);
+char *b = nvbuf;
+int i;
if (!nvbuf) {
perror(Error allocating buffer);
exit(EXIT_FAILURE);
}
-if (read(nvfd, nvbuf, nvsize) != nvsize) {
+while ((i = read(nvfd, b, nvsize)) 0) {
+ b += i;
+ nvsize -= i;
+}
+if (i == -1) {
perror(Error reading /dev/nvram);
exit(EXIT_FAILURE);
}
@@ -225,10 +231,15 @@
fprintf(stderr,Error seeking /dev/nvram\n);
exit(EXIT_FAILURE);
}
-written = write(nvfd, nvbuf, nvsize);
-if (written != nvsize)
+
+while ((written = write(nvfd, nvbuf, nvsize)) 0)
+{
+ nvsize -= written;
+ nvbuf += written;
+}
+if (written == -1)
{
- fprintf(stderr,Error writing /dev/nvram %x %x\n, nvsize, seek);
+ fprintf(stderr,Error writing /dev/nvram %x %x %x\n, nvsize, seek,
written);
exit(EXIT_FAILURE);
}
}
Adam
--
Adam [EMAIL PROTECTED]
Lackorzynski http://os.inf.tu-dresden.de/~adam/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412561: minicom can't read .dialdir created on amd64
On Mon Feb 26, 2007 at 11:41:34 -0800, Alan Ianson wrote: Package: minicom Version: 2.2-5 Severity: minor Minicom on amd64 can't read a .dialdir created by minicom on i386 or vice-versa. Some 32 - 64 bit thing? Yes, confirmed. Alignment issue in some structures. Will see how a fix could look like. Thanks, Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405219: minicom: unlocalized messages
tags 405219 patch thanks Hi, On Tue Jan 02, 2007 at 00:01:54 +0100, Samuel Thibault wrote: Package: minicom Version: 2.2-4 Severity: minor Tags: l10n Hi, Though they are available as mo files, french messages are not used instead of english messages. Indeed. I just committed the following to the minicom repo: --- src/intl.h 30 Mar 2003 18:55:51 - 1.1.1.1 +++ src/intl.h 7 Jan 2007 15:46:58 - @@ -3,9 +3,6 @@ #ifdef HAVE_LOCALE_H # include locale.h #endif -#if !HAVE_SETLOCALE -# define setlocale(Category, Locale) /* empty */ -#endif #define N_(Str) (Str) Thanks, Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361728: ifdata: more code improvements
Package: moreutils
Version: 0.10
Severity: normal
Tags: patch
Hi,
here are some more fixes to the code, esp. return checks for lib calls
as well as the removal of all macros and code duplication, thus reducing
the code size by nearly 5k (~40%).
Adam
--
Adam [EMAIL PROTECTED]
Lackorzynski http://os.inf.tu-dresden.de/~adam/
Index: ifdata.c
===
--- ifdata.c(revision 38)
+++ ifdata.c(working copy)
@@ -45,599 +45,480 @@
};
struct if_stat {
- unsigned long long int in_packets;
- unsigned long long int in_bytes;
- unsigned long long int in_errors;
- unsigned long long int in_drops;
- unsigned long long int in_fifo;
- unsigned long long int in_frame;
- unsigned long long int in_compress;
- unsigned long long int in_multicast;
- unsigned long long int out_bytes;
- unsigned long long int out_packets;
- unsigned long long int out_errors;
- unsigned long long int out_drops;
- unsigned long long int out_fifo;
- unsigned long long int out_colls;
- unsigned long long int out_carrier;
- unsigned long long int out_multicast;
+ unsigned long long in_packets, in_bytes, in_errors, in_drops;
+ unsigned long long in_fifo, in_frame, in_compress, in_multicast;
+ unsigned long long out_bytes, out_packets, out_errors, out_drops;
+ unsigned long long out_fifo, out_colls, out_carrier, out_multicast;
};
-void print_quad_ipv4(unsigned int i) {
-#if __BYTE_ORDER == __LITTLE_ENDIAN
- printf(%d.%d.%d.%d,
- i0xff,
- (i0xff00)8,
- (i0xff)16,
- (i0xff00)24);
-#else
- printf(%d.%d.%d.%d,
- (i0xff00)24,
- (i0xff)16,
- (i0xff00)8,
- i0xff);
-#endif
+void print_quad_ipv4(in_addr_t i)
+{
+ i = ntohl(i);
+ printf(%d.%d.%d.%d,
+ (i 0xff00) 24,
+ (i 0x00ff) 16,
+ (i 0xff00) 8,
+ (i 0x00ff));
}
-void print_quad_ipv6(uint16_t *a) {
- int i;
- for (i=0; i7; i++) {
- printf(%04x:,a[i]);
- }
- printf(%04x,a[i]);
+void print_quad_ipv6(uint16_t *a)
+{
+ printf(%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x,
+ a[0], a[1], a[2], a[3], a[4], a[5], a[6], a[7]);
}
-void print_quad(struct sockaddr *adr) {
- switch (adr-sa_family) {
- case AF_INET:
- print_quad_ipv4(((struct
sockaddr_in*)adr)-sin_addr.s_addr);
- break;
- case AF_INET6:
- print_quad_ipv6(((struct
sockaddr_in6*)adr)-sin6_addr.s6_addr16);
- break;
- default:
- printf(NON-IP);
- break;
- }
+void print_quad(struct sockaddr *adr)
+{
+ switch (adr-sa_family) {
+case AF_INET:
+ print_quad_ipv4(((struct sockaddr_in*)adr)-sin_addr.s_addr);
+ break;
+case AF_INET6:
+ print_quad_ipv6(((struct sockaddr_in6*)adr)-sin6_addr.s6_addr16);
+ break;
+default:
+ printf(NON-IP);
+ break;
+ }
}
-#define PREPARE_SOCK(iface)int sock; \
- static struct ifreq req; \
- int res; \
- sock=socket(PF_INET,SOCK_DGRAM,IPPROTO_IP); \
- strcpy(req.ifr_name,iface)
-#define CALL_IOCTL(call) res=ioctl(sock,call,req)
-#define END_SOCK close(sock)
-#define CALL_ERROR(todo) if (res==-1) { perror(ioctl); close(sock);
todo; }
+enum print_error_enum {
+ PRINT_ERROR,
+ PRINT_NO_ERROR,
+};
-int if_exists(char *iface) {
- PREPARE_SOCK(iface);
- CALL_IOCTL(SIOCGIFFLAGS);
- if (res==-1 errno==ENODEV) {
- END_SOCK;
- return 0;
- }
- CALL_ERROR(return 0);
- END_SOCK;
- return 1;
-}
+/**
+ * \return 0 success
+ * 1 error
+ */
+static int do_socket_ioctl(const char *ifname, const int request,
+ struct ifreq *req, int *ioctl_errno,
+ const enum print_error_enum print_error)
+{
+ int sock, res;
-#define PRINT_IF(cond,tell) if (req.ifr_flags cond) printf(tell); else
printf(No tell)
+ if ((sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP)) == -1)
+return 1;
+ strncpy(req-ifr_name, ifname, IFNAMSIZ);
+ req-ifr_name[IFNAMSIZ - 1] = 0;
-void if_flags(char *iface) {
- PREPARE_SOCK(iface);
- CALL_IOCTL(SIOCGIFFLAGS);
- CALL_ERROR(return);
- PRINT_IF(IFF_UP,Up\n);
- PRINT_IF(IFF_BROADCAST,Broadcast\n);
- PRINT_IF(IFF_DEBUG,Debugging\n);
- PRINT_IF(IFF_LOOPBACK,Loopback\n);
- PRINT_IF(IFF_POINTOPOINT,Ppp\n);
- PRINT_IF(IFF_NOTRAILERS,No-trailers\n);
-
Bug#360433: moreutils: bogus hwaddr for invalid interface
Package: moreutils
Version: 0.9
Severity: normal
Tags: patch
$ ifdata -ph foo
ioctl: No such device
00:00:00:00:00:00
The attached patch changes the behaviour to
$ ifdata -ph foo
ioctl: No such device
without printing the bogus hwaddr.
Adam
--
Adam [EMAIL PROTECTED]
Lackorzynski http://os.inf.tu-dresden.de/~adam/
Index: ifdata.c
===
--- ifdata.c(revision 35)
+++ ifdata.c(working copy)
@@ -152,9 +152,7 @@
PREPARE_SOCK(iface);
CALL_IOCTL(SIOCGIFHWADDR);
- if (res 0) {
- CALL_ERROR();
- }
+ CALL_ERROR(return);
hwaddr = (unsigned char *)req.ifr_hwaddr.sa_data;
printf(%02X:%02X:%02X:%02X:%02X:%02X,
hwaddr[0], hwaddr[1], hwaddr[2], hwaddr[3], hwaddr[4],
hwaddr[5]);
Bug#358930: moreutils: Segfaults if /proc not mounted
Package: moreutils
Version: 0.7
Severity: normal
Tags: patch
ifdata crashes if /proc is not mounted due to following
NULL pointer derefs. Possible patch attached, against 0.8.
I also added a check for malloc I spotted.
Adam
--
Adam [EMAIL PROTECTED]
Lackorzynski http://os.inf.tu-dresden.de/~adam/
--- moreutils/ifdata.c 2006-03-25 10:48:26.205496338 +
+++ x/moreutils/ifdata.c2006-03-25 01:50:18.0 +
@@ -275,15 +275,9 @@
int state=START;
int len;
struct if_stat *res=malloc(sizeof(struct if_stat));
-
-if (!res) {
- perror(malloc);
- return NULL;
- }
-
fd=open(/proc/net/dev,O_RDONLY);
if (fd==-1) {
- perror(open(\/proc/net/dev\));
+ perror(open);
return NULL;
}
while ((len=read(fd,buffer,4096))) {
@@ -448,48 +442,39 @@
break;
case DO_SINPACKETS:
if (!stats) stats=get_stats(ifname);
- if (stats)
- printf(%llu,stats-in_packets);
+ printf(%llu,stats-in_packets);
break;
case DO_SINBYTES:
if (!stats) stats=get_stats(ifname);
- if (stats)
- printf(%llu,stats-in_bytes);
+ printf(%llu,stats-in_bytes);
break;
case DO_SINERRORS:
if (!stats) stats=get_stats(ifname);
- if (stats)
- printf(%llu,stats-in_errors);
+ printf(%llu,stats-in_errors);
break;
case DO_SINDROPS:
if (!stats) stats=get_stats(ifname);
- if (stats)
- printf(%llu,stats-in_drops);
+ printf(%llu,stats-in_drops);
break;
case DO_SINFIFO:
if (!stats) stats=get_stats(ifname);
- if (stats)
- printf(%llu,stats-in_fifo);
+ printf(%llu,stats-in_fifo);
break;
case DO_SINFRAME:
if (!stats) stats=get_stats(ifname);
- if (stats)
- printf(%llu,stats-in_frame);
+ printf(%llu,stats-in_frame);
break;
case DO_SINCOMPRESSES:
if (!stats) stats=get_stats(ifname);
- if (stats)
- printf(%llu,stats-in_compress);
+ printf(%llu,stats-in_compress);
break;
case DO_SINMULTICAST:
if (!stats) stats=get_stats(ifname);
- if (stats)
- printf(%llu,stats-in_multicast);
+ printf(%llu,stats-in_multicast);
break;
case DO_SINALL:
if (!stats) stats=get_stats(ifname);
- if (stats)
- printf(%llu %llu %llu %llu %llu %llu %llu
%llu,
+ printf(%llu %llu %llu %llu %llu %llu %llu
%llu,
stats-in_packets,
stats-in_bytes,
stats-in_errors,
@@ -501,48 +486,39 @@
break;
case DO_SOUTBYTES:
if (!stats) stats=get_stats(ifname);
- if (stats)
- printf(%llu,stats-out_bytes);
+ printf(%llu,stats-out_bytes);
break;
case DO_SOUTPACKETS:
if (!stats) stats=get_stats(ifname);
- if (stats)
- printf(%llu,stats-out_packets);
+ printf(%llu,stats-out_packets);
break;
case DO_SOUTERRORS:
if (!stats) stats=get_stats(ifname);
- if (stats)
- printf(%llu,stats-out_errors);
+
Bug#345378: glibc: __libc_atexit section disappears with --gc-sections, breaking exit-flushing
Package: glibc
Severity: normal
Hi,
when a program is linked with the --gc-sections linker option,
the __libc_atexit section in the final binary disappears. As a
consequence the flushing on exit does not work.
$ cat x.c
#include stdlib.h
#include stdio.h
int main(void) { printf(blah\n); exit(0); }
$ gcc -static -W -Wall -o x x.c
$ objdump -h x | grep __libc_atexit
6 __libc_atexit 0004 080add30 080add30 00065d30 2**2
$ ./x | cat
blah
$ gcc -Wl,--gc-sections -static -W -Wall -o x x.c
$ objdump -h x | grep __libc_atexit
$ ./x | cat
$
The __libc_atexit section contains a reference to the _IO_cleanup
function in glibc which flushes all streams.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Adam
--
Adam [EMAIL PROTECTED]
Lackorzynski http://os.inf.tu-dresden.de/~adam/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327797: bins: contains paths from the build process
Package: bins Version: 1.1.29-1 Severity: grave Justification: renders package unusable Hi, the bins script file contains paths from the build process making it unusable because it cannot find its styles etc and therefore does not work: ~# grep tbm /usr/bin/bins my $localePath = /home/tbm/tmp/src/b/new/bins-1.1.29/debian/bins/usr/share/locale; # Base locale path (for I18N) globalDataDir = /home/tbm/tmp/src/b/new/bins-1.1.29/debian/bins/usr/share/bins, # System wide data directory It looks like this is a design issue in install.sh which always prepends DESTDIR instead of only doing so when operating on files and not when replacing paths in the binaries. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages bins depends on: ii libhtml-clean-perl 0.8-8Cleans up HTML code for web browse ii libhtml-parser-perl 3.45-2 A collection of modules that parse ii libhtml-template-perl 2.6-2HTML::Template : A module for usin ii libimage-info-perl 1.16-2 allows extraction of meta informat ii libimage-size-perl 2.992-1 determine the size of images in se ii libio-string-perl 1.05-1 Emulate IO::File interface for in- ii libjpeg-progs 6b-10Programs for manipulating JPEG fil ii liblocale-gettext-perl 1.05-1 Using libc functions for internati ii libtext-iconv-perl 1.4-1converts between character sets in ii libtext-unaccent-perl 1.08-1 provides functions to remove accen ii libtimedate-perl1.1600-4 Time and date functions for Perl ii liburi-perl 1.35-1 Manipulates and accesses URI strin ii libxml-enno-perl [libxml-xq 1.05-3 Perl modules for working with XML ii libxml-grove-perl 0.46alpha-11 Perl module for accessing parsed * ii libxml-handler-yawriter-per 0.23-5 Perl module for writing XML docume ii libxml-perl 0.08-1 Perl modules for working with XML ii libxml-writer-perl 0.600-1 Perl module for writing XML docume ii perlmagick 6:6.2.3.6-3 A perl interface to the libMagick bins recommends no packages. -- no debconf information Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325297: svnmailer: Example configuration missing
Package: svnmailer Version: 1.0.3-2 Severity: normal Hi, /usr/share/doc/svnmailer/README.Debian states that there's a example configuration file in /usr/share/doc/svnmailer/examples/ but that examples directory does not exist. Where is it? Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307411: unison: fails to install
Package: unison Version: 2.10.2-1 Severity: normal unison fails to install with the following message because of a wrong entry in the postinst: Setting up unison (2.10.2-1) ... /usr/share/doc-base/[EMAIL PROTECTED]@-manual: cannot open control file for reading: No such file or directory dpkg: error processing unison (--configure): subprocess post-installation script returned error exit status 2 Errors were encountered while processing: unison -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages unison depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an -- no debconf information Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
