Bug#430896: general: GNOME or KDE desktops should issue a warning when the user unplugs USB media without unmounting.

[Robert Collins]

On Thu, 2007-06-28 at 14:54 +1000, Andrew Donnellan wrote:
> On 6/28/07, Michael Biebl <[EMAIL PROTECTED]> wrote:
> > FWIW recent GNOME desktops in unstable using gnome-mount for doing the 
> > mounting
> > stuff, already have this kind of functionality. Whenever you unmount a 
> > removable
> > device, gnome-mount will show you a message via notification-daemon, when 
> > it is
> > safe to unplug the device. I'm not sure if XFCE in Debian already uses
> > gnome-mount, though.
> 
> I interpreted it as saying 'Give a warning if someone accidentally
> pulls it out before unmounting', not 'Tell me when I can pull it out
> after unmounting.'

It should do both if its recieved the patch from Ubuntu (and given it
shows when its unsafe, I think it has - both were done at the same time
IIRC).

-Rob
-- 
GPG key available at: .


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

'Uploaded' buildd status

[Sergei Golovan]

Hi!

Could someone explain me (or point to a manual) what 'Uploaded' means
in http://people.debian.org/~igloo/status.php?packages=erlang ?

The package was initially uploaded for amd64 architecture. It was
built for i386 and stays in 'uploaded' state for several days. I
wonder why it can't become 'installed' as for the rest of
architectures.

Best wishes!
--
Sergei Golovan


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

Bug#430896: general: GNOME or KDE desktops should issue a warning when the user unplugs USB media without unmounting.

[Andrew Donnellan]

On 6/28/07, Michael Biebl <[EMAIL PROTECTED]> wrote:

FWIW recent GNOME desktops in unstable using gnome-mount for doing the mounting
stuff, already have this kind of functionality. Whenever you unmount a removable
device, gnome-mount will show you a message via notification-daemon, when it is
safe to unplug the device. I'm not sure if XFCE in Debian already uses
gnome-mount, though.


I interpreted it as saying 'Give a warning if someone accidentally
pulls it out before unmounting', not 'Tell me when I can pull it out
after unmounting.'

--
Andrew Donnellan <><
ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure)
http://andrewdonnellan.comhttp://ajdlinux.wordpress.com
[EMAIL PROTECTED]hkp://subkeys.pgp.net 0x5D4C0C58
   http://linux.org.auhttp://debian.org
   Spammers only === [EMAIL PROTECTED] ===


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

Bug#430896: general: GNOME or KDE desktops should issue a warning when the user unplugs USB media without unmounting.

[Andrew Donnellan]

On 6/28/07, Andrew Donnellan <[EMAIL PROTECTED]> wrote:

I interpreted it as saying 'Give a warning if someone accidentally
pulls it out before unmounting', not 'Tell me when I can pull it out
after unmounting.'


The original request in the BR I mean; not the message from gnome-mount.

--
Andrew Donnellan <><
ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure)
http://andrewdonnellan.comhttp://ajdlinux.wordpress.com
[EMAIL PROTECTED]hkp://subkeys.pgp.net 0x5D4C0C58
   http://linux.org.auhttp://debian.org
   Spammers only === [EMAIL PROTECTED] ===


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

Bug#430896: general: GNOME or KDE desktops should issue a warning when the user unplugs USB media without unmounting.

[Michael Biebl]

Rafael wrote:
> Package: general
> Severity: wishlist
> 
> 
> 
> -- System Information:
> Debian Release: lenny/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: i386 (i686)
> 
> Kernel: Linux 2.6.22-6-generic (SMP w/1 CPU core)
> Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
> Debian KDE, Gnome or XFCE desktops should issue a warning when the user 
> unplugs USB media without unmounting it first, as Ubuntu 
> does.
> Thanks for your atention. 

FWIW recent GNOME desktops in unstable using gnome-mount for doing the mounting
stuff, already have this kind of functionality. Whenever you unmount a removable
device, gnome-mount will show you a message via notification-daemon, when it is
safe to unplug the device. I'm not sure if XFCE in Debian already uses
gnome-mount, though.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: key sign

[Kevin Mark]

On Wed, Jun 27, 2007 at 01:04:30PM -0300, Guilherme de S. Pastore wrote:
> Em Qua, 2007-06-27 às 19:28 +0330, Amin Shali escreveu:
> > Hi :)
> > Can anyone please sign my key? 
> 
> No.
> 
> Quoting http://www.debian.org/events/keysigning:
> 
> "You should never sign a key for somebody else you haven't met
> personally. Signing a key based on anything other than first-hand
> knowledge destroys the utility of the Web of Trust. If ones friend
> presents other developers with your ID card and your fingerprint, but
> you are not there to verify that the fingerprint belongs to you, what do
> other developers have to link the fingerprint to the ID? They have only
> the friend's word, and the other signatures on your key -- this is no
> better than if they signed your key just because other people have
> signed it!
Or more importantly, why do you want it signed? To become a new
maintainer or to become a debian maintainer (who is not part of debian)
who can have their packages uploaded to Debian? You man want to look
into mentors.debian.net or look into
http://www.debian.org/devel/join/newmaint ?
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal |mysite.verizon.net/kevin.mark/|
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
|  my keyserver: subkeys.pgp.net | my NPO: cfsg.org |
|join the new debian-community.org to help Debian!  |
|___  Unless I ask to be CCd, assume I am subscribed ___|


