Mailing List Archive: Maemo: Developers

Autobuilder repository priority ?

1 2

View All

Index | Next | Previous | View Threaded

maemo at csipa

Nov 3, 2009, 8:20 AM

Post #26 of 33 (625 views)
Permalink

Re: Autobuilder repository priority ? [In reply to]

On Tuesday 03 November 2009 16:30:26 you wrote:
> I'm interested to know what problems you are having with python-dbus.
> Can you please fill a bug report under
> https://bugs.maemo.org/enter_bug.cgi?product=PyMaemo ?
>
> And last but not the least, the python-dbus version you are referring
> (-1maemo3) is not supposed to be "unstable". We had no bug reports
> about it, so if you are having problems with it, please report a bug
> so we can fix it ASAP.

No, not unstable as in buggy, there is nothing 'wrong' with python-dbus per
se, it's the policies in combination with the changes that trigger the
problem. You changed some paths in -1maemo3 compared to -1maemo0. That's not
really a bug, but it *is* a non-backwards compatible change, as a
debian/mypackage.install can fail miserably if it refers to the wrong paths.
If I use the paths from -1maemo0, the autobuilder fails. If I use the paths
from -1maemo3, autobuilder is OK, but I can't promote the package.
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

maemo at csipa

Nov 3, 2009, 8:20 AM

Post #27 of 33 (623 views)
Permalink

Re: Autobuilder repository priority ? [In reply to]

On Tuesday 03 November 2009 14:23:10 Jeremiah Foster wrote:
> > As I understood Attila he proposed to create separate autobulder
> > incoming queue for Extras updates.
>
> Ah, a separate build queue.
>
> > If packages are uploaded to this queue they're built using only Extras
> > and SDK repos and put into extras-devel.
>
> So no extra repository needed?

Well, if we can guarantee that a trivial error causing a bad build does not
wipe out the package to be updated and wreak havoc on it's dependencies + we
don't need a staging repo that would serve as a base for promote (maybe after
a cursory glance at a diff/changelog of powers that be ?), then a queue is
just as fine.

Regards,
Attila
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

maemo at csipa

Nov 3, 2009, 8:37 AM

Post #28 of 33 (624 views)
Permalink

Re: Autobuilder repository priority ? [In reply to]

On Tuesday 03 November 2009 14:08:25 Jeremiah Foster wrote:
> Yes. As I see it, this might be the core of the problem: overlapping
> repositories preventing package promotion. For example, if python2.5-
> dbus is a 'depends', you cannot build the package for Extras.
> Am I understanding this correctly?
> Can you use another dependency to get the same functionality?
> Can you declare in your control file that a specific version of
> python2.5-dbus be used?
> Can we change the conflict that is preventing python2.5-dbus from
> being used?
> My hunch is that there may be a way to solve this specific case with
> the tools we now have. If we can't we have to look at how we fix it
> and like Graham says we may be able to find our own path and maybe an
> update repository is the way to go.

I will try to dig up the failed build log but I had two problems which
exacerbated each other.

a) A dependency problem. I would have to look up the exact build depends line,
but having a (non-version specific) python2.5-dbus dependency did not work
out (I suspect that some of my other (sub)dependencies caused a non-apt
solvable dependency loop).

b) Build problem. As mentioned in my previous mail to Anderson, python-dbus
changed some paths between the versions in the SDK and in extras-devel. This
caused an either-you-build-with-one-or-the-other situation for this
particular package of mine. This is also why I cannot put a versioned
dependency in there. It would be very dangerous for me to put in a fixed
dependency on the SDK python-dbus, as then when promotion time comes for the
new python-dbus, apt would not update it (as my package will hold on to the
old one).
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

anderson.lizardo at openbossa

Nov 3, 2009, 9:58 AM

Post #29 of 33 (619 views)
Permalink

Re: Autobuilder repository priority ? [In reply to]

