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

[Manoj Srivastava]

On Tue, Dec 29 2009, Russ Allbery wrote:

> I think the way forward for Git-maintained packages is the 3.0 (git)
> format, but changed to ship a bundle.  That way, relevant branches and
> history can be included, and Git is fairly space-efficient so the
> additional cost of doing so isn't that bad.

As far as I can tell, git-bundle is not submodule friendly. I
 would appreciate 3.0 (git)  supporting submodules; and I'd be willing to
 write code for that (once I am done relocating, that is)

manoj

-- 
With your bare hands?!?
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

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

[Russ Allbery]

Manoj Srivastava  writes:
> On Tue, Dec 29 2009, Russ Allbery wrote:

>> I think the way forward for Git-maintained packages is the 3.0 (git)
>> format, but changed to ship a bundle.  That way, relevant branches and
>> history can be included, and Git is fairly space-efficient so the
>> additional cost of doing so isn't that bad.

> As far as I can tell, git-bundle is not submodule friendly. I
>  would appreciate 3.0 (git)  supporting submodules; and I'd be willing to
>  write code for that (once I am done relocating, that is)

I think a bundle corresponds to a module, roughly, yes?  If so, then one
could presumably write some light infrastructure around multiple bundles
to recreate a source tree with submodules.

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


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

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

[Mike Hommey]

On Mon, Dec 28, 2009 at 10:40:34PM -0800, Russ Allbery wrote:
> Raphael Geissert  writes:
> 
> > 3.0 would be friendlier if it would only *not* automatically apply the
> > patches when extracting the source. But then there's not much point for
> > dpkg to know about patches.
> 
> I do think the problem of not having buildable source after dpkg-source -x
> is worth solving, and for a while most everyone was using quilt, so
> supporting quilt natively was a solid idea.  I've switched over to Git
> completely now, though, and while I was a bit dubious when I talked with
> people about it two years ago at DebConf, I can see now where patches
> aren't the most natural way to think about changes in Git and maintaining
> patches is more of a hassle.
> 
> I think the way forward for Git-maintained packages is the 3.0 (git)
> format, but changed to ship a bundle.  That way, relevant branches and
> history can be included, and Git is fairly space-efficient so the
> additional cost of doing so isn't that bad.
> 
> That does have the drawback of being tied to one particular version
> control mechanism again, though.  I'm wondering if possibly something
> using the fast-import format that both bzr and Git support might work,
> although I suspect that would lose a lot of the compression benefits.

How about designing a "patch" format that would handle merges, and a
"series" format that would handle branches ?

Mike


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

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

[Tollef Fog Heen]

]] Joey Hess 

| I think you should be using a dedicated source format for your patch
| system, preferably one that preserves the pre-patched source on unpack
| invariant. Either the existing 3.0 (custom), or a new 3.0 subformat.

Note that those won't be accepted into the archive (at least not without
patches to dak).  While I'm not an ftp-master, I would be surprised if
they were happy to take patches for a 3.0 (simple-patchsys).  Quilt
isn't that complicated to use and should just replace simple-patchsys,
dbs and similar patch systems.

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

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

[Gabor Gombas]

On Tue, Dec 29, 2009 at 08:46:09AM +0100, Vincent Bernat wrote:

> And BTW, this is exactly what hostname -f does. It does not read 
> /etc/hostname.

Nothing should read /etc/hostname except /etc/init.d/hostname.sh during
boot. Everything else should use either uname(2) or gethostname(3)
(which in turn calls uname() internally).

For example, on NFSROOT setups /etc/hostname usually does not exist
to prevent the host name received from DHCP being overwritten.

Gabor

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


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

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

[Michael Tautschnig]

> Hi,
> 
> there are several tools that generate C source code that is later
> complied in object code, e.g. yacc, lex or valac.  automake defaults to
> distribute these built intermediate files, so they are usually not
> regenerated during a build.
> 

[...]

Why do you restrict this question to generated C code? configure, Makefile.in
and some others are generated as well. Wouldn't it be consistent to talk about
all these files?

Best,
Michael



pgpS9Nk9lHOAO.pgp
Description: PGP signature

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

[Raphael Hertzog]

Hi,

On Mon, 28 Dec 2009, Norbert Preining wrote:
> $ git-buildpackage -us -uc -rfakeroot -S
[...]
> nothing to commit (working directory clean)
> $ 
> 
> So please tell me *what* has changed?

That's because you're doing a source only build. With a binary build,
patches would have been applied.

In the specific case of a source only build, you're right.

Cheers,
-- 
Raphaël Hertzog


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

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

[Serafeim Zanikolas]

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

To control whether automake regenerates auto-generated files, have a look at
AM_MAINTAINER_MODE [0]

I ask my upstreams to not distribute auto-generated files. Failing that, I
make sure that debian/rules rebuilds everything from scratch, in a way that
all upstream files are restored after running the clean target.

[0] http://www.gnu.org/software/hello/manual/automake/maintainer_002dmode.html

-- 
debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp


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

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

[Norbert Preining]

On Di, 29 Dez 2009, Raphael Hertzog wrote:
> That's because you're doing a source only build. With a binary build,
> patches would have been applied.

I always build my packages in a clean chroot and not in my life system.

Best wishes

Norbert

Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria   Debian TeX Task Force
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

MANKINHOLES (pl.n.)
The small holes in a loaf of bread which give rise to the momentary
suspicion that something may have made its home within.
--- Douglas Adams, The Meaning of Liff


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

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

[Adam Borowski]

On Tue, Dec 29, 2009 at 12:21:45AM +, Sam Morris wrote:
> What would a hypothetical host that only had IPv6 connectivity do?

It's not "hypothetical".  IPv4 sucks so badly compared to IPv6 that once you
switch your internal hosts to v6-only, you don't want to go back.  While
getting IPv6 connectivity in the first place may be tricky, when you have
it, you can forget about all NAT woes, having to run a series of VPNs
between locations just to get to hosts inside, and so on.
The sooner IPv4 dies, the better.

Brain-dead hostname -f remains one of the few annoyances in such a setup. 
At least in etch, you do need a fake IPv4 stub or it will die messily.
It appears that at least this problem has been fixed in unstable, I haven't
tested the new version but if it does work, big thanks, guys!

> We certainly don't have a line analogous to the '127.0.1.1' hack in /etc/
> hosts for ipv6, and I'm not even sure what such a line would look like,
> since ::1 has a /128 netmask.

Aye, this needs to be fixed for machines with intermittent connectivity.

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


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

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

[Jeremiah Foster]

On Dec 29, 2009, at 8:46, Vincent Bernat wrote:

> OoO En ce  doux début de matinée du mardi 29  décembre 2009, vers 08:34,
> je disais:
> 
>>> Details in . I 
>>> do wonder, however, why the system hostname has to appear in /etc/hosts 
>>> at all? Programs that want to find it out can read /etc/hostname 
>>> directly, after all. And wtf is 'localdomain' for, anyway?
> 
>> A common way to get hostname is to request node name through uname, then
>> asks  for a resolution  of this  name. If  the name  does not  appear in
>> /etc/hosts, this will lead to a DNS resolution and without network, this
>> can take a long time.
> 
> And BTW, this is exactly what hostname -f does. It does not read 
> /etc/hostname.

