Debian Bug report logs - #884635
transition: libupnp

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Uwe Kleine-König <ukleinek@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: transition: libupnp

Date: Sun, 17 Dec 2017 22:07:16 +0100

Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition

Hello,

Currently there are two versions of libupnp in the archive:

 - src:libupnp providing the 1.6.x branch of libupnp which is considered
   legacy by upstream
 - src:pupnp-1.8 providing the 1.8.x branch of libupnp

I want to get rid of libupnp6 converting all rdeps to the newer libupnp
package.

There are not that many reverse dependencies for libupnp6:

	amule
	amule-daemon
	djmount
	gmediarender
	gmediaserver
	libmediastreamer-base3
	linphone
	linphone-nogtk
	linux-igd
	mpd
	openclonk
	ring-daemon
	silverjuke
	vlc-plugin-base
	wmaloader

I know about mpd upstream already supporting both versions. The Debian
maintainer of vlc already invested some work in making vlc support both
versions. I'm about to send a bug about silverjuke with a patch
implementing a simple conversion which makes it support both versions.
The Debian maintainer of wmaloader asked me to report an RM bug.

James Cowgill (= maintainer of src:pupnp-1.8) already uploaded a version
of src:pupnp-1.8 providing libupnp-dev to experimental.
https://release.debian.org/transitions/ doesn't have an automatic
transition though (probably because there are two packages involved).

Ben file:

title = "libupnp";
is_affected = .depends ~ "libupnp6" | .depends ~ "libupnp10";
is_good = .depends ~ "libupnp10";
is_bad = .depends ~ "libupnp6";

Message #10 received at 884635@bugs.debian.org (full text, mbox, reply):

From: James Cowgill <jcowgill@debian.org>

To: Uwe Kleine-König <ukleinek@debian.org>

Cc: 884635@bugs.debian.org

Subject: Re: Bug#884635: transition: libupnp

Date: Sun, 17 Dec 2017 21:34:34 +0000

[Message part 1 (text/plain, inline)]

Control: block -1 by 882377 884252 884243 884245 884246 884247 884248
Control: block -1 by 884249 884250 884251

Hi,

On 17/12/17 21:07, Uwe Kleine-König wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> Currently there are two versions of libupnp in the archive:
> 
>  - src:libupnp providing the 1.6.x branch of libupnp which is considered
>    legacy by upstream
>  - src:pupnp-1.8 providing the 1.8.x branch of libupnp
> 
> I want to get rid of libupnp6 converting all rdeps to the newer libupnp
> package.
> 
> There are not that many reverse dependencies for libupnp6:
[...]
> I know about mpd upstream already supporting both versions. The Debian
> maintainer of vlc already invested some work in making vlc support both
> versions. I'm about to send a bug about silverjuke with a patch
> implementing a simple conversion which makes it support both versions.
> The Debian maintainer of wmaloader asked me to report an RM bug.

I've added blocks for the bugs I think need to be fixed before starting
the transition. Most were filed by Sebastian Ramacher who (very kindly)
did a rebuild of all the rdeps against pupnp 1.8. mpd, silverjuke and
wmaloader all have bugs already filed against them.

> James Cowgill (= maintainer of src:pupnp-1.8) already uploaded a version
> of src:pupnp-1.8 providing libupnp-dev to experimental.
> https://release.debian.org/transitions/ doesn't have an automatic
> transition though (probably because there are two packages involved).
> 
> Ben file:
> 
> title = "libupnp";
> is_affected = .depends ~ "libupnp6" | .depends ~ "libupnp10";
> is_good = .depends ~ "libupnp10";
> is_bad = .depends ~ "libupnp6";

One slight issue is #882377. In pupnp 1.8.3 upstream broke the ABI which
I pointed out to them. As a result they have bumped the SONAME in
upstream git (not yet released). To avoid having to do two transitions,
we should wait to use the new SONAME. Since the damage is already done,
I guess we could use the new SONAME right now, although I am always a
little cautious in doing that in case upstream changes something else :)
In any case, the ben file will need to be changed at some point.

Also thanks to the people working on this. I know I haven't done as much
as I probably should be doing.

Thanks,
James

[signature.asc (application/pgp-signature, attachment)]

Message #19 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Uwe Kleine-König <uwe@kleine-koenig.org>

To: James Cowgill <jcowgill@debian.org>

Cc: 884635@bugs.debian.org

Subject: Re: Bug#884635: transition: libupnp

Date: Sun, 17 Dec 2017 23:05:02 +0100

[Message part 1 (text/plain, inline)]

Hello James,

On Sun, Dec 17, 2017 at 09:34:34PM +0000, James Cowgill wrote:
> Control: block -1 by 882377 884252 884243 884245 884246 884247 884248
> Control: block -1 by 884249 884250 884251

Thanks for the blocks. Even though Sebastian told me in irc that he
reported these I didn't consider these blocks when reporting the
transition bug.

> > title = "libupnp";
> > is_affected = .depends ~ "libupnp6" | .depends ~ "libupnp10";
> > is_good = .depends ~ "libupnp10";
> > is_bad = .depends ~ "libupnp6";
> 
> One slight issue is #882377. In pupnp 1.8.3 upstream broke the ABI which
> I pointed out to them. As a result they have bumped the SONAME in
> upstream git (not yet released). To avoid having to do two transitions,
> we should wait to use the new SONAME. Since the damage is already done,
> I guess we could use the new SONAME right now, although I am always a
> little cautious in doing that in case upstream changes something else :)
> In any case, the ben file will need to be changed at some point.

I don't know if the transition is only added to the tracker when all
blocking bugs are resolved. If not, ben could use

	is_good = .depends ~ /libupnp1[01]/

(or even .depends ~ /libupnp1[0-9]/ if upstream is expected to misbehave
:-)

Best regards
Uwe

[signature.asc (application/pgp-signature, inline)]

