mozilla-firefox-locale package with all language translations

[Cesar Martinez Izquierdo]

Hi! Sometimes a package with all the firefox translations has been proposed.
With the arrival of Firefox 1.0, localization has been normalized and now this 
package seems quite suitable.

As a proof of concept, I have packaged "mozilla-firefox-locale-all", 
containing all the available translations at the moment.

You can download the package at:


The "rules" file includes an "wget" rule that can download the available XPI 
files with the translations.
After download new XPI files, if you regenerate the package then you get all 
the required files for these new XPIs.

The currently built package contains the XPI files downloaded from 
.
Maybe it would be better to use 
, 
which contains less translations but they are supposed to be tested and 
complete. Anyway the nightly XPIs seem to work fine for me.

Opinions and testing is welcome.

  Cesar Martinez Izquierdo

Re: Which 2.6 kernel for Sarge on a Via C3?

[Ron Johnson]

On Wed, 2004-11-10 at 23:54 +0100, Jerome Warnier wrote:
> On Wed, 2004-11-10 at 23:49 +0100, Finn-Arne Johansen wrote:
> > On Wed, Nov 10, 2004 at 07:33:43PM +0100, Jerome Warnier wrote:
> > > I'm wondering why I can't see many different 2.6 kernels on my Sarge
> > > systems any longer. I own a Via C3-based computer (an x86 for those who
> > > didn't know) and can find only -386 and -686 kernels which could
> > > possibly match.
> > > 
> > > Somebody knows?
> > 
> > I would go for a 386 kernel, If I remember correctly my via paniced
> > when I tried the 686 kernel. 
> Thanks, but honestly, I expected someone to say: "hey, where are all
> those kernels gone?" like me ;-)
> I'm already using -386, but Via C3 has MMX and other stuff like that
> which could probably be useful for maximum performance.

Roll your own kernel?

But really, does the kernel use MMX?

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B

Why won't GWB have the US invade the DPRK? Because the People's
Army has 11-15,000 cannons all aimed at Seoul...



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

Bug#280683: ITP: liburi-find-perl -- Find URIs in arbitrary text

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist

* Package name: liburi-find-perl
  Version : 0.14
  Upstream Author : Roderick Schertler <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/URI-Find/
* License : Dual GPL/Artistic
  Description : Find URIs in arbitrary text

 This module does one thing: Finds URIs and URLs in plain text.  It finds
 them quickly and it finds them all (or what URI::URL considers a URI
 to be.)  It only finds URIs which include a scheme (http:// or the
 like), for something a bit less strict have a look at
 URI::Find::Schemeless|URI::Find::Schemeless.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing'), (10, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.27
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15

Re: Bug#280534: ITP: kernel-patch-linuxabi -- Runs programs written for different Unix's under Linux

[Guillem Jover]

Hi Russell,

On Wed, Nov 10, 2004 at 11:28:25AM +1000, [EMAIL PROTECTED] wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: kernel-patch-linuxabi
>   Version : 20040724
>   Upstream Author : Various
> * URL : 
> http://www.lubemobile.com.au/ras/debian/sarge/kernel-patch-linuxabi

The URL is meant to point to the upstream website or download area.
I've seen you've done that with two other ITPs.

regards,
guillem

Re: Debian Entwicklung für unstable?

[Bernd Eckenfels]

Hello Markus,

On Wed, Nov 10, 2004 at 12:36:31PM +0100, [EMAIL PROTECTED] wrote:
> Hallo,
> 
> Ich habe bereits einige Debian Packete erstellt, von AVM (Kisdnwatch, 
> Kadslwatch etc.), 



Markus, in order to get a package included into Debian Distributions, you
need to find a developer who uploads them for you. Later you can apply for
Developership yourself.

See 

http://www.debian.org/devel/join/ 
  
  and especially

http://www.debian.org/devel/join/newmaint

Make sure you check out the Debian pages before.

Gruss
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o 1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+497211606754
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: Introducing pmount in Debian / New plugdev group

[Paul Hampson]

On Wed, Nov 10, 2004 at 04:43:41PM +0100, Martin Pitt wrote:
> Marco d'Itri [2004-11-10 14:19 +0100]:
> > > Our /etc/udev/udev.rules has two new rules directly after the cdrom
> > > and floppy rules:

> > > # put removable IDE/SCSI devices into group 'plugdev' instead of 'disk'
> > > BUS="scsi", KERNEL="sd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", 
> > > RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev"
> > > BUS="ide", KERNEL="hd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", 
> > > RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev"

> > What about I ship the script in udev (as /etc/udev/scripts/removable.sh)
> > and your package install the rules file? Or udev provides the rules file
> > too and your package enables it by creating the symlink?

> I was not sure whether it is valid that packages put their scripts
> into /etc/udev/rules.d. But I would be fine to leave udev.rules
> untouched and have pmount ship /etc/udev/rules.d/z_plugdev.rules (z_
> because it must be executed after the standard rules; if it is
> executed earlier, CD-ROM and floppy nodes will also be in plugdev,
> which is not intended).

But don't CD-ROM and floppy devices also need the same sort of pmount
support you're proposing here? After all, you can hot-swap the media in
them, so it seems reasonable to me that they can be pmounted? What's the
rationale for _not_ including these in the pmount infrastructure you're
proposing?

Hmm. Now that I think about it, surely the plugdev group would have to
be given using pam_console so that remote users in the plugdev group
can't remotely stomp on the USB memory stick the local user just put in,
before they could mount it?

In _that_ case, cdrom and floppy strike me as _very_ appropriate for the
same treatment, and the local administrator could add appropriate people
directly to those groups for things like a headless server where someone
whacks in a USB stick, and then wanders back to their laptop to access
it. This would close (to my mind) a security hole in systems where both
local and remote users have access.

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

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

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


signature.asc
Description: Digital signature

Re: Which 2.6 kernel for Sarge on a Via C3?

[Chris Cheney]

On Wed, Nov 10, 2004 at 07:33:43PM +0100, Jerome Warnier wrote:
> I'm wondering why I can't see many different 2.6 kernels on my Sarge
> systems any longer. I own a Via C3-based computer (an x86 for those who
> didn't know) and can find only -386 and -686 kernels which could
> possibly match.
> 
> Somebody knows?

I seem to recall the C3 is missing the CMOV instruction which would
require that you use a kernel < i686, so in this case the i386 kernel.

Chris

Re: Which 2.6 kernel for Sarge on a Via C3?

[Jerome Warnier]

On Wed, 2004-11-10 at 23:49 +0100, Finn-Arne Johansen wrote:
> On Wed, Nov 10, 2004 at 07:33:43PM +0100, Jerome Warnier wrote:
> > I'm wondering why I can't see many different 2.6 kernels on my Sarge
> > systems any longer. I own a Via C3-based computer (an x86 for those who
> > didn't know) and can find only -386 and -686 kernels which could
> > possibly match.
> > 
> > Somebody knows?
> 
> I would go for a 386 kernel, If I remember correctly my via paniced
> when I tried the 686 kernel. 
Thanks, but honestly, I expected someone to say: "hey, where are all
those kernels gone?" like me ;-)
I'm already using -386, but Via C3 has MMX and other stuff like that
which could probably be useful for maximum performance.

-- 
Jerome Warnier <[EMAIL PROTECTED]>
BeezNest

Bug#280675: ITP: l2tpns

[Jonathan McDowell]

Package: wnpp
Severity: wishlist

* Package name: l2tpns
  Version : 2.0.5
  Upstream Author : David Parrish and others <[EMAIL PROTECTED]>
* URL : http://l2tpns.sf.net/
* License : GPL
  Description : L2TP LNS which does not require l2tpd, pppd or any kernel 
patches.

   L2TPNS is half of a complete L2TP implementation. It supports only
   the LNS side of the connection.

   L2TP (Layer 2 Tunneling Protocol) is designed to allow any layer 2 protocol
   (e.g. Ethernet, PPP) to be tunneled over an IP connection. L2TPNS implements
   PPP over L2TP only.

   Also supports ISP features like speed throttling, walled garden, usage
   accounting, and more.


(This will require libcli, which I ITPed earlier today as #280611)

J.

-- 
 Too many freaks, not enough circuses.
[ Black Cat Networks ] [ 0845 PAYG dialup ] [ ADSL from £20+VAT/month ]
[ http://www.blackcatnetworks.co.uk/ ]

Re: Which 2.6 kernel for Sarge on a Via C3?

[Finn-Arne Johansen]

On Wed, Nov 10, 2004 at 07:33:43PM +0100, Jerome Warnier wrote:
> I'm wondering why I can't see many different 2.6 kernels on my Sarge
> systems any longer. I own a Via C3-based computer (an x86 for those who
> didn't know) and can find only -386 and -686 kernels which could
> possibly match.
> 
> Somebody knows?

I would go for a 386 kernel, If I remember correctly my via paniced
when I tried the 686 kernel. 


-- 
Finn-Arne Johansen 
[EMAIL PROTECTED]
http://bzz.no/

Re: Bug#280435: ITP: libkexif -- KDE library to read/edit EXIF informations

[Hamish Moffatt]

On Wed, Nov 10, 2004 at 02:21:35PM +0100, Achim Bohnet wrote:
> On Wednesday 10 November 2004 13:03, Hamish Moffatt wrote:
> > OK. (The description didn't mention that it was graphical.)
> 
> Mhmm... isn't KDE library enough?  I would never that something
> with KDE in it's descriptions has widgets in it.  Right, that's
> only me.  I'll check header files and add ... graphical
> library...' or '...widget and helper library...' as appropiate.
> Thx for the suggestion.

OK. Maybe KDE library is enough; I know that GNOME has non-visual
libraries and the description talked about manipulating the data,
nothing about displaying it though.

> Pardon? The -gtk and -ruby are extentions/'wrappers' and from different
> sources. Ditto for libkexif (beside not be named libexif-kde3).

Ahh. I didn't know. Thanks for your ITP then.


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

Bug#280656: ITP: portmidi -- a library for real-time MIDI input/output

[Paul Brossier]

Package: wnpp
Severity: wishlist


* Package name: portmidi
  Version : x.y.z
  Upstream Author : Ross Bencina <[EMAIL PROTECTED]>
Phil Burk <[EMAIL PROTECTED]>
Roger B. Dannenberg <[EMAIL PROTECTED]>
* URL : http://www-2.cs.cmu.edu/~music/portmusic/
* License : Modified BSD style license
  Description : a library for real-time MIDI input/output

 PortMidi is a platform independant library for real-time MIDI
 input/output.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.8.1
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Re: Bug#280324: ITP: freemind -- A Java Program for creating and viewing Mindmaps

[David Goodenough]

On Wednesday 10 November 2004 18:22, Eric Lavarde wrote:
> Hi,
>
> hope this is OK to reply-to-all in such cases...
>
> Hilko Bengen wrote:
> > Eric Lavarde <[EMAIL PROTECTED]> writes:
> >>the package does already exist actually (see
> >>http://freemind.sourceforge.net/wiki/index.php/FreeMind_on_Linux for
> >>details), I'm the maintainer of the package for the FreeMind project
> >>and I'd like to have it in the official Debian repository (contrib
> >>Section).
> >
> > Have you tried to compile/run freemind with any of the available
> > DFSG-free JREs so far?
>
> Not personally, but some users have unintentionally and unsuccessfully
> tried to start FreeMind with kaffe and gcj. Would I get a different
> result if I would try to _compile_ first FreeMind with whatever free JDK?

I tried to run it under gij-3.4 and it died.  I have yet to investigate why.

David

>
> >>I'm not yet a Debian developer, going through the documentation and
> >>the process of becoming one.
> >
> > Recently I spent a few hours on creating a freemind package myself,
> > since I hadn't seen the links to your package so far. If you want,
> > I'll be happy to sponsor your package.
>
> It would be a pleasure, I just need to find a key signer nearby. Anybody
> living around BÃblingen (or Stuttgart)?
> So, what would be the next steps? Remember: I'm still going through the
> documentation (and I didn't think it would be so quick to get a sponsor
>
> :-) ).
>
> Thanks, Eric
>
> > Cheers,
> > -Hilko

Bug#280650: ITP: wired -- a music production and creation software

[Paul Brossier]

Package: wnpp
Severity: wishlist


* Package name: wired
  Version : 0.1
  Upstream Author : Contact <[EMAIL PROTECTED]>
Colin Laplace, Vincent Bongiorno, Coumba Nar, 
GrÃgory Duhamel, Diodio Sambe, ClÃment Baret
* URL : http://bloodshed.net/wired/
* License : GPL
  Description : a music production and creation software

 Wired aims to be a professional music production and creation software running
 on the Linux operating system.
 .
 It brings musicians a complete studio environment to compose and record music
 without requiring expensive hardware.
 .
 Wired supports unlimited Audio/Midi tracks playback and recording, and
 introduces a Plugin system for instruments and effects. It can also read AKAI
 CDs and import 18 different Wave formats.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.8.1
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Which 2.6 kernel for Sarge on a Via C3?

[Jerome Warnier]

I'm wondering why I can't see many different 2.6 kernels on my Sarge
systems any longer. I own a Via C3-based computer (an x86 for those who
didn't know) and can find only -386 and -686 kernels which could
possibly match.

Somebody knows?

Thanks
-- 
Jerome Warnier <[EMAIL PROTECTED]>
BeezNest

Re: Bug#280324: ITP: freemind -- A Java Program for creating and viewing Mindmaps

[Eric Lavarde]

Hi,
hope this is OK to reply-to-all in such cases...
Hilko Bengen wrote:
Eric Lavarde <[EMAIL PROTECTED]> writes:

the package does already exist actually (see
http://freemind.sourceforge.net/wiki/index.php/FreeMind_on_Linux for
details), I'm the maintainer of the package for the FreeMind project
and I'd like to have it in the official Debian repository (contrib
Section).

Have you tried to compile/run freemind with any of the available
DFSG-free JREs so far?
Not personally, but some users have unintentionally and unsuccessfully 
tried to start FreeMind with kaffe and gcj. Would I get a different 
result if I would try to _compile_ first FreeMind with whatever free JDK?

I'm not yet a Debian developer, going through the documentation and
the process of becoming one.

Recently I spent a few hours on creating a freemind package myself,
since I hadn't seen the links to your package so far. If you want,
I'll be happy to sponsor your package.
It would be a pleasure, I just need to find a key signer nearby. Anybody 
living around BÃblingen (or Stuttgart)?
So, what would be the next steps? Remember: I'm still going through the 
documentation (and I didn't think it would be so quick to get a sponsor 
:-) ).

Thanks, Eric
Cheers,
-Hilko

--
Gewalt ist die letzte Zuflucht der Inkompetenz.
Violence is the Last Resort of the Incompetent.
Gwalt jest ostatnem schronieniem niekompetencji.
La violence est le dernier refuge de l'incompetence.
~ Isaac Asimov

Re: more current iproute

[simon]

Ce jour Wed, 10 Nov 2004, Andreas Barth a dit:

> Dear all,
> 
> I uploaded the current version of iproute (that also works with current
> 2.6-kernels) to experimental. As this is a major change, any test
> reports are appreciated. Also, a review of the source whether I managed
> to keep all security patches might be a good idea (I'm quite confident
> that I did, but - a independent look might be a good thing).
> 
> Please note that I'm aware that the package documentation is not in the
> best state, but as this was a NMU, I didn't do the changes that I would
> have done with a normal maintainer upload.

aah, thanks :).

> 
> Cheers,
> Andi
> -- 
>http://home.arcor.de/andreas-barth/
>PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
Cold pizza and cold coffee, second best thing to cold pizza and warm beer.


signature.asc
Description: Digital signature

Bug#280621: ITP: kisdnwatch -- Monitor for CAPI 2.0 based ISDN devices for KDEs systray

[Achim Bohnet]

Package: wnpp
Severity: wishlist

* Package name: kisdnwatch
  Version : 01.00.08
  Upstream Author : AVM <[EMAIL PROTECTED]>
* URL : 
http://www.avm.de/de/Service/AVM_Service_Portale/Linux/CAPI_Tools/K_ISDN_Watch.html
* License : GPL
  Description : CAPI based ISDN channel monitor for KDE's system tray

 kisdnwatch is a ISDN channel Monitor for the K Desktop Environment.
 This tool reside in the system tray of the KDE's desktop panel and
 shows the status of ISDN-Channels.
 .
 kisdnwatch requires a CAPI driver for the ISDN device and
 works in the moment only with AVM's ISDN devices.
 .
 kisdnwatch provides an info dialog for the available ISDN
 devices.  On an incoming or outgoing call kisdnwatch pops
 up (optinally) a window with more detailed information. 
 kisdnwatch record the connection times to a file

--
Status:
deb pkg is already maintained outside Debian for
1.5 years.  With 1.00.08 most of my changes are
now merged upstream.  So time to ITP.

Markus Fischer (X-debbugs-cc'ed) debianzied kisdnwatch now again.
I'll coordinate with him how to proceed to get it into Debian.

Achim

Re: Introducing pmount in Debian / New plugdev group

[Martin Pitt]

Hi Marco!

Marco d'Itri [2004-11-10 14:19 +0100]:
> > Our /etc/udev/udev.rules has two new rules directly after the cdrom
> > and floppy rules:
> > 
> > # put removable IDE/SCSI devices into group 'plugdev' instead of 'disk'
> > BUS="scsi", KERNEL="sd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", 
> > RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev"
> > BUS="ide", KERNEL="hd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", 
> > RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev"
> 
> What about I ship the script in udev (as /etc/udev/scripts/removable.sh)
> and your package install the rules file? Or udev provides the rules file
> too and your package enables it by creating the symlink?

I was not sure whether it is valid that packages put their scripts
into /etc/udev/rules.d. But I would be fine to leave udev.rules
untouched and have pmount ship /etc/udev/rules.d/z_plugdev.rules (z_
because it must be executed after the standard rules; if it is
executed earlier, CD-ROM and floppy nodes will also be in plugdev,
which is not intended).

If it is okay for you that pmount also ships /etc/udev/removable.sh,
then I can do that as well. In this case the udev package does not
need to be modified at all.

Thanks for your cooperation and have a nice day!

Martin

-- 
Martin Pitt   http://www.piware.de
Ubuntu Developerhttp://www.ubuntulinux.org
Debian GNU/Linux Developer   http://www.debian.org


signature.asc
Description: Digital signature

Bug#280611: ITP: libcli

[Jonathan McDowell]

Package: wnpp
Severity: wishlist

* Package name: libcli
  Version : 1.8.1
  Upstream Author : David Parrish <[EMAIL PROTECTED]>
* URL : http://libcli.sf.net/
* License : LGPL
  Description : emulates a cisco style telnet command-line interface

  libcli provides a consistant Cisco style command-line environment for
  remote clients, with a few common features between every implemtation.

  The library is not accessed by itself, rather the software which uses
  it listens on a defined port for a Telnet connection. This connection
  is handed off to libcli for processing. 

  libcli includes support for command history, command line editing and
  filtering of command output.

J.

-- 
Purrr.

Please test findutils 4.2.4 in experimental

[Andreas Metzler]

Hello,
findutils upstream has taken up lots of speed  while I was VAC and has
not only managed to declare 4.1.20 stable but also to make a couple of
new releases from CVS.

The changelog is quite big, closing many bugs and also adding a couple
of features (no, -exec {}+ is not there yet). I'd appreciate testing
before I upload to unstable.
 thanks, cu andreas

suscribe

[georg leugner]

-- 
Geschenkt: 3 Monate GMX ProMail + 3 Top-Spielfilme auf DVD
++ Jetzt kostenlos testen http://www.gmx.net/de/go/mail ++

Re: Bug#280435: ITP: libkexif -- KDE library to read/edit EXIF informations

[Achim Bohnet]

On Wednesday 10 November 2004 13:03, Hamish Moffatt wrote:
> On Wed, Nov 10, 2004 at 07:15:18PM +1100, Ben Burton wrote:
> > > > Libkexif is a KDE library for manipulating EXIF information embedded in
> > > > images. It currently supports viewing of all EXIF information via
> > > > libexif. It also supports the modification of a few attributes in a save
> > > > way that preserves all other EXIF information in the file. It can
> > > > currently modify the following tags:
> > > 
> > > Given that it sounds like it's non-graphical, what does it do that
> > > libexif doesn't, and why does KDE need its own EXIF library?
> > 
> > Because it is graphical (says me after taking a lightning look in the
> > upstream CVS).  And moreover it makes use of the regular libexif, as
> > Achim's description points out.
> 
> OK. (The description didn't mention that it was graphical.)

Mhmm... isn't KDE library enough?  I would never that something
with KDE in it's descriptions has widgets in it.  Right, that's
only me.  I'll check header files and add ... graphical
library...' or '...widget and helper library...' as appropiate.
Thx for the suggestion.
> 
> libexif already has some widgets I see. Pity that libkexif couldn't be
> one more:

Pardon? The -gtk and -ruby are extentions/'wrappers' and from different
sources. Ditto for libkexif (beside not be named libexif-kde3).
> 
> libexif-dev - The EXIF library allows you to parse an EXIF file
> (development files)
> libexif-gtk-dev - Library providing GTK+ widgets to display/edit EXIF
> tags (development files)
> libexif-gtk4 - Library providing GTK+ widgets to display/edit EXIF tags
> libexif-ruby - EXIF tag parsing Library for ruby (dummy package)
> libexif-ruby1.6 - EXIF tag parsing Library for ruby1.6
> libexif-ruby1.8 - EXIF tag parsing Library for ruby1.8
> libexif10 - The EXIF library allows you to parse an EXIF file

pkg libexif-gtk include a library libexif-gtk.   On the other hand
pkp libkexif0 contains libkexif0.   So it's consistent from upstream
naming point of view.  It's out of my hands that upsteam didn't use
libexif-kde3 as it's name.

Do you propose to use pkg name libexif-kde3-0 with library libkexif0
inside?

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

-- 
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
  -- [EMAIL PROTECTED]

Re: Introducing pmount in Debian / New plugdev group

[Marco d'Itri]

On Nov 10, Martin Pitt <[EMAIL PROTECTED]> wrote:

> Our /etc/udev/udev.rules has two new rules directly after the cdrom
> and floppy rules:
> 
> # put removable IDE/SCSI devices into group 'plugdev' instead of 'disk'
> BUS="scsi", KERNEL="sd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", 
> RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev"
> BUS="ide", KERNEL="hd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", 
> RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev"

What about I ship the script in udev (as /etc/udev/scripts/removable.sh)
and your package install the rules file? Or udev provides the rules file
too and your package enables it by creating the symlink?

-- 
ciao, |
Marco | [9119 prpW76ZT/rZhI]


signature.asc
Description: Digital signature

Re: Introducing pmount in Debian / New plugdev group

[Paul Hampson]

On Wed, Nov 10, 2004 at 01:25:56PM +0100, Sjoerd Simons wrote:
> On Tue, Nov 09, 2004 at 06:41:40PM +0100, Martin Pitt wrote:
> > We solved (4) by introducing a new group called 'plugdev'. Every user
> > who is a member of this group can access hotpluggable devices (digital
> > cameras, USB drives etc.). pmount can only be executed by members of
> > this group (it is root:plugdev 750), hal runs in this group to be able
> > to detect file systems (but it does not run in 'disk'), and udev
> > assigns the 'plugdev' group to removable devices (static drives remain
> > in group 'disk').
> > 
> > BTW, we also use 'plugdev' for libgphoto (IIRC Debian uses 'camera'
> > for that).

> I personally would prefer two groups. One to give access rights to the raw
> device of the removable drive and one to mount them using pmount. I don't like
> giving all my programs direct access, just because i'm allowed to pmount a
> drive.

Do the devices have to be g+w? Surely g+r is enough (or not even
neccesary) for pmount to identify them as pmountable? Although I guess
partitioning would require +w for the user, but in that case the user
needs direct access anyway, and then dialling your USB stick becomes a
distinct possibility.

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

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

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


signature.asc
Description: Digital signature

Re: Introducing pmount in Debian / New plugdev group

[Anand Kumria]

On Tue, 09 Nov 2004 19:32:38 +0100, Marco d'Itri wrote:

> On Nov 09, Martin Pitt <[EMAIL PROTECTED]> wrote:
> 
>> We solved (4) by introducing a new group called 'plugdev'. Every user
>> who is a member of this group can access hotpluggable devices (digital
>> cameras, USB drives etc.). pmount can only be executed by members of
>> this group (it is root:plugdev 750), hal runs in this group to be able
>> to detect file systems (but it does not run in 'disk'), and udev assigns
>> the 'plugdev' group to removable devices (static drives remain in group
>> 'disk').
> I'm not sure about what I should do as the udev maintainer. The default
> udev configuration does not really know for sure if a given device is
> removable.

Initially I was going to suggest you'd know because of the bus-type but I
suspect that even that may not be enough (SATA IDE devices: removable or
not; PCI-X cards: removable or not)

I'd assume that all storage can come and go 'at whim'.

Anand
-- 
linux.conf.au 2005   -  http://lca2005.linux.org.au/  -  Birthplace of Tux
April 18th to 23rd   -  http://lca2005.linux.org.au/  -   LINUX
Canberra, Australia  -  http://lca2005.linux.org.au/  -Get bitten!

Re: Introducing pmount in Debian / New plugdev group

[Sjoerd Simons]

On Tue, Nov 09, 2004 at 06:41:40PM +0100, Martin Pitt wrote:
> We solved (4) by introducing a new group called 'plugdev'. Every user
> who is a member of this group can access hotpluggable devices (digital
> cameras, USB drives etc.). pmount can only be executed by members of
> this group (it is root:plugdev 750), hal runs in this group to be able
> to detect file systems (but it does not run in 'disk'), and udev
> assigns the 'plugdev' group to removable devices (static drives remain
> in group 'disk').
> 
> BTW, we also use 'plugdev' for libgphoto (IIRC Debian uses 'camera'
> for that).

I personally would prefer two groups. One to give access rights to the raw
device of the removable drive and one to mount them using pmount. I don't like
giving all my programs direct access, just because i'm allowed to pmount a
drive.

  Sjoerd
-- 
Space is to place as eternity is to time.
-- Joseph Joubert

Re: Debian Entwicklung für unstable?

[Martin Pitt]

Hi Markus!

Please do not crosspost so heavily; this is a question for
debian-mentors, not for -devel, and even less for -release, let alone
the FTP masters. This is outright spamming. Second, this is an English
mailing list.

[EMAIL PROTECTED] [2004-11-10 12:36 +0100]:
> Ich habe bereits einige Debian Packete erstellt, von AVM (Kisdnwatch, 
> Kadslwatch etc.), 
> die dazugehörigen Kernel Module von AVM mit dem Kernel 2.6.9 werden auch 
> bald folgen.
> Das ganze für unstable mit KDE 3.3.1.
> Was muss ich machen, um diese auch in unstable mit zu veröffentlichen, 
> oder muss man den offiziellen weg eines debian Entwicklers, 
> wie im Internet beschrieben steht, beschreiten?

You do not need to be a Debian Developer to maintain packages. It is
enough to find a Debian Developer who reviews and uploads packages for
you. 

http://www.de.debian.org/doc/developers-reference/ch-new-maintainer.en.html#s-mentors

Martin

-- 
Martin Pitt   http://www.piware.de
Ubuntu Developerhttp://www.ubuntulinux.org
Debian GNU/Linux Developer   http://www.debian.org


signature.asc
Description: Digital signature

pmount in Sarge? [was: Re: Introducing pmount in Debian / New plugdev group]

[Martin Pitt]

Hi Nikita!

Nikita V. Youshchenko [2004-11-10 14:38 +0300]:
> AFAIK, Sarge is going to be released with 2.6.8.1
> 
> I think keeping pmount out of sarge is a bad idea. As long as pmount works
> (it it is *released* with ubuntu, probably it does), and may be useful at
> least from command line, why keep it out?
> 
> And if, for whatever reason, sarge will not be released for some more time,
> maybe some software that will use pmount will also migrate to sarge.

For my sake I can close the RC bug and have it in Sarge. I will
support it anyway, Ubuntu and Debian are in sync. I was just unsure
whether there are opinions that it is better to keep it out.

So if anybody does not want pmount to be in Sarge, please speak up now
:-)

Martin
-- 
Martin Pitt   http://www.piware.de
Ubuntu Developerhttp://www.ubuntulinux.org
Debian GNU/Linux Developer   http://www.debian.org


signature.asc
Description: Digital signature

Re: Bug#280435: ITP: libkexif -- KDE library to read/edit EXIF informations

[Hamish Moffatt]

On Wed, Nov 10, 2004 at 07:15:18PM +1100, Ben Burton wrote:
> > > Libkexif is a KDE library for manipulating EXIF information embedded in
> > > images. It currently supports viewing of all EXIF information via
> > > libexif. It also supports the modification of a few attributes in a save
> > > way that preserves all other EXIF information in the file. It can
> > > currently modify the following tags:
> > 
> > Given that it sounds like it's non-graphical, what does it do that
> > libexif doesn't, and why does KDE need its own EXIF library?
> 
> Because it is graphical (says me after taking a lightning look in the
> upstream CVS).  And moreover it makes use of the regular libexif, as
> Achim's description points out.

OK. (The description didn't mention that it was graphical.)

libexif already has some widgets I see. Pity that libkexif couldn't be
one more:

libexif-dev - The EXIF library allows you to parse an EXIF file
(development files)
libexif-gtk-dev - Library providing GTK+ widgets to display/edit EXIF
tags (development files)
libexif-gtk4 - Library providing GTK+ widgets to display/edit EXIF tags
libexif-ruby - EXIF tag parsing Library for ruby (dummy package)
libexif-ruby1.6 - EXIF tag parsing Library for ruby1.6
libexif-ruby1.8 - EXIF tag parsing Library for ruby1.8
libexif10 - The EXIF library allows you to parse an EXIF file


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

Re: Introducing pmount in Debian / New plugdev group

[Nikita V. Youshchenko]

> The removable.sh shell script (pasted below) returns whether a device
> is actually removable by looking at the "removable" sysfs attribute.
> However, this attribute was introduced in the kernel not before 2.6.8.
> This is okay for Ubuntu since it ships with 2.6.8.1, and since even
> Sarge ships with 2.6.8.1 (at some architectures at least), Etch will
> certainly use 2.6.8+ as standard kernel. BTW, I do not want to force
> this solution into Sarge, it is too late in the release cycle for such
> changes (pmount has an RC bug to prevent Sarge migration).

AFAIK, Sarge is going to be released with 2.6.8.1

I think keeping pmount out of sarge is a bad idea. As long as pmount works
(it it is *released* with ubuntu, probably it does), and may be useful at
least from command line, why keep it out?

And if, for whatever reason, sarge will not be released for some more time,
maybe some software that will use pmount will also migrate to sarge.

Re: more current iproute

[Andreas Barth]

* Milan P. Stanic ([EMAIL PROTECTED]) [041110 12:35]:
> Why version is iproute_20041019 while the upstream is
> iproute2-2.6.9-041019? Upstream version is 2.6.9 actually. Date is
> appended to serve as timestamp, I think.

Because changing the version format would be a bad think in a NMU.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Debian Entwicklung für unstable?

[markus . fm . fischer]

Hallo,

Ich habe bereits einige Debian Packete erstellt, von AVM (Kisdnwatch, Kadslwatch etc.), 
die dazugehörigen Kernel Module von AVM mit dem Kernel 2.6.9 werden auch bald folgen.
Das ganze für unstable mit KDE 3.3.1.
Was muss ich machen, um diese auch in unstable mit zu veröffentlichen, oder muss man den offiziellen weg eines debian Entwicklers, 
wie im Internet beschrieben steht, beschreiten?

Vielen Dank!!


Mit freundlichen Grüssen 

Markus Fischer
Meßabteilung

--
IMH - Institut für Motorenbau Prof. Huber GmbH 
Eggenfeldener Strasse 104 
81929 München 

Tel.:    +49 89 930003-71
Fax.:   +49 711 3052170696
Mail: [EMAIL PROTECTED]

Web:   www.imh.de

Re: more current iproute

[Milan P. Stanic]

On Wed, Nov 10, 2004 at 11:18:46AM +0100, Andreas Barth wrote:
> I uploaded the current version of iproute (that also works with current
> 2.6-kernels) to experimental. As this is a major change, any test
> reports are appreciated. Also, a review of the source whether I managed
> to keep all security patches might be a good idea (I'm quite confident
> that I did, but - a independent look might be a good thing).

Finally. Thanks!
It is worth backport to woody. I'm doing that right now.

> Please note that I'm aware that the package documentation is not in the
> best state, but as this was a NMU, I didn't do the changes that I would
> have done with a normal maintainer upload.

Why version is iproute_20041019 while the upstream is
iproute2-2.6.9-041019? Upstream version is 2.6.9 actually. Date is
appended to serve as timestamp, I think.

more current iproute

[Andreas Barth]

Dear all,

I uploaded the current version of iproute (that also works with current
2.6-kernels) to experimental. As this is a major change, any test
reports are appreciated. Also, a review of the source whether I managed
to keep all security patches might be a good idea (I'm quite confident
that I did, but - a independent look might be a good thing).

Please note that I'm aware that the package documentation is not in the
best state, but as this was a NMU, I didn't do the changes that I would
have done with a normal maintainer upload.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Introducing pmount in Debian / New plugdev group

[Martin Pitt]

Hi Marco!

Marco d'Itri [2004-11-09 19:32 +0100]:
> On Nov 09, Martin Pitt <[EMAIL PROTECTED]> wrote:
> 
> > We solved (4) by introducing a new group called 'plugdev'. Every user
> > who is a member of this group can access hotpluggable devices (digital
> > cameras, USB drives etc.). pmount can only be executed by members of
> > this group (it is root:plugdev 750), hal runs in this group to be able
> > to detect file systems (but it does not run in 'disk'), and udev
> > assigns the 'plugdev' group to removable devices (static drives remain
> > in group 'disk').
> I'm not sure about what I should do as the udev maintainer. The default
> udev configuration does not really know for sure if a given device is
> removable.

Our /etc/udev/udev.rules has two new rules directly after the cdrom
and floppy rules:

# put removable IDE/SCSI devices into group 'plugdev' instead of 'disk'
BUS="scsi", KERNEL="sd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", RESULT="1", 
NAME="%k", MODE="0660", GROUP="plugdev"
BUS="ide", KERNEL="hd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", RESULT="1", 
NAME="%k", MODE="0660", GROUP="plugdev"

The removable.sh shell script (pasted below) returns whether a device
is actually removable by looking at the "removable" sysfs attribute.
However, this attribute was introduced in the kernel not before 2.6.8.
This is okay for Ubuntu since it ships with 2.6.8.1, and since even
Sarge ships with 2.6.8.1 (at some architectures at least), Etch will
certainly use 2.6.8+ as standard kernel. BTW, I do not want to force
this solution into Sarge, it is too late in the release cycle for such
changes (pmount has an RC bug to prevent Sarge migration).

However, this udev modification is safe even on older kernels; the
script will always return 0 there, which effectively disables above
rules. If devices are not in the plugdev group, but rather in "disk",
the following features will not work:

- pmount will refuse to mount PCMCIA drives since they look like
  normal IDE adapters; mounting USB and FireWire devices will still
  work, though, because pmount then checks the sysfs ancestry for
  USB/FireWire nodes.

- Media checking will not work (e. g. hal will not recognize the
  insertion of a card into an USB card reader), because hal does not
  run in the "disk" group.

- hal will be unable to detect file systems and device labels on the
  removeable devices for the same reason (not being in "disk").

- Users will be unable to partition, format, and label their USB
  devices.

So hal/pmount/g-v-m will still be able to mount USB sticks, USB hard
drives, iPods, and so on, but will lack some reasonably important
features.

Martin

--- /etc/udev/removable.sh ---
#!/bin/sh -e

# print "1" if device $1 is removable, "0" otherwise.
# The "removable" attribute appeared in Linux 2.6.8; this script will always
# print "0" for earlier kernels.

DEV="${1%[0-9]*}"
REMOVABLE="/sys/block/$DEV/removable"

if [ -e "$REMOVABLE" ]; then
cat "$REMOVABLE"
else
echo "0"
fi
exit 0
--

-- 
Martin Pitt   http://www.piware.de
Ubuntu Developerhttp://www.ubuntulinux.org
Debian GNU/Linux Developer   http://www.debian.org


signature.asc
Description: Digital signature

Bug#280568: ITP: libtommath -- Number theoretic multiple-precision integer library

[Russell Stuart]

Package: wnpp
Severity: wishlist

* Package name: libtommath
  Version : 0.32
  Upstream Author : Tom St Denis <[EMAIL PROTECTED]>
* URL : http://www.lubemobile.com.au/ras/debian/sarge/libtommath/
* License : Public Domain
  Description : Number theoretic multiple-precision integer library

LibTomMath provides highly optimized and portable routines for
a vast majority of integer based number theoretic applications
(including public key cryptography). LibTomMath is not a
cryptographic toolkit itself but it can be used to write one.

Note: This is required by clit, which has also been ITP'ed.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-7-lube-686-smp
Locale: LANG=en_AU, LC_CTYPE=en_AU

Bug#280566: ITP: clit -- Decompiler for Microsoft's .lit ebook format

[Russell Stuart]

Package: wnpp
Severity: wishlist

* Package name: clit
  Version : 1.8
  Upstream Author : [EMAIL PROTECTED]
* URL : http://www.lubemobile.com.au/ras/debian/sarge/clit/
* License : GPL
  Description : Decompiler for Microsoft's .lit ebook format

Convert Microsoft's .lit ebook format back into the raw HTML it
was created from.

Note: this needs libtommath, which is also ITP'ed.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-7-lube-686-smp
Locale: LANG=en_AU, LC_CTYPE=en_AU

Bug#280546: netbase: multiple definitions for ypxfrd in /etc/rpc

[Marco d'Itri]

On Nov 10, Jamie Thompson <[EMAIL PROTECTED]> wrote:

> The current version of the netbase package corrected bug #275244 by
> adding the entry "ypxfrd  600100069" to /etc/rpc.
> 
> I however already had an entry for ypxfrd in my /etc/rpc, "ypxfrd  
> 100069". The addtion of this alternate name violates the unique name policy I 
> thought the lookup tables used. I noticed this when I was updating my LDAP 
> with the alterations and found that I could only have one port number for 
> each service name, leading me to reason this is invalid.

I noticed this, but I have no clue about which one is correct.
I'm waiting for more information.

-- 
ciao, |
Marco | [9114 re8uEw2n5qyC6]


signature.asc
Description: Digital signature

Re: Introducing pmount in Debian / New plugdev group

[Martin Pitt]

Hi!

Henning Makholm [2004-11-09 23:28 +]:
> Scripsit [EMAIL PROTECTED] (Paul Hampson)
> > On Tue, Nov 09, 2004 at 06:41:40PM +0100, Martin Pitt wrote:
> 
> > > We solved (4) by introducing a new group called 'plugdev'. Every user
> > > who is a member of this group can access hotpluggable devices (digital
> > > cameras, USB drives etc.). pmount can only be executed by members of
> > > this group (it is root:plugdev 750),
> 
> This must be be a typo. Surely such a program would need to be suid
> root, i.e. mode 4750 was meant rather than 750. 

Of course, sorry for that. Like mount, pmount of course needs root
privileges to actually do the mounting. Paul, this also solves your
question: a non-suid pmount cannot do anything useful.

Martin

-- 
Martin Pitt   http://www.piware.de
Ubuntu Developerhttp://www.ubuntulinux.org
Debian GNU/Linux Developer   http://www.debian.org


signature.asc
Description: Digital signature

sarge security (was: Re: Release update: please upload to unstable; toolchain; buildds; ...)

[Adrian 'Dagurashibanipal' von Bidder]

On Tuesday 09 November 2004 23.44, Colin Watson wrote:

>   N+0 days
>   Official security support for sarge begins

Will the start of official security support for sarge be announced widely, 
to get as much testing as possible? (Like: general debian-announce, press 
contacts, ...)

-- vbi

-- 
Oops


pgp4KTDwv9ZMr.pgp
Description: PGP signature

Re: Bug#280435: ITP: libkexif -- KDE library to read/edit EXIF informations

[Ben Burton]

> > Libkexif is a KDE library for manipulating EXIF information embedded in
> > images. It currently supports viewing of all EXIF information via
> > libexif. It also supports the modification of a few attributes in a save
> > way that preserves all other EXIF information in the file. It can
> > currently modify the following tags:
> 
> Given that it sounds like it's non-graphical, what does it do that
> libexif doesn't, and why does KDE need its own EXIF library?

Because it is graphical (says me after taking a lightning look in the
upstream CVS).  And moreover it makes use of the regular libexif, as
Achim's description points out.

Ben.

Re: Documentation for upstream software authors

[Adrian 'Dagurashibanipal' von Bidder]

[list policy is not to send cc:s - thank you]

On Tuesday 09 November 2004 17.00, Frank Küster wrote:
> Please do not use language like "brain-dead" in the text of this
> page.

Right - and you're too late, was already removed.

> An other point could be "Use sensible version numbering":

added, thanks.

greetings
-- vbi

-- 
Oops


pgpMr0HMGt7yc.pgp
Description: PGP signature

Re: Bug#280435: ITP: libkexif -- KDE library to read/edit EXIF informations

[Hamish Moffatt]

On Tue, Nov 09, 2004 at 03:18:59PM +0100, Achim Bohnet wrote:
> * Package name: libkexif
[..]
>   Description : KDE library to read/edit EXIF informations
> 
> Libkexif is a KDE library for manipulating EXIF information embedded in
> images. It currently supports viewing of all EXIF information via
> libexif. It also supports the modification of a few attributes in a save
> way that preserves all other EXIF information in the file. It can
> currently modify the following tags:

Given that it sounds like it's non-graphical, what does it do that
libexif doesn't, and why does KDE need its own EXIF library?

Next: libkc, being the KDE version of gnu libc...

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

Bug#280553: portmap: do NOT silently switch to localhost only operation !

[Michael Neuffer]

Package: portmap
Version: 5-5
Severity: serious

portmap should not silently switch to listening
to the localhost interface only.

This behaviour breaks things for every networked machine
that uses NFS for example.

This should not be the default behaviour.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-rc4-mm1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages portmap depends on:
ii  libc6   2.3.2.ds1-18 GNU C Library: Shared libraries an
ii  libwrap07.6.dbs-6Wietse Venema's TCP wrappers libra

-- no debconf information

Re: Bug#280539: ITP: conspy -- Remote control of Linux virtual consoles

[Ricardo Mones]

On Wed, 10 Nov 2004 11:43:39 +1000
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

>   Version : x.y.z
> * License : (GPL, LGPL, BSD, MIT/X, etc.)

  Haven't you decided the license and version yet?  

>   Description : Remote control of Linux virtual consoles
> 
> Conspy allows a (possibly remote) user to see what is displayed
> on a Linux virtual console, and send keystrokes to it.  It is
> rather like VNC, but where VNC takes control of a GUI conspy
> takes control of a text mode virtual console.  Unlike VNC,
> conspy does not require a server to be installed prior to being
> used.

  Any advantage over screen running in a virtual console?
-- 
  Ricardo Mones Lastra - [EMAIL PROTECTED]
  Centro de Inteligencia Artificial, Universidad de Oviedo en Gijon
  33271 Asturias, SPAIN. - http://www.aic.uniovi.es/mones