Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool

[Philipp Kern]

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

Re: [PROPOSAL v2] Orphaning another maintainer's packages

[Christian PERRIER]

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 work, Lucas, much appreciated and it had to be said..:-)




signature.asc
Description: Digital signature

discrepancy: rc_policy.txt and policy

[Osamu Aoki]

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 typo.

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" relationship on a non-main
package)," ..."

On the other hand rc_policy.txt states " Packages in main cannot require
any software outside of main for execution or compilation.
"Recommends:" lines do not count as requirements. ..."

rc_policy.txt is a bit confusing since it talks about source dependency and
comments on binary dependency w.r.t. "Recommends:" which seems to contradict
with policy.  (Am I wrong?  Was there any reasons?)

At least, discrepancy from policy can be fixed with the following:

--- rc_policy.txt.orig  2012-10-28 13:59:02.194465621 +0900
+++ rc_policy.txt   2012-10-28 13:59:31.764751376 +0900
@@ -52,7 +52,7 @@

Packages in main cannot require any software outside of main
for execution or compilation.
-   "Recommends:" lines do not count as requirements.
+   "Suggests:" lines do not count as requirements.

Packages must include a "Depends:" line listing any other
packages they require for operation, unless those packages are





-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121028071702.GA27770@goofy.localdomain

Re: Mandatory -dbg packages

[Philip Ashmore]

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
maintainer to ship a `-dbg` package may be a solution[2] but couldn't we
generate those packages automatically by the builders, like this is done
with Ubuntu[3]?

I remember we had a discussion about this a few years ago. An automatic
service has been setup for this[4] by myon but it does not seem to be
updated anymore.

Why does this experiment have been stopped? Could we mainstream it?



Afaik the work was started by pochu as port of GSoC [1][2]. According to
[3], Marc was his mentor. I've CCed both, maybe they can comment on
what's still missing.
I'd love to see that happen.
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 more are needed.
Having the sources installed in /usr/src and referenced there rather 
than /buildd would be an improvement too.


If there's a way to re-path debug information from /home/user/x or 
/buildd to /usr/src then that would be great.


One less reason for Debians build process to need a fake root.

Michael


[1] http://wiki.debian.org/EmilioPozueloMonfort/GSoC2009Ddebs
[2] http://wiki.debian.org/AutomaticDebugPackages
[3]
http://wiki.debian.org/SummerOfCode2009#Automatic_Debug_Packages_Creation_and_Handling

Philip


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/508ce6cd.4000...@philipashmore.com

Re: Mandatory -dbg packages

[Timo Juhani Lindfors]

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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/84ehkjt2vm@sauna.l.org

Re: suggestion

[Samuel Thibault]

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, but also installing *in*
windows, without repartitioning.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20121028093405.gs5...@type.wlan.youpi.perso.aquilenet.fr

Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool

[Arno Töll]

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 keep
some backward compatibility but we are not entirely backwards compatible
(but only a few users with edge case configurations should notice this).

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: Mandatory -dbg packages

[Bernhard R. Link]

* 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 more are needed.

While having some way to get the stripped debug info from the installed
packages is nice to more easily get some debug information or to
retroactively make a backtrace a bit more verbose, it is still not
enough for all cases of debugging. Ideal debugging information you get
by locally rebuilding the needed libraries with
DEB_BUILD_OPTIONS="noopt nostrip" and installing those.
(Sadly not all libraries support noopt, but it's getting much better as a
side effect of the current hardening effords).

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121028103552.ga3...@client.brlink.eu

Re: discrepancy: rc_policy.txt and policy

[Adam D. Barratt]

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" relationship on a non-main
package)," ..."

On the other hand rc_policy.txt states " Packages in main cannot 
require

any software outside of main for execution or compilation.
"Recommends:" lines do not count as requirements. ..."


That text has been there for several releases. We should possibly 
revisit it and decide whether to bring it more in line with the Policy 
wording, but I don't think that during a freeze is really the 
appropriate time to do so.


rc_policy.txt is a bit confusing since it talks about source 
dependency and
comments on binary dependency w.r.t. "Recommends:" which seems to 
contradict

with policy.  (Am I wrong?  Was there any reasons?)


