Hallo Jose,
You should also ping your RFS bug and maybe upload to mentors.d.n for
easier reviews and broader sponsor audience...
I could not find the package there to take a look.
(Though I could not sponsor you -- only just entered the NM process and
waiting for an AM :)
(BTW: You mail client i
Package: wnpp
Severity: wishlist
Owner: Emilio Pozuelo Monfort
* Package name: libinput
Version : 0.1.0
Upstream Author : Jonas Ådahl ,
Peter Hutterer
* URL : http://www.freedesktop.org/wiki/Software/libinput/
* License : MIT/X
Programmin
On Wed, Feb 26, 2014 at 10:09:22PM -0500, James McCoy wrote:
> On Wed, Feb 26, 2014 at 09:51:41PM -0500, Paul Tagliamonte wrote:
> > So, building off this mail (and ideas I had kicking around):
> >
> >
> > | Build-Depends-Indep field is defined as a list of architectures that the
> ^-- Build
On Wed, Feb 26, 2014 at 09:51:41PM -0500, Paul Tagliamonte wrote:
> So, building off this mail (and ideas I had kicking around):
>
>
> | Build-Depends-Indep field is defined as a list of architectures that the
^-- Build-Architecture-Indep, right?
Cheers,
--
James
GPG Key: 4096R/331BA3DB 20
On Wed, Feb 26, 2014 at 09:51:41PM -0500, Paul Tagliamonte wrote:
> Comments?
Erm, also - any package which omits this field may be considerd "any"
(or something like that)
Cheers,
Paul
--
.''`. Paul Tagliamonte | Proud Debian Developer
: :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7
On Wed, Feb 26, 2014 at 04:28:15PM +0100, Ansgar Burchardt wrote:
> "Build-Architecture-Indep" might also work and is visually similar to
> the already existing "Build-Depends-Indep" and "Build-Conflicts-Indep"
> fields.
Erm, I swear I didn't ignore your feedback; this is what I meant, I just
type
On Thu, Feb 27, 2014 at 7:51 AM, William Grant wrote:
> I'd probably define "Build-Indep-Architecture: armhf armel" to mean
> "build with -A on armhf if you have it, otherwise armel, otherwise
> nowhere". But maybe it would be better for "otherwise nowhere" to be
> "otherwise anywhere"?
You could
On 27/02/14 00:39, Paul Tagliamonte wrote:
> On Wed, Feb 26, 2014 at 01:11:55PM +, Thorsten Glaser wrote:
>> First, we need new syntax to specify the architectures an arch:all
>> package may be built on. (There may be cases where this cannot be
>> deducted from the other binary packages it buil
On Wed, Feb 26, 2014 at 11:28 PM, Ansgar Burchardt wrote:
> "Build-Architecture-Indep" might also work and is visually similar to
> the already existing "Build-Depends-Indep" and "Build-Conflicts-Indep"
> fields.
Why not just Build-Architectures? That also covers the case where an
arch-dependent
Nick Phillips writes:
> And if the newer version, for example, has updated a database schema in
> a non-backward-compatible way?
The same problem would apply to testing, so there would be a very high
incentive to find a way to fix that for testing users. Backports users
would then benefit from
On Wed, 2014-02-26 at 09:47 +0100, Gerfried Fuchs wrote:
> Erm, no, not at all. A package in stable-bpo can't have a newer
> version than testing when we release. With the removal there can be two
> situations:
>
> * After fixing the issue that got the package removed from testing, the
>p
I am sorry for being off topic. I am seeking for a DD or DM that use
amanda-server for sponsoring a new package 3.3.5. I am doing this by
suggestion of Bdale Garbee former DM of the package and because Bill
Blough asked for a sponsor on debian-mentors without success.
https://lists.debian.org/d
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: nose2-cov
Version : 1.0a4
Upstream Author : Meme Dough
* URL : https://pypi.python.org/pypi/nose2-cov/
* License : MIT/X
Programming Lang: Py
Package: wnpp
Owner: gregor herrmann
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libfile-slurp-tiny-perl
Version : 0.003
Upstream Author : Leon Timmermans
* URL : https://metacpan.org/release/File-Slurp-T
* Peter Samuelson [2014-02-26 18:36:10 CET]:
> [micah]
> > it feels like a bit too aggressive pressure for my tastes. I've seen
> > a lot of developers of packages who have found out their package will
> > be removed from testing, but don't have the time to resolve the
> > situation before it gets
[micah]
> it feels like a bit too aggressive pressure for my tastes. I've seen
> a lot of developers of packages who have found out their package will
> be removed from testing, but don't have the time to resolve the
> situation before it gets removed, resulting in much pulling of hair.
If only w
Package: wnpp
Severity: wishlist
Owner: Colin Watson
* Package name: python-tblib
Version : 0.1.0
Upstream Author : Ionel Cristian Mărieș
* URL : https://github.com/ionelmc/python-tblib
* License : BSD-2-clause
Programming Lang: Python
Description : Py
Hi.
* micah [2014-02-26 16:48:45 CET]:
> Gerfried Fuchs writes:
> > Remove from stable-bpo if it's not expected to come back in is what we
> > actually do, yes. And to have an overview of these situations I created
> > myself the diffstats page:
> > http://backports.debian.org/wheezy-backp
On Feb 26, 2014 10:49 AM, "micah" wrote:
> For example, say package X has been backported at version 1.0, version
> 2.0 is uploaded to sid, transitions to jessie and then has an RC bug
> that threatens removal.
If the RC bug is properly versioned, then the 1.0 upload, which isn't
affected, should
On Wed, 26 Feb 2014, Ansgar Burchardt wrote:
> For the implementation we might want to have a priority list. The
> first architecture from the priority list that is allowed in
> Build-Arch-Indep (or whatever) would build the arch:all packages. The
> list would likely start with amd64 or i386 so tha
Gerfried Fuchs writes:
> Remove from stable-bpo if it's not expected to come back in is what we
> actually do, yes. And to have an overview of these situations I created
> myself the diffstats page:
> http://backports.debian.org/wheezy-backports/overview/
>
> Looking at the "not available" pa
On 02/26/2014 14:39, Paul Tagliamonte wrote:
> I was going to send a mail about this yesterday. I've decided I'm going
> to start a quest to support this. I settled on Build-Indep-Architecture
> myself.
"Build-Architecture-Indep" might also work and is visually similar to
the already existing "Bui
[Paul Tagliamonte]
> I was going to send a mail about this yesterday. I've decided
> I'm going to start a quest to support this. I settled on
> Build-Indep-Architecture myself.
Sorry for the bikeshedding, but don't we already have ways to express
exactly what we mean?
Build-Depends-Indep: so
Hi,
Le 26/02/2014 15:55, Jakub Wilk a écrit :
> * Paul Tagliamonte , 2014-02-26, 08:39:
>>> First, we need new syntax to specify the architectures an arch:all
>>> package may be built on. (There may be cases where this cannot be
>>> deducted from the other binary packages it builds – if any. Heck,
On Wed, Feb 26, 2014 at 03:55:37PM +0100, Jakub Wilk wrote:
> >BTW; the syntax would define a single arch; you know, in the
> >spirit of reproducability.
>
> I have mixed feeling about this. On one hand, most[0] of arch:all
> packages can be built on more than one architecture, so “single
> arch”
* Paul Tagliamonte , 2014-02-26, 08:39:
First, we need new syntax to specify the architectures an arch:all
package may be built on. (There may be cases where this cannot be
deducted from the other binary packages it builds – if any. Heck,
there may even be cases where a source package has multi
Package: wnpp
Severity: wishlist
Owner: Antonio Terceiro
* Package name: vagrant-lxc
Version : 0.8.0-
Upstream Author : Fábio Rehm
* URL : https://github.com/fgrehm/vagrant-lxc
* License : MIT
Programming Lang: Ruby
Description : Linux Containers provid
On Wed, Feb 26, 2014 at 01:11:55PM +, Thorsten Glaser wrote:
> First, we need new syntax to specify the architectures an arch:all
> package may be built on. (There may be cases where this cannot be
> deducted from the other binary packages it builds – if any. Heck,
> there may even be cases whe
* Thorsten Glaser , 2014-02-26, 12:54:
To add insult to injury, buildd/sbuild currently hardcode both
--apt-update --no-apt-dist-upgrade
My sbuild.conf contains this:
# APT_DISTUPGRADE
# Type: BOOL
# APT distupgrade. 1 to enable running "apt-get dist-upgrade" at the start
# of each build, or
Carlos Alberto Lopez Perez igalia.com> writes:
> On 13/02/14 22:10, Dimitri John Ledkov wrote:
> > All that's needed, I guess, is for someone to write a patch to dak /
> > wanna-build ... and schedule _all.deb builds on amd64 ?
> > Or if arch-restricted package, on one of the arches it will buil
Paul Tagliamonte debian.org> writes:
>
> On Fri, Feb 14, 2014 at 04:39:25PM +0100, Wouter Verhelst wrote:
> > > Are buildd people happy with humans sending their logs this way?
> >
> > Well, I am, but it's probably not my call.
>
> Which keyring does it use to validate? Can DMs send logs? Does
Sam Hartman debian.org> writes:
[ autotools ]
> I assure you, that even if you get past the being blind bit, it's still
> impossible to figure out what's going on.
And even then, even when you did the unbelievable and, say, ported libtool
to MirBSD and Interix (consuming a whole bottle of wine i
Package: wnpp
Owner: Dominique Dumont
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libjira-client-automated-perl
Version : 1.04
Upstream Author : Michael Friedman
* URL : https://metacpan.org/release/JIRA-
Andrey Rahmatullin wrar.name> writes:
> On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wrote:
> > this is just a pledge to you all fellow debian developers to update your
> > build environment before you build a package.
> Isn't that one of problems fixed by rebuilding everything on buil
On Wed, Feb 26, 2014 at 9:12 AM, Andreas Tille wrote:
> Hi Bastien,
>
> On Tue, Feb 25, 2014 at 10:12:47PM +0100, Bastien ROUCARIES wrote:
>> I will add a Lintian warning if debian/uscan is a file.
>
> Just to make sure it was only a typo: You surely mean debian/upstream,
> right?
Right
>
> Kind
Hi there.
* Paul Tagliamonte [2014-02-25 23:59:05 CET]:
> I'm sending to both -devel and backports. I'm not sure which is the
> correct list. If one's wrong, feel free to drop it in replies.
>
> I've been talking with a mentee about backporting procedures, and I've
> explained why we don't b
On Tue, Feb 25, 2014 at 3:33 PM, Paul Wise wrote:
>> What shall we do? Remove from stable-bpo? Hope an update comes around?
>> Does it make sense to revisit the rules? Does a wait until testing still
>> make sense (ok, waiting always makes sense, but beyond the 'let it
>> settle' thing)
>
> Autor
Hi Simon,
(Charles intentionally in CC to make sure it will not be overlooked)
On Tue, Feb 25, 2014 at 08:43:51PM +0100, Simon Kainz wrote:
> I use a daily dump of
>
> svn://svn.debian.org/svn/collab-qa/packages-metadata
>
> to get the URLS from upstream metadata into DUCK. Does this naming
> co
Hi Bastien,
On Tue, Feb 25, 2014 at 10:12:47PM +0100, Bastien ROUCARIES wrote:
> I will add a Lintian warning if debian/uscan is a file.
Just to make sure it was only a typo: You surely mean debian/upstream,
right?
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, ema
39 matches
Mail list logo
