Bug#1075932: ITP: python-moarchiving -- Biobjective Archive class with hypervolume indicator and uncrowded hypervolume improvement computation

: BSD-3-Clause Programming Lang: Python Description : Biobjective Archive class with hypervolume indicator and uncrowded hypervolume improvement computation This module contains, for the time being, a single MOO archive class. A bi-objective nondominated archive as sorted list with

Bug#1064622: ITP: python-chocolate -- Improvement to Python's kwargs

* License : Expat Programming Lang: Python Description : Improvement to Python's kwargs Chocolate is a Python package that improves Python's `**kwargs`. It is a depend for other python packages. I am planning to maintain it under DPT, and need sponsorship.

Re: Improvement of sensible-utils

Le vendredi 11 août 2017, 16:37:49 UTC Bastien ROUCARIES a écrit : Hi, I have implemented on salsa the sensible-x-terminal, but I need --wait flags in order to wait... Moreover sensible-utils will now support EDITOR as shell snippet like EDITOR='emacsclients -n -c -a ""' Bastien > Hi, > > I h

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

Hello, On Fri 02 Sep 2022 at 12:31PM +01, Ian Jackson wrote: > Sean Whitton writes ("Re: Comments on proposing NEW queue improvement (Re: > Current NEW review process saps developer motivation"): >> On Sat 27 Aug 2022 at 04:22PM +02, Vincent Bernat wrote: >> > I

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

Sean Whitton writes ("Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation"): > On Sat 27 Aug 2022 at 04:22PM +02, Vincent Bernat wrote: > > It does not seem to work. Either people don't want to do that, either the

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

On Mon, 29 Aug 2022 00:15:27 -0400, Scott Kitterman wrote: >If I look at a package and determine it's only in New due to a new binary >package name and that means the project has prohibited me from looking for >other issues in the package until some time later when it's not in New, then I >feel

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

On Mon, 2022-08-29 at 12:33 +0530, Pirate Praveen wrote: > May be we should be able to tag packages with in NEW into categories > like this (similar to how a DD can give back a failed build via web > interface). This may need to go through a GR. If we prioritize packages > in NEW required for u

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

Sean Whitton wrote on 27/08/2022 at 20:24:55+0200: > [[PGP Signed Part:No public key for 695B7AE4BF066240 created at > 2022-08-27T20:24:55+0200 using RSA]] > Hello, > > On Sat 27 Aug 2022 at 04:22PM +02, Vincent Bernat wrote: > >> >> On 2022-08-27 15:53, M. Zhou wrote: >> >>> That's why I still

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

On Mon, Aug 29 2022 at 12:33:44 PM +05:30:00 +05:30:00, Pirate Praveen wrote: On Sun, Aug 28 2022 at 07:39:12 AM +02:00:00 +02:00:00, Andreas Tille wrote: BTW, the vast amount of new packages I'm packaging are new dependencies for existing packages to get their new versions. May be

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

On Sun, Aug 28 2022 at 07:39:12 AM +02:00:00 +02:00:00, Andreas Tille wrote: BTW, the vast amount of new packages I'm packaging are new dependencies for existing packages to get their new versions. May be we should be able to tag packages with in NEW into categories like this (similar to

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

Scott Kitterman writes: > If I look at a package and determine it's only in New due to a new > binary package name and that means the project has prohibited me from > looking for other issues in the package until some time later when it's > not in New, then I feel pretty precisely like I'm prohib

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

On Sunday, August 28, 2022 11:53:50 PM EDT Russ Allbery wrote: > Scott Kitterman writes: > > Sean Whitton wrote: > >> I think we still want the binary package namespace checking? > >> > >> I.e., a GR just saying "ftpteam should not do a full > >> licensing/copyright check for packages in binNEW"

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

Scott Kitterman writes: > Sean Whitton wrote: >> I think we still want the binary package namespace checking? >> I.e., a GR just saying "ftpteam should not do a full >> licensing/copyright check for packages in binNEW". >> Then no software changes are required. > I think that a GR to prohibit

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

On August 28, 2022 8:58:24 PM UTC, Sean Whitton wrote: >Hello, > >On Sun 28 Aug 2022 at 07:45AM +02, Andreas Tille wrote: > >> >> Am Sat, Aug 27, 2022 at 09:53:40AM -0400 schrieb M. Zhou: >>> In my fuzzy memory, the last discussion on NEW queue improvement

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

