Re: bug #561324: asking questions in postinst

[Reinier Haasjes]

Hi,

> Another good solution would be to get the brokers list in the
> config/preinst (and ask which one to use) if bind or host are already
> there (the common case) and to get the list in the postinst if the
> information has not already been gotten.

I think this won't be such a bad solution. It can also solve the problem
that if somebody can't do a TCP-query (the result is a long dns answer)
that he can still select an broker.
I won't let the user choose but first try to use bind/host, if this
failed because they don't exist or tcp query failed I can go to the
backup list.

Regards,

Reinier


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: automake and intermediate files generated by yacc, lex, valac

[Ansgar Burchardt]

Serafeim Zanikolas  writes:

> On Tue, Dec 29, 2009 at 03:23:21AM +0900, Ansgar Burchardt wrote [edited]:
>> there are several tools that generate C source code that is later
>> complied in object code, e.g. yacc, lex or valac.  automake defaults to
>> distribute these built intermediate files, so they are usually not
>> regenerated during a build.
>
> To control whether automake regenerates auto-generated files, have a
> look at AM_MAINTAINER_MODE [0]

Isn't this only to *disable* regenerating auto-generated files?
If you don't use it, they should be enabled by default (which is kind of
contradicting the documentation there...).

But my goal is the opposite: I want to *force* automake to regenerate
the files, and preferably not even include them in the distribution.

Regards,
Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: automake and intermediate files generated by yacc, lex, valac

[Ansgar Burchardt]

Michael Tautschnig  writes:

>> there are several tools that generate C source code that is later
>> complied in object code, e.g. yacc, lex or valac.  automake defaults to
>> distribute these built intermediate files, so they are usually not
>> regenerated during a build.
>
> Why do you restrict this question to generated C code? configure, Makefile.in
> and some others are generated as well. Wouldn't it be consistent to talk about
> all these files?

I'm not opposed to that, but for now am mainly concerned about files
that end up in the binary packages (or the object code produced from
them).

Regards,
Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: bug #561324: asking questions in postinst

[Patrick Schoenfeld]

On Tue, Dec 29, 2009 at 11:50:40PM -0800, Russ Allbery wrote:
> Patrick Schoenfeld  writes:
> 
> > Debconf or another tool that implements the Debian Configuration
> > Management Specification will also be installed, and any versioned
> > dependencies on it will be satisfied before preconfiguration begins.
> 
> Oh, sorry, I didn't think to check the footnote.
> 
> However, I think you're reading the wrong meaning into the footnote.  "It"
> here refers to "Debconf or another tool that implements"  

Hm, yeah, this could be. 

> In other
> words, what the message is saying is that if your package has a versioned
> dependency on debconf, you're guaranteed to get that version of debconf,
> not some other, before the config script of the package is run.

Oh.. ouch. This indeed makes sense. Too bad that natural language is
sometimes to ambigious ;)

Thanks for enlightening me,
best Regards,

Patrick


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: defaulting to net.ipv6.bindv6only=1 for squeeze

[Bernhard R. Link]

* Ben Hutchings  [091229 19:26]:
> > I routinely blacklist the ipv6 module. There are far too many
> > programs breaking or doing stuff I do not want if it is loaded.
>
> I trust you have filed bugs on these applications?

No, on most I have not. I don't believe anyone only having ipv6 right
now so if ipv4 is broken I assume people know this and simply fix my
machines. (It's the sad state of affairs that the situation is broken
in so many subtle ways that sometimes every single program can hardly
do something[1]).

Hochachtungsvoll,
Bernhard R. Link

[1] For example running sshd without -4 and without ipv6 blacklisted causes
(or caused[2]) sshd to listen on ipv6 resulting in
 a) netstat garbling the addresses of connected endpoints
 b) the interface having a link-local address (bug/feature in kernel?),
 which then causes(or caused[2]) programs to do ipv6 dns lookups[3]

 Now who is at fault and whom should I assign bugs to?
 Myself for not giving sshd a -4 (I once tries to
 give every program needing it to avoid ipv6 loaded those options, at
 some point they were to many)? Those programs for causing ipv6 to load
 when there is no interface for it yet? The kernel for assigning
 link-local address when ipv6 is loaded? Libc for asking for ipv6
 addresses even when AI_ADDRCONFIG is given on interfaces with a
 link-local address? (Not to speak of the programs not using
 AI_ADDRCONFIG)

[2] I don't have the time to recheck all the time if things now work
every few months.
[3] which not only pesters the root servers with questions for the
top-level domain "$(hostname -s)", but I do not even want to think
what it means security-wise that the recursing name server I use or
someone sitting in between can answer those requests.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: bug #561324: asking questions in postinst

[Reinier Haasjes]

> This doesn't help with any of your other dependencies, just the dependency
> on debconf (or some other DCMS implementation).
> 
So if I understand correctly a (pre-)depend on host/dig won't help to
make sure bind/dig is installed during the config script.

My idea now is the following:
config-script:
1) if host/dig is available use it to download the list.
2) if dns-query failed of host/dig is unavailable use static list (will
be packed)
3) ask the user which broker to use
4&5) ask username & password

postinst-script:
1) check if user has >1 tunnel
2) if user has >1 tunnel ask which one to use, else just use the one.
3) create the rest of the config script...

Regards,

Reinier


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: defaulting to net.ipv6.bindv6only=1 for squeeze

[Marco d'Itri]

On Dec 30, "Bernhard R. Link"  wrote:

> > > I routinely blacklist the ipv6 module. There are far too many
> > > programs breaking or doing stuff I do not want if it is loaded.
I call bullshit on this.

>  a) netstat garbling the addresses of connected endpoints
This is one of the reasons why bindv6only should be set.

>  b) the interface having a link-local address (bug/feature in kernel?),
Feature.

>  which then causes(or caused[2]) programs to do ipv6 dns lookups[3]
libc issue, solved long ago.

