Re: Not stopping daemons, where are we?

[Steve Langasek]

On Wed, Jul 02, 2008 at 04:36:56PM -0400, Joe Smith wrote:

>> Either I don't understand the usage scenario you are talking about, or I
>> misunderstand what is being proposed in this thread, or you
>> misunderstand what is being proposed in this thread.  Here is a more
>> concrete example of a situation based on what I think is being proposed:

>> The Debian maintainer for a specific VPN decides it does not need
>> special shutdown handling, so he marks it to not require calling
>> "/etc/init.d/SuperVPN stop" when doing a shutdown or reboot.  This is
>> what I understand this thread is about.  This will result in SuperVPN
>> not being stopped until the final "kill all remaining processes" step of
>> the halt or reboot (i.e. don't waste time shutting this daemon down
>> cleanly, let it die abruptly just before halting).

> Well, sending SIGTERM should not cause software to die abruptly, and IIRC 
> sending SIGTERM to all processes happens before sending SIGKILL.

The point is that this new proposal applies only to services whose
maintainers decide they do *not* need graceful handling.  If you have
another process that does need a graceful shutdown, it's only ever been
guaranteed if you give that process a shutdown script with the right
sequence number, and *all* such shutdown scripts are run *before* the
killall5 is sent.

If something depends on a particular /other/ service to be shut down
gracefully, and this hasn't been coordinated with the package providing the
service, then that something is broken by design.  Shooting it in the head
is a feature.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

[Andreas Tille]

On Thu, 3 Jul 2008, Lars Wirzenius wrote:


to, 2008-07-03 kello 08:24 +0200, Andreas Tille kirjoitti:

/me as a completely uneducated apt / aptitude user thinks: Triggers have
done more harm than good.


I haven't been following trigger adoption very much, so I'm ignorant:
what harm have triggers done?


It slows down apt-get / aptitude by calling update-menus / update-mandb
for every package that drops a file into this directory.  I have not done
measures whether the installation time with and without triggers is
really different (perhaps there are some other means of optimisation
done) but the user reads much more lines about things that are done when
calling apt which is annoing and leaves open questions for the user.
This is bad.

I reported another problem at

http://lists.debian.org/debian-devel/2008/06/msg00117.html

which was in principle easy to circumvent, but I did not got an
answer to my later question in this thread

http://lists.debian.org/debian-devel/2008/06/msg00132.html

where I wanted to know whether there is some means to obtain a
return code of update-menus about the reasons of the failure.  So
my script has no chance to differentiate between a real problem in
the installation (really missing config file) or a problem that
was caused by an (IMHO unnecessary and boring) call because of
the trigger feature.

Kind regards

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bug closed by $p4m mail?