Message #26 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Uwe Kleine-König <uwe@kleine-koenig.org>

To: 884635@bugs.debian.org

Subject: Re: Bug#884635: transition: libupnp

Date: Fri, 22 Dec 2017 22:38:23 +0100

[Message part 1 (text/plain, inline)]

Hello,

On Sun, Dec 17, 2017 at 10:07:16PM +0100, Uwe Kleine-König wrote:
> Currently there are two versions of libupnp in the archive:
> 
>  - src:libupnp providing the 1.6.x branch of libupnp which is considered
>    legacy by upstream
>  - src:pupnp-1.8 providing the 1.8.x branch of libupnp
> 
> I want to get rid of libupnp6 converting all rdeps to the newer libupnp
> package.
> 
> There are not that many reverse dependencies for libupnp6:
> 
> 	amule
> 	amule-daemon
> 	djmount
> 	gmediarender
> 	gmediaserver
> 	libmediastreamer-base3
> 	linphone
> 	linphone-nogtk
> 	linux-igd
> 	mpd
> 	openclonk
> 	ring-daemon
> 	silverjuke
> 	vlc-plugin-base
> 	wmaloader

Just a heads up with the current status of the affected packages (in
form of my todo list, I hope it is understandable):

 - amule
   - FTBFS #884996 (patch)
 - djmount
   - FTBFS #884243
 - gmediaserver
   - FTBFS #884245
 - gmrender-resurrect
   - FTBFS #884246
 - linphone
   - FTBFS #884247
 - linux-igd
   - triggers #884252 ("libupnp-dev: missing ThreadPool.h", fixed-upstream)
   - uses libupnp6 internal stuff (TimerThread.h) and so probably FTBFSs
     when #884252 is fixed with no easy patch fixing that.
   - package orphaned, maintainer MIA
 - mpd
   - builds fine
 - openclonk
   - builds fine
 - ring
   - FTBFS #884249
 - silverjuke
   - FTBFS #884250 (patch, forwarded)
 - vlc
   - builds fine
 - wmaloader
   - FTBFS #884251
   - RM #884637

I wonder how important it is to fix linux-igd compared with the effort
this will produce. Maybe it's sensible to remove it?

So five patches (djmount, gmediaserver, gmrender-resurrect, linphone,
ring) still to create before we could start the transition. I didn't
look into these yet.

Best regards
Uwe

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Sebastian Ramacher <sramacher@debian.org>

To: Uwe Kleine-König <uwe@kleine-koenig.org>, 884635@bugs.debian.org

Subject: Re: Bug#884635: transition: libupnp

Date: Sun, 30 Sep 2018 10:09:00 +0200

[Message part 1 (text/plain, inline)]

Hi

On 2017-12-22 22:38:23, Uwe Kleine-König wrote:
> Hello,
> 
> On Sun, Dec 17, 2017 at 10:07:16PM +0100, Uwe Kleine-König wrote:
> > Currently there are two versions of libupnp in the archive:
> > 
> >  - src:libupnp providing the 1.6.x branch of libupnp which is considered
> >    legacy by upstream
> >  - src:pupnp-1.8 providing the 1.8.x branch of libupnp
> > 
> > I want to get rid of libupnp6 converting all rdeps to the newer libupnp
> > package.
> > 
> > There are not that many reverse dependencies for libupnp6:
> > 
> > 	amule
> > 	amule-daemon
> > 	djmount
> > 	gmediarender
> > 	gmediaserver
> > 	libmediastreamer-base3
> > 	linphone
> > 	linphone-nogtk
> > 	linux-igd
> > 	mpd
> > 	openclonk
> > 	ring-daemon
> > 	silverjuke
> > 	vlc-plugin-base
> > 	wmaloader
> 
> Just a heads up with the current status of the affected packages (in
> form of my todo list, I hope it is understandable):

The list of open issues is down to:

>  - amule
>    - FTBFS #884996 (patch)
>  - djmount
>    - FTBFS #884243
>  - gmrender-resurrect
>    - FTBFS #884246
>  - linphone
>    - FTBFS #884247

Those still fail to build.

>  - gmediaserver
>    - FTBFS #884245

RM requested.

Considering that those packages had over 9 months to get fixed, I think we
should start the transition and RM the unfixed packages from testing.

Cheers
-- 
Sebastian Ramacher

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Uwe Kleine-König <uwe@kleine-koenig.org>

To: Sebastian Ramacher <sramacher@debian.org>, 884635@bugs.debian.org, Marcelo Roberto Jimenez <mroberto@users.sourceforge.net>

Subject: Re: Bug#884635: transition: libupnp

Date: Sun, 30 Sep 2018 12:20:45 +0200

[Message part 1 (text/plain, inline)]

Hello,

adding Marcelo (upstream for libupnp) to recipents.

On 09/30/2018 10:09 AM, Sebastian Ramacher wrote:
> On 2017-12-22 22:38:23, Uwe Kleine-König wrote:
>> Hello,
>>
>> On Sun, Dec 17, 2017 at 10:07:16PM +0100, Uwe Kleine-König wrote:
>>> Currently there are two versions of libupnp in the archive:
>>>
>>>  - src:libupnp providing the 1.6.x branch of libupnp which is considered
>>>    legacy by upstream
>>>  - src:pupnp-1.8 providing the 1.8.x branch of libupnp
>>>
>>> I want to get rid of libupnp6 converting all rdeps to the newer libupnp
>>> package.
>>
>> ...
> 
> The list of open issues is down to:
> 
>>  - amule
>>    - FTBFS #884996 (patch)
>>  - djmount
>>    - FTBFS #884243
>>  - gmrender-resurrect
>>    - FTBFS #884246
>>  - linphone
>>    - FTBFS #884247
> 
> Those still fail to build.
> 
>>  - gmediaserver
>>    - FTBFS #884245
> 
> RM requested.
(RM = Request to remove the package from testing)

