Bug#558739: RFH: hibernate -- smartly puts your computer to sleep (suspend to RAM or disk)

[martin f krafft]

Package: wnpp
Severity: normal

I request assistance with maintaining the hibernate package since
I don't use it anymore.

The package description is:
 The hibernate script helps you in putting your computer to sleep, using one
 of the various methods available in the kernel.
 .
 Hibernate can take care of loading and unloading modules, provides various
 hacks needed to get some video cards to resume properly under X, can
 optionally restart networking and system services, and basically do whatever
 else you ask it. It can be extended by writing new "scriptlets" which run at
 different points during the suspend process.
 .
 Currently the script supports all suspend mechanisms available through the
 /sys/power/state interface (including ACPI suspend and the in-kernel software
 suspend), as well as Software Suspend 2 (http://www.suspend2.net)

Thanks,

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Bits from the NM people

[Bernd Zeimetz]

Ralf Treinen wrote:
> the main resource is a psql database with offers and requests, and the
> gpg coordination web pages are mainly interfacing to these web pages.
> 
> Did you actually look at how gpg coordination works?

I know the code *puke* and the database very well, thanks.
And I still can't see a problem to migrate it to a wiki page or two.
At least thats what I'll do as soon as the NM page is rewritten and nobody took
care of the gpg stuff - drop the data nicely formatted into the wiki and link to
that.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: FOSDEM 2010

[Dominique Dumont]

On Saturday 28 November 2009 15:50:37 Wouter Verhelst wrote:
> For those of you who were waiting for a call for talks from me on this
> subject, it's not really coming. However, if you think your talk may be
> of some interest to people working on distributions (Debian or
> non-Debian), your talk should be welcome.

I can provide a talk on better ways to handle configuration upgrades during 
packages upgrade [1]. These ideas can also be applied to other distros, so 
they should interest FOSDEM people.

I also have some ideas about addressing ISV packaging needs but they are not 
fleshed out enough for a talk. May be a meeting between people having a 
similar goal ? 

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: bug #551926: python-pip and pip: error when trying to install together

[Tim Retout]

[CCing to python-pip upstream. Ian et. al.: please see
http://bugs.debian.org/551926 for the context of this email.  In
short, Debian needs to rename at least one of the 'pip' binaries.]

On Mon, Nov 30, 2009 at 12:01:51PM +1100, Adam Kennedy wrote:
> http://blog.ianbicking.org/2008/10/28/pyinstall-is-dead-long-live-pip/
> 
> The Perl package predates the Python one by several years.
> 
> The author was made aware of the clash well before it was shipped to
> Debian and chose to continue anyway.

This seems like a valid point.  I would like to hear the opinion of the
upstream author of python-pip on which should be renamed.

Ultimately this decision will be made by the Debian maintainers of the
packages, but I reckon it's best to involve upstream as far as possible
with changes of this kind.

If we cannot agree on the right course of action, both programs will be
renamed.

Regards,

-- 
Tim Retout 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: FOSDEM 2010

[Dominique Dumont]

Oops, I forgot the link [1] in my previous mail. Sorry.

[1] http://wiki.debian.org/PackageConfigUpgrade

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Goswin von Brederlow]

Charles Plessy  writes:

> Le Tue, Nov 24, 2009 at 08:17:17AM +0100, Raphael Hertzog a écrit :
>> 
>> I can add a new option "--no-debian-patch" that would refuse to create the
>> automatic quilt patch debian-changes- and make it fail instead if
>> there are upstream changes.
>
> Hi Raphaël,
>
> even simpler, an option or a format that would completely ignore what is
> outside the debian directory:
>
>  - When packing a source package, a compressed tar archive would be made from
>the contents of the debian directory.
>
>  - When unpacking a source package, the compressed debian tar archive would be
>unpacked in the upstream sources, after deleting any existing debian
>directory.
>
> As it is already the case with Format 1.0 when the maintainer took care of
> having a diff.gz file that only contains files within the debian directory, 
> the
> packaging system would not patch or unpatch the upstream sources, leaving this
> task to the maintainer.
>
> Have a nice day,

With one HUGE difference.

When someone (e.g. an NMUer) does edit an upstream file and builds the
package then the source do not contain those changes while the binary
will. That is clearly going to cause no end of pains.