[Johannes Wiedersich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2008-07-03 08:58, Lars Wirzenius wrote:
> For unarchiving and un-closing, use the control bot
> ([EMAIL PROTECTED]).

I didn't know about the 'unarchive' command.

Thanks, everything is fine now!

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

iD8DBQFIbID1C1NzPRl9qEURAqDHAJ9h5YQ2FdDF8wqctIx2hTMEHNYdIgCeLTmf
AM6xJ/wC2afoULe1DF3A7RU=
=5zgW
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#489132: lenny release notes, upgrade dpkg first

[Raphael Hertzog]

Package: release-notes
Severity: important

To work-around a problem that can happen in the perl 5.10 upgrade (see
#479711), the perl scripts contained in dpkg (update-alternatives,
dpkg-divert) have been modified... but for the work-around to be used, the
new dpkg must obviously be installed first, before the dist-upgrade.

Given that the new dpkg also supports triggers, we should probably also
recommend to upgrade apt/aptitude at the same time otherwise those tools
might be confused by the new package status...

X-Debbugs-Ccing [EMAIL PROTECTED] and -devel for possible comments (-dpkg left
out as it discards BTS mails).

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

buildd path name length

[Florian Weimer]

Suppose that a package wants to create a UNIX domain socket as part of
its test suite.  If the socket is created within the package build
directory, this might fail because of the quite low path name length
limit.  What is the correct way of dealing with this?  "mktemp -d" uses
TMPDIR, which is potentially affected by the same issue.

(My personal opinion is "fix the buildd", especially since none of the
official buildds seems to use long path names, but there is
disagreement.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd path name length

[Simon Josefsson]

Florian Weimer <[EMAIL PROTECTED]> writes:

> Suppose that a package wants to create a UNIX domain socket as part of
> its test suite.  If the socket is created within the package build
> directory, this might fail because of the quite low path name length
> limit.  What is the correct way of dealing with this?  "mktemp -d" uses
> TMPDIR, which is potentially affected by the same issue.
>
> (My personal opinion is "fix the buildd", especially since none of the
> official buildds seems to use long path names, but there is
> disagreement.)

Can't the low path name length limit be fixed?  What restricts the
length?  Kernel, libc, filesystem, ...?

/Simon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd path name length

[Florian Weimer]

* Simon Josefsson:

>> Suppose that a package wants to create a UNIX domain socket as part of
>> its test suite.  If the socket is created within the package build
>> directory, this might fail because of the quite low path name length
>> limit.  What is the correct way of dealing with this?  "mktemp -d" uses
>> TMPDIR, which is potentially affected by the same issue.
>>
>> (My personal opinion is "fix the buildd", especially since none of the
>> official buildds seems to use long path names, but there is
>> disagreement.)
>
> Can't the low path name length limit be fixed?  What restricts the
> length?  Kernel, libc, filesystem, ...?

It's part of the API:

  /* Structure describing the address of an AF_LOCAL (aka AF_UNIX)
  socket.  */
  struct sockaddr_un
{
  __SOCKADDR_COMMON (sun_);
  char sun_path[108]; /* Path name.  */
};


I haven't checked if the Linux kernel actually cares about the actually
length of this data structure (there are explicit length fields in all
cases), but I guess it should work.  However, this might not be portable
to the Hurd or kfreebsd.

In a larger context, there is sockaddr_storage, which indirectly imposes
a limit (because getpeername must complete when passed a
sockaddr_storage argument, for instance).  Overlong UNIX domain sockets
might break some libraries that rely on that functionality.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#489145: ITP: libgit-fastexport-perl -- A module to parse the output of git-fast-export

[Edi Stojicevic]

Package: wnpp
Severity: wishlist
Owner: Edi Stojicevic <[EMAIL PROTECTED]>


* Package name: libgit-fastexport-perl
  Version : 0.01
  Upstream Author : Philippe 'Book' Bruat  <[EMAIL PROTECTED]>
* URL : 
http://search.cpan.org/dist/Git-FastExport-0.01/lib/Git/FastExport.pm
* License : GPL
  Programming Lang: Perl
  Description : A module to parse the output of git-fast-export

Git::FastExport is a module that parses the output of git-fast-export and 
returns
Git::FastExport::Block objects that can be inspected or modified before being 
eventually passed on
as the input to git-fast-import.

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

Kernel: Linux 2.6.25-2-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Not stopping daemons, where are we?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> The Debian maintainer for a specific VPN decides it does not need
> special shutdown handling

Nono, thats not my point. My point is, that a maintainer of any package
cannot easyly forsee which part of the system he is using (resolver, pam,
proxy, ..) might depend on a daemon - at a specific user's installation.

The downside might be regular unexpected errors at shutdown like "host not
found". Those should be catched/ignored, but you never know.

This might not be a problem (because I also dont have real examples) but,
then again - its good to talk about it.

Gruss
Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#489059: ITP: mnemosyne-blog -- Maildir-to-blog compiler with XML templating and Python extensions

[Decklin Foster]

Ben Finney writes:

> I'd advise the name "mnemosyne-weblog" which is slightly less
> jargonny.

Hmm. While I don't want to dismiss this out of hand, I feel much more
natural saying "blog" myself. As a crude approximation of current usage,
here are the current numbers of google hits for:

  "weblog" - 184,000,000
  "blog" - 3,530,000,000

Additionally, the first hit for "weblog" is the wikipedia article for
"Blog" (the article for "Weblog" is a redirect to this article). IMO the
short form has passed into common enough usage that I would consider it
appropriate. Of course I wouldn't consider "weblog" *in*appropriate, if
upstream had a preference for that. I am my own upstream here, so I can
rule that one out :)

-- 
things change.
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#489164: ITP: jaranalyzer -- A Dependency management utility for jar files.

[Florian Grandel]

Package: wnpp
Severity: wishlist
Owner: Florian Grandel <[EMAIL PROTECTED]>


* Package name: jaranalyzer
  Version : 1.2
  Upstream Author : Kirk Knoernschild <[EMAIL PROTECTED]> (remove the _filter)
* URL : http://www.kirkk.com/main/Main/JarAnalyzer
* License : non-standard FOSS (see license.txt)
  Programming Lang: Java
  Description : A Dependency management utility for jar files.

JarAnalyzer's primary purpose is to traverse through a directory,
parse each of the jar files in that directory, and identify the
dependencies between the jar files. The output is an xml file
representing the PhysicalDependencies between the jar files.

-- System Information:
n/a



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

upgrade problems switching from conflictiong to depending packages

[Andreas Metzler]

Hello,

I found this when trying to solve #369386. There seems to be a problem
when trying to go from two conflicting packages to a dummy package and
the prefered one:

Before:
Package: lynx
Version: 2.8.6-2.1
Conflicts: lynx-cur

Package: lynx-cur
Version: 2.8.7dev9-1
Conflicts: lynx

After:
Package: lynx
# dummy packge
Version: 2.8.7dev9-1.1
Depends: lynx-cur (>=  2.8.7dev9-1.1)

Package: lynx-cur
Version: 2.8.7dev9-1.1
Conflicts: lynx (<<  2.8.7dev9-1.1)

If you start with lynx installed and lynx-cur uninstalled but not
purged and run a dist-upgrade, the following happens:

1. apt runs dpkg -u lynx_newversion.deb
2. apt runs dpkg -u lynx-cur_newversion.deb
---
This fails with:
dpkg: regarding .../lynx-cur_2.8.7dev9-1.1_i386.deb containing lynx-cur:
 lynx-cur conflicts with lynx
  lynx (version 2.8.7dev9-1.1) is present and unpacked but not configured.
dpkg: error processing /tmp/lynx-apt/./lynx-cur_2.8.7dev9-1.1_i386.deb 
(--unpack):
---

The reason is simple to see, dpkg's status file now contains this:
Package: lynx
Depends: lynx-cur (>=  2.8.7dev9-1.1)
Version: 2.8.7dev9-1.1
Status: install ok unpacked

Package: lynx-cur
Version: 2.8.7dev9-1
Conflicts: lynx
Status: install ok config-files

Dpkg now seems to use this dependency/conflict info instead of the one
in the new package version. I *think* this is a bug in dpkg. The status
we are in dependency-wise before running 2. is perfectly fine,
conflicts to not hit for uninstalled (config-files) packages. The
status we would have after installing the new version of lynx-cur
would be fine too, since the new conflict is versioned.

Anyway what should I do?
* Is this a bug in dpkg?
* What is the workaround? I actually think my dependencies are correct and 
don't think there is lot I *could* to change.

The behavior is easy to reproduce:
apt-get install lynx-cur=2.8.7dev9-1  ; apt-get install lynx=2.8.6-2.1
dist-upgrade to the packages on http://www.bebt.de/debian/lynx-cur/

thanks, cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#489169: ITP: bzr-git -- Bazaar readonly support for Git repositories

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: bzr-git
  Version : 0.0.1
  Upstream Author : David Allouche <[EMAIL PROTECTED]>
Aaron Bentley <[EMAIL PROTECTED]>
John Arbash Meinel <[EMAIL PROTECTED]>
Jelmer Vernooij <[EMAIL PROTECTED]>
James Westby <[EMAIL PROTECTED]>
Robert Collins <[EMAIL PROTECTED]>
* URL : http://bazaar-vcs.org/BzrForeignBranches/Git
* License : GPL v2 or later
  Programming Lang: Python
  Description : Bazaar readonly support for Git repositories

This is a simple plugin for Bazaar that allows it to inspect the history
of the head of git repositories. 

- -- System Information:
Debian Release: lenny/sid
  APT prefers gutsy
  APT policy: (500, 'gutsy'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

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

iJwEAQECAAYFAkhtCtAACgkQDLQl4QYPZuXoUwP/Smah/3YB0BfKGOoz0AhTNym8
tWv6l02T0Ix8ccviU91T/fJTaLsxJdjkxRMwZlq2rKcTVXj2onA/u+EHsYaSmaPD
43oXS7AC4ml7hcPfKNcfH+0dHWXBfXmeHNfYteWUDV00z1G7EFf9a9mzbCbmkIFi
lETiSP0Y0vzr++5LLMA=
=4zCw
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#489132: lenny release notes, upgrade dpkg first

[Holger Levsen]

Hi,

On Thursday 03 July 2008 12:25, Raphael Hertzog wrote:
> Given that the new dpkg also supports triggers, we should probably also
> recommend to upgrade apt/aptitude at the same time otherwise those tools
> might be confused by the new package status...

#464559 (in apt) is also a problem for etch to sid/lenny upgrades, so IMHO 
this is a sensible idea anyway...


regards,
Holger


pgpjzR33N9uk5.pgp
Description: PGP signature

Perl symbol problem - release critical (Re: Bug#489132)

[Ian Jackson]

Raphael Hertzog writes ("Bug#489132: lenny release notes, upgrade dpkg first"):
> To work-around a problem that can happen in the perl 5.10 upgrade (see
> #479711), the perl scripts contained in dpkg (update-alternatives,
> dpkg-divert) have been modified... but for the work-around to be used, the
> new dpkg must obviously be installed first, before the dist-upgrade.

I don't think this is the right solution.  To be honest I'm just
astonished at this situation, which is terrible.  It is the
consequence of a mistake in the Debian Perl policy - a mistake which
has caused trouble on every previous upgrade, too.


Here is a summary of the problem:

  Perl extensions (XS modules) are not compatible across Perl versions
  due to ABI changes.  For this reason Perl upstream put the Perl
  version number in the paths at which modules are installed.  The
  Debian Perl maintainer has decided not to do this.

  As a result, if you try to load a Perl extension from a script when
  the versions of the Perl interpreter (in perl-base) and the module
  (in a different package) are incompatible, you are trying to load a
  library .so with an incompatible ABI.

  As it happens, because of lazy symbol resolution, this is detected
  very late: after Perl thinks it has loaded the module, the runtime
  linker finds a missing symbol and has no option but to kill the
  process.

  (If it weren't for that, then loading the library would fail; the
  Essential scripts which are trying to load the module will then fall
  back, so the system would remain functional in a basic way and could
  recover.)

  As a result, it is possible for a situation to arise where Essential
  scripts in the dpkg package (and presumably in other packages) don't
  work, without any of the dependencies having been violated.  Unless
  you're an expert, once your system is in this state you're hosed.


Some observations and opinions:

* This problem is clearly release critical.  I don't think documenting
  a release critical bug of this severity in the release notes is
  acceptable.  Furthermore, the proposed workaround is very cumbersome
  due to the necessary installation ordering.

* The Debian Perl maintainer's decision to remove the Perl version
  number from the module path is clearly wrong.  Here is what upstream
  have to say, and the Debian Perl maintainer's explanation:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479711#85
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479711#120
  This explanation is basically that `Debian's dependency system
  means that it will work anyway'.  This is
(a) not a reason to deviate from upstream - at best it is only a
lack of a reason not to deviate;
(b) false.
  That it is false can be seen from the fact that a problem like this
  has happened for the last three releases: #158835, #278417,
  and now #479711.  (There may be other reports of course.)

* Suppressing lazy symbol resolution may work in this case, but it is
  not correct.  ABI changes may result in random crashes due to
  different structure sizes and do not necessarily involve missing
  symbols - so the problem may go undetected.  If we think that we
  want to fix it in etch->lenny by suppressing lazy symbol resolution,
  we need to:
(a) check what the actual ABI differences are and that either
there aren't any others besides missing symbols, or that
every module will definitely fail to load
(b) regard this as a workaround and do something sensible next
time.

* One of the Perl upstream commenters in #479711 suggests that the
  answer is to use a `pre-inst dependency' which apparently none of
  the submitters have realised is what dpkg already has and calls
  Pre-Depends.  However, a Pre-Depends doesn't solve this problem
  because there is no correct order to upgrade the packages:
  regardless of whether you upgrade Perl first, or the modules first,
  something may break.

* The fundamental problem is that there are currently some Perl
  module packages in lenny which whose dependencies are not violated
  by unpacking them into an etch system, but which will break the
  execution of essential packages.  This definitely cannot be fixed
  without changing at least those Perl module packages (because
  an etch system will be willing to install the broken Perl module
  packages right now, and the only thing currently stopping it doing
  so is that lenny isn't released).


Possible solutions that I see for lenny:

1. Reinsert the Perl version number in the Perl module packages.
   This is the correct long-term solution but involves at least
   rebuilding about 300 packages.

2. Find out which modules are used in this way by Essential packages.
   Arrange somehow for those modules to fail at `require' when loaded
   with Perl 5.8 from etch.  This might involve rebuilding only
   those modules.

3. Make the lenny Perl 5.10 package _also_ look in the directory with
   5.10 in the name.  Change the m

Re: Perl symbol problem - release critical (Re: Bug#489132)

[Don Armstrong]

On Thu, 03 Jul 2008, Ian Jackson wrote:
> * Suppressing lazy symbol resolution may work in this case, but it
>   is not correct.

Lazy symbol resolution should be supressed while in eval regardless of
the method which we use to resolve this problem. Non-recoverable
failures from code in eval should be minimized to the extent possible.

While there are other API/ABI differences that may not be caught,
catching the obvious ones is better than catching none at all.


Don Armstrong

-- 
Love is... a complex sequence of neurochemical reactions that makes
people behave like idiots. It's similar to intoxication, but the
hangover's even worse.
 -- J. Jacques _Questionable Content_ #1039
http://www.questionablecontent.net/view.php?comic=1039

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Not stopping daemons, where are we?

[Marvin Renich]

* Bernd Eckenfels <[EMAIL PROTECTED]> [080703 09:57]:
> In article <[EMAIL PROTECTED]> you wrote:
> > The Debian maintainer for a specific VPN decides it does not need
> > special shutdown handling
> 
> Nono, thats not my point. My point is, that a maintainer of any package
> cannot easyly forsee which part of the system he is using (resolver, pam,
> proxy, ..) might depend on a daemon - at a specific user's installation.
> 
> The downside might be regular unexpected errors at shutdown like "host not
> found". Those should be catched/ignored, but you never know.
> 
> This might not be a problem (because I also dont have real examples) but,
> then again - its good to talk about it.
> 
> Gruss
> Bernd
> 

If you are saying that the maintainer of SuperVPN, who is trying to
decide whether or not to mark his package as "use killall5 instead of
the initscript when halting", may not know whether certain services used
by the package are provided by daemons that may have already shut down,
my answer is that the maintainer most likely does (and should) know
that, but it is irrelevant.

The relevant question (pertaining to how other packages affect the
"quick halt" option of this package) is, "if services that might be
needed by this package are shut down between the time the sysadmin asks
for a halt and the time this package actually exits, will it adversely
affect user or sysadmin data?"  That is, does the package need to save
some data or state to disk (or to another daemon), and are certain
daemons needed for that purpose?

If the package is not trying to save any state, it doesn't matter that
the package normally queries a DNS server that might not respond; the
sysadmin has already said to shut down.

If the package does need to save state, don't enable the "quick halt"
option!  The maintainer definitely ought to know this.

A caching DNS server is an example of a daemon that might very well
benefit from the "quick halt" option.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs)

[Raphael Hertzog]

(Cc -devel to seek input)

On Thu, 31 May 2007, Iñaki Baz Castillo wrote:
> Acording to the LSB specifications for init scripts [1]:
> 
> "For all other init-script actions, the init script shall return an exit
> status of zero if the action was successful. Otherwise, the exit status
> shall be non-zero, as defined below. In addition to straightforward
> success, the following situations are also to be considered successful: 
> - Restarting a service (instead of reloading it) with the force-reload
> argument
> - Running start on a service already running
> - Running stop on a service already stopped or not running
> - Running restart on a service already stopped or not running
> - Running try-restart on a service already stopped or not running"
> 
> So if I start a service that is already running I should receive 0, but
> "start-stop-daemon" returns 1 (error).
> 
> The option "--oknodo" changes the behaviour to the LSB recomendations but many
> services in Debian don't use this option and return 1 in the case I've
> quotted. This is very problematic for me when I try to use a Debian
> service init script with HeartBeat that expects to receive a 0.

I'm reluctant to change the default behaviour of start-stop-daemon at this
point. What do other people think of making --oknodo the default behaviour
and adding a new option to force the current default behaviour (exit with
failure if nothing had to be done)?

The alternative is to change policy and/or lintian to ensure that packages
are using --oknodo unless they have a good reason not to.

> [1] LSB specifications about init script actions:
> http://www.linux-foundation.org/spec/refspecs/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#489132: lenny release notes, upgrade dpkg first

[Raphael Hertzog]

On Thu, 03 Jul 2008, Bryan Donlan wrote:
> On Thu, Jul 3, 2008 at 6:25 AM, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> > Package: release-notes
> > Severity: important
> >
> > To work-around a problem that can happen in the perl 5.10 upgrade (see
> > #479711), the perl scripts contained in dpkg (update-alternatives,
> > dpkg-divert) have been modified... but for the work-around to be used, the
> > new dpkg must obviously be installed first, before the dist-upgrade.
> >
> > Given that the new dpkg also supports triggers, we should probably also
> > recommend to upgrade apt/aptitude at the same time otherwise those tools
> > might be confused by the new package status...
> 
> Would it be better to just set pre-depends on the appropriate version
> of dpkg in perl? That ought to ensure they are upgraded in the correct
> order, even for people who don't read the release notes :)

Hum, this might be possible indeed. We don't like frequent use of
Pre-Depends but this one might be justifiable. Ccing -devel for comments
and [EMAIL PROTECTED] as they'd have to do it.

I'd like to also note that dpkg conflicts with the old version of
apt/aptitude, so this will also force the upgrade of apt/aptitude.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Perl symbol problem - release critical (Re: Bug#489132)

[Raphael Hertzog]

On Thu, 03 Jul 2008, Ian Jackson wrote:
> Here is a summary of the problem:

FWIW, the summary is right according to my understanding.

> * This problem is clearly release critical.  I don't think documenting
>   a release critical bug of this severity in the release notes is
>   acceptable.  Furthermore, the proposed workaround is very cumbersome
>   due to the necessary installation ordering.

It's clearly release critical but doesn't necessarily happen on all
upgrades. It depends if update-alternatives/dpkg-divert is called
between the liblocale-gettext-perl and perl-base unpack.

> * The Debian Perl maintainer's decision to remove the Perl version
>   number from the module path is clearly wrong.  Here is what upstream
>   have to say, and the Debian Perl maintainer's explanation:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479711#85
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479711#120
>   This explanation is basically that `Debian's dependency system
>   means that it will work anyway'.  This is
> (a) not a reason to deviate from upstream - at best it is only a
> lack of a reason not to deviate;
> (b) false.
>   That it is false can be seen from the fact that a problem like this
>   has happened for the last three releases: #158835, #278417,
>   and now #479711.  (There may be other reports of course.)

The problem AIUI is that perl upstream doesn't guaranty ABI stability for
any major release. It might be that all 5.8.x are ABI compatible but it's
not guaranteed. That's why the dependency system includes the full version
in its virtual package (Provides: perlapi-5.10.0 in perl-base). The binary
package get a dependency on the perl version used for the build. Every new
upstream release of perl-base includes the various perlapi-* that it is
compatible with.

It would be a pain to use versioned directories as all perl modules would
have to be rebuilt for each perl release, even if they are ABI compatible.
Simply adding old directories of compatible in the include path is not
very nice... you'll get modules spread over multiple directories.

In general a package offers no guaranty to be functionnal until it is
successfully configured... so the perl module rely on this assumption.
The problem is that some of the non-core modules are used by part of our
essential infrastructure. Locale::gettext is the most important one.
Any script using this module is potentially broken when called in
some preinst script.

In the case of Dpkg, the scripts have been written with this in mind and
tried to use a construct to fallback to a reasonable default behaviour
(with i18n disabled) but this doesn't work for the reasons explained (lazy
symbol resolution).

> * Suppressing lazy symbol resolution may work in this case, but it is
>   not correct.  ABI changes may result in random crashes due to
>   different structure sizes and do not necessarily involve missing
>   symbols - so the problem may go undetected.  If we think that we
>   want to fix it in etch->lenny by suppressing lazy symbol resolution,
>   we need to:
> (a) check what the actual ABI differences are and that either
> there aren't any others besides missing symbols, or that
> every module will definitely fail to load
> (b) regard this as a workaround and do something sensible next
> time.

I leave that to perl maintainers. :)

> * One of the Perl upstream commenters in #479711 suggests that the
>   answer is to use a `pre-inst dependency' which apparently none of
>   the submitters have realised is what dpkg already has and calls
>   Pre-Depends.  However, a Pre-Depends doesn't solve this problem
>   because there is no correct order to upgrade the packages:
>   regardless of whether you upgrade Perl first, or the modules first,
>   something may break.

This is why I suggested to integrate liblocale-gettext-perl in perl-base
itself. This would be the simplest/nicest solution IMO. It would always be
synchronized with the current perl.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479681

Unfortunately, it has not been considered yet. :-(

> * The fundamental problem is that there are currently some Perl
>   module packages in lenny which whose dependencies are not violated
>   by unpacking them into an etch system, but which will break the
>   execution of essential packages.

They are violated!

$ dpkg -s liblocale-gettext-perl | grep Depends
Depends: libc6 (>= 2.7-1)
Pre-Depends: perl-base (>= 5.10.0-9), perlapi-5.10.0

There's no way for this to be satisfied in etch. But
somehow you must break the package temporarily:
- either you unpack perl-base first, and it doesn't provide the
  perlapi-5.8.x that the old liblocale-gettext-perl require
- or you unpack liblocale-gettext-perl first, and its perlapi-5.10.0
  dependency is not yet satisfied until the new perl-base is
  installed

>   This definitely cannot be fixed
>   without changing at least those Perl module packages (becau

Re: Bug#489132: lenny release notes, upgrade dpkg first

[Luk Claes]

Raphael Hertzog wrote:
> On Thu, 03 Jul 2008, Bryan Donlan wrote:
>> On Thu, Jul 3, 2008 at 6:25 AM, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
>>> Package: release-notes
>>> Severity: important
>>>
>>> To work-around a problem that can happen in the perl 5.10 upgrade (see
>>> #479711), the perl scripts contained in dpkg (update-alternatives,
>>> dpkg-divert) have been modified... but for the work-around to be used, the
>>> new dpkg must obviously be installed first, before the dist-upgrade.
>>>
>>> Given that the new dpkg also supports triggers, we should probably also
>>> recommend to upgrade apt/aptitude at the same time otherwise those tools
>>> might be confused by the new package status...
>> Would it be better to just set pre-depends on the appropriate version
>> of dpkg in perl? That ought to ensure they are upgraded in the correct
>> order, even for people who don't read the release notes :)
> 
> Hum, this might be possible indeed. We don't like frequent use of
> Pre-Depends but this one might be justifiable. Ccing -devel for comments
> and [EMAIL PROTECTED] as they'd have to do it.
> 
> I'd like to also note that dpkg conflicts with the old version of
> apt/aptitude, so this will also force the upgrade of apt/aptitude.

Requiring from everyone wanting to upgrade to first manually upgrade
dpkg (and apt/aptitude) should be avoided if possible.

If the Pre-Depends will not break anything in whatever scenario it's
definitely preferred.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

[Gunnar Wolf]

Andreas Tille dijo [Thu, Jul 03, 2008 at 09:24:32AM +0200]:
> >I haven't been following trigger adoption very much, so I'm ignorant:
> >what harm have triggers done?
> 
> It slows down apt-get / aptitude by calling update-menus / update-mandb
> for every package that drops a file into this directory.  I have not done
> measures whether the installation time with and without triggers is
> really different (perhaps there are some other means of optimisation
> done) but the user reads much more lines about things that are done when
> calling apt which is annoing and leaves open questions for the user.
> This is bad.

Well, calling them once after every package modified its bits, instead
of each of them calling them without explicitly notifying you. So,
it's perceived as a longer time, but you didn't measure all the time
saved by _not_ calling it.

> I reported another problem at
> 
> http://lists.debian.org/debian-devel/2008/06/msg00117.html
> 
> which was in principle easy to circumvent, but I did not got an
> answer to my later question in this thread
> 
> http://lists.debian.org/debian-devel/2008/06/msg00132.html
> 
> where I wanted to know whether there is some means to obtain a
> return code of update-menus about the reasons of the failure.  So
> my script has no chance to differentiate between a real problem in
> the installation (really missing config file) or a problem that
> was caused by an (IMHO unnecessary and boring) call because of
> the trigger feature.

This, however, is an interesting point to work on - Of course, it
should be fixed by making more robust the processes that are
triggered, not by removing a feature by labelling it as a bug!

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Boletines Oficiales

[Ana Gil Barrenechea]

Hola,

Somos un grupo de ingenieros que hemos puesto en marcha el primer 
buscador libre de boletines oficiales.
Simplemente por si pensais que puede ser de interés y quereis colaborar 
poniendo un link a www.iboof.com en vuestra página.

Saludos cordiales,

Ana Gil Barrenechea
Ingeniera Desarrollo
www.iboof.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Perl symbol problem - release critical (Re: Bug#489132)

[Brendan O'Dea]

On Fri, Jul 4, 2008 at 6:17 AM, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> This is why I suggested to integrate liblocale-gettext-perl in perl-base
> itself. This would be the simplest/nicest solution IMO. It would always be
> synchronized with the current perl.
>
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479681

I'm inclined at this point to follow this suggestion.

--bod


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs)

[Iñaki Baz Castillo]

El Jueves, 3 de Julio de 2008, Raphael Hertzog escribió:

> I'm reluctant to change the default behaviour of start-stop-daemon at this
> point. What do other people think of making --oknodo the default behaviour
> and adding a new option to force the current default behaviour (exit with
> failure if nothing had to be done)?
>
> The alternative is to change policy and/or lintian to ensure that packages
> are using --oknodo unless they have a good reason not to.
>
> > [1] LSB specifications about init script actions:
> > http://www.linux-foundation.org/spec/refspecs/LSB_3.0.0/LSB-Core-generic/
> >LSB-Core-generic/iniscrptact.html

I think being LSB compliant is good for Debian.

Also, sincerely I think nobody gives importance to the return code of init 
scripts ("1" in case of starting an already started service) because most of 
people start services manually or they are started when the system swithes 
on, so return code is not so important.

But in case of service daemon (as HeartBeat that handles when to start or stop 
a service) these return code becomes important and being LSB compliant is, 
IMHO, the best way.

Just my opinion. Regards.


-- 
Iñaki Baz Castillo


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP: password -- little ruby random password generator

[Ryan Kavanagh]

Package: wnpp
Severity: wishlist
Owner: Ryan Kavanagh <[EMAIL PROTECTED]>


* Package name: password
  Version : 2007.12.30
  Upstream Author : Joakim Olsson <[EMAIL PROTECTED]>
* URL : http://lirhost.net/~jocke/password/
* License : GPL
  Programming Lang: Ruby
  Description : Compact ruby random password generator

Little random password generator which generates a random
password which is strong, safe and secure.

-- System Information:
Debian Release: lenny/sid
  APT prefers hardy-updates
  APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 
'hardy-backports'), (500, 'hardy')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-18-generic (SMP w/1 CPU core)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.UTF-8)
Shell: /bin/sh linked to /bin/dash


signature.asc
Description: Digital signature

Re: ITP: password -- little ruby random password generator

[Russ Allbery]

Ryan Kavanagh <[EMAIL PROTECTED]> writes:

> Package: wnpp
> Severity: wishlist
> Owner: Ryan Kavanagh <[EMAIL PROTECTED]>
>
> * Package name: password

That's a very generic package name and should probably say *something*
about how it's a random password generator.

>   Version : 2007.12.30
>   Upstream Author : Joakim Olsson <[EMAIL PROTECTED]>
> * URL : http://lirhost.net/~jocke/password/
> * License : GPL
>   Programming Lang: Ruby
>   Description : Compact ruby random password generator
>
> Little random password generator which generates a random
> password which is strong, safe and secure.

How does this differ from all the random password generators already in
Debian?  Why would I use this instead of one of:

apg - Automated Password Generator - Standalone version
funcoeszz - script with 65 useful mini applications
gpw - Trigraph Password Generator
libpam-pwgen - a password generator
libstring-mkpasswd-perl - random password generator

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Converting to source format "3.0 (quilt)" (was: Misc developer news (#9))

[Ben Finney]

[Followup on debian-devel, instead of debian-devel-announce. Raphael,
did you intentionally set Mail-Followup-To to debian-devel-announce or
was that an oversight?]

Raphael Hertzog <[EMAIL PROTECTED]> writes:

> Advice on quilt usage and compatibility with new source format

Thanks very much for this work and the resulting guidelines. It is
good to have information on using and transitioning to this new
format.

>  To prepare a future switch to the "3.0 (quilt)" source package format, I
>  tried to convert the whole archive and to rebuild the packages
>  afterwards.

What does this mean; what is it that you did? I don't quite know how
you "convert the whole archive" automatically to this new format,
unless you mean that packages which didn't use quilt are simply using
an empty patch set.

>  This resulted in lots of improvements on dpkg-source as I adapted
>  the code to make it support many of the existing build setups

Good result, thanks.

>  To ensure compatibility with the new source format, please try to
>  follow the guidelines below.

Thanks again for writing these.

-- 
 \  “Pinky, are you pondering what I'm pondering?” “Yes Brain, but |
  `\if our knees bent the other way, how would we ride a bicycle?” |
_o__)   —_Pinky and The Brain_ |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ITP: password -- little ruby random password generator

[Paul Wise]

On Fri, Jul 4, 2008 at 11:05 AM, Ryan Kavanagh <[EMAIL PROTECTED]> wrote:

> * Package name: password
>  Description : Compact ruby random password generator
>
> Little random password generator which generates a random
> password which is strong, safe and secure.

pwgen already exists.

Also, please use X-Debbugs-CC in future. It can also be used as a
pseudo-header if your MUA doesn't have the ability to add arbitrary
headers.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Multiarch and idea for improved diversions and alternatives handling

[Neil Williams]

On Tue, 2008-07-01 at 18:44 +0200, Goswin von Brederlow wrote:
> James Vega <[EMAIL PROTECTED]> writes:
> 
> > On Sat, Jun 28, 2008 at 02:03:05AM -0700, Steve Langasek wrote:
> >> So if we allow multiple packages to be installed at the same time which
> >> divert the same file, then I think we have another case for wanting to
> >> continue supporting an optional diversion target - or at least for not 
> >> using
> >> ".diverted" by default, since we wouldn't want diversions from multiple
> >> packages to collide.  Maybe ".diverted-$package", then?

(My internet connection has been very flaky since this thread started
and I have only been able to post intermittently so apologies if this
appears to be late or "out-of-sync" with other posts.)

Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all
when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire
package under that, as we do with dpkg-cross currently:

/usr/lib/
/usr/arm-linux-gnu/lib/

/usr/include/
/usr/arm-linux-gnu/include/

multiarch could even add:
/usr/share/
/usr/arm-linux-gnu/share

This adds only one new directory, it keeps the main contents of the
package in a single location (making it easier to manage and parse
things like dpkg -L) and it means less changes for existing packages
that use these paths already.

It also means no need for extra diversions at all, no need for Replaces:
and no headaches when removing the multiarch vs removing the primary
package etc.

BTW I think it is a mistake to want to use /usr/lib/i386/ when it is
entirely possible that multiarch users will actually need the full
triplet - think about hurd or kfreebsd as multiarch packages.

> > There are two use cases to consider regarding multiple packages and
> > diversions.
> >
> > 1) Multiple packages installing a file that has been diverted.
> > Currently, there is only one "divert to" filename so you'll end up
> > losing data once the second diverted file is installed.  This could be
> > alleviated by instead basing the "divert to" filename on the package
> > which contains the file being diverted (as you suggest above).
> >
> > There's still the problem of what to do when the package providing the
> > diversion is uninstalled as now you have conflicting packages.
> > Actually, you already had conflicting packages that just weren't
> > affected yet because of the diversion, which leads to 2).

