Re: USE flags ??

[Brendan]

On Sunday 24 October 2004 17:42, Jim Bailey wrote:
> It is alright but there is always room for improvement, I think emerge
> has the edge as a packet management tool. ;-P

Could you clarify that statement? That may take the cake as the 
least-substantive comment I have seen on here in awhile. Do you know the 
differences or each? Please, let us know.

USE flags. Check
Continue...

Re: Ubuntu discussion at planet.debian.org

[Jonas Meurer]

On 24/10/2004 Mike Hommey wrote:
> If people test unstable, then it's unstable we should release, not
> testing. As somebody said in this thread not enough people are trying
> testing, and that's one of our problems in the release cycle.

just to say that, i know of many debian users (me included) that run
unstable on their development machine, but testing on inofficial,
nonrelevant or in any way non-high-availabilty servers.

and the problem with freezing unstable is, that after release unstable
will become rather unusable, as not all developers will stop with
development of new and significant changes in their software.

bye 
 jonas

Re: Ubuntu discussion at planet.debian.org

[Michael K. Edwards]

> Steve Langasek

> It is not correct.  At the time testing freezes for sarge, there are likely
> to be many packages in unstable which either have no version in testing, or
> have older versions in testing.  The list of such packages is always visible
> at .  While
> it's a goal of the release team to ensure that *incidental* issues don't
> keep package fixes/updates out of testing, there are plenty of package
> updates which will come too late for consideration, or will be RC-buggy in
> their own right, that won't be part of sarge.

That's the URL I was trying to remember; thanks.  That's what I meant
by "the interesting thing about testing is the dependency analysis". 
I think the information in update_excuses mostly supports the
"convergence is readiness" hypothesis.

It seems to me that Jérôme's observation also takes into account the
fact that "experimental" exists, so that changes that maintainers know
would break britney don't get put into unstable late in the cycle. 
Without that, I wouldn't expect testing -> unstable convergence ever
to happen.  But don't you think that, until testing converges (nearly)
to unstable, it's hard to know how much of testing will FTBFS on
testing itself?

