On Mon, Oct 29, 2012 at 8:50 AM, Philip Ashmore wrote:
> While this feature allows gdb to know the correct source locations, using it
> implies that packages requiring the feature contain incorrect source paths -
> wouldn't it be better for these packages to contain correct source paths in
> the f
On 28/10/12 16:09, Wouter Verhelst wrote:
On Sun, Oct 28, 2012 at 08:03:25AM +, Philip Ashmore wrote:
Having the sources installed in /usr/src and referenced there rather
than /buildd would be an improvement too.
That's why there is the 'substitute-path' feature in gdb to fix that. Also se
Hi THere!
Just trying to avoid people wasting effort on bind9 NMU work.
I am working with LaMont Jones on an update for wheezy to bind9 9.8.4,
rebased on the ISC 9.8.4 code, which will definitely close #690569,
#690142, and may be #689755. (The rest of the Important bugs appear to
be with old ve
On Mon, 29 Oct 2012 03:07:16 Russ Allbery wrote:
> Andrew Starr-Bochicchio writes:
> > It's not that too many people are making mistakes. It's that too many
> > people don't take any action out of fear of making the mistake in the
> > first place. That's why we need a well defined process (or to a
On Mon, 29 Oct 2012 00:21:41 Thomas Goirand wrote:
> On 10/27/2012 04:47 AM, Dmitry Smirnov wrote:
> > For example if package is not maintained for years we can certainly wait
> > for a month or two before orphaning even though there may be no need to
> > wait that long.
>
> This unfortunately can
Hi folks,
sorry, I hadn't found time yet to let you know about the prospective
plans for beta 4. I also haven't found time to read most of the last ~
200 mails on -boot@ but baring regressions in beta 3 (privext handling
for netcfg/NM comes to mind, which got worked around already), I'm
tempted to
On Sat, Oct 27, 2012 at 11:36:15AM +0200, Lucas Nussbaum wrote:
> --->8
> 4. When/if consensus has been reached, or if no objections have been raised,
>the package can be orphaned by retitling and reassigning the ITO bug
>accordingly. Here are some example si
On Fri, Oct 26, 2012 at 06:24:24PM -0700, Steve Langasek wrote:
> > Similarly, Steve: can you comment on the criticism of "voting" on
> > packages, why don't you see it as a problem?
[…]
> *I am not proposing a new process*. This was the process that was
> used for *years* via debian-qa. But, ev
On Sun, Oct 28, 2012 at 12:07 PM, Russ Allbery wrote:
>>> If, as Bart has found, such mistakes are quite rare, then why worry so
>>> much? We don't need new formal processes for rarely occurring social
>>> problems. We need more people willing to help those that make social
>>> mistakes to learn
On Fri, Oct 26, 2012 at 12:37:38PM +0200, Niels Thykier wrote:
> ax25-apps, fabric, firmware-crystalhd, icewm-themes, ilisp, inguma,
> lustre, mingw-ocaml, noflushd, openvas-plugins-dfsg, php-crypt-gpg,
> phpgacl, python-django-piston, smbind, sorl-thumbnail, spatialite-gui,
> sugar-chat-activity-0
On Sun, Oct 28, 2012 at 02:40:53PM +0100, Arno Töll wrote:
> Yes, I know it still lacks code name aliases, but that's something we
> are aware of. Also, the user prompting interface is not very clean yet :)
Please make sure that it can be overridden on the commandline, thanks.
Kind regards
Philip
On Sun, Oct 28, 2012 at 12:25 PM, Wouter Verhelst wrote:
> If not, why are you claiming to replace their code? It's fine to be
> writing "something else" to replace older code; but it's fairly rude to
> be claiming that whatever you're writing is the "next generation" of
> that older code
Any rewr
On Sun, Oct 28, 2012 at 05:25:20PM +0100, Wouter Verhelst wrote:
> On Sun, Oct 28, 2012 at 11:15:47AM +0100, Arno Töll wrote:
> > Hi,
> >
> > On 28.10.2012 08:03, Philipp Kern wrote:
> > > I'd prefer if such a tool could replace an existing one. Why not aim at
> > > replacing dput if there's a rea
* Ben Hutchings [121028 17:02]:
> There are plenty of bugs that involve 'undefined behaviour' that in
> practice depends on whether optimisation is enabled. Unless you have a
> good idea what's going wrong, how do you know that 'noopt' won't hide
> the bug?
If the bug still shows up with the lib
On Sun, Oct 28, 2012 at 11:15:47AM +0100, Arno Töll wrote:
> Hi,
>
> On 28.10.2012 08:03, Philipp Kern wrote:
> > I'd prefer if such a tool could replace an existing one. Why not aim at
> > replacing dput if there's a reason for it?
>
> As for us, we'd welcome that. However, that's primarily left
On Sun, Oct 28, 2012 at 08:03:25AM +, Philip Ashmore wrote:
> Having the sources installed in /usr/src and referenced there rather
> than /buildd would be an improvement too.
That's why there is the 'substitute-path' feature in gdb to fix that. Also see
http://grep.be/blog/en/computer/code/gdb
Andrew Starr-Bochicchio writes:
> Michael Gilbert wrote:
>> If, as Bart has found, such mistakes are quite rare, then why worry so
>> much? We don't need new formal processes for rarely occurring social
>> problems. We need more people willing to help those that make social
>> mistakes to lear
On Sun, 2012-10-28 at 11:35 +0100, Bernhard R. Link wrote:
> * Philip Ashmore [121028 09:12]:
> > Yeah, in (cough)Fedora, kdbg even offers to download and install
> > debug packages for you.
> > Debug packages also make back-traces more than useless, and
> > (cough)Ubuntu offers to download debug
On Sun, Oct 28, 2012 at 12:19 AM, Michael Gilbert wrote:
> On Sat, Oct 27, 2012 at 8:51 PM, Charles Plessy wrote:
>>> maybe we could simply allow anyone, including non-DDs, to submit O-bugs for
>>> packages which seem abandoned by the maintainer, and to submit ITA-bugs for
>>> packages he/she wish
Hi,
On 28.10.2012 14:15, Adam D. Barratt wrote:
> On 28.10.2012 13:06, Arno Töll wrote:
>> On 28.10.2012 13:57, Florian Weimer wrote:
>>> Does it prevent uploading security updates to the main archive by
>>> default?
>>
>> Adam, with his Release Team hat on, suggested us to prevent this for
>> t-p
On 10/27/2012 04:47 AM, Dmitry Smirnov wrote:
For example if package is not maintained for years we can certainly wait for a
month or two before orphaning even though there may be no need to wait that
long.
This unfortunately cannot be set as a rule. Sometimes, a package that was
left unmaintain
On 28.10.2012 13:06, Arno Töll wrote:
On 28.10.2012 13:57, Florian Weimer wrote:
Does it prevent uploading security updates to the main archive by
default?
Adam, with his Release Team hat on, suggested us to prevent this for
t-p-u likewise.
I think it was p-u, but more as a grumble about an
Hi,
On 28.10.2012 13:57, Florian Weimer wrote:
> Does it prevent uploading security updates to the main archive by
> default?
Adam, with his Release Team hat on, suggested us to prevent this for
t-p-u likewise. We have the infrastructure and possibilities to
implement a check like this, and it is
* Arno Töll:
> dput-ng features many enhancements over dput, such as more
> comprehensive checks, an easy to use plugin system, and code
> designed to handle the numerous archives that any Debian package
> hacker will interact with.
Does it prevent uploading security updates to the main archive b
On 28.10.2012 07:17, Osamu Aoki wrote:
Policy states "In addition, the packages in main must not require or
recommend a package outside of main for compilation or execution
(thus,
the package must not declare a "Pre-Depends", "Depends",
"Recommends",
"Build-Depends", or "Build-Depends-Indep" r
* Philip Ashmore [121028 09:12]:
> Yeah, in (cough)Fedora, kdbg even offers to download and install
> debug packages for you.
> Debug packages also make back-traces more than useless, and
> (cough)Ubuntu offers to download debug packages which it installs
> and re-examines the back-trace to see if
Hi,
On 28.10.2012 08:03, Philipp Kern wrote:
> I'd prefer if such a tool could replace an existing one. Why not aim at
> replacing dput if there's a reason for it?
As for us, we'd welcome that. However, that's primarily left to the
current dput maintainer and his interest in that. Also note, we k
Paul Wise, le Sun 28 Oct 2012 11:34:33 +0800, a écrit :
> On Sat, Oct 27, 2012 at 6:39 PM, Samuel Thibault wrote:
> > When somebody implements it.
>
> Someone already did:
>
> ftp://ftp.debian.org/debian/tools/win32-loader/unstable/win32-loader.txt
Wubi is not only about installing from windows,
Philip Ashmore writes:
> Debug packages also make back-traces more than useless, and
They also allow systemtap to probe userland binaries once
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691167 is fixed.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "
On 27/10/12 19:30, Michael Biebl wrote:
On 27.10.2012 12:25, Vincent Bernat wrote:
Hi!
Libraries with `-dbg` package are a pain to deal with when debugging
some problem. The solution to ask each user to rebuild the library
without stripping debug symbols[1] seem suboptimal. Asking each
maintain
Hi,
I am a bit confused on discrepancy between policy and "Release Critical
Issues for Wheezy".
http://www.debian.org/doc/debian-policy/ch-archive.html#s-main
http://release.debian.org/wheezy/rc_policy.txt
Is this discrepancy of requirements for main on "Recommends:" intended
one or some ty
Quoting Lucas Nussbaum (lu...@lucas-nussbaum.net):
> I think I agree with everybody, so here is a new version of the last step of
> the proposed procedure:
I read the "huge thread" quickly during last days and I think your
text well summarizes what seems to be the best consensus.
That's great w
I'd prefer if such a tool could replace an existing one. Why not aim at
replacing dput if there's a reason for it?
signature.asc
Description: Digital signature
33 matches
Mail list logo
