Re: Re (2): lilo removal in squeeze / new lilo upstream

[William Pitcock]

Hi,

- "Joachim Wiedorn"  wrote:

> Russell Coker  wrote on 2010-06-05 22:30:
> 
> > On Wed, 26 May 2010, Stephen Powell  wrote:
> > > You're missing the point.  The main selling point to management
> > > is that Linux is free.  If they have to buy new backup software
> > > in order to accommodate Linux' backup requirements, that will
> > > kill it on the spot.  Whatever boot loader I use must not
> > > require new backup software or impose special backup
> requirements.
> > 
> > One of the advantages of Linux is that you are not forced to do
> things the way 
> > that the distribution vendor packages it.
> > 
> > You can take the last lilo package that gets uploaded, build it and
> put it in 
> > your own apt repository, and then support it for your own users.
>  
> I see that more people than thought still want to have or need LiLO.
> Now 
> I have decided to start and reanimate the upstream development.
> Everyone
> is invited to join in this development. I'm working on LiLO version
> 23.
> 
> Shortly with more informations ...

Have fun.  When you have a release that actually has merit, it can be
reconsidered for inclusion in Debian.

In the meantime, the original plan continues.

William


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/28336861.3901275860645697.javamail.r...@ifrit.dereferenced.org

Re: Bug#583257: ITP: haskell-gnomevfs -- Binding to the GNOME Virtual File System library

[William Pitcock]

Hi,

- "brian m. carlson"  wrote:

> On Wed, May 26, 2010 at 02:07:22PM -0300, Marco Túlio Gontijo e Silva
> wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: "Marco Túlio Gontijo e Silva" 
> > 
> > * Package name: haskell-gnomevfs
> >   Version : 0.11.0
> >   Upstream Author : Duncan Coutts
> > * URL : http://www.haskell.org/gtk2hs/
> > * License : LGPL-2.1+
> >   Programming Lang: Haskell
> >   Description : Binding to the GNOME Virtual File System
> library
> 
> It's my understanding that gnome-vfs is deprecated upstream and is
> going
> away.  Most GNOME components no longer use it or include support for
> it.
> Do you really want to package a binding for unsupported software?

Indeed.  GVFS has replaced GnomeVFS in the GNOME platform.

William


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/9514770.3811274896715696.javamail.r...@ifrit.dereferenced.org

Re: lilo removal in squeeze (or, "please test grub2")

[William Pitcock]

Hi,

- "Stephen Powell"  wrote:

> (blah blah blah blah)

Nobody cares if you are opposed to it.  Unless you are offering to become
lilo upstream, it's going away.

William


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2152114.3751274645490011.javamail.r...@ifrit.dereferenced.org

lilo removal in squeeze (or, "please test grub2")

[William Pitcock]

Hi,

After some discussion about lilo on #debian-devel in IRC, it has pretty
much been determined that kernel sizes have crossed the line past where
lilo can reliably determine the payload size.

This bug *can* be fixed, but not without a significant rewrite of the
way that lilo's stage2 loader code works.  Given that there is no active
upstream and that the Debian lilo package carries many patches for bug
fixes that are alleviated by standardizing on grub2, this seems like the
best option for Debian.

This means that users should *test grub2 extensively* before Squeeze is
released so that any issues can be resolved now.

As for removal, the following things need to be done:

(1) The release notes need to be updated to reflect that lilo is no
longer a bootloader option;
(2) The debian-installer team needs to remove the lilo-installer udeb;
(3) The ftpmasters need to remove lilo from unstable (which will be done
using the appropriate bug filing once the above steps are made);
(4) Users need to test grub2 now.

William


signature.asc
Description: This is a digitally signed message part

Re: Xen, Squeeze, and Beyond

[William Pitcock]

- "Ben Hutchings"  wrote:

> On Wed, 2010-03-24 at 17:58 +0800, Thomas Goirand wrote:
> > > But xen-tools have be removed from Squeeze, so I suppose it will
> be more difficult to create new
> > > installations (require much more work to replace the
> xen-create-image script).
> > 
> > Well, I've been maintaining dtc-xen since Lenny, and it does even
> more than xen-tools.
> > 
> > DTC-Xen is in Squeeze and I wont give-up on it.
> > 
> > > > 6) Are we communicating this to Debian users in some way?  What
> can I do
> > > > to help with this point?
> > > Remind people that Xen is dying and KVM is the present and the
> future.
> > 
> > This is your own *personal view* on Xen vs KVM thing. I really
> don't
> > see Xen dying despite the 2 years of bad propaganda of the KVM
> > supporters. This eroneous view should *NOT* be pushed as Debian's
> > official view. Xen is doing well, and there are more chances that
> the
> > dom0 patches will be accepted this year as people improve Xen as
> > required for inclusion.
> [...]
> 
> Xen might be doing well in some distributions but in lenny it has been
> a
> disaster.  We have been stuck with a dead-end branch that no-one has
> the
> time and knowledge to fix.  I believe squeeze will be better due to
> the
> common base kernel version and some support from upstream Xen
> developers
> (particularly Ian Campbell), but it will still lack the wide support
> that KVM gets as a project that has been merged into the kernel.

However, the 2.6.26 kernel runs more reliably than the 2.6.18 kernels
provided by Citrix on my hardware, even though it has some weird bugs
which are probably not very feasible to fix (but those bugs have
workarounds).

I do agree that squeeze will be a considerable improvement over lenny,
though.  The main thing is that the hypervisor ABI requirement needs to
be strongly enforced so that the damned thing will boot.

William


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/22498941.3141269460710304.javamail.r...@ifrit.dereferenced.org

Re: Xen, Squeeze, and Beyond

[William Pitcock]

Hello,

- "Ian Campbell"  wrote:

> On Fri, 2010-02-26 at 11:29 +0100, Olivier Bonvalet wrote:
> > 
> > But xen-tools have be removed from Squeeze, so I suppose it will be
> > more difficult to create new installations (require much more work
> to
> > replace the xen-create-image script). 
> 
> Squeeze (32- and 64-bit) and Lenny (32-bit only) both support
> installation into a Xen domU using the regular Debian Installer,
> including preseeding etc. Instructions for use can be seen at
> . Squeeze even supports
> installation from ISOs into a Xen domU (using the multiarch
> amd64+i386
> +powerpc netinst ISO). 
> 
> Is there any way this functionality could be exposed via xen-tools to
> make it easier to deploy? (I don't know if/how it would fit into the
> xen-tools model).

xen-tools is similar to ApplianceKit, in that it invokes the same lowlevel
tools that debian-installer uses to install the guest OS instead of using d-i
directly.

However, xen-tools is more limited than ApplianceKit in the regard that
ApplianceKit has functionality somewhat like preseeding.

I don't know about DTC-Xen, I've never tried it, but I suspect it probably
works the same way as the above, or uses tarballs which is *ugh*.

William


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/18967579.3201269461148524.javamail.r...@ifrit.dereferenced.org

Re: Xen, Squeeze, and Beyond

[William Pitcock]

Hi,

- "Thomas Goirand"  wrote:

> > But xen-tools have be removed from Squeeze, so I suppose it will be
> more difficult to create new
> > installations (require much more work to replace the
> xen-create-image script).
> 
> Well, I've been maintaining dtc-xen since Lenny, and it does even more
> than xen-tools.
> 
> DTC-Xen is in Squeeze and I wont give-up on it.

Not to mention that there is appliancekit, but it hasn't been uploaded into
Debian proper yet.  Both DTC-Xen and ApplianceKit are commercially-motivated
solutions, so there is no reason for them to disappear any time soon.

The main thing which has stopped getting AK uploaded into proper Debian is
that other dependencies need to be uploaded in order to get full feature
coverage and target support...

> 
> > > 6) Are we communicating this to Debian users in some way?  What
> can I do
> > > to help with this point?
> > Remind people that Xen is dying and KVM is the present and the
> future.
> 
> This is your own *personal view* on Xen vs KVM thing. I really don't
> see Xen dying despite the 2 years of bad propaganda of the KVM
> supporters. This eroneous view should *NOT* be pushed as Debian's
> official view. Xen is doing well, and there are more chances that the
> dom0 patches will be accepted this year as people improve Xen as
> required for inclusion.
> 
> Xen support in Debian will continue as long as there are some people
> willing to work on it, and there's quite some activity by the pkg-xen
> guys (Bastian, etc.).

Agreed.

William


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20211265.3171269460947202.javamail.r...@ifrit.dereferenced.org

Re: Xen, Squeeze, and Beyond

[William Pitcock]

- "Josip Rodin"  wrote:

> On Sat, Feb 27, 2010 at 01:23:07AM +0300, William Pitcock wrote:
> > I am looking into packaging xenner already as a backup plan if I
> cannot
> > manage to fix some major reentrancy problems in the Xen dom0 code
> > (Xensource 2.6.18 patches, the pvops stuff has it's own share of
> problems
> > and needs more evaluation).
> 
> The .18 dom0 patches are well on their way out from the perspective
> of
> both Debian and Xen upstream, so you might want to shift focus to the
> pvops
> branch instead.

I am well aware of that.  However, the pvops branch has several critical
bugs:

- On a 8-way system, it reports 259GHz CPUs for all cores when booted under
Xen;
- The paravirtualized clock is 4 times slower then it should be in dom0
mode;
- The same reentrancy issues exist, as the pvops work is mostly Jeremy
forward porting the 2.6.18 code; a workaround is to dedicate one CPU core
to dom0 operations and pin it.

There are also no pvops dom0 kernel packages shipped by Debian yet, at
least through official channels.

While you are correct that pvops is the future, right now it's no better
reliability-wise then the 2.6.18 xensource patches... unfortunately tracking
these reentrancy bugs (mostly deadlocks) down is a massive pain in the ass.

William


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/23012901.2831267308226442.javamail.r...@ifrit.dereferenced.org

Re: Xen, Squeeze, and Beyond

[William Pitcock]

Hi,

- "Michael Tautschnig"  wrote:

> First of all, I'd like to say a big THANKS to all the people
> maintaining Xen
> within (in of course also outside) Debian; you really saved us lots of
> money and
> energy (which is both, electrical and that personal one). 
> 
> [...]
> 
> > 
> > > 4) What will be our preferred server virtualization option for
> non-Linux
> > > guests after squeeze?  Still KVM?
> > Yes, virtualized Windows works much better in (modern) KVM than
> Xen.
> > 
> > > 5) Do we recommend that new installations of lenny or of squeeze
> avoid
> > > Xen for ease of upgrading to squeeze+1?  If so, what should they
> use?
> > It depends. KVM in lenny is buggy and lacks important features.
> While it
> > works fine for development and casual use I do not recommend using
> it in
> > production for critical tasks.
> > This is where Red Hat really beats us: RHEL shipped Xen years ago
> but
> > recently they released an update which provides a backported and
> > stabilized KVM.
> > 
> > > 6) Are we communicating this to Debian users in some way?  What
> can I do
> > > to help with this point?
> > Remind people that Xen is dying and KVM is the present and the
> future.
> > 
> 
> As I understand the later mails of Bastian and Ian, this is probably
> not an
> issue anyway, but still I'd like to note it: Even though KVM may have
> a
> promising future (on hardware with virtualization support, at least),
> there is a
> serious need for a nice migration path. It seems impossible to
> dist-upgrade to
> squeeze and switch from Xen to KVM at the same time.

Such a migration path already exists: xenner, but it needs to be packaged,
and possibly updated to work with newer Xen hypercalls (such as those introduced
since Xen 3.1).

I am looking into packaging xenner already as a backup plan if I cannot
manage to fix some major reentrancy problems in the Xen dom0 code (Xensource
2.6.18 patches, the pvops stuff has it's own share of problems and needs
more evaluation).

William


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/23104025.2771267222987538.javamail.r...@ifrit.dereferenced.org

Re: Xen support on Squeeze

[William Pitcock]

- "Gabor Gombas"  wrote:

> On Sun, Jan 03, 2010 at 06:31:20PM +0200, Pasi Kärkkäinen wrote:
> 
> > So the change has happened, lthough it took painfully long to get
> the
> > upstream Linux pv_ops framework in shape and all that.. and
> obviously
> > the pv_ops dom0 patches still need to get merged upstream.
> 
> That was opposed quite strongly by the kernel folks last time it was
> attempted. Were there any fundamental changes in the Xen dom0 patches
> since then?

Only by the kernel folks which believe all of the crap that the KVM
guys say about Xen.  There are plenty of kernel developers willing
to see the patches merged.

William


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Xen support on Squeeze

[William Pitcock]

- "Marc Haber"  wrote:

> On Sun, 3 Jan 2010 16:55:27 +1100, Brian May 
> wrote:
> >Like I said previously, I think dropping Xen support is a mistake
> because KVM
> >requires QEMU and QEMU seems to have a reputation of being insecure.
> 
> Xen is unsupportable due to clueless upstream, who has been in a
> constant FAIL state regarding support of current kernels for years.

Do you have any proof for this claim?  xen.git seems pretty up to date to
me (2.6.31.6), and there are already people who are hacking on xen.git who
have it working on 2.6.32, which means that xen.git will be up-to-date once
Jeremy is back from holiday.

William


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#532831: ITP: python-greenlet -- lightweight in-process concurrent programming

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock 

* Package name: python-greenlet
  Version : 0.2
  Upstream Author : Bob Ippolito 
* URL : http://undefined.org/python/#greenlet
* License : MIT
  Programming Lang: C
  Description : lightweight in-process concurrent programming
 The "greenlet" package is a spin-off of Stackless, a version of CPython that
 supports micro-threads called "tasklets". Tasklets run pseudo-concurrently
 (typically in a single or a few OS-level threads) and are synchronized with
 data exchanges on "channels". 
 .
 A "greenlet", on the other hand, is a still more primitive notion of 
micro-threads
 with no implicit scheduling; coroutines, in other words. This is useful when 
you
 want to control exactly when your code runs. You can build custom scheduled
 micro-threads on top of greenlet; however, it seems that greenlets are useful 
on
 their own as a way to make advanced control flow structures.
 .
 Greenlets are provided as a C extension module for the regular unmodified
 interpreter.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#532140: ITP: python-eventlet -- high performance network library using coroutines

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock 

* Package name: python-eventlet
  Version : 0.8
  Upstream Author : Linden Research, Inc. 
* URL : http://wiki.secondlife.com/wiki/Eventlet
* License : MIT
  Programming Lang: Python
  Description : high performance network library using coroutines
 Eventlet is a high performance networking library for Python.  It achieves
 high scalability by using non-blocking I/O while at the same time retaining
 programmer usability by using coroutines to make the non-blocking I/O
 operations appear blocking at the source-code level.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: fstrcmp

[William Pitcock]

On Sun, 2009-05-31 at 11:04 +0200, Florian Weimer wrote:
> * Peter Miller:
> 
> > I've been considering turning my fuzzy string compare function into a
> > library.
> 
> I would certainly welcome that.
> 
> Would you be willing to relicense it under a more permissive license,
> so that we don't have to worry about OpenSSL license compatibility
> etc.?
> 
> > /**
> >  * the fstrcmp function compare two strings, to determine how
> >  * similar two strings appear.
> >  *
> >  * @param s1
> >  * The first of the strings to compare.
> >  * @param s2
> >  * The second of the strings to compare.
> >  * @returns
> >  * a number between 0.0 and 1.0; 0.0 means the strings are
> >  * nothing alike, 1.0 means the two strings are identical.
> >  */
> > double fstrcmp(const char *s1, const char *s2);
> 
> It could be helpful if it didn't use floating point because we support
> some systems where floating point is software-emulated.
> 
> I don't think we've got a library of C goodies.  libbsd is something
> in that direction, but if your function isn't in the BSDs, it probably
> doesn't fit there, either.