Although it does sometimes happen that an update breaks something that
works in the version in "testing", I think it's more common for an RC
bug to apply to earlier versions as well, even when it's an FTBFS for
something that used to build.  (That often seems to mean that one of
the build-deps evolved out from under the package or got removed
because it was old or broken, and the source that's made it into
"testing" won't build there either.)  So I would expect that the vast
majority of RC bugs filed against packages in sid have to be handled
by really fixing them -- and letting the fix propagate into testing --
or excluding the package from sarge.

Freezing base+standard at this stage saves the package maintainers the
trouble of uploading to experimental instead of unstable for a while,
and makes it a lot easier for the RMs to allow fixes in selectively. 
Otherwise, progressive freezes don't really alter this analysis.

> And immediately *after* the freeze point, I think we can safely expect
> unstable to begin diverging even further from testing.

True enough.  In a lot of commercial software development, the
interval between "code freeze" / VC branch and release is necessary so
that QA can finally do a full run through the test plan and the senior
coders are free to fix any RC bug they can.  Everybody else works on
the trunk.  So apply the "testing (almost) = unstable" criterion to
the freeze point rather than the release point, with the understanding
that the packages for which it's not true are exactly the ones that
need more / different attention during the freeze than they were
getting before.

> While getting KDE updates into testing has been a significant task in the
> past, I'm not aware of any point during the sarge release cycle when KDE has
> been a factor delaying the release.

Er, does the current situation fit?  An awful lot of update_excuses
seems to boil down to Bug#266478, and it's hard to see the RC bug
count on KDE 3.2 apps dropping by much until the debate about letting
KDE 3.3 in is resolved.  I think the C++ toolchain issues I mentioned
were a factor in KDE 3.2 propagation into testing being delayed to the
point that KDE 3.3 is even worth discussing.  But I haven't been
following those issues at all lately, so don't take my opinion on this
too seriously; maybe I should just ignore that portion of
update_excuses.

Cheers,
- Michael

Re: Preparation of the next stable Debian GNU/Linux update [Oct 24]

[Michelle Konzack]

Hello Martin and *, 

Am 2004-10-24 11:24:26, schrieb Martin Schulze:
> Preparation of the next stable Debian GNU/Linux update
> ==
> 
> An up-to-date version is at .

For some minutes I have updated my local mirror and found a serious Problem on

ftp://ftp.de.debian.org/debian-security

in the woody/updates mirror. Original *.tag.gz files are missing,
but the *.diff.gz and *.dsc are still:

  ( 'stdin' )___
 /
| From: tddebmirror <[EMAIL PROTECTED]>
| To: [EMAIL PROTECTED]
| Subject: Updated Debian mirrors
| Date: Tue, 26 Oct 2004 01:56:54 +0200
| 
| Following mirrors are updated:
| ==
| 
| Binary:  ftp://ftp.de.debian.org/debian-security woody/updates/main i386
| Sources: ftp://ftp.de.debian.org/debian-security woody/updates/main
| 
| Logfile:
| 
| 
| 2004-10-26 01:55:45 : Reading tddebmirror.conf
| 2004-10-26 01:55:45 : Reading values for Server 1
| 2004-10-26 01:55:45 : 1 : Downloading Packages.gz
| 2004-10-26 01:55:49 : 1 : Creating file list
| 2004-10-26 01:55:50 : 1 : Get target directories.
| 2004-10-26 01:55:50 : 1 : Create target directories.
| : 1 : Erase old files.
| : 1 : Create download list.
| 2004-10-26 01:56:08 : 1 : Nothing to download.
| 2004-10-26 01:56:08 : 1 : Downloading Sources.gz
| 2004-10-26 01:56:12 : 1 : Get source directories.
| 2004-10-26 01:56:12 : 1 : Make target directories.
| 2004-10-26 01:56:12 : 1 : Create download list.
| 2004-10-26 01:56:19 : 1 : Erase old files.
| : 1 : Create download list.
| 2004-10-26 01:56:31 : 1 : Downloading sources.
| 2004-10-26 01:56:31 : 1 :  : bind9_9.2.1.orig.tar.gz
| 2004-10-26 01:56:33 : 1 :  : kdegames_2.2.2.orig.tar.gz
| 2004-10-26 01:56:36 : 1 :  : lv_4.49.4.orig.tar.gz
| 2004-10-26 01:56:37 : 1 :  : lynx_2.8.4.1b.orig.tar.gz

I have checke the server  manualy,
but these four files are not there.

| 2004-10-26 01:56:38 : 1 : 17957 : libapache-mod-ssl_2.8.9-2.4.diff.gz
| 2004-10-26 01:56:40 : 1 :   678 : libapache-mod-ssl_2.8.9-2.4.dsc
| 2004-10-26 01:56:42 : 1 :752613 : libapache-mod-ssl_2.8.9.orig.tar.gz
| 2004-10-26 01:56:51 : 1 :  : osh_1.7.orig.tar.gz

And here is the fiveth file missing...

| 2004-10-26 01:56:53 : 1 : Downloading finished.
| 2004-10-26 01:56:53 : 1 : Create Sources.gz.
| 2004-10-26 01:56:54 : Reading values for Server 2
| 2004-10-26 01:56:54 : No server availlable. Stoping here.
| 
 \__

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/ 
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Waiting for unfinished jobs....

[Anibal Monsalve Salazar]

Hello,

Package harbour is FTBFS on alpha, s390, m68k, powerpc and mips, as
you can see at:

http://buildd.debian.org/build.php?pkg=harbour
 
Could someone shed some light on this problem?

A build log extract follows.

[...]
gcc -I. -I../../../../include -Wall -g  -c ../../hbmlang.c -ohbmlang.o
../../../../source/compiler/linux/gcc/harbour ../../hbmake.prg  -n -q0 -w -es2 
-gc0 -I../../ -I../../../../include
make[4]: *** wait: No child processes.  Stop.
make[4]: *** Waiting for unfinished jobs
make[4]: *** wait: No child processes.  Stop.
make[3]: *** [descend] Error 2
make[1]: *** [first] Terminated
make[2]: *** [first] Terminated
make: *** [build-stamp] Terminated
Build killed with signal 15 after 150 minutes of inactivity
[...]

Anibal Monsalve Salazar
--
 .''`. Debian GNU/Linux  |
: :' : Free Operating System | http://www.debiancolombia.org/
`. `'  http://debian.org/| http://www-personal.monash.edu/~anibal
  `-


signature.asc
Description: Digital signature

Bug#278289: ITP: apt-dupdate -- diff-based update of APT's index files

[Eduard Bloch]

Package: wnpp
Severity: wishlist

* Package name: apt-dupdate
  Version : 0.0.1
  Upstream Author : me
* License : BSD
  Description : diff-based update of APT's index files

apt-dupdate is beeing written right now. The server part is almost done,
the client should be not a big deal. apt-dupdate is similar to the
unofficial apt-pupdate package and uses the same base idea: the
Packages/Sources files are updated using diff/patch files to the
previous version which is already downloaded. The advantage is
impressing: daily diffs for Sid are about 35KiB in size (average,
bzip2ed) compared to >=3MiB downloaded by APT (for main, gziped).

The advantages of apt-dupdate compared to apt-pupdate:

 - it will actually work. bjb seems to be MIA since the big server
   compromise, the diff update scripts on people.d.o are apparently not
   restored
 - in difference to apt-pupdate, I do not use chains of small diffs,
   based on days and managed by the server. Instead, the server provides
   the patch for a md5sum which contains the diffs between the version
   of the client and the current one (when the server has data for the
   old version, of course)
 - it will be faster on high-latency links. apt-pupdate AFAICS needed
   n*2+2 http requests where n=#days. apt-dupdate will use exactly one
   request.
 - it will be faster on low-speed links since one chunk of data
   compresses much better than n small chunks. apt-dupdate will use
   bzip2 instead of gzip.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.9
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8

Bug#278288: ITP: python-gtkmvc -- Model-View-Controller (MVC) implementation for pygtk

[Johannes Jordens]

Package: wnpp
Severity: wishlist


* Package name: python-gtkmvc
  Version : x.y.z
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Description : Model-View-Controller (MVC) implementation for pygtk

 This MVC for pygtk2 helps with writing well structured code by
 splitting
 the program's code into three distinctive sections. A program
 written using this MVC pattern usually contains four parts: The view
 (providing access to the Glade widget tree), the controller (providing
 glue functions), the model (providing the abstract logic) and the main
 program (simply connecting the three parts mentioned before).
 For more information please visit 

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

Location of Type 1 fonts

[Jaldhar H. Vyas]

I'm confused as to where to place Type 1 fonts.  Should they go into
/usr/X11R6/lib/X11/fonts/Type1 or /usr/share/fonts/type1?  Why do some TeX
packages have their fonts under /usr/share/texmf/fonts/type1?


-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/

Bug#278255: ITP: rdflib -- A python library for working with RDF

[Alberto Rodriguez Galdo]

Package: wnpp
Severity: wishlist

* Package name: rdflib
  Version : 2.0.4
  Upstream Author : Daniel Krech <[EMAIL PROTECTED]>
* URL : http://rdflib.net
* License : own license, free, osi certified
  Description : A python library for working with RDF


RDFLib is a Python library for working with RDF, a simple yet powerful
language for representing information. The library contains an RDF/XML
parser/serializer, a TripleStore, an InformationStore and various store
backends.

Re: Drop testing

[Thomas Bushnell BSG]

Anthony Towns  writes:

>   * One of Testing's goals was to be 95% releasable at all times.
>   * It hasn't been.
>   * Why not?
>  (a) RC bugs
>  (b) Can't install it
>  (c) Security vulnerabilities

This is the crux of the problem, I think, but I'm a little confused.

How does (a) contribute to this?  The assumption behind an RC bug is
"we can't release with this bug unfixed".  But the problem is that, of
course, we *do*, and we *have*, because many RC bugs are in things we
have already released.  In other words, woody has RC bugs in it Right
Now.  But that doesn't stop us from continuing to call it stable.

So the RC bugs should not be blocking release unless they are *new* RC
bugs which don't already exist.  In other words, a new stable release
shouldn't be worse, but it doesn't have to be maximally better.  It
shouldn't have new RC bugs, but it's tolerable if it continues to have
the same old ones.

As for (b), the solution, if there is one, is to have the installer
folks spend time targeting testing all the time.  I don't know if this
is actually worth the effort or not.

As for (c), the solution in my opinion is to allow security fixes to
migrate into testing without having to wait for the normal delay.

Thomas

Processed: reassign 278246 to general

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 278246 general
Bug#278246: Cyrillic letters are displayed as double-width in most places
Warning: Unknown package 'generic'
Bug reassigned from package `generic' to `general'.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Re: Bug#277582: ITP: kwin-baghira -- A MacOSX-like theme for Apple junkies ;)

[Christoffer Sawicki]

IMHO, the following names makes most sense since they
1) tell where the theme/style/icons/whatever is/are used
2) follow some current "naming schemes" [0]

 qt-styles-foobar
 kwin-decorations-foobar
 kde-icons-foobar