Building the source package and unpacking it should always result in
the same source tree or fail to build in the first place. Simply
ignoring changes is too dangerous.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Use of sarcasm on mailing lists (was: Re: bug #551926: python-pip and pip: error when trying to install together)

[Tim Retout]

On Mon, Nov 30, 2009 at 04:02:13AM +0100, Cyril Brulebois wrote:
> Mentioning $LANG in the binary is the way to go. Bonus points if
> obfuscated. What about pip, pipp, and ppip? Then, you even get room
> for php!

At the risk of sounding like a killjoy, I do not feel that sarcasm is an
effective means of communicating your points, especially when attempting
a potentially delicate negotiation between Debian and upstream.

I think you may have a valid point about the choice of binary name, but
it is difficult for me to evaluate it when presented in this manner.  I
do not wish to imply that I consent to the use of sarcasm by remaining
silent about this - but please feel free to restate your point in a
different way. :)

Thanks,

-- 
Tim Retout 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Goswin von Brederlow]

Russ Allbery  writes:

> Brian May  writes:
>
>> Just a general observation, it is rather painful to have to set and
>> maintian QUILT_PATCHES by hand everytime I want to modify a patch. There
>> have been a number of times now I have accidentally created the patch in
>> the wrong directory, which can be very confusing (mess two projects up
>> in one go!).
>
>> Maybe this is now fixed in unstable, last I checked it wasn't.
>
> If the only thing you use quilt for is Debian packaging and you perform
> quilt operations from the top of the tree, then this setting in ~/.quiltrc
> works fine:
>
> QUILT_PATCHES=debian/patches
>
> There's a more complex recipe in the quilt documentation that handles more
> cases.
>
> -- 
> Russ Allbery (r...@debian.org)   

http://bugs.debian.org/557623
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=26;filename=quilt-remember_locations.patch;att=1;bug=557623

Please do test.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Charles Plessy]

Le Mon, Nov 30, 2009 at 11:47:04AM +0100, Goswin von Brederlow a écrit :
> 
> When someone (e.g. an NMUer) does edit an upstream file and builds the
> package then the source do not contain those changes while the binary
> will. That is clearly going to cause no end of pains.
> 
> Building the source package and unpacking it should always result in
> the same source tree or fail to build in the first place. Simply
> ignoring changes is too dangerous.


Sorry Goswin, but I will be politically incorrect… Please do not take
personnaly.

Primo)

I checked your Debian QA page and it does not seem that you are doing NMUs. On
the other hand, if you check my QA page, you will see that do regular uploads
quite frequently. Therefore, when I write that it is not convenient for quilt
users that dpkg suddenly attempts to take control of the patch management they
were taking care by themselves, and when you answer that it is a necessary
feature for people who do NMU, isn't there a strong discrepancy in the
discussion since I speak from experience and you don't?

Secundo)

As I already answered (too harshly) to Raphaël, I and many developers only
upload packages that were built in a clean chroot. Therefore, I think that your
statement about ignoring changes being “too dangerous” is a gross overstatement
that is not backed by facts.


By the way, I started recently (for reasons unrelated to this thread) to
document in README.Debian how to test the packages I maintain, to facilitate
uploads by people not familiar with the package if needed, as well as to inform
the users about what level of testing they should expect. I encourage other
maintainers—especially those concerned with helping “NMUers”—to do so.


Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#558768: ITP: uget -- easy-to-use download manager written in GTK+2

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: uget
  Version : 1.5.0
  Upstream Author : Raymond Huang 
* URL : http://urlget.sourceforge.net/
* License : LGPL
  Programming Lang: C
  Description : easy-to-use download manager written in GTK+2
 Uget (formerly urlgfe) is a simple, lightweight and easy-to-use
 download manager.
 It provides the following features:
  * Resume downloads.
  * Queue downloads.
  * Classify downloads in categories.
  * Mozilla Firefox integration (through Flashgot plugin).
  * Clipboard monitoring.
  * Import downloads import from HTML files.
  * Batch download.
 .
 It also can be launched from the command line.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Sbiancante rapido

[Annalisa Ferri]

Con la presente siamo ad avvisarla che sono disponibili i nuovi kit sbiancanti 
rapidi per denti.
Denti bianchi in pochi minuti!
Dettagli e descrizione; http://dentibianchi.eu.tf  o su 
http://sbiancantedenti.urllogs.com


Annalisa Ferri - Dlm srl



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Goswin von Brederlow]

Charles Plessy  writes:

> Le Mon, Nov 30, 2009 at 11:47:04AM +0100, Goswin von Brederlow a écrit :
>> 
>> When someone (e.g. an NMUer) does edit an upstream file and builds the
>> package then the source do not contain those changes while the binary
>> will. That is clearly going to cause no end of pains.
>> 
>> Building the source package and unpacking it should always result in
>> the same source tree or fail to build in the first place. Simply
>> ignoring changes is too dangerous.
>
>
> Sorry Goswin, but I will be politically incorrect… Please do not take
> personnaly.
>
> Primo)
>
> I checked your Debian QA page and it does not seem that you are doing NMUs. On
> the other hand, if you check my QA page, you will see that do regular uploads
> quite frequently. Therefore, when I write that it is not convenient for quilt
> users that dpkg suddenly attempts to take control of the patch management they
> were taking care by themselves, and when you answer that it is a necessary
> feature for people who do NMU, isn't there a strong discrepancy in the
> discussion since I speak from experience and you don't?

Nowhere in my mail do I say that. I made no mention of quilt or dpkg
doing patch management. My argumentation has nothing to do with that
but only with your proposal.

Your suggestion to simply ignore all changes to upstream files makes
it dangerously simple to forget some of them and is totaly
avoidable. I have nothing against your proposed quiltless format but
then dpkg should fail if there are upstream changes. That way you can
not forget to update the patches or add a file to the patches or
forgot to commit to git or whatever is being used.

As for experience you are arguing from the experience of a good
maintainer that is carefull and methodical. I'm arguing from
experience of how badly maintainer manage to screw things up. I've
seen packages being uploaded with a syntax error in debian/rules but
still having all the binary debs build as well. Packages linked
against stable or experimental libraries. and the list goes on and on.
People do screw up. They are people.

> Secundo)
>
> As I already answered (too harshly) to Raphaël, I and many developers only
> upload packages that were built in a clean chroot. Therefore, I think that 
> your
> statement about ignoring changes being “too dangerous” is a gross 
> overstatement
> that is not backed by facts.

And many developers do not build in a clean chroot. Also the chroot
being clean or not has no affect on building the source. Unless you
build the source first and then do a clean  build starting with
unpacking the source again your "clean" build would still be broken.

Far too many people do not build source and then call pbuilder with
the dsc file for an upload (or equivalent).

And it only takes one to screw up.

> By the way, I started recently (for reasons unrelated to this thread) to
> document in README.Debian how to test the packages I maintain, to facilitate
> uploads by people not familiar with the package if needed, as well as to 
> inform
> the users about what level of testing they should expect. I encourage other
> maintainers—especially those concerned with helping “NMUers”—to do so.

Don't get me wrong. Documenting ways to test your package is
great. But why should I need to test something that dpkg can far
better test automatically with 100% accuracy?

> Cheers,

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

RFC: convenience copy of cddlib

[bremner]

Hi All;

I'm currently (well, currently for a few years :( ) packaging
polymake, a perl and C++ based workbench for discrete geometry and
topology (think math grad students).  polymake contains private copies
of 3 libraries that are now in Debian: cddlib, lrslib, and nauty (the
latter two packaged by me, the first by Tim, I think as part of
sagemath?).

I can use the system copy of lrslib and nauty, but I have discovered
what is probably an insurmountable issue with using the debian cddlib.
I thought I would throw this out there, and see if I missed some
solution that isn't worse than the problem.

cddlib produces two libraries: libcdd uses floating point arithmetic,
and libcddgmp use gmp.  Unfortunately there is a large overlap of
symbols between the two of them, as cdd upstream never envisioned
wanting to use both at the same time.  Polymake does need to link to
both versions, according to the polymake authors.  The polymake
solution is to rename the conflicting symbols in libcddgmp at compile
time.

I see two solutions so far:

1) patch the debian cddlib package to produce a third library,
   libcdd_gmp (or whatever) that can be linked together with
   libcdd. This basically migrates the polymake abi changes to the
   debian package, and maybe eventually upstream.

2) just use the convenience copy. I wouldn't be so foolish as to
   promise that there will never be a security problem in cddlib, but
   it seems relatively low risk.  No network access, for example.

Feedback gratefully received,

David


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: convenience copy of cddlib

[Francesco P. Lovergine]

On Mon, Nov 30, 2009 at 09:07:26AM -0400, brem...@unb.ca wrote:
> 
> I see two solutions so far:
> 
> 1) patch the debian cddlib package to produce a third library,
>libcdd_gmp (or whatever) that can be linked together with
>libcdd. This basically migrates the polymake abi changes to the
>debian package, and maybe eventually upstream.
> 
> 2) just use the convenience copy. I wouldn't be so foolish as to
>promise that there will never be a security problem in cddlib, but
>it seems relatively low risk.  No network access, for example.
> 

