Re: System users and valid shells...

[Javier Fernández-Sanguino Peña]

On Mon, May 08, 2006 at 09:04:35AM +0200, Marc Haber wrote:
> On Fri, 05 May 2006 11:12:35 +0300, Jari Aalto <[EMAIL PROTECTED]>
> wrote:
> >Richard A Nelson <[EMAIL PROTECTED]> writes:
> >> On Wed, 3 May 2006, Colin Watson wrote:
> >> The rest of the system accounts are happily running with /bin/false
> >
> >There is now /bin/nologin which is more secure
> 
> You can surely explain why /bin/nologin is more secure than
> /bin/false. I'm eager to learn.

Not "more secure" but it definately provides some accountability (i.e. log
traces) in case those accounts get used. At least by those services that
might spawn a shell, that is. Use of /dev/null or /bin/false will not get
logged so you might not be able to detect (through a logchecker tool such as
logcheck) suspicious activity.

Regards

Javier


signature.asc
Description: Digital signature

Re: System users and valid shells...

[Javier Fernández-Sanguino Peña]

On Mon, May 08, 2006 at 01:36:14AM +0200, Uwe Hermann wrote:
> 
> Or does such a thing already exist?

Not that I know of, such a report might be interesting...

Regards

Javier


signature.asc
Description: Digital signature

Intent to hijack Bacula

[John Goerzen]

Hello,

I intend to take over the Bacula package.  I would first like to say
thanks to Jose Luis Tallon for initially packaging it for Debian and
maintaining it for these years.

A brief history of why I intend to do this:

 * Bacula has had RC bugs open for more than a year.  It was removed
   from testing several months ago because of this.

 * Bacula's current maintainer is not a Debian Developer and has been
   in NM since 2003.

 * Bacula as it currently exists in sid is unbuildable and
   uninstallable.  Bacula will not be present in etch unless significant
   problems are fixed.

 * The last upload for Bacula was almost a year ago.

 * The maintainer has repeatedly, over the last year, said he's working
   on this but hasn't made much real progress, and has made no upload to
   Debian.

 * Several additional critical-level or grave-level unreported bugs
   exist in the bacula Debian source tree (such as stopping database servers
   without permission and deleting files un-owned by a particular
   package)

 * There are various policy compliance issues with the current packages.

 * The current maintainer does respond to pings, but has a long record
   of problems getting bugs (even RC bugs) fixed in a timely fashion.
 
I have already prepared an NMU that fixes 22 bugs, including all four RC
bugs.  I have tagged those bugs as pending.  This release is currently
sitting in NEW.  I also prepared subsequent NMUs that fix critical, but
unreported, bugs in the Debian Bacula packages.

Fixing the rest of the problems with Bacula requires a level of work
that is not really appropriate for an NMU.  I have discussed the
situation with Jose's AM, Stephen Frost, who encouraged me to hijack the
package.  I have also discussed the situation on #debian-devel, and
consensus there seemed to be that a hijack was warranted.

Finally, I should add that we intend to use Bacula at my workplace and
have made the fixes already made to Bacula as part of my job.  We will
be using it in a production environment, and I do not want to do that
until I can trust the Bacula packages to work right.  We will be backing
up 2-5TB of data across Debian, AIX, and Windows servers to a 48-tape
LTO3 library.  In short, I will be maintaining working Bacula packages
anyway, and I might as well upload them to Debian.

I also e-mailed Jose about the situation, offering to adopt Bacula, on
April 27, but have not yet received a reply to that message.

-- John


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

Bug#366547: ITP: xmlrpc++ -- XML-RPC library for C++

[Ondřej SurÃœ]

Package: wnpp
Severity: wishlist
Owner: "Ondřej Surý" <[EMAIL PROTECTED]>

* Package name: xmlrpc++
  Version : 20040713
  Upstream Author : Chris Morley