Hello, On Sun 28 Aug 2022 at 07:45AM +02, Andreas Tille wrote: > > Am Sat, Aug 27, 2022 at 09:53:40AM -0400 schrieb M. Zhou: >> In my fuzzy memory, the last discussion on NEW queue improvement >> involves the disadvantages by allowing SOVERSION bump to directly >> pas

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

On Sat, Aug 27, 2022 at 09:50:41AM +0200, Gard Spreemann wrote: > > Strong motivations such as "I use this package, seriously" are not > > likely to wear out very easily through time. Packages maintained > > with a strong motivation are better cared among all packages in our > > archive. > > I hum

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

Am Sat, Aug 27, 2022 at 09:53:40AM -0400 schrieb M. Zhou: > In my fuzzy memory, the last discussion on NEW queue improvement > involves the disadvantages by allowing SOVERSION bump to directly > pass the NEW queue. I'm not going to trace back, because I know > this will not be i

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

Am Fri, Aug 26, 2022 at 04:13:43PM -0400 schrieb M. Zhou: > If one's enthusiasm on working on some package is eventually > worn out after a break, then try to think of the following question: > > Is it really necessary to introduce XXX to Debian? May be I'm repeating myself but having packages

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

"M. Zhou" writes: > On Sat, 2022-08-27 at 09:50 +0200, Gard Spreemann wrote: >> >> I humbly disagree. Even from my own point of view, I may well be very >> motivated to package something I use seriously all the time, >> seriously. But then I see its dependency chain of 10 unpackaged >> items, >>

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

Hello, On Sat 27 Aug 2022 at 04:22PM +02, Vincent Bernat wrote: > > On 2022-08-27 15:53, M. Zhou wrote: > >> That's why I still hope ftp team to recruit more people. This is >> a very direct and constructive way to speed up everything. >> More volunteers = higher bandwidth. >> Recruiting more peo

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

On 2022-08-27 15:53, M. Zhou wrote: That's why I still hope ftp team to recruit more people. This is a very direct and constructive way to speed up everything. More volunteers = higher bandwidth. Recruiting more people doesn't seem to have a serious disadvantage. It does not seem to work. Eith

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

7;t seem to have a serious disadvantage. In my fuzzy memory, the last discussion on NEW queue improvement involves the disadvantages by allowing SOVERSION bump to directly pass the NEW queue. I'm not going to trace back, because I know this will not be implemented unless someone proposes a GR.

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

"M. Zhou" writes: > To be honest, in terms of volunteered reviewing work, waiting > for several months is not something new. In academia, it may > take several months to years to get a journal paper response. Sure, but (1) that situation isn't popular in academia either, (2) at least you can

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

On Fri, Aug 26, 2022 at 04:13:43PM -0400, M. Zhou wrote: > If one's enthusiasm on working on some package is eventually > worn out after a break, then try to think of the following question: > > Is it really necessary to introduce XXX to Debian? > Must I do this to have fun? > > Strong motiva

Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

To be honest, in terms of volunteered reviewing work, waiting for several months is not something new. In academia, it may take several months to years to get a journal paper response. I've ever tried to think of possible ways to improve the process, but several observations eventually changed my

Re: Is there room for improvement in our collaboration model?

On Sat, Apr 16, 2022 at 8:32 AM Steffen Möller wrote: > The only extra request from my side would be for salsa-maintained > packages to havet the NMU not bypassing the version management. I agree with the idea, except that it's common to want to NMU something that you don't have Salsa commit priv

Re: Is there room for improvement in our collaboration model?

On 15.04.22 15:53, M. Zhou wrote: On Fri, 2022-04-15 at 14:24 +0200, Luca Boccassi wrote: I think this will also improve newcomer's contributing experience. This proposal is also filed at https://salsa.debian.org/debian/grow-your-ideas/-/issues/34 What about doing something even simpler - rat

Re: Is there room for improvement in our collaboration model?

On Fri, 2022-04-15 at 14:24 +0200, Luca Boccassi wrote: > > > > I think this will also improve newcomer's contributing experience. > > This proposal is also filed at > > https://salsa.debian.org/debian/grow-your-ideas/-/issues/34 > > What about doing something even simpler - rather than having ad

Re: Is there room for improvement in our collaboration model?

On April 15, 2022 2:24:33 PM GMT+02:00, Luca Boccassi wrote: >On Fri, 2022-04-15 at 00:17 -0400, M. Zhou wrote: >> Hi, >> >> I just noted this problem recently. Our model for team collaboration >> (specifically for >> package maintenance) is somewhat primitive. >> >> We are volunteers. Nobod

Re: Is there room for improvement in our collaboration model?

On Fri, 2022-04-15 at 00:17 -0400, M. Zhou wrote: > Hi, > > I just noted this problem recently. Our model for team collaboration > (specifically for > package maintenance) is somewhat primitive. > > We are volunteers. Nobody can continuously maintain a package for decades > like a machine. > Cu

Re: Is there room for improvement in our collaboration model?

Hi, > A. The other DDs can do whatever they like to this package and upload directly >without asking me in a hijacking way. > B. May git commit but should ask before upload. > C. Must ask before any action. > D. ... D Upload NMU with DELAYED/15 or/7 is welcome even without fixing a RC bug

Is there room for improvement in our collaboration model?

Hi, I just noted this problem recently. Our model for team collaboration (specifically for package maintenance) is somewhat primitive. We are volunteers. Nobody can continuously maintain a package for decades like a machine. Currently our practice for accepting other people's help involves: (1)

Bug#903911: ITP: pilon-non-free -- automated genome assembly improvement and variant detection tool

: Java Description : automated genome assembly improvement and variant detection tool Pilon is a software tool which can be used to: * Automatically improve draft assemblies * Find variation among strains, including large event detection Pilon requires as input a FASTA file of the

Re: Improvement of sensible-utils

Am 11.08.2017 um 18:37 schrieb Bastien ROUCARIES: > Hi, > > I have done some work for sensible-utils but I am a little stuck due > to lack of documentation/policy. > > I want first to create desktop file for > sensible-editor/sensible-pager/sensible-browser in order to open from > firefox text fi

Improvement of sensible-utils

Hi, I have done some work for sensible-utils but I am a little stuck due to lack of documentation/policy. I want first to create desktop file for sensible-editor/sensible-pager/sensible-browser in order to open from firefox text file (fixing #780742). The main problem is to exec this in a termin

Bug#778489: ITP: jaligner -- implementation of the Smith-Waterman algorithm with Gotoh's improvement

Programming Lang: Java Description : implementation of the Smith-Waterman algorithm with Gotoh's improvement JAligner is an open source Java implementation of the Smith-Waterman algorithm with Gotoh's improvement for biological local pairwise sequence alignment with the affine gap pen

Re: big improvement with Experimental kernel 3.7.3

I would suggest you find the relevant fixes and report a bug asking the Debian Linux kernel team to backport them to the wheezy version of Linux. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Tro

big improvement with Experimental kernel 3.7.3

Debian 3.7.3-1~experimental.1 x86_64 GNU/Linux and it is a big improvement. I'm able to join ordinary WiFi networks (WPA2) as well as the Enterprise wireless network, including the multi-university "Eduroam" system. So, in case you are having WiFi trouble with Intel devices that use iw

popcon.debian.org improvement

Dear developers, I have updated popcon.debian.org to publish two dataset instead of one: 1) the statistics for all reports 2) the statistics for reports generated with the version of popcon in stable. See . Suggestions for the site layout are welcome. Cheers, -- Bill.

Re: Mouse configuration during installation needs improvement

Stephen Powell <[EMAIL PROTECTED]> writes: > Thinkpad 600). But I'm impressed. Theoretically, one > is not supposed to be able to hot swap a PS/2 mouse. > But it works. Kudos to the kernel folks. The problem has never been that the mouse didn't work after a hot swap. The problem is that with

Re: Mouse configuration during installation needs improvement

