Bug#304442: ITP: libconfig-yaml-perl -- Simple configuration automation

[Stephen Quinney]

Package: wnpp
Severity: wishlist
Owner: Stephen Quinney <[EMAIL PROTECTED]>

* Package name: libconfig-yaml-perl
  Version : 1.41
  Upstream Author : Shawn Boyette <[EMAIL PROTECTED]>
* URL : 
http://www.cpan.org/authors/id/M/MD/MDXI/Config-YAML-1.41.tar.gz
* License : GPL (>= 1) or Perl Artistic
  Description : Simple configuration automation

 Config::YAML is a somewhat object-oriented wrapper around the YAML
 module which makes reading and writing configuration files
 simple. Handling multiple config files (e.g. system and per-user
 configuration, or a gallery app with per-directory configuration) is
 a snap.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.11
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Temporal Release Strategy

[Patrick A. Ouellette]

Since I first became involved with Debian (1997 ish), people have
complained about the slow release cycle.  This has caused me to draw the
conclusion that there will always be someone who complains about the
frequency (either slow or fast) of official releases.

BACKGROUND COMMENTARY:

The advent of testing and package pools held the promise to shorten the
release cycle and improve the stability of the Debian stable release.
The debate can rage on in other circles as to the success or failure of
that statement.

There may be another way.  The institution of package pools has
essentially reduced the concept of a release to a package index file
generated on a particular day.  As long as the packages listed in the
Packages.gz file are available in the package pool, that Packages.gz
file describes a "release."  The "release" may not be stable, and may
contain many RC bugs, but it is a definite, reproducible collection of
packages that can be installed.

The automated progression of packages from unstable to testing has made
testing a viable distribution for many users.  That is not to say
testing is suitable for all users and all tasks, but rather that testing
is frequently "stable enough" for many uses.  I will venture to say the
promotion process from unstable to testing is an unqualified success.

PROPOSAL FOR DISCUSSION:

I suggest we can eliminate the traditional concept of a "release"  with
the addition of another step in the progression from unstable to
stable.  Additionally, all promotion of packages from one step to the
next will be automated according to strict rules.

The progression I see is:

unstable -> testing -> candidate -> stable

The existing rules for promotion from unstable to testing continue to be
used.

Promotion from testing to candidate requires meeting the same rules as
promotion from unstable to testing with the following exceptions:
packages must be in testing for at least 3 months, and have no release
critical bugs.

Promotion from candidate to stable would follow a similar pattern, with
a time in candidate requirement of 3 additional months.

Security updates are then provided for packages for 36 months after they
have been replaced with a newer version in stable.

No changes are made to experimental.

CD image generation can be run from any stage.  I would suggest monthly
image creation from candidate, and quarterly generation from stable.

For purists who insist on "blessing" a collection of packages proven to
work together with a release name & number, they can be satisfied if we
"release" driven by content changes (new libc, new desktop, whatever)
instead of the calendar.



Pat

-- 

Patrick Ouellette
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Amateur Radio: KB8PYM 



signature.asc
Description: Digital signature

Re: Bug#304401: ITP: libstatgrab -- library providing interface to system statistics

[W. Borgert]

Webpage: http://www.i-scream.org/libstatgrab/
not www.example.org :-)

It would be great, if you package pystatgrab
(http://www.i-scream.org/pystatgrab/) as well.


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

Re: Temporal Release Strategy

[Gunnar Wolf]

Patrick A. Ouellette dijo [Wed, Apr 13, 2005 at 10:12:31AM -0400]:
> (...)
> The progression I see is:
> 
> unstable -> testing -> candidate -> stable
> 
> The existing rules for promotion from unstable to testing continue to be
> used.
> 
> Promotion from testing to candidate requires meeting the same rules as
> promotion from unstable to testing with the following exceptions:
> packages must be in testing for at least 3 months, and have no release
> critical bugs.
> 
> Promotion from candidate to stable would follow a similar pattern, with
> a time in candidate requirement of 3 additional months.

Umh... There is a simple problem with your proposal: Most of my
packages are quite stable, yes, but some would never reach candidate
status. Try uploading a package every five days (with priority=low) -
it will never reach testing, as the old version disappears under the
new one.

Yes, this could be sorted out, so that old versions no longer
disappear until ${fateful_event}. This would create more problems: If
a RC bug report is closed, you will have to keep track of which upload
did the trick, not considering any of the ones below it for testing or
candidate. 

Finally, this would make any library migration a real nightmare :-/
You'd have to somehow keep the archive synchronized, doing something
similar to what is currently done re:testing, but on a _much_ broader
scale. Tracking dependencies and FTBFS bugs could become basically
impossible. 

...But if you come up with an implementation, I'll just shut up :)

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
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]

