Re: apt transition - please bump urgency of libept

[Enrico Zini]

On Sun, Dec 16, 2007 at 08:32:31PM -0800, Daniel Burrows wrote:

>   I wonder if it would be a good idea to announce apt transitions on
> [EMAIL PROTECTED]  aptitude is not special in its dependency structure; any
> upload of an apt-related package will do the same thing, and I think
> maintainers of those packages are more likely to be subscribed to deity
> than to -release.  I could be totally mistaken in this belief, of
> course.

I'm with you.  I'd even be happy if a mail was sent to all maintainers
of rdepends of apt when a tricky transition is in place.

It's quite demotivating to work 2 days on a new version, work another
day on testing it and all rdepends, and finally manage to upload it, and
the first reaction you get is not "ehi, that's cool!" but "cluebat that
guy, he broke the transition".  There were many things I was looing
forward to do after my last libept upload, that I just postponed to
avoid doing them in a moment where they could bring me more frustration
than satisfaction.

OTOH I'm sure it's even more demotivating for Frans to have to wait
weeks before uploading this cool new package.

So, as maintainer of C++ packages that use apt and are involved in apt
transitions every so often, I would like to have some sort of handy way
to know "you're free to upload to sid" or "hang on a sec, or upload to
experimental".  A way that possibly doesn't require following both
deity@ and debian-release@ regularly.

I suppose I'm not the only one, and since libapt-pkg is actively
maintained and a very useful piece of software, I expect there will be
even more in the future.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Status of the net-snmp transition

[Steve Langasek]

On Thu, Dec 13, 2007 at 01:50:29PM +0100, Julien BLACHE wrote:

> Weeks ago that transition was 85% done, but still it hasn't happened
> yet, due to a number of uploads at the worst possible times, last
> being heimdal.

> So is there a chance for this transition to happen soon, in which case
> I'll hold my breath for a few days with OpenSER 1.3.0, or should I
> just go ahead and upload ?

Before the weekend, I would've said that there isn't much chance.  Now, the
last blocker, cupsys, has been uploaded with a fix, so if there are no other
interruptions I think we can finish the transition within the week.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[SRM] mydns upload failed

[Thijs Kinkhorst]

Hi!

The DSA for mydns caused the upload to the regular archive to fail:

> mydns_1.1.0.orig.tar.gz doesn't exist
> Due to the errors above, the .changes file couldn't be processed.
> Please fix the problems for the upload to happen.

This could be related to the fact that mydns has been removed from unstable a 
while ago, but that is just my guess. Could you let me know if there's 
something I can do to get this resolved?


thanks,
Thijs


pgpeCDuq1MBUE.pgp
Description: PGP signature

Re: ICU transition status

[Steve Langasek]

On Sun, Dec 16, 2007 at 05:45:05PM -0800, Steve Langasek wrote:
> The attached patch works quite a bit better, and is what I'll upload if it
> finishes checking out here.

Nope, that patch was also total crap.  But this patch gets me a package that
builds successfully, *and* the binaries contain what they're supposed to.

I'll let this one sit for a while for people to comment on, and if there are
no objections I'll upload the NMU tomorrow.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]
diff -u boost-1.34.1/debian/control boost-1.34.1/debian/control
--- boost-1.34.1/debian/control
+++ boost-1.34.1/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Boost Team <[EMAIL PROTECTED]>
 Uploaders: Steve M. Robbins <[EMAIL PROTECTED]>, Domenico Andreoli <[EMAIL PROTECTED]>, Christophe Prud'homme <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 4), bison, flex, docbook-to-man, xsltproc, doxygen, zlib1g-dev, libbz2-dev, libicu36-dev, python-dev | python-all-dev, python2.4-dev, python-support (>= 0.3), g++-4.1
+Build-Depends: debhelper (>= 4), bison, flex, docbook-to-man, xsltproc, doxygen, zlib1g-dev, libbz2-dev, libicu-dev, python-dev | python-all-dev, python2.4-dev, python-support (>= 0.3), g++-4.2
 Standards-Version: 3.7.2
 
 Package: bcp