pgp3lZHBqOoT8.pgp
Description: PGP signature

Bug#430896: general: GNOME or KDE desktops should issue a warning when the user unplugs USB media without unmounting.

[Rafael]

Package: general
Severity: wishlist



-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-6-generic (SMP w/1 CPU core)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Debian KDE, Gnome or XFCE desktops should issue a warning when the user unplugs 
USB media without unmounting it first, as Ubuntu 
does.
Thanks for your atention. 


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

Re: Can we require build-arch/indep targets for lenny?

[Steve Langasek]

On Mon, Jun 18, 2007 at 10:30:55AM +0200, Goswin von Brederlow wrote:
> I would like to gather up some momentum for a policy change. Namely
> that the build-arch/indep targets in debian/rules become required
> instead of being optional.

> The reason for this is that dpkg-buildpackage can't reliable detect
> the existance of the build-arch/indep targets and must call 'build'
> instead. This forces every source to compile both architecture
> specific and architecture independent code on all buildds and
> increases the Build-Depends of packages a lot.

> Current status:

> I asked Lucas Nussbaum to rebuild all of debian with dpkg-buildpackage
> patched to call 'build-arch'. Here is the result:

> 7326 packages rebuilt (all packages not Architecture:all)
> 1727 built successfully
> 5463 failed to build with a "no rule to make" error.
> 136 failed for other reasons (unsat builddeps, etc)

> That means that only about 25% of debian package have a build-arch
> target. So there is still a long way to got.

> Possible upgrade paths:

> 1) Change policy now making 75% of package RC buggy instantly.

>This sounds horrible but the fix is trivial and there is still a
>long time to lenny to fix it.

No, the fix is not trivial; you will not get the buildd maintainers to
implement such a change when it makes 75% of the archive unbuildable, and
without such pressure you will never reach 100% adoption by package
maintainers.

Any serious adoption path needs to get used in the near term, to avoid the
package support for it atrophying due to disuse, while not breaking the
packages that have not yet implemented it.

> 2) Enforce the target for all new uploads and change policy once we
>exceed XX%.

>The unstable/experimental buildds could be patched to call
>'build-arch' instead of build making any upload without
>'build-arch' FTBFS. The security buildds would be left
>as is so nothing old breaks.

Again, very impractical, particularly for transitions where binNMUs are
involved.

> 3) Require 'build-arch/indep' with Standards-Version x.y.z

>Every source has a Standards-Version entry. dpkg-buildpackage could
>call 'build-arch' if the standards version is new enough and fall
>back to 'build' for older versions.

That's an option, but doesn't even let us take advantage of build-arch
support for existing packages that reference an older Standards-Version.

Whatever happened to the idea of using make options to check for the
existence of a target in debian/rules?  IIRC we have a total of one package
in the archive that stubbornly refuses to comply with Policy 4.9
(debian/rules must be a makefile), so if we're entertaining solutions that
make existing packages buggy, why would we not use the method that minimizes
the number of packages that will be broken in the process?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: standardizing pre-build maintainer actions

[Stefano Zacchiroli]

On Wed, Jun 27, 2007 at 08:08:08PM +0200, Frank Küster wrote:
> > Anyhow I was thinking at something more generic that only getting orig
> > sources
> I don't think a Debian diff.gz should contain arbitrary updates from
> upstream. 

I didn't imply that it should be some other kind of updates, but
generally some work that should be done before building the package. But
probably it is not such a widespread need, sorry for the noise. And
thanks to Russ for pointing to the policy, I wasn't aware that
get-orig-source was actually standardized.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: [Help] Autoconf problems when trying to build WordNet 3.0 package

[Daniel Schepler]

On Wednesday 27 June 2007 16:45:06 pm Andreas Tille wrote:
> On Wed, 27 Jun 2007, Ben Pfaff wrote:
> > OK, I can see now that /usr/lib/tk8.4/tkConfig.sh sets TK_PREFIX
> > in the environment of "configure".  But what is meant to
> > propagate this environment variable into the Makefile?  I don't
> > see anything intended to do that.  Autoconf does not
> > automatically propagate all environment variables from
> > "configure" into Makefiles (nor should it).
> >
> > It looks to me like there's a missing piece in the build system.
>
> Yes, you both seem to come to the same conclusion as I myself - but
> I have no idea how to fix this.  There must be some trick to propagate
> these variables, but how?  I've got no clue out of reading the
> texinfo docs.

For example, AC_SUBST(TK_PREFIX), then make sure Makefile.in has a line
TK_PREFIX = @TK_PREFIX@
-- unless it's generated by automake, which will put in lines like that 
automatically.
-- 
Daniel Schepler


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

