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

[Bart Martens]

On Thu, Nov 01, 2012 at 07:10:06PM -0400, Michael Gilbert wrote:
> On Thu, Nov 1, 2012 at 6:59 PM, Bart Martens wrote:
> > On Thu, Nov 01, 2012 at 06:41:24PM -0400, Michael Gilbert wrote:
> >> Maybe an example will help get us on the same page.  Russ seems to
> >> have the impression that my proposal is somehow a license to push
> >> unwanted changes at a maintainer.  That is not true.
> >>
> >> Let's consider mlocate as a hypothetical:
> >>
> >> - The contributor wants a new upstream for better hurd support
> >> - He prepares an nmu of that new upstream (making sure to not modify
> >> the maintainer's build setup and packaging style)
> >> - He convinces a DD that this is worthwhile to sponsor, and that DD
> >> decides that he is willing to take the social risk involved if
> >> something goes wrong
> >> - The DD uploads the package to DELAYED/ >> enough> and sends an nmudiff to the mlocate bts
> >> - The maintainer gets the mail, cancels the upload, and says to the
> >> contributor "for me hurd support is not enough to take the risk of a
> >> new upstream upload"
> >> - In this case, the contributor would probably say ok that's fine, and
> >> not push it further
> >> - But if he really thought it was that important, he would take it to
> >> the Tech Committee, and in this case, the committee would most likely
> >> side with the maintainer's opinion
> >
> > In this scenario the contributor should have talked to the maintainer before
> > requesting a sponsor.
> 
> This would be something that his potential DD sponsors would have
> taken into consideration before agree to a sponsorship.

Well OK, then the contributor should have talked to the maintainer before
requesting a sponsor, and the sponsor should have verified that before
uploading.

> So, yes, I've
> taken a bit of liberty in terms of assuming that a DD could be
> convinced that mlocate was in a state where this needs to happen when
> clearly its not.
> 
> Since this is a hypothetical, I'm free to set constraints, so please
> assume mlocate were in a worse state than it really is above.

I commented on the the described scenario, not on mlocate.  But also for
mlocate, I don't see any bug "NMU intent" in the bts, and Svante Signell has
confirmed that bug 669368 was not an NMU intent.
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mlocate

I'm not sure how all this would fit in the debate on Lucas' proposal about
orphaning.  I guess that mlocate is not the perfect example to evaluate Lucas'
proposal with.

Regards,

Bart Martens


-- 
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/20121102082426.ga...@master.debian.org

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

[Bart Martens]

On Thu, Nov 01, 2012 at 01:58:28PM -0400, Michael Gilbert wrote:
> On Thu, Nov 1, 2012 at 4:48 AM, Bart Martens wrote:
> >> wine: http://bugs.debian.org/585409 (new upstream pushed via nmu)
> >
> > This is a good example where talking helped to gather all views on all 
> > aspects
> > from all involved people.  My impression is that finally the maintainer 
> > allowed
> > new co-maintainers doing things differently.  That does not really match 
> > Lucas'
> > proposal which is about marking packages as orphaned so that they can be 
> > taken
> > over by a new maintainer.
> 
> It matches my proposal where interested contributors apply nmus as
> needed to improve the situation, then eventually become uploaders.

I didn't say that the series of NMUs should be used as a model for a new
procedure in dev-ref.  I said that my impression is that finally the maintainer
allowed new co-maintainers doing things differently.

I understand that you meant to bring attention back to your proposal, so I
looked it up here:
http://lists.debian.org/debian-devel/2012/10/msg00524.html

I already briefly commented on it here:
http://lists.debian.org/debian-devel/2012/10/msg00562.html

Other than that, I cannot support your proposal, because I really think that
when a maintainer is not maintaining a package anymore that new contributors
should get full package (co-)maintainership from the start, with consent from
the (previous) maintainer or from the TC or after orphaning.  Lucas' proposal
currently only addresses how the package could be orphaned.  An NMU is meant as
an occasional help, not as a step in taking over maintenance.  I agree however
that a series of NMUs is often one of the signs that the maintainer is not
maintaining the package anymore.

> 
> >> python2.6: http://bugs.debian.org/679030 (new upstream pushed via nmu)
> >
> > This does not seem to be an example of "the maintainer refuses to package 
> > any
> > newer upstream".  This seems to be just an NMU, not related to Lucas' 
> > proposal.
> 
> As we were getting close to the freeze, python2.6 was in a poor
> situation where it was going to ship with 2.6.7 in wheezy, and thus
> lack a whole bunch of security updates.  Julien Cristau made the
> decision that this would be unacceptable, and prepared a new upstream
> nmu resolving the inactivity.
> 
> This is certainly a case of a maintainer acting in an unproductive
> manner.  The previous 2.6.7 upload was made almost an entire year
> prior to that.

I don't see "a maintainer acting in an unproductive manner" but rather "a
package that got temporarily less attention so occasional help from others via
NMU was helpful".  Now that I look at this example again I see Julien Cristau's
upload as a one-time co-maintenance contribution with an NMU version.
According to the changelog the newer upstream release was already prepared by
the maintainer.
http://packages.qa.debian.org/p/python2.6/news/20120624T103440Z.html
So again, this does not seem to be an example of "the maintainer refuses to
package any newer upstream".  This seems to be just an NMU, not related to
Lucas' proposal about orphaning packages.

Regards,

Bart Martens


-- 
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/20121102095055.gb...@master.debian.org

Bug#637232: [patch] provide a libc6-dev-compat package

[Matthias Klose]

this is a patch I'm proposing to apply to the Ubuntu eglibc builds for precise, 
quantal and raring.


 - it adds symlinks for .a, .so and .o files
 - adds a symlink for the asm header dir
 - depends on the libc-dev- packages, which provide
   more needed header files/symlinks in /usr/include.

Matthias

diff -Nru eglibc-2.16/debian/changelog eglibc-2.16/debian/changelog
--- eglibc-2.16/debian/changelog	2012-10-28 00:24:42.0 +0200
+++ eglibc-2.16/debian/changelog	2012-11-02 10:57:32.0 +0100
@@ -1,3 +1,9 @@
+eglibc (2.16-0ubuntu4) raring; urgency=low
+
+  * Build a libc-compat-dev package. Closes: #637232.
+
+ -- Matthias Klose   Thu, 01 Nov 2012 18:16:32 +0200
+
 eglibc (2.16-0ubuntu3) raring; urgency=low
 
   * Regenerate the control file.
diff -Nru eglibc-2.16/debian/control eglibc-2.16/debian/control
--- eglibc-2.16/debian/control	2012-10-28 00:23:38.0 +0200
+++ eglibc-2.16/debian/control	2012-11-02 10:40:56.0 +0100
@@ -175,6 +175,17 @@
  Contains the symlinks, headers, and object files needed to compile
  and link programs which use the standard C library.
 
+Package: libc6-dev-compat
+Architecture: amd64 arm arm64 armel armhf hppa i386 m68k mips mipsel powerpc powerpcspe ppc64 sparc sparc64 s390 s390x sh4 x32
+Section: libdevel
+Priority: extra
+Depends: libc6-dev (= ${binary:Version}), ${multilibdev}
+Provides: libc-dev-compat
+Conflicts: libc6-dev (<< 2.13-0ubuntu7)
+Description: Embedded GNU C Library: Non-Multiarch compatibility symlinks
+ Contains the symlinks for headers, libraries and object files in
+ non-multiarch locations.
+
 Package: libc6-dbg
 Architecture: amd64 arm arm64 armel armhf hppa i386 m68k mips mipsel powerpc powerpcspe ppc64 sparc sparc64 s390 s390x sh4 x32
 Section: debug
@@ -265,6 +276,17 @@
  Contains the symlinks, headers, and object files needed to compile
  and link programs which use the standard C library.
 
+Package: libc6.1-dev-compat
+Architecture: alpha ia64
+Section: libdevel
+Priority: extra
+Depends: libc6.1-dev (= ${binary:Version}), ${multilibdev}
+Provides: libc-dev-compat
+Conflicts: libc6.1-dev (<< 2.13-0ubuntu7)
+Description: Embedded GNU C Library: Non-Multiarch compatibility symlinks
+ Contains the symlinks for headers, libraries and object files in
+ non-multiarch locations.
+
 Package: libc6.1-dbg
 Architecture: alpha ia64
 Section: debug
@@ -355,6 +377,17 @@
  Contains the symlinks, headers, and object files needed to compile
  and link programs which use the standard C library.
 
+Package: libc0.3-dev-compat
+Architecture: hurd-i386
+Section: libdevel
+Priority: extra
+Depends: libc0.3-dev (= ${binary:Version}), ${multilibdev}
+Provides: libc-dev-compat
+Conflicts: libc0.3-dev (<< 2.13-0ubuntu7)
+Description: Embedded GNU C Library: Non-Multiarch compatibility symlinks
+ Contains the symlinks for headers, libraries and object files in
+ non-multiarch locations.
+
 Package: libc0.3-dbg
 Architecture: hurd-i386
 Section: debug
@@ -445,6 +478,17 @@
  Contains the symlinks, headers, and object files needed to compile
  and link programs which use the standard C library.
 
+Package: libc0.1-dev-compat
+Architecture: kfreebsd-amd64 kfreebsd-i386
+Section: libdevel
+Priority: extra
+Depends: libc0.1-dev (= ${binary:Version}), ${multilibdev}
+Provides: libc-dev-compat
+Conflicts: libc0.1-dev (<< 2.13-0ubuntu7)
+Description: Embedded GNU C Library: Non-Multiarch compatibility symlinks
+ Contains the symlinks for headers, libraries and object files in
+ non-multiarch locations.
+
 Package: libc0.1-dbg
 Architecture: kfreebsd-amd64 kfreebsd-i386
 Section: debug
diff -Nru eglibc-2.16/debian/control.in/libc eglibc-2.16/debian/control.in/libc
--- eglibc-2.16/debian/control.in/libc	2012-10-26 17:50:39.0 +0200
+++ eglibc-2.16/debian/control.in/libc	2012-11-02 10:16:38.0 +0100
@@ -39,6 +39,17 @@
  Contains the symlinks, headers, and object files needed to compile
  and link programs which use the standard C library.
 
+Package: @libc@-dev-compat
+Architecture: @archs@
+Section: libdevel
+Priority: extra
+Depends: @libc@-dev (= ${binary:Version}), ${multilibdev}
+Provides: libc-dev-compat
+Conflicts: @libc@-dev (<< 2.13-0ubuntu7)
+Description: Embedded GNU C Library: Non-Multiarch compatibility symlinks
+ Contains the symlinks for headers, libraries and object files in
+ non-multiarch locations.
+
 Package: @libc@-dbg
 Architecture: @archs@
 Section: debug
diff -Nru eglibc-2.16/debian/rules eglibc-2.16/debian/rules
--- eglibc-2.16/debian/rules	2012-10-26 12:47:57.0 +0200
+++ eglibc-2.16/debian/rules	2012-11-02 09:35:16.0 +0100
@@ -143,7 +143,7 @@
   DEB_INDEP_REGULAR_PACKAGES = 
   DEB_UDEB_PACKAGES = 
 else
-  DEB_ARCH_REGULAR_PACKAGES = $(libc) $(libc)-dev $(libc)-dbg $(libc)-prof $(libc)-pic libc-bin libc-dev-bin multiarch-support
+  DEB_ARCH_REGULAR_PACKAGES = $(libc) $(libc)-dev $(libc)-dbg $(libc)-prof $(libc)-pic libc-bin libc-dev-bin multiarch-support $(libc)-dev-compat
   DEB_INDEP_REGULAR_PACKAGE

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

[Svante Signell]

On Thu, 2012-11-01 at 10:51 +0100, Tollef Fog Heen wrote:
> ]] Michael Gilbert 
> 
> > mlocate: http://bugs.debian.org/669368 (new upstream could have been
> > pushed via nmu before the freeze, but it was prepared too late)
> > 
> 
> The suggested NMU that does random changes like changing the packaging
> to 3.0 (quilt) and adding an uploader?  Is that even a serious
> suggestion?
> 
> The new upstream release did not include any particularly compelling
> changes for wheezy, which is why I did not update to the newer upstream
> version.