The text indeed refers to both source and binary dependencies, as does 
the Policy text you quoted - "compilation" is source, "execution" is 
binary.



At least, discrepancy from policy can be fixed with the following:

--- rc_policy.txt.orig  2012-10-28 13:59:02.194465621 +0900
+++ rc_policy.txt   2012-10-28 13:59:31.764751376 +0900
@@ -52,7 +52,7 @@

Packages in main cannot require any software outside of main
for execution or compilation.
-   "Recommends:" lines do not count as requirements.
+   "Suggests:" lines do not count as requirements.


As above, it's too late in the release cycle to be significantly 
changing what we consider to be RC for wheezy.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/bca7234f03a10a293049c6402737d...@mail.adsl.funky-badger.org

Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool

[Florian Weimer]

* 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 by
default?


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehkiiwjh@mid.deneb.enyo.de

Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool

[Arno Töll]

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 reasonably trivial to implement.

For the time being we do not prevent this, but it is on our TODO already
and the first version we upload to Debian will most likely feature such
a check.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool

[Adam D. Barratt]

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 uncoordinated upload 
than necessarily an actual feature request. :-)


Cheers,

Adam


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/3b9ec2eaa4e63f654b76f849b1415...@mail.adsl.funky-badger.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - delay for maintainer to react

[Thomas Goirand]

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 unmaintained for a long time becomes a piece of something else,
maybe because it's a dependency of a new package, and needs to be
taken care of, and that's exactly when you will want to have a quick
adoption of the package, in order to not waste some maintainer / DD
time and/or delaying the achievement/upload of a project/package.

On 10/27/2012 04:47 AM, Dmitry Smirnov wrote:

Michael Gilbert's proposal to start salvaging with NMUs makes more sense as it
allows to proceed gently and demonstrate motivation and willingness to work on
the package. From non-DD prospective couple of successful NMUs will confirm
salvaging intent and capacity better than random ACKs.

I also think it would be a good thing if there was some kind of work
showing the intent of the adopter, on top of the ACK. This could be
in the form of a patch sent to the BTS, or some NMU. But I don't
think this should be a hard requirement. I agree with others saying
that we should trust that DDs will do the right thing.

Cheers,

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/508d3165.5020...@debian.org

Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool

[Arno Töll]

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-u likewise.
> 
> I think it was p-u, but more as a grumble about an uncoordinated upload
> than necessarily an actual feature request. :-)

I implemented it nonetheless in [1] :>

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 :)

[1]
http://anonscm.debian.org/gitweb/?p=collab-maint/dputng.git;a=commitdiff;h=ae1121c8f0f872376689fe81ec49194d4bb35ae0
-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: [PROPOSAL v2] Orphaning another maintainer's packages

[Andrew Starr-Bochicchio]

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 wishes to salvage.
>>
>> I think that this misses one of the reasons for the original proposal, which 
>> is
>> to provide guidelines to the contributors who refrain from orphaning packages
>> because they are not sure how to appreciate whether packages "seem 
>> abandonned".
>>
>> Everybody who are confident in what they are doing can orphan anything any
>> time.  And they are fully responsible for their mistakes.  The guidelines 
>> that
>> are proposed to be added in the Developers reference are a formal process,
>> which purpose is to help the orphaners to strongly reduce the chances that 
>> they
>> make a mistake.
>
> 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 and improve themselves.

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 at least
codify the status quo more clearly).

-- Andrew Starr-Bochicchio

   Soon to be a...@debian.org Just waiting on account creation!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cal6k_axvhbxxe-w3_0zwjpx3pvn3yfvufbzasw8xrhieyot...@mail.gmail.com

Re: Mandatory -dbg packages

[Ben Hutchings]

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 packages which it installs
> > and re-examines the back-trace to see if more are needed.
> 
> While having some way to get the stripped debug info from the installed
> packages is nice to more easily get some debug information or to
> retroactively make a backtrace a bit more verbose, it is still not
> enough for all cases of debugging. Ideal debugging information you get
> by locally rebuilding the needed libraries with
> DEB_BUILD_OPTIONS="noopt nostrip" and installing those.
> (Sadly not all libraries support noopt, but it's getting much better as a
> side effect of the current hardening effords).

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?  Also, gdb and the GNU toolchain have recently got a lot better
at handling highly optimised code (tracking variables in registers,
treating inlined functions as logically separate functions, etc.).

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.