Re: [Help] Autoconf problems when trying to build WordNet 3.0 package

[Azazel]

Andreas Tille wrote:
> On Wed, 27 Jun 2007, Ben Pfaff wrote:
>
> >OK, I can see now that /usr/lib/tk8.4/tkConfig.sh sets TK_PREFIX
> >in the environment of "configure".  But what is meant to
> >propagate this environment variable into the Makefile?  I don't
> >see anything intended to do that.  Autoconf does not
> >automatically propagate all environment variables from
> >"configure" into Makefiles (nor should it).
> >
> >It looks to me like there's a missing piece in the build system.
>
> Yes, you both seem to come to the same conclusion as I myself - but
> I have no idea how to fix this.  There must be some trick to propagate
> these variables, but how?  I've got no clue out of reading the
> texinfo docs.

There's an acinclude.m4 file in the 2.1 source which is missing from
your 3.0 source which may be relevant.  I've attached it.

Az.
--
+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+
  www: http://www.azazel.net/
  pgp: http://www.azazel.net/~azazel/az_key.asc
+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+
#
# SC_PATH_TCLCONFIG --
#
#   Locate the tclConfig.sh file and perform a sanity check on
#   the Tcl compile flags
#
# Arguments:
#   none
#
# Results:
#
#   Adds the following arguments to configure:
#   --with-tcl=...
#
#   Defines the following vars:
#   TCL_BIN_DIR Full path to the directory containing
#   the tclConfig.sh file
#