For the record, this mail will also be Cc-ed to bug #669368 since the
commented-on mail was also delivered there.

I did not suggest an NMU, see the explanation in:
https://lists.debian.org/debian-devel/2012/11/msg4.html

Some stuff repeated here, for clarity:
> Well the submitted files was not an NMU, I would need a sponsor for
> that. It was a wish that the maintainer would complete the packaging,
> but that did not happen. The changelog entry was for installation at
> debian-ports. If the maintainer had adopted the changes, the changelog
> would have been written accordingly by him, of course.
> 
> The package is built and installed at debian-ports for GNU/Hurd where
> a sponsor was available. FYI, this package is currently the only
> locate package available on GNU/Hurd, therefore its importance.


-- 
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/1351861975.29093.692.ca...@s1499.it.kth.se

Bug#692159: ITP: pybit -- integrated cross-platform buildd toolkit using queued messages

[Neil Williams]

Package: wnpp
Severity: wishlist
Owner: Neil Williams 

* Package name: pybit
  Version : 0.1.0-1
  Upstream Authors: Nick Davidson ,
Simon Haswell ,
Neil Williams ,
Nick Bane ,
James Bennet 
* URL : https://github.com/nicholasdavidson/pybit
* License : GPL2+
  Programming Lang: Python
  Description : cross-platform buildd toolkit based on message queues

