Re: Intend to create an -fPIC library package...

[Raphael Hertzog]

On Wed, 22 Jul 2009, Christian Hammers wrote:
> Am Tue, 21 Jul 2009 22:13:55 + (UTC)
> schrieb Philipp Kern :
> > Well, actually... I would expect that from a maintainer of a... shared
> > library.  dpkg-gensymbols helps with that, though.
> 
> I meant "maintainer" as in Debian maintainer not as in upstream author.
> The upstream programmers are responsible for their soname as they know
> the best when they change relevant code. Or would you really mean we
> should compare the symbol table of every new upstream release with the
> previous one?

Yes. Check "man dpkg-gensymbols" and see how some nice tools can help you
automate part of this task. Furthermore by shipping symbols files with
your library, library users will have dependencies which are somewhat
optimized (depending on the symbols that they really use).

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: MTA experts: address rewriting depending on next hop

[Izak Burger]

On Tue, Jul 21, 2009 at 7:31 PM, Siggy Brentrup wrote:
> Here's the question again: which one of the abundance of MTAs in
> Debian is capable of address rewriting depending on destination?

I am pretty sure exim can do this. Chapter 24 in the manual describes
headers_rewrite which is a generic option for transports, ie it will
work for all transports including the smtp transport that is generally
the last one in the config and handles all non-local email (ie those
leaving the lan).


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

Re: Is adding dh_config and a postinst snippet ok ?

[Dominique Dumont]

Raphael Hertzog  writes:

> A question about this project, I've recently discovered augeas, how do you
> compare yourself with it?

I forgot to mention that a video of the Config::Model presentation done
during French Perl Workshop is available there:

  http://fpw2009.ubicast.eu/videos/free/64/

Unfortunately, this video is available only in French.

All the best

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


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

Re: MTA experts: address rewriting depending on next hop

[Siggy Brentrup]

Hi Izak,

On Wed, Jul 22, 2009 at 09:36 +0200, you wrote:
> On Tue, Jul 21, 2009 at 7:31 PM, Siggy Brentrup wrote:
> > Here's the question again: which one of the abundance of MTAs in
> > Debian is capable of address rewriting depending on destination?
> 
> I am pretty sure exim can do this. Chapter 24 in the manual describes
> headers_rewrite which is a generic option for transports, ie it will
> work for all transports including the smtp transport that is generally
> the last one in the config and handles all non-local email (ie those
> leaving the lan).

Thanks, I'll give it a try
  Siggy
-- 
Please don't Cc: me when replying, I might not see either copy.
   bsb-at-psycho-dot-informationsanarchistik-dot-de
   or:bsb-at-psycho-dot-i21k-dot-de
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


signature.asc
Description: Digital signature

[SOLVED] MTA experts: address rewriting depending on next hop

[Siggy Brentrup]

On Wed, Jul 22, 2009 at 09:36 +0200, Izak Burger wrote:
> On Tue, Jul 21, 2009 at 7:31 PM, Siggy Brentrup wrote:
> > Here's the question again: which one of the abundance of MTAs in
> > Debian is capable of address rewriting depending on destination?
> 
> I am pretty sure exim can do this. Chapter 24 in the manual describes
> headers_rewrite which is a generic option for transports, ie it will
> work for all transports including the smtp transport that is generally
> the last one in the config and handles all non-local email (ie those
> leaving the lan).

Again, avoiding to followup to myself :-)

No, exim4 can't do it either, the reason given in
  http://wiki.exim.org/FAQ/Rewriting_addresses/Q0807
is convincing.

Keeping that in mind, I'll go for the 2 instance approach with
Postfix.

Thanks
  Siggy
-- 
Please don't Cc: me when replying, I might not see either copy.
   bsb-at-psycho-dot-informationsanarchistik-dot-de
   or:bsb-at-psycho-dot-i21k-dot-de
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


signature.asc
Description: Digital signature

Re: [SOLVED] MTA experts: address rewriting depending on next hop

