Re: Terminal emulators and command line arguments (again!)

[Samuel Thibault]

Sune Vuorela, le Mon 13 Oct 2008 05:34:25 +, a écrit :
> On 2008-10-12, Steve McIntyre <[EMAIL PROTECTED]> wrote:
> > Sune wrote:
> >>I dont think supporting title and stuff should be required for providing
> >>x-terminal-emulator. I think we could require to handle -e properly, but
> >>not much more than that.
> >
> > Out of curiosity, why not support setting of title etc.? That's the
> > main thing I'm considering here, in fact...
> 
> I don't know if I see the need for setting the title at all?

When you have a bunch of windows, it's quite useful to be able to find
out the one you want in just a window list.

Samuel


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

Re: watch file problem

[Laurent Guignard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pierre Habouzit a écrit :
> On Sun, Oct 12, 2008 at 07:53:22PM +, Laurent Guignard wrote:
>> Hi mentors,
>>
>> I wrote a watch file like this :
>>
>> version=3
>> opts=filenamemangle=s/dhcp_probe/dhcp-probe/ \
>>  http://www.net.princeton.edu/software/dhcp_probe/dhcp_probe-(.*).tar.gz
>>
>> The URL to download the source file is :
>> http://www.net.princeton.edu/software/dhcp_probe/dhcp_probe-1.2.1.tar.gz
>>
>> When i do the uscan command i have his message :
>> "dhcp-probe: remote site does not even have current version"
> 
> What is your current changelog entry ? (its first line will be just
> fine).

My changelog first line :
dhcp-probe (1.2.2a-1) unstable; urgency=low

- --
Laurent Guignard, Registered as user #301590 with the Linux Counter
Site : http://www.famille-guignard.org
Blog : http://blog.famille-guignard.org
Projet : http://sicontact.sourceforge.net
GULL de Villefranche sur Saône : http://www.cagull.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI8wBgjcKpXFc/7oYRAni4AJ0epR9JItEueVeknzfb3DYvTnxRHACglWMm
bVbr9l+9cL2Q5UZtErTA4Q8=
=2U3Y
-END PGP SIGNATURE-


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

Re: watch file problem

[Pierre Habouzit]

On Mon, Oct 13, 2008 at 08:01:36AM +, Laurent Guignard wrote:
> Pierre Habouzit a écrit :
> > On Sun, Oct 12, 2008 at 07:53:22PM +, Laurent Guignard wrote:
> >> Hi mentors,
> >>
> >> I wrote a watch file like this :
> >>
> >> version=3
> >> opts=filenamemangle=s/dhcp_probe/dhcp-probe/ \
> >>  http://www.net.princeton.edu/software/dhcp_probe/dhcp_probe-(.*).tar.gz
> >>
> >> The URL to download the source file is :
> >> http://www.net.princeton.edu/software/dhcp_probe/dhcp_probe-1.2.1.tar.gz
> >>
> >> When i do the uscan command i have his message :
> >> "dhcp-probe: remote site does not even have current version"
> > 
> > What is your current changelog entry ? (its first line will be just
> > fine).
> 
> My changelog first line :
> dhcp-probe (1.2.2a-1) unstable; urgency=low

And you ask why it doesn't work ? You're kidding us right ?

Only 1.2.1 is on http://www.net.princeton.edu/software/dhcp_probe/.

$ uscan --report-status --force-download --watchfile watch --package dhcp-probe 
--upstream-version 1.2.2a
Processing watchfile line for package dhcp-probe...
Newest version on remote site is 1.2.1, local version is 1.2.2a
dhcp-probe: remote site does not even have current version

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


pgp1FJpU353zR.pgp
Description: PGP signature

Re: watch file problem

[Laurent Guignard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pierre Habouzit a écrit :
> On Mon, Oct 13, 2008 at 08:01:36AM +, Laurent Guignard wrote:
>> Pierre Habouzit a écrit :
>>> On Sun, Oct 12, 2008 at 07:53:22PM +, Laurent Guignard wrote:
 Hi mentors,

 I wrote a watch file like this :

 version=3
 opts=filenamemangle=s/dhcp_probe/dhcp-probe/ \
  http://www.net.princeton.edu/software/dhcp_probe/dhcp_probe-(.*).tar.gz

 The URL to download the source file is :
 http://www.net.princeton.edu/software/dhcp_probe/dhcp_probe-1.2.1.tar.gz

 When i do the uscan command i have his message :
 "dhcp-probe: remote site does not even have current version"
>>> What is your current changelog entry ? (its first line will be just
>>> fine).
>> My changelog first line :
>> dhcp-probe (1.2.2a-1) unstable; urgency=low
> 
> And you ask why it doesn't work ? You're kidding us right ?
> 
> Only 1.2.1 is on http://www.net.princeton.edu/software/dhcp_probe/.
> 
> $ uscan --report-status --force-download --watchfile watch --package 
> dhcp-probe --upstream-version 1.2.2a
> Processing watchfile line for package dhcp-probe...
> Newest version on remote site is 1.2.1, local version is 1.2.2a
> dhcp-probe: remote site does not even have current version
> 

Sorry, but i thought that uscan was done to scan according to the watch
file...

Irwin Tillman (upstream coder) sent me this url :
http://www.net.princeton.edu/software/dhcp_probe/dhcp_probe-1.2.2a.tar.gz

that is active an i don't understand why uscan can't discover
dhcp_probe-1.2.2a.tar.gz file !

That why i sent my watch file.

- --
Laurent Guignard, Registered as user #301590 with the Linux Counter
Site : http://www.famille-guignard.org
Blog : http://blog.famille-guignard.org
Projet : http://sicontact.sourceforge.net
GULL de Villefranche sur Saône : http://www.cagull.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI8ymBjcKpXFc/7oYRAkmgAKCLYOLxBbC+IBwnexmd/e2ERY3skQCeJAyF
IfN+S0LyZ8urManY6tADPbE=
=w9iz
-END PGP SIGNATURE-


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

Bug#502063: ITP: conmux -- A abstracted console multiplexor

[Jean Parpaillon]

Package: wnpp
Severity: wishlist
Owner: Jean Parpaillon <[EMAIL PROTECTED]>


* Package name: conmux
  Version : 0r2277
  Upstream Author : Andy Whitcroft <[EMAIL PROTECTED]>
* URL : http://autotest.kernel.org/wiki/Conmux
* License : GPL v2
  Programming Lang: Perl
  Description : A abstracted console multiplexor

CONMUX is a console abstractor. Presenting any console with a
consistent location, naming and semantic.  Access to the console,
and hardreset of the machine is the same regardless of the underlying
access methodology.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)



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

Re: watch file problem

[Clint Adams]

On Mon, Oct 13, 2008 at 12:57:06PM +0200, Laurent Guignard wrote:
> Sorry, but i thought that uscan was done to scan according to the watch
> file...
> 
> Irwin Tillman (upstream coder) sent me this url :
> http://www.net.princeton.edu/software/dhcp_probe/dhcp_probe-1.2.2a.tar.gz
> 
> that is active an i don't understand why uscan can't discover
> dhcp_probe-1.2.2a.tar.gz file !

How is it supposed to find it if it's not linked from the
http://www.net.princeton.edu/software/dhcp_probe/ page?


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

Bug#502121: ITP: sreadahead -- Super Read Ahead

[Julian Andres Klode]

Package: wnpp
Severity: wishlist
Owner: Julian Andres Klode <[EMAIL PROTECTED]>


* Package name: sreadahead
  Version : 0.02
  Upstream Author : Arjan van de Ven <[EMAIL PROTECTED]>
* URL : http://www.moblin.org/projects/fast-boot
* License : GPL-2
  Programming Lang: C
  Description : Super Read Ahead

sReadahead is based on Fedora Readahead, but is modified to take 
advantage of the kernel's new list of blocks read.
.
It allows the user to specify a set of files to be read into the page 
cache to accelerate first time loading of programs, typically during the boot
sequence.

This is just a basic ITP. Real work starts later.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)


