Re: packages being essential but having stuff in /usr/?!

[Giacomo A. Catenazzi]

On 14.07.2010 17:36, Christoph Anton Mitterer wrote:

Hi.

I wonder why this never came up before,.. or did it an I'm just blind?

I've just read parts of POSIX, where echo is more or less deprecated in
favour of printf
(http://www.opengroup.org/onlinepubs/9699919799/utilities/echo.html#tag_20_37_16).
Whether users will do this or not is a different question but I've seen
that Debian/corutils ships echo in /bin, but printf in /usr/bin.
The same for many other binaries part of coreutils.

Now coreutils is marked as essential, right?!
This means per policy section 3.8
(http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8):
"Essential is defined as the minimal set of functionality that must be
available and usable on the system at all times"

As far as I understand,.. it's fully ok, to have /usr on a separate
(i.e. non-root-) filesystem.



System initialisation and in general system script are outside POSIX
scope, as well many common command executed by such scripts 
(administration tools are also outside POSIX).

Additionally system initialisation is very complex and it should handle
to many different setups (from no local disks to very complex local
disks setup, etc.).

So it is impossible to have POSIX compatible scripts (or at least
at early stage) and on the other hand, over-specifying the booting
process will reduce flexibility to build a better system and to
correct existing and future bugs.
Our "boot people" take care about init scripts, their requirements
and thus what it should be moved from /usr to root.
It is a case-by-case analysis.

OTOH essential packages will provide a basic system for all debian 
packages, developers and users, thus it is important to have

more than basic tools to boot in "essential" packages.
And the contrary is also valid: a diskless system need some
network packages, some of them surely not "essential"



btw: Personally, I'd support to stop using echo,.. it's not really
portable...


not portable? Do you have some real/widely used examples of
incompatible use?
Most echo command don't start with "-", thus fully portable, but
nearly all echo support the -n option.

BTW GNU/Linux is not fully POSIX compatible by design. It follow the
LSB (an other standard) and there is a ISO groups to find and try
to correct the differences. "echo" is one of "required" difference.

Anyway the initialisation script are special and well distribution 
controlled, thus it would be easier to "posixify", when/if needed.


Anyway this was discussed already several times.

ciao
cate


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

Bug#589152: ITP: libcolladadom -- COLLADA Document Object Model (DOM)

[Sébastien Barthélémy]

Package: wnpp
Severity: wishlist
Owner: "Sébastien Barthélémy" 


* Package name: libcolladadom
  Version : 2.2.1
  Upstream Author : Sony Computer Entertainment Inc.
* URL : http://sourceforge.net/projects/collada-dom
* License : MIT
  Programming Lang: C++
  Description : COLLADA Document Object Model (DOM)

The COLLADA Document Object Model (DOM) is an application programming
interface (API) that provides a C++ object representation of a COLLADA
XML instance document.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100714001600.8878.53399.report...@sid32bits.local

Re: packages being essential but having stuff in /usr/?!

[Christoph Anton Mitterer]

On Wed, 2010-07-14 at 19:22 +0200, Petter Reinholdtsen wrote:
> I believe this is a misunderstanding.  The quoted section do not mean
> that all files in a essential package need to be on the root
> partition, but that the package should always be installed.
Well but what's the benefit then at all? If it's not guaranteed to be
there...?!

> This is the first time I hear someone read the policy section the way
> you do it, and I believe it is not representative for the intention
> behind that part of the policy.
At least to me it reads like that.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: packages being essential but having stuff in /usr/?!

[Christoph Anton Mitterer]

On Thu, 2010-07-15 at 12:09 +0200, Giacomo A. Catenazzi wrote:
> System initialisation and in general system script are outside POSIX
> scope, as well many common command executed by such scripts 
> (administration tools are also outside POSIX).
Well yes,... nevertheless I guess that it's always a good idea to
restrict to scripts to the bare minimum... of course as far as possible.


> Additionally system initialisation is very complex and it should handle
> to many different setups (from no local disks to very complex local
> disks setup, etc.).
That's what I've meant... and with such complex setups, not having many
coreutils available could be a problem.


> Our "boot people" take care about init scripts, their requirements
> and thus what it should be moved from /usr to root.
> It is a case-by-case analysis.
Uhm... looking at coreutils, I find many programs which I guess can be
used (or are actually) during system initialisation, e.g.:
env
base64
dirname
[
test
stat
timeout
id
printf

just to name a few.



> not portable? Do you have some real/widely used examples of
> incompatible use?
Especially "-n",... which is widely used,... but not portable.


> BTW GNU/Linux is not fully POSIX compatible by design. It follow the
> LSB (an other standard) and there is a ISO groups to find and try
> to correct the differences. "echo" is one of "required" difference.
Yeah I know,... but it does not automatically mean that this were the "right" 
choice.
I guess LSB&Co. just made it because it was already so widely used, that
you could never convince people to do different.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: packages being essential but having stuff in /usr/?!

[Giacomo A. Catenazzi]

On 15.07.2010 14:31, Christoph Anton Mitterer wrote:

On Thu, 2010-07-15 at 12:09 +0200, Giacomo A. Catenazzi wrote:

System initialisation and in general system script are outside POSIX
scope, as well many common command executed by such scripts
(administration tools are also outside POSIX).



Well yes,... nevertheless I guess that it's always a good idea to
restrict to scripts to the bare minimum... of course as far as possible.


Yes, and usually it is so.  In a short period the maintainer will
receive bug report about non working init.d script with some
configuration, which force people to minimize the init scripts.


Additionally system initialisation is very complex and it should handle
to many different setups (from no local disks to very complex local
disks setup, etc.).



That's what I've meant... and with such complex setups, not having many
coreutils available could be a problem.


usually no. see below.


Our "boot people" take care about init scripts, their requirements
and thus what it should be moved from /usr to root.
It is a case-by-case analysis.

Uhm... looking at coreutils, I find many programs which I guess can be
used (or are actually) during system initialisation, e.g.:
env
base64
dirname
[
test
stat
timeout
id
printf

just to name a few.


Early init script doesn't need a lot of complexity, and
they are must pretty stupid, so they usually don't need some
commands of coreutils.

e.g. 'stat' and 'id' are not so usefull at such stage,
the script could assume root and basic root files available.

'env' also not is very usefull: easy to work around with
standard shell. The other standard use of 'env' is '#!/usr/bin/env"
so an already hard coded path.

'dirname', '[' and 'test' could cause some problem. Usually they are
build-in on shell, but it is not mandatory, and policy BTW mandate
some extended (from POSIX) syntax on built-in 'test', but I think
policy missed the case of 'test' not being built-in and not
being available (because it is in /usr/bin).

[this is IMHO a BUG in policy]


timout could be interesting, but when a init.d script will
need it, I think there will be no problem to more it in /bin/



not portable? Do you have some real/widely used examples of
incompatible use?

Especially "-n",... which is widely used,... but not portable.


Yes, but it is very difficult (maybe impossible) to see a real
script where echo -n is intentionally intended to write -n (at
beginning of a line).



BTW GNU/Linux is not fully POSIX compatible by design. It follow the
LSB (an other standard) and there is a ISO groups to find and try
to correct the differences. "echo" is one of "required" difference.

Yeah I know,... but it does not automatically mean that this were the "right" 
choice.
I guess LSB&Co. just made it because it was already so widely used, that
you could never convince people to do different.


But I think now echo -n must be supported by all systems (not only on 
LSB systems), because of wide usage.

POSIX successfully standardized a lot of things, but POSIX also failed
on few points ('echo -n' and 'pax'), and IMHO it is a lost campain.
I expect that in next posix the 'echo -n' and 'tar' will reach the 
normative status.


ciao
cate


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

Re: packages being essential but having stuff in /usr/?!

[Michael Banck]

On Thu, Jul 15, 2010 at 02:18:53PM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2010-07-14 at 19:22 +0200, Petter Reinholdtsen wrote:
> > I believe this is a misunderstanding.  The quoted section do not mean
> > that all files in a essential package need to be on the root
> > partition, but that the package should always be installed.
> Well but what's the benefit then at all? If it's not guaranteed to be
> there...?!

AIUI, it's guaranteed to be there after system startup.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100715132839.ga32...@nighthawk.chemicalconnection.dyndns.org

Re: packages being essential but having stuff in /usr/?!

[Russ Allbery]

"Giacomo A. Catenazzi"  writes:

> 'dirname', '[' and 'test' could cause some problem. Usually they are
> build-in on shell, but it is not mandatory, and policy BTW mandate some
> extended (from POSIX) syntax on built-in 'test', but I think policy
> missed the case of 'test' not being built-in and not being available
> (because it is in /usr/bin).

> [this is IMHO a BUG in policy]

Possibly, but I don't think Policy is really the place to try to rule out
any unreasonable thing that someone might consider doing.  I have a hard
time imagining anyone trying to use a shell as /bin/sh which doesn't have
test as a built-in, and even if they did, dealing with NFS-mounted /usr
and the location of test would be the least of their problems.

That said, yes, Policy does have a trap door clause to deal with test not
being implemented as a built-in because people objected to the assumption
that it was a built-in at the time.  I think it's a marginal case, though,
and I'm not inclined to worry too much about it.

>> Especially "-n",... which is widely used,... but not portable.

Policy requires echo -n be portable to any Debian system.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874og0veru@windlord.stanford.edu

Re: packages being essential but having stuff in /usr/?!

[Russ Allbery]

Michael Banck  writes:
> On Thu, Jul 15, 2010 at 02:18:53PM +0200, Christoph Anton Mitterer wrote:
>> On Wed, 2010-07-14 at 19:22 +0200, Petter Reinholdtsen wrote:

>>> I believe this is a misunderstanding.  The quoted section do not mean
>>> that all files in a essential package need to be on the root
>>> partition, but that the package should always be installed.

>> Well but what's the benefit then at all? If it's not guaranteed to be
>> there...?!

> AIUI, it's guaranteed to be there after system startup.

Right, the point is that other packages can assume those binaries are
available during any normal package operations and during package
installation and removal.

Early system startup (before $remote_fs) is a weird and special
environment, and most services should just depend on $remote_fs and not
worry about it.  Normally they have to anyway since the daemon being
started is in /usr.  Services that do not depend on $remote_fs are
services that have to be prepared to run in a limited and special
environment and will require special attention and thought.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkxsu04m@windlord.stanford.edu

Re: packages being essential but having stuff in /usr/?!

[Christoph Anton Mitterer]

On Wed, 2010-07-14 at 19:26 +0200, Sven Joachim wrote:
> It's been reported as bug #428189 already, but without any followup.
> See also #532324.
Well while 532324 is a perfect example how some developers obviously
think they can ignore the policy just as they like (this issue is really
unbelievable,... wonder why we have all that policy crap...) in order to
save them work...
I'd agree that at least section 10.4 of the policy does not mandate that
the SUS3 Utilities are available,... as far as I understand it just
talks about compliance of shells providing /bin/sh with the SUS3 Shell
Command Language (which is not the Utilities),... and IIRC printf is not
required to be a built-in...


Nevertheless I still think that this stuff has to be there because of
the definition of "essential".
- Either this on is not exactly formed (so essential means only always
installed, but does not mean always available)... but this would make
the whole concept rather stupid IMHO,.. because then we'd again have to
check for every single essential thing we're using anywhere.

- Or it does mean, that everything essential has to be available
always,.. which would include at least the time when init takes over
from the kernel or the initramfs image.
But then we'd have a problem as many packages put their stuff in /usr/


> This is indeed a problem if /bin/sh has no printf builtin, but it does
> not affect people who use dash or bash.
Well but it's rather ugly to simply say dash/bash support it,.. => we're
fine...


> So is dpkg, and it lives almost completely under /usr, except for
> start-stop-daemon.
Well,... but dpkg is probably not needed during system startup...


> > That however would mean, that even outsite initramfs images (which are
> > probably a special case and do not count) many of corutils' binaries are
> > not _always_ available.
> Before /usr is mounted, yes.
Is there any policy document or that like,... which mandates:
a) What is guaranteed to be available in initramfs images?
b) What is guaranteed to be available as soon as the root-fs is mounted
(I mean /etc/, /bin/, /sbin, /lib/, but not /usr
c) When (!) it is guaranteed that also /usr/ is there? Is it after
$remote_fs? Or after mountall-nfs.sh?


> Only init scripts that do not depend on $remote_fs have to do this check.
There are quite a lot...


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: packages being essential but having stuff in /usr/?!

[Julien Cristau]

On Thu, Jul 15, 2010 at 21:07:11 +0200, Christoph Anton Mitterer wrote:

> Is there any policy document or that like,... which mandates:
> a) What is guaranteed to be available in initramfs images?
> b) What is guaranteed to be available as soon as the root-fs is mounted
> (I mean /etc/, /bin/, /sbin, /lib/, but not /usr
> c) When (!) it is guaranteed that also /usr/ is there? Is it after
> $remote_fs? Or after mountall-nfs.sh?
> 
No, and there doesn't need to be.  Now can you stop beating this dead
horse?  It would like to rot in hell unharmed.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: packages being essential but having stuff in /usr/?!

