Re: Guidelines for packaging projects on Alioth

2006-04-21 Thread Raphael Hertzog
Russ wrote:
> > In fact, upload notifications (the one that includes the changelog) are
> > not, so far as I can tell, sent to the maintainer by default and I end up
> > subscribing to the PTS to get those even for packages where I'm the only
> > maintainer.

I subscribe to debian-devel-changes for that. :-)

On Fri, 21 Apr 2006, Mike Hommey wrote:
> ... and maintainers should be subscribed to that by default.

There's room for improvement indeed.

I would be in favor of a tighter integration between the PTS and the
@packages.debian.org email address too for example.

I could implement a default subscription to the PTS for package
maintainers but you first need to solve several problems:
- decide which keywords they will receive by default (all except bts,
  bts-control and upload-binary is my choice, and maybe katie-other)
- when the maintainer changes, we logically need to unsubcribe the previous.
  So this must be recorded somewhere. (it's not a subscription like the
  others)
- in many cases, the maintainer doesn't want the "diff" since there's a
  dedicated mailing list for that on alioth ... is it OK if we leave the
  problem up to the maintainer to change the set of keyword accepted ?

Of course help to implement it is always welcome...

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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



Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Florian Weimer
* Adam Borowski:

> Idea: if /etc/iftab is present on upgrade, you can consume it,
> producing relevant rules in that place (and displaying a message to
> the admin).

There's also /etc/mactab, which is processed by nameif (from the
net-tools package).  Ideally, this one should be processed, too.

This does not address the vlan breakage, though.


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



Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Florian Weimer
* Marco d'Itri:

> On Apr 20, Florian Weimer <[EMAIL PROTECTED]> wrote:
>
>> This looks like a bug in udev.  It should not try to identify devices
>> based on names a user can and will change.

> I think I missed which alternative design you are proposing.

I'm not familiar with udev, sorry.

This change also broke the vlan package, which hasn't got to do much
with interface renaming (from a user perspective).  New VLAN
interfaces are called "eth0.1_ifrename" instead of "eth0.1".


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



Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Marco d'Itri
On Apr 21, Florian Weimer <[EMAIL PROTECTED]> wrote:

> This change also broke the vlan package, which hasn't got to do much
> with interface renaming (from a user perspective).  New VLAN
> interfaces are called "eth0.1_ifrename" instead of "eth0.1".

Interesting, I think this happens because eth0 and eth0.1 have the same
MAC address.
Can you try to add this to the top of persistent-net-generator.rules?

KERNEL=="*.*", GOTO="persistent_net_generator_end"

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Florian Weimer
* Marco d'Itri:

> On Apr 21, Florian Weimer <[EMAIL PROTECTED]> wrote:
>
>> This change also broke the vlan package, which hasn't got to do much
>> with interface renaming (from a user perspective).  New VLAN
>> interfaces are called "eth0.1_ifrename" instead of "eth0.1".
>
> Interesting, I think this happens because eth0 and eth0.1 have the same
> MAC address.
> Can you try to add this to the top of persistent-net-generator.rules?
>
> KERNEL=="*.*", GOTO="persistent_net_generator_end"

No visible change.

There's an error message in the syslog:

Apr 21 10:05:30 l udevd-event[6705]: rename_net_if: error changing net 
interface name eth0.1_ifrename to eth0: timeout

Sometimes, the error message is "Device or resource busy".

By the way, are there any other names managed by udev where the name
cannot be changed while the object is in use?  Maybe this is part of
the problem here.  It's impossible to rename a network interface while
it is being used.


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



Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Marco d'Itri
On Apr 20, Adam Borowski <[EMAIL PROTECTED]> wrote:

> Idea: if /etc/iftab is present on upgrade, you can consume it, producing 
> relevant rules in that place (and displaying a message to the admin).
An even better idea is, on the upgrade introducing persistent interface
names, to write rules which reflect the current names no matter what
configured them.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Steve Langasek
On Fri, Apr 21, 2006 at 10:19:46AM +0200, Marco d'Itri wrote:
> On Apr 20, Adam Borowski <[EMAIL PROTECTED]> wrote:

> > Idea: if /etc/iftab is present on upgrade, you can consume it, producing 
> > relevant rules in that place (and displaying a message to the admin).
> An even better idea is, on the upgrade introducing persistent interface
> names, to write rules which reflect the current names no matter what
> configured them.

And also, I hope, on initial install of udev?

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


signature.asc
Description: Digital signature


Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Marco d'Itri
On Apr 21, Florian Weimer <[EMAIL PROTECTED]> wrote:

> > KERNEL=="*.*", GOTO="persistent_net_generator_end"
> 
> No visible change.
> 
> There's an error message in the syslog:
> 
> Apr 21 10:05:30 l udevd-event[6705]: rename_net_if: error changing net 
> interface name eth0.1_ifrename to eth0: timeout
I think that something is wrong here, because it should not even try
renaming eth0.1.

> Sometimes, the error message is "Device or resource busy".
> 
> By the way, are there any other names managed by udev where the name
> cannot be changed while the object is in use?  Maybe this is part of
> the problem here.  It's impossible to rename a network interface while
> it is being used.
No, only network interfaces are special.
But why would they be in use at the time udev runs? It's very early in
the boot process.
Actually, at that time VLANs have not been created yet. OTOH I can see
that if they were created and the subinterfaces raised asyncronously in
a boot script then there would be a race with udev. (Not that it really
matters since they are not supposed to be renamed anyway.)

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: Bug#361418: [Proposal] new Debian menu structure

2006-04-21 Thread Jon Dowland
At 1145044383 past the epoch, Linas Žvirblis wrote:
> Manoj Srivastava wrote:
> 
> > Amateur radio is the dumb name, for people who
> > are confused by what the practioners call it --
> > HAM radio.
> 
> It is translated as "amateur radio" to some languages.
> Others translate it entirely to something specific to that
> language. And some use HAM.
> 
> Can you claim that HAM is the most common name for this
> worldwide?

One advantage of specifying this in the menu policy is ease
of translations (whereas previously, the hints system was
impossible to translate). Therefore, if it is referred to
predominantly as "Ham Radio" in one locale and "Amateur
Radio" in another, could we not accommodate both?


-- 
Jon Dowland
http://alcopop.org/


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



Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Marco d'Itri
On Apr 21, Steve Langasek <[EMAIL PROTECTED]> wrote:

> > An even better idea is, on the upgrade introducing persistent interface
> > names, to write rules which reflect the current names no matter what
> > configured them.
> And also, I hope, on initial install of udev?
Yes, and in d-i too.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Steve Langasek
On Fri, Apr 21, 2006 at 11:47:45AM +0200, Marco d'Itri wrote:
> On Apr 21, Steve Langasek <[EMAIL PROTECTED]> wrote:

> > > An even better idea is, on the upgrade introducing persistent interface
> > > names, to write rules which reflect the current names no matter what
> > > configured them.
> > And also, I hope, on initial install of udev?
> Yes, and in d-i too.

This was actually why I was asking. :)  Does d-i really need to do anything
here, or can it simply depend on the udev postinst to take care of it all in
the chrooted target?

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


signature.asc
Description: Digital signature


Re: Installation is FANTASTIC!!!

2006-04-21 Thread Wouter Verhelst
On Fri, Apr 21, 2006 at 08:14:10AM +0200, Wolfgang Lonien wrote:
> Adrian von Bidder wrote:
> >  How do I bind a computer to an NIS server?
> >  Use a rope?
> > -- Seen on #Debian
> 
> That was a good one! Was it Joey H. or Joey S.? Anyway: thanks for
> sharing this with us :-)

 is Joey Schulze;  is Joey Hess.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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



Re: locales broken?

2006-04-21 Thread Sam Morris
On Fri, 21 Apr 2006 08:29:09 +0200, Michael Biebl wrote:

> Bastian Venthur wrote:
>> James Vega wrote:
> 
> [..]
> 
>> So should I file a bug against KDE(M) for not respecting
>> /etc/default/locale?
> 
> Known bug [1]. A corresponding bug report for gdm has been filed too
> already.
> 
> Cheers,
> Michael
> 
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361089
> 
> Attachment not shown: MIME type application/pgp-signature; filename 
> signature.asc