3) Use versioned symbols for the internal library to avoid conflicts
with the external one.

http://sca.uwaterloo.ca/coldfire/gcc-doc/docs/ld_25.html

-- 
Francesco P. Lovergine


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#558797: ITP: sessioninstaller -- APT based installer using PackgeKit's session DBus API

[Julian Andres Klode]

Package: wnpp
Severity: wishlist
Owner: Julian Andres Klode 

* Package name: sessioninstaller
  Version : N/A yet
  Upstream Author : Sebastian Heinlein 
* URL : https://launchpad.net/sessioninstaller
* License : GPL-2+
  Programming Lang: Python
  Description : APT based installer using PackgeKit's session DBus API
 sessioninstaller makes use of PackageKit's DBus information to allow
 distribution neutral software management hooks for upstream software on
 APT based systems without loosing the interactiveness.

Again, I am not subscribed to debian-devel, so please include me and/or
the bug in To or CC. The third ITP since yesterday.
-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.


signature.asc
Description: Digital signature

Re: Linux image packages going to depend on python

[Noah Meyerhans]

On Sun, Nov 29, 2009 at 02:15:41PM -0600, Manoj Srivastava wrote:
> Perhaps you should consider making the script just create a
>  ./fstab.new file, and not overwriting /etc/fstab?  makes it easier to
>  test the script out without altering current setup.

Keeping a copy of the original file, maybe in /var/backups, might be
helpful as well.

noah



signature.asc
Description: Digital signature

Re: Linux image packages going to depend on python

[Thilo Six]

Noah Meyerhans wrote the following on 30.11.2009 17:42

> On Sun, Nov 29, 2009 at 02:15:41PM -0600, Manoj Srivastava wrote:
>> Perhaps you should consider making the script just create a
>>  ./fstab.new file, and not overwriting /etc/fstab?  makes it easier to
>>  test the script out without altering current setup.
> 
> Keeping a copy of the original file, maybe in /var/backups, might be
> helpful as well.
> 
> noah

Through this thread i digged into this on my machine myself and just want
through in some remarks i found:

Swap
The swap partition created by lenny 5.0.2 d-i didn't had any LABEL nor UUID.
Might be necessary to catch that up?

grub & initramfs
fstab is one place to be /boot/grub/menu.lst and
/etc/initramfs-tools/conf.d/resume are others. When discussing about modifing
fstab and which tools to use it might should be considerd there are other
places as well?


I am sorry for the noise if this is pretty obvious and already considered by
everybody involved.
-- 
bye Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux image packages going to depend on python

[Frank Lin PIAT]

On Sun, 2009-11-29 at 20:56 +0100, Frank Lin PIAT wrote:
> On Sun, 2009-11-29 at 13:56 +0100, Marco d'Itri wrote:
> > On Nov 28, Bastian Blank  wrote:
> > 
> > > The Linux image packages needs to do some modifications to core
> > > configuration files like fstab in the future to allow newer kernels to
> > > work. To do this and the planned further extension I intend to make all
> > > linux image packages depend on python.

FYI

As I were investigating an issue about volumes UUID, I noticed that
Ubuntu already had such transition, with this tool: volumeid[1]

It needed a minor update to use blkid instead of vol_id.

Franklin

[1] https://launchpad.net/ubuntu/gutsy/i386/volumeid/113-0ubuntu17.2
https://launchpad.net/ubuntu/+source/udev/113-0ubuntu17.2
#!/bin/sh -e
# Rewrite /etc/fstab so that filesystems are mounted by UUID

if [ -e /etc/fstab.pre-uuid ]; then
echo "/etc/fstab.pre-uuid already exists" 1>&2
echo "remove this file before running the script again" 1>&2
exit 1
fi

cp -a /etc/fstab /etc/fstab.pre-uuid
exec 9<&0 8>&1 /etc/fstab.new
trap "rm -f /etc/fstab.new" 0

uuids=""

old_IFS="$IFS"
IFS="
"
while read LINE
do
IFS="$old_IFS"
set -- $LINE
IFS="
"
DEV=$1 MTPT=$2 FSTYPE=$3 OPTS=$4