signature.asc
Description: Digital signature

Re: Bug#502021: ITP: etoolbox -- Toolbox for LaTeX class and package authors

[Rafael Laboissiere]

* Jan Hauke Rahm <[EMAIL PROTECTED]> [2008-10-12 21:57]:

> Package: wnpp
> Severity: wishlist
> Owner: Jan Hauke Rahm <[EMAIL PROTECTED]>
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA224
> 
> * Package name: etoolbox
>   Version : 1.7
>   Upstream Author : Philipp Lehmann 
> * URL : 
> http://www.ctan.org/tex-archive/help/Catalogue/entries/biblatex.html

Correct URL is
http://www.ctan.org/tex-archive/help/Catalogue/entries/etoolbox.html

-- 
Rafael


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

Re: Lenny upgrade-advisor

[Franklin PIAT]

Hello,

I have re-worked upgrade-advisor to make it pluggable. Also it's now
hosted on collab-maint[1]. This should make it easier for anyone to
submit a plug-in that detects and warns potential issues.

How it works

Before upgrading, running `upgrade-advisor pre-upgrade` will :
* Report post-upgrade recommendations from a previous upgrade, like
  detecting wrong update-grub path in /etc/kernel-img.conf.
* Perform various pre-upgrade test. Currently, it mainly focuses on
  warning for discontinued packages.
  But the long term goal is test all potential issues listed in the
  Release Notes.

