I'm planning on building a new version of PySide2 as it contains a lot of
bug fixes. Nothing appears to depend on it yet so shouldn't cause any
issues and I want to get the latest release built before porting over
freecad and the two consumers of PySide1.
I agree that subpackages for py2 and py3 seems best, but I'll have to
see if mercurial can be parallel installed without too much effort.
I don't expect to have time to work on this for the next 2 weeks.
On Sun, Aug 18, 2019 at 9:16 PM Mads Kiilerich <mads(a)kiilerich.com> wrote:
> You are giving many good reasons why we need Mercurial packages for
> Python 2 and Python 3, side by side.
> That will make it possible for other packages to jump to Python 3. Your
> package will no longer be blocking, and it doesn't have to be your concern.
> It will also put the Mercurial package in the good position where it has
> done all the work of transitioning, and the python2 part will be
> entirely optional, only kept alive for benefit of other packages that
> still depend on it.
> I am working upstream with tortoisehg. While late, I don't expect any
> problems. The current blocker for Fedora packaging of tortoisehg is the
> lack of Python 3 Mercurial, and the biggest risk is that the Python 2
> Mercurial package goes away before I had time to transition the
> tortoisehg package to depend on Python 3 Mercurial.
> On 8/16/19 3:53 PM, Neal Becker wrote:
> > I think tortoisehg is not ported to python3
> > On Wed, Aug 14, 2019 at 1:39 PM Neal Becker <ndbecker2(a)gmail.com> wrote:
> >> I just tested hg-5.1.0 with the latest git version of hg-evolve on
> >> python3 and at least some basic things seem to be working. One
> >> problem:
> >> hg
> >> *** failed to import extension hggit: No module named 'compat'
> >> That's with the latest pip version of hg-git (0.8.12).
> >> hg-git is a supported fedora package, so I think we need this to work.
> >> On Tue, Aug 13, 2019 at 9:35 AM Petr Stodulka <pstodulk(a)redhat.com> wrote:
> >>> On 12. 08. 19 22:36, Miro Hrončok wrote:
> >>>> On 12. 08. 19 20:37, Petr Stodulka wrote:
> >>>>> Can you explain better what do you mean by that? I am little lost
> >>>>> here.
> >>>> Sure. The idea was:
> >>>> 1) When Fedora 31 is branched (scheduled for tomorrow ), push the switch to rawhide (Fedora 32)
> >>>> 2) See what happens, collect feedback.
> >>>> 3) Soon before F31 Beta Freeze (scheduled for 2019-08-29 ) decide whether this is worth pushing to F31 (probably not)
> >>>> 4) Soon before F32 mass Python 2 removal flag day (scheduled for mid November ), decide whether to revert and request and exception or not
> >>>>  https://fedoraproject.org/wiki/Releases/31/Schedule
> >>>>  https://fedoraproject.org/wiki/Changes/RetirePython2#Detailed_Description
> >>> Thanks Miro for explanation. That sounds asi the best idea now probably. From that point, I will not create new subpackages for Py2 / Py3 and I will just do the switch tomorrow.
> >>> @mercurial-maintainers: if anyone have something against or better solution, answer here guys, otherwise I will do the rebase.
> >>> Just FYI, I will be kinda offline between 2019-08-15 - 2019-08-25 because of PTO. So in case of troubles, I will not be able to do anything during that time. From that point, I could postpone the rebase if needed, but I hope that someone else will be able to help around instead of me in case of troubles.
> >>> --
> >>> Petr Stodulka
> >>> OS & Application Modernization
> >>> IRC nicks: pstodulk, skytak
> >>> Software Engineer
> >>> Red Hat Czech s.r.o.
> >> --
> >> Those who don't understand recursion are doomed to repeat it
Those who don't understand recursion are doomed to repeat it
I've just orphaned both adapta-gtk-theme and adapta-backgrounds.
The upstream project is more or less dead, since the main developer
left after getting a lot of negative feedback for the release of a big
refresh / redesign of the Adapta GTK theme (which was then reverted).
The fedora package currently provides the last version of the theme
*before* the redesign.
I originally took over these packages because I used them myself, but
since fedora 30 I'm using stock GNOME / Adwaita again, and so I don't
have any use for them anymore.
Additionally, since the last inkscape update (move to gtk3 and
python3?), the theme assets rendering during the build process is now
broken, and this would need to be fixed as well.
On Mon, Sep 9, 2019 at 10:58 AM Mat Booth <mat.booth(a)redhat.com> wrote:
>> Directly dependent packages of jboss-jstl-1.2-api:
>> - jboss-jsf-2.1-api
>> - jboss-jsf-2.2-api
> IMO, you should just retire the jboss/wildfly stack right now. It has not been maintained for years already: https://firstname.lastname@example.org...
Oof. I didn't know that it has been basically unmaintained for so long ...
This post predates even my becoming a "packager" in fedora :/
Concerning JBoss / wildfly: We'll eventually get rid of most JBoss /
wildfly packages anyway.
However, the team responsible for dogtag-pki still needs some jboss
packages as dependencies, so we can't just retire everything.
This is why we decided on the current procedure - only try to find
maintainers for packages the stewardship-sig and the dogtag-pki stack
don't depend on, and orphan / retire unnecessary packages "layer by
The end result should be about the same, but this way maintainers of
dependent packages have more time to adapt and / or react to changes,
and the changes themselves are smaller.
I'm trying to contact the maintainer (Marek Skalický) of
mongo-cxx-driver, which has a pending update:
However, if I try to select "Need additional information", I get an error:
You can't ask Marek Skalický <mskalick(a)redhat.com> because that account
Should the package have been orphaned?
I need to create a multi-package bodhi update for F30 and F31 to fix a
bug. Could a provenpackager help me out please? I only have commit
rights to wxpython.
For F31, please create an update with builds and tag bug #1739469:
Thanks a lot,
I'm trying to run systemtap on F29 and I'm getting the following error:
$ sudo stap -v journal.stap
Pass 1: parsed user script and 491 library scripts using
355824virt/129076res/9628shr/119256data kb, in 290usr/40sys/334real ms.
semantic error: while resolving probe point: identifier 'process' at
semantic error: no match (similar functions: read, free, getenv, page_size,
So, 'process' is not a valid identifier? There seems to be something wrong
with the basic systemtap installation. I do have matching debuginfo for
both kernel and systemd installed. Running stap-prep only wants to install
How do I make this basic use-case work?
Software Engineer, Red Hat