AC_DEFUN(SC_PATH_TCLCONFIG, [
#
# Ok, lets find the tcl configuration
# First, look for one uninstalled.
# the alternative search directory is invoked by --with-tcl
#

if test x"${no_tcl}" = x ; then
# we reset no_tcl in case something fails here
no_tcl=true
AC_ARG_WITH(tcl, [  --with-tcl  directory containing tcl 
configuration (tclConfig.sh)], with_tclconfig=${withval})
AC_MSG_CHECKING([for Tcl configuration])
AC_CACHE_VAL(ac_cv_c_tclconfig,[

# First check to see if --with-tcl was specified.
if test x"${with_tclconfig}" != x ; then
if test -f "${with_tclconfig}/tclConfig.sh" ; then
ac_cv_c_tclconfig=`(cd ${with_tclconfig}; pwd)`
else
AC_MSG_ERROR([${with_tclconfig} directory doesn't contain 
tclConfig.sh])
fi
fi

# then check for a private Tcl installation
if test x"${ac_cv_c_tclconfig}" = x ; then
for i in \
../tcl \
`ls -dr ../tcl[[8-9]].[[0-9]].[[0-9]]* 2>/dev/null` \
`ls -dr ../tcl[[8-9]].[[0-9]] 2>/dev/null` \
`ls -dr ../tcl[[8-9]].[[0-9]]* 2>/dev/null` \
../../tcl \
`ls -dr ../../tcl[[8-9]].[[0-9]].[[0-9]]* 2>/dev/null` \
`ls -dr ../../tcl[[8-9]].[[0-9]] 2>/dev/null` \
`ls -dr ../../tcl[[8-9]].[[0-9]]* 2>/dev/null` \
../../../tcl \
`ls -dr ../../../tcl[[8-9]].[[0-9]].[[0-9]]* 
2>/dev/null` \
`ls -dr ../../../tcl[[8-9]].[[0-9]] 2>/dev/null` \
`ls -dr ../../../tcl[[8-9]].[[0-9]]* 2>/dev/null` ; do
if test -f "$i/unix/tclConfig.sh" ; then
ac_cv_c_tclconfig=`(cd $i/unix; pwd)`
break
fi
done
fi

# check in a few common install locations
if test x"${ac_cv_c_tclconfig}" = x ; then
for i in `ls -d ${libdir} 2>/dev/null` \
`ls -d /usr/local/lib 2>/dev/null` \
`ls -d /usr/contrib/lib 2>/dev/null` \
`ls -d /usr/lib 2>/dev/null` \
; do
if test -f "$i/tclConfig.sh" ; then
ac_cv_c_tclconfig=`(cd $i; pwd)`
break
fi
done
fi

# check in a few other private locations
if test x"${ac_cv_c_tclconfig}" = x ; then
for i in \
${srcdir}/../tcl \
`ls -dr ${srcdir}/../tcl[[8-9]].[[0-9]].[[0-9]]* 
2>/dev/null` \
`ls -dr ${srcdir}/../tcl[[8-9]].[[0-9]] 2>/dev/null` \
`ls -dr ${srcdir}/../tcl[[8-9]].[[0-9]]* 2>/dev/null` ; 
do
if test -f "$i/unix/tclConfig.sh" ; then
ac_cv_c_tclconfig=`(cd $i/unix; pwd)`
break
fi
done
fi
])

if test x"${ac_cv_c_tclconfig}" = x ; then
TCL_BIN_DIR="# no Tcl configs found"

Re: [Help] Autoconf problems when trying to build WordNet 3.0 package

[Ben Pfaff]

Andreas Tille <[EMAIL PROTECTED]> writes:

> Yes, you both seem to come to the same conclusion as I myself - but
> I have no idea how to fix this.  There must be some trick to propagate
> these variables, but how?  I've got no clue out of reading the
> texinfo docs.

That part is easy: just add
AC_SUBST([TK_PREFIX])
AC_SUBST([TCL_INCLUDE_SPEC])
to configure.ac and rerun autoconf and automake.  I assumed you
were trying to figure out why it didn't work out-of-the-box.

Now the build fails at a link step on missing Tk symbols, but I
haven't looked into why.  Quite possibly there's another missing
substitution.

(By the way, it also appears that
AC_LANGINFO_CODESET
in configure.ac should actually be
AM_LANGINFO_CODESET
although I'm not 100% certain.)
-- 
Ben Pfaff 
http://benpfaff.org


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

Re: [Help] Autoconf problems when trying to build WordNet 3.0 package

[Andreas Tille]

On Wed, 27 Jun 2007, Ben Pfaff wrote:


OK, I can see now that /usr/lib/tk8.4/tkConfig.sh sets TK_PREFIX
in the environment of "configure".  But what is meant to
propagate this environment variable into the Makefile?  I don't
see anything intended to do that.  Autoconf does not
automatically propagate all environment variables from
"configure" into Makefiles (nor should it).

It looks to me like there's a missing piece in the build system.


Yes, you both seem to come to the same conclusion as I myself - but
I have no idea how to fix this.  There must be some trick to propagate
these variables, but how?  I've got no clue out of reading the
texinfo docs.

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: Porting from OpenSSL to GnuTLS

[Florian Weimer]

* Bruno Costacurta:

> I might start thinking about porting an x509 application from OpenSSL to 
> GnuTLS (Gnu Transport Layer Security) and so looking about feedbacks, 
> experiences ..etc.. about such porting, libraries ..etc..

What kind of level of X.509 support do you need?  Is chasing
certificate chains a must?  Then it can be kind of hard.

If you just look up the certificate in some kind of database, it's not
that difficult.  In fact, I think the GNUTLS API is easier to work
with.


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

Re: standardizing pre-build maintainer actions

[Frank Küster]

Stefano Zacchiroli <[EMAIL PROTECTED]> wrote:

> On Wed, Jun 27, 2007 at 05:34:42PM +0200, Frank Küster wrote:
>> > I guess a lot of us have similar needs. What about defining a
>> > standardized debian/rules target which should take care of similar
>> > stuff?
>> 
>> We already have that: get-orig-source.  
[...]
> Anyhow I was thinking at something more generic that only getting orig
> sources

I don't think a Debian diff.gz should contain arbitrary updates from
upstream. 

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: [Help] Autoconf problems when trying to build WordNet 3.0 package

[Ben Pfaff]

"Sergei Golovan" <[EMAIL PROTECTED]> writes:

> On 6/27/07, Ben Pfaff <[EMAIL PROTECTED]> wrote:
>> The puzzling thing to me about this situation is what is expected
>> to set TK_PREFIX.  "grep TK_PREFIX" in the wordnet directory
>> shows TK_PREFIX being used, but never defined anywhere.  "grep
>> TK_PREFIX" in /usr/share/aclocal shows no hits at all.
>>
>> Ditto for TCL_INCLUDE_SPEC.
>>
>> What do you expect to set TK_PREFIX and TCL_INCLUDE_SPEC?
>
> They are to be set by /usr/lib/tcl8.4/tclConfig.sh and
> /usr/bin/tk8.4/tkConfig.sh. But something in configure process went
> wrong.

OK, I can see now that /usr/lib/tk8.4/tkConfig.sh sets TK_PREFIX
in the environment of "configure".  But what is meant to
propagate this environment variable into the Makefile?  I don't
see anything intended to do that.  Autoconf does not
automatically propagate all environment variables from
"configure" into Makefiles (nor should it).

It looks to me like there's a missing piece in the build system.
-- 
Ben Pfaff 
http://benpfaff.org


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

Re: [Help] Autoconf problems when trying to build WordNet 3.0 package

[Sergei Golovan]

On 6/27/07, Ben Pfaff <[EMAIL PROTECTED]> wrote:

The puzzling thing to me about this situation is what is expected
to set TK_PREFIX.  "grep TK_PREFIX" in the wordnet directory
shows TK_PREFIX being used, but never defined anywhere.  "grep
TK_PREFIX" in /usr/share/aclocal shows no hits at all.

Ditto for TCL_INCLUDE_SPEC.

What do you expect to set TK_PREFIX and TCL_INCLUDE_SPEC?


If you look at line 20547 (and below) of configure script you'll see
that both tclConfig.sh and tkConfig.sh are sourced, but only few
variables defined in them are actually used. I think there's something
wrong with wordnet autoconf stuff.

--
Sergei Golovan


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

Re: [Help] Autoconf problems when trying to build WordNet 3.0 package

[Sergei Golovan]

On 6/27/07, Ben Pfaff <[EMAIL PROTECTED]> wrote:

The puzzling thing to me about this situation is what is expected
to set TK_PREFIX.  "grep TK_PREFIX" in the wordnet directory
shows TK_PREFIX being used, but never defined anywhere.  "grep
TK_PREFIX" in /usr/share/aclocal shows no hits at all.

Ditto for TCL_INCLUDE_SPEC.

What do you expect to set TK_PREFIX and TCL_INCLUDE_SPEC?


They are to be set by /usr/lib/tcl8.4/tclConfig.sh and
/usr/bin/tk8.4/tkConfig.sh. But something in configure process went
wrong.

--
Sergei Golovan


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

Re: [Help] Autoconf problems when trying to build WordNet 3.0 package

[Ben Pfaff]

Andreas Tille <[EMAIL PROTECTED]> writes:

> the relevant line in src/Makefile.am is
>
> INCLUDES = -I$(top_srcdir)/include  $(TCL_INCLUDE_SPEC) -I$(TK_PREFIX)/include
>
> I have no idea why TCL_INCLUDE_SPEC which is not propagated
> correctly to Makefile.in and thus cc has not the correct path
> to the needed includes.

The puzzling thing to me about this situation is what is expected
to set TK_PREFIX.  "grep TK_PREFIX" in the wordnet directory
shows TK_PREFIX being used, but never defined anywhere.  "grep
TK_PREFIX" in /usr/share/aclocal shows no hits at all.

Ditto for TCL_INCLUDE_SPEC.

What do you expect to set TK_PREFIX and TCL_INCLUDE_SPEC?
-- 
Ben Pfaff 
http://benpfaff.org


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

Re: standardizing pre-build maintainer actions

[Russ Allbery]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
> On Wed, Jun 27, 2007 at 05:34:42PM +0200, Frank Küster wrote:

>> > I guess a lot of us have similar needs. What about defining a
>> > standardized debian/rules target which should take care of similar
>> > stuff?
>> 
>> We already have that: get-orig-source.  

> Documented where?

Debian Policy 4.9.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: standardizing pre-build maintainer actions

[Stefano Zacchiroli]

On Wed, Jun 27, 2007 at 05:34:42PM +0200, Frank Küster wrote:
> > I guess a lot of us have similar needs. What about defining a
> > standardized debian/rules target which should take care of similar
> > stuff?
> 
> We already have that: get-orig-source.  

Documented where?

Anyhow I was thinking at something more generic that only getting orig
sources ... let's call it "maintainer-update"? don't know, I suck at
names.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Can we require build-arch/indep targets for lenny?

[Ben Pfaff]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Currently, policy says that it's recommended (the weakest policy
> directive) to support noopt and nostrip.  My main concern with increasing
> the strength of that directive is that, depending on how demented the
> upstream build system is, it can be difficult to support these options,
> and since neither is used for regular builds in Debian, they're not
> usually tested and aren't necessary for properly functioning packages.

I have a little bit of experience with recompiling packages to
include debug symbols.  In that little of experience I found that
the easiest way to do it was to put a set of wrapper programs in
$PATH that ensured that compilers added debug symbols and that
programs and options to remove them were ignored.  I wonder
whether this general approach would be better than requiring each
package maintainer to implement a pair of build-time options.
The most obvious trouble I can see with it is packages that
invoke tools through absolute paths or reset $PATH themselves.

(I haven't followed previous discussion of these options.  If
this approach has already been considered and discounted, please
ignore me.)
-- 
Ben Pfaff 
http://benpfaff.org


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

Re: key sign

[Guilherme de S. Pastore]

Em Qua, 2007-06-27 às 19:28 +0330, Amin Shali escreveu:
> Hi :)
> Can anyone please sign my key? 

No.

Quoting http://www.debian.org/events/keysigning:

"You should never sign a key for somebody else you haven't met
personally. Signing a key based on anything other than first-hand
knowledge destroys the utility of the Web of Trust. If ones friend
presents other developers with your ID card and your fingerprint, but
you are not there to verify that the fingerprint belongs to you, what do
other developers have to link the fingerprint to the ID? They have only
the friend's word, and the other signatures on your key -- this is no
better than if they signed your key just because other people have
signed it!

"It is nice to get more signatures on ones key, and it is tempting to
cut a few corners along the way. But having trustworthy signatures is
more important than having many signatures, so it's very important that
we keep the keysigning process as pure as we can. Signing someone else's
key is an endorsement that you have first-hand evidence of the
keyholder's identity. If you sign it when you don't really mean it, the
Web of Trust can no longer be trusted."

If you want more information on how to get your key signed, you might
want to take a look at http://nm.debian.org/gpg.php

--
Guilherme de S. Pastore
[EMAIL PROTECTED]


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

key sign

[Amin Shali]

Hi :)
Can anyone please sign my key?
here is my USER-ID:
"Amin Shali (http://www.amshali.org/) <[EMAIL PROTECTED]>"