Using pam_env breaks the expectation that /etc/default/locale be a
shell script (that gets sourced at some point during login). Why not
place a script in /etc/X11/Xsession.d that sources it? It can also be
sourced in /etc/profile to cover text-mode logins. Maybe it's too late for
this anyway, now. :(

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

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


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



Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Marco d'Itri
On Apr 21, Steve Langasek <[EMAIL PROTECTED]> wrote:

> This was actually why I was asking. :)  Does d-i really need to do anything
> here, or can it simply depend on the udev postinst to take care of it all in
> the chrooted target?
No, currently postinst when run in a chroot does as little as possible
and probably it's better to keep it this way.

I am not sure if it's a good idea to unconditionally create the rules
in chroot installs, I'd rather do it only if postinst is running in a
d-i chroot. Is there a test which I can use for this?

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: Guidelines for packaging projects on Alioth

2006-04-21 Thread Simon Huggins
On Thu, Apr 20, 2006 at 08:49:58AM +0200, Raphael Hertzog wrote:
> On Thu, 20 Apr 2006, Simon Huggins wrote:
> > On Wed, Apr 19, 2006 at 11:13:13PM +0200, Raphael Hertzog wrote:
> > > * All existing packaging projects should use svnmailer to send SVN diffs
> > >   to the Package Tracking System. A sample configuration file is provided
> > >   and I can help if you have troubles installing it. 
> > Are you proposing that existing projects that send to a project mailing
> > list should change and send to the PTS and if so can you put forward
> > some reasons?
> No, I'm not proposing that. I'm just asking to send diffs to the PTS
> as well as to the mailing list.
> I even documented that configuration in the sample configuration file.

Sure the config file was clearer on that than your mail certainly.

> That's what I've done with python-modules recently. Some people
> subscribe to the -commits list because they are very involved in the
> team and other just use the PTS to follow the 2-3 packages that are of
> interest to them.

Yes this makes more sense now.  I must admit I still thought the PTS was
only really a way to get all the bugs for a package.

Is there a reason that when you subscribe to the PTS you don't just get
everything by default?

(cf 
http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pkg-tracking-system
 )

I'll go look at adding the PTS to pkg-xfce now anyway.

Simon

-- 
... "Did someone say they wanted toast?" -- Talkie Toaster


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



Bug#364065: ITP: libconvert-pem-perl -- Read/write encrypted ASN.1 PEM files for perl

2006-04-21 Thread Pierre-Matthieu Alamy
Package: wnpp
Severity: wishlist
Owner: "Pierre-Matthieu Alamy" <[EMAIL PROTECTED]>

* Package name: libconvert-pem-perl
  Version : 0.07
  Upstream Author : Benjamin Trott <[EMAIL PROTECTED]>
* URL : http://www.cpan.org/modules/by-module/Convert/
* License : Artistic
  Programming Lang: Perl
  Description : Read/write encrypted ASN.1 PEM files for perl

Convert::PEM reads and writes PEM files containing ASN.1-encoded objects. The 
files can optionally be encrypted using a 
symmetric cipher algorithm, such as 3DES.

-- 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.15
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)


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



Re: Marking BTS spam

2006-04-21 Thread Julian Gilbey
Just saw this thread mentioned on DWN.

Do you know about "bts reportspam NN" or "bts spamreport NN"
in the devscripts package?  Might do just what you want :)

   Julian


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



Bug#364066: ITP: libdata-buffer-perl -- Read/write buffer class for perl

2006-04-21 Thread Pierre-Matthieu Alamy
Package: wnpp
Severity: wishlist
Owner: "Pierre-Matthieu Alamy" <[EMAIL PROTECTED]>

* Package name: libdata-buffer-perl
  Version : 0.04
  Upstream Author : Benjamin Trott <[EMAIL PROTECTED]>
* URL : http://www.cpan.org/modules/by-module/Data/
* License : Artistic
  Programming Lang: Perl
  Description : Read/write buffer class for perl