Bug#304495: ITP: ttf-arphic-newsung -- "AR PL New Sung" Chinese TrueType font by FireFly

[Kanru Chen]

Package: wnpp
Severity: wishlist
Owner: Kanru Chen <[EMAIL PROTECTED]>

* Package name: ttf-arphic-newsung
* Version : 1.3.0
* Upstream Author : FireFly <[EMAIL PROTECTED]>
* URL : http://www.study-area.org/apt/firefly-font/
* License : APL(Arphic Public Licence)
Description   : "AR PL New Sung" Chinese TrueType font by FireFly

"AR PL New Sung" is a high-quality Chinese TrueType font (fireflysung.ttf)
made by FireFly. It contained two sets of font glyph, Simplified Chinese
and Traditional Chinese. This font combined AR PL Mingti, AR PL Sungti
and FireFly's embedded bitmap font so it can have pretty nice look at
both large size and small size.

Firefly clearly release his font which combined with other APL fonts
under APL.  I reopen this bug again because many people like to see this
font enter debian. Since it's license is clear and compact with DFSG,
why not? :)

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to zh_TW.UTF-8)


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

Bug#304510: ITP: ed2k-hash -- A command line tool for creating eDonkey2000 hash links.

[Luke Reeves]

Package: wnpp
Severity: wishlist
Owner: Luke Reeves <[EMAIL PROTECTED]>

I have the initial attempt at a packge at
http://www.neuro-tech.net/debian/.  See also bug #259863, an RFP for
this software.

* Package name: ed2k-hash
  Version : 0.3.3
  Upstream Author : Tim-Philipp Mller <[EMAIL PROTECTED]>
* URL : http://ed2k-tools.sourceforge.net/
* License : GPL
  Description : A command line tool for creating eDonkey2000 hash links.

ed2k_hash is a little command line utility that takes an number of files
and outputs their ed2k-links.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8.1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Bug#304509: ITP: libcmd-ruby -- library for building line-oriented command interpreters in Ruby

[David Nusinow]

Package: wnpp
Severity: wishlist
Owner: David Nusinow <[EMAIL PROTECTED]>

* Package name: libcmd-ruby
  Version : 0.7.2
  Upstream Author : Marcel Molina Jr. 
* URL : http://code.vernix.org/cmd/
* License : MIT
  Description : library for building line-oriented command interpreters in 
Ruby

This is a library for building line-oriented command interpreters in Ruby.
Simply inherit from cmd's Cmd class, and methods whose names start with do_
become interactive commands. cmd is inspired by the Python library  of the
same name, but offers a distinctive Ruby feel and several additional
features.

---

