gtkpod-devel — gtkpod development issues

[Gtkpod-devel] gtkpod 2.1.0 beta uploaded

[phantomjinx <p.g...@ph...>]

Hi,

Fixed some of the minor errors before putting it out there.

Anything major then let us know. Otherwise, will post the release mid week.

I was going to post the release this weekend but due to another couple
of bug fixes, it seemed prudent to post a beta first.

Cheers

phantomjinx


-- 
"I know exactly who reads the papers ...

The Daily Mirror is read by people who think they run the country.

The Guardian is read by people who think they ought to run the country.

The Times is read by people who do actually run the country.

The Daily Mail is read by the wives of the people who run the country.

The Financial Times is read by the people who own the country.

The Morning Star is read by the people who think the country ought to be
run by another country.

The Daily Telegraph is read by the people who think it is."

Jim Hacker, Yes Minister

[Gtkpod-devel] libgpod 0.8.2

[Christophe F. <cfe...@gm...>]

Hi,

At long last, I've released libgpod 0.8.2. It's mainly a bug fixes
release and can be downloaded from sourceforge at
http://sourceforge.net/projects/gtkpod/files/libgpod/libgpod-0.8/libgpod-0.8.2.tar.bz2/download
As always, if you find bugs with this release, please let the
gtkpod-devel mailing list now. You can find us on freenode in #gtkpod
if you have any questions. And donations are always welcome in order
to buy newer iPod models for more testing/debugging.

iPhone 4/iPod Touch 4/iPad/Nano 6g are still unsupported in this release.
However, libgpod now has a mechanism to dynamically load
a module named $libdir/libgpod/libhashab.so. This will be useful to
easily enable support for these devices if someone comes up with a
way to compute the music database checksum.
The udev helper is now built by default, and the HAL callout is no longer
built by default, use --enable-udev/--with-hal if you need ot change that.

The main changes in the release are :

* fix mono binding on 32 bit systems (Christian Krause)
* better iOS 4.3 support (Martin Szulecki, Nikias Bassen)
* dynamic loader for libhashab.so (Nikias Bassen)
* make smartplaylists case-insensitive to match what iTunes does
* (Christophe Fergeau)
* more robust Shuffle support in udev helper (Christophe Fergeau)
* various compilation fixes and build system improvements (Alexander
  Weinert, Bastien Nocera, Christophe Fergeau)
* bug fixes (phantomjinx, James Burton, Christophe Fergeau)
* updated French translation (Éric Lassauge)

git short-log can be found below :
Adeodato Simó (2):
      fix parsing of timezone on some Classic
      python: add Itdb_Device::timezone_shift to the binding

Alexander Weinert (1):
      fix compilation with --pedantic

Bastien Nocera (2):
      Fix warnings with GCC 4.6
      Require gmodule-2.0 for the blob loading code

Christian Krause (2):
      [mono] fix alignment issues on x86
      fix parsing of SysInfoExtended for nano 6g

Christophe Fergeau (49):
      use autoupdate to modernize configure.ac
      adjust versioning to current autotools pratices
      remove recent playcount file after db writing
      attempt to bring sanity in shuffle generations
      add 4th generation Shuffles
      generate bzip2 tarballs
      Merge branch 'autotools'
      Add ebook support
      fix warning in test compilation
      Merge branch 'next'
      add 8GB Orange Nano 6g serial number
      add 16GB Blue Nano 6g serial number
      add 8GB Blue Nano 6g serial number
      Add 16GB Black Nano 6g serial number
      remove duplicate AC_CONFIG_SRCDIR
      factor common code in hash functions
      fix libgpod version number
      fix nano5g support
      failing to parse recent playcounts isn't fatal
      add more error reporting to sqlite generation
      add more nano6g serial numbers
      use appropriate compile flags for libimobiledevice
      report libimobiledevice dependency in .pc file
      use unsigned int for file size in iTunesDB
      [mono] raise mono versioning since ABI was broken
      python: fix python binding build
      python: allow passing mountpoint to test program
      fix inverted test in playcount check
      make smart playlist string comparisons case-insensitive
      usb: return NULL when nothing could be read from USB
      don't crash on NULL in itdb_sysinfo_properties_free
      udev: handle invalid XML files read from devices
      udev: add g_debug to help diagosing bugs
      udev: set log domain for udev helpers
      udev: rework udev rule to handle Shuffle 4g
      fix (again) creation of non-existing Device dirs
      sqlite: don't leak 'composer' statement
      python: make mountpoint arg optional in examples
      remove internal GChecksum copy
      optionally provide g_int64_{hash,equal}
      add optional g_checksum_reset implementation
      refresh po files
      disable HAL support by default
      enable udev by default
      add --with-udev-dir
      add more flags to make distcheck
      update NEWS for 0.8.2 release
      NEWS: add note about udev/hal changes
      0.8.2 release

