2012/4/18 Mike Gabriel
> Package: libept1.4.12
> Version: 1.0.6.1
> Severity: Important
>
> Hi Oliver, hi Enrico, hi all,
>
>
> On Di 17 Apr 2012 17:29:53 CEST olivier sallou wrote:
>
> 2012/4/17 olivier sallou
>>
>> Hi,
>>> I cannot get debootstrap working anymore in sid since libept update.
Dear all,
I would like to start working on the future openjpeg 1.5 transition.
openjpeg 1.5 has been uploaded to experimental:
https://buildd.debian.org/status/package.php?p=openjpeg&suite=experimental
I would like to now `mass-bug` on all packages that build-dep on
libopenjpeg-dev, namely:
Roger Leigh writes:
> On Wed, Apr 11, 2012 at 12:13:09PM +0200, Goswin von Brederlow wrote:
>> Roger Leigh writes:
>> As a side note I have a use case at work where static order seems to be
>> needed. We build boot images for network boot of clusters. During boot
>> additional files can be copie
Petter Reinholdtsen writes:
> [Sven Joachim]
>> I beg to disagree, it is already unsupportable because the only way
>> to test it is to set up a lenny system, create some local init
>> script without LSB headers to prevent migration to dependency based
>> boot, and then upgrade all the way to squ
Raphael Geissert writes:
> Goswin von Brederlow wrote:
>> 3) Aborting the upgrade because dependency boot ordering fails will be a
>> major issue for users. You already mentioned 2 issues and on my system
>> at home I get an error about a dependency loop. Dependency based boot
>> doesn't seem to
On 04/18/2012 08:27 AM, Steve McIntyre wrote:
> If a maintainer isn't (capable of) doing the necessary work on a
> package themselves, then after a while the best thing they can do is
> admit that and cede control to others. It's not an easy thing to admit
> "failure" like this, but it's better to
On Wed, Apr 18, 2012 at 04:57:14PM +0800, Thomas Goirand wrote:
> what can we do if the maintainer doesn't admit his lack of time or his
> lack of skills/knowledge? My understanding is that in Debian, we are
> stuck, right? I believe that was the message of Chris: we don't really
> have procedures
On Wed, Apr 18, 2012 at 10:16:56AM +0100, Jon Dowland wrote:
> On Wed, Apr 18, 2012 at 04:57:14PM +0800, Thomas Goirand wrote:
> > what can we do if the maintainer doesn't admit his lack of time or his
> > lack of skills/knowledge? My understanding is that in Debian, we are
> > stuck, right? I beli
On Wed, 2012-04-18 at 10:16 +0100, Jon Dowland wrote:
> We have hijacks, we have the tech committee: weapons of last resort.
I was thinking about the same issue before this thread. My feeling is
that over the same time period in which we've moved towards team
maintenance, and moved to a lower thr
Package: wnpp
Severity: wishlist
Owner: Alessio Treglia
* Package name: lv2
Version : 1.0.0
Upstream Author : David Robillard
* URL : http://lv2plug.in/
* License : ISC
Programming Lang: C
Description : LV2 audio plugin specification
LV2 is a simple
* Mathieu Malaterre , 2012-04-18, 09:40:
I would like to start working on the future openjpeg 1.5 transition.
openjpeg 1.5 has been uploaded to experimental:
https://buildd.debian.org/status/package.php?p=openjpeg&suite=experimental
I would like to now `mass-bug` on all packages that build-dep
On Wed, Apr 18, 2012 at 1:44 PM, Jakub Wilk wrote:
> * Mathieu Malaterre , 2012-04-18, 09:40:
>
>> I would like to start working on the future openjpeg 1.5 transition.
>> openjpeg 1.5 has been uploaded to experimental:
>>
>> https://buildd.debian.org/status/package.php?p=openjpeg&suite=experimenta
On 18/04/12 12:51, Mathieu Malaterre wrote:
>> Intention to do what?
>
> Move the package from experimental once buildd are ok to unstable and
> then testing...
This is a transition. Before starting a transition, open a
release.debian.org bug asking the release team to schedule it, and wait
for a
Hey folks!
As already announced on the DPN (Debian Project News from April 16th,
2012), we will have a Debian BSP (Bug Squashing Party) event on the 29th
and 30th of April 2012. That's in a little bit more than a week, so
it's more than time to send the announcement!
All the practical details a
Russell Coker escreveu isso aí:
> Is there any progress being made on packaging these systems? Are there other
> social networking systems released under free licenses that we can package?
I am upstream for Noosfero (http://noosfero.org/), and we provide
packages for Debian stable as part of our
Package: wnpp
Severity: wishlist
Owner: Reto Buerki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: anet
Version : 0.1
Upstream Author : codelabs.ch
* URL : http://www.codelabs.ch/anet/
* License : GPL-2+ with Ada exception
Programming Lang:
severity 664257 important
thanks
On 18.04.2012 05:16, Jonathan Nieder wrote:
> Hi Matthias,
>
> Steve McIntyre wrote:
>
>> I've updated http://wiki.debian.org/Multiarch/Tuples with lots more
>> information such as links to external ABI specs where I could find
>> them.
>
> I think the Multiarch
Processing commands for cont...@bugs.debian.org:
> severity 664257 important
Bug #664257 [general] multiarch tuples are not documented/defined
Severity set to 'important' from 'serious'
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
664257: http://bugs.debian.org
On Wednesday, April 18, 2012 04:57:14, Thomas Goirand wrote:
> On 04/18/2012 08:27 AM, Steve McIntyre wrote:
> > If a maintainer isn't (capable of) doing the necessary work on a
> > package themselves, then after a while the best thing they can do is
> > admit that and cede control to others. It's
Package: wnpp
Severity: wishlist
Owner: Laszlo Kajan
* Package name: dssp
Version : 2.0.4
Upstream Author : Maarten L. Hekkelman
* URL : http://www.cmbi.ru.nl/dssp/
* License : Boost-1.0
Programming Lang: C++
Description : protein secondary structure a
On Wed, 18 Apr 2012 11:05:38 +0100
Moray Allan wrote:
> On Wed, 2012-04-18 at 10:16 +0100, Jon Dowland wrote:
> > We have hijacks, we have the tech committee: weapons of last resort.
>
> I was thinking about the same issue before this thread. My feeling is
> that over the same time period in wh
Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry
* Package name: pygrib
Version : 1.9.3
Upstream Author : Jeff Whittaker
* URL : https://pygrib.googlecode.com/svn/trunk/docs/index.html
* License : BSD
Programming Lang: Python
Description : py
On Wed, Apr 18, 2012 at 10:00:43AM -0400, Chris Knadle wrote:
> Debian has NMUs (Non-Maintainer Uploads) -- however this is mainly meant for
> uploading critical bug fixes without having to resort to hijacking the
> package, and AFAIK not to be used to upload new versions of the software.
Before
On Wednesday, April 18, 2012 04:57:14 PM Thomas Goirand wrote:
> On 04/18/2012 08:27 AM, Steve McIntyre wrote:
> > If a maintainer isn't (capable of) doing the necessary work on a
> > package themselves, then after a while the best thing they can do is
> > admit that and cede control to others. It'
On Wed, Apr 18, 2012 at 10:21 AM, Stefano Zacchiroli wrote:
> On Wed, Apr 18, 2012 at 10:00:43AM -0400, Chris Knadle wrote:
>> Debian has NMUs (Non-Maintainer Uploads) -- however this is mainly meant for
>> uploading critical bug fixes without having to resort to hijacking the
>> package, and AFAI
Michael Gilbert writes:
> Is it reasonable to do an NMU that has a debdiff equivilent of around
> 500 upstream git commits (the size of ever new upstream wine release)?
I don't think it's possible to answer that question with a firm yes or no.
It depends heavily on the situation, what bugs such
On Wednesday, April 18, 2012 10:21:45, Stefano Zacchiroli wrote:
> On Wed, Apr 18, 2012 at 10:00:43AM -0400, Chris Knadle wrote:
> > Debian has NMUs (Non-Maintainer Uploads) -- however this is mainly meant
> > for uploading critical bug fixes without having to resort to hijacking
> > the package, a
On Wed, Apr 18, 2012 at 11:28:33AM -0400, Chris Knadle wrote:
> The way section 5.11 is written, it implies NMUs are for bug fixes only. It
> literally states "Fixing cosmetic issues or changing the packaging style in
> NMUs is discouraged." Nowhere in the section is it implied that NMUs can be
Processing commands for cont...@bugs.debian.org:
> retitle 664257 multiarch tuples are not in the FHS
Bug #664257 [general] multiarch tuples are not documented/defined
Changed Bug title to 'multiarch tuples are not in the FHS' from 'multiarch
tuples are not documented/defined'
> tags 664257 + ups
On Wednesday, April 18, 2012 11:42:33, Jon Dowland wrote:
> On Wed, Apr 18, 2012 at 11:28:33AM -0400, Chris Knadle wrote:
> > The way section 5.11 is written, it implies NMUs are for bug fixes only.
> > It literally states "Fixing cosmetic issues or changing the packaging
> > style in NMUs is disc
Neil Williams wrote:
> Equally, take a care about which packages your packages depend upon
> because if there are optional components which bring in dependencies on
> shoddy code, you may need to quickly back away from those dependencies
> or face your own package being removed.
This conflates the
Hi,
I would like to throw out an idea for constructively combating low
activity in strongly maintained packages.
Across the Debian package ecosystem team maintainership has been seen
as the strongest antidote for package stagnation. This process "just
works" because as one team member becomes le
On Wed, Apr 18, 2012 at 12:20:51PM -0400, Joey Hess wrote:
> Package removal frequently causes collatoral damage, and in my
> experience, those doing the removals rarely consider it, and are happy
> wasting other people's time.
Sometimes not removing a package causes collatoral damage and wastes o
On Wed, Apr 18, 2012 at 11:00:00AM +0200, Goswin von Brederlow wrote:
> Petter Reinholdtsen writes:
> > [Sven Joachim]
> >> I beg to disagree, it is already unsupportable because the only way
> >> to test it is to set up a lenny system, create some local init
> >> script without LSB headers to pre
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok
* Package name: mkgltempdir
Version : 0.0.3
Upstream Author : Nikhef Grid Security Middleware Team
* URL : http://wiki.nikhef.nl/grid/GLExec_TransientPilotJobs
* License : Apache 2
Programming Lang: Bou
On Wed, Apr 18, 2012 at 07:15:48PM +0200, Philipp Kern wrote:
> On Wed, Apr 18, 2012 at 11:00:00AM +0200, Goswin von Brederlow wrote:
> > Petter Reinholdtsen writes:
> > > [Sven Joachim]
> > >> I beg to disagree, it is already unsupportable because the only way
> > >> to test it is to set up a len
Quoting Chris Knadle (chris.kna...@coredump.us):
> for lowering of severity level. [And realistically at least in the general
> case I don't think another DD is going to do an NMU if a bug is not RC.]
Have you seen the gazillion of localization NMUs I'm doing for about
4-5 years now? :-)
As l
On Wed, 2012-04-18 at 19:26 +0200, Dennis van Dok wrote:
> * Package name: mkgltempdir
> Version : 0.0.3
> Upstream Author : Nikhef Grid Security Middleware Team
>
> * URL : http://wiki.nikhef.nl/grid/GLExec_TransientPilotJobs
The link to the source code on that page
On Wed, 2012-04-18 at 13:10 -0400, Michael Gilbert wrote:
> So anyway, enough explanation, on to my proposed solution. Seeing as
> team spirit has been a quite effective antidote to stagnation, lets go
> ahead and use that again.
I agree with the general intention, but not with the details of the
On 15/04/12 15:04, Ben Hutchings wrote:
> On Sun, 2012-04-15 at 19:32 +0600, Andrey Rahmatullin wrote:
>> On Sun, Apr 15, 2012 at 01:18:28PM +0200, Petr Baudis wrote:
>>> I am rather dazzled that while there is working source package
>>> of wine-1.5 ready, other people are working on gradually
>>>
On Wednesday, April 18, 2012 11:19:39, Russ Allbery wrote:
...
> When we're talking about packaging significant new upstream releases, I
> think NMUs are dodging the problem in a somewhat unuseful way, and we
> really need to sort out the maintenance of the package going forward
> instead.
>
>
On Wed, Apr 18, 2012 at 2:12 PM, Moray Allan wrote:
> On Wed, 2012-04-18 at 13:10 -0400, Michael Gilbert wrote:
>> So anyway, enough explanation, on to my proposed solution. Seeing as
>> team spirit has been a quite effective antidote to stagnation, lets go
>> ahead and use that again.
>
> I agree
On Wed, Apr 18, 2012 at 01:10:42PM -0400, Michael Gilbert wrote:
> So anyway, enough explanation, on to my proposed solution. Seeing as
> team spirit has been a quite effective antidote to stagnation, lets go
> ahead and use that again. Here is my suggested process:
Nowhere in this process seems
On Wed, Apr 18, 2012 at 2:51 PM, Colin Watson wrote:
> Nowhere in this process seems to be the notion that you should
> contribute actual effort first before adding yourself as an uploader. I
> think that's important, particularly in the many situations where it's
> not lack of packaging of a new
]] Colin Watson
> alioth is just a Debian-specific hosting site, not a general gateway to
> package maintenance. We're not set up for them to be dispute resolution
> for the whole of Debian, and they have no constitutional authority to do
> that anyway. De-emphasising the role of alioth adminis
Michael Gilbert wrote:
> Plus I don't have to find hosting for my work elsewhere,
> which is kind of a pain and unwanted.
This at least is easy to address. Alioth automatically notices
per-user git repositories under ~/public_git[1]. Something similar
works for other version contr
Op 18-04-12 20:10, Adam D. Barratt schreef:
> On Wed, 2012-04-18 at 19:26 +0200, Dennis van Dok wrote:
>> * Package name: mkgltempdir
>> Version : 0.0.3
>> Upstream Author : Nikhef Grid Security Middleware Team
>>
>> * URL : http://wiki.nikhef.nl/grid/GLExec_TransientP
On Wed, Apr 18, 2012 at 10:16:56AM +0100, Jon Dowland wrote:
> On Wed, Apr 18, 2012 at 04:57:14PM +0800, Thomas Goirand wrote:
> > what can we do if the maintainer doesn't admit his lack of time or his
> > lack of skills/knowledge? My understanding is that in Debian, we are
> > stuck, right? I beli
On 12-04-18 at 07:17pm, Simon McVittie wrote:
> I hesitate to suggest this if there's a possibility that the main wine
> package can come up to date before we freeze, but one way to have Wine
> 1.4 (and/or 1.2) in the distribution without NMUs/hijacks would be a
> parallel wine-1.4 source packag
Chris Knadle writes:
> I think the above is reasonable and fits the Debian "do-acracy"
> methodology.
> At the same time, I also understand that this is a tough call to make.
> Removing the current maintainer if they're not totally MIA may not seem
> right -- it may feel "heavy-handed". Perhaps
Le Wed, Apr 18, 2012 at 10:00:43AM -0400, Chris Knadle a écrit :
>
> But what I'm seeing is that there are "in-between" states, where there
> doesn't
> seem to be any correct action to take. If a maintainer is not completely MIA
> but is going to not have any time for maintainership for 6 mont
Charles Plessy writes:
> If somebody foresees he can not maintain his packages for the next six
> months, I think that he should really consider mark his inactivity by
> proposing the package for adoption, arranging co-maintenance in a team,
> switching on the vacation flag on the LDAP, or ask hi
On Wednesday, April 18, 2012 04:04:49 PM Russ Allbery wrote:
> Chris Knadle writes:
> > I think the above is reasonable and fits the Debian "do-acracy"
> > methodology.
> >
> > At the same time, I also understand that this is a tough call to make.
> > Removing the current maintainer if they're no
53 matches
Mail list logo