[Izak Burger]

On Wed, Jul 22, 2009 at 10:20 AM, Siggy Brentrup wrote:
> No, exim4 can't do it either, the reason given in
>  http://wiki.exim.org/FAQ/Rewriting_addresses/Q0807
> is convincing.

Ok, your question wasn't too clear on that. I didn't know you needed
to rewrite the envelope sender based on the target domain, and quite
correctly, exim cannot do that.

I do recall doing something pretty similar at a previous employer, in
a slightly different manner. I will try and explain the setup, maybe
this can serve as inspiration.

We had three machines participating in a sort of mail network. One
machine was in a data center, receiving mail from the big bad world.
The other two lived in the offices, one in Johannesburg and one in
Cape Town, connected to the external mail server by VPN.

We also had an LDAP directory that was replicated over all three
machines, indicating what employee was in what office. We had an email
address mapping in LDAP for each employee that would map
emplo...@company.co.za to either emplo...@jhb.company.co.za or
emplo...@cpt.company.co.za, with a rewrite rule configured in exim to
do the rewrite on the recipient. This only affected the envelope.

Finally each machine had appropriate routers so that the relevant
domain was delivered locally, the "other" one was sent to the other
office over the vpn, and anything outside company.co.za was sent to a
smart host.

This way, people didn't have to know about their "internal" email
address. They simply sent email using their "official external"
address as the sender, using the other person's external address as
the recipient. If the recipient happened to be in the same office as
the sender, exim would rewrite the recipient to an internal address
and it would get delivered locally. Since the headers were never
touched, nobody was the wiser about all the trickery going on in the
background.

Unfortunately I didn't keep a copy of the configuration files, and
I've left that employer some five years ago, so an explanation is the
best I can do here.

regards,
Izak


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

Please test krb5-config in experimental

[Sam Hartman]

Last night I uploaded a more or less rewrite of krb5-config to
experimental.  The goal of this rewrite is to significantly reduce the
number of cases where users are asked questions or where the resulting
configuration is completely wrong.

krb5-config is responsible for generating /etc/krb5.conf, which is
used by Kerberos implementations in Debian.  Testing is valuable both
from people who use Kerberos and those who do not.

Testing is most valuable if you purge the krb5-config package before
testing.

Here is expected behavior:

* If your site does not use Kerberos at all, you will almost certainly
  be prompted for a Kerberos realm name.  If you enter a Kerberos
  realm name that Debian has never heard of, you will be prompted for
  Kerberos servers.  If you enter something like ATHENA.MIT.EDU (case 
sensitive), then you will not.

* If dnsdomainname or hostname --fqdn don't provide reasonable results you'll 
probably be prompted for a Kerberos realm.

* If your site uses Kerberos and your KDC configuration is in  DNS, then  you 
will not see any prompts at debconf priority above medium.

* If your Kerberos realm does not match your DNS domain, it should do
  a fairly good job of figuring that out.  If it doesn't, then I'd
  definitely like to hear from you--if nothing else, I can add a
  static hint.

* dpkg-reconfigure krb5-config at priority medium or below should allow you to 
set the realm and should make sure that Debian knows how to find KDCs for that 
realm.


Thanks for your help.

--Sam


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

Bug#537993: RFH: mdadm -- tool to administer Linux MD arrays (software RAID)

[martin f krafft]

Package: wnpp
Severity: normal

I request assistance with maintaining the mdadm package. I can still
maintain it, but would like to pass it to someone else in the long
run, so now would be a good time to get into it.

The package description is:
 The mdadm utility can be used to create, manage, and monitor MD
 (multi-disk) arrays for software RAID or multipath I/O.
 .
 This package automatically configures mdadm to assemble arrays during the
 system startup process. If not needed, this functionality can be disabled.


-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Intend to create an -fPIC library package...

[Bernd Zeimetz]

Peter Samuelson wrote:

> 2) Runtime linking.  This is overhead at application startup time.
>Something that embeds an SQL engine should not, I think, start up too
>frequently.  Am I wrong?

We're talking about amarok here. As a medi aplayer I could imagine it will be
starte several times per day...

-- 
 Bernd Zeimetz Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


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

Re: Bug#537623: ITP: busybox-syslogd -- Provides syslogd and klogd using busybox' implementation

[Julien Cristau]

On Sun, Jul 19, 2009 at 23:41:24 +0200, Axel Beckert wrote:

> Debian's busybox package has the syslogd and klogd functionalities
> already compiled in, but to use them, a little bit more than a few
> symbolic links is needed.
> 
> This package provides the appropriate dependencies, the symbolic links
> for syslogd and klogd, man pages (also symlinks), and init.d scripts.
> 
why does this need a separate source package?

Cheers,
Julien


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

Re: piuparts run by every uploader

[Holger Levsen]

Hi,

On Dienstag, 21. Juli 2009, Jonas Meurer wrote:
> is there any chance to get that fixed by either removing the circular
> dependency from perl directly or by adding code to manage circular
> dependencies to piuparts?

as a first approach to this problem I plan to make piuparts ignore circular 
dependencies from the same source package, which will catch the perl and xorg 
cases, which have the highest impact on this...

patches welcome...


regards,
Holger


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

Re: Switching /bin/sh to dash (part two)

[Russ Allbery]

"Giacomo A. Catenazzi"  writes:

> Why?
> "Always installed" is different to "essential", see e.g. libc.

libc is essential from a Policy perspective.  It's just not marked that
way in the packaging system in case the SONAME changes, but it's essential
in the same way that awk is.  Note that dependencies on awk are not
required (and indeed are a Lintian warning).

> I really think that some essential package would depends on bash (in
> this case would be passwd, who provides useadd/chsh/..).

In which case bash should stay essential with the essential flag; if we're
going to guarantee that it's part of the essential set anyway, may as well
let everyone rely on all the things that entails.

> If we remove the essential flag, we have a nice feature:  the packages
> who needs bash need to be documented (via Depends).

> I'm contrary to essential flags on shells, not because we should remove
> shells from debian systems, but I really think that explicitly
> documenting dependencies is really a good things for us and for
> interoperability.

It sounds more like you're opposed to omitting dependencies on essential
packages in general rather than wanting bash not to be essential.

-- 
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: Please test krb5-config in experimental

[Dominique Dumont]

Sam Hartman  writes:

> Last night I uploaded a more or less rewrite of krb5-config to
> experimental.  The goal of this rewrite is to significantly reduce the
> number of cases where users are asked questions or where the resulting
> configuration is completely wrong.

For what it's worth (knowing that this message may come too late), Peter
Knowles has done some work to create a Kerberos model for Config::Model.

This model (and Config::Model) could help:
- in providing validation for Kerberos config files
- upgrading configuration during package upgrade (see current thread on
  dh_config_model_upgrade)

As a bonus, you would also get a GUI to edit Kerberos config files.  (a
wizard for Config::Model is also planned so users can start a config
from scratch)

That said, I do not know how complere is Kerberos model, or if Peter
still has time to work on it.

Peter, what's the status on Kerberos model ?

All the best
 
-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Guido Günther]

On Fri, Jul 17, 2009 at 06:48:22AM -0400, David Bremner wrote:
[..snip..] 
> At least with topgit, patch branches are meant to be pushed and
> pulled, and use merge rather than rebase for just this reason.  This
> makes the history ugly, but does facilitate the kind of collaboration
> James alluded to. I lost track of what the global point of this
Sure. I think I do understand what James is talking about. It's
basically a matter of taste if you rebase patch branches or use topgit -
both have their up and downsides.
Cheers,
 -- Guido


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

a workflow based on rebasing? (was: RFC: DEP-3: Patch Tagging Guidelines)

[martin f krafft]

