Re: best policies for third party Debian packaging and get-orig-source target

[Andreas Tille]

Hi Faheem,

On Mon, Jul 29, 2013 at 04:24:21PM +0530, Faheem Mitha wrote:
> I've got Debian packaging for a piece of software I've written. This
> software probably is too specialized to be part of Debian.

Could you please tell us what specialized software you have written.
You might simply like to post your Description field here to let others
know.

Kind regards

 Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130730070142.gb28...@an3as.eu

Re: best policies for third party Debian packaging and get-orig-source target

[Faheem Mitha]

On Tue, 30 Jul 2013 09:01:43 +0200, Andreas Tille  wrote:
> Hi Faheem,
>
> On Mon, Jul 29, 2013 at 04:24:21PM +0530, Faheem Mitha wrote:
>> I've got Debian packaging for a piece of software I've written. This
>> software probably is too specialized to be part of Debian.
>
> Could you please tell us what specialized software you have written.
> You might simply like to post your Description field here to let others
> know.

Hi Andreas,

Certainly, but I'm pretty sure this is of no general interest. It is
accompanying software for a paper I've written.  It is just an
implementation of the methods I've developed. The package description
itself is fairly useless (I should think about how to write it
better), but I include the abstract of the paper below. This probably
could also use some work.

  We describe and implement a method to predict new members of a DNA
  sequence motif family using Bayesian model selection. This method
  assumes a specific correlation structure on the set of sequences. We
  apply our method to test the prediction of DNA sequence motifs in a
  cross-validation setup for two datasets.

The software uses SQL (PostgreSQL), Python, R and C++, so it is a bit
of a hotchpotch, and while a small package, it has a large number of
dependencies. Unfortunately the R packages I use are not all in
Debian, last I checked.

   Regards, Faheem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnkvesqe.q2h.fah...@chrestomanci.home.earth

Re: best policies for third party Debian packaging and get-orig-source target

[Paul Wise]

On Tue, Jul 30, 2013 at 10:03 AM, Faheem Mitha wrote:

>   We describe and implement a method to predict new members of a DNA
>   sequence motif family using Bayesian model selection. This method
>   assumes a specific correlation structure on the set of sequences. We
>   apply our method to test the prediction of DNA sequence motifs in a
>   cross-validation setup for two datasets.

There are two packages in the archive with descriptions related to
"DNA sequence motif" (mlv-smile alien-hunter), both maintained by
Debian Med (Andreas is part of this effort), I expect they might be
interested in your software being in Debian.

-- 
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
Archive: 
http://lists.debian.org/caktje6h0jt8y+cxjifnrebbvgnwvwmuukkve5yymr-5r-a5...@mail.gmail.com

Re: best policies for third party Debian packaging and get-orig-source target

[Andreas Tille]

Hi Faheem,

I'm really happy that I asked back! ;-)

On Tue, Jul 30, 2013 at 08:03:19AM +, Faheem Mitha wrote:
> On Tue, 30 Jul 2013 09:01:43 +0200, Andreas Tille  wrote:
> > Hi Faheem,
> >
> > On Mon, Jul 29, 2013 at 04:24:21PM +0530, Faheem Mitha wrote:
> >> I've got Debian packaging for a piece of software I've written. This
> >> software probably is too specialized to be part of Debian.
> >
> > Could you please tell us what specialized software you have written.
> > You might simply like to post your Description field here to let others
> > know.
> 
> Hi Andreas,
> 
> Certainly, but I'm pretty sure this is of no general interest.

You can never be sure!  Sometimes it is of specific interest ...

> It is
> accompanying software for a paper I've written.  It is just an
> implementation of the methods I've developed. The package description
> itself is fairly useless (I should think about how to write it
> better), but I include the abstract of the paper below. This probably
> could also use some work.
> 
>   We describe and implement a method to predict new members of a DNA
>   sequence motif family using Bayesian model selection. This method
>   assumes a specific correlation structure on the set of sequences. We
>   apply our method to test the prediction of DNA sequence motifs in a
>   cross-validation setup for two datasets.

The mailing list archive shows that in 2008 you had contributed to the a
plink related thread - so you might know the Debian Med project.  In
case you are unsure you might probably want to have a look at the list
of packages which definitely fall into your field on our web
sentinel[1].  If you want to have your package inside Debian (which
includes a lot of advantages starting from QA means until finally get
your publication listed on our web sentinel) you should move this thread
to Debian Med mailing list and we could talk about details there.  I
personally can not see any advantage for you to create private packages
if you can have publicly available ones.

> The software uses SQL (PostgreSQL), Python, R and C++, so it is a bit
> of a hotchpotch, and while a small package, it has a large number of
> dependencies. Unfortunately the R packages I use are not all in
> Debian, last I checked.

So why not changing at least the availablity of the preconditions?

Looking forward to help you solving your packaging problem in Debian Med
team.

Kind regards

Andreas.

[1] http://debian-med.alioth.debian.org/tasks/bio 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130730090638.gc28...@an3as.eu

Requesting DDs who want to help greet new contributors

[Asheesh Laroia]

Hi all Debianites,

I've been inspired by the "Developer Advisory Team" in another project 
[1], and so I want to create a similar team within Debian. In this email, 
first I'll summarize what the concept of Developer Advisory Team is, and 
second I'll request help.


The stated goals are:

* Reach out to new contributors, thank them for their work and get 
feedback.


* Reach out to people who might be ready to apply for upload rights and 
help them.


* Reach out to contributors that went inactive and get feedback from them 
and offer help.


The key concept here is that we use automated tools, based on the Ultimate 
Debian Database that already exists, to make it very easy to see who is 
newly contributing to the project, and commit as a team to reaching out to 
as many of them as we can in order to greet them. We'd try to reach out to 
them within a few days of them doing their first successful upload.


The people on the Developer Advisory Team would also use these tools to 
help track the progress of new prospective developers into the project. 
This way, when it seems that someone is ready to apply, the DAT members 
can realize that and ping them.


Generally, I believe it's useful to give people personal contacts within 
Debian, above and beyond their first package sponsor. (Lucas Nussbaum 
remarked to me that this is something like the MIA team, only it's to help 
people get *into* Debian, rather than to identify who is *absent*!)



Does any of that sound interesting to you?

* If anyone is interested in participating on that team, just reply 
on-list or off-list to me and I will loop you in (for example, if we 
create a mailing list for this team, will invite you) (simplest way to do 
so: reply off-list to me with the word "yes")


* If you have ideas for how to make this more feasible or useful, reply 
here on debian-devel. There's surely scope to revise the goals, if we 
want.


* If you want to reply saying, "This is a boring project and you should 
not waste your time," please refrain, since I am committed to doing 
something like this. (-:


* If you're on the MIA team or the QA team or some other team and think 
that this should just be a part of your existing team, that's fine by me! 
Preferably discuss here on debian-devel.



I'm interested in finding out how effective this is, so I intend to have 
the team work to measure our results. I'm also interested in bringing this 
idea to other large free software communities that want it!


David Lu (a GSoC student at OpenHatch) has been hacking with me this 
summer on some of the tooling [2], and we've been testing the UI with Paul 
Tagliamonte as a first member of the prospective team. Do you want to join 
in too? (-:


I know many of us in Debian are very busy with our existing commitments to 
the project, so no need to volunteer if you're unable to commit more time. 
paultag and I are interested in being part of this team initially, but 
naturally we'd love more volunteers.


-- Asheesh.

References:

1. https://wiki.ubuntu.com/DeveloperAdvisoryTeam

2. https://lists.debian.org/debian-mentors/2013/07/msg00045.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.02.1307301158250.29...@rose.makesad.us

/etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Christoph Anton Mitterer]

Hi.

Somme years ago Thomas Hood started a discussion[0] about how the system
hostname should be resolved.
The eventual result[1] was that Debian nowadays ships /etc/hosts like
these per default:

127.0.0.1 localhost
127.0.1.1 . 

As also described in the Debian reference[2].

I had a short mail conversation with Thomas and he proposed bringing up
the following at d-d.



Some background:
- The hostname is not necessarily a domain name, at least not de jure.
But in reality, many programs and people rely or are at least used to to
the hostname being resolvable.
That practise won't change and we cannot do much about it.

- Most applications that listen to the loopback actually only listen to
127.0.0.1 (and perhaps ::1) but often not to 127.0.0.0/8.

- A system does not necessarily have a domainname set (e.g. during
installation). Whether this is a good idea or not (especially with
respect to security considerations) is beyond that mail.
At least we should say it doesn't have to.
I personally always set a domain (well my own domain) even on mobile
systems that are connected to arbitrary networks.

- The system hostname (and domainname if any) should ALWAYS be
resolvable, whether a network is up or not, regardless of which.
(Assuming that lo is always up, if not, many things break anyway.)

- "localhost" when added like this to /etc/hosts is basically like a
TLD.
"localhost" is one of the reserved names, unlike ip6-localhost and
friends and unlike .localdomain.

- Back then, Thomas pointed out several ides on who the resolution could
be done (e.g. with a small nsswitch module) - I think the way
via /etc/hosts is probably the most simple one and also the one which
literally everybody will expect.
Therefore I don't suggest another system.

- The hostname MUST resolve to an address of the local host.
And if there is a domain name set, hostname.domainname MUST do so as
well.

- The current way of having
127.0.1.1 . 
i.e. the hostname resolving to 127.0.1.1 leads to some issues,
especially that you cannot reach those services that bind to 127.0.0.1
only.
It also doesn't point to ::1.




So I have basically two proposals / things to discuss:

I) Switch the .  to 127.0.0.1 unless
there is any strong reason to have it on another address.