Well shut my mouth! I did some testing this past weekend, as I said I would, and results are better than expected. First, leaving things the way I had them configured (X pointing to /dev/gpmdata and gpm pointing to /dev/psaux, I unplugged the PS/2 mouse from the mouse port. The mouse became dead

Re: Mouse configuration during installation needs improvement

Since my initial post I have done some research on the subject of mouse support in the Linux kernel. I can see now why my suggestion was met with such strong opposition: it goes counter to the direction the kernel has been going since 2.5. With such a sweeping redesign of mouse support since 2.4,

Re: Mouse configuration during installation needs improvement

[Stephen Powell] > I realize that PS/2 mice were not intended to be hot swapped, but > "stuff happens". The kernel 'psmouse' module, and the 'serio' layer that actually talks to the i8042, actually have much more thorough and robust support for PS/2 hotplugging than gpm ever did. The kernel even

Re: Mouse configuration during installation needs improvement

On Thu, May 29, 2008 at 12:22:15PM -0500, Ron Johnson wrote: > Which I did many years ago. But it would still make it easier for > us dual-use people, and not affect only-gooey users, if gpm were the > default. I would like ssh installed by default before gpm, but I don't think we need to go back

Re: Re: Mouse configuration during installation needs improvement

On Thu, May 29, 2008 at 07:35:20AM -0700, Stephen Powell wrote: > Thanks for the update on mouse sharing in newer > kernels. I didn't realize that this support had been > added. That does take away part of my supporting > argument for configuring X to use gpm. It was a very

Re: Mouse configuration during installation needs improvement

On Thu, May 29, 2008 at 08:16:28AM +1000, Ben Finney wrote: > Where is your data for this assertion? The number of people that have no idea how to get to the console from X. Personally I hate dealing with machines that don't have gpm installed, but I don't want to bloat the base install either.

Re: Mouse configuration during installation needs improvement

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/08 11:25, Frans Pop wrote: > Ron Johnson wrote: >> On 05/29/08 09:35, Stephen Powell wrote: >>> I'm not sure how one would know that most people don't >>> use the console. I, for one, use it a lot. But even > > I work mainly in consoles too

Re: Mouse configuration during installation needs improvement

Ron Johnson wrote: > On 05/29/08 09:35, Stephen Powell wrote: >> I'm not sure how one would know that most people don't >> use the console. I, for one, use it a lot. But even I work mainly in consoles too but I have no use at all for gpm as my consoles are normally all in a graphical environmen

Re: Re: Mouse configuration during installation needs improvement

On Thu, May 29, 2008 at 07:35:20 -0700, Stephen Powell wrote: > I realize that PS/2 mice were not intended to be hot > swapped, but "stuff happens". Sometimes the connector > is loose and falls out, sometimes a mischievous > co-worker unplugs it as a practical joke, sometimes > the mouse fails, s

Re: Mouse configuration during installation needs improvement

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/08 09:35, Stephen Powell wrote: [snip] > >> Given most people don't use the console ever, >> installing a service that >> is only for console use by default is simply wrong. > > I'm not sure how one would know that most people don't > use th

Re: Re: Mouse configuration during installation needs improvement

> With current kernels, if you use /dev/input/mice, the > port can be shared > by gpm and X at the same time, and all mice you connect > (no matter what) > show up in that device. Thanks for the update on mouse sharing in newer kernels. I didn't realize that this support had been added. That doe

Re: Mouse configuration during installation needs improvement

Quoting Ben Finney ([EMAIL PROTECTED]): > [EMAIL PROTECTED] (Lennart Sorensen) writes: > > > Given most people don't use the console ever > > Where is your data for this assertion? Probably too wide generalization by Lennart. My own assertion was that people who use the console *on an enough re

Re: Mouse configuration during installation needs improvement

On jeu, 2008-05-29 at 08:16 +1000, Ben Finney wrote: > This argument would also see the removal of 'login', since that's not > needed by your putative majority of people who don't log in over > text-only interfaces. Do you _really_ think gpm is as important as login? -- Yves-Alexis signature.as

Re: Mouse configuration during installation needs improvement

[EMAIL PROTECTED] (Lennart Sorensen) writes: > Given most people don't use the console ever Where is your data for this assertion? > installing a service that is only for console use by default is > simply wrong. The less services need to be enabled by default the > better. This argument would

Re: Mouse configuration during installation needs improvement

On Wed, May 28, 2008 at 06:49:17AM +0200, Christian Perrier wrote: > Not to mention the various remarks that have been made, I would like > to enhance that ppl who use the Linux console on a regular basis > (which is usually what motivates activating a mouse on it) are > perfectly able to know that

Re: Mouse configuration during installation needs improvement

Quoting Stephen Powell ([EMAIL PROTECTED]): > This will allow the use of the mouse both in a virtual > console and in X. Not only that, but "hot swapping" Not to mention the various remarks that have been made, I would like to enhance that ppl who use the Linux console on a regular basis (which

Re: Mouse configuration during installation needs improvement

Lennart Sorensen wrote: > With current kernels, if you use /dev/input/mice, the port can be shared > by gpm and X at the same time, and all mice you connect (no matter what) > show up in that device. Of course PS/2 mice can not be connected while > the system is on, since the hardware simply is no

Re: Mouse configuration during installation needs improvement

On Tue, May 27, 2008 at 12:57:11PM -0700, Stephen Powell wrote: > Per the suggestion of J?r?my Bobbio when he closed Bug > # 481514 against installation-reports, I am posting > this item to the debian-devel mailing list. > > The Debian installer needs some improvement when it &

Mouse configuration during installation needs improvement

Per the suggestion of Jérémy Bobbio when he closed Bug # 481514 against installation-reports, I am posting this item to the debian-devel mailing list. The Debian installer needs some improvement when it comes to mouse configuration. Currently, if the user requests a "standard system&q

Re: ML improvement proposition (Re: SMTP 550 on replies to bugs)

* 18-09-2007, Bernd Zeimetz * User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.4) Gecko/20070828 Thunderbird/2.0.0.4 Mnenhy/0.7.5.0 > >> * Allow messages, that have "In-reply-to" and "References" with valid >> message-id's (SHOULD in rfc2822) to pass to bts/ml freely. > > Why? This

Re: ML improvement proposition (Re: SMTP 550 on replies to bugs)

> * Allow messages, that have "In-reply-to" and "References" with valid > message-id's (SHOULD in rfc2822) to pass to bts/ml freely. Why? This can be faked easily, getting them together with a destination email address should be pretty easy for spammers. > * Opening new threads in MLs requires

ML improvement proposition (Re: SMTP 550 on replies to bugs)

(-devel was added in case if somebody is interested) 06-09-2007, Don Armstrong: > On Thu, 06 Sep 2007, Oleg Verych (Gmane) wrote: >> Should i reopen/post/close? Or additional info just not needed for >> "thousands of users and indexing search engines"? > > If there's a valid reason to add more inf

Re: suggestions for improvement

Branden Robinson writes: > The sad thing is, it's not necessary to ask this at all. [...] > > Please file a bug against any package that asks you to choose between mono > and color app-defaults files, and include this mail in it if you want. OK, I've submitted bug reports against xftpd and xsysi

Re: suggestions for improvement

Jonathan Walther writes: > No. Consider the case of America and Canada. They share 5 > timezones between them, but differ in the default dictionaries that > are appropriate. Too much work for too little gain. However, if > you make a nice patch and submit it to the maintainer of the > "diction

Re: Improvement ;)