[Russ Allbery]

Christoph Anton Mitterer  writes:

> c) When (!) it is guaranteed that also /usr/ is there? Is it after
> $remote_fs? Or after mountall-nfs.sh?

It's after $remote_fs.  Please don't assume that all non-local file
systems are NFS.  Someday, I'd like to support /usr in AFS, for instance,
since that's sometimes used at heavy AFS sites.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87iq4gse3h@windlord.stanford.edu

Re: packages being essential but having stuff in /usr/?!

[Bernd Zeimetz]

On 07/15/2010 09:07 PM, Christoph Anton Mitterer wrote:
> On Wed, 2010-07-14 at 19:26 +0200, Sven Joachim wrote:
>> It's been reported as bug #428189 already, but without any followup.
>> See also #532324.
> Well while 532324 is a perfect example how some developers obviously
> think they can ignore the policy just as they like (this issue is really
> unbelievable,... wonder why we have all that policy crap...) in order to
> save them work...

Full ack.
If the policy does not fit reality, then it should be changed *or* (which is
what I'd prefer), the package needs to be fixed.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 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
Archive: http://lists.debian.org/4c3f6fbe.9030...@bzed.de

Re: packages being essential but having stuff in /usr/?!

[Christoph Anton Mitterer]

On Thu, 2010-07-15 at 14:59 +0200, Giacomo A. Catenazzi wrote:
> Yes, and usually it is so.  In a short period the maintainer will
> receive bug report about non working init.d script with some
> configuration, which force people to minimize the init scripts.
Agreed.

> Early init script doesn't need a lot of complexity, and
> they are must pretty stupid, so they usually don't need some
> commands of coreutils.
Aggreed with the exception that you may have,.. as I noted in my
email just before stuff in initramfs-images which do use such things.

But I'm fully ok with putting this under the responsibility of the
respective author :)