signature.asc
Description: This is a digitally signed message part

Re: [PROPOSAL v2] Orphaning another maintainer's packages

[Russ Allbery]

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 learn and improve themselves.

> 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 at least
> codify the status quo more clearly).

Yes, exactly.

I don't want to be trusted to orphan packages on my own, and I've been a
DD for years.  It's too much pressure!  And as a result, I basically never
do it.  One of the huge advantages of somewhat more formal systems is that
they remove the feeling of personal responsibility and provide some sort
of system that can deal with issues, which can make the whole thing feel
much more comfortable for everyone involved.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcduh96z@windlord.stanford.edu

Re: Mandatory -dbg packages

[Wouter Verhelst]

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_substitute_path

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121028160936.gf23...@grep.be

Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool

[Wouter Verhelst]

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 to the
> current dput maintainer and his interest in that.

Have you talked to the dput maintainer?

If so, what were their answers?

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, unless you're either the actual maintainer of said
code, or the actual maintainer gave their assent. Calling something
"next generation" implies that the older code is suddenly outdated or no
longer useful or something similar; that may be your opinion, but that
isn't necessarily true.

So if you don't have the original maintainer's agreement to call this
the "next generation" of their code, please be a bit more creative and
give it a different name. After all, that was also what the "dput"
maintainers did when they rewrote "dupload".

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


signature.asc
Description: Digital signature

Re: Mandatory -dbg packages

[Bernhard R. Link]

* 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 library recompiled with 'noopt', then
no harm done. If it is a bug in the library, you want to look there
anyway (and you will most likely want to compile different parts of it
with or without optimisation or any other technique; in any case you
will want more of the library than just the binary and some debugging
symbols of it). The only case where a noopt library variant is a
disadvantage is a very ugly case of heisenbug, that is hidden by the
slightly changed library.

> Also, gdb and the GNU toolchain have recently got a lot better
> at handling highly optimised code (tracking variables in registers,
> treating inlined functions as logically separate functions, etc.).

Yeah, they got a lot better. But even if gdb got perfect in that regard
it can still not show what isn't there (like the value of a variable
(or function argument passed as register) no longer stored anywhere.

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121028163707.ga19...@client.brlink.eu

Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool

[Paul Tagliamonte]

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 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.
> 
> Have you talked to the dput maintainer?

No.

> 
> So if you don't have the original maintainer's agreement to call this
> the "next generation" of their code, please be a bit more creative and
> give it a different name. After all, that was also what the "dput"
> maintainers did when they rewrote "dupload".

It maintains the same interface and is backwards compatible. The change
between dput and dupload was big enough where they were totally
different ways of solving the problem.

We support old arguments, and will make it a point to make sure old
setups are still compatable.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool

[Michael Gilbert]

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 rewrite will be a "next generation" of the previous thing.  I
don't see the harm in calling things what they actually are.

There were probably some hurt feelings on the Star Trek staff when
Star Trek: TNG came around, but that's not sufficient justification to
stop the writers of that show from calling it what they wanted to call
it.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MPaaQDm03PocWUYaQ9CkFv17X0=q=v5aEeqimJ7=th...@mail.gmail.com

Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool

[Philipp Kern]

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
Philipp Kern


signature.asc
Description: Digital signature

Re: Candidates for removal from testing (results)

[Stefano Zacchiroli]

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.86, sugar-log-activity-0.86, sugar-moon-activity,
> twidge, venkman
> 
> The removed packages accounted for about 4.4% of all RC bugs left in
> testing[0].

Thanks a lot, Neil! Is that something that you plan to automate further
(at least the "warning" mails, I understand you probably want to further
inspect the individual removals), and/or run on a fixed cadence?

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: [PROPOSAL v2] Orphaning another maintainer's packages