Data::Buffer implements a low-level binary buffer in which you can get and put 
integers, strings, and other data. Internally 
the implementation is based on pack and unpack, such that Data::Buffer is 
really a layer on top of those built-in functions.

-- 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.15
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)


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



Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Gabor Gombas
On Thu, Apr 20, 2006 at 09:23:00PM +0200, Marco d'Itri wrote:

> > This looks like a bug in udev.  It should not try to identify devices
> > based on names a user can and will change.

> I think I missed which alternative design you are proposing.

AFAIK the only correct way to identify a network interface is its index.
That will remain constant even when the name changes, and will be
different even if you remove one module and insert an other one that
happens to claim the same in-kernel name.

Since there is a 1-1 connection between the interface index and the
in-kernel data structure, it is the ideal (and only) identifier udev
should use.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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



Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Marco d'Itri
On Apr 21, Gabor Gombas <[EMAIL PROTECTED]> wrote:

> Since there is a 1-1 connection between the interface index and the
> in-kernel data structure, it is the ideal (and only) identifier udev
> should use.
Too bad that it is not what the kernel reports in the hotplug events and
that there are no symlinks in sysfs to access a kobject by its ifindex.
Sending a patch RFC to LKML would be the first step to improve this.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: AMD64: etch and uploads

2006-04-21 Thread Goswin von Brederlow
Kurt Roeckx <[EMAIL PROTECTED]> writes:

> On Tue, Apr 18, 2006 at 12:17:54PM -0400, Stefano Zacchiroli wrote:
>> On Wed, Apr 19, 2006 at 12:41:50AM +1000, Anthony Towns wrote:
>> > Developers with amd64 machines are also now able to upload new versions
>> > of their package built locally (rather than in an i386 chroot) -- but
>> > in order to ensure dependencies are calculated correctly, please make
>> > sure you're building using Debian unstable and not packages from Ubuntu
>> > or the unofficial debian-amd64 archive; using pbuilder or debootstrap
>> > to create a chroot build environment might be helpful in this case.
>> 
>> In order to fulfill this requirement, is there a best practice / any
>> possible way to "convert" an amd64 box which has been installed from
>> debian-amd64 to an official debian amd64 box?
>
> I use the following:
> apt-get clean
> apt-get --reinstall install -d `dpkg --get-selections |grep -v deinstall | 
> sed -e 's/\t.*//' `
> cd /var/cache/apt/archives
> dpkg -i *.deb
>
> You can't do it without the -d, apt-get seems to have a problem
> with depedency loops.
>
> Note that it might complain about packages it can't (re)install,
> in my case those were all packages that have been replaced.  You
> should remove those.
>
>
> Kurt

I'm assuming you want this for your normal system and not for a build
chroot. Always build packages for upload in a clean environment one
last time before upload.

So here we go, way 2 (from memory):

# Mark all old packages
mv /var/lib/dpkg/status /var/lib/dpkg/status~
sed 's/Status:/Unofficial: yes\nStatus:/' /var/lib/dpkg/status

# reinstall
apt-get clean
dpkg --get-selections |grep -v deinstall | sed -e 's/\t.*//' \
| xargs -n1 apt-get --reinstall install

# check output for obsolete or missing packages
# optimaly there should be none
grep-dctrl -P Unofficial yes -s Package,Version /var/lib/dpkg/status

MfG
Goswin



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



Bug#364077: ITP: libcrypt-dsa-perl -- DSA Signatures and Key Generation for perl

2006-04-21 Thread Pierre-Matthieu Alamy
Package: wnpp
Severity: wishlist
Owner: "Pierre-Matthieu Alamy" <[EMAIL PROTECTED]>

* Package name: libcrypt-dsa-perl
  Version : 0.13
  Upstream Author : Benjamin Trott <[EMAIL PROTECTED]>
* URL : http://www.cpan.org/modules/by-module/Crypt/
* License : Artistic
  Programming Lang: Perl
  Description : DSA Signatures and Key Generation for perl