On Tue, Nov 3, 2009 at 12:20 PM, Attila Csipa <maemo [at] csipa> wrote:
> On Tuesday 03 November 2009 16:30:26 you wrote:
>> I'm interested to know what problems you are having with python-dbus.
>> Can you please fill a bug report under
>> https://bugs.maemo.org/enter_bug.cgi?product=PyMaemo ?
>>
>> And last but not the least, the python-dbus version you are referring
>> (-1maemo3) is not supposed to be "unstable". We had no bug reports
>> about it, so if you are having problems with it, please report a bug
>> so we can fix it ASAP.
>
> No, not unstable as in buggy, there is nothing 'wrong' with python-dbus per
> se, it's the policies in combination with the changes that trigger the
> problem. You changed some paths in -1maemo3 compared to -1maemo0. That's not
> really a bug, but it *is* a non-backwards compatible change, as a
> debian/mypackage.install can fail miserably if it refers to the wrong paths.
> If I use the paths from -1maemo0, the autobuilder fails. If I use the paths
> from -1maemo3, autobuilder is OK, but I can't promote the package.

Can you be more specific? Which paths are those? How does this affect
your package?

Did you mean "-1maemo1" instead of "-1maemo0"? (there is no maemo0 IIRC)

Why can't you promote the package using -1maemo3?

Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

maemo at csipa

Nov 3, 2009, 12:31 PM

Post #30 of 33 (615 views)
Permalink

Re: Autobuilder repository priority ? [In reply to]

Foreword: My particular problem is not that big of an issue, in the end I went
for extras-devel compatibility, no big deal, it's not yet for end users
anyway. It's the generic approach that is at question here - tomorrow someone
else will fall through the same manhole and it might become a recurring issue.

On Tuesday 03 November 2009 18:58:04 Anderson Lizardo wrote:
> Did you mean "-1maemo1" instead of "-1maemo0"? (there is no maemo0 IIRC)

Yes, indeed, -1maemo1. To add to the confusion there *IS* a python2.5-0maemo0
in *extras-testing* (see http://maemo.org/packages/view/python2.5-dbus/ )

> Can you be more specific? Which paths are those? How does this affect
> your package?

Okay, I backtracked my steps as far as I could, and it *seems* the actual
source of the problem is python-support (which I pull in through python-dbus).
1maemo1 (from the SDK) pulls in python-support 0.6.4 (from the SDK). 1maemo3,
on the other hand, pulls in python-support 1.0.2maemo1 (from extras-devel).
Depending on which python-support module got pulled in, the paths for the dbus
module change:

The sdk version's
/var/lib/python-support/python2.5/dbus

in extras-devel becomes
/usr/lib/pymodules/python2.5/dbus

This affects my package as I have a .install file that looks like this
(inherited from upstream):

debian/python2.5-qt4-dbus.install:
var/lib/python-support/python2.5/dbus

And since the paths change, the .so will go (or rather won't go, as the
autobuilder bombs) to the wrong path. Yes, I know, I can introduce a
downstream patchset and start depending on python-support myself, but that is
not the point here. :)

> Why can't you promote the package using -1maemo3?

See the path problem above.

_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

anderson.lizardo at openbossa

Nov 4, 2009, 4:51 AM

Post #31 of 33 (599 views)
Permalink

Re: Autobuilder repository priority ? [In reply to]

On Tue, Nov 3, 2009 at 4:31 PM, Attila Csipa <maemo [at] csipa> wrote:
> On Tuesday 03 November 2009 18:58:04 Anderson Lizardo wrote:
>> Can you be more specific? Which paths are those? How does this affect
>> your package?
>
> Okay, I backtracked my steps as far as I could, and it *seems* the actual
> source of the problem is python-support (which I pull in through python-dbus).
> 1maemo1 (from the SDK) pulls in python-support 0.6.4 (from the SDK). 1maemo3,
> on the other hand, pulls in python-support 1.0.2maemo1 (from extras-devel).
> Depending on which python-support module got pulled in, the paths for the dbus
> module change:
> [...]

This path has changed due to the new python-support 1.0.2 version.
They decided to change this path for some reason. Unfortunately, we
can't keep compatibility in this case, as it was an upstream change.
Ideally, your package should not depend on that path being the same
forever.