> [3] which not only pesters the root servers with questions for the
> top-level domain "$(hostname -s)", but I do not even want to think
Not really.

> what it means security-wise that the recursing name server I use or
> someone sitting in between can answer those requests.
Maybe you should, because no such thing exists.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: automake and intermediate files generated by yacc, lex, valac

[Guus Sliepen]

On Wed, Dec 30, 2009 at 05:13:29PM +0900, Ansgar Burchardt wrote:

> But my goal is the opposite: I want to *force* automake to regenerate
> the files, and preferably not even include them in the distribution.

The reason to include the autogenerated files is that while most UNIX based
platforms come with a compiler, most of them do not come with GNU autotools,
valac and other programs necessary to create those autogenerated files. So by
including those files in a release tarball, you're doing a huge favour to many
people who want to compile your project on such platforms.

If you want to force those files to be regenerated, just make sure they are
removed in the clean phase (calling make distclean usually does that job), and
then run autoreconf and/or anything else that is necessary in the configure
phase.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: where is /etc/hosts supposed to come from?

[Gabor Gombas]

On Tue, Dec 29, 2009 at 10:31:25PM +0100, Vincent Lefevre wrote:

> Well, the node name is unique. From that, you'll obtain the FQDN with
> either the obsolete function gethostbyname or the new POSIX function
> getaddrinfo (by using the AI_CANONNAME flag). POSIX says:
> 
>   If the AI_CANONNAME flag is specified and the nodename argument is
>   not null, the function shall attempt to determine the canonical name
>   corresponding to nodename (for example, if nodename is an alias or
>   shorthand notation for a complete name).

Read what you have written: _attempt_. It does not say that you can
expect it to succeed even in common situations.

> And here's what the getaddrinfo(3) man page says under Debian:
> 
>   If hints.ai_flags includes the AI_CANONNAME flag, then the ai_canonname
>   field of the first of the addrinfo structures in the returned  list  is
>   set to point to the official name of the host.
> 
> Then you need to configure your machine according to the spec, i.e.
> you need a single FQDN / canonical name / official name of the host.

If getaddrinfo(AI_CANONNAME) fails, that is fully conformant with the
spec you have quoted.

> > Example: there is a router box called "gw" which has about a dozen
> > addresses that resolve to "gw." for just as many domains. Some
> > addresses even share the same NIC. Which FQDN should "hostname -f"
> > display?
> 
> This doesn't really matter. The FQDN may also be another name, i.e.
> the nodename may be something more meaningful than "gw".

But it is not. This is a real world example. Reality does not match your
dream world.

> > Why that one, and not some other?
> 
> You should ask this question to those who configured such routers
> (but this would be more a practical matter, as you may have plenty
> of choices).

_I_ did configure it. I _know_ that none of the addresses is more
important than the other.

And you know, if you do not pretend such silly things that a host should
have just a single FQDN or that "hostname -f" should return anything
meaningful, then the above configuration works flawlessly. Only if you
start to pretend things that are simply not true you start having
problems.

> A FQDN is not associated with an IP address, but with a host. You
> cannot call them FQDN, which already has a well-established meaning.

Now this is bullshit. FQDN is a term related to DNS. An FQDN resolves to
a set of resource records, which may be IPv4 or IPv6 addresses and a
couple of other things, but definitely _NOT_ hosts, as that term has no
meaning for the DNS.

If the FQDN resolves to multiple IP addresses, then the very same FQDN
can belong to multiple hosts simultaneously. Similarly, if a host has
multiple IP addresses, then multiple FQDNs may point to it. You can even
mix these:

- host1 has addresses 192.168.1.1 and 192.168.2.1
- host2 has addresses 192.168.1.2 and 192.168.2.2
- the DNS has the following records:

service1.domain.IN  A   192.168.1.1
IN  A   192.168.1.2
service2.domain.IN  A   192.168.2.1
IN  A   192.168.2.2

Now both hosts has two FQDNs, and both FQDNs point to two hosts; neither
"host1" nor "host2" is resolvable. And it all works just fine if you do
not make invalid assumptions about what FQDNs are and how they are used.

> If I understand correctly, you do a reverse DNS lookup. Now, I'm
> wondering... Can a hostname obtained by reverse DNS lookup resolve
> to different IP addresses?

Of course it can. And it is common to refuse connections from such hosts
using the PARANOID option of TCP wrappers (which was first released more
than 18 years ago, so don't pretend it is some new thing).

> "hostname -f" just follows the POSIX notion of canonical name (a.k.a.
> FQDN). So, I doubt it will die.

Please quote the exact text from POSIX that says that

- there MUST be a canonical name,
- and that name MUST be an FQDN.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Gabor Gombas]

On Wed, Dec 30, 2009 at 02:36:12AM +0100, Vincent Lefevre wrote:

> BTW, Debian defines /etc/mailname as containing the FQDN. So,
> this notion is explicitly defined on Debian, and one should
> expect "hostname -f" to return the same name (according to its
> documentation).

What makes you think that /etc/mailname should have any resemblance to
the host name? Did you never administer a host that used a dedicated IP
address for sending/receiving mail, and did any other communication on
different addresses? Leaking the real host name in such a situation can
be considered a serious security issue...

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Gabor Gombas]

On Wed, Dec 30, 2009 at 08:37:21AM +0100, Vincent Bernat wrote:

> If this is a real question, put:
> 127.0.1.1 fqdn nodename
> 
> This seems a  very acceptable way to give a FQDN  to your laptop without
> relying  on network.  hostname -f  and  programs using  a similar  inner
> working will be able to get the right result.

Adding meaningless configuration to work around programs that are broken
by design does not seem like a good solution.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Philipp Kern]

On 2009-12-29, Adam Borowski  wrote:
> It's not "hypothetical".  IPv4 sucks so badly compared to IPv6 that once you
> switch your internal hosts to v6-only, you don't want to go back.