Crypt::DSA is an implementation of the DSA (Digital Signature Algorithm) 
signature verification system. The implementation 
itself is pure Perl, although the heavy-duty mathematics underneath are 
provided by the Math::Pari library.

This package provides DSA signing, signature verification, and key generation.

-- 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.15
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)


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



Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge

2006-04-21 Thread Manoj Srivastava
Hi,

Here is my solution for using vim + script as a pager; similar
 mechanisms can be used to use plain vim as PAGER as well.

,
| #!/bin/bash
| # Shell script to start Vim with less.vim.
| # Read stdin if no arguments were given.
| 
| #VRUNTIME=/usr/share/vim/vim64/
| VRUNTIME=$HOME/etc/vim/
| if test $# = 0; then
|   vim -c "so $VRUNTIME/macros/less.vim" -
| else
|   vim -c "so $VRUNTIME/macros/less.vim" "$@"
| fi
`

I take no credit for the vim script or the idea, but it seems
 to work pretty well. Note how the vim invocation changes based on
 whether the PAGER is being used as a filter or not.

manoj
-- 
"When in doubt, use brute force." Ken Thompson
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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



Re: Guidelines for packaging projects on Alioth

2006-04-21 Thread Raphael Hertzog
On Fri, 21 Apr 2006, Simon Huggins wrote:
> Sure the config file was clearer on that than your mail certainly.

:-)

> Yes this makes more sense now.  I must admit I still thought the PTS was
> only really a way to get all the bugs for a package.
> 
> Is there a reason that when you subscribe to the PTS you don't just get
> everything by default?

Yes, the PTS is not a "developer-only" tool. It's also for users who care
about a specific software in Debian and they certainly don't care about
the diff of the packaging. They do want to know when a new version comes
out and they may help duplicating bugs and so on. But not much more.

(Well, that's the theory, I never did any study of who the subscribers
are)

> I'll go look at adding the PTS to pkg-xfce now anyway.

Thanks!

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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



Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge

2006-04-21 Thread Loïc Minier
Hi,

On Fri, Apr 21, 2006, Manoj Srivastava wrote:
> Here is my solution for using vim + script as a pager; similar
>  mechanisms can be used to use plain vim as PAGER as well.

 Nice, I suggest filing a new bug against vim to propose this as a
 contrib script, or to ship it as "vim-pager" wrapper.

 #363250 is more about documenting the semantics of $PAGER (whether it
 can uses sh syntax, or whether it's a command with parameters separated
 with spaces), to be documented in man man, and/or policy.

 There's also another bug discussed in #363250 which is about nview's
 view not working correctly, but I didn't look into that.

   Bye,

-- 
Loïc Minier <[EMAIL PROTECTED]>
"You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04


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



Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge

2006-04-21 Thread James Vega
On Fri, Apr 21, 2006 at 08:36:10AM -0500, Manoj Srivastava wrote:
> Hi,
> 
> Here is my solution for using vim + script as a pager; similar
>  mechanisms can be used to use plain vim as PAGER as well.
> 
[snip script]

There is already a less.sh that does this, which is in the same
directory (/usr/share/vim/vimcurrent/macros) as less.vim.

James
-- 
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature


Re: Installation is FANTASTIC!!!

2006-04-21 Thread Marc Singer
On Fri, Apr 21, 2006 at 08:14:10AM +0200, Wolfgang Lonien wrote:
> And for those who still are complaining about the installer not being
> graphical: please, guys, there's more than your x86 machines. Keep that
> in mind. And where is the difference between a mouse click and a return
> key (yes, it's - mostly - that easy!)?

Hear hear.

I installed Debian with the etch installer to a new AMD64 machine.
The only hitch was that I had to use expert mode because the one of
the via drivers crashed the system.  It handled LVM on RAID deftly.


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



Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Jim Crilly
On 04/21/06 10:19:46AM +0200, Marco d'Itri wrote:
> On Apr 20, Adam Borowski <[EMAIL PROTECTED]> wrote:
> 
> > Idea: if /etc/iftab is present on upgrade, you can consume it, producing 
> > relevant rules in that place (and displaying a message to the admin).
> An even better idea is, on the upgrade introducing persistent interface
> names, to write rules which reflect the current names no matter what
> configured them.

But won't that miss any devices that aren't in the system right at that
moment, such as PCMCIA/USB wifi cards?

Jim.


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



Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Marco d'Itri
On Apr 21, Jim Crilly <[EMAIL PROTECTED]> wrote:

> > An even better idea is, on the upgrade introducing persistent interface
> > names, to write rules which reflect the current names no matter what
> > configured them.
> But won't that miss any devices that aren't in the system right at that
> moment, such as PCMCIA/USB wifi cards?

Yes, but there is other code to deal with this.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Guus Sliepen
On Thu, Apr 20, 2006 at 01:43:07AM +0200, Marco d'Itri wrote:

> > Besides the fact that ifrename is more of a hack, now that udev enables
> > persistent naming of interfaces (z25_persistent-net.rules) udev should
> > conflict with ifrename. Otherwise the user could get unexpected results
> > if /etc/iftab still exists and the ifrename init script tries to rename the
> > interfaces (again) with possibly different names than the ones set in
> > z25_persistent-net.rules.
> 
> If you have not noticed yet, the latest udev release by default
> automatically generates rules to have persistent names for network
> interfaces.
> 
> I am inclined to agree with the bug reporter, but I want to double check
> and ask if anybody has other arguments.

I'm sure there are people who use both ifrename and udev, and if udev
Conflicts: with ifrename, and I get bugreports about ifrename being
uninstallable together with udev, I'll reassign them to udev. The two
packages coexist peacefully, but if a user fills in both /etc/iftab and
z25_persistent-net.rules I say he is on his own. A warning in
README.Debian or in debconf is perhaps warranted though.

-- 
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature


Re: Guidelines for packaging projects on Alioth

2006-04-21 Thread Mike Hommey
On Fri, Apr 21, 2006 at 09:01:53AM +0200, Raphael Hertzog <[EMAIL PROTECTED]> 
wrote:
> Russ wrote:
> > > In fact, upload notifications (the one that includes the changelog) are
> > > not, so far as I can tell, sent to the maintainer by default and I end up
> > > subscribing to the PTS to get those even for packages where I'm the only
> > > maintainer.
> 
> I subscribe to debian-devel-changes for that. :-)
> 
> On Fri, 21 Apr 2006, Mike Hommey wrote:
> > ... and maintainers should be subscribed to that by default.
> 
> There's room for improvement indeed.
> 
> I would be in favor of a tighter integration between the PTS and the
> @packages.debian.org email address too for example.
> 
> I could implement a default subscription to the PTS for package
> maintainers but you first need to solve several problems:
> - decide which keywords they will receive by default (all except bts,
>   bts-control and upload-binary is my choice, and maybe katie-other)

I'd say upload-binary should be sent to the maintainer. It helps seing
when stuff are built and uploaded, and when binNMU occur.

> - when the maintainer changes, we logically need to unsubcribe the previous.
>   So this must be recorded somewhere. (it's not a subscription like the
>   others)

Isn't that a non issue if you subscribe @p.d.o ?

Mike


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



Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Marco d'Itri
On Apr 21, Guus Sliepen <[EMAIL PROTECTED]> wrote:

> I'm sure there are people who use both ifrename and udev, and if udev
Which part of "ifrename does not work with udev" you did not understand?

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Guus Sliepen
On Fri, Apr 21, 2006 at 10:32:21PM +0200, Marco d'Itri wrote:

> > I'm sure there are people who use both ifrename and udev, and if udev
> Which part of "ifrename does not work with udev" you did not understand?

The part where both work fine simultaneously on my own machines.

-- 
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature


Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Mike Hommey
On Thu, Apr 20, 2006 at 01:43:07AM +0200, Marco d'Itri <[EMAIL PROTECTED]> 
wrote:
> If you have not noticed yet, the latest udev release by default
> automatically generates rules to have persistent names for network
> interfaces.
> 
> I am inclined to agree with the bug reporter, but I want to double check
> and ask if anybody has other arguments.

The thing is that you could have ifrename installed for those older
kernels that don't support udev. But that would mean there should be
some way to disable ifrename depending on the kernel running and/or the
udev support for naming interfaces.

Mike


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



Re: libglew1: Newer upstream version is available

2006-04-21 Thread Arnaud Quette
I'd like to take care of updating it (1.3.4 available) as we're
working, with Christian Marillat, on Jahshaka packaging (ITP #335249)
which requires it.

If nobody steps up, we'll upload 1.3.4 during the week.

Arnaud
--
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/



Work-needing packages report for Apr 21, 2006

2006-04-21 Thread 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: 294 (new: 10)
Total number of packages offered up for adoption: 84 (new: 2)
Total number of packages requested help for: 19 (new: 0)

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



The following packages have been orphaned:

   3dchess (#363498), orphaned yesterday
 Description: 3D chess for X11
 Installations reported by Popcon: 220

   alltraxclock (#362929), orphaned 4 days ago
 Description: analog clock plugin for GKrellM
 Installations reported by Popcon: 116

   alltraxclock2 (#362930), orphaned 4 days ago
 Description: An analog clock plugin for GKrellM2
 Installations reported by Popcon: 130

   distributed-net (#363503), orphaned yesterday (non-free)
 Description: donate unused CPU cycles - client for distributed.net
   [non-free]
 Reverse Depends: gkrelldnet
 Installations reported by Popcon: 115

   epic4-script-light (#363500), orphaned yesterday
 Description: Light - It's Just Not Lame
 Installations reported by Popcon: 32

   hwb (#363504), orphaned yesterday (non-free)
 Description: The Hardware Book
 Installations reported by Popcon: 126

   pfe (#363497), orphaned yesterday
 Description: Portable Forth Environment, ANS standard, all wordsets.
 Reverse Depends: pfe-dev
 Installations reported by Popcon: 20

   rhyme (#363499), orphaned yesterday
 Description: console based rhyming dictionary
 Installations reported by Popcon: 34

   sysadmin-guide (#363501), orphaned yesterday
 Description: The Linux System Administrators' Guide
 Installations reported by Popcon: 193

   unalz (#362995), orphaned 4 days ago
 Description: The utility used for decompressing alzip format file.
 Installations reported by Popcon: 219

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

   noffle (#362879), offered 4 days ago
 Description: offline news server
 Installations reported by Popcon: 10

   obexserver (#363689), offered today
 Description: Receive files with OBEX protocol
 Installations reported by Popcon: 207

82 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 301 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-server
 Installations reported by Popcon: 53

   athcool (#278442), requested 541 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 207

   cvs (#354176), requested 56 days ago
 Description: Concurrent Versions System
 Reverse Depends: bonsai cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvsconnect cvsd cvsdelta cvsps cvsreport (15 more omitted)
 Installations reported by Popcon: 6802

   docbook (#358522), requested 29 days ago
 Description: standard SGML representation system for technical
   documents
 Reverse Depends: alcovebook-sgml docbook-dsssl docbook-to-man
   sgmltools-lite
 Installations reported by Popcon: 3364

   docbook-xml (#358520), requested 29 days ago
 Description: standard XML documentation system, for software and
   systems
 Reverse Depends: dblatex docbook-dsssl docbook-ebnf
   docbook-html-forms docbook-jrefentry docbook-mathml docbook-simple
   docbook-slides docbook-website docbook-xsl-stylesheets-ko (6 more
   omitted)
 Installations reported by Popcon: 7381

   dpkg (#282283), requested 516 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source and apt-build apt-src backuppc
   build-essential clamsmtp crosshurd cvs-autoreleasedeb (87 more
   omitted)
 Installations reported by Popcon: 12182

   grub (#248397), requested 710 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: dfsbuild grub-splashimages grubconf replicator
 Installations reported by Popcon: 9010

   gtkpod (#319711), requested 270 days ago
 Description: manage songs and playlists on an Apple iPod
 Installations reported by Popcon: 302

   mwavem (#313369), requested 311 days ago (non-free)
 Description: Mwave/ACP modem support software
 Installations reported by Popcon: 4

   nas (#354174), requested 56 days ago
 Description: The Network Audio System
   

Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Wouter Verhelst
On Fri, Apr 21, 2006 at 10:32:21PM +0200, Marco d'Itri wrote:
> On Apr 21, Guus Sliepen <[EMAIL PROTECTED]> wrote:
> 
> > I'm sure there are people who use both ifrename and udev, and if udev
> Which part of "ifrename does not work with udev" you did not understand?

Which part of "let the user shoot his own foot if he so desires" is so
impossible for you to understand? In, like, everything?

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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



Re: Guidelines for packaging projects on Alioth

2006-04-21 Thread Simon Huggins
On Fri, Apr 21, 2006 at 03:46:36PM +0200, Raphael Hertzog wrote:
> On Fri, 21 Apr 2006, Simon Huggins wrote:
> > I'll go look at adding the PTS to pkg-xfce now anyway.
> Thanks!

Except as discussed on IRC in #alioth it sends to the first package
affected if many packages are so I've not added this in yet.

We're sending to our list (as we have been for ages) for now.

Simon.

-- 
"I fought in the Korean war, you know.  I killed four men..." - Basil "He
was in the catering corps.  He poisoned them." - Sybil, Fawlty Towers


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



Bug#364082: ITP: python-markdown -- text-to-HTML conversion library/tool

2006-04-21 Thread Fredrik Steen
Package: wnpp
Severity: wishlist
Owner: Fredrik Steen <[EMAIL PROTECTED]>

* Package name: python-markdown
  Version : 1.4
  Upstream Author : Yuri Takhteyev <[EMAIL PROTECTED]>
* URL : http://www.freewisdom.org/projects/python-markdown/index.php
* License : GPL
  Programming Lang: Python
  Description : text-to-HTML conversion library/tool

Markdown is a text-to-HTML conversion tool for web writers. Markdown
allows you to write using an easy-to-read, easy-to-write plain text
format, then convert it to structurally valid XHTML (or HTML).

This is a Python implementation of John Gruber's Markdown. The current
version of python-markdown implements all Markdown syntax features and
fully passes Markdown Test Suite 1.0. It also supports footnotes and
attributes.

Will be maintained by Debian Python Modules Team.


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



Re: libglew1: Newer upstream version is available

2006-04-21 Thread Joost Yervante Damad
On Friday 21 April 2006 23:12, Arnaud Quette wrote:
> I'd like to take care of updating it (1.3.4 available) as we're
> working, with Christian Marillat, on Jahshaka packaging (ITP #335249)
> which requires it.
>
> If nobody steps up, we'll upload 1.3.4 during the week.

An 1.3.4 package is about to be uploaded by Marcello.

Greetings, Joost Damad

-- 
The planet Andete is famous for it's killer edible poets.


pgpQh8JWw0G72.pgp
Description: PGP signature


Re: Guidelines for packaging projects on Alioth

2006-04-21 Thread Andreas Metzler
Mike Hommey <[EMAIL PROTECTED]> wrote:
[...]
> I'd say upload-binary should be sent to the maintainer. It helps seing
> when stuff are built and uploaded,
[...]

Hello,
Eh no. I am not interested at all that the gazillion of build-daemons
grab my package and upload it to Debian.[1] For me that's just >10
*useless* mails for every upload I do.

> and when binNMU occur.

I guess more people are interested in that, but this should be
different keyword triggered when debian-release marks a package for
bin-NMU, but not for the >10 separate uploads.
cu andreas
[1] I am interested when they do not build package, of course. ;-)
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


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



Re: Bug#363598: udev should conflict with ifrename

2006-04-21 Thread Florian Weimer
* Marco d'Itri:

> On Apr 21, Guus Sliepen <[EMAIL PROTECTED]> wrote:
>
>> I'm sure there are people who use both ifrename and udev, and if udev
> Which part of "ifrename does not work with udev" you did not understand?

Certainly nameif works with udev.  Why should I care about missed
events for my non-pluggable Ethernet devices?  It's not that they
should go away when the link goes down or something like that.


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