* URL : http://sourceforge.net/projects/xmlrpcpp/
* License : LGPL
  Programming Lang: C++
  Description : XML-RPC library for C++

 XmlRpc++ is a C++ implementation of the XML-RPC protocol. It is
 based upon Shilad Sen's excellent py-xmlrpc. The XmlRpc protocol
 was designed to make remote procedure calls easy: it encodes data
 in a simple XML format and uses HTTP for communication. XmlRpc++
 is designed to make it easy to incorporate XML-RPC client and server
 support into C++ applications.

-- 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.15-22-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)

Re: patching a package?

[Joe Smith]

"Lionel Elie Mamane" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]


apt-get source ${PACKAGE}
cp -R ${PACKAGE}-${VERSION} ${PACKAGE}-${VERSION}.pristine-deb
cd ${PACKAGE}-${VERSION}
# hack away
cd ..
diff --recursive -u ${PACKAGE}-${VERSION}.pristine-deb 
${PACKAGE}-${VERSION} > descriptive_name.patch

#(add -N option to diff if appropriate)
#send descriptive_name.patch to the maintainer, probably through a bug
#report.


Um... the person wanted to build a deb and install it for testing. You 
should add those to the list of commands. 




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

Bug#366554: ITP: cdck -- verifies the quality of written CDs/DVDs

[gregor herrmann]

Package: wnpp
Severity: wishlist
Owner: gregor herrmann <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: cdck
  Version : 0.5.2
  Upstream Author : Alexey Semenoff>
* URL : http://swaj.net/unix/index.html#cdck
* License : GPL (2 or later)
  Programming Lang: C++
  Description : verifies the quality of written CDs/DVDs

 cdck (CD/DVD check tools) is a simple console program to verify CD/DVD
 quality. The known fact is that even if all files on the disc are readable,
 some sectors having bad timing can easily turn into unreadable ones in the
 future.
 .
 To get an idea about a disc cdck reads it sector by sector, keeping
 all reading timings and then tells you its verdict. Optionally it
 can write the timing table into text file usable by gnuplot(1)
 program, so you can draw some graphs out of it.


Additional comment:
qpxtool does something similar, but it depends on the used drive and
it needs X. cdck works on all discs/drives and is a console
application.


gregor


