Debian Installer team monthly meeting minutes (20050917 meeting)

[Christian Perrier]

(reply-to: debian-boot)

The minutes of the now monthly D-I (Debian Installer) team IRC meeting
are now available from the Debian Installer Meetings wiki page:

http://wiki.debian.net/?DebianInstallerMeetings

Minutes:
http://people.debian.org/~bubulle/d-i/irc-meeting-20050917/minutes

Log:
http://people.debian.org/~bubulle/d-i/irc-meeting-20050917/log

The next D-I meeting will be announced soon on debian-boot.


-- 



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

Re: Easy third-party package installer for debian-based distributions

[Wouter Verhelst]

On Mon, Sep 19, 2005 at 04:10:00AM +0200, Sami Dalouche wrote:
> Hi,
> 
> Sorry for being concerned with usability issues (hence average joe) while
> dealing with the way debian works. I guess that only ubuntu-devel was
> interested by this message then.

I'm not saying that.

What I'm saying is that I've seen many, many such scenarios that were
all based on how a hypothetical average joe is going to work with his
Debian-based computer, without actually checking things with reality
first. Unless you know an average joe who'll be interested in installing
a .deb by double-clicking on it, I don't think there's much value in
coming up with a solution for that 'problem'.

The way I see it, people who'll want to install third-party software
will either
* be competent enough to do it by themselves (and won't need nor use any
  graphical tools to help them),
* have an LSB package they want to install (hence, a framework for
  automatically adding lines to /etc/apt/sources.list is quite useless
  to them),
* have a tarball they need to unpack over their / filesystem (or in
  their /usr/local, or whatnot), or
* have a computer-savvy neighbour whom they'll ask to do it for them.

I don't think it's likely that there'll be many people who'll download a
.deb, feed it to the packaging system through some GUI, and expect it to
work; so IMO it's not worth the effort to create a framework that will
allow this. And even if it was, it's possible to make it possible to
install a .deb by using the tools already there, and just modifying
the relevant .desktop file.

> I am not claiming that synaptic is hard to use, (it can even be easier in some
> use cases), I am just claiming that adding a third party repository can be
> difficult for a newcomer, and my post was about trying to find an acceptable
> solution to this problem.

You've failed to do that, IMO.

Everything is difficult to newcomers. Always has been, always will be.
The correct way to help them out is not to hide away features inside
obscure binary files, hence adding more complexity for your users to
understand the bigger picture, but to make it easier for newcomers to
understand things.

> And yes, maybe third party are not competent enough to provide decent 
> packages.
> but if we don't even provide a framework they can build upon, they are never
> going to use it...
> 
> So, as a summary :
> - apt-get & dpkg solutions don't fulfill all the requirements :
> 
> 1) Does not subscribe to future updates
> 2) Does not allow the third party entity to provide several packages
> 
> - some people spoke about autopackage. I would be pleased to hear about some
> links detailing how autopackage plans to integrate with apt/dpkg.

autopackage is a bad idea:

* It overwrites files in your package management-managed system,
* It does not interact with the package manager to register and
  deregister packages

Hence, it's a very likely source of hard-to-trace bugs (becuase the
package foo you're using is differently compiled from the package dpkg
thinks is installed and from the package bar, which uses foo, expects to
find). Don't use it.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: Standardizing ~/.cache/ and similar things.

[Sylvain LE GALL]

Hello,

On Sun, Sep 18, 2005 at 07:43:43PM -0400, Faré wrote:
> Dear Debian developers,
> 
> here is a proposal I submit for inclusion in the debian policy:
> 
> PROPOSAL 1: ~/.cache/${package_name}/
> PROPOSAL 2: ~/.etc/${package_name}/
> PROPOSAL 3: ~/.run/ ~/.lib/ ~/.share, etc.
> 
> 

I like your idea. But i think that i think it should be better
to follow base-dir specification from freedesktop.org. It gives exactly
the same kind of dirname, but in a more standardized way.

Take a look at:
http://www.freedesktop.org/wiki/Standards_2fbasedir_2dspec

Kind regard
Sylvain Le Gall


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

Re: Debian 3.1 - avr-gnu tools compilation errors

[Oleg Figin]

On Saturday 17 September 2005 12:46, Andreas Fester wrote:
> Hi,
>
> what exactly are you trying to do? Note that the AVR tools are also
> in the debian archive, so unless you want to modify the sources
> a simple "aptitude install simulavr" should be sufficient.
>
> Otherwise, you should have a look at the Debian source package
> (apt-get source --download-only simulavr) which contains the
> original upstream sources and some patches in the .diff.gz file
> which are necessesary for the package to compile on Debian.
>
> Regards,
>
>   Andreas
>
> Oleg Figin wrote:
> > Hi,
> >
> > I work under Debian 3.1.
> > I've got compilation errors:
> >
> > 1. simulavr-0.1.2.2:
> > /usr/local/avr/simulavr-0.1.2.2/src/disp/disp.c
> > - error 'KEY-ENTER' undeclared etc. (multiple errors)
>
> [...]
>
> --
> Andreas Fester
> mailto:[EMAIL PROTECTED]
> WWW: http://www.littletux.net
> ICQ: 326674288

Hi Andreas,

many thanks for your hint. This seems to be a clue, because I did 'apt-get 
source an_avr_tool' but didn't figure out what .diff.gz.file was for.
I'll give a try and report you on results.

-- 
Best regards
Oleg


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

Re: hotplug blacklists

[Henrique de Moraes Holschuh]

On Sun, 18 Sep 2005, Marco d'Itri wrote:
> The new hotplug subsystem cannot handle blacklisting anymore, and now
> delegates it to modprobe.
> modprobe uses a different syntax, so the old /etc/hotplug/blacklist*
> files are not supported anymore.

What about user-installed blacklists?  Will the new packages at least try to
convert these from blacklist format to modprobe format?

Otherwise you are likely to cause severe headaches to a lot of people whose
system crashes when a given module (that hotplug likes) is loaded, etc.

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


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

Re: Managing users and groups within multiple devel chroots.

[Daniel Jacobowitz]

On Sun, Sep 18, 2005 at 11:52:09PM -0400, Daniel Jacobowitz wrote:
> Here's the code, hardcoded paths and all:
>   http://return.false.org/~drow/fuse/shadow-etc.c

Slightly better, but not much:
  http://return.false.org/~drow/fuse/

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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

Re: Easy third-party package installer for debian-based distributions

[Paul Wise]

Sami Dalouche wrote:

> Let's take, for example, Skype's example. It is not available in
> non-free/universe, but some people may still be interested in downloading it,

Once debian-unoffical.org supports Ubuntu, just get users to put
debian-unofficial.org in their /etc/apt/sources.list. They claim that
they will be importing Christian Marillat's mplayer/etc repository too
soon.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Managing users and groups within multiple devel chroots.

[Daniel Jacobowitz]

On Thu, Sep 15, 2005 at 06:29:12AM -0500, Peter Samuelson wrote:
> 
> [Ernestas V.]
> > Perhaps hard/symlinking original /etc/passwd, /etc/shadow and
> > /etc/group to chrooted environments would help?
> 
> Symlinks won't work.  Think about what a chroot environment *is*.
> 
> Hardlinks will only work if the programs that edit /etc/passwd and
> /etc/group overwrite them rather than copy / unlink.
> 
> Bind mounts will work
> (mount --bind /etc/passwd /mnt/sarge-chroot/etc/passwd)
> but apparently don't support locking all of a file's representations,
> so you would need to be careful not to run adduser in multiple chroots
> at once (like doing several dist-upgrades in parallel, or having users
> log in to different chroots and all try to change their passwords at
> once).