The construction of these package names is pretty clear.

[0] -
Packages currently in the Debian archive:

 2 - kde-icons-crystal - Crystal icon theme for KDE
21 - gtk-engines-begtk - BeOS-like theme for GTK+
20 - gtk2-engines-cleanice - CleanIce themes for GTK+ 2.x
 ^
(Number of packages following this naming scheme)

Yes, I'm aware of that this argument is not perfectly valid since some 
packages could be renamed to comply with a better naming scheme.
-

*/ Christoffer Sawicki <[EMAIL PROTECTED]>

Bug#278243: ITP: libhttp-cache-transparent-perl -- cache http requests transparently

[Kenneth Pronovici]

Package: wnpp
Severity: wishlist

  Package name: libhttp-cache-transparent-perl
  Version : 0.4
  Upstream Author : Mattias Holmlund
  URL : http://www.cpan.org/modules/by-module/HTTP/
  License : Perl
  Description : cache http requests transparently
 HTTP::Cache::Transparent is an implementation of HTTP GET that keeps a
 local cache of fetched pages to avoid fetching the same data from the
 server if it hasn't been updated. The cache is stored on disk and is
 thus persistent between invocations.
 . 
 The http-headers If-Modified-Since and ETag are used to let the server
 decide if the version in the cache is up-to-date or not.  All
 http-requests are made through the LWP module. Data is stored on disk
 by the Storable module. Digest::MD5 is used for creating a hash of the
 URL.

I'm packaging this because XMLTV 0.5.36 will recommend it.

KEN

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-k7
Locale: LANG=en, LC_CTYPE=en_US (ignored: LC_ALL set to en_US)

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>


pgp6i41fH8Tbs.pgp
Description: PGP signature

Re: what is /var/backup for?

[Bernd Eckenfels]

On Mon, Oct 25, 2004 at 09:13:16AM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 25 Oct 2004, Bernd Eckenfels wrote:
> > On Mon, Oct 25, 2004 at 06:37:10AM -0400, Kevin Mark wrote:
> > > Is there a policy for /var/backup and 
> > 
> > /var/backups is defined as a reserved legacy by the FHS 2.3.
> 
> Where did it go?  Or did they just remove it altogether?

It was not (never?) defined/mentioned in 2.2, dont know for older versions.

Gruss
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o 1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+497211606754
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: an idea for next generation APT archive caching

[martin f krafft]