diff -u boost-1.34.1/debian/changelog boost-1.34.1/debian/changelog
--- boost-1.34.1/debian/changelog
+++ boost-1.34.1/debian/changelog
@@ -1,3 +1,18 @@
+boost (1.34.1-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Build-depend on libicu-dev instead of libicu36-dev for the icu library
+transition.  Closes: #454605.
+  * Bump the Build-Depends from g++-4.1 to g++-4.2, and add
+backwards-compatibility "-gcc41" symlinks for all libraries to avoid
+gratuitous ABI breakage for the rebuild since the gcc version
+doesn't change the ABI, contrary to upstream assertion.  Bump the
+shlibs to match.
+  * Add shlibs to libboost-dbg package, for compatibility with new
+dpkg-shlibdeps behavior.
+
+ -- Steve Langasek <[EMAIL PROTECTED]>  Sun, 16 Dec 2007 13:59:29 -0800
+
 boost (1.34.1-2) unstable; urgency=low
 
   [ Steve Robbins ]
diff -u boost-1.34.1/debian/rules boost-1.34.1/debian/rules
--- boost-1.34.1/debian/rules
+++ boost-1.34.1/debian/rules
@@ -10,12 +10,12 @@
 
 # Boost does not guarantee any ABI, it uses the full version in SONAME
 SOVERSION = 1.34.1
-SHLIBS_VERSION =
+SHLIBS_VERSION = (>= 1.34.1-2.1)
 DEBIAN_SUFFIX =
 
 # tags for library name decoration
 boost_version = $(subst .,_,$(SOVERSION))
-gcc_version = gcc41
+gcc_version = gcc42
 
 # Boost libraries for which we want separate packages
 boost_libs := date-time filesystem graph iostreams program-options python regex serialization signals test thread wave
@@ -36,6 +36,7 @@
 # helpers to make basic and decorated library names
 mk_base_name = usr/lib/libboost_$(subst -,_,$(1))$(2)
 mk_full_name = usr/lib/libboost_$(subst -,_,$(1))-$(gcc_version)$(2)-$(boost_version)
+mk_compat_name = usr/lib/libboost_$(subst -,_,$(1))-gcc41$(2)-$(boost_version)
 
 # helpers to make proper release/debug package names
 mk_pkg_lib = libboost-$(if $(findstring -d,$(2)),dbg,$(1)$(SOVERSION)$(DEBIAN_SUFFIX))
@@ -49,7 +50,8 @@
 mk_ln_files = $(shell echo $(call mk_full_name,$(2),$(3)).so.$(SOVERSION) $(call mk_full_name,$(2),$(3)).so >> $(call mk_deb_dev,$(1),$(3)).links)
 mk_ln2_files = $(shell echo $(call mk_full_name,$(2),$(3)).so $(call mk_base_name,$(2),$(3)).so >> $(call mk_deb_dev,$(1),$(3)).links)
 mk_ln3_files = $(shell echo $(call mk_full_name,$(2),$(3)).a $(call mk_base_name,$(2),$(3)).a >> $(call mk_deb_dev,$(1),$(3)).links)
-mk_files = $(foreach fn,a so ln ln2 ln3,$(call mk_$(fn)_files,$(1),$(2),$(3)))
+mk_ln4_files = $(shell echo $(call mk_full_name,$(2),$(3)).so.$(SOVERSION) $(call mk_compat_name,$(2),$(3)).so.$(SOVERSION) >> $(call mk_deb_lib,$(1),$(3)).links)
+mk_files = $(foreach fn,a so ln ln2 ln3 ln4,$(call mk_$(fn)_files,$(1),$(2),$(3)))
 
 # invokes mk_files of every variant of every shared library of every Boost library
 mk_debhelper_files = \
@@ -62,9 +64,9 @@
 		) \
 	)
 
-TOOLSET_CONFIG="using gcc : 4.1 : g++-4.1 : _REENTRANT ;"
+TOOLSET_CONFIG="using gcc : 4.2 : g++-4.2 : _REENTRANT ;"
 ifeq ($(DEB_BUILD_ARCH), hppa)
-TOOLSET_CONFIG="using gcc : 4.1 : g++-4.1 : _REENTRANT -mlong-calls ;"
+TOOLSET_CONFIG="using gcc : 4.2 : g++-4.2 : _REENTRANT -mlong-calls ;"
 endif
 PYTHON_CONFIG="using python : 2.4 : /usr ;"
 