[Michael Gilbert]

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 and improve themselves.
>
>> 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 at least
>> codify the status quo more clearly).
>
> Yes, exactly.
>
> I don't want to be trusted to orphan packages on my own, and I've been a
> DD for years.  It's too much pressure!  And as a result, I basically never
> do it.  One of the huge advantages of somewhat more formal systems is that
> they remove the feeling of personal responsibility and provide some sort
> of system that can deal with issues, which can make the whole thing feel
> much more comfortable for everyone involved.

I think everyone is in agreement on that defined rules are bound to
improve the situation.  The question (at least with respect to
non-maintainer orphaning) is, do we codify the tried and true bug
report + wait 4*7*24*3600 system, or do we take a gamble with one of
the new untested bureaucratic ones?

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MOJNWTDUwaQ1B=ZwCc_diJEN8GqcfLydv-B8=mu+3a...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

[Stefano Zacchiroli]

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, evidently because this process
> was never adequately codified in the developer's reference

Hi Steve, thanks for your detailed reply. I'm in agreement with
basically [1] all you wrote.

In fact, I've remained subscribed to -qa all those years, after my
active hacking on the QA infrastructure, because I wanted to follow
orphaning and similar discussions there. Unfortunately, if my memory
serves me well, the "mail -qa" process has grown more and more underused
in recent years. Also, some recent "high profile" cases have often
debated on -devel, partly increasing the "drama" around 3rd party
orphaning. That, combined with the fact that the process you remember
was "written" only in folklore, has probably made it unknown to most and
hardly discoverable by new developers.

No matter the actual letter of the process, we could all probably learn
from this experience that there is a lot of value in documenting
processes, even when they're supposed to be known in folklore. In Debian
we are not particularly good at doing that and we often end up paying
the price of it.

Cheers.

[1] I think at this point our judgement differs only on the matter of
the minimum number of "ACKs", if any. My motive is that I like sane
defaults where responsible individuals _alone_ are empowered to act.
I'm fine with safeguards when the action is potentially risky, but
I'm weary of safeguards that block individuals to act forever if
everyone else in the world happen to be busy.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: [PROPOSAL v2] Orphaning another maintainer's packages

[Stefano Zacchiroli]

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 situations where it is considered
>acceptable to move forward:
> - one month has passed since the ITO bug was submitted, and nobody
>   objected to the orphaning;
> - one week has passed since the ITO bug was submitted, and at least
>   3 DDs supported the orphaning (possibly including the submitter
>   of the ITO bug, if it was a DD), while nobody objected.
> --->8
> 
> For completeness, here is the full proposal. I've also addressed a few
> cosmetic comments.

Hi Lucas, thanks a lot for this updated draft. I think is good and I'm
generally supportive of it.

A remaining concern of mine, however, is the second case. One week
really seems too short.

I understand that 3 DDs supporting the orphaning should give a good
safeguard against hostile takeovers. But I don't see the need for such a
short timeframe: if there's urgency, the interested DDs can use NMUs.
And on the other hand I do feel the risk of maintainers coming back from
VAC and finding packages where they've invested a lot of efforts
orphaned, maybe because a group of DDs working closely together ended up
sharing a (wrong) view on the maintainer intentions. That has a very
negative social potential and I think we should try hard to avoid it.

I propose to go for 15 days before proceeding in presence of ACKs.

It matches the longest DELAYED/XX period we currently have. For that
reason it seems to be culturally associated with a "long" delay we give
to people to react.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Towards d-i wheezy beta 4

[Cyril Brulebois]

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 release a beta 4 as soon as src:linux hits testing.

If you want to see packages migrate from sid to testing before that,
please speak up. I'm tempted to keep everything l10n-ish for release
candidates (beta 4 might be the last beta).

Release team: please ping me before unblocking packages.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - delay for maintainer to react

[Dmitry Smirnov]

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 cannot be set as a rule. 

That's fine, recommendation would be good enough. 

On Mon, 29 Oct 2012 00:21:41 Thomas Goirand wrote:
> Sometimes, a package that was
> left unmaintained for a long time becomes a piece of something else,
> maybe because it's a dependency of a new package, and needs to be
> taken care of, and that's exactly when you will want to have a quick
> adoption of the package, in order to not waste some maintainer / DD
> time and/or delaying the achievement/upload of a project/package.

Of course, but it looks like we've lost a bit of context.
I was talking about orphaning-only while what you're saying is about 
adoption/salvaging/co-maintainership.