also sprach Wouter Verhelst <[EMAIL PROTECTED]> [2004.10.22.2121 +0200]:
> Oh, absolutely. One way could be to talk to the apt-cacher and
> apt-proxy developers and help fixing bugs in their software,
> instead of calling your not even fully thought out idea (which
> surely hasn't proven itself) the "next generation".

It's an RFC. It's an idea that I liked. Sorry for claiming it next
generation.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: software updates file in /usr -- policy bug?

[Santiago Vila]

On Mon, 25 Oct 2004, martin f krafft wrote:

> Hi all,
> 
> apt-spy and pciutils (and possibly others) contain methods to update
> a database integral to their operation.
> 
>   - `apt-spy update` downloads the list of available Debian mirrors
> to /usr/share/apt-spy (see #277816).
> 
>   - `update-pciids` downloads a new /usr/share/misc/pci.ids
> 
> I think these are both in violation with the FHS, which states
> (Chapter 4, emphasis mine, using caps instead of asterisks for
> readability):
> 
>   "/usr is shareable, READ-ONLY DATA. That means that /usr should be
>   shareable between various FHS-compliant hosts and MUST NOT BE
>   WRITTEN TO."
> 
> The apt-apy maintainer thinks this is okay because (from the bug
> report):
> 
>   apt-spy does not "dynamically update".  It updates *if and ONLY
>   if* you ask it to.  I do not see this as a violation of the spirit
>   of the FHS.  I'm more than happy to have discussion about this.
> 
> If this holds, then why does `apt-get update` modify files in
> /var/lib/apt/lists, and why is /var/lib/dpkg/status not really
> /usr/lib/dpkg/status?
> 
> Well, two wrongs don't make a right, nor does APT/dpkg's choice for
> /var make using /usr for changeable resource data wrong for
> everyone, but I still think that apt-spy's mirror list and the PCI
> IDs should be kept in /var, since they are variable data.

Having a program asking the user "do you want to violate the FHS?"
does not make it not to be a violation. I would much prefer not to
have to answer such questions.

Some people might want to have /usr mounted read-only except when
using dpkg/apt to upgrade the system. The FHS says this should work,
so any program which fails because it tries to write to /usr could be
considered as a bug.

Even if the file is updated only by the postinst, it is useful to know
that you can recover a broken system from scratch by having:

* A backup copy of /etc, /var, /home, /usr/local, etc. (but not /usr).
* The list of installed packages.

I think this is a good property of the system that we should try to keep.

Would the user benefit from having the freedom to change apt-spy or pci.ids?
If yes, then those files would be much better placed in /etc. Just because
it is a "database" does not mean it may not be modified by the user.
Think about /etc/services for example.

Re: Drop testing

[Graham Wilson]

On Sun, Oct 24, 2004 at 05:35:57PM +0200, Eduard Bloch wrote:
> * Nikita V. Youshchenko [Sun, Oct 24 2004, 03:53:23PM]:
> > Probably there are non-technical problems with the uncoming release. But
> 
> There are, as described before. For example, I cannot see any life sign
> of our FTP masters. How comes?

I just had two packages I work on accepted into the archive. That means
the FTP masters are alive and active, right?

-- 
gram

software updates file in /usr -- policy bug?

[martin f krafft]

Hi all,

apt-spy and pciutils (and possibly others) contain methods to update
a database integral to their operation.

  - `apt-spy update` downloads the list of available Debian mirrors
to /usr/share/apt-spy (see #277816).

  - `update-pciids` downloads a new /usr/share/misc/pci.ids

I think these are both in violation with the FHS, which states
(Chapter 4, emphasis mine, using caps instead of asterisks for
readability):

  "/usr is shareable, READ-ONLY DATA. That means that /usr should be
  shareable between various FHS-compliant hosts and MUST NOT BE
  WRITTEN TO."

The apt-apy maintainer thinks this is okay because (from the bug
report):

  apt-spy does not "dynamically update".  It updates *if and ONLY
  if* you ask it to.  I do not see this as a violation of the spirit
  of the FHS.  I'm more than happy to have discussion about this.

If this holds, then why does `apt-get update` modify files in
/var/lib/apt/lists, and why is /var/lib/dpkg/status not really
/usr/lib/dpkg/status?

Well, two wrongs don't make a right, nor does APT/dpkg's choice for
/var make using /usr for changeable resource data wrong for
everyone, but I still think that apt-spy's mirror list and the PCI
IDs should be kept in /var, since they are variable data.

Looking forward to comments!

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: Bug#278027: RFP: ibm-acpi -- Driver for IBM laptops to extend ACPI support

[Matthew Garrett]

Loïc Minier <[EMAIL PROTECTED]> wrote:
> Matthew Garrett <[EMAIL PROTECTED]> - Sun, Oct 24, 2004:
> 
>> This has been integrated into the acpi.sf.net patch, so is fairly likely
>> to end up in the mainstream kernel before too long.
> 
>  Oh never read of that, do you have some pointers?  Are you sure it's
>  the same driver?  Thanks!

http://marc.theaimsgroup.com/?l=acpi4linux&m=109823399515032&w=2 is the
response from the acpi maintainer.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Bug#278075: ITP: libical0 -- An implementation of basic iCal protocols

[Ricardo Mones]

On Mon, 25 Oct 2004 18:02:51 +0200
Sebastian Ley <[EMAIL PROTECTED]> wrote:

> * Ricardo Mones wrote:
> 
> > * Package name: libical0
> 
> Are you aware that libical is currently pretty unmaintained upstream and
> has a lot of nasty bugs? In fact all projects who needed an ical parser
> (e.g. KDE PIM, evolution, OpenGroupware.org...) all dropped libical, forked
> it or wrote something new from scratch.
> 
> Libical has been in Debian until some months ago, when it was removed from 
> unstable due to buggyness and unmaintaindness.

  No, I wasn't aware of that. Thanks for the information.

  regards,
-- 
  Ricardo Mones Lastra - [EMAIL PROTECTED]
  Centro de Inteligencia Artificial, Universidad de Oviedo en Gijon
  33271 Asturias, SPAIN. - http://www.aic.uniovi.es/mones

Re: Bug#278075: ITP: libical0 -- An implementation of basic iCal protocols

[Matthew Garrett]

Ricardo Mones <[EMAIL PROTECTED]> wrote:

> * URL : http://www.softwarestudio.org/libical/

The last version of this appears to have been released in 2002. Is there
any sign of ongoing development, and is there any software that actually
uses this library?

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Bug#278075: ITP: libical0 -- An implementation of basic iCal protocols

[Ricardo Mones]

On Mon, 25 Oct 2004 16:58:01 +0100
Matthew Garrett <[EMAIL PROTECTED]> wrote:

> Ricardo Mones <[EMAIL PROTECTED]> wrote:
> 
> > * URL : http://www.softwarestudio.org/libical/
> 
> The last version of this appears to have been released in 2002. Is there
> any sign of ongoing development, and is there any software that actually
> uses this library?

  Yep, in fact there is a newer RC version, but this precise version (0.23)
is required for my previous ITP, sylpheed-claws-vcalendar-plugin.

  Anyway if there is a newer/better library which handles that and already
available in Debian I may try to convince upstream to switch libraries
(plugin is in early stages of development).

  regards,
-- 
  Ricardo Mones Lastra - [EMAIL PROTECTED]
  Centro de Inteligencia Artificial, Universidad de Oviedo en Gijon
  33271 Asturias, SPAIN. - http://www.aic.uniovi.es/mones

Re: Bug#278075: ITP: libical0 -- An implementation of basic iCal protocols

[Sebastian Ley]

* Ricardo Mones wrote:

> * Package name: libical0

Are you aware that libical is currently pretty unmaintained upstream and has a 
lot of nasty bugs? In fact all projects who needed an ical parser (e.g. KDE 
PIM, evolution, OpenGroupware.org...) all dropped libical, forked it or wrote 
something new from scratch.

Libical has been in Debian until some months ago, when it was removed from 
unstable due to buggyness and unmaintaindness.

Regards,
Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

Drop stable (was: Re: Drop testing)

[Marco d'Itri]

On Oct 24, Eduard Bloch <[EMAIL PROTECTED]> wrote:

>whole issue is about. We need to release faster. Faster releases are
>only feasible if enough developers are motivated. They are motivated
>if Unstable is blocked and they must care about the release instead
>of working on stuff that makes "more fun".
I wonder how you did end up thinking this may be true.
If I don't feel like fixing bugs in one of my packages (think mutt) then
I'm going to do something else. But I have a long list of tasks between
"work on new packages in unstable" and "fix bugs in mutt".

> Motivation is the only factor to make them do things. Having to care
> about the release in order to continue the "fun work" leads to
> motivation.
I don't feel motivated to work on releases which are not deployable
because when they get old they need tens of backports to be useful and a
knoppix CD to be installed.
Anyway unstable is good enough for my needs, and testing with a few
minor changes could be even better.
My solution? Stop releasing, and leave this to entities which are
motivated enough (or well-financed enough, which is the same thing) to
do it.

-- 
ciao, |
Marco | [8730 doXLPaWz36Tmo]


signature.asc
Description: Digital signature

Re: Drop testing

[Eduard Bloch]

#include 
* Nikita V. Youshchenko [Mon, Oct 25 2004, 12:17:15AM]:

> In fact, existance of testing allows me to be a user and a developer at the 
> same time.
> 
> You may state that such reason has nothing to do with release process, for 
> which testing was originally proposed. Yes, I agree. However, the above 
> argument shows why testing *is useful for real life* even in it's current 
> state.

Let's assume that I agree with you, for a moment.

> As for role of testing in the release process, I believe there is plenty of 
> room to improve.

Yes, a lot.

> You write, biggest problem with testing is outdated packages. Yes, probably 
> you are right. So, some action should be taken to overcome that. I can't 
> immidiatly answer what exact actions will help, but it's a good direction 
> to think on. Let's try.
> So what makes package's path to testing long?
> - - RC bugs. Here nothing else could be done other than fixing the bugs. 
> Personally I thing that some infrastructure change could be useful here to 
> force maintainers fix RC bugs. Probably any RC bug without activity for 

I already collect some ideas about creating an anti-karma list. Listing
maintainers that keep real bugs open for a while (based on the impact;
Severity: normal and above for all packages, minor for Section:
standard++ packages), multiplied with the time they have existed and
summ'ed over all packages. The results would be quite interesting, I
expect even some "core" developers among the crap-producing part.

> several (say, 5) days should "become more public", some mechanism should 
> be used to encourage non-maintainers to work on the issue.

Okay. This could be done with the wnpp listings on d-d-a sorted by the
impact of the bugs.

> - - Complex dependency chains. Probably some scheme could be used to decrease 
> the effect of those. E.g. build mostly against testing, not against sid, 
> and use build-deps from sid only if relly required (what exactly "really 
> required" means here, should be defined separately).

This is another thing I have proposed a solution, a while ago. Many
maintainers use Build-Depends to control transitions in Sid, while this
implicitely breaks Testing transtion. There should be a
Build-Depends-Min: field where the oldest required version of libFoo is
listed. So t-p-u autobuilders could pick this minimal set of
Build-Dependencies which is sufficient and would make Testing transition
possible without having the binary transition.

Yes, there are problems based on ABI incompatibilities that could be
hidden with this method, but that is the price for having working
build-debs and sane transtition times (in average). IIRC a quarter of
Testing cannot even be built based on Testing Build-Deps.

And the last part is not hidding open bug reports as we currently do
(Sid packages close bug reports that still exist in Testing/Stable for
months/years, months after that). I was told that the needed code for
the BTS is almost ready and they just wait for the release to activate
it.

> > But many maintainers simply do not care much
> > about testing, Unstable runs fine for them.
> 
> Do you really think that this is the point? Do you have statistics?

No, but some web survey can surely be done. There is something on
http://www.debian-administration.org/?poll=3 but there are not enough
votes (IMHO) base any statement on it.

Regards,
Eduard.
-- 
Jede einem Menschen zugefügte Beleidigung, geleichgültig, welcher
Rasse er angehört, ist eine Herabwürdigung der ganzen Menschheit.
-- Albert Camus

Re: Drop testing

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 06:02:38PM +0200, Eduard Bloch wrote:
> #include 
> * Wouter Verhelst [Sun, Oct 24 2004, 11:41:33AM]:
> 
> > > Very few bug reports from testing users are of any value at all.
> > 
> > I respectfully disagree here.
> > 
> > With most of my packages, bugs get filed only when the transition to
> > testing has been complete for quite a while already, except when the bug
> > is a /really/ severe one (severity grave or critical).
> 
> Counter example: you fix a bug in Sid but insufficiently (and you do not
> know for sure). Few users continue reporting bugs in the Testing
> version. You ask them to test the Sid version. But Sid scares them

In that case, you build a package against the testing libraries, upload
that to your people.d.o webspace, and ask them to test that.

If they are not willing to test that either, then they are not helpful
and you cannot fix the bugs that bother them. This will stay the same
regardless of whether or not there is a testing.

> and they promise to wait for the update to be in Sid. Then, you will
> wait weeks for the acknoledgement and the bug may still be in Testing
> in this time. And it will take another two weeks for a real fix to
> slip into Testing.
> 
> That is not fun. That is overhead which creates confusion.

Because you're doing it wrong.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: Drop testing

[Andreas Barth]

* Eduard Bloch ([EMAIL PROTECTED]) [041025 15:10]:
> At least they won't poison Sid with fresh things that may others life
> more difficult. Eg. new library versions.

And why should that work better than now? The developers _are_ asked to
not poison sid. The advantage of testing is however that we have some
chance to un-do broken actions.

> > they like less than x but still more than y. So this will at least fail,
> > and probably hurt debian too.

> Maybe. What is the alternative? Continue with the current method and
> release Edge... 2009 or so?

If we could get back to facts, our main problem is _not_ that sarge is
not in release-quality. Sarge is (mostly) in very good shape, and the
remaining problems would be there also with your proposal.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Drop testing

[Andreas Barth]

* Eduard Bloch ([EMAIL PROTECTED]) [041025 15:00]:
> #include 
> * Joey Hess [Sat, Oct 23 2004, 08:36:18PM]:
> 
> > > not look appear as critical for maintainer, or not important enough to 
> > > touch
> > > package in the holy "frozzen" state). Such bugs are a disaster, they make
> > > our definition of a Stable release absurd. Yes, Debian Stable has become a
> > > buggy stable release. Just face it.
> > 
> > AIUI, you propose to freeze unstable and go back to the old method of
> > having updates during the freeze be manually put in at the discretion of
> > the Release Managers. If we did that, how would one of these "ugly bugs"
> > be any more likely to be fixed in frozen unstable than it is in today's

> a) The release time would be shorter

I would like to see a prove of this.

> b) It would be up to humans (and not some obscure scripts) to decide whether 
> the bugs deseves a fix or not

This is already the case. If the humans decide that a bug should be
fixed, they can either just do it, or at least upgrade the bug to
RC-grade. If they decide that it is actually not so bad that it requires
a fix for the release, they could downgrade it.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Drop testing

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 05:57:05PM +0200, Eduard Bloch wrote:
> #include 
> * Marco d'Itri [Sat, Oct 23 2004, 10:06:24PM]:
> > On Oct 23, Eduard Bloch <[EMAIL PROTECTED]> wrote:
> > 
> > > ABSTRACT
> > You are trying to force developers to work on item x, which they dislike,
> > by forcing them to not work on item y, which they like more. You are
> > apparently oblivious to the fact that most developers will probably
> > spend their time on item w (which is probably not a Debian task), which
> 
> At least they won't poison Sid with fresh things that may others life
> more difficult. Eg. new library versions.
> 
> > they like less than x but still more than y. So this will at least fail,
> > and probably hurt debian too.
> 
> Maybe. What is the alternative? Continue with the current method and
> release Edge... 2009 or so?

Improve the way testing works. There are flaws, nobody is contesting
that; but just dropping the whole idea because of them flaws is akin to
throwing away the child with the bath water.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: Drop testing

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 05:51:47PM +0200, Eduard Bloch wrote:
> #include 
> * Joey Hess [Sat, Oct 23 2004, 08:36:18PM]:
> > > not look appear as critical for maintainer, or not important enough to 
> > > touch
> > > package in the holy "frozzen" state). Such bugs are a disaster, they make
> > > our definition of a Stable release absurd. Yes, Debian Stable has become a
> > > buggy stable release. Just face it.
> > 
> > AIUI, you propose to freeze unstable and go back to the old method of
> > having updates during the freeze be manually put in at the discretion of
> > the Release Managers. If we did that, how would one of these "ugly bugs"
> > be any more likely to be fixed in frozen unstable than it is in today's
> 
> a) The release time would be shorter

That remains to be seen.

> b) It would be up to humans (and not some obscure scripts) to decide
> whether the bugs deseves a fix or not

That is the case now, too. If the release managers deem it appropriate,
they can always override the testing scripts. However, the scripts
(which are far from obscure -- perhaps they are from your POV, but that
is not the same thing) generally do 'the right thing' by themselves,
which results in a massive reduction of manual work. That is a good
thing.

> Yes, some manpower would be required for this process.

Uh, I think that is a grave understatement.

> But fellow maintainers could be involved into process of evulation of
> the quality of a proposed upgrade.

That is the case now, too. You should try and have a look at
debian-release@lists.debian.org once.

> > currently frozen in testing, the situation is exactly what it is now;
> > the maintainer and RM have to decide whether putting this fix into
> > testing (or frozen) and possibly introducing new, more important bugs is
> > warrented by the ugliness of the bug. If the package is one of the large
> > majority of packages that are _not_ currently frozen in testing, then it
> 
> "not currently"? In my solution, the whole Sid archive would be frozen.

s/solution/proposal/

Even if dropping testing would be a good thing, then I still don't
believe it's a good idea to freeze the whole distribution in one go.
Freeze the base system first, freeze the rest when the base system is
good to go.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: Release-critical Bugreport for May 14, 2004