After upgrading, running `upgrade-advisor post-upgrade` will :
* Perform some tests to ensure that steps listed in "Preparing for
  the next release" of the Release-Notes are completed.


Your Contributions
--
+ Testing/Feedback is welcome (It's still beta quality, so I haven't
  uploaded the package yet). To use/test it, run :
sudo apt-get install git-core
git clone git://git.debian.org/git/collab-maint/upgrade-advisor.git
./upgrade-advisor/upgrade-advisor.sh pre-upgrade
  Feedback for false positive and false negative is especially welcome.

+ Help list packages that "require a human intervention" [2].
  I am planning to list the installed packages that "require a human
  intervention" to work after upgrade. This especially include the
  packages that need to be reconfigured/migrated manually.
  If you know such package, please let me know (provide a short
  description, like "re-configure /etc/foo.conf").
  The purpose is to let the sysadmin estimate the system "downtime".

+ Contributing a plug-in.
  You can contribute a plug-in, that warns users before
  they upgrade their systems.
  Here's a sample plugin :

### START of: plugins/A-20_check_update_grub_path ###
#!/bin/sh

check_update_grub_path() {
# This plugin applies to Etch and above only.
[ $CURRENT_OS -lt $ETCH ] && return 0
# Verbose/Debug mode.
start_function "$FUNCNAME" "Checking update-grub path
in /etc/kernel-img.conf"

# The actual test.
if grep -E "[[:blank:]=]+/sbin/update-grub" \
/etc/kernel-img.conf > /dev/null 2>&1; then
alert "The path to update-grub in /etc/kernel-img.conf
is wrong."
extra "$RELNOTES/ch-upgrading.en.html#s-for_next"
fi

#Done !
end_function "$FUNCNAME"
}
### END ###


On Tue, 2008-09-09, Alexander Reichle-Schmehl wrote: 
> Am 7.9.2008 schrieb "Franklin PIAT" <[EMAIL PROTECTED]>:
> 
> >I've worked on an upgrade advisor tool for Lenny. The idea is to do some
> >sanity check to then warn the users of potential problems (and also
> >advertise some best practices). The example below should be quite
> >explicit.
> 
> Wonderfull idea!  Are you "synchronizing" with the release notes? 
> Meaning, that you things you test, are documented there and vice versa?

I've synch'ed some of them... but more work is needed.

Finally, I'm wondering what would be the most convenient way to
distribute this tool. Any idea ?

Franklin

[1] http://git.debian.org/?p=collab-maint/upgrade-advisor.git;a=summary
[2] http://wiki.debian.org/NewInLenny/HumanInterventionNeeded


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