You don't switch to v6-only, you switch to dual stack IPv4+IPv6.  One point
being that with a v6-only host you're totally unable to reach IPv4 sites
without the help of application-level proxies.

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage

[Charles Plessy]

Le Tue, Dec 29, 2009 at 08:27:56PM -0800, Russ Allbery a écrit :
> Charles Plessy  writes:
> 
> > There were some concerns that applying patches through debian/rules
> > could be a security hole. In my opinion – that I already expressed in
> > the DEP1 discussion – given that 1) dpkg-source will not extract
> > packages that are not GPG-trusted,
> 
> Eh?  I'm fairly sure it does for me, although it prints a warning.

Indeed I was wrong: dpkg-source will refuse to unnpack a package that is signed
but the key is not available locally, however it will accept to unpack a
package that is not signed.

Sorry for the confusion,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#563052: ITP: mono-fuse -- CLI binding for FUSE

[Marco Nenciarini]

Package: wnpp
Severity: wishlist
Owner: Marco Nenciarini 

* Package name: mono-fuse
  Version : 0.4.2
  Upstream Author : Jonathan Pryor 
* URL : http://www.jprl.com/Projects/mono-fuse.html
* License : MIT/X11
  Programming Lang: C#
  Description : CLI binding for FUSE
  
Mono.Fuse is a binding for the FUSE library, permitting user-space 
file systems to be written in C#.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage

[Andreas Metzler]

Charles Plessy  wrote:
> Le Tue, Dec 29, 2009 at 08:27:56PM -0800, Russ Allbery a écrit :
>> Charles Plessy  writes:
[...]
>> > given that 1) dpkg-source will not extract
>> > packages that are not GPG-trusted,

>> Eh?  I'm fairly sure it does for me, although it prints a warning.

> Indeed I was wrong: dpkg-source will refuse to unnpack a package
> that is signed but the key is not available locally, however it will
> accept to unpack a package that is not signed.

Works for me.

(SID)ametz...@argenau:/tmp$ dpkg-source -x polipo_1.0.4-1.1.dsc
gpgv: keyblock resource `/home/ametzler/.gnupg/trustedkeys.gpg': file open error
gpgv: Signature made Wed Sep 23 21:35:56 2009 CEST using DSA key ID C1F24EA4
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./polipo_1.0.4-1.1.dsc
dpkg-source: info: extracting polipo in polipo-1.0.4
dpkg-source: info: unpacking polipo_1.0.4.orig.tar.gz
dpkg-source: info: applying polipo_1.0.4-1.1.diff.gz

cu andreas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ITP: jdownloader -- download manager for one-click hosting sites

[Piotr Lewandowski]

* Benjamin Drung , 2009-12-23 22:01:

JDownloader is open source (…)
(…) JDownloader is absolutely free of charge (…)

You don't need to include this in a package description (hint: DFSG).


This package contains only a dektop file and a script, which will download and
launch the current JDownloader.

And this is just plain wrong.

Regards,
--
Piotr Lewandowski


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage

[Charles Plessy]

Le Wed, Dec 30, 2009 at 01:46:08PM +0100, Andreas Metzler a écrit :
> Charles Plessy  wrote:
> 
> > Indeed I was wrong: dpkg-source will refuse to unnpack a package
> > that is signed but the key is not available locally, however it will
> > accept to unpack a package that is not signed.
> 
> Works for me.
> 
> (SID)ametz...@argenau:/tmp$ dpkg-source -x polipo_1.0.4-1.1.dsc
> gpgv: keyblock resource `/home/ametzler/.gnupg/trustedkeys.gpg': file open 
> error
> gpgv: Signature made Wed Sep 23 21:35:56 2009 CEST using DSA key ID C1F24EA4
> gpgv: Can't check signature: public key not found
> dpkg-source: warning: failed to verify signature on ./polipo_1.0.4-1.1.dsc
> dpkg-source: info: extracting polipo in polipo-1.0.4
> dpkg-source: info: unpacking polipo_1.0.4.orig.tar.gz
> dpkg-source: info: applying polipo_1.0.4-1.1.diff.gz

Indeed, I was doubly wrong. It is ‘dget -x’, not ‘dpkg-source -x’ that refuses
to unpack signed packages whose key is not available.

Sorry again for the noise…

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Adam Borowski]

On Wed, Dec 30, 2009 at 11:12:41AM +, Philipp Kern wrote:
> On 2009-12-29, Adam Borowski  wrote:
> > It's not "hypothetical".  IPv4 sucks so badly compared to IPv6 that once you
> > switch your internal hosts to v6-only, you don't want to go back.
> 
> You don't switch to v6-only, you switch to dual stack IPv4+IPv6.  One point
> being that with a v6-only host you're totally unable to reach IPv4 sites
> without the help of application-level proxies.

Dual stack means you have to configure BOTH.  Of course, that's needed for
world-facing servers only.  Client machines will want dual stack too, but
these can be behind plain outgoing-only NAT v4-wise.

I can't think of a reason to keep IPv4 on internal servers, though.  In
fact, this does give you an extra layer of security if you firewall
something wrong: when an IPv6-only box gets pwned, it's of little use for
your usual attacker.

The main benefit of IPv6 is making things simpler, and dual stacking doesn't
help there.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-29 20:23:31 -0800, Russ Allbery wrote:
> I'm having a hard time figuring out what you think the canonical name of
> my laptop could possibly be, given that it has no static IP address and no
> DNS entry.

It doesn't need to have a static IP, nor a DNS entry.

> In practice, it's whatever arbitrary label that I gave it,

Yes, it may be arbitrary (the main goal being to identify the
machine).

> and none of these DNS-based resolution techniques are going to do
> you much good or give you any sort of consistent answer, if they
> work at all.