[Florian Weimer]

* Cord Beermann:

> I added a temporary(?) fix, and bounced the latest report to the list.

Thanks, but it ended up in the archive (under the URL
),
but not in the inboxes of subscribers.

Re: Drop testing

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 05:44:31PM +0200, Eduard Bloch wrote:
> > Remember, Debian is a volunteer project, you cannot force people to do
> > something they do not want to.
> 
> Motivation is the only factor to make them do things. Having to care
> about the release in order to continue the "fun work" leads to
> motivation.

Indeed.

Having the idea that the release takes ages, and that the "fun work"
will not come back in the near future, does not.

> > >Testing synchronisation are not of pure technical nature, they are
> > >social problem, and so they should be solved by people and not
> > >scripts.
> > 
> > Yes, testing synchronisation is not a purely technical matter. Nor is it
> > purely social, so the testing scripts, which automatically keep stuff in
> > sync, are a real help. On top of that, package maintainers coordinating
> 
> They are overhead.

They most certainly are not. It certainly is a help to be able to see
what packages are in a mostly-releasable state just by looking at those
that are in testing, and those that are not.

I have a simple question for you: have you actually talked to those
currently managing our releases before drafting this GR?

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: what is /var/backup for?

[Henrique de Moraes Holschuh]

On Mon, 25 Oct 2004, Bernd Eckenfels wrote:
> On Mon, Oct 25, 2004 at 06:37:10AM -0400, Kevin Mark wrote:
> > Is there a policy for /var/backup and 
> 
> /var/backups is defined as a reserved legacy by the FHS 2.3.

Where did it go?  Or did they just remove it altogether?


-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: RFC: common database policy/infrastracture

[José Luis Tallón]

First of all, this package would be a God-send for me (see below)
Note that 'wwwconfig-common' already contains most of the needed 
infrastructure... but it is too php-oriented. Splitting it in purely 
Apache/PHP-oriented scripts (which would remain as wwwconfig-common) and 
a new 'dbconfig-common' package would probably be in order.

Please note that i find the 'database-common' name choice a very 
unfortunate one...it would surely cause confusion for the end user... 
dbconfig-common has none of these problems.

Oliver Elphick wrote:
On Mon, 2004-10-18 at 08:19, Javier Fernández-Sanguino Peña wrote:
 

I'm missing some "Best practice" on how to setup the database itself. That 
is, how to setup the tables (indexes, whatever...) that the application 
will use from the database and, maybe, even some initial data in some of 
the tables.
   