pyBit uses AMQP to create a distributed, cross-platform buildd toolkit
to build packages using a collection of buildds, direct from various 
VCS clients. pyBit is intended to support rapidly evolving software
collections and can support multiple VCS frontends and multiple build
backends. Cross building is expected to be supported for some backends.
The initial backend uses dpkg for Debian.

pyBit includes support for cancelling selected builds and using multiple
buildd clients per architecture, per platform and per suite.

Hooks are in development for subversion and git, other VCS hooks can
be added. A RESTful web API provides live build reports and can generate
build jobs for specific packages using particular VCS branches on
selected architectures to support re-building packages at any point
in the development process. Build history is stored using postgresql.

Initial packages:
pybit-svn - svn post-commit hook
pybit-client - buildd client (uses sbuild for Debian)
pybit-web - RESTful web API and report engine
pybit-common - common python code for each package.

Current dependencies:
rabbitmq-server, python-requests, python-psycopg2 (>= 2.4.2-1~),
python-amqplib, python-debian, python-jsonpickle.


-- 
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/20121102192010.30232.93291.reportbug@sylvester.codehelp

Bug#692167: ITP: notion-scripts -- Contributed scripts for the Notion window manager

[Dima Kogan]

Package: wnpp
Severity: wishlist
Owner: Dima Kogan 