Nevertheless,... I'd like to see definite clarification on this
situation in the policy :)


> 'dirname', '[' and 'test' could cause some problem. Usually they are
> build-in on shell, but it is not mandatory, and policy BTW mandate
> some extended (from POSIX) syntax on built-in 'test', but I think
> policy missed the case of 'test' not being built-in and not
> being available (because it is in /usr/bin).
> 
> [this is IMHO a BUG in policy]
Yes I see also a problem here...


> timout could be interesting, but when a init.d script will
> need it, I think there will be no problem to more it in /bin/
Is it really that easy moving such things? I've seen many scripts
throughout debian which hardcode the absolute path (and do not (have to)
set a secure PATH for that reason)... all of them would fail after such
movings...


> Yes, but it is very difficult (maybe impossible) to see a real
> script where echo -n is intentionally intended to write -n (at
> beginning of a line).
Admittedly,... I just noted this, because personally I also like other
non-Linux Unices... and we should not add incompatibilities if
avoidable :)


> But I think now echo -n must be supported by all systems (not only on 
> LSB systems), because of wide usage.
> POSIX successfully standardized a lot of things, but POSIX also failed
> on few points ('echo -n' and 'pax'), and IMHO it is a lost campain.
> I expect that in next posix the 'echo -n' and 'tar' will reach the 
> normative status.
Would be great!... Hopefully also "local" :D