- -- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'experimental'), (500, 'testing'), (500, 
'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.200605061601
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEYME3OzKYnQDzz+QRAisWAKDZyNEHSLSR4M1EpdKIaCATXQMvWwCePZHX
wtKB9mzU3laMwkdl0gLcgbo=
=5L0d
-END PGP SIGNATURE-


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

Re: patching a package?

[The Fungi]

On Tue, May 09, 2006 at 08:03:32AM +0200, Lionel Elie Mamane wrote:
> On Mon, May 08, 2006 at 11:32:38PM -0500, Jason D. Clinton wrote:
[...]
> > I want to take a Debian source package and make a few changes to do
> > it and then recompres it and test it. If it works I want to generate
> > a patch which I can send to the maintainer. What would be the best
> > way to do this?
> 
> apt-get source ${PACKAGE}
> cp -R ${PACKAGE}-${VERSION} ${PACKAGE}-${VERSION}.pristine-deb
> cd ${PACKAGE}-${VERSION}
> # hack away
[...]

Some other helpful bits since your "then recompres it and test it"
wasn't really addressed... You'll probably want to install the
devscripts and fakeroot packages (if you haven't already) and see
the manpage for debuild, but in short you probably want something
like:

   debuild -rfakeroot -b -uc -us
   sudo dpkg -i ../*.deb
   # test away

Added a Cc/MFT debian-user, as these sorts of questions are probably
more appropriate there.
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }


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

Re: PDF files and dh_compress

[Yaroslav Halchenko]

Dear Developers,

I've raised this discussion at -mentors first [1] but I think it is worth
asking on a devel list since no definite decision was reached and I
could not find similar discussion in the archives.

I've got annoyed enough by compressed pdf.gz in -doc packages
that I decided to check if that is required (deb pol, or dev ref?)
and/org common practice.

The facts are:

* the policy states in 12.3 Additional documentation:

 *Text documentation* should be installed in the directory
  /usr/share/doc/package, where package is the name of the package, and
   compressed with gzip -9 unless it is small.
 
 My take on that is that "text documentation" referred to uncompressed
 text files which definitely should be compressed. But PDF can be
 referred as text documentation with the same success as png with text
 in it.
 
* dh_compress doesn't compress some other files based on extension
  including .zip files. PDF (to my knowledge) uses zip internally to
  compress the document. So why PDF should be gzipped if .zip not?

* Although there is  a way to view pdf.gz without explicit decompression
  (use see or xzpdf) it is inconvenient for being used from firefox for
  instance (?)

* There is no general agreement of either PDF should be gzipped or not.
  There are 1250 pdf and 1068 pdf.gz file shipped with sid distribution
  (please see [2] for more details). Possible reasons for present
  disagreement is due to the lack of clear statement in the policy
  or in dev reference or best practices. Also I believe neither lintian
  nor linda warns about present pdf or pdf.gz files
  
* If we decide to allow pdf being installed uncompressed (which would be
  my wish) we would occupy additional 153M to current 299M (see [2]) on
  all of them on a sid system. If we rule opposite -- to keep them all
  in .gz, then we would free up 50M.

Now the questions are:

* Should we enforce the single way (pdf vs pdf.gz), or keep as it is now
  without any agreement and up to the maintainer?
 
* Is there already a clear policy/dev-ref/practices statement on how to
  deal with PDFs? Should we make such?

* If we should enforce one way, shouldn't we adjust linda/lintian rules
  to inform the maintainer?

* May be there is a way for facsimile re-compression of the existing PDFs
  with higher compression ratio?


Thank you in advance

[1] http://lists.debian.org/debian-mentors/2006/05/msg00098.html
[2] http://www.onerussian.com/Linux/questions/pdf.sid.ia64.txt
-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]




pgpU7UFggoqj2.pgp
Description: PGP signature

Re: PDF files and dh_compress

[Eduard Bloch]

#include 
* Yaroslav Halchenko [Tue, May 09 2006, 01:15:54PM]:
> Dear Developers,
> 
> I've raised this discussion at -mentors first [1] but I think it is worth
> asking on a devel list since no definite decision was reached and I
> could not find similar discussion in the archives.

I am strongly against compressing PDFs if the compression ratio is
miserable, which is IMO the case for most PDFs nowadays. Take our policy
document for example - compression saves less than 30 percent and throws
unneeded stowns in the way of potential readers.

Eduard.


signature.asc
Description: Digital signature

Re: PDF files and dh_compress

[Martin Wuertele]

* Eduard Bloch <[EMAIL PROTECTED]> [2006-05-09 20:05]:

> #include 
> * Yaroslav Halchenko [Tue, May 09 2006, 01:15:54PM]:
> > Dear Developers,
> > 
> > I've raised this discussion at -mentors first [1] but I think it is worth
> > asking on a devel list since no definite decision was reached and I
> > could not find similar discussion in the archives.
> 
> I am strongly against compressing PDFs if the compression ratio is
> miserable, which is IMO the case for most PDFs nowadays. Take our policy
> document for example - compression saves less than 30 percent and throws
> unneeded stowns in the way of potential readers.
 
How about compressing all generated pdf with eg pdftk instead of gzip?
That would save on space without troubling potential readers.

yours Martin
-- 
<[EMAIL PROTECTED]>  Debian GNU/Linux - The Universal Operating System
Michelle, please meet http://www.google.com. Google, meet Michelle.
-- Steve Greenland, debian-devel@lists.debian.org


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

Re: Intent to hijack Bacula

[Gustavo Franco]

On 5/9/06, John Goerzen <[EMAIL PROTECTED]> wrote:

Hello,

I intend to take over the Bacula package.  I would first like to say
thanks to Jose Luis Tallon for initially packaging it for Debian and
maintaining it for these years.
(...)


Hi John,

Thanks for this. I'm using backuppc at work and was considering to
move our backups to bacula after upgrading our current hardware setup.
Package updates and bug squashing in general was on the roadmap.

That would be good if you, Jose and probably others joined a 'bacula'
group in alioth to keep this in group maintenance. Hopefully i would
be able to join with real work in the next month. Thoughts?

Closing, do you think it will be possible to ship in Etch a "backup
server" task using bacula ? I think that's all up to add more stuff in
debconf and prepare the task itself. Probably a goal for the first
'group upload', if you agree.

regards,
-- stratus

Re: Intent to hijack Bacula

[Christoph Haas]

On Tue, May 09, 2006 at 11:07:27AM -0500, John Goerzen wrote:
> I intend to take over the Bacula package.

Although hijacking generally feels mean I welcome your action here.

>  * Bacula has had RC bugs open for more than a year.  It was removed
>from testing several months ago because of this.

I didn't even notice that. Bummer. Bacula has becoma a common backup
software and is IMHO likely to be equally famous and widely used as e.g.
Amanda. We should try hard to get it back into testing.

Another critical issue: the bacula-directory-mysql package in Sarge is
still unusable without manually patching it after the installation. I had
expected that this is worth an update even in Sarge.

> I have already prepared an NMU that fixes 22 bugs, including all four RC
> bugs.  I have tagged those bugs as pending.  This release is currently
> sitting in NEW.  I also prepared subsequent NMUs that fix critical, but
> unreported, bugs in the Debian Bacula packages.

Very good. Thanks for your effort. I'm looking forward to see your package
get through.

I definitely want to see more current and sane bacula packages in Debian as
I use it myself a lot. I second Gustavo's proposal to make it a team effort
in an alioth project. If you need a helping hand I'll happily join the
project and see what I can do. My environment is a lot smaller than yours
though - disk and tape (DDS-3) backup without an autochanger - MySQL
backend - 500,000 files.

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature

Re: Intent to hijack Bacula

[John Goerzen]

On Tue, May 09, 2006 at 03:45:42PM -0300, Gustavo Franco wrote:
> Hi John,
> 
> Thanks for this. I'm using backuppc at work and was considering to
> move our backups to bacula after upgrading our current hardware setup.
> Package updates and bug squashing in general was on the roadmap.
> 
> That would be good if you, Jose and probably others joined a 'bacula'
> group in alioth to keep this in group maintenance. Hopefully i would
> be able to join with real work in the next month. Thoughts?

I would be happy to do that.  I already maintain almost all of my Debian
packages in darcs, and in fact you can "darcs send" bacula patches to me
already.  Unlike svn, there's no need for a central repo with shared
perms and all that to make it work, so there's less of a need for an
Alioth project, but if you'd like me to set one up, drop me a note
offline (with some benefits you might see) and I'd be happy to do that.

You can get my current repo with:

darcs get http://darcs.complete.org/debian/bacula

Though I should warn you that I am rewriting most of the build system at
this time, so the tree you see there won't be buildable for another day
or two.

> Closing, do you think it will be possible to ship in Etch a "backup
> server" task using bacula ? I think that's all up to add more stuff in
> debconf and prepare the task itself. Probably a goal for the first
> 'group upload', if you agree.

That would certainly be possible -- though really the only package one
would need in that task is bacula-server.

-- John


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

Re: PDF files and dh_compress

[Frank Küster]

Martin Wuertele <[EMAIL PROTECTED]> wrote:

> * Eduard Bloch <[EMAIL PROTECTED]> [2006-05-09 20:05]:
>
>> #include 
>> * Yaroslav Halchenko [Tue, May 09 2006, 01:15:54PM]:
>> > Dear Developers,
>> > 
>> > I've raised this discussion at -mentors first [1] but I think it is worth
>> > asking on a devel list since no definite decision was reached and I
>> > could not find similar discussion in the archives.
>> 
>> I am strongly against compressing PDFs if the compression ratio is
>> miserable, which is IMO the case for most PDFs nowadays. Take our policy
>> document for example - compression saves less than 30 percent and throws
>> unneeded stowns in the way of potential readers.
>  
> How about compressing all generated pdf with eg pdftk instead of gzip?
> That would save on space without troubling potential readers.

Most PDF files in Debian are already compressed;  at least those
which are generated on a Debian system, and somehow TeX is involved
are.  

[EMAIL PROTECTED]:~/area$ pdftk policy.pdf output policy.unc.pdf uncompress
[EMAIL PROTECTED]:~/area$ pdftk policy.unc.pdf output policy.recomp.pdf compress
[EMAIL PROTECTED]:~/area$ lh policy.*
-rw-r--r--  1 frank frank 657K 2006-05-09 21:18 policy.pdf
-rw-r--r--  1 frank frank 667K 2006-05-09 21:19 policy.recomp.pdf
-rw-r--r--  1 frank frank 1.4M 2006-05-09 21:19 policy.unc.pdf
[EMAIL PROTECTED]:~/area$ lh /usr/share/doc/debian-policy/policy.pdf.gz  
-rw-r--r--  1 root root 471K 2006-04-26 07:27 
/usr/share/doc/debian-policy/policy.pdf.gz

So somehow uncompressing-recompressing with pdftk gives a slightly
larger file, whereas gzipping saves 28%.  Or in other words, the
original PDF ZIP compression saves 53% compared to the uncompressed PDF
file, additional gzipping saves 67% all in all.  And bzip2 on the
uncompressed PDF file yields

-rw-r--r--  1 frank frank 332K 2006-05-09 21:19 policy.unc.pdf.bz2

or 76% space saving.


To me, this sounds like in general it's not worth to compress compressed
pdf files with gzip; if we'd go for size, we should use bzip2.


However, we have to keep in mind that some -doc packages consist mainly
of PDF files and would significantly increase in size (or need some
additional splitting).

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: screenshot with package description

[Gonéri Le Bouder]

Hi,

This is a request for comment.

I did some changes since my last post:
- i splited indexes and pixmaps in two different trees (indexes & 
pool). Now 
we can provid the same pixmap for a collection of package (e.g: my example 
with KDE logo)
- i removed the tgz by letters. It was complexe and useless. I prefere 
to 
create a big one.
- screenshot size are standardised to 400x300, 200x150 and 100x75
- screenshot size are standardised to 128x128 and 64x64.
- i removed jpg format for the moment. png give a better result for 
screenshot but files a quite big.
- i did a script to import pixmaps (import_pixmap.pl)

http://gloria.rulezlan.org/debian2/


Regards,

Gonéri


pgp4cQnvYTH8p.pgp
Description: PGP signature

Re: PDF files and dh_compress

[Olaf van der Spek]

On 5/9/06, Yaroslav Halchenko <[EMAIL PROTECTED]> wrote:

* dh_compress doesn't compress some other files based on extension
 including .zip files. PDF (to my knowledge) uses zip internally to
 compress the document. So why PDF should be gzipped if .zip not?


Probably because .zip is compressed better already than .pdf?


* Although there is  a way to view pdf.gz without explicit decompression
 (use see or xzpdf) it is inconvenient for being used from firefox for
 instance (?)


What about improving transparent decompression somehow?

Getting rid of circular dependencies, stage 4

[Bill Allombert]

Hello Debian developers,

Here the lists of packages involved in circular dependencies listed by
maintainers.

This list is also available at

(update daily, courtesy of Robert Lemmen).

A list of dependencies including dependency graphs is available at


The list of bug I reported so far is there:


Cheers,
Bill.

Adeodato Simó <[EMAIL PROTECTED]>
amarok
amarok-arts
amarok-engines
amarok-gstreamer
amarok-xine

Alain Schroeder <[EMAIL PROTECTED]>
fsviewer-icons

Alastair McKinstry <[EMAIL PROTECTED]>
console-common
console-tools

Alioth Games Devel Team <[EMAIL PROTECTED]>
boson-data
boson-music

Andres Salomon <[EMAIL PROTECTED]>
ndiswrapper-common
ndiswrapper-utils-1.7

Andrew Mitchell <[EMAIL PROTECTED]>
phpgroupware
phpgroupware-admin
phpgroupware-phpgwapi
phpgroupware-preferences
phpgroupware-setup

Anthony Towns <[EMAIL PROTECTED]>
netbase

Bernd Schumacher <[EMAIL PROTECTED]>
bootcd
bootcd-hppa
bootcd-i386
bootcd-ia64

Brendan O'Dea <[EMAIL PROTECTED]>
perl
perl-modules

Carlo Contavalli <[EMAIL PROTECTED]>
wipl-client-exec
wipl-client-standard
wipl-daemon

Christian Marillat <[EMAIL PROTECTED]>
librep9
rep

Christian T. Steigies <[EMAIL PROTECTED]>
luola
luola-data
luola-levels

Console utilities maintainers <[EMAIL PROTECTED]>
kbd

Daniel Baumann <[EMAIL PROTECTED]>
lush
lush-library

Daniel Burrows <[EMAIL PROTECTED]>
heroes-common
heroes-ggi
heroes-sdl
lbreakout2
lbreakout2-data

David Coe <[EMAIL PROTECTED]>
iamerican
ispell

David Moreno Garza <[EMAIL PROTECTED]>
gxmms-bmp
gxmms-common
gxmms-xmms
liferea
liferea-gtkhtml
liferea-mozilla
playground
playground-plugin-xmms

Debian GCC Maintainers 
g++-3.3
g++-3.4
g++-4.0
g++-4.1
gcj
gcj-4.0
gcj-4.1
java-gcj-compat
libgcj-dev
libgcj6-dev
libgcj7-dev
libstdc++5-3.3-dev
libstdc++6-4.0-dev
libstdc++6-4.1-dev
libstdc++6-dev

Debian GCC maintainers 
g++-2.95
libstdc++2.10-dev

Debian GIS Project 
grass
libgrass

Debian GNOME Maintainers <[EMAIL PROTECTED]>
gamin
libgamin0

Debian GNUstep maintainers <[EMAIL PROTECTED]>
gnustep-back0.10
gnustep-base-common
gnustep-gpbs
gnustep-gui-common
gnustep-ppd
libgnustep-base1.11
libgnustep-gui0.10

Debian Games Team <[EMAIL PROTECTED]>
boson
boson-base

Debian Italian Maintainers Task Force <[EMAIL PROTECTED]>
festlex-ifd
festvox-italp16k
festvox-itapc16k

Debian Java Maintainers 
antlr
eclipse-jdt
eclipse-jdt-common
gjdoc
kaffe
kaffe-jthreads
kaffe-pthreads
libgnucrypto-java
libjessie-java
libswt3.1-gtk-java
libswt3.1-gtk-jni

Debian LyX Maintainers <[EMAIL PROTECTED]>
lyx-common
lyx-qt
lyx-xforms

Debian Mono Group <[EMAIL PROTECTED]>
libmono-security2.0-cil
libmono-system2.0-cil
mono-gac
mono-runtime

Debian NTP Team <[EMAIL PROTECTED]>
ntp-refclock
ntp-server
ntp-simple

Debian OpenOffice Team 
openoffice.org-common
openoffice.org-core

Debian Qt/KDE Maintainers 
kdelibs-bin
kdelibs4c2a
libkcal2b
libkdepim1a

Debian X Strike Force 
libx11-dev
libxext-dev
xserver-xorg-core
xserver-xorg-input-all
xserver-xorg-input-evdev
xserver-xorg-video-all
xserver-xorg-video-apm
xserver-xorg-video-ark
xserver-xorg-video-ati
xserver-xorg-video-chips
xserver-xorg-video-cirrus
xserver-xorg-video-cyrix
xserver-xorg-video-dummy
xserver-xorg-video-fbdev
xserver-xorg-video-glint
xserver-xorg-video-i128
xserver-xorg-video-i740
xserver-xorg-video-i810
xserver-xorg-video-imstt
xserver-xorg-video-mga
xserver-xorg-video-newport
xserver-xorg-video-nsc
xserver-xorg-video-nv
xserver-xorg-video-rendition
xserver-xorg-video-s3
xserver-xorg-video-s3virge
xserver-xorg-video-savage
xserver-xorg-video-sis
xserver-xorg-video-sisusb
xserver-xorg-video-tdfx
xserver-xorg-video-tga
xserver-xorg-video-trident
xserver-xorg-video-tseng
xserve

Re: Getting rid of circular dependencies, stage 4

[Steve Langasek]

On Tue, May 09, 2006 at 10:49:36PM +0200, Bill Allombert wrote:

> Here the lists of packages involved in circular dependencies listed by
> maintainers.

> Debian NTP Team <[EMAIL PROTECTED]>
>   ntp-refclock
>   ntp-server
>   ntp-simple

This is a really nice loop causing RC bug #329746 because the package
manager is unable to enforce configuring the packages in dependency order.

It'd be keen if you (or someone) wanted to work out a fix for this one and
submit a patch. :)

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

Bug#366618: ITP: cdck -- A simple program to verify CD/DVD quality

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi <[EMAIL PROTECTED]>

* Package name: cdck
  Version : 0.5.2
  Upstream Author : Alexey Semenoff <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : GPL
  Description : A simple program to verify CD/DVD quality

 Actually cdck is a simple program to verify CD/DVD quality. The known
 fact is that even if all files on the disc are readable, some sectors
 having bad timing can easily turn into unreadable ones in the future.
 .
 To get an idea about disc cdck reads it sector by sector, keeping all
 reading timings  and then  tells you its  verdict. Optionally  it can
 write timing  table into text  file usable by gnuplot(1)  program, so
 you can draw some graphs out of it.
 .
  http://swaj.net/unix/#cdck

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686-smp
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]

Re: Getting rid of circular dependencies, stage 4

[Thomas Bushnell BSG]

Bill Allombert <[EMAIL PROTECTED]> writes:

> Thomas Bushnell, BSG <[EMAIL PROTECTED]>
>   gnome-bin
>   gnome-libs-data
>   gnucash
>   gnucash-common
>   gtkhtml
>   libgnome32
>   libgnomesupport0
>   libgnomeui32
>   libgnorba27
>   libgtkhtml-data

Except for gnucash and gnucash-common, these are legacy packages which
will hopefully not be in the etch release.  So I won't spend effort
figuring out what the right fixes are. That said, if someone else were
to submit BTS bugs with suggested patches, I would be happy to upload
the fixes.

I'll fix the gnucash ones asap.

Thomas


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

Re: Getting rid of circular dependencies, stage 4

[Matthias Klose]

Bill Allombert writes:
> Debian GCC Maintainers 
>   g++-3.3
>   g++-3.4
>   g++-4.0
>   g++-4.1
>   gcj
>   gcj-4.0
>   gcj-4.1
>   java-gcj-compat
>   libgcj-dev
>   libgcj6-dev
>   libgcj7-dev
>   libstdc++5-3.3-dev
>   libstdc++6-4.0-dev
>   libstdc++6-4.1-dev
>   libstdc++6-dev
> 
> Debian GCC maintainers 
>   g++-2.95
>   libstdc++2.10-dev

maybe the corresponding g++-X.Y and libstdc++-Z-X.Z-dev packages could
be solved by merging these packages. Anyway, these binaries are built
from the same source, so we should ot care-

I currently do not understand the java-gcj-compat / gcj-4.X relationship.

> Debian OpenOffice Team 
>   openoffice.org-common
>   openoffice.org-core

that's just a splitting into arch/indep packages. you sould not warn
about it.

> Matthias Klose <[EMAIL PROTECTED]>
>   python-netcdf
>   python-scientific

same thing.


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

Bug#366647: ITP: rp-l2tp -- a user-space implementation of L2TP (RFC 2661) for Linux

[alex bodnaru]

Package: wnpp
Severity: wishlist
Owner: alex bodnaru <[EMAIL PROTECTED]>


* Package name: rp-l2tp
  Version : 0.4
  Upstream Author : Copyright 2002 Roaring Penguin Software Inc
* URL : http://sourceforge.net/projects/rp-l2tp/
* License : GPL
  Programming Lang: C
  Description : a user-space implementation of L2TP (RFC 2661) for Linux

 rp-l2tp  provides  a  user-space  L2TP daemon.  L2TP is the Layer Two
 Tunneling  Protocol described in RFC 2661.  It allows you to tunnel 
 PPP  sessions over a network or transport protocol (in this case, UDP.)


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-skas3-v8.2
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: Getting rid of circular dependencies, stage 4

[Michael Koch]

Hello,


>   antlr
>   gjdoc

Somehow these seem to be false positives to me because the packages
depend on a java runtime environment which can but does not have to
depend on.

>   libgnucrypto-java
>   libjessie-java

I think these an be removed before etch release.

>   eclipse-jdt
>   eclipse-jdt-common
>   kaffe
>   kaffe-jthreads
>   kaffe-pthreads
>   libswt3.1-gtk-java
>   libswt3.1-gtk-jni

I dont understand these.



Cheers,
Michael
-- 
http://www.worldforge.org/


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

Re: Getting rid of circular dependencies, stage 4

[Hubert Chan]

On Tue, 9 May 2006 22:49:36 +0200, Bill Allombert <[EMAIL PROTECTED]> said:

> Debian GNUstep maintainers
 ...
>gnustep-ppd

Ah, I didn't notice gnustep-ppd was involved in a circular dependency as
well.  This one should be easy to fix.  (And I'm working on the other
GNUstep packages this week.)

> Hubert Chan <[EMAIL PROTECTED]>
>alsaplayer-alsa
>alsaplayer-common
>alsaplayer-gtk

Hmm...  alsaplayer-common Depends: on "alsaplayer-alsa |
alsaplayer-output" and "alsaplayer-gtk | alsaplayer-interface".  Is this
really a problem?

-- 
Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA   (Key available at wwwkeys.pgp.net)
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA


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

Re: Bug#366618: ITP: cdck -- A simple program to verify CD/DVD quality

[Pierre Habouzit]

merge 366618 366554
thanks

Le Mar 9 Mai 2006 23:50, Sandro Tosi a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Sandro Tosi <[EMAIL PROTECTED]>
>
> * Package name: cdck
>   Version : 0.5.2
>   Upstream Author : Alexey Semenoff <[EMAIL PROTECTED]>
> * URL : http://www.example.org/
> * License : GPL
>   Description : A simple program to verify CD/DVD quality
>
>  Actually cdck is a simple program to verify CD/DVD quality. The
> known fact is that even if all files on the disc are readable, some
> sectors having bad timing can easily turn into unreadable ones in the
> future. .
>  To get an idea about disc cdck reads it sector by sector, keeping
> all reading timings  and then  tells you its  verdict. Optionally  it
> can write timing  table into text  file usable by gnuplot(1) 
> program, so you can draw some graphs out of it.
>  .
>   http://swaj.net/unix/#cdck
>
> -- System Information:
> Debian Release: 3.1
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.15-1-686-smp
> Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpz09yYNb4Zr.pgp
Description: PGP signature