I made some tests:
/etc/hosts (or the same entries swapped):
127.0.0.1   localhost
127.0.0.1   foobar
or (or the same entries swapped:
127.0.0.1   localhost
127.0.0.1   foobar.bar.net foobar
or (or the same entries swapped:
127.0.0.1   localhost localdomain.localhost
127.0.0.1   foobar.bar.net foobar

all lead to the desired results
$ hostname 
foobar
$ hostname -f
foobar respectively foobar.bar.net
$ hostname -d
 respectively bar.net

even hostname -a works as it should.

So the only thing that needs to be secured for the correct resolution is
that we don't mix up the localhost line with the foobar line.
And the order of the line's entries is important, e.g. it must be:
127.0.0.1   foobar.bar.net foobar
not
127.0.0.1   foobar foobar.bar.net

The only question open here is, whether we generate:
127.0.0.1   localhost
127.0.0.1   foobar[.bar.net foobar]
or
127.0.0.1   foobar[.bar.net foobar]
127.0.0.1   localhost

This controls what reverse resolution leads to (e.g. what tools like
netstat show).
I personally would take the first ordering,... since one sees localhost
then which usually makes it really clear what happens.


Further, but this isn't the case anymore anyway,... we should not
generate localhost.localdomain.


=> so the overall proposal (I) is:
If no one has any technical reasons against, can we stop using 127.0.1.1
and let the hostname point to 127.0.0.1 as in:
127.0.0.1   localhost
127.0.0.1   foobar[.bar.net foobar]




II) The second proposal is IMHO less important but probably related:
Should the hostname point to a static IP address (or better said an
address that is not the loopback)?

Most people set the static IP address of a system for their hostname
e.g.
127.0.0.1   localhost
66.66.66.66 foobar[.bar.net foobar]


Issues with that:
- Even if static, the iface may be up or not... sure this is true for lo
as well,... but lo usually always works... with some fancy network card
you can easily have driver problems (I could tell you some stories about
the myrinet cards at our institute).
If down, you cannot use the address anymore.

- Firewalling: I personally feel more safe if I know that stuff directed
to the localhost really use the loopback interface... and are not
touched by any of my (e.g.) eth0 firewall rules.

- Predictability:
When we set 127.x.x.x as default on systems with no static IP, and
x.x.x.x on the others... on does not immediately know on a system what
. or  actually are.
If we would generally point them to 127.0.0.1, it would be always clear,
hostname = loopback.

- "Primary Interface"
At least nowadays, there is probably nothing like a primary iface
anymo

Bug#718365: ITP: Testdrive -- run the daily Ubuntu ISO in a virtual machine

[Jackson Doak]

Package: wnpp
Priority: wishlist
Owner: Jackson Doak 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: testdrive
  Version : 3.22
  Upstream Author : Andres Rodriguez 
* URL or Web page : https://launchpad.net/testdrive
* License : GPL-3
  Description : run the daily Ubuntu ISO in a virtual machine

Testdrive is a tool for running the daily Ubuntu ISO (an any ISOs you
configure it for) in a virtual machine or on live USB. It is made by
canonical and already packaged in Ubuntu.

Thanks,
Jackson Doak


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+K2i_2d7TFb-mZ=iwq4uvj4k3eimeix_ffbud1fkeyzzmt...@mail.gmail.com

Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Russ Allbery]

Christoph Anton Mitterer  writes:

> - The system hostname (and domainname if any) should ALWAYS be
> resolvable, whether a network is up or not, regardless of which.
> (Assuming that lo is always up, if not, many things break anyway.)

This principal (and the general UNIX tradition of putting the local host
and IP address in /etc/hosts) has caused us no end of problems, since that
information inevitably gets out of date when systems are moved around or
re-IP'd.  We now do not put the local hostname anywhere in /etc/hosts, and
I believe that's the correct configuration for any system with stable DNS
and network.

-- 
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
Archive: http://lists.debian.org/87y58n4vge@windlord.stanford.edu

Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Matt Zagrabelny]

On Tue, Jul 30, 2013 at 3:57 PM, Russ Allbery  wrote:
> Christoph Anton Mitterer  writes:
>
>> - The system hostname (and domainname if any) should ALWAYS be
>> resolvable, whether a network is up or not, regardless of which.
>> (Assuming that lo is always up, if not, many things break anyway.)
>
> This principal (and the general UNIX tradition of putting the local host
> and IP address in /etc/hosts) has caused us no end of problems, since that
> information inevitably gets out of date when systems are moved around or
> re-IP'd.  We now do not put the local hostname anywhere in /etc/hosts, and
> I believe that's the correct configuration for any system with stable DNS
> and network.

Russ,

Does not the Wheezy installer still place hostname.domain.name entries
in /etc/hosts for said hostname?

Or do you mean some entity other than Debian when you say, "we", or is
"now" after the Wheezy release?

Cheers,

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3vaz9x-xz4mruhmb_q6sjbndzgx7kedkownhvklhmq...@mail.gmail.com

Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Russ Allbery]

Matt Zagrabelny  writes:

> Does not the Wheezy installer still place hostname.domain.name entries
> in /etc/hosts for said hostname?

We (Stanford) strip them out in FAI.  We can, of course, continue to do
that, but I thought I'd mention it as a data point.  If you have stable
DNS, you really don't want to have another shadow source of IP to host
mapping on local disk; it's almost certain to cause you problems later.

> Or do you mean some entity other than Debian when you say, "we"

Yes, sorry.

-- 
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
Archive: http://lists.debian.org/87fvuv4u63@windlord.stanford.edu

Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Christoph Anton Mitterer]

On Tue, 2013-07-30 at 14:25 -0700, Russ Allbery wrote:
> We (Stanford) strip them out in FAI.  We can, of course, continue to do
> that, but I thought I'd mention it as a data point.  If you have stable
> DNS, you really don't want to have another shadow source of IP to host
> mapping on local disk; it's almost certain to cause you problems later.
Well so long you have services, which depend on the host resolving to
it's local address (whatever that is)... it think it can have security
impacts if you leave that information up to some other server (e.g. your
DHCP).

Consider an application which only accept packets originating from
 as a security measure.. if the DNS server goes evil... than
that might be used by an attacker.



Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Requesting DDs who want to help greet new contributors

[Charles Plessy]

Le Tue, Jul 30, 2013 at 12:00:18PM -0400, Asheesh Laroia a écrit :
> Hi all Debianites,
> 
> I've been inspired by the "Developer Advisory Team" in another
> project [1], and so I want to create a similar team within Debian.
> In this email, first I'll summarize what the concept of Developer
> Advisory Team is, and second I'll request help.
> 
> The stated goals are:
> 
> * Reach out to new contributors, thank them for their work and get
> feedback.
> 
> * Reach out to people who might be ready to apply for upload rights
> and help them.
> 
> * Reach out to contributors that went inactive and get feedback from
> them and offer help.

Hi Asheesh,

When I saw a couple of emails about "Developer Advisory Team" on
debian-mentors, I had a hard time figuring out what it was about, and since I
had no extra time to find an answer, I concluded that Ubuntu do what it
wants...

The goals that you list above give me the impression that such a team in Debian
would better be named "Greeeting", "Reachout", "Encouragement", etc. Team.