@@ -117,6 +119,7 @@
 	rm -rf debian/libboost-*$(SOVERSION).install
 	rm -rf debian/libboost-*-dev.install
 	rm -rf debian/libboost-*-dev.links
+	rm -rf debian/libboost-*$(SOVERSION).links
 	rm -rf debian/libboost-dbg.install
 	rm -rf debian/libboost-dbg.links
 
@@ -318,6 +321,7 @@
 			echo DH_OPTIONS=-p$${lib

Re: apt transition - please bump urgency of libept

[Adeodato Simó]

* Enrico Zini [Mon, 17 Dec 2007 09:48:48 +0100]:

> I would like to have some sort of handy way
> to know "you're free to upload to sid" or "hang on a sec, or upload to
> experimental".  A way that possibly doesn't require following both
> deity@ and debian-release@ regularly.

* Enrico Zini [Mon, 17 Dec 2007 01:02:09 +0100]:

> This kind of scenario made me think... would it make sense to publish in
> a fixed location a machine-readable scenario of current ongoing
> transitions,

Yes, I've very often thought there is a real need for this, but I
haven't sat down to think how to do it, and no magic idea has suddenly
visited me either.

Cheers,


-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Man is certainly stark mad; he cannot make a flea, yet he makes gods by the
dozens.
-- Michel de Montaigne


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt transition - please bump urgency of libept

[Otavio Salvador]

[ I've droped people that are know to be subscribed on ml ]

Daniel Burrows <[EMAIL PROTECTED]> writes:

>   (this is an expansion of a reply I dashed off earlier to Otavio on my
>way to dinner)
>
> On Sun, Dec 16, 2007 at 10:42:41PM -0200, Otavio Salvador <[EMAIL PROTECTED]> 
> was heard to say:
>> I'd like to ask you to postpone any other aptitude upload, for sid,
>> until we're moved current APT to testing since we do want to move
>> forward with APT on sid but d-i and other things need this (0.7.9)
>> version to be available ASAP.
>
>   Hi, Otavio.  Thanks for bringing this to my attention.
>
>   Sorry about the trouble.  I wasn't aware that there was an apt
> transition going on, but I certainly won't upload any new versions until
> that goes through.  I've subscribed to -release so that I can keep an
> eye on what sorts of transitions are going on in the future.  Hopefully
> I can avoid future badly-timed uploads that way.

That's fine. We just want to make available on lenny to move forward
again on sid.

>   I wonder if it would be a good idea to announce apt transitions on
> [EMAIL PROTECTED]  aptitude is not special in its dependency structure; any
> upload of an apt-related package will do the same thing, and I think
> maintainers of those packages are more likely to be subscribed to deity
> than to -release.  I could be totally mistaken in this belief, of
> course.

Yes, I agree on that. We can use deity for this kind of coordination
too.

Personally I think that we (you, mvo and me) need to coordianate with
each other when doing uploads since we all are affected by them. This
way we avoid this mistake to happen in future.

Even if we forget to coordinate those things on ml, would be nice to
us send a notice for all involved people before uploading so we avoid
those mistakes, indeed.

Next APT upload will fix a lot of bugs and I think it's going to merge
some new features that were available at Ubuntu reduzing our diversion
a lot. I've also commited a bunch of bugfixes that were available on
BTS for a while. I'm looking forward to see it in :-)

Daniel,

I'd like to ask you, to in cuple of days, to ask on debian-release for
a urgency bump to medium for aptitude and cwidget so we reduce the
need time by half.

Cheers,

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt transition - please bump urgency of libept

[Otavio Salvador]

Enrico Zini <[EMAIL PROTECTED]> writes:

<...>
> So, as maintainer of C++ packages that use apt and are involved in apt
> transitions every so often, I would like to have some sort of handy way
> to know "you're free to upload to sid" or "hang on a sec, or upload to
> experimental".  A way that possibly doesn't require following both
> deity@ and debian-release@ regularly.
>
> I suppose I'm not the only one, and since libapt-pkg is actively
> maintained and a very useful piece of software, I expect there will be
> even more in the future.

Personally I think that deity is the most logical place for it. It's a
low volume ml and then I see no problem to just use it.

rdepends mail to all involved packages will fail since we all can
forgot to send to someone involved (a not that ofthen used rdepends or
a new one) and this specific one can be the open uploading a package
without noticing it.

I then think that the most easy and logical way for coordinating all
this is using deity as suggested by Daniel.

APT and aptitude are the most ofthen uploaded package and then are the
highly risk ones but all people using libapt-pkg ought to be careful
with this.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [SRM] mydns upload failed

[Luk Claes]

Thijs Kinkhorst wrote:
> Hi!
> 
> The DSA for mydns caused the upload to the regular archive to fail:
> 
>> mydns_1.1.0.orig.tar.gz doesn't exist

It does exist...

>> Due to the errors above, the .changes file couldn't be processed.
>> Please fix the problems for the upload to happen.

Can you give the actual error message?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#456646: aptitude: depends on libgcc1 from experimental

[Daniel Burrows]

On Mon, Dec 17, 2007 at 11:21:49AM +0100, Michal Politowski <[EMAIL PROTECTED]> 
was heard to say:
> aptitude 0.4.10-1 depends on libgcc1 (>= 1:4.3),
> which is only available in experimental.

  Ow.  So, release team, is the correct way of handling this without
making everyone even more angry at me to do a binary-only rebuild?

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Please hint glibc/2.7-4

[Aurelien Jarno]

Hi,

glibc/2.7-4 is ready to go into testing. It fixes bug that are present
in the testing version, and hasn't any known regression.

Could you please hint it?

Thanks,
Aurelien

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


signature.asc
Description: Digital signature

Re: Bug#456646: aptitude: depends on libgcc1 from experimental

[Luk Claes]

Daniel Burrows wrote:
> On Mon, Dec 17, 2007 at 11:21:49AM +0100, Michal Politowski <[EMAIL 
> PROTECTED]> was heard to say:
>> aptitude 0.4.10-1 depends on libgcc1 (>= 1:4.3),
>> which is only available in experimental.
> 
>   Ow.  So, release team, is the correct way of handling this without
> making everyone even more angry at me to do a binary-only rebuild?

Which is already built... so closing the bug...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please hint glibc/2.7-4

[Luk Claes]

Aurelien Jarno wrote:
> Hi,
> 
> glibc/2.7-4 is ready to go into testing. It fixes bug that are present
> in the testing version, and hasn't any known regression.
> 
> Could you please hint it?

unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [SRM] mydns upload failed

[Luk Claes]

Luk Claes wrote:
> Thijs Kinkhorst wrote:
>> Hi!
>>
>> The DSA for mydns caused the upload to the regular archive to fail:
>>
>>> mydns_1.1.0.orig.tar.gz doesn't exist
> 
> It does exist...
> 
>>> Due to the errors above, the .changes file couldn't be processed.
>>> Please fix the problems for the upload to happen.
> 
> Can you give the actual error message?

Apparantly all binary package uploads were rejected due to not finding a
source package, though the source package nor the i386 binary package
are to be found?

Maybe it's just a matter of uploading the i386 binary package together
with the source package (without orig.tar.gz) and reuploading the other
binary packages afterwards?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#456646: aptitude: depends on libgcc1 from experimental

[Daniel Burrows]

On Mon, Dec 17, 2007 at 03:59:51PM +0100, Luk Claes <[EMAIL PROTECTED]> was 
heard to say:
> Daniel Burrows wrote:
> > On Mon, Dec 17, 2007 at 11:21:49AM +0100, Michal Politowski <[EMAIL 
> > PROTECTED]> was heard to say:
> >> aptitude 0.4.10-1 depends on libgcc1 (>= 1:4.3),
> >> which is only available in experimental.
> > 
> >   Ow.  So, release team, is the correct way of handling this without
> > making everyone even more angry at me to do a binary-only rebuild?
> 
> Which is already built... so closing the bug...

  Ah.  Has one been done for libcwidget1?  It's built against the wrong
libgcc1 too.

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#456646: aptitude: depends on libgcc1 from experimental

[Luk Claes]

Daniel Burrows wrote:
> On Mon, Dec 17, 2007 at 03:59:51PM +0100, Luk Claes <[EMAIL PROTECTED]> was 
> heard to say:
>> Daniel Burrows wrote:
>>> On Mon, Dec 17, 2007 at 11:21:49AM +0100, Michal Politowski <[EMAIL 
>>> PROTECTED]> was heard to say:
 aptitude 0.4.10-1 depends on libgcc1 (>= 1:4.3),
 which is only available in experimental.
>>>   Ow.  So, release team, is the correct way of handling this without
>>> making everyone even more angry at me to do a binary-only rebuild?
>> Which is already built... so closing the bug...
> 
>   Ah.  Has one been done for libcwidget1?  It's built against the wrong
> libgcc1 too.

Yes, that's why I closed the other bug too ;-)

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt transition - please bump urgency of libept

[Steve Langasek]

On Mon, Dec 17, 2007 at 09:48:48AM +0100, Enrico Zini wrote:
> So, as maintainer of C++ packages that use apt and are involved in apt
> transitions every so often, I would like to have some sort of handy way
> to know "you're free to upload to sid" or "hang on a sec, or upload to
> experimental".  A way that possibly doesn't require following both
> deity@ and debian-release@ regularly.

- run the commands "grep-excuses libept; grep-excuses libept/i386"
- look for any Depends: lines
- look at the testing transition page for those dependencies on
  bjorn.haxx.se: http://bjorn.haxx.se/debian/testing.pl?package=apt
- if it looks hairy, ask

That's going to catch 99% of the problematic cases, and is far more scalable
than to have the release team try to notify all affected maintainers
whenever there's an ongoing transition.  (Perhaps not more scalable than
having dput warn, but the above is something any maintainer can do for
themselves today.)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Testing transition pages (was: apt transition)

[Frans Pop]

(dropping all CCs as this is basically a new issue)

On Monday 17 December 2007, Steve Langasek wrote:
> - look at the testing transition page for those dependencies on
>   bjorn.haxx.se: http://bjorn.haxx.se/debian/testing.pl?package=apt

Is Björn still around? I noted several times during this transition that his 
pages currently do not really support binNMUs.

There are also quite a lot of lines that could/should probably be 
suppressed, like:
Updating aptsh makes 1 non-depending packages uninstallable on alpha: aptsh


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

Re: apt transition - please bump urgency of libept

[Joerg Jaspert]

On 11236 March 1977, Steve Langasek wrote:
> On Mon, Dec 17, 2007 at 09:48:48AM +0100, Enrico Zini wrote:
>> So, as maintainer of C++ packages that use apt and are involved in apt
>> transitions every so often, I would like to have some sort of handy way
>> to know "you're free to upload to sid" or "hang on a sec, or upload to
>> experimental".  A way that possibly doesn't require following both
>> deity@ and debian-release@ regularly.
> - run the commands "grep-excuses libept; grep-excuses libept/i386"
> - look for any Depends: lines
> - look at the testing transition page for those dependencies on
>   bjorn.haxx.se: http://bjorn.haxx.se/debian/testing.pl?package=apt- if it 
> looks hairy, ask

> That's going to catch 99% of the problematic cases, and is far more scalable
> than to have the release team try to notify all affected maintainers
> whenever there's an ongoing transition.  (Perhaps not more scalable than
> having dput warn, but the above is something any maintainer can do for
> themselves today.)