There is libmowgli (don't ask why it's named this, we just picked
something random), but it requires all core modules to be licensed under
ISC.  There is some Windows portability components that are LGPL.

Unfortunately, we're renovating the atheme.org website right now, so
instructions to submit additional components are not yet available.

William


signature.asc
Description: This is a digitally signed message part

Re: Should we remove OpenMotif?

[William Pitcock]

On Wed, 2009-05-20 at 22:03 -0400, Barry deFreese wrote:
> Hi folks,
> 
> As some of you may already know, I have been doing a lot of package 
> removals and QA work.  One of the ones I ran across lately is 
> OpenMotif.  It has been orphaned since 2006 and has several bugs against 
> it.  However, it does still have 1 r(b)depends. (arb which is also in 
> non-free).
> 
> I was considering packaging up the new upstream but I would have to 
> register to do that and I am not really keen on putting that much effort 
> into a non-free package.
> 
> Anyone have an opinion?

Use GNU Lesstif instead?

William



signature.asc
Description: This is a digitally signed message part

Bug#527094: ITP: polkadot -- continuous integration server for debian packaging

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock 

* Package name: polkadot
  Version : 0.1
  Upstream Author : William Pitcock 
* URL : http://polkadot.dereferenced.org/ (not yet up)
* License : GPLv2
  Programming Lang: Python
  Description : continuous integration server for debian packaging
 Polkadot is a Continuous Integration (CI) server for Debian packagers to
 check their packaging efforts against upstream development branches.
 Continuous Integration may be useful for packagers wishing to provide
 nightly testing builds of their packages, or who wish to automatically
 track upstreams.
 .
 It supports:
 .
 - automatically building Debian source packages from upstream
   repositories (at the moment, only mercurial is supported) and
   the SCM version of the debian packaging
 - optionally building binary packages with cowbuilder
 - optionally putting the build results into an apt repository
   ala apt-ftparchive

Other features are planned, such as rebuildd integration, a plugin
architecture, and support for the most common repository formats
but they're not ready yet.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff? (was: Re: phyml_20081203-1_powerpc.changes REJECTED)

[William Pitcock]

On Mon, 2009-04-27 at 14:05 +0200, Holger Levsen wrote:
> Hi,
> 
> On Montag, 27. April 2009, Philipp Kern wrote:
> > Interestingly you did it again, ignoring the list Code of Conduct.
> 
> As it sadly happens many times every day. And as long as there are no means 
> to 
> enforce it (either pure social or aided by technology), it will continue to 
> happen.
> 

Reply-To: debian-devel@lists.debian.org ?

William



signature.asc
Description: This is a digitally signed message part

Re: About the current state of the Yum package in Lenny

[William Pitcock]

On Sat, 2009-04-18 at 14:00 +0800, Thomas Goirand wrote: 
> William Pitcock wrote:
> > neno...@petrie:~$ sudo yum -c ak-bootstrap.conf
> > --installroot=/home/nenolod/bootstraptest install centos-release yum
> > ak-bootstrap  100% |=| 1.1 kB
> > 00:00 
> > primary.xml.gz 28% |===  | 328 kB
> > 00:13 ETA 
> > [...]
> > neno...@petrie:~$ sudo yum -c ak-bootstrap.conf
> > --installroot=/home/nenolod/bootstraptest groupinstall base
> > [...]
> > 
> > It's not broken. End of story.
> > 
> > William
> 
> Can you please show me the output of "dpkg -l yum" and the content of
> your ak-bootstrap.conf?

$ dpkg -l yum
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ NameVersion 
Description
+++-===-===-===
ii  yum 3.2.12-1.2  
Advanced front-end for rpm
$ cat /home/nenolod/ak-bootstrap.conf 
[ak-bootstrap]
name=Bootstrap Repo
#baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/10/$basearch/os/
#mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-10&arch=$basearch
mirrorlist=http://mirrorlist.centos.org/?release=5&arch=$basearch&repo=os
enabled=1
gpgcheck=0

It works as expected... the package is not broken. Removing the package
from lenny would be counter-productive.

William


signature.asc
Description: This is a digitally signed message part

Re: About the current state of the Yum package in Lenny

[William Pitcock]

On Fri, 2009-04-17 at 21:11 +0800, Thomas Goirand wrote:
> William Pitcock wrote:
> > I call bollocks here. I am using the version of yum in stable right now
> > to yield perfectly working virtual machine filesystems.
> > 
> > How is it "broken" when it is working as expected on production servers?
> > 
> > William
> 
> This has been discussed many times, and detailed in the bug report.
> 
> Broken == can't bootstrap an OS with yum, with yum/misc.py importing the
> wrong python module (so yum just crashes each time yum/misc.py is involved).
> 
> The fact that you are saying that your yum is "perfectly working", I
> really don't think so, it's just pure hazard that in your environment
> you don't use yum/misc.py. What exactly are you doing with yum?

neno...@petrie:~$ sudo yum -c ak-bootstrap.conf
--installroot=/home/nenolod/bootstraptest install centos-release yum
ak-bootstrap  100% |=| 1.1 kB
00:00 
primary.xml.gz 28% |===  | 328 kB
00:13 ETA 
[...]
neno...@petrie:~$ sudo yum -c ak-bootstrap.conf
--installroot=/home/nenolod/bootstraptest groupinstall base
[...]

It's not broken. End of story.

William


signature.asc
Description: This is a digitally signed message part

Re: About the current state of the Yum package in Lenny

[William Pitcock]

On Fri, 2009-04-17 at 16:25 +0800, Thomas Goirand wrote:
> Luk Claes wrote:
> > Thomas Goirand wrote:
> >> Hi,
> >>
> >> I'm sorry that it took us so much time to make a working yum package,
> >> but we were quite overloaded with our work, taking over all the
> >> customers of another web hosting company (taking all our time doing
> >> support). Anyway, I could today take the time to upload a working
> >> version of yum. Here it is:
> >>
> >> ftp://ftp.gplhost.com/debian/dists/lenny/main/source/yum_3.2.21-1~gplhost1.dsc
> >>
> >> I guess you could notice that this is a newer upstream version. Please
> >> let me know if you think this would be an acceptable replacement to be
> >> sent in lenny proposed updates. At least, I'd be happy if somebody could
> >> NMU it to SID or experimental, so there's at least something working
> >> available in the archive.
> > 
> > I'm afraid it's too invasive to be included, though I would propose to
> > upload it to backports.org.
> > 
> > Cheers
> > 
> > Luk
> 
> Then can the current broken version of yum be removed of Stable? It
> makes absolutely no sense to keep a software that doesn't work in the
> distribution.

I call bollocks here. I am using the version of yum in stable right now
to yield perfectly working virtual machine filesystems.

How is it "broken" when it is working as expected on production servers?

William


signature.asc
Description: This is a digitally signed message part

Re: lilo about to be dropped?

[William Pitcock]

On Wed, 2009-04-08 at 12:41 -0400, Matt Arnold wrote:
> No this means I take over the package try to cou ntact upstream etc
   ^^

THERE IS NO UPSTREAM ANYMORE. If you're not willing to become upstream
and wish to take it over, then we gain NOTHING. There is NOT an upstream
to talk to anymore when things break. Even the website is gone.

> and fyi i do know Intel X86 ASM (not well) but i learn fast as you
> know. I just think a "This package is deprecated and may be removed at
> any time" clause in the package desc is the best way to go here that
> way the people who use it as a fallback when GRUB doesn't work (self
> included)  or otherwise can still continue to use it. I'm just not
> comfortable dropping it when it seems to work ok for most of the
> people who need to use it. cate dud just state that lilo worked for
> him. Why not let me have it for now and just let things flow as they
> will. Belive me i'm not about to let another XMMS style nightmare
> happen

But, you will. Infact, you told me yesterday on IRC that your intention
is to "take over lilo maintenance to score points with DDs" and that you
just "needed it for a few months". This isn't the right issue to "score
points" on, as lack of proper maintenance is WORSE than not having it in
Debian at all.

So unless your attitude is different and you want to maintain a
bootloader for the sake of maintaining it (I use lilo on older machines
where grub1 does not work nicely), then please stop with this nonsense.

William


signature.asc
Description: This is a digitally signed message part

Re: lilo about to be dropped?

[William Pitcock]

On Wed, 2009-04-08 at 16:22 +0200, Giacomo A. Catenazzi wrote:
> Nenolod: sorry for the other mail.
> 
> William Pitcock wrote:
> > On Tue, 2009-04-07 at 13:06 -0300, Otavio Salvador wrote:
> >> On Mon, Apr 6, 2009 at 9:21 PM, William Pitcock
> >>  wrote:
> >>> Lilo upstream is dead (no release in quite a while), but the lilo
> >>> maintainer has also been seen as saying in various mailing lists etc,
> >>> that since Debian patches lilo that he has no interest in helping to fix
> >>> problems in our version.
> >> Ok but you could try to push those patches upstream. This is how
> >> grub has been improved and also parted. This works most of time.
> >>
> >> This way we "reduce" the amount of patches we keep in Debian
> >> and also you could try to get in touch with other distros to share
> >> the load and avoid reworking at same things.
> > 
> > lilo is officially unmaintained now. The canonical website of lilo now
> > points to a 404 error page, see http://lilo.go.dyndns.org/ .
> 
> as grub was not really maintained. Also grub2 doesn't seems so fast in
> development.
> I think these kind of project have difficult to maintain motivated
> maintainer.
> 
> What do the other distributions?

I've seen a few smaller distributions looking into extlinux as an
alternative to lilo. Not sure what the redhat/fedora/centos/etc camp are
doing though.

> 
> extlinux seems the real alternative: the maintainer is active
> in kernel boot since a lot of years, he has a good knowledge
> of lilo (thus is not the usual: do a new project because I
> cannot read/understand the old code).
> 
> OTOH hpa test always the boot changes in kernel, and
> lilo is always tested, so in this regards, he take also
> care about lilo.
> 
> 
> I think we need a discussion of the fate of lilo at DebConf.
> I volunteer to check and give you technical details of the
> main boot loaders for i386/amd64 architecture, so that
> we can decide better (and give inputs to upstream on what
> they miss). Any interest in such talk?

It would be a good topic for discussion if I can make it to DebConf this
year (which is probable, just a matter of getting a good deal on plane
tickets).

> 
> 
> BTW: my new laptop was saved by lilo ;-)

One of my newer servers was also saved by lilo (fucking adaptec SAS
controllers...). However, the current health of lilo is still something
to be concerned about.

> I installed grub (and Debian). Trying the Windows hidden partition
> (to install windows), grub stopped working (it was rescue mode, but
> without capability to rescue something). Also rescue disk +
> reconfiguring + update-grub did nothing.
> Installing lilo gave me a know boot environment, and it worked at
> first try.  So: lilo should live!

That's because grub does a number of things incorrectly as well. I don't
think extlinux repeats those mistakes though, at least from what I have
seen in production.

William


signature.asc
Description: This is a digitally signed message part

Re: lilo about to be dropped?

[William Pitcock]

On Wed, 2009-04-08 at 11:05 -0400, Matt Arnold wrote:
> As the silent co-maintainer of lilo I believe I should now voice my
> thoughts on this
> 
> I too believe that lilo should belive that lilo should be remove *at
> some point* but now is not the time. So I restate my willingness to
> take over fully publicly. Upstream made a release of a bootloader in
> 2007 a bootloader is quite different from an internet facing service
> or a desktop app, so it is possible  that upstream hasn't made a
> release because they haven't felt a need to existed.  From this thread
> there still appears to be use cases for lilo and it seems to be
> meeting the needs of the people that need it. Unless there is a
> security hole or show stopping bug that makes the package totally
> unusable why remove it. There will eventually be that case and when
> such a time comes we will reexamine the issue but why fix what is
> working for people. Again I will take over the package if you
> (nenolod) don't want it anymore. I An RM seems overkill when a line in
> the package description will do nicely
> 

Does this mean that you will become lilo upstream as well? Are you
*qualified* to become lilo upstream? Do you know assembly language?
(tip: most of the important parts are assembly language.)

If not, then stop talking now. Anything less is unhealthy as it will
just become another XMMS with lots of patches ontop of it to fix bugs.

William



signature.asc
Description: This is a digitally signed message part

Re: lilo about to be dropped?

[William Pitcock]

On Tue, 2009-04-07 at 13:06 -0300, Otavio Salvador wrote:
> On Mon, Apr 6, 2009 at 9:21 PM, William Pitcock
>  wrote:
> > Lilo upstream is dead (no release in quite a while), but the lilo
> > maintainer has also been seen as saying in various mailing lists etc,
> > that since Debian patches lilo that he has no interest in helping to fix
> > problems in our version.
> 
> Ok but you could try to push those patches upstream. This is how
> grub has been improved and also parted. This works most of time.
> 
> This way we "reduce" the amount of patches we keep in Debian
> and also you could try to get in touch with other distros to share
> the load and avoid reworking at same things.

lilo is officially unmaintained now. The canonical website of lilo now
points to a 404 error page, see http://lilo.go.dyndns.org/ .

So at this point, our only option seems to be taking over upstream lilo
maintainance ourselves (which could be a good thing in some ways, I am
not denying that), or find a way to transition these use-cases to
grub/grub2/extlinux.

However, if we are to maintain lilo ourselves, then we need to flesh out
exactly what usecases we're going to be using it for. 

I recommend if we go that route that we come up with a list of
improvements that we want to see and get to hacking. If some of the
people who like lilo a lot got around to helping with a fork, we could
create a much less buggy bootloader than the current lilo.

Alternatively, we can just leave it and let it become another XMMS. I
don't like this solution very much.

William


signature.asc
Description: This is a digitally signed message part

Re: lilo about to be dropped?

[William Pitcock]

On Tue, 2009-04-07 at 10:52 +0200, Giacomo A. Catenazzi wrote:
> Stephen Gran wrote:
> > This one time, at band camp, William Pitcock said:
> >> The only way it is feasible to do so is to drop all of the Debian
> >> patches. Without this, upstream is not cooperative with us.
> > 
> > Why is this?
>
> I think because of William Pitcock with:
> - his very strong words,
> - his attitude: perfect or nothing (in design, in management, ...),
> - his lack to listen upstreams and their needs: needs of other
>distributions, old compatibility needs, or simply time
>constrain and limited interest of upstream.
> 
> ciao nenolod ;-)

Actually, the damage was done years ago, long before I ever maintained
lilo. But thanks for the flame.

William


signature.asc
Description: This is a digitally signed message part

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 22:20 +0100, Stephen Gran wrote:
> This one time, at band camp, William Pitcock said:
> > The only way it is feasible to do so is to drop all of the Debian
> > patches. Without this, upstream is not cooperative with us.
> 
> Why is this?