James Burton (1):
      fix itdb_free crash

Martin Szulecki (2):
      [sqlitedb] Remove the i_tunes_u column to fix a post process error
      [sqlitedb] Implement iPhoneSortKey and iPhoneSortSection sqlite function

Nikias Bassen (4):
      read genius_cuid (mhsd type 9) and also write it back
      write empty mhsd of type 10
      add hashAB support via external module
      Do not write mhips for mhsd type 5 playlists

phantomjinx (1):
      Fixed memory leaks

Éric Lassauge (1):
      updated French translation

Cheers,

Christophe

Re: [Gtkpod-devel] Libgpod :Best approach to update track's metadata on Ipod

[Christophe F. <cfe...@gm...>]

Hi,

2011/7/17 Liron Tal <lir...@gm...>:
> I've read the reference manuel and in the track object there are no update()
> method. the only method I've seen that updates the DB is itdb_write().
> I guess that's the optimal option but does it update the whole itdb on my
> Ipod or is it in some way checking the diff and updating only the changes?
> also, is there a refrence to a code example of using these methods or are
> they as straight forward as they seem?

You've got to rewrite the whole database, but the Itdb_Track you
haven't changed by yourself shouldn't be modified.

>
> Using the track object, I guess I can have it's location and than update the
> Mp3's ID3 tag.
> Is it a legit way to update metadata ? The problem is that "rating" is only
> stored in the itdb and not in a id3tag so this hack isn't really optional.

You have to modify the rating in the Itdb_Track structure if you want
the iPod to notice it. However, you could also change the mp3 tags if
you find an appropriate tag (POPM maybe?) so that the rating isn't
lost when you copy the file from your iPod to another computer.

Christophe

[Gtkpod-devel] Libgpod :Best approach to update track's metadata on Ipod

[Liron T. <lir...@gm...>]

Hi,
I'm writing a python script \ Rhythmbox plugin using libgpod to have two-way
sync of metadata between my ipod and Rhythmbox.
I'm mainly intrested in syncing the rating, play count and last played data.

I thought of two possible ways to update a track:


   1. I've read the reference manuel and in the track object there are no
   update() method. the only method I've seen that updates the DB is
   itdb_write().
   I guess that's the optimal option but does it update the whole itdb on my
   Ipod or is it in some way checking the diff and updating only the changes?
   also, is there a refrence to a code example of using these methods or are
   they as straight forward as they seem?

   2. Using the track object, I guess I can have it's location and than
   update the Mp3's ID3 tag.
   Is it a legit way to update metadata ? The problem is that "rating" is
   only stored in the itdb and not in a id3tag so this hack isn't really
   optional.
   Are there any update methods to update only specific tracks?

I'd be happy to understand what's the best approach to this issue.


Thanks,
Liron.

Re: [Gtkpod-devel] [PATCH] [python] Include device->timezone_shift in sw_ipod_device_to_dict()

[Christophe F. <cfe...@gm...>]

Hey,

2011/7/8 Adeodato Simó <da...@ne...>:
> In the first case, this could be solved if the Pythonic API would
> provide datetime objects with timezone information (but, beware, this
> can get very hairy very easy very fast).

Yep, that would be my preference if that's doable sanely (say without
adding more than ~30 lines of code)