also sprach Guido Günther  [2009.07.22.1523 +0200]:
> Sure. I think I do understand what James is talking about. It's
> basically a matter of taste if you rebase patch branches or use
> topgit - both have their up and downsides.

With reference to
http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/2009-May/000616.html,
I'd love to see a detailed account of your workflow. I am failing to
wrap my head around how it would work and would appreciate being
able to learn from you.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"the word yellow wandered through his mind in search of something to
 connect with."
 -- hitchhiker's guide to the galaxy


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge

[Colin Watson]

clone 363250 -1
reassign -1 general
retitle -1 PAGER as a pipeline
tags 363250 fixed-upstream
thanks

On Sun, Apr 23, 2006 at 09:52:34PM +0200, Loïc Minier wrote:
>  Yes, indeed, the root of the problem is the change of support for
>  pipelines.  However, I'm not sure that pipelines worked in the use case
>  of passing a file as a parameter to $PAGER in the past.
> 
>  Currently, each program (for example man) has its way of calling
>  $PAGER, perhaps as "$PAGER " or piping to "sh -c "$PAGER"",
>  or perhaps piping directly to "$PAGER".
> 
>  Of course, if we say $PAGER can be a pipeline, and a pager can be used
>  both as "$PAGER " and as the end of a pipeline, then
>  defining $PAGER to be a pipeline must work in both cases, but I'm not
>  sure it is a regression to not support pipelines in the use case of a
>  file name as argument.
> 
>  In other words:
> 
> $PAGER is a $PAGER is a
> program pipeline
>  
>  call $PAGER as works   ???
>  $PAGER 
>  
>  call $PAGER as
>  cat  | $PAGERworks   works

That last entry is not correct. See below.

>  I do agree that the two use cases that you listed in a previous message
>  exist, I'm not sure they were both supported in the case where $PAGER
>  is a pipeline, but we can work on fixing that at least in
>  sensible-pager by using systematically: cat "$@" | $PAGER

Sorry I took so long to deal with this bug report against man-db. I must
confess that the length of the thread intimidated me a bit!

For the meantime, I note that putting pipes in $PAGER doesn't work even
with sensible-pager, since variable expansion doesn't work that way in
shell:

  $ cat f
  foo
  bar
  $ PAGER='cat | grep bar' sensible-pager f
  cat: |: No such file or directory
  cat: grep: No such file or directory
  cat: bar: No such file or directory
  foo
  bar
  $ PAGER='cat | grep bar' http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_01

I therefore don't think it makes sense to do the not inconsiderable
amount of work required to support pipes-in-$PAGER in man-db when even
sensible-pager can't cope wth it. (The reason it used to work was that
man-db used to be very sloppy about all sorts of things and just passed
stuff to system(); over the last few years I taught it how to handle
pipelined command execution itself, which fixed a wide variety of
interesting bugs. As a result, though, pipes in $PAGER and other things
that man-db interprets stopped being supported.)

For the meantime, I've simply documented the constraints on PAGER and
friends in man(1), and advised the use of a script in such cases:

Tue Jul 21 15:17:49 BST 2009  Colin Watson  

