]] Hector Oron
[...]
| Even more, there is no yet a decision if the architecture is accepted
| or not in the "official" archive, we have not requested such thing
| (yet) as we do not meet archive criteria for now. But as other
| unofficial ports, I guess it is correct to add support for it into
Hi,
2011/2/28 Tollef Fog Heen :
> ]] Hector Oron
> | > * Raising the severity doesn't really imply anything
> |
> | True. Would you suggest some better way to proceed with porter-NMU?
> I would think it quite rushed to be pushing NMUs for an archicture not
> in Debian and not even in dpkg yet.
]] Hector Oron
Hi,
| > * Raising the severity doesn't really imply anything
|
| True. Would you suggest some better way to proceed with porter-NMU?
I would think it quite rushed to be pushing NMUs for an archicture not
in Debian and not even in dpkg yet. Even more so when it's not accepted
as
Hello Raphael,
2011/2/27 Raphael Geissert :
>> I do really apologize in case we have miss something, we'll try to do
>> better next time.
> Let's list a few things:
> * I didn't like that there was no notification on the bug report
We note that one for next time.
IMHO, BTS should acknowledge th
On Sun, Feb 27, 2011 at 03:29:05PM -0600, Raphael Geissert wrote:
> Steve Langasek wrote:
> > On Sun, Feb 27, 2011 at 02:41:32PM -0600, Raphael Geissert wrote:
> >> If you ask me, I would say that providing a magic for file(1) as I said
> >> on debian-arm[1] would be more useful that NMUing a few
Steve Langasek wrote:
> On Sun, Feb 27, 2011 at 02:41:32PM -0600, Raphael Geissert wrote:
>> If you ask me, I would say that providing a magic for file(1) as I said
>> on debian-arm[1] would be more useful that NMUing a few hanging fruits.
>> Lintian will annoy people with one tag per ELF object o
On Sun, Feb 27, 2011 at 02:41:32PM -0600, Raphael Geissert wrote:
> If you ask me, I would say that providing a magic for file(1) as I said on
> debian-arm[1] would be more useful that NMUing a few hanging fruits.
> Lintian will annoy people with one tag per ELF object otherwise.
Um, that'll be a
On Sun, Feb 27, 2011 at 08:21:25PM +, Hector Oron wrote:
> I do really apologize in case we have miss something, we'll try to do
> better next time.
Thanks for this followup Hector.
FWIW, no one said those NMUs were not welcome and it's in fact nice to
see you're pushing for armhf. Julien's (
[removing most CCs and setting reply to -devel]
Hi,
On Sunday 27 February 2011 14:21:25 Hector Oron wrote:
> 2011/2/27 Julien Cristau :
> > there are a number of NMUs currently in the delayed queue, adding armhf
> > support to some packages. The bugs referenced in those uploads have
> > seen no
Hello,
2011/2/27 Julien Cristau :
> there are a number of NMUs currently in the delayed queue, adding armhf
> support to some packages. The bugs referenced in those uploads have
> seen no notification of any such upload, and no NMU diff has been sent.
> Please fix this. And in the future, do th
* martin f krafft [Mon, 05 Jun 2006 15:58:47 +0200]:
> exactly. Ideally, write a bug before you start preparing the NMU,
> and then try to fix it before the bug confirmation gets in. :)
The real kick is to put dak and the BTS to compete. You `nmudiff`, and
right afterwards you `dput`. Then you ma
also sprach Bill Allombert <[EMAIL PROTECTED]> [2006.06.05.1446 +0200]:
> So, if the NMU is linked to a bug, use it, else create a fresh bug.
exactly. Ideally, write a bug before you start preparing the NMU,
and then try to fix it before the bug confirmation gets in. :)
--
Please do not send cop
On Mon, Jun 05, 2006 at 01:11:15AM +0200, martin f krafft wrote:
> also sprach Junichi Uekawa <[EMAIL PROTECTED]> [2006.06.05.0036 +0200]:
> > I don't think there is much harm in opening a new NMU bug.
>
> Isn't an NMU by definition bound to an existing bug? Or at least
> should be? So then I'd sa
Adeodato "=?utf-8?B?U2ltw7M=?=" <[EMAIL PROTECTED]> writes:
> Hi all,
>
> for those who don't know, nmudiff is a small script by Steinar H.
> Gunderson that, when invoked in the source tree of a NMU, will create a
> diff with respect the previous version, and send it to the BTS. I've
> found it qu
Scripsit Adeodato Simó <[EMAIL PROTECTED]>
> * Junichi Uekawa [Mon, 05 Jun 2006 07:36:43 +0900]:
>> I don't think there is much harm in opening a new NMU bug.
> No, there isn't. Plus has been the right way for years, AIUI, and
> dev-ref explicitly mentions it.
How is it righter than sending the
* Junichi Uekawa [Mon, 05 Jun 2006 07:36:43 +0900]:
> I don't think there is much harm in opening a new NMU bug.
No, there isn't. Plus has been the right way for years, AIUI, and
dev-ref explicitly mentions it.
> How about taking a command-line option so that it will add to the
> bugreport when
also sprach Junichi Uekawa <[EMAIL PROTECTED]> [2006.06.05.0036 +0200]:
> I don't think there is much harm in opening a new NMU bug.
Isn't an NMU by definition bound to an existing bug? Or at least
should be? So then I'd say that nmudiff should *never* open a new
bug.
--
Please do not send copie
Hi,
> By default, the current version of nmudiff opens a new bug against the
> package and attaches the diff to it. I recently submitted wishlist
> #370056 against devscripts so nmudiff behaves like this only if --new is
> passed, and by default sends the patch to the bugs the NMU fixes.
I don't
Adeodato Simó wrote:
> Hi all,
Hi
> for those who don't know, nmudiff is a small script by Steinar H.
> Gunderson that, when invoked in the source tree of a NMU, will create a
> diff with respect the previous version, and send it to the BTS. I've
> found it quite useful myself, and probably other
On Sun, Jun 04, 2006 at 05:23:33PM +0200, Adeodato Simó wrote:
> (And while I wait for answers, I'll go dream about the day when dak
> itself will send the diffs to the BTS, if ever.)
Actually, you can implement this outside dak, but I'd hesitate to do this
automatically. How would people feel abo
20 matches
Mail list logo
