Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Jacobo Tarrio]

El domingo, 18 de junio de 2006 a las 22:03:32 -0500, Ron Johnson escribía:

> When I tried to install it as root (using "su -" from an xterm
> window), it complained about not being able to find DISPLAY.  Unlike
> Sun Java & Macromedia Flash, it uses a GUI installer.

 I've found "sux" works beautifully :-)

-- 
   Jacobo Tarrío | http://jacobo.tarrio.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Choice of gcc versions for kernel modules

[Bastian Blank]

On Sun, Jun 18, 2006 at 06:44:47PM -0700, Russ Allbery wrote:
> I'm not sure what to do with bug #374367 against OpenAFS, so I'm asking
> for advice.  The short version (slightly longer version in the bug log) is
> that the archive has switched from gcc 4.0 to gcc 4.1, but the AMD64
> kernel (at least -- I haven't checked other architectures) was built with
> gcc 4.0.  However, CC in the linux-headers packages is set to just "gcc"
> and therefore uses the system default.

Any reason why you don't ask the maintainer of the kernels? The problem
will be fixed with the next upload.

Bastian

-- 
Death, when unnecessary, is a tragic thing.
-- Flint, "Requiem for Methuselah", stardate 5843.7


signature.asc
Description: Digital signature

Re: Bug#374373: ITP: googleearth-package -- utility for automatically ...

[Christian Perrier]

> Concur.  Even if the installer isn't accepted into contrib, but were
> in a separate mirror like Marrilat, I'd add it.


If the installer works well (ie does the advertised job), I see no
reason for it not going in the archive.




signature.asc
Description: Digital signature

Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Wesley J. Landaker]

Paul Wise wrote:
> On Sun, 2006-06-18 at 23:56 -0400, Joey Hess wrote:
>   
>> Wesley J. Landaker wrote:
>> 
>>> But the most important one of all is: I've found it useful, I've got it
>>> working[1], and I'd like to give others an opportunity to use it if they
>>> want to.
>>>
>>> [1] (almost working--I'm still tweaking it a bit, since I've only been
>>> working on it for a few hours)
>>>   
>> Does it use the loki installer as I read somewhere? I had been
>> considering possibly adding loki support to alien as a package format
>> (without generation support), which might be a nicer general solution.
>> 
>
> It uses makeself as the wrapper format (shell script+tar.bz2):
>
> http://packages.debian.org/unstable/utils/makeself
>
> Inside that is a setup.sh, which runs setup.gtk/gtk2, running strings -a
> on those files gives some loki_* functions, looks like it is using the
> loki system. The app itself seems to reside in 2 tarballs (data and
> program).
>
>   

Well, having a unified installer that supported lots of stuff, including
Google Earth, would be nice, and could possibly depricate this package.
But for now, I've finished the first version of this utility that just
packages Google Earth and just uploaded it.

The package includes the following niceities:
  * Makes a nice, clean googleearth package with no interaction
  * Installs things in the normal, proper FHS places
  * Does the menu entry and MIME registration the Debian way
  * Dependencies are set correctly, including shlibdeps and fonts
  * Installs the upstream license into the standards Debian spot
  * Can use a pre-downloaded version, or can attempt to download
automatically

And the following rough edges:
  * It spews a lot of output to the screen while building
  * It uses more diskspace during build than is strictly necessary
  * The package it generates could use some minor improvements

Anyway, the standards "it-works-for-me" applies, but I've tested it on
both etch and sid with no problems. Patches and helpful suggestions are
welcome.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Benjamin Seidenberg wrote:
> Ron Johnson wrote:
>> Benjamin Seidenberg wrote:
 Joe Smith wrote:
> "Wesley J. Landaker" <[EMAIL PROTECTED]> wrote in message
> 
> 
[snip]
>> When I tried to install it as root (using "su -" from an xterm
>>  window), it complained about not being able to find DISPLAY. 
>> Unlike Sun Java & Macromedia Flash, it uses a GUI installer.
>> 
>> Since many (most?) desktop users install apps from within su or
>>  sudo'ed xterm windows, how will you work around that?
>> 
> If you don't use -, DISPLAY should be preserved. Ditto for sudo.

   $ su -m

Can dpkg emulate that?

> Benjamin
> 
> (Postscript: I almost replied to your sig, but decided i wasn't 
> going to go there.)

Off-list replies always welcome.

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEli8jS9HxQb37XmcRAmamAJ4pPciAOJ7WYk81IIl3eXbvNpPNZwCeJhjL
W0pIBtbLPjVTw1jHpBP3hck=
=Kkhq
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Benjamin Seidenberg]

Ron Johnson wrote:
> Benjamin Seidenberg wrote:
> >> Joe Smith wrote:
> >>> "Wesley J. Landaker" <[EMAIL PROTECTED]> wrote in message
>
>  Package: wnpp
>  Severity: wishlist
>  Owner: "Wesley J. Landaker" <[EMAIL PROTECTED]>
> 
>  * Package name: googleearth-package
>   Upstream Author : Wesley J. Landaker <[EMAIL PROTECTED]>
>  * URL : (native package)
>  * License : GPL
>   Description : utility for automatically building a Google Earth
>  Debian package
> 
>  Google Earth is a great program now available for GNU/Linux,
>   but sadly is both non-free and non-distributable. For those
>  who wish to run it on
>  their Debian system, but wish it to be managed by the normal
>   Debian packaging system, this program will assist in
>  building a local Debian package in a similar fashion to
>  java-package. This package *itself* contains absolutely no
>  code from Google and is 100% free. (For the curious, this is
>  appropriately destined for contrib.)
> [snip]
> >> What's more, google earth can be installed without root
> >> privileges and installs into a users home directory, thus the
> >> systems administrator doesn't even need to install it, the user
> >> can
>
> When I tried to install it as root (using "su -" from an xterm
> window), it complained about not being able to find DISPLAY.  Unlike
> Sun Java & Macromedia Flash, it uses a GUI installer.
>
> Since many (most?) desktop users install apps from within su or
> sudo'ed xterm windows, how will you work around that?
>
If you don't use -, DISPLAY should be preserved. Ditto for sudo.

