mueller: dictd (>= 1.10.1) | any-other-dict-server dependency

[Mikhail Gusarov]

Gentlemen,

what's the best way to handle the following dependency problem:

mueller7-dict package is UTF-8 encoded and requires one of the
following dict servers to operate:

* dictd (<< 1.10.1) with --locale=xx_XX.UTF-8 in config
* dictd (>= 1.10.1)
* serpento (as the only one more dict server in Debian providing dict-server)

Handling of first case currently involves debconf questions and
patching dictd config, other ones do not require any handling.

I would like to drop first case completely (as dictd << 1.10.1 is only
in Sarge) to simplify things. However, it is unclear for me how to
declare dependencies properly.

Current situation is "Depends: dictd | dict-server". Changing it to
"Depends: dictd (>= 1.10.1) | dict-server" is incorrect as dictd (<<
1.10.1) provides dict-server. Changing it to "Depends: dictd (>=
1.10.1) | serpento" makes life harder if someone wants to add another
dict server to Debian.

-- 
JID: [EMAIL PROTECTED]


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

Work-needing packages report for Sep 22, 2006

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 304 (new: 15)
Total number of packages offered up for adoption: 99 (new: 7)
Total number of packages requested help for: 31 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   binutils-h8300-hms (#387772), orphaned 5 days ago
 Description: GNU cross assembler for H8/300[HS], linker and binary
   utilities
 Reverse Depends: brickos gcc-h8300-hms
 Installations reported by Popcon: 28

   brickos (#387769), orphaned 5 days ago
 Description: alternative OS for LEGO(r) Mindstorms RCX. Supports
   devel. in C/C++
 Installations reported by Popcon: 8

   divine (#387774), orphaned 5 days ago
 Description: Automatic IP configuration detection for laptops
 Installations reported by Popcon: 12

   exdbm (#387773), orphaned 5 days ago
 Description: eXode database manager
 Reverse Depends: gpsim
 Installations reported by Popcon: 70

   feta (#388363), orphaned 2 days ago
 Description: simpler interface to APT, dpkg, and other package tools
 Installations reported by Popcon: 178

   gcc-h8300-hms (#387771), orphaned 5 days ago
 Description: The GNU C/C++ cross-compilers for the Hitachi
   H8/300[HS] processors
 Reverse Depends: brickos
 Installations reported by Popcon: 17

   gpsim-led (#387778), orphaned 5 days ago
 Description: LED module for gpsim
 Installations reported by Popcon: 31

   gpsim-logic (#38), orphaned 5 days ago
 Description: logic module for gpsim
 Installations reported by Popcon: 36

   lnpd (#387770), orphaned 5 days ago
 Description: daemon for LNP communication with BrickOS
 Installations reported by Popcon: 1

   pathological (#388358), orphaned 2 days ago
 Description: puzzle game involving paths and marbles
 Installations reported by Popcon: 158

   pathological-music (#388359), orphaned 2 days ago
 Description: puzzle game involving paths and marbles
 Reverse Depends: pathological
 Installations reported by Popcon: 173

   pydance (#388361), orphaned 2 days ago
 Description: dancing simulation game similar to the kind in arcades
 Installations reported by Popcon: 82

   pydance-music (#388360), orphaned 2 days ago
 Description: Songs and step patterns for pydance
 Reverse Depends: pydance
 Installations reported by Popcon: 104

   tkcon (#388520), orphaned yesterday
 Installations reported by Popcon: 27

   uligo (#388362), orphaned 2 days ago
 Description: tsumego (go problems) practice tool
 Installations reported by Popcon: 97

289 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   gift (#388134), offered 3 days ago
 Description: the giFT filesharing system
 Reverse Depends: apollon gift giftd giftoxic giftui libgift-dev
   libgiftproto-dev libgiftproto0 libgnutella-gift libopenft-gift
 Installations reported by Popcon: 441

   gift-gnutella (#388135), offered 3 days ago
 Description: giFT plugin for the Gnutella network
 Reverse Depends: gift
 Installations reported by Popcon: 234

   gift-openft (#388136), offered 3 days ago
 Description: giFT plugin for the OpenFT network
 Reverse Depends: gift
 Installations reported by Popcon: 371

   libifp (#388365), offered 2 days ago
 Description: communicate with iRiver iFP audio devices
 Reverse Depends: amarok ifp-line-libifp ifpgui libifp-dev
 Installations reported by Popcon: 1713

   remind (#388426), offered yesterday
 Description: a sophisticated reminder service
 Reverse Depends: wyrd
 Installations reported by Popcon: 264

   root-portal (#387596), offered 6 days ago
 Description: Monitors the system and displays the results on the
   desktop
 Installations reported by Popcon: 123

   tkcon (#388520), offered yesterday
 Installations reported by Popcon: 27

92 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 455 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-client
 Installations reported by Popcon: 50

   apt-build (#365427), requested 145 days ago
 Description: Need new developer(s)
 Installations reported by Popcon: 449

   apt-show-versions (#382026), requ

Bug#388701: ITP: beryl -- Beryl Project compositing window manager

[Shawn Starr]

Package: wnpp
Severity: wishlist
Owner: Shawn Starr <[EMAIL PROTECTED]>

* Package name: beryl
  Version : 0.1.0
  Upstream Author : Quinn Storm <[EMAIL PROTECTED]>
* URL : http://www.beryl-project.net/
* License : GPL
  Programming Lang: C
  Description : Beryl Project compositing window manager, decorator and 
theme support

The Beryl Project brings 3D desktop visual effects that improve usability of
the X Window System and provide increased productivity though plugins and themes
contributed by the community giving a rich desktop experience.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-rc5
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)


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

Re: 2.4 vs. 2.6 (was: Re: Moving /var/run to a tmpfs?)

[Martín Ferrari]

On 9/17/06, Hendrik Sattler <[EMAIL PROTECTED]> wrote:


A good hint for such cases is to actually report such bugs to the driver
developers. Did you?
You must have pretty uncommon hardware, though, as many use 2.6 kernels
without such problems...


I have an old server with 2.4 because 2.6 won't run on it. Not big
deal, it doesn't need 2.6 anyway...

--
Martín Ferrari

Re: Compatibility between Debian amd64 and other distributions

[Daniel Jacobowitz]

On Sat, Sep 23, 2006 at 02:50:35AM +0200, Goswin von Brederlow wrote:
> But running Debian binaries on other distributions remains a
> problem. For example static binaries that use libnss* plugins will
> fail to find those plugins on other systems. Copying the debian libc6
> to your ~/lib/ dir on another distribution will break locale plugins.

Do you have any less contrived examples?  FWIW, I think in either of
these cases you deserve to keep both pieces.

> The fix is really simple. Compile glibc with libc_[s]libdir =
> [/usr]/lib64 but move [/usr]/lib64 to [/usr]/lib and add the
> compatibility links after the build. That results in libc6 using the
> FHS paths [/usr]/lib64 when looking for plugins, which means following
> the [/usr]/lib64 link on Debian, just like every other distributions
> glibc does on amd64. Nothing else changes.

I'm perfectly happy to do this.  After etch.

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: XS-X-Vcs-XXX field not (yet) announced

[John Goerzen]

On Sat, Sep 23, 2006 at 01:04:59AM +0200, Stefano Zacchiroli wrote:
> I'm a casual user of distributed VCS (used sparingly hg and baz here),
> but I don't see how this is related to the field as we are intending it.
> But maybe it's just because I'm not that familiar with them, let me know
> if this is the case.
> 
> AFAICT, no matter how may repo you're pulling changes from or pushing
> changes to, you as a DD have a main repository out of which you create
> the debian package, isn't it? That's probably the repo the user want to

I do, yes.  But that is because I already have the orig.tar.gz from 
upstream.

If somebody wants to casually build source packages from an older 
version, by using a tool such as darcs-buildpackage -- which generates a 
diff.gz based on the differences between the two branches -- they'll 
need the upstream URL as well.

However, if they are just using it to send me a few patches, the Debian 
URL will do just fine.

-- John


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

Compatibility between Debian amd64 and other distributions

[Goswin von Brederlow]

Dear release team and DDs,

I submitted a trivial patch for glibc in bug#387446 to increase the
compatibility between debian amd64 and other distributions. The
maintainer has reassign this to 'general' saying:

Aurelien Jarno <[EMAIL PROTECTED]> writes:
> Actually there is nothing wrong with the glibc, it is perfectly
> coherent with the other packages on amd64, even if it violates the
> FHS. If you want to change it we have to stay coherent and also
> change all the others packages. I am therefore reassigning this bug
> to general. A global decision as to be taken.

So let me summarize the situation for the release team and DDs in
general so you know that there is a problem and what it is while we
can still do something about it. The issue is the following:

FHS says that 64bit libraries on amd64 go to [/usr]/lib64. All non
Debian distributions follow that line.

Debian compiles its glibc for [/usr]/lib and adds symlinks for
[/usr]/lib64 to [/usr]/lib so FHS compliant binaries run on Debian.

But running Debian binaries on other distributions remains a
problem. For example static binaries that use libnss* plugins will
fail to find those plugins on other systems. Copying the debian libc6
to your ~/lib/ dir on another distribution will break locale plugins.


The fix is really simple. Compile glibc with libc_[s]libdir =
[/usr]/lib64 but move [/usr]/lib64 to [/usr]/lib and add the
compatibility links after the build. That results in libc6 using the
FHS paths [/usr]/lib64 when looking for plugins, which means following
the [/usr]/lib64 link on Debian, just like every other distributions
glibc does on amd64. Nothing else changes.


Aurelien Jarno doesn't like the incoherents introduced by compiling
for [/usr]/lib64 but then still using [/usr]/lib. A fact that already
exists in part in glibc because 'libc_rtlddir = /lib64' is set to get
the /lib64/ld-linux-x86-64.so.2 compiled into binaries (every dynamic
amd64 binary on Debian has that path and file). This was introduced
after sarge was released. In sarge /lib/ld-linux-x86-64.so.2 is used
in glibc binaries.

Steve Langasek had concerns about side-effects:
> That probably means that a change for this would not be accepted
> into etch, since fiddling library paths may have unexpected
> side-effects and glibc is already frozen.

So far I have seen none.


Now I guess the release-team has to make a decision how important the
FHS and compatibility is to Debian.

MfG
Goswin


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Joey Hess]

Stefano Zacchiroli wrote:
> > As to it being an XS- field, dpkg-dev doesn't warn at all about building
> > packages with such a field (unlike an XB- field), so I don't really
> > care, although it seems it would be better to lose the XS- if possible.
> 
> Note that we were more discussing about losing the X- part (for the
> records, a sample field is "XS-X-Vcs-Svn"), which in my mind is the part
> representing the non officialness of the field.
> 
> I don't know at all if it's possible to remove the XS- part. I don't
> really care on the PTS side, but I suspect it wont get in the Sources
> file without the XS- prefix. Am I wrong? Request for help on this ...

The "X" in the XS- part already is intended to mean what your extra X-
is being used to mean, actually. XS- means that the field is unofficial.

To make a Vcs-Svn field work, dpkg-dev needs to be modified to recognise
that field. A simple modification but it would need to be done for all
the other ones for other RCSes, which could be a problem since there are
more and more of them. If we wanted to use a formalised field with no X-
prefix, then something like this might be more scalable:

Vcs: svn svn://...

My preference is either the above or XS-Vcs-*

> > Have you thought at all about automated systems that could be built on
> > top of this? Things like a repo browser that can browse (and find
> > recent changes in) all packages, or mirrors of repos that arn't hosted
> > at svn.debian.org, or what have you.
> 
> I haven't yet thought about going that far, but they are all ideas which
> are whetting my appetite :-)

Another one is sucking them all in to a grand unified tracking repo using
a single RCS (or as many RCSes as everything can be converted to).

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Debian ISOs

[Andrew Donnellan]

On 9/22/06, Anthony L. Bryan <[EMAIL PROTECTED]> wrote:

(Oops, hit the send key combo before finishing, sorry).

Here's a brief refresher on metalinks & how it could be useful for Debian
ISO distribution:

'Metalink makes complex download pages obsolete by replacing long lists of
download mirrors and BitTorrent trackers with a single .metalink file. As
you might have already guessed, a .metalink file is a file that tells a
download manager all the different ways it can download a file. The file
itself takes the form of an open XML standard that can list an unlimited
number of HTTP and FTP sources as well as BitTorrent trackers and ed2k and
magnet links.'


Is it possible to extend it and make a client capable of jigdo or
similar? It might look like:

http://cdimage.debian.org/debian-cd/current/i386/jigdo-dvd/debian-31r3-i386-binary-1.jigdo";>
ftp://ftp.au.debian.org/debian/

(Sorry, this is hacked up; I don't know how acceptable it would be to
specify the jigdo template as an attribute instead of the content.)
--
Andrew Donnellan
http://andrewdonnellan.com
http://ajdlinux.blogspot.com
Jabber - [EMAIL PROTECTED]
GPG - hkp://subkeys.pgp.net 0x5D4C0C58
---
Member of Linux Australia - http://linux.org.au
Debian user - http://debian.org
Get free rewards - http://ezyrewards.com/?id=23484
OpenNIC user - http://www.opennic.unrated.net


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

RE: Debian ISOs

[Anthony L. Bryan]

(Oops, hit the send key combo before finishing, sorry).

Here's a brief refresher on metalinks & how it could be useful for Debian
ISO distribution:

'Metalink makes complex download pages obsolete by replacing long lists of
download mirrors and BitTorrent trackers with a single .metalink file. As
you might have already guessed, a .metalink file is a file that tells a
download manager all the different ways it can download a file. The file
itself takes the form of an open XML standard that can list an unlimited
number of HTTP and FTP sources as well as BitTorrent trackers and ed2k and
magnet links.'

aria2 is in unstable and testing so people can install & use it easily,
thanks to Patrick.

I hope some people can try it out!

apt-get install aria2

aria2c
http://www.metalinker.org/samples/debian-31r2-i386-binary-1.iso.metalink

This is a big DVD ISO download, but if you just let it run for a few minutes
you'll see how fast & easy it can be if you have a fast connection. Once it
finishes, the checksum will automatically be verified. Automatically
generated metalinks would list all mirrors, so you could tell the client
you're in de so it should use those mirrors first, then other mirrors
nearby.

Here's what this metalink contains:


http://www.metalinker.org/";>
  
debian
http://www.debian.org/
  
  Debian 3.1r2 i386 DVD ISO
  

  3.1r2
  Linux-x86
  
e467b508185f4fdd8e97c9ee76045288
  
  
http://cdimage.debian.org/debian-cd/current/i386/iso-dvd/de
bian-31r2-i386-binary-1.iso
http://debian.osuosl.org/debian-cdimage/current/i386/iso-dv
d/debian-31r2-i386-binary-1.iso
http://ftp.iasi.roedu.net/mirrors/ftp.debian.org/debian-cd/
current/i386/iso-dvd/debian-31r2-i386-binary-1.iso
http://linorg.usp.br/iso/debian/3.1_r2/i386/iso-dvd/debian-
31r2-i386-binary-1.iso
http://ftp.gva.es/mirror/debian-cd/current/i386/iso-dvd/deb
ian-31r2-i386-binary-1.iso
http://ftp.de.debian.org/debian-cd/current/i386/iso-dvd/deb
ian-31r2-i386-binary-1.iso
http://ftp-stud.fht-esslingen.de/debian-cd/current/i386/iso
-dvd/debian-31r2-i386-binary-1.iso
http://debian.inode.at/debian-cd/3.1_r2/i386/iso-dvd/debian
-31r2-i386-binary-1.iso
ftp://ftp.free.fr/pub/Distributions_Linux/debian-cd/3.1_r2/
i386/iso-dvd/debian-31r2-i386-binary-1.iso
ftp://mirror.aarnet.edu.au/pub/debian-cd/3.1_r2/i386/iso-dv
d/debian-31r2-i386-binary-1.iso
ftp://ftp.iinet.net.au/pub/debian/debian-cd/current/i386/is
o-dvd/debian-31r2-i386-binary-1.iso
ftp://ftp.scarlet.be/pub/debian-cd/current/i386/iso-dvd/deb
ian-31r2-i386-binary-1.iso





  



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

Re: Media players in Debian

[Ben Finney]

"César Martínez Izquierdo" <[EMAIL PROTECTED]> writes:

> First of all, I don't have time to send bug reports for all the bugs I
> find (although I send most of them, when I have to choose I send to
> packages which I usually use).
> Specially, when I want to see a film, I really want to see the film at
> that moment, not after sending some bug reports.

That's entirely your choice of course. No-one here can tell you what
to do with your time.

However, if you experience the bug, and don't ensure that the bug
tracker has a record of that bug, then you can't expect anyone to fix
it.

-- 
 \  "Time's fun when you're having flies."  -- Kermit the Frog |
  `\   |
_o__)  |
Ben Finney


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

RE: Debian ISOs

[Anthony L. Bryan]

Here's a brief refresher on metalinks & how it could be useful for Debian
ISO distribution:


aria2 is in unstable and testing so people can install & use it easily,
thanks to Patrick.

I hope some people can try it out!

apt-get install aria2

aria2c
http://www.metalinker.org/samples/debian-31r2-i386-binary-1.iso.metalink



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

Re: XS-X-Vcs-XXX field not (yet) announced

[Stefano Zacchiroli]

On Fri, Sep 22, 2006 at 04:18:56PM -0400, Joey Hess wrote:
> As far as using this field for svn repos, I assume that it should be to
> an anonymous-friendly version of the repo if possible (svn:// not
> svn+ssh://). Should it link to the trunk, rather than the head of the
> repo? I think so and that's how your example gives it.

Totally agreed, that's precisely my examples have svn://. Still, the
drawback of this is that with svn you can just right click on a terminal
and "open link", but I'm convinced this is a flaw in our browsing tool,
I feel the svn:// url scheme is the right one for that.

> As to it being an XS- field, dpkg-dev doesn't warn at all about building
> packages with such a field (unlike an XB- field), so I don't really
> care, although it seems it would be better to lose the XS- if possible.

Note that we were more discussing about losing the X- part (for the
records, a sample field is "XS-X-Vcs-Svn"), which in my mind is the part
representing the non officialness of the field.

I don't know at all if it's possible to remove the XS- part. I don't
really care on the PTS side, but I suspect it wont get in the Sources
file without the XS- prefix. Am I wrong? Request for help on this ...

> Have you thought at all about automated systems that could be built on
> top of this? Things like a repo browser that can browse (and find
> recent changes in) all packages, or mirrors of repos that arn't hosted
> at svn.debian.org, or what have you.

I haven't yet thought about going that far, but they are all ideas which
are whetting my appetite :-)

Cheers.

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

Re: XS-X-Vcs-XXX field not (yet) announced

[Stefano Zacchiroli]

On Fri, Sep 22, 2006 at 03:42:47PM -0500, John Goerzen wrote:
> That doesn't work so well for heavily distributed systems such as darcs.
> In darcs, every repo is a branch, and every branch is a repo.  Every
> repo represents exactly 1 branch.  Of course, branching is cheap, so
> creating repos is also cheap.

I'm a casual user of distributed VCS (used sparingly hg and baz here),
but I don't see how this is related to the field as we are intending it.
But maybe it's just because I'm not that familiar with them, let me know
if this is the case.

AFAICT, no matter how may repo you're pulling changes from or pushing
changes to, you as a DD have a main repository out of which you create
the debian package, isn't it? That's probably the repo the user want to
see, e.g. the one where you've just committed (or pulled, it doesn't
matter) the fix which triggered the +pending tag in the BTS.

As a different point, the distinction upstream/debian does not always
apply. All my packages maintained with svn doesn't have an upstream
part, I just use an orig tarball (some times available on the repo,
sometimes no) and the mergeWithUpstream property.

Cheers.

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

Re: Media players in Debian

[Andrew Donnellan]

On 9/22/06, Reinhard Tartler <[EMAIL PROTECTED]> wrote:

"Andrew Donnellan" <[EMAIL PROTECTED]> writes:

> It would be great if upstream would actually care about legal issues,
> licenses and patents in particular.

Upstream does care for legal issues, and patents in particular. Check
the mplayer development mailing list archive for the last months.


For the last months, as you say. Maybe this is because of the
increased pressure now that software patents are now being enforced
and so on. At the beginning they seemed to just chuck in whatever.



> This is pretty much the only thing stopping Debian from distributing
> it - it may actually be illegal [...]

The problematic parts regarding patents are mostly in ffmpeg, which is
already in debian for some time. There seem to be no problem for debian
redistributing ffmpeg.


I believe it is a patent-stripped ffmpeg.



Other maybe problematic parts are in libdvdcss, which has been strpped
off in the proposed mplayer package.

Honestly, I don't know what problems remain problems regarding mplayer,
but claiming that mplayer upstream did not care about copyright and
patent issue is straight wrong and does only spread FUD. Please help to
improve the situation by mentioning concrete remaining problems.


The Mplayer devs are still not communicating with Debian about the
remaining problems. To rectify them we need to communicate better and
get their input on d-l and d-d.

--
Andrew Donnellan
http://andrewdonnellan.com
http://ajdlinux.blogspot.com
Jabber - [EMAIL PROTECTED]
GPG - hkp://subkeys.pgp.net 0x5D4C0C58
---
Member of Linux Australia - http://linux.org.au
Debian user - http://debian.org
Get free rewards - http://ezyrewards.com/?id=23484
OpenNIC user - http://www.opennic.unrated.net


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

Re: XS-X-Vcs-XXX field not (yet) announced

[John Goerzen]

On Fri, Sep 22, 2006 at 09:43:37PM +0200, Stefano Zacchiroli wrote:
> On Fri, Sep 22, 2006 at 02:21:22PM -0500, John Goerzen wrote:
> > I would also like to raise a question: does it make any sense to be able
> > to list two URLs, one for the Debian branch and one for the upstream
> > branch?
> 
> I've thought about similar issues. I made up my mind about these
> questions being in the wrong direction :)
> 
> My idea for this field it to give a pointer intended for human
> consumption. Once a user knows where to look, if he is willing to have
> access to the repo he is probably able to discover branches, tags, learn
> the repo layout and so on. If we agree on this idea I would answer no,
> it doesn't make sense to me.

That doesn't work so well for heavily distributed systems such as darcs.
In darcs, every repo is a branch, and every branch is a repo.  Every
repo represents exactly 1 branch.  Of course, branching is cheap, so
creating repos is also cheap.

A person may be able to discover an upstream repo by simply browsing to
a parent directory if the webserver is configured to simply show this.
On the other hand, when darcs is used upstream, it is quite likely that
the upstream repo doesn't even exist on the same server.  The package's
repo may not even have a link to the upstream repo.

Now, that may not be a big deal -- the person could presumably still
find out about the upstream repo from the upstream website.

Just a question.

-- John


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Joey Hess]

As far as using this field for svn repos, I assume that it should be to
an anonymous-friendly version of the repo if possible (svn:// not
svn+ssh://). Should it link to the trunk, rather than the head of the
repo? I think so and that's how your example gives it.

As to it being an XS- field, dpkg-dev doesn't warn at all about building
packages with such a field (unlike an XB- field), so I don't really
care, although it seems it would be better to lose the XS- if possible.

Very good idea on this, I'll be adding it to all my packages, and to all
of d-i, if someone else doesn't do it first.

Have you thought at all about automated systems that could be built on
top of this? Things like a repo browser that can browse (and find recent
changes in) all packages, or mirrors of repos that arn't hosted at
svn.debian.org, or what have you.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Contact et distribution

[Josselin Mouette]

Le jeudi 21 septembre 2006 à 10:57 -0700, Sammy Nzazi a écrit :
> Bonjour,
> Nous avons commencé une serie d'études sur le lunix et nous voulons en
> faire le sytème le plus repandu dans notre pays République
> Démocratique du Congo. Aussi nous vous demandons de nous aider  en
> nous envoyant 20 cds de Linux débian car nous ne pourrons pas faire
> des téléchargements. Ces Cds seront recopiés et distribués
> gratuitement avec un minimum d'encradement d'installation et
> utilisation.
> Car nous avons une école informatique dans notre organisation 'Eglise
> Chretienne' Victory Chapel.
> Merci d'avance pour votre concours.
> Notre Adresse :
> Réverend Samy Nzazi
> B.P. 498 Limete
> 00243 Kinshasa
> République Démocratique du CONGO

For non-French speakers, this guy is trying to spread Linux and
especially Debian in Congo, but he cannot download our CD images. He's
looking for someone who would send him 20 Debian CDs, which will be
copied and distributed for free with some help for their installation.

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Bug#388673: ITP: pwman3 -- Command line password manager

[Julien Louis]

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

* Package name: pwman3
  Version : 0.0.5
  Upstream Author : Ivan Kelly <[EMAIL PROTECTED]>
* URL : http://pwman.bleurgh.com
* License : GPL
  Programming Lang: Python
  Description : Command line password manager

 Pwman3 aims to provide a simple but powerful command line interface for
 password managment. It allows to store your password in a sqlite database
 locked by a master password which can be encrypted with different
 algorithm (e.g Blowfish, AES, DES3). 
   
 It is also possible to tag them to ease searches in a large amount
 of passwords.


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

-- 
L'idée de Dieu et les religions sont source et maintien de l'ignorance,
de l'abrutissement, par conséquent de l'esclavage et de la misère.
-+- Auguste Blanqui -+-


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Stefano Zacchiroli]

On Fri, Sep 22, 2006 at 02:21:22PM -0500, John Goerzen wrote:
> I would also like to raise a question: does it make any sense to be able
> to list two URLs, one for the Debian branch and one for the upstream
> branch?

I've thought about similar issues. I made up my mind about these
questions being in the wrong direction :)

My idea for this field it to give a pointer intended for human
consumption. Once a user knows where to look, if he is willing to have
access to the repo he is probably able to discover branches, tags, learn
the repo layout and so on. If we agree on this idea I would answer no,
it doesn't make sense to me.

Alternatively we can try to fully encode in the field(s) all the
semantic information that might be needed to perform several tasks:
automatic downloading of the appropriate branch matching a given debian
release, spotting the tags matching given versions, whatever. I really
think this is a dangerous slope, we will probably be swamped in the
details of the VCS we consider.

XS-Vcs-XXX was in my mind a one-size-does-fit-all solution, assuming the
target of the information is a human. YMMV.

Cheers.

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

Re: XS-X-Vcs-XXX field not (yet) announced

[John Goerzen]

On Fri, Sep 22, 2006 at 09:02:31PM +0200, Stefano Zacchiroli wrote:
> My doubt was on the line: "who am I to suggest a non X- field to be
> added to Sources files"?  If no one has objections on the field
> XS-Vcs-XXX-Url I will add support for it and document its usage (without
> the "X-".
> 
> So, poll time:
> 
> does anyone see a problem about recommending a XS-Vcs-XXX-Url field with
> semantics "URL pointing to an XXX version control repository", intended
> to be informative for users about where to find latest source version of
> a given package?

I would also like to raise a question: does it make any sense to be able
to list two URLs, one for the Debian branch and one for the upstream
branch?

-- John


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

Bug#388569: general: always printed in letter format

[gerhard oettl]

Maybe this posting is related to this bug?




-- 
 .''`.   gerhard oettl   on   Debian/Gnu Linux
: :'  :  
`. `'`   gpg key: 1024D/D59131AA 2002-06-18
  `-


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Stefano Zacchiroli]

On Fri, Sep 22, 2006 at 08:46:51PM +0200, Florian Weimer wrote:
> If you use the X- prefix and the field gains widespread acceptance, a
> transition is needed.

Not really, being the PTS the only piece of software considering the
field it would be enough to document the non X- version and support both
in the PTS. I will be strict in what I document and relaxed in what I
accept :-)

> Debian might be able to do this in a coordinated manner, but usually,
> it's better to just omit the X- prefix from the spart.

My doubt was on the line: "who am I to suggest a non X- field to be
added to Sources files"?  If no one has objections on the field
XS-Vcs-XXX-Url I will add support for it and document its usage (without
the "X-".

So, poll time:

does anyone see a problem about recommending a XS-Vcs-XXX-Url field with
semantics "URL pointing to an XXX version control repository", intended
to be informative for users about where to find latest source version of
a given package?

Cheers.

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

Re: Policy regarding virtual packages

[Roger Leigh]

Roger Leigh <[EMAIL PROTECTED]> writes:

> Following some discussion with Marco d'Itri about inetd, I'd like to
> put forward some more general thoughts on virtual package handling for
> some comments.
>
> Currently, virtual packages (such as mail-transport-agent) cannot be
> specified by themselves.  They can only be used in combination with a
> non-virtual package which provides the default implementation.  For
> example:
>
>   Depends: exim4 | postfix | mail-transport-agent
> or
>   Depends: exim4 | mail-transport-agent
>
> This means that
>
> 1) Each package depending on a virtual package must specify a real
>package
> 2) There is no central policy defining which package is the default
>implmentation--each package could specify a different default
> 3) Changing the default is a lot of work--every reverse dependency
>must be updated.
>
> For the case of mail-transport-agent, this could be simply solved by
> the creation of a mail-transport-agent-default package.  This would
> be an empty package, doing nothing but providing this dependency:
>
>   Depends: exim4 | mail-transport-agent
>
> All packages wanting to depend on mail-transport-agent need only have
>
>   Depends: mail-transport-agent-default
>
> When exim4 becomes exim5, or some other MTA, only the
> mail-transport-agent-default package would need updating.
>
>
> For the new inet-superserver virtual package, there are potentially
> over 120 packages which would need to add
>
>   Depends: openbsd-inetd | inet-superserver
>
> However, I feel that this is too many places to hardcode the
> openbsd-inetd default (Marco d'Itri does not believe this is worth the
> effort, but I personally think that it will potentially prevent a lot
> of future effort).  Here, I think a means of specifying a
> distribution-wide default is much better than requiring each package
> to separately specify it.  For this case, I would like to create an
> inetd-default (or inet-superserver-default) package, which would
> simply be
>
>   Depends: openbsd-inetd | inet-superserver
>
> and all inetd-requiring packages would just use
>
>   Depends: inetd-default
>
> See http://people.debian.org/~rleigh/inetd-default_1.tar.gz
> and http://people.debian.org/~rleigh/inetd-default_1.dsc
>
>
> There are some other useful side-effects:
>
> Custom Debian Distributions can easily change the -default package to
> customise the distribution defaults.
>
> Example: Scott Remnant recently blogged on -planet about the "upstart"
> init/cron/inetd replacement being developed in Ubuntu.  This would
> replace openbsd-inetd, and with this scheme would require a one-line
> change to a single package.  Other CDDs might want to use other
> inetds, e.g. xinetd, or a "null" inetd which does nothing.
>
> For MTAs, other distributions might want to switch from exim4 to a
> more lightweight MTA (or even a "null" MTA for minimal systems).  This
> system would allow that to be simply and easily configured.

Was there any further discussion needed about this?

The only objection I saw was to the package naming, which I would like
to hear alternatives for (currently $virtualname-default).  I also got
one mail privately concerned that packages should still be able to
specify a particular preference should they need it; it is of course
possible to have a "preference | virtual-default" dependency.

Unless there are any valid objections, I would like to implement the
above inetd-default packages for etch.  This would require mass-filing
bugs against about 200 packages; they were listed in an earlier inetd
thread.  This would switch their current openbsd-inetd/netbase
dependencies to using inetd-default.

Implementing it for all other virtual packages would also be nice
(particularly m-t-a), but does need approval first.


Any further comments?


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


pgprq1WzfVPUi.pgp
Description: PGP signature

Re: XS-X-Vcs-XXX field not (yet) announced

[Stefano Zacchiroli]

On Fri, Sep 22, 2006 at 12:55:01PM -0500, John Goerzen wrote:
> I hadn't even thought about the reference.  That's indeed a good way to
> go, but the problem with doing that only is that existing developers
> won't learn about it very quickly.

I wasn't really sure that this might be of *that* interest to other DD,
so I didn't care in the beginning very much about quick widespreading.
Now I am a bit more sure it's of interest I'll try to fix things.

> > Feel free to help in any way you want, writing a Wiki page for example,
> > or being faster than me in submitting the whishlist bug report against
> > the developer reference :-)
> Does highlighting the topic on -devel count? ;-)

No! :-)

I'm expecting from you at the very minimum a page on wiki.d.o on the
topic; the for the assignment is a week from now :-PPppPP

Cheers.

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

Re: XS-X-Vcs-XXX field not (yet) announced

[Florian Weimer]

* Stefano Zacchiroli:

> As an answer specific for this case. The field is still an X- field,
> because I actually don't know how and if it should be standardized.

If you use the X- prefix and the field gains widespread acceptance, a
transition is needed.  Debian might be able to do this in a
coordinated manner, but usually, it's better to just omit the X-
prefix from the spart.


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

Re: Media players in Debian

[Petter Reinholdtsen]

[César Martínez Izquierdo]
> Another reason is... lots of Debian users download mplayer from
> Marillat or other sources (maybe Marillat may provide some stats)...

popcon.debian.org can provide stats.  Of 16473 machines submitting
info, 3555 (22%) have the mplayer package installed.  There are 84
packages with mplayer in the name reported, and some of the are
alternative pcakages (like mplayer-586), so the installation base for
mplayer might be higher than 22%.

I used the numbers in http://popcon.debian.org/by_inst.gz>.

Friendly,
-- 
Petter Reinholdtsen


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

Re: XS-X-Vcs-XXX field not (yet) announced

[John Goerzen]

On Fri, Sep 22, 2006 at 06:39:35PM +0200, Stefano Zacchiroli wrote:
> On Fri, Sep 22, 2006 at 11:17:56AM -0500, John Goerzen wrote:
> > This is an *excellent* idea, but a terrible way of introducing it.  Why
> > was it posted only on a blog, and not to -- at least -- debian-devel?
> > 
> > I'm growing increasingly annoyed with things that are announced only on
> > blogs and not on the Debian developer mailing lists.  (I know it wasn't
> > you, but this is a general comment.)
> 
> Please yell at me, I'm the responsible for that :-)

Well, now that you ask so nicely, I don't think I can ;-)

> As a general answer: posting to blogs is usually faster than the
> "proper" way to do things (in this case whishlist bug report + patch for
> the developers reference), that's why it is usually preferred. Of course
> this is ok only if followed by the "proper" way.

Well, I would suggest that a post to debian-devel or even d-d-a is
better than a blog post only.  There are so many posts on planet that,
even though I read it regularly, I probably miss half of them.

I hadn't even thought about the reference.  That's indeed a good way to
go, but the problem with doing that only is that existing developers
won't learn about it very quickly.

> Feel free to help in any way you want, writing a Wiki page for example,
> or being faster than me in submitting the whishlist bug report against
> the developer reference :-)

Does highlighting the topic on -devel count? ;-)

Thanks for doing this, BTW.

-- John


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

Re: Media players in Debian

[Reinhard Tartler]

Mike Hommey <[EMAIL PROTECTED]> writes:

> On Fri, Sep 22, 2006 at 01:12:02PM +0200, Reinhard Tartler <[EMAIL 
> PROTECTED]> wrote:
>> > This is pretty much the only thing stopping Debian from distributing
>> > it - it may actually be illegal [...]
>> 
>> The problematic parts regarding patents are mostly in ffmpeg, which is
>> already in debian for some time. There seem to be no problem for debian
>> redistributing ffmpeg.
>
> Note that debian's ffmpeg doesn't include encoding support for aac or
> mp3...

Interesting. Luckily, ffmpeg/mencoder is able to encode a lot more
formats, so one could assume that it should be able to stip the
''problematic'' parts.

Unfortunately, it seems quite unclear what ftpmaster currently considers
as a problem and what would need to be stripped. However, I think this
is a problem which is currently handled by the maintainers and
ftpmasters. I hope that the problematic parts will get documented
properly in debian/copyright, so that anyone interested can read about
the problems and decide themselves if they want to work on them.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: Need for darcs.debian.org?

[John Goerzen]

On Fri, Sep 22, 2006 at 07:13:54PM +0200, Luca Capello wrote:
> >
> > It could be useful, I think.  How would one push to it -- over ssh
> > or with darcs send?
> 
> ATM, for what is the CL-Debian packages I'm rsyncing my local
> repositories to the Alioth ones, because there's only one maintainer,
> me :-D
> 
> IMHO the simplest solution I can see is a push over SSH, which is what
> I successfully use for the BESE software [1] [2].

Yes, I think that would work well also.

-- John


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

Processed: Bug#388805: RFP: please package mod_auth_xradius

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> retitle 388805 RFP: please package mod_auth_xradius
Bug#388805: libapache2-mod-auth-radius missing
Changed Bug title.

> reassign 388805 wnpp
Bug#388805: RFP: please package mod_auth_xradius
Bug reassigned from package `apache2' to `wnpp'.

> severity 388805 wishlist
Bug#388805: RFP: please package mod_auth_xradius
Severity set to `wishlist' from `wishlist'

> thank you
Stopping processing here.

Please contact me if you need assistance.

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


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

Bug#388805: Info received (Bug#388805: RFP: please package mod_auth_xradius)

[Debian Bug Tracking System]

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the package maintainer(s)
and to other interested parties to accompany the original report.

Your message has been sent to the package maintainer(s):
 Debian Apache Maintainers 

If you wish to continue to submit further information on this problem,
please send it to [EMAIL PROTECTED], as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

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

Re: Need for darcs.debian.org?

[Luca Capello]

Hello!

On Fri, 22 Sep 2006 18:17:56 +0200, John Goerzen wrote:
> On Fri, Sep 22, 2006 at 03:14:02PM +0200, Luca Capello wrote:
>> one would be better, similar to the SVN one:
>> 
>>   http://darcs.debian.org/$GROUP/$PACKAGE
>> 
>> Now, the questions:
>> 
>> 1) could it be useful and will it be adopted by the
>>Darcs-maintained packages?
>
> It could be useful, I think.  How would one push to it -- over ssh
> or with darcs send?

ATM, for what is the CL-Debian packages I'm rsyncing my local
repositories to the Alioth ones, because there's only one maintainer,
me :-D

IMHO the simplest solution I can see is a push over SSH, which is what
I successfully use for the BESE software [1] [2].

`darcs send` could be useful if we want to keep track of the various
commits on a mailing list.

Moreover, we could have darcs-server or darcsweb :-)

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://common-lisp.net/project/bese
[2] http://common-lisp.net/project/ucw


pgp2D5Yt10FZy.pgp
Description: PGP signature

Re: Problem including (linux-kernel-headers 2.6.17)

[Marco d'Itri]

On Sep 21, Martin Kittel <[EMAIL PROTECTED]> wrote:

> I have no experience in this area, so I am just wondering: are
> user-space applications not supposed to include any headers below
> /usr/include/asm
Yes. The application is buggy.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Problem including (linux-kernel-headers 2.6.17)

[Hendrik Sattler]

Am Donnerstag 21 September 2006 20:09 schrieb Martin Kittel:
> In file included from /usr/include/asm-x86_64/vsyscall.h:4,
>                  from /usr/include/asm/vsyscall.h:8,
>                  from /usr/include/asm-x86_64/timex.h:11,
>                  from /usr/include/asm/timex.h:8,
>                  from RTESys_MicroTime.c:76:
> /usr/include/linux/seqlock.h:76: error: expected '=', ',', ';\
> ', 'asm' or '__attribute__' before 'unsigned'
> /usr/include/linux/seqlock.h:91: error: expected '=', ',', ';\
> ', 'asm' or '__attribute__' before 'int'

This comes from the __always_inline that is not defined. To define it, include 
linux/compiler.h
Kernel headers tend to not include all headers for the things they use, you 
magically have to find the right combination yourself.

The other errors probably have similar causes.

HS


pgp4aZtdJBK8c.pgp
Description: PGP signature

Re: Media players in Debian

[Mike Hommey]

On Fri, Sep 22, 2006 at 01:12:02PM +0200, Reinhard Tartler <[EMAIL PROTECTED]> 
wrote:
> "Andrew Donnellan" <[EMAIL PROTECTED]> writes:
> 
> > It would be great if upstream would actually care about legal issues,
> > licenses and patents in particular.
> 
> Upstream does care for legal issues, and patents in particular. Check
> the mplayer development mailing list archive for the last months.
> 
> > This is pretty much the only thing stopping Debian from distributing
> > it - it may actually be illegal [...]
> 
> The problematic parts regarding patents are mostly in ffmpeg, which is
> already in debian for some time. There seem to be no problem for debian
> redistributing ffmpeg.

Note that debian's ffmpeg doesn't include encoding support for aac or
mp3...

Mike


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

XS-X-Vcs-XXX field not (yet) announced

[Stefano Zacchiroli]

On Fri, Sep 22, 2006 at 11:17:56AM -0500, John Goerzen wrote:
> This is an *excellent* idea, but a terrible way of introducing it.  Why
> was it posted only on a blog, and not to -- at least -- debian-devel?
> 
> I'm growing increasingly annoyed with things that are announced only on
> blogs and not on the Debian developer mailing lists.  (I know it wasn't
> you, but this is a general comment.)

Please yell at me, I'm the responsible for that :-)

As a general answer: posting to blogs is usually faster than the
"proper" way to do things (in this case whishlist bug report + patch for
the developers reference), that's why it is usually preferred. Of course
this is ok only if followed by the "proper" way.

As an answer specific for this case. The field is still an X- field,
because I actually don't know how and if it should be standardized. I
posted to a blog also to see if people like it and to see how many
people will start using it now that is supported in the PTS, albeit
being an X- field. As a first sight it seems people like it, since
several guys asked me info about it.

The "proper" way of documenting it, patching the developers reference is
on my TODO list.

Feel free to help in any way you want, writing a Wiki page for example,
or being faster than me in submitting the whishlist bug report against
the developer reference :-)

Cheers.

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

Processed: Re: Processed: Re: Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> retitle 387446 amd64 system not compliant with FHS
Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Changed Bug title.

> Debian Bug Tracking System wrote:
Unknown command or malformed arguments to command.

> > Processing commands for [EMAIL PROTECTED]:
Unknown command or malformed arguments to command.

> >
Unknown command or malformed arguments to command.

> >> reassign 387446 general
Unknown command or malformed arguments to command.

> > Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Unknown command or malformed arguments to command.

Too many unknown commands, stopping here.

Please contact me if you need assistance.

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


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

Re: Need for darcs.debian.org?

[John Goerzen]

On Fri, Sep 22, 2006 at 03:14:02PM +0200, Luca Capello wrote:
> After having read zack's blog entry [2] about the new XS-X-VCS-xxx
> field for debian/control files, I was adding it to my packages [3]
> (all related to Common Lisp).

This is an *excellent* idea, but a terrible way of introducing it.  Why
was it posted only on a blog, and not to -- at least -- debian-devel?

I'm growing increasingly annoyed with things that are announced only on
blogs and not on the Debian developer mailing lists.  (I know it wasn't
you, but this is a general comment.)

> one would be better, similar to the SVN one:
> 
>   http://darcs.debian.org/$GROUP/$PACKAGE
> 
> Now, the questions:
> 
> 1) could it be useful and will it be adopted by the Darcs-maintained
>packages?

It could be useful, I think.  How would one push to it -- over ssh or
with darcs send?

I am using my own private server for this now.  Easier than to have to
deal with all the alioth overhead.



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

Problem including (linux-kernel-headers 2.6.17)

[Martin Kittel]

Hi,

I am trying to prepare packages for the new MaxDB release 7.5.00.38 and
am having problems with a new piece of code in there.

The code in question looks like this and is known to work on Suse SLES9:

...
#ifdef LINUX
#   include 
typedef SAPDB_UInt8 u64;
#   include 
#   include 
#   include 
#   define HAS_GET_CYCLES
#endif
...

However when I try to compile this with linux-kernel-headers
(2.6.17.10-3) on my amd64 box I only get a host of error messages
starting like this:

RTESys_MicroTime.c fast
In file included from /usr/include/asm-x86_64/vsyscall.h:4,
 from /usr/include/asm/vsyscall.h:8,
 from /usr/include/asm-x86_64/timex.h:11,
 from /usr/include/asm/timex.h:8,
 from RTESys_MicroTime.c:76:
/usr/include/linux/seqlock.h:76: error: expected '=', ',', ';\
', 'asm' or '__attribute__' before 'unsigned'
/usr/include/linux/seqlock.h:91: error: expected '=', ',', ';\
', 'asm' or '__attribute__' before 'int'
In file included from /usr/include/linux/cpumask.h:86,
 from /usr/include/asm-x86_64/processor.h:23,
 from /usr/include/asm/processor.h:8,
 from /usr/include/asm-x86_64/timex.h:14,
 from /usr/include/asm/timex.h:8,
 from RTESys_MicroTime.c:76:
/usr/include/linux/bitmap.h: In function 'bitmap_zero':
/usr/include/linux/bitmap.h:128: error: 'BITS_PER_LONG' undeclared \
(first use in this function)
/usr/include/linux/bitmap.h:128: error: (Each undeclared identifier is \
reported only once
... (I can provide the full output if required)

>From looking at the header files in /usr/include it seems that a lot of
types and macros used in those headers are only available to the kernel
(protected by #ifdef __KERNEL__) and to me it seems that 
cannot be successfully included by a user-space application.

I have no experience in this area, so I am just wondering: are
user-space applications not supposed to include any headers below
/usr/include/asm or is this a problem with the header files?

In any case, what MaxDB seems to try to do, is to use get_cycles() from
 for its internal timers. Is this a problem, and has it
been working for upstream just by accident, or is this ok and I should
try and get it to work on Debian?

Thanks for any help,

Martin.


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

Contact et distribution

[Sammy Nzazi]

Bonjour,  Nous avons commencé une serie d'études sur le lunix et nous voulons en faire le sytème le plus repandu dans notre pays République Démocratique du Congo. Aussi nous vous demandons de nous aider  en nous envoyant 20 cds de Linux débian car nous ne pourrons pas faire des téléchargements. Ces Cds seront recopiés et distribués gratuitement avec un minimum d'encradement d'installation et utilisation.  Car nous avons une école informatique dans notre organisation 'Eglise Chretienne' Victory Chapel.  Merci d'avance pour votre concours.  Notre Adresse :  Réverend Samy Nzazi  B.P. 498 Limete  00243 Kinshasa  République Démocratique du CONGO 
		Get your email and more, right on the  new Yahoo.com 

Processed: Re: Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 387446 general
Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Bug reassigned from package `glibc' to `general'.

> retitle 387446: amd64 system not compliant with FHS
Unknown command or malformed arguments to command.

> thanks
Stopping processing here.

Please contact me if you need assistance.

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


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

Re: new mplayer

[Luca Capello]

Hello!

Cc:ing directly Andrea and Dariush (the Debian maintainer) to be sure
they read my post, hope you don't mind.

On Thu, 21 Sep 2006 15:36:16 +0200, A Mennucc wrote:
> I prepared a new mplayer (with help from  Diego Biurrun of the
> mplayer team)

From the package description:

Mplayer is a movie player for LINUX.
.
NOTE: the .tar.gz distributed with Debian does not contain all of the upstream
code. Read README.Debian and copyright for details.
.
MPlayer plays most MPEG, VOB, AVI, OGG/OGM, VIVO,
ASF/WMA/WMV, QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA files,
supported by many native, XAnim, RealPlayer, and Win32 DLL codecs. You can
watch VideoCD, SVCD, DVD, 3ivx, RealMedia, and DivX movies too.
.
Another big feature of MPlayer is the wide range of supported output
drivers.  It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev,
AAlib(*), DirectFB, but you can also use SDL and GGI(*) (and this way
all their drivers) and some lowlevel card-specific drivers (for
Matrox, 3Dfx and Radeon, Mach64, Permedia3) too!  Most of them
supports software or hardware scaling, so you can enjoy movies in
fullscreen.  MPlayer supports also displaying through some hardware MPEG
decoder boards, such as the DVB and DXR3/Hollywood+.
(*) GGI and  AAlib are not currently compiled by default.
=

Some hints:

1) please add the upstream homepage at the end, as per the Developer
   Reference paragraph 6.2.4 [1], like
   =
   [...]
   (*) GGI and  AAlib are not currently compiled by default.
   .
Homepage: http://www.mplayerhq.hu
   =

2) the second paragraph could be better wrapped, especially compared
   to the third one
   =
   .
   MPlayer plays most MPEG, VOB, AVI, OGG/OGM, VIVO, ASF/WMA/WMV,
   QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA files,
   supported by many native, XAnim, RealPlayer, and Win32 DLL codecs.
   You can watch VideoCD, SVCD, DVD, 3ivx, RealMedia, and DivX movies too.
   =

3) I'd put the NOTE paragraph at the end of the description, but AFAIK
   there's no consensus on this as I could see from the output of
   `grep-aptavail -FDescription NOTE`

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-upstream-info


pgpFEZ9BM2kUg.pgp
Description: PGP signature

Re: new mplayer

[Josselin Mouette]

Le jeudi 21 septembre 2006 à 10:00 -0600, Joseph Smidt a écrit :
> 
> 
> On 9/21/06, A Mennucc <[EMAIL PROTECTED]> wrote:
> hi
> 
> this mplayer does not contain 'mencoder' the legal status
> of mencoder is not clear enough to include it into Debian
> 
> Thanks for letting me know.  In that case  I will have to look to
> third party stuff. :(

The ffmpeg Debian package has probably all you need to encode videos.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: new mplayer

[Joseph Smidt]

On 9/21/06, A Mennucc <[EMAIL PROTECTED]> wrote:
hithis mplayer does not contain 'mencoder' the legal statusof mencoder is not clear enough to include it into Debian
Thanks for letting me know.  In that case  I will have to look to third party stuff. :(

                              Joseph Smidt 
-- -   Joseph Smidt [EMAIL PROTECTED]

Need for darcs.debian.org?

[Luca Capello]

Hello!

Croos-posting to d-d and the CL-Debian mailing list to let it know
about my post, but please answer only on d-d (I set M-F-T and R-T
accordingly).

After having read zack's blog entry [2] about the new XS-X-VCS-xxx
field for debian/control files, I was adding it to my packages [3]
(all related to Common Lisp).

Now, most of the CL-Debian packages are Darcs-maintained, with
repositories like the following:

  http://cl-debian.alioth.debian.org/repository/$MAINT/$PACKAGE

While I'm fine with the string above, I'm wondering if a more general
one would be better, similar to the SVN one:

  http://darcs.debian.org/$GROUP/$PACKAGE

Now, the questions:

1) could it be useful and will it be adopted by the Darcs-maintained
   packages?

2) has someone already proposed it?  The only reference I could found
   is from a post to d-d by George Danchev [4].

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://cl-debian.alioth.debian.org
[2] http://www.bononia.it/~zack/blog//posts/xs-x-vcs-XXX.html
[3] http://qa.debian.org/[EMAIL PROTECTED]
[4] http://lists.debian.org/debian-devel/2006/07/msg00853.html


pgpEFieLKwCMy.pgp
Description: PGP signature

Re: gfdl gcc documentation packages for non-free: update

[Marco d'Itri]

On Sep 21, Matthias Klose <[EMAIL PROTECTED]> wrote:

>  - the man pages (all except gfortran.1) are not built from
>source. -> RC
As long as the source is available in the package this is not a bug at
all.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: new mplayer

[Joseph Smidt]

I understand the freeze is probably too soon, but I need mplayer for making
movies I need for my physics research.  Please allow this mplayer into Etch.
-- -   Joseph Smidt [EMAIL PROTECTED]

Bug#388613: ITP: libnfnetlink -- Netfilter netlink library

[Max Kellermann]

Package: wnpp
Severity: wishlist
Owner: Max Kellermann <[EMAIL PROTECTED]>

* Package name: libnfnetlink
  Version : 0.0.16
  Upstream Author : Netfilter Core Team <[EMAIL PROTECTED]>
* URL : http://www.netfilter.org/projects/libnfnetlink/
* License : GPL
  Description : Netfilter netlink library

libnfnetlink is a lowlevel C library which helps accessing the
netfilter netlink layer in the kernel.


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

Re: Media players in Debian (was: new mplayer)

[César Martínez Izquierdo]

On 9/22/06, Josselin Mouette <[EMAIL PROTECTED]> wrote:

Le vendredi 22 septembre 2006 à 12:29 +0200, César Martínez Izquierdo a
écrit :
> I could never see a whole film using Totem or VLC (from Debian).

I don't remember seeing your bug report, could you point me to the bug
number please?


First of all, I don't have time to send bug reports for all the bugs I
find (although I send most of them, when I have to choose I send to
packages which I usually use).
Specially, when I want to see a film, I really want to see the film at
that moment, not after sending some bug reports.

Second, if I'm see a not original film, whose legality is at least
doubtful in some countries, and the player crashes, probably I don't
want to send a bug report about that.

Maybe my fault, anyway...
Regards,

César

Bug#388614: ITP: libnetfilter-conntrack -- Netfilter netlink-conntrack library

[Max Kellermann]

Package: wnpp
Severity: wishlist
Owner: Max Kellermann <[EMAIL PROTECTED]>

* Package name: libnetfilter-conntrack
  Version : 0.0.31
  Upstream Author : Pablo Neira Ayuso <[EMAIL PROTECTED]>
* URL : http://www.netfilter.org/projects/libnetfilter_conntrack/
* License : GPL
  Description : Netfilter netlink-conntrack library

libnetfilter_conntrack is a userspace library providing a programming
interface (API) to the in-kernel connection tracking state table.


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

Bug#388620: ITP: drapes -- a desktop wallpaper managment application for the GNOME desktop

[Francesco Namuri]

Package: wnpp
Severity: wishlist
Owner: Francesco Namuri <[EMAIL PROTECTED]>


* Package name: drapes
  Version : 0.4.97
  Upstream Author : Milosz Tanski <[EMAIL PROTECTED]>
* URL : http://drapes.mindtouchsoftware.com/
* License : GPL
  Programming Lang: C#
  Description : a desktop wallpaper managment application for the GNOME 
desktop

 the aim of drapes is to compliment (replace) the built in GNOME desktop
 wallpaper selection tool. It can be configured as a tray application or as a
 panel applet. The bigest selling point of drapes is ability to rotate wallapers
 on a timely basis. It strives to be as simple as possible and fit in the rest
 of the GNOME 2 desktop.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (850, 'unstable'), (750, 'testing'), (200, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-custom.2
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)


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

Re: Media players in Debian (was: new mplayer)

[Chris Lamb]

On Fri, 22 Sep 2006 13:03:44 +0200, Steinar H. Gunderson wrote:
> I've heard these claims (“player X should be more than good enough,
> what do you need mplayer for these days?”) for at least the last five
> years

Not, "This cannot be played on record^Hmedia player X" ?


Tortoise


-- 
 Chris Lamb, Cambs, UK  WWW: http://chris-lamb.co.uk
  Q. Why is top posting bad? GPG: 0x634F9A20
  A. Because it breaks the logical sequence of discussion


signature.asc
Description: PGP signature

Bug#388615: ITP: conntrack -- Program to modify the netfilter conntrack tables

[Max Kellermann]

Package: wnpp
Severity: wishlist
Owner: Max Kellermann <[EMAIL PROTECTED]>

* Package name: conntrack
  Version : 1.00~beta2
  Upstream Author : Pablo Neira Ayuso <[EMAIL PROTECTED]>
* URL : http://www.netfilter.org/projects/conntrack/
* License : GPL
  Description : Program to modify the netfilter conntrack tables

conntrack is a userspace command line program targeted at system
administrators. It enables them to view and manage the in-kernel
connection tracking state table.


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

Bug#388586: /etc/profile contains PATH=/usr/bin/X11...

[Sam Morris]

reassign 388586 base-files
found 388586 3.1.16
thanks

/etc/profile is installed by the postinst of the base-files package;
reassigning appropriately.

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


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

Processed: re: /etc/profile contains PATH=/usr/bin/X11...

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 388586 base-files
Bug#388586: /etc/profile contains PATH=/usr/bin/X11...
Bug reassigned from package `general' to `base-files'.

> found 388586 3.1.16
Bug#388586: /etc/profile contains PATH=/usr/bin/X11...
Bug marked as found in version 3.1.16.

> thanks
Stopping processing here.

Please contact me if you need assistance.

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


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

Re: Media players in Debian (was: new mplayer)

[Josselin Mouette]

Le vendredi 22 septembre 2006 à 12:29 +0200, César Martínez Izquierdo a
écrit :
> I could never see a whole film using Totem or VLC (from Debian).

I don't remember seeing your bug report, could you point me to the bug
number please?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Media players in Debian (was: new mplayer)

[Andreas Tille]

On Fri, 22 Sep 2006, Steinar H. Gunderson wrote:


I've heard these claims (ÿÿplayer X should be more than good enough, what do
you need mplayer for these days?ÿÿ) for at least the last five years -- it's a
difficult claim to refute, since people have rather different viewing habits,
different platforms and different needs. For _my_ part, I've still not seen
any player that works remotely as reliably over a wide range over file
formats and various brokenness as mplayer does.


And, BTW, do we really need Emacs if we have vi?



 Andreas.

--
http://fam-tille.de

Re: Media players in Debian

[Reinhard Tartler]

"Andrew Donnellan" <[EMAIL PROTECTED]> writes:

> It would be great if upstream would actually care about legal issues,
> licenses and patents in particular.

Upstream does care for legal issues, and patents in particular. Check
the mplayer development mailing list archive for the last months.

> This is pretty much the only thing stopping Debian from distributing
> it - it may actually be illegal [...]

The problematic parts regarding patents are mostly in ffmpeg, which is
already in debian for some time. There seem to be no problem for debian
redistributing ffmpeg.

Other maybe problematic parts are in libdvdcss, which has been strpped
off in the proposed mplayer package.

Honestly, I don't know what problems remain problems regarding mplayer,
but claiming that mplayer upstream did not care about copyright and
patent issue is straight wrong and does only spread FUD. Please help to
improve the situation by mentioning concrete remaining problems.


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

it`s all about SOFT Lucienne

[Mui]

Want to see something shocking?

Everyone knows it's embarressing for people to talk with their physician about 
their or their partners private "issues". Well, you
don't need to be embarressed. We can offer the pill right to your door and at 
about one third of the cost.

We have hundreds of thousands of happy couples who changed their marriages. If 
you want to take a look, please check
up the site below. You'll be quite impressed:

http://meddu.com>.qqdckini3zjzpiz4cczexunhucu.dashesnp.cc







collar future



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

Bug#388569: general: always printed in letter format

[gregor herrmann]

On Thu, 21 Sep 2006 11:13:27 +0200, gerhard oettl wrote:

> Since updating to etch some weeks ago i was not able to print
> from firefox, because always letter format is requested on the
> printer panel.

Do you have /etc/papersize and what is its content?

$ cat /etc/papersize 
a4
$ 

Cf. also man papersize

gregor 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian: the universal operating system - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: Eagles: Desperado


signature.asc
Description: Digital signature

Re: Media players in Debian (was: new mplayer)

[Steinar H. Gunderson]

On Fri, Sep 22, 2006 at 11:12:10AM +0200, Petter Reinholdtsen wrote:
> And I agree, the tools in Debian are quite good, and I am not sure if
> mplayer have much extra to offer these days. 

I've heard these claims (“player X should be more than good enough, what do
you need mplayer for these days?”) for at least the last five years -- it's a
difficult claim to refute, since people have rather different viewing habits,
different platforms and different needs. For _my_ part, I've still not seen
any player that works remotely as reliably over a wide range over file
formats and various brokenness as mplayer does.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: new mplayer

[Reinhard Tartler]

Yavor Doganov <[EMAIL PROTECTED]> writes:

> I was wondering, what's so important about mplayer?  With totem and
> vlc (and I anticipate there's something similar for KDE) you have
> everything you need.  I've never tried mplayer and I don't know how it
> looks or what it does, so that's just my uneducated guess.

Mplayer is important for a couple of reasons. A really lot of modern
video and audio formats is supported by ffmpeg, which is already in
debian. There is a big overlap of mplayer and ffmpeg developers, and
mplayer tracks ffmpeg development very closely.

It is hard for outsiders to understand why mplayer is (supposely) not
acceptable for debian, while xine, vlc, and even ffmpeg have been in
debian for a very long time. Mplayer is great and free software, and
really pushes development for free (as in speach) modern multimedia
codecs. I think it would be a great win to have mplayer in debian.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: gfdl gcc documentation packages for non-free: update

[Nikita V. Youshchenko]

> Nikita V. Youshchenko writes:
> > Hello.
> >
> > I've updated gcc-4.1 documentation packages (Section: non-free/doc).
> > Packages are no longer debian-native, also several issues have been
> > fixed.
> >
> > Also, I've created gcc-doc-defaults package (Section: contrib/doc)
> > that builds gcc-doc, cpp-doc, gfortran-doc and treelang-doc packages
> > with proper dependences and symlinks.
> >
> > Maintainer of all those packages is set to debian-gcc@lists.debian.org
> >
> > As for over version of gcc - packages for those that are currently in
> > sid still contain gfdl documentation. So creation of proper non-free
> > packages has to be postponed until this documentation is not removed
> > from there.
> >
> > Currently packages are at
> > http://zigzag.lvk.cs.msu.su/~nikita/debian/gcc-doc/
> >
> > I'm going to upload there (to non-free and contrib) in a day or two.
> > Comments welcome.
>
> some problems:
>
>  - the man pages (all except gfortran.1) are not built from
>source. -> RC

Most manpages are available as is in upstream tarball - so I decided to use 
those unmodified. Fortran manpage was not there - so I had to build it.

If that's a problem, all may be made built from texi source, that should be 
simple.

>  - the gfdl is not included in the man pages, nor the gfdl(7) man
>pages are shipped, violating the GFDL (dropping invariant
>sections). -> RC

What is the best approach to handle this? Include full gfdl text in 
debian/copyright? Depend on a package that will provide gfdl.7 (or 
maybe /usr/share/common-licenses/GFDL)?

>  - the java man pages are not built
>
>  - the libstdc++ docs are not built

I've checked which files are in package set build from gcc-4.1 4.1.1-10, 
but are not in files built from gcc-4.1 4.1.1ds1-13 source.

Probably java stuff is built from different source - so additional source 
package is needed for it's docs?

As for libstdc++, looks like you do still provide all docs in 
libstdc++6-doc 4.1.1ds1-13 package?

>  - the man pages are not up to date. you have to apply the patches
>from our sources.

This could be done I guess.

> for an alternative approach (somebody did volunteer to do that, but I
> never heard again from this developer):
>
>  - put the doc files from
>http://people.debian.org/~doko/gcc-4.1/gcc-4.1.1-doc.tar.bz2
>in a source tarball.
>
>  - build-depend on gcc-4.1-source (including the -doc patches),
>build the package (bootstrap_target=all), then just package
>the documentation.

I don't know if this approach is better or not. Won't it take much longer 
to build/test/...?

I did the doc package in the form I did it because:
- there is currently no gcc docs in debian, which I consider a fatal 
problem (in my personal rating, it's much more RC than most of "official" 
RC bugs)
- enough time has passed since gcc docs have been removed, and there is no 
visible activity to provide it
- etch release is near, so etch release without gcc docs starts to look 
very probable. For me, that will mean that I will have to stop recommend 
Debian for people with whom I work - and then maybe to switch from Debian 
myself, because it is too difficult to support non-very-technical perople 
on distribution other than you use. I don't like this scenario at all.

So I did the minimal packaging, and will try to fix at least the required 
minimum of issues so etch will include those (in non-free and contrib 
sections). Btw, thanks for reports.

If anybody else wishes to create or maintain or co-maintain gcc docs 
packages, using mine or your or any other approach, I have nothing 
against. Just the opposite. I have bad and hopeless problems with free 
time. All free software - related plans and ideas, even simple ones, are 
frozen already for months. I'm doing gcc-doc packages only because I don't 
see anybody else working on this problem, which I consider critical.

Nikita


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

Re: Media players in Debian (was: new mplayer)

[George Danchev]

On Friday 22 September 2006 13:29, César Martínez Izquierdo wrote:
> I could never see a whole film using Totem or VLC (from Debian).

That is interesting assertion. I have very good experience with vlc here.
Did you report your issue to the BTS ?

> I do, with mplayer (from Marillat).

In fact, I've never felt a need to use these, so I can't comment on these.

> I think this is enough reason to include Mplayer in Debian.

Are you sure it is not patent encumbered ? Debian is quite a large and 
attractive target to attack for various infringements.

I haven't looked at mplayer svn for quite some time so I can't be sure what 
the latest developments are.

> Another reason is... lots of Debian users download mplayer from
> Marillat or other sources (maybe Marillat may provide some stats)...
> users are not stupid, if lots of them do an extra effort to get a
> program which is not in Debian, you can be sure the program is better
> in some way.

In fact yes, that was my case in the past. Here is what I've used back then 
[1], when upstream used to use CVS, thus you might want to adjust that for 
their SVN now. But since as I already said I'm perfectly fine with vlc and 
didn't feel the need to use that anymore.

[1] svn co http://svn.openfmi.net/debian-addons-bg/mplayer-builder/trunk

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: Media players in Debian (was: new mplayer)

[César Martínez Izquierdo]

On 9/22/06, Josselin Mouette <[EMAIL PROTECTED]> wrote:

Le vendredi 22 septembre 2006 à 11:19 +0200, Bartosz Fenski aka fEnIo a
écrit :
> Mplayer comes with his friend mencoder. I doubt that koffeine, totem, xine,
> vlc have something to offer in that regard.

VLC does, and we also have ffmpeg for command-line encoding.

GStreamer in Debian currently doesn't support encoding, but it would
become possible if it was built against Debian's ffmpeg (which requires
quite some work).
--
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom



I could never see a whole film using Totem or VLC (from Debian).
I do, with mplayer (from Marillat).
I think this is enough reason to include Mplayer in Debian.

Another reason is... lots of Debian users download mplayer from
Marillat or other sources (maybe Marillat may provide some stats)...
users are not stupid, if lots of them do an extra effort to get a
program which is not in Debian, you can be sure the program is better
in some way.

Re: Debian cares more about documents than people

[George Danchev]

On Friday 22 September 2006 00:42, alfredo diega wrote:
> On 9/21/06, Thaddeus H. Black <[EMAIL PROTECTED]> wrote:
> >   I ask you, is that
> > fair?
>
> Well, I guess it isn't fair.  Look, have any of you ever sent an email out
> of
> frustration, then wish you could take it back?  I am sorry, I hope somebody
> will forgive me.
>
> I just need to loose my pride and switch to Ubuntu.  I haven't and I know
> the
> LUG here will laugh at me and tell me "We told you so" but what you say is
> true.  Different goals.  What I was telling my friends was I wanted to use
> the best community distro based on free software out there.  I thought it 

If you think it is community based distro, and you want more frequent stable 
releases (say, one release per year, i.e. every December before the Christmas 
holidays ;-) then you might want to help to keep testing (resp. unstable) as 
close as possible to a reasonable releaseable state. This means sending 
decent bugreports, patches, etc. ... that should be community-made I belive, 
and not just shouting out 'oh, can't wait, your old software doesn't not 
support my new hardware'.

> was Debian and maybe it still is but I guess I need to ask myself:  What is 
> the best community distro based on free software that isn't so free that it 
> doesn't work.  I guess that right now is Ubuntu.

Will you approach ubuntu's mailing lists the same way when next Debian Stable 
got released with much more current software than the latest Ubuntu Stable 
release ?

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: gfdl gcc documentation packages for non-free: update

[Josselin Mouette]

Le jeudi 21 septembre 2006 à 14:32 +0200, Matthias Klose a écrit :
>  - build-depend on gcc-4.1-source (including the -doc patches),
>build the package (bootstrap_target=all), then just package
>the documentation.

If the source packages still contain some GFDL documents, then this is a
RC bug.

The DFSG don't apply only to binary packages.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Media players in Debian (was: new mplayer)

[Josselin Mouette]

Le vendredi 22 septembre 2006 à 11:19 +0200, Bartosz Fenski aka fEnIo a
écrit :
> Mplayer comes with his friend mencoder. I doubt that koffeine, totem, xine,
> vlc have something to offer in that regard.

VLC does, and we also have ffmpeg for command-line encoding.

GStreamer in Debian currently doesn't support encoding, but it would
become possible if it was built against Debian's ffmpeg (which requires
quite some work).
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Media players in Debian (was: new mplayer)

[Andrew Donnellan]

On 9/22/06, Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> wrote:

Yes, I know there won't be w32codecs package in Debian, but even mplayer
would be great addition.


It would be great if upstream would actually care about legal issues,
licenses and patents in particular. This is pretty much the only thing
stopping Debian from distributing it - it may actually be illegal and
while Marillat is probably too small a target to sue, the Debian
project may be large enough.

--
Andrew Donnellan
http://andrewdonnellan.com
http://ajdlinux.blogspot.com
Jabber - [EMAIL PROTECTED]
GPG - hkp://subkeys.pgp.net 0x5D4C0C58
---
Member of Linux Australia - http://linux.org.au
Debian user - http://debian.org
Get free rewards - http://ezyrewards.com/?id=23484
OpenNIC user - http://www.opennic.unrated.net


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

Re: Media players in Debian (was: new mplayer)

[Bartosz Fenski aka fEnIo]

On Fri, Sep 22, 2006 at 11:12:10AM +0200, Petter Reinholdtsen wrote:
> > I was wondering, what's so important about mplayer?  With totem and
> > vlc (and I anticipate there's something similar for KDE) you have
> > everything you need.
> 
> I believe kaffeine is the totem equivalent for KDE.  And I agree, the
> tools in Debian are quite good, and I am not sure if mplayer have much
> extra to offer these days.  There is the question of libdvdcss2 (for
> DVD playing) and some codeces missing, but the situation is improving
> there too. :) There is also gnash, the flash player.  It is able to
> run quite a few flash files, but lack video support still.

Mplayer comes with his friend mencoder. I doubt that koffeine, totem, xine,
vlc have something to offer in that regard.

And if I can't play something with vlc I'm almost sure it's playable with
mplayer + w32codecs.

Yes, I know there won't be w32codecs package in Debian, but even mplayer
would be great addition.

regards
fEnIo

-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

Media players in Debian (was: new mplayer)

[Petter Reinholdtsen]

[Yavor Doganov]
> I was wondering, what's so important about mplayer?  With totem and
> vlc (and I anticipate there's something similar for KDE) you have
> everything you need.

I believe kaffeine is the totem equivalent for KDE.  And I agree, the
tools in Debian are quite good, and I am not sure if mplayer have much
extra to offer these days.  There is the question of libdvdcss2 (for
DVD playing) and some codeces missing, but the situation is improving
there too. :) There is also gnash, the flash player.  It is able to
run quite a few flash files, but lack video support still.

Friendly,
-- 
Petter Reinholdtsen


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

Re: Third and final call for votes for the assets handling constitutional amendment GR

[Frederik Schueler]

> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> b7af2494-93e2-490e-9312-85647b0928b3
> [ 1  ] Choice 1: Amend the constitution  [needs 3:1]
> [ 2  ] Choice 2: Further discussion
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

-- 
ENOSIG


signature.asc
Description: Digital signature

Re: gfdl gcc documentation packages for non-free: update

[Matthias Klose]

Nikita V. Youshchenko writes:
> Hello.
> 
> I've updated gcc-4.1 documentation packages (Section: non-free/doc).
> Packages are no longer debian-native, also several issues have been fixed.
> 
> Also, I've created gcc-doc-defaults package (Section: contrib/doc) that 
> builds gcc-doc, cpp-doc, gfortran-doc and treelang-doc packages with 
> proper dependences and symlinks.
> 
> Maintainer of all those packages is set to debian-gcc@lists.debian.org
> 
> As for over version of gcc - packages for those that are currently in sid 
> still contain gfdl documentation. So creation of proper non-free packages 
> has to be postponed until this documentation is not removed from there.
> 
> Currently packages are at 
> http://zigzag.lvk.cs.msu.su/~nikita/debian/gcc-doc/
> 
> I'm going to upload there (to non-free and contrib) in a day or two.
> Comments welcome.

some problems:

 - the man pages (all except gfortran.1) are not built from
   source. -> RC

 - the gfdl is not included in the man pages, nor the gfdl(7) man
   pages are shipped, violating the GFDL (dropping invariant
   sections). -> RC

 - the java man pages are not built

 - the libstdc++ docs are not built

 - the man pages are not up to date. you have to apply the patches
   from our sources.

for an alternative approach (somebody did volunteer to do that, but I
never heard again from this developer):

 - put the doc files from
   http://people.debian.org/~doko/gcc-4.1/gcc-4.1.1-doc.tar.bz2 
   in a source tarball.

 - build-depend on gcc-4.1-source (including the -doc patches),
   build the package (bootstrap_target=all), then just package
   the documentation.

Matthias


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

Bug#388586: /etc/profile contains PATH=/usr/bin/X11...

[Dan Jacobson]

Package: general
Severity: minor

$ reportbug -f /etc/profile
Finding package for '/etc/profile'...
No packages match.
No package specified; stopping.

1. No way to tell how /etc/profile got on my system.

2. All I know is it contains
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games"
and /usr/bin/X11 is merged so should be deleted.
-- System Information:
Debian Release: testing/unstable


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

Re: Bug#387385: ITP: shed -- Hex editor using ncurses, with a friendly pico-style interface

[Alex Sisson]

> No, a bug (or rather, doesn't meet a release goal):

> | And these release goals currently:
> | - pervasive LFS (large files) support

>
http://lists.debian.org/debian-devel-announce/2006/07/>
msg5.html

Okeydokey. will look into ading this.

alex the shed author




___ 
Inbox full of spam? Get leading spam protection and 1GB storage with All New 
Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html


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