> Considering that those packages had over 9 months to get fixed, I think we
> should start the transition and RM the unfixed packages from testing.

The bug for gmrender-resurrect is tagged "help". I didn't look into that
but I think it would be fair to check this one at least before starting
to remove packages. I'll give it a bump in my todo list.

@Marcelo: Do you care to look into https://bugs.debian.org/884246 ?

Best regards
Uwe

[signature.asc (application/pgp-signature, attachment)]

Message #45 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Marcelo Roberto Jimenez <mroberto@users.sourceforge.net>

To: Uwe Kleine-König <uwe@kleine-koenig.org>

Cc: Sebastian Ramacher <sramacher@debian.org>, 884635@bugs.debian.org

Subject: Re: Bug#884635: transition: libupnp

Date: Mon, 1 Oct 2018 18:33:25 -0300

[Message part 1 (text/plain, inline)]

Hi,

Unfortunately, there is no porting guide. But the good news is that the new
API is pretty much straight forward and I can summarize it here. It is much
easier to use than it is to explain, but here it goes:

You no longer have pointers to data structures. All the pointers have been
substituted by handlers. This also means that you no longer de-reference
pointers, you use functions with meaningful names to access the fields.
That was done a long time ago to shield the applications using libupnp from
changes in the internal data structures, as well as allowing developers to
make changes to these structures without the need to release incompatible
libraries.

In the processes, several repetitive bug prone boiler plate code has been
replaced by those functions, which being defined as macro templates are no
longer subject to this type of mistakes. Just call the function and get
what you want.

All the magic is done in the files upnp/inc/TemplateSource.h and
upnp/inc/TemplateInclude.h. The technique is called x-macros (
https://en.wikipedia.org/wiki/X_Macro), and is as old as the first assembly
pre-processor. Together with some of the C preprocessor features, it works
like a C++ object. You have classes defined in source files like
ActionComplete.h, and the class definition is boiler plate. There are a
limited number of types that an object can have, like integer, string,
DOMString, buffer, list and object. The last is a handle to another object.
There are get and set methods for each member. Every class has a new(),
delete(), dup() and assign() methods.

Example. The class ActionComplete is defined like this:

#define CLASS UpnpActionComplete


#define EXPAND_CLASS_MEMBERS(CLASS) \

	EXPAND_CLASS_MEMBER_INT(CLASS, ErrCode, int) \

	EXPAND_CLASS_MEMBER_STRING(CLASS, CtrlUrl) \

	EXPAND_CLASS_MEMBER_INT(CLASS, ActionRequest, IXML_Document *) \

	EXPAND_CLASS_MEMBER_INT(CLASS, ActionResult, IXML_Document *) \


This creates the following methods:

UpnpActionComplete *UpnpActionComplete_new();
void UpnpActionComplete_delete(UpnpActionComplete *p);
UpnpActionComplete *UpnpActionComplete_dup(UpnpActionComplete *p);
UpnpActionComplete *UpnpActionComplete_assign(UpnpActionComplete *p, const
UpnpActionComplete *q);

For each INT member field:

int UpnpActionComplete_get_ErrCode(const UpnpActionComplete *p);
int UpnpActionComplete_set_ErrCode(const UpnpActionComplete *p, int n);

For STRING member fields:

const UpnpString *UpnpActionComplete_get_CtrlUrl(const UpnpActionComplete *p);

int UpnpActionComplete_set_CtrlUrl(CLASS *p, const UpnpString *s);

size_t UpnpActionComplete_get_CtrlUrl##_Length(const UpnpActionComplete *p);

const char *UpnpActionComplete_get_CtrlUrl##_cstr(const UpnpActionComplete *p);

int UpnpActionComplete_strcpy_CtrlUrl(UpnpActionComplete *p, const char *s);

int UpnpActionComplete_strncpy_CtrlUrl(UpnpActionComplete *p, const
char *s, size_t n);

void UpnpActionComplete_clear_CtrlUrl(UpnpActionComplete *p);


And so on.

There is only one class that is coded in C, and that is UpnpString, which
can be found in upnp/src/api/UpnpString.c and upnp/inc/UpnpString.h. There
you can see how the template generate code would look like.

If I can help further, please do contact me.

Best regards,
Marcelo.


On Sun, Sep 30, 2018 at 7:40 AM Uwe Kleine-König <uwe@kleine-koenig.org>
wrote:

> Hello,
>
> adding Marcelo (upstream for libupnp) to recipents.
>
>

[Message part 2 (text/html, inline)]

Message #50 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: Uwe Kleine-König <uwe@kleine-koenig.org>, 884635@bugs.debian.org, Sebastian Ramacher <sramacher@debian.org>, Marcelo Roberto Jimenez <mroberto@users.sourceforge.net>

Subject: Re: Bug#884635: transition: libupnp

Date: Tue, 02 Oct 2018 05:34:00 +0000

Uwe Kleine-König:
> Hello,
> 
> adding Marcelo (upstream for libupnp) to recipents.
> 
> On 09/30/2018 10:09 AM, Sebastian Ramacher wrote:
>> On 2017-12-22 22:38:23, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> On Sun, Dec 17, 2017 at 10:07:16PM +0100, Uwe Kleine-König wrote:
>>>> Currently there are two versions of libupnp in the archive:
>>>>
>>>>  - src:libupnp providing the 1.6.x branch of libupnp which is considered
>>>>    legacy by upstream
>>>>  - src:pupnp-1.8 providing the 1.8.x branch of libupnp
>>>>
>>>> I want to get rid of libupnp6 converting all rdeps to the newer libupnp
>>>> package.
>>>
>>> ...
>>
>> The list of open issues is down to:
>>
>>>  - amule
>>>    - FTBFS #884996 (patch)
>>>  - djmount
>>>    - FTBFS #884243
>>>  - gmrender-resurrect
>>>    - FTBFS #884246
>>>  - linphone
>>>    - FTBFS #884247
>>
>> Those still fail to build.
>>
>>>  - gmediaserver
>>>    - FTBFS #884245
>>
>> RM requested.
> (RM = Request to remove the package from testing)
> 
>> Considering that those packages had over 9 months to get fixed, I think we
>> should start the transition and RM the unfixed packages from testing.
> 
> The bug for gmrender-resurrect is tagged "help". I didn't look into that
> but I think it would be fair to check this one at least before starting
> to remove packages. I'll give it a bump in my todo list.
> 
> @Marcelo: Do you care to look into https://bugs.debian.org/884246 ?
> 
> Best regards
> Uwe
> 

Hi,

Before this transition can start, we will need a solution for amule,
djmount, gmrender-resurrect and linphone (which is either RM or upload
with a fix).

Removing all of them leads to the following collateral damage[1]:

"""
Checking reverse dependencies...
# Broken Depends:
kopete: kopete
libosmo-abis: libosmotrau2

# Broken Build-Depends:
kopete: libmediastreamer-dev (>= 3.6)
        libortp-dev (>= 0.13)
libosmo-abis: libortp-dev
libosmo-netif: libortp-dev
osmo-bts: libortp-dev

Dependency problem found.
"""
(I have not researched exactly which package causes what to break; that
is an exercise left for the reader)

Accordingly, if we plan on removing these packages, their dependencies
are now also a part of the transition (having to move away from the
packages being removed or being removed themselves - the latter leading
to a rinse-and-repeat effect).

So:

 * Which of amule, djmount, gmrender-resurrect, linphone are going to
   be fixed/removed?

 * What is and how do we handle the collateral (if any) from any
  removals?

Thanks,
~Niels


[1]:
dak rm -nR -s testing amule djmount gmrender-resurrect \
  linphone gmediaserver

Can be run from respighi.debian.org, which is DD-accessible.

Message #55 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Uwe Kleine-König <uwe@kleine-koenig.org>

To: Marcelo Roberto Jimenez <mroberto@users.sourceforge.net>

Cc: Sebastian Ramacher <sramacher@debian.org>, 884635@bugs.debian.org

Subject: Re: Bug#884635: transition: libupnp

Date: Tue, 2 Oct 2018 14:29:30 +0200

[Message part 1 (text/plain, inline)]

Hello Marcelo,

On 10/01/2018 11:33 PM, Marcelo Roberto Jimenez wrote:
> If I can help further, please do contact me.

I started to port gmrender-resurrect to 1.8, but I think there are a few
code parts that won't work with 1.8, but that might also be me not
understanding the data model completely.

If you'd take a look at
https://github.com/ukleinek/gmrender-resurrect/commit/ad3c91b9a63e8bf443e56747fc43ff29e92c5414
that would be great.

Thanks
Uwe

[signature.asc (application/pgp-signature, attachment)]

Message #60 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Marcelo Roberto Jimenez <mroberto@users.sourceforge.net>

To: Uwe Kleine-König <uwe@kleine-koenig.org>

Cc: Sebastian Ramacher <sramacher@debian.org>, 884635@bugs.debian.org

Subject: Re: Bug#884635: transition: libupnp

Date: Wed, 3 Oct 2018 20:22:13 -0300

[Message part 1 (text/plain, inline)]

Hi Uwe,

I have make a pull request for your gmrender-resurrect github repo with my
changes.

I also have the aMule port ready. Does anyone knows if they accept patches
in github?

In the case of djmount has an internal frozen libupnp that is compiled
static by default, at least in the repo I cloned in Github, so it should
not be a problem.

Finally, linphone, I did not understand how it uses libupnp since it does
not seem to call libupnp functions. Or I cloned the wrong repo :)