Note: I have an ITP open on libformatr-ruby (#295171) and both this library
and formatr are very small, so I am hesitant to put them in their own
packages. I plan instead to create an aggregate package (libruby-extras or
something) with non-standard ruby libs that are helpful. If anyone would
like to add some small ruby libs to this package and co-maintain it with
me, please let me know so we can set up an alioth project for it.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#304508: Gnome + realplayer10 problem

[Stephane Savage]

Package: general
Version: 20051304

Hi I'm using the latest Sarge debian version.

I've encountered something weird and I'm not sure if it has been
reported.

Using the latest RealPlayer combine with gnome and any browser, I get
the following when trying to visualise some realplayer stream movies
on
the internet:

-My desktop split in two and it completely freezes.  The split occurs
from left to right, so my left side is shown on the right of the
screen
and vice versa.  The only solution I found to get out of this is to
restart the GUI.

Under kde I don't get this problem and I can visualize stream with
realplayer without any problems.

hardware:
-geforce 4 128mb card with the latest nvidia driver.
-1 gig ram
-2.5 ghz intel 4

I got this problem last week and didn't log back in Gnome since.  I
could try to generate the problem again if you need further details.

Regards,

Stephane Savage


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

Bug#304513: RFP: kernel-patch-v4l2-2.4

[Martin Samuelsson]

Package: wnpp

* Package name: kernel-patch-v4l2-2.4
  Version : 2.4.26-1
  Upstream Author : Gerd Knorr <[EMAIL PROTECTED]>
* URL : http://dl.bytesex.org/patches/
* License : GPL
  Description : video4linux2 patch against 2.4 kernels


For the reason that I need to use another module that is only existing 
for 2.4 kernels I'm stuck with 2.4 on one system.

I do not know how high the interest is in having this in Debian, but my
intention is to give creating packages for myself a try. I am however
already a bit stuck.

Is there a guide somewhere on how to create kernel-patch packages? There
is nothing on it in the developers reference as far as I can see,
neither did I find anything in the policy manual, and google turns out
fruit less as well.

Of course a kernel-patch package should place it's diffs in
/usr/src/kernel-patches/diffs/ and have some appropriate apply and
unapply scripts, but what are the exact requirements of those scripts?

Any help would be appreciated.
--
/Martin


signature.asc
Description: Digital signature

Re: Temporal Release Strategy

[Patrick A. Ouellette]

On Wed, Apr 13, 2005 at 11:11:13AM -0500, Gunnar Wolf wrote:
> Date: Wed, 13 Apr 2005 11:11:13 -0500
> From: Gunnar Wolf <[EMAIL PROTECTED]>
> Subject: Re: Temporal Release Strategy
> To: "Patrick A. Ouellette" <[EMAIL PROTECTED]>,
>   debian-devel@lists.debian.org
> 
> Patrick A. Ouellette dijo [Wed, Apr 13, 2005 at 10:12:31AM -0400]:
> > (...)
> > The progression I see is:
> > 
> > unstable -> testing -> candidate -> stable
> > 
> > The existing rules for promotion from unstable to testing continue to be
> > used.
> > 
> > Promotion from testing to candidate requires meeting the same rules as
> > promotion from unstable to testing with the following exceptions:
> > packages must be in testing for at least 3 months, and have no release
> > critical bugs.
> > 
> > Promotion from candidate to stable would follow a similar pattern, with
> > a time in candidate requirement of 3 additional months.
> 
> Umh... There is a simple problem with your proposal: Most of my
> packages are quite stable, yes, but some would never reach candidate
> status. Try uploading a package every five days (with priority=low) -
> it will never reach testing, as the old version disappears under the
> new one.

If you upload a package to unstable every 5 days with a low priority it
will not migrate from unstable under the current system without manual
intervention.

> 
> Yes, this could be sorted out, so that old versions no longer
> disappear until ${fateful_event}. This would create more problems: If
> a RC bug report is closed, you will have to keep track of which upload
> did the trick, not considering any of the ones below it for testing or
> candidate. 

The only time you need to worry about old versions is in the final
stable tree.  If a package in stable depends on another package with a
== or <= version dependency, the promotion of the new package would
break stable.  This means one of two things needs to happen: either the
old package needs to be upgraded or the old package needs to be removed.
Policy would have to be set on what the proper action is for orphaned
packages.  I don't think it too unreasonable to expect an actively
maintained package to be updated within 9 months of the upload of an
updated dependency.  I don't think it too unreasonable to remove an
orphaned package that reaches that state either.  People have complained
about the number of packages - now we have a natural method to remove
packages from the distribution that are no longer used.

A package must be in unstable for at least 2 days according to the
"rules" in the FAQ.  The preferred time is 10 days.  Uploading every 5
days with low priority should just replace the package with the newer
version and start the clock again.  If your package is unable to meet
the 3 months time in testing (or the 10 day time in unstable) due to 
frequent uploads, then it really is not a stable package - is it.  
That is the point of having a "stable" branch - it should change slowly 
and the packages in the stable area should be, well, stable.

If an RC bug report is closed, the new package is uploaded to unstable
and must run through the process.  The idea being that by the time your
package reaches candidate or stable status it really is stable and
contains no known RC bugs.

> 
> Finally, this would make any library migration a real nightmare :-/
> You'd have to somehow keep the archive synchronized, doing something
> similar to what is currently done re:testing, but on a _much_ broader
> scale. Tracking dependencies and FTBFS bugs could become basically
> impossible. 

The rules for migration from unstable to testing cover the library
migration issue.  If a package has a depends on one or more other
packages, all must exist and be satisfied for migration to occur.  So we
either already have this problem, or we don't.  If we have the problem,
we need to solve it anyway

> 
> ...But if you come up with an implementation, I'll just shut up :)
> 

Discussion first.  Then consensus, then implementation.


Pat

--
Patrick Ouellette
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Amateur Radio: KB8PYM 


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

Re: Bug#304513: RFP: kernel-patch-v4l2-2.4

[martin f krafft]

also sprach Martin Samuelsson <[EMAIL PROTECTED]> [2005.04.13.1938 +0200]:
> Is there a guide somewhere on how to create kernel-patch packages?

Nope, until I find the time... the dh-kpatches package makes it
rather easy though, provided your patches are single files per
kernel release. So check out that package and some kernel-patch
packages using it.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
"i have smoked pot. it is a stupid business, like masturbation."
 -- thomas pynchon


signature.asc
Description: Digital signature

Bug#304517: ITP: cacao -- Java virtual machine

[Evan Prodromou]

Package: wnpp
Severity: wishlist
Owner: Evan Prodromou <[EMAIL PROTECTED]>


* Package name: cacao
  Version : 0.91
  Upstream Author : Cacao Team <[EMAIL PROTECTED]>
* URL : http://www.cacaojvm.org/
* License : GPL
  Description : Java virtual machine

Cacao is a JIT-compiling Java virtual machine which claims to support
Java at the 1.4 JDK level. Cacao uses GNU classpath for its standard
library.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.10-5-k7
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)


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