Ooh ooh, an excuse to share my new toy...

I was setting up a chroot a couple of weeks ago and wanted it to
reflect my system configuration.  So the first thing I tried were bind
mounts for shareable directories - /home, /tmp, /etc, et cetera.  There
are a couple of problems with this for /etc.  The biggest one, for me,
was that the chroot was i386 and the base system was amd64.  Which in
itself works fine, except it points out one of those files which can't
be shared in this way: ld.so.cache.  And if you bind mount a different
ld.so.cache on top of the bind mounted /chroot/etc, then you can no
longer rename /etc/ld.so.cache - this has to do with the way the Linux
VFS works, as I understand it.

So I took FUSE, and the included demo which proxies one filesystem to
another location.  And I hacked it to support bringing specific files
from other locations, based on name.  It's not the most robust thing in
the universe - FUSE is not "good enough" to share / this way, things
just won't work right.  By "good enough" I don't know whether the
limitations are in FUSE or in the nature of what I was trying to do,
though.  And don't try this on /proc or /dev.  But for /etc, it works
well enough for 32-bit firefox and OpenOffice.org.

I've got the feeling this could handle flock() locking correctly, but
doesn't - does FUSE even implement that?  Anyway it should be fine
for /etc/.pwd.lock.

Here's the code, hardcoded paths and all:
  http://return.false.org/~drow/fuse/shadow-etc.c

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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

Re: last change to save (adopt) some packages

[David Moreno Garza]

On Sun, 2005-09-18 at 18:24 -0400, Andres Salomon wrote:
> * libxml-ruby - Ruby interface to libxml
> * libxslt-ruby - Ruby interface to libxslt

These may be maintained by the pkg-ruby-extras team.

--
David Moreno Garza <[EMAIL PROTECTED]>   | http://www.damog.net/
   <[EMAIL PROTECTED]>  | GPG: C671257D
  Come to where the flavor is.


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

Re: Easy third-party package installer for debian-based distributions

[Benjamin Seidenberg]

Sami Dalouche <[EMAIL PROTECTED]> writes:

 


OK, may be an overkill.
   



 


But what happens with your solution if skype depends on libskype, which
is not available from debian's repository ?The user has to download
several .debs in order to install a single software ?
   



Skype should set up their own Debian repository and tell people to add it
to /etc/apt/sources.list.  It's not exactly hard.

 


Agreed. And if they HAVE to have some kind of one click installer, make
a small script.

#!/bin/sh
echo "http://whatever/path/to/repository"; >> /etc/apt/sources.list
apt-get install skype




signature.asc
Description: PGP signature


signature.asc
Description: OpenPGP digital signature

Re: Easy third-party package installer for debian-based distributions

[Russ Allbery]

Sami Dalouche <[EMAIL PROTECTED]> writes:

> OK, may be an overkill.

> But what happens with your solution if skype depends on libskype, which
> is not available from debian's repository ?The user has to download
> several .debs in order to install a single software ?

Skype should set up their own Debian repository and tell people to add it
to /etc/apt/sources.list.  It's not exactly hard.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Standardizing ~/.cache/ and similar things.

[Ron Johnson]

On Sun, 2005-09-18 at 19:07 -0700, Steve Langasek wrote:
> On Sun, Sep 18, 2005 at 08:21:21PM -0500, John Hasler wrote:
> > Faré wrote:
> > > PROPOSAL 3: ~/.run/ ~/.lib/ ~/.share, etc.
> > > Programs that insist to install stuff in the user's directory (such as
> > > openoffice, gimp, etc.), or that have runtime files (such as emacs'
> > > .saves-*) should put this stuff in a proper hierarchy that mirrors the
> > > categories of the FHS, only on a per-user basis. This will help
> > > administration of per-user installed stuff in the same way that the
> > > FHS helps with machine-global installed stuff.
> 
> > I like this idea.
> 
> I don't.  I don't think it has any business in policy when there are *no*
> packages doing this today.

I think it's a *great* FHS idea, but a *horrible* Debian idea.

If that makes any sense.

I'm glad that OP also sent the idea to the FHS/LSB people.

-- 
-
Ron Johnson, Jr.
Temporarily not of Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"... going to war without France is like going deer hunting
without an accordion. You just leave a lot of useless noisy
baggage behind."
Jed Babbin, former deputy undersecretary of defense in the first
Bush administration



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

Re: Easy third-party package installer for debian-based distributions

[Sami Dalouche]

Hi,

Sorry for being concerned with usability issues (hence average joe) while
dealing with the way debian works. I guess that only ubuntu-devel was
interested by this message then.

I am not claiming that synaptic is hard to use, (it can even be easier in some
use cases), I am just claiming that adding a third party repository can be
difficult for a newcomer, and my post was about trying to find an acceptable
solution to this problem.

And yes, maybe third party are not competent enough to provide decent packages.
but if we don't even provide a framework they can build upon, they are never
going to use it...

So, as a summary :
- apt-get & dpkg solutions don't fulfill all the requirements :

1) Does not subscribe to future updates
2) Does not allow the third party entity to provide several packages

- some people spoke about autopackage. I would be pleased to hear about some
links detailing how autopackage plans to integrate with apt/dpkg.

Regards,
Sami Dalouche


Quoting Wouter Verhelst <[EMAIL PROTECTED]>:

> (Side note: What's this obsession with Joe User everyone has? If there's
> something _you_ have a problem with when using Debian, shoot. Otherwise,
> synaptic is very easy to use -- even to Joe User).
>
> On Sun, Sep 18, 2005 at 11:22:30PM +0200, Sami Dalouche wrote:
> > OK, may be an overkill.
> > But what happens with your solution if skype depends on libskype, which is
> not
> > available from debian's repository ?The user has to download several .debs
> in
> > order to install a single software ?
>
> You consider proprietary software developers to be competent enough to
> understand how Debian is supposed to work, and then create and maintain
> policy-compliant packages for their users?
>
> Hah.
>
> If they provide packages at all, they'll give you one package you're
> supposed to install. If you're lucky, it may have dependencies via the
> shlibdeps system. That's about it.
>
> One improvement that I can see is that the double-click action you're
> talking about would also run 'apt-get -f install' after installing the
> proprietary .deb to automatically install any dependencies. That's about
> it; all the rest is overkill.
>
> --
> The amount of time between slipping on the peel and landing on the
> pavement is precisely one bananosecond
>
>





This message was sent using IMP, the Internet Messaging Program.


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

Re: Standardizing ~/.cache/ and similar things.

[Steve Langasek]

On Sun, Sep 18, 2005 at 08:21:21PM -0500, John Hasler wrote:
> Faré wrote:
> > PROPOSAL 3: ~/.run/ ~/.lib/ ~/.share, etc.
> > Programs that insist to install stuff in the user's directory (such as
> > openoffice, gimp, etc.), or that have runtime files (such as emacs'
> > .saves-*) should put this stuff in a proper hierarchy that mirrors the
> > categories of the FHS, only on a per-user basis. This will help
> > administration of per-user installed stuff in the same way that the
> > FHS helps with machine-global installed stuff.

> I like this idea.

I don't.  I don't think it has any business in policy when there are *no*
packages doing this today.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Standardizing ~/.cache/ and similar things.

[John Hasler]

Faré wrote:
> PROPOSAL 3: ~/.run/ ~/.lib/ ~/.share, etc.
> Programs that insist to install stuff in the user's directory (such as
> openoffice, gimp, etc.), or that have runtime files (such as emacs'
> .saves-*) should put this stuff in a proper hierarchy that mirrors the
> categories of the FHS, only on a per-user basis. This will help
> administration of per-user installed stuff in the same way that the
> FHS helps with machine-global installed stuff.

