[Cameron Gary] Bug#237076: zinf: Zinf fails to start

Just got his bug report. Note that serity "grave" bugs are
release-critical, thus risking the inclusion in sarge...

From: Cameron Gary <camerongary <at> cox.net>
Subject: Bug#237076: zinf: Zinf fails to start
Date: 2004-03-09 15:36:24 GMT

Package: zinf
Version: 2.2.5-2
Severity: grave
Justification: renders package unusable

failed to open /home/cameron/.zinf/db/metadatabase
zinf: src/database.cpp:57: Database::Database(const char*, int):
Assertion `m_dbase' failed.
Aborted

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.24-1-k7

Re: [Cameron Gary] Bug#237076: zinf: Zinf fails to start

Remove ~/.zinf and restart.  I've seen this only when the metadatabase
(old style) gets corrupted.

On Tue, 2004-03-09 at 09:03, Andreas Rottmann wrote:
> Just got his bug report. Note that serity "grave" bugs are
> release-critical, thus risking the inclusion in sarge...
> 
> 
> ______________________________________________________________________
> From: Cameron Gary <camerongary <at> cox.net>
> To: Debian Bug Tracking System <submit <at> bugs.debian.org>
> Subject: Bug#237076: zinf: Zinf fails to start
> Date: Tue, 09 Mar 2004 07:36:24 -0800
> 
> Package: zinf
> Version: 2.2.5-2
> Severity: grave
> Justification: renders package unusable
> 
> failed to open /home/cameron/.zinf/db/metadatabase
> zinf: src/database.cpp:57: Database::Database(const char*, int):
> Assertion `m_dbase' failed.
> Aborted
> 
> 
> -- System Information:
> Debian Release: testing/unstable
>   APT prefers testing
>   APT policy: (900, 'testing')
> Architecture: i386 (i686)

Re: [Cameron Gary] Bug#237076: zinf: Zinf fails to start

Hi,

> failed to open /home/cameron/.zinf/db/metadatabase
> zinf: src/database.cpp:57: Database::Database(const char*, int):
> Assertion `m_dbase' failed.
> Aborted

I've seen this. If zinf dies (from a segmentation fault for example) it 
leaves its meta data database in an unusable state.

David Vrabel

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: [Cameron Gary] Bug#237076: zinf: Zinf fails to start

David Vrabel <dvrabel <at> cantab.net> writes:

> Hi,
>
>> failed to open /home/cameron/.zinf/db/metadatabase
>> zinf: src/database.cpp:57: Database::Database(const char*, int):
>> Assertion `m_dbase' failed.
>> Aborted
>
> I've seen this. If zinf dies (from a segmentation fault for example)
> it leaves its meta data database in an unusable state.
>
One might argue zinf should either try to repair the DB or move it
away and create a new one (along with a message, explaining the issue
to the user).

Andy
--

-- 
Andreas Rottmann         | Rotty <at> ICQ      | 118634484 <at> ICQ | a.rottmann <at> gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Bug#237076: zinf: Zinf fails to start

Kristian Kvilekval writes:

> Remove ~/.zinf and restart.  I've seen this only when the metadatabase
> (old style) gets corrupted.

Being a survivor of several Zinf upgrades, I can tell you that with pretty 
much every version of Zinf you need to blow away ~/.zinf, otherwise the new 
version will be seriously fubared.

Unless the upgrade path is stabilized, it's a good idea to have Zinf 
autorename ~/.zinf to ~/.zinf.save.$RANDOM if it does not recognize its 
current version.

Re: Re: Bug#237076: zinf: Zinf fails to start

Sam Varshavchik <mrsam <at> courier-mta.com> writes:

> Kristian Kvilekval writes:
>
>> Remove ~/.zinf and restart.  I've seen this only when the metadatabase
>> (old style) gets corrupted.
>
> Being a survivor of several Zinf upgrades, I can tell you that with
> pretty much every version of Zinf you need to blow away ~/.zinf,
> otherwise the new version will be seriously fubared.
>
> Unless the upgrade path is stabilized, it's a good idea to have Zinf
> autorename ~/.zinf to ~/.zinf.save.$RANDOM if it does not recognize
> its current version.
>
Seconded.

Andy
--

-- 
Andreas Rottmann         | Rotty <at> ICQ      | 118634484 <at> ICQ | a.rottmann <at> gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

It's *GNU*/Linux dammit!

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

character sets and filenames

I've seen some problems when scanning filenames
with foreign characters and I was hoping somebody
would have some suggestions.

Say, for example, I have 

  /home/music/luiz_macedo-bossa_electromagn<E9>tica.m3u

Currently this is failing to be encoded as a URL
by the routine  FilePathToURL which in turn
is implemented with g_filename_to_uri

>From reading the URI/URL documentation, I would
expect this to be encoded as 

  /home/music/luiz_macedo-bossa_electromagn%E9tica.m3u

My initial reaction is that it's a bug in glib, but
on the other hand  the documentation says for g_filename_to_uri:

filename : an absolute filename specified in the encoding used for
filenames by the operating system.

And the filename passed in is probably not considered legal (but
actually works fine).

Would someone like to clarify?

--

-- 
email:kris <at> cs.ucsb.edu office:(805)893-4276 http://www.cs.ucsb.edu/~kris

Re: character sets and filenames

Kristian G. Kvilekval writes:

> I've seen some problems when scanning filenames
> with foreign characters and I was hoping somebody
> would have some suggestions.
> 
> Say, for example, I have 
> 
>   /home/music/luiz_macedo-bossa_electromagn<E9>tica.m3u
> 
> Currently this is failing to be encoded as a URL
> by the routine  FilePathToURL which in turn
> is implemented with g_filename_to_uri
> 
>>From reading the URI/URL documentation, I would
> expect this to be encoded as 
> 
>   /home/music/luiz_macedo-bossa_electromagn%E9tica.m3u
> 
> My initial reaction is that it's a bug in glib, but
> on the other hand  the documentation says for g_filename_to_uri:
> 
> filename : an absolute filename specified in the encoding used for
> filenames by the operating system.
> 
> And the filename passed in is probably not considered legal (but
> actually works fine).
> 
> Would someone like to clarify?

Re: Re: character sets and filenames

On Tue, 2004-03-09 at 17:49, Sam Varshavchik wrote:

> The user used an encoding other than the "encoding used by the operating 
> system."
> 
> By fiat, Unix filenames have been decreed to be using UTF-8; still plenty of 
> stuff creates files using iso-8859-1, et al…
> 
> There is no easy solution for this one.

How about a tool to guess the encoding and re-write the filenames
as UTF8.  Would this sufficient?

--

-- 
email:kris <at> cs.ucsb.edu office:(805)893-4276 http://www.cs.ucsb.edu/~kris

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click

Re: character sets and filenames

Kristian G. Kvilekval writes:

> On Tue, 2004-03-09 at 17:49, Sam Varshavchik wrote:
> 
>> The user used an encoding other than the "encoding used by the operating 
>> system."
>> 
>> By fiat, Unix filenames have been decreed to be using UTF-8; still plenty of 
>> stuff creates files using iso-8859-1, et al…
>> 
>> There is no easy solution for this one.
> 
> How about a tool to guess the encoding and re-write the filenames
> as UTF8.  Would this sufficient?

It's the lesser of all evils.  I think the following heuristics are probably 
the best one can do:

A)  Try to see if the filename parses in UTF-8.  Stuff that's not UTF-8 is 
very unlikely to be parsable as valid UTF-8.

B)  Try nl_langinfo(CODESET).  Not all platforms have that call.  You'll 
need to probe if this is implemented, in configure.ac.

C)  ????