Benjamin

(Postscript: I almost replied to your sig, but decided i wasn't going to
go there.)



signature.asc
Description: OpenPGP digital signature

Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Paul Wise]

On Sun, 2006-06-18 at 23:56 -0400, Joey Hess wrote:
> Wesley J. Landaker wrote:
> > But the most important one of all is: I've found it useful, I've got it
> > working[1], and I'd like to give others an opportunity to use it if they
> > want to.
> > 
> > [1] (almost working--I'm still tweaking it a bit, since I've only been
> > working on it for a few hours)
> 
> Does it use the loki installer as I read somewhere? I had been
> considering possibly adding loki support to alien as a package format
> (without generation support), which might be a nicer general solution.

It uses makeself as the wrapper format (shell script+tar.bz2):

http://packages.debian.org/unstable/utils/makeself

Inside that is a setup.sh, which runs setup.gtk/gtk2, running strings -a
on those files gives some loki_* functions, looks like it is using the
loki system. The app itself seems to reside in 2 tarballs (data and
program).

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Joey Hess]

Wesley J. Landaker wrote:
> But the most important one of all is: I've found it useful, I've got it
> working[1], and I'd like to give others an opportunity to use it if they
> want to.
> 
> [1] (almost working--I'm still tweaking it a bit, since I've only been
> working on it for a few hours)

Does it use the loki installer as I read somewhere? I had been
considering possibly adding loki support to alien as a package format
(without generation support), which might be a nicer general solution.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition

[Guillem Jover]

On Fri, 2006-06-16 at 23:10:36 +0200, Goswin Brederlow wrote:
> Package: debian-policy
> Severity: normal

> [Side note: Buildds/dpkg-buildpackage has no robust way of telling if
> the optional build-arch field exists and must call build. This is
> wastefull for both build dependencies and build time.]

I've a counter-proposal. ;) Make dpkg source v2.0 (Wig And Pen) format
require build-arch and build-indep.

> Why is this proposal better than others that have failed before?
> 
> - non disruptive: Current buildd behaviour will continue to build all
>   existing packages.

Ditto.

> - Packages will not instantly have RC bugs.

Ditto.

> - Simple to implement.
>   + Trivial change in dpkg for the new field.
>   + dpkg-checkbuilddeps has to parse 3 fields (2 with -B option)
> instead of 2 (1).
>   + sbuild, same change
>   + Simple change for 'apt-get build-dep'

Those changes will not be needed.

> - Buildds/dpkg-buildpackage can use the build-arch target
>   + reduces Build-Depends field and install time of same
>   + build-indep is no longer called, reduces compile time and disk
> space

Only will need changes in dpkg-buildpackage.

> - Build-Depends/Conflicts-Indep becomes usefull, build-indep becomes
>   usefull

Ditto.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#374373: ITP: googleearth-package -- utility for automatically ...

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Miles Bader wrote:
> "Joe Smith" <[EMAIL PROTECTED]> writes:
>> Is this really needed? Google was very careful in making sure
>> that the package installs in /usr/local, and does not interfere
>> with the system. Normally the main reason why a debian package
>> is better than what upsteam distributed is because using
>> upstreams packages will mess with stuff it should not touch.
> 
> I like installing from a debian package even when the upstream 
> distributions a reasonable binary installation of their own.  No
> matter how good the upstream, the debian package is almost always
> even easier, more consistent, and less to worry about.

Concur.  Even if the installer isn't accepted into contrib, but were
in a separate mirror like Marrilat, I'd add it.

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFElhfnS9HxQb37XmcRAhbdAJ9JgV5PAyY/bGCez/7t3QXkEe+ZTACfQRfw
x5hF1BpbpYCfOKGehclLtKg=
=g6JZ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Netatalk and SSL

[Thomas Bushnell BSG]

Daniel Dickinson <[EMAIL PROTECTED]> writes:

> Ok, I'm confused.  In the netatalk README.Debian it says that the
> Debian project has decided that OpenSSL is GPL-incompatible and
> therefore he can't distribute the ssl-based portions of netatalk (like
> encrypted authentication with classic macs).  I was pretty sure that
> debian had worked something out for linking OpenSSL with debian
> package.  Was it only for specific packages?  Is this developer just
> not aware of the accommodation?  Am I totally out to lunch on what's
> going on with this?

It isn't just Debian: it's the GPL Compliance Lab too.

Anyhow, the point is that certain GPLd programs have special
exceptions that allow them to be linked with openssl.  However, note
that *all* the GPL'd code in the final program must have the
exception.  

For example, gwenhywfar is a library which contains the exception and
which uses openssl, but that doesn't solve the gnucash problem, where
we want to link gnucash against this library.  We can't do that,
because gnucash and gnome don't have the exception.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Miles Bader]

"Joe Smith" <[EMAIL PROTECTED]> writes:
> Is this really needed? Google was very careful in making sure that the
> package installs in /usr/local, and does not interfere with the
> system. Normally the main reason why a debian package is better than
> what upsteam distributed is because using upstreams packages will mess
> with stuff it should not touch.