If it doesn't make sense (e.g., you can't connect to the machine
from the outside), they don't need to work... well, only locally,
but it has been said that 127.0.1.1 is typically used for that.

> I have no entry in /etc/hosts other than 127.0.0.1 and the corresponding
> IPv6 entries.  What could I possibly put in there?

As said by Steve Langasek in <2009122753.ga19...@dario.dodds.net>,
something of the form:

127.0.1.1 nodename.domainname

> > This is implementation-defined, but still, the host has a canonical
> > name, that should be obtainable with getaddrinfo, as described.
> 
> I don't see where you're finding any justification for that "should" in
> POSIX.

Otherwise this would be a failure, and failures are things that one
wants to avoid.

> > BTW, Debian defines /etc/mailname as containing the FQDN. So, this
> > notion is explicitly defined on Debian, and one should expect
> > "hostname -f" to return the same name (according to its
> > documentation).
> 
> No, it's not.  You have completely misunderstood the purpose of
> /etc/mailname.

No, this is what is documented. You should RTFM.

> If your package needs to know what hostname to use on (for example)
> outgoing news and mail messages which are generated locally, you
> should use the file /etc/mailname. It will contain the portion after
> the username and @ (at) sign for email addresses of users on the
> machine (followed by a newline).
> 
> So on my system, for instance, /etc/mailname is "stanford.edu,"
> because that's what goes on the RHS of e-mail addresses. Which, of
> course, is not the canonical name of my laptop.

"stanford.edu" is definitely wrong. First it's just a domain name, not
a FQDN (as required by the mailname(5) man page). This would meen that
two different machines could generate the same Message-Id; the right
part of "@" in a Message-Id should contain the hostname to avoid this
kind of problems. Moreover, concerning the e-mail addresses, root is
local to the machine, so that generating a mail from r...@stanford.edu
is incorrect.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-30 11:56:13 +0100, Gabor Gombas wrote:
> On Tue, Dec 29, 2009 at 10:31:25PM +0100, Vincent Lefevre wrote:
> > Then you need to configure your machine according to the spec, i.e.
> > you need a single FQDN / canonical name / official name of the host.
> 
> If getaddrinfo(AI_CANONNAME) fails, that is fully conformant with the
> spec you have quoted.

But that's a ***FAILURE***. Don't assume that things will work
perfectly in such a case.

> > > Example: there is a router box called "gw" which has about a dozen
> > > addresses that resolve to "gw." for just as many domains. Some
> > > addresses even share the same NIC. Which FQDN should "hostname -f"
> > > display?
> > 
> > This doesn't really matter. The FQDN may also be another name, i.e.
> > the nodename may be something more meaningful than "gw".
> 
> But it is not. This is a real world example. Reality does not match
> your dream world.

Could you please read again what I've written? I've said *may*.
"gw" is fine too, if you really want. No theoratical problem with
that.

> > You should ask this question to those who configured such routers
> > (but this would be more a practical matter, as you may have plenty
> > of choices).
> 
> _I_ did configure it. I _know_ that none of the addresses is more
> important than the other.

So what?

> And you know, if you do not pretend such silly things that a host should
> have just a single FQDN or that "hostname -f" should return anything
> meaningful, then the above configuration works flawlessly. Only if you
> start to pretend things that are simply not true you start having
> problems.

I'm not pretending, this is how it is. RTFM.

> > A FQDN is not associated with an IP address, but with a host. You
> > cannot call them FQDN, which already has a well-established meaning.
> 
> Now this is bullshit. FQDN is a term related to DNS.

Wrong. /etc/hosts (which is commonly used for the FQDN) has nothing to
do with DNS.

> An FQDN resolves to a set of resource records, which may be IPv4 or
> IPv6 addresses and a couple of other things, but definitely _NOT_
> hosts, as that term has no meaning for the DNS.

I've never said that a FQDN resolves to hosts.

> If the FQDN resolves to multiple IP addresses, then the very same FQDN
> can belong to multiple hosts simultaneously.

I'd say that's an incorrect configuration. Several mechanisms may fail
in such a case (e.g. Message-Id generation).

> Similarly, if a host has multiple IP addresses, then multiple FQDNs
> may point to it. You can even mix these:
> 
> - host1 has addresses 192.168.1.1 and 192.168.2.1
> - host2 has addresses 192.168.1.2 and 192.168.2.2
> - the DNS has the following records:
> 
>   service1.domain.IN  A   192.168.1.1
>   IN  A   192.168.1.2
>   service2.domain.IN  A   192.168.2.1
>   IN  A   192.168.2.2

One often uses CNAME for services, or the FQDN may be a bit more
hidden. For instance:

$ host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 209.85.227.106
www.l.google.com has address 209.85.227.147
www.l.google.com has address 209.85.227.99
www.l.google.com has address 209.85.227.103
www.l.google.com has address 209.85.227.104
www.l.google.com has address 209.85.227.105
$ host 209.85.227.106
106.227.85.209.in-addr.arpa domain name pointer wy-in-f106.1e100.net.
$ host 209.85.227.147
147.227.85.209.in-addr.arpa domain name pointer wy-in-f147.1e100.net.

and so on. (I'm not saying that wy-in-f106.1e100.net,
wy-in-f147.1e100.net and so on are the FQDN's of these hosts,
but this is probably the case.)

In your example, host1.domain and host2.domain could be the respective
FQDN's of these hosts, that could resolve as 127.0.1.1 locally on each
machine.

> > If I understand correctly, you do a reverse DNS lookup. Now, I'm
> > wondering... Can a hostname obtained by reverse DNS lookup resolve
> > to different IP addresses?
> 
> Of course it can.

So, this would mean that your new option --all-fqdns would lie,
as it could give IP's belonging to other machines.

> > "hostname -f" just follows the POSIX notion of canonical name (a.k.a.
> > FQDN). So, I doubt it will die.
> 
> Please quote the exact text from POSIX that says that
> 
> - there MUST be a canonical name,
> - and that name MUST be an FQDN.