Lesstif bug breaking other software, no action for two months

[Kimmo Jukarainen]

There are two[1] open bugs: 

  * #287187 assigned to lesstif1-1, priority important
  * #279402 assigned to xastir, priority minor[2]

that are essentially the same: A bug in lesstif breaks menus of 
software that are using it.

I've provided information about a working patch on both of these 
bugs (and tagged them with +patch) over two months ago, but there 
hasn't been any maintainer action on either of these bugs since 
then - nor in lesstif in general. Meanwhile lesstif has been NMU'd
twice during last month.

Now, as sarge's release seems to be really approaching I've started 
to wonder if we are going to be stuck with this annoyance until etch.

Would a NMU for this be allowed, and even accepted in sarge, if 
someone[3] is willing to do a third NMU in a row for lesstif?

-kimju

[1] As I am not the originator of neither of those bugs, I've been 
vary on merging them or reassigning #279402 to lesstif (where 
it belongs).

[2] In my opinion, minor is too low priority - while this bug doesn't
make the software totally unusable, it's quite annoying and makes
it very hard to use for new users (who doesn't remember, or even 
know, what the incorrectly displayed menu items really say).

[3] I'm not a DD, but I can provide the patch as a ready to be build 
diff on top of lesstif 1:0.93.94-11.2 if that will be any help.


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

unsubscribe

[Pasca Chenevas-paule]

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

Bug#304521: ITP: wanna-build -- Database management for package (re-)compilation/status control

[Jesus Climent]

Package: wnpp
Version: N/A; reported 2005-04-13
Severity: wishlist

* Package name: wanna-build
  Version : 2005.04.13
  Upstream Author : FTP Archives -- <[EMAIL PROTECTED]>
* URL : deb http://db.debian.org/ debian-admin/
* License : GPL
  Description : Database management for package (re-)compilation/status 
control

(Although the debian/copyright says you can access it from
http://svn.cyberhqz.com/svn/wanna-build, it is not working at the time of this
writing).

The complete long description follows:

  wanna-build maintains a database of packages which need to be
  (re-)compiled. It keeps track of packages in need of a compilations,
  in failed state, uploaded, installed, in need of dependencies, ...
  .
  wanna-build is part of the Debian autobuilder infrastructure.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux genarin 2.4.26 #1 Thu Apr 15 17:45:21 CEST 2004 i686
Locale: LANG=es_ES, LC_CTYPE=en_US

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

So, Lord Helmet, at last we meet again for the first time for the last time.
--Lone Starr (Spaceballs)


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

Re: Minimizing ld dependencies with --as-needed

[Tollef Fog Heen]

* Ralf Wildenhues 

| I would be much happier if someone with time would just help to put
| this into libtool properly as an option (and possible adjust pkg-config,
| FWIW).  I'm pretty sure it would minimize the combined amount of work,
| with increased benefit.

pkg-config has the necessary patches now, but the support is disabled
by default in Debian.  It'll be enabled post-sarge.

-- 
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: Bug#304521: ITP: wanna-build -- Database management for package (re-)compilation/status control

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jesus Climent <[EMAIL PROTECTED]> writes:

> * Package name: wanna-build
>   Version : 2005.04.13
>   Upstream Author : FTP Archives -- <[EMAIL PROTECTED]>
> * URL : deb http://db.debian.org/ debian-admin/

If you haven't already, you might like to pick up the manpages I wrote
from here: http://people.debian.org/~rleigh/buildd/