I like installing from a debian package even when the upstream
distributions a reasonable binary installation of their own.  No matter
how good the upstream, the debian package is almost always even easier,
more consistent, and less to worry about.

-Miles
-- 
自らを空にして、心を開く時、道は開かれる


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Benjamin Seidenberg wrote:
> Joe Smith wrote:
>> "Wesley J. Landaker" <[EMAIL PROTECTED]> wrote in message

>>> Package: wnpp
>>> Severity: wishlist
>>> Owner: "Wesley J. Landaker" <[EMAIL PROTECTED]>
>>>
>>> * Package name: googleearth-package
>>>  Upstream Author : Wesley J. Landaker <[EMAIL PROTECTED]>
>>> * URL : (native package)
>>> * License : GPL
>>>  Description : utility for automatically building a Google Earth
>>> Debian package
>>>
>>> Google Earth is a great program now available for GNU/Linux,
>>>  but sadly is both non-free and non-distributable. For those
>>> who wish to run it on
>>> their Debian system, but wish it to be managed by the normal
>>>  Debian packaging system, this program will assist in
>>> building a local Debian package in a similar fashion to
>>> java-package. This package *itself* contains absolutely no
>>> code from Google and is 100% free. (For the curious, this is
>>> appropriately destined for contrib.)
[snip]
>> 
> What's more, google earth can be installed without root
> privileges and installs into a users home directory, thus the
> systems administrator doesn't even need to install it, the user
> can

When I tried to install it as root (using "su -" from an xterm
window), it complained about not being able to find DISPLAY.  Unlike
Sun Java & Macromedia Flash, it uses a GUI installer.

Since many (most?) desktop users install apps from within su or
sudo'ed xterm windows, how will you work around that?

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFElhQES9HxQb37XmcRArnhAJ97z8ewrNgL1NCwlTUPRNsoBlLhMgCguEMY
/X96cCnAl3spFulff41Kllc=
=d49o
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Wesley J. Landaker]

Joe Smith wrote:
> Is this really needed? Google was very careful in making sure that the
> package installs in /usr/local, and does not interfere with the
> system. Normally the main reason why a debian package is better than
> what upsteam distributed is because using upstreams packages will mess
> with stuff it should not touch.
Well, it doesn't install in /usr/local (by default, you can get it
there) but in a user's home directory. Actually, perhaps if you run it
as root it will pick /usr/local by default, but I didn't try that (I
don't usually run things as root, even stuff from Google).
> Google Earth takes care of its own updates by prompting the user, and
> allowing them to download and run the new installer (or at least it
> does on windows, and I can't imagine why the linux version would not).
> Needing to use a *-package utility prevents automatic updates anyway,
> and does not simplify installation much if any. So the only real
> advantage would seem to be that it would make Google Earth easier to
> uninstall. Well I guess it simplifies pushing updates out to a bunch
> of workstations, but in most cases users should just download the the
> .bin and run it.
Apparently, the "easier to uninstall" is a bigger deal to me than it is
to you. So this utility may not be for you.

There has only been one version out for GNU/Linux as far as I'm aware,
so I'm not sure anyone knows exactly how the updater works. Seeing how
their software is packaged, I actually don't see any way that the
Debianized version would break updates if run as root (which would have
to be the case anyway unless every user has their own version) but
personally I don't like programs that try to update themselves outside
of package management.

Anyway, there are a few advantages:
  * Once you've made the package, you can install on multiple machines
easily.
  * It's much cleaner, as you have a managed Debian package to
install/uninstall.
  * In-program updates are optional (run as root and do them, or don't).
  * If you don't like doing it this way, nobody is going to make you do
it. =)

But the most important one of all is: I've found it useful, I've got it
working[1], and I'd like to give others an opportunity to use it if they
want to.

[1] (almost working--I'm still tweaking it a bit, since I've only been
working on it for a few hours)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Benjamin Seidenberg]