Re: Bits from the Debian Eee PC team, autumn 2008

[Matteo Croce]

On Monday 13 October 2008 19:35:16 Ben Armstrong wrote:
> Ath5k wifi works on Eee PC in Linux 2.6.27
>
>Jean-Christophe reports that [2]ath5k works in Linux 2.6.27 on
>the Eee PC 701, and just needs a [3]small patch to work with our
>eeepc-acpi-scripts package. This is good news for those of us with
>models 701, 900, 900A and 1000HD who have been wanting to get off of
>the non-free Madwifi drivers and onto DFSG free drivers.
>

ath5k? aren't 901 and 1000HD 802.11n devices, so they are supported
by the newer ath9k driver?


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

Re: Bits from the Debian Eee PC team, autumn 2008

[Ben Armstrong]

On Tue, 14 Oct 2008 02:00:29 +0200
Matteo Croce <[EMAIL PROTECTED]> wrote:
> On Monday 13 October 2008 19:35:16 Ben Armstrong wrote:
> > Ath5k wifi works on Eee PC in Linux 2.6.27
> >
> >Jean-Christophe reports that [2]ath5k works in Linux 2.6.27 on
> >the Eee PC 701, and just needs a [3]small patch to work with our
> >eeepc-acpi-scripts package. This is good news for those of us with
> >models 701, 900, 900A and 1000HD who have been wanting to get off of
> >the non-free Madwifi drivers and onto DFSG free drivers.
> >
> 
> ath5k? aren't 901 and 1000HD 802.11n devices, so they are supported
> by the newer ath9k driver?

I think you're thinking of 1000H which is an N device.  1000HD is a
different model altogether b/g like the 701 and 900.  I know it's
confusing with Asus coming out with all of these new models.  Please
consult the table we drew up in our wiki summarizing the differences
between models we support or plan to support:

http://wiki.debian.org/DebianEeePC/Models

Besides, no Eee model that I know of uses an Atheros N chipset, so ath9k
will not work for them.  Models 901, 1000 and 1000H use Ralink rt2860,
as indicated in the table.  While the driver is GPL'd, unfortunately it
embeds a non-free firmware.  There is no 100% open source solution for
these devices yet.  I believe there is work in progress in
compat-wireless, but nothing that works yet.

Ben


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

Bug#502156: ITP: python-django-diario -- A Django application that implements a simple blog system

[Lincoln de Sousa]

Package: wnpp
Severity: wishlist
Owner: Lincoln de Sousa <[EMAIL PROTECTED]>


* Package name: python-django-diario
  Version : 0.1
  Upstream Author : Guilherme Mesquita Gondim (semente) <[EMAIL PROTECTED]>
* URL : http://code.google.com/p/django-diario/
* License : GPL
  Programming Lang: Python
  Description : A simple weblog Django application

Diário (diary in portuguese) is a pluggable weblog application for
Django Web Framework projects, with many features like tagging
support, web syndication feeds, sitemaps.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)



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

Re: Rejuvenated kernel-package uploaded to unstable, please test

[Frans Pop]

Manoj wrote:
> It correctly installs firmware in a versioned location under
> /lib/firmware.

Problem is that even though this may avoid package conflicts, it is *not* 
correct given the way Debian currently looks for firmware. Also, it is 
not the way upstream recommends to install firmware.

All (non-free) Debian firmware packages install the firmware files 
directly under /lib/firmware, not /lib/firmware/$kernel-version.

And Debian's udev does not consider the kernel-version when looking for 
firmware. /lib/udev/hotplug.functions has:
FIRMWARE_DIRS='/lib/firmware /usr/local/lib/firmware /usr/lib/hotplug/firmware'

This means that if you start installing the same firmware file under 
versioned directories, udev will use the first one it finds. Which will 
be the one for some $random kernel version and not the one for the 
currently running kernel.

Installing firmware in versioned directories will also result in bloated 
initramfs initrds as the whole /lib/firmware dir will be copied into 
them, including the duplicated firmware files for all installed kernel 
versions.