* Package name: notion-scripts
  Version : 20121023
  Upstream Author : Various people
* URL : http://notion.sourceforge.net/
* License : Multiple. Each script is contributed and licensed separately
  Programming Lang: Lua
  Description : Contributed scripts for the Notion window manager
Provides user-contributed add-ons to the Notion window manager,
Including:
 * scripts that can alter Notion's window management behaviour
 * monitors for Notion's statusbar to monitor disk usage, network
   traffic, battery and more.
 * multiple themes that change Notion's look


-- 
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/20121102210807.19798.58045.reportbug@shorty.local

IPv6, tentative addresses, bind(), wheezy

[martin f krafft]

Hey folks,

wheezy will be the first Debian release to feature dependency-based
booting (insserv). I just finished installing a very simple gateway
(IPv4 and IPv6) for a customer, and unbound is failing to start
during a regular boot.

The reason is that by the time bind() is called, the IPv6 address
(configured with /e/n/i inet6 static, which unbound should listen
on) is not yet ready, but "tentative", so the bind() call fails.

In squeeze, this wasn't usually a problem because enough happened
before S20unbound got called.

In wheezy, however, S03unbound gets called in parallel as soon as
"$network $remote_fs $syslog" are provided, and
/etc/rcS.d/S10networking turns on $network right after configuring
the IPv6 address, ignoring that IPv6 assignment comes with the
"tentative" period, during which duplicate address detection (DAD)
is being performed.