I guess there is no scriptable way to do that? Ie. if it would be
scriptable without too much guesses here and there I would love to add
something into process-new that shows me if there is anything related to
transitions with the package I just look at. Which would show such
things as the cwidgets upload, or other uploads where the library
package name changes due to soname, but where it would be better to
wait a day or two more before it gets accepted to let the old version
transition first, together with whatever depends on it...

-- 
bye Joerg
 man
 the AMD64 camp is not helped by the list of people supporting it
 when nerode is on your side, you know you're doing something wrong


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt transition - please bump urgency of libept

[Otavio Salvador]

Joerg Jaspert <[EMAIL PROTECTED]> writes:

> On 11236 March 1977, Steve Langasek wrote:
>> On Mon, Dec 17, 2007 at 09:48:48AM +0100, Enrico Zini wrote:
>>> So, as maintainer of C++ packages that use apt and are involved in apt
>>> transitions every so often, I would like to have some sort of handy way
>>> to know "you're free to upload to sid" or "hang on a sec, or upload to
>>> experimental".  A way that possibly doesn't require following both
>>> deity@ and debian-release@ regularly.
>> - run the commands "grep-excuses libept; grep-excuses libept/i386"
>> - look for any Depends: lines
>> - look at the testing transition page for those dependencies on
>>   bjorn.haxx.se: http://bjorn.haxx.se/debian/testing.pl?package=apt- if it 
>> looks hairy, ask
>
>> That's going to catch 99% of the problematic cases, and is far more scalable
>> than to have the release team try to notify all affected maintainers
>> whenever there's an ongoing transition.  (Perhaps not more scalable than
>> having dput warn, but the above is something any maintainer can do for
>> themselves today.)
>
> I guess there is no scriptable way to do that? Ie. if it would be
> scriptable without too much guesses here and there I would love to add
> something into process-new that shows me if there is anything related to
> transitions with the package I just look at. Which would show such
> things as the cwidgets upload, or other uploads where the library
> package name changes due to soname, but where it would be better to
> wait a day or two more before it gets accepted to let the old version
> transition first, together with whatever depends on it...