Joe Smith wrote:
>
> "Wesley J. Landaker" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>> Package: wnpp
>> Severity: wishlist
>> Owner: "Wesley J. Landaker" <[EMAIL PROTECTED]>
>>
>> * Package name: googleearth-package
>>  Upstream Author : Wesley J. Landaker <[EMAIL PROTECTED]>
>> * URL : (native package)
>> * License : GPL
>>  Description : utility for automatically building a Google Earth
>> Debian package
>>
>> Google Earth is a great program now available for GNU/Linux, but sadly
>> is both non-free and non-distributable. For those who wish to run it on
>> their Debian system, but wish it to be managed by the normal Debian
>> packaging system, this program will assist in building a local Debian
>> package in a similar fashion to java-package. This package *itself*
>> contains absolutely no code from Google and is 100% free. (For the
>> curious, this is appropriately destined for contrib.)
>>
>>
>
> Is this really needed? Google was very careful in making sure that the
> package installs in /usr/local, and does not interfere with the
> system. Normally the main reason why a debian package is better than
> what upsteam distributed is because using upstreams packages will mess
> with stuff it should not touch.
>
> The reason java-package is needed is that upstream's packages are not
> well behaved, and install into /usr, potentially causeing problems if
> it decides to edit the files of other packages.
>
>
> Google Earth takes care of its own updates by prompting the user, and
> allowing them to download and run the new installer (or at least it
> does on windows, and I can't imagine why the linux version would not).
> Needing to use a *-package utility prevents automatic updates anyway,
> and does not simplify installation much if any. So the only real
> advantage would seem to be that it would make Google Earth easier to
> uninstall. Well I guess it simplifies pushing updates out to a bunch
> of workstations, but in most cases users should just download the the
> .bin and run it.
>
>
What's more, google earth can be installed without root privileges and
installs into a users home directory, thus the systems administrator
doesn't even need to install it, the user can



signature.asc
Description: OpenPGP digital signature

Choice of gcc versions for kernel modules

[Russ Allbery]

Hello all,

I'm not sure what to do with bug #374367 against OpenAFS, so I'm asking
for advice.  The short version (slightly longer version in the bug log) is
that the archive has switched from gcc 4.0 to gcc 4.1, but the AMD64
kernel (at least -- I haven't checked other architectures) was built with
gcc 4.0.  However, CC in the linux-headers packages is set to just "gcc"
and therefore uses the system default.

Of course, if one builds a kernel module with gcc 4.1 and tries to load it
into a kernel built with gcc 4.0, it doesn't load and OpenAFS
initialization fails.  However, OpenAFS uses the kbuild machinery to build
the module and therefore doesn't set the compiler itself.

Modifying CC in /usr/src/linux-headers-2.6.16-2-amd64-k8/Makefile to be
gcc-4.0 instead of gcc fixes the problem.  Shouldn't this be done in the
kernel headers by default, given that the gcc packages provide a versioned
binary and given that using a different major version of gcc is pretty
much always going to fail?

Should I reassign this bug to one of the kernel packages (and probably
downgrade it)?  Is this problem going to just go away once 2.6.17 hits
unstable and I should wait?  Is there something I should be doing in the
build machinery for OpenAFS (which is unfortunately complex) that I'm not
doing?

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Joe Smith]

"Wesley J. Landaker" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Package: wnpp
Severity: wishlist
Owner: "Wesley J. Landaker" <[EMAIL PROTECTED]>

* Package name: googleearth-package
 Upstream Author : Wesley J. Landaker <[EMAIL PROTECTED]>
* URL : (native package)
* License : GPL
 Description : utility for automatically building a Google Earth 
Debian package


Google Earth is a great program now available for GNU/Linux, but sadly
is both non-free and non-distributable. For those who wish to run it on
their Debian system, but wish it to be managed by the normal Debian
packaging system, this program will assist in building a local Debian
package in a similar fashion to java-package. This package *itself*
contains absolutely no code from Google and is 100% free. (For the
curious, this is appropriately destined for contrib.)




Is this really needed? Google was very careful in making sure that the 
package installs in /usr/local, and does not interfere with the system. 
Normally the main reason why a debian package is better than what upsteam 
distributed is because using upstreams packages will mess with stuff it 
should not touch.


The reason java-package is needed is that upstream's packages are not well 
behaved, and install into /usr, potentially causeing problems if it decides 
to edit the files of other packages.



Google Earth takes care of its own updates by prompting the user, and 
allowing them to download and run the new installer (or at least it does on 
windows, and I can't imagine why the linux version would not). Needing to 
use a *-package utility prevents automatic updates anyway, and does not 
simplify installation much if any. So the only real advantage would seem to 
be that it would make Google Earth easier to uninstall. Well I guess it 
simplifies pushing updates out to a bunch of workstations, but in most cases 
users should just download the the .bin and run it. 




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ping for missing maintainers

[Hex Star]

PING missing_maintainers (127.0.0.1): 56 data bytes64 bytes from missing_maintainers: icmp_seq=0 ttl=64 time=0.136 ms64 bytes from missing_maintainers: icmp_seq=1 ttl=64 time=0.114 ms
64 bytes from missing_maintainers: icmp_seq=2 ttl=64 time=0.116 ms64 bytes from missing_maintainers: icmp_seq=3 ttl=64 time=0.114 ms64 bytes from missing_maintainers: icmp_seq=4 ttl=64 time=0.114 ms64 bytes from missing_maintainers: icmp_seq=5 ttl=64 time=
0.113 ms64 bytes from missing_maintainers: icmp_seq=6 ttl=64 time=0.116 ms64 bytes from missing_maintainers: icmp_seq=7 ttl=64 time=0.115 ms64 bytes from missing_maintainers: icmp_seq=8 ttl=64 time=0.115 ms
64 bytes from missing_maintainers: icmp_seq=9 ttl=64 time=0.113 ms--- missing_maintainers ping statistics ---10 packets transmitted, 10 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.113
/0.117/0.136/0.007 msOn 6/18/06, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:Howdy. Just wondering if anyone knows the whereabouts of two maintainers:
Otavio Salvador (apt-proxy)Peter Veenstra (dosbox)I have not noticed many updates to these programs recently, and both seem tohave some ignored bugs in the bts such as#336433#312969#301925
#362928I have sent both maintainers emails to which I received no reply. Justattempting to ping the list to see if they are active or mia.Thanks all,Christian--To UNSUBSCRIBE, email to 
[EMAIL PROTECTED]with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ping for missing maintainers

[Felipe Augusto van de Wiel (faw)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[ otavio CCed ]

On 06/18/2006 09:39 PM, [EMAIL PROTECTED] wrote:
> Howdy. Just wondering if anyone knows the whereabouts of two maintainers:
> 
> Otavio Salvador (apt-proxy)
> Peter Veenstra (dosbox)
> 
> I have not noticed many updates to these programs recently, and both seem to 
> have some ignored bugs in the bts such as
> #336433
> #312969
> #301925
> #362928
> 
> I have sent both maintainers emails to which I received no reply. Just 
> attempting to ping the list to see if they are active or mia. 
> 
> Thanks all,
> Christian

Otavio is active (not MIA). I know that he has plans for apt-proxy
(while I'm not quite sure about what are the plans). He probably will reply
in the next days, I will try to talk with him on IRC or another IM.

Kind regards,

- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFElfwrCjAO0JDlykYRAr0cAKCmlnZN8f1gGXY9szVK29cELRXdLACfa85E
mfUFTGk/WxcSlBrblra6w24=
=Ev6L
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ping for missing maintainers

[christian . mchugh]

Howdy. Just wondering if anyone knows the whereabouts of two maintainers:

Otavio Salvador (apt-proxy)
Peter Veenstra (dosbox)

I have not noticed many updates to these programs recently, and both seem to 
have some ignored bugs in the bts such as
#336433
#312969
#301925
#362928

I have sent both maintainers emails to which I received no reply. Just 
attempting to ping the list to see if they are active or mia. 

Thanks all,
Christian


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Wesley J. Landaker]

Package: wnpp
Severity: wishlist
Owner: "Wesley J. Landaker" <[EMAIL PROTECTED]>

* Package name: googleearth-package
  Upstream Author : Wesley J. Landaker <[EMAIL PROTECTED]>
* URL : (native package)
* License : GPL
  Description : utility for automatically building a Google Earth Debian 
package

Google Earth is a great program now available for GNU/Linux, but sadly
is both non-free and non-distributable. For those who wish to run it on
their Debian system, but wish it to be managed by the normal Debian
packaging system, this program will assist in building a local Debian
package in a similar fashion to java-package. This package *itself*
contains absolutely no code from Google and is 100% free. (For the
curious, this is appropriately destined for contrib.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Correct dependencies on libgnutls-dev? (#370387)

[Goswin von Brederlow]

Loïc Minier <[EMAIL PROTECTED]> writes:

> Hi,
>
>  I received #370387 claiming that I should version my libgnutls-dev dep
>  because libgnutls11-dev provides libgnutls-dev and this can cause
>  multiple versions of libgnutls to be linked to a binary (e.g. the
>  version pulled by libsoup, and the version pulled by -lgnutls when the
>  binary is built).

Provided package can never be versioned since dpkg does not support
that. Also, if 2 or more packages provide a virtual package then you
may not Build-Depend on that virtual package but must use "real |
virt". But I don't think this is the case for libgnutls-dev.

I think you are correct to depend on the virtual libgnutls-dev. If
libsoup needs a specific version of libgnutls to be used when linking
then libsoup-dev should depend on the stricter libgnutls11-dev package
to force linking against the correct one. I don't think it is the
packages job to guess what sub libraries their libraries need.

If you Build-Depend on libgnutls11-dev and libsoup updates to
libgnutls12 your package will become instantly FTBFS while with
libgnutls-dev it will just need a binNMU to transition.

>  I consider all of this is normal even if it indeed allows binaries to
>  end up linked with multiple versions of gnutls.

Happens all the time, at least with different versions with the same
abi/soname of a library. Mixing libfoo1 and libfoo2 is usualy bad.

>  If we were to force all binaries to link to one and only one gnutls,
>  then we wouldn't allow two or three gnutls versions in the archive at
>  the same time.

If the symbols in libgnutls are properly versioned you could even mix
libraries linked against different versions of libgnutls. But not
every library is that clean, most require a combined transition of all
libs in a binary at once.

>  Is this correct?  Am I missing something?

Don't think so.

>Thanks for comments,

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GCC 4.1 now the default GCC version for etch

[Wouter Verhelst]

On Sun, Jun 18, 2006 at 02:24:35PM -0700, Blars Blarson wrote:
> (amd64 is only faster in 64-bit mode because of all the poorly
> designed x86 32-bit instruction set.)

"x86 32-bit instruction set" and "designed" in one sentence? Hah.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GCC 4.1 now the default GCC version for etch

[Blars Blarson]

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:

>there appears to currently be a sparc release of debian,
>http://www.debian.org/ports/sparc/

(not currently a release candidate for etch)

>and it appears to claim to support some kind of limited 64bit support.

>There are some unstated things from the page that I would like to bring to
>the table as relevant:
>
>1. since it is sparc, I would presume debian/sparc is "big endian"

Yes.

>2. since the amd64 arch now has 64bit applications (?) I would guess that
>   at some point, the debian sparc folks may follow suit.

It does support 64-bit applications.  However, in almost all cases
compiling for 64-bit just makes the application slower.  Don't expect
all 64-bit mode support for sparc.


(amd64 is only faster in 64-bit mode because of all the poorly
designed x86 32-bit instruction set.)
-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Correct dependencies on libgnutls-dev? (#370387)

[Loïc Minier]

Hi,

 I received #370387 claiming that I should version my libgnutls-dev dep
 because libgnutls11-dev provides libgnutls-dev and this can cause
 multiple versions of libgnutls to be linked to a binary (e.g. the
 version pulled by libsoup, and the version pulled by -lgnutls when the
 binary is built).

 I consider all of this is normal even if it indeed allows binaries to
 end up linked with multiple versions of gnutls.

 If we were to force all binaries to link to one and only one gnutls,
 then we wouldn't allow two or three gnutls versions in the archive at
 the same time.

 Is this correct?  Am I missing something?

   Thanks for comments,
-- 
Loïc Minier <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GCC 4.1 now the default GCC version for etch

[Goswin von Brederlow]

Henning Makholm <[EMAIL PROTECTED]> writes:

> Scripsit Falk Hueffner <[EMAIL PROTECTED]>
>> Henning Makholm wrote:
>
>>> Another related bug type that I found lurking in my packages when I
>>> investigated the warnings in this list, is trying to format a size_t
>>> value with a %u or %d format string, which will break if size_t is 64
>>> bits (unless the actual number is small and it is the last argument
>>> and the endianness of the architecture happens to match its stack
>>> growth direction).
>
>> Since any sane ABI pads arguments to word size, this is only a problem
>> on big endian 64-bit architectures (that is, no current release
>> architecture).
>
> Hm, that makes sense. Perhaps I should back out my (clumsy) fixes for
> it, then.

No, the bug remains and should be fixed.

It just doesn't cause crashes or even show any signs at all as long as
there is no overflow. For examle %d for size_t will work only up to
2GiB and then display the wrong values. If all you use are number 0-100
then you will not hit the bug on any debian archtecture.

The next port could be a 64bit big endian system though. It really is
better to fix it now instead of worrying about it again in the future.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Netatalk and SSL

[Martijn van Oosterhout]

On 6/18/06, Lars Wirzenius <[EMAIL PROTECTED]> wrote:

The OpenSSL license is incompatible with the GPL. A GPL application
needs an addition to its license that allows linking with OpenSSL. Some
application authors do that and then Debian (or anyone) can distribute
the apps (in a binary form); some don't, or haven't yet, and those apps
Debian doesn't distribute.


The other alternative is to port it to another SSL library, like
Mozilla NSS or GnuTLS. Most of the time the SSL code is not terribly
complicated and the port is fairly straight-forward.

Have a nice day,
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: some Debian Apache Maintainer here ?

[Olaf van der Spek]

On 6/18/06, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:

* Josselin Mouette

| Le dimanche 18 juin 2006 à 15:30 +0200, Tollef Fog Heen a écrit :
| > | Tollef, you realise that neither me nor Marc (who has started this thread)
| > | have ever talked about NMUs?
| >
| > Josselin Mouette did.  I've earlier this week had to stop an NMU of
| > apr-util and would prefer that people don't NMU apache or related
| > packages.
|
| At the moment I proposed it, the Apache team was described as quite
| unresponsive and it looked like a logical answer. Now that you're back
| in the loop, of course this isn't needed anymore.

Uh, we were?  I've been fixing an apr build failure and general


Yes. Still are.

Re: some Debian Apache Maintainer here ?

[Tollef Fog Heen]

* Josselin Mouette 

| Le dimanche 18 juin 2006 à 15:30 +0200, Tollef Fog Heen a écrit :
| > | Tollef, you realise that neither me nor Marc (who has started this 
thread) 
| > | have ever talked about NMUs?
| > 
| > Josselin Mouette did.  I've earlier this week had to stop an NMU of
| > apr-util and would prefer that people don't NMU apache or related
| > packages.
| 
| At the moment I proposed it, the Apache team was described as quite
| unresponsive and it looked like a logical answer. Now that you're back
| in the loop, of course this isn't needed anymore.

Uh, we were?  I've been fixing an apr build failure and general
cleanups for the last week or so.  Adam was going to upload a new
apache before the weekend, but didn't get around to it due to loads of
other stuff on his plate.

| I still fail to see why you feel "threatened" by a NMU proposal, though.

I said it was a threat of NMUing the package.  I haven't said anything
about how I feel about it apart from not being happy about it due to
seeing botched attempts in the past.

| See the words? Proposal, not threat. Do you think I'd be careless enough
| to upload such an important package without asking for more input
| before?

I'd certainly hope not.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: some Debian Apache Maintainer here ?

[Josselin Mouette]

Le dimanche 18 juin 2006 à 15:30 +0200, Tollef Fog Heen a écrit :
> | Tollef, you realise that neither me nor Marc (who has started this thread) 
> | have ever talked about NMUs?
> 
> Josselin Mouette did.  I've earlier this week had to stop an NMU of
> apr-util and would prefer that people don't NMU apache or related
> packages.

At the moment I proposed it, the Apache team was described as quite
unresponsive and it looked like a logical answer. Now that you're back
in the loop, of course this isn't needed anymore.

I still fail to see why you feel "threatened" by a NMU proposal, though.
See the words? Proposal, not threat. Do you think I'd be careless enough
to upload such an important package without asking for more input
before?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: some Debian Apache Maintainer here ?

[Tollef Fog Heen]

* Adrian von Bidder 

| On Sunday 18 June 2006 07:51, Tollef Fog Heen wrote:
| [...]
| > > Without knowing or having asked Adam, this seems like help might be
| > > welcome.
| >
| > Useful patches and comments are always welcome.  Threats of NMUs and
| > similar aren't.
| 
| Tollef, you realise that neither me nor Marc (who has started this thread) 
| have ever talked about NMUs?

Josselin Mouette did.  I've earlier this week had to stop an NMU of
apr-util and would prefer that people don't NMU apache or related
packages.

| Marc merely offered his help - and it seems that there seemed to be
| a lack of communication from the Apache team's side in the past.

Yes, we are aware of that and trying to fix it.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: some Debian Apache Maintainer here ?

[Tollef Fog Heen]

* Josselin Mouette 

| Le dimanche 18 juin 2006 à 07:51 +0200, Tollef Fog Heen a écrit :
| > > Without knowing or having asked Adam, this seems like help might be 
welcome.
| > 
| > Useful patches and comments are always welcome.  Threats of NMUs and 
| > similar aren't.
| 
| Why do you see NMUs as threats? This only means people are willing to
| help you.

Please read my sentence again.  «Threats of NMUs» != «NMUs are a
threat».

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: GCC 4.1 now the default GCC version for etch

[Henning Makholm]

Scripsit Falk Hueffner <[EMAIL PROTECTED]>
> Henning Makholm wrote:

>> Another related bug type that I found lurking in my packages when I
>> investigated the warnings in this list, is trying to format a size_t
>> value with a %u or %d format string, which will break if size_t is 64
>> bits (unless the actual number is small and it is the last argument
>> and the endianness of the architecture happens to match its stack
>> growth direction).

> Since any sane ABI pads arguments to word size, this is only a problem
> on big endian 64-bit architectures (that is, no current release
> architecture).

Hm, that makes sense. Perhaps I should back out my (clumsy) fixes for
it, then.

-- 
Henning Makholm"*Jeg* tænker *strax* på kirkemødet i
 Konstantinopel i 381 e.Chr. om det arianske kætteri..."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: some Debian Apache Maintainer here ?

[Adrian von Bidder]

On Sunday 18 June 2006 07:51, Tollef Fog Heen wrote:
[...]
> > Without knowing or having asked Adam, this seems like help might be
> > welcome.
>
> Useful patches and comments are always welcome.  Threats of NMUs and
> similar aren't.

Tollef, you realise that neither me nor Marc (who has started this thread) 
have ever talked about NMUs?  Marc merely offered his help - and it seems 
that there seemed to be a lack of communication from the Apache team's side 
in the past.

cheers
-- vbi


pgpAG3gllKtlY.pgp
Description: PGP signature

Re: some Debian Apache Maintainer here ?

[Thijs Kinkhorst]

On Sun, 2006-06-18 at 07:51 +0200, Tollef Fog Heen wrote:
> Useful patches and comments are always welcome.  Threats of NMUs and 
> similar aren't.

NMU's are not personal attacks but they are people helping you to
improve the quality of packages in Debian. I hope you don't feel
threatened by people helping.


Thijs


signature.asc
Description: This is a digitally signed message part

Bug#374287: ITP: tuxguitar -- TuxGuitar is a multitrack guitar tablature editor and player. It can open GP3, GP4, and GP5 files.

[Philippe Coval]

Package: wnpp
Severity: wishlist
Owner: Philippe Coval <[EMAIL PROTECTED]>


* Package name: tuxguitar
  Version : 0.6
  Upstream Author : Julian Casadesus 
* URL : http://www.herac.com.ar/soluciones/tuxguitar.htm
* License : LGPL
  Programming Lang: Java
  Description : TuxGuitar is a multitrack guitar tablature editor and 
player. It can open GP3, GP4, and GP5 files.

With TuxGuitar, you will be able to compose music using the following features:
Tablature editor
Multitrack display
Autoscroll while playing
Note duration management
Various effects (bend, slide, vibrato, hammer-on/pull-off)
Support for triplets (5,6,7,9,10,11,12)
Repeat open and close
Time signature management
Tempo management
Imports and exports gp3 and gp4 files 

The GUI is using Java SWT and provides MIDI synth output.

I made a quick and dirty package for those who want to try it out,
untill I submit it somewhere.

Check http://rzr.online.fr/q/SWT for download, news , help etc

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.19-k7-amiloa
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#374132: ITP: tntdb -- C++ class library for easy database access

[Stephen Gran]

This one time, at band camp, Kari Pahula said:
> On Sat, Jun 17, 2006 at 03:46:11PM +0300, Kari Pahula wrote:
> > * License : GPLv2 or later
> 
> >  Currently has support for MySQL, PostgreSQL and SQLite.
> 
> And PostgreSQL links to openssl, which is GPL incompatible.  Sigh...
> I'll investigate what could be done about this.

If it's a transitive link, is that really an issue?  With newish linker
features, you don't get a NEEDED line for libssl unless you actually
use it's symbols in your app.  I'm not sure, but how far down the tree
of recursive linking is this an issue for?
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: some Debian Apache Maintainer here ?

[Olaf van der Spek]

On 6/18/06, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:

> Without knowing or having asked Adam, this seems like help might be welcome.

Useful patches and comments are always welcome.


But sending them to /dev/null appears to have the same effect.


Threats of NMUs and
similar aren't.


How about NMUs without the threat?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Jubiläum Angebot.

[Jubiläum Angebot.]

***Fuenf Sterne Strand Hotel an Tuerkischen Riveria HP eine Woche KOSTENLOS .***
Als S Group 2006 feiern wir das 10jährige Jubiläum unserer Gründung.
Aus diesem Anlass bieten wir in den 5 Sterne Strandhotels in Belek Antalya 
Aufenthalt-Halbpension kostenlos.
Im Einzelnen: Reisetermine sind zwischen dem 10.11.2006 bis zum 30.04.2007, 
jeden Freitag und Samstag.
Flug und Transfer zum Hotel übernehmen Sie selbst.
Auf Wunsch können wir dies für Sie organisieren.
Schon ab € 89.- p. P.  für die einfache Flugstrecke, können Sie auch  Ihre 
Flüge bei uns bequem buchen.
-Ab;Duesseldorf-Frankfurt-Muenchen-Hamburg-Hannover-Berlin(TXL-SXF) - 
Friedrichshafen-
 Wien-Salzburg-Graz-Linz-Zuerich und Basel.
KOSTENLOSE INKLUSİVELEİSTUNG:
· 6 Übernachtungen im 5-Sterne-Hotel im Doppelzimmer.
· 1 Übernachtung in einem Thermalhotel in Pamukkale.
· Begrüßungscocktail
· Orientierungsfahrt 
· 1-Tägiger Ausflug nach Antalya mit Bootsfahrt.
·Sprechstunden (Täglich) im Hotel
·Klimatisierte Buße fuer 2 Ausfluege.
·Stadtlichgeprüfte Reiseführer

*Info Reise fuer die Gruppenleitern möglich.

Ihr S Group Team.

Re: some Debian Apache Maintainer here ?

[Josselin Mouette]

Le dimanche 18 juin 2006 à 07:51 +0200, Tollef Fog Heen a écrit :
> > Without knowing or having asked Adam, this seems like help might be welcome.
> 
> Useful patches and comments are always welcome.  Threats of NMUs and 
> similar aren't.

Why do you see NMUs as threats? This only means people are willing to
help you.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Bug#374257: ITP: svnclientadapter -- high-level Java API for Subversion

[Ivan Dubrov]

Package: wnpp
Severity: wishlist
Owner: Ivan Dubrov <[EMAIL PROTECTED]>

* Package name: svnclientadapter
  Version : 1.0.3
  Upstream Author : Chabanois Cedric <[EMAIL PROTECTED]>,
  Daniel Bradby <[EMAIL PROTECTED]>, Mark Phippard <[EMAIL PROTECTED]>
* URL : http://subclipse.tigris.org/
* License : Apache License 2.0
  Programming Lang: Java
  Description : high-level Java API for Subversion

 Subversion is a version control system much like the Concurrent Versions
 System (CVS). Version control systems allow many individuals (who may be
 distributed geographically) to collaborate on a set of files (typically
 source code).  Subversion has all the major features of CVS, plus certain
 new features that CVS users often wish they had.
 .
 SVNClientAdapter is easier Java API for Subversion and is used by Subclipse.
 It can use one of 2 low-level Subversion client implementations to provide
 access to the Subversion repository:
  * JavaHL (JNI), Subversion library
  * JavaSVN, pure Java Subversion client
  * Command line Subversion client
 .
 Homepage: http://subclipse.tigris.org/

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#374256: ITP: javasvn -- a pure Java Subversion client library

[Ivan Dubrov]

Package: wnpp
Severity: wishlist
Owner: Ivan Dubrov <[EMAIL PROTECTED]>

* Package name: javasvn
  Version : 1.0.6
  Upstream Author : Unknown
* URL : http://tmate.org/svn/
* License : Custom
  Programming Lang: Java
  Description : a pure Java Subversion client library

 This library can be used to access or modify Subversion repository from the
 pure Java application, be it a standalone program plugin or web application.
 JavaSVN does not require any configuration or native binaries.
 .
 Homepage: http://tmate.org/svn/

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: some Debian Apache Maintainer here ?

[Christian Perrier]

> >Without knowing or having asked Adam, this seems like help might be 
> >welcome.
> 
> Useful patches and comments are always welcome.  Threats of NMUs and 
> similar aren't.


But what about the apparent unresponsiveness of the mailing list,
which seems to have been raised in this thread?

From the packages control files, the mailing list is the maintainer of
the package. So, people could expect some reaction when sending mails
to the mailing list. If, actually, Adam Conrad is the only working
contact for Apache, then he should be listed in the control file of
packages.

Nothing personal against any of the Apache maintainers, but I would
like to raise here an apparent concern which seems to be shared by
several other people.





signature.asc
Description: Digital signature

Bug#374255: ITP: ganymed-ssh2 -- SSH2 protocol implementation in pure Java

[Ivan Dubrov]

Package: wnpp
Severity: wishlist
Owner: Ivan Dubrov <[EMAIL PROTECTED]>

* Package name: ganymed-ssh2
  Version : 0.209
  Upstream Author : Christian Plattner <[EMAIL PROTECTED]>
* URL : http://www.ganymed.ethz.ch/ssh2/
* License : Custom
  Programming Lang: Java
  Description : SSH2 protocol implementation in pure Java

 Ganymed SSH2 for Java is a library which implements the SSH2 protocol in pure
 Java. It allows one to connect to SSH servers from within Java programs. It
 supports SSH sessions (remote command execution and shell access), local port
 forwarding, local stream forwarding, and SCP. There are no dependencies on any
 JCE provider, as all crypto functionality is included.
 .
 Ganymed SSH2 for Java  was originally developed for the Ganymed replication
 project and a couple of other projects at the IKS group at ETH Zurich.
 .
 Homepage: http://www.ganymed.ethz.ch/ssh2/

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re:Ms?

[Allen Wesley]

You've qualified for one of our mortgage rates given below!
Bad cred? these rates are guaranteed.

Our last few customers today:

-Marvin. FLos Angeles, CA279,000 @ 4.11%
-Will. WTampa, FL519,000 @ 3.74%
-Janice. JAtlanta, GA789,000 @ 3.24%
-Sammy. APatterson,  NJ919,000 @ 3.24%

http://mx.geocities.com/cowan041cantrell


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GCC 4.1 now the default GCC version for etch

[Bastian Blank]

On Sun, Jun 18, 2006 at 07:40:13AM +0200, Tollef Fog Heen wrote:
> Philip Brown skrev:
> >So to deliberately ignore an issue, becuase 
> >"we dont support big-endian 64bit *right now*", would seem to be rather
> >short sighted to me.
> ia64 has been supported for quite a while and is a pure 64 bit architecture.

But not big-endian.

Bastian

-- 
Dismissed.  That's a Star Fleet expression for, "Get out."
-- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud"


signature.asc
Description: Digital signature