> And there's no other solution
> for the second case other than exposing this field (typically, Unix
> timestamp + UTC offset is the most robust way to represent time
> internally in any application).

I must say that timezone issues always confuse me ;) And I'm not that
experienced with that, I didn't even know that application typically
use time_t + an additional UTC offset to represent time robustly. :)

And yeah, now it makes more sense to me, you need this offset because
you're interested in timestamps in both UTC and ipod local time, and
the conversion from UTC to local time is specific to the iPod and may
not be the same as a conversion from UTC to local time on the host.

Thanks for the explanation!

Christophe

>
> Thoughts?
>
> Thanks for taking a look,
>
> --
> - Are you sure we're good?
> - Always.
>         -- Rory and Lorelai
>

Re: [Gtkpod-devel] [PATCH] itdb_tzinfo.c: handle more iPod classic sizes (6g)

[Christophe F. <cfe...@gm...>]

2011/7/8 Adeodato Simó <da...@ne...>:
> I think it's 6g (I noted this in the commit message, probably it could
> be noted in the comment too).
>
> To verify: the last 3 digit of the serial number are 9ZS (model MC293).
>
> As for firmware, is this the “Version” in the About page on the
> device?It says “2.0.4 PC”.

Ok, it's a classic 3rg generation, same as mine, though mine is only
at 2.0.3. I'll have a look at which size the file is on mine.

Thanks for the details,

Christophe

Re: [Gtkpod-devel] [PATCH] [python] Include device->timezone_shift in sw_ipod_device_to_dict()

[Adeodato S. <da...@ne...>]

Hi again!

On Thu, Jul 7, 2011 at 21:46, Christophe Fergeau <cfe...@gm...> wrote:
> Hi,
>
> On Tue, May 31, 2011 at 04:12:15AM +0100, Adeodato Simó wrote:
>> as a follow-up to my other path, it seems I cannot access the "timezone_shift"
>> member of Itdb_Device via Python:

> Why do you want to access it? I'd rather keep it private, the python
> binding should take care of convering timestamps to/from the right format.
> Or is there some use for it that I'm missing?

Yes, there can be different needs for it, depending whether you use the
Pythonic API or the C-like API.

The Pythonic API provides "time_played" as a datetime object in the
device's local time but with no timezone information attached to it (to
the the datetime object). You need to now the device's TZ if you want to
convert those times to UTC, e.g. to scrobble them.

The C-like API, instead, provides you with "time_played" as a Unix
timestamp. You need the device's TZ if you want to know, for example at
what time (day? night?) the user actually played the track.

In the first case, this could be solved if the Pythonic API would
provide datetime objects with timezone information (but, beware, this
can get very hairy very easy very fast). And there's no other solution
for the second case other than exposing this field (typically, Unix
timestamp + UTC offset is the most robust way to represent time
internally in any application).

Thoughts?

Thanks for taking a look,

-- 
- Are you sure we're good?
- Always.
        -- Rory and Lorelai

Re: [Gtkpod-devel] [PATCH] itdb_tzinfo.c: handle more iPod classic sizes (6g)

[Adeodato S. <da...@ne...>]

Hello!, thanks for your reply.

On Thu, Jul 7, 2011 at 21:48, Christophe Fergeau <cfe...@gm...> wrote:
> Ah, the size of the Preferences file changed for some iPod Classic? Do you
> know what generation your iPod Classic is? (if you don't, the last 3 digit
> of the serial number will do). What firmware are you using?
> I can't check which size is this file on my classic because of
> https://lkml.org/lkml/2011/5/25/248 :( I'll try rebooting on OS X later.
> These questions aside, your patch looks good, thanks.

I think it's 6g (I noted this in the commit message, probably it could
be noted in the comment too).

To verify: the last 3 digit of the serial number are 9ZS (model MC293).

As for firmware, is this the “Version” in the About page on the
device?It says “2.0.4 PC”.

Cheers,

-- 
- Are you sure we're good?
- Always.
        -- Rory and Lorelai

[Gtkpod-devel] Can't connect

[Akovia <ak...@em...>]