See my other mail, basically, lilo upstream view is that our patches
"broke" it and that we have to fix it ourselves. I've seen him on
various threads saying basically that over the years.

But regardless, a lilo release has not been made in some time.

William


signature.asc
Description: This is a digitally signed message part

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 18:46 +0200, Christian Perrier wrote:
> Quoting Frans Pop (elen...@planet.nl):
> 
> > I'm not sure where the original mail comes from, but IMO this should be 
> 
> From lilo package BTS which I was tracking for l10n purposes. So I
> just happened to notice William's answer to a bug report and thought
> it would be good for this to be discussed in public.
> 
> Clearly, I didn't choose the right place to discuss and the topic has
> wider implications than just D-I, as the followups show. Good thing
> that you made the discussion wider.
> 
> > > Don't we have some install paths that still depend on LILO?
> > 
> > Yes: /boot on LVM is the main one.
> > 
> > > Anyway, even if we don't, I think we should track that lilo removal
> > > and coordinate with William, in order to stop providing
> > > lilo-installer.
> > >
> > > And, I think this should be mentioned as a release goal (dropping
> > > lilo). Either high priority if we have install paths depending on
> > > lilo, or normal priority otherwise.
> > 
> > D-I release goal or Debian release goal [1]?
> 
> Clearly Debian release "goal".
> 
> > IMO the latter could well be justified as there will also need to be some 
> > kind of upgrade strategy for existing users that does not make 
> > uncontrolled changes on their hard disk or loses them the ability to boot 
> > alternative OSes on dual (or multi) boot systems.
> 
> Which might be very tricky
> 
> But, as William mentioned in his original mail, upstream activity
> seems to be low so we need to figure out if we want to keep yet
> another unmaintained software in Debian. What later puzzled me if the
> mention in non collaboratve upstream *if we don't drop Debian
> patches*.
> 
> That's not exactly inactive upstream so it would be good to clarify
> the situation of lilo upstream.
> 

Lilo upstream is dead (no release in quite a while), but the lilo
maintainer has also been seen as saying in various mailing lists etc,
that since Debian patches lilo that he has no interest in helping to fix
problems in our version.

William


signature.asc
Description: This is a digitally signed message part

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 18:19 +0200, Vincent Zweije wrote:
> On Mon, Apr 06, 2009 at 06:06:38PM +0200, Mike Hommey wrote:
> 
> ||  On Mon, Apr 06, 2009 at 08:02:04PM +0400, Dmitry E. Oboukhov 
>  wrote:
> 
> ||  > I use lilo, I like lilo.
> ||  > I don't like grub because it has unlogically config, unlogically
> ||  > behavior, strange reconfig-system. I don't like the programs with
> ||  > perverse intellect. Grub is not unixway.
> ||
> ||  Which is more perverse to read a kernel?
> ||  - reading actual files from actual filesystems
> ||  - reading hardcoded blocks on the device
> 
> I think this question should be:
> 
> Which is more perverse to read without a kernel?
> 
> The answer could still fall either way.

No, the answer is always the second one.

William



signature.asc
Description: This is a digitally signed message part

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 18:06 +0200, Mike Hommey wrote:
> On Mon, Apr 06, 2009 at 08:02:04PM +0400, Dmitry E. Oboukhov 
>  wrote:
> > OS> I also share the feeling that a lot of people still uses LILO; if
> > OS> possible I do belive it should be kept.
> > 
> > I use lilo, I like lilo.
> > I don't like grub because it has unlogically config, unlogically
> > behavior, strange reconfig-system. I don't like the programs with
> > perverse intellect. Grub is not unixway.
> 
> Which is more perverse to read a kernel?
> - reading actual files from actual filesystems
> - reading hardcoded blocks on the device

Not to mention that it breaks if the blocks span multiple devices. See
also: LVM.

William



signature.asc
Description: This is a digitally signed message part

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 17:40 +0200, Giacomo A. Catenazzi wrote:
> William Pitcock wrote:
> > On Mon, 2009-04-06 at 17:26 +0200, Giacomo A. Catenazzi wrote:
> >> Frans Pop wrote:
> >>> On Monday 06 April 2009, Christian Perrier wrote:
> >>>> Quoting William Pitcock (neno...@dereferenced.org):
> >>>>> lilo is due for removal anyway due to being unmaintained upstream and
> >>>>> the widespread availability of alternatives.
> >>> I think that last part is debatable.
> >>>
> >>>>> I do not have time to manage the removal at this point, but it will
> >>>>> be gone by June.
> >>> Has the package already been offered for adoption? Preferably with an 
> >>> overview of its current (upstream) status and main issues. I'd say that 
> >>> if there's anybody willing to (actively) maintain it, it should not be 
> >>> removed.
> >>>
> >>>> This is a heads up mail for the D-I team.
> >>> I'm not sure where the original mail comes from, but IMO this should be 
> >>> discussed on d-devel, especially since it impacts more than just D-I. I 
> >>> suspect there are quite a few packages that make some sort of provisions 
> >>> for lilo.
> >>> There are also significant numbers of people still using lilo for, at 
> >>> least for them, very good reasons.
> >> I totally agree.
> >> But I think that lilo package description must be changed, warning new
> >> users that lilo have several limits (thus not all kernel within debian
> >> are bootable with lilo).
> >>
> >> Maybe we could also require grub{,2} when installing lilo (chained
> >> as other in lilo, for emergency, new debian kernel policies, etc),
> >> but I don't know if it is feasible (e.g. when lilo is not in MBR).
> > 
> > chainloader will work with lilo, but lilo is only kept around for the
> > people who are crazy and booting off LVMs as it is.
> 
> Yes, but it works if you have an additional partition (for boot
> record). I don't know if they could live in the same partition
> (with some magic).
> 
> But IIRC lilo fails also in other cases: some xen immages, on very big
> images (which can be reached in some initram).
> 
> > Booting off LVMs is supported directly by grub2 and ext2linux could
> > probably be modified to support it in a much better way than lilo does
> > it, so this is not really a compelling argument for keeping it.
> 
> What is ext2linux? packages.d.o and google doesn't give me relevant
> informations.

Oops. It is extlinux. It's syslinux except it boots off a hard-disk
instead of a floppy or CD. Quite similar to lilo in featureset.

William


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 17:26 +0200, Giacomo A. Catenazzi wrote:
> Frans Pop wrote:
> > On Monday 06 April 2009, Christian Perrier wrote:
> >> Quoting William Pitcock (neno...@dereferenced.org):
> >>> lilo is due for removal anyway due to being unmaintained upstream and
> >>> the widespread availability of alternatives.
> > 
> > I think that last part is debatable.
> > 
> >>> I do not have time to manage the removal at this point, but it will
> >>> be gone by June.
> > 
> > Has the package already been offered for adoption? Preferably with an 
> > overview of its current (upstream) status and main issues. I'd say that 
> > if there's anybody willing to (actively) maintain it, it should not be 
> > removed.
> > 
> >> This is a heads up mail for the D-I team.
> > 
> > I'm not sure where the original mail comes from, but IMO this should be 
> > discussed on d-devel, especially since it impacts more than just D-I. I 
> > suspect there are quite a few packages that make some sort of provisions 
> > for lilo.
> > There are also significant numbers of people still using lilo for, at 
> > least for them, very good reasons.
> 
> I totally agree.
> But I think that lilo package description must be changed, warning new
> users that lilo have several limits (thus not all kernel within debian
> are bootable with lilo).
> 
> Maybe we could also require grub{,2} when installing lilo (chained
> as other in lilo, for emergency, new debian kernel policies, etc),
> but I don't know if it is feasible (e.g. when lilo is not in MBR).

chainloader will work with lilo, but lilo is only kept around for the
people who are crazy and booting off LVMs as it is.

Booting off LVMs is supported directly by grub2 and ext2linux could
probably be modified to support it in a much better way than lilo does
it, so this is not really a compelling argument for keeping it.

William


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 10:44 -0300, Otavio Salvador wrote:
> Frans Pop  writes:
> 
> > On Monday 06 April 2009, Christian Perrier wrote:
> 
> [...]
> 
> >> > I do not have time to manage the removal at this point, but it will
> >> > be gone by June.
> >
> > Has the package already been offered for adoption? Preferably with an 
> > overview of its current (upstream) status and main issues. I'd say that 
> > if there's anybody willing to (actively) maintain it, it should not be 
> > removed.
> 
> Fully agree; it should be properly offered for adoption.
> 
> >> This is a heads up mail for the D-I team.
> >
> > I'm not sure where the original mail comes from, but IMO this should be 
> > discussed on d-devel, especially since it impacts more than just D-I. I 
> > suspect there are quite a few packages that make some sort of provisions 
> > for lilo.
> > There are also significant numbers of people still using lilo for, at 
> > least for them, very good reasons.
> >
> > Anyone remember the fairly big upset when lilo was removed from testing 
> > around D-I Lenny Beta2?
> 
> I also share the feeling that a lot of people still uses LILO; if
> possible I do belive it should be kept.

The only way it is feasible to do so is to drop all of the Debian
patches. Without this, upstream is not cooperative with us.

However, I think ext2linux is a feasible upgrade path and that lilo will
become unnecessary by the release of squeeze.

William



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 15:09 +0100, Darren Salt wrote:
> I demand that Otavio Salvador may or may not have written...
> 
> > Frans Pop  writes:
> [snip]
> >> Anyone remember the fairly big upset when lilo was removed from testing 
> >> around D-I Lenny Beta2?
> 
> > I also share the feeling that a lot of people still use LILO; if possible
> > I do belive it should be kept.
> 
> . I for one use it, and intend to continue using it.

Have you looked into ext2linux? It is intended to supercede lilo. I
think your usage requirements will be satisfied by it.

William


signature.asc
Description: This is a digitally signed message part

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 16:17 +0200, Harald Braumann wrote:
> On Mon, 6 Apr 2009 17:03:10 +0800
> Paul Wise  wrote:
> 
> > On Mon, Apr 6, 2009 at 4:49 PM, Romain Beauxis wrote:
> > 
> > > I also use lilo for /boot on LVM and I also clearly remember that
> > > was the major reason for the previous debate about the removal of
> > > lilo.
> > 
> > Grub2 in lenny and later contains an lvm module:
> > 
> > /usr/lib/grub/i386-pc/lvm.mod
> > 
> > Has anyone who uses lilo for this tried grub2?
> 
> Yes, I do and it works without problems. There are some inconveniences,
> though, with grub2, which might make some stick with LILO:

The LVM support in LILO is hideously broken, so these arguments do not
really matter. It only works in certain conditions and is known to break
horribly if you have say, a kernel spanning multiple PVs.

Only a true idiot boots off an LVM volume anyway, since there is risk of
metadata corruption, etc. The real reasoning for carrying LILO around is
for machines where grub1 does not work, and we have ext2linux for those
situations now.

> 
> * on boot it takes quite some time for grub2 to scan the disks for LVM
> volumes
> 
> * configuration of grub2 is really a PITA
> 
> The is no simple configuration file that one could edit. You have to
> write scripts to add entries.

/boot/grub/{menu.lst,grub.conf} is hard to edit...?

> 
> You can't specify the default entry (only the number of the entry,
> which changes if a new kernel is installed) and there is no
> vmlinuz/vmlinuz.old (unless you add a script that adds these entries)

"default X" in the config file, and "setdefault", works for me.

> 
> You can't specify boot options per entry (there's only a global option
> in /etc/default grub, that applies to all entries).

Sure you can, just don't use update-grub(1) and update it yourself
instead. Same as lilo, really.

William


signature.asc
Description: This is a digitally signed message part

Re: net-tools future

[William Pitcock]

On Tue, 2009-03-17 at 21:30 -0600, Gunnar Wolf wrote:
> Oops... I strongly suggest providing a wrapper that matches netstat's
> format as closely as possible (even bug-for-bug if possible). Netstat
> is probably among the most used tools by sysadmins and programmers
> alike, both for software we distribute and for home-grown tools.

sockstat is similar, but needs to be adapted for IPv6 still.

William


signature.asc
Description: This is a digitally signed message part

Re: HD TV as Monitor

[William Pitcock]

Hi,

Is it 720p or 1080i or 1080p?

The following modeline makes my 720p 32" HDTV happy:

|SubSection "Display"
|Depth   24
|Modes  "1680x1050"
|EndSubSection

William