Thanks,

--
http://www.amshali.org/

Re: yatex maintenance

[Junichi Uekawa]

Hi,

> > sorry, wrong mailing list.
> > re-sending the same mail to @jp.
> 
> But it made me run 
> 
> $ apt-cache show yatex 
> [...]
> Recommends: ptex-bin|ptex-jtex, tetex-bin
> [...]
> Description: Yet Another TeX mode for Emacs
> 
> 
> Please replace tetex-bin with texlive - this is one of the few examples
> where the texlive metapackage is the correct choice.

The original mail was actually meant to be a RFA for yatex, since the
maintainer (who was sponsored) is MIA. So yes, this should be fixed.



regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


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

Re: Looking for a copy of dpkg's old arch repository

[Raphael Hertzog]

On Wed, 27 Jun 2007, Gustavo Franco wrote:
> On 6/27/07, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> >If anyone has a copy of it, please make it available to us.
> >It was named [EMAIL PROTECTED]/dpkg--devel--1.13 AFAIK.
> >(Neither Scott nor Ian have a copy of it)
> 
> Hi buxy,
> 
> Manoj participed on the discussion cited above? It seems that he had
> that repository registered some time ago, maybe he kept a copy
> somewhere.

I asked him already during Debconf, he will look at it when he comes back
from his vacation/trip. He might have a copy on his backup server, not
sure yet.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: standardizing pre-build maintainer actions