Regards,
Marcelo.


On Tue, Oct 2, 2018 at 9:29 AM Uwe Kleine-König <uwe@kleine-koenig.org>
wrote:

> Hello Marcelo,
>
> On 10/01/2018 11:33 PM, Marcelo Roberto Jimenez wrote:
> > If I can help further, please do contact me.
>
> I started to port gmrender-resurrect to 1.8, but I think there are a few
> code parts that won't work with 1.8, but that might also be me not
> understanding the data model completely.
>
> If you'd take a look at
>
> https://github.com/ukleinek/gmrender-resurrect/commit/ad3c91b9a63e8bf443e56747fc43ff29e92c5414
> that would be great.
>
> Thanks
> Uwe
>
>

[Message part 2 (text/html, inline)]

Message #65 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Bernhard Schmidt <berni@debian.org>

To: Niels Thykier <niels@thykier.net>, 884635@bugs.debian.org

Subject: Re: Bug#884635: transition: libupnp

Date: Thu, 4 Oct 2018 01:42:17 +0200

Hi,

Niels Thykier <niels@thykier.net> wrote:

> Before this transition can start, we will need a solution for amule,
> djmount, gmrender-resurrect and linphone (which is either RM or upload
> with a fix).
>
> Removing all of them leads to the following collateral damage[1]:
>
> """
> Checking reverse dependencies...
> # Broken Depends:
> kopete: kopete
> libosmo-abis: libosmotrau2
>
> # Broken Build-Depends:
> kopete: libmediastreamer-dev (>= 3.6)
>         libortp-dev (>= 0.13)
> libosmo-abis: libortp-dev
> libosmo-netif: libortp-dev
> osmo-bts: libortp-dev
>
> Dependency problem found.
> """
> (I have not researched exactly which package causes what to break; that
> is an exercise left for the reader)