On Fri, 2009-03-13 at 16:04 -0400, Dale Scheetz wrote:
> I have a Samsung 42" HD TV. It has a connector for a computer monitor
> input, and I have been trying to get a computer hooked up to use it as
> a monitor with little luck. If the machine runs Windows it will use
> the monitor correctly as a display. If I run Damn Small it will
> display, but the bottom portion of the screen is below the bottom of
> the TV screen. Ubuntu, Knoppix, and Debian all produce "Mode Not
> Supported" messages on the TV but produce no display. If I try to use
> the Debian Install disk to create a new system, the boot up stuff
> displays fine, but when it gets to the first installation screen the
> text is diagonally ripped and unreadable.
> 
> On one of my laptops, even in windows there is no display. (I assume
> that the graphics card in that machine doesn't support the screen
> modes necessary.
> 
> On the machine where windows works, I assume the graphics card is
> capable, and I only need a functional MODE line in the config file.
> 
> At work we use wide screen TVs as monitors in meetings where groups
> need to view the screen, but then we only have Windows machines
> there...
> 
> Does anyone have any idea what the mode line should look like for these 
> devices?
> 
> I also want to take this time to thank you all for the great advances
> that Debian has made since I retired from the group the hardware
> detection and automated update processes are truly wonderful! And,
> thank you for keeping Spider in the distribution, I really appreciate
> it!
> 
> Please CC me on all responses as I am not currently signed up to this
> mailing list.
> 
> Luck,
> 
> Dwarf
> 
> 


signature.asc
Description: This is a digitally signed message part

Re: Bug#519339: ITP: tmux -- an alternative to screen, licensed under 3-BSD

[William Pitcock]

On Wed, 2009-03-11 at 23:56 +0100, Karl Ferdinand Ebert wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Karl Ferdinand Ebert 
> 
> * Package name: tmux
>   Version : 0.7
>   Upstream Author : Nicholas Marriott 
> * URL : http://sf.net/projects/tmux
> * License : BSD
>   Programming Lang: C
>   Description : an alternative to screen, licensed under 3-BSD
> 
> tmux enables a number of terminals (or windows) to be accessed and
>  controlled from a single terminal. tmux runs as a server-client system.
>  A server is created automatically when necessary and holds a number of
>  sessions, each of which may have a number of windows linked to it.
>  Any number of clients may connect to a session, or the server may be
>  controlled by issuing commands with tmux. Communication takes place
>  through a socket, by default placed in /tmp.

What does this have over screen, other than being BSD licensed?

The design of tmux seems less secure, too.

William


signature.asc
Description: This is a digitally signed message part

Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage

[William Pitcock]

On Mon, 2009-03-02 at 22:59 +0100, Guus Sliepen wrote:
> On Mon, Mar 02, 2009 at 09:10:21PM +, Ben Hutchings wrote:
> 
> > > On Mon, Mar 02, 2009 at 02:02:08AM -0600, William Pitcock wrote:
> > > > 
> > > > What does this have over PowerDNS?
> > > 
> > > Probably nothing, else that I am using it and packaging it for my own 
> > > and thought that it would be a good idea to contribute to Debian, is 
> > > redundancy a problem ?
> > 
> > Even if you're a perfectly responsible maintainer, a new package still
> > requires some work by ftpmaster, the release team, possibly the security 
> > team,
> > and so on.  It also increases the number of options a user has to choose
> > between.  If the package is redundant, this is a waste of their time.
> 
> If it is really redundant then it is also a waste of upstream's time. William,
> since you're trying to package it, could you compare it in detail to PowerDNS,
> and if there is really little difference, try to see if both upstreams can 
> work
> together and merge their efforts? That would help everyone in the end.
> 

It's not me who is trying to package it, but Sylvain Rochet.

William


signature.asc
Description: This is a digitally signed message part

Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage

[William Pitcock]

On Mon, 2009-03-02 at 16:42 +0100, Sylvain Rochet wrote:
> Hi,
> 
> On Mon, Mar 02, 2009 at 02:02:08AM -0600, William Pitcock wrote:
> > 
> > What does this have over PowerDNS?
> 
> Probably nothing, else that I am using it and packaging it for my own 
> and thought that it would be a good idea to contribute to Debian, is 
> redundancy a problem ?

No, I was just wondering if it had anything over PowerDNS because
PowerDNS has some design concepts that I do not necessarily agree with.

Specifically, the behaviour of PowerDNS's listen-address and listen-ipv6
being separate seems like an unpleasant design that I have found
annoying. listen-address and listen-ipv6 break in unpleasant ways if one
is global scope, and the other is not -- this results in the server
failing to start. I should probably file a bug on that, but I am not
sure if it is a bug or an intentional thing yet.

William



signature.asc
Description: This is a digitally signed message part

Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage

[William Pitcock]

On Mon, 2009-03-02 at 03:19 +0100, Sylvain Rochet wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Sylvain Rochet 
> 
> 
> * Package name: mydns
>   Version : 1.2.8.26
>   Upstream Author : Howard Wilkinsin 
> * URL : http://mydns.pl/
> * License : GPLv2
>   Programming Lang: C
>   Description : DNS server using MySQL or PostgreSQL for data storage
> 
> Free DNS server for UNIX implemented from scratch and designed to
> utilise the MySQL or PostgreSQL database for data storage.
> ..
> Its primary objectives are stability, security, interoperability, and
> speed, though not necessarily in that order.
> ..
> MyDNS does not include recursive name service, nor a resolver library.
> ..
> It is primarily designed for organisations with many zones and/or
> resource records who desire the ability to perform real-time dynamic
> updates on their DNS data via MySQL or PostgreSQL.

What does this have over PowerDNS?

William


signature.asc
Description: This is a digitally signed message part

Re: xcdroast does no longer work with wodim: Who to blame?

[William Pitcock]

On Sun, 2009-03-01 at 23:35 +0100, Josselin Mouette wrote:
> Le dimanche 01 mars 2009 à 22:31 +0100, Michelle Konzack a écrit :
> > I have 35 TEAC CD-Burner, 18 TraxData and a bunch of Yamaha.
> > All they are SCSI and not a singel one is working with wodim.
> > 
> > The same goes for my 4 DVD burners which are SCSI too.
> > 
> > Since I have the CD-Burner in production, I have not the time  to  check
> > wodim years for bugs.
> > 
> > I have installed cdrecord and it just  work  like  Nero4linux  with  the
> > difference, that Nero can handel only one Burner @once but cdrecors  all
> > 28 TEAC burner on the installed 4 Cards @once...
> 
> Unfortunately, as such, we are not going to distribute either Nero
> (which is non-free) nor cdrecord (which is undistributable). If you are
> interested into improving CD burning support in Debian, you’re welcome
> to either help fixing these bugs in wodim or help resolving the
> licensing situation of cdrecord. 

Or look into libburn + cdrskin, which should "just work".

William


signature.asc
Description: This is a digitally signed message part

Re: xcdroast does no longer work with wodim: Who to blame?

[William Pitcock]

On Sat, 2009-02-28 at 17:54 +0100, Arthur de Jong wrote:
> On Sat, 2009-02-28 at 12:43 +1100, Russell Coker wrote:
> > http://en.wikipedia.org/wiki/Joerg_Schilling
> > 
> > I notice that Joerg's Wikipedia page is rather bare.
> > 
> > Instead of spending time covering all the old arguments on this list,
> > perhaps some people could add links (such as the ones you cited) to
> > Joerg's Wikipedia page.  A Wikipedia page about Joerg that is remotely
> > complete and also neutral requires a reference to these issues (the
> > current page only has two paragraphs).
> 
> Have a look at the cdrtools page:
> http://en.wikipedia.org/wiki/Cdrtools
> 
> The cdrkit page also has some info:
> http://en.wikipedia.org/wiki/Cdrkit
> 

We should take information from those pages and copyedit them into
something suitable for inclusion on Joerg's page. The best part is Joerg
will probably try to delete it, but it will be reverted due to
"vandalism".

William


signature.asc
Description: This is a digitally signed message part

Re: xcdroast does no longer work with wodim: Who to blame?

[William Pitcock]

On Fri, 2009-02-27 at 12:38 +0100, Joerg Schilling wrote:
> Roger Leigh  wrote:
> 
> > On Fri, Feb 27, 2009 at 11:56:38AM +0100, Joerg Schilling wrote:
> > > William Pitcock  wrote:
> > > 
> > > > 2. I am not convinced that there is any legal issue with the fork of
> > > > cdrecord as wodim; it is clearly identified that it is a fork, and
> > > 
> > > There definitely _is_ a major legal problem with the fork.
> >
> > Please provide specific details, rather than vaguely defined "major
> > problems".
> 
> Read the related entry in the Debian bugtracking system before asking me for 
> details.
> 

Can you provide a URL to this entry? I have still yet to find it.

William


signature.asc
Description: This is a digitally signed message part

Re: xcdroast does no longer work with wodim: Who to blame?

[William Pitcock]

On Fri, 2009-02-27 at 12:26 +0100, Joerg Schilling wrote:
> William Pitcock  wrote:
> 
> > > are some "Debian maintainers" that rather attack software authors instead 
> > > of 
> > > colaborating.
> >
> > It is impossible to collaborate when you add invariant sections to the
> > code. Well done.
> 
> This is a text that has been created in collaboration a former Debian 
> maintainer.
> 

So what?

> 
> > Generally it is considered to be bad taste when you change the licensing
> > rules abruptly.
> 
> It is generally considered bad taste to offend and to try to blackmail the 
> Copyright holder. As this has been done by the Debian package maintainer, 
> Debian should not complain. Note that the license change was caused by 
> attacks from a Debian maintainer and that the license change that was done 
> in an agreement with the other authors.

What does Eduard being a Debian maintainer have to do with it? Also,
ISTR Eduard no longer being involved in Debian at all, or cdrkit.

William


signature.asc
Description: This is a digitally signed message part

Re: xcdroast does no longer work with wodim: Who to blame?

[William Pitcock]

On Fri, 2009-02-27 at 11:56 +0100, Joerg Schilling wrote:
> William Pitcock  wrote:
> 
> > > > > The fork distributed by Debian may however be called dubious:
> > > > > 
> > > > > - The fork is in conflict with the Copyright law and thus may not 
> > > > > be 
> > > > >   legally distributed.
> > > >
> > > > If your code was Free Software, then it is perfectly legal for Debian to
> > > > do what it does.
> > > 
> > > It seems that you first need to learn what Free Software means and what 
> > > constraints the License and the Copyright law enforce. A Free software 
> > > license
> > > allows you to do many things, it does definitely not allow you what 
> > > Debian did.
> >
> > While I personally do not use wodim, simply because wodim does not
> > inspire much confidence with me being based on cdrecord, I have a few
> > observations:
> >
> > 1. If your code was licensed correctly, and there wasn't concerns about
> > it's quality, then nobody inside Debian would have forked it.
> 
> This is an asumption that is only true in a "nice world". Unfortunately, there
> are some "Debian maintainers" that rather attack software authors instead of 
> colaborating.

It is impossible to collaborate when you add invariant sections to the
code. Well done.

Generally it is considered to be bad taste when you change the licensing
rules abruptly.

> 
> wodim has been created by Eduard Bloch because he is a person who is 
> interested 
> in actively preventing collaboration.
> 

I am sorry that you are hurt about that, but get over it.

> The attacks run by him started in May 2004 and at that time he did already 
> create broken (buy him) versions of cdrecord and shipped them as Debian 
> package.
> 
> 
> > 2. I am not convinced that there is any legal issue with the fork of
> > cdrecord as wodim; it is clearly identified that it is a fork, and
> 
> There definitely _is_ a major legal problem with the fork.

I have a solution that I think will make us all happy.

Why not just get rid of cdrkit and write some nice wrappers for cdrecord
and other components of cdrtools using libburn/libisofs. That way we get
a CD/DVD/BD burning engine that isn't originated from *you*, so *you*
can't complain about it anymore.

If cdrkit is as buggy as you claim, and you are so busy trolling, then I
feel that we cannot hold confidence in your product either. Good job on
that.

After all, if we aren't using your code or any derivative of your code,
then you have no reason to complain at us.

William


signature.asc
Description: This is a digitally signed message part

Re: xcdroast does no longer work with wodim: Who to blame?

[William Pitcock]

On Thu, 2009-02-26 at 15:47 +0100, Joerg Schilling wrote:
> Before Eduard Bloch made insane modifications, the code was GPLv2 and legal.
> Now the cude is undistributable because of modifications in the fork
> that are incompatible with the Copyright law.
>  
> See my bug report from December 2006.
> 

Please provide a URL for this supposed bug report. I have spent the last
30 minutes datamining bugs.debian.org for it, and have found nothing
other than replies to other bug reports from you which mostly have to do
with whining.

William


signature.asc
Description: This is a digitally signed message part

Re: xcdroast does no longer work with wodim: Who to blame?

[William Pitcock]

Hi,

On Fri, 2009-02-27 at 00:18 +0100, Joerg Schilling wrote:
> John Goerzen  wrote:
> 
> > Joerg Schilling wrote:
> >
> > > 
> > > The fork distributed by Debian may however be called dubious:
> > > 
> > > - The fork is in conflict with the Copyright law and thus may not be 
> > >   legally distributed.
> >
> > If your code was Free Software, then it is perfectly legal for Debian to
> > do what it does.
> 
> It seems that you first need to learn what Free Software means and what 
> constraints the License and the Copyright law enforce. A Free software license
> allows you to do many things, it does definitely not allow you what Debian 
> did.

While I personally do not use wodim, simply because wodim does not
inspire much confidence with me being based on cdrecord, I have a few
observations:

1. If your code was licensed correctly, and there wasn't concerns about
it's quality, then nobody inside Debian would have forked it.

2. I am not convinced that there is any legal issue with the fork of
cdrecord as wodim; it is clearly identified that it is a fork, and
anything published describing problems with cdrecord would be the
opinions of wodim's authors, not the Debian project itself, or the wodim
project itself. As a result, no personal harm to your reputation has
been done in the context of the Urheberrechtsgesetz[1] by the fork of
cdrecord itself. As a result, it appears that your argument that the
fork of cdrecord being illegal is actually invalid.

3. You might be taken more seriously at this point if you didn't act
like a toddler. I'm just saying... every time this subject comes up, you
show up and whine and whine and whine. It's doing you no good. Try
something else, like improving cdrecord with your time instead of
wasting it whining here.

Please note that I haven't even tried wodim. I suspect it is not any
better than cdrecord, and further I don't care. All of the burning apps
I use are based around libburn, which seems to have a drama-free
maintainer. I consider that to be a good thing, the fact that it
supports more than just CD burning without any bogus license key-based
closed-source "cdrecord-pro" software is a plus.

[1] Everyone here should read the Urheberrechtsgesetz here
http://www.iuscomp.org/gla/statutes/UrhG.htm and stop listening to
Joerg's bollocks. He appears to be very misinformed.

> 
> > If your code wasn't Free Software, then we wouldn't be using it in the
> > first place.
> 
> > ISTR that your code WAS free, but now isn't.
> 
> The code that was taken by Debian for the fork WAS free but now it is no 
> longer
> because Debian did apply changes that are forbidden by law.

What changes are those? Can you identify them? "All of them" is not a
valid response here, just FYI.

> 
> As you don't know what grants and what duties you have when dealing with free 
> software, please try to inform yourself. You may get into trouble if you 
> change
> things that are forbidden by law.

I am pretty sure Eduard knows what he is doing.

> 
> Let me quote the license person from the board of directors from the 
> OpenSource 
> initiave:
> 
>   No OpenSource license gives you all grants you need to change anything  
>   in the  source. If the authors or Copyright holders of a software like,
>   they may always sue you. If you like to avoid being sued, play nicely
>   with the Copyright holders.

Just because you can sue someone does not make their actions illegal. I
can sue somebody for skipping a rock across a puddle in their own
property, mind I would be laughed out of court for doing this, but I
hope you see my point here.

> 
> Eduard Bloch made a big mistake, he started a deffamation campaign against 
> cdrtools and Debian made the mistake to support Eduard Bloch.
> 
> I don't know whether you are able to change the named mistake, but please note
> that I am the copyright holder for the vast majority of the cdrtools code. I 
> am 
> licensing the code and I am able to sue people for Copyright violations on 
> the 
> code, Debian is not. If Debian claims they might be sued because of so called 
> license problems in the original software, this is just FUD. I am not 
> interested to sue people as long as there is a chance to have a solution that 
> does not need a court. If Debian however continues to attack me, Debian should
> be aware that at some point I am forced to sue people for violating GPL and 
> Copyright law with the fork.
> 

People who make threats should be fully prepared to deal with backlash
from those threats. How will Fraunhofer handle such a public relations
disaster? You may want to keep this in consideration before continuing
with legal threats, as I am pretty sure that it will be all over
slashdot, and Fraunhofer will likely be asked for a comment.

> So let me ask: Is Debian willing to "play nicely" with me in the future or is
> Debian interested in continuing the attacks?
> 
> In case you don't know: My main interest is to make sure that the software I

Re: Accelerated video cards and non-free firmware

[William Pitcock]

On Wed, 2009-02-25 at 16:28 -0500, Daniel Dickinson wrote:
> Hi,
> 
> I'm looking at getting a video card, and I want to know what video card
> that has 3D acceleration to get.  Normally I'd ask on -users but as the
> subject says I want to know what video cards will still have
> acceleration when the non-free firmware is removed from the kernel,
> which is supposed to happen for squeeze.
> 
> I had heard that the ATI cards, which would normally be my first
> choice, have non-free firmware in the driver, which may be removed.  Is
> this true, and if so what accelerated cards will have have acceleration
> once non-free firmware is removed.
> 
> I can delay purchase (easily), if the answer to this is not yet known.

The kernel team has separated out the radeon firmware as part of the
firmware-nonfree package in non-free. So, if you run with non-free
enabled and install the firmware-nonfree package, radeon cards will
continue to behave as expected.

William


signature.asc
Description: This is a digitally signed message part

Re: PlayOnLinux in contrib

[William Pitcock]

On Wed, 2009-02-18 at 19:30 +0100, Bertrand Marc wrote:
> Mehdi Dogguy a écrit :
> > If it's GPLv2+ and doesn't depend on proprietary software, why it cannot
> > be in main?
> > Does it depend on proprietary things?
> >
> > Regards,
> As it is now, PlayOnLinux makes the user install Microsoft fonts. You 
> can say no, but it will keep asking every time you start PlayOnLinux. We 
> are currently thinking to add a Depends: ttf-mscorefonts-installer 
> because of that...

Or you could patch it to stop asking.

William


signature.asc
Description: This is a digitally signed message part

Re: AW: Bug#515130: ITP: unrealircd -- Unreal IRC Server

[William Pitcock]

On Mon, 2009-02-16 at 08:37 +0100, Patrick Schoenfeld wrote:
> On Sun, Feb 15, 2009 at 09:00:22PM -0600, William Pitcock wrote:
> > There is also questions concerning why you would want to package
> > something that has effectively a dead upstream, and many code flaws
> > which could result in security issues in the future.
> 
> Uh? Since when is Unrealircd dead upstream? I wouldn't call a release
> less then a month ago "dead upstream", regardless of what can be
> said about unrealircd otherwise.

Once 3.2.8 final is out the door, it will be stagnant. "Syzop" has a
fairly large slacker attitude, and is only interested in Unreal for the
money (oops, it doesn't make any for him anymore. especially not now
with InspIRCd).

As such, we can call Unreal dead now, barring some miracle -- but I
don't see this happening with next generation ircd picking up steam like
InspIRCd - which cater to that same market of IRC admin which would be
interested in Unreal.

William


signature.asc
Description: This is a digitally signed message part

Re: Bug#515663: ITP: kmess2 -- Windows(R) Live(R) Messenger(R) Client for KDE4.

[William Pitcock]

On Mon, 2009-02-16 at 20:38 +0100, Rafael Belmonte wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org
> 
> --- Please fill out the fields below. ---
> 
>Package name: kmess2
> Version: 2.0alpha
> Upstream Author: Diederik van der Boor
> URL: http://kmess.org
> License: GPL-2
> Description: Kmess2 is an instant messenger for Windows(R) Live(R)  
> Messenger(R) protocol for KDE4.
> It supports emoticons, drawing, avatar and videoconference.
> 

A better description is needed. The first line should be short and
lowercase.

The second part should be at least a paragraph.

William


signature.asc
Description: This is a digitally signed message part

Re: AW: Bug#515130: ITP: unrealircd -- Unreal IRC Server

[William Pitcock]

On Mon, 2009-02-16 at 07:56 +0100, Giacomo Catenazzi wrote:
> Rondal wrote:
> > Hi,
> >  
> >> UnrealIRCd has many licensing and code-quality issues which would
> >> block it's inclusion in a Debian release.
> > 
> > I admit that the sourcecode is not of the highest quality, but I do not
> > see where it will block inclusion into Debian. About the licensing issues
> > I already said that their license is incompatible with the OpenSSL license
> > but thats it.
> > 
> > Please be a little bit more specific. If I missed something important
> > within
> > their license or code, I will gladly reconsider building this package.
> 
> IIRC unrealircd will pass to inspiricd sources, so I recommend you to
> evantually pack only the "develpement" version.

That effort is dead. UnrealIRCd itself is basically a walking zombie. We
don't need this in Debian -- it is more trouble than it is worth.

William


signature.asc
Description: This is a digitally signed message part

Re: AW: Bug#515134: ITP: ircservices -- IRC Services for IRC networks providing services like Nick- and ChanServ

[William Pitcock]

Hi,

On Sat, 2009-02-14 at 13:59 +0100, Rondal wrote:
> retitle 515134 ITP: ircservices-church -- IRC Services for IRC networks
> providing services like Nick- and ChanServ
> 
> Hi,
> 
> > See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424844 .
> > Inclusion of ircservices in Debian may be problematic.
> 
> I missed this one when I looked for ITPs/RTPs. I've did a little bit
> testing over the last hour and it seems that there is no longer
> any problem building on amd64.
> 
> The very generic name is another problem discussed in #424844, I see
> no problem in renaming, especially because there are currently no
> other IRC Services packages in the repositories and I don't want
> to support the wrong impression that those are the one and only
> ircservices.

Andrew Church's IRCServices is dead upstream, other than "security
fixes", and those will most likely stop within Squeeze's release
lifecycle. Do you intend to maintain it yourself?

If not, I strongly urge you to not package this.

William


signature.asc
Description: This is a digitally signed message part

Re: AW: Bug#515130: ITP: unrealircd -- Unreal IRC Server

[William Pitcock]

Hi,

On Sat, 2009-02-14 at 12:50 +0100, Rondal wrote:
> Hi,
>  
> > UnrealIRCd has many licensing and code-quality issues which would
> > block it's inclusion in a Debian release.
> 
> I admit that the sourcecode is not of the highest quality, but I do not
> see where it will block inclusion into Debian. About the licensing issues
> I already said that their license is incompatible with the OpenSSL license
> but thats it.
> 
> Please be a little bit more specific. If I missed something important
> within
> their license or code, I will gladly reconsider building this package.

Carsten Munk has specifically requested that UnrealIRCd not be included
in Debian, and will likely be hostile towards it's inclusion.

Secondly, UnrealIRCd uses OpenSSL for SSL support, and non DFSG-free
versions of the MD5 algorithm for hostcloaking. Both of these DFSG
violations would be required for inclusion into Debian, as they are also
a GPL license violation.

There is also questions concerning why you would want to package
something that has effectively a dead upstream, and many code flaws
which could result in security issues in the future.

William


signature.asc
Description: This is a digitally signed message part

Re: Bug#515134: ITP: ircservices -- IRC Services for IRC networks providing services like Nick- and ChanServ

[William Pitcock]

Hi,

On Fri, 2009-02-13 at 21:52 +0100, Stefan Becker wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Stefan Becker 
> 
> 
> * Package name: ircservices
>   Version : 5.1.14
>   Upstream Author : Andrew Church 
> * URL : http://www.ircservices.za.net/
> * License : GPL
>   Programming Lang: C
>   Description : IRC Services for IRC networks providing services like 
> Nick- and ChanServ
> 
> Services provides for definitive nickname and channel ownership, as well as 
> the ability to send
> messages ("memos") to offline users, and gives IRC operators considerably 
> more control over the
> network. In particular, Services provides the following features to an IRC 
> network:
> 
>  * Nickname management: Services allows users to "register" nicknames. 
>  * Channel management: Like nicknames, Services allows users to register 
> channels as well. 
>  * Messages to offline users: Allowing users to leave messages for offline 
> users. 
>  * Centralized network management: Features which allow IRC operators greater 
> control over the network 

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424844 . Inclusion
of ircservices in Debian may be problematic.

William


signature.asc
Description: This is a digitally signed message part

Re: Bug#515130: ITP: unrealircd -- Unreal IRC Server

[William Pitcock]

On Fri, 2009-02-13 at 21:37 +0100, Stefan Becker wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Stefan Becker 
> 
> 
> * Package name: unrealircd
>   Version : 3.2.7
>   Upstream Author : Carsten Munk (stske...@unrealircd.com),
> Dominick Meglio (codema...@unrealircd.com),
> David Flynn,
> McSkaf,
> Finny Merrill (grie...@unrealircd.com),
> Bram Matthys (sy...@unrealircd.com)
> * URL : http://www.unrealircd.com/
> * License : GPL
>   Programming Lang: C
>   Description : Unreal IRC Server
> 
> A full featured and highly configurable IRC daemon with the option
>  to load custom modules from third parties into it.
>  .
>  Development of UnrealIRCd began in May of 1999. Unreal was created
>  from the Dreamforge IRCd that was formerly used by the DALnet IRC
>  Network. Over the years, many new and exciting features have been
>  added to Unreal. It is hard to even see a resemblance between the
>  current Unreal and Dreamforge.

UnrealIRCd has many licensing and code-quality issues which would block
it's inclusion in a Debian release.

I strongly recommend you do not package this.

William


signature.asc
Description: This is a digitally signed message part

Re: Release Candidate 2 of Debian Installer

[William Pitcock]

On Tue, 2009-02-03 at 23:43 +0100, Harald Braumann wrote:
> On Tue, 3 Feb 2009 12:35:48 +0900
> Paul Wise  wrote:
> 
> > How about letting the person doing the installation write the labels
> > if they want to use LABEL and use UUID by default.
> > 
> Or as a third option, put everything in LVM, including boot and root,
> and the problem goes away. GRUB2 would have to be used, though.

I am not sure GRUB2 is ready for a production release of Debian. It will
be by squeeze, but not yet for lenny IMHO.

Right now for booting off LVM, we use lilo. This is lilo's main use-case
in Debian currently[1], excluding hardware configurations where GRUB1
fails to work correctly.

A configuration resulting in us using lilo as the default bootloader is
probably not a good idea for many reasons, of which I have gone through
before, and do not intend to outline here (mostly related to the age of
the lilo codebase, and the fact that lilo needs to be refactored if it
is to remain relevant for much longer).

William

[1] debian-installer explicitly installs lilo instead of grub when a LVM
is used as the boot partition.


signature.asc
Description: This is a digitally signed message part

Re: Release Candidate 2 of Debian Installer

[William Pitcock]

On Mon, 2009-02-02 at 14:09 -0600, Gunnar Wolf wrote:
> Mike Hommey dijo [Sun, Feb 01, 2009 at 10:46:11AM +0100]:
> > > > A good option would be to use LABEL or UID instead. However I am not 
> > > > sure if that has some drawbacks as well:
> > > > 
> > > > - for uuid the system is less forgiving if you swap disks
> > > > - for label the system is less forgiving if you bring in temp. new disks
> > > > 
> > > > So I think UUID has less risks.
> > > 
> > > Anaconda uses LABEL. I don't know the full rationale on why this is, but
> > > it may be a good idea to follow suit.
> > 
> > And thanks to that, it's a PITA to have several RH/Fedora installs on the
> > same computer.
> 
> Still, it is a saner overall system. Of course, if during install d-i
> finds there is already a partition labeled 'root', it could either ask
> the user for an alternative name or set it to
> d-i-${timestamp}-root. Or label all the partitions with a timestamp,
> preemptively avoiding this kind of conflicts.
> 
> FWIW, setting them by label is the most flexible and robust way, not
> tied to hardware keys or specific hookups. 

It can't because 'd-i-${timestamp}-root' is longer than 16 characters.

William


signature.asc
Description: This is a digitally signed message part

Re: Release Candidate 2 of Debian Installer

[William Pitcock]

On Sun, 2009-02-01 at 10:46 +0100, Mike Hommey wrote:
> On Sun, Feb 01, 2009 at 03:22:07AM -0600, William Pitcock wrote:
> > On Sun, 2009-02-01 at 00:19 +0100, Bernd Eckenfels wrote:
> > > In article <87bptnccj6@mid.deneb.enyo.de> you wrote:
> > > > What needs to be done so that these two issues can be fixed?
> > > > 
> > > > | Disk devices may change on reboot
> > > 
> > > A good option would be to use LABEL or UID instead. However I am not sure 
> > > if that has some drawbacks as well:
> > > 
> > > - for uuid the system is less forgiving if you swap disks
> > > - for label the system is less forgiving if you bring in temp. new disks
> > > 
> > > So I think UUID has less risks.
> > 
> > Anaconda uses LABEL. I don't know the full rationale on why this is, but
> > it may be a good idea to follow suit.
> 
> And thanks to that, it's a PITA to have several RH/Fedora installs on the
> same computer.

Yes, I could indeed see why this would be problematic. So, UUID might
indeed be a better solution.

William


signature.asc
Description: This is a digitally signed message part

Re: Release Candidate 2 of Debian Installer

[William Pitcock]

On Sun, 2009-02-01 at 00:19 +0100, Bernd Eckenfels wrote:
> In article <87bptnccj6@mid.deneb.enyo.de> you wrote:
> > What needs to be done so that these two issues can be fixed?
> > 
> > | Disk devices may change on reboot
> 
> A good option would be to use LABEL or UID instead. However I am not sure if 
> that has some drawbacks as well:
> 
> - for uuid the system is less forgiving if you swap disks
> - for label the system is less forgiving if you bring in temp. new disks
> 
> So I think UUID has less risks.

Anaconda uses LABEL. I don't know the full rationale on why this is, but
it may be a good idea to follow suit.

William


signature.asc
Description: This is a digitally signed message part

Bug#513322: ITP: mupen64plus -- plugin-based N64 emulator

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock 

* Package name: mupen64plus
  Version : 1.5
  Upstream Author : "Blight" 
* URL : http://code.google.com/p/mupen64plus
* License : GPLv2
  Programming Lang: C/C++
  Description : plugin-based N64 emulator
 Mupen64Plus is a plugin-based N64 emulator for Linux which is capable of
 accurately playing many games. Included are four MIPS R4300 CPU emulators,
 with dynamic recompilers for 32-bit x86 and 64-bit amd64 systems, and
 necessary plugins for audio, graphical rendering (RDP), signal co-processor
 (RSP), and input.

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#511980: ITP: Plumi -- Plumi is a Free Software video sharing Content Management System based on Plone.

[William Pitcock]

On Fri, 2009-01-16 at 11:22 +1100, Andy Nicholson wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Andy Nicholson 
> 
> * Package name: Plumi

Package names need to be lowercase.

>   Version : 0.2.3
>   Upstream Author : Andy Nicholson 
> * URL : http://plumi.org/
> * License : GPL
>   Programming Lang: Python
>   Description : Plumi is a Free Software video sharing Content Management 
> System based on Plone.

The short description should be lowercase, also placing "free software"
here is redundant, as the Section: header will tell you if it is free or
not (foo vs non-free/foo).

The short description should not be a complete sentence.

Something like "video sharing CMS based on Plone" would be sufficient
here.

> 
> Plumi is a Free Software video sharing Content Management System based on 
> Plone and produced by 
> the EngageMedia collective. Plumi enables you to create your own 
> sophisticated video sharing site; 
> by adding it to an existing Plone instance you can quickly have a wide array 
> of functionality to 
> facilitate video distribution and community creation.

Please make sure your description is wrapped to 80 characters.

> 
> In a net landscape where almost all video sharing sites keep their 
> distribution platform under 
> lock and key, Plumi is one contribution to creating a truly democratic media.

The second paragraph does not add anything to the package description;
you should consider removing it.

William


signature.asc
Description: This is a digitally signed message part

Bug#511997: ITP: libdownload -- library for downloading files from HTTP/FTP

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock 

* Package name: libdownload
  Version : 1.3
  Upstream Author : Aaron Griffin 
* URL : http://www.archlinux.org/pacman
* License : BSD
  Programming Lang: C
  Description : library for downloading files from HTTP/FTP
 Libdownload is a library for downloading files from HTTP/FTP servers.
 It is a fork of libfetch, used by FreeBSD and others, and supports a
 very simple interface for downloading files into memory buffers and
 file descriptors. Changes from libfetch include modification to improve
 portability, and proper use of select(2) timeouts.

This is being packaged because it is a dependency of pacman-package-manager
(see #511994).

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#511994: ITP: pacman-package-manager -- minimalist package manager using tarballs and scripts

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock 

* Package name: pacman-package-manager
  Version : 3.2.2
  Upstream Author : Judd Vinet 
* URL : http://www.archlinux.org/pacman
* License : GPL
  Programming Lang: C
  Description : minimalist package manager using tarballs and scripts
 Pacman is a package manager typically used by ArchLinux and similar
 distributions. It features a simple design which is easy for packagers
 to create functional packages with, and utilizes a simple tarball-based
 package format.
 .
 Using Pacman directly will bypass the Debian packaging system, and
 therefore is not recommended. The recommended use of this package is
 for bootstraping ArchLinux chroots.

This package is being packaged to facilitate support for ArchLinux and other
pacman-using distributions as ApplianceKit guests (for both vserver and xen
installations).

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Sections - especially section:kde and section:gnome

[William Pitcock]

On Fri, 2009-01-02 at 13:43 +, Sune Vuorela wrote:
> I guess we actually need to consider what the sections are good for.
> Asking in a random irc channel at least didn't reveal any real
> answers.
> So what about killing the concept of sections entirely ?

The primary user of section: is packages.debian.org, as far as I can
tell.

I also believe that dselect/aptitude/synaptic use them to organize it's
package browser. But I don't use those tools.

William


signature.asc
Description: This is a digitally signed message part

Re: Josselin Mouette and Planet Debian

[William Pitcock]

Hi,

On Thu, 2008-12-18 at 23:04 +1100, Russell Coker wrote:
> The above article concerns the damage that Josselin's actions cause to the 
> Debian project.  D-d-a is not that different from other parts of Debian, bad 
> behaviour in other forums also hurts the project.

I think that flame-war threads with 81 posts in them resulting in many
contributors slagging many other contributors also hurts the project. In
fact, I find it quite appalling.

If we are truly concerned about the health of Debian, then why do we
continuously flame other people's behaviour?  These flame-wars are
causing much more damage to Debian than any bad stories being published
on websites will ever do.

I am reading things recently like discussion about people making
petitions to expel other people from the project entirely (e.g. Manoj),
flame-wars like these, and other crap. This stuff is tearing Debian
apart, and while people may feel that these concerns are valid -- they
really are not worth the damage that raising them in this way is
causing.

Reading stuff like this concerns me about the future and viability of
Debian. As most people who contribute to Debian, I do so with the goal
of improving Debian's utility to myself (in the choices of packages I
choose to maintain -- those are programs I tend to use), and to the rest
of the community (hopefully they like to use them too). If stuff like
this continues, there may not be any perceived point in improving
Debian. (Why work on an OS that has an undefined future?)

Debian is a project to create a free operating system, not a trolling
collective. If you have issues with Josselin, then you should resolve
those in a private environment. You, and everyone else, have the right
to ignore other people, and what they are doing outside of their
contributions to the project.

People who do a great amount of work on Debian (manoj and joss and who
knows who will be next) -- far more work than I do on Debian -- are
being targeted by vigilantism. This is truly unacceptable. Maybe they
deserve it, maybe they do not, but this is stuff that I at least find
appalling.

Everyone should stop playing this drama game, and get back to working on
releasing Lenny. Every moment that is wasted on bullshit like this is
time that could be spent on fixing an RC bug.

William


signature.asc
Description: This is a digitally signed message part

Re: Packages still depending on GTK+ 1.2

[William Pitcock]

On Sat, 2008-12-06 at 20:42 +0100, Klaus Ethgen wrote:
> You forgot xmms. It is still heavily used and there are no alternative
> for it. (It is just such a application as xv - very old but there are no
> alternative that completely replace it (in all facets).)

There's not?

There's at least 20 different media players in Debian that are
available, that cover the same codec support (at least partially) of
XMMS.

Unless you're talking about the ugly XMMS GUI. In which case, I believe
QMMS is available for packaging.

William


signature.asc
Description: This is a digitally signed message part

Re: Packages still depending on GTK+ 1.2

[William Pitcock]

On Sat, 2008-12-06 at 19:08 +0100, Josselin Mouette wrote:
> Le vendredi 05 décembre 2008 à 21:43 -0600, Raphael Geissert a écrit :
> > > Alain Schroeder <[EMAIL PROTECTED]>
> > >gsnes9x
> > >  => visualboyadvance ?
> > 
> > C'mon, there are at least 15 years between the two consoles.
> > And nope, visualboyadvance doesn't replace gsnes9x, although the latter is 
> > just
> > a front-end.
> 
> Gah, I thought it was able to handle SNES ROMs. The correct answer would
> probably be zsnes, although it only works on i386.
> 

Actually, gsnes9x can just be dropped. It is just a frontend to snes9x
(which, afaik, uses Xlib directly).

William


signature.asc
Description: This is a digitally signed message part

Bug#507233: ITP: appliancekit -- tools for managing, creating and deploying software appliances

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock <[EMAIL PROTECTED]>

* Package name: appliancekit
  Version : 0.131
  Upstream Author : William Pitcock <[EMAIL PROTECTED]>
* URL : http://appliancekit.systeminplace.net/
* License : ISC
  Programming Lang: Python
  Description : tools for managing, creating and deploying software 
appliances
 ApplianceKit is a tool for authoring and distributing software appliances.   
 Appliance authors typically distribute the appliance in the form of an XML
 metadata file, which ApplianceKit uses to compile into a functional
 appliance.
 .
 ApplianceKit supports deploying to chroots, Xen domains, and VServer 
 containers. It is an essential tool for deploying virtual machines in a
 hosting environment due to it's abilities to provide for a fully customized
 environment inside the appliance instance.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)



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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[William Pitcock]

Hi,

On Sat, 2008-11-29 at 02:19 +0100, Holger Levsen wrote:
> Hi,
> 
> On Saturday 29 November 2008 01:57, William Pitcock wrote:
> > What I propose is something more along the lines of Gentoo's "sunrise"
> > overlay... a repository that anyone can get upload access to provided
> > that they understand basic Debian policy and have established that they
> > will be non-malicious (likely through some sort of indirect uploading
> > for a few months). Basically a true *community* repo.
> 
> just seen on #debian-community
> 
>  hmmm
>  "community-repo" makes me think we should setup somethink like 
> ubuntus PPA on debian-community.org
>  interesting idea
> * h01ger scratches head

As mentioned on #debian-community, I don't think PPAs are the right way
to address this because PPAs are separate from each other, and therefore
require many sources.list lines.

The ideal way to handle this would be to have a single repository. PPAs
solve a different problem, which is giving contributors and developers a
playground to publish their in-progress packages. This is more about
getting packages to users in an efficient way, for maintainers that do
not wish to include those packages in Debian proper for either policy
reasons, code quality reasons, or otherwise.

William



signature.asc
Description: This is a digitally signed message part

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[William Pitcock]

Hi,

On Fri, 2008-11-28 at 23:57 +0100, Holger Levsen wrote:
> Hi,
> 
> On Friday 28 November 2008 22:42, William Pitcock wrote:
> > I think issues like these call for an unsupported repository outside of
> > Debian, but publicized within the community as an unofficial repository
> > for things like qmail, packages unwanted in Debian proper for the time
> > being, etc.
> 
> debian-unofficial.org