[Frank Küster]

Stefano Zacchiroli <[EMAIL PROTECTED]> wrote:

> I guess a lot of us have similar needs. What about defining a
> standardized debian/rules target which should take care of similar
> stuff?

We already have that: get-orig-source.  

If the upstream-provided contents change regularly, this should also
give a new upstream version, however called.  Adding manually selected,
carefully considered patches is a different thing.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

[Help] Autoconf problems when trying to build WordNet 3.0 package

[Andreas Tille]

Hi,

I have some trouble building the new version of WordNet.  For
reasons I do not want to discuss here I had to build a composite
source tarball from two different upstream tarballs and had
to adjust the autoconf stuff - which obviousely failed.  I
putted the relevant files to

   http://people.debian.org/~tille/packages/wordnet/

where you can see in the end of the pbuilder build log the lines:

cc -DHAVE_CONFIG_H -I. -I.. -I../include   -I/include -I../include   -I/include 
   -g -Wall -O2 -c -o wishwn-tkAppInit.o `test -f 'tkAppInit.c' || echo 
'./'`tkAppInit.c
tkAppInit.c:16:16: error: tk.h: No such file or directory

the relevant line in src/Makefile.am is

INCLUDES = -I$(top_srcdir)/include  $(TCL_INCLUDE_SPEC) -I$(TK_PREFIX)/include

I have no idea why TCL_INCLUDE_SPEC which is not propagated
correctly to Makefile.in and thus cc has not the correct path
to the needed includes.

Any help would be welcome

   Andreas.

--
http://fam-tille.de


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

Re: Looking for a copy of dpkg's old arch repository

[Gustavo Franco]

On 6/27/07, Raphael Hertzog <[EMAIL PROTECTED]> wrote:

Hello,

as discussed on [EMAIL PROTECTED], we're looking for a copy of dpkg's old
arch repository used while Scott James Remnant was dpkg's maintainer.

http://lists.debian.org/debian-dpkg/2007/06/msg6.html

If anyone has a copy of it, please make it available to us.
It was named [EMAIL PROTECTED]/dpkg--devel--1.13 AFAIK.
(Neither Scott nor Ian have a copy of it)


Hi buxy,

Manoj participed on the discussion cited above? It seems that he had
that repository registered some time ago, maybe he kept a copy
somewhere.

regards,
-- stratus
http://stratusandtheswirl.blogspot.com
get debian @ http://get.debian.net/


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

Re: apt package channel / python-apt

[Gustavo Franco]

On 6/27/07, Frédéric PICA <[EMAIL PROTECTED]> wrote:

Greets,

I have some interrogations about apt :
I want to develop a centralized system holding what packages operations
happened on a remote debian system (in a database).
I'm using the DPkg::Pre-Install-Pkgs apt option to get information about
what packages are installed/removed/updated but I need also to know from
wich channel the package come (channel + url).
I have took a look at python-apt but I didn't find a good documentation :(,
the same for libapt... so I've got some troubles to use it.



Considering you don't want to write a wrapper over apt or something
like that, there's no reason to dive in python-apt. I would suggest
you to use 'apt-cache madison $pkgname' output on DPkg::Post-Invoke or
something like that, that data compared with the package version
installed would give you the exact 'channel' you want.

regards,
-- stratus
http://stratusandtheswirl.blogspot.com
get debian @ http://get.debian.net/

standardizing pre-build maintainer actions

[Stefano Zacchiroli]