Not being a native speaker, "Advisory" for me is has strong connotations, that
remind me that much of the music that I listened when I was younger had a
"Parental Advisory" sticker on it...  Now that I am older, "Advisory" means
prestigious scientist that give us their point of view from outside, on how to
better steer our research institute.  With all the respect I have from my
experienced colleagues, I think that it would not fit the Debian way.

My fear is that after a few years of drifting and rotation of its members, the
"Advisory" team, influenced by its own name, might engage in giving less
greetings and more "advices"...

In summary, I welcome the goal of increasing new contributions to Debian, but
recommend to pick a more casual name for your project.

Cheers,

-- 
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
Archive: http://lists.debian.org/20130730220407.ga18...@falafel.plessy.net

Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Russ Allbery]

Christoph Anton Mitterer  writes:
> On Tue, 2013-07-30 at 14:25 -0700, Russ Allbery wrote:

>> We (Stanford) strip them out in FAI.  We can, of course, continue to do
>> that, but I thought I'd mention it as a data point.  If you have stable
>> DNS, you really don't want to have another shadow source of IP to host
>> mapping on local disk; it's almost certain to cause you problems later.

> Well so long you have services, which depend on the host resolving to
> it's local address (whatever that is)...

...it will break horribly when you have an IP address in /etc/hosts that's
no longer the host's IP address.  Which is the point.

> it think it can have security impacts if you leave that information up
> to some other server (e.g. your DHCP).

If you trust DNS, you trust DNS.  If you don't trust DNS, putting the
local host's IP address in /etc/hosts is just the start of your
remediation.  You had better also put in every other host that host cares
about, and you generally have a much more comprehensive problem.  Putting
the local hostname into /etc/hosts is neither necessary nor sufficient,
and therefore basically useless.

> Consider an application which only accept packets originating from
>  as a security measure.. if the DNS server goes evil... than
> that might be used by an attacker.

And this static file will not help you in the slightest against that
attack, since no host is only going to accept packets from itself, and the
attacker can just spoof one of those other possible source hostnames.

-- 
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
Archive: http://lists.debian.org/87ehaf3dqv@windlord.stanford.edu

Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Simon McVittie]

On 30/07/13 21:43, Christoph Anton Mitterer wrote:
> - Back then, Thomas pointed out several ides on who the resolution could
> be done (e.g. with a small nsswitch module)

libnss-myhostname is basically this, and is packaged. It tries to return
a public address if possible, only falling back to 127.0.0.2 (upstream),
127.0.1.1 (as patched in Debian) or ::1 (IPv6) if there's nothing more
suitable. Possibly it ought to try RFC1918 addresses before 127.x.y.z,
or ought to fall back to 127.0.0.1 instead; I'm sure there are valid
arguments each way.

I would be inclined to install libnss-myhostname by default, since it's
the 99% solution. People who feel strongly about this sort of thing can
uninstall or disable it, and apply whatever manual configuration they
want to.

> I) Switch the .  to 127.0.0.1 unless
> there is any strong reason to have it on another address.

I think `getent hosts 127.0.0.1` should always return "localhost" and
`getent hosts localhost` should always return "127.0.0.1" (and possibly
also "::1", I'm not sure about that part).

I wouldn't have any particular objection to `getent host mymachine`
returning 127.0.0.1 *as well* if it makes things work better.

> Should the hostname point to a static IP address (or better said an
> address that is not the loopback)?
> 
> Most people set the static IP address of a system for their hostname
> e.g.
> 127.0.0.1   localhost
> 66.66.66.66 foobar[.bar.net foobar]

[citation needed] for "most people" - hard-coding a non-loopback IP
address is never going to work for a laptop that's used in multiple
locations, and I hear those are quite popular these days :-)

> I must say though, that I have meet several programs which do some weird
> ways of interface discovery, and these will break when one doesn't set
> the global IP address.
> The problem with such is that they don't let you configure the bind
> address, but always use the hostname to detect it.

I suspect it might be quite common in Java apps developed on Windows.
InetAddress.getLocalhost() does approximately the same as
libnss-myhostname on Windows, so people who primarily test on Windows
will tend to assume that InetAddress.getLocalhost() is "the right thing"
(or at least not entirely useless); but on Linux it looks up
gethostname() in DNS. Minecraft had this bug, resulting in it listening
on 127.0.1.1 on Debian for a while.

I would argue that servers intending to listen on externally-accessible
addresses should default to listening on 0.0.0.0 and letting the kernel
do the work - that way, they'll continue to work correctly if you "roam"
from wired to wifi to 3G or whatever, or if you start them when you
didn't yet have an IP address at all. Applications that really need to
know about individual IP addresses can't safely make the assumption that
you have exactly one non-loopback IP address (because it has never been
true in general), and should use netlink.

> Now some people may argue, that they conveniently use the feature of
> some programs, which allow to configure the bind addresses via
> hostnames. If the address changes, you just adapt /etc/hosts,... and all
> these services will automatically pick it up (at the next start).

I think whether this is viable depends whether your networking is
basically static or dynamic. If your networking is basically static (a
typical server), almost anything is acceptable, because you won't have
to change it very often in any case. If your networking is basically
dynamic (a typical laptop), then hostname-to-IP-address configuration
will have to be either automatic, loopback-based, or "usually broken".

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51f83b03.10...@debian.org

Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Ulrich Dangel]

* Russ Allbery wrote [30.07.13 22:25]:
> We (Stanford) strip them out in FAI.  We can, of course, continue to do
> that, but I thought I'd mention it as a data point.  If you have stable
> DNS, you really don't want to have another shadow source of IP to host
> mapping on local disk; it's almost certain to cause you problems later.

If you are in a situation with no stable DNS you can use
libnss-myhostname which resolves the hostname to your local configured
IP addresses or 127.0.1.1 & ::1 if no IP address is configured.

Ulrich


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130730220945.GB19874@shell

Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Simon McVittie]

On 30/07/13 22:54, Christoph Anton Mitterer wrote:
> Consider an application which only accept packets originating from
>  as a security measure..

If you only want to accept packets from yourself, use 127.0.0.1 (or ::1,
or a Unix socket). Anything else has more possible failure modes.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51f83b98.8050...@debian.org

Re: Requesting DDs who want to help greet new contributors

[Nicolas Guilbert]

On Tuesday, July 30, 2013 12:00:18 PM Asheesh Laroia wrote:
> Hi all Debianites,
> 
> I've been inspired by the "Developer Advisory Team" in another project 
> [1], and so I want to create a similar team within Debian. In this email, 
> first I'll summarize what the concept of Developer Advisory Team is, and 
> second I'll request help.
> 
> The stated goals are:
> 
> * Reach out to new contributors, thank them for their work and get 
> feedback.
> 
> * Reach out to people who might be ready to apply for upload rights and 
> help them.
> 
> * Reach out to contributors that went inactive and get feedback from them 
> and offer help.
> 

This sounds like means rather than goals to me. My guess is that the goal 
would be something like "create a feel-good atmosphere around and within 
Debian" or "get more people engaged in the development of Debian".

If the latter is what we want, how about also involving some other leverages:

 * promoting the mentoring principle as the official Debian way of building 
the community's skill pool. Mentoring is known to be the by far most efficient 
pedagogy [citation pending] - a perfect match for the best distribution :)

 * the mentoring principle holds the promise of exponential growth, which is 
interesting if you can get the coefficient sufficiently far above 0 (one 
mentor can teach "two", who can teach "two" etc.). Pushing up the coefficient 
could also be achieved by contributors to the project acting increasingly as 
advocates for it. This advocacy could be built around narratives such as 
"Contributing to a project like Debian is something one can be proud of - tell 
that you do, what you do, why you do it and encourage others to do it."

Social engineering can also be quite efficient :)

Thanks for a fine initiative,


 Nicolas
-- 
Nicolas Guilbert

"Intelligence: property of a lifeform capable of outliving its planet of 
origin"



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4185618.VxLhrfubq3@ikulrir

Re: Requesting DDs who want to help greet new contributors

[Asheesh Laroia]

On Wed, 31 Jul 2013, Charles Plessy wrote:


Hi Asheesh,

When I saw a couple of emails about "Developer Advisory Team" on 
debian-mentors, I had a hard time figuring out what it was about, and 
since I had no extra time to find an answer, I concluded that Ubuntu do 
what it wants...


The goals that you list above give me the impression that such a team in 
Debian would better be named "Greeeting", "Reachout", "Encouragement", 
etc. Team.