There's a few problems with debian-unofficial.org, as I see it:

1. It has the same quality requirements as Debian proper in terms of
packaging and code quality -- in my way of interpreting things, qmail
would not be acceptable here;
2. I believe, but may be wrong, that [EMAIL PROTECTED] is the only person who
can actually add anything to it. So if daniel does not like qmail for
example, it would not be added.

What I propose is something more along the lines of Gentoo's "sunrise"
overlay... a repository that anyone can get upload access to provided
that they understand basic Debian policy and have established that they
will be non-malicious (likely through some sort of indirect uploading
for a few months). Basically a true *community* repo.

This would likely be with the packaging source being maintained in SVN,
so that there is a large amount of transparency in the maintenance
process.

William


signature.asc
Description: This is a digitally signed message part

what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[William Pitcock]

Hi,

On Fri, 2008-11-28 at 20:51 +0100, Neil Williams wrote:
> > Can you advise me on how to get out of that dilemma?
> 
> Stop trying to get qmail into Debian?
> or
> Take on upstream development of qmail and solve all the problems
> (whether qmail will then be recognisable compared to the existing
> packages that do the same job, I have no idea).
> 

I think issues like these call for an unsupported repository outside of
Debian, but publicized within the community as an unofficial repository
for things like qmail, packages unwanted in Debian proper for the time
being, etc.

That way if people want to run qmail, they can easily get it, but under
the understanding that it was unofficial and totally unsupported by
Debian itself. (A debbugs installation could be provided for maintainers
if necessary though.)

We could also use this repository as a way for teaching new maintainers
(as an alternative to sponsorship, for the most part) -- packages that
people use could be cherrypicked out of this archive by DDs who want the
package in Debian.

Thoughts?

William


signature.asc
Description: This is a digitally signed message part

Re: screenshots.debian.net goes beta

[William Pitcock]

On Mon, 2008-11-10 at 15:29 +0100, Christoph Haas wrote:
> On Montag, 10. November 2008, Guus Sliepen wrote:
> > On Mon, Nov 10, 2008 at 03:05:32PM +0100, Christoph Haas wrote:
> > > it took a little longer than I expected but I finally launched
> > >
> > >   http://screenshots.debian.net
> >
> > [...]
> >
> > > Have fun and let me know what you think.
> >
> > Please do not reduce images in size. The screenshots of, for example,
> > dillo and amiwm are horrible. If you have a guideline of having a
> > maximum size of 800x600 pixels, just give an error when someone uploads
> > a screenshot that is larger than that.
> 
> In the "guidelines" I suggest not to upload screenshots larger than 800x600 
> if the uploader doesn't want automatic reduction. Too large images cannot 
> be viewed properly (e.g. I wouldn't be able to enjoy a 1600x1280 image on 
> my screen) by most users. So I thought that 800x600 is a good compromise.

800x600 would be a good compromise provided that the original is
available.

William


signature.asc
Description: This is a digitally signed message part

Re: DFSG violations: non-free but no contrib

[William Pitcock]

