Bug#345196: libneon
On 02/26/06 19:28, Robert Millan wrote: > libneon24 is missing as well. Please, could you build with > libneon25-dev on next upload? Subversion 1.3.0 with a dependency on libneon25 is has been uploaded and is currently in the NEW queue. Troy pgphEWFX2LeJQ.pgp Description: PGP signature
Bug#352139: getopt optional arg does not work as documented
Package: glibc
Severity: normal
On sid with libc 2.3.5-13 the getopt man page states:
Two colons mean an option takes an optional arg; if there is text in
the current argv-element, it is returned in optarg, otherwise optarg
is set to zero. This is a GNU extension.
However, this does not seem to be the case.
tst1.c
-
int
main (int argc, char **argv)
{
int a = 0;
int opt;
opterr = 0;
while ((opt = getopt (argc, argv, "a::")) != -1)
switch (opt)
{
case 'a':
a = 1;
printf("a arg is: %s\n", optarg);
break;
default:
printf("bad arg\n");
exit(1);
}
return 0;
}
When run:
[EMAIL PROTECTED]:/tmp$ a.out -a
a arg is: (null)
[EMAIL PROTECTED]:/tmp$ a.out -a hello
a arg is: (null)
According to the man page, I would expect to see the second example to
output hello.
I have been able to get it to work like one would expect, by using
argv[optind] instead of optarg, i.e.:
printf("a arg is: %s\n", argv[optind]);
When run with the change:
[EMAIL PROTECTED]:/tmp$ a.out -a
a arg is: (null)
[EMAIL PROTECTED]:/tmp$ a.out -a hello
a arg is: hello
This behavior is specifically different that what's documented in the
man page, and in /usr/include/getopt.h. Both say the argv-element
should be in optarg not in argv. I have also compiling using
-std=gnu9x to ensure that I'm getting all of the GNU extensions, with
the same results.
Thanks,
Troy
pgpy5pMwmBYE7.pgp
Description: PGP signature
Bug#337871: FTBFS (alpha): invalid lvalue in assignment
tags 337871 +patch upstream thanks I just got access to an Alpha this week. This is already fixed in a new upstream version. However, it has a couple of other issues I need to resolve before the upload, which should be soon. Troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343142: Changing severity to wishlist
severity 343142 wishlist
thanks
On 12/30/05 14:07, Jason Dorje Short wrote:
> This is a major problem. Not being able to use the output of `date`
> within subversion makes the date diff useless for many purposes.
> And not being able to do `svn diff -r {yesterday}` means a very
> user-friendly feature of CVS is gone.
Actually, you can use the date command, you just need to use a FORMAT
modifier. For example 'date +%Y-%m-%d' will give you the desired
output in a format svn can understand.
I'm changing the severity to whishlist because there is no specific
defect. There is a request for a change in behavior. I'll try
to summarize here:
1. svn -r to understand several different date formats.
a) specifying the month in English i.e. {December}.
b) the unformated output of the date command, i.e:
Thu Jan 12 09:51:37 MST 2006
The month one is a little tricky because different locals can have
different spelling for months names.
Using the unformated output of the date command would be a nice
feature.
2. svn -r to understand keywords, such as yesterday.
I will make sure to forward all of your requests to the upstream
subversion developers. Please let me know if I missed anything.
Troy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338403: requesting more info
tags 338403 + moreinfo unreproducible I have been unable to reproduce your exact issue. I have seen the same symptoms in which you are forced to do an update to the same revision you are currently on before you are allowed to do a check-in before. Although, I haven't seen it recently. If you can give me more information maybe we can track this down. Do you still see the problem on 1.2.3dfsg1-3? What format is your repo in BDB or FSFS? Is it local or remote? If you are accessing it remotely how are you accessing it, svn, ssh, etc? And just to make sure I'm using your rough test case in the same way. #> mkdir one #> touch one/a one/b #> svn add one #> svn ci -m "tst" #> svn mv one two #> svn ci -m "tst" Thanks, Troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350756: invalid option in example bip.conf
Package: bip Version: 0.5.0-1 Severity: minor On line 38 in bip/examples/bip.conf.gz is this option: #no_backlog = false;# disable backlog If you attempt to use it, set to false or true, bip gives the error: Parse error line 39, unknown character 'n' 31-01-2006 08:14:11 FATAL: Parse error near n, line 39 Thanks, Troy pgpUjRwBIk6X2.pgp Description: PGP signature
Bug#302031: status update
Hello Sven, I just realized that Max and I both neglected to cc -submitter. We are unable to reproduce this issue. Can you still reproduce the problem on a current version? When you have a minute can you take a quick look at this bug and give us a update. Thanks for the assistance!! Troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337871: FTBFS (alpha): invalid lvalue in assignment
I lied earlier, we do need the patch Ben submitted (the chroot I was using wasn't updated and didn't show the bug). The problem is there is no "good" way to patch it at the debian level, because the gdb included in crash is shipped as a gzip tarball that gets unpacked at build time. It's much easier to submit the patch upstream and get a fixed versions there, especially because upstream is so responsive. I submitted the patch upstream today, so we should have a new version fairly soon. Thanks, Troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331700: libjudy-dev: a few important lines are missed in man pages
tags 331700 +upstream +pending thanks Thank you very much for the patch, and catching this bug! Unfortunately the man pages are actually generated during the build so patching the generated file is not the best approach. The fix I used is to just strip the .C using sed when the file is generated in doc/Makefile.am. I have applied the fix upstream and it will be included in the next upload. Again, thank you for the bug report! Troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303855: lcrash: fails to set up for dump access
On 04/09/05 09:54, Mario Holbe wrote: > > trying to load a dump saved via savedump (dumputils 0.4-3) into lcrash > fails: Hum.. It looks like there is a problem in the lcrash compression handling. It will be a few more days before I can get a 2.4 kernel running to try to duplicate this bug. In the mean time, can you try a couple of things? 1. Can you bring up lcrash on the live machine rather than the dump? i.e. lcrash -m /boot/System.map-2.4.27 -t /boot/Kerntypes-2.4.27 2. If your kernel was built debug (-g), you could try to see if the "crash" debugger can read the dump as a workaround. It's packaged as "crash". Thanks, Troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281779: patch to fix FTBS
Tags: patch The attached patch is the most minimal change to fix the FTBS. It simply removes the cruft that prevents the library from being installed in the correct directory. Troy diff -urN glui-2.2/debian/rules.vars new/debian/rules.vars --- glui-2.2/debian/rules.vars 2005-03-18 09:59:30.570101002 -0700 +++ new/debian/rules.vars 2005-03-18 10:00:40.993973392 -0700 @@ -5,7 +5,7 @@ VERSION := 2.2 MAJOR := 2 -LIBGLUI := libglui$(MAJOR)c102 +LIBGLUI := libglui$(MAJOR) LIBGLUI_DEV := libglui-dev # Paths
Bug#281779: My mistake
Sorry, I didn't see the package rename so please ignore the above patch. My *BIG* mistake. Troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298961: Patch to remove non-free font
tag 298961 + patch
thanks
I removed the non-free font from the .orig.tar.gz, then I made the
attached patch to fix this problem. I then tested all of the individual
epplets to make sure they look ok, and they do.
Troy
diff -urN o/epplets-0.8.cvs.20040805/debian/changelog
x/epplets-0.8.cvs.2004080501/debian/changelog
--- o/epplets-0.8.cvs.20040805/debian/changelog 2004-08-05 21:38:42.0
-0600
+++ x/epplets-0.8.cvs.2004080501/debian/changelog 2005-03-18
12:56:36.856324468 -0700
@@ -1,3 +1,10 @@
+epplets (0.8.cvs.20040805-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * Removig non-free aircut3.ttf font from upstream package (Closes: #298961)
+
+ -- Troy Heber <[EMAIL PROTECTED]> Fri, 18 Mar 2005 11:42:42 -0700
+
epplets (0.8.cvs.20040805-1) unstable; urgency=medium
* New CVS build. Medium urgency for libtiff4 crap, Closes: #262850
diff -urN o/epplets-0.8.cvs.20040805/debian/control
x/epplets-0.8.cvs.2004080501/debian/control
--- o/epplets-0.8.cvs.20040805/debian/control 2004-08-05 21:17:09.0
-0600
+++ x/epplets-0.8.cvs.2004080501/debian/control 2005-03-18 12:45:09.275030755
-0700
@@ -8,7 +8,7 @@
Package: epplets
Section: x11
Architecture: any
-Depends: libepplet0 (= ${Source-Version}), ${shlibs:Depends}, enlightenment
(>= 0.16.5-1)
+Depends: libepplet0 (= ${Source-Version}), ${shlibs:Depends}, enlightenment
(>= 0.16.5-1), ttf-bitstream-vera
Suggests: eeyes
Description: The Epplets for the Enlightenment Window Manager
Epplets are small applets for the Enlightenment Window Manager. Epplets
Binary files o/epplets-0.8.cvs.20040805/epplets/aircut3.ttf and
x/epplets-0.8.cvs.2004080501/epplets/aircut3.ttf differ
diff -urN o/epplets-0.8.cvs.20040805/epplets/E-Clock.ABOUT/MAIN
x/epplets-0.8.cvs.2004080501/epplets/E-Clock.ABOUT/MAIN
--- o/epplets-0.8.cvs.20040805/epplets/E-Clock.ABOUT/MAIN 1999-10-13
16:16:47.0 -0600
+++ x/epplets-0.8.cvs.2004080501/epplets/E-Clock.ABOUT/MAIN 2005-03-18
12:06:33.947644582 -0700
@@ -1,11 +1,11 @@
-
+
E-Clock
-
+
Small Analogue Clock
-
+
By The Rasterman - 1999
diff -urN o/epplets-0.8.cvs.20040805/epplets/E-Cpu.ABOUT/MAIN
x/epplets-0.8.cvs.2004080501/epplets/E-Cpu.ABOUT/MAIN
--- o/epplets-0.8.cvs.20040805/epplets/E-Cpu.ABOUT/MAIN 2001-03-16
11:47:13.0 -0700
+++ x/epplets-0.8.cvs.2004080501/epplets/E-Cpu.ABOUT/MAIN 2005-03-18
12:06:47.466256347 -0700
@@ -1,11 +1,11 @@
-
+
E-Cpu
-
+
The Flaming Cpu monitor.
-
+
By The Rasterman - 1999
diff -urN o/epplets-0.8.cvs.20040805/epplets/Emix.ABOUT/MAIN
x/epplets-0.8.cvs.2004080501/epplets/Emix.ABOUT/MAIN
--- o/epplets-0.8.cvs.20040805/epplets/Emix.ABOUT/MAIN 1999-10-19
07:46:24.0 -0600
+++ x/epplets-0.8.cvs.2004080501/epplets/Emix.ABOUT/MAIN2005-03-18
12:10:09.796450903 -0700
@@ -1,11 +1,11 @@
-
+
Emix
-
+
Simple audio mixer
-
+
(c) 1999 Roberto Machorro
diff -urN o/epplets-0.8.cvs.20040805/epplets/E-Mixer.ABOUT/MAIN
x/epplets-0.8.cvs.2004080501/epplets/E-Mixer.ABOUT/MAIN
--- o/epplets-0.8.cvs.20040805/epplets/E-Mixer.ABOUT/MAIN 1999-11-29
14:50:40.0 -0700
+++ x/epplets-0.8.cvs.2004080501/epplets/E-Mixer.ABOUT/MAIN 2005-03-18
12:07:12.401540356 -0700
@@ -1,14 +1,14 @@
-
+
E-Mixer
-
+
An Enlightenment Volume Control.
-
+
By Tom Gilbert - 1999
diff -urN o/epplets-0.8.cvs.20040805/epplets/E-MoonClock.ABOUT/MAIN
x/epplets-0.8.cvs.2004080501/epplets/E-MoonClock.ABOUT/MAIN
--- o/epplets-0.8.cvs.20040805/epplets/E-MoonClock.ABOUT/MAIN 1999-11-20
12:30:36.0 -0700
+++ x/epplets-0.8.cvs.2004080501/epplets/E-MoonClock.ABOUT/MAIN 2005-03-18
12:07:23.943209000 -0700
@@ -1,11 +1,11 @@
-
+
E-MoonClock
-
+
An Enlightenment Epplet showing the current phase of the moon.
-
+
By Michael Lea - 1999
diff -urN o/epplets-0.8.cvs.20040805/epplets/E-Mountbox.ABOUT/MAIN
x/epplets-0.8.cvs.2004080501/epplets/E-Mountbox.ABOUT/MAIN
--- o/epplets-0.8.cvs.20040805/epplets/E-Mountbox.ABOUT/MAIN2000-03-18
09:17:01.0 -0700
+++ x/epplets-0.8.cvs.2004080501/epplets/E-Mountbox.ABOUT/MAIN 2005-03-18
12:08:31.675265087 -0700
@@ -1,12 +1,12 @@
-
+
E-Mountbox
-
+
"The Nicest Mount Epplet Around" (tm).
-
+
Version 0.4
Written by Christian Kreibich - 1999
@@ -28,7 +28,7 @@
-
+
The Mountbox was designed with the the way Enlightenment's iconbox
works in mind. For every user-mountable device you have in your system, the
@@ -52,7 +52,7 @@
-
+
You can configure the images for the Mountbox background, the types of devices
that the Mountbox recognizes and icons for these types using the configuration
@@ -76,7 +76,7 @@
using the control elements below.
-
+
By default, E-Mountbox ejects media after unmounting. You can disable
this feature in the configuration dialog completely or enable manual
diff -urN o/epplets-0.8.cvs.20040805/epplets/E-NetFlame.ABOUT/MAIN
x/epplets-0.8.cvs.20040805
Bug#311065: lcrash: support for more arches.
On 05/28/05 11:03, Kurt Roeckx wrote: > However, in the source I seem to find support for: > alpha arm i386 ia64 ppc64 s390 s390x amd64 lkcd & lcrash have had a long history of getting code contributed to them from various people. However, I can assure you that just because there are some ifdefs for certain architects does not imply that those architectures are supported or will even compile. > Would it be possible to support more arches? Like alpha and > amd64. Eventually yes. There is active development upstream for lcrash and lkcd. Right now we are working on a major re-write in the 7.X.X development branch, which involves completely re-architecting how lkcd & lcrash work at a core level, additional architectures will come after we complete most of this work. > PS: I find the ppc64 weird since powerpc itself doesn't seem to be > supported? Not really sure, I don't have any ppc hardware to test on. powerpc might work or it might not. Since it's not spelled out upstream, and I don't have powerpc hardware to test crash dumps on I'm going to stick with not. Again, once we finish the major 7.X.X dev work upstream more functionality/archs will come. Troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311065: change severity to wishlist.
severity 311065 wishlist thanks Support for as many architectures as feasible will be added as LKCD & lcrash development progresses. Upstream is currently working on a new development branch with many new features, so it will be some time before the next major release. Troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302031: tagging bug
tags 302031 moreinfo unreproducible thanks We need more information to reproduce this bug, so I'm tagging it moreinfo and unreproducible. Troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#279711: status update
tags 279711 moreinfo unreproducible thanks There is not enough information in this report to reproduce this bug. Is this still a bug you are facing or can this report be closed? If this is still a problem, can you provide more information. Troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316143: subversion: segfault when add a directory
Hello Carlo, Can you try to duplicate this problem after setting your local to "C" or "en_US"? The only way I've been able to duplicate this is by changing the locale as in bug #323376. Thanks, Troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297526: kernel-patch-lkcd: Doesn't build Kerntypes
On 03/03/05 12:36, Russell Stuart wrote: Hello Russell, I recently started co-maintaining the kernel-patch-lkcd package with Micah. I am also one of the upstream developer and administrator. > What we are talking about here is adding a line of them form: > > Note: on some architectures Kerntypes is included in the > compiled kernel's binary package, and will be installed > into /boot for you. > > It isn't a big deal. As Micah stated the best place to resolve this is upstream. > Yes, I did notice the patches are changing rapidly. What is > causing all the changes? Upstream we recently forked off a new development branch and there are a lot of changes in that branch that are very beneficial to LKCD crash dumping in Debian. Micah and I are working very hard to do a clean up and a reword to provide a complete and solid crash debugging environment for Debian. As such we have been doing a lot of work on all of the related packages. You correctly pointed out this issue, and I think we all agree this will make for a nice enhancement. > > I've talked with upstream about it and they are considering it, > > probably will be able to do it pretty quickly. I'll work on a complete upstream patch for this reasonably soon. I have a few higher priority patches to write first. > Actually - I was looking at it from the reverse angle - it was a feature > that has been removed and should not of been. I personally think there are two valid schools of thought here. If you are a "lcrash" user you would miss not automatically having /boot/Kerntypes-uname. However, if you are a "crash" user then you don't want to clutter up your boot directory with unnecessary crap that you don't have any use for. I think each argument makes a valid point. Overall, it's probably not that much of an inconvenience for a crash user. I'm not sure how I'll end up writing the patch, I'm considering making it a config option, we'll see when I sit down to write it. > In that context I agree the priority I assigned it was wrong. OK, I'm going to treat this as a general feature request, I'll do it when I have a free moment. > If the choice is between upstream and dpatches, this is the > right way to proceed. I think we all agree upstream is where the feature should be added. Thanks, Troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373877: me too
I also want to jump on the "please package 2.6.4" bandwagon. When you do please add the libgtkspell-dev build-depends so we cat get gtkspell functionality. 2.6.4 adds GTKSpell functionality for the input-box, which is a feature I really need. Thanks, Troy pgpLn3ROYjdAe.pgp Description: PGP signature
Bug#373663: keys have become toggles
Package: xfce4 Version: 4.3.90.1-2 Severity: normal I just upgraded to 4.3.90.1 (Xfce 4.4 BETA1) and noticed that some of my keyboard shortcuts have become toggles. I have the following "Window shortcuts": "Workspace 1" "Alt+F1" "Workspace 2" "Alt+F2" ... In previous versions, pressing Alt+F1 would take me from any workspace to "Workspace 1" even if I was already on "Workspace 1". However, the behavior has now changed to toggle between "Workspace 1" and the previously visited workspace. Yuck, when I bind a key to take me to "Workspace 1", I expect it to do just that. I believe this behavior is a bug. However, if you think it should be wishlist feel free to adjust the severity. BTW: I also had the horrible upgrade experience outlined in #315662, I really hope that some of this can be resolved for etch, even if upstream is not providing any path. It's not very friendly to loose most of your desktop settings. Thanks, Troy pgpKdSt29XNST.pgp Description: PGP signature
Bug#370482: multiple locations for keyboard shortcuts
Package: xfce4 Version: 4.3.90.1-2 Severity: wishlist I just upgraded to 4.3.90.1 (Xfce 4.4 BETA1) and noticed that some of my keyboard shortcuts quit working. I looked at Xfce Settings Manager -> Windows Manager -> Keyboard, my profile was still intact after the upgrade and my keybindings for "Alt-F1" and "Alt-F2" were there, and there was no conflicting command with the same keybindings. However, "Alt-F1/F2" reverted to default Xfce behavior, Xfce help and run command, respectively. I took me quite some time to discover Xfce Settings Manager -> Keyboard -> Shortcuts. In there there is a "Default" shortcut profile that seems to have precedence over the Windows manger keyboard shortcuts. So, my wish list item for upstream would be to merge these into a single keyboard shortcuts. If that is not possible then at least on upgrade, if a new default shortcut exists make sure that it's not clobbering an existing previously defined and working shortcut defined by the user. Thanks, Troy pgp4So6yMBkqG.pgp Description: PGP signature
Bug#401124: [m68k] alignment problems causing segfaults
Severity: normal thanks On 12/01/06 00:40, Roman Zippel wrote: > A few structures are not evenly dividable by word_t and thus too > little memory is allocated. I'm trying to figure out how this is a bug in Judy. It seems like the allocator is simply broken, what does it do for a packed structure? Is there another bug filed against libc for this as well? I'm down grading the severity to normal for now. I'm extremely reluctant to make this change because it really seems like treating the symptom rather than the root cause. Thanks, Troy pgp7ics5RnzU4.pgp Description: PGP signature
Bug#387610: subversion: FTBFS on ia64
On 09/22/06 00:04, Philip Martin wrote: > The error message is the one that would occur if Subversion's DB_ENV > cache failed in some way, and since most of the tests are being run > with FSFS the failing test might be the only one that exercises the > cache. Perhaps gcc is miscompiling Subversion's cache code; how about > building without optimisation on ia64? It's not an optimization bug, compiling O0 does not help. We know that lt-fs-base-test 2, creates and closes a new db, it then creates a new fs object and tries to re-open the db. The call to apr_hash_get returns NULL, so it's not finding the object in the hash. The call continues on and tries to open the db using libdb4.4 via __env_open_pp, which eventually leads to __envreg_add and the error message. I haven't built a debug version of libdb yet, I'm going to do that this morning and walk through. From, what I'm guessing I don't think the apr_hash_get lookup should have failed, so the problem might be that direction, I need to build libapr debug as well. Troy pgp2M0VTqZ6L9.pgp Description: PGP signature
Bug#388806: multi battery support for xfce4-battery-plugin
Package: xfce4-battery-plugin
Version: 0.4.0-3
Severity: wishlist
The attached patch written by Alex Williamson adds ACPI multi battery
support to the plugin. Without the patch the plugin only detects and
reports the status of one battery. Please consider adding it to the
debian package and forwarding it upstream for inclusion.
Thanks,
Troy
diff -urpN -urN -X /home/troyhebe/dontdiff
xfce4-battery-plugin-0.4.0/panel-plugin/battmon.c new/panel-plugin/battmon.c
--- xfce4-battery-plugin-0.4.0/panel-plugin/battmon.c 2006-04-27
13:10:40.0 -0600
+++ new/panel-plugin/battmon.c 2006-09-22 09:48:54.0 -0600
@@ -213,19 +213,23 @@ detect_battery_info(t_battmon *battmon)
/* First check to see if ACPI is available */
if(check_acpi()==0) {
/* ACPI detected */
- int i;
+ int i, present_cnt = 0;
battmon->method = BM_USE_ACPI;
+ apm.battery_percentage=0;
+ apm.battery_time=0;
for (i=0;ipercentage;
- apm.battery_time=acpistate->rtime;
+ read_acpi_info(i);
+ read_acpi_state(i);
+
+ if (acpiinfo->present) {
+ apm.battery_percentage+=acpistate->percentage;
+ apm.battery_time+=acpistate->rtime;
+ present_cnt++;
+ }
}
+
+ if (present_cnt)
+ apm.battery_percentage /= present_cnt;
return TRUE;
}
if(apm_read(&apm) == 0) {
@@ -302,16 +306,36 @@ update_apm_status(t_battmon *battmon)
(GSourceFunc) update_apm_status, battmon);
}
if(battmon->method == BM_USE_ACPI) {
- int i;
+ int i, rate = 0, present_cnt = 0;
+
acline = read_acad_state();
- for (i=0;imethod = BM_USE_ACPI;
+ charge=0;
+ time_remaining=0;
+ if (!acline) {
+ for (i=0;iprate;
+ }
}
- /*read_acpi_state(0);*/ /* only consider first battery... */
- if (batt_count) {
- charge = acpistate->percentage;
- time_remaining = acpistate->rtime;
+ for (i=0;ipresent) {
+ charge+=acpistate->percentage;
+ if (acpistate->rtime)
+ time_remaining+=acpistate->rtime;
+ else if (!acline)
+ time_remaining+=
+ ((acpistate->rcapacity/rate)*60);
+ present_cnt++;
+ }
}
+
+ if (present_cnt)
+ charge /= present_cnt;
}
#ifdef __linux__
else {
diff -urpN -urN -X /home/troyhebe/dontdiff
xfce4-battery-plugin-0.4.0/panel-plugin/libacpi.c new/panel-plugin/libacpi.c
--- xfce4-battery-plugin-0.4.0/panel-plugin/libacpi.c 2006-04-27
13:10:40.0 -0600
+++ new/panel-plugin/libacpi.c 2006-09-22 09:50:20.0 -0600
@@ -220,9 +220,9 @@ int check_acpi(void)
sprintf (batteries[batt_count], "/proc/acpi/battery/%s/state", name);
if (!(acpi = fopen (batteries[batt_count], "r"))) {
- sprintf (batteries[batt_count], "/proc/acpi/battery/%s/status", name);
+ continue;
}
-else fclose (acpi);
+fclose (acpi);
#if 0
if (!(acpi = fopen ("/proc/acpi/battery/1/status", "r")))
@@ -271,21 +271,42 @@ int check_acpi(void)
int read_acad_state(void)
{
#ifdef __linux__
- FILE *acpi;
+ DIR *acdir;
+ struct dirent *adapter;
+ FILE *acpi = NULL;
+ char ac_adapters[128];
char *ptr;
char stat;
- if (!(acpi = fopen ("/proc/acpi/ac_adapter/0/status", "r")))
-if (!(acpi = fopen ("/proc/acpi/ac_adapter/ACAD/state", "r")))
- if (!(acpi = fopen ("/proc/acpi/ac_adapter/AC/state", "r")))
-if (!(acpi = fopen ("/proc/acpi/ac_adapter/ADP1/state", "r")))
- if (!(acpi = fopen ("/proc/acpi/ac_adapter/AC0/state", "r")))
- if (!(acpi = fopen ("/proc/acpi/ac_adapter/ADP0/state", "r")))
- if (!(acpi = fopen ("/proc/acpi/ac_adapter/C11B/state", "r")))
- return -1;
+ acdir = opendir ("/proc/acpi/ac_adapter");
+ if (acdir == 0)
+ {
+#ifdef DEBUG
+ printf("DBG:No AC Adapter. /proc/acpi/ac_adapter not found!\n");
+#endif
+ return 2;
+ }
+
+ while ((adapter = readdir (acdir)))
+ {
+ char *name = adapter->d_name;
+
+ /* skip . and .. */
+ if (!strncmp (".", name, 1) || !strncmp ("..", name, 2)) continue;
+
+ sprintf (ac_adapters, "/proc/acpi/ac_adapter/%s/state", name);
+ if (!(acpi = fopen (ac_adapters, "r")))
+ continue;
+
Bug#387610: subversion: FTBFS on ia64
On 09/22/06 16:32, Philip Martin wrote:
> The first time the breakpoint is reached it's from the
> svn_test__create_fs line, the second time it's from the
> svn_fs_open_berkeley line. The key has the same value in each case,
> and the second time that value is present in the cache, so the hash
> lookup doesn't return NULL.
Hi Philip,
It looks like the hash is getting updated fine during the initial
create. However, on the second one it goes through init again and
comes up with a new ht pointer. Digging into it I think I've found the
problem in libapr0, although I was kind of rushed and didn't have time
to test it because I'm leaving for a trip and out the door now.
In any case, this looks like the culprit.
apr_uint32_t apr_atomic_cas(volatile apr_uint32_t *mem, long with,
long cmp)
{
long prev;
#if APR_HAS_THREADS
apr_thread_mutex_t *lock = hash_mutex[ATOMIC_HASH(mem)];
if (apr_thread_mutex_lock(lock) == APR_SUCCESS) {
prev = *(long*)mem;
if (prev == cmp) {
*(long*)mem = with;
}
apr_thread_mutex_unlock(lock);
return prev;
On a 64-bit machine we end up with a size mismatch and a compare of
junk. mem is defined as a pointer to a 32-bit, then a cast to long
64-bit in this case. prev ends up with junk it it and fails the
compare prev == cmp that passes on a 32-bit box. In any case this is a
bug, not positive if it's the only one.
Troy
pgphbL8j1mISo.pgp
Description: PGP signature
Bug#349130: Second request for new version
I would like to jump on the bandwagon and request an update, xsensors is now at version 0.50 upstream. Since I have the smsc47b397 I really need the new version. Thanks, Troy pgpGwqaXHyGQ0.pgp Description: PGP signature
Bug#381885: require/recommend a dictionary
Package: xchat Version: 2.6.4-2 Severity: minor It seems that depending libgtkspell, is not enough to obtain gtkspelling support in the input box. A dictionary is also required. I believe that xchat can use either enchant or aspell as it's dictionary but it seems to default to using libgtkspell and aspell when configured with --enable-spell with no option. It might be a good idea to require aspell or at least recommend it. Thanks, Troy pgpbf6sLpwDMN.pgp Description: PGP signature
Bug#379834: xfce4 uninstallable
Package: xfce4 Version: 4.3.90.2 Severity: normal xfce4 is currently uninstallable: The following packages have unmet dependencies: xfce4: Depends: xfdesktop4 (>= 4.3.90.1-1) xfdesktop4: Depends: libxfce4util2 (>= 4.3.90.1) Which leads you to the end: libxfce4util2 has been replaced by libxfce4util4 Thanks, Troy pgp0iKYcQM2bx.pgp Description: PGP signature
Bug#390716: wishlist features
Package: bip Version: 0.5.3-3 Severity: wishlist I have a couple wishlist items :-). First, and most important, I would love the ability to keep bip from printing the lines from "-bip" when giving me a backlog, because they always give me falls hits on my nick in the join messages it prints.. A separate but related request would be an option to prevent new tabs (channels) from popping up when I reconnect to a running bip. For example when I reconnect I always get a "ChanServer", "NickServ", "MemoServ", and "-bip" tabs for each server it holds a connection to. I would adore an option to prevent those from coming up as well. I'm a very happy user of bip. These are just a couple of features I would like to see. Thanks, Troy pgps9EO6Yro30.pgp Description: PGP signature
Bug#390716: wishlist features
On 10/02/06 23:00, Arnaud Cornet wrote: > To sum up, you want only the lines when people talk ? That could be an > option I guess. Exactly. > I don't quite understand there, you want all windows to open (channels, > personnal messages) except those from ChanServ and NickServ ... ? > Or do you want only channels to be replayed and no private message. Hrm.. how do I explain this. I don't mind the windows the first time bip gets them, i.e. when it connects to the server for the first time. The part that annoys me is this situation: 1. fire up bip, it connects to a few servers. 2. client connects to bip 3. I get all my auto connect channels plus the memoserv, nickserv, "-bip", etc. 4. I close all of the *serv and "-bip" tabs/windows. 5. I disconnect the client from bip, but bip is still running. 6. The client reconnects to bip and I get all of the *serv and the "-bip" tabs/windows again. I want bip to honor the close of the windows/channels. I understand if I restart bip I will automatically get those again, I just don't want them between sessions. This works in the other direction now. If I connect to bip and join a new channel the disconnect. When I reconnect the client that channel is there. I want the same thing. If I close a channel I don't want it to come back on future connections. In other words I want my irc client to look like I just left it running even though I closed it and opened it up again. > If you recieve a private message when you have no client connected, when > you connect to bip you do want the private message window to popup > right? Yes. I don't mind them coming up for a *new* event. Did that clarify the request? Troy pgpwWpUDRFrV7.pgp Description: PGP signature
Bug#430954: RM: lcrash -- FTBFS; dead upstream; functionality provided by crash package
Package: ftp.debian.org Severity: serious lcrash is virtually dead upstream, it's sole function is to debug LKCD type crash dumps. The "crash" package provides similar functionality but can be used to debug many crash dump formats. lcrash also recommends the LKCD kernel patch which is not been ported to any current kernels, as kdump has been mainlined. Please remove lcrash. Thanks, Troy signature.asc Description: Digital signature
Bug#393503: remove kernel-patch-lkcd
Package: ftp.debian.org Severity: normal Please remove kernel-patch-lkcd from unstable, it is unused and will not apply to the 2.6.18 kernel (Bug#393286). I'm also CC'ing debian-release to request the removal from testing as well. Thanks, Troy pgpEjSYs8woJw.pgp Description: PGP signature
Bug#393023: PAGE_SIZE is undeclared
You can add the crash package to the list for FTBFS on Alpha because PAGE_SIZE has been blocked by the #ifdef __KERNEL__. Using PAGE_SIZE directly from a user space application is broken. However, in my case it's BFD that is indirectly using it by using NBPG defined in ! Troy pgpfwJIr6tJY5.pgp Description: PGP signature
Bug#394267: FTBFS on Alpha
Package: crash Version: 4.0-3.7-1 Severity: grave Crash FTBFS on Alpha because linux-kernel-headers 2.6.18-3 asm/page.h blocks PAGE_SIZE from being defined. See #393023. Troy pgpKxfgEYfDOY.pgp Description: PGP signature
Bug#394381: gdb: FTBFS, indirectly uses PAGE_SIZE
Package: gdb Version: 6.4.90.dfsg-1 Severity: grave gdb FTBFS with: /tmp/p/gdb-6.4.90.dfsg/bfd/trad-core.c:116: error: 'PAGE_SIZE' undeclared (first use in this function) /tmp/p/gdb-6.4.90.dfsg/bfd/trad-core.c:116: error: (Each undeclared identifier is reported only once /tmp/p/gdb-6.4.90.dfsg/bfd/trad-core.c:116: error: for each function it appears in.) make[5]: *** [trad-core.lo] Error 1 gdb contains bfd, and bfd uses NBPG defined in . However, that is just a redefinition of PAGE_SIZE which is no longer defined to user space becasue of #ifdef __KERNEL__, See #393023. Using PAGE_SIZE directly from a user space application is broken because systems now can have variable PAGE_SIZE. The problem is that the clobbered PAGE_SIZE but didn't audit for its dependencies. This will occur on several architectures including Alpha and ia64 when compiled against the new linux-kernel-headers package. I was compiling with version 2.6.18-3. Even gdb-5 upstream has this issue. Troy pgpSW1rg0I49A.pgp Description: PGP signature
Bug#394385: PAGE_SIZE is incorrectly exposed
Package: libc6.1-dev Version: 2.3.6.ds1-6 Severity: grave PAGE_SIZE is no longer exposed to user space in , see Bug#393023. However, defines NBPG to be PAGE_SIZE which prevents packages that use it form building gdb (Bug#394381) and crash (Bug#394267). Thanks, Troy pgpm45mZRDIuk.pgp Description: PGP signature
Bug#394381: gdb: FTBFS, indirectly uses PAGE_SIZE
On 10/20/06 18:20, Daniel Jacobowitz wrote: > I might be wrong, but I think that this is a bug in glibc; I understand > why it can't provide PAGE_SIZE, but it ought to provide NBPG if it's > going to bother to provide "struct user" (a purely legacy format) at > all. It seems like a hideous hack to have to try to compile NBPG in > autoconf. I agree which is why I also filed a Bug #394385 against glibc. I filled both because I'm not positive where this should get handled. I would venture to guess that there should be a patch both in the glibc header and in gdb. Troy pgpjY7FClBU3t.pgp Description: PGP signature
Bug#438377: subversion: svn (or svnadmin) Segfault
On 08/16/07 15:00, Phil R wrote: Hello Phil, I'm just trying to clarify this bug. You are getting a segfault when you run ldd against the subversion binary: > $ ldd -v /usr/bin/svn Do I understand the bug correctly? If so I would like to downgrade the severity of this bug, since it's really ldd that is segfaulting and thus should not be a grave subversion bug since it does not make subversion unusable for a majority of users. I've tried to duplicate this on several architectures and have been unable to. I would like to get some more information about this report, can you run "ldd" against other binaries in /usr/bin? Thanks, Troy signature.asc Description: Digital signature
Bug#428202: update
tags 428202 unreproducible severity 428202 normal I just tried to reproduce this one as well and it works for me on i386 and amd64 on a clean pubilder update, as such I'm changing the severity to normal, especially given CVE-2007-2448. Troy signature.asc Description: Digital signature
Bug#443484: openhpi spams syslog
Package: openhpi Version: 2.6.2-3 Severity: normal openhpi keeps spewing these messages in syslog, until it fills the disk! Sep 10 06:25:47 juno-a openhpid: DEBUG: (sim_injector.c, 265, errorno = 22) Sep 10 06:25:47 juno-a openhpid: DEBUG: (sim_injector.c, 264, error during msgrcv) Sep 10 06:25:47 juno-a openhpid: DEBUG: (sim_injector.c, 265, errorno = 22) Sep 10 06:25:47 juno-a openhpid: DEBUG: (sim_injector.c, 264, error during msgrcv) Sep 10 06:25:47 juno-a openhpid: DEBUG: (sim_injector.c, 265, errorno = 22) Sep 10 06:25:47 juno-a openhpid: DEBUG: (sim_injector.c, 264, error during msgrcv) Sep 10 06:25:47 juno-a openhpid: DEBUG: (sim_injector.c, 265, errorno = 22) Sep 10 06:25:47 juno-a openhpid: DEBUG: (sim_injector.c, 264, error during msgrcv) signature.asc Description: Digital signature
Bug#432467: subversion: svn co on ia64 fails with PROPFIND errors but works just fine on i686
On 07/10/07 07:42, Al Stone wrote: Hi Al! I just tried to duplicate the problem on ia64 and it works for me, with 1.4.2 from etch and 1.4.4 form sid. >>> $ svn co http://llvm.org/svn/llvm-project/llvm/trunk anywhere >>> svn: PROPFIND request failed on '/svn/llvm-project/llvm/trunk' >>> svn: PROPFIND of '/svn/llvm-project/llvm/trunk': could not connect to >>> server (http://llvm.org) This is the error you will get if you are behind a proxy and can not access the machine directly. From your ia64 box can you telnet to port 80 of llvm.org? > Interesting. Non-http works just fine. Is this starting to look > like something on the server side? It looks like you are behind a firewall or a web proxy. Troy signature.asc Description: Digital signature
Bug#398035: 398035: svn_load_dirs
On 08/23/07 10:32, Ross Boylan wrote: > What is the work-around? Is it just for svn-buildpackage, or for > general use of svn_load_dirs. In unstable and testing you can use the svn-load package as a replacement. For the most part it should function as a drop in replacement. Troy signature.asc Description: Digital signature
Bug#400230: Where is svn_load_dirs?
merge 400230 398035 thanks On 11/25/06 00:54, Chun Tian (binghe) wrote: > It seems that there's no svn_load_dirs in recent subversion-tools > package, could you tell me where is it? svn_load_dirs was removed on purpose, see #398035. The script has no copyright notice or license grant, so we're not allowed to distribute it. Troy pgpLjnTUMTbgZ.pgp Description: PGP signature
Bug#355930: Please add ia64 arch
Package: ipmitool Version: 1.8.2-2 Severity: wishlist Please add ia64 as a supported architecture. I've been able to build and utilize ipmitool on ia64 with out any modification to the package. Thanks, Troy pgpBH2KrbRfq4.pgp Description: PGP signature
Bug#394267: FTBFS on Alpha
On 10/23/06 17:50, Julien Danjou wrote: > On Thu, Oct 19, 2006 at 03:30:14PM -0600, Troy Heber wrote: > > Crash FTBFS on Alpha because linux-kernel-headers 2.6.18-3 asm/page.h > > blocks PAGE_SIZE from being defined. See #393023. > > I cannot reproduce this right now. It builds perfectly. > Please send a build log or close this bug. Did you look at PTS? http://buildd.debian.org/fetch.cgi?&pkg=crash&ver=4.0-3.7-1&arch=alpha&stamp=1160779497&file=log This *just* got resolved by the 2.3.6-ds1-7 libc6 upload, see (Bug#394385). Closing, because NBPG is now defined via sysconf. Troy pgpfJmwWp08UU.pgp Description: PGP signature
Bug#394894: libsvn-dev: missing depend??
reassign 394894 medusa forcemerge 394432 394894 tags 394894 patch thanks On 10/23/06 11:20, LaMont Jones wrote: > the following errors show up: > > i486-linux-gnu-gcc -Wall -g -O2 -g -DDEBUG -fPIC -I/usr/local/include > > -I/usr/local/ssl/include -I/usr/include/subversion-1 -I/usr/include/apr-0 > > -I/usr/include/postgresql -L/usr/local/lib -rdynamic -ldl -o postgres.mod > > -module -fPIC -shared postgres.o medusa-trace.o -lsvn_client-1 -lpq -lncp > > -lssl -lpthread The problem is actually the "-I/usr/include/apr-0 " subversion has transitioned from apr0 apr1 and medusa has hardcoded apr0 into the configure script. The correct option is to use arp-config to return the meta information about the system apr library. Patch is attached. Troy --- configure.ori 2006-10-23 13:52:59.0 -0600 +++ configure 2006-10-23 13:53:34.0 -0600 @@ -3418,7 +3418,7 @@ if test -d "/usr/local/ssl/lib" fi CFLAGS="$CFLAGS -fPIC" -CFLAGS="$CFLAGS -I/usr/local/include -I/usr/local/ssl/include -I/usr/include/subversion-1 -I/usr/include/apr-0 -I/usr/include/postgresql" +CFLAGS="$CFLAGS -I/usr/local/include -I/usr/local/ssl/include -I/usr/include/subversion-1 $(apr-config --includes --cppflags) -I/usr/include/postgresql" echo "$as_me:$LINENO: checking for main in -lpthread" >&5 pgpAKwtpQmD07.pgp Description: PGP signature