I think it's scriptable but it won't catch cases that doesn't go
throught NEW queue so it looks suboptimal. Besides, this should be
done by you (ftp-master) but by us developers and maintainers.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt transition - please bump urgency of libept

[Enrico Zini]

On Mon, Dec 17, 2007 at 11:46:00AM +0100, Adeodato Simó wrote:

> > This kind of scenario made me think... would it make sense to publish in
> > a fixed location a machine-readable scenario of current ongoing
> > transitions,
> Yes, I've very often thought there is a real need for this, but I
> haven't sat down to think how to do it, and no magic idea has suddenly
> visited me either.

How hard would it be for the release team to maintain a file like this?

 Build-Depends: libapt-pkg-dev libept-dev
 Action: block
 Message: Transition to testing of 140 rdepends of apt: please contact
  debian-release@lists.debian.org before uploading.
 
 Build-Depends: libfoo-dev libbar-dev foobar
 Action: warn
 Message: A transition is being planned, you may want to contact xyz if
  you intend to upload again in the near future

If that isn't too much burden, I can patch dput to download the file,
check if one of the build-deps in the .dsc shows up on a record an take
the appropriate action.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

binNMUs to follow libgps soname bump

[Bernd Zeimetz]

Hi release team,

please schedule the following binNMUs as gpsd builds libgps17 now (since
version 2.35-1). So the dep-wait should be libgps-dev (>= 2.35).