All of these are caused by linphone. We have a really really old
linphone in testing/unstable that has been out-of-date since several
Debian releases. The current version is staged in experimental, the
transition (Bug#891620) is blocked by Kopete which does not build
against a current libmediastreamer (Bug#890606).

There is an upstream bug with patches attached. The first one was just
NULLing additional arguments. Felix Lechner recently created a better
one that still fails compilation. The upstream bug has been open for two
years now, without any significant progress. We've suggested to the
kopete maintainers to drop Jingle support and allow us to proceed, but
no response.

The linphone stack in experimental does not use libupnp anymore as far
as I can see.

If it helps please RM src:linphone from testing, we will rather have
Buster without linphone than with this version.

Bernhard

Message #70 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Uwe Kleine-König <uwe@kleine-koenig.org>

To: Marcelo Roberto Jimenez <mroberto@users.sourceforge.net>

Cc: Sebastian Ramacher <sramacher@debian.org>, 884635@bugs.debian.org, Tobias Frost <tobi@debian.org>

Subject: Re: Bug#884635: transition: libupnp

Date: Thu, 4 Oct 2018 08:20:59 +0200

[Message part 1 (text/plain, inline)]

Hello Marcelo,

On 10/04/2018 01:22 AM, Marcelo Roberto Jimenez wrote:
> I have make a pull request for your gmrender-resurrect github repo with
> my changes.

Yeah, I saw that and already asked the Debian-Maintainer of
gmrender-resurrect to test it. (Though that was in irc so he might have
missed it. Added to Cc:.)

> I also have the aMule port ready. Does anyone knows if they accept
> patches in github?

There is already a patch for amule in the Debian-BTS[1] that is
forwarded to the github issue tracker[2].

> In the case of djmount has an internal frozen libupnp that is compiled
> static by default, at least in the repo I cloned in Github, so it should
> not be a problem.

On Debian the system's libupnp is used. I posted some patches for it,
but it seems upstream is dead and the Debian maintainer too busy with
other stuff.

> Finally, linphone, I did not understand how it uses libupnp since it
> does not seem to call libupnp functions. Or I cloned the wrong repo :)

I remember I looked into linphone once and didn't understand it either.

Best regards
Uwe

[1] https://bugs.debian.org/884996
[2] https://github.com/amule-project/amule/issues/126

[signature.asc (application/pgp-signature, attachment)]

Message #75 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Bernhard Schmidt <berni@debian.org>

To: Uwe Kleine-König <uwe@kleine-koenig.org>, 884635@bugs.debian.org

Subject: Re: Bug#884635: transition: libupnp

Date: Thu, 4 Oct 2018 11:34:45 +0200

In gmane.linux.debian.devel.release, Uwe Kleine-König wrote:

>> Finally, linphone, I did not understand how it uses libupnp since it
>> does not seem to call libupnp functions. Or I cloned the wrong repo :)
> I remember I looked into linphone once and didn't understand it either.

As already stated, the linphone stack in experimental is vastly
different. We'd like to push this to unstable, but are currently
blocked.

The master branch of the git repo contains the current experimental
version, this is probably deeply confusing (updating linphone was
attempted several years ago, that's why master diverged from the code in
unstable)

The upnp code resides in src:mediastreamer2 now, but is not used. I
asked upstream about this and they confirmed.

So if we get this linphone transition sorted out we don't block upnp
anymore. Otherwise feel free to drop from testing.

Bernhard

Message #80 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Felix Lechner <felix.lechner@lease-up.com>

To: 884635@bugs.debian.org

Subject: Linphone block

Date: Thu, 4 Oct 2018 10:40:14 -0700

Hi,

Before removing Linphone, please have a look at the kopete patch I
posted yesterday. [1] Thank you!

Kind regards,
Felix Lechner

[1] https://bugs.debian.org/890606#48

Message #85 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Bernhard Schmidt <berni@debian.org>

To: 884635@bugs.debian.org

Subject: Re: Bug#884635: transition: libupnp

Date: Wed, 10 Oct 2018 12:54:57 +0200

On Thu, Oct 04, 2018 at 11:34:45AM +0200, Bernhard Schmidt wrote:

> >> Finally, linphone, I did not understand how it uses libupnp since it
> >> does not seem to call libupnp functions. Or I cloned the wrong repo :)
> > I remember I looked into linphone once and didn't understand it either.
> 
> As already stated, the linphone stack in experimental is vastly
> different. We'd like to push this to unstable, but are currently
> blocked.
> 
> The master branch of the git repo contains the current experimental
> version, this is probably deeply confusing (updating linphone was
> attempted several years ago, that's why master diverged from the code in
> unstable)
> 
> The upnp code resides in src:mediastreamer2 now, but is not used. I
> asked upstream about this and they confirmed.
> 
> So if we get this linphone transition sorted out we don't block upnp
> anymore. Otherwise feel free to drop from testing.

So, there is now a patch for kopete in Bug#890606 that would allow the
linphone transition in Bug#891620 to happen which would in turn get
linphone out of the way for upnp.

Bernhard

Message #90 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Uwe Kleine-König <uwe@kleine-koenig.org>

To: Sebastian Ramacher <sramacher@debian.org>, 884635@bugs.debian.org

Cc: James Cowgill <jcowgill@debian.org>

Subject: Re: Bug#884635: transition: libupnp

Date: Tue, 23 Oct 2018 09:48:30 +0200

[Message part 1 (text/plain, inline)]

Hello Sebastian,

On 09/30/2018 10:09 AM, Sebastian Ramacher wrote:
> On 2017-12-22 22:38:23, Uwe Kleine-König wrote:
>> On Sun, Dec 17, 2017 at 10:07:16PM +0100, Uwe Kleine-König wrote:
>>> Currently there are two versions of libupnp in the archive:
>>>
>>>  - src:libupnp providing the 1.6.x branch of libupnp which is considered
>>>    legacy by upstream
>>>  - src:pupnp-1.8 providing the 1.8.x branch of libupnp
> 
> The list of open issues is down to:
> 
>>  - amule
>>    - FTBFS #884996 (patch)