Hi,
I have read everything I can find but I've never once had my iphone
auto-mount. Regardless, it is recognized by gtkpod. I ended up creating a
mount point and mounting the phone with ifuse, and that seems to work fine,
but with the phone not mounted I get a message "ipod directory structure not
found" and asks if I would like to create it. If I try to create it, I get
the incomplete message "Error Initializing iPod: Can't write iPod database
because of missing"

A look at the terminal I ran gtkpod from gives message "Couldn't find get
device UUID itdbprep processing won't work!" & "WARNING **: Trying to unlock
an already unlocked device"
When I look at the directory it found after it fails, (I assume from mtab)
it does have what looks to be the directories gtkpod created.

After this I tried to mount the phone with ifuse first. I get the same
message about directory structure and tell it to proceed, but it fails this
time with a different message that I can't recreate. On a second try I get
the same incomplete message from before. I do get some different info from
the terminal though..

libitdbprep: itdb_iphone_start_sync called with uuid=xxxxxxxxxxxxxxxxxxxxxx
itdb_iphone_start_sync: posted syncWillStart
itdb_iphone_start_sync: posted syncLockRequest
Locking for sync, attempt 0...
Locking for sync, attempt 1...
Locking for sync, attempt 2...
Locking for sync, attempt 3...
Locking for sync, attempt 4...
Locking for sync, attempt 5...
Locking for sync, attempt 6...
Locking for sync, attempt 7...
Locking for sync, attempt 8...
Locking for sync, attempt 9...
Locking for sync, attempt 10...
itdb_iphone_start_sync: posted syncDidStart
libitdbprep: itdb_iphone_stop_sync called
itdb_iphone_stop_sync: posted syncDidFinish

I have all the latest packages installed via pmcenery/ppa.

iOS 4.0.1
Xubuntu 10.04 (Lucid) 2.6.32-32-generic SMP i686 GNU/Linux
Xfce 4 Desktop Environment - version 4.6.1 (Xfce 4.6)
-- 
View this message in context: http://old.nabble.com/Can%27t-connect-tp32017754p32017754.html
Sent from the GtkPod mailing list archive at Nabble.com.

Re: [Gtkpod-devel] [PATCH] itdb_tzinfo.c: handle more iPod classic sizes (6g)

[Christophe F. <cfe...@gm...>]

Hi,

On Tue, May 31, 2011 at 04:12:05AM +0100, Adeodato Simó wrote:
> ---
> Hi,
> 
> this tiny patch (adding one extra possible size for the Preferences
> file) fixes timezone recognition in my 6g iPod Classic.
> 
> I've tested it:
> 
>   - the get-timezone.c program prints correct values for Europe/Dublin
>     (local timezone in the computer) and Europe/Madrid (not local
>     timezone in the computer), UTC+1 and UTC+2 respectively (we're on
>     DST at the moment)
> 
>   - reading a LE 32-bit integer at byte 0xb70 in my Preferences file
>     yields the expected city IDs (0x4b when the timezone is Dublin in
>     the iPod; 0x62 for Madrid).
> 
> I'd be grateful if you could apply it.

Ah, the size of the Preferences file changed for some iPod Classic? Do you
know what generation your iPod Classic is? (if you don't, the last 3 digit
of the serial number will do). What firmware are you using?
I can't check which size is this file on my classic because of
https://lkml.org/lkml/2011/5/25/248 :( I'll try rebooting on OS X later.
These questions aside, your patch looks good, thanks.

Christophe

Re: [Gtkpod-devel] [PATCH] [python] Include device->timezone_shift in sw_ipod_device_to_dict()

[Christophe F. <cfe...@gm...>]

Hi,

On Tue, May 31, 2011 at 04:12:15AM +0100, Adeodato Simó wrote:
> as a follow-up to my other path, it seems I cannot access the "timezone_shift"
> member of Itdb_Device via Python:

Why do you want to access it? I'd rather keep it private, the python
binding should take care of convering timestamps to/from the right format.
Or is there some use for it that I'm missing?

Christophe

Re: [Gtkpod-devel] Bus error during itdb_parse

[Christophe F. <cfe...@gm...>]

On Wed, May 11, 2011 at 01:15:47PM -0500, wb...@fa... wrote:
> We're using libgpod 0.8.0 a very small number of users have had crashes
> with the stack traces below. I've given multiple examples of the call
> stack that leads to it, but the crash seems to be when accessing data
> from a file that libgpod has mapped into memory. The exception is always
> a bus error and the platform is always Mac OS X.

Is that Mac OS X x86 or ppc? I assume you're not supporting the latter, are
you?

Thanks,

Christophe

Re: [Gtkpod-devel] Crash in db_parse_context_get_m_header_internal

[Christophe F. <cfe...@gm...>]

Hi Whitney,

On Tue, Apr 26, 2011 at 09:02:38AM -0500, wb...@fa... wrote:
> I've seen a few crashes on the 0.8.0 release coming from
> db_parse_context_get_m_header_internal. The stack trace looks like:
> 
> strncpy
> db_parse_context_get_m_header_internal
> parse_mhfd
> ipod_parse_artwork_db
> itdb_parse
> 
> Is it possible for the MHeader header_id to be pointing to invalid memory at this point?

Might be, or it might be the content of the header that is NULL. By any
chance, would you have a backtrace with debug symbols, a core, an ArtworkDB
triggering the bug, ... ?

Christophe

Re: [Gtkpod-devel] smart playlists: case sensitivity of string comparisons

[Christophe F. <cfe...@gm...>]

Hi James,

Sorry it took me an eternity to answer to your email :(

On Sat, Oct 30, 2010 at 09:14:48PM +0100, James Burton wrote:
> This would be a trivial change (using strcasecmp/strcasestr/strncasecmp
> in itdb_splr_eval in itdb_playlist.c), but I don't know if this issue has
> come up before and the current behaviour was deemed preferable.
> 
> Thoughts?

I don't think the case sensitive match was done on purpose, it's more than
noone has brought it up so far imo :) So your patch is really helpful!
However, I reworked it so that it handles non-ASCII UTF-8 strings as well,
see
http://gitorious.org/~teuf/libgpod/teuf-sandbox/commit/b35c72da7e3a73d031cdf4200eadc3145436336b
(disclaimer, I haven't tested it yet ;)

Let me know if that's fine with you, thanks again for the patch, and I'm
really sorry for the huge delay in answering :(

Christophe

[Gtkpod-devel] [PATCH] fix itdb_free crash

[James B. <bur...@go...>]

Hi,

I hope this is the correct list for libgpod discussion.

I've seen a few libgpod crashes in itdb_free() which appear to be due to a 
double free of itdb->priv->genius_cuid.  Also I assume the check before the 
first g_free() can be removed since g_free does nothing if passed NULL.

Thanks,
James Burton


diff --git a/src/itdb_itunesdb.c b/src/itdb_itunesdb.c
index 446e43f..8e47c26 100644
--- a/src/itdb_itunesdb.c
+++ b/src/itdb_itunesdb.c
@@ -1355,8 +1355,7 @@ void itdb_free (Itdb_iTunesDB *itdb)
 	            (GFunc)(itdb_playlist_free), NULL);
 	    }
 
-	    if (itdb->priv->genius_cuid)
-	        g_free(itdb->priv->genius_cuid);
+	    g_free(itdb->priv->genius_cuid);
 	}
 
 	g_list_free (itdb->playlists);
@@ -1367,7 +1366,6 @@ void itdb_free (Itdb_iTunesDB *itdb)
 	itdb_device_free (itdb->device);
 	if (itdb->userdata && itdb->userdata_destroy)
 	    (*itdb->userdata_destroy) (itdb->userdata);
-	g_free (itdb->priv->genius_cuid);
 	g_free (itdb->priv);
 	g_free (itdb);
     }

Re: [Gtkpod-devel] New iPod models

[<tin...@gm...>]

On Mon, Jun 13, 2011 at 13:40:54 +0100, James A R Brown wrote:
> Hi Phantomjinx,
> 
> I know this is not a forum, but this line I felt needed a remark.
> 
> "Sent from my Android phone with K-9 Mail. Please excuse my brevity."
> 
> You wonder if now Apple may have overstepped, where its starting to be
> easier to swap to an Android device and get on with life than to reverse
> engineer the iPhone. ie there is a falling demand to reverse engineer.
> 
> iTunes always pushed its commercial nature in your face, even when all
> you wanted to do was drag on some music. 

The Apple devices support gapless playback with MP3. Well, sounds like
I'm a music enthusiast, but I really missed that feature when I tried
to use my Nokia phone as a music player. Is there an Android player
which can do gapless playback with MP3?

Regards,
Tino

Re: [Gtkpod-devel] gtkpod 2.1.0... timeframe?

[phantomjinx <p.g...@ph...>]

Bad news on the testing front for 2.1.0. My server hard disk is failing so have ordered a new one but it will be a week before I am back up in a position for testing.

If anyone has mageia installed and can verify the latest bug report 3323692 concerning 2.1 then I would be grateful.

The latest unstable is the first beta in all but name.

Cheers

Phantomjinx

 wrote:

>

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [Gtkpod-devel] gtkpod 2.1.0... timeframe?

[Matteo V. <mve...@gm...>]

On 24/06/2011 21:48, phantomjinx wrote:
>
> Matteo,
>
> Just looked at the dsc on mentors.debian.
>
> Due to the plugin environment, I wondered if a slightly more distributed
> packaging was appropriate. My experimenting, a couple of months back,
> produced a ppa for ubuntu maverick ->
>
> http://ppa.launchpad.net/phantomjinx/gtkpod-2.0.1-beta/ubuntu/pool/main/g/gtkpod/

Yep, I remembered that you splitted the plugins from the main package 
when I gave a look at the debian/ dir in your ubuntu source package.

> This is on similar lines to how I have done it for rpms on Fedora.
>
> What do you think?

I decided not to split the plugins for two reasons:
  * it was the original approach used by the former maintainer
    (and it could be questionable any time);
  * the package isn't so complicated and space-consuming to be
    in need of a split of few plugins, as it would force the
    final users to discover and understand which plugin they
    have to install for the feature they want. Monolithic is
    better this time, I guess. :-P

Time will say which was the best approach ;-)

Hope to see a brand new shining 2.1.0 soon in the repos :-)

> Cheers
>
> PGR

Regards,

mfv

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

[Gtkpod-devel] Fedora rpm packaging

[phantomjinx <p.g...@ph...>]

Hi Todd,

Hope you are well. I was wondering if you have the time to review the
spec files attached for building rpms for fedora. This is what I use for
the unstable builds.

Are you able to recommend/sponsor me for fedora?

Thanks and Regards

Paul (a.k.a. phantomjinx)



-- 
"I know exactly who reads the papers ...

The Daily Mirror is read by people who think they run the country.

The Guardian is read by people who think they ought to run the country.

The Times is read by people who do actually run the country.

The Daily Mail is read by the wives of the people who run the country.

The Financial Times is read by the people who own the country.

The Morning Star is read by the people who think the country ought to be
run by another country.

The Daily Telegraph is read by the people who think it is."

Jim Hacker, Yes Minister

Re: [Gtkpod-devel] gtkpod 2.1.0... timeframe?

[phantomjinx <p.g...@ph...>]

On 24/06/11 11:55, Matteo Vescovi wrote:
> On 24/06/2011 11:46, P.G. Richardson wrote:
>>
>> Hi mfv,
>>
>> Yes I did see your IRC question but have been suffering build servers
>> falling over at home. They are back up and intending to at least get an
>> alpha build of the next ubuntu up to see if there are any compilation
>> issues. Fedora 15 has no problems with 2.1.0.
> 
> Nor Debian sid/experimental has issues of that kind. Had to update the 
> libraries the source depended on but after that the compile and build 
> processes run smoothly. I've prepared a test build and uploaded to 
> mentors.debian.net. Have a look at it, if you're interested in the 
> packaging settings.
> 
>> The reason being is a guy using mageia reported compile errors to do with
>> drag n drop, using GTK 3.0.11, so I need to first determine whether it is
>> a general migration issue or something specific to that distro.
> 
> I'm using the Debian experimental libgtk-3-dev (3.0.10) and it gave me 
> no problems. But I've not completely tested it yet.
> 
>> As soon as that is solved then I see no reason to start the beta process
>> for 2.1.0.
> 
> OK, hope I could help in that phase. ;-)
> 
> Happy hacking!
> 
>> Cheers
>>
>> PGR
> 
> Regards,
> 
> mfv
> 

Matteo,

Just looked at the dsc on mentors.debian.

Due to the plugin environment, I wondered if a slightly more distributed
packaging was appropriate. My experimenting, a couple of months back,
produced a ppa for ubuntu maverick ->

http://ppa.launchpad.net/phantomjinx/gtkpod-2.0.1-beta/ubuntu/pool/main/g/gtkpod/

This is on similar lines to how I have done it for rpms on Fedora.

What do you think?

Cheers

PGR



-- 
"I know exactly who reads the papers ...

The Daily Mirror is read by people who think they run the country.

The Guardian is read by people who think they ought to run the country.

The Times is read by people who do actually run the country.

The Daily Mail is read by the wives of the people who run the country.

The Financial Times is read by the people who own the country.

The Morning Star is read by the people who think the country ought to be
run by another country.

The Daily Telegraph is read by the people who think it is."

Jim Hacker, Yes Minister

Re: [Gtkpod-devel] gtkpod 2.1.0... timeframe?

[Matteo V. <mve...@gm...>]

On 24/06/2011 11:46, P.G. Richardson wrote:
>
> Hi mfv,
>
> Yes I did see your IRC question but have been suffering build servers
> falling over at home. They are back up and intending to at least get an
> alpha build of the next ubuntu up to see if there are any compilation
> issues. Fedora 15 has no problems with 2.1.0.

Nor Debian sid/experimental has issues of that kind. Had to update the 
libraries the source depended on but after that the compile and build 
processes run smoothly. I've prepared a test build and uploaded to 
mentors.debian.net. Have a look at it, if you're interested in the 
packaging settings.

> The reason being is a guy using mageia reported compile errors to do with
> drag n drop, using GTK 3.0.11, so I need to first determine whether it is
> a general migration issue or something specific to that distro.

I'm using the Debian experimental libgtk-3-dev (3.0.10) and it gave me 
no problems. But I've not completely tested it yet.

> As soon as that is solved then I see no reason to start the beta process
> for 2.1.0.

OK, hope I could help in that phase. ;-)

Happy hacking!

> Cheers
>
> PGR

Regards,

mfv

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

[Gtkpod-devel] gtkpod 2.1.0... timeframe?

[Matteo V. <mve...@gm...>]

Hi all. I'm repeating something I already asked for in IRC channel, but 
no reply there.

I received a bug report (http://bugs.debian.org/631293) querying if 
there is any timeframe when the 2.1 branch (using GTK3) would be 
declared stable. We need to know that to define the switch process 
between the experimental distribution and the unstable one in Debian.

Let me know.

Thanks.

mfv

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

Re: [Gtkpod-devel] iPod model: iPod Nano 5G Black

[Christophe F. <cfe...@gm...>]

Hi,

2011/6/20 Dean Lewis <dea...@bt...>:
> Contents of iPod_Control/Device/SysInfo:
>
> ModelNumStr: xC062
> FirewireGuid: 000A27002049CEC7
>

Thanks for the data! However, this ipod model is already listed in
libgpod 0.8.0 as far as I can tell. Did you have any issues with it?

Thanks,

Christophe

[Gtkpod-devel] iPod model: iPod Nano 5G Black

[Dean L. <dea...@bt...>]

Contents of iPod_Control/Device/SysInfo:

ModelNumStr: xC062
FirewireGuid: 000A27002049CEC7

[Gtkpod-devel] iPod model: iPod Nano 5G Black

[Dean L. <dea...@bt...>]

Contents of iPod_Control/Device/SysInfo:

ModelNumStr: xC062
FirewireGuid: 000A27002049CEC7