For instance, under getnameinfo():

  The flags argument is a flag that changes the default actions of the
  function. By default the fully-qualified domain name (FQDN) for the
  host shall be returned, but:

This means that a host *has* a FQDN (POSIX doesn't say "if there is
one" and something like that). It is just an implementation-defined
property of the system.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-d

Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage

[gregor herrmann]

On Wed, 30 Dec 2009 22:09:51 +0900, Charles Plessy wrote:

> Indeed, I was doubly wrong. It is ‘dget -x’, not ‘dpkg-source -x’ that refuses
> to unpack signed packages whose key is not available.

JFYI: This can be changed by setting
DGET_VERIFY=no
in ~/.devscripts .

Cheers,
gregor 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Johnny Cash: Field Of Diamonds


signature.asc
Description: Digital signature

Re: Bug#563004: ITP: procserv -- A process server with telnet console and log access

[Ralph Lange]

Hello,

On Wed 30 Dec 2009 2:07:16 Frank Lin PIAT wrote:

I am curious why ssh+screen can't do the job? It would be much more
secure than telnet. It would be nice to add a note in the package
description.

Also it is much more "à la unix" to use two tools together to do one
job, each one doing one thing well.
  


Here's a bit of background:
procServ origins as a tool for the open source accelerator and physics 
control system software EPICS (http://www.aps.anl.gov/epics). In that 
context it is mainly used to run "soft" EPICS I/O processes in the 
background, while giving access to the console (stdin/stdout) of the 
process through a local telnet port. These soft IOC (input/output 
controller) processes are doing real-time (as fas as Linux allows) 
stuff, are heavily multi-threaded, doing lots of socket-based IO.
The other, "hard" IOCs in control systems are usually VME-based systems 
running a real-time OS, with their serial console wired to a terminal 
server, that allows telnet access. (Some with, most without authentication.)


A ssh/screen combination was used to run the soft IOCs in the beginning, 
but we had many reports that using nifty features of screen (like 
browsing the history buffer) would stall threads and eventually crash 
the child process. Also (to provide the rich set of features), screen 
always assumes the connecting terminal is interactive and understands 
VT100 escape sequences, which is not the case when using a more generic 
console access and logging facility like conserver, where connecting to 
screen sessions fill up log files with escape sequences that make 
viewing the log impossible.


So to make things simpler, a lot more stable, and actually more "à la 
unix", procServ was created as a small, simple facility that runs a 
child process and connects the console to a telnet server, and that's 
it. No history browsing, no authentication, no multiple, named, 
individually colored background sessions, no terminal escape sequences. 
It adds some system-service level features that screen misses, like 
restarting the child manually or automatically (with a grace period), 
blocking characters that could kill the child, creating PID files, etc.


To keep things secure, procServ only allows telnet connections from 
localhost, so the suggested tool chain is 
conserver(/ssh/)telnet/procServ: conserver doing multi-user mode, 
authentication/authorization, central logging, etc., either running 
locally (connecting by telnet to procServ), or remote (connecting by ssh 
then telnet to procServ). Within a control system, the use of conserver 
allows to integrate the "hard" and "soft" IOCs in exactly the same 
fashion, i.e. access to the console, log files etc. is the same for VME 
real-time and Linux soft real-time IOCs.


Ralph


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Bernd Eckenfels]

In article <20091229135244.gc26...@xvii.vinc17.org> you wrote:
> When the machine is correctly configured (i.e. really has a FQDN),
> "hostname -f" is reliable. But note that this is Debian-specific.

It is not. It is net-tools specific, hostname -f uses gethostbyname. If you
only want the node name, and if the node name is fqdn, you can use
"hostname" or "hostname -s" to get it with or without the domain.

Besides that, I would allow FQDN in /etc/hostname

Gruss
Bernd


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#563081: ITP: r5u87x -- firmware loader for cameras based on Ricoh R5U87x chipsets

[David Jurenka]

Package: wnpp
Severity: wishlist
Owner: David Jurenka 

* Package name: r5u87x
  Version : 0.2+r62
  Upstream Author : Alexander Hixon 
* URL : http://www.bitbucket.org/ahixon/r5u87x/
* License : GPLv2
  Programming Lang: C
  Description : firmware loader for cameras based on Ricoh R5U87x chipsets

This package contains a firmware loader for cameras based on Ricoh R5U87x
chipsets that are UVC (USB video class) compliant.

Please note that the firmware itself is not included because of its unclear
copyright and license status. The package contains a script that helps users
download the necessary firmware from the upstream repository if they wish.
The script is located at /usr/share/r5u87x/r5u87x-download-firmware.sh .



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Henrique de Moraes Holschuh]

On Tue, 29 Dec 2009, Russ Allbery wrote:
> > If this is a real question, put:
> > 127.0.1.1 fqdn nodename
> 
> I think we're having some sort of fundamental misunderstanding or
> communications gap here.  What FQDN do you think I should put there?
> Should I just make something up, like laptop.russ.allbery?

Yes, if you must/want.

I prefer to alocate such host names in a real domain, and give them just TXT
records or 127.0.1.1 A records in some weird cases where I can't trust the
box to not do idiotic things like go to the DNS bypassing the libc resolver.

Any arbritary but valid and unique DNS name would do.  People often use
".local" suffixes when doing that, I've seen ".local", ".localnet" and many
others.

> In truth, my laptop *does not have an FQDN*.  The concept has no useful

It must have, POSIX provided a way for apps to query it, and apps started
doing that.  So you need one.  It will be an arbitrary one, but that's fine.

> You seem to have a basic assumption that every given machine can, at the
> end of the day, be assigned a unique "home" in DNS that is somehow more
> legitimate and more correctly defines that system than any other.  This is
> simply not the case in several practical real-world situations.