Jason Gunthorpe wrote: > > On Thu, 30 Apr 1998 [EMAIL PROTECTED] wrote: > > > 2. Make sure that the color monitors are supported automatically from the > > installation screen itself. > > Thats a good point, who actually has a truely MONO screen anymore? I've > got lots of 'mono' VGA screens (g

Re: Improvement ;)

Jason Gunthorpe wrote: > Thats a good point, who actually has a truely MONO screen anymore? I've > got lots of 'mono' VGA screens (grey scale actually) and I have one true > mono screen on the floor someplace, it connects an old 8bit herc card. I hope that one day we will be able to install debian

Re: Improvement ;)

On Thu, Apr 30, 1998 at 08:21:13PM -0600, Jason Gunthorpe wrote: > I think machines with a mono video card (ie a herc) would be unable to run > Debian in the first place, and a greyscale screen doesn't need mono > support. Why's that? I ran Debian successfully on one machine with a Herc card for o

Re: Improvement ;)

On Thu, 30 Apr 1998 [EMAIL PROTECTED] wrote: > 2. Make sure that the color monitors are supported automatically from the > installation screen itself. Thats a good point, who actually has a truely MONO screen anymore? I've got lots of 'mono' VGA screens (grey scale actually) and I have one true

Re: Improvement ;)

I say -- Put your code where your mouth is. Loads of people are saying what "ought" to be. Most Linux things exist because someone wanted it and nothing existed to do it. Or what did exist they hated. If you want to see something done -- give code. I find the Debian install a matter of poundin

Improvement ;)

A couple of thing I noticed in debian that can be improved (for an average user) 1. Add lines in \etc\fstab automatically or with a menu to mount other partitions. 2. Make sure that the color monitors are supported automatically from the installation screen itself. 3. Ease of configuration by