On Thu, 2008-10-30 at 10:34 +, Robert Lemmen wrote:
> hi everyone,
> 
> the current situation concerning firmware blobs and dfsg-freeness is a
> bit sad, among other things because there really isn't too much we can
> do about it in the short run. so how about some practical proposal that
> we can actually implement in a reasonable timeframe that gets us in a
> better position to deal with this in the long run? my idea would be:
> 
> firmware blobs without source get put into non-free, firmware blobs with
> source but without the necessary free tools to generate the image end up
> in contrib, firmware which is cryptographically signed and can tehrefore
> not be modified goes to non-free. we relax the "main" requirements
> insofar that a package that depends on another package in non-free may
> stay in main (and doesn't have to go to contrib), if the contents of
> that other package are not executed or used on the main/host computer'c
> cpu, but on some additional hardware. (this would of course need to be
> phrased a bit better, but you get the idea).

Not possible, non-free is not enabled by default. Suggests/Recommends:
would be technically feasible though.

William


signature.asc
Description: This is a digitally signed message part

Re: [DRAFT] resolving DFSG violations

[William Pitcock]

On Wed, 2008-10-29 at 22:52 -0700, Thomas Bushnell BSG wrote:
> But regardless, Debian has promised that Debian is only free software.

Then why does Debian have non-free? Is that not part of Debian?

Does this mean that non-free should move to a third-party repo like
certain other repos out there containing controversial things?

If non-free is meant to be an opt-in part of Debian, then put the
distributable firmware there and be done with it.

William


signature.asc
Description: This is a digitally signed message part

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

[William Pitcock]

On Wed, 2008-10-22 at 09:03 +1100, Ben Finney wrote:
> William Pitcock <[EMAIL PROTECTED]> writes:
> 
> > Unfortunately, those who contribute to Debian must be dedicated to
> > ensuring future releases of Debian support the latest available
> > hardware at time of release.
> 
> That's news to me. Where is such a dedication required? Is it some
> special reading of the vague “our users” commitment, or do you get
> this dedication from all Debian contributors some other way?
> 
> Does that dedication somehow override every DD's explicit commitment
> to ensuring Debian is 100% DFSG-free in the Social Contract?

I worded that rather badly. You should imply "within acceptable terms of
the DFSG" here... in this case, putting stuff in the nonfree firmware
package in non-free is an acceptable solution.

William



signature.asc
Description: This is a digitally signed message part

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

[William Pitcock]

On Tue, 2008-10-21 at 14:36 -0700, Thomas Bushnell BSG wrote:
> On Tue, 2008-10-21 at 16:27 -0500, William Pitcock wrote:
> > On Tue, 2008-10-21 at 14:20 -0700, Thomas Bushnell BSG wrote:
> > > On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote:
> > > > Would it be a good compromise between SCs #1, #3 and #4 if we made an
> > > > exhaustive list of non-free bits in main, and make it our goal that the
> > > > list gets smaller between each release and not to add anything to
> > > > that list?
> > > 
> > > I would be entirely happy with that.  But I have just been told by
> > > William Pitcock that apparently we are required somehow to support new
> > > hardware with non-free software too.  So it's not a decreasing list,
> > > it's an accordion list with no real commitment to the DFSG at all.
> > 
> > Do not put words into my mouth. I simply stated that user experience is
> > an important factor, and that if free drivers (*FREE*) which depend on
> > non-free firmware are available, and the firmware is inline, then it
> > should not block Lenny's release.
> 
> Huh?  So you would be willing to agree to a rule that we never add
> anything new to the list of non-free bits?  

In the kernel itself, yes. Provided that:

  * the kernel framework for loading firmware is used for drivers
depending on non-free firmware, and
  * that firmware is available in non-free via firmware-nonfree

Infact, once I have time, I intend to start pushing patches upstream to
make this happen.

But this is going to take another kernel release cycle... if we intend
to release Lenny with 2.6.26, than this is not an option.

For hardware where this is an unacceptable solution, rewriting the
driver to not use the firmware may still be possible.

William


signature.asc
Description: This is a digitally signed message part

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

[William Pitcock]

On Tue, 2008-10-21 at 14:20 -0700, Thomas Bushnell BSG wrote:
> On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote:
> > Would it be a good compromise between SCs #1, #3 and #4 if we made an
> > exhaustive list of non-free bits in main, and make it our goal that the
> > list gets smaller between each release and not to add anything to
> > that list?
> 
> I would be entirely happy with that.  But I have just been told by
> William Pitcock that apparently we are required somehow to support new
> hardware with non-free software too.  So it's not a decreasing list,
> it's an accordion list with no real commitment to the DFSG at all.

Do not put words into my mouth. I simply stated that user experience is
an important factor, and that if free drivers (*FREE*) which depend on
non-free firmware are available, and the firmware is inline, then it
should not block Lenny's release.

William



signature.asc
Description: This is a digitally signed message part

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

[William Pitcock]

On Tue, 2008-10-21 at 13:30 -0700, Thomas Bushnell BSG wrote:
> On Tue, 2008-10-21 at 14:59 -0500, William Pitcock wrote:
> > If we waited for a release to be 100% perfect, it will likely take
> > several more years. The good news is that the amount of inline firmware
> > in the kernel is decreasing. So, eventually, all non-DFSG
> > redistributable firmware can belong in firmware-nonfree.
> 
> Do we have an ironclad commitment to not add any additional non-DFSG
> firmware, period, no matter what?  I would accept a compromise which
> guaranteed an increasing slope.  But not a back-and-forth thing.  Your
> reply focuses on regression issues, so is that really sufficient?  We
> guarantee that, say, there will always be *less* non-DFSG firmware in
> each release, and we guarantee that there will never be *new* non-DFSG
> firmware.

Unfortunately, those who contribute to Debian must be dedicated to
ensuring future releases of Debian support the latest available hardware
at time of release. 

If those drivers require firmware, then we can work to ensure that they
use the kernel's firmware loading framework. This is a cause that is a
good idea for many practical reasons excluding ensuring the firmware is
segregated to firmware-nonfree.

However, not supporting the latest 3ware RAID card due to non-free
firmware, as an example, would be unacceptable, considering Debian's
strong foundation in being run on servers.

Likewise, failing to support the latest 3D hardware or audio hardware
when DFSG-free drivers are available, but depend on non-DFSG firmware,
will lose Debian users on desktop hardware as well.

That said, Debian release cycles are fairly long, so there's time to
make sure things are implemented right in the future.

> 
> > If the NMU involves removing support for hardware, then no, the NMU's
> > solution would be in my opinion unacceptable, and hopefully enough
> > people agree that it would be rejected.
> 
> Thought so.  So the claim that "nobody is standing in the way" was
> simply false.  People are standing in the way of a simple fix for a
> simple bug, and insisting on a more complex fix.  I agree completely
> that the more complex fix is better, but it is simply not true that
> nobody is standing in the way of a fix.  Rather, they have declared that
> only one sort of fix is tolerable, and mostly refused to discuss the
> question.

People are not standing in your way as long as it does not cause
regressions or break support for current hardware that people may wish
to use.

William


signature.asc
Description: This is a digitally signed message part

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

[William Pitcock]

On Tue, 2008-10-21 at 10:38 -0700, Thomas Bushnell BSG wrote:
> On Tue, 2008-10-21 at 15:22 +, Anthony Towns wrote:
> > Thomas: your continued inaction and unwillingness to code an acceptable
> > solution to this issue, in spite of being aware of the problem since
> > at least 2004 -- over four years ago! -- means we will continue to do
> > releases with non-free software.
> 
> I am *happy* to code an acceptable solution, but I regard "not support
> the hardware for installation" as acceptable.  

Luckily very few others do.

Failing to support anything that was infact, supported by Etch, that
isn't absolutely positively ancient, is a regression.

> 
> I ask simply that the project's standards be *applied*, or that at the
> very least, we have a resolution as we did before.  And yes, I would
> likely vote against it, as I did before.  But in a democratic system,
> people generally are well advised to accept the result of past votes
> gracefully and work towards the next one.  That's what I did; my vote
> did not carry the day last time, and I have not objected about that
> decision since.  But I *do* object to the apparent new rule that the
> ftpmasters and release engineers are now empowered to ignore DFSG
> violations without any review by anyone else.
> 
> And now we have people saying, "hey, let's exempt firmware from the
> DFSG!" again, even though we have a GR on topic which decided that, no,
> firmware counts.

Shipping Lenny within a reasonable timeframe is more important than
firmware. If the release managers feel that firmware bugs should be
tagged lenny-ignore, than it is because they feel that fixing these bugs
would likely delay the Lenny release too long. Note that Debian is
already distributing this stuff in sid, so why give Lenny special
treatment?

If we waited for a release to be 100% perfect, it will likely take
several more years. The good news is that the amount of inline firmware
in the kernel is decreasing. So, eventually, all non-DFSG
redistributable firmware can belong in firmware-nonfree.

But that goal will simply not be realized before Lenny is released, if
we intend to ship Lenny anytime soon.

> 
> > "Hey, you've had four years; we're just going to keep releasing until
> > you fix the bug."
> > 
> > Hint: you're not being held hostage by anyone, seriously. You know how
> > you can tell? Two words: Stockholm syndrome.
> 
> So I can upload an NMU right now that fixes the problem?  That will be
> ok?

If the NMU involves removing support for hardware, then no, the NMU's
solution would be in my opinion unacceptable, and hopefully enough
people agree that it would be rejected.

The correct solution here would be to work with the kernel team and
derive a list of acceptable goals that still result in Lenny being
shipped in a reasonable timeframe.

William


signature.asc
Description: This is a digitally signed message part

Bug#500525: ITP: dronebl-tools -- tools for accessing the DroneBL rpc2 webservice

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock <[EMAIL PROTECTED]>

* Package name: dronebl-tools
  Version : 0.3
  Upstream Author : William Pitcock <[EMAIL PROTECTED]>
* URL : http://dronebl.org/doc/dronebl-tools
* License : BSD
  Programming Lang: Python
  Description : tools for accessing the DroneBL rpc2 webservice
 This package contains tools and a python module for interaction with
 the DroneBL rpc2 webservice, as well as other webservices which implement
 the same protocol. The commandline tools can be used in combination with
 fail2ban to submit bruteforce attackers to DroneBL and other blacklists.
 .
 The python module can be used to integrate DroneBL and other blacklists
 with other applications.
 .
 Please note that an RPCKEY is needed in order to access webservices
 implementing this protocol. 

-- System Information:
Debian Release: lenny/sid
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: Bug#497056: lsb-base: /lib/lsb/init-functions NON-DSFG Licence ?

[William Pitcock]

Hi,

On Fri, 2008-08-29 at 18:30 +0300, root wrote:
> Package: lsb-base
> Version: 3.2-19
> Severity: serious
> Justification: Policy 2.1
> 
> 
> Please investigate if files included in lsb-base conform to DFSG. A lincense
> change to GPL would be better suited for Debian.
> 
> Policy / 2.1. The Debian Free Software Guidelines:
> 
>  ...
>  Derived Works
>   The license must allow modifications and derived works, and must
>   allow them to be distributed under the same terms as the license
>   of the original software.
> 
>  Integrity of The Author's Source Code
>   The license may restrict source-code from being distributed in
>   modified form _only_ if the license allows the distribution of
>   "patch files" with the source code for the purpose of modifying
>   the program at build time.  The license must explicitly permit
>   distribution of software built from modified source code.  The
>   license may require derived works to carry a different name or
>   version number from the original software.  (This is a
>   compromise.  The Debian Project encourages all authors to not
>   restrict any files, source or binary, from being modified.)
> 
> File and Licence in question
> -
> 
> # /lib/lsb/init-functions for Debian -*- shell-script -*-
> #
> #Copyright (c) 2002-08 Chris Lawrence
> #All rights reserved.
> #
> #Redistribution and use in source and binary forms, with or without
> #modification, are permitted provided that the following conditions
> #are met:

This is DFSG-free, and meets both requirements.

> #1. Redistributions of source code must retain the above copyright
> #   notice, this list of conditions and the following disclaimer.

This is also DFSG-free, and meets both requirements.

> #2. Redistributions in binary form must reproduce the above copyright
> #   notice, this list of conditions and the following disclaimer in the
> #   documentation and/or other materials provided with the distribution.

This is also DFSG-free, and meets both requirements.

> #3. Neither the name of the author nor the names of other contributors
> #   may be used to endorse or promote products derived from this software
> #   without specific prior written permission.

This is also DFSG-free, and meets both requirements.

> #
> #THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
> #IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> #WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> #ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE
> #LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> #CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> #SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> #BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> #WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
> #OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> #EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

This is also DFSG-free, and meets both requirements.

The DFSG does not mean GPL. Provided all requirements of the DFSG are
met, then the work is DFSG free. If you do not understand this, e.g.
clearly you don't if you propose moving to GPL, then please do not
report such bugs.

William


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

Re: Is it a "user error" to use lilo?

[William Pitcock]

On Wed, 2008-08-27 at 16:53 +0200, Bjørn Mork wrote:
> William Pitcock <[EMAIL PROTECTED]> writes:
> 
> > If you have both GRUB and LILO installed, there will be problems. That
> > is infact, a bug. They should Conflict with each other to ensure that
> > only one can be installed at a time, but it is a minor bug at best, as
> > any smart user would not have both bootloaders installed. And infact,
> > any typical user would not install a second bootloader.
> 
> Well, since I'm obviously not a smart user I can continue to ask the
> stupid questions :-)
> 
> What is the recommended procedure for changing from e.g. lilo to grub?
> Since you plan to drop lilo post-lenny, I guess this will be a quite
> common question during the lifetime of lenny.  Users will notice that
> lilo is being deprecated and wonder how to switch. Maybe something to
> document in either lilo or grub? or both.

For lilo's particular usecases, we would probably be proposing (extlinux
| grub | grub2-pc) as an alternative.

As for migration, I am not sure yet. It will be something that will have
to be decided post-lenny, as well as lilo's fate. Lilo's codebase is
mostly unmaintainable.

William



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

Re: Is it a "user error" to use lilo?

[William Pitcock]

Hi,

On Wed, 2008-08-27 at 15:41 +0200, Jonas Smedegaard wrote:
> 
> Harrasing LILO users by silencing bugreports about problems[2] using
> it 
> is the wrong approach.  If LILO is officially unsupported by Debian
> (not 
> only by kernel team and/or initramfs-tools maintainer) we should drop 
> that package from the archive!

I am LILO's maintainer. It is hardly unsupported, infact it is supported
better now than it has been in a long time. While I do plan to drop it
post-lenny, it will certaintly be supported for lenny's release
lifecycle.

The initramfs-tools maintainer does not support any bootloader. It is
not their place to support any bootloaders.

I think it is absurd that you claim you are being silenced when you are
not.

If you have both GRUB and LILO installed, there will be problems. That
is infact, a bug. They should Conflict with each other to ensure that
only one can be installed at a time, but it is a minor bug at best, as
any smart user would not have both bootloaders installed. And infact,
any typical user would not install a second bootloader.

William


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

Re: Is it a "user error" to use lilo?

[William Pitcock]

Hi,

Using latest initramfs-tools with lilo works for me, provided that the
new large-memory feature is enabled.

As maks says, user error applies here.

William

On Wed, 2008-08-27 at 12:43 +0200, Jonas Smedegaard wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi fellow developers,
> 
> Please someone help look at bug#494422.
> 
> What is wrong with my judgement[1]?
> 
> 
> It seems to me that bug#494422 origins as the fix for bug#356850[2]
> 
> Generally I am worried about initramfs-tools being so invasive (see 
> bug#494422 - especially Max seemingly recommending[3] to reinstall from 
> time to time - slowly upgrading is not expected to work).
> 
> 
> Please cc me on replies - I am not subscribed to -devel.
> 
>   - Jonas
> 
> 
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494422#50
> [2] bug#http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356850
> [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=385949#29
> 
> - -- 
> * Jonas Smedegaard - idealist og Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
>   [x] quote me freely  [ ] ask before reusing  [ ] keep private
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> 
> iEYEARECAAYFAki1L74ACgkQn7DbMsAkQLjjgQCeKVQ4n8yHVnt9AfTV6L8sLw/C
> aZsAn0zrptW5TCEuZUF1FOmvwRG7ptUo
> =1m91
> -END PGP SIGNATURE-
> 
> 


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

Re: Remove libflash

[William Pitcock]

I think it's time for libflash to go, yes.

William

On Sat, 2008-08-23 at 22:13 +0900, Nobuhiro Iwamatsu wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi, All.
> 
> I am maintainer of libflash[0] pakcage. 
> 
> This package is very old. and only an old Flash version is supported.
> And, this has a lot of problems. 
>  
> Only this package supported the reproduction of Flash by a browser before. 
> However, there is grate free software such as swfdec[1] and gnash[2] and 
> other, 
> and new Flash is supported now. 
> 
> Then, I think to delete this package from Debian. 
> I get an opinion from other developers[3], but think that I want the opinion 
> from 
> the user/developper that is interested in this package. 
> 
> I think that I will give the deletion request of this package from Debian 
> if there is not an opinion. 
> 
> Best regards,
>  Nobuhiro
> 
> [0]:http://packages.qa.debian.org/libf/libflash.html
> [1]:http://packages.debian.org/source/sid/swfdec0.6
> [2]:http://packages.qa.debian.org/g/gnash.html
> [3]:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+495040
> - -- 
> Nobuhiro Iwamatsu
>   [EMAIL PROTECTED]
>   [EMAIL PROTECTED]
> 
>   GPG ID : 3170EBE9
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> 
> iEYEARECAAYFAkiwDQYACgkQQSHHQzFw6+meuQCgqaBvF3trdqlnXXtSv7V6Z74a
> UnUAoJnkn3ryYe2LjSoho1ABrIDsL4xj
> =GScE
> -END PGP SIGNATURE-
> 
> 


signature.asc
Description: This is a digitally signed message part

Bug#495736: ITP: instantbird -- instant messaging client based on XULrunner and libpurple

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock <[EMAIL PROTECTED]>

* Package name: instantbird
  Version : 0.1.2
  Upstream Author : Florian Quèze and Quentin Castier
* URL : http://www.instantbird.com/
* License : GPL
  Programming Lang: C, C++
  Description : instant messaging client based on XULrunner and libpurple
 Instantbird is an IM client based on Mozilla's XULrunner (the same
 platform that Iceweasel is based on). It supports connecting to all
 of the popular IRC networks through the use of libpurple, Pidgin's
 messaging core.
 .
 It supports all of the usual IM networks, like AIM, MSN, Jabber and so on.

-- System Information:
Debian Release: lenny/sid
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#492215: ITP: sigx -- interthread communication library for c++ on top of libsigc++ and glibmm

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock <[EMAIL PROTECTED]>

* Package name: sigx
  Version : 2.0
  Upstream Author : Klaus Triendl <[EMAIL PROTECTED]>
* URL : http://www.assembla.com/spaces/sigx
* License : LGPL-2.1 or later
  Programming Lang: C++
  Description : interthread communication library for c++ using libsigc++ 
and glibmm
 Sigx is an interthread communications library for sending messages between
 multiple threads. It extends libsigc++ and glibmm by adding "dispatchable"
 and "threadable" classes, and has bindings for glibmm to enable it's usage
 in Gtkmm/Glibmm applications.

Due to the in progress development of this library, it will be uploaded to 
Debian
experimental until the API is frozen.

-- System Information:
Debian Release: lenny/sid
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: Good communication with upstream is good idea

[William Pitcock]

On Mon, 2008-07-21 at 09:38 -0700, John H. Robinson, IV wrote:
> Steve Langasek wrote:
> > 
> > Launchpad can already be used as an openid /provider/ today, but I haven't
> > heard anything to indicate it will allow logins via other openid providers;
> > is more information available about this somewhere?
> > 
> > And even if LP accepted other openid providers, one would still have to log
> > in to LP the first time in order to configure which openid provider to use,
> > which I guess is still going to be more effort than some are interested in
> > doing. :)
> 
> What is the problem with closing the Debian bugs in the Debian
> changelog, and letting the Ubuntu MOTU (I hope I am using the right
> terminology here) handle the Ubuntu bug tracking?

There is none.

> 
> I am speaking from the standpoint of a Debian Developer that is not
> affiliated with Ubuntu. If a Developer is handling both the Debian and
> Ubuntu packaging, then they can do as they feel best.
> 
> I know that I test the Debian bugs prior to closing. I don't test Ubuntu
> builds - so I wold find it very presumptuous to close an Ubuntu bug.