Best wishes,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: packages being essential but having stuff in /usr/?!

[Christoph Anton Mitterer]

On Thu, 2010-07-15 at 10:26 -0700, Russ Allbery wrote:
> Right, the point is that other packages can assume those binaries are
> available during any normal package operations and during package
> installation and removal.
Ok... than perhaps one can add a note to the policy, that this means
"after the system has booted, or especially after all filesystems
including /usr are mounted".

And apart from that,... during initramfs only that what has been
included (or is part of busybox, if used ist available), and
berofre /usr... only that what the respective maintainers (e.g.
coreutils) decided to put into non-/usr locations.
Right?



> Early system startup (before $remote_fs) is a weird and special
> environment, and most services should just depend on $remote_fs and not
> worry about it.  Normally they have to anyway since the daemon being
> started is in /usr.
Well I came across this by writing a (hopefully) improved version of the
current /etc/init.d/skeleton to ask for its inclusion,... and I did not
want to restrict the notes I give there for just these normal kinds of
daemons.
(So much for my motivation.)


> Services that do not depend on $remote_fs are
> services that have to be prepared to run in a limited and special
> environment and will require special attention and thought.
Well I wrote some keyscripts for cryptsetup, which happen to execute
long before any /usr or so is there,... and I use e.g. printf and some
others.
I never noticed however that printf is not there, because of that
built-in versions ;)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: packages being essential but having stuff in /usr/?!

