Bug#277746: ITP: mesord -- A stochastic simulator of coupled chemical reactions and diffusions in space

[Andrea Tasso]

Package: wnpp
Severity: wishlist


* Package name: mesord
  Version : 0.1.9
  Upstream Author : David Fange <[EMAIL PROTECTED]>
* URL : http://mesord.sourceforge.net/
* License : GPL
  Description : A stochastic simulator of coupled chemical reactions and 
diffusions in space

MesoRD is a tool for stochastic simulation of reactions and diffusion. In 
particular, it is an implementation of
the Next Subvolume Method, which is an exact method to simulate the Markov 
process corresponding to the
reaction-diffusion master equation.


-- System Information:
Debian Release: 3.0
Architecture: i386
Kernel: Linux chemware.net 2.6.9-rc3-tun-dragonv #1 SMP Tue Oct 5 02:42:52 CEST 
2004 i686
Locale: LANG=C, LC_CTYPE=C

Re: an idea for next generation APT archive caching

[Brian May]

> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:

Manoj> Hi, I can mostly live with the current apt-proxy, except
Manoj> for the fact that it does not seem to want to play nice
Manoj> with debbootstrap: debbootstrap just hangs.

Strange. I have never had any problems with debootstrap and apt-proxy
myself (unless it was because the server was down or something at the
time).
-- 
Brian May <[EMAIL PROTECTED]>

Bug#277748: ITP: libsbml -- Systems Biology Markup Language (SBML)

[Andrea Tasso]

Package: wnpp
Severity: wishlist


* Package name: libsbml
  Version : 2.2.0
  Upstream Author : Ben Bornstein <[EMAIL PROTECTED]>
* URL : http://sbml.org/software/libsbml/
* License : LGPL
  Description : Systems Biology Markup Language (SBML)

LibSBML is a library for reading, writing and manipulating files and data 
streams containing the Systems Biology
Markup Language (SBML). It is not an application itself, but rather a library 
suitable for embedding into an
application. The Systems Biology Markup Language (SBML) is a machine-readable 
format for describing qualitative
and quantitative models of biochemical networks. It can also be used to express 
the interactions of biochemical
networks with other phenomena. By a ``biochemical network'', we mean a system 
consisting of biochemical entities
linked by chemical reactions that alter, transport and/or transform the 
entities.

 -- System Information:
Debian Release: 3.0
Architecture: i386
Kernel: Linux chemware.net 2.6.9-rc3-tun-dragonv #1 SMP Tue Oct 5 02:42:52 CEST 
2004 i686
Locale: LANG=C, LC_CTYPE=C

Re: an idea for next generation APT archive caching

[Brian May]

> "martin" == martin f krafft <[EMAIL PROTECTED]> writes:

martin> also sprach Jonathan Oxer <[EMAIL PROTECTED]>
martin> [2004.10.21.0617 +0200]:
>> So it's necessary to keep fetching the Packages files within
>> their expiry time or the cache gets nuked.

martin> Why delete them at all?

Need more disk space?

When I last partitioned my hard disk, I allocated 2 gig for caching
Debian files with apt-proxy. I thought this would be heaps to meet my
requirements.

It currently has approx 350 Meg free, and no doubt if I kept my
testing systems up to date with testing, this would vanish in several
days time.
-- 
Brian May <[EMAIL PROTECTED]>

Re: an idea for next generation APT archive caching

[Paul Hampson]

On Fri, Oct 22, 2004 at 02:21:17PM +1000, Jonathan Oxer wrote:
> On Fri, 2004-10-22 at 13:43 +1000, Paul Hampson wrote:
> 
> > Is there anything such a system would want to fetch from a Debian
> > mirror that doesn't show up in Packages.gz or Sources.gz?

> Yes, lots of things as I found out the hard way when I implemented
> object type checking in apt-cacher - even plain old .tar.gz if you want
> people to be able to fetch sources. Not good from a "don't use this as a
> general purpose relay" standpoint! The current checks in apt-cacher look
> like this:

> if ($filename =~ /(\.deb|\.rpm|\.dsc|\.tar\.gz|\.diff\.gz|\.udeb)$/) {

> } elsif ($filename =~ /(Packages.gz|Release|Sources.gz)$/) {
> ...
> } else {
> etc.

.rpm
To my mind:
Packages.gz refers to the .deb or .udeb
Sources.gz refers to the .dsc, .orig.tar.gz and the .diff.gz
Releases refers to Packages, but is this either neccessary, or
widely used outside the Debian mirrors themselves? (Does apt
even use Releases?)

I'm not even going to think about non-apt uses of this. ^_^
(Although circumvention of any checking is relatively easy... A
Sources.gz that refers to a. .orig.tar.gz which may contain anything
the web site owner wishes.)

And of course, this all is a complete shutout on apt-archives
without Packages.gz. ^_^

Once a file's in the cache tree, then Apache can serve it directly,
and it'll be there until it's cleaned by some other process.

Now that I look in my /var/lib/apt/lists directory, I'm reminded of
the other gain I'd like to see made here... The output from apt-cache
policy shows the host name/IP and then the path under 'dists'. Which
means it can't visually distinguish packages from:
deb http://192.168.0.1:/debian sid main
deb http://192.168.0.1:/ipv6 sid main
both give: 500 http://192.168.0.1 sid/main Packages
(This is a mock-up... the IPv6 archive has ipv6 as pool, not 'main'.
I can't seem to find an example now, but I'm sure I used to hit one
all the time before. >_<)

Using this as a proxy means the source names don't chance, and so the
hostnames become sensible/usable again. (Even though they're not
neccessarily accurate ^_^).

> (It's trapping the Packages.gz etc files separately because you can't
> just cache them directly: you'd have namespace collisions all over the
> shop. They have to be stored separately in the cache based on the
> requested host, distro etc and then the names mapped back again when
> another request comes in).

Hopefuly _that_ will be avoided by storing in a mirror-structured tree,
rooted at the mirror-source or something.

And for that I'm thinking something like the apt-proxy configuration
where the admin defines a mirror-type, hostnames to recognise, and
mirror sources to talk to.

Also an option for "dynamic mirrors" would be good, for any unrecognised
hostname to effectively autogenerate it's own mirror directory.

Of course, now I might be asking too much of mod_rewrite and/or
mod_proxy. I'll need to do some reading myself to determine if this is
possible in the form I hope for.

-- 
---
Paul "TBBle" Hampson, MCSE
7th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: discover and hotplug must be able to co-exists

[Brian May]

> "Petter" == Petter Reinholdtsen <[EMAIL PROTECTED]> writes:

Petter> At least it sounds like a good idea to have such option.
Petter> The work is done in the init.d-script.  I'm sure patches
Petter> to make it optional to load kernel modules at boot time
Petter> are welcome. :)

Edit /etc/discover.conf and delete the appropriate lines (discover
2.0.4-5).
-- 
Brian May <[EMAIL PROTECTED]>

Re: an idea for next generation APT archive caching

[Eduard Bloch]

#include 
* Adeodato Simó [Fri, Oct 22 2004, 04:40:52AM]:
> > Further, I wish there could be pre-caching. Means: if a file was
> > downloaded and that file was mentioned in packages-file A and after the
> > next update, A has a newer version of this package than the package
> > could be downloaded. This would be an optional feature, of course, but
> > it could be implemented without millions LOC.
> 
>   well, that would change apt-cacher from a from a simple webserver
>   script to a daemon-via-cron application.

...and? The clean script is already cron-triggered.

>   what problems does it have a cron.daily script that runs like:
> 
> apt-get -qq update && apt-get -qqdy dist-upgrade

That the hosting machine is maybe not a Debian box? Or runs different
Debian branch than its clients?

Regards,
Eduard.
-- 
Sieht die Magd den Bauern nackt, wird vom Brechreiz sie gepackt.

Ubuntu discussion at planet.debian.org

[Jérôme Marant]

Hi,

It's too bad that interesting discussions take place in blogs rather
than in Debian mailing lists, especially for those who don't blog
but would like to participate.

Scott James Remnant said something interesting about Ubuntu release
management: Ubuntu people run the distribution that gets released,
and the distribution is frozen until it's ready.

Debian developers, on the contrary, run unstable and rarely run
testing, which means that they don't really know about the shape
of what they release.
The Testing distribution helped a lot in release management,
especially for synchronizing architectures.
Some improvements have already been proposed by Eduard Bloch and
Adrian Bunk: freezing unstable while keeping testing.
Freezing unstable forces people to work on fixing bugs, and the
quicker the bugs are fixed, the quicker the distribution is
released and the quicker Debian people can start working on
on the next release.