On one of my machines apticron uses a call to hostname -f, which fails, while 
uname -n succeeds. 

Perhaps it should be a bug to use hostname -f since it unreliable?

Jeremiah

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

Bug#562942: ITP: liblog4ada -- An Ada library for flexible logging

[xavier . grave]

Package: wnpp
Severity: wishlist
Owner: xavier.gr...@ipno.in2p3.fr


* Package name: liblog4ada
  Version : 1.0
  Upstream Author : Xavier Grave 
* URL : http://www.ada-france.org:8081 branch org.log4Ada
* License : GPL
  Programming Lang: Ada
  Description : An Ada library for flexible logging

 Log4Ada is a library written in the intend to ease logging in applications
 written in Ada. For more information about the logging scheme developped in
 this library see the log4j project : http://logging.apache.org/log4j/docs/



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

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

[Vincent Lefevre]

On 2009-12-28 20:56:03 -0800, Steve Langasek wrote:
> On Tue, Dec 29, 2009 at 01:47:40AM +0100, Vincent Lefevre wrote:
> > > As for mail, we already appear to have an /etc/mailname file for MTAs and 
> > > MUAs to use for finding out the 'canonical' name of the host for message-
> > > IDs and the like.
> 
> > /etc/mailname doesn't seem to be specified by POSIX
> 
> Nope, it's specified in Debian policy (11.6).
> 
> > , so that I doubt that all mail software uses it in practice (Mutt doesn't
> > seem to use it...
> 
> That would be a bug, then.

Not all software is written for Debian. So, why?

Even if Debian has its own patches to match its policy, end users
are still allowed to compile software from upstream (this is what
I do for Mutt, because I have my own patches), and they expect
such software to work. So, if the admin of a Debian machine doesn't
configure a FQDN (so that the POSIX way to get it doesn't work)
just because there's a /etc/mailname already specifying the FQDN,
I won't be pleased.

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


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

Re: bug #561324: asking questions in postinst

[Lionel Elie Mamane]

On Mon, Dec 28, 2009 at 07:44:56PM +0100, Reinier Haasjes wrote:

>> Why? Is it really required to have _all_ questions in the postinst?

> No, not all. There are 4 questions asked.
> 1) brokers list, the list is received by the package-binary and the user
> selects te broker he wants to use. For this I can use a dns-query (type
> TXT) but dig and host are both not essential packages, so this still has
> to go to the postinst.

Well, this could be solved by a pre-depends on dnsutils |
bind9-host. Pre-depends are often frowned upon, what do others think
of this for this case?

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

-- 
Lionel


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

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

[Vincent Lefevre]

On 2009-12-29 14:09:49 +0100, Jeremiah Foster wrote:
> On one of my machines apticron uses a call to hostname -f, which
> fails, while uname -n succeeds.

"uname -n" doesn't necessarily return the FQDN.

xvii% uname -n
xvii
xvii% hostname
xvii
xvii% hostname -f
xvii.vinc17.org
xvii% cat /etc/hostname 
xvii

Note in the hostname(1) man page:

  /etc/hostname This file should only contain the hostname and not the
  full FQDN.

> Perhaps it should be a bug to use hostname -f since it unreliable?

When the machine is correctly configured (i.e. really has a FQDN),
"hostname -f" is reliable. But note that this is Debian-specific.

FYI, here's how one can get the FQDN in Perl (gethostbyname is no
longer in POSIX, but it currently works in practice... or perhaps
"hostname" has something more reliable?):

#!/usr/bin/env perl

use strict;
use POSIX;

my $nodename = (POSIX::uname)[1];
print "Nodename: $nodename\n";
print "FQDN: ", (gethostbyname $nodename)[0], "\n";

(You would do the same thing in other languages: uname, then
gethostbyname.)

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


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

Re: bug #561324: asking questions in postinst

[Patrick Schoenfeld]

Hi,

On Tue, Dec 29, 2009 at 02:38:46PM +0100, Lionel Elie Mamane wrote:
> On Mon, Dec 28, 2009 at 07:44:56PM +0100, Reinier Haasjes wrote:
> 
> >> Why? Is it really required to have _all_ questions in the postinst?
> 
> > No, not all. There are 4 questions asked.
> > 1) brokers list, the list is received by the package-binary and the user
> > selects te broker he wants to use. For this I can use a dns-query (type
> > TXT) but dig and host are both not essential packages, so this still has
> > to go to the postinst.
> 
> Well, this could be solved by a pre-depends on dnsutils |
> bind9-host. Pre-depends are often frowned upon, what do others think
> of this for this case?

I've discussed this issue here with Martin Zobel-Helas and
he and I agree that in this limited case it could be a good solution:

- It solves the problem in question (without a code duplication)
- A pre-depend loop is highely unlikely. After all we should slap
  anybody pre-depending on aiccu very hard.
- A Pre-Depend on utilities that are likely to be installed anyway
  seems like a not so great risk to avoid it.

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

Would work, would be robust, but basically it would mean to have
basically the very same code (except some conditionals) two times
in two different places. Not a big drawback, but still worth a notice.

Best Regards,
Patrick


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

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

[Joachim Wiedorn]

Hello,

Joachim Wiedorn  wrote:

> The only missing item for me is: there are no simple command to unapply
> the patches with dpkg-buildpackages (or debuild). For example: 
> 
>debuild unapply

Even though there are some newer Mails this question seems to not be
solved.

Is it true, that I need an installed quilt to unapply the patches? 
Or can I do it with dpkg-buildpackage or dpkg-source?

Fondest regards,
 Joachim Wiedorn



signature.asc
Description: PGP signature

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

[Julien Cristau]

On Mon, Dec 28, 2009 at 12:29:48 +0100, Joerg Jaspert wrote:

> It would have been MORE than easy to have bz2 support in 1.0. There is
> absolutely no reason why it needs a 3.0 just for a different compression.
> But that wasnt wanted.

By whom?  dpkg maintainers, archive admins, package maintainers?
tar.bz2 support is the only reason I see for considering 3.0 at this
point…

Cheers,
Julien


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

Re: bug #561324: asking questions in postinst

[Martin Zobel-Helas]

Hi, 

On Tue Dec 29, 2009 at 15:13:54 +0100, Patrick Schoenfeld wrote:
> Hi,
> 
> On Tue, Dec 29, 2009 at 02:38:46PM +0100, Lionel Elie Mamane wrote:
> > On Mon, Dec 28, 2009 at 07:44:56PM +0100, Reinier Haasjes wrote:
> > 
> > >> Why? Is it really required to have _all_ questions in the postinst?
> > 
> > > No, not all. There are 4 questions asked.
> > > 1) brokers list, the list is received by the package-binary and the user
> > > selects te broker he wants to use. For this I can use a dns-query (type
> > > TXT) but dig and host are both not essential packages, so this still has
> > > to go to the postinst.
> > 
> > Well, this could be solved by a pre-depends on dnsutils |
> > bind9-host. Pre-depends are often frowned upon, what do others think
> > of this for this case?
> 
> I've discussed this issue here with Martin Zobel-Helas and
> he and I agree that in this limited case it could be a good solution:
> 
> - It solves the problem in question (without a code duplication)
> - A pre-depend loop is highely unlikely. After all we should slap
>   anybody pre-depending on aiccu very hard.
> - A Pre-Depend on utilities that are likely to be installed anyway
>   seems like a not so great risk to avoid it.

Nevertheless there should be an extra thread on debian-de...@l.d.o that
announces the intend to add a Pre-Depends for this package.

Martin
-- 
 Martin Zobel-Helas   | Debian System Administrator
 Debian & GNU/Linux Developer   |   Debian Listmaster
 Public key http://zobel.ftbfs.de/5d64f870.asc   -   KeyID: 5D64 F870
 GPG Fingerprint:  5DB3 1301 375A A50F 07E7  302F 493E FB8E 5D64 F870


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

Re: Bug#562861: ITP: remmina-xfce -- XFCE applet for Remmina

[Cyril Brulebois]

Luca Falavigna  (28/12/2009):
>   Description : XFCE applet for Remmina
>   Remmina-XFCE is a XFCE applet for the Remmina application. This XFCE
>   desktop applet allows for easy-access of the Remmina main features.
>   Remmina-XFCE is also able to list all remote desktop files and makes
>   the connection easy.

It would be nice to have a vague idea of what Remmina is.

Mraw,
KiBi.


signature.asc
Description: Digital signature

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

[Peter Samuelson]

> On Mon, Dec 28, 2009 at 12:29:48 +0100, Joerg Jaspert wrote: It would
> > have been MORE than easy to have bz2 support in 1.0. There is
> > absolutely no reason why it needs a 3.0 just for a different
> > compression.  But that wasnt wanted.

[Julien Cristau]
> By whom?  dpkg maintainers, archive admins, package maintainers?
> tar.bz2 support is the only reason I see for considering 3.0 at this
> point…

Presumably dpkg maintainers.  I've long suspected that the main reason
they chose not to add tar.bz2 to format 1.0 is, if they did, a lot of
us would have no reason to want format 3.0.  Many packagers don't need
multiple tarballs or non-text files, and are quite happy to 'include
/usr/share/quilt/quilt.make' by hand.  We don't find it hard to extract
an NMU diff even if it wasn't posted to the bug as it should be.  It's
hard enough to convince us to want 3.0 even with tar.bz2 support.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


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

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

[Stefano Zacchiroli]

On Tue, Dec 29, 2009 at 10:04:19AM -0600, Peter Samuelson wrote:
> Presumably dpkg maintainers.  I've long suspected that the main reason
> they chose not to add tar.bz2 to format 1.0 is, if they did, a lot of
> us would have no reason to want format 3.0.  Many packagers don't need
> multiple tarballs or non-text files, and are quite happy to 'include
> /usr/share/quilt/quilt.make' by hand.  We don't find it hard to extract
> an NMU diff even if it wasn't posted to the bug as it should be.  It's
> hard enough to convince us to want 3.0 even with tar.bz2 support.

All this is getting a bit FUD-ish, can we please stop here?

Format 3.0 is more than .bz2 support. To me both the support of multiple
tarballs and that of binary files in diffs look like significant
improvements. Similarly, the knowledge of different patches by dpkg
itself sounds like the proper way of doing things, instead of encoding
individual patches several times by the means of nested tools, without
even a lingua franca layer shared by all patch systems (you know, for
instance, how annoying is to have to support different patch systems in
patch-tracker.d.o?).

All in all, the complaints I've been reading in this thread are about
suboptimal support in our _present_ toolchain for the new format. Well,
that's quite normal: the format is young. Maybe the impact analysis has
not been as thorough as it could have been, but the preliminary FTBFS
analysis was quite good in fact, and has minimized the introduction of
RC bugs due to the introduced new features.  Possibly most reported
annoyances could have been avoided *if* the people who are complaining
now had tested 3.0-support before it hit unstable (packages have been
RFC-ed quite in advance and have been made available via experimental).