* man/man1/man.man1 (Controlling formatted output, ENVIRONMENT):
  Explicitly state that -P/$PAGER/$MANPAGER identifies a single
  command with no pipes (Debian bug #363250).

If we want to extend PAGER in general, then I'm willing to revisit this.

Cheers,

-- 
Colin Watson   [cjwat...@debian.org]


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

Processed: Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge

[Debian Bug Tracking System]

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

> clone 363250 -1
Bug#363250: please clarify in the man manpage how $PAGER is invoked
Bug 363250 cloned as bug 538022.

> reassign -1 general
Bug#538022: please clarify in the man manpage how $PAGER is invoked
Bug reassigned from package `man-db' to `general'.

> retitle -1 PAGER as a pipeline
Bug#538022: please clarify in the man manpage how $PAGER is invoked
Changed Bug title to `PAGER as a pipeline' from `please clarify in the man 
manpage how $PAGER is invoked'.

> tags 363250 fixed-upstream
Bug#363250: please clarify in the man manpage how $PAGER is invoked
There were no tags set.
Tags added: fixed-upstream

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: Please test krb5-config in experimental

[Sam Hartman]

I'd recommend coordinating any such model with the upstream Kerberos
implementations and with distributions.


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

Essential [Re: Switching /bin/sh to dash (part two)]

[Giacomo A. Catenazzi]

Russ Allbery wrote:

"Giacomo A. Catenazzi"  writes:


Why?
"Always installed" is different to "essential", see e.g. libc.


libc is essential from a Policy perspective.  It's just not marked that
way in the packaging system in case the SONAME changes, but it's essential
in the same way that awk is.  Note that dependencies on awk are not
required (and indeed are a Lintian warning).


No! ;-)  Unfortunately "essential" has two meanings:

- packages which are always required on every Debian system.
  - note: there is also the priority "Required"
  - note: mawk has priority required, it is not essential,
  but an essential package (base-files) predepends on it.

- package who should not be written in the dependency list (but
  on versioned dependencies).

I want to solve this question:
"What packages really depends on bash?"

Note: nine packages depends on mawk, so if we replace mawk with gawk
(a trully virtual example) we know where to test the changes (because
it not essential by the second rule). With bash we don't have such info.

I accept that bash is required on every Debian system, but I would
like to have explicit dependencies on bash.

So for my point of view [weight on second interpretation], mawk, glibc are
not really "essential" package.

But I see your confusion, so I propose a change in policy:
- essential will have only the first meaning
- policy must explicitly enumerate the packages which don't require
  explicit dependencies.
  [for obvious reason these deb should be in the subset of essential or
  essential-like packages]

ciao
cate


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

Re: Essential [Re: Switching /bin/sh to dash (part two)]

[Russ Allbery]

"Giacomo A. Catenazzi"  writes:
> Russ Allbery wrote:

>> libc is essential from a Policy perspective.  It's just not marked that
>> way in the packaging system in case the SONAME changes, but it's
>> essential in the same way that awk is.  Note that dependencies on awk
>> are not required (and indeed are a Lintian warning).

> No! ;-)  Unfortunately "essential" has two meanings:

> - packages which are always required on every Debian system.
>   - note: there is also the priority "Required"

Which is not the same thing.

>   - note: mawk has priority required, it is not essential,
>   but an essential package (base-files) predepends on it.

awk is essential.  Specific awk implementations are not, but the interface
is essential.  This is something that we've discussed many times over the
years and I'm absolutely certain that statement is correct.

> - package who should not be written in the dependency list (but
>   on versioned dependencies).

awk should not be written into the dependency list, because it is
essential.

> I want to solve this question:
> "What packages really depends on bash?"
>
> Note: nine packages depends on mawk,

If they need mawk in particular, they need to depend on it, but if they
just need awk, they should not have a dependency.

> so if we replace mawk with gawk (a trully virtual example) we know where
> to test the changes (because it not essential by the second rule).

Not if you need to check all the packages that depend on awk.

> So for my point of view [weight on second interpretation], mawk, glibc are
> not really "essential" package.

> But I see your confusion, so I propose a change in policy:
> - essential will have only the first meaning
> - policy must explicitly enumerate the packages which don't require
>   explicit dependencies.
>   [for obvious reason these deb should be in the subset of essential or
>   essential-like packages]

I think the best way to resolve the confusion is for you to bring your
internal interpretation of essential in line with the definition the rest
of the project uses.  :)

-- 
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: Essential [Re: Switching /bin/sh to dash (part two)]

[Giacomo A. Catenazzi]

Russ Allbery wrote:

"Giacomo A. Catenazzi"  writes:

Russ Allbery wrote:



libc is essential from a Policy perspective.  It's just not marked that
way in the packaging system in case the SONAME changes, but it's
essential in the same way that awk is.  Note that dependencies on awk
are not required (and indeed are a Lintian warning).



No! ;-)  Unfortunately "essential" has two meanings:



- packages which are always required on every Debian system.
  - note: there is also the priority "Required"


Which is not the same thing.


  - note: mawk has priority required, it is not essential,
  but an essential package (base-files) predepends on it.


awk is essential.  Specific awk implementations are not, but the interface
is essential.  This is something that we've discussed many times over the
years and I'm absolutely certain that statement is correct.


awk is a virtual package, so it could not be essential. Virtual packages
have not package flags.

mawk is alway installed (required and a dependency of an essential package).
mawk provides awk, but mawk is not essential.




- package who should not be written in the dependency list (but
  on versioned dependencies).


awk should not be written into the dependency list, because it is
essential.


not with the "essential flag"


so if we replace mawk with gawk (a trully virtual example) we know where
to test the changes (because it not essential by the second rule).


Not if you need to check all the packages that depend on awk.


hmm. Your sentence is not so good ;-)  Do you mean "depend implicitly"?


I think the best way to resolve the confusion is for you to bring your
internal interpretation of essential in line with the definition the rest
of the project uses.  :)


Maybe. But now you enlarged the interpretation of 3.8 with indirect essential
packages ;-)  "awk" has no explicit "Essential" flag!

ciao
cate


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

Re: Essential [Re: Switching /bin/sh to dash (part two)]

[Russ Allbery]

"Giacomo A. Catenazzi"  writes:
> Russ Allbery wrote:

>> awk is essential.  Specific awk implementations are not, but the
>> interface is essential.  This is something that we've discussed many
>> times over the years and I'm absolutely certain that statement is
>> correct.

> awk is a virtual package, so it could not be essential. Virtual packages
> have not package flags.

I'm not sure what I can say here other than "you're wrong."

-- 
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: Essential [Re: Switching /bin/sh to dash (part two)]

[Sven Joachim]

On 2009-07-22 18:06 +0200, Giacomo A. Catenazzi wrote:

> mawk is alway installed (required and a dependency of an essential package).

Wrong, you can easily remove mawk if you like, as long as you have
another package that provides awk:

,
| % LANG=C aptitude -s remove mawk
| Reading package lists... Done
| Building dependency tree   
| Reading state information... Done
| Reading extended state information  
| Initializing package states... Done
| Reading task descriptions... Done  
| The following packages will be REMOVED:
|   mawk 
| 0 packages upgraded, 0 newly installed, 1 to remove and 22 not upgraded.
| Need to get 0B of archives. After unpacking 233kB will be freed.
| Would download/install/remove packages.
`

But you cannot remove _all_ packages providing awk: 

,
| % LANG=C aptitude -s remove mawk gawk original-awk
| Reading package lists... Done
| Building dependency tree   
| Reading state information... Done
| Reading extended state information  
| Initializing package states... Done
| Reading task descriptions... Done  
| The following packages are BROKEN:
|   base-files dictfmt tla 
| The following packages will be REMOVED:
|   gawk mawk original-awk 
| 0 packages upgraded, 0 newly installed, 3 to remove and 22 not upgraded.
| Need to get 0B of archives. After unpacking 2466kB will be freed.
| The following packages have unmet dependencies:
|   base-files: PreDepends: awk which is a virtual package.
|   tla: Depends: gawk but it is not installable
|   dictfmt: Depends: gawk but it is not installable
| The following actions will resolve these dependencies:
| 
| Keep the following packages at their current version:
| gawk [1:3.1.6.dfsg-3 (unstable, now)]
| 
| Score is -9939
| 
| Accept this solution? [Y/n/q/?] q
| Abandoning all efforts to resolve these dependencies.
| Abort.
`

Sven


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

Re: Intend to create an -fPIC library package...

[Peter Samuelson]