In my opinion, the best way to handle it is to have your package
Build-Depend on python-support (>= 1.0.2maemo1), given that you rely
on this private path (which BTW comes from "installedpath" variable in
/usr/share/python-support/private/movemodules).

> And since the paths change, the .so will go (or rather won't go, as the
> autobuilder bombs) to the wrong path. Yes, I know, I can introduce a
> downstream patchset and start depending on python-support myself, but that is
> not the point here. :)

I can see that it is not the main point of the discussion (I myself
had problems with some broken libraries being uploaded to extras-devel
that "shadowed" working ones from the SDK), but keep in mind that in
case of any python* packages in the SDK, it is legitimate for the
PyMaemo team to upload up-to-date versions to the extras*
repositories, and you should not rely on any Python packages that come
from the SDK tools repository when doing Python development on Maemo,
as they are outdated and they are there just for satisfying
dependencies of some SDK tools.

Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

maemo at csipa

Feb 10, 2010, 12:47 AM

Post #32 of 33 (375 views)
Permalink

Re: Autobuilder repository priority ? [In reply to]

On Tuesday 03 November 2009 21:31:29 Attila Csipa wrote:
> Foreword: My particular problem is not that big of an issue, in the end I
> went for extras-devel compatibility, no big deal, it's not yet for end
> users anyway. It's the generic approach that is at question here - tomorrow
> someone else will fall through the same manhole and it might become a
> recurring issue.

And yes, I got oopsed by this again, but this time around it's worse (hence my
unzmbification of this thread). My package was already in the testing
quarantine when somebody else promoted a package depending on it. As a result,
new versions of my dependencies from -devel got silently promoted to -testing,
so when I promoted my package, unbeknowst to me, I was actually promoting the
packages from -devel. But wait, the plot thickens ! As we only had overlapping
dependencies with the other project, this means now I also have not only stuff
from -devel in Extras, but actually a funky mix of versions, something nobody
tested for. The worst part is I cannot make a quick fix as it would have to go
(again) through the 10 day quarantine. Please, let's reconsider the
promotion/repository logic as per the ancient thread this message belongs to.
Thank you :)

Regards,
Attila
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

niels at maemo

Feb 10, 2010, 1:03 AM

Post #33 of 33 (375 views)
Permalink

Re: Autobuilder repository priority ? [In reply to]

> On Tuesday 03 November 2009 21:31:29 Attila Csipa wrote:
>
>> Foreword: My particular problem is not that big of an issue, in the end
>> I
>> went for extras-devel compatibility, no big deal, it's not yet for end
>> users anyway. It's the generic approach that is at question here -
>> tomorrow someone else will fall through the same manhole and it might
>> become a recurring issue.
>
> And yes, I got oopsed by this again, but this time around it's worse
> (hence my
> unzmbification of this thread). My package was already in the testing
> quarantine when somebody else promoted a package depending on it. As a
> result, new versions of my dependencies from -devel got silently promoted
> to -testing, so when I promoted my package, unbeknowst to me, I was
> actually promoting the packages from -devel. But wait, the plot thickens !
> As we only had overlapping
> dependencies with the other project, this means now I also have not only
> stuff from -devel in Extras, but actually a funky mix of versions,
> something nobody tested for. The worst part is I cannot make a quick fix
> as it would have to go (again) through the 10 day quarantine. Please,
> let's reconsider the promotion/repository logic as per the ancient thread
> this message belongs to. Thank you :)
>
This problem stems from the fact that we don't have real maintainers for
packages. In the past anybody could move packages to extras, the new
process changed that. But to make it not too complicated the whole
automatic promotion of dependencies was introduced.

As part of the growing up, we need to move towards a more formalized way
of maintaining of packages. In current February Sprint, I have a task
(10.02-12) to create a proper maintainer interface. As part of that task I
want to implement promotion of dependencies only if they are owned by you
or don't have a maintainer.

This needs to be refined more, I hope to have time to work on this this
month. Not promising that it will be finished this month as there is a lot
going on.

>
> Regards,
> Attila

--
Niels Breet
maemo.org webmaster

_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads