usbsink-list — USBSink mailing list

[Usbsink-list] Development halted

[Marko A. <mar...@gm...>]

Hi,

This is to annouce that the development of USBSink is now halted.

It has reached the modest goals which I set when I was starting the project;
then there are many small reasons leading to a general lack of time.
But really the bottom line is that I have lost interest in it, and thus have
not been doing any significant work for a while.

I can accept to commit patches which could come along in order to keep
the program in a buildable state. OTOH, if there is anybody interested
in picking up the project, please let me know. In any case, it is free software.

In the future (free time) I will continue to work on other projects. At the
moment, PaperBox is the most interesting one from a free desktop user's
point of view. Some other day it might be something else.

I would like to thank everyone for downloading, trying and talking about
USBSink so far. I know that it has helped some people out there and it
has been an important experience for me.

    Marko

[Usbsink-list] Prepping for gcc 3.4 introduction in Fedora 9

[Jeff S. <jsp...@gm...>]

Due to some re-organization of how certain gcc provided header files
reference other header files, usbsink needs to explicitly list
additional header files to include. A test build against the pending
gcc 3.4 in fedora development revealed that a number of packages need
to make include statement adjustments, usbsink among them.  I'm going
to work through this and give you a set of patches to make usbsink
buildable against the new gcc 3.4.

-jef

Re: [Usbsink-list] USBSink 0.3.3 released

[Marko A. <ma...@ma...>]

On Wed, 2007-09-05 at 08:38 -0800, Jeff Spaleta wrote:
> On 9/5/07, Marko Anastasov <ma...@ma...> wrote:
> > Also, (for the next release) I plan to add a D-Bus interface and
> > activation, which could be used by a Nautilus plugin, for instance.
> 
> yeah... d-bus would be keen.  I can imagine all sorts of scenarios.
> Basically something like.. you call up the main application window to
> set things up. But the notification icon only comes up when you stick
> a usb stick into the computer and the through dbus magic the usbsink
> daemon is started and you get the notification icon..which you can
> interact with if you want to see a log of actions as they go or
> whatever.
> 
> I've been thinking about user oriented tools in general as it relates
> to backing up personal data. Have you thought at all about other
> targets other than usb? Network targets? Like rsync.net? or amazon's
> S3 service? Or perhaps a local network location via rsync or
> rsync-backup?  If you are going to go D-Bus, can you identify
> different networks and take actions based on what network you are on?
> Usage case: roaming user with a laptop, the return to work or home and
> want to backup personal data over that network using rsync.


I have thought that I'd work on syncing over the network.
Generally I will replace GnomeVFS transfers, with... something else.
I still need to evaluate all the options - libcurl, librsync, see
what GVFS will bring. GnomeVFS will be deprecated in favour of GVFS,
maybe by the end of the next GNOME dev cycle. Also Conduit already
does many kinds of these scenarios of specific types of user data
to an online service or device. My goal has been synchronization
between computers.

I'm not sure how much is it possible ATM to utilize a D-Bus interface
over the network, although I know that there has been some work towards
that for OLPC. AFAIK Avahi services would be the way to do that..

This is a page where the Ubuntu people have discussed a possible
solution for the kind of the usecase that you've mentioned:
https://wiki.ubuntu.com/MultipleComputersSynchronization

But what I think would be really useful in a program is to have
a layer of abstraction over things such as creating and copying
to a network share, when you just need to sync/backup some files.
So a network-enabled usbsink could work as this:

Computers run instances of the program, which advertises an Avahi
service (primarily) readable and discoverable by other instances
on the network. A service defines labeled locations which act as
potential sinks. So with my laptop, wishing to sync some files
in my home directory, I could browse destinations such as 'local usb
drive', 'fun_stuff on desktop X', 'external hard drive on desktop Y',
while these locations would have been previously defined in the program,
behind-the-scenes being actually "proper" network shares where
transfers are being done with (S)FTP.

Marko

Re: [Usbsink-list] USBSink 0.3.3 released

[Marko A. <ma...@ma...>]

On Tue, 2007-09-04 at 13:33 -0800, Jeff Spaleta wrote:
> On 9/4/07, Marko Anastasov <ma...@ma...> wrote:
> > Hello,
> >
> > I am almost-happy to announce USBSink 0.3.3, a bugfix release
> > which resolves a compilation error reported by Jeff Spaleta.
> 
> :->
> 
> The notification icon is a good start. I really need the minimize to
> tray feature to maximize my use of usbsink.  Suggestion though, you
> might want to make that icon visible all the time, instead of
> disappearing when the main window is active. That behavior is more
> inline with other tray notifiers I interact with such as
> seahorse-agent, xchat,ekiga,rhythmbox etc..etc.