I would suggest something like this:
1. Identify the server, database type (PostgreSQL, MySQL, Firebird,
etc.) and access method (UNIX socket, TCP/IP, TCP/IP with SSL)
2. If your package needs to create a user or database, identify the
database administrator's id and password; note that this may include
doing "su -c postgres" or similar.
 

Almost ok, except for the fact that most of us prefer to ask the 
database administrator's password(and usually name) during postint, so 
that it can be forgotten( db_reset()'d ). This passwords are(and should) 
usually only necessary to setup the database, while all the 
database-related operations from the packaged program are done via an 
unprivileged user which was setup precisely for this purpose.

3. Determine and, if necessary, create the database user which will own
your package's database and other DB objects.  If your chosen server is
remote, or the server package's policy forbids application packages to
change the authentication setup, this may require manual intervention by
a database administrator.  In that case, your package will be left
installed but not yet usable - any attempt to use it should return a
message saying what steps are needed to get it working.
4. For PostgreSQL, the preferred method of supplying a password from a
script is by creating ~HOME/.pgpass (perms=0600) and specifying the
password there as described in the PostgreSQL manual.  If
password-authenticated access to the database is required, the
installation should create this file for the duration of the
installation only; if it already exists with different contents, it
should be moved aside.  The installation script should use trap
statements to ensure that everything is put back as it was at the
termination of the script.
5. If the database does not already exist,
  a. Create the database, assigning it to the ownership of the
 chosen database user.  For PostgreSQL:
createdb -O  [-E ] 
  b. As the owner, run an SQL script (appropriate to the kind of
 database) to create the schema and populate it.  For PostgreSQL:
psql -d  -f  -e [-h ]
[-p ] -U 
 or
su -  -c "psql -d 
   -f  -e [-h ]
  [-p ]"
 The latter is preferable if the system user 
 exists, because it matches PostgreSQL's default authentication
 setup.
 At this point, database authentication may forbid the execution of
 the script; this again may need manual intervention by the
 database administrator.
6. If the database does exist,
  a.  As the owner, run any script necessary to update the database
  objects. (The PostgreSQL script command is as above; the same
  caveats apply, though one would expect that password access as
  database_owner would already be set up and would therefore
  succeed.)

If the database supports SQL transactions (as PostgreSQL does), SQL
scripts should do everything inside a transaction, so that either all
objects are successfully created and populated or else there is no
change at all to the database.
 

Ok... assuming this applies to user setup also :-?
One common issue is that the application depends on that in order to work 
and it's not done automatically. Maybe the user is prompted to do it but he 
might be unable to do so until the installation is finished. For an example 
of this problem see #205683 (and #219696, #265735, #265878). 
   

The problem there is that the prompting is being done in the preinst,
which is useless, because the files referred to do not yet exist.  That
is not specifically a database-using problem; it is simply a packaging
error.  That package should hold all the information it needs in its
preinst script, or else not attempt to do things in the preinst.
 

Hmmm.
I think this package we are proposing should contain all the Debconf 
templates (to avoid duplicates in all packages, as it is now) and 
*routines* which perform the needed tasks as fail-safely as possible...
packages would then only need to be modified to make use of the new 
infrastructure; that is, use database-

Re: what is /var/backup for?

[Bernd Eckenfels]

On Mon, Oct 25, 2004 at 06:37:10AM -0400, Kevin Mark wrote:
> Is there a policy for /var/backup and 

/var/backups is defined as a reserved legacy by the FHS 2.3.

Some debian  scripts used to store backups of essential files in there (and
still do), but if you want to follow FHS, just dont use it.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o 1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+497211606754
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

what is /var/backup for?

[Kevin Mark]

Hi DD folks,
just a simple question. 
Is there a policy for /var/backup and 
what is it for or how should it be used? 
If there is a URL, google didnt show anything.
TIA
-Kev
-- 

(__)
(oo)
  /--\/
 / |||
*  /\---/\
   ~~   ~~
"Have you mooed today?"...


signature.asc
Description: Digital signature

Re: an idea for next generation APT archive caching

[Chris Halls]

On Sat, 2004-10-23 at 05:45, Brian May wrote:
> No, max_versions is not correct. It will only work if all my computers
> use the same distribution; if some computers use unstable while others
> use stable for example, then the stable version will get deleted after
> n revisions of the unstable version of the package.

Early versions of v2 from Ranty had this behaviour, but I fixed it a
while ago.

apt-proxy (1.9.12) experimental; urgency=low
[...]
  * Fix max_versions to work in the same way as version 1
did, taking distributions into account (part of #242197)

 -- Chris Halls <[EMAIL PROTECTED]>  Sun, 30 May 2004 07:32:18 +0200

Re: Drop testing

[Francesco Paolo Lovergine]

On Sat, Oct 23, 2004 at 02:33:24PM -0700, Brian Nelson wrote:
> Gergely Nagy <[EMAIL PROTECTED]> writes:
> 
> >> It may sound a bit radical, but core points have been mentioned in the
> >> thread already. I suggest to do it in a more radical way:
> >> 
> >>  - unstable lockdown in the freeze
> >>  - drop Testing and concentrate on work instead of wasting time on
> >>synching stuff. This eliminates the need for testing-security. See
> >>the last part of the paper for details.
> >
> > Doing this would result in many users who currently run testing fall
> > back to stable + backports or switch to another distro (ubuntu being a
> > likely candidate), which in turn, would result in less bugreports and a
> > less stable distribution.
> 
> Very few bug reports from testing users are of any value at all.  They
> usually either report some transient dependency problem that the
> maintainer can't fix anyway, or report something that has already been
> fixed in the unstable package.

The true solution is a multi-release BTS, not dropping testing. And
being maintainer/uploader of quite a good number of packages, I can say
those cases of testing-only problems is a minority. We have also
reports which are (yet now) stable-only, for what I can see. A proper
BTS implementation for that could help in tracking things appropriately. 

-- 
Francesco P. Lovergine

Re: Drop testing

[Francesco Paolo Lovergine]

On Sat, Oct 23, 2004 at 10:44:58PM +0200, Gergely Nagy wrote:
> > It may sound a bit radical, but core points have been mentioned in the
> > thread already. I suggest to do it in a more radical way:
> > 
> >  - unstable lockdown in the freeze
> >  - drop Testing and concentrate on work instead of wasting time on
> >synching stuff. This eliminates the need for testing-security. See
> >the last part of the paper for details.
> 
> Doing this would result in many users who currently run testing fall
> back to stable + backports or switch to another distro (ubuntu being a
> likely candidate), which in turn, would result in less bugreports and a
> less stable distribution. I, for one, wouldn't run unstable on my
> parents' box, whereas testing proved to be quite reliable there.
> 

Absolutely agree. DON'T drop testig. I'm using testing since ages here
on a good deal of boxes with different configurations and used by 
naive users without big gotchas. It helps me to check problems
in -sarge- without using sid on any computers, but for my personal ones.
It helps a lot in debugging and testing upgrades from woody.
It helps in creating custom distros starting from an archive in 
a reasonable state.

And, about the general 'shape' of testing: are you conscious that
testing is _now_ in very better general shape than other 'released'
distros? Are you consciuous that _our_ requirements about 
level of quality is higher than that of many blasonated 
(also $$$) distros?

> Freezing unstable will get you nothing compared to what we have now.
> Those who don't care about a release, will not care that way either,
> just their complaints will get louder and more frequent. Those who are
> willing to do the work neccessary for the release are already trying to.
> 

I agree too. I add also that dropping testing would not help in having
up-to-date versions in stable. Simply, we would have a lng freeze
in sid, due to the current size of archive (i.e. package per developer)
and number of RCs. Versions would be obsolete in any way.

> Remember, Debian is a volunteer project, you cannot force people to do
> something they do not want to.
> 
> >  - about the "filtering updates for frozen" - yes, some additional
> >manpower is required but that work must be done. The problems with
> >Testing synchronisation are not of pure technical nature, they are
> >social problem, and so they should be solved by people and not
> >scripts.
> 
> Yes, testing synchronisation is not a purely technical matter. Nor is it
> purely social, so the testing scripts, which automatically keep stuff in
> sync, are a real help. On top of that, package maintainers coordinating
> with each other (the social part) is welcomed too, and should be
> encouraged. (And those who break a transition should be kicked in the
> ass, so they won't try it again :P)
> 
> I firmly believe that fixing the problems with testing (mainly
> testing-security at this point in time) would be MUCH better than
> dropping testing and freezing unstable before the next release.
> 

You are my hero :-P

-- 
Francesco P. Lovergine

Re: Bug#277582: ITP: kwin-baghira -- A MacOSX-like theme for Apple junkies ;)

[Wouter Verhelst,,+32 15 27 69 50,+32 3 542 35 14,]

On Mon, Oct 25, 2004 at 06:23:08AM +0200, Adeodato Simó wrote:
> * José Luis Tallón [Mon, 25 Oct 2004 03:53:46 +0200]:
> > This is NOT a theme...
> 
>   agreed. note to Wouter: I strongly prefer kde-$FOO-style instead of
>   using the word theme, since kde uses the word "theme" for something
>   different than styles (as baghira).

Noted. Didn't know KDE uses those two things for different things, but
that's of course a good reason not to do it that way.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Ubuntu discussion at planet.debian.org

[Wouter Verhelst,,+32 15 27 69 50,+32 3 542 35 14,]

On Sun, Oct 24, 2004 at 12:44:35AM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 24 Oct 2004, Matthew Palmer wrote:
> > On Sat, Oct 23, 2004 at 02:40:24PM -0500, Manoj Srivastava wrote:
> > > On Sat, 23 Oct 2004 11:54:05 +0200, J?r?me Marant <[EMAIL PROTECTED]> 
> > > said: 
> > > > Manoj Srivastava <[EMAIL PROTECTED]> writes:
> > > >>> Okay, that's what t-p-u is roughly for, but the fact is that it's
> > > >>> quite painful.
> > > >> 
> > > >> Could you elaborate on that? Why is it so painful?
> > > 
> > > > Probably because you need maintain packages for both unstable and
> > > > testing at the same time.
> > > 
> > >   That is a simple branching issue in the version control
> > >  system, no?
> > 
> > A huge rush of air fills the list as hundreds of developers fill their
> > lungs to collectively say "I don't use version control"...
> 
> Is there really a developer out there that doesn't do even the most
> rudimentary VC by keeping copies of all the source packages he has
> uploaded/worked on ?

I never did that. Even though disk space is cheap these days, I always
manage to run out of it, and tend to remove stuff I do not think I will
still need (such as, old and already uploaded/installed packages).

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: Security updates for sarge?

[Bartosz Fenski aka fEnIo]

On Mon, Oct 25, 2004 at 12:19:05AM -0400, Andres Salomon wrote:
> > 4) security team (though I'm not sure how bad the situation is)
> > 
> > So, if my help is wanted with one of the first three of those, I will 
> > gladly file a NM application immediately.
> > 
> 
> Afaict, James processes NM apps alphabetically, by last name. 

I think that's not true. NMs are processed in the order they finished their
applications. http://nm.debian.org/nmlist.php
The last person from the "Applicants waiting for DAM approval" will be in
theory at least processed first.

> You can probably get through the first few stages of NM in a few weeks 
> (It took me a little over a month, between submitting my app, to getting
> Front Desk approval). So, if you applied now and hurried, I'm betting
> you'd become a DD before me.  :/

I hope you're not right... that would be extremely unfair and in fact you
would never became maintainer with your surname ;)

regards
fEnIo
-- 
  _  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | 
IRC:fEnIo
_|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska
(0 0)  phone:+48602383548 | Slackware - the weakest link
ooO--(_)--Ooo  http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001


signature.asc
Description: Digital signature

Re: Bug#277582: ITP: kwin-baghira -- A MacOSX-like theme for Apple junkies ;)

[Ben Burton]

Hi ho,

>   yes, please consider kde-baghira-style, since it's not only kwin
>   decorations that you'll be providing in the package, right? see
>   rationale in my other message.

I'd suggest kde-style-baghira, since with such a scheme all styles will
show up together in the package listing.

Just my 2c,

b.