Not being a native speaker, "Advisory" for me is has strong 
connotations, that remind me that much of the music that I listened when 
I was younger had a "Parental Advisory" sticker on it...  Now that I am 
older, "Advisory" means prestigious scientist that give us their point 
of view from outside, on how to better steer our research institute. 
With all the respect I have from my experienced colleagues, I think that 
it would not fit the Debian way.


My fear is that after a few years of drifting and rotation of its 
members, the "Advisory" team, influenced by its own name, might engage 
in giving less greetings and more "advices"...


In summary, I welcome the goal of increasing new contributions to 
Debian, but recommend to pick a more casual name for your project.


I appreciate all this feedback and encouragement! For now I like 
"Developer Encouragement Team", and I'll take your advice to heart that 
"Advisory" sounds like "Parental Advisory"; I agree something more casual 
would be better.


I'm not totally settled on the name, and will mull it over.

-- Asheesh.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.02.1307301958360.19...@rose.makesad.us

Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Steve Langasek]

On Tue, Jul 30, 2013 at 10:43:44PM +0200, Christoph Anton Mitterer wrote:
> Somme years ago Thomas Hood started a discussion[0] about how the system
> hostname should be resolved.
> The eventual result[1] was that Debian nowadays ships /etc/hosts like
> these per default:

> 127.0.0.1 localhost
> 127.0.1.1 . 

> As also described in the Debian reference[2].

> I had a short mail conversation with Thomas and he proposed bringing up
> the following at d-d.

> Some background:



What I'm missing your email is a problem statement explaining what it is
you're trying to solve.  The current implementation has been working
reliably for years.  If it ain't broke, don't fix it.

> - The hostname is not necessarily a domain name, at least not de jure.
> But in reality, many programs and people rely or are at least used to to
> the hostname being resolvable.
> That practise won't change and we cannot do much about it.

And we don't need to.  The current implementation handles this.

> - Most applications that listen to the loopback actually only listen to
> 127.0.0.1 (and perhaps ::1) but often not to 127.0.0.0/8.

That's correct.  If you want to talk to a loopback-only service, you should
be connecting to 'localhost', *not* to the hostname.  You don't want a
server to resolve its hostname to somewhere other than where all the other
machines on the network will resolve it.

> - The system hostname (and domainname if any) should ALWAYS be
> resolvable, whether a network is up or not, regardless of which.
> (Assuming that lo is always up, if not, many things break anyway.)

The current implementation assures this.

> - The current way of having
> 127.0.1.1 . 
> i.e. the hostname resolving to 127.0.1.1 leads to some issues,
> especially that you cannot reach those services that bind to 127.0.0.1
> only.
> It also doesn't point to ::1.

If the service binds to 127.0.0.1 only, it should be asked by the name
'localhost'.

> I) Switch the .  to 127.0.0.1 unless
> there is any strong reason to have it on another address.

> I made some tests:
> /etc/hosts (or the same entries swapped):
> 127.0.0.1   localhost
> 127.0.0.1   foobar
> or (or the same entries swapped:
> 127.0.0.1   localhost
> 127.0.0.1   foobar.bar.net foobar
> or (or the same entries swapped:
> 127.0.0.1   localhost localdomain.localhost
> 127.0.0.1   foobar.bar.net foobar

> all lead to the desired results
> $ hostname 
> foobar
> $ hostname -f
> foobar respectively foobar.bar.net
> $ hostname -d
>  respectively bar.net

> even hostname -a works as it should.

> So the only thing that needs to be secured for the correct resolution is
> that we don't mix up the localhost line with the foobar line.
> And the order of the line's entries is important, e.g. it must be:
> 127.0.0.1   foobar.bar.net foobar
> not
> 127.0.0.1   foobar foobar.bar.net

> The only question open here is, whether we generate:
> 127.0.0.1   localhost
> 127.0.0.1   foobar[.bar.net foobar]
> or
> 127.0.0.1   foobar[.bar.net foobar]
> 127.0.0.1   localhost

> This controls what reverse resolution leads to (e.g. what tools like
> netstat show).
> I personally would take the first ordering,... since one sees localhost
> then which usually makes it really clear what happens.

You have overlooked the fact that only one of these can be the canonical
hostname of 127.0.0.1, and having the hostname and localhost canonicalize to
each other causes problems.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Josh Triplett]

Simon McVittie wrote:
> On 30/07/13 21:43, Christoph Anton Mitterer wrote:
> > - Back then, Thomas pointed out several ides on who the resolution could
> > be done (e.g. with a small nsswitch module)
> 
> libnss-myhostname is basically this, and is packaged. It tries to return
> a public address if possible, only falling back to 127.0.0.2 (upstream),
> 127.0.1.1 (as patched in Debian) or ::1 (IPv6) if there's nothing more
> suitable. Possibly it ought to try RFC1918 addresses before 127.x.y.z,
> or ought to fall back to 127.0.0.1 instead; I'm sure there are valid
> arguments each way.
> 
> I would be inclined to install libnss-myhostname by default, since it's
> the 99% solution. People who feel strongly about this sort of thing can
> uninstall or disable it, and apply whatever manual configuration they
> want to.

I'd like to see this as well (with a corresponding change to the
installer to stop putting an entry for the hostname in /etc/hosts).