The patch was forwarded
(https://github.com/amule-project/amule/issues/126), no response so far.
The patch needs libupnp-1.6.25 or ..-1.8 which are both available in Debian.

>>  - djmount
>>    - FTBFS #884243

The upstream maintainer doesn't care any more and the Debian maintainer
wrote in May "I lack of free time right now, but will engage on this as
soon as I can.". Nothing happend so far.

>>  - gmrender-resurrect
>>    - FTBFS #884246

upnp-upstream supported here to come up with a patch. gmrender-resurrect
was recently uploaded and not build-depends on libupnp1.8-dev and so is
out of the hot path for this transition.

>>  - linphone
>>    - FTBFS #884247

Fixed in unstable.

> Those still fail to build.
> 
>>  - gmediaserver
>>    - FTBFS #884245
> 
> RM requested.

It would be great if
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=0;dist=unstable;ordering=normal;repeatmerged=0;src=gmediaserver
included this bug (#904833).

> Considering that those packages had over 9 months to get fixed, I think we
> should start the transition and RM the unfixed packages from testing.

+1

I don't know what needs to be done from my side. I guess James and I
have to prepare an upload of libupnp6 and libupnp1.8 where the
libupnp-dev package moves from the former to the latter? According to
https://wiki.debian.org/Teams/ReleaseTeam/Transitions we should wait for
an ACK by the release team. Should I upload libupnp6 with libupnp-dev
dropped to experimental? (pupnp-1.8 is in experimental providing
libupnp-dev already.)

Best regards
Uwe

[signature.asc (application/pgp-signature, attachment)]

Message #97 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Sebastian Ramacher <sramacher@debian.org>

To: Niels Thykier <niels@thykier.net>

Cc: Uwe Kleine-König <uwe@kleine-koenig.org>, 884635@bugs.debian.org

Subject: Re: Bug#884635: transition: libupnp

Date: Fri, 2 Nov 2018 12:03:35 +0100

[Message part 1 (text/plain, inline)]

Control: forwarded -1 https://release.debian.org/transitions/html/libupnp.html

Hi Niels

On 2018-10-02 05:34:00, Niels Thykier wrote:
> Uwe Kleine-König:
> > Hello,
> > 
> > adding Marcelo (upstream for libupnp) to recipents.
> > 
> > On 09/30/2018 10:09 AM, Sebastian Ramacher wrote:
> >> On 2017-12-22 22:38:23, Uwe Kleine-König wrote:
> >>> Hello,
> >>>
> >>> On Sun, Dec 17, 2017 at 10:07:16PM +0100, Uwe Kleine-König wrote:
> >>>> Currently there are two versions of libupnp in the archive:
> >>>>
> >>>>  - src:libupnp providing the 1.6.x branch of libupnp which is considered
> >>>>    legacy by upstream
> >>>>  - src:pupnp-1.8 providing the 1.8.x branch of libupnp
> >>>>
> >>>> I want to get rid of libupnp6 converting all rdeps to the newer libupnp
> >>>> package.
> >>>
> >>> ...
> >>
> >> The list of open issues is down to:
> >>
> >>>  - amule
> >>>    - FTBFS #884996 (patch)
> >>>  - djmount
> >>>    - FTBFS #884243
> >>>  - gmrender-resurrect
> >>>    - FTBFS #884246
> >>>  - linphone
> >>>    - FTBFS #884247
> >>
> >> Those still fail to build.
> >>
> >>>  - gmediaserver
> >>>    - FTBFS #884245
> >>
> >> RM requested.
> > (RM = Request to remove the package from testing)
> > 
> >> Considering that those packages had over 9 months to get fixed, I think we
> >> should start the transition and RM the unfixed packages from testing.
> > 
> > The bug for gmrender-resurrect is tagged "help". I didn't look into that
> > but I think it would be fair to check this one at least before starting
> > to remove packages. I'll give it a bump in my todo list.
> > 
> > @Marcelo: Do you care to look into https://bugs.debian.org/884246 ?
> > 
> > Best regards
> > Uwe
> > 
> 
> Hi,
> 
> Before this transition can start, we will need a solution for amule,
> djmount, gmrender-resurrect and linphone (which is either RM or upload
> with a fix).
> 
> Removing all of them leads to the following collateral damage[1]:
> 
> """
> Checking reverse dependencies...
> # Broken Depends:
> kopete: kopete
> libosmo-abis: libosmotrau2
> 
> # Broken Build-Depends:
> kopete: libmediastreamer-dev (>= 3.6)
>         libortp-dev (>= 0.13)
> libosmo-abis: libortp-dev
> libosmo-netif: libortp-dev
> osmo-bts: libortp-dev
> 
> Dependency problem found.
> """
> (I have not researched exactly which package causes what to break; that
> is an exercise left for the reader)
> 
> Accordingly, if we plan on removing these packages, their dependencies
> are now also a part of the transition (having to move away from the
> packages being removed or being removed themselves - the latter leading
> to a rinse-and-repeat effect).
> 
> So:
> 
>  * Which of amule, djmount, gmrender-resurrect, linphone are going to
>    be fixed/removed?

djmount and linux-igd would get removed:

% dak rm -Rn -s buster djmount linux-igd
Will remove the following packages from buster:

   djmount |   0.71-7.1 | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
 linux-igd | 1.0+cvs20070630-6 | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x

Maintainer: Debian QA Group <packages@qa.debian.org>, Dario Minnucci <midget@debian.org>

------------------- Reason -------------------

----------------------------------------------

Checking reverse dependencies...
No dependency problem found.


If not fixed by the maintainer, we'll NMU amule. gerbera needs a sourceful
upload in any case to switch back to libupnp-dev. All the other issues have been
fixed.

Cheers

> 
>  * What is and how do we handle the collateral (if any) from any
>   removals?
> 
> Thanks,
> ~Niels
> 
> 
> [1]:
> dak rm -nR -s testing amule djmount gmrender-resurrect \
>   linphone gmediaserver
> 
> Can be run from respighi.debian.org, which is DD-accessible.
> 

-- 
Sebastian Ramacher

[signature.asc (application/pgp-signature, inline)]

Message #104 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Uwe Kleine-König <uwe@kleine-koenig.org>

To: Sebastian Ramacher <sramacher@debian.org>, Niels Thykier <niels@thykier.net>

Cc: 884635@bugs.debian.org

Subject: Re: Bug#884635: transition: libupnp

Date: Fri, 2 Nov 2018 12:12:57 +0100

[Message part 1 (text/plain, inline)]

Hello,

On 11/02/2018 12:03 PM, Sebastian Ramacher wrote:
> If not fixed by the maintainer, we'll NMU amule. gerbera needs a sourceful
> upload in any case to switch back to libupnp-dev. All the other issues have been
> fixed.

gmrender-resurrect would need to switch back to libupnp-dev, too. It was
switched to libupnp1.8-dev when fixing #884246 (see
https://release.debian.org/transitions/html/auto-pupnp-1.8.html)

Other than that I agree with Sebastian that all blockers are gone (and
djmount and linux-igd should be removed).

Best regards
Uwe

[signature.asc (application/pgp-signature, attachment)]

Message #109 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Uwe Kleine-König <uwe@kleine-koenig.org>, 884635@bugs.debian.org, Sebastian Ramacher <sramacher@debian.org>

Subject: Re: Bug#884635: transition: libupnp

Date: Mon, 5 Nov 2018 16:37:24 +0100

Control: tags -1 confirmed

On 02/11/2018 12:12, Uwe Kleine-König wrote:
> Hello,
> 
> On 11/02/2018 12:03 PM, Sebastian Ramacher wrote:
>> If not fixed by the maintainer, we'll NMU amule. gerbera needs a sourceful
>> upload in any case to switch back to libupnp-dev. All the other issues have been
>> fixed.
> 
> gmrender-resurrect would need to switch back to libupnp-dev, too. It was
> switched to libupnp1.8-dev when fixing #884246 (see
> https://release.debian.org/transitions/html/auto-pupnp-1.8.html)
> 
> Other than that I agree with Sebastian that all blockers are gone (and
> djmount and linux-igd should be removed).

Please get this started, and bump the bug severities to serious.

Cheers,
Emilio

Message #116 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Uwe Kleine-König <uwe@kleine-koenig.org>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 884635@bugs.debian.org, Sebastian Ramacher <sramacher@debian.org>, James Cowgill <jcowgill@debian.org>, Sandro Tosi <morph@debian.org>

Subject: Re: Bug#884635: transition: libupnp

Date: Mon, 5 Nov 2018 18:28:21 +0100

[Message part 1 (text/plain, inline)]

Hello Emilio,

[adding jcowgill to recipients]

On 11/05/2018 04:37 PM, Emilio Pozuelo Monfort wrote:
> Please get this started, and bump the bug severities to serious.

I never did a transition before, so I'm not entirely clear what should
happen now.

The following steps should be done:

a) upload pupnp-1.8 providing libupnp-dev to unstable
b) rebuild reverse dependencies of libupnp-dev
c) remove src:libupnp from unstable
d) remove src:libupnp from testing
e) remove the binary packages of src:libupnp from unstable
f) remove the binary packages of src:libupnp from testing
g) for b in 884243 884996 912066 885025; do bts severity $b serious;done
h) remove djmount and linux-igd from unstable and testing
i) apply patch from 884996 to amule and upload to unstable

