Gwave runs but doesn't plot

I just tried building it from source, and the problem persists. I'll try to take a look at the source code, but I'm a novice at this.

Curiously, it decodes well the binary coded formats. I succeeded to plat the included file. I tested all of the source included examples of binary format and each of them plot well. I also tested the non binary examples of input data provided with the source, and had issues with plotting for each of them.

So the results of my experiment with gwave 20090213-1ubuntu1 are :
plotting for binary formats (.raw, etc.) : OK
plotting for ascii formats (spice output, gnucap, etc.) : FAIL

Given that binary formats work, I wonder if it is your system locale which is throwing off the ASCII format parser.

I'm not 100% sure how to test this, but perhaps try opening a terminal and running gwave like this:

LC_ALL=C gwave ...
or
LANG=C gwave ..
or
LOCALE=C gwave ...

(I can't recall which variable is the important one to set to rejig string processing rules).

What is the output of your "locale" command?

I've sent a note to the geda-dev email list linking to this bug. I'm not sure if the upstream maintiner is subscribed or not, but I think he is - and this might get it some attention.

Ok - I thought this kind of bug sounded familiar, it probably came up on the geda-dev list already...

There is a fix committed upstream. Someone probably needs to work up a debdiff to introduce this patch into the Ubuntu package, and (in an ideal world) start the SRU process.

https://sourceforge.net/tracker/?func=detail&atid=1019623&aid=2886359&group_id=211903

I've attached a debdiff of the patch which ought to fix the issue.

Note that the new package drops some build-time gernated files out of the .diff.gz, which I think is for the best.

I've attached the i386 binary build of this package for the OP to test.

I believe some confirmation that the new package fixes the issue will be required if we want to SRU this into Karmic.

Hello Peter!
Thank you so much!

Since my system is 64 bit, I built my own deb with the debdiff package you submitted in post #8, following these instructions : https://wiki.ubuntu.com/UbuntuPackagingGuide/BuildFromDebdiff.

Result : A working gwave :D

I will attach the amd64 gwave build and also a printscreen of fixed gwave displaying V(out) of "data.out".

builds in PPA cleanly: https://launchpad.net/~showard314/+archive/ppa

in case someone wants an apt-getable repository for testing.

Hi,

Please, do not add a patch system to a Debian package, as it makes the change bigger, and less easy to read.
Also, do not delete files, even if they are temporary. Your debdiff should be minimal. In this case, it should contains only the changelog entry, the control update with maintainer and the modification to the source (no patch).

Also, keep in mind that the change has to be uploaded to the development release (lucid), before being able to process the SRU (exact SRU process is described at https://wiki.ubuntu.com/StableReleaseUpdates), so the entry in the changelog whould use lucid instead of karmic.

I'll change the status to incomplete meanwhile. Please put back as new when you have an updated debdiff.

Thanks for your work,
Fabrice

Do you need the .dsc and .diff.gz files, or just the .debdiff?

It seemed against best packaging guidelines just to patch the source-code without using a patch-system, but I can do that if you wish.

The removed files should not have been in the previous package - they were erroenously left over by the binary build, but again.. I can produce a debdiff which leaves them in place.

Is this more what you're after?

Hi,

I only need the debdiff for sponsoring, and this debdiff is a lot better :-)
The general rule in Ubuntu is to keep the same patching system as "upstream", so if the package comes from Debian, we keep what Debian does (that is in this case, nothing)

Thanks,
Fabrice

Hi,

I was trying to reproduce the problem in lucid, and I've not been able to do so: the chart plots correctly with the repo's version, using your data.out file. Here is the version I' am using:
apt-cache policy gwave
gwave:
  Installed: 20090213-1ubuntu1
  Candidate: 20090213-1ubuntu1
  Version table:
 *** 20090213-1ubuntu1 0
        500 http://archive.ubuntu.com lucid/universe Packages
        100 /var/lib/dpkg/status

And the screenshot with the output.

Can you please elaborate a bit?

thnaks,
Fabrice

I'm guessing - as I can't reproduce either, that we would need to set our LC_NUMERIC to a locale which had "," as its decimal point separator.

LC_NUMERIC=de_DE gwave .... ?

NB: That doesn't work on my box, since the C library doesn't support that locale.

Hello,

On Sun, Nov 15, 2009 at 10:50:57PM +0000, Peter Clifton wrote:
> A user has reported an issue with the gwave package in Ubuntu.
> https://bugs.edge.launchpad.net/ubuntu/+source/gwave/+bug/482748
>
>
> Turns out the bug has been fixed upstream already, so I proposed the
> following debdiff:
>
> http://launchpadlibrarian.net/35719155/gwave_20090213-1ubuntu1_gwave_20090213-1ubuntu2.debdiff
>
> This also removes some spuriously included files in the .diff.gz left
> over from the binary build. Probably the package clean rules could do
> with updating a little.
>
>
> Note that the Ubuntu package is already patched w.r.t the Debian one, in
> that they added a Depends: on guile-gnome2-gtk
>
> * Add dependency on guile-gnome2-gtk to fix segfault at launch (LP: #414297).
>
> -- Nick Ellery <email address hidden> Sat, 15 Aug 2009 22:03:44 -0700
>
>
> For the upload I was proposing to Ubuntu, they didn't want me to add a
> patch system (dpatch) as I used in the above debdiff. The debdiff with
> _only_ the changes (no patch), is here:
>
> http://launchpadlibrarian.net/35730112/gwave_20090213-1ubuntu1_gwave_20090213-1ubuntu2.debdiff
>
>
> Anyone fancy sponsoring an upload for me (or whatever the Debian process
> for allowing a relative noob like me push packages is?). If anyone is
> keen to fix the package without my further involvement, that would also
> be great!
---end quoted text---

  Thanks Peter for sending the patch to Debian, I am currently working
  on merging the Ubuntu changes into Debian, but I see that according to
  the bug report on Launchpad, the problem cannot be reproduced by
  Fabrice on Lucid, does that mean that the patch of Peter is not needed
  or what ?

--
 ‎أحمد المحمودي (Ahmed El-Mahmoudy)
  Digital design engineer
 GPG KeyID: 0xEDDDA1B7 (@ subkeys.pgp.net)
 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7

On Mon, 2009-11-16 at 16:56 +0200, أحمد المحمودي wrote:
> Hello,

> Thanks Peter for sending the patch to Debian, I am currently working
> on merging the Ubuntu changes into Debian, but I see that according to
> the bug report on Launchpad, the problem cannot be reproduced by
> Fabrice on Lucid, does that mean that the patch of Peter is not needed
> or what ?

It is an upstream patch, not my own.

The problem can only be reproduced on systems where the LOCALE
(LC_NUMERIC) in use forces "," as the decimal point specifier.

I'm not 100% sure it is the "," vs. "." issue which is the problem, as
the original reporter didn't report the LC_NUMERIC of his system yet.

In any case, the reporter stated that the patch fixed the issue for
them, and was included upstream to fix the same problem reported
elsewhere.

Reading through this bug report, it doesn't look like there's adequate consensus yet for a SRU debdiff. I'm going to unsubscribe MOTU-SRU for the time being; please resubscribe us once a fix is ready.

Thanks!

My system is localized with french canadian language. You could test gwave after changing your localization (but this would necessitate some package fetching and installing). How does the LC_NUMERIC switch works? I believe the "keyword" for french localization is fr_CA.

So this would be like LC_NUMERIC=fr_CA, but I don't know if this would work. In french, we do use ',' instead of '.' as the decimal point specifier. So you seem right about the problem cause.

I have included a new screenshot displaying the behavior of the unpatched gwave on my system, when I try to plot the initial data.out file posted above.

Just to note, Debian have just uploaded an updated package in "unstable".

http://packages.debian.org/changelogs/pool/main/g/gwave/gwave_20090213-2/changelog

It encompases this change, the Ubuntu delta, and various other cleanups and improvements. I guess this could / should be synced to Lucid at some point, and we will have to consider how to proceed with a SRU request for Karmic.

Presumably the really simple debdiff which patches the source directly - would be preferred, rather than taking the whole new Debian package?

I'm not completely sure, but I think we need to get more confirmation from users / developers that the proposed change fixes issues they are having - and doesn't cause regressions anywhere else in the package, or for other users.

I can confirm that the patched version works, but since I'm on an en_GB locale, I was never affected by the original bug.

Is there anyone else who can test, and confirm a fix (or confirm no adverse affects) to the patch?

TEST CASE:

Try the following to reproduce the bug:

Download data.out attached to this bug report, as test-data.

You need to install the correct locale support. If you haven't got fr_CA, do this:

echo fr_CA.UTF-8 UTF-8 | sudo tee /var/lib/locales/supported.d/fr_CA_test
sudo locale-gen

Run gwave with:

LC_NUMERIC=fr_CA.UTF-8 gwave data.out

From the list of waveforms window, drag the V(Out) @ tbl1=0 item onto the drawing area of the main window.
This alreay shows the bug.. there is just one data-stream in that file, V(Out)

With the bug, it will not display correctly (correct display screenshot attached in this bug). Incorrect display shows two lines.

Without the bug, the only data-stream in the file is V(Out). Dragging it to the main window causes a plot with many cycles of waveform.

Remove the test locale (if you added one) with:

sudo rm /var/lib/locales/supported.d/fr_CA_test
sudo locale-gen --purge

(NB: --purge will remove all existing system locales, then re-add the ones which configuration files remain for. This was fine on my machine, but could potentially cause issues if your locale config files are in a mess!)

Impact of bug:

Source changes are within gwave only, so no regression potentiall outside of this application.

Bug effects all users with LC_NUMERIC specifying "," rather than "." as a decimal point specifier.

Tested on locales where the bug didn't manifest, the proposed (upstream) fix has no effect on reading the test data.

If the SRU team could advise the best way to proceed, that would be appreciated. I believe an upload needs to be made to Lucid - either the very minimal proposed fix to the Ubuntu version of the pacakge - such that we can SRU it into Karmic.

OR.. a sync could be made from Debian unstable, to get the Debian version of the fix.

Since I've now figured out, and detailed a way for non fr_CA users to reproduce the bug, I expect the concensus issue John Dong mentioned shoud be resolevd. I realise there is not yet a fix in Lucid to back-port from, but I'm going to subscribe MOTU-SRU again for further advice.

Thanks

Hi Peter,

And thanks for that instructions: I've been able to reproduce the bug report, so as soon as I'm able to build the package in Lucid, I'll upload it (guile-1.8-dev is broken for the moment).

Thanks again,
Fabrice

Uploaded to Lucid. Thanks for your contribution! :-)

This bug was fixed in the package gwave - 20090213-1ubuntu2

---------------
gwave (20090213-1ubuntu2) lucid; urgency=low

  [ Peter Clifton ]
  * src/gwave.c: Applied upstream patch to fix LC_NUMERIC issue importing ASCII
    files. (lp: #482748)

  [ Fabrice Coutadeur ]
  * debian/control: changed build dependency on libreadline5-dev to
    libreadline-dev. This fix a FTBFS.
 -- Peter Clifton <email address hidden> Sun, 15 Nov 2009 14:02:21 +0000

Hi,

Doesn't work in an up to date Lucid install. Version of gwave is 20090213-2.

Is it definately picking up the Lucid installed version?

("which gwave")

Try LC_NUMERIC="C" gwave

Does that fix it?

How about LC_ALL="C" or LANG="C" gwave

Are you using a GTK-> Qt theme engine? I'm aware that the initialisation of the Qt engine in that instance can reset the LC_NUMERIC erranously.

As per comment #31, I looked again at the patch uploaded to lucid, and it looks appropriate for a SRU.

To proceed, please format a debdiff against karmic-proposed and include the testing instructions from posts #30 and #31 in the bug description itself.

Once this debdiff is ready, I'd be happy to review it.

Sorry, I've told you a nonsense. I belived Gwave didn't work because its ergonomy is somewhat confusing: having to drag and drop a button on the plotting area isn't very logic for me, I was trying to click on the button. So after having understood that, the soft works for me.

Bye!