Bug#1007965: Cyrus IMAP 3.6 Migration Failure
Hi,
I'm on the same boat. But it seems that upgrade failure is not
caused by missing utilities, but rather by mailboxes created more than
7 years ago (probably in cyrus 2.x).
Code to upgrade mailboxes
(https://github.com/cyrusimap/cyrus-imapd/blob/add814e90cb2cb5804e5e9c87faca7af253ded4e/imap/mboxlist.c#L5411)
is calling hash_lookup with mbentry->uniqueid - but mbentry->uniqueid
may be NULL, causing NULL pointer dereference and crash.
When I dumped my old mailbox db, I can see that "new" entries have new
% format, with 'I' field, but old ones use legacy format without 'I'
key:
...
user.petr.Inbox2013 0 default petr lrswipcda
user.petr.Inbox2014 0 default petr lrswipcda
user.petr.Inbox2015 %(A %(petr lrswipcda) I
ol64w50y514kvpoke32tg6a3 P default V 1569218712 F 1 M 1569218711)
user.petr.Inbox2016 %(A %(petr lrswipcda) I
abommco8w0dxyzyjju8nu2rw P default V 1569218720 F 1 M 1569218719)
...
So to me this looks like upstream problem. I have applied patch below
on my host, and it seems to have fixed update crash.
--- cyrus-imapd-3.6.0~beta2/imap/mboxlist.c 2022-03-10
15:09:08.0 -0800
+++ cyrus-imapd-3.6.0~beta2.new/imap/mboxlist.c 2022-03-31
23:52:52.427711987 -0700
@@ -5408,6 +5408,9 @@
mbentry->mbtype |= MBTYPE_LEGACY_DIRS;
int idx = 0;
+if (mbentry->uniqueid == NULL) {
+mbentry->uniqueid = xstrdup(makeuuid());
+}
ptrarray_t *pa = hash_lookup(mbentry->uniqueid, urock->ids);
if (!pa) {
pa = ptrarray_new();
Also I think it would be nice if update code would create new
mailbox.db.NEW, and then rename .db to db.OLD and db.NEW to db on
success, rather than moving mailbox.db to mailbox.db.OLD, and then
perform upgrade - as then you end up with empty mailbox.db, and so 2nd
upgrade attempt succeeds, deleting mailbox.db.OLD and causing data
loss.
And finally I would suggest adding 'mailbox_legacy_dirs: true' to
imapd.conf on upgrade - if upgrade would not have failed, I would have
been for rude awakening when mailboxes for new users would have moved
into uuid directory without any warning.
Thanks,
Petr
P.S.: Sorry about using gmail, my own email server is now in a bit of
disarray :-(
Bug#948396: New glibc broke existing app due to historic stack alignment
Florian Weimer wrote on 1/7/2020 9:31 PM: * Petr Vandrovec: As far as I can tell, while x86-64 ABI requires stack to be aligned on entry to the functions, x86 ABI does not have any such requirement, and so glibc should align stack itself if it wants to use XMM instructions that require aligned values. The i386 ABI was changed after its initial release to require additional stack alignment. That's a problem. If you want to build glibc for i386 with SSE2 enabled (for example, with -march=x86-64), you need to build it with -mrealignstack as well. I'm not aware of any remaining issues with this combination. I do not want to rebuild anything, I just want things to work :-( libc6:i386 is built without SSE2 support, and takes precedence over libc6-i386, so that is how I've "solved" problem. Should be libc6-i386 named (after obsolete/virtual) libc6-i686 if it requires SSE2 and new stack alignment? Thanks, Petr
Bug#948396: New glibc broke existing app due to historic stack alignment
Package: libc6-i386 Version: 2.29-8 Since updating my system today our build system binaries started crashing. Upon further investigation problem is that __mktime_internal code in libc6-i386 now started using 'movaps' instruction without aligning stack on 16 byte boundary. As far as I can tell, while x86-64 ABI requires stack to be aligned on entry to the functions, x86 ABI does not have any such requirement, and so glibc should align stack itself if it wants to use XMM instructions that require aligned values. It seems that libc6:i386 is compiled correctly, so I worked around by installing that instead of libc6-i386:amd64. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/build/toolchain/lin32/p7zip-9.20/bin/7za x -y -tzip /bhavesh/home/petr/drboss/'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0xf7dbe0e2 in __mktime_internal (tp=0xffb60f8c, convert=0xf7dbd990 <__GI___gmtime_r>, offset=0xf7ee6350 ) at mktime.c:387 387 mktime.c: No such file or directory. (gdb) bt #0 0xf7dbe0e2 in __mktime_internal (tp=0xffb60f8c, convert=0xf7dbd990 <__GI___gmtime_r>, offset=0xf7ee6350 ) at mktime.c:387 #1 0xf7dc114d in timegm (tmp=0xffb60f8c) at timegm.c:33 #2 0x0804aa2b in ?? () #3 0x080704fc in ?? () #4 0x080f6859 in ?? () #5 0x0807fdf8 in ?? () #6 0x080804de in ?? () #7 0x080fa53a in ?? () #8 0x0808d0f9 in ?? () #9 0x0808f118 in ?? () #10 0x08054101 in ?? () #11 0x08057edf in ?? () #12 0xf7d2b811 in __libc_start_main (main=0x8057eb0, argc=6, argv=0xffb61be4, init=0x804a190, fini=0x8141ab0, rtld_fini=0xf7f41300 <_dl_fini>, stack_end=0xffb61bdc) at ../csu/libc-start.c:308 #13 0x0804a871 in ?? () (gdb) x /10i $eip-19 0xf7dbe0cf <__mktime_internal+591>: psubq %xmm1,%xmm0 0xf7dbe0d3 <__mktime_internal+595>: movd %xmm0,0x78(%esp) 0xf7dbe0d9 <__mktime_internal+601>: movq %xmm0,0x90(%esp) => 0xf7dbe0e2 <__mktime_internal+610>: movaps %xmm0,(%esp) 0xf7dbe0e6 <__mktime_internal+614>: movaps %xmm0,0x10(%esp) 0xf7dbe0eb <__mktime_internal+619>: mov0x40(%esp),%eax 0xf7dbe0ef <__mktime_internal+623>: mov%edi,%ecx 0xf7dbe0f1 <__mktime_internal+625>: mov%esi,%edx 0xf7dbe0f3 <__mktime_internal+627>: call 0xf7dbdc10 0xf7dbe0f8 <__mktime_internal+632>: test %eax,%eax (gdb) print /x $esp $1 = 0xffb60e24
Bug#941863: Patch to collect image body before transmitting it
Patch I'm using as workaround to postpone all sending data to
client until all GetImage() invocations are complete. This
way XDamage events arrive before GetImage reply header, rather
than between GetImage reply header and image data.
diff -u xorg-server-1.20.4-pristine/dix/dispatch.c xorg-server-1.20.4/dix/dispatch.c
--- xorg-server-1.20.4-pristine/dix/dispatch.c 2019-02-26 11:28:50.0 -0800
+++ xorg-server-1.20.4/dix/dispatch.c 2019-10-06 23:31:32.067804155 -0700
@@ -2077,9 +2077,10 @@
/* coordinates relative to the bounding drawable */
int relx, rely;
-long widthBytesLine, length;
+long widthBytesLine, length, responseLength;
Mask plane = 0;
char *pBuf;
+char *iPtr;
xGetImageReply xgi;
RegionPtr pVisibleRegion = NULL;
@@ -2155,21 +2156,19 @@
xgi.depth = pDraw->depth;
if (format == ZPixmap) {
widthBytesLine = PixmapBytePad(width, pDraw->depth);
-length = widthBytesLine * height;
+responseLength = widthBytesLine * height;
}
else {
widthBytesLine = BitmapBytePad(width);
plane = ((Mask) 1) << (pDraw->depth - 1);
/* only planes asked for */
-length = widthBytesLine * height *
+responseLength = widthBytesLine * height *
Ones(planemask & (plane | (plane - 1)));
}
-xgi.length = length;
-
-xgi.length = bytes_to_int32(xgi.length);
+xgi.length = bytes_to_int32(responseLength);
if (widthBytesLine == 0 || height == 0)
linesPerBuf = 0;
else if (widthBytesLine >= IMAGE_BUFSIZE)
@@ -2192,9 +2191,10 @@
length += widthBytesLine;
}
}
-if (!(pBuf = calloc(1, length)))
+if (!(pBuf = calloc(1, responseLength)))
return BadAlloc;
-WriteReplyToClient(client, sizeof(xGetImageReply), );
+
+iPtr = pBuf;
if (pDraw->type == DRAWABLE_WINDOW)
pVisibleRegion = &((WindowPtr) pDraw)->borderClip;
@@ -2206,23 +2206,24 @@
linesDone = 0;
while (height - linesDone > 0) {
nlines = min(linesPerBuf, height - linesDone);
+assert(responseLength >= iPtr - pBuf + nlines * widthBytesLine);
(*pDraw->pScreen->GetImage) (pDraw,
x,
y + linesDone,
width,
nlines,
- format, planemask, (void *) pBuf);
+ format, planemask, (void *) iPtr);
if (pVisibleRegion)
XaceCensorImage(client, pVisibleRegion, widthBytesLine,
pDraw, x, y + linesDone, width,
-nlines, format, pBuf);
+nlines, format, iPtr);
/* Note that this is NOT a call to WriteSwappedDataToClient,
as we do NOT byte swap */
-ReformatImage(pBuf, (int) (nlines * widthBytesLine),
+ReformatImage(iPtr, (int) (nlines * widthBytesLine),
BitsPerPixel(pDraw->depth), ClientOrder(client));
-WriteToClient(client, (int) (nlines * widthBytesLine), pBuf);
+iPtr += nlines * widthBytesLine;
linesDone += nlines;
}
}
@@ -2233,29 +2234,33 @@
linesDone = 0;
while (height - linesDone > 0) {
nlines = min(linesPerBuf, height - linesDone);
+assert(responseLength >= iPtr - pBuf + nlines * widthBytesLine);
(*pDraw->pScreen->GetImage) (pDraw,
x,
y + linesDone,
width,
nlines,
- format, plane, (void *) pBuf);
+ format, plane, (void *) iPtr);
if (pVisibleRegion)
XaceCensorImage(client, pVisibleRegion,
widthBytesLine,
pDraw, x, y + linesDone, width,
-nlines, format, pBuf);
+nlines, format, iPtr);
/* Note: NOT a call to WriteSwappedDataToClient,
as we do NOT byte swap */
-ReformatImage(pBuf, (int) (nlines * widthBytesLine),
+ReformatImage(iPtr, (int) (nlines * widthBytesLine),
1, ClientOrder(client));
-WriteToClient(client, (int)(nlines * widthBytesLine), pBuf);
+iPtr += nlines * widthBytesLine;
linesDone += nlines;
}
}
Bug#941863: XDamage events are intermingled with GetImage response
eader, and image data. Note that drawable returned by XDamage (1001) is same drawable on which client issued XGetImage. So 32 bytes of XDamage event is interpreted as image data, and last 32 bytes of image data are interpreted as X server response - resulting in instant crash as image data interpreted as X11 sequence will almost never match. So problem is not in vino-server, nor libx11 nor libxcb, but in X server itself. And indeed, with little instrumentation added there is a code path that generates XDamage event for drawable X from GetImage call for drawable X, inserting XDamage header between GetImage response header and its body, or between two parts of the body if GetImage could not be completed in one response: Thread 1 "Xorg" hit Breakpoint 1, DamageInsideGetImage () at ../../../../damageext/damageext.c:121 121 ../../../../damageext/damageext.c: No such file or directory. (gdb) bt #0 0x56203f7405cf in DamageInsideGetImage () at ../../../../damageext/damageext.c:121 #1 0x56203f7405cf in DamageExtNotify (pDamageExt=0x562040e766f0, pBoxes=0x7fff2a10fc20, nBoxes=1) at ../../../../damageext/damageext.c:121 #2 0x56203f74811b in DamageReportDamage (pDamage=pDamage@entry=0x562040e77540, pDamageRegion=0x562040e77598) at ../../../../../miext/damage/damage.c:1950 #3 0x56203f7488f8 in damageRegionProcessPending (pDrawable=) at ../../../../../miext/damage/damage.c:294 #4 0x56203f748f9d in damageComposite (op=, pSrc=, pMask=, pDst=0x562040adc6a0, xSrc=, ySrc=, xMask=0, yMask=0, xDst=0, yDst=1161, width=1600, height=39) at ../../../../../miext/damage/damage.c:518 #5 0x56203f6f2d7b in compWindowUpdateAutomatic (pWin=) at ../../../../composite/compwindow.c:705 #6 0x56203f6f2d7b in compPaintWindowToParent (pWin=pWin@entry=0x562040ce7790) at ../../../../composite/compwindow.c:729 #7 0x56203f6f3c48 in compPaintChildrenToWindow (pWin=0x562040771b30) at ../../../../composite/compwindow.c:744 #8 0x56203f6f3c48 in compPaintChildrenToWindow (pWin=pWin@entry=0x562040771b30) at ../../../../composite/compwindow.c:736 #9 0x56203f6f14ef in compGetImage (pDrawable=0x562040771b30, sx=1465, sy=1162, w=26, h=38, format=2, planemask=4294967295, pdstLine=0x562040e82980 "") at ../../../../composite/compinit.c:153 #10 0x56203f6667ab in DoGetImage (planemask=, height=, width=, y=, x=, drawable=, format=, client=0x562040cc5f80) at ../../../../dix/dispatch.c:2214 #11 0x56203f6667ab in ProcGetImage (client=0x562040cc5f80) at ../../../../dix/dispatch.c:2276 #12 0x56203f669944 in Dispatch () at ../../../../dix/dispatch.c:478 #13 0x56203f66d914 in dix_main (argc=6, argv=0x7fff2a110078, envp=) at ../../../../dix/main.c:276 #14 0x7fbfcefeabbb in __libc_start_main (main=0x56203f657700 , argc=6, argv=0x7fff2a110078, init=, fini=, rtld_fini=, stack_end=0x7fff2a110068) at ../csu/libc-start.c:308 #15 0x56203f65773a in _start () at ../../../../dix/gc.c:814 Unfortunately that's where my expertise ends. For my use I've modified ProcGetImage() to first collect all image data, and then send them together with header in one go, so events are sent before GetImage response header. But I don't think that's optimal solution, as it increases memory needed to complete full-screen GetImage call quite a bit. In my setup reproducibility is simple - start X with xfce, start vino-server, and try to connect. Thanks, Petr Vandrovec
Bug#908556: IPQoS change in 7.8p1 broke network access via Palo Alto Networks Global Protect
Package: openssh-server Version: 1:7.8p1-1 Hi, since update to OpenSSH 7.8p1-1 my ssh connection is getting terminated by RST as soon as OpenSSH figures out that this is interactive session, and starts using non-zero ToS: 22:18:37.850520 00:08:e3:ff:fd:90 > 34:17:eb:b5:b5:57, ethertype IPv4 (0x0800), length 150: (tos 0x0, ttl 114, id 44915, offset 0, flags [none], proto TCP (6), length 136) 10.16.112.99.60256 > 10.20.93.187.22: Flags [.], cksum 0xd1ea (correct), seq 3693:3789, ack 4721, win 3840, length 96 22:18:37.850533 00:08:e3:ff:fd:90 > 34:17:eb:b5:b5:57, ethertype IPv4 (0x0800), length 118: (tos 0x0, ttl 114, id 44920, offset 0, flags [none], proto TCP (6), length 104) 10.16.112.99.60256 > 10.20.93.187.22: Flags [P.], cksum 0x7c83 (correct), seq 3789:3853, ack 4721, win 3840, length 64 22:18:37.850554 34:17:eb:b5:b5:57 > 00:08:e3:ff:fd:90, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 64, id 35842, offset 0, flags [DF], proto TCP (6), length 40) 10.20.93.187.22 > 10.16.112.99.60256: Flags [.], cksum 0xe25c (incorrect -> 0x6489), ack 3853, win 309, length 0 22:18:37.851382 34:17:eb:b5:b5:57 > 00:08:e3:ff:fd:90, ethertype IPv4 (0x0800), length 214: (tos 0x48, ttl 64, id 35843, offset 0, flags [DF], proto TCP (6), length 200) 10.20.93.187.22 > 10.16.112.99.60256: Flags [P.], cksum 0xe2fc (incorrect -> 0x8767), seq 4721:4881, ack 3853, win 309, length 160 22:18:37.851515 34:17:eb:b5:b5:57 > 00:08:e3:ff:fd:90, ethertype IPv4 (0x0800), length 342: (tos 0x48, ttl 64, id 35844, offset 0, flags [DF], proto TCP (6), length 328) 10.20.93.187.22 > 10.16.112.99.60256: Flags [P.], cksum 0xe37c (incorrect -> 0xb328), seq 4881:5169, ack 3853, win 309, length 288 22:18:37.851570 34:17:eb:b5:b5:57 > 00:08:e3:ff:fd:90, ethertype IPv4 (0x0800), length 246: (tos 0x48, ttl 64, id 35845, offset 0, flags [DF], proto TCP (6), length 232) 10.20.93.187.22 > 10.16.112.99.60256: Flags [P.], cksum 0xe31c (incorrect -> 0x74ba), seq 5169:5361, ack 3853, win 309, length 192 22:18:37.854537 34:17:eb:b5:b5:57 > 00:08:e3:ff:fd:90, ethertype IPv4 (0x0800), length 118: (tos 0x48, ttl 64, id 35846, offset 0, flags [DF], proto TCP (6), length 104) 10.20.93.187.22 > 10.16.112.99.60256: Flags [P.], cksum 0xe29c (incorrect -> 0xdb54), seq 5361:5425, ack 3853, win 309, length 64 22:18:37.929327 34:17:eb:b5:b5:57 > 00:08:e3:ff:fd:90, ethertype IPv4 (0x0800), length 118: (tos 0x48, ttl 64, id 35847, offset 0, flags [DF], proto TCP (6), length 104) 10.20.93.187.22 > 10.16.112.99.60256: Flags [P.], cksum 0xe29c (incorrect -> 0xdb54), seq 5361:5425, ack 3853, win 309, length 64 22:18:38.141863 00:08:e3:ff:fd:90 > 34:17:eb:b5:b5:57, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 10177, offset 0, flags [none], proto TCP (6), length 40) 10.16.112.99.60256 > 10.20.93.187.22: Flags [R], cksum 0x2ae6 (correct), seq 3044012753, win 3840, length 0 Once I added 'IPQoS 0x00' into /etc/ssh/sshd_config, things are back in working order. I suspect that Palo Alto Network's Global Protect VPN our company uses for remote access is throwing away or corrupting packets with non-zero QoS. Unfortunately it seems that Global Protect VPN prevents wireshark from starting, so I do not have packet trace from client side. I'm not sure if there is anything that can be done on Debian/OpenSSH side, but maybe it will help someone else who suffers from same problem. Thanks, Petr Vandrovec
Bug#903153: nasm does not handle rdf2 output correctly due to incorrect use of pure_func
Package: nasm Version: 2.13.03-1 Hi, when I tried to switch to new nasm for one of our projects, nasm started panicking; nasm: panic: rdf segment numbers not allocated as expected (0,0,0) nasm code in question calls seg_alloc 3 times: segtext = seg_alloc(); segdata = seg_alloc(); segbss = seg_alloc(); if (segtext != 0 || segdata != 2 || segbss != 4) nasm_panic(0, "rdf segment numbers not allocated as expected (%d,%d,%d)", segtext, segdata, segbss); and seg_alloc returns consecutive even integers, so it should never happen that all three would be zeroes. Except that seg_alloc() is marked as pure_func, and so new gcc figures out that seg_alloc() returns constant, and so it can call it just once, and then assign returned value to all three variables :-( Simple fix below solves the problem. Petr Signed-off-by: Petr Vandrovec --- nasm-2.13.03/include/nasmlib.h 2018-02-07 13:40:15.0 -0800 +++ nasm-2.13.03.patched/include/nasmlib.h 2018-07-06 22:59:37.595561715 -0700 @@ -192,7 +192,7 @@ * seg_alloc: allocate a hitherto unused segment number. */ void pure_func seg_init(void); -int32_t pure_func seg_alloc(void); +int32_t seg_alloc(void); /* * many output formats will be able to make use of this: a standard
Bug#814287: Recent security fix for symlinks renders root filesystem exports unusable
Package: samba Version: 2:4.3.3+dfsg-1+b1 Severity: important Since I updated samba package to latest version, I cannot access my exports: == > net use w: \\petr-dev3\rootfs\bhavesh\home\petr /user:petr System error 5 has occurred. Access is denied. == It seems to me that there is a thinko in how export of '/' directory is handled, ending up with: check_reduced_name: Bad access attempt: bhavesh/home/petr is a symlink outside the share path conn_rootdir =/ resolved_name=/bhavesh/home/petr despite there being no symlinks involved, and /bhavesh/home/petr being inside / space. For now I've worked around the problem by setting follow symlinks = yes wide links = yes allow insecure wide links = yes but I do not think I should be forced to enable 'follow symlinks' to use symlink-less share. Petr [2016/02/09 13:11:33.139038, 5, pid=17936, effective(0, 0), real(0, 0)] ../source3/auth/token_util.c:639(debug_unix_user_token) UNIX token of user 884 Primary group is 201 and contains 20 supplementary groups Group[ 0]: 201 Group[ 1]: 0 Group[ 2]: 4 Group[ 3]: 5 Group[ 4]: 6 Group[ 5]: 7 Group[ 6]: 15 Group[ 7]: 20 Group[ 8]: 24 Group[ 9]: 25 Group[ 10]: 26 Group[ 11]: 27 Group[ 12]: 29 Group[ 13]: 44 Group[ 14]: 46 Group[ 15]: 50 Group[ 16]: 118 Group[ 17]: 1010 Group[ 18]: 1031 Group[ 19]: 104310 [2016/02/09 13:11:33.139074, 5, pid=17936, effective(884, 201), real(884, 0)] ../source3/smbd/uid.c:363(change_to_user_internal) Impersonated user: uid=(884,884), gid=(0,201) [2016/02/09 13:11:33.139081, 4, pid=17936, effective(884, 201), real(884, 0), class=vfs] ../source3/smbd/vfs.c:844(vfs_ChDir) vfs_ChDir to / [2016/02/09 13:11:33.139093, 4, pid=17936, effective(884, 201), real(884, 0), class=vfs] ../source3/smbd/vfs.c:855(vfs_ChDir) vfs_ChDir got / [2016/02/09 13:11:33.139102, 10, pid=17936, effective(884, 201), real(884, 0)] ../source3/smbd/smb2_create.c:501(smbd_smb2_create_send) smbd_smb2_create: name[bhavesh\home\petr] [2016/02/09 13:11:33.139110, 10, pid=17936, effective(884, 201), real(884, 0)] ../source3/smbd/smb2_create.c:932(smbd_smb2_create_send) smbd_smb2_create_send: open execution phase [2016/02/09 13:11:33.139121, 5, pid=17936, effective(884, 201), real(884, 0)] ../source3/smbd/filename.c:257(unix_convert) unix_convert called on file "bhavesh/home/petr" [2016/02/09 13:11:33.139129, 10, pid=17936, effective(884, 201), real(884, 0)] ../source3/smbd/statcache.c:244(stat_cache_lookup) stat_cache_lookup: lookup failed for name [BHAVESH/HOME/PETR] [2016/02/09 13:11:33.139136, 10, pid=17936, effective(884, 201), real(884, 0)] ../source3/smbd/statcache.c:244(stat_cache_lookup) stat_cache_lookup: lookup failed for name [BHAVESH/HOME] [2016/02/09 13:11:33.139141, 10, pid=17936, effective(884, 201), real(884, 0)] ../source3/smbd/statcache.c:244(stat_cache_lookup) stat_cache_lookup: lookup failed for name [BHAVESH] [2016/02/09 13:11:33.139148, 5, pid=17936, effective(884, 201), real(884, 0)] ../source3/smbd/filename.c:449(unix_convert) unix_convert begin: name = bhavesh/home/petr, dirpath = , start = bhavesh/home/petr [2016/02/09 13:11:33.139158, 5, pid=17936, effective(884, 201), real(884, 0)] ../source3/smbd/statcache.c:143(stat_cache_add) stat_cache_add: Added entry (56549fbbc990:size 11) BHAVESH/HOME/PETR -> bhavesh/home/petr [2016/02/09 13:11:33.139164, 5, pid=17936, effective(884, 201), real(884, 0)] ../source3/smbd/filename.c:472(unix_convert) conversion of base_name finished bhavesh/home/petr -> bhavesh/home/petr [2016/02/09 13:11:33.139171, 10, pid=17936, effective(884, 201), real(884, 0), class=vfs] ../source3/smbd/vfs.c:1147(check_reduced_name) check_reduced_name [bhavesh/home/petr] [/] [2016/02/09 13:11:33.139182, 10, pid=17936, effective(884, 201), real(884, 0), class=vfs] ../source3/smbd/vfs.c:1207(check_reduced_name) check_reduced_name realpath [bhavesh/home/petr] -> [/bhavesh/home/petr] [2016/02/09 13:11:33.139189, 2, pid=17936, effective(884, 201), real(884, 0), class=vfs] ../source3/smbd/vfs.c:1240(check_reduced_name) check_reduced_name: Bad access attempt: bhavesh/home/petr is a symlink outside the share path conn_rootdir =/ resolved_name=/bhavesh/home/petr [2016/02/09 13:11:33.139198, 5, pid=17936, effective(884, 201), real(884, 0)] ../source3/smbd/filename.c:1078(check_name) check_name: name bhavesh/home/petr failed with NT_STATUS_ACCESS_DENIED [2016/02/09 13:11:33.139204, 3, pid=17936, effective(884, 201), real(884, 0)] ../source3/smbd/filename.c:1431(filename_convert_internal) filename_convert_internal: check_name failed for name bhavesh/home/petr with NT_STATUS_ACCESS_DENIED petr-dev3:/bhavesh/home/petr/debian/samba-4.3.3+dfsg$ ls -lad / drwxr-xr-x 84 root root 4096 Aug 10 2015 / petr-dev3:/bhavesh/home/petr/debian/samba-4.3.3+dfsg$ ls -lad /bhavesh drwxr-xr-x 13 root root 4096 Jan 6 2014 /bhavesh
Bug#787489: Bug#787490: curl: VMWare doesn't start anymore
Hi Daniel, as workaround you can do LD_PRELOAD=/usr/lib/x86_64_linux-gnu/libssl.so.1.0.0 vmware to force use of system's openssl upon VMware Workstation. Workstation does not use libssl's APIs that changed binary compatibility between those two releases, so it should work reasonably until VMware Workstation moves to 1.0.2 too. Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739721: Unable to use NFS with systemd...
Hi, here too... Problem is not with mount/rpc.statd dependency - mount seems to start rpc.statd now whenever it needs. Problem is that systemd tries to mount NFS filesystems before portmap is started. portmap's init.d says that it needs $local_fs, and unfortunately as far as I can tell, systemd-fstab-generator treats remote filesystems exactly same as local, without any dependency on portmap or anything else, and without any configuration option that could explain to systemd that NFS filesystems need portmap. To get NFS to work I've added 'mkdir /run/rpcbind; /sbin/rpcbind -w' into my catch-all initscript that I run before systemd starts messing up things, as I could not figure out how to explain to systemd-fstab-generator that it must run rpcbind before doing any mounts. Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757835: nfs-kernel-server: after update 1.2.8-6-1.2.8-8 rpc.mountd starts crashing
Hi, it seems to be gcc bug. For inexplicable reason compiler optimized 'if (cp *cp)' to just 'if (*cp)' :-( Changing 'char *cp' to 'char * volatile cp' at line 468 in support/export/client.c is enough to explain to gcc that it has no idea what it is doing, and fixes the crash. I think that after code does 'strncpy(new, old, cp-old)' or 'new[cp-old] = 0' or 'if (cp != old *cp)' compiler believes 'cp' cannot be NULL, forgetting that both 'cp' and 'old' could have been NULL, making these expressions valid for NULL cp. Petr nfsworkaround.patch Description: Binary data
Bug#757835: nfs-kernel-server: after update 1.2.8-6-1.2.8-8 rpc.mountd starts crashing
amd64. I think it affects all architectures. In case you want to
follow-up, attached is minimum testcase I could come up with. It
crashes with gcc-4.9 and -O2. No crash with gcc-4.8, or at -O1.
$gcc-4.9 -W -Wall -O2 client.c ./a.out
Segmentation fault
$gcc-4.8 -W -Wall -O2 client.c ./a.out
$gcc-4.9 -W -Wall -O1 client.c ./a.out
$
Petr
On Mon, Aug 11, 2014 at 12:15 PM, Steve Langasek vor...@debian.org wrote:
On Mon, Aug 11, 2014 at 11:49:16AM -0700, Petr Vandrovec wrote:
Hi,
it seems to be gcc bug. For inexplicable reason compiler optimized
'if (cp *cp)' to just 'if (*cp)' :-(
Changing 'char *cp' to 'char * volatile cp' at line 468 in
support/export/client.c is enough to explain to gcc that it has no
idea what it is doing, and fixes the crash.
I think that after code does 'strncpy(new, old, cp-old)' or
'new[cp-old] = 0' or 'if (cp != old *cp)' compiler believes 'cp'
cannot be NULL, forgetting that both 'cp' and 'old' could have been
NULL, making these expressions valid for NULL cp.
Are you seeing this problem on i386 (like the original submitter), or do you
see this problem on a different architecture?
(If it's a compiler problem, this will be relevant to getting it fixed
properly.)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
char buf[100];
void
add_name(char *old)
{
char *cp = old;
while (cp *cp) {
cp++;
}
__builtin_strncpy(buf, old, cp-old);
if (cp != old) {
buf[0] = 'Q';
}
if (cp *cp) {
buf[0] = 'Q';
}
}
int main(void) {
add_name(0);
return 0;
}
Bug#756047: Switch to systemd causes my cron scripts to fail, filling all available disk space, rendering system unusable
Package: cron Version: 3.0pl1-124.1 systemd was forced on me yesterday - and while it took me 4 hours to get system back to boot (that's another story), I thought it is reasonably stable to survive during night. But today when I came to work, I found that my system crashed due to /tmp being full. Investigation revealed that under systemd cron - and everything spawned by cron - ignores SIGPIPE. So cron script doing: while true; do echo X=`getRandomNumber`; done | process10NumbersAndQuit now emits gazillion of: renew.sh: line 5: echo: write error: Broken pipe and never stops, which end up in /tmp in file where cron redirected stderr... Can you ensure that cron scripts are run in same environment under sysvinit and systemd? I know this script got broken in quite fatal way, but I have hundreds of other, and I did not find any cron option to not ignore SIGPIPE when starting children, and in shell it seems impossible to revert SIGPIPE to default handling if it was ignored when shell started. For now I've changed systemd to use cron's initscript rather than cron.service - that seems to do the trick. You can check it by creating script: while true; do echo x; done | head -1 When run under sysvinit started cron, it nicely stops after printing one 'x'. Under systemd started cron it generates infinite amount of stuff on stderr. Thanks, Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754914: python3.4-minimal/python cannot be installed when multiple libpython3.4 packages are present
Package: python3.4-minimal Version: 3.4.1-7 Severity: important Attempt to update python3.4-minimal package fails with failure: Setting up python3.4-minimal (3.4.1-7) ... # Empty sitecustomize.py to avoid a dangling symlink dpkg-query: error: --listfiles needs a valid package name but 'libpython3.4-minimal' is not: ambiguous package name 'libpython3.4-minimal' with more than one installed instance Use --help for help about querying packages. dpkg: error processing package python3.4-minimal (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuredion of python3.4: python3.4 depends on python3.4-minimal (= 3.4.1-7); however: Package python3.4-minimal is not configured yet. dpkg: error processing package python3.4 (--configure): dependency problems - leaving unconfigured E: Sub-process /usr/lib/dpkg returned an error code (1) 1st: I think that there is missing redirect of '# Empty sitecustomize.py ...' in python3.4-minimal.postinst, so it is printed on screen, rather than to the file, and 2nd: dpkg -L libpython3.4-minimal should be dpkg -L libpython3.4-minimal:$DPKG_MAINTSCRIPT_ARCH so that only one matching-architecture package is selected, rather than all architectures. Or perhaps make libpython3.4-minimal architecture-less? Same problem then exists in python3.4.postinst for libpython3.4-stdlib. dselect insists that I need both amd64 and i386 libpython3.4 packages to satisfy all dependencies of packages I have installed :-( Thanks, Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614018: PIE support for ltrace...
Hello,
attached is patch for ltrace 0.5.3 (from unstable) to add PIE
support. Just in case somebody is interested - upstream's current git
still does not grok PIE executables either.
Thanks,
Petr
diff -urN ltrace-0.5.3/breakpoints.c ltrace-0.5.3.pie/breakpoints.c
--- ltrace-0.5.3/breakpoints.c 2009-07-25 08:13:02.0 -0700
+++ ltrace-0.5.3.pie/breakpoints.c 2012-09-23 00:00:32.561719352 -0700
@@ -77,6 +77,22 @@
}
}
+static void
+parse_auxv(Process *proc) {
+ struct library_symbol *sym;
+ void *entry_point;
+ ptrdiff_t offset;
+
+ debug(DEBUG_FUNCTION, parse_auxv(pid=%d), proc-pid);
+ entry_point = get_entry_point(proc);
+ debug(1, Header entry point %lX, loaded %p\n, proc-e_entry,
entry_point);
+ offset = (uintptr_t)entry_point - proc-e_entry;
+ for (sym = proc-list_of_symbols; sym; sym = sym-next) {
+ sym-enter_addr += offset;
+ insert_breakpoint(proc, sym2addr(proc, sym), sym);
+ }
+}
+
void
enable_all_breakpoints(Process *proc) {
debug(DEBUG_FUNCTION, enable_all_breakpoints(pid=%d), proc-pid);
@@ -99,7 +115,10 @@
#endif
debug(1, Enabling breakpoints for pid %u..., proc-pid);
- if (proc-breakpoints) {
+ if (proc-need_to_relocate_breakpoints) {
+ proc-need_to_relocate_breakpoints = 0;
+ parse_auxv(proc);
+ } else if (proc-breakpoints) {
dict_apply_to_all(proc-breakpoints, enable_bp_cb,
proc);
}
@@ -198,9 +217,19 @@
} else {
proc-list_of_symbols = NULL;
}
- for (sym = proc-list_of_symbols; sym; sym = sym-next) {
- /* proc-pid==0 delays enabling. */
- insert_breakpoint(proc, sym2addr(proc, sym), sym);
+ /*
+* Only 386 x86_64 are tested, so use DYN-via-auxv only for them.
+* I think it works on other platforms too (as long as .plt is
+* in same segment as entry point), but there are some suspicious
+* mips and ppc ifdefs...
+*/
+ proc-need_to_relocate_breakpoints = proc-e_type == ET_DYN
+ (proc-e_machine == EM_386 || proc-e_machine == EM_X86_64);
+ if (!proc-need_to_relocate_breakpoints) {
+ for (sym = proc-list_of_symbols; sym; sym = sym-next) {
+ /* proc-pid==0 delays enabling. */
+ insert_breakpoint(proc, sym2addr(proc, sym), sym);
+ }
}
proc-callstack_depth = 0;
proc-breakpoints_enabled = -1;
diff -urN ltrace-0.5.3/common.h ltrace-0.5.3.pie/common.h
--- ltrace-0.5.3/common.h 2009-07-25 08:13:02.0 -0700
+++ ltrace-0.5.3.pie/common.h 2012-09-22 23:41:48.067146052 -0700
@@ -177,7 +177,10 @@
void * return_addr;
Breakpoint * breakpoint_being_enabled;
void * arch_ptr;
- short e_machine;
+ GElf_Half e_type;
+ GElf_Half e_machine;
+ GElf_Addr e_entry;
+ short need_to_relocate_breakpoints;
short need_to_reinitialize_breakpoints;
#ifdef __arm__
int thumb_mode; /* ARM execution mode: 0: ARM, 1: Thumb */
@@ -247,6 +250,7 @@
extern int umovelong (Process * proc, void * addr, long * result,
arg_type_info * info);
extern int ffcheck(void * maddr);
extern void * sym2addr(Process *, struct library_symbol *);
+extern void * get_entry_point(Process *);
#if 0 /* not yet */
extern int umoven(Process * proc, void * addr, int len, void * laddr);
diff -urN ltrace-0.5.3/elf.c ltrace-0.5.3.pie/elf.c
--- ltrace-0.5.3/elf.c 2009-07-25 08:13:02.0 -0700
+++ ltrace-0.5.3.pie/elf.c 2012-09-22 22:31:31.125049219 -0700
@@ -466,6 +466,8 @@
do_init_elf(lte, proc-filename);
proc-e_machine = lte-ehdr.e_machine;
+ proc-e_type = lte-ehdr.e_type;
+ proc-e_entry = lte-ehdr.e_entry;
for (i = 0; i library_num; ++i)
do_init_elf(lte[i + 1], library[i]);
#ifdef __mips__
diff -urN ltrace-0.5.3/sysdeps/README ltrace-0.5.3.pie/sysdeps/README
--- ltrace-0.5.3/sysdeps/README 2009-07-25 08:13:02.0 -0700
+++ ltrace-0.5.3.pie/sysdeps/README 2012-09-22 23:35:00.708248113 -0700
@@ -30,3 +30,4 @@
void trace_me(void);
int trace_pid(pid_t pid);
void untrace_pid(pid_t pid);
+void * get_entry_point(Process * proc);
diff -urN ltrace-0.5.3/sysdeps/linux-gnu/proc.c
ltrace-0.5.3.pie/sysdeps/linux-gnu/proc.c
--- ltrace-0.5.3/sysdeps/linux-gnu/proc.c 2009-07-25 08:13:02.0
-0700
+++ ltrace-0.5.3.pie/sysdeps/linux-gnu/proc.c 2012-09-23 00:07:26.420759968
-0700
@@ -1,6 +1,10 @@
#include config.h
+#include common.h
+
#include sys/types.h
+#include errno.h
+#include fcntl.h
#include stdio.h
#include string.h
#include
Bug#626418: Fwd: Re: Bug#626418 closed by Ondřej Surý ond...@debian.org (Bug#626418: fixed in cyrus-imapd-2.4 2.4.8-4)
Ondřej Surý wrote: I've dug somewhat deeper into the cyrus code and I'm going to remove the patch, because the Cyrus IMAPD bdb code is constantly opening/closing the database, so it would cause performance problems anyway. Thanks. Sorry for the regression. I will fix that as soon as perl has hit the testing... You can convert the affected database to (default) skiplist meanwhile. Well, I already converted them to skiplist - for whatever reason upgrading code to update from 2.3 to 2.4 was not able to upgrade my db files automatically, so I did it manually, and as cyrus-db-types.txt said skiplist everywhere, I converted them: petr-dev3:~$ cat /usr/lib/cyrus/cyrus-db-types.active ANNOTATION skiplist DBENGINE BerkeleyDB5.1 DUPLICATE skiplist MBOX skiplist PTS skiplist QUOTA quotalegacy SEEN skiplist STATUSCACHE skiplist SUBS flat TLS skiplist USERDENY flat Unfortunately even in this config cyrus still uses libdb for something... Petr O. On Thu, May 12, 2011 at 23:18, Petr Vandrovecp...@vmware.com wrote: Hello, most of crashes in -4 are gone, but still it seems that lmtpd/lmtpunix is dying: May 12 12:47:59 petr-dev3 cyrus/lmtpunix[2883]: DBERROR db5: DB_ENV-get_home: method not permitted before handle's open method May 12 12:47:59 petr-dev3 kernel: [ 7228.269495] lmtpd[2883]: segfault at 7f150002 ip 7f15980cddab sp 7fffe2ae6408 error 4 in lmtpd[7f1598069000+165000] May 12 12:47:59 petr-dev3 cyrus/master[18238]: process 2883 exited, signaled to death by 11 May 12 12:47:59 petr-dev3 cyrus/master[18238]: service lmtpunix pid 2883 in READY state: terminated abnormally And every now and then lmtpd is clearly not happy that environment was removed by someone else: May 12 12:48:17 petr-dev3 postfix/smtpd[13104]: connect from localhost.localdomain[127.0.0.1] May 12 12:48:18 petr-dev3 postfix/smtpd[13104]: 0B6CD5380CF: client=localhost.localdomain[127.0.0.1] May 12 12:48:18 petr-dev3 postfix/cleanup[13107]: 0B6CD5380CF: message-id=bug-711764-1305229695-15...@https.bugzilla.eng.vmware.com May 12 12:48:18 petr-dev3 postfix/qmgr[6643]: 0B6CD5380CF: from=bugzi...@vmware.com, size=3848, nrcpt=1 (queue active) May 12 12:48:18 petr-dev3 cyrus/master[13110]: about to exec /usr/lib/cyrus/bin/lmtpd May 12 12:48:18 petr-dev3 postfix/smtpd[13104]: disconnect from localhost.localdomain[127.0.0.1] May 12 12:48:18 petr-dev3 cyrus/lmtpunix[13110]: DBERROR db5: /var/lib/cyrus/db/__db.001: No such file or directory May 12 12:48:18 petr-dev3 cyrus/lmtpunix[13110]: DBERROR: dbenv-open '/var/lib/cyrus/db' failed: No such file or directory May 12 12:48:18 petr-dev3 cyrus/lmtpunix[13110]: DBERROR: init() on berkeley May 12 12:48:18 petr-dev3 cyrus/lmtpunix[13110]: DBERROR: reading /var/lib/cyrus/db/skipstamp, assuming the worst: No such file or directory May 12 12:48:18 petr-dev3 cyrus/lmtpunix[13110]: executed May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: skiplist: checkpointed /var/lib/cyrus/deliver.db (7985 records, 934500 bytes) in 1 second May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: skiplist: checkpointed /var/lib/cyrus/mailboxes.db (48 records, 3872 bytes) in 0 seconds May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: skiplist: checkpointed /var/lib/cyrus/annotations.db (0 records, 144 bytes) in 0 seconds May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: skiplist: checkpointed /var/lib/cyrus/statuscache.db (0 records, 144 bytes) in 0 seconds May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: accepted connection May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: lmtp connection preauth'd as postman May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: duplicate_check: bug-711764-1305229695-15...@https.bugzilla.eng.vmware.com user.petr.Bugzilla 0 May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: Delivered: bug-711764-1305229695-15...@https.bugzilla.eng.vmware.com to mailbox: user.petr.Bugzilla May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: duplicate_mark: bug-711764-1305229695-15...@https.bugzilla.eng.vmware.com user.petr.Bugzilla 1305229700 365145 May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: duplicate_mark: bug-711764-1305229695-15...@https.bugzilla.eng.vmware.com .petr+@.sieve. 1305229700 0 May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: USAGE petr user: 0.07 sys: 1.62 May 12 12:48:20 petr-dev3 postfix/lmtp[13109]: 0B6CD5380CF: to=petr@localhost, relay=petr-dev3.eng.vmware.com[/var/run/cyrus/socket/lmtp], delay=2.1, delays=0.14/0.03/1.9/0.05, dsn=2.1.5, status=sent (250 2.1.5 Ok SESSIONID=cyrus-13110-1305229700-1) May 12 12:48:20 petr-dev3 postfix/qmgr[6643]: 0B6CD5380CF: removed May 12 12:49:30 petr-dev3 cyrus/lmtpunix[13110]: DBERROR db5: DB_ENV-get_home: method not permitted before handle's open method May 12 12:49:30 petr-dev3 cyrus/lmtpunix[13110]: DBERROR: error exiting application: Invalid argument May 12 12:49:30 petr-dev3 cyrus/master[18238]: process 13110 exited, status 0
Bug#626418: Fwd: Re: Bug#626418 closed by Ondřej Surý ond...@debian.org (Bug#626418: fixed in cyrus-imapd-2.4 2.4.8-4)
Hello, most of crashes in -4 are gone, but still it seems that lmtpd/lmtpunix is dying: May 12 12:47:59 petr-dev3 cyrus/lmtpunix[2883]: DBERROR db5: DB_ENV-get_home: method not permitted before handle's open method May 12 12:47:59 petr-dev3 kernel: [ 7228.269495] lmtpd[2883]: segfault at 7f150002 ip 7f15980cddab sp 7fffe2ae6408 error 4 in lmtpd[7f1598069000+165000] May 12 12:47:59 petr-dev3 cyrus/master[18238]: process 2883 exited, signaled to death by 11 May 12 12:47:59 petr-dev3 cyrus/master[18238]: service lmtpunix pid 2883 in READY state: terminated abnormally And every now and then lmtpd is clearly not happy that environment was removed by someone else: May 12 12:48:17 petr-dev3 postfix/smtpd[13104]: connect from localhost.localdomain[127.0.0.1] May 12 12:48:18 petr-dev3 postfix/smtpd[13104]: 0B6CD5380CF: client=localhost.localdomain[127.0.0.1] May 12 12:48:18 petr-dev3 postfix/cleanup[13107]: 0B6CD5380CF: message-id=bug-711764-1305229695-15...@https.bugzilla.eng.vmware.com May 12 12:48:18 petr-dev3 postfix/qmgr[6643]: 0B6CD5380CF: from=bugzi...@vmware.com, size=3848, nrcpt=1 (queue active) May 12 12:48:18 petr-dev3 cyrus/master[13110]: about to exec /usr/lib/cyrus/bin/lmtpd May 12 12:48:18 petr-dev3 postfix/smtpd[13104]: disconnect from localhost.localdomain[127.0.0.1] May 12 12:48:18 petr-dev3 cyrus/lmtpunix[13110]: DBERROR db5: /var/lib/cyrus/db/__db.001: No such file or directory May 12 12:48:18 petr-dev3 cyrus/lmtpunix[13110]: DBERROR: dbenv-open '/var/lib/cyrus/db' failed: No such file or directory May 12 12:48:18 petr-dev3 cyrus/lmtpunix[13110]: DBERROR: init() on berkeley May 12 12:48:18 petr-dev3 cyrus/lmtpunix[13110]: DBERROR: reading /var/lib/cyrus/db/skipstamp, assuming the worst: No such file or directory May 12 12:48:18 petr-dev3 cyrus/lmtpunix[13110]: executed May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: skiplist: checkpointed /var/lib/cyrus/deliver.db (7985 records, 934500 bytes) in 1 second May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: skiplist: checkpointed /var/lib/cyrus/mailboxes.db (48 records, 3872 bytes) in 0 seconds May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: skiplist: checkpointed /var/lib/cyrus/annotations.db (0 records, 144 bytes) in 0 seconds May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: skiplist: checkpointed /var/lib/cyrus/statuscache.db (0 records, 144 bytes) in 0 seconds May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: accepted connection May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: lmtp connection preauth'd as postman May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: duplicate_check: bug-711764-1305229695-15...@https.bugzilla.eng.vmware.com user.petr.Bugzilla 0 May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: Delivered: bug-711764-1305229695-15...@https.bugzilla.eng.vmware.com to mailbox: user.petr.Bugzilla May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: duplicate_mark: bug-711764-1305229695-15...@https.bugzilla.eng.vmware.com user.petr.Bugzilla 1305229700 365145 May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: duplicate_mark: bug-711764-1305229695-15...@https.bugzilla.eng.vmware.com .petr+@.sieve. 1305229700 0 May 12 12:48:20 petr-dev3 cyrus/lmtpunix[13110]: USAGE petr user: 0.07 sys: 1.62 May 12 12:48:20 petr-dev3 postfix/lmtp[13109]: 0B6CD5380CF: to=petr@localhost, relay=petr-dev3.eng.vmware.com[/var/run/cyrus/socket/lmtp], delay=2.1, delays=0.14/0.03/1.9/0.05, dsn=2.1.5, status=sent (250 2.1.5 Ok SESSIONID=cyrus-13110-1305229700-1) May 12 12:48:20 petr-dev3 postfix/qmgr[6643]: 0B6CD5380CF: removed May 12 12:49:30 petr-dev3 cyrus/lmtpunix[13110]: DBERROR db5: DB_ENV-get_home: method not permitted before handle's open method May 12 12:49:30 petr-dev3 cyrus/lmtpunix[13110]: DBERROR: error exiting application: Invalid argument May 12 12:49:30 petr-dev3 cyrus/master[18238]: process 13110 exited, status 0 Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626418: All cyrus-imapd tools crash on exit
Package: cyrus-imapd-2.4 Version: 2.4.8-2 I've upgraded yesterday from imapd 2.3 to 2.4, and since then all my logs are full of SIGSEGVs from cyrus, and even simple tools like cvt_cyrusdb crash left right. Initially I've suspected that problem is that libsasl2 is linked against libdb4.8 while imapd against libdb5.1, causing confusion in closing database, but that's not root cause. Root cause is debian/patches/101-berkeley-db_remove-unused-environment.patch: this patch adds calls to dbenv-get_home dbenv-remove *AFTER* call to dbenv-close. So we have nice use-after-free, which reliably crashes with my glibc, because contents of dbenv is set to 0xDBDBDBDB on dbenv-close, and so dbenv-get_home jumps to 0xDBDBDBDBDBDBDBDBDBDB killing process. And even if it would not kill process, dbenv-remove documentation says that you cannot use dbenv handle which was already used to open something to call remove: you must create new fresh dbenv handle, and use that one to call dbenv-remove. Please revert 101-berkeley-db patch, or rework it to not crash... For now I've removed it from my local systems, and crashes are gone, and I can read my emails again. Thanks, Petr Vandrovec -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550153: /proc/kallsyms does not contain init_nfsd on 2.6.32-rc3
Package: nfs-kernel-server Version: 1:1.2.0-4 Hello, nfs-kernel-server startup script fails to start on my 2.6.32-rc3 with modular nfsd, saying that kernel does not support nfsd: petr-dev3:/usr/src/git/linux-2.6/fs/nfsd# /etc/init.d/nfs-kernel-server start Not starting NFS kernel daemon: no support in current kernel. ... (warning). Apparently init method is no longer listed with its name in exported symbols, most probably due to symbols in __init section being dropped. petr-dev3:/usr/src/git/linux-2.6/fs/nfsd# grep nfsd /proc/kallsyms | grep init a0382400 t svc_export_init [nfsd] a0383d60 t expkey_init [nfsd] a03aac38 b nfs4_init[nfsd] a039d4d0 t ent_init [nfsd] a039f1d0 t init_state [nfsd] a03bb1f0 b rec_dir_init [nfsd] a039e610 t nfsd_idmap_init [nfsd] a03871a0 t nfsd_stat_init [nfsd] a0386080 t nfsd_reply_cache_init[nfsd] a03991b0 t nfs4_state_init [nfsd] a0384760 t nfsd_export_init [nfsd] a037e520 t nfsd_racache_init[nfsd] a0385950 t nfsd_lockd_init [nfsd] a03a0560 t nfsd4_init_recdir[nfsd] Testing presence of /proc/fs/nfs/exports seems to work on that kernel - though I have no idea how far back (and into the future) that works... # See if our running kernel supports the NFS kernel server if [ ! -f /proc/fs/nfs/exports ]; then log_warning_msg Not starting $DESC: no support in current kernel. exit 0 fi Thanks, Petr Vandrovec -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545366: dselect 1.15.4 does not distinguish between new and old packages
Guillem Jover napsal(a): Hi! This increases the status file, the parsing and processing time when doing dependency resolutions and package iterations for everyone, and just to be able to show new packages on dselect. The correct solution here is not to revert the change, but to store the seen/not-seen information in another place, in a similar way as how apt/aptitude do it. And ideally in a unified place which all front-ends can share, so we avoid duplication. IMHO change should be reverted until old functionality can be achieved through some other way - unless you can achieve such functionality today. Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545366: dselect 1.15.4 does not distinguish between new and old packages
Raphael Hertzog napsal(a): On Sun, 06 Sep 2009, Petr Vandrovec wrote: You can use git bisect to isolate the problem more precisely. My bet would be on the code that auto-cleans up the status database, maybe it applies by error on the available file as well and thus it believes that all packages are new everytime? 224f0285abc304bec059e61447781... is first bad commit commit 224f0285... Author: Guillem Jover guil...@debian.org Date: Sun Jul 12 20:11:53 2009 +0200 Obsolete --forget-old-unavail On parse mark not-installed leftover packages for automatic removal from the database on next dump ... Closes: #94, #429262 And while we are on it, checkin 7fa96f35... (disable default automake paths) causes FTBFS on my box. Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545366: dselect 1.15.4 does not distinguish between new and old packages
Package: dselect Version: 1.15.4 Since today's update run dselect is completely confused and does not remember which packages are new and which are old - it lists all available and not installed packages as new, again and again. And not only that, it also marks some of them for installation although I do not want them (and some are not installable at all - for some reason it wants to install libsasl2 which is not installable together with libsasl2-2). I see that it updates available status, they seem to contain valid data, but on load it somehow ignores them. Besides that it creates some strange /var/lib/dpkg/updates/tmp.i which is full of lines saying '##padding', but other than that I do not see what can be wrong, and unfortunately diff between 1.15.3.1 and 1.15.4 is quite huge. Thanks, Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541171: smbd SIGSEGV when breaking oplocks
Package: samba
Version: 2:3.4.0-2+b1
Hello,
whenever I try to access same file from both Linux locally and from
XP remotely (for example building software from same tree, once on
Linux, once on Windows), samba commits suicide in oplocks code:
push_file_id_24 (buf=0x7fffdacbf2c0 \22\b, id=0x30) at lib/file_id.c:71
71 lib/file_id.c: No such file or directory.
in lib/file_id.c
(gdb) bt
#0 push_file_id_24 (buf=0x7fffdacbf2c0 \22\b, id=0x30) at
lib/file_id.c:71
#1 0x006fc295 in break_kernel_oplock (msg_ctx=0x1d1e500,
fsp=0x0) at smbd/oplock.c:43
#2 0x006d4f97 in tevent_common_check_signal (ev=0x1d1e440) at
../lib/tevent/tevent_signal.c:311
#3 0x006d34b5 in run_events (ev=0x7fffdacbf2c0, selrtn=-1,
read_fds=0x7fffdacbf4f0, write_fds=0x7fffdacbf470) at lib/events.c:89
#4 0x00509a23 in smbd_server_connection_loop_once () at
smbd/process.c:798
#5 smbd_process () at smbd/process.c:2151
#6 0x00943e95 in smbd_accept_connection (ev=value optimized
out, fde=value optimized out, flags=value optimized out,
private_data=value optimized out) at smbd/server.c:394
#7 0x006d35b6 in run_events (ev=0x1d1e440, selrtn=1,
read_fds=0x7fffdacbf8e0, write_fds=0x7fffdacbf860) at lib/events.c:126
#8 0x006d37ff in s3_event_loop_once (ev=0x1d1e440,
location=value optimized out) at lib/events.c:185
#9 0x006d3bdc in _tevent_loop_once (ev=0x1d1e440,
location=0xa78def smbd/server.c:680) at ../lib/tevent/tevent.c:478
#10 0x0094492d in smbd_parent_loop (argc=value optimized out,
argv=value optimized out) at smbd/server.c:680
#11 main (argc=value optimized out, argv=value optimized out) at
smbd/server.c:1250
tevent_common_check_signal invoked this tevent_signal:
(gdb) print *se
$3 = {prev = 0x0, next = 0x1cb8af0, event_ctx = 0x1d1e440, signum = 35,
sa_flags = 4, handler = 0x6fc8f0 linux_oplock_signal_handler,
private_data = 0x1d28060, handler_name = 0x9f4705
linux_oplock_signal_handler,
location = 0x9f46ed smbd/oplock_linux.c:210, additional_data =
0x1d37720}
For signal 35 it says:
(gdb) print i
$14 = 35
(gdb) print sig_state-signal_count[35]
$19 = {count = 27, seen = 25}
(gdb) print count
$20 = 2
So count was 2, and it matches with expected state. But code to call
handlers says:
for (j=0;jcount;j++) {
/* note the use of the sig_info array as a
ring buffer */
int ofs = ((count-1) + j) % SA_INFO_QUEUE_COUNT;
se-handler(ev, se, i, 1,
(void*)sig_state-sig_info[i][ofs],
se-private_data);
}
So for count=2 it will try to access elements (2-1)+0 = 1, and (2-1)+1 =
2. But elements 0 1 are ones which are valid:
(gdb) print sig_state-sig_info[35][0]._sifields._sigpoll.si_fd
$43 = 31
(gdb) print sig_state-sig_info[35][1]._sifields._sigpoll.si_fd
$44 = 32
(gdb) print sig_state-sig_info[35][2]._sifields._sigpoll.si_fd
$45 = 1918967843
I admit that I have troubles understanding what this code tries to do,
but as far as I can tell second index to sig_info[i][xxx] array should
be using some different indices.
As far as I can tell attached patch could do the trick. Unfortunately
Samba is FTBFS on my box (seems to be completely confused about talloc.h
libtalloc.so) so I could not even compile-test it...
Petr
diff -urN samba-3.4.0.orig/lib/tevent/tevent_signal.c
samba-3.4.0/lib/tevent/tevent_signal.c
--- samba-3.4.0.orig/lib/tevent/tevent_signal.c 2009-07-03 04:21:14.0
-0700
+++ samba-3.4.0/lib/tevent/tevent_signal.c 2009-08-11 20:50:35.0
-0700
@@ -32,8 +32,8 @@
#define NUM_SIGNALS 64
-/* maximum number of SA_SIGINFO signals to hold in the queue */
-#define SA_INFO_QUEUE_COUNT 100
+/* maximum number of SA_SIGINFO signals to hold in the queue. Must be power
of two. */
+#define SA_INFO_QUEUE_COUNT 64
struct sigcounter {
uint32_t count;
@@ -44,6 +44,9 @@
#define SIG_SEEN(s, n) (s).seen += (n)
#define SIG_PENDING(s) ((s).seen != (s).count)
+#define SIG_QUEUE_IDX(sig) (sig_state-signal_count[(sig)].count %
SA_INFO_QUEUE_COUNT)
+#define SIG_DEQUEUE_IDX(sig, idx) ((sig_state-signal_count[(sig)].seen +
(idx)) % SA_INFO_QUEUE_COUNT)
+
struct tevent_common_signal_list {
struct tevent_common_signal_list *prev, *next;
struct tevent_signal *se;
@@ -70,10 +73,7 @@
*/
static uint32_t sig_count(struct sigcounter s)
{
- if (s.count = s.seen) {
- return s.count - s.seen;
- }
- return 1 + (0x ~(s.seen - s.count));
+ return s.count - s.seen;
}
/*
@@ -97,7 +97,7 @@
void *uctx)
{
uint32_t count = sig_count(sig_state-signal_count[signum]);
- sig_state-sig_info[signum][count] = *info;
+ sig_state-sig_info[signum][SIG_QUEUE_IDX(signum)] = *info;
tevent_common_signal_handler(signum);
@@ -307,21 +307,11 @@
for
Bug#534903: ia32-apt-get+libmagick9 breaks dpkg
Package: ia32-apt-get Version: 18 Severity: important I've grabbed ia32-apt-get, ia32-libs, and ia32-libs-tools version 18, installed them, bumped apt-get's memory limit to 90MB, but unfortunately dpkg is still not quite happy: arch_all.list: deleting prelude-correlator amd64 arch_all.list: deleting python-osd amd64 arch_all.list: deleting rep-gtk-gnome amd64 Ignoring ftp.us.debian.org_debian_dists_squeeze_main_binary-i386_Packages.IndexDiff Ignoring ftp.us.debian.org_debian_dists_squeeze_non-free_binary-i386_Packages.IndexDiff Ignoring www.debian-multimedia.org_dists_sid_main_binary-i386_Packages.IndexDiff Merging ... Reading package lists... Done Merging available information Replacing available packages info, using /var/cache/apt/available. dpkg: parse error, in file '/var/cache/apt/available' near line 969216 package 'ia32-libmagick9': `Conflicts' field, reference to `ia32-libmagick5': version contains ` ' update available list script returned error exit status 2. Press enter to continue. Looking at line 969216, there is indeed a problem. Arguably it is problem in original package, as it has libmagick5 (= 4:5.5.1-1 ), but dpkg is apparently OK with trailing space, while it is not OK with space inside, like libmagick5 (= 4:5.5.1-1 ~18). Could you strip trailing spaces from version, or just ignore such record altogether (I won't miss not having 32bit libmagick9, while I do miss dpkg...) Maybe severity should be grave, as now dpkg is hosed here, dunno. Thanks, Petr Vandrovec i386 (line 9692xx): Package: ia32-libmagick9 Architecture: amd64 Version: 7:6.2.4.5.dfsg1-0.14~18 Conflicts: ia32-libmagick, ia32-libmagick-lzw, ia32-libmagick5g, imagemagick (= 5:6.0.1.2-1), ia32-libmagick5 (= 4:5.5.1-1 ~18), ia32-libmagick6.0.1, ia32-libs (= 3~~), ia32-libs-gtk (= 3~~) Depends: lib32bz2-1.0, libc6-i386 (= 2.3.6-6~18), ia32-libfreetype6 (= 2.2~18), ia32-libice6 (= 1:1.0.0~18), ia32-libjasper-1.701-1 (= 1.701.0~18), ia32-libjpeg62, ia32-liblcms1 (= 1.08-1~18), ia32-libpng12-0 (= 1.2.13-4~18), ia32-libsm6, ia32-libtiff4, ia32-libx11-6, ia32-libxext6, ia32-libxml2 (= 2.6.27~18), ia32-libxt6, lib32z1 (= 1:1.2.1~18) Pre-Depends: libc6-i386 (= 2.9-14) Replaces: ia32-libmagick, ia32-libmagick-lzw, ia32-libmagick5g, imagemagick (= 5:6.0.1.2-1), ia32-libmagick5 (= 4:5.5.1~18), ia32-libs (= 3~~), ia32-libs-gtk (= 3~~) Suggests: libwmf-bin Description: Image manipulation library LibMagick supports loading and saving a very large set of image formats. It allows a lot of image manipulation as well. Filename: pool/main/i/imagemagick/libmagick9_6.2.4.5.dfsg1-0.14_i386.deb Installed-Size: 4096 MD5sum: e87539ad99c97650c78f67458becc5c7 Maintainer: Ryuichi Arafune araf...@debian.org Priority: optional SHA1: c4b2bf234b0476cebf0f80a4013085941ae6f8d0 SHA256: 60de78e06739080c8becc5b0f802975a2fa94352731e2a02e8201375cf799a8d Section: libs Size: 1296246 Source: imagemagick (7:6.2.4.5.dfsg1-0.14) Tag: role::shared-lib amd64 (line 7082xx): Package: libmagick9 Priority: optional Section: libs Installed-Size: 4088 Maintainer: Ryuichi Arafune araf...@debian.org Architecture: amd64 Source: imagemagick Version: 7:6.2.4.5.dfsg1-0.14 Replaces: libmagick, libmagick-lzw, libmagick5g, imagemagick (= 5:6.0.1.2-1), libmagick5 (= 4:5.5.1) Depends: libbz2-1.0, libc6 (= 2.3.5-1), libfreetype6 (= 2.2), libice6 (= 1:1.0.0), libjasper-1.701-1 (= 1.701.0), libjpeg62, liblcms1 (= 1.08-1), libpng12-0 (= 1.2.13-4), libsm6, libtiff4, libx11-6, libxext6, libxml2 (= 2.6.27), libxt6, zlib1g (= 1:1.2.1) Suggests: libwmf-bin Conflicts: libmagick, libmagick-lzw, libmagick5g, imagemagick (= 5:6.0.1.2-1), libmagick5 (= 4:5.5.1-1 ), libmagick6.0.1 Filename: pool/main/i/imagemagick/libmagick9_6.2.4.5.dfsg1-0.14_amd64.deb Size: 1321620 MD5sum: 3cc8273f825aa359564a9e431cf628a5 SHA1: 91f3f8166ff6b4f3fad42c8dc7296fc5caf559e8 SHA256: 6baec1e2678525af15d1f33f8afb6cf191d4bdb40fd24651c4276f869bffcf42 Description: Image manipulation library LibMagick supports loading and saving a very large set of image formats. It allows a lot of image manipulation as well. Tag: role::shared-lib -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533636: defoma: remove /usr/bin PATH from debhelper scripts
Hideki Yamane wrote: Hi, On Sat, 20 Jun 2009 11:52:26 +0200 Petr Vandrovec p...@vandrovec.name wrote: please do not apply these patches. Apparently Hideki built recently uploaded ttf-kiloji, ttf-sawarabi-gothic, and ttf-dejima-mincho with these patches, and so they are not installable unless dpkg --configure --pending is started from /usr/bin: NO, that was caused by mistake, that is removing postinst and prerm script. And now it is okay, added to end of those scripts. Because postinst does this: #!/bin/sh set -e # Automatically added by dh_installdefoma FILE='/etc/defoma/hints/ttf-kiloji.hints' if [ $1 = configure ]; then test -x defoma-font defoma-font reregister-all $FILE fi # End automatically added section And -x defoma-font will fail if defoma-font is not in current directory. No, if path is set correctly, it is not a problem. Also as test is written now it causes breakage when defoma-font is not installed. I'm not sure that this is intentional. No, if defoma-font is executable it would be execute. Erm, which shell are you using? 2.1.0-9 is still broken. Not as badly as before, but still broken - reregister is not invoked at all during upgrades. Verify there is a kiloji... gwy:/# grep kiloji /var/lib/defoma/* | wc -l 341 341 of them. Great. Clear cache: gwy:/# defoma-font unregister-all /etc/defoma/hints/ttf-kiloji.hints No CIDSupplement specified for JamoNovel-Regular, defaulting to 0. No CIDSupplement specified for Yetgul-Regular, defaulting to 0. ... No CIDSupplement specified for Gulim-Regular, defaulting to 0. No CIDSupplement specified for Shinmun-Regular, defaulting to 0. Updating fontconfig cache for /usr/share/fonts/truetype/kiloji Indeed no kiloji: gwy:/# grep kiloji /var/lib/defoma/* | wc -l 0 Now let's reinstall package with pwd = '/': gwy:/# dpkg -i /mirrors/debian/pool/main/t/ttf-kiloji/ttf-kiloji_2.1.0-9_all.deb (Reading database ... 509169 files and directories currently installed.) Preparing to replace ttf-kiloji 1:2.1.0-9 (using .../ttf-kiloji_2.1.0-9_all.deb) ... Unpacking replacement ttf-kiloji ... Setting up ttf-kiloji (1:2.1.0-9) ... Processing triggers for fontconfig ... Hmm, that was quick. What about defoma? gwy:/# grep kiloji /var/lib/defoma/* | wc -l 0 Oops. No reinstall was run. Let's try again, from /usr/bin: gwy:/# cd /usr/bin gwy:/usr/bin# dpkg -i /mirrors/debian/pool/main/t/ttf-kiloji/ttf-kiloji_2.1.0-9_all.deb (Reading database ... 509169 files and directories currently installed.) Preparing to replace ttf-kiloji 1:2.1.0-9 (using .../ttf-kiloji_2.1.0-9_all.deb) ... Unpacking replacement ttf-kiloji ... Setting up ttf-kiloji (1:2.1.0-9) ... No CIDSupplement specified for Pen-Regular, defaulting to 0. No CIDSupplement specified for Headline-Regular, defaulting to 0. ... No CIDSupplement specified for Graphic-Bold, defaulting to 0. No CIDSupplement specified for Gulim-Regular, defaulting to 0. Updating fontconfig cache for /usr/share/fonts/truetype/kiloji Processing triggers for fontconfig ... Now this looks much better. What about defoma? gwy:/usr/bin# grep kiloji /var/lib/defoma/* | wc -l 341 Yup. No fonts unless installation is run from /usr/bin. If you do not believe these tests, you can put some 'print STDERR I was here.\n;' into /usr/bin/defoma to see that it is not run unless installation starts from /usr/bin. Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533636: defoma: remove /usr/bin PATH from debhelper scripts
Hello, please do not apply these patches. Apparently Hideki built recently uploaded ttf-kiloji, ttf-sawarabi-gothic, and ttf-dejima-mincho with these patches, and so they are not installable unless dpkg --configure --pending is started from /usr/bin: gwy:/# apt-get install --reinstall ttf-kiloji ttf-sawarabi-gothic ttf-dejima-mincho Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: gfortran-4.2 gfortran-4.3 libkexiv2-7 libcommons-compress-java libopenmpi-dev libopenmpi1.3 linux-headers-2.6.28-11 gfortran gobjc++-4.4 gobjc-4.4 libibverbs1 libibverbs-dev mpi-default-dev openmpi-common libv4l-dev Use 'apt-get autoremove' to remove them. 0 upgraded, 0 newly installed, 3 reinstalled, 0 to remove and 35 not upgraded. Need to get 0B/16.0MB of archives. After this operation, 0B of additional disk space will be used. Do you want to continue [Y/n]? (Reading database ... 508440 files and directories currently installed.) Preparing to replace ttf-sawarabi-gothic 20090610-2 (using .../ttf-sawarabi-gothic_20090610-2_all.deb) ... Unpacking replacement ttf-sawarabi-gothic ... Preparing to replace ttf-dejima-mincho 220-4 (using .../ttf-dejima-mincho_220-4_all.deb) ... Unpacking replacement ttf-dejima-mincho ... Preparing to replace ttf-kiloji 1:2.1.0-8 (using .../ttf-kiloji_1%3a2.1.0-8_all.deb) ... Unpacking replacement ttf-kiloji ... Processing triggers for fontconfig ... Setting up ttf-sawarabi-gothic (20090610-2) ... dpkg: error processing ttf-sawarabi-gothic (--configure): subprocess installed post-installation script returned error exit status 1 Setting up ttf-dejima-mincho (220-4) ... dpkg: error processing ttf-dejima-mincho (--configure): subprocess installed post-installation script returned error exit status 1 Setting up ttf-kiloji (1:2.1.0-8) ... dpkg: error processing ttf-kiloji (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: ttf-sawarabi-gothic ttf-dejima-mincho ttf-kiloji E: Sub-process /usr/bin/dpkg returned an error code (1) gwy:/# dpkg --configure --pending Setting up ttf-kiloji (1:2.1.0-8) ... dpkg: error processing ttf-kiloji (--configure): subprocess installed post-installation script returned error exit status 1 Setting up ttf-sawarabi-gothic (20090610-2) ... dpkg: error processing ttf-sawarabi-gothic (--configure): subprocess installed post-installation script returned error exit status 1 Setting up ttf-dejima-mincho (220-4) ... dpkg: error processing ttf-dejima-mincho (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: ttf-kiloji ttf-sawarabi-gothic ttf-dejima-mincho gwy:/# cd /usr/bin gwy:/usr/bin# dpkg --configure --pending Setting up ttf-kiloji (1:2.1.0-8) ... Setting up ttf-sawarabi-gothic (20090610-2) ... Setting up ttf-dejima-mincho (220-4) ... gwy:/usr/bin# Because postinst does this: #!/bin/sh set -e # Automatically added by dh_installdefoma FILE='/etc/defoma/hints/ttf-kiloji.hints' if [ $1 = configure ]; then test -x defoma-font defoma-font reregister-all $FILE fi # End automatically added section And -x defoma-font will fail if defoma-font is not in current directory. Also as test is written now it causes breakage when defoma-font is not installed. I'm not sure that this is intentional. Thanks, Petr Vandrovec -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533067: libc6-dev-i386 broken?
Aurelien Jarno wrote: There is no bug in libc6-dev-i386. In that case where are i386 libraries? libc6-dev-i386 contains only headers, so all attempts to build anything fail due to missing libc_nonshared.a, libc.so, libm.so, and others: gwy:/# dpkg -L libc6-dev-i386 /. /usr /usr/share /usr/share/doc /usr/share/doc/libc6-dev-i386 /usr/share/doc/libc6-dev-i386/copyright /usr/share/doc/libc6-dev-i386/changelog.Debian.gz /usr/include /usr/include/i486-linux-gnu /usr/include/gnu /usr/include/gnu/stubs-32.h /usr/include/sys /usr/include/sys/vm86.h /usr/include/sys/elf.h BTW, where is document saying that /emul is going away? I see this question repeated multiple times (f.e. in lib32z1 report), but no pointer to discussion or anything (and I cannot find anything on debian-devel either). Thanks, Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507659: sysstat: dies after HW upgrade
Hello,
so after digging around I've found a culprit. It is reallocation
code in open_ofile - when number of items in the file does not match one
collected, code goes and reallocates _buf0 with new size. But!
act[x]-nr value is shared with multiple activites, so all must be
reallocated (well, or one could remove this nr sharing - I have no idea
what purpose it serves).
Hack to get things to work on my box is attached.
On my box problem was caused by change in the number of network adapters
(activity 11 12 both share same nr[] index):
petr-dev3:/usr/src/debian/sysstat-9.0.1# valgrind ./sadc -F -L 1 1 -
==3127== Memcheck, a memory error detector.
==3127== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==3127== Using LibVEX rev 1884, a library for dynamic binary translation.
==3127== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==3127== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation
framework.
==3127== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==3127== For more details, rerun with: -v
==3127==
Init: Activity 0 reports count 5
Init: Activity 1 reports count 1
Init: Activity 2 reports count 257
Init: Activity 3 reports count 1
Init: Activity 4 reports count 1
Init: Activity 5 reports count 1
Init: Activity 6 reports count 1
Init: Activity 7 reports count 1
Init: Activity 8 reports count 1
Init: Activity 9 reports count 0
Init: Activity 10 reports count 11
Init: Activity 11 reports count 6
Init: Activity 12 reports count 6
Init: Activity 13 reports count 1
Init: Activity 14 reports count 1
Init: Activity 15 reports count 1
Init: Activity 16 reports count 1
Init: Activity 17 reports count 1
Init: Activity 18 reports count 1
Init: Activity 19 reports count 1
Init: Activity 20 reports count 1
Init: Activity 21 reports count 1
Init: Activity 22 reports count 1
Init: Activity 23 reports count 1
Init: Activity 24 reports count 1
Init: Activity 25 reports count 1
Init: Activity 26 reports count 1
Init: Activity 27 reports count 1
Init: Activity 28 reports count 1
Init: Activity 29 reports count 5
Reset: Activity 0 reports count 5
Reset: Activity 1 reports count 1
Reset: Activity 2 reports count 257
Reset: Activity 3 reports count 1
Reset: Activity 4 reports count 1
Reset: Activity 5 reports count 1
Reset: Activity 6 reports count 1
Reset: Activity 7 reports count 1
Reset: Activity 8 reports count 1
Reset: Activity 9 reports count 0
Reset: Activity 10 reports count 12
Reset: Activity 11 reports count 8
Reset: Activity 12 reports count 8
Reset: Activity 13 reports count 1
Reset: Activity 14 reports count 1
Reset: Activity 15 reports count 1
Reset: Activity 16 reports count 1
Reset: Activity 17 reports count 1
Reset: Activity 18 reports count 1
Reset: Activity 19 reports count 1
Reset: Activity 20 reports count 1
Reset: Activity 21 reports count 1
Reset: Activity 22 reports count 1
Reset: Activity 23 reports count 1
Reset: Activity 24 reports count 1
Reset: Activity 25 reports count 1
Reset: Activity 26 reports count 1
Reset: Activity 27 reports count 1
Reset: Activity 28 reports count 1
Reset: Activity 29 reports count 5
==3127==
==3127== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
==3127== malloc/free: in use at exit: 0 bytes in 0 blocks.
==3127== malloc/free: 87 allocs, 87 frees, 32,879 bytes allocated.
==3127== For counts of detected errors, rerun with: -v
==3127== All heap blocks were freed -- no leaks are possible.
petr-dev3:/usr/src/debian/sysstat-9.0.1#
Petr
--- sysstat-9.0.1/sadc.c.orig 2009-03-08 03:08:10.0 -0700
+++ sysstat-9.0.1/sadc.c2009-06-02 20:27:46.0 -0700
@@ -714,12 +714,17 @@ void open_ofile(int *ofd, char ofile[])
*/
goto append_error;
else {
+ int j;
+
/*
* Force number of items
(serial lines, network interfaces...)
* to that of the file, and
reallocate structures.
*/
*act[p]-nr = file_act.nr;
- SREALLOC(act[p]-_buf0, void,
act[p]-msize * *act[p]-nr);
+ for (j = 0; j NR_ACT; j++) {
+ if (act[p]-nr ==
act[j]-nr)
+
SREALLOC(act[j]-_buf0, void, act[j]-msize * *act[j]-nr);
+ }
}
}
/* Save activity sequence */
Bug#519774: libc6: causes many programs not to be able to resolve dns addresses
Hello,
it seems that DNS resolver is grossly confused, and sends
two DNS requests on same socket back to back (strace below is
from 'lynx http://www.jeep.com'). In first one DNS server
responded only to second packet sent by resolver, and resolve
failed (after that mdns was tried, and eventually lynx reported
error that www.jeep.com does not exist). In second one DNS
server responded only to first packet (in my tests I've never
seen DNS server responding to both requests), and although DNS
resolver still uselessly waited for 5 seconds, slowing web browsing
to being almost unusable, after that 5 seconds DNS resolver
declared success, and moved on.
My /etc/resolv.conf is:
gwy:~# cat /etc/resolv.conf
domain hsd1.ca.comcast.net.
search hsd1.ca.comcast.net.
nameserver 68.87.76.178
nameserver 68.87.78.130
nameserver 68.87.69.146
gwy:~#
It seems to be caused by __libc_res_nquery always sending both
T_A and T_ request when T_UNSPEC query is being sent, and
getting confused when only T_ reply arrives.
2008-05-10 Ulrich Drepper drep...@redhat.com
...
* resolv/res_query.c (__libc_res_nquery): Take two additional
parameters for second answer buffer. Handle
type=T_UNSPEC to mean look up IPv4 and IPv6.
Change all callers.
Sending only one reply seems to be property of Comcast's servers.
When I use DNS server 147.32.1.20 (which runs bind), I'm getting two
responses. I'll try talking to Comcast support, but I doubt they'll
have any idea what I'm talking about.
Petr
16469 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
16469 connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(68.87.76.178)}, 28) = 0
16469 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
16469 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
16469 gettimeofday({1237095720, 803573}, NULL) = 0
16469 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3,
revents=POLLOUT}])
16469 send(3, \30\223\1\0\0\1\0\0\0\0\0\0\3www\4jeep\3com\0\0\1\0\1,
30, MSG_NOSIGNAL) = 30
16469 poll([{fd=3, events=POLLIN|POLLOUT}], 1, 5000) = 1 ([{fd=3,
revents=POLLOUT}])
16469 send(3, \3503\1\0\0\1\0\0\0\0\0\0\3www\4jeep\3com\0\0\34\0\1,
30, MSG_NOSIGNAL) = 30
16469 gettimeofday({1237095720, 803994}, NULL) = 0
16469 poll([{fd=3, events=POLLIN}], 1, 4999) = 1 ([{fd=3,
revents=POLLIN}])
16469 ioctl(3, FIONREAD, [159]) = 0
16469 recvfrom(3,
\3503\201\200\0\1\0\2\0\1\0\0\3www\4jeep\3com\0\0\34\0\1\300\f...,
2048, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(68.87.76.178)}, [16]) = 159
16469 gettimeofday({1237095720, 831053}, NULL) = 0
16469 poll([{fd=3, events=POLLIN}], 1, 4972) = 0 (Timeout)
16469 close(3) = 0
17497 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
17497 connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(68.87.76.178)}, 28) = 0
17497 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
17497 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
17497 gettimeofday({1237096105, 330041}, NULL) = 0
17497 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3,
revents=POLLOUT}])
17497 send(3, 1\311\1\0\0\1\0\0\0\0\0\0\3www\4jeep\3com\0\0\1\0\1, 30,
MSG_NOSIGNAL) = 30
17497 poll([{fd=3, events=POLLIN|POLLOUT}], 1, 5000) = 1 ([{fd=3,
revents=POLLOUT}])
17497 send(3, \367\241\1\0\0\1\0\0\0\0\0\0\3www\4jeep\3com\0\0\34\0\1,
30, MSG_NOSIGNAL) = 30
17497 gettimeofday({1237096105, 330529}, NULL) = 0
17497 poll([{fd=3, events=POLLIN}], 1, 4999) = 1 ([{fd=3,
revents=POLLIN}])
17497 ioctl(3, FIONREAD, [117]) = 0
17497 recvfrom(3,
1\311\201\200\0\1\0\3\0\0\0\0\3www\4jeep\3com\0\0\1\0\1\300\f...,
2048, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(68.87.76.178)}, [16]) = 117
17497 gettimeofday({1237096105, 350551}, NULL) = 0
17497 poll([{fd=3, events=POLLIN}], 1, 4979) = 0 (Timeout)
17497 close(3) = 0
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515229: New dash has serious problems with waiting for spawned processes
Package: dash Version: 0.5.5.1-1 Severity: critical Hello, new dash has some serious problems with waiting on spawned processes, which completely breaks apt-move - at the end apt-move spawns pipe as shown below: p...@gwy:~$ cat /tmp/err 20768 tty4 S+ 0:00 \_ dash /usr/bin/apt-move sync 21840 tty4 S+ 0:00 \_ sort 21841 tty4 S+ 0:00 \_ awk -f /usr/share/apt-move/cmpbignum.awk -f /usr/share/apt-move/cmpversion.awk -f /usr/share/apt-move/getdist.awk -f /usr/share/apt-move/get2 21843 tty4 S+ 0:00 \_ sort 21844 tty4 D+ 0:00 \_ /usr/bin/awk -f /usr/share/apt-move/pkg1 /tmp/MOVE_lfwAkG/make_pkg_files-fifo1 /tmp/MOVE_lfwAkG/make_pkg_files-contents/unstable/main/binary-i386 21845 tty4 S+ 0:00 \_ gzip 21846 tty4 S+ 0:00 \_ tee dists/unstable/main/binary-i386/Packages /tmp/MOVE_lfwAkG/make_pkg_files-fifogz Once 'tee' completes, it starts consuming 100% CPU, and can be killed only by -9... p...@gwy:~$ cat /tmp/err2 20768 tty4 R+ 0:02 \_ dash /usr/bin/apt-move sync And strace shows that it is doing endless stream of calls to wait4(), waiting for someone who does not exist anymore: p...@gwy:~$ head -10 /tmp/err3 wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) p...@gwy:~$ I suspect that it could be same as bug 515064, but maybe not. In any case, as far as I can tell, severity should be critical as it breaks unrelated package (apt-move). Downgrading back to 0.5.4 fixes the problem. Thanks, Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492691: Does libopenusb-dev package actually work?
Package: libopenusb-dev
Version: 1.0.1-3
Hello,
I just tried to build some code against libopenusb-dev package, and
as far as I can tell, that's not going to work.
(1) openusb-config reports that I should link with -lusb. But if I do
that, I'm getting libusb 0.1, not openusb library, so link fails
complaining that none of openusb functions were present - no
openusb_init, no openusb_open_device, nothing. If I change link to use
-lopenusb -lpthread -ldl, then
(2) I get binary which can be built, but openusb_init immediately fails
trying to open /usr/lib/openusb_backend. Unfortunately linux.a is not
being shipped at all, and I have some doubts that library supports
static linux.a built by build process at all...
So I'm kind of lost. After rebuilding libopenusb with --enable-shared I
was awareded with linux.so, which after being dropped to
/usr/lib/openusb_backend seems to get things moving (modulo that
openusb_init() causes sigsegv somewhere in libdbus, but first things
first...). Is libopenusb really preferred API for new applications, as
documentation suggests?
Sample code attached - it most probably does not do anything useful, but
it should build, and should not crash before openusb_init() returns...
All tests were run on x86-64, with unstable updated as of 1 hour ago.
Thanks,
Petr
#include openusb.h
static struct openusb_request_handle rqIntr;
static openusb_intr_request_t rqIntrIntr;
static uint8_t buffer[8];
static int32_t
print_and_retry(openusb_request_handle_t rqh);
static void
initiate_intr_dumper(openusb_dev_handle_t dev)
{
int32_t err;
rqIntr.dev = dev;
rqIntr.interface = 0;
rqIntr.endpoint = 1;
rqIntr.type = USB_TYPE_INTERRUPT;
rqIntr.req.intr = rqIntrIntr;
rqIntr.cb = print_and_retry;
rqIntr.arg = NULL;
rqIntrIntr.interval = 10;
rqIntrIntr.payload = buffer;
rqIntrIntr.length = sizeof(buffer);
rqIntrIntr.timeout = 0;
rqIntrIntr.flags = 0;
rqIntrIntr.result.status = -1234;
rqIntrIntr.result.transferred_bytes = 0;
rqIntrIntr.next = NULL;
err = openusb_xfer_aio(rqIntr);
if (err != OPENUSB_SUCCESS) {
fprintf(stderr, Could not initiate INTR listening: %d\n, err);
}
}
static int32_t
print_and_retry(openusb_request_handle_t rqh)
{
printf(INTR transfer done, result %d, bytes %u\n,
rqIntrIntr.result.status, rqIntrIntr.result.transferred_bytes);
printf(RCVD: %02X %02X %02X %02X-%02X %02X %02X %02X\n,
buffer[0], buffer[1], buffer[2], buffer[3],
buffer[4], buffer[5], buffer[6], buffer[7]);
initiate_intr_dumper(rqIntr.dev);
return 0;
}
static void
abort_intr_dumper(void)
{
int32_t err;
err = openusb_abort(rqIntr);
if (err != OPENUSB_SUCCESS) {
fprintf(stderr, Abort failed: %d\n, err);
}
}
int
main(int argc, char* argv[])
{
int32_t err;
openusb_handle_t handle;
openusb_devid_t *devs;
uint32_t numDevs;
unsigned int instance = 0;
openusb_dev_handle_t dev;
openusb_ctrl_request_t ctrl;
openusb_request_handle_t done;
err = openusb_init(0, handle);
if (err != OPENUSB_SUCCESS) {
fprintf(stderr, Could not initialize USB: %d\n, err);
return 100;
}
openusb_coldplug_callbacks_done(handle);
openusb_set_default_timeout(handle, USB_TYPE_CONTROL, 1000);
openusb_set_default_timeout(handle, USB_TYPE_INTERRUPT, 0);
err = openusb_get_devids_by_vendor(handle, 0x187C, 0x0511, devs, numDevs);
if (err != OPENUSB_SUCCESS) {
fprintf(stderr, Could not enumerate devices: %d\n, err);
openusb_fini(handle);
return 99;
}
if (numDevs instance) {
fprintf(stderr, Could not find instace %u of fx (%u found)\n,
instance, numDevs);
openusb_free_devid_list(devs);
openusb_fini(handle);
return 98;
}
err = openusb_open_device(handle, devs[instance], USB_INIT_FAIL_FAST, dev);
if (err != OPENUSB_SUCCESS) {
fprintf(stderr, Could not open device: %d\n, err);
openusb_free_devid_list(devs);
openusb_fini(handle);
return 97;
}
openusb_free_devid_list(devs);
err = openusb_claim_interface(dev, 0, USB_INIT_FAIL_FAST);
if (err != OPENUSB_SUCCESS) {
fprintf(stderr, Could not claim interface: %d\n, err);
openusb_close_device(dev);
openusb_fini(handle);
return 96;
}
initiate_intr_dumper(dev);
ctrl.setup.bmRequestType = 0x21;
ctrl.setup.bRequest = 0x09;
ctrl.setup.wValue = 0x0200;
ctrl.setup.wIndex = 0x;
ctrl.payload = \x06\x00\x00\x00\x00\x00\x00\x00;
ctrl.length = 8;
ctrl.timeout = 1000;
ctrl.flags = 0;
ctrl.result.status = -1234;
ctrl.result.transferred_bytes = 1234;
ctrl.next = NULL;
err = openusb_ctrl_xfer(dev, 0, 0, ctrl);
if (err != OPENUSB_SUCCESS) {
fprintf(stderr, Failed to execute control request: %d\n, err);
} else {
printf(OK, result: status: %d, tb
Bug#463787: /etc/blkid.tab negates purpose of label-based mounts
Package: libblkid1 Version: 1.40.5-2 Hello, my box decides more or less randomly how attached disks should be named. So I'm using LABEL=xxx in /etc/fstab to identify filesystems. It worked great until today - now there is strange unwanted /etc/blkid.tab, which contains values from *previous* boot. Actually probably from first boot which occurred after latest e2fsprogs update. Which unfortunately completely breaks boot on my system - after system boots (fortunately boot disk is always /dev/sda, so system at least boots) I have to remove /etc/blkid.tab and then try 'mount -a' again: gwy:~# mount /vms6 mount: No medium found gwy:~# grep vms6 /etc/blkid.tab device DEVNO=0x0891 TIME=1202040213 LABEL=vms6 UUID=82a15e8d-bae0-4300-8329-dc89268a71c4 SEC_TYPE=ext2 TYPE=ext3/dev/.static/dev/sdj1/device gwy:~# rm /etc/blkid.tab gwy:~# mount /vms6 gwy:~# grep vms6 /etc/blkid.tab device DEVNO=0x0831 TIME=1202040663 LABEL=vms6 UUID=82a15e8d-bae0-4300-8329-dc89268a71c4 TYPE=ext3 SEC_TYPE=ext2/dev/sdd1/device gwy:~# cat /etc/fstab # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc procdefaults0 0 proc/debian-x64/proc procdefaults0 0 /dev/sda5 / ext3defaults,errors=remount-ro 0 1 /dev/sda6 noneswapsw 0 0 /dev/hda/media/cdrom0 udf,iso9660 user,noauto 0 0 none/selinuxselinuxfs noauto 0 0 /dev/sda1 /dos/d ntfsro,umask=0220 0 /dev/sda2 /dos/c ntfsro,nls=utf8,umask=022 0 0 LABEL=vms /vmsext3defaults,errors=remount-ro 0 1 LABEL=vms2 /vms2 ext3defaults,errors=remount-ro 0 1 LABEL=vms3 /vms3 ext3defaults,errors=remount-ro 0 1 LABEL=vms4 /vms4 ext3defaults,errors=remount-ro 0 1 LABEL=vms5 /vms5 ext3defaults,errors=remount-ro 0 1 LABEL=vms6 /vms6 ext3defaults,errors=remount-ro 0 1 LABEL=vms7 /vms7 ext3defaults,errors=remount-ro 0 1 none/proc/bus/usb usbfs defaults0 0 This boot /dev/sdj is USB floppy, while last time it was one of harddisks. Also for some reason sometime blkid decides to use /dev/.static/dev/X entries instead of /dev/X :-( It would be great if mounting by label could work again... (mount is 2.13.1-1, but to me it looks like libblkid's problem) Thanks, Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463787: /etc/blkid.tab negates purpose of label-based mounts
Theodore Tso wrote:
OK, can you try the following? Right after you boot, can you try
running this command, and let me know whether it returns the correct
information?
blkid -t LABEL=vms6
Or you don't have to reboot; try changing the device name at the end
of the line for vmm6, changing it to be something like this:
device DEVNO=0x0831 TIME=1202040663 LABEL=vms6 UUID=82a15e8d-bae0-4300-8329-dc89268a71c4
TYPE=ext3 SEC_TYPE=ext2/dev/sda5/device
(The above is all one line)
and then try the above line, and see whether you get the right
information.
Blkid has always done the right thing in this regard, and nothing has
changed here recently --- that's why I'm asking you what version of
e2fsprogs you upgraded from previously.
I'm wondering if the issue is that the kernel is taking longer to
autodetect your USB devices, so they simpler aren't showing up at
boot. If the above works after the boot process.
So I would try the following. Try corrupting /etc/blkid.tab so the
device information for vms6 is wrong, and then try the mount. If it
works, but it's not working at boot time, try adding a sleep 15 before
the mount -a command in the init scripts, and see if that fixes it...
It seems to have something to do with device nodes which do exists in
namespace, but returns an ENOMEDIUM on open (*). When I tried your
example, or /dev/sda5 0x805, or any other /dev/sd* node (/dev/sd* is
maintained by udev on my box), or non-existing node, or node which
reports ENXIO (/dev/.static/dev/sdk1, /dev/.static/dev/sdg5) everything
is fine.
But when I pointed entry to:
device DEVNO=0x0811 TIME=1202096532 LABEL=vms6
UUID=82a15e8d-bae0-4300-8329-dc89268a71c4
TYPE=ext3/dev/.static/dev/sdb1/device
(/dev/.static/dev/sdb1 is partition on device which returns ENOMEDIUM on
open)
it added correct line, but left incorrect in place as well. So blkid
now reports two results:
gwy:/home/petr# blkid -t LABEL=vms6
/dev/.static/dev/sdb1: LABEL=vms6
UUID=82a15e8d-bae0-4300-8329-dc89268a71c4 TYPE=ext3
/dev/sdg1: LABEL=vms6 UUID=82a15e8d-bae0-4300-8329-dc89268a71c4
TYPE=ext3
And monut reports 'No medium' - with either one or two lines in
blkid.tab (and while blkid adds correct entry, mount does not do anything).
I've attached strace blkid -t LABEL=vms6 output for case where there
was only bogus sdb1 entry in blkid.tab.
I suspect that problem is that volume in question was repartitioned
reformatted recently - apparently it took udev some time to create nodes
in /dev, so blkid somehow found devices in /dev/.static/dev/sdX1, and
that triggered ENOMEDIUM problems on next boot - as for udev /dev/sdX1
would not exist, and so blkid would notice.
(*) I've looked at sources, and blkid has special case for
ENXIO/ENOENT/ENODEV. For ENOMEDIUM it reports back returning
unverified data, and returns whatever it found in cache. I have no
idea what correct behavior should be - I'm sure in some cases users are
trying to mount drives without medium inside.
Petr
execve(/sbin/blkid, [blkid, -t, LABEL=vms6], [/* 31 vars */]) = 0
brk(0) = 0x954e000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf7f77000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=152329, ...}) = 0
mmap2(NULL, 152329, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7f51000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/libblkid.so.1, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\\0..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=33816, ...}) = 0
mmap2(NULL, 36684, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7f48000
mmap2(0xf7f5, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7) = 0xf7f5
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/libuuid.so.1, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \20\0\000..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=12656, ...}) = 0
mmap2(NULL, 15440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7f44000
mmap2(0xf7f47000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xf7f47000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/i686/cmov/libc.so.6, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260e\1..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1356196, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf7f43000
mmap2(NULL,
Bug#429619: openssh-server: password based authentication not working following upgrade
Hello, it is still not quite right. To work around 4.6p1-1 bug I enabled 'PasswordAuthenticaion yes' in sshd config file, and it worked great. But for 4.6p1-2 I'm prompted for password, and then thing crashes (Works fine with key based authentication): petr-dev3:/var/log# ssh localhost -l petr Password: Read from remote host localhost: Connection reset by peer Connection to localhost closed. petr-dev3:/var/log# tail auth.log Jun 21 17:50:28 petr-dev3 sshd[5445]: fatal: PAM: pam_setcred(): Permission denied Jun 21 17:50:41 petr-dev3 login[5411]: (pam_unix) session opened for user root by (uid=0) Jun 21 17:50:41 petr-dev3 login[5448]: ROOT LOGIN on 'tty1' Jun 21 17:56:21 petr-dev3 login[5412]: (pam_unix) session opened for user root by (uid=0) Jun 21 17:56:21 petr-dev3 login[5490]: ROOT LOGIN on 'tty2' Jun 21 17:56:56 petr-dev3 sshd[5496]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost.localdomain user=petr Jun 21 17:57:00 petr-dev3 sshd[5496]: Accepted keyboard-interactive/pam for petr from 127.0.0.1 port 53393 ssh2 Jun 21 17:57:00 petr-dev3 sshd[5499]: (pam_unix) session opened for user petr by (uid=0) Jun 21 17:57:00 petr-dev3 sshd[5499]: fatal: PAM: pam_setcred(): Permission denied Jun 21 17:57:00 petr-dev3 sshd[5499]: (pam_unix) session closed for user petr petr-dev3:/var/log# After I put 'PasswordAuthentication no' back into sshd config file, things look better... (though I do not understand how PAM can work without PasswordAuthentication, as server definitely needs my cleartext password to be able to send it to PAM...) Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428937: ncpfs: FTBFS: ncpm_common.c:1229: error: expected expression before 'struct'
Lucas Nussbaum wrote: During a rebuild of all packages in sid, your package failed to build on i386. Fix below should fix problem. Probably time to release ncpfs-2.2.7, it looks really bad that there is 2000+ warnings in the build. Petr ncpm_common.c: In function 'process_connection': ncpm_common.c:1229: error: expected expression before 'struct' make[2]: *** [ncpm_common.o] Error 1 diff -urN sutil.x/ncpm_common.c sutil/ncpm_common.c --- sutil.x/ncpm_common.c 2007-06-15 01:14:28.0 -0700 +++ sutil/ncpm_common.c 2007-06-15 01:12:30.0 -0700 @@ -85,6 +85,7 @@ #include stdio.h #include string.h #include signal.h +#include stddef.h #include pwd.h #include grp.h #include ncp/ext/socket.h diff -urN sutil.x/ncpm_common.c sutil/ncpm_common.c --- sutil.x/ncpm_common.c 2007-06-15 01:14:28.0 -0700 +++ sutil/ncpm_common.c 2007-06-15 01:12:30.0 -0700 @@ -85,6 +85,7 @@ #include stdio.h #include string.h #include signal.h +#include stddef.h #include pwd.h #include grp.h #include ncp/ext/socket.h
Bug#423600: gphoto 2.3.1 kills Olympus C-3000 ZOOM
Package: libgphoto2-port0 Version: 2.3.1-5 Tags: patch Hello, for about month and half I was not able to download pictures from my camera to my Linux box. Today I finally took a look at what's different between 2.2.1 and 2.3.1, and found that some hack for some other Microsoft hack (MTP) was added to the library, and that it is what is breaking my Olympus. Problem is that MTP's attempt to read string descriptor 0xEE from this camera apparently crashes its firmware, as this request returns with -EPIPE, and device is gone from lsusb or any other listing until it is powercycled. I guess that lot of other devices will be affected as well, but as I have only this camera, here I go. Definitely better solution would be just first probe for devices by vendor/device ID, and after that do class-based searches (especially these violating USB spec). Unfortunately it does not seem doable with current libgphoto infrastructure. Thanks, Petr Vandrovec diff -urN libgphoto2-2.3.1/libgphoto2_port/usb/libusb.c libgphoto2-2.3.1.fixed/libgphoto2_port/usb/libusb.c --- libgphoto2-2.3.1/libgphoto2_port/usb/libusb.c 2006-11-25 06:47:35.0 -0800 +++ libgphoto2-2.3.1.fixed/libgphoto2_port/usb/libusb.c 2007-05-13 02:13:20.0 -0700 @@ -671,6 +671,10 @@ int ret,i,i1,i2; usb_dev_handle *devh; + /* If string descriptor 0xEE is read from Olympus C-3000 ZOOM, it dies. */ + if (dev-descriptor.idVendor == 0x07B4 dev-descriptor.idProduct == 0x0100) + return 0; + /* All of them are vendor specific device class */ #if 0 if ((dev-descriptor.bDeviceClass!=0xff) (dev-descriptor.bDeviceClass!=0)) diff -urN libgphoto2-2.3.1/libgphoto2_port/usb/libusb.c libgphoto2-2.3.1.fixed/libgphoto2_port/usb/libusb.c --- libgphoto2-2.3.1/libgphoto2_port/usb/libusb.c 2006-11-25 06:47:35.0 -0800 +++ libgphoto2-2.3.1.fixed/libgphoto2_port/usb/libusb.c 2007-05-13 02:13:20.0 -0700 @@ -671,6 +671,10 @@ int ret,i,i1,i2; usb_dev_handle *devh; + /* If string descriptor 0xEE is read from Olympus C-3000 ZOOM, it dies. */ + if (dev-descriptor.idVendor == 0x07B4 dev-descriptor.idProduct == 0x0100) + return 0; + /* All of them are vendor specific device class */ #if 0 if ((dev-descriptor.bDeviceClass!=0xff) (dev-descriptor.bDeviceClass!=0))
Bug#393530: [PATCH] Use dpkg --compare-versions for version compare
Hello,
so this is what I've done to my apt-move to get openoffice (and couple of
other packages it seems...) right. During apt-move run on my box cmpversion is
invoked about 12000 times - fortunately 11800 of them is for matching
source target, so for them we can take shortcut of not executing dpkg.
For remaining 200 we have...
Unfortunately I was not able to find apt's equivalent for dpkg
--compare-versions,
so probably patch is not OK for upstream, as it won't work on RPM based apt.
But it might be fine for Debian/Ubuntu.
I'm not awk expert, so I just hope that there is no special quoting needed
around a/b arguments to dpkg. If there is, then I'm sorry, but I have no
clue how it should look like.
Thanks,
Petr Vandrovec
diff -urN apt-move-4.2.26.post-sign/apt-move apt-move-4.2.26/apt-move
--- apt-move-4.2.26.post-sign/apt-move 2006-11-05 15:11:05.0 -0800
+++ apt-move-4.2.26/apt-move2006-11-05 19:04:15.0 -0800
@@ -72,7 +72,7 @@
FETCH=/usr/lib/apt-move/fetch # crappy replacement for apt-get
SCRIPTS=$APTMOVE_SCRIPTS
: ${SCRIPTS:=/usr/share/apt-move}
-awk=awk -f $SCRIPTS/cmpbignum.awk -f $SCRIPTS/cmpversion.awk -f
+awk=awk -f $SCRIPTS/cmpversion.awk -f
awk=$awk $SCRIPTS/getdist.awk -f
MOVE3=$SCRIPTS/move3
MOVE4=$awk $SCRIPTS/move4
diff -urN apt-move-4.2.26.post-sign/cmpbignum.awk apt-move-4.2.26/cmpbignum.awk
--- apt-move-4.2.26.post-sign/cmpbignum.awk 2002-01-25 00:47:24.0
-0800
+++ apt-move-4.2.26/cmpbignum.awk 1969-12-31 16:00:00.0 -0800
@@ -1,35 +0,0 @@
-# cmpbignum --- compare two arbitrarily long integers.
-# The function returns:
-# 0 if a b
-# == 0 if a == b
-# 0 if a b
-# The idea came from Anthony Towns in http://bugs.debian.org/92839.
-#
-# Copyright (c) 2001 Herbert Xu [EMAIL PROTECTED]
-# $Id: cmpbignum.awk,v 1.1 2002/01/25 08:47:24 herbert Exp $
-
-function cmpbignum(a, b, i, j, k, l, d) {
- i = match(a, /[^0]/)
- j = match(b, /[^0]/)
- if (!i || !j) {
- return !!i - !!j
- }
-
- k = length(a)
- l = length(b)
- d = (k - i) - (l - j)
- if (d) {
- return d
- }
-
- do {
- d = substr(a, i, 1) - substr(b, j, 1)
- if (d) {
- return d
- }
- i++
- j++
- } while (i = k)
-
- return 0
-}
diff -urN apt-move-4.2.26.post-sign/cmpversion.awk
apt-move-4.2.26/cmpversion.awk
--- apt-move-4.2.26.post-sign/cmpversion.awk2002-10-28 23:59:41.0
-0800
+++ apt-move-4.2.26/cmpversion.awk 2006-11-05 19:08:11.0 -0800
@@ -1,128 +1,20 @@
# cmpversion --- compare versions of Debian packages.
-# The function returns:
-# 0 if a b
-# == 0 if a == b
-# 0 if a b
-# This function depends on cmpbignum.
+# The function compares two versions and returns TRUE if
+# a b and operator is ne, lt, or le.
+# a == b and operator is eq, le, or ge.
+# a b and operator is ne, gt, or ge.
#
# Copyright (c) 2001 Herbert Xu [EMAIL PROTECTED]
# $Id: cmpversion.awk,v 1.2 2002/10/29 07:59:41 herbert Exp $
-function _cmpversion_segment(a, b, i, j, k, l, m, n, p, q, d) {
- k = length(a)
- l = length(b)
-
- while (k 0 l 0) {
- i = match(a, /[0-9]/)
- if (!i) {
- i = k + 1
- }
- j = match(b, /[0-9]/)
- if (!j) {
- j = l + 1
- }
-
- m = 1
- n = 1
- while (m i n j) {
- p = substr(a, m, 1)
- q = substr(b, n, 1)
- d = (q ~ /[A-Za-z]/) - (p ~ /[A-Za-z]/)
- if (d) {
- return d
- }
- if (p != q) {
- return p q ? -1 : 1
- }
- m++
- n++
- }
-
- d = (m i) - (n j)
- if (d) {
- return d
- }
-
- a = substr(a, i)
- b = substr(b, j)
- k -= i - 1
- l -= j - 1
- if (k = 0 || l = 0) {
- break
- }
-
- i = match(a, /[^0-9]/)
- if (!i) {
- i = k + 1
- }
- j = match(b, /[^0-9]/)
- if (!j) {
- j = l + 1
- }
-
- d = cmpbignum(substr(a, 1, i - 1), substr(b, 1, j - 1))
- if (d) {
- return d
- }
-
- a = substr(a, i
Bug#320827: No archive signing since last apt-move update...
reopen 320827 thanks Hello Chuan-kai, hello Herbert, it seems that patch for signing archive was not included upstream, so we lost it on last apt-move update :-( Can you reinstate it, my apt-get otherwise complains that local archive is unsigned and does not want to touch it... Thanks, Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327867: Bug 327867: apt-move sync downloads *.tar.gz which I already have on CD-ROM
Hi Richard, I've finally looked at your apt-move.conf co. Can you replace security.debian.org with '/all/' ? Also you are using accessing CD by their label. I do not believe that in batch mode apt-move uses you can do that. You should copy all CDs somewhere and then tell to apt-get that CDs are in http://localhost/firstcd, .../secondcd, ... - I think that this way it will pick up *.orig.tar.gz from local file. Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394600: apt-move has new upstream version for almost year
Package: apt-move Version: 4.2.24-1.1 For almost year apt-move has upstream version 4.2.26. Would it be possible to get that version to Debian? Besides other problems it fixes apt-move behavior when retrieving source packages, which is half of bug 327867. Thanks, Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393530: Openoffice versioning breaks apt-move
Package: apt-move
Version: 4.2.24-1.1
Hi,
openoffice.org packages use (in violation of chapter 5.6.12 of Debian
policy, see
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version)
version number 2.0.4~rc3-1 and 2.0.4-1, hoping that 2.0.4~rc3 is below
2.0.4 - which surprisingly is for apt and dpkg, but not for apt-move.
Perhaps this should be reported as openoffice's policy violation, but
as damage was already done it would be nice if apt-move's
/usr/share/apt-move/cmpversion.awk could be modified so it orders
2.0.4~rc3 below 2.0.4. Currently apt-move just downloads openoffice
packages tarballs (of version 2.0.4) and then throws them away because
repository already contains newer (2.0.4~rc3) version.
I've used hack below to teach apt-move how to order openoffice, but it
most probably fails for lot of other corner cases. Perhaps spawning
dpkg --compare-versions is right thing to do. Hack below is definitely
not OK for world wide use, it may eat your repository...
Thanks,
Petr Vandrovec
--- cmpversion.awk 2002-10-28 23:59:41.0 -0800
+++ /usr/share/apt-move/cmpversion.awk 2006-10-16 10:20:17.0 -0700
@@ -26,8 +26,14 @@
n = 1
while (m i n j) {
p = substr(a, m, 1)
+ if (p == ~) {
+ p = !
+ }
q = substr(b, n, 1)
- d = (q ~ /[A-Za-z]/) - (p ~ /[A-Za-z]/)
+ if (q == ~) {
+ q = !;
+ }
+ d = (p ~ /[A-Za-z]/) - (q ~ /[A-Za-z]/)
if (d) {
return d
}
@@ -71,6 +77,18 @@
l -= j - 1
}
+ if (k = 0) {
+ a = 0;
+ }
+ if (l = 0) {
+ b = 0;
+ }
+ a = substr(a, 1, 1);
+ b = substr(b, 1, 1);
+ d = (b ~ /~/) - (a ~ /~/);
+ if (d) {
+ return d;
+ }
return (k 0) - (l 0)
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392724: dselect 1.13.23 crash on strlen(NULL)
Package: dselect Version: 1.13.23 Hi, apparently latest dselect update is not completely happy on my box. It crashes because somebody calls strlen(NULL) when trying to open dselect's [S]elect. It was working fine before update (hour ago). Thanks, Petr Vandrovec dselect[3737]: segfault at rip f7d382b3 rsp ff9f352c error 4 debian:~# gdb /usr/bin/dselect core GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu...(no debugging symbols found) Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. warning: Can't read pathname for load map: Input/output error. Reading symbols from /lib/libncurses.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/tls/i686/cmov/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libc.so.6 Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libdl.so.2 Reading symbols from /lib/ld-linux.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.3.6.so... (no debugging symbols found)...done. (no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 warning: Lowest section in system-supplied DSO at 0xe000 is .hash at e0b4 (no debugging symbols found) Core was generated by `dselect'. Program terminated with signal 11, Segmentation fault. #0 0xf7d382b3 in strlen () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xf7d382b3 in strlen () from /lib/tls/i686/cmov/libc.so.6 #1 0x08055d0a in operator new () #2 0x08052298 in operator new () #3 0x0805267c in operator new () #4 0x0804e25f in operator new () #5 0x0804dfa2 in operator new () #6 0x0804e1b5 in operator new () #7 0xf7ce1ea8 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #8 0x0804aa81 in ?? () (gdb) x /10i $eip 0xf7d382b3 strlen+51: mov(%eax),%ecx 0xf7d382b5 strlen+53: mov$0xfefefeff,%edx 0xf7d382ba strlen+58: add%ecx,%edx 0xf7d382bc strlen+60: jae0xf7d38317 strlen+151 0xf7d382be strlen+62: xor%ecx,%edx 0xf7d382c0 strlen+64: or $0xfefefeff,%edx 0xf7d382c6 strlen+70: inc%edx 0xf7d382c7 strlen+71: jne0xf7d38317 strlen+151 0xf7d382c9 strlen+73: mov0x4(%eax),%ecx 0xf7d382cc strlen+76: mov$0xfefefeff,%edx (gdb) info registers eax0x0 0 ecx0x0 0 edx0x0 0 ebx0x0 0 esp0xff9f352c 0xff9f352c ebp0xff9f3568 0xff9f3568 esi0xff9f35a4 -6343260 edi0xff9f3550 -6343344 eip0xf7d382b3 0xf7d382b3 strlen+51 eflags 0x10246 [ PF ZF IF RF ] cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x63 99 (gdb) debian:~# cat /etc/apt/sources.list deb file:/mirrors/debian unstable main contrib non-free #deb file:/mirrors/debian unstable/non-US main deb-src file:/mirrors/debian unstable main contrib non-free #deb-src file:/mirrors/debian unstable/non-US main deb http://petr-dev3.eng.vmware.com/debian unstable main contrib non-free deb-src http://petr-dev3.eng.vmware.com/debian unstable main contrib non-free #deb cdrom:[Debian GNU/Linux 3.0 r2 _Woody_ - Official i386 Binary-1 (20031201)]/ unstable contrib main non-US/contrib non-US/main #deb http://master/debian unstable main contrib non-free #deb http://master/debi2 unstable main contrib non-free deb http://www.debian-multimedia.org/ sid main deb http://ftp.cz.debian.org/debian sid main contrib non-free deb http://ftp.debian.org/debian sid main contrib non-free #deb-src http://master/debian unstable main contrib non-free #deb-src http://master/debi2 unstable main contrib non-free deb-src http://www.debian-multimedia.org/ sid main deb-src http://ftp.cz.debian.org/debian sid main contrib non-free deb-src http://ftp.debian.org/debian sid main contrib non-free # deb http://non-us.debian.org/debian-non-US woody/non-US main contrib # non-free # deb http://security.debian.org/ stable/updates main debian:~# -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject
Bug#383194: fbtv does not work correctly on radeonfb
Package: fbtv
Version: 3.95-1
Tags: patch
Hello,
this patch fixes 4 problems with fbtv I've observed with radeonfb:
(1) Fixes to support 15bpp depth in v4l-conf. d-bpp must be used to
distinguish between 24 and 32 RGB888 formats, but d-depth must
be used to distinguish between RGB555 and RGB565.
(2) When switching terminals fbtv forgets to reload palette.
(3) Clearing 256MB of videoram is dog slow. It is better to just clear
visible area - which is usually 10-100 times smaller.
(4) On atyfb FBIOGETCMAP returns (in 15/16bpp) returns cmap with 256
entries, but when this cmap is programmed back it returns EINVAL
when cmap length is over 32 (or over 64 for 16bpp). Fortunately
first 32/64 entries are programmed anyway, so we can just ignore
EINVAL returned from FBIOPUTCMAP.
Thanks,
Petr Vandrovec
diff -urN xawtv-3.95.dist/console/fbtools.c xawtv-3.95/console/fbtools.c
--- xawtv-3.95.dist/console/fbtools.c 2003-02-14 15:14:04.0 +0100
+++ xawtv-3.95/console/fbtools.c2006-08-15 16:07:29.0 +0200
@@ -447,7 +447,7 @@
fb_activate_current(tty);
/* cls */
-fb_memset(fb_mem+fb_mem_offset,0,fb_fix.smem_len);
+fb_memset(fb_mem+fb_mem_offset,0,fb_var.yres * fb_fix.line_length);
return fb;
err:
@@ -458,15 +458,33 @@
void
fb_cleanup(void)
{
+struct fb_var_screeninfo var;
+
/* restore console */
+if (0 == ioctl(fb,FBIOGET_VSCREENINFO,var)) {
+ if (!memcmp(var, fb_ovar, sizeof(var))) {
+ goto skip_var;
+ }
+}
if (-1 == ioctl(fb,FBIOPUT_VSCREENINFO,fb_ovar))
perror(ioctl FBIOPUT_VSCREENINFO);
+skip_var:
if (-1 == ioctl(fb,FBIOGET_FSCREENINFO,fb_fix))
perror(ioctl FBIOGET_FSCREENINFO);
if (fb_ovar.bits_per_pixel == 8 ||
fb_fix.visual == FB_VISUAL_DIRECTCOLOR) {
- if (-1 == ioctl(fb,FBIOPUTCMAP,ocmap))
- perror(ioctl FBIOPUTCMAP);
+ if (-1 == ioctl(fb,FBIOPUTCMAP,ocmap)) {
+/*
+ * radeonfb in 15/16bpp returns EINVAL when color
+ * map retrieved by FBIOGETCMAP is programmed back
+ * by FBIOPUTCMAP. It still programs palette
+ * correctly, just instead of ignoring items 64-255
+ * it returns an error.
+ */
+ if (errno != EINVAL) {
+ perror(ioctl FBIOPUTCMAP);
+ }
+ }
}
close(fb);
diff -urN xawtv-3.95.dist/console/fbtv.c xawtv-3.95/console/fbtv.c
--- xawtv-3.95.dist/console/fbtv.c 2005-09-30 12:09:22.0 +0200
+++ xawtv-3.95/console/fbtv.c 2006-08-15 16:07:04.0 +0200
@@ -230,6 +230,26 @@
}
static void
+fb_loadpalette(int fd)
+{
+if (fb_var.bits_per_pixel == 8 ||
+fb_fix.visual == FB_VISUAL_DIRECTCOLOR) {
+if (-1 == ioctl(fd,FBIOPUTCMAP,cmap)) {
+ /*
+* radeonfb in 15/16bpp returns EINVAL when color
+* map retrieved by FBIOGETCMAP is programmed back
+* by FBIOPUTCMAP. It still programs palette
+* correctly, just instead of ignoring items 64-255
+* it returns an error.
+*/
+ if (errno != EINVAL) {
+perror(ioctl FBIOPUTCMAP);
+ }
+ }
+}
+}
+
+static void
fb_initcolors(int fd, int gray)
{
/* get colormap */
@@ -288,11 +308,7 @@
}
/* set colormap */
-if (fb_var.bits_per_pixel == 8 ||
- fb_fix.visual == FB_VISUAL_DIRECTCOLOR) {
- if (-1 == ioctl(fd,FBIOPUTCMAP,cmap))
- perror(ioctl FBIOPUTCMAP);
-}
+fb_loadpalette(fd);
}
static void
@@ -511,11 +527,17 @@
}
static void
+clear_video(void)
+{
+fb_memset(fb_mem+fb_mem_offset,0,fb_var.yres * fb_fix.line_length);
+}
+
+static void
do_fullscreen(void)
{
do_va_cmd(2,capture,off);
quiet = !quiet;
-fb_memset(fb_mem+fb_mem_offset,0,fb_fix.smem_len);
+clear_video();
do_va_cmd(2,capture,on);
}
@@ -553,8 +575,9 @@
case FB_ACQ_REQ:
switch_last = fb_switch_state;
fb_switch_acquire();
- fb_memset(fb_mem+fb_mem_offset,0,fb_fix.smem_len);
+ clear_video();
ioctl(fb,FBIOPAN_DISPLAY,fb_var);
+ fb_loadpalette(fb);
do_va_cmd(2,capture,on);
break;
case FB_ACTIVE:
@@ -748,7 +771,7 @@
}
#endif
-fb_memset(fb_mem+fb_mem_offset,0,fb_fix.smem_len);
+clear_video();
for (;!sig;) {
if ((fb_switch_state == FB_ACTIVE || keep_dma_on) !quiet) {
/* clear first lines */
@@ -918,7 +941,7 @@
audio_off();
drv-close(h_drv);
if (fb_switch_state == FB_ACTIVE)
- fb_memset(fb_mem+fb_mem_offset,0,fb_fix.smem_len);
+ clear_video();
tty_cleanup();
fb_cleanup();
exit(0);
diff -urN xawtv-3.95.dist/console/v4l-conf.c xawtv-3.95/console/v4l-conf.c
--- xawtv-3.95.dist/console/v4l-conf.c 2005-02
Bug#382490: Add support for Seagate 7200.10 drives
Package: hddtemp Version: 0.3-beta15-22 Tags: patch Hello, I've sent something like patch below upstream on June 6th, but it seems that nothing happened. As I'm tired from bringing this patch across your frequent releases, could you apply this? I've also moved 320GB 7200.10 drive you have added yesterday - sections are supposed to be alphabetically sorted. Anyway, patch adds support for all Seagate 7200.10 drives my hardware supplier offers. One thing which is not quite clear to me is why we need these hddtemp configuration file additions at this point at all? All drives released in last few years (definitely ones supporting ATA6 or ATA7) use 194C for temperature, so only purpose of this file is (more or less) to provide full fancy drive name, and I'm not sure whether hddtemp displays that fancy name at all... Thanks, Petr Vandrovec P.S.: A=PATA, AS=SATA, 6=16MB cache, 8=8MB cache. --- /etc/hddtemp.db.dpkg-dist 2006-08-10 23:23:59.0 +0200 +++ /etc/hddtemp.db 2006-08-11 15:16:15.0 +0200 @@ -297,16 +297,22 @@ ST3160812(A|AS) 194 C Seagate Barracuda 7200.9 160GB ST3160827AS 194 C Seagate Barracuda 7200.7 160GB (Serial ATA) ST3200021A 194 C Seagate Barracuda 7200.7 Plus 200GB +ST3200[68]20(A|AS) 194 C Seagate Barracuda 7200.10 200GB ST3200822(A|AS) 194 C Seagate Barracuda 7200.7 Plus 200GB (PATA or SATA) ST3200826A194 C Seagate Barracuda 7200.8 200GB -ST3320620AS 194 C Seagate Barracuda 7200.10 320GB SATA +ST3250[68]20(A|AS) 194 C Seagate Barracuda 7200.10 250GB ST3250623A194 C Seagate Barracuda 7200.16 250GB ST3250624AS 194 C Seagate Barracuda 7200.9 250GB SATA ST3250823A 194 C Seagate Barracuda 7200.8 250GB ST3250823A194 C Seagate Barracuda 7200.7 Plus 250GB ST3250823NS 194 C Seagate NL35 SATA (RAID-Edition) 7200 250GB +ST3300[68]20(A|AS) 194 C Seagate Barracuda 7200.10 300GB ST3300831A 194 C Seagate 300GB ST3300831A +ST3320[68]20(A|AS) 194 C Seagate Barracuda 7200.10 320GB +ST3400[68]20(A|AS) 194 C Seagate Barracuda 7200.10 400GB ST3400832A194 C Seagate Barracuda 7200.8 Plus 400GB +ST3500[68]30(A|AS) 194 C Seagate Barracuda 7200.10 500GB +ST3750[68]40(A|AS) 194 C Seagate Barracuda 7200.10 750GB ST3808110AS 194 C Seagate Barracuda 7200.9 80GB ST910021A194 C Seagate Momentus 7200.1 100GB ST9100823A 194 C Seagate Momentus 5400.2 100GB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375300: new tar behavior and --wildcards
[I'm not on Debian-devel, so please CC me] Bdale Garbee wrote: The new tar behavior with respect to wildcards is not a change I introduced just for Debian, it's a new upstream change that appears to be quite intentional and well documented, as per this text from the tar info docs: The following table summarizes pattern-matching default values: MembersDefault settings -- Inclusion `--no-wildcards --anchored --no-wildcards-match-slash' Exclusion `--wildcards --no-anchored --wildcards-match-slash' -- Footnotes -- (1) Notice that earlier GNU `tar' versions used globbing for inclusion members, which contradicted to UNIX98 specification and was not documented. Although maybe that it was not documented, it was widely used, and it exists for at least 6 years. So upstream should fix documentation instead of tar behavior. As documentation is not part of Debian, it does not matter for Debian anyway. Obviously, the problems reported with various Debian utilities are due to the default now being --no-wildcards for inclusion combined with a dependency on the footnoted feature of previous versions of GNU tar. Since this seems to have been an intentional behavior change by upstream to better align with a published standard, I'm uninclined to fight it, and think our best response is to update our utilities to include the --wildcards option, with a suitable versioned dependency on tar. This decision makes tar completely incompatible. Programs which worked fine with tar for 6 years are suddenly broken, and now you have to have two versions - one for 'tar' before this brokeness, which do not pass --wildcards, and one for this broken 'tar', which passes --wildcards. And older version on newer 'tar' extracts nothing, while new version on older 'tar' fails with an unknown option error. Maybe it could be default for tar's POSIX mode, but I have no idea why GNU mode behavior should be changed in any way. Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375300: tar 1.15.91 breaks at least apt-listchanges
Package: tar Version: 1.15.91-1 Severity: critical Justification: makes apt-listchanges unusable When apt-listchanges tries to extract changelogs, it hits new feature of tar 1.15.91 which forbids wildcards in filenames, and so it fails to do anything as it finds no changelog: 12528 execve(/bin/sh, [sh, -c, dpkg-deb --fsys-tarfile /var/cache/apt/archives/ttf-dejavu_2.7-2_all.deb |tar xf - -C /tmp/apt-listchangesEKaRJr \'usr/doc/*/NEWS.Debian.gz\' \'usr/share/doc/*/NEWS.Debian.gz\' \'usr/doc/*/NEWS.Debian\' \'usr/share/doc/*/NEWS.Debian\' \'./usr/doc/*/NEWS.Debian.gz\' \'./usr/share/doc/*/NEWS.Debian.gz\' \'./usr/doc/*/NEWS.Debian\' \'./usr/share/doc/*/NEWS.Debian\' \'usr/doc/*/changelog.Debian.gz\' \'usr/share/doc/*/changelog.Debian.gz\' \'usr/doc/*/changelog.Debian\' \'usr/share/doc/*/changelog.Debian\' \'./usr/doc/*/changelog.Debian.gz\' \'./usr/share/doc/*/changelog.Debian.gz\' \'./usr/doc/*/changelog.Debian\' \'./usr/share/doc/*/changelog.Debian\' \'usr/doc/*/changelog.gz\' \'usr/share/doc/*/changelog.gz\' \'usr/doc/*/changelog\' \'usr/share/doc/*/changelog\' \'./usr/doc/*/changelog.gz\' \'./usr/share/doc/*/changelog.gz\' \'./usr/doc/*/changelog\' \'./usr/share/doc/*/changelog\' 2/dev/null], [SHELL=/bin/bash, TERM=linux, HUSHLOGIN=FALSE, USER=root, MAIL=/var/mail/root, PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:., PWD=/tmp, LANG=C, PS1=\\h:\\w\\$ , SHLVL=1, HOME=/root, LOGNAME=root, LC_CTYPE=cs_CZ, _=/usr/bin/strace, OLDPWD=/tmp/w]) = 0 12530 write(2, tar: , 5) = 5 12530 write(2, usr/doc/*/NEWS.Debian.gz: Not found in archive, 46) = 46 12530 write(2, \n, 1) = 1 12530 write(2, tar: , 5) = 5 12530 write(2, usr/share/doc/*/NEWS.Debian.gz: Not found in archive, 52) = 52 12530 write(2, \n, 1) = 1 12530 write(2, tar: , 5) = 5 12530 write(2, usr/doc/*/NEWS.Debian: Not found in archive, 43) = 43 12530 write(2, \n, 1) = 1 12530 write(2, tar: , 5) = 5 12530 write(2, usr/share/doc/*/NEWS.Debian: Not found in archive, 49) = 49 12530 write(2, \n, 1) = 1 ... Please, if you must introduce some new options, make '--wildcards' default so you do not change behavior in backward incompatible way. Or, if you are absolutely sure that no other program on the world besides apt-listchanges depends on this behavior, feel free to reassign this to apt-listchanges. But I'm absolutely sure that apt-listchanges is not only program which depends on this behavior (as I've written couple of tools which depend on this as well)... Thanks, Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311815: powerpc matroxfb?
Are there some details available about hardware in question? For some time matroxfb drives accelerator in little endian mode. Unfortunately there is no screenshot nor dmesg log, nor used font size, so I can only guess what problem is. To track problem further I need to know what happens with 2.6.12 or newer kernel - some bigendian fixes for accelerated characters drawing went into 2.6.12, so it is quite possible that problem is already fixed. Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311815: matrox support on ppc64
Tom Gall wrote: Hi Petr, I was just talking to sven luther about matrox graphics on ppc64. It would seem we have somewhat similiar experiences tho somewhat different as well. Currently I'm running 2.6.11.6 on my power3 box with a matrox g200. I do pass to the kernel : video=matroxfb:[EMAIL PROTECTED],memtype:3 . You'll want to do the same if you're not. This does work, console, X and all. Now later kernels, 2.6.15 for instance seem to be quite quite busted but I suspect 2.6.14.x is probably fine, the thought being that 2.6.15 is obviously when the great grand merge was done. matroxfb itself should not have changed between 2.6.12 and 2.6.15 at all. Only difference between 2.6.12 and 2.6.15 are: (1) Removal of hardware cursor. fbcon lost this ability sometime before 2.6.15, so it was removed. (2) matroxfb now knows how to find PInS structure in the GXP450 (or how is IBM adapter named). This should alleviate need for 'memtype:3'. (3) Added PCI IDs for some Matrox Mystique AGP I never ever saw. (4) Different cache flush is used on old 2064W chips (old Millennium I). So as far as I can tell, you should get identical behavior with 2.6.12 and anything newer. It would be nice if you could tell us what color depth you are using (default should be 8bpp, but maybe you did not have built this support into kernel so another depth was used) and character cell size you are using (8x16 or anything else). Anyway when I have two reports, one saying that matroxfb does not work on 2.6.11 and another that it does work, I'm lost. As since 2.6.9 or so matroxfb uses only readl()/writel() to access all hardware, without any optimizations, 64bitness of hardware should not matter, only endianness problems should in the drawing code (matroxfb_1bpp_imageblit) - readl writel should still work same way. Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311815: matrox support on ppc64
Sven Luther wrote: On Wed, Jan 11, 2006 at 11:26:35PM +0100, Petr Vandrovec wrote: Anyway when I have two reports, one saying that matroxfb does not work on 2.6.11 and another that it does work, I'm lost. As since 2.6.9 or so matroxfb uses only readl()/writel() to access all hardware, without any optimizations, 64bitness of hardware should not matter, only endianness problems should in the drawing code (matroxfb_1bpp_imageblit) - readl writel should still work same way. Its not the same card though, one is a G450, and the other a G200. Furthermoe Tom used a 2.6.11.6 kernel, while Roberto probably used a much earlier version. Not sure if there are still two different matroxfb in 2.6.11 as they used to be though ? There were never two different matroxfbs in any kernel... Also from matroxfb's viewpoint all accelerators between Millennium I and G550 are identical - if you got some picture on screen and your monitor agrees that input signal is what you've specified, then you should observe identical behavior on primary head. I repeat again, anything older than 2.6.12 is completely uninteresting as 2.6.12 is known to fix problems with character painting on big endian. Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341234: New dash 0.5.3-1 breaks apt-move
Package: apt-move
Version: 4.2.24-1
Severity: grave
Tags: patch
Hello,
apt-move uses
if ! type exp /dev/null 21; then
if type dash /dev/null 21; then
exec dash $0 $@
else
exec ash $0 $@
fi
fi
to make sure that it is executing under dash or ash. dash 0.5.3-1 breaks
this code, causing it to enter endless loop as dash lost its 'exp' builtin:
$ dpkg -l dash
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version
Description
+++---
ii dash 0.5.2-8
The Debian Almquist Shell
$ type exp
exp is a shell builtin
$ dpkg -l dash
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version
Description
+++---
ii dash 0.5.3-1
The Debian Almquist Shell
$ type exp
exp: not found
It is probably caused by this upstream change:
2005-02-28 Herbert Xu [EMAIL PROTECTED]
* Replaced EXEVAL with SKIPEVAL.
* Update funcnest atomically.
* Only set skipcount for break and continue.
* Removed expcmd built-in.
* Normalise input in likely/unlikely macros.
I've verified that upstream apt-move 4.2.25 still uses this detection.
If you believe that this detection is correct and dash is package with problem,
then feel free to reassign this to dash. As Herbert is upstream maintainer
for both dash and apt-move, it probably does not matter a lot, as it
ends up in his mailbox this way or another.
For Debian I would apply patch below, which removes dash/ash detection and
forces dash through #!.
Thanks,
Petr Vandrovec
diff -urN apt-move-4.2.24/apt-move apt-move-4.2.24/apt-move
--- apt-move-4.2.24/apt-move2005-10-24 17:35:09.0 +0200
+++ apt-move-4.2.24/apt-move2005-11-29 13:42:54.0 +0100
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/dash
#
# Copyright (c) 1999 Michael Merten [EMAIL PROTECTED]
# Copyright (c) 1999-2000 Gregory T. Norris [EMAIL PROTECTED]
@@ -18,14 +18,6 @@
#
set -e
-if ! type exp /dev/null 21; then
- if type dash /dev/null 21; then
- exec dash $0 $@
- else
- exec ash $0 $@
- fi
-fi
-
[ ${CDPATH+1} ] unset CDPATH
if [ ${LC_ALL+1} ]; then
export LC_MONETARY=$LC_ALL
diff -urN apt-move-4.2.24.go/debian/control apt-move-4.2.24/debian/control
--- apt-move-4.2.24.go/debian/control 2005-10-21 03:18:29.0 +0200
+++ apt-move-4.2.24/debian/control 2005-11-29 13:42:40.0 +0100
@@ -7,7 +7,7 @@
Package: apt-move
Architecture: any
-Depends: bc, dash | ash, ${shlibs:Depends}
+Depends: bc, dash, ${shlibs:Depends}
Recommends: apt
Description: Maintain Debian packages in a package pool
apt-move is used to move a collection of Debian package files into a proper
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339024: apt-move complains about EOF on /tmp/MOVE_xxx/movefiles-fifo1
It is caused by recent coreutils upgrade (IMHO coreutils bug). stat -c %s . .. / printed 4096 4096 4096 before upgrade while it prints 409640964096 after upgrade. And as 'stat' does not provide any way to put \n to the format, it is actually impossible to create format older stat generated! You have to replace all %s in apt-move with %s and hope that shell you are using will cope with new line embedded in the string correctly... Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339136: Changes in stat package output break apt-move
Package: coreutils Version: 5.93-2 Severity: critical Justification: renders apt-move unusable Hello, in the past 'stat -L -c %s / /' produced 4096 LF 4096 LF while now (since 5.93 update) it produces 40964096 without any explanation why this happened. This breaks at least apt-move and some programs I've written. But what's worse is that now stat does not provide any way how to get each of stat results on separate line - %s\n just generates 4096\n4096\n, without interpreting \n... Can you revert to the old behavior and provide special option for new (IMHO broken) one, or provide some method how to embed LF to the output without actually having LF embedded directly into shell scripts? Though I would prefer backward compatibility over even bigger incompatibility. See bug 339024 for apt-move's half of story. Thanks, Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327867: Bug 327867: Patch to get apt-get sync working for sources
tags 327867 +patch
thanks
Hello,
I've finally got a clue what's wrong with 'apt-get sync' not
retrieving source packages. Problem is that lowest version available
in repositories is preferred, so if you have two repositories (like
network and local cdrom, or two networks, one updated and one not)
then binary packages are mirrored from newest one, while sources from
oldest one. Which is not quite what one would expect.
This simple one-liner fixes problem for me - once I patched apt-move,
it happilly downloaded 490MB of sources it was ignoring for last half
of year...
Best regards,
Petr Vandrovec
diff -urN apt-move-4.2.24/apt-move apt-move-4.2.24/apt-move
--- apt-move-4.2.24/apt-move2005-10-24 17:35:26.0 +0200
+++ apt-move-4.2.24/apt-move2005-10-24 17:35:09.0 +0200
@@ -475,7 +475,8 @@
[ -f $dir/local ] || $dir/local
[ -f $dir/debian ] || $dir/debian
- sort -k 1,1 -sum $dir/local $dir/debian |
+$dir/debian $GET2 |
+ sort -k 1,1 -sum $dir/local - |
awk '{
printf %-30s\t%-9s\t%-15s\t%s\n,
$1, $2, $3, $4
diff -urN apt-move-4.2.24/debian/changelog apt-move-4.2.24/debian/changelog
--- apt-move-4.2.24/debian/changelog2005-10-24 17:35:26.0 +0200
+++ apt-move-4.2.24/debian/changelog2005-10-21 03:19:24.0 +0200
@@ -1,3 +1,9 @@
+apt-move (4.2.24-1.1) unstable; urgency=low
+
+ * Retrieve source packages correctly (closes: #327867).
+
+ -- Petr Vandrovec [EMAIL PROTECTED] Mon, 24 Oct 2005 17:40:00 +0200
+
apt-move (4.2.24-1) unstable; urgency=low
* New upstream version (closes: #310391)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#280844: Another patch to fix downloaded files corruption
Michael Vogt wrote: On Sat, Oct 22, 2005 at 06:00:04PM +0200, Petr Vandrovec wrote: I have no idea what I'm doing wrong. So I wrote something what looks more reasonable than original Geller's patch to me. Am I really only one who cares that apt is corrupting package it downloads ? This time tetex-base_3.0.orig.tar.gz is corrupted on redownload as its last byte is CR (0D) (it is replaced with 'H', see previous messages in this bugreport and bug 290694). I applied your patch to the apt I uploaded to experimental. I'm not entirely sure about possible side-effect in the patch so I would like to see it tested in experimental first. Thanks. Original code seems to think that line delimiter is either LF or LF-CR. But RFC says quite clearly that it is CR-LF. So usually you have: Content-type: application/octet-streamCRLF CRLF binarydata which current parser parses as 'Content-type: application/octet-streamCRLFCR' and then finds empty line with LF only. But if binary data start with CR, old parser find empty line with LFCR, eating first byte of data payload. Then whole payload is shifted by one byte, and at the end first byte of following 'HTTP/1.0 ...' response is eaten, causing failure for subsequently downloaded package as parser does not understand 'TTP/1.0' header. With my fixes it parses example above as 'Content-type: application/octet-streamCRLF' followed by empty 'CRLF' line, and it should never look beyond this last LF at transfered data. Maybe this loop should skip all CR bytes while doing copy, so subsequent code can rely on lines separated with single LF only, but as it seems that everybody already handles random CRs scattered through headers it would be just cleanup... Can sombody at least tell me why this important data corrupting bug is ignored for more than year? Probably because this is a very central piece of the code and any mistake here is fatal. Anyway, it's in experimental now and let's hope we find enough people to test it :) Thanks. Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#280844: Another patch to fix downloaded files corruption
Well,
I have no idea what I'm doing wrong. So I wrote something what looks more
reasonable than original Geller's patch to me. Am I really only one who cares
that apt is corrupting package it downloads ? This time
tetex-base_3.0.orig.tar.gz
is corrupted on redownload as its last byte is CR (0D) (it is replaced with 'H',
see previous messages in this bugreport and bug 290694).
Can sombody at least tell me why this important data corrupting bug is
ignored for more than year?
Thanks,
Petr Vandrovec
diff -urN apt-0.6.42/debian/changelog apt-0.6.42.fix/debian/changelog
--- apt-0.6.42/debian/changelog 2005-10-20 11:33:43.0 +0200
+++ apt-0.6.42.fix/debian/changelog 2005-10-22 16:59:15.0 +0200
@@ -1,3 +1,9 @@
+apt (0.6.42.1) unstable; urgency=low
+
+ * Fix corruption of downloaded packages (closes: #280844, #290694).
+
+ -- Petr Vandrovec [EMAIL PROTECTED] Sat, 22 Oct 2005 17:00:00 +0200
+
apt (0.6.42) unstable; urgency=low
* apt-pkg/cdrom.cc:
diff -urN apt-0.6.42/methods/http.cc apt-0.6.42.fix/methods/http.cc
--- apt-0.6.42/methods/http.cc 2005-10-19 21:19:09.0 +0200
+++ apt-0.6.42.fix/methods/http.cc 2005-10-22 16:58:15.0 +0200
@@ -204,28 +204,23 @@
if (Buf[I%Size] != '\n')
continue;
++I;
- if (I InP Buf[I%Size] == '\r')
- ++I;
if (Single == false)
{
-if (Buf[I%Size] != '\n')
- continue;
- ++I;
if (I InP Buf[I%Size] == '\r')
++I;
+ if (I = InP || Buf[I%Size] != '\n')
+continue;
+ ++I;
}
- if (I InP)
-I = InP;
-
Data = ;
while (OutP I)
{
unsigned long Sz = LeftWrite();
if (Sz == 0)
return false;
-if (I - OutP LeftWrite())
+if (I - OutP Sz)
Sz = I - OutP;
Data += string((char *)(Buf + (OutP%Size)),Sz);
OutP += Sz;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334943: apt knows nothing about backward compatibility: please rebuild apt-move
Package: apt-move Version: 4.2.24-1 Hello, sorry to bother you, but can you please rebuild apt-move? Upgrade from apt-0.6.41 to apt-0.6.42 breaks binary compatibility (fetch from apt-move gets sigsegv) without changing soname of their libpkg-apt library. After simple rebuild of apt-move everything works again. So you need to upload new apt-move, with build-depends on libpkg-apt-dev = 0.6.42, and resulting package should probably conflict with apt 0.6.42 if it does not happen automatically. Thanks, Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332693: Any intent to package libldap-2.2-7-dev ?
Package: libldap2-dev Version: 2.1.30-12 Hello Torsten, is there some intent to package 2.2.26's libldap-dev package? I'm hitting quite strange problem since September 13th - our imports from Windows-based LDAP server stopped working. We issue ldap_search_ext and then go through replies - we get 46 entries, 3 referrals, and then ldap_result() hangs forever, instead of returning message type 101, search complete. When same program is linked with libldap_r-2.2.so.7.0.19 instead of with libldap_r.so.2.0.130, everything works - program gets 46 entries, 3 referrals, and - voila - 1 search complete result. ldapsearch itself exhibits same behavior, so I'm quite sure that I have my code correct - unless I hit ^C, ldap_search waits rather long time (doing select(1024, [4], NULL, NULL, NULL) waiting for some more data from server) and then returns -1 after server kills connection due to inactivity timeout. Due to this I would like to see libldap-2.2-dev package in the Debian - as I assume that request to fix this in 2.0.130 will be shoot down recommending upgrade to 2.2.x... I have no control over server, only thing I know is that it is running some version of Windows. Thanks, Petr Vandrovec usermap:/usr/local/bin# ./ldapsearch-old -H ldaps://dc2.fa.cvut.cz -D 'cn=Petr Vandrovec,ou=CIT,ou=Zamestnanci,ou=uzivatele,dc=fa,dc=cvut,dc=cz' -W -x -b dc=fa,dc=cvut,dc=cz '(cn=Petr Vandrovec)' 1.1 Enter LDAP Password: version: 2 # # filter: (cn=Petr Vandrovec) # requesting: 1.1 # # Petr Vandrovec, CIT, Zamestnanci, UZIVATELE, fa.cvut.cz dn: CN=Petr Vandrovec,OU=CIT,OU=Zamestnanci,OU=UZIVATELE,DC=fa,DC=cvut,DC=cz # search reference ref: ldaps://DomainDnsZones.fa.cvut.cz/DC=DomainDnsZones,DC=fa,DC=cvut,DC=cz # search reference ref: ldaps://ForestDnsZones.fa.cvut.cz/DC=ForestDnsZones,DC=fa,DC=cvut,DC=cz # search reference ref: ldaps://fa.cvut.cz/CN=Configuration,DC=fa,DC=cvut,DC=cz ^C usermap:/usr/local/bin# ldapsearch -H ldaps://dc2.fa.cvut.cz -D 'cn=Petr Vandrovec,ou=CIT,ou=Zamestnanci,ou=uzivatele,dc=fa,dc=cvut,dc=cz' -W -x -b dc=fa,dc=cvut,dc=cz '(cn=Petr Vandrovec)' 1.1 Enter LDAP Password: # extended LDIF # # LDAPv3 # base dc=fa,dc=cvut,dc=cz with scope sub # filter: (cn=Petr Vandrovec) # requesting: 1.1 # # Petr Vandrovec, CIT, Zamestnanci, UZIVATELE, fa.cvut.cz dn: CN=Petr Vandrovec,OU=CIT,OU=Zamestnanci,OU=UZIVATELE,DC=fa,DC=cvut,DC=cz # search reference ref: ldaps://DomainDnsZones.fa.cvut.cz/DC=DomainDnsZones,DC=fa,DC=cvut,DC=cz # search reference ref: ldaps://ForestDnsZones.fa.cvut.cz/DC=ForestDnsZones,DC=fa,DC=cvut,DC=cz # search reference ref: ldaps://fa.cvut.cz/CN=Configuration,DC=fa,DC=cvut,DC=cz # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 1 # numReferences: 3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290694: apt-move broken due to inability of apt-get to correctly handle HTTP
merge 290694 280844 tags 290694 patch thanks Hello, is there some reason why Geller's patch in this bug report is still not applied, or objections against that patch reported in the bugreport ? Do I have to bump priority of this bug to critical as it breaks unrelated package and causes data corruption ? As of today there is another victim of apt's inability to handle correctly data chunks beginning with '\r' : openclipart: # apt-move sync ... Get:67 http://ftp.debian.org sid/main netkit-ftp-ssl 0.17.12+0.2-5 (tar) [64.6kB] Get:68 http://ftp.debian.org sid/main netkit-ftp-ssl 0.17.12+0.2-5 (diff) [5861B] Get:69 http://ftp.debian.org sid/main openclipart 0.17+dfsg-2 (dsc) [693B] Get:70 http://ftp.debian.org sid/main openclipart 0.17+dfsg-2 (tar) [78.6MB] Err http://ftp.debian.org sid/main openclipart 0.17+dfsg-2 (diff) 0 Partial Content Get:71 http://ftp.debian.org sid/main openssl 0.9.7g-3 (dsc) [758B] Get:72 http://ftp.debian.org sid/main openssl 0.9.7g-3 (tar) [3132kB] Get:73 http://ftp.debian.org sid/main openssl 0.9.7g-3 (diff) [29.1kB] Get:74 http://ftp.debian.org sid/main shadow 1:4.0.12-5 (dsc) [867B] ... Get:87 http://ftp.debian.org sid/main xaw3d 1.5+E-9 (diff) [16.1kB] Fetched 28.4MB in 54s (521kB/s) Failed to fetch http://ftp.debian.org/debian/pool/main/o/openclipart/openclipart_0.17+dfsg.orig.tar.gz MD5Sum mismatch Failed to fetch http://ftp.debian.org/debian/pool/main/o/openclipart/openclipart_0.17+dfsg-2.diff.gz 0 Partial Content E: Failed to fetch some archives. Unknown error: runsync: 123. # Thanks, Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328568: ssh 4.2p1-3 crash
Hello, due to pure luck (new ssh crashed on all my systems except one) I've found workaround - default_realm in [libdefaults] in /etc/krb5.conf must not be empty. default_realm = crashes, default_realm = x works... Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290694: apt-move broken due to inability of apt-get to handle chunked encoding...
For several releases of mozilla-firefox (to be precise once when mozilla-firefox_1.0.6-1 = -2 was released, once for 2 = 3, and finally this week 3 = 4) apt-move always fails to perform update, saying that mozilla-firefox's MD5Sum is invalid, and that HTTP headers are too complicated to understand them correctly on next file downloaded after mozilla-firefox_1.0.6.orig.tar.gz. Problem is that apt-get uses rather questionable approach to truncate last byte from file it has locally and then ask server for this last byte. And for mozilla-firefox_1.0.6_orig.tar.gz last byte is CR - \r. This confuses apt-get's parser a lot, and it just skips '\r' of content. Instead it believes that 'H' from HTTP is payload, and it does have no idea what to do with 'TTP/1.1 ...' from next response: HTTP/1.1 206 Partial Content\r\n Date: Sat, 10 Sep 2005 02:17:15 GMT\r\n Server: Apache/1.3.33 (Debian GNU/Linux)\r\n Last-Modified: Wed, 20 Jul 2005 16:17:47 GMT\r\n ETag: \4100fe-2659f1e-42de792b\\r\n Accept-Ranges: bytes\r\n Content-Length: 1\r\n Content-Range: bytes 40214301-40214301/40214302\r\n Keep-Alive: timeout=15, max=96\r\nConnection: Keep-Alive\r\n Content-Type: application/x-tar\r\n Content-Encoding: x-gzip\r\n \r\n \r HTTP/1.1 206 Partial Content\r\n Due to this it appends 'H' at the end of (previously completely valid) mozilla-firefox tarball, and immediately fails as md5sum does not match. ppc:/usr/src/linus# apt-move sync Updating from local Packages files... Syncing mirror... Reading package lists... Done Building dependency tree... Done Moving files... Skipping files: /var/cache/apt/archives/libgnome-perl_0.7009-4_i386.deb /var/cache/apt/archives/libgtk-imlib-perl_0.7009-4_i386.deb /var/cache/apt/archives/libgtk-perl_0.7009-4_i386.deb /var/cache/apt/archives/libgtk-pixbuf-perl_0.7009-4_i386.deb /var/cache/apt/archives/libswt-gtk-3.1-java_3.0+3.1M4-5_all.deb /var/cache/apt/archives/libswt-gtk-3.1-jni_3.0+3.1M4-5_i386.deb Moving Files: Reading package lists... Done Building dependency tree... Done Need to get 44.3MB/45.2MB of source archives. Get:1 http://ftp.nerim.net unstable/main ffmpeg 3:20050427-0sarge0.1 (dsc) [865B ] Get:2 http://ftp.nerim.net unstable/main ffmpeg 3:20050427-0sarge0.1 (tar) [2338 kB] Get:3 http://ftp.nerim.net unstable/main ffmpeg 3:20050427-0sarge0.1 (diff) [787 8B] Get:4 http://ftp.debian.org sid/main libgtk-perl 0.7009-5 (dsc) [994B] Get:5 http://ftp.debian.org sid/main libgtk-perl 0.7009-5 (tar) [447kB] Get:6 http://ftp.debian.org sid/main libgtk-perl 0.7009-5 (diff) [113kB] Get:7 http://ftp.debian.org sid/main mozilla-firefox 1.0.6-4 (dsc) [972B] Get:8 http://ftp.debian.org sid/main mozilla-firefox 1.0.6-4 (tar) [40.2MB] Err http://ftp.debian.org sid/main mozilla-firefox 1.0.6-4 (diff) 0 Partial Content Get:9 http://ftp.debian.org sid/main swt-gtk 3.1-1 (dsc) [785B] Get:10 http://ftp.debian.org sid/main swt-gtk 3.1-1 (tar) [880kB] Get:11 http://ftp.debian.org sid/main swt-gtk 3.1-1 (diff) [24.0kB] Fetched 10B in 5s (2B/s) Failed to fetch http://ftp.debian.org/debian/pool/main/m/mozilla-firefox/mozilla -firefox_1.0.6.orig.tar.gz MD5Sum mismatch Failed to fetch http://ftp.debian.org/debian/pool/main/m/mozilla-firefox/mozilla -firefox_1.0.6-4.diff.gz 0 Partial Content E: Failed to fetch some archives. Unknown error: runsync: 123. ppc:/usr/src/linus# Once I applied Geller Sandor's patch (thanks Sandor) from bug 290694 to apt-get 0.6.41, everything seems to be happy and apt-move does its job without complaining about invalid md5sums. So it would be great if that patch could be applied to the apt. Or some other equivalent to unbreak apt-get when it meets \r or \n at the beginning of the data payload. Thanks, Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324939: ncpfs: while we mount novell volumes in debian linux they are mounted in uppercase.
Anand wrote: Package: ncpfs Version: 2.2.6-1 Severity: important Dear Petr Vandrovec even after using the below suggested option we get the same problem. Here i am attaching the screenshot of the process for your reference. i have mounted the novell volume and created a directory with name test. which is created in uppercase (TEST). What reports 'nwdir -v DISKHOG.EXE' in the /mnt/test directory? And was your kernel built with CONFIG_NCPFS_SMALLDOS option (Lowercase DOS filenames under ncpfs submenu) ? Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324939: ncpfs: while we mount novell volumes in debian linux they are mounted in uppercase.
Anand wrote: 'nwdir -v DISKHOG.EXE' /mnt/test# nwdir -v diskhog.exe Directory DATA:DISKHOG.EXE File: DOS: DISKHOG.EXE Rights: Inherited: [SRWCEMFA] Effective: [SRWCEMFA] Owning namespace: DOS Miscellaneous NetWare Information: Last update:Thursday 01 March 2000 11:03:00 GMT Last archived: never Last accessed: Thursday 25 August 2005 12:00:00 GMT Created/Copied: Thursday 29 June 2004 02:27:30 GMT User:SUPERVISOR Flags: [Rw] [---] [---] File size:37968 (allocated 40960) Yep. You have only DOS namespace on the volume. If you have control over server, issue 'add nfs namespace to volume data' on server's console. If you do not have control over server, ... Kerner version is 2.6.8-2-686, where should i include this line CONFIG_NCPFS_SMALLDOS, can u please specify in which configuration file. i don't have any idea in kernel compiling. ... you'll have to recompile your kernel. If you never did it, ask some friend to do that for you. If you are using Debian stock kernel, and you do not want to build kernel yourself, simplest thing to do might be reassigining this bug to the kernel package, asking for ncp kernel module being build with 'CONFIG_NCPFS_SMALLDOS' option set. www.kernel.org provides links on which you could find details about kernel building. But as incorrectly built kernel may render your box unusable, you should think twice before installing your own kernel. Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324939: ncpfs: while we mount novell volumes in debian linux they are mounted in uppercase.
Anand wrote: Package: ncpfs Version: 2.2.6-1 Severity: important while we mount novell volumes in debian linux they are mounted in uppercase. All the files and directories are in uppercase which gives us a problem according to our work procedure. I kindly request you to suggest is there any option to mount novell volumes in lower case. Add NFS namespace to the volume, or use '-o noos2' option to use DOS namespace only. LONG/OS2 namespace is by definition case preserving, and changing letter case would break this. NFS namespace is implemented on server to lowercase filenames created from DOS namespace, so if Windows app insist on using capital letters, you'll still get them, but if DOS app creates file, it will be lowercased. Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320827: apt-move should sign local archive...
Hello,
please apply this patch on the top of patch above. As apt-move uses
'set -e', it was failing with exit code == 1 when no SIGNINGKEY was
defined :-(
Thanks,
Petr Vandrovec
--- apt-move-4.2.23/apt-move2005-08-07 18:01:22.0 +0200
+++ apt-move-4.2.23/apt-move2005-08-01 21:31:02.0 +0200
@@ -1326,7 +1326,7 @@
exec -
- [ -n $SIGNINGKEY ] gpg --detach-sign -ao Release.gpg --default-key
$SIGNINGKEY --batch --yes --sign Release
+ [ -z $SIGNINGKEY ] || gpg --detach-sign -ao Release.gpg --default-key
$SIGNINGKEY --batch --yes --sign Release
}
make_contents() {
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320827: apt-move should sign local archive...
Package: apt-move
Version: 4.2.23
Tags: patch
Hello,
although apt-move needs rebuild to work with updated apt, so it
is currently uninstallable in unstable, if you'll rebuild it,
you'll notice that all packages are downloaded from the network
again and again as 'apt-get' prefers trusted signed sources
over unsigned, and there is no option how to disable this
behavior (only way I've found is modifying apt-get to treat
all sources as untrusted).
So I've wrote patch below which I use on my system to get
apt-move happy again (and signed repository as an additional
effect). Maybe someone else will need additional options passed
to the gpg (like removing --batch), but this is just what sufficed
to me.
Patch applies to both 4.2.23 in unstable and to Herbert's
upstream 4.2.24.
Thanks,
Petr Vandrovec
diff -urN apt-move-4.2.23.orig/apt-move apt-move-4.2.23/apt-move
--- apt-move-4.2.23.orig/apt-move 2004-11-22 00:04:26.0 +0100
+++ apt-move-4.2.23/apt-move2005-08-01 21:31:02.0 +0200
@@ -52,6 +52,7 @@
COPYONLY=no
PKGCOMP=gzip
CONTENTS=no
+SIGNINGKEY=
LISTALL=
# Remember where we came from.
@@ -1324,6 +1325,8 @@
cat $pf-sha1sum
exec -
+
+ [ -n $SIGNINGKEY ] gpg --detach-sign -ao Release.gpg --default-key
$SIGNINGKEY --batch --yes --sign Release
}
make_contents() {
diff -urN apt-move-4.2.23.orig/apt-move.8 apt-move-4.2.23/apt-move.8
--- apt-move-4.2.23.orig/apt-move.8 2004-11-22 00:04:26.0 +0100
+++ apt-move-4.2.23/apt-move.8 2005-08-01 21:35:24.0 +0200
@@ -399,6 +399,18 @@
.B packages
will generate Contents files.
+.TP
+.BR SIGNINGKEY=
+If this is set to non-empty string, then
+.B packages
+will sign generated Release files with specified signing key. You
+must install gnupg before enabling this option. With current apt
+you should list compression
+.B none
+in
+.B PKGCOMP
+directive, otherwise apt will complain about missing files.
+
.PP
For the
.I sync
diff -urN apt-move-4.2.23.orig/apt-move.conf apt-move-4.2.23/apt-move.conf
--- apt-move-4.2.23.orig/apt-move.conf 2004-11-21 23:23:15.0 +0100
+++ apt-move-4.2.23/apt-move.conf 2005-08-01 21:31:08.0 +0200
@@ -45,4 +45,7 @@
# Set this to yes to make apt-move generate Contents files.
CONTENTS=no
+# Set this to key name to be used for signing Release files.
+SIGNINGKEY=
+
# End Configuration --
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311209: Default DB_CONFIG should be created
Package: slapd Version: 2.2.23-6 Hello Torsten, thanks for switching to bdb, I did that few days ago as 'sub' indexes do not work quite reliably in 2.2's ldbm. There is one problem, that DB_CONFIG is put (should be put...) in /var/lib/ldap, not into backends which were switched from ldbm to bdb. Something based on get_database_list is needed, like slapcat slapadd loops do... Due to this subsequent slapadd failed on ~5th entry as it was run without any DB_CONFIG file. I had to copy DB_CONFIG from /usr/share/slapd myself. And BTW, there is something wrong with this copy anyway - DB_CONFIG was not copied into /var/lib/ldap either (it is just directory with some old ldap database from April, and there is no DB_CONFIG here...). And what's worse, on rerunning configuration it skipped slapadd step, so I was left with /var/lib/slapd empty (besides DB_CONFIG file I just copied there). Fortunately rerunning 'slapadd /var/backups/slapd-2.2.23-5/ou=usermap,o=cvut,c=cz.ldif' was done with its job in few minutes. Thanks, Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310907: fp-compiler uninstallable if gpc is installed
Package: fp-compiler Version: 2.0.0-1 Severity: important Justification: package cannot coexist with gpc Tags: patch Hello, please apply this patch to the postinst script, otherwise installation fails with: (Reading database ... 293637 files and directories currently installed.) Unpacking fp-compiler (from .../fp-compiler_2.0.0-1_i386.deb) ... Setting up fp-compiler (2.0.0-1) ... update-alternatives: slave link name /usr/share/man/man1/pc.1.gz duplicated dpkg: error processing fp-compiler (--configure): subprocess post-installation script returned error exit status 2 Errors were encountered while processing: fp-compiler E: Sub-process /usr/bin/dpkg returned an error code (1) Some errors occurred while unpacking. I'm going to configure the packages that were installed. This may result in duplicate errors or errors caused by missing dependencies. This is OK, only the errors above this message are important. Please fix them and run [I]nstall again Press enter to continue. as it tries to use 'fpc.1.gz' link name in /etc/alternatives, although correct name (and one used by gpc) is 'pc.1.gz'. Thanks, Petr Vandrovec --- /tmp/fp-compiler.postinst.bad 2005-05-26 22:57:15.0 +0200 +++ /var/lib/dpkg/info/fp-compiler.postinst 2005-05-26 22:53:50.0 +0200 @@ -7,7 +7,7 @@ # add alternative update-alternatives \ --install /usr/bin/pc pc /usr/bin/fpc 20 \ ---slave /usr/share/man/man1/pc.1.gz fpc.1.gz /usr/share/man/man1/fpc.1.gz +--slave /usr/share/man/man1/pc.1.gz pc.1.gz /usr/share/man/man1/fpc.1.gz # create link ln -sf $FPCDIR/ppc386 /usr/bin/ppc386 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304812: slapadd takes days due to its sched_yield use
Torsten Landschoff wrote: Hi Peter, On Fri, Apr 15, 2005 at 05:58:17PM +0200, Petr Vandrovec wrote: slapd/slapadd use sched_yield on places where it really should not be idling. Due to this upgrade from 2.1.30 to 2.2.23 takes more than 1 day on our 10 objects tree Erm. Wow! we have, with about 40 indexed attributes (after one day I gave up, attached debugger to slapadd and overwrite sched_yield procedure in slapadd with 'ret'; import finished ~1 hour after I did that). Nice. :) Could you please check if the new slapadd -q option in 2.2.23-2 improves the situation for you? I've tried it on my system at home, and it indeed improves situation a lot - so I think that you can close this bug, slapadd -q seems sufficiently cut time down when box is idle during import. Only strange thing is relation between dbsync/dbnosync of ldbm backend and time to perform import. With dbnosync it took 2h04m18s to import data with 'slapadd -q', with 'dbsync 50 30 1' it took 50m35s, with 'dbsync 5 30 1' 39m30s, and with 'dbsync 1 30 1' it took 1h27m12s. User time consumed was always 2m34s-2m35s, and system time 2m2s-2m10s. So even in best case it spent 35 minutes of import time by waiting :-( Thanks, Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304812: slapadd takes days due to its sched_yield use
Package: slapd
Version: 2.2.23-1
Hello,
slapd/slapadd use sched_yield on places where it really
should not be idling. Due to this upgrade from 2.1.30 to
2.2.23 takes more than 1 day on our 10 objects tree
we have, with about 40 indexed attributes (after one day
I gave up, attached debugger to slapadd and overwrite
sched_yield procedure in slapadd with 'ret'; import
finished ~1 hour after I did that).
So I created shared library with function below, and
LD_PRELOADed it before upgrading replicas - replicas
were upgraded in about 1h15m, so I assume that slapadd
without killing sched_yield would take at least 4 days
with our configuration, which seems a bit too long to me.
It would be nice if upstream could eliminate at least
some useless sched_yield from code (if not all these
calls, I do not believe they are doing anything good
on 2.6.x kernels). Or you should warn users that
slapadd can take days, maybe weeks.
/*
%.so: %.c
gcc -W -Wall -O2 -shared -o $@ $ -ldl
*/
#define _GNU_SOURCE
#include dlfcn.h
int sched_yield(void) {
return 0;
}
Thanks,
Petr Vandrovec
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
