On Sat, 2011-01-15 at 13:07 +0200, Andrei Popescu wrote:
> On Sb, 15 ian 11, 10:10:04, Chris Carr wrote:
> >
> > Is there some forum in which the choice of a default for a package or
> > service gets made? I subscribe to debian-devel and debian-policy, but
> > neither seems to contain discussions
hee friends
plzz add this id for
link exchange.
outsource project
www.deepahosting.com
On Sat, 15 Jan 2011 18:02:06 -0800, Russ Allbery
wrote:
>Adam Borowski writes:
>> On Fri, Jan 14, 2011 at 04:07:58PM -0800, Russ Allbery wrote:
>
>>> Huh. Every system I've upgraded had no problems.
>
>> I find this strange, since every system that has ever been etch will
>> have at least libdev
New products for lighting applications!
Post-top and radial-waves overhead CutOff luminaires (lighting fixtures), as
well low-voltage overhead fixtures are already available now. Please look-up at
all.
http://post-top.electrical-contractor.net/ds_posttop_stand/sect_view_cutoff/pack_pt_sect.h
Am Sonntag, 16. Januar 2011 schrieb Marc Haber:
> On Sat, 15 Jan 2011 18:02:06 -0800, Russ Allbery
>
> wrote:
> >Adam Borowski writes:
> >> On Fri, Jan 14, 2011 at 04:07:58PM -0800, Russ Allbery wrote:
> >>> Huh. Every system I've upgraded had no problems.
> >>
> >> I find this strange, since
Quoting Christian PERRIER (bubu...@debian.org):
> Quoting Christian PERRIER (bubu...@debian.org):
>
> > I have ready NMUs for most of the affeted packages. I can upload them
> > soon.
>
> My plans are to upload before the end of the upcoming week-end an NMU
> for each of the affected package(s).
On Sun, 16 Jan 2011 12:14:45 +0100, "Hans-J. Ullrich"
wrote:
>I believe "aptitude purge ~c" does the same.
I avoid using aptitude for non-interactive things since I am falling
over two annoying bugs in aptitude for months without seeing them
fixed.
> Also you might want to take a
>look at "orph
Michael Biebl writes:
> Completely agreed. The focus of dependency based boot is correctness.
> The old system with static start/stop priorities was a pain to maintain and
> actually had many bugs which were effectively impossible to change, because
> changing the priority of *one* package can le
On Fri, 2011-01-14 at 07:58 +0900, Charles Plessy wrote:
> In the candidate version of the DEP, it is not recommended anymore to add an
> X-
> prefix to extra fields.
btw: Why was this removed? Adding the X- is not only conventional style
in email headers and many other RFCs but also (in a similar
On Fri, 2011-01-14 at 12:09 -0400, Joey Hess wrote:
> I probably misread DEP5 -- when it says "formatted text, no synopsis",
> it probably means that the entire field including the first line
> is treated as one thing. So both "Comment: foo\n" and "Comment:\n foo\n" are
> the same value.
I've also
Oh, and I've also would like to see the "X-" on personal license short
names.
Perhaps one could also add a namespace that is "privately" managed, but
still global, e.g. in the style of:
"org.example.license.foobar"
Specifying globally unique a license "foobar" from Example Org.
But not sure whet
On Sun, Jan 16, 2011 at 2:47 AM, Mike Bird wrote:
> On Sat January 15 2011 16:33:28 Olaf van der Spek wrote:
>> If insserv meses up so bad, shouldn't it be able to detect that things
>> will go wrong too?
>
> insserv completely discards the Snn/Knn values and generates a new
> boot ordering based
On Sun, Jan 16, 2011 at 3:54 AM, Russ Allbery wrote:
> It's the responsibility of packages to clean up obsolete conffiles as
> they're upgraded. If you run into the case of a package that's been
> upgraded and not cleaned up its obsolete conffiles, and there isn't some
> reason for that, that's w
On 15/01/2011 22:18, Neil Williams wrote:
Ben Finney wrote:
Neil Williams writes:
Can the rest of us now actually ask if there is anything we can do
to get more people involved in helping packaging teams which are
openly asking for help?
[…]
The problem is a lack of manpower in critical t
On 15/01/2011 23:50, Russ Allbery wrote:
Chris Carr writes:
Is there some forum in which the choice of a default for a package or
service gets made? I subscribe to debian-devel and debian-policy, but
neither seems to contain discussions about the risks of replacing
perfectly good defaults with
Le Sun, Jan 16, 2011 at 01:12:46PM +0100, Christoph Anton Mitterer a écrit :
> On Fri, 2011-01-14 at 07:58 +0900, Charles Plessy wrote:
> > In the candidate version of the DEP, it is not recommended anymore to add
> > an X-
> > prefix to extra fields.
> btw: Why was this removed? Adding the X- is
Le Sat, Jan 15, 2011 at 11:38:12PM +0100, Stefano Zacchiroli a écrit :
>
> Well, I was assuming that DEP5 was going to become an "associated text"
> under policy §5.6.11 and, as such, subject to Standards-Version. That
> would bring IMHO various benefits such as: 1) the possibility of
> dropping F
On Sun, 16 Jan 2011 12:44:10 +
Chris Carr wrote:
> > Bug triage doesn't need huge amounts of package-specific skills. It
> > just needs the people doing triage to be able to cooperate with the
> > maintainer(s).
> [snip]
> >> Is there an obvious way for people willing to do grunt work to help
Package: wnpp
Owner: tak...@debian.org
Severity: wishlist
* Package name: python-exif
Version : 1.0.8
Upstream Author : Ianar$(D+1(B S$(D+1(Bvi
* URL or Web page : http://sourceforge.net/projects/exif-py/
* License : BSD
Description : Python library to extract EXI
On Sat, Jan 15, 2011 at 05:47:24PM -0800, Mike Bird wrote:
[...]
>> Got a concrete example of a case that fails?
> We ran into the Apache-Bind problem and the RequestTracker-Apache-Mysql
> problems and then stopped using insserv.
This one was reported and solved thanks to RT maintainers:
http://bu
Le dimanche 16 janvier 2011 13:48:55, Charles Plessy a écrit :
> Given that there are only 9 different fields in the current DEP-5 syntax, I
> think that parsers can simply incorporate the full list of them rather than
> rely on a X- prefix to determine if a field is in the specification or not.
S
]] Bjørn Mork
Hi,
| Although I do agree with the improved simplicity, I do not agree that
| *all* incorrect orderings are simple to fix (or necessarily package
| bugs). Unfortunately, there are some packages which require system
| dependent ordering. The most obvious example is the set package
On Sun, 16 Jan 2011, Olaf van der Spek wrote:
> On Sun, Jan 16, 2011 at 3:54 AM, Russ Allbery wrote:
> > It's the responsibility of packages to clean up obsolete conffiles as
> > they're upgraded. If you run into the case of a package that's been
> > upgraded and not cleaned up its obsolete conff
Hi
Dne Sun, 16 Jan 2011 22:44:09 +0900
TANIGUCHI Takaki napsal(a):
> Package: wnpp
> Owner: tak...@debian.org
> Severity: wishlist
>
> * Package name: python-exif
> Version : 1.0.8
> Upstream Author : Ianar$(D+1(B S$(D+1(Bvi
> * URL or Web page : http://sourceforge.net/proje
On Sun January 16 2011 04:40:02 Olaf van der Spek wrote:
> AFAIK insserv doesn't guess. "Much less info" is the dependencies
> listed in the scripts themselves, right? Isn't this enough?
That is correct. However there are far fewer dependencies
listed in the headers than implicit in the Snn/Knn n
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard
* Package name: timeago
Version : 0.9.2
Upstream Author : Ryan McGeary
* URL : http://timeago.yarp.com/
* License : Expat
Programming Lang: JavaScript
Description : jQuery plugin providing live-u
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard
* Package name: json-js
Version : 0~20101208
Upstream Author : Douglas Crockford
* URL : http://www.json.org/js.html
* License : PD
Programming Lang: JavaScript
Description : JSON encoders/decode
On Sat, Jan 15, 2011 at 11:52:34PM -0800, Mike Bird wrote:
> Some people have expressed interested in obsolete config files
> associated with currently installed packages.
>
> Here's a (slow) script for finding them, plus the merged results
> of running the script on a dozen servers and workstatio
On Sun January 16 2011 12:15:18 Roger Leigh wrote:
> The main problem with this script is that all it does is spit out
> the available information. It doesn't actually check if the user
> modified one of the conffiles. An example is attached. Modifying
> it to automatically purge "safe" packages
On Sat, Jan 15, 2011 at 05:47:24PM -0800, Mike Bird wrote:
> On Sat January 15 2011 16:33:28 Olaf van der Spek wrote:
> > If insserv meses up so bad, shouldn't it be able to detect that things
> > will go wrong too?
>
> insserv completely discards the Snn/Knn values and generates a new
> boot orde
On Sun January 16 2011 12:49:20 Roger Leigh wrote:
> You're saying that an unwieldy ad-hoc fixed list of numbers and names
> is superior to detailed dependency information… This is patently
> untrue.
No, I'm saying that Snn/Knn values boot some systems where
insserv fails. Therefore Snn/Knn is s
Hi, Mike:
On Sunday 16 January 2011 19:48:24 Mike Bird wrote:
[...]
> I filed a bug[1] with a simple patch[2] to give people fair
> notice of the pros and cons of insserv but unfortunately
> Julien Cristau simply closed the bug without explanation[3].
Regarding your patch, I find the first part
Charles Plessy writes:
> There is another reason why I would not support an alignment on the
> Policy's version number: from the begining we promised that DEP-5 was
> not an attempt to modify the Policy.
I don't recall that promise ever being made. Where did you see it?
The promise in the first
On Sun January 16 2011 13:40:58 Jesús M. Navarro wrote:
> Regarding your patch, I find the first part of it being quite to the point
> while the second paragraph is unneeded as long as the information is
> included in /usr/share/doc/sysvr-rc/README.Debian, and I feel it should be
> added to the pac
On Sun, Jan 16, 2011 at 12:44:10PM +, Chris Carr wrote [edited]:
> In both cases I ended up "pestering the team with newbie questions" because
> of the complexities of d-i and of packaging, respectively - not because I
> was unintelligent or unmotivated, nor because I had failed to read the
> a
Hi,
I submitted ITP for simple-image-reducer (#607237). That depends on
python-exif, if python-exif has not good support, anyway I need this
package.
Regards,
Takaki
> On Sun, 16 Jan 2011 19:07:05 +0100
> Michal.$ (D*-(Biha$(D+Z(B said:
>
> [1 ]
> Hi
>
> Dne Sun, 16 Jan 201
Package: wnpp
Owner: tak...@debian.org
Severity: wishlist
* Package name: tuxfootball
Version : 0.3.0
Upstream Author : Jason Wood
* URL or Web page : http://tuxfootball.sourceforge.net/
* License : GPL-2+
Description : great 2D soccer (sometimes called football) gam
Hi, Mike:
On Sunday 16 January 2011 23:37:20 Mike Bird wrote:
> On Sun January 16 2011 13:40:58 Jesús M. Navarro wrote:
> > Regarding your patch, I find the first part of it being quite to the
> > point while the second paragraph is unneeded as long as the information
> > is included in /usr/share
Hi,
I've recently adopted a package (nyquist) that only builds in 32-bit
mode. I'm struggling with supporting it on amd64 and other 64-bit
architectures in Debian.
First: yes, clearly the code should be migrated to 64-bits. Upstream
is aware of that and it's a nontrivial effort. I'm interested
On Mon, Jan 17, 2011 at 11:25 AM, Steve M. Robbins wrote:
> What is the recommended course of action for such a package?
For now: build on a 32-bit system or in a 32-bit chroot.
Other options in increasing order of preference:
Add deps to ia32-libs.
Add lib32 packages for the deps.
Help fix
On Wed, Jan 12, 2011 at 07:59:29PM -0200, Otavio Salvador wrote:
> We do need your help to find bugs and further improve the installer, so
> please try it. Installer CDs, other media and everything you else you
> will need are available at our web site[3].
Just did. VirtIO devices appear to be mis
Mike Bird schrieb:
> No, I'm saying that Snn/Knn values boot some systems where
> insserv fails. Therefore Snn/Knn is superior in some cases.
Does insserv fail then because it is inherently unable to mimic the
Snn/Knn behaviour or due to wrong (missing, ...) dependency info in
the initscripts? I
On Sun January 16 2011 15:41:40 Thomas Hochstein wrote:
> Mike Bird schrieb:
> Does insserv fail then because it is inherently unable to mimic the
> Snn/Knn behaviour or due to wrong (missing, ...) dependency info in
> the initscripts? If it's the latter, the right solution would be
> fixing the sc
Olaf van der Spek writes:
> On Sun, Jan 16, 2011 at 3:54 AM, Russ Allbery wrote:
>> It's the responsibility of packages to clean up obsolete conffiles as
>> they're upgraded. If you run into the case of a package that's been
>> upgraded and not cleaned up its obsolete conffiles, and there isn't
44 matches
Mail list logo