There are situations where you would know that the bug is fixed on both
builds, e.g. if it's just an outright bug in the source and not a
Debian-specific problem. In those cases, if you wish to, you can use
(LP: ###) to close out the bugs just like you close out Debian bugs.

You're not required to do that, but if you want to be helpful to them,
then it's an option you have available.

There are clear advantages to doing it, such as that it helps improve
the Debian distribution ecosystem. As Ubuntu is the largest derivitive,
to some extent, monitoring the buglist for your packages there helps to
improve your own QA efforts on the packaging.

William


signature.asc
Description: This is a digitally signed message part

Re: FHS and /var/www

[William Pitcock]

Hi,

On Mon, 2008-07-21 at 13:26 +0200, Gabor Gombas wrote:
> On Mon, Jul 21, 2008 at 02:55:25AM +0100, Stephen Gran wrote:
> 
> > Yes.  My webservers tend to use something like
> > /srv/www//{config,cgi-bin,htdocs,lib,logs,blah,blah}/ as the
> > normal layout.  Exposing /srv/www as a document root would give access to
> > lots of things that are not public in many cases - we tend to not bother
> > with .htaccess files since config/ and so on are not under the webroot.
> 
> You're not alone with such a setup. /srv is becoming popular exactly
> because it does not conflict with the OS.
> 
> Quoting the FHS:
> 
>   "This main purpose of specifying this is so that _users_ may
>   find the location of the data files for particular service, ..."
> 
> Note how it only talks about users, not the operating
> system/distribution.
> 
> Gabor

I would say that the redhat default of /srv/www/localhost/htdocs might
be a good option.

William


signature.asc
Description: This is a digitally signed message part

Re: Good communication with upstream is good idea

[William Pitcock]

Hi,

On Mon, 2008-07-21 at 11:45 +0900, Charles Plessy wrote:
> Le Sun, Jul 20, 2008 at 01:43:13PM -0700, Steve Langasek a écrit :
> > 
> > You can close Launchpad bugs in Ubuntu packages from Debian.  The "LP: 
> > ##"
> > syntax lets bugs get autoclosed when your package is synced to Debian, or
> > when it's merged by an Ubuntu developer.
> 
> Interesting...
> 
> Does it work exactly like for the Debian BTS: i.e. it must be part of
> the .changes files? I ask the question because for the primer3 package,
> a Ubuntu user contacted Upstream for LP:191053, Upstream released a new
> version that I packaged, but the Ubuntu user did not close the Launchpad
> bug. In the next Debian upload, I can add a LP: 191053 tag in the
> changelog, but if it is not associated with the upload that actually
> corrected the bug it will be messy. If I add it deeper in the Debian
> changelog, will it do its magic?

It has to be in the .changes file. It works exactly like DAK's behaviour
for bug closing.

William



signature.asc
Description: This is a digitally signed message part

Re: RFC: libprojectM, new upstream version.

[William Pitcock]

On Thu, 2008-07-17 at 19:18 +0200, Francesco Namuri wrote:
> Il giorno mer, 16/07/2008 alle 17.46 -0500, William Pitcock ha scritto:
> > Hi,
> > 
> > On Wed, 2008-07-16 at 22:59 +0200, Francesco Namuri wrote:
> > > Hi,
> > > I've packaged the new version of this library, the upstream author has
> > > changed the SONAME, and so I've changed the name of the lib and -data
> > > package, not changed the name of the -dev file because the old
> > > maintainer has chosen to not version the package.
> > > 
> > > This is my first library package, and I've some doubts, is for this that
> > > I'm asking for RFC...
> > > 
> > > Is it correct to replace the old library? This can cause some breakage
> > > with old linked binaries (if any, I've seen that no package depends on
> > > this library)...
> > 
> > audacious-plugins
> > libvisual-projectm
> > 
> > You will have to at least update audacious-plugins to work before doing
> > this.
> 
> audacious-plugins is already compatible with the new version of
> libprojectM... I've looked at the logs of buildd of audacious-plugins
> and the projectM plugin isn't build from version 1.4.5-1, so the update
> of libprojectM don't break anything, indeed I tried to compile with
> libprojectM 1.2 and it builds also the projectM plugin... So I'm going
> to package the new library version...

Then you cause a feature regression. *great*.

> 
> > > about the change of SONAME by the upstream author, is it correct to
> > > change the SONAME if the library is compatible with the old one?
> > 
> > The library isn't compatible. Upstream breaks the API with every
> > release, so I gave up on them.
> 
> Best regards,
> francesco


signature.asc
Description: This is a digitally signed message part

Bug#491139: ITP: audacious2-plugins -- required and optional plugins for Audacious2

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock <[EMAIL PROTECTED]>

* Package name: audacious2-plugins
  Version : 1.9.0+hg20080717
  Upstream Author : William Pitcock <[EMAIL PROTECTED]>,
Tony Vroon <[EMAIL PROTECTED]>,
Matti Hamalainen <[EMAIL PROTECTED]>,
Tomasz Mon <[EMAIL PROTECTED]>,
Michael Farber <[EMAIL PROTECTED]>
* URL : http://audacious-media-player.org/index.php?title=Audacious2
* License : GPL  
  Programming Lang: C 
  Description : required and optional plugins for Audacious2
 Audacious2 is a cross platform player which supports multiple interfaces
 through an abstraction layer. It is the spiritual successor to Audacious, 
 but is a new codebase with most of the XMMS legacy removed.
 .
 It supports all of the formats Audacious does, with additional features   
 and also new formats like PSF2.
 .
 This package contains the plugins required for Audacious2 to operate.
 .
 This package is still experimental, and shouldn't be used yet.

For now, this package will conflict with audacious-plugins, and be uploaded to
experimental. As audacious2 development progresses, it will be possible
to install audacious and audacious2 side-by-side.

-- System Information:
Debian Release: lenny/sid
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#491138: ITP: audacious2 -- cross-platform multi-interface audio player

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock <[EMAIL PROTECTED]>

* Package name: audacious2
  Version : 1.9.0+hg20080717
  Upstream Author : William Pitcock <[EMAIL PROTECTED]>,
Tony Vroon <[EMAIL PROTECTED]>,
Matti Hamalainen <[EMAIL PROTECTED]>,
Tomasz Mon <[EMAIL PROTECTED]>,
Michael Farber <[EMAIL PROTECTED]>
* URL : http://audacious-media-player.org/index.php?title=Audacious2
* License : GPL
  Programming Lang: C
  Description : cross-platform multi-interface audio player
 Audacious2 is a cross platform player which supports multiple interfaces
 through an abstraction layer. It is the spiritual successor to Audacious,
 but is a new codebase with most of the XMMS legacy removed.
 .
 It supports all of the formats Audacious does, with additional features
 and also new formats like PSF2.
 .
 This package is still experimental, and shouldn't be used yet.

For now, this package will conflict with audacious1, and be uploaded to
experimental. As audacious2 development progresses, it will be possible
to install audacious1 and audacious2 side-by-side.

-- System Information:
Debian Release: lenny/sid
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: RFC: libprojectM, new upstream version.

[William Pitcock]

On Thu, 2008-07-17 at 00:57 +0200, Francesco Namuri wrote:
> Il giorno mer, 16/07/2008 alle 17.46 -0500, William Pitcock ha scritto:
> > Hi,
> > 
> > On Wed, 2008-07-16 at 22:59 +0200, Francesco Namuri wrote:
> > > Hi,
> > > I've packaged the new version of this library, the upstream author has
> > > changed the SONAME, and so I've changed the name of the lib and -data
> > > package, not changed the name of the -dev file because the old
> > > maintainer has chosen to not version the package.
> > > 
> > > This is my first library package, and I've some doubts, is for this that
> > > I'm asking for RFC...
> > > 
> > > Is it correct to replace the old library? This can cause some breakage
> > > with old linked binaries (if any, I've seen that no package depends on
> > > this library)...
> > 
> > audacious-plugins
> > libvisual-projectm
> > 
> > You will have to at least update audacious-plugins to work before doing
> > this.
> 
> ok,
> but about the name of the binary library package, is much correct to add
> the SONAME in the name of the package libprojectm2_1.2.0-1_i386.deb that
> replaces libprojectm1_1.01.0-1_i386.deb for example? or, considering
> that it is a small library a generic libprojectm_1.2.0-1_i386.deb?

Debian policy requires that it be named libprojectm2. Please be sure to
read the policy manual before continuing.

> 
> and to avoid breakage with audacious-plugins without updating
> audacious-plugins itself, can I, hypothetically, make libprojectm2 to be
> installable with libprojectm1?

Audacious-Plugins actual code will have to be ported to the new API. The
new API has incompatible changes. 

See the lines in my previous mail with ^'s below them, for a more
detailed explanation about the breakage trend in projectM.

>  
> > > about the change of SONAME by the upstream author, is it correct to
> > > change the SONAME if the library is compatible with the old one?
> > 
> > The library isn't compatible. Upstream breaks the API with every

> > release, so I gave up on them.
^^^

API breakage results in ABI breakage, which means the SONAME must be
changed, and *applications ported to the new API*.

At any rate, is there really any *point* in upgrading the library
anyway? The new versions do not introduce any new features that make the
effort worthwhile.

If you can't handle this, then please do not take the package, or at
least wait until after lenny is released to do so.

William


signature.asc
Description: This is a digitally signed message part

Re: RFC: libprojectM, new upstream version.

[William Pitcock]

Hi,

On Wed, 2008-07-16 at 22:59 +0200, Francesco Namuri wrote:
> Hi,
> I've packaged the new version of this library, the upstream author has
> changed the SONAME, and so I've changed the name of the lib and -data
> package, not changed the name of the -dev file because the old
> maintainer has chosen to not version the package.
> 
> This is my first library package, and I've some doubts, is for this that
> I'm asking for RFC...
> 
> Is it correct to replace the old library? This can cause some breakage
> with old linked binaries (if any, I've seen that no package depends on
> this library)...

audacious-plugins
libvisual-projectm

You will have to at least update audacious-plugins to work before doing
this.

> about the change of SONAME by the upstream author, is it correct to
> change the SONAME if the library is compatible with the old one?

The library isn't compatible. Upstream breaks the API with every
release, so I gave up on them.

William


signature.asc
Description: This is a digitally signed message part

Re: [Pkg-xen-devel] Xen status in lenny?

[William Pitcock]

On Wed, 2008-07-16 at 14:11 +0200, maximilian attems wrote:
> On Wed, Jul 16, 2008 at 07:11:06AM -0500, William Pitcock wrote:
> > 
> > Without dom0, lenny will be unusable for several installations of mine
> > which presently run an ugly combination of etch's dom0 and lenny's
> > kernel. I would like to do that in a different way.
> > 
> > If we will not see dom0 in linux-2.6 on Debian, we should at least have
> > a 2.6.18 tree with dom0.
> 
> no.
> we will not have 2 different linux-2.6 versions in Lenny.
> please think of the implications before throwing out suggestions.
> 

What about the implications of introducing feature regressions? The
patches to enable dom0 without pv-ops are available, yet they are
unwanted.

Wouldn't it be possible to build with both pv-ops and non-pv-ops for
dom0?

At any rate, please make it well documented where waldi's kernels are if
you intend to not have dom0 in 2.6.26.

William


signature.asc
Description: This is a digitally signed message part

Re: [Pkg-xen-devel] Xen status in lenny?

[William Pitcock]

On Wed, 2008-07-16 at 12:35 +0200, maximilian attems wrote:
> On Wed, Jul 16, 2008 at 12:51:21PM +0300, Pasi Kärkkäinen wrote:
> > On Wed, Jul 16, 2008 at 10:50:22AM +0200, maximilian attems wrote:
> > > On Wed, 16 Jul 2008, Ben Hutchings wrote:
> > > 
> > > > On Tue, Jul 15, 2008 at 05:22:55PM +0300, Pasi Kärkkäinen wrote:
> > > > 
> > > > > Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
> > > > > important Xen kernel features ported to pv_ops framework and 
> > > > > integrated 
> > > > > into vanilla linus kernels soon.. 
> > > > > 
> > > > > Status/todo:
> > > > > http://wiki.xensource.com/xenwiki/XenParavirtOps
> > > > > 
> > > > > Redhat/Fedora pv_ops Xen kernel dom0 support status:
> > > > > http://fedoraproject.org/wiki/Features/XenPvopsDom0
> > > > 
> > > > SLES 11 will include Linux 2.6.26 with Xen patches - packages should be
> > > > available any day now from
> > > > .  Is it
> > > > possible that those patches will be usable in lenny, as I believe the
> > > > kernel team expects to release with Linux 2.6.26?
> > > 
> > > dom0 looks currently out of reach,
> > > what we have is the snapshotting features of 2.6.27 for x86_32.
> > > 
> > 
> > Hmm.. what do you mean with "out of reach" ? pv_ops dom0 is not yet
> > ready/working, but those SLES 11 patches have the xensource (2.6.18 forward
> > port) of dom0 and all the other xen kernel features for 2.6.26.. 
> 
> sorry but no please read
> http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
> 
> pv_ops is the upstream way we enabled them in 2.6.25 and
> enhance the existing 2.6.26 base.
> what are you moaning?

Without dom0, lenny will be unusable for several installations of mine
which presently run an ugly combination of etch's dom0 and lenny's
kernel. I would like to do that in a different way.

If we will not see dom0 in linux-2.6 on Debian, we should at least have
a 2.6.18 tree with dom0.

William


signature.asc
Description: This is a digitally signed message part

Re: [Pkg-xen-devel] Xen status in lenny?

[William Pitcock]

Hi,

On Wed, 2008-07-16 at 11:42 +0300, Pasi Kärkkäinen wrote:
> 
> I guess it was faster _now_, but they'll have to live with the forward
> porting pain for years more now..

While this is true, the patches still allow for Debian to ship Lenny
without a feature regression in Xen support.

William


signature.asc
Description: This is a digitally signed message part

Re: [Pkg-xen-devel] Xen status in lenny?

[William Pitcock]

On Wed, 2008-07-16 at 11:12 +0300, Pasi Kärkkäinen wrote:
> On Wed, Jul 16, 2008 at 01:54:50AM +0100, Ben Hutchings wrote:
> > On Tue, Jul 15, 2008 at 05:22:55PM +0300, Pasi Kärkkäinen wrote:
> > 
> > > Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
> > > important Xen kernel features ported to pv_ops framework and integrated 
> > > into vanilla linus kernels soon.. 
> > > 
> > > Status/todo:
> > > http://wiki.xensource.com/xenwiki/XenParavirtOps
> > >
> 
> This xensource wiki page was just updated to contain up-to-date status,
> ie. features present in 2.6.26 and features submitted for 2.6.27.
> 
>  
> > > Redhat/Fedora pv_ops Xen kernel dom0 support status:
> > > http://fedoraproject.org/wiki/Features/XenPvopsDom0
> > 
> > SLES 11 will include Linux 2.6.26 with Xen patches - packages should be
> > available any day now from
> > .  Is it
> > possible that those patches will be usable in lenny, as I believe the
> > kernel team expects to release with Linux 2.6.26?
> > 
> 
> Interesting.. do you know if they have dom0 support etc included? based on
> pv_ops?

They include dom0 and are not based on paravirt_ops AFAIK.

William


signature.asc
Description: This is a digitally signed message part