[Christoph Anton Mitterer]

On Thu, 2010-07-15 at 20:15 +0100, Julien Cristau wrote: 
> No, and there doesn't need to be.  Now can you stop beating this dead
> horse?  It would like to rot in hell unharmed.
Wow,... supposing that you speak for Debian,... this reaction is
really ... "interesting"...

Always thought that Debian would be an open project,... so
- either I'm wrong with my assumptions on the policy and one could
(being so "open") explain the where and why...
- or I'm right,.. than there's somewhere some problem, either in the
policy,.. or the package...

But just saying "go away,... I don't wanna know anything"... and
ignoring that there are e.g. non-dash/bash shells which conform to the
policy as a /bin/sh but still would break here... this is really
Drepper-ism in it's purest form :)

Thank your for that ... uhm... entertainment...


Best wishes,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: packages being essential but having stuff in /usr/?!

[Peter Samuelson]

[Christoph Anton Mitterer]
> > This is indeed a problem if /bin/sh has no printf builtin, but it does
> > not affect people who use dash or bash.
> Well but it's rather ugly to simply say dash/bash support it,.. =>
> we're fine...

What problem are you trying to solve?  Did you actually try to use an
init script that use printf and doesn't depend on $remote_fs, on a
system where /bin/sh is neither bash nor dash?

Or is this just a big gedanken-experiment?

It sounds a great deal like the latter, in which case I think you would
waste a lot less time by simply joining forces with those people who
are working toward being able to run other shells as /bin/sh.  Let
_them_ know that if they don't provide builtin test and printf
commands, there will be problems before /usr is mounted.  If they want
to crusade about it, I think it would sound more credible than you
doing so with no apparent concrete goals.
-- 
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
Archive: http://lists.debian.org/20100715213129.ge3...@p12n.org

Re: upcoming issues with python-hulahop, python-xpcom, xulrunner-1.9.2

[Darren Salt]

I demand that Luke Kenneth Casson Leighton may or may not have written...

[snip]
> basically, an interpretation of the decision from the mozilla foundation is
> that all languages but javascript can get lost.  i do not understand why,
> after years of support thanks to xpcom, _just_ when there's a project which
> actually _uses_ alternative language bindings 100% and i meaaan 100%, the
> mozilla foundation slams the door in its face and in the face of every
> other project using xpcom.

I'm wondering whether I should start investigating alternative Javascript
libraries, given Mozilla's (apparent) reluctance to install libmozjs as
anything other than a private library for use by xulrunner-using apps.

That said, if anybody is prepared to take the Ubuntu workaround for this in
their gxine package and make that suitable for upstream, I'll take that
instead. I did try to push for something which is acceptable for upstream,
but no, distribution-specific workaround...

(I suppose that I could create a Ubuntu-based chroot, but I'd rather avoid
that.)

[snip]
-- 
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back!
| + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING.

I have to stop now; my fingers are getting hoarse!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/mpro.l5ljve00akfzk0279.li...@youmustbejoking.demon.co.uk

Work-needing packages report for Jul 16, 2010

