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_
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++
Descri
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?
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
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).
W
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 tha
"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
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
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
unbelievabl
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/, /sb
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
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 ignor
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 ne
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
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
[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
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
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 request
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 ar
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:
"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
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
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 lib
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
Th
24 matches
Mail list logo