On Mon, 29 Oct 2012 00:21:41 Thomas Goirand wrote:
> I also think it would be a good thing if there was some kind of work
> showing the intent of the adopter, on top of the ACK. This could be
> in the form of a patch sent to the BTS, or some NMU. But I don't
> think this should be a hard requirement. I agree with others saying
> that we should trust that DDs will do the right thing.

Indeed it don't have to be just NMU -- any form of contribution will do.

Regards,
Dmitry.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201210290904.04784.only...@member.fsf.org

Re: [PROPOSAL v2] Orphaning another maintainer's packages

[Dmitry Smirnov]

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 at least
> > codify the status quo more clearly).
> 
> Yes, exactly.
> 
> I don't want to be trusted to orphan packages on my own, and I've been a
> DD for years.  It's too much pressure!  And as a result, I basically never
> do it.

Perhaps your experience may confirm my observation: Except for orphaning as 
part of MIA procedure I can't recall situation when a particular package was 
orphaned by non-maintainer. 
It looks like such cases are extremely rare so as result prospective 
contributors are often reluctant to invest much time into improvement of de-
facto unmaintained but not orphaned package.


> One of the huge advantages of somewhat more formal systems is that
> they remove the feeling of personal responsibility and provide some sort
> of system that can deal with issues, which can make the whole thing feel
> much more comfortable for everyone involved.

Absolutely.
Even a bit of guidelines will do very well.
For example at the moment it is not obvious that adoption can begin with ITA 
bug to the package but this little hint can save time and improve visibility 
of adoption comparing to private email to maintainer if it remains unanswered.

Regards,
Dmitry.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201210290958.21858.only...@member.fsf.org

Re: Bug#690142: marked as done (remote named DoS on recursor (CVE-2012-5166))

[Matthew Grant]

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 versions of bind9 before 9.7.x.)

The main reason is to reduce the work required for security patching and
to mostly eliminate the risk of introducing new bugs with the fixes.

It has been found that the data structures between ISC bind9 9.8.1 and
9.8.4 have markedly changed due to essential protocol fixes and security
fixes.  Applying patches is no longer that simple a matter, with a
considerable risk of introducing new bugs.

I originally adapted up the patch for bind9 9.8.1.dfsg.P1-4.2 , and was
proceeding to fix  #690569 "DNS wildcards fail to resolve with DNSsec
enabled" when I found that there was a serious risk of introducing new
new bugs, and desisted from NMUing bind9. (I was a professional C router
programmer)

There is also the matter of "#689755 bind9: memory leak in named".  I am
currently working on an ISP DNS project based on wheezy, and have
observed some suspicious behaviour in this regard.  On reading the ISC
CHANGES file for 9.8.4, there are fixes that could be related to this
sort of behavior.

This is a notice that the bind9 9.8.1.dfsg.P1-4.x package might be
replaced, after going through the appropriate channels (Debian Release
Team). LaMont will be uploading our work to wheezy-proposed shortly.

A repository of work done so far is up at
http://anonscm.debian.org/git/collab-maint/bind9.git/

Thank you very much for your patience.

Best Regards,

Matthew Grant

On 29/10/12 11:21, Debian Bug Tracking System wrote:
> Your message dated Sun, 28 Oct 2012 23:16:32 +0100
> with message-id <20121028221632.ga21...@spike.0x539.de>
> and subject line fixed in 9.8.1.dfsg.P1-4.3
> has caused the Debian Bug report #690142,
> regarding remote named DoS on recursor (CVE-2012-5166)
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: Mandatory -dbg packages

[Philip Ashmore]

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 see
http://grep.be/blog/en/computer/code/gdb_substitute_path
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 first place?


Regards,
Philip


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/508dd2c3.9090...@philipashmore.com

Re: Mandatory -dbg packages

[Paul Wise]

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 first place?

There is no such thing as a "correct source path", I unpack source
tarballs to ~/tmp/ when debugging, you seem to use /usr/src/ and John
Doe uses ~/src/debian/pool/f/foo/foo-0.1/.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6FyXaEmW2uPvzyn2=3qhn_avregh8w0bkn89zogiot...@mail.gmail.com