> > 2) Runtime linking.  This is overhead at application startup time.
> >Something that embeds an SQL engine should not, I think, start up too
> >frequently.  Am I wrong?

[Bernd Zeimetz]
> We're talking about amarok here. As a medi aplayer I could imagine it
> will be starte several times per day...

Depends: amarok-common, amarok-engine-xine | amarok-engine-yauap,
unzip, kdelibs4c2a, libc6, libgcc1, libgl1-mesa-glx | libgl1,
libglib2.0-0, libgpod3-nogtk | libgpod3, libifp4, libkarma0,
libmtp7, libmysqlclient15off, libnjb5, libpq5, libqt3-mt,
libruby1.8, libsdl1.2debian, libsqlite3-0, libstdc++6, libtag1c2a,
libtunepimp5, libusb-0.1-4, libvisual-0.4-0

...I don't think the 'startup overhead of a shlib' argument holds up.
-- 
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

Bug#538067: ITP: opencpn -- A concise ChartPlotter/Navigator

[Anton Martchukov]

Package: wnpp
Severity: wishlist
Owner: Anton Martchukov 

* Package name: opencpn
  Version : 1.3.2
  Upstream Author : David Register 
* URL : http://opencpn.sourceforge.net/
* License : GPL
  Programming Lang: C/C++
  Description : A concise ChartPlotter/Navigator

A cross-platform ship-borne GUI application supporting 

* GPS/GPDS Postition Input 
* BSB Raster Chart Display
* S57 Vector ENChart Display
* AIS Input Decoding
* Waypoint Autopilot Navigation



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

Re: Intend to create an -fPIC library package...

[Cyril Brulebois]

Raphael Hertzog  (22/07/2009):
> Yes. Check "man dpkg-gensymbols" and see how some nice tools
> […propaganda…]

FSVO “nice”. #536034.

In case a maintainer of a shared lib never did this, I strongly advise
playing around with a simple combo of diff, find, and nm, in order to
have a look at what symbols are becoming between two releases.

I always thought it was something *needed* so that depending packages
don't suddenly stop working. But oh well.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: The wider implications of debhelper/dbus breakage

[Cyril Brulebois]

Raphael Hertzog  (17/07/2009):
> At least dpkg-dev has one and it's run at build-time.

I thought the goal of dpkg-dev was to actually build other packages. I
don't know how dpkg-dev developers see this, but maybe having a few
packages rebuilt using the new dpkg-dev package would help spotting
breakages? I dunno, but especially eglibc and other important packages
would be quite good candidates. I guess that a loop for getting the
source packages, pushing them through sbuild once with the old dpkg-dev
package and once with the new dpkg-dev packages, then debdiffing (and
whatever interesting diff tests might come to mind) would help and
wouldn't be very hard to implement.

That also holds for debhelper, cdbs, .

> Of course the test was added when the bug got fixed (we're speaking of
> #536034 for those wondering).

I know. Guess what, I checked the facts. ;p

> Speaking for dpkg-dev, any help is always welcome to enhance the
> test-suite but it's a huge job that is not so rewarding.

See above for a trivial idea.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: [config-model-users] Please test krb5-config in experimental

[Peter Knowles]

"Dominique Dumont"  writes:

> That said, I do not know how complere is Kerberos model, or if Peter
> still has time to work on it.
>
> Peter, what's the status on Kerberos model ?

The model was pretty much 100% complete and had been well tested on my
box. However, I ran out of free time to work on this, so I never got
around to implementing the suggestions that you made back in September
2008 (i.e the fix for the 'experienced' typo in
models/Krb5/Logging/LoggingConfig.pl, as well as simplifying some of those
fetches):

http://sourceforge.net/mailarchive/message.php?msg_name=kgiod34qgkv.fsf%40komarr.gre.hp.com

Regards,
Peter



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

plz add

[simi angels]

Hello Dear

   PLz add mu new email id for the link excahnge,i have
lot of good sites

simi.ang...@gmail.com



Thanks