I'm not sure about the order, I think jcowgill is supposed to care for
a) and can then do g) directly after that. Does b) - f) happen
automatically? Maybe only after g)?

@morph: Do you care for i)?

Best regards
Uwe

[signature.asc (application/pgp-signature, attachment)]

Message #121 received at 884635@bugs.debian.org (full text, mbox, reply):

From: James Cowgill <jcowgill@debian.org>

To: Uwe Kleine-König <uwe@kleine-koenig.org>

Cc: Emilio Pozuelo Monfort <pochu@debian.org>, 884635@bugs.debian.org, Sebastian Ramacher <sramacher@debian.org>, Sandro Tosi <morph@debian.org>

Subject: Re: Bug#884635: transition: libupnp

Date: Mon, 5 Nov 2018 17:58:22 +0000

[Message part 1 (text/plain, inline)]

Hi,

On 05/11/2018 17:28, Uwe Kleine-König wrote:
> Hello Emilio,
> 
> [adding jcowgill to recipients]
> 
> On 11/05/2018 04:37 PM, Emilio Pozuelo Monfort wrote:
>> Please get this started, and bump the bug severities to serious.
> 
> I never did a transition before, so I'm not entirely clear what should
> happen now.
> 
> The following steps should be done:
> 
> a) upload pupnp-1.8 providing libupnp-dev to unstable
> b) rebuild reverse dependencies of libupnp-dev
> c) remove src:libupnp from unstable
> d) remove src:libupnp from testing
> e) remove the binary packages of src:libupnp from unstable
> f) remove the binary packages of src:libupnp from testing
> g) for b in 884243 884996 912066 885025; do bts severity $b serious;done
> h) remove djmount and linux-igd from unstable and testing
> i) apply patch from 884996 to amule and upload to unstable

Yeah we can start this transition now that 1.8.4 was released (which
resolved the ABI related issues). I'll upload it soon.

The order is this:

a) I upload pupnp-1.8 (which "hijacks" libupnp-dev from src:libupnp)
g) Update bug severities
b) binNMU all rdeps of libupnp-dev
[time passes]
i) NMU amule / any other package if not fixed soon
[time passes - eventually all broken rdeps are autoremoved from testing]
d and f) Happen automatically at this point
[transition complete (with respect to testing)]
h) File requests to remove remaining packages
c and e) File request to remove src:libupnp

James

[signature.asc (application/pgp-signature, attachment)]

Message #126 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Uwe Kleine-König <uwe@kleine-koenig.org>