Well, sorry, but since gethostname() and friends exist and are used, there
IS a special name which is the box main 'identity'.  That one needs to be
there, needs to be sane, and most apps that use it will require it to
resolve to something that works (that's what the loopback is for).

Whether an application should be using gethostname() at all is a different
problem.

Give your box an GUID as its canonical name, if you want.  Change at every
boot, if you want.  Add a .local suffix to it to make it a FQDN (since too
much stuff is too broken to undestand a top-level FQDN).  As long as it is
resovable by the box itself, that's a perfectly fully functional canonical
host name.

> As with a few other people commenting on this thread, I usually shrug and
> pick an arbitrary one of the DNS names assigned to a multihomed box to be
> the "real" name for hostname, since usually it doesn't matter.  But I

You are quite correct in that.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Henrique de Moraes Holschuh]

On Tue, 29 Dec 2009, Vincent Lefevre wrote:
> On 2009-12-29 17:44:31 +0100, Milan P. Stanic wrote:
> > Mutt in testing/unstable use /etc/mailname.
> 
> But not the official Mutt version.

Who lets you configure the correct domain you want it to use for email
addresses in its config files, although I don't recall if you can tell it
what to use for message-ids.

Debian mutt will autoconfigure better, but that's it.

That said, the canonical name is required by POSIX, but POSIX (looking at
SuSv3) doesn't require it to be unique, doesn't give it any application
usage notes, and in fact doesn't even require it to be a FQDN (which is, in
fact a pratical requirement of the stuff that uses the canonical name).

If you want proper message-ids, do it right and have a GUUID in it.  If mutt
depends on the result of gethostname() to be unique in the whole world to
generate proper message-ids, it is broken.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Henrique de Moraes Holschuh]

On Wed, 30 Dec 2009, Henrique de Moraes Holschuh wrote:
> > In truth, my laptop *does not have an FQDN*.  The concept has no useful
> 
> It must have, POSIX provided a way for apps to query it, and apps started
> doing that.  So you need one.  It will be an arbitrary one, but that's fine.

Better correct myself here.  POSIX provides a way for apps to query the
canonical host name, but DOES NOT REQUIRE IT TO BE A FQDN.

So, it provided the notion of a "special name", the canonical host name.

In practice, it has to be a FQDN, but that's due to bad usage by
applications, not a POSIX (or SuSv3) requirement.

And anything that depends on it to be unique in the whole world is broken.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Henrique de Moraes Holschuh]

On Wed, 30 Dec 2009, Philipp Kern wrote:
> You don't switch to v6-only, you switch to dual stack IPv4+IPv6.  One point
> being that with a v6-only host you're totally unable to reach IPv4 sites
> without the help of application-level proxies.

That's false.  You can use protocol-level gateways, which do NAT and PT
(protocol translation).

But you are much better off with application-level proxies.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: automake and intermediate files generated by yacc, lex, valac

[Henrique de Moraes Holschuh]

On Tue, 29 Dec 2009, Ansgar Burchardt wrote:
> there are several tools that generate C source code that is later
> complied in object code, e.g. yacc, lex or valac.  automake defaults to
> distribute these built intermediate files, so they are usually not
> regenerated during a build.

[...]

> 1. What is Debian's policy about this,

You have to rebuilt the entire stack from source, and the debian/rules
"clean" target is your friend if the upstream build system doesn't help you.

It is normal to have these intermetidate files in the tarball to ease the
life of the 'download source and build' user, and the distros are used to
dealing with it.

> 2. How to stop automake from including intermediate files,

Sorry, I don't have the canned reply, but you can tweak what automake things
should go into the dist target, and use make distclean and make dist.

> 3. How to make sure the intermediate files are regenerated during the
> build.  Is there a nicer way than removing them?

Frankly, the easiest and least error-prone solution is to have custom clean
rules that nuke these autogenerated files, and use the usual makefile
machinery to make sure they get rebuilt when missing.

> Note: I did send this mail to debian-ment...@l.d.o [1] some time ago,
> but did not get any reply.  Also I think the topic might be of interest
> to others as well.

You might get even better help from the autotools mailinglists, since none
of your questions are really Debian-sepecific.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: bug #561324: asking questions in postinst

[Russ Allbery]

Reinier Haasjes  writes:

>> This doesn't help with any of your other dependencies, just the dependency
>> on debconf (or some other DCMS implementation).

> So if I understand correctly a (pre-)depend on host/dig won't help to
> make sure bind/dig is installed during the config script.

Correct.

> My idea now is the following:
> config-script:
> 1) if host/dig is available use it to download the list.
> 2) if dns-query failed of host/dig is unavailable use static list (will
> be packed)
> 3) ask the user which broker to use
> 4&5) ask username & password

> postinst-script:
> 1) check if user has >1 tunnel
> 2) if user has >1 tunnel ask which one to use, else just use the one.
> 3) create the rest of the config script...

This is roughly what kerberos-configs does, except that it defers the list
to postinst if host isn't available so that it can always do SRV record
queries.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: automake and intermediate files generated by yacc, lex, valac

[Paul Wise]

Your question sounds like you want autotools to automatically rebuild
the intermediary files when ./configure detects the requisite
build-depends. I'd suggest discussing this autotools feature request
on the upstream lists instead of here.

>From the debian/rules side of things; there isn't yet anything better
than just deleting the files before ./configure and in debian/rules
clean.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Russ Allbery]

Vincent Lefevre  writes:
> On 2009-12-29 20:23:31 -0800, Russ Allbery wrote:

>> No, it's not.  You have completely misunderstood the purpose of
>> /etc/mailname.

> No, this is what is documented. You should RTFM.

Er, yes, I have, several times.  It's something that one does when one is
maintaining the manual in question.

>> If your package needs to know what hostname to use on (for example)
>> outgoing news and mail messages which are generated locally, you
>> should use the file /etc/mailname. It will contain the portion after
>> the username and @ (at) sign for email addresses of users on the
>> machine (followed by a newline).
>> 
>> So on my system, for instance, /etc/mailname is "stanford.edu,"
>> because that's what goes on the RHS of e-mail addresses. Which, of
>> course, is not the canonical name of my laptop.

> "stanford.edu" is definitely wrong. First it's just a domain name, not a
> FQDN (as required by the mailname(5) man page).

stanford.edu is an RFC 1035 FQDN.  I've watched N different iterations of
the discussion of exactly what is an FQDN in various IETF lists, and while
there are some strange corner cases, ("va", for instance), stanford.edu
isn't one of them.  You'll observe that the grammar in RFC 1035 matches it
just fine, and all of the requirements stated for it in RFC 1035 are met.

> This would meen that two different machines could generate the same
> Message-Id; the right part of "@" in a Message-Id should contain the
> hostname to avoid this kind of problems.

The term "message ID" appears nowhere in the description of /etc/mailname.
Why do you think it's supposed to be used for generating message IDs?  It
is specifically intended for generating e-mail addresses.

> Moreover, concerning the e-mail addresses, root is local to the machine,
> so that generating a mail from r...@stanford.edu is incorrect.

You do not know either that root is local to my system or that
r...@stanford.edu is incorrect for it.  Both of those are configuration
*choices*, not requirements.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Russ Allbery]

Henrique de Moraes Holschuh  writes:
> On Tue, 29 Dec 2009, Russ Allbery wrote:

>> In truth, my laptop *does not have an FQDN*.  The concept has no useful

> It must have, POSIX provided a way for apps to query it, and apps
> started doing that.  So you need one.  It will be an arbitrary one, but
> that's fine.

The fact that my laptop is working just fine, running Debian unstable,
without having any such thing seems to point out a conflict between your
statement and reality.

> Well, sorry, but since gethostname() and friends exist and are used,
> there IS a special name which is the box main 'identity'.  That one
> needs to be there, needs to be sane, and most apps that use it will
> require it to resolve to something that works (that's what the loopback
> is for).

gethostname() for my laptop returns a string which is neither
fully-qualified nor resolves to anything in either DNS or /etc/hosts.
Which apps break exactly?  I should start filing bugs against them.

> Give your box an GUID as its canonical name, if you want.  Change at
> every boot, if you want.  Add a .local suffix to it to make it a FQDN
> (since too much stuff is too broken to undestand a top-level FQDN).  As
> long as it is resovable by the box itself, that's a perfectly fully
> functional canonical host name.

I don't see why I should have to do any of those things just to satisfy
your misreading of the POSIX standard, when in practice the applications I
run seem to work just fine.  If there are buggy applications that break,
they should be fixed.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Russ Allbery]

Henrique de Moraes Holschuh  writes:
> On Wed, 30 Dec 2009, Henrique de Moraes Holschuh wrote:

>>> In truth, my laptop *does not have an FQDN*.  The concept has no useful

>> It must have, POSIX provided a way for apps to query it, and apps
>> started doing that.  So you need one.  It will be an arbitrary one, but
>> that's fine.

> Better correct myself here.  POSIX provides a way for apps to query the
> canonical host name, but DOES NOT REQUIRE IT TO BE A FQDN.

Ack, sorry, I should have read ahead.

I think it depends on your definition of canonical (that's going to depend
on what protocol you're using to speak to the box and what the box is
doing), but yes, there is a way to retrieve one name for a system, which
is used for things like shell prompts and syslog messages because those
things need a single name.

> In practice, it has to be a FQDN, but that's due to bad usage by
> applications, not a POSIX (or SuSv3) requirement.

I've not run into many that have this problem.

> And anything that depends on it to be unique in the whole world is
> broken.

Indeed.  Which implies, for instance, that if you're using gethostname to
form the LHS of message IDs, you need to be prepared for it to not be
unique.  That was a much-discussed problem in the USEFOR working group
once upon a time.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Bernat]

OoO Pendant le  temps de midi du mercredi 30  décembre 2009, vers 12:03,
Gabor Gombas  disait :

>> If this is a real question, put:
>> 127.0.1.1 fqdn nodename
>> 
>> This seems a  very acceptable way to give a FQDN  to your laptop without
>> relying  on network.  hostname -f  and  programs using  a similar  inner
>> working will be able to get the right result.

> Adding meaningless configuration to work around programs that are broken
> by design does not seem like a good solution.

There are  a lot of  programs requiring some  kind of FQDN  (for example
because they implement a protocol requiring it). How should they get it?
I have never  seen a more universal that to get  node name with uname(),
then use gethostbyname(). Please, provide better way.
-- 
MUD IS NOT ONE OF THE 4 FOOD GROUPS
MUD IS NOT ONE OF THE 4 FOOD GROUPS
MUD IS NOT ONE OF THE 4 FOOD GROUPS
-+- Bart Simpson on chalkboard in episode 9F15


pgpNbq2P1eUD7.pgp
Description: PGP signature

Bug#563109: ITP: e17-modules-svn -- Misc plugins for the e17 window manager

[Albin Tonnerre]

Package: wnpp
Severity: wishlist
Owner: Albin Tonnerre 


* Package name: e17-modules-svn
  Version : 0.16.999.063
  Upstream Author : e17 development team 

* URL : http://www.enlightenment.org/
* License : various (GPL2, BSD, LGPL2.1)
  Programming Lang: C
  Description : Misc plugins for the e17 window manager

This package provides a collection of non-core modules for e17, from the
enlightenment.org SVN repository. They provide various functionnality, such as :
 - Tiling capability
 - Network status applet
 - cpu/mem/disks status applet
 - digital clock applet
 - experimental composite extension


signature.asc
Description: Digital signature

Re: Bug#563109: ITP: e17-modules-svn -- Misc plugins for the e17 window manager

[Mike Hommey]

On Wed, Dec 30, 2009 at 11:28:37PM +0100, Albin Tonnerre wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Albin Tonnerre 
> 
> 
> * Package name: e17-modules-svn
>   Version : 0.16.999.063
>   Upstream Author : e17 development team 
> 
> * URL : http://www.enlightenment.org/
> * License : various (GPL2, BSD, LGPL2.1)
>   Programming Lang: C
>   Description : Misc plugins for the e17 window manager
> 
> This package provides a collection of non-core modules for e17, from the
> enlightenment.org SVN repository. They provide various functionnality, such 
> as :
>  - Tiling capability
>  - Network status applet
>  - cpu/mem/disks status applet
>  - digital clock applet
>  - experimental composite extension

Could the package name *not* include -svn in its name, and use -extras
or something similar if e17-modules only is not possible ?

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#563116: ITP: rtgui -- A web based front-end for rTorrent

[Dario Minnucci (midget)]

Package: wnpp
Severity: wishlist
Owner: "Dario Minnucci (midget)" 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: rtgui
  Version : 0.2.7
  Upstream Author : Simon Hall
* URL : http://code.google.com/p/rtgui/
* License : GPL3
  Programming Lang: PHP
  Description : A web based front-end for rTorrent

rtGui is a web based front end for rTorrent - the Linux command line BitTorrent 
client.
It's written in PHP and uses XML-RPC to communicate with the rTorrent client. 


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

iQIcBAEBCAAGBQJLO+KPAAoJEPyEGy2CyLcRd70P/1qndg0A5H54HlpsEprLveno
OmyWXl3KesJH+91f65V31E7CxrK6TGwAa7QGNB2gBmw2cfgEQBfSkVaK8eRD7TBw
xstgHHhDw41HgCLrDFA6QWiqRBOoecHAzJSsYCzTJzVaFWHTfTZbl/5yQAdQ1haY
7QJcoRll6O9+1PvCXrI02srWcxLqme2z/tuU/g/ZctPl1gSi9xGTlNYQMdcCu48c
nbIQ7ygV5nMwDN2pvkb3hHivX/weQtueBMjMmOddwo6j+v5jNrevCEPEHYjVqolH
vP4Gu/IrZE3Jy5zfN7JBNKX95X/ljXZl+9qIIesW5qMi3EyepjuFReLrrOfnF1jL
QUsodG0EFUlrvommK2kOlqJJ0xR1D7eP9eF9arKi2SeSnWs9PRTybI597NbRVGPb
nJg83rryW17+zRIWp0UZWTiFUGkBUZ0GD22pUGVJwq5rVe4T53K6Why4t1/BLERi
WRskBrXL6s4va3hdAzLm+rB4Jq01pt/FjBlxb+++zTK+ZokKoLLGcseUECg016Vk
VVdSxQrjs3MlFufzwqfbSWkmYFXAbZyH8Lqe6T7JB2NDOUj2asQITsl2tEBnj1ej
xu2kzxmenF/TKsjaviqe6Sjsorebt7hzlcLV+HxcXNEg4Ea86InPni0iPjFOEhPM
slxO5BZh3W5NLZ5wlRjP
=DKQB
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Brian May]

On Wed, Dec 30, 2009 at 03:18:51PM -0200, Henrique de Moraes Holschuh wrote:
> I prefer to alocate such host names in a real domain, and give them just TXT
> records or 127.0.1.1 A records in some weird cases where I can't trust the
> box to not do idiotic things like go to the DNS bypassing the libc resolver.

I wouldn't use ".local" as that seems to be treated as a special case by
zeroconf enabled computers, and various OS seem to have zeroconf enabled by
default (like it or not).
-- 
Brian May 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Sam Morris]

On Wed, 30 Dec 2009 21:28:52 +0100, Vincent Bernat wrote:

> OoO Pendant le  temps de midi du mercredi 30  décembre 2009, vers 12:03,
> Gabor Gombas  disait :
> 
>>> If this is a real question, put:
>>> 127.0.1.1 fqdn nodename
>>> 
>>> This seems a  very acceptable way to give a FQDN  to your laptop
>>> without relying  on network.  hostname -f  and  programs using  a
>>> similar  inner working will be able to get the right result.
> 
>> Adding meaningless configuration to work around programs that are
>> broken by design does not seem like a good solution.
> 
> There are  a lot of  programs requiring some  kind of FQDN  (for example
> because they implement a protocol requiring it). How should they get it?
> I have never  seen a more universal that to get  node name with uname(),
> then use gethostbyname(). Please, provide better way.

The admin should supply it in the program's configuration, since only the 
admin is able to know the correct value.

-- 
Sam Morris


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#563131: ITP: libdebug-client-perl -- module to debug Perl programs remotely

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libdebug-client-perl
  Version : 0.11
  Upstream Author : Gabor Szabo
* URL : http://search.cpan.org/dist/Debug-Client/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to debug Perl programs remotely

Debug::Client is a Perl module designed to facilitate remote debugging of
your Perl software. Its interface consists of connecting to a remote Perl
session, permitting manipulation of breakpoints and providing stack traces
or variable values where needed.

NOTE: this was requested by dam for the Padre project



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#563133: ITP: libtemplate-tiny-perl -- lightweight implementation of Template Toolkit

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libtemplate-tiny-perl
  Version : 0.09
  Upstream Author : Adam Kennedy 
* URL : http://search.cpan.org/dist/Template-Tiny/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : lightweight implementation of Template Toolkit

Template::Tiny is a reimplementation of a partial subset of the Template
Toolkit, in as few lines of code as possible.

It is intended for use in light-usage, low-memory, or low-cpu templating
situations, where you may need to upgrade to the full feature set in the
future, or if you want the familiarity of TT-style templates.

Note: This module is experimental and subject to change without notice.

NEEDED FOR Padre. Requested by Damyan Ivanov.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org