Cheers,

--
Jérôme Marant

Re: NMU for libpaper

[Frank Küster]

Frank Küster <[EMAIL PROTECTED]> schrieb:

> Giuseppe Sacco <[EMAIL PROTECTED]> wrote:
>
>> It seems that libpaper package is unmaintaned, but i would like to do an
>> NMU using a large patch. The relevant bug report (with patch) is #188899
>> and this would also close hylafax bug report #269184.
>>
>> Does anyone see any problem in applying this patch?
>
> I have no opinion on that. But if you do it, I hope you will also fix
> the three l10n bugs. And I suggest that you also consider my patch for
> the annoying debconf bug #269603, and have a look at #270103. Should be
> fairly easy.

I just noticed that this hasn't been copied to the bug and the
maintainer directly. I think it should be.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Security updates for sarge? (was: Ubuntu discussion at planet.debian.org)

[Jan Niehusmann]

On Fri, Oct 22, 2004 at 10:20:51AM +0200, Jérôme Marant wrote:
> Debian developers, on the contrary, run unstable and rarely run
> testing, which means that they don't really know about the shape
> of what they release.

I would immediately upgrade at least one, probably more, woody machines
to sarge if there was a working security update system. And I guess I'm
not the only one.

Question to the security team: What's holding back security support for
sarge? (This is not a complaint - I'm just curious)

Jan

Re: Security updates for sarge?

[Petter Reinholdtsen]

[Jan Niehusmann]
> Question to the security team: What's holding back security support
> for sarge? (This is not a complaint - I'm just curious)

Debian-edu is trying to form a separate security team for
debian/testing, working on keeping the testing distribution secure in
paralell with the debian/stable security team.  The blocking feature
here is lack of people capable and willing to contribute.

The idea is to make it safe to use testing and get more people using
testing that way, and to make sure testing is closer to a releasable
state when it is frozen and renamed to debian/stable.

Interested people can join #debian-edu or contact me, Joey Hess
<[EMAIL PROTECTED]> and Finn-Arne Johansen <[EMAIL PROTECTED]> by email.

Re: Security updates for sarge? (was: Ubuntu discussion at planet.debian.org)

[Andreas Barth]

* Jan Niehusmann ([EMAIL PROTECTED]) [041022 11:10]:
> Question to the security team: What's holding back security support for
> sarge? (This is not a complaint - I'm just curious)

There are no autobuilders for testing-security. See the latest release
update http://lists.debian.org/debian-devel-announce/2004/09/msg5.html:
| The bad news is that we still do not have an ETA for the
| testing-security autobuilders to be functional.  This continues to be
| the major blocker for proceeding with the freeze; we would /like/ to
| have security support in place for sarge before encouraging widespread
| upgrade woody->sarge upgrade testing, but we /need/ to have it in place
| before releasing, so it would be unwise to try to freeze the rest of the
| archive without any confirmed schedule for the last stages of the
| release.

The good news is that we finalized the toolchain for sarge in the very
last days.



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: Ubuntu discussion at planet.debian.org

[Martin Schulze]

Jérôme Marant wrote:
> It's too bad that interesting discussions take place in blogs rather
> than in Debian mailing lists, especially for those who don't blog
> but would like to participate.

Logbooks are suited for a lot, but not for discussions.  They're more
suited for experiences, statements and the like.

I'm thankful you're taking the discussion to this list, where probably
more people will be able participate as well.

> Scott James Remnant said something interesting about Ubuntu release
> management: Ubuntu people run the distribution that gets released,
> and the distribution is frozen until it's ready.

> 
> Debian developers, on the contrary, run unstable and rarely run
> testing, which means that they don't really know about the shape
> of what they release.

Since testing is what unstable was (and many packages are the same in
both sid and sarge), this is often not the case when you look at
individual packages or groups of packages.

However, it is true that the developers often run the bleeding edge
suite since that's the development target most of the time.

> The Testing distribution helped a lot in release management,
> especially for synchronizing architectures.

Despite some problems that weren't dealt with (missing dependencies,
missing/unfulfilled source depenendencies) testing worked pretty well.

> Some improvements have already been proposed by Eduard Bloch and
> Adrian Bunk: freezing unstable while keeping testing.

It may pose a problem that development in unstable usually continues
while testing is frozen and only important bugs should be fixed.

However, if unstable would be frozen at the same time, would
development stop?  Probably not.  I'm pretty sure that several would
start with separate repositories and the like to make more recent
versions of the software available which they maintain.

We must not forget the focus on fixing the frozen distribution and
making it ready, though.

> Freezing unstable forces people to work on fixing bugs, and the
> quicker the bugs are fixed, the quicker the distribution is
> released and the quicker Debian people can start working on
> on the next release.

Freezeing unstable forces people not to do development in unstable.
It won't force people to fix bugs and the like.  Closing a motorway
won't stop people from driving (too) fast, it would stop people from
using the motorway for driving (too) fast instead.

Regards,

Joey

-- 
Reading is a lost art nowadays.  -- Michael Weber

Please always Cc to me when replying to me on the lists.

Re: Security updates for sarge?

[Martin Schulze]

Jan Niehusmann wrote:
> Question to the security team: What's holding back security support for
> sarge? (This is not a complaint - I'm just curious)

It still (as written on -project one or two weeks ago) lacks the
infrastructure as in a working buildd network that processes the
target ``testing-security''.  This is something that two people in
Debian can set up.  (This is only information, please don't start
a flamware about it).

Regards,

Joey

-- 
Reading is a lost art nowadays.  -- Michael Weber

Re: Security updates for sarge?

[Steve McIntyre]

Joey writes:
>Jan Niehusmann wrote:
>> Question to the security team: What's holding back security support for
>> sarge? (This is not a complaint - I'm just curious)
>
>It still (as written on -project one or two weeks ago) lacks the
>infrastructure as in a working buildd network that processes the
>target ``testing-security''.  This is something that two people in
>Debian can set up.  (This is only information, please don't start
>a flamware about it).

Thanks for the info. It would be nice to see this kind of information
made more readily available, more often.

Colin/Steve - you seem to have been posting about once every 3 weeks
listing current sarge status. Can you up the frequency of that please?
A weekly short summary might help a great deal to keep people informed
and focussed on doing sarge work.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"I've only once written 'SQL is my bitch' in a comment. But that code 
 is in use on a military site..." -- Simon Booth

Re: Ubuntu discussion at planet.debian.org

[Eduard Bloch]

#include 
* Jérôme Marant [Fri, Oct 22 2004, 10:20:51AM]:

> Some improvements have already been proposed by Eduard Bloch and
> Adrian Bunk: freezing unstable while keeping testing.

Jerome, please, you could have asked me. I prepare an internal GR draft
for exactly this issue, but it is to be made public on the day of the
release, and better not before. We should concentrate on making the
Sarge release ready, NOW. Do not start another flamewar.

Regards,
Eduard.
-- 
 bla. mach ichs halt als root.
  Oh ja, machs mir als root!

Bug#277766: ITP: moniwiki -- MoniWiki is yet another WikiEngine written in PHP. It is fast, light and easy to install. Also it has many enhanced and new features. Moni is slightly modified sound which means What? or What is it? in Korean. The name also indicates that MoniWiki is nearly compatible with the MoinMoin. MoniWiki WikiFormattingRules were inspired and adopted from MoinMoin. Check MoniWikiFeatures to see what MoniWiki has to offer.

[Ki-Heon Kim]

Package: wnpp
Severity: wishlist


* Package name: moniwiki
  Version : 1.0.9
  Upstream Author : Won Kyu Park <[EMAIL PROTECTED]>
* URL : http://http://moniwiki.sourceforge.net/
* License : GPL
  Description : MoniWiki is yet another WikiEngine written in PHP. It is 
fast, light and easy to install. Also it has many enhanced and new features. 
Moni is slightly modified sound which means What? or What is it? in Korean. The 
name also indicates that MoniWiki is nearly compatible with the MoinMoin. 
MoniWiki WikiFormattingRules were inspired and adopted from MoinMoin. Check 
MoniWikiFeatures to see what MoniWiki has to offer.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1-386
Locale: LANG=ko_KR.eucKR, LC_CTYPE=ko_KR.eucKR (ignored: LC_ALL set to 
ko_KR.eucKR)

Softiware

[snd_pcm_hw_params_get_buffer_time_max]

New Q E M on http://laik.huturo.com/
Adobe After Effects V 6.5 Professional PC - 130.00
Borland StarTeam 6.0 - 120.00
Crystal Reports 10.0 Developer - 110.00
Crystal Reports 10.0 Developer - 110.00
AutoCAD LT 2004 - 110.00
Pinnacle Studio 9 - 30.00
Microsoft InfoPath 2003 - 40.00
Delphi 8 Architect - 130.00
Autodesk Inventor Series 7 - 130.00
Adobe InDesign CS PageMaker Edition Mac - 100.00
Games X Copy - 25.00
Autodesk Civil Design 2004 - 80.00
Autodesk AutoCAD Revit Series 2 (AutoCAD 2005 and Revit 6.1) - 165.00
Macromedia RoboHelp Office X5 - 110.00
Adobe Streamline 4.0 Mac - 60.00
Norton Password Manager 2004 - 25.00
VMware ESX Server 3 Linux - 150.00
AutoCAD Electrical 2005 - 120.00
Adobe InDesign CS V 3.0 PC - 90.00
Adobe Graphics Server (formerly AlterCast) - 110.00
AutoCAD Mechanical 2004 DX - 120.00
Microsoft System Management Server 2003 - 110.00
Macromedia JRun 4 - 89.00
Adobe Premiere Pro 1.5 - 95.00
Peachtree Complete Accounting 2005 - 95.00
DVD X Copy Xpress - 44.99 - 24.99 - 20.00
Adobe PhotoDeluxe 4.0 - 25.00
CorelDraw Graphics Suite V 12 PC - 100.00
Undelete 4.0 - 25.00
FileMaker Professional 7 - 80.00
Pinnacle TitleDeko Pro 2.0 - 50.00
CorelDraw Graphics Suite V 12 PC - 100.00
Corel Grafigo 2 - 40.00

Re: Your details

[autoreply_signup]

From: [EMAIL PROTECTED]
Subject: Autroreply from [EMAIL PROTECTED]

Hi

Thank you for writing to [EMAIL PROTECTED] This email has been sent by a robot.

Please note that the email address for HotMat signup emails has changed to
[EMAIL PROTECTED]   Please resend your email to the new address. 

Sorry for the inconvenience.

Best Regards,

HotMat Robot
http://www.hotmat.com
 Original Message 

> 
> The requested excel document is attached!
> Thanks
> 
> +++ X-Attachment-Type: document
> +++ X-Attachment-Status: no virus found
> +++ Powered by the new Panda OnlineAntiVirus
> +++ Website: www.pandasoftware.com
> 
> 
> 

Bug#53121:

[Michelle]

Want a Rolex Watch?
http://dai.beud.com/r/giggles/

Softtware

[pedro]

New Q E M on http://ymyh.huturo.com/
Quicken 2004 Premier Home and Business - 40.00
Adobe SmartSound 6.5 - 20.00
Adobe Type Manager Deluxe 4.1 - 10.00
Microsoft Excel 2003 - 55.00
Crystal Reports 10.0 Professional - 100.00
Nero V 6.0 Ultra Edition CD/DVD Burning Suite - 30.00
Microsoft InfoPath 2003 - 40.00
Adobe Pagemaker V 7.0 PC - 80.00
Crystal Reports 10.0 Developer - 110.00
Autodesk 3ds max 6 - 140.00
McAfee Virusscan V 8.0 Retail - 15.00
Adobe InDesign CS V 3.0 Mac - 90.00
Alias WaveFront Maya Plugin - 30.00
Microsoft Windows 2003 Enterprise Server - 100.00
QuickClean - 20.00
Symantec Ghost Corporate Edition 8.0 - 25.00
Games X Copy - 25.00
Corel CorelDRAW GS 12 DRAWstitch - 110.00
Delphi 7 Architect - 70.00
Macromedia JRun 4 - 89.00
Microsoft Speech Server 2004 - 160.00
Adobe InDesign CS PageMaker Edition - 100.00
Microsoft Excel 2004 for Mac - 50.00
Borland Together Ed 6.1 Visual Studio - 120.00
Borland JDataStore v7.0 Server - 120.00
Visual FoxPro 8.0 Professional - 80.00
Macromedia Dreamweaver MX 2004 Mac - 60.00
Microsoft Windows 2003 Enterprise Server - 100.00
Corel KPT Collection - 50.00
Corel KnockOut 2 Mac - 50.00
Personal Firewall Plus - 20.00
Macromedia Flash Communication Server MX - 49.00
VMware GSX Server 3 Linux - 150.00

Re: Security updates for sarge?

[Florian Weimer]

* Andreas Barth:

> There are no autobuilders for testing-security.

So what's missing at this stage?  Machines?  An active local system
administrator?  Or someone who is trusted enough to integrate the
buildds into the security build infrastructure?

If it's machines or the local system administrator, it shouldn't be
too hard to throw a little bit of money at the problem and install a
machine at a location which someone who's committed to do the work can
access physically.

Re: Ubuntu discussion at planet.debian.org

[Jérôme Marant]

Selon Eduard Bloch <[EMAIL PROTECTED]>:

> #include 
> * Jérôme Marant [Fri, Oct 22 2004, 10:20:51AM]:
>
> > Some improvements have already been proposed by Eduard Bloch and
> > Adrian Bunk: freezing unstable while keeping testing.
>
> Jerome, please, you could have asked me. I prepare an internal GR draft

I mentioned your name because the "idea" comes from you.

> for exactly this issue, but it is to be made public on the day of the
> release, and better not before. We should concentrate on making the
> Sarge release ready, NOW. Do not start another flamewar.

I do not intent to start a new flamewar. The discussion is happening
somewhere else anyway, and I think the subject deserves a wider
audience.

Cheers,

--
Jérôme Marant

Re: Ubuntu discussion at planet.debian.org

[Matthew Garrett]

Eduard Bloch <[EMAIL PROTECTED]> wrote:

> Jerome, please, you could have asked me. I prepare an internal GR draft
> for exactly this issue, but it is to be made public on the day of the
> release, and better not before. We should concentrate on making the
> Sarge release ready, NOW. Do not start another flamewar.

Is the entire world on crack and I just failed to notice until now?

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Ubuntu discussion at planet.debian.org

[Jérôme Marant]

Selon Martin Schulze <[EMAIL PROTECTED]>:

> I'm thankful you're taking the discussion to this list, where probably
> more people will be able participate as well.

I hope so.


[...]

> > Some improvements have already been proposed by Eduard Bloch and
> > Adrian Bunk: freezing unstable while keeping testing.
>
> It may pose a problem that development in unstable usually continues
> while testing is frozen and only important bugs should be fixed.
>
> However, if unstable would be frozen at the same time, would
> development stop?  Probably not.  I'm pretty sure that several would
> start with separate repositories and the like to make more recent
> versions of the software available which they maintain.

I think it would be marginal. After all, the experimental distribution
does exit for this purpose and nonetheless, people do not neglect
unstable.

> We must not forget the focus on fixing the frozen distribution and
> making it ready, though.
>
> > Freezing unstable forces people to work on fixing bugs, and the
> > quicker the bugs are fixed, the quicker the distribution is
> > released and the quicker Debian people can start working on
> > on the next release.
>
> Freezeing unstable forces people not to do development in unstable.
> It won't force people to fix bugs and the like.  Closing a motorway
> won't stop people from driving (too) fast, it would stop people from
> using the motorway for driving (too) fast instead.

Before "testing", the RM used to freeze unstable and people were
working on fixing bugs. There were pretest cycles with bug horizons,
and freezes were shorter.
Of course, without "testing", synchronizing arches was a pain,
that's why I'd say let's combine both.

Instead of always telling than a given idea won't work, let's
try it and conclude afterwards.

Cheers,

--
Jérôme Marant

Re: Security updates for sarge?

[Josselin Mouette]

Le vendredi 22 octobre 2004 Ã 11:26 +0200, Martin Schulze a Ãcrit :
> It still (as written on -project one or two weeks ago) lacks the
> infrastructure as in a working buildd network that processes the
> target ``testing-security''.  This is something that two people in
> Debian can set up.  (This is only information, please don't start
> a flamware about it).

And without starting a flamewar, could you give us the additional
information that explains why only two people in Debian can do that?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: RE: Mail Delivery (failure dailyhoroscope@mailer1.astronet.com) (KMM1187634

[Stottalex]

Did not receive my daily horoscope for Friday 22 Oct 04 only the summary which does not give access to extended horoscope for that day.

Thank you for your service

Re: NMU for libpaper

[Hamish Moffatt]

On Thu, Oct 21, 2004 at 07:27:32PM +0200, Giuseppe Sacco wrote:
> It seems that libpaper package is unmaintaned, but i would like to do an
> NMU using a large patch. The relevant bug report (with patch) is #188899
> and this would also close hylafax bug report #269184.
> 
> Does anyone see any problem in applying this patch?

An NMU for a wishlist bug is questionable IMHO. The bug report for
hylafax-client is vague; it says that there are (tiny) differences
between "default" and "ISO A4" in the pagesizes file but fails to
explain why that's a problem.

Rather than NMU just for this bug, you could try to contact the
maintainer again and adopt the package if unsuccessful, or with his
consent. Echelon says Stephen Zander was last seen in early August.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

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

[Wouter Verhelst]

On Fri, Oct 22, 2004 at 04:31:52AM +0200, Adeodato Simó wrote:
>   I would suggest a name like kde-$FOO-style to be used (e.g.,
>   kde-baghira-style) for packages that provide a widget style for
>   QT/KDE, and include kwin decoration (if they exist) in the same
>   package. (*)

For the sake of consistency, I would suggest kde-theme-$FOO. This is
what enlightenment, jsboard, opie, and even previous incarnations of KDE
itself use (kdeartwork-theme-*).

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


signature.asc
Description: Digital signature

Re: NMU for libpaper

[Giuseppe Sacco]

Hi Hamish,

Il ven, 2004-10-22 alle 15:39, Hamish Moffatt ha scritto:
[...]
> Rather than NMU just for this bug, you could try to contact the
> maintainer again and adopt the package if unsuccessful, or with his
> consent. Echelon says Stephen Zander was last seen in early August.

Thanks for your suggetions, but I already sent Stephen three messages
during the last month. Every message returned because his mailbox is
full.

Moreover, as you may see from this thread in d-d
http://lists.debian.org/debian-devel/2004/08/msg01016.html , he was
already contacted here and he never reply.

So, you are right: I should adopt the package.

Thanks,
Giuseppe

Re: an idea for next generation APT archive caching

[martin f krafft]

also sprach Robert Collins <[EMAIL PROTECTED]> [2004.10.22.0019 +0200]:
> store_avg_object_size should have no impact on what is and is not
> cached.

Ah, interesting. I guess my testing results were influence by my
expectations then.

Thanks for your tips!

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

raptor crippled

[Bastian Blank]

Hi folks

raptor is currently crippled to one cpu.

It uses nfs to import most of the storage and was regulary hit by the
problem described in #275673.

Bastian

-- 
We'll pivot at warp 2 and bring all tubes to bear, Mr. Sulu!


signature.asc
Description: Digital signature

Re: Mail Delivery (failure dailyhoroscope@mailer1.astronet.com) (KMM1187634

[John Hasler]

Stottalex writes:
> Did not receive my daily horoscope for Friday 22 Oct 04 only the summary
> which does not give access to extended horoscope for that day.

Here you go:

"Today will not be a good day.  You will receive many snarky responses to
your message to debian-devel complaining about your missing horoscope.
More bad news to follow in other messages".
-- 
John Hasler

Re: Ubuntu discussion at planet.debian.org

[Romain Francoise]

Matthew Garrett <[EMAIL PROTECTED]> writes:

>> Jerome, please, you could have asked me. I prepare an internal GR draft
>> for exactly this issue, but it is to be made public on the day of the
>> release, and better not before. We should concentrate on making the
>> Sarge release ready, NOW. Do not start another flamewar.

> Is the entire world on crack and I just failed to notice until now?

Don't worry, we're preparing an internal General Resolution to address
this crack problem, but you're not supposed to know about it.  This is
how we fix problems in Debian: hide them, then propose General
Resolutions.

-- 
  ,''`.
 : :' :Romain Francoise <[EMAIL PROTECTED]>
 `. `' http://people.debian.org/~rfrancoise/
   `-

Re: Security updates for sarge?

[Martin Schulze]

Josselin Mouette wrote:
> Le vendredi 22 octobre 2004 à 11:26 +0200, Martin Schulze a écrit :
> > It still (as written on -project one or two weeks ago) lacks the
> > infrastructure as in a working buildd network that processes the
> > target ``testing-security''.  This is something that two people in
> > Debian can set up.  (This is only information, please don't start
> > a flamware about it).
> 
> And without starting a flamewar, could you give us the additional
> information that explains why only two people in Debian can do that?

Because they have set up and maintain the buildd network.

Regards,

Joey

-- 
Reading is a lost art nowadays.  -- Michael Weber

Please always Cc to me when replying to me on the lists.

Re: Security updates for sarge?

[Ingo Juergensmann]

On Fri, Oct 22, 2004 at 06:13:46PM +0200, Martin Schulze wrote:

> Because they have set up and maintain the buildd network.

Yes, nice, well done, thank them for their initial work, but it seems as if
it's up for others now to take over that job, because they obviously failing
continuously doing it now.  

-- 
Ciao...  // 
  Ingo \X/

Re: Mail Delivery (failure dailyhoroscope@mailer1.astronet.com) (KMM1187634

[Graham Wilson]

On Fri, Oct 22, 2004 at 10:07:00AM -0500, John Hasler wrote:
> "Today will not be a good day.  You will receive many snarky responses to
> your message to debian-devel complaining about your missing horoscope.
> More bad news to follow in other messages".

Please, don't not make the spam problem worse by responding to spam
messages on public mailing lists.

-- 
gram

Re: Security updates for sarge?

[Matthias Urlichs]

Hi, Martin Schulze wrote:
 
> Because they have set up and maintain the buildd network.

Other people have set up, and are maintaining, their very own buildd
networks, and thus might be assumed to be qualified to add t-s support
and/or whatever else is missing.

Me, for example. (I think I've mentioned that a few times.)

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]

Re: Ubuntu discussion at planet.debian.org

[Antti-Juhani Kaijanaho]

On 20041022T134825+0200, Jérôme Marant wrote:
> Before "testing", the RM used to freeze unstable and people were
> working on fixing bugs. There were pretest cycles with bug horizons,
> and freezes were shorter.

That's not true (unless you are talking about something that was ceased
several years before testing became live, certainly before I started
following Debian development in 1998).  Before testing the RM used to
fork unstable into a "frozen" distribution.  Unstable was still open for
development, and heated arguments developed on this very list asking
that the process be changed so that unstable would be frozen; this was
never done.

I don't know what you mean by "pretest cycles with bug horizons".

The current freeze has been quite short - if one ignores the current
delay by the missing testing security support - and pre-testing freezes
were not that much shorter (unless, again, one looks at ancient history.
when Debian was a lot smaller).

> Instead of always telling than a given idea won't work, let's
> try it and conclude afterwards.

The problem is that on this scale trying such things out is costly and
time-consuming.  Arguably were are still in the process of trying
"testing".

-- 
Antti-Juhani Kaijanaho, Debian developer 

http://kaijanaho.info/antti-juhani/blog/en/debian


signature.asc
Description: Digital signature

Re: an idea for next generation APT archive caching

[Matthias Urlichs]

Hi, martin f krafft wrote:

> also sprach martin f krafft <[EMAIL PROTECTED]> [2004.10.20.1155 +0200]:
>> #!/bin/sh -e
>> 
>> echo 200 OK
>> echo Content-type: application/x-debian-package
>> echo
>> 
>> exec wget -O - $MIRROR/$RPATH | tee $LPATH
> 
Don't forget
  mkdir -p "$(dirname "$LPATH")"

The above pipe needs either bash 3 or a subshell, if you want to be able
to catch any errors wget might die from.

> one might want to parse wget's error output and return 404 as before
> if it returns 404. then again, in the end, this should be
> implemented in perl of C/C++ anyway.

One more problem -- what happens if client #2 wants the file while the
wget is still in progress?

In other words, you need locking. I'd also ask the remote server for
a Content-Length: (via HEAD or whatever) so that broken transfers can be
detected a bit more reliably.

NB: What to do about no-cache pragmas?


This rapidly turns from a plain 404 error script into a somewhat
nontrivial Perl-or-Python-or-whatever doument handler.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]

Re: requirements regarding 'priorities'

[Matthias Urlichs]

Hi, Wolfgang Sourdeau wrote:

> What can be done, regarding this package, and also every other packages
> which could be in this situation?

At the moment? Not much. It's a low-priority problem.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]

Re: Ubuntu discussion at planet.debian.org

[Eduard Bloch]

#include 
* Romain Francoise [Fri, Oct 22 2004, 06:04:12PM]:

> > Is the entire world on crack and I just failed to notice until now?
> 
> Don't worry, we're preparing an internal General Resolution to address
> this crack problem, but you're not supposed to know about it.  This is
> how we fix problems in Debian: hide them, then propose General
> Resolutions.

And your point is..? 

It is our right to hide things. We do not hide problems, we hide
possible solutions. The problem is well known, but there are different
ways to solve it. And before you think about writing another message,
think about the reason for having the debian-private ML.

Regards,
Eduard.
-- 
 Wenn's beim (verdammt guten) Gefühl bei galon bleibt,
schicke ich opera morgen in Rente
 jjFux: Fällt Opera unter den Generationenvertrag? ;-)

Re: an idea for next generation APT archive caching

[martin f krafft]

also sprach Matthias Urlichs <[EMAIL PROTECTED]> [2004.10.22.2011 +0200]:
> >> exec wget -O - $MIRROR/$RPATH | tee $LPATH
> > 
> Don't forget
>   mkdir -p "$(dirname "$LPATH")"

Why the extra two processes?

mkdir -p ${LPATH%/*}

> The above pipe needs either bash 3 or a subshell, if you want to
> be able to catch any errors wget might die from.

Yes, errors are not easy to handle in shell. That's why this
should be done with Perl/Python, or at least curl.

> One more problem -- what happens if client #2 wants the file while
> the wget is still in progress?

Couldn't you somehow tell apache to not read the premature EOF? The
second client could read the file and the connection would just
block until more data becomes available.

> NB: What to do about no-cache pragmas?

Serve the file but don't store it? Just leave out the tee(1) call in
the above.

> This rapidly turns from a plain 404 error script into a somewhat
> nontrivial Perl-or-Python-or-whatever doument handler.

It's still rather simple. I will have to think about the premature
EOF. I am sure there is a way to do it.

-- 
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: NMU for libpaper

[Roger Leigh]

Giuseppe Sacco <[EMAIL PROTECTED]> writes:

> It seems that libpaper package is unmaintaned, but i would like to do an
> NMU using a large patch. The relevant bug report (with patch) is #188899
> and this would also close hylafax bug report #269184.
>
> Does anyone see any problem in applying this patch?

The BUILT_SOURCES stuff isn't necessary.  For example (taken from
Gimp-Print 4.2 src/main/Makefile.am).  print-printers.c is generated
from printers.xml:

print-util.lo: print-printers.c $(srcdir)/print-util.c

print-printers.c: ../printdef/printdef $(srcdir)/printers.xml
../printdef/printdef < $(srcdir)/printers.xml > print-printers.c

CLEANFILES = print-printers.c


Regards,
Roger

-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Re: Ubuntu discussion at planet.debian.org

[Jérôme Marant]

Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes:

> On 20041022T134825+0200, Jérôme Marant wrote:
>> Before "testing", the RM used to freeze unstable and people were
>> working on fixing bugs. There were pretest cycles with bug horizons,
>> and freezes were shorter.
>
> That's not true (unless you are talking about something that was ceased
> several years before testing became live, certainly before I started
> following Debian development in 1998).  Before testing the RM used to
> fork unstable into a "frozen" distribution.  Unstable was still open for
> development, and heated arguments developed on this very list asking
> that the process be changed so that unstable would be frozen; this was
> never done.
>
> I don't know what you mean by "pretest cycles with bug horizons".
>

You are correct. It seems so old to me that I didn't even recall
it was a fork. This indeed explains why that process had to
be improved. It also explains why the current process needs to
be improved as well.

Thanks to Ubuntu, we now have a good example of what's proven
to work.

> The current freeze has been quite short - if one ignores the current
> delay by the missing testing security support - and pre-testing freezes
> were not that much shorter (unless, again, one looks at ancient history.
> when Debian was a lot smaller).

I was refering to the woody freeze.

>> Instead of always telling than a given idea won't work, let's
>> try it and conclude afterwards.
>
> The problem is that on this scale trying such things out is costly and
> time-consuming.  Arguably were are still in the process of trying
> "testing".

I didn't says "let's try it right now", and certainly not while trying
to release Sarge.

-- 
Jérôme Marant

http://marant.org

Re: Ubuntu discussion at planet.debian.org

[Joey Hess]

Martin Schulze wrote:
> Logbooks are suited for a lot, but not for discussions.  They're more
> suited for experiences, statements and the like.
> 
> I'm thankful you're taking the discussion to this list, where probably
> more people will be able participate as well.

Indeed..

> However, if unstable would be frozen at the same time, would
> development stop?  Probably not.  I'm pretty sure that several would
> start with separate repositories and the like to make more recent
> versions of the software available which they maintain.

When we used to freeze unstable before a release, one of the problems
was that many updates were blocked by that, and once the freeze was
over, unstable tended to become _very_ unstable, and took months to get
back into shape.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: an idea for next generation APT archive caching

[Wouter Verhelst]

On Fri, Oct 22, 2004 at 08:22:57PM +0200, martin f krafft wrote:
> also sprach Matthias Urlichs <[EMAIL PROTECTED]> [2004.10.22.2011 +0200]:
> > This rapidly turns from a plain 404 error script into a somewhat
> > nontrivial Perl-or-Python-or-whatever doument handler.
> 
> It's still rather simple. I will have to think about the premature
> EOF. I am sure there is a way to do it.

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".

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

Re: Ubuntu discussion at planet.debian.org

[D. Starner]

> And before you think about writing another message,
> think about the reason for having the debian-private ML.

The reason why debian-private exists is so people can
talk about sensitive issues without posting them on
the web, especially things involving personal or private
things between people. It's not so we can hide technical
discussions about non-security issues away from everyone.

> > This is
> > how we fix problems in Debian: hide them, then propose General
> > Resolutions.

> And your point is..? 

I agree with him; not speaking for him, but...

That that's wrong. That GRs have been proposed way too much recently.
That we should discuss things long before we propose a GR, so that
even if it's formally necessary to have a GR, it's largely a moot
issue. That GR's are a last step, not a first one.

> It is our right to hide things.

Just because it's your "right" to hide things, doesn't mean that
you must or should.

> We do not hide problems, we hide
> possible solutions.

And that's _so_ much better.

David Starner -- [EMAIL PROTECTED]
-- 
___
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: Ubuntu discussion at planet.debian.org

[Otavio Salvador]

|| On Fri, 22 Oct 2004 14:52:05 -0400
|| Joey Hess <[EMAIL PROTECTED]> wrote: 

jh> Martin Schulze wrote:
>> Logbooks are suited for a lot, but not for discussions.  They're more
>> suited for experiences, statements and the like.
>> 
>> I'm thankful you're taking the discussion to this list, where probably
>> more people will be able participate as well.

jh> Indeed..

>> However, if unstable would be frozen at the same time, would
>> development stop?  Probably not.  I'm pretty sure that several would
>> start with separate repositories and the like to make more recent
>> versions of the software available which they maintain.

jh> When we used to freeze unstable before a release, one of the problems
jh> was that many updates were blocked by that, and once the freeze was
jh> over, unstable tended to become _very_ unstable, and took months to get
jh> back into shape.

Sure but not we have the experimental distribution to deal with it
while we are stabilizing the unstable and testing distribution. The
current problem is experimental is not a full distribution and doesn't
have buildd systems.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Re: Ubuntu discussion at planet.debian.org

[Andreas Barth]

* Otavio Salvador ([EMAIL PROTECTED]) [041022 22:15]:
> Sure but not we have the experimental distribution to deal with it
> while we are stabilizing the unstable and testing distribution. The
> current problem is experimental is not a full distribution and doesn't
> have buildd systems.

Actually, a lot of packages in experimental are autobuilded now (as long
as they are buildable in unstable, and only on some archs).


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: Ubuntu discussion at planet.debian.org

[Eduard Bloch]

#include 
* D. Starner [Fri, Oct 22 2004, 11:31:10AM]:
> > And before you think about writing another message,
> > think about the reason for having the debian-private ML.

And why do you move parts of my message around?! To place your part of
the "answer" in the beginning, to look more important?

But, hey, why t.f. do you not just go and fix some bugs instead of
writing another useless message? Maybe beginning with your own packages,
or looking at some RC bugs?

> The reason why debian-private exists is so people can
> talk about sensitive issues without posting them on
> the web, especially things involving personal or private
> things between people. It's not so we can hide technical
> discussions about non-security issues away from everyone.

Starting another mega-thread on controversial issue causes ill-feeling,
wastage of spare time and loss of productivity. And there are _always_
flamewars when something says "GR draft" or even postes a controversial
paper looking like a "good" GR candidate.
Or do you really believe that mega-threads help much? Do you really
think that Canonical/Ubuntu is more successfull because they discuss
more and let everyone publish its 0.02$ that everybody needs to read? Do
you really think that the explosion of redudant messages in mega-threads
is productive?

> That that's wrong. That GRs have been proposed way too much recently.

Exactly. That is why I am not going to release a half-done paper. It is
better to be discussed in a small circle. The GR drafts posted in the
last months caused something I wish to avoid - fscking huge flamewars.

> > We do not hide problems, we hide
> > possible solutions.
> 
> And that's _so_ much better.

If we get more important things done first - yes.

And from now, I will refuse to answer to anything posted to this
subthread.

Regards,
Eduard.
-- 
 Overfiend: why dont you flame him? you are good at that.
 I have too much else to do.

Re: Ubuntu discussion at planet.debian.org

[Jérôme Marant]

Joey Hess <[EMAIL PROTECTED]> writes:

>> However, if unstable would be frozen at the same time, would
>> development stop?  Probably not.  I'm pretty sure that several would
>> start with separate repositories and the like to make more recent
>> versions of the software available which they maintain.
>
> When we used to freeze unstable before a release, one of the problems
> was that many updates were blocked by that, and once the freeze was
> over, unstable tended to become _very_ unstable, and took months to get
> back into shape.

What do you think we'd get by combining both (testing + unstable freeze)?

-- 
Jérôme Marant

http://marant.org

Re: Ubuntu discussion at planet.debian.org

[Romain Francoise]

Eduard Bloch <[EMAIL PROTECTED]> writes:

> And your point is..? 

..lost on you, obviously.

> It is our right to hide things. We do not hide problems, we hide
> possible solutions.

This is ludicrous.

> And before you think about writing another message, think about the
> reason for having the debian-private ML.

I am well aware of the reason why we have this list and it is entirely
irrelevant to this discussion.

Let's end this farce: I will wait for your secret GR to be proposed,
then we can have a more productive discussion.  In the meantime, if the
burden of keeping this miracle solution to yourself gets too heavy, feel
free to share it with us mere mortals on a Debian list of your choice.

Cheers,

-- 
  ,''`.
 : :' :Romain Francoise <[EMAIL PROTECTED]>
 `. `' http://people.debian.org/~rfrancoise/
   `-

Re: Ubuntu discussion at planet.debian.org

[Matthew Garrett]

Eduard Bloch <[EMAIL PROTECTED]> wrote:

> Or do you really believe that mega-threads help much? Do you really
> think that Canonical/Ubuntu is more successfull because they discuss
> more and let everyone publish its 0.02$ that everybody needs to read? Do
> you really think that the explosion of redudant messages in mega-threads
> is productive?

Canonical work because they consist of a small set of people that work
together and who don't let egos get in the way. They work because they
have a strong leader who provides firm direction. They work because they
don't have the flaws Debian has - lack of communication, excessive
self-importance and no strong feeling of what the fuck we're actually
supposed to be doing. I don't see your solution or your method solving
any of these issues. Building consensus helps with all of them. Consider
investing your efforts in that, rather than refusing to discuss your
opinions.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Ubuntu discussion at planet.debian.org

[Jérôme Marant]

Matthew Garrett <[EMAIL PROTECTED]> writes:

> Canonical work because they consist of a small set of people that work
> together and who don't let egos get in the way. They work because they
> have a strong leader who provides firm direction. They work because they
> don't have the flaws Debian has - lack of communication, excessive
> self-importance and no strong feeling of what the fuck we're actually
> supposed to be doing. I don't see your solution or your method solving
> any of these issues. Building consensus helps with all of them. Consider
> investing your efforts in that, rather than refusing to discuss your
> opinions.

Are you saying that technical choices do not contribute to the success
of Canonical? For instance, deciding to target the distribution at
most popular architectures only?
I'd be insterested in hearing your point of view on the technical
flaws as well.

Thanks.

-- 
Jérôme Marant

http://marant.org

Re: an idea for next generation APT archive caching

[Chris Halls]

On Thu, 2004-10-21 at 04:04, Brian May wrote:
> * If the above point wasn't bad enough by itself, the apt-proxy binary has 
> hard coded:
> 
> WGET_CMD="$WGET --timestamping --no-host-directories --tries=5 
> --no-directories -P $DL_DESTDIR"

Hmm, seems you are talking about version 1, which has been rewritten. 
The new version isn't bug free yet but it does fix several problems.  It
doesn't use wget.

> * No thought put into the file deletion algorithm. IMHO, deleting
> files based on age is wrong (consider how long stable files
> last). Deleting files based on number of different copies is also
> wrong (consider if you have some systems setup with stable and another
> is unstable). IMHO, the only correct way is to scan the most recently
> downloaded Packages and Source index files and delete files that
> aren't mentioned anymore. This could be made more aggressive though if
> disk space is low.

There are several cleaning algorithms, controlled by different
parameters.  The 'only correct way' algorithm described above is
controlled by the max_versions parameter (in version 1 & 2)

Chris

Re: Ubuntu discussion at planet.debian.org

[Matthew Garrett]

Jérôme Marant <[EMAIL PROTECTED]> wrote:

> Are you saying that technical choices do not contribute to the success
> of Canonical? For instance, deciding to target the distribution at
> most popular architectures only?

Supporting a reduced range of both targets and software makes life
slightly easier, yes. But I've no especially good reason to believe that
they'd be less successful if they had a slightly larger staff and
supported all our architectures.

It's not the technical issues with supporting multiple architectures
that give us problems - it's the social issues surrounding access to
buildds, incorporation into architectures, people failing to fix
architecture specific bugs, people demanding that people fix
architecture specific bugs, that sort of thing. It's undoubtedly true
that we could release slightly faster with fewer architectures, but it's
also true that we'd find something else to argue about in order to
remove any advantage. 

> I'd be insterested in hearing your point of view on the technical
> flaws as well.

In Debian? I think what technical flaws there are are masked by other
problems. We're actually spectacularly good at dealing with technical
issues in comparison to most distributions.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Ubuntu discussion at planet.debian.org

[Colin Watson]

On Fri, Oct 22, 2004 at 02:48:01PM +0200, Jérôme Marant wrote:
> Joey Hess <[EMAIL PROTECTED]> writes:
> > When we used to freeze unstable before a release, one of the problems
> > was that many updates were blocked by that, and once the freeze was
> > over, unstable tended to become _very_ unstable, and took months to get
> > back into shape.
> 
> What do you think we'd get by combining both (testing + unstable freeze)?

My guess is that the release team would go insane having to approve
every upload to unstable.

Before you say it, it's much easier to do this sort of thing in Ubuntu
because we have a small enough team that we don't have to lock down the
archive during freezes, but instead just say "don't upload without
approval". In Debian, we've seen many times (e.g. when trying to get
large groups of interdependent packages into testing) that not all
developers can be assumed to have read announcements or will agree with
the procedure, and I think we could expect many unapproved uploads if we
tried such an open procedure; so we'd have to lock down the archive
using technical measures.

The result of this is that the load on the Debian release team if we
tried this would be significantly higher than the load on their Ubuntu
counterparts, not even counting the order of magnitude increase in the
number of packages involved. I doubt we'd be able to get much else done
at all without increasing the size of the team to the point where
effective coordination became impossible.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]

Re: Ubuntu discussion at planet.debian.org

[Colin Watson]

On Fri, Oct 22, 2004 at 03:53:28PM +0200, Jérôme Marant wrote:
> Matthew Garrett <[EMAIL PROTECTED]> writes:
> > Canonical work because they consist of a small set of people that work
> > together and who don't let egos get in the way. They work because they
> > have a strong leader who provides firm direction. They work because they
> > don't have the flaws Debian has - lack of communication, excessive
> > self-importance and no strong feeling of what the fuck we're actually
> > supposed to be doing. I don't see your solution or your method solving
> > any of these issues. Building consensus helps with all of them. Consider
> > investing your efforts in that, rather than refusing to discuss your
> > opinions.
> 
> Are you saying that technical choices do not contribute to the success
> of Canonical? For instance, deciding to target the distribution at
> most popular architectures only?

In my experience as both a Canonical employee and a Debian developer,
the number of architectures supported by Ubuntu makes a negligible
difference to Ubuntu's ability to release.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]

Re: Ubuntu discussion at planet.debian.org

[Steve Greenland]

On 22-Oct-04, 05:25 (CDT), J?r?me Marant <[EMAIL PROTECTED]> wrote: 
> Thanks to Ubuntu, we now have a good example of what's proven
> to work.

Yes, pay 30 (40?) developers to work fulltime on stabilizing a subset
of Debian. Somehow I don't think that's going to work for the Debian
Project.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Does the Debian gpg key infrastructure support multiple sub-keys?

[Rob Browning]

If I added a new sign/encrypt sub-key to my Debian key, would I be
able to use that to sign and upload packages?  Would the Debian
keyserver and the Debian upload infrastructure be able to handle it?

If not, would I at least be able to add the sub-key for non-Debian
uses without causing trouble with the Debian infrastructure?

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: Ubuntu discussion at planet.debian.org

[D. Starner]

> But, hey, why t.f. do you not just go and fix some bugs instead of
> writing another useless message? Maybe beginning with your own packages,
> or looking at some RC bugs?

To avoid a flame war, you curse at me, flame me, tell me what do and
to boot are hypocritical in the last part (as you too are writing a
useless message.) Perhaps you should try politeness to avoid a flame
war.

David Starner -- [EMAIL PROTECTED]
-- 
___
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: Does the Debian gpg key infrastructure support multiple sub-keys?

[Henrique de Moraes Holschuh]

On Fri, 22 Oct 2004, Rob Browning wrote:
> If I added a new sign/encrypt sub-key to my Debian key, would I be
> able to use that to sign and upload packages?  Would the Debian

Yes, mostly.  Some stuff (db.d.o and vote.d.o come to mind, but I am not
sure about that) require you to always sign using the master key.  gpg lets
you do that, so it is not a problem.  The archive tools don't care and will
use subkeys happly, as they should (either that, or debsign is being quite
ingenuous and telling gpg to always use the master key :-) thus I never
noticed any problems).

> keyserver and the Debian upload infrastructure be able to handle it?

Yes, without any problems.

> If not, would I at least be able to add the sub-key for non-Debian
> uses without causing trouble with the Debian infrastructure?

The subkeys cause no problems in Debian.  But make sure to never let the
master key expire, and to upload a new subkey to keyring.d.o a few _months_
before all of your subkeys expire...

-- 
  "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

ITH: basket ( was: About Basket packaging status)

[José Luis Tallón]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since i have not received any answer since Oct 5th, i prepare to
hijack Basket's ITP in 2 days' time barring
answer from the OP (101 days in preparation)
I believe that Basket is an useful application to have in Debian, and
will take care of maintaining it as an official package.
Best,
~J.L.
-  Original Message 
Subject: About Basket packaging status
Date: Tue, 05 Oct 2004 01:40:02 +0200
From: José Luis Tallón <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Hi, Luke!
~   How is the BasKet packaging status?? I thought it would be wonderful
to have it in Debian... have you already contacted upstream and began
packaging? how is everything going??
~   If you need some help or feel than you'd like to relinquish
packaging to someone else, please contact me.
Best,
~   J.L.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFBeaNgM/NWxgIQZSwRArzNAJsET0J1q2pK84VYNvWz319HjxC7RwCfVupO
NLiajUiP5hy6FR31KHIzoFo=
=1wSl
-END PGP SIGNATURE-

Re: an idea for next generation APT archive caching

[Manoj Srivastava]

On Fri, 22 Oct 2004 15:44:12 +1000, Brian May <[EMAIL PROTECTED]> said: 

>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
Manoj> Hi, I can mostly live with the current apt-proxy, except for
Manoj> the fact that it does not seem to want to play nice with
Manoj> debbootstrap: debbootstrap just hangs.

> Strange. I have never had any problems with debootstrap and
> apt-proxy myself (unless it was because the server was down or
> something at the time).  -- Brian May <[EMAIL PROTECTED]>

Hmm. The sever was on the same machine as debbootstrap, and it
 did not seem to be down (other clients were being served) --- ony
 debbootstrap seemed to hang. I'll keepa sharper look out when I do
 the 2.6.9 UML's.

manoj
-- 
To spot the expert, pick the one who predicts the job will take the
longest and cost the most.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

gfreeamp playlist inquiry

[Siqueland-Gresch]

Title: Message



 
Hello and good 
evening from Rhode Island !
 
I do not know 
whether you can help me. Right up front, I am not a programmer at all. No clue. 
Not a sausage.So if I sound ignorant it is because I am. But here it is: 

I have been using 
the Freeamp program for years and I am in love with its simplicity. No gimmicks. 
Just functionality. I love that it has a simple playlist window on the left 
and the songs of the playlist on the right. Now the only thing missing to my 
happiness is that the playlists on the left become so 
many and that they 
cannot be subdivided. It would be so nice if it would be possible to have the 
ability to create a playlist named JAZZ which opens up on clicking to its 
subdivisions: Miles Davis, Coltrane , etc. And then closes/folds up on 
clicking it again. 
Has anyone ever 
built a freeamp module which would enable Freeamp to do that 
?
If not, could one 
inspire you to build this into Freeamp ?
I would be very 
grateful if you could let me know.
 
Best 
regards,
 
Peter 
Gresc
Warren/RI
 
 
 
 
 

Re: ITH: basket ( was: About Basket packaging status)

[Brian Nelson]

On Sat, Oct 23, 2004 at 02:18:40AM +0200, Jos? Luis Tall?n wrote:
> Since i have not received any answer since Oct 5th, i prepare to
> hijack Basket's ITP in 2 days' time barring
> answer from the OP (101 days in preparation)
> 
> I believe that Basket is an useful application to have in Debian, and
> will take care of maintaining it as an official package.

You're a bit confused here.  First of all, mail sent to [EMAIL PROTECTED]
does not go to the submitter, so no one other than the QA group actually
saw your first mail.

Second of all, the person you're trying to contact (Luke) merely filed
the RFP (request for package).  Check the bug report and you'll see that
Pierre Habouzit was the person to change the title to ITP.

-- 
Blast you and your estrogenical treachery!

Re: Does the Debian gpg key infrastructure support multiple sub-keys?

[Graham Wilson]

On Fri, Oct 22, 2004 at 09:09:53PM -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 22 Oct 2004, Rob Browning wrote:
> > If I added a new sign/encrypt sub-key to my Debian key, would I be
> > able to use that to sign and upload packages?  Would the Debian
> 
> Yes, mostly.  Some stuff (db.d.o and vote.d.o come to mind, but I am not
> sure about that) require you to always sign using the master key.

db.debian.org for sure requires you to use your master key to do things
like changing your SSH public key, or your password.

Last time I voted I asked Manoj about it, and he said he was babysitting
GnuPG to handle subkeys I believe. Manoj, what is the status of a newer,
more function GnuPG on master for devotee?

> The archive tools don't care and will use subkeys happly, as they
> should (either that, or debsign is being quite ingenuous and telling
> gpg to always use the master key :-) thus I never noticed any
> problems).

The archive tools do work fine with subkeys. I don't even have my main
key on my primary workstation, and always use my signing subkey to
upload packages with.

-- 
gram

Re: an idea for next generation APT archive caching

[Peter Palfrader]

On Wed, 20 Oct 2004, martin f krafft wrote:

> Here's an idea I just had about apt-proxy/apt-cacher NG. Maybe this
> could be interesting, maybe it's just crap. Your call.

rapt proxy is an actuall http proxy that caches debian packages.  It's
written in ruby and since all you have to do to use it is setting
the http_proxy environment (or configure apt to use the proxy it will
rock.  No more stupid changing sources.list just to get cached.

It's available on alioth.

-- 
 PGP signed and encrypted  |  .''`.  ** Debian GNU/Linux **
messages preferred.| : :' :  The  universal
   | `. `'  Operating System
 http://www.palfrader.org/ |   `-http://www.debian.org/

Re: Ubuntu discussion at planet.debian.org

[Manoj Srivastava]

On Fri, 22 Oct 2004 16:56:31 -0300, Otavio Salvador <[EMAIL PROTECTED]> said: 

jh> When we used to freeze unstable before a release, one of the
jh> problems was that many updates were blocked by that, and once the
jh> freeze was over, unstable tended to become _very_ unstable, and
jh> took months to get back into shape.

> Sure but not we have the experimental distribution to deal with it

We've always had experimental. But consider this: experimental
 contains packages _known_ to be volatile, and nobody sane has
 experimental turned on for their boxes (most people cherry pick a
 package or two that they are interested in).  Secondly, buildd's do
 not work with experimental.

> while we are stabilizing the unstable and testing distribution. The
> current problem is experimental is not a full distribution and
> doesn't have buildd systems.

That too. If packages don't get tested, you have indeed
 arrested development.

manoj
-- 
Death before dishonor.  But neither before breakfast.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Ubuntu discussion at planet.debian.org

[Manoj Srivastava]

On Fri, 22 Oct 2004 14:48:01 +0200, Jérôme Marant <[EMAIL PROTECTED]> said: 

> Joey Hess <[EMAIL PROTECTED]> writes:
>>> However, if unstable would be frozen at the same time, would
>>> development stop?  Probably not.  I'm pretty sure that several
>>> would start with separate repositories and the like to make more
>>> recent versions of the software available which they maintain.
>> 
>> When we used to freeze unstable before a release, one of the
>> problems was that many updates were blocked by that, and once the
>> freeze was over, unstable tended to become _very_ unstable, and
>> took months to get back into shape.

> What do you think we'd get by combining both (testing + unstable
> freeze)?

If you freeze unstable anyway, you are blocking the updates --
 and thus have all the problems of this style of interrupted
 development. If unstable is frozen, what is the point of Testing?

Am I missing something in your (somewhat nebulous) proposal?

manoj
-- 
The new Linux anthem will be "He's an idiot, but he's ok", as
performed byMonthy Python.  You'd better start practicing. -- Linus
Torvalds, announcing another kernel patch
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Ubuntu discussion at planet.debian.org

[Manoj Srivastava]

On Fri, 22 Oct 2004 10:20:51 +0200, Jérôme Marant <[EMAIL PROTECTED]> said: 

> Debian developers, on the contrary, run unstable and rarely run
> testing, which means that they don't really know about the shape of
> what they release.

The reason I run unstable is because tat is where I upload
 to -- and that is where the shared libs are that my packages use, and
 that is where I work out the bugs experienced. However, testing does
 not seem to be too far off from unstable in the packages I use a
 lot. 

> The Testing distribution helped a lot in release
> management, especially for synchronizing architectures.  Some
> improvements have already been proposed by Eduard Bloch and Adrian
> Bunk: freezing unstable while keeping testing.  Freezing unstable
> forces people to work on fixing bugs, and the quicker the bugs are
> fixed, the quicker the distribution is released and the quicker

This is a fallacy.  In the past, when we did freeze unstable,
 it never forced me to do anything but twidle my thumbs for months
 until things got moving again. The reason that freezing unstable did
 not make me fix any more bugs, since the bugs were not in packages I
 was in any way an expert in.

Freezes just used to be a frustrating, prolonged period in
 which I did no Debian work at all, waiting for unstable to thaw back
 out.

manoj
-- 
"The geeks shall inherit the earth." Karl Lehenbauer
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: gfreeamp playlist inquiry

[Kevin Mark]

On Fri, Oct 22, 2004 at 10:05:30PM -0400, Siqueland-Gresch wrote:
>  
> Hello and good evening from Rhode Island !
>  
> I do not know whether you can help me. Right up front, I am not a programmer
> at all. No clue. Not a sausage.So if I sound ignorant it is because I am.
> But here it is: 
> I have been using the Freeamp program for years and I am in love with its
> simplicity. No gimmicks. Just functionality. I love that it has a simple
> playlist window on the left and the songs of the playlist on the right. Now
> the only thing missing to my happiness is that the playlists on the left
> become so 
> many and that they cannot be subdivided. It would be so nice if it would be
> possible to have the ability to create a playlist named JAZZ which opens up
> on clicking to its subdivisions: Miles Davis, Coltrane , etc. And then
> closes/folds up on clicking it again. 
> Has anyone ever built a freeamp module which would enable Freeamp to do that
> ?
> If not, could one inspire you to build this into Freeamp ?
> I would be very grateful if you could let me know.
>  
> Best regards,
>  
> Peter Gresc
> Warren/RI
Hi Peter,
what I get from skimming your message is that you want the Freeamp
developer to consider your request for a new feature. Your ability to
ask for features in the software programs that you use is one of the
advantages of libre/free software. You can file a bug report at the
debian site or with the bug tool for a new feature. You can also contact
the debian maintainer and the original developer about this. Their info
should be availble. But unfortunatley this list is about discussion of
issues specific to debian as a whole and not to discussion of one
program or package. I'd suggest to check the site for a better forum
like debian-user.
-Kev (not a debian developer)
-- 

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


signature.asc
Description: Digital signature

Re: Ubuntu discussion at planet.debian.org

[Manoj Srivastava]

On Fri, 22 Oct 2004 13:48:25 +0200, Jérôme Marant <[EMAIL PROTECTED]> said: 

> Selon Martin Schulze <[EMAIL PROTECTED]>:
>> I'm thankful you're taking the discussion to this list, where
>> probably more people will be able participate as well.

> I hope so.

> [...]

>> > Some improvements have already been proposed by Eduard Bloch and
>> > Adrian Bunk: freezing unstable while keeping testing.
>> 
>> It may pose a problem that development in unstable usually
>> continues while testing is frozen and only important bugs should be
>> fixed.
>> 
>> However, if unstable would be frozen at the same time, would
>> development stop?  Probably not.  I'm pretty sure that several
>> would start with separate repositories and the like to make more
>> recent versions of the software available which they maintain.

> I think it would be marginal. After all, the experimental
> distribution does exit for this purpose and nonetheless, people do
> not neglect unstable.

I do not think you understand what the experimental
 distribution is, and how it is different from unstable, if you can
 say that. (not a full distribution, contains truly volatile packages,
 not supported by buildd's, for a start).

>> We must not forget the focus on fixing the frozen distribution and
>> making it ready, though.
>> 
>> > Freezing unstable forces people to work on fixing bugs, and the
>> > quicker the bugs are fixed, the quicker the distribution is
>> > released and the quicker Debian people can start working on on
>> > the next release.
>> 
>> Freezeing unstable forces people not to do development in unstable.
>> It won't force people to fix bugs and the like.  Closing a motorway
>> won't stop people from driving (too) fast, it would stop people
>> from using the motorway for driving (too) fast instead.

> Before "testing", the RM used to freeze unstable and people were
> working on fixing bugs. There were pretest cycles with bug horizons,

Not true. People were mostly twiddling their thumbs. Only a
 small subset of people can actually help in fixing RC bugs.

> and freezes were shorter.  Of course, without "testing",
> synchronizing arches was a pain, that's why I'd say let's combine
> both.

> Instead of always telling than a given idea won't work, let's try it
> and conclude afterwards.

We have tried the whole freezing route. But feel free to try
 it out (like aj did Testing), and tell us how it would have worked.


manoj
-- 
Ha. I say let them try -- even vi+perl couldn't match the power of an
editor which is, after all, its own OS.  ;-) -- Johnie Ingram on
debian-devel
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: gfreeamp playlist inquiry

[Brian Nelson]

On Fri, Oct 22, 2004 at 11:42:57PM -0400, Kevin Mark wrote:
> On Fri, Oct 22, 2004 at 10:05:30PM -0400, Siqueland-Gresch wrote:
> >  
> > Hello and good evening from Rhode Island !

Go Red Sox!

> > I have been using the Freeamp program for years and I am in love with its
> > simplicity. No gimmicks. Just functionality. I love that it has a simple
> > playlist window on the left and the songs of the playlist on the right. Now
> > the only thing missing to my happiness is that the playlists on the left
> > become so 
> > many and that they cannot be subdivided. It would be so nice if it would be
> > possible to have the ability to create a playlist named JAZZ which opens up
> > on clicking to its subdivisions: Miles Davis, Coltrane , etc. And then
> > closes/folds up on clicking it again. 
> > Has anyone ever built a freeamp module which would enable Freeamp to do that
> > ?
> what I get from skimming your message is that you want the Freeamp
> developer to consider your request for a new feature. Your ability to
> ask for features in the software programs that you use is one of the
> advantages of libre/free software. You can file a bug report at the
> debian site or with the bug tool for a new feature. You can also contact
> the debian maintainer and the original developer about this. Their info
> should be availble. But unfortunatley this list is about discussion of
> issues specific to debian as a whole and not to discussion of one
> program or package. I'd suggest to check the site for a better forum
> like debian-user.

Also note that freeamp was renamed to zinf due to trademark infringment
or something a couple years ago.

-- 
Blast you and your estrogenical treachery!

Re: an idea for next generation APT archive caching

[Hamish Moffatt]

On Thu, Oct 21, 2004 at 02:59:17PM -0500, Manoj Srivastava wrote:
> Hi,
> 
> I can mostly live with the current apt-proxy, except for the
>  fact that it does not seem to want to play nice with debbootstrap:
>  debbootstrap just hangs.

Happens here too.. my apt-proxy and debootstrap client (pbuilder) are on
different machines. I've done this before, so I think it's new with
apt-proxy v2.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>