On Sun, Jun 10, 2007 at 08:40:21AM +0900, Junichi Uekawa wrote:
> > > I had an idea and still pondering on it.  I wanted to do automatic
> > > two-way synchronization with README.Debian and wiki.debian.org

I like the idea in general, but I would rather focus on ...

> [web->package]
> 
> 2. upstream FAQ page is updated through 'wget' into the package source
>from time-to-time.

My feeling is that we, maintainers body, have in some packages the need
to do "stuff" before building a package, that this "stuff" often
encompasses accessing the network, and also that the result of "stuff"
needs to be committed in our versioning system (or at the very minimum
to become part of the new Debian source package we are going to upload).

A couple of example from packages I maintain:
- vim-scripts needs to download the HTML pages of all shipped addons in
  order to use them as user documentation available under /usr/share/doc
- vim needs to download upstream patches for micro releases which are
  stored in the source package and applied at build time

I guess a lot of us have similar needs. What about defining a
standardized debian/rules target which should take care of similar
stuff?

Once we have it one can imagine, for example, a CDBS rules file which
implement a dependency of this target as performing the one-way
synchronization asked by Junichi using a mapping from package names to
wiki pages, exploiting the docbook export, and so on and so forth ...

Comments?

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Can we require build-arch/indep targets for lenny?

[Russ Allbery]

Loïc Minier <[EMAIL PROTECTED]> writes:
> On Tue, Jun 26, 2007, Joey Hess wrote:

>> I think it would also be useful to include 'nostrip' and 'noopt' in the
>> Build-Options field, as a way to indicate that the package implements
>> those DEB_BUILD_OPTIONS. I also have some Evil Plans for other things
>> that can go in Build-Options, but they're not ready yet and would be OT
>> in this thread.

>  Why not promote these to requirements in a particular policy version
>  instead?  I fear we will have to list 10 Build-Options in all packages
>  in a couple of years.

Currently, policy says that it's recommended (the weakest policy
directive) to support noopt and nostrip.  My main concern with increasing
the strength of that directive is that, depending on how demented the
upstream build system is, it can be difficult to support these options,
and since neither is used for regular builds in Debian, they're not
usually tested and aren't necessary for properly functioning packages.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Bug#430813: ITP: hubackup -- Concise and easy to use backup application for the desktop user

[Julian Andres Klode]

Package: wnpp
Severity: wishlist
Owner: Julian Andres Klode <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: hubackup
  Version : 0.0.7
  Upstream Author : Sivan Greenberg <[EMAIL PROTECTED]>
* URL : https://launchpad.net/hubackup
* License : GPL 2
  Programming Lang: Python
  Description : Concise and easy to use backup application for the desktop 
user

HUBackup is short for Home User Backup System. As the
name implies, this is a very simple, concise and easy to use backup
application that uses the renowned and proven dar (Disk ARchive) to do
the actual archiving. Emphasis has been on providing true and reliable progress
indication throughout all operations, as well as the ability to cancel any
operation at any given point. HUBackup mainly concerns with backing up your
home folder data, allowing you to restore it in case of data loss.

- -- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable'), (300, 'proposed-updates')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGglzDrCpf/gCCPsIRAuTjAJ0bzjdzc7HkLbcP62ErNb7oLlYPAgCeLtmH
4v2pqY0S9omsaHeQewgv1o8=
=Qp5P
-END PGP SIGNATURE-


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

Re: Porting from OpenSSL to GnuTLS

[Russell Coker]

On Wednesday 27 June 2007 18:05, Bruno Costacurta <[EMAIL PROTECTED]> wrote:
> I might start thinking about porting an x509 application from OpenSSL to
> GnuTLS (Gnu Transport Layer Security) and so looking about feedbacks,
> experiences ..etc.. about such porting, libraries ..etc..
>
> Thanks for your (intellectual and spirit) contribution.

I have made Postal build with either of those SSL libraries with selection via 
autoconf.  Doing this was a major PITA and not something I recommend doing, 
but the code will probably be useful to some people.

Postal is GPL so feel free to copy the source to other GPL projects.

-- 
[EMAIL PROTECTED]
http://etbe.coker.com.au/  My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


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

Re: Can we require build-arch/indep targets for lenny?

[Loïc Minier]

On Tue, Jun 26, 2007, Joey Hess wrote:
> I think it would also be useful to include 'nostrip' and 'noopt' in the
> Build-Options field, as a way to indicate that the package implements
> those DEB_BUILD_OPTIONS. I also have some Evil Plans for other things
> that can go in Build-Options, but they're not ready yet and would be OT
> in this thread.

 Why not promote these to requirements in a particular policy version
 instead?  I fear we will have to list 10 Build-Options in all packages
 in a couple of years.

-- 
Loïc Minier


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

apt package channel / python-apt

[Frédéric PICA]

Greets,

I have some interrogations about apt :
I want to develop a centralized system holding what packages operations
happened on a remote debian system (in a database).
I'm using the DPkg::Pre-Install-Pkgs apt option to get information about
what packages are installed/removed/updated but I need also to know from
wich channel the package come (channel + url).
I have took a look at python-apt but I didn't find a good documentation :(,
the same for libapt... so I've got some troubles to use it.