# Check the device is sane for conversion
case "$DEV" in
""|\#*) # Preserve blank lines and user comments
echo "$LINE"
continue
;;
LABEL=*|UUID=*) # Already mounting by LABEL or UUID
echo "$LINE"
continue
;;
/dev/mapper/*_crypt)# DM-Crypt devices
echo "$LINE"
continue
;;
/dev/disk/*)# Already mounting by particulars
echo "$LINE"
continue
;;
/dev/fd[0-9]*)  # Floppy devices, not mounted by filesystem
echo "$LINE"
continue
;;
/dev/*) # Ordinary devices -- we want to convert
if [ ! -b "$DEV" ]; then
echo "$LINE"
continue
fi
;;
*)  # Anything else gets left alone
echo "$LINE"
continue
;;
esac 

# Don't convert filesystem types that don't make sense
case "$FSTYPE" in
auto)   # Auto detection -- implies non-fixed fs
echo "$LINE"
continue
;;
esac

# Check filesystem options also
case "$OPTS" in
noauto|*,noauto|noauto,*|*,noauto,*)# Implies non-fixed
echo "$LINE"
continue
;;
esac


# If we reach this point, we think we want to move the fstab
# entry over to mount-by-UUID.  The first check is that the
# filesystem on the device *has* a uuid
UUID=$(/sbin/vol_id -u "$DEV" || true)
if [ -z "$UUID" ]; then
# Can we generate one?
if [ "$FSTYPE" = "swap" ]; then
REAL_FSTYPE=$(/sbin/vol_id -t "$DEV" || true)
case "$REAL_FSTYPE" in
swap)   # is a swap device, add a UUID to it
UUID=$(uuidgen)
echo -n "$UUID" |
  perl -ne 's/-//g;chomp;print pack "H*",$_' |
  dd conv=notrunc "of=$DEV" obs=1 seek=1036 2>/dev/null
;;
swsusp) # contains a suspended image, mkswap it!
if ! mkswap "$DEV" >/dev/null; then
echo "Warning: unable to make swap $DEV" 1>&2
echo "$LINE"
continue
fi

UUID=$(/sbin/vol_id -u "$DEV" || true)
if [ -z "$UUID" ]; then
echo "Warning: unable to generate uuid for $DEV" 1>&2
echo "$LINE"
continue
fi
;;
*)
echo "Warning: $DEV is not a swap partition" 1>&2
echo "$LINE"
continue
;;
esac
else
echo "Warning: unable to find a UUID for $DEV" 1>&2
echo "$LINE"
continue
fi
fi

# Check for duplicates
case "$uuids" in
"$UUID" | "$UUID "* | *" $UUID" | *" $UUID "*)
echo "Error: duplicate UUID $UUID detected" 1>&2
echo "Unable to migrate /etc/fstab to UUID-based mounting" 1>&2

exec 0<&9 9<&- 1>&8 8>&-
trap 0

rm -f /etc/fstab.new
exit 1
;;
*)
uuids="${uuids:+$uuids }$UUID"
;;
esac

# Now write the new line out
shift
echo "# $DEV -- converted during upgrade to edgy"
echo "UUID=$UUID $@"
done
IFS="$old_IFS"

exec 0<&9 9<&- 1>&8 8>&-
trap 0

#mv -f /etc/fstab.new /etc/fstab

exit 0
#!/bin/sh -e
# Rewrite /etc/fstab so that filesystems are mounted by UUID

if [ -e /etc/fstab.pre-uuid ];

Re: bug #551926: python-pip and pip: error when trying to install together

[Tim Retout]

[Resending to Ian Bicking's direct email address, since the
virtualenv list address bounced.]

On Mon, Nov 30, 2009 at 09:49:18AM +, Tim Retout wrote:
> On Mon, Nov 30, 2009 at 12:01:51PM +1100, Adam Kennedy wrote:
> > http://blog.ianbicking.org/2008/10/28/pyinstall-is-dead-long-live-pip/
> > 
> > The Perl package predates the Python one by several years.
> > 
> > The author was made aware of the clash well before it was shipped to
> > Debian and chose to continue anyway.
> 
> This seems like a valid point.  I would like to hear the opinion of the
> upstream author of python-pip on which should be renamed.
> 
> Ultimately this decision will be made by the Debian maintainers of the
> packages, but I reckon it's best to involve upstream as far as possible
> with changes of this kind.
> 
> If we cannot agree on the right course of action, both programs will be
> renamed.

Ian, please see the thread starting at:
http://lists.debian.org/debian-devel/2009/11/msg01034.html

In short, Debian must rename at least one of the binaries called 'pip'.

My first thought was to rename the perl pip because it was a more
recent addition to Debian, but it's been pointed out that Perl's pip
predates the Python one.  Do you have any thoughts as to how we should
proceed?

-- 
Tim Retout 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#559006: ITP: mlpy -- high-performance Python package for predictive modeling

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko 


* Package name: mlpy
  Version : 2.1.0
  Upstream Author : mlpy Developers - FBK-MPBA 
* URL : https://mlpy.fbk.eu/
* License : GPL-3+
  Programming Lang: C, Python
  Description : high-performance Python package for predictive modeling
 mlpy provides high level procedures that support, with few lines of
 code, the design of rich Data Analysis Protocols (DAPs) for
 preprocessing, clustering, predictive classification and feature
 selection. Methods are available for feature weighting and ranking,
 data resampling, error evaluation and experiment landscaping.
 .
 mlpy includes: SVM (Support Vector Machine), KNN (K Nearest
 Neighbor), FDA, SRDA, PDA, DLDA (Fisher, Spectral Regression,
 Penalized, Diagonal Linear Discriminant Analysis) for classification
 and feature weighting, I-RELIEF, DWT and FSSun for feature weighting,
 *RFE (Recursive Feature Elimination) and RFS (Recursive Forward
 Selection) for feature ranking, DWT, UWT, CWT (Discrete, Undecimated,
 Continuous Wavelet Transform), KNN imputing, DTW (Dynamic Time
 Warping), Hierarchical Clustering, k-medoids, Resampling Methods,
 Metric Functions, Canberra indicators.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: bug #551926: python-pip and pip: error when trying to install together

[Frank Lin PIAT]

On Sun, 2009-11-29 at 21:17 -0500, Jonathan Yu wrote:
> Hi:
> 
> [Cc'ing Adam Kennedy since I'm not sure if he's subscribed to debian-devel]
> 
> Since Adam mentions that Perl's pip predates Python's pip by a
> significant margin, I think we should close this issue by renaming
> Python's installer back to pyinstall. It doesn't seem fair for someone
> who came on the scene later (who didn't do the appropriate research,
> and who, when prompted with the problem, decided to proceed with pip
> anyway) to be able to usurp the namespace from Perl.

Some facts:
---

pip
 - It's in the archive since 2002-08
 - It never entered testing or stable
 - It's average popcon since 2004 is about 10 (out of 7)
 - It's popularity suddenly increased in Octobre (reaching 68)

python-pip
- It's in the archive since 2009-04
- It is in testing
- It's popcon is slowly and constantly increasing, reaching 57/7

Why (perl) pip popcon suddenly[1] reached 68? Is it due to the new
version, or is it due to people installing it by mistake?


Non-factual!


WTF? 
1. Can't perl and python upstream just talk together, this is not
   just about Debian. Having two ${p}-installer-program it just so
   convenient, what ever the platform!
2. 
   Don't we use apt/dpkg in Debian?
   Do those $pip install stuffs outside /usr/local?
   Shouldn't those packages description mention that users should
   ITP/RFP desired modules? and that modules installed "manually" are
   guaranteed to:
   - Never be upgraded by Debian on upgrade/security updates
   - Conflict with some properly installed packages
   - Download untrusted/unsigned material (?)
   - Download stuffs with unknown license (?)
   - Never be supported by Debian
   


/usr/bin/pip should be a wrapper to invoke perl-pip and python-pop
randomly, in order to be really fair.

My 2¢

Franklin


popcon data:

2009-05: python-pip  3 0 0 3 0
2009-05: pip 8 1 7 0 0
2009-06: python-pip  180 612 0
2009-06: pip 8 1 7 0 0
2009-07: python-pip  19115 3 0
2009-07: pip 8 0 8 0 0
2009-08: python-pip  25115 9 0
2009-08: pip 8 0 8 0 0
2009-09: python-pip  32620 6 0
2009-09: pip 9 0 9 0 0
2009-10: python-pip 421125 6 0
2009-10: pip 9 0 9 0 0
2009-11: python-pip 51 934 8 0
2009-11: pip19 4 7 8 0
2009-12: python-pip 551434 7 0
2009-12: pip68151043 0

[1] http://qa.debian.org/popcon.php?package=pip
http://qa.debian.org/popcon.php?package=python-pip


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org