I can now disable DAD, or insert "sleep 10" at the top of
/etc/init.d/unbound, but neither is an acceptable solution.

IPv6 has been a release goal for years and we are about to release
another Debian version that does not properly cater for IPv6.

What can be done?

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"auch der mutigste von uns hat nur selten den mut zu dem,
 was er eigentlich weiß."
 - friedrich nietzsche


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: IPv6, tentative addresses, bind(), wheezy

[Russ Allbery]

martin f krafft  writes:

> Hey folks,

> wheezy will be the first Debian release to feature dependency-based
> booting (insserv).

squeeze shipped with insserv.  We use it on all of our squeeze servers.
I'm fairly sure it was even the default on upgrades from lenny.

-- 
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/87liejr60k@windlord.stanford.edu

Re: IPv6, tentative addresses, bind(), wheezy

[Don Armstrong]

On Fri, 02 Nov 2012, martin f krafft wrote:
> The reason is that by the time bind() is called, the IPv6 address
> (configured with /e/n/i inet6 static, which unbound should listen
> on) is not yet ready, but "tentative", so the bind() call fails.

I've actually seen users run into a similar class of problem twice in
the past two days on #debian. [One was easily fixed by adding setting
ASYNCMOUNTNFS="no" to /etc/default/rcS, the other by adding a look
checking for the appropriate device to come up to the init script.]

I think we're going to have little choice but to switch to a real
dependency system which allows for init scripts to be called when a
much broader set of dependencies have been satisfied.

> I can now disable DAD, or insert "sleep 10" at the top of
> /etc/init.d/unbound, but neither is an acceptable solution.

Seems like the right solution is to wait for the network device to be
fully up in the init script with a sleep loop... though that's
certainly not optimal.


Don Armstrong

-- 
I now know how retro SCOs OSes are. Riotous, riotous stuff. How they
had the ya-yas to declare Linux an infant OS in need of their IP is
beyond me. Upcoming features? PAM. files larger than 2 gigs. NFS over
TCP. The 80's called, they want their features back.
 -- Compactable Dave http://www3.sympatico.ca/dcarpeneto/sco.html

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20121102225317.ga11...@rzlab.ucr.edu

Re: IPv6, tentative addresses, bind(), wheezy

[Marco d'Itri]

On Nov 02, Don Armstrong  wrote:

> Seems like the right solution is to wait for the network device to be
> fully up in the init script with a sleep loop... though that's
> certainly not optimal.
Maybe for the time being it will be easier and safer to have ifupdown 
wait until DAD is finished?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: IPv6, tentative addresses, bind(), wheezy

[Holger Levsen]

Hi Martin,

On Freitag, 2. November 2012, martin f krafft wrote:
> What can be done?

file bug reports and/or include bug numbers when posting to -devel?!


cheers,
Holger


-- 
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/201211030105.58626.hol...@layer-acht.org

Re: IPv6, tentative addresses, bind(), wheezy

[martin f krafft]

also sprach Marco d'Itri  [2012.11.03.0038 +0100]:
> Maybe for the time being it will be easier and safer to have
> ifupdown wait until DAD is finished?

I think this would be the best solution (configurable waiting
timeout…) while we do not have true dependency-based booting.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"die zeit für kleine politik ist vorbei.
 schon das nächste jahrhundert
 bringt den kampf um die erdherrschaft."
 - friedrich nietzsche


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)