To: James Cowgill <jcowgill@debian.org>

Cc: Emilio Pozuelo Monfort <pochu@debian.org>, 884635@bugs.debian.org, Sebastian Ramacher <sramacher@debian.org>, Sandro Tosi <morph@debian.org>

Subject: Re: Bug#884635: transition: libupnp

Date: Wed, 7 Nov 2018 12:03:19 +0100

[Message part 1 (text/plain, inline)]

Hello James,

On 11/5/18 6:58 PM, James Cowgill wrote:
> Hi,
> 
> On 05/11/2018 17:28, Uwe Kleine-König wrote:
>> Hello Emilio,
>>
>> [adding jcowgill to recipients]
>>
>> On 11/05/2018 04:37 PM, Emilio Pozuelo Monfort wrote:
>>> Please get this started, and bump the bug severities to serious.
>>
>> I never did a transition before, so I'm not entirely clear what should
>> happen now.
>>
>> The following steps should be done:
>>
>> a) upload pupnp-1.8 providing libupnp-dev to unstable
>> b) rebuild reverse dependencies of libupnp-dev
>> c) remove src:libupnp from unstable
>> d) remove src:libupnp from testing
>> e) remove the binary packages of src:libupnp from unstable
>> f) remove the binary packages of src:libupnp from testing
>> g) for b in 884243 884996 912066 885025; do bts severity $b serious;done
>> h) remove djmount and linux-igd from unstable and testing
>> i) apply patch from 884996 to amule and upload to unstable
> 
> Yeah we can start this transition now that 1.8.4 was released (which
> resolved the ABI related issues). I'll upload it soon.
> 
> The order is this:
> 
> a) I upload pupnp-1.8 (which "hijacks" libupnp-dev from src:libupnp)
> g) Update bug severities

Given that a) and g) is done now ...

> b) binNMU all rdeps of libupnp-dev

do we need to do anything here by hand? Note that

	https://release.debian.org/transitions/html/libupnp.html

lists linphone as dependency, but the version in unstable doesn't depend
on libupnp (at least not via an explicit B-D).

> [time passes]
> i) NMU amule / any other package if not fixed soon
> [time passes - eventually all broken rdeps are autoremoved from testing]
> d and f) Happen automatically at this point
> [transition complete (with respect to testing)]
> h) File requests to remove remaining packages
> c and e) File request to remove src:libupnp

Thanks
Uwe

[signature.asc (application/pgp-signature, attachment)]

Message #131 received at 884635@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Uwe Kleine-König <uwe@kleine-koenig.org>, James Cowgill <jcowgill@debian.org>

Cc: 884635@bugs.debian.org, Sebastian Ramacher <sramacher@debian.org>, Sandro Tosi <morph@debian.org>

Subject: Re: Bug#884635: transition: libupnp

Date: Wed, 7 Nov 2018 19:07:02 +0100

On 07/11/2018 12:03, Uwe Kleine-König wrote:
> Hello James,
> 
> On 11/5/18 6:58 PM, James Cowgill wrote:
>> Hi,
>>
>> On 05/11/2018 17:28, Uwe Kleine-König wrote:
>>> Hello Emilio,
>>>
>>> [adding jcowgill to recipients]
>>>
>>> On 11/05/2018 04:37 PM, Emilio Pozuelo Monfort wrote:
>>>> Please get this started, and bump the bug severities to serious.
>>>
>>> I never did a transition before, so I'm not entirely clear what should
>>> happen now.
>>>
>>> The following steps should be done:
>>>
>>> a) upload pupnp-1.8 providing libupnp-dev to unstable
>>> b) rebuild reverse dependencies of libupnp-dev
>>> c) remove src:libupnp from unstable
>>> d) remove src:libupnp from testing
>>> e) remove the binary packages of src:libupnp from unstable
>>> f) remove the binary packages of src:libupnp from testing
>>> g) for b in 884243 884996 912066 885025; do bts severity $b serious;done
>>> h) remove djmount and linux-igd from unstable and testing
>>> i) apply patch from 884996 to amule and upload to unstable
>>
>> Yeah we can start this transition now that 1.8.4 was released (which
>> resolved the ABI related issues). I'll upload it soon.
>>
>> The order is this:
>>
>> a) I upload pupnp-1.8 (which "hijacks" libupnp-dev from src:libupnp)
>> g) Update bug severities
> 
> Given that a) and g) is done now ...
> 
>> b) binNMU all rdeps of libupnp-dev
> 
> do we need to do anything here by hand?

binNMUs scheduled.

> Note that
> 
> 	https://release.debian.org/transitions/html/libupnp.html
> 
> lists linphone as dependency, but the version in unstable doesn't depend
> on libupnp (at least not via an explicit B-D).

That should be because of the old cruft packages. You can ignore it.

gmrender-resurrect and gerbera need to update their build-dep to libupnp-dev

Cheers,
Emilio

Message #140 received at 884635-submitter@bugs.debian.org (full text, mbox, reply):

From: Jonathan Wiltshire <jmw@debian.org>

To: control@bugs.debian.org

Cc: 866335-submitter@bugs.debian.org, 877168-submitter@bugs.debian.org, 881718-submitter@bugs.debian.org, 884635-submitter@bugs.debian.org, 885420-submitter@bugs.debian.org, 886237-submitter@bugs.debian.org, 888438-submitter@bugs.debian.org, 900111-submitter@bugs.debian.org, 906643-submitter@bugs.debian.org, 909412-submitter@bugs.debian.org

Subject: closing 877168, closing 866335, closing 881718, closing 884635, closing 885420, closing 886237 ...

Date: Sun, 11 Aug 2019 13:42:24 +0100

close 877168 
close 866335 
close 881718 
close 884635 
close 885420 
close 886237 
close 888438 
close 906643 
close 900111 
close 909412 
thanks

This transition was completed.

Send a report that this bug log contains spam.