El jueves, 26 de julio de 2018 11:16:10 -03 Raphael Hertzog escribió:
> Control: tag -1 pending
>
> Hello all,
Hello! Good to read you again!
> we have made good progress on the pyside2 packaging. Yesterday we
> had working packages built against Qt 5.10 that we managed to use to
> rebuild freecad and the application was working.
>
> We worked in our own repository at the start:
> https://salsa.debian.org/freexian-team/pyside2
>
> But I just pushed this to the team's official repository. You are more
> than welcome to review the package. The upstream build system is based
> on Python's setup.py but it then executes lots of custom code relying on
> cmake to build everything.
>
> We use pybuild because it does the right thing to build against the
> various Python versions but the upstream installation procedure is not
> really able to cope with the logic of building the same thing for
> different python versions and then installing the different set of file.
>
> So we just used dh_install (and not pybuild's install procedure) to install
> the files out of some intermediate directories used by upstream. We
> used dh-exec to be able to install in multi-arch directories via
> dh_install.
>
> I hope the package will continue to build once the Qt 5.11 transition is
> over, right now it doesn't because unstable is in flux with the transition
> that just started. It might build against experimental, I haven't tried.
I'm not a python packager, but what you describe sounds good. I'll try to take
a look after I deal with various FTBFSs in the current transition.
> On Fri, 11 May 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> > It is worth to note that pyside2 will probably use some Qt's private
> > headers.
> We do depend on qtbase5-private-dev, right.
And qtdeclarative5-private-dev, which explains the dependency listed below.
> > - If Pyside2 uses private headers it will end up depending in
> > qt<foo>-abi-x-y- z, that's the way we track packages using private
> > headers (which includes qt submodules) and allows us to do very smooth
> > transitions whenever possible. That only means that it will need to get
> > rebuilt whenever we ship a new upstream version.
>
> Some of the generated packages depend on "qtdeclarative-abi-x-y-z". That's
> the only occurrence of this pattern.
Well, it's strange that you build depend upon qtbase5-private-dev and do not
end up depending on qtbase-abi-x-y-z. Except maybe the created binary is
discarded in the process, like a test needing qtbase's internals.
> > All that being said, if the package is kept under qt/ following our repo
> > style it's easier for us to jump in in case it's needed (for example, if
> > we are
> That's definitely the goal here. I have no long term interest here. The
> initial packaging of pyside has been funded by a customer who is using
> freecad and wanted to keep the package in Debian. We will continue
> to help for as long as the customer is willing to pay our work but
> we definitely want the package to be under the team's umbrella so that
> it survives our efforts.
One of the reasons we did not package pyside2 was that none of us had the
interest/could afford the extra time. But then again if the above situation
arises is like when any of us can't keep on maintaining a package for
<reasons>, so better than nothing, and much welcomed.
> On Sat, 12 May 2018, Maximiliano Curia wrote:
> > I've created: https://salsa.debian.org/qt-kde-team/qt/pyside2
>
> Pushed our work here.
>
> > They are somewhat documented in http://pkg-kde.alioth.debian.org/, I would
> > say: http://pkg-kde.alioth.debian.org/gitguidelines.html -> but the
> > tagging
>
> This moved here:
> https://qt-kde-team.pages.debian.net/
> https://qt-kde-team.pages.debian.net/gitguidelines.html
>
> I honestly find those policies very counter-productive with a high
> setup cost and lots of divergence compared to usual practices in most
> other teams.
To be honest our team's practices exists from before most teams got usual
practices, and gbp was created.
I think none of us use the "git tricks" described there, just keep the debian/
stuff and unpack the tarballs.
> Anyway, I can stick to them for this package but right
> now I'm maintaining pyside2 with git-buildpackage in a usual
> merged-with-upstream branch and I will just cherry-pick my changes
> to the debian-only branch pushed to your repository.
That sounds just like the right thing to do if you prefer gbp. And it's
actually nice to read that you could follow your (almost) normal workflow non
the less :-)
> BTW, the policy of requiring a changelog entry in each commit goes very
> much again the stated goal of "reduce conflicts in debian/changelog when
> cherry-picking and merging between branches".
I didn't know that goal to be honest. But this has worked pretty well for us
so far. I think I need to make a note here: we usually do not add changelog
entries for stuff like running wrap-and-sort, but we do ask for one commit per
functionality change, to call it somehow.
Thanks for the follow up!
--
Background: talking about Nokia's aquisition of Trolltech.
<mukidohime> That's why there's the FreeQt agreement, a poison pill against
just that sort of thing.
...
<MoDaX> mukidohime: agreements can be broken
<mukidohime> MoDaX: Yes, with a massive lawsuit following soon after.
<mukidohime> If Nokia pulled something like that, aseigo would entirely pull
some sort of dragonball Z-esque maneuver, and it would probably
be visible from the ISS.
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Attachment:
signature.asc
Description: This is a digitally signed message part.