Every remaining misbehaviors are bugs, of course, but not that serious
(as far as I've read in this thread): report them, provide patches, and
be happy. That would be terribly more useful than trying hard to make
everybody believe 3.0 is unnecessary and/or seriously-buggy, which IME
it is not, as confirmed by the current acceptance rate [1].

Finally, nobody is forced to use it: if you don't like it, just avoid
using it.

Cheers.

[1] http://upsilon.cc/~zack/stuff/dpkg-v3/

PS the post of course is not aimed at you, Peter, in particular

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: bug #561324: asking questions in postinst

[Josselin Mouette]

Le mardi 29 décembre 2009 à 14:38 +0100, Lionel Elie Mamane a écrit :
> Well, this could be solved by a pre-depends on dnsutils |
> bind9-host. Pre-depends are often frowned upon, what do others think
> of this for this case?

It is utterly and absolutely useless, since config scripts are executed
before pre-depends are installed.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling



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

Re: bug #561324: asking questions in postinst

[Patrick Schoenfeld]

On Tue, Dec 29, 2009 at 05:32:29PM +0100, Josselin Mouette wrote:
> Le mardi 29 décembre 2009 à 14:38 +0100, Lionel Elie Mamane a écrit :
> > Well, this could be solved by a pre-depends on dnsutils |
> > bind9-host. Pre-depends are often frowned upon, what do others think
> > of this for this case?
> 
> It is utterly and absolutely useless, since config scripts are executed
> before pre-depends are installed.

Uhm, yes, you are right. So it wouldn't help anyway. Only
possibility would be a versioned dependency (according to [1])
or to really do it in the postinst. Leads to the question
which of the solution we'd prefer.

Regards,
Patrick

[1] http://www.debian.org/doc/debian-policy/ch-binary.html#fr10


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

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

[Julien Cristau]

On Tue, Dec 29, 2009 at 17:35:53 +0100, Stefano Zacchiroli wrote:

> Format 3.0 is more than .bz2 support.

And we're saying .bz2 support is the only thing in it we care about, and
didn't need to come with 3.0's drawbacks.

[...]
> Finally, nobody is forced to use it: if you don't like it, just avoid
> using it.
> 
They are, at this point, if they need .bz2 support.  It didn't need to
be this way, but apparently the other way was "unwanted" for some reason.

Cheers,
Julien


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

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

[Milan P. Stanic]

On Mon, 2009-12-28 at 20:56, Steve Langasek wrote:
> On Tue, Dec 29, 2009 at 01:47:40AM +0100, Vincent Lefevre wrote:
> > > As for mail, we already appear to have an /etc/mailname file for MTAs and 
> > > MUAs to use for finding out the 'canonical' name of the host for message-
> > > IDs and the like.
> > /etc/mailname doesn't seem to be specified by POSIX
> Nope, it's specified in Debian policy (11.6).
> > , so that I doubt that all mail software uses it in practice (Mutt doesn't
> > seem to use it...
> That would be a bug, then.

Mutt in testing/unstable use /etc/mailname.

-- 
Kind regards,  Milan
--
Arvanta, IT Securityhttp://www.arvanta.net
Please do not send me e-mail containing HTML code.


signature.asc
Description: Digital signature

Re: Bug#562848: RFP: pencil -- animation/drawing software

[Frank Lin PIAT]

Hello Nick,

Nick Shaforostoff wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org
>
> --- Please fill out the fields below. ---

It is a best practice to fill all the fields below (they wouldn't
be in the template otherwise ;)

>Package name: pencil
> Version: 0.4.4
> Upstream Author: NAME 
> URL: http://www.pencil-animation.org/
> License: GPL
> Description: animation/drawing software

Usually, it is a good idea to write the full package description
that you would use for the upload... so people can give feed back.

Otherwise, that looks like a funny pice of software.

Thanks,

Franklin


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

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

[Stefano Zacchiroli]

On Tue, Dec 29, 2009 at 04:52:59PM +, Julien Cristau wrote:
> > Format 3.0 is more than .bz2 support.
> And we're saying .bz2 support is the only thing in it we care about, and
> didn't need to come with 3.0's drawbacks.

And I'm still saying that ranting _here_ about that is pointless.

Submit a bug report (I've just looked for it, but I didn't find it, does
it exist at all?), provide patches for it, and have them accepted by the
dpkg maintainers and FTP masters. They day they'll refuse the patches or
tag the bug as +wontfix you'll have a reason to complain and we will
hopefully know the technical reasons why the involved maintainers thin
it is a bad idea.

All this belongs to the BTS, not to -devel.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Bug#562968: ITP: otpasswd -- one-time passwords implementation for PAM

[Luke Faraone]

Package: wnpp
Severity: wishlist
Owner: Luke Faraone 


* Package name: otpasswd
  Version : 0.4
  Upstream Author :  Tomasz bla Fortuna  
* URL : http://savannah.nongnu.org/projects/otpasswd/ 
* License : GPLv3+
  Programming Lang: C
  Description : one-time passwords implementation for PAM

otpasswd consists of a pam module and an user utility. With the
utility user manages his "state" file: creates his KEY, manages flags
and prints passcards with one-time passwords.

PAM module enables (for example) OpenSSH to do an authentication using
one-time password with the information from user state file.

The program is written in C (C99) and implements OTP as described in
"Perfect Paper Passwords" description of which can be found here
https://www.grc.com/ppp.htm
This program also kind of extends this idea with "salt".

Unlike OPIE, otpasswd uses modern hashing algotrithms and supports offline
/ out-of-band use.



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

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

[Raphael Hertzog]

Hi,

On Tue, 29 Dec 2009, Norbert Preining wrote:
> On Di, 29 Dez 2009, Raphael Hertzog wrote:
> > That's because you're doing a source only build. With a binary build,
> > patches would have been applied.
> 
> I always build my packages in a clean chroot and not in my life system.

I do the same (albeit not a minimal chroot) but I share my /home between
the chroot dedicated to package building and the main system so that 
I can simply do "schroot -p sid debuild" (or similar).

Cheers,
-- 
Raphaël Hertzog


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

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

[Bernhard R. Link]

* Hendrik Sattler  [091226 18:48]:
> > Does that mean your application only works if the kernel supports
> > IPv6?
>
> Why would you want to disable basic IPv6 support?

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

Hochachtungsvoll,
Bernhard R. Link


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

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

[Gabor Gombas]

On Tue, Dec 29, 2009 at 02:52:44PM +0100, Vincent Lefevre wrote:

> When the machine is correctly configured (i.e. really has a FQDN),
> "hostname -f" is reliable.

No, it is not. "hostname -f" can return one value only, while a host may
have dozens or hundreds of valid FQDNs.

Example: there is a router box called "gw" which has about a dozen
addresses that resolve to "gw." for just as many domains. Some
addresses even share the same NIC. Which FQDN should "hostname -f"
display? Why that one, and not some other?

I've submitted a patch for hostname (#562830) to add two new options:
one that displays all IP addresses of the host, while the other displays
all the FQDNs for those addresses. Neither relies on the value returned
by gethostname(), so "the hostname must be an FQDN" misbelief together
with any usage of "hostname -f" can die a silent death.

Gabor

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


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

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

[Raphael Hertzog]

Hi,

On Tue, 29 Dec 2009, Stefano Zacchiroli wrote:
> On Tue, Dec 29, 2009 at 04:52:59PM +, Julien Cristau wrote:
> > > Format 3.0 is more than .bz2 support.
> > And we're saying .bz2 support is the only thing in it we care about, and
> > didn't need to come with 3.0's drawbacks.
> 
> And I'm still saying that ranting _here_ about that is pointless.
> 
> Submit a bug report (I've just looked for it, but I didn't find it, does
> it exist at all?), provide patches for it, and have them accepted by the
> dpkg maintainers and FTP masters. They day they'll refuse the patches or
> tag the bug as +wontfix you'll have a reason to complain and we will
> hopefully know the technical reasons why the involved maintainers thin
> it is a bad idea.

I would tag such a bug wontfix because I'm not interested in breaking
backwards compatibility. 1.0 is what it is, and I made the deliberate
choice to not change what it is and to fix all the known
problems/misfeatures in 3.0.

I welcome improvements to 3.0 so that it suits the needs of everybody but
I'm not interested in creating a 1.1 format that would be 1.0 with
bz2 support.

Actually I recently added the "--single-debian-patch" dpkg-source option
so that 3.0 can be used much like 1.0 for the case where people use a VCS
to store the debian changes directly on top of the upstream source code
(without using a patch system).

Most complaints seen are wrong-headed because you can do everything
you did in 1.0 with the new format if you really wish (although I largely
prefer that people use the quilt patch system if they were using a patch
system already).

I know of only one use-case that the new format does not support very
nicely and it's when you store changes both in the .diff.gz and in
debian/patches/ (with quilt). Currently the changes in .diff are applied
before the changes in debian/patches/ and with the new format the content
of the diff is moved in the "debian-changes" quilt patch at the end of the
series. Julien is doing that with xorg packages because he doesn't 
want quilt patches for simple cherry-pick, he only uses quilt for patches
that are really debian-specific divergence while the other changes are
mixed in the .diff and disappear semi-automatically when he imports a new
upstream version that contains the changes that were already
cherry-picked. I think some helper tools to auto-remove patches
that are already part of the git history would nicely solve this problem
but someone has to write such tools and Julien simply doesn't have the
time (xorg is enough maintenance work).

Cheers,
-- 
Raphaël Hertzog


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

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

[Raphael Hertzog]

On Tue, 29 Dec 2009, Joachim Wiedorn wrote:
> Even though there are some newer Mails this question seems to not be
> solved.
> 
> Is it true, that I need an installed quilt to unapply the patches? 

Yes. With "3.0 (quilt)", the default state is "patches are applied" (since
that's what you get when you do dpkg-source -x).

> Or can I do it with dpkg-buildpackage or dpkg-source?

No.

Cheers,
-- 
Raphaël Hertzog


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

Bug#562976: ITP: python-ev -- Python bindings to libev

[Julien Danjou]

Package: wnpp
Severity: wishlist
Owner: Julien Danjou 

* Package name: python-ev
  Version : 0.5.3
  Upstream Author : Malek Hadj-Ali
* URL : http://code.google.com/p/pyev/
* License : BSD/GPL-3
  Programming Lang: C, Python
  Description : Python bindings to libev


-- 
Julien Danjou
// ᐰhttp://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
// Tomorrow I was nothing, yesterday I'll be.


signature.asc
Description: Digital signature

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

[Ben Hutchings]

On Tue, 2009-12-29 at 18:37 +0100, Bernhard R. Link wrote:
> * Hendrik Sattler  [091226 18:48]:
> > > Does that mean your application only works if the kernel supports
> > > IPv6?
> >
> > Why would you want to disable basic IPv6 support?
> 
> I routinely blacklist the ipv6 module. There are far too many
> programs breaking or doing stuff I do not want if it is loaded.

I trust you have filed bugs on these applications?

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.


signature.asc
Description: Digital signature

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

[Russ Allbery]

Peter Samuelson  writes:

> Presumably dpkg maintainers.  I've long suspected that the main reason
> they chose not to add tar.bz2 to format 1.0 is, if they did, a lot of
> us would have no reason to want format 3.0.  Many packagers don't need
> multiple tarballs or non-text files, and are quite happy to 'include
> /usr/share/quilt/quilt.make' by hand.  We don't find it hard to extract
> an NMU diff even if it wasn't posted to the bug as it should be.  It's
> hard enough to convince us to want 3.0 even with tar.bz2 support.

I don't think this is entirely fair.  The 3.0 format was designed to solve
a bunch of problems that had all gotten a lot of discussion on the mailing
lists.  bzip2 (and LZMA, and now probably XZ) support is only one of them.

The dpkg maintainers were hearing from the project that various people
wanted solutions to all of the following problems:

* Support for other compression methods.
* Multiple upstream source tarballs.
* Apply patches so that dpkg-source -x gives buildable source.
* Ship debian/* as a tarball instead of a patch.
* Allow binaries in the debian directory.
* Allow modified binaries in the upstream source.
* Standardize a patch format so that NMUers don't need to know so many.

All of those problems were rather heavily discussed in -devel, -policy,
-dpkg, DebConf, and various other places.  At the time that the design was
done, there was both existing wig & pen work to incorporate and there was
a general move in the project towards using quilt as the patch system of
choice.  Lots and lots of packages were being converted to it at the time,
and of the available options, it was probably the best balance of
features, simplicity, and number of active users.  It also had the
advantage of not being a Debian-specific tool.

The 3.0 source format does solve all of those problems.  I think it may be
fair to argue that it suffers from some degree of second-system syndrome,
but that's an inherent risk in this sort of work.

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


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

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

[Felipe Sateler]

On Mon, 2009-12-28 at 22:40 -0800, Russ Allbery wrote:
> I think the way forward for Git-maintained packages is the 3.0 (git)
> format, but changed to ship a bundle.  That way, relevant branches and
> history can be included, and Git is fairly space-efficient so the
> additional cost of doing so isn't that bad. 

Why go through the hassle of creating a git format when patching dak to
import a VCS-signed tag (which may be mor difficult, I agree) is much
more efficient?

-- 
Saludos,
Felipe Sateler



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

Re: bug #561324: asking questions in postinst

[Russ Allbery]

Patrick Schoenfeld  writes:

> Uhm, yes, you are right. So it wouldn't help anyway. Only possibility
> would be a versioned dependency (according to [1]) or to really do it in
> the postinst. Leads to the question which of the solution we'd prefer.

> [1] http://www.debian.org/doc/debian-policy/ch-binary.html#fr10

I'm not sure what sort of versioned dependency you're referring to, but
config scripts can only use binaries from essential packages or debconf
itself.  See debconf-devel:

   Note that the config script is run before the package is unpacked.
   It should only use commands that are in essential packages.  The
   only dependency of your package that is guaranteed to be met when
   its config script is run is a dependency (possibly versioned) on
   debconf itself.

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


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

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

[Russ Allbery]

Felipe Sateler  writes:
> On Mon, 2009-12-28 at 22:40 -0800, Russ Allbery wrote:

>> I think the way forward for Git-maintained packages is the 3.0 (git)
>> format, but changed to ship a bundle.  That way, relevant branches and
>> history can be included, and Git is fairly space-efficient so the
>> additional cost of doing so isn't that bad.

> Why go through the hassle of creating a git format when patching dak to
> import a VCS-signed tag (which may be mor difficult, I agree) is much
> more efficient?

That doesn't solve the same problem as near as I can tell.  That's a
replacement for the upload process, but once dak has imported the signed
tag and has a copy of the repository, now what?  How is that data
represented?  How is it distributed to Debian systems that want to
download the source package?  I think you end up reinventing 3.0 (git) as
a format for redistributing the thing that dak has pulled as a signed tag.

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


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

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

[Russ Allbery]

Vincent Lefevre  writes:

> Even if Debian has its own patches to match its policy, end users are
> still allowed to compile software from upstream (this is what I do for
> Mutt, because I have my own patches), and they expect such software to
> work.

If you expect the software you use to be properly integrated with the
Debian system, you should use the Debian packages.  That's kind of the
whole point of what we're all doing here.

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


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

Re: Bug#562848: RFP: pencil -- animation/drawing software

[Cyril Brulebois]

Frank Lin PIAT  (29/12/2009):
> It is a best practice to fill all the fields below (they wouldn't be
> in the template otherwise ;)
> […]
> Usually, it is a good idea to write the full package description
> that you would use for the upload... so people can give feed back.

Better yet, check the BTS. #490702

(And for you, Frank Lin, Cc the bug submitter, added back…)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: [Expat-discuss] RFH: Patch for CVE-2009-3560 in expat breaks the Perl XML parser

[Karl Waclawek]

Niko Tyni wrote:

>> Could you please run the failing tests with Expat directly, instead of the
>> Perl parser?
> 
> I'm able to reproduce (at least part of) the problem without the Perl
> bindings, using the 'xmlwf' example tool from the expat source (shipped
> in the 'expat' package on Debian.)
> 
> I'm attaching an example XML document and the external DTD it
> references. Without the CVE-2009-3560 patch, the test 'xmlwf -p t.xml'
> silently passes. With the patch, the output is
> 
>  t.dtd:4:3: syntax error
>  t.xml:2:28: error in processing external entity reference
> 
> (The DTD was copied verbatim from the example at
>  http://www.w3.org/TR/REC-xml/#sec-condition-sect )

I revised the patch - see newest revision of xmlparse.c (rev. 166).

May I ask for a favour:
Please discuss these issues directly on the comments of the bug entry on
SourceForge. Without this we will have no clue what things were discussed and
discovered while fixing a bug.

Thanks,

Karl



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

Bug#562980: RFP: iFolder -- keeps synchronized the directories on many computers

[C Sights]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: iFolder
Version: 3.8
Upstream Author: Novell (Bipin sivaraman, Ravi Kumar, Joe 'Zonker' Brockmeier)
URL: http://sourceforge.net/projects/ifolder/
License: GPL
Description: iFolder continuously synchronizes directories across multiple 
computers using a server to coordinate transfers.  It also backs up the 
directories to a server.  Similar to "Dropbox", but open source so there are 
no artificial limits on the size of the synchronized directories.

There are some preliminary packages in an Ubuntu PPA:
https://launchpad.net/~marceloshima/+archive/ifolder

Source in SVN:
http://ifolder.svn.sourceforge.net/svnroot



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

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

[Vincent Lefevre]

On 2009-12-29 18:49:00 +0100, Gabor Gombas wrote:
> On Tue, Dec 29, 2009 at 02:52:44PM +0100, Vincent Lefevre wrote:
> > When the machine is correctly configured (i.e. really has a FQDN),
> > "hostname -f" is reliable.
> 
> No, it is not. "hostname -f" can return one value only, while a host may
> have dozens or hundreds of valid FQDNs.

Well, the node name is unique. From that, you'll obtain the FQDN with
either the obsolete function gethostbyname or the new POSIX function
getaddrinfo (by using the AI_CANONNAME flag). POSIX says:

  If the AI_CANONNAME flag is specified and the nodename argument is
  not null, the function shall attempt to determine the canonical name
  corresponding to nodename (for example, if nodename is an alias or
  shorthand notation for a complete name).

And here's what the getaddrinfo(3) man page says under Debian:

  If hints.ai_flags includes the AI_CANONNAME flag, then the ai_canonname
  field of the first of the addrinfo structures in the returned  list  is
  set to point to the official name of the host.

Then you need to configure your machine according to the spec, i.e.
you need a single FQDN / canonical name / official name of the host.

> Example: there is a router box called "gw" which has about a dozen
> addresses that resolve to "gw." for just as many domains. Some
> addresses even share the same NIC. Which FQDN should "hostname -f"
> display?

This doesn't really matter. The FQDN may also be another name, i.e.
the nodename may be something more meaningful than "gw".

But host names (like www.debian.org) can also resolve to several IP
addresses corresponding to different machines. So, make use that the
FQDN doesn't correspond to such a host name.

> Why that one, and not some other?

You should ask this question to those who configured such routers
(but this would be more a practical matter, as you may have plenty
of choices).

> I've submitted a patch for hostname (#562830) to add two new options:
> one that displays all IP addresses of the host, while the other displays
> all the FQDNs for those addresses.

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

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

> Neither relies on the value returned by gethostname(), so "the
> hostname must be an FQDN" misbelief together with any usage of
> "hostname -f" can die a silent death.

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

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


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

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

[Vincent Lefevre]

On 2009-12-29 17:44:31 +0100, Milan P. Stanic wrote:
> Mutt in testing/unstable use /etc/mailname.

But not the official Mutt version.

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


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

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

[Vincent Lefevre]

On 2009-12-29 10:45:17 -0800, Russ Allbery wrote:
> Vincent Lefevre  writes:
> > Even if Debian has its own patches to match its policy, end users are
> > still allowed to compile software from upstream (this is what I do for
> > Mutt, because I have my own patches), and they expect such software to
> > work.
> 
> If you expect the software you use to be properly integrated with the
> Debian system, you should use the Debian packages.  That's kind of the
> whole point of what we're all doing here.

When I compile Mutt or any other portable software (e.g. conforming to
POSIX), I don't mind if such software isn't integrated with the Debian
system. I just want it work according to the POSIX spec. If it doesn't
because the system configuration doesn't comply to POSIX, then the
system (configuration) is broken.

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


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

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

[Russ Allbery]

Vincent Lefevre  writes:

> When I compile Mutt or any other portable software (e.g. conforming to
> POSIX), I don't mind if such software isn't integrated with the Debian
> system. I just want it work according to the POSIX spec. If it doesn't
> because the system configuration doesn't comply to POSIX, then the
> system (configuration) is broken.

I don't think POSIX says what you think it says, but I could be wrong.
Could you cite the exact section that says that systems are required by
POSIX to be configured in the manner that you describe?  getaddrinfo does
not place such a restriction; AI_CANONNAME is allowed to fail.  Note the
use of the word "attempt" and the note:

Since different implementations use different conceptual models, the
terms ``canonical name'' and ``alias'' cannot be precisely defined for
the general case. However, Domain Name System implementations are
expected to interpret them as they are used in RFC 1034.

I don't believe there's any requirement anywhere in POSIX that the return
value of uname -n be registered in DNS.  In fact, the POSIX definition of
the uname utility specifically says "the name of this node within an
implementation-defined communications network."  Implementation-defined
means you cannot depend on it to be anything in particular without
additional information about the implementation you're using.

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

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

[Ralph Lange]

Package: wnpp
Severity: wishlist
Owner: Ralph Lange 


* Package name: procserv
  Version : 2.5.0
  Upstream Author : Ralph Lange 
* URL : http://sourceforge.net/projects/procserv/
* License : GPLv3
  Programming Lang: C++
  Description : A process server with telnet console and log access

procServ is a wrapper that starts an arbitrary command as a child process in
the background, connecting its standard input and output to a TCP port for
telnet access. It supports logging, child restart (manual or automatic on
exit), and more.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



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

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

[Joerg Jaspert]

>> It would have been MORE than easy to have bz2 support in 1.0. There is
>> absolutely no reason why it needs a 3.0 just for a different compression.
>> But that wasnt wanted.
> By whom?  dpkg maintainers, archive admins, package maintainers?
> tar.bz2 support is the only reason I see for considering 3.0 at this
> point…

Archive side its about a tiny regex.

-- 
bye, Joerg
 Joerg knuddeln ist wie mit Skorpionen schlafen.


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

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

[Vincent Lefevre]

On 2009-12-29 14:18:47 -0800, Russ Allbery wrote:
> Vincent Lefevre  writes:
> > When I compile Mutt or any other portable software (e.g. conforming to
> > POSIX), I don't mind if such software isn't integrated with the Debian
> > system. I just want it work according to the POSIX spec. If it doesn't
> > because the system configuration doesn't comply to POSIX, then the
> > system (configuration) is broken.
> 
> I don't think POSIX says what you think it says, but I could be wrong.
> Could you cite the exact section that says that systems are required by
> POSIX to be configured in the manner that you describe?

I haven't say anything about the configuration, just that POSIX says
that a system (locally identified by nodename) has a canonical name.

> getaddrinfo does not place such a restriction; AI_CANONNAME is
> allowed to fail.  Note the use of the word "attempt"

Yes, but a failure is something one can expect to happen under some
occasions, at least for remote hosts. This doesn't mean that hosts
don't have a canonical name, just that this canonical name couldn't
be determined.

For the local host, I would say that a failure is mostly due to a
configuration problem (unless a remote DNS is used, in which case
it may be down, and BTW, that's why I think it is a bad idea to use
one for something purely local). I'd say that making the request
fail on purpose is contrary to POSIX, and I find it not surprising
that software could fail to behave correctly because of that.

> and the note:
> 
> Since different implementations use different conceptual models, the
> terms ``canonical name'' and ``alias'' cannot be precisely defined for
> the general case. However, Domain Name System implementations are
> expected to interpret them as they are used in RFC 1034.
> 
> I don't believe there's any requirement anywhere in POSIX that the
> return value of uname -n be registered in DNS.

I haven't said that. And this is often not the case under Debian,
i.e. the FQDN is often obtained from /etc/hosts, which has the
precedence over DNS (see /etc/nsswitch.conf).

> In fact, the POSIX definition of the uname utility specifically
> says "the name of this node within an implementation-defined
> communications network." Implementation-defined means you cannot
> depend on it to be anything in particular without additional
> information about the implementation you're using.

This is implementation-defined, but still, the host has a canonical
name, that should be obtainable with getaddrinfo, as described.

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

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


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

Intel 845G Card not working on SID..

[mukund jampala]

I Just upgraded to SID from Lenny and I am having a problem with the
Graphics Card. Someone please help me out here on Intel Graphics cards is
not working on SID platform.

I am seeing an error on my Intel 82845G Integrated Graphic Device
A message
drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged
drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged
drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged
drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged
.
drm:i915_gem_execbuffer] *ERROR* hardware wedged

Does anyone have a clue about this error.
I can provide more info if needed

Thanks
- Mukund

Re: Intel 845G Card not working on SID..

[Ben Hutchings]

On Tue, Dec 29, 2009 at 06:30:42PM -0800, mukund jampala wrote:
> I Just upgraded to SID from Lenny and I am having a problem with the
> Graphics Card. Someone please help me out here on Intel Graphics cards is
> not working on SID platform.

Report bugs to the Bug Tracking System, not debian-devel.  Run
'reportbug linux-2.6'.

Ben.

-- 
Ben Hutchings
When you say `I wrote a program that crashed Windows', people just stare ...
and say `Hey, I got those with the system, *for free*'. - Linus Torvalds


signature.asc
Description: Digital signature

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

[Charles Plessy]

Le Tue, Dec 29, 2009 at 10:33:45AM -0800, Russ Allbery a écrit :
> 
> * Support for other compression methods.
> * Multiple upstream source tarballs.
> * Apply patches so that dpkg-source -x gives buildable source.
> * Ship debian/* as a tarball instead of a patch.
> * Allow binaries in the debian directory.
> * Allow modified binaries in the upstream source.
> * Standardize a patch format so that NMUers don't need to know so many.
 
> The 3.0 source format does solve all of those problems.  I think it may be
> fair to argue that it suffers from some degree of second-system syndrome,
> but that's an inherent risk in this sort of work.

In my opinion, much of the current disagreements come from two false needs:

 * Apply patches so that dpkg-source -x gives buildable source.
 * Standardize a patch format so that NMUers don't need to know so many.

I remember the discussion that took place during DEP1 preparation. It already
had the outcome that the main patch systems converged on a common interface:

 - Store the patches in debian/patches;
 - Apply them with ‘debian/rules patch’;
 - Document specificities in debian/README.source.

There were some concerns that applying patches through debian/rules could be a
security hole. In my opinion – that I already expressed in the DEP1
discussion – given that 1) dpkg-source will not extract packages that are not
GPG-trusted, 2) the contents of debian/rules are easy to inspect and 3) in the
case of NMU debian/rules is trusted, there was no necessity to ignore the
de-facto standard interface: debian/rules patch.

Personnaly, I am completely unconvinced of the necessity of applying patches at
unpack time, nor of standardising on one particular patch implementation
instead of using a clear patch interface as the one above (parts of which being
already in the Debian Policy). If I am not the only one having this concern,
maybe we could ask the technical comittee to give us its conclusions on this
matter. I am ready to follow it.

In parallel, having dpkg-source call ‘debian/rules patch’ if it exists would
solve part of the conflict for the control of patching process. And this way we
will not be blocked with quilt if a better system emerges later.

Have a nice day,

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

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

[Russ Allbery]

Vincent Lefevre  writes:

> Yes, but a failure is something one can expect to happen under some
> occasions, at least for remote hosts. This doesn't mean that hosts don't
> have a canonical name, just that this canonical name couldn't be
> determined.

> For the local host, I would say that a failure is mostly due to a
> configuration problem (unless a remote DNS is used, in which case it may
> be down, and BTW, that's why I think it is a bad idea to use one for
> something purely local). I'd say that making the request fail on purpose
> is contrary to POSIX, and I find it not surprising that software could
> fail to behave correctly because of that.

I'm having a hard time figuring out what you think the canonical name of
my laptop could possibly be, given that it has no static IP address and no
DNS entry.  In practice, it's whatever arbitrary label that I gave it, and
none of these DNS-based resolution techniques are going to do you much
good or give you any sort of consistent answer, if they work at all.

> I haven't said that. And this is often not the case under Debian,
> i.e. the FQDN is often obtained from /etc/hosts, which has the
> precedence over DNS (see /etc/nsswitch.conf).

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

> This is implementation-defined, but still, the host has a canonical
> name, that should be obtainable with getaddrinfo, as described.

I don't see where you're finding any justification for that "should" in
POSIX.

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

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

If your package needs to know what hostname to use on (for example)
outgoing news and mail messages which are generated locally, you
should use the file /etc/mailname. It will contain the portion after
the username and @ (at) sign for email addresses of users on the
machine (followed by a newline).

So on my system, for instance, /etc/mailname is "stanford.edu," because
that's what goes on the RHS of e-mail addresses.  Which, of course, is not
the canonical name of my laptop.

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


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

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

[Russ Allbery]

Charles Plessy  writes:

> In my opinion, much of the current disagreements come from two false needs:

>  * Apply patches so that dpkg-source -x gives buildable source.

That was the need that had as much or more project consensus as anything
else on my list, and as I recall was the impetus for doing the whole
next-generation source format work in the first place.

> I remember the discussion that took place during DEP1 preparation. It
> already had the outcome that the main patch systems converged on a
> common interface:

>  - Store the patches in debian/patches;
>  - Apply them with ‘debian/rules patch’;
>  - Document specificities in debian/README.source.

If I'm not mistaken, that convergence and standardization actually
happened *after* the 3.0 work was mostly finished.  Certainly after the
2.0 work.

> There were some concerns that applying patches through debian/rules
> could be a security hole. In my opinion – that I already expressed in
> the DEP1 discussion – given that 1) dpkg-source will not extract
> packages that are not GPG-trusted,

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

> Personnaly, I am completely unconvinced of the necessity of applying
> patches at unpack time, nor of standardising on one particular patch
> implementation instead of using a clear patch interface as the one above
> (parts of which being already in the Debian Policy). If I am not the
> only one having this concern, maybe we could ask the technical comittee
> to give us its conclusions on this matter. I am ready to follow it.

I personally don't have a strong opinion, but there were a lot of people
who felt this was important during the initial discussions.

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


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

Re: bug #561324: asking questions in postinst

[Patrick Schoenfeld]

On Tue, Dec 29, 2009 at 10:37:45AM -0800, Russ Allbery wrote:
> Patrick Schoenfeld  writes:
> 
> > Uhm, yes, you are right. So it wouldn't help anyway. Only possibility
> > would be a versioned dependency (according to [1]) or to really do it in
> > the postinst. Leads to the question which of the solution we'd prefer.
> 
> > [1] http://www.debian.org/doc/debian-policy/ch-binary.html#fr10
> 
> I'm not sure what sort of versioned dependency you're referring to, but
> config scripts can only use binaries from essential packages or debconf
> itself.  See debconf-devel:

I'm not sure if you actually read the remark in the policy I linked to.
According to the policy _all_ versioned dependencies and debconf are
installed before the config script is run.

>Note that the config script is run before the package is unpacked.
>It should only use commands that are in essential packages.  The
>only dependency of your package that is guaranteed to be met when
>its config script is run is a dependency (possibly versioned) on
>debconf itself.

Hm. Contrary information. Makes me wonder weither debconf-devel or
debian-policy is right..

Regards,
Patrick


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

Re: bug #561324: asking questions in postinst

[Russ Allbery]

Patrick Schoenfeld  writes:
> On Tue, Dec 29, 2009 at 10:37:45AM -0800, Russ Allbery wrote:
>> Patrick Schoenfeld  writes:

>>> Uhm, yes, you are right. So it wouldn't help anyway. Only possibility
>>> would be a versioned dependency (according to [1]) or to really do it in
>>> the postinst. Leads to the question which of the solution we'd prefer.

>>> [1] http://www.debian.org/doc/debian-policy/ch-binary.html#fr10

>> I'm not sure what sort of versioned dependency you're referring to, but
>> config scripts can only use binaries from essential packages or debconf
>> itself.  See debconf-devel:

> I'm not sure if you actually read the remark in the policy I linked to.
> According to the policy _all_ versioned dependencies and debconf are
> installed before the config script is run.

I'm not sure what you're talking about.  If you mean the URL quoted above,
the relevant portion of that section is:

The config script might be run before the preinst script, and before
the package is unpacked or any of its dependencies or pre-dependencies
are satisfied. Therefore it must work using only the tools present in
essential packages.

which says the same thing that debconf-devel does (well, it implies that
you can't even use debconf, but that's not the case).

If you're referring to something else, could you quote the relevant text?
I can't find it in that section.

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


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

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

[Frank Lin PIAT]

Hello,

On Tue, 2009-12-29 at 17:35 -0500, Ralph Lange wrote:
> 
> * Package name: procserv
> * URL : http://sourceforge.net/projects/procserv/
>   Description : A process server with telnet console and log access
> 
> procServ is a wrapper that starts an arbitrary command as a child process in
> the background, connecting its standard input and output to a TCP port for
> telnet access. It supports logging, child restart (manual or automatic on
> exit), and more.

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

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

Franklin


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

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

[Vincent Bernat]

OoO En  cette fin  de nuit  blanche du mercredi  30 décembre  2009, vers
05:23, Russ Allbery  disait :

>> I haven't said that. And this is often not the case under Debian,
>> i.e. the FQDN is often obtained from /etc/hosts, which has the
>> precedence over DNS (see /etc/nsswitch.conf).

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

If this is a real question, put:
127.0.1.1 fqdn nodename

This seems a  very acceptable way to give a FQDN  to your laptop without
relying  on network.  hostname -f  and  programs using  a similar  inner
working will be able to get the right result.
-- 
I WILL NOT BURP IN CLASS
I WILL NOT BURP IN CLASS
I WILL NOT BURP IN CLASS
-+- Bart Simpson on chalkboard in episode 7G04


pgpikse8ltT4a.pgp
Description: PGP signature

Re: bug #561324: asking questions in postinst

[Patrick Schoenfeld]

On Tue, Dec 29, 2009 at 11:01:58PM -0800, Russ Allbery wrote:
> Patrick Schoenfeld  writes:
> > On Tue, Dec 29, 2009 at 10:37:45AM -0800, Russ Allbery wrote:
> >> Patrick Schoenfeld  writes:
> 
> >>> Uhm, yes, you are right. So it wouldn't help anyway. Only possibility
> >>> would be a versioned dependency (according to [1]) or to really do it in
> >>> the postinst. Leads to the question which of the solution we'd prefer.
> 
> >>> [1] http://www.debian.org/doc/debian-policy/ch-binary.html#fr10
> 
> >> I'm not sure what sort of versioned dependency you're referring to, but
> >> config scripts can only use binaries from essential packages or debconf
> >> itself.  See debconf-devel:
> 
> > I'm not sure if you actually read the remark in the policy I linked to.
> > According to the policy _all_ versioned dependencies and debconf are
> > installed before the config script is run.
> 
> I'm not sure what you're talking about.  If you mean the URL quoted above,
> the relevant portion of that section is:

Sorry, the link was obviously to the section not the footnote. My fault.
The footnote in that section (next to the quoted passage) reads

Debconf or another tool that implements the Debian Configuration
Management Specification will also be installed, and any versioned
dependencies on it will be satisfied before preconfiguration begins. 

Regards,
Patrick


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

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

[Russ Allbery]

Vincent Bernat  writes:
> Russ Allbery  disait:

>>> I haven't said that. And this is often not the case under Debian,
>>> i.e. the FQDN is often obtained from /etc/hosts, which has the
>>> precedence over DNS (see /etc/nsswitch.conf).

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

> If this is a real question, put:
> 127.0.1.1 fqdn nodename

I think we're having some sort of fundamental misunderstanding or
communications gap here.  What FQDN do you think I should put there?
Should I just make something up, like laptop.russ.allbery?

In truth, my laptop *does not have an FQDN*.  The concept has no useful
meaning for a system that is not persistently on any one network, has no
"native" domain, has no DNS entry, and just gets IP addresses via DHCP
wherever it happens to be.  Nor, as other people have been pointing out,
does it have any well-defined meaning for a system that has the opposite
problem:  multiple separate IP addresses in completely different domains.

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

As with a few other people commenting on this thread, I usually shrug and
pick an arbitrary one of the DNS names assigned to a multihomed box to be
the "real" name for hostname, since usually it doesn't matter.  But I
don't think there's anything inherently correct about that, nor do I see
anywhere it's required by POSIX.  And, for my laptop, there really isn't
any such name at all.

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


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

Re: bug #561324: asking questions in postinst

[Russ Allbery]

Patrick Schoenfeld  writes:

> Debconf or another tool that implements the Debian Configuration
> Management Specification will also be installed, and any versioned
> dependencies on it will be satisfied before preconfiguration begins.

Oh, sorry, I didn't think to check the footnote.

However, I think you're reading the wrong meaning into the footnote.  "It"
here refers to "Debconf or another tool that implements"  In other
words, what the message is saying is that if your package has a versioned
dependency on debconf, you're guaranteed to get that version of debconf,
not some other, before the config script of the package is run.

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

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