This would get us one step closer to having the hostname configured in
only *one* place (namely, /etc/hostname).  With dhclient fixed to detect
the hostname at runtime, I think nss-myhostname is the last step
required before hostname changes become a one-step process of editing
/etc/hostname.

Note that /etc/hosts will still take precedence over nss-myhostname if
it specifies a name for the local system, so you can trivially override
nss-myhostname with or without uninstalling it.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130731014035.GA8425@leaf

Missing makefile

[Jerry Stuckle]

Hi, all,

I hope this is the right list.

I'm trying to compile my first module for Debian (right now it doesn't 
do anything - one step at a time :) ).


My makefile is:

obj-m = mymodule.o
KVERSION = $(shell uname -r)
all:
make -C /lib/modules/$(KVERSION)/build M-$(PWD) modules
clean:
make -C /lib/modules/$(KVERSION)/build M=$(PWD) clean

When I try to run make, I get the following:

make -C /lib/modules/3.2.0-4-amd64/build M-/home/jerry modules
make[1]: Entering directory `/usr/src/linux-headers-3.2.0-4-amd64'
/usr/src/linux-headers-3.2.0-4-common/scripts/Makefile.build:44: 
/usr/src/linux-headers-3.2.0-4-common/scripts/basic/Makefile: No such 
file or directory
make[5]: *** No rule to make target 
`/usr/src/linux-headers-3.2.0-4-common/scripts/basic/Makefile'.  Stop.



That is true - 
/usr/src/linux-headers-3.2.0-4-common/scripts/basic/Makefile does not exist.


I've googled for the problem and seen several others with similar 
problems (including a bug on the Debian list), but nothing stands out. 
I seem to have all of the packages needed, have run m-a update and m-a 
prepare, all with no change.


Has anyone seen this?  Any idea what I'm doing wrong?

TIA


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51f87edd.2000...@attglobal.net

Bug#718394: ITP: buck -- Facebook's build system for large Java projects

[Jonathan Nieder]

Package: wnpp
Severity: wishlist
Owner: jrnie...@gmail.com

* Package name: buck
  Version : 0.20130612-1
  Upstream Author : buck-bu...@googlegroups.com (Facebook)
* URL : http://facebook.github.io/buck/
* License : Apache-2.0
  Programming Lang: Java
  Description : Build system for large Java projects

I plan to upload buck from
https://git.wikimedia.org/summary/operations%2Fdebs%2Fbuck
to experimental, assuming the maintainer is ok with it.
Development of the packaging would be coordinated as before on
gerrit.wikimedia.org.

Thoughts welcome, as always.

Regards,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130731034629.GC11068@elie.Belkin

Re: Missing makefile

[Paul Wise]

On Wed, Jul 31, 2013 at 5:05 AM, Jerry Stuckle wrote:

> I'm trying to compile my first module for Debian (right now it doesn't do
> anything - one step at a time :) ).
>
> My makefile is:
>
> obj-m = mymodule.o
> KVERSION = $(shell uname -r)

Looks like you are talking about a Linux kernel module. How about
getting that merged into the upstream Linux kernel instead of
packaging it separately?

-- 
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
Archive: 
http://lists.debian.org/caktje6fgpo7x3mhthkwbfjztzavg_pisddghv30v1a_c2bg...@mail.gmail.com