Package: wnpp
Severity: wishlist
Owner: Anton Gladky
* Package name: pysph
* URL : http://pysph.googlecode.com
* License : BSD
Programming Lang: Python
Description : Open source framework for Smoothed Particle Hydrodynamics
open source framework for Smoothed Parti
On Thu, 2014-12-11 at 21:08 -0600, Benjamin Przybocki wrote:
> Hello,
> I am aware that Debian Jessie will be using Linux Kernel 3.16, however
> I was wondering if there is a possibility of Jessie including some of
> the features added in 3.17 such as: getrandom(), support for Acer
> C720, and supp
On Thursday, December 11, 2014 09:23:36 PM Barry Warsaw wrote:
> On Dec 12, 2014, at 08:36 AM, Ben Finney wrote:
> >Even for the source package name, “pathlib” is IMO too general. This is
> >specifically a library for Python programmers only; its source package
> >name should not grab a generic nam
Hello,
I am aware that Debian Jessie will be using Linux Kernel 3.16, however I
was wondering if there is a possibility of Jessie including some of the
features added in 3.17 such as: getrandom(), support for Acer C720, and
support for Broadwell audio.
getrandom() commit:
http://git.kernel.org/cgi
I'm interested in EFI, and therefore in debian-efi.
David Coe
+1 410 489 9521
On Thu, Dec 11, 2014 at 7:49 PM, Fernando Toledo
wrote:
> El 11/12/14 a las 16:00, Steve McIntyre escibió:
> > Hi folks,
> >
> > I'm thinking it might be useful to set up a specific debian-efi
> > mailing list to hel
On Dec 12, 2014, at 08:36 AM, Ben Finney wrote:
>Even for the source package name, “pathlib” is IMO too general. This is
>specifically a library for Python programmers only; its source package
>name should not grab a generic name like “pathlib”.
Why not first-come-first-served?
Cheers,
-Barry
El 11/12/14 a las 16:00, Steve McIntyre escibió:
> Hi folks,
>
> I'm thinking it might be useful to set up a specific debian-efi
> mailing list to help as a central space for discussion about (U)EFI
> issues and support in Debian.
>
> There's been quite a lot of development in this area recently,
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: 656 (new: 4)
Total number of packages offered up for adoption: 145 (new: 0)
Total number of packages request
Benjamin Drung writes:
> The source is called pathlib, but the binary packages are called
> python-pathlib and python-pathlib-doc.
Even for the source package name, “pathlib” is IMO too general. This is
specifically a library for Python programmers only; its source package
name should not grab a
On 11 December 2014 at 20:07, Neil Williams wrote:
> On Thu, 11 Dec 2014 19:36:19 +0100
> Simon Richter wrote:
>
>> Hi Leif,
>>
>> On 11.12.2014 19:08, Leif Lindholm wrote:
>>
>> > If we could transition this to be able to specify efi-all (or
>> > whatever) instead of an explicit list of certain
On 11/12/14 18:08, Leif Lindholm wrote:
> The point is, when we add support for another architecture which
> supports UEFI, there are a number of packages that you will want to
> enable for that architecture.
I've occasionally wished we had a way to make a requiring package
conditionally built dep
Quoting Neil Williams (2014-12-11 21:07:15)
> On Thu, 11 Dec 2014 19:36:19 +0100
> Simon Richter wrote:
>> On 11.12.2014 19:08, Leif Lindholm wrote:
>>
>>> If we could transition this to be able to specify efi-all (or
>>> whatever) instead of an explicit list of certain architectures, this
>>> w
Hi,
On Thu, Dec 11, 2014 at 06:08:58PM +, Leif Lindholm wrote:
> When working on UEFI kernel support, for both armhf and arm64, we came
> across packages (in several distributions) that were manually set to
> build for architectures where UEFI was available - and so would not be
> built for th
On Thu, 11 Dec 2014 19:36:19 +0100
Simon Richter wrote:
> Hi Leif,
>
> On 11.12.2014 19:08, Leif Lindholm wrote:
>
> > If we could transition this to be able to specify efi-all (or
> > whatever) instead of an explicit list of certain architectures, this
> > would be a lot more straightforward o
Quoting Simon Richter (2014-12-11 19:36:19)
> On 11.12.2014 19:08, Leif Lindholm wrote:
>
>> If we could transition this to be able to specify efi-all (or
>> whatever) instead of an explicit list of certain architectures, this
>> would be a lot more straightforward operation.
>
>> Would this be u
Simon Richter wrote:
>Hi Leif,
>
>On 11.12.2014 19:08, Leif Lindholm wrote:
>
>> If we could transition this to be able to specify efi-all (or
>> whatever) instead of an explicit list of certain architectures, this
>> would be a lot more straightforward operation.
>
>> Would this be useful, desirab
Hi folks,
I'm thinking it might be useful to set up a specific debian-efi
mailing list to help as a central space for discussion about (U)EFI
issues and support in Debian.
There's been quite a lot of development in this area recently, and (as
Leif just mentioned on -devel) there are a number of p
Hi Leif,
On 11.12.2014 19:08, Leif Lindholm wrote:
> If we could transition this to be able to specify efi-all (or
> whatever) instead of an explicit list of certain architectures, this
> would be a lot more straightforward operation.
> Would this be useful, desirable, an accident waiting to hap
When working on UEFI kernel support, for both armhf and arm64, we came
across packages (in several distributions) that were manually set to
build for architectures where UEFI was available - and so would not be
built for the ARM architectures.
These are some obvious utilites such as:
- efibootmgr
Thanks for quick replies! I'll go forward with AICCU and debconf way.
Not sure if I will eventually upload my package to Debian though,
since
this dynDNS provider is only for Finland and user base would be small.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
Package: wnpp
Owner: Balint Reczey
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: kerneloops
Version : 0.12+git20140509-1
Upstream Author : Arjan van de Ven
* URL : https://github.com/oops-kernel-org/kerneloops
* License : GPL-2
Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant
* Package name: pyzolib
Version : 0.3.3
Upstream Author : Almar Klein
* URL : https://bitbucket.org/pyzo/pyzolib
* License : BSD
Programming Lang: Python
Description : Utilities for the P
Hi,
> [Forwarding to d-d-a on behalf of Iain since he can not sign as DD]
The quoted message was addressed *to* Iain and didn't make much sense
to me.
Isn't this the announcement here?
https://lists.debian.org/debian-blends/2014/12/msg0.html
Regards,
--
Steven Chamberlain
ste...@pyro.eu.or
On Thu, Dec 11, 2014 at 01:39:29PM +0100, Iain R. Learmonth wrote:
> [Forwarding to d-d-a on behalf of Iain since he can not sign as DD]
This seems to be the wrong sort of email to forward to d-d-a.
(Note: I'm not subscribed to -devel, so CC me on a reply).
>
> Ian R Leamonth,
>
> In Debian GN
Am Donnerstag, den 11.12.2014, 14:35 +0100 schrieb Joachim Breitner:
> Hi,
>
>
> Am Mittwoch, den 10.12.2014, 17:17 +0100 schrieb Frank Brehm:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Frank Brehm
> >
> > * Package name: pathlib
> > Version : 1.0.1
> > Upstream Author
Hi,
Am Mittwoch, den 10.12.2014, 17:17 +0100 schrieb Frank Brehm:
> Package: wnpp
> Severity: wishlist
> Owner: Frank Brehm
>
> * Package name: pathlib
> Version : 1.0.1
> Upstream Author : Antoine Pitrou
> * URL : https://pypi.python.org/pypi/pathlib
> * License
On 2014-12-11 12:39, Iain R. Learmonth wrote:
[Forwarding to d-d-a on behalf of Iain since he can not sign as DD]
I suspect you forwarded the wrong mail, was it meant to be an
announcement from Iain about the blend as the subject line implies?
--
Jonathan Wiltshire
Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant
* Package name: iep
Version : 3.5
Upstream Author : Almar Klein
* URL : http://www.iep-project.org/
* License : BSD
Programming Lang: Python
Description : Interactive Editor for Python
D
❦ 11 décembre 2014 13:12 +0200, Eugene Zhukov :
> I plan to package a perl script to run as daemon. It will update
> dynamic DNS provider with IP changes etc., but for that it needs user
> credentials registered at provider's web site beforehand.
> Is it a good solution to ask for credentials at
Package: wnpp
Severity: wishlist
Owner: David Drysdale
* Package name: chaps
Version : 0.1
Upstream Author : ChromiumOS Authors
* URL : https://github.com/google/chaps-linux
* License : BSD
Programming Lang: C++
Description : PKCS#11 implementation for
On Thu, Dec 11, 2014 at 11:30:06AM +, Wookey wrote:
> +++ Eugene Zhukov [2014-12-11 13:12 +0200]:
> > Hi,
> >
> > I plan to package a perl script to run as daemon. It will update
> > dynamic DNS provider with IP changes etc., but for that it needs user
> > credentials registered at provider's
+++ Eugene Zhukov [2014-12-11 13:12 +0200]:
> Hi,
>
> I plan to package a perl script to run as daemon. It will update
> dynamic DNS provider with IP changes etc., but for that it needs user
> credentials registered at provider's web site beforehand.
> Is it a good solution to ask for credentials
Hi,
I plan to package a perl script to run as daemon. It will update
dynamic DNS provider with IP changes etc., but for that it needs user
credentials registered at provider's web site beforehand.
Is it a good solution to ask for credentials at package installation
step? These credentials and othe
33 matches
Mail list logo