Yeah, I'm feeling that that's better behaviour now too.
Previously I was too much under influence of some writings how there
should be as few application icons in the tray as possible. But it
clearly is necessary for usbsink.

> Do you plan to add the ability for usbsink to attach itself to the
> gnome-session automatically or through a preference dialog? Instead of
> having to manually add it to the startup?

I actually should've tried harder find out what lies behind this.
It is actually just a matter of having a desktop entry in
~/.config/autostart. So yes, there will be a preference dialog in
the next release with a "start usbsink with desktop session" checkbox.

Also, (for the next release) I plan to add a D-Bus interface and
activation, which could be used by a Nautilus plugin, for instance.

Marko

[Usbsink-list] USBSink 0.3.3 released

[Marko A. <ma...@ma...>]

Hello,

I am almost-happy to announce USBSink 0.3.3, a bugfix release
which resolves a compilation error reported by Jeff Spaleta.

You can download it from

        http://sourceforge.net/project/showfiles.php?group_id=141363

Enjoy,

Marko
http://marko.anastasov.name/blog

Re: [Usbsink-list] USBSink 0.3.2 released

[Marko A. <ma...@ma...>]

On Tue, 2007-09-04 at 09:00 -0800, Jeff Spaleta wrote:
> On 9/4/07, Marko Anastasov <ma...@ma...> wrote:
> > Glib guint64 which is "guaranteed to be 64 bits on all platforms".
> > Which platform are you running?
> 
> I was building locally on 32bit intel.  I've patched the line out to
> get it to build in fedora development branch.
> http://koji.fedoraproject.org/koji/buildinfo?buildID=17721
> 
> I could use the fedora build system to fire off scratch builds against
> 64bit pc and ppc to see if the problem happens there as well if you
> want to look over build logs.

Ah, no need to do that, sorry. I wrongly declared the constant,
I should've put a UL suffix, such as:

static const guint64 TB = 0x10000000000UL;

But like I said, it can stay commented and I'll keep it that way
as long as I am not using it anywhere in code.

Marko

Re: [Usbsink-list] USBSink 0.3.2 released

[Marko A. <ma...@ma...>]

On Tue, 2007-09-04 at 09:00 -0800, Jeff Spaleta wrote:
> On 9/4/07, Marko Anastasov <ma...@ma...> wrote:
> > Glib guint64 which is "guaranteed to be 64 bits on all platforms".
> > Which platform are you running?
> 
> I was building locally on 32bit intel.  I've patched the line out to
> get it to build in fedora development branch.
> http://koji.fedoraproject.org/koji/buildinfo?buildID=17721
> 
> I could use the fedora build system to fire off scratch builds against
> 64bit pc and ppc to see if the problem happens there as well if you
> want to look over build logs.

Yes, please, I am interested in the results - although more for ppc
as I'm running Fedora 7 x86_64 and had no error/warning regarding this.

Marko

Re: [Usbsink-list] USBSink 0.3.2 released

[Jeff S. <jsp...@gm...>]

On 9/4/07, Marko Anastasov <ma...@ma...> wrote:
> Glib guint64 which is "guaranteed to be 64 bits on all platforms".
> Which platform are you running?

I was building locally on 32bit intel.  I've patched the line out to
get it to build in fedora development branch.
http://koji.fedoraproject.org/koji/buildinfo?buildID=17721

I could use the fedora build system to fire off scratch builds against
64bit pc and ppc to see if the problem happens there as well if you
want to look over build logs.

-jef

Re: [Usbsink-list] USBSink 0.3.2 released

[Marko A. <ma...@ma...>]

On Tue, 2007-09-04 at 00:39 -0800, Jeff Spaleta wrote:
> On 9/1/07, Marko Anastasov <ma...@ma...> wrote:
> > Hello,
> >
> > I am happy release and announce USBSink 0.3.2.
> >
> > You can download it from
> >
> >         http://sourceforge.net/project/showfiles.php?group_id=141363
> >
> 
> 
> I'm getting an error attempting to compile the 0.3.2 src code on an
> up2date Fedora 7.
> 
> utils.cc:56: error: integer constant is too large for 'long' type

Hmm, strange, I'll have to see why this resolves to long. I'm using
Glib guint64 which is "guaranteed to be 64 bits on all platforms".
Which platform are you running?

> The TERABYTE constant is not being used anywhere in the codebase it
> seems, so commenting this line out lets the compile continue.  Do you
> need me to file this as a bug at sf.net against usbsink?

No need really to file a bug, I just committed this. That const is not
used anywhere so it can go. Thanks for reporting.

Build errors should of course not happen so I'll make another release
later today.

Marko

Re: [Usbsink-list] USBSink 0.3.2 released

[Jeff S. <jsp...@gm...>]

On 9/1/07, Marko Anastasov <ma...@ma...> wrote:
> Hello,
>
> I am happy release and announce USBSink 0.3.2.
>
> You can download it from
>
>         http://sourceforge.net/project/showfiles.php?group_id=141363
>


I'm getting an error attempting to compile the 0.3.2 src code on an
up2date Fedora 7.

utils.cc:56: error: integer constant is too large for 'long' type

The TERABYTE constant is not being used anywhere in the codebase it
seems, so commenting this line out lets the compile continue.  Do you
need me to file this as a bug at sf.net against usbsink?

-jef

[Usbsink-list] USBSink 0.3.2 released

[Marko A. <ma...@ma...>]

Hello,

I am happy release and announce USBSink 0.3.2.

You can download it from

	http://sourceforge.net/project/showfiles.php?group_id=141363


Changes since 0.3.1
===================

Core:

  * Fixed a bug of segfaulting sometimes when a drive gets unplugged
    without unmounting.

  * Support removable drives on SCSI.

  * Added option '--minimized', which runs the program in this state.
    This allows the program to start nicely with the desktop session.

  * Use GTK+ UIManager and actions for menus and toolbar, meaning
    less work for translators.

  * Keep track of some transfer statistics.

  * Added extensive application logging capabilities, using
    Dodji Seketeli's code from Nemiver.

GUI:

  * Show some transfer statistics, slightly improved drive
    browsing dialog.

  * Closing the application window now minimizes it to tray, ctrl-q to
    quit.

Translations:

  * Added Brasilian Portuguese (Og Maciel), updated Serbian
    and Swedish (Daniel Nylander).

Documentation:

  * Updated Yelp-browseable user manual.

  * Added .doxygen file to allow optional code documentation generation.

Build scripts:

  * Check for g++ 4.x in configure.

  * Fixed icon cache update at uninstall.

Development
===========

For information on how to report bugs and general development, visit

http://usbsink.sourceforge.net/development.html

and/or post to this list.

Enjoy,

Marko
http://marko.anastasov.name/blog

[Usbsink-list] Towards usbsink 0.3.2

[Marko A. <ma...@ma...>]

Hello,

I plan to release USBSink 0.3.2 soon (in a week, or maybe two if
I don't notice a week passing too fast), so I'd like to invite
everyone who's interested to checkout the code from SVN [1] and
give it a spin.

I have not had much of free time in summer, as immediately after
university I started an internship, which is still going on and I
have not managed to do much with the project. So, no major new stuff,
but there's enough for a minor release.

>From a user's point of view, the visible changes are displaying
of some basic transfer statistics, minimize to tray functionality
and support for anything removable recognized as a SCSI device.
To run usbsink minimized, run it as 'usbsink --minimized'. There's
not much more than that; if you think that a context menu or some
information from the tray icon tooltip would be useful, let me know.

There are some internal changes, the biggest one being that I've
incorporated some utility code from Dodji Seketeli's Nemiver, with
the goal to enable some sophisticated application logging. This has
even led me to start a new project, gtkmm-utils, which will one
day probably become a dependency, when there comes up another
application using it.

Another thing is that the program now uses GTK+ actions and UIManager;
I still need to check once again that I haven't broken anything for
i18n. I plan to announce on gnome-i18n list that the app is ready and
I'd love some more translations.

Marko

[1] svn co https://usbsink.svn.sourceforge.net/svnroot/usbsink/trunk .

Re: [Usbsink-list] Future plans

[Marko A. <ma...@ma...>]

У пет, 20. 04 2007. у 15:17 -0800, Jeff Spaleta пише:
> Good Afternoon,
> 
> What are the near term plans for the codebase?  Are there new features
> or ui changes in the current svn trunk that you'd like to see tested
> by other people?

Since 0.3.1 I haven't had much free time, mostly because of the
work at university. I think the situation will get better soon.

So there have been no significant updates in the trunk, except for
some refactoring and small fixes in configure/install scripts.

> Are you planning on having the usbsink systemtray icon so they utility
> can start minimized as part of desktop startup?

Yes. I think that's quite important and it should be in the next
release.

So the near term plans are:

- add a simple window to view statistics for all tasks and transfers
- migrate to GtkActions for menus and toolbars
- optional script execution after transfer is completed
- minimize to tray option

Anyway, I'm happy you asked. Small things like this add more
inspiration :). I'll post on the list as I add interesting stuff.

--
  Marko

[Usbsink-list] Future plans

[Jeff S. <jsp...@gm...>]

Good Afternoon,

What are the near term plans for the codebase?  Are there new features
or ui changes in the current svn trunk that you'd like to see tested
by other people?

Are you planning on having the usbsink systemtray icon so they utility
can start minimized as part of desktop startup?

-jef

[Usbsink-list] SVN migration

[Marko A. <ma...@ma...>]

Hi,

As of today USBSink uses Subversion for version control.
Main repository can be checked out with:

svn co https://usbsink.svn.sourceforge.net/svnroot/usbsink/trunk usbsink

And browsed online at:

http://usbsink.svn.sourceforge.net/viewvc/usbsink/

--
 Marko

Re: [Usbsink-list] I have submitted and gained approval for usbsink packages

[Jeff S. <jsp...@gm...>]

On 2/25/07, Marko Anastasov <ma...@ma...> wrote:
> I should mention that Veit Wahlich has also made a RPM earlier, it's
> in the CRU repo ( http://naturidentisch.de/packages/fc6/usbsink/ ).

Yeah i saw that in the list archives. I should have ping'd this list
when i started the submission process to help avoid duplicate effort.

A package of 0.3.1 went to the fedora extras build servers today, so
once the packaging signing process is done usbsink will be available
in fedora extras for FC-6 and fedora development. That will most
likely happen sometime tomorrow.

-jef

Re: [Usbsink-list] I have submitted and gained approval for usbsink packages

[Marko A. <ma...@ma...>]

On нед, 2007-02-25 at 11:15 -0900, Jeff Spaleta wrote:
> Good Morning,
> 
> I started the process for submitting usbsink packages into Fedora
> Extras a couple of weeks ago, based on the 0.3.0 version of usbsink.
> The submission process is complete and a version of usbsink 0.3.0 is
> now available in the Fedora Extras for development and FC6 branches.
> 
> Now that the package is through review and into the fedora cvs I will
> be working on updating to  0.3.1 starting today.
> 
> Sorry I didn't catch up with the list sooner, so we could avoid some
> duplication of effort on the packaging effort.

Hello Jeff,

Thanks for your work. I'm very happy to hear this.

I should mention that Veit Wahlich has also made a RPM earlier, it's
in the CRU repo ( http://naturidentisch.de/packages/fc6/usbsink/ ).

Marko

[Usbsink-list] I have submitted and gained approval for usbsink packages

[Jeff S. <jsp...@gm...>]

Good Morning,

I started the process for submitting usbsink packages into Fedora
Extras a couple of weeks ago, based on the 0.3.0 version of usbsink.
The submission process is complete and a version of usbsink 0.3.0 is
now available in the Fedora Extras for development and FC6 branches.

Now that the package is through review and into the fedora cvs I will
be working on updating to  0.3.1 starting today.

Sorry I didn't catch up with the list sooner, so we could avoid some
duplication of effort on the packaging effort.


-jef

Re: [Usbsink-list] USBSink Source RPMs and Fedora Core 6 x86_64 RPMs [scanned]

[Marko A. <ma...@ma...>]

On суб, 2007-02-17 at 00:58 +0100, Veit Wahlich wrote:
> Hi Marko,
> 
> Am Freitag, den 16.02.2007, 21:37 +0100 schrieb Marko Anastasov:
> > It is about gtk icon cache indeed. The reason is that I didn't have
> > a hook in the Makefile to update the cache at uninstall. I've just
> > committed the fix. I'm not very much familiar with packaging, so could
> > you tell me if this affects packaging and so is it worth a release,
> > or in binary packages the gtk-icon-cache update stuff is done manually
> > for each program anyway because the makefile rules don't get run when
> > you install a binary package?
> 
> usually the cache should be updated on login so this ought be no problem
> as long as an icon's path does not alter, which should not be the case
> for clean packages.
> As no Makefile is run after binary package installation, I included a
> call of gtk-update-icon-cache -q after (un)installation to the packages
> (for upgraders) - version 0.3.1-2.cru is available at
> http://naturidentisch.de/packages/fc6/usbsink/ and its mirrors.
> 
> The changelog so far is:
> 
> * Sat Feb 17 2007 Veit Wahlich <cr...@zo...> - 0.3.1-2.cru
> - Some spec file clean-ups.
> - Run gtk-update-icon-cache after install/uninstall.
> 
> * Fri Feb 16 2007 Veit Wahlich <cr...@zo...> - 0.3.1-1.cru
> - Upgrade to version 0.3.1.
> - Use find_lang macro for locales.
> - Use _smp_mflags macro for make.
> - Added gnome-doc-utils >= 0.3.2 to build pre-requisites.
> 
> * Mon Feb 12 2007 Veit Wahlich <cr...@zo...> - 0.3.0-1.cru
> - Initial package release.

Ok, thanks.

Btw do you generally propose your packages to eg Fedora Extras
after a while or... how does it work?

Marko

Re: [Usbsink-list] USBSink Source RPMs and Fedora Core 6 x86_64 RPMs [scanned]

[Veit W. <cr...@zo...>]

Hi Marko,

Am Freitag, den 16.02.2007, 21:37 +0100 schrieb Marko Anastasov:
> It is about gtk icon cache indeed. The reason is that I didn't have
> a hook in the Makefile to update the cache at uninstall. I've just
> committed the fix. I'm not very much familiar with packaging, so could
> you tell me if this affects packaging and so is it worth a release,
> or in binary packages the gtk-icon-cache update stuff is done manually
> for each program anyway because the makefile rules don't get run when
> you install a binary package?

usually the cache should be updated on login so this ought be no problem
as long as an icon's path does not alter, which should not be the case
for clean packages.
As no Makefile is run after binary package installation, I included a
call of gtk-update-icon-cache -q after (un)installation to the packages
(for upgraders) - version 0.3.1-2.cru is available at
http://naturidentisch.de/packages/fc6/usbsink/ and its mirrors.

The changelog so far is:

* Sat Feb 17 2007 Veit Wahlich <cr...@zo...> - 0.3.1-2.cru
- Some spec file clean-ups.
- Run gtk-update-icon-cache after install/uninstall.

* Fri Feb 16 2007 Veit Wahlich <cr...@zo...> - 0.3.1-1.cru
- Upgrade to version 0.3.1.
- Use find_lang macro for locales.
- Use _smp_mflags macro for make.
- Added gnome-doc-utils >=3D 0.3.2 to build pre-requisites.

* Mon Feb 12 2007 Veit Wahlich <cr...@zo...> - 0.3.0-1.cru
- Initial package release.

Best regards,
// Veit

Re: [Usbsink-list] USBSink Source RPMs and Fedora Core 6 x86_64 RPMs [scanned]

[Marko A. <ma...@ma...>]

On пет, 2007-02-16 at 18:21 +0100, Veit Wahlich wrote:
> Am Freitag, den 16.02.2007, 15:06 +0100 schrieb Marko Anastasov:
> > No it's definitely not due to the RPM spec, but the icon (theme)
> > loading in the program. I'll see what needs to be fixed.
> 
> Hi Marko,
> 
> I could use a sed or perl substitution to hardwire the icon file to 
> %_datadir/pixmaps/usbsink.png in the .desktop file, but that would
> disable icon themes and scalable icons at all...
> 
> Besides I may suspect the icon cache to still search the graphics
> in /usr/local/ if a previous copy existed there. 
> 
> Best regards,
> // Veit

It is about gtk icon cache indeed. The reason is that I didn't have
a hook in the Makefile to update the cache at uninstall. I've just
committed the fix. I'm not very much familiar with packaging, so could
you tell me if this affects packaging and so is it worth a release,
or in binary packages the gtk-icon-cache update stuff is done manually
for each program anyway because the makefile rules don't get run when
you install a binary package?

Marko

Re: [Usbsink-list] USBSink Source RPMs and Fedora Core 6 x86_64 RPMs [scanned]

[Veit W. <cr...@zo...>]

Am Freitag, den 16.02.2007, 15:06 +0100 schrieb Marko Anastasov:
> No it's definitely not due to the RPM spec, but the icon (theme)
> loading in the program. I'll see what needs to be fixed.

Hi Marko,

I could use a sed or perl substitution to hardwire the icon file to=20
%_datadir/pixmaps/usbsink.png in the .desktop file, but that would
disable icon themes and scalable icons at all...

Besides I may suspect the icon cache to still search the graphics
in /usr/local/ if a previous copy existed there.=20

Best regards,
// Veit

Re: [Usbsink-list] USBSink Source RPMs and Fedora Core 6 x86_64 RPMs [scanned]

[Marko A. <ma...@ma...>]

On пет, 2007-02-16 at 14:51 +0100, Marko Anastasov wrote:
> On пет, 2007-02-16 at 03:44 +0100, Veit Wahlich wrote:
> > Hello!
> > 
> > I created clean package specifications (compatible to RedHat's package
> > naming scheme) and corresponding Source RPMs for USBSink 0.3.1 (and
> > 0.3.0) that are meant to build cleanly on RedHat(-based) distributions
> > such as RedHat Enterprise Linux, Fedora Core, CentOS, Aurora Linux, etc:
> > 
> > http://naturidentisch.de/packages/fc6/usbsink/
> > 
> > You may build binary RPMs suitable for your distribution and CPU target
> > by executing:
> > 
> > rpmbuild --rebuild usbsink-0.3.1-1.cru.src.rpm
> > 
> > As available for me, I already built x86_64 binary packages for 
> > Fedora Core 6, downloadable at the URI above.
> > 
> > Best regards,
> > // Veit Wahlich
> 
> Hi Veit,
> 
> Thank you for your work! This is great news.
> 
> I also run FC6 x86_64, so I tried the said package (0.3.1).
> When I try to add the application launcher on the panel, I see
> an error message "Could not load icon...
> /usr/local/share/icons/hicolor/scalable/apps/usbsink.svg...".
> Also this means that it is missing in the about dialog. The icon
> is in usr/share/* as expected. Is this perhaps something which
> should be fixed in the build scripts or in the RPM spec?
> Maybe it's none of them, but my Gtk code-related, I'll see.
> 
> Marko

No it's definitely not due to the RPM spec, but the icon (theme)
loading in the program. I'll see what needs to be fixed.

Marko

Re: [Usbsink-list] USBSink Source RPMs and Fedora Core 6 x86_64 RPMs [scanned]

[Marko A. <ma...@ma...>]

On пет, 2007-02-16 at 03:44 +0100, Veit Wahlich wrote:
> Hello!
> 
> I created clean package specifications (compatible to RedHat's package
> naming scheme) and corresponding Source RPMs for USBSink 0.3.1 (and
> 0.3.0) that are meant to build cleanly on RedHat(-based) distributions
> such as RedHat Enterprise Linux, Fedora Core, CentOS, Aurora Linux, etc:
> 
> http://naturidentisch.de/packages/fc6/usbsink/
> 
> You may build binary RPMs suitable for your distribution and CPU target
> by executing:
> 
> rpmbuild --rebuild usbsink-0.3.1-1.cru.src.rpm
> 
> As available for me, I already built x86_64 binary packages for 
> Fedora Core 6, downloadable at the URI above.
> 
> Best regards,
> // Veit Wahlich

Hi Veit,

Thank you for your work! This is great news.

I also run FC6 x86_64, so I tried the said package (0.3.1).
When I try to add the application launcher on the panel, I see
an error message "Could not load icon...
/usr/local/share/icons/hicolor/scalable/apps/usbsink.svg...".
Also this means that it is missing in the about dialog. The icon
is in usr/share/* as expected. Is this perhaps something which
should be fixed in the build scripts or in the RPM spec?
Maybe it's none of them, but my Gtk code-related, I'll see.

Marko

[Usbsink-list] USBSink Source RPMs and Fedora Core 6 x86_64 RPMs [scanned]

[Veit W. <cr...@zo...>]

Hello!

I created clean package specifications (compatible to RedHat's package
naming scheme) and corresponding Source RPMs for USBSink 0.3.1 (and
0.3.0) that are meant to build cleanly on RedHat(-based) distributions
such as RedHat Enterprise Linux, Fedora Core, CentOS, Aurora Linux, etc:

http://naturidentisch.de/packages/fc6/usbsink/

You may build binary RPMs suitable for your distribution and CPU target
by executing:

rpmbuild --rebuild usbsink-0.3.1-1.cru.src.rpm

As available for me, I already built x86_64 binary packages for=20
Fedora Core 6, downloadable at the URI above.

Best regards,
// Veit Wahlich