[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: 612 (new: 9)
Total number of packages offered up for adoption: 141 (new: 4)
Total number of packages requested help for: 67 (new: 1)

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



The following packages have been orphaned:

   autounit (#588591), orphaned 5 days ago
 Description: C unit testing framework interfacing well with
   autotools
 Reverse Depends: libautounit-dev
 Installations reported by Popcon: 15

   bookmarkbridge (#588592), orphaned 5 days ago
 Description: tool to synchronize bookmarks between browsers
 Installations reported by Popcon: 147

   dtmfdial (#588835), orphaned 3 days ago
 Description: DTMF Tone Dialer
 Installations reported by Popcon: 198

   gtk-theme-switch (#588836), orphaned 3 days ago
 Description: GTK+ theme switching utility
 Installations reported by Popcon: 1189

   libpam-pwdfile (#588877), orphaned 2 days ago
 Description: PAM module allowing authentication via an
   /etc/passwd-like file
 Installations reported by Popcon: 334

   mwavem (#588988), orphaned yesterday (non-free)
 Installations reported by Popcon: 1

   seyon (#589106), orphaned yesterday
 Description: Full-featured native X11 communications program
 Installations reported by Popcon: 186

   wmmoonclock (#588837), orphaned 3 days ago
 Description: WindowMaker moon phase dockapp
 Installations reported by Popcon: 283

   wmsun (#588838), orphaned 3 days ago
 Description: Dockable WindowMaker SunRise/SunSet App
 Installations reported by Popcon: 243

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

   autounit (#588591), offered 5 days ago
 Description: C unit testing framework interfacing well with
   autotools
 Reverse Depends: libautounit-dev
 Installations reported by Popcon: 15

   bookmarkbridge (#588592), offered 5 days ago
 Description: tool to synchronize bookmarks between browsers
 Installations reported by Popcon: 147

   dvorak7min (#588878), offered 2 days ago
 Description: typing tutor for Dvorak keyboards
 Installations reported by Popcon: 135

   qcad (#588854), offered 3 days ago
 Description: professional CAD system
 Installations reported by Popcon: 2508

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

[NEW] mwavem (#588988), requested yesterday (non-free)
 Installations reported by Popcon: 1

   apt-cross (#540341), requested 342 days ago
 Description: retrieve, build and install libraries for
   cross-compiling
 Reverse Depends: apt-cross emdebian-crush
   mlton-target-alpha-linux-gnu mlton-target-arm-linux-gnueabi
   mlton-target-hppa-linux-gnu mlton-target-i486-linux-gnu
   mlton-target-ia64-linux-gnu mlton-target-mips-linux-gnu
   mlton-target-mipsel-linux-gnu mlton-target-powerpc-linux-gnu (3 more
   omitted)
 Installations reported by Popcon: 341

   apt-xapian-index (#567955), requested 164 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: adept ept-cache fuss-launcher packagesearch
 Installations reported by Popcon: 12379

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

   asymptote (#517342), requested 503 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 1301

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

   boinc (#511243), requested 553 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1561

   chromium-browser (#583826), requested 46 days ago
 Description: Chromium browser
 Reverse Depends: chromium-browser chromium-browser-dbg
   chromium-browser-l10n gecko-mediaplayer sun-java6-plugin
 Installations reported by Popcon: 1455

   cvs (#354176), requested 1603 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsps cvsservice

Re: Upstream Tracker

[Paul Wise]

On Wed, Jul 14, 2010 at 7:09 PM, Andrey Ponomarenko  wrote:

> Suggestions for libraries inclusion and feature/bug requests are very
> welcome. Thanks!

I would strongly suggest you spread the word about this tool and
website amongst the FLOSS community. Probably a good initial start
would be an article in LWN's Development section and may lead to
various upstreams using the tool as part of their development process.
After that, file bugs upstream as they appear in new releases.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

[Steve M. Robbins]

Folks,

The package "aptitude" is priority "important" and depends on
libboost-iostreams, which is "optional".  This is a violation of
Policy section 2.5.

The request of Bug #588608 is to raise the priority of
libboost-iostreams to "important".  Reading Policy, I note that
"important" means:

 `important'
  Important programs, including those which one would expect to
  find on any Unix-like system.  If the expectation is that an
  experienced Unix person who found it missing would say "What on
  earth is going on, where is `foo'?", it must be an `important'
  package.[1] Other packages without which the system will not run
  well or be usable must also have priority `important'.  This does
  _not_ include Emacs, the X Window System, TeX or any other large
  applications.  The `important' packages are just a bare minimum
  of commonly-expected and necessary tools.

I wouldn't place any of Boost in that category.  In fact, I wouldn't
place "aptitude" in that category, either.

So while raising Boost will "solve" the issue, it seems to me to be
a recipe for runaway priority inflation.

Is there any central authority to vet priority changes?

Thanks,
-Steve


signature.asc
Description: Digital signature

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

[Russ Allbery]

"Steve M. Robbins"  writes:

> I wouldn't place any of Boost in that category.  In fact, I wouldn't
> place "aptitude" in that category, either.

aptitude was historically the recommended tool to use for upgrades because
it had the best dependency resolver for handling the dist-upgrade case.
For so long as that's true, it should be priority: important, which means
that by definition the things that it requires are also priority:
important or higher.

If apt-get is now strong enough that we can recommend it for upgrades
without qualms, then aptitude is another alternative package manager and
standard may be fine.  Is that now the case?

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y6dc83h9@windlord.stanford.edu

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

[Will]

6, 2010 at 12:17 AM, Russ Allbery  wrote:
> "Steve M. Robbins"  writes:
>
>> I wouldn't place any of Boost in that category.  In fact, I wouldn't
>> place "aptitude" in that category, either.
>
> aptitude was historically the recommended tool to use for upgrades because
> it had the best dependency resolver for handling the dist-upgrade case.
> For so long as that's true, it should be priority: important, which means
> that by definition the things that it requires are also priority:
> important or higher.
>
> If apt-get is now strong enough that we can recommend it for upgrades
> without qualms, then aptitude is another alternative package manager and
> standard may be fine.  Is that now the case?
>
> --
> Russ Allbery (r...@debian.org)               
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/87y6dc83h9@windlord.stanford.edu
>
>

aptitude is the preferred package management tool, so I'm thinking
that the priority of libboost-iostreams should be upgraded [1][2].
aptitude has more features than just a better dependency handler, like
the significantly more advanced search syntax and the smarter,
interactive resolver. I think the better decision is to edit it such
that it doesn't require that library. However, that's a decision for
the aptitude team to make, since I have no idea how heavily it relies
on that package, or what portions of the program depend on that
library.

I'd be glad to donate some of my time if the aptitude team wanted it though.

[1] 
http://www.debian.org/doc/manuals/reference/ch02.en.html#_basic_package_management_operations
[2] http://wiki.debian.org/Aptitude

-- 
-Will Orr


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

Re: Upstream Tracker

[Will]

On Wed, Jul 14, 2010 at 7:09 AM, Andrey Ponomarenko  wrote:
> Hello, Colleagues!
>
> The new service for tracking ABI changes in various C/C++ libraries is
> now available for Linux distribution maintainers and upstream developers
> - "Upstream Tracker". It may be helpful for analyzing risks of libraries
> updating in the Debian Linux. The service includes more than 100
> libraries at the moment: OpenSSL, ALSA, glib, cairo, libssh, fontconfig etc.
>
> The service is freely available at:
> http://linuxtesting.org/upstream-tracker/
>
> Suggestions for libraries inclusion and feature/bug requests are very
> welcome. Thanks!
>
> --
> Andrey Ponomarenko
>
> Linux Verification Center, ISPRAS
>  web:    http://www.linuxtesting.org
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/4c3d9b07.1000...@ispras.ru
>
>

This service looks excellent! Definitely spread the word about it, and
thanks for providing such a service.

PS I posted it on the linux Reddit.

-- 
-Will Orr


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

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

[Steve Langasek]

On Fri, Jul 16, 2010 at 12:59:56AM -0400, Will wrote:
> aptitude is the preferred package management tool, so I'm thinking
> that the priority of libboost-iostreams should be upgraded [1][2].

> [1] 
> http://www.debian.org/doc/manuals/reference/ch02.en.html#_basic_package_management_operations

This manual represents the opinion of a single developer.  It has not been
ratified by the Debian project, and individual recommendations made within
should not be taken for the preferences of the Debian project.

Though I think any manual published on debian.org recommending aptitude for
upgrades is a bug that should be fixed.

> [2] http://wiki.debian.org/Aptitude

Well, and this is a page in a wiki about aptitude.  The existence of such a
page is not a recommendation by the Debian project that it should be used.

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


signature.asc
Description: Digital signature