I like this idea.
-- 
John Hasler


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

Announcing an intention to produce an armeb port of Debian

[Debonaras Project Lead]

1/ Who are we?
 
The Debonaras project (http://www.debonaras.org) is a group of Linux
developers who have created the beginnings of a big-endian ARM (armeb)
port of Debian.  We have built 2500+ stable packages so far (see
http://ftp.debonaras.org).
 
Debonaras is targeted primarily at consumer devices (such as the Linksys
NSLU2 or Synology DS101) with large attached storage (e.g. the ability
to attach a USB hard disk).  The first target device is the Linksys
NSLU2, and we have had big-endian arm Debian running on that device (and
building armeb Debian packages) for about a month now.  We also have
big-endian arm Debian running on other armeb devices (including custom
hardware built by a member of the core team).
 
2/ What are our plans?
 
Our plan is to compile at least 95% of Debian for armeb, to produce an
armeb debian-installer port, to put in place a set of buildd machines
that can keep up with unstable, to have a number of our core team
members become Debian Developers (we have two applications waiting for
an AM to be assigned) and then gain enough Debian Developer support to
put forward a proposal for an official armeb Debian port (and then
officially rebuild all the packages).  In essence, we plan to meet the
requirements set out in
http://lists.debian.org/debian-devel-announce/2005/08/msg9.html and
then hope to be assimilated by Debian.
 
Most of the core Debonaras developers come from the NSLU2-Linux project
(http://www.nslu2-linux.org).
 
3/ What is the potential user base for an armeb port of Debian?
 
The NSLU2-Linux project has over 4300 subscribers on the mailing list,
attracts over 3 hits on the http://www.nslu2-linux.org website per
day, has provided over 12000 custom firmware downloads in the last three
months, and manages two package download systems (one for the
vendor-firmware-compatible 2.4 kernel custom firmware, and the other for
the OpenEmbedded-based 2.6 kernel custom firmware) which serve up
400GB/month of package downloads from four mirrors across the world). 
Every one of those 12000 custom firmware downloads is a potential user
of an armeb Debian port, just for the single NSLU2 device.
 
4/ Why do we want to port Debian to big-endian ARM?
 
The NSLU2 bootloader starts the kernel in big-endian mode, and the
on-board ethernet driver modules currently also run in big-endian mode. 
A number of our developers have other reasons (related to networking
performance of other ixp-based non-consumer devices) for requiring an
armeb port.
 
Note that there has already been success in targeting little-endian arm
Debian to the NSLU2, but it requires additional hardware (it currently
doesn't support the on-board ethernet port).
 
5/ How does this relate to Emdebian?
 
We are in contact with a number of Debian Developers from debian-arm,
and have discussed our plans with Wookey from Emdebian.  We believe that
Debonaras targets a different set of devices from Emdebian (Debonaras
intends to provide a full port of Debian targeting devices with large
attached storage).
 
6/ Why are we announcing this now?
 
We are not looking for publicity (please don't post this to slashdot). 
We do want to make the Debian developer community aware of what we are
doing.  We are looking for help from interested Debian Developers to get
a buildd system up and running and building the rest of the Debian
packages from source for armeb.
 
7/ How do I install Debian on my NSLU2 today?
 
See http://www.nslu2-linux.org/wiki/DebianSlug/OpenDebianSlug
 
8/ What does "Debonaras" stand for?
 
Debian On NAS And Routers And Stuff
 
-- Signed, the Debonaras and NSLU2-Linux core team. 


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

Re: Standardizing ~/.cache/ and similar things.

[Wesley J. Landaker]

On Sunday 18 September 2005 17:43, Faré wrote:
> Dear Debian developers,
>
> here is a proposal I submit for inclusion in the debian policy:
>
> PROPOSAL 1: ~/.cache/${package_name}/
> All packages that keep a per-user directories caches of data that need
> not be archived/backed up should put it in ~/.cache/${package_name}/
> instead of wherever they put it currently.

Given PROPOSAL 3 below, shouldn't this be ~/.var/cache or something like 
that?

> PROPOSAL 3: ~/.run/ ~/.lib/ ~/.share, etc.
> Programs that insist to install stuff in the user's directory (such as
> openoffice, gimp, etc.), or that have runtime files (such as emacs'
> .saves-*) should put this stuff in a proper hierarchy that mirrors the
> categories of the FHS, only on a per-user basis. This will help
> administration of per-user installed stuff in the same way that the
> FHS helps with machine-global installed stuff.

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


pgpjeitVu6BP0.pgp
Description: PGP signature

Bug#329033: ITP: webxml -- Simple form-based generator/editor of Tomcat's web.xml files

[Martin Ferrari]

Package: wnpp
Severity: wishlist
Owner: Martin Ferrari <[EMAIL PROTECTED]>


* Package name: webxml
  Version : 1.12-1
  Upstream Author : Boulgakov Andrei <[EMAIL PROTECTED]>
* URL : http://webxml.sourceforge.net/
* License : GPL
  Description : Simple form-based generator/editor of Tomcat's web.xml files

Webxml is a simple form-based generator/editor of Tomcat's web.xml files.
It supports the following tags:
, , , ,
, , , .
These tags are basic and most of them are indispensable for every Web
Application.

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


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

Re: Standardizing ~/.cache/ and similar things.

[Faré]

Dear Debian developers,

here is a proposal I submit for inclusion in the debian policy:

PROPOSAL 1: ~/.cache/${package_name}/
All packages that keep a per-user directories caches of data that need
not be archived/backed up should put it in ~/.cache/${package_name}/
instead of wherever they put it currently.

Rationale: KHTML, Mozilla, w3m, slime, etc., all use different
directories: ~/.kde/share/cache/, ~/.mozilla/$USER/$CODE/Cache/,
~/.w3m/, ~/.slime/, etc. When duplicating some user's settings (from
one machine to another, from one user to another, etc.), or when doing
a backup, this means a lot of useless data will be copied over, or
non-reliable ad-hoc exclusion lists must be devised. Putting things in
a well defined location will tremendously help system administrators,
while providing users with a well-defined interface for keeping things
in or out of backup: put things physically in or out of ~/.cache/, add
use symlinks to ensure proper access through logical paths.

Cost to users: the ~/.cache/ hierarchy is not used yet, so there is no
cost to user.

Cost to implementors: all packages that keep a cache must be modified.
A way to move the previous cache must be devised. Symlinks from
previous location might have to be provided for backwards
compatibility.

Note: this might (or not) also replace things like
/var/cache/$package/$user that have an intrinsic security problem if
some other user tries to hijack the cache before the user uses the
program.


PROPOSAL 2: ~/.etc/${package_name}/
All packages should put their configuration in ~/.etc/${package_name}/
instead of ~/.{weird_variation_on_package_name}. Moreover per-user
~/.etc/ hierarchy should be essentially the same as the /etc/
hierarchy, in terms of mapping configured functionality to filename.
Thus, no more ~/.zshrc. but instead ~/.etc/zsh/zshrc (or ~/.etc/zsh/rc
if they shorten the name).

Rationale: this solves the mess of files in ~/, which makes the
directory browsable once again, and allows for intelligible management
of what files should be kept for the purpose of which package, or what
can be safely deleted.

Cost to users: the transition period may involve some breakage, unless
symlinks are provided. Said symlinks are still cruft that will have to
be cleaned up later.

Cost to implementors: almost every package must be modified.


PROPOSAL 3: ~/.run/ ~/.lib/ ~/.share, etc.
Programs that insist to install stuff in the user's directory (such as
openoffice, gimp, etc.), or that have runtime files (such as emacs'
.saves-*) should put this stuff in a proper hierarchy that mirrors the
categories of the FHS, only on a per-user basis. This will help
administration of per-user installed stuff in the same way that the
FHS helps with machine-global installed stuff.

Cost to implementer: if we already to proposal 1 and 2, the
incremental cost is low. If things are properly designed, this could
actually simplify a bit of the cruft in existing programs, that do
things with random unrelated filenames, and will do thing with
uniformly chosen filenames instead.


NB: I've send a similar proposal to the FHS mailing-list. I'm trying
to get the message to as many free software developers and packagers
as I can. I have 280 files and directories that match .* in my home
directory, and hundreds of megabytes of cruft in there if I wanted to
duplicate it as is when creating an account on a new machine.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
They laughed at Columbus, they laughed at Fulton, they laughed at the
Wright brothers.  But they also laughed at Bozo the Clown.
-- Carl Sagan

Re: [libsmjs-dev]: Missing files

[Davi Leal]

Thanks for the feedback, the improved script, etc.

I will fill the bug report.
Davi



Darren Salt wrote:
> I demand that Davi Leal may or may not have written...
>
> > I am missing the "js.msg" and "jsopcode.tbl" files in the
> > "libdevel/libsmjs-dev" development library package.
> >
> > The files are in the mozilla-thunderbird-dev and mozilla-dev packages,
> > but not in the libsmjs-dev.

> (Assuming bash...)
>
>   # aptitude download mozilla-dev
>   # dpkg-deb -x mozilla-dev_1.7.8.1sarge2_i386.deb foo
>   # cp -a foo/usr/include/mozilla/js/js{.msg,opcode.tbl} /usr/include/smjs/
>   # rm -rf foo
>   # rm mozilla-dev_1.7.8.1sarge2_i386.deb
>
> Note that these files /may/ not be the same as those which you say should
> be in libsmjs-dev.
>
> > Could you include the files in the libsmjs-dev package?.
>
> See http://www.debian.org/Bugs/Reporting>.
>
> (FWIW, if your application is intended to be buildable on non-Debian
> systems, you need to be aware that /usr/lib/smjs may be known as
> /usr/lib/js. I got build failure reports about this when I deprecated
> gxine's internal copy.)


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

Re: last change to save (adopt) some packages

[Thomas Bushnell BSG]

Andres Salomon <[EMAIL PROTECTED]> writes:

> I have more than a few packages that I've been looking to get rid of for
> some time.  No one's taken them, so I'm going to request the ftp masters
> drop some of them if no one takes them within the few weeks.  

This is not the correct way to orphan a package.  The way to orphan a
package is to upload with the Maintainer set to Debian QA Group
<[EMAIL PROTECTED]>, and change the title of your wnpp bug to be
an "O" entry instead of "RFA".

Thomas


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

last change to save (adopt) some packages

[Andres Salomon]

Hi,

I have more than a few packages that I've been looking to get rid of for
some time.  No one's taken them, so I'm going to request the ftp masters
drop some of them if no one takes them within the few weeks.  These
packages are:

* messagewall - An SMTP proxy daemon, designed to help keep out unwanted
email

This package no longer has an upstream maintainer.  If you want it,
you'll probably need to become upstream as well.  Otherwise, I'll have
it dropped from the archive.

* firedns - an asynch. dns resolver library

This library is by the same author as messagewall, and is still
maintained; however, there haven't been any new releases in a while.
Messagewall depends upon it, as well as a few other things not in debian
(such as dsbl.org's tester program(s)).  It's actually a neat little
library, but with nothing else in Debian using it, there's not much
point in keep it in the archive.

* firestring - a string handling library

Again, this library is by the same author as messagewall, and is still
maintained.  Messagewall depends upon it, but nothing else in Debian
uses it.  I'm going to have it removed from the archive if no one wants
it.

* libxml-ruby - Ruby interface to libxml
* libxslt-ruby - Ruby interface to libxslt

These are fairly useful; however, afaict they are no longer maintained
upstream.  There is a fairly sordid history here; basically, the
original author (Sean Chittenden) stopped maintaining them around 2002
or 2003.  He licensed them under a BSD license (iirc).  In 2003,
Gregoire Lejeune started maintaining libxslt; however, he relicensed the
program under the GPL, and stripped off Sean's copyright information
(violating Sean's license); this is according to Sean, anyways.  At some
point in 2004/2005, someone named Trans Onoma imported them into the
xml-tools [1] repository, but he hasn't worked on them since 2004 or so.
I have no idea whether or not he intends to actively maintain them.

Sid still contains Sean's last releases, from 2002/2003.  I don't know
whether Gregoire's latest version even contains any of Sean's original
code; I no longer have a use for either of these packages, so I haven't
bothered to figure it out.  Whoever takes over these packages should
probably talk to the upstream (or ask on one of the ruby lists) to find
out which will actively be maintained.  Both licenses are problematic
for libraries as well, so maybe simply rewriting them from scratch under
the LGPL or 3-clause BSD would be the best way to go here.

Given the licensing pains and upstream squabbling, I'm going to remove
these from the archive if no one takes them.

* libhtml-tokenizer-ruby - simple HTML tokenizer/parser for Ruby

This is a really easy package, and still actively maintained [2]
upstream.  It's great for quickly parsing html; I used it in scripts to
interface the bitkeeper web interface, back when Linus used bitkeeper
(so that I didn't have to install the non-free bk client).  However, now
that Linus uses git, I don't have a use for this package.

I'll simply orphan this one, if no one takes it.

* par2 - Parity Archive Volume Set, for checking and repair of files

If you've ever downloaded those funny .par2 files off newgroups, this is
the tool you need to actually make use of them.  It's maintained
upstream (afaict), but hasn't had a new release in a while.  I'll orphan
this one as well, if no one takes it.


[1] http://rubyforge.org/projects/xml-tools/
[2] http://rubyforge.org/projects/htmltokenizer/

-- 
Andres Salomon <[EMAIL PROTECTED]>


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

Re: How can I build a package from source that require the source of another (library) package?

[Jaldhar H. Vyas]

On Sun, 18 Sep 2005, Christoph Hellwig wrote:


This is as wrong as doign that for kernel drivers?  What driver packages
do that?  Look like I need to file some bugs..



Um, I don't recall.  But IIRC we did in the past recommend people who 
needed private kernel headers not included in the kernel-headers package 
to just copy them into their own source packages.




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


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

Re: Easy third-party package installer for debian-based distributions

[Wouter Verhelst]

(Side note: What's this obsession with Joe User everyone has? If there's
something _you_ have a problem with when using Debian, shoot. Otherwise,
synaptic is very easy to use -- even to Joe User).

On Sun, Sep 18, 2005 at 11:22:30PM +0200, Sami Dalouche wrote:
> OK, may be an overkill.
> But what happens with your solution if skype depends on libskype, which is not
> available from debian's repository ?The user has to download several .debs in
> order to install a single software ?

You consider proprietary software developers to be competent enough to
understand how Debian is supposed to work, and then create and maintain
policy-compliant packages for their users?

Hah.

If they provide packages at all, they'll give you one package you're
supposed to install. If you're lucky, it may have dependencies via the
shlibdeps system. That's about it.

One improvement that I can see is that the double-click action you're
talking about would also run 'apt-get -f install' after installing the
proprietary .deb to automatically install any dependencies. That's about
it; all the rest is overkill.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: Easy third-party package installer for debian-based distributions

[Ante Karamatic]

On Sun, 2005-09-18 at 22:47 +0200, Sami Dalouche wrote:

> - Joe downloads a .mdeb (meta-deb) package on skype's website.

It would be easier to download deb, double-click it. App starts, makes a
copy of deb/moves deb to /var/lib/my-apt-repo, creates Packages.gz,
apt-get update, apt-get install program. In sources.list would allways
be "deb file://var/lib/my-apt-repo".

-- 
Ante Karamatic <[EMAIL PROTECTED]>


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

Re: Easy third-party package installer for debian-based distributions

[Sami Dalouche]

OK, may be an overkill.
But what happens with your solution if skype depends on libskype, which is not
available from debian's repository ?The user has to download several .debs in
order to install a single software ?

Sami Dalouche

Quoting Josselin Mouette <[EMAIL PROTECTED]>:

> Le dimanche 18 septembre 2005 à 22:47 +0200, Sami Dalouche a écrit :
> > Let's take, for example, Skype's example. It is not available in
> > non-free/universe , but some people may still be interested in downloading
> it,
> > be they linux experts or not. So what happens on a
> Debian/Ubuntu/MEPIS/whatever
> > box ? Average joe downloads the "Debian package" available on skype's
> website,
> > and clicks on it (I believe it is possible to install a deb by
> double-clicking
> > on it, right ?). Then, libqt is not installed, so it complains. End of the
> > game, "linux sucks, I can't even install skype on it".
> >
> > OK, joe should be taught to use apt-get, etc, but we are in the real world,
> so
> > it is not possible. What about the following scenario :
> >
> > - Joe downloads a .mdeb (meta-deb) package on skype's website.
> > - Joe double clicks on it, some progress bar appears
> > - Few seconds after, skype is installed, great !
>
> This is complete overkill. The only thing currently missing in your
> scenario is support in apt-get and synaptic for grabbing dependencies
> for a single binary package. E.g. "apt-get install foo.deb" or "synaptic
> foo.deb".
> --
>  .''`.   Josselin Mouette/\./\
> : :' :   [EMAIL PROTECTED]
> `. `'[EMAIL PROTECTED]
>   `-  Debian GNU/Linux -- The power of freedom
>





This message was sent using IMP, the Internet Messaging Program.


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

Re: Easy third-party package installer for debian-based distributions

[Trent Lloyd]

IMHO, the 'right' solution to do this is to have some file whcih describes
a normal apt archive and the package in it to install, and double clicking
it adds it to your apt sources, updates, and installs the package using apt,
then upgrades will be handled normally with update-notifier et al.

IIRC someone was working on this quite a while ago but I don't know what
happened, and of course, some people are concerned with the security of
this etc (altho I personally think its a good idea)

Trent

On Sun, Sep 18, 2005 at 10:47:24PM +0200, Sami Dalouche wrote:
> 
> Hi,
> 
> I'm crossposting between debian-devel and ubuntu-devel, but maybe some other
> debian-based distributions may be interested as well. Feel free to forward..
> 
> This email is about sharing some thoughts about installing third party 
> packages
> inside on a debian box..
> 
> Let's take, for example, Skype's example. It is not available in
> non-free/universe , but some people may still be interested in downloading it,
> be they linux experts or not. So what happens on a 
> Debian/Ubuntu/MEPIS/whatever
> box ? Average joe downloads the "Debian package" available on skype's website,
> and clicks on it (I believe it is possible to install a deb by double-clicking
> on it, right ?). Then, libqt is not installed, so it complains. End of the
> game, "linux sucks, I can't even install skype on it".
> 
> OK, joe should be taught to use apt-get, etc, but we are in the real world, so
> it is not possible. What about the following scenario :
> 
> - Joe downloads a .mdeb (meta-deb) package on skype's website.
> - Joe double clicks on it, some progress bar appears
> - Few seconds after, skype is installed, great !
> 
> Behind the scenes :
> - a .mdeb is just a script/ deb with post-install script, or whatever that
> allows to add apt-get's skype's sources.
> - Once the sources are installed, and apt-get update done, skype gets 
> installed,
> and apt-get takes care of the dependencies
> - apt-get will take care of upgrading when necessary.
> 
> It could also be envisionned that a .mdeb could be an archive, containing a
> apt-get repository, that is extracted to /var/apt/whatever. This repository
> could contain all the required dependencies (for example, a copy from debian's
> archive) that may or may not be available on some machines, and be used as an
> offline installation. So no more hell to install a software with many depends,
> and no helly static-linking. And if a better version of any depends is already
> avaialble, then it will be used by apt.
> 
> 
> OK, so several questions :
> - What do you think about this system, which would actually be a 1 or 2 hour
> hack, and be potentially very useful at helping people at installing packages 
> ?
> - What would be the hidden / additional requirements that I did not think of ?
> - If such hack was programmed, would Debian/Ubuntu/Others officially endorse
> this way of distributing packages ?
> 
> Regards,
> Sami Dalouche
> 
> 
> 
> This message was sent using IMP, the Internet Messaging Program.
> 
> --
> ubuntu-devel mailing list
> [EMAIL PROTECTED]
> http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
Trent Lloyd <[EMAIL PROTECTED]>
Bur.st Networking Inc.


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

Re: Easy third-party package installer for debian-based distributions

[Sami Dalouche]

Well, this "right" solution has 2 main problems :
- It needs some package to be installed on the box. This is workable, but
ubuntu/debian/others have to agree and install the necessary software to handle
this by default, otherwise it becomes useless.
- It doesn't handle offline installations.. Not sure whether it's a problem, but
 wouldn't it be handy for some people if we could just have one archive that
contains bunch of dependencies, ready to be installed ?

Quoting Trent Lloyd <[EMAIL PROTECTED]>:

> IMHO, the 'right' solution to do this is to have some file whcih describes
> a normal apt archive and the package in it to install, and double clicking
> it adds it to your apt sources, updates, and installs the package using apt,
> then upgrades will be handled normally with update-notifier et al.
>
> IIRC someone was working on this quite a while ago but I don't know what
> happened, and of course, some people are concerned with the security of
> this etc (altho I personally think its a good idea)
>
> Trent
>
> On Sun, Sep 18, 2005 at 10:47:24PM +0200, Sami Dalouche wrote:
> >
> > Hi,
> >
> > I'm crossposting between debian-devel and ubuntu-devel, but maybe some
> other
> > debian-based distributions may be interested as well. Feel free to
> forward..
> >
> > This email is about sharing some thoughts about installing third party
> packages
> > inside on a debian box..
> >
> > Let's take, for example, Skype's example. It is not available in
> > non-free/universe , but some people may still be interested in downloading
> it,
> > be they linux experts or not. So what happens on a
> Debian/Ubuntu/MEPIS/whatever
> > box ? Average joe downloads the "Debian package" available on skype's
> website,
> > and clicks on it (I believe it is possible to install a deb by
> double-clicking
> > on it, right ?). Then, libqt is not installed, so it complains. End of the
> > game, "linux sucks, I can't even install skype on it".
> >
> > OK, joe should be taught to use apt-get, etc, but we are in the real world,
> so
> > it is not possible. What about the following scenario :
> >
> > - Joe downloads a .mdeb (meta-deb) package on skype's website.
> > - Joe double clicks on it, some progress bar appears
> > - Few seconds after, skype is installed, great !
> >
> > Behind the scenes :
> > - a .mdeb is just a script/ deb with post-install script, or whatever that
> > allows to add apt-get's skype's sources.
> > - Once the sources are installed, and apt-get update done, skype gets
> installed,
> > and apt-get takes care of the dependencies
> > - apt-get will take care of upgrading when necessary.
> >
> > It could also be envisionned that a .mdeb could be an archive, containing a
> > apt-get repository, that is extracted to /var/apt/whatever. This repository
> > could contain all the required dependencies (for example, a copy from
> debian's
> > archive) that may or may not be available on some machines, and be used as
> an
> > offline installation. So no more hell to install a software with many
> depends,
> > and no helly static-linking. And if a better version of any depends is
> already
> > avaialble, then it will be used by apt.
> >
> >
> > OK, so several questions :
> > - What do you think about this system, which would actually be a 1 or 2
> hour
> > hack, and be potentially very useful at helping people at installing
> packages ?
> > - What would be the hidden / additional requirements that I did not think
> of ?
> > - If such hack was programmed, would Debian/Ubuntu/Others officially
> endorse
> > this way of distributing packages ?
> >
> > Regards,
> > Sami Dalouche
> >
> >
> > 
> > This message was sent using IMP, the Internet Messaging Program.
> >
> > --
> > ubuntu-devel mailing list
> > [EMAIL PROTECTED]
> > http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
> --
> Trent Lloyd <[EMAIL PROTECTED]>
> Bur.st Networking Inc.
>
> --
> ubuntu-devel mailing list
> [EMAIL PROTECTED]
> http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
>





This message was sent using IMP, the Internet Messaging Program.


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

Bug#329020: ITP: kleansweep -- Tool to reclaim disk space by finding unneeded files

[Moratti Claudio]

Package: wnpp
Severity: wishlist
Owner: Moratti Claudio <[EMAIL PROTECTED]>

* Package name: kleansweep
  Version : 0.1.6
  Upstream Author : Pawel Stolowski <[EMAIL PROTECTED]>
* URL : http://linux.bydg.org/~yogin/
* License : GPL
  Description : Tool to reclaim disk space by finding unneeded files


 KleanSweep allows to reclaim disk space by finding unneeded files.
 It can search for files basing on several criterias:
   * empty files
   * backup files
   * broken symbolic links
   * dead menu entries (.desktop files pointing to non-existing executables)
   * duplicated files
   * orphaned files (files not found in RPM database).

 Results for each criteria are shown in separate tab, files may appear on many
 tabs if they match many criterias - in this case they are "linked".

 Packages are available at:
 http://repos.knio.it/ (repository)


System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13-maxer-splash
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)


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

Re: Easy third-party package installer for debian-based distributions

[Josselin Mouette]

Le dimanche 18 septembre 2005 à 22:47 +0200, Sami Dalouche a écrit :
> Let's take, for example, Skype's example. It is not available in
> non-free/universe , but some people may still be interested in downloading it,
> be they linux experts or not. So what happens on a 
> Debian/Ubuntu/MEPIS/whatever
> box ? Average joe downloads the "Debian package" available on skype's website,
> and clicks on it (I believe it is possible to install a deb by double-clicking
> on it, right ?). Then, libqt is not installed, so it complains. End of the
> game, "linux sucks, I can't even install skype on it".
> 
> OK, joe should be taught to use apt-get, etc, but we are in the real world, so
> it is not possible. What about the following scenario :
> 
> - Joe downloads a .mdeb (meta-deb) package on skype's website.
> - Joe double clicks on it, some progress bar appears
> - Few seconds after, skype is installed, great !

This is complete overkill. The only thing currently missing in your
scenario is support in apt-get and synaptic for grabbing dependencies
for a single binary package. E.g. "apt-get install foo.deb" or "synaptic
foo.deb".
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Easy third-party package installer for debian-based distributions

[Sami Dalouche]

Hi,

I'm crossposting between debian-devel and ubuntu-devel, but maybe some other
debian-based distributions may be interested as well. Feel free to forward..

This email is about sharing some thoughts about installing third party packages
inside on a debian box..

Let's take, for example, Skype's example. It is not available in
non-free/universe , but some people may still be interested in downloading it,
be they linux experts or not. So what happens on a Debian/Ubuntu/MEPIS/whatever
box ? Average joe downloads the "Debian package" available on skype's website,
and clicks on it (I believe it is possible to install a deb by double-clicking
on it, right ?). Then, libqt is not installed, so it complains. End of the
game, "linux sucks, I can't even install skype on it".

OK, joe should be taught to use apt-get, etc, but we are in the real world, so
it is not possible. What about the following scenario :

- Joe downloads a .mdeb (meta-deb) package on skype's website.
- Joe double clicks on it, some progress bar appears
- Few seconds after, skype is installed, great !

Behind the scenes :
- a .mdeb is just a script/ deb with post-install script, or whatever that
allows to add apt-get's skype's sources.
- Once the sources are installed, and apt-get update done, skype gets installed,
and apt-get takes care of the dependencies
- apt-get will take care of upgrading when necessary.

It could also be envisionned that a .mdeb could be an archive, containing a
apt-get repository, that is extracted to /var/apt/whatever. This repository
could contain all the required dependencies (for example, a copy from debian's
archive) that may or may not be available on some machines, and be used as an
offline installation. So no more hell to install a software with many depends,
and no helly static-linking. And if a better version of any depends is already
avaialble, then it will be used by apt.


OK, so several questions :
- What do you think about this system, which would actually be a 1 or 2 hour
hack, and be potentially very useful at helping people at installing packages ?
- What would be the hidden / additional requirements that I did not think of ?
- If such hack was programmed, would Debian/Ubuntu/Others officially endorse
this way of distributing packages ?

Regards,
Sami Dalouche



This message was sent using IMP, the Internet Messaging Program.


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

Re: Debian Reference

[Javier Fernández-Sanguino Peña]

On Sun, Sep 18, 2005 at 04:20:32AM +0100, Antony Gelberg wrote:
> > Your observation is somewhat correct.  I think user oriented
> > distribution manual is collection of documents now.  See list on
> > http://www.debian.org/doc .
> 
> I am well aware of that URL, and it's not ideal.  Lots of things spread
> about and out of date.  And a Progeny manual to boot.  The best *cough*
> thing I found was the Debian Dictionary.  That needs removal.

What needs removal? The Dictionary or the manual? In an ycase, /doc/ is
probably sub-optimal as it is a list of available documentation in Debian,
what I believe you miss is something like "New to Debian?" that points people
to documentation they should read first, this includes: the installation
manual, the FAQ and the Debian Reference.

Maybe the support page (www.debian.org/support) should list these instead
of refering people to /doc/ directly. 

Of course, changing the doc index so that the obsolete or not up-to-date
documentation is removed (or marked as such) might help too.

Regards

Javier


signature.asc
Description: Digital signature

Bug#329004: ITP: cairo-ocaml -- OCaml bindings for the cairo library

[Samuel Mimram]

Package: wnpp
Severity: wishlist
Owner: Samuel Mimram <[EMAIL PROTECTED]>


* Package name: cairo-ocaml
  Version : CVS
  Upstream Author : Olivier Andrieu <[EMAIL PROTECTED]>
* URL : http://cairographics.org/cairo_2docaml
* License : LGPL
  Description : OCaml bindings for the cairo library

 Cairo is a multi-platform library providing anti-aliased
 vector-based rendering for multiple target backends. Paths consist
 of line segments and cubic splines and can be rendered at any width
 with various join and cap styles. All colors may be specified with
 optional translucence (opacity/alpha) and combined using the
 extended Porter/Duff compositing algebra as found in the X Render
 Extension.
 .
 Cairo exports a stateful rendering API similar in spirit to the path
 construction, text, and painting operators of PostScript, (with the
 significant addition of translucence in the imaging model). When
 complete, the API is intended to support the complete imaging model of
 PDF 1.4.
 .
 This package will contain the libraries needed to use cairo in OCaml
 programs.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Bug#329006: ITP: newton -- A desktop wiki applet for Gnome

[David Watson]

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


* Package name: newton
  Version : 0.0.9
  Upstream Author : Dennis Craven <[EMAIL PROTECTED]>
* URL : http://newton.sourceforge.net
* License : GPL
  Description : A desktop wiki applet for Gnome

Newton is a desktop wiki applet for the GNOME2 desktop environment. You
enter your notes and information in a simple wiki-like syntax and Newton
formats it in rich HTML for you! It is designed to make the creation of
richly formatted documents of any type as simple and quick as possible.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)


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

Re: Build-Depend'ing on libasound2-dev just for Linux

[Josselin Mouette]

Le dimanche 18 septembre 2005 à 02:22 +0300, Guillem Jover a écrit :
> > In this case, it is enough to do something like:
> > Build-Depends: type-handling, libasound2-dev | not+linux-gnu
> 
> No, that's too late, the Build-Depends are analyzed before installing
> them. You'd need some kind of ugly Build-PreDepends or similar.

I can only see this as a bug in the buildd software. I agree that we
need the functionality in dpkg anyway, but tools should be able to
handle a workaround like type-handling.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Bug#328996: ITP: hdaps-utils -- HDAPS (IBM Hard Drive Active Protection System) utilities

[Murillo Bernardes]

Package: wnpp
Severity: wishlist
Owner: Murillo Fernandes Bernardes <[EMAIL PROTECTED]>


* Package name: hdaps-utils
  Version : 0.1
  Upstream Author : Yoni Rom <[EMAIL PROTECTED]>,Robert Love <[EMAIL PROTECTED]>
* URL : http://143.106.24.56/~bernarde/hdaps/debian/
* License : (GPL)
  Description : HDAPS (IBM Hard Drive Active Protection System) utilities

This is a simple collection of utilities for HDAPS (IBM Hard Drive
Active Protection System). The kernel driver is relatively stable,
included in Linus tree and available in Linux-2.6.14-rc1. The two
applications in this package allows the user see the driver in
action, one of them is a simple text-based app and the other a nice
openGL laptop that rotates in real-time via hdaps.

The Hard Drive Active Protection System (hdaps) is present and
supported in IBM Thinkpad T41, T42, T43, R50, R50p, R51, and
X40, at least.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13-rc7
Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1)

Removing yehia and gql?

[Andreas Rottmann]

Hi!

When I started with Debian, I packaged several libraries which I am
upstream for. Since I don't actively develop these libraries
anymore[0], and they don't get much usage according to popcon, I'm
considering filing removal requests against ftp.d.o against them. The
libraries are:

* gql -- A C++ database interface in the spirit of JDBC, includes
 drivers for postgresql, mysql, sqlite and a command-line DB
 shell similiar to psql from PostgreSQL.

  Packages: libgql-0.5-1, libgql-0.5-dev, libgql-driver-0.5-pg,
libgql-driver-0.5-mysql, libgql-driver-0.5-sqlite,
libgql-0.5-script, gql-shell

* yehia -- A C++ application framework, centered on dynamically
   loadable plugins. This is used by GQL for loading the
   database drivers.

  Packages: libyehia0.5-0, libyehia0.5-dev, libyehia0.5-script-gtk

So, if you are interested in keeping these packages in Debian, please
speak up now, and maybe offer adopting them ;). I will still act as
upstream for bugfixes if needed, but there will be no active
development.

[0] Well, frankly, after hacking in Scheme for a while now, I abhor
the monstrosity that is C++, and don't want to spend time doing
this in my free time, since my current day job requiring C++
coding gives more than enough opportunity to enjoy that lovely
pile of features that aims to make C a higher level language, but
still doesn't add real expressiveness when compared to
Scheme/CL.  

Regards, Rotty
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://yi.org/rotty  | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com

Anonymous surfing? Use Tor: http://tor.eff.net


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

Re: [libsmjs-dev]: Missing files

[Darren Salt]

I demand that Davi Leal may or may not have written...

> I am missing the "js.msg" and "jsopcode.tbl" files in the
> "libdevel/libsmjs-dev" development library package.

> The files are in the mozilla-thunderbird-dev and mozilla-dev packages, but
> not in the libsmjs-dev.
[snip]

> I have workaround the compilation error of my application as follows:
>  apt-get install mozilla-dev
>   cp /usr/include/mozilla/js/js.msg   /usr/include/smjs/
>   cp /usr/include/mozilla/js/jsopcode.tbl /usr/include/smjs/
>  apt-get remove  mozilla-dev

(Assuming bash...)

  # aptitude download mozilla-dev
  # dpkg-deb -x mozilla-dev_1.7.8.1sarge2_i386.deb foo
  # cp -a foo/usr/include/mozilla/js/js{.msg,opcode.tbl} /usr/include/smjs/
  # rm -rf foo
  # rm mozilla-dev_1.7.8.1sarge2_i386.deb

Note that these files /may/ not be the same as those which you say should be
in libsmjs-dev.

> Could you include the files in the libsmjs-dev package?.

See http://www.debian.org/Bugs/Reporting>.

(FWIW, if your application is intended to be buildable on non-Debian systems,
you need to be aware that /usr/lib/smjs may be known as /usr/lib/js. I got
build failure reports about this when I deprecated gxine's internal copy.)

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| sarge,| youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   I don't ask for much, just untold riches...

The surest way to be late is to have plenty of time.


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

Re: How can I build a package from source that require the source of another (library) package?

[Christoph Hellwig]

On Sat, Sep 17, 2005 at 04:02:56PM -0400, Jaldhar H. Vyas wrote:
> On Sat, 17 Sep 2005, Tomas Fasth wrote:
> 
> >Well, I can and already do. But it doesn't make a difference because
> >pathan has been programmed to depend on the xerces source, not the
> >exported library interface. For example, this is how the compiler
> >error looks like:
> >
> 
> I think I had to deal with this kind of thing when I was attempting to 
> deal with packaging dbxml.  (And its this kind of thing that makes me 
> glad you're doing it not me!)  It's still  only looking for header files 
> even though they are not public ones.  So you should copy any headers it 
> needs into your (pathan) source package as is done for device driver 
> packages which rely on kernel headers not in the kernel-headers package.

This is as wrong as doign that for kernel drivers?  What driver packages
do that?  Look like I need to file some bugs..


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

Re: How can I build a package from source that require the source of another (library) package?

[Stefano Zacchiroli]

On Fri, Sep 16, 2005 at 09:34:30PM +0200, Tomas Fasth wrote:
> Berkeley DB XML sources provided by Sleepycat Software. The pathan
> build script require a path to the xerces source code tree. I have

AOL on all the comments about how bad is to have this kind of
dependencies.

Still, if you fail convincing upstream to remove this source
dependencies you can follow the approach I took with the "wlex" source
package (an UTF8 lexer library for OCaml).

The wlex package used to build-depends on the "ocaml-source" package (a
binary package shipping in /usr/src a tarball of the ocaml source code).
In debian/rules I used to extract the tarball in debian/...  and invoke
the wlex build process pointing it to debian/...  as the directory
containing the ocaml source code.

Cheers.

PS note that wlex has been superseded by ulex, if you want to look ad
the sample debian/rules you have to look for it on snapshot.debian.net

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

[libsmjs-dev]: Missing files

[Davi Leal]

Hi,
Debian GNU/Linux 3.1 (a.k.a. sarge)


I am missing the "js.msg" and "jsopcode.tbl" files in the 
"libdevel/libsmjs-dev" development library package.

The files are in the mozilla-thunderbird-dev and mozilla-dev packages, but not 
in the libsmjs-dev.

 mail/mozilla-thunderbird-dev
   usr/include/mozilla-thunderbird/js/js.msg
   usr/include/mozilla-thunderbird/js/jsopcode.tbl

 devel/mozilla-dev
   usr/include/mozilla/js/js.msg
   usr/include/mozilla/js/jsopcode.tbl


I have workaround the compilation error of my application as follows:
 apt-get install mozilla-dev
  cp /usr/include/mozilla/js/js.msg   /usr/include/smjs/
  cp /usr/include/mozilla/js/jsopcode.tbl /usr/include/smjs/
 apt-get remove  mozilla-dev

Could you include the files in the libsmjs-dev package?.

Best regards,
Davi


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

Re: How can I build a package from source that require the source of another (library) package?

[Roberto C. Sanchez]

On Sun, Sep 18, 2005 at 01:26:36PM +0200, Josselin Mouette wrote:
> Le samedi 17 septembre 2005 à 06:36 -0500, Bill Allombert a écrit :
> > On Fri, Sep 16, 2005 at 09:34:30PM +0200, Tomas Fasth wrote:
> > > Pathan is a library that implements XPath functionality in c++. It
> > > is available both as a separate tarball as well as bundled with the
> > > Berkeley DB XML sources provided by Sleepycat Software. The pathan
> > > build script require a path to the xerces source code tree. I have
> > > tried to find a way to build the pathan library without providing
> > > the xerces source but failed.
> > 
> > find out exactly the files in the xerces sources that are needed
> > to build Pathan (using strace, etc.). Change xerces26-dev to include
> > these files so that you can just build-dep on xerces26-dev. Then try to
> > help upstream to reduce the source dependency.
> 
> I guess this is still a bad idea. If these symbols are not part of the
> public API, you should never rely on them, as there's a possibility for
> xerces26-dev to stop providing them, or to change them, later.

True.  I ran into same thing with packaging anyterm (still in progress)
and librote (already in Sid/Etch).  I simply had to ask the librote
developer to make the symbols public and he did.  No problem and much
cleaner than requiring the source of another package.

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


pgpOLIcywpdK5.pgp
Description: PGP signature

Re: apt with index diff support

[Andreas Metzler]

Michael Vogt <[EMAIL PROTECTED]> wrote:
[...]
> We believe that the code is now "good" enough for wider testing. I
> have setup a repository for the patched version of apt with the pdiff
> support.  Just add this line to your sources.list file:
> "deb http://people.debian.org/~mvo/apt/pdiffs/ /"
[...]
> Example: apt-get install 3dchess -o
> APT::URL-Remap::http://merkel.debian.org/~aba/debian/=http://ftp.de.debian.org/d
> +ebian/"

The remapping features seems not to work with deb-src entries.


(SID)[EMAIL PROTECTED]:/tmp$ apt-get -o 
APT::URL-Remap::http://merkel.debian.org/~aba/debian/=http://ftp.at.debian.org/debian/
 source efax
Reading package lists... Done
Building dependency tree... Done
Need to get 114kB of source archives.
Err http://merkel.debian.org sid/main efax 1:0.9a-15 (dsc)
  404 Not Found
[...]
Failed to fetch 
http://merkel.debian.org/~aba/debian/pool/main/e/efax/efax_0.9a-15.dsc  404 Not 
Found
[...]
E: Failed to fetch some archives.


"apt-get update"ing of deb-src entries seems to work well, though.
Just the actual fetching of source packages is broken.
  cu andreas

-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


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

Re: How can I build a package from source that require the source of another (library) package?

[Josselin Mouette]

Le samedi 17 septembre 2005 à 06:36 -0500, Bill Allombert a écrit :
> On Fri, Sep 16, 2005 at 09:34:30PM +0200, Tomas Fasth wrote:
> > Pathan is a library that implements XPath functionality in c++. It
> > is available both as a separate tarball as well as bundled with the
> > Berkeley DB XML sources provided by Sleepycat Software. The pathan
> > build script require a path to the xerces source code tree. I have
> > tried to find a way to build the pathan library without providing
> > the xerces source but failed.
> 
> find out exactly the files in the xerces sources that are needed
> to build Pathan (using strace, etc.). Change xerces26-dev to include
> these files so that you can just build-dep on xerces26-dev. Then try to
> help upstream to reduce the source dependency.

I guess this is still a bad idea. If these symbols are not part of the
public API, you should never rely on them, as there's a possibility for
xerces26-dev to stop providing them, or to change them, later.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

[ldap]: Missing libldap-2.2-dev in Sarge

[Davi Leal]

Hi,
Debian GNU/Linux 3.1 (a.k.a. sarge)


There is not development libraries available for the 2.2.23 OpenLDAP version. 
I have read OpenLDAP must be used with care due to bugs. I am going to 
develop an application using the C language. What libldap-dev and slapd 
version do you advise me to use?.

 libldap-2.2-7  2.2.23-8OpenLDAP libraries  
  

 libldap2   2.1.30-8OpenLDAP libraries
 libldap2-dev   2.1.30-8OpenLDAP development libraries  
  

 slapd  2.2.23-8OpenLDAP server (slapd) 
  


Regards,
Davi


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

hotplug blacklists

[Marco d'Itri]

The new hotplug subsystem cannot handle blacklisting anymore, and now
delegates it to modprobe.
modprobe uses a different syntax, so the old /etc/hotplug/blacklist*
files are not supported anymore.
Considering that the other distributions have no plans to keep
supporting hotplug-style blacklisting I think we can just switch to the
new system and forget about it.

*BUT* if somebody really feels strongly about this, as the
module-init-tools maintainer I would not object to a modprobe patch to
add support old-style blacklists, as long as it will be ready in a few
days and the submitter is willing to maintain it as long as it will be
needed.


The affected packages are:

alsa-base   Debian ALSA Maintainers <[EMAIL PROTECTED]>
capiutils   Paul Slootman <[EMAIL PROTECTED]>
hostap-utilsAndres Salomon <[EMAIL PROTECTED]>
libphidgets0martin f. krafft <[EMAIL PROTECTED]>
libsane Julien BLACHE <[EMAIL PROTECTED]>
lm-sensors  Aurelien Jarno <[EMAIL PROTECTED]>

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Debian Reference

[Osamu Aoki]

On Sun, Sep 18, 2005 at 04:20:32AM +0100, Antony Gelberg wrote:
> 
> There's rather a lot there.  

Nay, that a tiny fraction of things which needs to be consideded.  This
is one of the key reason behind why few bothered to contribute.  So
changing this situation from bottom by offering better infrastructure to
create such an document is way to think.

> I'll start with a patch for Chapter 2 to
> see if we are on the same wavelength.  We need to restructure it before
> we can improve the content.

Chapter 2 shares a lot with FAQ in terms of contents.  Javi is updating
it.  See mailing list for the details and be aware of it. 

This chapter describes a lot of old things which is useful for few
extreme case.  To update it, you need to be very familiar with how
Debian works and worked.  I think you may need a bit more time for that.
So for now, I strongly limit patch to factual errors.

Instead, I suggest you to do bug hunting and issue hunting on chapters
and thinking how all other needs to be reorganized and how that will be
achieved:

3. installation hint.  
  -  how this can be reorganized without duplicating install masnual.
5. Upgrading distribution
  - how can this be made distribution independent
  - avoid overlap with installation and release note.
6. Package management
  - Now that aptitude is main tool, we need to carefully update this.
  - Remove all woody/potato things.
7. Kernel
  - Rewite this focusing udev/2.6 management (But who knows best?)
8. Tips
  - New installation CD is not easy tool for emergency recover.
Suggest bootable CD alternative
  - im-switch
  - UTF-8

Oh, please read some basics of contributing document at:

 http://qref.sourceforge.net/doc/

Osamu


FYI: As for the spam on the list, I gave up doing spam filtering myself.
I use (semi-)commercial POP account (gmail) to do the dirty work for me
to save my bandwidth.



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