Python3 was released upstream exactly 1 year ago, but Python3.* still
hasn't been released in Debian Unstable.
Hell, even the even older Python2.6 is not there yet.
I appreciate all the hard work that needs to done to maintain
packages, but if you're going to maintain packages as important as
thes
On Wed, 2009-12-02 at 15:58, Karl Goetz wrote:
> On Wed, 02 Dec 2009 05:58:17 +0100
> "Dario Minnucci \(midget\)" wrote:
> > * Package name: shc
>
> > shc's main purpose is to protect your shell scripts from
> > modification or inspection. You can use it if you wish to
> > distribute your
Angus wrote:
> Python3 was released upstream exactly 1 year ago, but Python3.* still
> hasn't been released in Debian Unstable.
> Hell, even the even older Python2.6 is not there yet.
[...]
> Does Debian even have a roadmap for Python? If there is any, I'm not
> seeing it. At least be transparent a
Hello Angus,
On Wed, Dec 2, 2009 at 09:06, Angus wrote:
> Python3 was released upstream exactly 1 year ago, but Python3.* still
> hasn't been released in Debian Unstable.
> Hell, even the even older Python2.6 is not there yet.
>
> I appreciate all the hard work that needs to done to maintain
> pa
Sandro Tosi writes:
> This (and other) rant are a signal we should create a TEAM around any
> fundamental packages in Debian, and python MUST NOT be and exception.
>
> Am I the only one (together with Angus, I'd say) believing python
> deserves a better maintainership than the one it currently ha
Le mercredi 02 décembre 2009 à 09:27 +0100, Sandro Tosi a écrit :
> The problem with Python (interpreters packages) is the maintainer,
> that's force us in his one-man-show and, as you can see, it's failing
> loudly. Matthias is holding back the release and his not willing to
> communicate to the
On Wed, Dec 2, 2009 at 10:17, Ben Finney wrote:
> Sandro Tosi writes:
>
>> This (and other) rant are a signal we should create a TEAM around any
>> fundamental packages in Debian, and python MUST NOT be and exception.
>>
>> Am I the only one (together with Angus, I'd say) believing python
>> dese
On Tue, Dec 01, 2009 at 04:21:31PM +0100, Julian Andres Klode wrote:
> > The confirmation, error reporting and progress notification of the
> > installation is handled by sessioninstaller. Currently it comes only
> > with a GTK based user interface.
> Shouldn't this by 'only comes' instead of 'come
On Wed, 2 Dec 2009 17:06:40 +0900, Angus wrote:
>Or
>otherwise, let someone else do it (like me).
We actually need people showing traces of social skills, which you
don't.
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber | " Q
On 02/12/09 at 09:27 +0100, Sandro Tosi wrote:
> Hello Angus,
>
> On Wed, Dec 2, 2009 at 09:06, Angus wrote:
> > Python3 was released upstream exactly 1 year ago, but Python3.* still
> > hasn't been released in Debian Unstable.
> > Hell, even the even older Python2.6 is not there yet.
> >
> > I a
Lucas Nussbaum wrote:
> It's a bit too easy to behave like an ass and insult him, and then
> complain that he is not talking to you or willing to work with you.
There were several nice and friendly attempts to get this problem fixed behind
the scenes - but Matthias didn't even bother to reply to
On Wed, Dec 2, 2009 at 4:37 PM, Lucas Nussbaum wrote:
> It's a bit too easy to behave like an ass and insult him, and then
> complain that he is not talking to you or willing to work with you.
Right. Let him talk about current status of Python in Debian.
--
Cheers,
Kartik Mistry | 0xD1028C8D
On Dec 2, 2009, at 10:26, Sandro Tosi wrote:
> On Wed, Dec 2, 2009 at 10:17, Ben Finney wrote:
>> Sandro Tosi writes:
>>
>>> This (and other) rant are a signal we should create a TEAM around any
>>> fundamental packages in Debian, and python MUST NOT be and exception.
>>>
>>> Am I the only on
Le mercredi 02 décembre 2009 à 12:07 +0100, Lucas Nussbaum a écrit :
> Seriously, Sandro. Do you really think that, in Matthias' position, you
> would agree to team-maintain Python with people that attack you so
> harshly on public mailing lists?
I certainly wouldn’t want to co-maintain anything
HI all,
I have no personal opinion on python, but seeing that the maintainer
has not stepped up and at elast *explained* what is going on and why
we are lacking behind several releases is not a good sign.
On Mi, 02 Dez 2009, Lucas Nussbaum wrote:
> It's a bit too easy to behave like an ass and in
I agree that the current situation sucks. However, I've been involved in
discussion with various developers on both sides (Debian and Ubuntu)
that are interested in finding solutions. I'm still confident that we
can reach a solution. But clearly, attacking each other like that is
counter-productive
> I agree that the current situation sucks. However, I've been involved in
> discussion with various developers on both sides (Debian and Ubuntu)
> that are interested in finding solutions. I'm still confident that we
> can reach a solution. But clearly, attacking each other like that is
> counter-
On 02/12/09 at 14:26 +0100, Norbert Preining wrote:
> HI all,
>
> I have no personal opinion on python, but seeing that the maintainer
> has not stepped up and at elast *explained* what is going on and why
> we are lacking behind several releases is not a good sign.
>
> On Mi, 02 Dez 2009, Lucas
On Mi, 02 Dez 2009, Lucas Nussbaum wrote:
> Also, FWIW, I was told that Matthias is currently unable to read/answer
> email. So don't put too much hope in a statement from him in the next
> hours.
Actually I don't care. I have used python only for a small applet
that allows turning on/off rfkills
On Wed, 02 Dec 2009, Norbert Preining wrote:
> Actually I don't care. I have used python only for a small applet
> that allows turning on/off rfkills (why is there nothing in the world
> by now, strange, maybe I should package it for debian, but I have
http://bugs.debian.org/cgi-bin/bugreport.cgi?
On Mi, 02 Dez 2009, Henrique de Moraes Holschuh wrote:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538389
Nice try, but I was talking about a GNOME/systray applet I wrote
so that you can click-point turning on/off the various hardwares.
This is currently only possible for the bluetooth in
On Wed, 02 Dec 2009, Norbert Preining wrote:
> On Mi, 02 Dez 2009, Henrique de Moraes Holschuh wrote:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538389
>
> Nice try, but I was talking about a GNOME/systray applet I wrote
> so that you can click-point turning on/off the various hardwares
Hi,
I remember that debian/copyright should not only list where the source
was downloaded from, but also the files which were removed by the
packager and the motivation for the removal (DFSG, patents, large
convenience copy of a library...). At least, that's how I interpret
this (from [1]
On Wed, Dec 02 2009, Milan P. Stanic wrote:
> On Wed, 2009-12-02 at 15:58, Karl Goetz wrote:
>> On Wed, 02 Dec 2009 05:58:17 +0100
>> "Dario Minnucci \(midget\)" wrote:
>> > * Package name: shc
>>
>> > shc's main purpose is to protect your shell scripts from
>> > modification or inspection
Hi Henrique,
not sure if it fits here, but still interesting.
On Mi, 02 Dez 2009, Henrique de Moraes Holschuh wrote:
> Ah, ok. NetworkManager is supposed to be able to deal with rfkill, too
But probably only for WLAN, not WWAN. And then, I don't want install
the whole bunch of horrible NM onl
I'm definitely interested in participating! One question tho, since I'm from
Bosnia, what other activities (perhaps involving Debian) could I be involved in
during this whole week, since I wouldn't come to Germany just for two days ...
suggestions? Share :)
Adnan
On Wed, Dec 2, 2009 at 3:27 P
[Manoj Srivastava]
> Having said that, I am not advocating blocking this package (nor
> am I advocating accepting it), I am just commenting on the arguments
> being presented here.
Indeed, the thing to do would probably be to provide both shc and an
equivalent decompiler - assuming of c
On Wed, 02 Dec 2009, Norbert Preining wrote:
> > Just keep in mind that /dev/rfkill manipulates radios of a given _type_
> > as a group, and that an user could have many radios of the same type,
>
> *Really*?? I was looking into the rfkill code since I reimplemented
> the protocol in my python app
I'm the maintainer of pdns-recursor. This program uses swapcontext which is not
available on all platforms.
Recently the mips, mipsel and sparc architecture got support for those calls.
So I sent a mail to @buildd.debian.org
for enabling this. But until now I didn't get any response, so my quest
Matthijs Mohlmann wrote:
> I'm the maintainer of pdns-recursor. This program uses swapcontext which is
> not available on all platforms.
>
> Recently the mips, mipsel and sparc architecture got support for those calls.
> So I sent a mail to @buildd.debian.org
> for enabling this. But until now I
On Dec 2, 2009, at 8:03 PM, Luk Claes wrote:
> Matthijs Mohlmann wrote:
>> I'm the maintainer of pdns-recursor. This program uses swapcontext which is
>> not available on all platforms.
>>
>> Recently the mips, mipsel and sparc architecture got support for those
>> calls. So I sent a mail to @b
On Wed, Dec 02, 2009 at 05:06:40PM +0900, Angus wrote:
> Python3 was released upstream exactly 1 year ago, but Python3.* still
> hasn't been released in Debian Unstable.
> Hell, even the even older Python2.6 is not there yet.
>
> I appreciate all the hard work that needs to done to maintain
> pack
On Wed, 2009-12-02 at 08:48, Manoj Srivastava wrote:
> On Wed, Dec 02 2009, Milan P. Stanic wrote:
>
> > On Wed, 2009-12-02 at 15:58, Karl Goetz wrote:
> >> On Wed, 02 Dec 2009 05:58:17 +0100
> >> "Dario Minnucci \(midget\)" wrote:
> >> > * Package name: shc
> >>
> >> > shc's main purpose i
Hi all,
I'm packaging an in-memory message queuing service [0] that ships tests, which
require listening on a non-privileged port for the 1-2 seconds that the tests
last.
The service supports no authorisation/authentication and, as of now, has no
way of limiting the size of inserted messages. Wou
Executive summary: mercurial-buildpackage can now recreate pristine
upstream tarballs.
mercurial-buildpackage is a set of tools for maintining Debian
packages in a Mercurial repository, and in version 0.2 you can run
"mercurial-pristinetar 1.2.3" to recreate a tarball that is identical
to the one
2009/12/2 Jens Peter Secher
>
> Executive summary: mercurial-buildpackage can now recreate pristine
> upstream tarballs.
>
Does it support 3.0 (quilt) and puts them into mercurial queues? That
would be IMHO a killer feature (me is sad that git is getting used for
packages so much I am still hopin
Modestas Vainius writes:
> On pirmadienis 23 Lapkritis 2009 23:35:28 Russ Allbery wrote:
>
>> Debian tries to avoid RPATH used in ways that might break multilib or
>> override local administrator settings, which means we want to avoid
>> RPATH pointing to /usr/lib or to build directories and the
Ana Guerrero writes:
> If you really want to help, read the mail archive of the debian-python
> mailing list [1] (optionally hang out in the IRC channel), and get
> an idea of what the problem is.
> I also advise to take a look to the archive to people participating
> in this thread who has no
38 matches
Mail list logo