If the multiarch package can be installed alongside the primary without
any conflicts by using /usr/$triplet instead, then the need for the
diversion and consequent hacks goes away entirely.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Work-needing packages report for Jul 4, 2008

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 497 (new: 4)
Total number of packages offered up for adoption: 110 (new: 2)
Total number of packages requested help for: 50 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   cfi (#488603), orphaned 4 days ago
 Description: Copyright does not exist, book about hacker culture
 Installations reported by Popcon: 62

   hindent (#488601), orphaned 4 days ago
 Description: Reformats HTML code
 Installations reported by Popcon: 125

   uspp (#488790), orphaned 2 days ago
 Description: Universal Serial Port Python library
 Installations reported by Popcon: 11

   xmailbox (#488599), orphaned 4 days ago
 Description: A version of xbiff with animation and sound effects
 Installations reported by Popcon: 38

493 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   mp3splt (#488931), offered yesterday
 Description: Splits MP3 and Ogg Vorbis files without reencoding
 Installations reported by Popcon: 870

   wallpaper-tray (#488396), offered 5 days ago
 Description: wallpaper changing utility for GNOME
 Installations reported by Popcon: 355

108 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   apache2 (#470795), requested 112 days ago
 Description: Co-maintainer wanted
 Reverse Depends: achims-guestbook ampache apache2 apache2-dbg
   apache2-mpm-event apache2-mpm-itk apache2-mpm-prefork
   apache2-mpm-worker apache2-prefork-dev apache2-suexec (154 more
   omitted)
 Installations reported by Popcon: 37531

   ara (#450876), requested 235 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 120

   athcool (#278442), requested 1346 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 230

   bash-completion (#472468), requested 101 days ago
 Description: programmable completion for the bash shell
 Installations reported by Popcon: 10948

   cfs (#458061), requested 188 days ago
 Description: Cryptographic Filesystem
 Installations reported by Popcon: 111

   cvs (#354176), requested 861 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta cvsps (12 more
   omitted)
 Installations reported by Popcon: 22085

   darcs (#486192), requested 19 days ago
 Description: an advanced revision control system
 Reverse Depends: arch2darcs darcs-buildpackage darcs-load-dirs
   darcs-monitor darcs-server darcsweb
 Installations reported by Popcon: 1351

   dctrl-tools (#448284), requested 250 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies dlocate feta
   haskell-devscripts hg-buildpackage mlmmj sbuild simple-cdd
 Installations reported by Popcon: 8105

   dpkg (#282283), requested 1321 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc build-essential bzr-builddeb checkinstall clamsmtp (107
   more omitted)
 Installations reported by Popcon: 73835

   drscheme (#402589), requested 570 days ago
 Description: PLT scheme programming environment
 Reverse Depends: drscheme minlog proofgeneral-minlog
 Installations reported by Popcon: 376

   elvis (#432298), requested 360 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 263

   fglrx-driver (#454993), requested 208 days ago (non-free)
 Description: non-free AMD/ATI r5xx, r6xx display driver
 Reverse Depends: fglrx-amdcccle fglrx-atieventsd fglrx-control
   fglrx-driver fglrx-glx fglrx-glx-ia32 fglrx-kernel-src
 Installations reported by Popcon: 2188

   flightgear (#487388), requested 12 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 931

   gentoo (#422498), requested 424 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported b

Re: Multiarch and idea for improved diversions and alternatives handling

[Tollef Fog Heen]

* Neil Williams 

| Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all
| when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire
| package under that, as we do with dpkg-cross currently:

How would you then handle libraries that go in /lib?  (Apart from the
fact that I think just using a subdirectory of /usr/lib is much neater
than random subdirectories in /usr.

| /usr/include/
| /usr/arm-linux-gnu/include/

Please note that the initial goal of multiarch at least has been just
running of packages from foreign architectures.  Not building them.

| multiarch could even add:
| /usr/share/
| /usr/arm-linux-gnu/share

Pardon my language, but this is crack.  The point of /usr/share is you
can share it between systems.  If you go down this route, just use a
chroot and some wrapper scripts to bounce between them instead.

[...]

| BTW I think it is a mistake to want to use /usr/lib/i386/ when it is
| entirely possible that multiarch users will actually need the full
| triplet - think about hurd or kfreebsd as multiarch packages.

I don't believe anybody has suggested using just /usr/lib/i386, but
rather /usr/lib/i486-linux-gnu?

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Converting to source format "3.0 (quilt)" (was: Misc developer news (#9))

[Raphael Hertzog]

On Fri, 04 Jul 2008, Ben Finney wrote:
> [Followup on debian-devel, instead of debian-devel-announce. Raphael,
> did you intentionally set Mail-Followup-To to debian-devel-announce or
> was that an oversight?]

Well, mutt adds it automatically as I have it configured to recognize all
debian-* as mailing lists. 

I added now a "unlists debian-devel-announce" that will hopefully solve
this for next time.

> >  To prepare a future switch to the "3.0 (quilt)" source package format, I
> >  tried to convert the whole archive and to rebuild the packages
> >  afterwards.
> 
> What does this mean; what is it that you did? I don't quite know how
> you "convert the whole archive" automatically to this new format,
> unless you mean that packages which didn't use quilt are simply using
> an empty patch set.

The operation corresponds to (with dpkg-dev 1.14.20):
apt-get source 
dpkg-source --format="3.0 (quilt)" -b -*
dpkg-source -x _*.dsc
cd -* && debuild

Yes, it means that packages not using quilt and without upstream changes
in the .diff.gz have an empty quilt series.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Multiarch and idea for improved diversions and alternatives handling

[Neil Williams]

On Fri, 2008-07-04 at 08:33 +0200, Tollef Fog Heen wrote:
> * Neil Williams 
> 
> | Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all
> | when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire
> | package under that, as we do with dpkg-cross currently:
> 
> How would you then handle libraries that go in /lib?  (Apart from the
> fact that I think just using a subdirectory of /usr/lib is much neater
> than random subdirectories in /usr.

/lib/
/arm-linux-gnu/lib/

(did I miss that bit?)

A single subdirectory of /usr is, IMHO, neater than a subdirectory
of /usr/include and /usr/lib/. It would also mean less changes for those
who are currently using multiple architectures on one system for the
purposes of cross building. I wouldn't want to go the whole hog though
and have /arm-linux-gnu/usr/lib /arm-linux-gnu/lib because that would be
ugly, at least to me.

> 
> | /usr/include/
> | /usr/arm-linux-gnu/include/
> 
> Please note that the initial goal of multiarch at least has been just
> running of packages from foreign architectures.  Not building them.

True but the current usage of these mechanisms is in cross-building so
sometimes the results of having to do something without major changes
elsewhere can be helpful in designing the subsequent mechanism.

> 
> | multiarch could even add:
> | /usr/share/
> | /usr/arm-linux-gnu/share
> 
> Pardon my language, but this is crack.  The point of /usr/share is you
> can share it between systems.  If you go down this route, just use a
> chroot and some wrapper scripts to bounce between them instead.

It was only a suggestion for /usr/share - it was an alternative to
renaming the package to get a different directory in /usr/share/ as the
current tools do. Until all suitable packages have things like
translations separated out into TDebs and other things like images in a
-data or -common package instead of being packaged along with the
architecture-dependent binaries, conflicts will occur if /usr/share is
used as intended.

Personally, I think it is better to avoid the need for complicated
changes to diversions, alternatives or Replaces: if a simpler change in
the packaging can achieve a smoother effect overall - albeit that the
change in packaging would affect a lot more packages. Multiarch isn't
needed for every possible package - not even every lib package or every
binary package, changes can be made in the relevant package when people
find a need to use that package as a multiarch package.

> 
> [...]
> 
> | BTW I think it is a mistake to want to use /usr/lib/i386/ when it is
> | entirely possible that multiarch users will actually need the full
> | triplet - think about hurd or kfreebsd as multiarch packages.
> 
> I don't believe anybody has suggested using just /usr/lib/i386, but
> rather /usr/lib/i486-linux-gnu?

OK - as I said, my connection has been flaky and I might have missed
that bit.


-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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