I posted this to the buildd-disc list quite some time ago, but they
were never committed.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCXX0wVcFcaSW/uEgRAqYOAJ9e4yF0CxOVuMovzI9v5QB9sIJnagCfdXMZ
4YUiYx8gTLk/LPA9fm8Fcb8=
=nE2r
-END PGP SIGNATURE-


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

Re: Bug#304521: ITP: wanna-build -- Database management for package (re-)compilation/status control

[Jesus Climent]

On Wed, Apr 13, 2005 at 09:12:47PM +0100, Roger Leigh wrote:
> 
> > * Package name: wanna-build
> 
> If you haven't already, you might like to pick up the manpages I wrote
> from here: http://people.debian.org/~rleigh/buildd/

Thanks. I will (I had already taken wanna-build.1) and will modify them
accordingly to the additions i have already made.

Thanks again!

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

A minute ago this was the safest job in the world. Now it's turning into 
a bad day in Bosnia.
--Soap (Lock, Stock and Two Smoking Barrels)


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

Bug#304554: ITP: weathermap4rdd -- script that generates picture network links utilization

[Julien Danjou]

Package: wnpp
Severity: wishlist
Owner: Julien Danjou <[EMAIL PROTECTED]>

* Package name: weathermap4rdd
  Version : 1.1.1g 
  Upstream Author : Alexandre Fontelle <[EMAIL PROTECTED]>
* URL : http://weathermap4rrd.tropicalex.net/
* License : GPL
  Description : script that generates picture network links utilization

Network Weathermap4RRD is a perl script that generates picture network
links utilization. Data used to create graph are acquired from RRDTool
databases and are displayed as two ways colored arrows on a map
representing the logical topology of the network.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686-smp
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)


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

Re: Temporal Release Strategy

[Wesley J. Landaker]

On Wednesday 13 April 2005 08:12, Patrick A. Ouellette wrote:
> PROPOSAL FOR DISCUSSION:
>
> I suggest we can eliminate the traditional concept of a "release"  with
> the addition of another step in the progression from unstable to
> stable.  Additionally, all promotion of packages from one step to the
> next will be automated according to strict rules.
>
> The progression I see is:
>
> unstable -> testing -> candidate -> stable

I like the spirit of this idea, although I'm sure the details need a lot of 
working over. (This could, but wouldn't need to *replace* releases--it 
could simply augment the release creation process.)

I'm interested to hear other's ideas on why this is/is not a good idea, and 
what technical/logistical hurdles would prevent this from being done.

-- 
Wesley J. Landaker <[EMAIL PROTECTED]>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgp3g2JDBTT46.pgp
Description: PGP signature

Popular software for download. License. Adobe, Microsoft, MacroMedia. For PC and Macintosh

[EpigonEion]

www.dkh9y2x1h6vuwyd.mhdla.com


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

Re: Lesstif bug breaking other software, no action for two months

[Hamish Moffatt]

On Wed, Apr 13, 2005 at 10:06:43PM +0300, Kimmo Jukarainen wrote:
> There are two[1] open bugs: 
> 
>   * #287187 assigned to lesstif1-1, priority important
>   * #279402 assigned to xastir, priority minor[2]
> 
> that are essentially the same: A bug in lesstif breaks menus of 
> software that are using it.
> 
[..]
> [1] As I am not the originator of neither of those bugs, I've been 
> vary on merging them or reassigning #279402 to lesstif (where 
> it belongs).

Go ahead and reassign the xastir bug if you like.

According to Echelon (on db.debian.org) the maintainer has been active
this month (seen on debian-bugs-closed). So an MU would be appreciated.

Hamish (xastir maintainer)
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Bug#304570: ITP: codeblocks -- Code::Blocks is a free C/C++ IDE built

[Francois-Denis Gonthier]

Package: wnpp
Severity: wishlist
Owner: "Francois-Denis Gonthier" <[EMAIL PROTECTED]>


* Package name: codeblocks
  Version : x.y.z
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Description : Code::Blocks is a free C/C++ IDE built.

Code::Blocks is a free C/C++ IDE built specifically to meet the most
demanding needs of its users. It has been designed, right from the
start, to be extensible and configurable... Code::Blocks is built around
a plugin framework that allows it to be extended through the use of
external libraries (plugins). Actually, much of Code::Blocks
functionality already available, is provided by plugins. Code::Blocks
even includes a plugin creation wizard to help you create your own
plugins easily!

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.9
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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