Thanks for your help,
Frédéric PICA

Looking for a copy of dpkg's old arch repository

[Raphael Hertzog]

Hello,

as discussed on [EMAIL PROTECTED], we're looking for a copy of dpkg's old
arch repository used while Scott James Remnant was dpkg's maintainer.

http://lists.debian.org/debian-dpkg/2007/06/msg6.html

If anyone has a copy of it, please make it available to us.
It was named [EMAIL PROTECTED]/dpkg--devel--1.13 AFAIK.
(Neither Scott nor Ian have a copy of it)

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: [EMAIL PROTECTED] Package Submission

[Steffen Moeller]

Hi Zach,
On Wednesday 27 June 2007 03:44:21 Zachary Palmer wrote:
> Hey, all.  I *think* I have a working submission for the contrib section
> of Debian mainline; this is the [EMAIL PROTECTED] download-and-install
> wrapper that I was discussing a couple days ago.  I'm rather new at
> this, so I don't know exactly how I should proceed.  What is the process
> for screening my package?  Is this the appropriate mailing list to
> discuss the matter?  It'd probably be a good idea to have someone who
> knows what they're doing look over my package and make sure that it's
> not... well... insane.

as it was mentioned in another email, mentors.debian.net would be a good place 
for a first or second version of your package. So is your home page. I would 
presume the Debian-Med community http://www.debian.org/devel/debian-med/ to 
be interested, too, and expect you to eventually find a sponsor, too.

If you have not already, I think you are ready to prepare an ITP (interest to 
pack, http://www.debian.org/devel/wnpp/) for your package, which is commonly 
regarded as the entry point of every new package. Once the package is 
available for download somewhere, you should add this info to your ITP 
report.

Something I would like to discuss is to what degree your package is in 
conflict with, say, boinc-client, another idle time scavenger. I do not think 
that both should be installed on a single machine, but is this something that 
should be stated as a conflict in the control file? Rather not, does it?.

Best regards

Steffen



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

Porting from OpenSSL to GnuTLS

[Bruno Costacurta]

Hello,

I might start thinking about porting an x509 application from OpenSSL to 
GnuTLS (Gnu Transport Layer Security) and so looking about feedbacks, 
experiences ..etc.. about such porting, libraries ..etc..

Thanks for your (intellectual and spirit) contribution.

Regards,
Bruno

-- 
PGP key ID: 0x2e604d51
Key server: hkp://subkeys.pgp.net
Key fingerprint = 713F 7956 9441 7DEF 58ED  1951 7E07 569B 2E60 4D51
--


pgpvEvql7s3ta.pgp
Description: PGP signature

Re: [EMAIL PROTECTED] Package Submission

[Laszlo Gabor Liszi]

Zachary Palmer wrote:
Hey, all.  I *think* I have a working submission for the contrib 
section of Debian mainline; this is the [EMAIL PROTECTED] 
download-and-install wrapper that I was discussing a couple days ago.  
I'm rather new at this, so I don't know exactly how I should proceed.  
What is the process for screening my package?  Is this the appropriate 
mailing list to discuss the matter?  It'd probably be a good idea to 
have someone who knows what they're doing look over my package and 
make sure that it's not... well... insane.


Thanks for the help.  Cheers,

Zach




Take a look at the mentors.debian.net and the debian-mentors maillist.
--
Start Yahoo! Auction now! Check out the cool campaign
http://pr.mail.yahoo.co.jp/auction/


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

Re: Official presentation template

[Andreas Tille]

On Wed, 27 Jun 2007, Javier Fernández-Sanguino Peña wrote:


It would be nice if you uploaded also the files (TeX+figs) you used in  your
presentation. That way people could still use them as a template, or as
a starting point for their own presentations just in case no "official"
template ends up being available.


Well, the slides of the "presentation" are rather what I would NOT like
to use people in their talks because it is just a rude mix from everything
that came into my mind and might be discussed.  I'd regard it by far a
better idea to grab a random one of my other talks if you are looking
for a reasonable template and add some Debian logo stuff.  I have the
sources of all my talks uploaded as well - perhaps a little bit hidden,
but if you follow the link "Used technique" you will reach a page that
explains what you have to do to reproduce the slide.  The rationale
behind this is that the "plain LaTeX source" is just half of the truth
because I store needed input files and images in a common directory.
Try to understand the instructions and bug me in case it is not understandable.
I'll try to fix this as soon as possible.


Oh, and if a design was settled, it would be really nice to have the design
implemented in some other presentation toolkits (besides beamer) such as OO's
impress or Kpresenter. For the benefit of those that do not like LaTeX (I'm
not one of them :)


Yes, this was the idea - but this will definitely not be done by me
because I'm lacking knowledge about the later ones and also lacking
interest.

Kind regards

 Andreas.

--
http://fam-tille.de