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

[Tollef Fog Heen]

]] 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.

On most of my systems, I solve this by generating /etc/hosts from the
host's primary (from ohai's point of view, that is, the one that will be
picked for traffic sent to the default route) legacy IP address and IPv6
address.

There are of course many ways to skin the cat, this is just mine.  (And
it gives me best of both worlds.)

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


-- 
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/87pptzusca@qurzaw.varnish-software.com

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

[Thomas Goirand]

On 07/31/2013 08:30 AM, Steve Langasek wrote:
> 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.

He did wrote it. 127.0.1.1 breaks because some daemon (many, according
to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should.

IMO, we'd better try to fix these, even if it might be a lot more work.

Thomas


-- 
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/51f8c0d5.2090...@debian.org

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

[Steve Langasek]

On Wed, Jul 31, 2013 at 03:46:29PM +0800, Thomas Goirand wrote:
> On 07/31/2013 08:30 AM, Steve Langasek wrote:
> > 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.

> He did wrote it. 127.0.1.1 breaks because some daemon (many, according
> to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should.

I disagree that this is a problem.  If you are connecting to a loopback-only
service, you should connect to it by the name "localhost".  If you are
connecting to it by hostname, that implies that it's an outward-facing
service - one that should be bound to all interfaces by default.  Anything
else is user / configuration error.

-- 
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: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Ben Hutchings]

On Wed, 2013-07-31 at 15:46 +0800, Thomas Goirand wrote:
> On 07/31/2013 08:30 AM, Steve Langasek wrote:
> > 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.
> 
> He did wrote it. 127.0.1.1 breaks because some daemon (many, according
> to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should.
[...]

You can't bind a server to an address range, and there's the problem.
You have to listen on all addresses and then either immediately close
remote connections after accepting them (e.g. using tcp-wrappers) or
bind to device 'lo'.  Both or which are more complex to implement and
configure.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


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

Re: Missing makefile

[Ben Hutchings]

On Tue, 2013-07-30 at 23:05 -0400, Jerry Stuckle wrote:
> 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
[...]

You typed 'M-' instead of 'M='.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


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

LXDE is dead in Debian?

[Mateusz Łukasik]

Hello everybody,

Can somebody tell me if anybody is engaged in lxde in Debian? If I look on  
for example libfm sources: http://packages.debian.org/source/sid/libfm it  
was NMU last time I see down mailing list and VCS-git too. One of  
uploaders gave up and second did nothing for 2 years. Now I have a  
question what must I do to adopt packages?


Cheers,

Mateusz


--
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/op.w02vxocdifijsr@laptop

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

[Vincent Bernat]

 ❦ 31 juillet 2013 09:46 CEST, Thomas Goirand  :

>> 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.
>
> He did wrote it. 127.0.1.1 breaks because some daemon (many, according
> to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should.

How a daemon could bind to 127.0.0.0/8? bind() only takes an IP address.
-- 
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c


signature.asc
Description: PGP signature

Re: LXDE is dead in Debian?

[Paul Wise]

On Wed, Jul 31, 2013 at 10:45 AM, Mateusz Łukasik wrote:

> Can somebody tell me if anybody is engaged in lxde in Debian? If I look on
> for example libfm sources: http://packages.debian.org/source/sid/libfm it
> was NMU last time I see down mailing list and VCS-git too. One of uploaders
> gave up and second did nothing for 2 years. Now I have a question what must
> I do to adopt packages?

LXDE upstream is merging with RazorQt upstream (also in Debian) so
there doesn't seem much point in adopting the LXDE GTK packages in
Debian right now. Once the upstream situation is sorted out they may
either get removed or updated, depending on the name of the project
created from the merge of the two projects.

http://blog.lxde.org/?p=1046

-- 
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/caktje6gq9k6rfnd+da8epfogzpvc-g7hz+caxgv0u1kzsj8...@mail.gmail.com

Re: LXDE is dead in Debian?

[Jonas Smedegaard]

Quoting Mateusz Łukasik (2013-07-31 10:45:14)
> Can somebody tell me if anybody is engaged in lxde in Debian? If I 
> look on for example libfm sources: 
> http://packages.debian.org/source/sid/libfm it was NMU last time I see 
> down mailing list and VCS-git too. One of uploaders gave up and second 
> did nothing for 2 years. Now I have a question what must I do to adopt 
> packages?

How about the (seemingly to me) less intrusive option of joining the 
"Debian LXDE Maintainers" team?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

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

[Vincent Lefevre]

On 2013-07-31 15:46:29 +0800, Thomas Goirand wrote:
> On 07/31/2013 08:30 AM, Steve Langasek wrote:
> > 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.
> 
> He did wrote it. 127.0.1.1 breaks because some daemon (many, according
> to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should.

I disagree. If the goal is to accept connections for request to ,
then binding on 127.0.0.0/8 wouldn't be a solution, as it wouldn't work
if the IP associated with  is not a loopback one.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC 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
Archive: http://lists.debian.org/20130731104330.ga24...@xvii.vinc17.org

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

[Vincent Lefevre]

On 2013-07-31 11:00:24 +0200, Vincent Bernat wrote:
>  ❦ 31 juillet 2013 09:46 CEST, Thomas Goirand  :
> > He did wrote it. 127.0.1.1 breaks because some daemon (many, according
> > to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should.
> 
> How a daemon could bind to 127.0.0.0/8? bind() only takes an IP address.

Perhaps Thomas actually meant accept any address, then drop those
outside 127.0.0.0/8? But this wouldn't necessarily solve the
mentioned "problem" anyway.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC 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
Archive: http://lists.debian.org/20130731104747.gb24...@xvii.vinc17.org

Bug#718416: general: tty1 is cleared at boot, obscuring a screenfull of important boot messages

[Thorsten Glaser]

Package: general
Severity: normal

Ever since, I think, wheezy, tty1 is cleared at boot like tty2-6 are.
This is bad because it obscures the last screenfull of bootmessages,
at least 25 lines, but with framebugger console, a lot(!) more, which
is very bad.

I’ve got no idea which package is responsible for this change, hence
filing against general. Please help by reassigning to the correct
package and Cc’ing its maintainers (see #704984 for why this needs
to be done manually currently).

Thanks!


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (100, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.10-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh


-- 
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/20130731121120.4687.53776.report...@tglase.lan.tarent.de

Bug#718416: general: tty1 is cleared at boot, obscuring a screenfull of important boot messages

[Michael Biebl]

Am 31.07.2013 14:11, schrieb Thorsten Glaser:
> Package: general
> Severity: normal
> 
> Ever since, I think, wheezy, tty1 is cleared at boot like tty2-6 are.
> This is bad because it obscures the last screenfull of bootmessages,
> at least 25 lines, but with framebugger console, a lot(!) more, which
> is very bad.
> 
> I’ve got no idea which package is responsible for this change, hence
> filing against general. Please help by reassigning to the correct
> package and Cc’ing its maintainers (see #704984 for why this needs
> to be done manually currently).

Use the getty --noclear parameter if you want to keep the messages.


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



signature.asc
Description: OpenPGP digital signature

Re: /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 23:09 +0100, Ulrich Dangel wrote:
> 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.
Yeah... but this doesn't change the "problem" that 127.0.1.1. is used...


Some technical reasons against my own proposal:

1)
I had some off list communication with Thomas Hood in the meantime and
one (strong?) reason back then apparently was, that cyclic resolution
wouldn't work anymore if both, localhost and the hostname point to
127.0.0.1, e.g.

/etc/hosts:
127.0.0.1 localhost
127.0.0.1 hostname[.domainhostname]

If you now resolve "hostname" you get 127.0.0.1, if you reverse-resolve
that, you get localhost (and not hostname).


Surely this is the case, an Thomas meant it caused many troubles... I
tried it, and so far I couldn't find a program which couldn't deal with
that (but obviously I only made a few tests).

And there is not really any guarantee by the concepts of DNS, that this
"cyclic" resolving will work.
So if a daemon makes this assumption it is anyway kinda broken IMHO.


The only major example I know where this is used  in a sense are
mailservers.


2) hosts(5) (also pointed out by Thomas):
"This file is a simple text file that associates IP addresses with
hostnames, one line per IP address."

So that would mean that double entries like I proposed were forbidden
anyway.
I used this however since many years and never found a case where it
didn't work.
Even things like bash's completion seem to happily work with multiple
associations for one address.
Not sure if that text line in the manpage is just a relict from the
past.



Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Missing makefile

[Jerry Stuckle]

On 7/31/2013 2:11 AM, Paul Wise wrote:

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?



Because this is a specialized module to handle interrupts in a hardware 
controller.  It is not general purpose.



--
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/51f908c6.8050...@attglobal.net

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

[Christoph Anton Mitterer]

On Wed, 2013-07-31 at 01:30 +0100, Steve Langasek wrote:
> 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.
You even extracted it yourself from my text:


> > - 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.
Well why not? Imagine that one server in a cluster serves a debian
package repo (e.g. via http)...
I have a common sources.list which all point to
deb http://somehost.foo/debian main

I don't want to make exceptions for the host itself, and have to change
it http://localhost/debian there.

So the only ways around would be:
- set the hostname to the global IP -> has several drawbacks as I
described originally
- let the webserver listen as well on 127.0.1.1,... sure that works but
it's rather ugly to make such special handling... and not all services
are even able to bind to multiple addresses.



> > - 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.
Not sure... IIRC, the installer currently asks, for a static IP, right?
And sets this in /etc/hosts for the hostname.
As I wrote in (II), experience has shown that that can break more easily
than it always being resolved to 127.x.x.x



> > 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.

Yeah,... I realised that, too, in the meantime,... but well... I think
at least from the DNS side there is no guarantee that this should work.
So if you have no hostname set at all in /etc/hosts and let DNS handle
this... there is no guarantee that the domain name and reverse entry
correspond.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

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

[Christoph Anton Mitterer]

On Wed, 2013-07-31 at 12:47 +0200, Vincent Lefevre wrote:
> Perhaps Thomas actually meant accept any address, then drop those
> outside 127.0.0.0/8?
That seems really ugly and error prone IMHO.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Missing makefile

[Jerry Stuckle]

On 7/31/2013 4:39 AM, Ben Hutchings wrote:

On Tue, 2013-07-30 at 23:05 -0400, Jerry Stuckle wrote:

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

[...]

You typed 'M-' instead of 'M='.

Ben.



Ben,

Thanks for catching that (it must have been later than I thought last 
night :) ).


However, that didn't change the problem.  I still get the missing 
Makefile message.



--
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/51f909c1.4010...@attglobal.net

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

[Thomas Goirand]

On 07/31/2013 06:47 PM, Vincent Lefevre wrote:
> On 2013-07-31 11:00:24 +0200, Vincent Bernat wrote:
>>  ❦ 31 juillet 2013 09:46 CEST, Thomas Goirand  :
>>> He did wrote it. 127.0.1.1 breaks because some daemon (many, according
>>> to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should.
>>
>> How a daemon could bind to 127.0.0.0/8? bind() only takes an IP address.
> 
> Perhaps Thomas actually meant accept any address, then drop those
> outside 127.0.0.0/8?

Correct.

> But this wouldn't necessarily solve the
> mentioned "problem" anyway.

I'm not sure there's a problem anyway. I'm on the side of Steve, which
is I think the current setup works quite well. Our users can do a
minimum of configuration, that's what I expect from anyone running a
server/daemon anyway (things who are aimed at our users should be using
localhost anyway).

Thomas


--
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/51f90aa1.70...@debian.org

Re: LXDE is dead in Debian?

[Thomas Goirand]

On 07/31/2013 04:45 PM, Mateusz Łukasik wrote:
> Hello everybody,
> 
> Can somebody tell me if anybody is engaged in lxde in Debian? If I look
> on for example libfm sources:
> http://packages.debian.org/source/sid/libfm it was NMU last time I see
> down mailing list and VCS-git too. One of uploaders gave up and second
> did nothing for 2 years. Now I have a question what must I do to adopt
> packages?

My understanding was that Andrew needs to reinstall his server, and is
waiting on someone else to provide that to him. I expect the issue to be
solved during the next debconf.

Thomas


--
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/51f90afe.2050...@debian.org

Bug#718416: general: tty1 is cleared at boot, obscuring a screenfull of important boot messages

[Thomas Goirand]

On 07/31/2013 08:24 PM, Michael Biebl wrote:
> Am 31.07.2013 14:11, schrieb Thorsten Glaser:
>> Package: general
>> Severity: normal
>>
>> Ever since, I think, wheezy, tty1 is cleared at boot like tty2-6 are.
>> This is bad because it obscures the last screenfull of bootmessages,
>> at least 25 lines, but with framebugger console, a lot(!) more, which
>> is very bad.
>>
>> I’ve got no idea which package is responsible for this change, hence
>> filing against general. Please help by reassigning to the correct
>> package and Cc’ing its maintainers (see #704984 for why this needs
>> to be done manually currently).
> 
> Use the getty --noclear parameter if you want to keep the messages.

If this wasn't clear enough:

sed -i 's|1:2345:respawn:/sbin/getty|1:2345:respawn:/sbin/getty
--noclear|' /etc/inittab

My understanding is that the latest version of getty changed its default
behavior. I do agree that sysv* should have cope with the change though,
and that a new (default) version of /etc/inittab should have been made,
but at the same time this is annoying during upgrades if you changed
anything in that file. So I understand that nothing has been done to
address it. Probably best way would have been to patch getty to keep the
old behavior, though now it's too late, and some may complain that in
Jessie, we changed the behavior of Wheezy...

So, let's close the issue, ok?

Thomas

P.S: It's a little bit too late to complain about this, IMO.


--
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/51f90c18.3050...@debian.org

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 23:15 +0100, Simon McVittie wrote:
> 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.
Sounds nice and as Josh said, why not using it per default?

But it wouldn't change the annoyance I was mainly talking about, namely
that a non-127.0.0.1 is used.


> 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.
Does it first try to determine a global IP, or does it always give
127.x.x.x respectively ::1?


> 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.
If that doesn't break any things... and libnss-myhostname can be made
doing that... that would sound the ideal solution to me.


> [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 :-)
Sure,... but there are still non-laptops/tablets... and Debian want's to
be the "universal" OS ;-)
And as I said, I've seen several weird services which don't work when
the hostname doesn't point to the global IP,... of course this is their
fault and they are especially quite severely broken in multi-homed
setups... but things are as they are and these services probably won't
change anytime soon.


> I suspect it might be quite common in Java apps developed on Windows.
Hehe... you hit the point ;-) But dCache is at least not developed in
Windows :)


> 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".
Sure... but usually you don't run all too much such services on a laptop
anyway.



Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#718416: general: tty1 is cleared at boot, obscuring a screenfull of important boot messages

[Holger Levsen]

reassign 718416 sysvinit
thanks

Hi,

On Mittwoch, 31. Juli 2013, Thorsten Glaser wrote:
> I’ve got no idea which package is responsible for this change, hence
> filing against general.

$ grep etc/inittab /var/lib/dpkg/info/*
/var/lib/dpkg/info/sysvinit.postinst:if [ ! -f /etc/inittab ]
/var/lib/dpkg/info/sysvinit.postinst:   cp -p /usr/share/sysvinit/inittab 
/etc/inittab


cheers,
Holger


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

Processed: Re: Bug#718416: general: tty1 is cleared at boot, obscuring a screenfull of important boot messages

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 718416 sysvinit
Bug #718416 [general] general: tty1 is cleared at boot, obscuring a screenfull 
of important boot messages
Bug reassigned from package 'general' to 'sysvinit'.
Ignoring request to alter found versions of bug #718416 to the same values 
previously set
Ignoring request to alter fixed versions of bug #718416 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
718416: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718416
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
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/handler.s.c.13752766946220.transcr...@bugs.debian.org

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

[Holger Levsen]

Hi,

On Dienstag, 30. Juli 2013, Jackson Doak wrote:
>   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.

IMHO this description lacks info what virtualisation technic is used as well 
what exactly will it be running. Is that system just started or some test run 
or or or?

> It is made by
> canonical and already packaged in Ubuntu.

this doesnt belong in the description.


cheers,
Holger


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

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

[Bastien ROUCARIES]

On Wed, Jul 31, 2013 at 3:01 PM, Thomas Goirand  wrote:
> On 07/31/2013 06:47 PM, Vincent Lefevre wrote:
>> On 2013-07-31 11:00:24 +0200, Vincent Bernat wrote:
>>>  ❦ 31 juillet 2013 09:46 CEST, Thomas Goirand  :
 He did wrote it. 127.0.1.1 breaks because some daemon (many, according
 to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should.
>>>
>>> How a daemon could bind to 127.0.0.0/8? bind() only takes an IP address.
>>
>> Perhaps Thomas actually meant accept any address, then drop those
>> outside 127.0.0.0/8?
>
> Correct.

Using SO_BINDTODEVICE ? Does it is limited to root (some time ago it
was limited to root but now no mention on man 7 socket).

BTW how to detect unsafe usage of 127.0.0.1 ? codesearch of
INADDR_LOOPBACK is inconclusive.
>
>> But this wouldn't necessarily solve the
>> mentioned "problem" anyway.
>
> I'm not sure there's a problem anyway. I'm on the side of Steve, which
> is I think the current setup works quite well. Our users can do a
> minimum of configuration, that's what I expect from anyone running a
> server/daemon anyway (things who are aimed at our users should be using
> localhost anyway).
>
> Thomas
>
>
> --
> 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/51f90aa1.70...@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/CAE2SPAbdsonr5G39M_PPN8gm8HOX_cwkaG_uvFhjLaaJ=es...@mail.gmail.com

Re: Missing makefile

[Ben Hutchings]

On Wed, 2013-07-31 at 08:57 -0400, Jerry Stuckle wrote:
> On 7/31/2013 4:39 AM, Ben Hutchings wrote:
> > On Tue, 2013-07-30 at 23:05 -0400, Jerry Stuckle wrote:
> >> 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
> > [...]
> >
> > You typed 'M-' instead of 'M='.
> >
> > Ben.
> >
> 
> Ben,
> 
> Thanks for catching that (it must have been later than I thought last 
> night :) ).
> 
> However, that didn't change the problem.  I still get the missing 
> Makefile message.

Your Makefile works for me with the typo fixed and a trivial mymodule.c:

#include 
MODULE_LICENSE("GPL");

Please direct further questions to debian-user, as this is not on-topic
for debian-devel.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


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

Re: Missing makefile

[Jerry Stuckle]

On 7/31/2013 10:32 AM, Ben Hutchings wrote:

On Wed, 2013-07-31 at 08:57 -0400, Jerry Stuckle wrote:

On 7/31/2013 4:39 AM, Ben Hutchings wrote:

On Tue, 2013-07-30 at 23:05 -0400, Jerry Stuckle wrote:

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

[...]

You typed 'M-' instead of 'M='.

Ben.



Ben,

Thanks for catching that (it must have been later than I thought last
night :) ).

However, that didn't change the problem.  I still get the missing
Makefile message.


Your Makefile works for me with the typo fixed and a trivial mymodule.c:

#include 
MODULE_LICENSE("GPL");

Please direct further questions to debian-user, as this is not on-topic
for debian-devel.

Ben.



Well, it still doesn't work for me.  No change in the error, and the 
file is still missing.


And compiling kernel modules is off-topic for debian-user.  It should, 
however, be on-topic here.


Of course, if you don't new modules (the hardware will eventually be 
available to the public), then we can always look at other distros.



--
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/51f924ed.7080...@attglobal.net

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

[Wouter Verhelst]

On 30-07-13 22:57, 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.

Agreed; however, for mobile systems, assuming stable networking (or even
the existence of any networking at all) is just plain wrong; and since
there are very good reasons why "ping $(hostname)" and similar things
should work, I think at least a single line with the local hostname
should be in /etc/hosts.

I think using 127.0.1.1 is a bad idea; I wasn't part of the original
discussion, but I've only ever seen problems with it, and I never
understood why we switched to that in the first place. The right way, in
my opinion, is that /etc/hosts should look like this:

127.0.0.1   localhost
127.0.0.1   hostname.domain hostname

or, alternatively:

127.0.0.1   hostname.domain hostnamelocalhost

both make "hostname" output the hostname as specified in /etc/hostname,
and "hostname --fqdn" output the FQDN. It also doesn't result in any
problems with IP address changes in my experience, since 127.0.0.1
should always be correct; the only exception is when the hostname is
actually _changed_, but then you have to change other files anyway
(/etc/hostname, for instance), so at that point it shouldn't matter too
much.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/51f927a1.3050...@debian.org

Re: Bug#718416: general: tty1 is cleared at boot, obscuring a screenfull of important boot messages

[Didier 'OdyX' Raboud]

Le mercredi, 31 juillet 2013 15.17:57, Holger Levsen a écrit :
> reassign 718416 sysvinit
> thanks
> 
> $ grep etc/inittab /var/lib/dpkg/info/*
> /var/lib/dpkg/info/sysvinit.postinst:if [ ! -f /etc/inittab ]
> /var/lib/dpkg/info/sysvinit.postinst:   cp -p
> /usr/share/sysvinit/inittab /etc/inittab

sysvinit didn't change in that regard for a long time. I think the bug 
belongs to util-linux which changed the getty implementation:

util-linux (2.17.2-4) unstable; urgency=low
 (…)
  * Deliver agetty as both agetty and getty, preferring agetty.
Closes: #117596
 (…)
 -- LaMont Jones   Fri, 24 Dec 2010 14:06:47 -0700

Cheers,
OdyX


--
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/201307311715.41868.o...@debian.org

Re: Missing makefile

[Chris Bannister]

On Wed, Jul 31, 2013 at 10:53:33AM -0400, Jerry Stuckle wrote:
> 
> And compiling kernel modules is off-topic for debian-user.  It
> should, however, be on-topic here.

Correct, but you are more likely to be directed to debian-mentors. Try
there.


-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
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/20130731150903.GA9392@tal

Bug#718429: ITP: patsy -- statistical models in Python using symbolic formulas

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko 

* Package name: patsy
  Version : 0.1.0
  Upstream Author : Nathaniel J. Smith 
* URL : http://github.com/pydata/patsy
* License : BSD-2
  Programming Lang: Python
  Description : statistical models in Python using symbolic formulas

 patsy is a Python library for describing statistical models
 (especially linear models, or models that have a linear component)
 and building design matrices.

 patsy is a dependency of upcoming new statsmodels release

 most probably post-release git snapshot will be packaged


-- 
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/20130731155822.9671.70517.report...@novo.onerussian.com

Status of deb(5) format support in Debian

[Guillem Jover]

Hi!

Due to bug 718295, and in preparation to add non-gzip compression
support for control.tar, I've tried to get an accurate view of the
current deb(5) format support in software present in Debian. The
resulting table looks pretty bad:

   

Please help by filling it with either other software that you might
know handles .deb files directly, so that these can get coordinated on
format changes, by filling the '?' in there or by correcting existing
entries (but if in doubt about specific conclusions, please ask here),
or even by actually fixing the software listed there. I should probably
also add other columns, like the type of R/W support, acceptance of
bogus/broken/damaged archives, and similar, but maybe another day.

I've reported some of the problems, might try report the rest in the
coming future.

Thanks,
Guillem


-- 
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/20130731162432.ga10...@gaara.hadrons.org

Re: Status of deb(5) format support in Debian

[Stefano Zacchiroli]

On Wed, Jul 31, 2013 at 06:24:32PM +0200, Guillem Jover wrote:
> Due to bug 718295, and in preparation to add non-gzip compression
> support for control.tar, I've tried to get an accurate view of the
> current deb(5) format support in software present in Debian. The
> resulting table looks pretty bad:
> 
>

So, about the following passage on that page:

> The current support seems quite bleak, and part of the blame goes to
> dpkg for not providing better interfaces for others to use, hopefully
> that will be remedied soon.

Can you expand on the planned remedy and in how "soon" it might arrive?

I'm myself guilty of having implemented, back in 2007, python-debian's
support to manipulate .deb files: the debian.debfile module. It is yet
another Python implementation of deb(5), because back in the days there
was no libdpkg* libraries I could wrap around (IIRC).

These days debian.debfile is lagging in compression formats support, as
your table properly shows. (BTW, thanks for the bug reports!) That said,
I'm not particularly keen of racing in features with dpkg/deb(5). I'd
rather throw away the alternative Python implementation all together,
and provide a Python wrapper around libdpkg*. But libdpkg-dev is still a
static only library and comes with scary warnings about its API
stability.

Given the number of tools/libraries in need of fixing, this might be the
good moment to rather ask them to migrate to some libdpkg* API instead.

Thanks in advance for your advice,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Missing makefile

[Jerry Stuckle]

On 7/31/2013 11:09 AM, Chris Bannister wrote:

On Wed, Jul 31, 2013 at 10:53:33AM -0400, Jerry Stuckle wrote:


And compiling kernel modules is off-topic for debian-user.  It
should, however, be on-topic here.


Correct, but you are more likely to be directed to debian-mentors. Try
there.




Chris,

I looked at that list first, but it seems to be more for how to create 
packages.


In this case I think it's a bug in one of the packages.  Note that I am 
not directly calling 
/usr/src/linux-headers-3.2.0-4-common/scripts/Makefile.build - that's 
part of the make process.


That file is trying to call 
/usr/src/linux-headers-3.2.0-4-common/scripts/basic/Makefile, which 
doesn't exist.


The problem is I'm not sure which package(s) contain these files (and 
don't know how to check).  But obviously a make file in a package should 
not be calling another makefile unless it either contains the second 
makefile, or depends on the package which does.



--
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/51f9464d.9080...@attglobal.net

Re: LXDE is dead in Debian?

[Mateusz Łukasik]

On 31.07.2013 at 11:17 Paul Wise  wrote:


LXDE upstream is merging with RazorQt upstream (also in Debian) so
there doesn't seem much point in adopting the LXDE GTK packages in
Debian right now. Once the upstream situation is sorted out they may
either get removed or updated, depending on the name of the project
created from the merge of the two projects.

http://blog.lxde.org/?p=1046



But the developed version pcmanfm-qt still needs gtk version libfm.

On 31.07.2013 at 11:23 Jonas Smedegaard  wrote:

How about the (seemingly to me) less intrusive option of joining the
"Debian LXDE Maintainers" team?


If it possible I would like join this team.


--
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/op.w02581l1ifijsr@laptop

Re: Requesting DDs who want to help greet new contributors

[Paul Wise]

I already do similar stuff but without the benefit of the tool you are
working on, just based on mailing list mails from folks asking how to
get involved or what I remember of folks activities. I might be
interested to get more involved here but that would probably need to
be later in the year.

-- 
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/caktje6gk3uzqcifpxd+o7mjqanyy9sfrfsvc2snqcoypm1p...@mail.gmail.com

Re: Missing makefile

[Adam D. Barratt]

On Wed, 2013-07-31 at 10:53 -0400, Jerry Stuckle wrote:
> And compiling kernel modules is off-topic for debian-user.  It should, 
> however, be on-topic here.

Not really, although I realise the longer description on
https://lists.debian.org/debian-devel/ could lead you to that
conclusion. As the short description better indicates, debian-devel is
focused on the development of the distribution, rather than development
on or using it.

Regards,

Adam


-- 
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/1375295952.15301.14.ca...@jacala.jungle.funky-badger.org

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

[Faheem Mitha]

Hi Andreas,

Thank you for your kind message, and for your interest.

On Tue, 30 Jul 2013 11:06:38 +0200, Andreas Tille  wrote:
> 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.

I also exchanged some emails with Debian-Med developers (including
yourself) in January regarding MEME. Additionally, I wrote on June 7th
asking if the project wanted any help with the ggplot2 package, which
was out of date, and asking to be added to the Project Member
List. (I'm faheem-guest on alioth.) I did not get a reply to this
message. I'm a little puzzled why ggplot2 is being packaged by Debian
Med. It is a general purpose R graphing package.

I certainly have no objection to my package being in
Debian. Regardless of whether Debian Med considers it worthy of
inclusion, I'd certainly appreciate any feedback on the package from
people who probably know far more about such things than I do.

I'm in the process of reworking my repos so I can make it public. When
I have done so I'll post the repos location to Debian Med, and then
you (the Debian Med developers) can decide if you have any interest in
the software.

In the meantime, I'd still appreciate feedback on the general issues I
originally posted about in this thread.

>> 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?

I'm not sure what you mean.

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

Thank you again for your interest.

  Regards, Faheem

> Kind regards
>
> Andreas.
>
> [1] http://debian-med.alioth.debian.org/tasks/bio 
>


-- 
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/slrnkvimju.q2h.fah...@chrestomanci.home.earth

Re: Missing makefile

[Jerry Stuckle]

On 7/31/2013 2:39 PM, Adam D. Barratt wrote:

On Wed, 2013-07-31 at 10:53 -0400, Jerry Stuckle wrote:

And compiling kernel modules is off-topic for debian-user.  It should,
however, be on-topic here.


Not really, although I realise the longer description on
https://lists.debian.org/debian-devel/ could lead you to that
conclusion. As the short description better indicates, debian-devel is
focused on the development of the distribution, rather than development
on or using it.

Regards,

Adam




Adam,

Thanks for your reply.

OK, I can understand that.  However, then where do you get support for 
building modules with tools supplied by Debian - especially when there 
seems to be a bug in one of those tools, but can't figure out which tool 
to file a bug report against (or if it even is a bug - which I think it is)?


The mentors list doesn't seem to be appropriate, either.


--
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/51f95fe0.5010...@attglobal.net

Re: Missing makefile

[Ben Hutchings]

On Wed, 2013-07-31 at 15:05 -0400, Jerry Stuckle wrote:
> On 7/31/2013 2:39 PM, Adam D. Barratt wrote:
> > On Wed, 2013-07-31 at 10:53 -0400, Jerry Stuckle wrote:
> >> And compiling kernel modules is off-topic for debian-user.  It should,
> >> however, be on-topic here.
> >
> > Not really, although I realise the longer description on
> > https://lists.debian.org/debian-devel/ could lead you to that
> > conclusion. As the short description better indicates, debian-devel is
> > focused on the development of the distribution, rather than development
> > on or using it.
> >
> > Regards,
> >
> > Adam
> >
> >
> 
> Adam,
> 
> Thanks for your reply.
> 
> OK, I can understand that.  However, then where do you get support for 
> building modules with tools supplied by Debian - especially when there 
> seems to be a bug in one of those tools, but can't figure out which tool 
> to file a bug report against (or if it even is a bug - which I think it is)?
> 
> The mentors list doesn't seem to be appropriate, either.

It's not a bug in our packages, otherwise we would have hundreds of bug
reports of this already.

(My guess: you haven't installed the packages properly, for example you
made /usr/src a symlink.)

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


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

Re: Missing makefile

[Jerry Stuckle]

On 7/31/2013 3:46 PM, Ben Hutchings wrote:

On Wed, 2013-07-31 at 15:05 -0400, Jerry Stuckle wrote:

On 7/31/2013 2:39 PM, Adam D. Barratt wrote:

On Wed, 2013-07-31 at 10:53 -0400, Jerry Stuckle wrote:

And compiling kernel modules is off-topic for debian-user.  It should,
however, be on-topic here.


Not really, although I realise the longer description on
https://lists.debian.org/debian-devel/ could lead you to that
conclusion. As the short description better indicates, debian-devel is
focused on the development of the distribution, rather than development
on or using it.

Regards,

Adam




Adam,

Thanks for your reply.

OK, I can understand that.  However, then where do you get support for
building modules with tools supplied by Debian - especially when there
seems to be a bug in one of those tools, but can't figure out which tool
to file a bug report against (or if it even is a bug - which I think it is)?

The mentors list doesn't seem to be appropriate, either.


It's not a bug in our packages, otherwise we would have hundreds of bug
reports of this already.

(My guess: you haven't installed the packages properly, for example you
made /usr/src a symlink.)

Ben.



Ben,

I'm not sure what would have been wrong.  I haven't made any additional 
symlinks other than some for Apache configuration files, etc. - nothing 
like /usr/src.


Additionally, there was one bug report (I don't have the number off 
hand) which was closed with no apparent (to me, at least) solution. 
Others have also experienced this problem - but again, I haven't been 
able to discern a resolution for any of these (other than one which was 
a change to the user's makefile).


Anyway, I've posted in debian-users; I'll see what goes there.


--
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/51f96e19.6020...@attglobal.net

Re: Missing makefile

[Jerry Stuckle]

On 7/31/2013 3:46 PM, Ben Hutchings wrote:

On Wed, 2013-07-31 at 15:05 -0400, Jerry Stuckle wrote:

On 7/31/2013 2:39 PM, Adam D. Barratt wrote:

On Wed, 2013-07-31 at 10:53 -0400, Jerry Stuckle wrote:

And compiling kernel modules is off-topic for debian-user.  It should,
however, be on-topic here.


Not really, although I realise the longer description on
https://lists.debian.org/debian-devel/ could lead you to that
conclusion. As the short description better indicates, debian-devel is
focused on the development of the distribution, rather than development
on or using it.

Regards,

Adam




Adam,

Thanks for your reply.

OK, I can understand that.  However, then where do you get support for
building modules with tools supplied by Debian - especially when there
seems to be a bug in one of those tools, but can't figure out which tool
to file a bug report against (or if it even is a bug - which I think it is)?

The mentors list doesn't seem to be appropriate, either.


It's not a bug in our packages, otherwise we would have hundreds of bug
reports of this already.

(My guess: you haven't installed the packages properly, for example you
made /usr/src a symlink.)

Ben.



Ben,

I should also add - I doubt there are many people trying to create new 
kernel modules for Debian which aren't being merged into the upstream 
kernel, so I'm not sure why there would be "hundreds of bug reports".


Jerry


--
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/51f96ee7.8060...@attglobal.net

Re: Status of deb(5) format support in Debian

[David Kalnischkies]

On Wed, Jul 31, 2013 at 6:56 PM, Stefano Zacchiroli  wrote:
> On Wed, Jul 31, 2013 at 06:24:32PM +0200, Guillem Jover wrote:
>> Due to bug 718295, and in preparation to add non-gzip compression
>> support for control.tar, I've tried to get an accurate view of the
>> current deb(5) format support in software present in Debian. The
>> resulting table looks pretty bad:
>>
>>
>
> So, about the following passage on that page:
>
>> The current support seems quite bleak, and part of the blame goes to
>> dpkg for not providing better interfaces for others to use, hopefully
>> that will be remedied soon.
>
> Can you expand on the planned remedy and in how "soon" it might arrive?

That I would be interested in as well.

APT (or better: libapt-inst) is containing this tar stuff for two reasons:
1) apt-extracttemplates – which is a hack/layer violation as that is really
   something a dpkg-* (or debconf) tool should do but its still here…
   [Its on the roadmap for dpkg since at least 1.15.X (according to wiki).]
2) apt-ftparchive – used to generate Contents files (which seem to be
   slightly different from the ones dak is generating for all the cool kids).

So, 2) we can ignore for now, 1) would be nice to fix as basically everyone
has this one installed (and hence everyone has 2) installed), but "maybe" I
will leave that bugreport open for a while just to see what happens…


I know that everyone dreams about a stable API for a library, but I believe
that even an unstable library at this point is way better than the status
quo of having other layers like libapt (which is a proof that even if being
 unstable is a pain, the alternative would be worse – and that's a freaking
 C++ "library" …) providing makeshift replacements.

There are e.g. a bunch of dpkg-style version-comparison implementations in
Debian which should really just be a single one under the control of dpkg and
that might be "just" ~5 because libapt includes one, so it could be misused
by others (anyone remember the kernel depending on libapt-pkg-perl?).


Best regards

David Kalnischkies

P.S.: Could the table be enhanced with a description for the table headers?
I have no idea what an "ar slash" might be, and not really what LFS means
as the format has no support for >10 character filesizes as far as I know.


--
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/CAAZ6_fAaY2_L+mfbTtUU2T=wgl4whwbymh1ocjufyeztbek...@mail.gmail.com

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

[Andreas Tille]

Hi Faheem,

On Wed, Jul 31, 2013 at 06:41:59PM +, Faheem Mitha wrote:
> >
> > 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.
> 
> I also exchanged some emails with Debian-Med developers (including
> yourself) in January regarding MEME.

Ahh, sorry for my bad memory - but since you are saying this I remember
for sure the MEME discussion.

> Additionally, I wrote on June 7th
> asking if the project wanted any help with the ggplot2 package, which
> was out of date, and asking to be added to the Project Member
> List. (I'm faheem-guest on alioth.) I did not get a reply to this
> message.

That's a bit sad and definitely not the usual way we are dealing with
requests.  The savest way is to use the alioth interface to ask for
membership but at least now you are member of Debian Med

> I'm a little puzzled why ggplot2 is being packaged by Debian
> Med. It is a general purpose R graphing package.

If nobody else is packaging preconditions we are simply doing it
in our own Vcs.  And this is just a precondition:

$ apt-cache rdepends r-cran-ggplot2
r-cran-ggplot2
Reverse Depends:
  r-bioc-cummerbund

And you are right - it is not uploaded yet which is most probably
due to the fact that Charles is quite occupied since some time.
What I currently can see from the status in Git the preparation for
the latest upstream is done but the Build-Depends r-cran-scales is
just missing.  It is waiting in

   http://ftp-master.debian.org/new.html

since one month when Charles has uploaded this package.  So we can hope
that it will be accepted soonish so r-cran-ggplot2 will follow.

> I certainly have no objection to my package being in
> Debian. Regardless of whether Debian Med considers it worthy of
> inclusion, I'd certainly appreciate any feedback on the package from
> people who probably know far more about such things than I do.

OK.

> I'm in the process of reworking my repos so I can make it public. When
> I have done so I'll post the repos location to Debian Med, and then
> you (the Debian Med developers) can decide if you have any interest in
> the software.

We can also work on preconditions for your package - you mentioned that
there are some R packages missing.

> In the meantime, I'd still appreciate feedback on the general issues I
> originally posted about in this thread.

I think you mean the way you should create the private package?  I'd
recommend applying the very same rules as for any other Debian package.
You are welcome to do the development in Debian Med Git / SVN at your
preference (as I said you now have commit permissions).  The rules
are explained in our group policy[1].

> >> 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?
> 
> I'm not sure what you mean.

You wrote: "Unfortunately the R packages I use are not all in Debian" -
so lets try to get those packages you need in.  As you see we are taking
also quite general packages if they are preconditions.  The rationale is
simply that there is no such thing like an R packaging team (which is a
shame but we need to cope with this).
 
> > Looking forward to help you solving your packaging problem in Debian Med
> > team.
> 
> Thank you again for your interest.

:-)

BTW, please do us a favour and if you somehow feel ignored (for instance
by failing to accept your alioth membership request) please ping again.
That's usually not the way we deal with newcomers and it should not
happen again - but pinging somehow helps specifically it seems that it
were in a quite busy time with release preparations, Debian Med sprint
etc.  So sorry if something did not went as smooth as you would have
expected.

Kind regards

Andreas.

[1] http://debian-med.alioth.debian.org/docs/policy.html 

-- 
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/20130731203437.gb20...@an3as.eu

Re: On accepting pre-generated doc from upstream

[Lisandro Damián Nicanor Pérez Meyer]

On Tuesday 23 July 2013 14:05:41 Goswin von Brederlow wrote:
> On Thu, Jul 18, 2013 at 12:07:59PM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > On Thursday 18 July 2013 14:45:38 Goswin von Brederlow wrote:
> > [snip]
> > 
> > > - Option 3:
> > > 
> > > (Note: I'm assuming you are generating API docs directly fromt the
> > > source files. So the input for the doc building is not seperable from
> > > the actual source.)
> > > 
> > > For packages 1 and 2 build without docs but also build a
> > > package{1,2}-src package.
> > > 
> > > Have another source package{1,2}-doc that Build-Depends:
> > > tools-for-doc-building, package{1,2}-src and sets Build-Using:
> > > package{1,2}-src. This would then generate the API docs from the
> > > source files using the tools and sources from the package{1,2} builds.
> > > On update you would usualy only need to bump the version for this
> > > package.
> > 
> > Pino also suggested me this approach. I looked into it and also at how the
> > original build system builds the doc. Saddly, I think the amount of time I
> > will need to put in this is simply insane.
> > 
> > I think I'll just drop the documentation.
> 
> Would it be so much time to
> 
> 1) build-arch / binary-arch build without docs
> 2) Build-Depends-Indep: depend on the binary-arch packages
> 3) build-indep / binary-indep build with docs
> 
> On each new release you would then need to
> 
> 1) debuild -us -uc -b   package1
> 2) debuild -us -uc -b   package2
> 2) dpkg -i debs
> 3) debuild  package1
> 4) debuild  package2
> 5) upload
> 
> That doesn't seem like too much of a problem.

It is, that's what I'm currentyly doing. But in this way the resulting doc 
will not have cross-linking between them, which is a needed feature after all.

It woiuld need to B-D on all the previous doc and build the doc twice to do 
that. For all 14+ packages.

-- 
perezmeyer: Gus no tiene inet :-(
PabloOdorico: oh
perezmeyer: te mando una copia de lo que hagamos esta noche
PabloOdorico: de ultima mandame un loro del parque con una flash en la pata ;)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

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

[Peter Samuelson]

> On Wed, 2013-07-31 at 01:30 +0100, Steve Langasek wrote:
> > That's correct.  If you want to talk to a loopback-only service,
> > you should be connecting to 'localhost', *not* to the hostname.

[Christoph Anton Mitterer]
> Well why not? Imagine that one server in a cluster serves a debian
> package repo (e.g. via http)...

That doesn't sound like a "loopback-only service" at all.


> - let the webserver listen as well on 127.0.1.1,... sure that works but
> it's rather ugly to make such special handling... and not all services
> are even able to bind to multiple addresses.

Special handling?  No, I'm pretty sure the default for all web servers
in Debian is to listen on INADDR_ANY.  That's not special handling at
all.  Special handling would be to listen on 11.22.33.44 and 127.0.0.1
specifically.


-- 
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/20130731214229.ga6...@p12n.org

Re: Missing makefile

[Wouter Verhelst]

On 31-07-13 22:09, Jerry Stuckle wrote:
> Ben,
> 
> I should also add - I doubt there are many people trying to create new
> kernel modules for Debian which aren't being merged into the upstream
> kernel,

There are plenty of out-of-tree modules; that isn't very special.

This should Just Work(TM), and does for most people.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/51f9886d.7030...@debian.org

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

[Charles Plessy]

Le Wed, Jul 31, 2013 at 10:34:37PM +0200, Andreas Tille a écrit :
> 
> On Wed, Jul 31, 2013 at 06:41:59PM +, Faheem Mitha wrote:
> 
> > I'm a little puzzled why ggplot2 is being packaged by Debian
> > Med. It is a general purpose R graphing package.
 
> What I currently can see from the status in Git the preparation for
> the latest upstream is done but the Build-Depends r-cran-scales is
> just missing.  It is waiting in
> 
>http://ftp-master.debian.org/new.html
> 
> since one month when Charles has uploaded this package.  So we can hope
> that it will be accepted soonish so r-cran-ggplot2 will follow.

Dear Faheem,

I received multiple enquiries about ggplot2, and I am very sorry that I got
confused and forgot to answer to yours.

I am also very sorry for the state of this package.  When preparing the update,
I overlooked some of the new pakcages that need to be introduced, which added a
long waiting period to the process.  When they will be accepted in Debian,
ggplot2 will be updated a soon as possile.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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/20130731225318.gb11...@falafel.plessy.net

Bug#718455: ITP: hypirion-io-clojure -- I/O redirection, signal handling, and console utilities

[Eugenio Cano-Manuel Mendoza]

Package: wnpp
Severity: wishlist
Owner: "Eugenio Cano-Manuel Mendoza" 

* Package name: hypirion-io-clojure
  Version : 0.3.1
  Upstream Author : Jean Niklas L'orange 
* URL : http://www.hypirion.com/
* License : EPL-1.0
  Programming Lang: Java, Clojure
  Description : I/O redirection, signal handling, and console utilities

hypirion-io provides a set of features wrapped in Java classes:
   *Pipe: Establish a link between InputStream and OutputStream, also
   supports Reader and Writer.
   *SignalInterceptor: Intercept POSIX signals before they are sent to
   their signal handlers.
   *RevivableInputStream: Allow canceling blocking read calls to
   streams without closing them.
   *ConsoleUtils: Set on/off echoing in the console.
Common usage of this library includes: asynchronous zipping of data
from two data sources, redirecting output and input to subprocesses
and loggers, and send messages to threads.


-- 
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/20130731233316.10351.95437.reportbug@localhost

Bug#718461: ITP: cgrand-regex-clojure -- Composable regexes for Clojure

[Eugenio Cano-Manuel Mendoza]

Package: wnpp
Severity: wishlist
Owner: "Eugenio Cano-Manuel Mendoza" 

* Package name: cgrand-regex-clojure
  Version : 1.1.0
  Upstream Author : Christophe Grand 
* URL : https://github.com/cgrand/regex
* License : EPL-1.0
  Programming Lang: Java, Clojure
  Description : Composable regexes for Clojure

Allows to use regexes or parts of them. Also provides support for named
groups. Its syntax can be found at:
https://github.com/cgrand/regex/blob/master/syntax.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/20130801010129.2162.25754.reportbug@localhost

Bug#718464: ITP: tools-cli-clojure -- command line argument parser for Clojure

[Eugenio Cano-Manuel Mendoza]

Package: wnpp
Severity: wishlist
Owner: "Eugenio Cano-Manuel Mendoza" 

* Package name: tools-cli-clojure
  Version : 0.2.2
  Upstream Author : Gareth Jones 
* URL : https://github.com/clojure/tools.cli
* License : EPL-1.0
  Programming Lang: Java, Clojure
  Description : command line argument parser for Clojure

tools.cli is a command-line argument parser for Clojure. It currently
supports:
 *Multiple switches per option.
 *Option description.
 *Default values for options.
 *Boolean flags.


-- 
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/20130801024705.22333.37087.reportbug@localhost

Re: Requesting DDs who want to help greet new contributors

[Asheesh Laroia]

On Wed, 31 Jul 2013, Paul Wise wrote:

I already do similar stuff but without the benefit of the tool you are 
working on, just based on mailing list mails from folks asking how to 
get involved or what I remember of folks activities. I might be 
interested to get more involved here but that would probably need to be 
later in the year.


*nod*!

Hopefully as the team gets up and documents the tools and process, and 
refines the goals, and so on, you'll find it interesting to join!


-- 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.1308010209030.4...@rose.makesad.us

Re: Requesting DDs who want to help greet new contributors

[Asheesh Laroia]

On Wed, 31 Jul 2013, Nicolas Guilbert wrote:


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".


I think I agree with this clarification. Thank you for that!

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 :)


(-:

I agree that mentoring is often very effective. One of the key elements I 
find missing in mentoring, however, is the work to establish a 
relationship between mentor and mentee that leads to them having 
meaningful discussions rather than not asking each other questions.


As for your "citation pending" -- clarifying this sort of thing is one of 
the goals of this project. One plan that Mako and I came up with that 
since at first, we may not have enough bandwidth to ping everyone, we can 
see if those who we *do* manage to reach become more active in the project 
than the people we do get around to pinging.


I'm excited by the warm reception to the ideas here! I'll work with David 
Lu on fixing more our bugs, and y'all will hear more from us soon. (And if 
that's not soon enough, 
http://lists.openhatch.org/mailman/listinfo/greenhouse + 
https://github.com/openhatch/oh-greenhouse + #openhatch on freenode!)


-- 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.1308010211240.4...@rose.makesad.us