viking_0.9.3-2, Rebuild against newer libgps, 1, alpha amd64 arm hppa i386 ia64 
m68k mips mipsel powerpc s390 sparc
gaia_0.1.2-4, Rebuild against newer libgps, 1, alpha amd64 arm hppa i386 ia64 
m68k mips mipsel powerpc s390 sparc


gosmore FTBFS and needs a normal NMU or upload anyway (#454519).
All other packages rdepending on libgps are built from the gpsd source.


Thanks,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt transition - please bump urgency of libept

[Raphael Geissert]

Hi Enrico,

Enrico Zini wrote:
> 
> If that isn't too much burden, I can patch dput to download the file,
> check if one of the build-deps in the .dsc shows up on a record an take
> the appropriate action.

Why dput? dput can also be used for local and non-Debian repositories so I'd
rather make the change in dak so uploads can be kept in a
DELAYED-BY-TRANSITION queue, making this useful for all kind of uploads.
There are many tools to upload a package, so I strongly believe the change
should be made on the server side, not on client's.

> 
> 
> Ciao,
> 
> Enrico
> 

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt transition - please bump urgency of libept

[Otavio Salvador]

Raphael Geissert <[EMAIL PROTECTED]> writes:

> Hi Enrico,
>
> Enrico Zini wrote:
>> 
>> If that isn't too much burden, I can patch dput to download the file,
>> check if one of the build-deps in the .dsc shows up on a record an take
>> the appropriate action.
>
> Why dput? dput can also be used for local and non-Debian repositories so I'd
> rather make the change in dak so uploads can be kept in a
> DELAYED-BY-TRANSITION queue, making this useful for all kind of uploads.
> There are many tools to upload a package, so I strongly believe the change
> should be made on the server side, not on client's.

Yes, it looks logical to me too. This could be then controlled by RM
team as bridney is today.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]