The correct solution for this would IMO be to have kernel-package build a 
*separate* package for firmware which does not include the kernel version 
in its package name.

IMO this is an RC bug in the new kernel-package.

Cheers,
FJP


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

kernel 2.6.27 in lenny?

[Peter Jordan]

Hi,

considering that Adrian Bunk announced long time support for kernel
2.6.27 (http://article.gmane.org/gmane.linux.kernel/743377) wouldn't it
be a good idea to take kernel 2.6.27 as the stable kernel in lenny?

PJ


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

Re: kernel 2.6.27 in lenny?

[Yves-Alexis Perez]

On mar, 2008-10-14 at 07:59 +0200, Peter Jordan wrote:
> wouldn't it
> be a good idea to take kernel 2.6.27 as the stable kernel in lenny?

If we want to release lenny before 2.6.27 is not supported anymore,
maybe it's not?

-- 
Yves-Alexis


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

Re: Rejuvenated kernel-package uploaded to unstable, please test

[Paul Wise]

On Tue, Oct 14, 2008 at 12:23 PM, Frans Pop <[EMAIL PROTECTED]> wrote:

> Problem is that even though this may avoid package conflicts, it is *not*
> correct given the way Debian currently looks for firmware. Also, it is
> not the way upstream recommends to install firmware.
>
> All (non-free) Debian firmware packages install the firmware files
> directly under /lib/firmware, not /lib/firmware/$kernel-version.
>
> And Debian's udev does not consider the kernel-version when looking for
> firmware. /lib/udev/hotplug.functions has:
> FIRMWARE_DIRS='/lib/firmware /usr/local/lib/firmware 
> /usr/lib/hotplug/firmware'

In contrast, the latest upstream udev (130) has this:

FIRMWARE_DIRS="/lib/firmware/$(uname -r) /lib/firmware"

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Rejuvenated kernel-package uploaded to unstable, please test

[Manoj Srivastava]

On Mon, Oct 13 2008, Frans Pop wrote:

> Manoj wrote:
>> It correctly installs firmware in a versioned location under
>> /lib/firmware.
>
> Problem is that even though this may avoid package conflicts, it is
> *not* correct given the way Debian currently looks for firmware. Also,
> it is not the way upstream recommends to install firmware.

I think where Debian looks for firmware could change. Or people
 can use hardlinks.

> All (non-free) Debian firmware packages install the firmware files 
> directly under /lib/firmware, not /lib/firmware/$kernel-version.

Which, of course, has nothing to do with kernel images prduced
 by make-kpkg, incidentally.


> And Debian's udev does not consider the kernel-version when looking for 
> firmware. /lib/udev/hotplug.functions has:
> FIRMWARE_DIRS='/lib/firmware /usr/local/lib/firmware 
> /usr/lib/hotplug/firmware'

Seems like upstream udev firmware loader does look at
 /lib/firmware/$(uname -r)/, which seems sane.

Why was this removed?

> This means that if you start installing the same firmware file under
> versioned directories, udev will use the first one it finds. Which
> will be the one for some $random kernel version and not the one for
> the currently running kernel.

This is not a sound argument.

And if I have multiple kernels installed, and only one firmware,
 theb the firmware on the machine will be the random firmware most
 recently installed. By just reverting back to upstream behaviour, this
 randomness in the face of versioned dirs disappears.


> Installing firmware in versioned directories will also result in
> bloated initramfs initrds as the whole /lib/firmware dir will be
> copied into them, including the duplicated firmware files for all
> installed kernel versions.

Again, seems like an easy fix for the initram creator. Load
 files from lib/firmware. and lib/firmware/$(uname -r)

> The correct solution for this would IMO be to have kernel-package
> build a *separate* package for firmware which does not include the
> kernel version in its package name.

A package for a single firmware blob?

> IMO this is an RC bug in the new kernel-package.

That just makes me question your technical judgement.

manoj
-- 
The more you complain, the longer God lets you live.
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]